[Bf-committers] BGE improvements: States and state engine support

[Benoit Bolsee]

Hi,
 
This is a follow-up of a discussion that I had with Ton and several devs
of the Apricot team. To keep it short, the Apricot game prototyping is
starting but the integration with Crystal Space is not in a usable state
at present. Ton would like to use the GE for the prototype but feels
that the current logic architecture is not good enough to implement
complex object behavior.
 
The idea is to add the concept of state and state engine, with the goal
being to create reusable code and high level logic layers: logic bricks
-> state -> behavior(state engine) -> AI. We discussed different ways to
achieve this and after thinking about it, I come with this proposal:
 
Starting from the existing logic bricks design, a state will be defined
as a collection of controllers. All the sensors and actuators linked to
these controllers will also be part of the state. A sensor/actuator can
be part of more than one state but a controller belongs to one state
only. States can be activated/deactivated with a new state actuator.
Deactivating a state is equivalent to removing its controllers and all
their links to sensors/actuators from the scene. When sensors/actuators
are detached from all controllers, they are also removed from the scene
to save CPU. When a state is activated, the controllers and all their
links are brought back in the config. When a state is deactivated, the
actuators receive an OFF pulse so that they stop automatically.
How to identify states is not decided yet; it could be a name or a
simple bit in a bit mask, or both: each controller will have a single
bit set; activating state(s) would consist in setting the object's state
mask: all the controllers matching the state mask will be active.
An always sensor attached to a state will generate at least one ON pulse
every time the state is activated; this allows to implement a "enter
state" controller for some specific actions.
With this concept of state, message sensors become more important: they
play the role of a state method that can be called from other objects. A
new state sensor that is more oriented to function call (with name and
parameters) and has less overhead than the message sensor will be
created. Of course there will be a corresponding state trigger actuator.
It will be possible by Python scripting to trigger the state sensor of
another object on the spot, without having to wait for a frame cycle,
allowing to implement "helper" objects that perform tasks on demand.
Th GUI will allow to name the states and hide/display them to keep the
logic UI clean. A special display mode will only display the state names
and the state sensors/actuators so that only the overall state engine is
visible. 
To ensure backward compatibility with existing games, there will be a
global state, corresponding to controllers without state defined. This
global state will be the state enabled by default at the start of the
game.
 
The above feature is relatively simple to implement and it brings some
level of code reuse but not enough. I gathered some thoughts about this:
 
Ideally, a state engine should be self contained: only sensors/actuators
of a single object should be allowed.
I've reviewed existing BGE games implemented according to good standards
and it seems impossible to limit states to a single object but it is a
reasonable trade off to limit states to objects belonging to a "family".
I call family a collection of objects that are linked with child-parent
relationship. By adding the concept of "first name" (a name that is
specific to a child object in the family but not unique in blender),
sensors and actuators could be assigned to child object's first name.
When reusing the state engine, the condition would be that the object to
which it is applied as child objects with the same first name.  Of
course a hierarchy of families will be possible: a family that contains
one or more families, each with their specific logic. It will be
possible to send/call method of the upper family without naming it to
achieve a stack-style implementation.
In any case, a separate GUI for creating state will be necessary.  
A state engine defines a specific behavior but an object can have
multiple behaviors during its live time. It seems useful to add a
concept of behavior with the corresponding sensor/actuators.
At this stage, the proposal of Jonathan van Wunnik should be used to get
more ideas
(http://www.blender.org/documentation/logic_editing_proposal.pdf)
 
Comments are welcome. I can start to code something along these lines if
everybody agrees. I will need help for the GUI part as I'm more familiar
with GE's internal than Blender's UI. Also I don't have too much time to
spend on this. I hope I can do something quickly that is still useful.
 
/Benoit
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20080610/168b20db/attachment-0001.htm