Category Archives: Loop Dipole and the Chaoties

My current project – a 3D racing and puzzle game built with the Blender Game Engine.

Legend of Hondo is Dead! Long Live the Commodore 64!

Life is full of compromises and choices. Given that my time is not infinite, I have chosen to focus my “nerd hobby time” on working with a single computer, the Commodore 64. As a result, here is where my previous projects stand:

Side scroller web based game
Will be finished in 2018-2019. Once finished, I will package it as a native application, using NodeJS, for Linux and Windows. Even though it will not be released as a Chrome App for Google Chromebooks, as it was originally intended to be, I am sticking with the goal of having it play well on a low-end Chromebook (instructions will be provided on how to do so).

Legend of Hondo
Star Wars Galaxies Emulator server mods
Will not see further development. Last fall I was working a huge branch related to Bio-Engineer, which would have been finished were it not so tedious to make BE pet versions of some animals – I bit off a giant chunk of work that I just don’t feel like doing, but the rest of the features for that branch were finished. The plain truth of the matter is that I don’t play the game and it takes way more time/effort to develop it than I want to spend on a game that I don’t play!

Loop Dipole and the Chaoties
Blender Game Engine
Game play wise, it wasn’t fun and that really disappointed me so I took a step back from it for a couple years. BGE also proved to be overwhelming to work with after the project grew beyond a certain level, so I will not be finishing this iteration of the game. However, the initial concept of “go fast and have fun getting there” and the rest will be the basis of a game that I make for the Commodore 64 once I have become skilled with Assembly language.

Rescue Girlies
SDL / Supertux mod
I have not updated this game since 2014, just as I said I would not when I released the custom GPL version of the game. It was a “one off” game that truly I made only for my kids, but I released to the open source community as a way to give back some of my knowledge. Play it if you’d like or study the differences between it and SuperTux 0.3.3 for an idea on how to make such mods.

World of Warcraft Server Emulator mods
Yeah, I don’t really play this one either, so I haven’t bothered working on it in about a year now! Wrath of the Lich King era was the best, but it’s kind of boring to play solo. That said, the TrinityCore server code base was a pleasure to use!

Tux Time, by Fives
Web based educational game
I really wish I finished this game, but for a while there my girls did use it on the tablet to help them learn how to read a good old analogue clock. All that is missing are the voice overs and the sound setup, so I will post the source on Github, but I will not be developing it further.

Torchlight II Mod
I occasionally play Torchlight II and when I do, I use this mod. It still works and I’m content with its features, so it doesn’t need any further development. Along those lines, Torchlight II itself, with the handful of mods I have downloaded, is also fine the way it is so I won’t be creating any other mods for it.

Music Production
Sunvox and Impulse Tracker on PC
I don’t spend a lot of time tracking music anymore, but I will continue to do so when the mood strikes. The sound produced with these systems is completely different than what I will be creating with the Commodore 64.

Electronics Hobby Computer Prototype
Arduino UNO programmed using a Raspberry Pi Zero
I very much would like to build this prototype, but it seems like a frivolous use of our limited discretionary funds and it likely will not be produced. The major expenses are a basic “ten keyless” usb mechanical keyboard ($35 CAD), the 4″ LCD display ($40-$70 CAD), and misc electronic bits (??$$ + shipping…). I estimate the prototype would cost about $200. If I can scrape together the parts, I’ll totally build this a little bit at a time as a proof of concept, “just because”. 🙂

I would like to thank everyone who encouraged me to work on these projects over the years, especially the supportive folks in the SWGEmu server modding community and the world of kind people who contributed to the open source projects upon which my own projects were based.

My game plan for the future consists of the following,

  • Work through the Commodore 64 Programmers Reference Guide, using a real physical book even!
  • Learn everything there is to know about the Commodore 64 hardware and software!
  • Share my Commodore BASIC programs on GitHub in text format.
  • Share my open source games/software in disk image format using Google Drive.
  • Learn how to program EEPROMs and make cartridges.
  • Make a game that is worth selling and distribute it on cartridge – how cool would that be!
  • Try to make an Arduino UNO compatible electrical system that can be programmed using BASIC.

If you’d like to listen to me talk about this sort of thing for 24 awesome “stream of consciousness” minutes, have a gander at the video below! If not, suffice to say that I am making this change of focus so as to get the most return on my “time spent doing things” investment, while also increasing the likelihood that the things I create may actually be of use (perhaps even after I kick off and walk the stars!).

Dev Blog – Major Milestones, New Character Models, and More!

I guess the reality is that if I am typing something for my website site, then I am not working on the game! As such, the only updates I have shared in a while have been some quick posts on Facebook, usually showing off a screenshot of some sort of nerdity.

Today, I don’t have a lot of time to write this post, but I thought it would be nice to share that I have completed the layout of the terrain and road system for the two largest areas of the game. I’ve also finalized the player models, added a seventh shape at the request of my kids (it’s a slow, easy to drive car), made a ski jump, significantly improved my python code structure, made the saving/loading of player stats work again (though it still doesn’t really save/load anything useful), added a screenshot system, started on the special models that represent the Fountain Puzzles, and a whole whack of other things! Many hours pla… I mean “QA testing”, learning, and iterating as well.

With that in mind, I’ll take a few minutes today to share some captioned screenshots of some of what I have been working.

Bottom: First revamp. Top: Total remake.

Bottom: First revamp. Top: Total remake.

Thinking... :)

Thinking… 🙂

Made me a skybox.

Made me a skybox.

And here it is!

And here it is!

The set of road parts that I created to the road system.

The set of road parts that I created to the road system.

Testing to determine why the character would get stuck on 90 degree walls.

Testing to determine why the character would get stuck on 90 degree walls.

Turns out it was caused by hitbox behind inside the wheelbase. The wheel would get caught on the other side of the wall.

Turns out it was caused by hitbox behind inside the wheelbase. The wheel would get caught on the other side of the wall.

After trying several hit boxes, this convexed hull performed the best.

After trying several hit boxes, this convexed hull performed the best.

Many physics tests went into production of this shape. It almost never fails a physics check, even at crazy high speed.

Many physics tests went into production of this shape. It almost never fails a physics check, even at crazy high speed.

Something is on Tux's mind! :)

Something is on Tux’s mind! 🙂

Remember those ball popping toys on wheels, with a handle that we had as kids? I made a room like that, "just because". I'll optimize it and give it a purpose later.

Remember those ball popping toys on wheels, with a handle that we had as kids? I made a room like that, “just because”. I’ll optimize it and give it a purpose later.

Castle inspired by one my kids and I made a few years ago out of paper mache.

Castle inspired by one my kids and I made a few years ago out of paper mache.

Screenshot at 2016-02-12 15:59:27

Screenshot at 2016-02-12 17:33:49

CN Tower will be one of the fountain puzzle land marks.

CN Tower will be one of the fountain puzzle land marks.

Making low polygon things in Blender is a lot of fun!

Making low polygon things in Blender is a lot of fun!

Tada! Still was not finished being OCD about its scale and proportions.

Tada! Still was not finished being OCD about its scale and proportions.

Can't have the CN Tower without also having the Skydome!

Can’t have the CN Tower without also having the Skydome!

This proved to be tricky to make look right, despite it's simple looking shape...

This proved to be tricky to make look right, despite it’s simple looking shape…

Not perfect, but you get the idea!

Not perfect, but you get the idea!

Besides, this is how all of the fountains will be textured! lol...

Besides, this is how all of the fountains will be textured! lol…

Chalet style building.

Chalet style building.

There are probably better ways to make models than by placing individual vertices, but... meh, this is "my speed".

There are probably better ways to make models than by placing individual vertices, but… meh, this is “my speed”.

Screenshot at 2016-02-13 14:06:11

I think this is the final model. I may have further scaled down the door later...

I think this is the final model. I may have further scaled down the door later…

From blank slate to....

From blank slate to….

Screenshot at 2016-02-14 17:40:20

Screenshot at 2016-02-14 18:57:05

Screenshot at 2016-02-15 01:42:02

Downhill run, "hill climb", and ski jump! This isn't the final iteration, but it is complete now.

Downhill run, “hill climb”, and ski jump! This isn’t the final iteration, but it is complete now.

Making the muscle car way better!

Making the muscle car way better!

And adding simple paint jobs.

And adding simple paint jobs.

Screenshot at 2016-02-16 21:45:13

The girls (my kids) said this guy was too hard to see, so that's what started my painting.

The girls (my kids) said this guy was too hard to see, so that’s what started my painting.

Further improved the default shape. Hard to believe that year ago he was little more than a green blob! lol...

Further improved the default shape. Hard to believe that year ago he was little more than a green blob! lol…

Tada! Big o'l pod racer / radial engine style nacelles.

Tada! Big o’l pod racer / radial engine style nacelles.

Starting a remake for shape 4.

Starting a remake for shape 4.

A cross between the Avro Arrow and a Z-95 (Star Wars).

A cross between the Avro Arrow and a Z-95 (Star Wars).

This was a fun challenge. Again, there are probably easier ways to model.

This was a fun challenge. Again, there are probably easier ways to model.

Screenshot at 2016-02-17 02:12:40

So sleek!

So sleek!

Screenshot at 2016-02-17 02:55:46

I was getting pretty excited (and exhausted) by this point.

I was getting pretty excited (and exhausted) by this point.

Screenshot at 2016-02-17 04:40:45



Shapes, shapes, everywhere are shapes!

Shapes, shapes, everywhere are shapes!

Screenshot at 2016-02-17 06:23:02

I've since cleaned up the bottom, rear of the model.

I’ve since cleaned up the bottom, rear of the model.

Screenshot at 2016-02-20 23:24:47

Looking neat

Looking neat

I was going for something British, cartoony... Shelby-but-not looking...

I was going for something British, cartoony… Shelby-but-not looking…

Screenshot at 2016-02-21 23:50:56

Almost right....

Almost right….



And here are all the "shapes" that Loop Dipole (the player/character) in the game can take. Each has different handling, abilities, functions, etc.

And here are all the “shapes” that Loop Dipole (the player/character) in the game can take. Each has different handling, abilities, functions, etc.

Dev Blog: I don’t do “Asking for help” so well…

Truth be told, I rarely ask for help with my projects, because it forces me to thoroughly understand the problems I face and, frankly, other folks have better things to do than answer my questions. I made all of Rescue Girlies without asking anyone anything – instead I spent my time researching the answers to my own problems. Crazy concept, I know!

Anyway, recently I decided to break with my hermit tradition and post a question on the forum. The question was simple enough, “Looking for a smooth, seamless way to keep a car on the road”, but the technical issues of solving it were quite tricky. Perhaps they were so tricky that no one answered or maybe… folks have better things to do than answer my question! 🙂 Either way, as usual I came up with a solution myself (no one else offered any). I guess I’m just that awesome.

Here’s a link to my post and here’s the actual content of the post, with the solution first for those who need a TL;DR…

SOLVED: I decided to go with just a “corner assist mode” that automatically drives the player around 180 and 90 degree bends, rather than gluing them to middle of the road all the time. And instead of having a cooldown, the player can simply choose to toggle it on or off.

I did this by making a set of 4 navigation meshes, left/right for each turn type, and moving them into position when needed and away when finished. The nav meshes have 3 triggers parented to them: Start Pathing, Stop Pathing, and Move Mesh Home. At every corner, I have placed a trigger that moves the correct nav mesh into place (they also have a parented trigger object that prevents them from firing from the wrong direction).

Doing it this way meant I only needed 4 total nav meshes (and their trigger groups) and by moving them rather than creating/destroying them, I didn’t have to concern myself with object name changes. Also, there are only 4 types of generic triggers to move the nav mesh into place, which means they’ll be really simple to add after I have finished laying out the whole road system. Finally, I chose to use collision and property sensors as triggers, because I figured they would trigger consistently and would be processor efficient (I’ll probably need about 200 corner triggers).

It’s not exactly what I wanted, but I think in the long run it’s probably a better solution, because it still leaves a lot of places where the player has to put some thought and effort into driving lol…

If you want to try it out or see how it was programmed, the project is and the two “shapes” that can use driving assist are enabled by pressing NumPad 5 or 6. NumPad 1 – 4 are gliding/flying type “shapes”. I put a little race track in for testing, so there’s something to drive on.


Howdy fellow Blenderers!

Sorry for posting a question, but I have been working on this issue for months and my research and testing have been unfruitful. I actually don’t like asking for help on projects.

Using the car logic, I have set up an open world driving game, where the player can drive anywhere, on or off the roads. Overall, the game works great, but I am having some trouble creating a “driving assist mode” for when the player is on the roads.

Driving Assist Mode can be toggled on by the user and while it is active, the player is essentially glued to a rail in the center of the road, such that it doesn’t matter how poorly they steer, they will always stay in the center of the road.

What makes this tricky to achieve:

1. The roads aren’t race tracks, where the player can only go in a single direction. Rather, they are more like real life, with junction points and the ability to travel in either direction.

2. It’s an open world, where there is stuff do when off the road, so the driving assist needs to be able to start from anywhere the player happens to enter the roadway.

I’ve already programmed tracking when the player is on or off the road and driving assist is enabled while while holding SPACEBAR. The trouble is, I have yet to program a method of driving assist that actually works! lol….

Here are some things I have tried:

1. Aligning the Y vector of the player to the local Y vector of the ray hit object (road). Works great on a straight line and in a single direction, but is totally useless for going around curves.

2. Dropping a ray down on either side of the vehicle and pushing the player back into the roadway when the left or right ray stops touching the road. This works ok at slow speeds, but it’s jarring and completely fails to work at any speed where it might actually be useful.

3. Added invisible guide rails on corners that push the player back when the “am I on the road ray” touches them. This worked ok, but if the player hit it at the wrong angle it would fling them off the road. Also, it failed at high speeds and was jittery looking.

4. Turning on guard rails to keep the player on the road by basically making them a “bumper-car”. The troubles with this are that the car tends to get jammed when hitting a 90 degree wall or bounce up when hitting a any obtuse angle. It’s also way more work and objects, while also being rather annoying to actually play with and totally not what I had in mind.

Some things I have considered:

1. I thought about making it a “cornering assist” only and putting a “path to object” (Steering Actuator) in both directions of every bend in the road. When the player’s “am I on the road ray” hits a trigger property, the player loses control and is sucked around the corner automatically. I think this would be effective, but it would be a lot of work to build. Update Feb 5th, 2016: I just pushed an update that shows this functionality in action (in one direction, for testing). It works, even moving the same navigation mesh and triggers around, but it looks twitchy (and did so even when I tried 900 faces around the bend lol…) This is probably what I will end up using – not perfect, but a workable solution.

2. Constantly spawning an invisible object in front of the player and having the player path to that object, then destroy the object and repeat. The trick would be programming the spawner to search for and locate the center of the road even on turns.

The nice part is that all of my roads will be built using track pieces, so the 45, 90, and 180 turns are consistently sized and shaped. Thus if I go with only corner assist, I can reuse the method for all corners of the same type (and it will still work once I merge sections of tacks together into larger objects to reduce overlapping verts).

Thanks for your time and consideration!

Dev Blog – Loop Dipole and the much better world design!

After taking a break from developing the game, I am back at it in Blender Game Engine 2.69 looping some dipoles and blasting some Chaoties! Alright, at this point the only thing to blast are some cylinders (spawned by pressing F5), but I have finally decided how to layout the game world in a fun way. That’s something.

“The good news is that the kids and I have a lot of fun just driving and flying around, even though that’s all there is to do at the moment!”

I have been batting the concept for this game around for five years or so and in 2015 I finally sat down and wrote a design document that covered all aspects of the game play. As with any project, actual testing leads to iteration and, most often, improvements upon the original design. One of the things that I quickly came to realize when building the game is that level design is an art form and making one that is fun to play on requires a lot of work to finish. Not only that, but having a large amount of physical space for the player to use doesn’t mean much if there’s not enough to actually DO in that space.

The gist of the “lore” behind Loop Dipole and the Chaoties is that the main character, Loop, is an energy being living on a cube of energy. He wants to balance the energy, by solving puzzles, and he has to fight/avoid the Chaoties along the way. Simple enough, but the devil is in the details.

The primary focus of the game is “Go fast and have getting there!”, so when it came to representing the 6 sides of Loop’s cube world, I was reluctant to use loading screens. I prototyped a rotating cube world, but it was nightmare to develop for and not worth it in the long run. So I then decided the player would use a nexus in the center of each map to travel between them and that was all fine and dandy until I discovered… maps are hard! More to the point, maps, just like race tracks in SuperTuxKart, need to offer unique visuals, locales, and game play in order to truly justify their existence. The more I tested, the more I thought about what’s important, the more I realized that not only are multiple maps outside of the scope of what I am trying to make, but they’re also a net detriment to the game play experience for the player.

Having to load into and then traverse a whole new map just to collect a certain type of energy seemed, to me, like a waste of… energy for both the player and myself as a developer.

When “going fast”, the player travels around a large open space collecting different types of energy. He uses the energy to manage his abilities and to solve the various puzzles. The puzzles are 2D games, where the player stops driving around and does “something else with his head for a bit”. I want the player to enjoy the large open area as well as the ability to fly and drive to higher levels, but I want this to be a fluid experience he does between puzzle sessions. Having to load into and then traverse a whole new map just to collect a certain type of energy seemed, to me, like a waste of… energy for both the player and myself as a developer. Not only would it break up the fluidity of driving, but it would mean that I would need to make every map either too confining (like the one I made in 2015) or so large that it would take me forever to fill it with awesome and likely drive most players to boredom. As such, I decided that Loop Dipole and the Chaoties will consist of one single, awesome level!

The level will incorporate all the “sides” I previously had envisioned, but they will instead be different vertical levels. The lowest level, which is really just there to look cool, is the chaos, while the rest of the levels ascend from red to violet. The player starts on the red level, which is also the largest flat area (noobish to get around, but also great for the slow turning “bomber” shape), and can fluidly travel anywhere he’d like from there. If he falls down in the chaos below, he can fart around there if he likes or he can press R to get back up to the red level and, you know, do something productive. Most importantly though, the entire game world will be both useful AND fun to travel around, while also allowing me to focus my efforts such that I may actually finish this game before the heat death of the universe.

Will you add more levels later?

No. Come on, man, I just said I am going to build the whole game into a single level! 🙂

Seriously though, think of Loop Dipole and the Chaoties more like a… a mashup of Star Trek chess, the “bestest Hot Wheels track you ever seen!”, and Bejeweled and less like your standard 3D PC game. As for the Bejeweled reference there, for the record I don’t intend the puzzle games to be clones of existing games. The puzzles will definitely be like games we’ve all played before though, cause I ain’t no Tetris Wizard.

Here, have a look-see at some development screenshots:

And if you’d like to play around with what I’m working on, you can find the project on GitHub and you can download Blender version 2.69. Later version of Blender have some quirks/issues in the game engine, so don’t use’em with this game. Note that when I am finished the game, I will package it with Blender Player such that it will work like any other PC game for Linux or Windows (Mac too, if I had one to test with).

As always, please respect the General Public License attached to my work (and the work of others who have also contributed to this project) by providing credit for any part of my work that you use in your own stuff. Thanks! 🙂

I’ve Taken a Long Break!

I tend to be obsessive about projects I am working, which makes working on something like Loop Dipole and the Chaoties the opposite of what I am good at in a way. Without distractions, I can toss concepts, variables, and whatnot up into the air and juggle them until I collapse from exhaustion . I think that is what all the great scientists of yore would do as well, build picture in their mind and live within it for as long as possible, because once there is a distraction it takes a long time to get back to that productive state of mind. In truth, I know that this is normal for programmers as studies have shown that a 10 second distraction can lead to 15 minutes of time wasted “getting back into the zone”.

Anyhow, I would like this project to remain an ongoing hobby for several years, in part to learn how to pace myself, but also to have something consistent to work at. Thus far I have failed miserably.

Let’s see, what was I doing with my “free time”…

I spent a bit over a month playing Guild Wars 2, giving it its “fair shake”. Great game, I like it a lot, but there’s just something about that fails to hold my interest. I decided to get back into working on stuff for the Tarkin SWGEmu based game server, mostly because I really like the people there and it’s fun to work on collaborative projects; working exclusively on my own game alone is very isolating. And, I spent a lot of time puttering around with my smartphone dilemma, researching and trying new things. Not really a lot of things, but damned if I don’t have the inertia of a neutron star – once I get moving on something, it’s hard to slow me down. Sadly sometimes that something is watching Star Trek The Next Generation on Netflix… Yeah, like that is a good use of my time!

So, I am learning and trying hard to find the right balance when it comes to my “free time” projects. Free time, for the record, does not include the time I spend playing with my kids and lounging with my wife. It’s strictly, “the time in which I CAN do something else”. For the rest of 2015 I am working on:

  1. Re-envisioning what it means to play on the Tarkin Server. We’ve decided to do something new that better suits our small population and development / customer service resources.
  2. Creating a video series explaining how to play on the Tarkin server. Star Wars Galaxies did an abysmal job of helping new and old players know what the heck to do in the game and it’s something that dramatically effects player retention in the first hour of play. Lots of people never come back after that first play session, likely because the default controls are clunky and the game does such a poor job of explaining what there is to do (and how to do it).
  3. Working on Loop Dipole and the Chaoties.

That is more than enough to work on, especially the Tarkin programming stuff, as it really challenges me to study and learn!

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!

Foley – It’s a Profession for a Reason!

Foley, for those who don’t know, is the name given to process of creating the sound effects that make up the “soundscape” for movies and television. Not exactly the same thing as creating sound effects for games, but the principles are similar.

“Ah, how hard could it be to make some sounds, Rob?!”, you say. Pretty damned hard actually!

Over the years, I’ve read stories about and watched videos about how sounds were made for movies such as Star Wars as well as television shows, so I have some understanding of the principles involved. However, creating sounds, either from scratch with a tone generator in a program such as Audacity, or by recording and modifying live sounds is easier said than done. The easy part is saying, “Well, I’d like it to sound something like ____ in ____ movie” or some thought along those lines. The hard parts are finding the starting point for that sound and figuring out what work needs to be done to make it sound they way you would like without having it end up sounding the same as what was in that other program. Particularly that last part, because it’s important respect others creations.

From a practical perspective, here is a bit of information on some sounds that I made recently for use in Loop Dipole and the Chaoties.

Files are hosted in the game’s Github here.


I made the base sounds for these by sloshing and clinking a metal spoon inside my stainless steel thermos that was partly filled with water (what a great Christmas gift from my wife and kids!). It was a neat sound I noticed one night when I making a cup of tea. I figured somewhere in there were some nifty sound effects waiting to happen, but after recording them (with my Shure PG48 microphone, Peavey PV6 mixer, and K-World TV Tuner’s RCA inputs) I found they were much more tinny and grating than I had anticipated. Not being a professionally trained sound engineer, I wasn’t entirely sure what to do about that, but I did my best to bring the sounds to life. Here is a bit more detail about each sound,

A really nice “clink/slosh” forms the base of this sound. I added an echo, some reverb, played with the equalization, and I *think* I used the “Paulstretch” or Change Speed filter.

The base sound for this one was same as shoot1.ogg. Any Star Wars fan would know this sound is a mimic of the spatial charges used by Boba Fett in Episode II: The Clone Wars. I added echo, used the Wahwah filter, and potentially other things I have forgotten, because you know a week ago was a long time…

This is a reversed, Paulstreched, echoed, and reverbed “clink”. I actually have my wife to thank for this cool sound, as I reversed the sound accidentally when I was showing her how Audacity worked and we both thought it sounded neat. I think that’s how a lot of these things happen.

I am quite proud of this sound. It’s pretty cool and I don’t entirely recall exactly how I made it. I tend to spend eons trying different things until I get what I am after. I do know that it is a Paulstreched “clink/slosh” with reverb. When you listen to it you could easily say, “how in the hell is that a clink/slosh?” and all I can say is, welcome to the magic of Audacity and a lot of futzing around! 🙂


These sounds were created by folding or hitting an 18 inch or so piece of sheet metal. hit.ogg and select.ogg don’t even have any effects applied to them! shoot4.ogg is a combination of a slower version of itself and a phaser filter.

In the past, particularly for the open source version of Rescue Girlies, I have created sounds by using just the tone generator and I have to say that it’s way harder to make something neat by just using the tone generator. Live sounds have more character and harmonics, plus it’s more rewarding to hear something in “real life” and say, “boy, that would be neat if…” and then actually DO that “if” at some point.

I look at some of the masters of sound effects and foley, such as Ben Burt and Richard Hymns (to name just two of many hundreds of extremely talented people!), and I can’t help but respect and admire their talent and dedication to their craft. While I am sure most people don’t really think about the “soundscape” of the productions they enjoy, the effects of sound on our culture are diverse and pervasive none the less. Everyone knows the sound of Darth Vader breathing and how many times have we heard someone mimic the transporter sounds from Star Trek in various other programs? Sound is everywhere and it takes a lot of talent to bring it to life in a production.