Cartesi Deterministic Game Engine

Submit a proposal
1

Cartesi Deterministic Game Engine

Project Description

The aim of the project is to bring one of the well established open source game engines to work with cartesi, which would help developers build next gen blockchain AAA games.

Problem

Current game engines are built to work in a traditional client server mode, which possess several challenges:

  1. Game engine dependencies and build targets are not optimally structured to create a build that works on Cartesi VM.
  2. Game engines are non-deterministic, where code running on different operating systems/different machines, wouldn’t produce identical results (figure 1), which would break the aim for creating deterministic results for a trustless web3 game running on cartesi machine (ex. we need to get the same results running the game on a client operating system using windows and running the same game on Cartesi VM).

1600×795 354 KB

Figure 1 - bullet float results between windows and linux comparison

Value proposition

Having a Cartesi compatible and deterministic game engine would aid in developing many AAA games and onboarding experienced game developers with minimum blockchain experience by providing game engine that they are used to in their web2 video games development.

How you will use Cartesi, specifically?

Demo using an Open source game engine would be provided, such that the demo would be working on Cartesi VM, as well as on other operating systems. Output from the demo running on Cartesi VM would be identical to the output from the client run.

Milestones

Milestone 1: R&D and POC (COMPLETED)

Target from R&D Phase:

  1. Determine pros and cons of using different game engines and determine the best engine to be used with Carteis.
  2. Determine the cause for non-deterministic outcomes and figure solutions that could be integrated with the game engine.
  3. Create a demo using a popular open source game engine that is open source, cross platform, and deterministic.

Duration: 4 months

Outcome:

Initially, unreal engine was heavily researched as it is open source and its code base is in c++. A sample game demo was developed using unreal engine and two builds of the game were executed on windows and linux. While unreal engine provides mode for making runs deterministic, it is only deterministic across builds targeted towards the same operating system. Runs on Linux and Windows failed to match which required extra investigation!

After extensive search and several code trials, it was found that the root cause for having non-deterministic results is floating-point arithmetic which game engines, specifically physics components, rely heavily on. A code sample, let’s name it AlphaTest, was developed to prove such discrepancy and a solution was searched to address this critical issue.

Two solutions had been found using fixed point arithmetic and softfloat. The code sample, AlphaTest, was first built using the GCC compiler option for using softfloat, though it failed to work (this option had limited support). Changing AlphaTest to work with fixed point arithmetic resolved the issue and produced deterministic results.

Next unreal engine code needed to be built on windows and linux machines as well as heavily investigated to determine the best approach for changing the code to use fixed point.

After successfully building unreal engine and editor on linux and windows, and going through the code base, it was deduced that it would be very challenging to continue with this approach due to the complexity of the code base, legacy code, dependency list and most importantly the demanding resources for building and running unreal engine and editor from the code base.

A search for alternatives started, which would still have a proven track record for creating AAA games and open source, with c++ code base, but lightweight.

Ogre was found to be the best option, coupled with Bullet physics engine. Tests started, and a demo was created running on both windows and linux, comparing results, which were non-deterministic. Source code was investigated and changes to bullet engine were made to use fixed point arithmetic. After 4 weeks, a version of bullet engine using fixed point was put to work, and a demo running on both linux and windows produced identical results. Major problem still existed where performance was a major bottleneck due to fixed point arithmetic. Softfloat had to be revisited again, and another approach was tried using a 3rd party softfloat library, and AlphaTest was visited again, this time using the softfloat library, and results on windows and linux were deterministic this time.

Bullet engine was adjusted to use softfloat instead of fixed point, producing close results to float numbers (figure 4), and performance was now suitable for usage (figure 2) and demo running on windows and linux is deterministic (figure 3.1 and 3.2).

This concludes milestone 1 with the creation of a deterministic POC demo that uses a popular open source game engine, ogre and bullet (figure 5), and providing code for the adjusted bullet physics engine and the demo.

Figure 2 - bullet softfloat demo

1600×861 199 KB

Figure 3.1 - bullet softfloat results between windows and linux comparison

1600×752 328 KB

Figure 3.2 - bullet softfloat results between windows and linux comparison

1600×748 466 KB

Figure 4 - Comparison between softfloat and float (close results)

Figure 5 - Ogre/bullet softfloat physics demo

Deliverables:

Softfloat implementation of bullet engine:

Demo using ogre and bullet:

References:

Ogre repo:

GitHub - OGRECave/ogre-next: aka ogre v2 - scene-oriented, flexible 3D C++ engine

Bullet Repo:

GitHub - bulletphysics/bullet3: Bullet Physics SDK: real-time collision detection and multi-physics simulation for VR, games, visual effects, robotics, machine learning etc.

Softfloat library:

STandalone REproducible FLOating-Point library (brodu.net)

Milestone 2: Cartesi VM Integration

Demo created in M1 would be deployed to Cartesi VM. Complete source code and documentation would be available for the community to use and build upon.

Duration: 1 Month

Deliverables:

Complete source code for the demo deployed on Cartesi VM with documentation.

Total Funds request (USD) : $20,000 USD

About your Team

Karim, current blockchain enthusiast and evangelist, has over 20 years of experience in driving Innovation and Technology. Having attained his Master’s Degree in Technology from University of Advancing Technology, Arizona, USA, in 2006, Karim have strived to deliver cutting edge Technologies throughout his career, having worked for IBM for over 2 years, in addition to leading, inspiring and taking initiatives to deliver innovative technologies to a multitude of multinationals for over two decades. Previous work include developing a programming language and compiler for Blu-ray authoring system, sdk, advanced features and mini games for Blu-ray, developed for some of the biggest studios in the world.

Linkedin:

https://www.linkedin.com/in/ktimam/

ERC-20 Payee address

0xcb25fc71dc83a45b37dddf5e81d9a2494ef99cb1

2

Hi Karim, Thanks for the proposal. I can tell you put a lot of thought and care into showing that you’re well on your way to building something meaningful.

We’ll need a few of our technical voices to chime in still, but let me provide my remarks as they pertain to adherence to the CGP guiding principles of lean development.

  1. It’s great that you’ve provided a working demo! However, we’re unable to fund your previously completed work via the CGP fund. Additionally, can you please specify whether your POC actually implements any of Cartesi’s technology (beyond your R&D exploration).

  2. What I would advise, is for an initial grant proposal, is to focus on milestone 2 only, and to follow the template that we’ve provided that explains how the POC of the integration is actually validating a hypothesis that you espouse in the proposal, as it pertains to the broader “vision” (which might be your milestone 3 from your current proposal).

  3. Suposing that a more focused proposal is delivered, subsequently funded, and satisfactorily completed, your milestones 3 and 4 could serve as the basis for a larger second grant proposal.

3

Thanks joe for your feedback. Taking your remarks into consideration, fund request is removed from milestone 1, and milestones 2 and 3 are adjusted accordingly. Milestone 2 would have accomplished a great feat by having a fully compatible and deterministic game engine running on Cartesi with basic demo. Milestone 3 would further extend onto that by creating a more sophisticated demo using the game engine from milestone 2.

4

Many of our technical voices are out of office for break in the last few weeks, and we’ll expect them to chime in soon.

May I ask though, why milestone 2 was changed from $5,000 to $20,000 but the scope did not change?

5

Overall cost was redistributed on later milestones based on earlier feedback.

6

Hello @Kiko, thanks for your proposal.

Super interesting stuff that you did with Unreal. However, I’m a bit confused about interactions of this with Cartesi. Everything that runs in the Cartesi Machine is already deterministic because of the way the VM was built (taking care of fixed point arithmetics and etc like you did for the game engine). So it looks a bit redundant to me, first creating a determinstic game engine and then porting that to Cartesi - while any gaming engine ported to Cartesi would be, automatically, deterministic.

7

Thanks Felipe. Results wouldn’t be deterministic with runs from other operating systems/devices with floating points in place (figure 1). For example, a run on cartesi wouldn’t be identical to a run on windows, hence two players playing on windows then submitting play data to cartesi for arbitration wouldn’t get the same result from their windows runs!

8

Hi @Kiko, along the lines of the concerns from Joe and Felipe, I would prefer if you focused on a minimalistic game demo running on Cartesi Rollups. Perhaps deploying soccer is a bit ambitious for the first grant.

As @felipeargento mentioned, there are design questions around your proposal, although I understand your motivation to have a deterministic code that can run outside the Cartesi Machine.

I see value if you can have a minimal Cartesi Rollups game running on your game engine, especially if you can shed light on possible kinds of games and provide a well-documented reference for future game developers.

There are interesting questions to be explored and answered along such a project. For example, what things should game developers consider, e.g. blockchain data costs and throughput limits, gameplay latencies, the likely restriction to turn-based games, VM computational limits etc.

9

Running games within a localized rollup environment was visited by myself, with consideration to use optimism and mud. Code is not documented though, and after a couple of weeks I abandoned this approach due to various complexities and as it wouldn’t be feasible for mobile and low powered devices.

As for the simulator here’s a snap for a simple demo I made on unreal engine (nothing fancy though):
soccer_unreal

That being said, the soccer simulator demo part could be excluded from the proposition without affecting the overall value for the end product.

10

Hello Kiko,

Firstly, I want to acknowledge the substantial effort and dedication evident in your proposal. Constructing a deterministic game engine like this is undoubtedly impressive.

However, I have some concerns about the value of integrating this game engine with Cartesi Rollups.

@erick.demoura has raised several valid points about the challenges, and I echo his sentiments. There are numerous impediments and challenges in this endeavor. AAA games are complex entities with extensive requirements in terms of computation, storage, and real-time interactions. Introducing a blockchain layer, regardless of its compatibility, may introduce latencies and complications that could detract from the gaming experience.

I would be keen to understand more about the specific use cases you envision for this integration. Are there particular genres or types of games that might benefit uniquely from this setup? Could there be a more niche application within the gaming sphere that this project could cater to, rather than attempting to port full-blown AAA games?

From a fiscal perspective, this initiative represents a significant investment for a product that might serve very specific use cases. Furthermore, one of the appealing aspects of Cartesi Rollups is the compatibility with standard game engines. This raises a question: is there a real need to create or port new game engines for it?

Again, congratulations and extremely impressive stuff that you’ve built. I’m just questioning how much of a priority would it be, for the Cartesi Ecosystem, to spend significant money on this - but I guess that’s up for the community to judge :slight_smile:

11

Hey there Felipe. I think you might be confusing AAA games with specific genres like FPSs, which wouldn’t be perfectly fit to host as server on cartesi in it’s current state. Despite that, there are many other genres that caters for millions of players worldwide, which would be perfectly fit to build on cartesi vm, like strategy, simulation/management, sandbox (with ai agents) and more.
As for current game engines being compatible with cartesi out of the box, it would be great indeed. If there is a way to deploy a headless Linux build from any of the current popular game engines as a server to cartesi, please let me know the steps to do that.

12

Edit: milestones 3 and 4 removed from proposal to focus on the core value for the purpose of this proposition.