u/custybeam — reddlx

• Split the selected area into Tetris-like shapes / chains.
• Try to assign arrow directions and “pull-out order” afterward to make the level solvable.

The problem was that this approach became extremely slow on larger grids because the generator spent most of its time creating and rejecting huge numbers of invalid layouts. Generation time started growing almost exponentially.

The new approach is much simpler and surprisingly much faster.

Now, before placing each new arrow, the generator immediately checks whether the level is still solvable. If the placement creates an impossible state, it simply tries another arrow instead.

This ended up improving performance massively because:

• the generator focuses only on building one valid level instead of brute-forcing thousands of broken ones,
• deadlocks are avoided much earlier,
• and generation scales far better on large grids.

One fun benchmark fact: the old algorithm generated a 50х50 level roughly 5х slower than the new algorithm generates a 100х100 level.

What surprised me the most is that even very large grids like 100х100 or 150х150 are now generating extremely fast compared to before.

I’ve attached:

• updated code,
• a short video,
• and some tiny benchmark stats for anyone interested.

I still feel there’s a lot of room for optimization, especially for mobile devices. My goal is to make generation fast enough even on phones without noticeable freezes.

And honestly, I’m pretty sure this algorithm still isn’t “perfect.” There are probably much smarter and faster approaches out there, and I’d love to hear more ideas.

Huge thanks again to everyone who gave feedback on the first post - some of your comments genuinely helped me rethink the entire structure of the generator.

Also, I’ve already decided to add several people from the previous discussion into the game credits because they helped a lot with solving these generation problems. Anyone who significantly helps improve this version will absolutely be credited too)

u/custybeam — 3 months ago

▲ 20 r/arrowspuzzle+8 crossposts

Hi everyone,

I’m currently working on a game called Arrow Puzzle Escape. It’s a kind of puzzle/maze game where you solve levels by “pulling out” arrow chains and figuring out how they interact to complete the puzzle.

Right now I’m developing a procedural level generator for the game. The idea is that the generator takes a user-selected area on a grid and fills it with arrow-based structures to create a playable puzzle.

The generator works in two main phases:

It first splits the selected area into “chains of cells”, somewhat similar to Tetris-like shapes.
Then it tries to assign directions to these shapes, effectively turning them into arrows that form a solvable level.

The main issue I’m running into is that the first phase doesn’t currently include any logic to prevent “deadlocks” — situations where arrows end up blocking each other in a way that makes the level impossible to solve.

For small grids (like 10x10 or 30x30), everything works fine. However, for larger grids (40x40, 50x50 and above), the generation time grows exponentially, and the number of invalid layouts increases significantly. At that point, generation becomes practically unusable.

I feel like the issue is not just optimization, but more about the structure of the algorithm itself. I’m looking for ideas on how this approach could be redesigned so it can reliably generate larger solvable levels without exponential retries or deadlock situations.

Also, stepping back a bit — I’m starting to wonder if this kind of approach is even fundamentally scalable in general. Is it actually possible to design a procedural system like this that reliably produces valid 50×50+ solvable levels without falling into exponential failure rates?

I’ve attached a video showing a quick demonstration of how the generator currently works in Unity. If anyone is interested in digging deeper or experimenting with ideas, I can also share the source code of the project.

Any suggestions or feedback would be greatly appreciated. Also, I would be very happy to credit anyone who helps significantly with improving or solving this algorithm inside the game.

u/custybeam — 3 months ago