A Question About Memory Management with Scenes/Nodes

Avencherus

Was thinking about what a large game project would look like with 100s of scenes, that all contain nodes and scenes nested in them. If your project looks something like: GameNode

Scene001

Scene002

..........

Scene280

Does this load and keep everything in memory, or does it allocate based on what is being used? If it's the former, where everything is retained, what is the more appropriate way to organize a really large game with lots and lots of scenes?

Elf_Ears

If you attempted to load every scene at once, it would theoretically keep everything in memory (in reality it would probably crash...)Try using global variables for event tracking and such, those variables are retained from scene to scene (however if you want to save them you'll need to look at the filesystem api)

Avencherus

I see.  Thanks.  G:If you create a large amount of scenes that represent game areas, is it then the goal to create a global scene that acts as some sort of scene manager, loading and unloading them as needed?  Or can they still be somehow segregated in a single scene hierarchy?It sort of feels like each area would be somewhat like building the game multiple times.  I must be rather off the mark.I want to be careful and make sure I organize my projects as the design is intended, but it wasn't completely explained in the documentation, and I'm not advanced enough at this point in my pursuits to parse through the source code for a concrete answer.So I am just a little unclear at the moment about what kind of testing I could do to make sure I'm working in the frame work of their data structures and memory management, rather than blindly working against it.

bitwes

This may help a little.  I think it's a bit dated but it seemed to cover things.  You can use autoload to hold some values from scene to scene and supply some common functionality across your scenes.  The script for each scene should probably inherit from a base class that you have.  The autoloaded script is also where you would keep logic for loading up new scenes. http://www.gamefromscratch.com/post/2015/02/23/Godot-Engine-Tutorial-Part-6-Multiple-Scenes-and-Global-Variables.aspx http://docs.godotengine.org/en/latest/tutorials/step_by_step/singletons_autoload.html?highlight=autoload

Avencherus

Thanks bitwes, I have looked into those. I'm just confused about the timing and memory management of them in the engine itself.  Here is my example of something I'd like to do. I want to implement something like stream loading.  Having a world where you go back and forth from room to room.  It would be nice to have a few rooms (scenes) ahead and behind the player to be kept in memory.  As you advance in one direction, have Godot unload scenes that are further away, and begin loading in the background the scenes that are approaching.  Eliminating most loading screens. It's just not clear to me how to measure or test what Godot might be doing to design this, and I'm not quite at the level of engine architect that I can dissect the source code's memory allocator design.

danjo

In my endless runner I used VisibilityNotifier2D to achieve that. There is also VisibilityNotifier for 3D

Avencherus

It's not obvious to me how to use that to load unrendered scenes into memory, since it's a trigger about what's visible on screen. In the context of a runner game my best guess is you mean that you have some sort of landmark to tell the game to start loading what's up ahead.  I want to a small tree of scenes immediately available in memory, as a player might have more than one path they may choose to take in any given scene, and then possibly decide to immediately turn around.  There isn't any logical way I can think of to perfectly predict a player's choices of direction by seeing what's on screen. If you have an example, I would really appreciate it.

danjo

Avencherus said:

In the context of a runner game my best guess is you mean that you have some sort of landmark to tell the game to start loading what's up ahead.

</blockquote> That's the idea and I think this can be applied to other games, that limit the view distance by the size of the viewport, like top-down, isometric, side-scroller, etc. For the simplicity I take a top-down dungeon crawler as an example. You need one scene, we call it 'word', to instanciate the scenes (we call them 'chunks') your world is made of. Each chunk as one VisibilityNotifier(2D) (abrv. as VN) and a unique name. When the games starts, you load the chunk the player is in, and 1  chunk in all directions the player can possibly go. When the player moves in one direction, he'll eventually reach the point where one VN enters the viewport/camera, and triggers adding 1 more chunk in the direction the player is heading and removing one chunk in the direction the player is coming from.  I suggest you use a coordinatish naming convention. Like Chunk_X-Y where X and Y are integers. The chunk the player is, when the game starts would be Chunk_0-0, Chunks to the right of the player would be Chunk_0+N-0, chunks to the top of the player would be Chunk_0-0-N, etc. If you keep track of the chunk the player is currently in, it's pretty easy to tell where he's going and where he's coming from. Hope that helps, if something's not clear, please ask :)

Avencherus

Ok, I understand, thanks for the example, you've been very generous. I should say that it's not an open world game that I'm working on.  The continuity I'm aiming for is not one of a seamless world, though what you've given is I think the right way to approach it.  Mainly what I'm trying to achieve is lazy loading. If I can be afforded more of your patience, I think I ought to better explain more what I'm working on, and maybe you can give me your thoughts on a method to fit the context more precisely. My game is something more akin to a click and point adventure.  You would enter a room that is mainly a background that is artwork, and inside it resides a character that navigates it.  Interacting with items and such.  Then there will be doors (portals) to load another game scene with the artwork and content.  It is a spontaneous switch, with probably some kind of screen wipe transition. I would like to keep the adjacent scenes cached in memory, so the player can rapidly jump back and forth without incurring a scene load.  I'd also like to unload cached scenes as they become more distantly connected. So just entering a room is indicator enough that some future content needs to begin loading, and I don't think I'd need the VisibilityNotifier, though I'm glad to have learned of it from this thread.  I feel it may come in handy down the road in my learning adventures with Godot. I plan to manage the room or environment layout in data structure, so a rudimentary path finding algorithm will decide what scenes down the way need to begin to be streamed into memory.  With the hope they will lazily be loaded by the time a player could conceivable get there.  The depth of these branches would be a variable I could adjust and test. I'm not really having an issue with triggering the event.  Where my problem lies is how to accomplish this buffered loading in practice.  I'm just unclear about what Godot is actually doing with it's load and preload methods under the hood. Currently I'm looking at:  http://docs.godotengine.org/en/latest/classes/class_resourceinteractiveloader.html Not much about it, but I'm really looking for some way to indicate to Godot to begin allocating resources into memory for an upcoming scene, and unload distant resources.  The part I'm hunting for is the mechanism and usage of the actual load operations.  I would like to try to queue up scenes to load and fallback to a loading transition if it cannot stream fast enough. Well, I hope that is more specific. Thanks again for your time Danjo.

danjo

<blockquote class=" Quote">Well, I hope that is more specific.</blockquote>Yes, it is! :)Sorry, it took some time to answer, I didn't get much pc time :neutral: Anyway, I don't have any experience with your specific situation but what I would try:1. load the current scene (the one the player is in) 2. use ResourceLoader to load all adjacent scenes and remove all scenes the player can't access from the current scene3. When the player goes to one of these scenes, got to step 2 Sorry, but that's the best I can come up with

Avencherus

<a target="_blank" rel="nofollow">danjo</a> said:

1. load the current scene (the one the player is in) 2. use ResourceLoader to load all adjacent scenes and remove all scenes the player can't access from the current scene3. When the player goes to one of these scenes, got to step 2

</blockquote>Thanks, that sounds like what I would I need.  Are you familiar at all with ResourceLoader?  There seems to be only this on it:  http://docs.godotengine.org/en/latest/tutorials/engine/background_loading.html Would references to scenes in an array keep them around?

danjo

I only used it for scene transitions as described in the docs. But I don't think there is much more to it then that. As a side note: If you save your scenes as *.tscn, the first line of the file tells you how many load stages your scene has. (load_steps=X) If this is 1, it makes no difference if you just use load() or use ResourceInteractiveLoader. <blockquote class="Quote">Would references to scenes in an array keep them around?</blockquote>That would keep them in memory but remember to instantiate and add them to the scene tree to actually use them