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

[Lincoln P. <sa...@sb...>]

On Tuesday 03 April 2007 07:05, ms...@an... wrote:
> Re-doing the whole works in Prolog would be interesting.  

Perhaps, but that's not quite what I had in mind.

> I have a fair 
> bit of experience with Prolog and I think most of the kernel would be easy
> to implement that way.  It also would be really easy (maybe one weekend's
> work to get the basics) to read the current GDL format as Prolog facts.
> Despite the original claim that it's LISP-based, the things we do in
> GDL are already very much like Prolog code anyway.

Hence my original suggestion.  I should mention that, although Prolog is the 
only logic programming language I know (I used it for a class), I'm not sure 
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 
types.  A quick Google search turns up several object-oriented Prolog 
variants, but they're all probably too obscure.

I think the most complex thing I ever wrote in Prolog that actually worked was 
a genetics solver, which I used occasionally in a biology class.  And it 
wasn't a very complicated program.

>
> However, I think the GUI would be a problem.  There's a lot of weird stuff
> in the current TCL/TK GUI - in particular, drawing the map is handled by a
> complicated piece of code that I don't think any current developer really
> understands.  That's why the "connections and borders don't display at
> maximum magnification" bug has gone unfixed for so long, for instance -
> it's somewhere in that mysterious display code.  Although current
> SWI-Prolog, which is what I'd use, comes with a sophisticated
> cross-platform GUI toolkit, I think it would be a lot of work to get a
> working GUI for the game out of it.  

The last time I checked, SWI-Prolog was only available for Windows, so I'd 
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).  

> On the other hand, the current GUI is 
> only marginally acceptable, and does need to be rewritten one way or
> another.  Another significant issue might be speed.  Some of the logic
> we're doing would actually go faster if we did it in Prolog because we
> could, for instance, benefit from behind-the-scenes hash lookups in tasks
> that we're currently solving by linear search.  But the language as a
> whole, being interpreted, is likely to take its toll on overall speed.

I suppose we could consider building some kind of Just-In-Time (JIT) compiler, 
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.

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.

>
> There's also the general issue that it's harder to find developers who
> know exotic languages; C++ has a much bigger base of potential volunteers.
> And we'd be spending a lot of time reimplementing basics that could have
> gone to new features in the existing framework.  That would have to be
> balanced against the idea that a better framework would eventually mean
> that new features would be easier to add.

The way I see it, Xconq has the advantage that you can specify a game in terms 
of how it should work, rather than how to make it work that way (as you would 
have to do in C++).  Logic programming is built on the same idea, so it seems 
like a good fit, even if you DO have to learn a new language to use it.

>
> I think that it might be better to think of a Prolog- (or other language)
> based XConq-like game as a separate project rather than as part of XConq.
> Would you be willing/able to work on such a project?  Would others on this
> list?  It does sound pretty interesting to me, and I think I have the
> skills, but I wouldn't have enough time to do it alone.  And I wonder how
> much bang for the buck it would provide, in terms of being helpful to
> users.

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.

If it were to go where I envision it going, the current GDL-based Xconq would 
become little more than a historical curiosity.

>
> If we went ahead with it, I think the first three steps I'd suggest would
> be:
>
> - code to load GDL files (which implies some data-structure work; easy)

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

Since the Prolog idea (in my view) is really just a way to improve the tools 
available to Xconq game developers, I think that if we're going to go this 
far, we shouldn't limit ourselves to a single obscure language that's really 
good at some things but awkward at other things.  In fact, I could imagine 
that doing so might eventually lead to a similar problem to the one we have 
now.

In fact, as I think about it, we could probably achieve enormous flexibility 
if Xconq were reworked to use a layered architecture like this:

* User interface
* Game state
* Database driver
* Rules database

Note that when I say database, I'm not necessarily referring to an SQL-based 
system (I've heard Prolog described as a form of database).

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.


As a side note, I recently built an artificial neural network that plays 
Othello (a.k.a. Reversi).  It's interesting from a technical standpoint (and 
it could easily be adapted to almost any board game), but it never played 
very well (it contained only the most rudimentary of pattern-recognition 
abilities).  It might be possible to build a learning Xconq AI using a 
similar idea, but the time-space complexity is very high, and would require a 
significant amount of optimization (I used MySQL to store all the data 
points).

> - code to display a (fully defined) map read from GDL files (implies
>   having a map-display widget; hard)

I think I'd rather code the GUI in C++ using e.g. SDL and use the pipe/socket 
trick I mentioned earlier to talk to a Prolog interpreter.  At least then we 
can be sure it's cross-platform.

> - code to do random map generation (testbed for other "kernel" stuff;
> medium)

Unless you know an easy way to do this in Prolog, I'd rather do it in C++, 
simply because I'm much more familiar with C++.


-- 
Lincoln Peters		<sa...@sb...>

BOFH excuse #332:

suboptimal routing experience