Combat System Design Overview

Second Life, multiplayer, targeted auto-combat. Character sheets built and stored behind the rookeryisles.com login. The combat engine is the existing Rookery d20 system, taken from the Mage System reference. All 10 classes run on that one engine; they differ only in their ability lists and the name of their resource pool.

---

1. The core engine (d20, from the Mage System)

LOCKED (this session): the engine is the Mage System homebrew d20. Custom saves (Fortitude, Reflex, Will, Arcane), per-class resource pools (the spell-point mechanic, renamed), a cast roll vs Cast DC then a resist roll vs Resist DC, level mods +1 to +6. The ten Houses get translated into this language, not the reverse. The finished engine, including the HP, stats, skills, conditions, and rest the Mage doc left open, lives in the Core Rules. The Mage resolution as written:

Resolution: 1. Cast / action roll. Roll 1d20 + level mod (+ the class's key stat). Meet or beat the ability's Cast DC. On failure the ability fizzles and the resource cost is still spent. 2. Resist roll. If the action lands, the target rolls 1d20 + level resist mod (+ the matching save stat) vs the ability's Resist DC, using the ability's named save: Fortitude, Reflex, Will, or Arcane. 3. Outcome. Resist success negates (or, for attacks, takes the hit cleanly). Fail the resist by 3 or less is a partial: half effect. Otherwise full effect and full damage dice. 4. Crit cast (natural 20): damage dice doubled, target resists at disadvantage (roll twice, keep lower). 5. Crit fail (natural 1): misfire, resource lost, minor backlash. 6. Non-combat actions: Cast DC reduced by 3; player may describe their approach for a further bonus.

Level modifiers:

Situational modifiers (carried from the doc): near a leyline +2 cast; in Azura +3 cast and +1 damage die; at 10% resource -2 cast; overdraw at 0 resource -4 cast and +3 Cast DC; target is higher level +2 to their resist; target is non-magical -2 to their resist; target unaware -3 to their resist; caster injured or distracted -2 cast; same ability spammed 3+ times in a scene -1 cumulative.

---

2. The three gaps the Mage doc leaves (proposed, all tunable)

The Mage doc defines casting, resisting, the resource pool, and damage. It does not define HP, the stat block, or skills, because those are character-wide, not mage-specific. These have to be set once and shared by all 10 classes. Proposed starting values below. If you already have a core rules or character-creation doc that sets these, that wins and I will use it instead.

A. Health. Damage is in dice, so there is an HP pool. Three build tiers by role:

Light = Mage and the stealth class. Medium = Druid, Sea Shepherd, Steampunk, Bard, Archer. Heavy = Warrior/Barbarian, Paladin, Dragon Rider.

B. Stats and saves. Six stats, each feeding a save and the action roll:

Save bonus = stat modifier + level resist mod. The action roll uses the class's key stat (Mage = Wits, Warrior = Might, Archer = Finesse, Bard = Presence, and so on).

C. Skills. Non-combat checks: roll 1d20 + skill rank (0 to 5) + relevant stat vs a task DC (Easy 8, Moderate 12, Hard 16, Extreme 20). Starting skill list: Perception, Stealth, Athletics, Lore, Sailing, Craft, Persuasion, Survival, Medicine, Performance. Each class leans on a few.

---

3. Class framework (one engine, ten data packs)

The Mage doc is the template every class copies in structure:

Each ability is one data row: name, unlock level, cost, Cast DC, Resist DC, resist type, damage, description. The HUD reads rows; it has no per-class code. Add a class by adding rows, not by writing logic.

Resource model. Every class uses the same pool mechanic as the mage (scales by level, spent per ability, recovered by rest), just renamed for flavor. This keeps one engine. Names per class are in the roster below. (A few martials could later use a build-up resource instead of a spend-down pool; that is a v2 option, not v1, so the engine stays single.)

---

4. The classes (locked, from the live character creator)

Pulled from character-create.php (HOUSE_CLASSES and HOUSE_IDENTITY). Each House has one signature class, a fixed region, and a gated race. Sunflare is the merit house that takes any class up to level 7; Commoner (no specialty) is open to everyone. That gives ten combat classes. Resource and HP tier below are provisional; the real skills get written to Mage depth, and where a skills doc already exists it wins.

Locked from the source: - "No dragons" explained: a Dragonrider does NOT start with a dragon. The bond is earned through RP (see the Dragon Rules page). Dragons exist in three tiers up to mature; they are earned, not given. - The gryphon knight is the Cavalier/Knight of Emberwave, not a Paladin. There is no Paladin class. Gryphons belong to Thaloria. - Steampunk is the Artificer (Sunpeak). Mage is the Wizard (Sandstinger). Archer is the Ranger (Seaquill). - The tenth class is Fighter, the generic martial available through Sunflare (the merit house serving the Celestial Court, accepts all classes to level 7). Commoner is the no-specialty citizen, open to any house. - Arcane magic is bloodline-gated: only Sandstinger-blood Human Variants can be Wizards.

Race is set by House (Sunflare is the only any-race house; Dawnstar offers three). Race traits are more data rows on the engine, mostly advantage on certain checks, a class gate (Sandstinger blood for arcane), or a companion unlock.

Prestige classes

Some classes are not entered at level 1 but advanced into from a base class once requirements are met (level, House standing, a sworn deed). A prestige class grafts onto the base class's higher tiers rather than replacing it, and is just more data rows gated by a requirement.

• Paladin is a prestige class of the Cavalier. A Cavalier of Emberwave who swears a sacred oath to the Celestial Court ascends to Paladin, trading some tournament-and-cavalry breadth for radiant, oath-bound power. Proposed requirements: Cavalier level 6 or higher, an oath sworn, Celestial Court sanction. The Suncoast and Sunspear holy perks (radiant burst, reveal the hidden) live on the Paladin oath.

There is no Paladin base class; it sits above the Cavalier. Other base classes can grow their own prestige paths the same way later.

Power models

Not every class casts the same way. Two models are defined so far, both running on the one engine: - Arcane (Wizard): learned from a list, swappable on rest, leyline-fed, creates effects. Mage System doc. - Blooded Sorcery (Sea Shepherd): innate and fixed, manipulates forces that already exist, proximity-gated to the sea. See the Sea Shepherd page. The engine support this needs (environmental requirement, proximity modifier, loadout and magic-item flags) is written up in the core rules.

4.1 Houses / Nations (third axis)

A character is Class + House + Level. The House is where you are from, and it layers perks on your class at levels 1, 6, and 10. Ten houses:

Skjaldor picks one clan at level 1: Stormrider (cavalry, warhorse), Ironshield (smiths and defenders), Frostwolf (survivalists and hunters, frost wolf companion), Seastrider (sailors and raiders), Skybreaker (aerial riders, giant eagle companion).

House perks use the same data model as class abilities: each perk is a row keyed to house, clan, and unlock level. No new engine code, just more rows the brain reads.

Companions and mounts (sub-module). Class mounts: the Cavalier/Knight rides a gryphon (Thaloria's), the Dragonrider earns a dragon bond through RP rather than starting with one. House and clan companions: Drakoria (hippogriff), Skjaldor Skybreaker (giant eagle), Skjaldor Frostwolf (frost wolf), Thaloria (griffon), Azura (house-elf familiar), Valoria (mechanical horse, flying machine). Common rules: a ridable ground mount or companion that fights as a Beast Master companion, matures and gains flight at level 10 where flight applies, and can die permanently. That is its own HUD panel (companion HP, status, ride and dismiss, flight unlock) layered on the same engine.

---

5. HUD layout (your art, mapped)

Echo and the Chat Relay become buttons on this one HUD, so a player wears one attachment.

---

6. Targeted auto-combat protocol

1. Target. Attacker taps an ability, then picks a target from nearby Rookery HUD wearers (HUDs ping a region channel, same idea as your Chat Relay's HUD_ACTIVE broadcast).
2. Action roll. Attacker's HUD rolls 1d20 + level mod + key stat vs the ability's Cast DC, handles crit 20 and fail 1, and spends the resource. On a fizzle it announces and stops.
3. Send. On a successful cast it sends on the region channel: ATTACK | attacker | target | ability | resistType | resistDC | damageSpec | effects | crit.
4. Resist. The target's HUD rolls its save (1d20 + level resist mod + that save's stat) vs the Resist DC, applying partial within 3 and disadvantage on a crit cast.
5. Resolve. The target's HUD rolls the damage dice (halved on partial, doubled on crit), subtracts from its own HP, applies effects, announces the full result to local chat, and replies RESOLVED | ....
6. KO. HP at 0 announces incapacitation and locks the loser out until healed or reset.
7. Conditions and scene tracking (stagger, slow, prone, drain, burn over time, the repeat-spam penalty) tick on a per-round timer.

All combat is announced to local chat in formatted text so onlookers and staff can read it, and can mirror to Discord like your current relay if you want.

A note on trust: SL HUDs run client-side, so a determined cheater can edit their own copy. Normal for RP. If you ever want it locked, the website backend can referee rolls. Not needed for v1.

---

7. Character sheets on rookeryisles.com

• Build: a sheet page behind your existing login. Player picks class, allocates stats and skills, picks abilities, sees their level and title. Stored in a new table keyed to their web account.
• Link Second Life once: site shows a one-time code, player taps Link on the HUD and types it (same textbox flow as Ask Echo), the HUD POSTs code + avatar UUID, backend ties the UUID to the account.
• Load on attach: HUD calls a GET endpoint with the owner UUID (exactly how Ask Echo already sends user_uuid) and loads the sheet as JSON: HP, resource, level, stats, saves, skills, abilities.
• Persist: level, stats, abilities, max pools live on the site and survive relogs. In-combat current HP and conditions are ephemeral by default; can be POSTed back if you want wounds to persist on logout.

Reuses your existing pattern: same shared-secret header style, same UUID lookups, same MariaDB instance. New pieces: one table, a few endpoints (get sheet, link avatar, optional save state).

---

8. Architecture (one brain, the rest are pipes)

• HUD brain (one LSL script): owns all resolution, state (HP, resource, conditions), the level mod table, and the loaded class data. Every decision happens here.
• Button pipes (link messages): buttons and panels send raw inputs ("ability 3 fired", "target chosen") and render what the brain returns. No button decides anything.
• Comms pipe: one listener handles the region channel and hands raw strings to the brain.
• Web brain: owns the persistent sheet; the HUD trusts the answer.

No class checks or content-sniffing scattered across scripts. One resolver, fed by data.

---

9. Build phases

1. Engine core in one HUD script: d20 resolution, level mods, HP and resource, cast/resist/damage, crit and partial, local-chat output. Testable solo.
2. Class data format: the row schema and a loader (notecard or website JSON), with the full Mage list dropped in first as proof.
3. Targeted auto-combat: region-channel targeting and the cast/resist/resolve handshake between two HUDs, KO handling.
4. HUD frame and buttons: the panel from your art wired to the engine.
5. The other nine class systems: each written to full Mage depth.
6. Website sheets: build page, link flow, endpoints, table.
7. HUD pulls the sheet on attach.
8. Fold in Echo and Chat Relay as the Echo and CHAT ON buttons.

Each phase ships complete, nothing half done.

---

10. What I need from you

1. Any core / character-creation rules doc that already defines HP, stats, saves, or skills. If it exists, upload it so I match yours instead of my section 2 proposal.
2. The tenth class (Rogue/Assassin and Cleric/Priest are the cleanest fills).
3. Confirm the per-class resource names in the roster, or rename any you dislike.
4. Whether fights should mirror to Discord like your current relay, or stay in-world.
5. Whether wounds should persist on logout or reset each session.

Give me 1 and 2 and I can start building the engine and the first new class system immediately.

---

11. Ruleset reconciliation (RESOLVED)

Decision: keep the Mage homebrew as written. Four custom saves, per-class resource pools, two-roll casting, level mods +1 to +6. The ten Houses are translated into this language. The finished engine, with HP, stats, skills, conditions, rest, and the House-to-homebrew translation rules, is written up in the Core Rules.