<Edited by x2ftp admin> Shortly after Tim Triemstra and I posted articles discussing strategy game AI to rec.games.programmer, a Danish student by the name of Peer Sommerlund (peso@diku.dk) posted an article in which he outlined an object-based "methodology" for implementing an AI system which combined my ideas with Tim's. I was impressed by the effort which Peer put into his article and wrote to him, suggesting that I would like to see his posting, Tim's postings and my "essay" appear together at x2ftp.oulu.fi. When Peer expressed his approval of the idea, I contacted Tim, who was also keen to be a part of the venture. --- Andrew e-mail addresses: Peer Sommerlund: peso@diku.dk Tim Triemstra: empath@umcc.umich.edu Jouni: Yes, we are very interested in computer opponent AI and want more theory, ideas, implementations, source code, anything =-) --------------------(Peer Sommerlund's article)-------------------- Newsgroups: rec.games.programmer From: peso@diku.dk (Peer Sommerlund) Subject: Re: AI programming (ala Civ, Moo, etc.) Date: Fri, 2 Dec 1994 17:03:22 GMT andrew@cs.uct.ac.za (Andrew Luppnow) writes: > empath@umcc.umcc.umich.edu (Tim Triemstra) writes: >[Summary of a computer-player-AI technique based on "situations."] > >Tim's post reminded me of a little "essay" on the topic of >strategy-game AI which I wrote last year. I just thought I'd >dredge it up and see what you all think of the ideas I was >toying with back then. Hope the splurge below doesn't bore you >too much! ;-) [Andrew defines a hieracial system of situations] I think the two ideas match nicely. Tim has described a nice way of building prototypes for your game, Andrew has described a way to build larger systems (ie. ISS wargames). I like Tim's idea, especially the point about "the one that fits the current situation best". This way you could get your game up running fast, and refine it as you find weaknesses. You may even make your rule-database user-modifiable! A system that can be gradually expaned is very usefull. You might even make a system that can start at 1 level then later expand by building a higher level function. And another, etc.. Let's call Tim's expansions for "horizontal expansion" and Andrew's for "vertical expansion" So, you should define two classes: class action class actor Action is what your actors do. Let's take an example Actor Tank1, Tank2, Boss; Actor gets goal from higher level, send goals to lower levels, gets progress >from lower levels, sends progress to higher levels Action = "move this direction", etc.. Actor loop : get goal decide strategy deploy strategy evaluate strategy report to superior deploy strategy: send goal to lower level get report from lower level Ok, now all this should be running concurrently! Actor loop: switch case new goal: redesign strategy case report available: evaluate strategy redesign strategy: get goal evaluate current strategy if strategy needs change change strategy send new goals to lower levels evaluate strategy: see if current reports matches with current goal, can I optimize the situation by sending new goals to subordinates? if the situation has changed since last time superior was notified, tell him. Right. A concurrent Actor should know the following things: - last reports send to superior - last goals send to subordinates - current goal recieved from superior - current reports recieved from subordinates .. and the interesting part: - how to match goals and reports You may want to use Tim's excelent method here: A collection of situations (S), a distance measuerement (D) between situations, an action (A) connected to each situation. You find the S that is closest to the current situation S0 by minimizing D(S,S0). Then you apply the matching A. If you're clever, you'll sort the situations some way, and your search will be much quicker, but this is not neccesary in the first attempts to get things up running. so, "how to match goals and reports": Your situation has the following attributes: (last_goal_recieved, last_goals_send, last_reports_recieved, last_report_send) ... perhaps a few more: time, your location, etc. Just to be able to differ between goals going up and down, lets use this wording: superior A | Goal | Summary V me A | Command | Report V subordinate .. well, lots of talk. Back to the example: T1 E T2 This is a simple 2D game. Let's say each tank has a cannon that only points forwards, a tank turns slowly, so an escape strategy is to move a lot. The bullets take some time to hit target, so you can move forward, wait untill enemy points at you, then move back, etc. Also, the tank cannot turn, and move, at the same time. Some technical details: There is 32 directions your tank can face. Your tank is a circle with diameter 8, tank speed 0.1 unit/frame, cannon reload: 100 frames the bullet has diameter 1. bullet speed 1 unit/frame, bullet range: unlimited, An overall strategy (the boss) may be "surround": place a tank on opposite sides, let one duge the cannon, while the other shoots him in the back. Lets give the boss the following rules: "split": if tanks are close, separate them "surround": try to move the tanks such that ennemy is surrounded. "prepare duge": don't move the tank so close to the enemy that it cannot move away before it gets hit. leading to this set of commands: "move here, duge" "move here, kill" Let equip each tank with the following rules: "survive", 9: if ennemy is targeted on you, move 1-2 squares "kill", 5: if goal is "kill" rotate to target enemy, shoot "move", 4: if goal is "move here" rotate to face target position, move "duge", 6: if you are off your target position, and duging, wait until enemy cannon points at you. commands: "forward" "backwards" "wait" (don't move) "turn left" "turn right" "shoot" summary: "current position" Remember to put priorites on rules, you don't want the order of the rules decide which rule should be executed. regards, -Peer -- Peer Sommerlund \ Groenjordskollegiet v2512 \ 2300 Koebenhavn S \ Denmark \ E-mail: peso@diku.dk -------------------------------------------------------------------