The Raw Numbers + Future

So it has been a while since I’ve done the raw numbers. Here they are:

Marble Maze Game: 6528 lines of code
Maze Editor: 7482 lines of code

So what’s next on the agenda? I would like to tighten up the logic used for deciding which target the Whirlygig will pick. I will be making it so the Whirlygig can slowly stop at the target coordinates. (This will help it not fall of the edge, and look a little more realistic.) I need to get a death sequence for the Whirlygig (fade away).

Once the Whirlygig is all set I will most likely move onto the Editor portion. There is a lot of Editor work that needs to be done, and not just for adding enemies. In order to get the Special/Props system I want, I’m going to have to rework Specials so they are more like Widgets. In that they can be rotated by the user, show up on the map faded until placed, and be larger than 1×1. Once that is done, there will be a lot of cool possibilities with props and moveable objects.

Props are just static models that can be placed and will give character to a level. They will all fit into a predefined “shape” category. For instance, in the jungle theme there will be a prop which is a “mound shape”, that will be textured like a boulder. In the snow theme it will just be a mound of snow the marble rolls over.

Moveable objects will be used for particular physical puzzles. A large box type moveable can be placed near a trench, and dropped inside to make a bridge. A thin/wide moveable can be knocked over to be used as a bridge, or when leaned against a short wall, used as a ramp. These are typical in many marble games so nothing new, but it will be fun to play with nonetheless.

The Whirlygig Is Born

I recently had another soul-crushing bug on my hands that I did not know how to fix, so I scrambled for a workaround. Instead of getting depressed for 2 months and ignoring Marble Maze for the duration, it only took me 2 days to shake it off and find a way to make it work. But if I couldn’t make it work this would have been a deal breaker, for sure. Probably would have made me go to 2D development where everything is under my control, and makes sense. 🙂

Basically I had a concept of the physics engine representation of the Whirlygig models, and it took about a dozen iterations of trial and error before I found something that works. Here were some of the major stages of the race…

  • A convex hull collision with an upvector joint, and using impulse forces to push the model around. This had serious performance issues (too many contact points, I believe?) and I could only have about 20 models running at any given time on my fast PC. Bounce collision with the player was not consistent, either.  No good.
  • A sphere collision with an upvector joint, and using Impulse to push the model around. This had less performance issues than the previous attempt but the model would jump around a bit and cause problems. I also received random issues where all of a sudden a physics object would have position/velocity of 1.#QNAN (yes you read that right). It caused the object to disappear from the world. It also happened to the player marble which is the most bizarre thing of all, and the player would be treated to a black screen stuck inside never-never-land. This 1.#QNAN is some sort of floating number corruption that is caused by divide by zero or negative exponents, or something. Google it, it freaks me out just thinking of what inside the wrapper or Newton DLL that could cause this.
  • A sphere collision with no upvector joint (thinking that may cause the corruption) and using Impulse. The 1.#QNAN issue still happened. By then I was getting very frustrated.
  • A sphere collision with no upvector joint, and using actual Forces instead of Impulse. This made the collisions skip all about and behave kind of weird. Still got the 1.#QNAN problem too.
  • A sphere collision, no upvector joint, and use Omega forces (just like the player) to move the sphere around. Bingo. We have a winner.

So what caused the 1.#QNAN ? I still have no clue, and I hope I don’t ever see it again. It is obviously some memory corruption of some kind (wrapper or Newton, I wouldn’t know) and it was extremely random.   A problem with using Impulse/Forces on too many objects?  Sometimes it would happen to the player marble as soon as a the Whirlygigs began to move. Sometimes it would happen part way through. Sometimes I could run the level of 25 Whirlygigs bopping around for 5 minutes before some of them started disappearing, one by one. It is maddening!

And thus my struggle with programming a complex system which utilizes 3rd party software that I can’t really get into or debug.

Having models represented by spheres in the physics engine will work for a majority of the enemies planned, but will not work for some of the more interesting ones, such as the flip-truck and the slimey oozes.  I’m not sure how those will be handled or if I’m stuck with a rolling sphere for everything.

But it seems to work now, no major bugs.  It doesn’t work perfectly: I eventually want these Whirlygigs to slow down and stop on a dime.  And sometimes the Whirlygig thinks it shouldn’t move when it should.  But it works.

So to celebrate I posted a few videos of the Whirlygigs!
Whirlygig AI
100 Whirlygigs

Stressing the Whirlygig

So whenever I add a new component to the game engine I like to stress test it. You know, push it to the limit and gauge the results. So after plugging in a bare-bones Enemy system (copying some stuff from the Widget system) I decided to add 400 Whirlygig models (animated via rotate limb) to the game engine to see how they fared. They did pretty well from what I could see.

If this were not a test, the player would probably be in a heap o' trouble.

Don’t get too excited, the only thing these guys do is sit there and spin. Nothing happens when you touch them (except normal collision) and they don’t move at all. They just sit and animate. This will probably be the only time 400 enemies will be on a level… once the movement/AI is put in another stress test will be done.
I’ll be working on the game engine for the next couple of weeks to flesh out these little guys and get them moving on their own. After my hard-coded enemy placement is complete and they work well in the game itself, I will then make them available in the editor. Which hopefully won’t be too bad… but I have hoped that before. 🙂

Welcome the Whirlygig

The Whirly Gig

All hail the powerful Whirlygig!

Today I have finished the model for the Whirlygig, which is the first enemy I will put in the game. I think it came out okay according to Funcy Standards. I took a basic cylinder and shrunk/expanded the scale at various heights to make a type of stumpy, glass shaped object. Hey, if I ever make a 3D RPG I will already have a model for the health potions! 🙂 The fan blades will whirl around (hence the name) when the object moves across the floor. This is pretty much a steal from the enemy Peahat in the 8-bit Nintendo game “Legend of Zelda”. I hope nobody minds…

There are at least a couple types of Whirlygigs planned for. One will move randomly, stopping and starting in random directions, ignoring the player. Another kind will always move toward the player if the player is in its vicinity which is a little trickier to avoid. It may also move faster or more often as well.

On related news: Despite lack of updates, work has continued on the marble game in other areas. I am close to finishing coins. The coin behavior will be the same as gems… roll over them and they rise and shrink into nothingness. It’s an easy trick to do on an object.

For the short term I need to finish the coins, place enemies in the editor (which shouldn’t be too bad), and then I will start on the enemy system in the game itself!

A Second Eagle Has Landed!

The second Alpha version is out. This includes camera/simulation speedup (based on feedback, game is too slow), gems, restart points (another request), and some bug fixes.

You can get the latest here: