Re: [Xconq-hackers] A bunch of bug fixes, bug reports, and requests

[<ms...@an...>]

On Tue, 3 Apr 2007, Lincoln Peters wrote:
> it's really the best solution.  What I would like to see is some form of
> logic programming that is more object-oriented, since it would be much easier
> to think about the different things in an Xconq game as objects and object

Well, then we probably face the issue of having *no* current developers
familiar with the language... I'm not sure how good an idea it is to
choose a language none of us are familiar with and settle on writing
significant amounts of code in it.

> The last time I checked, SWI-Prolog was only available for Windows, so I'd

That must have been a while ago; I use it under Linux exclusively, and to
be honest, I'd be more concerned about whether it would *really* be as
compatible with Windows and MacOS as it claims to be.

> prefer to avoid it.  A more flexible (but possibly more cumbersome) solution
> might be to run GNU Prolog in a separate process, and interact with it via
> pipes or sockets (kind of like how a typical web application interacts with
> an SQL database).

I think it would be really nice if we could have the GUI and other code
more closely integrated than what we currently have; it seems like we
spend more effort trying to integrate the TCL with the other stuff, than
we should.  For that reason I'm hesitant to say that it's a good idea to
run something in a separate process and interact with it via IPC; there'd
have to be some really compelling benefit.  Do you think that having a
full Prolog (or similar) interpreter for game designs would really be such
a benefit?  I think if we were going to go that route we might be better
off just writing a small, simple interpreter from scratch ourselves and
integrating it tightly - or using an existing open-source interpreter that
can be embedded.  I'm aware of Perl, Prolog, Scheme, TCL, and several
other such interpreters that can be used that way.

> I suppose we could consider building some kind of Just-In-Time (JIT) compiler,

Aiee!  I don't want to have to write that!  But if you, or someone else,
does, great, let's go for it.

> like .NET uses, but I'd leave that for the future.  As long as it's faster
> than it is now, I don't think it's worth worrying about now.

I'm concerned that it might not be.

> Besides, even without changing GDL, we could probably clean up the kernel code
> and replace all of the linear searches with binary searches.  That would
> provide a huge increase in speed.

My impression is that a lot of stuff is currently stored in unsorted
arrays that can't really be searched except with linear search.  I think
significant data structure work would be needed to make the current kernel
signficantly faster.

> I see a Prolog(?)-based Xconq as more than just a rewrite of the current
> rules.  The real goal is to simplify the rules, so that they gain more
> flexibility.  Using Prolog (or something similar) to define game rules is
> simply a means to an end.

Understood... but that does mean that something of equal power to the
current hardcoded rules would have to be written and debugged in whatever
language we use, whether it's written as part of the kernel/interpreter or
in the new-GDL on top of the kernel/interpreter.  Otherwise, the average
non-programming user won't see an advantage to switching.

> I once tried to write a parser in Prolog.  It was such a nightmare, I finally
> gave up and wrote it in C++.

I put off learning Prolog's "definite clause grammar" support for a long
time myself because I was concerned that it would be nightmarish, but I
ended up being forced to use it for a paid-work project about a year ago,
and I think I've conquered the learning curve; I think I can write parsers
in Prolog now without too much fuss.

> Ideally, you could have two or more databases per game: one defining the game
> rules, the other defining the AI behavior.  But I don't think you'd want to
> write an Xconq AI in Prolog (it's too rigid), so it should be possible for
> these databases to have completely different implementations.

This kind of layered approach means we need clearly-specified interfaces
between the parts, and that would probably be a good thing anyway.  A
more precisely-described protocol for the network game would be nice, too.
-- 
Matthew Skala
ms...@an...                    Embrace and defend.
http://ansuz.sooke.bc.ca/