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