Here's my .plan file, which describes what I (Christian Mauduit) have 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.
Note that the information here was written in summer 2005, it might or not be accurate now, as the main reason for plans to exist is that people never follow them. I'm no exception.
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:
Liquid War 6 will use a different technical framework than Liquid War 5.
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.
Liquid War is not a 3D game, so why use OpenGL?
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.
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-)
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.
There are many things that could be done easily:
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 a poor game?".
It's a good game because:
It's a poor game because:
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:
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.
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.
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!