Next: Architecture, Up: Hacker's guide

### 3.1 Designing levels

#### 3.1.1 Why is level design so important?

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. It's believed the levels often make the game much more than its engine. This is true for any type of game, and Liquid War is no exception.

So this section is here to help players understand how to hack existing levels, and create new ones, in the hope that 1) they can enjoy their own creations and 2) possibly share their work with others.

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.

#### 3.1.2 Format overview

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 `./map/` directory of the source Liquid War 6 distribution to see example of maps.

#### 3.1.3 map.png

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, a layer system is planned, you could imagine `layer2.png`, `layer3.png` and `layer4.png` would code layers that would be piled one on top of the other, so that fighters can follow tunnels, or make some places deeper than other ones. Still in progress...

#### 3.1.4 texture.png, texture.jpeg and texture-alpha.jpeg

It is possible to define a texture for the map by putting a `texture.png` or `texture.jpeg` file. 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, and also import colors from `style.xml` if defined.

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. But to save disk space, it can be convienient to prefer the JPEG format, use `texture.jpeg` instead of `texture.png` and store the alpha layer in a separated file, called `texture-alpha.jpeg`. This avoids handling heavy PNG files, PNG compression not being performant on most textures.

In `texture-alpha.jpeg`, white is considered opaque, black is transparent. Different levels of gray correspond to different levels of opacity.

#### 3.1.5 rules.xml

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. `rules.xml` is special.

See rules.xml reference.

#### 3.1.6 hints.xml

This XML file gives hints to the map loader. It will for instance allow the user to modify the resolution on the fly, force a minimum, a maximum surface (resolution) for the map. It can seriously change gameplay, but parameters set here never appear directly in the loaded map, changing them afterwards makes no sense.

See rules.xml reference.

#### 3.1.7 style.xml

This is a simple XML file defining various appearance parameters. It 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.

See style.xml reference.