Liquid War(6) Liquid War(6)NAMEliquidwar - a unique multiplayer wargame
SYNOPSISliquidwar [-vh]
DESCRIPTION
Liquid War is a multiplayer wargame. Its rules are very simple but yet
original.
OPTIONS-v Displays the version number.
-h Displays copyright and various information.
...
There are many other command lines options, which are described fur‐
ther in this document.
WARNING
As Liquid War is a cross-platform program (it also runs on DOS and Win‐
dows), I could reasonably not provide groff UNIX-style documentation to
Windows user. Therefore, Liquid War's documentation is available in
many formats, including HTML, PostScript and PDF.
I believe these formats are easier to read than this man page. So
check out the /usr/share/doc/liquidwar or /usr/local/share/doc/liquid‐
war directories, for this is where HTML and other documentation files
should be. Otherwise, if you are a die-hard man page user, you may con‐
tinue with this document 8-)
Rules
The Liquid War concept
Liquid War is a wargame. But it is different from common wargames.
When playing Liquid War, one has to eat one's opponent. There can be
from 2 to 6 players. There are no weapons, the only thing you have to
do is to move a cursor in a 2-D battlefield. This cursor is followed by
your army, which is composed by a great many little fighters. Fighters
are represented by small colored squares. All the fighters who have the
same color belong to the same team. One very often controls several
thousands fighters at the same time. And when fighters from different
teams meet, they eat each other, it is as simple as that.
How do teams react?
Teams are composed of little fighters. These fighters all act indepen‐
dently, so it can happen that one single fighters does something dif‐
ferent from what all the other do.
The main goal of these fighters is to reach the cursor you control. And
to do that, they are in a way quite clever, for they choose the short‐
est way to reach it. Check it if you want, but it is true, they
*really* choose *the* shortest way to reach the cursor. That is the
whole point with Liquid War.
But these fighters are not perfect, so when they choose this shortest
way, they do as if they were alone on the battlefield. That's to say
that if there is a fighter blocking their way, they won't have the idea
to choose another way, which is free from fighters but would have been
longer otherwise. So fighters can be blocked.
Who eats whom?
When two fighters from different team meet each other, they first try
to avoid fighting, and they dodge. But if there is no way for them to
move, they get angry and attack the guy which is blocking them. Some‐
times, they attack each other and both loose health. But it can happen
that a fighter is attacked by another one, which is himself not
attacked at all.
Here is an example of this behaviour: A blue fighter and a red fighter
both want to move to their right, for that would be the shortest way to
reach their cursor if there was nobody on the battlefield. But they are
blocked by other fighters. If, for instance, the red fighter is on the
right and the blue fighter on the left, it is the red fighter which
will be eaten.
When a fighter is attacked, he first looses health, that is to say that
he gets darker. When his health reaches 0, his color changes and he
becomes a member of the team by which he has been attacked. Therefore
the number of fighters on the battlefield always remains the same.
When fighters of a same team get stuck together and block each other,
then they regenerate, that is to say that they get brighter.
However, I think the best way for you to understand the way it works is
to try the game...
Basic strategy
When I play Liquid War, I always try to surround my opponents, and it
usually works.
By the way, the computer has no strategy at all, he is a poor player,
and if you get beaten by him, it means you have to improve yourself a
lot!
But still, the computer doesn't do one thing which I've seen many
beginners doing: he never keeps his cursor motionless right in the mid‐
dle of his own fighters, for this is the best way to loose.
More strategy
Here are some more tips, kindly submitted by Jan Samohyl.
* Try to cut your opponent off walls and surround him completely with
your troops; when trying to penetrate his forces inside a tunnel,
keep your troops at the wall (and force them ocassionaly to attack
off the wall). I think this is a biggest weakness of the computer
AI, that it doesn't know this.
* When luring your troops to outflank an enemy, always move your cur‐
sor through the enemy, not the other way around.
* To penetrate very narrow tunnels, stand back for a while and let
some enemy troops come from the tunnel to you. Then surround them,
destroy, repeat.
* I have observed that with more than 2 players (6), the game diffi‐
culty depends on the map in the following way: If the playing field
is completely empty, without any holes (topologically equivalent to
full circle), the game is the easiest, because you can just go
through the middle to outflank your opponent. If there is a single
large obstacle (ie. playfield is topologically equivalent to ring
(the area between two nested circles)), the game is the most diffi‐
cult, because you have to choose one direction for the attack, and
cannot simply defend the other direction. For other maps, it seems
to really depend on their similarity to one of these two extreme
situations (and army size, of course, because it changes the rela‐
tive size of obstacles). Also, if you would later add another cur‐
sor, this property would probably disappear (maybe then games with
n+1 obstacles would be the hardest ones with n cursors).
* If you want a particularly challenging computer game (at least for
some maps), use several players, max out attack, min out defense,
max out base health (opposite would be harder, but game then changes
to the large cloud of black troops, so you don't see anything) and
give winner an advantage.
The winner is...
The clever guy who has got the greatest number of fighters in his team
at the end of the game. Or the one who exterminates all the other
teams!
Authors
Thom-Thom
Liquid War rules have been invented by Thomas Colcombet.
He was trying to find algorithms to find the shortest path from one
point to another, and found the Liquid War algorithm. Then it came to
his mind that a game could be build upon this algorithm, and Liquid War
was born. He programmed the first two versions of Liquid War using Bor‐
land Pascal for DOS, and gave me some information about the algorithm
so that I could re-program it.
U-Foot
I'm the guy who programmed the latest versions of Liquid War. I
enhanced the algorithms, and did quite a bunch of work to have the game
playable by (almost) anyone, that's to say create a correct GUI.
If you want to join me, here's all the information you'll ever need:
Christian Mauduit
E-mail: ufoot@ufoot.org
Web site: http://www.ufoot.org
GnuPG public key: FD409E94 - http://www.ufoot.org/gnupg.pub
GnuPG fingerprint: 4762 1EBA 5FA3 E62F 299C B0BB DE3F 2BCD FD40 9E94
Snail mail: 32 rue Jean Moulin 95100 Argenteuil FRANCE
Other contributors
As Liquid War is now free software, protected by the GPL, anyone is
allowed to view, edit, modify, re-compile the source code, and distrib‐
ute it, as long as Liquid War is still distributed under the GPL.
Here's a list of the contributors:
* Alstar: drew a map, which is now included in the main distribution.
* Peter Wang: ported Liquid War to GNU/Linux.
* Cort Danger Stratton : helped me setting up network support.
* Tim Chadburn : wrote midi files for the game. His contribution has
been truely appreciated since it's rather hard to find GNU GPL com‐
pliant artwork. He also wrote documentation and helped with midi
support in general.
* Jan Gretschuskin : contributed 11 maps, and made the German transla‐
tion. So if you run Liquid War with German menus, you know who you
have to thank -> Jan! 8-) Also do not forget to visit
http://www.game-factor.de
* Mouse : contributed a map.
* Rene Stach : drew 3 maps.
* Roderick Schertler : implemented HTTP 1.1 support.
* Ryan D. Brown : ported Liquid War to Mac OS X.
* Eduard Bloch : maintained the Debian package, and helped with German
support.
* Michael Terry : provided a .desktop file for better integration with
Gnome, KDE and other UNIX desktop environments.
* Kasper Hviid : contributed many maps, with their own textures, and
made the Danish translation. Great work, also available on
http://levels.2v1.cz/index.html
* David Redick : wrote an external random map generator, available on
http://xdavidx.sqrville.org/lwmapgen/index.html
* Alexandre Pineau : maintains the Debian package.
* Michael Wagner : translated the web site in German.
* Peter Williams : fixed the "too many opened socket" server bug.
* Jan Samohyl : submitted strategy tips.
* Gavin : wrote the Liquid War fanfic.
* Dave Vasilevsky : fixed the Mac OS X port.
* 2 of omega : contributed a map.
* 666-REFIZUL-666 : created many maps (distributed separately).
* Thomas Klausner : fixed Makefile for FreeBSD
* Joan Dolc : helped with Mac OS/X port
Many other people helped me by submitting bug reports and patches, and
I want to thank them for their precious help. Thanks to all the Debian
people too, who nicely maintain the Liquid War .deb package.
Mailing lists
liquidwar-user
Description
This list is for general discussions about Liquid War. Here you can
make suggestions, submit bug reports, ask for help, find players,
etc... Basically, any question or remark which concerns the game is
welcomed on this list.
Practical informations
You can't send messages to the list without subscribing. The only rea‐
son for this is that it's one of the only way to block spam effi‐
ciently. I first thought it could be OK to allow anyone to post, but
liquidwar-user seems to have be harvested by robots, so now I need to
restrict posters. However, I insist on the fact that anyone can sub‐
scribe, and the subscription to the list is not moderated. So if you
are a human being and not a stupid spam robot, you're welcome on the
list 8-)
Here's a list of usefull URLs:
* To (un)subscribe: http://mail.nongnu.org/mailman/listinfo/liquid‐
war-user
* To consult archives: http://mail.nongnu.org/pipermail/liquid‐
war-user/
* To post on the list: liquidwar-user@nongnu.org
Chat and IRC
Web-based chat-box
I have have set up a web-based chat-box which is accessible here:
http://www.ufoot.org/liquidwar/v5/metaserver.php3
It's not as good as a good old IRC channel but not everybody can use
IRC (because of firewalls and the likes), and I like the idea that peo‐
ple can chat and have the list of available servers in one single web
page.
IRC channels
I personnally spend some time on irc.freenode.net so you might use it
to find other players - though I'm not really an IRC addict... ...not
yet at least!
Here are the channels I recommend:
* #liquidwar : Liquid War dedicated channel, to find players and chat
while playing.
* #netgame_players : general channel for players who want to play
Internet games - Free Software and/or Open Source games of course,
we're on freenode.net 8-)
Fanfic
What's this?
Quoting Gavin: "I wrote a liquid war fanfic some time ago [...] I wrote
it after a friend claimed that there wasn't any liquid war fanfic
because it wasn't possible."
So here it is, a Liquid War fanfic, enjoy! (and special thanks to
Gavin)
The Battle of Emberlificoted
...
The General presided over his massing army in his seat, or rather hov‐
ering ring, of power. It dipped slightly as he flew low over his troops
marching through the viscous marsh-like terrain. They were like chil‐
dren: obedient, loyal, and they ate a lot.
Glancing at the status panel mounted in front of him he grimaced; the
other five armies: Yellow, Green, Orange, Turquoise, and, of course,
Red, were also readying armies of a similar size to his own. His violet
clones would have to fight hard and eat well to win this day.
Today would not be a battle of luck, the General mused, it would be a
battle of tactics, of alliances, and of betrayal. Every clone was iden‐
tical - that was the general idea behind clones - and the terrain
seemed strangely symmetrical; it would not give advantage to any of the
six armies amassed today. Glancing at the hologram of the battlefield
projected in front of him the General noted that he would have to move
quickly, Orange and Yellow were too close for comfort, though fortu‐
nately Baron Red's army of eponymous coloured clones was the furthest.
General Violet's fingertips were sweaty even before they touched the
four main control keys in front of him. They were labeled 'W', 'A',
'D', and, of course, the full retreat button - very useful for mislead‐
ing foes and ambushing them as they pursued - 'S'. The keys were
arrange in a roughly equilateral triangular pattern; with 'S' forming
the base and being adjacent to both 'A' and 'D', 'W' formed the tip of
the triangle.
A long breath left his parched lips as at last he made his move.
...
"Dammit!" he screamed moments later. He had misjudged Captain Yellow
and Commander Orange; he had expected one at least to attack immedi‐
ately, one he could have handled. They were working together - foiling
his attempt to shoot between them to near the center of the battlefield
to gain a better vantage point. Yellow had shot down towards him, cut‐
ting off his advance, and now Orange had sealed his escape route. "It's
not over yet" muttered the General. He opened a voice channel with Com‐
mander Orange:
"Very clever. Flawed, but still clever."
"Flawed?" came the reply.
"Yes flawed, when the good Captain is finished devouring my army who do
you think he will turn to next?", bluffed the General - his hands
worked quickly as he manoeuvred his hovering control ring, all that his
troops ever saw of him, carefully towards the weakest section of his
attackers. If he could just break out a few units he could soon turn
the tide against both Yellow and Orange.
"We have an alliance..." Orange's voice was unsure now.
Time for some sarcasm to through her even more off balance, thought the
General,
"I gathered", he spoke softly, slowly, and with too much meaning. Then
closing the channel he turned his attention back to his escape.
...
"Yes!" wooped the ecstatic figure of the General. Fifty or so of his
troops had broken free undetected and were even now working their way
cautiously towards the camps of the Yellow army, only the front lines
were still actively fighting; this opening gambit of Yellow and Orange
had turned into a stale siege and Yellow's army had pitched tent.
General Violet steered his hovering guidance ring to the center of the
Yellow camp. His troops struck, both those who had got behind the lines
and those who were still besieged. Yellow reacted too slowly and sud‐
denly found that her army, was shrinking back from the onslaught. There
was nowhere to run to, and bye now her only ally - Commander Orange -
had abandoned her to her fate; he was too busy engaging Sir. Turquoise,
who had managed to escape from the slaughter that the Baron had caused
to the Turquoise ranks and was even now valiantly attacking the flanks
of the Orange troops.
A glance at the status panel showed that Yellow's life force was fading
quickly: 8%, 3%, 1%, Gone.
The General smiled, he always enjoyed getting the first kill, and by
now his armies life force had grown and his clones had replicated. With
his, now, formidable fighting force it was no problem to engulf both
Sir. Turquoise and Commander Orange's brawling armies and annihilate
them. Once again his army grew in size and power. Now if only the Baron
didn't notice that..., thought the General.
...
"Too late!" yelped the General, now thrown into panic, as he saw the
approaching Baron. His army had also grown in size and power - having
fatally injured the Turquoise army within the opening moments of the
battle, and having finally managed to catch the elusive fleeing form
of, or what remained of, Emperor Green.
Gripping the controls harder the General thought quickly, his army
doesn't so completely outnumber me that this is already over, however
unless I can cause him to make a mistake that allows me to take the
upper hand then I will inevitably lose. Maybe I can...
This thought was terminated and replaced by another as the Baron's
angry red troops broke through the undergrowth that had covered their
movements and started to surround the General's army. The thought that
now throbbed through the panic-stricken mind of General Violet was sim‐
ply 'Run!'.
Even as he signaled the retreat and made for what seemed to be the only
possible means of escape the Baron's blood red control ring appeared at
the opening. The General knew it was over, even before the host of red
beings appeared at the opening.
There was no escape. His life force was almost depleted and he was sur‐
rounded. Then it was that the Baron decided to communicate:
"Too bad. It was a good game"
The General blinked, gaped, and was generally gobsmacked. Just before
his life force completely failed and his own weary eyes closed in
defeat he snarled,
"What!? This is not a game!" were the General's dying words.
Menus and hot keys
Introduction
This section describes how the GUI works. Since programming advanced
GUIs with Allegro is not so easy - standard C programming definitely
lacks flexibility -, and also since it's somewhat hard for me to figure
out what is user-friendly and what's not, Liquid War's menus are not
always self-explanatory. I'll just try and do something better next
time!
Menus
Map menu
The map menu allows you to choose the map you are going to play on. A
map is defined by 3 things:
* A frame. The frame can be chosen with the slider which is below the
preview. The frames are automatically sorted by alphabetical order.
* A texture for walls.
* A texture for the zone where fighters are allowed to move.
In the middle of the screen, there is a preview of the level. In this
menu, the values of the parameters can be independently changed by:
* Moving a slider.
* Clicking on a "+" or a "-" button.
* Typing a number.
On each side of the preview, sliders allow you to choose the two tex‐
tures. There is also a preview of each texture. Below this preview
there are 128 little buttons which allow you to choose single colored
textures.
The name of the map and its resolution are displayed in the lower part
of the screen.
You'll notice that on some maps the texture selection zones simply dis‐
appear. This is because these maps are associated with a texture, so
choosing a different texture is often not recommended for it won't look
as nice as with the right one. If you still want to override this be‐
haviour you can click on the "on/off" button just right to the "Use
default texture" label. This is a toggle button which will allow you to
use your own textures even on maps that normally come with their own
skin.
You'll also notice that a "Random map" button is available. This button
generates a new random map using an external program, "lwmapgen",
developped by David Redick, available on http://www.cs.clem‐
son.edu/~dredick/lwmapgen/
This program supports many command line options, and if you want a very
precise control on the generated maps, you'll need to run it sepa‐
rately. Looking at LW's log file you should be able to see the commands
LW issues when calling this program, this can give you ideas on how to
launch it manually. Alternatively using the "--help" option (for
instance "liquidwar-mapgen --help" under UNIX) should describe how to
use it.
Teams menu
This menu allows you to choose the teams which are going to play. There
are 6 square zones in this menu. Each of them is associated to a team.
Each team can be either:
* Disabled ("Off")
* Controlled by a player ("Human")
* Controlled by the computer ("Cpu")
The computer plays poorly, so remember that Liquid War is basically a
multiplayer game, and that the cpu control is dedicated to beginners
only.
You can also choose the color associated to each team by clicking on
one of the 12 colored buttons.
Below the 12 colored buttons, there are four buttons which allow you to
choose your keys. Click on one of these buttons and then press the key
you want to define. Joystick movements and buttons are considered as
keys. You can disable the joystick with the button which is at the bot‐
tom left of the menu. Mouse input is also possible, and mouse movements
are considered as keys too. To define mouse control, click on the but‐
ton associated to the direction you want to control, and then move the
mouse. Then the button should display something like "M->". Mouse sen‐
sibility can be set with the little slider at the bottom right of the
menu.
Graphics menu
Here you can choose the graphic options of the game.
The "Video mode" button allows you to switch between fullscreen and
windowed mode. This button is not available under DOS.
The "Brightness" slider allows you to set the brightness of the game.
The "Menu res" slider allows you to set the resolution used by the
menus. There are currently 5 possible values, which depend on which
platform you're running the game on.
I personnaly think the menus look best with the 640x480 resolution, but
some may prefer higher resolutions. Lower resolutions should only be
used if you have problems using SVGA video modes.
The "Game res" slider allows you to set the resolution used during the
game. The allowed values are the same than those for the menus. I rec‐
ommend that you don't use resolution higher than 640x480, unless you
have a Pentium VIII running a 10GHz.
Page flipping can be toggled. It is up to you to decide wether you keep
this option or not. The main disavantage of turning page flipping off
is that the info bar and the battlefield can look rahter ugly if they
overlap. But if you turn page flipping on you will not easily reach the
166 frames per second I sometimes get on small levels with my K6-225. I
personnaly always turn page flipping off.
The viewport size defines how much of your screen will be used by the
battlefield.
* If you set the slider on its left position, the batllefield will not
be stectched at all. Or if is strechted, it will be by a x2 or a x4
factor. So this is the mode wich allows the fastest display.
* If you set the slider ont its right position, the game will run in
fullscreen mode.
* With all the other positions of the slider, the battlefield will
keep its general proportions but it will be stretched.
The "Waves" button allows you to toggle the wave effect. You can also
do this while playing, by simply pressing F4.
Sound menu
This section allows you to set the sound volumes. There are 4 sliders,
which are:
* "Sfx": sets the volume of all the sfx sounds, thats to say'the
sounds you hear when the game starts, when you loose etc...
* "Click": sets the volume of the click, this nasty noise you hear
each time your press on a button.
* "Game water": sets the volume of the blop blop blop sounds which are
played continuously while you are playing.
* "Menu water": the same thing than "Game water" except that it con‐
cerns the sounds played while your are choosing options.
* "Music": general music volume.
Rules menu
This menu is the one where you can change the rules of the game.
The "Time" slider controls the time limit. The game will stop after
this time is elapsed. You can pause the game by pressing the "F3" key.
By the way, an info bar can display the time left while you are play‐
ing. This info bar can be toggled during the game by pressing the "F1"
key, and you can change its location by pressing the "F2" key. It also
displays how many fighters there are in each team.
The "Army size" slider controls the amount of fighters there will be on
the battlefield. The position of the slider reflects the amount of
fighters of all the teams together. If there are 4 teams, then each
player will have half as many fighters than if there had only been 2
teams.
The "Cursor x" slider controls the speed of your cursor.
* If it is set on the left, the cursor goes at the same speed than the
fighters.
* If it is centered, the cursor goes twice faster than the fighters.
* If it is set on the right, the speed of the cursor is multiplicated
by 3.
Below is a "Min 160x100" box with a slider on its right. This means
that maps will automatically be magnified so that they have a size of
at least 160x100. Indeed, some of the maps that come with Liquid War
were designed in 1995 when 486 Intel computers were common. Therefore
the maps were smalls. Today, these maps are not really fun to play on
fast computers, so Thomas Harte suggested this automatic magnifying
feature, and that was IMHO a smart idea. You can move the slider to the
right to make maps use a higher resolution - ie magnify them.
The "Defaults" button of the "Rules" menu will reset rules to their
defaults. This way you can tweak rules and then come back to the
default rules whenever you want. Note that there's also a "Defaults"
button in the main "Options" menu, but it will reset *all* options,
including player names... The advantage of the "Defaults" button in the
"Rules" menu is that it will only reset rules parameters, and keep the
rest of your configuration options untouched.
Speeds menu
The "frames/s" slider allows you to limit the number of frames per sec‐
ond. If this slider is set on the left, there won't be any limit, so
Liquid War will repaint your screen each time the fighters move. But
this can be a weird behaviour if your machine is really fast, for no
one cares about 100 fps per second, one can not even see them... So
this paramters limits the refreshment rate, so that there can be sev‐
eral logical moves of the fichters for only one screen refreshing. If
it is set on its right, the display is limite to 10 fps, so you'll have
to find your setting. I personnally set it right in the middle, and get
40 fps. If you press "F5", you'll get the number of frames per second,
and if you press "F6", you'll get the number of logical moves per sec‐
ond. You can also press "F7" or "F8", and you will get the percentage
of time your computer spends on calculating or displaying the level.
The "rounds/s" slider allows you to limit the number of rounds per sec‐
ond. If this slider is set on the left, there won't be any limit, so
Liquid War will run as fast as possible. This setting will be of no use
if you use Liquid War on a slow computer or if you play with hudge
maps, but sometimes, with a high-end Pentium class computer, it's sim‐
ply impossible to play on small maps because things simply go too fast.
So this parameter is here to help you and avoid the "10000 moves per
sec" problem.
Waves menu
This is where the wave parameters are set. The waves are just a graphic
effect, which is not really usefull. I don't often use waves, but I
still think they can sometimes look nice. Change these parameters if
you really mean to do it, but if you don't understand what they mean,
it is really OK...
There are 4 different types of waves, each of them being defined by:
* An "Ampli" parameter, to define how big the waves have to be.
* A "Number" parameter, to define how many waves should be displayed
at the same time.
* A "Speed" parameter, to define how fast the waves should move.
If you want to undestand what the "WX", "HY", "WY", and "HX" codes
mean, try to pay with only one type of wave, the "Ampli" parameter of
the 3 other types of wave being set to 0 (that is to say the slider is
on its left position), and sea how it looks like.
The wave effects can be toggled during the game by pressing the "F4"
key.
Advanced menu
This menu allows the user to change the behaviour of the fighters.
The "Attack" slider sets the agressivity of the fighters. If it is set
on the right, fighters eat each other very fast. If it is set on the
left, it takes ages to fighters to change teams.
The "Defense" slider sets the capacity that the fighters have to regen‐
erate themselves. The more it is on the right, the faster fighters
regenerate.
The "New health" slider sets the health of the fighters which have just
changed teams. The more it is on the left, the weaker these fighters
will be.
The "Winner help" slider controls a parameter which causes fighters to
attack with various strength depending on how many fighters belong to
their team. Not very clear... Let's just say that:
* If this slider is set on the right, the more fighters you have in
your team, the more aggressive they will become.
* If it is centered, all the fighters of every team will always attack
with the same strength.
* If it is set on the left, the less fighters you have, the stronger
they will be. In this mode, games usually never end.
The "Cpu strength" parameter never makes the computer more intelligent
than a monkey. But if you set it on the right, it advantages the
machine outrageously and fighters controlled by the cpu will be really
strong. So to get rid of them you'll definitely need to be clever.
Again and again, don't forget that Liquid War was conceived as a multi‐
player game and that playing against the computer is not really an
interesting thing to do.
The "CPU vs human" parameter allows you to control how aggressive CPUs
are towards humans.
* If set to "Always", CPUs will always attack humans and will never
try to attack another CPU, unless there are no humans left. This
used to be the default behavior in previous Liquid War versions, but
some players remarked that it was rather unfair, so now this is an
option.
* If set to "Random", CPUs won't care wether their opponents are CPUs
or humans, they'll attack anybody. This is the default behavior.
* It set to "Never", CPUs will attack each other before bothering
human players.
The "Allow net bots" button can be used to allow bots to connect on
network games. Indeed, bots are by default disabled in network games,
since in this case LW assumes that bots are useless (there are already
several human players). However, turning this option on will allow you
to connect bots within the game. It's important to note that this is a
per client option, this means that you can't use it to forbid access to
bots to a given network game. This option was simply created to avoid
confusion when connecting on network games, while still allowing bots
to connects if you really want them to.
The "Algorithm" parameter allows you to force the algorithm to standard
C mode. There's no real good reason you would like to do this, since
the C algorithm is slower than the ASM one. Moreover, the ASM algorithm
is automatically disabled if you play against a computer which does not
have ASM enabled. Think of this as a testing/debugging option.
Hot keys
Here's a list of keys you might use while playing:
* F1: toggles the "info" zone where the game time and the state of
each team is displayed.
* F2: moves the "info" the zone arround, possible positions being top,
right, bottom and left.
* F3: pauses the game. This function is disabled during network games.
* F4: toggles the "wave effect". Without this "wave effect", which is
turned on ny default,the game will run faster.
* F5: displays the number of frames per second (*).
* F6: displays the number of rounds per second (*).
* F7: displays the precentage of CPU spent on the game logic, calcu‐
lating where fighters must go for instance (*).
* F8: displays the precentage of CPU spent on graphics (*).
* F9: turns on/off the "capture" mode. In this mode, screenshots of
each frame are taken, and written to the hard drive as bitmaps.
* F10: quits the game right away without any confirmation prompt, also
known as the "my boss is coming here!" function.
(*) all these figures tend to be clearly false as computer go faster
and faster. Basically, the time required for "logic" and "display"
operations is getting shorter and shorter, and the tools I use to mea‐
sure it are not precise enough. Therefore I get approximations which
might by plainly wrong.
Network game
Basics
Since release 5.4.0, Liquid War includes network support, that's to say
that people can play over a LAN (Local Area Network). However, due to
limitations in Liquid War's legacy code, and also because of the lack
of time I have, it might be a little tricky to set up a network game at
first. So please read this section carefully.
You should keep in mind that:
* DOS only releases of Liquid War do not include network support, only
Windows and GNU/Linux versions will allow you to set up a network
game.
* The game should run fine on any LAN, but there's no garantee the
game will be playable on the Internet. Indeed if your "ping delay"
is not good enough, the game will be awfully slow. Bandwidth is not
an issue, since Liquid War rarely needs more than 2 Kb/sec.
* You'll need to know what an IP address is.
* You don't need to set up a network game to run a multiplayer game.
Liquid War was originally a multiplayer game without network sup‐
port. Network support is here only for people who don't feel com‐
fortable when playing at 6 on the same keyboard 8-)
Getting started
What do you need?
You'll basically need 2 computers connected on the same LAN. We'll call
them computer A and B. You might be able to play over the Internet too,
but the game can be harder to set up and - which is worse - very slow.
You'll also need to know the IP address of computer A. Type "ipconfig"
under Windows or "ifconfig" as root under GNU/Linux to get this infor‐
mation if you don't have it.
Starting the server
Liquid War uses a very traditionnal client/server approach. Basically,
the server gets informations from all the clients and then dispatches
the collected information to everybody.
So you'll need to start a server on computer A by running "liquid‐
war-server" on GNU/Linux or "lwwinsrv.exe" on windows. This is a con‐
sole application, ie it does not set up any graphic mode.
Here's a small example of a server start on GNU/Linux:
$ liquidwar-server
How many teams will connect to this server?
At this point you must enter a number between 2 and 6, and then press
"ENTER". In this example we will answer 2. The server really needs to
know how many teams will be in the game: when enough teams are con‐
nected, the game starts. It can also be a good idea to answer 6 system‐
atically and then force game start by clicking the "Start now" button
within the client. It's possible to skip this question by typing "liq‐
uidwar-server -2" instead of a plain "liquidwar-server".
Use "-2" to get rid of this question.
Register on "www.ufoot.org/metaserver/" (y/n)?
Now if we answer "y", then the server will automatically contact the
"meta-server" and it will be listed on http://www.ufoot.org/liquid‐
war/v5/metaserver.php3
This can be convenient for people who want to find other gamers to play
with on the Net. For now, let's answer "n", we'll test this meta-server
stuff later 8-)
Use "-private" to get rid of this question.
2002-06-03 16:43:00: Listening on port 8035...
2002-06-03 16:43:00: Waiting for 2 teams...
Now the server is ready to accept clients. By default it listens to
clients on port 8035. You could change this behavior setting by calling
"liquidwar-server -port 8061" for instance, but let's use the default
port to make things easier.
Starting the clients
Start the client on computer A normally by typing "liquidwar" on
GNU/Linux or double-click "lwwin.exe" on Windows.
Go to the "Teams" menu and select 2 teams, a red human and a blue CPU
for instance. If you don't know how to do this, then try and play Liq‐
uid War on a single computer first. It's important to notice that by
default the "blue CPU" won't connect on the network game. It's possible
to allow bots to connect on network games, but they are disabled by
default.
Now come back to the main menu, and a "Net Game" button should be
available. Click it. Now you should be able to:
* Start the game.
* Change the IP address of the server.
* Change the communication port.
* Set a password.
* Search for internet games automatically.
Since the server is also running on the same machine (A), you can leave
the default IP address as is (127.0.0.1).
Now you are ready to start the second client on computer B. Like with
computer A, you'll have to:
* Select 2 teams, green an yellow this time.
* Select "Net Game" in the main menu.
But this time you'll also need to change the server address, since the
client is not running on the same computer than the server.
Now click on "Start game" on computer A. The server should play a "sys‐
tem beep", which is usefull if you run a server and want to be notified
of client connections without watching the console all the time, and it
should display messages like this:
2002-06-03 16:44:48: Connection from "127.0.0.1:34677"
2002-06-03 16:44:48: Team "Napoleon" on client "127.0.0.1:34677"
accepted
2002-06-03 16:44:49: Client "127.0.0.1:34677" accepted
2002-06-03 16:44:49: Waiting for 1 team...
And on the client you should see a screen which says "Waiting for 1
team(s)" with the list of connected players below (Napoleon). You do
not need to click on the "Start now" button.
Now click on "Start game" on computer B. The server should display mes‐
sages like this:
2002-06-03 16:49:14: Connection from "192.168.1.1:1098"
2002-06-03 16:49:14: Team "Henri IV" on client "192.168.1.1:1098"
accepted
2002-06-03 16:49:15: Client "192.168.1.1:1098" accepted
2002-06-03 16:49:15: Client "192.168.1.1:1098" ready
2002-06-03 16:49:15: Client "127.0.0.1:34677" ready
2002-06-03 16:49:15: Sending info to "127.0.0.1:34677"
2002-06-03 16:49:15: Sending info to "192.168.1.1:1098"
2002-06-03 16:49:16: Game start
And at that point, the game should start 8-)
Restart a new game
Once the game is over, you can start another network game on the
clients without touching the server, because the server automatically
restarts and waits for players to connect.
To stop the server - if you want to change its settings for instance -
just go to the console where it's running and press CTRL-C.
Using the meta-server
Basics
The meta-server is a piece of software which is running on my web site,
and allows servers to register themselves so that client can get a list
of available servers.
It's written in PHP and is _very_ basic but I believe it's enough for
what has to be done: maintain a list of running servers.
The source code for the meta-server is included in the source package
of Liquid War, so you might run such a server yourself if you want to.
However, by default, servers will register themselves on my web site,
and will be listed on http://www.ufoot.org/liquidwar/v5/metaserver.php3
How to register a server
Launch the server, and when you get the question:
Register on "www.ufoot.org/metaserver/" (y/n)?
answer "y".
Note that if you're behind a proxy or a firewall, the server might be
unable to register itself. Clients might also have problems to connect
themselves on your server if there's a machine which does NAT (Network
Address Translation) between you and the meta-server.
How to find a server
In the main menu, click on "Net Game" and then "Search for internet
games".
Now you should see a list of available servers. You can click on the
items in the list to get more informations about a given server. Once
you have chosen a server, click on "Join now".
Now you get on a "Waiting for teams" screen. You might be interested in
using the "Start now" button. Indeed, if you are 4 players connected on
a server that accepts up to 6 players, maybe you'll want to start the
game right away without waiting for 2 more players. In this case, every
player must click "Start now". A "*" character will replace the "-" in
the players list when a player clicks on "Start now". When all the
players are displayed with a "*a, the game starts.
You can also chat with other players by entering text in the area above
the "Send message" button, and then click on this button. Keep in mind
that this is a very primitive chat and that the best way to chat effi‐
ciently is IMHO to play in windowed mode and have an IRC client at
hand.
Note that you can also get the list of available servers from
http://www.ufoot.org/liquidwar/v5/metaserver.php3 There you'll also
find a little chat-box which will allow you to send exchange messages
with other players.
Options
Server options
You can pass options to the server using the command line. The follow‐
ing parameters are accepted:
* "-n" where "n" is a number between 2 and 6 : with this option you
can tell the server how many teams will connect to the game. Beware,
there can be several teams on the same computer, so if you want to
have a computer with 2 players on it and 2 other computers with a
single player, then you need to use the "-4" option.
* "-lag n" where "n" is an integer : with this option, you can control
the lag used at startup. Normally, Liquid War handles this parameter
automatically, but you might want to force it to a given value.
* "-port n" where "n" is an integer : allows you to change the IP port
used by the server to listen to the clients. if you omit this param‐
eter, the default port is (8035) is used.
* "-log file.log" : dumps all informations in "file.log" instead of
using the standard output.
* "-public" : skips the "Register on ..." question, and registers the
server automatically on the meta-server, so that clients can find it
easily.
* "-private" : skips the "Register on ..." question, and does not reg‐
ister the server at all.
* "-comment This_is_a_comment" : associates a comment to the server,
which will be displayed by the meta-server. Note that the character
"_" will be replaced by spaces. This makes command line parsing eas‐
ier. I'm lazy 8-)
* "-password xxx" : associates a password to the server. With this
option, clients will need to give the right password to be able to
connect on the server.
* "-callback cmd" : with this option, the command "cmd" will be
launched whenever someone connects on an empty server. For instance,
if you want to run a permanent server and want to know when someone
connects but do not wish to permanently keep an eye on the server's
log, you might use this option and put in "cmd" a command that auto‐
matically sends you a mail. You might also use a command that fires
a popup window. It's up to you. 2 sample scripts are available in
the "misc" directory of the Liquid War source distribution. One is
"misc/liquidwar_notify.sh" and works on UNIX platforms, and the
other one is "misc/lwpopup.js", which is automatically used by
"misc/lwserver.bat", and works on Windows.
Common options
These options work on both client and server, even if they are rather
"server-oriented".
* "-metaserver url" : redefines the URL of the meta-server. Usefull if
you want to use your own meta-server.
* "-netlog" : if you use this option, the server will dump all the
network traffic on the standard output. This is usefull for debug‐
ging.
* "-nobeep" : Disables the system beeps that the application might
fire. These beeps are mostly used on the server to notify clients
connections.
About Liquid War's network implementation
Basics
Liquid War uses TCP sockets, and a single-threaded server. This implies
that:
* The game can sometimes get blocked if you play on Internet.
* The server can't talk simultaneously with several clients.
I needed to use TCP sockets, since LW's algorithm can not cope with any
data loss and it's not a reasonnable to try and anticipate what the map
would be like if the player did not move etc...
I did not implement any complex multithreaded stuff since I'm lazy and
however, clients need to have informations about all the other before
something can be done. However, implementing a mutltithreaded server
could have advantages over the current solution.
What is this lag stuff anyway?
In Liquid War, all the clients send their key presses to the server,
and then the server dispatches this information to everyone. This has
to be done for every round.
You can easily imagine that if a player has a poor connection, with a
very long "ping delay", it can take quite a long time to send the
information to the server, and then get it back.
So what Liquid War does is that at the beginning of the game, the
server sends a couple of "blank" key strokes to the clients. This way,
clients receive data from the server before thay have sent any. The
number of key strokes sent at the beginning of the game is called the
"lag".
So if it takes 200 msec to send and then receive data from the server
(approx the time returned by the "ping" command) then with a lag of 6,
you can theorically play at a rate of (1/0.2)*6=30 rounds/sec.
On one hand, setting the lag parameter to a high value will avoid many
network errors and allow you to play at a very fast pace, but the big
drawback is that there will be quite a long time between the instant
you send a key stroke to the server and the moment it comes back to
you. On the other hand, setting the lag to a low value will limit dras‐
tically he number of rounds per second, but make the game more "respon‐
sive".
However, since release 5.4.1, the "lag" is modified automatically and
should adapt itself to the situation. I've not been able to test it in
real conditions yet, but it should work 8-)
Still, setting the lag to a sensible default value can save you some
trouble. Indeed, by default, Liquid War will choose a value (6), but it
can not guess if you are playing on Internet or on a 100 Mbit LAN, and
it can take quite a long time before Liquid War automatically finds the
right value. To know the right value which should be used with the
"-lag" option, simply play a few games and watch the average lag (which
is displayed on the server console every minute) at the end of the
game.
Performance issues
Liquid War uses a "light" server, and one of the advantages of this
solution is that it allows you to run the server on low-end computers.
I personnally run a permanent server on a 486 DX2, and it runs like a
charm.
The only thing you have to take care of when running a server is band‐
width. Don't worry, you won't need a 10Mbit connection, basically, each
clients sends and receives 12 bytes of data at each round. If you add
TCP/IP headers and the facts that stuff will probably be bundled in
bigger packets, a client must deliver about 15 Kbit/sec (up and down)
for a game that runs at 100 frames/sec. A 56K V90 modem is enough for
this.
So if you run a server with 2 clients connected, the server will need
to deliver 30 Kbit/sec in both ways. A 56K V90 modem _can_ do that, but
your provider needs to be a good one 8-)
And if you run a server with 6 clients, you simply won't be able to
reach the 100 frames/sec with a 56K V90 modem. It will necessarly drop
to something less than 30 frames/sec, and is likely to drop to about 15
frames/sec. OK this is not a big deal, since few Internet games run at
more than 30 frames/sec, but well, if the server has troubles receiv‐
ing/sending data, everyone will wait, and the fun will go away.
As a conclusion: if you have the choice, choose the friend who has the
best bandwidth to run the server, without even considering the power of
his computer.
Troubleshooting
General information
Network support in 5.4 and 5.5 is still experimental in many ways, so
you might get weird behaviors. Basically, if you have a problem, just
do the following:
* Stop and restart the server when something goes wrong. To stop it,
use CTRL-C.
* Check out that you have entered the correct IP addresses.
* Try and start the client and the server using the "-netlog" option
to have an idea about what's happening.
Bugs in 5.4.x corrected in 5.4.2
Liquid War 5.4.0 and 5.4.1 were very hard to play over the Internet.
The reason is that the network routines did not do enough error check‐
ing, and therefore there were very often errors when sending and/or
receiving the map to the server. Hopefully, this bug should not appear
anymore in 5.4.2 or any other recent release.
About security
Network games passwords
As you might have noticed, under the box where you can enter the pass‐
word, a little notice explains that you must choose a "weak" password.
Now you'll tell me -> people keep on explaining me that passwords must
be something complex like "aS\r!Y9p" and now I'm told to use "hello",
what's up?
OK, keep in mind Liquid War is a game. This password stuff is just a
way to be able to play with your friends only and keep on using the
meta-server's services. Liquid War does not encrypt data and I can see
no good reason to do it for, so the password is stored and sent to the
server in clear, as plain text.
The consequence is that if you use a valuable password - for instance
the one you use to log in on your computer - the guy who runs the
server will see your password in the log file if he wishes to. There‐
fore, use something weak, something that if someones finds out what it
is, you won't really care. So "hello" is a wise choice.
Is Liquid War likely to have security holes?
Yes.
Any program is likely to have security holes, especially when it's net‐
worked. However, I have good reasons to think that Liquid War is safe
enough for a game. At least I find it safe enough to run a permanent
public server on my personnal computer 8-)
FYI, here are some things which I think make Liquid War rather safe to
run:
* Liquid War does not store anything on your hard drive that would
have been received from the network. The maps are kept in RAM. So
you won't download any virus playing Liquid War on Internet.
* Liquid War does not transmit any sort of code on the network. All
the transmitted bytes represent plain data. So you're not likely to
execute any arbitrary code - virus, worm - when playing on the Net.
* Liquid War receives network packets in static buffers, and if the
received data is too big, it is truncated. One consequence is that
Liquid War has a bunch of "limits". You can't send hudge maps over
the network, you can't have long nicknames, and so on. But another
consequence is that if you try to send garbage in the buffer, it
will be truncated. Liquid War will protest with a "network error"
message and the connection will be closed, but there will be no easy
exploit possible here.
* Liquid War does not use the sprintf, strcpy and strcat functions,
which are known as being rather unsecure since they can lead to buf‐
fer overflows. Instead, it uses the equivalent functions snprintf,
strncpy and strncat. On platforms where these functions are sup‐
ported natively, the game will use the default system functions,
otherwise it will use a free implementation by Mark Martinec. FYI,
Windows does not support snprintf-like functions natively, that is,
it's a piece of crap.
* Liquid War is Free Software, so I'm not likely to have put backdoors
in it myself, since anyone can look at the source code 8-)
However, I have not - and I know nobody who has - audited Liquid War
for security holes. So there might be some. Therefore you should
respect a few things while running Liquid War:
* Never run Liquid War as root or administrator. This is obvious but I
still mention it. If you want to run a Liquid War daemon on UNIX,
run it as user "nobody" or something approaching. If "root" or
"administrator" does not make sense on your system (DOS, Win98...)
then I assume you're not _really_ concerned about security anyway
8-P
* If you run a server 7/7 24/24, use the "-log" option to log every‐
thing in a file. This way you'll keep a trace of network activity,
and if something goes wrong, you might get a chance to see it.
* If you use passwords in network games, *never* choose a valuable
password. Use something simple like "hello" or "goodbye".
* Keep in mind that Liquid War is a game, and not a bullet proof pro‐
fessionnal server.
Last point: you should be aware that version 5.4.5 of Liquid War has
been proved to be vulnerable to a local buffer overflow, and one should
run at least 5.5.9 to get rid of this problem. FYI by the time the
exploit was found on 5.4.5, 5.5.9 was already out 8-) See
http://www.securityfocus.com/bid/8629 and http://www.securityfo‐
cus.com/bid/9453 for more informations.
Can people cheat when playing on the Net?
No.
Or at least, not really. In fact, you can still find the following
types of lamers:
* A guy who lets the CPU play at his place. He'll loose anyway because
the CPU is definitely not a great Liquid War Master 8-)
* A guy who tweaks the game and gets all his bots fight anyone he
wishes. That's mean.
* A guy who manages to let you have a 500msec lag while he does not
have any lag at all.
Apart from this, I can hardly see any way to cheat. Why? Because the
Liquid War server does not store any information about the game. It's
not aware of who wins, who looses, it knows nothing. The only thing it
does is to transmit key presses between client computers.
This way, if someone plays with a tweaked release of Liquid War, think‐
ing he will fool you, then he will fool you on his computer only... On
your computer, everything will be fine. After some time, your screen
and his screen will have nothing in common, and both players are likely
to think they have won. Except the lamer will stay a lamer.
This also explains why it's required to play with the very same ver‐
sions of the game during network games. If you plug a 5.5.2 with a
5.5.1, after a minute the screens will be completely different on each
client, since there are subtle differences between the 5.5.1 and the
5.5.2 engine. However, you shouldn't be able to do this, since a net‐
work error will stop you before you can start to play.
Additionnally, versions 5.5.5 and higher have a checksum system. Every
100 rounds, each client calculates a checksum with its local map, and
sends it to the server. If the checksum is incorrect, the server will
log a message like:
Checksum error on client "192.168.1.1:1098"
If you see this, then you're in one of the following situations:
* There's a bug in the game
* A lamer tries to cheat
FYI, all releases from 5.4.0 to 5.5.4 have a bug which causes clients
to desynchronize after a while...
Command line parameters
Introduction
When you launch Liquid War 5, you can use command line options. If you
have no problems launching Liquid War, this section should not interest
you very much.
You can use several options at the same time. The basic syntax for
options looks like this:
lw -option1 -option2 parameter2 -option3 parameter3 -option4 -option5
Note that most of the options are legacy options which where usefull
with the initial releases of Liquid War, when you had to run in a Win‐
dows DOS box, and when there were still plenty of 486 computers with
only 8Mb ram...
Version checking
These are basic options which can be usefull to figure out which
release of Liquid War is installed.
* "-v" : returns the version number of the program.
* "-h" : displays a short description and copyright information.
Changing default paths
Very usefull options, especially if you can not install Liquid War in
default directories or want to put the game in a special place.
* "-cfg myconfigfile.cfg" : causes Liquid War to use the specified
config file.
* "-dat mydatafilefile.dat" : causes Liquid War to use the specified
datafile. This might be a very interesting option if you run Liquid
War on a GNU/Linux box where you do not have root access and there‐
fore can not put the datafile in /usr.
* "-map mycustommapdir" : causes Liquid War to use the specified
directory as the user map directory. The user map directory is where
you can put plain bitmaps to be used as maps.
* "-tex mycustomtexturedir" : causes Liquid War to use the specified
directory as the user texture directory. The user texture directory
is where you can put plain bitmaps to be used as textures.
* "-mid mycustommusicdir" : causes Liquid War to use the specified
directory as the user music directory. Any midi file placed in this
directory will be added to the list of available musics.
* "-server myliquidwarserverfile" : causes Liquid War to use the spec‐
ified file as the server executable. This option has no effect for
now since the server is not launched by the client.
* "-mapgen mylwmapgenfile" : causes Liquid War to use the specified
file as the "lwmapgen" executable. "lwmapgen" is an utility by David
Redick which generates random maps automatically for Liquid War. You
might wish to change this option if random map generation does not
work for some reason, or if you want to use your own map generator.
Troubleshooting switches
These options give you control on how Liquid War treats initialisation
errors, how much memory it should reserve, what kind of video mode sit
should not choose etc...
* "-vga" : This option forces Liquid War to use your video card as if
it was only a basic VGA card. This option is required if you play
Liquid War from Windows NT.
* "-no400300" : This option disables the VGA 400x300 video mode. I
created this options for I know that some video cards/monitors don't
support the 400x300 mode.
* "-silent" : With this option, Liquid War will not play any sound. It
will not search for any sound card. This can be interesting if you
don't have any sound card or if Liquid War doesn't handle your card
correctly.
* "-nowater" : Causes Liquid War not to load any water sound. Use this
if Liquid War runs short of memory, and you should gain about 850kb.
* "-nosfx" : Causes Liquid War not to load any sound fx. Use this if
Liquid War runs short of memory, and you should gain about 150kb.
* "-nomusic" : Causes Liquid War not to load any midi music.
* "-mem n" : The parameter "n" sets the amount of memory (in Mb) Liq‐
uid War will allocate to do all its calculus. If this number is too
small, you won't be able to play on all the levels. If it is too
high, Liquid War may not start at all or crash while you are play‐
ing. The default value is 8. If you play Liquid War from Windows and
Liquid War refuses to run because this parameter is too high, then
try and give more dpmi memory to Liquid War.
* "-nojoy" : This option disables joystick support.
* "-noback" : Causes Liquid War not to load the background image. Use
this if Liquid War runs short of memory, and you should gain about
300kb.
* "-notex" : Causes Liquid War not to load any texture. Use this if
Liquid War runs short of memory, and you should gain about 750kb.
* "-auto" : If you set this option, Liquid War won't generate any
error while allocating memory or loading data.
* "-safe" : With this option, you will play with a very reduced ver‐
sion of Liquid War. It looks rather ugly but should work in a DOS
box with only 4Mb of DPMI memory. Use this if you experience serious
memory or device problems. If Liquid War doesn't start with this
option turned on, I really don't think I can do anything for you...
* "-nice" : With this option, Liquid War will use a mode which is
between the default mode and the "safe" mode.
* "-check" : With this option, Liquid War will stop as soon as it
detects something strange while initializing.
* "-stop" : If you set this option, Liquid War will prompt you for a
key when the init process is completed.
* "-c" : This is a weird option, if you turn it on, the game will only
use fonctions which are programmed in C langage. The default behav‐
iour is to use some functions I rewrote in assembly langage, so that
the game is a little faster.
Debug options
These options are usefull if you want to debug the game and trace
what's happening.
* "-netlog" : Dumps all the network traffic on the standard output.
This can help finding problems when trying to connect to the server
in a network game.
Server options
The server command line options are described in the section which
deals which network games in general. IMHO you need to understand how
network works in LW before trying to tweak the server 8-)
Other options
Everything else 8-)
* "-capture" : Activates the capture mode. In this mode, the game will
dump a .bmp file on the disk several times per second, which is use‐
full if you want to create an mpeg movie of your game session after‐
wards. You can also activate this mode interactively by pressing F9
within the game.
* "-metaserver url" : redefines the URL of the meta-server. Usefull if
you want to use your own meta-server.
* "-nobeep" : Disables the system beeps that the application might
fire. These beeps are mostly used on the server to notify clients
connections.
* "-tombola" : Activates a special mode where scores are not displayed
normally. Instead, the game displays 3 random numbers between 1 -
500.
lwmapgen options
The external lwmapgen program by David Redick accepts a number of com‐
mand line options. You can type:
liquidwar-mapgen --help
to get a list of all available options under UNIX. Under Windows the
command would be:
lwwinmap --help
Note that lwmapgen is called automatically by Liquid War when you click
on the "Random map" button.
The idea behind lwmapgen is that you choose a function which sets the
type of map generated, and then pass various arguments to this func‐
tion. If you do not explicitly choose a function, one will be picked up
for you randomly, and all other parameters will use default values.
The most usefull and common options are:
* "--help" : displays help.
* "--out filename" : save bitmap to filename.
* "--size n" : bitmap size (an integer between 0 and 5).
* "--list" : list all available functions.
* "--function function_name" : which function to use.
Here's a typical use of lwmapgen:
liquidwar-mapgen --size 3 --function hole --out test.bmp
Platform specific issues
General remarks
Liquid War is now a cross-platform game, thanks to Allegro. So now you
can play under different OS.
The same source tree will compile on all supported platforms, but with
slight differences when running. C preprocessor #defines are used to
code some platform specific stuff, and in some cases there are differ‐
ent files for the DOS, Windows and UNIX versions.
As I said, I try to use the same code for all platforms. This is in the
long term the best choice. Otherwise there would different branches of
the source tree, and I don't think this is a very good solution.
Therefore some optimizations that were performed in the old DOS-only
version have been totally removed, for they were 100% platform depen‐
dent (ie mode-X asm coding). So the new versions are all a little
slower than the old 5.1 stuff, but the performance loss is only about
20%, which is not significant with today's PCs. And anyways the perfor‐
mance loss is most of the time limited to the goog old VGA 320x200x8
mode-X, which starts being kind of obsolete.
DOS
This is the original version. It's the fastest one as far as I know,
the safest one and it will always be I think, since Allegro was first
designed for DOS, and DOS allows a full unconditionnal access to all
the hardware ressources LW requires. LW doesn't use any hardware accel‐
eration and it's not been designed to do so. Unfortunately there's no
network support for the DOS version of Liquid War.
Windows
When running under a Windows box, the DOS release used to be safer than
the native Windows port. Now that DOS support is getting really poor
with recent versions of Windows, the native Windows release of Liquid
War starts begin the good choice for Windows users. And Allegro for
Windows is getting quite stable in the 4.x series.
The other reason to choose this release rather than the DOS release is
that it has network support.
If you have problems running Liquid War under Windows, please check out
the "data\lwwin.log" file which should be written each time you run the
game. It contains the information which is displayed on the console
under other platforms, and might give you a clue about what's going
wrong.
GNU/Linux
This port is the most recent one, and also the one I prefer. Paths have
been changed to an UNIXish style, ie the data is stored in:
/usr/local/share/games/liquidwar
the executable in:
/usr/local/games
and the configuration file is
~/.liquidwarrc
Since not all GNU/Linux distributions have /usr/local/games in their
path, I also put a symbolic link to the binaries in /usr/local/bin. I
believe Liquid War is quite FHS compliant, so if its default directo‐
ries do not match your configuration, blame your distro for not follow‐
ing the standards 8-) AFAIK the only touchy directory is
/usr/local/share/pixmaps which I've seen on many distribution but does
not seem to be referenced in the FHS.
With the latest releases of Allegro, Liquid War is becoming pretty sta‐
ble under GNU/Linux. You should also know that the GNU/Linux port is
usually the most up to date, since I very very seldom boot Windows at
home and do most of the coding under GNU/Linux.
FreeBSD
This is the latest port, so I expect it to be a little touchy to
install and/or run for some time.
Note that to compile the game you'll need to install GNU tools like
gmake and gcc. Liquid War won't compile with the genuine make and cc
commands.
One thing you might ask is: "why do you provide the binary as a plain
.tgz file, it would be much nicer if a standard FreeBSD port was pro‐
vided instead!". The answer is that the statically linked binary should
work flawlessly and does not raise any dependency problem. Also I don't
know how to make a BSD port and I'm not really interested in doing it.
If it's easy to do, then someone can simply do it and send it back to
me. If it's hard to do, then I do not really have the time nor motiva‐
tion to do it. What I did is make the code and install scripts FreeBSD
friendly so that it would be possible to compile the game under Free‐
BSD. Packaging is another story.
Mac OS X
There's currently a beta version of a Mac OS X port for Liquid War.
Ryan D. Brown nicely managed to compile and run the game under Mac OS
X, and the latest news was that it does basically work. Still, this
port did not go through intensive testing, so there might still be some
bugs, expecially concerning networking.
There were some byte endianess problems in previous ( <=5.5.8 )
releases of LW, but I tried to fix them and they should be gone now.
As of today, we're trying to find out a convenient way to package and
release the Mac OS X version of LW. You can contact us on the mailing
list if you're interested in this port.
User levels
A piece of advice
You can use your own levels whith Liquid War 5. The only thing you have
to do is to put your own 256-colors vbitmap files in a special direc‐
tory, and the program will use them. Currently, BMP, LBM, PCX, and TGA
files are supported. It is a good thing to use 256 colors bitmaps, for
they waste less disk space than truecolor bitmaps, and Liquid War 5
converts all bitmaps to 32 colors bitmaps. Additionnally, truecolor
bitmaps might cause the DOS version to crash randomly... 2-color bit‐
maps will also cause the program to crash. I warned you!
The best thing you can do to create your user levels is to have a look
at the few user files I put in the .zip file and try at first to do
something that looks about the same!
Maps
Liquid War 5 does many checks on user levels and is much safer than
Liquid War 3. Still, try and help the program not to crash, if possi‐
ble.
Liquid War considers that dark colors are walls and bright colors are
associated to the playable area. So you can draw your walls in black,
dark blue, etc... And the rest of the map can be of any bright color
such as white or yellow.
You can draw a small map on a big bitmap, as long as you use a bright
background color. Liquid War will autodetect the range of your map and
add the border line if necessary.
Liquid War re-orders all the maps, so that the smallest ones are on the
left and the most complicated ones on the right when you choose them
with the slider in the "map" menu. So if you can't find the map you
just draw, don't worry, it is probably just mixed with the levels from
the .dat file.
The default path for maps is "custom\map\" on windows, and
"/usr/local/share/games/liquidwar/map" on GNU/Linux.
Textures
All you have to do is put a bitmap in the default directory which is
"custom\texture\" on windows, and "/usr/local/share/games/liquid‐
war/texture" on GNU/Linux.
Textures
As of Liquid War 5.6.x, it's possible to associate a map with a tex‐
ture. All you need is to call the maps with the same name (case is
important, lowercase recommendend...). Look at the "meditate" custom
map which is shipped with Liquid War for instance.
This also works with internal builtin maps (those stored in the
datafile) so for instance if you name a custom texture "world1.bmp" it
will automatically be associated to the builtin map world1 (to figure
out internal names you have to unpack the source distribution and look
in the ./data directory). This also works the other way, if you name a
map "wood2.bmp" it will be automatically associated with the builtin
texture wood2.
Associating a texture with a map requires more work than designing a
simple map, but the results is usually much nicer. See the "Kasper -
..." series of maps for instance.
Send your levels
Maybe you will find that the original levels are ugly and unplayable.
Well, if you have made user levels and think they are great, just send
them to the Liquid War user mailing list. Please use only 256 colors
bitmap and zip them before sending them, or else they might be blocked
by my provider...
As of today, dozens of user maps have already been included in Liquid
War, this is very nice for it happens that every map designer has his
own personnal tastes, so the maps all look different.
Still, to be included in Liquid War's mainstream distribution, your
maps will need to be placed under the terms of the GNU General Public
License, or at least a compatible license. You should have received a
copy of this license with Liquid War anyway. Read it 8-)
Of course, you can use *any* map when playing. You can even play with a
bitmap you got from a proprietary source - such a proprietary game you
bought for instance - but the point is that I can't - and you can't
either - distribute such a map along with Liquid War.
However, this is enough legal boring stuff! What you should keep in
mind is that I'm always happy when I receive maps from players, and
it's a pleasure for me to include them in the mainstream distribution.
Core algorithm
Introduction
General remarks
If you have played Liquid War, you must have noticed that your army
always takes the shortest way to reach the cursor. So the fundamental
stuff in Liquid War is path-finding. Once you've done that the game is
quite easy to code. Not harder than any other 2D game. Still the path
finding algorithm is an interesting one, for it's not a common method
that we used.
Basically, at each round (by round I mean a game logical update, this
occurs 10 or 100 times/sec depending on the level and/or your machine),
the distance from all the points of the level to your cursor is calcu‐
lated. Now the point is to calculate this fast, real fast. In fact, a
"gradient" is calculated for all the points of the level, and the value
of this gradient is the distance required for a little pixel/fighter to
reach your cursor, assuming that he takes the shortest way. Liquid War
does this with a 10% error tolerance, and it's enough for keeping the
game interesting.
Once you have this gradient calculated, it's not hard to move your
fighters. Basically, you just have to move them toward the adjacent
point that has the lowest gradient value, ie is the closest to your
cursor.
History
The Liquid War algorithm has been invented by my friend Thomas Colcom‐
bet In fact the Liquid War algorithm has been invented before the game
itself. The game came as a consequence of the algorithm, he just
thought "mmm, cool, we could make a game with that!".
Later, I enhanced the algorithm, as I coded it. The consequences were a
performance increase, especially on simple but big levels. I mean lev‐
els with wide areas for teams to move. Still the basis of the algorithm
remained the same.
Pros
The Liquid War algorithm for path-finding is very efficient:
* When you have to move lots of different points toward one single
point. Good thing that's the rule of Liquid War!
* When you have no clue about how your map will look like, ie if the
walls are randomly placed. The complexity of the level doesn't
influence much the speed of the algorithm. The size does, but the
complexity, ie the number of walls, is not so important.
Cons
The Liquid War algorithm is very poor compared to other algorithms
when:
* You have several target destinations, that's to say Liquid War would
be really slow if there were 100 teams with 10 players only.
* You want to move one single point only.
* > You want the exact (100% sure) path. In fact, this algorithm finds
solutions which approach the best one but you can never figure out
if the solution you found is the best, and the algorithm never ends.
In the long term, the algo will always find the best solution or
something really close but I don't know any easy way to figure out
when you have reached this state.
Mesh
Introduction
The first Liquid War algorithm used to calculate the gradient (the dis‐
tance from a point to your cursor) for every single point of the map.
With Liquid War 5, I used a mesh system. This mesh system is a struc‐
ture of squares connected together. Squares may be 1,2,4,8 or 16 units
large or any nice value like that, and the gradient is only calculated
once for each square. Squares have connections between them, and each
connection is associated to a direction.
There are 12 directions:
* North-North-West (NNW)
* North-West (NW)
* West-North-West (WNW)
* West-South-West (WSW)
* South-West (SW)
* South-South-West (SSW)
* South-South-East (SSE)
* South-East (SE)
* East-South-East (ESE)
* East-North-East (ENE)
* North-East (NE)
* North-North-East (NNE)
Example
Well, let me give you an example, supposing that you level structure
is:
**********
* *
* *
* **
* *
**********
The * represent walls, that's to say squares where fighters can not go.
Then the mesh structure would be:
**********
*11112233*
*11112233*
*1111445**
*i1114467*
**********
In this mesh, there are 7 zones:
* zone 1 has a size of 4. It's linked with zones 2 (ENE) and 4 (ESE).
* zone 2 has a size of 2. It's linked with zones 3 (ENE,ESE), 5 (SE),
4 (SSE,SSW) and 1 (SW,WSW,WNW).
* zone 3 has a size of 2. It's linked with zones 5 (SSW), 4 (SW) and 2
(WSW,WNW).
* zone 4 has a size of 2. It's linked with zones 2 (NNW,NNE), 4 (NE),
5 (ENE), 6 (ESE) and 1 (WSW,WNW,NW).
* zone 5 has a size of 1. It's linked with zones 3 (NNW,NNE,NE), 7
(SE), 6 (SSE,SSW), 4 (SW,WSW,WNW) and 2 (NW).
* zone 6 has a size of 1. It's linked with zones 5 (NNW,NNE), 7
(ENE,ESE) and 4 (WSW,WNW,NW).
* zone 7 has a size of 1. It's linked with zones 5 (NW) and 6
(WSW,WNW).
Why such a complicated structure?
Because it allows the module which calculates the gradient to work much
faster. With this system, the number of zones is reduced a lot, and
calculus on the mesh can go very fast. At the same time, this mesh
structure is complicated to understand by us humans but it's very easy
for the computer.
Gradient
Introduction
For each zone defined in the mesh, LW calculates an estimation of the
distance between the cursor and this zone.
The algorihm is based on the fact that to cross a zone which size is n,
n movements are required. Easy, eh?
Description
Here's the way the algorithm works:
for each turn of the game, do:
* pick up a direction between the 12 defined directions. They have to
be chosen is a peculiar order to avoid weird behaviors from fight‐
ers, but let's suppose we just pick up the "next" direction, ie if
WSW was chosen the last time, we pick up WNW.
and then for each zone in the mesh, do:
* Compare the potential of the current zone with that of its neighbor
zone. The neighbor zone to be chosen is the one which corresponds to
the direction which has been previously picked up, and by potential
I mean "the distance to the cursor, estimated by the algorithm's
last pass".
* If potential_of_the_neighbor_zone > (potential_of_the_current_zone +
size_of_the_current_zone) then potentiel_of_the_neighbor_zone =
potential_of_the_current_zone + size_of_the_current_zone
How can this work?
Well, just ask my friend thom-Thom, he's the one who had the idea of
this algorithm!
The basic idea is that by applying this simple rule to all the zones,
after a certain amount of time, it's impossible to find any place in
the mesh where the rule is not respected. And at this time, one can
consider the potiential is right in any point.
Of course when the cursor moves the potential has to be recalculated,
but you see, cursors move really slowly in Liquid War, so the algorithm
has plenty of time to find a new stable solution...
Demo
It's possible to see this algorithm working by typing:
ufootgrad[n]
while playing, where [n] is the number of the team the gradient of
which you want to view. The game is still running but you view a team's
gradient being calculated in real time instead of seeing the fighters.
If you type ufootgrad0 the display comes back to normal mode.
Move
Introduction
Once the gradient is calculated for any zone on the battlefield, it's
quite easy to move the fighters, hey?
The following method is used to move the players:
* A "main direction" is chosen for the fighter, this direction is cho‐
sen using the gradient calculated on the mesh.
* Knowing which direction is the main one, a "level of interest" is
applied to the 12 defined directions.
There are 4 "level of interest" for directions:
* Main directions: the direction calculated.
* Good directions: these directions should lead the fighter to the
cursor.
* Acceptable directions: ok, one can use this direction, since the
fighter shouldn't loose any time using it.
* Unpossible directions: wether there's a wall or using this direction
means the fighter will be farer from his cursor than before, it
always means that this direction will not be used, never.
Rules
The fighters will try to find any matching situation in this list, and
chose the first one.
* The main direction is available, no one on it, OK, let's follow it.
* There's a good direction with no one on it, OK, let's follow it.
* There's an acceptable direction with no one on it, OK, let's follow
it.
* The main direction is available, but there's an opponent on it, I
attack! By attacking, one means that energy is drawned from the
attacked fighter and transmitted to the attacker. When the attacked
fighter dies, he belongs to the team which killed him.
* A good direction is available, but there's an opponent on it, I
attack!
* The main direction is available, but there's a mate on it, I cure
him. That's to say that energy is given to the mate. This way, when
there's a big pool of fighters from the same team, they re-generate
each other.
* None of the previous situations found, do nothing.
Tips and tricks
The behavior of the armies is quite tricky to set up. I had myself to
try many algorithms before I came to something nice. In fact, I had to
introduce some "random" behaviors. They are not really random for I
wanted the game to behave the same when given the same keyboard input,
but for instance, fighters will prefer NNW to NNE sometimes, and NNE to
NNW some other times. By the way, I think Liquid War could stand as a
nice example of the thoery of chaos.
Source code
General remarks
Modularity
Liquid War 5 is basically a big C program. I've splitted the source
code in many small files for I do not like to have to handle big mono‐
lithic sources, but this does not mean Liquid War is very modular. In
fact Liquid War 5 is quite bloated with global variables and other ugly
stuff 8-(
Coding style
To be honest, it's a big mess. You won't find 2 files coded in the same
maner... OK, I'm exagerating a bit. From now I try to make an effort
and stick to basic rules such as:
* use the GNUish-style indentation - the default Emacs mode in fact
* prefix global functions / variables / constants / types with
lw_<NAME_OF_THE_file>_. For instance, a "do_it" function in myfile.c
will be called lw_myfile_do_it
* use capitals for constants, globals and types only. All functions
are in lowercase with "_" to separate words
* keep on using 8.3 filenames for .c source files. This is for better
DOS integration. DOS version of Liquid War is still maintained, you
know 8-)
* use English only for code and comments
I might decide to rename and cleanup everything some day, for it would
help other coders to understand what I wrote, but well, this is cer‐
tainly not a thrilling task 8-/
Source files organization
Main game code
Here you'll find the main() function, the main game loop, applica‐
tion-wide constants and other global stuff.
It might be a good start if you want to hack the code.
* base.h: contains global constants used in many different files.
* game.c / game.h: contains the main game loop.
* main.c / main.h: the file where the main C function is declared.
Doesn't contain much except calling init functions and running the
GUI.
Menus
The menus are coded using the Allegro GUI system. While this system is
very powerfull, it's IMHO not adapted to very complex GUIs, and one of
its drawbacks is that it's not so easy to redesign something once
you've coded it.
Besides, when I started coding the GUI in 1998, I did it in a rather
ugly way, and now I'm paying for my being lazy at that time, since I
spent hours coding when I want to change something 8-/
* about.c / about.h: contains the code for the about menu.
* advanced.c / advanced.h: contains the GUI advanced options menu.
* connect.c / connect.h: contains code for the "connect" menu which
displays which players are connected to the server, before the game
actually starts.
* controls.c / controls.h: contains the code for the controls menu.
* graphics.c / graphics.h: code for the graphic options menu.
* internet.c / internet.h: contains the code for the "Search for
Internet games" menu, where one can pick up a running server auto‐
matically with the help of the meta-server.
* language.c / language.h: contains the code for the "Language" menu.
* level.c / level.h: contains code for the menu where the player can
select a level and its options (texture or color).
* menu.c / menu.h: contains the code for the main menu.
* netgame.c / netgame.h: contains the code for the net game menu.
* options.c / options.h: contains the code for the options menu.
* play.c / play.h: contains the code which ties the menu to the main
gameloop.
* rules.c / rules.h: code for the rules menu.
* score.c / score.h: functions to display the scores at the end of the
game.
* speeds.c / speeds.h: contains the code for the speeds menu.
* team.c / team.h: code for the team menu, where one choses which
teams will play.
* volume.c / volume.h: code for the sound menu.
* wave.c / wave.h: code for the wave menu.
GUI tools
These files contain various utilities which are used in the menus.
* alleg2.c / alleg2.h: contains some tweaked allegro functions. I
wanted to use bitmaps with sevral colors for my fonts, and change
some of the allegro default behavior. So rather than modifying the
allegro source code right in the library I copied it in this file
and then modified it.
* back.c / back.h: this modules displays the background image.
* dialog.c / dialog.h: contains code for standard dialog boxes.
* error.c / error.h: contains functions to display error messages once
the game is in graphical mode.
* help.c / help.h: generic functions to display the various help
pages.
Core algorithm
Here's *the* interesting part. All the rest of the code is just sugar
coat to display stuff, receive players commands, communicate with other
computers, handle errors, etc... But the real thing is here!
It's funny to note that these files have almost not been modified since
Liquid War 5.0.
It's also interesting to note that they represent a small percentage of
the total amount of code in the game. This tends to prove - and I'm
convinced of it - that game programming does not only consists in hav‐
ing great ideas, but also requires a lot of "dirty" and boring work.
Honestly, coding an option menu is as boring as coding Liquid War algo‐
rithm is fun.
* fighter.c / fighter.h: contains code to move the armies, once the
gradient has been calculated.
* grad.c / grad.h: this module calculates the gradient for each team.
One could say it's the "kernel" of the game, since most of the CPU
time is spent in this module (except if you have a slow display...).
* mesh.c / mesh.h: contains code to set up a usable mesh with a map.
Mesh are re-calculated at each time a new game is started, the rea‐
son for this being that meshes are *very* big so it would not be
reasonnable to save them directly on the HD.
* monster.s / monster.h: assembly functions to speed-up the game. It's
a replacement for some fighter.c functions.
* spread.s / spread.h: contains assembly replacements for some func‐
tions of grad.c. These replacements do the same than the original
ones from grad.c, but faster. Could still be optimized.
Moving cursors
It looks like nothing, but moving a cursor and deciding where it should
go if there's a wall in front of it is not that easy, especially if you
want things to work nicely.
* autoplay.c / autoplay.h: contains the code for the computer AI. This
module simulates keypresses from the computer, then the computer is
handled as any other player.
* move.c / move.h: provides an API to move the cursors.
User input
Until 5.4.0, Liquid War did not have network support. As it is designed
to be multiplayer, one needed to have several players on the same com‐
puter. The mouse also needed to be handled in a special way since cur‐
sors can *not* pass walls in Liquid War. Additionnally, I wanted all
input channels (keyboard mouse and joystick) to be handled in a unified
way.
This explains why there's so much code for user input, when one would
think at first sight that "polling the keyboard is enough".
* joystick.c / joystick.h: contains code to support joystick input. It
wraps joystick buttons to virtual keyboard keys, so that joystick
and keyboard behave exactly the same.
* keyboard.c / keyboard.h: contains code to handle key presses.
* mouse.c / mouse.h: wraps the mouse movements to virtual keyboard
keys. This way the mouse can be used to control the players.
Initialisations
These files contain functions to intialize various game components.
100% boring code.
* area.c / area.h: contains functions to create the game area. Basi‐
cally it contains functions to create the data structures in which
the level is stored during the game.
* army.c / army.h: functions to create the armies, and place them on
the battlefield.
* asm.c / asm.h: various constants, macros and utilities to ensure
that asembly code works correctly.
* bigdata.c / bigdata.h: I had a really hard time with the malloc
function with DJGPP under Win95 dos box. I tried to have it working
for hours and hours but my program kept being buggy. So I decided to
allocate the memory myself, in a memory zone I create at startup.
This is what this module does: create a huge memory zone and then
give parts of it to the rest of the program.
* config.c / config.h: contains everything that is related to the game
configuration. This module contains in global variables all the
parameters that are stored in the config file.
* cursor.c / cursor.h: contains the code to init the cursors and place
them on the battlefield at the beginning of the game.
* decal.c / decal.h: This module makes the link between teams and
players. Its coding is quite ugly, for some modules in LW assume
that when 2 teams are playing they are always teams 0 and 1. So when
3 teams are playing are playing and the second team loses, one has
to make team 2 become team 1. That's what this module is for.
* exit.c / exit.h: contains code that is executed when the game ends,
it shuts down Allegro and displays messages on the console.
* gfxmode.c / gfxmode.h: contains code to set up the various video
modes, and defines which modes are available for each platform.
* init.c / init.h: contains code to initialize Allegro with proper
options and analyze failures.
* palette.c / palette.h: contains function to set up the current color
palette. Liquid War uses different palettes, depending on what col‐
ors are chosen for teams.
Graphics
Here lies most of the graphic functions in Liquid War. There's not that
much code since Liquid War's strength is not its visual effects, but
rather its gameplay.
The only "funny" thing is the wave effect. I'm quite happy with it, and
honestly, I do think it is rather fast, given the fact that it uses no
3D hardware at all.
* disp.c / disp.h: contains functions to display the battlefield.
* distor.c / distor.h: this module contains code to create the "wave
effect". It uses a lot of data tables, and is quite complicated to
understand...
* glouglou.s / glouglou.h: assembly module, it is a replacement for
some functions of distor.c. It goes much faster but does the same.
* info.c / info.h: contains code to display the info bar. The info bar
is the bar which display the time left and the amount of players for
each team while the game is running.
* message.c / message.h: provides an API to display messages during
the game. Very useful if you want to debug the game: you can trace
and display anything.
* pion.c / pion.h: contains code to display the cursors.
* viewport.c / vieport.h: code to allocate and resize the zone where
the map is displayed, also called "viewport".
Sound and music
Sound and music routines required some encapsulation, since the game
must be able to run even if the sound and/or music did not load cor‐
rectly.
* music.c / music.h: contains the code to control MIDI playback.
* sound.c / sound.h: functions to play sound.
Data management
These functions handle the datafile contents and also the custom data.
Note that the various utilities such as liquidwarcol, liquidwarmap and
liquidwartex do not share code with the main executable. This is obvi‐
ously a design error, for liquidwarmap will handle maps in a very poor
way and is unable to autodetect map errors, whereas the game does it
rather well. Blame the programmer.
* disk.c / disk.h: contains all the code to access data from the hard
drive. In fact, all the HD access is done at startup.
* map.c / map.h: contains code to load the maps from a datafile raw
data or a user defined bitmap to a usable structure in RAM.
* maptex.c / maptex.h: contains code to handle the "use default tex‐
ture" option, and associate a map with a given texture automati‐
cally.
* texture.c / texture.h: contains code to handle textures. Textures
are stored in a special format which uses 5 bits per pixel.
Random map generator
Liquid War has a "generate random map" feature which is available
within the game and also as an external program. The source code for
the external program is in ./utils/lwmapgen in Liquid War source dis‐
tribution. This program has been coded by David Redick, is also avail‐
able on http://www.cs.clemson.edu/~dredick/lwmapgen/ and works on
GNU/Linux. Compiling this program under DOS and/or Windows is untested
and unsupported.
The random map generator within Liquid War - which of course works on
any platform support by LW - uses for its greater part the same source
code as the external lwmapgen program.
* random.c / random.h: wrapper for the map generator written by David
Redick. It basically does the same as ./utils/lwmapgen/main.c except
that it does it within Liquid War as it is running and not in an
external independant program.
Time handling
Time handling is fundamental in a game. Time is used for visual effects
(waves...) during the game, it's used to generate some pseudo random
stuff, well, it's used everywhere!
Note that on the client, I use 2 "different" clocks. The first counts
the "real" time, in seconds. The second one is counts "rounds" and is
incremented by 1 at each game round.
* srvtime.c / srvtime.h: code used to handle time on the server, where
Allegro's functions are not available.
* ticker.c / ticker.h: sets up a timer callback.
* time.c / time.h: functions to know how long the game has been run‐
ning, knowing that it can be interrupted.
In-game utilities
These are various utilities use to monitor and control the game while
one's playing.
* capture.c / capture.h: code used to capture the video output of the
game and store it in .bmp files while playing.
* checksum.c / checksum.h: utilities to generate a checksum from a
given game state. Used in network code to make sure all the clients
stay synchronized.
* code.c / code.h: This file contains the code to handle key presses
during the game. That's to say the pause key for instance.
* profile.c / profile.h: provides tools to calculate how fast the game
is runnning and what operations slow it down.
* watchdog.c / watchdog.h: this module waits for "secret codes" to be
typed while the game is running, and traps them.
Command line handling
OK, now to all the UNIX guys, I *know* there are many ways to do things
in a better and simple way than I did. But keep in mind that in 1998,
under DOS, I had a rotten command line and even now I need everything
to work on both UNIX and Microsoft platforms.
These utilities are not perfect, but they work, that's all I ask them.
* basicopt.c / basicopt.h: handles basic command line parameters such
as "-v" or "-h".
* parser.c / parser.h: contains code to parse and analyze the command
line parameters.
* startup.c / startup.h: analyzes the command line parameters and
stores them into global variables.
Locale support
Liquid War now has locale support. Basically, all the labels and texts
in the UI are stored in constants. There's simply file per language.
Note to translators: if you decide to translate the menus in another
language, keep in mind that all the translations must fit in the vari‐
ous buttons and textboxes. The best resolution to test this - the one
where letters take most place - is 640x480.
* lang.c / lang.h: contains code to handle language dependant stuff.
* langen.c / langen.h: contains code to handle English specific stuff.
* langfr.c / langfr.h: contains code to handle French specific stuff.
Log and various messages
OK, the API of the log routines is a piece of crap. Now I'm simply too
lazy to change it. It works, that's all I ask.
BTW, there's a clear advantage in using custom-made log functions
instead of plain calls to "fprintf(stderr,...". It might not be obvious
for UNIX users, but think about Windows. Nothing like a "tail -f"
there, nor a proper output redirection system. When a user clicks on
the Liquid War icon, I want "console" information to be logged in a
file!
* log.h: common header for logcli.c and logsrv.c.
* logcli.c: contains code to display messages on the console. It's
usefull for console may have different behaviors when the games is
used on different platforms. This file is used to compile the
client.
* logsrv.c: contains code to display messages on the console. This
file is used to compile the server, which does not use Allegro at
all.
* popupgen.h: common header for popup functions.
* popupw32.c: code to handle popup on the Win32 platform. Popups are a
must-have under Windows for error diagnostics, since the average
Windows user never gives any look at any log file...
Macros, utilities and string support
As usual, I needed to prepare a small set of usefull macros.
* macro.h: contains basic wrappers/macros for snprintf like functions.
This mostly to ease up string manipulation which is - as always - a
nightmare in standard C.
* path.c / path.h: code used to handle filenames and paths, for
instance remove path and file extension from a filename.
It's also important to note that Liquid War uses snprintf instead of
sprintf, for using the latter is very likely to cause buffer overflows.
Under Linux glibc provides this function but Microsoft does not provide
it natively on Windows. Therefore I used a third party snprintf imple‐
mentation by Mark Martinec: http://www.ijs.si/software/snprintf/ and
its source is available in the ./utils directory of Liquid War source
distribution.
Byte order and endianess
As you might know, PC Intel based computers are "little-endian" while
Sun Sparc stations and Mac computers are "big-endian". This is an issue
for LW since in network games maps are transmitted in binary format.
Therefore I needed to set up some (un)serialization fonctions.
* serial.c / serial.h: code used to transform integers and map headers
into an uniform cross-platform byte stream which is readable by both
little and big endian machines.
Thread support
Liquid War does have thread support, but it is a "limited" thread sup‐
port. I mean that the game is generally monothreaded, but a few func‐
tions use threads. For instance, calls to the meta-server are done
within threads.
Basically, I do not really enjoy programming in a multithreaded envi‐
ronnement. So when possible, I chose the monothread path, and used
threads only where I simply would not be able to find another accept‐
able solution.
I also needed to use some mutexes to prevent crashes in the user inter‐
face.
* mutxdos.c: provides fake mutex support under DOS. This module is
here only to make compilation easier.
* mutxgen.h: header for mutxdos.c, mutxunix.c and mutxw32.c.
* mutxunix.c: provides mutex support on UNIX.
* mutxw32.c: provides mutex support on Win32.
* thrddos.c: provides fake thread support under DOS. This module is
here only to make compilation easier.
* thrdgen.h: header for thrddos.c, thrdunix.c and thrdw32.c.
* thrdunix.c: provides thread support on UNIX.
* thrdw32.c: provides thread support on Win32.
Launching external programs
Liquid War might sometimes launch external programs. This is (for secu‐
rity reason) not a default behavior and has to be activated and config‐
ured by yourself, using the "-callback" command line option on the
server for instance.
* execgen.h: header for execunix.c and execw32.c.
* execunix.c: code to launch external programs on UNIX.
* execw32.c: code to launch external programs on Win32.
* exec2.c: code to launch external programs within the client, without
any interaction with the user, ie no unwanted popping window for
instance.
Low-level network code
There are network packages for Allegro, but I decided not to use them.
Socket support is not that hard to implement under UNIX and Win32 and
besides, I've done it for my job recently, so I just knew how to do it.
Another reason which decided me to code my own toolbox is that I did
not want Liquid War to have external dependencies - except Allegro of
course. This way, UNIX gamers to not have to set up and/or download a
specific network library. It's also easier to integrate the game in
projects like Debian if it has few dependencies.
This network code is not a masterpiece, it's just a little set of tools
that have proven to work. That's all.
BTW, it's important to notice that when linking with Allegro, most
blocking UNIX calls ("sleep" or "recv" for instance) stop working: they
alwasys return immediately. This led me to implement weird ugly hacks,
like calling "recv" in a loop until it gets what it wants... This is
theorically and practically a performance killer, but I found no other
way to fix this. And FYI, this is not an Allegro bug, it's a feature
8-)
* dnsutil.c / dnsutil.h: wrapper code to issue DNS requests, without
having to handle the hostent struct.
* sock2cli.c: sode used to wrap low-level network function on the
client.
* sock2gen.h: header for sock2cli.c and sock2srv.c.
* sock2srv.c: code used to wrap low-level network function on the
server.
* sockdos.c: network API for DOS.
* sockex.c: netowrk routines shared by sockunix and sockw32.
* sockgen.h: header for sockdos.c, sockunix.c and sockw32.c.
* sockunix.c: network API for UNIX.
* sockw32.c: network API for Win32.
High-level network code
These files contains network utilities which are Liquid War specific.
* chat.c / chat.h: functions used to handle chat messages in network
games.
* keyexch.c / keyexch.h: functions to send and receive keys to the
server. Used on the client.
* netconf.c / netconf.h: code to send and receive the config of the
clients over the network.
* netkey.c / netkey.h: contains some tools to manipulate key strokes
over the network.
* netmap.c / netmap.h: code to send and receive the maps over the net‐
work.
* netmess.c / netmess.h: contains a parser to interpret plain text
messages. Used when exhanging information over the network.
* netplay.c / netplay.h: contains the code to set up and start network
games.
* network.c / network.h: contains some network related functions and
constants used on the client.
* ping.c / ping.h: code used on the client to estimate the average
ping time with a server.
* protocol.c / protocol.h: contains the sequence of messages send and
recevied by the client when connecting on the server.
* startinf.c / startinf.h: contains struct and tools to handle some
network informations while starting a network game.
Communication with the meta-server
The meta-server is called by both client and server. Basically, the
server registers itself, and the client asks for a list of servers.
The meta-server itself is just a set of simple PHP scripts with a sim‐
ple MySQL database. I chose PHP because my provider allows execution of
PHP pages, that's all.
The protocol is *very* basic, and uses HTTP 1.0 for requests. Answers
are received in plain text, with one information per line. There's no
garantee that this would work with any HTTP server, but experience
proved that it works with my provider 8-)
* httputil.c / httputil.h: low level functions to handle http
requests.
* wwwcli.c / wwwcli.h: code used on the client to communicate with the
meta-server.
* wwwsrv.c / wwwsrv.h: code used on the server to communicate with the
meta-server.
Server code
The Liquid War server is a rather small program. The only thing it does
is accept new players, transmit map and game parameters between them,
and then "replicate keys".
By "replicate keys" I mean that the server asks each client what keys
have been pressed during the last round, and then dispatches this
informations to all clients. This implies that the server has abso‐
lutely no idea of who's loosing, who's winning, etc...
All the "logic" of the server is coded in these files, the rest is only
utilities and helper functions.
* server.c / server.h: main code for the server (equivalent of main.c
for the client).
* srvchan.c / srvchan.h: code used to handles channels on the server.
A channel is associated to a given computer and may manage several
teams.
* srvcont.c / srvcont.h: global network controler used on the server.
* srvteam.c / srvteam.h: code used to handle teams on the server.
Bugs
Report a new bug
If you have troubles with Liquid War 5, if you think it is a bug, and
if it is not described in this file, then just send a (precise...)
decription of your problem to the Liquid War user mailing list.
Besides, it happens that now most bug reports come from the Debian
tracking system "http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=liq‐
uidwar". Thanks to the Debian users and maintainers, it's a very valu‐
able feedback source.
Additionnaly, on online bug tracking system has been set up. It uses
Flyspray http://flyspray.rocks.cc/. It's accessible on
http://www.ufoot.org/bugtracker/ or "http://www.ufoot.org/bug‐
tracker/index.php?project=2". I try to collect everything here : bugs
reported on the mailing-list, bugs from Debian, and bugs I found
myself. Alternatively you can report bugs directly on it 8-)
Network
Network support in Liquid War is far from being perfect, so there are a
bunch of little problems which can appear. Basically, once the game is
correctly started on a LAN, you should have no problems, but getting
the game started might be difficult.
Mouse does not work
Some users reported that they were unable to control the Liquid War
cursor with the mouse. Well, the answer is a typical Microsoftish "this
ain't a bug, it's a feature!".
More seriously, you're supposed to move the cursor with the keyboard in
Liquid War. There's no way to handle the cursor "like a mouse pointer"
(*). This is due to:
* Severe limitations in the Liquid War core algorithm.
* The fact that moving the cursor "too fast" would really change the
gameplay of Liquid War. As a Liquid War integrist 8-) I can tell you
the game would really not be the same if you could move the cursor
as fast as you wish. It's part of the game that sometimes it takes
you ages to recover from a strategical mistakes. You need to think
twice before going to the very end of a level. That's strategy. At
least that's how I view things... Anyways as I mentionned above
there's a limitation in the core algorithm.
(*) This is not perfectly true, there's a way to control the cursor
with the mouse, but it's designed for the case "4 people want to play
on the same computer and one single keyboard is not enough". Control‐
ling the cursor with the mouse in Liquid War is possible but yet rather
hard to master 8-/ Try it and you'll understand what I mean. This mode
can be set up in the "Teams" menu.
Game does not start
On non UNIX platforms such as Windows or DOS, Liquid War is distributed
in a .zip file. It's IMPORTANT that you unzip the .zip files with an
"unzipper" which preserves the directory structure. Most install prob‐
lems under Windows come from broken unzipping programs which extract
all files in the same directory... WinZip 8.x or the unzip32.exe util‐
ity that comes with DJGPP are both able to uncompress Liquid War .zip
files correctly.
On Liquid War 5.5.9 and later, the Windows version should detect this
problem automatically and warn you with a message which basically says
something like "Unable to load datafile. Are you sure Liquid War is
correctly installed?". If you get this message, you need to reinstall
the game by unzipping it with a "correct" unzipping program which does
not wreck directory structrure up.
Interference with other Windows programs
It's been reported that Liquid War can run very slowly on Windows when
some other programs (Mozilla for instance) are running. So if Liquid
War's menus seem to be really really slow, then try to shut down other
applications and run the game again.
This problem does not seem to apply on GNU/Linux - at least if you do
not run 300 daemons together on your machine 8-)
Datafile bugs
Sometimes there are some problems when compiling the datafile, this
includes:
* The liquidwarcol, liquidwarmap and liquidwartex utilities might
freeze or segfault. Typing "make" again often solves the problem.
* The background image sometimes ends up using the wrong palette,
which has a very nasty consequence: it looks ugly.
These bugs are quite hard to get rid off, since I can not reproduce
them easily. The good solution would be to completely rewrite the liq‐
uidwarcol, liquidwarmap and liquidwartex utilities.
Midi does not work on OSS
Preamble
IF your midi music on Liquid War, or indeed any other Allegro game,
doesn't work and you are using the OSS (Open Sound System) drivers
(these are the sound drivers which come with the standard kernel dis‐
tribution), this may well be because Allegro only supports "FM synthe‐
sis" and not "wavetable" when it is using OSS. FM synthesis is a very
old method of making sound from MIDI and has long since been replaced
by wavetable synthesis, with the net result that it's quite possible
you've got OSS MIDI working nicely in other applications without having
FM support set up at all. This is what I found. (It has to be said that
I didn't find the FM sound quality quite as bad as people have said,
though).
In this situation, it looks to me like you have the following choices:
Hack Allegro...
and for the rest of us...
Use Allegro's DIGMID midi driver...
Get an FM driver up and running...
* Find out which FM driver is appropriate for your sound card. If you
have distribution-specific tools and docs for setting up sound, try
those. If not, you will need to be familiar with the knowledge in
the Sound-HOWTO and Kernel-HOWTO i.e. know how to compile kernels
and modules and deal with sound drivers.
* Look through the OSS modules in 'make menuconfig' and see if any‐
thing catches your eye. See if there is any specific documentation
on your sound card on http://www.linuxdoc.org. Do a few web
searches. For my AWE64, I use the OPL3 driver.
* Compile and install the FM driver module, or set up your system to
use the new kernel if you want to compile the driver in.
* Load the module, or boot your new kernel. It is very important that
you pay attention to what is said in the 'help' for your FM driver
in 'make menuconfig' and read any necessary files in the Documenta‐
tion/sound/ directory. For example, I just had a nice half-hour won‐
dering why the hell my FM wasn't working now when it had been before
- with the OPL3 driver, you have to give the option io=0x388 to ins‐
mod. Which is stated nice and clear in the docs, but of course I had
forgotten since then. You can prevent such happenings by recording
options permanently in /etc/modules.conf - see the manpage etc.
* Try the game. If it's worked you will hear particularly beepy music.
Enjoy!
Opl3 occult FAQ
--IMPORTANT-- If you are using Liquid War, your FM will only work if
you go to the map 'Elephant inside a boa' and proceed to chase each
other round in circles for at least 10 minutes. This cures a bug in the
design of the OPL3 interface which conflicts badly with the core Liquid
War algorithms. How the hell the music hardware even knows about the
core algorithms I don't know, but that's what I made of the now-defunct
opl3-occult-FAQ, from which here is an excerpt:
Many roads a man must take. Those with one-track minds are DOOMED, I
tells ya.
---- The Liquid War algorithm calculates distances to one place, the
cursor.
And:
Man or machine, face or code, must stand strong and solid; must not
just ooze away as slime.
---- We think it might just take objection to the whole 'slimy' nature
of the LW beings. As well as it being LIQUID War.
So, our carefully tailored approach, is to firstly have the players
going in all the possible different directions evenly by moving around
the map in circles, and secondly to divert the opl3's attention from
the general slimy liquidness of it all by emphasizing the solidity,
reality, and natural goodness of that classic tapestry: an elephant
inside a boa.
That and it's a f***ing ace level.
Checksum errors
The Liquid War server is a "light" servers which - to some extent - has
no idea about what is going on in the game. It simply replicates key
strokes between clients and each client maintains its own game state.
Normally, the game is designed so that given the same user input, it
will behave exactly the same.
However, it happens that sometimes 2 clients can behave differently,
and this is a (severe) bug. One consequence is that messages reporting
"Checksum errors" appear on the server's and on the client's console
output. This bug appears when using non-default rules settings. Basi‐
cally, if someones tweaks his rules, then the checksum errors appear.
Of course I double-triple checked that options were correctly sent on
the network, but, well, could not fix the bug. Yet. The short term
solution seems to play with default factory settings...
I'm highly interested in bug-reports concerning this problem.
To do
Bug-fixing
In its latest releases Liquid War is quite stable IMHO. However there
are still some issues with network under Windows for instance. I'm
aware of these bugs and I'm trying to fix them but this does really
take time.
I always welcome bug-reports and patches, as making Liquid War W 5.x.x
as stable and bug-free as possible is really important to me - and most
of the time players also appreciate stable programs 8-)
The most important bug-fixing area is probably cross-platform support.
That is, make sure that the game runs fine on every supported OS. For
instance, it's quite common for Mac OS/X and/or FreeBSD users to
"crash" the game. This rarely happens on GNU/Linux, just because it has
been so much more tested on this platform. This applies to Liquid War
itself and also, to some extent, to Allegro.
New features
Let's be clear: no new features in Liquid War 5. It's bloated, compli‐
cated, old, uninteresting to hack. All new features should be found in
Liquid War 6.
Liquid War 6
Since summer 2005, Liquid War 6, a complete rewrite of Liquid War, is
on its way. See http://www.gnu.org/software/liquidwar6/ or
http://www.ufoot.org/liquidwar/v6 for more informations.
Work in progress
Note on releases
Whenever Liquid War is released, I usually pass the good news to Fresh‐
meat ( http://freshmeat.net/projects/liquidwar/ ). Then all releases
are accessible from the main download page, which is
http://www.ufoot.org/liquidwar/v5/download.
Releasing the game takes time, for I want all binaries to install prop‐
erly and sources to compile cleanly. Therefore there might be some
delay before the time coding is over and the time a release is actually
ready. So for impatients and/or for people who need to test out the
very latest versions (eg someone who wants to compile the game on a new
platform), it's possible to access the source repository directly.
About GNU Arch
I use GNU Arch (Tom Lord's Arch in fact, http://www.gnu.org/soft‐
ware/gnu-arch/ ) instead of the previously used CVS. Indeed, tla has
some very fancy features such as signing patches with gpg, and I'm
tired of suffering CVS limitations.
So FYI the previously active CVS repositories, on Sourceforge and
Savannah, are currently unmaintained.
How to get latest releases
* Step 1: read the excellent Arch tutorial http://reg‐
exps.srparish.net/www/tutorial/html/arch.html if you are not famil‐
iar with tla. I admit there's a steep learning curve, but it's yet
clear and understandable.
* Step 2: point on the repository, which is accessible (read-only) on
http://arch.sv.gnu.org/archives/liquidwar/.
A typical set of tla commands would be:
tla register-archive http://arch.sv.gnu.org/archives/liquidwar
tla get -A liquidwar@sv.gnu.org liquidwar6--stable
If you are interested, I can open this repository in read/write mode,
however one of the points of GNU Arch is that it allows cooperative
developpement with multiple depots, so this isn't mandatory. And any‐
ways, importing myself patches received by email has never been a real
burden.
Besides, most developpement is now done on Liquid War 6. See
http://www.gnu.org/software/liquidwar6/ or http://www.ufoot.org/liquid‐
war/v6 for more informations.
Copying
Liquid War is a multiplayer wargame.
Copyright (C) 1998-2007 Christian Mauduit (ufoot@ufoot.org)
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MER‐
CHANTABILITY or FITNESS FOR A partICULAR PURPOSE. See the GNU General
Public License for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
AUTHOR
Christian Mauduit <ufoot@ufoot.org>
v5.6.4 Liquid War(6)
