There’s a common problem in software design that doesn’t only exist in game development called code dependencies. In a project, small or big, every developer comes to the point where several modules depend on each other: The GUI renderer depends on the health points and inventory, the inventory depends on the object pool and player state, the rendering engine depends on the object pool, textures, geometry, and much more.
One goal of object-oriented programming is to write modular (thus flexible) source code, and one of the biggest rules is to keep dependencies low. This article will talk about a system that implements a message bus with fire-and-forget behavior, with the main target being eliminating dependencies in the sources.
Welcome to another article in the Game Development Design series. This article covers good habits, techniques and workflows which are important for a general programming behavior and how to approach developing games (or even applications in general) in a way that will improve your progress.
We will talk about some well established techniques in the field of rapid development, which will move your programming focus to implementing features that are really required, and that those implementations are guaranteed to work as best as possible by automatically checking them.
Welcome to part 2 of “Game Development Design: The Component System”. Initially a second part wasn’t planned, but as I got a lot of feedback on part 1 asking about how self-attaching component systems work in detail, I decided to write a more detailed article about that.
Let’s quickly recall what a self-attaching component system is: The system consists of entities, properties and controllers. Entities can have none or any amount of properties, where every property is identified by a name and a type. Depending on what properties an entity has, controllers are attached to it.
Quick example: If there’s an entity with the property velocity, the controller Gravity will be automatically attached to it, because it requires exactly that property.
Before we start to go into detail, keep in mind that the GDD articles do not provide full source code. I believe in self-education and experimenting. Therefore I think that if you really want to learn and understand something, you have to play around with it.
GDD articles are mostly about software design for C++. I try my best to keep them independent, but since I’m a C++ programmer myself, using examples/code in that language just feels natural for me.
Now have fun with this article and drop me a line if you (dis)liked it or if you have any questions.