Small Rule. Big Dance
I’ve been working on a new strategy game.
It’s very interesting; there are farms, cavalry, little men who attack stone walls with swords because orders are orders.
The game has groups of army, warbands. Each warband has one banner bearer. Banner makes nearby soldiers brave and without a banner, the soldiers run. Two banners in the same warband would stack bravery and turn the ordinary spearman into an unstoppable cloth-powered monster. Can’t have that.
So I added a simple rule:
Every warband must always have exactly one banner bearer. Clean, simple, sensible, and it even fits on one line.
Then the banner bearer takes an arrow in the knee, chest, and several other important locations. I want to give the banner to a healthy pikeman.
I click old bearer and choose “put down banner.” The game says no. Warband would have zero bearers.
I click healthy pikeman and choose “take banner.” The game says no. Warband would have two bearers.
I stare at the simple rule. The simple rule stares back.
No Legal First Action
Before transfer:
- wounded scout has banner
- healthy pikeman does not
- exactly one bearer
After transfer:
- wounded scout does not have banner
- healthy pikeman has banner
- exactly one bearer
The problem lives between two wonderful pictures. If the scout stops first, there are zero bearers. If the pikeman starts first, there are two bearers. Both little actions are forbidden, neither can go first. The rule does not say banner transfer is impossible, but it says transfer cannot be made from two separate commands.
This is a strange hidden cost from the word always.
“Exactly one at the beginning” is cheap, “exactly one at the end” is also cheap. “Exactly one at every point during the change” needs choreography.
I thought the rule described army, but the rule also described how army is allowed to change.
Make One Bigger Action
My excellent game implementation gives me a new command, pass_banner.
The player chooses the old bearer, the new bearer, clicks once.
The game checks the whole change:
- Old unit really has banner
- New unit belongs to same warband
- New unit able to carry banner
- Transfer leaves exactly one bearer
Then it changes both roles as one single, completed gameplay event.
Not remove, announce, add, announce, simply pass. This adds a bridge directly between the two legal states.
The program may still change several bits of memory. The computer is a tiny fast clerk, not a wizard, but the important part is that combat code, morale code, quest scripts, and other nosy systems do not inspect half-finished handoff and decide warband has no banner.
Otherwise the sequence becomes:
- Remove banner from the scout
- Morale system notices zero banners
- Entire army flees
- Give banner to the pikeman
- The pikeman is now very brave and very lonely
All final data is perhaps correct, but the battle is a small disaster.
If transfer is one game event, observers see old arrangement or new arrangement. Not the awkward moment between.
This isn’t needless complexity. The rules of the system demand it. As long as a game promises exactly one bearer, some part of the game must coordinate removal and addition.
Maybe A Handoff Should Be Dangerous
The game designer (me) gets excited.
What if the banner cannot teleport across the map? Old and new bearer must stand near each other for two seconds while passing it.
This simple rule creates drama on the battlefield.
Wounded scout running back. Pikeman pushing forward. Enemy cavalry approaching. Player needs to bring both together without losing either.
If successor dies before pass completes, old bearer keeps banner.
If old bearer dies first, banner falls and the warband panics.
If the pass completes, pikeman raise banner and the scout retires peacefully.
Fun maybe!
But the designer must keeps ideas separate.
Exactly-one rule requires coordinated transfer. Adjacency, delay, interruption and so on are design choices added around the transfer. The rule does not demand any of them.
Maybe The Rule Is Too Strong
As you build larger, more complex projects, you learn to manage your own expectations. You start asking “is this even worthwhile?” Building a game is a daunting task. As a solo developer, you have to become extremely pragmatic and simplify things as much as you can. Building an RTS game is complex as is.
Before building a fancy banner-passing system, we must ask why this rule even exists.
Maybe the actual goal is only:
A warband must never receive bonus from more than one banner
That is not the same rule. Now zero bearers can be allowed. Scout can put the banner down, warband loses courage bonus, pikeman picks banner up, bonus returns.
The middle state has a cost but it is legal, and two separate commands work again.
Or maybe, the banner is a real object on the ground. There is always exactly one banner for the warband, but sometimes no unit carries it. Now enemy can steal it, a missing bearer is not an error; a missing bearer is an emergency and possibly a good game story.
Or maybe every warband truly must have one active bearer because formation, control, and morale, all depend on one commander. Then we must keep the strong rule, and provide the pass operation.
None of these answers are automatically the best, but the important thing is to name the actual promise, make it obvious and consistent.
Many expensive systems begin with a rule stronger than the reason for the rule.
Same Bug, Different Masks (Or Helmets)
The banner is a game mechanic, but the same problem hides in the game code itself.
Unit has one owner, squad has one leader, target has one reservation, building upgrade has one active version. Match has one host. Old owner is acceptable, new owner is also acceptable. Old leader is acceptable, new leader is also acceptable. But if the system only exposes “remove old” and “add new”, exact-one promise creates the same trap every time.
The choices are small:
- Allow a temporary middle state
- Provide one coordinated operation
- Weaken rule to what design truly needs
- Declare destination unreachable on purpose
This also explains why good interfaces often contain verbs like transfer, replace, swap or promote.
The verb tells the truth: this is one meaningful change, not two unrelated edits that happen quickly and hope that nobody is looking while it happens.
Simple rules can introduce expensive coordination.