Home > iPhone, iPad, iPod touch, Software Architecture > Tutorials and Game Development

Tutorials and Game Development

October 29th, 2010

Tutorials or training modes in games are useful for players to learn your game. The simplest games might be discarded by players because they cannot figure out how to play the game. This blog entry is based on my own experience in this matter. I will describe how I have done it so far and how I plan to do it in future game development.

Games developers coming from a business application area will know, that there are some fundamental differences in developing games instead of a business apps. The business app tries to solve a business case, where the program typically processes data and presents it to the user after some processing. A game is all about the user, here called player. Business apps need to be mathematically correct, whereas games might not even use correct physics. So, business apps are helping a user to solve a problem. Games are made to entertain the player, much like a movie.

Many developers begin to craft a game by making the main part first. Afterward, they add some intro and end-game scene. Based on my experience, this is wrong. The main part of the game will often appear detached from the rest of the game in the described case. The player will thus get a feeling of an unfinished or lower quality game. Furthermore, the developer will quite often find it difficult to add the missing parts, once the main part of the game is done.

When doing business software, I often tell developers to make the simplest implementation through all layers. I call this a feature bullet. You will avoid ending up with two parts of the system not being able to communicate (integration problems). Also a typical case is when something in the last steps fails due to technically impossibilities. By using the feature bullet you reduce the risk of failure, the risk of producing code-waste and you have a way to try out the feature earlier.

The feature bullet is also applicable for game development when you take the whole game and create the simplest possible playable prototype. This will typically include the tutorial part, because you want to distribute this to someone else in order to get his opinion.

So far I have discussed the game dynamics. Let us now look at the architecture and the way to integrate the game parts, especially the tutorial.

The best similarity between the tutorial and other concepts in application development is test driven development (unit and integration tests). Look at the tutorial part as a reference implementation of the entire game. Write the tutorial first and keep it updated while you extends the game with more features. You will always have an up-to-date tutorial for the current state of the game and you can at any time ship it to the beta testers, even though you are missing the uber-cool monster in level 516.

The implementation itself relies on your methods and algorithms to be scalable and configurable. In case you made the main game part as the first one, it is most likely, that the methods lack these attributes. A tutorial should be a scaled-down version of the main game in order to introduce the player to the main concepts. As a simple example you can imagine a puzzle game. It uses X by Y tiles and the goal of the game is for the player to re-arrange the tiles. Let us assume, that you hard-coded the game to use 20 by 20 tiles. This is too complicated for a novice player. A 5 by 5 tile game could just as well serve the purpose to explain the game. As a live demonstration of this you can take a look at the free iPad/iPhone game Lupus.

The principal idea of this blog entry is to use the tutorial part as a test tool for yourself and as an introduction for players. You want to work against a goal and the tutorial part keeps you on track. The game must provide a coherent and easy way to interact with it. Use the tutorial part as a proof-of-concept to test out new features before spending weeks on development. Building your game in parts and not using the feature bullet approach will let you end up with your architecture dominating the user experience. It is one of the principal patterns in GUI development to avoid that. Use the tutorial part to guide your game architecture.

Comments are closed.