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

Campbell Barton ideasman42 at gmail.com
Thu Jun 12 10:32:51 CEST 2008


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.

- Cam

On Tue, Jun 10, 2008 at 4:15 PM, Kent Mein <mein at cs.umn.edu> wrote:
> In reply to Benoit Bolsee (benoit.bolsee at online.be):
>
> Hi Benoit,
>
> I could be way off base here so don't take this email as law or
> anything.  ;)
>
> Its already possible to do a state machine with the current logic
> bricks, I think it would be nice to stream line things and make the
> logic bricks a bit easier to read/setup but the basics are already there
> right?
> (I Think your over thinking this a little.)
>
> Here is a simple example:
> Just add a property name it state change type to int and set it to 1.
>
> Then add a Sensor change it to property change the value to 1 (state 1)
> Then connect it to and and some logic say move it X.
> Then add a change of state by doing the following,
>        Add another and, link it to our first if we are in state 1,
>        Then add a check to see if we have moved X.
>        If so change property to State 2.
>
> For this example State 2 is our end state ;)
>
> Note if you were drawing this on paper you would want something like
> this:
>
>                State           1                       2
> Condition |---------------------------------|-----------------------|
>  x >= X   |             state = 2           |     END               |
>  always   |             x= x+ X             |     END               |
>
>
> Would be nice to change the logic bricks so you can do something like
> this, note the reason I mention this is Your conditions are your
> controllers sort of and you pretty much want to reuse them as
> well sometimes.  (Although you maybe don't need to all the time...
> The above example could also be written with x>=X and state 2 left
> blank..
>
> Kent
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list