Capstone Game Post Mortem: Fantasy Frenzy
Game Summary:
Author
Matthew Tjarks
Game App Icon
Title
Fantasy Frenzy
Genre
Time Management
Platform(s)
Android
Revenue model
Paid - $3
Development tools/Language
Unity3D:
v4.6.1f1
MonoDevelop:
v4.0.1
C#
Facebook
SDK: v2.0
Game audience
My game is
targeted to females aged 15-30 years old. My game targets Achievers and
Explorers in Bartle's (1996) player types. Achievers will be interested in beating
every level and getting the highest scores, while Explorers will be interested
in creating and discovering what the different combinations and potions can do.
Team
Matthew Tjarks -
designer/developer
Nick Adams - App Icon Artist
Copyright/Reference
Fantasy Frenzy copyright 2015
Matthew Tjarks
Backstory:
Sound Bite
A blacksmith must outfit an
entire army before the kingdom he loves is no more.
Executive Summary
Fantasy
Frenzy is a fast-paced time management game set in a fantasy kingdom besieged
by their enemies. The player plays a blacksmith who is tasked with outfitting
an army with weapons and armor, and he has the ability to enchant and enhance
them in different and perhaps unexpected ways.
Inspiration
The inspiration for Fantasy
Frenzy came from my enjoyment of Time Management games, despite being primarily
marketed and themed for younger girls. I wanted to create a time management
game that had a more neutral theme, as well as adding in another layer of game
play in the battle system for more depth. Although my game is still targeting
females, I hope the theme is neutral enough to also be able to bring in males
as well to this genre.
Ideal
Ideally, when finished,
Fantasy Frenzy will have both the Time Management half and the Battle half of
the game and they will be tied together for a more fully realized game. The
graphics would be completely overhauled to fit together tighter and be more
colorful and playful, as this should be a fairly light, fun game.
Demo Scrrencast
The Critique: What went right…
Design & Aesthetics
The
aspect of the aesthetics that went the most right was the user interface. I
feel that the user interface is very clear and communicates to the player what
is happening in the game well. Some improvements can still happen in this area
for sure, in particular, adding a graphical representation of the time
remaining as well as the score. In particular, the "thought bubbles"
over the items to indicate where they should go next worked very well. The user
interface went through many iterations from the beginning, since I did not have
a solid concept of what it should be from the beginning, as is illustrated in
the pictures below. The controls also feel very good and appropriate for the
game and the devices it is targeting. The music does a great job evoking the
right mood. In the menus, it is slow, subdued, and relaxing. In the game, it is
upbeat and happy, evoking exactly the mood I want for this game.
 |
| Mockup interface (top) vs. Current interface (bottom) |
Project Management
The use of Git as source control went very well, and helped me keep
tasks short and focused. This helped a lot as I can be known to jump around
between features. Forcing myself to make sure one small task, generally part of
a larger feature, was done and tested before moving on allowed my game to
progress more rapidly. Along the same lines, the weekly deadlines helped ensure
that the project was always making some sort of progress every week.
Development
I was able to implement almost every feature that I had scheduled to
complete during the capstone. Working in Unity enabled me to rely on a lot of
systems already in the Unity engine so that I did not have to reinvent the
wheel. Architecture decisions made early on in development, such as using
anchor points rather than relying on a specific asset for game functionality
meant that I could more easily swap assets and add anchors without too much
effort, and entirely within the editor.
Testing
For what i was able to test, it was very successful. Unit testing in
particular helped ensure that my classes did what I expected them to do. The
Unity profiler helped track down a performance bug that I was aware of from
fairly early on, where the game would drastically slow down when opening and
closing my recipe menu.
Demo Screencast
The Critique: What went wrong…
Design & Aesthetics
The
graphics in particular could still use quite a bit of work. When starting this
project, I did not anticipate nearly the number of assets that would be needed
for this type of project. I also figured I would be able to more easily find
good assets that fit my theme. Not many people, as it turns out, make assets
for the inside of a blacksmith shop, and so I had to use what I could find.
This meant that many of my assets are disjointed and do not fit well together.
Going forward, I would want to hire an artist to completely overhaul the
graphics to be more colorful, as well as to stylistically fit together more
cohesively.
Project Management
The
project I believe was poorly scoped from the beginning for the time I would
have to complete it. My initial design was far too large for the capstone, and
so we focused it down to just the time management part of the game. Going back,
I would likely have had a much more reasonable design for a game that could
have been started and finished in the time of the capstone project.
 |
| The bloated GameManager |
The
weekly milestones were also poorly scheduled. Some features scheduled for a
week of development were almost trivial, while other weeks there was far too
much scheduled. While this ended up being smoothed out over the course of the
project by working ahead and rescheduling, better time estimates from the
beginning would have greatly helped in creating a better schedule for the game
from the beginning.
Development
The
majority (>60%) of my code ended up in a single class (GameManager), which
was also singleton. This helped me solve problems faster, and allowed scenes to
more easily talk between each other, but made many sections of code dependent
on each other and on the singleton to function. If I changed one thing, many
parts of the code had to change with it. Toward the end, I was better about
segmenting my code, and only having dependencies where necessary. In future
projects, I plan to make this a priority, and to not allow a single entity to
control so much of the game.
Testing
Unfortunately,
testing for this project did not come until very late in the development cycle.
At this point it became a huge burden to test large sections of my code, and
even if they were tested, there would have been too many dependencies to
guarantee that it was being tested properly and fully. In future projects, I
plan to start testing much earlier in the process, in order to create better
tests, better code, and to spread out the work of writing tests over time.
Summary:
My
goal going into this project was to simply complete a game from idea to design,
and through to development. For the most part, I have succeeded at this goal.
Although the game is by no means complete, and has a lot of work to be done
still, the core idea of the time management game is done. From here, I plan to
continue to work on the game, first finding an artist to begin working with on
assets, and then developing the battle portion of my game. Although I am happy
with my game so far, if I were to start the capstone over, I would have done a
much smaller game that could have been done with less assets in order to see it
through to completion within the span of the capstone months.
References
Bartle, R. (1996). Hearts, Clubs, Diamonds, Spades: Players Who
Suit MUDs. Retrieved from: http://mud.co.uk/richard/hcds.htm
Tjarks, M. (2015). Fantasy Frenzy
[Android game].
