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

[Eric M. <mcd...@ph...>]

Lincoln Peters wrote:

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

Lua seems to be currently popular among a number of FOSS game 
developers. It's a relatively simple language and has some following. 
And, it certainly commends itself to table manipulation, which we do in 
fair abundance. I'm not necessarily advocating it, but just pointing out 
some potential merits.

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

I had several reasons for pushing xConq towards C++. One of them was, 
indeed, the advantage of using pre-built, already-tested templates, such 
as those provided by STL and Boost. xConq has a number of custom linked 
list implementations, for example, and it would be nice to replace them 
with something more standard. (And, in some cases, something other than 
a linked list -- for performance reasons!)

(Another reason for the push towards C++ was simply one of perception. 
At this date, I think that most people now perceive C code as inferior 
and as legacy code (even if that is not necessarily the case!) There are 
some potential developers who are probably turned off by code which does 
not use "proper" encapsulation, etc....)

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

If by IPC, you mean inter-process communication, then I think that it is 
a very shoddy solution. If an interpreter can't be embedded, I wouldn't 
want to use it.

Topic change:

As far as SQL goes, I actually have a strong interest in merging xConq 
with a SQL-queryable database backend. Not only does one get the 
advantage of having an efficient B-tree (or somesuch) implementation for 
data management, but I think it would ease some of the pain involved 
with searching and filtering objects that we now experience (take the 
views code in 'side.c', for instance).

I've contributed some to the Litesql project 
(http://litesql.sourceforge.net), because I see it as a potential 
vehicle for achieving this aim. Litesql effectively seeks to be 
something akin to Hibernate, but for C++ instead of Java. It can talk to 
MySQL, PostgreSQL, and SQLite3 backends. I am particularly interested in 
talking to a SQLite3 backend via LiteSQL, because that could be shipped 
with the game and would not require a standalone DB server to be run.

There is another possibility in the form of QoF (Query Object Framework: 
http://qof.sourceforge.net), but that is not tightly-coupled to a DB 
backend. It is also a C-based solution, and so it is not quite as wieldy 
as dealing with objects as direct actors/agents.

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

Well, I've been debating cleanup vs. rewrite for a long time. I've done 
some exploration as far as rewriting goes, but I've also made actual 
efforts as far as cleanup and separation of interfaces goes. Last year 
about this time, I had a few weeks between jobs and felt ambitious 
enough to actually work on interface separation and full internal 
documentation. What I was able to get done is in the 'src' and 
'cvs_hist' directories in CVS. Unfortunately, I now have neither the 
time nor the energy to complete this exercise.

Given another few weeks and some corresponding ambition, I think I could 
complete the documentation and interface separation. (As a bonus, xConq 
would also be fully autotoolized and would have a suite of 
dynamically-loadable libraries better suited for writing lightweight 
tools, and for being shared among various GUI frontends.)

Of course, there is still plenty of work to do after that. One of the 
things I would like to pursue is the decoupling of 
serialization/deserialization from GDL. I would prefer to use a 
generalized framework such as provided by Boost or Stephen Beal's s11n 
for performing ser/deser, and then making GDL a particular ser/deser 
target to use in the framework. One particular advantage to doing things 
this way is that we could ser/deser across the network with little 
additional effort, and essentially rid ourselves of much of the nuisance 
of making special network functions for the transfer of various objects 
(such as the tasks), as xConq has now. I believe this would address 
Matthew's concern about the network protocol, a concern which I 
definitely share.

Just some musings, hopes, plans.... Discussion and implementation help 
are always welcome.

Eric