Entity System vs. OO Game Engine: Considerations for teaching undergraduate game programming

In Fall 2010, I will be teaching CS315: Game Programming. The course is already full, with 30 undergraduate Computer Science majors enrolled. This Fall, the course will be a continuation of my History Education Game Design research project --- a collaboration with Ronald Morris in the History Department --- and the students will be implementing the Morgan's Raid game.

Last Spring, Ron and I led an honors colloquium in which students contributed to the design of the game. The results were not ready to move directly into implementation, and so I have invested significant effort this Summer revising the design documentation and writing the technical specification. These are both works-in-progress, although the design documentation is nearing completion. I have postponed writing the technical specification until I have been able to settle a major design decision: whether to use an entity-based or an object-oriented implementation strategy.

The object-oriented approach is the conventional approach, a common road to take and also the way I have always taught the class in the past. In fact, the whole course was created as an exercise in teaching design concepts through game development. For the past several semesters, we have written games in Java using Slick, and these technologies promote an OO approach. (More information on this approach can be found in my paper, "An experience report and analysis of Java technologies in Undergraduate game programming courses.")

The complications of the OO approach are well articulated in Mick West's article, "Evolve Your Hierarchy." Briefly, one tends to end up with overloaded game logic objects and complex inheritance hierarchies. That's why West advocates the Entity System (ES) approach.

I first read about ES development on Adam Martin's blog, where there is an excellent series of articles on ES for MMOG development. More recently, he posted an example implementation of ES on Android, which I found compelling enough to copy into a little hobby project to get my feet wet with this approach. The core tenet of an entity system is that each game logic object is implemented as an entity, which has a unique identifier and nothing else. An entity manager associates components with entities, where a component is a "dumb" data object that holds just enough information for it to be processed by a system. For example, consider rendering: those entities that can be drawn have a Sprite Image and Position component, and the list of such entities can be sent to the Rendering System, which draws the corresponding image at its indicated position. There is an intentional similarity to relational databases, where: the entity is the primary key; each component type has a table of component-tuples; selection of entities with specific components is a query; and the systems are the procedures that operate on the query results.

That's a rough overview of what ES is, but not much about what it's good for. The main benefit of the ES over the non-ES approach is that there is a clear separation of concerns: there is no overloaded GameObject class that can do everything under the sun: update position, render itself, simulate physics, score points, blow up, execute scripts, etc. It's important to realize -- and explicitly pointed out in Adam's post -- that the ES approach is not non-OO. Rather, all the benefits of OO design can still be reaped, but it's done in the design of the systems, not the design of a game object class hierarchy. This is one of the most appealing things to me, as a member of the "extends is evil" camp. That is, I always prefer to use and to teach delegation and interfaces over inheritance. However, I am still a novice with the ES approach, compared to my years of study, teaching, and practice with OO and patterns, and so I am uncertain how to most effectively design ES components and systems. Searching the Web, I have found a few scattered discussions on ES development but nothing remotely close to the maturity of discourse regarding OO design principles.

I am very interested in creating an ES system so that I can learn more about it. I'm not confident in my ability to write an accurate technical specification based on ES design methodology. It is worth noting that the game itself will be a 2D game in which the player clicks on cities on a map to move Morgan from city to city. There are not a lot of moving parts, and so the scalability of ES is not critical.

It is useful to look at the perceived benefits and disadvantages of these two approaches for this particular project with my students.

OO Advantages

• It's what the students ostensibly know.
• There is a wealth of information on how to design OO systems.
• I have significant experience using and teaching OO approaches.

OO Disadvantages

• The student's don't really know OO. They think they do, because their intro text books talk about OO, but except for the handful of students who have already done their senior software engineering course, they will hold a strong misconception that they know OO. This means that students will likely make lots of mistakes without knowing they are making them.
• Using OO for the game objects can -- and probably will -- result in an overloaded GameObject that some team of students will have to maintain, or that multiple teams will get into inconsistent states. Even a good source management system is not as good as avoiding conflicts in the first place.

ES Advantages

• The various parts of the game can be separated into systems, and each student team can be given a different system to work on. Because ES systems are architecturally orthogonal, this makes it easy for each team to work within a relatively safe sandbox. I can also use this to encourage unit testing of systems prior to integration testing.
• Because the systems will still follow OO design principles, we inherit the benefits of OO.

ES Disadvantages

• Because the systems will still follow OO design principles, we inherit the disadvantages of OO, except for game object overloading.
• Because the systems will still follow OO design principles, we have a multiparadigm system. Many of the students have only been programming for about 1.5 years, and they have only seen one language and approach. Dealing with the ES + OO, as well as the other tools I intend to use such as unit testing and continuous integration, may be cognitive overload. This is not a certainty, but it is an identifiable risk with negative consequences, namely leaving us without a completed system to field test in Spring.

I had hoped that writing this would help me come closer to a decision, but I think it has shown me that I have been leaning towards ES all along, primarily because of the first advantage that I mentioned. The prospect of leading a team of 30 novices in a significant development endeavor is unsettling, but it seems that the ES architecture gives rise to a natural separation of teams. My other concerns about dealing with such a large team will be addressed in a future post on software development methodologies and project management techniques.

I welcome any feedback that people have about the ES v. OO issues, both from game implementation and teaching perspectives. I found blogging to be an excellent venue for reflective practice on teaching last semester, and so you can expect regular status reports in the Fall, regardless of which approach we take.