World Forge SVG Map Specification

Version 1
By Brent Bartels

The Tools

The tool of choice for making SVG maps is going to be Sodipodi. Both the specification and the conversion script are tailored to the peculiarities of Sodipodi. The possiblity of implementing these conversions with the output of any other application will have to be carefully researched. Sodipodi has a few dependencies like intltool, Gnome Application Library, and GnomePrint. Although you can find Sodipodi downloads at, the latest, greatest and most useful sources will be on the Gnome cvs server under the module 'sodipodi'. The code base is still very much in flux especially the features that apply to us and it will probably be necessary for us to maintain our own copy of the application.

SVG to Atlas conversion will be done with which requires the Python interpreter, PyXML, and the Python Imaging Library. It uses PyXML to create a DOM tree out of the SVG map. The relevant geometric information is stripped out and drawn to a grid with the Python Imaging Library. This grid is used as a basis for creating two output xml files. One for the Cyphesis-C++ server and one for Uclient.

The Specification

Document and Gridline Settings

Because SVG documents are vectoral and our Atlas output files will essentially be gridded, careful attention must be paid to the document's dimensions and the spacing of an overlaid grid. Your document dimensions represent the dimensions of the world you are creating and anything outside of these bounds will be clipped out. Set your gridspacing to 1.00 for both the 'x' and 'y' axis. Make sure that all units are in points. The easiest way to get started if you are unfamiliar with Sodipodi is to load up 'example.svg' and start from there. If your copy of Sodipodi permits you can also use your top level SVG document tag to store metadata for the map as a whole. Map level attributes are optional but recommended.

Attribute Description
author The name of the author
mapname A nice title for the map
mapid A C style identifier, alpha-numerics and underscores with a letter first.
revision A revision number. The 'mapid' and the 'revision' together should be unique.
ruleset Identifies the game for which the map is intended "acorn", "mason" and "werewolf" are possible values.
license Identifies the license type.

Height Maps

A height map will be represented by an image element with an ID of the form 'elevation_x' where 'x' is unique among height maps. The image should cover the portion of the base rectangle that you would like the elevation data to affect. In Sodipodi you can hide a height map either by setting the opacity to 0% or sending the image behind the base rectangle. This will make it easier to see and work with the rest of the map.


SVG has support for all kinds of shapes. Currently there's only two tags that will be supported by SVG to Atlas conversion. They are 'rectangle' and 'path'. Create one of these elements to specify the boundaries of a terrain area. The ID of the terrain area should be 'A_x' where 'A' is the name of the archetype linked to the terrain and 'x' uniquely identifies the instance of that archetype in the map.


To create an object import an image and give it an ID that follows the same 'A_x' convention where A is an archetype name and x is the number of a specific instance of that type in the map. Scale your object carefully because the bounding box of the image will be the bounding box of the object. This is where gridlines will come in handy. Currently the conversion script will set a default size on the height of an object's bounding box. This will probably be remedied as Sodipodi matures.

The Conclusion

The moral to all this is 'Be careful what you wish for.' What I intended to create was a tool that took in an SVG image and created an Atlas spec 0.2 grid for Uclient and a list of items in a similar format for Cyphesis-C++. This is something that could be used now assuming we had the art for it. After a good bit of wrestling with Sodipodi and then Python my first SVG to Atlas conversion of games/mason/moraf.svg produced and output file of almost 40 Megs. And why not? A 400x400 grid will generate 160000 Atlas objects. I consider this a prohibitively expensive way to lay down terrain.

I will probably implement some simple conversion that outputs .map files for Uclient but this method has limited potential also. Even if we had the art to support it, it would be difficult to achieve the kind of seamless isometric terrain that we enjoyed with Acorn. Hand editing the output .map files is not ideal either since changes to the source SVG file could invalidate the hand editing.

With any luck I will soon be able to abandon Atlas spec 0.2 in favor spec 0.3. This would allow me to express SVG files in terms of triangle meshes, and push the burden of trying to create pleasant isometric terrains onto client developers.