Re: [liquidwar-user] Liquid War tenth birthday

[Christian Mauduit]

Hi,

For those who didn't read it yet:
http://www.ufoot.org/liquidwar/liquidwar6/.plan

Kasper Hviid a écrit :
> It's great to hear that LW6 are going to be made - I had almost given up
> the hope! LW is the only Open Source game I has kept playing, and it
> truly deserves a new version!
> 
> 
> I would be happy to supply some graphic for LW6. I have "a few"
> questions about the subject:
> 
> 1) Should I get my ass moving, or should I wait a bit? The .plan do say
> year 2008 for the graphic.
Wait a bit. Let's say at the beginning of 2006 I'll be able to know what
sort of graphics is required (3D, vectorial, raster bitmap, fonts...)

> 2) Will LW6 have a fixed resolution, or will the user be able to change
> it? I can just make the levels so big that they can be sized down to
> whatever will be needed, but it would be nice to know anyway.
I'd opt for changeable resolution again. Basically OpenGL will offer
easy builtin stretch functions.

> 3) Will the levels be in the same format as in Liquid War 5, with a
> fullcolor image for eyecandy, and a black and white image to define the
> wall?
There will probably be at least a compatibility mode or a "converter".
Maps designed for LW5 should work for LW6 one way or another. I'm not
going to waste all the work that has been done on LW5 maps.

> 4) You say that one of the sucking parts of LW5 is its ugly retro look.
> Is there anything specific you want instead? I think about title, text,
> gui, and other eyecandy.
Some fancy texts/fonts and a general set of colors (a "palette") would
be nice to start with. Again, no big hurry yet.

But if you're interested I can give you more hints on what's short-term
needed.

> LICENSE
> On your site (ufoot.org/liquidwar/doc/userlevels) you say that the
> artwork in the official game has to be under the GPL or a similar
> license. It is good that the artwork has to be under a proper licence -
> many open source games forgets that. But I'm unsure how a licence
> designed for source code will legally fit on a piece of graphic.
> A better choice might be the Creative Commons Attribution-ShareAlike 2.5
> License:
> http://creativecommons.org/licenses/by-sa/2.5/
I asked the FSF about this long time ago, the answer was: if your game
is GPL and it requires cool graphics to work, put the graphics under the
GPL. I think it's a hudge overhead (and mess) to double licence things
in the same project.

> A BIT OF BRAINSTORM
> It could be possible to browse the other online players homemade levels,
> or chat with them. The players could also create a profile, so they knew
> who they are fighting.
That's a cool idea, be able to browse other levels before playing them.
Could even store them in a shared repository (as blobs in MySQL for
instance). I'll think about that.

> It would be nice with a turnament mode, where a series of games are
> played in a row. Besides that, I hope the simple gameplay of Liquid War
> 5 will be somewhat intact. I think the games main feature is its
> simplicity.
I don't think you risk much, I'd opt for simplicity too.

> 
> 
> By the way - Happy birthsday, everyone! :-)

BTW, .plan copy-pasted below:

----------8<------------------------------------------------
So what's up?

Here's my .plan file, which describes what I've planned for Liquid War
6. There's no garantee that what's written here is a precise description
of the real future, however it should give a good idea of what I have in
mind.
Complete rewrite

Liquid War 6 will be an almost complete rewrite. I mean that common code
between branches 5 and 6 might end up in representing 0% of the total
code. I think this is a wise decision, for the current code is really
hard to maintain, and would not survive any serious cleanup. LW5 was
first written in 1998, for DOS, when I had much less experience in
programming. In 7 years I - and other people as well - hacked major
enhancements in it such as cross-platform support, network games, and if
you compare release 5.0 with the latest 5.x.x release, you'll see that a
bunch of things have changed. I had never expected I would patch and fix
this game for so long, and it's no surprise that it's bloated today.

FYI, here's a list of what makes LW5 unsuitable for major improvements
without a complete rewrite:

    * global variable hell. Lots of things are stored in globals.
    * hard-coded C GUI. Read src/level.c to get an idea of how horrible
it is.
    * hard-coded 256 colors paletted mode. A clever bet in 1998
(performance...). Not anymore.
    * generally bloated code. Makes bug-finding very tricky.

Technologies

Liquid War 6 will use a different technical framework than Liquid War 5.
Script + standard C + assembly

It happens that coding a large project in pure C is a waist of time, if
possible at all.

If one applies the standard 80/20 rule to a computer game, one might
state that 80% of the code eat up 20% of the CPU and the other 20% of
the code eat up 80% of the CPU, the former being high-level glue code
and the latter being low-level algorithmic code.

With Liquid War, one could speak of the 99/01 rule. I mean that 99% of
the CPU time concerns only 1% of the code, and vice-versa. Basically,
Liquid War has a very CPU-greedy core algorithm, still spends a fair
amount of CPU displaying stuff (but this is delegated to the low-level
game programming library) and the rest is totally unsignificant, in
terms of CPU. Point is this "rest" represents the vast majority of the
code, and also represents the very same buggy code I spend nights to
patch on Liquid War 5. I'm talking about network code, GUI, and other
high-level glue-code which are currently being written in C.

This idea is to write all this in a convenient scripting language. There
won't be any impact on performances. I can't garantee Liquid War 6 will
be blazingly fast, but for sure it won't be the scripting language
fault. And of course if, as in Liquid War 3 and 5, I feel the need to
implement some stuff in assembly for performances issues, I will do it.

We end up with a multi-language architecture: script + C + assembly.

My guess is that I'll use Scheme as an extension language. Python would
be a good choice too. Let's say I'll give Scheme a chance, and if it's
really not adapted, I'll switch back to Python. The point is that today
I know Python and don't really know Scheme, but, well, it's always a
pleasure for me to learn new things. It's fun.

So what is planned today is that Liquid War 6 will be a Scheme program,
which will call callbacks functions written in C and/or assembly. These
functions will do all the low-level time consuming algorithmic and
graphical stuff. The rest of the code being entirely scripted.
OpenGL

Liquid War is not a 3D game, so why use OpenGL?

    * it's a very convenient way to access video hardware acceleration
with XFree86.
    * low-end computers and/or computers without 3D acceleration can
still run Liquid War 5.
    * I'm interested in learning/using this API 8-)

This choice implies that I won't use Allegro anymore. Allegro stays a
very convenient library and I would recommend it for it's excellent,
easy to learn, powerfull, and stable. But for the needs of Liquid War 6
I'll use something else (because of OpenGL). I first thought of using
GLUT but I might end up simply using SDL. The idea is just fo have an
OpenGL wrapper which sets up OpenGL in a similar manner on all
platforms, and handles basic things such as mouse or keyboard.
CSound

I've got two excellent books on Csound, and the will to learn how to use
this tool.

I'll probably use Csound for a number of things, ranging from "bubbling
sounds" to full blown music. Stay tuned 8-)
Functionnalities
Visual enhancements

Of course Liquid War 6 will look nicer than Liquid War 5, blah blah
blah. What do you think?

Maybe I'll try to use some OpenGL features to make it possible to play
on a ball, on a Moebius ring, or other fancy things. I have zillion of
ideas, future will decide which ones will be implemented first.

To make it clear, visual enhancements aren't my top-level priority.
However I'll try and make room for these enhancements, and prepare the
terrain correctly. So it's possible that the first releases of Liquid
War 6 won't be that much better than Liquid War 5, but at least Liquid
War 6 will have the possibility to evolve. Something Liquid War 5
doesn't have.
Rules enhancements

There are many things that could be done easily:

    * several cursors for one team
    * alliances between teams
    * deep places on a map, where more liquid can reside
    * circular maps which "connect" the left border to the right one
    * ...

As for graphical improvements, this is not my top-level priority.
Simply, I'll make the game ready-to-improve. Again, all these
enhancements are very hard to code in Liquid War 5, else I would already
have coded them.
Network enhancements

That's my top-level prioriry.

Why is that? Well, think of Liquid War in terms of "what makes it a good
game?" and "what makes it suck?".

It's a good game because:

    * the idea is original
    * the gameplay is addictive
    * you can play on a LAN
    * all the family can play
    * it's cross-platform
    * it's Free Software

It sucks because:

    * it's somewhat ugly and has a retro "back in the eighties" look
    * network games are slow on Internet
    * there are not enough active Internet servers

For the ugliness, well, OpenGL and some artwork should make it. But for
the network, what's the real problem?

The real problem is that in the current situation, the server needs to
have all "keystrokes" before doing anything, and all players must be
connected before a game starts. Here's what I plan to do to fix this:

    * players will be able to connect on a game "on the fly". This is
done by most online games, and it's IMHO a required features for a
network mode to work on Internet (not speaking of local networks, but
real wide online gaming). How this will fit with Liquid War's rules is
not totally decided, but I already know of several way to achieve this.
    * I'll implement an "anticipation" system "à la" U61. This means
that no matter if a remote player has a poor network connection, things
will behave as if everything was fine. Internally, the system keeps 2
images of the game. One which is "anticipated" and displayed to the
player, and one which is validated but outdated, kept internally. It's a
little hard to explain, consumes twice as much CPU and memory, but it
works. It happens that today the lacking ressource for playing Liquid
War online is more on the network side than on the local CPU and memory
aspects.
    * I'll take it to the next level and implement a "peer-to-peer-like"
network model, in which any client can become a server. The idea behind
is that if a server quits the game, then a client takes its role,
letting the game continue for hours. This way one could virtually have a
never ending Liquid War game which would last weeks. I believe this
could be really cool. I also believe no proprietary game will ever
implement that, for in this model there's no way to force people to
access a centralized server, this server usually being the major key in
the business model of a company which sells proprietary software.

This third point will be the real enhancement of Liquid War with version
6. It's one of the very points which drives me to rewrite it completely.
First because it's impossible to implement it without some heavy work.
Then because I find it very motivating.
Hey, you forgot my idea!!!

Many gamers submitted suggestions, either by mail or by posting messages
on the mailing list.

Don't worry, I keep them. Not reading them here does not mean I won't
implement them. It simply means I won't implement them first. I first
need the game basically function before enhancing it with fancy stuff.
Road map

As I stated on the mailing list, when thinking about Liquid War 6, think
of years rather than months (unless I get fired, jobless, or spend
several months in a hospital with a laptop).

Note that this road map takes it for granted that I'll be the lone coder
on the project. It's unlikely that someone is going to help me for the
first stages, until there's at least something real, something playable.
Something that proves that the concept is valid. Besides, (real) team
work implies a significant overhead, especially at project start. It's
hard to figure out how to distribute tasks when the tasks themselves are
not clearly identified. But for the rest (starting in 2007 or 2008),
it's possible that external help might greatly... ...help!

    * 2005 : Project framework should be done. This implies that the
scripting engine is up and running, graphical mode works, config and
data loading work, basic menus are available. Nothing playable.
    * 2006 : Import the core algorithm from Liquid War 5, make the game
playable in "demo mode" ("à la" Liquid War 2), implement the network
"peer-to-peer-like" mode. At this stage, it will be possible to know
wether Liquid War 6 is true vaporware or not.
    * 2007 : glue all this together to make something usable by anyone,
heavy work on the GUI, on the options, on error checking, many bug
fixes. The goal is to have a game which is equivalent to Liquid War 5,
with the network aspects pushed to the next level.
    * 2008 : tadaaaaaaaaaaa! Release the game "publicly" - inform
Freshmeat 8-) - and enhance it with all the feedback from gamers (bug
reports and suggestions received since 1998). Work on artwork (both
graphics and musics). Write documentation.
    * 2009 : stabilize the game, patch it for all those things which had
been forgotten back then in 2005, optimize for speed, bug-fix bug-fix
bug-fix.
    * 2010 : stop maintaining Liquid War 5, invite Liquid War fans and
coders to a hudge party in my garden, sing all night, drink beers and
wine, teach Liquid War strategies to my 5 and 6 year old daughters,
remember the old times when Liquid War wasn't so cool 8-)
----------8<------------------------------------------------

Have a nice day,

Christian.

-- 
Christian Mauduit <address@hidden>     __/\__ ___
                                        \~/ ~/(`_ \   ___
http://www.ufoot.org/                   /_o _\   \ \_/ _ \_
http://www.ufoot.org/gnupg.pub            \/      \___/ \__)