Member Discussions

Greetings,

after a few years of absence from the MUD-scene I'm doing a comeback with a new codebase written in Java.
After reading the posts about the Perlin Noise Algorithm I took the opportunity to implement it.

But, what happens when you have a world which consists of 2^32*2^32 rooms?

Problem areas:

1) Players getting lonely because the world is huge and they're small.
2) When do NPCs spawn, and where? (There's no reason to spawn an NPC in a room which is 1237123 miles away from the nearest player)
3) Same goes for items

Possible solutions:
1) Implement teleportational systems and/or telepath-systems to allow the players to intercommunicate and/or travel fast to specific locations.

2) Implement some sort of random-encounter-system and/or only spawn NPCs in the vincinity of players.

3) Only spawn items if players are in the vincinity.

Any 2 cents would be appreciated, ideas are highly welcome, and criticism even more!

My first thought is make each "room" 1 foot x 1 foot, so you have "squares", instead. You could step, walk or stride to move 1, 2, or 3 squares. A room description would be linked to all the squares that made up the floor. Exits could be sized... you just need ways of dealing with them as groups.

Ah, clarification.

The whole world is outdoors, houses and other stuff are considered to be items within the room, and since all physical things can contain other physical things smaller than the container, the player can actually enter the house.

I don't have exits as such, players are free to move in what direction they prefer although swimming is heighly encouraged wen going into water, that also goes for mountains and climbing.

The room description is linked to the result of the Perlin Noise-generator and the contents of the "room" (I prefer to call it a geographical area).

You can't store 2^32 rooms in your game's address space (not on a 32 bit machine, anyway), so you're probably planning to generate rooms on the fly when a player either nears or enters the room. That's the time to decide whether any NPCs should be loaded there.

I once designed a system which flagged generated rooms, generated mobs, and generated items as temporary. The game would destroy temporary rooms and their contents after a delay, so long as no permanent entities were within. That allowed me to save a lot of memory while providing the illusion of a large, consistent, and well-populated world.

If you generate the rooms on the fly however, how would that make the game even seem consistent? If the room isn't the same when I travel back to a place I was before, and it is somehow changed by the random generation of the room, it ceases to seem consistent.

I suppose you could explain this away as your perception of the "room" being different, so long as the forests remain forests and the deserts deserts.

Hrm...

My two cents, something to chew on,

Vopisk

Use a consistent seed for the random generator so it creates the same stuff for
the room at a given location each time.

"You can't store 2^32 rooms in your game's address space (not on a 32 bit machine, anyway), so you're probably planning to generate rooms on the fly when a player either nears or enters the room. That's the time to decide whether any NPCs should be loaded there."

Actually, it might be purely philosophical, but the only thing that needs to be stored are value-pairs Location/Content, the "rooms" themselves are merely a noise generated by X/Y/Seed.

But when do I spawn NPCs and/or Items? In rooms nearby players, when they move? I guess I could make a service which runs every once in a while and removes all "temporary" items/NPCs which are far away from any players.

I like it.

"If you generate the rooms on the fly however, how would that make the game even seem consistent? If the room isn't the same when I travel back to a place I was before, and it is somehow changed by the random generation of the room, it ceases to seem consistent."

The Perlin Noise-algorithm guarantees that given the same coordinates and the same seed, the same result is always returned consistently.

"I suppose you could explain this away as your perception of the "room" being different, so long as the forests remain forests and the deserts deserts."

Procedure:
We have a Location (a location is an X and a Y)
If we stuff that into the noise-generator, we'll get Z
We interpret Z as a type of Terrain depending on the value.

Given the Location, we can find out if that location has any content (players, npcs, items).

Now we have a Terrain type, a Location and a list of content.
If we retrieve the Time and Weather information we can generate a description of the room even based upon the perceptiveness of the character viewing the "room".

Do I make sense?

> Procedure:
> We have a Location (a location is an X and a Y)
> If we stuff that into the noise-generator, we'll get Z
> We interpret Z as a type of Terrain depending on the value.

That part is fairly easy - the difficult part is making it so that the terrain is laid out in a logical fashion. It's not so hard to lump together chunks of mountain and forest, but it gets really tricky when it comes to things like rivers...for example, how will you prevent a river from flowing in a circle, so that it has no source or exit?

Excellent question KaVir, I see a couple of different solutions to that.

1) I currently employ a couple of different terrain types:
MOUNTAIN, FOREST, PLAINS, SHORE, WATER
they could easily be divided into HIGH_MOUNTAIN,
LOW_MOUNTAIN, etc. Which means that I do not call the
bodies of water anything else than just Water ;)

2) A river/stream which flows in the shape of a circle may
be a lake but with a huge island in it, or it could be a
ditch, or something flaky with the gravitation...

3) One could have a collection of polygons representing the
rivers in the game, and put them "on-top" of the
getTerrain()-function so that the noise-function
generates all but the rivers, and then you actually have
a map of actual rivers, this defeats the purpose of
having 2^31*2^32-planetlike world, since it'd take quite
some time to map out all the rivers and streams.


I guess it boils down to what you'd like to call the room, and if rivers have a current which can pull you downstream.

Also, I've noticed that using values close to 0.0 as water gives a better looking map. Unfortunately this aged forum software doesn't allow for posted images, else I could have sent in some samples (I made a map-generator which generates an image where each pixel is 1 room, in a color that resembles the room, so one can easily tweak the noise-interpretor to get a better looking world.

Anyhow, this is becoming a long post so I'll stop writing here. Do you have any suggestions for a solution KaVir?

Best regards
/Varnak

Do I make sense?

Yeah, I totally didn't think of the idea of using a consistent seed to always generate the same results with computers and their psuedo-randomness and whatnot. However, I still have to question though, would this lead to the same MOBs always loading in the exact same manner, or would you actually randomize that so that while some mobs (shopkeeps and the like) do appear where they're expected, you always get the chance of a random encounter something akin to the early Final Fantasy series?

I think I agree with KaVir that there are some hazards to using a system like this, I'm still working on the basic idea of my "world generation idea" but the basics go like this (maybe someone has comments or has/can do it, who knows). What I'm looking into/trying to figure out how to do, is read a BMP file by pixel. Based on this pixel, given that we know what color it is and we know what our colors are supposed to do, we can achieve excessively comlex world generation on the fly all based upon a particular picture that someone has drawn (hypothetically). A first pass of BMP1.bmp could give us all of our land/waters and their basic terrain types, then a pass of BMP2.bmp could give elevation to all those same rooms, etc... etc...

Like I said, it's just an idea I've been toying around with for a while, but I think there's promise. From my experiments with the files themselves and searching on the internet, I'm somewhere close to determining how to extract the header information out and use it as I see fit, after that it's all a matter of manipulating information in four-byte chunks (color codes, stored sequentially in a structured array form). Just have to remember that things are sorted from the bottom left, to the right and up!

Anyway, my two cents, something to chew on,

Vopisk

"Yeah, I totally didn't think of the idea of using a consistent seed to always generate the same results with computers and their psuedo-randomness and whatnot. However, I still have to question though, would this lead to the same MOBs always loading in the exact same manner, or would you actually randomize that so that while some mobs (shopkeeps and the like) do appear where they're expected, you always get the chance of a random encounter something akin to the early Final Fantasy series?"

Well, the solution to this problem is to introduce 2 different states on Items and Mobs, TRANSIENT (T) and PERSISTENT (P) where T-stuff (mobs and/or items) will be removed from the world when they "time-out", and P-stuff always remains until reboot.
T-stuff manipulated by players could be changed from T to P so that they will not be removed from the world.
Or you could have a system-service doing a full wipe of T-stuff at random intervals.

Random encounters would be incredibly easy to implement using this system. Every time a player would move from one room to another, just check the terrain-type of the new room, and go through some randomized-load-function which only loads mobs that occur in that type of terrain, or even better, also take the Location (X/Y) into to consideration to make certain mobs only spawn in certain places in the world.

"I think I agree with KaVir that there are some hazards to using a system like this, I'm still working on the basic idea of my "world generation idea" but the basics go like this (maybe someone has comments or has/can do it, who knows). What I'm looking into/trying to figure out how to do, is read a BMP file by pixel. Based on this pixel, given that we know what color it is and we know what our colors are supposed to do, we can achieve excessively comlex world generation on the fly all based upon a particular picture that someone has drawn (hypothetically). A first pass of BMP1.bmp could give us all of our land/waters and their basic terrain types, then a pass of BMP2.bmp could give elevation to all those same rooms, etc... etc..."

I see where you're coming from. I actually built such a system a couple of years back. I really liked the idea of "painting the world", and the reason I moved to the "perlin noise-camp" was because with perlin noise there will be no "end" of the grid (what happens when a player decides to go west from 0:0?) and the fact that you have to have the whole world in memory.

With Perlin Noise you only need to store room contents, not the rooms themselves.

Best regards
/Varnak

I'm actually not thinking of storing the whole world in memory. Rather, "painting the world" would be simply my mechanism to create the world, at which point I would be able to load which sections of it I so desired (at least theoretically). Also, more than likely, I would adop the method oft employed by MUDs by having continental land masses end at large bodies of water in all four cardinal directions, then if they really want to sail for days to go around the world and come up on the eastern seaboard, well then, I suppose they can.

This also allows for the possibility of later adding in new continents or new areas like "The Lost Isles of Bubbltoes!" by randomly dropping the area into the ocean somewhere.

Quite frankly, I don't think a mud really needs to be 2^32x2^32 in dimension. What I have in mind is a lot of at least slightly different than norm systems that I want to get working in a very small world first, and then expand from that. Something I was thinking of with this "Paint the World" system is that for custom player housing, they could merely go online to the website let's say and interact with the OLC tool that let's them lay out their rooms and whatnot in a graphical manner and then implements it into the MUD as the player has dictated. Something like designing blueprints I suppose one might say.

Anyway, yeah, I'm all foggy from lack of sleep so probably not making much sense,

Vopisk

No, you're making sense actually.

The difference is that you see "rooms" as actual rooms, within houses and stuff, whereas I see "room" as a square of horizontal geographical space. :)

The thing is that I _really_, _really_ _hate_ when not able to walk where I want to walk. If I want to step west 123791246278934 times, I should be able to do so, even if it drowns my character, or I fall off a cliff. There should never be an invisible barrier stopping you from moving in a certain direction.

One of the strongest things about noise-based worlds are the fact that you can quickly change the whole world without having to attend to the details.

Cave-items can be spawned in mountains, tree-items can be spawned in the forests, Pidgeons can be spawned litterally everywhere etc.


My biggest concern is how to create a world which is bigger than any other, but yet flows with life, dynamic descriptions, taking surroundings, time and weather into account etc.

Best regards
/Varnak

> Anyhow, this is becoming a long post so I'll stop writing
> here. Do you have any suggestions for a solution KaVir?

Not really. The approach I'm working on allows for limited rivers, but does so at the expense of a less random world. I generate a basic "land/water" map which looks a bit like this:

     ###
    #####    ###
   ######   #####   ###
  #######   #####  #####
  ###### ########  ########
  ##### ########## #########
   ### ###### ##### ########
      ####### #####    #####
      ######  #####     ###
      #####    ###
       ###

It's generated based on each X/Y position, so you only need to calculate the part of the map you're looking at (and a little bit nearby for smoothing), and don't need to save anything.

Each "#" then represents 4 zones (2x2), selecting from a zone list based whether the surrounding characters are land ("#") or water (" "). For example if there is " " to the left, top, and top-left of the "#" and other "#"s on all other sides, then the top-left zone (of the 2x2 which the "#" represents) will be selected from the list of zones which have land in the bottom-right corner and ocean in the other corners, the bottom left zone will be selected from the list of zones which have land on the right and ocean on the left, the top-right zone will be selected from the list of zones which have land on the bottom and ocean on the top, and the bottom-right zone will be selected from the list of zones which have land on all sides.

Each zone consists of 16x16 tiles, each of the 250+ tiles consist of 10x10 plots, each of which is one terrain type and represents one square chain (66x66 feet). Supposing the bottom-left zone faced water to the left and bottom, and land to the top and left - the mud would then select one of the zones from the list of zones which have land on the top-right corner, which would include this:

@@@@@@@@@@@@@@@@@:::::::::::::::
@@@@@@@@@@@@@@@@@:::::::::::::::
@@@@@@@@@@@@@@@@@@@:::^:^^^^:^::
@@@@@@@@@@@@@@@@@@@::::^^^~^^:::
@@@@@@@@@@@@@@@@@::::::^^^~^^:::
@@@@@@@@@@@@@@@::::::::::^~^^:::
@@@@@@@@@@@@@@@:::::~~~~~~~:::::
@@@@@@@@@@@@@@@:::::~:::::::::::
@@@@@@@@@@@@@@@@@:::~::::@@@@@@@
@@@@@@@@@@@@@@@@@@@:~~:@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

So you'd have a small river (~~~) running from a spring in the forest, out into the ocean.

I plan to extend it so that certain '#' will be marked as a "river source" with a direction, allowing the rivers to flow across 3 or 4 zones. But I'll still miss out on really long rivers, and the world may start to look a bit repetitive after a while, because the same zone will be used in different places.

You could use another algorithm to spawn persistent mobs and items. If a mob moves from its spawning point (hunting down a player or something) and is done interacting with a player you can have it move back and once it heals up etc you can have it vanish since it'll spawn back consistently.

I'd discourage implementing the spawning of random mobs and items with a random bonus. It's what most muds do and it results in rather shallow / boring gameplay.

> But when do I spawn NPCs and/or Items? In rooms nearby
> players, when they move?

Pretty much the same issue was discussed on mudlab about a year ago - you might find it of interest: http://www.mudlab.org/forum/viewtopic.php?t=142

*grins*

I think I'll be making 2 different types of world-implementation, one that uses a fixed grid, created from a bitmap, and another using the noise-algorithm, that way I can make the players decide ;)

Would or will the players notice the difference? I think, most likely not.

What I like about the BMP idea is that, if you want a game that takes place in England, you can just feed in a BMP of England, simplified of course to indicate large swatches of "terrain" type and come out with something that quasi-realistically represents Britain in its entirety, including a seaboard that is the exact same length as the real deal (assuming you get your pixels:miles ratio correct).

The idea of implementing such a system for a MUD, in my mind, is to allow easy implementation of actual established fantasy settings, like the world of the Wheel of Time, or Dragonlance or what-have-you. You could basically scan in the map that's included in the front of the book, apply some color here and there, and have a world generated even to the level of border lines for different countries.

I also like the idea of feeding maps of cities in and having all your buildings and whatnot created dynamically rather than hand-built (excepting some details added for the interior and whatnot of course). I think it would be overall easier and yet, at the same time, harder. So it may not be worth it from a development standpoint in the long run.

However, if you're going for something on a planetary scale, or going to have multiple planets and whatnot, I think it would be best to look into the noise algorithm and find a way to make rivers and lakes and whatnot work, because creating believable terrain for a bunch of different planets is going to get real tedious real fast with the BMP idea.

As for your reply to my previous posting, I don't think I was clear enough in my definition of "rooms". My idea of a room is what is in your visible space, so something akin to the immediate 10-20' square around your current location (the relative distance I think you should be able to spot small objects from). However, in using a BMP style as I had proposed and may or may not in the end implement, I was referring to using the BMP to establish basic things like what would historically be referred to as "zones" in the blink of a CPU cycle (exaggerated obviously) but still using a coordinate system for movement and the like.

Also a thought in relation to using BMPs would be the ability to assign elevation maps that overlay on top of our terrain maps to give mountains and valleys real elevatory difference, so that your cliffs are actual cliffs based simply on the pitch of your up or down elevation, which of course, would result in the player having to find a way around or scale the cliff-face, yada yada, ad naseum.

Anyway, more ramblings,

Vopisk

(Comment added by Vopisk on Wed Jun 7 23:15:25 2006)

Edit: Another point in regards to the elevation maps and whatnot. I also had envisioned creating an in-depth weather system that would create actual storm fronts and move them across the world realistically. Using a fixed-size bitmap that stays persistent, one could run the weather system as a seperate task, keeping constant track of what the weather patterns are doing and log it to a database, then having the MUD check against the database to give current weather information. I think this element of persistence would be difficult to maintain in a noise-generated system, but I may be wrong.

Well I'm currently implementing both the bmp-based type and the noise-based type in my Mud (You've gotto love inheritance and polymorphism ;)) and I'll see what I'll do.

What I consider negative is taht if you use the BMP you'll have to have to store X+Y=terraintype somewhere, be it ingame or database (which gives the overhead of relational dbms).

The only real Pro I see for the bmp-idea is that the world is not generated at random, which allows for more customizations.

Although both will suffer from the same problem, if we were to name the rooms, we'd have to map X+Y=Name somewhere too.


I'm leaning on having a preprocessor that takes the bmp and churns though it, producing actual Room-objects containing Terrain-type and Name and stuff, then keeps them in-memory.

The downside is that the world will me ram-limited, but ram is cheap. :p

> The only real Pro I see for the bmp-idea is that the world
> is not generated at random, which allows for more
> customizations.

It allows for three types of customisation though, so it's a pretty big 'pro'.

The first type of customisation is by your world builders, who will be able to create a much more nicely shaped world than you'd get from randomisation. If you're based on the real world, or on an existing theme, then (as Vopisk pointed out) you could use real maps to create the layout of your world, so that they're modelled correctly for your setting.

The second type of customisation is by the players - you'll be able to support a dynamic environment where the players can build cities, burn down forests, dig mines, divert rivers, plant crops, and so on. This can help support many other mud features - it provides resources for crafting systems, side-effects for massively powerful spells, customisable battlegrounds for kingdom-based warfare, and so on.

The third type of customisation is by the mud itself - persistent evolution of the world. Forests can grow, volcanos can errupt, lakes can dry out, rivers can burst their banks and create swamps, earthquakes can leaves their permanent mark upon the landscape, and so on.

All of these types of customisation require data to be saved in RAM (barring some very clever caching) - as well as to disk, if you want them to be persistent. The noise-based approach could save changes to the environment (eg 'burnt forest' would be a savable terrain feature placed on top of the generated forest), but that can easily get out of hand for long-term persistence.

I don't think it's very practical to save the data in bmp format, however. Instead you could create a tool for converting the bmp data to the format used by the mud (and perhaps another tool for generating a viewable bmp image of the world from the mud data).

> Although both will suffer from the same problem, if we were
> to name the rooms, we'd have to map X+Y=Name somewhere too.

I define a name based on terrain type between two points. For example all forest terrain between points 1900/500 and 9100/8500 is named 'Greenleaf Forest', while all river terrain between points -1984/-1320 and 6270/4290 is named 'The Crimson River'.

"The first type of customisation is by your world builders, who will be able to create a much more nicely shaped world than you'd get from randomisation. If you're based on the real world, or on an existing theme, then (as Vopisk pointed out) you could use real maps to create the layout of your world, so that they're modelled correctly for your setting."

This is a really big pro.

"The second type of customisation is by the players - you'll be able to support a dynamic environment where the players can build cities, burn down forests, dig mines, divert rivers, plant crops, and so on. This can help support many other mud features - it provides resources for crafting systems, side-effects for massively powerful spells, customisable battlegrounds for kingdom-based warfare, and so on."

As you pointed out, this can be applied to noise-based worlds also, but it somewhat defeats the purpose of having an algorithm-generated world.

"The third type of customisation is by the mud itself - persistent evolution of the world. Forests can grow, volcanos can errupt, lakes can dry out, rivers can burst their banks and create swamps, earthquakes can leaves their permanent mark upon the landscape, and so on."

True, true.

"All of these types of customisation require data to be saved in RAM (barring some very clever caching) - as well as to disk, if you want them to be persistent. The noise-based approach could save changes to the environment (eg 'burnt forest' would be a savable terrain feature placed on top of the generated forest), but that can easily get out of hand for long-term persistence."

Actually, I've been thinking of only having the gird itself RAM-resident, and then load a room when it is needed, setting an expire-timer on it, and refresh the timer every time an object in that room does something and eventually swap it out to disk/db/whatever media. (If you'd use a 4096*4096-sized grid, you'd eat alot of memory if you'd keep all rooms RAM-resident at all times).

"I don't think it's very practical to save the data in bmp format, however. Instead you could create a tool for converting the bmp data to the format used by the mud (and perhaps another tool for generating a viewable bmp image of the world from the mud data)."

I'd say I don't agree, every tool you create is a tool that you have to perform maintenance on, and I hate maintenance :p. I'd rather use a bmp and an accompaning XML-file (curse-word, I know) or the like to transform the image and the room-metadata (descriptions etc), into Room-objects and store them in a flatfile/db/whatever.

"I define a name based on terrain type between two points. For example all forest terrain between points 1900/500 and 9100/8500 is named 'Greenleaf Forest', while all river terrain between points -1984/-1320 and 6270/4290 is named 'The Crimson River'."

Yeah, but what happens when you cannot contain the forest, the whole forest and nothing _but_ the forest within only 4 points in the grid?

Simple example:

# = your Greenleaf Forest
@ = my Swamp of Nudity
€ = your Forest of the limp rooster

@@@@@@
@##@@@
@####@
@##@@@
#@@@€@
##@@€€

If you'd use 1:0->5:4 you'd accidentally name 4:4 and 5:4 Greenleaf Forest when it really should be Forest of the limp rooster.

> > All of these types of customisation require data to be
> > saved in RAM (barring some very clever caching) - as well
> > as to disk, if you want them to be persistent. The noise-
> > based approach could save changes to the environment (eg
> > 'burnt forest' would be a savable terrain feature placed
> > on top of the generated forest), but that can easily get
> > out of hand for long-term persistence.
>
> Actually, I've been thinking of only having the gird itself
> RAM-resident, and then load a room when it is needed, setting
> an expire-timer on it, and refresh the timer every time an
> object in that room does something and eventually swap it out
> to disk/db/whatever media. (If you'd use a 4096*4096-sized
> grid, you'd eat alot of memory if you'd keep all rooms RAM-
> resident at all times).

If you're using rooms, then obviously those would need to be handled virtually. But it was really the map/grid I was talking about - if the world is very large, you're not going to be able to save all of it. And if you're storing changes within a noise-generated world, and those changes are long-term, it's going to start causing problems as the number of changes builds up.

> > I don't think it's very practical to save the data in
> > bmp format, however. Instead you could create a tool for
> > converting the bmp data to the format used by the mud
> > (and perhaps another tool for generating a viewable bmp
> > image of the world from the mud data).
>
> I'd say I don't agree, every tool you create is a tool that
> you have to perform maintenance on, and I hate maintenance
> :p. I'd rather use a bmp and an accompaning XML-file (curse-
> word, I know) or the like to transform the image and the
> room-metadata (descriptions etc), into Room-objects and
> store them in a flatfile/db/whatever.

Once again I'm not talking about rooms, but the map itself. You're going to need to convert the bmp into mud-usable data at some point anyway - but it's likely to use a lot more memory to store a bmp in memory than to store a map. Plus there's the fact that the bmp will look a bit iffy for display purposes if it's also doubling up as mud data, because you'll need slightly different shades of blue depending on which direction a river is flowing, etc.

> > I define a name based on terrain type between two points.
> For example all forest terrain between points 1900/500 and
> > 9100/8500 is named 'Greenleaf Forest', while all river
> > terrain between points -1984/-1320 and 6270/4290 is named
> > 'The Crimson River'.
>
> Yeah, but what happens when you cannot contain the forest,
> the whole forest and nothing _but_ the forest within only 4
> points in the grid?

It rarely happens - it's only occurred a couple of times, with rivers. In those two cases I simply defined a second section of world with the same name.

"If you're using rooms, then obviously those would need to be handled virtually. But it was really the map/grid I was talking about - if the world is very large, you're not going to be able to save all of it. And if you're storing changes within a noise-generated world, and those changes are long-term, it's going to start causing problems as the number of changes builds up."

Yeah, so we're actually talking about some kind of caching-mechanism to load and unload rooms as needed, persisting the changes made aswell.

"Once again I'm not talking about rooms, but the map itself. You're going to need to convert the bmp into mud-usable data at some point anyway - but it's likely to use a lot more memory to store a bmp in memory than to store a map. Plus there's the fact that the bmp will look a bit iffy for display purposes if it's also doubling up as mud data, because you'll need slightly different shades of blue depending on which direction a river is flowing, etc."

I tink we're talking past eachother here, I'm with you on this one :)
But I don't like to be dependent on external applications in order to be able to alter the world. :/

"It rarely happens - it's only occurred a couple of times, with rivers. In those two cases I simply defined a second section of world with the same name."

I'll take your word for it ;)



I think I like where we're going with this. But I still see somce concerns:

1) What happens if the player tries to walk over the edge of the grid?

2) Thought about implementing currents in seas?

3) What do you think about the Transient/Persistent-idea? (Mentioned earlier in the thread)

4) How big grids have you've experimented using?

> I think I like where we're going with this. But I still see
> somce concerns:
>
> 1) What happens if the player tries to walk over the edge
> of the grid?

There are three possibilities I can think of:

a) The grid wraps around - walk off one side and you appear on the other.

b) Have a default terrain type outside of the grid - probably ocean, although in some cases it might be vacuum, lava, air, or something else. I use this for player home planes.

c) Use randomly/noise-generated terrain outside of the grid - this is the approach I'm using.

> 2) Thought about implementing currents in seas?

Could do, although personally I wouldn't bother, except for things like whirlpools and tides. Players already have enough hassle crossing rivers because of the currents.

> 3) What do you think about the Transient/Persistent-idea?
> (Mentioned earlier in the thread)

I only bother with transient stuff, personally, except for a few special cases. I'm not so struck on the suggestion that "P-stuff always remains until reboot" - IMO if an object or mob is supposed to last until a reboot, it should still be there after the reboot as well.

> 4) How big grids have you've experimented using?

I'm currently working on one 800x800 pixels, with each pixel representing a 660x660 foot tile (consisting of 10x10 terrain plots). So basically it'll be 100x100 mile section of custom-built landscape, with the rest of the world randomly generated.