Adding Web3 elements to your game: why and how?
Overview
This high-level guide is geared towards both developers and non-developers considering whether or not to add Web3 elements to a game.
Below, we cover the benefits of adding Web3 elements to a game and help you think about how much to add (spoiler alert: you don't need that much to make a big difference). We then cover the key questions you need to ask to get started planning. We also provide a high-level overview of the possible interactions between your app, other apps, and the blockchain so that you'll know what to look into further in order to proceed. Finally, we share next steps if you're interested in learning more.
Adding Web3 elements: why and what?
Player ownership = engagement, retention
Web3 = infusing your game with assets users can own, upgrade, lend, trade, use for rewards and experiences, and more. It's a powerful way to increase engagement and can enhance replay-ability and community excitement about your game.
Games have always rewarded players for time spent and accomplishments achieved. For example, leveling up a character, earning gold or gems that can be used to buy items, and unlocking new levels. What changes with Web3 is that players now have true ownership over these items and rewards.
This ownership is also publicly visible - not restricted to a private database that only your app has access to. This means that other Web3 apps can see the data in a standardized way that they know how to read. This can enable new avenues for engagement and value accrual. For example, players joining a Web3 social network can display the game sword they proudly earned on their profile by proving that they own it. Or, they could sell the item on a marketplace, earning some profit for their long hours spent on the game (and earning your game a cut of the sale).
As we'll discuss below, you may or may not give players full control over their assets immediately, as full control means more effort on their part and less control on yours. You may slowly give them more control over time, or only give this control to players who want it. The goal is not to force a bunch of effort and new ideas onto all players, or to create new unpredictability for you, the game maker. It's to use true ownership and public visibility of assets, and the new opportunities this creates, only when it benefits your users and your game.
Two common examples of owned assets are covered next.
In-game items
Gamers are used to acquiring items and upgrades for their efforts. Now, you can give players verifiable ownership on a blockchain of some of these items. Why is this good for you or the player?
Players feel more invested in your game, because this unlocks the opportunity to buy, sell, lend, or trade these verifiably scarce items in a transparent way where they won't be scammed. No more transferring money to a PayPal account and hoping that the person on the other end actually gives you their World of Warcraft password. Allowing players to have control over using, displaying, and trading these items gives them an enhanced sense of connection to your game and a pride in their in-game accomplishments. It can also help build a vibrant community around your game, as players interact with each other and display their assets for yet-to-be-acquired users to see. Letting players sell their items adds a new way for both the players and your game to make money on what the players are doing anyway: having fun playing your game.
Your game gets access to a global market where you can get a cut of these sales. For an example of how player ownership of in-game items can drive engagement and retention, see our case study with BlueJay Games.
Tokens
A game-specific blockchain token can be used to give players a stake in the success of the game's community. Tokens can be given for playing the game, but also for taking other actions that drive interest to the game like posting on social media. These tokens can be exchanged for all sorts of rewards like unlocking new maps, game merchandise, etc. Players can also be given the option to sell some of their tokens to others, earning money for their time and effort building your ecosystem and creating additional value around your game.
The benefits for you include driving player engagement and community growth, rewarding players fairly, and easily tying rewards to key actions you want to promote. For an example of how a token can be used to drive engagement and retention, see our case study with Playground.
How to add Web3 elements to your Web2 game?
Start small.
Let's not forget what players care most about: a great UX and a game that's fun to play.
You don't need to write every change in player or game state to the chain. A good place to start is with one key item like an in-game object represented as on-chain NFT. This could be a character or a key item that character uses. Just owning one important thing can make a big difference in how connected a user feels to a game.
As a result, you don't have to read from the blockchain or write to it constantly. You can cache some chain-based game state and will almost certainly store some in your internal, private databases. You only need to write major changes to the blockchain, like when a user acquires that key item for the first time or when it's upgraded.
Introduce it slowly.
Player ownership is something you can slowly layer in over time - after all, these things are a reward for spending time in your game. When players launch your game, the reason they come back the next day is because of great gameplay and/or community. No NFT can make up for a boring game.
Instead, think about ownership as one of multiple reasons why a player sticks around for week two or month two. Maybe they don't earn ownership of a game object, or game tokens, until level 20. Or, after 10 hours of gameplay. From there, maybe they don't earn an upgrade or more tokens until level 30, or another 5 hours. And, maybe that second point is where you introduce to them that they have a personal Web3 wallet behind the scenes.
You can then give players the option to learn more or take direct control of their wallet, but don't force it. Later, you can introduce actions they can take with their wallet, like selling their object to another player or trading some of their tokens for a reward. Eventually, they can gain full control over the items in their wallet by either taking control of the wallet or transferring the items to a wallet they control. The point is to not make Web3 knowledge a requirement of playing your game. Instead, these elements are an optional but rewarding enhancement to a player's experience with your game and game community.
Questions to think through
The following questions are designed to help you think about how and what Web3 elements to add to your game. The presumption of this section is that you do not want a game where users need to be Web3 experts to play.
How will users ultimately benefit?
You should have a plan for at least one way you think users will benefit from storing a game asset in a blockchain wallet as opposed to your private database. The plan may change as you get more feedback from players and see what's working well about your game and what can be improved. Further, the benefit may not come immediately. Still, you should have one in mind.
Examples include:
- Users will eventually be able to take full control of their NFT(s) or tokens and sell or trade them as they wish on third party Web3 marketplaces and exchanges.
- Users will be able to sell or trade their NFT(s) or tokens in an in-game marketplace you create.
- Users will gain special rewards for having the NFT(s) or tokens - perhaps the ability to unlock new levels or level-up their heroes faster.
Decision to make
- What is our initial plan for how users will benefit from this effort, both initially and in the future?
What initial asset(s) will be on chain?
This is directly tied to your plan for the value users will get. As we covered above, key options include:
- NFT(s) representing in-game characters or items.
- Game-specific reward tokens.
- Designing a good plan for how your game's tokens are created, earned, used, transferred, burned, etc - called your "tokenomics" - can be a significant amount of work. It's important to think through all the relevant user scenarios, to balance rewards and distribution in a way that's fair and meaningful to players, and to be flexible enough to accommodate both a user base that can change size over time and the fact that your rewards and plans may change over time. You also may want to include an element of governance with your token - where token holders can vote on the direction of your game (but be careful if non-players can buy these tokens).
Decisions to make
- Determine which game assets, if any, will be stored on the blockchain. It's okay to start small with one item - like a player's in-game character - and add more over time.
- Determine whether you will have an in-game currency that lives on the blockchain. You could keep game tokens inside the game and not allow transfer or sale of the tokens to happen outside of the game (at least initially). You could also award players experience points in your database as a first step, and later convert those to tokens once you've finalized your token plan.
What on-blockchain code will your app need?
You will need the code - called a smart contract - that defines your NFT or game token specifications and how to create, transfer, upgrade (for NFTs), and (optionally) destroy these assets. We talked about blockchain as a public database above, but really it's a public computer with code that runs on top of a database. Some of the code that runs on it is smart contracts (the other code is the blockchain protocol itself, which processes transactions).
You often won't need to write a lot of code, but you'll need someone with experience working in the programming language of the chain (or able to learn it). As an example, here is the Sui Move smart contract code for our game dashboard demo (which requires a free Shinami account in order to log in and use).
Needs
- A developer on your team or a dev shop you hire you to write your smart contract(s).
- (Especially if you make an in-game currency) A smart contract audit (a specialist reviews your code to look for errors in your desired functionality, security vulnerabilities, etc).
How often will a blockchain write occur (and who pays)?
- If you made the wallet, you should pay the small gas fee for the transactions as the users will not have any tokens needed to pay.
- If the user connected the wallet, it's up to you. However, sponsoring the gas fee can drive more interactions with your game.
Needs
- A developer on your team or a dev shop you hire to write code that builds and executes blockchain transactions that mint game assets (NFTs or token). This will involve both the service that manages your player wallets (e.g. Shinami wallet service) and a Node Service to write to the blockchain. Shinami has a TypeScript SDK that makes this easy.
- A plan to sponsor the gas fees of these transactions. This is done in the same code as the first bullet point. With Shinami you can sponsor the gas for a transaction for an embedded wallet with 0 additional requests needed!
How often will a blockchain read occur (and will you cache/duplicate this info in your internal db)?
If you have full control of player wallets, the most you would need to read is likely each time a player logs into your game and then whenever a change occurs (e.g. your game upgrades the player's character and the NFT representing it). Further, you may wish to duplicate some or all of the information about each player's character or game token total in your own internal database. This can provide faster read times, fewer requests to your blockchain Node provider, and redundancy.
If some or all of your players have control over their wallet (and thus their NFT(s) or game tokens), you'll need to check the blockchain regularly. This is because players can transfer assets to another wallet (including selling them to another player). In this case, you may wish you read from the wallet when each new level starts, every X minutes, etc. You still may wish to cache or duplicate some of this data in an internal database, but you'll need a mechanism to check and update this information regularly to catch any changes in what a player owns. These changes could also mean a player's inventory decreases or increases - for example if player A buys an NFT representing an item from player B because they want to use it in the game, or if player A has two accounts and transfers game tokens from one of their accounts to the another.
Needs
- A developer on your team or a dev shop you hire to write code that reads what exists in a user’s wallet.
- (optional) A caching strategy for frequently read data.
- (optional) A data duplication strategy for game assets that also exist on-chain.
What wallet type(s) will you support
This ties into how users authenticate with your app as well as whether you want to accommodate users connecting a pre-existing Web3 wallet to your app. It is also a question of user control vs hassle: embedded wallets, a common choice for games targeting Web2 natives, introduce little to no friction for the player with the tradeoff that players don't have full control over their assets.
It may be that the wallet players use can change over the course of their time with your game. For example, you may start all players with embedded wallets and give them the option to later migrate to a connected wallet that stores their game assets (maybe as a part of future work to add more Web3 elements to your game).
Here is a brief summary of wallet types:
# | Wallet type | User authentication | Required user interaction | Wallet only works with your game | User can initiate transfers, sales, etc of their game assets on their own, even when not logged into your game | Target user type |
---|---|---|---|---|---|---|
1 | Invisible NFT wallet (embedded) | Whatever your game already does. | None. Provides for a very smooth UX. | Yes | No | Web2 native |
2 | Single-app zk SSO wallet (Sui zkLogin, Aptos Keyless) | User logs into their supported SSO provider. | Logging into their account with an SSO provider (e.g. Google), which may or may not be how they already log into your game. Beyond that it provides for a very smooth UX. | Yes | No | Web2 native |
3 | Connected browser or app wallet (including SSO-login wallets). | User logs into your game and their wallet so they can connect the wallet. | 1. Logging into their wallet app and connecting it to your app. 2. Remembering their secret phrase, wallet password, and/or their SSO login password (e.g. for Google). 3. Approving certain transactions (e.g. minting an NFT or listing it for sale). | No | Yes | Web3 native, or Web3-curious |
A true Web3 experience means players have full control over their assets, so you may want to eventually migrate your users to #3 (if they opt in). Or, you might decide to introduce Web3 elements while retaining the great UX that comes with embedded wallets - like an in-game marketplace that lets users freely buy, sell, and trade game assets with other players.
Decision to make
- Determine what kind of wallet(s) you want to support your initial use case. #1 or #2 in the table above are good starting points. You can read more about them in our high-level Wallet Services guide for Aptos and Sui.
When and how will you introduce the Web3 elements of your game to users?
For a summary of these considerations, see the "How to add Web3 elements to your Web2 game?" section above. Here, we give an image showing what was discussed above, along with a comparison for the connected wallet case.
Example timeline for introducing Web3 elements

As you can see, for the common embedded-wallet case, you don't even have to tell the user they have a wallet that stores something until they've reached a certain milestone - like playing for 15 hours or beating level 8. In the case of a connected wallet, you'll likely want to tell players right away when they can expect to earn something and what they'll earn (because these are Web3 natives who are expecting to own an asset or token for investing time in your game).
Decision to make
- When and how will you introduce the Web3 elements of your game to users?
What blockchain will you build on?
Shinami works with Move blockchains because of the powerful combination of low latency, high-throughput, cheap transaction fees, and a secure smart contract programming language. We have guides that cover the specific benefits of connecting your game to the Aptos or Sui blockchain.
Decision to make
- Choose a blockchain to integrate with.
High-level overview of interactions
Below is a high-level overview of the key interactions that could take place. It's not meant as a detailed, technical integration guide, but as a way for you to get an initial sense of the overall picture so you can learn what you may need to look into further.

Summary of some of the apps and services above:
-
User-connected wallet. Most Web2 games adding Web3 are likely to not have this, at least at first. It's for the case when Web3-knowledgeable users have full control over their assets, with the extra user-effort that comes with that. Examples include Petra for the Aptos blockchain and Sui Wallet for the Sui blockchain.
-
Asset resource server. Not all the data associated with an in-game asset lives on chain. Some, like logic involving game mechanics or all the audio dialogue for a character, will live in your private databases. Others, like an image for the character, needs to be at a publicly-accessible endpoint. This is so that other apps can read from it, including: user-connected wallets, blockchain explorers, and NFT marketplaces. For examples, see our guide summarizing how NFTs work on Aptos or Sui.
-
Web3 infrastructure provider. You'll need the following pieces of infrastructure
-
Service What it does High-level guide to learn more about the services and what Shinami offers Node Reads from and writes to a blockchain. This is how you mint NFTs or in-game tokens and transfer them to players wallets. Aptos --- Sui Gas Station Facilitates easy sponsorship of user wallet transactions. Important because for an embedded wallet a user will have no crypto in it and may not even know it exists at first. Aptos --- Sui Wallet Service Helps you create and manage embedded user wallets. Aptos --- Sui
-
-
Other Web3 Apps. These are common apps that may interact with your on-chain data. Examples:
-
App type What it does App examples Blockchain Explorer Lets players explore what they own on a blockchain. SuiVision (showing a Shinami game demo NFT) NFT Marketplace Allows players to to buy or sell NFTs. Only relevant if you enable this for players via embedded wallets or let them connect their own wallet. This functionality could be replaced by an in-game marketplace you run. Tradeport, BlueMove Crypto Exchange Lets people buy or sell a token, or trade one kind of token for another. Only relevant if you have an in-game token and you allow it to be sold on exchanges. Bluefin, Panora
-
Next steps
- Read about how Playground and BlueJay Games use Shinami + Web3 elements to drive user engagement.
- Read about the benefits and more specifics about connecting your game to the Aptos or Sui blockchain.
- Reach out to us at
support@shinami.com
if you have any questions!
Updated 2 days ago