BOLT Modular infrastructure, ECS full-chain game engine of Solana ecosystem

BOLT A Modular Infrastructure and Full-Chain ECS Game Engine for the Solana Ecosystem

Video link:

Speakers: Andrea, Gabriele, Co-founders of Magicblock


Translator’s preface: “BOLT is a full-chain gaming engine developed by the Magicblock team for the Solana ecosystem. This article is a compilation of the speech given by the two co-founders of Magicblock at the Breakpoint 2023 event.”

BOLT: Modular infrastructure, Solana ecosystem's ECS full-chain gaming engine

Hello everyone, this is the last speech before Halloween, and I hope the content of the speech will be interesting to you all. My name is Andrea, and beside me is my co-founder Gabriele. Today, we will introduce a new full-chain gaming framework (engine).

01. Why do we need full-chain gaming?

Let’s start with the basics: why go through the trouble of building a game entirely on the blockchain, putting both the state and logic on-chain, and dealing with all the complexity that comes with it? The reason is simple: to obtain features that traditional game infrastructures lack.

BOLT: Modular infrastructure, Solana ecosystem's ECS full-chain gaming engine

The first feature is permissionless modularity. This means that all players and developers can customize any component of the game, including introducing plugins or mods, right from the advanced client. Even the underlying logic of the game can be expanded through smart contracts. Essentially, this is a new paradigm where every game, by default, is a new platform, and no matter how small your team is, you can become a content powerhouse.

The second feature is persistence. The self-contained worlds and the ability for these virtual experiences to exist indefinitely have garnered tremendous interest. Since there are no servers that can be censored or shut down, these experiences introduce an entirely new meaning. Games become platforms for players to play, engage socially, and conduct global business, surpassing traditional gaming platforms in universality.

The final feature is open economies. Games can leverage the frictionless global payment system offered by blockchain, especially for microtransactions within our ecosystem, and reuse existing on-chain infrastructure such as DEX or NFT marketplaces.

02. Existing solutions

The current challenge with full-chain gaming is that the development experience is extremely poor. We have observed some solutions in the market attempting to simplify the developer experience.

BOLT: Modular infrastructure, Solana ecosystem's ECS full-chain gaming engine

Some of them are very interesting. They are trying to iterate on provable sessions, where you can compute off-chain and prove the completeness of the computation on-chain. Or introduce event-driven runtimes that are more suitable for blockchain game engines rather than loop-based runtimes.

But all these frameworks need to balance between performance and composability to achieve higher performance and TPS. Typically, you would achieve this by creating isolation or introducing different runtimes with sharding.

BOLT: Modular Infrastructure, Solana Ecosystem's ECS Full Chain Game Engine

But we are not satisfied with this trade-off. We ask ourselves, what if there is a framework that can support the TPS we need? Imagine a game with millions of players achieving success without sacrificing their user experience due to gas wars. And this framework does not require sharding, so you can have provable game sessions and even simulate the passage of time without paying gas fees. No need to fragment the system or use Layer 3.

03. BOLT: Full Chain Game Development Engine on Solana

BOLT: Modular Infrastructure, Solana Ecosystem's ECS Full Chain Game Engine

Therefore, we are excited to introduce BOLT, a high-performance and composable full chain game development framework based on SVM.

BOLT is modular and composable, and it can leverage all existing infrastructures on Solana. It works with our on-chain facilities like on-chain identity, gasless API, session key, as well as existing Anchor development framework and all existing programs on Solana. Both can achieve scalability at higher orders of magnitude, thanks to Ephemeral Rollup, which opens and closes game sessions (rollups) based on user demand and scales accordingly.

BOLT is lightning-fast, achieving the same level of performance as traditional game engines, and then using these dedicated runtimes to accelerate certain operations.

BOLT: Modular Infrastructure, Solana Ecosystem's ECS Full Chain Game Engine

This is an overview of the BOLT framework. It is clearly built for Solana, but it can be used on any SVM-compatible platform, such as SVM-compatible Layer 2. BOLT has two main goals: composability and scalability.

ECS (Entity Component System) is one of the methods we use to simplify on-chain component usage. Another one is Ephemeral Rollup, which I will delve into shortly.

BOLT has integrated with the most commonly used traditional game engines, such as Unity, which usually serve as the front end of the game. Of course, this also includes other open-source and well-loved game engines, such as Godot and Phaser. We are even collaborating with the updated game client, Turbo, which focuses on improving the experience of independent developers and facilitating fast game creation. There may be more future collaborations with other partners.

BOLT: Modular Infrastructure, Solana's ECS Full-Chain Game Engine

I will start from here and continue explaining why we need an ECS entity-component system. The answer is simple: it allows for maximum composability, meaning that we can create and reuse ready-made components.

As the name suggests, ECS is built upon three main elements: entities, which are essentially just identifiers registered to an independent game world (World Instance); components, which define the data structure and are essentially data associated with entities; and finally, systems, which are the logic that operates on the components attached to entities.

The advantage of this architecture is that all systems and components are reusable. They can be published in a public registry, where developers can easily contribute, build, discover, and integrate any type of component. This means you don’t have to start from scratch and can reuse all existing components and eventually contribute to them. For example, we can have a grid data structure, a movement system, or a zero-knowledge proof system for fog of war.

04.BOLT Engine ECS Programming in Action

Now, I will switch to my IDE and show you a simple game example using the BOLT ECS engine.

BOLT: Modular Infrastructure, Solana's ECS Full-Chain Game Engine

We will define several entities, a position component, and two systems that will operate on and modify the data of this position component. The first entry point is to interact with the World Program. The World Program is part of the BOLT framework and exposes some extractions that allow you to register new World Instances.

You can add entities to your World Instance and can register components to the entities you just defined, where components are essentially defined by component programs. Among the component program, there are two instructions, and the first instruction is initialization, creating and allocating space to store the row data to be used in your component. In this simple example, we are defining a position component, and if we look at the context of the initialization instruction, we can see that we have component data, and the component data simply defines a structure with XYZ coordinates that can store, for example, player position.

Now, the second instruction may be the most interesting; it is an entry point that allows us to execute any logic. It takes our component and any system as the input and executes the internal logic defined in the system across the programming location. Now, if you look at line 15, we have our CPI (Common Programming Interface) call, which executes the internally defined logic through the CPI. It performs all the computations defined in the system and then returns our position, which the component program retrieves and sets back into our data.

Now, let’s try to examine the context of our apply function, where we can see that we basically only have two accounts. The first one is the account that contains our component data, and the second one is the system program. Therefore, the system program is now an interface rather than a single program. As a result, any program that adheres to our BOLT system interface can be executed through this application.

05. The Significance of ECS System

Essentially, this changes the way you design game logic and disrupts the traditional process. Previously, if you wanted to create or encapsulate some logic in a program, you would typically add features, each of which was an instruction in the program, and eventually, at some point, you would lock in the game program you developed.

However, with the ECS pattern, we instead have an immutable program from the start, and through this proxy mechanism, we can add systems built internally or by anyone else, resulting in a game that can run forever, is scalable, and allows anyone to truly change the game logic.

They can deploy new systems that operate on those components. Now, interfaces can also allow you to perform some checks, so we can design a game mechanism that makes it unnecessary to get permission for adding new systems that can modify component data.

Alternatively, we can set up an interface to check if a system is allowed to operate on a component. For example, you can design a governance system where if someone proposes a new logic and it gets approved, all players can use that logic in the game.

This can even lead to forks in the game world (World contract). In one world, you have a flying system. In another world, if that system is not approved, there can be different rules, and everyone can still contribute to their respective version of the world.

Now let’s take a look at how to build a system that can modify this component. A system is essentially just a program on Solana that defines an instruction, and the execute instruction is the one we call from the component program in the CPI (Common Programming Interface). Here, he only encapsulates a very simple logic where he takes an input direction, calculates the increment, and then changes the X and Y positions of the component.

So, let’s now look at another system that could be deployed by someone else, even after we release the game. This is an example of a system that implements execute. Here, the Z position is increased by 1, so someone is trying to add a wing system, which could be an interface and have a different layer on top of your game.

So, the idea now is that all these systems, all these components are truly composable, and the users of the game are no longer just users; the game has become an open, scalable, and persistent platform. Therefore, I will try to run the unit tests I prepared in this example and will use BOLT CLI, which is built on Anchor (a Solana smart contract framework), so if you are already familiar with Solana, you don’t need to learn anything new.

Now, you can develop programs on Solana by simply developing and testing programs. So here, I’m running bolt build and bolt test, which deploys our program, and then executes the typescript tests I prepared here.

So, here we are testing sending transactions to initialize a new world. We are registering a few entities, attaching position components to some of them, and then the interesting part is executing some systems here. So, here we are calling the apply function and then we are using one of the systems. So, here is just a default system.

BOLT: Modular Infrastructure, Solana's ECS Blockchain Game Engine

Here, we are calling a simple movement and then we have a flying movement here. Well, now, if we look at the log of the test, in the first transaction, here we use a movement system with an upward direction and increase the Y position by 1. In the second transaction, we use the same system to move to the right, and finally, we execute a flying system that performs the opposite operation, increasing our Z position by 1. This is just a simple example, but it provides a very powerful mechanism that allows anyone to develop, expand, and possibly make your game interesting.

06. Ephemeral Rollup

BOLT: Modular Infrastructure, Solana's ECS Blockchain Game Engine

Now we’re going back to the slides, and I’ll describe the second interesting aspect of the BOLT framework, which is our scalability solution called Ephemeral Rollup.

People generally think that Solana is already very fast and cheap, generating a block every 400 milliseconds and capable of processing thousands of transactions, so it’s actually well-suited for building blockchain games. However, if you have an old logic chain for a multiplayer game, the position updates will be too slow.

Therefore, we can build a temporary acceleration layer that is fully compatible with Solana’s runtime. The timing used is optional and can serve as a real acceleration for specific operations, while most of the logic still executes on the main chain, so it relies on the feature of storing all state on accounts on Solana.

Typically, you would have a game program that defines the logic, and all the state would be stored in this account, so we can delegate some of these accounts to this temporary layer using the BOLT engine.

In this example, there are two authorized accounts storing player positions, and the provider is actively listening to delegation requests and deployment requests. He will start a new runtime as needed, which is fast and customizable, can have gasless transactions or a tick mechanism, allowing us to truly have transactions below 50 milliseconds, and possibly scale by having multiple specialized runtimes.

Now, another interesting part is that all this complexity can be abstracted away from the user. We have an RPC router, which is essentially similar to a traditional RPC router. RPC clients can interact directly with the RPC and send transactions. Because on Solana, all transactions pre-declare all mutable and readable accounts, the RPC router can basically route transactions, data queries, and retrievals to the correct layer.

At some point, the Ephemeral layer (as the name suggests) will be closed, and all states will be settled on the Solana base layer. This is the responsibility of the sorter, who will track all accounts.

BOLT: Modular infrastructure, Solana's ECS Full-chain Game Engine

Another way to look at this mechanism is that we have two layers that execute transactions in parallel. We have delegated accounts, which can update with lower latency without consuming main chain throughput. Then we have other accounts that are not delegated and are executed on the main chain.

Now, one very interesting thing is that the programs, tools, frameworks, and infrastructure are all on the main chain. You don’t need to deploy your program in Rollup, although it is common in many other architectures. Everything is on the same layer, everything is composable, and as mentioned, this specialized runtime can also scale and truly be customized.

BOLT: Modular infrastructure, Solana's ECS Full-chain Game Engine

Now, this unlocks a whole new category of games built on the blockchain and with low latency. It’s like using traditional multiplayer game servers, but still being able to combine with all available content in the Layer 1 ecosystem.

BOLT: Modular infrastructure, Solana's ECS Full-chain Game Engine

You can access existing liquidity, send messages through protocols, mint NFTs, use account abstraction, session keys, leaderboards, and a unified ecosystem where everyone enriches the same ecosystem.

BOLT: Modular infrastructure, Solana's ECS Full-chain Game Engine

Thank you very much for listening. You can register for early access to our framework using the QR code and please check out the repository. You can already find comprehensive documentation and a whitepaper that details the framework we just introduced. Thank you very much.