Home
  • Manual
  • Node Index
  • API
  • Changelog
Show / Hide Table of Contents
  • Tutorials
    • Creating your first map generator
      • 1. Creating your first map graph
      • 2. Running a graph at runtime
      • 3. Adding more nodes
      • 4. Object placement
    • Basic map types
      • • Cave-like maps
      • • Room-based maps
      • • Sample-based maps
      • • Combining map types
    • More Tutorials
      • • Using prefabs instead of tilemaps
      • • Changing tile/prefab/tilemap set probabilities (weighted random)
      • • Linking a named color set to tilesets/prefab sets
      • • Organizing nodes into groups
      • • Adding notes & comments
      • • Running a graph within a graph (Sub graphs)
      • • Tilemap Sets
      • • Optimization tips
      • • Static seed (daily challenges)
      • • Running a graph asynchronously/multi-threaded
      • • Object pooling
      • • Tips for rule tiles
      • • Saving and loading maps
    • Tutorials for coders
      • • Running graphs from scripts
      • • Output parameters
      • • Creating your own nodes
      • • Creating your own node views
      • • Adding a constant node type
  • Sample Project
  • Troubleshooting
  • Support

Optimization tips

As your map generators get larger and more complex, they are going to take longer to run, which might freeze up your game or the Unity editor or simply have your player waiting too long, while a map is being generated.

One thing you can do is run your graphs asynchronously or multi-threaded. Though this can be very useful, as it will keep Map Graph from hogging the main thread (and locking up your game or the Unity Editor) until it completes running a graph, it won't generate your map any faster.

A better way to handle performance issues is to diagnose the bottlenecks in your graph by enabling the Debug Info in the graph editor:

  1. Open your graph in the editor.
  2. Press the ⋮ icon in the right-hand corner.
  3. Toggle Debug Info.

You'll notice that most nodes (the ones that do work), now have a footer that contains some text. This text tells you how long that particular node took to complete its work the last time it was run. (If it reads -1 ms that just means the graph hasn't been run yet.)

This should help you diagnose which parts of the graph are taking the most time to complete, so that you can try to remedy that. For example, if a Cellular Automata Smoothing node takes a long time, it might be helpful to reduce the number of passes. Or in other cases, you might be able to achieve a similar result by using a different set of (faster) nodes.

This is also very useful when optimizing any of your own custom nodes.

In This Article
Back to top Generated by DocFX