[Bf-committers] Re: [Crystalblend-main] Crystal Space, CrystalBlend, GameEngine: Discussion and Plans

[Jorrit Tyberghein]

On 10/17/05, Herman Bruyninckx <Herman.Bruyninckx at mech.kuleuven.be> wrote:

> >  + This scenario would give us the chance to do it right exactly how we want
> >    the logic to be.
>
> Does some documentation exist about what exactly is meant by "to do it
> right exactly how we want the logic to be"?

No not yet. That is what I'm trying to find out. We need to find out a
good system that is both easy to use (as is the current logic brick
system in Blender) but still flexible and powerful.

> In our robot control software project Orocos <http://www.orocos.org> we
> have chosen to go the "state machine" way, and more in particular the
> "statecharts" semantics that have been standardized in the UML context
>   (<http://www.embedded.com/1999/9901/9901feat1.htm>).
> Currently, we have the implementation of the _infrastructure_, not of the
> UI; here is the documentation:

I haven't yet read the papers you give here but personally I'm also
feeling a lot for having some support for state machine in the game
logic. I think it can be a flexible system for expressing game logic.


> The "bad news" is: a good state machine implementation requires its own
> threads of execution, which implies some dependencies on an
> "operation system" interface (basically, an interface to "threads").

Why exactly does a good state machine require threads?

Greetings,

--
Project Manager of Crystal Space (http://www.crystalspace3d.org)
and CEL (http://cel.crystalspace3d.org)
Support Crystal Space. Donate at
https://sourceforge.net/donate/index.php?group_id=649