1
\$\begingroup\$

I have a dungeon generating algorithm, but I would like to generate X levels, which are all connected somehow.

I have a few approaches, but all of them has problems and questions, and I wonder how i.e. Diablo II handles them so seamlessly.

1. Approach: Upon leaving a level, generate the next one on the fly.

  • This would be the easiest, but would result in a relatively long loading screen everytime the player enters a new level.

  • So generating the levels should be at the beginning of a new game, thus the next level will just have to be loaded, which is much faster. In theory not even a loading screen is necessary.

2. Approach: Generate every level at the beginning of a new game and store them.

  • Okay, now levels just have to be loaded, which could be done under half a second. No loading screen is necessary, maybe just a fade out-fade in.
  • How do I store them?
    • Make custom files (i.e. scriptable objects) for them, or is there a simpler way?

3. Approach: Generate and load every level at the beginning.

  • Zero loading time, because everything is already generated and loaded into the tilemap.

  • But how do I guarantee that levels don't collide, and the player can't see level Y from level X if there are lots of levels?

  • And wouldn't it affect the performance? Because everything is loaded all the time. Yes, renderers, rigidbodies, scripts, etc can be turned off, improving the performance a lot... but still... this seems wrong.

What is the best way to solve this problem?

\$\endgroup\$
6
  • \$\begingroup\$ What algorithm are you using to generate your levels? Most algorithms I experimented with were surprisingly fast. Generating a level on the fly was usually not a problem. How long does your algorithm even need to generate a new level? Have you benchmarked it? \$\endgroup\$
    – Philipp
    Commented Oct 12, 2019 at 8:09
  • \$\begingroup\$ I use my own one and an average map takes 2.5 seconds. But it hasn't been optimized yet. \$\endgroup\$
    – Tudvari
    Commented Oct 12, 2019 at 8:18
  • 1
    \$\begingroup\$ Every single one of these solutions could work just fine, as well as 4. Approach: generate the connected level(s) on another thread while the player is playing this one, then instantiate one when they reach the exit. Which one you choose is up to you. If you have implementation questions about making your preferred option work well, you should edit your question to ask about that one topic instead - eg. if you want to ask about saving levels, you'll need to show use what kind of data you're saving. Be sure you've read other Q&A on those topics so you're up to speed. \$\endgroup\$
    – DMGregory ♦
    Commented Oct 12, 2019 at 10:45
  • \$\begingroup\$ Well not really about the implementation, just need a solution. Is there a way to slow down, lower priority of that other thread? I'm afraid that if it would run at maximum efficiency, the main thraid would suffer. \$\endgroup\$
    – Tudvari
    Commented Oct 12, 2019 at 14:31
  • 2
    \$\begingroup\$ Very often, the only way to know if the performance is going suffer is to measure it. I've seen numerous instances of brute force solutions in game dev that are theoretically terrible, but in practice work more than well enough. \$\endgroup\$
    – Pikalek
    Commented Oct 12, 2019 at 15:30

1 Answer 1

Reset to default
1
\$\begingroup\$

From generative code, if you have less than 100 levels, you can save the levels as unity assets / prefabs and load them instantly using a bit of scene management, level code and choose the 100 best that you prefer.

If you have an animation of a level transition, which rewards the player, it can give you a few moments for him to chill out while you do the generative maths.

Whatever time you have to run the generator, using yield wait can skip frames every i%10 loops or yield when deltatime > 1/30fps.

Generally, unless you have lots of processor overhead, it's best to generate when you plan the game, else during animations, else to give the player some tasks like lockpicking while the next level loads.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .