Hello,

in our project we have separated the logic and the loading of the objects it needs. The loading of the objects happens in different thread and after all the objects are loaded we start the execution of the logic. For example, we have gameplay code where we will need certain object (which can be seen only when reading the code, the object is not present in level file), we first load the object and after that we start the code (some function for example).

Our goal is to free the current thread, which executes logic, from the loading of objects. 

Some objects depend on other objects - to load certain object, another object must be loaded first. Also, there is no established hierarchy (so we can traverse it and load child objects of a parent) and we don't know what has to be loaded, unless we read the code.

The current problem with this implementation is that it is hard to maintain - we have to read all the logic, see what is going to be needed and add it for loading.

Is there elegant solution to solve this problem?

So, you're basically wanting some kind of lazily populated resource cache? Am I right in assuming that each object may be consumed by multiple other objects? So basically an object graph of some form?

Depending on the language of choice, there's an implementation of this at GitHub - ObjectGraph - documentation.

Essentially, one has a dictionary of address to object builder info (using my terminology above), requests are made on the main thread, and then get built on a thread pool. When an object has been built, it can then trigger any of its dependencies which have been asked for as well as being made available to any external caller which requested it.

The hard part is defining the addresses to use etc.

What objects are you referring to?

In many simulations and engines, there are several asynchronous pools.  The actual bits of objects for the simulator tend to be quite small. Large resources like textures, graphics and physics meshes, and similar work easily enough with a store/proxy/cache/instance model. The store creates small proxy objects that the simulator can use.  The proxy object contains the minimal information like the location in the world, but it may or may not have the actual resources loaded.

These are usually coupled with interest systems. Items both inside the view and close to a player are high interest, farther away are lower interest, and things outside the player's view distance are low interest. There is no need to keep old resources around when they're low interest and the space is needed for something that is high interest.

On 8/28/2019 at 4:42 AM, svetpet said:

Our goal is to free the current thread, which executes logic, from the loading of objects. 

"Objects" is an unfortunately overused term. It is quite common to have the level load and process information about a game object structure without loading any data for the mesh, texture, audio, or other presentation features.

Again, with a store/proxy/cache/instance model (it goes under many names, none are commonplace) much of this is solved.  A tiny structure serves as an intermediate object, or a proxy, that contains all the core information needed by the game.  It doesn't matter if they have the resource loaded or not, they contain enough data to run the simulation, and that's the important part.