I’ve entered strictly for learning purposes and to see if I can actually finish something. Game development is surprisingly very different from application development, and it’s nice to feel really stupid again.

Synopsis

You’re a dwarven treasure hunter piloting a gnome sphere powered by music on Thuldanen, 2nd layer of Esheron, the plane of war. The plane has floating cubes with caves inside, and the 2nd layer, Thuldanen, is notorious for having many treasures left over from the ever-happening wars above. They turn to stone after a time, so you have to be quick… this includes if you go outside of the sphere.

The sphere is powered by colored crystals, and each color has a different element that unlocks different powers. You start with black, gravity, to roll and jump the sphere. Later you get blue, electricity, to power the explosive grappling hooks to traverse over the more rough terrain full of impassable refuse. The gameplay is similar “Where’s My Water” where as you learn a new power’s abilities, you can start to combine them to defeat each new level’s complexity.

I was inspired by the game Loom which utilized a simple interface of music notes to basically do everything in the game. Some songs you knew, some you had to memorize, and some you had to simply find on your own. That, and I like dwarfs fighting orcs and goblins on their home turf with an axe or just rolling over the whole lot with a giant metal sphere, for the sake of getting pimp treasure, all the while attempting to do so quickly so you don’t turn to stone.

Thuldanen Maestro Goals

My goals with Thuldanen Maestro were to make a smaller scoped game than my January entry in the hope I could finish it. Additionally, I wanted to follow the month’s theme of “music”.

Actual Results

I didn’t finish.

… but it’s playable and feels… well, almost like a real game. I had sketched out 7 levels that utilized at least 2 crystals, and started getting pretty challenging and cool. Instead, I  fell down the rabbit hole that is game juicing (polishing). I didn’t know this ahead of time, but in retrospect it makes sense, it’s a lot like perfecting code that’ll never be perfected.

Even so, I was really happy with how it turned out. This is definitely a game I want to come back to in 2014 first and git-r-done proper. My girls wanted to play this one during development a lot more than the first one.

What Went Wrong

First problem, I lost 18 days. I’m a adult, run a business, do business trips, have taxes, and 2 kids. And I got a flu I think for 10 days. And I workout at least 1 hour, 5 days a week. All conspired to use the most amount of my time during the shortest month of the year.

Second problem, too much polish. I spent too much time in art land, when I should just be doing programmer art and hiring an artist to the real stuff.

Third, while it’s a music driven game, I had no time for music itself, and no time for sound effects, nor the dialogue I wanted to create.

Fourth, I didn’t even get to create proper buttons for moving the dwarf around, nor time to create enemies for him to fight (although the fight code IS in there…). That game didn’t really need ’em but it DID need the stone bar; the progress bar that slowly shrinks before you turn to stone if you get out of your sphere. Without, you have no sense of urgency, and less of a desire to roll around in the sphere to explore and experiment with notes.

What Went Right

I’ve fallen in love with Corona SDK because they make Box2D easy. You can do it in Flash which has some great implementations, but it doesn’t run on mobile devices at all. However, I’ve always felt compelled to make level editors because I never know how to properly generate the required geometry for Box2D. However, creating non-concave shapes, and MULTIPLE convex shapes to assemble a concave one was… ridiculous.

…until I found out about PhysicsEditor. Holy. Drastically changed, sped up, and improved my workflow. That and I have little need for level editors on the smaller games. Now I can create un-even terrain for side-scrolling levels and all kinds of crazy shapes for terrain, both static and interactive.

I also found out PhysicsEditor has a friend called TexturePacker. Now it’s uber-easy to create sprite sheets, and edit AND re-edit them vs. using those insanely unwieldy and hard to write JSFL scripts for Fireworks. The workflow with After Effects was great as well.

I made my package structure only 1 level deep this go around and started the code base from scratch only pulling in classes/libs when I needed them. This made a massive difference in the speed of iteration. That said, it’s merely a work around for the lack of tooling.

While I suck at art, I really liked the Steam Punk style for the game. Victorian era steam tech works great with gnome engineering and dwarven grit.

Even during the first play iteration tests (you create a build just to see how the game feels to play), it felt like a game I’d actually want to play. I was CLOSE!

Key Takeaways

Like any n00b who isn’t a n00b in other things, I realize I still don’t know what I don’t know. Things like PhysicsEditor make curious what other earth shattering tooling or techniques I don’t know about that could drastically speed up my development process.

I didn’t use Trello as much this go around because I knew what needed to be done since the scope was smaller. I feel like that’s a good sign. That said, I could feel when I was spending too much time on a task because it was fun vs. actually needed. Not sure how to fix that since I’m doing this for fun.

Conclusion

March: Smaller scope, focus on more levels, just a little polish. Maybe team up?

The source code is up on Github and you can install on your Android device here.