Growing Pains, Blender Issues, and Stuff Magically Working

I don’t know how game development is for anyone else, but in my experience there is always some inexplicable problem that magically resolves itself or mysteriously arises from the mist. One such issue I had since moving my Loop Dipole project to Blender Game Engine from SupertuxKart is extremely inconsistent collision detection on terrain. I researched the issue and tried many of the suggestions to remedy it, but nothing seemed to prevent the built in vehicle physics system from causing my player character to sail on through angled surfaces rather than going up them or bouncing off of them. It was the damnedest thing, because by rights terrain does work fine in BGE!

As it turns out, one day last week I decided that I really, REALLY did not like the “blocked out” layout I had made for level 1 (the level in which I am building and testing all of the game play systems) so I took another crack at making a terrain. First, I downgraded from Blender 2.73 to 2.69 (used in PcLinuxOS 64Bit), as 2.69 is the last official version that doesn’t break the BGE. Next I started with a plane scaled to 1,000 Blender Units, subdivided a few times. Applied the scale, pulled up a few verticies to make a hill and sure enough, the usual weirdness ensued – driving through the hill, driving off the edge of the hill and continuing on out into open air as if I was still on the hill. Knowing that terrains do work in BGE I sat back thought for a moment. Eventually my mind bumbled upon how video cards render shapes as triangles, so I selected all the faces of the plane and triangulated them (cut them in half on a diagonal, making the squares into triangles). Then it occured to me that there was a physics setting, “… something, something, triangle mesh…” so I popped over to the physics tab and sure enough I could set the “Collision Bounds” to “Triangle Mesh”. Next time I fired up the game, OMG IT ACTUALLY WORKED AS EXPECTED!

Tears of joy, tears of joy…

Turns out that I later unchecked the Collision Bounds box and the collision detection still worked properly, so that does not appear to be required. The really weird thing here is though, in the past I made triangle mesh plains and had collision issues! So… what gives?

From what I can tell, collision detection in BGE is based on frame rate. Testing this theory on my old Dell Inspiron 1501 laptop (dual core 1.8GHz Turion64 with ATi video), the new terrain I made, which works perfectly on my desktop (AMD FX8320 with AMD R9 270 video), still has the same collision detection problems that I was having before. Granted, I was testing using Blender 2.72b in Windows Vista Basic at the time, but still – this game NEEDS a better computer than my old lappy! šŸ™‚ However, that doesn’t explain why I was having collision issues on the desktop up until it magically decided to start working… ah well!

At any rate, collision detection being based on the frame rate is all kinds of crappy, because as a designer/programmer I now have to worry about giving the player the ability to drop his frame rate so low that he literally flies/falls through the level. One way to do just such a thing, even on my desktop system, is to make an ability that instantly throws 500 cubes at 90m/s. Yeah… breaks the world! šŸ™‚ But realistically, it’s not going to be possible for me to guarantee that the game will function correctly on systems with specs lower than the lowest I have to test with (Core2 Quad 8200 / Ati 5670 / 8GB DDR2), because I can’t really tell at what point the physics stops reacting to collisions. I know for certain though that Loop Dipole and the Chaoties will require an AMD or Nvidia video card that can handle GLSL (Intel’s PowerVR based graphics might work, but I’m not going to loose any sleep if it doesn’t).

On a different note, I’ve learned that Logic Bricks are an integral part of the BGE, which can execute commands faster than Python scripts, depending on what one’s doing. One really good example is syncing a “Shoot” sound effect with the physical ability when a mouse button is pressed. Sending mouse button presses to a simple function like this,

def example():
cont = logic.getCurrentController()
obj = cont.owner

# if variable = number, do ability
if obj["abilityLMB"] == 1:
# do something
# call the actuator that plays the sound effect
elif obj["abilityLMB"] == 2:
# do something
# call the actuator that plays the sound effect

will not, in my experience, play the sound effect every time the mouse button is pressed. There appears to be a delay related to how many times Python “ticks” happen per second. However, accomplishing the same thing with logic bricks and Python scripting solves the delay problem.

The Logic Bricks are setup like so,

State 1: Mouse Sensor (LMB) > And Controler > State Actuator to State 2
State 2: Property Sensor 1 (“Listens” for value of activeAbility) > And Controller > Sound Actuator & State Actuator (resets state back to 1)
State 2: Property Sensor 1 (“Listens” for value of activeAbility) > Python Controller (runs script that does the ability)

Functionally, this takes a mouse click, hops into State 2 where (in my case) 8 Property Sensors “listen” for the value of the activeAbility variable (1 to 8, depending on the ability the player is using at the time). If the activeAbility value matches one of the Property Sensors, then the next step is taken where sound plays, the ability is fired, and the state is set back to the beginning.

Quirky thing to have to do, but it works well to make 1 mouse click translate into 1 sound played and 1 ability fired. You can see this in action attached to the Abilities empty in the current version of the game. At the moment I have it setup such that both right and left mouse buttons have their own copy of the abilities, but later this week I plan on moving that into a multi state system so that the abilities won’t need to be duplicated (because WOW do Logic Bricks get complicated looking in a hurry!). That setup, my mind’s eye tells me, will look like so,

State 1:
LMB Click > Move to Stage 2
RMB Click > Move to Stage 3

State 2:
Property Sensors listen for activeAbilityLMB value and move to States 4 through 12, depending on the ability.

State 3:
Property Sensors listen for activeAbilityRMB value and move to States 4 through 12, depending on the ability.

States 4 through 12:
Each state has an Always Sensor that activates the desired sound effect and action of the ability, while also resetting the state back to State 1.

That should work to produce a system that performs the ability only when the correct mouse button is pressed, without having to have two copies of the abilities (one for each button).

Update: I’ve now updated the mouse button ability logic to new method I was describing. Thankfully it worked as planned! Two abilities are complete and I’ve bound one two each mouse button. You can press F5 to spawn some targets and practice destroying them now. Woo!

And finally, since changing to Blender version 2.69 I have noticed that the frame rate and other profiling information doesn’t show up in the standalone player when using the button from the Blender UI. Another quirky issue, as the standalone player in the official 2.69 package displays the info just fine when launched from the command line with the correct switches. Go figure lol… So… I made myself a quick link icon for my Mate Desktop toolbar with the following command:

/home/rob/blender-2.69-linux-glibc211-x86_64/./blenderplayer -f 1600 900 -g show_properties = 1 -g show_framerate = 1 -g show_profile = 1 /home/rob/workspace/LD-BGE/level1.blend

It’s a long one, but it works swimmingly! Hope that little tip proves useful for anyone else out there who is stilling using 2.69.

All that said, I am still keen on making my game with Blender Game Engine 2.69, because it’s a wicked awesome open source tool. With anything there will be ups and downs, so its important to try and work with what you have as much as possible – restarting a project over and over is a sure fire way to not finish it!