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, March 27, 2016

Capstone Game Post Mortem: Robomancer

Game Summary: A turn-based tactics game aboard an abandoned space station


Joshua Fox




Turn-based tactics


Android, eventually iOS and Windows

Revenue model

The game will be released as a free demo, with the first few levels included. Players wishing to play the full game can purchase the full version for $4.99.

Development tools/Language

Robomancer was created using Unity and C#, with art assets created in Maya and Photoshop.

Game audience

The target audience for this game is fans of other titles in this genre, such as Final Fantasy Tactics, XCOM, Fire Emblem, etc.


Robomancer © 2015 Joshua Fox


Sound Bite

One man's junk is another man's robotic army.

Executive Summary

Robomancer is a top-down, turn-based, tactical RPG set on a space station discovered by the main character. The hero finds the station is full of powered-down robots, and using his technical know-how he powers up a few and explores the station with them. The game features tactical battles in which positioning is key: the main character is more vulnerable than his robotic allies, but he also must stay close to them in order to direct them around the battlefield.


Science fiction stories have always fascinated me, especially those involving space stations--Star Trek: Deep Space Nine is one of my all-time favorite shows. Combine this with my love of tactics games, and you have Robomancer. I wanted to create a game that included the same feeling of danger and tension as the XCOM series as well as a diverse cast of characters and abilities like Final Fantasy Tactics into something uniquely my own.


The initial vision for the capstone project was to create a slice of the eventual game. During the design process I included far more elements that I could implement in the capstone time frame alone; this was done in to create a cohesive design. Since the goal was to create a small slice of the overall design, for the most part I was successful. I would have liked to have had more visual content in the game in the form of character models and animations, as it would have added a lot more variety for the player. From a technical perspective, however, I think I achieved what I set out to do. Going forward most of the effort will be spent on creating additional content, though there still are some systems which were not in the capstone project that need to be implemented as well.

Gameplay Screencast

The Critique: What went right…


Unity is a powerful engine with a lot of capabilities. It is very easy to pick up and get started, though it is not without its own challenges when trying to something complex. Using Unity gave me a good start on my project, as all of the core systems for any game (a renderer, level editor, etc) are already in place.

Unity's Asset Store

Early on in the project I found some content packages in the asset store that allowed me to fill out a large portion of my game's assets (at least for the prototyping/capstone process), so I could focus on making those assets do something interesting. The asset store has a lot of good content which can provide solutions to common problems, as well as act as a learning tool in some cases.

Grid System

One of the first big systems that I wrote for Robomancer was the grid system. All unit actions and AI behaviors revolve around this system--finding units in range, determining a valid movement path, etc. Though I added to this and tweaked it a bit as the project progressed, by and large I got this system right from the beginning. A few extra bits of functionality here and there in the planning stages made later features which utilized the grid much easier to implement.

The 3D level on the right, and its grid representation on the left


Unity's lightmapping system allows for light detail to be calculated and then "baked" into textures called lightmaps. These textures are then rendered on top of the static geometry at run-time, in lieu of using real-time lighting . As a result, the final rendering cost for an object using this method is much less than it would be using a more realistic, dynamic lighting model. Using these lightmaps, I was able to achieve a great deal of visual quality while still maintaining a high level of performance.

Another useful element to go along with lightmaps is what Unity refers to as Light Probes. Light Probes allow a moving object (such as the characters in the game) to look up information about the baked lighting, and change the colors of the objects based on their position in the level. What this means is that dynamic objects are affected by the lightmap information to give the impression of a detailed and dynamic lighting model. The result is not entirely realistic, but just hinting at a bit of realism can make a huge difference.

Light Probes hinting at realistic lighting

The Critique: What went wrong…


This was my first large project using Unity. Prior to this, my experience was limited to a tutorial here or there, and often those only covered the basics of the editor: dragging a GameObject onto a script variable, creating a Prefab, and so on. Creating Robomancer has been a crash course in how to use Unity on a deeper level, and I had to learn as I went along. Unity is a very flexible engine, and someone using it can accomplish virtually any task in a variety of ways. Unfortunately this is a double-edged sword, as some ways are better than others, with no real guidelines as to which is which for someone not completely familiar with the engine (e.g. me).

This is not the fault of Unity; the engine is there to support the developer's project, not structure it for them. This project forced me to develop some more organizational skills, something I often struggle with. Knowing what I know now, there are some things I would have structured differently from the beginning, and some things that I will rewrite once I resume work on the project.

Asset Store Content

Not all asset store content is created equally. The assets that I used for the bulk of the environments had issues with baking lightmaps, and I spent a fair amount of time attempting to debug the problem. Eventually, I discovered there was a problem with the way that Unity was importing the assets, and that it was a known issue with the version of Unity I used for the project (which was 5.2.1). A Unity developer had mentioned in a forum post I came across that the bug was fixed in a newer version of Unity, but I was reluctant to update in the middle of a project because that can be a risky thing to do. I found a workaround eventually, but the time spent trying to resolve those issues could have been spent elsewhere.

Lightmapping artifact from an Asset Store mesh

Incomplete Planning

There is the expression which says someone "Can't see the forest for the trees." It implies a person is missing out on the big picture because they are focused on the smaller details. I often have the opposite problem, in which I can't see the trees for the forest. I see the big picture, but the small (and often critical) details are overlooked. Early on in the project, I overlooked some of these details when planning some unit abilities, and the visual aspects of these abilities (unit models, animations, etc) were not planned. The features were implemented, but during usability tests everyone playing the game was confused about what was happening--understandable, given the lack of visual cues. Better planning at the beginning stages could have alleviated this.


I created the tutorial as my first level, and this ended being perhaps the worst decision I made on the project. First, I had no way of scripting level sequences or events (and didn't have time to create one), so every step of the tutorial had to be hand-crafted. I had to rip apart some existing functionality in order to be able to essentially pause in the middle of something and check to make sure players performed the correct action for that part of the tutorial.

This was all very tedious, but the real problem is that other game features were being implemented or tweaked after they were created for the tutorial. If I changed the way a system worked, I would have to make sure that the tutorial version of the system was modified as well. I made numerous tweaks and adjustments to the game after the tutorial was created, so I had to rework it over and over again. Going forward, I would save the tutorial until the very end, once I was certain the game and its features were finalized.


Overall I am very happy with my capstone project. I think the design is solid, and the implementation so far is good, given the tight time constraints during the last few months. Going forward there are some areas that need a bit of work, and there are still some missing systems and features, but this was only ever meant to be a slice of the final product. There are three big areas that I will be focusing on in the months leading up to this being released as a finished product.

Systems Redesign

Knowing what I know now about Unity, there are some things I would like to go back and change. How certain classes interact with each other, how GameObjects can be created dynamically, these types of things can be improved to make it easier to integrate into other systems later on.

Level Encounters

Currently the levels in the game play out as just an arena for the two teams to shoot at each other. Long-term, I would like to have levels play out as individual scenarios, with goals or objectives for the player along the way. This will make the game feel more like a progression through the levels (and the space station in which they are located), which is one of the overall goals for the game.

Asset Creation

The placeholder assets I used for this game were fantastic overall, but they are just that, placeholders. The main character needs to be created from scratch, as do many other units and the environments themselves. Having never created much content for a mobile game before now, I look forward to the challenge of creating interesting art assets that will run well on a mobile platform.


I plan on releasing Robomancer in mid- to late-2016. I would like for it to be completely finished by then, but if only the first few levels (i.e. the demo) are complete, I will still be releasing it then, with additional content to come out later as an update.


Fox, J. (2016). Robomancer [Android video game]. Oviedo, FL.

Saturday, March 19, 2016

Capstone Postmortem: Evolve or Die

Capstone Postmortem: Evolve or Die
Evolve or Die
Game Summary:
Game App Icon

Evolve or Die
Action / RPG
Revenue model
Interstitial ads periodically during menus
Development tools/Language
Unity3D / C# Scripting
Game audience
Ages 10 – 40
Primarily developed to allow the largest target audience however between the learning curve and reading requirements it kept the audience between a certain age range.
Matt Fenderson – Programming and Design
Copyright/Reference - cite yourself
Matt Fenderson (2016). Evolve or Die [Mobile Application Software] Virginia
Sound Bite
Challenge your opponents with a fight to the death, win and be rewarded with experience to evolve.
Executive Summary
Co-op online multiplayer matches, play with others against AI in a fight to the death to win your rewards in which you can use to gain more power.  Play as a creature that can grow and change into much more, choose your path and determine your own destiny!  Each player can choose to follow a path that suits their play, these paths branch and allow their play to grow and change into much more.  While other games may pit you against your enemies, never have you done it in such a unique manor of evolutionary style!
Many RPG’s and Action games such as Diablo, but with a different play style, in what I like to call a “Leveler” where the fun comes from building upon your character and growing. 
While many games play a single protagonist I was going for something slightly different in which you play as a morphing and evolving creature that while you have your main game player leveling it unlocks and allows your actual physical being to change, unlocking additional stats and “abilities”.  Hopefully as this game in itself evolves, additional special attacks can be associated with each creature to truly unlock special attacks that could have effect on gameplay to give more reason for choosing between which creature the player would want to be.  The original concept of the single attack method was developed to ease learning time and make playing on mobile platforms easier.
Demo Screencast:
The Critique: What went right (Please include screenshots where appropriate)
Design & Aesthetics
Terrain Development

While a lot of design issues arose while creating Evolve or Die, one of the things that did go right was the terrain development, initially I had thought to use a single layout and swap out some textures to keep resources low while making it look like you’re in a different place, however it did not have that effect, it was very clear that the arena was the same thing with different textures.  So I had to go back and look at this, which I am very happy for, above are a couple full views of the terrains that players can play in, while still requiring flat areas to be walkable having the 3D elevation and extra detail for each terrain really helps get a player immersed in the scenery.
Project Management
I utilized Sourcetree as a UI for committing my project to Underdog Repository.  This helped enable me to keep backups and be able to revert to solid builds in case of something going wrong.  One practice that I utilized was prior to “risky” development or changes, I would commit a current state of the project with comments of what I was about to attempt, this enabled me to have a specific launch point if that risky process did not pay off and I just wanted to go back to a solid state.
The best thing that happened to this entire project was the requirement for a complex AI, I developed an editor tool that would become a layout for easily selecting maneuvers in certain situations that allowed for the aI to pick the best possible maneuver given the current state of the battle.  This process utilized intrinsic indicators, parameters that are inherent to the match, such as the player’s creature types, number of players and the AI creature type.  This was cross referenced with extrinsic behaviors, things that are currently happening to the match that change over time, such as is the player moving towards the AI, player’s current health and AI’s health.  With as little as 3 modifiers (3 intrinsic and 3 extrinsic) I would have up to 21 potential situations that the AI would be able to pick the best behavior.  In my current build there are 525 possible situations that the AI can analyze!  Additionally, I have created the tool to programmatically build the combinations to allow for an increase/decrease in parameters as needed so as not to have to hand create each of the possible lists.  Also, each of the maneuvers (the option that can be selected from) is created as an enum so as additional options are created they are stored in the option list to choose from.  Here is an example (part of it) of what the tool looks like in use:

So simple and easy to use yet powerful to allow the AI to deduce the best choice for the situation, furthermore keeping a very organized layout to allow making changes stress-free.  
Testing was conducted on a multitude of devices, including the Bluestacks emulator, the target device (NVIDIA Shield) and some various smart phones.  This helped to ensure that lag was limited and that no matter the screen resolution the UI and camera worked correctly given the various devices.  Additionally, profiling was conducted through ADB (Android Debug Bridge) connection from Unity3D to the Shield device to get more real time profile updates from the actual device.
Business Model/Plan
In creation of Evolve or Die I relied on assets I developed, creative commons assets (freesound.org) and free assets from the Unity Asset store.  This kept costs down to nothing and allowed for quickly implementing design and layouts of environments.  Additionally I utilized the Google Admob package for Unity, which has no cost and simply requires an account (also free), to be associated with the Unity Game.  Utilizing the Google Play Game Services I was required to purchase the Developer License in order to enable cloud save and multiplayer which had a cost of $25 (Good for life).
The Critique: What went wrong (Please include screenshots where appropriate)
Design & Aesthetics
One of the largest design flaws in Evolve or Die are some of the feedback loops not entirely providing appropriate reactions to player’s inputs.  For example, as player’s level up and unlock new creature evolutions there isn’t any feedback as to this happening, a player would need to intrinsically know to check what level they are and look at the evolution tree to see any new creatures available.  In the future this could be fixed by providing animation screens of the new creatures being unlocked as well as level up notifications to show a player that something important has happened.  Ultimately I have found that my major weakness in game development is design, having this knowledge will really help in my progress as a game developer and I can focus on this weakness while relying on my strengths to push through and make myself better.
Project Management
While focused on development only, there were a lot of design related issues that could have been looked at, unfortunately due to time management and the development tasks already assigned this got pushed out of the picture. 
While developing the AI Selection matrix there was some tricky issues happening that caused a lot of extra time to be wasted because the problem was not readily apparent.  The AI Selection Matrix utilized a 2D array [,] that associated the maneuver enum assigned by the user.  Unfortunately, unknown during the initial development these 2D arrays are not serialized, which means that as soon as the game was played the array was initialized and cleared out.  Once seeing this I wrote to the player prefs each of the array positions index of the enum, again unfortunately not thinking about where player prefs are written once the game is built for android the editor player prefs are not saved nor do they go with the android build.  As this happened later after testing I did not upfront realize there were any issues as the AI was still attacking the player (although it only used the default charge attack) but I had no reason to believe it was going through selecting any other choice.  Luckily, I had eventually decided to set all choices to hit and run and play on android to see how it looked, at that point only seeing the AI charge I had the realization that player prefs is specific to the device.  In order to overcome the base problem of the 2D array not being serialized I essentially took it and wrote it into a single array (row * column) which allowed Unity to serialize it and save my changes.
User testing was a huge boon for me, I was not able to get my primary audience to test my game periodically as the majority of people who were available to test my game were not of the standard type that would play it.  I had two ends of the spectrum age wise yet neither primarily plays this type of game, and those that were in the middle age spectrum were not really gamers.  While it did help to provide some inherent user interface problems having the actual feedback from a gamer that likes this type of game was not readily available.  An open public alpha testing may have helped however getting appropriate feedback in a consistent standardized form would have been a problem and would have caused a lot more time to just decipher the feedback that was provided.
Business Model/Plan
The interstitial ads cause a lot of grief for players, it takes them out of the game and forces them to focus on something else.  Also, getting the right amount of ads between menus seemed to cause issues as well, having more ads of course means more money however to many ads will drop your players interest.  I may go back and look at this and may look at doing banner ads during gameplay and only interstitial between the main game and menu (plus on game exit / open).  This will help to keep the player playing during normal times and only as they are in-between playing and changing settings do they get interrupted.
I have learned a lot through this whole process, my strengths and weaknesses, and by determining these I hope to be able to focus my attention and improve upon both.  Identifying my weakness in design has really helped open my eyes to what it is and how it really benefits a game to being fun.  As I am primarily a developer/programmer I tend to focus more on getting things to work and function, seeing how giving some focus to design can really turn a well-functioning oiled machine into a fun playing game can help to keep a player interested and wanting to play.  I’ve always seen it as if the game is laggy and functions poorly that will quickly turn players off, but additionally without some kind of focus on feedback for the player it really doesn’t matter how many bells and whistles are running in the background if the player doesn’t care to stick around to find them. 


Atwood, J. (2007, 07 04). Game Development Postmortems. Retrieved from Coding Horror: http://blog.codinghorror.com/game-development-postmortems/
Bevilacqua, F. (2013, 10 24). Finite-State Machines: Theory and Implementation. Retrieved from envatotuts: http://gamedevelopment.tutsplus.com/tutorials/finite-state-machines-theory-and-implementation--gamedev-11867
Fenderson, M. (2016, 03 19). Evolve or Die. [Mobile Application Software]. Virginia.
freesound. (2016, 03 19). Retrieved from freesound.org: http://www.freesound.org/