If you come from the programming, you might have some difficulties starting with Blender.
I suggest to think in objects. Each object can have its own set of logic.
The logic is always:
- controllers that activate/deactivate
- actuators to make changes to actual game state
The execution ardoer is:
- all sensors (of all objects)
- all controllers that received a pulse from a sensor (controller with star activated run first)
- all active actuators
The best is to think in a “parallel” way. There is no guaranty on the execution order of the objects.
Wihtin an object the logic bricks are executed up->down.
The Python controller is special, it is a controller, but can perform actuator tasks as well. That also means its tasks are performed before any actuator tasks.
Sensors are always verified.
Controllers are executed only when receiving an pulse from an sensor.
Actuators are executed as long as they are active. Some actuators deactivate after their execution (e.g. property actuator), others stay active until they get deactivated (e.g. motion actuator).
You can access a not connected sensor by a python script. You can even change this sensor’s configuration.
You can access a different controller by a python script. You can not trigger this controller.
You can access but not activate/deactivate a not connected actuator by a python script.
Why do I write this much, you haven’t asked?