Game design from a gamer's perspective Pt. 3

Loading Screens Continued

You should always keep the gamer in mind when you design your game. Always! You should never program the game for your convenience. Always program for your target audience. So, when you design your loading screens, you need to consider how long it takes to get data into memory. If it takes longer than 2 minutes, it's taking too long. If you don't have a choice in this matter and it is what it is, then design a mini-game or alternative screen that the gamer can play with during the loading period. Alternatively, use of cinematics during this time is acceptable. Do use cinematics as ways of moving the game forward combined with loading the world into memory. Don't wait through loading screens only to watch a long cinematic and then get into the game.

Health pickups

If you design a game where the character will lose health, then always design a system to obtain health on the level. Batman Arkham Asylum is yet another shining (bad) example of how not to do this. Batman's designers chose to obtain health pickups by subduing other creatures. So, as long as there was something to subdue, you could get health. The problem with this 'feature' is that there were never enough enemies to subdue (Batman doesn't kill in the game). Worse, when you did subdue enemies, they gave you a pittance of health back. Meaning, you never could fully ever replenish your health bar. Don't do this. If the character needs health pickups, put enough health pickups around the level and make them blatantly obvious what and where they are. If that means attaching a medkit to the wall, do it. Also, health pickups should come in at least two sizes, small and large. Small increases about 1/4 of your health. Large sized should fully or almost fully replenish your health. I despise playing games where my health meter is always 1/4 full because I am unable to find health pickups.

Story

As we move more and more into cinematic games, it's now becoming increasingly important to weave gameplay together with story. Unfortunately, I've yet to find a single game that has successfully achieved this goal. The closest game was probably Oblivion. Oblivion's method was to weave each quest into its own substory. There was the 'main quest'. This quest basically starts and finishes the game. You can do this quest at any time, but because of the way it changes Cyrodil's landscape, it is best to wait until much later after completing many other smaller quests to tackle the main quest. Even still, there were smaller quests that needed to be completed before you could complete the main quest. Thus, this tied in at least exploration and completion of other goals into finishing the main story line. That unfolded other stories that helped solidify the main quest's story and ensure the gamer a much more immersive gaming experience.

A story is a story is a story. It doesn't matter whether you read a book, watch a movie or play a video game. The story is important to the entire affair. If the story is well written, has twists, feels complete and has a satisfying ending, then that's all you can ask. Games with weak stories or without stories at all are limp and lifeless like Dead Rising. Mindless games without a compelling story verge rapidly on boredom. A solid well thought out story not only keeps the gamer interested, it gives enough subtext for the gamer to become immersed in the world. That's exactly what a good story should do. Once you've gotten the person immersed in the story, they will continue to play for a long time. Games with great story lines include Oblivion, Halo 3, Halo 3 ODST and Fallout 3. A good game has great gaming elements. A great game combines the gaming with a solid story. A perfect game devises a way to marry the story and gameplay seamlessly (we've not gotten here yet).

Granted, not all game styles need a story. For example, sports games and racing games don't really need them. But, it helps if there is some kind of story involved. For example, Gran Turismo is pretty much a straight racing game. The goal is to race your way through each event and improve your car. That's pretty much one tracked. Now, if you took that gaming element and wrapped it around a person and events in their life, that would make Gran Turismo take on a whole new dimension in gameplay. You could even open up free roaming aspects to let the person walk around the cities and find things to enhance the car or their driving skills. Just think of a combination of Grand Theft Auto and Gran Turismo together in one game!

Gameplay

Enemy and Boss Tactics

Perhaps this should have been under the bosses section, but I also feel it needs to be under game play. When designing how a boss works, do not use an unkillable/undamageable boss simply to whittle down player health for later smaller enemy attacks. This is frustrating and annoying. If you're going to let the gamer battle the boss, then let them battle it. Don't do some intro game play where it's impossible to kill (or even wound) the boss. If the boss can't take any damage during a specific area of play, then it should not be there. Only enemies on the play field that can actually be killed or damaged should be actively engaging the player. If something can't be killed or damaged, then it should not be there... or at least, it should not be launching damage salvos at the player character. This is similar to Perfect Aim. Don't do it. Only killable or damageable enemies should be actively engaging the player character.

Character Control - Messing with a good thing

Here's an issue where changing controller mappings sometimes works, but most times doesn't. As a game designer, be mindful of your intended gamer audience. Between the PS3 and the Xbox 360, the controllers are similar enough that you can map similar styles to each of the buttons. For example, the analog sticks usually are reserved for camera on one and movement on the other with the buttons mapped to attack, jump, climb, etc. This is the perfect combination. Because so many games have used this style of mapping, don't mess with a good thing. If you want to design a 3D shooter or RPG, use this style. Don't think that because you decided to put the camera movement on the bumper buttons that that will make your game better. Don't do it. Stick with what works and is accepted.

If you decide to modify the usual and standard controller layout to something odd, then at least give the gamer the ability to change this mapping to a controller style of other familiar games. Don't lock the gamer to a non-standard button mapping system and force them to play the game that way. Having to relearn the controller layout for your game is just bad design and, worse, may even doom your title into obscurity and lackluster sales.

Also, don't lock gamers into using the Xbox Kinect, the PS3 Move, PS3 Sixaxis or the Wiimote motion controllers for your games. Give the gamer the option of using a standard controller to play. Simply because you, as the designer, feel the game may be better experienced by using these motion control systems may alienate an entire paying audience who can't (or won't) play games using these motion control systems. Spend the time to add a standard controller layout to your game along side these novelty controllers.

Cameras

I know a lot of people are familiar with the use of fixed cameras through franchises like Resident Evil and early Tomb Raider titles. As much as Resident Evil liked this style of camera, when designing your title, don't do it. The trouble with Resident Evil becomes quite apparent very rapidly once game play starts: Enemies can hide out of the camera view and damage the player. The player can't even see the enemy to kill it. This, once again, goes back to Perfect Aim (and Perfect Vision). In game, the enemies aren't reliant on the camera and can 'see' exactly where the player is. The gamer, on the other hand, is limited by what's shown on screen by the camera. Fixed cameras prevent the player from seeing critical parts of the game playfield. Don't use fixed cameras. Always use a floating camera and let the player move the camera to wherever they need it to be. The camera is the only way to view into this game world. Don't cripple the player by imposing stupid restrictions on the camera. The camera should never be used as a challenge element. It should only be thought of as a way to peer into the world. If the player can't see the world in the way they need to see it, they will get frustrated and stop playing the game.

Recently, I've found few games that cripple the camera. However, every once in a while a game will come along and try to do something creative with the camera. In fact, by crippling the camera the only thing the developers have done with their game is doom it to obscurity and failure.

Audio and Soundtracks

Music is an important element in any game. It's what sets the mood and tone of a given level. It can swell to indicate enemies approaching. It can diminish to indicate the battle is done. There are lots of ways to use music and sound effects in creative astonishing ways. The trouble with some soundtracks, though, is monotony. Be careful to use the right music at the right time. Don't use hip-hop music when doing a medieval genre game (not that I've seen anyone do this, yet). That's an extreme example, but be aware of what you need. I prefer orchestral music in games as it's soothing at necessary times and intense at others. Heavy metal can be used in some instances successfully, but it can be out of place at other times. So, be cautious of using heavy metal in a game you design. The same can be said of techno, so be careful with this genre. The style and type of music, though, can definitely help or hurt your storyline. It can make the difference between an emotional scene or making it stupid.

Coming Up:

• Characters
• Computer Graphics: 3D models, textures, lighting
• Playability
• Easter Eggs
• In-game Tutorials

Parts: 1 | 2 | 3 | 4 | 5

Game design from a gamer's perspective Pt. 2

Time Wasting Continued

When designing a game, you're already asking the game player to forfeit part of their lives on your game. But, as long as the gamer is having fun, they don't see that as a loss. However, what is a loss are all of the time wasting moments that are not in-game. For example, loading screens, cinematics, transition scenes, etc. These are all non-playing aspects of the game. Anything that takes the gamer away from the action and forces them into a 'watching' or 'waiting' mode is dead-time. This is true time wasting at its best. To avoid these dead times, always allow the gamer to do something. If that means designing a mini-game or putting up an experience management page, allow the gamer to do something during dead time.

Dead time is what can also make or break a game. Too much dead time and the game becomes boring. Gamers will move on to more action oriented games and leave yours behind. If you want to keep the gamer excited, be acutely aware of dead time. A good example of how to prevent dead time is Assassin's Creed II. During loading screens, you can at least play with Desmond and make him run and so forth. This gives the gamer at least something to do during these dead times.

Also, do not waste a game player's time by making them do pointless activities. Think heavily about each part and level of your game. Consider if it moves the game forward or if it's exciting for the gamer. If it neither moves the story forward nor is exciting for the gamer, remove it from the title or spice it up and make it worthwhile. A few good examples of this are chests, cupboards or containers that contain nothing. If you're going to create a container, put something in it. Make it worth the gamer's while to search for things. If you're planning on creating a level, put something on the level to make it worth being there (a boss, treasure, something.. anything). The prime example of a level being done badly is in Darksiders. The Vulgrim Tunnels are pointless. You walk down a path from start to finish with nothing in that void (literally). Unless they're trying to give your character exercise or test your walking skills, there's nothing here to do. Don't do this in your game.

For loading screens, though, it is suggested to load a mini-game, a shop or an experience screen and let the user manage their character until the loading of the next level is complete. Even better, use incremental loading during the game and never have a loading screen at all. For dungeons or other rooms, begin to prefetch these in the game when the gamer gets close enough to the room. So, if the gamer opens the door and enters, the room is nearly already loaded. This can cut loading times in half or more.

Bosses

There is plenty to be said about bosses. Let's just cut to the chase, though. Bosses can be done right or done wrong. Most times, however, the reason a boss level is done wrong is not because of the boss itself. Many times it's done wrong because the game designer didn't work through the proper method of how it should work.

In Batman Arkham Asylum, for example, the bosses in this game weren't the issue. They were hard, yes. But, the issue is that the game relied on trial and error play to win the level. This means that your character must die and start over many times in order to find a strategy to defeat the boss. This goes back to time wasting. Making the gamer restart the boss battle over and over and over is a utter time waster. Don't do this. The problem with Batman, though, goes back to the fact that Batman's health drops rapidly. Far too rapidly for the amount of armor he is supposed to be wearing. Secondarily, the game throws 12-15 enemies at Batman all at once. Then there are other issues, like certain moves the enemies can do that take away nearly 1/4 to 1/2 of Batman's health... merely by kicking or punching him.

So, in Batman, the way to win is let the enemies take out themselves and simply run around and avoid being hit. Yes, the enemies will attack each other. So, let them. The trouble, of course, is that you have to get them in a position to do so. They won't do it on their own. Batman must lure them.

Perfect Aim / Perfect Vision

One thing about enemies and bosses that always drives me nuts is perfect aim. In a digital world, we are limited by our view into this world through pixels. Because pixels are a fixed dimension, as objects get smaller they also get harder to read. But, the game world itself has clear vision to infinity. So, while the gamer is crippled by the pixel screen, the in-game enemies have perfect vision. This is an unfair advantage. So, for example, enemies can always seem to find, aim and target your player character perfectly. On the other hand, finding and aiming at enemies can be a challenge due to pixel size limitations.

When designing a game, please keep this in mind and compensate for the 'perfect vision' by at least making the enemies miss or aim incorrectly at least some of the time. Perfect aim gets old and tired in games. Don't do it. Do make the enemies miss more often the farther away they are from the player character. Basically, whatever rules you impose on the player to negatively affect aim should be applied to enemies and bosses. Even more than this is that extra care should be taken to ensure there is no such thing as 'perfect aim' in your game.

Enemies always targeting the Player Character

An offshoot of the Perfect Vision problem is game designers who design games so that the enemy AI always targets the player's character. Even if you have a team helping you, inevitably most games have their bosses and enemies target the player's character. This is stupid, unfair and unrealistic. If you have a team, the enemies should equally target each of the team. The player's character should have no more weight in being attacked than any other player. The trigger to whether a specific character should be attacked is if the character enters the enemy's block of influence. This means, as soon as any character gets in range, the enemy should 'see' and begin targeting that character. A perfect example of this being done wrong is in by Bioware in Mass Effect 2 and Dragon Age Origins. In these games, once an enemy locks onto your character, it stays locked until you kill it or run away.

Character Deaths

Inevitably, when playing bosses, your character may die. How your game design team chooses to handle a character death is as important as any other aspect of the game. In some cases, it's even more important. Some games (Too Human) like to produce long drawn out unskippable death sequences. Don't do this. Instead, if you must show some kind of cinematic, make it quick and let the gamer skip it. If you are going to show a cinematic, use that time to reload the level. Don't wait until the cinematic is complete before reloading the level.

As far as level reloads, I never get this part of gaming. You already have the level loaded, yet you have to reload it again from scratch? This can take 1-2 minutes. Why do this? Instead, use the existing loaded level and simply reset all of the objects on the level. That's got to be faster than dumping the level and reloading it from disk. After all, you were already playing the level and it's already in memory. It may be slightly more complex to code this, but shaving the time off of the gamer's dead time gives the gamer much more in-game time. This is what you want. So, it IS worth the effort to code it. Smart coding leads to higher quality gaming.

The next issue with character deaths is using this as part of the gaming experience. The player characters should never die. Never. The goal is to keep the gamer in the game experience as much as possible. Making the gamer wade through death sequences time and time again goes back to time wasting. Don't do it. Do everything you can to avoid the character dying. If the character must die, then the reload to start the level should be instantaneous. No sequences, no specialty things, just fade out and fade back in. Let the gamer start immediately. We'll come to why this is important for the story shortly.

Loading Times

When a game needs to load a level or reload after a character death, it should be as fast as possible. There is no need for 3 minute loading screens. This is excessive and wasteful of the gamer's time. Granted, sometimes it can't be helped, but smart incremental loading can be designed. Oblivion and Fallout 3 are perfect examples of incremental loading of the environment. With incremental loading, the game never has a loading screen and instead is constantly fetching in-game data to build the next part of the environment. Waiting through loading screens is not mindful of the value of the gamer's time and suggests convenience on the part of the programmer and designer. Don't do this.

Coming Up:

• Health Pickups
• Story
• Character Control
• Controller Mapping
• Audio & Music

Parts: 1 | 2 | 3 | 4 | 5

Game design from a gamer's perspective

This is a multi-part series on successful game design from a gamer's perspective. This article series will encompass such topics as story, models and texturing, lighting, artwork, gameplay, genre choice, audio and many other subtle aspects of creating 3D based video games. This article will also discuss what game techniques work and what to avoid. So, let's get started.

Successful games

Let's get right into the meat of this and discuss what makes a successful game. Clearly, success is nearly always measured by dollars. Specifically, how many units sold and how much profit was made. Even more, did the game pay off its debts that were generated during creation and did the revenue rise above those expenses to actually make money? For executives of gaming companies, this is the goal of a video game. But, was the game actually successful for the gamer? For the C-level executives, I'm sure they'd respond a resounding yes (assuming it exceeded its dollar goals). From their point of view, apparently enough gamers purchased the game to make the dollars at least work. But, was the game a success for the gamer? That's a completely different question.

From the gamer's perspective, the game may not actually work. An overhyped game from a brand resting on past successful history can produce games that appear successful, but only because a gamer was 'tricked' into the purchase. So, success of a game is measured both in dollars and in how the game was received by the gamer. The adage is still quite relevant, "Once bitten, twice shy". If you burn the gamer with a bad title, you likely won't get much respect from future titles. So, don't burn the people who keep you in business by producing bad titles.

So, that means you should measure success in two ways. First, money. Second, longevity. Money describes how well the gamers decided to adopt the game immediately. Longevity describes how long the gamer played the game before giving up or trading it in. If there are massive trade-ins within a few days, the game failed as a game. That's when the developers need to understand why it failed.

No longer can developers sit in a bubble and develop games without listening to gamer comments. With social networks like Twitter and blogging, it is more important than ever for developers to review forums, read critical reviews, listen to complaints and understand just what problems gamers have found in a game. These are issues that must be addressed, preferably in patch updates to the existing game if possible. If not, then these issues definitely need be addressed in any sequel games.

So, while sheer numbers may describe immediate monetary success, this does not tell the whole story. Executives who are simply bean counters fail to see the bigger picture. Gamers are finicky and will choose with their wallets. Once bitten, twice shy applies to game titles. More than this, it also applies to game development company loyalty more and more frequently. As a gamer, I know what companies to avoid. For example, I simply will not purchase any more Square Enix titles. I've been burned too many times from this company. I've about had it with EA as well. The quality of EA titles is so widely varied that it's too much of a risk. So, before I buy any EA titles, I must read reviews and play demos, if possible. I also feel this same way with Activision's and Atari's hit and miss strategy.

Game development: Ideas that work and techniques that don't

As a game developer, it's important to solidify the game style and format up front. All too many times, the gaming engine that is chosen dictates the game's play style. The choice, for example, of using the Havok engine may have serious consequences on the success or failure of the final game. So, choose your engine wisely based on game genre and understand its downsides carefully. For example, licensing the Havok engine for a full RPG is probably not a good idea. At least, it's not a good idea without some recoding effort.

Health Status Indicators

As an example of what doesn't work, there are some licensed engines that don't offer a health meter. Instead, the engine opts for a blood or out-of-focus halo around the screen. As health diminishes, the halo increases. For a gamer, this aspect can make the game frustrating and unplayable. Halos obscure the play view, so you can't see what you're doing (see Perfect Aim / Perfect Vision). Worse, some games inhibit the character's ability to play after a certain point. So, you can't move or respond correctly to enemies. This just leaves the gamer to stop right there and reload from a saved game. There's no point in continuing to play when you can't even control the character properly. Mass Effect 2 is the perfect example of a blood halo done poorly. In 2010, if you can't provide a health meter on the screen, don't bother creating the game. There is no reason not to provide a health status indicator (more than a blood halo). All too many times, especially in health screen halo engines, once you see the blood halo, your character has 1-3 hits left before completely dying. Worse, you can't properly see the screen to maneuver your character out of the way.

On the other hand, having an actual meter on the screen so you can see how many hit points you can take before dying is much more useful. It helps the gamer decide how strong a given enemy is by how much damage they deal. Having this information allows the gamer to create a strategy to beat that enemy and know their relative weapon strength.

Save Game Locations

There are many styles of game saves. These include checkpoint saves, save anywhere, pause save screen options and in-game save points (obelisk saves). Game developers need to understand that saving the game is not and should not be part of the game play. Don't weave in saves as part of the story or challenges. Saves are there for convenience to the gamer. They are there to allow the gamer to save progress and also allow the gamer to stop the game at selected times and/or prevent losing the work up to that point. Therefore, game save points should never be treated as some kind of obstacle, challenge or in-world treasure. Never.

It is preferable if game saves be allowed anywhere in the game. This style is the most efficient for the gamer and allows the gamer to prevent starting over time and time again. The game save style to completely avoid is the one that forces you to play through an incredibly long, hard and complex level with lots of chances for death before you reach an in-game save point. This style of gaming is frustrating and extremely bad design. It ensures the gamer will give up before they finish the game. Don't do this.

Checkpoint saves can be useful as long as there are enough checkpoints. Again, this goes back to in-game saving. If your team has decided that checkpoint saves will be the only mechanism for saving progress, then your team better make sure there are enough of them along the way. Otherwise, your game will end up in the same boat as the immediate example above. Keep in mind the pitfalls of using checkpoint saves, though. Checkpoint saves overwrite the previous save. So, the gamer can only start at the most recent checkpoint. This means they cannot step back two or three checkpoints and redo those sections of the game. If your game is the type where you can make choices that affect the outcome of the story, then checkpoint saves are not appropriate for this gaming style. Checkpoint saves are intended for mindless zombie killing. They are used where outcome of the game is irrelevant. For RPGs where choices can be made that affect outcome, do not use checkpoint saves. Instead, RPGs should always use save-anywhere saves. This allows the gamer to save before critical choices or battles and restart the battle from seconds before.

It's fine to combine save styles, though. If you allow save-anywhere saves and want to also create checkpoint or restart mission saves along side, that's fine. Again, though, beware of pitfalls. If the character dies on the level, let the gamer choose which save point to restore from. Do not automatically start loading from the checkpoint immediately after a character death. This is especially true if there is a newer save-anywhere save present. This is waste of the gamer's time as he/she will need to wait through that load sequence only to reload again from their own save. Mass Effect 2 is a prime example of this behavior. Do not do this!

Other saving issues include how much data is saved to the save file. For example, the best games store everything including character position in game, character level, inventory items, etc. With this save type, your character starts exactly where you left off. This is the best style of save format there is and the least disruptive to the gamer. Always choose this style of save when designing. Other save game file formats include starting over at the checkpoint. So, this file format stores only the start point and nothing else. In this case, the gamer starts the level over with a clean slate (no previous weapons, armor or whatever). This is frustrating because all of the stuff you'd found to that point is lost. Don't do this... especially on an RPG. Don't force the gamer to backtrack in a game to get goodies a second, third or fourth time. For shooters, it may be acceptable, but even here I wouldn't recommend it.

Time Savings

As part of the game, don't waste the gamer's time on irrelevant or unnecessary things. These things include long loading screens, long death sequences or unskippable cinematic sequences. In this goal, the pause button on the controller should work 100% of the time in game. Granted, certain times you can't, like intro loading screens, game saving sequences and other operations that can't easily be interrupted. But, as long as it's in game, pause and load panels should be available 100% of the time. Again, Mass Effect 2 is the prime example of not doing this correctly.

Coming up in part 2:

• Bosses (when is too much or not enough)
• Character Deaths
• Loading screens
• Loading times

Parts: 1 | 2 | 3 | 4 | 5