Cubicle festering. Avoid it… Using Scrum!

Alright, it’s time to finish off the series (same disclaimer applies).  We’ve been talking a lot about Scrum lately, and with the help of Clinton Keith’s Agile Game Development with Scrum, we’ve finally settled on a system that we all agree on.

The book was very helpful.  It frames agile game development in a realistic manner that is grounded with a vast wealth of industry experience, highlighting key differences between pure IT Scrum and Game Development Scrum.  The primary difference (as we discovered) is that, despite all attempts to distance themselves from the Waterfall Model, game development projects have some distinctly identifiable phases, the largest of which are called Pre-Production and Production.

In Pre-Production, you do a lot of exploration, prototyping, tool building, and architecture work to try and find what makes a fun game.  In Production (the single largest and most expensive phase of development), you commit to a game design and start mass producing assets like art, levels, and music.  Minor changes to the game design during Production can cause huge re-work of assets, so it’s important to spend enough time in Pre-Production before you go all-in.  However, since we’re still working in an agile game development world, there is significant overlap between the end of Pre-Production and the beginning of Production, in which you start introducing the first few game levels into your game engine and testing them to make sure you’re not just making a big, steaming pile of crap.

Right now, we’re sitting pretty firmly in Pre-Production territory in Tainted Sword as we continue to refine the engine and make prototypes and even begin work on our map editor tool.  The big revelation for us was that, once we head into Production, we’re going to need to step away from Scrum and head into Lean Manufacturing territory.  This all makes perfect sense now, but keep in mind that my background is in IT Scrum, which is adequate from beginning to end on most IT projects.  I’ll be the first to admit that Scrum is my project management security blanket, so Lean Manufacturing is pretty scary to me 😉

Using all of this information, we were able to create a comprehensive Product Backlog of User Stories, and we’ve even estimated a bunch of them using Planning Poker.  Rock on.  Even so, we’ve uncovered a flaw in Clinton Keith’s description of game development which is indicative of a problem with the game industry in general.

He forgot to talk about the story.

Well, not quite.  But he mentions it only in passing and lumps writers in with designers, essentially treating story and writing as an afterthought to game design and mechanics.  I’m not going to go all “Games as Art” on you guys, but I will say that a big, valid criticism of the game industry is that game stories tend to be juvenile when compared to other story-telling mediums.  Clinton’s book, while not resolving the issue, at least shows us why the issue exists.

Our solution was to consider the kinds of story activities that need to take place in each of the four phases of game development, then spread them out in a Just-In-Time fashion.  By doing this, we encourage iteration between the story and other game development disciplines like art and code, and avoid discussing the story details until they’re relevant and testable.  For example, the story events, conclusion, themes, and style are all determined early in order to justify creating the game, but details like history, culture, geography, and even names are only defined at a high level until they begin to appear in the game.  In this way, we avoid changing story details in order to satisfy gameplay requirements.

We follow the same approach with character progression and content design.  This means that while we’ve identified skills and items as an important part of our combat engine and even tested the combat engine with placeholder skills and items, we aren’t going to finalize a list of skills or items until we can understand the context of each skill and item in terms of gameplay and progression.

Wow, that was a pretty heavy series of posts.  If you somehow managed to endure all that, I hope you learned something.  If not, well… here’s something to cheer you up.

Posted in Development, Rants, Tainted Sword, Tool Reviews

Leave a Reply