Doors, Triggers, Monsters, and Memory

[David Ward]

Hello. I was curious if anyone knew what the limit on the number of doors, triggers and monsters in one project was before issues would arise regarding hardware memory. My friend and I are looking to end up with something like 1,000 floor triggers, for example, and it sounds like a bit much. Would it be so much that the game could not be exported from the editor or even playable?

[minmay]

Memory usage from game objects is going to be dwarfed by the memory usage from textures, etc. The bigger problems are:
- CPU usage. I believe all components on 3 levels will be updated every frame (this was the case in Grimrock 1, not sure about Grimrock 2); if you really have tons of components on one or more levels it could cause problems. I did some testing and 1,024 floor triggers on a level (one for each tile) will probably add a few milliseconds to the update delay, so you can get away with it but there's probably a better way to accomplish whatever it is you want to do. Of course if you mean 1,000 floor triggers in your entire mod, not just one level, it's unlikely to be a problem.
Note that FloorTriggerComponent seems to be exceptionally demanding; 1000 spawners or 1000 timers is no problem.
- Save games. Every object in the dungeon has to be saved in the save game file. If it doesn't have minimalSaveState, its entire state has to be saved. The more objects you have, especially without minimalSaveState, the longer it'll take users to save the game (and the larger the file will be).

Doors and monsters will presumably have models or particle effects, so your limitation there is basically guaranteed to be the GPU rather than any other hardware.

The main campaign has about 60,000 objects.

[badhabit]

Memory usage from game objects is going to be dwarfed by the memory usage from textures, etc. The bigger problems are:
- CPU usage. I believe all components on 3 levels will be updated every frame (this was the case in Grimrock 1, not sure about Grimrock 2); if you really have tons of components on one or more levels it could cause problems. I did some testing and 1,024 floor triggers on a level (one for each tile) will probably add a few milliseconds to the update delay, so you can get away with it but there's probably a better way to accomplish whatever it is you want to do. Of course if you mean 1,000 floor triggers in your entire mod, not just one level, it's unlikely to be a problem.
Note that FloorTriggerComponent seems to be exceptionally demanding; 1000 spawners or 1000 timers is no problem.
- Save games. Every object in the dungeon has to be saved in the save game file. If it doesn't have minimalSaveState, its entire state has to be saved. The more objects you have, especially without minimalSaveState, the longer it'll take users to save the game (and the larger the file will be).

Doors and monsters will presumably have models or particle effects, so your limitation there is basically guaranteed to be the GPU rather than any other hardware.

The main campaign has about 60,000 objects.

To give some quantitative numbers and measurements into the discussion: for the LOg2 main campaign, my system with a AMD 3.6GHz CPU and some years medium AMD graphic card, manages to be CPU and GPU limited in the outside areas (50%/50% for reasonable resolutions). LoG2 engine is quite heavy both CPU and GPU wise, what is untypically for a game in my experience.

[minmay]

To give some quantitative numbers and measurements into the discussion: for the LOg2 main campaign, my system with a AMD 3.6GHz CPU and some years medium AMD graphic card, manages to be CPU and GPU limited in the outside areas (50%/50% for reasonable resolutions). LoG2 engine is quite heavy both CPU and GPU wise, what is untypically for a game in my experience.

This isn't because of the number of objects, though. Not really relevant here.

[badhabit]

To give some quantitative numbers and measurements into the discussion: for the LOg2 main campaign, my system with a AMD 3.6GHz CPU and some years medium AMD graphic card, manages to be CPU and GPU limited in the outside areas (50%/50% for reasonable resolutions). LoG2 engine is quite heavy both CPU and GPU wise, what is untypically for a game in my experience.

This isn't because of the number of objects, though. Not really relevant here.

This I would like to know, because I see it otherwise wise. The outside areas with the greatest FPS hits, have most probably more objects. Also, Petri mentioned in a thread that an excessive draw call number as performance bottleneck, which is I guess related to the object number.

[David Ward]

Some great feedback, thank you both.

60,000 objects in the main campaign is a good reference point. By objects you mean...Monsters, floor triggers, doors, chests, items...what about individual trees? Rocks on the hillside? Or by objects do you mean anything that is interactive, not just graphical?

[minmay]

I mean instances of GameObject that are on a map.

[David Ward]

Right. 60,000 seems to be a lot, but maybe it isn't once everything starts getting added in.

Much appreciated for the responses, minmay. What do you think the upper limit on GameObjects would be before there would be issues exporting/playing?

[minmay]

Depends on what components they have, but you aren't going to get anywhere near it anyway.