About

Outer Fields is an ambitious proof-of-concept project that demonstrates a PVP trading card game built around decentralized ownership and user-economy. Utilizing decentralized identities (DIDs), and on-chain tokenization all asset ownership is maintained via users own self-custody, with users and their linked assets (cards) identified and linked via their own chain DID registered with their account. Users may then utilize these card assets via building “Card Sets” in-game in PVP battles vs other users with a fallback on an adaptively skilled bot. Users are rewarded with either card drops, or tokens which can be redeemed for card packs, which are issued directly to their on-chain address.

Reasoning behind project

I’ve always dabbled in game development, and upon seeing the primitives offered by the Chia Blockchain, creating a TCG around these on-chain primitives seemed like a fun and interesting challenge. The ability to tokenize assets and allow for users to trade them and maintain full ownership is both an interesting concept, and allows for vibrant economies around assets to exist organically with out any control/concern of the developer.

Implementing a full online multiplayer back-end also is an interesting challenge and a great learning experience, this coupled with particularities around assets being on chain made for the project to be a great learning experience in building a full back-end architecture reliant on multiple services and the ability to process and handle many events in real time. This meant that both real time systems for handling the game logic where needed, along with a robust backend and database for tracking and managing result, users accounts, updating and tracking assets, and issuing and tracking rewards.

Back-end Architecture

The core services supporting the back-end of the project are:

Auth Service: Handles login and session token issuance. When connecting via websocket for matches, or making http requests users session token is validated with the auth service. Session token is included with requests to other services to facilitate this, and is also used to handle reconnection.

— Game Service: Handles matchmaking, PVP game-logic, Bot instances, Account interactions (Name changes, Creating card sets, Avatars). Utilizes a concurrent architecture for performing matchmaking and game logic. Game logic is refreshed at a 200ms interval, which each match having its own state that queues players incoming moves, validating and applying them at the refresh interval. This service also handles account requests like name changes, avatar changes, players stored card sets, leaderboard/results. Match results and rewards are committed to the database for later issuance by the item service.

— Item Service: Handles the issuances of rewards, monitors and parses all new blocks for redemption of card pack tokens and the movement of assets between DIDs. The item service handles the issuance of all new assets as well as the tracking of existing ones. At a set interval once daily all the pending rewards are queued and issued on chain, the item service also monitors all new blocks checking if any card pack tokens are deemed to a specific address. These redemptions are then calculated via chance and the resulting cards queued to be issued, with issuance happening after a set queue size or wait time. Detailed logs are kept around issuances, as well as retry on failure logic to ensure assets or always successfully issued, logged and auditable, with any issues and failures both logged and commited to the database to rectification. Item server also handles resolving players avatars, which can be any NFT owned by their DID. This is parsed from the on-chain data, validated/resized and uploaded to amazon S3, players can change their avatar once a day.

— Database: While players use their DID and on-chain wallet for managing assets, players also have account data like their name, avatar and up to 10 card sets that are stored server-side. The data base also stores all game results, asset issuance/redemption, failures, and caches all card assets to quickly load players assets.

— On-Chain Services: One node instance, and one wallet instance is ran in a vm. The wallet instance handles all asset issuance, while the node instance is used for transaction submissions and for making queries to the blockchain database for new block data. A small service is ran on the node, so the item service can make predefined queries via rpc to get either new block data or data needed for redemption services.

Front-end Architecture

Front-end is HTML5/OpenGL powered by godot 3.5. Players are provided a robust ui for inspecting card and their stats, a ui to build and design card sets to play, the decentralized marketplace dexie.space is also mirrored when users are browsing cards, so as users are viewing cards they are also presented with existing ones offered for trade/sell. This is all facilitated on-chain and does not involve the back-end at all. Users are presented with offer files from dexie.space which are half signed transactions that users can complete on-chain.

When in matches all gameplay actions are facilitated via dragging and dropping the card to be played either on the opponent or a players own pawns depending on the card and its logic. All cards of the players, and visible cards of the opponent can be right clicked on to view and inspect their stats/logic.

The front end communicates to the back-end via https requests. All active game logic is communicated via websockets, and while a player is active they maintain a websocket connection, after a period of inactivity this connection is dropped. Things like players historical results, assets, existing card sets, leader-boards, opponent account info is refreshed via get requests to the backend. Upon logging in a temporary session token is acquired, this is used to authorize http requests and for upgrading a websocket connections, this makes it easy to handle network dropouts and quickly reconnect and upgrade websockets as needed.