Ive noticed that print()ing large amounts of data to the console slows the game down. Does this also apply to when Blender reports coding errors to the console? In other words: should I address EVERY SINGLE bug in my game in order to increase performance? Including even the “un-noticable” bugs? Or does BGE disregard these bugs when exported as an executable? By the way…im about to launch my game…follow me guys
DO NOT ignore console errors!! even if you have to post a “Known Issues” section.
python is a special thing, it doesnt require to be compiled, so that means it can half work. running in standalone wont help at all, in fact, it could make it worse. most languages require you to compile the code first, which means you cant even start the program until all the bugs are out.
each time an error occurs, that script will STOP, then start again from the top next frame. leaving these unattended will cause unexpected behavior or new bugs which will be harder to find. in bigger more complex projects, one error can cause the whole thing to come crashing down long after the error occurred. also, bugs can be used to exploit the game, no matter how small.
most errors can be fixed with an if-then statement. ill be happy to help troubleshoot and debug.
to answer your question, yes, errors can have a pretty serious impact on performance. each time an error occurs, python tries to figure out what went wrong and tell you about it in the console which eats up processing time.
That’s what I suspected. The Unity Engine wont even compile a game if there is a single error. Even without doing a “bug-sweep” my game still runs pretty good. So I’ll try to not lose too much sleep over it. But I guess I’ll be up all night injecting try: and except: statements into my code. Thanks again for the input man!
I advice checking before rather than try/except. Particularly for dictionary/list lookups (which is probably where your code currently fails). Check list length, or use “if ‘key’ in some_dict” rather than waiting for it to fail.
Try/except should be used when you cannot know if an action will fail or succeed (such as receiving from a socket, writing a file).
squah those bugs…even if they do not ‘seem’ to interfere with gameplay…they will impact performance, or cause secondary bugs that will confuse the parser(or whatever :)) and you may not see errors for secondary bugs and those could lead to bigger problems.
Thanks for the advice guys. I almost have all the bugs addressed and am about ready to launch!!! Please subscribe lol
Please be aware - in Programming there are different types of errors:
Compile errors - As the compiler does not understands your code it can’t generate machine code = no application to start
Runtime errors - This happens while the process gets into erroneous state while running the code. If not told otherwise the execution leaves the current code block (till it exits the process).
Logical/Business errors - This is behavior that is not supposed to happen. Typically they can’t be detected automatically. You just wonder why things happen that you do not expect (or vice versa).
Within the BGE the difference between compile errors and runtime errors is not always visible as the compile starts while the game is already running.
You should always care about errors. When the console prints an error it means this is an error you do not expect. This also means your game is in a state you can’t be sure about. E.g. was a point counted or not?
You should never just catch errors that you do not know about (= all errors) unless you are 110% percent sure you know what you are doing (e.g. establishing an alternative error handler).
This means a pure “try:…except” without a specific error type should not be in your code. If you do it you hide the fact an error occurred without dealing with the specific situation [Not looking at the console window does not mean there is no error - you just do not know about it]. More worse the problems that will arouse due to the error will still be there with all the unexpected results. But you have no idea why you get this results. This makes support really really hard.
When you get errors you have several options:
- You review your code ensure this situation will not happen again (code change)
- You turn the error into an expected error by catching the specific error and ensure the process remains in a valid processing state (e.g. by closing a file).
- You modify the environment that the error will not occur again
To answer your question: when you have errors … performance is not the number one priority anymore.
I understand. Thanks for the added verbosity monster
+1 do not try/except unless absolutely necessary
a game without bugs are impossible yet ALL bugs must be squashed asap, unless you wanna purposely launch a buggy game …a trending act in modern AAA industry …mass effect, fallout, ffxv asssssssin creek…