HEXTOK!: Q.A. # 1

Last week, I very quickly whipped up a quick and simple small-scale multi-map hex-grid based tabletop tactics game in the course of the evening. My goals in doing so were as follows:

• I wanted there to be very little for the player to keep track of in terms of stats/points/etc. For this reason, I used a simple two hit point system, with one side of a token (such as a coin or button) representing two hits and the other representing one.
• I wanted to have an in-battle leveling-up mechanic, which in my experience is usually the purview of video game tactics games and not their table-top brethren. This game features three levels of units, with a simple point-spending system to recruit new units/level them up.
• I wanted to have a very forgiving comeback system that prevents what David Sirlin calls the "Slippery Slope": that point in the game where one side has it pretty much in the bag, and the other side spends the next twenty turns knowing they've already lost. Players earn points for defeating enemies and holding bases, but also when they're down to one or two units (out of five). Respawning is cheap (healing less so), and a forced spending mechanic that resets your pool to zero whenever it hits ten prevents one player from securing a tremendous numerical lead on the other.
  

The resulting game, Hextok, had its first Quality Assurance session today. And even though (and perhaps because) a number of major changes were made to my original design in its wake (more on that a graf or two hence), I'm very pleased with the results so far. First and foremost, the thing is playable, and I know that sounds like a silly thing to worry about, so let me explain.

I try to play-test all my video games as extensively as possible, and have always benefited from the process immensely, rethinking and and refining and redesigning not only things like the user interface, but whole game mechanics and level designs. But before I ever sit anyone in front of a computer and say, "play this!", I've played through it on my lonesome dozens of times. I try to get my game pretty damned polished and bug-free before I let anyone else touch it; if a concept I'm working on isn't fun or working for me, I know it's not going to work for anyone else, and I usually scrap work on it or restart before my play-testers ever catch a whiff of it.

But since this is a board game, and a two-player board game at that, I don't have that luxury; I can't see if the game is fun, if it works, if it fits together, or if there are glaring and obvious mistakes in its design, until I get another person in the room. I'm very picky about unveiling something that I think is only half-formed, but in this case I didn't have a choice. My worse nightmare is that the game would be a confusing, broken mess, and that my play-testers, upon leaving, would stop on my porch and shake their heads sadly.

That, fortunately, wasn't the case. The players had fun-- with the first map more than the second-- and there were several thoughtful "hmms" as they tried to figure out a way out of a predicament or turn the tables on the other player.

That's not to say it went off without a hitch; as I said, there were some major changes made to the rules, mostly nerfing the level three unit. In the version I presented them with, the level three unit moves eight hexes, does instant-kill damage, and moves through water at a cost of two movement points per hex. On the game's relatively small board (103 hexes altogether), the level three just dominated the game.

This was exacerbated by the fact that the player was able to spend a finite number of points before the game to recruit from all three levels. Even when one player had five level-one guys and the other one level-three and one level-one, the second player managed to route the first at every turn, causing his ranks to drop like flies.

One of the players, J.D., suggested a very smart nerf on the level-three: reduce his movement to five hexes, like the first. This makes the second stand out more-- he moves eight hexes and has a wider attack range than the other two-- without getting rid of the level-three instant kill that was so vital to making it desirable. And the water hexes-- which cost two movement points for the level-three but were impassable for the other two levels-- would be even more of a challenge.

They were, in fact, too much of a challenge. The next game, they played with this five-hex movement rule for the level-three, and the water just slowed the pieces down so much that the sense of power was gone. And so, we removed the slowdown on the water hexes-- the level-three unit moves five hexes only, and can move through water, but there's no difference in his movement speed.

The other problem we noticed is, with a four-point across the board buy per unit to recover a lost hit point, that a level-three piece was basically rendered immortal if its player was holding enough bases. The other player would attack the level-three, the level three would heal itself for four points and kill the other unit, repeat, repeat, repeat. Discussing it with the play-testers, the idea was bandied about that we should make the level-three heal cost more than the other two levels. I was reticent about this, having concocted what I thought was a simple and easy-to-remember point scale: 2 for a level one, 3 to level up to two, 4 to heal, 5 to level up to three. That's 2,3,4,5, simple and clean.

What I decided instead was to remove healing for the level-three unit entirely, making the piece as valuable as a Queen in Chess. (Because it is so deadly, one wants to be extra careful with it.) And this (I think) should prevent the ugly kind of losing-loop I want so strenuously to avoid.

Feedback from my gamers also convinced me that a level three player should not be available for a starting party, and that led me to discard my prior (and somewhat confusing) system that allowed for various strategic starting line-ups in favour of five level-one units for each player: equal and balanced, ensuring that no player dominates the game right out of the gate.

There'll be a few more local QA sessions before I start contacting web-folk to play-test for me; if you're interested in being part of the latter, drop me a message in the comments field below, or shoot me an e-mail at milos_parker at yahoo dot com.