Fortress was a failure. That’s not necessarily a bad thing, but it was a failure. Let us acknowledge at least that, and get to learning some lessons.
First, in the interest of proper postmortem formatting: Fortress is a turn-based strategy card game designed to be played with a standard deck of cards. Each player receives one King and half of the remaining cards above 7 (including the two remaining Kings). Each of these cards represent a soldier with an Attack and Defense rating based on its face value, suit, and whether its suit matches the player’s King or the opponent’s King. Players use these soldiers to attack each other’s fortresses and try to destroy each other’s Kings. Cards valued Ace through 6 are set aside and used in place of a six-sided die during attacks.
Fortress was developed primarily by one developer (me), with art and music assets contributed by two contractors, both rookies at game development like myself. These individuals began the project under contract for shares, which I eventually bought back for various reasons. Overall, everyone got along well, with some friction I’ll expound on below.
The game was targeted from day one for iPhone OS (now simply iOS). All coding was done in Xcode, using the cocos2d package for graphics and audio.
What Went Right
1 – Based on a well-honed card game: Fortress had existed as a card game for over four years before I began making the video game version. Because of that, the gameplay was already tried and tested. The card game essentially served as a paper prototype.
2 – Early beta: I didn’t hesitate to put the game in front of people. The beta began well before the game was even remotely stable, and had dozens of eyes on it from the beginning. Feedback came early and often, and a lot of poor design decisions got backed out before they could do any lasting harm as a result.
3 – Cohesive art direction: Both contractors took direction extremely well while making their own contributions to the game’s creative vision. The graphic artist in particular had to adapt to my cartooning style, and successfully combined it with his own methods to create a silly, lighthearted motif that I hope will influence all of my future projects.
4 – Robust audio: The same goes for the musician’s work. I’m a mediocre composer, myself, but Ryan was able to take my meandering whistles and doot doot doots and transmute them into something with some meaty weight while still fitting into the upbeat feel of the visuals.
5 – Ambiance: I have to be fair. This part didn’t get done before the axe fell. But it would have been awesome. The game was meant to be accompanied by quiet ambient noises punctuating the unbearable silence of a long siege, with a slow day/night cycle gradually fading the play field from sunrise to sunset and back again. Chirping birds, nervous men clanking as they adjust their armor, crickets, lapping water. I’m really sore that I never got this done, actually.
What Went Wrong
1 – Friction within due to differing styles of time management: I’m more right-of-center when it comes to deadlines, while the artist leans more to the left. I prefer to have set milestones that I can count on being hit on time, Parker prefers to let things flow and not get stressed (and I can’t say I disagree). This caused a bit of friction in the beginning, but we hugged it out early and I agreed to loosen up on deadlines on the condition that Parker come through in a timely manner. I still prefer to hit milestones where possible, especially when there are dependancies on assets that are holding up a project, but in this case, the compromise led to less stress and better productivity in the end.
2 – Early beta: I went to beta way too early. A lot (maybe most) of the feedback during the first two or three beta versions ended up being about stuff I was already planning to fix for subsequent pushes. Lots of time wasted as a result. Guys! Stop Pressing Buttons! absolutely will not go to beta until it is feature-and-asset complete, so the focus can be on bugs and balance where it belongs.
3 – Tutorial: The tutorial was an unmitigated catastrofuck. Text text text text text. Boring boring boring boring boring. Nobody had the patience to sit through it, and so no one understood the inner workings of the game. For G!SPB!, tutorials will use as much pantomime as possible. I may even go all the way to making the entire tutorial text free.
4 – No prototyping led to poor architecture: The game’s code base was unsound from day one. I ran with a “just make it work” mentality from the moment my fingers first touched the keyboard, and almost every line of the resulting mess ended up being the foundation for the entire game model. I was also still coding like a college kid, which means the game is saddled by layers upon layers of inheritance. To be fair, the game is heavily state-based and event-driven and probably wouldn’t have benefited in any world-changing magnitude from a more component-based architecture. Regardless, these sloppy coding decisions should have been part of a prototype, not the finished product.
5 – Mental health: By a wide margin, this is the big one. Everyone who’s read my blog before knows I have to wrestle with my brain to get it to cooperate. I’m getting better at it now! But during most of this game’s development, I spent more time depressed and procrastinating than I did working. I’m optimistic that this will be less of a problem in the future, but it’s still a long road ahead. I’m going to have to work really hard to fix these issues.
The End
Fortress was a big learning experience, and I think that’s all I ever really needed it to be. I failed to get my wings in the end, but I put myself in a good position to make a successful second flight. Guys! Stop Pressing Buttons! will get done, and if it doesn’t, I will simply choose a new career.
That sounded a lot more melancholy than I intended. I’m excited about moving on! I swear!
Developers: 1 (me)
Contractors: 2, an artist and a composer
Budget: $1500 – I bought out Parker’s (artist) share for $1000, and Ryan’s (composer) for $500. I’m not counting the cost of hardware or the Apple Developer fee, since I use those for other things outside of this project.
Length of development: 2 or 6 years, depending on how you’re counting
Release date: Heh
Platforms: All iOS devices
Development hardware: A MacBook Pro and a standing desk
Development software: Xcode
Final SLOC count: 12,054 lines of code! WAY too many!






