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

Posted by Michael on June 23rd, 2006, in Development

Every actor has a basic set of motions that it can use to perform the actions to achieve a goal. But to interact with objects, it is the object itself that offers the motions to the actor. Such a set of motions is stored seperately so that different objects with similar interaction possibilities can share them.

An actor has a dedicated “motion container” in which the motions specific to the object it is interacting with are loaded. Every time a new object is chosen, new motions are loaded into this container, thus unloading the previous ones and keeping memory usage low (and the actor stupid 😉 ).

No Comments »

Posted by Michael on June 21st, 2006, in Development

One of the interesting things that came out of the Drama Princess Symposium was the fact that it was perfectly acceptable for an autonomous character to be stupid, as long as it was believable. One of the things that made The Sims less believable was the fact that all Sims play the same animation to achieve the same goal. The fact that they had an enormous amount of opportunities to choose as their goal (=intelligent) did not make up for this.

We have already defined opportunities as things that are offered by the environment. The idea is that this will lead to surprising behaviour. Instead of equipping the actor with a “pickup and throw” behaviour that it can apply to many different objects, you will never see a Drama Princess actor pick up and throw something until it finds a ball. The same is true for other characters. Drama Princess characters offer unique ways to the actors of interacting with them.

One thing that can aid this is to use our conditions to help the actor make a decision. There could be an opportunity that says “show you love me” and there could be several conditions like “if you’re younger then me, do this” and “if you’re my lover, do that” and “if you’re a dog do this other thing”. If the conditions are not there, the variation would depend on the actor: each actor may express “show you love me” in their own way(s).

But to get back to the opening paragraph, it would seem like a large number of opportunities to choose from an object as a goal, is not as important as a multitude of ways of achieving this goal. Some of this variety could be moved to the opportunities list where an object could advertise both “run to me and pick me up” and “summersault, fall, land next to me and pick me up”. But it seems like it would be advantageous to just have one opportunity “come to me and pick me up” and to let the actor pick one of several of his own ways in which to do this. If only because a shorter list of opportunities will require less processing when making the decision.

For the sake of variety, which way to “come” and which way to “pick up”, should be chosen randomly by the actor. But since certain ways of moving express emotions, we should take into account the actor’s intimacy level with the pertaining object when making the choice. If they dislike the object deeply, they shouldn’t be summersaulting towards it.

So rather than inventing a large number of interactions, it seems like it would be aid believability more to create a large number of animations to perform the same interaction.

This means that a ball would only advertise, e.g. “kick me”, “throw me” and “pick me up” and that an actor would have several ways of kicking, throwing and picking up. As a basis, all actors could share the same animations for this. But if time and budget permit, unique animations could be added for each character.

No Comments »

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

This is an updated and elaborated version of Decision filters. It deals with the way in which the global list of opportunities advertised by all objects is reduced to a single goal by an actor. This time, rather than ordering the list, we simply remove the items we don’t want until a single opportunity remains.

Notes about implimentation are in monotype.

Objective list of opportunities
Every object has a list of opportunities with corresponding intimacy values. All opportunities of all objects in a scene are collected in an global, objective list. All actors in the scene consult this list.

The opportunities list is an array with a row for every opportunity and columns for object ID, intimacy, condition, etc. This list can be created at runtime, or saved with the scene. This list is static and only changes if the scene changes.

Personal list of opportunities
Every actor makes a list of the same size and order where it can keep its personal notes about the opportunities. This is where the dynamic fascination for each opportunity is stored.

Objective list of objects
There is a global list of all objects in the scene. This includes environments, inanimate items and actors. This is where all data about each object is stored. This list can be consulted by every actor when they need to know something about an object.

The global list of objects is an aray with a row for each object and a column for category, state, position, etc, a column for the the level of intimacy of the relationship with each actor and a column for each actor's attitude about this relationship. The latter are personal to an actor but shared by both members of the relationship, which is why the are stored in an objective list. To simplify the array, intimacy and attitude could be stored in a single (vector) column.

The "state" column keeps track of an object's availability. This includes whether or not another actor is interacting with it. The latter serves as a parameter every time relationships are evaluated due to seperation: once in a while all relationships move a bit towards indifference except the ones that are currently involved in an interaction.

Selection filters
Once in a while, an actor goes through the whole list and removes the opportunities that don’t interest it. This happens through a series of filters. After each filter, the number of desirable opportunities is reduced.

Basically, the actor keeps a list of numbers: row numbers of the opportunities list. With each filter it removes the numbers of rows that it doesn't want to choose.
Selection parameters are relative to the available opportunities. If they would be absolute, there would be a chance that no goal remains after the filtering process.
Where possible the filters are ordered for optimal performance: filters that are processor-intensive should be executed as late in the chain as possible (i.e. with as small a number of opportunities as possible).
Running the different filters can be spread out over several frames to optimize performance.

1. Filter of Availability
   Removes the opportunities of objects that are not available.
   E.g. because they are being used by another actor.
2. Filter of Distance
   Removes the opportunities of objects that are too far away.
   This depends on their type: characters can be further away than objects.
   Type is deduced from the category property of an object.
3. Filter of Condition
   Remove the opportunities of which the condition cannot be satisified.
   E.g. passionate kissing if the actor is a young child and the object an adult.
4. Filter of Intimacy
   Removes the opportunities that match the relationship the least.
   Based on the intimacy level of the opportunity modified by the actor's fascination for this opportunity.
5. Filter of Fondness
   Removes the opportunities of objects that the actor likes least.
   Based on the intimacy level of the relationship modified by the actor's attitude.
6. Filter of Goal
   Selects a single opportunity and makes it the actor’s goal.
   Random selection out of the remaining opportunies.

Every filter (except for the first and the third) uses a little bit of randomness to allow for unexpected choices.

I’m unsure about the order of the filters of Intimacy and Fondness. Should the actor select objects first, or opportunities?

3 Comments »