Godot Brainstorming

Godot Brainstorming

A structured design process for Godot 4.3+ features and systems — from blank slate to a clear scene tree, signal map, and data flow before you write a single line of implementation code.

Related skills: godot-grill for settling open design decisions first, scene-organization for scene tree composition patterns, component-system for component-based architecture, event-bus for signal-based communication design.

Process: How to Brainstorm

Do NOT jump straight to designing. Follow these steps:

Step 1: Settle the decisions

If the request has open design decisions (scope, dimension, authority, data home, …), invoke godot-prompter:godot-grill and let it run to its end. Skip it when a record in the project's decisions or ADR directory already covers this feature, or the user has stated the decisions. Either way, check what already exists (code, scenes, assets). Carry the record into Step 2 — approaches must respect its settled rows.

Step 2: Propose 2-3 approaches

With the decisions settled, propose architectural options with trade-offs. For example:

• "Enum FSM vs Node FSM for your state machine — here's when each fits"
• "EventBus vs direct signals for your systems — here's the trade-off" Lead with your recommendation and explain why.

Step 3: Design with approval

Present the design section by section (scene tree, signal map, data flow). Ask "does this look right?" after each section before continuing.

Step 4: Prepare for implementation

After the design is approved:

1. Offer the agent instructions section — Ask whether to add the GodotPrompter integration section to the file this project already uses for agent instructions (see Agent Instructions Injection below). It is what tells subagents and future sessions to use GodotPrompter skills. Skip silently if a ## GodotPrompter section already exists in any of them, or if the user has declined before. Never add it without agreement.

2. Create implementation plan — If a planning skill is available (e.g., superpowers:writing-plans), use it; if not, break the design into ordered tasks yourself. Either way the project decides where the plan is saved: the user's instructions or the project's agent instructions file; then the planning skill's convention; then an existing plans directory. If none applies, ask the user, suggesting docs/plans/, or use docs/plans/ when you cannot ask.

3. Annotate each task with skills — Every task in the plan that involves a Godot system MUST list which godot-prompter:* skill(s) to invoke during implementation. Example:

   • Task 3: Player movement — Create CharacterBody3D with walk, sprint, jump. Skills: godot-prompter:player-controller, godot-prompter:input-handling

   This ensures that even when another plugin executes the plan, the implementing agent knows which GodotPrompter skills to load.

1. When to Use

Start here whenever you are:

• Adding a new feature — a chest, a dialogue system, a crafting bench, a skill tree
• Creating a new scene — you need to decide what nodes it contains and how they communicate
• Choosing between approaches — inheritance vs. composition, Autoload vs. Resource, 2D vs. 3D
• Feeling stuck on structure — the code works but the scene tree feels wrong
• Onboarding someone — you need to explain the design of an existing system

If you already know exactly what nodes you need and how they connect, skip this skill and build. Use it when uncertainty is slowing you down.

2. Scene Tree Planning

Sketch the scene tree on paper (or in a comment block) before opening the Godot editor. The goal is to answer three questions for every node:

1. What does this node own? (data, child nodes, visual representation)
2. What does this node do? (its single responsibility)
3. How does it talk to neighbors? (signals up, method calls down, EventBus sideways)

Planning Steps

1. Name the root node and its type — this defines the scene's contract with the world.
2. List immediate children by responsibility group, not by Godot node type.
3. Assign a Godot node type to each entry.
4. Identify every signal the scene emits and every signal it consumes.
5. Mark which nodes should be separate .tscn files (reuse candidates).

Example: Planning a "Chest" Interactable

Step 1 — Name and root type

A Chest is a world object the player walks up to and opens. It is not a physics body; it does not move. Root: StaticBody2D or Node2D.

Step 2 — Responsibility groups

• Visual representation (sprite, animation)
• Collision / interaction trigger (detect player proximity)
• Loot data (what items are inside)
• UI feedback (prompt label, open animation trigger)
• State (is it open or closed?)

Step 3 — Assign node types

Chest (StaticBody2D)
├── Sprite2D                  # closed/open frame, or swap texture on open
├── AnimationPlayer           # open animation
├── CollisionShape2D          # physical body shape (blocks player)
├── InteractionArea (Area2D)  # detect when player is close enough
│   └── CollisionShape2D      # slightly larger than body shape
├── PromptLabel (Label3D or Label) # "Press F to open"
└── LootTable (Node)          # holds @export var items: Array[ItemData]

Step 4 — Signal map

Step 5 — Reuse candidates

LootTable is likely reused by barrels, enemies, and shop crates — extract it as a separate .tscn component.

For the resulting GDScript and C# Chest sketches, plus the four-part design entry (Scene Tree, Node Responsibilities, Signal Map, Data Flow) used to document this design, see references/example-chest.md.

3. Picking Node Types and Dimension

Two lookups belong here but are pure recall — load them only when the answer is not already obvious:

• Which node for which need? CharacterBody vs RigidBody vs StaticBody vs Area, UI vs world-space labels, particles, cameras, spawn markers.
• 2D, 3D, or 2.5D? Selection criteria for each, hybrid techniques (billboarded sprites, orthographic 3D, SubViewport UI), and the performance consequences.

Two Godot 4.3+ specifics are easy to get wrong and worth stating up front: tile-based levels use TileMapLayer (one layer per node — TileMap is deprecated), and blend-tree locomotion needs an AnimationTree paired with an AnimationPlayer, not an AnimationPlayer alone.

Full need-to-node table, the 2D/3D decision criteria, and 2.5D hybrid techniques: references/node-selection.md