Friday, February 5, 2010

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

No comments: