[Help-liquidwar6] liquid wars on mobile phone

[Christian Mauduit]

Hi,

Here's a message I received on the info list (just a remark Chris, your 
message should go to address@hidden which is the general 
discussion list, address@hidden is a read-only newsletter with 
annoucements only).

> Hi everybody
>
> I've been thinking, would it be
> possible to implement liquid wars using J2ME (Java Mobile Edition).
> Wouldn't it be cool to be able to play liquid wars on a mobile phone?
> I could certainly implement such a port.
> I'm just not so sure whether phones have enough CPU power
> to handle the algorithm. What do you think?
>
> Have anybody tried, talked or thought about such an implementation?
>
> Cheers
>     Chris

And, my answer 8-)

Fundamentally, there's no real limitation for implementing Liquid War on 
Java, I've personnally hesitated a lot between plain C (the current 
choice for Liquid War 6, same as all previous versions) and Java. Given 
that there's now with gcj and GNU Classpath a correct implementation of 
Java, or at least pretty much sufficient for what needs to be done, it 
could have been done that way.

The reason Java wasn't used is that, believe it or not, Liquid War does 
really consume much much CPU. It looks simple but shortest path 
algorithms are not such a trivial thing. Liquid War adopts the stupid 
"brute force" way of doing things so the algorithm isn't complex, but it 
requires many CPU cycles. It could of course probably be optimized but 
well, good luck 8-) Liquid War 5 on i386 still uses assembly code, and 
it pays. So the conclusion is that you need to choose: LW could run on a 
mobile phone, but probably not running Java. It could probably run using 
Java, but not on a mobile phone... FYI when I first developped Liquid 
War 3, I developped it on a 386 SX @ 16Mhz, and it ran smoothly on a 
pentium @ 75Mhz. Not that I'm not ranting "Java is slow" bla-bla-bla, 
it's just that Liquid War does the very exact things Java is not really 
comfortable with. That is, heavy integer low-level work, and using 
pointers to perform by-reference modifications. The kind of things 
orthodox programmers won't do. Most performant Java programs use, at 
some level, high-level functions which perform fast so that the Java 
code itself isn't that relevant. Think of string manipulation, handling 
SQL requests, which is 99% of a web server's job. A good proof of this 
is that the strengh of Java is essentially the bazillion classes which 
come with it - and perform fast out-of-the-box, usually faster than any 
home-made I-reinvent-the-wheel implementation. But the core Liquid War 
algorithm can't use this, it's not about strings or high-level 
dictionnary objects, it's just plain 32-bit integer wizardry. If I had 
to port Liquid War to Java, I would certainly keep the core algorithm in 
C, and export it to Java using whatever wrapper there is. In fact, this 
is exactly what I've did with Liquid War 6, except I didn't use Java but 
Scheme (through Guile). And Guile is an order of magnitude slower than 
Java, and it doesn't harm. But this kind of implementation does not 
solve your mobile-phone problem (I suspect you need a pure Java 
implementation).

Still, if someone proves me wrong and does in pure Java a faster 
implementation than mine, I'll be just pleased and will happily switch 
to it, for sure.

The other good reason for not using Java is that graphical libraries are 
simply not portable, and whenever you find a correct implementation that 
does things fast enough, you end up learning that it has serious 
platform specific issues, requires native binary libraries to be loaded, 
and does not solve the "portability" problem at all.

Still, here are some hints of what I judge as being "doable":
1) make a separate, really "different from LW6" port, on Java, which 
would in fact use pretty much nothing from the current implementation, 
except the gameplay and possibly the levels (which are bitmaps, or 
bitmaps enriched with XML configuration files as of Liquid War 6). I 
suggest you concentrate on a Liquid War 3 -like algorithm, very simple. 
I could code the shortest path algorithm if you wished, and get to the 
point where the question "where does this fighter go?" can be answered. 
But I must admit I have no time for the rest (graphics and all the 
boring programming plumbery that any project carries as a burden). I 
have good reasons to think that you can achieve correct gameplay on 
100x100 maps, even in pure Java. Remember, it used to work in C on a 486 
DX2 66;
2) in all what I said, I assumed you needed a pure Java implementation. 
If it's not the case, you might be interested to know that the core 
algorithm of the game is plain standard C code, which does not require 
any external libraries but libc. And even that, with some quick hacks, 
could be removed, so that if you have a C compiler, even without 
standard GNU-compliant libs -> it works. The rest is only sugar-coating 
for humans, displaying stuff, handling input, network wizardry, and so 
on. So *if* there's a way to compile C code -> it will work;
3) any suggestion welcome 8-)

To answer your last question, I'm not aware of any existing LW 
implementation in Java - but I've surely discussed that point, though 
probably not on public mailing lists, and it was a long time ago.

I hope this answers your questions, and o not hesitate to subscribe to
http://lists.gnu.org/mailman/listinfo/help-liquidwar6

Have a nice day,

Christian.

--
Christian Mauduit <address@hidden> - http://www.ufoot.org/ ___ __/\__
Liquid War 6 - http://www.gnu.org/software/liquidwar6/     / _")\~ \~/
"Les amis de la vérité sont ceux qui la cherchent et non _/ /   /_ o_\
ceux qui se vantent de l'avoir trouvée" - Condorcet     (__/      \/