[MUD-Dev] Universe Design Notes, version 061098
Mike L Kesl
mlkesl at cpinternet.com
Fri Jul 10 00:37:03 CEST 1998
. o O ( Universe System ) O o .
(mlkesl 061098 - revised)
(mlkesl 060798 - created)
* The universe can be thought of infinite space. Inside this space, there
are worlds, represented as 255x255 grids. Each square in this grid is a
zone. Each zone has the potential to contain an area, which in turn
contains to 255x255x255 rooms (the group of rooms is called an area).
* The universe will be stored in memory as a linked list of worlds or
something similar. The worlds will be some static data structure which
will have the same effect as an array of arrays. The actual implementation
may be a fancy tree or something that will go well with the code for the 3
dimensional zones and allow the same types of algorithms to be used on it
(stuff like the A* path searching algo). The rooms will be represented by
a currently unknown data type. This data type will be dynamic, with a
maximum size of 255*255*255. However this space must not be allocated if
not need, as many zones will not even have a set of rooms (area) in it. I
could definitely use some suggestions on the data type to use.
universe Stores a linked list of worlds
|
|---world 255x255 static grid of zones
| |
| |---zone Possibly stores an area
| |
| |---area Stores up to 255*255*255 dynamic rooms
|
|-------------------,
| |
| Chunk of rooms |
| |
|-------------------`
---pseudo infinitely more possible worlds here---
* Each area will contain a maximum of (x,y,z) rooms. x and y will be
represented by the positive side of two bytes, while z will be represented
by a whole byte, with 0 representing something like the surface level.
* Entering areas from zones, will require commands other than north south
east west etc. If a zone contains an area, such as a city, there will be
an area entrance in that zone which can then be entered.
* Independent of everything else. Area entrances will not be contained in
zones, they will be put there and be a part of their own
container. This way, you can change the wilderness as needed while the Area
entrances do not have to be remade...
* Most areas will not be moveable short of an earthquake, but those that
are can quite possibly be considered vehicles, such as a ship, coach, or
airplane. Have to remember to keep code from being genre-specific.
. ( Zone Specifics ) .
1 final byte representing the terrain type of a zone
(each terrain will have multiple room descriptions)
( dont even use random function here, just cycle to next )
( room desc every time one is used by anyone in the world )
Possibly create extras in zone descriptions based on area entrances nearby
or major landmarks / geological formations
Some terrain type ideas:
Marsh or Swamp Light Woods Grass Land Heavy Undergrowth Heavy Woods
Overcast Weather Rocky Terrain Tundra Searching At Night Desert or Arctic
Terrain from old mud:
inside city field forest hills mountain water_swim water_noswim unused air
desert road enter rock_mountain snow_mountain swamp jungle ruins
4 bytes for...
1 byte stores flora growth and death
1 byte stores fauna growth and death
1 byte stores minerals depletion and tiny growth
8 booleans for something else?
1 byte for soil, 1 byte for water
no resets in world idea...
mobs can be done with random encounter events
objects, will be placed their with the area entrance objects
a separate container controls these, independent of wilderness
for example, a broken down wagon on side of road...
cool world stuff, want a 3d world not a 2d one.
perhaps, code this into the gif2wilderness so that it will
build rooms above land and below water...
above land idea...
allow flight all over
below land idea...
allow mining, perhaps race skill, spells
mine entrances placed in wild rooms like objects above
below water idea...
allow swimming down all over where water.
(a pretty much open ended file)
More information about the mud-dev-archive
mailing list