[freeciv-ai] Re: Hi, I'm back. aiclient

[Raimar Falke <i-freeciv-lists@xxxxxxxxxxxxx>]

On Tue, Jul 01, 2003 at 12:39:19AM +0200, Manuel Gutierrez Algaba wrote:
> El Lun 30 Jun 2003 21:38, escribió:
> > >
> > > Well, expert systems are coded in Clips or Jess or Prolog not in C.
> > > Perhaps you could browse the web a bit.
> >
> > A related question is: in what languages are commercial computer game
> > AIs coded?
> >
> 
> Well, Clips is coded in C, and Jess is coded in Java, you can always have a 
> commercial game, 

> coded in C, but that internally implements a inference-engine. I
> don't know,

Yes.

> google would tell, 

I haven't found this much information about the subject. So if you
have any URL...

> anyway I've heard that they've even used neural networks for ai
> intelligence. Now that I remember about it, Simcity was "heavily"
> based in a kind of expert system, I think.


> > tar files in tar files in tar files. uhhh. And at least one of tar
> > files is named ".tex".
> 
> Well, I have a project pybackup:
> algaba.sdf-eu.org/pybackup.php 
> that makes recursive tar files, in fact, it is a safer way of storing info. 

From the website:

   Well, I simply got fed up of getting buggy backup files stored in
   CD ROMS. I had a large .tar.gz file and then it corrupted, and I
   lost 50 mb out of 650 mb. I decided to use a safer method, so that
   if 1 % of the file gets corrupted then I don't lose the 100 \% of
   the file.

I thought the canonical solution for this problem is to add redundancy
with Reed-Solomon or a similar algorithm. Par
(http://parchive.sourceforge.net/) does this for example. The simpler
solution is to burn a second CD with the same content.

> > > I just want the interface and go little by little. Don't be so fast.
> >
> > Some people also have thought about the problem a lot and want to
> > share now some ideas.
> >
> 
> There's no easy way to do AI, and the ideas are many, that requires that the 
> process is as abstract and structured as possible. Part of my project was to 
> feed each of the engines with "fake" data so that the debugging was much 
> faster. Having a socket-fed aiclient gives the possibility of creating
> series of orders:
> move settler 10,30;
> fight falanx 7,6;
> ...
> so the ai can be debug without the need of running the entire program. 

While this is a nice idea it won't work IMHO. The problem is that the
(at least a top-down) AI has to check the results of the
commands. Example: you have a unit which has moves left. The AI
decides that the unit should attack an enemy unit which is nearby. You
issue the attack order by there is no fight. Where is there no fight? 
One cause could be that the enemy unit moved away. As a client AI you
have to cope with a changing world. Here a server AI has an advantage
because it can "freeze" the whole game until all of its actions are
carried out. Back to the fight. There was no fight. So the client AI
has to be aware of this and now since the unit still have moves left
have to think about further actions.

So you could feed a state into the AI via the socket
interface. However in the worst case you would got one commant out of
the AI before the AI waits for the response. It is possible here that
some other code which isn't "the entire program". But I think that
programming this responder is hard and it is easier to use the real
freeciv.

> And thus , AI development is sped up. 

It will speed up because of other reasons: it is easy to debug, people
can choose the language they know and so on.

> And any discussion in this list can be supported by adding some
> instructions into the file to be fed in the aiclient and seeing its
> output. As easy as writing the aditional rules , writing the
> sequence of events and seeing what aiclient produces out of it.

> Another lesson I learnt in Clips is that you have to keep the
> interrelation of variables low, so you have isolated modules as much
> as possible.

Yes isolation of modules is good.

> Anyway, I think everything boils down to getting an interface
> aiclient <-> civclient. That'd be the start of it all. Perhaps
> there're volunteers out there to do it. A warclient is an excellent
> way of scaling up. With many people writing their warclients, it's
> just a matter of time of getting a real AI working. When people
> learnt to play faster and easily.
> 
> If nobody is going to get that interface done, AI will keep its
> current pace of improvement for several years...

So you aren't going to code this interface? You want to code only the
clisp aiclient?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  What's nice about GUI is that you see what you manipulate.
  What's bad about GUI is that you can only manipulate what you see.