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?
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.
minmay wrote: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.
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.
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?
