Prof. Monster's BGE Guide to the GameLoop

Hi Blenderheads,

If you are reading this, you are mostlikely thinking of making a game. The BGE is a great platform to do that.

There is one thing that each game has:
THE GAMELOOP

I do not want to go into detail what a game loop is. I’m pretty sure you can find a lot of information in wikipedia or if you google for it ;).

Netherless I want to present you how the GameLoop is build up in the BGE.

It is essential to know how it works. If you keep that in mind it will explain a lot of “mysterious” behaviour that you might have discoverred in the past.

The presentation is split into these sections:

  • Loops
  • SCA

I hope you enjoy reading. let me know if something is unclear.

Edit:
now as PDF too!

Monster

Attachments

BGE Guide to - the GameLoop.pdf (578 KB)BGE Guide to - the GameLoop.pdf (578 KB)

Game Loop

Each cycle in the Game Loop represents one logical frame. Also known as logic tick. It is the smallest time unit within your game.

The BGE GameLoop is quite simple:

/uploads/default/original/4X/2/6/2/2625a23f2d850f21cac0d0518866d4a8d8259389.PNGd=1307796798

  • First the scenes are processed
  • Then the devices are checked for input
  • Last but not least the image is rendered.

It is important to know, that the render part might be skipped if the last frame was eating to much processing time (lag).
There is a limit how much renders can be skipped. If this limit exceeds (default = 5), a render will take place regardless how long it takes. Such “render” lags will result in “logic” lags. This let the game run slower than expected.

The BGE GameLoop contains another loop - the
Scenes Loop

The scenes loop cycles through all active scene performing following steps for each scene:
This loop is a bit more complex:
/uploads/default/original/4X/3/8/a/38ad8c8d943ddee751b5c2859da75d251381a7bf.PNGd=1307796798

  • Sensor evaluation
  • Controller execution
  • Actuator running
  • Physics update
  • Sound playing

1…3 builds the SCA concept that you configure as Logic bricks. The logic bricks are the interface to the logic of the game.

This is the order. Keep it in your mind.

  • You will never see a controller executed before a sensor is evaluated.
  • You will never see an actuator running before all controllers are executed.
  • The physics update is done after the controllers are executed and the actuators were running but before the render!

(If so you are wether in another frame or in another scene :cool:.)

Get both loops in one picture!

The SCA is part of the Scenes Loop which is part of the Game Loop.

Here you define the behaviour of your game. Knowing the SCA concept means knowing how to create the expected behaviour and knowing how to create efficient logic.

Sensors

I explained the setup of sensors and how they work in another thread.
Here I show you how sensors fit into the big picture.
/uploads/default/original/4X/d/b/f/dbff559e188f36e65f71caa99c802347bafae008.PNGd=1307796847

Active sensors are ALWAYS evaluated regardless what parameters you set. There is no parameter that prevents a sensor to be evaluated at every frame.
For more information on Sensors look at Sensors - A Word on Pulses.

Sensors are active if they are connected to a controller of the current state.

This means if the sensor is not connected to a controller in the current state it is not evaluated. This becomes quite handy if you want to stop the evaluation of “heavy” sensors like radar or ray.

Dependent on their paramters evaluated sensors trigger their connected controllers

Controllers

/uploads/default/original/4X/b/3/a/b3a9eee66daa4d431e2716068320b357b8f19b55.PNGd=1307796798

ALL triggered controllered are executed, regardless if the sensor’s state is True or False.
and
ONLY triggered controllered are executed, regardless if the sensor’s state is True or False.

There is no way to execute controllers that are not triggered by their connected sensors. So it is important to choose the right sensors for your controllers.

Executed controllers send activation or deactivation signals to their connected actuators.

Actuators

/uploads/default/original/4X/8/b/d/8bdbbcb68e14d5baa07cc9c08aefec78ab7abc52.PNGd=1307796847

Activation and deactivation is input from a connected controller. For that reason we call them activation signal and deactivation signal.
Receiving these signals does not necessarily mean the actuator gets activated or deactivated.

For example: an action actuator in flipper mode plays

  • the action forward when receiving the activation signal by a controller from the current pose.
  • the action reverse when receiving the deactivation signal by a controller. It deactivates after the reverse playing is done.

How long an actuator stays active depends on the actuator type.

We have sensors that run for one frame only, while others wait for deactivation signals, or stay active until they are done even with deactivation signal.

For more information look at Actuators - A Word on execution

I do not want to go into to much detail, so I hope you find this information usefull.

Monster

I think this will be very good for the overall comprehension of newcomers. :smiley: thumbs-up

And oldies who have been in the business for ages and have never taken the time to understand it. Great article Monster, very well written/illustrated!

Is it really true?

Would make more sense if device input run before scenes loop (as close in time to sensor evaluation as possible).

This is extracted from the sources (of 2.49). I can’t tell if the devices are read before starting the game loop.

Devices are:

  • keyboard
  • mouse
  • network

Now as pdf.
See Post #1

Prof. Monster can I use your model in my thesis Document.
It thesis about Blender GE with PS Move and Laser Joy
Ps Move is SONY PS3 new Controller and Laser Joy is my designed hardware for playing game in blender

Sure no problem you can use it.
Just refer where you got it from. I think this is mandatory in a thesis document anyway.

You can use the pictures in this thread as well as the content of the PDF.
Let me know if you need them in another format.

Monster

Thank you I really appreciate.
When it finish I’ll make the thread about how to connect Ps Move to Blender as well.

Oh boy what a good read!

+1 for this, a good read, this is some important stuff to know.

It is important to know, that the render part might be skipped if the last frame was eating to much processing time (lag).
There is a limit how much renders can be skipped. If this limit exceeds (default = 5), a render will take place regardless how long it takes. Such “render” lags will result in “logic” lags. This let the game run slower than expected.
@Monster: So is there a way to change that default=5 value via python? Because I am trying to make a render engine, not a game I want the render to take place no matter how long it takes.

You are a LEGEND. (Thanks a ton for your generosity)

Thx, this was highly informative ^^
But I have a couple of questions:

Since the physics are updated after the SCA, any script that reads a moving object’s position would actually be getting outdated coordinates. Am I right?

This would also mean that dynamic object’s API functions, such as “localLinearVelocity”, are actually executed during the Physics update phase, right?

Thx in advance!

Yes, you are right.

In most cases this “lag” is not visible. But there are important situations when this can become a nightmare. Example: Synchronizing two physics objects in different scenes (overlaying each other see this video).

One Workaround is to hide the physics object (make it invisible) and copy the transformation (pos/rot/scale) to one or more visible non-physics objects.

As far as I know you can change this “Physics Attribute” immediately (you can read it after changing). But the effect (positional change over time) will be calculated during Physics update. So I think you are right with your assumption.

Very nice tutorial and reference.

Thanks!

Is this your wiki?
http://wiki.gameblender.org/index.php?title=Guide_To_the_GameLoop

One question. If I want to do a game with python controllers only… The most recommendable is to have 2 always sensor, the first with triggering level false for startup and second with true to game loop?

Indeed it is the wiki version, but not my wiki ;).

(The SCA is a complete and very efficient event system. I do not recommend to bypass it.)

In case you really need this (e.g. if there is no sensors for the event in question) what you describe is a good method.

A) the Always (no pulses) - triggers the controller exactly once
B) the Always (with True pulse) - triggers the controller at each frame

The controller of B) should be placed after the controller of A) to ensure A) runs first.

Pro:

  • initialization code and permanent code is separate
  • you see the initialization code just by looking at the GUI
    Contra:
  • running two controllers is more overhead - but it is in one frame one time with very minor overhead

The differences are really small and it depends on the situation. In a lot of situation there is very few initialization code. Which makes the separation obsolete.