Generating prototypes from game design document with Cursor, Zed and LÖVE | by Oleg Chumakov | Luden.io
From the collection
Game Development
What it is all about
This article tells the story of how we (a few folks from Luden.io ), tried to use LLMs, Tiled Map Editor , and LÖVE 2D Lua game engine to generate video game prototypes from a game design document during the pre-production of the SuperWEIRD game.
What you will find below:
- All the sources so you can generate your own prototypes
- Gameplay and videos of the development process
- Why did this approach not work as planned for us
- How it ended up transforming the SuperWEIRD game in unexpected ways Press enter or click to view image in full size
Short summary
To automate game prototype generation, we used: Cursor/Zed in Agent Mode, ChatGPT 4.1 and Claude 4, clear and well-formatted markdown game design and style guide documents, a markdown task list, procedural code-defined graphics, Tiled map editor for levels, and command-line-friendly game engine LÖVE with gameplay log output.
It worked, though it wasn’t as easy as we expected. However, it did save us time at a critical moment, so it was worth it.
And no — our game designer didn’t end up using this system as intended.
And yes — this article is fully written by me, not AI-generated. Here is the proof: Press enter or click to view image in full size
Context
What kinds of games is this prototyping system designed for?
This system is suitable for prototyping a wide range of games with core mechanics such as:
- Character movement (WASD controls)
- Resource mining
- Crafting and building (e.g., constructing defense towers)
- Automating tasks by hiring workers (for mining, crafting, and building)
- Trading/exchanging with NPCs
- Handling enemies that attack, steal resources, or destroy structures
In summary, it’s geared toward simulation, automation, and strategy games with resource management and defense elements.
Why did we do this?
We developed this system during the pre-production of our new co-op game, SuperWEIRD — a game about automation and designing systems using an endless supply of low-quality (I mean like really unstable and unreliable, but that’s fine, since they’re free) tiny robots.
Our goal was to streamline prototyping for a game to faster test game design ideas and invest the team’s time only in the playtested concepts. Press enter or click to view image in full size We’re making SuperWEIRD with the help from Carina Initiatives , a team of amazing people making and supporting great projects in math, STEM, and education, such as National Math Stars , Art of Problem Solving , and Thinky Games .
Idea
Optional, skip if you need only technical details.
It all began at a Gaming Day with Google Cloud at Nexters ’ office in Limassol. During a break, we discussed LLM tools for game narrative, and Maxim from Owlcat Games raised the challenge of managing large-scale narratives — it’s hard to fit all content into an LLM’s context window and maintain smooth collaboration for narrative designers.
He was looking for a solution that would make it easy to access relevant narrative segments while working on related parts of the story and highlight conflicts. Press enter or click to view image in full size We talked about meaning-based search and Retrieval-Augmented Generation (RAG) as a promising but underutilized approach, compared to the usual “put everything in context” strategy. We hypothesized that Cursor’s way of handling “docs” — by indexing and surfacing only the relevant parts — might solve Maxim’s issue.
Disclaimer: This was before Google released NotebookLM , which now seems like an ideal tool for this scenario. Our in-house RAG solutions, in my opinion, weren’t user-friendly enough for narrative designers compared to Cursor. Press enter or click to view image in full size Inspired by the discussion about Cursor, we wondered: what if game designers could quickly generate prototypes directly from their game design documents, playtest their ideas, and only move them to production after successful testing?
Because we focus on system-driven games, we often prototype using simple “primitives,” but this still requires programmers, who are already busy with other tasks. Even if a game designer can code, it still takes a lot of time. What if we could now create prototypes in just 1–2 hours?
Spoiler: Game designers appreciated this new prototyping setup — though they don’t use it for every idea. They also requested to make a bot that plays the generated game “with maximum efficiency,” to help spot balance and systems issues. And no — we didn’t manage to make this bot.
Components
The tech stack needed to make this “generation” possible:
Map editor
We used Tiled Map Editor, a simple and powerful tool that exports maps in a text format, making them easy to load and render in the game engine. The same files can be re-edited in Tiled anytime. Press enter or click to view image in full size For tile textures, we used free assets by Kenney.nl (licensed CC0): https://kenney.nl/assets/micro-roguelike Press enter or click to view image in full size
Game engine
We needed a game engine with a command-line build that outputs gameplay logs, so an LLM Agent could launch the game and track what’s happening. After testing MonoGame, Love2D, and others, we chose Love2D for its simplicity, Lua scripting (which LLMs handle well and it’s the same language we use in Defold), and fast iteration. MonoGame is great, but C# requires longer build times.
Test cases during the selection:
- Building a simple 2D game with WASD movement and log output
- Letting the Agent launch and debug the game itself
- Creating basic procedural visuals (squares, circles, etc.)
- Loading and interpreting Tiled map files
LLM coding agent
To keep the experience accessible for non-programmer game designers, I focused on local IDE workflows — letting designers edit maps in Tiled, ask the agent to update the code, and launch the game easily. We tested VS Code, Zed, and Cursor. Press enter or click to view image in full size Test cases during the selection:
- Reading and following project documentation task-by-task
- Running the game from the command line
- Auto-fixing and relaunching after errors
- Ensuring Tiled’s .json map files weren’t changed by the agent
Cursor and Zed (with an OpenAI API key)
Cursor and Zed (with an OpenAI API key) performed similarly, but Zed’s Agent feature was still in preview and not officially available on Windows at the time. (As of June 2025, I mostly use Zed, but most early prototypes were done in Cursor.)
Disclaimer: I’m a longtime fan of Zed (and before that, Sublime Text), but I did my best to test VS Code without bias.
VS Code (with an OpenAI API key)
VS Code is familiar to our game designers and famous for its strong documentation, so I started there. Agent mode worked well initially, but sometimes project docs were ignored or response times lagged — often fixed by restarting VS Code. Press enter or click to view image in full size Occasionally, the game’s log output wasn’t integrated into agent dialogue. Switching to Cursor solved these issues with the same API key and model. I suspect VS Code agent integration is improving (likely even better with Copilot subscription), but for speed, I moved to Cursor with plans to revisit VS Code later.
Project structure
To help the Agent better understand the project, I placed the game design document, task list, and development guidelines (including file structure) in the docs directory. Press enter or click to view image in full size I manually created the initial task list and then decomposed it into more details using the same LLM Agent. I’ve heard good things about the Task Master CLI tool for decomposing tasks. If I was to start this experiment again, I’d use it for task breakdown. Press enter or click to view image in full size At one point, automatic file updates caused the “ToDo” section to move between design.md and todo.md without me noticing until after several iterations.
Agent workflow
- Read design.md and instructions.md / Reality: OK
- Find task in todo.md / Reality: OK
- Implement task / Reality: OK, but often with multiple iterations and game restarts
- Store constants in constants.lua / Reality: OK, but you should keep telling agent to do that in 40% of cases
- Keep game logic separate in logic.lua / Reality: Gave up — this needs clearer explanations and examples for the Agent, or else it creates unused or fake logic
- Add tests in tests.lua / Reality: Not relevant after previous step failed
- Run tests and fix issues / Reality: Not real issues were found with failed tests
- Playtest the game as a designer and report any issues to the Agent / Reality: OK, much better than expected when launching the game by asking the Agent to do that — this is how the Agent can see the logs from the play session and understand reported issues much better. If the Agent can’t fix or understand an issue, feel free to ask it to add more logs to the specific part of the gameplay — worked all the time for me.
- Mark tasks as done / Reality: Sometimes it’s necessary to ask the Agent to revisit the task list, as it may try to redo tasks that have already been completed.
- Edit design.md or the map in Tiled, and repeat / Reality: OK but pay close attention to any attempts by the Agent to modify the Tiled exported map file
- After design changes, sync docs and tasks / Reality: OK
After big design changes, run something like: “ revisit design.md , todo.md and instructions.md , compare with current code implementation and propose documentation cleanup updates ” to sync tasks and highlight conflicts.
The single most effective way to improve the Agent’s understanding of the design in our experience was to include examples into the documentation. Press enter or click to view image in full size
What we’ve prototyped
Features tested using generative prototyping (total time spent is about 15–20 hours):
- Different building processes (with blueprints, virtual coin-based, real resource-based, etc.)
- Building towers
- Coins as a virtual in-game currency (UI counter)
- Coins as a collectible resource item
- Enemies who steal or mine resources
- Enemies who attack buildings
- Enemy wave spawns
- Enemy spawns triggered by player actions
- Rechargeable and classic tower defense towers
- Craftable towers made from multiple components
- And countless small details I can’t even remember.
What else we’ve tried
LLM-generated feature designs
We experimented with using Agent to generate feature designs based on the whole project’s documentation and code, for example Emergent Building System Design . This approach worked technically, but none of the generated designs were compelling enough to pursue further or playtest. Press enter or click to view image in full size
Automated playtesting bots
We tried creating a bot to automatically playtest the game. However, after investing about two hours into a simple game scene, we didn’t see meaningful progress and went back to human playtesting. We haven’t spent enough time here to draw solid conclusions.
Final thoughts
Who else can use it
This workflow is fast and strongly supports the principle of “it’s faster to try than to discuss” — something we value in game design. While it’s not quite ready for non-technical game designers, it’s much easier than learning to code from scratch, and a big time-saver for designers who are comfortable with basic coding. Press enter or click to view image in full size
Usage
We relied on this system heavily during early development (pre-production). Usage dropped after the core systems were finalized — though, in reality, we returned to it frequently (see further explanation below).
Sources and how to play
Since many iterations followed the cycle of play-redesign-implement-play, not all versions were saved on GitHub , and there aren’t in-game tutorials.
To launch the game you need to install LÖVE and execute “ love . ” command in the repository’s root directory.
For information on gameplay and controls, refer to design.md . Basically, you just need WASD to move and the mouse to build. For constructing programmable objects on the map, use hotkeys like Arrows for directional commands and G, 1, 2, 3, and 4 for other commands— these are also listed in design.md . Press enter or click to view image in full size Tilemap tiles logic simply described as list of IDs Press enter or click to view image in full size Please feel free to use our setup for your own generative prototyping — everything is open source under the MIT license . Always happy to read your comments here or in our Discord about your experience with the generative prototypes.
Thank you for reading (v1)!
Re: Final
Just before publishing of this article, new platform requirements emerged— the game needs to highlight its unique features early on and ensure a high average session length for random players.
These are always valuable goals for any platform, but the new target metrics were much higher than we anticipated.
This required us to rethink onboarding, as introducing our CIRCLE programming system too early made the game too complex and reduced playtime. Press enter or click to view image in full size Let me know in the comments if you want to learn more about the CIRCLE programming system. It’s interchangeable, it’s exist in any object in the game’s world, it’s a lot of fun, but a bit tricky to understand without programming experience. We didn’t have time to completely redo pre-production. So the idea was to invent some “tiny hack” to fit into new requirements since we don’t have time to re-invent and re-playtest new big features anymore. We haven't succeed in creating such “tiny hack” by tuning the existing parts of the game, and got depressed a bit.
Then we remembered our generative prototyping system, which allowed us to rapidly test some of the ideas immediately.
Surprisingly this led us to a much more engaging early-game design than we had before — a simple and intuitive programmable map for simple robots, instead of programmable complicated robots.
This approach made it easier to introduce the core mechanics while still leaving room for more automation and complexity later on. So after playtests we’ve doubled down on this and I hope to write another article inviting you to the public playtest as soon as possible.
I’m sure we wouldn’t have taken this path if the new platform requirements hadn’t challenged us and we hadn’t been able to test potential solutions so quickly. At the end of the day, this generative setup saved us time and made the game more unique and fun.
And yes — robots can pick up things and use it. Who said that we can’t craft shields and swords for them! What for? The SuperWEIRD world is full of weird stuff :) Press enter or click to view image in full size
Stay tuned
We hope our generative prototype sandbox will save you time in some critical moment the game development too. Thanks for reading (v2)!
Stay tuned for playtest announcements in our Discord , Newsletter and, oh boy, we’re filming Dev Diaries on YouTube — stop by and say hi in the comments!
P.S. Our toolset for game development
I don’t know why but I am a big fun of learning other developers’ IDE styles and tools, so please find ours below:
SuperWEIRD ’s game engine: Defold Game Engine ( here is why )
Tools we use
Cursor, Zed, VS Code, Sublime Merge, Sublime Text, Fork, Defold Game Engine, Unity Game Engine, Tiled Map Editor, GitHub and GitHub Actions, Figma, MidJourney, Grok, NotebookLM, a lot of OpenAI API based automatisations of Google Docs / Spreadsheets, Photopea, Gimp, Paint (I have no idea why Ivan still using it), Sonic Pi, Strudel, Formats Factory.
Spine, Photoshop, Illustrator, DaVinci Resolve, Premier, After Effects, PureRef, RoughAnimator, Blender (with crazy amount of custom code added for automating rendering 3D to 2D in zillions of poses).
Favourite fonts for code
JetBrains Mono, Consolas, Droid Sans Mono
Favourites IDE themes
Visual Studio 2019 Dark, Dark Modern, One Dark, Monokai Press enter or click to view image in full size Thanks for reading (v3) (finally)! Llm Cursor Programming Game Development Generative Ai Tools