Game engine logic bricks observations and an OO proposition

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

Moderators: jesterKing, stiv

Post Reply
zingbat
Posts: 0
Joined: Thu Apr 29, 2004 12:36 am

Game engine logic bricks observations and an OO proposition

Post by zingbat »

I have been trying the game engine and i'm happy with it's capabilities, however i think that the logic bricks idea isn't very good the way it is right now.

One problem i found is that it's very hard to create interface logic with it. Imagine that whenever you had to connect your LCD monitor to your computer you had to hardwire it's cable directly to the graphics board instead of using a standard vga cable and two vga input and output ports. That's how i feel when i try to reuse other peoples actors. The problem i see here is that logic bricks as an idea is too simple. Kind of like assembler when compared to an high level programming language.

It makes sense that any form of visual programming language like the logic bricks idea has three kind of blocks: data sources with output only, functional blacks that convert data, actions that produce side effects and return no data. The limitation exists in how we can combine these blocks together forming a circuit and how we can organize them in modules and packages. There's also no possibility to have types of circuits with state variables we can instantiate like classes and objects in an OO programming language.

When creating circuits we can only link sensors to controllers and controllers to actions. It makes sense since sensors have no inputs and actions have no outputs, but we can't create, for example a filter and link it to a sensor then link it to a controller. We can't create a controller and link to another controller. We have script controllers that can do this but then we loose the ability to visually edit what we are doing.

It would be interesting to be able to define our own logic bricks with their own inputs and outputs to create a type of logic brick and then use that type to create copies of it in different circuits, permitting a modular approach to this. Also interesting is the ability to create logic brick interfaces which concrete logic bricks that implement those interfaces are expected to follow.

About state variables, with the instantiation mechanism for logic bricks it would make more sense for state variables to be stored in logic bricks and not in Blender objects.

This sounds like i'm trying to turn logic bricks into some kind of OO visual programming language and it's very close to what i'm proposing.

This could be done by adding a few extra objects to Blender collection.

LBNameSpace - A group of logic brick associated to a name.

LBType - An interface or a partially implemented logic brick used to instantiate concrete lbobjects. Defines the inputs, outputs and state variables for a logic brick. Something without inputs is a source or sensor. Something without outputs and having side effects is an action.

LBObject - An instantiated logic brick with their state variables initialized to default values.

LBCircuit - A collection of logic brick objects connected by their inputs and outputs. This is the tricky part; an LBCircuit is itself an LBObject and has it's own inputs and outputs. An LBCircuit can then be used inside other circuits.

Each Blender file would be a name space for logic bricks, each storing other name spaces, types, objects and circuits.

Blender Objects could have one LBCircuit associated or none. Where the LBCircuit is placed it defines the scope of that circuit. A 'this3DObject' variable would permit access the Blender Object the circuit is associated with. If that Blender object is the root of a hierarchy or a group of objects than all it's children can be inspected by the associated LBCircuit. A variable 'this3DObject.children' could be used for this purpose.

The advantages i see with this method:

* OO visual programming
* Higher level visual programming and less spaghetti code
* Better modularity
* Game Blender developers can create their own apis and share them with Blender files, in a much more easy way

Post Reply