FeysStudio Steam Group

The place to interact with the GameDev and discuss the games and your opinions, give feedback and share what you think!

ПОПУЛЯРНЫЕ ОБСУЖДЕНИЯ

ПОКАЗАТЬ ЕЩЁ (11)

НЕДАВНИЕ ОБЪЯВЛЕНИЯ

Update #22: Depot Worker Task Logic finished

10 июня 2025 г. - FeysStudio | Комментариев: 0

https://youtu.be/pnQ4MeqTblw

Today was a big milestone in the development of Quartermaster! I finally implemented the entire task management logic for our hardworking depot workers.

Now, the game can assign and unassign tasks dynamically or through hand by the player across different areas - whether it’s barracks, the deployment zone, the hospital, the mechanics bay, or beyond. Each worker now has proper stats: you can check exactly which worker is assigned to which task, at which place, and adjust it on the fly.
While the basis is rather simple, making sure no task could be assigned twice, no worker on two assignments and to make sure the code would always know and be able to adapt where exactly which worker exactly is, took a bit of fiddling.

I even got tasks like repairing telegraph lines, upgrading shelters, barracks cleaning, and sleeping already included.

Of course, there’s more to come: I still need to add a few additional tasks for other zones, but the foundational logic is solid. Assigning workers will actually affect game values - things like unloading speed, how fast or slow buildings degrade, how secure the depot is from sabotage, and so on. It’s all dynamic, and it’s going to add a whole new layer of depth to the gameplay.

This was a huge chunk of the logic, and I’m honestly proud to have it finished. It took a lot of careful checking.

Next up: I’ll be expanding the task list for all the different zones. Once that’s in place, the Depot Worker Tasks will be fully fleshed out! After that, I will not immediately implement the modifiers that make their work actually impact the game world (e.g., boosting efficiency, handling maintenance, etc.) and instead think I will first implement the upgrade system for units and modules/zones.

Thanks for following along - and stay tuned for more updates!

Update #21 - Major MIlestone Achieved

9 июня 2025 г. - FeysStudio | Комментариев: 0

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)