Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Lost Along The Way: Design Pitfalls on the Road from Concept to Completion
View All     RSS
June 17, 2019
arrowPress Releases
June 17, 2019
Games Press
View All     RSS

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


Lost Along The Way: Design Pitfalls on the Road from Concept to Completion

April 12, 2002 Article Start Previous Page 4 of 4

Losing the Player: Obstacles to Enjoying the Title

So now, hopefully, you've caught the eye of the potential purchaser. (Of course, you knew something about that buyer all along, because he's part of an audience that you identified long ago.) That's a step in the right direction, but the look and the hook aren't going to bring everyone into your market, and they aren't going to keep people loyal once they're playing. Most of the buyers out there (retailers and their customers) will look a lot more carefully once they've picked up the box, and many of these will try before buying. These players are going to be concerned not only with the look of the game, but also with the feel of the game. If a game's design loses the player, then it's likely to come right back to the store - or never to leave the shelves in the first place.

Losing the player happens first and foremost through the game's interface. Whatever the title, the purpose of an entertainment product in any industry is to transport the participant to a place either slightly or entirely outside of his realm of experience and to keep him there engagingly throughout the experience. Without a functional set of tools, the player is prevented from ever achieving that suspension of disbelief or - even worse, in my opinion - continually reminded of his interaction with the product, rather than immersed in the game itself.

The problem of interface is usually a matter of too many controls (making a game very difficult to get into) or an interface that is too intrusive (making a game very easy to leave). This is not to say that a game can't have lots of controls. As I mentioned before, Longbow, had functions for almost every key on the keyboard. Not only did the game's design take into account the target market, but it also helped the individual player to learn the game with a clear tutorial, plenty of practice missions, and clear documentation. When they could learn to enjoy the game at the right pace, players could appreciate the realism of the simulation. Mastering the controls just like a pilot became a reward to players, rather than an obstacle.

The faster a player can start up a game and get into the action, the more likely it is that he will want to keep playing it. Diablo is an excellent example of controls that appealed to a wider market. Anyone who was familiar with Windows at the time of the game's release could readily understand the game controls. The point and click interface was intuitive and accessible, and Diablo reached a huge market because of this. Myst is another good example: not only did it satisfy the visual requirements that I spoke of earlier, but it was incredibly easy to play, and anyone - with or without any history of playing games - could quickly start the game and launch into the story. Whether or not it appeals to you as a gamer, its sales certainly speak volumes as to what you can do right as a game designer. Even better for their developers, both of these games translated readily to console play, because there weren't a lot of controls to work with in the first place. (Of course, there are a number of different philosophies on creating an adequate substitute for the mouse on a console.)

In preparing your design, make sure that you address control. Fit your platform, aim for ease of use, and realize that not everyone who will play your product is as familiar with games as you are. In the later stages of development, make sure that you have succeeded in allowing players to play the game that you've created. Most importantly, be thorough in teaching the player what you expect. The more controls you're using, the more preparation the player will need, and the more time he will need to learn each different aspect of those controls. Provide tutorials - hopefully within the actual structure of the game - and clear documentation. (While there may have been a time when nobody read the manual, a wider marketplace and a wider variety of players demand that there be a ready reference for those who are just getting started.)

If your design has given the player a chance to really get started, then the next pitfall to avoid is discouraging him with an intrusive interface. There is nothing more distracting than having to press four or five buttons when one would have been sufficient. Recent games have provided both good and bad examples of this. Devil May Cry (for the Playstation 2) doesn't let its interface get in the way of its action. How much would the game have suffered if you had to push extra buttons to draw your guns or reload them? Fortunately, we don't have to know. Silent Hill 2, while being a fun and very disturbing game, has a problem with too many button presses at times. When you walk up to a door and press the action button once to notice a note on the door, again to read the note, again to end the text, yet again to open the door, and still again to actually enter the room, you've worked too hard. Similarly, some of the manipulation puzzles would have benefited greatly from a few interface shortcuts. Metal Gear Solid (the original) is one of the best games ever made. Its major flaw? The fact that you had to button through every single line of a conversation. If you actually made the mistake of dying and restarting that section of the game (for those of us who actually played with restarts), you had to do it all again. And some of those conversations were long. Resident Evil: Code Veronica forces you to enter the inventory screen, select an item, turn it the right direction, and then look closer (another button press) to solve critical puzzles. This could have been simplified to a single action, and the game wouldn't have suffered at all, except for maybe being a few minutes shorter. I've brought Myst up before, and it's relevant here, too, as the Myst designers took interface reduction even one step further: they gave you the zap option to jump from one scene to any visible one that you had already visited. This shortened some oft-repeated trips by a bunch of unnecessary clicks and kept the user focused on the game. [A side note: the 3DO version didn't have this feature. Combined with the agonizingly long load times from the CD ROM, this was a compounded error.]

While I'm on the subject of pressing buttons, menus in general are another aspect of the game with the potential for too much interface. Do you have too many screens that aren't part of the actual game? How long does it take to find a particular item and use it, and will you lose the suspense or energy of the title while the player is out of the action? If a limited inventory is crucial to gameplay, make that fact clear and make it as simple as possible to manipulate that inventory. (Could somebody show me the "drop item" button in Code Veronica?) Stacking is helpful. So is automatic combination of items and reloading of weapons. Of course, there must be balance between the realism you want for your title and the simplicity of playing it, but erring on the side of fewer button presses will never hurt you. Whatever you do, make sure that the player can quit the game if he wants to. A non-intrusive interface is one thing, but frustrating the player when he's already trying to quit is just begging him not to come back.

Could somebody show me the "drop item" button in Code Veronica?

Particularly with console titles, loading time is as much a danger as control complexity. While developers understand that the game takes time to get all of its data in order, players are generally distracted and frustrated when they are required to sit for long periods of time with nothing happening. Hopefully, you can minimize your loading times by swapping data during the game itself. If this isn't possible, and especially if your loading times are long, then at least give the player something to look at while the game engine is getting ready for the next portion. Attractive visuals and some sort of indicator - a bar, or clock, or anything that actually moves - at least reduce the pain of waiting. The player who gets up to make lunch during the loading screen may never sit back down.

The major lesson here: don't let your interface get in the way of the game experience. Streamlined, simple controls leave people talking about the game, and not about the difficulties they had playing it. A good designer must have the ability to judge what features should be removed from the design and which should make it into the final product in order to make that product accessible to its audience. Trim the excess. Combine pieces that don't work individually into a single, harmonious whole. A key or button press is fairly automatic, but a sequence of them draws attention to the machine, and away from the product, so pay close attention to how many steps outside of the game are required to move it along.

Word of mouth is a very powerful force. How likely would you be to pick up a game that a friend told you they didn't understand or couldn't get into? This includes the friendly guy at the computer store, who has played a lot of games and may make or break your product in a 30-second chat with a prospective customer, and the reviewer, who may not talk to all of your audience but is certainly reaching some of it.

To keep the player from walking away, you have to do more than just let him play the game with as little distraction as possible. Once you've opened the door to this alternate world, what's on the other side of the door should be interesting and give the player something that he can relate to. You certainly don't want your door to lead to a blank wall, and you don't want the player to run screaming from the room after a short amount of playing time. Extending the player's visit to your world means creating an interesting concept, delivering it well, providing ample and immediate rewards, and ramping up your level of difficulty at the proper pace.

Concept isn't really something that can be defined in an article of this nature. Almost anything can make a fun game, and there are many concepts that have yet to be tested. Coming up with something new is the easy part. Delivering it to the player is the hard part. Designers have traditionally been responsible for story delivery and the flow of the game. Most importantly, the idea has to have enough interest for the player to pick up the game, and then it has to make enough sense for him to stay with it. (And it doesn't take long to put down a box in the store when you read the back and think, "Now why would I want to do that?") If there are too many gaps in the plot, or too many steps that are unclear or just plain unacceptable to the audience, then the player will again be lost. Nobody wants to get lost or stuck, and if the solution to a major puzzle is too obscure, requires too many events to occur in an exact fashion, or requires skills that the player has never learned, then the only thing that your user will spend time learning about your game is how to uninstall it. As I mentioned before, word of mouth is a powerful force, and word of a game that just doesn't make sense will surely get around.

If you have made sure that the game has piqued the player's interest, and you haven't stymied him with the interface, then the next thing that you need to do is to reward him for his time. Whatever the reward - a cut scene, a new item, a new area to explore, character advancement, or merely the first victory in a string of conflicts - the game should provide the player with some simple reward in about the first half hour of play. That first play session and the first impressions from that play session will decide whether or not there will be a second one. In that initial time period, the player should understand enough about your game to feel comfortable with it, and your reward is encouragement to move forward.

As the player continues the game, challenges and rewards should become greater and more meaningful, with the final reward being winning the game (or finishing the game, or mastering all of its levels, or whatever is appropriate to the title that you're building). Remember that making a game too easy is just as dangerous as making it too difficult. Achievement only has real value if there is risk attached, and a game that offers no danger and no increasing challenges will quickly become boring. When it is possible, your game should offer multiple levels of difficulty, as this provides a more level playing field for different skill levels (again, the wider audience) at the same time that it offers the player an increased challenge when he can master the easier levels. With each successive challenge, you can ask the player for more time and more skill, and the resulting satisfaction should increase with your game's progression. Overall, you are building to a climax that asks the player to know everything that you can teach him in the game, and the end result of that climax will be the overall victory that is the highest reward.

Once you think that you have the makings of a game that grabs the player and won't let him go, you need to find out if you're right. At the other end of the product cycle is testing, and it is the most valuable tool for making sure that your product won't lose the player. Somewhere along the line, but before the game ever hits the shelves, it must be taken out of the hands of its creators and placed into new ones. Even one completely new pair of eyes near the end of the product can prevent a huge number of simple gameplay hurdles from making it into the box. As professional game builders, we often understand how to circumvent small flaws and difficult areas of a game by using the game against itself. We react as much to structure as to content. Most players are not as familiar with the workings under the hood, and they react in a much more visceral way to a product. What the user sees and feels when he's actually involved in the product is much more strongly influenced by those tiny details that someone familiar with the game is prone to overlook.

Placing the game into the hands of the end user will find the flaws in its construction far more effectively than those who built it looking at the product hundreds of times. Complex motions and solutions that become second nature as you perform them over and over during the development cycle may not reveal themselves to be barriers until somebody is forced to look at them for the first time.

If the resources are available, this sort of feedback can be introduced earlier in the development cycle. Input from marketing, especially focus group testing, can tell you quickly if you're reaching some, all, or none of your intended players. The sooner you find out where you've lost your players, the sooner you can get them back. The value of evaluating a product with members of its intended audience cannot be overestimated.

At the end of the road, most of the potential pitfalls in development come from the creators of a product becoming too attached to the game as theirs - as "art" or "expression," rather than as a job they're doing for a group of consumers. One necessary role of designers is looking at their work with a detached eye and remembering that it has a responsibility to a much larger audience than the people who are working on it day in and day out. Look at the game as a gift to someone else, and not as a gift to yourself, and you have a better idea of what I'm talking about. Even more correctly, keep in mind that the people who will have to give up their hard-earned money for your product will evaluate it not as someone who loves it like a parent or plays it like a gamer, but simply as someone seeking to be entertained. These users will have no initial attachment to your product, and they won't be able to play it like you did after a year or so of developing it. Make sure that you're building it for them.

While concepts and features may come and go and systems may be modified time and time again, the core design should always be a guidepost for a product's development. Careful design in the initial stages of the product cycle and full knowledge of the designer's responsibilities beyond simply building a game will guarantee that nothing - and no one - will get lost along the way.

Article Start Previous Page 4 of 4

Related Jobs

Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

QA Manager
Legends of Learning
Legends of Learning — Washington, DC, District of Columbia, United States

Senior Unity Engineer - $140k - Remote OK
Cold Iron Studios
Cold Iron Studios — San Jose, California, United States

Senior World Builder
Cold Iron Studios
Cold Iron Studios — San Jose, California, United States

Senior Content Designer

Loading Comments

loader image