[Freeciv-Dev] Re: Keepig Xconq and Freeciv syncronized.

[Stan Shebs <shebs@xxxxxxxxxxxxxxxxx>]

Erik Sigra wrote:
> 
> [...] They will notice us too, because they are subscribed to
> freeciv-dev (at least their chief, Stan).

Always keeping an eye out for stuff to steal... :-)

> But porting could be easier. As it is now, each game independently implements
> a bunch of helper functions; a logging function, a random function and
> some string handling functions. They all have different names and behave
> slightly different, which makes porting difficult.

In practice though, the common code is pretty small.  One of the hazards of
trying to share too much is that you have to generalize the shared code,
which makes it larger and more complicated.  So you end up spending more
time getting sharing to work than if you had simply cloned the code and
adapted it to each platform.

It's one of the most difficult design problems in programming; when to
make an interface generic, and when to specialize.

For instance, a common random number generator is probably a waste of
time, because Xconq and Freeciv both have requirements on consistency
and read/write behavior.  Satisfying those will likely need more code
than the few lines that actually implement the RNG.

Xconq's name generator is a little more plausible, but then you end up
dragging in a bunch of low-level Xconq code, which was not designed to
be generic.  (If I'd thought that my mini-Lisp would ever have ended up
in anybody else's program, I would have designed it differently, or more
likely, used SIOD or some such.)  But one could imagine a libnamegen.a
being installed in /usr/lib.

At the next level up, Xconq's map/country synthesizer has a Bryce-like
array of options and controls, but it would be a lot of work to
separate from the rest of Xconq.  For instance, it has the ability to
start some units inside other units, but then the code has to know or
be informed of the caller's limits on occupancy, and return a result
that says which units are occupying which other units.  Does Freeciv
need Xconq's map synthesis that badly?  Probably not, it's already got
a generator that works.

> The convergence program could continue, if people just looked more outside
> their own sandboxes. That is the point of OS/Free Software. Take full
> advantage of the GPL, like the big projects. For example, KDE and GNOME have
> a kde-gnome mailing list for interoperability issues.

They have a somewhat different issue, which is that applications
using different toolkits still need to interoperate at a high
level.  What you're proposing is more like Qt using GDK in its lower
levels, which is pretty unlikely.

Could Xconq and Freeciv actually converge in the future?  I suppose
it's possible.  Xconq has had 14 years of wandering down the generality
road, and indeed it serves as a cautionary tale of what kind of morass
you can end up if you try to generalize everything - it can do all sorts
of games, but no single game particularly well, and the code scares off
most would-be contributors.  Freeciv has a more limited goal, is much
closer to achieving it, and that's a really good thing.

I think there's also a bit of attitude difference.  I notice that
Freeciv developers who've commented on Xconq's interface and coding
style generally seem to dislike how Xconq does things, and conversely,
if I were to work on Freeciv, I would be consumed with the urge to
"fix" :-) lots of things that seem wrong to me.

So for now I think the best thing is simply to learn from each
other's successes and mistakes, and to borrow designs and code
whenever it makes sense.  That's the real strength of open source,
that whether we work on the same program or different programs,
we're all able to share the results, and thus become a single
community of programmers.

Stan