Embers of Olympus — The Full Development Plan

The step-by-step build plan, from an empty machine to a shipped Act 1. Written 2026-09-13 as the project's backbone. Read README.md (the design decisions) and act-1-story.md (the content) first; this document is how it gets built, in order.

How to read this. Phases are sequential and each ends in a gate — a yes/no question you must answer before spending a day on the next phase. The gates are the whole point. A solo ARPG dies from building content on top of a loop that was never fun, or systems that were never data-driven. The order below exists to make those failures impossible, or at least cheap.

0. The five principles this plan enforces

1. Prove the fun before you build content. The grey-box loop (Phase 0) is judged for fun before any Greek art, story, or class exists. If move → kill → loot → equip isn't satisfying with cubes, no amount of art will save it.
2. Data-driven from day one. Items, affixes, skills, enemies, and loot tables are data (ScriptableObjects), not code. This is the single most important engineering decision in an ARPG — it's how one person authors hundreds of items and a dozen enemies without writing hundreds of classes. Built wrong, it's a rewrite; built right, content becomes filling in spreadsheets.
3. Vertical before horizontal. Build one of everything end-to-end (one class, one zone, one boss, the full loot loop) and ship-polish it, then replicate. Never build all three class skeletons half-way.
4. Separate narrative strings from systems strings from the first line (README §4.2). Quest/dialogue/item-flavour in one table; menus/buttons/errors in another. Free now, a re-architecture later.
5. The project is not in OneDrive. OneDrive fights Unity's Library/. Decide the on-disk location once, correctly, before installing anything.

1. Phase P — Pre-production & setup (≈1–2 weeks)

Nothing here is game code. It's the foundation; skipping it costs weeks later.

Step 1 — Machine & tools

1. Install Unity Hub, then the current Unity 6 LTS editor (LTS, not the bleeding edge — stability matters more than features for a multi-year project).
2. Install Visual Studio (or Rider) with the Unity workload; confirm C# IntelliSense and debugger attach to Unity.
3. Install Blender (free) — you'll need it for asset cleanup even if you buy most art. Install Git and (optional but recommended) Git LFS for binary assets.
4. Skim ../plan-version-1/csharp-and-unity-for-a-php-developer.md — what transfers from PHP, what doesn't. Don't try to learn all of C# first; learn it against the tasks below.

Step 2 — Project creation (do this once, correctly)

1. Create a new Unity project with the Universal Render Pipeline (URP) — the right choice for a stylized-but-atmospheric 3D look on a solo budget (README §3.7). Not HDRP (too heavy solo), not Built-in (legacy).
2. Location: a local drive, outside OneDrive/Dropbox (e.g. Z:\dev\... or C:\Dev\...). Confirm the path has no cloud-sync icon.
3. Initialize git in the project root. Add Unity's standard .gitignore (ignore Library/, Temp/, Logs/, Build/, obj/). Enable Visible Meta Files and Force Text serialization (Project Settings → Editor) — required for git to diff Unity assets sanely.
4. First commit: the empty project. You now have a safety net.

Step 3 — Project skeleton (folders & conventions)

Create the folder structure now so nothing ever lands in the wrong place:

Assets/
  _Project/            (everything we author lives under here)
    Art/               (models, materials, textures, VFX)
    Audio/
    Code/
      Runtime/         (gameplay scripts)
      Editor/          (custom inspectors, tools)
    Data/              (ScriptableObjects: items, affixes, skills, enemies)
    Prefabs/
    Scenes/
    UI/
    Localization/
      narrative.csv    (quest, dialogue, item flavour, inscriptions)
      systems.csv      (menus, buttons, errors, tooltips)
  ThirdParty/          (asset-store packs, kept separate & untouched)

• Namespace all your code (e.g. EmbersOfOlympus.Combat).
• Adopt a naming convention doc (1 page) and never deviate: PascalCase types, _camelCase private fields, one MonoBehaviour per file.

Step 4 — Decide the asset shortlist (don't buy yet)

Survey the Unity Asset Store and shortlist (buy in Phase 1, when you know what you need):

• Characters + animations: a Greek/fantasy character pack or a modular humanoid set; Mixamo (free) for the animation library. This is the pipeline from README §4.1 — you are not modelling animated characters yourself.
• Environment: a modular ancient-Greek/Mediterranean environment kit.
• A behaviour/utility asset you may want later (e.g. a nav/AI helper) — note it, don't buy it.
• VFX: a stylized spell/hit-effect pack (for the Oracle and hit feedback).

Gate P → 0: Unity opens the project, a script compiles and runs, git commits work, and the folder skeleton exists. That's it. Move on.

2. Phase 0 — The grey-box loop (≈3–5 weeks) — THE most important phase

No Greek theme. No art. No story. Capsules and cubes. Build the ARPG core loop and answer one question: is it fun? (README's Phase 0.) Build in this exact order — each step is playable before the next.

Step 5 — Movement & camera

1. A capsule "player" on a flat plane. WoW-style third-person: WASD movement relative to camera, mouse-look, camera on a spring arm with zoom. Use Unity's input system.
2. Ground it with a CharacterController or Rigidbody; get the feel right (acceleration, turn speed) — this is worth days, it's felt every second.

Step 6 — Target & basic attack (tab-target core)

1. Tab-target: press Tab / click to select the nearest valid enemy; show a target ring. Face target; a basic attack on a global cooldown (GCD).
2. One cube "enemy" with a health value that dies when it hits zero. First dopamine: a thing you kill.

Step 7 — Health, damage & the stat spine

1. A shared Stats component: Health, Damage, Attack Speed, Armor, and a couple of resistances. Player and enemy both use it.
2. Damage pipeline: attacker's damage → defender's mitigation → health change → death event. Route ALL damage through one function — every future affix, crit, and skill hooks here. Get this architecture right; it's load-bearing.

Step 8 — The loot drop (data-driven itemization — the ARPG heart)

This is where the game becomes an ARPG. Build it as data, per Principle 2.

1. ItemDefinition (ScriptableObject): base type, slot, icon, base stats.
2. AffixDefinition (ScriptableObject): a stat, a value range (min–max), a tier, allowed slots, a weight.
3. ItemInstance (runtime): a rolled item = a base + N random affixes with values rolled from their ranges. This distinction (definition vs rolled instance) is the core of the genre.
4. Rarity tiers: Normal (0 affixes) / Magic (1–2) / Rare (3–4). Rarity sets how many affixes roll.
5. LootTable (ScriptableObject): an enemy drops from a weighted table; roll rarity, then roll the item, then roll its affixes.
6. Enemy dies → spawns a loot beam on the ground → item is a real rolled instance.

Step 9 — Pick up, inventory, equip (the payoff)

1. Walk over / click loot → into a grid inventory.
2. An equipment panel with slots. Equip an item → its stats apply to the player's Stats → a number visibly changes on screen.
3. This closes the loop: move → kill → loot → equip → stronger → kill faster.

Step 10 — One affix that matters + minimal HUD

1. Ensure at least one affix is felt (e.g. +Attack Speed or +% Damage) so an upgrade changes how the game plays, not just a number.
2. Bare HUD: health bar, target health, XP bar, a hotbar slot. Ugly is fine.

⛔ GATE 0 — the fun gate (do not skip, do not rationalize)

Play your own grey-box loop for real sessions. Ask honestly: Is move → kill → loot → equip satisfying with cubes?

• Yes → proceed to Phase 1. The hard creative risk is retired.
• No → stay here. Tune combat feel, hit feedback (screen shake, hit-stop, sound), loot pacing, and stat impact until it's fun — or conclude the design needs to change now, when changing it is free. Building Greek art on an unfun loop is the most expensive mistake available.

3. Phase 1 — The vertical slice: one class, one zone, one boss (≈6–10 weeks)

Now add theme and depth — but only one of everything, polished to shipping quality. Prove the game, not just the loop. Recommended class: Hoplite (simplest to feel good — melee, few projectiles).

Step 11 — Skill system architecture (data-driven)

1. SkillDefinition (ScriptableObject): cost, cooldown, cast time, damage coefficients (scaling off stats), effects, animation trigger, VFX ref.
2. A skill runtime that executes a definition: GCD, cooldowns, resource cost, applies effects through the same damage pipeline from Step 7.
3. Build 3–4 Hoplite skills as data (e.g. a strike, a shield-bash stun, a leap, a shout buff). Bind to the hotbar.

Step 12 — Skill tree (per-class progression)

1. SkillTreeNode / tree asset: nodes unlock/upgrade skills or grant passives; spend points earned on level-up; prerequisites define the branches.
2. Build the Hoplite tree as data (full design comes in the skill-trees doc, next task after this plan). A respec option (paid or free — decide) from the start; players experiment more when respec exists.

Step 13 — First real art pass (buy the packs now)

1. Buy the shortlisted character + environment packs (Step 4). Import into ThirdParty/.
2. Retarget Mixamo animations to your character rig. Wire attack/skill animations to the skill system's animation triggers.
3. Hit feedback: impact VFX, hit-stop, sound on hit and on kill. This is 50% of why combat feels good — do not defer it.

Step 14 — One zone, handcrafted (Zone A: the Rarian Plain)

1. Build Zone A from act-1-zones.md (layout & encounter flow): the failing fields. Handcrafted landmark + skeleton-plus-shuffle connective ground (v1 world model).
2. Populate with Skeletal Hoplites and Keres (data-driven enemies): an EnemyDefinition (SO) → stats, loot table, skills, model/anim set. A spawner that scales density (parameterize it now even for single-player). Full roster — behaviours, elites, minibosses — in act-1-enemies.md.
3. Apply the art law (README/act-1): unattended, swept, empty — never rubble.

Step 15 — The town hub (Eleusis, minimal)

1. A safe hub scene with the service NPCs you need for the slice: Keeper of the Hearth (stash), Forgemaster (later), Wayfinder (waypoint), Merchant, Oracle (quest board). Greek names per README §3.8.
2. Dialogue system (data-driven, narrative strings from narrative.csv). Myrra never speaks — NPC lines only.
3. Chiron present as the mentor (framing, not a quest dispenser).

Step 16 — Quest system + Chapters 1–2

1. A lightweight quest system (objectives, state, triggers) — data-driven.
2. Implement Ch. 1 "The Last Harvest" (tutorial) and Ch. 2 "Bread and Timber" (the grove, Dryad Blights) — objectives, triggers, and dialogue in act-1-quests.md.

Step 17 — The boss (Polydegmon) + save system

1. Build Polydegmon, the Intake (two-phase, tab-target-friendly — see story doc). A reusable boss framework (phases, telegraphed AoE, add spawns).
2. Save/Load system (JSON serialization of character, inventory, quest state, waypoints). Build it now — retrofitting saves is painful. Decide save model (single save slot per character; ARPG-standard).

⛔ GATE 1 — the "is this a game?" gate

A 15–30 minute slice: create a Hoplite, enter Eleusis, take the first quests, fight through the Rarian Plain and the grove with real art and hit feedback, kill Polydegmon, get loot, spend a skill point, and save/quit/resume. Does this feel like a real game you'd want to keep playing?

• Yes → the model is proven; replicate it into a full act.
• No → fix feel/pacing/clarity here, in one class and one zone, where fixes are cheap. Do not build the rest of Act 1 on a slice that isn't fun.

4. Phase 2 — The full Act 1, one class (≈8–12 weeks)

Replicate the proven slice across all of Act 1's content, still Hoplite-only.

Step 18 — Zone B complete + all Act 1 chapters

1. Finish Zone B (Sacred Grove & Ploutonion approach) to shipping quality — layout & encounter flow in act-1-zones.md.
2. Implement Chapters 3–5 + denouement (the failing rite, the blame, the boss, Theano's death, the Delphi hook).

Step 19 — Full itemization content pass

1. Author the Act 1 item bases, affix pool, and loot tables as data (bronze-age feel per story doc).
2. Build the signature relic, the Rarian Sickle (after its canon relic-story + dedupe check against 11-relic-entries.md).
3. Add the Forgemaster (sockets/salvage) and Occultist (reroll/transmog) if you want them in the first release — or defer to keep scope tight.

Step 20 — Shrine blessings + economy

1. Shrines (Demeter/Hestia/Hermes) granting temporary boons (light gods system).
2. Drachmae economy: vendor buy/sell, the Gambler (blind buys). Currency has no metaphysics (canon) — the clean transaction.

Step 21 — Difficulty tiers

1. Implement Mortal → Heroic → Divine (canon names): the same act, scaled enemy stats + better loot. This is your cheap replay multiplier — parameterize scaling as data.

⛔ GATE 2 — the "complete act" gate

Act 1 is playable start to finish in 1–2 hours as a Hoplite, with the full loot loop, story, boss, save system, and at least Heroic difficulty replay. Is it fun the whole way through, with no dead spots?

5. Phase 3 — The other two classes (≈8–12 weeks)

Now go horizontal — the architecture from Phases 0–2 makes this mostly content, not new systems.

Step 22 — Archer, then Oracle

1. Build the Archer (ranged): projectiles, kiting, marks. New animation set; reuse the skill/tree/loot systems.
2. Build the Oracle (caster): elemental/divine spells, resource management, bigger VFX lean.
3. Author each class's skill tree as data (full designs in the skill-trees doc).

Step 23 — Balance & distinctness pass

1. Tune all three classes to clear Act 1 on all difficulties, each feeling distinct (README's replay-via-class-variety depends on this).
2. Ensure affixes/items support all three (e.g. spell-damage affixes matter to the Oracle).

⛔ GATE 3 — the "three real classes" gate

All three classes are viable and feel different through Act 1 on every difficulty. Replay value is real.

6. Phase 4 — Polish, systems, and release (≈8–12 weeks)

Turn a complete game into a shippable one. Most of "finishing" lives here — budget for it honestly; polish is not a week.

Step 24 — Full UX & options

1. Main menu, character create/select, settings (graphics, audio, keybinds), pause. Controller support if feasible.
2. Accessibility basics (text size, colourblind-safe rarity colours, remappable keys) — cheap if done now, per v1's accessibility notes.

Step 25 — Audio & juice

1. Music (adapt v1's track list), ambient beds, full SFX pass, UI sounds.
2. A final game-feel pass: camera shake, hit-stop, death effects, loot sounds, level-up moment.

Step 26 — Content completeness

1. Uniques/sets sparse but memorable; a few side quests from the Oracle board ("work-order queue" — canon).
2. Codex/lore hooks (optional book tie-ins per README §4.4).

Step 27 — Stabilize & ship

1. Performance pass (profiler: draw calls, GC allocations, load times).
2. Bug bash: play every class, every difficulty, edge-case the save system.
3. Build pipeline: produce and test a standalone Windows build on a clean machine. Fix what only breaks outside the editor.
4. Store prep (Steam page, capsule art via AI, trailer). Finalize the hype book (README §4.4). Trademark clearance (Cl. 9 + 41) before branding spend.

⛔ GATE 4 — the ship gate

A stranger can install the build, play any class start-to-finish, replay at higher difficulty, save/resume reliably, and hit no blocking bugs. Ship it.

7. Cross-cutting systems (build once, used everywhere)

These are threaded through the phases above; collected here so none is forgotten:

8. Working cadence & discipline (solo survival)

• Commit daily; branch per feature. Tag a build at each gate.
• Keep a playable build at all times. If it doesn't run, that's the only bug that matters until it's fixed.
• Timebox art. Buy, don't build, animated assets (README §4.1). AI for 2D (concept, textures, UI, promo, book), asset store for 3D characters, Blender only for cleanup.
• One "vertical" rule: never start the next class/zone/system until the current one is genuinely done. Half-finished breadth is how solo projects die.
• Play your game weekly as a player, not a developer. The gates depend on honest play.

9. Working with Claude — who does what

You are building this solo + Claude. That's a viable team for this scope, but only if the split is clear. Claude is the engine-room programmer and design partner; you are the director, the hands in the Unity Editor, and the sole judge of whether it's fun. Claude cannot operate the Unity Editor, see the game run, judge game feel, or make 3D art — those are always yours.

The division, phase by phase

How to actually work with it (the loop that works)

1. Right here in Claude Code: point it at your Unity project folder and it writes .cs files straight into Assets/_Project/Code/, manages git, and generates data files. Ask for one system at a time, in the plan's order.
2. Editor wiring: after Claude writes a script, it tells you exactly what to do in Unity (which object to attach it to, what to set in the Inspector). You do that part.
3. Debugging: paste the full Unity console error (and the relevant script) back to Claude — it fixes it. This round-trip is most of your day in Phases 0–1.
4. Feel problems are yours to diagnose: Claude can't feel the game. Describe what's wrong ("attacks feel floaty, no impact") and it'll suggest concrete fixes (hit-stop, animation events, screen shake) — but you decide when it's right.
5. Keep Claude scoped: one system, one script, one bug at a time. "Build the whole game" is not a prompt; "write the ItemInstance + affix-rolling system as ScriptableObjects" is.

The honest limits (repeat, because they matter)

• Claude never judges fun. Every gate is yours.
• Claude never makes 3D models or animations. Asset store + Mixamo + Blender cleanup (README §4.1).
• You still must learn enough Unity to be the hands and eyes — a few weeks via the PHP→Unity primer, not years. This is unavoidable and it is the real prerequisite.

10. Realistic timeline

The phase estimates above assume steady, focused solo work. Total for a shipped Act 1: roughly 10–15 months full-time, or proportionally longer part-time — a serious multi-year project at hobby hours. This is with the scope discipline already baked in (short act, buy-don't-build art, one thing at a time).

This estimate depends entirely on your hours per week. Tell me your realistic weekly time and I'll turn these phase ranges into a dated schedule with monthly milestones.

The single most important number is Gate 0. Reaching a fun grey-box loop is achievable in ~1–2 focused months and de-risks the entire project. Everything after it is craft and endurance; that gate is the one real unknown.

11. Risk register (and the mitigation already in the plan)

12. What's next in the design docs

This plan is the how. The immediate design work that feeds Phase 1:

1. ~~The three skill trees~~ — done: skill-trees.md (Hoplite / Huntress / Oracle, node by node), which Phase 1 (Step 12) and Phase 3 (Step 22) build directly from.
2. ~~Polydegmon's full encounter design~~ — done: boss-polydegmon.md (Step 17).
3. ~~The Rarian Sickle relic — canon story + dedupe~~ — done: reworked into the Rarian Sheaf, act-1-items.md §9 (Step 19).
4. ~~Act 1 item/affix pool as a data spec~~ — done: act-1-items.md (Steps 8 & 19).

Status: Full development plan drafted 2026-09-13. Next: the three skill trees.