Xconq language thoughts

[Stan Shebs]

Brandon J. Van Every wrote:

>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.
>
Um, the AIs I'm talking about would be in C or C++. In theory one could 
build
infrastructure to link in other languages at that point; the API is the 
same as the
networking layer, in fact the AI could be a separate program if one wanted.
(Nobody has tried to write one of those either, despite all the years I put
into rewriting the code so that it was possible.)

>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.
>
I don't actually buy that reasoning. Programmers who are really 
interested are
willing to key in machine code using toggle switches if they have to; 
better API
and internals is for the benefit of the programmers already working on 
the code.
I've been tricked before by the "build it and they will come" theory; see my
remark above about the networking layer.

Stan