Today’s guest article is by Dustin DePenning and is part of our Design Diary series. It covers the use of grids in games and talks about how they make interesting combat options. Check it out, and check out his beautiful and intriguing game Synthicide! – Not a Cylon John

Synthicide is set in a violent, post-war galaxy where life has no value. As the tagline goes, “When robots are gods, killing humans is fair game.” Players take on the role of sharpers: human drifters fighting for their next meal. They get by doing dirty work for gangs and corporations, even taking illegal contracts to kill robots. All this conflict made a Battle system central to Synthicide’s design.

The Decision to Use Grids

As I began developing the battle system, I took stock of what I liked playing other games. My favorite battle experiences involved tactical decisions: finding superior ground, taking cover, knowing how to rush the enemy, and so on. Grids make these sorts of decisions concrete. I can visually compare my position to the enemy’s. I can see where good cover is. I can map a path from point to point to advance on my target. I wanted this for my game, so grid combat was locked in early for the design.

The Flaw of Grids

Grids have design downsides. Commoditizing spatial relationships raises questions. How does having higher-ground work? Does moving next to an enemy endanger them or me? Does the side of an enemy I stand on matter? Can I force an enemy to move?

It is tempting to answer these questions with individual rules and special maneuvers, growing game complexity. Perhaps you design a Rule to push enemies with physical strength, but then think of pushing enemies with attacks or intimidating them to step aside. Suddenly you have three rules for the same effect: moving enemies. And the more complex the rules get, the harder the game is to play and adjudicate. Battles become a slow, mental chore. To keep play fluid, I needed something simpler.

Sidestepping Complexity

I tried to sidestep design complexity two different ways. First, I left out any rules covering most of the questions above. This made battles solely about finding cover. While simple, shootouts and scuffles were one-dimensional and predictable. Players needed more. At minimum, I knew players wanted to move enemies, get the upper hand, stop enemies from moving, and even make enemies lose turns.

So in the second design stage, I took a hint from modern RPGs employing “design for effect” methodology. Codifying mechanical effects was what mattered, rather than describing every method players used to create them. So I rolled everything up under one generic move called “Gain Advantage.” You imagined whatever maneuver you wanted, described it to the GM, and chose one of the four battle effects. If the GM approved and you rolled well, you succeeded!

Embracing (Good) Complexity

Believing I could address more battle situations without making the game too complicated, I looked at other questions. One that stuck out was moving next to enemies. I lifted the concept of opportunity attacks, calling my version “quick attacks.” The rule granted combatants with fast weapons a free attack if an enemy entered or left adjacent squares.

It seemed good at first. Quick attacks gave grid movement meaning and danger. But this created a second clunky problem: melee lock. High-defense enemies could barge in on you, shrug off your retaliation, and then brutally punish you for fleeing. Rifle-carriers would stand still while a knife-fighter wailed on them, just to avoid the extra attack.

A Solution and Another Question

There was an easy solution though. I made free attacks defensive instead of aggressive. Quick attacks became guard attacks, where weapons like pistols and swords got attacks when an enemy walked up to you, not when they left. A melee fighter could no longer trap a gunman just by standing next to them.

This solution raised one more question. The defensive paradigm didn’t make sense if a knife fighter could get the first strike against combatants charging with swords or pistols. So what could reactive, knife-like weapons do to make them useful? I invented one more attack called counter. It made sense that if an adjacent enemy successfully attacked you, you could leverage the opening and retaliate. This made knife vs. sword fights interesting. The sword fighter would hang back in a defensive stance, striking the knife fighter advancing, and the knife fighter would retaliate with a quick stab whenever they were struck.

The Unanswered Question

The final battle rules, while more complex than I initially planned, successfully prevented rules bloat and melee lock. However, one aspect of the system was never quite cracked. One decision I had made was to give weapons range limitations. This put even more emphasis on grid positioning, resulting in one thing I wanted and one thing I didn’t. The good part was the tactical significance; for example, pistol carriers needed to take careful aim to hit far away targets, or find a way to get closer. The bad part was the mental math of counting squares, comparing ranges, and calculating how much movement it would take to split the difference.

In the end, I decided the tactical richness outweighed the loss in fluidity. But I know there is a rule solution, some halfway between ranges having meaning and tic-tac square math. Any future expansions to Synthicide’s rules will address this. In the meantime, what do you guys think? Are there games that have a good solution to weapon ranges?