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

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

On Sun, 1 Apr 2007, Lincoln Peters wrote:
> The way I envision it right now is to transform GDL into a Turing-complete,
> logic-oriented language (like Prolog or Haskell), which would essentially
> allow a game designer to write a game by specifying types and the
> relationships between them.  Ideally, higher-level functionality (such as AI
> rules) or more specialized functionality (such as the tables you describe)
> could be defined as "include" files, in much the same way that in C++, you
> can include <string> or <list> to gain access to pre-built string and linked-
> list objects, respectively.  Most importantly, this functionality could be
> defined purely in GDL, without having to modify the Xconq kernel (unless you
> wanted to optimize for certain behaviors, or something like that).

Re-doing the whole works in Prolog would be interesting.  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.

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.  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.

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.

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.

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)
- code to display a (fully defined) map read from GDL files (implies
  having a map-display widget; hard)
- code to do random map generation (testbed for other "kernel" stuff; medium)
-- 
Matthew Skala
ms...@an...                    Embrace and defend.
http://ansuz.sooke.bc.ca/