Synopsis: Overhead wilderness. December 97 From: "Erwin S. Andreasen" To: John cc: rom Subject: Re: 2 questions [overworld & random area generator] On Fri, 2 Jan 1998, John wrote: > has anyone successfully implimented either of these features? Here's the latest I could find in which I explain a wilderness area interconnecting areas. It's not the first time I've written about this, maybe you can find some more info in some archives for the ROM list. Sample of what it looks like you you're in the wilderness area: >> at 40,20 l """"|"""" Forest [54040, forest] x=40, y=20 @-------- A forest of trees stands here, rising up to """"""""" the sky and sheltering the earth below, where """"""""" numerous creatures make their home. TTTT*T""T TT%X%TTTT %%%%%%%%% %%%%%^^TT TTTTTTTTT (It looks nicer with color) On Mon, 29 Dec 1997, StormeRider wrote: > We're talking maps outside of the cities. The idea of a few rooms > connecting areas that should be long distances apart, IMHO, is bullshit. =) Some info about how I've implemented a wilderness on AR: Wilderness is a dedicated area, limited to 200x50 in size. You can from an X/Y coordinate derive the room vnum (e.g. 50000 + x + y * 200) and thus drawing a map centered on the character is quite easy: if the character is standing in 12,12, the point right to the north is 12,11 , the one to the right of that 13,11 etc. Each room has a legend field and a color field. The map was originally made with acidDraw,saved as some binary format and converted to another binary format which is read in by the MUD Rooms get a default description depending on sector type/color. If someone changes a room, it will be saved as other rooms in area files, as long as it's unchanged, it only saves as some 8 bytes of data in the binary file Exits in the wilderness are virtual: a getExit method returns a pointer to a static Exit structure: since we know that the room to the east of room (12,12) is (13,12) there is no need to allocate 40,000 exit structures for those exits The 10,000 rooms take up a good chunk of memory: however having them be real rooms gives flexibility (e.g. you can add mob/object resets in them, add real exits (that then override the virtual ones) and all code that does something to rooms needs no changing. Bad things about this implementation: It's nearly impossible to expand the map to be larger once the size is set. Big memory use (though the rest of the MUD takes up 27mb, so another mb does not concern me). The map draw includes things like LOS and lighting too, so you cannot see behind those mountains, can see farther while standing on a hilltop, etc. Landmarks make navigating around the wilderness easier: a certain command will reveal things like: "You see a flaming tower far to the northeast" even when the flaming tower is outside the range of the drawn map. Area connections are made by simply creating a real exit in the room leading to some actual area: the real exits override the virtual ones. A more in-depth walk-through of the implementation will, I hope, appear some day soon in my MERC Programming FAQ at http://www.abandoned.org/drylock/faq/. ============================================================================== Erwin Andreasen Herlev, Denmark UNIX System Programmer <*> (not speaking for) DDE ============================================================================== [It's not part of the FAQ yet, but visit the FAQ anyway!]