Skip to main content

Mechanics

Overview​

Every game is fundamentally a collection of various resources that a player manages and interacts with. The way resources behave and interact is defined by the game developer, often based on a foundational game narrative or lore.

In the realm of game development, managing game resources effectively and defining how they interact are central to creating an immersive gaming experience. Every action concerning a resource or the interplay between several resources is predetermined by the developer and built upon the foundational narrative.

To achieve modular game logic structures, developers use universal building blocks known as Mechanics.

Definition​

Mechanics are predefined logics designed to execute specific actions with one or more Non-Fungible Assets (NFA). These actions can be as simple as modifying a single NFA or as complex as orchestrating interactions between multiple NFAs.

Example

Suppose a player wants to construct a house on a selected piece of land. In this case, a mechanic is employed, which essentially merges the NFA “House” with the NFA “Land.” If the construction of the house is designed to take a specific duration, the mechanic can also set a status for the NFA “House,” preventing any actions with the house until a specified time elapses.

Working Principle​

At a high level, a mechanic acts as a process that:

  1. Accepts assets as inputs.
  2. Performs a set of predetermined actions on these assets.
  3. Outputs the results, which could be:
    • Changes to NFA properties.
    • Creation of new NFAs.
    • Increment of Fungible Assets (FA) quantities.

Lifecycle and Management​

Every mechanic possesses a lifecycle defined by a timeout. Once this timeout duration lapses, the mechanic is automatically canceled, and any resources engaged within it are freed. This design is crucial to prevent an uncontrollable buildup of stagnating mechanics, ensuring optimal game performance.

Upgrading Mechanics​

Game dynamics evolve, and sometimes there might be a need to adjust or upgrade mechanics. In such scenarios, an initiator can call for a mechanic upgrade by providing additional resources. This feature allows developers and game managers to adapt and enhance game mechanics without disrupting the ongoing game flow.

Mechanics​

destroyNFA​

Description: Destruction of NFA. This operation is utilized for the destruction of an NFA.

The NFA destruction takes into account its Destroyable characteristic if it's defined.

During the destruction process, the Residual characteristic is taken into account. If defined, logic specified in this characteristic (like asset generation) is executed.

The destroyNFA mechanic largely mirrors the operational logic of the createNFA mechanic.

Execution Context: UserAccount

Parameters:

  • assetId - ID of the asset to be destroyed.
  • assets[] - List of various NFAs required to produce the NFA of the createdNFAClass type.

Execution Result: The NFA with the specified ID owned by the UserAccount is destroyed. Assets are generated (if applicable).

terminateNFA​

Description: Destruction of an NFA without considering the Residual characteristic. It is used when the NFA shouldn't generate other assets upon its destruction (if applicable).

Execution Context: UserAccount

Parameters:

  • assetId - ID of the asset to be destroyed.

Execution Result: The NFA with the specified ID owned by the UserAccount is destroyed.

transferNFA​

Description: Transfer of an NFA between UserAccounts.

Execution Context: UserAccount

Parameters:

  • assetId - ID of the NFA to be transferred.
  • toUserAccount - ID of the recipient UserAccount.

Execution Result: The ownership of the NFA with the specified ID has changed.

caution

An NFA cannot be owned by a DevAccount.

createNFA​

Description: Creation of an NFA. The NFA creation is carried out by a UserAccount.

An NFA of a specific class has predefined characteristics and properties. The createNFA operation endows the NFA with these properties using the required resources and materials.

For the operational algorithm of the `createNFA` mechanic, see here

Definitions​

  • Initiator Generally, the player who, through a certain action in the game, triggers the execution of a mechanic.

  • Target NFA An NFA that is created through the mechanics.

  • Resource NFA An NFA that possesses the characteristic of Resource.

  • Production Production is the process of transferring production_property from the resource NFA to the target at a production_rate pace.

General Work Cycle​

  1. The Initiator requests the creation of a mechanic with parameters:

    1. createdNFAClass - the class of NFA, of which the NFA should be created.
    2. assets[] - a list of NFAs required for creating the desired NFA.

  2. The mechanic checks if there's enough FA (Functional Assets) for creation. This check is utilized only in cases where the NFA being created (according to the NFA class) requires the use of certain FAs. If the UserAccount doesn't have enough FA, an Event indicating a shortage of FA is raised, and the execution of the mechanic is canceled.

  3. If the UserAccount has sufficient FA, it's debited, and an event with the mechanicId is returned to the initiator, through which the initiator can interact with the instance of the mechanic.

    The mechanic locks all the provided (used) NFAs so they can't be utilized in other mechanics or be managed in other ways.

    The mechanic then starts the deduction of the production_property from the NFAs (which have it and are passed into the mechanic) at a production_rate. Simultaneously, from the resource NFA (from which the production_property is deducted), the spending_property is also deducted at a spending_rate (if available).

  4. In the event that the spending_property runs out, the mechanic notifies the initiator and releases the corresponding NFA.

  5. Production halts if there isn't a single resource NFA left in the mechanic with the corresponding production_property, until the initiator upgrades the mechanic with a resource NFA having the required production_property.

  6. If the initiator doesn't possess the required resource NFA, they can cancel the mechanic.

  7. In this case, the mechanic is canceled, all resource NFAs are unlocked/released, and an event is sent indicating this.

  8. When the entire volume of production_property has been transferred to the target NFA, all resource and target NFAs are unlocked/released, and an event is dispatched about the completion of the mechanic instance.

Execution Context: UserAccount

Parameters:

  • createdNFAClass - The class of NFA to be created.
  • assets[] - List of various NFAs required for the production of the NFA of the createdNFAClass type.

Execution Result: An NFA owned by the UserAccount is created.

topupNFA​

Definition:
Accumulation of the required FA (Funds or Features Allocated) for a subsequent NFA upgrade.

FA accumulation is only possible for Upgradable NFA. The mechanic checks if the given NFA can accumulate the transferred FA (see the fundedFA property), deducts the required amount from the UserAccount, and credits this amount to the fundedFA property. If the NFA cannot accumulate the provided FA, the mechanic is aborted with an error.

Execution Context: UserAccount

Parameters:

  • nfaId: The NFA to which the FA needs to be credited.
  • fundedFA: The FA that needs to be credited.
  • amount: The number of FA to be credited.

Execution Outcome: The NFA receives the specified amount of FA in the fundedFA property.

upgradeNFA​

Definition:
Upgrading a specified characteristic using FA. It works in conjunction with the topupNFA mechanic.

In certain situations, there's a need to improve the value of a particular NFA property if it's intended by the Legend. Details can be seen in the Upgradable description.

The mechanic checks the accumulated amount of the required FA against the threshold for the next conversion and converts it if possible.

Execution Context: UserAccount

Parameters:

  • nfaId: The NFA that needs an upgrade.
  • propertyId: The Id of the property to be upgraded.

Execution Outcome: The specified NFA property is changed in accordance with the conditions set in the upgradableProperties of the NFA.

recoverNFA​

Definition:
A mechanic that restores the characteristics of the NFA using FA or by destroying a Material MFA.

For instance, healing a fighter using a medkit.

The recovery is based on the value of the property with the same name in the transferred Material NFA, but not more than the maximum allowable value.

If the transferred Material NFA has multiple attributes with the same name that are recoverable, all matching ones are restored.

For example, if a fighter has recoverable attributes like strength, health, and mood, and the medkit has strength and health, then only strength and health will be restored based on the medkit's values. Mood will not be restored.

Execution Context: UserAccount

Parameters:

  • nfaId: The NFA that needs its characteristics restored.
  • recoverableByFA: The FA, its sum, and the property's name that needs to be restored.
  • assets[]: List of NFAs used for restoring characteristics. They must be Material NFA with properties of the same name that are available for restoration in the target NFA.
caution

The properties recoverableByFA and assets[] are mutually exclusive - only one of them can be passed to the mechanic.

miningFA​

Mechanic that produces FA (Finite Assets).

This is required when a game asset needs to produce FA, following the game's Legend.

For example, a windmill produces electricity.

The production of FA is facilitated using an NFA (Non-Finite Asset) that possesses the Miner characteristic.

Execution Context: UserAccount

Parameters:

nfaId - The NFA responsible for mining the FA.

assets[] - List of various NFAs needed for extraction (materials and NFAs required for blocking).

Execution Outcome: The NFA mines FA until the mechanic is manually halted or the required FA and/or Material NFA are exhausted.

bet​

Mechanic with a probability defined in NFA Bettor that dispenses predetermined resources (FA and NFA).

This is required when there's a need to implement betting or a random chance of winning a prize.

For example, using a key to unlock a chest, but the key might break. Or place a bet on "black".

The mechanic is accessible for NFAs possessing the Bettor characteristic.

The mechanic randomly chooses an outcome from those set in the NFA and returns it. If the outcome is winning, the player is credited with predetermined FA and NFA set in the Bettor.

If the Bettor defines a number of tries (Rounds, the mechanic concludes only after all rounds are carried out (or when a win/loss can be distinctly determined).

For instance, a triple coin toss. If the first two tosses are unsuccessful, the third doesn't make sense, so the mechanic concludes prematurely.

Thus, if multiple rounds are needed, the mechanic doesn't conclude instantly. The continuation of the mechanic's operation is via upgradeMechanic with an empty asset set.

Each outcome's result is returned as an event.

Upon initiating the mechanic, the NFA Bettor is locked. NFA is only unlocked in one scenario: if the result is deemed a Draw, and in Draw Outcome keep is indicated. In all other instances, including timeouts, the NFA Bettor is destroyed.

Parameters:

nfaId — NFA of type Bettor

Execution Outcome: NFA is destroyed. Specifically, if the outcome isn't determined Draw Outcome, the indicated property behavior is used. When winning, the player receives assets predefined in the NFA Bettor.

buyNFA​

Mechanic that creates an NFA instance for FA, in line with the characteristics defined in Purchased.

This is needed to purchase any assets within the game.

For instance, buying a potion to restore strength.

Parameters:

classNfaId — NFA of type Purchased

Execution Outcome: FA is deducted from the game account, creating an NFA with specified characteristics for the player.

Mechanic Operations​

A mechanic may operate over a certain period, and during its execution, situations may arise where actions or modifications to the mechanic are necessary.

For example, building construction. If a worker runs out of energy, they stop building, and a new worker needs to be assigned to the construction or the existing worker's energy must be replenished.

To interact with mechanics, operations are used.

getMechanic​

Retrieve all information about the mechanic.

Execution Context: DevAccount, Mechanic Owner (UserAccount)

Parameters:

mechanicId - Id of the mechanic instance

cancelMechanic​

Cancel the execution of the mechanic. In this case, all unused assets are unlocked.

Execution Context: Mechanic Owner (UserAccount)

Parameters:

mechanicId - Id of the mechanic instance

upgradeMechanic​

Make modifications to the mechanic.

Add/remove assets from the mechanic.

Execution Context: Mechanic Owner (UserAccount)

Parameters:

mechanicId - Id of the mechanic instance

assets[] - a list of various NFAs (Non-Fungible Assets) that should be used by the mechanic. This is the complete list. If an NFA is not in the list, it means it should be removed from the mechanic.