Re: What to do with Xconq

[Stan Shebs <shebs at shebs dot cnchost dot com>]

"A. Rick Anderson" wrote:
> 
> At 07:35 AM 02/17/2000 -0800, Stan Shebs wrote:
> >So every technology idea needs to be evaluated in terms of what it does
> >for making a good strategy game.  A change of implementation language,
> >or a reimplementation in a new language, is a huge step and a lot of
> >work to make happen, so it needs a correspondingly high payoff.
> 
> Yes and No.  I would agree with Jessen that all projects/products have a
> life-cycle.  Periodically, you are better off stepping back, taking the lessons
> learned, and re-writing from ground level up, similar to what you did when
> moving xconq from 5.x to 7.x.

(Actually, I was going to respond to Erik that having been involved in a
few corporate rewrites in my career, it's usually caused by the old code
having degenerated into an unmaintainable heap... comparing those to open
source projects, it's interesting to see that the public visibility of
the sources seems to stimulate programmers to make a little more effort
on code quality.)

> >I've looked at Java twice now.  While the language has a lot of good
> >features - it might even be called "Lisp done right" - I don't see that
> >the payoff is high enough to make it worthwhile to convert.
> 
> IMHO, the language itself isn't all that exciting.  Java's strength is the
> breadth of the libraries that come with the language and the ongoing
> innovation that is happening around and with it, just as cross-platform
> sound and image manipulation.
> 
> The ready accessibility to development tools on just about any platform
> is another delightful feature.  Cross-platform development goes down by
> an order of magnitude.

That's very true, and a key selling point for Java here.

> Locale and internationalization becomes a runtime, extensible, resource-file
> issue,  not a compile-time issue.  To add support for a new locale, you just
> add an additional text file.

Alas, for Xconq the problem is a little harder than that - much of the player
visible text is in GDL files, not in the code proper.  GDL needs its own
localization mechanism.  And then there's the text synthesis code in nlang.c...

> >Xconq has performance-critical areas; not for the standard game on a small
> >map, but when scaling up to larger games.  How much slower will a Java
> >version be?
> 
> No offense intended, but IMHO, this is a red-herring.  If we take the worst
> case scenario, that no amount of tweaking on the performance-critical
> areas turns out to be fast enough, we can always fall back to:
> 1) Java Native Interface (JNI) - take existing C code and wrap it,
> 2) Generate platform-specific native code for the major platforms, such
> Win-Doze, Linux, AIX etc.  With VisualAge, I can do this with the
> touch of a button.

How about Macs?  I don't recall VisualAge being available for it...

Performance-critical areas don't always segment neatly into separate
subroutines.  There would be issues of data conversion as well; Xconq
manages a lot of data internally.  Just look at the tcl-to-C difficulties
in the current code, and consider that none of those are in critical
sections.

A non-GUI Java test case occurs to me - AIs.  AIs have a pluggable
architecture, one could imagine writing an AI in Java and connecting
to it from C.  A good test of data conversion, since the AI wants to
get terrain data and such for its analysis.

> >I *have* found for Java is a couple of dead strategy game projects that
> >seemed to start out well, but then broke down - not clear whether it was
> >the language or the developer, but not encouraging in any case.
> 
> Another excellent point.  Could you point me out where these are.  Maybe
> I'm just a gawkier,  but one of the hallmarks of open-source is starting from
> a previous base of work.  I'd like to check these out.

Unfortunately, I must have bookmarked these on a machine I no longer have
access to, and a quick search via Altavista hasn't turned them up.  I'll
keep looking though.

> >To be brutally honest, I don't see that any of the major contributors to the
> >big open-source projects work on them to enhance their resumes - they do it
> >because they're interested in the project.
> 
> I agree.  I guess I was projecting my own feelings.  I am very interested in
> several projects, but I am too sensitive to the limitations on my time to be
> willing to spend a lot of time chasing technologies that I have no other
> compelling interest in, like tcl and C.  I've done all my undergraduate work in
> C, and extensive commercial work before C++ came out.  I have also done a
> reasonably complex project in tcl.  They both remind me of doing metal-work
> using a one-inch, copper-head, soldering iron :-)

Once upon a time, I built a sailing ship game in Lisp, basically a clone
of the board game Wooden Ships & Iron Men.  Ran on HP's Pascal workstation
converted to be an all-Lisp environment.  State of the art, it was; game had
speed issues, but was otherwise spiffy, graphics and all.  So what happened
to it?  Well, Lisp never quite caught on the way it was supposed to, and then
I started tinkering with this Empire clone written in plain C with no tricks...
I'm sure the Lisp game's sources are still around, but that line of machines
is so dead, forget even finding documentation about what the graphics calls
were supposed to do!

The moral of the story is that new technologies can let you down in a big
way.  When looking at a technology, you have to consider - what happens if
it dies, or languishes?  Can you recover your investment, or will you have
to start over?

I'm still angry with the X folks for having made such a feeble effort with
Athena widgets, which has cost me personally a lot of time trying to work
around their lamenesses.  The lameness was deliberate on the part of the
X Consortium, who didn't want them to compete too well with vendors'
proprietary widget sets (Motif, etc).  I've also been disappointed by
tcl/tk graphics on Windows, which has also taken way more tinkering than
the advertising led me to believe; I should have gotten my evaluation prototype
running on Windows to see for myself.  (Fortunately all the tcl/tk sources
are available, and not too mystifying...)

So I think my conservatism on the choice of technologies is justified by
experience.

> On a different, more pragmatic note, with Redhat not being interested in
> supporting game development on Linux, what happens to the website?

I already asked, and we have the sourceware site for as long as we want it.
Part of Red Hat's plan is to be a portal for open source developers, a la
sourceforge, so it would be counterproductive for them to take projects off!

Stan