In this tutorial I will try to present all the technical elements and aspects that make up a good map and also explain how you can improve your map-making process by modifying or writing the XML code that defines a Transformice map. I myself quickly switched from using the editor to writing my maps completely in a suitable text editor because it has quite a few advantages that will be explored later. Of course making a map starts with an idea, that I cannot help you with, but as the title says this hopefully will prevent you from creating maps that fail and lower everyone's gaming experience.
Layout is one of the most crucial aspects of a map, if the layout does not work out the whole map might end up badly, you have to manage the room that you have at your disposal carefully, think of possible mice traps and so on. But the very first thing that you need to take care of is the orientation.
Your map should almost always be oriented from the left to the right, that is to
say that the hole and/or the spawn of the mice is on the left side of the map while
the cheese is to the right. That is because almost all
original maps are made that way and because it is crucial to start running
as soon as a map loads to not be at a disadvantage in the race for the cheese. The
game favours those who get cheese faster than others, first place earns more points
and getting cheese first is also counted in your personal statistics, earning you
specific titles.
If you stray from this convention by spawning mice on a thin ice pole at the right
of the map you successfully will induce rage in seasoned players of the game, your
map will be hated and voted down, rightly so I should add.
There is one major exception to this rule, it occurrs in those cases where the map is symmetrical and the mice spawn at the middle of the map or on the two sides. Often there will be two cheese or hole locations at the sides or it is a shaman duell map where the respective shamans and/or their coloured holes are at the edges of the map. If you decide to make a symmetrical map you should ensure that it actually is symmetrical by using numerical values as opposed to placing the objects freely in the editor. More on that later.
Of the current 109 original maps there are only seven maps that have more than one cheese source, five of which are symmetrical, one uses those additional sources as a trap. If you make maps that are asymmetrical and have multiple cheese sources you are likely to confuse players and get the shaman into sticky situations. Unless this is intended for trapping & fooling purposes one should avoid it. Same goes for making multiple routes, unless it is supposed to be a maze where some ways are longer than others and route-planning is an element of the map, you will cause the mice to be scattered all over the place, leaving the shaman to jump around helping out beginners who got stuck. Multiple holes are also to be avoided.
If your map has off-screen geometry it automatically encourages trolling and time-wasting since hiding obviously is the most fun thing to do if you cannot make an anvil-god. This can be prevented by adjusting the dimensions of your objects to be tailored to the visible part of the map. Another thing that wastes time is permanently trapped mice, so if you have a very thin gap you better make it bottomless because the mice who fall down cannot be saved in many cases. In general maps with more death-opportunity take less time, an example of how to not do it is Map 70, the Trampoline World, where it is impossible to die. Death should be the award for failure.
In many cases less is more when making a map, right now it is not possible to deactivate
the shaman, so it is better to either design maps in a way that the shaman is needed
to get to the cheese and/or the hole or to make the path quite difficult but ensuring
that the shaman will be able to help out beginners and less skilled players. After
all takes some time to rack up the score to become shaman, it is quite annoying
when your precious shaman turn is wasted by an easy map that has absolutely no use
for a shaman.
Your map should be clear cut, it should be possible to determine in a short amount
of time where the cheese is, if and how you can get there and where you need to
bring it to. Traps and mazes are the exception here, while mazes often conflict
with the goal of making the shaman useful.
If your map is intended to have elaborate mechanics and dynamic objects it is best
to try and hide those off-screen to prevent them from irritating players. How to
do this is explored later.
The less-is-more-priciple also applies to ground types and shaman objects. The vast
majority of original maps have no shaman objects in them whatsoever, and if they
feature different than normal ground types there is always only one other
such type on the map. If you think lava and ice makes a great combo you are very
wrong. Why this is should become apparent in the next chapter.
One of things that makes a lot of the original maps interesting to play is the dynamic
that you can only get the cheese if there are either very few mice going for it
or if other mice counter-balance those heading for the cheese. It's a signature
design of Transformice and if you can manage to implement it in your map you almost
instantly win at map-making.
A veriation of the cheese & no-cheese balance is a symmetrical apporoach that leads
to to split between cheese & cheese-faster. The side with less mice gets the cheese
faster, so when too many mice think they'll switch sides to be first they cause
that side to loose the race.
At this point some people will scream "It's only a flash-game!", if you are
one of them, I encourage you to take a look at
Machinarium, which is absolutely brilliant despite the fact that it uses
flash as its vessel. For some things flash is quite suitable, and if you want to
make an accessible browser game flash is a rather attractive option.
Competitiveness is something that depends on many factors and it can turn a decent
map into a great map. This is because competition is the one thing that adds the
highest replay value to any game. Multiplayer games live from competition, for many
games it is their sole reason for existence. This goes especially for ancient games
like chess which is based on warfare.
If you want to make a map competitive you need to eliminate randomness to the best
of your ability. Imagine an alternate chess in which every five turns one of the
two players randomly looses a random figure. It would be a very bad game.
This is why I like the shaman-less maps a lot, without a shaman there is less randomness.
If the map additionally does not have dynamic ground or shaman objects it is even
better. While it still is not possible to remove the shaman from custom maps it
is thus best to make the map quite hard to warrant that the shaman is not bored
and that skill pays off at the same time.
Classic examples for a bad map that has a huge random component is
Map 62, The Anvil God, it kills players almost completely at random. At
almost the same level of anti-competitiveness we have all the collision maps, wether
you win or not depends largely on where you spawn in the mouse-cluster and how you
get pushed around and stomped on, I greatly despise those levels and refuse to ever
make a map with that parameter.
Map 96 is about as random as it gets, whoever gets the first balloon wins.
Random dropping bomb-ball spawns are also great for decreasing competitiveness.
There are several maps that have all the mice in a small box, what often happens
is that, either you lag out of the box and die, or you lag out of the box and win,
neither of these options are desirable. Even if there was no lag the maps would
still be horrible since all the mice get to the hole at almost the exact same time
no matter the skill of the individual.
Try to avoid blocking the path at later stages of the map, if you hava a gap right before the hole, this will nullify all the advantages & disadvantages that players have accumulated until that point. Thus any racing was pointless and the competitivity is reduced to running and jumping at the right time when the shaman makes a board to help the horde accross.
If the state of the map deteriorates because some dynamic ground is moving upon mice comming in contact with it, the first player to enter that area will likely have his/her advantage boosted. Wether to use dynamic ground in such a way depends on the map-maker's intention and the usage. If it is placed early in the map it will often benefit those with the least starting-lag.
Directly manipulating the XML code that describes a map enables you to make your maps more precise, change several objects at the same time and have components of your map placed off-screen or hidden beneath the chat-section among other things.
In XML a document is made up of elements, those elements can have attributes and
encompass other elements, those are called child nodes. A XML document can only
have one root element, for Transformice maps that root element is called "C":
<C>...</C>
The map editor exports maps in-line, that can hardly be read, so if you work with
the code you have to structure it.
Original code:
<C><P /><Z><S><S L="800" X="400" H="70" Y="400" T="0"
P="0,0,0.3,0.2,0,0,0,0" /></S><D><T X="75" Y="365" /><F
X="725" Y="360" /></D><O /></Z></C>
Formatted:
<C>
<P />
<Z>
<S>
<S L="800"
X="400" H="70" Y="400" T="0" P="0,0,0.3,0.2,0,0,0,0" />
</S>
<D>
<T X="75"
Y="365" />
<F X="725"
Y="360" />
</D>
<O />
</Z>
</C>
Child nodes are always indented, that way you make the hierarchy visible. <P
/> is an empty element, it can also be written as <P></P>.
Attributes are written inside the element opening tag, T for example
has two attributes, X and Y: <T X="75" Y="365" />.
In the next section I will explain all the elements and attributes that are necessary
for Transformice maps.
The root element C has to contain two child elements, those are P
and Z, the order is important. P contains the map's parameters,
the element itself is empty but can contain several attributes. An example would
be: <P G="5,10" C="" N="" A="" />
G sets the gravity, it has two components. The first is the gravity
on the X-axis the second is the gravity on the Y-axis, G="0,10" is
the standard gravity. While wind in reality is a force the editor's setting for
wind sets the gravity on the Y-axis which is an acceleration. C enables
collision, you will never need this attribute if you intend to make a good map.
The interpretation of the attribute is not very "clean", instead of taking the value
the editor only cares about wether the attribute exists, its value does not matter.
Same goes for N & A. N enables night mode.
A enables soul mate mode.
Z contains all the building blocks of the map, it has to contain three
child elements: S,D & O.
S contains all ground elements, its child nodes are also named S
but contain attributes and have no children. There are a multitude of attributes
for those elements.
An example:
<S X="330" Y="135" L="60" H="10" T="0" P="1,0,0.3,0.2,0,1,0,0" />
X & Y define the coordinates of the centre of the ground
object. L & H define length and height. T
sets the appearance of the ground. T="0" means normal ground (1
= ice, 2 = trampoline, 3 = lava, 4 = chocolate).
If the T attribute is omitted the ground type will be normal. Omitting
other attributes might crash your map, if you hit validate on such a map you can
get stuck in validation since the back-button disappears in some cases. P
is the trickiest attribute, it lists all the physical parameters of the object.
The first digit can be either 0 or 1, 1 means
that the ground is dynamic. The second digit sets the mass of the object, 0
makes the mass proportional to its size. The third digit sets the friction of the
object. The fourth digit sets the repulsion of the object. The fifth figit sets
the rotation. The sixth digit sets wether the object can rotate, 1
means the rotation is fixed. The seventh digit sets linear damping the eighth sets
angular damping.
The next containter element is D, it contains: holes, cheese, mouse
spawns and shaman spawns. All of these elements have only two attributes: X
& Y that set the coordinates of that object. The elements names are:
T = Hole, F = Cheese, DS = Mouse spawn &
DC = Shaman spawn. Note: When a shaman spawn is omitted the shaman
will spawn at the mouse spawn, if the mouse spawn is missing too everyone spawns
at the hole. If there are multiple mouse spawns the mice will spawn at the "latter"
(last mouse spawn in the code).
The last container element O stored all the information about shaman
objects. The child nodes are also named O but need to have several
attributes. Those attributes are once again X & Y for
the coordinates and P for parameters. The P attribute
has two components divided with a comma like it was the case for the ground objects,
the first sets the rotation in degrees, the second sets wether the object is ghosted,
1 means it is a ghost object, the second parameter may be omitted since
it was added in an update (compatibility with older maps). To define what kind of
object it is there is a fourth attribute named C, the numerical value
for an anvil is 10 for example.
You will probably not memorize all this right away and this section is not in the
best format for reference, so I would like to direct you the
respective page on the Transformice-Wiki which holds pretty much the same
information, well structured and with default values. There also is an
object code list needed for the C attribute of an object. (As
of an update the objects that cannot made through the editor (like portals for example)
will no longer be loaded into the map.)
Text editing can be more than opening Notepad and typing away. There are advanced
text editors that provide you with syntax-highlighting, editing and formatting tools.
I myself use Visual Studio 2010 Ultimate which I normally use for writing software
in C#, its XML capabilities are good enough for Transformice map-making. There is
a free version avaiable, unfortunately
it will require you to (freely) register it after 30 days and there are a several
sub-versions for different programming languages. Visual Web Developer 2010 Express
is probably the one to go with even though all versions are likely to support XML.
If you prefer to use open source software you could use
Eclipse and/or Notepad++, Eclipse
is also a quite powerful software development platform like Visual Studio, Notepad++
is a rather lightweight but capable text editor. Now I will list a few things you
can do with a good text editor.
Update: I wrote an external map editor that has auto-formatting and other useful
features. Check it out here.
As I noted earlier the map code from the editor will be in one line when you export
it, if you make an XML document in Visual Studio and paste the code from clipboard
it will automatically add all the line-breaks and all the appropriate indentations.
If you go back into the editor to work there and export it frequently to edit the
XML again this will save a lot of time. You can apply the formatting at any time
via the menu (Edit > Advanced > Format Document), or the respective button in one
of the toolbars. I made a screenshot to illustrate
this, you can also see the syntax highlighting (those are not the default colours)
and how you can collapse elements with the minus symbols at the left.
Eclisple also has a formatting, the menu path is: Source > Format
To my knowledge Notepad++ does not support XML formatting, but it supports something
else that Eclispe does not have and that is...
If you want to effectively manipulate several objects at the same time you need to line up all your attributes and you need to have a multi-line cursor. If you hold the alt-key while clicking you can drag a rectangular selection (Visual Studio & Notepad++), that way you can erase or change the values of more than one objects. It is useful to group objects with identical or similar values together, that way you can for example shift them at once. Note that the order of the shaman objects in particular is important though. If an anchor is placed before the object it is supposed to anchor, it will not work. For ground objects the order is important for overlapping grounds, the later the ground appears in the code, the further at the front it will be displayed.
A document type definition specifies which elements and attributes are to be placed
at which point in a document of that type. Of the editors I mentioned only Visual
Studio makes good use of this. If you specify the document type at the beginning
of the XML map file Visual Studio will tell you wether your map has all the elements
it needs and which attributes you may use, even which values are acceptable for
attributes. I wrote a DTD that defines Transformice
maps as closely as I could manage. To use it download the file and place
it in the same folder as your transformice maps, then add the following line at
the beginning of your map file:
<DOCTYPE C SYSTEM "T4M-Maps.dtd">
If you have just created a XML document you need to save it to the right location
and reopen the it in order for it to work.
I recorded a quick video of how you can write code using a DTD:
In the video I use entities, that are named values, an entity definition in a DTD
looks like this:
<!ENTITY big-board "4">
They can be used in the XML by placing the name of the entity between an ampersand
and a semicolon, like this: C="&big-board;". I made those entities
so that I can get object codes and standard values when I do not have my object
code list at hand. By mouse hovering over the entity its value is displayed in a
tool-tip, you will have to replace the entity with its value because the map editor
knows nothing of my hacked together document type definition.
Having the machanics of a dynamic map off-screen or below the chat keeps your maps clean and can help you make nice traps. One method of making a map that has extensive off-screen geometry is to model the map shifted on-screen; when it is done you simply shift everything back by adding or subtracting to or from the respective coordinates. Unfortunately there are limitations to how far off screen objects can exist. About 125 units off-screen to the left and right seems save, this concerns the coordinates, the length of the object does not matter. At 130 it starts to glitch sometimes even with low object counts and at 135 objects disappear quickly. The top and bottom limits are less restrictive but you should always test if your map glitches, which occurrs more often with higher object counts and dynamic ground elements. Only go as far off-screen as really needed.
Now you should know what makes a good map and how to enhance your map editing & creation process. Get inspired and go on to cook up some masterpieces, Transformice players everywhere are counting on you!
Written by Stalky - 09.09.2010
