Next: General design, Previous: Configuration, Up: Top
As of Liquid War 5, most levels have been contributed by players. While the maintainer of Liquid War 6 has technical knowledge to develop the game, artistic talent and taste might not be his domain of excellence 8-)
Therefore contribution are truely welcomed when they take the form of a new, original, fun and good looking level.
Note that this manual might refer to levels and maps: they are just two different names to describe the very same thing. It's an alias.
Liquid War 6 stores level information in a plain directory.
There is no such thing as an opaque .dat
binary file.
The name of the level is the name of the directory itself,
and its elements are the files contained in it.
Files must follow a precise naming scheme. For instance
Liquid War 6 expects a map.png
file to be present
in each map directory.
All image files in a level use the Portable Network Graphics or JPEG format.
It is possible that in the long term, Liquid War 6 will
be able to handle levels as .tar.gz
or .zip
files. In that case these files will only be a compressed
image of the actual level directory.
See the ./data/map/
directory of the source Liquid War 6
distribution to see example of maps.
This is the only required file in a level.
In fact, the existence of map.png
makes a
directory a level. When checking wether a directory
is a correct level, Liquid War 6 simply tests the
existence and validity of map.png
.
This image is a simple black & white area, where white zones are the background, the sea, the places where fighters can move, and black zones are the foreground, the walls, the places where fighters can't go.
This informations can be stored in a 2-color indexed file, or in a grayscaled or even truecolor RGB file, but color information won't be used. Internally, Liquid War 6 will read the color of every point. If it is over 127 on a 0 to 255 scale, it will be considered as background, if it is below 127, it will be considered as foreground.
In future versions, different levels of gray will allow map designers to make places that are deep (several fighters in the same place) and places with a single thin layer of water (default mode).
The idea of this layer is to provide information about elevation, for map renderers that can use it. It has nothing to do with gameplay, only used for shading and/or eye candy graphical effects.
Not implemented yet.
A texture used for the map. It does not need to have the same dimensions as the map itself. Indeed, textures can be much more precise than the actual logical map.
There's no theorical limit on how big a texture can be, more precisely, it can be much bigger than any hardware/driver maximum texture size. In practice, a too big texture will waste your video card RAM, and slow everything down. Sizes ranging from 640x480 to 1600x1200 are reasonable texture sizes.
If you don't define this, the map.png
file will
be used as the texture.
Note that the shape of the texture defines the shape of the map, that is, the ratio with which it will appear on the screen.
The PNG alpha layer will be used for transparency. To save disk space, it can be convienient to prefer the JPEG format and store the alpha layer in a separated file.
When one uses a JPEG format for the texture (texture.jpeg
),
for the sake of disk space (reduces both disk usage and
bandwidth by drastically reducing the size of package tarballs),
one looses the alpha layer, since JPEG format has no support
for this.
A workarround is to create a texture-alpha.jpeg
file,
and store alpha informations in it. White is considered opaque,
black is transparent. Different levels of gray correspond to
different levels of opacity.
This file can be used to automatically fill background zones (that is, where fighters can move, areas filled with liquid) using a texture tiling approach, the way it was done in Liquid War 5.
Not implemented yet.
This file can be used to automatically fill foreground zones (that is, where fighters can't go, walls) using a texture tiling approach, the way it was done in Liquid War 5.
Not implemented yet.
A simple XML file defining various appearance parameters. Has absolutely no effect on gameplay. These settings can ultimately be overriden by the player, but the idea is that if the map designer thinks this level looks better with this or that option, let him say it in this file.
The file has a very simple key/value structure, available options (keys) are:
true
) defines wether
the map should keep its ratio, or if it should
be stretched to fill the whole screen.
1.0
) defines a zoom level.
If lower than 1.0, map will occupy only a fraction
of the screen, if greater than 1.0, some areas
will be outside the screen, and the player will
need to scroll through it.
water
) defines the
style to be used for the background and menu colors.
4 styles available: air
, earth
, fire
and water
.
floating
) defines which
hud to use. 2 huds available: floating
and tactical
.
The former is a very light hud, with the bare minimum displayed
in overlay mode, so that the map can use the whole screen.
The latter is a feature rich hud, which reduces the map size
(in term or pixels) but provides complete information.
cylinder
) defines
the menu engine to be used. For now, only one possible value:
cylinder
.
flat
) defines
the renderer to be used. For now, only one possible value:
flat
. Expected future values are wave
and
3d
. wave
should reproduce the wave effects
of Liquid War 5
and 3d
should allow players to play on 3D structures
such as spheres, cylinders, tores, moebius rings and klein bottles.
Note that this is a different option that the graphical backend
to be used. The graphical backend is a technical choice, that
allows the game to run on various hardware and software combinations,
whereas this is a wish of the map designer/player on how the
map has to be rendered.
#f00
)
defines the exact color which should be used for red teams.
Format can be #rgb
or #rrggbb
.
#0f0
)
defines the exact color which should be used for green teams.
Format can be #rgb
or #rrggbb
.
#00f
)
defines the exact color which should be used for blue teams.
Format can be #rgb
or #rrggbb
.
#ff0
)
defines the exact color which should be used for yellow teams.
Format can be #rgb
or #rrggbb
.
#0ff
)
defines the exact color which should be used for cyan teams.
Format can be #rgb
or #rrggbb
.
#f0f
)
defines the exact color which should be used for magenta teams.
Format can be #rgb
or #rrggbb
.
#f80
)
defines the exact color which should be used for orange teams.
Format can be #rgb
or #rrggbb
.
#8bf
)
defines the exact color which should be used for sky (blue) teams.
Format can be #rgb
or #rrggbb
.
#b8f
)
defines the exact color which should be used for purple teams.
Format can be #rgb
or #rrggbb
.
#f8b
)
defines the exact color which should be used for pink teams.
Format can be #rgb
or #rrggbb
.
Here's an example style.xml file, which does not change anything from the default settings:
<?xml version="1.0"?> <lw6mapparam> <bool key="keep-ratio" value="true" /> <float key="zoom" value="1.0" /> <string key="background-style" value="water" /> <string key="menu-style" value="cylinder" /> <string key="view-style" value="flat" /> <string key="hud-style" value="floating" /> <color key="team-color-red" value="#ff0000" /> </lw6mapparam>
Whereas style.xml
is only about the appearance
of the map, options.xml
allows the map designer
to change pretty much any parameter.
Ultimately, the player can still ignore these settings and overide them with its own values, but the idea is: most game options are only pertinent in a given context. For instance, on some maps it's interesting to move slowly, on some other it's interesting to move fast. Some maps might be playable packed with fighters everywhere, some other might be much more fun with almost nobody on them.
The approach in Liquid War 5 was to make the options available, but let the player himself find the right settings for the right map. The consequence is that no one ever used all those cryptic options in the advanced options menu, and probably 99% of the players ended up playing with default settings. This is not that bad, but given the fact that changing a few parameters one can totally transform the gameplay, it has decided been that in Liquid War 6, the map designer suggests the right options that matches his map.
This does not prevent the player from toying with options himself, he can still do it.
There's also one important point to note: all these options are
technically implemented as integer parameters. We certainly do not
want any float here, since, and it is a Liquid War specific behavior,
the game must be 100,00% predictable and behave the same on every platform.
As there is nothing like exactness when speaking of floats, those are
forbidden here. As for strings, we are dealing here with low-level
internals, and this section is not about telling a story. They
are technical options only. Booleans are implemented with the usual
false = 0
and true = 1
convention. Note that other
config files in Liquid War 6 might rely on floats, strings, and
booleans with conventionnal true
and false
values,
but not this one. options.xml
is special.
These are the basic parameters that any map designer should consider modifying. Not that it is mandatory to change them, but it is really worth asking oneself wether it might or not be usefull to change something here.
600
) defines the maximum time of the game,
defined in seconds. Note that in some cases, the game can end much
earlier if some player has managed to win before the bell rings.
Also, technically, this value will be translated into rounds
and moves, and the game engine will wait until enough rounds and moves
have been played. So if the computer is too slow and the desired speed
is not reached, then the game will last for a longer time.
Not implemented yet.
6
) defines how many teams can connect.
This is the maximum numbers of players, by default its
value is 6, which means 2 to 6 players can play.
It can be raised up to 10.
default 1
)
defines what to do when a team dies. If set to 0,
team disappears forever, if set to 1, team reappears automatically
with fresh fighters. It's a deathmatch mode, where the winner is
not the one who stays alive the longest time, since it makes no
real sens in this case, but the one who has died less often than
others.
Not implemented yet.
0
) defines how the map will be wrapped
on the X (horizontal) axis. If set to 0, nothing is wrapped.
If set to 1, the right and left borders are connected, any
fighter can disappear on the right border and reappear
on the left border, for instance.
If set to -1, it will be
wrapped but also inversed, that is on a 320x240 map,
a fighter disappearing on the left border at position (0,60)
will reapper on the right border at position (319,180).
Not implemented yet.
0
) defines how the map will be wrapped
on the Y (vertical) axis. If set to 0, nothing is wrapped.
If set to 1, the top and bottom borders are connected, any
fighter can disappear on the top border and reappear
on the bottom border, for instance.
If set to -1, it will be
wrapped but also inversed, that is on a 320x240 map,
a fighter disappearing on the bottom border at position (40,239)
will reapper on the top border at position (280,0).
Not implemented yet.
25
) defines the overall speed
of the game. All other settings being equal, raising this value will
cause the game to behave faster. Everything will be faster, except
probably the display since your computer will calculate more game
positions in a given time and spend more CPU time. It will also
increase network traffic. Values between 10 and 50 really make sense.
2
) defines how many times
fighters move per round. Increasing this will just make fighters
move faster, but won't change anything for the rest, that is
keyboard and mouse responsivity, and network traffic will stay
the same. Multiplying the number of moves per round by the
number of rounds per second will give the number of moves per
second, which is, in fact, how fast fighters move on the screen.
spreads-per-round (default 3
) defines how many times
the gradient is spread per round. Gradient spread is a very
Liquid War 6 specific feature, just remember that the more
often you do it, the more accurately fighters will move. That is,
you will be sure they really take the shortest path. Usually
this does not have much effect, the default value should fit
in most cases, but you might want to decrease it on very simple
maps where the gradient is obvious, or increase it on complex
maps where you want fighters to be real smart.
A README
which describes the map. Should contain
a short description, and copyright information.
It is a deliberate choice not to use specific
fields to store these informations and use
a global README
instead. It makes both program code
and map design simpler.
Note that the file must be called README
and
not README.TXT
or readme.txt
whatsoever.
Todo...
Many Free Software games come with a free game engine, but without free data. A very good example of this is Doom. While the engine of this game is free, released under the GNU GPL, the data required by it is still proprietary. The Freedoom project addresses this issue, and aims at creating a complete Doom-based game which is Free Software. This requires time and energy, and it is very usefull since a Free Software game without free data to run with is not really usable.
All the data in Liquid War 6 are released under the GNU GPL, along with the source code. Data is considered as being part of the game, since running Liquid War 6 without any level makes no sense.
While the act of running Liquid War 6 is not restricted (see the complete terms of the GNU GPL), no non-free levels or graphics will be distributed with the game.
Here are some points you should think about before designing new maps: