We’re Not in Kansas Anymore. Me Neither!
I’m not flogging AI. I’m saying use it—but use it with real-world wisdom and experience.
Journal entry ↓Skritch in the yard. 9 September 2026.
Brought the player into the game world this morning to give the little #ucker a reality check.
Pretty soon, we will be answering to investors, milestones, ROI and all the other criteria that measure success in the real world.
But AI doesn’t live in the real world.
And on most days, it feels like the AI companies don’t live in it either.
The tech is mind-blowing. The blue sky, galactic.
But right now, I’m on earth. This is reality.
And I’m in a good position.
4 machines. All Apple. One brand-new M5. Studio screens. Storage. High-speed internet and a $300 Codex account plus Claude Pro. Studio monitors.
I have a yard which grinds to a standstill when I push the pedal to the metal with any fast character movement.
And I still have 90% of elements outstanding.
And getting AI to forecast anything is impossible because it has no comprehension of time as we know it. It doesn't have to pay the rent.
I was taught to make television by Murphy’s law. What can go wrong will go wrong. I grew up in the 80s under the steel heel of hard, uncompromising men who had a daily TV show to get to air. Failure wasn’t an option when you were a Packer, Murdoch or Wonder World! reporter.
40 years of entrepreneurship also hardens you.
So I test and re-test—way ahead of ever having to.
I plan for the worst.
Load the system up.
Overload it.
Then redline it.
I’d rather do it now on my own money than somebody else’s.
I won’t bore you with all the stuff that needs to go right in a video game for it to work. But if there’s one stray character in the code, it ain’t pretty.
So this morning, we started the Reality Checks.
The first measurement points to drawing the scene: about 31 ms per frame, compared with under 3 ms for the measured collision/security work. That already exceeds the 16.7 ms budget for 60 fps.
The renderer is issuing roughly 4,800 draw calls in this view. Blah. Blah.
For Carny as I’ve described it, tens of thousands to a few hundred thousand lines of custom code is a plausible scale for the finished game. That’s a broad comparison, not an estimate derived from a complete Carny specification.
That excludes the engine, libraries and generated artwork data. Those can add millions of lines without representing work we need to write.
The main systems would be:
- Movement, camera and interaction. - Grave excavation, inventory and body assembly. - Shrift, threats and game rules. - Animation, sound, lighting and weather. - Saves, interfaces and eventually phone/multiplayer connections.
Line count won’t tell us whether Carny is affordable or nearly finished.
A small rendering mistake can stall the whole yard; thousands of additional lines won’t necessarily fix it.
This pass:
- Reduced tunnel draw calls from 4,831 to 2,353, preserving artwork resolution and triangles. - Improved drawing time from roughly 31 ms to 22 ms. - Restored visible Skritch and corrected discarded movement time. - Passed 12 crossing legs across three graves. - Verified the speech-to-music playback sequence.
The yard still misses the performance target. Remaining-art capacity and a sustained 20-minute walkthrough are unproven.
The video is rendered frame by frame. It shows the artwork and movement; it doesn’t prove the game can sustain them in real time. That’s why these reality checks matter.
So, now I’ve established the Scratch’s size relationship to the yard, I am returning to decorating it fully and then starting a new LAB to work on the camera angles of the Scratch digging a grave from above ground.
I’m not flogging AI. I’m saying use it—but use it with real-world wisdom and experience.
If left unchecked, AI will give you the world. As an atlas.
Production notes — prepared by Codex
The following technical account is separate from the first-person Dev Log by Brett Clements of Mongril Labs. It describes our local WebGL prototype and the evidence collected on 9 September 2026. The yard is not a finished game or an accepted real-time release.
What the film proves
The film contains 900 frames for a 30-second sequence. Each frame can take longer than 1/30 of a second to calculate before encoding. A smooth film therefore demonstrates composition and animation, but does not demonstrate that the live yard sustains that speed under player control.
What the measurements show
At a 1984 × 1116 canvas on the M5 Max MacBook Pro, the sampled tunnel view took a median 31.0 ms for main-scene drawing. Grouping cobweb strands reduced submissions from 4,831 to 2,353 with the same 5,667,261 scene triangles. Drawing median fell to 21.9 ms. These are sequential, stationary-view measurements, not isolated GPU timings or a sustained walking benchmark.
What remains unproven
Frame-interval p95 remained about 33.4 ms, with observed pauses above 100 ms. The proposed 60 fps target remains unmet. Twelve controlled grave-crossing legs passed; that does not establish reliable input across the whole yard, basement access, or a 20-minute session. Remaining-art percentages are Mongril Labs’ estimates, not measured capacity or completion statistics.
The art pipeline
Preserve the original artwork and produce traceable runtime derivatives. Record source hashes, dimensions, placement and scale. Inspect both ordinary PSD animation and embedded Fresco motion metadata: one motion layer must remain one logical animated asset, with its timing, holds, looping and transparency. Expanding every frame into scene geometry would multiply the load and lose the intended playback structure.
Budget the runtime, not the drawing
Record texture dimensions, decoded memory estimates, geometry and material counts, animation upload rates and download size per logical asset. Share equivalent runtime resources. Use separate representations for visible art, collisions and shadows. Graves and frames are walkable; headstones, flats, hedges and the Hump remain obstacles. Validate at delivery size and close viewing distance rather than hiding cost by blurring the entire yard.
Carny’s working SOP
CARNY_WEBGL_LAB_SOP.md, version 0.1, is the local engineering reference. It supplements the existing Fresco import, composition and marketing rules. Mongril Labs’ art and latest direction remain authoritative. The document has not been reconciled across all Studio projects. Creating an SOP does not itself pass a performance milestone.
What the SOP asks us to prove
Record machine, browser, build, canvas dimensions and quality settings. Compare identical routes before and after changes. Measure frame intervals, long stalls, drawing cost, geometry, texture use and loading. The proposed main-Mac targets include p95 frame intervals at or below 20 ms, p99 at or below 33.3 ms, no repeated stalls over 100 ms and no progressive slowdown during a 20-minute route. These are proposed acceptance targets, not achieved results.
The next rendering investigations
The current grave batching spans the yard and expands indexed triangles, which limits spatial culling and increases memory use. Investigate spatial batching, shared geometry or instancing where art permits, and a measured shadow-update budget. Freezing shadows was useful diagnostically; it is not a finished solution for moving searchlights. Test each change against the same sharp baseline.
A deliberate change of scope
Mongril Labs’ immediate direction is to finish decorating for a standard fly-through and develop grave-digging camera work in a smaller Lab. A rendered fly-through can be completed independently of proving a sustained Villain-driven walk. A live browser fly-through still needs a route-specific performance test. Neither should be described as completion of the full game.
Milestones we can inspect
First, approve the short film and its presentation. Next, inventory the remaining yard and basement art and agree the fly-through route. Install source-linked decoration in reviewable batches, then inspect every shot at output resolution. Keep the movement/camera and dense-art performance Labs separate, and require new capacity evidence before claiming a full interactive yard is ready.
Time, tokens and investor reporting
The account usage percentage does not reveal this project’s token total or cost, especially with simultaneous work on different Macs. Per-task token totals remain unavailable in the evidence record. A credible delivery forecast requires an asset inventory, measured batch throughput, named dependencies and low/base/high ranges. No dated whole-game shipping commitment or ROI figure is established by this pass.
Rendering defects visible in the review
These are the actual review screenshots supplied by Mongril Labs. They remain evidence of the earlier cut even when later exports change the route or restore a missing control.
Yard rendering problems
The welcome sign is readable backwards from this side, and the searchlight produces a harsh white ground patch. These are visible defects in the current test, not a finished lighting treatment.

Shadow ACNE
Shadow acne is the leading explanation for these horizontal bands: the shadow map can make a surface incorrectly shadow itself. This is a suspected cause, pending a shadows-on versus shadows-off comparison.

Missing move control
The MOVE control is absent beside the red action button in this earlier film. It existed as a separate HTML control, which the canvas-only export omitted. The export must composite it explicitly. The revised 16:9 export restores the MOVE control beside the red action button.

Plywood backs, where they belong
Mongril Labs will supply plywood textures for visible backs that need them, while reverse-side artwork can remain on other 2D flats where it works. The Morgue, Moma’s and Invinniecible carry text but will not be viewed from behind, so they need no special rear-text treatment. Backing work should follow the intended sightlines rather than be applied indiscriminately.
