Using the Tezos Unity SDK for Large-Scale Game Development

The blockchain development company Baking Bad has released a new sample game to illustrate how game developers can use Tezos, the Tezos Unity SDK, and related tools to simplify large-scale game development.

The game is a third-person shooter that has the player blast a variety of demons with a selection of weapons and other power-ups. You can play the game via this link.

Let’s have a look at how this game illustrates the advantages of building games with Tezos and its SDK for the Unity game development platform:

Architecture #

To demonstrate how a game developer might set up an enterprise-level game application, the sample game is split into several components instead of doing everything in the Unity application itself:

• User wallets: Instead of managing player accounts itself, it outsources account management to the players’ Tezos accounts. More on that later.
• Unity WebGL application: The frontend of the game is made in Unity, one of the most popular platforms for multiplatform game development and immersive experiences.
• Backend application and API: The game uses a backend that hosts a REST API for the Unity application to call. The backend is responsible for secure operations like distributing tokens that represent in-game objects to players who earn them in the game. It also keeps track of active player sessions to demonstrate how an application can add dynamic services like monitoring active player counts and enabling live interaction between players.
• Smart contract: The game uses a smart contract, which is a program that runs on the Tezos blockchain. The smart contract maintains a ledger of tokens and owners and manages the creation and transfer of tokens that represent in-game items. Smart contracts are public, so you can view and interact with the game’s contract on a block explorer, such as tzkt.io.
• Interplanetary File System (IPFS): Like many decentralized applications, the game stores metadata for the in-game objects on the IPFS peer-to-peer file storage system, including pictures and descriptions.

This diagram shows the basic interaction between these components:

Ease of use for developers #

Tezos and the Unity SDK handle many peripheral tasks of game development so you can focus on the game itself. Here are a few ways that the sample game makes development simple by leaving things to Tezos:

Authentication and account management #

All developers know how much of a headache authentication can be. It can also be a real pain to store user accounts for any web application. Developers either have to store user passwords and account information securely or use federated identity to tie accounts to some other online service like Google or Facebook. In either case, they have to be responsible for some parts of account management, like allowing users to change the email address or federated account that identifies their player account.

The sample game shows how you can set up an entire enterprise-level application without dealing with authentication directly and without storing any account information at all, not even a list of players:

When the game loads, it prompts the player to connect their wallet:

Players click the Connect wallet button and select whether to connect to a wallet application via Beacon or a wallet that’s tied to a social media account via Kukai. From here, the TezosAuthenticator prefab takes over; all the game UI button has to do is call Tezos.Wallet.Connect(WalletProviderType.beacon) or Tezos.Wallet.Connect(WalletProviderType.kukai) and the Unity SDK and related tools handle the rest.

If the player picks a wallet application, the Beacon SDK handles the connection to many different Tezos-compatible wallets. If they pick a social wallet, Kukai handles the federated identity connection to their social media account:

The Unity SDK, Beacon, and Kukai handle all of the security for this connection process; the game doesn’t have to deal with any passwords or account information. After the player connects their wallet, the SDK triggers the WalletConnected event and provides information about the connected wallet to the handler function in the game’s UserDataManager class:

private void WalletConnected(WalletInfo wallet)
{
    ResetData();
    _connectedAddress = wallet.Address; // Player’s wallet address
    _pubKey = wallet.PublicKey; // Player’s public key
    // …

With these SDKs, the game can open a wallet app directly, link to Kukai for social wallets, or generate a QR code for the user to scan without having to handle any of these connections or support any specific wallets directly. The game also doesn’t have to remember any accounts because the wallet connection tools automatically reconnect wallets when the player returns.

As an additional verification step, the backend generates a random string and the game prompts the user to sign that string in their wallet. This step proves that the user has the private key for the account.

Here’s a diagram of how this authentication flow works in the full application:

Inventory management #

The game avoids having to store the player’s inventory persistently by storing all in-game items as Tezos FA2 tokens, similar to Ethereum ERC-20 or ERC-721 tokens. You can see these tokens in the game’s smart contract by looking it up on a block explorer such as Better Call Dev.

Each in-game item is a token type; there’s a token type for each different weapon and armor bonus module in the game. Here’s a token type that represents a specific gun:

Because it uses tokens to represent game items, the game doesn’t have to remember which items each player has. Instead, when the player connects, the game checks the tokens in the player’s account. It calls the SDK’s GetTokensForOwner() method, which accesses the smart contract and returns the account’s tokens. Then the game uses those tokens as the player’s inventory.

When the player gets a new game item, the Unity client calls the backend API, which calls the smart contract’s transfer entrypoint to send a token to the player. For security, all of this logic happens on the backend; the game’s private keys are kept on the backend so the game client never has access to them.

In this way, the game doesn’t have to store any player data directly; it’s all stored as tokens on Tezos. Also, because the game handles the transfer, its account pays all of the transaction fees. That way, game developers can handle the costs themselves and offer the game for free or charge players whatever they want.

The game does store some information in a database, but it’s all optional secondary information about player statistics, like the number of games played and the number of bosses killed. The game gets this information from the backend API.

Here’s a diagram of how token distribution works in the game:

Player freedom #

The SDK also allows the game to give players a lot of freedom in how they access it and use its in-game items:

Wallet choice #

Players get to pick their own wallet application and account. They can tie their Tezos account (and therefore their game account) to a social media account or use a separate, anonymous account on the wallet application of their choice. Players can have as many accounts as they want and they don’t cost them or the game anything.

Control over in-game items #

Because the in-game items they receive are stored in their wallets, players can work with them outside of the game application and even create their own ways of using them:

• If they accidentally log in with a different account and get a token, they can send it to their main account with an ordinary token transfer on many different Tezos platforms and wallet applications. There’s a built-in transfer tool in the game, but players with basic knowledge of how Tezos works can transfer them directly from other tools such as their wallets.
• Because the tokens are standards-compliant, players can see them and interact with them in their wallets, though they may have to manually add the contract as a source of tokens. Here’s a game asset shown in the Temple wallet:

• Because the smart contract and its token information are public, players can set up other uses of their tokens. They can create applications to show them off and trade them and games that recognize the tokens as game items just like the sample game.
• Even the metadata for the in-game items is public, stored on the decentralized IPFS system. Each token has a link to information and images that you can see on the Tokens page of a block explorer. Other applications like marketplaces can use this metadata to represent the in-game items.

Explore on your own #

To give these features a try, you can load the sample game in the Unity Editor and explore it on your computer. Here are the general steps for loading the game locally:

1. Install Unity Hub: https://unity.com/unity-hub.
2. Clone the sample game repository at https://github.com/baking-bad/tezos-unity-game.
3. In Unity Hub, click Add > Add project from disk.
4. Select the repository folder and click Add Project.
5. If Unity Hub prompts you to install a specific version of Unity Editor, follow the prompts to install that version.
6. Click the project in Unity Hub to open it in Unity Editor.
7. Open the “Main” scene to see the UI for the main menu, which handles most of the features around connecting to wallets and managing tokens:

From here you can explore the Assets/Scripts folder to see how the game runs.

We hope you’ll install the SDK and explore the sample game to see what’s possible with games on Tezos. If any questions come up, you can get in touch with the community on the Tezos Discord. More information about the game and the SDK is available at https://docs.tezos.com/unity/sample-game.