Right now I'm using C# in XNA/MonoGame. I'm brainstorming an isometric game that consists of rectangular rooms. The allowed dimensions of each room range from 3x3x3 to 12x12x6.
The max volume of each level is 432x432x216. That volume can hold a max of 1,492,992 rooms! That's practically 1.5 million! So it's important to consider how rooms are stored. My default idea is to use 2D arrays to hold a list of objects on the floor, wall, and ceiling (yes, I want to use magic spells for wall walk and even ceiling walk to get secrets on the walls/ceilings).
So, again, a 3x3x3 room would have 6 2D arrays that are each 3x3 arrays. Each array element is a list holding items. So each room would hold 54 lists. So now 1.5 million rooms would hold 81 million lists!!! I don't know what the max or average number of elements in each list will be, but I'm guessing up to a max of 6.
If we assume each Object in the list will be only 1 kilobyte in size (that's a low estimate), we're talking 81 gigabytes of memory. This does not even count the overhead of 2D arrays and lists.
Obviously, this cannot be stored in memory. So I need some other scheme. Is there some officially recommended scheme for this sort of thing?
One more caveat. The player character will not be the only guy walking around. There will be monsters too. They need to run around in other rooms.
Here is my explanation for the 1KB object data size.
1KB is my estimate based on past experience. Off the top of my head, here's what each object needs:
- enum byte for the type (block, food, key, etc.)
- byte for subtype (like different colored keys or different colored tiles)
- 2 bools for pushable, pullable
- byte for points (treasure might give 50 or 100 points, food might fill 10 or 20 health points)
- byte for height (some objects are flat, others have height 1, 2, 3, up to 6)
- 8 bools for 4 enterable dirs and 4 exit dirs (for force-field blocks)
- a List of target objects for switches (this is a 32-byte or 64-byte pointer depending on architecture, and each entry will also be 32 or 64 bytes).
- a pointer back to the room object (32 or 64 bytes again)
I count 14 bytes + the list and final pointer. This is probably only the beginning. I can compact some things, if I want, like compacting the 8 force field bools into a single bool (which is normally 8 bits, but I could use a byte and do integer comparisons for which bit I'm looking at).
The real question is what will be the average size of each object, which I think is impossible to estimate right now. I'm sticking with my 1KB estimate; I think at the very least, it's a reasonable cap on the worst case scenario.
Max volume is now reduced to 144x144x144. Assuming all rooms are 3x3x3, the max rooms is about 110,000, which would take over 30 hours just to traverse all rooms assuming 1 second is spent in each room. So 144x144x144 is plenty of volume. I will proly store levels as giant string or byte arrays since the data has to come from disk anyway (when loading a new level). A few rooms can be culled with more elaborate 2D and 3D arrays holding actually objects, which will drawing and interactions much easier.