[liquidwar-user] Re: Liquid War tenth birthday

[Kasper Hviid]

On 7/5/05, Christian Mauduit <address@hidden> wrote:

> I'd opt for changeable resolution again. Basically OpenGL will offer
> easy builtin stretch functions.

Changeable resolulution sounds like a good choice. Most players expect
to be able to change resolution. Further, changeable resolution will
both satisfy people with outdated computers, and people with new ones.

The bad thing about changeable resolution is that the graphic suffers
from being resized. However, if we design the graphic with a certain
resolution in mind, we will be able to play the game at that
resolution with unresized graphic. This can be done in two ways:

1) The level textures has the same size as the games standard
resolution (800x600?). As long as the user sticks to the standard
resolution, the textures won't be resized. At highter resolution, the
graphic will just be upsampled.

2) The level textures has the same size as the games recommended
resolution (1024x768?). Setting the resolution higher than the
standard resolution gives the graphic more details. But the game will
also be a heavier download.

I'm not quite sure how big the textures should be. I LW5, big textures
would often slow the game down.

> > 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.

I am interested! Speaking of text, it would be nice if the font in LW6
had foreign characters like æøåö.

> 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.

Okay, sounds like the GPL is safe enough!

Maybe the levels should be kept as .png files instead of being built
into the binary? It would make it possible for gamers to see how the
levels works, or recycle them in their own levels.

On 7/5/05, Christian Mauduit <address@hidden> wrote:
> 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            \/      \___/ \__)
> 
> 
> _______________________________________________
> liquidwar-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/liquidwar-user
>