Category Archives: Coding

Topic for things specific to programming


In blog years it has been an eternity since the last update — 9 months ago.  I have been dabbling here and there, with not much to show for it.

Lost Wand mobile

Smaller dungeon means packing the fun into tighter spaces!

The current plan is to get The Lost Wand to market on the Android, to sit along with the other 1,000,000+ apps. :(  If things go better than expected (i.e. more than $0.50 a month in ad revenue) the push for Windows phones will be made as well.

Some sprucing up of the game is needed to make it more fun to play and a better presentation.  Here is a list of the things I would like to do, in no real order:

  • Smooth movement of character/monsters, walking & combat
  • Dungeon tiles fading in with movement
  • Health meters in combat, and at top
  • AdMob support
  • Ability to flee combat (experience penalty?)
  • New Speed stat will determine how fast you move + flee chance
  • Upon leveling you can choose Speed, Attack, or Defense bonus
  • Multipurpose button on bottom, to sacrifice gold, flee combat, stairs
  • Text which fades out, describing the action!
  • Achievements system (amassing gold, winning through combat or sneaking, etc.)
  • Better title screen, with scrolling icons to show what is what
  • Better graphics (?) , with option to “go retro!”
  • About screen with credits & a point to Monkey-X language

These items should not take very long to accomplish, really.  It’s a matter of motivation at this point.  I really need to finish this project so I can begin the next one (many ideas, haven’t settled on one yet).

Surrounded by the Enemy

I’ve made enemies available in the editor.  It didn’t take too long, I mirrored what is done for Widgets (i.e. duplicate code).  Since I always add new things to the game engine with the editor in mind, I simply had to start storing the enemy data in the Level file and bam there they were.

What’s next?  To finish off enemies for the beta I would like to work on types that chase the player, both a giant evil ball and a new enemy type that pushes the marble upward (think intelligent tornado).  I may play with some more moveable items and put in the ball, the box, and a wedge.  I’m sure some other shapes will come out of user suggestions or if I see the need for one.  I also have to make sure they disappear when falling off the level.

Really all the major pieces are in, what is left is fine-tuning, adding content, and some polish to the game.  Of course that could be another 2 years worth of work, easy!

Here are the latest numbers:
Marble Maze Game: 7159 lines of code
Maze Editor: 8101 lines of code


So a couple late nights of coding and I have some progress.  First off, I “fixed” the textures of the coins.  I didn’t put my ugly mug on them but that can come later. For now I have this simple star pattern I took off the interwebs.

Coin collecting ... will it have a purpose in the game. Purchase powerups inbetween levels, perhaps?

I was able to check off a few items on the to do list as well. I was able to finish the Specials reworking to behave more like Widgets in the editor. Specials now are faded unless they can be placed, with some being able to be rotated, and can be larger than 1×1. To prove this is working I made a Prop (static object) of a large “mound” which takes up 2×2 grid squares. Right now it has the texture of stone but really it could be anything.

Unfortunately I didn’t tweak Widgets enough to make some grand unifying design where everything goes through the same code to place/store items on a level. There is now a bit of code duplication, with more to come for Enemies. I was stressing about doing this, because I hate duplicated code, but the way I store the Widgets vs Specials vs Enemies, there wasn’t a nice way to do it in a general sense anyway. I could have called the same functions but put in a big select…case statement everywhere for all three types. Or I could have a large “Entity” data type that stored all the data for any type of item on the map. These are not quite worth it, in my opinion. Especially when I’d be stepping on code that is a few years old. If the language was OOP there would probably be a clearer path, but I just didn’t see it with what I’m using. Maybe I’m getting old. Or lazy.

I must say, like a kid who rediscovers just how good sugary soda is, I find it quite tasty to get quick results with several copy/paste/adjust sessions. I can see why code duplication and minor tweaking is so tempting under a time crunch. I still don’t like it, but I’m willing to live with it.

Hal 2

Well slowly but surely, we’re getting a decent Enemy AI system. The Whirlygigs can now stop on a dime.

Check out the video

Next up, zoning and raycasting themselves to stay safe. Right now they go right off a cliff like a lemming. Wrong game for that!

Hal 1

I have been working more on the enemy system, getting it to where I want to be. Most recently I made it so the enemies are aware when they are falling (under the level) and they disappear when they reach a certain depth below. Eventually I will have them fade out, but right now they “blink” out.

I have been busy with other things so not much marble development, but I have been reading fun books when I can…

Some light reading...

I use Finite State Machines (FSM) for many things in this game. So naturally I have put it into the AI code I have been creating. FSMs are easy to understand and build upon, but sometimes easy to get carried away with if not planned properly. So I am trying to sketch out some flowcharts of the various states the enemies can be in, and how they relate to one another. I’ll include a diagram of what the FSM for an enemy is once I have it all mapped out. Right now we have a rudimentary Wait->Active->Finished->Wait cycle written for the Whirlygig. It works out well and each enemy takes care of its own state.

I have done something which I think is interesting with the AI system. I have two controlling variables that [a] dictate how often I update the AI per second (cycles) and [b] how many enemies update per cycle. This variable system will be fairly helpful in determining a good balance for smooth updating throughout the second. In other words, we don’t want to update the AI for each enemy 100 times a second but we may want to spread it out and update 100 enemies once over the course of a second. This can be done any number of ways, either 10 times per second for 10 enemies, 5 times per second for 20 enemies, or twice a second for 50 enemies. The 10*10 will be the smoothest overall. An “update” is where the enemy will make decisions whether it should change state or keep doing what it is doing.