[MUD-Dev] World Creation Notes, version 061098

[Mike L Kesl]

Mike L Kesl
{
	I may make the standard world, but if I did not have to then great.
	Need to decide on terrain types and their rgb representations.
	These notes like all others are up for discussion and review.
	I consider it a brainstorming session and always hope for better.
}


. o O ( World Creation ) O o .
(mlkesl 061098 - typofix)
(mlkesl 060898 - created)

( vocabulary such as "world", "zone", "universe" and "room" is defined in
  the Universe Notes, please read them if you wish to fully understand this )

Problem: How do contributors easily create worlds?
Goals: Allow contributors to simply create worlds by drawing them as gif's

(1) Each world will be created as a 256x256 gif image. 
(2) The image will need to be detailed down to every last pixel. 
(3) This image will be processed by ATOM to produce a world.

(1) Each world will be created as a 256x256 gif image.  

Each pixel will represent a terrain type. The terrain type each pixel
represents will be determined by that pixels RGB value. Logically, these
colors will be chosen in a way that best represents the terrain while not
overlapping. In other words, grassy terrain will most like be green, and
forest terrain will most likely be green, but not the same exact shade. 
Also, please remember that a terrain could be outer space or something
like that if the world was meant to represent a galaxy with multiple
universes for example. We must remember, mostly the coder must remember to
keep the environment separated from the implementation. This is done
because ATOM is meant to be a flexible genre-less engine into which an
environment is plugged, or multiple environments. 

(2) The image will need to be detailed down to every last pixel.  

Every pixel in the image will represent some zone in the world that the
players can travel into and will be represented in the text version of the
game just as the wilderness in SS was. For those that do not know, the
wilderness in SS (my mud, "The Scribe's Secrets") was represented to the
player as a small ascii map with a description of the surroundings to the
right of the ascii map. For Example...

Intersection of Lost Cause

  @+@	You are standing at a 3 way intersection.
 @@+@@  The road goes east, west and north.
 ++*++  There is a field of grass to the south.
 @""""  To the north is a dense forest on both sides
  @""   of the road.

This system required me to actually go through every room on the 9600 room
wilderness and change the terrain type for the room online. With just one
of a possible multitude of 255*255 grids, this would be insane.

The detail of the image should be apparent now, and you may have some
questions about the scale of things in the world. For example roads. The
above example take from SS, shows a road as a plus sign and the character
as a star. The character is obviously not as wide as a road, and the road
does not exactly represent the same size plot as a forest or grasslands
area. However, making roads 5 pixels wide and characters 1 pixel wide, and
general terrain types 100 pixels wide would be pretty senseless. So, it is
assumed that the road square is a road going through another terrain type,
such as a forest, and that the character is on a road, which is in a
forest, which is all represented as one square. You might find it helpful
to think of roadmaps. On a roadmap you might see a city represented as a
circle and roads leading into it as lines. These representations of roads
are usually not to scale with the city. This does not mean the road is as
wide as half a metropolitan city, and the big X you draw on the map to
represent your house does not make your house the city of 3 or 4 cities. I
hope this is understood. In practice, just draw roads as 1 pixel, but
remember that they are really much smaller than 1 pixel.

(3) This image will be processed by ATOM to produce a world.

The processing done on the image will go beyond just the simple conversion
of a grid of pixels into a grid of terrain types. It will add static
descriptions based on the terrain and the surrounding terrain as well as
data from a separate form about area entrances. Area entrances are not a
part of the actual world format, but instead are kind of layered over the
world. Allowing you to keep them in place if you make changes to the world
image. For example, you want to add a lake and tidy up some of the world
image without having to re-add the area entrances over again. This has
been discussed elsewhere, but I guess this is a good place to explain
again or rephrase the area entrances idea. As noted in the Universe Notes,
a world is a grid of 255*255 areas, which in turn can contain a grid of up
to 100*100*100 rooms. Not all areas will contain a grid of rooms by any
means, the areas should be fairly spread out in the world. For those areas
that do contain a grid of rooms there will be an entrance into the rooms
area from the world area block. This entrance will be represented on the
world map overriding any terrain type, but no entrances will be included
in the world image, they are strictly separate layers. Also, characters
must explicitly enter the rooms area from the world area, unlike SS where
the player was automatically in some said city when he/she walked into
that wilderness square. This separation of areas from the world also
allows for any mines or payer homes and such things to be kept when and if
the world image changes. This could also be used for effects like bringing
a world wide drought, all the land could be made desert or what not while
the areas still remained, like homes, cities, caves, mines, etc. I think
this is a flexible way of doing it. 

--


Am I boring you yet?, maybe the archivers will like it :p
Mike L Kesl