Holy Moly Dragons Postmortem

Holy Moly Dragons Postmortem

Holy Moly Dragons (HMD) is a 3D tower defense iPhone game in which you hatch different types of dragons to defend against an army of medieval creatures. 

I’ve always loved the tower defense genre, and making one had been a goal for a while.  I’m also a big fan of dragons and fantasy games and I thought it would be cool to play as a dragon because oftentimes they are depicted as the “bad guys” in stories and games.

My friend Hugo Beyer is a big fan of tower defense as well, and mobile games in general, so in October 2009 I pitched him the simple idea of a tower defense game where your towers are dragons and you have to stop medieval enemies like knights, trolls, and minotaurs. He really liked the idea, so we began discussing design ideas on Skype after work. Thus began our 18 month journey.

Holy Moly Dragons Main Menu

What Went Right

1) Unity

We chose to use the Unity3D game engine because we both had experience with it and we felt that, since we were doing a 3D game for iPhone, we would have a much easier development time than starting from scratch in Objective-C and Apple’s Xcode.  This was a great decision because not only were we able to iterate on HMD at an extremely fast rate, we also got much better at using Unity3D, which has become an incredibly popular engine over the last few years.  Also, Unity has extremely active forums with very smart people that provided assistance to any question that we asked.

2) Tools

There are 15 levels in HMD. Each was balanced with different numbers of enemies and enemy waves.  Early on in the development process, I wrote a level editor tool that allowed us to rapidly iterate on the level terrain.  The tool broke down the terrain into a grid with 1x1 cells so that we could set properties on each individual cell through GUI buttons.  These properties were exported from the tool and read during game runtime to generate paths for the enemies and allow hatching dragons on certain cells, amongst other things.  Whenever Hugo would export a new level .fbx file from Maya into Unity, the level would be playable within 5 minutes.

Balancing the levels was a quick process as well.  Each level had its own script file and we could balance any characteristic of enemies or enemy waves that we wanted.  Things such as enemy type, health, speed, delay time between waves, score value, money value, food given, warning text, and tutorial pop-ups were all easily modifiable, which made balance testing an enjoyable process.

3) Level Design

One of the things that makes HMD stand out from other tower defense games is its level design.  In a lot of tower defense games, the enemies will spawn off screen and move towards their goal which is also off screen.  In HMD, our levels are islands and the enemies enter and exit the level from swirling portals.  We used 4 different materials on the levels: the cliffs, water, ground, and trees.  A custom shader was used to blend 2 textures on the ground to make it look much more organic.  Hugo did a really good job in giving the levels an aesthetic appeal.

The enemies in HMD use dynamic path finding, meaning you can block the path that they are walking on with dragons so that they have to find a new route to their destination.  We decided against having a big open field to hatch dragons on. Instead, we strategically built water and trees into the terrain that the player could build around in order to force the enemies to walk longer paths.  This deepened the gameplay by adding problem solving and puzzle elements.

Molten Gateway Level

4) A Game to be Proud Of

My main goal for HMD was to implement all of our game’s features and having it running at a very fast framerate on iOS devices.  Hugo’s main goal was to get the game looking as good as possible.  In software development, these are conflicting goals. However, Hugo and I made it work.  On average case, HMD runs between 50-60 fps with a clear and vibrant art style.  Our music was created by Hugo’s brother Filipe and it adds even more to the overall production value of the game.  Most importantly, it is very fun to play and it provides a gaming experience that we are extremely proud of.  

What Went Wrong

1) Development Duration

Eighteen months is a long time to be working on an indie project.  Between both of us having full time jobs, which often called for crunch hours, and having a fairly complex game to work on, making the time to work on the project was sometimes difficult.  As time went on, burn out started to set in and the quality of the work would suffer.  Some of it had to be redone as a result, which only extended development time longer.

Frozen Fortress Level

2) User Interface

The Unity way of drawing GUI elements such as buttons and text is great for rapid prototyping. In a final product, however, I found its functionality extremely limiting as well as having poor performance on iOS devices due to how the elements are being rendered.  I switched our GUI system to use a 2D GUI system called SpriteManager created by a Unity forum member.  SpriteManager is good, but SpriteManager 2 is excellent.  The trouble was that SpriteManager 2 costs money, SpriteManager is free, and I cheaped out.  Unity is a great 3D engine, but if you are going to be doing any 2D work in your game, buy SpriteManager 2 and EZ GUI in the Unity asset store.  Using SpriteManager 2 wouldn’t have made HMD any better, but it sure as hell would have sped up development time.

3) Not Enough Pre-Production

When we first sat down to talk about doing a tower defense game involving dragons, we had the basic idea of what we wanted. Yet, as in most things, the devil is in the details.  For example, we didn’t decide upon how big the levels would be until later in the project, we retro-fitted our tutorial level as the first stage of the game, the orange flamethrower dragon was originally a green poison dragon with a different type of attack, and achievements and leader boards were an afterthought, just to name a few things.  I know it has been said many, many times before but it’s worth mentioning again: Design as much as you can upfront and plan accordingly.

4) Small Team, Many Roles

I come from a programming background and Hugo’s background is in art.  This meant we both had to develop better design skills in order to finish this game.  We also had to cover all areas of our respective primary skill.  For me, this meant programming the audio, gameplay, shaders, tools, and AI.  For Hugo this meant modeling, texturing, animating, and user interface work. Along with all this, we needed to design levels, balance test, bug test, and then fix the bugs, rinse and repeat.  Oftentimes I would come home and stare at my TODO list for 15 minutes before deciding upon which was the most important task to be completed on that particular day.

On the positive side, we both greatly broadened and deepened our skill sets and became much better developers in the process.  We obtained a much better understanding of each others work flow, how it could be optimized, and why certain processes should be done in certain ways.

Final Thoughts

Despite a very long development cycle for an iPhone game, we came out with a finished, polished product that we are proud to show to our friends and family.  I love video games, I always have, and I always will.  The fact that I was lucky enough to develop one with a friend is an incredibly rewarding experience.

Development Tools:
Maya 2011

Unity 3.3

Monodevelop

Adobe Photoshop

Xcode3

Team:

Programming: Adam Reilly

Art: Hugo Beyer

Music: Filipe Beyer

Project Start Date: October 1^st, 2009

Project Release Date: April 15^th, 2011

Total Lines of Code: 20,063

Platforms: iPhone, iPad