Posted by Michael on July 24th, 2006, in Development

The avatar of the player is also driven by Drama Princess. As such, the actor will also go through the selection process filters to find the most interesting opportunities to do. But rather than making the computer pick one of those, we offer the player an interface to perform this task. In theory this could lead to situations where the player wants his or her avatar to interact with a character that is standing right in front of it, but the opportunities to do this don’t show up because other objects in the environment seem more interesting.

For this reason, the distance factor should weigh heavier on the selection process if the distance is extremely small. This probably applies to both autonomous actors as player-controlled actors. It’s a good idea to remove obects that are too far away early in the selection process. But we should add conditions that make sure that objects that are very close by get VIP treatment.
When doing the distance check, we could flag objects that are very close to ensure that at least one opportunity offered by this object makes it to the final list. Except when this objects offers no suitable opportunities. Or in Drama Princess speak, the Filter of Condition should not care about this VIP treatment. The Filter of Intimacy should pick the opportunities from this object that match the relationship best. And the Filter of Fondness could be skipped for the VIP object.

2 Comments »

Posted by Michael on July 22nd, 2006, in Development

Drama Princess needs to be a reusable system and a system that can be instanced so that multiple characters in a game can use it without having to make multiple copies of the system. For these reasons, amongst others, the system will consist of components that are used by each actor.

For reasons of performance, actors will not call all of their components every frame. But for reasons of simplicity, in what follows we will assume that they do. The order in which the components are called can be important because one component may require information from another. Components will never request information directly from other components but rather read the information from a common location that all components write to. This location is a table with rows for each actor and columns for each parameter.

Broadcast system
Called by each object (including actors) to add all the opportunities for interactions that are available with this object to the global list of opportunities that actors can consult. When objects are busy, they will not call this component, thus preventing actors from trying to interact with them when they cannot be interacted with.
Since the opportunities are behaviours, each of which will be stored in a seperate file (only to be loaded in memory when required by an actor), the list of opportunities could consist of a list of file names (or numerical IDs that represent them -for faster data transfer) accompanied by the originating object’s ID and the opportunity’s intimacy value (can be different for same behaviour with different objects).
Since an object’s list of opportunities never changes, a lot of performance optimisation can be done by reducing the requirement to actively broadcast all the opportunities to the global list of opportunities (and replacing it perhaps by an “include” flag).

Decision system
Each actor will read the global list of opportunities and apply a number of filters to it that gradually reduce the number of opportunities down to one. Each of these filters could be a component on its own.

Behaviour system
When an actor has chosen an opportunity as a goal, it calls the behaviour related to this goal. Each behaviour consists of a sequence of actions. The system evaluates the conditions for each of these actions from top to bottom (the final action of the sequence being at the top) and will execute the first one that evaluates as true.
Behaviours are independent little components that can be shared by multiple objects.
Common behaviours (like “walk to target”) can be reused by other behaviours.

Motion system
Plays skeletal animations of an actor with the aid of an animation blending system that allows for playing multiple animations simultaneously with different priorities and different subsets of bones. The animation blending system of each actor uses animations both form a standard set that comes with the actor and from a special set offered by the behaviour.
A sub-component will take care of facial expressions through morphing. Actors that are far away from the camera do not need to call this component (you wouldn’t see their expressions anyway). The blending of the morph targets will be defined by the behaviour.

Movement system
Changes the position and rotation of the actor according to parameters set by the behaviour and environmental conditions such as collisions and gravity, each of which will be components on their own.
The avatar of the player will also call an “user input” component that will influence movement.

Emotion system
Keeps track of an actor’s relationship and attitude towards an object, and of the fascination with opportunities.
Relationships improve or worsen after interactions and they worsen with seperation. Attitude becomes weaker when interacting with the same object and is reset when a new object is chosen. Attitude can become positive or negative when the relationship is neutral. Fascination drops after an interaction and then slowly increases again.
Relationship, attitude and fascination are key elements in the decision-making process.
(the fact that relationship and attitude direction are shared by both members of the relationship, may complicate matters a bit)

No Comments »

Posted by Michael on July 14th, 2006, in Development

Drama Princess Action System test 1: press a key to move the pink cone to another spot: the black actor will walk towards the cone, stop when he arrives and start displaying idle behaviour.

This may look like a simplistic test but it is structured to accomodate for the whole Drama Princess system. This structure consists of two main parts: data and engine.

The data part contains the mesh and texture of the actor, animations and Behaviours described as conditional lists of actions. These Behaviours are mini-applications that can contain any form of logic. They communicate with the engine through Interface systems.

The engine part is more elaborate. It consists of a logic system and a draw system.

The Logic System consists of four Manager systems that are applied to each actor in a loop.

• The Decision Manager will contain the decision making logic and starts new Behaviours.
• The Behaviour Manager calls the currently active Behaviour.
• The Motion Manager prepares the animation system for the next frame.
• And the Movement Manager calculates the position and rotation of the actor based on animation speed and target location.

Interface systems provide for the communication between Managers and Behaviours and each other.

• The Behaviour Interface takes care of loading Behaviours.
• The Motion Interface adds and removes animations and contains “shortcut” logic for starting and stopping the walking of an actor.
• The Actor Interface contains routines for storing Actors’ parameters.

The Draw System consists of the Appearance Manager which draws the actor in 3D space at the correct position with the correct animation.

Download the test executable (3 MB, requires Windows and DirectX 9.0c).

4 Comments »

Posted by Michael on July 8th, 2006, in Development

We will build Drama Princess as a collection of components. One of the first components that we will build is the action logic. At its root a system for playing character animations based on action sequences. For starters the choice of sequence (=opportunity) will be made by user input and not by some form of artificial intelligence. Then we can

• “play AI” to test the visual effects of our theories before building any systems and
• start with the creation of animation assets early (and direct it based on the results of the tests).

The basis of the action system will be the design discussed before in From goal to behaviour. So it’s not just about playing animations but about going through a sequence of actions based on rules. These actions trigger both animations and changes in parameters (state, position, rotation, etc). But the focus will be on animation blending first.
Other elements we will want to work on will be transitions between animation sequences and idle poses.

1 Comment »

Posted by Michael on July 8th, 2006, in Development

Drama Princess’s main focus is on a sort of decorative behaviour that only serves the purpose of making characters appear believable in a game. Often, however, characters will have a function other than decoration. With the current model, it would be difficult for a character to have personal goals, like trying to go to a certain location, being a tourist looking at things, following another character. Even for reasons of credibility it would be good if the actors could display such behaviour. And it’s another way for the author to define a character’s role or personality (a person is often characterized by his profession).

In Characters with jobs, I proposed the idea of a hard switch between the character’s “ambient AI” behaviour and a form of very controlled goal-oriented, more or less scripted behaviour when you want the character to perform a certain task. This may remain a suitable solution for forcing the character to behave in a certain way exactly (in a cut scene e.g.). But it is too strict and demands too much control from above to be suitable for general use.

Rather than continuously telling an actor what to do, we will include a task list in the definition of his personality. Not every character needs to have a task list, of course. Unlike other behaviours in the game, these tasks are not connected to objects. They are connected to the actor. They are its goals in life, so to speak.
As such, in Romanticism terms, they can be defined a opportunities without an intimacy requirement and coming from an imaginary object with which the actor has a a good relationship. Since they don’t have an intimacy level, the actor can perform tasks whenever it “wants”. And since the relationship is good, it will prefer to perform this task over most. The exact level of this relationship can be used to define the importance of the task.

This way, the opportunities list is still active and the task can be interrupted when the actor meets an object it really really likes. This should lead to more believable behaviour.

Since tasks are not connected to anything in the game world, they need to be “injected” into the opportunities list artificially. Since they are very important but they should be interruptable by very loved objects, we can add them to the opportunities list in between the filters of Intimacy and Fondness.

When the task’s goal has been reached, the actor is allowed to behave ambiently. Until the conditions change. Then the task needs to be prioritized again. The simplest way to do this is by adding a condition for injecting the task in the opportunities list. Something like “if the target is further than 20 meters away, follow it”. We could add some randomness and relativity to the condition to allow for less predictable behavior. Something like “the further away the target is, the higher the chance that you should start following it”.

Once a task has been chosing, the actor should be fairly obstinate about reaching its goal. This can be achieved by not allowing the fascination for the opportunity and the attitude towards the (imaginary) object to drop. For this, we can add an exception rule to the system that reduces fascination and attitude when interacting with objects.

Unlike normal opportunities which are selected from the surroundings and come with the necessary parameters, tasks need to have logic that allows them to actively fill in these parameters. If the task of “look at a landmark” is chosen for our Tourist character, the actor needs to actively search for the nearest landmark and move towards it.

Tasks are described in exactly the same way as opportunities (see From goal to behaviour). Tasks are independent components that can be shared by multiple actors. Tasks could even be used by objects to broadcast as opportunities. A landmark could broadcast a “look at me” opportunity e.g.

No Comments »

Posted by Michael on July 3rd, 2006, in Development

Every interaction between two actors has an impact on the intimacy of the relationship. This intimacy is objective (i.e. shared by both actors), the attitude towards it is objective as well (whether they want to make it more or less intimate). Only the enthusiasm of the actor is subjective: some actors are very enthusiastic, others are not.

But enthusiasm only impacts the chance of a break-up (also objective). After an interaction with a higher level of intimacy, the relationship will improve, even if one of the actors is more eager than the other.

It may be nice to see actors express happiness after an interaction that increased the intimacy and sadness or anger after one that didn’t. Would facial expressions be sufficient for this? Or would a certain pose or short animation be required as well? I’m not fond of the all-too-clear way in which The Sims have plus or minus graphics above their heads after an interaction.

I also don’t like the idea of actors doing a “i liked it” or “i disliked it” after every interaction. And in fact, this is not necessary. The impact of the interaction is known when the interaction is chosen. So perhaps the facial expression can be used during the interaction. This would mean that a couple that is falling out of love, would shake hands with a sad face (because it is below their intimacy level). While actors who just met, would shake hands with a happy face. Could be good.

Alternatively, or next to this, simple emotion expressions could also be played in between other interactions. When the past few interactions have improved the relationship, actors may play a little animation expressing contentment.

A break-up should probably be met with an emotional response, the strength of which possibly related to the severity of the break-up, i.e. the level of intimacy that the relationship had before the break-up. Actors may cry passionately or just bow their head, depending on how good their relationship was, before they start interacting again.

A break-up resets the intimacy to neutral. When the intimacy is neutral, attitude is being defined randomly. Attitude impacts whether the relationship will get better or worse. The more neutral a relationship is, the more chance attitude can go either way. Once the intimacy of a relationship evolves (towards less or towards more), attitude will tend to remain the same.
Emotions should probably be expressed when attitude seems to have been decided upon: towards more or less intimacy (happy or mean).

2 Comments »

Posted by Michael on July 3rd, 2006, in Development

The avatar of the player is also a Drama Princess character. But instead of automatically choosing opportunities as goals, the filtered list of opportunities will be presented to the player (in a dynamic button bar as in The Endless Forst e.g.). The player will then choose an opportunity as goal for the avatar.

I’m not sure if we should inform the player about the current level of the relationship with the object and the position of a certain opportunity compared to it (i.e. more or less intimate). It might be more fun for the player to “go on instinct” and choose with imagination.

I briefly considered only offering two buttons to the player: more or less intimacy. But the lack of knowing what the avatar was going to do, reduced the agency of the player too much, in my opinion. I think it’s better to know what you tell your avatar to do (and not be certain of the impact).

The player’s avatar will also broadcast opportunities for the other actors to choose from. This means that NPCs can initiate interactions that force the avatar to respond in a certain way. E.g. when the avatar broadcasts “slap me”, it will repond by falling backwards after another actor has achieved this goal. Ergo, as a result of broadcasting opportunties, the player would loose control over the avatar momentarily once in a while.
Some opportunities come with multiple ways to respond to them. These multiple ways could be offered as choices in the player’s interface. But only if the action allows for some time to pass before responding. Responding to a kiss by slapping the actor or kissing him back should happen quite quickly after the initial kiss.

Perhaps we should simply select the opportunities that an avatar broadcasts very carefully. These should be either actions with a single immediate and logical response or actions to which the response can happen at any time, while the other actor waits for it.

Or we forget about the idea of multiple responses altogether. To make life simpler. 🙂

No Comments »

Posted by Michael on June 28th, 2006, in Development

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.

8 Comments »

Posted by Michael on June 28th, 2006, in Books

The most recent part in the series.

I immediately jumped into the Architecture section and found 2 gems already. Sergio Garces’ “Flexible Object-Composition Architecture” is a more or less exact description of the method we’ve been using for Quest3D programming since a few years already (introduced to us by Ronald Jones). So it’s reassuring to read an expert’s opinion on this.

And Elizabeth Gordon’s description of behaviours as ordered lists of rules in “A Goal-Based, Multitasking Agent Architecture” is very inspiring.

“A behavior is a list of rules for achieving a goal, where each rule consists of a condition and then one or more actions to be executed if the condition is satisfied. The rules are evaluated in order from top to bottom during each game loop, and the first rule that matches is executed. The ordering of the rules should be such that the first step in the behavior is at the bottom, the second step is just above that, and so on, with the topmost rule checking whether the goal has been successfully achieved. When read from bottom to top, the rules shold thus form a complete plan. It should be clear that this structure is essentially a function containing only an if-then statement. (…) A behavior encoded in this way gives game characters important flexibility: if an action fails, the character will simply try again. If the chaacter can no longer perform the action, it will drop down to an earlier step in the plan, and if a step can be skipped, the character will skip it automatically.”

Beautiful… Elegant… Let’s steal it! 👿

1 Comment »

Posted by Michael on June 24th, 2006, in Development

Sometimes you may want an NPC to perform a certain task in the game. You could try to tweak the character’s personality so that it would be naturally inclined to do these tasks. But it’s probably a better idea to just tell it to do something.

You don’t want the character to be fully scripted, of course. After it has performed its task, the character can go back to autonomously choosing opportunities from the environment. Until the conditions for performing the task appear again.

This basically means that a character can be switched between autonomous and controlled states. The controlled state is when the character performs tasks for the game. One of these tasks might be allowing the player to control the character as an avatar, perhaps. Or scripted behaviours which can be simple (go to a certain location) or complex (follow a character while hiding behind trees and run away when a monster comes near).

The latter might approach certain forms of game AI, so you might end up switching between one type of AI and another. 😕

2 Comments »