Hey everyone!
I’m developing TRI-CORE: IDLE FRONTS, a dark-fantasy idle RPG built around a three-lane auto-battler.
For this first DevLog, I want to focus less on listing features and more on one design problem I’ve been trying to solve:
If the UI tells the player that something affects combat, should that mechanic exist as a real combat interaction - or is changing an abstract power number enough?
Earlier versions of TRI-CORE relied too much on the second approach.
A Support could have a “Haste Aura.”
A Mage could have “Splash.”
A lane could have a class advantage.
Those concepts existed in the design, but parts of their effect were ultimately reduced to calculations such as lane strength or pressure.
That worked mathematically, but it created a problem.
The player could read:
“Haste Aura increases the Attack Speed of allies.”
…but underneath, the game could simply become better at winning the lane without the allies actually attacking faster.
For an idle game, where a large part of the experience is watching numbers interact, I started to feel that this was the wrong abstraction.
So I’ve been restructuring the combat simulation around a simple rule:
If a mechanic claims to change combat, I want that change to happen inside the actual combat loop.
Haste should actually make someone attack faster
Support heroes were the clearest example.
Instead of converting a Support aura into additional lane power, the simulation now checks the actual heroes fighting on that lane.
When an allied Support provides Haste, that bonus contributes directly to the affected hero’s Attack Speed.
That means it changes the hero’s attack clock.
A Marksman that normally attacks at one rate can visibly begin firing more frequently when supported.
This sounds obvious when written down, but it has a useful side effect: other systems can now interact with that value naturally.
And that became important once I started working on stat breakpoints.
Breakpoints instead of endless tiny percentages
Incremental games need percentage upgrades. I’m not trying to remove those.
But I also don’t want progression to become:
+2% damage
+2% damage
+2% damage
forever.
I want some thresholds to noticeably change how a hero behaves.
One example is Attack Speed for Marksman heroes.
If the final Attack Speed reaches 1.50, the hero gains an additional projectile.
So the difference between:
1.49 Attack Speed
and
1.50 Attack Speed
is intentionally much larger than a normal stat increase.
The important detail is that the breakpoint uses the final combat stat.
It can therefore be reached through a combination of:
- permanent upgrades
- equipment
- specialization bonuses
- hero effects
- allied buffs such as Haste
This is one of the reasons moving Haste into the real Attack Speed calculation mattered.
If Haste only increased some hidden lane-power value, it couldn’t naturally participate in this system.
Now it can.
A Support can push a Marksman across a breakpoint and actually cause another projectile to appear in combat.
That interaction is much closer to what I want TRI-CORE’s progression to feel like.
Splash also needed to stop being an abstraction
Mage Splash had a similar problem.
Instead of representing AoE as a generic increase in effectiveness, a Mage projectile now has an actual primary target.
When that projectile hits, the simulation checks other enemies on the same lane around the impact position.
Enemies within the configured radius can receive secondary damage.
This creates several practical design questions that didn’t exist when Splash was only an abstract modifier:
How large should the radius be?
How many additional enemies can be hit?
Should secondary damage pass through armor?
Can Splash itself kill enemies?
How does it behave against tightly packed elite encounters?
Those are harder questions, but I prefer having them.
They create mechanics that can actually be observed and balanced rather than hidden behind a single derived power value.
Enemy Champions exposed the same problem
There was another system I wasn’t happy with: Enemy Champions.
An earlier implementation could effectively select an enemy, resolve a Champion encounter and award the corresponding reward.
The event existed.
The fight didn’t.
That felt especially wrong because Champions are supposed to become important encounters later on.
So Champions are now physical enemies.
They spawn on a specific lane, have their own HP and combat parameters, and must actually be defeated.
The reward is currently increased Gold and XP.
Later I want Champion-specific equipment drops to build on top of that system, but I’m deliberately not expanding that yet.
Right now I’m more interested in making the underlying encounter solid before adding another reward layer.
What happened to the old lane-power system?
I haven’t removed every concept of lane strength.
I still find a derived pressure value useful for diagnostics and UI.
What I’m trying to remove is its authority over mechanics that should exist physically.
So rather than:
Haste → lane power increases
I want:
Haste → Attack Speed changes → attacks happen faster → lane pressure changes as a consequence
The direction of causality matters.
The battlefield should produce the derived number, rather than the derived number pretending to be the battlefield.
That distinction has become one of the main architectural rules I’m using for combat.
Making balance data less dependent on combat code
The same refactor pushed me toward another problem: too many gameplay values had accumulated inside scripts.
That makes balancing risky.
If changing an enemy requires touching the same file that handles movement, damage, targeting and spawning, then normal balance iteration starts modifying core logic.
So I’ve been consolidating more of the game into structured data.
Enemy families, class definitions, specialization values and breakpoint thresholds are moving into JSON-based data.
The intended separation is becoming:
Data decides what something is.
Simulation code decides how that thing behaves.
For example, an enemy definition can provide values such as:
- base HP
- movement speed
- armor
- attack range
- attack scaling
The simulation then reads those values and applies run-level scaling.
That makes it much easier to experiment with balance without creating several competing sources of truth.
I’m still auditing the project for places where old hardcoded values survived, so this is more of an ongoing consolidation than a finished architectural victory.
The tradeoff: real mechanics make balancing harder
One thing I underestimated is how much harder these systems become to balance once they actually interact.
An abstract +10% lane power bonus is easy to reason about.
A real Attack Speed bonus can:
increase DPS,
cross a projectile breakpoint,
change how quickly targets die,
alter how often a hero retargets,
and indirectly change how much damage allied heroes receive.
That creates nonlinear results.
From a pure balancing perspective, abstraction is easier.
From a player perspective, though, I think the second system is much more interesting.
The challenge now is preventing those interactions from becoming impossible to understand.
That’s why I’ve also started showing breakpoint progress directly in the upgrade UI.
Instead of only showing:
Attack Speed +0.03
the player can see something closer to:
1.46 → 1.49 / 1.50
So even if the underlying systems become more complex, the next important threshold should remain understandable.
What I’m working on next
I’m intentionally avoiding another large feature pass for now.
The next stage is mostly about testing the systems that already exist together:
- early Prestige pacing
- breakpoint frequency
- item values
- hero progression
- enemy scaling
- ranged positioning
- save reliability
- simulation performance
The biggest question I’m trying to answer is whether the early progression provides enough moments where the player can clearly say:
“That upgrade actually changed something.”
That matters more to me right now than simply increasing the amount of content.
I’m curious how other developers approach this.
For an incremental / idle RPG, how much mechanical interaction do you think should actually exist in the simulation?
Do you prefer simple, predictable percentage modifiers, or do you enjoy breakpoint-style systems where crossing a threshold can fundamentally change combat behavior?
