REIMAGINE A GAME · SOULSLIKE

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.

Reimagine the mechanics in your own style: original characters, artwork and world. This independent guide builds Ashen Pilgrim, rather than recreating Elden Ring or its commercial assets.

Ashen Pilgrim original concept comparison: 2D left, 2.5D centre, 3D right — Original AI-generated concept art for Ashen Pilgrim · 2D / 2.5D / 3D · not playable screenshots

Don’t waste AI usage rebuilding what already exists. Find it. Reuse it. Make it yours.

You are creating your own original game inspired by general mechanics. Elden Ring is a reference, not an exact-copy brief or official project.

Choose the game you can finish

Your first milestone: One ruined courtyard, one weapon, one regular enemy, a three-pattern guardian, one checkpoint, equipment and saved progression. Finish this slice before multiplying maps, characters or mechanics.

Original 2D Ashen Pilgrim concept: 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. — 2D · Original AI-generated concept · not gameplay

2D soulslike

Side-view sword combat, ledges and short dodge windows. Use 2D physics and sprite hitboxes; control complexity is lower than a third-person RPG.

MAKE MY OWN 2D GAME

Original 2.5D Ashen Pilgrim concept: 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. — 2.5D · Original AI-generated concept · not gameplay

2.5D soulslike

A fixed isometric camera with 3D or layered actors. Combat lives on a ground plane; account for depth, height and occlusion.

MAKE MY OWN 2.5D GAME

Original 3D Ashen Pilgrim concept: 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. — 3D · Original AI-generated concept · not gameplay

3D soulslike

Third-person character movement, lock-on, stamina and animation-driven melee. Reuse controller code but replace restricted art and author your own combat.

MAKE MY OWN 3D GAME

See what original creators have built

GDQuest

Godot 4 third-person controller

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.

Code and asset rights: MIT scripts/scenes/shaders; art is CC BY-NC-SA 4.0

Compatibility: Godot 4 controller code only for a commercial starter. Replace the non-commercial textures/models; test all scene references after removal.

VIEW ORIGINAL GITHUB PROJECT ↗

Read the official licence & usage terms ↗

Source checked 11 October 2026 · pinned review; not whole-project runtime certification. Open the creator’s repository for genuine media; concept art here is separate.

Godot contributors

Godot demo projects

Feature-sized editor projects for movement, physics, tilemaps and UI. No verified AI-authorship claim.

Code and asset rights: MIT code; retain notices and inspect each demo’s asset credits

Compatibility: Use a demo branch matching your Godot editor; individual examples supply systems, not a complete game.

VIEW ORIGINAL GITHUB PROJECT ↗

Read the official licence & usage terms ↗

Source checked 11 October 2026 · pinned review; not whole-project runtime certification. Open the creator’s repository for genuine media; concept art here is separate.

Step by step: build Ashen Pilgrim

1Third-person or adapted 2D movement and target lock

2Stamina costs, regeneration delay and exhaustion

3Dodge invulnerability window and blocking rules

4Attack windup, active hit window and recovery

These are an original implementation plan with explicit checks, not claims that every proposed engine integration has already been executed.

STEP 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 result: A safe, readable combat space and stable camera.
Try this check: Circle the target, pass a pillar and remove the target mid-lock.
2D · Original AI-generated concept · not gameplay
STEP 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 result: Actions have understandable limits without sluggish walking.
Try this check: Hold attack at zero stamina, interrupt an attack and pause during regeneration.
Controls → state → feedback
Hold attack at zero stamina, interrupt an attack and pause during regeneration.
Acceptance check · run this in your own project
STEP 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 result: Sword hits follow visible commitment and recovery.
Try this check: Overlap the same target for several frames: only one hit occurs per swing.
2.5D · Original AI-generated concept · not gameplay
STEP 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 result: Players can read, evade and punish attacks.
Try this check: Test damage immediately before, inside and after the dodge window.
Validate → change once → show result
Test damage immediately before, inside and after the dodge window.
Acceptance check · run this in your own project
STEP 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 result: A learnable original boss with different safe responses.
Try this check: Run deliberate dodge/counter strategies and check a careless attack-spam strategy cannot trivialise the fight.
3D · Original AI-generated concept · not gameplay
STEP 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 result: A complete courtyard run with return and progression.
Try this check: Die during an attack, reload after victory and swap equipment without refilling resources unexpectedly.
Save → reload → compare
Die during an attack, reload after victory and swap equipment without refilling resources unexpectedly.
Acceptance check · run this in your own project

Start with a working reference

The related 2D workshop has a smaller runnable practice loop and public source. It is separate from this multi-dimension production roadmap.

Open the practical starter workshop →

Actual BINX Forge Build a Game genre selection — Actual BINX Forge builder capture · 10 October 2026. Select a genre, then dimensions, camera, engine and target; review the resulting plan.

Open Build a Game →

Free code, assets and systems you can reuse

Godot supplies physics, input mapping, UI controls, animation tools, navigation and file APIs. Its demos illustrate individual systems. Reuse those before asking ChatGPT, Claude Code or Codex to recreate them; AI still has to adapt your game-specific rules. Work avoided is not a measured credit-saving percentage.

Kenney Tiny Dungeon

Original creator: Kenney.

CC0 · tiles for a 2D combat courtyard.

View assets, real previews & licence ↗

Kenney UI Pack

Original creator: Kenney.

CC0 · health/stamina bars and equipment controls.

View assets, real previews & licence ↗

Animation, UI, audio, inventory and saving

Keep one art scale and test one imported model or sprite first. Reuse engine animation states and native UI focus. Use original sound synthesis or an exact cleared audio pack. Define inventory/collection IDs and transaction rules as game data; a visual pack cannot implement those rules. Godot’s saving tutorial supplies a file-workflow starting point; add schema validation, migrations and error handling.

Godot saving tutorial ↗ · Animation integration guide · Add one code or asset resource

Godot editor showing a 3D robot TPS demonstration scene and its editing panels.

ScreenshotFree

Godot Engine contributors · Original screenshot ↗ · CC BY 4.0 ↗. Resized and compressed.

Godot Engine contributors

Godot

Free, open-source game editor for 2D and 3D projects, with scene, animation and interface tools.

MITEngine

Official licence ↗Licensing summary, not legal advice. Check the exact edition and use.

See previews & details

Creator previewOpen the original page for real screenshots.

Free + paid editions

Kay Lousberg

KayKit Dungeon Pack

Modular dungeon architecture and props for fantasy room building.

CC0-1.0Asset pack

Official licence ↗Licensing summary, not legal advice. Check the exact edition and use.

See previews & details

Sprint_Loop pose on the actual free Universal Animation Library mannequin

Sample renderFree + paid editions

Quaternius

Universal Animation Library

Humanoid animation library with a free subset and expanded paid editions.

CC0-1.0Asset pack

Official licence ↗Licensing summary, not legal advice. Check the exact edition and use.

See previews & details

Creator previewFree

Kenney

UI Pack

Interface artwork for buttons, panels and sliders.

CC0-1.0Asset pack

Official licence ↗Licensing summary, not legal advice. Check the exact edition and use.

See previews & details

Optional paid assets are for an evidenced gap such as extra animation actions or a consistent environment set. Keep the free baseline beside the paid option. Browse free resources · Compare optional paid resources. Check current prices at the creator; no commission-based ranking or invented improvement percentage.

Licensing summary, not legal advice. Before selling or publishing, check exact official terms. Finished-game use, reselling raw files and including files in a source/template product are separate permissions; art, audio, trademarks and promotional media have separate rights.

COPY PROMPT TO YOUR AI

Copy to make your own game. Choose a dimension below; each complete prompt includes the original concept, source links, controls, systems, phased work, checks and upgrades. Nothing is sent to an AI automatically.

Review the prompt, then copy it or select its text manually.

Your 2D game-building prompt

Review or manually copy this 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.

Refine this 2D game in the Forge builder →

Your 2.5D game-building prompt

Review or manually copy this 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.

Refine this 2.5D game in the Forge builder →

Your 3D game-building prompt

Review or manually copy this 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.

Refine this 3D game in the Forge builder →

Read the complete guide and all three prompts as Markdown →

Make Your Game Even Better

Beginner

Clearer attack tells

Improve windup pose, ground warning and impact sound before adding weapons.

Inspect the free resource and optional paid editions →

Review or manually copy this prompt

Improve my existing ORIGINAL Ashen Pilgrim game: Clearer attack tells. Improve windup pose, ground warning and impact sound before adding weapons. Inspect the current implementation first, preserve controls and progress, and reuse its working systems. Free-first resource: https://binxforge.com/resources/quaternius-universal-animation-library; verify current licence, engine, dimension and target. Use a paid alternative only for a specific proven gap and keep the free option alongside it. Make one reversible change and test the same scene before and after, including keyboard/touch, pause and save/reload. Preserve source notices; no private engine or purchased-file uploads. Report actual evidence and unresolved checks; no invented percentage improvements.

Intermediate

Equipment choices

Add one shield and one heavy weapon with distinct stamina/recovery tradeoffs.

Inspect the free resource and optional paid editions →

Review or manually copy this prompt

Improve my existing ORIGINAL Ashen Pilgrim game: Equipment choices. Add one shield and one heavy weapon with distinct stamina/recovery tradeoffs. Inspect the current implementation first, preserve controls and progress, and reuse its working systems. Free-first resource: https://binxforge.com/resources/kenney-ui-pack; verify current licence, engine, dimension and target. Use a paid alternative only for a specific proven gap and keep the free option alongside it. Make one reversible change and test the same scene before and after, including keyboard/touch, pause and save/reload. Preserve source notices; no private engine or purchased-file uploads. Report actual evidence and unresolved checks; no invented percentage improvements.

Advanced

Boss adaptation

Add spacing-aware pattern selection and an earned second phase, profiling effects and animation transitions.

Inspect the free resource and optional paid editions →

Review or manually copy this prompt

Improve my existing ORIGINAL Ashen Pilgrim game: Boss adaptation. Add spacing-aware pattern selection and an earned second phase, profiling effects and animation transitions. Inspect the current implementation first, preserve controls and progress, and reuse its working systems. Free-first resource: https://binxforge.com/resources/godot; verify current licence, engine, dimension and target. Use a paid alternative only for a specific proven gap and keep the free option alongside it. Make one reversible change and test the same scene before and after, including keyboard/touch, pause and save/reload. Preserve source notices; no private engine or purchased-file uploads. Report actual evidence and unresolved checks; no invented percentage improvements.

Audit an existing game with Forge →

Questions before you build

Does a free third-person controller include Soulslike combat?

No. It can supply movement and camera scaffolding. Stamina, hit windows, target lock, bosses and checkpoint rules need focused integration and tests.

Can I make this without coding experience?

An AI can explain and draft code, but you still need to run the project, inspect errors and test controls and saves. Start with the runnable workshop, use a supported engine, and ask for one small milestone at a time.

Will this save AI credits?

Reusing a controller, tilemap, UI component or verified asset can reduce rebuilding work. Credit use depends on your AI, prompt and iterations; no fixed saving is promised.

Your next original game

GTA 6-style guide Minecraft-style guide Pokémon-style guide Terraria-style guide Mario Kart-style guide Fuse two game mechanics Search Reimagine a Game