Theory: Two Common Design Issues in Competitive Games

Yesterday I played a favorite wargame against a relatively new player. My opponent played well, but I was able to set up a turn in which I removed almost all of his heavy hitters. The following turn I cleaned up what remained of them, and from that point on my opponent was on the wrong side of rock-paper-scissors. I had thickly-armored units, nothing on his  side of the table could deal with them, and we could both see the writing on the wall.

It’s a rule in this particular game that if you ever lose your general, you’re out. One purpose of that rule, I believe, is to give players who are losing an out. When the tide turns against you, you can snatch victory from the jaws of defeat by getting to the enemy leader and taking them off the table.

Knowing that losing my general could cost me this game that was otherwise in the bag, I did the only logical thing: I backed up. Way, way up. My general–my most important piece–ended the game tucked into the corner of the board, far from the light infantry-versus-heavy armor scrum that was deciding the game in the middle of the table. The one remaining weak link that my opponent was meant to be able to exploit stayed out of range, entirely safe.

Yesterday’s opponent was sporting about all this, but in the end he simply conceded. The “out” that was supposed to give him a chance wasn’t there. Why should he keep playing?

For that matter, why should I? It was all over but the die-rolling. There was no fun in grinding out the remainder of the exercise.

I see in that single play a microcosm of two issues that plague competitive games in general:

1. The best strategy is often to minimize risk, but that’s also the least fun strategy. We love the exciting moments in games, but those are the times when something could go wrong. It’s usually better, from a purely victory-focused standpoint, to avoid excitement. My game would have been more fun if I’d gotten my general stuck in . . . but hiding off in the corner was the smart play, and I knew it.

To counteract this, we as designers should reward engaging, risk-accepting play. That’s the approach that makes the game the most fun, both for whoever’s in the lead and for whoever’s trying to come from behind. Allowing–or, worse, encouraging–risk minimization means that decisions stop being interesting; it doesn’t take long for that to sap the fun out of the experience.

2. The game doesn’t end when it’s been decided. Although my opponent and I could tell that the game was over, the rules couldn’t. We had at least two turns of largely decision-less mopping-up to get through before an official end state was reached. Luckily, we were both of the same mind about whether conceding was appropriate; had we not been, it could easily have taken the rest of the evening to grind out the conclusion.

Again, this is a problem that we as designers need to confront. It’s not always easy to judge when a game is “actually over,” especially when the game is complex. Nevertheless, we should always be keeping an eye on the data, and refining the game-end conditions where possible. If it turns out that X is a good predictor of who will win, it’s worth considering whether attaining X should itself mean victory.

Competitive games have suffered from these problems for thousands of years. I don’t expect that we’re going to be able to address them instantly; even as I point at these issues, I have to acknowledge that I struggle to respond to them in my own work. Nevertheless, I feel that it’s worth recognizing them. Dealing with these two problems is, I think, one of the next horizons in game design.

In the Lab: Phalanx 3D

I’d like to say that I have a grand new conception of game design to offer this evening, or at least a fresh insight. Unfortunately, I spent the day figuring out which of several rules for colliding phalanxes was best–not by doing something new and different, but by brainstorming and iterating, as one does. Then I ground out the relevant code: planning the architecture, writing, re-writing when I realized that my design wasn’t going to produce the gameplay I wanted, and finally debugging. No new techniques, just the usual approach.

Sometimes game design is a matter of keeping one’s nose on the grindstone.

Slack, Revisited

A while ago I asked what the benefits of using Slack are, as compared to, say, a web forum. While the jury is still out for me, I have detected a few advantages worth noting.

  • You aren’t responsible for backend security issues; somebody else is handling updates.
  • Slack’s notification settings are easy to understand, and Slack is much more respectful of one’s choices than is true for some social media systems. We
  • The free version of Slack is quite powerful, and is frankly generous about exceeding its intended limits (e.g., one can continue uploading files even after the group is over the memory limit).

I’m particularly aware of the first of those advantages. Not having to worry about technical aspects of site maintenance is a big deal. Whatever else is true about Slack, I’ve never seen its channels taken over by spambots.

Driving Games, Turning Radii, and Helping Players Deal with Unrealistic Acceleration

You’re driving in a parking lot. As you turn into a space you realize that you’re going to hit something–perhaps the curb or a lamp post. Maybe you’re just going to park over the line. You back up a bit, do a little S-turn to redirect the car, and get into the space.

8-19-16 - Parking Diagram

This works because real cars are capable of accelerating very slowly. Part (2) is the key, and it’s quite difficult if you’re doing more than about five mph. After all, parking spaces aren’t very wide; you’ll overshoot if you back up at speed. Substantially redirecting the car in a small area requires the ability to accelerate gently, and use that slight velocity to get into a carefully-chosen position.

Arcade-style driving games generally have strong acceleration, and that means the little maneuvers necessary to correct a missed turn are quite difficult. By the time one is ready to put the “S” in the s-turn, part (2) in the diagram above, one is already back at the starting point. The effort to get off the obstacle ends up looking like this:

8-19-16 - Parking Diagram 2

This can go on for quite some time.

Assuming slowing the car’s acceleration isn’t an option, the solution is to change the turning radii when the car is moving forward and backward:

8-19-16 - Parking Diagram 3

This isn’t realistic–but that hardly matters. Arcade racers are all going fast, about keeping control at the edge of the performance envelope, about doing unreasonable, death-defying, exciting things. Struggling to get back on track doesn’t check any of those boxes. Make turns behave unrealistically so that I can back to them when my terribleness slows the game down.😉

Link: Merchants of Araby

There are a small number of designers and companies whose products I’ll buy sight unseen. Jay Treat is at the top of that list.

Jay’s Merchants of Araby is on Kickstarter now. I’ve never played MoA, in playtest or final form. Nevertheless, this is a snap-back for me. Jay is an amazing designer and a past master of social games; if his name is on a negotiation title, it’s going to be great.

I’m not getting paid anything from Merchants of Araby, and my name isn’t on it anywhere. My only connection to MoA is that Jay’s a good friend of mine–and that’s no surprise, he’s an awesome person. If you knew him, you’d be friends with him too. Take a look at his games, and MoA in particular; they’re worth your time.

Olympian Challenges

The Olympics raise many game design questions, separate and apart from those involved in the individual sports. What is the best way to organize tournaments so that players are motivated to do their best? How can the matches best be presented to viewers who aren’t familiar with the game being played? Who are legitimate competitors, and who makes that decision?

Sadly, there’s an additional question as well: how does one restore wonder to the Olympic Games, a sense of awe at the remarkable feats being performed, when one is all too aware of past achievements marred by later revelations of doping, steroid use, and other wrongdoing?

I’m sorry to say that I don’t have the answer. I hope that someone does.

Seeking a New Algorithm

I’ve run into an efficiency issue while coding the new version of Phalanx. While it’s not game-breaking, I very much want a game that’s meant to run 24/7 on arcade cabinets to be as easy on the hardware as possible. Thus, I thought I would raise it here, in the hope that someone might have insight.

Phalanx is played in real time on a board.

Screen Shot 2016-08-12 at 11.46.48 PM

Although the game is played in real time, it is effectively divided into turns–one turn per frame. In each turn, the movement rules are as follows:

  1. A piece can move if the space it is moving into:
    1. is currently empty, or
    2. will be empty this turn (e.g., because the piece in it is leaving).
  2. A piece cannot move off the board, or into a space containing water (the blue area in the middle), either of the goals, or another piece that is not going to leave this turn.
  3. Pieces move in number order, starting with player 1’s pieces and then proceeding through player 2’s pieces. (This is terrible, and messing with the algorithm is a good time to change it.) In the event of a conflict during movement (e.g., two pieces want to enter the same space), the earlier-moving piece takes priority.
  4. If a piece is part of a formation, the entire formation cannot move if any individual member of the formation cannot move.

To implement those rules, the game proceeds as follows:

  1. The game loops through all the pieces that want to move.
    1. All those that are moving into an empty space do so.
    2. All those that definitely will not move (e.g., pieces blocked by water) are marked as not moving.
    3. If a piece wants to move and is blocked by something that might get out of the way (e.g., another piece that hasn’t had its turn in the loop yet), that piece is skipped for this loop.
  2. The game repeats step (1) until all pieces have moved or been marked as not moving.

This algorithm consistently produces the correct results, but the performance hit is rough. Is there a better way?