Towards a Game Architecture Using Unity and State Channels
Blockchain the Omnipresent
As innovations go, the latest essential addition to the arsenal of digital tools is without a doubt Blockchain . But despite being the new Bluetooth that every application today needs, there are still hurdles to overcome before wider usage can be adopted. One of the main problems is that data transfer (e.g. transactions) to and from the chains are currently not fast enough even for web applications such as marketplaces. Not to mention the next step we would like to apply Blockchain technology to — real-time systems like games. For a nice overview of why this would be useful in the first place have a look at this article.
How to scale Blockchain to support fast pace applications?
One solution is using state channels. Regardless of which Blockchain technology is used or whether the games support state channels or not, to cope with the complex game design and high performance requirements a strong architecture is needed.to attract and maintain a large online player base and provide them a wholesome experience, one of the requirements is strong game architecture. The technologies for this are rapidly changing with one of the main points of relevance being the constantly developed new Blockchain solutions.
With that in mind, it would be convenient to be able to exchange the Blockchain components of our game without problems. Additionally, having the game mechanics detached from the game engine, used to present the game, would enable parts of the game to be completely moved onto Blockchain. Furthermore, separating the presentational parts of a game from the logic makes it possible to build different front-ends onto the same game basis.
A look at the architecture
I would like to present a proposal for such an architecture. In hopes that it sparks an interesting and constructive discussion, as an example for games developed in Unity with connection to Blockchain technology, consider this:
Here we have taken a classic three layer architecture (network/data, logic, presentation) and mixed it with a Model-View-ViewModel approach. Explaining from the bottom up: We start with a Network Layer, which establishes connections between clients, servers, and communicates with the Blockchain. Next it provides all the data to a Logic Layer (or Model for the Model-View-ViewModel).
All the game logic is calculated and game states are processed in the Logic layer that then generates commands to the Network Layer for updating and receiving updates from other clients, the server, or the Blockchain. Furthermore, it receives commands handed down from the UI to change the game state according to player inputs. When the changes are processed, it hands a new game state back up to the ViewModel.
The ViewModel simplifies the complex game state to something that is easily usable by the View components connected to the ViewModel. We propose to turn each View component into a Model View Controller (MVC) architecture for better detachability and exchange of game parts. For example, the UI overlay can be swapped out without needing to touch any of the components present in a scene.
As a member of a team using Unity for an upcoming game, I can attest that the above-described architecture works well with the engine. However, the best part is that the Unity specific sections of the game can be kept to the upper View and ViewModel layers. At the “lower” levels one can use the full potential of C# without being hindered by the life cycle or scene loading problems introduced by Unity, therefore making the underlying state of the components more manageable. Furthermore, using this setup, there is more control over the Blockchain technologies and implementations we include, as compared to using only the Loom SDK connecting Ethereum to a Unity game.
On the other hand, a drawback of this architecture is that it isn’t possible to use the matchmaking and client-server connections with synchronization delivered by Unity. This means that, game states need to be passed back and forth between clients and servers manually. Furthermore, algorithms on how to choose opponents need to be implemented on a server, instead of being able to use the server infrastructure Unity provides.
The schematic above is the first proposal of team Calystral in this development direction. We are constantly reworking our architecture to adapt to the many requirements of modern games. Join in the discussion and see how far we can push a general game architecture for Unity games with Blockchain connection.
Who are we?
Our vision at Calystral is to unleash the potential of gamers. We are focusing on enhancing the players’ experience and empowering the contemporary gamer. In the process we strive to overcome technical limitations of Blockchain and share the solutions with the community and other developers. Towards a better future of Gaming!
________________________________________
Join our journey creating a new world of gaming:
• Discord
• Telegram
• Medium
