Game Design for Beginners: Droid Runner
Developing a video game is generally a collaborative effort among a group of people. There are usually artists, designers, programmers, and production staff involved from the beginning of the game development cycle right through to the end. It’s also possible that you will be pitching your ideas to a third party, possibly a platform holder or a publisher, to acquire funding or marketing support for your title.
In all of these scenarios, it is vitally important that you have good lines of communication among staff members to ensure that production of your title goes to plan. The central focus of this communication in the initial stages of development is the game design document.
As the document is such a key pillar in the development of a game, we will dive into looking at how we can write our own before we look at writing our code.
An Introduction to Design Documents
Design documents serve a few different purposes. First and foremost, they contain a functional specification of the game. This functional specification details the game world, mechanics, and gameplay systems from the point of view of the user. It helps determine how the game will play and how different parts of the game come together to create the user experience.
The second purpose of the design document is the technical specification. The technical design section will describe in more detail how certain aspects of the game will be implemented. This will be useful when it comes to implementing the game as it can provide a high-level overview of how the different systems will interface with each other. It’s also essential to have at least a rough spec to help with scheduling development. An attempt at creating an accurate schedule is vitally important if you’re developing your game in a commercial environment with a limited amount of time and budget.
It’s not uncommon for there to be multiple documents containing different aspects of the design but for our small game, a single document will be good enough. The first required section is the overview.
Creating a World, Telling a Story, and Setting the Scene
Every game needs to tell a story. This story, however detailed, helps to create a sense of urgency and empathy within the player and can turn a collection of mechanics into a compelling experience. Even the earliest successful games managed to tell a story: Donkey Kong was released by Nintendo in 1981 and told the story of Jumpman trying to save the Princess from the giant ape. Pac-Man’s story is in the relationship between the player and the AI. Each of the four ghosts try to catch Pac-Man in their own way up until the point where the player collects a power pellet, the tables are turned, and the ghosts then run away from Pac-Man. The power of storytelling is evident in the fact that the developers even gave the ghosts unique names: Blinky, Pinky, Inky and Clyde.
Modern games are becoming more and more story driven as the technology used to play games advances. Home console and PC games are now commonly written by writers who have been involved with Hollywood movies. Games for mobile platforms such as Android have already been written and developed in a similar fashion at the larger game publishers, and while this is out of the reach of most small developers, a sense of story and journey is still important.
Our back story will be covered in the overview, and we don’t really need to add any more for our simple game. What we should do is keep our story in mind and ensure that everything we add to the game is in keeping with the narrow theme we wish to portray. For our game, that’s a theme of trying to escape from a place where we’re held captive and have little power.
The Droid Runner Design Overview
In the following sections, we’ll cover the different sections of our game design document. This example covers the minimum number of sections which we need to fully describe our game to others. There is not a hard set of rules which you can follow when laying out your game design. This makes some sense, as each game is different and no two documents could possibly contain the same information and also describe completely different designs for games. We’ll begin by looking at the game overview.
Section 1 - Game Overview
Droid Runner is a side scrolling game where the player automatically moves from left to right on the screen. The main character in the game is Droid, a green android who is trying to escape from an environment where he is utilized as a tool. The red security droids patrolling the environment will prevent Droid from leaving if they manage to catch him. The environment contains different obstacles which Droid must overcome to reach the exit.
The short overview above sets the basic scene for Droid Runner. It helps lay out who the player is and the antagonists who are trying to prevent the player from achieving their goal. As we’re creating our first game using a new platform, this is an adequate overview of the game we will be aiming to create. The following sections will cover the details of the gameplay.
Defining the Gameplay and Mechanics
The gameplay section of the design document should cover a description of the actions which the player will be carrying out during the game. This section is split between a high-level overview of the gameplay structure as well as a more detailed analysis of the game mechanics which will be used to create the high-level experience. More complicated games will have a description of different levels in which the game will take place, and for games with role-playing elements, a description of the skill system would also be found here.
Section 2 - Gameplay and Mechanics
Section 2.1 - Gameplay
A level will progress from left to right and have no vertical movement. As the camera moves along, the player will be exposed to enemy characters as well as obstacles which he must avoid. The core fun experience of the game will be created by designing levels which position enemies and obstacles in a manner which presents the player with a challenge which increases in difficulty as the player progresses through the level.
The player will complete the level by reaching the goal area at the far right extremity of the level.
The game over scenario will be triggered by the player coming into contact with an obstacle or an enemy droid.
Section 2.2 - Mechanics
Section 2.2.1 - Movement
The player will move automatically from left to right. The speed at which the player moves will be tuned to an appropriate velocity to ensure that a challenge is presented by the positioning of obstacles and enemies which is neither too easy nor too difficult.
The player will be able to jump at a height which represents 33% of the height of the level. The upward and downward velocity will be symmetrical as to provide a consistent and predictable jumping behavior. There will be no delay between landing a jump and starting another as the gameplay relies on responsive controls and timing to create a sense of tension and fun. The velocity of the jump should slow around the peak to create an area of floating to allow the player some ability to preemptively jump over obstacles and utilize timing to their advantage.
Section 2.2.2 - Obstacles
Crates - The level will contain stacked crates which the player must jump over or onto. Crates will be square, and obstacles will be created by placing crates side by side or one on top of another. All crates will have equal dimensions with the sides being equal to 25% of the height of the screen. This will allow the player to be able to comfortably clear the crates with their 33% jump height.
Enemies - The level will contain enemy droids which will be following a set path between two points. These paths will be linear, either vertically or horizontally. Horizontal paths should cover no more than 75% of the visible width of the screen at 720p. Vertical paths can cover the entire height of the level. Enemies will move at a speed which is slightly slower than the player’s horizontal velocity. This will allow the player to move past enemies and only be concerned with new enemies coming from the right.
Section 2.2.3 - Pickups
The player will be able to pick up an invincibility pickup which allows them to pass through obstacles and enemy players without triggering the game-over scenario.
A lot of developers who are new to making games look for a perfect set of rules on how to construct levels. From my experience, such a set of rules doesn’t exist. If such a set of rules did exist, we may end up in a situation where the levels of different games become very similar as they are designed from the same formula but those levels may not fit in with the game which is being developed. This is the crux of why I feel there are no hard-and-fast rules on level design: every game strives to have slightly different mechanics and therefore slightly different design considerations. What do exist are some tenets of level design which can be considered when designing a level for a game.
Pacing
The first tenet of level design, I believe, is pacing. When constructing a full game across multiple levels, it’s important to consider how often you introduce new gameplay mechanics and then build the use of these mechanics into the world.
The Legend of Zelda games provide a classic blueprint of ramping difficulty through their games using pacing. A new weapon is introduced and there will be a small task which is required to be completed with the new ability provided by the weapon to instruct the player on how it can be used. There will then be a boss encounter which requires the new ability to complete the dungeon and advance in the story. The player will then be able to access new areas of the map in the outer world which were previously inaccessible and, more often than not, more difficult than the areas which had come before.
Games can also use pacing of intensity to create engagement for the player. High intensity levels for sustained periods of time may cause players to become stressed. If this stress is perceived as difficulty then many players will feel overwhelmed and decide to stop playing the game. What you should strive for is variations in the pacing to create a sense of interest. Periods of high intensity with lots happening and high levels of engagement for the player should be followed by relative calm. This will give the player a chance to recover and regain some composure. In the beginning, a game can have longer periods of calm with short bursts of high intensity, and the opposite closer to the end once the player is experienced and requires a higher level of challenge.
We will attempt to use the complexity of the obstacles and placement of the AI characters in our level to alternate between periods in which the player will be required to tap on the screen in rapid succession to clear areas and periods of lower levels of input, which will denote calm. Towards the end of the level, the periods of relative calm may be as intense as the areas of high intensity from earlier in the level, but the player should be more experienced and therefore less stressed by the level of these areas towards the end of the level.
Aesthetics
The aesthetics of a level are vitally important in conveying the setting and theme to the player. If an area of a game is to feel intense for a player, depending on the type of game, the aesthetics will help to convey that sense of intensity if they are done properly.
Aesthetics can also be used to lead a player through a level. Generally, the path the designer wants a player to take through the level will be lit using bright lights at key points. If you ever find yourself lost in a first-person shooter such as Halo 4, take a while to stand still and look around for any path openings or doors which look like they may be lit more brightly or with different colors to the rest; there’s a reasonable chance that this is the way you should go. Placing secrets in darker areas also makes them less likely to be found by players who are subconsciously following the directed path and therefore warrant the reward offered to those exploring off the beaten track.
Scale
The scale of a level is important in determining how long it will take to build. Everyone would like a game of unlimited scope. RPGs such as Skyrim are heralded for their scale. Scale does not come for free and the scope of your game will be intrinsically linked to the scale of your levels and vice versa.
Larger levels generally require a large number of game mechanics to ensure that they remain compelling to play. A large level will quickly become repetitive and boring to a player if it requires them to repeat the exact same challenges over and over. Levels which are also small for the number of available mechanics may also mean that the player may not get to use some of the most compelling features which they are being offered, damaging the perceived quality of the title.
The scale of the level is also impacted by the target hardware which the game is intended for. A PC game can make use of several gigabytes of RAM and can store very large data sets for levels in memory all at once. A Playstation 3, on the other hand has only 256MB of system memory and can therefore store data only for much smaller levels and the objects contained within. Issues such as these will be reliant upon the technical requirements we look at in the next section.
The technical requirements document details the engineering specs of the low-level systems which will be used to create the game. This documentation will rarely contain implementation details but will instead give an overview of how such a system should work, algorithms to be used, and the interfaces which will allow different systems to communicate.
There are a couple of important reasons for writing a requirements document. This first is for team communication, which is relevant even if you’re developing a game on your own to communicate with your future self about how you envisioned the system integrates with other systems in the framework.
Another is for scheduling. With experience, you’ll begin to learn how much effort will be required to implement a given system while writing the requirements document. This in turn will lead to better budgeting and planning, an important aspect of building games which are commercially successful.
The technical requirements of a given system should define the interface which the system will expose to the outside world. Taking the time to design the interface will allow you to understand how data will flow into and out of the system and will help identify any areas of high coupling and low cohesion. Identifying areas where these properties exist at design time can help to avoid costly refactoring once development has already begun.
The Unified Modeling Language was created in the 1990s to help technical writers visualize their object-oriented designs. Some software has been written to aid in the construction of the models of your system, and the example in Figure 3-1 was created using ArgoUML. The design is for the Kernel and Task system, which we will be using to create our game loop a little later in the book.
Figure 3-1. The Kernel UML Class Diagram
The technical documentation can contain as much or as little documentation as you feel is necessary; however, it is important to note that it is generally accepted that the more time spent planning means less time spent implementing. Implementing systems is usually the process in software development which takes the most time and costs the most money, so anything which can help reduce this period is welcome. It isn’t necessary to write all of the documentation before beginning any development. Using a development methodology such as Agile can mean that the documentation is filled out as you go; however, it is still a good idea to plan some work in advance to be sure that system interfaces will be adequate for the job at hand.
Writing good documentation comes with experience and at this point we have little experience with the Android system. It would be a good exercise for you to write some tech docs for the systems which we will be implementing as we move through the following chapters. Writing technical documentation can be a daunting prospect and a difficult task to undertake. A selection of example documents is available via the web site along with the source code for the samples used throughout this book.
Summary
This chapter has taken a look at the design document which is produced during what is commonly referred to as pre-production. This is the stage of development where prototypes are created, brainstorming sessions take place, and the look and feel of the game are thrashed out.
We’ve seen that it’s useful to split the design into two discrete sections; one covering the gameplay, logic, and story and another covering the technology which will be used to create the vision. The remainder of this book will look at both of these sections simultaneously moving forward. We’ll do this by looking at building games from the ground up, starting with creating a game loop, communicating with the Android OS, then initializing OpenGL before moving onto more game logic–focused code from Section 2 onwards.
We will begin in the next chapter by tackling the creation of a task-based game loop and encapsulating the Android native app glue event polling into a task.