🚀 go-pugleaf

In article <BsvzMw.LFy@news.cso.uiuc.edu>, tmkk@uiuc.edu (Khan) writes:
|> 
|> >Please post your questions
|> >on building artificially intelligent computer players.  Give some specifics
|> >I am interested in this.  We (Josh and some others) were building a game
|> >to have a computer player, and eventually scrapped that entire aspect, because
|> >it seemed so difficult, at the time.  Since then I have encountered a few 
|> >"classic techniques" and have had some ideas on how to handle this.  We have 
|> >some ideas from playing StarControl on the Amiga, but have not implemented 
|> >them yet.  (Another Josh is doing that.)  I would be interested in hearing 
|> >some discussion on the different view points.
|> 
|> OK, I'm interested in this topic, and it's certainly generic enough.
|> Just what are these "classic techniques" for computer-controlled
|> players? Assume for the sake of argument that this is an adventure game
|> like Zork (everybody remember the thief in Zork?) This guy had a pretty
|> detailed personality. He would follow you around, picking up the things you
|> dropped while mapping a maze, just to screw up your map making efforts.
|> 
|> I read an article in an old Byte (April 1980 I believe) written by a
|> couple of the authors of Zork, talking about the implementation of the
|> game. The article says that basically the thief is just a formula: the
|> chances of him attacking are a certain percentage, lower if you are
|> unarmed; the chances that he will filch an item vary depending on how
|> valuable the item is, and so forth. It doesn't seem as though there's a
|> whole lot to it, but I'm interested in what other techniques there are
|> to implement computer opponents.
|> 
|> Strategy games are, of course, a whole 'nother kettle of fish, since a
|> chess opponent who makes random moves isn't partu=icularly challenging.
|> ;-)
|> 

The way to go is to equip those CCPs with a life-cycle procedure with 
possibilities for changes. In addition comes the CCPs ability to parse
what is happening around it, such as 'x drops y', 'x says : hey you' etc.

I like to think of the life-cycle of a robot (much better word) as consisting
of states that check on the environment and schedules state changes forward
in time. These state changes can then be prevented either by unscheduling
events or preventing them from happening by status variables.

Heres an example in a non-existing language. I prefer lisp myself, but
as many people find it unreadable...   (((((( what ? () () ))))))


event move-on (i : integer) 
dir : direction;
begin
   if following_someone then return;   (* no automatic moving *)
   if players_present then
      schedule(10, move-on (i));  (* delay the move by ten time-units *)
   else
      dir := my_path[i];
      scedule (0, move_myself (dir));
      schedule (10, move-on (i+1 % path_length));
         (* schedule next move in ten time units *)
   end if;
end;

event someone-arrives (who : objid)
begin
   schedule(2, tell_player(who, select_intro_message())); 
end;

event tell_player (who : objid, what : string)
begin
   tell_player (who, what);
end;
   
event someone-says (who : objid, what : string)
begin
   if match(what, <pattern for 'who are you'>) then
      schedule (2, tell_player (who, select_selfdesc_message() ));
   else
   if match(what, <pattern for 'what do you do'>) then
      schedule (2, tell_player (who, select_mission_message() ));
   else
     :
     :
   end if;
end;


event someone-does (who : objid, what : string)
begin
   if match(what, <pattern for 'x goes somewhere'>) then
      if following==who then 
         scedule(1, move_myself (same-direction));
      end if;
   else
   if match(what, <pattern for 'x drops y'>) then
      if random<0.5 then
         schedule (5, take_object (the_object));
         schedule (30, drop_object (the_object));
      end if;
   else
     :
     :
   end if;
end;
 
and so on...

By adding those small intervals between an action and a reaction from
the robot it becomes much less 'robotic'. Mixing with chances, good pattern
recognition, a well defined interface towards the game kernel (such as
the 'someone-does' events being scheduled for the robot when someone  near
does something, etc) and of course an object oriented environment, it
is possible to create computer controlled players that are 'alive'...

   "Number five is alive !"  B^)


-- 
Roar Foshaug                                      (roarf@stud.cs.uit.no)
Department of Computer Science
University of Tromsoe                             'oe' is '\o{}' in Tex
N-9000 TROMSOE, NORWAY                            'OE' is '\O{}' in Tex