[Tavish]

Perhaps not advanced, but moreso questions regarding the wilderness concept.

Mud Wilderness - A vast locale that usually depicts the space between more concise areas.  Descriptions are either simple repeats of the same lines or dynamically generated.   Normally handled via coordinates and players have a much greater range of movement (no predetermined "only" path from A to B).

I was trying to look into the history of the wilderness system, perhaps the first known designs, the first public implementations.  Has it evolved much, or are there simply different takes on the same idea?

As I understand it there are some implementations that are infinite??  In what ways would this be handled, not from the coding aspect, but from the world design (outer space aside)?  

Obviously, with so many of the "new generation" of muds being devolped implementing a wilderness system, the idea is here to stay.  Just how far it can be taken is something that I find very intriguing.  Any insight would be apprciated.

[Lodes]

I am not really sure what you mean in your post but I guess I can share some of the things I am using my wilderness code for. (Thanks Samson for the base code).

My mud is derived from the SWRiP codebase, and it is based in the star wars universe. Basically the wilderness helps me, to implement an entire planet that the player may go through using a speeder. It also helps me into developing the atmospheric flight. Ships can now go in the atmosphere and bomb cities and such. Yet they better watch out for planetary defenses.

The wilderness code also helps me for big asteroids or undiscovered planets. The player, let's say he is an explorer, finds an unknown planet. There if can bring enough ressources through his freighter, and droids to work or npc's he can have himself built his own little hq and such while nobody knows that he has this secret base.

Also the wilderness system helps me to develop a new weather system. Each planet has its own weather, and by typing weather you could see an ansi map showing you the different storms and such moving around. Let's say the player is on Tatooine. He sees a sandstorm coming towards him. His sihp which is landed on the desert will probably get covered with sand at least 20 feet deep. What can he do? that's to the player to find out.

I am also using the wilderness system, to make the planet of Coruscant, which is really a huge city except around its north pole. Basically it helps me to have multiple speeder lanes, and buildings on the sides. Navigation is as easy as driveto main spaceport but yet can be as hard as climbaltitude, turn right. (It is not really sure how we will do it yet, as you can see ).

Now I hope I have somehow told you how we are bringing the wilderness system to a new level. Really I think it is a great way to represent what the player can see without having to use this roomless feel in which I personally don't feel really comfortable.

[KaVir]

Originally Posted by As I understand it there are some implementations that are infinite??

Well you can't really have an infinitely big wilderness/world, but you can certainly have some pretty large ones - for example in my implementation everything is measured in feet, yet the main plane of existence is 2.7 times the diameter of the earth, and it would take 136 years (real time) for a character to walk all the way around it.  It didn't need to be that big, but that's just the way it worked out (with a 32 bit integer representing a coordinate location - using a 16 bit integer would have resulted in a world only 1 mile in circumference, which was just too small for what I wanted).

Of course if I really wanted to, I could quite easily change the coordinates to use 64 bit integers, giving me a world over 92.5 trillion miles in diameter.  To put that in perspective, that's over a hundred million times the diameter of the sun, and over ten thousand times the diameter of our solar system.  If you dug a tunnel through the centre of such a world, it would be around 3.5 times the distance between our solar system and the nearest star.  The time it would take for a character to walk all the way around such a world would be roughly equal to 40 times the currently estimated age of the universe.  For all intents and purposes, that's as good as "infinite".

Originally Posted by In what ways would this be handled, not from the coding aspect, but from the world design (outer space aside)?

When you're talking about extremely large worlds like I described above, it starts becoming unrealistic to map stuff yourself - or even to save automatically generated terrain features.  There are simply not sufficient resources to do this, so you need to cheat.

The approach I would recommend is to use psuedo-random numbers calculated from coordinate positions and a global seed to calculate regular terrain features, and then temporarily save changes to the world (so they would come back after a while) - persistence is unfortunately not really feasible when you're talking about such a large world.  You could then place your builder-created places of interest at various locations within the overall world, and even allow players to create such places themselves if they wished (for example, building a castle).  Other places might be randomly generated by the mud to represent mob villages and the like.

[Molly]

Some of the best dynamic descs I've seen for a Wilderness grid were made by a coder named Noximistic, who posted some examples on this board. I don't remember the name of the mud, but he might still be around somewhere. Or the thread might, in the back-up Synozeer keeps.

I use the wilderness code quite a bit myself, mainly because I like the nice-looking maps you get from it, but since I neither like repeated nor code-generated descs much, I tend to add individual descs manually, after setting up the grid. (unless the zone is some typically desolate area, like outer space, a prairie or the middle of an ocean of course, then I think repeated descs are in character). Even with manually adding descs the Wilderness code still is an extremely fast way of creating a zone, compared to the 'normal' way of building.

[Ytrewtsu]

The mud is A Dark Portal and the coder's name is Noximist. I don't know the exact address but I am sure it is listed somewhere. Plus I totally agree with Molly, her descriptions are awesome. She and Tavish sold me on the idea (although I still don't have it coded yet).

Ytrewtsu

[Tavish]

Unfortunately, although my description and wilderness generator that we talked about during our discussion do very well for what it was designed to do, that being the basic overland type design that added depth between the hand-built areas, I am still struggling with the same questions I had then.  KaVir basically touched upon them in his post, sorry if I take anything out of context, but it hits very close to the mark of my debate.

Originally Posted by ...for example in my implementation everything is measured in feet, yet the main plane of existence is 2.7 times the diameter of the earth, and it would take 136 years (real time) for a character to walk all the way around it. [snip] When you're talking about extremely large worlds like I described above, it starts becoming unrealistic to map stuff yourself - or even to save automatically generated terrain features.  There are simply not sufficient resources to do this, so you need to cheat.[snip] ... persistence is unfortunately not really feasible when you're talking about such a large world.  You could then place your builder-created places of interest at various locations within the overall world...

It seems with a scale this large that distances between the hand-built areas would be so great that players would only visit a small sampling of the in a lifetime, or that you would need so many areas to fill in the wilderness that it would be a very significant drain on your resources.  Are you relying very heavily upon mob villages or other code-generated mini-areas?

If the wilderness is unique enough that the players can explore and adventure through it much the same as they could a "normal" hand-built area, I would think that a MUD could be viable without any premade areas.  Having the code generate outposts, dungeons, along with player empowerment to build the world as they go could lead to a very interesting dynamic of players.

[Molly]

Sorry about the mistake with the name, I must be getting senile.

That was all in all a very interesting thread, even though our respective goals were a bit different.

What I don't understand in all this is why you guys need to make the grid so large? Sure, it sounds cool to say that your world is more or less 'endless', but what's the meaning with it? If the distance between the 'real' areas gets too big, the players will just lose interest and give up.

A mud is meant to be played, right?
So why not adapt the size of the grid to what is feasible for a player to handle?

[KaVir]

Originally Posted by Tavish It seems with a scale this large that distances between the hand-built areas would be so great that players would only visit a small sampling of the in a lifetime, or that you would need so many areas to fill in the wilderness that it would be a very significant drain on your resources. Are you relying very heavily upon mob villages or other code-generated mini-areas?

The number of hand-written locations will be small, and scattered around the landscape, but they won't be at the "extreme" lengths of the world. These are specially designed quest zones, which each player can complete only once. Other locations will be automatically generated.

Originally Posted by Molly wrote: What I don't understand in all this is why you guys need to make the grid so large?

As I already explained, that's just the way it worked out because of the scale I was using. I could artificially limit it, but that would require extra code, so why bother?

And please don't overlook the fact that this is a fantasy setting. While it would certainly be unrealistic to expect players to walk hundreds of miles between cities, there are plenty of other options available to them, ranging from horses to flying to teleportation...

[Kallian]

Originally Posted by When you're talking about extremely large worlds like I described above, it starts becoming unrealistic to map stuff yourself - or even to save automatically generated terrain features. There are simply not sufficient resources to do this, so you need to cheat.

Ah. But you can certainly ensure the same automatically generated features and descriptions each time. You said you could easily use a 64 bit integer instead of a 32 bit integer. You could use half of it for room coordinates as you are doing now, and half of it as descriptor flags.

A subroutine could be written to turn the 32 bits of descriptor flags into a full-featured room description, and each room could have the same terrain and description each time somebody visited it.

Not that you'd really want or need to do this.. I don't think it would add any value to the gameplay unless you're going for a completely dynamic world, but it's certainly feasible.

[KaVir]

Originally Posted by Ah.  But you can certainly ensure the same automatically generated features and descriptions each time.

Indeed you can - by using psuedo-random numbers to generate those features, as I described in my earlier post.  That way you can ensure the features and descriptions remain the same without any resource overhead.

Originally Posted by You said you could easily use a 64 bit integer instead of a 32 bit integer.  You could use half of it for room coordinates as you are doing now, and half of it as descriptor flags.

Unfortunately no, you couldn't.  What you describe is indeed a workable solution (and bares similarities to one which I've actually implemented in the past) but as I said earlier, there are simply not sufficient resources to do this for the huge worlds being discussed (although you could use it for a tiny section of the world).  The room-based implementation I mentioned previously was barely over a billion rooms in size, and even then it had the potential to run into serious resource problems.

The 32 bit integers (for coordinates) are stored by each thing within the mud for it's x/y/z coordinate location, relative to whatever it's inside of.  Bare in mind that these are not "room" coordinates - because there are no rooms (although arguably you could say the world was a room).

[Ytrewtsu]

Out of curiosity did you use an actual sphere when generating these rooms? I cannot visualize how you would generate a sphere using traditional room exits (unless some were either not connected in some directions or connected to the same room).

Ytrewtsu

[KaVir]

Originally Posted by Out of curiosity did you use an actual sphere when generating these rooms?

I assume you're referring to the room-based implementation I just mentioned in my previous post, rather than the roomless model I've been talking about earlier? It was not a sphere, no - I suppose the world would be better described as a donut shape. Basically it was 51200x51200x40 grid (with the last dimention representing height).

Originally Posted by I cannot visualize how you would generate a sphere using traditional room exits (unless some were either not connected in some directions or connected to the same room).

It didn't use room exits, it was a grid.

[OnyxFlame]

In the mud I play, the wilderness is a map of ascii "hexes" showing various terrains. The cities and various other locations are shown in certain hexes and the location of everything is static. (In recent times, the amount of travel in each hex has been added to its text desc. Travel density determines the frequency of critters that appear and the amount of resources available.)

Anyway, back to the main point. The world is theoretically infinite. As far as I understand the code, hexes which haven't been in use for a while are flushed from the system and regenerated when someone enters them. You can swim any direction in the ocean which surrounds the landmasses, and the game will keep creating ocean hexes for you to travel in up until the point you get so far out that the mud crashes, heh.