Exploring LLM-Driven Level Design #
What? #
I suppose a first explanation of what LLM-Driven Level Design is, is that you could provide a sketch of a level layout, with notes, descriptions of the theming and aesthetic and then let the LLM loose to design the whole level in a single shot. I found that this was a generally poor use of LLMs, as it would frequently bulldoze through load-bearing walls and cause all sorts of issues in both an immersion-breaking way where it's just sloppy and poor quality as the architecture is implausible or ridiculous the game design baked into the level design is just plain absent(as the LLM needs to have a concrete and thorough understanding of the game design to make good levels), and the performance is quite often bad as for some tasks, it will generate a million brushes.
I mentioned brushes there as I built upon the work of TrenchBroom-MCP. This is generally the same style of level design as Half Life 1, Dusk, Quake and other games of this nature. Generally the "Boomer Shooter" genre of game, as well as Retro games tend to target this.
Initial research #
My initial lot of research led me to looking at this paper which talks about LLMs for generating new and unique Sokoban levels. The issue here is that, firstly Sokoban is a well described, defined and formulated game, it is a 2D game, and it is has a single hard constraint(the solvability constraint) that is easily tested. As a result, for a game in development, I found that this research was not particularly useful.
Initial work #
Rather than setting up TrenchBroom-MCP, I firstly set up some MCP tools that do some manual changes to a .map file directly. Stuff like making brushes and reading the file and all that. I found this to be somewhat effective, but I found that after a while it'd start losing its understanding of the map and just bulldoze and make nonsense geometry. This nonsense geometry has a performance cost associated and just plain looks bad, so it was back to the drawing board a bit.
I then learnt about TrenchBroom-MCP, compiled it and ended up extending it slightly to provide vertex tools too. In the end, this on its own was insufficient too, for the same reasons as before with nonsense geometry getting made, but an additional reason too. The amount of output that TrenchBroom produces makes this tool particularly token-heavy.
The next natural step was combining the two tools. The results were somewhat better and more sensible, and it largely did away with the token-usage issues, but still left me with the hard issue of how to handle the nonsense geometry it made.
I had 1 main idea on how to tackle this, and that was to add a rewritable graph grammar as a sort of tool that the LLM could use in order to generate a structure for how the level should look like. This follows the approach laid out in Joris Dorman's game and seminal work: Unexplored, where a graph would be laid out, and rewritten following graph grammar rules and then once a finished graph was made, the resolution was increased with more details until it was an actual playable level. An excellent blog article on the subject of graph rewriting can be found here.
This approach sort of worked. It gave the levels it produced a lot more structure, even if the contents of the levels had no sense of game balance. Unfortunately it still resulted in nonsense geometry.
(and for the record, I also attempted using SKILLS.md files and prompt engineering to also steer it towards avoiding these errors).
This approach resulted in levels that looked like this:
A Cathedral accessed through a staircase that breaks a load-bearing wall.
An underground church in a cave. The cave ended up blowing up the brush budget for the map and has performance issues as a result.
Part of the same map, but an actually cool looking Crypt.
A hilarious misunderstanding of "Place a bunch of Mushrooms around everywhere"
A particularly egregious example of how it cuts through load-bearing walls and makes nonsense geometry.
Ultimately, if you're after frequently nonsense geometry, this approach works.
Compromising on the view #
I stepped back from this problem and thought about the approach to go with which may be more of a compromise. Namely, to go ahead and use LLMs as more of a level design assistant rather than a full on level designer. This approach ended up being far more fruitful, because the issue with LLMs is its inability to understand what is relevant in the level, game balance, game structure and a number of other concerns even those like texture usage.
The main question is how do you define a space that the LLM should actually be working in? This actually turned out to be a fairly trivial problem. I just created a new brush entity, gave it some key-value pairs that the LLM would fetch to understand the context of it, and let it loose. The Brush entities in particular are a single marker entity, and a brush entity that lets you encapsulate a room, as well as a brush entity to define protected areas of a room that should not be edited.
This approach ended up being a lot more successful. I'll let the images below say most of what can be said
A very good first impression of the room it made
The Fireplace, very cute and cool, but note 2 deficiencies. Firstly the logs are piled in a perfect geometric pile which looks unnatural, and the fires are placed perfectly in line with each other. Both would need a human hand to adjust these.
The tables. Note that it got the texture alignment correct for the wood grain, and it also added little gaps in between the planks. The only real issue here is the prop entity which would probably be changed.
A front view of the bar. Note how it even got small details like the footrest for the bar stools and frying pans with as close as it could get textures(which in-game are black rock textures).
Probably the worst thing it did was make these Tudor Timber beams. Firstly they overlap causing Z-Fighting, and secondly, they don't even connect to the posts, so it just looks bad. This would need a human hand to correct or remove.
It still has some texture alignment issues. The top of the bar has this for the texture which looks bad, and the posts has the wood grain going imo, the wrong direction.
Personally I think of this approach as a much more surgical, aimed and precise form of the first tool, where instead of trying to "one shot" a whole level, it instead "one shots" the specific area a level designer targets it at.
What all this does mean, is that a human is ultimately the director of the level and must still design the whole level on a macro level, and ensure the small details the AI adds makes sense in the context of the level. The textures and texture alignment is another thing that needs to be checked too, and then of course the actual gameplay needs to be tested as this is the most important thing overall. It is a videogame after all.
Conclusion and discussion on ethics/morals #
To conclude this, I do want to make it clear I'm uncertain where I stand on the morals and ethics of LLMs for use in Level Design, and I do not want to make a judgement on this just yet. On the one hand, it gives an indie developer a lot more speed in the level design process, and lets the iteration times be shorter. Because of this, it also gives the keys to the kingdom for some sorts of games that are quite simply almost impossible for indie developers to approach meaningfully too. I'm thinking of open world games like Morrowind, Fallout and Skyrim where large quantities of game spaces have to be filled out and populated.
One concern of this sort of approach is one that PCG tool authors have been debating for a long time too. The problem of 10,000 bowls of oatmeal. Games like No mans sky sold on the promise of millions of unique procedurally generated worlds, but when you visited them(at launch at least), the areas were all just another bowl of oatmeal and felt very similar and bland. I wonder if a similar issue applies to these sorts of LLM-assisted levels.
Another concern with this sort of approach is detection and AI usage disclaimers. I personally think it would be extremely trivial in the current state for an LLM to design a level and for it to not be detectable as an LLM-assisted level, and I would not be surprised if there are already games and game developers doing this, but keeping it under wraps as a sort of trade secret(whether or not it's in violation of the Steamworks agreement is up in the air though, an argument can be made it's a workflow efficiency tool and an argument can be made it is straight up generating content).
I also suspect this approach cannot be taken with some kinds of games. Games that about expressing a unique idea in the most elegant and expressive way possible will probably be butchered by an LLM. These would mainly be Puzzle Games, like my own game Mirrormind, or games like The Witness and so on, because they are about expressing an idea as simply as possible within the game, without obscuring or obfuscating it unnecessarily.
There is another point that many of these LLMs are unlikely to have been trained on .map files. Certainly not specialised in them, and especially MOE(mixture of expert models) are unlikely to understand them well. Probably at best, 3D modelling is the closest equivalent. Regarding this training question, and the inability to peer inside the black box to know if it was trained on .map files, would one consider it a plagiarism machine when it comes to level design?
Email your feedback about "Exploring LLM-Driven 3D Level Design"
Published on 2026/11/12
Articles from blogs I follow around the net
The Need for Speed Challenge > a half-assed review -- Need for Speed: Underground 2 (2003)
November 2026 Update After a couple of weeks of sustained play, I finished the game. A few notes and photos at the end of the article. …
via andrei.xyz November 11, 2026Silence: a Sonnet for Remembrance Day
As we approach Remembrance Sunday I am reposting this sonnet about the two minutes silence, which was first published in my book Sounding the Seasons. I’m posting it early so that any one who wishes to, can use it in … Continue reading →
via Malcolm Guite November 7, 2026thecozycat 💻 Slowly building up my Neocities. I'm really liking...
Slowly building up my Neocities. I'm really liking how it looks so far! Very different from Wordpress but, in a good way.
via thecozycat November 4, 2026Generated by openring