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

[Benoit Bolsee]

Hi Cam

Your remarks concern the second phase of this project for which separate
state entities will clearly be needed. 
At this stage, the states will be libdata entities with properties on
their own (and corresponding actuator/sensors). On the Python API, the
state will be addressable directly with a getCurrentState() function. 

Groups better than parent/child? Probably. I don't know about groups; my
knowledge of Blender's internal is pretty much limited to the GE. I came
with this idea of family because a game object is rarely alone and
relies on child objects to perform, for example several empties with ray
sensors so sense the proximity of the ground, or accessoiries like a gun
etc. Making separate states for these objects seems overkill. If a state
engine becomes a separate entity, we need to find a way to map the state
bricks to a group of objects dynamically.

I'll start now with the first step of the work, which does not require
separate state entities.

Ben

-----Original Message-----
Date: Thu, 12 Jun 2008 10:32:51 +0200
From: "Campbell Barton" <ideasman42 at gmail.com>
Subject: Re: [Bf-committers] BGE improvements: States and state engine
	support
To: "bf-blender developers" <bf-committers at blender.org>
Message-ID:
	<7c1ab96d0806120132u3870073bx6f292400c1a7c3bc at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi Ben,
The first part of your proposal, though rough, seems good.
Some stuff to think about...
* Would states have their own properties? - This could be useful instead
of having to copy the properties to every object, or having to make sure
the state sets the properties. If so how would the properties co-exist
with the objects? - merge them? have global/local property namespace per
object-instance of a state?
* Regarding global states, some do_versions magic could convert each
objects bricks into a default state
* Would states be libdata? - having an ID struct and unique name, like
objects, particle systems etc. (This would be good IMHO)
* Using parent/child relationships for a family gives me flashbacks to
blenders Dupli's. Could Groups be used instead?

Though Im not familiar with the GE, could to help with PythonApi, UI,
Converting old bricks, general debugging and work with artists to test
the system for apricot.