What i have now is a level which consists of a room containing about 50~100 prefabs. The room has 4 doors on each side of the room.
Once the player enters a trigger on a door i instantiate a copy of the room with one of 10 inner wall/prop combination. This causes quite a big lag spike, which is a problem.
The idea is for the player to be able to go as far as he wants, and be able to backtrack so I’m not sure if object pooling is the right call. Players are able to break stuff in the room they are in, so if i understand it correctly eventually you’d be getting already wrecked rooms once the pool runs out and starts reusing rooms.
I’ve googled that people use coroutines for similar things and split the instantiation over multiple frames to reduce the lag, I don’t fully understand how coroutines work, so if it is a good idea, how would one go about spawning let’s say an inner wall prefab, and 60 prefabs of some furniture over multiple frames once the player starts a OnTriggerEnter function ?
For the distributed instantiation:
let’s say you have a list of 60 prefabs to spawn in Start(). You can then start a Coroutine (yes, you will need to look into them to do this right but it is not so hard, a good tutorial can be found here:
)
The coroutine will then maybe instantiate the first 10 prefabs and then call a command to pause the execution until the next frame so Unity can then run the normal updates and render a frame on screen. Of course, you will only have 10 prefabs visible at that point. After that, the coroutine will continue its work and you can spawn the next 10 prefabs and pause again until the next frame and so on until all prefabs are spawned.
Regarding the endless rooms:
if you want to be able to go back ALL rooms you have created you can either spawn new ones until the player runs out of memory or you need to destroy older rooms or move them to the new position (like an object pool) and reset them to the neutral state. Of course, for every room you move that way you need to save the information about that room somewhere either in memory or to a save file so when you come back to that room, you move another room there and “decorate” it with the information you read from the file. If players can break stuff, you need to save which object is broken and where and maybe use a “broken” model for the broken state so it will look the same. If you use physics, it might look different.
But maybe that is all not needed and maybe you can rethink the design. I mean if you spawn 100 rooms and the player walks through each of them, do they really REALLY want to go back to all 100 rooms? Maybe there is a reason for that, if so it is perfectly fine, maybe it is like Minecraft where you explore for miles and come back to your base camp.
You could cook your objects. That’s to say you can have an initial number of objects that are likely to reocurr in the next few procedural rooms.
You distribute these objects in your rooms, and instantiate more objects for this list to replace them at a separate and controlled interval. And distribute them as rooms are created.
This way you can hopefully walk into a room and not notice how it was put together. As all the assets for that room were cooked a couple of rooms back. So they were prepped for their random delivery, and replenished 1 by 1 at a controlled interval
Thanks! that video helped me quite a lot since the guy explained everything clearly and thoroughly. I’ve split the instantiation over multiple frames and it works like a charm, no more lag spikes.
