Blender Game Engine Overview | Page 2

Blender org


Links
Links (3A) are the direction of logical flow between object s. Link lines are drawn by LMB dragging
from one link node (3B) to another. Links can be drawn from Sensors t o Controllers, Controllers to
Actuators or directly between Sensors and Controllers. The latter option will add an AND controller as an
intermediary brick. Sending nodes (the black circles found on the right-hand side of Sensors and
Controllers) can send to multiple reception nodes (found on the lef t-hand side of Controllers and
Actuators). Reception nodes can likewise receive multiple links.
Links can be removed by holding Ctrl + LMB selecting the link (similar to knife cut)
You cannot directly link Sensors to Actuators - A controller must be present (But as mentioned drawing a
link between them adds a controller). Actuators cannot be linked back to Sensors; if you desire to cause a
Sensor to activate after an Actuator has completed, use the actuator sensor.
Sensors
Sensors begin all logic actions. Sensors “sense” things, such as a nearby object, a key pressed on the
keyboard, timed events, etc. When a sensor is triggered, a pulse is sent to all linked controllers.
For a more in-depth look, see Sensors.

Controllers
Controllers handle the logic, evaluating pulses from sensors and sending pulses to actuators in response.
The different kinds of controllers are:
 AND - All connected sensors must be positive to send a positive pulse.
 OR - One or more connected sensor has to be positive.
 XOR - Exclusive Or: one, and only one, connected sensor has to be positive.
 NAND - Not And, inverted And controller.
 NOR - Not Or, inverted Or controller.
 XNOR - Exclusive Nor controller.
 Expression - Write your own expression.
 Python - Control the sensor with a python script or module.
For a more in-depth look, see Controllers.

Actuators
Actuators affect objects or the game in some way. Actuators change motion, sound, properties, objects,
etc. These changes can be in other objects, physics, properties or they can cause trigger events for other
logic bricks.
For a more in-depth look, see Actuators.


Properties
Properties are the game logic equivalent to variables. They are stored on the object and can be used to
represent things about them such as ammo, health, name, and so on.

Properties Panel
The properties panel.
Open the properties by selectingView »Properties or shortcut N
The properties panel is made up six parts:
Add Property button
This button adds a new property to the list, default is a Float property named “prop”, followed by
a number if there already is one with this name.
Name field
Where you give your property its name, this is how you are going to access i t through python or
expressions. The way to do so in python is by dictionary style lookup
(GameObject["propname"]). The name is case sensitive.
Property type menu
It determines which type of property it is (see below).
Value field
Sets the initial value of the property.
Debug button
Turns on debugging. Note that you must also tick Show Debug Properties in the Game menu.
When done all properties with debugging activated will be presente d with their object name,

property name and value during gameplay. This is useful if you suspect something with your
properties is causing problems.
Delete button X
Next to each property is the button to delete it.


Property Types
There is five types of properties:
Timer Starts at the property value and count upwards as long as the object exists. It can for example be
used if you want to know how long time it takes the player to complete a lev el.
Float Uses a decimal number as value, can range
Continue reading on your phone by scaning this QR Code

 / 23
Tip: The current page has been bookmarked automatically. If you wish to continue reading later, just open the Dertz Homepage, and click on the 'continue reading' link at the bottom of the page.