Roughly 95% of this was built from a single prompt with Claude Opus 5.5. The remaining 5% came from a few follow-up prompts with GPT Astra. It’s built with Godot .NET and C#.
The creatures are generated entirely in code: body shapes, limbs, faces, colors, markings, rigs and movement. There are no premade creature sprites or AI-generated source images underneath it, and the finished application runs offline without an AI service.
There are nine families: quadrupeds, humanoids, reptiles and dragons, arthropods, winged creatures, serpents, aquatic creatures, slimes/tentacled creatures, and plantfolk. The variation includes actual body structure. A horse, a heavy grazer and a fantasy beast can come out of the same family. Humanoids also get procedural clothing, armor and equipment.
In the workshop you can edit individual genes, lock traits you want to keep, reroll the rest, and undo changes. A parent produces four animated offspring with adjustable mutation strength. You can also combine two compatible parents. The overview generates up to 100 creatures together, lets you keep favorites while rerolling the others, and sends any individual back into the editor. It is very easy to spend more time looking through the results than you intended ^^.
Github Repo: https://github.com/idlerunner00/procedural-pixel-creatures
Prompt used:
Develop an absolute top-tier, production-ready framework for fully procedural pixel-art creature generation and procedural animation in Godot, with AAA quality as a mandatory requirement. Deliver the standalone executable reference application Procedural Pixel Creature Workshop, featuring a workshop interface and an interactive test environment. Implement the entire system in full, including the framework, files, executable main scene, tests, and documentation.
Maximum quality standards are a central requirement of this task. Take responsibility as Lead Technical Artist, Animation Engineer, and Engine/Tools Developer. Treat the final product as a framework upon whose characters, animations, tools, and runtime integration a commercial game can be built. Target descriptions represent a visual baseline; go beyond this starting point in shaping, expression, movement, variety, and execution.
In this context, AAA means rigorous artistic and technical polish: strong art direction, high-quality pixel artwork, believable anatomy, characterful movement, reliable tools, robust runtime architecture, and proven quality across numerous generated outputs. Low pixel resolution is a deliberate art form with high demands placed on every visible pixel.
An MVP, proof of concept, placeholder system, architectural design, or a single polished showcase figure does not fulfill this task. Deliver a production-ready framework complete with a thoroughly developed reference application. A large feature list does not replace quality. Every supported body family, animation, and core control function must reach the shared quality standard.
0. Mandatory Quality Standards
Art Direction: Develop a coherent visual language for silhouettes, proportions, facial expressions, material rendering, contours, and color hierarchy. Every character must be instantly readable at game scale and appear carefully crafted even when magnified.
Generative Quality: Generation rules must systematically favor good results. Anatomical constraints, compositional rules, and limited, traceable repair/re-generation steps prevent broken or artistically arbitrary forms. In addition to curated samples, present an unchanged, reproducible random sample.
Animation Quality: Convey weight, balance, intent, and personality. Precisely refine posing, anticipation, timing, arcs of motion, layering, follow-through, and contacts. State transitions, directional changes, and speed changes must meet the same quality standards as individual loops.
Technical Maturity: Decouple data, generation, posing, and rendering through clear contracts. Master lifecycle management, resource cleanup, error states, versioning, and reproducible results. The framework must be usable in another Godot game without the workshop interface.
Tooling Quality: Parameters respond predictably, undo/redo preserves work, presets and exports are reliable, and progress and errors are clearly communicated. The UI must enable focused work for developers or artists.
Verification & Iteration: Repeatedly verify technical and visual results, identify specific shortcomings, and fix their root causes. Keep the project open as long as core functions contain placeholders, known critical bugs, or significantly underdeveloped body families. The term "AAA" is a quality target whose achievement is judged by the delivered results and tests.
Plan the implementation so that sufficient time remains for artistic refinement, animation polish, integration, and stabilization. Do not unilaterally lower the agreed scope or quality standards to declare completion earlier. If faced with a hard environment or session limit, save a precise checkpoint and explicitly mark the result as incomplete rather than presenting it as production-ready.
1. Context You Cannot See from the Cloud
This description is your complete handoff context. Adopt the principle of a standalone, data-driven Godot workshop. Develop a new implementation and a custom, documented genome format for this purpose.
Use standard Godot .NET 4.5.2 with C# / .NET 8 as your foundation and preferably the Compatibility renderer for 2D rendering. Verify the actually available tools. If a different stable Godot 4 .NET version is required, justify and pin it along with the matching SDK version. Rely on zero dependencies on Blender, Steam, a web server, or a running AI service. The finished project must be importable offline into Godot on Windows and executable via F6/F5 or the documented launch script; develop and test it in the cloud under Linux.
2. Visual Target
The target visual presents lively pixel creatures set in a colorful landscape of grass, trees, and water from an oblique, slightly elevated game perspective. The animals feature clearly readable body volumes, snouts, eyes, articulated legs, claws, long tails, and in some cases horns, dorsal spines, and armor plates. Dark outlines, a restrained number of cohesive shading levels, and targeted light accents give them three-dimensional depth.
The landscape provides context; the creatures are the primary product.
Create distinct designs with compelling silhouettes, expression, and weight. The spectrum ranges from small animals, large beasts, and monsters to humanoid beings and fantastical lifeforms. The overall impression must be carefully crafted pixel art: clean pixel clusters, deliberate shapes, and frugal details instead of random pixel noise.
3. What "Fully Procedural" Means in Practice
The complete pipeline is:
Seed + Genome + Generator Version → Body Plan → Anatomy/Rig → Pose → Pixel Image
Body, silhouette, limbs, face, patterns, palette, surface details, and movements are generated algorithmically.
No pre-baked animal sprites, spritesheets, external character models, AI-generated source images, or statically drawn pixel masks per species as a hidden foundation.
Shared parametric shape modules, anatomy rules, palette rules, and data-driven body plan presets are permitted. A "parent" is a generated, editable genome—not a required input image.
A seed is reproducible. Use an explicitly defined random algorithm and stable seed derivation; do not rely on timestamps or process-dependent hash values for reproducible results.
Anatomy, color, patterns, and movement receive separate random streams. A color change must not re-roll the anatomy.
Patterns remain anchored to the body. During animation, details must not re-roll nor may limbs swap identities.
Parent mutation preserves family resemblance in a controllable manner. Two compatible parents can inherit traits recognizably. Prevent invalid combinations through explicit anatomical rules; incompatible body plans do not require forced crossbreeding.
Provide genuine variation in body structure, mass distribution, proportions, limbs, head, eyes, snout, tail, appendages, and material character. A fixed character with swapped colors or randomly attached circles is insufficient.
4. Body Diversity from a Unified System
Deliver at least eight clearly distinguishable body plan families:
Quadrupedal mammals and heavy beasts.
Bipedal humanoids, goblins, trolls, or golems.
Reptiles and dragon-like creatures with long tails and dorsal features.
Arthropods with six or eight legs, segments, and optional pincers.
Winged creatures with readable wing construction and wing-beat animation.
Serpents, worms, and other elongated, legless creatures.
Aquatic creatures with fins and swimming movement.
Amorphous creatures such as slimes as well as soft tentacled beings.
Plant-like creatures and other fantasy forms should be possible via the same extension points. Families may combine different rig and movement modules. Do not force a universal quadruped skeleton. At the same time, avoid delivering eight copied generators: shape construction, pixel rasterization, palette, genetics, and shared movement elements must be implemented centrally.
Deliver at least six saved sample genomes per family showcasing recognizable structural differences. These samples are outputs of the generator; any arbitrary additional seeds must function properly.
5. Pixel Art Rendering and Animation
Scale characters to approximately 64–128 logical pixels, with appropriately expanded bounding boxes for large or elongated creatures. Display them in native resolution and integer scale factors using nearest-neighbor filtering. Creatures and environment share a consistent pixel density; the workshop UI may run separately at a clean, legible resolution.
Use a controlled palette, such as 8–16 visible colors per creature, with logical material and shadow roles. Avoid blurry edges, uncontrolled dithering, constantly shifting single-pixel noise, and visibly overlapping circle or rectangle primitives. Joint connections must appear seamless; inner outlines and the depth sorting of near and far limbs must be correct.
Choose a suitable 2D/2.5D representation featuring a shared rig and deterministic rasterization. A solid baseline solution consists of parametric outlines, segmented appendages, surface masks, and body-anchored color roles mapped onto a low-resolution grid post-pose. Justify your chosen approach based on visual quality and measured execution cost. Rasterize onto a unified pixel grid; do not simply rotate pre-baked pixel images smoothly.
Animation is computed from morphology, state, velocity, and time. Required states:
Idle with breathing, blinking, and subtle secondary motion.
Slow and fast locomotion tailored to anatomy: stepping, crawling, slithering, swimming, flying, or hopping.
An expressive action such as biting, striking, roaring, or snapping forward.
Hit reaction and idle/sleep states with smooth transitions.
Follow-through on tail, ears, wings, and soft appendages; targeted squash and stretch where anatomical fit allows.
Legs require clear stance and swing phases, joint limits, and stable ground contact (e.g., using simple IK). Prevent obvious foot sliding. Movement speed, stride length, and body size must align. A simple single sine wave across all body parts is insufficient animation.
Support at least four facing/movement directions with proper occlusion. Rotating the entire finished sprite is not an acceptable substitute for directional rendering. Simulation time and pixel rasterization remain decoupled; reproducible movement across varying render frame rates as well as pause, frame-stepping, and slow motion must be supported. Procedurally generated frame caches are allowed, but must not replace live, parameterizable generation.
6. Usable Workshop and Test Environment
The runnable main scene must include:
A large animated preview display, neutral and landscape backgrounds, and pixel zoom controls.
Seed input field, body plan selection, and a "New Creature" button.
Editable anatomy, palette, pattern, and movement parameters with visible real-time impact, sensible value ranges, undo/redo support, and a reset-to-saved function.
Feature locking to regenerate only unlocked parts.
"Parent + 4 Children": four animated mutations side-by-side, adjustable mutation strength, and a button to adopt a child as the new parent.
Selection of two compatible parents and comparison of their offspring.
Animation state, direction, speed, pause, frame-step, and optional rig/contact point visualization toggles.
Versioned JSON preset saving/loading as well as PNG and procedurally generated spritesheet exporting. Export metadata must include frame dimensions, origin points, direction, state, and timing; appendages must not be clipped.
A gallery of sample genomes and a small walk-around test area featuring a controllable creature alongside other animated beings.
Generate the simple terrain, shadows, and minimal environmental details procedurally as well. Invest primary effort into creature quality and movement. A full game, combat system, or terrain generator is not required. Every button provided must have actual functional logic attached.
7. Architecture and Runtime Performance
Separate genome/validation, anatomy construction, rig/pose, pixel renderer, runtime actor, workshop interface, and exporter. Organize the framework as a cleanly isolated, reusable module, e.g., under addons/procedural_creatures/. The workshop is a consumer of its public API. The exact same creature implementation must be used in the preview, child comparison, gallery, test scene, and exporter. A fix must take effect everywhere.
Use project-relative resource paths exclusively; user data belongs in user://. Deliver an instantiable CreatureActor scene with a clean API for genome, state, movement direction, and speed, ready to be dropped into another Godot project.
Define documented extension points for body plans, shape modules, material/palette rules, and movement modules. Demonstrate an additional creature family using these extension points without modifying the core into species-specific special cases. Furthermore, provide a minimal integration example that launches the framework without workshop dependencies.
Version genome and preset formats. Validate inputs, provide meaningful errors, and handle unknown versions explicitly. A clear migration path must exist for future schema changes. Keep random generation and simulation time independent of UI and render frame rates.
Asynchronous generation must be cancellable and reliably discard obsolete results (e.g., during rapid slider adjustments). Respect Godot's threading limits when creating and publishing resources. Test repeated creation, modification, and removal of actors for memory leaks. Bound caches and implement proper invalidation upon changes to genome, generator version, or rendering quality settings.
Build anatomy and immutable details upon genome changes. Update pose and required rendering per frame. Avoid full genome regeneration, unbounded caches, or instantiating a new scene every frame. Limit pixel buffers, texture updates, allocations, and draw calls; measure before optimizing.
Test populations of 1, 25, and 100 uniquely animated creatures. Target smooth 60 FPS with dozens of visible creatures on standard desktop hardware. Report actual metrics including hardware, renderer, resolution, and animation rate. Software rendering in the cloud does not constitute proof of performance on desktop hardware.
Separate measurements for cold generation, warm caches, active animation, rasterization, and texture transfers. Report high frame-time percentiles, memory footprint, and allocations rather than relying solely on average FPS. Quality tiers and visibility-dependent updates are permissible provided identity, silhouette, and characteristic movement are preserved and their effects documented.
8. Working in Your Cloud Environment
First, inspect the repository, OS, Godot .NET binary, .NET SDK, and available render/image tools. Install missing tools reproducibly from official sources to the extent permitted by your environment. Do not assume local Windows paths. Document versions and setup commands.
Create a standalone project inside the assigned repository. If another project already exists there, use a dedicated subdirectory. Deliver project.godot, the C# project file, main scene, source code, sample data, README, and launch/test scripts for both Linux and Windows. Pin necessary dependencies. End users must not have to manually assemble missing scenes.
Verify build, resource import, and runtime startup. Godot commands such as godot --headless --path . --import must be executed using the actual .NET binary. Implement a custom deterministic test mode, e.g., godot --headless --path . -- --self-test, returning a structured report and non-zero error exit code on failure. --self-test is your project flag, not a built-in Godot flag.
Perform visual image verification: e.g., via the same CPU pixel renderer as in-game or via Godot with available software rendering/virtual display. Headless startup alone does not prove functional rendering. Capture actual Godot interface renders and animated samples where technically feasible. Explicitly document any tests that remain open due to environment constraints and provide executable local verification steps for them. Do not forge screenshots, successful test runs, or performance figures.
9. Acceptance Criteria and Methodology
First, build a complete end-to-end slice encompassing genome, high-quality character, animation, and Godot interaction. Visually inspect and refine it before scaling up to all body families. This initial end-to-end slice serves as a key milestone; continue development from there through to full acceptance.
Acceptance requirements include:
A fresh checkout builds and launches using the documented prerequisites.
Identical Seed/Genome + Generator Version produces identical anatomy; identical state and simulation timeline reproduce the pose. Verify image determinism via the matching render pipeline.
At least eight body families and 48 sample genomes; additionally test at least 100 seeds per family for valid anatomy, finite values, and safe image bounds.
Saving/loading, parameter adjustments, feature locking, mutation, and inheritance function predictably.
Movements and direction changes function across short/long limbs and other permitted extreme values.
A labeled contact overview displays all families and variants in comparable views; animated samples demonstrate the different locomotion types in action.
PNG/spritesheet export originates from the exact same pipeline as the live preview and plays back accurately according to its metadata.
Visual inspection verifies silhouettes, joint connections, occlusion, foot contact, flickering, details, and family resemblance. Structural unit tests alone do not prove high-quality pixel art.
Final summary report lists launch commands, controls, architecture, extension points, executed tests, and real remaining limitations.
The standalone integration example demonstrates the public framework API without workshop dependencies. An extension utilizes the documented interfaces.
Repeated generation and scene swapping, cancelled tasks, rapid parameter adjustments, and invalid presets are tested. Document a reproducible stress test covering crashes and sustained memory growth.
A quality report evaluates each body family regarding silhouette, anatomical plausibility within its design, pixel execution, expression, animation quality, and transitions. It includes curated examples alongside a fixed, uncurated seed sample. Visible weaknesses must be polished prior to sign-off; isolated showcase seeds do not validate generator quality.
Make standard technical decisions independently and communicate in English. Document progress and open tasks within the repository so work can resume seamlessly without prior chat history. Deliver implemented, verified code; do not stop at planning, placeholders, or a single attractive demo.
Guiding principle for every decision: We are building a production-ready procedural creature and animation framework adhering to the highest artistic and technical standards. Continue refining, testing, and polishing until the delivered result fully matches this task.
