• the acceleration is set depending on the slope of the character - but only for the direction axis
• translate the character on his local direction (z-axis)

This way we try to simulate gravity and a gliding effect to the front- or back side of the character.

First set up your (test) scene:

• an environment (with hills ;) ) - a character - a camera
• put you character on a hill, facing downhill. Set IC.
• Set 'Floor' attribute to grounds.
• create a behaviour for your camera so it fellows your character (i.e. keep at constant distance BB, Look-At BB)
• create character controller behaviour for turning your character on the local y-axis for (i.e. keyboard controller, character controller [don't use animation which translates your character!]

Now create a new Attribute Category ... add two new attributes to it:

• acceleration (float)
• speed (float)

Add them to your character.
Now have a look at the following:

So here we see - besides other less interesting stuff - the 3 main components of our behaviour

• SSP_Detector
• SSP_Translate
• Keep On Floor

The first one is responsible for getting the angle/slope and setting a corresponding value to the Acceleration-Attribute.
The second one is responsible for calculating the speed (minus friction) and for doing the actual translation.
Well and the last one simply stichtes the character to the ground.

Ok, now about getting the angle and setting the 'acceleration' attribute:

I had big difficulties to find out how to get the slope of the character concerning of the direction vector.
None of the parameter-operations I tried gave me what I needed, so I am finally using two hidden geometries, frames -
whatever you want - one is behind the character and one is in front.
You need to attach them to the character (parenting) or translate them in the same way like the character.

I am using two 3D geometries, because I wanted to use them as 'jumping-detectors' also. But otherwise 3D frames are generally a better choice, I think.

So, getting the angle is now pretty simple, just get the difference in height!

Get the height of the dummies.
Create the difference.
Now we have a problem with the precision;
therefore we have a threshold which simulates friction. Otherways, the character would nearly never stop ... no plane is plain! ;)
In my example: no acceleration between -0.1 and 0.1.

I use the angle value to create the acceleration value. Just add a multiplicator inbetween.
A good thing would be to add keys or a GUI slider which allows to finetune the multiplicator value during runtime.

Don't forget to set the value to the character's acceleration attribute!

Loop this.

Ok, next !
Retrieve the attribute values.
Add the acceleration value to the speed value and substract 'friction'.
My friction value here is 0.1 ... a value you need to tweak for yourself.

We have two cases ... sliding forwards or sliding backwards. The difference for processing is to either add
or substract the friction value.

If the new speed value is not less than 0, go ahead and set this value as new speed value and make the translation.
If the value is less than 0, check if it's between 0 and friction value * (-1) - in that case speed = 0, otherwise
go ahead.

The translation is done through a translate per second loop.

So our speed value actually - if I am not wrong - represents metres per second ?!

So, that's all.
This approach is a behavioural approach but if you are using many characters/objects with such a behaviour,
a manager-like approach might be a good solution, too.
This means a level-behaviour which iterates through a group and processes those items which are having the right
attributes.

Have fun
Dominique