Purpose of this thread
Originally opened to hold my own thoughts regarding best practice in BGE, this thread is magically attractive for a lot of good hints and tips.
So everyone can add own thoughts in here. When you do that please keep in mind:
-
these are no laws,
[LIST] -
this are guide lines
-
it is better to think about it and keep it in mind
-
rather than blindly follow them
-
:rolleyes: if you want to contribute, add one post with your thoughts
-
you can edit and extend it later with new ideas
-
if you change your mind later, you can change your post
-
provide some reasons, why you prefer a solution
-
this helps to judge if it fits into the situation and
-
this helps to compare different solutions
-
:ba: please do not discuss in this thread, if you disagree or want to discuss
-
open a new thread at the BGE discussion forum
-
invite the BA users you want to discuss with by private message
-
as usual discuss with respect!
-
add the (objective) results of the discussion in your own post
[/LIST]
Thanks to everyone who posted here.
Thanks to everyone who is reading it (you).
Welcome to everyone who learned something from it (it includes me :D).
PS: Rate the thread - so everyone knows it is an important one!
Monsterâs best practice for BGE
This post holds my thought about how to create efficient games with the BGE.
It is meant to be a personal use. This are my rules and you do not need to follow them. Finally it is more a guide than a must. Maybe you find it usefull too ;).
Avoid unnecassary triggering of controllers
:Performance (high relevance)
-
belongs to true and false pulse settings of sensors
[LIST] -
controllers are executed everytime they are triggered by sensors
-
not executing a controller (regardless of its type) is simply faster than executing
-
belongs to sensors with general setting (like all keys) where a Python controller checks for a few key presses.
-
the controller is also triggered on other keys than the checked ones which wasts processing time
-
a balance between performance and flexibility is required.
-
âall keysâ hides what keys are checked and what not (increases complexity).
-
âall keysâ is fine if the controler deals with all keys of the game.
[/LIST]
Bad Example:
- true pulse on any sensor triggering an AND controller which activates a motion actuator. Why: The motion actuator needs just one activation and runs until receiving a deactivation. Any other true or false pulses waste controller time.
Good Example:
- no pulse on the sensor triggering an AND controller which activates a motion actuator.
Exit Python controllers as soon as possible
: Performance (high relevance)
: Complexity (high relevance)
- belongs to Python code
[LIST] - running Python code eats time (also compiled code eats time )
- reducing executed code as much as possible = faster
- if you know that you do not want to proceed with processing, exit rather than perform more processing
[LIST] - after that the checked the assumptions are valid(e.g. sensors positive)
- there is no need for large (and confusing) ifâŠthenâŠelse statements
- indentation is reduced (which improves readablity)
[/LIST]
[/LIST]
Examples:
- checking sensors to be positive - the check fails -> but the controllers continues to assign local variables, extract data - simply does nothing that âmattersâ outside of the controller BETTER exit after the check failed
- parsing through a complete list until its end - but found the results already - BETTER break after finding a result
Use actuators rather than Python controller performing the same tasks
: Performance
- belongs to tasks that will be processed over more than one frame
[LIST] - this does not belong to tasks that need adjustment by the Python controller at each frame (e.g. changing an actuators parameter dependent on the distance, speed etc.).
- actuators are compiled code and therefore faster executed than Python code
- actuators can remain active longer than just one frame - Python controllers needs to be triggered at every frame to remain active
[/LIST]
Examples:
- rotating an object with a Python controller. BETTER use a motion actuator. It can do the same and is much more efficient.
- rotating an object with a Python controller dependent on the position of another object. It is fine: There is no actuator doing this.
Disable heavy sensors that are not required all the time
: Performance (medium relevance)
- belongs to sensors with heavy processing time that are not required all the time
[LIST] - ray, near, radar - each sensors needs to perform additional physics processing
- fine are mouse over, collision etc. they just use data that is produced anyway (by physics)
- it is a question of amount
- several heavy sensors take sums up much, while several light sensors can share the same data (e.g. ray through mouse cursor, keyboard keys)
- disable sensors by switching states - sensors not connected to an controller of the active state are nor evaluated
[/LIST]
Meaningfull names for game objects, meshes, sensors, actuators, IPOâs, textures etc.
: Ccomplexity (high relevance)
- It is really difficult to understand a .blend file where everything is called Plane.xxx or Cube.xxx and it is clearly somthing else.
- Naming increases readablity a lot. You wouldnât even need to open a logic brick if the names already says what it is doing.
- I recommend to think about Naming conventions before you start
[LIST] - it difficult to change everything later
- e.g. All object names start with upper case, all sensor names start with âsâ
[/LIST]
Keep it simple
: Complexity (high relevance)
- this is not easy to do, but helps a lot.
- Somehow it is difficult to explain
- one controller - one function (on high level meaning)
Examples:
- one controller to switch on Mouse cursor
- one controller to get the window size (might be triggered more than once!)
Keep it independent
: Complexity
: Reusability
- one controller - one function (on high level meaning)
- do only depend on other objects if you really need to (maybe better identify objects by property than name)
Avoid configuration in Python code
: Usability (high relevance)
: Complexity
- belongs to parameters used in python controllers
[LIST] - do not force users to edit Python code (bad, bad, bad)!
- configuration parameters are important for flexibility/reusability
- use properties rather than hardcoded values
- hardcode default values only
- clearly document what properties are used and what are expected
[/LIST]
Example:
- the VehicleWrapper script - contains a lot of hardcoded values at various places - this forces users to dig into code - BETTER use properties - some values can be directly taken from the scene (e.g. wheel positions)
Maintain version numbers if you published files
: Organization
- belongs to .blend files, Python code etc. everything that is published
[LIST] - if planned to be published add a version number, date and the author
- when published increase the version number of you local file
- this allows you to distinguish between different files from several locations.
- this information can be in a text file, properties or whatever.
- this gets important latest when more than one user is involved.
[/LIST]
Avoid repetition of static information examination
: Performance
: Useablity
- belongs to frequent data examination of not changing data
[LIST] - e.g. locating an object in the scenes object list by name if there is just one and never disappears
- look for it once, store the result (in a property, dict etc.)
- the search takes more time than directly grapping from the storage
- remember: properties can hold references to game objects
- it gets more important on higher number of objects, higher execution frequence of the python code
[/LIST]
Avoid dependency on object names
: Usebility
: Flexibility
- belongs to Python code
[LIST] - Object names can be different in other files.
- Objects could be renamed while developing the game
- better use properties
[LIST] - they can be assigned to multiple objects
- multiple properties can be assigned to one object
[/LIST]
[/LIST]
Try to follow a coding standard
: Organization
: Readability
-
defining yourself a coding standard
[LIST] -
let your code looking consistant through all your files
-
avoids confusion because of different writing styles in one file
-
looks just more professional
-
you can find suggestions and reasons at the Style Guide of Python Code
[/LIST]