I got permission to disclose some of my experience and associated knowledge as a playtester for Kerbal Space Program (which also uses Unity3D.) It seems that your GC issues and memory leak issues are far from unique with Unity3D, but anyone who's browsed the Unity3D developers and moders forums will know that one. There are several things they did in Kerbal Space Program to mitigate the problem. First they moved a huge portion of the metadata to an SQL database running parallel to the game. This could be a big solution to server lag and instance lifespan, but can even benefit the client. I would recommend, if possible, using a cloud-capable object-base for Shroud of the Avatar due to many aspects in which it allows larger objects to be stored. Also cloud-capable servers tend to be better at sparse storage of assets across several servers of varying latency. The use of a local mirror to a cloud-capable servers could also abstract the fetch of all major dynamic game data, as well as allowing predictive background prefetch and better timestamped cache for proper dynamic cache syncing. Second, they set scene transitions to purge a huge number of objects, and "froze" any that weren't purged. Then they they set it to force the GC. This was followed by loading the next scene (keeping objects frozen), forcing the GC again, and finally unfreezing everything. A few functions may not be able to be frozen (such as chat windows) but otherwise this might help substantially on transition memory leaks. Third, For texture memory reduction, the KSP team was incredibly cautious about the quriks of Unity3D. The team was very attentive to insure that any textures that did not receive CPU alteration to be marked as non-accessible by the CPU. This change alone nearly cut footprint in half. Additionally, the use of texture compression and various forms of height mapping are used extensively. It was found that Unity3D had a serious memory leak in it's image import routine, so all textures were pre-processed into Direct3D texture format (which the other render paths also can load cleanly.) This also allowed the textures to be pre-compressed and lightly "crunched" to reduce disk bandwidth used during loading at the cost of a tiny bit of CPU time during load. As of using various methods of height mapping to give you an idea of the extent that this is done, all the cylinder and rod shapes are either hexagons or octagons before being given their "shape" with the height map offsets. This substantially reduces resource usage across the board. If you need more information, or have any questions, I am in contact with the KSP dev team. I can relay your questions or set up a line of communication. I'm sure any echange between the two teams about the nature of the Unity3D platform could be mutually beneficial and make both games better.