How to optimize a game?

I know the obvious few such as:
low poly count (utilizing baking)
not too high resolution textures
Level of detail
not too many lamps

but was wondering if there were any other ways to optimize a game and if so how?


I would say: clever design

“optimization” has some effects:
A) it costs time
B) it (often) adds requirements which might not be met at a later stage

Typically it creates a new balance between different aspects of a game (reaction time, render time, render details, … )

A usual advice is to avoid such steps at the beginning (do it as late as possible), to avoid the additional work and prevent introducing “blocking” requirements.

E.g. you removed the bottom of a car model as it is not planned to be shown in the game.
Later you want the car be able to flip … but this would show the bottom.
You triangulated the terrain … to avoid conflicts between visible and physical representation … But triangles makes it harder to edit the terrain.

My advice is … to finish parts of your game … then “optimize” where there are no obvious side effects … then do that again on finer detail.

My practical solution is to find the crappiest pc you can put your hands on and try to make the game run on that. I have a dedicated notebook for that, if I can get a somehow stable 30fps on that I can pretty much guarantee it will work at 60 on all pc.
For the engine, I found out that the amount of polygons is not really that important, the key is trying to keep the polygons in one mesh with one material, If you have to use a bigger texture, it’s fine. Because the engine uses frustum culling on objects, it also works if you split the scene into regular blocks, so that the renderer can avoid drawing what the player is not looking at in a predictable way.
Lights and shadows really kill the framerate.
Always check out physics, if there is a dyamic stuck inside a static everything goes down the drain.
I never had any problem with scripting unless you do math computations, that’s not really advisable. But you can freely create lots of class instances and and jump all over the place with function calls, it won’t be a problem.
That’s for low end systems.

I probably have the crappiest (sp?) PC for gaming there is.

I break large mesh into smaller chunks, and put them on an inactive layer, and spawn them when needed. Then end them when not needed. This way I can get between 60-fps and 30-fps, with fairly decent texture. I parent all object (furniture, items, pickups, etc) to that mesh so it all loads at once with just one empty to spawn it.

Also when I copy an object I use ALT-D, not SHIFT- D where I need many copies.

I also spawn and end lamps where needed.

I also use occluders to block large mesh, but sometimes it don’t work.

Looking forward to hearing from others.

what about sounds?
are really CPU wasting in games as shooter.
that is a simple solution

# NOTES : to use only for little sounds (gun shoot, explosions for little file as ogg, wav) music 
# big files due problem with RAM

import aud


def bufferize_my_actuators_sound(cont): # <- always (no pulse,just in the first frame) 
    gob = cont.owner
    gob_name =
    for act in [a for a in gob.actuators if hasattr(a, "sound") and a.sound]:
        factory_id = gob_name +
        if not factory_id in ACTUATORS_BUFFERIZED:
            buf = aud.Factory.buffer(act.sound)
            ACTUATORS_BUFFERIZED[factory_id] = buf
        act.sound = ACTUATORS_BUFFERIZED[factory_id]

after that you can run the actuators normally, but without lag!
PS: this MUST be a module(no script)

I had heard that if you have a few large obnects, rather than a bunch of smaller objects, that can help your game run faster. Can anyone confirm/explain this? I haven’t been able to find much on this topic.

I think this is because all the properties of one mesh are applied to the big object rather than applying many properties to all the small objects.

it is because each object gets a seperate render draw call,

joining the meshes makes it send all the data in one call, rather then many,
however this makes LOD for the object hard if it is to large,

The best thing you can do, is if any objects are appearing on top of a tile of ground, join them to that tile.

With LOD you are manipulating the vram

with libLoad And libFree you are manipulating ram

camera draw distance also effects performance.

If you want a large infinate world,
you are probably going to want to use libFree and libLoad,
but it crashes if you use it with texture caching turned on.

if you load, unload, then load a object.

I’ve seen libload mentioned a lot, but what is it?

load a scene or mesh from a external file.

Ah, okay. I’m sorry for the idiot questions, but how much can it improve performance, and why?

by removing objects from the ram, when not needed.

for instance you leave a castle,
when you get far enough away, you can unload the inside of the castle.
also, when a object is removed from all calculations, like Camera , physics , logic etc.

Would it cause a huccup when you get close enough to load the inside? I get a hiccup whenever I go to a new are in my game, and I have no idea why.

How can i load a scene from a external file? From “add overlay scene” or something else?

For 0.2x releases, there is the LibLoad function which allows dynamic importing of objects at run-times.

0.3x release's LibLoad is relatively still broken due to compatibility issues, however, it's been proven/shared you can still workaround that by making a custom import system with BPY for dynamic usage.
1 Like

you use bpy to load a object and then scene.convertBlenderObject() to wrap it in a game object for ‘libload’ in 3.0

1 Like