DISASTER AT SEA (by Tom Russell)

I've done a number of games that hew pretty closely to established concepts and mechanisms (done my share of hex-and-counter games with ZOC and step-losses, though oddly I've avoided going odds-based in all but one instance) and a number of games that try to do something new and unusual. The latter tend to sell better than the former, which is always rewarding, and those more than the "normal" games have probably won me what modest following I have as a designer.

The danger with doing something new and unusual is of course that sometimes it doesn't work. That's not so bad, in and of itself. It's something I encountered a lot when I was just getting started as a designer, and it's part of the process. You take stock of what went wrong, you tinker with it, you make adjustments, you test it again, and eventually you end up with something that's worth showing to the public. It's something that even happens with hex-and-counter games: this movement allowance is too liberal, this combat unit isn't robust enough, this supply rule doesn't work. So you fix it and you try again. It's easier to do that with a "traditional" wargame, because you have that solid foundation to fall back on. And, actually, because of that foundation, you're less likely to come across something that just plain doesn't work in the first place.

But when you're working on something more unusual and idiosyncratic, you're more likely to stumble, and you're also more likely to have no clue what went wrong or how to fix it. Is one little thing broken, or is it everything? Is any of it salvageable, or is the whole thing a wash? You have no clue. It's incredibly disorienting and frustrating. Speaking of...

I've been working on an Age of Sail game. Partially, there's a business motivation for that - what self-respecting wargame company doesn't have its very own Age of Sail game? But mostly it's because I find the period rich and fascinating. I'd like to play an Age of Sail game that can cover large fleet actions while simultaneously fitting on my table without turning into a marker farm. I have yet to find a game that can cover all of those bases. So I thought, well, I might as well design one.

It started with research, like it always does, and then I let things percolate for a while in the old noggin. I don't actually start "designing" the game - writing rules, coming up with mechanisms, creating counters - until things have coalesced to the point that I have a clear picture of what I want the game to be. This helps to focus me on the core elements of the design. It also helps me know when a design is done; does it do the things I wanted it to do? Then it's done.

The core elements of this design were as follows -

1. It would be a single-map game.
2. It would not get caught up in tracking six different kinds of damage sustained over time.
3. It would not give the player total control over their fleet.

That last one was the biggie. A lot of Age of Sail games - heck, a lot of wargames - let the player move each unit where they see fit, within whatever those movement rules are. I don't actually have much of a problem with that in land games, which is probably somewhat hypocritical, because I absolutely have a problem with it in Age of Sail games. Even a cursory glance at the history will tell you that coordination was the exception, not the rule, and plans more ambitious than "float past the other guy with potshots" were almost always doomed to failure. There's a reason why naval battles were so seldom as decisive as they end up being on the game table.

So, the core idea, and selling point, for the design is that you don't have that kind of control. Instead, there's an Orders system. At the start of the game, you assign Orders to specific Triggers - so, when the Trigger applies, that's the Order that is to be executed. These Orders dictate the behavior of the ships, movement, combat, you name it. You don't, however, get to change the Orders as you might in something like the Musket & Pike series. The plan you made at the beginning of the game is the one you're stuck with. There's a little more to it than that, and there are some tactical decisions to be made, but the heart of the game is entirely front-loaded.

Being committed to this idea - which I still think should and can work like gangbusters - I turned my attention to movement. Because if you're performing movement as dictated by your Orders, then movement is going to be done somewhat automatically. You move this counter here and that one there, without much by way of decision making. And that's fine for what the game wants to achieve, but moving twenty-odd counters so many hexes in this direction or that in accordance with programmed movements is a little tedious in a way that making a movement decision for the same twenty-odd counters is not. "Tedious" is, of course, not a quality you want one to associate with a game.

And I had that goal of keeping the game to one "full" mapsheet measuring 22" x 34". The problem with naval games is that there's a lot of movement on down the line, necessitating a lot of table-space that I just plain don't have. It's especially frustrating because, on the whole, the "terrain" is featureless. It's not like the Ship is moving closer to a mountain or bridge or forest hex or whatever. It occurred to me that the spatial relationship between a Ship and the "terrain" didn't really matter - only the spatial relationships between Ships did. What if, I wondered, what if the Ships only moved relative to one another? If Ships are running, they don't move at all. If a Ship is reaching or beating, it only moves relative to the running Ships. Oddly, this meant that a ship that was in irons would move more than the rest, because it was "standing still" while everything else was moving.

This is a great idea, I thought. It's a little weird, sure - I mean, here we have a naval game, which is maneuver dialed up to eleven, only there's hardly any maneuver. But it would reduce the amount of time making adjustments to the line, and reduce the amount of space needed to fight out a battle. It would very deliberately move the focus away from tactical distractions and center it on the strategic planning phase.

So, I built my movement rules around that. I wrote my rules and I built my counters, and in the late morning I went out to my garage and set it up.

I had one fleet that was reaching, and another that was beating - moving in opposite directions. The orders for each fleet were to maintain their distance of ten hexes - therefore, after movement, the two fleets should still be ten hexes apart, running parallel, with one fleet further west and the other further east. Dutifully, I began to resolve the relative moment procedures in place for reaching and beating ships under those orders.

And it immediately fell apart. The ships weren't maintaining their distance - they were further apart. The fleet that was moving west was now further east, and the fleet that was moving east was now further west. What.

I spent the better part of an hour moving counters around, trying to figure out what parts of the relative movement system worked, and what parts didn't. The procedures worked fine for ships that were moving relative to ships that were running. Which is, after all, what I used as the basis of my mechanism. But ships that were reaching and beating didn't move relative to each other, which of course would result in a distortion even with a running ship in the mix. This would have been obvious to anyone who wasn't me long before any counters got onto the map. I'm a little embarrassed to be telling you about this, because it's such an obvious thing. What can I say? Sometimes you get too close to an idea and don't realize how awful and broken it is.

Now, everything in the game is built, to some degree, around this movement mechanism that just plain doesn't work. So much so that I can't even see if any of the rest of it works - the Orders mechanism, the gunnery and damage mechanism - because none of that exists in isolation. Either I'll need to find a way to make the relative movement work (and I'm pretty much stymied right at this moment), adjusting the rest of it accordingly before the next playtest, or I'll need to rebuild the game from the ground up around a new movement mechanism. And in the latter case, I might end up going with something more traditional, something more bread-and-butter, but I'm not entirely sure as of yet how to do that while keeping the map size manageable and making it less tedious given the automatic/programmed nature of the movement.

So at the moment - writing this about an hour after that first playtest - I have no idea how I'm going to fix this, or if it's even possible to fix it, or if it's even worth it. I'll figure it out or I won't. I've been here before, and I'll be here again: it's all part of the process. There's some consolation in that knowledge.

And perhaps some comfort for the first-time designers who might be reading this, frustrated that something isn't working, wondering desperately if they can ever make it work. Relax, guys. You can have over two dozen games published, and you will still have days and projects where you feel like you're banging your head against the wall like a hopeless amateur.