In Dev Diary #1, I described how we built the Avalon engine's StateMachine and Renderer. Today I want to go deeper into the system that players interact with more than any other: combat. Turn-based browser RPG combat is not a solved problem. There are a thousand ways to design it, and most of them are either too flat (every fight plays the same) or too complex (no one reads the tooltips). Here is how we found our way to a system that we are actually happy with.
The Design Goal: Tension Without Tedium
The core design goal for Avalon's combat was simple to articulate and difficult to execute: every combat encounter should feel meaningful, but no encounter should feel like a chore. This rules out both the "one-button mash" approach (meaningless) and the "fifteen-ability management simulator" approach (exhausting). We wanted fights to reward attention and preparation without punishing experimentation.
The reference point we kept returning to was the early Final Fantasy games — specifically IV and VI. Those games had combat that felt weighty and strategic with a relatively small number of options per turn. The player had to think, but the thinking was satisfying rather than overwhelming. That was the register we were aiming for.
The Combat Loop
Avalon's combat is strict turn order: player acts, enemy acts, repeat. No simultaneous resolution, no speed-based initiative (in base combat — certain class abilities can alter turn order as a mechanic). On the player's turn, they choose from a context-sensitive action menu: Attack, Ability, Item, Defend, or Flee.
Attack is the baseline. Damage is calculated as baseDamage + (STR * strMultiplier) - (enemyDEF * defReduction), with a small randomisation band of ±15% to prevent combat from being purely deterministic. The randomisation is seeded per encounter so that reloading a save and retrying a fight produces different outcomes — this was essential for preventing the degenerate strategy of save-scumming to perfect outcomes.
Ability opens a secondary menu of class-specific skills. Each class has four base abilities available at the start of the game and can unlock four more through progression. Abilities cost MP (mana points) and range from straightforward damage multipliers to status effects, healing, and the class-unique mechanics described in the classes post.
Defend halves incoming damage for the enemy's next action and slightly regenerates MP. It is most useful in fights where the player knows a heavy hit is incoming — boss encounters telegraph certain attacks with a warning line of text, giving the player one turn to prepare a response.
Balancing the Numbers
Balancing is, in my honest opinion, the least glamorous and most important part of game design. You can have a beautiful system that is rendered meaningless by numbers that are off. We went through four complete rebalancing passes before the combat felt right.
The first version was too punishing. Players at level 1 were losing 30-40% of their HP in a single hit from common enemies, which made early exploration feel like a death march rather than an adventure. We dialled back enemy base damage by 25% and increased starting HP by a flat 20 points across all classes.
The second version was too forgiving. Players could walk through every early encounter by mashing Attack with no strategy at all. We introduced enemy variety — specifically, enemies with very high DEF values that required the player to use class abilities to deal meaningful damage, forcing engagement with the Ability system.
Passes three and four were fine-tuning: adjusting the HP scaling per level (we settled on a flat +12 HP per level plus a class-specific modifier), tuning the damage formula to keep fights feeling close without being unfair, and calibrating boss HP pools so that each boss fight lasts five to eight turns for an average player.
The balancing tool that helped most was a combat simulator we built internally: a script that ran ten thousand simulated combats between a given player build and a given enemy configuration and reported win rate, average turns to resolution, and average player HP remaining on victory. Anything outside a 55-80% win rate for a player at the encounter's intended level triggered a rebalance.
The Flee System
Flee mechanics in RPGs are usually either useless (50% chance to fail, and the enemy attacks you anyway) or trivially exploitable (flee always works, making all combat optional). We wanted fleeing to be a genuine strategic option — something you might actually choose, not because you had to but because it was the right call.
The Avalon flee system uses a weighted probability based on three factors: the player's Agility stat relative to the enemy's Speed stat, the player's current HP as a percentage of max HP (lower HP increases flee success chance — desperation lends wings), and whether the enemy is flagged as a pursuit-type.
Pursuit-type enemies — the more aggressive creatures in Shadows Hollow and the Minds' Eye — reduce flee success probability by 30% and, if the flee attempt fails, deal a pursuit strike before the player's next turn. This creates an asymmetry in fleeing behaviour across different Realms that feels thematically appropriate: the Mystical Sanctum's creatures are largely territorial and not inclined to chase, while Shadows Hollow's hunters are exactly that.
On a successful flee, the player exits combat and is returned to the exploration layer at the same position. The enemy is set to a temporary "roused" state, meaning re-entering its patrol zone within the next sixty seconds will trigger a second encounter. This prevents the exploit of fleeing and immediately re-engaging to farm a single enemy indefinitely.
Status Effects and the Condition Stack
Status effects — Poisoned, Burned, Stunned, Weakened, Empowered — are handled by a condition stack attached to each combat participant. At the start of each turn, the condition stack is evaluated: duration decrements, effects apply, expired conditions are removed.
The key design decision here was that negative status effects on the player are never permanently crippling. A player who is Stunned loses their action for one turn — not multiple turns, which in testing felt unfair and uncontrollable. Poisoned deals a percentage of max HP per turn, which scales correctly with level and means a two-minute fight with a poison spider is never an automatic death spiral.
We also added visual feedback for every status change — a small animated indicator in the combat UI and a line of descriptive text in the combat log. The combat log was one of the features we almost cut for scope and ended up being glad we kept. Players read it. They engage with the narrative texture of what is happening in the fight. Replacing "You dealt 14 damage" with "Your blade finds a gap in the Shade's armour — 14 damage" was a forty-minute writing task that meaningfully changed how the combat felt.
What Comes Next
Phase 2 will introduce multi-enemy encounters — up to three opponents simultaneously — and a revised targeting system to handle them. We are also planning a combo mechanic that rewards players who chain specific ability sequences across turns. The underlying combat system is built to accommodate both without major architectural changes.
The full combat guide, with all damage formulas and enemy stat sheets, is in the combat guide. The next Dev Diary covers the world-building behind Avalon's four Realms — how the lore influenced the design, and vice versa.