So my programming class has spent one week getting a handle on Blender, another on Python, and this week we bring the two together. The problem is, I’m having trouble thinking of a few simple rules of thumb for when one should use Python and when one should use logic bricks. This is what I’ve come up with:
Logic Bricks
Direct cause-and-effect. If one thing happens, another thing must happen next.
Simple interactions between objects. For example, rays, collisions, etc.
Python
There is complex logic deciding what happens next. E.g. when the character stands on a coloured tiles, they will jump higher or lower. The tile contains information about how the jump will be effected.
Changing the property of another object directly.
Using resources outside of blender. Network play, dynamic textures, etc.
Remember, this is a beginner class and there are many topics we haven’t touched yet (such as states). That and it is an ESL classroom.
Are there any other ideas you would add, or anything that you think I have wrong?
I’m no BGE expert, but logic bricks are more integrated and thus quicker than python, right? Perhaps it’s best to use logic bricks for everything that happens often in the game, and phython for the more complex tasks.
Logic bricks are partial replacement for python and traditional coding. Logic bricks make achieving game mechanics visual and easier to grasp but are a bit limited in what they can do. Also large and complex games are perhaps harder to achieve via trying to manage all the logic connections and game states than writing everything in python. Logic bricks simply offer an easy way in for people that aren’t familiar with programming and are one of the key points of Blender Game Engine.
Logic bricks are also faster in similar tasks because they are programmed in C++ so in logic-intensive features it might be better to use them even if you could do the same in python. For example if you need to do a lot of raycasts for a particle system you might still want to use python to access a Raycast sensor rather than use python rayCast() function.
All logic bricks can be replaced with python script, including the sensors, controllers and actuators, interaction between bricks, game states etc. You can write one python script for your object with functions, attach an always sensor to that and have the object do everything you could do with logic bricks. This solution resembles how things are usually achieved in object oriented game development environment such as Unity or UDK. Thus why people that are aiming for professional game development and non-BGE environments should perhaps get well acquainted with python (rather than logic bricks) and coding concepts python involves such as different forms of data, loops, classes, inheritance etc.
There isn’t a definable rule per say, but there is a general concept. Python scripting offers a subset of logic brick features. This is to say that certain sensor types are not available unless you read the data from the python api of the sensors themselves, but that is what you’re supposed to do after all!
Logic bricks can be used as a tool to translate code between a visual system and a code based system. Creating comparable systems can hep familiarise the users with the mapping of visual programs to their python counterparts. However, in order to do this the user must learn how to program visually. Some may argue it is just as effective to jump straight to python.
Either way, it’s always effective to give the users the general scope of the task ahead, so inform them of what methods a game object supports, how to write data to its internal dictionary and so on, even if they don’t do it at first.
The logic bricks offer a visual and object orientated event system to configure behavior (not to be confused with OOP!). They have a nice GUI to enter the configuration parameters.
The predefined logic bricks are perfectly fine for static behavior which is typically 90% of the logic. To achieve dynamic and customized behavior you can use the Python controller, which is a logic brick too. This means you can mix predefined logic bricks and custom logic bricks without much pain.
The main difficult is to decide what to place in a custom brick and when to use predefined bricks. With sensors it is easy, there is simply no Python sensor. For efficiency purposes it should not exist anyway.
There is no Python actuator either. This is a little bit a shame as in a lot of cases you want to describe actuator behavior. But you can use the Python controller to perform actuator tasks despite the fact it is a controller. But all you can configure are the connected sensors/actuators. So it is somehow lacking custom configuration parameters. The custom code needs to extract it’s parameters from the context (properties, object relationships etc.).
With both methods it is very easy to create a mess of logic.
I suggest:
Use the predefined logic bricks whenever
you need simple tasks and
it is easily configurable with the bricks
Use the Python controller when
you need dynamic behavior
the desired behavior is not achievable with predefined logic bricks or
is much easier to solve in Python
Thumb rule: Use the right tool for the right purpose. If it does not feel right … it most-likely is not right.
BTW: You can’t replace all logic bricks with Python and they are no replacement for Python. Python is an enhancement of logic bricks ;).
I know it’s actually this way if you go technical. BGE (C++) > Logic Bricks (C++) > Python.
But the facts that there are more that you can do with python than you can do via logic bricks and that BGE as well as any other program actually processes code rather than logic bricks makes it more clear to think of the situation the other way around. Also like you said “Python is an enhancement of logic bricks”, so:
BGE (C++) > Logic Bricks (C++) < Python
Thus why it might be easier to view the situation as:
I’m going to side-step the Python vs. Logic Brick religious war. It sounds like this is a programming class and they already have an intro to Python so you should focus on Python scripting in Blender.