Top Mud Sites Forum - View Single Post

koteko · 12-03-2012, 01:26 PM

@newworlds:

As I've stated in the last post, I don't "want" to load them all, of course, mine was just a (naive) point of simplicity. I do want a world that big though, since it has to be modifiable by the players (the "ground level" as well as skies and undergrounds). Minecraft-like MUD, as camlorn said.

Now my problem is not IF I have to cache, but to find a compromise between efficiency and simplicity/cleaness of code. Assembler-era optimisations were necessary, but now they are an overkill in most of the cases. I'm ok with wasting some RAM and cpu cycles as long as I'm comfortable with the code I'm creating and of course I meet my own requirements, in this case maximum 2GB of overall RAM usage (that's the reason I use Java). What is really important, instead, is to have algorithmic efficiency (using the right sorting algorithm at the right moment, for example, and choosing the right data structures case by case): that does never become old. These are just my opinions though.

After the discussions here, that's what I've decided so far:

1) a grid style format of the data (the offline rooms will all be tagged with four coordinates, the plane and the x, y and z) so that I can have the spatial coerence I want
2) templates for entities, so that there is as less redundancy as possible (the actual Room objects, for example, will only contain room-specific data, not the descriptions or the general size of the TYPE of room they are made from)
3) load on request of objects, mobs and rooms as now is for players. These objects will be put in different HashMaps, some of them backed by hard disk in case a certain threshold is reached. Only the actual room stuff will be loaded since the templates will all be put in memory, as KaVir did.

that should be:

1) cpu efficient, since when an object is requested the DB quickly retrieves it (thanks to indexes) and it is quick to be created having the template linked externally (only a few bytes actually have to be loaded)
2) memory efficient, since I have some object overhead but the average number of loaded objects should be very small most of the time. Using MapDB for the hashmaps, in addition, lets the garbage collector free up some cache in case loaded entities are used rarely during a session
3) very clean code-wise, since the caching will be completely transparent and I've already written an API to get the objects without knowing there's a database behind (this to make it simple to change the backend in future).

So I guess I'm going to use very little RAM and still have all the flexibility I want. This thanks to all the very good suggestions here...this forum is a really good resource, thanks again!

12-03-2012, 01:26 PM	#17
koteko New Member Join Date: Mar 2012 Posts: 20	Re: A huge grid world @newworlds: As I've stated in the last post, I don't "want" to load them all, of course, mine was just a (naive) point of simplicity. I do want a world that big though, since it has to be modifiable by the players (the "ground level" as well as skies and undergrounds). Minecraft-like MUD, as camlorn said. Now my problem is not IF I have to cache, but to find a compromise between efficiency and simplicity/cleaness of code. Assembler-era optimisations were necessary, but now they are an overkill in most of the cases. I'm ok with wasting some RAM and cpu cycles as long as I'm comfortable with the code I'm creating and of course I meet my own requirements, in this case maximum 2GB of overall RAM usage (that's the reason I use Java). What is really important, instead, is to have algorithmic efficiency (using the right sorting algorithm at the right moment, for example, and choosing the right data structures case by case): that does never become old. These are just my opinions though. After the discussions here, that's what I've decided so far: 1) a grid style format of the data (the offline rooms will all be tagged with four coordinates, the plane and the x, y and z) so that I can have the spatial coerence I want 2) templates for entities, so that there is as less redundancy as possible (the actual Room objects, for example, will only contain room-specific data, not the descriptions or the general size of the TYPE of room they are made from) 3) load on request of objects, mobs and rooms as now is for players. These objects will be put in different HashMaps, some of them backed by hard disk in case a certain threshold is reached. Only the actual room stuff will be loaded since the templates will all be put in memory, as KaVir did. that should be: 1) cpu efficient, since when an object is requested the DB quickly retrieves it (thanks to indexes) and it is quick to be created having the template linked externally (only a few bytes actually have to be loaded) 2) memory efficient, since I have some object overhead but the average number of loaded objects should be very small most of the time. Using MapDB for the hashmaps, in addition, lets the garbage collector free up some cache in case loaded entities are used rarely during a session 3) very clean code-wise, since the caching will be completely transparent and I've already written an API to get the objects without knowing there's a database behind (this to make it simple to change the backend in future). So I guess I'm going to use very little RAM and still have all the flexibility I want. This thanks to all the very good suggestions here...this forum is a really good resource, thanks again!