How to build a Web3 (blockchain) Game in 1 Week

Lost Dungeon is a casual blockchain game that demonstrates how to best leverage the potential of blockchain technology in gaming. Play here.

This article details how to build “invisible” blockchain features so that:

For players can just focus on gameplay, and still get the full benefits of web3 (ie. in-game asset ownership). No wallet connection for authentication, no gas fees or popups for transactions.
For game developers, familiar gaming tools at your disposal, powerful and reliable SDKSs and APIs with the necessary tooling to start monetizing at any point.

Why we built a Web3 Game

The goal of Lost Dungeon is to show the power of blockchain technology in the games. Traditionally players often suffer from limitations such as lack of gaming ownership and not being able to enjoy their progress in other ecosystems.

Our aim with Lost Dungeon was to establish an experimental mini-game that empowers players with complete control over their in-game assets. It is designed to reward gameplay with gaming value and provides players with genuine ownership over claimed items.

Moreover, it also enhances the gaming experience through unprecedented levels of interactivity and interoperability, extending beyond the game itself.

Game Architecture

Blockchain

Lost Dungeon is built on top of Avalanche Fuji Testnet. Leveraging Avalanche as the game’s public cloud infrastructure ensures transparency, security and immutability. Developers need to “do your own research” on the blockchain you want to launch and grow as each blockchains have different tradeoffs, demographics and focus.

Gaming Backend

Lost Dungeon uses Playfab as a backend as a service solution together with Azure functions to execute certain custom logic. At its core, the gaming assets and economics of the game are in the blockchain making the game a “web2.5” approach.

Player Authentication

Lost Dungeon usesPlayfab Authentication to onboard users with and without existing wallets. Providing a unified experience regardless of how crypto-saby the player is.

In-game Wallet

The first component of a game is the player. In blockchain, the player has both a profile/identity and a payment railway attached. In traditional blockchain we call this wallets and are crucial to hold in-game currencies and assets through the game. Wallets (or vaults in the gaming context) are crucial and can be generated at the backend of the game not to disrupt the player’s experience.

Onboarding crypto and non-crypto players In-game wallets offer standardize experiences for both crypto native and non-crypto native player base. We create smart wallets for every single player signing up for the first time. The main difference is that players with existing wallets will be the owner of the smart wallet being completely self-custodial. Players without a wallet will have a non-custodial wallet created link with their email. Both are completely indistinguishable.

Here is how we link an email to a non-custodial account

import Openfort from "@openfort/openfort-node";
const openfort = new Openfort(process.env.OPENFORT_API_KEY);
const OFplayer = await openfort.players
    .create({
        name: req.body.CallerEntityProfile.Lineage.MasterPlayerAccountId,
    });

Playing as a Guest We’ve also created a “play as a guest” button where players enjoy the game without having to sign up. This onboarding creates a wallet in the background that players would be able to claim if they want to save their progress in the game.

Gasless Transactions

Gas transactions are a massive friction point for onboarding new users. Onboarding a complete newcomer to Web3 involves creating a wallet and acquiring a native token to initiate their first transaction. For game developers, this process can deter potential users as they typically need to purchase the native token through a fiat on-ramp, which often necessitates Know Your Customer (KYC) procedures.

Granular gas sponsoring is essential to the gaming experience and it’s no exception with the Lost Dungeon, enabling players to perform actions on the blockchain without needing initial funds or worrying about the costs of transaction fees.

Openfort lets you define a gas policy to handle the payment transaction fees on behalf of the players. This pairs with any created wallet who doesn’t hold any funds initially. This combo enables a smooth and uninterrupted gaming experience, without the need for players to transfer AVAX or worry about gas prices.

Group 382-min.png

Signless Transaction

Signless transactions (Session Keys) are a massive leap forward for user experience. They allow users to pre-approve an application's transactions according to a set of parameters. Session keys are used to simply pre-approve your session and play the game without constantly being bombarded by your wallet asking “confirm this transaction”.

Here is how we use session keys on Lost Dungeon. We create a local session key to be able to buy a weapon (mint an asset) by pre-approving functions of the smart contract during a specific period of time.

using Openfort;
public class Web3AuthService: MonoBehaviour
private OpenfortClient _openfort;
private void Start() {
  _openfort = new OpenfortClient("pk_test_…");
}
private void RegisterSession() {
  Debug.Log("Registering session...");
  var loadedSessionKey = _openfort.LoadSessionKey();
  if (loadedSessionKey == null) {
    var sessionKey = _openfort.CreateSessionKey();
    walletConnectorKit.ChangeState(State.CreatingSessionKey);
    _openfort.SaveSessionKey();
  }
}

Group 383-min.png

Read more about gaming popless experience.

Beyond the wallet

Purchasing Assets (ERC721)

The Shop screen enables players to purchase weapons using their $GOLD tokens. Let’s walk through how this works.

The ERC721 contract allows players to “claim” the assets as long as they meet the onchain conditions defined on the claim condition of the contract. When a player clicks on “Buy” we hook up the purchase buttons of each UI item with the claiming function.

If the conditions are met, the player will exchange some $GOLD tokens for a weapon NFT.

const currencyAddress = process.env.GOLD_CONTRACT_ADDRESS;
const weaponAddress = process.env.OF_WEAPON_CONTRACT;
const _proof = [
    "0x0000000000000000000000000000000000000000000000000000000000000000",
];
const _quantityLimitPerWallet = 1;
const _receiver = resultData["OFplayer"].Value;
const _tokenId = Number(offerId);
const _quantity = 1;
const _pricePerItem = {
    "0": "1000000000000000000",
    "1": "10000000000000000000",
    "2": "20000000000000000000",
    "3": "30000000000000000000",
    "4": "40000000000000000000",
    "5": "50000000000000000000",
};
const _data = "0x";
const _allowlistProof = [
    _proof,
    _quantityLimitPerWallet,
    _pricePerItem[offerId],
    currencyAddress,
];
const interaction_1: Interaction = {
    contract: process.env.OF_GOLD_CONTRACT,
    functionName: "approve",
    functionArgs: [weaponAddress, _pricePerItem[offerId]],
};
const interaction_2: Interaction = {
    contract: process.env.OF_WEAPON_CONTRACT,
    functionName: "claim",
    value: "0",
    functionArgs: [
        _receiver,
        _tokenId,
        _quantity,
        currencyAddress,
        _pricePerItem[offerId],
        _allowlistProof,
        _data,
    ],
};
const transactionIntentRequest: TransactionIntentRequest = {
    player: _receiver,
    chainId: 43113,
    optimistic: true,
    interactions: [interaction_1, interaction_2],
    policy: process.env.OF_TX_SPONSOR,
};
const transactionIntent = await openfort.transactionIntents.create(
    transactionIntentRequest
);

You can find the Weapons Minting Contract used by the game here.

Collecting Coins -$GOLD (ERC20)

Group 384-min.png

The $GOLD token works as the in-game currency within Lost Dungeon. The in-game mechanics rely on the token to upgrade your progress in the game.

When onboarding for the first time, we drop the player with 1 GOLD. Players complete runs to obtain GOLD Tokens, which in turn can be spent to purchase weapons from the shop. These are NFTs owned by the players, and are reflected inside and outside of the game.

Some of the mechanics implemented in the game:

Reading balance. We’ve set a CRON function to periodically refresh the player’s balance. Additionally, we hook up a refresher for related user actions that update their balance.
Minting Flow. With Last Dungeon we used the aforementioned Sesion Keys to approve every action happening onchain. That’s in the case of the dungeon, the collection of Gold, triggers a minting event automatically.

We could also decide to put those transaction onchain once the game is over and batch them all together in one single mint to save on gas fees, but for the sake of this example we wanted to show how smooth it is with single transactions.

You can find the $GOLD Token Contract used by the game here.

Other notable features we could include

Transfer Ownership Allowing players with non-custodial wallets to transfer their ownership to a self-custodial wallet without exposing private keys.

Read more about how to transfer the account ownership.

Token Bound Accounts Turning battle passes or simple player avatars into smart wallets that could also host more game tokens and assets without. This approach ensure an easy transfer of wallets via the NFT directly instead of the signer.

Read more about the benefits of ERC6551.

Ecosystem ID Openfort's headless approach makes it ideal for building a gaming wallet on top of. Additionally, this enables the creation of companion apps and enhances the gaming ecosystem.

Read more about how to create your own ecosystem ID

Playing as a guest functionality Playing as a guest is a common way for players to authenticate to games, and all BaaS providers offer that functionality. The problem is that if the player has made some progress while playing as a guest, they will lose it for the next gaming session.

Learn how to implement it in our PlayFab guide.

Get started today!

By leveraging the Openfort APIs and Unity SDK, we were able to expedite the development process. We focused on creating a great gaming experience and fun core loop. The web3 integration was the easy part!

The SDK is fully open-source and permission-less. Give it spin and let us know what you think!