Top Mud Sites Forum - View Single Post

koteko · 12-02-2012, 09:38 AM

@camlorn:

I'll make sure to have each graphical part optional, so that the text stream would contain all the information needed ("You see a closed door north, a red river east" etc). To make the MUD accessible is a priority. Thank you for pointing that out.

You're definitely right about the array overhead, I'll try to quantify it. A huge 4-dimensional array would mean..a bloody big waste of memory I fear. I might make it a huge unidimensional array in case I continue over this line. I could also use an hashmap, with (plane, x, y, z) as key, but if I remember well the performance go very bad with more than 10^6 elements unless I override the hashCode (there should good ones, and in general java 7 could have fixed this so I have to research).

About the 100 bytes, I don't think it's so bad. Most fields are for flags and properties and I can use a byte because I don't need many values.

I'd need 6 byte variables for the status of directions (or using some bit operations I might use only 1) (are they open, close, blocked, walls, or other?). I was also thinking of using 6 variables for the ID of the keys that open the doors, if they are present, because if I do just the opposite (each key knows which door of which room it opens) I have a problem if all the keys get destroyed. With 6 variables is more immediate and it costs 6*4=24 bytes. I could, otherwise, use an HashMap (with a blocked capacity of maximum 6) so only if there are actually doors there is memory consumption (in most of the cases there are not).

Let's say that at maximum I would consume 30 bytes for the doors informations but that could be reduced a lot for 90% of the rooms (most of the landscape would be open).

Than I have a reference to the room template, so another 4 bytes, and a float containing the current load of the room (there is a limit to how many objects can be put in each room).

In addition I need to store some properties because I have dynamic descriptions. For now, I've been regenerating the actual short and long description each time a property gets modified and saving them in the Room object but I could accept the overhead of generating them on the fly from the template only when a player enters a room. That would cost nothing memory wise.

These properties of course can be a lot, I'm adding them as I go, but most of them are template-specific (if I have a room_type "street" the side of the square will always be 10 meters, so I don't need a Room-specific field for the size (100 m^2)) so they don't have to be added to the Room object. This however can be an issue because, so far, I'm below 100 bytes, but I could go over in the next few years.

Than we have to count the references to players, mobs and objects but 90% of the rooms won't have any of them so should be fine (I use linkedhashset to store them, but I instantiate it only when a player add the first entity and I destroy it when a player removes the last).

All of this said, your suggestions are great! I could indeed populate the said array/hashmap/whatever only for rooms already built & visited (let's say 99% of the underground has not been colonized, as some of the planes and of course the sky, they won't be instantiated until a player actually visit it. At the reboot, they can avoid being saved if they are empty) or use only one object for default rooms until something modify its state. The two approaches seems roughly equivalent to me, given the fact that when a player enters a room there is already the need for a specialized Room object, otherwise I wouldn't know how to handle communication between players in that same room.

The worst case would likely never happen so I should be fine (especially if after a certain time I destroy things left on the ground).

About the coordinates in the rooms, this is how I've been doing so far with my little test environment (9x9 rooms..). Since I'm going to implement teleportation, I would certainly need something like you suggest (storing one out of 50 rooms or similar). I don't see a huge improvement however, just the 40 megabytes of the pointers table + the array overheads (I don't really know how much that is going to be), unless I also implement one of the other suggestions (in that case, I'd go for the matrix to keep coordinates as I find it easier to visualize and manage the world).

In general I'll avoid caching unless really obliged, it's like a point of honour :P

One last thing: almost everything is managed with lookup tables, and entity classes just use pointers to element of these tables. Especially strings are mostly stored somewhere and eventually parsed on the fly for specific uses. I try to avoid redundancy as much as possible, so I'm not really worried about the memory of anything except for this map issue. It requires further analysis though.

Thank you again!!

@KaVir:

So you actually used what camlorn suggested me: creating rooms on the fly only when a player enters them, avoid as much redundancy as possible through lookup tables. It's amazing to see how little space your world occupied. Thank you for sharing it.

About the player problem, you certainly are making me think carefully. Have you tried ways to control the abuse? BANs, especially, but even passive ways: make it difficult. To dig requires time and teamwork and a lot of materials, if you don't build good structures underground the room will crash. Because each object has a "life countdown" based on its material and quality of production, if you manage to build some "stupid thing" into the environment it will eventually crash on itself even without staff intervention, especially if the player get banned for a while.

If you add to this that the MUD is FULL-RPG, there will be very few people that'll try this kind of stupid things, I hope. Normally lamers stay away from RPI muds. What do you think?

12-02-2012, 09:38 AM	#4
koteko New Member Join Date: Mar 2012 Posts: 20	Re: A huge grid world @camlorn: I'll make sure to have each graphical part optional, so that the text stream would contain all the information needed ("You see a closed door north, a red river east" etc). To make the MUD accessible is a priority. Thank you for pointing that out. You're definitely right about the array overhead, I'll try to quantify it. A huge 4-dimensional array would mean..a bloody big waste of memory I fear. I might make it a huge unidimensional array in case I continue over this line. I could also use an hashmap, with (plane, x, y, z) as key, but if I remember well the performance go very bad with more than 10^6 elements unless I override the hashCode (there should good ones, and in general java 7 could have fixed this so I have to research). About the 100 bytes, I don't think it's so bad. Most fields are for flags and properties and I can use a byte because I don't need many values. I'd need 6 byte variables for the status of directions (or using some bit operations I might use only 1) (are they open, close, blocked, walls, or other?). I was also thinking of using 6 variables for the ID of the keys that open the doors, if they are present, because if I do just the opposite (each key knows which door of which room it opens) I have a problem if all the keys get destroyed. With 6 variables is more immediate and it costs 64=24 bytes. I could, otherwise, use an HashMap (with a blocked capacity of maximum 6) so only if there are actually doors there is memory consumption (in most of the cases there are not). Let's say that at maximum I would consume 30 bytes for the doors informations but that could be reduced a lot for 90% of the rooms (most of the landscape would be open). Than I have a reference to the room template, so another 4 bytes, and a float containing the current load of the room (there is a limit to how many objects can be put in each room). In addition I need to store some properties because I have dynamic descriptions. For now, I've been regenerating the actual short and long description each time a property gets modified and saving them in the Room object but I could accept the overhead of generating them on the fly from the template only when a player enters a room. That would cost nothing memory wise. These properties of course can be a lot, I'm adding them as I go, but most of them are template-specific (if I have a room_type "street" the side of the square will always be 10 meters, so I don't need a Room-specific field for the size (100 m^2)) so they don't have to be added to the Room object. This however can be an issue because, so far, I'm below 100 bytes, but I could go over in the next few years. Than we have to count the references to players, mobs and objects but 90% of the rooms won't have any of them so should be fine (I use linkedhashset to store them, but I instantiate it only when a player add the first entity and I destroy it when a player removes the last). All of this said, your suggestions are great! I could indeed populate the said array/hashmap/whatever only for rooms already built & visited (let's say 99% of the underground has not been colonized, as some of the planes and of course the sky, they won't be instantiated until a player actually visit it. At the reboot, they can avoid being saved if they are empty) or use only one object for default rooms until something modify its state. The two approaches seems roughly equivalent to me, given the fact that when a player enters a room there is already the need for a specialized Room object, otherwise I wouldn't know how to handle communication between players in that same room. The worst case would likely never happen so I should be fine (especially if after a certain time I destroy things left on the ground). About the coordinates in the rooms, this is how I've been doing so far with my little test environment (9x9 rooms..). Since I'm going to implement teleportation, I would certainly need something like you suggest (storing one out of 50 rooms or similar). I don't see a huge improvement however, just the 40 megabytes of the pointers table + the array overheads (I don't really know how much that is going to be), unless I also implement one of the other suggestions (in that case, I'd go for the matrix to keep coordinates as I find it easier to visualize and manage the world). In general I'll avoid caching unless really obliged, it's like a point of honour :P One last thing: almost everything is managed with lookup tables, and entity classes just use pointers to element of these tables. Especially strings are mostly stored somewhere and eventually parsed on the fly for specific uses. I try to avoid redundancy as much as possible, so I'm not really worried about the memory of anything except for this map issue. It requires further analysis though. Thank you again!! @KaVir: So you actually used what camlorn suggested me: creating rooms on the fly only when a player enters them, avoid as much redundancy as possible through lookup tables. It's amazing to see how little space your world occupied. Thank you for sharing it. About the player problem, you certainly are making me think carefully. Have you tried ways to control the abuse? BANs, especially, but even passive ways: make it difficult*. To dig requires time and teamwork and a lot of materials, if you don't build good structures underground the room will crash. Because each object has a "life countdown" based on its material and quality of production, if you manage to build some "stupid thing" into the environment it will eventually crash on itself even without staff intervention, especially if the player get banned for a while. If you add to this that the MUD is FULL-RPG, there will be very few people that'll try this kind of stupid things, I hope. Normally lamers stay away from RPI muds. What do you think?