Creative Coding / CASE 04 / 2026-09-24
Claude Opus 5.5 hands-on: four creative coding tasks, from web page to finished video
In Claude Code, Claude Opus 5.5 built a 3D samurai game, an interactive meteor shower, a crayon-style animated short and a pixel-art mech animation. Each task delivered a runnable web page and a video rendered through a pipeline the model set up itself.
- Model
- Claude Opus 5.5
- Harness
- Claude Code
- Tasks
- 4 different tasks
- Outputs
- Web page + video
EXPERIMENT SETUP / 01
The tasks and how they were made
The four tasks are independent, and each had to deliver a web page that runs in the browser plus a video. The videos are not screen recordings: the model built its own frame-by-frame rendering pipeline to export them. Along the way it checked its work with headless-browser screenshots, fixed what it found, and wrote a making-of record. This page is compiled from those four records.
Only Ronin at Dusk kept the verbatim original Prompt. For the other three experiments, the task requirements are summarized from the making-of records rather than quoted from the Prompt, and this page does not reconstruct or guess the original wording.
RESULTS / 02
Four tasks, four web pages and videos
Each video was rendered frame by frame by a pipeline the model built; click to play it. The interactive version is the raw web page the model wrote. It opens in a new window, outside the site shell.
EXPERIMENT 01 / Three.js 3D action game
Ronin at Dusk
A 3D samurai game in a shrine courtyard at sunset: three-hit combos, deflects, guarding, dashes and waves of enemies. Character models and sound effects are all generated in code, with no external assets.
- Video
- 30 s
- Resolution
- 1080p30
- Audio
- Sound
- Three.js r128
- WebAudio
- Chrome DevTools Protocol
- ffmpeg
The interactive version loads Three.js and fonts from the internet. It is best played with a keyboard and mouse on a computer; the touch controls have not been tested on a real phone.
Open the interactive versionTask brief
- Make a 3D samurai game demo. The original request was a single sentence; the original text is below.
- Follow-up: record a 30-second demo video.
create a 3d samurai game demoWhat the model did
- It set its own ukiyo-e colour direction: the torii gate frames the setting sun, a raked karesansui sand garden is the arena, and about 380 cherry petals keep falling.
- The combat system has three-hit combos, a 0.24-second deflect window, guarding that drains stamina and dashes with invincibility frames; from wave 3, oni warriors appear that light attacks cannot interrupt.
- For the video, a scripted bot plays the samurai. Its tactics went through three versions, and a no-render simulation mode compared 12 random seeds to pick a run that reaches wave 3 with 2–3 deflects.
- Sound effects are logged with their timestamps only, then rendered into a soundtrack with an offline AudioContext, so sound and picture stay in sync frame by frame.
Found and fixed in self-review
- The blade looked almost black because the scene had no environment map to reflect: metalness went from 0.9 to 0.35.
- The samurai on the title screen faced away from the camera: it now starts facing the camera.
- During frame-by-frame capture, CSS banner animations still ran on real time, several times faster than the video: every frame now pauses the animations and advances them by 1/30 s by hand.
EXPERIMENT 02 / Three.js interactive 3D scene
Starfall Ridge
A meteor shower over a lake in a mountain valley: drag to orbit the view, click the sky to launch a meteor, and switch between four real showers: the Perseids, Orionids, Leonids and Geminids.
- Video
- 10 s
- Resolution
- 1080p60
- Audio
- Silent
- Three.js 0.160
- GLSL
- Puppeteer
- ffmpeg
The interactive version loads Three.js and fonts from the internet and needs a browser with WebGL2; it may stutter on less powerful devices.
Open the interactive versionTask brief
- Build an interactive 3D meteor shower scene with HTML and Three.js.
- It needs a starfield background, particle trails for the meteors, real-time lighting on the terrain surface and mouse-drag orbit controls (OrbitControls).
- Follow-up: export a 10-second 16:9 video.
What the model did
- A sky shader draws airglow, light pollution from distant towns and the Milky Way; 9,601 stars are spread by colour temperature and brightness and dim towards the horizon.
- Meteor trails use a GPU ring buffer of 36,000 particles, with particle motion and cooling colour computed in the vertex shader.
- A pool of 8 always-present point lights lets passing meteors light up the terrain and the lake; the light count never changes, so Three.js never has to recompile its shaders.
- The four showers use their real entry speeds and ZHR, and the page opens on the next upcoming shower based on the visitor's date.
Found and fixed in self-review
- Large black squares flickered into the video: the shader called pow() on negative numbers, which returns NaN on Metal, and bloom spread it into a square. Adding clamp fixed it, and the web page got the same fix.
- The scene was too bright and fireballs looked like daylight: point-light strength and fireball brightness were lowered across the board, and fireballs now spawn away from the radiant so they draw long trails.
- Trees hid the lake and the radiant marker sat on the title: trees were cleared from the shore and the sight line, and the radiants moved to the upper middle of the frame.
EXPERIMENT 03 / Canvas 2D crayon-style animated short
Baking Time
A 30-second hand-drawn crayon animation: an orange character modelled on Opus 5.5 bakes a cake that blinks back, then signs the ending by hand. Every frame is drawn procedurally in code.
- Video
- 30 s
- Resolution
- 1080p30
- Audio
- Silent
- Canvas 2D
- Chrome DevTools Protocol
- Python
- ffmpeg
The original video's music is a commercial recording with no licence for public release, so both the video and the interactive version on this page are silent.
Open the interactive versionTask brief
- A 30-second animation on the theme “Baking Time”, starring the Opus 5.5 character from a reference image.
- Fun, cute and charming, ending with an Opus 5.5 signature.
- No synthesized audio: only audio files found on the local disk.
- Deliver the finished video in one go, with no check-ins along the way, for posting on X.
What the model did
- It measured the character's proportions from the reference image; crayon texture, paper grain and hand-drawn line wobble are all drawn procedurally in Canvas 2D, with no image assets.
- It scanned the local disk for audio to choose a song, then laid out the storyboard on the song's beat-by-beat grid; the picture and 81 sound cues share one timeline.
- It could not listen during production, so it measured each sound effect's envelope, onset time and dominant frequency to choose and align them.
- The signature writes itself: the ink centroid of each column of an off-screen signature gives the path and speed of the crayon tip.
Found and fixed in self-review
- The cake pan jumped when handed from the character to the oven: its starting point is now computed live from the character's pose.
- The steam transition stayed fully white for about 0.75 s and slowed the reveal: it was cut to about 0.35 s.
- Measured over 250 ms windows, many sound effects sat 12–30 dB below the music: gains were raised across the board from those measurements.
EXPERIMENT 04 / Canvas 2D pixel animation
Plasma Lance Mech
A pixel-art sci-fi mech that charges, fires a plasma beam, vents heat and resets, on a loop. A single HTML file with no external resources.
- Video
- 30 s
- Resolution
- 1080p60
- Audio
- Silent
- Canvas 2D
- Node.js vm
- ffmpeg
The interactive version uses a 4:3 framing by default; add #wide to the URL to switch to the 16:9 framing used in the video.
Open the interactive versionTask brief
- A single self-contained HTML file in plain JavaScript and Canvas 2D, with no external assets, libraries or network requests.
- Draw to a 128×96 off-screen canvas, then scale up by a whole-number factor; everything pixel-aligned, with no anti-aliasing, gradients or shadowBlur.
- A fixed palette of about 24 colours and a procedurally drawn mech of about 28×36 pixels.
- A looping idle → charge → fire → recover state machine, an allocation-free particle pool and a fixed 60Hz update.
- Follow-up: export a 30-second 16:9 video.
What the model did
- Drawing goes into a palette-index frame buffer, which rules out off-palette colours by construction; glow and shadow come from remap tables plus 4×4 Bayer dithering.
- Pose parameters ease on every tick but are sampled and rounded only every 5 ticks, giving a 12fps pixel-animation cadence while the beam and particles still update at 60fps.
- For the 16:9 video it added a 160×90 framing and made every blinking light's period divide 1,800 ticks, so the 30-second video loops seamlessly.
- The page script runs directly inside Node's vm module and is driven frame by frame; the 30-second 60fps video renders in about 6 seconds.
Found and fixed in self-review
- The charging arcs looked like a tangle of cyan lines: jitter amplitude, radius and spawn chance were reduced.
- Red warheads in the missile pod sat next to the head and read as a pair of red eyes: they became dark launch tubes.
- The arm cannon did not look heavy: the housing grew from 7px to 9px and the barrel from 3px to 5px.
- Headless Chrome's virtual time did not advance requestAnimationFrame, so every screenshot showed the first frame: it now calls update() up to the chosen moment and then renders.
OBSERVATIONS / 03
What kept coming up across the four experiments
None of the four tasks stopped at "the code is written". The model inspected its output, located problems and fixed them; when a tool was missing on the machine or rendering hit a limit, it found another way to finish. The points below come from the four making-of records and have not been checked by human play-testing or expert review.
- 01
None of the four videos is a screen recording. The model took over the page's clock and random numbers, stepped and captured it frame by frame, then handed the frames to ffmpeg, so the same parameters reproduce exactly the same video.
- 02
The model tiled key frames into contact sheets to review its own work, then fixed what it saw: Starfall Ridge lost the black squares caused by pow() returning NaN on Metal, Plasma Lance Mech lost a missile pod that read as a pair of red eyes, and Baking Time lost a jump when the cake pan changed hands.
- 03
When ffmpeg or Homebrew was missing, the model switched to the copy bundled with the npm package ffmpeg-static or the Python package imageio-ffmpeg; when ffmpeg could not decode an audio format, it used macOS's built-in afconvert instead.
- 04
Very long single outputs get cut off: Plasma Lance Mech's first attempt to write the whole page at once failed, so the model wrote the same file in four parts.
- 05
Limits: game feel and difficulty have not been play-tested by a person, and the Baking Time mix was levelled from measurements; nobody listened to it during production.
KEEP EXPLORING