mirror-textfiles.com/programming/AI/code_ai.txt

<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

-------------------------------------------------------------------