BGE Best Practices, post here your tips!


All Game Engines have good and bad points and the right understand of a “good practices list” is the best way to avoid traps in performance of the game. I will share a list with some tips that i had using in my works until now. if you have more please share it :smiley:


  • No Colision is always the faster, use it if you can
  • Don’t let internal collisions unsolved, it can drop the framerate without you see why.
  • Don’t use softbody. for a Physic Demo is ok, but for a final product/game, just avoid it.
  • Don’t use Triangle Mesh in your “Graphic Mesh”, make a low poly “proxy” and use Convex Hull if you can.

Loading Times:

  • Don’t make copies (SHIFT+D) make instances (ALT+D) they loads faster.
  • Don’t use large textures, Max 1024x1024
  • Png are bigger than jpg, use that just when you need alpha map
  • One Object loads faster than many objects, join all if it have the same material.
  • No compressed files loads faster


  • Don’t use many objects with the same material, join all if you can (you will lose the frustrum culling, is a good idea join they by area)


  • Shadeless is always faster than anyone config. Try use it.
  • If you can, write your own shaders, the build in Material/Node editor make a good but not too good code. It’s really dirty.
  • Don’t use many lamps, One or Two is Ok, more that is painful. (all objects compute all lamps, even it is another layer or far away)
  • Remove specular if you can (Set specular to 0)
  • Minnaert and Lambert are fast, Oren Nayar is really slow.
  • in Specular try to use Phong is faster than others.
  • Avoid use Ramps
  • Avoid use “Vertex Color Paint” option
  • When you can set ON “Backface culling” (already ON per default)
  • Use World/Ambient Color instead Hemi Light to make the Ambient Light.
  • Don’t use Dynamic Shadows yet (wait for blender 2.62 and project Hamony xD)


  • Just use Pulse Mode True/False when you need it, and try optimize the value of “freq”

Is that for now, anyone have more tips?
Please post here and i will update the first page ^^

I was just about to rant about the common JPEGophilia… then I opened Gimp, took a 512²px-Normalmap of Mine, exported it as .jpg, turned the Quality to 100 and could clearly see the Quality was still worse than the .png … but little did I know ere I increased the Substeps in Order to use the highest Quality (Advanced Properties), exported that one and could see:
.png = 611 KB
.jpg = 574 KB
Shocked I was eager to prove that the .jpg just MUST look different, loaded the .jpg to the .png and displayed the Difference… pure Blackness… no Difference… except for the still smaller Filesize…


World and Ambient color washes out the overall color, rather than actually lighting objects, like Hemisphere lights do (in GLSL mode). As for your physics section, to me, the best setup is as follows:

Mesh (no collision), parented to Armature (no collision), parented to Collision Box (simple box or sphere collision, or convex hull, if necessary).

EDIT: @C.A.ligari - Really? JPEG are smaller and can be compression-less? I didn’t know that…

Don’t use many objects with the same material? That was a typo, right? I don’t see how more materials could make the game run faster.

No, he means, “Don’t use four separate cubes with the same material when you can join them into one object”. He’s right - separate objects are drawn in separate batches, and so take much longer than drawing them together. That’s why the BGE can handle a 90000 face object at 60 FPS, but can’t handle 2000 4-face objects without choking.

Python tip:
Use modules instead of scripts. Hit the “register” button next to the text block name and then use the module logic with “scriptname.function”

Gravity tips :
The higher the gravity in the bullet settings, the more impact on performance.

Don’t use soft body? How am I gonna make cloth physics then?


Moved from: Game Engine Support and Discussion


sdfgeoff: I found out You don’t have to (and should not) register scripts to use them as modules. But using modules is good!

Registering have something to do with extending the blender UI…

@ suctioncup: In most Cases Animation won’t give very good Results, as Cloth Physics must react to Realtime Circumstances.
@ TNSv: For Cloth Physics when on a moving Character, Soft Bodies are not a very good Solution because if you would but a Coat as a Softbody over your Character’s Body, the whole Coat would permanently be wobbling, and I mean also on the Shoulders for Example, and you would get glitchy Results with Polygons leaking through.

I find a good Solution for Cloth and Hair Physics is using one or two Bones with some Bone Constraints.
And then there was a Topic where a good Solution was presented, but I don’t know anymore which Topic it was. (The One where, as a Result, a Pair of wobbling Breasts on a stiff Chest-Mesh was shown – stupid Example, but it did the Job. :wink: )

Well Overall what can be concluded:

Is that BGE is good for small games but for games that are really big and has to land as a superb graphic game is impossible in current BGE (Unless you own a beast [powerful PC] )?

Hah, good tips!
About the lights, I use 8 and 1 of them has VSM shadows.( not a slow pc tho)
And I also use ramps,and 2024 res. TGA format.

My tip: Make your characters 1k-1.5 k vertex if you want good framerate.
Use occluder option in physics tab when u can, ( if you are in a building for example make the walls occlude). This way you hide what you don’t see increasing drastically the framerate!

Good luck!

Not exactly. If you design the game right, you can make a graphically impressive game, but you might have to split the scene up. Or, you can make it graphically impressive, but not a lot going on on the logic end (where most FPS’s lean toward - lots of eyecandy, not that much actually happening).

When completed, project Harmony should help things out considerably with better lighting.

aonegamer - I dont think anything can be “concluded” from these statements in this thread. That is not the point… and most of these tips apply to every engine.

I’ve always been under the impression that .PNG is better for general use because it isn’t compressed and, when used a lot or in large sizes, gives a faster framerate. Can it be determined that framerate and loading time are inversely proportional in this manner?

Have you done any direct comparisons on this on the same build? If you have, what was the minimum size that you determined improved framerate?

Cucumber is landing in 2.62 and bring DDS files compressed on the video card - see 1.47 into this video:!

I haven’t done any tests in a long time, nor do I think I had ever done any tests. Just recalling what I’d heard all along. Glad to see that technology is progressing. :slight_smile: