9 stages in mobile game development

This post has been written and contributed by Ilya Dulskiy, Unity Developer / Game Designer

We are starting a new category on our blog related to mobile game development.

In this blog post, we will talk about what it takes to develop a mobile game from scratch. Each game development project, on average, has 9 distinct phases which are described in a bit more detail below:

1. Come up with a game idea

An idea is the first thing that comes to mind when a game is being described. However, the idea is not complete until it can answer the following questions:

• Who is our player?
• Why would a player want to play our game? What players’ needs does the game solve?
• What kind of experience do we want the player to have? What is essential to that experience?
• Is the game fun? What parts of it are fun?
• What will surprise players when they play our game? What kind of surprises will we have through the game?
• What is valuable in the game? How does the value correspond to inner motivations of the player?
• What kind of problem solving does the game involve?

2. Develop the concept

A game concept is a brief document containing a quick game overview and basic representation of four building blocks of every game.

• Game Mechanics. Mechanics, the ruleset of the game, describe the steps a player takes to achieve the goals of the game. The mechanics of a chess game, for example, include the description of the board, the starting position and list of moves each figure can take. Of course it will also include the winning condition.
• Setting. The setting encapsulates two important parts: story and aesthetics. The story describes the game world, events that had happened before and events happening during the gameplay. The aesthetics is about how your game looks and sounds. Both parts of the settings are closely tied together. Both of them are extremely important to the user experience. The story could be omitted for some abstract games.
• Technology. What are the target devices? What kind of middleware are we going to use to create the game? What programming language is the best choice for our target platform? How much performance do we actually need, considering the chosen aesthetics? The choice of tech is finding a fragile balance between having an easy to write + supportable code and having enough performance on target devices. The first is usually completed by writing a highly abstract code. Unfortunately, abstraction layers may sometimes be heavy on performance.
• Interaction. How do users interact with the game? How are we going to use advantages of the device and chosen input methods? How do we utilize screen space? This part is extremely important when mobile devices are taken into consideration.

3. Develop the proof of concept

Some parts of the concept document need to be verified as soon as possible. For example:

• Will the tech handle the task? To check this you need to create a quick and dirty implementation of critical features. If you are creating an Augmented Reality Shooter for mobile devices, for example,  you need to be sure that the navigation accuracy is good enough for the task.
• How does your setting appeal to the target audience? Are your artists skilled or gifted enough to pull the style through? There is a reason there are so many 8-bit style games on the market, and not all of them have anything to do with the nostalgia.
• Is the gameplay engaging enough? Most of the games could be reduced to paper / board game prototype and still work. In fact, if your game isn’t physics-based, but fails as a paper prototype it’s a good indication that it will fail after being coded.
• What about the chosen controls? Do they work? Are they intuitive enough?Loads of games are extremely demanding to the controls and failing them means failing the entire game.

4. Create a game design document (GDD)

A game design document is a highly descriptive and detailed document of the design for a game. A GDD is a living document, which means it’s prone to feedback. Every time the requirements change, a GDD should change.  Usually, a GDD is created and edited collaboratively by developers and designers and used to organize the efforts within the team.

Unlike the high-level concept document, the GDD includes the underlying details of realization.

For example, the mechanics description of Commandos game in the concept document may sound like “The goal of the game is to infiltrate the enemy bases using a small squad of highly-skilled troops. Due to the disparity in numbers and firepower, the stealth approach is expected. Most of the time a player will spend learning the patrol routes and watchmen positions, occasionally performing swift and precise actions to take down unsuspecting enemies,” while the GDD will include the detailed description of all enemy types, their health, movement speed, behaviors (patrolling, sounding alarm, shooting etc) and their triggers, weapons, armor, field of view etc.

In addition to describing the game, the GDD should also describe a player. Who is he? What does he do for a living? What are his hobbies? What are his drives? How old is he? Where does he come from? How much money does he make? Games that are targeting too wide audiences often lack distinctive features and may appear too shallow and not catchy enough to everyone.

5. Create prototypes

While most of the mechanics are already tested during the PoC phase, it is important to create a playable prototype for your target platform. A prototype should include most of the important mechanics and resemble substantial parts of the game.

For a game like Commandos, the prototype would be a simplified game engine  (one level with a placeholder art, one kind of highly-functional enemies and two commandos under player control). While this kind of an early prototype may take some time to create, it is still crucial to have it to determine some mistakes in the game design. Often players behave completely different to the designers’ expectations, controls appear to be non-intuitive and some technical tasks are too hard to solve. Sometimes unexpected player behavior may even lead to the new ideas which can be more fun than the original ones. Most of the issues are easy to solve while this early in the development and it is important  to remember that the cost of the prototype is only a fraction of the late project pivot cost.

6. Design architecture

Most of the game functions and scenarios evolve during the development stage. Hardly any game in the world looks and behaves like it was initially described in the GDD. New ideas arise, the technology changes and so does the project. Ever-changing nature of game development requires very flexible architectural solutions based on the modular approach. Creating this kind of architecture design may be a hard task, but it is the most important phase in the game development process. The team of mediocre developers won’t have problems joining the dev team if a great architectural solution is already in place and presented to them, but even the best developers will struggle with a poor architecture framework.

7. Development

With the architecture already designed and prototypes created, the team should have no problems with the actual development. Due to above mentioned volatile requirements of the games, agile methodology should be used. Creating a Minimum Viable Product as soon as possible is also important for the team motivation and involvement of a QA into the process. Required tools should be created / bought at the highest priority. Having shared solutions for typical tasks is important for writing the supportable code. An early availability of the tools means that the game designers and artists will start working on the game configuration (like balance, lights, particles etc) as soon as possible.

8. Test the game

As soon as the first playable versions are available, QAs and beta testers should join the team. When testing is in place, some teams prefer to work using tik-tok methodology, alternating between new feature development and bug fixing sprints. Delaying all the bug fixes is extremely ineffective and dangerous: it reduces the effectiveness of testing and may lead to accumulation of hard to solve problems.

When a release is approaching, the alpha and beta testing phases are required. During the alpha testing, the unfinished game is exposed to a narrow range of potential players to get the feedback about the gameplay and behavior of the game in the wild on a wide range of devices. During the beta-test there should be no critical errors, most of the content should be already in the game. This phase is mostly used to test the performance and make final fixes and balance small tweaks. Adding new features is highly unlikely during the beta testing stage.

9. Support the game

For most mobile and web projects, a release is just the start of the long road. To achieve a continual growth of the user base and high retention rates, the game updates are critical! The analysis of the modern hit games suggests that the updates should be released every two-five weeks and every other update should add more content to the game.

Can you share your game development experience? How many stages does a game development project need to go through in your opinion? Please share your comments below.