This design pattern will help you make sense of your game design as it gets bigger.
You can listen to episodes 77, 86, 87, and 88 for more information and background. This episode will start tying things together. I didn’t originally describe this because it really is a merging of many patterns. But as I started coding this myself, I’ve realized that there’s more to it than just sticking a few design patterns together. Enough that you can benefit from a description.
Here’s the big picture. Your game will likely have many characters and objects in it. The characters can be directly controlled by one or more players or be controlled by the game as either direct opponents or just background characters.
And the objects can be almost anything that your character interacts with. This could be a weapon, or an apple, or a door or table. All of these characters and objects share certain abilities and behaviors. That’s normally a good sign to use inheritance in your design. But if you go that way, you’ll find that inheritance leads to large and complicated hierarchies of classes that are difficult to change.
Listen to the full episode to learn more about how the patterns work together to keep your game design understandable as it gets bigger. Or, you can read the transcript below.
Transcript
This is something I’ve been working on for the last three months in the game development sessions. You can listen to episodes 86, 87, and 88 for more information and background. This episode will start tying things together.
And if you’d like to participate in these game development sessions, you can really learn a lot more than what I can describe here. Listen to episode 248 for a full description of a special offer now through the middle of January. And in that episode, you’ll also hear about a specific example of a template design that I was working on.
The best way to participate in the game development sessions is to become a patron. You can get extra podcast episodes, videos, and free game development sessions.
Okay, on to the topic for today. This brings together several design patterns. I didn’t originally describe this because it really is a merging of many patterns. But as I started coding this myself, I’ve realized that there’s more to it than just sticking a few design patterns together. Enough that you can benefit from a description.
You can also listen to episode 77 about the observer pattern. That forms a big part of this as well.
Here’s the big picture. Your game will likely have many characters and objects in it. The characters can be directly controlled by one or more players or be controlled by the game as either direct opponents or just background characters.
And the objects can be almost anything that your character interacts with. This could be a weapon, or an apple, or a door or table.
All of these characters and objects share certain abilities and behaviors. That’s normally a good sign to use inheritance in your design. But if you go that way, you’ll find that inheritance leads to large and complicated hierarchies of classes that are difficult to change.
And I mean they’re difficult to change both at design time and at run time. You might want to change something about how an object looks or behaves and doing so affects other things in the game because they all inherit from the same base classes. This causes problems and increases the work and time needed to write your code.
And it also causes problems when you want something in your game to change how it works during the game. Maybe you want the character to be able to move through walls like a ghost for a short while and then go back to being solid. You’ll have a really hard time designing such a game if you’ve relied too much on inheritance.
Episode 86 describes the Component design pattern which can be used to attach behavior to characters and game objects by having them contain this behavior instead of inheriting this behavior. Want a different behavior? Just swap out one component for another. It’s like being able to rearrange your inheritance hierarchy whenever you want.
Because you’ll have code separated into components, you’ll need some way for them to communicate. Episode 87 describes the event queue and episode 77 describes the observer pattern. Each of these has a place. Sometimes, you’ll want to place events in a queue and process them later and sometimes you’ll want a more targeted approach that lets interested code know about something happening right away.
A other way to think about this is that a queue lets you stack up work to be done by almost any other code. This is work that needs to be done maybe to finalize something that’s already happened in the game. While an observer lets only that code which has previously shown an interest to get involved right away. Maybe the observer will let that other code change things before they become settled. Or even cancel something sort of like a veto power.
I’ve been talking about characters and game objects as if they were different things in a game. And they are. But I also said that they can have many of the same needs and share behavior. If you throw a chair against a wall, it should bounce off and possibly break just like how a character will fall back after hitting a wall and maybe take damage too.
The entity component system tries to treat as much as possible as just a game entity. Whether this is the hero of the game or a rock laying alongside a road that can be picked up and thrown, they’re all entities. Or game objects if you prefer.
What makes one game object different from another is the components attached to each and the values of properties that these components have.
You’ll need another aspect of all this and that’s systems. Think of a system as something to manage various game objects and their components. You might have a system that just deals with movement. In order for this system to actually move a game object, then the game object will need to have a moveable component with properties to remember the current position.
With all these components and systems, you’ll need to sometimes find one or another one. That’s where episode 88 helps by describing a pattern you can use. It’s a flexible way to describe what you want instead of looking for a component or system directly. You might find a component or system that you weren’t expecting but it should do what you need and that’s what’s important.
Hopefully, you can see the need for an entity component system for large games. Actually implementing one is a very different story. I’m almost done with the implementation for the game I’m working on and will go into more details in the next episode.
I’ll end with one final thought. And it has to do with what I’ve found to be a good way to develop software. You see, I started out without an entity component system and got the game to a point where you can move the character around on the screen. Then I switched focus to building an entity component system and for the last several months have been working on just that. The only way I know it’s working has been through unit tests.
But before going too far, I switched back to the game and modified it to start using the entity component system. There were some changes that I realized were needed to make the new entity component system easier to use.
This is an agile approach. Get something working that actually has value. But don’t take it too far just yet. Eventually, something else will become important and working on that might change your thinking about earlier designs. That’s okay and leads to a better overall design that stays focused on the current and evolving needs of your customer.
In this case, I’m not just trying to build a fun game, but I’m doing it a way that will help you to learn how to program better.