This site showcases the thesis capstone projects for the Full Sail Mobile Gaming Master of Science program. Students completing the program post their end of program project self evaluation here examining what went right and what went wrong during production.

The site provides examples of all completed projects, without regard to the quality of work. Final faculty evaluation of your project is separate from your postmortem. It is a place to share student work and start dialogue with faculty about completed and upcoming projects.

If you are adding a postmortem for a completed project to this blog, please do your best to provide a meaningful meta-level evaluation of your project. This helps students currently in the program have a better understanding of the critical points related to independent production, game development and design and project management. The template for the blog content and instructions can be found in the first post from July 2014.

Thank You,
MGMS Faculty

Monday, December 12, 2016

Capstone Game Postmortem: Overclock

Capstone Game Postmortem: Overclock

Richard Keller

MGMS Program

Full Sail University

December 10, 2016

Game Summary

Game App Icon


Lane Defense

iOS and Android

Revenue Model
Premium: $1.29

Development Tools/Language
Unity 5.4.2 / C# / Git with Tower

Game Audience
Primary: Boys and Girls Ages 12-20, Secondary: Men and Women Ages 35-45

Ricky Keller

Richard Keller


Sound Bite
Overclock! Fast-paced alien lane defense!

Executive Summary
Overclock is a lane defense game in which the player is able to reposition its units after initial placement. The player can place its attack units next to power converters in order to become overclocked. Becoming overclocked provides different abilities based on which power converter type is affecting the current attack unit. Position your attackers in coordination with your defensive units in order to hold off the incoming alien threat.

I wanted to make something similar the gameplay found in Plants vs Zombies but with a twist. I also enjoyed the cartoony light-hearted aesthetic that it brought. I was also very heavily inspired at the direction of design as is explained in the GDC Vault video How I Got My Mom to Play Through Plants vs. Zombies by George Fan.

I was hoping for 10-12 levels that introduced unlockable levels, hero types, special abilities, and 7 enemy types. I was also hoping to have included some more custom assets so as to play with assets that required more that one tile at a time and enemies that wore earmuffs to protect themselves against audio debuffs. I also wanted to keep the heroes robot themed so I could play more with the wording of overlocking. The rest of the design details seemed to go well.

Demo Screencast

The Critique: What Went Right

Design and Aesthetics
The final design seems to be well-balanced and the bigger design decisions made to distinguish itself from other lane defense games seem to have paid off well. The two major decisions I want to point out are the ability to move your units at will after initial placement and the positioning of attack units next to power-converters. Separately these features may not have worked well, but together they allow for interesting gameplay as the player is able to cover their bases while still focusing on the pattern they'd like to build. Even more than that, their pattern can improve as the game continues.

Aesthetically, the end result turned out to look very sharp. Although I was unable to get exactly what I wanted from the Unity Asset Store, I found some assets online that fit the theme I wanted, light-hearted and approachable but still with a slight edge.

The in-game visuals look familiar and still new at the same time. I was happy with how professional the game itself looked despite art not being my forte. Initially I thought I would need to go with a faked 3D perspective in a 2D game world, similar to that of what Plants vs Zombies did, but I was happy that the idea of corridors worked quite well. Although I wasn't able to stick with robots for the final aesthetic, I was happy with the compromise of android-like figures.

I was happy with the idea of currency being earned as each enemy was defeated which borrows from the idea of sunlight in Plants vs Zombies but does not require any units specifically for income. It also requires the player to defend themselves before being rewarded with additional means to fortify their defense.

While I did not develop any of the assets myself, the layout and animation presentations were completely developed by me.

Project Management
I relied somewhat heavily on the issues tracker in Underdog to help with my backlog of items I wanted to complete. It was also helpful for tracking and resolving bugs as they arose.

I hadn't worked with Unity 2D Sprites before, but I found them to be quite simple to work with. The scripting itself was fairly familiar to me, and the core features of unity, such as collision detection, physics, and the low-level memory management were all handled for me. This was nice because it allowed me to focus on gameplay programming as I wanted to focus more on design than development for this project.

A lot of my testing was trying to get it in the hands of as many people as possible and watching them play. There were several bugs that I was able to find out myself by simply trying to get the game to break, but since I was the sole developer on the project, it wasn't difficult for me to diagnose the root of the problem typically. The non-design bugs were very easy to fix in a short amount of time.

Business Model/Plan
The premium model seems to suit this game very well as no design aspect particularly sticks out as prime ad placement or the need for microtransactions. These could be added with a few small design changes, but they were never a part of the original plan.

The Critique: What Went Wrong

Design & Aesthetics
While the end result turned out nicely, there were a number of things that weren't able to be added. I would have liked for the levels themselves to unlock as you completed each level. I wasn't able to cap off the last round with a boss battle either. That is something that would have been nice to be added. 

After some of the last feedback received by play testers, the game seemed to be too difficult from the second level onward. For the most part, this was not an issue of the mechanics themselves not being able to provide a path to victory, but rather that the game did not slowly walk them through each ability the different units were capable of. I would have like to have included a more progressive tutorial that introduced one unit type at a time over several levels as each new unit was unlocked. Instead, the game introduced 3 out of 5 character types and delivered all types at the very beginning.

Although the game included an interactive tutorial, it also required a more detailed tutorial. This tutorial, however, was a bit too detailed as most people didn't care to stop to read everything.

This particular screen also didn't adhere very well to the inner 80% screen space rule.

Initially, I had planned to work with an artist friend of mine who works in the industry. After finishing the three items in the bottom left of the image above, the artist was forced to admit that he could not keep up with the time commitment required in order to complete this project. After that, I was forced to search online for assets to fit my theme. I was a bit disappointed that I could not implement some of my more custom ideas such as the enemies wearing earmuffs or robots that fit the right level of cartoony I was looking for.

Towards the end of the development cycle, I implemented a scoring system. In an effort to better give the players an idea of what actions were earning them points, I implemented the idea of floating points. The problem was that points are earned for each successful attack and the players thought the floating points were readouts of damage dealt. After not coming to a quick alternative solution, I made the decision to remove them as to not confuse the player.

Project Management
I didn't make very good use of the GANTT chart made available to me in Underdog and mostly stuck to the issue tracker. The technical design doc helped me keep my items of highest priority in order, and the issue tracker was able to help me organize my features into sprints three at a time.

Something I would have loved to put more time into was developing some flashier visuals. It was difficult for some players to tell that the power-converters could be used in combination, meaning that the damage power-converter could be used with the speed power-converter to produce both extra damage bullets at a quicker rate. Something as simple as having the tiles cycle through their currently available power ups or displaying the colors in a split view would have been very helpful for the user, but in the end I had to prioritize other things such as the tutorial and the core aesthetic looking sharp.

I don't care too much for the way managers needed to be implemented in Unity, by adding a script that needs to keep state to an object in the scene that will never be destroyed, but it got the job done for spawning enemies and keeping track of tile allocation and power ups.

Something that came up in testing as unnatural was the idea of tapping the characters on the bottom of the left to build them before dragging them from the build bench onto the board itself. Every player wanted to drag the characters straight from their icon on the bottom left to the board directly. This seemed like a good change to make, but by the time it became prioritized, it was too late in the development cycle and affected too many other aspects of the game. I eventually determined that it was too risky to change so late in the development cycle.

Business Model/Plan
The premium model is a hard sell for this game as other games such as Plants vs Zombies 2 are free-to-play, and is backed by a much larger development staff. For a commercial release, I'd have to look at a pricing model with a lower risk to curious players.


I'm happy that I was able to stick pretty close to what I had originally planned. Other than the change from robots to androids, I was able to develop the game I wanted to with the exception of a few missing features. I'm also happy with my choice to focus on design rather than development for this project. As a graduate of the GDBS program, I wanted to switch it up to focus on some different aspects of game development.

There are some things I'd like to do with this game before a commercial release, however. While I feel it's on the right track to being deliverable, it needs to be adjusted with some of the missing features I referenced above. It should also adhere to a more progressive tutorial system to teach the players how to best play the game while still providing a good level of challenge. I'd also like to experiment more with an artist who can be dedicated to the project in order to provide the charm the game requires.

Although this is not the first game I've developed, I feel like I've learned a lot focusing more on design. It's a difficult thing to find that right level of balance for a game when trying to help the player teach themselves how to play. It was also nice to stretch myself in making more artistic decisions than I expected I'd need to make. I feel more comfortable approaching game development as a team of one, and while I would definitely do a few things different next time, I was happy that some of my design ideas turned out well.


Tower. (n.d.) The most powerful git tool for Mac and Windows. [OSX Application]. https://www.git-tower.com/mac/

Unity. (n.d.) Unity - Game Engine. [OSX Application]. https://unity3d.com/

(Fan, G.) (2012.) How I Got My Mom to Play Plants vs Zombies. Retrieved from http://www.gdcvault.com/play/1015541/How-I-Got-My-Mom

PopCap Games. (2009.) Plants vs. Zombies. Retrieved from http://www.popcap.com/plants-vs-zombies-1

PopCap Games. (2013.) Plants vs. Zombies 2: It's about time. Retrieved from http://www.popcap.com/plants-vs-zombies-2

Sunday, November 20, 2016

Capstone Game Post Mortem: For Glory M

Capstone Game Post Mortem: For Glory M

Michael Celey

MGMS Program

Full Sail University

November 19, 2016

Game Summary:
Game App Icon (TV Icon)

For Glory M


Android TV, Fire TV, Apple TV, Windows 10

Revenue model
The game will be free to play and monetized through in-app purchases to buy glory points and modifiers that allow the player to earn more glory. A single glory point would run $0.99 and a pack of five would be $2.99. Increasing the earned glory by 25% for two hours would be $1.99.

Development tools/Language
The game is developed entirely in Unity using C#, though a little Java and Objective-C were involved due to the first party library integration for Android, Amazon Android, and tvOS.

Game audience
For Glory M is intended for males, aged 25 to 32, who enjoy arcade fighting games with minor RPG elements. The game was meant to target short play sessions on TV platforms.

While I coded the entire game myself, all art for the game was provided by Nick Heckman.

@AuraTummyache on Twitter

For Glory M © 2016 Aura Softworks, LLC

Sound Bite
Fight for honor. Fight for survival. Fight, For Glory!

Executive Summary
The monster hoard has been broken. No longer do the people of the city fear the coming invasion. Now, the remaining monsters are battled for sport in the city’s coliseum.  In For Glory, the player takes on the role of a warrior looking to earn glory through combat against the monsters in the arena.  Should the warrior fall, a new warrior will continue the fight with upgraded equipment based on the glory earned by the previous challenger.  Take up the mantle of the warrior and fight, for glory!

Demo Video

For Glory M was designed to be a new take on the original game For Glory that I developed back in 2010. While the original game was a single direction, side-scrolling beat ‘em up, this iteration was designed to be a single screen arena fighter. The inspiration behind the change of design came from the game Slayin by Pixel Licker Games (n.d.) that utilized this style of gameplay, but didn’t incorporate a lot of the features of the original For Glory.

Capstone Scope
The scope of this capstone game was to deploy across multiple platforms from a single source base while incorporating all first party library features for each platform and having a single source accommodate multiple different control schemes.

If everything had gone right, I was planning to have an endless set of enemy waves with boss waves occurring every 10 waves. When the player died, they would be able to purchase equipment upgrades in a skill tree like fashion and each upgrade would alter the appearance of the character. The player would also be able to look back at all of their past lives a see how each character progressed.

The Critique: What went right…

Design & Aesthetics
While I didn’t quite get all the assets that I hoped for, the assets I did receive looked exactly how I hoped they would. The character and enemies meet the exact design aesthetic I was going for in the game. Additionally, both the main menu and options screens turned out as expected.

Project Management
While the project didn’t necessarily start out great, my advisor and I made great strides at getting on the same page as development progressed. We found that my crazy work schedule wasn’t really conducive to Sunday deadlines as the class defined, so we moved more towards incremental builds throughout the month that hit smaller feature milestones instead of larger kitchen sink style milestones.

On the asset side of things, my artist would commonly forget milestones or sometimes he forgot what went into milestones. To correct this, we moved to using a Trello board for defining which assets belonged in which milestone and when each milestone was due. The artist could then attach assets to cards on the board when they were ready and I would move the card to complete when I signed off on the asset being completed.

The wave and enemy behavior systems that I built are probably the two crowning features of the game. The wave system allows the developer to drag together prefabs of enemies, set properties for how much glory each enemy awards and what their attack/defense modifier might be, and the wave system automatically adds that enemy into a list of enemies available for a given wave. The wave system then seamlessly transitions between waves when the player reaches a certain threshold of enemies defeated versus enemies remaining in the current wave.

The enemy behavior system that I built is similarly easy to use. Every enemy in the game has an entrance behavior that defines how they enter the field of play, an attack behavior that defines how they act once in the field of play, and a death behavior that defines how they exit the field of play. While it takes awhile to write a single behavior in an abstract enough way that it might be reusable, once behaviors are written you can create enemies rather quickly. To create an enemy, you simply add an entrance, attack, and death behavior to the enemy along with a controller object, and the enemy will go through the different phases the same way each time. Therefore, once you have a base set of entrance, death, and attack patterns, you can simply drag those behaviors onto new enemies to cut down on rewriting the same code over and over again.

There was very little formal testing done on this project. After the core of the gameplay was completed, user testing was conducted and found that the game wasn’t very fun to play on a touchscreen. The game was then altered to work with a controller and new play sessions were conducted with the same two users. Both users found that the game was much more responsive and fun to play with a controller and so the switch was made from mobile to TV platforms. Aside from that, all testing was conducted by the developer.

Business Model/Plan
The business model for the game is rather appropriate and matches industry standards for this type of game. If the full upgrade system were to be implemented so that the purchases have real value, this game could be a success in terms of revenue.

The Critique: What went wrong…

Design & Aesthetics
While the main menu and options screens ended up looking exactly as planned, the gameplay and upgrade screens didn’t quite work out as well. About halfway through the project, my artist started falling behind on some of the asset milestones and I needed to cut several features from the game to accommodate. There is also only a single audio track in the game due to asset deadlines being missed.

 Since the upgrade system had been cut, the upgrade screen now only shows simple numerical upgrades instead of the skill tree that was planned.

What made it in the game.
What was originally planned.

The character is also now a single Spritesheet with static equipment instead of having variable equipment based on upgrades.

Aside from the issues with missing assets, all other art assets turned out as desired. However, most of the assets I requested weren’t delivered and a large part of that had to do with how I interacted with my artist. At first I just sent him requests and deadlines, but they were easy to forget or the list would get lost in a stream of chat messages on Discord. We eventually moved to using Trello to fix some of the issues.

Project Management
The project management aspect of this particular project was a complete disaster up to the very end. From day one, I was unable to meet many milestones due to a combination of work being busy and me having estimated many features completely wrong. While the process did improve and I was able to work things out with my advisor, the biggest failing in this project was the hours estimating. I had never built a full-scale project in Unity before so many of my estimates were based on research and what I knew from other game engines. However, most of the things that I thought would be easy ended up being really hard and/or time consuming while things that I thought would be hard ended up being a quick fix. Because of this, none of my milestones were properly balanced and I fell behind constantly.

Aside from the time estimates being off, the biggest problem with development had to be confusing documentation. When working with several libraries for different platforms, you have to be able to rely on accurate documentation to get you through any issues, or you’re stuck debugging everything. In the case of the Amazon Game Circle SDK, a lot of debugging was required. According to their documentation, Game Circle didn’t support the iOS or tvOS platforms. With that in mind, I went ahead and made an iOS build and excluded all Amazon code. However, while I wasn’t referencing any Amazon code, it was still in my project and thus required native libraries on the iOS side. This didn’t seem right so I went and looked through their code and documentation and found that they have dummy libraries in place for iOS to exclude their code. I followed the links on the documentation though and ended up at a dead link for the library download. Because of this, I had to go through and rewrite a lot of the Amazon library to make sure it didn’t require dummy libraries on unsupported platforms.

I didn’t do a lot of testing on this project because I often didn’t have a lot of progress to show to the end user. Instead, a lot of my time had been spent building systems that would support future functionality, some of which never actually made it into the game. Most of the testing that did happen with this project was development testing of in-app purchases using the testing mechanisms provided by each platform. However, since I was going through Unity instead of doing these purchases natively, most of the testing period was spent guessing at fixes and attempting to decipher error codes that were non-descriptive.

Business Model/Plan
While I believe the end-goal business model for this game is appropriate, it’s complete garbage in its current form. Since the game resets glory count for every play-through and the upgrade system is strictly numerical, not to mention there are no bosses in the game, there’s no incentive for the player to want to make a purchase. To make the purchasing model work, the rest of the planned features would have to be built out to even have a chance at bringing in revenue.


For Glory M didn’t quite turn out how I expected. I had planned for this solid finished product that I could immediately push out to the app stores and I was left with a barely playable demo in the end. There are still several features that need to be implemented in order to make this project a success. I need to build in the bosses, flesh out the full upgrade system, add in game saves, and add in the visual changes to the player. My artist still likes the game idea and has offered to continue making assets when he has some free time, but currently the game is going to be set on the shelf until we both have more time to move forward.

If I had to do anything different, I’d probably build fewer systems. I like game systems and so I spent a lot of my focus on that part of the game, even though the game really could’ve done without them. I also would’ve planned out things with my artist a bit further in advance to make sure that he could start delivering assets before I needed them as opposed to giving them to me the day a milestone was due.

If there were at all a high point in this project, it would have to be the day I was able to present to Tof my working in-app purchases across all of my platforms and show that they all worked. After so many setbacks, that day was the win I needed to get myself across the finish line in the program. On the other side, the low point of the project definitely had to be the day I met with Tof and Joe about rescoping the project. I was so defeated at that point that when they asked me what my ideal outcome was, I told them they’d ideally forget this whole thing ever happened and I’d just leave the program.


Celey, M. (2016). For Glory M [Game Application].

Pixel Licker Games. (n.d.). Slayin. [Web Application]. http://www.pixellicker.com/games/games_slayin.html

Unity. (n.d.). Unity – Game Engine. [OSX Application]. http://unity3d.com/unity/download

Sunday, October 23, 2016

Defend Thy Castle

Capstone Game Post Mortem: Defend Thy Castle

Brian Welch

MGMS Program

Full Sail University

October 23, 2016

Defend Thy Castle

Real Time Strategy


Pay for download $0.99

Unity 3D, C#, Javascript, Source Tree

My intended audience is 15-25 year old Real Time Strategy fans who are looking for a new approach to RTS games


Defend Thy Castle  © 2016 Gaming Chef LTD

Command the Impossible

Defend Thy Castle is a real time strategy game that places the user in-charge of a flying castle on a quest for world domination.  The user is able to deploy troops to defend the walls, aim cannons to combat overwhelming waves of enemies, and cast powers to even the odds.  The user must do whatever it takes to survive and conquer the ten levels. Defend Thy Castle’s unique selling point is that it takes the RTS genre and mobilizes it by making the user’s base fly towards the enemy base creating a more dynamic setting for the battlefield. 

Demo Video:
My original concept was to create a hybrid time management and strategy game drawing my inspiration heavily from Kitchen Scramble and Diner Dash in terms of incorporating the time management game play into a battlefield context.  The final version resembles a game that fully favors RTS game play in the same way Warcraft would with the exception that the user’s base is flying toward the enemy base and is not static.

The scope of this project was to achieve developmental mastery through the use of artificial intelligence.  This concept has been established through the use of an enemy algorithm to analyze and select optimal attack waves based on line of sight and user defense information.  Once an attack selection is made, this algorithm is further augmented with a path-finding algorithm attached to the enemy units as they are deployed onto the map to attack the approaching Castleship.

I was hoping for 30 levels divided into three zones to present along with the developmental mastery. This addition can be added through more research on the Asset Store for terrain assets.  If the Asset Store is insufficient, a freelancer can be hired to supply the actual artwork before the game is released.  The rest of the mechanics have gone according to plan.

The Critique: What went right…

The three dimensional graphics that I sourced from the Asset Store have largely been a success as they are high quality without having too high of a polygon count to drag down my frame rate.  In addition, the particle effects for the explosions and lightning have also been given good feedback through user testing.
The three primary user interfaces went well. The first interface is what allows the user to deploy troops to a wall and this is done through a radial interface that appears when a user touches the wall and allows the user to drag their finger to select a troop to deploy to that particular wall.  This functionality is pictured below.
The second portion of the user interface that went well was the cannon reticle UI controls that allow the user to drag and aim each of the Castleship’s cannons.  This concept evolved throughout the course of the project and has been the most frequently used UI control throughout testing.  Pictured below the cursor represents finger placement as the cannon’s reticle is dragged towards the oncoming enemy waves.  Notice the cannon rotates behind the cursor to follow the trajectory path. 
The final portion of the UI that was successful was the special character spells.  These are represented by the three icons floating around the main character at the center of the ship and are activated by simply tapping and dragging to any wall of choice.  Two of the powers are uniform throughout each level (heal and repair) and the top power is changed every map.  This particular picture shows ice as the selected power.
The GANNT chart Milestone management through Underdog helped facilitate productivity and the core functionality has been completed.  Project Management is covered further in the below ‘what went wrong’ section.

Unity 3D has been efficient and enjoyable to work worth.  I utilized the new Unity GUI system heavily throughout my game and I feel that this Engine specific feature really helped facilitate the effectiveness of my overall user enjoyment and interface.  The Pathfinding Algorithm has gone tremendously well with my enemies fully able to respond to the user’s Castleship as a dynamic obstacle.  Below the Debug mode draws pink lines to show the current paths each enemy takes to their respecitve assigned lane of attack.  Please note that there is an ‘I’ collider over the user’s Castleship as a dynamic obstacle to ensure that the enemies only approach from their assigned lanes.

In addition, the Enemy AI Analysis algorithm successfully cycles through each lane and is able to dynamically determine the user’s defenses based on the line of sight of the enemies on the screen.  In the below picture the LOS of the enemy is represented by the green collider and the eyeball is the notation that the AI uses to track which lanes can be analyzed.  From this information the AI is able to determine the best wall to attack.
A good portion of testing was informal and done to see how natural/intuitive the UI controls were.  This testing has led to the current UI system as the troop deployment UI has been drastically changed several times throughout this development cycle.  I feel that the final UI has been a direct result of the testing done to ensure that the interface controls were user friendly.

Once the new levels have been completed, I have decided that my game is not suitable for interstitial ads and have decided to opt for pay for download option with the price of $0.99.   My marketing plan will consist of the following elements when I release my game to Google Play:
  • App Store Optimization (ASO)
  • Google Adword Campaign
  • Press Releases
  • Game Reviews from Sites and Blogs
  • Youtube Influencer reviews
  • Forum Posting
  • Social Media presence – Twitter , Facebook, Pinterest, Stumble Upon, Youtube, and G+

The two main elements of my Aesthetics that have fallen short are the cloud background and the general center of the ship.  As seen in the below picture, the clouds are a bit blurry and are often mistaken for static waves and the center of the ship only reinforces this obscurity.  These elements will have to be revisited before the game is actually released. 

I need to, also, design 20 more levels to organize into three zones.  Since, I will be charging $0.99 for the game I will need to ensure that there is at least an acceptable base amount of content to justify the expenditure. 
My project management has suffered many delays.  I had to do two Green Light Presentations, I was hospitalized and set back two months, and I had to repeat one month in my development phase due to a complete lack of progress.  I need to be better organized and have a better handle on my time.  The GANNT chart was helpful for keeping me accountable, but it still was unable to break me of my last minute tendencies.

There could be more choice given to the user for defending the actual walls.  This point would also help show how dynamic the analysis algorithm is because it could successfully show how the computer is able to read and respond to the current defensive situation on the user’s wall.  This issue can be resolved with the addition of new units.  However, the models will have to be of the same quality of my pre-existing units and it will be difficult to add more than 1 unit with current radial selection UI. 

X  X
I need to have more focused testing on my graphics as I feel that my background graphics have let me down.  This testing will be done through a couple rounds of A/B Testing through Preapps and Facebook, which will hopefully give me a better solution. 

I have changed the business model to a paid game instead of a free game because I didn’t feel that ads were suitable for my game. In addition, because I currently have no in-game currency for promotional video ads or any type of in-app purchases to offer, the paid direction seems the most economical. 

                  Though my project has evolved significantly from the original concept, I feel all the changes have been beneficial and have massively helped improve the overall project.  The main trade-off was switching from time management/ strategy to real time strategy as this changed my core game play focus.  From this experience, I have learned the importance of articulating my ideas from the beginning of the project and, also, the importance of doing thorough research on my assets before I begin coding.  However, if I had to do the project again, I wouldn’t change anything, as each milestone was an essential part of my learning curve. 
                  I am currently paving the way for this game to be released in January of next year with several other game releases to help establish my brand and market presence before Defend Thy Castle is released.  In addition, I will be using the revenue generated from these other games to go with a reputable marketing agency to help promote my game correctly from the onset.  I have already experienced how quickly a poorly marketed game can end up in the app graveyard and I will not be making these mistakes for Defend Thy Castle. 

SourceTree. (n.d.). A free Git & Mercurial client for Windows or Mac. [OSX Application]. http://www.sourcetreeapp.com/

Unity. (n.d.) Unity – Game Engine. [Android Application]. http://unity3d.com/unity/download\

Welch, B. (2016). Defend Thy Castle [Android Application]

Big Dragon
Cannon Design
Castle Design
Character Design
Level Design
Small Dragon