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.

I’ve entered into the One Game a Month party. It’s like Ludum Dare, a challenge to make, and most importantly FINISH, a game in a set amount of time based on a theme. What makes #1GAM unique is you have an entire month and it spans an entire year. They have a thriving Twitter and Google+ group.

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.

Snynopsis

PlaneShooter, a 1942 clone, was all about the story, improved plane engine & weapon customizations, and taking advantage of improved graphical hardware. You play Kay, the protagonist, who flies a P90 Lightning aircraft modified for cargo. Her Dad, O, a former military pilot, and her battle bandits at their latest town of delivery. They slowly uncover a plot that leads to war with an ending that leads you to the 2nd version of the game.

I really liked how you could personalize even a 1940’s era plane with tech that was available around then, yet still leave room for the fantasy element to give it otherworldly powers.

PlaneShooter Goals

My 2 goals with PlaneShooter was simple: finish a game I’d been working on for 8 months in my spare time, and hopefully learn more about the marketing/business side. I had a bonus goal of finally getting a chance to juice a game, ie polish.

It was basically a 1942 clone with a story behind it with extra side-scrolling levels to help in character and story development. Additionally, you could customize your plane between levels. Finally, the game had on going dialogue either during the game or it would pause at key points.

Actual Results

I didn’t finish.

I managed to get the game 99% there with 2 levels. I did get an intro screen, game play, reasonable interaction, a semblance of scoring, reasonable programmer art, and an end screen.

I had created a script and recorded audio content + sound effects for 8 levels.  I had completed all the mechanics for drag and drop of upgrading your plane. This includes the speed + weapon power adjustments, etc. The achievements were half done, and scoring was 99% there, I just had some persistence challenges I was working through. None of which made it in the game, hah!

The intro screen and end screen were not completed and used the wrong art, but I made them functional to call it a day. All planes had 1 hit points except the bosses which was not planned.

What Went Wrong

I’m still learning, so this is all conjecture.

I believe my story scope added a ton of work. While I believe it made/will make the game actually fun to play, it required a significant amount of audio work man hours, including 4 days of purely just scripting writing. If I removed the entire story element, removed the plane weapon/engine customizations, and focused strictly completing levels + art, I may have had a game that felt more complete. That wasn’t the kind of game I wanted to create, though.

All in all, audio took up 60% of my entire work effort. Music creation, dialogue recording & editing, and sound effects. Whoops. I sure had fun, though.

Conclusion: That level of scope was not something I could complete in a month.

What Went Right

Taking a year old code base with 8 months worth of work and yelling at it, “You’ll be frozen in a month” was a great feeling. Many of us programmers have ideas laying around, dozens of them, that are left unfinished. Some don’t need to be completed, but others… yes. So over all that part really felt good to attempt to get some closure.

Secondly, I learned a ton. I read a lot about game design process, re-opened a lot of the artistic tools I haven’t really used professionally in 10 years (Photoshop, After Effects, Reason, Audition, etc). I got to spend significantly more time in them. Some things I remembered, but others I had to learn while under such a short deadline. I also learned new ways to put them into a workflow.

Third, the processes I did use SEEMED to pan out fine:

1. think up idea
2. write it down, sketch it out
3. write up a list of goals, tasks, and scope
4. code the things I don’t know
5. create art & audio
6. implement
7. bug test

That general process seemed to work great, and while there were some kinks, it proves that the general way of build games is a lot like software; you do a hybrid approach of Waterfall and Agile, the requirements (heavy on the pen & paper since they are cheap to undo/redo), and then you iterate on 4-7. I think I just put a too huge idea into the process.

Fourth, although not complete, I could taste I was getting close on some things, but I also started to get a better sense of how much work polish actually is. Additionally, some polish you don’t actually know about until you get the idea solid. Sometimes getting the idea solid is an actual prototype WITH assets in it to play with.

Fifth, Corona actually worked with tons of assets and code. As a long time Director/Flash/Flex developer who grew up in tincy runtimes using dynamic languages and learned how much “better” it was to have a mature one with a strongly typed language… it was nice to have success with a non-mature runtime with a loosely typed language, Lua.

Sixth, it was interesting to see where architecture got in the way, and where it didn’t, but more importantly WHEN it was too early to implement. People have written volumes about YAGNI. They’re usually exhausted Java developers who have found a job doing Ruby in a different company with good medical benefits. YAGNI, like all things software, is an on-going learning process. Building things only when you need them is a given, but it’s when is it too early, too late, how much do you build, etc… that’s the challenge.

Seventh, Chris gave us no deadline for January… which allowed me to learn my lesson. Sort of.

Eight, taking a 5 year old and having her do dialogue actually worked out well. We did all 8 levels in one sitting which took about 40 minutes with a few re-takes and 2 glasses of water. I was very impressed with Adobe’s Audition and how quickly I could batch my hundreds of assets all with my effects applied. It’s a bit unstable, though, and I have to reinstall when the audio drivers get corrupted.

Nine, I actually liked most of the code. I suffered from a lot of left over ideas in the code which meant navigating it was a little challenging, but it is starting to be clear which parts of architecture I like and help. I lived and died by my game loop, and since Corona doesn’t have one built in, I was impressed you could build an entire game based on one. That, and Box2D’s collisions were solid.

Ten, creating music went quite well, and the timing was also just luck as well for the crescendo’s to hit when you reach the mini-bosses.

Key Takeaways

Over all, #6 was directly the result with the lack of tooling. While my package names, ways to build classes in Lua, and other architecture patterns were legit, wading through it and modifying it was way more challenging than it is in other languages that have mature tooling and IDE support. This in turn adjusted how much architecture I implemented, where, and when.

For example, yes, long descriptive package names are helpful, prevent you from having to think where things are, and really organize your code. However, in Lua and Sublime… they’re a pain in the ass to navigate and change. Once you want to refactor something, even with unit tests the entire effort is on you; you get no help from the IDE nor runtime what you forgot unless you’ve left asserts with descriptive error messages everywhere. That is a HUGE burden on a developer under a tight deadline.

Additionally, I learned that a lot of the Robotlegs code I borrowed you don’t need in Corona SDK because it has a built in event bus that works fine. You don’t often need to create sequestered event buses, 1 is fine. That and Dependency Injection isn’t worth it merely because the language doesn’t support it; you’re better off just following a convention, much like jury-rigging PureMVC to act like Robotolegs by firing created and destroyed events in the View’s so the framework can add the required Mediators.

I spent 5+ years ensuring I don’t use global variables in my code, and another 5+ years ensuring you don’t create too many Singletons once ActionScript went to a class based language. Now, I’m always using the same 2 globals in my games and they’re really useful and make the code readable. It’s still not good practice, but for quick iterations and speed, they’re legit. Having to pass the same 2 variables into 99% of my classes externally is ridiculous… it got a lot worse with composition. I no longer judge those who use _G intentionally.

Organizing my tasks into Trello quickly pointed out how much work I had left. If I kept tabs on my tasks, I could quickly judge if I was off track (doing the wrong tasks), or if I was going to have too much work. That, however, took a lot of discipline… when the whole reason I’m doing this is for fun.

Conclusion

Feburary: Smaller scope, focus on more levels.

The source code is up on Github. You can install on Android here.