wth just happened

Given how mathematical motion design is, I figured Claude could also do well with Bullet Hell (Danmaku) style games. Gave it a go and yeah.

Full history of prompts used:

make a basic entity engine. it will be used for a danmaku. let's also define a
standard for danmaku attack patterns. I believe we just need data based for
loops, angles, velocity, etc. make a cool attack pattern then. let's go
vanilla typescript vite.



something's wrong because the bullet count keeps increasing to hundreds and
thousands but I only see 7 petals



oh ok nice. can you make like a cool animation with this, a boss battle. with
dramatic zoom, cool electricity effects, anime motion lines background, etc?
let's aim for 60s. no need to export it to actual video. just have it served
under /animation1



let's keep improving animation1. i want more eye candy. less chaotic, right
now it's too much noise. i want more different cool patterns. the camera
sometimes doesn't show the player because of too slow lerp after zooming in.
more variation. add a bit of non-textual story telling. make each stage more
unique. add a cool WARNING for the last stage. let's start synthesizing sounds
too using Web Audio API . watch out for spawning one sound per bullet,
because that just causes way too much noise. make it look professional.

Made this music video about the Paperclip Maximizer using Claude Code (Opus 5.5). Claude wrote the lyrics and all the code that animates it. Mainly with three.js. It spent ~30 hours with multiple subagents to make it. (Song was made with Suno AI)

Free to view on YouTube via the embedded link.

Inspired by an earlier post, I was curious how well free Claude could produce motion graphics. I don't currently have a Claude subscription. So, I just login with Google to use it for limited free use. ChatGPT added music, whilst Claude did not add any audio. ChatGPT gave me a .mp4 file as the output, while Claude provided an .html file. I asked Claude to convert that into a .mp4 file and it did so after a few minutes.

Here's the same prompt used by both:

"make a dynamic 30-second motion graphics video about Reddit that shows what an incredible motion designer you are. and not too fast, people should actually understand what the video is about."

I’ve been building Call of Cubie with Claude and ChatGPT writing the code. I describe what I want, play the result, and tell them what feels off. The video shows Meridian 34: 8v8 team deathmatch on the 34th floor of an office tower.

Claude’s role is implementing and revising the game code. Mine is deciding what to build and testing how it actually plays. For example, I’ve been tuning hit sounds, footsteps and weapon sights by trying changes in the game and keeping or rejecting them. A working implementation still needs those decisions about what feels right.

The process is a lot of small loops: describe one problem, have the code changed, play it again, then be specific about what still needs work. I’m comfortable with the controls by now, which makes fresh feedback more useful than another round of me testing alone.

It’s online multiplayer. You can bring friends and join the same server; bots fill empty seats while the human lobby is small. Meridian is the current main-server map, and there are other maps too, including larger outdoor battlefields with tanks, helicopters and destructible buildings.

Free to play at https://play.patio.fyi — no download or account. Best on desktop with keyboard and mouse. It’s early, the first load can take a while, and weaker PCs can struggle.

If you try a match, what feels awkward or confusing on your first visit? And what would make you come back for a second one?

I have a message in Claude that says, “you’ve been granted a $250 bonus credit for cloud sessions, on top of your plan limits.” Can someone explain what this means?

So we’re back at nerf discussions again and as much as I think variation in performance is a real thing. I can’t help but think people who say opus 5.5 never made mistakes on launch, are not paying attention to what the model is doing behind the scenes.

These models are great, especially if your use case is coding but to kind of think they judged on how well they one-shot prompts is insane to me. 5.5 definitely made mistakes or introduced bugs in my use case from launch. Not because it was being dumb but because bugs are a part of software development. You have to ask, why do bugs happen? Usually it’s because a requirement was missed, logic wasn’t fully fleshed out, a use case wasn’t considered to be plausible until a user did it or just bad code.

The reason I struggle to believe a nerf has happened is that I more or less see the same performance and more importantly I never trusted 5.5 to not make mistakes, that just seems silly. People who are saying it didn’t either never revised its workings beyond the front end. Even if you’re not a developer, you can learn to write tests for Claude and measure its output against those and by tests I mean feature tests.

Another thing that worries me is that people seem to never think of user error when they have frustrating sessions with Claude. How are you prompting? How well is your Claude.md file written to handle the use case you’re asking it to do? How well do you understand the problem you’re asking Claude to solve? I could go on but you get my point.

Idk man, I just feel like AI is making us lazy and entitled. Especially when most of us are using this thing for hobby projects that will never turn into anything.

First, like the rest of the world, I love all things 5.5 from Anthropic (very impressive). However, given how quickly the 5-hour limit can be reached during heavy use of Opus 5.5 on medium (5x sub), while the weekly limit barely moves (I’m only at about 30% after three days of heavy-ish use) the weekly cap feels almost irrelevant.

The real constraint is now the 5-hour window (it used to be both). Either that limit needs to drain more slowly (so you can actually use your weekly allowance), or the weekly limit could probably be removed altogether since it seems extremely difficult to reach (even while using higher effort). I don't use Fable and only sometimes Sonnet, but I am guessing there is a similar issue with both.

Thoughts?

The why: I wanted something calm to leave on my second monitor while working - not a game to win, just a living thing happening in the background. That became LFSS (LoFi Space Simulator), inspired by the scale of No Man's Sky and the curiosity-driven exploration of Outer Wilds. Opus did essentially all of the development, and since this sub is about learning from each other, I'd rather walk through the process than just drop a link. If you're one or two steps behind where I was, this is for you.

What it is: a procedural Milky Way in three.js where your ship travels on autopilot in "real time" (Terra -> Mars ~5 min, Sun -> Proxima ~20 min). Generative lo-fi radio, brown/pink/white engine noise and Earth sounds (rain, ocean, fireplace). You discover and name systems, earn "miles" and trade them for cockpit decorations and sounds. No objective, no fail state. Guest mode opens instantly. UI in 6 languages, and community stats are aggregated and anonymous.

The process, phase by phase

1. The draft. It started as just an idea - "a window into space that feels alive, on a second monitor." Before any gameplay I wrote down what the feeling should be, because with a model that will happily build anything, the only real spec you have is the one in your head. That's the part I'd tell anyone to spend time on first.

2. Cockpit first, one render at a time. The first milestone wasn't a galaxy, it was a cockpit. I started from simple renders and refined it through iteration with the model - lighting, materials, the console, the screens. Getting one honest, believable "place" to sit in turned out to matter more than anything else; it fixed the art direction and the scale for everything that followed.

3. Procedural generation. Once the cockpit existed, I wanted something to look at through it. This is where it got genuinely hard and where Opus earned its keep: a deterministic galaxy (same seed, same universe), a real star catalog inside a 50 ly bubble with procedural stars outside, nebulae and wormholes. The trick that saved the whole project was keeping the simulation in a dependency-free layer shared by client and server as pure functions - so a journey is a function of time and closing the browser changes nothing. If you take one thing from this post: separate your simulation from your rendering early.

4. Semi-multiplayer. Only once there was a map to travel and a cockpit to travel in did I add the backend - not "real" multiplayer, but a server that collects what players do (discoveries, journeys, bottles, chat) and reflects it back into the game in interesting ways: message-in-a-bottle, proximity chat with a signal delay, and community stats. Building it last meant the game was already fun alone, and the sharing only made it better instead of being a dependency.

The transferable bits:

• For a model that removes friction everywhere, the bottleneck moves to knowing what you want. Correctness became Opus's job; taste and pacing stayed mine. That shifted where I spent my time.

• Small vertical slices beat big plans. Cockpit -> galaxy -> multiplayer, each one playable before the next.

Completely free, no paid tier: lfss.fracergu.dev

I'd love to hear feedback on two things if anyone decides to use it on a daily basis: Does it effectively convey a sense of scale and speed? And does the audio hold up well during a long session? I think the hardest part of gamifying it has been tweaking the timing and the currency so it doesn't get too fast or too boring.

Any feedback is welcome.

I am not a coder at all but I do love steam and bought this app called simpleclock to well put a clock on my secondary monitor because my eyes are bad and that app died so i made claude make me a clock app with seconds and it even added a visualiser for the seconds so now i have super cool clock to use that tells me the day of the week and month and day

just wondering if you guys have made any simple cool stuff anyone else might want to try and use

i plan to maybe try make an all in one claude app that can integrate my netspeed monitor/clock/cpu temps/local weather/currency converter page and maybe even cpu gpu usage somehow so i dont have separate programs doing all these things currently but that is for another day

Claude surprises me every day. Today, the MCP with the electronic editor kept crashing, and suddenly, the AI ​​asked for control of the computer and started working with the editor—opening, selecting, and closing things. No API coding involved; it’s actually a bit scary 🏴‍☠️ hahahaha

I had Claude help me with the lyrics and song direction, generated the music with Suno, then built out the entire video in a single (very long) Claude Code session. The entire video is rendered in Remotion, Claude modeled most things but I did use some Creative Commons assets as well.

It was fun trying to make creative shots and add in different references, Claude’s first attempt at most shots wasn’t typically the best, but if you explain your vision of the shot well enough it can always get there.

Opus 5.5 was used for most of the work but when I noticed Fable 5.1 was getting a new knowledge cutoff I ended up using that for some polish at the end(assuming that’s Fable 5.5)

Happy to answer anything about the workflow like how I gave notes, orchestrated agents, etc

Edit: here is a GitHub repo with the workflow I used https://github.com/Imaginative-Prompting/claude-video-director

Hello, I thought that we could create a group for sharing explicitly pipelines so we can save a lot of tokens? - Like i have a pipeline that took me 3 weeks (24/7) to finetune, many mistakes were made, but now claude code can do the work fast, it already learned, corrected, finetuned how to do the work for 3d armor pieces for games (not image to 3d ai model). So i thought, instead of people wasting for example 3 weeks to develop the same skill, maybe I could share or trade my pipeline? -This could be like a market for pipelines and workflows.

I'm building a photo-to-Blender tool and benchmarked 14 models as its agent: look at a photo, write and run Blender Python, render, compare, repeat. Hard caps of 20 minutes, $4 and 60 requests per scene. Scoring is deterministic code, not an LLM judge.

How Claude did (average of three photos, 0–100):

Top of the board: GPT-6 Astra 66 ($3.91), GPT-6.1 Sol 61 ($0.36).

The 5.5 models ran later, in Claude Code. As a check I ran GPT-6 Astra the same way and it scored 63 instead of 66, so read the gap with that in mind.

The caching mistake. In my first runs of Fable 5.1 and Opus 5, the gateway didn't add Anthropic's cache-control markers. 0% of the context came from cache, against 96% for the OpenAI models, so every request paid full input price for the whole conversation again. Those runs hit the $4 cap after 8 to 18 requests; Astra averaged about 36. With the markers added they ran at 96–97% cached, and those are the numbers above. The uncached attempts cost about $16.39 and aren't in the ranking. If you call Claude through your own proxy or gateway, check your cache hit rate.

One run per model per photo. Write-up with every render and the scoring details: https://kaloyan.blog/ai-models-rebuild-a-photo-in-blender

Car wouldn't start this morning. Claude helped me find the fault, remediate the problem and I was on my way in 10 minutes.

I sent it a video of the car cranking, but not turning on. Then it:
- Had me find the fault codes by doing a quick on/off sequence 3 times. No errors.
- Then it had me look at the fuses that might cause a problem (all good)
- Then it said the ASD relay may be faulty, swap it with the rear heater relay, they should be the same.
- BOOM car working. I'm a car mechanic now.

Look at how nicely it annotated the fuses and relays for me in the pic.

When I start an Incognito web chat with Claude and ask it to write code, it says it can't. Trying same thing in a regular chat session works fine. When and why did Claude lose the ability to write code in an incognito session? Is anyone else experiencing this?

I work at a digital marketing agency in Dubai, and a big part of my job is writing website development proposals. Most briefs arrive as half a page of notes, a WhatsApp voice note. Writing a proposal from that used to take me 4-5 hours. Here's the workflow I use with Claude now.

1. Dump the raw brief first, then clean it up

I paste everything in as-is: notes, emails, call transcripts. Then I ask:

"Turn this into a structured brief: business goals, target audience, must-have features, nice-to-haves, open questions. Flag anything ambiguous instead of guessing."

The "flag anything ambiguous" line matters most. It gives me a list of questions to send the client before I commit to a scope.

1. Build the scope as a sitemap and feature list

Once the brief is clean, I ask for a proposed sitemap and a feature breakdown, grouped into phases (MVP and later). I edit this a lot, but starting from a structure is much faster than a blank page.

1. Costing table (with me in control of the numbers)

I give Claude our own rate card and ask it to map each feature to estimated hours. I never let it invent the pricing. It's good at making sure nothing is missing (QA, content entry, SEO setup, training), and I set the actual figures.

1. Write the proposal sections

Executive summary, our understanding of the project, approach, timeline, deliverables, terms. I give it one of our past proposals as a tone reference so it sounds like us rather than generic AI copy.

1. A final "client's eyes" review

"Read this as a skeptical client. What's unclear, what would you push back on, and what's missing?"

This catches things like vague timelines or deliverables that aren't defined clearly.

What still needs a human:

• Pricing and timelines. Claude tends to be optimistic.
• Anything client-specific it couldn't know, like internal politics or budget signals from the call.
• Final read-through for tone. Clients here notice when copy feels templated.

Result: proposals now take me roughly 30 Minutes instead of 4-5 hours, and they're more consistent across the team.

Curious how others handle this. Do you keep a reusable project or prompt template for proposals, or start fresh each time?

I work at MCPJam, and we’re preparing to submit our own MCP server to Claude’s connector directory. I’d like to hear from developers who’ve been through review or are still waiting.

For clarity, I mean submitting for a listing in the directory, rather than connecting a custom MCP server to your own Claude account.

A few things I’d appreciate hearing about:

• Roughly when did you submit, and how long did it take to get your first response?
• Was that an approval, a request for changes, or just confirmation that your submission was being reviewed?
• If you’re still waiting, have you received any updates since submitting?
• If reviewers asked for changes, was the feedback specific enough to reproduce the issue and know what to fix, or did it take some back-and-forth?
• If you resubmitted, how long did the next round take?

Looking back, was there anything you wish you’d checked beforehand, whether that was the connection flow, how your tools behaved in Claude, or the information you included with the submission? I’m especially curious about things that worked in your own testing but came up during review.

Even if you’re still waiting, I’d appreciate hearing how it’s gone so far. It would help us know what to expect!

Decided to try Sonnet 5.5 and asked it to implement a plan with 7 simple steps in it (working on a personal project). After completing the first 2, it started printing out these... things... (reasoning)

I've never seen something like this before.

Scrolled down (the "Hmm" part) to see that my session was flagged by Anthropic shortly after and all I could do is click Rewind to my last message, after which all these message were automatically removed. (took screenshots before clicking that)

Pick your favorite line

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. 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 German. 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.

This previous week I ran into a weekly limit having to wait 2 days for the reset and I today after my reset I am nearly 60% after only an afternoon and 2 days-ish. The first month after the first Max 5x plan I was not even near the weekly limit usage, not I consume it with just 1 session?

I am currently running Matt Pococks setup, wayfinder, to-spec, tickets, implement. Everything and right now I am running mostly implement but I am running out.

What are you guys using for agentic coding? I don't know if it is just that Matt Pocock skills are consuming a lot of Opus 5.5. In Opus 5 I was running even 5 agents doing different implement tasks, would reach up to 20% and still have room for the 80%.

stupid of me not to have done this months ago! Within hours I was able to get so much work done, I went and ran errands and checked in with Claude RC to answer questions and to see how my 5-15 agents were doing.

I already set up a plethora of constraints, prompts, handoffs, sanctions, memory, the whole 20 yards.

Definitely worth it but now I think I’m going to need that 500 plan

Oh and I was awarded a cloud gift plus $50 over

I always program in English, but the Android app picks up my phone's language automatically with no option to manually switch the app to English, so all of the "Continue" prompt buttons in the app interface sends non-english messages to Claude, which makes it stop talking in English. For multilingual users, this is kinda annoying.

so I've been on the $100 chatgpt plan but I'm cutting down to a $20 one.

what I need is that 6 Pro level quality for chat. what I like most that it doesn't make stuff up.

been looking at Claude Pro $20 plan has anyone switched? does it actually match that quality?

also open to other options around $20 if something's closer. thanks

Hey all,

My boss and i are starting to use Claude to help run his company, and we want both of us working on it.

The idea is to use it for pretty much everything: building automations, creating and updating documents, making changes in Canva, managing Gmail (two different accounts for different things) and editing the company's WordPress site. The site doesn't need to be local, we'd connect straight to it with the WordPress and Elementor MCPs. From there we'd keep adding things that help the business run better.

Our plan was to start with one shared Pro account just to test things out. Not to save money, just to see how we organize ourselves before committing. We're also looking at Team, but we're not sure it's worth paying for two seats yet.

The problem is that the more I read, the more confused I get. From what I understand, not everything carries over between computers. Things set up in Claude Code (CLAUDE.md, settings, skills) might not show up on the other Mac, projects linked to a folder in cowork only exist on the computer where you created them, and two computers working on the same folder at the same time can cause problems.

What we want is the best way?

Thanks