[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-liquidwar6] liquid wars on mobile phone
[Help-liquidwar6] liquid wars on mobile phone
Sun, 06 Jan 2008 15:00:02 +0100
Icedove 18.104.22.168pre (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
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
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
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> - 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 (__/ \/
|[Prev in Thread]
||[Next in Thread]|
- [Help-liquidwar6] liquid wars on mobile phone,
Christian Mauduit <=