#Godot and openclaw

1 messages · Page 1 of 1 (latest)

slim dove
#

I have little to no experience with game dev but I have a ton of great ideas I'd love to implement. I created an agent a few days ago to start creating a few basic scenes. Gave it instructions and some skills but it's still a noob but still better than what I could do. Any advice on some prompts or skills that can help? Or is this a slow crawl and it will get better as time goes on. I've only been playing around with OC for about 2 weeks with a gpt plus Oauth.

lavish stagBOT
vast geodeBOT
#

Totally normal. It’s a bit of a crawl at first, but not because OpenClaw “learns over time” by itself. It gets better mostly when you tighten the workflow.

For game dev agents, I’d recommend:

1. Keep tasks tiny
Don’t say “build my game”.
Say:

  • “Create a Godot scene with a Player node, Sprite2D, CollisionShape2D, and basic WASD movement”
  • “Add a main menu scene with Start and Quit buttons”
  • “Refactor this script without changing behavior”

2. Make it plan first
A good prompt pattern is:

First inspect the current project structure.
Then explain your plan in 3-5 bullets.
Then make the smallest safe change.
Then summarize what changed and what I should test in Godot.

#

3. Give it constraints
Agents do way better with:

  • Godot version
  • 2D or 3D
  • exact node names
  • exact behavior wanted
  • “do not rewrite working files”
  • “prefer small edits over big rewrites”

4. Build one vertical slice
Pick one tiny playable loop:

  • move
  • interact
  • score
  • restart

That’s way better than trying to scaffold a full dream game too early.

#

5. Make a custom Godot skill/instruction
Useful rules for that skill:

  • always inspect existing files before editing
  • preserve scene/node names unless asked
  • prefer GDScript simplicity over clever abstractions
  • explain exported vars and signals
  • keep one feature per change
  • if uncertain, ask instead of inventing APIs

A solid base prompt for your agent could be:

You are helping build a small Godot game.

Rules:
- Start by inspecting the existing project files before proposing changes.
# 
- Prefer small, incremental changes.
- Do not rewrite working systems unless asked.
- Use clear, beginner-friendly GDScript.
- Preserve existing node names and scene structure when possible.
- Before coding, give a short plan.
- After coding, summarize what changed, which files changed, and how to test it in Godot.
- If requirements are ambiguous, ask a clarifying question instead of guessing.

And for feature requests, use prompts like:

In this Godot project, add basic top-down player movement.
Requirements:
- WASD movement
# 
- normalized diagonal movement
- movement speed exposed as a variable
- no animation yet
First inspect the current files, then give a short plan, then implement the smallest safe change.

My honest take: don’t wait for it to “just get smarter.” You’ll get faster results by improving:

  • prompt structure
  • project context
  • smaller task size
  • tighter review loop

If you want, I can help you write a better Godot agent instruction file and a few reusable prompts for scenes, UI, movement, enemies, and save systems.

slim dove
#

Yes, I would like help writing a better godot agent instruction file and some good reusable prompts.

vast geodeBOT
#

Yep, here’s a solid starter you can paste into your agent instructions and build from.

1) Godot agent instruction file

You are a Godot game-dev assistant helping build a small game incrementally.

Project goals:
- Build features in small, testable steps
- Prefer clarity and stability over cleverness
- Assume the user is new to game development unless told otherwise

Behavior rules:
1. Inspect the current project structure before proposing changes.
2. Do not rewrite large working systems when a small edit will do.
3. Prefer beginner-friendly GDScript and simple scene structures.
# 
4. Preserve existing node names, signal connections, and scene structure unless there is a good reason to change them.
5. Before making changes, explain the plan in 3-5 short bullets.
6. After making changes, summarize:
   - what changed
   - which files changed
   - how to test it in Godot
   - any likely follow-up improvements
7. If something is ambiguous, ask a clarifying question instead of guessing.
8. If an error appears, diagnose from the actual error text and nearby code, not assumptions.
9. Prefer one feature per task.
10. When adding code, keep comments brief and useful.

Godot-specific rules:
- Use Godot APIs and node types that match the project’s existing version and style.
- Do not invent node names, signals, methods, or project settings.
# 
- Prefer exported variables for values the user may tweak in the editor.
- Prefer signals for clean communication between nodes when appropriate.
- Keep scripts focused. Avoid unnecessary abstraction early on.
- If changing scene trees, clearly describe the expected node hierarchy.

Working style:
- First inspect
- Then plan
- Then make the smallest safe change
- Then explain how to test it

When giving code:
- Show complete script replacements only when necessary
- Otherwise prefer targeted edits
- Keep code readable for a beginner
# 

When debugging:
- Explain the likely cause in plain English
- Point to the exact file/line or node involved if possible
- Suggest the smallest fix first

2) Reusable prompts

A. Build a new feature

Inspect the current Godot project first.
# 
Then add this feature: [FEATURE]

Requirements:
- [requirement 1]
- [requirement 2]
- [requirement 3]

Constraints:
- keep changes small
- do not rewrite unrelated systems
- preserve existing node names and scene structure if possible

First give a short plan, then implement it, then tell me exactly how to test it in Godot.

B. Create a new scene

# 
Inspect the project first, then create a new Godot scene for [SCENE PURPOSE].

Requirements:
- root node type: [Node2D / CharacterBody2D / Control / etc.]
- child nodes: [list]
- attach scripts only if needed
- keep it beginner-friendly

Before coding, show the proposed scene tree.
Afterward, explain how to open and test the scene.

C. Add player movement

Inspect the current player scene and scripts first.
# 

Add basic player movement with:
- WASD input
- normalized diagonal movement
- exported speed variable
- no animation yet

Keep the implementation simple and explain which node/script should own the movement logic.
Then tell me how to test it.

D. Debug an error

Help me debug this Godot issue.
# 
Context:
- what I was trying to do: [goal]
- what happened instead: [problem]
- error message: [paste error]
- relevant script/scene: [paste code or structure]

First explain the likely cause in plain English.
Then suggest the smallest fix.
Then show me what to test after the fix.

E. Refactor safely

Inspect this script and refactor it for readability without changing behavior.
# 
Goals:
- clearer variable names
- simpler flow
- beginner-friendly structure

Do not change functionality.
Explain what you changed and why.

F. Plan the next step

Based on the current Godot project, suggest the next 3 smallest useful improvements.

For each one, include:
- why it matters
# 
- difficulty
- what files/scenes it would touch

Then recommend the best next step for a beginner.

3) Best practice that helps a lot

Use this pattern almost every time:

“Inspect first, plan second, smallest safe change third.”

That alone usually makes agents way less chaotic.

#

Also, for game dev, I’d strongly avoid prompts like:

  • “make this more fun”
  • “build my combat system”
  • “finish the game”

Better:

  • “add a dash with cooldown”
  • “make enemy patrol between 2 points”
  • “create a pause menu with resume and quit”

If you want, I can also give you a more opinionated version tuned for 2D Godot beginners, plus a prompt pack for menus, enemies, pickups, save/load, and dialogue.

slim dove
#

Yes please

vast geodeBOT
#

Nice. Here’s the more opinionated 2D beginner-friendly version plus a prompt pack you can reuse.

2D Godot beginner agent instructions

You are a Godot 2D game assistant for a beginner.

Primary goal:
Help build a small, playable 2D game through tiny, safe, understandable steps.

Assumptions:
- The user is new to game dev
- Simplicity is better than cleverness
- A working small feature is better than an ambitious broken system

Default approach:
# 
1. Inspect the current project before suggesting changes.
2. Explain the plan in 3-5 short bullets.
3. Make the smallest safe change.
4. Summarize what changed and how to test it in Godot.

2D rules:
- Stay in 2D unless explicitly asked for 3D.
- Prefer simple Godot nodes: Node2D, CharacterBody2D, Area2D, Sprite2D, CollisionShape2D, Control, CanvasLayer, Timer.
- Use beginner-friendly GDScript.
- Prefer exported variables for tweakable values.
- Prefer clear scene composition over deep inheritance.
- Prefer one scene = one responsibility.
- Do not add advanced architecture unless clearly needed.
- Avoid shaders, complex state machines, or singletons unless asked.
- Do not invent Godot APIs, node names, or input actions.
# 

Structure preferences:
- Keep player, enemy, UI, pickups, and level logic separated when practical.
- Preserve existing scene structure unless there is a strong reason to change it.
- If changing node hierarchies, clearly show the new scene tree.

Coding preferences:
- Keep scripts short and readable.
- Use clear names.
- Add only brief comments when helpful.
- Do not rewrite unrelated files.
- Prefer targeted edits over full rewrites.

When debugging:
- Use the exact error text.
# 
- Explain the likely cause in plain English.
- Suggest the smallest fix first.
- Tell the user exactly what to test after the fix.

When uncertain:
- Ask a clarifying question instead of guessing.

Reusable prompt pack

1) Make a player controller

Inspect the project first.
# 

Then create or improve a 2D player controller.

Requirements:
- movement: WASD
- normalized diagonal movement
- exported speed variable
- simple, readable GDScript
- no animation yet

Show the expected scene tree first.
Then implement the smallest safe change.
Then explain how to test it in Godot.

2) Add enemy patrol

# 
Inspect the existing enemy scene and scripts first.

Add a simple 2D enemy patrol behavior.

Requirements:
- enemy moves between 2 points
- exported patrol speed
- easy to tweak in editor
- beginner-friendly code
- do not add unnecessary complexity

First explain the approach, then implement it, then tell me how to test it.

3) Add chase behavior

# 
Inspect the current enemy and player setup first.

Add simple chase behavior:
- enemy patrols by default
- if player enters detection range, enemy chases player
- if player leaves range, enemy returns to patrol

Keep it simple and beginner-friendly.
Show which nodes and scripts should handle each part.
Then explain how to test it.

4) Add collectibles and score

Inspect the project first.
# 

Add a collectible pickup and a simple score UI.

Requirements:
- collectible disappears when player touches it
- score increases by 1
- score is visible on screen
- keep scene setup and code easy to understand

First show the scene/node plan.
Then implement the smallest safe version.
Then explain how to test it.

5) Build a main menu

# 
Inspect the project first.

Create a simple main menu scene with:
- title text
- Start button
- Quit button

Constraints:
- use simple Control nodes
- keep layout clean
- beginner-friendly setup
- explain which signals are connected

Show the proposed node tree first.
Then implement it and explain how to connect it to the main game scene.
#

6) Add health system

Inspect the current player setup first.

Add a basic health system.

Requirements:
- player starts with [X] health
- taking damage reduces health
- health can be displayed in a simple UI label or hearts
- if health reaches 0, explain a simple death/restart flow

Keep the implementation small and easy to understand.
Then tell me how to test it.

7) Scene transition prompt

# 
Inspect the current scenes first.

Help me add a scene transition from [SCENE A] to [SCENE B].

Requirements:
- simple and reliable
- beginner-friendly
- explain which script should trigger the transition
- do not rewrite unrelated systems

First explain the approach, then implement it, then show how to test it.

8) Save/load prompt

# 
Inspect the project first.

Add a very simple save/load system for:
- player position
- score
- current level

Constraints:
- keep it minimal
- prefer the simplest Godot-friendly solution
- explain the file/data flow in plain English

Before coding, tell me whether this should be done now or later for a beginner project.
If now, implement the smallest safe version.
#

9) Bugfix prompt

Help me debug this Godot issue.

Context:
- what I expected: [expected behavior]
- what happened: [actual behavior]
- error text: [paste error]
- relevant script or scene: [paste here]

First explain the likely cause in plain English.
Then suggest the smallest fix.
Then show me exactly what to test afterward.

10) “What next?” prompt

# 
Inspect the current Godot project first.

Then suggest the next 5 smallest useful features for a beginner 2D game.

For each one, include:
- what it adds
- difficulty
- which scenes/scripts it likely touches
- why it is a good next step

Then recommend the best next one.

One extra tip that really matters

#

Have the agent target a tiny game loop, like:

  • move
  • collect item
  • avoid enemy
  • win/lose
  • restart

That’s the sweet spot. If you try to jump straight to “RPG systems / inventory / quests / AI companions / procedural world,” the agent usually gets sloppy fast.

If you want, next I can give you a starter roadmap for a first Godot 2D game the agent can build with you step by step.

If this helped, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed on Answer Overflow for future folks.

slim dove
#

Yes give me a starter roadmap

vast geodeBOT
#

Yep, I’d start with a tiny top-down 2D game. It’s way easier than jumping into a platformer or RPG.

Starter roadmap: first playable game

Game idea:
Move around, collect items, avoid enemies, reach the exit.

That gives you a full loop without too much complexity.

Phase 1: Project skeleton

Goal: get a clean base project.

Build:

  • input actions (move_up, move_down, move_left, move_right)
  • a Main scene
#
  • a Player scene
  • a simple test level

Prompt:

Inspect the current Godot project first.

Set up a simple 2D project foundation for a beginner:
- input actions for movement
- a Main scene
- a Player scene
- a simple test level

Keep everything beginner-friendly and explain the scene structure before making changes.
#

Phase 2: Player movement

Goal: make the game feel alive.

Build:

  • WASD movement
  • collision
  • camera follow
  • tweakable speed

Prompt:

Inspect the existing player scene first.

Add simple top-down player movement with:
- WASD input
- normalized diagonal movement
# 
- exported movement speed
- camera follow if appropriate

Keep it simple and explain how to test it.

Phase 3: Level basics

Goal: create one playable room.

Build:

  • walls/collisions
  • floor art or placeholder tiles
  • spawn point
  • exit door area
#

Prompt:

Inspect the current level scene first.

Create a simple first level with:
- boundaries/walls
- player spawn point
- an exit area
- placeholder visuals if needed

Show the proposed scene tree before changing anything.

Phase 4: Collectibles + score

Goal: first real objective.

#

Build:

  • collectible scene
  • score counter
  • UI label

Prompt:

Inspect the project first.

Add collectibles and a simple score system:
- player can collect pickups
- score increases by 1
- score is shown in the UI
- keep it easy to understand

Then explain how to place collectibles in the level and test them.
#

Phase 5: One enemy

Goal: add tension.

Build:

  • one patrol enemy
  • player loses on contact, or takes damage
  • simple detection/collision

Prompt:

Inspect the current player and level setup first.

Add one simple enemy with patrol behavior.
Requirements:
# 
- moves between 2 points
- hurts or defeats the player on contact
- beginner-friendly code
- easy to tweak in the editor

Explain what nodes/scripts handle patrol and collision.

Phase 6: Win / lose loop

Goal: make it an actual game.

Build:

  • win when all collectibles are gathered and exit is reached
  • lose when enemy hits player
#
  • restart button or restart key

Prompt:

Inspect the current project first.

Add a simple win/lose loop:
- player wins after collecting everything and reaching the exit
- player loses when hit by the enemy
- allow restart after win or loss

Keep the logic simple and clearly explain the flow.

Phase 7: Main menu + polish

#

Goal: make it feel complete.

Build:

  • main menu
  • restart flow
  • simple sound effects
  • basic juice like particles or tween on pickups

Prompt:

Inspect the project first.

Add a simple main menu and light polish:
- title screen
- Start button
- Quit button
# 
- optional pickup sound or small visual feedback

Keep it minimal and beginner-friendly.

Phase 8: Only then consider extras

Do later, not early:

  • health bars
  • multiple enemy types
  • dialogue
  • save/load
  • inventory
  • procedural levels
  • quest systems
#

Those are fun, but they explode complexity fast.

Recommended build order

  1. Project setup
  2. Player movement
  3. One level
  4. Collectibles
  5. Score UI
  6. One enemy
  7. Win/lose
  8. Menu
  9. Polish
  10. Expand
#

If step 6 is broken, do not move to step 9. That discipline helps a ton.

My honest advice

For your first game, I would aim for:

  • 1 level
  • 1 player ability
  • 1 enemy type
  • 1 objective
  • 1 win screen

That is enough to teach you a lot, and it’s small enough that the agent won’t go off the rails as easily.

If you want, I can next give you a super practical “milestone checklist” version you can paste directly into OpenClaw and have it work through one step at a time.

slim dove
#

Yes I would like a checklist

vast geodeBOT
#

Absolutely, here’s a copy-paste checklist prompt for your agent.

Work through this Godot 2D beginner checklist ONE milestone at a time.

Rules:
- Inspect the current project before changing anything
- Do not skip ahead
- Keep changes small and beginner-friendly
- After each milestone:
  1. summarize what changed
  2. list files changed
  3. tell me exactly how to test it in Godot
  4. STOP and wait for confirmation before continuing

Checklist:
# 

[ ] 1. Inspect the project structure and summarize the current scenes, scripts, and likely entry point.

[ ] 2. Verify or create input actions:
- move_up
- move_down
- move_left
- move_right

[ ] 3. Create or clean up a Player scene:
- CharacterBody2D
- Sprite2D
- CollisionShape2D

[ ] 4. Add simple top-down movement:
# 
- WASD
- normalized diagonal movement
- exported speed variable

[ ] 5. Create a simple test level:
- floor/background
- walls or boundaries
- player spawn point

[ ] 6. Add camera follow if needed.

[ ] 7. Create one collectible item:
- disappears on touch
- can be placed in the level
# 
[ ] 8. Add a score system:
- score increases when collecting item
- score shown in a simple UI label

[ ] 9. Add an exit area:
- player can reach it
- do not trigger win yet unless conditions are met

[ ] 10. Create one enemy:
- simple patrol between two points
- easy to tweak in editor

[ ] 11. Add lose condition:
- touching enemy causes lose state or restart
# 
[ ] 12. Add win condition:
- player must collect all items
- then reach exit to win

[ ] 13. Add simple restart flow:
- restart key or button after win/loss

[ ] 14. Add a main menu:
- title
- Start button
- Quit button

[ ] 15. Add light polish only after everything works:
- pickup sound
- simple particles or tween
# 
- basic UI cleanup

Important:
- Prefer targeted edits over rewrites
- Preserve existing node names and scene structure when possible
- If something is ambiguous, ask before changing it
- Explain scene trees clearly when creating new scenes

Tiny pro tip

At the very top of each session, add this line too:

Do not try to complete the whole checklist at once. Complete exactly one milestone, then stop.