Originally we had planned to re-use the Action List system that we had developed for 8 but reading Elizabeth Gordon’s article about behaviours as lists of rules has made us reconsider.
Objects offer opportunities to an actor. Each opportunity consists of a sequence of actions required to achieve the goal of the opportunity. For example the opportunity “Drink” translates to “go to the table, pick up the glass, drink, put down the glass, sigh”. We will call such a sequence a behaviour.
The behaviour -or action sequence- could be stored with the object. Or the object could refer to a generic behaviour stored indepedently -so that the behaviour could be shared by multiple objects.
The original idea was to simply store a behaviour as a list of actions. This list would be copied to an actor’s Action List when the opportunity is chosen as a goal. Then the actor would do each action on the list and remove it when it’s done. When the Action List is empty, the actor does idle behaviour until a new goal is selected.
This is a slight simplification for the sake of argument. In reality, a new goals can be chosen at any time, possibly interrupting and replacing the current sequence.
Miss Gordon’s idea could be applied to Drama Princess as follows.
Rather than a simple list of actions, the actions would be arranged in an if-then-else series with the final goal at the top of the list and the first thing to do at the bottom. And rather than copying this sequence, the actor would simply remember the location of the behaviour and read it directly from there.
Rather than a simple action, each line of the list would include a condition for this action to happen. So in our previous example, the behaviour would read like “if you have put down the glass then sigh, else if you have drunk then put down the glass, else if you have a glass in your hand then drink, else if you’re close to the table then pick up the glass, else if you can see the table then walk to the table, else give up or refuse.”
The conditions could be more complex, like “if you’re close to the table and the class is not dirty” or “if you can see the table and it’s not too far”, etcetera. For Drama Princess, it will be important that these conditions can be described in an objective way. “Too far” might be different for each character so we cannot hard-code a number of meters in the condition.
Rather than keeping track of when an action has been completed in order to proceed to the next line in the Action List, the actor would simply call the complete behaviour all the time and automatically move up the list when an action is complete (i.e. when a condition evaluates as true). The end-to-start order means that the actor wouldn’t even try to walk to the table if it already has a glass in its hand, e.g.
Such a system simplifies Drama Princess in two ways.
- It removes the requirement of copying the action sequence. In fact it removes the requirement of an actor having an Action List altogether.
- And it removes seperate checking for subgoals achievement since this is built into the format of the list of rules.
Posted on June 28, 2006 at 2:22 pm
A disadvantage of removing the Action List is that we cannot drive the actor with scripted behaviours anymore. If there would be a need for that, a seperate system would be required. Scripted behaviour could be a seperate state as suggested in the Characters with jobs post and comments.
Posted on June 28, 2006 at 4:09 pm
In the example, the “sigh” action may need to be replaced by a more general “respond” that will allow the actor to express its feelings about achieving the goal (i.e. good or bad as a direct result of how the action influenced the relationship with the object).
Posted on June 28, 2006 at 4:15 pm
The behaviour would be called with the actor’s ID as a parameter. With the aid of that, it would actively check whether a condition is true by using the objective properties of the actor that are known in the game world.
This way, each behaviour can be called in the same way and we don’t need to supply different parameters depending on the requirements for the conditions.
Posted on June 28, 2006 at 4:21 pm
A single action could be as simple as an animation being played by the actor. Or it could be an action sequence in and of itself, with rules of its own. This “sub-behaviour” could be shared by many behaviours.
For example, a “put down the object in your hand” action -which may be required for picking up something else- may consist of a search for appropriate places to put the thing and different animations depending on what kind of thing or what kind of person (a child would drop a rock put put down a glass plate very carefully while a rude person may just throw the plate and let it break).
The cool thing about these behaviours being so independent as that you can program each one in fine detail without any implications for the global system (other than performance).
Posted on June 29, 2006 at 10:10 am
Sounds very interesting!
Seems to be like a good idea, to break up behaviours into several actions, that can be checked in a top-down order.
I have good experiences with creating lists in Quest3D – in a comma seperated text field. Much compacter than endless (dynamic) columns in an Array.
You could of course make a function that simply ‘plays’ an action list. For pre-defined (scripted) behaviour, the list contains a number of actions. For real-time behaviour, the function could be called with just one action as parameter.
Did you already create a list of action types?
Eg. Play animation, move from A to B, Send out signal, Wait, Reevaluate options…
All of these will have their own functions, which have a number of context sensitive parameters.
Accessing the player’s variables by using only his ID sounds compact and logical, that’s the way to do it.
Posted on June 29, 2006 at 10:40 am
I like using text-based data but Quest3D is very slow with text. So I doubt if we’ll be able to use that much.
For scripted behaviour, I’d make a seperate list with the same actions and not an alternative way to play back the rule-based action list.
I’m not sure what you mean by “action types” and why we would need them. The idea is to have everything by data-driven. So that the action itself can do whatever it wants to do and doesn’t need to fit within a predefined class or type. As long as the interface with the system is the same, an action could be anything.
The sequence that you are suggesting -if that’s what it is- is not compatible with our Drama Princess model as it gives the character too much autonomy. With the ideas described above, I hope to automate a lot of this so there is no separate “send out signal” phase, e.g. Instead the system is “always on” and updates variables whenever it is relevant to do so.
Posted on June 29, 2006 at 11:24 am
I can see how you understand my comment about action types, and maybe there’s no need.
It will come down to what indeed those ‘functions’ would be part of.
One could argue though, that a system that makes characters do stuff is actually the same as the characters. 🙂
Posted on July 8, 2006 at 10:38 pm
[…] The basis of the animation system will be the design discussed before in From goal to behaviour. So it’s not just about playing animations but about playing a sequence of animations based on rules. Other elements we will want to work on will be transitions between animation sequences and idle poses. […]