re: Xconq language thoughts

re: Xconq language thoughts

[Brandon J. Van Every]

Bruno Boettcher wrote:
>
> ergo: we need not only a good abstraction layer defined
> through a set of
> interfaces, we need also easy to use and combinable basic actions to
> attract people into that area...

That's an inspiring vision!  A lot of game design would get done with
such tools.


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

Taking risk where others will not.

Re: Xconq language thoughts

[Peter Garrone]

On Wed, Nov 19, 2003 at 06:15:30PM -0800, Stan Shebs wrote:
> In all the discussion of extension languages for Xconq, the one thing I look
> for is "what is it for". It's always lots of fun to talk about languages and
> their good/bad points, but what do the game players and designers get 
> for it?
> 
> For instance, many of the games in Xconq are based on a randomly generated
> world, the purpose being to provide a new and different experience each 
> time.
> This is completely opposite to 95% of commercial game design, where 
> everything
> is so predetermined that you can buy a printed walkthrough at the bookstore.
> Random generation is harder; you can't just write a script for AI 
> behavior, the
> AI actually has to be able to do its own analysis. In return, you get a game
> where you can't win by knowing to send a full transport to 34,45 after 
> turn 30;
> transports may even be the totally wrong strategy. Now if people want to 
> write
> scripted scenarios for Xconq, that would be an interesting addition; but I
> haven't seen very many requests for that.
> 
> Another consideration is that there is a tension between generality and
> specificity; if you generalize everything a lot, you get more flexibility,
> but you also have to do more work to get something working.  In the most
> extreme case, you end up with one of those generic "game engines" that
> amounts to little more than a poor reimplementation of event loop and
> memory manager. Xconq is consciously designed to support only a very
> specific class of games; in return you get lots of functionality that "just
> works". 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.)
> 
> 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.
> 
> Stan
>

I find the C code in the kernel to be reasonably structured and useable.
I dont see how C++ would increase its efficiency or useability
significantly. I suppose there is some replicated code there, that
might disappear into a base class. But to do that well would require a
lot of OO design effort. I dont see how the current kernel is a
developmental brick wall. When it does become one, then rewrite in
a new language.

I dont like the tcl/tk much. I cant get it to work well. The interface
is unresponsive. I think we should stick to one language as far as
possible. I am comfortable with C. I am also comfortable with GTK
without special designer tools. Just work it all out in the code.
I hate those interfaces where all the pixel positions are hard-coded.

I would like to see development in terms of 
1) integrating pathfinding into the AI, 
2) setting up a combat model so that multiple units on differing adjacent 
   hexes attack simultaneously, 
3) setting up a combat/turn system so that all combats can be resolved 
   at the end of a turn by a referee somewhere, so that play by email 
   would be possible without cheating, and tournaments can be set up.
4) Make it easier to implement the vast existing hex-cell game library,
   which have been game-tested over time. e.g. russian campaign.
5) Develop the AI interface so that a wider variety of AI algorithms
   might be tested, with game-specific specialization, 
   e.g. neural nets, genetic, perhaps simple parametric
   search might work. I havent gone into the details here.

None of this development is particularly language specific, just pick
good algorithms and implement them. There is no magic language bullet
to fix this. I dont think this is particularly generalizing the existing
functionality, just trying to extend it to its target market.

Hope this is on thread.
 Peter

Re: Xconq language thoughts

[Bruno Boettcher]

On Thu, Nov 20, 2003 at 01:55:48AM -0800, Brandon J. Van Every wrote:
> Almost nobody is interested in writing AI in C.  Some will want to do
> C++, "for the performance."  Others, like myself, find C++ to be a poor
> fit to the AI tasks they want to implement.  People like that pick
> Python or some other higher level language.
i fear i have to concur with Brandon on this....
see below...

> One question is how much coding is needed to get an AI going.  It's not
> enough to have a separable layer.  It must be a *doable* layer.
one good point...

> > 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;
i am giving C++ and Java courses among others, and i took down a IBM -
JAVA project of a robot battle arena. The students got all exited over
it, and are now happily playing with it producing lots of different ai's
to control those battle bots.....

strong of that experience i dug out a similar project in C++ for the
same named course.... and it was a big flop.... 

the difference? 
the java projects proposes a full blown set of allreading and very
easily usable primiteves that you only need to plug together to get a
first bot running, whilst the C++ bots needs a hell of programming to
get just the basic parts working....

as often you encounter the paradigm: you use C/C++? then you are
qualified to do things the hard way... you use Java (same goes for
    python BTW) then you are considered stupid enough to be given
powerfull ready tools into your hands....

ergo: we need not only a good abstraction layer defined through a set of
interfaces, we need also easy to use and combinable basic actions to
attract people into that area...

and concerning touching the code: i tryed several times to dig into
xconq sources, but allways managed to break things at different
parts.... so mee too i would really prefer a true OO design to all
this... encapsulation is nice ;)

-- 
ciao bboett
==============================================================
bboett@adlp.org
http://inforezo.u-strasbg.fr/~bboett
===============================================================

RE: Xconq language thoughts

[Brandon J. Van Every]

Stan Shebs wrote:
> >
> >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++.

Almost nobody is interested in writing AI in C.  Some will want to do
C++, "for the performance."  Others, like myself, find C++ to be a poor
fit to the AI tasks they want to implement.  People like that pick
Python or some other higher level language.

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

One question is how much coding is needed to get an AI going.  It's not
enough to have a separable layer.  It must be a *doable* layer.

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

Good luck attracting AI developers to your project then.  Have they been
beating down your door?  Actually, this would be a worthwhile question
for comp.ai.games.  "What would attract you to an open source project?"

One thing I do know about AI coders, from talking to a crowd of
Diplomacy AI writers.  Everyone argues over theoretical approaches, and
then people make up their minds about the best way to tackle a given AI
problem.  People always differ about what "the best" way is.  Once
people have drawn their lines in the sand, they will not do it your way.
Only their way.  At that point discussion has to cease and people have
to start implementing.

So, you might expect AI coders to be a non-cooperative sort of crowd.
The best thing you could do for them would be to provide tools for them
and get out of their way.

> I've been tricked before by the "build it and they will come"
> theory; see my remark above about the networking layer.

You don't want to "build it."  You do want an OO migration path that can
be implemented incrementally.

I'm going to look at how to poison your code base with Python.  I'm
giving it until Sunday.  If I can get Python embedded and make some
trivial game design or AI changes by then, I'll consider this viable.


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

Taking risk where others will not.

Re: 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

RE: Xconq language thoughts

[Brandon J. Van Every]

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.

Xconq language thoughts

[Stan Shebs]

In all the discussion of extension languages for Xconq, the one thing I look
for is "what is it for". It's always lots of fun to talk about languages and
their good/bad points, but what do the game players and designers get 
for it?

For instance, many of the games in Xconq are based on a randomly generated
world, the purpose being to provide a new and different experience each 
time.
This is completely opposite to 95% of commercial game design, where 
everything
is so predetermined that you can buy a printed walkthrough at the bookstore.
Random generation is harder; you can't just write a script for AI 
behavior, the
AI actually has to be able to do its own analysis. In return, you get a game
where you can't win by knowing to send a full transport to 34,45 after 
turn 30;
transports may even be the totally wrong strategy. Now if people want to 
write
scripted scenarios for Xconq, that would be an interesting addition; but I
haven't seen very many requests for that.

Another consideration is that there is a tension between generality and
specificity; if you generalize everything a lot, you get more flexibility,
but you also have to do more work to get something working.  In the most
extreme case, you end up with one of those generic "game engines" that
amounts to little more than a poor reimplementation of event loop and
memory manager. Xconq is consciously designed to support only a very
specific class of games; in return you get lots of functionality that "just
works". 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.)

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.

Stan