<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Summary: The "Extensible Game AI" thread -->
<!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> -->
<!--X-Date: Wed, 8 Jul 1998 11:33:31 -0700 -->
<!--X-Message-Id: 199807081833.LAA07175#under,engr.sgi.com -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Summary: The "Extensible Game AI" thread</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:claw#under,engr.sgi.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00089.html">Previous</a>
| <a href="msg00090.html">Next</a>
]
Thread:
[ <a href="msg00106.html">Previous</a>
| <a href="msg00089.html">Next</a>
]
Index:
[ <A HREF="author.html#00088">Author</A>
| <A HREF="#00088">Date</A>
| <A HREF="thread.html#00088">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Summary: The "Extensible Game AI" thread</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Summary: The "Extensible Game AI" thread</LI>
<LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI>
<LI><em>Date</em>: Wed, 08 Jul 1998 11:33:22 -0700</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
URL:<A HREF="http://www.cris.com/%7eswoodcoc/exai.thread.html">http://www.cris.com/%7eswoodcoc/exai.thread.html</A>
February 13, 1997
Hello Folks:
This is my best summary of the (rather long and rambling) "Extensible
Game AI" thread that ran over on comp.ai.games newsgroup throughout
December, 1996. This was one of the better threads (in my opinion) to
run on said newsgroup; a lot of excellent ideas were brought up, and
hopefully it will eventually lead to more games that permit user
modification of their AI.
If I missed any posts please let me know; the thread began as
"Warcraft 2" and rapidly split into three parallel and intermingling
threads (the other two beign "ExAI Security Issues" and "Extensible
Game AI"), so I may have missed something.
The posts are presented essentially as is, with some minor editing on
my part to trim out redundant .sigs, spelling errors, etc. I did leave
the first use of a given .sig in for the sake of individuality,
however. ;)
Here are the email addresses for those contributors that I have, in
case the reader wishes to follow up a comment or idea via
email. Again, my profound apologies if I've missed anybody; please let
me know.
Carl D. Burke cburke#mitre,org
Eric Dybsand edybs#ix,netcom.com
Seth Golub seth#siesta,cs.wustl.edu
Les Howie lhowie#novalis,ca
Benton Jackson benton#bitstream,net
Doc O'Leary droleary#alpha,temporal.org
Scott R Lenser s-lenser#coewl,cen.uiuc.edu
Keith M. Lucas sillywiz#excession,demon.co.uk
Darrin Robert O'leary olearydr#freenet,msp.mn.us
Glen Miner gminer#Newbridge,COM
Andrae Muys ccamuys#dingo,cc.uq.oz.au
Russell Penney rpenney#cyberspace,net.au
Bradley Richards bradley#ai-lab,fh-furtwangen.de
Gerry Quinn gerryq#indigo,ie
Asbj rn bheid#sn,no
Sunir Shah sshah#intranet,ca
Nigel Sim Nigel_Sim#msn,com
Nate Trost nctrost#pobox,com
(unknown) tallent1#airmail,net
Mike White mykey#geocities,com
Bernd Wolff bwolff#newswire,de
Steven Woodcock Swoodcoc#cris,com
Enjoy!
Steve
This thread began when Nigel Sim posted a simple question regarding
the possibility of modifying the AI in Warcraft 2....
From: Nigel_Sim#msn,com (Nigel Sim)
Subject: War Craft II
Date: 12 Dec 96 12:14:29 -0800
How is it possible to write a new AI engine for War2. Hack it...if
so has anyone done it??? Or have a network program that plays in the
place of human player.
Thanks
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: War Craft II
Date: 12 Dec 1996 17:03:50 GMT
Nigel Sim (Nigel_Sim#msn,com) wrote:
: How is it possible to write a new AI engine for War2. Hack it...if
: so has anyone done it??? Or have a network program that plays in the
: place of human player.
: Thanks
Hello Nigel:
Well, the short answer is of course...anything's possible. ;)
Having made the obligatory smartaleck remark, I don't believe there
are any tools or interfaces built into War2 to allow you to do such a
thing. The only three games I know of on the market that have any form of
"roll your own AI" are Abuse (they have a LISP-based interface you can
do some things with), Quake (there's a programming kit out there someplace
that many players are using to build Quake 'bots), and the Carriers
At War series (using their scenario builder you can adjust the AI
fairly extensively).
I suppose one COULD build a program that "pressed the buttoms"
for War2 (basically emulating a human player) and thus play one
side. I'm not sure how you'd "see" things though.
Another possibility (this one is more solid) would be to read the
data stream sent out over a War2 network or modem game and inject
your own packets instead. You'd have to know the formats the data
was being sent in, but theoretically if you could analyze that info
you could change it however you wanted. That might be a good way to
"see" things.
Warcraft 2, C&C, etc. weren't really built to allow the players to
mess with the AI much, unfortunately. We had an interesting thread a
while back on this very newsgroup discussing the desirabilty of such
games, and the general consensus was that it would be a lot of fun
for us AI weenies to play with. ;)
Steve
From: "Keith M. Lucas" <sillywiz#excession,demon.co.uk>
Subject: Re: War Craft II
Date: Fri, 13 Dec 1996 11:38:44 GMT
In article <58pdtm$nus#herald,concentric.net>,
>
> Another possibility (this one is more solid) would be to read the
>data stream sent out over a War2 network or modem game and inject
>your own packets instead. You'd have to know the formats the data
>was being sent in, but theoretically if you could analyze that info
>you could change it however you wanted. That might be a good way to
>"see" things.
The data simply consists of the other players mouse and keyboard
clicks. The game "runs" on both machines, regularly resynched over the
network. Not that I asked Blizzard at all...
The differences between this and a client-server are apparent
if one runs experiments regarding timing constructions when run over
two very differing machines. Not that I did this at all, you
understand...
> Warcraft 2, C&C, etc. weren't really built to allow the players to
>mess with the AI much, unfortunately. We had an interesting thread a
>while back on this very newsgroup discussing the desirabilty of such
>games, and the general consensus was that it would be a lot of fun
>for us AI weenies to play with. ;)
So there'd be some interest in, say, a construction kit which allows
the creation of WarCraft II style games, complete with programming
language for the units ?
One that allows units to order other units about. Complete with full
combat model and all the rest ( customisable economy, add-in graphics
and maybe network play ) ?
Some of us might have such a project on the go, you see, and just need
some encouragement.
-----------------------------------------------------------------------------
"It's not a personality.. it's a bulldozer" sillywiz#excession,demon.co.uk
Current project: Computer wargaming's next generation...
------------------------------------------------------------------------------
This site does not wish to receive advertising e-mail, defined in this case as
any mail which is a) sent to more than one user at this site over any span of
time b) mail specifically advertising products or services. This is notific-
ation that we do not wish such traffic to enter this system via its telephone
line. You are not authorised to cause this system to route such mail or to
cause such mail to be routed to this site. Causing such is a violation of
various portions of the Computer Misuse Act. Senders may also be in violation
of the Data Protection Act if mailing lists are held within the UK.
-----------------------------------------------------------------------------
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: War Craft II
Date: 14 Dec 1996 16:44:14 GMT
Keith M. Lucas (sillywiz#excession,demon.co.uk) wrote:
: > Warcraft 2, C&C, etc. weren't really built to allow the players to
: >mess with the AI much, unfortunately. We had an interesting thread a
: >while back on this very newsgroup discussing the desirabilty of such
: >games, and the general consensus was that it would be a lot of fun
: >for us AI weenies to play with. ;)
:
: So there'd be some interest in, say, a construction kit which allows
: the creation of WarCraft II style games, complete with programming
: language for the units ?
:
: One that allows units to order other units about. Complete with full
: combat model and all the rest ( customisable economy, add-in graphics
: and maybe network play ) ?
The interest seemed high, but this is an AI newsgroup full of hackers. ;)
The thread itself centered on the question of how one might design such a
game (with an AI interface) and whether or not it would sell enough
copies to make it worth the extra effort. While nearly everybody here
thought it would be a great thing to see and fiddle with, there was
massive disagreement over whether the "sales benefits" of having such
a feature would outweigh the costs of implementing, documenting, and
user-proofing it.
:
: Some of us might have such a project on the go, you see, and just need
: some encouragement.
You too eh? So far my managers love the idea, but since they haven't
had to commit yet talk is, as we say, cheap.
Good luck!
Steve
From: "Keith M. Lucas" <sillywiz#excession,demon.co.uk>
Subject: Re: War Craft II
Date: Sun, 15 Dec 1996 13:13:51 GMT
In article <58ulgu$ocu#herald,concentric.net>,
Steven Woodcock <Swoodcoc#cris,com> wrote:
>
>Keith M. Lucas (sillywiz#excession,demon.co.uk) wrote:
>: > Warcraft 2, C&C, etc. weren't really built to allow the players to
>: >mess with the AI much, unfortunately. We had an interesting thread a
>: >while back on this very newsgroup discussing the desirabilty of such
>: >games, and the general consensus was that it would be a lot of fun
>: >for us AI weenies to play with. ;)
>:
>: So there'd be some interest in, say, a construction kit which allows
>: the creation of WarCraft II style games, complete with programming
>: language for the units ?
>:
>: One that allows units to order other units about. Complete with full
>: combat model and all the rest ( customisable economy, add-in graphics
>: and maybe network play ) ?
>
> The interest seemed high, but this is an AI newsgroup full of hackers. ;)
>The thread itself centered on the question of how one might design such a
>game (with an AI interface) and whether or not it would sell enough
>copies to make it worth the extra effort. While nearly everybody here
>thought it would be a great thing to see and fiddle with, there was
>massive disagreement over whether the "sales benefits" of having such
>a feature would outweigh the costs of implementing, documenting, and
>user-proofing it.
Ah -- no. The concept here is to have a system into which user created
systems can be plugged - think DOOM wads. I guess the compiled modules
that are shipped with the games produced under the system could be
"hacked", but there are people who'll do that to non-open
architectures as well.
As for the cost of implementation, it was desigend in from the start,
and turns out to be no harder than a closed architecture. Admitedly
the development environment is a bit unfriendly at the moment ( being
a bundle of command line compilers running under Linux ) but
shiny-spangly intelligence-free Winders interfaces shouldn't prove too
hard.
The "AI" is a tad lower level than most people here are probably used
to -- think an assembly language with some instructions for things like
"find the nearest entity to me".
>:
>: Some of us might have such a project on the go, you see, and just need
>: some encouragement.
>
> You too eh? So far my managers love the idea, but since they haven't
>had to commit yet talk is, as we say, cheap.
Um. _Being_ the manager has some advantages it seems.. I have the
basic system up & running, units are obeying the language ( only about
half is implemented yet ) and the world model seems fine - things can
shoot at other things. There's no large scale navigation routine yet
and the economic stuff is only starting to be tested yet.
Mind you I do keep having to stop and go do "real" work as well..
The big thing is I want to sell games written with it on a shareware
type basis, but give away the system so other people can write
components too. Trouble is no-one really seems to like this idea --
all the publishers go green in the face with the thought of
non-proprietry stuff that hasn't got a lock on each and every byte,
and the public hate the idea of not having a "proper" bit of
software. ( They're the ones who don't like Emacs because it includes
a programming interface and therefore "isn't finished". )
From: tallent1#airmail,net
Subject: Re: War Craft II
Date: 16 Dec 1996 11:07:28 GMT
In <58pdtm$nus#herald,concentric.net>, Swoodcoc#cris,com (Steven Woodcock) writes:
>
>Nigel Sim (Nigel_Sim#msn,com) wrote:
>: How is it possible to write a new AI engine for War2. Hack it...if
>: so has anyone done it??? Or have a network program that plays in the
>: place of human player.
>: Thanks
>
>Hello Nigel:
>
> Well, the short answer is of course...anything's possible. ;)
>
> Having made the obligatory smartaleck remark, I don't believe there
>are any tools or interfaces built into War2 to allow you to do such a
>thing. The only three games I know of on the market that have any form of
>"roll your own AI" are Abuse (they have a LISP-based interface you can
>do some things with), Quake (there's a programming kit out there someplace
>that many players are using to build Quake 'bots), and the Carriers
>At War series (using their scenario builder you can adjust the AI
>fairly extensively).
Just for the record. There are two other games that have development
kits for reprogramming their AI. "Galactic Civilizations", and "Master of the
Empire". Both of these are OS/2 games, which I presume just bores most
of you out there... But I thought I'd let it be known anyhow...
take it easy
walter
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: War Craft II
Date: 16 Dec 1996 15:01:44 GMT
tallent1#airmail,net wrote:
:
: Just for the record. There are two other games that have development
: kits for reprogramming their AI. "Galactic Civilizations", and "Master of the
: Empire". Both of these are OS/2 games, which I presume just bores most
: of you out there... But I thought I'd let it be known anyhow...
Walter:
Thanks for the info, guy. I'm thinking about adding a page to my Game
AI page that talks about games that let you fiddle with their AI, and this is
good info to know.
Steve
From: bradley#ai-lab,fh-furtwangen.de (Bradley Richards)
Subject: Re: War Craft II
Date: Tue, 17 Dec 96 12:21:11 GMT
In article <58ulgu$ocu#herald,concentric.net>, Swoodcoc#cris,com (Steven Woodcock) wrote:
>
>Keith M. Lucas (sillywiz#excession,demon.co.uk) wrote:
>: Some of us might have such a project on the go, you see, and just need
>: some encouragement.
>
> You too eh? So far my managers love the idea, but since they haven't
>had to commit yet talk is, as we say, cheap.
Encourage, encourage... I have long been looking for such a game, so I could
give it to my AI students and say "go thou and practiceth what I preach".
As yet no luck finding a suitable game.
BTW, as long as some game designers do read this group, why isn't this done
as a matter of course? In *any* game that provides computer opponents,
reasonable software engineering demands that the computer opponents work
through some sort of reasonably clean interface. Documenting this interface
and making it available with some sort of add-on toolkit would cost little
and could bring in a lot of additional interest in the game.
If said interface *doesn't* exist, then someone in the game firm needs to
go re-take Software Engineering 101...
Cheers,
Bradley
-----------------------------------------------------------------------
Bradley L. Richards, AI Lab, Fachhochschule Furtwangen, D-78120 Germany
<A HREF="http://www.ai-lab.fh-furtwangen.de:80/~bradley/">http://www.ai-lab.fh-furtwangen.de:80/~bradley/</A>
bradley#ai-lab,fh-furtwangen.de
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: War Craft II
Date: 17 Dec 1996 17:19:40 GMT
Bradley Richards (bradley#ai-lab,fh-furtwangen.de) wrote:
: In article <58ulgu$ocu#herald,concentric.net>, Swoodcoc#cris,com (Steven Woodcock) wrote:
: > You too eh? So far my managers love the idea, but since they haven't
: >had to commit yet talk is, as we say, cheap.
:
: Encourage, encourage... I have long been looking for such a game, so I could
: give it to my AI students and say "go thou and practiceth what I preach".
: As yet no luck finding a suitable game.
As I said in an earlier posting, there are only 6 games I can think
of that come close here:
* Abuse -- They have a LISP-based interface you can
do some things with.
* Carriers At War series -- Using their scenario builder you can
adjust the AI fairly extensively.
* CDDNA -- A Risk-like game that uses genetic algorithms and
which offers a little "lab" for breeding new and
better AIs.
* Galactic Civilizations -- OS/2 game with an AI programming kit
* Master of the Empire -- Another OS/2 game (from the same company
as Gal Civ, I think) with an AI programming
kit.
* Quake -- There's a programming kit out there someplace
that many players are using to build Quake 'bots.
Maybe one of those will help you with your classes?
:
: BTW, as long as some game designers do read this group, why isn't this done
: as a matter of course? In *any* game that provides computer opponents,
: reasonable software engineering demands that the computer opponents work
: through some sort of reasonably clean interface. Documenting this interface
: and making it available with some sort of add-on toolkit would cost little
: and could bring in a lot of additional interest in the game.
:
: If said interface *doesn't* exist, then someone in the game firm needs to
: go re-take Software Engineering 101...
Heh. I would have to argue that a BIG part of the reason is indeed
a "poor adherence to software design philosophy" on the part of many
developers. I've seen games that you couldn't have wedged a linked list
into cleanly. ;)
Having said that, however, I think the larger reasons are simply
a.) lack of a demand for such a feature (we can argue whether this is
perceived or real), b.) the return on investment that such a feature
would provide, and c.) fear of revealing company secrets.
Let's tackle "a" first. Exactly how much demand for a programmable
AI is there in the marketplace? Pretty much everybody who reads this
newsgroup would love it, sure, but how many 15 year-old Warcraft II
players really want a game with an interface that allows them to plug
in their own AI modules? It's one thing to offer up some options in
the scenario builder to make the AI "agressive", "passive", etc....that's
just clicking buttons, and the user is very restricted in what he
can do. But it's quite another thing to build in programming and
function interfaces to allow some budding C/C++/Delphi programmer
to "roll his own" AI for a game.
And that leads neatly to issue "b". If we were to add such a feature
to (for example) Warcraft II, it would need EXTENSIVE documentation...arguably
more than the game itself. The interface would need to be robust, so
that the user doesn't do some spectacularly stupid and erase his
hard drive. It needs to allow for some kind of dynamic linking (since
nobody's going to hand over full game source code), so it'll pretty
much need to be a DLL (don't know what the Mac equivalent is). You'll
also have to decide what language interfaces to support, whether or not
the user will be allowed to add new extensions to the AI interface,
and how you're going to SUPPORT these budding young developers when
they start calling Blizzard at 3:00 AM with a DLL-interface error.
And don't forget the development time to put this in and test it all
out; it's got to be part of the game's development schedule, and will
only make it longer. Many developers might think this is worth it,
but selling it to their managers (whose eyes are always on the budget
and the schedule) probably won't.
Issue "c" is a particularly thorny one which I myself have run into
quite often. Those few developers who *are* AI weenies (such as myself)
are often quite proud of something they've put into a particular game.
It may be a wicked fast pathing algorithm, or an extremely flexible
targetting algorithm, or just a very compact data structure in which
full unit details are stored. Depending on the implementation of
your AI interface, you may have to reveal these to the world...or enough
of them for another keen AI developer to suss out what you're doing.
That means you've just handed over a competitive advantage of SOME
kind. Try running THAT by your boss....
Don't get me wrong. Personally I think there's a great market
for a game that provides this kind of adaptability, and an fighting to
include it in a future project or two. But the problems above are
very real and (in my humble opinion) the main reason why you don't
really see much along these lines today.
Steve
From: ccamuys#dingo,cc.uq.oz.au (Andrae Muys)
Subject: Re: War Craft II
Date: 18 Dec 1996 01:24:55 GMT
Steven Woodcock (Swoodcoc#cris,com) wrote:
: Bradley Richards (bradley#ai-lab,fh-furtwangen.de) wrote:
: : In article <58ulgu$ocu#herald,concentric.net>, Swoodcoc#cris,com (Steven Woodcock) wrote:
: : If said interface *doesn't* exist, then someone in the game firm needs to
: : go re-take Software Engineering 101...
: Heh. I would have to argue that a BIG part of the reason is indeed
: a "poor adherence to software design philosophy" on the part of many
: developers. I've seen games that you couldn't have wedged a linked list
: into cleanly. ;)
Surely this only increases the development cost of the game. After all if
you do have clean interfaces between graphics, ai, networking, game-engine
etc I would have thought this would have reduced development time,
especially of the 'next' version. Hopefully you can convince management
that a good software design philosophy is a good idea.
: Having said that, however, I think the larger reasons are simply
: a.) lack of a demand for such a feature (we can argue whether this is
: perceived or real), b.) the return on investment that such a feature
: would provide, and c.) fear of revealing company secrets.
: Let's tackle "a" first. Exactly how much demand for a programmable
: AI is there in the marketplace. Pretty much everybody who reads this
: newsgroup would love it, sure, but how many 15 year-old Warcraft II
: players really want a game with an interface that allows them to plug
: in their own AI modules? It's one thing to offer up some options in
: the scenario builder to make the AI "agressive", "passive", etc....that's
: just clicking buttons, and the user is very restricted in what he
: can do. But it's quite another thing to build in programming and
: function interfaces to allow some budding C/C++/Delphi programmer
: to "roll his own" AI for a game.
This fails to consider the 'entire' demand. Naturally direct demand for
the capacity to write your own AI is small, if it wasn't few of us would
have a job :). However you fail to consider a very signifigant
indirect demand, which if marketed well should form a large market.
Westwood are you listening... The brother of a friend of my best friend
(no it's not monty python) purchased Red Alert. Throught that contorted
train I have had a chance to play it. Personally the AI sucks. Better
then C&C but then I have all the experience from completing C&C to fall
back on. I am sorry but it is just too easy to hold my attention. I will
NOT be purchasing it. The graphics are fine, the game play has a little
too much mouse clicking then I would like but I can live with it. The AI
however is very disapointing, (BTW my best friend who is not a programmer,
just a wargame freak, like myself, came the that exact same conclusion
before I even saw it). I will not buying Red Alert. I was intending to
but Red Alert. If I could write my own AI routines/download and install
them off the net I would have already bought Red Alert. Remember .WADs,
you don't have to be able to design a WAD to use it. A replacable AI is a
marketable feature, don't market it as a 'programmable AI', sell it as a
'user upgradable AI'. Then publish the spec's of the interface so that
those of us who do enjoy programming can do your AI development for you.
: And that leads neatly to issue "b". If we were to add such a feature
: to (for example) Warcraft II, it would need EXTENSIVE documentation...arguably
: more than the game itself. The interface would need to be robust, so
Not that I've seen many well documented games.
: that the user doesn't do some spectacularly stupid and erase his
: hard drive. It needs to allow for some kind of dynamic linking (since
: nobody's going to hand over full game source code), so it'll pretty
: much need to be a DLL (don't know what the Mac equivalent is).
So you encapsulate all the information that your AI might need in objects,
and provide the AI read-only access to the data. Allow the AI to interact
with the game engine thru some form of message passing/member
functions/etc so if they really want to erase their hard-drives they are
going to have to work at it.
: You'll
: also have to decide what language interfaces to support, whether or not
: the user will be allowed to add new extensions to the AI interface,
: and how you're going to SUPPORT these budding young developers when
: they start calling Blizzard at 3:00 AM with a DLL-interface error.
This is just policy, work it out. What language do you use. Maybe
provide e-mail only support for the AI. You should expect AI developers
to read the documentation (if it's readable).
: And don't forget the development time to put this in and test it all
: out; it's got to be part of the game's development schedule, and will
: only make it longer. Many developers might think this is worth it,
: but selling it to their managers (whose eyes are always on the budget
: and the schedule) probably won't.
It shouldn't take that much longer, not if you are using a clean
interface, and designing the code to be extensiable from the start. It
will require more resources however as you will have to prepare the
documentation in //'l with the development effort or the documentation
will cause a delay (and therefore be skimped, destroying the use of an
extensiable AI). I would be surprised if documentation is in the critical
path(provided you have the resources required to prepare it in //'l).
: Issue "c" is a particularly thorny one which I myself have run into
: quite often. Those few developers who *are* AI weenies (such as myself)
: are often quite proud of something they've put into a particular game.
: It may be a wicked fast pathing algorithm, or an extremely flexible
: targetting algorithm, or just a very compact data structure in which
: full unit details are stored. Depending on the implementation of
: your AI interface, you may have to reveal these to the world...or enough
: of them for another keen AI developer to suss out what you're doing.
: That means you've just handed over a competitive advantage of SOME
: kind. Try running THAT by your boss....
So implement the AI interface so you don't.
Of course you could also run a competition for the best AI's. With prizes
for different catagories. You would then be in a position to purchase the
rights for any particually good code and include it in subsequent
versions.
: Don't get me wrong. Personally I think there's a great market
: for a game that provides this kind of adaptability, and an fighting to
: include it in a future project or two. But the problems above are
: very real and (in my humble opinion) the main reason why you don't
: really see much along these lines today.
Yes I know you like the idea, and would love to be able to provide it/play
with it. I just feel that your arguements are a little lopsided. You
don't sell US on this idea, just the general public, and if you ensure
that there are a few alternative AI's avaliable before you release the
game I think the marketing guru's should be able to sell the general
public on the ide
'Hey guy's with this game, when you get bored with it, and can beat it
blindfolded, you just plug in a better AI and its a challange again!'
Andrae Muys.
The only problem I see with this is that if you have a game with
extensiable AI, most people will expect it to have extensiable everything
else. (Graphics, rules, etc).
Not that is that uncommon these day's.
--
=========================================================================
andrae#humbug,org.au | #include <favourite_disclaimer.h>
|
Andrae Muys | Linux... What do you want to DO today!
4th(and a half)Yr CSE |
University of Queensland. | Diplomacy is the art of saying "Nice Doggie!"
Australia | till you can find a rock. - Wynn Catlin
--
=========================================================================
andrae#humbug,org.au | #include <favourite_disclaimer.h>
|
Andrae Muys | Linux... What do you want to DO today!
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: War Craft II
Date: 18 Dec 1996 05:01:39 GMT
Organization: Wyrdhaven Wyrks
Apologies to all for the length of this post; I felt it necessary to
include large chunks of quotes so the discussion would be easier to
follow.
Andrae Muys (ccamuys#dingo,cc.uq.oz.au) wrote:
: Steven Woodcock (Swoodcoc#cris,com) wrote:
: : Heh. I would have to argue that a BIG part of the reason is indeed
: : a "poor adherence to software design philosophy" on the part of many
: : developers. I've seen games that you couldn't have wedged a linked list
: : into cleanly. ;)
:
: Surely this only increases the development cost of the game. After all if
: you do have clean interfaces between graphics, ai, networking, game-engine
: etc I would have thought this would have reduced development time,
: especially of the 'next' version. Hopefully you can convince management
: that a good software design philosophy is a good idea.
I agree completely, and have worked to design my games accordingly.
That allows me to get the "engine" up and running early and then add
things to it that I can *see* and play with.
Still, it's not necessarily the way it's done. It needs to be, and
I think the industry is going that way for precisely the reasons you
mention.
: : Let's tackle "a" first. Exactly how much demand for a programmable
: : AI is there in the marketplace. Pretty much everybody who reads this
: : newsgroup would love it, sure, but how many 15 year-old Warcraft II
: : players really want a game with an interface that allows them to plug
: : in their own AI modules? It's one thing to offer up some options in
: : the scenario builder to make the AI "agressive", "passive", etc....that's
: : just clicking buttons, and the user is very restricted in what he
: : can do. But it's quite another thing to build in programming and
: : function interfaces to allow some budding C/C++/Delphi programmer
: : to "roll his own" AI for a game.
:
: This fails to consider the 'entire' demand. Naturally direct demand for
: the capacity to write your own AI is small, if it wasn't few of us would
: have a job :). However you fail to consider a very signifigant
: indirect demand, which if marketed well should form a large market.
: (snip)
: If I could write my own AI routines/download and install
: them off the net I would have already bought Red Alert.
I agree again, of course, but that's not necessarily the market you
might think it is. In order to market a game with a capability you
can "plug into", you need to find a sufficient number of people who
a.) buy your game, b.) can program, and c.) have the time and inclination
to write their own AI.
I agree that the BEST feature of an upgradable AI is that users
that DO meet those criteria can put things together on a web site for
everybody ELSE to play with. That's a strong point, and one which
I've made to my management with some success. They remain dubious,
however, that there's enough interest out there to warrant this
type of effort (needless to say, I'm saving all of these posts to
show them! ;).
: Remember .WADs,
: you don't have to be able to design a WAD to use it. A replacable AI is a
: marketable feature, don't market it as a 'programmable AI', sell it as a
: 'user upgradable AI'.
The comparison with WAD files came up in the previous discussion, and
it's not one I think is very good. A WAD file is just a database file,
really...that's not that hard (relatively speaking) to put together
when compared to programming a DLL. The success of WAD files is what
makes this idea even remotely possible, but beyond that I think
(my opinion) there's a world of difference in terms of scale.
:
: : And that leads neatly to issue "b". If we were to add such a feature
: : to (for example) Warcraft II, it would need EXTENSIVE documentation...
: : arguably
: : more than the game itself. The interface would need to be robust, so
: : that the user doesn't do some spectacularly stupid and erase his
: : hard drive. It needs to allow for some kind of dynamic linking (since
: : nobody's going to hand over full game source code), so it'll pretty
: : much need to be a DLL (don't know what the Mac equivalent is).
: So you encapsulate all the information that your AI might need in objects,
: and provide the AI read-only access to the data. Allow the AI to interact
: with the game engine thru some form of message passing/member
: functions/etc so if they really want to erase their hard-drives they are
: going to have to work at it.
Possible, certainly. That's pretty much the approach I'd take,
anyway. (Can you tell I've given this a *LOT* of thought? ;)
:
: : And don't forget the development time to put this in and test it all
: : out; it's got to be part of the game's development schedule, and will
: : only make it longer. Many developers might think this is worth it,
: : but selling it to their managers (whose eyes are always on the budget
: : and the schedule) probably won't.
: It shouldn't take that much longer, not if you are using a clean
: interface, and designing the code to be extensiable from the start. It
: will require more resources however as you will have to prepare the
: documentation in //'l with the development effort or the documentation
: will cause a delay (and therefore be skimped, destroying the use of an
: extensiable AI). I would be surprised if documentation is in the critical
: path(provided you have the resources required to prepare it in //'l).
This I disagree with. There's a world of difference between the
game's design and interface spec, which is what a developer will work
from, and real honest-to-gosh documentation that a user is going to
read. And don't forget the little, assumed thing. I might "know" to
only hand the AI a sorted linked list of units, to the point that it's
second nature. The user needs documentation that spells that out,
two or three times, with an example.
That's why you find books describing the features and functions of,
say, Netscape (arguably one of the simplest pieces of software to use
around). If you do your AI's job right, you may have some 68 functions
(just to pick a random number from my last design document) that do
various things. Those all need good documenting, and that adds
to Ye Olde Software Schedule.
Managers WILL go for that, IF you can show them (up front) that it
will add to the saleabilty and marketability of the product. The
reasons for why that is so you outlined very well above, and I even
agree with them...the trick is convincing managers that this isn't
a "geek" thing. ;)
:
: Of course you could also run a competition for the best AI's. With prizes
: for different catagories. You would then be in a position to purchase the
: rights for any particually good code and include it in subsequent
: versions.
One of the very best reasons for doing it: publicity. As someone
once said, "Any publicity is good publicity". Running contests,
providing regular upgrades ("Now Available: The Patton Template!"),
etc. are great ways to make the idea more saleable and palatable.
Particularly if the company feels this will be a "hit" game from
the start.
:
: Yes I know you like the idea, and would love to be able to provide it/play
: with it. I just feel that your arguements are a little lopsided.
They probably are; I felt everybody here already knew the GOOD reasons
why this ought to be done by SOMEBODY. ;) But not everybody here knows
how those strange critters called Managers view this....
: You
: don't sell US on this idea, just the general public, and if you ensure
: that there are a few alternative AI's avaliable before you release the
: game I think the marketing guru's should be able to sell the general
: public on the ide
Another good point. I'll add that one to my arsenal.
:
: The only problem I see with this is that if you have a game with
: extensiable AI, most people will expect it to have extensiable everything
: else. (Graphics, rules, etc).
: Not that is that uncommon these day's.
Hmmmm....good point. The ultimate extension of this, of course, is
a core game engine that anybody can hang anything off of. THAT could
be interesting too, though a bit weird to see evolve....
Steve
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Re: War Craft II
Date: Wed, 18 Dec 1996 14:45:17 GMT
In article <597trj$d01#herald,concentric.net>,
Swoodcoc#cris,com (Steven Woodcock) wrote:
>
> The comparison with WAD files came up in the previous discussion, and
>it's not one I think is very good. A WAD file is just a database file,
>really...that's not that hard (relatively speaking) to put together
>when compared to programming a DLL. The success of WAD files is what
>makes this idea even remotely possible, but beyond that I think
>(my opinion) there's a world of difference in terms of scale.
>
I'd like to add a point here. In my "Battles" series of shareware games,
I did place scenario specific AI code and data in a .dll, and called that
..dll from the main engine of the game, to produce the computer opponent
for a given scenario. This was not a 'public access' to the AI but more
a way for me to produce specific AI for each scenario, with a minimum
of fuss on my part.
FWIW, that was far more complex than just producing a .wad or .pud file.
>:
>: : And that leads neatly to issue "b". If we were to add such a feature
>: : to (for example) Warcraft II, it would need EXTENSIVE documentation...
>: : arguably
>: : more than the game itself. The interface would need to be robust, so
>: : that the user doesn't do some spectacularly stupid and erase his
>: : hard drive. It needs to allow for some kind of dynamic linking (since
>: : nobody's going to hand over full game source code), so it'll pretty
>: : much need to be a DLL (don't know what the Mac equivalent is).
>: So you encapsulate all the information that your AI might need in objects,
>: and provide the AI read-only access to the data. Allow the AI to interact
>: with the game engine thru some form of message passing/member
>: functions/etc so if they really want to erase their hard-drives they are
>: going to have to work at it.
>
> Possible, certainly. That's pretty much the approach I'd take,
>anyway. (Can you tell I've given this a *LOT* of thought? ;)
>
I view creating the encapsulated interface that is suggested, as
yet another layer of coding, that does not necessarily need to be
done, if the AI access was not going to be public.
Thus, in order to "hide" my AI object properly, I have to wrap it in
yet another object. That increases the complexity of the AI, makes
it harder to test/debug and increases the development time.
If I don't wrap my AI objects, then their public access must be made
known to all (to be able to access) who want to tweak it.
This is not all bad, but it is an _extra_ cost of development.
>:
>: : And don't forget the development time to put this in and test it all
>: : out; it's got to be part of the game's development schedule, and will
>: : only make it longer. Many developers might think this is worth it,
>: : but selling it to their managers (whose eyes are always on the budget
>: : and the schedule) probably won't.
>: It shouldn't take that much longer, not if you are using a clean
>: interface, and designing the code to be extensiable from the start. It
>: will require more resources however as you will have to prepare the
>: documentation in //'l with the development effort or the documentation
>: will cause a delay (and therefore be skimped, destroying the use of an
>: extensiable AI). I would be surprised if documentation is in the critical
>: path(provided you have the resources required to prepare it in //'l).
>
> This I disagree with. There's a world of difference between the
>game's design and interface spec, which is what a developer will work
>from, and real honest-to-gosh documentation that a user is going to
>read. And don't forget the little, assumed thing. I might "know" to
>only hand the AI a sorted linked list of units, to the point that it's
>second nature. The user needs documentation that spells that out,
>two or three times, with an example.
>
I agreed with Steve, 110% on this! Regardless of how _clean_ the interface
is, or how _extensible_ the design is, adding public access to the game's
AI is going to cost more to develop. The simple reason is that 'public'
access is not needed in the development of a game that does not support it.
RE: documentation. IMO, it is at least an order of magnitude more work to
produce a Game AI API Reference Manual than a Game Instruction Manual.
Fundamentally, I like the idea (I've even done it on my own "Battles"
series, although that access was never publicized), however every
publisher I've pitched it to, and developer I've worked with, has not
yet been able to justify the added cost of development, in order to
do it for another game.
IMHO, when a hit game comes out, in which the public access to the AI
proves to be the killer selling point, then you will see this feature
provided in _all_ games. Considering that so many computer game developers
and publishers in the recent past, have prioritized AI development behind
glitz: graphics, animation, frame-rate, killer music and sound; and network
and mulit-player play has reduced the role of the computer AI opponent in
games; then I personally do not hold much hope that it will happen soon.
Now, if any of you folks who want this feature in a computer game would
be willing to put up the $500,000 (or more) for development of a new
commercial quality computer game with this feature, then I know myself,
Steve, Andrew, or any number of other computer game AI developers would
LOVE to be able to put our ideas (some already tested) to work, and provide
public access to the game's AI via a programmable interface (a .dll actually).
Regards,
Eric
From: "Keith M. Lucas" <sillywiz#excession,demon.co.uk>
Subject: Re: War Craft II
Date: Wed, 18 Dec 1996 17:35:38 GMT
In article <5963ff$9o3#zeus,ai-lab.fh-furtwangen.de>,
Bradley Richards <bradley#ai-lab,fh-furtwangen.de> wrote:
>In article <58ulgu$ocu#herald,concentric.net>, Swoodcoc#cris,com (Steven Woodcock) wrote:
>>
>>Keith M. Lucas (sillywiz#excession,demon.co.uk) wrote:
>>: Some of us might have such a project on the go, you see, and just need
>>: some encouragement.
>>
>> You too eh? So far my managers love the idea, but since they haven't
>>had to commit yet talk is, as we say, cheap.
>
>Encourage, encourage... I have long been looking for such a game, so I could
>give it to my AI students and say "go thou and practiceth what I preach".
>As yet no luck finding a suitable game.
Better be using Linux then !!
( Seriously, A Windows port will not be too far distant as long as I
can find a compiler which doesn't blow the budget. ( I've got DJGPP
for the DOS version. Just got to get started on it !! ))
Sound driver is currently very broken.. I think I may have found a bug
in the Linux sound system, the file never appears to signal
ready-for-writing in a select(). Very scary.
>BTW, as long as some game designers do read this group, why isn't this done
>as a matter of course? In *any* game that provides computer opponents,
>reasonable software engineering demands that the computer opponents work
>through some sort of reasonably clean interface. Documenting this interface
>and making it available with some sort of add-on toolkit would cost little
>and could bring in a lot of additional interest in the game.
No -- it's clear, very clear from many games, that much of the AI is
not as clean as required. C&C uses an AI that can:
a) Build units from the enemy side.
b) Build units without enough money.
c) Build buildings disobeying the rules applied to the humans.
d) See, and issue orders to, many units in parallel.
e) See unexposed areas of ground.
[ I think it cheats to the extent of if you build aircraft and you
can't see its base, the base gets AA guns added. But I can't prove
that yet. ]
WarCraft also cheats.
The AI code seems very deeply embedded in the game, it accesses data
that it should not in order to win. And clean interfaces are a bit of
an anathema to most of the games world.
>If said interface *doesn't* exist, then someone in the game firm needs to
>go re-take Software Engineering 101...
Most games programmers need to go _TAKE_ Software Engineering 101.
Having worked for a large games company I can tell you that structured
methods, revision control and interface design are simply three
mythical subjects to them. It's a source of pride to most of the games
programmers I've met that they have no education beyond age 16 -- they
think it makes them more "dynamic" because they aren't "locked into a
mindset".
Oh yeah -- their code is shit and unmaintainable. All the stunts --
routine does two TOTALLY seperate tasks and a boolean input
picks. Endless loops with no error reports. None of them know what a
manual looks like and tend to program by cargo cult -- they take the
bits of code that worked in the last project and re-use them. Whether
they're needed or not...
Hey, maybe I should post the draft of the embedded language !! Then you
can all critique it. :-( !!
From: ccamuys#student,uq.edu.au (Andrae Muys)
Subject: Re: War Craft II
Date: 19 Dec 1996 00:37:25 GMT
To save on typing I am using the contraction ExAI to replace the multitude
of occurances of Extensiable AI. (don't you just hate it when they use X
as a contraction of Ex :)
Steven Woodcock (Swoodcoc#cris,com) wrote:
: Andrae Muys (ccamuys#dingo,cc.uq.oz.au) wrote:
: : Steven Woodcock (Swoodcoc#cris,com) wrote:
: :
: : This fails to consider the 'entire' demand. Naturally direct demand for
: : the capacity to write your own AI is small, if it wasn't few of us would
: : have a job :). However you fail to consider a very signifigant
: : indirect demand, which if marketed well should form a large market.
: : (snip)
: : If I could write my own AI routines/download and install
: : them off the net I would have already bought Red Alert.
I feel that I should explain here that my 'raving' concerning Red Alert
was provided as much to provide a 'real' case study of a NO SALE caused
directly by the failure of AI to meet my needs. (AI is the ONLY reason we
haven't/won't bought(buy) this game).
: I agree again, of course, but that's not necessarily the market you
: might think it is. In order to market a game with a capability you
: can "plug into", you need to find a sufficient number of people who
: a.) buy your game, b.) can program, and c.) have the time and inclination
: to write their own AI.
My gut feeling (and this is only intuition :) is that in the case of AI,
'sufficient' is no more then half a dozen or so. All other extensions to
games marketed so far (graphics/senarios) don't change the game play. So
once you had mastered the game itself all these extensions provided were
pretty pictures and insanely difficult(biased) options. In the case of
ExAI you are talking about improving the challange of the game across all
senarios.
:
: : Remember .WADs,
: : you don't have to be able to design a WAD to use it. A replacable AI is a
: : marketable feature, don't market it as a 'programmable AI', sell it as a
: : 'user upgradable AI'.
:
: The comparison with WAD files came up in the previous discussion, and
: it's not one I think is very good. A WAD file is just a database file,
: really...that's not that hard (relatively speaking) to put together
: when compared to programming a DLL. The success of WAD files is what
: makes this idea even remotely possible, but beyond that I think
: (my opinion) there's a world of difference in terms of scale.
:
Yes, and No, and No.
Yes it came up last time.
No they aren't a good comparison to ExAI.
But No you didn't read what I actually wrote. I am fully aware of the
couple of orders of magnitude difference in the complexity of ExAI
compared to .WADs. I was just making the point that you don't have to be
able to program to be able to take full advantage of ExAI, and that this
is something that you sell to everyone not just us AI weenies.
: : So you encapsulate all the information that your AI might need in objects,
: : and provide the AI read-only access to the data. Allow the AI to interact
: : with the game engine thru some form of message passing/member
: : functions/etc so if they really want to erase their hard-drives they are
: : going to have to work at it.
:
: Possible, certainly. That's pretty much the approach I'd take,
: anyway. (Can you tell I've given this a *LOT* of thought? ;)
:
Really OO is the only 'safe' way I can think of doing it currently. It's
not so much their machine that's the problem, rather retaining a stable
installation of your game. You can't really afford to have the user
mucking around with the internals of the game without strict access
controls. (ie data access methods).
: : : And don't forget the development time to put this in and test it all
: : : out; it's got to be part of the game's development schedule, and will
: : : only make it longer. Many developers might think this is worth it,
: : : but selling it to their managers (whose eyes are always on the budget
: : : and the schedule) probably won't.
: : It shouldn't take that much longer, not if you are using a clean
: : interface, and designing the code to be extensiable from the start. It
: : will require more resources however as you will have to prepare the
: : documentation in //'l with the development effort or the documentation
: : will cause a delay (and therefore be skimped, destroying the use of an
: : extensiable AI). I would be surprised if documentation is in the critical
: : path(provided you have the resources required to prepare it in //'l).
:
: This I disagree with. There's a world of difference between the
: game's design and interface spec, which is what a developer will work
: from, and real honest-to-gosh documentation that a user is going to
: read. And don't forget the little, assumed thing. I might "know" to
: only hand the AI a sorted linked list of units, to the point that it's
: second nature. The user needs documentation that spells that out,
: two or three times, with an example.
: That's why you find books describing the features and functions of,
: say, Netscape (arguably one of the simplest pieces of software to use
: around).
But then again I wouldn't expect anyone who needs a netscape book to even
attempt to write their own AI :) (I suspect this might be a strawman
thrown up by some of steves manager's :)
If you reread what I wrote above you will see that I never suggested that
the documentation will be as simple/cheap/etc as game instructions (I
hesitate to call them documentaion). I am just not convinced that it is
in the critical path, it therefore shouldn't affect the time to market.
: If you do your AI's job right, you may have some 68 functions
: (just to pick a random number from my last design document) that do
: various things. Those all need good documenting, and that adds
: to Ye Olde Software Schedule.
:
See above, however of course if you aren't willing to add the necessary
resources to write the documentation, you will find yourself facing
time to market pressures. (and I expect the documentation will be skimped,
the ExAI will fail and so much for a good idea :()
: : Of course you could also run a competition for the best AI's. With prizes
: : for different catagories. You would then be in a position to purchase the
: : rights for any particually good code and include it in subsequent
: : versions.
:
: One of the very best reasons for doing it: publicity. As someone
: once said, "Any publicity is good publicity". Running contests,
: providing regular upgrades ("Now Available: The Patton Template!"),
: etc. are great ways to make the idea more saleable and palatable.
: Particularly if the company feels this will be a "hit" game from
: the start.
Sorry that was me being lopsided :). The right's issue is of course only
a side show (although I would consider it an important one). The main
game is the publicity you hope to gain for it.
: : Yes I know you like the idea, and would love to be able to provide it/play
: : with it. I just feel that your arguements are a little lopsided.
:
: They probably are; I felt everybody here already knew the GOOD reasons
: why this ought to be done by SOMEBODY. ;) But not everybody here knows
: how those strange critters called Managers view this....
But of course when we discuss this issue hopefully we share arguements in
favour. Arguements that we might not have thought of otherwise.
: : You
: : don't sell US on this idea, just the general public, and if you ensure
: : that there are a few alternative AI's avaliable before you release the
: : game I think the marketing guru's should be able to sell the general
: : public on the ide
:
: Another good point. I'll add that one to my arsenal.
See :)
: : The only problem I see with this is that if you have a game with
: : extensiable AI, most people will expect it to have extensiable everything
: : else. (Graphics, rules, etc).
: : Not that is that uncommon these day's.
:
: Hmmmm....good point. The ultimate extension of this, of course, is
: a core game engine that anybody can hang anything off of. THAT could
: be interesting too, though a bit weird to see evolve....
:
Yes I thought that too when I said it. But documenting one interface
should be out of the critical path. Documenting ALL of them just might
put it in there.
Andrae Muys.
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: War Craft II
Date: 19 Dec 1996 01:29:10 GMT
Keith M. Lucas (sillywiz#excession,demon.co.uk) wrote:
: In article <58ulgu$ocu#herald,concentric.net>,
: Steven Woodcock <Swoodcoc#cris,com> wrote:
: > The interest seemed high, but this is an AI newsgroup full of hackers. ;)
: >The thread itself centered on the question of how one might design such a
: >game (with an AI interface) and whether or not it would sell enough
: >copies to make it worth the extra effort. While nearly everybody here
: >thought it would be a great thing to see and fiddle with, there was
: >massive disagreement over whether the "sales benefits" of having such
: >a feature would outweigh the costs of implementing, documenting, and
: >user-proofing it.
:
: Ah -- no.
Ah...yes. I think maybe you missed the point (at least what I take
to be the point) of the discussion so far.
: The concept here is to have a system into which user created
: systems can be plugged - think DOOM wads. I guess the compiled modules
: that are shipped with the games produced under the system could be
: "hacked", but there are people who'll do that to non-open
: architectures as well.
...which is basically what we're all in agreement with, actually.
What we're trying to figure out are the $$$ reasons that a manager will
understand to let us go and do this thing. ;)
:
: As for the cost of implementation, it was desigend in from the start,
: and turns out to be no harder than a closed architecture.
Implementation *is* different for such beastie, for the very reasons
that poster Eric Dysband mentioned earlier. Doing this kind of thing
means *some* kind of layer between the "game" and the "AI", a layer
which is intrinsically slower than direct access and which must be
documented for a USER to use. That documentation can't be overlooked...
just look at the C programming language, which has only what? 60 commands?
and yet books can run hundreds and pages and not touch more than a fraction
of the available power.
If your modular AI is done right (I think my design is, anyway), then
it just might need a book that big to document it.....
:
: The "AI" is a tad lower level than most people here are probably used
: to -- think an assembly language with some instructions for things like
: "find the nearest entity to me".
Agreed. Good analogy.
:
: Um. _Being_ the manager has some advantages it seems.. I have the
: basic system up & running, units are obeying the language ( only about
: half is implemented yet ) and the world model seems fine - things can
: shoot at other things. There's no large scale navigation routine yet
: and the economic stuff is only starting to be tested yet.
I'm glad to hear that SOMEBODY is fiddling with this! I wish
you the best of luck on it.
: The big thing is I want to sell games written with it on a shareware
: type basis, but give away the system so other people can write
: components too. Trouble is no-one really seems to like this idea --
: all the publishers go green in the face with the thought of
: non-proprietry stuff that hasn't got a lock on each and every byte...
This may be the only way to get this done....I've been toying with
the idea myself. If successful, THEN publishers might buy into the
idea. As you yourself noted, however, they'll take some convincing.
Right now you've got a couple of companies announcing lawsuits over
EDITORS that have been developed for their games....the idea of providing
an interface into the game AI will probably send some of them straight
into a stroke ;)
Steve
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: War Craft II
Date: 19 Dec 1996 01:43:02 GMT
Andrae Muys (ccamuys#student,uq.edu.au) wrote:
: To save on typing I am using the contraction ExAI to replace the multitude
: of occurances of Extensiable AI. (don't you just hate it when they use X
: as a contraction of Ex :)
Works for me. ;)
: In the case of
: ExAI you are talking about improving the challange of the game across all
: senarios.
Agreed, and I love the idea. It's tougher to sell that to a manager,
though. You can talk about how you can upgrade the AI and sponsor
contests and make continual improvements, and what THEY (often) see
is merely on ongoing drain on resources better put to another game.
The best I've gotten so far from *my* folks is "well, but wouldn't we
just want to save all of that for a sequel?". That's when I try to
talk to them about the power of using the Net and all those rabid gamers
out there, and how that leverages *my* brainpower, etc., etc., and
they get that panicked look in their eye that says "I don't understand
a word he's saying...".
Though I've been told I can get a bit *passionate* about explaining
this *cool* idea.... ;)
: : The comparison with WAD files came up in the previous discussion, and
: : it's not one I think is very good. A WAD file is just a database file,
: : really...that's not that hard (relatively speaking) to put together
: : when compared to programming a DLL. The success of WAD files is what
: : makes this idea even remotely possible, but beyond that I think
: : (my opinion) there's a world of difference in terms of scale.
: :
: Yes, and No, and No.
: Yes it came up last time.
: No they aren't a good comparison to ExAI.
: But No you didn't read what I actually wrote. I am fully aware of the
: couple of orders of magnitude difference in the complexity of ExAI
: compared to .WADs. I was just making the point that you don't have to be
: able to program to be able to take full advantage of ExAI, and that this
: is something that you sell to everyone not just us AI weenies.
With luck, it can be an item which SELLS the game even if the average
gamer doesn't plan to use it. I mean, everybody who bought Warcraft II
has an editor, but very few actually really did more than fire it up
once and take a look. You're absolutely right about that.
: : That's why you find books describing the features and functions of,
: : say, Netscape (arguably one of the simplest pieces of software to use
: : around).
:
: But then again I wouldn't expect anyone who needs a netscape book to even
: attempt to write their own AI :) (I suspect this might be a strawman
: thrown up by some of steves manager's :)
Good catch. ;)
: If you reread what I wrote above you will see that I never suggested that
: the documentation will be as simple/cheap/etc as game instructions (I
: hesitate to call them documentaion). I am just not convinced that it is
: in the critical path, it therefore shouldn't affect the time to market.
: See above, however of course if you aren't willing to add the necessary
: resources to write the documentation, you will find yourself facing
: time to market pressures. (and I expect the documentation will be skimped,
: the ExAI will fail and so much for a good idea :()
I agree that most games no longer have documention, just info sheets. ;)
My worry is that in order to really USE this functionality it will
require decent documention. I suppose, however (now that I'm thinking
about it), that since we're already assuming the folks who would do this
are somewhat capable and connected, that you could just post the whole
kit and documentation on the company web page. Hmmmmmm....that just
might swing some opinions....lemme write that down....
: :
: : Hmmmm....good point. The ultimate extension of this, of course, is
: : a core game engine that anybody can hang anything off of. THAT could
: : be interesting too, though a bit weird to see evolve....
: :
: Yes I thought that too when I said it. But documenting one interface
: should be out of the critical path. Documenting ALL of them just might
: put it in there.
Of course, then you start getting towards something more like XConq,
or maybe the VonNeumann Project.
Good points, Andrew.
Steve
From: "Benton Jackson" <benton#bitstream,net>
Subject: ExAI security issues
Date: 19 Dec 1996 13:42:58 GMT
There's been some talk on this thread about using a .dll to implement
the plug-in ExAI. How do we address the security and/or reliability of
these .dll's? Some hacker could put in a "weapon" type that when a
particular monster shoots you with it, it nukes your hard drive.
Or, it could just be poorly written, and it crashes your game
making you look bad.
--
_ _ ___ _
|_) |_ |\ | | / \ |\ | Benton Jackson, Goat Rider
|_) |_ | \| | \_/ | \| Fenris Wolf Electronic Games
benton#fenriswolf,com <A HREF="http://www2.bitstream.net/~benton">http://www2.bitstream.net/~benton</A>
From: "Carl D. Burke" <cburke#mitre,org>
Subject: Re: ExAI security issues
Date: Thu, 19 Dec 1996 14:25:50 -0500
Benton Jackson wrote:
>
> There's been some talk on this thread about using a .dll to implement
> the plug-in ExAI. How do we address the security and/or reliability of
> these .dll's? Some hacker could put in a "weapon" type that when a
> particular monster shoots you with it, it nukes your hard drive.
> Or, it could just be poorly written, and it crashes your game
> making you look bad.
Hmmm... I really need to go back and read this thread, but it sounds
like what you need is something like the Java Virtual Machine to
run the AIs. The security manager in the JVM can prevent things like
access to local files, etc. The standard security manager class
might not give you what you need, but you may be able to inherit
from it and define a security policy that meets the needs of the game.
--
--------------------------------------------------
Carl Burke, cburke#mitre,org -- Morde me, iuvat
My opinions are mine and mine alone, unless you
agree with them. Then I'll share.
--------------------------------------------------
In the world of nightmares there are three separate
levels... the pits of fire, the mouth of the mud
badger, and telemarketing. -- Jay Martin, "Tommy"
--------------------------------------------------
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Extensible Game AI (was Warcraft 2 AI)
Date: Thu, 19 Dec 1996 14:35:10 GMT
Since we have renewed the discussion about an Extensible Game AI (ExAI)
and Steve Woodcock has announced that he will be archieving the discussion
for his Game AI web page, perhaps we should overlook the marketability
of such a feature, and ignore the fact that our developers and publishers
and managers fail to see the benefit of this idea, and just for the time
being, focus on what would be the generalized structure, form and the
capabilities of such a game AI feature?
Is anyone interested, in discussing this, without regard to if it could
be actually delivered in a commercial product?
Assuming someone (other than me) is interested, here is a start:
FORM
I would begin with a definition of what form the ExAI takes.
To me, an ExAI is a set of APIs (application program interface) or function
calls, that can be accessed from a sub-module, such as a .dll (data link
library as in Windows). These functions would allow an outside entity to
cause changes in computer opponent behavior, within the context of the game.
To others, an ExAI may be a set of keyword statements that are ASCII text in
a file, that are input to a computer game, which in turn provide outside
entity control over the game's computer opponent.
Other ideas? Comments?
Regards,
Eric
Eric Dybsand
Glacier Edge Technology
Glendale, Colorado, USA
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Re: ExAI security issues
Date: Thu, 19 Dec 1996 16:16:55 GMT
In article <01bbedb1$91e32f40$6fed90ce@blueheron>,
"Benton Jackson" <benton#bitstream,net> wrote:
>There's been some talk on this thread about using a .dll to implement
>the plug-in ExAI. How do we address the security and/or reliability of
>these .dll's? Some hacker could put in a "weapon" type that when a
>particular monster shoots you with it, it nukes your hard drive.
>Or, it could just be poorly written, and it crashes your game
>making you look bad.
>
Gee Benton, you make the same valid point that my developer and
publisher made when I brought the ExAI idea up to them.
FWIW, we felt it would take an extra layer of code, to provide the
security to prevent _most_ or _some_ of the above mentioned BAD things
from happening. Of course, if some outsider AI developer linking in
through your publically provided .dll access does crash the game that
a paying customer is playing, then guess who gets the BLAME?
Regards,
Eric
From: Mike White <mykey#geocities,com>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Fri, 20 Dec 1996 00:11:23 -0800
Andrae Muys wrote:
[Snip]
> Well so far we have .DLL, IPC, and scripting. I would be interested to
> hear if anyone else has thought of any other methods of implementing ExAI.
>
My $0.02,
.DLL: Dangerous....(Mentioned previously)
IPC: No Comment (I skimmed over that)
Script: Slow...
An Idea..
What about a language like Java, your EXE interprets the "machine code"
and doesn't allow access to anything outside of the game. It adds another
layer that probably make it unacceptable, but something along these lines.
I personally like the DLL.... Risks and all...
Mike
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: ExAI security issues
Date: 20 Dec 1996 01:12:33 GMT
Benton Jackson (benton#bitstream,net) wrote:
: There's been some talk on this thread about using a .dll to implement
: the plug-in ExAI. How do we address the security and/or reliability of
: these .dll's? Some hacker could put in a "weapon" type that when a
: particular monster shoots you with it, it nukes your hard drive.
: Or, it could just be poorly written, and it crashes your game
: making you look bad.
Benton:
Excellent point. You're really trusting that the anonymous
hacker developer out there who built the new "Ghandi AI" is a nice guy
and not somebody who's out to nuke your system. The problem with a
DLL link-in is similar to the one the Netscape folks are now discovering
with Java applets...you don't KNOW what the thing is doing.
One *possible* solution to this is to only allow "certified" AIs
to run with the game in question. Problem is, that means that the programmer
has to send the AI module to the company who built the game, and they
have to look at it and give it some kind of certification. Not only is
that cumbersome, slow, and costly (to the original developer), but it
reveals all of the hacker's secrets AND makes the certifier liable if
in fact they missed something.
It would also kill the whole idea of a group of users freely exchanging
AI modules.
On the third hand (this is getting fun), is it really a much different
situation than what you have with shareware and freeware now? I mean, you
see some nifty utility online and download it without much more than a
virus check; I'd wager the risk here is about the same. If a "bad AI"
does crop it, word can be spread quickly through newsgroups and web
pages.
Anyway, I don't really have a solution for that, but it IS certainly
worthy of discussion.... ;)
Steve
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 20 Dec 1996 01:21:55 GMT
Eric Dybsand (edybs#ix,netcom.com) wrote:
:
: (perhaps we should) just for the time
: being, focus on what would be the generalized structure, form and the
: capabilities of such a game AI feature?
:
: Is anyone interested, in discussing this, without regard to if it could
: be actually delivered in a commercial product?
Sounds good to me. :)
: FORM
:
: I would begin with a definition of what form the ExAI takes.
:
: To me, an ExAI is a set of APIs (application program interface) or function
: calls, that can be accessed from a sub-module, such as a .dll (data link
: library as in Windows). These functions would allow an outside entity to
: cause changes in computer opponent behavior, within the context of the game.
This is a good definition. A DLL is the most natural way (I feel) to
do this on a Windows platform, though I wouldn't necessarily want to leave
out the folks trying their hand with the new Playstation Yarouze systems
(a homebrew developer's kit for building PSX games).
Any such API (let me take a look at my design document) needs to have
functions which broadly provide the following:
-- status (position, strength, condition) of all units, probably
broken out by "team" or "side" or whatever as desired;
-- a pathing function of some kind so the homebrew AI can
determine how to get from A to B;
-- a terrain type report for each hex/location/whatever;
-- some functions that define the SCALES used in the game
for damage, movement, etc. (what good does it do to know
that Unit A has 10 hit points when you don't know if the
upper limit is 11 or 1100?);
-- functions for issuing orders to the units within the game
(move, attack, build, collect resources, etc.).
At a very high level these break out into what one could call
Status functions and Control functions.
:
: To others, an ExAI may be a set of keyword statements that are ASCII text in
: a file, that are input to a computer game, which in turn provide outside
: entity control over the game's computer opponent.
Hmmm...hadn't considered the scripted approach, but that may make
more sense for an adventure game. Good point.
Steve
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Fri, 20 Dec 1996 04:14:38 GMT
In article <59cpnj$ag7#herald,concentric.net>,
Swoodcoc#cris,com (Steven Woodcock) wrote:
>
>Eric Dybsand (edybs#ix,netcom.com) wrote:
>:
>: To me, an ExAI is a set of APIs (application program interface) or function
>: calls, that can be accessed from a sub-module, such as a .dll (data link
>: library as in Windows). These functions would allow an outside entity to
>: cause changes in computer opponent behavior, within the context of the game.
>
> This is a good definition. A DLL is the most natural way (I feel) to
>do this on a Windows platform, though I wouldn't necessarily want to leave
>out the folks trying their hand with the new Playstation Yarouze systems
>(a homebrew developer's kit for building PSX games).
>
> Any such API (let me take a look at my design document) needs to have
>functions which broadly provide the following:
>
> -- status (position, strength, condition) of all units, probably
> broken out by "team" or "side" or whatever as desired;
> -- a pathing function of some kind so the homebrew AI can
> determine how to get from A to B;
> -- a terrain type report for each hex/location/whatever;
> -- some functions that define the SCALES used in the game
> for damage, movement, etc. (what good does it do to know
> that Unit A has 10 hit points when you don't know if the
> upper limit is 11 or 1100?);
> -- functions for issuing orders to the units within the game
> (move, attack, build, collect resources, etc.).
>
Great list!
Perhaps a "communication with other players facility" might be handy too?
Eric
From: ccamuys#student,uq.edu.au (Andrae Muys)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 20 Dec 1996 05:01:31 GMT
Steven Woodcock (Swoodcoc#cris,com) wrote:
:
: Eric Dybsand (edybs#ix,netcom.com) wrote:
: :
: : FORM
: :
: : I would begin with a definition of what form the ExAI takes.
: :
: : To me, an ExAI is a set of APIs (application program interface) or function
: : calls, that can be accessed from a sub-module, such as a .dll (data link
: : library as in Windows). These functions would allow an outside entity to
: : cause changes in computer opponent behavior, within the context of the game.
:
There is another method that I haven't seen discussed yet. Coming from a
UNIX background myself, for me a natural interface would be some form of
IPC. The AI would run as a seperate process, and ExAI would be
implemented as a combination of IPC's. A combination of sockets (for
networked support), pipes, fifos, messages, and shared memory spaces would
probably work well. Then the new AI is simply compiled as an executable,
linked to a library(supplied) that handles all the IPC stuff, and ExAI
becomes as simple as passing the name of the AI executable to the Game as
a command line parameter(you could easily wrap a GUI config around this).
fork()
//if child then
exec ()//checked command line executable.
// else if parent then
run_game().
Of course this automatically solves the problem of rogue AI's trashing
your program (although they can still trash the host system).
: This is a good definition. A DLL is the most natural way (I feel) to
: do this on a Windows platform, though I wouldn't necessarily want to leave
: out the folks trying their hand with the new Playstation Yarouze systems
: (a homebrew developer's kit for building PSX games).
:
: Any such API (let me take a look at my design document) needs to have
: functions which broadly provide the following:
:
: -- status (position, strength, condition) of all units, probably
: broken out by "team" or "side" or whatever as desired;
Yes, probably indexed by unit id. As well as the ability to get a list of
unit id's.
struct {
int id;
int team;
} unit_id;
: -- a pathing function of some kind so the homebrew AI can
: determine how to get from A to B;
You might also want to provide a hook so that the user can add their own
pathing function.
: -- a terrain type report for each hex/location/whatever;
Yes, in fact if this is done well then you have provided a hook for the
user to add their own pathing function.
: -- some functions that define the SCALES used in the game
: for damage, movement, etc. (what good does it do to know
: that Unit A has 10 hit points when you don't know if the
: upper limit is 11 or 1100?);
Or this could be provided in the form of const's and #defines in a header
file.
: -- functions for issuing orders to the units within the game
: (move, attack, build, collect resources, etc.).
And of course here is where the performance penalty comes in. To prevent
bad code from destablising the AI, it will be necessary to check the
parameters in the functions.
: At a very high level these break out into what one could call
: Status functions and Control functions.
I personally see three catagories; Status, Control, and Information. The
information being more static then status.
: : To others, an ExAI may be a set of keyword statements that are ASCII text in
: : a file, that are input to a computer game, which in turn provide outside
: : entity control over the game's computer opponent.
:
: Hmmm...hadn't considered the scripted approach, but that may make
: more sense for an adventure game. Good point.
:
Well so far we have .DLL, IPC, and scripting. I would be interested to
hear if anyone else has thought of any other methods of implementing ExAI.
Andrae Muys.
From: "Keith M. Lucas" <sillywiz#excession,demon.co.uk>
Subject: Re: War Craft II
Date: Fri, 20 Dec 1996 10:45:57 GMT
In article <59a5p6$6av#herald,concentric.net>,
Steven Woodcock <Swoodcoc#cris,com> wrote:
>
>Keith M. Lucas (sillywiz#excession,demon.co.uk) wrote:
>: In article <58ulgu$ocu#herald,concentric.net>,
>
>: The concept here is to have a system into which user created
>: systems can be plugged - think DOOM wads. I guess the compiled modules
>: that are shipped with the games produced under the system could be
>: "hacked", but there are people who'll do that to non-open
>: architectures as well.
>
> ...which is basically what we're all in agreement with, actually.
>
>What we're trying to figure out are the $$$ reasons that a manager will
>understand to let us go and do this thing. ;)
Well personally I'm doing it as a component of the research into a far
distant future project (currently scheduled for release in 2002-3ish :)
which you can't know about..
>:
>: As for the cost of implementation, it was desigend in from the start,
>: and turns out to be no harder than a closed architecture.
>
> Implementation *is* different for such beastie, for the very reasons
>that poster Eric Dysband mentioned earlier. Doing this kind of thing
>means *some* kind of layer between the "game" and the "AI", a layer
>which is intrinsically slower than direct access and which must be
>documented for a USER to use. That documentation can't be overlooked...
>just look at the C programming language, which has only what? 60 commands?
>and yet books can run hundreds and pages and not touch more than a fraction
>of the available power.
>
> If your modular AI is done right (I think my design is, anyway), then
>it just might need a book that big to document it.....
It might well. Third party author anyone ?
>:
>: The "AI" is a tad lower level than most people here are probably used
>: to -- think an assembly language with some instructions for things like
>: "find the nearest entity to me".
>
> Agreed. Good analogy.
I'm actually using it because a) I can get it to run fast. b) I know
the approach works -- the last time I released a similar game the
target audience went nuts over it...
>:
>: Um. _Being_ the manager has some advantages it seems.. I have the
>: basic system up & running, units are obeying the language ( only about
>: half is implemented yet ) and the world model seems fine - things can
>: shoot at other things. There's no large scale navigation routine yet
>: and the economic stuff is only starting to be tested yet.
>
> I'm glad to hear that SOMEBODY is fiddling with this! I wish
>you the best of luck on it.
>
>: The big thing is I want to sell games written with it on a shareware
>: type basis, but give away the system so other people can write
>: components too. Trouble is no-one really seems to like this idea --
>: all the publishers go green in the face with the thought of
>: non-proprietry stuff that hasn't got a lock on each and every byte...
>
> This may be the only way to get this done....I've been toying with
>the idea myself. If successful, THEN publishers might buy into the
>idea. As you yourself noted, however, they'll take some convincing.
>Right now you've got a couple of companies announcing lawsuits over
>EDITORS that have been developed for their games....the idea of providing
>an interface into the game AI will probably send some of them straight
>into a stroke ;)
Hell, I'll self publish if necessary.
From: "Keith M. Lucas" <sillywiz#excession,demon.co.uk>
Subject: Re: ExAI security issues
Date: Fri, 20 Dec 1996 10:54:48 GMT
In article <32B996BE.446B#mitre,org>, Carl D. Burke <cburke#mitre,org> wrote:
>Benton Jackson wrote:
>>
>> There's been some talk on this thread about using a .dll to implement
>> the plug-in ExAI. How do we address the security and/or reliability of
>> these .dll's? Some hacker could put in a "weapon" type that when a
>> particular monster shoots you with it, it nukes your hard drive.
>> Or, it could just be poorly written, and it crashes your game
>> making you look bad.
>
>Hmmm... I really need to go back and read this thread, but it sounds
>like what you need is something like the Java Virtual Machine to
>run the AIs. The security manager in the JVM can prevent things like
>access to local files, etc. The standard security manager class
>might not give you what you need, but you may be able to inherit
>from it and define a security policy that meets the needs of the game.
My AI system runs under a limited VM. Mainly because I have the
screaming heebie-jeebies about linking "real" code into anything
running on my system without giving it a once over.( The hard drives
Linux talks too aren't even in the BIOS table, just so DOS programs
can't nuke them !! ) It is very oriented to the game -- don't expect
to be able to find prime numbers with it when it appears !! ( or most
of the other useful things you can do with an AI. Now shooting at
other AI things..)
From: "Benton Jackson" <benton#bitstream,net>
Subject: Re: ExAI security issues
Date: 20 Dec 1996 14:13:03 GMT
It's hard to limit the damage an ExAI can do without also limiting
its power in some way. For example, suppose you wanted to build an
AI that needed some data files, it would certainly need to read those.
If it is a learning AI, then it is going to need to write files also!
Plenty of damage can be done with reading and writing files.
--
_ _ ___ _
|_) |_ |\ | | / \ |\ | Benton Jackson, Goat Rider
|_) |_ | \| | \_/ | \| Fenris Wolf Electronic Games
benton#fenriswolf,com <A HREF="http://www2.bitstream.net/~benton">http://www2.bitstream.net/~benton</A>
From: "Benton Jackson" <benton#bitstream,net>
Subject: Re: ExAI security issues
Date: 20 Dec 1996 14:20:03 GMT
Steven Woodcock <Swoodcoc#cris,com>:
> Excellent point. You're really trusting that the anonymous
> hacker developer out there who built the new "Ghandi AI" is a nice guy
> and not somebody who's out to nuke your system.
"Ghandi AI"- I love it! "We are just a peaceful AI,
you can trust us."
> One *possible* solution to this is to only allow "certified" AIs
> to run with the game in question. Problem is, that means that the
> programmer
> has to send the AI module to the company who built the game, and they
> have to look at it and give it some kind of certification. Not only is
> that cumbersome, slow, and costly (to the original developer), but it
> reveals all of the hacker's secrets AND makes the certifier liable if
> in fact they missed something.
Yes, of course this would suck.
> On the third hand (this is getting fun), is it really a much different
> situation than what you have with shareware and freeware now? I mean,
> you
> see some nifty utility online and download it without much more than a
> virus check; I'd wager the risk here is about the same. If a "bad AI"
> does crop it, word can be spread quickly through newsgroups and web
> pages.
This is probably the best we are going to do.
But wait- How about a combination of the two? Allow free AI modules
to circulate, but the developer also keeps an eye on them and collects
the best, looks over them, and approves the safe ones on their own
web site. Those who don't like the idea of using bath house software
can be assured of safety.
- Ben
From: droleary#alpha,temporal.org (Doc O'Leary)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 20 Dec 1996 14:30:23 GMT
On Thu, 19 Dec 1996 14:35:10 GMT, Eric Dybsand <edybs#ix,netcom.com> wrote:
>Is anyone interested, in discussing this, without regard to if it could
>be actually delivered in a commercial product?
I will argue for the same thing I did the last time this discussion went
around. I don't want an AI-specific API, but rather to have the Player
API published. That way the user could not only be allowed to create
an AI to play the game, but they could create their own player view,
including a module that allows networked players. This can all be done
without changing the game engine (model) at all.
Problems exists for games have no clean separation between the model and
the view (unlikely) or where the AI does not take the form of another
player (somewhat more common).
As to the exact implementation, I favor dll's as well. The API could be
made up of functions or perhaps a Player class. I am less inclined to
use a "scripting" approach, as that could be a module of it's own.
--------- Doc
--
Copyright 1996 by Doc O'Leary.
Author of the wildly unsuccessful "DOS and Windows for People Who
Still Have a Clue"
From: "Benton Jackson" <benton#bitstream,net>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 20 Dec 1996 14:38:32 GMT
Eric Dybsand <edybs#ix,netcom.com> wrote in article
<59d3ot$ctc#sjx-ixn5,ix.netcom.com>...
> In article <59cpnj$ag7#herald,concentric.net>,
> Swoodcoc#cris,com (Steven Woodcock) wrote:
>
> >
> >Eric Dybsand (edybs#ix,netcom.com) wrote:
> >:
> >: To me, an ExAI is a set of APIs (application program interface)
> >: or function calls, that can be accessed from a sub-module, such as a .dll
> >: (data link > >: library as in Windows). These functions would allow an
> >: outside entity to cause changes in computer opponent behavior, within
> >: the context of the game.
> >
> > This is a good definition. A DLL is the most natural way (I feel) to
> >do this on a Windows platform, though I wouldn't necessarily want to leave
> >out the folks trying their hand with the new Playstation Yarouze systems
> >(a homebrew developer's kit for building PSX games).
> >
> > Any such API (let me take a look at my design document) needs to have
> >functions which broadly provide the following:
> >
> > -- status (position, strength, condition) of all units, probably
> > broken out by "team" or "side" or whatever as desired;
> > -- a pathing function of some kind so the homebrew AI can
> > determine how to get from A to B;
> > -- a terrain type report for each hex/location/whatever;
> > -- some functions that define the SCALES used in the game
> > for damage, movement, etc. (what good does it do to know
> > that Unit A has 10 hit points when you don't know if the
> > upper limit is 11 or 1100?);
> > -- functions for issuing orders to the units within the game
> > (move, attack, build, collect resources, etc.).
> Perhaps a "communication with other players facility" might be handy too?
This talks about the facilities available to the .dll. You also have
to have a standard set of entry points for the .dll, so
that the game knows when to use it. Perhaps a set of notification
events that the .dll can hook out? Such as:
- create
- deletion (or maybe begin death scene?)
- graphics frame tick
- simulation frame tick
- see new enemy/ally/object
- getting hit
- end of path reached
- receive command message from another entity
On another vein, has anybody thought of using a Java interpreter for this?
I don't know Java, but would it be an appropriate language for programming
an AI? How portable would a Java core be? Could we include it in a game
at a reasonable price? Have a game with Java scripting would certainly
be "buzzword compliant"! I like the idea of .dll's better, since you can
use any convenient language, but let's explore all options.
benton#fenriswolf,com <A HREF="http://www2.bitstream.net/~benton">http://www2.bitstream.net/~benton</A>
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Fri, 20 Dec 1996 15:14:10 GMT
In article <59d6jb$usp$1#nargun,cc.uq.oz.au>,
ccamuys#student,uq.edu.au (Andrae Muys) wrote:
>There is another method that I haven't seen discussed yet. Coming from a
>UNIX background myself, for me a natural interface would be some form of
>IPC. The AI would run as a seperate process, and ExAI would be
>implemented as a combination of IPC's. A combination of sockets (for
>networked support), pipes, fifos, messages, and shared memory spaces would
>probably work well. Then the new AI is simply compiled as an executable,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>linked to a library(supplied) that handles all the IPC stuff, and ExAI
>becomes as simple as passing the name of the AI executable to the Game as
>a command line parameter(you could easily wrap a GUI config around this).
>
Hi Andrae,
Since its been awhile (over 10 years) since I've done any UNIX coding,
I'm a little rusty on inter-program communication (IPC) issues. Are
you suggesting that the ExAI (developed by an outsider) is compiled
and linked into the actual game?
If this is the case, then I'm at a loss as to how the customers playing
the game, and using a new "Evil Elmo" ExAI they just downloaded from
the net, would be able to compile and link the ExAI into the game.
Can you please elaborate?
>
>: -- a pathing function of some kind so the homebrew AI can
>: determine how to get from A to B;
>
>You might also want to provide a hook so that the user can add their own
>pathing function.
>
>: -- a terrain type report for each hex/location/whatever;
>
>Yes, in fact if this is done well then you have provided a hook for the
>user to add their own pathing function.
>
Good idea to provide a hook for an ExAI based pathing function.
Eric
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: ExAI security issues
Date: 20 Dec 1996 16:46:04 GMT
Benton Jackson (benton#bitstream,net) wrote:
: Steven Woodcock <Swoodcoc#cris,com>:
: > Excellent point. You're really trusting that the anonymous
: > hacker developer out there who built the new "Ghandi AI" is a nice guy
: > and not somebody who's out to nuke your system.
:
: "Ghandi AI"- I love it! "We are just a peaceful AI,
: you can trust us."
Heh. Yeah, the more I thought about that one the more I liked it. I
can see it now....a "passive resistance" AI that turns off your mouse cursor
so you can't hurt him..... ;)
: But wait- How about a combination of the two? Allow free AI modules
: to circulate, but the developer also keeps an eye on them and collects
: the best, looks over them, and approves the safe ones on their own
: web site. Those who don't like the idea of using bath house software
: can be assured of safety.
I like that. Put a big disclaimer up on the developer's web page and
in the AI DLL interface that says, "You're using a non-certified AI; it's
not our fault if your system gets erased" and leave it at that.
Steve
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 20 Dec 1996 16:49:43 GMT
Benton Jackson (benton#bitstream,net) wrote:
:
: On another vein, has anybody thought of using a Java interpreter for this?
: I don't know Java, but would it be an appropriate language for programming
: an AI? How portable would a Java core be? Could we include it in a game
: at a reasonable price? Have a game with Java scripting would certainly
: be "buzzword compliant"! I like the idea of .dll's better, since you can
: use any convenient language, but let's explore all options.
Benton has a good point here. Java might be a good way to go with this
thing. I don't know Java myself (need to find the time to learn), but it
is a heck of a buzzword, is theoretically cross-platform portable, and has
a number of available development tools lying around.
I've seen some flocking demos and NNs done in Java, so it's certainly up
to the task per se. I'm not sure about execution speed though.
Steve
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Re: ExAI security issues
Date: Fri, 20 Dec 1996 17:33:33 GMT
In article <01bbee7e$eba6fca0$75ed90ce@blueheron>,
"Benton Jackson" <benton#bitstream,net> wrote:
>It's hard to limit the damage an ExAI can do without also limiting
>its power in some way. For example, suppose you wanted to build an
>AI that needed some data files, it would certainly need to read those.
>If it is a learning AI, then it is going to need to write files also!
>Plenty of damage can be done with reading and writing files.
>
How about requiring all I/O for the ExAI to go through the API
provided by the game? I'm not sure how one could do this, as from
a .dll I think one could open and write to any file without the
game code knowing it happened.
Eric
From: gminer#Newbridge,COM (Glen Miner)
Subject: Re: ExAI security issues
Date: 20 Dec 1996 18:08:48 GMT
>: There's been some talk on this thread about using a .dll to implement
>: the plug-in ExAI. How do we address the security and/or reliability of
>: these .dll's?
> Excellent point. You're really trusting that the anonymous
>hacker developer out there who built the new "Ghandi AI" is a nice guy
>and not somebody who's out to nuke your system.
I am currently designing a byte-code and virtual machine package that
would solve many of the problems presented by DLLs. Since it would be
inherintly less effecient, I'm making every effort to design it with
optimization in mind. Since all environment interaction would be done
through virtual machine system calls, it would be 100% safe. The worst
thing an AI Agent could do would be get caught in an endless loop.
I would _really_ be interested in any comments or suggestions (via the
group). I'm being meticulas in my planning to avoid any kludgy fixes later
on (I've had enough experience with intel asm to know what can happen when
you don't think far enough ahead ).
Peace
--
===[ Gabo / [ABC] : gaminer#undergrad,math.uwaterloo.ca ]===================
Latest ABC Shogi: <A HREF="http://www.undergrad.math.uwaterloo.ca/~gaminer/shogi.html">http://www.undergrad.math.uwaterloo.ca/~gaminer/shogi.html</A>
"What Greenpeace spends in a year General Motors spends in four hours" -Moby
From: Scott R Lenser
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Fri, 20 Dec 1996 20:10:55 -0600 (CST)
In comp.ai.games you write:
>Benton Jackson (benton#bitstream,net) wrote:
>:
>: On another vein, has anybody thought of using a Java interpreter for this?
>: I don't know Java, but would it be an appropriate language for programming
>: an AI? How portable would a Java core be? Could we include it in a game
>: at a reasonable price? Have a game with Java scripting would certainly
>: be "buzzword compliant"! I like the idea of .dll's better, since you can
>: use any convenient language, but let's explore all options.
> Benton has a good point here. Java might be a good way to go with this
>thing. I don't know Java myself (need to find the time to learn), but it
>is a heck of a buzzword, is theoretically cross-platform portable, and has
>a number of available development tools lying around.
> I've seen some flocking demos and NNs done in Java, so it's certainly up
>to the task per se. I'm not sure about execution speed though.
>Steve
I'm not sure about the interfacing issue, although I think it can be done. Java
is a nice language and does support both the cross-platform portability and
security. I wouldn't exactly characterize Java as having a lot of good
development tools yet, but it is getting there. Parts of the Java language are
still a little buggy or unfinished, but this mostly has to do with the
GUI which would not be needed for this application.
There are too basic types of Java programs, applets and apllications. As far
as I know applets can only be run through a web browser or Sun's applet viewer.
Running Java applications removes the security restrictions and requires that
a Java virutal machine be installed on the machine.
The Java language is certainly expressively powerful enough and a lot of nice
utility classes are beginning to appear. As for speed, Java currently runs
about 10 times slower than native code. This is _supposed_ to change in the
near future as just in time compilers come out that will compile the code when
it is loaded/needed. This is supposed to bring Java within 1-2x the speed of
comparable C code. I've heard that just in time compilers are out for some
systems but I don't know which ones.
As for price, I'm not familiar with all of the restrictions Sun has placed on
Java but I wouldn't be surprised if they would want compensation.
From: rpenney#cyberspace,net.au (Russell Penney)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 20 Dec 96 23:07:44 GMT
In article <59d6jb$usp$1#nargun,cc.uq.oz.au>,
ccamuys#student,uq.edu.au (Andrae Muys) wrote:
>Steven Woodcock (Swoodcoc#cris,com) wrote:
>:
>: Eric Dybsand (edybs#ix,netcom.com) wrote:
>: :
>: : FORM
>: :
>: : I would begin with a definition of what form the ExAI takes.
>: :
>: : To me, an ExAI is a set of APIs (application program interface) or
>: :function
>: : calls, that can be accessed from a sub-module, such as a .dll (data link
>: : library as in Windows). These functions would allow an outside entity to
>: : cause changes in computer opponent behavior, within the context of the
>: :game.
>:
>There is another method that I haven't seen discussed yet. Coming from a
>UNIX background myself, for me a natural interface would be some form of
>IPC. The AI would run as a seperate process, and ExAI would be
>implemented as a combination of IPC's. A combination of sockets (for
>networked support), pipes, fifos, messages, and shared memory spaces would
>probably work well. Then the new AI is simply compiled as an executable,
>linked to a library(supplied) that handles all the IPC stuff, and ExAI
>becomes as simple as passing the name of the AI executable to the Game as
>a command line parameter(you could easily wrap a GUI config around this).
>
<< Interesting bits chopped out >>
Can I suggest you don't try and even think about the interface method just
yet. I have seen too many discussions evolve into UNIX vs Windows vs product
XYZ arguments. If we work on a standard API, it should fit into any interface
method ( RPC anyone? ).
Russell
From: Scott R Lenser <s-lenser#coewl,cen.uiuc.edu>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
On Fri, 20 Dec 1996 Swoodcoc#cris,com wrote:
> Scott:
>
>
> Thanks for the email! In case you didn't post it to the newsgroup too, I
> hope you don't mind my adding it to the archive of this thread?
>
Thanks.
> >
> > There are too basic types of Java programs, applets and apllications.
> > As far as I know applets can only be run through a web browser or Sun's
> > applet viewer. Running Java applications removes the security restrictions
> > and requires that a Java virutal machine be installed on the machine.
>
> As I understand it (reading the latest magazines), there are some problems
> with the various versions of the JVMs being 100% compatible with each other.
> It appears to be mostly a Microsoft vs. Netscape/Sun issue, from what I
> read, and one presumes it will get sorted out eventually.
>
Most of these have to do with the GUI though which shouldn't be a problem here
since the interface will almost certainly need to be written in native code.
> > The Java language is certainly expressively powerful enough and a lot of
> > nice utility classes are beginning to appear. As for speed, Java currently
> > runs about 10 times slower than native code. This is _supposed_ to
> > change in the near future as just in time compilers come out that will
> > compile the code when it is loaded/needed. This is supposed to bring
> > Java within 1-2x the speed of comparable C code. I've heard that just
> > in time compilers are out for some systems but I don't know which ones.
>
> That still may not be fast enough, except maybe for a turn based game.
> I don't know if you're a game developer or not, but CPU cycles are the
> single most precious resource on a game system. If I can make a pathing
> algorithm 10% faster, it's worth doing even if it does mean another 2 weeks
> of debugging.
>
I realize how precious cycles are for games (One of my friends is a games
programmer). I was under the general impression that the AI did not consume
the majority of cycles used by the game, but that the graphics did. If this
is not the case then even the relatively modest speed degradation is a
significant problem. I doubt Java will ever be quite as fast as C/C++ since
function calls in Java have the address of the called function computed at
runtime to allow for dynamic binding of modules. I suppose this might be
avoided by a just in time compiler if it already had the required function
but it would have to be quite intelligent to decide when this would be
possible without introducing any errors.
> On the other hand, the cross-platform portability of Java is a powerful
> sales and development incentive. And, if the just-in-time compilers perform
> as advertised, I think there are real possibilities here.
I agree, the possibilities are very promising. Java is the best language I
have seen to date (C/C++ included) in terms of ease of programming and
cleanliness. Unfortunately, its implementation is still not as good as C/C++.
###############################################################################
"To thine own self be true" -Shakespeare |Scott Lenser
"I em what I em, and thats alls that I em" -Popeye|e-mail: s-lenser#uiuc,edu
From: s-lenser#coewl,cen.uiuc.edu (Scott R Lenser)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 21 Dec 1996 01:57:58 GMT
Organization: University of Illinois at Urbana
Mike White <mykey#geocities,com> writes:
>Andrae Muys wrote:
>[Snip]
>> Well so far we have .DLL, IPC, and scripting. I would be interested to
>> hear if anyone else has thought of any other methods of implementing ExAI.
>>
>My $0.02,
>.DLL: Dangerous....(Mentioned previously)
> IPC: No Comment (I skimmed over that)
> Script: Slow...
Hey, I just thought of this. How about the devlopers set up a web or telnet
site that you send your scripted code to. It then takes your scripted code,
compiles it, and returns the resulting DLL back to you to plug into the game.
By defining the scripting language used (or perhaps just C/C++ code with
system function calls disallowed) you could carefully control what access the
AI has to the host machine as bad code can simply be rejected. To ensure that
all DLLs used by the program go through this process, the conversion routine
would have to sign the DLL as valid. A reasonable language might use C++
syntax but disallow any system calls while allowing the AI to call any of the
API functions. I would suggest an API to write and read a file to/from disk,
but only in a directory dedicated to the AI's data files. This could at least
stop someone from deleting an entire harddrive. This would also take care of
the speed problem with scripts. The disadvantage is that someone has to write
the code to convert the script to actual executable and the additonal hardware
resources needed by the company to support this. Another advantage would be
that someone could write the script file without needing to have a compiler
available.
>An Idea..
>What about a language like Java, your EXE interprets the "machine code"
>and doesn't allow access to anything outside of the game. It adds another
>layer that probably make it unacceptable, but something along these lines.
This would be slow and would require a major effort to implement the
interpreter unless the java interpreter could somehow be used.
>I personally like the DLL.... Risks and all...
It's certainly not bad.
From: sshah#intranet,ca
Subject: Re: War Craft II
Date: 21 Dec 1996 05:39:30 GMT
To: Ccamuys#dingo,cc.uq.oz.au
Subject: Re: War Craft II
This entire debate about AI plug ins is fascinating but I'm just going to
make one comment. Abuse has a LISP parser that allows you to rewrite the
ant AI, the levels, the physics, etc. NTM, Quake, wh/ I already have. I
haven't played Quake yet though.
And then there's OpenCiv.
And then there's MUDs . . .
And then there's RARS . . .
And then there's Bolo . . .
And then there's Omega . . .
And then there's . . .
Ad infinitum. Just go out and look.
And, hey, if someone wants to do my homework for me, I'll finish WASTE for
you. :)
-----------------------------------------------------------------------
Sunir Shah WWW: <A HREF="http://intranet.ca/~sshah/">http://intranet.ca/~sshah/</A>
WASTE (AI Contest): /waste/waste.html comp.ai.games FAQ: /cagfaq.html
Programmers' Booklist: /booklist.html Synapsis: /synapsis.html
-"It's not a mistake./This is my haircut." _This is my Haircut_, 54-40-
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 21 Dec 1996 05:57:10 GMT
Hello All:
I'm posting this for Scott Lenser, who emailed it to me and then
asked for it to be posted. He provides some interesting insight on
the use of Java for an extensible game AI.
=======================================================================
From: Scott R Lenser <s-lenser#coewl,cen.uiuc.edu>
Date: Fri, 20 Dec 1996 20:10:55 -0600 (CST)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
In comp.ai.games you write:
>Benton Jackson (benton#bitstream,net) wrote:
>:
>: On another vein, has anybody thought of using a Java interpreter for this?
>: I don't know Java, but would it be an appropriate language for programming
>: an AI? How portable would a Java core be? Could we include it in a game
>: at a reasonable price? Have a game with Java scripting would certainly
>: be "buzzword compliant"! I like the idea of .dll's better, since you can
>: use any convenient language, but let's explore all options.
> Benton has a good point here. Java might be a good way to go with this
>thing. I don't know Java myself (need to find the time to learn), but it
>is a heck of a buzzword, is theoretically cross-platform portable, and has
>a number of available development tools lying around.
> I've seen some flocking demos and NNs done in Java, so it's certainly up
>to the task per se. I'm not sure about execution speed though.
>Steve
I'm not sure about the interfacing issue, although I think it can be done. Java
is a nice language and does support both the cross-platform portability and
security. I wouldn't exactly characterize Java as having a lot of good
development tools yet, but it is getting there. Parts of the Java language are
still a little buggy or unfinished, but this mostly has to do with the
GUI which would not be needed for this application.
There are too basic types of Java programs, applets and apllications. As far
as I know applets can only be run through a web browser or Sun's applet viewer.
Running Java applications removes the security restrictions and requires that
a Java virutal machine be installed on the machine.
The Java language is certainly expressively powerful enough and a lot of nice
utility classes are beginning to appear. As for speed, Java currently runs
about 10 times slower than native code. This is _supposed_ to change in the
near future as just in time compilers come out that will compile the code when
it is loaded/needed. This is supposed to bring Java within 1-2x the speed of
comparable C code. I've heard that just in time compilers are out for some
systems but I don't know which ones.
As for price, I'm not familiar with all of the restrictions Sun has placed on
Java but I wouldn't be surprised if they would want compensation.
From: sshah#intranet,ca
Subject: Re: ExAI security issues
Date: 21 Dec 1996 07:29:16 GMT
To: Gminer#newbridge,com
Subject: Re: ExAI security issues
Gm> The worst thing an AI Agent could do would be get caught in an endless
Gm> loop.
Which is also fixable by say, causing its health to go down unless it eats or
by having a watchdog sniff out extremely comatose agents.
From: Darrin Robert O'leary <olearydr#freenet,msp.mn.us>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Sat, 21 Dec 1996 08:14:58 -0600
On Fri, 20 Dec 1996, Eric Dybsand wrote:
> Since its been awhile (over 10 years) since I've done any UNIX coding,
> I'm a little rusty on inter-program communication (IPC) issues. Are
> you suggesting that the ExAI (developed by an outsider) is compiled
> and linked into the actual game?
IPC is more correct inter-process communication, so the suggestion amounts to
having the AI run as its own client program and communicate with the
server-type game engine. It's of questionable value because, as I said in a
previous post, networking can be added with a player dll.
--------- Doc
From: Mike White <mykey#geocities,com>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Sat, 21 Dec 1996 13:50:03 -0800
If the Remote compiler returns a valid .DLL with some kind of Check
system and the game program accepts it and runs the code, then you
still have the .DLL problem.
Whatever the Remote compiler can generate, a hacker can also generate
and add thier evil code to it.
This is actually even a worse condition since the Remote approach
implies the .DLLs are safe..
If the Remote Compiler can't really help protect your system, then it
is a complete waste of time.
The only 100% safe method would be to interpret psuedo Op-codes.
As for the possible Endless loop, the interpreter could allow a maximum
of number of operations per turn. If the routine "times out", then AI
is assumed to be saying "continue with your last instructions".
(In warcraft... Keep chopping that wood etc..)
Mike
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Sat, 21 Dec 1996 15:19:35 GMT
In article <59fg76$p08#vixen,cso.uiuc.edu>,
s-lenser#coewl,cen.uiuc.edu (Scott R Lenser) wrote:
>
>Hey, I just thought of this. How about the devlopers set up a web or telnet
>site that you send your scripted code to. It then takes your scripted code,
>compiles it, and returns the resulting DLL back to you to plug into the game.
>By defining the scripting language used (or perhaps just C/C++ code with
>system function calls disallowed) you could carefully control what access the
>AI has to the host machine as bad code can simply be rejected. To ensure that
>all DLLs used by the program go through this process, the conversion routine
>would have to sign the DLL as valid. A reasonable language might use C++
>syntax but disallow any system calls while allowing the AI to call any
>of the API functions. I would suggest an API to write and read a file
>to/from disk, but only in a directory dedicated to the AI's data files.
>This could at least stop someone from deleting an entire harddrive. This
>would also take care of the speed problem with scripts. The disadvantage
>is that someone has to write the code to convert the script to actual
>executable and the additonal hardware resources needed by the company
>to support this. Another advantage would be that someone could write
>the script file without needing to have a compiler available.
>
It would appear, that for the "script" approach to work, that the game
developer would have to develop a script compiler, which would accept
the script "code" and then produce an ExAI .dll as output.
IMO, that sure seems like a whole lot of extra work, added
to the development of the game.
This script compiler _would_ solve several of the problems pointed out already
with the ExAI, such that security issues would be minimized as the compiler
would provide the additional layer which could filter out harmful operations
that were within the script itself. Also, the slow speed of the script method
would be overcome with the production of the .dll and this could also offer a
means for the ExAI Outside Developer to test the script, by using the script
compiler during their own script developement. Once the .dll has been produced,
then any customer playing the game could grab it, load it and use it.
However, I still see file I/O as a problem using this approach. Dose anyone
else see that too?
Also, as a game developer, I would not want to deal with 10s or 100s of ExAI
scripts sent to my web site, that I (or someone I have to pay) would have to
debug and compile to return .dlls to the ExAI Outside Developers. I would much
rather put out the script compiler to the ExAI Outside Developers, and let them
debug and compile their own scripts, themselves.
Eric
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: War Craft II
Date: 21 Dec 1996 21:13:22 GMT
sshah#intranet,ca wrote:
: To: Ccamuys#dingo,cc.uq.oz.au
: Subject: Re: War Craft II
:
: This entire debate about AI plug ins is fascinating but I'm just going to
: make one comment. Abuse has a LISP parser that allows you to rewrite the
: ant AI, the levels, the physics, etc. NTM, Quake, wh/ I already have. I
: haven't played Quake yet though.
:
(Sunir's list of games with "roll your own" AI deleted)
This seems a good place to point out that I've now got a page up on
the Game AI web pages (address below) that tracks games that allow some
form of extensibility and/or programmability. Drop by and tell me what
I've missed (though I am more interested in commercial games, since
that's what we're debating here).
:
: And then there's Omega . . .
:
There's one I need to add....
Steve
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 21 Dec 1996 21:21:32 GMT
Eric Dybsand (edybs#ix,netcom.com) wrote:
: IMO, that sure seems like a whole lot of extra work, added
: to the development of the game.
Agreed. I don't think I'd ever get a manager to sign off on that.
: This script compiler _would_ solve several of the problems pointed out already
: with the ExAI, such that security issues would be minimized as the compiler
: would provide the additional layer which could filter out harmful operations
: that were within the script itself. Also, the slow speed of the script method
: would be overcome with the production of the .dll and this could also offer a
: means for the ExAI Outside Developer to test the script, by using the script
: compiler during their own script developement. Once the .dll has been
: produced, then any customer playing the game could grab it, load it and
: use it.
Yes, there are many advantages to this method, but it's way too expensive
to support (in my opinion). I could maybe see automating the whole process
on a web site...you send it the code and it compiles it and sends it back...
but that's still a lot of work to set up. Not to mention the aggravation
for the guy trying to BUIlD his own AI....he'd write some code, send off
the code to be compiled, and hope and pray he got back an executable.
In that respect it's much like some high schools did in the early 70s,
where their comp sci classes wrote code then shipped it to a local
college (where the computer was) for compilation. Very slow, very
aggravating....I don't think we'd want to do this to the very people we're
trying to get to write AI modules for our game.....
:
: However, I still see file I/O as a problem using this approach. Dose anyone
: else see that too?
Yeah. I'm not sure there's any way around it, actually.
Steve
From: s-lenser#coewl,cen.uiuc.edu (Scott R Lenser)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 21 Dec 1996 20:24:10 GMT
Eric Dybsand <edybs#ix,netcom.com> writes:
>In article <59fg76$p08#vixen,cso.uiuc.edu>,
> s-lenser#coewl,cen.uiuc.edu (Scott R Lenser) wrote:
>>
>>Hey, I just thought of this. How about the devlopers set up a web or telnet
>>site that you send your scripted code to. It then takes your scripted code,
>>compiles it, and returns the resulting DLL back to you to plug into the game.
>>By defining the scripting language used (or perhaps just C/C++ code with
>>system function calls disallowed) you could carefully control what access the
>>AI has to the host machine as bad code can simply be rejected. To ensure that
>>all DLLs used by the program go through this process, the conversion routine
>>would have to sign the DLL as valid. A reasonable language might use C++
>>syntax but disallow any system calls while allowing the AI to call any
>>of the API functions. I would suggest an API to write and read a file
>>to/from disk, but only in a directory dedicated to the AI's data files.
>>This could at least stop someone from deleting an entire harddrive. This
>>would also take care of the speed problem with scripts. The disadvantage
>>is that someone has to write the code to convert the script to actual
>>executable and the additonal hardware resources needed by the company
>>to support this. Another advantage would be that someone could write the
>>script file without needing to have a compiler available.
>>
>It would appear, that for the "script" approach to work, that the game
>developer would have to develop a script compiler, which would accept
>the script "code" and then produce an ExAI .dll as output.
>IMO, that sure seems like a whole lot of extra work, added
>to the development of the game.
I don't think I made myself very clear. What I actually add in mind was to make
the script so C++ like that the script compiler mostly just copies the code
verbatim filtering out evil things in the code. If this is done it shouldn't be
that much more work since mostly the script just filters.
>This script compiler _would_ solve several of the problems pointed out already
>with the ExAI, such that security issues would be minimized as the compiler
>would provide the additional layer which could filter out harmful operations
>that were within the script itself. Also, the slow speed of the script method
>would be overcome with the production of the .dll and this could also offer a
>means for the ExAI Outside Developer to test the script, by using the script
>compiler during their own script developement. Once the .dll has been
>produced, then any customer playing the game could grab it, load it and use it.
>
>However, I still see file I/O as a problem using this approach. Dose anyone
>else see that too?
File I/O can be done through an API call that given say a filename and memory
area to write to disk writes the file for you. Of course, these reads/writes
need to be checked by the API functions to make sure they are in directories
the AI should have access to. This solution to file I/O will work with any
system which can implement security measures on the AI.
>Also, as a game developer, I would not want to deal with 10s or 100s of ExAI
>scripts sent to my web site, that I (or someone I have to pay) would have to
>debug and compile to return .dlls to the ExAI Outside Developers. I would
>much rather put out the script compiler to the ExAI Outside Developers, and
>let them debug and compile their own scripts, themselves.
I meant that the site returns either the DLL if it compiles OK, or a list of the
errors if their are problems. The result is then returned directly back to the
person who submitted it or posted for all to have access to. The process could
be completely automated but would admittedly still require extra hardware
resources. If you release the script compiler, there is no way to ensure that
someone won't modify the script compiler to allow through nasty code. By
having the only script compiler that produces the correct signature, it makes
sure that you at least get to look at the persons code before it is compiled.
Scott
From: "Keith M. Lucas" <sillywiz#excession,demon.co.uk>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Sat, 21 Dec 1996 20:24:25 GMT
In article <01bbee81$f6db9c40$75ed90ce@blueheron>,
Benton Jackson <benton#bitstream,net> wrote:
>
>- create
>- deletion (or maybe begin death scene?)
>- graphics frame tick
Why ?
Decouple the rendering from the game as far as possible I say !
>- simulation frame tick
>- see new enemy/ally/object
>- getting hit
>- end of path reached
>- receive command message from another entity
>
>On another vein, has anybody thought of using a Java interpreter for this?
>I don't know Java, but would it be an appropriate language for programming
>an AI? How portable would a Java core be? Could we include it in a game
>at a reasonable price? Have a game with Java scripting would certainly
>be "buzzword compliant"! I like the idea of .dll's better, since you can
>use any convenient language, but let's explore all options.
If you use DLLs you limit the target to PCs. Bear in mind many of the
AI programmers you want to attract are using UNIX workstations. A VM
like Java is IMNSHO a much better solution.
From: ccamuys#student,uq.edu.au (Andrae Muys)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 23 Dec 1996 02:27:41 GMT
Eric Dybsand (edybs#ix,netcom.com) wrote:
: In article <59d6jb$usp$1#nargun,cc.uq.oz.au>,
: ccamuys#student,uq.edu.au (Andrae Muys) wrote:
:
: >There is another method that I haven't seen discussed yet. Coming from a
: >UNIX background myself, for me a natural interface would be some form of
: >IPC. The AI would run as a seperate process, and ExAI would be
: >implemented as a combination of IPC's. A combination of sockets (for
: >networked support), pipes, fifos, messages, and shared memory spaces would
: >probably work well. Then the new AI is simply compiled as an executable,
: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: >linked to a library(supplied) that handles all the IPC stuff, and ExAI
: >becomes as simple as passing the name of the AI executable to the Game as
: >a command line parameter(you could easily wrap a GUI config around this).
: >
:
: Hi Andrae,
:
: Since its been awhile (over 10 years) since I've done any UNIX coding,
: I'm a little rusty on inter-program communication (IPC) issues. Are
: you suggesting that the ExAI (developed by an outsider) is compiled
: and linked into the actual game?
:
: If this is the case, then I'm at a loss as to how the customers playing
: the game, and using a new "Evil Elmo" ExAI they just downloaded from
: the net, would be able to compile and link the ExAI into the game.
:
: Can you please elaborate?
:
Sure, while I refuse to be drawn into an OS debate, I am forced to refer
directly to UNIX system calls and architecture, as that is all I am
familar with in this area.
IPC :- Inter-Process Communication. There are a number of different
forms of IPC avaliable. (I hope I don't forget any :)
Signals : Sort of like software interrupts, managed by the Kernel.
Pipes : Two process' share a pipe. They see it as a file. What one
writes to the pipe, the other reads. (common ancestry required).
FIFO's : Also called 'named pipes'. Act like a pipe only a link to them
is created in the file-system. So unrelated process' can use it
to communicate.
Message Queues : Allow you to send messages, including blocks of data to
process'. (I don't know much about them, never needed them.)
Semaphores : Used for syncronisation and mutural exclusion. If you don't
know what they are find a book on con-current programming.
Shared-Memory : Allow multiple process' to access the same memory. By far
the fastest IPC. However you need to ensure mutural exclusion
around any access of the variables.
There are more, including Stream Pipes, Record Locking, however I am
unfamiliar with them.
As these are for communication between process' (a process is an executing
program). The ExAI would be compiled, linked with a library, and made
avaliable as an executable. The important thing here is that the ExAI
isn't actually linked to the game. Rather it is linked to a library of
functions which know how to use IPC to communicate with the game. From
the programmer's point of view he is just using functions that return
information, or effect actions in the game. From the users point of view
they simply copy the file into a directory, and tell the game (dialog
box/command line/whatever) which AI to use (by naming the file). This
would of course default to a 'medium' AI installed with the game. For a
game on a unix system I would definately use IPC, as it would solve almost
all of the security problems (it would run setuid nobody), the
communication could be made fast enough and the programmer could use
almost any language they liked. I don't however know enough about
W95/MacOS/W3.11/NT to know if you can do it this way under these systems
(although I am given to understand NT can). My gut feeling is that for
the other systems you simply don't have the infrastructure necessary to
ensure security.
Andrae Muys.
P.S.
As IPC is not directly related to AI, if you want to discuss IPC with
me please e-mail me. Of course discussions on how to use IPC to implement
ExAI should stay posts to this group.
From: ccamuys#student,uq.edu.au (Andrae Muys)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 23 Dec 1996 02:36:21 GMT
Russell Penney (rpenney#cyberspace,net.au) wrote:
: In article <59d6jb$usp$1#nargun,cc.uq.oz.au>,
: << Interesting bits chopped out >>
:
: Can I suggest you don't try and even think about the interface method just
: yet. I have seen too many discussions evolve into UNIX vs Windows vs product
: XYZ arguments. If we work on a standard API, it should fit into any interface
: method ( RPC anyone? ).
:
I am afraid I must disagree here. While discussions on OS's must NOT be
allowed to enter this group. A major part of the usability of ExAI will
depend on the interface method. The interface method can affect what we
can provide the user. A script will have difficulty in accessing the map
directly. (not impossible, just difficult). A .DLL restricts ExAI
development to those who have access to compilers for that platform. Each
has it's advantages and disadvantages. While we should be investigating
options for the API, we must also brainstorm various interface methods.
So far we have seen,
.DLL
IPC
Script
Compiled Script
Java
(I think this is all).
Andrae Muys.
From: seth#siesta,cs.wustl.edu (Seth Golub)
Subject: Re: War Craft II
Date: 23 Dec 1996 14:15:37 -0800
In article <E2ME7F.Gn#excession,demon.co.uk>,
Keith M. Lucas <sillywiz#excession,demon.co.uk> wrote:
> The AI code seems very deeply embedded in the game, it accesses data
> that it should not in order to win.
The AI subsystem may be too tightly coupled with the rest of the
system, but the fact that it accesses data and uses abilities not
available to players is poor evidence. There could, and should, I
think, be a layer between the world model and the player (human or
computer) that filters things like views and command orders.
Seth Golub --- seth#cs,wustl.edu --- <A HREF="http://www.cs.wustl.edu/~seth/">http://www.cs.wustl.edu/~seth/</A>
From: "Keith M. Lucas" <sillywiz#excession,demon.co.uk>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Sat, 21 Dec 1996 21:00:24 GMT
In article <32BA4A2B.254E#geocities,com>,
Mike White <mykey#geocities,com> wrote:
>Andrae Muys wrote:
>[Snip]
>> Well so far we have .DLL, IPC, and scripting. I would be interested to
>> hear if anyone else has thought of any other methods of implementing ExAI.
>>
>> Andrae Muys.
>
>My $0.02,
>
>.DLL: Dangerous....(Mentioned previously)
> IPC: No Comment (I skimmed over that)
> Script: Slow...
>
>An Idea..
>
>What about a language like Java, your EXE interprets the "machine code"
>and doesn't allow access to anything outside of the game. It adds another
>layer that probably make it unacceptable, but something along these lines.
It's definitely fast enough. I have done experiments with such a
system and it runs acceptable with several hundred units on a 486.
You lose in the "grab an instruction" bit, but you gain in not having
a lot of superflouous code - you don't have to decide what lump of AI
to run next, you have a number telling you.
Draft III of my system had "orders" which were written in machine
language, each instruction of which had microinstructions within it. A
ucode instruction was run every universe tick, and could only do a set
number of things -- in particular its return values were "call me
again", "hop back a u-instruction", "skip next u-instruction", "end
opcode" or "halt cpu" -- which speeds things up a bit.
I abandoned that approach for the current version IV in favour of the
opcodes being more hard-coded. ( And I regretted it at first too ! )
and also fixed length. They are however quite BIG opcodes. 8 bits of
opcode, 2 8bit register numbers, 8 bits of type indicator and a 32 bit
parameter per opcode.
The orders consist of code segments and initialisation data, the code
segments containing the compiled input and 8 IRQ addresses. The 8
interrupts are kicked by:
The normal entry,
being shot at,
unable to reach a destination,
can't follow the unit I'm following anymore,
can't follow my leader anymore,
I'm carrying something no-one wants,
an opcode took longer than I asked for, and
a type mismatch.
Here's some example code for a randomly roaming patroller.
---------------------------------------------------------------
name-hntr ; a symbolic name.
desc-Wander hunting enemies ; a textual name.
type-1 ; I can't remember what this does ATM :-)
code-
_RUNN
_NOSI
wander ; pick random square and go there.
watch ; nearest enemy in R0
null? 0 ; or zero if none seen
jumpyes $RUNN
_SHOT
attack 0 ; attack unit in R0
jump $SHOT
---------------------------------------------------------------
{ The last segment looks like an infinite loop, but the attack on the
unit whose ID is in R0 will fail after it is destroyed raising a NOSI
exception -- I can't see that unit and then the code drops into the
wander loop. }
Further work may be slow until mid-January as I have to real jobs. One
of my customers is getting huffy. I dunno, anyone would think they had
a country to practice invading or something...
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Sat, 21 Dec 1996 22:30:37 GMT
In article <59hh1a$1st#vixen,cso.uiuc.edu>,
s-lenser#coewl,cen.uiuc.edu (Scott R Lenser) wrote:
[Scott's "send in the C++ like script to developer" snipped]
>Eric Dybsand <edybs#ix,netcom.com> writes:
>
>>It would appear, that for the "script" approach to work, that the game
>>developer would have to develop a script compiler, which would accept
>>the script "code" and then produce an ExAI .dll as output.
>
>>IMO, that sure seems like a whole lot of extra work, added
>>to the development of the game.
>
>I don't think I made myself very clear. What I actually add in mind was to
>make the script so C++ like that the script compiler mostly just copies the
>code verbatim filtering out evil things in the code. If this is done it
>shouldn't be that much more work since mostly the script just filters.
>
I thought that _was_ what you were suggesting. Still, it would require _most_
of a compiler (parsing and content evaluation at the least) to "filter... out
evil things" or the script compiler would not accomplish too much.
>
>>However, I still see file I/O as a problem using this approach. Dose anyone
>>else see that too?
>
>File I/O can be done through an API call that given say a filename and memory
>area to write to disk writes the file for you. Of course, these reads/writes
>need to be checked by the API functions to make sure they are in directories
>the AI should have access to. This solution to file I/O will work with any
>system which can implement security measures on the AI.
>
That is the solution that I come up with too for this. Meaning that all
file I/O from the ExAI script, comes through the game's own code, and is
considered for proper access.
>>Also, as a game developer, I would not want to deal with 10s or 100s of ExAI
>>scripts sent to my web site, that I (or someone I have to pay) would have to
>>debug and compile to return .dlls to the ExAI Outside Developers. I would
>>much rather put out the script compiler to the ExAI Outside Developers, and
>>let them debug and compile their own scripts, themselves.
>
>I meant that the site returns either the DLL if it compiles OK, or a list of
>the errors if their are problems. The result is then returned directly
>back to the person who submitted it or posted for all to have access to.
>The process could be completely automated but would admittedly still require
>extra hardware resources.
Even automated, still means someone sets it up, checks on it, fixes it when it
breaks, updates it, answers questions when someone's submission fails and
changes it when it needs attention. I'm not knocking the idea, I just
wanted to make the point it took some people resources (in _addition_ to the
extra hardware) to do it this way. BTW, would you be volunteering to
run it?
>If you release the script compiler, there is no way to ensure that
>someone won't modify the script compiler to allow through nasty code.
Good point, however if it is .exe code, then that means they hack the object
code and that is the same risk all game developers run whenever they publish
a game (that risk being someone gets a copy of their game .exe and hacks it
to do bad things to customers).
Has anyone heard if the public availability of Quake C (not exactly the same
thing as an ExAI, I think) has created any problems for Id with people trying
(and succeeding) in doing bad stuff (via Quake) to Quake customers?
Regards,
Eric
From: "Benton Jackson" <benton#bitstream,net>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 23 Dec 1996 13:52:15 GMT
Keith M. Lucas <sillywiz#excession,demon.co.uk>:
> Benton Jackson <benton#bitstream,net> wrote:
> >
> >- graphics frame tick
>
> Why ?
>
I don't know why. Perhaps to add a form of animation not anticipated
by the rendering engine? Let's provide as many options as possible.
And maybe its because I've always been a graphics guy :^)
> If you use DLLs you limit the target to PCs. Bear in mind many of the
> AI programmers you want to attract are using UNIX workstations. A VM
> like Java is IMNSHO a much better solution.
".dll" is the term I use because I am working with PC's now. I know the
Amiga has a similar mechanism. Surely all OS's worth their stuff have
this or a similar facility. Of course, since this is a compiled approach,
ExAI's using .dll's will not be as portable, so that is certainly a strike
against it.
Benton
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Mon, 23 Dec 1996 13:54:00 GMT
>In article <01bbee81$f6db9c40$75ed90ce@blueheron>,
>Benton Jackson <benton#bitstream,net> wrote:
>>
>>
>>On another vein, has anybody thought of using a Java interpreter for this?
>>I don't know Java, but would it be an appropriate language for programming
>>an AI? How portable would a Java core be? Could we include it in a game
>>at a reasonable price? Have a game with Java scripting would certainly
>>be "buzzword compliant"! I like the idea of .dll's better, since you can
>>use any convenient language, but let's explore all options.
>
>If you use DLLs you limit the target to PCs. Bear in mind many of the
>AI programmers you want to attract are using UNIX workstations. A VM
>like Java is IMNSHO a much better solution.
>
"Are you sure your feelings on this matter are clear?"
-- Emperor Papaltine to Darth Vader in "Return of the Jedi"
Seriously, I would think that the whole point of spending the extra
development money and time on an ExAI would be to attract more customers,
regardless of the platforms used by ExAI Outside Developers. The majority
of the game buying public does *not* use UNIX workstations, that I know of.
Regards,
Eric
From: seth#siesta,cs.wustl.edu (Seth Golub)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 23 Dec 1996 14:25:43 -0800
In article <slrn5bl8ns.to.droleary#alpha,temporal.org>,
Doc O'Leary <olearydr#freenet,msp.mn.us> wrote:
> Problems exists for games have no clean separation between the model
> and the view (unlikely) or where the AI does not take the form of
> another player (somewhat more common).
I think every game's AI can take the form of a player if you are
willing to have players with different abilities. For example: human
player can only see the map near his units, computer can see
everything, etc. Vary the restrictions to vary the amount of cheating
the AI gets to do.
> The API could be made up of functions or perhaps a Player class. I
> am less inclined to use a "scripting" approach, as that could be a
> module of it's own.
I agree. Supporting scription and defining a set of
actions/commands/functions/methods are two independent issues.
Seth Golub --- seth#cs,wustl.edu --- <A HREF="http://www.cs.wustl.edu/~seth/">http://www.cs.wustl.edu/~seth/</A>
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Mon, 23 Dec 1996 14:32:42 GMT
In article <59kqmt$d4h$1#nargun,cc.uq.oz.au>,
ccamuys#student,uq.edu.au (Andrae Muys) wrote:
>Eric Dybsand (edybs#ix,netcom.com) wrote:
>:
>: Since its been awhile (over 10 years) since I've done any UNIX coding,
>: I'm a little rusty on inter-program communication (IPC) issues. Are
>: you suggesting that the ExAI (developed by an outsider) is compiled
>: and linked into the actual game?
>:
>: If this is the case, then I'm at a loss as to how the customers playing
>: the game, and using a new "Evil Elmo" ExAI they just downloaded from
>: the net, would be able to compile and link the ExAI into the game.
>:
>: Can you please elaborate?
>:
>
>Sure, while I refuse to be drawn into an OS debate, I am forced to refer
>directly to UNIX system calls and architecture, as that is all I am
>familar with in this area.
>
> IPC :- Inter-Process Communication. There are a number of different
>forms of IPC avaliable. (I hope I don't forget any :)
>
>Signals : Sort of like software interrupts, managed by the Kernel.
>Pipes : Two process' share a pipe. They see it as a file. What one
> writes to the pipe, the other reads. (common ancestry required).
>FIFO's : Also called 'named pipes'. Act like a pipe only a link to them
> is created in the file-system. So unrelated process' can use it
> to communicate.
>Message Queues : Allow you to send messages, including blocks of data to
> process'. (I don't know much about them, never needed them.)
>Semaphores : Used for syncronisation and mutural exclusion. If you don't
> know what they are find a book on con-current programming.
>Shared-Memory : Allow multiple process' to access the same memory. By far
> the fastest IPC. However you need to ensure mutural exclusion
> around any access of the variables.
>There are more, including Stream Pipes, Record Locking, however I am
>unfamiliar with them.
>
Ah, now I remember. Thanks for the memory jog.
>As these are for communication between process' (a process is an executing
>program). The ExAI would be compiled, linked with a library, and made
>avaliable as an executable. The important thing here is that the ExAI
>isn't actually linked to the game. Rather it is linked to a library of
>functions which know how to use IPC to communicate with the game. From
>the programmer's point of view he is just using functions that return
>information, or effect actions in the game. From the users point of view
>they simply copy the file into a directory, and tell the game (dialog
>box/command line/whatever) which AI to use (by naming the file). This
>would of course default to a 'medium' AI installed with the game. For a
>game on a unix system I would definately use IPC, as it would solve almost
>all of the security problems (it would run setuid nobody), the
>communication could be made fast enough and the programmer could use
>almost any language they liked. I don't however know enough about
>W95/MacOS/W3.11/NT to know if you can do it this way under these systems
>(although I am given to understand NT can). My gut feeling is that for
>the other systems you simply don't have the infrastructure necessary to
>ensure security.
>
Sounds very doable. FWIW, Win95/Win32s/WinNT support threads, which can
be used to accomplish the same basic process communication function, but
not in exactly the same way as IPC.
> As IPC is not directly related to AI, if you want to discuss IPC with
>me please e-mail me. Of course discussions on how to use IPC to implement
>ExAI should stay posts to this group.
>
Thanks, but there is not really a need to discuss IPC in depth, as your
brief outline above, was more than sufficient to warm up my tired old
neurons to recall the IPC work that I did decades ago. Too many lines of
code (and too many new APIs) have passed since then.
Back to ExAI, it seems that the .dll and IPC approaches, still leave open
the door, for the maleviolent ExAI Outside Developer to do unauthorized
things to the customer's computer. Also, the scripting approach seems to
leave no good way to handle functions like hooking in a "home grown" path
finding algorithm or providing for long term ExAI memory (disk files).
Regards,
Eric
From: gerryq#indigo,ie (Gerry Quinn)
Subject: Re: ExAI security issues
Date: Mon, 23 Dec 96 20:22:09 GMT
In article <01bbee7e$eba6fca0$75ed90ce@blueheron>, "Benton Jackson" <benton#bitstream,net> wrote:
>It's hard to limit the damage an ExAI can do without also limiting
>its power in some way. For example, suppose you wanted to build an
>AI that needed some data files, it would certainly need to read those.
>If it is a learning AI, then it is going to need to write files also!
>Plenty of damage can be done with reading and writing files.
Suppose it can write files, but they have to have a limited range of names.
E.g. they must be called AI44????.AIF. This will allow it to record data with
little risk of harm.
- Gerry
----------------------------------------------------------
gerryq#indigo,ie (Gerry Quinn)
----------------------------------------------------------
From: nctrost#pobox,com (Nate Trost)
Subject: Re: War Craft II
Date: Tue, 24 Dec 1996 18:48:06 +0000
There is one Warcraft-ish game in development that does plan on supporting
a fair bit of customization, including unit behavior. The working name of
the project is "Myth", from Bungie (best known for their Marathon 3D 1st
person series). There is a preview of Myth at their web site:
<A HREF="http://www.bungie.com">http://www.bungie.com</A>
They did quite a good job at making the physics models, etc. in Marathon
editable (with Marathon Infinity they finally shipped an official editor
with the game), so it will be interesting to see how Myth ends up.
--
Nate Trost
nctrost#pobox,com
From: "Benton Jackson" <benton#bitstream,net>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 25 Dec 1996 14:00:17 GMT
Bernd Wolff <bwolff#newswire,de>:
> mykey#geocities,com meinte am 20.12.96
> zum Thema "Re: Extensible Game AI (was Warcraft 2 AI)":
>
> m> .DLL: Dangerous....(Mentioned previously)
> m> IPC: No Comment (I skimmed over that)
> m> Script: Slow...
> m>
> m> An Idea..
> m>
> m> What about a language like Java, your EXE interprets the "machine
> m >code"
>
> This gives the same problem as the Script - it is interpreted, and
> therefore slow. Still, I think that a language which is part of the
> game is a good choice, as it could give better integration with the
> game's features (e.g. limited visibility hence limited knowledge of the
> situation)
I don't think slow is a problem. Compared to the amount of effort that is
expended by the graphics rendering, I think the AI, game play, and even
simulation code should require very little processor time. Using a slow
scripting language should not be a problem. Of course, there may be a few
computationally expensive things, such as path finding and visibility
calculations, that can be provided by the engine, but that is only
natural since the engine has a more detailed knowledge of the map.
Which brings up a problem I've been thinking about. When you separate the
game engine from the AI this way, how does the AI know about the map?
When the AI is part of the engine, the most natural way to keep track
of who knows what about the map is to include that data in the same
data structure the game engine uses for the world. When we separate
the AI into a separate module, we now have to have a way of communicating
the map knowledge. Perhaps this is good, since we can now abstract the
map data into a form that is more useful to the AI. Any thoughts?
Benton
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Wed, 25 Dec 1996 18:43:23 GMT
In article <01bbf26b$66a914c0$6aed90ce@blueheron>,
"Benton Jackson" <benton#bitstream,net> wrote:
>
>Bernd Wolff <bwolff#newswire,de>:
>> mykey#geocities,com meinte am 20.12.96
>> zum Thema "Re: Extensible Game AI (was Warcraft 2 AI)":
>>
>> m> Script: Slow...
>> m>
>> m> An Idea..
>> m>
>> m> What about a language like Java, your EXE interprets the "machine
>> m>code"
>>
>> This gives the same problem as the Script - it is interpreted, and
>> therefore slow. Still, I think that a language which is part of the
>> game is a good choice, as it could give better integration with the
>> game's features (e.g. limited visibility hence limited knowledge of the
>> situation)
>
>I don't think slow is a problem. Compared to the amount of effort that is
>expended by the graphics rendering, I think the AI, game play, and even
>simulation code should require very little processor time. Using a slow
>scripting language should not be a problem. Of course, there may be a few
>computationally expensive things, such as path finding and visibility
>calculations, that can be provided by the engine, but that is only
>natural since the engine has a more detailed knowledge of the map.
>
If the ExAI will be used by a "real-time strategy" game, then I disagree
that script performance that is slow is not going to be a problem.
IMO, the scripting performance would become an issue, because in a real-time
game, every single cycle is important. Even using IPC or threads or some
multi-processing approach, the ExAI will be hard pressed to take the time
to make "good" decisions (which often take many more inerations to do) and
will find that it is able to only come up with "adequate" decisions, before
the time comes that it must implement a decision.
If the ExAI is just used in a turn-based game, and the customers do not care
how long the ExAI "thinks" between turns, then I would agree with Benton,
that the script's poor performance would not be as _much_ an issue as coming
up with a "good" decision is.
>Which brings up a problem I've been thinking about. When you separate the
>game engine from the AI this way, how does the AI know about the map?
>When the AI is part of the engine, the most natural way to keep track
>of who knows what about the map is to include that data in the same
>data structure the game engine uses for the world. When we separate
>the AI into a separate module, we now have to have a way of communicating
>the map knowledge. Perhaps this is good, since we can now abstract the
>map data into a form that is more useful to the AI. Any thoughts?
Abstracting the game's map is the way I would want to go.
The ExAI would communicate with the game through some API, that would
provide up-to-date info on the status of a map location. That info
could be processed and _stored_ by the ExAI as needed.
Once it is initialized, this separate ExAI map would only need to be
updated based on changes, so there should not be too much performance
lost due to the overhead of the additional map. However, that may change
depending on the type of game, and how it is played.
Regards,
Eric
From: bwolff#newswire,de (Bernd Wolff)
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: 26 Dec 1996 00:58:00 +0100
benton#bitstream,net meinte am 25.12.96
zum Thema "Re: Extensible Game AI (was Warcraft 2 AI)":
b> Which brings up a problem I've been thinking about. When you separate the
b> game engine from the AI this way, how does the AI know about the map?
b> When the AI is part of the engine, the most natural way to keep track
b> of who knows what about the map is to include that data in the same
b> data structure the game engine uses for the world. When we separate
b> the AI into a separate module, we now have to have a way of communicating
b> the map knowledge. Perhaps this is good, since we can now abstract the
b> map data into a form that is more useful to the AI. Any thoughts?
There should be an API which can be used to interact with the game engine
in the same way as a human user would do - e.g. a call like
"Get_Visible_Area" could return a copy of the map with all undiscovered
parts still blank. Or a "Move_Unit" command which would have its
parameters (i.e. distance,direction) checked by the engine to avoid
cheating. A closely integrated AI can manipulate game data directly, and
thus - even if not intended, but by fault - cheat, making the game much
less interesting to the human player. I have read of cases where the AI
(if it could be called this -- it was some years ago) did not obey the
rules of the game.
Ciao
Bernd
From: Swoodcoc#cris,com (Steven Woodcock)
Subject: Re: War Craft II
Date: 26 Dec 1996 07:03:45 GMT
Hello Nate:
Yeah, I was reading about Myth in the latest issue of Computer Games
Strategy Plus. There is quite a bit of customization in the game, though
I dind't see anything AI-related mentioned. I'll check that web page
reference though; thanks.
Steve
Nate Trost (nctrost#pobox,com) wrote:
:
: There is one Warcraft-ish game in development that does plan on supporting
: a fair bit of customization, including unit behavior. The working name of
: the project is "Myth", from Bungie (best known for their Marathon 3D 1st
: person series). There is a preview of Myth at their web site:
: <A HREF="http://www.bungie.com">http://www.bungie.com</A>
From: Asbj rn <bheid#sn,no>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Fri, 27 Dec 1996 03:58:52 -0800
Bernd Wolff wrote:
>
> This gives the same problem as the Script - it is interpreted, and
> therefore slow. Still, I think that a language which is part of the
> game is a good choice, as it could give better integration with the
> game's features (e.g. limited visibility hence limited knowledge of the
> situation)
>
Hmmm.. What about something like Duke3D. A kinda C/script thing that you
compile before you run it. Or was the point to be able to change it while in
game? Then you had to recompile after changing.
- Asbj rn
From: "Keith M. Lucas" <sillywiz#excession,demon.co.uk>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Sat, 28 Dec 1996 13:10:02 GMT
In article <01bbf1a5$a23b1720$82ed90ce@blueheron>,
Benton Jackson <benton#bitstream,net> wrote:
>Eric Dybsand <edybs#ix,netcom.com>:
>
>> The majority of the game buying public does NOT use UNIX workstations, that I
>know of.
But the majority of the game buying public can't program their VCR
never mind an accessible AI system. So if you limit it to PCs you lock
out manu of the people who would code the AI and make it deliverable
to many who wouldn't be able to tell the difference anyway.
Of course it may just be my bias against Windows oriented
software. Lots of neato stuff arrives but I can't keep Windows off the
floor long enough to use it. I can't even draw graphics in Paint Shop
Pro because Windows keeps giving up accepting mouse & keyboard input
at random intervals. Neopaint under a DOS emulator under Linux seems
to work much better (With just DOS it periodically freezes solid) and
I can read news at the same time...
From: Les Howie <lhowie#novalis,ca>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Sat, 28 Dec 1996 23:20:01 -0400
Benton Jackson wrote:
> Which brings up a problem I've been thinking about. When you separate the
> game engine from the AI this way, how does the AI know about the map?
> When the AI is part of the engine, the most natural way to keep track
> of who knows what about the map is to include that data in the same
> data structure the game engine uses for the world. When we separate
> the AI into a separate module, we now have to have a way of communicating
> the map knowledge. Perhaps this is good, since we can now abstract the
> map data into a form that is more useful to the AI. Any thoughts?
It looks to me like, in developing the imbedded language
interpreter, you would also have to provide objects to cover the
interface to game objects such as the map. The only interpreter
designed for imbedding which I have played with (a visual basic
clone whose name escapes me) provided for host defined
extensions to the object environment. ESRI provided a similar
environment with their proprietary Avenue language for Arc/View.
My variation on this question: How do you do this for a Java
developer. If you can in fact imbed a bytecode interpretter in
a game (anyone know how?) how do you then provide the
Java.StuffForMyGame package to the programmer? I might tackle a
forth interpreter, but there is no way I'm writing a Java
compiler for a lousy game... :-)
Can anyone cite some references/examples on how to write a Java
interpreter? In many ways, it does seem like a natural.
From: Eric Dybsand <edybs#ix,netcom.com>
Subject: Re: Extensible Game AI (was Warcraft 2 AI)
Date: Mon, 30 Dec 1996 13:47:39 GMT
In article <E34KKr.Bo#excession,demon.co.uk>,
"Keith M. Lucas" <sillywiz#excession,demon.co.uk> wrote:
>
>But the majority of the game buying public can't program their VCR
>never mind an accessible AI system. So if you limit it to PCs you lock
>out manu of the people who would code the AI and make it deliverable
>to many who wouldn't be able to tell the difference anyway.
>
I agree, that limiting it to _any_ platform, UNIX or PC or MAC or whatever,
is not necessary for designing an ExAI conceptually, but if it is ever going
to be implemented for a commercial computer game, then some platform bias
will need to be considered, or the ExAI will not run as well as it could
on the platforms it is supported on.
Also, platform independence does come at a price. For instance, I can test
a PC version with the equipment I have in-house, but to test a MAC version,
I would have to go buy a MAC (or 2) and to test a UNIX version, the same.
Likewise, someone without PCs would need to make that investment to be able
to test the ExAI for that platform.
However, let's try not to get into a platform discussion on this?
Happy Holidays,
Eric
--
J C Lawrence Internet: claw#null,net
(Contractor) Internet: coder#ibm,net
---------(*) Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00089.html">[MUD-Dev] Summary: The Game Design Mailing List "Learning AI" Thread</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00090.html">[MUD-Dev] Re: 1997 CGDC AI Roundtable Moderator's Report</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00106.html">[MUD-Dev] Re: 1997 CGDC AI Roundtable Moderator's Report</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00089.html">[MUD-Dev] Summary: The Game Design Mailing List "Learning AI" Thread</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00088"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00088"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><strong><A NAME="00098" HREF="msg00098.html">[MUD-Dev] Re: Back to the Future (was Re: WIRED: Kilers have more fun)</A></strong>,
S. Patrick Gallaty <a href="mailto:choke#sirius,com">choke#sirius,com</a>, Thu 09 Jul 1998, 02:17 GMT
<UL>
<LI><strong><A NAME="00342" HREF="msg00342.html">[MUD-Dev] Re: Back to the Future (was Re: WIRED: Kilers have more fun)</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 24 Jul 1998, 22:23 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00092" HREF="msg00092.html">[MUD-Dev] Re: 1997 CGDC AI Roundtable Moderator's Report</A></strong>,
Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Wed 08 Jul 1998, 18:57 GMT
<UL>
<LI><strong><A NAME="00106" HREF="msg00106.html">[MUD-Dev] Re: 1997 CGDC AI Roundtable Moderator's Report</A></strong>,
Ling <a href="mailto:K.L.Lo-94#student,lboro.ac.uk">K.L.Lo-94#student,lboro.ac.uk</a>, Thu 09 Jul 1998, 13:29 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00088" HREF="msg00088.html">[MUD-Dev] Summary: The "Extensible Game AI" thread</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 08 Jul 1998, 18:33 GMT
<LI><strong><A NAME="00089" HREF="msg00089.html">[MUD-Dev] Summary: The Game Design Mailing List "Learning AI" Thread</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 08 Jul 1998, 18:31 GMT
<LI><strong><A NAME="00082" HREF="msg00082.html">[MUD-Dev] Re: (fwd) Re: command parsers: a modest proposa</A></strong>,
Michael.Willey <a href="mailto:Michael.Willey#abnamro,com">Michael.Willey#abnamro,com</a>, Wed 08 Jul 1998, 16:15 GMT
<UL>
<LI><strong><A NAME="00084" HREF="msg00084.html">[MUD-Dev] Re: (fwd) Re: command parsers: a modest proposa</A></strong>,
Ross Nicoll <a href="mailto:rnicoll#calmar-mud,com">rnicoll#calmar-mud,com</a>, Wed 08 Jul 1998, 17:35 GMT
</LI>
<LI><strong><A NAME="00086" HREF="msg00086.html">[MUD-Dev] Re: (fwd) Re: command parsers: a modest proposa</A></strong>,
Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Wed 08 Jul 1998, 18:13 GMT
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>