A Lifecycle Model for Game Development

My official profession is software product development.  If you work in the software development world, be it as a programmer, tester, project manager, tech writer, whatever, you tend to be pretty concerned about the development lifecycle.  How and when do we define the product requirements?  The architecture and design of the product?  How do we predict when we’ll ship the product?  How do we know when a product is “good enough” to ship?  These questions are often polarizing – today you are most likely in the agile development camp or the traditional lifecycle camp (often considered “heavy process”).  Both camps have good reasons for adhering to their “belief systems” – understanding the context in which you are operating is critical because there’s no One True Way to get interesting work done in software development.  Life critical health monitoring systems require different attention and concern for quality than do desktop applications that get revised/updated several times a year.

I can’t help but superimpose lifecycle concerns like this onto the process of board/card game development.  The irony of this is that many software methodologists have attempted to apply manufacturing lifecycle models onto the process of software development.  I guess I’m coming at it from a different angle.

I’ll assert straight up that I think the process of game development more closely aligns with traditional waterfall-style development technologies where you take a product through very discrete stages with very little re-visiting of earlier stages throughout the development process.  The process of manufacturing a physical product like a game requires decisions to be locked in well in advance of product shipment. There are exceptions – many niche RPG game manufacturers have gone to print-on-demand publishing models that lend themselves well to revision after initial print runs (at least better than boardgames – there are still costs involved).  Another exception is the so-called DTP game market (if there is such a market), but I want to focus on games that you can pick up off the shelf and purchase.

I am by no means an expert in this area, having only “done it” once, but I still want define a strawman lifecycle model for game publishing.  I want to do it for selfish reasons as we consider what to publish in 2006.  Having a bit more structure around the process should help the three of us involved (Rita, KC, and I) talk the same language and be clear about the different stages of development and publication.

The diagram is a combination of process flow and lifecycle phases.  This certainly doesn’t capture all of the steps required, but hits on the main points.  Also, the phase transitions aren’t always crisp – rules and component development, for example, is part of prototyping but also part of game development.  I view development as the process of refining all aspects of the game into something that will be easy to learn and self consistent.

The production of Havoc: the Hundred Years War is case in point on why a waterfall-style model is required once you enter the development phase and transition into production.  We had a production collation error in one of the decks that has been very difficult to fix; fortunately, we assembled the game in discrete batches and had the opportunity to address the problem before most of the product got to market.  We also had to do a lot of real-time repair work while selling the game at Essen.

Which leads to my final point: if we have time, in the future we expect to get all of the components in final form for inspection (QA) before going to production.  I don’t mean looking at proofs (we did that), but get the cards in celo, final rules, etc.  We were literally getting all of the pieces together in the final 5 days before departing for Essen so this wasn’t an option for us.  I’m also not sure how accommodating the production shops will be, especially for a tiny publisher like us.