The one week game project: aftermath

The week of my OWGP is over, and it's time to wrap-up and summarize the lessons learned while conducting this experiment. First of all, I would like to explain what the idea of the project was all about.

Motivation

During my years working in the game industry, the most disturbing pattern I noticed was one that has to do with planning, prototyping and delivery. Basically, these steps only existed as a good idea but they were never truly developed.

Planning was just a way of casually stating what kind of game we were doing and some general rules about the directions, but the whole project was rapidly driven off course by means of improvisation, unexpected requirements and general trashing that came from upper management, or simply from the last person to join the team.

Prototyping didn't exist, or at least not intentionally. Turns out everything we were doing was treated as a prototype, because everything was open to tweaking and experimentation.

Finally, delivery was just a requirement to fulfill, but had nothing to do with the actual development schedule. Significant changes were made during the beta stage, introducing new bugs and cases, and the final version released was just the one that crashed the least, and included the features that had made it through the chaotic development cycle with as fewer bugs as possible.

In fact, I was actually able to ship only one game, and reaching gold was a nightmare of last minute changes, unforeseen features and overtime.

Unfortunately, these things are usual in the games industry. Not all studios like it, but most accept it, and even exploit it, as part of their culture. And these things are the cancer of an already troublesome industry, leading projects to delays, overbudget, cancellations, and teams to frustration, turnover and burnout.

What I want to prove is that planning and prototyping can happen in very short development iterations, where features can be tried and tested. And with a consistent application of these, and some work discipline on the part of managers, producers and designers, it is possible to actually deliver on time and on budget.

This is why I decided to conduct this small-scale experiment, where I would play all the roles, and feel the urge to delay and trash, but restraining myself from doing so because of the short time schedule. And I also had to keep myself from the programmer urge to overengineer and aim toward perfection, basically because there was no time for that. I had only five days to get the job done (hit a fictious beta stage, let's say) and that had to be it.

Postmortem

So let me summarize briefly the day-by-day development of this project:

• Day 1. I created a small scale simulation of the game idea, without using any actual resources, only abstract progammer art (cubes and spheres) representing the game entities (the stage, the props, the player, the enemies and the projectiles). I could get a simple game like this done in less than a day work, given that I had the technology for that (I used the Zombie Demo framework). Also, the game was a simple shoot'em up retro-style game, so I guess design was not such a big issue here.
• Day 2. This was the moment to start creating an environment for the game. I decided to use resources I had from an old project I worked with using the Zombie Engine. Problem is, I didn't want to use the Zombie Engine itself, because the complexity of defining and managing entities was too big and I wanted to keep such a small project small. So I tried to load only the data I needed and go with it. By the end of that day, it was obvious that I couldn't do that in just a few days, and still get the game done.
• Day 3. This is where I had to be practical and came up with an interesting idea. The only thing I knew for sure of the Zombie Engine is that graphics and edition worked really well. It was gameplay I couldn't really grasp. So I had this idea to create a level for my game that was made only of "dumb" entities, that is, entities with no logic or behavior. Then, I would get access to each of these entities and let my game logic update their state. I didn't even think this was going to work, but it was worth a shot, and by the end of the day, I could move my non-animated player through the level, so I decided to go this way.
• Day 4. After finding this indirect way to use Zombie to my advantage, I kept on developing the game but instead of abstract graphics, I used to entities in the level, and had to write the gameplay logic to move and animate graphics, and let game objects interact with each other (shoot, etc.) By the end of the day, I had my player running up and down, shooting forward, and enemies attacking. Unfortunately, I had only one day left to finish it off and still had some important things to figure out.
• Day 5. This was the day I had reserved for the finishing touches and I still had the important task of defining end game conditions, and restraining the movements of the player (I didn't want to use the collision system in zombie) so that's pretty much what I ended up doing. By the end of the day, the game ran more or less ok in my test level, but not so much in an actual game level. But this was something for the beta stage to work on, and I had already proven my point.

The result of this experiment has been enlightening. I've realized how easy it can be to stray from your original concept when faced with technical limitations, but also that short iterations lead to practical solutions, and having a clearly defined timespan, you don't get to trash or change your mind, so you just work with what you have. If it's not perfect the first time, you will do better next time. But if you deliver, you'll most likely be able to deliver again.

As Seth Godin states it: "You don't make a living out of being creative. You make a living because you ship." Being creative is something that happens only in the first stages of a project, but the kind of changes and redirections I've had to suffer (and many other developers for that matter) because of the hierarchical nature of development in the games industry are proof that poorly understood creativity leads to projects that are finished late, over budget and with a hidden cost of lost human motivation and satisfaction.

These factors may not usually be taken into account, but they are part of the process of creating games as well. And what I wanted to prove, myself included, is that it is possible to think of games development in a more practical and imperfect way, but one that ultimately leads to shipping, and getting to try again because of that.

So maybe I'll try again, and see what comes up next time.

I can't really publish the resulting product, because it's too shameful, and because some of the resources it uses are copyrighted by a former employer. But if you're interested, the code can be found in the SVN address.