Liquid War (v5.6.2) - 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 (http://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
    (http://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 (http://mikmod.raphnet.net) will
    probably be used.

  * Scheme as the glue language for all this. I'll very certainly use Guile
    (http://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.

