In the game industry we have a kind of essay that we call a ‘postmortem’. This is usually an article that is written after a game is shipped where the developers examine the project with the benefit of hind-sight. This typically includes what went right, what went wrong, and the lessons learned. This way, developers can learn from each other. After all, a wise man learns from his own mistakes, but a wiser man learns from the mistakes of others.
Of course, we haven’t finished Hegemony, so we can’t write a postmortem yet. However, this is the most ambitious project any of us have ever worked on, and we’ve already learned tonnes, so today I’m starting a two- or three-part series that I’m calling a ‘premortem’. This is the sort of stuff we discuss in the office whenever we’re daydreaming about how we’ll manage our next project. Nothing I’m about to talk about has been proven yet – we won’t know that until the game is released – but these are our lessons learned so far, as we see them today.In the Beginning
We started working on Hegemony at an interesting point in time. At the start it was just Jim, Philippe, and Rob. They had mostly been working on casual games before that point, but when the big boys like Reflexive and PopCap cornered the market on casual games it became exceedingly difficult for a small shop like us to survive on casual games alone. In addition to that, the guys here were getting pretty eager to try something more ambitious; Jim had been researching Philip of Macedon and toying with the idea of designing a game about his campaign for the better part of ten years, so they ran with the idea and set forth into uncharted territory.
They knew going into the project that there would be a lot to learn. Rob was familiar with 3D programming, but never on the scale of a fully-realized game, and while Philippe was familiar with 3D art from his work on Tread Marks as well as in a pre-rendered form in games like Rival Ball Tournament or Vortiball, Hegemony would be the project where he would cut his teeth on modelling and animating human characters. When they hired me a year into the project I was fresh out of college and still living in an idyllic world where the concept of ‘return on investment’ was difficult to accept.
A number of things I’m about to talk about were, for the most part, unavoidable as a part of this learning experience. Some things were avoidable, but we simply didn’t know any better.
Vertical Slice
The phrase ‘vertical slice’ is one we’ve heard a lot from other industry professionals since we began work on Hegemony. The concept of a vertical slice is a demo that establishes our gameplay without any of the polish that you expect of a full game. It usually takes the form of a single level with no sound and boxes or spheres instead of proper artwork.
With Hegemony, our goal has always been to make something that plays out on a grand scale but still simulates skirmishes in a detailed way. In accordance with that goal it was decided that the game shouldn’t have levels, but instead take place on one gigantic map. This is still the design of Hegemony, and it’s one of the more unique features of the game.
With that design in mind, it seemed like a natural starting point for Hegemony: build a giant map of ancient Greece. Rob began work on a map editor, Jim started modelling the map, and Philippe began work on textures and models for the map. In retrospect, this wasn’t necessary. We could probably have started with a square grid and grey cubes for cities and farms, and we would have been able to experiment with the gameplay a long time ago.
This method of development lead to a lot of redundant work. For example, Rob experimented with three path-finding engines over the course of this project, and for each one Jim had to specify where and how the brigades in the game could move around. This was a lot of work, all spent fleshing out an unproven technique. At the time it seemed like none of this effort was wasted because Jim had nothing else to work on, but if we had re-ordered our priorities Jim could have spent this time play-testing the game.
Offset Programming and Design from Art and Level Design
The example I just gave highlights a more general problem with our development of Hegemony. The job of creating a path-finding engine is a programming problem and that of specifying where and how brigades can move around is a level design problem. Ideally, we wouldn’t have begun the latter until the former was complete, but as always ideals can be difficult to attain. In practice, we did a lot of things all at once that would have worked better in sequence.
Another example of this is our animation system, which I’ll come back to later in this series. In the beginning, the animation was going to be done with sprites; we later switched to morph targets and finally settled on skeletal animation. With each one of these changes Philippe had to re-create all of his animations for the new system. In an ideal scenario we wouldn’t have spent any more time than necessary exporting these animations until we were sure our animation system wouldn’t change any further.
It wasn’t all for naught, though. During this period of time Philippe learned a lot about modelling and animation, but for our next project we’ll be in a much better position to try to offset these tasks. We’ve been designing the Hegemony engine to be reusable, so after we launch the game our plan is to set Rob to work on building tech for an new original game while other parts of our team are working on creating another game with the Hegemony engine. This should ensure that we aren’t working with new technology until it’s developed to a point where it’s ready to be used.
Usability Testing
Shifting gears, I’d like to jump ahead a few years and talk about something we only recently learned about first-hand: usability testing. This involves bringing people to the office and watching how they play the game to see if we can learn anything that we would have otherwise glossed over. Before trying it for ourselves, I think we all had the idea that usability testing produces very little insight unless you have more testers and more man-hours than we could afford to spend.
How wrong we were! Over a period of only two days we gathered a dozen students and let them play the game while one of us stands over their shoulder and records their session. Even though it was only a dozen testers playing an hour each, we learned more than we could have imagined.
We had been playing the game so much at this point that there were a lot of aspects of the game which were unintuitive, but we were too close to the game to notice. When we got the chance to watch somebody else play the game a lot of things became crystal clear to us, and the entire process was much easier to execute than we had expected. Hopefully we’ll have another chance to repeat this experiment before we launch.
Stay Tuned
I’ve got a list of these lessons about as long as my arm, so I’ll be talking about this for another week or two. If you enjoyed this article, be sure to come back next week, when I’ll probably be discussing some of the lessons we’ve learned on the art side of things.