game programming patterns - The 3 most common Patterns
The subject of game programming patterns, or design patterns as they’re sometimes referred to, isn’t always well represented on the internet. With this article, we want to explore what game programming patterns are and which, among them, are most commonly used by developers.
What are game programming patterns?
Programming patterns are generalized, reusable, and widely implemented solutions to generalized problems that occur with some frequency when you’re developing software using the object-oriented programming paradigm. They aren’t the same as libraries - programming patterns are a strategy, which effectiveness is proven by experience, to tackle a certain problem. They are better than any solution you could come up with on your own, and knowing about them can help you make the best design decisions and create good architecture - and once you know about them, they can make your work a lot easier!
The 3 most common game programming patterns
There are quite a few game programming patterns that you can learn about, but in this article we’re going to focus on the most common ones.
The Entity Component System
The ECS is one of the most known game programming patterns. It follows the composition over inheritance principle so that entities possess properties and functionality through the means of composition (rather than inheritance). Every object in the game scene is considered an entity, and every entity consists of one or more components that add behaviors and functionalities to it. Therefore, the behavior of an entity can be changed by adding or removing components.
An example of a game engine that uses the ECS is Unity.
The typical implementation of this pattern consists of:
- Entities: general-purpose objects, usually consisting of a unique id.
- Components: the raw data for one aspect of the object, and how it interacts with the world.
- Systems: systems run continuously and perform actions on the entities that possess the same component of the same aspect of the system.
The Observer Pattern
In the observer design pattern, an object, called the subject, maintains a list of other dependent objects, called observers, that are interested in its state and notifies them of any change in its state, usually by calling one of their methods. Since games are user-interaction driven, objects can change their state at any time; the observer pattern helps you avoid the problem of event notification in your game.
Let’s say you have 3 Character-Objects with 3 Characters’ animation-Objects. Animation-Objects are observers of the Character-Objects, so that every time a state variable in a character changes, it notifies the new state to the associated Animation-Object and takes action if necessary (for example animating the character).
The Factory Pattern
With this game programming pattern, you can create an object whose purpose is to create other objects. The Factory pattern helps you avoid the problem of complex instantiation: it allows you to keep these complex configurations in a single place, instead of having them scattered all around your code. For example, you can have a factory class with static methods to create other game objects such as characters or tools.