Crystal Space, CrystalBlend, GameEngine: Discussion and Plan

Game Engine, Players & Web Plug-in, Virtual Reality, support for other engines

Moderators: jesterKing, stiv

Post Reply
jorrit
Posts: 0
Joined: Thu May 15, 2003 4:01 pm

Crystal Space, CrystalBlend, GameEngine: Discussion and Plan

Post by jorrit »

DISCLAIMER! This post 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:

http://community.crystalspace3d.org/tik ... mageId=292

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 movement.
    - 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 example.

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:

Code: Select all

  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.
Pros:
  • + 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.
Cons:
  • - 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).
Pros:
  • + 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 CEL.
    + 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.
Cons:
  • - 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.
Pros:
  • + The changes to Blender to support this would be a lot easier then in the CEL-scenario.
    + 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.
Cons:
  • - 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 :-)
Pros:
  • + 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.
Cons:
  • - 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).

Greetings,

kakapo
Posts: 0
Joined: Sat Sep 04, 2004 2:32 pm

Post by kakapo »

sounds very interesting! about the plugin and previews... can the plugin only render in its own window? is there no way to get it rendering in the blender window?

Fred_Pyo
Posts: 25
Joined: Sat Nov 02, 2002 8:31 pm
Location: Somewhere in South America

Post by Fred_Pyo »

Wow! I'm impressed jorrit, SO glad to see this taking shape!

I'm kind of short of time, so I had to skim and scan the long post (also recieved it by mail)... but I will surely give you some feedback...

First... PORTAL TECHNOLOGY!!! Hehehe, it would be interesting making blender games with this... although... how familiarized are you with blender's game engine? There's this interesting actuator that some guys developed for the GE. It basically "appends" another scene to the current scene, as a way to integrate various scenes seamlessly...

Can't wait for the binary... But how will these first releases of crystal blend work? I will need Crystal Space + CEL + Blender + Crystal Blend to make it work? I guess that Blender will only be a front-end for all the twisted machinery behind Crystal Space.

About the GUI, have you seen this post?
http://www.blender.org/forum/viewtopic. ... c&start=30
This guy (Bandeler) is doing some nice work on revamping the GameEngine's GUI! It would be interesting if for better integration something like that can be developed to improve the use Crystal Blend...

But definetively, the whole Game Engine system needs a makeover. I'm sorry but I'm not fluent at all with C or C++ (still fighting my way through the easy chunks of the Blender code), I cannot offer you anyting else but ideas, or help releated to anything not very code related...

How's the progress of the Crystal Blend project itself? I mean, what is working and what isn't yet?

And about the integration of all these new things as a DLL, hmmmm... that could be interesting, but it could be somewhat disturbing to some of the Game Engine users... But if that's the best way to work, then modularity it will be!

Again, glad to see this taking shape!

jorrit
Posts: 0
Joined: Thu May 15, 2003 4:01 pm

Post by jorrit »

Fred_Pyo wrote: Can't wait for the binary... But how will these first releases of crystal blend work? I will need Crystal Space + CEL + Blender + Crystal Blend to make it work? I guess that Blender will only be a front-end for all the twisted machinery behind Crystal Space.
For the first binary I plan to release soon it will actually be the 'old-style' crystalblend which is a standalone application that doesn't depend on Blender. The new project which I'm starting now is actually going to be integrated with Blender but for that we don't have binaries yet :-)
About the GUI, have you seen this post?
http://www.blender.org/forum/viewtopic. ... c&start=30
This guy (Bandeler) is doing some nice work on revamping the GameEngine's GUI! It would be interesting if for better integration something like that can be developed to improve the use Crystal Blend...
Will have a look at that.

Greetings,

jorrit
Posts: 0
Joined: Thu May 15, 2003 4:01 pm

Post by jorrit »

jorrit wrote: Will have a look at that.
Ah just looked. That UI was the subject of the presentation right before mine. It was decided that while it was a very powerful system it was a bit too complicated for most users to actually use for games.

Greetings,

Bandoler
Posts: 28
Joined: Mon Oct 14, 2002 3:16 pm
Location: Somewhere between the 1 and the 0

Post by Bandoler »

Agreed. I'll update the thread on my engine soon with the conclusions from BlenderCon. Mainly i got to the conclusion that my system cannot target non-developer users, so it is not suitable for the Blender Game engine replacement.

I'll move it a little bit away from these web pages to avoid disrupting the new official game engine approach, but i'll go on with it, because i'm not interested in working in a more conventional engine.

However, i want to remark that the UI wasn't the subject of my presentation. The engine architecture was :).

(bandoler)

kakapo
Posts: 0
Joined: Sat Sep 04, 2004 2:32 pm

Post by kakapo »

did you miss my question? :)

something else came to my mind when thinking about how to do previews (if starting up the plugin with updated data takes to long). what about using verse in a game engine?

kakdila
Posts: 0
Joined: Fri Jan 28, 2005 2:44 pm
Location: France

Post by kakdila »

hello,
I am very happy to see that it is there again much of activity for the game engine !
I would like to ask you some thinks :
- I find that the principal problem of the game current engine it is that it is rather slow, "crystalblen" will much improve that?
- in the last version of blender, the creator of gameblender add the system colision "bullet" which seems to me very powerful, you will concerver it ?, or it exists an identical system in "crystal" ?
- I also find that the problem with the logic bric is that for projects a little large that very quickly becomes bordelic.
-I better like to program in code, do you provide that someone can entirely do a project in python if it is wished? or then to make a system logic brick which amene not rapiment with an enormous "bordel" ?
-I find as damage as you do not work together with Bandoler, your two projects seem interessants, perhaps that there would be average to find a happy medium between the two systems ?,
or to have a very simple stucture for the beginner (sensor, to control, actuator) who can be held (system of Bandoler) for those which wishes it?

-------
sorry my bad english

jorrit
Posts: 0
Joined: Thu May 15, 2003 4:01 pm

Post by jorrit »

kakdila wrote:hello,
I am very happy to see that it is there again much of activity for the game engine !
I would like to ask you some thinks :
- I find that the principal problem of the game current engine it is that it is rather slow, "crystalblen" will much improve that?
Yes I think it will.
- in the last version of blender, the creator of gameblender add the system colision "bullet" which seems to me very powerful, you will concerver it ?, or it exists an identical system in "crystal" ?
CrystalBlend now uses ODE library which is pretty powerful but we are working on a Bullet plugin to so that we can compare the two systems.
- I also find that the problem with the logic bric is that for projects a little large that very quickly becomes bordelic.
-I better like to program in code, do you provide that someone can entirely do a project in python if it is wished? or then to make a system logic brick which amene not rapiment with an enormous "bordel" ?
Soon I'll upload my new design document for the new CrystalBlend project. There you can see how these issues will be addressed.
-I find as damage as you do not work together with Bandoler, your two projects seem interessants, perhaps that there would be average to find a happy medium between the two systems ?,
or to have a very simple stucture for the beginner (sensor, to control, actuator) who can be held (system of Bandoler) for those which wishes it?
Cooperation is always nice. However in this case it seems that the two proposals are radically different from each other and it will be hard to find a common ground here.


Greetings,

Post Reply