Movement contraints

Worldforge _finally_ got “movement constraints” implemented.

This feature basically allows world creators to declare rules for which entities the players are allowed to move.

Previously there were no constraints, so any random player could pick up any random other entity (such as a house, or another player).

As with so many other things the main reason why such a seemingly basic feature took such a long time to implement is that we want to make the rules generic and dynamic enough to allow for many different kinds of games.

We now provide multiple interception points where the world rules can make decisions on what kind of movements are allowed.

A movement operation typically involves four entities: the mover, the entity being moved, its current location and its new location. The new properties “mover_constraint”, “move_constraint”, “contain_constraint” and “destination_constraint” allows world authors to declare Entity Filters which determine what entities are allowed to move, for each step in the movement chain.

The default ruleset uses multiple definitions.

The “land” entity has a rule which restricts movement of child entities that are both “planted” and are marked as “rooted” (which basically translates to “all plants that are planted”) in land.xml

<map name="contain\_constraint">  
    <string name="default">describe("Entity is planted and can't be moved.", not (entity.mode = "planted" and entity.rooted = 1))</string>  
</map>

All creatures have a restriction which stops them from moving too heavy objects in creature.xml

<map name="mover\_constraint">  
    <string name="default">entity.mass = none or describe('Entity is too heavy.', entity.mass = none or entity.mass &lt; actor.\_mover\_mass\_max)</string>  
</map>

And mobile creatures (i.e. most larger ones) have a constraint preventing others from moving them in mobile.xml

<map name="move\_constraint">  
    <string name="default">describe("Creature can't be moved.", false)</string>  
</map>

If even more complex rules are required there’s always the possibility to add Python scripting code which directly intercepts the Move operation, at any stage of the move chain. This is done for the “effects” for example, to make them delete themselves when their parent is deleted.

See Immobile.py for example. 

These rules serve as an example; it’s easy for any world author to declare rules more fitting to their specific world.

Together with the newly added “container” functionality the engine is now in a much nicer state.