Threading at start.

Hello,
I have developed a game where a 3x3x3 set of rooms develop and the player is in the center of the 3x3x3 grid, but notice it takes very long to wait for the 3x3x3 rooms to set up before the game starts. I was wondering if there is a way that the game will play WHILE the objects instantiate and create the 3x3x3 grid of rooms. Thank you.

 

You can load scenes asynchronously, but it sounds as though you're generating them procedurally - is that correct?

In that case, you can

a) put the generation process in a coroutine and have it 'yield return null' in its inner loops to break the process down, or:

b) figure out why it's taking so long and fix that.

 

Yeah before you even think of threading, first get the profiler going and turn on Deep Profile. Run it for a moment then stop play mode. Go into the Profiler, choose a large segment that is taking so long and dive into the details of which functions is taking the most time. That's how I solved a lot of my bottlenecks.

 

3³ are only 27 rooms. How do you actually create them? You said you instantiate them? are they prefabs? If that's the case, no, you can not instantiate things on a background thread. You may want to break down a room into several prefabs which you can load individually spread over multiple frames. However how practical that is depends on your setup.

 

I have 4 objects, a floor, a wall, a ceiling and a room (which is a blank object). I instantiated each room. For each room, I instantiated 4 walls, a floor and a ceiling and made them child objects of each room. Then, I assigned a 'seed' for each wall, floor and ceiling (based on the value of the current room and the reighboring room that is past the wall, floor or ceiling, that is beyond that wall, floor or ceiling), so each wall, floor and ceiling has its unique seed value. The seed value determines where the doors and staircases go (in randomized spots)... so each room has doors and staircases in unique spots (leading to the next room). It would be nice if I could somehow 'thread' that process per room instead of waiting for all 27 rooms to process before the game starts.

 

If you're waiting any human-detectable amount of time for that to happen, then something about the way you are doing it is pathological, ie, involving millions of failed iterations, repeatedly loading an asset rather than retaining a reference - something.

For perspective, I'm writing a procedural dungeon game with up to 30x30 rooms in a level, with randomised elements on every wall, floor and ceiling, plus a pass to simulate the trickling of water and the growing of moss, and all that takes a fraction of a second. You should not be having to wait for 27 boxes.

Try logging out Time.realTimeSinceStartup after each room is completed, to make sure you're actually waiting for what you think you're waiting for.

 

The 'wall and floor seed values' determine where the doors and staircases go for the next room. They are placed in randomized spots (with the random seeds based on the wall and floor's seed value which is a local variable in the scripts). That causes all 27 rooms to have doors and staircases leading to the neighboring rooms. When I walk into the next room, the rooms at the end of the 3x3x3 grid get updated, the rooms at the beginning of the grid get moved over to the end rooms on the 'grid' (making it 'appear' to be an endless ongoing set of rooms with doors and staircases as you move from room to room). Therefore, every time the player goes to another room, only 9 of the 27 rooms get updated. THAT process takes only milliseconds, but when I start the program, I notice it takes almost 9 seconds to create the 27 rooms.

 

...If it only takes milliseconds to generate nine rooms, why on earth would you think it's taking nine seconds to generate twenty-seven? The most you can possibly save by threading the process will be milliseconds.

Something else during startup is taking that time. Try logging out Time.realtimeSinceStartup at various points in your setup and you'll find out what.

 

There is no Time.realTimeSinceStartup function.

 

I capitalized the T.

 

Sorry; my mistake. Have corrected it in my post. What were your results?

 

I reduced the size of the rooms and the spacing between randomizing the doors on each wall, and that increased the speed of the starting of the game. What I did, was instantiated the walls (to fit around each door, through a function called 'doCutouts()'). The function makes copies of the wall, fits them and positions them around the doors, destroys the original copy and makes each instantiated object a child of the transform. I found that is what cost time, but narrowing the rooms (for lesser doors) sped up the starting time.

 

Hmm. I still don't see how nine rooms can take milliseconds and three times as many 9 whole seconds. Super curious to know why that would happen.

Let me know if you want to share some of the project; this is really interesting