Your big D'oh moments when working in the BGE.

Game Engine Game Engine Support and Discussion
1

And I mean you’re working on something, something goes wrong, you try to fix it for hours only to find out the solution was simple.

Personally, I’ve had too many to count, sometimes to the point where I question myself if I’m really meant to do any coding in the Python API at all.

For example, a lot of initial code I write to solve a problem or add something to a game starts out as this big complex mass of code with the idea to get it working and then work on simplifying, only to find out I do not have the solution until after I simplify to reduce the overall possibilities where the problem could occur and something that goes from several ‘if’ statements down to a few lines of code.

And just this evening, I got something working as I designed it in one of my projects, then I thought I did something that pretty much broke the whole system even though I did only cosmetic changes to the code like adding comments since I got it working. I mulled over it for about an hour when I found out the entire problem was that I set a property value for a couple objects to zero (which they shouldn’t at first), to see if something else was working properly.

Sometimes after those things I feel like an idiot and that I actually am no good at all in developing complex game systems due to all the times I fail before getting something that actually works.:spin:

So list your biggest game development D’oh moments here.

2

Ahaha - You’re not the only one, man. Pretty much any time I come to a project after a little while, I mess up code somehow. Even my own Sprites module confused me a bit when I was trying to use it - turns out there was a bug that kept initializing the variables and prevented the animation from playing. These kinds of moments can be what keeps people from coding, but the moments when you figure out how simple the problem was and laugh at it keeps you going.

3

Welcome to the programmers club ;).

Yeah, for that you need to check out your tools and styles. There are some pretty good best-practice guides out there showing how to avoid such problems. E.g. Never add testcode to your sources. Have them always in separate files.
For Python you should read the PEP 8, which is a quite good guideline on the basics.
Look for refactoring! You might need it. Look for tools that support it. (Untforunatly I can’t recommend PyDev)

And the golden rule:

Keep it simple!

If it is to much -> split it
= separate the code into multiple independent modules

Here are some hints I learned last year:

Rather to use comments (which might by just incorrect or will be incorrect in future) - use functions with a descriptive names.

Do not add a comment to things that are obvious


#import GameLogic
import GameLogic

Comments are usually badly maintained and do not produce errors when incorrect.
This rule does not apply if you want to teach someone. But you need to carefully maintain your comments.
In some cases it might be better to add doc strings. Doc strings are part of your documentation if you create one.

If the function is to long for a page = to long for a function =-> split it (ok I do not like this hint :wink: so much).

Rather to use a lot of nested if/loop/while statements:
Separate the code into functions. As more nested code = as more complexity at your code.

If you do security checks at the begin of your code, better return rather than continue with a large nested code block that has no else block and does not continue:


if sensor.positive:
  ... do something fancy here ...
nothing more

better


if not sensor.positive:
  return
... do something fancy here ...

(this does not work if you have an else!)

I hope this helps a bit

Oh and here is my frustration story:
I was fiddling around with matrices since weeks. I though I know about them, but reality said “no you are a fool”. Finally I discovered, it was working all the time, I just looked at the wrong place :o. Where is the wall to bang my head against?:no:

4

Well, I had to restart my project thousands of times (for 3 years, I basicaly restart it every month) in order to optimize it or because I changed my mind on how it should work or because a script goes rebel! But in most cases the whole system is wrong! The problem is in our way of thinking! We forget about all the baby wheels we put around the project(script) and after it interferes with the whole thing! My solution to these problems is to write down a progress/brainstorm note, to keep all the objectives and the auxiliary changes made to accomplish certain goals. One can only focus on the final goal…

5

I spent 10 hours straight trying to write code to display a logic brick. By the end of it I couldn’t think, or even see straight, but it worked. That code became obsolete a few weeks after I finished it…

As to actual D’oh moments, I can’t recall a specific one, but they are very normal. I guarantee you I have one in every project I work on.

6

well, this happens to me also many times.
I just rebuild a whole Programm(commercial gamble) for the third time, because i didnt know how it works…
I had plenty of comments, but after a half Year, i couldnt get it run as it should…
Sometimes rebuild it from the beginning can be helpful, specially if you have to many Funktions and loose the plan, what actually you did.
The more you know, the more komplex tasks you will be able to programm.
So never give up:no:

7

Its Specularity for me “WHY IS THE FRAME RATE DROPPING SO BAD IF I STAND IN THIS POSITION?!!?!?!” this was a real problem to troubleshoot when dealing with multiple rooms. Keeping on top of the rasterizer is a full time job for me. But during the process of trying to figure it out i was Chopping code, Disabling physics, detaching logic bricks, only for it to be the small element that makes things shine :slight_smile:

Ive restarted my project a few times because of this. since 2008. Like a ping pong ball ive been switching engines a lot, but realized Blender has everything i need to get the job done, Blender is like a high maintenance woman. lol

8

Well, my actual D´oh moment is when I move close to light with shadow and framerate starts to drop smoothly. Removing shadows did the job for now.

I think I should find a way to enable/disable shadows in runtime so the lighting could look better at least on stronger PC´S.
EDIT: I have a .cfg file that takes care of some settings already

9

@Bigbob - That game looks pretty interesting. It’s a bit dark until you get to the disk, and I would personally set the disk to be flat-shaded, rather than smooth. As for the framerate drop, I think that it might be usual for older graphics cards to slow down when rendering more of a scene (mine slows down on getting closer to advanced graphics too, though not necessarily shadows).

10

Thanks for the disk shading tip, fixed :o) … Darkness is a part of level design. In next level, player is given a gun with lamp.

about FPS drop, I accidentaly left the light object static, that was partialy causing this slowdown. It is still there but its not as noticable as before.

11

I just added a few moving characters into my scene, and noticed a hefty fps drop.
After replacing all textures with a smaller version, I was disappointed to see my fps hasn’t risen.
I started fiddling around on sensors and python code, just to realize a few hours later that armatures are expensive as hell in bge.
Things got a little better after lowering IK iterations, but I’m still having performance issues :/.

12

My Big D-oh moments are as follows! :stuck_out_tongue:

stupid errors in python, like missing ()parenthesis on the end of def statements, regularly.

I once spent around about a day trying to figure out why a single line of code was executing. It was a typo :@

13

I spent quite a few hours over the last week trying to fix a problem in my code that was destroying an entire feature in my game, only to have someone add one line of code and fix the entire thing.

14

Biggest d’oh moment: when I forgot to connect a few logic bricks. :spin:

15

Big D’oh! moments are a regular thing for me.

The biggest was working on my ragdoll addon in 2.49a and then starting again in 2.5x. I spent weeks trying to get it working and finally managed it! Only to find that with the inclusion of bone constraints in the game engine, all of my most difficult work was unnecessary. Hahaha. :smiley:

The result of this is code that would achieve a similar game runtime result in 2.49a as it does in 2.5x with very little performance decrease versus 2.5x (this really surprised me, I thought that it would run much faster without my hacks), but to actually get skinned game ragdolls working in 2.49a would still require a bit more work.

Never give up, never surrender, and read the first line in my sig. :wink: