In this post I’m going to continue setting up some ground work to talk about Agile and Games Development by discussing the Game Development Lifecycle. A lifecycle in this context is the identifiable stages of production a project moves through from initial conception through to shipping (or going live in the case of services). I think the games lifecycle is pretty much divorced from the project management methodology you follow. There are simply several stages a game goes through whether they are explicit recognised or not. Much of what I write below is idealised in order to illustrate what I think the stages are and what happens in them. I’ve also deliberately ignored stuff like marketing as I’m no expert and it’s something so dependent on the chosen business model.
Here we have the lifecycle:
A couple of initial things to note off the bat. Firstly there is no scale to this diagram it ultimately captures the process in a fractal manner. As you decompose a game you still need to go through all of these steps for each component of the design. For example if you are adding a new feature to an existing game you still need to work out if it’s a good idea or not so prototyping is only sensible. The second thing to note is that the transitions and where exactly a game is might not be clear in any particular organisation. Some organisations are very formal, have very specific hand-offs and might even abandon work (but keep the game artifacts made). Others, particularly in smaller teams can be very fluid and the move from prototype to shipped product is a series of refactorings of the game. In my opinion almost all games go through these lifecycle stages and quite a lot of project cock ups come from not respecting the limitations of each stage. For example if a project goes through a sudden large pivot in development during some of the latter stages then it’s behooves people to recognize that they will need to drop back in the game development lifecycle for substantial portions of the game to prove it out again.
Moving from left to right through the stages in the diagram should lead to a firming up of the game ideas. It’s an oft said thing that the initial game concept bears only a passing resemblance to the final game and that’s because ideas are just the starting point. Ideas need to be tested and refined, preferably in the crucible of real player experience. This is one reason why putting a massive amount of time into a monolithic design document before anyone starts making anything is a terrible idea. Moving through the lifecycle stages should also firm up knowledge about when the game will be shippable and the scope of work remaining. For a lot of projects this doesn’t happen though and I think a decent Agile approach that takes some ideas from Lean would help approach the lifecycle stages with the right mindset.
Idea
The cornerstone of any project but also the least important part. Ideas are ten-a-penny and it’s the ability to take that idea and build something good from it that is hard. Sometimes the team you have might not be a good fit for making a particular idea or the resources required are unrealistic for what you want to achieve or there is no real market for your idea. There are lots of reasons not to pursue an idea but at this stage many benefit from a little making to gain a better understanding of what might be involved. I’m a firm believer that there is a lot of value in a failed idea and even more value in having a whole bunch of ideas you like in existence as prototypes. Ideas should be given a quick sanity check before moving onto the next stage without getting too involved in details that will likely change further on in the lifecycle anyway.
Prototyping
Lets make a game! In game development it’s the job of a prototype to take the core game ideas and demonstrate that the team is capable of turning them into something fun. This is necessarily messy and exploratory. It’s also an ideal time to stop spending more money on an idea if it seems to be going nowhere. I’ve written at more length on the value of prototyping to both individuals and businesses as well as having spoken about my own experiences. The end result should be an entry in your prototype repository and a decision about whether or not the prototype was deemed a success. Prototypes are also very useful for securing funding to take the game into pre-production as well as validating your game idea by letting real people get their hands on it.
Pre-Production
Pre-Production begins when you take a prototype and decide to make it into a complete game. It’s the process of taking the core game ideas, refactoring them and expanding on them to create a meatier game with the view to nailing down most of the game systems and features. As this progresses the underlying technology is generally refactored as well, to make it technically better and suited to the creation of the large amounts of content many games need. The goal of pre-production is typically to end up in a position where the majority of the work remaining is content creation without large changes to game features. Usually this culminates in a ‘vertical slice’ of the game containing every aspect demonstrated at production quality in a ‘one level’ run through. Making a ‘vertical slice’ also exposes the weaknesses in the technology and content creation pipelines that need to be fixed before the game should be put into production. There should be further validation of the game with lots of real people all the way through this process as the game changes and by this point you should have a good idea of the quality of game you are going to put out.
Production
Production is the point where you get hard to work at cranking out game content which is often the most time consuming part. At this point it can get incredibly expensive to make relatively innocuous seeming changes to the game design. For example altering the attributes that define how a character jumps at a late stage might mean you need to rework all the content in your game. Ouch! Ideally people not concentrating on making content or supporting content creators will be fixing defects, optimizing the game, improving the user experience or ‘juicing it‘. Hopefully it goes without saying that you should be putting all this new content in front of real people all the time to validate that it’s fun and works well with the game pacing (e.g. everyone fails then gives up on stage 3, maybe we should fix that).
Polish
Polishing is the final step that takes a game from being good to great. It’s adding more ‘juice’, improving the user experience, making sure the game pacing is great using feedback gained from playtesting with real people, squashing as many defects as possible and making sure the game runs smoothly on all targeted platforms. A lot of the time this runs in sync with production as some content is often finished before other parts. Although a bit of time at the end of a project dedicated to making the game much more polished can make all the difference. A word of warning though. Games never feel finished to the people working on them. At some point you just have to stop and put it out into the world.
Ship
Champagne or shame this is where the rubber hits the road and your game either crashes and burns or achieves some reasonable commercial success. It’s also the hardest point to reach for all sorts of reasons so it’s quite an achievement to be part of a team to ship something even if it’s not a commercial success.
meheleventyone 