Thursday, May 11, 2006

Gameplay Pacing

How "fast" should gameplay go in a multiplayer game? Should it be like a first-person shooter? Or like a real-time strategy game? Or should it be turn-based like 4X games?

For me this choice isn't so much about what kind of game I'd want to emulate as it is about what kind of gameplay I'm trying to support.

At a high level like this, I find it useful to break down action using the old military model:

Tactics: short-term, small-unit actions in which the local environment can affect the outcome

Operations: medium-term tactical engagements organized to achieve a regional objective

Strategy: long-term operations organized and logistically supported to win a global conflict

Grand Strategy: very-long-term strategic actions intended to make conflict unnecessary

Where this helps the current discussion is in determining the time allowed for decision-making.

Tactical activity is more about the moment; it's a visceral, heart-pounding, adrenaline-pumping kind of thing. So tactical gameplay, to accurately reflect the level of this kind of activity, needs to use a model that presents problems and opportunities as a continuous flow -- in short, tactical action needs to be real-time to "feel" right.

Operational- and strategic-level gameplay, on the other hand, just aren't much fun when you're constantly being interrupted. So-called "real-time strategy" (RTS) games aren't strategic at all -- they're operational-level resource collection and expenditure games. You can slow time down a little to give orders to multiple units, but you can't really stop it. That doesn't mean these games aren't fun; it just means calling them "strategy" games is misleading.

For a truly strategic game, you need to have some reasonable amount of time to understand large-scale problems and devise solutions to them, which is why most actual strategy games (such as 4X games) are turn-based. They actually let you freeze time to do as much thinking as you like -- if you don't win, it won't be because an opponent (i.e., the game) jogged your elbow.

So what I'd like to see is the passage of time keyed to the current mode of gameplay. The bigger the problem you choose to consider, the more time you should have to solve it. In short:







If I'm playing a single character who gets jumped by someone with a knife, I should mostly be in real-time gameplay mode. You might let me slow that down slightly and occasionally (as in the "bullet-time" feature of F.E.A.R.), but tactical-level gameplay should mostly be real-time.

When I'm asked to go up a level, to make operational decisions about how to string together tactical actions to attain some regional objective for an organization, there should still be a sense of urgency but I need a little more time for good decision-making. At this level, I'd like to be able to slow time without actually stopping it -- maybe give me ten minutes (plus or minus five minutes or so) before the opportunity to make a decision ends.

And for strategic-level gameplay, I want to be able to pause time so that I can survey all the relevant high-level information, identify what's needed to move the current state toward my desired end-state, and develop a plan to accomplish that motion. In a persistent-world, multiplayer game, of course, you can't actually stop the game! But you can find ways to control the speed of large objects (whether physical objects or groups of people) so that players have hours or even days in which to make strategic decisions and set them in motion before the window of opportunity closes.

In summary, the speed of gameplay decision-making should be determined by the window through which the player is viewing gameplay. A personal-sized window should be real-time; an organization-sized window should be slow-time; and a world-sized window should be stop-time... or as close to it as you can get.

As usual, this kind of thing is easier to describe than to implement.

No comments:

Post a Comment