Game Engine Architectures
This week, in one of the game programming classes, students enquired about the best way of designing their Graphics Engines and Game Engines. We run courses in which students have to implement simple graphical applications with the use of OpenGL; and courses in which they have to implement games in C++. I have recommended them to use component-based entity systems and delegation, as it is by far one of the most widely used solution. I have pointed out that typical object-oriented hierarchy modelling, even though it is simple to start with, may quickly lead to problems and the need for multiple inheritance. I’ve also suggested model-view-controller pattern, or MVC, to cleanly isolate their model, logic, and presentation layers. You can check the introduction article here. It is important to note that there have been multiple discussions on game engines, and this one is a good example this one: “Why are MVC and TDD not employed more in game architecture?” and this one “Component based game engine design“.
Obviously, the typical solutions that we use need regular update and therefore this weekend I’ve looked into the various options for design game engines. And it turns out to be quite a complicated topic on its own. I have learned 2 things: a new, pretty complex way of implementing component system, and functional reactive programming patterns. Let us start with CBES.
Component-based entity systems
CBES, or Component-based Entity Systems are one of the most popular and pervasive models used in modern designs of many games and game engines. One of the best introductions is provided in the Game Programming Patterns. However, they have their drawbacks. They tend to get quite complex, due to inter-component communication, state-tracking, and dependencies. They do not take any advantage of cache lines, and they can be limited in the way of abstracting behaviours.
One of the interesting models for implementing the components is Data-oriented Design. In CppCon 2015, Vittorio Romeo provided a skeleton for the Implementation of the component-based entity system in modern C++. His talk is definitely worth a watch.
There are other alternatives. In this simple article “Why I switched from CBES to FRP” the author is pointing out some of the limitation of component-based system, and suggesting the switch to Functional Reactive Programming.
Functional Reactive Programming
It turns out, that FRP, or Functional Reactive Programming is not only limited to Haskel or Elm. It can be used in your C++ projects to. There is Reactive programming in C++ (RFP in C++: video lecture). The code of David Sankel’s sbase system is available on Bitbucket.
ps. David has also C++ oriented podcast, that is quite interesting.
- Poznan marathon: October 11
- Birdman, 2014