[Bf-committers] First attempt at a design for the new CrystalBlend UI

[Jorrit Tyberghein]

I did a first attempt at a design for the new CrystalBlend UI based on
the state-scenario in my previous mail. You can download the PDF here:

http://www.crystalspace3d.org/CrystalBlend/crystalblend_ui_proposal.pdf

A bit of explanation. There are basically two editing modes here.
First you have the screen where you can edit 'quests' (terminology can
be changed, don't worry too much about that). A quest is basically a
state machine. In this example I have a quest for a door that can open
('OpenableDoor'). This quest has two inputs: 'button' and 'timeout'.
The 'button' input is the object that will respond to clicks in order
to open and close the door. The 'timeout' input is the timeout value
to use for automatically closing the door. The quest also has four
states: Closed, Opening, Open, and Closing. Every state is linked to
one or more triggers. In this example I use three kinds of triggers:
  - OnClick: when an object is clicked.
  - SequenceFinish: when an animation sequence finishes.
  - TimeOut: when a timeout occurs.
More triggers are of course possible. In a way triggers represent the
current sensor system in Blender.
Every trigger is linked to one or more rewards. In this example I use
the following actuators:
  - StartSequence: start an animation sequence
  - NewState: switch the quest to a different state.
More rewards are possible. Rewards are equivalent to actuators right now.

Then you have the other mode where you can edit entities. Entities are
a bit like logic bricks (we can also call them that way if that is
preferred). A very important difference between current GameBlender
logic and this system is that the logic (i.e. triggers+rewards) is
disconnected from the actual entity so that you can reuse the same
logic for different entities. i.e. if you have multiple doors you
don't have to completely clone the entire sensor/actuator block all
the time (and have a lot of work if you need to change something).

In the entity editor you can see how the entity has three different
sections: 'properties', 'mesh', and 'quest'. More sections are
possible here if needed.

The big advantage (in my view) of this system is that it is a generic
and powerful system that is not hard to use. Also it maps VERY well to
CEL but it isn't actually very tied to it. i.e. this system can very
well be implemented on top of another 3D engine/Game logic kit.

So what do you think?

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