Link: GameMaker Humble Bundle

It’s that time again!

For another 14 hours, you can pick up a whole lot of GameMaker content on Humble Bundle. Everything I said the last time this happened is still true: GameMaker is powerful, yet still great for beginners, and the source code included with the bundle’s upper tiers is great as a learning resource. If you’re interested in getting started with digital design, the $15 bundle on offer here is an excellent way to go.

Wargames Study: The Kriegsspiel

Yesterday I had the opportunity to act as the umpire in a round of the original, 1824 Kriegsspiel. It was an eye-opening experience. Without a doubt, the Kriegsspiel–originally built as a training exercise for Prussian military officers, and later adopted as a hobby pastime–is the most disturbing wargame I’ve ever played.

img_0857
The Kriegsspiel in progress.

Many wargames are, and feel like, a chess variant. Pieces move in abstract units: hexes, inches, or centimeters. Health, too, is handled abstractly, often through hit points. One feels oneself engaged with a harmless intellectual exercise.

By contrast, the Kriegsspiel measures everything in human terms. Movement and firing ranges are expressed in paces. Losses are tallied using an abstract system which immediately relates to the actual number of soldiers harmed. Everything about the game emphasizes that it is a simulation, not of fantastical battles, but of human conflict.

This careful effort to translate game functions to human scales lends the kreigsspiel a grim air. Chess variants were its immediate ancestors, but the kriegsspiel lacks their sense of remove. After totaling up the precise number of cavalrymen undone by an infantry volley, one feels an urge to shudder and walk away from the table.

The kriegsspiel has a number of design lessons to teach. Perhaps the greatest of them, though, is the power of choosing the terms in which one expresses the scales used to measure game effects. Abstract scales create an abstract feel. Scales based firmly on lived experience produce a very different sense.

Develop a Nose for It

Game Center Department Chair Frank Lantz offered some advice when the collected students “aah”ed for a key moment in a thesis prototype. I’m paraphrasing it here for safe-keeping:

It’s important when people respond to something in a prototype. That doesn’t often happen, and the times when it does are signals one should not ignore. “Develop a nose for” positive audience reactions; it will help you find the fun in your idea.

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.

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. 😉

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.

All The King’s Theories

One of the great joys of game design is that there’s always something new to learn. There are so many fields involved in creating a game intended for public release that no one person can master them all. It’s always possible to find something new to explore.

Today, for example, I did a lot of audio mixing. Having no particular audio experience, I had to learn the skills involved from scratch. Needless to say, I touched only the surface–but even what I was able to learn in a workday was fascinating. The audio in the new version of Phalanx is better for having learned it, and future projects will no doubt benefit as well.

I don’t have anything especially insightful to say about audio mixing. I’m simply struck by how neat it is that I got to spend some time studying it at all. On the list of things I never thought I’d get to try . . . .

The Unattractive Process of Attract Modes

Today I did the attract mode for the latest version of Phalanx wrong in two entirely different ways. Fortunately, a conversation with a colleague taught me the right method in the end. Lest I forget in the future, here it is:

  1. Code your game so that inputs are stored, along with a time stamp. Preferably the inputs should be handled by a manager devoted entirely to them; it then sends the data to an intermediary, which in turn helps it get to everything that needs to know what the inputs were.
  2. In addition to the input manager, build a system that reads move records, sending “inputs” as the game timer reaches their associated time stamp.
  3. When there’s a great playtest game, put its record into the record player.
  4. Set up your game so that the intermediary reads from the input manager, your attract mode so that it gets “inputs” from the record player.

Voila! Exciting attract mode matches, all thanks to good code architecture.