The idea started nicely: a digital molar that sends you on adventures, inspired by The Amazing Digital Circus. A 'digital pet' that generates games and small missions to boost your productivity, disguised as a videogame. What happened is a hands-on lesson about model limits, contexts, and expectations.
Sound fun, right? But how do you get an LLM to build playable microgames every day without breaking everything? This story shows the practical pitfalls.
What they tried to build
The author wanted to create a pet that generated full games in three.js every day, powered by a large model (Nemotron 30b). The idea was that those adventures would help productivity — a kind of hyper-gamified to-do list that feels like a game.
They started with long prompts that described the game logic and how to implement it. When that failed, they added skill cards (ability templates) taken from this repo game-engine SKILL.md. Then they tried to distill those skills with Codex and apply RAG to keep the information available to the model. In the end, the project became a simple HTML generator — able to create clocks, to-do lists, snake or breakout, but not more complex games like tetris.
Techniques used and why they failed
-
Context window and memory limits: the model had a short
context windowto save compute. Adding more context blew up resource limits. Many failures came because the generated code needed more state and references than the model could keep. -
Long prompts vs. distillation: very long prompts are fragile. Putting everything into a single prompt usually gives inconsistent results. Trying to compress knowledge into skill files and using
RAGworked better, but not enough to deliver bug-free games. -
Common errors in game generation: blank screens from runtime errors, misdeclared dependencies, asset coordination problems, and incomplete physics or collision logic. A model can sketch valid-looking code, but tiny inconsistencies break the whole game.
-
Limited tooling and debugging: auto-generating code is useful, but without a test-and-debug loop (tests, linters, headless execution) the result breaks in production.
Technical things that help understand what happened
-
Nemotron 30b: a large base model, capable but subject to the same context limits and fragility when generating complex code. -
RAG(Retrieval-Augmented Generation): keeps an external knowledge repo and injects it into the model. It reduces the need for kilometer-long prompts, but it requires good search structures and chunking of information. -
Codex: used to distill and rewrite skills; helpful to turn instructions into more consistent code. -
three.js: the target library for the games. You have to coordinate canvas, state updates, and assets; minimal mistakes produce a blank screen.
Current status and practical lessons
The project pivoted to an HTML-toymaker hosted on Hugging Face Spaces. You can try it here: AmazingDigitalPetDentures.
Clear lessons:
-
Start with small, tested modules. Better to have many simple examples than one complex and fragile system.
-
Automate tests: a headless browser + unit tests for game logic helps catch blank screens before deployment.
-
Use RAG with chunking and precise metadata. It's not just dumping everything into a txt; you need to index and design coherent retrievals.
-
Limit the model's ambition: generating small interactions or templates that the system "assembles" is more robust than asking for a whole game in one go.
Ideas for pivot and technical improvements
-
Modular template generator: instead of full games, generate
three.jscomponents (player, enemy, physics) that users combine. More control, fewer failures. -
Hybrid system: predefined templates + generation of specific scripts. The model produces only the logic that changes between templates.
-
Automated verification pipeline: after generating code, run it in a headless environment and capture errors so the model can fix them (generate-test-repair loop).
-
AI-assisted interactive editor: suggest code chunks with instant preview so a human can accept or reject broken parts.
-
Procedural microgames: rather than recreating Tetris, generate variations of minigames with reduced rule sets. More creativity, less complexity.
Final reflection
Failing at a hackathon isn't a total failure; it's a lab where you see which parts of the stack need real engineering. What broke here has solutions: pipelines, tests, and modular design. Want to build a small generate-test-repair pipeline for this kind of project? We can sketch it and turn the digital molar into a reliable microgame factory.
Original source
https://huggingface.co/blog/build-small-hackathon/amazingdigitaldentures
Summary: A project inspired by The Amazing Digital Circus tried to generate full games with Nemotron 30b, three.js and RAG, but ran into context limits, runtime errors and lack of automated tests. The author pivoted to a simple HTML generator; the key lesson is modularity, automated tests and generate-test-repair pipelines to make AI code generation viable.