The Pitch Was Perfect
The idea behind Amazing Digital Dentures was genuinely clever: build a digital pet inspired by Caine from The Amazing Digital Circus—an AI that sends you on adventures. Start with productivity-flavored quests (an over-engineered todo list disguised as a game), then pivot to full procedural game generation with Three.js.
It didn't work. At all. And honestly? That failure is more instructive than most of the polished demos we see.
The Descent into Three.js Hell
The developer started with Nemotron 30B and a straightforward approach: long prompts explaining how to generate working Three.js games. The model produced code. The code didn't run.
Next attempt: inject GitHub's Copilot skill cards—specifically the game engine skills—into the prompt. This is actually a smart move in theory. Skill cards are structured context that should help models understand domain patterns. But the approach immediately hit the context window limit the developer had set to save on compute.
So they scaled up the context window. Still broken games. Blank screens everywhere.
RAG to the Rescue (Sort Of)
The third iteration got more sophisticated: use another model (Codex, presumably an OpenAI variant) to distill the skill cards into a compressed text file, then RAG over it. This is the kind of hybrid approach you see in production systems—using one model to prep context for another.
It helped. The games were less broken. But "less broken" isn't "working." Simple HTML output? Fine. Clocks, todo lists, Snake, Breakout? Sure. Anything more complex—Tetris, for example—and the model falls apart.
What Actually Shipped
The project now exists as a simple HTML toy maker. One-shot HTML generation for straightforward widgets. No games. No procedural adventures. No Caine-inspired AI pet.
This is a graceful retreat to a scope the model can actually handle.
Why This Matters More Than Another GPT-4 Demo
Here's what makes this post valuable: it's an honest account of what happens when you try to ship with a 30B model in a constrained environment.
Most of the discourse around small models focuses on benchmarks and evals. "Nemotron 30B achieves X% on HumanEval!" Cool. Can it generate a working Tetris clone that runs in a browser without human intervention? Apparently not reliably.
The gap between "generates plausible code" and "generates code that actually runs" is the entire product surface. This developer tried every reasonable trick:
- Prompt engineering (failed)
- Structured context injection via skill cards (failed)
- Scaled compute (failed)
- RAG with compressed skill distillation (helped, but insufficient)
None of it bridged the gap for moderately complex game logic.
The 80/20 Trap
The pattern here is classic: the model gets you 80% of the way on simple tasks (HTML clocks) and 40% of the way on complex ones (Three.js games). That 40% isn't useful. You can't ship 40%.
This is the small model tax. You can get close enough on narrow, well-defined tasks. But the moment you need compositional reasoning—coordinating game state, rendering loops, input handling, collision detection—the model starts generating plausible-looking garbage.
Larger models don't eliminate this problem, but they push the failure threshold higher. GPT-4 might get you to 70% on a Tetris clone. Claude 3.5 Sonnet might hit 85%. You still need human intervention, but you're intervening less often and on more subtle bugs.
The Context Window Gambit
The detail about artificially constraining context to save compute, then scaling it back up when things broke, is telling. This is the resource optimization dance every team building on LLMs has to do.
Longer context windows help with complex tasks—more room for examples, retrieved docs, error traces. But they cost more and run slower. The developer tried to thread the needle and discovered the hard way that Nemotron 30B couldn't generate working games even with generous context.
That's not a knock on Nemotron specifically. It's a reality check on what 30B parameters can reliably do in a code generation + execution loop.
What Would Have Worked?
A few options the developer didn't try (or couldn't, given hackathon constraints):
- Constrained generation: Template-based game scaffolds with LLM-generated content filling in specific slots (level layouts, enemy patterns) rather than generating entire games from scratch
- Multi-stage generation with validation: Generate game skeleton → validate structure → generate game logic → validate logic → generate rendering → validate rendering. Catch failures early before they cascade
- Hybrid symbolic/LLM approach: Use the LLM for high-level game design, hand off to deterministic code generation for the Three.js plumbing
But all of these require more engineering time than a hackathon allows, which brings us to the real lesson.
The Hackathon Scope Problem
The developer started with an ambitious, genuinely novel idea (AI pet productivity game generator) and ended with a working but much simpler tool (HTML widget maker). This is what responsible engineering looks like when the model can't deliver.
Too many AI demos stay in the "80% done" zone and declare victory. This developer shipped something that actually works within the model's capabilities, even though it meant abandoning the original vision.
That's harder than it sounds. There's enormous pressure—especially in hackathons and demos—to oversell what the model can do. Showing a broken Tetris game with "just needs a few tweaks!" is easier than admitting the approach fundamentally doesn't work.
The Ask
The developer ends by asking for suggestions on where to pivot. Here's mine: lean into the constraint.
The HTML toy maker that actually works is more valuable than the game generator that doesn't. There's a real use case for "generate me a custom timer/todo list/widget on demand." Market it as a tool for people who need bespoke HTML components but don't want to write them from scratch.
Or pivot to a different creative domain where single-pass generation works better: SVG art, CSS animations, data visualizations. Find the tasks where Nemotron 30B's actual capabilities (not its aspirational ones) create value.
The Real Takeaway
This project failed at its original goal and succeeded at something smaller. That's not a failure of imagination—it's a success of engineering discipline.
We need more write-ups like this. The field is drowning in demos that work once, carefully staged, with cherry-picked examples. We need fewer "look what I built!" posts and more "here's what I tried, here's what broke, here's what actually works."
The Amazing Digital Dentures project didn't ship the game generator. But it shipped something honest: a clear-eyed view of what a 30B model can and can't do when you try to build something real.
That's worth more than another polished demo.