<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2900.3314" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>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:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>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. </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008></SPAN></FONT> </DIV></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>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:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>Ideally, a state
engine should be self contained: only sensors/actuators of a single object
should be allowed.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>In any case, a
separate GUI for creating state will be necessary. </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008></SPAN></FONT><FONT
face=Arial size=2><SPAN class=250595520-09062008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>At this stage, the
proposal of Jonathan van Wunnik should be used to get more ideas (<A
href="http://www.blender.org/documentation/logic_editing_proposal.pdf">http://www.blender.org/documentation/logic_editing_proposal.pdf</A>)</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=250595520-09062008>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008>/Benoit</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=250595520-09062008></SPAN></FONT> </DIV></BODY></HTML>