Friday, June 25, 2010

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.

10 comments:

  1. It does seem to me that you have gone ahead and made a decision. You genuinely seem to believe that ES more naturally allows you to accomplish the goals of this class. My input, as a student, is one of intrigue. I've never heard of the ES approach to design and am always looking to learn something new. Also, there is something to be said for a professor teaching something which not even they are terribly familiar. Learning becomes a shared experience, not the same mundane lectures that so commonly infest the college classroom. My experience with some teachers has been that, when they have been teaching the same thing for years, they forget what it can be like to experience the material for the first time. This leads them to teaching above the heads of some of the students in the class, which of course is an extreme detriment.

    Beware of not being prepared, however, for there is nothing worse than a teacher who attempts to instruct students in a subject he/she does not fully understand.

    ReplyDelete
  2. My main concern along these lines that, in order to fulfill our production schedule, I will need to do the lion's share of the ES design work over the Summer. That is, I will have to decide on the components and their systems in such a way that I can divvy out systems to student teams.

    If students were doing their own projects, it wouldn't matter so much if their approach was successful or not. We could take our time and experiment with different ways of designing entity systems together, and honestly, that would be pretty great. In this case, we actually have "clients" (i.e. external stakeholders) to which we will be delivering a software product. Also, we need to keep maintenance in mind: I'll have 30 students in Fall, but there will inevitably be some maintenance required, and that will probably be done by me or independent study students.

    I'm not sure if it's too late to get you into a Summer 499 to look into it. More seriously, there's a few people I want to be looking at the technical specification over the Summer, once I get to writing it, in hopes that you will then apply for management positions in the class. (Yes, you heard right, but more on that in a later post. ;)

    ReplyDelete
  3. I could sense through your post that you are more inclined to the ES approach. I guess there are two ways to go about it. If you want the project to be completed and have a deadline at hand, then may be the best way to go would be by trying out the approach that you are familiar with. But by the perspective of a professor( who needs to experiment) may be inclined to the new ES approach that you are not that familiar with. What is the point of doing a project by some approach that you are familiar with and you know that you can complete? However it is different issue when you have a deadline and there are other parties involved to whom you are accountable.

    ReplyDelete
  4. You hit the nail on the head at the end there, Siva. If the experience was designed purely for learning, I would enthusiastically jump into ES with both feet. However, this really is a semester of production, and we need to have working software at the end; this makes me anxious to try something that is totally new to me.

    ReplyDelete
  5. This is a very interesting topic, as I'm digging into ES as well. I've already made a prototype system, but my brain is still digesting how to implement it properly. My primary concern right now is how to deal with the rendering aspect for a 2D game. Scenegraph or not, how do deal with culling, is scenegraph a component? What about render priority? What about complex resources? Do they fit in a table?, etc. Adam Martin does not provide enough practical implementation details.

    I have been using Game Object Component System, as described in Game Gems 6 (or was it 5?), which is something like a hybrid between ES and OO. It has a "dummy" GameObject class and Components associated with it.
    Each Component has all of the data and the method implementation to manipulate it's data. Components can communicate with each other, and actually acts like systems, manipulating components of all gameobjects.

    I would recommend this for your students. It has a lower learning curve and thus gets things going faster. It might be a good entrance point into ES.

    ES is still being digested by most, I believe, and I wouldn't count on tech-support from the only person who actually knows how to properly do this, Adam Martin.

    ReplyDelete
  6. Thanks for the tip, Arni! I went and checked out Game Programming Gems 6 from the university library this evening, and I look forward to reading about the Game Object Component System approach. From my brief glance and your description, it sounds like it may jive more nicely with my OO leanings. To me, there are still a lot of unknowns in "pure ES" regarding how to design effective systems.

    ReplyDelete
  7. So, it has been a few months... How goes it? Were you able to come up with a reasonable ES implementation for the class? What are your experiences so far with it? Care to share any code?

    ReplyDelete
  8. It's gone quite well! I gave a core ES implementation consisting of (IIRC) an EntityManager interface, a BasicEntityManager default implementation, the Entity class, the Component interface, the Position component, and the ImageRenderable component and system, which system draws images at positions. The students have built upon this with some success, although right now there is a lot of code duplication because of the number of people on the team.

    One of the goals for this sprint is to refactor, ameliorating some of the spaghettiness that has infested the system. This was an expected complication, given that the students are novices at ... well ... pretty much every part of software development!

    I plan on writing a more comprehensive status report as a new blog post soon.

    Thanks for the interest!

    The code that I provided was not substantially different from Adam's. I modified a few method names to suit my preferences and approached convenience methods a little differently, but it's really the same core as in his Android-based approach.

    ReplyDelete
  9. Thanks for the update, Paul!

    Quote: "I plan on writing a more comprehensive status report as a new blog post soon."

    Looking forward to reading more about it. I understand the concept of ES, but I'm still somewhat hazy on the best way to implement, so I'm happy to glean anything I can...

    ReplyDelete
  10. I just wrote a lengthy post last night about my experiences with the game programming class so far. Although it doesn't deal much with the mechanics of the entity system, I do say a little about the complexity of doing this with a team.

    http://paulgestwicki.blogspot.com/2010/09/two-sprints-with-315-studio.html

    We're going to do a refactoring session on Monday, and I'll try to share some notes from that experience, because I think that's where I'll be able to see how my students are learning these ideas. I'll also post to my list and see if any of the students are interesting in writing a bit about their own ES experience, either on their own blogs or as guest posts here.

    ReplyDelete