Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Coding
Click here to Register

Reply
 
Thread Tools
Old 12-01-2012, 06:10 PM   #1
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
A huge grid world

I had written a big post but the browser crashed, so I'm going to make it short.

In my MUD engine, I'm trying to decide whether to go for the standard area-based world or if to try to make it more coerent (yet less flexible, builder-side) using a huge matrix.

Mine is going to be a big universe, describable by a 4-dimensional matrix of pointers to Room objects: world[planes_n][x][y][z]. The planes are probably going to be 5, each one with at most 1000x1000 rooms. The "z" coordinate is needed because I want to allow digging tunnels and flying in the skies freely.

Doing some calculation, I ended up with this:

1000x1000 pointers (4 bytes on a 32 bits system) to room objects (each one, for simplicity, let's say big 100 bytes), 5 planes, 5 layers under the ground and 5 layers for the skies (so 11 possible values for the "z" coordinate) occupy a bit more than 5GB of RAM ((5*1000*1000*11*4 + 5*1000*1000*11*100) bytes if you were curious). Without counting objects, mobs and players. With 32bit the JVM is able to allocate at most 2GB so...I have a problem.

Just the pointers to the rooms occupies about 40 megabytes, so trying to reduce as much as possible the size of a single room object is a must. Maybe trying to reuse the same room object for some parts of the world (especially the skies) would do the job, but I don't really know how to do it consindering the players will together move into the same sky-rooms.

I'm also bugged about the limit which I am obliged to put to the "z" coordinate, which with this area-less system determines the height of the buildings (maximum five floors over the ground) and the depth of dungeons (maximum 5 levels under the ground).

Of course there are things I can think of to reduce the memory usage, like the underground and the skies are instantiated at running time and made persistent only when an user actually use it and modify it while digging tunnels or creating a flying house. Or I could make some of the planes smaller than 1000x1000, and/or reduce the world grid to 1000x500 or even less.

I just thought I'd post here my doubts to get some feedback. I'm aware odds are that you are already using an area-based system, but do you think it would work with a fully persistent, modifiable world? Do you have any ideas on how to reduce the memory usage with a grid-based universe like mine?

Last question: do you think a seamless world of 1000x500 rooms is too big? I'm going to allow the building of villages/towers from players, that I guess make a small world little apt to my needs.

Thank you from any advice you'll be able to give me.

Last edited by koteko : 12-01-2012 at 06:42 PM.
koteko is offline   Reply With Quote
Old 12-01-2012, 08:23 PM   #2
camlorn
Member
 
Join Date: Aug 2011
Posts: 144
camlorn is on a distinguished road
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.
camlorn is offline   Reply With Quote
Old 12-02-2012, 07:09 AM   #3
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: A huge grid world

I did something similar in the past - described , more recently I gave an overview of the memory usage .

The world was 5120x5120x40 (over a billion rooms), and typically used under 2MB of RAM. It managed this by using virtual rooms generated from templates. Players could dig tunnels and mine for ore, chop down trees and use the wood to construct buildings, plow and seed fields to grow crops, etc.

I thought it would be great, but that was 15 years ago and I still had a lot to learn about players. They decimated the forests, riddled the ground with tunnels, and scrawled offensive messages across the landscape in gigantic letters made from buildings or crop fields.
KaVir is offline   Reply With Quote
Old 12-02-2012, 09:38 AM   #4
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
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 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?
koteko is offline   Reply With Quote
Old 12-02-2012, 11:05 AM   #5
scandum
Senior Member
 
Join Date: Jun 2004
Posts: 315
scandum will become famous soon enough
Re: A huge grid world

I'd suggesting using a grid of pointers to an index table. KaVir uses 2 byte keys which means he can't easily create dynamic content.

Using pointers you have the flexibility to set the pointer to a tile in the lookup table, saving quite a bit of memory doing so, or alternatively to a custom tile that can be altered and modified on the fly.

Using this approach you can also add two pointers for tiles up and down from the tile that is on the 2d grid, allowing the creation of tunnels and towers.

Another problem it solves is that you can maintain a linked list of all players on the tile. With the 2 byte key approach the world is treated as one room, typically resulting in long lists slowing down the system.

So if a player moves from one tile to the next the MUD would check if that tile points to dynamic memory or static memory in the index table. If the tile is in the lookup table the MUD will allocate memory and create a duplicate of the tile in dynamic memory, and adds the player as content of the newly created tile. When the player leaves the tile the dynamic memory is freed and the pointer is set back to point to the index table.

The only downside is that pointers take up 8 bytes on modern systems.
scandum is offline   Reply With Quote
Old 12-02-2012, 11:10 AM   #6
camlorn
Member
 
Join Date: Aug 2011
Posts: 144
camlorn is on a distinguished road
Re: A huge grid world

Well, no.

You will cache. It doesn't matter how much you don't want to, you will cache. KaVir's 2mb world was that small because it cached. Most muds, even smaller ones, cache (Not rom/diku...but lpmuds do).

Here's the thing. If you cache, well, disk space is cheep. You can put as many properties on the rooms as you want, etc. The problem with using bitwise operations to store properties is that, eventually, you'll want to add a new one. You'll have 3 bits, say, idk...open/closed, locked/unlocked, and whether I can go in that direction in the first place, and you'll be storing more than one direction in the same variable for size. Then you'll want to add, say, a forcefield spell, and you'll need a fourth...good luck. I really think that implementing caching now, while your world is still at an early stage, and not using bitwise operations will save you a lot of work in the long-run. There really is no avoiding it: your calculations only account for room objects, not corpses and players and swords that people drop everywhere. Capping how much stuff can be in a room isn't a bad idea, but it'll have to be a pretty high cap, if you want corpse delay; people will be running around with full sets of eq and as many items as they can save up, and so will mobs, or so I imagine...maybe you've got something different in mind, but if you don't, that's going to take another chunk of ram.

The second point. Have you looked at server pricing? I don't know for certain, but I suspect that a server with over 4gb of ram is going to be pricy. At that point, you're looking into a non-shared server solution, and vps providers really, really want you to share with other people.

I've looked into doing something similar to what you want to do, a sort-of cross between godwars2, empiremud, and dark legacy, with a huge world. I did talk to some people about it, people who know a whole lot more about all this than me, and there was one universal answer: disk caching. From everyone.

Finally, this isn't the thread for it, but if you open up the discussion of blind friendliness, I will help you. I've got qualifications after all: namely, being blind...so.
camlorn is offline   Reply With Quote
Old 12-02-2012, 11:35 AM   #7
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: A huge grid world

I shut that mud down over a decade ago, for a number of reasons (including the realisation that the entire concept of "rooms" was an unnecessary artificial limitation), but I've never viewed the ban hammer as a good solution to a design problem.

My solution did use an array of pointers. In fact it worked almost exactly as you've just described.
KaVir is offline   Reply With Quote
Old 12-02-2012, 03:34 PM   #8
scandum
Senior Member
 
Join Date: Jun 2004
Posts: 315
scandum will become famous soon enough
Re: A huge grid world

Guess I should have read the entire post.

Another option is using an octree, though these are a little less straight forward to implement.
scandum is offline   Reply With Quote
Old 12-02-2012, 03:41 PM   #9
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
Re: A huge grid world

as far as server pricing is concerned, I'm fine with buyvm for the 25$ monthly (it's 20$ if you pay bi-yearly). That means I need to stay into MAXIMUM 2GB overall, even though burst up to 4GB are available. Indeed I'm considering very carefully which optimisation to use.

I have actually thought to use databases, since the offline data is already stored. H2 database seems to be very well performant (especially if embedded in the application, not client-server) and it'd do the caching for me (some of the tables could be completely loaded in memory). I'm just not sure about how good it is with a lot of users issuing a lot of commands and moving around, but I will do some tests with a huge database to see how it does.

Any experience with DBs for MUDs? If I understood correctly also CoffeeMUD uses them, I'm going to check if they do some personalized caching loading rows into objects or something.
koteko is offline   Reply With Quote
Old 12-02-2012, 05:12 PM   #10
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
Re: A huge grid world

..as far as I could see in the messy CoffeeMUD, they get all the stuff and put it in vectors..so I guess they just have a small world.
koteko is offline   Reply With Quote
Old 12-03-2012, 07:25 AM   #11
Achon
Member
 
Join Date: Oct 2011
Posts: 40
Achon is on a distinguished road
Re: A huge grid world

You could use a database management system, like one of oracles. Which would
use some local caching and no doubt utilize the OS virtual memory subsystem.

This would probably give reasonable speed and offer more space for your
ideas. It would also scale well and free up valuable memory for perhaps, even
more caching.
Achon is offline   Reply With Quote
Old 12-03-2012, 08:11 AM   #12
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
Re: A huge grid world

I might have found a solution:

It implements a java.util.Map interface for a disk based map, with cache. It's the fourth version of a 10-years old library called JDBM, first born to manage astronomical data (millions of records). It supposedly scales well for maps smaller than 10^8 elements, which is fine for me considering that I would work with less than 30 millions rooms at most. I guess the disk footprint is going to be massive though :P but it shouldn't be a problem. It supports indexes and a few characteristics from relation DBs.

My idea is this. I have a proper relational database, H2, with all the data. It's going to be huge but I can enable compression, encryption, backups and the such. I'll try to make the data compact enough without being unanderstandable.

Than, at startup, I start populating the disk-backed hashmap, but only with the "necessary" entities. As the players log in, more entities are put in the map. In this way, after the inital little lag, if anything, the most used parts of the world would be loaded into the hashmap. The map will "commit" to the disk only when the objects go over a particular threshold, so the RAM is well under control. At that point, the disk and memory usage is transparently managed by MapDB so I don't have to care anymore.

When it's time to save the world, I iterate the map and if something needs to be eliminated/added to the DB, I do. Than I update the existent records, using referential integrity to be sure everything is how it should be (no links to non-existent objects, etc). In this way I always have a compressed and coerent data in case during the execution of the MUD something goes bad.

EDIT: @Achon, I have looked into Berkely DB, yes, and it might be another solution. I guess I'll have to experiment..but I have to say I much prefer to work, into the MUD, with specialized classes (Room, Mob, Player with their appropriate inheritances) for the world stuff, and I don't think I'll be able to do it with BerkelyDB unless I create those classes on the fly OR I store the serialize the objects into the DB which is, in my opinion, like killing the whole idea of a relational DB.

A decision will be made but for now I think I'll go with the disk-based map, because I don't have to change anything in my code, just the instantiation of the map itself. I really hope it is stable and efficient how the author says.
koteko is offline   Reply With Quote
Old 12-03-2012, 10:08 AM   #13
plamzi
Senior Member
 
Join Date: Nov 2009
Home MUD: bedlam.mudportal.com:9000
Home MUD: www.mudportal.com
Posts: 292
plamzi is on a distinguished road
Re: A huge grid world

If I was designing a MUD world from scratch, I would probably go with a hybrid solution. I would split zones into "travel" vs. "dungeon", lay out the travel ones on a consistent grid (using the grid to ensure spacial consistency only, with only some of the travel rooms actually existing, or being generated on the fly if needed). Then I would use different rules for actual dungeon areas, not enforcing spacial consistency. The end result would be very much like the world of the Morrowind / Oblivion / Skyrim games.

The advantage of not enforcing spacial consistency in a dungeon is that you can design it in a way that the user can experience in an efficient way (e. g. dropping them at the entrance of the zone when they are "done").
plamzi is offline   Reply With Quote
Old 12-03-2012, 10:17 AM   #14
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
Re: A huge grid world

Uhm, but that can be done in any case, can't it? I can put a portal at the end of the dungeon that, when entered, redirect me to the entrance room. I'd like to implement "linked" objects, ie a portal linked to another portal, so that if you move the entrance portal for some reason (enlarging the dungeon, for example) the "end portal" would still be linked to it.

The only thing that really bugs me off is to have millions of "filling rooms" 99% of the time empty and not visited once. Thanks to the discussions here I'm now sure I don't want to load them unless really necessary, and creating them on the fly using already-loaded templates is an efficient enough approach I guess. Then I'll cache them to avoid too much creation overhead, and only in very extreme cases (1000 users, a miracle, and they all decide to massively explore the world) the disk caching will kick in.
koteko is offline   Reply With Quote
Old 12-03-2012, 11:56 AM   #15
Newworlds
Legend
 
Join Date: Aug 2007
Name: NewWorlds
Home MUD: New Worlds
Posts: 1,425
Newworlds will become famous soon enoughNewworlds will become famous soon enough
Re: A huge grid world

I'm still confused at the fact that you want to load 5 Gigs worth of rooms into your game that uses maybe (on a good day) .001 % of that. What gives man. Since when does a text MUD need more than 500 megs at most for the entire game. It would be like prepping for 10000 players and loading 10000 player objects just in case 10000 players wanted to log on.

Doesn't anyone remember the days of assembly when we had to code everything into 32K? Bunch of sloppy memory hogs out there methinks.
Newworlds is offline   Reply With Quote
Old 12-03-2012, 12:03 PM   #16
plamzi
Senior Member
 
Join Date: Nov 2009
Home MUD: bedlam.mudportal.com:9000
Home MUD: www.mudportal.com
Posts: 292
plamzi is on a distinguished road
Re: A huge grid world

"Portals" are only the simplest link that "freeform" MUD rooms can have. There's also compression, loops, "multi-jumps", whatever you want to call them.

If portals are the most you're willing to bend the spacial rules, then sure, you can enforce a grid throughout and add a single special case.

A division between "travel/roam" and "dungeon" can be useful even if you enforce a grid for both (with small exceptions). E. g. a "roam" area will create a room dynamically if a player strays from the beaten path between A and B, whereas a "dungeon" will block them.
plamzi is offline   Reply With Quote
Old 12-03-2012, 01:26 PM   #17
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
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!
koteko is offline   Reply With Quote
Old 12-03-2012, 01:42 PM   #18
koteko
New Member
 
Join Date: Mar 2012
Posts: 20
koteko is on a distinguished road
Re: A huge grid world

I'm actually quite sure I want to avoid things like labyrinths and loops like I used to see in Diku-style MUDs. I'd like the world to be well mappable and, as said, colonizable, and the "physics" of the world to be coerent and deterministic.

The magic system allows the users to create these same effects, temporarily (for example, somebody can install a trap door for his room, and anyone who enters it get teleported to a cage at the top of his tower. An expert mage can instead disable it, reverting it to the normal effect).

I will think however if it makes sense in my case to create such a distinction. Thank you for pointing that out
koteko is offline   Reply With Quote
Old 12-03-2012, 04:01 PM   #19
Achon
Member
 
Join Date: Oct 2011
Posts: 40
Achon is on a distinguished road
Re: A huge grid world

If it applies to your DB solution, you might also consider organizing your
records in a way to help increase the performance of the underlying disk
caching system. Like dividing the world into 10*10* sectors or some other
fancy pants scheme to designed to improve coherency by grouping adjacent
rooms (and other closely related info) into discrete units.
Achon is offline   Reply With Quote
Old 12-03-2012, 05:45 PM   #20
camlorn
Member
 
Join Date: Aug 2011
Posts: 144
camlorn is on a distinguished road
Re: A huge grid world

Well, not exactly. Sectors are probably pointless-ish here.

I mean, 99% of the world the way you want it won't be seen or used. Avoid sectors, and to be quite honest, "towers" can be built by allowing one to simply extend beyond the "top" of the sky. That eliminates rather a lot of rooms right there.

I honestly think that most players won't admire this kind of set-up. It depends on what you want from it specifically. If this is going to be hack and slash with building, well...nononono.

I have considered making an rts mud, crossing it with godwars2 like movement (it'd be a hybrid, because you are a god, and if not inhabiting a body move around by rooms which are x*x regions, kind of thing). In my use case, which is debateably too complicated to be fun, the fact that you have a 10x10 kingdom or larger is a core component of gameplay--worshippers kind of thing, I never started it so I didn't work out the thematic details. Every player gets one, and the world expands with the players (again, sort of; I'd not let the map become some wierd shape).

The problem here is this. Unless building is a core part of gameplay, i.e. newbies will be doing it from day one, and hack and slash is supported by building, there's no point to so much space. You'll have the classic problems muds have these days: a huge world and 10 players, who never run into each other. If players can build the world, and if you want a space constraint i.e. all rooms are 1 unit, don't do it this way. You don't need all this, and I'd say over 99%, maybe even as much as 99.9% of all your rooms are going to be generic template rooms that no one will care about.

Minecraft works because there is a 3d graphical representation. If I go build a mile-high sign that says something, or some sort of ALU, I can get the big picture or see my ALU working (well, not me, but). This doesn't work so well in muds. Ascii diagrams can show at most one layer and at most 2 dimensions. It's like the hypercube, the closest way to conceptualize it is a 3d cube moving through time, but we can only see the limited 3d cube (I know that that's not what a hypercube is, not really. It's only a 4-dimensional cube, the 4th dimension doesn't have to be time, but for our example...), we can't see the part of it that conceptually extends into the 4th dimension. In a mud, the most graphical information you can ever give is 2 dimensions at once, and you run into the same problem. You can show a 2-dimensional cross-section of a 3-dimensional object, no more. You've now lost either height or width, can't have both at the same time.

From a technical standpoint, this sounds like an awesome mud. Great programming skill, great tech usage, etc...but step back a moment. How sure are you that it will be "fun"? How sure are you that players will care?

Perhaps, play godwars2. I totally see why this sounds cool, but I also totally see why KaVir eventually abandoned the room. Rooms are great for builders or for any building-like abstraction, but for a world this size, maybe it's time to consider being the second roomless mud. I'm only keeping rooms in my "dream" mud that I'd like to program one day because it makes rts-like stuff possible. My specific idea is the "region", which is like a room but also like a little miniature godwars2 environment, wherein you can move around in 2d space (I considered godwars2 clone. But if you have a "region" with "features", it's possible to do some...unique things).

As to the actual programming, sectors work to an extent, yes. I just don't think that there's a point in diong all this stuff. The comment about muds typically not going above 200mb is true in most cases, and we are talking large, quality muds here. I believe Discworld, one of the largest still-existing muds, is somewhere around 2 gb, but that's with hundreds of players running around generating loot and leaving it about, etc.

If you can find code, and if it was ever even released, maybe look at empiremud.
camlorn is offline   Reply With Quote
Reply


Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 01:14 AM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2022