So, right on time, the first alpha for Firehawk: Blades of Freedom is released.

Firehawk is an old school top down shoot 'em up modeled a bit after Raid on Bungeling Bay, although Firehawk doesn't quite have the same level of depth despite being released 30 years after! I have some plans to rectify that, but since I'm a man that lives or dies by deadlines, I knew I had to get something out by December 31st of 2017 (officially one hour in the past as of this writing). Without constraints it's easy to lose sight of your goal and make no progress, and that's a trap I didn't want to fall into. All in all, things came together pretty well, and more-or-less on schedule despite some road-bumps.

So, on to the backstory and postmortem for alpha.1.

Background

Firehawk: Blades of Freedom is a game whose origins lie in a 2016 New Year's resolution: release a relatively playable game before the year is out. So, why did I start so late, after more than half the year had gone by?

The simple answer is, "I didn't."

Originally I was working on another game, a platformer with stealth mechanics. Here's a shot of an incomplete level mockup:

This, codename "Sneaky Pete," was originally to be my 2017 foray into game-dev. Unfortunately things didn't quite work out the way I'd planned. Due to the complicated animations I had envisioned, as well as the artist's tight schedule, I forecasted that I wouldn't be able to get Sneaky Pete to a playable state by the end of 2017. Now, I could have taken more time, and given an additional 3 or 4 months (March, April 2018) I'd have a working game... in theory. Without having a deadline to adhere to, there's no real sense of urgency. I don't necessarily need a deadline to work toward in order to get things done, but I still think its important to have a goal --in this case,  a concrete number on a calendar -- that you work toward. It's easy to go off the trail to investigate a new shiny thing in the underbrush when you don't have a clear goal ahead of you.

So, in early July, I started another project: air_assault, or as it's published here, Firehawk: Blades of Freedom. Since I only had 6 of my originally planned 12 months for development left, my design document focused on two crucial elements: an extremely simple concept, and a streamlined workflow to get art into the game as quickly as possible. 

That said, I never intended to slap something together and call it a day. My personal belief is that if you don't take a project seriously then you may as well not do it at all. By "seriously" I don't mean grim and dark, just that you're giving it your all and not pulling any punches when it comes down to the raw act of creation. 

Me? I'm taking these games as seriously, because if I didn't, they might never see the light of day. I suppose that's why I'm writing this postmortem with game downloads attached, rather than not.

Planning

Before I wrote a single line of code, I spent about 7 days sampling gameplay footage on the web. There's a lot of game genres out there, and I wasn't going to delude myself into thinking I would come up with a type of game that hadn't been invented yet. Given how complex some games are these days, I stuck to going through archives of old Commodore and Spectrum games. Due to hardware constraints, these games were pretty simple, but that didn't mean they weren't fun.

I ended up with quite a few ideas, but I went with a top down shooter concept because those never go out of style, and when it comes to the actual code implementation they're pretty simple games to model. As for actual details and theme, I settled on a helicopter / jet motif, with air enemies and ground enemies. That meant that I could get away with moving the player over terrain instead of around it, thus simplifying things quite a bit.

Idea in hand, I sketched out how I was going to proceed with the project.

When it came down to the art side, these are the decisions I made:

• Do most or all of the initial art myself, and get an artist in at the last minute to replace or touch up the work.
• No fancy animations that require keyframing or code-integration.
• Spritesheets are organized in a predictable manner, so that they can easily be swapped out for fast content creation. Here's an example: 
• Organizing the content pipeline in Trello, rather than relying on teaching someone how to use Git, or figuring out a way to use Dropbox without accidentally creating file conflicts. When the art is ready, just upload a file in Trello -- easy to do (drag and drop), easy to see (Activity History pane), and easy to review (comments on cards).

When it came down to the code side, these are the decisions I made:

• Prototype first, clean up later. It's better to have something working poorly but right now versus working and next week. All things equal, this makes it easy to throw away features that aren't working out.
• The most simple implementation wins. Don't code for the future "what if's," unless I'm 100% sure that the future is about to be an hour from now.
• "30 man days" was how much time I wanted to budget for the project. That is 240 hours.

So, how did it go? Well, you tell me. There's a game attached to this post, after all. Keep reading to find out what went right and what went wrong in the dev cycle.

What went wrong

Godot.

Godot is a great open-source game engine, but the 2.x branch is just chock full of bugs. Normally this isn't a problem with open source software, but in this case Godot has a strange release schedule where they do monstrous 1-2 year release cycles, and no breaking changes are allowed outside a major version. Because of that, a lot of the bugs I personally encountered were languishing on the Github issue tracker for several months (at least a year, at one point), due to the need to make a breaking change somewhere.

I could work around most of them with some effort, but eventually I hit a mysterious -- and apparently unreproducible -- bug in the engine regarding threading. I did the monster math, and after realizing that if I hit any more bugs of this caliber, or just a bunch of smaller ones, there was a good chance I wasn't hitting my deadline.

Ultimately I switched to Unity mid-project, and lost about 2-3 weeks picking up the idioms after sloppily porting the code over.

Getting access to early art.

By chance, I connected with pixel artist who was interested in, you know, doing art for Firehawk. Looking back on it, I would have definitely postponed refused offer until I had more of the game fleshed out with my prototype art. With an artist on board I more-or-less left them to their own devices after handing off a rather sizable list of art the game would need, and went immediately into game mechanics. Crucially, I never bothered doing a thorough check over the essential art pieces to see if all the "must haves" were complete or in-flight.  When life inevitably interrupted the artist, I had to quickly decide what I was going to do and how I was going to do it.

Fortunately there was enough essential art to cobble together the game as you see it -- I did end up doing some minor editing on the tilemap, but it only cost me 2 or 3 hours.

Work.

My work had a rash of "WE MUST LAUNCH ON FRIDAY AND NOT A MINUTE BEFORE!"s, for no real discernible reason that I could gather. 

You know what happens when you launch on a Friday?

You work on a Saturday.

You know when I mostly had free time to work on Firehawk? You guessed it: Saturday!

What went right

Godot

Godot is a great open-source game engine, with a dedicated 2d engine. It saved me some great time in the beginning, since I didn't have to worry about any of the quirky rendering issues you can get with Unity games at low art resolutions. It's "everything is a scene" approach also helped me quickly assemble reusable game components that I could throw onto an object to achieve certain behavior.

Unity

Using Unity is basically bringing a chaingun to a knife fight. You usually don't need it until a 100 duck-sized horses show up and things get messy.

That aside, Unity has everything you need to make a game, if you're willing to write everything from scratch. In the cases you don't (specific domain knowledge, or just expediency), the Unity asset store has great, cheap, and most importantly, reusable tools that can be brought from project-to-project. Some of the stuff people have made inside of Unity amazes me.

Also, Unity Collaborate was great for the short period I used it with the artist.

The simplified spritesheets

The art decisions I made early on definitely paid off in the end.  Simply being able to slot in some art -- no rigging -- was invaluable in getting things going again in Unity.

The Time Budget

In terms of development time taken, I think I came in at around 200ish hours total, spread out across mostly weekends (and some pretty boring Friday nights). Having close to 0 experience in Unity, I spent maybe 40-50% of those 200 hours just picking up the engine. It was a pretty stark transition to go from Godot to Unity, but I pulled it off.

The Code

Although this alpha release itself is pretty simple, most of the code under the hood is extensible. I can turn a few knobs and make any projectile homing; I can adjust the existing enemy AI behavior or add new behaviors in 30mins or less. The initial port from Godot to Unity was sloppy, but over time I shaped it into something pretty powerful. I can focus mostly on bug fixes and content addition without having to worry about breaking current functionality.

These videos.

These two videos proved to be an incredible resource, and definitely improved my overall workflow and Unity architecture. They definitely helped to avoid some issues I would have had down the line if I had been less careful.

"Overthrowing the MonoBehavior tyranny in a glorious ScriptableObject revolution"

"Game Architecture with Scriptable Objects"

The Deadline.

While stressful, the arbitrary deadline definitely contributed to the actual release of an alpha version of Firehawk. There's so much more I want to add to the game, but without a deadline looming I might have worked on this thing for a long time without it ever seeing the light of the day, if it ever did.

Closing

I've probably missed a bunch of things that will only come to me in my sleep -- that's how things always are, right?

Right now, it's 2:45am, and I'm looking forward to a short break before I get back to work on Firehawk.

See you then,

and have a good 2018 if I don't.