27 Apr, 2007, Skol wrote in the 21st comment:
Votes: 0
I hear you, that's my initial feel too heh. I'm used to thinking of certain geographic areas, all of them actually on one large continent too.

You know though, that kind of building like we're talking of, combined with something like a generated wilderness code, you could have some seriously spacious worlds, then the only 'old style' areas would be the areas of interest, the rest simply old ultima style walk through with random encounters (I don't build like I type btw, holy run-on sentences ;p).

I've often thought about that though, using wilderness as the 'grid' and attaching areas as the focal points etc. I've just never had the time to write up a wilderness code heh. (aka, generated forests, seas etc)
27 Apr, 2007, Metsuro wrote in the 22nd comment:
Votes: 0
Yes basically a planet would have just a room name, with coords, a generic room description, and then its exits. But I'd rather much like to have all physical features, which I'd have to keep cause it shouldn't just randomly generate a different planet is a player constructs a spaceport on said planet, which on the planet scale would be like a room, for the port itself and then any extra buildings. And for the ground-rot thing my problem is should it be removed, or should I let it just sit there till someone picks it up is it more real to have it disappear or for it to remain? And I dont exactly have the talent required for most of these things, I'm still learning.
27 Apr, 2007, Conner wrote in the 23rd comment:
Votes: 0
As I understand it, the wilderness code is based on image files, not really randomized, so your world(s) would still be static even in the wilderness regions.
28 Apr, 2007, kiasyn wrote in the 24th comment:
Votes: 0
Depends on the wilderness code you use =)
28 Apr, 2007, Metsuro wrote in the 25th comment:
Votes: 0
If I did it, I wouldn't use a form of image to do it, I'd just have it something like check a room type if its a mountain it'd be displayed as a ^ but then that goes into a whole mess of how to store the information and get it, as a player is walking and looking at the map. Easiest way to do it I could think would to give each room a coord, and then so many distances from player will be check in like say if your at 0,0 then it'd check 10 spaces in each direction and display the data it had to and then it'd be done, but the only place I've seen this is on a MOO cause even IRE i'm pretty sure uses some form of image for theres.
28 Apr, 2007, Conner wrote in the 26th comment:
Votes: 0
AFAIK, AFK uses image color mapping to achieve it's wilderness code whereas to preset each room by type you're back to using up vnums and building the old way, though I could see building only select rooms and letting the code generate surrounding rooms based off of those rooms, but I'm not sure I can see how that'd be beneficial or even preferable to just drawing a bitmap for the basis or using normal static rooms… unless your code was dynamic like KaVir talks about where it'd plot viable paths for thse who are walking and calculate wind patterns for those who are floating/flying as well.
30 Apr, 2007, Guest wrote in the 27th comment:
Votes: 0
My wilderness system only uses the image files to store the data offline. Once loaded, it all goes into a static memory table of sector types. When a person is out in the wilderness, it's handled in a single real room vnum and the X/Y location on that map is updated each time the person moves in a different direction. The display radius can be as small as 2 spaces in the dark with no light, and as large as 14 if using a wizardeye type spell. And for special cases like our skyship system you get a map display that fills up most of a 24x80 display which is typically only seen by immortals in normal cases. Yes, it displays mountains as ^ in a greyish color. Hills as a brown ^ etc. So obviously it is best used by people who play with ANSI enabled.

It's a fairly crude system, but it works nicely for us and does exactly what was wanted at the time. Nothing more. Though it can of course be expanded upon to become more dynamic, and there have been a few people who have looked at making it work for a space travel system.
30 Apr, 2007, KaVir wrote in the 28th comment:
Votes: 0
Samson said:
Yes, it displays mountains as ^ in a greyish color. Hills as a brown ^ etc. So obviously it is best used by people who play with ANSI enabled.


It strikes me that an increasing number of muds could benefit from a custom client capable of displaying graphical tiles instead of ASCII characters…
30 Apr, 2007, Conner wrote in the 29th comment:
Votes: 0
KaVir said:
Samson said:
Yes, it displays mountains as ^ in a greyish color. Hills as a brown ^ etc. So obviously it is best used by people who play with ANSI enabled.


It strikes me that an increasing number of muds could benefit from a custom client capable of displaying graphical tiles instead of ASCII characters…


Actually, I'd go as far as to say that most muds could benefit from something like that, but would we all really want to support a custom client for each mud or could there be a new client made that could offer such a "protocol" for our muds to support instead? (If it were just another protocol, like MCCP, MCP, MSP, etc, perhaps other existing clients would pick up on it too.)
30 Apr, 2007, Guest wrote in the 30th comment:
Votes: 0
KaVir said:
Samson said:
Yes, it displays mountains as ^ in a greyish color. Hills as a brown ^ etc. So obviously it is best used by people who play with ANSI enabled.


It strikes me that an increasing number of muds could benefit from a custom client capable of displaying graphical tiles instead of ASCII characters…


Yes, I would love to see something like that. It would bring us back full circle to the days when we could log on to a local BBS and play a door game that had custom graphic tiles. Of course, that was possible without needing any other special software. :)
01 May, 2007, Conner wrote in the 31st comment:
Votes: 0
Samson said:
Yes, I would love to see something like that. It would bring us back full circle to the days when we could log on to a local BBS and play a door game that had custom graphic tiles. Of course, that was possible without needing any other special software. :)


Actually, if we're just talking about employing regular ansi like BBSes used, the only special software/clients we'd need would be non-mud clients.. which means we'd need to heavily modify our mud clients so we could still have our bells and whistles with normal telnet ansi support instead of the impaired ansi support that we've all gotten used to in mud clients. As it is, all that would really be needed for most mud clients would be screen position support and line/block drawing support, for the most part.
20.0/31