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).
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).
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.
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 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.
- - 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.
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 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.
- - 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.
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.
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.
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).