Is it possible to use too many logic bricks in BGE? In a very complex and large game is it wise to mix Python with bricks?
I’m no pro at blender, but I’ve used Python in games before. First off, I am fairly certain logic bricks are done in python. I also know that python is not fast. BGE does a great job at optimizing it, but too much logic will eventually bog you down. I heard somewhere that the logic bricks are more expensive computationally than a script, so if you plan on using a lot I would try to script as much as possible. There are loads of articles and tutorials out there explaining how to best use python for the least amount of overhead.
I’ve already written a couple scripts for testing (I’m literally just getting started with Blender and BGE) and when I TRIED to break it I only ever saw just about 40fps loss. All things considered that’s really not bad at all.
My advice: Knock yourself out. Do whatever will get your concept out the fastest while keeping in mind ways to reuse logic where you can, or “fake” logic using the BGE engine (ie physics). IF you run into trouble, go back and adjust what needs fixing. There’s something to be said for doing it right the first time, and there’s also something to be said for not spending an eternity on one project.
That was probably a lot more words than you wanted, but there you go.
It all depends…
Yes, you can have too many bricks. You have too many bricks when you open the blend file tomorrow, and can’t figure out how things work. This usually is a long time before they make a dent on processor time.
It is wise to mix python with logic bricks.
Python allows you to do complex things more simply. But it also allows you to do a lot of things that you couldn’t otherwise do, and with those extra things, comes extra computation time.
In my current game, I’m simulating all the forces on a hover-car with reasonably physics accuracy (with a python controller providing drag, electrostatic repulsion etc). It is consuming nearly 10% logic for a single vehicle. I could have achieved a similar looking/playing effect with much simpler logic bricks, and with much less processor time. But then I would be constrained by physical accuracy.
Programming is always a trade-off unfortunately.
That’s actually incorrect; logic bricks are part of Blender’s source, which is all C / C++. So it’s better to do simpler tasks with logic bricks, and use Python for the more complex.
Also watch out for iterating through all objects in a scene. Those can easily become time-consuming.
This is very easy to do. But you can have to much of everything not just logic bricks.
Therefore you need to figure out what works good in what situation.
Not just in large and complex games. In all games it is wise to consider all options you can get. This is one reason why I’m not a friend of the “all in Python” fraction.
The logic bricks are there because it is incredibly easy to establish logic. They are fast, they come with a GUI. They give your logic design a fixed structure. They are meant to be used for the 90% of the easy work to spend 10% of your time.
But the remaining 10% require a more flexible and dynamic design as it will not fit into the structure of logic bricks. It will eat 90% of your time. The Python brick will satisfy these needs. As it is a brick it perfectly fits into the overall structure.
Bricks and Python are your tools. They are not the source of design problems. Usually it is the design itself ;).
Running 20.000 game objects with logic bricks at the same time is not a good choice.
Running a single game object that manages 20.000 game objects at the same time with Python is not a good choice either.
Most-likely 20.000 separate game objects even without logic are no good idea.
as sayd the bricks here more fast to do the same task vs python .
python cost when you simply run it and write 1+1.
with python you can do things potentially heavy (usually some loop) as find object or loop a mesh, brick simply cannot.
you have to be a bit more aware about what you do.
on the other side, you have more control with python and is more easy cut at the “root” a lot of calculation.
ps: i agree that a lot of object here not manageable as performances, you can do “big game” but never have billions of objects at the same time.