Evolutionary Wave Function Collapse
This paper proposes an evolutionary search framework that optimizes the small input examples used by Wave Function Collapse (WFC) to generate higher-quality procedural content, demonstrating that this approach effectively improves generation in domains where global properties emerge from local constraints, such as maze connectivity and dungeon layouts.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you are trying to teach a robot to draw a map for a video game. You have two different ways to do this, and this paper is about trying to mix them together to get the best of both worlds.
The Two Approaches
1. The "Copycat" Robot (Wave Function Collapse)
Think of the first method, called Wave Function Collapse (WFC), as a very talented but slightly myopic copycat.
- How it works: You show the robot a tiny, 4x4 square of a picture (like a tiny patch of a dungeon or a maze). The robot looks at how the tiles in that tiny patch touch each other (e.g., "a wall usually sits next to a floor").
- The Result: It uses those tiny local rules to build a huge, complex map.
- The Problem: The robot is "short-sighted." It knows that a wall touches a floor, but it doesn't understand the big picture. It doesn't know that the map needs to be one big connected loop, or that there must be exactly one key and one door. It just follows the local rules, which sometimes leads to messy or broken maps.
2. The "Trial-and-Error" Artist (Evolutionary Search)
The second method is like a sculptor who creates thousands of statues, throws away the ugly ones, and keeps the good ones to make slightly better versions.
- How it works: You generate many random maps, check which ones are fun to play, and then "breed" the best ones to create new generations.
- The Problem: This takes a long time. You have to build the whole huge map, test it, and then start over. It's computationally expensive and slow.
The Big Idea: The "Genotype" and the "Phenotype"
The authors of this paper asked: What if we let the "Trial-and-Error" artist design the tiny 4x4 patch, and let the "Copycat" robot build the big map?
They treated the tiny 4x4 patch as the Genotype (the DNA or the blueprint) and the huge map the robot builds as the Phenotype (the actual living creature or the final product).
Instead of evolving the whole huge map (which is slow), they evolved the tiny 4x4 patch. The "Copycat" robot (WFC) acted as the machine that turned that tiny DNA into a full-sized level.
The Experiment: Two Different Games
They tested this idea in two different video game worlds to see if it worked:
1. The Maze World (The "Local" Success)
- The Goal: Create a maze where you can walk from start to finish without getting stuck.
- The Result: It worked great!
- The Analogy: Imagine you are teaching a robot to build a brick wall. If you tell the robot "every brick must sit on two bricks below it," the wall will naturally be strong and connected. The "Maze" goal (connectivity) is a local rule. If the tiny patch has good local connections, the big map will naturally be a connected maze. The evolutionary search quickly found the perfect tiny patch that made the robot build great mazes.
2. The Zelda World (The "Global" Struggle)
- The Goal: Create a dungeon with exactly one player, one key, one door, and some enemies, where the player can actually reach the key and door.
- The Result: It was much harder.
- The Analogy: Imagine you are telling the robot to build a house, but you only give it rules about how bricks touch each other. The robot might build a beautiful house, but it might accidentally build two front doors or forget to put a roof on. The "Zelda" goal requires global rules (e.g., "There must be exactly one key in the whole building"). The tiny 4x4 patch doesn't "know" about the whole building. Even though the evolutionary search made the maps look more organized, the robot still struggled to get the exact count of keys and doors right because it was only looking at the local neighborhood, not the whole house.
What They Found
- When it works: If the thing you want (like a connected path) comes naturally from how small pieces fit together, this hybrid method is fantastic. It finds the perfect "blueprint" quickly.
- When it struggles: If the thing you want requires counting things across the whole map or ensuring specific items exist in specific places (global constraints), the method hits a wall. The "Copycat" robot just doesn't have the brainpower to understand the big picture, no matter how good the tiny blueprint is.
The Conclusion
The paper concludes that you can use evolution to teach a "short-sighted" robot to build better maps, but only if the rules of the game are local. If the game needs strict, big-picture rules (like "exactly one key"), this method alone isn't enough. The robot needs a way to look at the whole map, not just the tiny patch it's currently copying.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.