koobas.hobune.stream
Large City (Mobile) Memory Optimization Idea
Hi
I'm working on a city building game for mobile (iPhone 5S min) that is similar to Age of Empires (the PC version). The terrain is already present (it is a large terrain - 3500x2000) and the user can place around 100 different buildings in there.
I'm estimating the terrain will be able to have approximately 1000 buildings, a few dozen ships and 300-400 people which causes a memory havoc.
What is the best way to optimize performance in a way that doesn't cause memory issues. I was thinking of destroying buildings/people that were not visible in the camera view and then instantiating as the user is moving the camera. This could be CPU intensive and might cause lag.
Any help will be greatly appreciated.
P.S - I have already optimized the rendering aspect with low poly assets, one texture etc.
Destroying and re-instantiating objects is a horrible idea.
Divide the map into a virtual grid of X by Y units. (lets say 128x128 units for instance) $$anonymous$$eep data for all tiles in the view frustum + some radius around it in memory, destroy the rest and load if these tiles fall into the radius of the view frustum.
Put loading in a coroutine to avoid lags. It might cause some popping objects here and there but I suppose it can be countered the one way or the other.
That's a general idea but it's probably not that easy. If stuff isn't in memory it can't be simulated (people going after their tasks for instance).
Perhaps it will suffice to toggle the graphical components on or off.
Thank you for the reply.
Yes this is what I plan on doing. Adding it into coroutine seems like a good trick to avoid lag. For the people, most of these will be cosmetic (only there to fill up). I won't remove the workers that have to do tasks.
Do you think removing complete building objects using "Destroy/Instantiate" in this case will be fine?
Also, on a side note, how much memory should such a game consume on iPhone 6 that can be handled by the phone?
If you have absolutely no other solution for this, sure it will do.
But then, with the idea of limiting visible stuff - you'll probably not have all the 1000 objects on screen at once so ins$$anonymous$$d of destroying these, put them in a pool (or one pool each object type) and enable/disable them and adjust positions accordingly.
Like, make a pool of 200 something buildings. Define (in one way or the other) positions in space where houses can be placed.
Take houses out of the pool and place them at the pre-defined coords if they fall into the visible area as defined above. Put them back into the pool if they leave the visible area. That keeps a constant memory footprint and avoids lag of instantiating things during runtime.
You'll have to deter$$anonymous$$e / remember the places where buildings are separately. But a list of Vector3 instances is not such a big memory hog, after all.
Using an occlusion culling system could boost the performance of the game greatly. Occlusion culling deactivates the gameobjects that are not visible to the camera.
Occlusion Culling helps in reducing rendering over head - I'm not sure there is any benefit to reduce memory usage?
