Capstone Game Post
Mortem: For Glory M
Michael Celey
MGMS Program
Full Sail University
November 19, 2016
Game App Icon (TV Icon)
Title
For Glory M
Genre
Arcade
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.
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.
Team
While I coded the entire game
myself, all art for the game was provided by Nick Heckman.
 |
| @AuraTummyache on Twitter |
Copyright/Reference
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
Inspiration
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.
Ideal
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.
Development
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.
Testing
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.
Development
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.
Testing
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.
Summary:
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.
References
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
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.