The Protostar Engine is a project that was developed by a team of three developers using C++, DX11, and the Bullet Physics SDK to bring together the necessary systems for basic gameplay.

At the start, we had our rendering systems in place and a basic input system that allowed us to read in key presses to drive the game. To get to the state where we could create a full gameplay loop, we needed to add our physics and scene management systems and allow them to work together. Our main problem was that we had all of our logic for our systems constantly checking for work to do in our game’s core update loop. We knew that this would not be a scalable approach over time because it created unnecessary work and made communicating across systems complicated.

To get around this, we looked for ways to establish a new architecture that would allow us to add on systems and have better control over how they interact. The approach we ended up using was an event bus architecture or pub/sub messaging system. This technique provides a few key features that the team was interested in:

1. System decoupling. In this architecture, each of the major systems subscribes to the types of events they need to work with and publishes events related to their domain. This allows each system to only process relevant data and remove the possibility of unnecessary or unintended code dependencies across unrelated areas.
2. Clean, organized code. With each system relying on communication through the event bus, it makes it easy to locate relevant code. For example, the Physics system should contain all physics-related code and nothing else.
3. Efficiency. Previously, each of our engine’s systems were required to check if there was any work to be done each frame. Under the new architecture, we eliminate the need for individual systems polling for work by only executing code as events require it.
4. Concurrency. We create a single event bus and give a reference to all major systems so that events of different kinds can be processed as they arrive. This gives games the feeling of having many things going on simultaneously and in varying order, even when the code execution isn’t truly parallel.

In the end, we were able to put together a simple platforming game in which the user controls a ball and must jump their way to the top and knock down some cubes that are up there. This puts together our game entities, physics, input, and rendering systems to generate a basic gameplay loop.

Check out the repository here!