caedes | 
04 10th, 2008
Here follows some explanation of how we’re working on the game logic.
The idea is to give an initial picture to the uninitiated, so that you’ll get the basic jargon we use, while also talking about some apricot specific stuff more towards the end of the post.
Entity System
First I’ll describe our logic system a little bit. For starters it’s called CEL, which stands for “Crystal Entity Layer”. This is a set of extra plugins for Crystal Space more tailored for interaction and game design, so to speak.
CEL introduces the concept of “Entities” which are just containers for logic components, that can be connected either in code or graphically.
Component system
Each entity will usually contain a number of components (called “Property Classes” in cel jargon) that provide a number of “qualities” or “behaviours” to the entity.
Actually, a component is just a black box that can perform any kind of actions (like format your hard drive, punch, have an inventory), and they are controlled through input/output messages, and properties that the user can change. CEL provides a number of “native” c++ components, and more can be created using c++, python or xml (other languages could be used too, but are not supported right now).
The good thing with the component model, is that different aspects of object behaviour can be very nicely encapsulated, and if done right, we end with a component that we’ll be able to reuse in any game or app we want to make.
Setting up from blender
So… the game designer needs to add and configure components in her entities, and then connect all the messages to define how the logic will work. In brief we can set any blender object to be an entity, and then set logic properties and networks for it. We have a whole interface section devoted to entity setup, but in the following paragraphs I’ll detail just the parts related to the logic components.
Property classes tab
Setting up the components can be done from the b2cs “Property classes” tab, which basically allows to add any number of components to blender objects, and then setup the properties, or actions that will be run when the entity is created. On the right you can see a somehow old screenshot of the bunny components, you can see it is one mean bunny.
Graphical logic editing
Graphical logic design can be done by using a cel implementation of State Machines which in cel are called “Quests”.
These allow to have a number of states, and in each of these states wait for some trigger (aka sensors), that when activated will run a series of rewards (aka actuators), and possibly go to a different state. This allows to nicely design interaction ranging from behaviour of something simple like a door, to more high level concepts as the sequence of actions you need to do to finish some game quest. Also the quest editor directly supports new components that programmers create, so it is already hugely extendable (say we want a component to run an external program, or render nice scrolling credits, or allow to flash the screen at some point, or…).
Note that these logic representations are just a way to graphically creating cel components (by following the state machine pattern), so it is still a bit “low level”, the idea is we will eventually have a
higher level node thing to actually edit the full application at a glance. We’ve been studying a number of other node systems (quartz, kismet, pure data, isadora…), and are still designing ours. Meanwhile we’ve started working on a generic python node graph library, that will hopefully allow us (and others) to easily use node editors for a number of things (rendering, materials, animation, logic…), both inside blender and out
Apricot Python Components
So, for the moment we made a number of python components for the game, these should all be easily reusable for other games in the future (ie, they don’t have or won’t have apricot specific stuff):
- Brownian: Brownian motion for butterflies
- Enemy: Enemy actions: Attack, Die, Wander (but not deciding what to do at a certain moment)
- FallingHurts: Get damage when hit the floor at a certain speed
- Punching: Punch enemies!
- Pushing: To push physics objects around using the player
- Roll: Roll on the floor
- Shooting: Shoot stuff in your inventory (yes, for the apricot bazooka)
- Talking: For handling dialogues with npcs
- Throwing: Throw stuff around.
A lot more will be programmed in the coming months.
Apricot State Machines
The apricot state machines is where the apricot specific logic is implemented. Some can possibly still be reused for other games, but in general they are easy to make graphically, so we dont expect the same level of reusability. Also i’m not going to explain each in detail, but feel free to ask, and if there is a lot of people wanting more on this we can make a blog post later on just to show all the state machines.
Here goes the names of all that we have, to add to the mystery :-D:
Acorn, Actor, Apricot, Chestnut, Enemy, Franky, GetDamage, HudItem, HudNumber, Lever, MineWaterfall, PlaySoundTimer, RunSequence, SlideDoor, TalkToYou, TalkWithMe, VisibleOnPick
Test maps
Ok, now you have an idea of all the separate components, but how do we design these? Do we just put everything in a big map? Yeah you know the answer… we’re making a load of test cases.
Each of these test cases is a separate blend file that allows to play with just one aspect of the game, like movement, fighting with enemies, solving some specific puzzle, and so on. Right now darek is busy finishing all the test cases for the game, that will all have to be solved (as most still fail obviously), and will be a kind of “contract” among the game designer (darek) and the game developers (several outside people, and me coordinating)… which means if something is not in the test cases we’re not going to do it! 
The screenshot on the right is one of the test cases, that is supposed to test a number of difficult movement problems, btw kuddos to Khaki from Planeshift who is helping us refining the movement routines in cel and cs. The one a bit up to the left is test case for the “general interaction button”.
Of course the test cases all use linked libraries, so the objects in them are actually the real ones from the game, and all stuff that gets worked on in the test cases gets directly transferred to the main game. Also this allows to mix svn and blender development pretty nicely, specially for bigger teams, as everyone is usually working on a different blend file, and this way we mostly avoid svn conflicts.
Links
Ok, now some links related to all i just explained, in case people is interested in the different sub systems.
- CEL
- B2cs Quest Editor
- Quest Editor Remarks
- Cel Overview
- Python Property Classes
- CEL Messaging System
I still feel like there is still a lot to explain, but hopefully this will make the situation a bit clearer in general. Otherwise… please ask!!
Enjoy!
AWESOME!
Best post ever! Thanks!
It really gives the impression that you know what you are doing.
To Florian: only an impression? 🙂
That was a great blog posting – very informative, and gave lots of cool information!
It would be great if a version of the toolset was released to Blender game makers who check out this blog, so that they could tinker around with the test cases etc.
This could have a number of advantages…
– increase the amount of testing carried out with the test cases
– increase the number of people with experience using Blender and CEL / CS
– maybe even get some developers coming up with a fix / optimisation for a test case – or even a new test case scenario!
Keep up the great work!
If I could code better I would just turn Blender Src into a flexible level editor like radiant except with AA, Materials, etc. It’d be like an open source Unreal Engine. 😀 Though I’m horrible at coding.
So yall should do it!
I like this post, too. Will the StateMachine-Editor and the Entity/Property Class-Editor be limited to CEL, or will there be an abstraction layer, which can be used for ogre combined with a self defined component model (really would appreciate that 😉 )?
mfg,
Jonny.
to jonny: I’m afraid that CEL is very limited to Crystal Space (it is sitting on top of it) and the state machine is part of CEL so for now this is not usable for Ogre. Of course it shouldn’t be *that* hard to make something similar and even compatible for Ogre.
Caedes, thank you very much for all the information. This post is nice homework for self-taught persons like me. 🙂
man, I love that graphical/node AI stuff, I cant code but I can model, texture and animate haha, so it would help people like me out alot!
Thanks a lot for the information! The project looks great! One question though… will these modules (and their development) remain as a separated project or will they be integrated in the future Blender releases? In other words, will the Blende Game Engine will be replace by a CEL engine? Because the features of the CEL engine look far more advanced than the engine embedded in Blender. Thanks in advance!
Hi thanks for the detailed post. I agree with Mal. I think you guys should post versions we can test and play with. You are developing a game after all and not a movie, so there’s no plot to ruin. also games need lots of testing before release 😉 It would be usefull to the current GE users so we can see how things are heading.
How is the crystal space development coming? Are you using bullet for physics? Is the realtime bone animation system still happening? We want to hear about crystal space dev to pls. thanks again for the posts!
Something blender really need if it is ever
to be a good level editor, is a static mesh
browser.Also, an actor class browser to make it easier to place and create entities.
We always planned this guys. But we need to prepare this stuff. It’s not about spoiling the plot but 1) we need good stuff to show/test 2) we need to make good, stable and easy to install running environment. Stay tuned ! 🙂
About other questions – no, we don’t prepare B2CS as replacement of BGE, B2CS it’s just downloadable plugin.
to jonny: as jorrit says cel is very tightly coupled with cs, but some of the interface stuff we’re working on for blender should make it easier for other people in the future to create blender gui for their engines/logic systems (like tree property editor -still not started-, or the generic node library i talked about).
to Anthoni_c: well a detailed description of what you miss (with mokups and so on) always makes it easier to code for us. other than that, thats where we want to go with this.
Static Mesh Browser:
A separate view port or window in which meshes or mesh packages are displayed and can be inserted into the world environment.
Actor Class Browser:
Displays all entities that can be placed in game world for easy insertion.
This is great stuff, I can’t wait to get my hands on your .blend file and have a play with all these new features!
You guys really are my hero! The world is already a better place thanks to you, keep up the great work.
@caedes: Thanks for the info. I’ll have a look at it, when it’s finished 😉 so I can see if it helps me…
wfg,
Jonny.
Thank you very much for this post. I start understanding some concepts from crystal and Blender. this is a miracle!!! 😉
Come on Apricot team!!!
Most logical.
I’m pleased to see so much progress. Keep up the good work.
Some great news, I almost got a taste to make something interactive in blender again after 3 years. Very nice job done!
What I don’t get – why do you develop graphical nodes for python, if you could use blender’s beautiful nodes, which are already there?
another question – 1 of results(I thought so) of appricot was supposed to be an api to easy hook outer game engines(other than SC too) into viewport. Is this somehow progressing?
> What I don’t get – why do you
> develop graphical nodes for python,
> if you could use blender’s beautiful > nodes, which are already there?
I agree – Blenders graphical node setup visually looks great!
> 1 of results(I thought so) of
> appricot was supposed to be an api to
> easy hook outer game engines(other
> than SC too) into viewport. Is this
> somehow progressing?
This might make for an interesting future blog – how does Blender currently interact with CS ( sending models / textures, updates etc ), and how could this be extended for other engines ( eg a custom game engine for a commercial company, so that that they could integrate Blender into their tool pipeline )?
Ton spoke about 2.5 aiming to be very customisable, to the extent that you could effectively create a custom tool with it – I’d be interested in finding out if I could link a Blender viewport with another engine ( in my case, Shockwave 3D ), and create a custom toolkit for the artists to use in a specific scenario ( eg a “snap to grid” game editor )
Hi, Yes, one of the goal is to show how to and allow to use any engine inside blender window. It is already possible as can you see on screenshots but needs to be improved.
Greetings
This is quite interesting, from a point of view of placing 3D resources into the Apricot game scene…
The developer who just got blender-nationed regarding using the GE for a “Neural Network” application, also posted this Blender project video…
http://youtube.com/watch?v=z5GnOEqgDm8
It seems to be the basis of something that could be re-used by all Blender users.
So it seems the old python code “game Logic” will be erased *cries* i spent so long tryin gto program in python loloh well. Im too use to seeing the good old fashion logic blocks and scripting code which was easy and fun, i hope adding in all this will complicate and detour people from using the game engine…yet there seems to have alot more control which is nice since after you ‘master’ BGE you see its major flaws and dips, yet it was simple and fun i wonder what will happen to the old logic blocks, this is way more ‘industry standard’ but it might be too scary…iam a 3 year experianced blender user and iam alittle afraid of what it might turn into…and what about PYTHON CODING!!??
Rakunko:
CrystalSpace+Cel will not replace BGE, its just another (pluggable) option. Its your choice which to use, and hopefully in the future there will be even more options.
And yeah, what about python coding?
Mal: wow so cool. Problem is blender devs dont seem too interested in nice library browser, they recommended us to use some particles thing to place objects. Still.. i hope we’ll be able to have something like that (doesnt seem so incredibly difficult to pull off).
RAKUNKO:
Despite whichever high level engine component abstraction makes its way to “lead” Blender &| CS development, there will always be a level of specification, where the implementation actually is “where the rubber hits the road”, more likely than not the current Python behaviours, and C++ primitive stuff. It’s anyway nice to have higher abstraction layers to choreograph these basics onto more complex assembliles of behaviour.
Have you considered the possibilities of running some of the test cases automatically, in test driven dev / unit testing style?
Like you perhaps saw from my early tests then, testing gameplay and logic is certainly possible to some extent, but it is often not easy (in another case last week I did not succeed much, but did get limited test code that can perhaps improve later .. for AI movement sanity checks).
Of course the guts of game dev is testing by playing to get the feel etc., but still I guess it does not hurt if you can run a set to see that none of the basics are broken after refactors etc.
The various existing Python testing tools of course work inside Blender too, and I guess they can also within the CS/CEL context (i don’t know anything about the details of how py is there).
~Toni
antont:
im still thinking about how nice test cases for cel would look like, the problem is in general we are dealing with very complex situations which are somewhat difficult to reproduce, but we certainly need something, specially some nice generic support for unit-testing logic components (by testing their exposed properties and actions for example).
about the .blend test cases, there are two things we can do… export them, and run them with some test script that checks stuff… mmm… yeah that could work pretty nicely.