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

Sunday, September 14, 2014

Capstone Game Post Mortem: Jettisoned

Game Summary:

Brandon Jones


Sci-fi Dungeon Explorer/Builder

Android devices

Revenue model
The game is using the Freemium model. My monetization model was supposed to be to sell in-game currency which unlocked skin packs for dungeons as well as for traps/obstacles. However that didn’t quite make it into the game due to limited assets. In order to quickly add in monetization I can integrate Google’s AdMob service.

Development tools/Language
I am using the Unity2D engine in C# for this project. I have used Unity Tools for Unit and Integration Testing. If I use AdMob I will also be using Google’s Google Services API acquired through the Android SDK Manager. 

Game audience
My target demographic is a 20-30 year old male who would be considered to be a Killer according to the Bartle Player Type model. Since the game primarily focuses on competition this target demographic makes sense although there will be game elements that might also appeal to an Explorer by the Bartle Player Type model.

I worked with 3 other people on this project: Anna Di Masi, Seth Jones, and Nick DeMarc.

Anna was the Lead Artist for this project. Her work includes: All obstacles and traps in the game, the safe and teleporter objects, and the player assets including animations.

Seth Jones composed the music for the game including the music for the menu, fortification phase, and infiltration phase.

Nick DeMarc did all of the audio effects in the game including: Player Walking, Menu Sounds, Player Actions, Mini-game sounds, selection sounds, and activation/deactivation sounds.

© 2014 by Brandon Jones. All rights reserved

Sound Bite
Two sworn enemies are stranded on an uninhabited planet and are forced to outwit, deceive, and steal from one another in order to escape.

Executive Summary
Jettisoned is a Sci-Fi themed strategy game where players are forced to outwit, deceive, and steal from each other in order to escape the planet on which they have been stranded. In Jettisoned players fortify their crashed space craft with various traps and obstacles before setting out to steal the opposing player's Fuel Cell. Players must use whatever tactics they can to make it off the planet.

With Jettisoned I wanted to prove that it was possible to have an intense competitive multiplayer experience on the mobile platform. I wanted players to strategically place their traps and obstacles around their dungeon in creative ways that challenged their opponents. During the Infiltration Phase of the game I wanted players to feel a sense of urgency. I wanted these players to each be racing through the play area not knowing what would or wouldn't be around the next corner. It is this feeling that I love in competitive games and I wanted to capture that in a clean and simplified way on the mobile platform.

If everything had worked out perfectly I would have at least 4 mini-game types with 5 different obstacles and 5 different types of traps for the player to play with. Also the player would have all of its animation ironed out and I would have my brief opening intro still shot “cinematic”. I would also have a tutorial mode and a bit more polish on the game overall.

The Critique: What went right…

Design & Aesthetics
The mechanics in the game were designed to be meaningful and simplistic. That way a player was able to quickly understand the game and focus on competing against his/her opponent rather than the game itself. This worked out well with some tweaks to the UI to reinforce the game controls.

Project Management
The project was very well scoped in my opinion from the beginning. This worked in my favor since I wasn't in over my head from the start and was able to work at a comfortable pace. This allowed me to work overtime to catch up if I was behind without missing any additional deadlines.

Using the Unity2D engine worked very well for my project. It allowed me to quickly add game-play features to my project including: game objects, player actions, map creation, and networking. Using C# as my primary language was also good since I have a strong background in C style programming languages. I structured my code so that it was easily expandable which allowed me to quickly iterate on systems that weren't working optimally as far as the player experience was concerned.

Unity’s testing tools were extremely useful. I consistently play tested myself to be sure that the game was bug-free and flowing properly. I also did some third party play testing to make sure that the game was readable and intuitive. Through this process I was able to pinpoint issues in the game and address them quickly.

The Critique: What went wrong…
Design & Aesthetics
The UI in the game has undergone the most drastic changes within the game and is still not perfect. The UI within the Fortification Phase in particular has caused some of the most issues. There were several actions that needed to be given to the player within this phase which was challenging. There are still a few visual and audio assets missing from the game that didn't quite make it in including final animations, cinematic still images, and game music.

Project Management
While the project was well scoped for a three month project, I was not remarkably successful at managing my time while also working a full-time job. As a result at fell behind on a few tasks that I should not have and as a result I did not fully make some of the features I had hoped to get into the game. I also did not do an amazing job at managing those within my team and as a result I am also missing some final assets.

I was not very effective with keeping up with my documentation and as a result I did not update my Technical Documentation or development schedule. This caused my issues later on which led to my inefficient time management.

Unfortunately I only started using Unity Tools towards the end of my project. If I were using Unit Testing and Integration Tests from the start of my project I could have discovered issues earlier on and saved some development time. In the future I am going to be sure to use these tools from the start of my projects.

Business Model/Plan
I did not properly manage my time for game-play features behind my monetization plan and as a result was unable to integrate the in-game currency. I also was unable to get the assets necessary to sell different asset packs for dungeons/game objects.

The final version of the project was a little less expanded than my ideal. Although I am glad that I sacrificed an expanded version of the game rather than the quality of the core game concept. I would personally rather have a smaller complete product rather than a large project with holes in it. As a result I completed my A-List features and had to partially cut down some of my B-List Features. I intend to take this project and expand on it in the near future. Since I have a solid foundation for the game I feel like I can definitely make it happen without any reworks. With the core of the game complete, all that’s left is to expand on the current game objects, add more mini-game types, and clean up the game interface. Other than that a game can always use polish. Perhaps I’ll add in some visual effects. I was excited about this project because I wanted to see what I could create on my own and I am not disappointed with the results. However I have learned that when I am working alone I might need to create more formal deadlines and schedules for myself. That way I can hold myself accountable and keep myself on track. If I could go back I think that I would have created a day-to-day schedule for myself so I understood just how much time I had left. I would also have created a prototype of my UI a bit more so that I wouldn't have to rework it later on. As a high-point, I really enjoyed working on the player mechanics and the tile-based room structure. I was a lot of fun and I learned a lot about how to build and expand complicated data structures. As a low point it was finding out just how much more time I had to work on the project towards the end. I felt kind of demoralized and as a result my work faltered a bit. I don’t think I’ll release the game just yet, but I plan on expanding the game and eventually making something out of it.


Jones, B. (2014). Jettisoned [Android Game].
Lead Artist: Anna Di Masi
Lead Music Engineer: Seth Jones
Lead Audio Effects Engineer: Nick DeMarc

Kyatric, (Feb 18, 2013). Bartle’s Taxonomy of Player Types.

Retrieved from http://gamedevelopment.tutsplus.com/articles/bartles-taxonomy-of-player-types-and-why-it-doesnt-apply-to-everything--gamedev-4173