From a real object to a playable world.

Beady Little Eyes begins with a physical vocabulary: beads that occupy space, wire that bends and holds, stones that belong to a structure. Chirincoca brings that vocabulary into digital art and game systems, then checks the result against the objects and against play.

One object, several forms

  1. Physical reference

    Start with a photographed piece or a construction study. Look closely at how the materials meet.

  2. Digital translation

    Build and refine a digital form. Geometry, surfaces and proportions have to serve the physical reference and the game.

  3. Integration

    Bring the work into the game, where lighting, movement, controls and context reveal new problems.

  4. Review

    Compare what appears on screen with the original piece and the intended experience. Revise or discard what does not hold up.

Handmade pink-beaded copper dragonfly resting on lava stone in sunlight.
Physical objectBeads, wire and stone, made by hand.
An in-engine dragonfly with beaded wings and a series of stones, perched on lava stone.
In-engine captureDevelopment presentation capture · October 2026.
A character beneath a lit redwood-bank ledge, with a dragonfly above and creek water alongside.
Gameplay capturePlayable development scene · October 2026. An isolated place study; not final campaign footage.

One creative lead, work moving in parallel

Chirincoca is a one-person studio built to work in parallel. The creative lead sets the direction and gives bounded AI-assisted work lanes ownership of research, engineering, art integration, testing and recovery of existing work. They can advance separate tasks at the same time. Cross-system decisions, visual choices and playable results return to him for review.

That structure lets a small studio explore a large design, but it also makes rejection essential. A render can look plausible and still violate the physical reference. A test can pass while measuring the wrong thing. A new system can work alone and fail when integrated. The answer is to inspect artifacts, reconcile ownership, run regressions and play the build. Bad work gets revised or discarded.

What failed, and what changed

The production record includes bad renders, duplicated implementations and false confidence from tests. The useful story is how a better decision was made, not how quickly an image appeared.

The test is the work itself.

A physical object you can inspect. A digital form you can compare. A game you can play. Those are the proofs that matter here.