Clic The Technology

Archive for the ‘strategy and tips’ Category

The physical layout of your map will be heavily influenced by its gameplay type. Single-player levels tend to be linear. If the level is too open, the player doesn’t know which way to go and can become lost. You should design these levels with a flow that leads the player along until he has reached his goal.

Death Match levels tend to be circular. The architecture should be simple and easy to navigate. The player should be able to learn the map quickly and thereafter never be confused about where he is. These levels should have no safe territory where a player can hide out indefinitely. They should have several ways players can double back on each other, along with the requisite hard-to-reach places where expert players can snipe at unsuspecting novices below.

Capture the Flag levels should be balanced, with each team’s home base equally easy to attack and defend. Give special thought to color schemes to help the players know when they are entering enemy territory. In all cases, the look of the level should be internally consistent.

Don’t mix graphical styles within a level, particularly if it is a small map. Although larger maps can contain a series of smaller locations that look different, the style should be consistent within the  boundaries of each location. This constant supply of convincing, coherent detail helps sustain the player’s waking dream as he travels your landscape, totally immersed in the world you have created.

Organize a level or mission around one major premise, whether it is a particular style of gameplay or an unusual goal. Because variety is the spice of life, change the themes and underlying structures of missions as the player goes through the game. Vary the strategies for success from mission to mission. One could be, “Build up your units and make a rush,” the next could be, “Send in a small but powerful unit on a sneak attack,” and a third could be, “Defend the base against an enemy rush.”Mix it up so that the player doesn’t become bored.

Quality here is more important than quantity. If you have to choose between giving the players lots of the same kinds of levels, or fewer levels with a greater variety, choose the latter. Make sure that the player knows what his objectives are for each mission. This can be done either in a cutscene prior to the mission or within gameplay as the mission gets underway. It’s also good to give the player access to a screen with his current status and a simple restatement of his mission.

Create visually distinctive landmarks to keep the player from getting lost as he navigates through your world. It’s especially helpful if some of these landmarks appear as a result of the player’s actions, so he can orient himself if he has to do any backtracking. This applies to both 3D worlds and tiled worlds. Within a level, as within a game, start easy and build up the difficulty as the player goes along. Don’t make the hardest part of the level the first thing he has to do. Ease him into it. Also, avoid the “restore” puzzles that plague adventure and action games. In theory, it should be possible for a player to win a level on his first try, rather than failing repeatedly in order to gain the knowledge he needs to win.

Nothing knocks a player out of a game like a bug. Many designers think that bugs are the exclusive domain of programmers. Not so. There are many ways you can help keep the game bug-free. Be clear in your design documents. If you’re unclear and the programmers do things the wrong way, they’ll have to go back and do it again. This reduces the amount of time they have to address other problems, and vestiges of the incorrect way are certain to remain and will be hard to stamp out. The more you can get it right the first time, the  more they can too.

Be flexible in creating your design. Consult with your tech lead and listen to his advice. If he says of a particular feature, “It will be hard to code and buggy as hell,” believe him. Perhaps there’s some other way to accomplish what you want. Stay involved throughout the whole development cycle. You can’t create a design document and walk away.

A bug doesn’t have to be a crash. It can be anything that deviates from what you intended: a weapon that’s too powerful, a line of dialogue that’s spoken in jest but that you meant to be taken seriously, or an inappropriate lighting scheme that creates the wrong mood for a room. The earlier you catch these problems in the development cycle, the easier they are to fix. The later you discover them, the more likely they are to remain in the game.

If you design a multiple-disc game with a huge world and give the player complete access to the entire world at any time, it will result in annoying disc swaps. If he shuttles back and forth between two locations that have graphics and sound on different discs, he’ll be faced with the onerous task of swapping discs every time he crosses the boundary.
One solution to that problem is to dump everything onto the player’s hard drive, but this creates a huge footprint that will drive your sales and marketing people crazy. The system requirements will go up, thereby driving sales down. The better solution is to design choke points in the game. These are points beyond which the player can’t go back, other than by restoring a saved game.

This allows the programmers to organize the game’s data on successive discs, put fewer core assets on the hard drive, and eliminate the need for the player to swap discs continually. By doing this, you give up a theoretical design advantage (total freedom for the player to go anywhere at any time) in favor of a practical game play advantage (game play uninterrupted by annoying disc swaps).

Two hidden problems of single-player level design are how to contain the player in a given area of a level until he has accomplished what you want him to and how to prevent him from returning to that area after he’s done.

The first problem is especially prevalent in open-air levels, where there are no natural barriers to keep the player from moving around. In these levels, the player can sometimes simply run past his opponents, rather than engage them in battle. This will effectively “break” the game, because the player either arrives at the end of the level with a host of bad guys on his tail who are sure to kill him or reaches the end with no challenges and wonders why the game is so short.

There are many solutions here; the key is to be aware of the problem. You can create natural barriers that are destroyed as a byproduct of the player making progress in the level. Or you can provide naturally occurring choke-points in the level geometry that are guarded by mini-boss monsters. The point is to ensure that the player doesn’t get too far too fast.

The second flow control problem is how to close off an area after the player is done with it. There are many reasons for doing this, including better memory management and prevention of player paranoia. If a player cannot return to a given area of the level, he knows that he’s making progress and doesn’t wonder whether he left any tasks unfinished back there. Of course, closing off the area also means that the programmers can free up the memory associated with making everything there work.