RE: Xconq language thoughts

["Brandon J. Van Every" <vanevery at indiegamedesign dot com>]

Stan Shebs
>
> For instance, there has long been an ability to write
> AIs customized
> for a particular game design, but so far everybody has
> preferred to just
> sponge off the generic AI instead. (Not too surprising, since
> AI writing
> is hard, and there is no possible API that can help you with the hard
> parts.)

Yes, writing AIs is hard.  However, most AI developers probably have no
desire to write AIs in GDL, they probably want to use their language of
choice.  And, as far as difficulty of plugging AIs into an architecture
goes, the Xconq C codebase looks (ahem) less than ideal.  It is a
sprawl.  It may be a well-organized sprawl but it is still hundreds and
hundreds of C functions.  AI developers - indeed, any kind of
developers - are probably more willing to do things in OO source code
pools that take far less work.

> So when thinking about language integration, don't think about resumes
> or user familiarity or whatever; think about how much Xconq
> machinery you want to use as-is, vs how much you want to change.

Once I get done eyeballing the Xconq code, I hope there's something I
want to use.  I've already decided on GUI stuff: I don't want to use any
of it.

So, I am thinking in terms of whether people want to make the Xconq
codebase more OO and more usable to newcomers?


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.