A Simple to Use Map Format for Cities and Dungeons

A problem slowing the creation of maps is that there are no easy to use tools for doing it. There is a building editor in Ember, and although it is quite flexible, it is not yet very intuitive to use, and operates on a quite detailed level.

So here’s a suggestion for a very simple to edit, tile based ASCII format for special sites in the world, such as towns, castles, dungeons, etc.


A site entity could be associated with a specific SiteMap, and then placed into some position in the world.
The server and/or client then reads the maps either on startup or on demand, and create entities based on the characters in the ascii map.

Special rules are used to select exactly which entity is created from a given character, other adjacent occurences of the same or some other types of characters can affect which entity is picked. For example when defining a wall, the SiteMap loader would look at characters
to the right, left, below, and above, and based on that select a straight wall segment, an L segment, a T junction, or a wall crossing,
and rotate it as needed. Stairs need to check if there are other stairs above or below or both, and pick the correct stair entity type based on that.

Or when adding things such as trees, a tree could be picked randomly from a pre-defined set, based on a location dependent random seed.

This is just an initial idea, and is open to further modification, redesign, or rejection.

Here’s an example SiteMap file:

# SmallCastleOfEvil.sitemap

# The basic requirements of the format used for the SiteMap file is a key-value pair configuration file,
# with the extension of support for named subspaces, lists, and multiline values.
# Text form Atlas seems like a suitable format to use.
# In that case = should probably be replaced by :, and an implicit { } pair is assumed around the whole SiteMap file.

# Perhaps some kind of pre-processor like include statements could be supported, or perhaps the files are parsed in some order,
# contextual and entities defined in earlier ones are available in later ones.

# Define ContextualEntities, whose exact entity type may depend on adjacent ContextualEntities:

OuterWall =
{
# Which kinds of entities that this contextual entity type can connect to.
AdjacentTypes = [ Wall, Door ]

# A parent entity type for this contextual entity type. Any settings defined for the parent type is inherited by this type.
ParentType = Wall

# The models to use for the different cases of adjacent walls
ContextAlone = 3d_objects/buildings/models/pillar/
ContextEnd = 3d_objects/buildings/models/wall_end/
ContextLine = 3d_objects/buildings/models/wall/
ContextBending = 3d_objects/buildings/models/wall_bend/
ContextTJunction = 3d_objects/buildings/models/wall_T_junction/
ContextCrossing = 3d_objects/buildings/models/wall_crossing/

# The texture template used for this kind of wall
TextureSet = 3d_objects/buildings/textures/granite_blocks/

}

Stairs =
{
# Which kinds of entities that this contextual entity type can connect to.
AdjacentTypes = [ Stairs ]

# Stairs are interested in if there are other Stairs above or below them.
ContextMiddle = 3d_objects/buildings/models/stairs_continuous/
ContextTop = 3d_objects/buildings/models/stairs_top/
ContextBottom = 3d_objects/buildings/models/stairs_bottom/
ContextDefault = none # Used if none of the other contexts match.
# In this case, we won’t create any entity at all for stairs that don’t lead anywhere.

# The texture template used for the stairs
TextureSet = 3d_objects/buildings/textures/wood_weathered/
}

Tree =
{
# We don’t care about adjacent trees, but we may pick from several different kinds of trees.
# We may also include nulls here, indicating that in some percent of the cases the contextual Tree entity may not produce any entity.
ContextDefault = [ "3d_objects/plants/trees/models/oak/", "3d_objects/plants/trees/models/rowan/", none, none ]

# The texture template used for the tree.
TextureSet = 3d_objects/plants/trees/textures/gnarly/

# NOTE: To match specific textures to specific tree types it seems like we would have to be
# able to not just specify the model type above, but be able to specify the entity type.
# The entity type then contains the mapping to the correct texture. The ContextDefault line above could then look like
# ContextDefault = [ Oak, Rowan, none, none ]

# Some entities should be positioned at the local ground level,
# others on the same level as the site entity that specified the location for the SiteMap
SetAtLocalGroundLevel = true
}

Door =
{
# …. Etc. Rest of the definition left out from this example
}

# Define character shortcuts for the entities used.
# On the right hand we have some identifiers for some ContextualEntities defined above or in some common included files.
# Common character definitions may also be put in a standard include file so that they don’t need to be repeated for all maps.

O = OuterWall
o = OuterWallTop
I = InnerWall
S = Staircase
F = Fountain
T = Tower
R = Tree
D = Door
. = GroundTile

# Define the map. Each level is defined separately. [ starts a block of ascii characters and ] closes it.
# If Atlas is used, the map could be expressed as a nested list of strings perhaps.


Level1 = [
OOOOOTOOTOOOOOOOOOOOOOOOOOO
O...................R.....O
D...R...R...R...IIIII..R..O
D.....F.........D..SI.....O
D...R...R...R...IIIII...R.O
O.....................R...O
OOOOTOOOTOOOOOOOOOOOOOOOOOO
]

Level2 = [
oooooTooToooooooooooooooooo
o                         o
o               IIIII     o
o               I..SI     o
o               IIIII     o
o                         o
ooooToooToooooooooooooooooo
]

Level3 = [

     T   T
                IIIII
                I..SI
                IIIII     

     T   T
]

6 Responses to “A Simple to Use Map Format for Cities and Dungeons”

  1. erik Says:

    Interesting. The idea of the work I’ve done with Carpenter in Ember is to restrict what the user can do, so that the process of building becomes less confusing.
    I do think your suggestion tends to be a little bit too restricive though. since it makes the world snap to a grid. Though, when you look at most games or virtual worlds today, you’ll notice that they too to some degree orders the world in a gridlike pattern. it’s hard to avoid it when dealing with digital things.

  2. xrenmilay Says:

    I have tried using the grid approach and that too is restrictive. I also find the grid approach great for isometric games however place that in a 3d evironment and it becomes blocky. Furthmore not everything will fit in to the 1×1 grid some times you need 1.5×2 object to make it look a bit more organic. With in this paper I wrote about building modular conent. http://dev.worldforge.org/docs/workflow/tuts/curtain_modular.html. I am confident that my approach works for building conent with in a CCS. However I am not sure if it will be usable with in a modular game environment.

  3. James Says:

    I think the idea of a simple 2d input format for quick map building is a good one, but I’m not sure ascii is the right tool for the job. As was mentioned above, using character based maps makes everything look grid-like and tiley. Also, you can’t easily specify what direction an entity should be facing unless you define a new character for each orientation. Also,what about multiple overlapping entities?

    What I suggest, which is very similar to your idea, is to use dia. You could create a sheet whatever entities you need (I don’t remember exactly how to to do this, but I don’t think it’s that difficult) and then draw your map with them. When you’re done, dia saves your map into an easily parsed xml format, which you can then munge into whatever map format WF uses. I’m planning on doing something similar for a 2d game that I’m (sort of) working on.

  4. August Young Says:

    While i have been spending most of my time with the AI. Here are some things that went through my mind. you could have a built in editor, with a submition build feature. what i mean is say the evil knight wally wants to build his castle of ultimate bunny tourchure. he has a choice have the building built by Goblins ( a simple design using a spicific tile set) or Dwarves (diferent tiles) , etc and soforth. that way if some one wants to introduce a tile set you assign it a NPC Race crew. that way it takes time to bulld and if the tile set works then all the NPC’s with the skill build can build with that tile set.

    What this does is allows the NPC to gain skills and gives the build team the ability to bless or not the tile set. have the tile sets submitted out of game in the lounge

  5. zzorn Says:

    Erik: Agreed, snapping to a grid just makes it easier to design the tiles and edit the world. We could always allow the building map to be rotated and positioned any way in the world, just the tiles in it would be aligned in grids.

    xrenmilay: Hmm, perhaps if the grid was more of a default guidline than an absolute limitation? But then we’ll need a more complex map editor. Something vector based, where you could for example draw out a city wall, and the edior / client then automatically places / generates wall section to follow the lines.

    A full featured 3D editor gives precise control of world creation, but it’s quite complex to use, and restricts the number of people that can do world design. And it makes it very hard to support player designed buildings.

    James: An excellent idea.. As long as we can define our own metadata for drawing primitives, that could work. We might want to support point like entities with a direction (e.g. trees, predefined buildings?), as well as line entities (roads, perhaps things like city walls, etc), and areas (different kinds of land types).

    I wonder if SVG has some way for users to specify own metadata? Or we could replace some icons with objects, and perhaps specific fill or line patterns with different kinds of areas / linear entities.

    August Young: I do think it would be nice to support player designed buildings, but I doubt many players would create their own tilesets / 3D building blocks. If they do, they could more simply contribute them directly through the project.

    I’ll investigate the use of an existing vector format for map generation more.

  6. August Says:

    I agree, most people won’t take the time but often those who do find distributing the tile set difficult. This way player Wally doesn’t have to actually take the time to create a tile set all Wally has to do is find an architect (special character- maybe a quest) of the appropriate race and using a simple line and block interface to set up the floor plan and then Wally has to find a work crew. From an AI point of view it provides a team work model to develop.

Leave a Reply

You must be logged in to post a comment.


UA-925252-3