05 Jun, 2009, Skol wrote in the 1st comment:
Votes: 0
Runter said:
Skol said:
I hear you, it's one of the things I remember people always talking about, but I never remembered seeing a 'get wilderness_12.c' or such. Might be a great addition for the RaM project though, allow worlds to be built with the main areas, then wilderness between etc.

I think I've only used a handful of snips over the years, but that's one that I wouldn't mind not having to reinvent heh. Although I'm sure I'd hack the heck out of any I found making it into the version I want. I'm sure I'll have to knuckle down and just write my own heh ;D


I think they're pretty easy really. There's more than one way to do it but arrays with x/y coordinate is by far the most popular. I'm working on a codebase in Ruby with Chris Bailey that's coming along nicely and I think it'll include that tool by default.


(pulled off another thread, figured it was worthy of it's own tangent).

My thoughts on Wilderness in a RoM/RaM setting (just off the hip, wanted to start a discussion of approaches etc):
1. An 'overhead' map approach vs a generated description only type approach.
a. I think most prefer the 'heads up map' as that's what I've seen more of.
b. Clear screen type 'refresh' vs scrolling with said overhead map.
b1. Most seem to scroll, personally I like clearing input.
b2. Scrolling does allow for 'look back' though.
c. Generated descriptions _only_ could actually be nice, would keep the feel of the 'wilderness' more like the rest of the game (assuming you don't normally have said overhead map).
c1. Generated descriptions allow more dynamic descriptions based upon time of day, weather, room contents, which entrance you took into the room, etc etc.

2. Single 'room' per wilderness vs…? (assuming X/Y type coordinate area)
a. Allows a nearly endless supply of wilderness areas depending on the size you set in X/Y.
b. Requires some reworking of 'in_room' type checks to see if the 'room' is actually it's own wilderness area.
b1. To avoid fighting etc, when the actors are actually say '30' apart (whatever measurement type the wilderness uses).
b2. And any other type interaction etc, unless they have the 'range' for that.
c. Could allow each room to be a 'wilderness' in the sense that it would have x/y coordinates, essentially turning the game into a coordinate based for each. Interesting thought there… Sized rooms and 'where in the room'…

Anyway, just popping off the top of my head, feel free to chime in (or renumber, or all that heh).
05 Jun, 2009, Zenn wrote in the 2nd comment:
Votes: 0
I'm rather partial to EmpireMUD's wilderness system. It uses X, Y coordinates on a big overland map, and IS scrolling. I'm not really sure how you'd be able to make it NOT scrolling in a MU* client unless you made a custom client with a box specifically for that.
05 Jun, 2009, David Haley wrote in the 3rd comment:
Votes: 0
Quote
I'm not really sure how you'd be able to make it NOT scrolling in a MU* client unless you made a custom client with a box specifically for that.

Err, that, or you used standard cursor control that's been around for a decade or so… :rolleyes:
05 Jun, 2009, Runter wrote in the 4th comment:
Votes: 0
I'm not sure if (most?) mud clients are compliant with that. Do you know, David?
05 Jun, 2009, Skol wrote in the 5th comment:
Votes: 0
I was thinking the ansi 'clear'. I did that in a spy mud I wrote about 7-8 years ago (Top Secret, was fun heh).
#define C_CLEAR_SCR     "\e#define C_CLEAR_SCR     "\e[2J"  // Clear Screen[/code]
05 Jun, 2009, Sharmair wrote in the 6th comment:
Votes: 0
Zenn said:
I'm rather partial to EmpireMUD's wilderness system. It uses X, Y coordinates on a big overland map, and IS scrolling. I'm not really sure how you'd be able to make it NOT scrolling in a MU* client unless you made a custom client with a box specifically for that.

Actually, EmpireMUD's default is to clear the screen and put the map on the top of the screen when the
map is displayed. The thing is, a lot of clients do not support the ANSI for clearing the screen and
cursor positioning and so the display just scrolls. If you do have a client that supports clearing, you
can use the noclear command to toggle if the display clears or not.

Though it is not a wilderness display, one display method I think would work well (for a client that can
support it) would be to do a system like SMAUG's menu system. The menus are displayed on the top
of the screen, but the text scrolls under it (EmpireMUD just clears the screen on map update but SMAUG
also uses cursor positioning and scroll regions). I think an even better system might be to put the map
on the bottom and scroll above it as the back scroll might still work more like normal though.
05 Jun, 2009, David Haley wrote in the 7th comment:
Votes: 0
Not all clients implement it – e.g. MUSHclient does not – but you hardly need custom clients to implement non-scrolling maps. Even telnet can do it, if memory serves. zMUD can do it as well, again if memory serves.
05 Jun, 2009, Skol wrote in the 8th comment:
Votes: 0
Interesting idea Sharmair! Could float the map right top/bottom etc.
Do most clients support that? I haven't seen that in my line of Romisms.
05 Jun, 2009, KaVir wrote in the 9th comment:
Votes: 0
Skol said:
b. Clear screen type 'refresh' vs scrolling with said overhead map.

I've played muds like this, and really didn't like it, because while I was running around I kept catching glimpses of messages which would then get wiped over before I could properly read them.

I've used screen clearing during character creation before, but I don't think I'd ever use it within the mud. If you really want maps that update instead of scroll, I'd suggest having it as an option for a custom client (although then you might as well use proper graphics for the wilderness).

Skol said:
c. Generated descriptions _only_ could actually be nice, would keep the feel of the 'wilderness' more like the rest of the game (assuming you don't normally have said overhead map).

You could have them as description-only by default, but I'd recommend at least having a map as a configurable option. It's a really handy feature for navigating a large wilderness.

Skol said:
c1. Generated descriptions allow more dynamic descriptions based upon time of day, weather, room contents, which entrance you took into the room, etc etc.

Hand-written descriptions can be just as dynamic as generated ones, it's just that most builders don't seem to like the concept of dynamic descriptions.

Skol said:
2. Single 'room' per wilderness vs…? (assuming X/Y type coordinate area)

I created my second wilderness system that way, and it worked out pretty well. Whereas my first wilderness system allowed an entire area to be linked to a specific X/Y coordinate, my second implementation required each individual room to be linked. I could then place walls around the area if I wished, and have it inaccessable from the outside except through designated doors.

In theory I could have linked (say) Midgaard room-by-room over the starting point, so that people would initially seem to be within a stock world - but they'd be able to kick down walls at any point and wander out in the surrounding world.

Skol said:
c. Could allow each room to be a 'wilderness' in the sense that it would have x/y coordinates, essentially turning the game into a coordinate based for each.

My rooms had internal coordinates as well, but it's really not the same as a coordinate-based system - you still have those artificial room boundries interfering with movement, communication, combat, etc.
05 Jun, 2009, Skol wrote in the 10th comment:
Votes: 0
KaVir said:
Skol said:
b. Clear screen type 'refresh' vs scrolling with said overhead map.

I've played muds like this, and really didn't like it, because while I was running around I kept catching glimpses of messages which would then get wiped over before I could properly read them.

I've used screen clearing during character creation before, but I don't think I'd ever use it within the mud. If you really want maps that update instead of scroll, I'd suggest having it as an option for a custom client (although then you might as well use proper graphics for the wilderness).


Yeah, I think I actually ended up turning that off due to the same issue. Good for creation though for sure.


KaVir said:
Skol said:
c. Generated descriptions _only_ could actually be nice, would keep the feel of the 'wilderness' more like the rest of the game (assuming you don't normally have said overhead map).

You could have them as description-only by default, but I'd recommend at least having a map as a configurable option. It's a really handy feature for navigating a large wilderness.

Way true, and you can allow 'line of sight' and amount of light etc that way.
Nice stuff, and I always loved the _old_ Ultima feel. With a custom client though, I'd have to get into telnet subnegotiations and all that stuff I've hidden from heh. Would be nice though, perm score sheet up, map, inventory, scrolling window of the normal input, configurable buttons.. er wait, back to the thread heh.

KaVir said:
Skol said:
c1. Generated descriptions allow more dynamic descriptions based upon time of day, weather, room contents, which entrance you took into the room, etc etc.

Hand-written descriptions can be just as dynamic as generated ones, it's just that most builders don't seem to like the concept of dynamic descriptions.

No kidding, it's hard enough to get them to write one good one sometimes, without saying 'ok now add winter/spring/summer/fall/day/night/raining' bits.

KaVir said:
Skol said:
2. Single 'room' per wilderness vs…? (assuming X/Y type coordinate area)

I created my second wilderness system that way, and it worked out pretty well. Whereas my first wilderness system allowed an entire area to be linked to a specific X/Y coordinate, my second implementation required each individual room to be linked. I could then place walls around the area if I wished, and have it inaccessable from the outside except through designated doors.


Yeah, in/out exits of the wilderness with specific coordinates would be the way I'd think as well. A cave within a wilderness for example (a hand-built area of like say 10 rooms), only at like blah[4,[123,14]] or such.

KaVir said:
In theory I could have linked (say) Midgaard room-by-room over the starting point, so that people would initially seem to be within a stock world - but they'd be able to kick down walls at any point and wander out in the surrounding world.

Skol said:
c. Could allow each room to be a 'wilderness' in the sense that it would have x/y coordinates, essentially turning the game into a coordinate based for each.

My rooms had internal coordinates as well, but it's really not the same as a coordinate-based system - you still have those artificial room boundaries interfering with movement, communication, combat, etc.

Quite true, quite true.

Nice thoughts, thanks KaVir!
05 Jun, 2009, quixadhal wrote in the 11th comment:
Votes: 0
Skol said:
My thoughts on Wilderness in a RoM/RaM setting (just off the hip, wanted to start a discussion of approaches etc):
1. An 'overhead' map approach vs a generated description only type approach.
a. I think most prefer the 'heads up map' as that's what I've seen more of.
b. Clear screen type 'refresh' vs scrolling with said overhead map.
b1. Most seem to scroll, personally I like clearing input.
b2. Scrolling does allow for 'look back' though.
c. Generated descriptions _only_ could actually be nice, would keep the feel of the 'wilderness' more like the rest of the game (assuming you don't normally have said overhead map).
c1. Generated descriptions allow more dynamic descriptions based upon time of day, weather, room contents, which entrance you took into the room, etc etc.

2. Single 'room' per wilderness vs…? (assuming X/Y type coordinate area)
a. Allows a nearly endless supply of wilderness areas depending on the size you set in X/Y.
b. Requires some reworking of 'in_room' type checks to see if the 'room' is actually it's own wilderness area.
b1. To avoid fighting etc, when the actors are actually say '30' apart (whatever measurement type the wilderness uses).
b2. And any other type interaction etc, unless they have the 'range' for that.
c. Could allow each room to be a 'wilderness' in the sense that it would have x/y coordinates, essentially turning the game into a coordinate based for each. Interesting thought there… Sized rooms and 'where in the room'…

Anyway, just popping off the top of my head, feel free to chime in (or renumber, or all that heh).


For myself, I actually prefer generated descriptions, as breaking out into a "nethack-style" game isn't really my thing. I do, however, like to HAVE a small ANSI map alongside the descriptions, anywhere such a map is possible/allowed. BatMUD does a good job in this regard. Others really like the giant ANSI map filling the screen though.

In that regards, the "best" way is to force the client to be in raw mode and actually use termcap/terminfo and curses to manage the display. IE: just like nethack/conquer/etc… but over a network connection instead of a direct pty. That's not trivial, and will certainly break with clients that can't put themselves in "dumb" mode.

The next best would be to move the cursor to coordinates and draw. There are ANSI sequences for this, but again, many clients won't deal with it.

After that, it's redrawing the whole display with the option of clearing the screen first. Plus side, less scrolling and mess… minus side, tells and other parts of the display will be lost if you're NOT using a custom client that keeps all that seperate.

My thoughts about single-room vs. multiple-room? Well, single-room wilderness areas all have problems unless you really can track down and rewrite LOTS of code to handle wilderness as a "special case". The game is designed around rooms, and treating a room as a set of rooms breaks many assumptions throughout.

Personally, I think a better idea is to generate a virtual room for every player (or NPC) that is in the wilderness. If someone moves and their coordinates will then match an already existing room, move them into that room instead of generating a new one. If no players/npcs are left in such a room, recycle it or destroy it.

For the sake of argument, let's say we just set aside vnums 1,000,000 to 1,009,999 as a "wilderness" zone. You create real rooms at the entry points, so room 3000 might be the west gate of a village that heads off into the grasslands. It links to room 1,000,001 which has a real description pointing to the village. wandering further west might point to vnum 0, which in the case of a wilderness zone means "the first unused vnum in my range" – let's say you get room 1,000,178. You are at coordinate 20,24. You walk west again, coordinate 19,24 has no fixed vnum entry, so you generate a description/map and stay in vnum 1,000,178. You walk east, coordinate 20,24 has an entry saying goto vnum 1,000,001, so you move back into a "real" room.

If Joe walks out the same gate while you're wandering, he might get vnum 1,000,179, and so you're both in your own rooms, having your own npc spawns/descriptions/etc. Now, he walks onto the same coordinates as you, since those coordinates match a room that already exists, he moves into 1,000,178 and the normal room code works. Room 1,000,179 gets deleted until someone else needs a new room.

Yeah, details aren't fleshed out there, but that's my idea.
06 Jun, 2009, Skol wrote in the 12th comment:
Votes: 0
I like that idea Quix, I'd thought of a similar one to create rooms for 'tents' and creatable buildings. Essentially the object would store the information for the room, but the room wouldn't exist unless there was an object 'set up'. Then if the tent is taken down, the room is removed. (Tent could be tent, yurt, cabin, lean-to, etc).

As far as wilderness and the 'one-room' approach yeah, I was looking at how many times Ram code checks things like ch->in_room == gch->in_room etc. Although, I suppose you could make a check pretty easily…
// blah idea
bool is_same_spot (CHAR_DATA *ch, CHAR_DATA *gch)
{
if (ch->in_room != gch->in_room)
return FALSE;
if (ch->in_room->location[x] != gch->in_room->location[x]
&& ch->in_room->location[y] != gch->in_room->location[y])
return FALSE;
else
return TRUE;
}


Then just have a check for things like combat, look, etc. Could even allow for in-wilderness' ranged combat that way. I don't think stock RoM had any ranged did it? Maybe one room away?
06 Jun, 2009, Runter wrote in the 13th comment:
Votes: 0
Quote
My thoughts about single-room vs. multiple-room? Well, single-room wilderness areas all have problems unless you really can track down and rewrite LOTS of code to handle wilderness as a "special case". The game is designed around rooms, and treating a room as a set of rooms breaks many assumptions throughout.


This is the kind of hackery elegance that is a bad good idea.
06 Jun, 2009, Runter wrote in the 14th comment:
Votes: 0
Quote
Then just have a check for things like combat, look, etc. Could even allow for in-wilderness' ranged combat that way. I don't think stock RoM had any ranged did it? Maybe one room away?


Yes, but generally *any* wilderness system (not just the display) is going to allow this considering they all are most easily built around having x/y coordinates.
06 Jun, 2009, Runter wrote in the 15th comment:
Votes: 0
Here's my idea (off the top of my head) for a decent wilderness system.

Use an data abstraction layer that gives you easy interfaces to access data.
Eg,
room = wilderness_lookup(x, y);

room->name; // is valid
room->x; // is valid
room->people; // is valid
// It's a real ROOM_DATA so all regular fields become valid after this call.
wilderness_print(player, x, y); // I would not build rooms to generate a map.

Albeit C is going to be a little ugly for any such abstraction and result in needing to find places to write some alternative code.

But under this layer I would then make it work a little unintuitive. (for C)

I would only build your room_data in that function call from internally maintained sparse arrays for a few important datas.
A. lists of people in the same rooms (that aren't empty)
B. lists of objects in the same rooms (that aren't empty)
C. lists of rooms that act as exits from the wilderness.



The obvious downfall to such a system is building a room each time instead of a constant access an array in memory gives you.
The benefit is how amazingly little memory such a system takes. (Practically none.)
Use caching to improve performance with your generated map.

Keep in mind with higher level languages (even C++) you can do some more elegant things with the same idea while maintaining good performance.
06 Jun, 2009, Skol wrote in the 16th comment:
Votes: 0
I think the reason I like the 'one room is a wilderness' approach is the apparent expandability of it?
I wouldn't mind even seeing an x/y/z grid. But there's almost no allowance for height/depth built into Rom/Ram that I'm aware of.

Rooms with mobs/objects etc could be persistent, or all could be (although memory use?), or they could be junked if empty as Quix stated above. Even if they are persistent though, if it's a generated description it would simply be a matter of something like an array of strings. Then you just say this room has string 3,8,23,46,78, if it's night it has 86 etc etc. So the entire 'area' might be 100/200/500 lines for the descriptions etc. Exits could be 0/1 for pass/nopass, doors/walls/exit sizes etc all as another small array of ints. Saved as it's own file…

Thinking outloud of course.
06 Jun, 2009, Runter wrote in the 17th comment:
Votes: 0
I personally think the one room approach with coord data attached to players is a bad one. It's not very expandable, and it requires an extraordinary amount of work tracking down and writing exceptions for parsing people and object lists. And undetected places can just result in unresolved/annoying bugs.


You'd be better off setting their room to NULL and having a zero room wilderness.
This way at least it will crash and you'll find those bugs quicker.

Of course I'm being a cynic, but the point is this isn't going to result in as easy of a time to get working as it could, and it won't be very expandable.
06 Jun, 2009, Skol wrote in the 18th comment:
Votes: 0
Ok, more brain spew:

Hm, reading yours… so it would create a room as needed, regular room info etc.
But how does it handle things like 'vnum' (just 0?) or exits (east to wilderness_lookup (x+1, y)), all that? Also, would it function as 'one big' wilderness, or is this something where you can have many unique wilderness areas? I'm still wrapping my head around how it would be done.

Also, how about players quitting? Does it move them out or just save them at x/y within said wilderness?

Then 'building' such a wilderness I suppose could be as simple as a text file (load one, or generate) or…

OLC like WEDIT.

WEDIT create sample
>New Wilderness (sample.wld) created. Initial size 10 x 10.
Taking you to coordinate 0,0.


WEDIT[sample.wld[0,0]]:size 50 50
> Wilderness (sample.wld) size set to 50 x 50
WEDIT[sample.wld[0,0]]:
wRedit 1 8
> Taking you to 1,8 in Unnamed (sample.wld)
WEDIT[sample.wld[1,8]]:
area name North Seas
> Wilderness area is now called 'North Seas'
WEDIT[sample.wld[1,8]]:
area filename nseas
> Wilderness area filename: nseas.wld
WEDIT[nseas.wld[1,8]]:
area sector water_noswim
> All sectors in 'North Seas' now 'water_noswim
WEDIT[nseas.wld[1,8]]:
sector surf
> 'North Seas'[1,8] sector set to surf.
WEDIT[nseas.wld[1,8]]:
east barrier
> 'North Seas'[1,8] east exit blocked.

Then perhaps save the entire thing like:
. is base sector
s is surf (or maybe 'graphically'?)
| indicates barrier (if there is nothing between coordinates, no door/barrier etc, free movement)
X: for X coordinate line, E: for n/s exits line? // Has to be a better way, ugh.

sample.wld:
#WILDERNESSDATA
Name North Seas~
Builders Runter~
Coordinate 50 50
Security 9
Base_Sector 8
End

#COORDINATES
X1:…..sss|xxxxx……………………………….~
E1: ———- ~
X2:…sbbbbbs.xx………………………………..~
E2:– – ~
// Through X50 E50 etc
END
// There has to be a better way to store that, imagine a 1000x1000 one?
06 Jun, 2009, Runter wrote in the 19th comment:
Votes: 0
Something like that format would be far better for most people than the same format as other areas.
06 Jun, 2009, KaVir wrote in the 20th comment:
Votes: 0
quixadhal said:
Personally, I think a better idea is to generate a virtual room for every player (or NPC) that is in the wilderness. If someone moves and their coordinates will then match an already existing room, move them into that room instead of generating a new one. If no players/npcs are left in such a room, recycle it or destroy it.

That's the approach I used for my old mud, and it worked well. The only problem I found was dealing with objects left in the rooms - you'll probably want to cache them somehow, so that you can deal with players dropping loads of objects all over the place (eg leaving a trail of breadcrumbs) and also with players moving back and forth (i.e., you don't want to repeatedly load and unload a pile of objects every few seconds as a player runs back and forth between two rooms).
0.0/181