Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Smart monsters

From:  (Raphael Quinet)

> With this approach, all monsters will have to be redefined.  This could be
> nice to have an object-oriented language to describe monsters, but this is
> easier for now to add a set of conditions and corresponding actions to the
> existing definitions.  Some monsters could have a special "actions" 
> definition (name it as you like) when they are put on the map.  The 
> archetype will remain unchanged and only this particular instance of the 
> monster will be affected by the "actions".

Yes, the main reason to have a script language is make an individual 
monster behave individually, but there is no reason why some archetypes
can't contain special code too.

> Here are a few conditions that could be tested :
> - hear "<words>"            Just like the "@match" command.  Maybe with
>                             regexp matching ?

I think crossfire already contain rexexp matching, so that could be used.

> - has <object> [<number>]   If the player in one of the adjacent squares is
>                             carrying some object or a certain amount of it
>                             (five gold coins, for example).
> - on <number> / off <num>   The number is the same as the one used in the
>                             "connect" command for a set of doors and buttons.
> - die                       True only if the monster dies.
> - any combination of these conditions, with the traditional boolean operators
>   ("&&", "||" and "!").

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).

> 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 
  name peaceful guard
  hitted { set unaggressive 0 
           set name aggrassive guard }

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 }
{ walk 5555...3333...1111...7777 }

... means missing numbers and numbers are directions i.e.
1 = north, 3 = east, 5 = south, 7 = west 

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

> 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).

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 :)