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

Jorrit Tyberghein jorrit.tyberghein at gmail.com
Mon Oct 17 12:15:43 CEST 2005

DISCLAIMER! This mail is LARGE. I'm not responsible for any headache
you might get by reading this!


Hi all,

First an introduction. Last saturday I was at the Blender conference
where I talked in a small presentation on the work I have done on CrystalBlend
so far. CrystalBlend is an attempt to port the current Game Engine to
Crystal Space (http://www.crystalspace3d.org). Here is a screenshot of the
demo I showed at the conference:


I will soon upload a binary for windows for this demo so you can try it out
yourselves. If you have CVS and compile you can already try it at home
by downloading and compiling CS+CEL+CrystalBlend.

One of the reasons Ton invited me to the conference was to discuss the
future of the Game Engine. At the end of the day we decided that I should
try to take the lead in planning and designing the future of the Game Engine.

In this mail I try to give a summary of my thoughts on the subject of the
Game Engine. To start with I will give a small summary of the phylosophy
behind CEL (Crystal Entity Layer). This will be useful later on when I
talk about some of the ideas that I have. None of my ideas are to be seen
as fixed or something. I'm just thinking aloud here and sharing my thoughts
with you. Everything is open for discussion. Also I'd like to note that
as project manager of Crystal Space and CEL I will of course make sure that
changes needed for all this can be done in both projects (if needed).
I'd also like to note that as the project manager of Crystal Space and CEL
I will only talk about options that involve those two projects although I think
it would be a good point if we find a system in which other engines can
also be plugged in.

0. Confusing Terminology
Before going further I need to alert you to a confusion in terminology
between Crystal Space and Blender. In Blender you have 'meshes' and
'objects'. In Crystal Space those are called 'factories' and 'meshes'. Just
warning you about this as I typically use the word 'mesh' when a Blender
developer/user would use the word 'object'.

1. Info and thoughts about Crystal Space
Crystal Space as such is a 3D engine. It knows about things like mesh objects,
materials, textures, lights, a camera and so on. It knows about a lot more but
this is the basic idea. In Crystal Space everything is structured in 'sectors'.
A sector is roughly similar to what in Blender is called a 'Scene'. Every
sector contains objects, lights, and so on. Sectors are usually independent
from each other. The big difference between Crystal Space and Blender is that
you can connect sectors with portals. A portal is basically a polygon which
does not have a material attached to it but instead it has a reference to
another sector. When that portal polygon is rendered by Crystal Space it will
render the contents of that other sector as seen through this portal. i.e. it
is a 'doorway' into the other sector. At this moment CrystalBlend doesn't use
sectors and portals but they are extremely useful if you want to create big
worlds as this greatly helps the engine to find out what is visible and what
not. Without sectors and portals big MMORPG games would be harder to make using
Crystal Space (not impossible, but harder). A portal can also have a
transformation attached to it. In that case the portal will arrive in the
destination sector at another spot. You can do very nice tricks with that.
For example you can have a portal that points back to the same sector but
at another spot. Easy to make an infinite hall that way. Or you can make a
100% realistic and working mirror by making a portal that points back to the
same sector with a mirroring transform.
I think the future Game Engine should be able to use this powerful feature in
Crystal Space so some thoughts will have to go into exactly how we will do
this. The idea of using a scene for a sector seems logical (this is also how
current exporter from Blender to Crystal Space does it) but then we still need
to be able to mark portals. Currently the way we do this in the blender2cs
exporter is to mark an object as being a portal object (by using a logic
property) and then all faces of that object will be converted to portals. The
destination sector (destination scene) will also be a logic property
of that object.

2. Info and thoughts about CEL
CEL adds the notion of game entities to Crystal Space. An entity can be anything
that has relevance in a game. Most games will typically have an entity for
the actor (player). The world itself is typically also an entity. Entities
don't always have a visual representation (i.e. a mesh). Sometimes entities
can be there only for game logic purposes. Entities can be created and destroyed
at any time through game logic.

To every entity we attach a number of property classes. A property class
basically defines what the entity can do. I think this is most clearly explained
with an example. For example, a typical actor entity in an FPS game might have
the following property classes:
  - pcmesh: this is the property classes that tells CEL that this entity
    has in fact a 3D visual representation (i.e. a mesh in CS).
  - pclinmove: this is a simple movement system that supports gravity and
    basic collision detection (but otherwise no other physics). By adding
    this property class to an entity you tell CEL that this entity can move
    around in a world.
  - pccamera: the actor is typically associated with the actual player that
    plays the game. So with pccamera you tell CEL that what the actor can see
    is what the player can see. The pccamera property class supports several
    modes like first and third person view.
  - pcsoundlistener: this is similar to pccamera but instead of the visual
    it tells CEL that the sound that the player hears is the sound that the
    actor hears. Crystal Space has a 3D sound system so when you move around
    you can hear other objects around you (you can attach 'pcsoundsource'
    property classes to other entities so that they produce sound).
  - pccommandinput: this property class allows the actor entity to listen
    to keyboard, mouse, and other input devices. This will be used to control
  - pcactormove: this class ties together the property classes above so
    that when you press the key to run forward it will actually start moving
    the mesh (using pcmesh and pclinmove), move the sound listener, and also
    make sure that the mesh is playing the correct animation (like 'walk'
    when actor is walking and so on).
  - pcinventory: if you are making a game where the player can hold several
    items in his inventory then you can use this property class. pcinventory
    is capable of keeping track of other entities that are in the inventory
    (like healthkit, ammo, weapons, ...). It can use things like weight and
    other generic properties for the objects to see if the player can actually
    hold it (i.e. you can set maximum weight the player can carry and so on).
This is just an example. There are a lot more property classes (like
'pcproperties' so that you can set generic properties a bit like game logic
properties in Blender), 'pcsoundsource', 'pcquest' (more on this later),
'pcmechobject' (which makes the entity use a more realistic physics system using
ODE.  CrystalBlend uses this), and so on.

Property classes can be removed and added to an entity at any time during
the game. So this is a very dynamic and flexible system.

Finally every entity also has a 'behaviour'. The property classes describe
the physical properties of an entity. They define what the entity can do.
But they don't define HOW the entity will do it. That's for the behaviour.
The behaviour is actually what in CEL terminology is called the 'game logic'
as this is something which will typically be described in the game that
uses CEL and not in CEL itself. Behaviours are also very often scripts using
(for example) Python. But this is not a requirement. Behaviours can also be
written in C++. Crystal Blend uses the behaviour of an entity to place the
actual sensor/controller/actuator logic. Property classes communicate to the
behaviour with messages (just plain C++ function calls). For example, when
'pccommandinput' finds out a key is pressed it will send a message to the
behaviour. The behaviour can then take appropriate action. When something
puts something in the inventory the 'pcinventory' property class will send
a message to the behaviour for that. When a property is set this will also
cause a message to be sent. And so on. It is this message system that is
currently used in CrystalBlend to get information about key presses for

3. The Quest Manager
There is one property class in CEL that deserves a bit more attention because
I think that in some scenarios it could play an important role in the Game
Engine. This is the 'pcquest' property class. Basically a quest is a state
machine. I will demonstrate this with a simple example. Imagine that I need
a door in my game that opens when I click with the mouse on a button. Then
the door would close again after 30 seconds unless the button is pressed again
in which case it would close sooner. In pseudo-code this quest would
look roughly like this:
  State: Closed
    ; Wait until the button is clicked. Then start the animation sequence
    ; to open the door and go to the state 'Opening'. That state will be
    ; active while the door is busy opening.
    Trigger: on click(button-entity)
      -> Reward: start sequence 'Open Door'
      -> Reward: go to state 'Opening'
  State: Opening
    ; When the Open Door animation finishes we go to the Open state.
    ; Before that happens we don't react to button clicks or timeouts.
    Trigger: on sequence finished(Open Door)
      -> Reward: go to state 'Open'
  State: Open
    ; Wait until the button is clicked. Then start the animation sequence
    ; to close the door and go to the state 'Closing'. That state will be
    ; active while the door is busy closing.
    Trigger: on click(button-entity)
      -> Reward: start sequence 'Close Door'
      -> Reward: go to state 'Closing'
    ; We also trigger when 30 seconds has elapsed.
    Trigger: on timeout(30 seconds)
      -> Reward: start sequence 'Close Door'
      -> Reward: go to state 'Closing'
  State: Closing
    ; When the Close Door animation finishes we go to the Closed state.
    ; Before that happens we don't react to button clicks or timeouts.
    Trigger: on sequence finished(Close Door)
      -> Reward: go to state 'Closed'
  Sequence: Open Door
    ; Do the animation needed to open the door (i.e. move the mesh).
  Sequence: Close Door
    ; Do the animation needed to close the door (i.e. move the mesh).

So this quest has four states. Two states would not be sufficient because
then there is the potential problem of the player clicking on the button
again when the door hasn't finished opening yet. This is just an example
but it shows the kind of thing you can do with this. There are various
types of triggers (objects collide, object is clicked, property gets some
value, timeout, ...). There are also various types of rewards (go to another
state, set a property value, move an object, start an animation sequence, ...)

Doing this with current GameBlender sensor/actuator system would be a lot
more complicated I think.

4. Game Engine, the 0-scenario
As I see it the 0-scenario is the easiest path to go. It is basically what
I'm doing right now with CrystalBlend but then integrated into Blender. In
this scenario we would keep the current sensor/controller/actuator system and
just extend it to support the new functionality we can do in Crystal Space
and CEL. We can make it roughly backwards-compatible with current GameBlender
but I don't think that that should be a strict goal. We can add new types
of sensor and actuators to support what Crystal Space can do.
  + Easiest path. Requires least work on Blender.
  + We use a game logic system that is simple and familiar to the current
    GameBlender user base.
  + We still get the advantages of using the Crystal Space features (shaders
    and such).
  + Easier to match using non-Crystal Space/CEL engine.
  - We don't fundamentally change the logic system so all fundamental flaws
    that are present will stay there (i.e. hard to do for really big and
    complex games).
  - The current UI for sensor/controller/actuator is not that easy to use when
    the logic for an object gets rather complicated (lots of scrolling and
    folding/unfolding in a relatively small area). Although of course it would
    be possible to design a totally new UI for the existing logic system.

5. Game Engine, the CEL-scenario
In this scenario we try to make a totally new logic system which fits closely
into what CEL supports. We could have a kind of UI where you would be able
to define entities and attach property classes to it using the UI. And then
using some kind of graph or simple connections you could connect things to
(yet to be defined) 'logic blocks' (corresponding to the CEL behaviour notion).
  + It would be a good match for CEL. I also know that the CEL concept is
    received very well in the Crystal Space community and CEL is getting a
    very popular game engine. Most projects using Crystal Space also use
  + I think that it would be possible to design a relatively simple
    UI and logic system based on CEL building blocks that would be easy
    to understand and use even for people who are not programmers. i.e. it
    is basically a matter of attaching the right property classes to every
    object so that that object gets the functionality you want.
  - Politically this might be a harder option as it totally changes the
    way the Game Engine works and also very tightly couples the Blender
    Game Engine to CEL (i.e. not easy to quickly make another game engine
    plugin that uses (for example) OGRE3D).
  - It is also a lot of work to support in Blender as it would require to make
    a totally new UI for this.

6. Game Engine, the State-scenario
In this scenario we combine the existing sensor/controller/actuator system
with some kind of state machine. I haven't yet read the PDF on this subject
though. With the state machine every object would have some state and depending
on that state you would be able to attach different sensor/controller/actuator
sets. And of course there would be an actuator to switch to a different state.
  + The changes to Blender to support this would be a lot easier then in the
  + I think that simply adding this state machine alone can already solve a lot
    of the issues we currently have in the Game Engine.
  + Easier to match using non-Crystal Space/CEL engine.
  - The UI problem of the 0-scenario is also present here.
  - Perhaps this solution doesn't go far enough into changing the way the
    Game Engine works. But then that depends on how much we do want to change.

7. Game Engine, the Scratch-scenario
This is the final scenario. Completely redesign a totally new logic system
from scratch and then map it to whatever engine is used (i.e. Crystal Space
and optionally CEL if I have any say in it :-)
  + This scenario would give us the chance to do it right exactly how we want
    the logic to be.
  + Easier to match using non-Crystal Space/CEL engine.
  - Will perhaps be hard and a lot of work to come up with something that is
    both easy to use (as the current system is) and still powerful and flexible
    so that we cater for the professional game developer.
  - Also a lot of work on the Blender/UI side.
  - Depending on the system we reach it might or might not be a good match
    for CEL.

8. Plugin, modularity
In all scenarios above I think that trying to make the new Game Engine a
plugin (dll file on windows) would be the best scenario.

9. In-Blender preview thoughts
I talked to Ton after the presentation and one thing that came up was that
it would be nice to be able to use the Blender viewer itself as a quick
Game Engine preview. i.e. basically make sure that the game logic works
also inside Blender but instead of rendering with Crystal Space (or other
engine) we would let the classical Blender 3D view do the rendering and simply
let the game logic control the blender objects directly. I can't tell what
implication this would have on Blender itself as I don't know the internals
of Blender. For the 0-scenario en State-scenario this preview mode would
not be that hard to do. However for the CEL-scenario it is harder as it would
mean that we have to be able to let CEL control things that are not CS objects
(possible with some work) or else we have to duplicate the logic that is in CEL
in Blender (not a good idea). For the Scratch-scenario the complexity of this
preview depends also on how CEL is being used.

On this subject, changing CEL to work directly on Blender objects is a bit of
work to do but it is certainly possible and not a huge task.

If the transition to the new Game Engine is fast enough we perhaps don't need
to worry about this.

10. Conclusion
I would like to spark a discussion about this issue and also gather a
number of people around me that would be willing to help work on this.
I would like to work on the integration part with Crystal Space and
Crystal Entity Layer but I would like other people to work on (a forked)
version of the Blender code base to work on the new UI for the logic system
(if needed) and on a way to integrate the Crystal Space based Game Engine
as a dll (or set of dll's).


Project Manager of Crystal Space (http://www.crystalspace3d.org)
and CEL (http://cel.crystalspace3d.org)
Support Crystal Space. Donate at

More information about the Bf-committers mailing list