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

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

On Wednesday 04 April 2007 05:49, ms...@an... wrote:
> 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.

Fair enough.  My point was that if we pick a language that doesn't really fit 
what we want it to do, it might take more effort to get it to work than it 
would to learn a new language.  

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

My mistake; I was thinking of Strawberry Prolog.

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

What I'm thinking is that, if possible, we should have a clear layer of 
abstraction between the GUI and the mechanics of the game.  That way, if for 
some reason Prolog turned out not to fit some game designer's plans, it would 
be possible to use something else (e.g. a Scheme interpreter) without the 
same nastiness that switching to Prolog now would take.

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

That might be reasonable.

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

I don't have time for that, either.  But if we're talking about maximizing 
performance, that's probably the way to go.  Eventually.

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

I didn't explain that very well.  What I meant was that if *Prolog* would be 
faster than what we have now, it's currently not worth worrying about 
speeding up further, e.g. using a JIT compiler.

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

Which is yet another reason that the code needs significant clean-up.  Even if 
the arrays cannot easily be sorted into e.g. a binary search tree, we could 
probably create multiple trees, each of which holds a pointer to an array 
element.  And with C++ templates, it should be easy to build a generic binary 
search tree that will work with ALL of the different data structures that 
Xconq supports.

Or if IPC is the way to go, I suppose we could off-load all these arrays to an 
SQL database, and let some other developers figure out how to optimize it.  
But that's an even more radical change than using IPC to talk to a Prolog 
interpreter, so I highly doubt we'll go there any time soon.

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

It has to be of GREATER power than the current hardcoded rules.  Otherwise 
there is no incentive for game developers to switch from GDL.

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

I think I'll leave that to you.

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

Just to be clear: based on what little kernel hacking I have done, I am quite 
aware that the Xconq code is a huge mess, with different parts scattered all 
over the place.  I'm not really sure if it would be better to clean up the 
code and then make these kinds of radical changes, or to just throw away the 
current code and start over.

I think we need a much better idea of what exactly we'd be doing in Prolog (or 
another logic-oriented language), and how it differs from what GDL currently 
allows, before we can make that decision.


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

Fame lost its appeal for me when I went into a public restroom and an
autograph seeker handed me a pen and paper under the stall door.
		-- Marlo Thomas