Sunday, April 27, 2008

What is Your Game About?

One of the best pieces of advice about game design I've ever heard was, "Figure out what your player is doing most of the time, and concentrate on making that fun." I don't remember where I heard it - I think it might have been at an IGDA meeting or something, but it stuck with me.

What's strange about that relatively straightforward, relatively simple piece of advice is how few game developers really understand the concept, but more, how people can be easily confused because they don't actually know what the core of their game is.

Look at a game like GTA - you could make an argument that what you're doing is running and shooting, but what you're *really* doing, because of the auto-aim is running, picking a weapon with the right capabilities, and then managing the auto-aim algorithms. Yeah, it's a little nitpicky, but it makes a *huge* difference. It's really surprising how many people will suggest auto-aiming as a "tweak" to make a shooter more accessible - it's not a tweak, it's a fundamental revision of what the gamer is required to do on a moment-to-moment basis.

The game no longer becomes about understanding the weapon you're using, aiming at a target, then pulling the trigger at the precise moment where your aim is dialed in. Instead, the game is about selecting the proper weapon, making sure the computer has locked on to the right target, then shooting 'till dead. There's possible decisions to be made re: ammo conservation, which target should be the highest priority, and whether you're using a weapon that has the right range/damage combination - but aim is removed, timing is radically de-emphasized, and a large number of potential variables for weapons (lead time, etc.) are removed from the equation.

Think of it this way - where is the player's skill required? In a game like Quake, the skill is seeing a target, tracking them, having the right weapon, shooting it at the right time, and managing ammo. In Quake with GTA's auto-aim, for instance, seeing the target may not be an issue - they may be automatically highlighted if they're the only target in the area, tracking them is not an issue (that's the "auto-aim" bit), having the right weapon is solely about range, ammo, and firing rate, and shooting it at the right time is solely an issue of line-of-sight and range. Ammo is pretty much the same, though.

So, that adage about finding what your players are doing most of the time may not be quite specific enough - it's also about finding where you expect the player's skill to be required and ensuring that those decision points are compelling. This means developing the game with a very thorough, detailed understanding of what those decision points are - something like auto-aim changes *everything*. Level design is less about the process of aiming, tracking and maintaining lines of sight - it's less about skill at mitigating the technical differences between weapons and exploiting the actual differences between weapons. If I've got a sniper rifle and my enemy has a shotgun, at a long distance I should be at an advantage, except that I *suck* at using sniper rifles. Auto-aim means that independent of my personal skill at aiming/shooting sniper rifles, I will *always* have an advantage over shotgun guy because my skill doesn't play into the conflict at all.

How does that get resolved? How do you create gameplay out of those kinds of situations? Some of the answers are very similar to how you'd do the same for the manual-aim versions - break lines of sight, create mechanics where a player can mask themselves (smokescreens, invisibility, etc.) - but they're less about confusing the opposing player, and more about forcing the auto-aim algorithm to abandon its lock on you. A good player could predict where you might go, even if they can't see you - a lost auto-aim makes that skill totally useless.

Anyway - it's just strange how many games suffer from people either not fully understanding what the core of their game is, or simply not spending the lion's share of the time on making that fun. Find where the player is making the most skill-based decisions, and ensure they ahve a good time doing it.

2 comments:

Angry Chad said...

I read somewhere once where a guy described gaming, in typical programmer fashion, as a series of loops. From the smaller loops (running around picking up weapons and auto-aiming) to the larger loops (completing missions). If the smaller loops aren't fun, the rest of it doesn't matter. You really need to nail the fun-factor in your most common loops, or you've failed.

I don't really have anything to add. Your post just reminded me of whatever it was I read.

Seppo said...
This comment has been removed by the author.