Capstone Game Post Mortem: Fantasy Frenzy

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].