Balancing Game Economics with Crafting

Mighty Bear Games is thrilled to introduce its groundbreaking Web3 game, an innovative blend of Web2 and Web3 philosophies. Within this discourse, we’ll delve into the intricate realm of game economics, emphasizing the craft, and revealing the rationale and technical subtleties behind crafting mechanisms.

Crafting, historically, has been a game of equilibrium between player satisfaction and in-game economic stability. With the advent of Web3, where in-game assets possess tangible real-world value and can be traded, utilized, or demolished, this balance becomes even more intricate.

Crafting Mechanics: An Overview

In our novel battle royale game, players wield the capability to craft various items from ingredients. These aren’t mere components; they dictate the result, quality, and nature of the crafted product. For example, fusing fragments can yield shells, which, when amalgamated with components like Boomdust, transform into potent Grenades.

The Essence of Bonding Curves

The crafting materials’ price, notably the shell, experiences fluctuations driven by demand and supply dynamics, overseen by the bonding curve. This curve is a mathematical representation that determines a token’s (or our in-game items) price, relying on its supply.

Crafting Process: A Technical Deep Dive

Our crafting system, powered by Spring Boot, embodies a structured approach:

• Initialization and Validation: This foundational step validates crafting requisitions, verifies the quantity, and confirms the recipe’s presence in our database.
• Bonding Curve Integration: Here, we ascertain if the resultant item price is governed by the bonding curve and subsequently determine the necessary materials.
• Material Checks: This dual-phase check confirms that players possess the necessary components for crafting.
• Rolling for Outcome: Introducing an element of unpredictability, a dice roll alongside logic like crafting success rates governs the crafting’s success or failure.
• Crafting Outcome Determination: Drawing from the dice roll, crafting results are computed.
• Price Adjustments: Post-crafting, if items fall under the bonding curve’s ambit, their prices are adjusted to maintain in-game economic equilibrium.
• Persistence & Finalisation: Crafted items and alterations are stored, updating player inventories.

Significantly, failure doesn’t spell doom. Unsuccessful crafting attempts still yield items, like burnt Boomdust, offering players consolation and motivation to reattempt.

Crafting in the Age of Concurrency

The online gaming universe demands promptness. This urgency often culminates in multiple simultaneous server requests. With crafting at the intersection of game economics and player repercussions, data integrity and concurrent request management are critical.

The Dilemma of Data Integrity

Crafting launches a sequence of database interactions, stored in Amazon’s DynamoDB, renowned for its agility. Central to our crafting paradigm is the PlayerItemUpdateUtility class. This class shoulders the responsibility of crafting transaction integrity:

• Initialization: This step validates the crafting order, confirming requisite items and quantities.
• Atomicity with Versioning: Versioning ensures atomic updates since DynamoDB isn’t inherently transactional. Each PlayerItem sports a version attribute. Prior to updates, current versions are compared against intended versions. Discrepancies hint at concurrent updates, prompting retries.
• Handling Update Failures: Our system’s tolerance is marked by MAX_TX_ATTEMPTS. Upon successive failures, crafting operations are terminated.
• WebSocket Notifications: Successfully crafting dispatches notifications via webSocketService, keeping the player’s interface updated.

Concurrency: Challenges and Countermeasures

Our strategy isn’t without hurdles:

• Negative Quantities: Protections prevent quantities from becoming negative. Failures in this regard prompt players to retry.
• Conditional Checks: DynamoDB’s conditional writes fortify crafting operations. Failures trigger exceptions, efficiently managing concurrent requests.
• Scaling with Traffic: DynamoDB’s scalability ensures the crafting system’s resilience during traffic surges. Our utility class gracefully handles potential bottlenecks.

Crafting Logic Behind the Scenes: An Insight

Crafting, in its essence, is more than just combining items; it is about breathing life into the players’ intentions, giving them the tools they require to survive, thrive, and conquer on the virtual battlefield. This intricacy is well-captured by our crafting system at Mighty Bear Games. But what happens behind the curtains? Let’s unveil the secrets of our advanced crafting logic.

Deepening the Dive into Crafting Transactions

• The core of crafting, as many might reckon, lies in transactions. Crafting transactions are a reflection of the player’s interaction with the game’s crafting system. But what are these transactions? At Mighty Bear Games, we’ve designed the CraftingTx class, a component stored in our DynamoDB database. This component embodies all details regarding a crafting activity: the player involved, the recipe, ingredients used, and the output.

1. Crafting Transaction ID: Every transaction has its unique ID (txId), assuring easy identification and traceability.
2. The Crafting Recipe: The crafting action is guided by the recipe used (recipeId). It dictates the items to be combined, the quantities, and the outcome.
3. Input & Output Dynamics: Every crafting action involves ingredients (inputs) and yields products (outputs). This mechanism ensures a seamless transformation from what players provide to what they get.
4. The Price Data: While the realm of virtual games can seem disconnected from reality, the real-world value of in-game assets can’t be ignored. The priceData attribute is a reflection of this, hinting at the real-world value of crafted items.
5. Crafting Updates: With every crafting action, the inventory must be updated. The list pendingPlayerItemUpdates ensures that every ingredient used and product obtained is properly logged and updated in the player's inventory.

Safeguarding Crafting Transactions

In the vast realm of Web3 gaming, discrepancies can emerge. Imagine a situation where a player crafts an item, but due to a minor glitch, the crafting doesn’t finalize. Such scenarios could lead to dissatisfied players. Therefore, our code contains safeguard mechanisms:

1. Crafting Transaction Discrepancy Handling: The handleCraftingDiscrepancy function is our sentinel. It scans for incomplete crafting transactions and ensures their proper completion. In cases of discrepancies, they are corrected, ensuring no player loses out due to system issues.
2. Scheduled Discrepancy Checks: Technology, while remarkable, is not infallible. Errors might creep in, but our system is vigilant. With the invokeHandleCraftingDiscrepancy function, set on a scheduler, we periodically check for discrepancies, ensuring crafting integrity at all times.

Crafting Outcomes and Determinants

Crafting isn’t purely deterministic. An element of randomness makes the game intriguing. Our computeCraftingResults function showcases this balance. While certain crafting actions yield predictable results, drop tables introduce unpredictability. Whether players get a coveted item or a common one is decided here.

Additionally, crafting is not limited to fungible items alone. With the buildOutputsFromResults function, we handle non-fungible tokens (NFTs), ensuring that each crafted NFT is unique, providing players with distinctive in-game assets.

Conclusion: A Symphony of Logic and Creativity

Crafting in our battle royale is an elegant dance of game design, economic theory, and technical architecture. At Mighty Bear Games, we ceaselessly evolve, embracing trends like Web3, and prioritizing impeccable player experiences. As you immerse yourself in our world, craft unique treasures and navigate the challenges of the battle royale with finesse.