I'm trying my hand at creating a turn-based 4x game in Unity, with a galaxy map and 2D hexagon grid maps for each individual planet. The planet grid hexes would be gameobjects, with the overall grid being around 30x40 in size. The number of planets would be under 50.

What would be the best way to set this up? I'm looking for a solid approach regarding performance here, but one that also caters to easier design/programming would be a plus.

Some approaches I've come up with:

  1. Load all of the grids for the individual planets at the start into a single scene, with each being under a "planet gameobject", and then set those gameobjects to inactive. The galaxy map would be its own scene that is loaded additively when needed; clicking on a planet to view it would set its associated gameobject to active and then unload the galaxy map scene.
  2. Instantiate the gameobjects for planets as they're called up; the grid data for the planet is dynamically loaded as part of this. The planet gameobject is destroyed when no longer needed. Galaxy map would function the same as approach 1.
  3. Individual scenes for each planet, loaded/unloaded additively when needed. A separate, single scene would be used for loading procedurally generated planets.
    1. Seems to have serious challenges for managing units/resources across planets/scenes.

Approach 1 seems to be the most straightforward, as the core of the game would be managed in a single scene, but I am concerned about performance. I'm setting up some test projects to stress test the approaches, but it'd be great to get feedback from someone with more experience.

Any help is appreciated!


closed as too broad by Philipp, Tyyppi_77, DMGregory, Vaillancourt, doppelgreener Nov 3 '17 at 14:43

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ There is never a "best" way in software engineering. Only the way which works best for you and your game. \$\endgroup\$ – Philipp Oct 29 '17 at 12:30
  • 1
    \$\begingroup\$ The approaches you mention are a trade-off between memory and computation time. The one extreme (approach 1) loads everything into memory and activates its execution when needed. This approach uses the most memory, but does not consume computation time through loading and unloading. The other extreme (approach 3) loads as little as possible into memory, but does require computation time for resource loading and unloading. The "best" approach can only be found through experimentation. I would set up memory and performance monitoring through your IDE and tweak the system until you are satisfied. \$\endgroup\$ – Jelle van Campen Oct 29 '17 at 13:51
  • 1
    \$\begingroup\$ For the numbers of objects you're describing, you probably won't hit major problems for any of these approaches, especially if you're targeting the desktop. The only way to know for sure though is to profile it. Build a quick mockup to stress-test it for the amount of instances you expect. If your profiling doesn't show a problem, then proceed in the way that you find clearest/most pleasant to work with until a problem manifests. \$\endgroup\$ – DMGregory Oct 29 '17 at 16:32
  • \$\begingroup\$ Thanks for the feedback. I'm glad it doesn't sound like I'm too far off the mark with my approaches? I was concerned that they would be considered "bad", and that there was perhaps already a generally accepted way to do something like this. I'm going to stress test 1 and 2 to see which approach works better for my case. \$\endgroup\$ – Alex Oct 30 '17 at 1:37
  • \$\begingroup\$ @Philipp That's definitely true, but I'd hate to slog down one path to get something working for my game, only to completely miss a much better way due to my lack of experience! \$\endgroup\$ – Alex Oct 30 '17 at 7:43

What are your minimum requirements?

Approach one could require a lot of memory if each planet has to keep its variables in stored there, but would have almost no loading times.
The other two approaches could slow down your game while instantiating or loading the scene for the planet, but would only hold one planet in memory at a time.

In the end it's trade-off between memory and harddrive speed, and the only way to know what works for your game is to test it for yourself.

  • \$\begingroup\$ I'd like to have roughly 50 planets as a maximum, with each planet having its own grid of approximately 30x40 hexes. I'll do some testing--was just hoping to get some insight from someone with more experience before I start. \$\endgroup\$ – Alex Oct 30 '17 at 7:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.