Show HN: Claude Code skills that build complete Godot games

Original Article ↗ Hacker News Discussion ↗

An open-source tool that uses Claude-based agents to generate complete Godot projects from a text prompt is drawing both admiration and skepticism. Supporters see it as a powerful way to automate boilerplate, asset pipelines, and early prototyping—especially for non-programmers or designers who struggle with GDScript and engine setup—while critics argue that one-shot generations produce lifeless “AI slop” rather than shippable games and could flood marketplaces with low-effort titles. Much of the debate centers on how LLMs should be used in gamedev (as assistants vs. autonomous builders), the tradeoffs between GDScript and C#, and whether such tools lower the barrier to creativity or erode the craft and passion of making games by hand.

Language choice: GDScript vs C#

  • Debate over using GDScript (default, strong docs, tight engine integration) vs C# (better LLM familiarity, static typing, interfaces, possibly lower token cost).
  • Some report excellent results using C# + Godot + Claude for serious projects; others say recent Claude versions handle GDScript well if given version info and docs.
  • Noted C# limitations: missing web export and some bindings, though support has improved over time.

Quality of generated games & intended use

  • Many find the one-shot demo games technically impressive but “lifeless,” lacking good physics, mechanics, and polish.
  • Several argue that fully automatic “prompt in, game out” is not yet useful for shipping games; better to treat this as a prototyping or boilerplate generator.
  • Others see value as a jumping-off point to explore ideas, reduce setup friction, and let humans focus on design and “fun.”

Agent workflow & technical approach

  • Core problem identified: agents can’t “see” what they build, leading to broken layouts and unusable scenes.
  • The project’s loop runs Godot headlessly, captures screenshots, and uses a vision model for visual QA (e.g., z-fighting, floating objects, bad paths).
  • Godot API and engine quirks are exposed via lazily loaded “skills” to keep context small; a common-class subset is always in view.
  • Some question the need to re-document GDScript/Godot vs relying on official docs.

Assets and animation pipeline

  • Assets are a major focus: 2D art from image models, 3D from Tripo3D, sprite sheets with background removal; 3D models are static, 2D animation via sprite sheets.
  • Future plans mentioned for video models to generate smoother animated sprites.

Cost, performance, and scale

  • Estimated LLM cost per generated game: roughly $1–3 in tokens.
  • Asset generation (images + 3D) adds a few dollars; full simple game around $5–8 total.
  • Note that large text-based scenes in Godot can become slow; binary formats (.scn/.res) are faster but less agent-friendly.

Broader impact, slop, and craftsmanship

  • Strong split between enthusiasm (“great for non-coders,” “unlocks prototypes”) and concern (“AI slop,” flooded stores, loss of craft).
  • Some predict programming becoming more of a hobby; others find that AI frees them from “tech churn” to focus on fundamentals.
  • Many emphasize that human taste, iteration, and curation will remain critical; tools won’t replace good design, but may amplify both good and bad output.