In 2021, inspired by the success of Dark Forest, the Lattice team set out to create a new fully onchain game (FOCG) called zkDungeon. They planned to leverage the existing stack built for DF but quickly found they were spending the majority of their time updating the network stack rather than focusing on game design. This unwieldy process led the team to create MUD, a framework designed to abstract away the complexities of onchain state management and client synchronization for EVM games. Elsewhere in the cryptosphere, another team was building a FOCG called Roll Your Own. Inspired by the work Lattice had done with MUD, they sought to offer similar tools and abstractions to game developers on Starknet. In the spirit of open source, they applied the design principles of MUD into a new engine. Thus, Dojo was born. 

Over recent months we’ve seen growing interest in the FOCGs and autonomous worlds (AWs) space. As gaming investors, we’ve observed throughout history that breakout successes don’t occur until a game fully leans into the unique affordance of a new medium. Think how Farmville ignited the social gaming category through its deep integration with Facebook’s social network, or how Angry Birds leaned into the touch-based interface of smart phones. We believe that the blockchain as a decentralized computing platform is no different. We made our first investment in the FOCG space - Playmint - in 2022, and have since spent a lot of time exploring this niche. One of the best ways to understand new technologies is to get down in the trenches and actually build something. To this end, as the technical analyst at BITKRAFT, I’ve spent the last few months building a fully onchain game called Ascension, first using MUD, then again using Dojo. 

The goal of this report is to offer an overview of these engines/frameworks, highlight their differences and similarities, and share an account of my journey through both realms as a developer. It is my hope that founders and developers interested in exploring this fascinating space will find value in the following words and be inspired to dive deeper.

Introducing Ascension

Ascension is inspired by Tank Turn Tactics from Australian game developer Halfbrick Studios. At its core, Ascension is a simple PvP game, where players spawn on a grid with an initial amount of health points, action points and range. Action points can be claimed at set intervals (current demo set to 30 seconds) and are required to move, attack and boost range. Players can also choose to donate an action point to another player instead of using it themselves. The objective of the game is to eliminate all other competitors, however defeated players have the power to assign extra action points to live players.

Victory in Ascension is decided by how well one can manipulate other players. The real gameplay happens away from the board. Pacts can be made between players to pool action points and launch deadly strikes against others, but as this game only has one winner, at some point all pacts must be broken. Players also need to think carefully about how and when they choose to betray others, as creating too many enemies will result in a player’s living rivals receiving disproportionate action points from fallen players. 

I chose to make this game firstly because it has a simple set of rules that can easily be represented in smart contracts, and secondly because it’s well suited to stake-to-play mechanics. Although not yet implemented, the goal is to enhance the game experience by requiring players to commit a certain number of tokens in order to play, with the winner taking all. Furthermore, due to the composable nature of FOCGs one could extend Ascension in a number of ways, e.g. with prediction markets or action point marketplaces. 

Clients: Ascension (MUD) | Ascension (Dojo)
Github Repos: Ascension (MUD) | Ascension (Dojo)

Pillars of Creation

The upcoming sections will explore the key building blocks of MUD and Dojo. We will delve into following areas:

• ECS
• World State
• World Contract, Namespaces and Access Control
• Indexers
• Client support
• Toolchain and Infrastructure

ECS

Entity Component System (ECS) is an architectural design pattern commonly used in game development to structure logic and state in a modular and clear-cut way. In ECS an Entity is basically a database key identifying a game object, be it a player, an enemy, a consumable, a rock etc. A Component stores game state for an entity, e.g., the number of health points a player has, and can be likened to a database table. Systems are stateless smart contracts containing logic that can be executed to mutate a component’s state for a specific entity. For example, consuming a health potion may increment the health points component for a specific player entity. 

It’s useful to think of MUD and Dojo in terms of ECS, since there’s a clean separation of state and logic. Yet, due to the computational overhead associated with lots of individual component lookups on a blockchain, both engines have evolved from strict ECS principles, which advocate for breaking down models into minimal components. They now favor grouping related data fields to optimize performance.

Maintaining a clean break between state and logic fosters modularity, composability and reusability. For instance, if I choose to introduce NPC entities in future iterations of the game, I can just use the same health point and range components as real players. 

Modularity also aids upgradability and maintainability. Many of today’s smart contracts are monolithic, in that they contain all of an application’s logic and state. When structured this way, upgrading or introducing new logic typically involves the laborious and expensive task of deploying a new contract then migrating state over from the old contract. Conversely, updating logic that’s part of an ECS design only requires redeployment of the relevant systems contract, leaving all state and other logic untouched. 

It’s worth noting that although ECS is the recommended way to use both MUD and Dojo, it doesn’t have to be. In ECS the entity ID acts as a single primary key to attach component data. As both engines now support composite keys (keys constructed from multiple columns) in their data models they’re actually compatible with any relational database structures, considerably expanding the design space.

World State

FOCGs and AWs are data-hungry applications. They have to be able to store a lot of game state onchain and their clients need be able to query and respond to complex state changes with minimal latency. Solidity’s native compiler-driven storage engine was never designed for such a load and is not performant enough to service these requirements. Therefore, the MUD team developed a gas-efficient onchain database called Store. Store is similar in concept to an embedded database like SQLite and is created automatically when deploying the world contract. It is responsible for centrally storing and serving the world's state in a standardized way that removes the need for storage arrays and mappings at the individual contract level. 

Another pain point addressed by Store is the idiosyncratic nature of contract events emitted from Solidity contracts. Sure, developers are still free to create custom events if they wish, but any time a storage update occurs, Store automatically emits a standardized event which can be picked up by the client or an indexer. At first this might sound inconsequential, however it allowed the MUD team to develop a generalized network layer that abstracts away much of the complexity involved in keeping a game client in sync with onchain state. This standardization also makes MUD worlds highly composable, as an indexer can now be pointed at any world contract.

All this is abstracted away from the developer. When tables are defined in the config file, a library of getter() and setter() functions that handle all data encoding and decoding are generated automatically. It’s possible to hack at a lower level to introduce bespoke storage behaviors, but for 99% of use cases these libraries will work fine. Figure 3 demonstrates how a health point would be deducted from an enemy player during an attack.

Store is more gas-efficient than Solidity's standard storage engine, as it removes unnecessary padding around stored data to achieve tight bitpacking. It also allows new tables with new schemas to be added at runtime, a feature essential for composable and extensible worlds. For more detail see the MUD docs.

Dojo also maintains an onchain database similar to Store, however unlike MUD, not much of its inner workings are exposed in the docs, and there are no auto generated library functions easily viewable in your project. However this is not an issue as Dojo exposes a number of abstractions called macros to simplify common operations like retrieving and updating models, and generating unique IDs. The following example from Ascension shows how player attributes are set using both MUD (left) and Dojo (right).

Behind the scenes, both code snippets are adding new records to 11 different components and in the process emitting a bunch of standardized storage events, which can be picked up by any client or indexer instance, effectively allowing multiple clients to exist for a single game. This is the reason why FOCG are sometimes referred to as ‘headless games’. 

Building the Ship’s Log in Ascension:

Although storage events are emitted automatically, I needed something more bespoke for Ascension. I wanted a way for players to look back and see exactly what moves all other players had made since the start of the game. This required emitting a single event for each type of action that contained timestamps, usernames and actions taken. I found the experience of creating custom events in MUD and Dojo quite different. 

MUD events are defined as ‘offchain tables’, and they behave much like regular component tables except they are not stored onchain. They can be queried from the client and decoded using the recs library like you would query any other table. In Dojo, custom events are defined within your systems as structs labeled with the starknet::Event attribute. Once emitted they are picked up automatically by the Torii indexer, but to get them to display in the client was challenging and required some support from the wizards in the discord server. The solution involved executing graphql queries to retrieve raw event data, manually defining contract components describing the events composition, and then decoding them with custom parsing logic. That being said, I believe the Dojo team is planning to make this way easier by streaming these events over gRPC, allowing them to be queried and decoded like any other component. 

World Contract, Namespaces and Access Control

Within the onchain ECS paradigm, the “World” is a smart contract that acts like a container for all the world's components and systems. It’s also the entry-point for all function calls attempting to access the world's state, which makes it a great place to establish access controls. The world contract is mostly abstracted away from the developer - for both engines, other than assigning access controls to Ascension’s systems, I didn’t have to interact with the world much. However, it’s useful to understand how this fits into the wider system, as in more advanced projects it is key to enabling extensibility and composibility. 

Both MUD and Dojo allow developers to set granular permissions on the world contract that determine what systems are allowed to mutate specific components. 

Access control in MUD worlds hinges on the concept of namespaces. Consider a MUD world like a tree: at its base is the root namespace (as shown in Fig. 5 under 'basegame'), where the world's immutable laws, or 'digital physics,' are set. Within this world, anyone can freely create their own namespace (see 'extension' in Fig. 5), which can be likened to a branch of the main trunk. Each namespace has an owning address(s), which acts as an administrator and has the right to add new tables and systems among other things.

Within a namespace systems can freely interact with each other. By default, they have the ability to call into any other system within the same namespace and can modify (read/write) all tables. Systems can be either public or private. Public systems are open for all, meaning they can be accessed by any account or contract/system (internal or external) without restrictions. Private systems, on the other hand, are more exclusive and only accessible to accounts or systems/contracts with specific permissions, which can be granted at either the namespace or system level. It's important to note that granting access rights to an account, system, or resource at the namespace level includes significant power: the ability to withdraw any ETH held by that namespace. 

Ascension’s MUD version housed all systems and components within the root namespace. However, in theory someone could create their own namespace in the Ascension world and build functionality around the components and systems, an Action Point marketplace for example. 

To drive the point home, let's use an example of a player moving in Ascension to illustrate the control flow in a simple MUD world:

1. Bob initiates a move action from (0,0) to (0,1). The request first hits Ascension’s world contract
2. The world contract authorizes the request and forwards it onto the move() function in Ascension’s MapSystem 
3. The move() function attempts to call the Position component’s set() function, passing in the (0,1) coordinates, along with Bob’s entity key. This function call is routed back through the world contract, which checks that the MapSystem has write permissions for the Position table. If authorized, the component state for Bob’s player entity is updated
4. Not implemented in Ascension, but systems may call into other systems in different namespaces, i.e., systems owned by a 3rd party can call into the base world systems and vice versa

Dojo’s control flow operates in much the same way, albeit with a few differences. In Dojo there is no concept of a namespace to broadly define access controls. Upon deployment, systems have no authorization to write to any models. Instead, the model's owner must explicitly grant access to each system that wants to mutate it. When first starting with Dojo, this tripped me up a few times, however this manual step does make permissioning more intentional, decreasing the likelihood of accidental authorizations occuring. Moreover, the team chose to implement this lower-level access control to facilitate easier access control abstractions on top. Similarly to MUD, each function within a Dojo contract is a separate system, i.e. contracts can contain multiple systems. However, like MUD, access control is granted at the contract level, therefore developers should carefully consider isolating logic across multiple contracts depending on how granular the permissions need to be (see fig. 7 for a helpful decision tree). Finally, in contrast to MUD where system calls are proxied through the world contract, Dojo systems are invoked directly, as shown in fig. 6, facilitating composibilty with contracts outside the Dojo framework. Access control checks are instead performed by the world before any model mutation can occur. 

Indexers 

Even a relatively simple FOCG or AW can have a complex world state if there are lots of players interacting with it. Furthermore, if these games are to move beyond simple and slow turn-based experiences, this state needs to be available at very low latencies. Having thousands of clients performing complex multi-step read/write operations over RPC puts tremendous strain on any service and will quickly become cost prohibitive. 

Both Mud and Dojo offer an offchain indexer that listens for all state update events emitted from the world contract it is pointed at, stores them in a database, and exposes them for clients to query. Additionally by using composite keys, such as combining a components key with a unique game ID key (as done in Ascension), developers can segment state, enabling the client to only pull data relevant to the player. This allows multiple separate game sessions to run simultaneously without the long loading times caused by state bloat. As mentioned earlier, using a standard framework for representing state means game developers spend less time writing boilerplate code, as the indexer or core client code will automatically pick up on any new types of state defined in the contracts. This is why this type of solution is sometimes referred to as automatic indexing. 

Dojo’s Torii indexer is split into two components. 

• A server side component comprising a Rust backend that listens for events, loads them in and exposes graphql and gRPC endpoints
• A client side component that provides an API for your client to call

Interestingly, due to the fact that the canonical base Torii client is written in Rust, it’s relatively straightforward to generate reactive bindings in other languages, effectively making Dojo client agnostic. The recently announced Dojo Unity SDK was achieved by generating C bindings and wrapping them in an engine specific API. Furthermore, having a canonical Rust client means less maintenance overhead across multiple clients, as updates can be made once and the bindings regenerated, without the need to manually update each separate client’s codebase. This is something the MUD team is also investigating but have not yet implemented. One point worth mentioning is that due to the similarities between the MUD and Dojo onchain storage engines, it’s theoretically possible for MUD worlds to be indexed by Torii, allowing them to also benefit from the aforementioned client agnosticism. 

The Torii indexer can be stood up with a single command and was a core part of my developer workflow from the very start. Conversely, when onboarding into MUD there was not as much emphasis on using an indexer for the simple tutorial projects I started with. Ultimately, I never got round to setting an indexer up for Ascension’s MUD build, and the process is a bit more involved than setting up a Torii instance, see the mud docs. When the BITKRAFT team playtested the (MUD) Ascension game with 6 players and short turn times, multiple players were stockpiling action points then firing off quick bursts of actions. For some players this resulted in buttons becoming unresponsive. I will spend time diagnosing the root cause of this, but I suspect this can be attributed to sync issues between the client and onchain state.

Client support

This leads us nicely onto the topic of client support. Some of Dojo's client libraries began life as forks from the Lattice versions. Over time, however, they have evolved to be quite different. That being said, Dojo still leverage’s MUD’s recs library, which helped translate Ascension’s MUD client over to Dojo. Both the MUD and Dojo versions of Ascension were built using React.  

Here is a summary of the clients supported by each engine at the time of writing. 

Toolchain & Infrastructure

Both MUD and Dojo bring together a series of infrastructure components in order to provide a full stack for onchain game developers. MUD leverages the existing Foundry toolchain built by Paradigm, which includes local development and testing nodes, frameworks and CLI tools for building Ethereum applications. As mentioned earlier they also have an automatic offchain indexer. Recently Lattice also announced Redstone, a plasma-implementation of the OP Stack. Although not strictly part of the MUD engine framework, Redstone is specifically designed with onchain games and worlds in mind. MUD will likely have deep integrations with Redstone in the future, providing an enhanced user experience when used together. However, the team are cognisant of balancing this with maintaining both MUD’s and Redstone’s compatibility with the wider EVM ecosystem. Diving into the details of Redstone is beyond the scope of this piece but we’d recommend reading the docs, as well as listening to this Space with Lattice CEO Ludens.

The Dojo toolchain is built in-house and consists of the Katana sequencer, the Torii indexer, and the Sozo command line interface tool for world building, deployment and maintenance. Katana is a centralized sequencer that runs at speeds comparable to traditional game servers, whilst Torii offers both graphql and performant gRPC endpoints. Slot, a managed infrastructure product from Cartridge, makes it super easy to spin up Katana and Torii instances, so developers can share builds quickly for playtesting or deploy straight to production. 

It’s not the case that one of these stacks is better than the other, they service different ecosystems. Both toolchains are built using Rust to be performant, but Foundry is a general purpose toolchain for developing Ethereum applications and has been in production for a while now. Because of this it has a large community of open source contributors and has had a lot of battle-testing. On the other hand, the Dojo toolchain is built in-house to be domain specific and deeply integrated with the Dojo engine, resulting in a streamlined experience for game devs. Foundry also offers a Starknet toolchain, which will soon be supported by Dojo. 

Side Quests

The previous section addressed the core engine components of MUD and Dojo. This next section briefly touches on a number of elements that add to the experience of building and playing games onchain. 

Optimistic multiplayer updates

Optimistic updates refers to the ability for the client to allow each player’s action to be ‘optimistically’ rendered on screen before it has been confirmed onchain. Optimistic multiplayer updates take this one step further and enable the client to optimistically render everyone else's actions in a multiplayer session before being confirmed onchain. This functionality was first implemented onchain by the Playmint team as part of the custom infrastructure stack they built for Downstream. Check out this tweet from Playmint’s CEO, David Amor to see this in action. 

Dojo currently supports optimistic multiplayer updates because the state events emitted from the Katana sequencer are picked up by the Torii indexer in a pending state. This allows them to be rendered client-side before being fully confirmed onchain. Any reverted transactions will also be picked up by the indexer and the resulting state change reflected in the client. In future, Dojo plans to support natively running the Cairo VM in the browser to further reduce latency.

At time of writing MUD supports optimistic rendering within a single client but not optimistic multiplayer rendering. However, the engineering team are working on Redstone features that will provide a very similar user experience to optimistic updates across many users, but with a different approach. 

Client-side proof support

One way to scale FOCGs and AWs is to move computation to cheaper execution environments. This could take the form of an L2 like Arbitrum, Starknet or the Immutable zkEVM, a game-specific L3 like Xai, or an ephemeral rollup that temporarily forks the state of the chain. Another way is to move the execution onto the client device where compute is abundant, and use validity proofs (a.k.a. zero knowledge proofs) to prove that game logic was executed correctly. 

Because it’s possible to run the CairoVM natively and prove the resultant execution trace, Dojo applications can benefit from client-side proving, something which is key to Dojo’s scalability roadmap. EVM programs are provable if deployed on a zkEVM, albeit in a less-performant way than Cairo. However, as Solidity is not a provable language, it cannot support client-side proofs without the use of an additional stack (like Circom), as this allows custom circuits to be written to prove execution with a Solidity verifier (again, initially experimented with by engineers at Playmint). 

Client-side proving also has the added benefit of enabling hidden player information. All  execution occurs client-side, with only a state diff and zero-knowledge proof submitted onchain. This mechanism can hide a whole sequence of moves that lead to a specific outcome, whilst still maintaining assurances that the player acted in accordance with the game’s smart contracts.

Hidden Information

Information asymmetry is a key component for many game designs. Age of Empires without fog of war wouldn’t be much fun, and being able to see everyone else's hands in a game of Poker would break the game. However running games on a transparent public blockchain where anyone can check the state makes achieving this hard. As mentioned above, client-side proofs can enable the kind of hidden player information required for Poker. There are also examples of developers using mechanisms like commit-reveal schemes to achieve hidden information in games. However the holy grail of hidden information is having a shared hidden state onchain, i.e., information that no one knows, and companies like Inco are working on building a fully homomorphic EVM, where computations can run over encrypted data. Neither MUD or Dojo natively support hidden information, as this is not a feature of Solidity or Cairo, but this functionality can be added by leveraging 3rd party libraries.

Hidden information is a budding area of research within the FOCG/AW space and is beyond the scope of this report. However, for those wishing to get a good primer on the subject we’d recommend the Eternal Playgrounds Wiki from Baz and Goblin over at Tonk.

Account Abstraction

Put simply, account abstraction turns a player's wallet into a programmable smart contract, unlocking features like account recovery, spending limits and session keys etc. For more info check out our developer tooling report. As Dojo has been designed and built from the ground up to support Starknet, it has native support for account abstraction. When first loading the Dojo version of Ascension, players will be required to deploy a smart contract burner account. The Ascension MUD game also creates a burner account for the player but this is not a smart contract account, as MUD doesn't yet support account abstraction. However MUD does support account delegation, which allows a player (delegator) to assign permission to a different address (delegatee) to call system functions on their behalf. This enables features like session wallets that abstract away transaction signing during gameplay.

Developer Experience

It's obvious but sometimes overlooked: for a new tool or infrastructure piece to become popular among developers, they need to like using it. This goes beyond the quality of the tool itself and encompasses the entire user experience including developer support, docs, tutorials, example projects and community engagement.

During the building of Ascension, both Discord servers were an invaluable resource for onboarding and troubleshooting problems. Thankfully, both the community and the core devs are happy to answer newbie questions, of which I had many. Both servers have dedicated support channels, where you can post queries that require a longer thread. This is not only great for helping developers onboard and overcome tricky problems, it also helps the respective teams to identify holes in their documentation or spot common feature requests from their community. Over time this also builds up a useful archive of questions and answers, which I made a habit of searching through daily. In the spirit of open-source, both projects have public core dev chats, offering a transparent view into their pipeline.

One of the best ways to onboard new developers is to provide a hands-on tutorial that covers the stack end-to-end. I really liked the fact that MUD’s Emojimon tutorial walked through the client code in addition to the onchain aspects, as this part can often be the most complex. That being said, in both cases, there are a myriad of example projects which were extremely useful to use as starting points or for figuring out how to do something that was perhaps unclear in the docs. Furthermore, both frameworks come with a CLI tool (similar to create react app) to initialize a new end-to-end project, using a template. As a new developer to both ecosystems I found these a great onboarding tool, as I was able to get a basic but functional end-to-end dapp running without any modifications.

These engines are still in early development and have not yet reached stable versions. Frequent updates to the underlying packages sometimes introduced new ways of working and breaking changes which made development challenging. Furthermore, due to the rapid iteration and the leanness of the core teams, the docs occasionally drifted out of sync, which could be rather confusing. However, both teams published version migration guides when required. The Lattice team, in particular, has been really consistent with this. 

The last thing I wanted to touch on is quality of life improvements for developers. There's a lot I could mention, but I'll just focus on one point for now. The development process in MUD felt more streamlined. Perhaps this is to be expected considering it’s been under development for longer than Dojo. I was able to fire up a newly initialized project with a single command that takes care of everything: installing dependencies, launching an Anvil instance, deploying contracts, and starting the client. One feature I really appreciated was the development servers that watch both the client and contract packages. Upon detecting any changes, they automatically recompiled my code, and for the contract package redeployed new contracts to the Anvil node. This might sound inconsequential but it meant I had less context switching between my code and the command line.

Closing Thoughts

By abstracting away the complexity of building FOCGs and AWs, engines like MUD and Dojo are progressively lowering the barrier to entry. This allows developers to experiment with non-skeuomorphic game design ideas that this new medium has the potential to unlock. Despite being in early development, both engines have enabled the creation of many more onchain experiences (see this MUD projects reel and this Dojo game jam summary). Other than contracts being implemented in different languages, the two engines are very similar in terms of design. This is not surprising considering the fact that the Dojo team has been influenced by Lattice’s work over the past few years. Furthermore, the open source nature of both projects and the similarities in design, particularly on the client side, could lead to a convergence of ideas over time, as contributors build adapters that blur the boundaries between infrastructure components. 

The fundamental distinctions between these engines stem from the core infrastructure primitives they leverage. MUD is EVM-centric and can run on any EVM-compatible chain. Dojo is designed for a non-EVM, zero-knowledge (zk) framework, however the slot instances that run Dojo applications can settle down to Starknet or any EVM-compatible chain.  

Due to the maturity of Optimism’s code base, Lattice has opted to build Redstone with the OP Stack. Currently that means Redstone will settle optimistically to Ethereum, but this could change in the future. That being said, the optimistic approach can be cheaper, as proofs only need to be generated if someone wants to challenge the outcome of a state transition. However, this depends on there being enough economically incentivised stakeholders who are willing to incur the cost of challenging an outcome. For this reason, optimistic approaches typically have higher data availability requirements, as validators may need to re-execute all the transactions in a batch to validate or falsify the challenge. As data storage is responsible for the majority of settlement costs, the savings provided by the lack of having to prove every transaction are somewhat offset by DA requirements. That being said, Redstone reduces the cost of DA by posting input commitments to L1 and using a 3rd party DA provider (see docs).

Dojo’s zk approach, enabled through Cairo’s provability and Starknet’s fractal scaling, has the potential to enable massive horizontal scaling. An abundance of computation can be created by sharding execution across many independent contexts, whose respective proofs can be aggregated and verified on a base layer. The integrity of computation is mathematically proven rather than relying on incentivised honest actors watching the chain. This means in theory, the zk approach can work for narrow contexts with only a handful of users, e.g., a dungeon instance, whereas optimistic assumptions would break down. However, the current high costs associated with proving transactions makes this approach uneconomical for low stakes gameplay. That being said, prover technology is still early and there are multiple well-funded teams working on improving performance.

How can a Web2.5 game use an onchain game engine? 

In many cases, it might not make sense to completely migrate your existing game to being fully onchain, especially if the game logic is complex and the core mechanics are already functioning well. Of course this can be done but it would require substantial development work to rewrite the game’s logic in smart contracts. Furthermore, games designed to run on centralized servers may not work out of the box on a blockchain, where there’s no concept of the external passage of time for instance. Although the game's UI could remain unchanged, you’d also have to swap out much of the client-side networking code with the respective sync stacks of MUD or Dojo. 

A lower lift approach to leveraging MUD and Dojo might be to keep your existing Web2.5 game as is, but augment it with fully onchain experiences. This would involve first deploying a MUD/Dojo world contract and registering a new NFT collection in it that mirrors your existing collection, including attributes, traits and ownership. Once this is in place you could start by creating simple fully onchain mini games around this NFT collection. This could even be used for NFT PFP projects that do not have a game. For example, one could take the Neo Tokyo Citizens collection and create an autobattler based on their attributes like class, ability, weapon or vehicle etc. By doing this, not only do you create extra utility for your NFT collection, you have also created a low-level primitive (think Loot) that anyone can permissionlessly build experiences around - all of which has the potential to drive value back to holders.

Throughout the evolution of video games, whenever a new medium is introduced, be that  arcades, consoles, VR or mobile, we typically first see skeuomorphic approaches towards game development - bringing a game from an old medium to the new. It’s historically not been until a game fully leans into the unique affordance of a new medium that we really see a breakout success. FOCGs and AWs uniquely enable permissionless composability, interoperability and permanence within video games. With engines like MUD and Dojo accelerating developer adoption, we believe the groundwork is being laid that could lead to a golden age of modding and UGC. 

We hope you found value in this write up and if you’re building games onchain or have questions regarding the topics discussed please reach out. Also keep an eye out for a follow-up piece that will delve into the FOCG/AW space through an investor lens.

Special thanks to 5p0rt5BEArD, Loaf, Tarrence and Ludens for providing valuable feedback. Also shoutout to Loaf and Frolic and their respective communities for their enduring and patient developer support. 

Disclaimer: 

“Specific investments described herein do not represent all investment decisions made by Bitkraft. The reader should not assume that investment decisions identified and discussed were or will be profitable. Specific investment advice references provided herein are for illustrative purposes only and are not necessarily representative of investments that will be made in the future.”