I would like to start by apologizing for how abruptly my last post (Game Entity – Part IV) finished, I actually hadn’t realized just how abrupt it was until it was pointed out to me in the comments. Lesson learned – don’t post when up to your eyeballs with other things.
Future Ponderings
Over this series of posts I have brain dumped a lot of what I know about game entities, how we use and abuse them and the various issues that can occur. While doing this I have tried to maintain a high level perspective, mainly so that I don’t get stuck in any low level nitty-gritty implementation details of one system over another.
So what conclusions have I come to in regards to our humble game entity and where it might be heading in the future?
Entities
The Game Entity is very much alive and kicking, it is evolving and still a fundamental part of most games in development today.
As much as we all want to move away from the traditional hierarchical tree structure it still has its uses, usually when developing on machines that don’t have enough processing / memory to allow the use of components. In some cases the traditional structure is used because the game doesn’t require anything more complex. I don’t see an issue with this after all it makes sense to use “The right tool for the right job”.
Components
Since components have come along the game entity has lost its grip on the data and functionality it once commanded, now it is reduced to a container or the glue that binds components together.
I remember a few years ago trying to sell the idea of components to someone with promises that level designers would be able to put game entities together without the need for taking up valuable programming time. Unfortunately my experience to date has not reflected this and engineers are still building the entities for games, albeit under a system that is a lot more flexible. The only exception and pleasant surprise to this has been when prototyping with Unity3D I have witnessed not only level designers building entities but artists as well.
Components evolved out of the issues we had with the bloated game entity, it hardly seems surprising that the Life Cycle and Processing Architecture have not really changed that much from their ancestor. I suspect that as components continue to evolve their architecture will adapt to the components requirements and not the entities they are attached to.
Some issues still haven’t been resolved, circular dependencies and processing priorities are just as much an issue under components as they were under entities. In the past we solved them on an individual basis rather than with a major change to the core system. This seems to have carried over to the components as well.
Nick MERCIER’s suggestion that components could be placed into processing groups has some interesting possibilities not least of which it seems to offer one solution to the inter-component dependency issue where component A must be updated before component B.
At various points during the game (level load, scripted event, etc.) entities are created, components are attached and initialized and then they are left to run within the world. At some point the entities are not needed anymore and they are then de-initialized and deleted. This is common for so many projects you can almost see that we are still thinking in the traditional game entity way. What seems to be slipping people’s minds is that data driven components are dynamic, they can be disabled / enabled, deleted / created even detached from one entity and attached to another. The idea that a game entity could be radically morphed during game play from one thing into another is an area that I don’t believe we have even begun to explore yet (designers take note!).
Multi-threading
The potential gains with a multi-threaded game entity / component system is obviously enormous and just the thought of those extra additional cycles certainly has a fair few game engineers excited, me included. The hardware is going to keep getting better so the sooner we start to take advantage of it the better we will be placed in the future when more cores become available. My main question is why hasn’t it happened yet?
Before I answer that question I have to confess that although I have experience working with multi-threaded systems I haven’t actually tried to implement a multi-threaded entities / component system yet. That is on my list of things to do when my current project has finished and I have some free time again. Just making you aware of this in case you think the following is based upon empirical data or hard won experience.
Architecture – In order to become multi-threaded we need to change more than just the component system, you need to look at all the supporting game systems as well. Of particular importance is putting under scrutiny how the various systems interact and communicate with entities. What is interesting is the way that Unity3D makes all game systems components as well, maybe this is the way we need to go? It certainly simplifies the problem.
Refactoring – I could see it being a bit of a nightmare to retrofit a component system to be multi-threaded, it would certainly be easier to implement from scratch.
Memory – It doesn’t matter how much memory you have it is never enough! Splitting a component update into multiple stages (read, execute and write) is going to create additional requirements on the amount of memory entities consume.
Educate – When we moved from writing traditional game entities to component based entities a fundamental shift in thinking was required. I suspect the shift in thinking that is going to be required when adapting to multi-threaded components is going to be even larger.
The shift from linear entity processing to multi-threaded processing is not going to be a quick over night transition. I suspect that we will convert first the easiest components then expand upon that slowly bringing the other components into the fold. Now that I have said that, someone will probably prove me wrong next week.
What have I forgotten?
I didn’t really get around to talking as much about A.I. and entities as I had originally hoped, maybe I will come back to them at a later date. I solemnly swear I will not write another blog series without first preparing it up front. :)
I will also follow up at some point in the future with how I got on writing a multi-threaded entity / component system, keep your eyes peeled!
These posts were written while under the influence of coffee, thank you to Taree, Sharon and Roberto at Sip Café for the most awesome coffee in Brisbane.
Previous Posts
The Game Entity – Part I, A Retrospect
The Game Entity – Part II, The Life Cycle and Processing Architecture