Capstone Game Post Mortem: Wreckage

Capstone Game Post Mortem: Wreckage

 

Game Summary

Game App Icon

Title

Wreckage

Genre

Strategy Builder
Arcade style Shoot-em-up (SHMUP)
Hybrid

Platform

Android

Revenue model

Free-to-Play – Extra life for a token

Development tools/Language

Unity with MonoDevelop and C#
SourceTree – GIT repository management
Trello – mobile kanban-style task notes
Parse – cloud database services
Pixabay – public domain sprites

Game audience

25-50 year old American males

Team

Nick Penney – Design and code
Andrew Trahan – Music and sound effects
Pascal Duverger – Logo and character art

Copyright/Reference

Wreckage © 2015 Nick Penney

Backstory

Sound Bite

"In order to salvage, you must first destroy."

Executive Summary

Wreckage is an arcade style space shooter game, where you are battling against the creations of other players so you can steal their technology and use it to build your own mega boss. The game is a mash up of the shoot-em-up (SHMUP) and strategy builder genres of games. (Ikaruga meets Dungeon Keeper)

Unique selling points include the ability to build and upgrade your own boss character, fighting against player-created bosses, better controls than most mobile shoot-em-up games, and persistent ship upgrades for more comfortable casual play.

Inspiration

The inspiration for this game comes from many different disciplines and experiences, including other games I have played, movies I have watched, and books I enjoyed reading. I wanted to add a spin to the typical shoot-em-up game, which is salvage mining and construction. The bite size game-play of the mobile game experience lends itself well to this idea.

Capstone Game Scope

The development plan for this game was to complete 1/3 of the project during my capstone and have a playable demo to put in front of users. This was done so that I could gain valuable feedback and minimize financial risk. I was able to surpass this goal, getting almost halfway done, and still had time to implement many suggestions given through user feedback. This was largely because I found other people during testing, most of whom I had just met, volunteering their time to work on the project with me.

Ideal

The ideal for this project is to continue development past the capstone and publish. My team is the main driving force in this becoming a reality. If they continue to volunteer their time, I would happily continue working on it with them.

Demo Screen-cast

The Critique: What went right

Design & Aesthetics

The primary game mechanics work well for this game. The input mechanics work well, and people love the idea of touch-up pausing. The majority of work relating to final art was scheduled for post-capstone development, but we managed to get a good portion of it done ahead of schedule and put it into the game demo.

 

Project Management

This project was managed quite well. The time estimates were well considered and I was able to accomplish all my project goals on time. Having weekly milestones and screencasts due each week provided just the right amount of pressure to maintain sustainable progress without getting in the way. Using GIT for source control management was great and definitely saved the day on a number of occasions.

Development

Unity was a joy to work with. I really like working with the new GUI system that was added in the latest release of the product. The anchor system made working in different resolutions easy. I was also able to drop the parse.com module and other third party scripts into the editor with minimal effort.

Testing

The A/B testing we did in the testing class shed some light on the utility of post-deployment tweaks that were possible. This was even further enhanced for my application, because it is already largely cloud based. I got the idea to use a cloud based string table, which can be modified for usability without having to redeploy the application. I also store a good amount of object properties in the cloud so I can A/B test them and deploy appropriate tweaks for game balancing.

The Critique: What went wrong

Design & Aesthetics

Clearly conveying the purpose or message of the game without a lengthy diatribe is something a good number of games suffer from, and this one is no exception. Because the primary selling point of this game is divergent from the average SHMUP, users who picked up the game for the first time had no idea what the point of the guardian character was. I had implemented an in-game help system, but they largely ignored its existence and chose instead to forge ahead blindly. It was foolish of me to assume 25-50 year old American males would bother with directions when they didn’t know what to do.

Project Management

Defining deliverables for artists to produce is something I have never done before. The first few artists who agreed to work on the project with me were inexperienced and ended up drowning in too much creative freedom. It wasn’t until I had a conversation with an experienced artist later in the development cycle, that I realized this was largely my fault for not providing specific enough constraints to give them the push they needed to succeed.

Development

The Unity Editor WWW stack on OSX suffers from a flaw in decreasing timeout durations, which means that I need to restart the program any time I want to run my game more than once. This continues to be a source of endless frustration for me, and I have to rely on hardware or standalone apps whenever I need to do end-to-end testing.

MonoDevelop offered another hurdle for me, because I was using asynchronous threaded tasks to connect to cloud code. When debugging with MonoDevelop, it would freeze whenever it hit one of these task statements. For this reason, I was only able to attach the debugger after the login process was completed. This led me to rely heavily on caveman style debugging techniques to debug any issues with the cloud code, as the debugger was unable to be used.  A free third party Unity plug-in called Log Viewer helped with this.

Testing

Our academic schedule was such that testing was in month 3 of development and I found that bootstrapping unit testing onto an already developed game proved to be largely fruitless. There were only small portions of code that were testable, due to almost everything being already developed as a mono behavior and attached to a Unity game object. Luckily this won’t be the case for future students, because the program outline has already been revamped to incorporate the testing curriculum earlier.

Summary

 

The development of this project has been an enjoyable experience. I knew going into the project that there was only so much I could accomplish, due to my schedule being limited by work and family obligations, so I selected a project with appropriate scope. I picked something I was interested in and knew that I could accomplish, but offered significant technical challenges and learning opportunities. I was lucky to run into both an audio engineer and several artists during the course of testing my game, who volunteered to do some work to contribute. This was not part of the original plan, so I am excited that the game has improved as a result, and I am happy with what we were able to accomplish. 
 

References

Log Viewer. (2014). What you see in the editor console is what you get in the game screen. [Unity Plugin]. https://www.assetstore.unity3d.com/en/#!/content/12047

Parse. (n.d.). The complete mobile app platform. [Website]. https://parse.com

Penney, N. (2015). Wreckage. [Android Application].

Pixabay. (n.d.). Free high quality images you can use anywhere. [Website]. http://pixabay.com

SourceTree. (n.d.). A free Git & Mercurial client for Windows or Mac. [OSX Application]. http://www.sourcetreeapp.com/

Trello. (2014). Trello - Organize anything. [iOS Application]. Retrieved from https://itunes.apple.com/app/trello-organize-anything/id461504587

Unity. (n.d.) Unity – Game Engine. [OSX Application]. http://unity3d.com/unity/download