A Guidelines of Game Development Life Cycle (v2.0)

This is the revised version of my research during my thesis (see post here). There are many game developers who have proposed their own way to conduct a game development process, and each of them prove their method is successful. Here, in this post, I want to proposed a new approach on how a game development is done.

Let’s call it: GDLC Guidelines

Why Game Development?

Because game has become one of the most prominent industry in this era. Assume there are computer, several programming experience, and willingness to create game, anybody can be game developer, given the circumstances. Anyone can try their own method on how to create games, but this one try to give an insight on how game development conducted, both as engineering process and as creation of art.

The Phases

For the starter, the proposed GDLC consist of six phases which is shown below.

Game Development Phases

The diagram shows the phases, while the table below shows the game build progresssion. Version means the game build version, while stage means the maturity stage of game prototype build. Well, no matter, the details are provided in my paper (download here – using IEEE Xplore) and my book (sorry, written in Bahasa Indonesia).

To understand the diagram, let me give you an impossible-to-win war analogy:

To declare a war, one must give a warning, ultimatum, or announcement which state there will be agression. Before the battle begin, there is briefing to plan what actions should be done to win the battle. Then the battle ensues when the both party start the assault. The battle ensues, loses a lot of casualties, then the commander gather his party in a war council to evaluate the current situation. The discussion end up in two choice: refine the strategy for the next battle, or propose an armistice. If the former is chosen, repeat from briefing to evaluation. If the latter is chosen, armistice session is taken. During the armistice session, the general may evaluate the whole battle and ask to the leader whether to continue the war after the armistice end, or propose a peace treaty. If the former is taken, repeat from briefing, if the latter, both army will retreat and the war is finished.

From the analogy above, it can be inferred as:

1. The whole game development process is the same as the war or the battle
2. Initiation is the ultimatum, announcement to declare a new war
3. Pre-production is the war briefing
4. Production is the battle/assault/aggression
5. Testing is the war council evaluation
6. Beta testing is the armistice
7. Release is the peace treaty

Got it? No? Alright, no problem. Let’s just jump in to the details. See the animation below to get a hold of how the game development phases occur.

The process of game development

 

Initiation

Every journey begins with a single step. The game development does too. The first step in game development is creating the idea. I mean, not just ordinary idea, but the idea. Creating idea is the hardest part to begin with, especially if you want to craft something new, with very limited basis. What to do in Initiation is you ask yourself, what kind of game you want to make.

Brainstorming is the key, and here are some useful pointers:

• What kind of game you’ll make?
• How is the gameplay?
• Who are the characters?
• What feature it has?
• Is it 2D or 3D?
• How the story begins?
• Who’s your target audience?
• What’s the target platform?
• What kind of technology/engine you’ll use?

Pre-Production

Pre-production is the planning phase before the real production begins. The first pre-production is the most critical one: The Game Design.

Game design revolves around the refinement of game concept, defining the genre, characters, gameplay features, game mechanics, players interaction, game fun factor, and monetization techniques. After the game design is finished, it’s written down in the form of Game Design Document, and start creating the first prototype: Foundation prototype, which serve to show what gameplay it has – It must be fun. After the foundation is accepted, begins with refining the foundation into Structure, refined and more playable prototype which shwon the potential of being fun and functional.

That’s what happen during pre-production in the first cycle. During the next cycles, prototyping is not that significant anymore and game design is far more focused on bug fixing and game balancing.

Production

The core process of production cycle is the production. It is the heart of game development process, as the blood being pumped to every vein your body (well, kidding). Production is closely tied to the creation of game assets, source codes, and the integration of both elements. The explanation is just as simple as that, but the reality of the activities is not that simple. You have to manage the milestone, deliverable, and ensure that when both elements are integrated, it will work well. The result of production is the playable game. In what form? In a form of Formal Details prototype or Refinement prototype.

Formal Details is a playable game which not only include the gameplay and the mechanics, but also the win-lose rule, co-relation between features, and most importantly: run well. It must be playable at least to test the game whether it is functional, complete, and balanced.

Refinement is the most matured prototype which only need several polishing. It’s the refinement over the formal details, complete, playable, and almost ready to ship. However, it needs to be intuitive enough to be played by player.

Testing

As the name implies, testing revolves around the evaluation of the game build. The test is conducted to test the game features, value, concept, design, everything. Everything. Testing is conducted by the internal team members to assess the game features, modules, etc. Near the end, the test is used to assess the game as a whole game. The test need test plan, scenario, and several discussion between fellow developer. Several useful pointers:

• Is the game still buggy?
• Have you ever find yourself stuck and can’t continue the game?
• Is there any sign of exploits/glitch?
• Is the game is too easy/too hard to beat?
• Is there any features that should’ve been there but it isn’t yet?

After the testing is conducted, there will be generated test report which includes all errors and several things which should be omitted, or included. The test result will end up in two different decision: reiterate a new production cycle from new Pre-production then refine the whole game, or advance to the next step, in this context: Beta Testing

Beta

If the Testing conducted by fellow developer, the Beta is conducted by third party, such as publisher, potential buyer, game reviewer, etc. The goal of Beta Testing is to find any bugs lurking in the game and user’s feedback towards current game build. The result is the same, that is test report. The report is used to decide whether to refine again the game (repeat from pre-production) or the game is already fine and ready to ship, so advance to the Release.

Release

Well, what else can be said when a game is ready to ship? This phase is related to game launching, releasing to the appropriate marketplace, and close the project. Creating book of knowledge, project portfolio, and knowledge sharing is important to prepare to a better next project.

The Verdict

It may be not the best way to properly conduct a game development, but I’ve tried and prove that it is applicable and fit for my project in the development of Niew’s Tale for Imagine Cup 2013. Every project has different characteristics and this guidelines might provide you insight on how to develop a game and what are the steps needed to make a game. This proposed GDLC is made due to my research to show the co-relation between software engineering and game development, as there are several challenges when a game development merely use the SDLC.

Sources:

1.	H. M. Chandler, Game Production Handbook, Sudbury: Jones and Bartletts Publishers, 2010.
2.	T. Fullerton, Game Design Workshop – A Playcentric Approach to Creating Innovative Games, 2nd Ed., Burlington: Elsevier, 2008.
3.	E. Adams, Fundamentals of Game Design, 2nd Ed, Berkeley: New Riders, 2009.
4.	Blitz Games Studios, “Project Lifecycle,” 2011. [Online]. Available: http://www.blitzgamesstudios.com/blitz_academy/game_dev/project_lifecycle.
5.	A. Hendrick, “Project Management for Game Development,” 15 June 2009. [Online]. Available: http://mmotidbits.com/2009/06/15/project-management-for-game-development/.
6.	J. McGrath, “The Game Development Lifecycle – A theory for the extension of the Agile project methodology,” 3 April 2011. [Online]. Available: http://blog.dopplerinteractive.com/2011/04/game-development-lifecycle-theory-for.html.