Home | Rules | Authors | Mailing lists | Menus and hot keys | Network game | Command line parameters | Platform specific issues | User levels | Core algorithm | Source code | Bugs | To do | Copying

# 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-)

## Artwork

It's hard to find people to do that kind of thing. Artists are indeed pretty rare, at least artists who wish to create stuff freely... So if you feel like adding some theme support to Liquid War, this could *really* help. I used the textures I had but it would be nice if one could have a "space" ambiance, an "ocean" ambiance or a "desert" ambiance. This could really make the game better I think.

Musics (in midi format) are also appreciated. Tim Chadburn spontaneously contributed the first midi files, and it really pleased me 8-)

## New features

I regularly receive requests for new features in Liquid War. Of course I do not have enough time to implement them all, so they land in my "todo" list. However, most "major" evolutions are now planned for Liquid War 6, since the code in Liquid War 5 is bloated as hell. It's all right to debug it and code minor evolutions, but that's all.

However, here's a list of what "could be" in the next Liquid War 5.x.x releases, although it might never be implemented there and come later with Liquid War 6:

- Network enhancements. Network in LW5 is somewhat buggy and hard to use, improvements wouldn't harm.
- Theme support. This would be a way to get rid of the ugly current fonts and menus.

## Liquid War 6

Liquid War 6 *is* planned.

This being said, it's important to note that:

- Not one single line of code has been typed yet 8-)
- Until 6.0.0 is released, 5.x.x remains *the* stable and useable branch. 5.x.x will be maintained as long as needed and will probably be maintained (bugfixes I mean) even when 6.0.0 is ready. So if you want to contribute some maps, graphics, or anything else for the current 5.x.x branch, don't fear that your work will be lost before 2 months because all interest went off 5.x.x and everyone is using 6.0.0 instead. 5.x.x is here to stay.
- 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 5 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.
- Liquid War 6 won't run on "slow" computers anymore. I mean it will require some accelerated display (OpenGL for instance) to run. This is IMHO acceptable since LW5 will remain available. People with slow computers will always be able to run LW5 instead of LW6. But if some nice fancy features are to be implemented in 6.x.x, one needs to drop support for low-class machines.

I also plan to use different technologies and languages to code LW6. As of today, I have a rather precise idea of what tools I'm going to use, but *before* I really start coding LW6, I'd like to test these tools on a "real life example". This "real life example" will probably be a rewrite of the good old HP48 Babal (www.ufoot.org/babal/) for desktop computers (GNU/Linux and Windows). Here are the tools I plan to use:

- "GNU framework". I mean that I'll try to make LW6 as close as possible to the GNU standards. This has the advantage that it's then much easier to make the program operate in a GNU environment. For instance LW6 will use GNU automake/autoconf, GNU gettext, and have a GNU-ish source tree. This should save time in the long run, the experience I have on LW5 teaches me that there are a bunch of low-level boring tasks (generating documentation in several formats, generating source tarballs, handling i18n/l10n) which are done automatically by GNU tools, and it's a good idea to re-use other people's work and be standard compliant.
- Standard C language for the core algorithm. This is where I might use a few dozen lines of code from LW5. C is fast, portable, and very adapted to this kind of code.
- Assembly for the core algorithm on Intel architectures. LW5 does this too, and it's even faster than C. However, this assembly code will be written only when the equivalent algorithm is available in C. Think of it as an optimization, not as a base component.
- OpenGL display. I'll probably use Glut (www.opengl.org/developers/documentation/glut.html) which is portable and does enough stuff for me. I do not think I'll need a wrapper on it and/or a more general library like SDL.
- "mod" music. Let's be clear: MIDI sucks. Well, more precisely, it sucks on standard desktop computers (the kind of computer everyone uses). Most of the time mod files sound much better, and have the advantage of sounding the same on every computer. MikMod (mikmod.raphnet.net) will probably be used.
- Scheme as the glue language for all this. I'll very certainly use Guile (www.gnu.org/software/guile/guile.html). I'm strongly convinced that C is absolutely *not* adapted to code large scale programs, unless one uses an extension language. Guile solves this issue by offering a way to code some parts in scheme. You might wonder why I do not use another extension language. The excellent Python language (which I know better than scheme by now) would be a very good contender for instance. Well, to be honest, I'm very interested by Scheme and Lisp-like languages in general, and I've good reasons to think that once I master them, they'll simply be the languages I prefer. But this is enough Scheme advocacy 8-)

Of course, all this complete rewrite and new tools are not a goal in themselves. So here's the list of new features which are planned to be in LW6:

- Truecolor support. LW5 has strong color limitations (32 colors, not 32 bits colors but really *only* 32 colors) for textures and this won't be anymore in LW6.
- Map wrapping/tiling. You could have a map where the right and left border would "communicate". Any fighter leaving the map on the right side would reappear on the left.
- Several cursors per team. This feature is easy to implement even with the current algorithm, but isn't possible to implement in a reasonnable time because LW5 is bloated. LW6 should have it. The fighters would simply follow the closest cursor.
- Fancy multiplayer options such as team alliance.
- Fancy 3D displays. This could be very nice combined with map wrapping/tiling. You could imagine playing on a sphere, on a tore, on a Moebius ring...
- Maps could be deeper in some places. In a deep place armies would take less surface but would be stronger.
- Of course, anything that LW5 does (unless maybe running under DOS), LW6 will do it 8-)
- Any idea is welcome! Although I can't garantee all ideas will be implemented, there are at least more chances that it happens given the fact that LW6 should be much easier to hack and enhance.

So, that's it for LW6 for now. It's still vaporware, but believe me, some day you'll be able to download liquidwar-6.0.0.tar.gz. Until then, any idea, suggestion or help is welcome.

This documentation is also available on: www.ufoot.org/liquidwar.