Showing posts with label designer's notes. Show all posts
Showing posts with label designer's notes. Show all posts

Wednesday, July 8, 2026

CC: Adversary, Part 2 — New Horizons (I)

This is part 2 of a series of articles about my upcoming Combat Commander: Adversary game module—a solitaire system that lets one player duke it out with an automated opponent on the storied battlefields of GMT's classic wargame.

I explained in part 1 of this design diary that I started working on Adversary quite a few years ago, slowly chipping away at one problem after another. Most of those problems I expected from the get-go: I knew going in I'd have to design systems for the bot to select units, to order them around, to react to player actions, to act according to secret objectives, and so on.

But there was one problem that did come as a surprise—a shock, even—and which nevertheless made me smile in wonderment, because it unveiled a process we humans all go through without thinking about it when we're playing games like Combat Commander. And that thing's never mentioned in the rulebook, either.

Wargames all run on a variety of metrics: line of sight, range, firepower, cover value, movement allocation, and so on. Most of those concepts have a numerical value, or else a binary state, attached to them. The rulebook can direct you to perform X "if the attack roll is higher than the defense value," or that you can't perform Y "if the unit lacks sufficient movement points to reach its intended destination." Those concepts are quantifiable, and the rules teach you how to handle them.

When I set out to test an early version of, say, the movement system, I had the bot run through a simple algorithm intended to conform to the automated opponent's "intentions" at that point in the game. It wants to send some of its units to better cover? That's easy enough: look at the cover values of neighboring hexes. On a quest for higher elevation? Climb a neighboring hill. But what do you use to break a tie if several hexes qualify? Well, obviously you just send the units to the hex where they'll better be able to see the enemy that's com

And there it was. What I started out calling "coverage" was that elusive metric, that value we all compute in our heads even though we never speak it aloud and the rulebook doesn't cover it. (It just doesn't need to.) How well can you see around you from that point on the map, so that you can fight off incoming enemy units? It's a very human, very intuitive notion that's blindingly obvious to us meat sacks. But for a bot trying to hold its own in a tactical game, it's a different matter.

No sooner had I made that realization, however, that I put it aside—temporarily. I wanted to finish the ordering system first, always keeping in mind that the bot would eventually make use of that "coverage" thingy.
(Much later, Kai Jensen at GMT would suggest I pick a different label for that value, pointing out that the game already used "cover" as an operational term, which might bring about unwanted confusion. She was right, 
as usual, and I renamed that concept "Horizon.")

A workable definition of Horizon became a burning need when I set out to design setup rules for the bot. At the start of any given scenario, each faction gets assigned an array of units it must deploy on its side of the map. Humans perform this task without a hitch, using established notions to hedge their bets and spread the risk: "I'll split my forces into two main stacks so that I can pack serious firepower at both ends of that road, and still remain mobile if I need to leave in a hurry." We also wield the idea I'm calling Horizon like we came out of the womb playing games like Combat Commander"I'll put my guys at the very edge of that hill, so they can see—and shoot atthe entire valley below." (It's something akin to balancing a mathematical equation, except you're using machine-guns in lieu of plus signs.) No need for numbers, man: you just LOOK at the map and you see it, clear as day.
But a bot lacks eyes, and so it very much craves its numbers.

My first definition for Horizon remained open-ended. I knew I had to give the bot a Horizon value for each hex on the map so that it could compute decisions in an effective manner. And it seemed to me like that value should be the number of directions, from each hex, into which units standing there could see "far enough." Just how far was enough remained to be determined.

I decided to start with 6; in other words, Horizon would be, for any given hex, the number of directions into which you could see at least six hexes away. Since I defined direction as "looking through one of the hexsides," it meant the maximum Horizon value for a hex would be, coincidentally, 6.
So far, so good. I now possessed a metric I could access to steer adversary units towards hexes more suited to their nefarious purposes.

Of course, on most maps, a line of sight six hexes long is very hard to achieve, which meant that most Horizons would be listed as 1 or 2; maybe a little more in certain, rare cases. Hardly a usable data point.

Map #2, also known as "Where LOS Comes to Die"

For a brief moment I considered including in my calculations the range of that hypothetical unit (i.e. how far it can shoot) standing in the hex. But considering the wide variety of ranges assigned to units in the game
not to mention the weapons they carry!it became clear that that way lay madness.

So I opted to attack (assault? melee?) the problem from the opposite direction: I made the Horizon requirement a LOS of 1. I knew it wouldn't suffice, but I wanted to build up to the right number. Plus, looking at Horizon values for hexes with such a short LOS (which instantly became 5 or 6 for almost every hex on most maps) helped me rephrase my question: instead of wondering how far is enough for a unit to see around itself, I started asking myself how far the unit needs to see. Or, considered differently, when do human players stop caring, in the heat of the moment? Two hexes (as in "two hexes away") opened things up a bit, but three hexes felt just right to me, and I proceeded to run Horizon evaluations using that metric.
(Much later, out of curiosity, I ended up computing the average range of "common" units across all six nationalities in the game, ignoring those elite dudes who only show up in a handful of scenarios or when they feel like it. It worked out to 3.17 hexes.
)

It didn't take me long to realize that my "base 3" Horizon system worked like a charm: the adversary was making great use of it, shifting its units towards spots that would put my own guys at a disadvantage. Naturally, I took some time to experiment with making the requirement 4 hexes, but there was no joy to be found in that expanded definition. Without doubt, Horizon was a 3-hex-range affair.

End of story? Hardly.

You see, back when I was attempting to read my bot's intentions in hex leaves, I still wasn't in "publication mode." I had yet to reach out to GMT, and I was still building this thing for me. (Take a look at Part 1 in this series of articles for a detailed retelling of those halcyon days.) And as such, I was trying to make do, as much as possible, with whatever shipped in the Combat Commander box. This doctrine meant that players (i.e. just me at that point) were required to figure out the "best Horizon value" at various moments in the game, and to compute that value mentally. I got really good at it—although it still slowed things down—but it was an insane thing to ask of everyone else.
Would you find it thrilling to stop in the middle of a turn to compute LOS in six directions for half a dozen hexes? Yeah, me neither.

Then Jason Carr (that guy again!) reached out across the screen during a video call and virtually slapped me. And I'm glad he did.


(Next time: MOAR about Horizon charts!)



* * *








Sunday, June 14, 2026

CC: Adversary, Part 1 — Beginnings

This is part 1 of a series of articles about my upcoming Combat Commander: Adversary game module—a solitaire system that lets one player duke it out with an automated opponent on the storied battlefields of GMT's classic tactical wargame.

I didn't start thinking about a Combat Commander "bot" (as they are commonly referred to) because I needed one. I am blessed with an environment filled to the brim with CC nuts; that includes my closest friends andit seems at timesmost of the adult population of the greater Montreal area.

So no, it wasn't for lack of opponents that I started to pull on the automated opponent thread, but rather because I began asking myself a singular question: if I ever decided to build a bot for my favorite game, how would I go about it? After a while, I decided to try to answer that question.
Still, I kept telling myself I was not designing a solitaire system for CC: I was merely exploring how I'd do it IF I were to do it. And much like that delicious snippet from The Princess Bride ("Good night Wesley, I'll kill you tomorrow"), I kept telling myself, "I'm not designing a CC bot; but if I decide to build one tomorrow, this is how I'll do it."

Before long, however, the problems became so engaging—and my imagined solutions so exciting—that I had to come to grips with reality: I was designing a bot for Combat Commander. The battle plans were coming along rather nicely, as a matter of fact. So nicely that I felt I had better pump the brakes a little and ask myself a different question: Where was I going with this? Was I just doing this to challenge myself, to try to crack/untie that nut/knot (pick your metaphor), or did I harbor ulterior motives?

Allow me to take a step back before I continue, because at this point I need to demonstrate just how much of an idiot I can be.

* * * * *

Back in ancient times, circa 1999, I was living in California and working for Lucasfilm. (That's incidentally when I met and befriended Combat Commander designer Chad Jensen, who was—unbeknownst to me—already at work on his seminal opus.) I was also spending my weekends doing some translation work for Steve Jackson Games, which meant that Steve and I were trading emails on a regular basis. At some point I came up with the concept for what would be my first published game, Proteus: a chess variant where you're moving and evolving dice across the chessboard, building up your army to answer new threats over the course of the game. I had designed the whole thing and playtested it (in the game store where Chad worked, amongst other locales), and the contraption behaved surprisingly well.
Next steps? Naturally, I was wondering if I should try to get the thing published; but at the same time it was clear to me that anyone armed with the rules of the game could make up their own set using regular six-siders and any 8x8 square grid. So I fired off an email to Steve Jackson
—who'd published Tile Chess not too long before (and which was one of the games I was translating for him, for crying out loud)—and asked him... well, no, not the question you're thinking about.

Because I'm an idiot.

I gave him an overview of Proteus and asked him for his professional opinion: should I just get the rules published as a DIY article in a gaming magazine (yep, those old printed things, of which there were many in existence back then), or rather attempt to get the thing published as an actual game?


To his credit, Steve didn't call me an idiot. He replied that he was curious about the design, and would I feel comfortable sending him the rules? 

I happily did so. The next day, he answered my question in a way I hadn't considered: he offered to put my game out there.
(His actual words were adorable. He wrote to me: "Would you let me publish this one?")

* * * * *

Alright, back to our regularly scheduled programming.

Working on and off on my little non-project, I had reached the stage where I'd say about half the solitaire system was done. There was still a lot to execute, but I had solved all of the major problems, and my entire roadmap was in place. 

That was in the fall of 2019, and that's when I reached out to GMT's very own Tony Curtis, with whom I'd had occasional online encounters over the years. I told him I had been working on a CC bot, stated the current advancement of the project (half-baked at best) and briefly described the problems I'd tackled and how I'd put them to bed.

Was I pitching him my solitaire system? Of course not. (Haven't you been paying attention?) I asked Tony if they had something of that nature in the pipeline for Combat Commander. Because if they did, then I'd put my own project on some indefinite backburner and enthusiastically wait to see what they'd come up with.

Tony's reply was two-fold: No, they weren't working on such a solitaire system. And would I mind showing him what I had so far?
I was happy to oblige. And in my mind, I still wasn't pitching him my design. It was a sort of professional courtesy, a healthy curiosity between designers. Neat, right!
(My daughters just called to express their desire to opt out of wearing my last name.)

Plot twist: I didn't hear back from Tony. The guy who reached out to me, after a couple of months, was Jason Carr, Director of Game Development at GMT. He wrote "This is a sound approach" and encouraged me to finish the system. Which took a couple more years of me working on Adversary whenever Life would unclench its vise-like grip for a few hours. At some point, Jason confirmed GMT wanted to publish my system, my heart skipped an unspecified number of beats, and what followed was a series of back-and-forth messages and a visit to GMT HQ for one of those legendary "Weekends at the Warehouse," during which I had a chance to meet a gaggle of designers and rub elbows with the best and friendliest in the business. (The absolute sweetest of them all was Chris Janiec, but don't tell the others I said so.) I flew back home with a series of notes that led to more feverish late nights and never-ending weekends of head scratching and rules revising, until Gene spoke those momentous words: "I have a free slot on P500 next month, and I'd like to fill it with CC: Adversary. Is it ready enough?"

It was.

An old spreadsheet along with one of the first
versions of the German deck, pre-tarot size


There's still some ways to go until the module is considered done, but the stormy seas are behind us. And the horizon's looking mighty fine. 

(Speaking of which, next time we'll talk about the Horizon charts!)


# # #









Friday, July 7, 2023

Designer's notes — Proteus

(This article was originally published in Steve Jackson Games' own Pyramid Magazine back in 2001, a faraway era when print publications still thrived. I thought I'd revive it here—in a slightly edited format—to celebrate the 2nd edition of Proteus, arriving this summer.)


“And Proteus began at once with his old tricks, first changing himself into a lion with a great mane. Then suddenly he became a dragon, a leopard, a wild boar; the next moment he turned into running water, and then, finally, he was a tree.”
Homer, The Odyssey, Book IV

I designed the basic mechanics of Proteus while waiting in line for the Back to the Future ride at Universal Studios, in California.
Seriously.

For some time I had been toying with the idea of playing a game with dice for pieces and the rules of chess for movement, but I had never sat down to figure out how such a game might work. I don’t really like chess: I find the frame of the game too restrictive (and I don’t mean the edges of the chessboard), but I’m fascinated by the movement possibilities of chess pieces. As a result, I oftentimes contemplate chess but rarely play it. I had tried my share of chess variants, but somehow I felt that my “dice chess” idea would create something interestingly different. If I could only figure it out.

Things stayed pretty much status quo for about two years. My brain might have been polishing up some 
concepts on its own, but I didn’t consciously work on the game until I found myself stuck in line at Universal Studios.
You see, I was alone in Los Angeles for work and, with a free afternoon ahead of me, the temptation of the Universal Studios demon proved too great to resist. So I went. At some point I ended up trapped in line at the Back to the Future ride, and since I had no one to talk to and hadn’t brought a book or a smart phone (we're talking 1999 here...), I thought it might be worth my while to start laying down the foundations of my dice-chess game. In my head. In any case, it would be a lot more productive than staring at the Hawaiian shirt in front of me for an hour. By the time I got on the ride, I already had a good idea of the inner workings of the game. And when I stepped out of my rigged Delorean (great ride, by the way), I couldn’t wait to get back to my hotel room and write everything down. But the day wasn't done yet, so I used the rest of my in-line waiting sessions to run a few mental tests and do some basic math.

At the end of the day, I drove back to the hotel with my head full of sketches and design notes. I knew that my game would be a two-player affair and that player turns would alternate. I also knew that each player would start with eight dice, that those dice would show a different chess piece on each face, and that the goal of the game would involve capturing several pieces (as opposed to neutralizing one particular target). Furthermore, a player would perform two actions on their turn: move a die and rotate a die (to change the identity of that piece) one step at a time. Most importantly (hey, we all have our fixations), I also had a name for the game: Proteus, the Greek god of ever-changing form.

I had trouble falling asleep that night, as Morpheus was always bumped by Proteus who thought some of his needs still had to be addressed.
And he was right.

First of all, I didn’t know how you were supposed to win the game. I entertained a vague notion related to taking out as many of the opposing pieces as possible, but somehow that felt wrong. Moreover, I still hadn’t found a balancing mechanism that would prevent powermongers from rotating all of their dice up to queens. There was also a delicate matter: I didn’t know what to do with the king. Since I was hellbent on eliminating the concept of checkmate from Proteus, did it make sense to keep the king in there?
I eventually managed to switch off, despite having resolved none of the above problems. I did try to refine and complement my notes the next morning on the flight back, but somehow I didn’t make much progress. 
Then, in one evening, I answers practically all of my questions.

For the sequence in which the chess pieces would "evolve," I chose to adhere to the traditional chess value sequence, with one exception: I placed the bishop in front of the knight, because I felt it would open up the game faster. That gave me pawn -> bishop 
-> knight -> rook -> queen. Still no idea about the king, though. But it became obvious that a player would have to move a die and then rotate a different die; infiltrating the enemy camp as a bishop and immediately transforming into a knight smelled of overpowered tactics.

Interestingly enough, the problems of game balance and victory conditions were vanquished at the same time, using the same solution. Back then I was playing the game with standard six-sided dice, remembering that the 6 was the queen, 5 the rook, 4 the knight, 3 the bishop and 2 the pawn (1 could have been the king, but meh). I thought it might be fun to win a game of Proteus by scoring the most points, with each piece being worth a certain number of them. In assigning point values to the pieces—I simply chose the number of dots on each corresponding die face—I discovered that such a scheme would also balance the game, because the stronger pieces would be worth more points upon capture.

Still, what about the king? Well, since you achieved victory through points, there was little incentive to keep it in the game. Without its essential function
—keeping you alivethe king just becomes a limping queen, and that’s just boring given the morphing nature of game pieces in Proteus. I could just have thrown the king away, but this was an opportunity to inject another new concept into the game. So instead of eliminating the king, I replaced it: the new piece would not move at all, but would also be impossible to take. I named that piece the fortress.

With these problems handled, I could sit down and play a few “real” games against myself. Everything was going rather smoothly: the game was simple, played fast, yet retained its potential for deep strategy. And then I hit a brick wall wearing an evening dress and a crown.
The queen.

Because of the mathematical progression of piece values, and because of the similar progression of their respective powers, the game was pretty balanced—except for the damn queen. The problem resided in the power of the queen being much greater than its point value. Between a rook and a queen, the difference in power is immense; yet the difference in point value was only one. That couldn’t work. One solution was to raise the point value of the queen, which meant assigning it some 
ridiculous valuesay, 12 points. But then a player capturing a queen would probably win, which would sort of take me back to the issue I had with the king in the first place. So instead I gave the queen a weakness: you could capture it by moving to the square right behind it—stepping on the queen's gown, as it were.
But would that work? I played some more test games and, sure enough, it did.
It was time to take Proteus out for a spin.

I brought my prototype to the Santa Rosa game store I frequented back then, and a couple of friends expressed interest in the game. We played it over and over again, and while I kept fearing that some obvious flaw would blow up in my face, no such thing happened. Then more people played it and the game still held up. We did toy around with a few things. For instance, we increased the number of pieces each player starts with (up to 12), but we only succeeded in creating quite a mess of a traffic jam, with games that would take more than an hour to completion, which was way too long for me
. We also experimented with fewer pieces for each player, but the game became boring and predictable. Eight—my original numberseemed to be just right.

At that time I had just finished translating both Illuminati and Tile Chess into French for Steve Jackson Games, so it was an easy matter for me to tell Steve about Proteus. I briefly described the game and asked him if I should just publish the rules in a gaming magazine, or try to find a publisher. He asked to see the rules, and wrote back the next day with a question: "Would you let me me publish it?" In-house testing would take place, naturally, but he asked for only one change up front: 
that the fortress become the well known "eye in the pyramid" Illuminati symbol that also doubles as the Steve Jackson Games logo. And before I knew it, my game was on the list of upcoming Steve Jackson Games titles.
So I got to work.

You want dice? We got dice.

The thing was, I hadn’t really planned on selling Proteus to anyone; I was just playing around with the game for my own enjoyment. But now that it was going to be out there in the wild, I thought the door was wide open for a series of intriguing variations on the basic rules. So I designed and tested a handful of variants, four of which ended up in the finished game: Trade-Off, Russian Roulette, Wall Street and Polarity. That’s actually five if you count the two different setups for Wall Street. Steve also suggested an additional way to play, which we ended up calling Warhorses, for a total of six variants.
Where did the discards go? Right this way. 

RANDOM SETUP
This was the shortest-lived of the variants I came up with. Rolling your dice to see what pieces you'd start with was the dumbest idea this side of the sun, and it only survived for about half a setup phase—I realized pretty fast there was no way I could make this work. Still, the concept of rolling pieces (because they are dice, after all) appealed to me, and that eventually became the Russian Roulette variant.

PYRAMID
The idea here was that pieces could only capture opposing pieces that were of equal or higher value. So a pawn could capture everything (except the pyramid, but that’s a given), and a queen could only capture other queens. This didn’t work because no player wanted to upgrade to stronger pieces.
“So what if you have a knight? I’ll just stay with bishops and the only thing you’ll catch is a cold.”
I tried playing the Inverted Pyramid (capture downwards) but it only succeeded in destroying the effectiveness of the weaker pieces and handing a flak jacket to the stronger ones.

BLACK & WHITE
Whenever you capture a piece, its point value is the standard one if it was captured on a black square, but is whatever’s on the bottom face (or 7 minus top face) if it was captured on a white square.
Pretty inventive, right? This one I did send to Steve, but in the end it was not included with the rest because it didn’t add all that much to the strategy. Plus, the configuration of the Proteus dice would be different from that of regular six-siders in order to facilitate the upgrade/downgrade procedure, and that would throw the point balance out of whack.

There were other variant possibilities, but most of them involved complicated rules, and I didn’t want to burden Proteus with unnecessary weight.
There was only one thing left to do, and that was asking Steve for a favor: I wanted to dedicate the game to one of my oldest friends, whom I’d known since we were both nine years old, and with whom I’d shared a universe of close games, hot matches, and gaming disputes. I gave Steve two versions of the dedication, with the short one ending up in the game. Here’s how the long one read:

“This game is dedicated to my dear friend Alexandre "Le Brown" Boivin, who started bugging me about designing my own game over a decade ago and hasn't stopped since. I'm as happy to see my first game published as I am to finally shut him up.”

There is a final variant, which Steve came up with right after he played his first game of Proteus. It didn’t make it in the game because of space considerations, but since there’s no limit on electrons (yet), here it is:

DICTATORSHIP
This is played with regular chess pieces and two Proteus dice. Each turn, roll the two dice. You must move one of the two pieces showing on your dice (pyramid=king). If you can’t make a legal move with one of the indicated pieces, you don’t move.
If this is too hard, roll three dice to give yourself more options. Or play with a handicap: the stronger player gets only two dice, and the weaker player gets three.


Now, what about my next game? I do have a few ideas floating around in my head; I’m trying to arrange a trip to Disneyland to sort them out.

* * *

P.S.: Just as I was about to push this article live, a delivery guy handed me my advanced copies of the new edition! So here is the new Proteus, in all its glory:

Yes, it now comes with a board!



# # #