The key thing I hear is "Hash Tables", i.e. plural. Sounds lke you have a added so much data that you have basiscaly overfilled the sink. The answer I am about to give may not be easy to deal with but it sounds like you are at the point of fix or scrap. Here is what I would do: First perform a full evaluation of the design to determine how much data really needs to store in a persistent manner, how much is ephemeral in nature, and finally what is the best way to store all this stuff? Remember a hash table is a fair amount of code that comes at the expense of memory. However in a game "speed" is the chief criterion. Thus finding a viable storage mechanism and keeping memory utlization reasonable should guide the solution. For these reasons I would think about creating a more efficient storage strategy. This takes into account things like graphics, you only need one copy and after that you should only store the deltas. Sure this means GDI programming but your are writing a game afterall. Game design is almost always equated with system code, and in C# that equates to unmanaged code. If you create a memory storage strategy and implement memory allocatio via Marshalled OS calls and pointers, then you are on the right track. For sure, any game write should know exactly how much data needs to be stored, how much needs to be paged in from disk, etc. Although C# is nice for lots of applications, I personally would use C++ for a game because of the closer fit to the OS. At the same time you can always write DLLs in C++ if you need the performance tweaks. Good Luck Mike Luster CTI/IVR/Telephony SME
