Skip to main content
added 150 characters in body
Source Link
ratchet freak
  • 8.1k
  • 20
  • 16

Hiding inactive game objects off-screen and out of bounds (where collision won't be a factor) and then teleporting them in place on certain triggers is actually a very common technique.

It vastly simplifies lifetime management of those object. It keeps pointers/references alive so you are less likely to crash by using a pointer to a freed object.

It front-loads the time spent allocating the object to the loading time of the level itself. With a specialized allocator you can even allocate all the memory a level needs in one go and then partition it out to the object in the level. "Allocate" here can also mean reuse the chunk of memory the previous level used. How the memory gets partitioned can be precalculated so the level load itself focus just on getting all the assets in place.

And because you are not allocating/freeing in the middle of a level, crashes due to out of memory are less likely in the middle of play and instead only happen as you load the next level (after your autosave makes sure that the player can resume at that point after you patch the mem leak that caused it).

If you have a level that gets revisited but needs different (heavy) prefabs then you could make 2 variants of the level. One for each stageset of prefabs you need for it.

Hiding inactive game objects off-screen and out of bounds (where collision won't be a factor) and then teleporting them in place on certain triggers is actually a very common technique.

It vastly simplifies lifetime management of those object. It keeps pointers/references alive so you are less likely to crash by using a pointer to a freed object.

It front-loads the time spent allocating the object to the loading time of the level itself. With a specialized allocator you can even allocate all the memory a level needs in one go and then partition it out to the object in the level. "Allocate" here can also mean reuse the chunk of memory the previous level used.

And because you are not allocating/freeing in the middle of a level crashes due to out of memory are less likely in the middle of play and instead only happen as you load the next level (after your autosave makes sure that the player can resume at that point after you patch the mem leak that caused it).

If you have a level that gets revisited but needs different (heavy) prefabs then you could make 2 variants of the level. One for each stage.

Hiding inactive game objects off-screen and out of bounds (where collision won't be a factor) and then teleporting them in place on certain triggers is actually a very common technique.

It vastly simplifies lifetime management of those object. It keeps pointers/references alive so you are less likely to crash by using a pointer to a freed object.

It front-loads the time spent allocating the object to the loading time of the level itself. With a specialized allocator you can even allocate all the memory a level needs in one go and then partition it out to the object in the level. "Allocate" here can also mean reuse the chunk of memory the previous level used. How the memory gets partitioned can be precalculated so the level load itself focus just on getting all the assets in place.

And because you are not allocating/freeing in the middle of a level, crashes due to out of memory are less likely in the middle of play and instead only happen as you load the next level (after your autosave makes sure that the player can resume at that point after you patch the mem leak that caused it).

If you have a level that gets revisited but needs different (heavy) prefabs then you could make 2 variants of the level. One for each set of prefabs you need for it.

Source Link
ratchet freak
  • 8.1k
  • 20
  • 16

Hiding inactive game objects off-screen and out of bounds (where collision won't be a factor) and then teleporting them in place on certain triggers is actually a very common technique.

It vastly simplifies lifetime management of those object. It keeps pointers/references alive so you are less likely to crash by using a pointer to a freed object.

It front-loads the time spent allocating the object to the loading time of the level itself. With a specialized allocator you can even allocate all the memory a level needs in one go and then partition it out to the object in the level. "Allocate" here can also mean reuse the chunk of memory the previous level used.

And because you are not allocating/freeing in the middle of a level crashes due to out of memory are less likely in the middle of play and instead only happen as you load the next level (after your autosave makes sure that the player can resume at that point after you patch the mem leak that caused it).

If you have a level that gets revisited but needs different (heavy) prefabs then you could make 2 variants of the level. One for each stage.