Hey everyone!

Welcome back to another Quartermaster devlog. As usual, YoutTube video at the end.

Today, I want to talk about a pretty big conceptual error I ran into while coding the modifier system for my World War I logistics game. It’s one of those things that just happens I guess.

Issue 1: Missing Baseline Variables

First, I realized I completely forgot to implement baseline values for my variables. Right now, for example, I have a single variable for something like food consumption. If I change that value (say, apply a +100% modifier), that new value is now the “current” value — and any further modifiers stack on top of that. So instead of always recalculating from the original base (say, 1), the system is stacking on an already-inflated value.

Imagine:

Base value: 1

First modifier: +100% ➔ 2

Second modifier: +100% ➔ 4

Third modifier: +100% ➔ 8

That’s exponential growth — not additive growth — and it totally messes with balancing.

What I actually want is a clean separation between the base value (the “ground truth” stat) and the current value after applying modifiers. That way, every time I recalculate, I can start fresh from the base and apply the modifiers in a consistent way.

Issue 2: No Modifier Hierarchies

The second problem (which became way clearer once I realized I was missing baselines) is that I didn’t account for modifier hierarchies at all. Right now, all my modifiers are just stored in an array, treated equally, and applied in sequence — regardless of their type or logic.

In Quartermaster, I actually have different levels of modifiers:

- Map modifiers (like weather, terrain, frontlines)

- General modifiers (e.g. an artillery general that improves supply efficiency or movement speed)

- Unit modifiers (like fatigue, sickness)

- Mission modifiers (mission-specific effects)

- Upgrade modifiers (special bonuses from upgrades)

- others

But currently, everything is on the same level — and every modifier simply applies its change based on the last calculated value. That’s a huge problem for balancing. For example:

If an exhausted unit is supposed to lose half its movement speed, and then it starts raining (another -50% modifier), I don’t want the unit to have 0 movement (or close to it!). I’d rather have the rain affect the already exhausted movement speed, not multiply the penalties together in an out-of-control way.

What I really need is a hierarchy where I can define:

- Which modifiers should apply first,

- Whether they stack cumulatively or additively, and

- Whether they use the baseline value or the already-modified value as input.

The Good News

The good news? Most of the ideas I had actually work fine — the core code runs, the design is solid, and the system works. It’s just that I missed these two key things: saving a proper baseline to recalculate from, and structuring the modifiers logically so they interact properly.

It’s easy to fix, but will take a bit of time. I just wanted to share this with you so you see the real process of making a game — the mistakes, the learning, and the small steps that make the difference.

Thanks for sticking with me on this journey!

PS: If you want to playtest the game once it's in the prototype stage, leave a comment on my profile and I'll reach out to you once I'm there.