Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
December 13, 2018
arrowPress Releases






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

A bit of design theory for mobile games

by Christopher Walden on 10/29/14 01:59:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Not every app has had hours of time dedicated to its design experience. Unfortunately for other developers, it leaves a bad impression of apps as a whole. There are examples of weird, convoluted menu designs and over-explained core game mechanics on every app store, and there’s a good chance that you’ve downloaded an app only to find yourself stumped at how to access a particular function. This is bad design.

Video games have an advantage when it comes to conveying game mechanics. It has become accepted to use in-game dialogue to teach players how to perform certain actions. This can happen every time a new mechanic is introduced, sometimes breaking immersion by halting the game and surfacing a tutorial. Teaching players in-game and not in a tutorial section is a practice that was only accepted after video games made the leap to 3D. However, just because they are accepted doesn’t mean that it’s the ideal scenario. It’s very lazy to do this without good reason, as you can improve your game by building the tutorials into gameplay without having to spell them out.

A classic example of this can be seen in the first level of Super Mario Bros. This was in a time where there were no button configuration menus, and the game certainly wasn’t going to waste time telling you how to use a controller with eight buttons on it. Granted, it had an instruction booklet, but they couldn’t rely on every player reading that. The first level had to be designed with this in mind, to make sure players started to learn how the game was played.

The example comes in the form of a Goomba, the iconic mushroom-like enemy. It’s the first enemy you see when you start the level, and it slowly moves towards the left, in your direction. If the player doesn’t move Mario out of the way, they will lose a life. Even if the player lets this happen the first time, they now have the knowledge that being hit by a Goomba is bad, and they can begin to explore other options.

With there being only two face buttons that are not used for movement or pausing the game, there can be only two options. Players will quickly discover that the only available option is to jump. Pressing the ‘a’ button will make Mario jump, and it’s from here that the player will be able to avoid the Goomba and start navigating the level. It’s only a matter of time until they try to jump on enemies to defeat them, and later on Spinies, turtle-like enemies with spiky backs, will teach players that some enemies cannot be jumped on to defeat them.

This whole process is implied. Not once does the game need to tell you explicitly what to do. Neither does it just simply expect the player to figure it out. The clever thing about the design, especially in retro games like this, is that the levels are specifically designed to teach the player without having to explain anything. This is becoming a lost art, with many games resorting to dialogue windows to explain how the game works.

You might be wondering what the problem is. I mean, why bother changing it if it has become acceptable to do it that way? The problem is that each and every dialogue box is another barrier that you are putting up in your game, and each one carries the risk of your user just giving up before even getting to the game. That’s not to say that games cannot have dialogue boxes at all, and some games certainly wouldn’t be playable without them, but designers need to be checking every time they are used to work out whether it’s necessary or not. Players don’t need to be treated like idiots!

For a modern gaming example of how to do this correctly, you can look at Rovio’s Angry Birds. Love it or hate it, this game makes some great design choices. First of all, the menu is incredibly simple, and the graphics used on the level select screen make it easy for all players to understand what their progress looks like. There’s no explanation as to what stars are, or that you need to beat the previous level to unlock the next one, but both of these things are implied in the design. When you unlock a new type of bird, you get to see a single, word-less graphic that replaces any form of tutorial, simply instructing you how to play the game and what the bird’s power is. You could even argue that this is unnecessary, but it’s unobtrusive enough to not matter in this case. A simple picture like this has so many advantages. For instance, written tutorials will alienate every player that doesn’t speak your language, or at best, increase your localisation costs. You also alienate children who might not be able to read or read well. Some people won’t use the tutorial if it’s a separate option in the menu, and others will drop out of the game if you force it on them.

Conveying the rules of the game also extends to general gameplay. The oversized slingshot is perfect for giving players an idea of how to play the game, and the physics demonstrate the remainder of the game after you’ve launched a bird. It’s also important to mention the decision to use a slingshot is extremely smart and quite understated in its importance. For example, if the birds were launched out of a cannon, how would you operate that in-game? Do you change the height of the shot by moving the front of the cannon? Do you fire by tapping on it? Can you make the bird go further by holding your finger down? These are things that can be explained in a long-winded and boring tutorial, but it would be a tough task to communicate this in a single image like they currently do.

How else would you launch a bird? A trebuchet perhaps? Catapult? These are all options that fall down at the same point as the cannon idea. The slingshot is a great idea because you know that they are operated by pulling back on the elastic. You know that pulling back further will increase the power of the shot, and you know that pulling down on the elastic will cause the missile to rise higher. These are concepts that we are familiar with aside from anything Angry Birds tells us, which makes it perfect for use in-game. The same also applies to the different materials protecting the pigs, which are represented by glass, wood and stone. It’s easy to know with a quick glance which will be easiest to break.

The great thing about game development is that we can learn from the past mistakes and successes of other companies. Look at your game, looks at your game rules and make sure that players know what to do without instruction. If they don’t, look at why that is and if there’s anything you can do to make it more obvious. On a final note, there’s a popular video by Youtuber Egoraptor that goes into detail about ditching tutorials and how you can make levels more intuitive, so be sure to give that a watch. A warning though, it does contain a lot of expletives!

Menus can also be a problem from a design standpoint. Many developers will just throw in options as and when features are added to their app, without much thought on the user journey. A good way to optimise your in-game menus is to look at traditional website site maps. Site maps list every webpage under the domain, making it easy to find what pages exist and, in some case, the hierarchy of how to navigate to them. It’s not the site map itself that is important, but rather the practice of not having buried web pages that is important. Just as you shouldn’t have to click more than two times to get to the content you want to view on a website, you shouldn’t have to go through this many options or menus before getting into a game, without good reason. Even if these options are correctly surfaced, you must also limit the number of steps required for a user to do what it is they want to do. If it takes three or more steps to get to the option they need, seriously consider whether any of these steps can be removed by improving the UI. Make sure that your users agree with you.

It’s also worth taking a look at the Super Smash Bros. for 3DS menu system. It’s unconventional in design, however it takes a rather unique approach for a video game in that it ‘weights’ particular menu options. Game modes that are more likely to be played, such as the ‘Smash’ versus, appear larger on the menu screen. Options like Streetpass and Wii U connectivity are smaller as they are not used as regularly, and every option is a unique shape and colour. This makes it even easier for players to associate the different buttons with the various game modes and therefore navigate menus quicker. Being in the menu for less time also increases the time in-game, which is the ultimate end goal for video games. This is especially so if you want to sell additional content to your users via in-app purchases or expansions, so be sure to consider what you can do before making a traditional bullet-list menu.

At all times you must be looking from the perspective of the user, and whether the feature you want to add is going to make things worse for them. For example, if you have a podcast app, you can ask them where to go to subscribe to a podcast. Where do you go to unsubscribe? Where do you go to allow the app to automatically download new podcasts? This is simple testing, but the information you receive as a result will be incredibly useful. Timing users, and seeing if/when people get lost looking for something should point you towards possible areas to improve with better design. This is all with the aim of making your app a great experience, and not a frustrating one. The testing must come from outside the development team, because you’ll be working too closely to the project to give unbiased answers. Find some friends that will speak honestly, or look online for people willing to help out if you’re on a tight budget. If you’ve got some money to spend, there are many user testing companies that are available for good prices.

You can see the importance of menus and their positioning in the game Puzzix. It’s a very well received game overall, but there was a complaint brought up about the menu design in episode thirteen of the Isometric podcast. The menu is opened by tapping on the settings button, which appears in the bottom left of the screen at all times. However, different options appear depending on whether it is accessed from in-game or from the title menu.

The problem stems largely from muscle memory and inattentiveness, things that aren’t often considered when it comes to design. In the case of Puzzix, leaving an active game requires you to select Save and Exit, the third option from the menu. However, while on the main menu this option becomes New Game, and if you aren’t paying attention to the warning menu that pops up afterwards, you could end up deleting your save data. To be clear, this is an unlikely scenario as you’re usually going to want to use the Continue button while on the main menu and not touch the options button, but as evidenced by the podcast, it’s happened to at least one person. That’s one person too many.

Design theory is a huge subject, but it’s something that will naturally come while playing and breaking down other games. If you take a critical eye to modern games and see what they’ve done well and what they haven’t, you can apply these to your own games. With a bit of thought and some testing, you can make your game a much nicer experience for everyone.


Related Jobs

Deep Silver FISHLABS
Deep Silver FISHLABS — Hamburg, Germany
[12.12.18]

Senior Producer (f/m)
Deep Silver FISHLABS
Deep Silver FISHLABS — Hamburg, Germany
[12.12.18]

Level Artist (m/f)
Deep Silver FISHLABS
Deep Silver FISHLABS — Hamburg, Germany
[12.12.18]

Level Designer (m/f)
Deep Silver FISHLABS
Deep Silver FISHLABS — Hamburg, Germany
[12.12.18]

Senior 3D Artist (m/f)





Loading Comments

loader image