The Story: Another lesson in agile game development

This post is really just Scrum to the Max! part II.  Same disclaimer applies.  Also, expect a few more of these kinds of posts while we’re feeling out this whole game-development-scrum thing.

Okay, we’ve spent a lot of time talking (if not on the blog, then face-to-face with friends and family) about our story.  In fact, the entire project started to move back in summer ’09 based on the strength of the story.  Eight long years of thought and development, as well as Lewis’ incredible personal talents, have certainly made their mark.

But is it finished?

Without the story, there is no game.  All other components are affected by the story; in fact, the importance of every single addition we make to our game, be it art, music, code, or design, is measured against how well it serves the story.  If a game mechanic or feature is superfluous to the story, then it is wasted effort.  If a piece of music or art clashes with the emotion of the story, then it needs to be re-done.  For these reasons, it’s tempting to hold up the story as an all-encompassing requirements document that needs to be 100% complete before any project work can start.  That’s not very agile, but since all the code depends on the story anyway, why not just wrap up the “game story” into a high priority task and get it out of the way first?  Should game project leads go into game development with a story that has all the details hashed out, anyway?

As ever, it’s not that simple.  A game story can only be taken so far in isolation.  Even after eight years of story work, Tainted Sword’s story is still undergoing active development.  Any game story should hold water, but it’s remarkably difficult to iron out all of the details in advance.  History, naming conventions, back story, geography, religion, culture, politics, genealogy, and more, all coalesce into an incredibly complicated set of constraints that could take a lifetime to fully define.  Just for fun, I googled the names of the different characters in Tainted Sword some time ago, and found out that the name of a certain high-profile character is actually the Albanian word for “depository” 😉  This wouldn’t be such a bad thing if the character were secondary, but as a member of the royal family, you’d think his parents would have known better!

So, could you just take a really long time and sort out all the details?  It seems unlikely;  sometimes the nuances of a written story are contradicted by game play design choices.  Writing doesn’t produce games, it produces novels; writing a novel before writing your game only ensures that you undergo the same painful choices that a film director does when adapting a book to the big screen.

Finally, even if you could develop the story to perfection before building a game, you wouldn’t necessarily want to.  Some details are impossible to refine without context, and context is easier to comprehend in an interactive game than in the abstract realm of thought.  The act of refining these details can have far-reaching implications; a story is a fragile thing, and even a subtle variation in the details will be enough to turn the entire story in its head, even without changing any dialogue or events.  This happened to us about two weeks ago while resolving some details in the background of one of our primary characters.  That’ll teach us for thinking our story was finished!

All of this seems to imply that stories, like games, need to iterate, and will necessarily benefit from iterating at the same time as the game itself.  That’s not to say that you should try to make a game without having a story first; you need the story to provide that critical early project direction.  The function of the early story is to justify creating a game.  More rigor at an early stage is welcome, but could be unnecessary and might even be counter-productive in the long run.

Now, the real problem for us is that we have story work to do, but no easy way to prioritize it against code, design, and other work.  Are story details like high priority bugs?  Should we work on resolving just a limited number of story details each iteration?  Should we prioritize story work in a separate track to code?  The answer is, I don’t know.  We’ve brainstormed a couple of solutions already, and nothing seems to quite fit.  The book we ordered just shipped today, so hopefully it can shed some light on this problem.

Posted in Development, Rants, Tainted Sword, Tool Reviews
0 comments on “The Story: Another lesson in agile game development
1 Pings/Trackbacks for "The Story: Another lesson in agile game development"
  1. […] it’s time to finish off the series (same disclaimer applies).  We’ve been talking a lot about Scrum lately, and with […]

Leave a Reply