<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Overworld Maps on diku style Muds- Design notes -->
<!--X-From-R13: Yngevan [pQyryna <xvgxngNgur486.oenqyrl.rqh> -->
<!--X-Date: Tue, 21 Jul 1998 15:41:05 -0700 -->
<!--X-Message-Id: Pine.LNX.3.93.980721182149.22315C-100000#the486,bradley.edu -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Overworld Maps on diku style Muds- Design notes</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:kitkat#the486,bradley.edu">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00289.html">Previous</a>
| <a href="msg00291.html">Next</a>
]
Thread:
[ <a href="msg00313.html">Previous</a>
| <a href="msg00292.html">Next</a>
]
Index:
[ <A HREF="author.html#00290">Author</A>
| <A HREF="#00290">Date</A>
| <A HREF="thread.html#00290">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Overworld Maps on diku style Muds- Design notes</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Overworld Maps on diku style Muds- Design notes</LI>
<LI><em>From</em>: Katrina McClelan <<A HREF="mailto:kitkat#the486,bradley.edu">kitkat#the486,bradley.edu</A>></LI>
<LI><em>Date</em>: Tue, 21 Jul 1998 18:38:49 -0500 (CDT)</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
Not sure how many of you will find this useful, but this is my peliminary
design for adding a coordinate based overworld to co-exist with standard
diku style rooms, taking advantages from both world design methods. It
still has the problems that rooms present on a local level, but it should
work well enough for me to use without having to totally start over, and
should actually be able to be added to a diku style base without too much
of a hack. It is specifically designed for my code, so generic diku will
likely pose more of a hassle, but the same concepts may prove useful.
It's not to be confused for an elegant completely coordinate based world
with 100% dynamic descriptions, but I think it can be achived with much
less effort.
NOTE that I have not started any implementation, and as always, actually
trying to implement something exposes any and all holes in a design. I'm
sure there are some things that I'll have to tweak below, but I'm also
fairly sure that in general, the below will work without too much hassle.
------
Data Hierchy/Table of Contents:
Coordinate World
Static Zones
Random Encounters
Encounter Tables
Dummy Rooms
a) Coordinate World
The coordinate world, would be divided into square terain sectors. Each
Sector Grid would have it's own table of encounters. Also each sector
grid would have a localized list of 'objects' (programming term, not
swords) that one might see. The world would be (MAX_X by MAX_Y by 2) (the
z dimension is either ground level or sky level)
Sectors will have sight ranges to each adjoining sector, to determine when
the neighboring sector should appear in descriptions (ie along the Coast
of Despair, you can See the Sea of Sorrows from N coordinates away)
Sector Size will probably be constant squares, though I haven't decided
the right size to make it. Probably 75x75 or so. (note that a big zone
such as Allandria could easily be 20x20, with sight of 40x40
Sectors also have a magnitude range for seeing other people, at day and
night, both at ground and sky levels.
b) Static Zones (Land Marks)
No way we can avoid having major cities, and places like Myth Drannor.
Zones would have 5 bounding boxes (coordinates of top, left, right, and
bottom) These boxes would determine:
i) entrance area
ii) visibility radius from the ground in daylight
iii) visibility radius from the ground at night
iv) visibility radius from the air in daylight
v) visibility radius from the air at night
Additionally, a zone would have 6 defined entry points:
i) entry from the north
ii) entry from the south
iii) entry from the east
iv) entry from the west
v) entry from above
vi) entry by surprise
Note that if the room for "above" entry is -1, then the zone can be
entered at sky level (ie it has sky defined), and the entry room is the
room UP from the appropriate directional entry (ex: flying in from north
would enter in the room UP from entry point (i)) For this reason, ground
level zones with outdoor rooms should have a slew of up exits to the
overworld (see the EXIT_ZONE flag below)
Entry by surprise is when the visibility radius for a zone is equal to the
entry area, meaning that you don't see the zone until you're in it. This
usually means you enter not at an edge. This does make sense as a
DIFFERENT entry point because the visibility radius can vary depending on
time, or altitude. Note also that by surprise, it usually will just mean
that you enter in the middle of a zone, and can't just reverse your path
to exit the zone.
EXIT_ZONE exit flag. This flag marks an exit as leaving the zone,
triggering a change of scope back to the overworld grid. Exit zone exits
should lead back to the same room so that r->exit[i] != NULL.
Static Zones reset as zones do now.
c) Encounter Tables/Random Encounters
When a player on the overworld moves, a check against encounters is made.
If an encounter occurs, then an encounter is chosen at random from a list
of valid encounters. A random encounter is a zone file similar to the
static zones, except that it's location is non-static. This means that
unless contridicted here, a random encounter behaves like a static zone
including visibility and entry. When an encounter occurs, it is placed on
the map at maximum distance that it can be seen from, relative to the
player, in a way such that no player is closer that maximum sight range.
If this is not possible, then the encounter is discarded. Additionally,
an encounter visibility radius cannot overlap the entry area for any other
encounter or static zone, (in otherwords, you should not be able to see an
encounter from what is "inside Allandria") Note that if the visibility
radius for a random encounter is 0, then a "surprise" occurs (the 0 range
is applied to placing it at maximum range, causing the player to be IN the
zone as it appears, which by definition is a surprise entrance since
visibility and entry are the same) Random encounters can have unique
maps, or can share maps with different sets of mobs (ie: a generic battle
map for a region). Random encounters should in general be about 20 rooms
or so.
[editors note]
This next part is a problem in Diku since the room table is an array
(all the ugly calls to real_roomp()). My rooms are referenced as an
array of room pointers, localized by zone (rather than dikus global
array) so duplicating them as below into a new zone is not a major
hassle. The Dummy Rooms section will also likely force some sort of a
hack onto a standard diku, where for me, rooms are all pointers, and
can be created and destroyed easily on the fly
[end note]
Random Encounters do NOT ever reset. They disappear anytime they are
empty (zone->people==NULL), or they reset and no PLAYERS are in the zone.
The rooms for encounter zones will be loaded into the static zone table,
and copied anytime they become an encounter. Since the room struct has
(char *) types for all text, the rooms will share descriptions if more
than one copy of a room exists. In fact, I can just copy the rooms
exactly, since all pointers (people, objects, affect description, descs,
func) will either be NULL, or constant in the static zone_table. The
exception to this will be exits, which I will have to reset, but it's a
lot less work when you do block copies on most of it.
d) Dummy Rooms
On the overworld grid, there will be "floating" rooms to contain wandering
players. This is to simplify the problem of displaying messages to the 6
people at x=X, y=Y. These rooms will "split" or "merge" triggered by
movement on the overworld grid. Created Rooms (due to splitting, or
leaving a zone) will get some generic description based on the sector
defaults, and things within sight range, including people, encounters,
zones, and other sectors. Dummy rooms being discarded (due to merging or
entering a zone) will remain in a list of unused rooms to save on calls to
malloc and free with the logic that the mud will equalibriate to X loaded
rooms over time. Note that the notion of "being in a room" in the
overworld will make the transition from views relatively seemless.
Players will notice a shift in detail level, to be sure, however, entering
an encounter or zone (similarly leaving an encounter or zone) will
otherwise look like moving inside of standard "rooms". Clueless players
may not even notice the context shift, or even fully realize the
coordinate system underneath. Experienced players will quickly catch on,
particularly with random "moving" encounters, but may not fully understand
that there are two completely different systems at work. Oh, as a note,
mobiles will NEVER appear outside of encounters or static zones. If you
want mobs to appear, place them in an encounter. I haven't quite decided
how best to handle an item dropped in the middle of nowhere. Prolly idle
out the dummy room it leaves, and it gets "picked up by a some wandering
beast" (ie destroyed by the god of Anti-Clutter) when the room disappears.
I don't think I missed anything, but feel free to throw my face in it if I
have :)
-Kat
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00292" HREF="msg00292.html">[MUD-Dev] Re: Overworld Maps on diku style Muds- Design notes</A></strong>
<ul compact><li><em>From:</em> Richard Woolcock <KaVir#dial,pipex.com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00289.html">[MUD-Dev] Re: DBMS in MU*'s</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00291.html">[MUD-Dev] Re: WIRED: Kilers have more fun</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00313.html">[MUD-Dev] OT: Sid Meier</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00292.html">[MUD-Dev] Re: Overworld Maps on diku style Muds- Design notes</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00290"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00290"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: Fun vs Realism [ Was: OT: Sid Meier ]</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00378" HREF="msg00378.html">[MUD-Dev] Re: Fun vs Realism [ Was: OT: Sid Meier ]</A></strong>,
Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Mon 27 Jul 1998, 20:46 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00321" HREF="msg00321.html">[MUD-Dev] More on Informix Linux release</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 23 Jul 1998, 20:23 GMT
<LI><strong><A NAME="00318" HREF="msg00318.html">[MUD-Dev] Informix releases free version for Linux</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 22 Jul 1998, 20:49 GMT
<LI><strong><A NAME="00313" HREF="msg00313.html">[MUD-Dev] OT: Sid Meier</A></strong>,
s001gmu <a href="mailto:s001gmu#nova,wright.edu">s001gmu#nova,wright.edu</a>, Wed 22 Jul 1998, 19:40 GMT
<LI><strong><A NAME="00290" HREF="msg00290.html">[MUD-Dev] Overworld Maps on diku style Muds- Design notes</A></strong>,
Katrina McClelan <a href="mailto:kitkat#the486,bradley.edu">kitkat#the486,bradley.edu</a>, Tue 21 Jul 1998, 22:41 GMT
<UL>
<LI><strong><A NAME="00292" HREF="msg00292.html">[MUD-Dev] Re: Overworld Maps on diku style Muds- Design notes</A></strong>,
Richard Woolcock <a href="mailto:KaVir#dial,pipex.com">KaVir#dial,pipex.com</a>, Wed 22 Jul 1998, 00:19 GMT
<UL>
<LI><strong><A NAME="00298" HREF="msg00298.html">[MUD-Dev] Re: Overworld Maps on diku style Muds- Design notes</A></strong>,
Katrina McClelan <a href="mailto:kitkat#the486,bradley.edu">kitkat#the486,bradley.edu</a>, Wed 22 Jul 1998, 01:05 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00262" HREF="msg00262.html">[MUD-Dev] Re: Login and Accounts</A></strong>,
quzah <a href="mailto:quzah#geocities,com">quzah#geocities,com</a>, Sun 19 Jul 1998, 20:42 GMT
<LI><strong><A NAME="00261" HREF="msg00261.html">[MUD-Dev] Re: DBMS in MU*'s</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sun 19 Jul 1998, 20:09 GMT
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>