Welcome and thanks for reading the second Airship Commander development diary. This one covers how the game came to exist, and the process used to decide what to implmenent next.
At the end of 2014 I was working at a company named Dynamighty, and we had just finished shipping CounterSpy. While the executives worked on our next deal, many of us were given opportunities to work on things of personal interest.
There was a great game jam, that actually birthed our next game Fingers of Fury. I worked on a project with the art director, which gave me the opportunity to pick up c# and scripting in unity to bring his assets to life. Building upon this knowledge I banged out a quick mobile game called Moons of Bovis in my spare time. It married the choice driven progression of Starcraft 2 with a game I thought I could actually finish: Space Invaders.
I was halfway through a “sequel in tech” to Bovis when my Oculus DK2 landed. After getting it up and running, one of the first things I did was see if I could get the existing game working in VR. It was pretty straight forward, but the twitch gameplay wasn’t a great fit for the technology. This lead to a swift shelving of the current project, and revisiting my dream game about airships (see last diary).
There are countless methods that result in good games, but you can see a pattern among many of the most successful studios. That unifying trait is playing their own game…a lot. The development process for all of Airship Commander took this philosophy to heart and made it a cornerstone of how our time was spent.
Every day went pretty much the same way:
a) Play the game for 30 minutes
b) Identify the number one thing that would improve the player’s experience
c) Implement that thing you identified
d) Goto step a
In addition, we targeted improvements that impact the core gameplay loop. Whatever the player does in your game 90% of the time is always a safe area to make better. For Airship Commander that’s steering the ship to line up broadsides. Ideas that made this interaction more compelling almost always won priority fights with features less impactful to the moment-to-moment experience.
We were also biased towards tasks that could be finished in a day or less. Working on smaller features that improved the core loop gave the team a great sense of progress every day. There are absolutely times where multi-day projects had to be tackled, but the baseline was high tempo modest improvements.
In the end, this focus on achievable doing let us accomplish more than otherwise would have been possible for such a small team. A couple of months in early 2015 resulted in the prototype you can see in this video:
https://youtu.be/GwJ2hVjwbEk
Most of the Airship Commander gameplay can be seen here. Much of the same code running in the video is still operating under the hood, albeit faster and more stable. Prototyping using primitives enabled lots of mistakes to be cheaply made, and future development will always exist in extensive “greybox” prototypes before committing precious content resources.
The direction of the game’s development has been influenced greatly by all the feedback provided since the Early Access program started. We’ve paused finishing capital ships for the moment and are targeting the next release to focus on room scale and tracked motion controllers. Other valid feedback we hope to address is vessel collision with the environment (buildings, birds) and overall performance.
As always I’m grateful for your time and thank you for reading this update! We’re excited about what’s coming and can’t wait to show more in the coming weeks!
Jeff