in Crystal Space, Development
Thursday, April 10th, 2008 at 10:04 am
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.
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.
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.
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
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
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.
Ok, now some links related to all i just explained, in case people is interested in the different sub systems.
- 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!!