So I decided to make hd-art openworld game. And to do so I implemented a system of spawners that would repopulate the world when you return to the places you already been to. And it works perfectly, except compiled game freezes for a split second every time first enemy of a kind is created by a spawner. I checked the ram usage - it adds roughly 25Mb to the RAM, which should not really cause that problem, and it was tested on an SSD so it should not be a problem with a hard drive either, but cpu usage spikes at those moments as well, but I tried to use uncompressed png files in case decompression takes that time, and it didn’t help if not made it worse.
I know, I can keep the assets in memory at all times, but if I’m making an open world game this isn’t really an option. Suppose I’ll do it for all the enemies since they have a lot of animations, but would it freeze every time a part of the terrain loaded? I don’t know, I only have a test terrain reused a few times since I’m starting with game mechanics first.
Either way, for the very least I’d like you to allow the game to run wile assets still being loaded to prevent freezes since enemies are spawned way off the screen, and load current animation frames first, or something. I don’t know how it works, I’m mostly an art kind of person myself, but I also understand the machine logic, so GDevelop would be a perfect solution for me if not this freezing problem
UPDATE: I realized I should probably mention that this happens in the compiled native windows application, preview inside GDevelop doesn’t have that problem probably because assets are always kept in RAM.
UPDATE2(offtopic): forum engine counts me checking on my own message as a new view every time, might want to do something about it ^^’
Also related question: how does GDevelop handle huge game levels with a lot of assets, both in compiled game and in editor itself? Does it automatically unload objects too far away from camera, or will I have to make a spawner system for elements of terrain as well?
GDevelop doesn’t unload objects even if they are far away from the screen and if I recall correctly, it also renders the objects even if they are too far (maybe we can do something about it if it’s the case).
I don’t think GDevelop is made for open worlds games, I mean those games have dynamic memory management to load/unload resources as the player moves in/out around zones. So I think you’ll have to do it manually, saving dynamic objects in external files to load and create them when needed, and creating static objects from external layouts, for example the terrain, but not sure about the overal performance
What caught my attention is the freeze time in the compiled game that doesn’t happen in the preview, because I have already readed this some time ago: [url]Compiled game take pauses]
I have to say, setting up a spawner system was pretty easy - you just have an object with two animation sets with first having a huge collision box, then when player collides with it logic calls for the variable of the spawner to get what should be spawned and it switches to the second animation which is inactive. And it switches back to animation 0 when you are too far away and whatever it is is despawned.
It works perfectly well, if only game didn’t pause for assets to load. And another question is would spawners on their own be too much even if they would have no assets of their own, or shared 1 pixel texture.
How do you imagine that? I’m loading just one object per spawner, and it’s just an enemy with 4 animations, and I cut out as much empty space as I could. It’s just uncompressed bitmap data for 17 or something frames takes 25Mb of ram, and game doesn’t load them one by one, it just pauses until the whole package is done, which takes like 0,1-0,2 seconds, but completely breaks the flow of the game. Should I have a logic object without assets, and swap animated ones instead of switching animations? That sounds like even more of a disaster tbh. I have another enemy spawning by the same logic that don’t have animation yet, so I used one of player’s frames as a placeholder, and it causes no freeze, even though it’s logic is much more complex - it’s an archer that shoots arrows, keeps the distance, runs away from you if you get closer and goes mele if you get too close.
Also at the very early point of the spawners when I tried to rely only on proximity (never worked out btw) I had one object per spawner limit removed and it was quite a hilarious wave of enemies without that much of a hit to performance. I’m pretty sure there is some sort of inefficiency in the way this engine handles ram, 25Mb should not even take one frame to load into it, that’s the whole point of ram.
When compiled, game loads their resources from a single file (where all resources have been regrouped at compilation time). That’s maybe why it’s taking a bit more time. However, I do not believe there’s a “bug” in GDevelop’s way of creating objects.
Basically, when spawning an object, GDevelop do :
Find the object to create (according to its name)
Create an instance from it
Apply the instances properties to it (mainly X and Y position, and sometimes object’s variables specific to this instance)
Add the behaviors to it
Doing some other object initialization (for example, request the texture for a sprite : if the texture is already used by another object or flagged “Always loaded”, just get it without reloading it ; if not, loading it).
EDIT : I’ll take a look at the loading process to be sure no performances problems are related to it.
I may have some ideas to improve the performances. However, I don’t have a game with a lot of texture on my computer.
So, can you send me your project (with all the resources) in a PM ? It will allow me to do some tests with different loading procedures.
