Capstone Game Post Mortem: Airship: Wary In the Skies

Game Summary

Title

Airship: War in the Skies

Genre

Tactical Naval Action

Platform

Android

Revenue model

The game is intended to be released for free, with the primary monetization occurring from in-app purchases.

Development tools/Language

Airship was developed using Unity 4.6 as the primary engine. Assets were generated using Adobe Illustrator and Adobe Photoshop. The online components were created using the Photon Unity Plugin. The store components were created using the Soomla Store Plugin.

Game audience

The primary audience for Airship are young adults between the ages of 18 and 25, who have a history of playing online competitive games, or are interested in naval combat.

Team

Avram Suson worked on design and development.

Zachary Haley worked on initial level design.

Jacob Suson created all sound effects and music.

Michael Press, Derrick Snodgrass, et al. created the models for the ships.

Copyright/Reference

Airship: War In The Skies © 2015 Avram Suson

Demonstration Screencast

Backstory:

Sound Bite

As the country’s last hope, only the bravest can defeat the coming tide. Lead your ship to battle for victory in the sky!

Executive Summary

In Airship, the player takes direct control of a flying warship and goes head-to-head with other ships and players. The game offers a variety of vessels and game modes, so that players can enjoy the game, no matter what kind of play style they are looking for. People looking for competition can try the multiplayer arenas, aiming to be last ship soaring. If you’re looking for just playing some solo battles, you can hop into Practice Battle mode to get some practice against the AI. In either case, prepare to get behind the wheel of your ship and guide your crew to victory!

Inspiration

I am a long-time steampunk fan, and have always enjoyed the concept of Airships. One of the earlier games I had made for a quick assignment was a naval combat game with really simple controls. After trying to come up with an idea for a while, I decided to try and enhance the older game, but to change from traditional wooden ships into airships. 

Ideal

The ideal design for Airship is to have an active multiplayer system, with lots of players making rooms and fighting against each other. Similarly, players would be able to experience a story in Campaign mode, or play against challenges to test their capability. The ships would be customizable with a wide array of upgrades and power ups that players would buy and earn. This would also result in each battle being unique and exciting, as players could use power ups at unexpected times.

The Critique: What went right… 

Bug Database

Using the database to track bugs and features that still needed work really helped with keeping the workflow organized and efficient. It provided a list of everything that still needed to be worked on, while also showing what was more critical than others. It also served as a reminder of how much of the work still remained to be completed, and could be used to see how much work had just been completed. It was a helpful tool for keeping me focused on a task and knowing what I needed to focus on.

Development

A lot of the code structure was developed freshly and taught me a number of significant tricks that will be useful for a long time to come. The system that I developed for loading models during runtime turned out really well, and will be useful in the future. Also, the system was developed in a very open-ended way, which allows me to easily add more features and content as desired, which makes the game very easy to expand upon. This is predominantly because of the way the system reads from binary files for the content, rather than relying on the content being hard-coded into the project. This is something that will prove beneficial for expansion of this game, as well as future projects.

Testing

While some of the testing happened a bit too early on, some of the user tests proved really helpful with the feedback and helped show me how the players would interact with the project. While I have done testing before, my experiences with user testing throughout this capstone was different and substantially more useful than my past experiences. I was able to see what caught players’ attention and what didn’t, which allowed me to know how I needed to re-focus my work, or adjust certain features to help players with the game.

The Critique: What went wrong…

Design & Aesthetics

One of the original plans of the project was to try and build our own models, or find models online. However, after two thirds of the project timeline had passed, it was discovered that the team would not get around to making the models, and there weren’t any models of the desired type available online. I sent out a request for model-help and was contacted by a student group working for one of the professors, who offered to assist me with the models for free. I sent them a list of models needed, but the list was too much for the time remaining in the project. Before starting, we should have created a more realistic and solid plan for the assets, and we should have recognized when the asset plan was failing earlier so that it could have been fixed sooner. It is even more critical to catch when the asset plan needs to be changed early, since asset development can be one of the more time-consuming parts of a project.

Project Management

The largest reason for failure with this project was scheduling and time management. When I had developed the plan for this project, I had planned a tight schedule with a little bit of time for debugging at the end. However, as the project went on, some features took longer to be implemented than I had planned. Similarly, there were more bugs than I had expected, and I found myself quickly working to just keep up with the schedule while fighting bugs. It didn’t take long for me to become swamped and fall behind the schedule, requiring large features to be cut from the design to make up for the time to work on the bugs. In the future, I will plan that at least half of the development time, if not two-thirds of the time, should be dedicated to fixing bugs and features.  

Controls

One of the bigger issues that appeared late in development was a problem with the ship controls. This problem primarily appeared after I entered the final review stage, when the reviewers stated that they had trouble with the controls and couldn’t control the ship. This resulted in confusion, because it had contradicted with earlier user tests that I had run. The end result was a series of alternative controls hastily implemented to help the reviewers control their ships. What I ultimately learned out of this was, while testing with the public is still good for development, I needed to test more with the client for my game, the reviewers in this case, and ensure that the product was matching what they desired.

Summary:

Overall, I would say the project is well on it’s way for what I had desired. It is much more of a prototype and proof of concept than a completed product, but most of what remains is implementing assets and content, which can be done over time. There are a few major features, such as a Campaign mode, which had to be cut from the design due to time constraints, and I would want to attempt to implement these before final release. I did learn to plan for significantly more time for debugging, as well as to plan milestones more carefully so that I can spot when an aspect of the game is starting to not meet expectations earlier in the development cycle. I also learned that programming for abstract content benefits development in the long term. Similarly, maintaining a database of issues and features is a great way to maintain organization and focus of a development team. If I had to redo all of this from the beginning, I would probably implement those changes and more properly plan out the project in detail, using the experience I had from this project.