Initiative-Based Battle Test

When I played Final Fantasy X years ago, I was taken with its focus on manipulating the turn order during battles. Jockeying to get more turns, and delay the opponent’s, was a great mini-game. Every little victory felt enormous, and was rewarded with the coolest thing possible–more play. Setbacks were punished with similar vigor. The system wasn’t subtle, but the enormous stakes certainly made it engaging!

I’ve long thought that there’s an entire game in that system, just waiting for its time to shine. This prototype (Mac build) is a quick-and-dirty exploration of the concept. There’s a broken strategy right now; can you find it?

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.

Back at the Game Center

Today I sat down with three other designers to discuss a prototype. We talked about everything from tuning numbers to the fundamental nature of cooperative play.

It’s good to be back.

Please forgive the brief update; I’m writing this quickly as I prepare for the beginning of the thesis process tomorrow. Wish me luck!

Phalanx: Platform-Driven Performance Issues?

Oddly, the current build of Phalanx works fine on my Mac laptop . . . but stutters on my PC desktop. The stuttering is occurs when the CPU is in heavy use. I’m surprised to see that, since the PC has an i5-4590 processor; it’s pretty beefy CPU-wise. It’s certainly as powerful as the laptop is.

I checked around a bit, and it doesn’t seem like Unity (the engine behind Phalanx’s latest iteration) is known to have performance issues on PC. If anyone has insights, or things I might look into, your thoughts would be gratefully received. I’ll keep up the sleuthing on my end. 🙂

“Everything that Begins Has an Ending”

I lived in Japan when Matrix Revolutions was coming out. The posters were up at the local movie theater, a drive-in at the top of a mall parking garage:

b5-matrixrev

The text across the top translates, roughly, as “everything that begins has an ending.”

On Friday I begin the second of my two years at the NYU Game Center. I am both looking forward to the rest of what’s been an excellent program, and am horrified at the thought that in just nine months I’ll no longer be working day-to-day alongside some of the finest designers around.

Everything that begins has an ending. I’d best make the most of the time before then.

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.