The future of the game engine
To read the original post, see here.
The dream of virtual worlds has been upon us for decades. Science fiction is obsessed with it; where will they take us? What will our interactions look like in them? Will we care about the things that happen within them? Will the virtual world replace the real world? While the promise of artificial intelligence is augmenting the way we think, virtual worlds promise a new landscape for the imagination to roam.
In living worlds, we will be able to connect with thousands of other adventurers, all exploring the same world with us; our actions will matter, the world won’t be scripted. But while we focus on the headsets and on the first games to come out, what, we wonder, will be the future of the technology used to build them? And what does the future of the game engine look like?
The game engine today
The current generation of games is pushing the boundaries of what’s possible with today’s technology, both in terms of art and gameplay. Game engines such as Unity and Unreal do a fantastic job of rendering game worlds for the player, yet they are also doing all the work under the hood to make the game itself happen — running physics, AI, pathfinding, and game logic.
For a single player game, the engine will be doing all this work on the player’s device. The concept of the game loop hasn’t changed much since its invention decades ago.
Multiplayer games aren’t very different. The game loop is split between client and server, with the client dealing with inputs and rendering, and the server performing the world simulation work.
But there is a limit to what can be achieved building games this way. You can only fit so much physics and AI on a single server, and this inevitably leads to compromises in terms of the size of the world, the number of players, or the complexity of the physics or the AI.
This, in turn, imposes limits on the creative vision. When game logic, physics and AI are already competing for a share of the available resources, there’s not much room left to experiment with truly innovative ideas.This is a problem we’ve been doing a lot of thinking about.
The Entity-Component-System pattern
Most games follow the Entity-Component-System (ECS) pattern to some degree. Every “thing” in the game world is represented by entities. These can be characters, trees, parts of cars or entire spaceships, depending on your game.
Entities are defined by their components, which group the properties that describe their state. Components can be shared between different entities, which leads to a modular design. For example, both characters and trees can share a Physical component that defines their position and rotation, whereas an Inventory component will be used only by characters.
These entities and components are brought to life by systems, typically threads that deal with the different aspects of the game. The physics system updates the Physical component, the AI system will observe the world and make decisions, the game logic system will make the game world behave in the way its designers intended, and so on.
The limitation of this approach comes from the fact that all these systems run on a single server with limited capacity; each system is competing for cycles with every other system.
But what if each system could be a distributed system?
This is the same epiphany Google had in the early 2000s: it is cheaper, simpler and infinitely more scalable and reliable to develop applications that run in clusters of commodity hardware instead of running on monolithic mainframes.
Of course, building distributed systems is hard. Insanely hard, even; you need to debug race conditions, write netcode, think about concurrency and consistency, try to understand Paxos and implement Raft, build fault tolerance into your design, have a strategy to deal with network latency and packet loss, put metrics and monitoring systems in place, and a myriad other issues which are not directly related to the fun and joy of making games.
It seems like a hopeless situation. The solution exists in theory, but in practise it seems impossibly complex for game developers, who are already stretched to their limits with everything involved in building a game!
Introducing workers: a new approach.
Fortunately, it is possible to formulate this problem in an elegant way, which preserves the simplicity of the ECS pattern but makes it possible for a platform to abstract away all of the unpleasantness of building distributed systems.
The key innovation is introducing the concept of workers. We take each system in ECS and replace it with a distributed system; each distributed system is built out of many workers, each of them being a program that can simulate some components of a subset of the entities in the world. The most obvious general- purpose examples of workers are game engines, logic workers or even game clients (desktop, mobile or even VR headset).
But say, for example, you would like to build a world with a fully functional ecosystem. Perhaps, you want to have realistic flocking behaviour. You could introduce this into this same approach. In this way of developing, a model of flocking behaviour could also be integrated. By giving each instance of a worker authority to simulate a component for a set of entities, it enables you to scale your game world. For these entities, it sends periodic updates reflecting their state. The worker then performs the simulation it is designed to do, and sends updates back to SpatialOS.
We call this the Entity-Component-Worker architecture:
This new architecture means the size of your game world is no longer limited by, for example, how much the physics engine on a single server can handle, because you run hundreds of instances of the physics engine to simulate different parts of the world.
This is rendered even more complicated when the number of workers you have are completely dynamic: you might need a physics engine for part of the game world, but not for another. Working out how to distribute the load across many, potentially hundreds of physics engines, is therefore a massive challenge. This is the problem we solved here at Improbable. How to manage these workers and run them in the cloud.
Conclusion
We envision the next generation of games will be built on a set of workers that cooperate to simulate a game world far bigger and far more complex than it is possible with a traditional architecture or in a single server.
Game engines leveraging cloud infrastructure in intelligent ways, will help us realise our dream of virtual worlds.
