Capstone Game Post Mortem: For Glory M
Full Sail University
November 19, 2016
Game App Icon (TV Icon)
For Glory M
Android TV, Fire TV, Apple TV, Windows 10
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.
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.
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
Fight for honor. Fight for survival. Fight, For Glory!
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!
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.
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.
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.
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.
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.
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. (2010). For Glory [Xbox 360 Game Application]. https://marketplace.xbox.com/en-US/Product/For-Glory/66acd000-77fe-1000-9115-d802585506b5
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