Thursday 9 February 2012

a dead end

Still making two-player games. There's a particular dead end I've run into repeatedly. It seems quite natural, at least to the way I think - lots of designs have ended up in the same place for completely different reasons.

(Definitions: I'm just talking about real-time competitive videogames here.)
(Disclaimer: Somewhat tired and unwell. Thoughts may be fragmented or incoherent.)

So, I'm not interested in making games where being quicker than your opponent guarantees a win. Just a matter of taste. I'm happy for speed (and chance) to play a part, but in general I prefer the outcome to be determined by decisions made by the players.
Part of the reason for this is that I play games with my wife, and usually if speed is very dominant in a game then I'll just win in a kind of boring way. My reflexes are better trained by more years of playing videogames, big deal. In a battle of wits, we're usually evenly matched (although don't ask about Chess). Having relatively even chances of winning is more interesting.

So the problem is: how to make a real-time game where quick action doesn't dominate?
A too-obvious solution is to have some kind of resource that accumulates over time and constrains how fast you can act. This leads to the dead end of which I spoke: having resource constraints on all actions. I've made at least four different games on this model, and although they had interesting decisions to make, they weren't interesting to play. Build something, wait to recharge, build something, wait to recharge. Games where you spend most of your time waiting for something to happen are boring. BORING. There's a lack of engagement. No matter how short the delay is, eventually you've made your decision and are just waiting. (Make the delay short enough and the quicker player wins and still spends most of the game waiting impatiently.)

I'm working on a very short timescale. Games that are over within five minutes. I've seen this type of thing done on a much larger time scale, games like Neptunes Pride with actions that take hours to execute. Circumvents the boredom by letting you achieve something else while waiting. But I don't like these either, they tend to advantage logging in frequently and at inappropriate times; they take over your life.

I've done games with some continuous actions with no time constraint, and some discrete actions constrained by a resource dependent on time. e.g. Exuberant Struggle. This works. I'm working with very restricted controls so it becomes quite limiting, but it's led to nice designs. The continuous actions often give false decisions - "do you want to dodge the incoming bomb? y/n" - but still give something to do and make the game more engaging. Speed is still an advantage, but I've been able to constrain how much of an advantage it is enough so that a player with slower reflexes can still win.

Glitch Tank's a curious example. It has a built-in disadvantage to haste. Spamming actions will let you build up lots of tanks and mines quickly, but friendly fire means this isn't a strict advantage. Acting quickly is an advantage, but only if you do so safely. It just barely works.

There are other ways out. I'm interested if anyone has examples that solve this. But I recommend avoiding it because it's been a dead end for me. Certainly if you throw away my constraints there isn't a problem - if you're happy for speed to be a big advantage, or if you make a turn-based game (which can end up playing faster as you master it). Or if a game is intentionally boring (?).

2 comments:

  1. I guess one way out leads into microing -- that is, give different granularity to decisions. You can move a squad, or you can move each unit individually. Those that act faster can make more (and more intricate) decisions, but the superiority isn't overwhelming if they can be out-thought at more strategic levels. Essentially, you're giving faster-acting players more choices, but trying to design it so that those choices are worth less.

    This shades into continuous charging, with firing available at any point, which I know you have explored... And that comes down to waiting, again, for many strategies.

    And of course, for the short games, with quick to pick up mechanics, it's hard to design in these more intricate layers, and have them accessible.

    I do like the approach of being able to hurt yourself with a poorly chosen choice. It's honest, and feels good in a game, and it punishes playing too hastily.

    ReplyDelete
  2. Yeah exactly, Starcraft-style micro is a great example! Constantly gives you something to do to get an advantage, but the big strategic decisions are constrained by resources gathered over time. This kind of multi-level thing does need a more complex control scheme than I've been working with though.

    Erik Svedang's ShotShotShoot is another good example. Bullets are a time-resource - the game wouldn't work if you had unlimited shots. And then there's a continuous element where you can control your last shot to get more value out of it - the game would still work without this, but it wouldn't be as much fun because there'd be boring bits of waiting doing nothing.

    ReplyDelete