FeysStudio Steam Group

https://youtu.be/vjbwL49Pr4Q

My Modifier System Is Ready!

I’m excited to share that I’ve just finished the biggest chunk of the code for my WW1 logistics simulation game! The modifier system — which lets units, sectors, and even upgrades influence each other — is now fully functional.

Here’s what I’ve built:

Modifier System: Data-Driven and Flexible

I started by defining modifiers as data dictionaries, making it super easy to add new ones. Instead of hard-coding every single modifier effect, I can now drop in a dictionary that specifies:

- Which stat to affect

- The operation (like +5 or -10)

- Whether it recalculates every tick or only applies once

- Required states and forbidden states

- What the target entities can be (battle units, or transport units, or both, or depot workers, etc)

This means I can quickly expand the game with new events, unit upgrades, or commander effects — just by adding a new dictionary entry.

I built a ModifierFactory (a piece of code) that creates all modifier instances at the start of the game. This ensures everything is organized and easy to manage. Whether it’s a unit-level effect, a general bonus, a sector-wide debuff, or an upgrade, they can all be accessed, added or removed immediately because the are preloaded into memory and instantiated already at start.

The ModifierProcessor function is now complete. It applies all active modifiers, whether they come from unit states, sectors, upgrades, or commanders. This makes the system powerful yet simple — one function handles all cases.

Clean Separation of Modifiers

To keep things tidy, I separated modifiers into different arrays:

-modifier_unit_state for unit-specific effects

-modifier_sector_state for sector-wide impacts

-modifier_commander for commander bonuses

-modifier_upgrades for player upgrades

This lets me control when and how to implement different kinds of effects — perfect for balancing and expanding the game later.

I also took the time to refactor the unit stats into multiple layers:

-Baseline values — the original values, untouched by modifiers

-Modified values — what’s actually used in gameplay

-Delta values — how much should be changed per tick/hour

This way, I can always calculate from the original base value, avoiding rounding errors or compounding mistakes.

Plus, I added modifier snapshots — these store the values applied at the moment the modifier was added. It saves how much a modifier changed a value, so that it can be undone when the modifier is removed.

Last Time’s Blunder? Sorted Out!

Remember that head-scratcher from before — where I couldn’t figure out how to separate single-application effects from those recalculated each hour? That’s now fixed! The system properly applies single-application effects once, and repeated effects every tick. One step closer to a fully working game!

Conclusion

With this huge piece of functionality now complete, the game’s core logic is way more robust and flexible. Adding new mechanics is now a breeze, and the risk of bugs has dropped dramatically. Next up: Adding a few more modifiers for each instance to test it all out.

Then the next goal will be the upgrade system for the modules (stables, depot, hospital, etc)