[WF-General] Entity movement constraints, animation and the mode property

Erik Hjortsberg erik.hjortsberg at gmail.com
Mon May 11 11:36:29 PDT 2009

Hi, this is really good to go through.
As you say, we really should separate the information on how the entity 
moves from how it should be positioned.

Basically, the client can infer most thing about how to animate the 
entity from the existing entity.
Whether it's walking, running, going backways, sidestepping, sneaking 
etc. can be inferred from the velocity in relation to the orientation of 
the entity. Though, how to distinguish between walking slowly and 
sneaking? Jumping? It might be good to retain an attribute for those 
entities that are moving and are animated (i.e. creatures) which 
describes how they move.

The placement is another issue.
As I see it there are these placement types:
* gravity affected (i.e. snapped to the ground or its current container)
* fixed (here I count both those that are fixed in the air and in the water)
* floating (on top of the container, which usually should be a body of 
* attached (anything wielded, a character on a horse etc.)
* falling (not entirely sure that's this is needed, but I don't think we 
can represent things that are falling otherwise)

The "fixed" is easy; just use the position.
However, the other ones I'm thinking that we should use the vertical 
position as an offset. So that if something is "gravity affected" or 
"floating" the vertical position should define an offset. This way we 
can express when things are submerged (like a boat, or a carrot). The 
way we currently do that is that we place the origo a little further up 
the mesh. This make is possible for us to show carrots as submerged into 
the ground, but makes it impossible to easily show them when out of the 
ground. It would be much more nicer if we could have the mesh instead be 
positioned normally (i.e. the origo at the bottom of the mesh) and then 
let the server decide whether it's submerged or not. So as an example, 
if we would like to represent a carrot which is in the ground, and the 
entity has a height of 0.2, the server should use "gravity affected" 
positioning and offset the height of the entity by say -0.1. Note that 
for entities which are fixed to the terrain, such as houses, the client 
representation will need to have a foundation part which extends below 
the origo. This is to avoid gaps when the terrain underneath is uneven. 
I'm thinking that it would be good to also include this on the server, 
so that the bounding box for these entities extend a bit below the 
origo. However, in the case with the stakes it should just be an offset 
in the stake's vertical position (since a stake, in difference to a 
house, can be represented lying on the ground, when it's not embedded 
into it).
For "attached" I'm thinking that the whole position should be an offset 
from where it's normally attached. The issue with this is that the 
position of the entity is then very much dependent on how the client 
represents it. And this might perhaps not be much of an issue, since I'm 
thinking of stuff like wielded entities or ridden mounts here, where the 
client pretty much _has_ to determine where the entity is placed in 
order to make it look good. However, with your case of a tree house 
(I've previously also thought about attaching fruits to trees, for 
example apples to an apple tree) there will be some discrepancies 
between the model and the server representation (unless there will 
always be a 1-to-1 match between the server side representation and the 
client model, which I think is really hard to achieve). However, it's 
also hard not to do it that way: it will look strange otherwise. I think 
in the end it's best to do it like that (i.e. letting the client control 
where to attach it) and then put effort into making sure that the server 
and the client have approx. similar representations. As we in the future 
add a better physics support on the client I think it's a requirement.

I'd like to return to the "gravity affected" one. This is the default 
placement mode. What Ember does currently is that each entity which is 
placed using this mode queries it's parents in order about how it should 
be adjusted. In most cases they'll end up at the world entity which will 
do a height query against the mercator height map and tell the entity to 
adjust itself so that it's snapped to the ground. In some cases however 
another parent entity will respond, for example with the entities placed 
on the stalls where the stall will return an adjustment so that the 
entities are shown as lying on the table. This is however currently done 
very crude (there's a fixed height offset set on the stall Model). It 
should perhaps instead be done by doing ray checks against the geometry 
to make sure that the actual mesh geometry is used. As we add physics 
support to cyphesis this will also be changed.

And finally "falling" or "projectile". I'm not entirely sure how to 
handle these. In some sense they are "gravity affected" but just haven't 
reached the ground yet. It might very well be that they will need a 
separate position mode.

However, to start I think it's just a good idea to separate out the mode 
of positioning from the mode of movement.
And then to think a little more on whether the "gravity affected" and 
"floating" positioning modes should use the vertical position as a pure 


Alistair Riddoch wrote:
> Erik,
> How much use does Ember currently make of the various different uses
> of the "mode" property?
> This property currently feels very overloaded and ambiguous as its use
> has changed an mutated over time. In the old 2d client days it was
> used to directly access the various named animation sequences
> character sprites used. As server simulation and terrain moved into
> the third dimension we started using it to indicate if an entity sits
> on the surface of the terrain or not, then gradually extended it to
> cover other ways in which position might be constrained, or otherwise
> modified automatically by either client or server.
> If all current uses are to be covered I think we should break it down
> into at least two properties, and while we are doing an overhaul of
> this we should probably revisit the requirements.
> 1) What do clients really need in order to be able to get animations
> right? I am guessing a property giving the current motion type?
> 2) Independent of the animation of the model, what is the best way to
> express the current position constraints of an entity? Tracking the
> surface is going to be one of the most common cases, but other
> important ones include:
>  a) flying linearly through the air (birds, flying carpets etc,
> including stationary floating objects)
>  b) projectile flight through the air (missiles, falling characters)
>  c) moving freely through water (fish, diving things)
>  d) tracking the surface of the water (surface swimmer characters, ducks)
>  e) embedded in the terrain. (buried treasure, palisade stakes)
>  f) pinned to another entity (Tree houses)
> Al

More information about the General mailing list