When Math Meets the Void: Building a Foundation to your Game Engine

Colin Bevis

I set out to start making a competitive two person card game starting in 2019. 

I wanted a game focused on horizontal progression. A game that didn’t have constant power creep that devalues older cards. That kind of short-term gain undermines player trust, and I never want to do that to a community.

I wanted this philosophy to be a core pillar and a clear promise: I aim for horizontal progression so that if players return after years away, their cards are still playable, strong, and relevant.

I wanted a game that was dedicated to horizontal progression. It turns out that it’s an easy goal to have, but it’s very hard to achieve. Go figure.

For years, I worked on a system that could use infinite horizontal progression. I developed many different systems, got close, but ultimately realized that reality means there are no perfect, mathematical equations to achieve that goal.

Here’s how Luminous got where it is after thousands of hours of conversations and testing.

Establishing a baseline

I wanted to develop a system of plus and minus modifiers you could ascribe cards that helped with balance, but before something can have a plus or minus you have to define what the baseline is. 

To do this, I started with units that had no abilities (affectionately called vanilla units in most card games). Each Vanilla Unit costs a certain amount of resources (Orbs in our game), and has an attack and health value. The baseline revolved around these vanilla units.

I thought this would be a simple equation, but it was far from it. What I thought would take no more than a month to work out ended up taking years. I rebuilt the model, studying other games, talking to mathematicians and pro-level players from other competitive games, and then tested these models.  

Free cards have a cost

The first thing that stood out right away is that “free cards” (any card that does not take expending a full resource) are not able to be balanced. 0 isn’t a number and the percentage difference between 0 and 1 can’t be quantified. Free cards are often far more powerful than they first appear and open the door for crazy combos that can break a game. If you want to put any free cards into your game, just know this is a whole other can of worms. Currently printed and in design we have no free cards in Luminous. 

Percentage differences

In Luminous you can have 6 total basic orbs in play. You are guaranteed to get one each turn from a resource pile outside your main deck. 

I have stared at the above graph for more hours than I care to admit. These numbers at first glance look like they tell the story, but it is only the first chapter. 

I then had to pick what the starting attack and health would be for a 1 resource cost vanilla unit. If you start at 1 attack and 1 health, the unit has 2 total “points.” If you extrapolate that to each cost, the vanilla unit graph for point allocation looks like this: 

How we got to those point allocations looks like:

  • Cost 1: choose 2 total
  • Cost 2: 2 × (1 + 1.00) = 4
  • Cost 3: 4 × (1 + 0.50) = 6
  • Cost 4: 6 × (1 + 0.3333) ≈ 8
  • Cost 5: 8 × (1 + 0.25) = 10
  • Cost 6: 10 × (1 + 0.20) = 12

So a 2 resource vanilla unit has 4 total points to allocate and could be a 3/1, 2/2, 1/3 or 0/4.  Units cannot have zero health in our game so that is all four variations of how you could allocate points on a two resource vanilla unit. 

This seems easy to balance and makes some amount of intuitive sense. It’s the easy part of the equation though. 

Leaving the vanilla world

If I wanted to add abilities to units, I needed to start with higher baseline point totals, so we could use a +/- modifier system. I wanted to develop a system that let me remove base attack and health points from a vanilla unit in order to give it an ability. The better, or more powerful, an ability was, the more points they subtracted. In the future, I plan to write a whole design discussion about +/- modifiers. 

So I doubled the starting total of points to the model:

For a while, this felt right. 

We were building out units with modifiers and testing simple first versions of units that were more than vanilla. 

The boar broke the math

Enter the boar. We were in early internal playtesting with a 5 resource Unit that we gave a -2 modifier so that it gained a positive modifier, Overwhelm, a way to deal excess damage over the unit that blocked it. Instead of being a 10/10 Vanilla Unit (using all 20 allocation points from the graph above), it became a 9/9 with Overwhelm because of the modifier. A giant boar that was a simple design to test big units barreling over smaller ones. 

This is when the cracks in the math started to appear. 

Not so spoiler alert to any competitive player or game designer: Boar is a really bad card. It is significantly underpowered compared to other cards we had been playing and designing. 

But why? It’s math is right. It has to work.

So if the math is right, it must be the modifier we added was too punishing. Except, no. We agreed that Overwhelm was actually a really strong mechanic, so it had a -2 modifier, taking the unit from 10/10 to 9/9 didn’t seem to be the issue with the card. 

Just as a fun test I asked the team to make it a 4 resource instead of 5 resource card, but leave it a 9/9 with Overwhelm. It was still bad. 

Then we made it a 13/13 with Overwhelm for 4 resources. It became a polarizing card that was mostly just really bad. 

The boar broke the math. 

Bonus for risk

I weighted higher-cost units with extra allocation points to reflect real-game risks (like vulnerability to bounce or removal). 

Therefore, a 5 resource unit should, by default, have more allocation points via percentage than the two and three resource Units.

 

So instead of 4, 8, 12, 16, 20, and 24 it was 4, 9, 14, 19, 24, 29. Each additional resource gets a point +1 for each value above 1. 

Fun fact: we printed one vanilla unit in our first Wanderers set, a two resource Unit with exactly 9 resource points, a 5 attack 4 health Unit. 

This worked better, but did not solve everything. More and more cracks in the math formed as we added more complex cards. 

Horizontal progression 2.0

So where did that leave us? I learned that card game math works on paper but breaks in the game engine, where hundreds of cards interact in unseen combos. It is like the Three Body Problem. Newton’s gravity laws work perfectly for two bodies, but making a game of this scale is 100s of moving bodies. Balance becomes nearly impossible using the formula I had developed because of the constantly forming puzzles that make design frustrating yet rewarding.

Ultimately, we largely dropped the +/- modifier I spent years developing, but the idea for horizontal progression lives on in our game. 

Just not in the way we first thought it would. We are still dedicated to playtesting, to comparing new cards to previous cards of the same cost that have come out before them, and attempting to make a game that cards you buy now can be played years from now, with no intentional power creep. 

We’re still committed to the idea of horizontal progression, but in new ways that allow us to scale. If you’re curious about where our current design is, let me know, and I can write more about it in future blog posts.

Latest blog posts