[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-liquidwar6] liquid wars on mobile phone

From: Christian Mauduit
Subject: [Help-liquidwar6] liquid wars on mobile phone
Date: Sun, 06 Jan 2008 15:00:02 +0100
User-agent: Icedove (X11/20071020)


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?


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

Have a nice day,


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]