I used to love this game back in the day. I have fond memories of playing it on my NEC Turbographx 16. The Turbographx was sort of niche even back then – Genesis and then the SNES were much more popular, and to be honest I eventually sold my TG16 and moved on to those too, but still, this game always stands out as I think back to that era.
So one day I’m talking with Claude – because I do that for no good reason sometimes. My kids have just bought a 3D printer “with their own money” (whatever that actually means) and it occurs to me, what a great project this would be. Take the rules that govern Military Madness and use them to create a board game, and have my son print the pieces.
A really intuitive division of labor presented itself immediately: I would design the rules, and my son would design the pieces. I know the game – remember a surprising number of rules from 37 years ago – but have no real patience for physical building; Sammy is the opposite, does not know the rules but loves building things.
The first thing I did was to remember what I could about the rules. And if you’re reading this post and think I got something wrong, please leave a comment and let me know. I’m working from memory, and also from firing up the game on an emulator and seeing what it looks like is happening. I also found a couple of sites where people had recorded some information about the game mechanics – this one was the most helpful.
RULES
A first approximation of the rules is this: the game is made up of military units that move on a hexagon board, where each hex represents a type of terrain. All units are either air (i.e., an airplane) or ground-based (a tank). There are something like 20 different named unit types (a full list can be found here). They have names like “Bison” (tank), “Charlie” (infantry), “Hunter” (bomber/fighter jet), “Atlas” (long-range artillery) or “mule” (transport vans).
GOAL
There are two sides, and the goal is for one side to destroy all the other side’s units, or to walk a pedestrian unit (only a pedestrian unit will do) into the opposing team’s base.
TURNS
The game is turn-based. One side makes all its moves, announces that it is done, and then the other side makes all its moves, and so on, until the game is over. Each unit on each side may move once per turn, and attack once per turn. Most units must move first then attack, but a couple of special units can move after they attack. Some units are immobile and so can attack but not move.
COMBAT BASICS
Units have an attack rating – two actually – air attack (how strong they are against air units) and ground attack (how strong they are against ground units). More complicated is that some units can attack only units adjacent to them (which the game calls “direct” attacks); some units can attack only units not adjacent to them (“indirect” attacks). So actually each unit has 4 attack ratings – direct vs. ground, direct vs air, indirect vs ground, and indirect vs. air. Whenever the attack is direct, the attacking and the defending units each attack and defend against each other. Whoever initiates it doesn’t have any special status – both attack each other simultaneously. Units also have a defense rating. Initially, each unit has a “Strength” of 8 – which basically means a unit represents a cluster of 8 airplanes, tanks etc. that you move as a group. When units attack each other, they essentially reduce each other’s strength, representing individual entities within the cluster getting destroyed. When a unit’s strength reaches 0 it is eliminated from the board. The game determines how much each side reduces the other’s strength by doing some behind-the-scenes random number work. Higher attack tends to do more damage than lower attack, and that’s somehow run against the unit’s defense. The result is not deterministic – this isn’t like Magic the Gathering, where each unit has an exact number of damage to allocate and an exact amount of damage it can receive. I’m not really sure what the game does to make the damage determinations. I did my best (see below) to develop a system that feels like it approximates it, but making changes that I hope will help it work as a tabletop game.
Attack vs. defense seems to be the core mechanic, but when actual combat happens, the game makes a sequence of modifications to the base attack numbers. First, it multiplies attack and defense power times unit strength. So if a unit has a base attack of 10 (say, an infantry unit), and there are 8 soldiers remaining in the unit (8 strength) the game will list 80 as the attack. Same with defense – 5 defense x 8 = 40, let’s say (these numbers are made up). After the base number of computed, the game augments each of these stats by a factor determined by the unit’s level of “experience” – how many battles it has been in. Each unit can earn up to 8 small stars for combat valor. A full 8 small stars (represented on screen as a larger star) means the overall attack and defense are doubled. 1 small star, I think, adds ⅛ to the overall value (so 12.5%). Also, whatever terrain the unit is positioned on adds a defense bonus, expressed as a percentage. Being on a road adds 0%; being on dirt adds 5%; a hill, 10%, etc. The game also augments attack and defense depending on the location of other nearby friendly or enemy units, and depending on those unit’s attack ratings and strengths. I’m not sure of the details but I know if a unit is fully surrounded (which means, its 6 surrounding hex “zone of control” is overlapped entirely by enemies’ zones of control) then its offense and defense are halved. If friendly units are nearby, its offense and/or defense are augmented, but I do not know by how much and it’s hard to tell because the game flashes all this info pretty quickly.
So to sum up so far, attack and defense are calculated by:
- Base attack and base defense (multiplied by unit strength)
- Experience modifier (seemingly a percentage bump)
- Terrain modifier (also seemingly a percentage bump)
- Surround effect (seems to be either all or nothing – either it doesn’t affect the attack and defense, or it halves them)
- Support effect (this might be multiplication by a percentage or addition, I’m not sure)
The battle happens by random numbers that are not shown; we only see the on-screen result, as units’ strength is depicted as reduced through animation of tanks, infantry, etc. blowing up or not.
After the battle, each unit’s strength drops depending on how much damage was generated, and each unit gains experience according to this rule: if the unit reduced the other units strength, it receives 1 small star, or 2 small stars if it emerges unscathed from the battle (i.e., its strength remains the same). Units can earn up to 8 small stars, translating into one big star, doubling their overall strength.
MOVEMENT BASICS
Units also have movement stats (which the game calls “shift”). Terrain affects movement for ground units in different ways. Only some units can seize enemy bases (there are 3 types – each basically infantry). Only some units can go in mountains (actually, it’s 2 out of those same 3 infantry types). Units’ shift is affected by the terrain, probably in a percentage-based way too. Units’ ability to move is affected by opposing units’ zones of control. You cannot move freely through an opposing unit’s ZOC. You can move right up to them, and attack them, but you can’t just move directly past them.
THE MAP AND LEVELS
The original game has 32 levels, which represent battlefields on the moon. The blue team (earthlings) battles the green team (Martians, maybe). It was designed primarily, it seems, as a one-player game. You can play two players but it’s hard because the levels as designed were designed to be played as one player vs the CPU. Because of this, the levels are of progressively increasing difficulty – level 1 is very easy for blue, and level 32 is very hard for blue. None of them are necessarily well-balanced for two-player action. As with other games of that era, there are really 16 maps, repeated twice. The terrain for 1 and 17, 2 and 18, and so on, are the same, but the starting units and their starting positions are different. The first map is about 15×10 in hexes – one screen you can see in its entirety, and the last map is about 30×20 (four times as big – you have to scroll around to see the whole thing) Basically the first few levels levels are 15×10, the next several are twice as big (30×10 or 15×20), and some are 30×20. Over the course of the levels, new unit types are introduced, adding new strategic complexities for the player to discover.
BASES AND FACTORIES
Every map has blue base and a green base. Capturing your opponents’ base with an infantry unit means you win. Factories begin either as blue, green or uncontrolled (gold). Infantry units can capture factories from the other team or uncontrolled factories. Factories are actually warehouses – they don’t “make” units. They begin the round with a set number of units within them. Whichever team controls the factory can remove the units from the factory and use them. Factories can also repair units – if a unit strength has dropped below 8, but still exists (so is 1 or more), moving that unit into the base means at the start of the next turn, that unit will be ready to emerge from the base at full strength (8).
How to Make This a Board Game?
My vision was as follows: take each of the units and 3D print game pieces. You’d need to make multiple copies of each unit type because they all recur beyond just one instance. For example – on the first level, blue has 3 bison and 2 charlies; green has 2 bison and 2 charlies. Then 3D print a base board with recessed hex slots (ultimately 30×20, probably modular) so you could represent any level. Inside the hex slots you’d put terrain tokens, so you could generate any of the 32 levels (or levels you could make up yourself) using the board and tokens. Then you’d play the game using the game pieces. You’d need some way to make combat happen without the massive calculations the video game does behind the scenes. So I figured, that would require dice, and some way to scale the numbers downward. The game’s combat numbers usually fall between 0-1000, but obviously that’s tough with dice. So there are both design problems to solve and rules adaptation problems to solve. But between myself and my son, I thought, we can probably make this happen. A perfect summer break project.
I decided to start by doing a mock-up of the first level, and confine all thinking to the first level, which has 2 types of units, simple terrain, no air or transport units, no factories.
First, a lot of Chats with Claude
Say what you want about AI, something it’s pretty good at is synthesizing rules and data sets and answering questions about them. So I went to work asking Claude questions like – based on this data, how do you think the game determines combat results? Based on that, what do you think would be a good dice-based solution? All these percentage modifiers are hard to do with dice so what could we do instead? Essentially, how could we preserve the essence of what made the game fun, but do it on an analog basis?
Some problems immediately presented themselves.
- We need to have some idea of how combat works to port it onto dice
- Then we need to port that onto dice
- This probably involves re-calibrating all the unit’s attack and defense
- We need good models to 3D print, and they need to be an appropriate size
- We need a board and terrain tokens that work with those models
- We need to equalize the levels somehow, to make the game fun for 2 players
- We need a workable movement system that doesn’t rely too much on percentages
- We need a way for factories to stay organized
- We need to easily represent a unit’s changing strength and experience as it moves around the board, and this will be trickier given the number of identical units (this is a HUGE game management issue)
I am not an engineer – the closest I’ve come to being one is taking some computer science classes in late high school and early college. That said, these all seemed like problems I or my son could solve, and I felt pretty motivated to solve them, because I think the end result will be pretty cool. My intuition told me that each of these problems is not discretely isolateable as a “physical design problem” or a “game mechanics problem.” I intuitively saw that those categories overlap – design decisions impact game mehcanics and vice versa. But I thought if we bootstrap our way up, we’d get there.
Version 0 – Proof of Concept
I’m going to go through and describe the initial solutions I developed for each of 1-9:
- We need to have some idea of how combat works to port it onto dice
This took a lot of back and forth with Claude. The game generally produces combat values for between 0-1000, beginning with a base attack, base defense, strength as a multiplier (number of sub-units basically), with percentage multipliers for experience and terrain, potential divisor for surround, and seemingly addition for support, probably calculated using the adjacent unit’s stats in a similar manner. Bison with 8 strength multiplier, 50 base attack and 40 base defense, with no experience and no surround or support or terrain modifiers is thus 400 attack, 320 defense.
Let’s imagine two identical bison x 8 attacking each other – A and B. I think what the game does is compute an attack for A, basically a random number between 0-400, and then subtract B’s defense from that (or possibly a random number for defense, between 0-320). Let’s say the A offense random number is 350, vs the defense random number of 250. That’s 100 net offense. I think it would then take 100 and divide that by the per-sub-unit defense (so, here that’s 40). 100/40 = 2.5. Since the strength is expressed in whole numbers, A kills either 2 or 3 of B’s units, depending on rounding rules – let’s say it picks 3 because 2.5 rounded is usually said to be 3. Then the game does the same thing for B attack vs. A defense – random 0-400 minus random 0-320.. Let’s say that ends up being 200 offense -250 defense. That’s -50. -50 is below 0, so I think then units in A would be unscathed. So what began as 8 A bison vs. 8 B bison becomes 8 A and 5 B.
After that you’d calculate experience bonuses but we’ll set that aside for now.
That’s the general sense of how the game works. I don’t know if “random number between 0 and base attack x strength” and “random number between 0 and base defense x strength’ is really what it’s doing but it’s a good first approximation. I had a vision of reverse engineering by tracking a few battles and then having Claude do some pattern matching, but in fact, I don’t think that’s necessary. BECAUSE – random number generation that high isn’t really very doable or fun in a dice-based game.
- Then we need to port that onto dice.
So I came up with this. If you look at the chart of units, every base attack is between 0 and 90, and all in increments of 5. A Bison’s attack is 40. A Charlie’s base attack is 10. A giant (really huge scary tank) is 90. A Hadrian (mobile artillery) is 45. Everything on the whole chart ends in a -0 or a -5. Meaning they’re all divisible by 20. 20-sided dice are pretty easy to get (especially at my house that plays a lot of DnD). So I took the whole chart of all the units and divided everything by 5 – attack and defense so everything’s attack is now between 2 and 18. Bison’s attack is 10 and defense is 8. Charlie’s attack is 2 and defense is 2. And so on.
Instead of multiplying by the whole unit’s strength, I thought, let’s do combat sub-unit by sub-unit. If the overall unit’s strength is 8 (i.e., there are 8 surviving subunits) you role 8d20. But you don’t add them up. You look at each die independently, and subtract from defense. Claud I came up with a formula. To-hit = 11+(base defense of defender)-/attack of attacker). The 11 might look ugly but that’s just to express this idea: if two opponents’ attack and defense are equally matched, the two terms cancel out, and on a roll of 11-20, you hit. On a roll of 0-10, you miss.
So now combat works like this. Let’s start our battle again A ,strength of 8, vs A. Strength of 8
A’s attack is 10. B’s defense is 8. A’s to-hit is 11+8-10 = 9. This intuitively is true because Bisons have better attack than defense. So Bison vs. Bison should be relatively bloody. 11 (remember, 11-20 on a d20) would be 50% change – even money – 9 on a d20 is better than that to hit – 60% chance.
A’s 8 rolls – 14, 8, 19, 3, 20, 11, 7, 16. According to this rule, A hits 5 times (14, 19, 20, 11 and 16 are all greater than or equal to 9). A misses 3 times (8, 3, 7 are all less than 9). So B’s strength is reduced to 3.
B’s rolls – 6, 19, 4, 18, 15, 14, 6, 7. B hits 4 times, misses 4 times. So A’s strength is reduced to 4.
Again, you’d calculate experience bonuses as a result of the battle, but that’s not relevant right now.
This is a good rough-and-ready approximation for what combat could work like. For version 0, it will suffice. Though there are two problems I want to think about for future iterations. Problem 1 – that’s a lot of killing. When I had Claude compare my dice mechanic to that putative game mechanic by running 100 iterations, in general the hypothetical video game mechanic led to 2-3 deaths in Bison vs. Bison, and the dice mechanic led to 5-6 deaths. That’s a faster game, probably too fast. There won’t be time for experience, terrain, surround, and support to even matter in later rounds if so many units get killed so quickly. Second problem – I distinctly remember in the original game, when you were late-game and you have a strong unit that had leveled all the way up with experience, even if it only had 2-3 sub-units left, it could kill 5-6 enemy sub-units. But the way this is written, any given attacker can only make kills equal to its strength (the number of its subunits). So early in the game, my dice mechanic probably kills too many, and later in the game, too few. I have some ideas for rounding this off but the best is the enemy of the good, so that’s where I stuck for version 1.
3. This probably involves re-calibrating all the unit’s attack and defense
I did that above – the divide by 5 and using d20 seems to solve it.
We also created rough and ready rules for terrain modifiers, surround and support. Emphasis on rough and ready. Basically you add to any given unit’s defense based on its terrain type. +1 for dirt, +2 for mountains/hills. We figured terrain impacts defense, not offense.
For surround, if the ZOC of enemy units crosses into all 6 of your ZOC, your attack and defense is halved. Probably rounding down.
For support, it doesn’t seem realistic to do calculations on the fly for neighboring unit’s attack, defense, and strength. So we just decided on simple modifiers – if an ally’s ZOC overlaps yours, you get +1 attack and +1 defense for each unit that’s overlapping. Regardless of what type of unit it is.
4. We need good models to 3D print, and they need to be an appropriate size
My son is working on this. But we have a big family 3D print queue (my son wants to make Switch accessories, my daughter wants to make animal based fidgets, and this 3D printer is really new). So for version 0, we just used pennies for Bison, and dimes for Charlies. Since the game’s first level is Bison and Charlies.
5. We need a board and terrain tokens that work with those models
That’s way further down the line. For version 0, I found some hex paper on the computer and made a board, and drew in simple colors to correspond to terrain.
6. We need to equalize the levels somehow, to make the game fun for 2 players
First approximation. Level 1 starts with Blue getting 3 Bison and 2 Charlies, and Green getting 2 Bison and 2 Charlies. Clear advantage because this is basically a tutorial level. So I just said, let’s try level one with both sides gettings 3 Charlies. Absolute equality in unit allocation. Later levels might pose other problems but for now, that’s what I did.
7. We need a workable movement system that doesn’t rely too much on percentages
We came up with a “budget” system instead of percentage adjustments. Basically roads take 1 movement point to enter, dirt 2, hills and mountains 3, and mountains are not accessible by anything but infantry. A Bison gets 6 movement points, a Charlie gets 3. Those are from the original game but the budget isn’t,
8. We need a way for factories to stay organized
Level 1 has no factories but I have a visiion of a 3D-printed factory that has like 4-6 hexes where a unit can sit. The factory sits in front of the person who controls it.
9. We need to easily represent a unit’s changing strength and experience as it moves around the board, and this will be trickier given the number of identical units (this is a HUGE game management issue)
For version 0, I’m making cards that have attack, defense, experience and strength. The card will be held by the player, and kept near the unit on the table. Since strength decreases, or experience increases, the player will note the change on the card in writing. When that unit was done with its turn the player turned the card over (a little like mortgaging a property in Monopoly). When it’s your turn you turn the cards back over. It’s clunky and easily confused. But it’s a start.
Here is the doc that contains the rules for Version 1, including charts converted do d20, movement and terrain modifiers, and charts that can be cut out with scissors into unit cards.
Conclusion – What’s Next?
When we played, we noticed that the attack formulas were a little tricky at first but once we remembered how they worked there was a lot of repetition that got easier to manage. The cards were messy. We realized pretty quickly the units needed some type of numbers on them. When we 3D print units, rather than using coins, we’ll print little white numbers onto them. Version 1 will still have a paper board and paper cards. The cards will now crucially have numbers that correlate with the numbers on the units. Then the card doesn’t need to sit near to the unit, it just needs to have the same number on it. There is still a lot more prototyping to do, but this felt like a good start.
Original Positions 