Posted by Michael on December 20th, 2006, in Development
When a Drama Princess Actor functions as the player’s Avatar, the player will not only make the final decisions concerning the Goal to choose but also control the movement of the Actor.
Autonomous Actors get their movement information from the behaviour that was selected as a Goal. For an Avatar Actor, in most cases, a movement command from the player will seem like a “go to certain position” behaviour. So perhaps this is how it should be triggered.
Perhaps the player’s Avatar has a Task to “go to the target defined by the player” that they will (almost?) always prefer to do over anything else.
One problem with this is that we would like the choice of Avatar to be dynamic. To allow for the possibility of the player switch avatars during the course of the game. So far, Tasks have been static pre-defined behaviours attached to an Actor by the author. Perhaps all Actors can have a latent “go to the player-defined target” Task with a Condition. Opportunities already come with Conditions. And a Task is a kind of Opportunity.
This Conditional Task could also be used to force Actors that are not Avatars to go to a certain location. For use in scripted cut scenes, for instance. So rather than having this Task look at a single set of coordinates, each Actor should have its own set of coordinates that can be changed, either by the player or by a script. This could simply change the Target Position variable that is already used by the Behaviours.
The problem with this “go to the player-defined position” Task is that, as a Behaviour, it would go through the Decision System and then be presented as a menu choice to the player. This makes no sense in terms of interface. The player should have direct control over the avatar.
An override is required. Player-controlled movement as a Behaviour is not suitable.
We need an interface to immediately set the Goal of an Actor to “go to this target position”. The logic to end the previous behaviour before starting the new one can still be used (so the Actor first stands up when they were sitting down e.g.).
That’s fine for point-and-click. For direct control (joystick, cursor keys, dragging), a “follow input directions” Goal should be used that doesn’t end until the player explicitly lets go of the joystick, cursor keys or mouse button.
The nice thing about the Drama Princess concept is that these new Behaviours don’t need to be built into the Actors. An Actor can do anything you throw at them, providing you give them enough information.
So basically, at any time (and without explicitly defining an Actor as Avatar), the player can override any Actor’s Decision System and force them to go somewhere. Cool! 8)
No Comments »
Posted by Michael on December 15th, 2006, in Development
Here’s a little demo of the current state of the project. This concludes the work on the Action System so far. There’s a million little things that we would like to do but with respect to our main motto (“It’s better to make something than nothing”), we will proceed to start building the second big chunk of Drama Princess, the Decision System, next week.
There are four behaviours in this demo that each of the actors can perform: walk to a random position, walk to a random position and sit down, and walk to a random object and walk to the other actor. In the case of the latter, a “Shock” is sent to the other actor that makes him or her turn around and face the actor (not very elegantly for now 😉 ).
These behaviours are just triggered at random. When a behaviour is chosen while another one is still playing, the system first ends the other one. Every behaviour is stored in its own file and loaded in memory every time the behaviour is triggered. If special animations are required to perform the behaviour (like sitting, e.g.), these are included in the behaviour file.
Every actor uses the exact same systems (not copies or instances) with different parameters (stored in an array table). In theory, the system can support an unlimited number of actors (until your videocard gives up) but the maximum in this demo is set to 10 (press the space bar to add an actor).
There is no collision detection but the actors are aware of which objects are close to them. They look at these randomly. If the object is another actor and the other actor looks at them, they will look away.
The idea of this Action System is to give the actors a natural looking idle behaviour with built-in reflexes: spontaneous responses to their environment that do not require any decision making. There’s a lot more we would like to implement (feel free to make suggestions in the comments) but for now it will have to do.
You can download this demo here.
It requires Windows and a 3D videocard.
3 Comments »
Posted by Michael on December 7th, 2006, in Development
It’s our philosophy to only design for the rule, and not for the exception. So this post is sort of tangential since there’s not so much opportunity for it most of the time.
One of my mental tests for Drama Princess is to imagine what would happen if I, as a player, just “magically” dropped an object in the virtual world, not too far away from the actor. How would they respond?
In the current system, the actor would probably look at it. And then, depending on their relationship with this object and the other objects in the scene, they might go and interact with the new object.
This is not really what one would expect. If an object magically appears, the actor would be extremely curious. There’s a good chance that they would drop everything to go and investigate the new object. This investigation can take several forms, depending on whether the object seems to form a threat or whether it seems attractive.
To provoke this kind of response, the Drama Princess system would generate a Shock. A Shock adds a number of Opportunities to the list that the actor can choose from, and it gives those Opportunities a high Urgency value. The Shock could add an Opportunity for every desired reaction: fear, indifference, attraction. Because of the high Urgency, there’s a very good chance that the actor would “choose” one of these (the one that matches his or her relationship with the object best).
To generate a Shock as the result of user input is easy enough. But could we design a way in which Shocks can be generated by the system itself? (Do we need this?) A system like this would look at what’s going on in the world and generate a Shock when something surprising happens. To do this you need to define “surprising”.
This definition could be a list of equations, containing, amongst others,
- actors performing interactions that don’t match their relationship
- something bad happening to another actor (the lower the relationship, the worse it needs to be)
For each of these equations, the Shock Manager would need to have a few Opportunities that can be offered to the actors who are affected by the Shock.
If there’s several actors around, or if a similar response is required multiple times in the game, it would be good to have several ways to respond to the event with the same emotion. Otherwise all actors will perform the same animation and that will look unnatural. This can be partially guided with Conditions that need to be met by parameters in the actor’s definition (Enthusiasm, Faithfulness, Sexual Orientation, Gender, Age). But perhaps one of the Conditions needs to be “if no other actor in the area has chosen this opportunity”.
No Comments »
Posted by Michael on November 30th, 2006, in Development
I haven’t been able to compile a little demo as I said I would because of all sorts of administration that required my attention. It’s not so easy to find time for working… Anyway, I’m not even sure if I will be posting many demos at all given the ever increasing file size of the project.
What I’m focussing on now -and hopefully for the next few weeks without interruption- is the animation system. There’s no decision making logic in the project at all yet because I want to make sure that the animation system runs perfectly. This should make authoring and bugfixing a lot easier later.
So now I’m creating the systems that come between the decision making process and the actual animation. This includes idle motion logic as well. And I’m trying to implement a few “reflexes”, such as automatically glancing at another actor when he passes by or looking at an object close by. These “reflexes” are independent of the decision making logic. They just happen due to a simple trigger.
The idea is to make the actors seems as believable as possible without any A.I. to speak of.
No Comments »
Posted by Michael on November 19th, 2006, in Development
Is it a problem that our Actors don’t have a memory?
Or do they?
They develop Affection for every Object in the game world through interaction. This means that if they meet an Object again, they “remember” their Affection for this Object and act accordingly.
Is that enough?
What else would they need a memory for?
Do they need to learn?
Only if we want them to appear intelligent.
But intelligence is not required for believability. It’s ok if they seem a bit stupid -I guess. Perhaps it’s even endearing. And it ensures that the player always feels superior. Which is something we may want to exploit: by allowing the player to “take care” of the virtual characters, to protect them and want to help them.
1 Comment »
Posted by Michael on November 18th, 2006, in Development
Is our Decision System simple enough? Or better: is the logic to choose a goal worth the CPU time compared to a purely random choice? Will that logic make a great enough difference?
If I remember correctly, the main reason why purely random decisions are not believable is because they almost always lead to inconsistent behaviour (making all Actors look like lunatics). For interactions between virtual characters this may be acceptible to some extent (because, thanks to the missing information, we may make up for the lack of logic with our imagination), but when the player interacts with a virtual character, inconsistent behaviour would quickly destroy the illusion. Another problem is robotic behaviour: when the choice is purely random, the chance of the Actor repeating himself is great.
In our system, the first problem is solved by Affection: every Actor has a relationship with every Object in the world and that relationship only changes in small increments. All interactions have an Intimacy value that makes recommendations about which Affection level the interaction is appropriate for. The second problem is solved by Interest: the Actor loses Interest in an interaction immediately after having done it. This Interest grows back slowly, allowing the Actor to do a few other things before repeating the same one again.
The question is: is this convoluted? Or does it only sound convoluted because of the heavy words we use? After all, the Affection system is not much more than a way to keep track of the kind of interaction you did with a certain Object last time and to make sure that you do something that is not too different. And “losing Interest” is even more mechanical.
I guess we can easily test this: it’s easy to set up a system that randomly triggers behaviour. Maybe we should include that in our Behaviour System tests. Then we can observe what randomness leads to and be fully aware of the reasons why it’s not good. With that information we can evaluate the theory of our Decision system and ammend it where appropriate.
2 Comments »
Posted by Michael on November 16th, 2006, in Development
When a Goal has been selected, the Drama Princess system calls the Behaviour System. This makes the Actor play animations, move through space and trigger events. If the Decision Sytem is the brain, then the Behaviour System is the body.
Both the Decision System and the Behaviour System are called continuously for each Actor.
A Drama Princess Actor is stupid. He doesn’t know any Behaviours. The Behaviours are offered by the Objects in the game world around him in the form of Opportunities. When an Opportunity is selected by the Decision System as the Goal for the Actor, the Behaviour that corresponds to this Opportunity is loaded into memory. Only then does the Actor know what to do. When a new Goal is selected, the previous Behaviour is ended (if it hasn’t already) and it is replaced by the new Behaviour. The Actor doesn’t remember a thing. He remains an empty shell (that doesn’t take up too much RAM 😉 ).
A Behaviour is a little program that tells the Actor which animations to play, where to move to, what sounds to make, what events to trigger, etcetera. In its simplest form, a behaviour is basically a sequence of animations: “go to the table, pick up the cup, drink, put down the cup”. But it could contain more complex elements too: “find the nearest table” or “pick the cup that has water in it”. And also “reduce the amount of liquid in the cup” or even “make Johny look at me while I drink”, i.e. commands that affects other Objects than the Actor.
Every Behaviour also contains logic to end the Behaviour. This includes conditional logic to end the Behaviour at different moments. To end the “Go Sit down” behaviour while the Actor is still walking towards the chair, all that is needed is a “Stop Walking” command. But if the Actor was already seated, a “Get Up” command would be required. The Decision Manager waits for the Behaviour to end before it gives the Actor a new Goal.
So rather than making general structures in which to fit each behaviour, every Behaviour is a little unit on its own. This allows for infinite flexibility (we hope).
A behaviour can end when it is done, after which the Actor goes back to his Idle state. Or a behaviour can continue infinitely, until some external event forces it to end.
So far, there is one general system: the Look At system. It continuously plays, disregarding whether the Actor is doing a Behaviour or not. It makes the Actor look at certain positions in space. This is expressed as motion of the head. Different systems can tell the Look At system what the target of the Actor’s gaze should be: Shock events, for instance, or Behaviours themselves, or just a random function, to keep the gaze of the Actor moving around.
The movement of the Actor through space (position and rotation) is also defined in the Behaviour. It generally depends on the animation frame or time.
Behaviours can also call each other. The “Go Sit down” behaviour, for instance, starts with calling the “Go To Target” behaviour to move the Actor to the correct position.
The “Idle” behaviour is called when an Actor doesn’t have a Goal. Currently “Idle” consists of a few standing poses, some upper body activities (like scratching or yawning), looking around and some facial animations (blinking and smiling). All of these triggered randomly. I have noticed that there is a lot that you can do with this simple idle behaviour to make the Actor seem more believable. So it’s important to author and fine-tune this idle behaviour as well.
No Comments »
Posted by Michael on November 15th, 2006, in Development
This is a summary of everything that was discussed previously, plus some improvements.
Some terms have changed: Relationships are expressed as Affection, while Intimacy is only used as a property of Opportunities anymore. The Filter of Comfort has been renamed Filter of Initimacy. And the Filter of Fondness is now called Filter of Affection. Fascination is now called Interest and Attention Span is now simply Attention.
The Drama Princess system chooses a Goal from a list of Opportunities compiled for each Actor. The choice is made by filtering this list with different parameters until a single goal remains.
The list of Opportunities consists mostly of Opportunities offered by Objects in the game world. Objects include the environment, inanimate items and other actors. Opportunities offer behaviours that allow for interaction with an Object. Next to the Opportunities offered by Objects, the Actor himself can add Opportunities to the list in the form of Tasks. These are behaviours that we want the Actor to perform, disregarding the availability of Objects. And lastly, a Shock can add Opportunities to the list. A Shock is usually caused by an unexpected event in the game world. Opportunities added by a Shock are accompanied by an Urgency value.
Every Opportunity has an Initimacy value. This expresses the level of Affection between Actor and Object that is suitable for performing the behaviour. A high Intimacy value of an Opportunity requires a lot of Affection between the Actor and the Object that offers the Opportunity. And vice versa: a stone would offer a “Throw me” Opportunity with very low Intimacy value, e.g. (unless it is a masochist stone 😉 ). As a result an Actor would only throw that stone if he didn’t feel much Affection for it.
These Opportunities are then filtered down to a single one: the Goal. This filtering happens in a precise order, partially for reasons of performance (reduce the size of the list most early). At every level, a degree of randomness is injected to allow for surprise.
Continue…
2 Comments »
Posted by Michael on November 14th, 2006, in Development
I have started a thread on our Game Design Forum about stylised game characters. The current experiments that I’m doing for Drama Princess use fairly realistic models. But I’m jaleous of what games like Animal Crossing can get away with in terms of animation and behaviour.
As we have established before, consistency is of utmost importance for believability: a realistic looking characater that bounces around like a rubber ball is not believable (Prince of Persia), realistic animatitions that get repeated over and over again by many different characters neither (The Sims). So I think that if I reduce the realism of the characters a notch or two, the demands on the Drama Princess engine in terms of believability may be a bit lighter.
I’m not interested in going all the way down to cartoon level, however. So the thread mentioned above, is about trying to find examples of stylised character designs that would be suitable for use with a serious topic. If you have any tips or know of any games with stylised characters, please post (either here or in the forum).
No Comments »
Posted by Michael on November 14th, 2006, in Development
You thought this would become one of the many abandoned AI sites, didn’t you? 😉
Nono. We’re back. We’re done with all the silliness in our lives and can get back to the serious task of building Drama Princesses.
Expect a few posts soon. And some demo software by the end of the month.
1 Comment »
