Re: Smart monsters

[quinet@montefiore.ulg.ac.be (Raphael Quinet)]

> From: Tero Haatanen <Tero.Haatanen@lut.fi>

(...)
(Refer to previous mails.  I don't want to overload people's mailboxes :-) )

> 
> Some more what I also like see (these could be used normal objects too):
> - examined		- object is examined
> - applied		- object is applied
> - picked/dropped	- object is picked up or droppped
> - hitted		- monster is hitted
> and some way to examine all values of object (level, hp, levitate and so on).

Good ideas.  In fact, nearly every field in the objects' structure could be
tested (all but the pointers, of course !).  Maybe we should just use the
field name and some comparison operators.

> > And here are some actions that could be associated with the conditions :
> > 
> > - say "<words>"             Guess what this one does...
> > - create <object> [<num>]   Create one or several objects.
> > - destroy <object> [<num>]  Destroy one or several objects in the player's
> >                             inventory.
> > - set <num>                 Set a flag (open the corresponding doors).
> > - reset <num>               Clear a flag (close the doors).
> > - toggle <num>              Toggle a flag (open or close the doors).
> 
> - buy, sell, give	- change items between players and NPC's
> set (or some similar) could be used set any variable 
> Example:
> {
>   name peaceful guard
>   hitted { set unaggressive 0 
>            set name aggrassive guard }
> }
> 

If we use the field names for the comparisons, we could also use these names
to change their values.

> I think, that the current message could be used to save actions and
> rest of archetype could be unchanged. Inputs/actions solution's weakest
> point is that is hard to implement actions, which don't need any
> input, like the guard which walk around the castle. Maybe some kind of 
> repeat/default input could be used.
>  
> { goto  0,31 
>   goto 31,31 
>   goto 31, 0
>   goto  0, 0 }
> or 
> { walk 5555...3333...1111...7777 }
> ... means missing numbers and numbers are directions i.e.
> 1 = north, 3 = east, 5 = south, 7 = west 
> 

If an action doesn't require any condition, we could use some dummy condition
which always evaluates to true, or define a specific keyword like "always" :

{ always walk 111...
  hit    say "Ouch !"
}

or :

{ if (true) walk 111...
  if (hit == true) say "Ouch !"
}

> > Dozens of other actions or conditions may be added, like a "random" command
> > or way to check if the number of objects that the player is carrying is
> > greater or lower than a given number, and so on...
> 
> Even the simple implementation could be very useful, if there is an easy 
> way add more conditions and actions. One very useful feature would be have 
> some state variable that could be used, so same condition would generate 
> a different action in the different phase of the game.
> 
I thought about that : in the "set/reset/toggle" commands, one could use a
number which is not used by any doors.  This is an easy way to implement a
binary flag.

> > This method should not add too much overhead in the game : the conditions
> > need only to be tested when a player comes near the monster or when he says
> > something.
> 
> It's easy check when a player says/hits/uses/applies something, but much
> harder if you must check every monster which is near the player everytime
> that someone moves. Maybe there could be special floor object  that checks 
> actions, if a player steps on it (like magic mouth or magic ear).
> 
There is an simpler way : the "special" monsters don't do anything until the
player hits them.

> I don't know, what would be good syntax to use, but it should be
> clear and easy to understand, IMHO. So that all mapmaker don't
> need to programmers :)
> 
Has someone got any ideas ?

And now comes the big question : who will add all this stuff to the game ?
I'm busy for now and I won't be able to do much before a month or so.  Any
volunteers out there ?

                                              Raphael

P.S.: Please cut out the unnecessary text in future replies.