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
================================ Physics:
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
================================ Scenegraph:
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)
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…
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”
@ 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. )
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!
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?
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.
)