Top Mud Sites Forum - View Single Post

camlorn · 12-01-2012, 08:23 PM

First, as I always do, let me take this time to point out that blind accessibility is a good source of players and that giving that some thought is probably worthwhile (ascii maps don't work).

Now, your question:

You have some options here. You're not going to be storing arrays of pointers, no. Do you know about the overhead of the jvm with 2-dimensional arrays? The numbers in your post aren't correct, it's actually bigger, because the jvm's 2-dimensional arrays aren't optimized into 1 array, and every array has overhead: it's an array of 1000 arrays, each with 1000 items, and so on. Also, there's almost no way your room objects are going to be 100 bytes, unless you do a whole bunch of things with bit shifting and bitwise operators. You're looking at closer to 10gb, if I had to guess, but this is possibly high, and you're not accounting for objects.

Firstly, in theory, it's minecraft. Minecraft works, graphically, because each room is a component, and we look at it from a larger perspective than the single-component view. In a mud of this size, most players aren't ever going to visit 90%+ of your rooms. In theory, being able to modify everything like that is great, but unless you're doing something graphical or something rts, there's not much point of going that route. Players will find the best path and share the speedwalk, and will simply strip mine, etc.

So, consider one of the following optimizations.

Each room doesn't exist until it must exist. A room exists if it has been built by a builder or caused to exist by a player action. Rooms can be transient or perminent, and transient rooms can be removed so long as nothing is in them.

Coordinates can be assigned to the rooms. Rooms have coordinates based on the coordinates of surrounding rooms: if the room 1 south has a y of 500, I'm in room with y 501, etc. If you know the coordinates of some room c, and are making some room n, the coordinates of n are the coordinates of c + the vector of the direction in which n is to be connected. There are optimizations on this and ways to get it working such that you can arbetrarily find the room n rooms north, or whatever: namely, storing one out of 50 rooms, and starting at the one closest to the coordinates you want to look at. Getting rid of temporary rooms will free up the space, and there's no enormous pointer index (pointer index isn't end-all or anything, but it does make some of this harder, and it isn't exactly small).

Rooms can be cached to disk. This can be done transparently, though doing so is work. The idea is that you start storing to disk when you start running out of space, in an oldest-first fashion. The trick here is that the pointer index isn't an array, it's a "smart" class that handles this, i.e. roomIndex.access(5,20), etc. Name rooms for their coordinates, i.e. r5_20, and use java serialization to get a saveable format before destruction (this, also, has problems. You can't share data, not easily, because when deserializing the data is copied--I think. Could be wrong. If the room links, somehow, back to the pointer index, well, the whole pointer index gets dragged along for the ride if you don't mark it properly, and you'll need the special magical functions that let you reestablish transient class members). It's been a long time since I've looked at java serialization, at all, so sorry for inaccuracies.

Finally, and this is the easiest perhaps. There is some generic terrain room, for example the sky room. When something happens to our sky room, maybe weather control--I picked sky because it really illustrates this--you make a copy. The trick is this. In the pointer index, you store all sky rooms as a pointer to the generic sky room. When a sky room gets changed, by whatever, the reference in the table is replaced with the pointer to the changed sky room, the sky room is flagged as non-default, and further changes act on that copy. This may have issues with your chosen path of multithreading, and copying the sky room and relinking to the table every time it changes has advantages, but that also has bookkeeping problems.

You can take this further and cache strings, too.

12-01-2012, 08:23 PM	#2
camlorn Member Join Date: Aug 2011 Posts: 144	Re: A huge grid world First, as I always do, let me take this time to point out that blind accessibility is a good source of players and that giving that some thought is probably worthwhile (ascii maps don't work). Now, your question: You have some options here. You're not going to be storing arrays of pointers, no. Do you know about the overhead of the jvm with 2-dimensional arrays? The numbers in your post aren't correct, it's actually bigger, because the jvm's 2-dimensional arrays aren't optimized into 1 array, and every array has overhead: it's an array of 1000 arrays, each with 1000 items, and so on. Also, there's almost no way your room objects are going to be 100 bytes, unless you do a whole bunch of things with bit shifting and bitwise operators. You're looking at closer to 10gb, if I had to guess, but this is possibly high, and you're not accounting for objects. Firstly, in theory, it's minecraft. Minecraft works, graphically, because each room is a component, and we look at it from a larger perspective than the single-component view. In a mud of this size, most players aren't ever going to visit 90%+ of your rooms. In theory, being able to modify everything like that is great, but unless you're doing something graphical or something rts, there's not much point of going that route. Players will find the best path and share the speedwalk, and will simply strip mine, etc. So, consider one of the following optimizations. Each room doesn't exist until it must exist. A room exists if it has been built by a builder or caused to exist by a player action. Rooms can be transient or perminent, and transient rooms can be removed so long as nothing is in them. Coordinates can be assigned to the rooms. Rooms have coordinates based on the coordinates of surrounding rooms: if the room 1 south has a y of 500, I'm in room with y 501, etc. If you know the coordinates of some room c, and are making some room n, the coordinates of n are the coordinates of c + the vector of the direction in which n is to be connected. There are optimizations on this and ways to get it working such that you can arbetrarily find the room n rooms north, or whatever: namely, storing one out of 50 rooms, and starting at the one closest to the coordinates you want to look at. Getting rid of temporary rooms will free up the space, and there's no enormous pointer index (pointer index isn't end-all or anything, but it does make some of this harder, and it isn't exactly small). Rooms can be cached to disk. This can be done transparently, though doing so is work. The idea is that you start storing to disk when you start running out of space, in an oldest-first fashion. The trick here is that the pointer index isn't an array, it's a "smart" class that handles this, i.e. roomIndex.access(5,20), etc. Name rooms for their coordinates, i.e. r5_20, and use java serialization to get a saveable format before destruction (this, also, has problems. You can't share data, not easily, because when deserializing the data is copied--I think. Could be wrong. If the room links, somehow, back to the pointer index, well, the whole pointer index gets dragged along for the ride if you don't mark it properly, and you'll need the special magical functions that let you reestablish transient class members). It's been a long time since I've looked at java serialization, at all, so sorry for inaccuracies. Finally, and this is the easiest perhaps. There is some generic terrain room, for example the sky room. When something happens to our sky room, maybe weather control--I picked sky because it really illustrates this--you make a copy. The trick is this. In the pointer index, you store all sky rooms as a pointer to the generic sky room. When a sky room gets changed, by whatever, the reference in the table is replaced with the pointer to the changed sky room, the sky room is flagged as non-default, and further changes act on that copy. This may have issues with your chosen path of multithreading, and copying the sky room and relinking to the table every time it changes has advantages, but that also has bookkeeping problems. You can take this further and cache strings, too.