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

Alistair Riddoch alriddoch at googlemail.com
Tue May 12 10:02:57 PDT 2009

2009/5/11 Erik Hjortsberg <erik.hjortsberg at gmail.com>:
> 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.

I think most of these cases can be covered independently of the core
movement code, and are related mostly to scripted gameplay elements.
How about a property called something like "pose" which is independent
of how the character is currently moving?

My current plan is to strip out the "mode" code from the core
entirely, as I think this will not remove any functionality.

> 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
> water)
> * 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 problem with this is that it means server coordinates as sent by
default are not longer euclidean, and it massively increases the
complexity of the server code for handling visibility calculations and
physics. We actually tried this approach a long while ago while still
working mostly with a 2d client.

If we are going to want to specify an offset like this then I think it
should be specified separately, and the Z coord kept accurate, but
more often than not ignored by the client code.

One approach would be to make the new "mode" property complex, and
allow it to contain in addition to a name other optional attributes
like this;

"mode" = {
    name = "buried",
    depth = .03,

"mode" = {
    name = "flying",
    height = 22.5,

I do think we need to be very careful about handling flight this way
as it can lead to some very odd behavior over rough ground. Things in
flight don't track every detail of rough terrain, and it would be
better if flying things were usually specified in terms of their real
height thus freeing their trajectory, and allowing them to crash.

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

This all gets very media specific and I think the server is probably
better off staying out of it for things like wielded entities,
mounting on horseback etc. The server should just specify the
relationship between the entities in abstract terms, and the details
are down to metadata associated with the media. I hope this doesn't
sound like I am trying to offload the problem onto the client, but I
really don't think the server can do much to help here.

The case I was more considering was more freeform construction like
pioneering where players are building things by attaching lumps of raw
materials together, like building a platform in the branches of a

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

The fruit case is different again. I am happy to leave it to the
client to make that look good.

> I'd like to return to the "gravity affected" one.

"gravity affected" is I think overly broad and non-specific here. It
covers a number of cases that need to be treated quite differently.

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

I am really reluctant to start down the road of depending on physics
for stuff like that. We need to devise ways of marking up where the
contents of entities get placed so that it can be done right. The more
I deal with cascading up the containment hierarchy the less I like it
and the more I am inclined just to make the immediate parent
authoritative for contained entities placement constraints.

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

"falling" and "projectile" are the same case. In both examples of the
case an acceleration should be specified for gravity, and the
constraints once they intersect with the terrain will be the same as
for default grounded objects.

> 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
> offset.

I am really against using the Z coord as an offset as explained above,
though I am more than happy to allow for an offset to be specified
elsewhere as I have explained above.

I am going to go ahead now and start stripping out the "mode" code as
it stands as only a negligible portion of it is concerned with any of
the things we have discussed here, and the vast majority relates to
triggering looped animations. This will really help me with the
refactoring of the movement code at which point I can have a better
perspective on how to handle the constraints issue better.

I'll assume you can proceed with ensuring Ember can handle doing
animations without "mode"?


> 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
> _______________________________________________
> General mailing list
> General at mail.worldforge.org
> http://mail.worldforge.org/lists/listinfo/general

Alistair Riddoch
alriddoch at googlemail.com

More information about the General mailing list