# How to Make an Elden Ring-Style Soulslike Game With AI — Free Combat Code & Assets

Build a small original dark-fantasy action RPG around readable attacks, stamina, dodge timing and a memorable boss. Reuse a controller before writing combat-specific rules.

Canonical: https://binxforge.com/guides/reimagine-elden-ring

Original game: Ashen Pilgrim
First milestone: One ruined courtyard, one weapon, one regular enemy, a three-pattern guardian, one checkpoint, equipment and saved progression.

## Build steps
1. Build the courtyard and target lock
Greybox a spawn, checkpoint, enemy lane and boss space. Reuse movement/camera code. Lock-on chooses visible nearby targets and clears invalid/dead targets; never rotate the player instantly through obstacles.
Expected: A safe, readable combat space and stable camera.
Check: Circle the target, pass a pillar and remove the target mid-lock.

2. Make stamina an explicit rule
Define maximum stamina, attack/dodge/block costs and a regen delay. Reject actions that cannot pay their cost; spend once when the action starts. Movement stays responsive while recovery limits attacks.
Expected: Actions have understandable limits without sluggish walking.
Check: Hold attack at zero stamina, interrupt an attack and pause during regeneration.

3. Separate attack phases from visuals
Author windup, active and recovery durations. Apply damage only during the active phase, once per target per attack ID. Animation events may help presentation but cannot be the sole owner of damage.
Expected: Sword hits follow visible commitment and recovery.
Check: Overlap the same target for several frames: only one hit occurs per swing.

4. Add dodge and blocking fairly
Give dodge a finite invulnerable interval, recovery and stamina cost. A block checks facing and guard strength, then spends stamina. Show both rules through animation/audio and clear HUD feedback.
Expected: Players can read, evade and punish attacks.
Check: Test damage immediately before, inside and after the dodge window.

5. Author a guardian, not inflated stats
Use three patterns: delayed overhead, sweeping arc and short charge. Telegraph each, commit to its target and allow recovery. Phase two changes one pattern rather than doubling all damage.
Expected: A learnable original boss with different safe responses.
Check: Run deliberate dodge/counter strategies and check a careless attack-spam strategy cannot trivialise the fight.

6. Add checkpoints, equipment and saves
Checkpoint restores the player and resets intended enemies. Save unlocked checkpoint IDs, gear IDs and earned progress; transient attack states stay out of the save. Equip stats consistently and validate older saves.
Expected: A complete courtyard run with return and progression.
Check: Die during an attack, reload after victory and swap equipment without refilling resources unexpectedly.

## 2D — complete AI prompt

BINX Forge — How to Make an Elden Ring-Style Soulslike Game With AI — Free Combat Code & Assets
Build Ashen Pilgrim, my ORIGINAL 2D soulslike game. This is general-mechanics inspiration, not an exact copy of Elden Ring.
Guide: https://binxforge.com/guides/reimagine-elden-ring
Open selected Forge build: https://binxforge.com/build?v=2&guide=reimagine-elden-ring&dimension=2D&camera=Side-view&genre=Soulslike&theme=Dark+fantasy&engine=Godot&platform=Browser&players=Solo&budget=Free+only&commercial=Yes&buildScope=full

FIRST RESPONSE: give an achievable first playable milestone and begin one reversible implementation step if you can edit my project. If you are chat-only, give exact files and steps without claiming edits. Inspect and preserve working systems first. Reuse before rebuilding; spend AI effort on my original gameplay and polish. Do not demand private uploads just to provide a plan.

PRESENTATION: 2D. Side-view sword combat, ledges and short dodge windows. Use 2D physics and sprite hitboxes; control complexity is lower than a third-person RPG.
Original world and art direction: Ashen Pilgrim; Build a small original dark-fantasy action RPG around readable attacks, stamina, dodge timing and a memorable boss. Reuse a controller before writing combat-specific rules. Use the guide’s illustrations as mood concepts, not finished assets or screenshots. Create my own characters, names, environments and UI.
RECOMMENDED ENGINE: Godot, a free MIT engine. Use an editor and demo branch that match, record the version, and test the export. For 2D target desktop and mobile browsers first; for 2.5D/3D start desktop, then profile and verify browser/mobile compatibility before promising it. Camera: Side-view. Do not combine engine-specific code unchanged.
FIRST PLAYABLE: One ruined courtyard, one weapon, one regular enemy, a three-pattern guardian, one checkpoint, equipment and saved progression.
CORE SYSTEMS:
- Third-person or adapted 2D movement and target lock
- Stamina costs, regeneration delay and exhaustion
- Dodge invulnerability window and blocking rules
- Attack windup, active hit window and recovery
- Telegraphed enemy/boss states
- Checkpoint reset, equipment and progression

SOURCE-REVIEWED FREE CODE AND REFERENCES (not a certified combined starter):
Godot 4 third-person controller by GDQuest
https://github.com/gdquest-demos/godot-4-3d-third-person-controller/tree/b3bd6e81084f568be8aa44a69a0c2b1e52e806b3
Licence: MIT scripts/scenes/shaders; art is CC BY-NC-SA 4.0
Official terms: https://github.com/gdquest-demos/godot-4-3d-third-person-controller/blob/b3bd6e81084f568be8aa44a69a0c2b1e52e806b3/LICENSE
Fit: Godot 4 controller code only for a commercial starter. Replace the non-commercial textures/models; test all scene references after removal.
Approach: A third-person movement and camera example. Adapt its controller without assuming it supplies stamina, lock-on, a Soulslike combat system or commercial art. No verified AI-authorship claim.

Godot demo projects by Godot contributors
https://github.com/godotengine/godot-demo-projects/tree/b761b4cd5718a7118f2c95eb55f181d0a5f004f1
Licence: MIT code; retain notices and inspect each demo’s asset credits
Official terms: https://github.com/godotengine/godot-demo-projects/blob/b761b4cd5718a7118f2c95eb55f181d0a5f004f1/LICENSE.md
Fit: Use a demo branch matching your Godot editor; individual examples supply systems, not a complete game.
Approach: Feature-sized editor projects for movement, physics, tilemaps and UI. No verified AI-authorship claim.

FREE ASSETS FROM THEIR CREATORS:
Kenney Tiny Dungeon — https://kenney.nl/assets/tiny-dungeon — CC0 · tiles for a 2D combat courtyard.
Kenney UI Pack — https://kenney.nl/assets/ui-pack — CC0 · health/stamina bars and equipment controls.
Existing Forge resources: https://binxforge.com/resources/godot, https://binxforge.com/resources/kaykit-dungeon-pack, https://binxforge.com/resources/quaternius-universal-animation-library, https://binxforge.com/resources/kenney-ui-pack. Check each is published and fits the selected dimension; a model pack supplies art, not gameplay code.

CONTROLS: remappable WASD/arrows, genre-specific actions and Escape pause. Add native touch joystick/buttons sized for phones, cancellation/blur cleanup and keyboard-accessible menus. Use running where exploration needs it. Preserve control while separating menus and gameplay.
UI: start, pause, settings/mute, readable objective/status, inventory/equipment/collection where needed, results, save status and manual recovery. No fake account/cloud saving.
ANIMATION/VFX/AUDIO: coherent scale and rig, idle/move/action/recovery states, readable anticipation and hits, restrained particles, original or cleared audio; match sounds to actual events and offer mute.
STATE/SAVING: one owner per gameplay transition; stable IDs, versioned schema, validation, clamped counts, one-time rewards, no transient attack/input state in saves, safe failed-storage handling and migration tests.

PHASED DEVELOPMENT AND EXPECTED CHECKS:
1. Build the courtyard and target lock: Greybox a spawn, checkpoint, enemy lane and boss space. Reuse movement/camera code. Lock-on chooses visible nearby targets and clears invalid/dead targets; never rotate the player instantly through obstacles.
Expected: A safe, readable combat space and stable camera.
Check: Circle the target, pass a pillar and remove the target mid-lock.

2. Make stamina an explicit rule: Define maximum stamina, attack/dodge/block costs and a regen delay. Reject actions that cannot pay their cost; spend once when the action starts. Movement stays responsive while recovery limits attacks.
Expected: Actions have understandable limits without sluggish walking.
Check: Hold attack at zero stamina, interrupt an attack and pause during regeneration.

3. Separate attack phases from visuals: Author windup, active and recovery durations. Apply damage only during the active phase, once per target per attack ID. Animation events may help presentation but cannot be the sole owner of damage.
Expected: Sword hits follow visible commitment and recovery.
Check: Overlap the same target for several frames: only one hit occurs per swing.

4. Add dodge and blocking fairly: Give dodge a finite invulnerable interval, recovery and stamina cost. A block checks facing and guard strength, then spends stamina. Show both rules through animation/audio and clear HUD feedback.
Expected: Players can read, evade and punish attacks.
Check: Test damage immediately before, inside and after the dodge window.

5. Author a guardian, not inflated stats: Use three patterns: delayed overhead, sweeping arc and short charge. Telegraph each, commit to its target and allow recovery. Phase two changes one pattern rather than doubling all damage.
Expected: A learnable original boss with different safe responses.
Check: Run deliberate dodge/counter strategies and check a careless attack-spam strategy cannot trivialise the fight.

6. Add checkpoints, equipment and saves: Checkpoint restores the player and resets intended enemies. Save unlocked checkpoint IDs, gear IDs and earned progress; transient attack states stay out of the save. Equip stats consistently and validate older saves.
Expected: A complete courtyard run with return and progression.
Check: Die during an attack, reload after victory and swap equipment without refilling resources unexpectedly.

OPTIMISATION: bound world size and agent/effect counts, profile frame time at busiest points, batch terrain work and cull visuals without deleting persistent state. Test desktop and phone layouts, actual keyboard/touch, pause/restart, denied storage, corrupt saves and repeatable progression. Report tests actually run and remaining limits; screenshots must come from the real project.
LICENSING: preserve exact source notices. MIT source does not clear bundled models, audio, logos or promotional screenshots. Check finished-game sale, raw-file redistribution and source/template inclusion separately. Keep uncertain rights unconfirmed and link exact official terms. No franchise files, private BINX Engine source, proprietary systems, purchased pack files, credentials or unpermitted AI uploads. GDQuest non-commercial art must be replaced for commercial use; Open Theft Auto is reference-only; GPL references are not silently copied into a proprietary starter.
FUTURE UPGRADES: Beginner: Clearer attack tells — Improve windup pose, ground warning and impact sound before adding weapons.; Intermediate: Equipment choices — Add one shield and one heavy weapon with distinct stamina/recovery tradeoffs.; Advanced: Boss adaptation — Add spacing-aware pattern selection and an earned second phase, profiling effects and animation transitions.. Add each only after its earlier loop passes. Provide a small milestone first, then a larger progression roadmap. Do not invent percentage savings or publish a broken build.

## 2.5D — complete AI prompt

BINX Forge — How to Make an Elden Ring-Style Soulslike Game With AI — Free Combat Code & Assets
Build Ashen Pilgrim, my ORIGINAL 2.5D soulslike game. This is general-mechanics inspiration, not an exact copy of Elden Ring.
Guide: https://binxforge.com/guides/reimagine-elden-ring
Open selected Forge build: https://binxforge.com/build?v=2&guide=reimagine-elden-ring&dimension=2.5D&camera=Isometric&genre=Soulslike&theme=Dark+fantasy&engine=Godot&platform=Desktop&players=Solo&budget=Free+only&commercial=Yes&buildScope=full

FIRST RESPONSE: give an achievable first playable milestone and begin one reversible implementation step if you can edit my project. If you are chat-only, give exact files and steps without claiming edits. Inspect and preserve working systems first. Reuse before rebuilding; spend AI effort on my original gameplay and polish. Do not demand private uploads just to provide a plan.

PRESENTATION: 2.5D. A fixed isometric camera with 3D or layered actors. Combat lives on a ground plane; account for depth, height and occlusion.
Original world and art direction: Ashen Pilgrim; Build a small original dark-fantasy action RPG around readable attacks, stamina, dodge timing and a memorable boss. Reuse a controller before writing combat-specific rules. Use the guide’s illustrations as mood concepts, not finished assets or screenshots. Create my own characters, names, environments and UI.
RECOMMENDED ENGINE: Godot, a free MIT engine. Use an editor and demo branch that match, record the version, and test the export. For 2D target desktop and mobile browsers first; for 2.5D/3D start desktop, then profile and verify browser/mobile compatibility before promising it. Camera: Isometric. Do not combine engine-specific code unchanged.
FIRST PLAYABLE: One ruined courtyard, one weapon, one regular enemy, a three-pattern guardian, one checkpoint, equipment and saved progression.
CORE SYSTEMS:
- Third-person or adapted 2D movement and target lock
- Stamina costs, regeneration delay and exhaustion
- Dodge invulnerability window and blocking rules
- Attack windup, active hit window and recovery
- Telegraphed enemy/boss states
- Checkpoint reset, equipment and progression

SOURCE-REVIEWED FREE CODE AND REFERENCES (not a certified combined starter):
Godot 4 third-person controller by GDQuest
https://github.com/gdquest-demos/godot-4-3d-third-person-controller/tree/b3bd6e81084f568be8aa44a69a0c2b1e52e806b3
Licence: MIT scripts/scenes/shaders; art is CC BY-NC-SA 4.0
Official terms: https://github.com/gdquest-demos/godot-4-3d-third-person-controller/blob/b3bd6e81084f568be8aa44a69a0c2b1e52e806b3/LICENSE
Fit: Godot 4 controller code only for a commercial starter. Replace the non-commercial textures/models; test all scene references after removal.
Approach: A third-person movement and camera example. Adapt its controller without assuming it supplies stamina, lock-on, a Soulslike combat system or commercial art. No verified AI-authorship claim.

Godot demo projects by Godot contributors
https://github.com/godotengine/godot-demo-projects/tree/b761b4cd5718a7118f2c95eb55f181d0a5f004f1
Licence: MIT code; retain notices and inspect each demo’s asset credits
Official terms: https://github.com/godotengine/godot-demo-projects/blob/b761b4cd5718a7118f2c95eb55f181d0a5f004f1/LICENSE.md
Fit: Use a demo branch matching your Godot editor; individual examples supply systems, not a complete game.
Approach: Feature-sized editor projects for movement, physics, tilemaps and UI. No verified AI-authorship claim.

FREE ASSETS FROM THEIR CREATORS:
Kenney Tiny Dungeon — https://kenney.nl/assets/tiny-dungeon — CC0 · tiles for a 2D combat courtyard.
Kenney UI Pack — https://kenney.nl/assets/ui-pack — CC0 · health/stamina bars and equipment controls.
Existing Forge resources: https://binxforge.com/resources/godot, https://binxforge.com/resources/kaykit-dungeon-pack, https://binxforge.com/resources/quaternius-universal-animation-library, https://binxforge.com/resources/kenney-ui-pack. Check each is published and fits the selected dimension; a model pack supplies art, not gameplay code.

CONTROLS: remappable WASD/arrows, genre-specific actions and Escape pause. Add native touch joystick/buttons sized for phones, cancellation/blur cleanup and keyboard-accessible menus. Use running where exploration needs it. Preserve control while separating menus and gameplay.
UI: start, pause, settings/mute, readable objective/status, inventory/equipment/collection where needed, results, save status and manual recovery. No fake account/cloud saving.
ANIMATION/VFX/AUDIO: coherent scale and rig, idle/move/action/recovery states, readable anticipation and hits, restrained particles, original or cleared audio; match sounds to actual events and offer mute.
STATE/SAVING: one owner per gameplay transition; stable IDs, versioned schema, validation, clamped counts, one-time rewards, no transient attack/input state in saves, safe failed-storage handling and migration tests.

PHASED DEVELOPMENT AND EXPECTED CHECKS:
1. Build the courtyard and target lock: Greybox a spawn, checkpoint, enemy lane and boss space. Reuse movement/camera code. Lock-on chooses visible nearby targets and clears invalid/dead targets; never rotate the player instantly through obstacles.
Expected: A safe, readable combat space and stable camera.
Check: Circle the target, pass a pillar and remove the target mid-lock.

2. Make stamina an explicit rule: Define maximum stamina, attack/dodge/block costs and a regen delay. Reject actions that cannot pay their cost; spend once when the action starts. Movement stays responsive while recovery limits attacks.
Expected: Actions have understandable limits without sluggish walking.
Check: Hold attack at zero stamina, interrupt an attack and pause during regeneration.

3. Separate attack phases from visuals: Author windup, active and recovery durations. Apply damage only during the active phase, once per target per attack ID. Animation events may help presentation but cannot be the sole owner of damage.
Expected: Sword hits follow visible commitment and recovery.
Check: Overlap the same target for several frames: only one hit occurs per swing.

4. Add dodge and blocking fairly: Give dodge a finite invulnerable interval, recovery and stamina cost. A block checks facing and guard strength, then spends stamina. Show both rules through animation/audio and clear HUD feedback.
Expected: Players can read, evade and punish attacks.
Check: Test damage immediately before, inside and after the dodge window.

5. Author a guardian, not inflated stats: Use three patterns: delayed overhead, sweeping arc and short charge. Telegraph each, commit to its target and allow recovery. Phase two changes one pattern rather than doubling all damage.
Expected: A learnable original boss with different safe responses.
Check: Run deliberate dodge/counter strategies and check a careless attack-spam strategy cannot trivialise the fight.

6. Add checkpoints, equipment and saves: Checkpoint restores the player and resets intended enemies. Save unlocked checkpoint IDs, gear IDs and earned progress; transient attack states stay out of the save. Equip stats consistently and validate older saves.
Expected: A complete courtyard run with return and progression.
Check: Die during an attack, reload after victory and swap equipment without refilling resources unexpectedly.

OPTIMISATION: bound world size and agent/effect counts, profile frame time at busiest points, batch terrain work and cull visuals without deleting persistent state. Test desktop and phone layouts, actual keyboard/touch, pause/restart, denied storage, corrupt saves and repeatable progression. Report tests actually run and remaining limits; screenshots must come from the real project.
LICENSING: preserve exact source notices. MIT source does not clear bundled models, audio, logos or promotional screenshots. Check finished-game sale, raw-file redistribution and source/template inclusion separately. Keep uncertain rights unconfirmed and link exact official terms. No franchise files, private BINX Engine source, proprietary systems, purchased pack files, credentials or unpermitted AI uploads. GDQuest non-commercial art must be replaced for commercial use; Open Theft Auto is reference-only; GPL references are not silently copied into a proprietary starter.
FUTURE UPGRADES: Beginner: Clearer attack tells — Improve windup pose, ground warning and impact sound before adding weapons.; Intermediate: Equipment choices — Add one shield and one heavy weapon with distinct stamina/recovery tradeoffs.; Advanced: Boss adaptation — Add spacing-aware pattern selection and an earned second phase, profiling effects and animation transitions.. Add each only after its earlier loop passes. Provide a small milestone first, then a larger progression roadmap. Do not invent percentage savings or publish a broken build.

## 3D — complete AI prompt

BINX Forge — How to Make an Elden Ring-Style Soulslike Game With AI — Free Combat Code & Assets
Build Ashen Pilgrim, my ORIGINAL 3D soulslike game. This is general-mechanics inspiration, not an exact copy of Elden Ring.
Guide: https://binxforge.com/guides/reimagine-elden-ring
Open selected Forge build: https://binxforge.com/build?v=2&guide=reimagine-elden-ring&dimension=3D&camera=Third-person&genre=Soulslike&theme=Dark+fantasy&engine=Godot&platform=Desktop&players=Solo&budget=Free+only&commercial=Yes&buildScope=full

FIRST RESPONSE: give an achievable first playable milestone and begin one reversible implementation step if you can edit my project. If you are chat-only, give exact files and steps without claiming edits. Inspect and preserve working systems first. Reuse before rebuilding; spend AI effort on my original gameplay and polish. Do not demand private uploads just to provide a plan.

PRESENTATION: 3D. Third-person character movement, lock-on, stamina and animation-driven melee. Reuse controller code but replace restricted art and author your own combat.
Original world and art direction: Ashen Pilgrim; Build a small original dark-fantasy action RPG around readable attacks, stamina, dodge timing and a memorable boss. Reuse a controller before writing combat-specific rules. Use the guide’s illustrations as mood concepts, not finished assets or screenshots. Create my own characters, names, environments and UI.
RECOMMENDED ENGINE: Godot, a free MIT engine. Use an editor and demo branch that match, record the version, and test the export. For 2D target desktop and mobile browsers first; for 2.5D/3D start desktop, then profile and verify browser/mobile compatibility before promising it. Camera: Third-person. Do not combine engine-specific code unchanged.
FIRST PLAYABLE: One ruined courtyard, one weapon, one regular enemy, a three-pattern guardian, one checkpoint, equipment and saved progression.
CORE SYSTEMS:
- Third-person or adapted 2D movement and target lock
- Stamina costs, regeneration delay and exhaustion
- Dodge invulnerability window and blocking rules
- Attack windup, active hit window and recovery
- Telegraphed enemy/boss states
- Checkpoint reset, equipment and progression

SOURCE-REVIEWED FREE CODE AND REFERENCES (not a certified combined starter):
Godot 4 third-person controller by GDQuest
https://github.com/gdquest-demos/godot-4-3d-third-person-controller/tree/b3bd6e81084f568be8aa44a69a0c2b1e52e806b3
Licence: MIT scripts/scenes/shaders; art is CC BY-NC-SA 4.0
Official terms: https://github.com/gdquest-demos/godot-4-3d-third-person-controller/blob/b3bd6e81084f568be8aa44a69a0c2b1e52e806b3/LICENSE
Fit: Godot 4 controller code only for a commercial starter. Replace the non-commercial textures/models; test all scene references after removal.
Approach: A third-person movement and camera example. Adapt its controller without assuming it supplies stamina, lock-on, a Soulslike combat system or commercial art. No verified AI-authorship claim.

Godot demo projects by Godot contributors
https://github.com/godotengine/godot-demo-projects/tree/b761b4cd5718a7118f2c95eb55f181d0a5f004f1
Licence: MIT code; retain notices and inspect each demo’s asset credits
Official terms: https://github.com/godotengine/godot-demo-projects/blob/b761b4cd5718a7118f2c95eb55f181d0a5f004f1/LICENSE.md
Fit: Use a demo branch matching your Godot editor; individual examples supply systems, not a complete game.
Approach: Feature-sized editor projects for movement, physics, tilemaps and UI. No verified AI-authorship claim.

FREE ASSETS FROM THEIR CREATORS:
Kenney Tiny Dungeon — https://kenney.nl/assets/tiny-dungeon — CC0 · tiles for a 2D combat courtyard.
Kenney UI Pack — https://kenney.nl/assets/ui-pack — CC0 · health/stamina bars and equipment controls.
Existing Forge resources: https://binxforge.com/resources/godot, https://binxforge.com/resources/kaykit-dungeon-pack, https://binxforge.com/resources/quaternius-universal-animation-library, https://binxforge.com/resources/kenney-ui-pack. Check each is published and fits the selected dimension; a model pack supplies art, not gameplay code.

CONTROLS: remappable WASD/arrows, genre-specific actions and Escape pause. Add native touch joystick/buttons sized for phones, cancellation/blur cleanup and keyboard-accessible menus. Use running where exploration needs it. Preserve control while separating menus and gameplay.
UI: start, pause, settings/mute, readable objective/status, inventory/equipment/collection where needed, results, save status and manual recovery. No fake account/cloud saving.
ANIMATION/VFX/AUDIO: coherent scale and rig, idle/move/action/recovery states, readable anticipation and hits, restrained particles, original or cleared audio; match sounds to actual events and offer mute.
STATE/SAVING: one owner per gameplay transition; stable IDs, versioned schema, validation, clamped counts, one-time rewards, no transient attack/input state in saves, safe failed-storage handling and migration tests.

PHASED DEVELOPMENT AND EXPECTED CHECKS:
1. Build the courtyard and target lock: Greybox a spawn, checkpoint, enemy lane and boss space. Reuse movement/camera code. Lock-on chooses visible nearby targets and clears invalid/dead targets; never rotate the player instantly through obstacles.
Expected: A safe, readable combat space and stable camera.
Check: Circle the target, pass a pillar and remove the target mid-lock.

2. Make stamina an explicit rule: Define maximum stamina, attack/dodge/block costs and a regen delay. Reject actions that cannot pay their cost; spend once when the action starts. Movement stays responsive while recovery limits attacks.
Expected: Actions have understandable limits without sluggish walking.
Check: Hold attack at zero stamina, interrupt an attack and pause during regeneration.

3. Separate attack phases from visuals: Author windup, active and recovery durations. Apply damage only during the active phase, once per target per attack ID. Animation events may help presentation but cannot be the sole owner of damage.
Expected: Sword hits follow visible commitment and recovery.
Check: Overlap the same target for several frames: only one hit occurs per swing.

4. Add dodge and blocking fairly: Give dodge a finite invulnerable interval, recovery and stamina cost. A block checks facing and guard strength, then spends stamina. Show both rules through animation/audio and clear HUD feedback.
Expected: Players can read, evade and punish attacks.
Check: Test damage immediately before, inside and after the dodge window.

5. Author a guardian, not inflated stats: Use three patterns: delayed overhead, sweeping arc and short charge. Telegraph each, commit to its target and allow recovery. Phase two changes one pattern rather than doubling all damage.
Expected: A learnable original boss with different safe responses.
Check: Run deliberate dodge/counter strategies and check a careless attack-spam strategy cannot trivialise the fight.

6. Add checkpoints, equipment and saves: Checkpoint restores the player and resets intended enemies. Save unlocked checkpoint IDs, gear IDs and earned progress; transient attack states stay out of the save. Equip stats consistently and validate older saves.
Expected: A complete courtyard run with return and progression.
Check: Die during an attack, reload after victory and swap equipment without refilling resources unexpectedly.

OPTIMISATION: bound world size and agent/effect counts, profile frame time at busiest points, batch terrain work and cull visuals without deleting persistent state. Test desktop and phone layouts, actual keyboard/touch, pause/restart, denied storage, corrupt saves and repeatable progression. Report tests actually run and remaining limits; screenshots must come from the real project.
LICENSING: preserve exact source notices. MIT source does not clear bundled models, audio, logos or promotional screenshots. Check finished-game sale, raw-file redistribution and source/template inclusion separately. Keep uncertain rights unconfirmed and link exact official terms. No franchise files, private BINX Engine source, proprietary systems, purchased pack files, credentials or unpermitted AI uploads. GDQuest non-commercial art must be replaced for commercial use; Open Theft Auto is reference-only; GPL references are not silently copied into a proprietary starter.
FUTURE UPGRADES: Beginner: Clearer attack tells — Improve windup pose, ground warning and impact sound before adding weapons.; Intermediate: Equipment choices — Add one shield and one heavy weapon with distinct stamina/recovery tradeoffs.; Advanced: Boss adaptation — Add spacing-aware pattern selection and an earned second phase, profiling effects and animation transitions.. Add each only after its earlier loop passes. Provide a small milestone first, then a larger progression roadmap. Do not invent percentage savings or publish a broken build.

Concept artwork is AI-generated, not gameplay. Creator repositories provide their own original media and scoped licences. Implementation plans are not whole-project runtime certification.