Looking for a specific blueprint generator

Heya, hoping one of you can help me find something specific, I'm having no luck on my searches.

Basically, I'm looking for a (preferably random) generator that specializes in contemporary apartment complex blueprints. It doesn't need to be an actual map maker (I've tried a number of realty/architectural sites with dubious results) but something like a roll up list that determines the size of a room with primary furnishings (bed, stove, light sources) and their locations within it. I've dabbled with randomized gaming map makers, but I'm looking for something more modern in nature for my TTRPG experiment. I've tried developing my own roll for results generator, but it's been tedious work at best. Does anyone have eyes on something like that?

https://redd.it/1uhoi2q
@proceduralgeneration

Needed a world for some simulation testing - procedural generation to the rescue.

https://preview.redd.it/t45n8xpirz9h1.png?width=907&format=png&auto=webp&s=e462e273b0c197cbdfb6f8f76c3affdddd76f3fc

Reddit Earth...

Needed some weather...

What started as a quick little interest project to provide a set of believable simulation data got a little out of hand and bits and pieces just kept on adding on :grin:

https://redd.it/1uhsxyh
@proceduralgeneration

resources for terrain creation

After learning all the OpenGL basics, where would one go to learn about terrain generation from the basics. I'm talking about like heightmaps, noise, chunking, optimizations, etc). How much OpenGL should I know before diving into this?

https://redd.it/1uhx1pt
@proceduralgeneration

Custom Procedural Terrain and Prop Generation System

https://redd.it/1uhydlt
@proceduralgeneration

An agent-based transport network simulation
https://redd.it/1uhzz8t
@proceduralgeneration

Spirals: a free, open source, cross platform generative VJ app
/r/generative/comments/1ui3nk4/spirals_a_free_open_source_cross_platform/

https://redd.it/1ui3woe
@proceduralgeneration

Generating Levels for SAKOBAN a PSPACE complete puzzle using a single level

I've been working on a small research project recently and would love to get some feedback from people interested in procedural content generation, diffusion models, or Sokoban.

The goal was simple:

Can a diffusion model generate diverse and solvable Sokoban levels when given only a single handcrafted level as input?

Since Sokoban is a PSPACE-complete puzzle, generating levels that are both playable and diverse is a challenging problem.

# Initial Pipeline

I started with a single handcrafted 10×10 Sokoban level and built the following pipeline:

Single Level → Random Mutations (walls, boxes, goals) → Structural Validity Check → BFS Solver → Label as Solvable / Unsolvable → CNN Classifier → DDPM → Classifier-Guided Sampling → Evaluation

The structural validity check removes obviously broken layouts (multiple players, mismatched numbers of boxes and goals, etc.), while the BFS solver determines whether a structurally valid level is actually solvable.

# First Attempt

Initially, every generated level was produced by mutating only the original seed level.

Although this produced many levels, they were extremely similar to one another and often shared nearly identical solutions. The resulting dataset lacked diversity, making it less useful for training the classifier.

# What I Changed

Instead of always mutating the original level, I switched to an iterative mutation strategy.

New levels could be generated by mutating either:

the original seed level, or
a previously generated valid level.

This allowed the archive to gradually expand instead of remaining close to the original layout.

After 500 iterations, the archive statistics were:

Valid levels: 500
Invalid levels: 0
Duplicate layouts skipped: 8
Archive size: 492
Unique solvable layouts: 187
Unique unsolvable layouts: 305
Unique solution signatures: 140
Balanced solvable saved: 187
Balanced unsolvable saved: 187
Duplicate rate: 1.60%

This generated archive was then used to train a CNN classifier whose task was simply to predict whether a Sokoban level was solvable.

# Diffusion Model

I first trained a DDPM using only the original handcrafted level.

As expected, it generated highly playable levels, but they were extremely repetitive.

To improve diversity, I trained another DDPM using the automatically generated archive instead.

I also compared training:

only on solvable layouts
on all structurally valid layouts (including unsolvable ones)

Interestingly, training on all structurally valid layouts produced noticeably better structural diversity.

# Classifier Guidance

After training, the CNN classifier was reused during diffusion sampling as a guidance model.

The DDPM learned how Sokoban layouts are distributed, while the classifier estimated how likely a generated level was to be solvable.

During sampling, the classifier nudged the diffusion process toward layouts predicted to be solvable. In other words, instead of changing how the DDPM was trained, I used the classifier only during generation to bias sampling toward playable levels.

# Best Result (5,000 Generated Levels)

|Metric|Result|
|:-|:-|
|Structurally Valid Levels|2,583 / 5,000 (51.66%)|
|Solvable Levels (BFS Verified)|2,407 / 5,000 (48.14%)|
|Unique Layouts|4,973 / 5,000 (99.46%)|
|Duplicate Layouts|27 / 5,000 (0.54%)|
|Average Pairwise Normalized Hamming Distance|0.1424|

# Metric Definitions

Solvability: A level is counted as solvable only if the BFS solver successfully reaches the goal state.

Invalid Level: Multiple players, mismatched numbers of boxes and goals, or other structurally invalid layouts.

Uniqueness: Measured using exact ASCII layouts. Each generated 10×10 grid is serialized into a canonical string representation, and only exact matches are counted as duplicates.

Diversity: Measured using the average pairwise normalized Hamming distance between generated layouts.

I'm still

nowhere near "solving" this problem, and there are plenty of things I'd like to improve. However, it was interesting to see how much a classifier can steer a diffusion model toward solvable content without modifying the DDPM training objective itself.

I'd really appreciate feedback from anyone working on procedural content generation, Sokoban, or diffusion models.

In particular, I'd love suggestions on improving the percentage of valid and solvable generations while maintaining the level of diversity.

https://redd.it/1uies0u
@proceduralgeneration

Volumetric Terrain Erosion - Blog Post
https://redd.it/1uirxr4
@proceduralgeneration

Procedural Stone & Timber

https://redd.it/1uitmh6
@proceduralgeneration

Finished my quest generator.

https://preview.redd.it/mpiyr42hn8ah1.png?width=1516&format=png&auto=webp&s=a3143f066dc7440123b688b812f83e398c3d181d

TL;DR Jump to the bottom to see some examples of the generated quests

So the reason I wrote this system was because I really like RPGs and questing, however most procedural quests are filler and pretty shit. Go somewhere, fetch a thing, come back. It's very easy to detect the pattern, and nothing genuinely interesting happens. It also feels like the quests are meaningless in and of themselves because they have no real interaction with the larger world.  


So the system that I've written is for generating procedural quests that don't feel like filler. It uses graph grammars, it grounds every quest in the live world state . It's not a particularly new solution, but it clearly is underrated in so far as I don't really see people adopting it that much. I really wanted to show how flexible the system is and that it could generally produce good outputs.


It does not replace handmade quests. A designer with a specific idea and an expert touch wins on novelty and memorability, partly because a quest worth doing justifies reorienting the game around it. This system raises the floor instead. It targets the radiant, "always something to do" layer, keep it alive instead of mechanical, raise interactivity, extend the life of the game, without hand-authoring thousands of one-off tasks.


Authorial vs. simulationist


So to start with, we need to pick this first.


Authorial: the generator changes the world to fit the quest. Needs a bandit warlord menacing a village? Create one. Quest first, world bends to it. This is how most narrative-first generators work.


Simulationist: the generator cannot invent facts. Every quest grounds in things already true, real entities, real relationships, real character needs. If a giver wants a foe slain, that foe exists and is already menacing that giver. World first, quest discovered inside it.


Well, Thoriel is actually a lot easier to do because you don't really need to read the world state as much. Just need to know what new enemies, etc., you need to create. The trade-off here is it's going to feel disconnected from your main world, and that's because it is. Hence why the rest of this article is going to be about simulationist as it's the harder problem, but it's more interesting.


Shape of a quest


Every quest shares a skeleton, an exposition phase that sets the situation and stakes, a body where the work happens, a reward at the end. This forms the general core spine of a quest.


Generation starts by picking an archetype, slay, escort, defense, and so on.


So far I've identified about 14 different archetypes, although I expect there are a lot more.


1. Compete
2. Defend
3. Escape
4. Escort
5. Exploration
6. Fetch
7. Heist
8. Hunt (Potentially similar to fetch quests, although there is more nuance with a hunt because it could be a fleeing beast, runaway etc. )
9. Investigation
10. Negotiation
11. Provision (which is actually similar to a Fetch Quest except it normally requires additional steps to refine or craft something. )
12. Rescue
13. Slay
14. Survive


Each archetype is an abstract layout, nodes and relationships at high abstraction. Nothing concrete yet. A slay quest is just "a foe exists, the foe must die, killing it resolves a threat." A template expressed as a graph, attached to nothing real.



Reification


So the next step is to make the pieces concrete. Take the abstract template, bind it layer by layer to specific concrete entities and facts in the current world state. Multiple passes. Each pass matches against what is true right now.


Slay quest. Abstract version, something must die. To reify, find a foe currently menacing the giver. That is a constraint against the world graph, an entity with a "menaces" edge to the giver, or to something the giver cares about. No such entity, no

quest from this archetype here. The generator moves on. That is the simulationist discipline.


Start from the most abstract interaction (kill the foe), then add slots for complications and nuance. A slot is an open position asking to be filled, "what stands between the player and the foe?", "why hasn't the giver handled this already?", "what does the kill cost or risk?". Slots expand recursively. Filling one can spawn more, and each resolves by reading adjacent relations in the world graph. A complication slot might pull in that the foe holes up in a fort held by a faction the player is allied with, which opens a slot about loyalty or disguise. The structure grows outward from the seed and stays anchored to real relationships.


Example- the slay quest


The generator picks SLAY. Abstract form: *[giver\] wants [foe\] dead because [foe\] threatens [giver's interest\]*.


Reify against the world. The graph holds a village elder (candidate giver) with a "fears" edge to a frost troll, and the troll has a "raids" edge to the village granary. Those facts already exist. The generator invented none of them. Elder becomes giver, troll becomes foe, granary becomes stake.


Add slots. A complication slot reads the troll's adjacent edges, it "dens in" a cave that "is controlled by" a poacher gang. Real obstacle, so it becomes a complication. You cannot walk up to the troll. A second slot asks how the player gets past the gang. Because games reward agency, it emits multiple resolutions, fight through, bribe, or pass a persuasion check by arguing the troll is bad for the gang's business too.


Reward draws from what the giver can plausibly offer, the elder's edges point to stored grain and a small standing boost with the village. Output reads as authored ("the elder fears the troll raiding the granary, but its den is held by poachers you'll deal with first") and was assembled entirely from facts that were already true.


Why this is a game generator, not a story generator


This is where most of the design effort goes.


Player agency. A story is one chain of events. A quest gives choice. For every obstacle, emit multiple ways through, a combat route, a dialogue route, a skill check. The obstacle is fixed, but there are multiple routes past it.


Optional branching. Past the multiple solutions to one obstacle, support optional branches, a player who wants more diverts into a harder sub-quest hanging off the main line instead of being locked to one path.


Multiple terminals. Do not ship one rigid chain with one ending. Place candidate terminals at several points, so an earlier decision can resolve the quest sooner. A short completion is valid, but gate it behind harder interactions, so the short road costs difficulty. That keeps the choice real. An example I made is when handling a negotiation quest, should the player manage to get through a legendary skill gate and placate both sides, the quest just ends immediately without any additional complications.


Cheap branching buys breadth. If generation is cheap, spend branches freely. Hand the player many options and route them into genuinely different content based on what they pick. Cheap generation turns branching from what would normally be expensive handwritten content, To feel like there is genuine impact and different decisions that a player can make.


Dynamic gating. Condition branches on world or character state and emergent behavior follows. Gate a branch behind a requirement evaluated at the moment the player reaches it. Fail the check, stay on the mainline, nothing breaks. Pass it, get a point of divergence into unlocked content. That is a living gate, not a static one.


Partial generation. You do not need to generate the whole quest up front. Lay out the spine, then generate complications when the player arrives at them. This pairs with dynamic gating, world state at arrival decides what gets built.


Rare events


Good quest design budgets for rare,

high-interest occasions. Not every quest should be reachable every time. Hold some archetypes, complications, and rewards behind low trigger rates so they surface occasionally and land hard when they do.


This matters most for long-term players. After enough quests, a player starts to feel the pattern underneath the generation. Rare events break that read. They keep things surprising and hide the undercurrent of how the system actually works, so the world stays interesting well past the point where a player has seen most of the common content.


The hard parts, and where they actually are


The difficulty is not where people expect.


The graph grammar is not the problem. It works. Rewriting abstract nodes into concrete subgraphs is solved.


The corpus is the problem. The system is only as good as the library of interactions, rules, and patterns it can fire to fill slots. You need a large, rich corpus, and it is specific to your game. Quest interactions bind to a game's mechanics, so there is no universal corpus to drop in. You cannot lift one from D&D, no one-to-one overlap, D&D is richer in many mechanics than most games, and it leans on live player-DM interaction to flesh out generic content. A generator cannot assume that improvisation exists. Partial mitigation, write generic modules with explicit, parameterized requirements so some rules survive across contexts instead of being authored fresh each time.


Reifying the story is its own problem. Graph grammars create nodes and relationships. A created graph is not a playable quest. You need a graph-walking system that traverses the output and makes the game produce side effects, spawn entities, set flags, generate exposition, evaluate the story, then handle presentation and implementation. The walk turns structure into something a player experiences, and most of the quality lives there.


Quality is execution as much as structure. "Go there and slay a beast" reads boring but if the fight is memorable, hard, and demands planning, it plays well. The graph has structure but presentation and moment-to-moment mechanics decide whether it is worth doing.


Speaking of that, you likely will need to generate expository dialogue in between. This is something where pattern recognition can very easily crop up. It might be a genuinely good reason to use LLMs, either dynamically in the game just to help with that and to get a high temperature, or to generate a large enough corpus ahead of time to setup enough of the dialogue necessary .


When generation fails


A simulationist generator can fail. Every slot must match something real, so sometimes nothing fits, a complication slot finds no obstacle, or an archetype will not reify against the available state. You need a deliberate answer instead of shipping a broken quest. Three approaches, and they combine.


Tune to avoid failure. Tune the rules and their trigger conditions to push the failure rate near zero. Most demanding option, since it depends on how rules interact, but a tuned system rarely hits a dead end.


Generate in batches and rank. Generate several candidates, keep the valid ones. Failure gets cheap when one bad candidate among many does not matter. Then rank the batch and ship the most exciting result, not the first that works. Robustness and quality from the same mechanism.


Collapse slots. When a slot will not fill, do not throw out the quest. Collapse the slot, drop it, proceed with the simpler structure. The quest is less ornate but still valid and still grounded. One failed match does not cascade into a failed quest.


Modeling and scaling the world graph


Nodes vs. properties. Use nodes for discrete entities, a person, a place, an object. Use properties for continuous or scalar data on them, like an NPC strength score. This keeps the graph clean and matching fast as the amount of nodes in a graph is one of the big O scaling factors .


Do not match against the whole world. The naive approach, and

the one I started with, generates a massive world graph and matches quest subgraphs against all of it. It works, but it is expensive, and it scales badly. You almost never need the entire world state in the matcher.


Localize and cull. Scope the matchable graph to what a giver would plausibly know, or to entities in an area. Run a phased priority approach, cull state at each step so only the relevant slice survives into the next pass. Scope to relevant, then narrow progressively. That turns one giant global match into a series of cheap local ones.


Since the crest expansion generally follows a step-by-step process, with some of the earlier phases influencing later ones once those earlier phases have been done, if they required specific nodes that are no longer needed later on, both those rules and the nodes themselves can be dropped.


Mods and extensibility


The grammar makes the system easy to extend, for official expansions and for fan mods. Content is nodes, relationships, and rules, not hand-wired quest scripts, so a mod does not author bespoke quests to participate. It exposes a small set of rules describing how the generator may interact with its content.


Low bar, large payoff. A modder drops in new locations, NPCs, and interactions, exposes a few rules, and the generator folds them into the simulationist world. The new NPC becomes a giver, the new location becomes a foe's den, the new interaction fills a complication slot, with the base game knowing nothing about the mod in advance. Every quest grounds in real world state regardless of source, so third-party content runs on the same footing as first-party content and the world stays coherent as it grows. If necessary, you can also just rely on an opt-out system so that a mod's specific important NPC doesn't interact with you outside of their handwritten content.



https://redd.it/1uivja4
@proceduralgeneration

Procedural Barrel Generation in Unity | CosmoNode
https://youtu.be/AD2umc8VqsQ?si=CzG4Rj5lqlHKLEbP

https://redd.it/1uivvjw
@proceduralgeneration

I've Made a Procedural Noise Collection
https://redd.it/1uiy6yp
@proceduralgeneration

Adding Caves to my Micro Voxel Engine (Devlog #3)
https://youtu.be/qFcWtRgE25s?is=bK5nYGVQzjYcotii

https://redd.it/1uizbap
@proceduralgeneration

Galacto

https://redd.it/1uj0tqv
@proceduralgeneration

An agent-based transport network simulation

https://redd.it/1uj2ih7
@proceduralgeneration