Newsgroups: comp.ai.games,rec.games.programmer
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!godot.cc.duq.edu!newsgate.duke.edu!news.mathworks.com!hunter.premier.net!netnews.worldnet.att.net!ix.netcom.com!ixnews1.ix.netcom.com!netcom.com!raf
From: raf@netcom.com (Hugh Sider)
Subject: Re: Gripe: Games with poor or static opponents (Re: what kind of AI to use?)
Message-ID: <rafDt5MCM.5IM@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <4plcti$10h@celebrian.otago.ac.nz> <Pine.SGI.3.91r.960614065636.11081A-100000@freenet> <rafDt04xA.Gr0@netcom.com> <Pine.SGI.3.91r.960615165911.14275B-100000@freenet>
Date: Mon, 17 Jun 1996 17:09:58 GMT
Lines: 47
Sender: raf@netcom16.netcom.com

In article <Pine.SGI.3.91r.960615165911.14275B-100000@freenet>,
Darrin Robert O'leary  <olearydr@freenet.msp.mn.us> wrote:
>
>
>On Fri, 14 Jun 1996, Hugh Sider wrote:
>
>> This isn't really an AI topic, but consider that neither an AI dll nor a 
>> directly attached UI has latency problems.  A network socket does.  
>
>Yes and no.  For externally implemented opponents, they could very well 
>be "latent" by way of slow calculations.  In any case, there's no reason 
>for the game engine to care why the player isn't responding.  Allow for a 
>timeout or a force out by other players.  It's not a great solution for 
>networking intensive action games, but I didn't intend it to be.

First of all, your architecture assumption is a good one, at least by 
our standards, and we implement our games this way.  That does not mean I 
completely agree with your comments.  The game does have to determine 
that a remote player has been dropped due to communications failure.  I 
don't think we really have much disagreement here.

Now back to the more relevant topic.

>> I am also concerned about the effort needed to expose the game data to an 
>> external AI, and the time involved.  I'll give it some thought, though.
>
>Like I said, it's better not to think of it as being just for AI, but for 
>all players.  It should take no more time than defining the player 
>interface and creating an appropriate API.
>
>         ---------   Doc
>
There are two problem areas I can forsee in this model,at least for the 
type of games we produce.  The first, navigation, could probably be 
considered a mechanics problem, not a player problem.  This does meant 
that your player would be saddled with one navigator.  The second problem 
is the more general "strategic disposition perception" problem that has 
been discussed here at length.  An embedded AI has access to the map 
structure; this simplifies things somewhat.

I have not had too long to consider the problem, so I may be overlooking 
something here; I'll keep thinking about it.

-- 
Hugh Sider                               raf@netcom.com
Coolhand Interactive                     Opinions are mine, not Coolhand's.

