(For more resources related to this topic, see here.)
The basic game design process
The game design process shares many stages with any type of software design; identify what you want the game to do, define how it does it, find someone to program it, then test/ fix the hell out of it until it does what you expect it to do. Let's discuss these stages in a bit more detail. Find an idea.
Unless you are one of the lucky few who start with an idea, sitting there staring at a blank piece of paper trying to force an idea out of your blank slate of a brain, may feel like trying to give birth when you're not pregnant: lots of effort with no payoff.
Getting the right idea can be the hardest part of the entire design process and it usually takes several brainstorming sessions to achieve a good gameplay idea. In case you get stuck and feel like you're pondering too much, we suggest you to stop trying to be creative; go for a walk, watch a movie, read a book, or play a (gasp!) video game! Give the subconscious mind some space to percolate something cool up to the surface.
- Rough concept document: Once you have an idea for a game firmly embedded in your consciousness, it's time to write it down. This sounds simple and at this stage it should be. Write down the highlights of your idea; what is/are the fun parts, how does one win, what gets in the way of winning, how the player overcomes their obstacles to winning, and who you imagine would like to play this game.
- Storyboarding: The best way to test an idea is, well, to test it! Use pen and paper to create storyboards of your game and try to play it out on paper. These can save a lot of (expensive) programming time by eliminating unsuccessful ideas early and by working through interface organization on the cheap.
The goal of storyboarding is to get something on paper that at least somewhat resembles the game you imagine in your head and it can go from very basic sketches, also called wire-frames, to detail schematics in Azure. Either way you should try to capture as many elements in the sketch as possible. The following figure represents the sketch of the double jump mechanic for a mobile platform made by one of the authors:
Once you have concrete proof that your idea is good, invest some time and resources to create a playable demo that focuses on the action(s) the player will do most during the gameplay. It should have nothing extra such as fancy graphics and sound effects. It should include any pertinent actions that rely on the action in question and vice versa, for example if a previous action contributes to the action being tested, include it in the prototype. The question the prototype should answer is: do I still like my initial idea?
While prototyping, it is acceptable to use existing assets scavenged from the net, other projects, and so on. Just be aware of the subtle risks of having the project become inadvertently associated with those assets, especially if they are high quality.
For example, one of the authors was working on a simple (but clever!) real-time strategy game for Game Boy Advance. It was decided to add on a storyline to support the gameplay, which included a cast of characters. Instead of immediately creating original art for these characters, the team used the art from a defunct epic RPG project. The problem was that the quality of this placeholder art was so high (done by a world class fantasy/sci-fi artist) that when it was time to do final art for the game, the art the in-house artist did just wasn't up to the team's expectations. And the project didn't have enough money in the budget to hire the world-renowned artist to do the art for it. So both the team and the client (Nintendo) felt like the art was second rate, even though it was appropriate for the game being made. The project was later cancelled, but not necessarily due to the art.
The following screenshot shows an adventure title prototype made by one of the authors with GameMaker studio by using assets taken from the Zelda saga:
Test it once you have a working prototype, it is time to submit your idea to the public. Get a variety of people in to test your game like crazy. Include team members, former testers (if any), and fresh testers. Have people play often and get initial reactions as well as studied responses and collect all the data you can.
Fix the issues that emerge from those testing sessions and be ready to discard anything that doesn't really fit the gameplay experience you had in mind. This can be a tough decision, especially for an element that the designer/design team have grown attached to. A good rule of thumb is if this element is on its third go around on being fixed; cut it if it doesn't pass. By then it is taking up too much of the project's resources.
Refine the design document as implemented features pass the tests and the test, fix, or discard cycle is repeated on all the main features of your games, take the changes that were implemented during prototyping and update the design document to reflect them.
By the end of this process, you will have a design document, a document that will be what you built for your final product. You can read an interesting article on Gamasutra about the layout of one such document, intended for a mobile team of developers at http://www.gamasutra.com/blogs/JasonBakker/20090604/84211/A_GDD_Template_for_the_Indie_Developer.php.
Please note that this does not mean there won't be more changes! Hopefully it means there won't be any major changes, but be prepared for plenty of minor ones.
End the preproduction once you have a clear idea of what your gameplay will be and a detailed document about what needs to be done, it is time to approach game production by creating the programming, graphics, audio, and interface of your game. As one works towards realization of the final product, continue using the evaluation procedures implemented during the prototyping process. Continually ask "is this fun for my target audience?" and don't fall into the trap of "well that's how I've always done that". Constantly question the design, and/or its implementation. If it's fun, leave it alone. If not, change it, no matter how late it is in the development process. Remember, you only have one chance to make a good first impression.
When is the design really done? By now you have reached the realization that a project is never complete, you're simply done with it. No doubt you have many things you'd like to change, remove, or add but you've run out of time, money, or both. Make sure all those good ideas are recorded somewhere. It is a good idea to gather the team after release, and over snacks and refreshments capture what the team members would change. This is good for team morale as well as a good practice to follow.
Mobile design constraints
There are a few less obvious design considerations, based on the player's play behavior with a mobile device. What are the circumstances that players use mobile devices to play games? Usually they are waiting for something else to happen: waiting to board the bus, waiting to get off the bus, waiting in line, waiting in the waiting room, and so on. This affects several aspects of game design, as we will show in the following sections.
The most obvious design limitation is play time. The player should have a satisfying play experience in three minutes or less. A satisfying play experience usually means accomplishing a goal within the context of the game. A good point of reference is reaching a save game point. If save game points are placed about two and a half minutes of an average game player's ability apart, the average game player will never lose more than a couple of minutes of progress.
For example, let's say an average player is waiting for a bus. She plays for three minutes and hits a save game point. The bus comes one minute later so the player stops playing and loses one minute of game progress (assuming there is no pause feature).
Generally speaking, mobile games tend not to have much longevity, when compared to titles, such as Dragon Age or Fallout 3. There are several reasons for this, the most obvious one being the (usually) simple mechanics mobile games are built around.
We don't mean that players cannot play Fruit Ninja or Angry Birds for a total of 60 hours or so, but it's not very likely that the average casual player will spend even 10 hours to unfold the story that may be told in a mobile game. At five hours of total gameplay, the player must in fact complete 120 two and a half minute save games. At 50 hours of the total gameplay, the player must complete 1200 two and a half minute save games. Are you sure your gameplay is sustainable over 1200 save game points?
Mobile games are frequently played outdoors, in crowded, noisy, and even "shifting" or "scuffling" environments. Such factors must be considered while designing a mobile game.
Does direct sunlight prevent players from understanding what's happening on the screen? Does a barking dog prevent the players from listening to important game instructions? Does the gameplay require control finesse and pixel precision to perform actions?
If the answer to any of these questions is yes, you should iterate a little more around your design because these are all factors which could sink the success of your product.
Smartphones are still phones, after all. It is thus necessary that mobile games can handle unexpected events, which may occur while playing on your phone: incoming calls and messages, automatic updates, automatic power management utilities that activate alarms.
You surely don't want your players to lose their progress due to an incoming call. Pause and auto-save features are thus mandatory design requirements of any successful mobile game.
Single player versus multiplayer
Multiplayer is generally much more fun than single player, no question. But how can you set up a multiplayer game in a two and half minute window? For popular multiplayer titles it is possible. Thanks to a turn-based, asynchronous play model where one player submits a move in the two and half minute window and then responds to the player's move. Very popular titles like Ruzzle, Hero Academy, or Skulls of the Shogun game system do that, but keep in mind that to support asynchronous gameplay it requires servers, which cost money and complex networking routines to be programmed. Are these extra difficulties worth their costs?
The mobile market
The success of any commercial project cannot arise with disregard to its reference market, and mobile games don't make exception.
We the authors, believe that if you are reading this article, you are aware that the mobile market is evolving rapidly. The Newzoo market research for the games industry trends report for 2012 states that there are more than 500 million mobile gamers in the world and around 175 million gamers pay for games and that the mobile market was worth 9 billion dollars in 2012 (source: http://www.newzoo.com/insights/placing-mobile-games-in-perspective-of-the-total-games-market-free-mobile-trend-report/).
The following screenshot represents the numbers of the mobile gaming market 2012 reported by Newzoo:
As Juniper Research, a market intelligence firm, states, "smartphones and tablets are going to be primary devices for gamers to make in-app purchases in the future. Juniper projects 64.1 billion downloads of game apps to mobile devices in 2017, compared to the 21 billion downloaded in 2012." (source: http://www.gamesindustry.biz/articles/2013-04-30-mobile-to-be-primary-hardware-for-gaming-by-2016 ). Even handheld consoles, such as the 3DS by Nintendo or the PSVita by PlayStation are suffering from the competition of mobile phones and tablets, thanks to the improvements on mobile hardware and the quality of games. With regard to market share, a study by Strategy Analytics (source: http://www.strategyanalytics.com/default.aspx?mod=reportabstractviewer&a0=8437) shows that Android is the leading platform in Q1 2013, with 64 percent of all handheld sales. Japan being the only market where iOS is on the lead; though, as Apple is fond of pointing out, iOS users generally spend more money, when compared to Android estimators.
All the data tell us that the positive trend in mobile devices growth will continue for several years and that with almost one billion mobile devices in the world, the mobile market cannot be ignored by game developers. Android is growing faster than Apple, but Apple is still the most lucrative market for mobile apps and games. Microsoft phones and tablets, on the other hand, didn't show positive trends as to be compared with iOS and Android growth.
So the question is how can an indie team enter this market and have a chance of success?
In this article we discussed best practices for designing mobile games that can have chances to emerge in the highly competitive mobile market. We discussed the factors that come into play while designing games for the mobile platform, with regards to hardware and design limitations to the mobile market characteristics and the most successful mobile business models.
Resources for Article :
- Unity Game Development: Welcome to the 3D world [Article]
- So, what is Spring for Android? [Article]
- Interface Designing for Games in iOS [Article]