Last September I wrote a blog post introducing Invader Zurp which revealed a little of the back story on how I came upon this new game idea after it’s first 2 months in development. Fast forward to 3 months later and Invader Zurp had just hit the App Store! I thought it would be useful to sit down and review the last 5 months of development, kind of plan out where I want to go from here and go over the events and insights that I thought were most influential during development.

The Story So Far…

So to recap the original blog post a bit, it was the middle of the summer (2011) and I had been working my brains out on Cannonade for the previous 6 months. I was a little discouraged at that point because progress wasn’t coming quite as quickly as I had hoped. Reception from my testers (just friends and family at that point) hadn’t been as positive as I had wanted either. I still had a very clear vision of what I wanted Cannonade to be and still believed that there is a ton of untapped potential for multiplayer-only games on iOS. But there was only so much I that could do as a one-man team and testing a multiplayer game can be quite time consuming. I took the family on vacation in early July and was able to step away from things for a while. It was then that I got an idea for a single player experience that distilled the core gameplay mechanic of Cannonade down to it’s essence. Thus Invader Zurp was born. Within two weeks I had modularized the Cannonade game engine, re-written the graphics sub-system in OpenGL ES 2.0 and had a working prototype. And it was fun! I found myself on very long “testing” sessions playing even after I had verified my fixes. I seeded the first alpha version in early September and wrote the introductory blog post. Then began the journey of finishing the game and kicking the darn thing out the door.

Feedback Lesson 1: Make Written Feedback Easy

I got a lot of really great feedback from my testers all along the way. I learned two very valuable things about feedback through my experiences with Invader Zurp. The first was that you really need to make it dumb easy for people to give you WRITTEN feedback. A lot of my friends would give me awesome feedback when I saw them in person but for the life of me I wouldn’t be able to remember it even the next day. I got on the beta list for the TestFlight SDK and start integrating various features into Invader Zurp. One of the most important functionality that I saw in the SDK was a one-line (of code) feedback dialog. I added an obnoxious red “Feedback” button into the app and made it pervasive except when the user was actively playing the game. This button brought up the TestFlight feedback dialog where they could write to their hearts content. The floodgates opened. I started getting a lot of feedback. Most of it was pretty short, just stuff people had noticed in the moment. But it was those little things that people would not have remembered to tell me later that really helped raise the polish level in a lot of places.

Feedback Lesson 2: Take Individual Opinions As Part Of A Whole

The second important thing I learned about feedback was that any individual person’s opinion needs to be treated as a part of a larger set of feedback. I had friends tell me very confidently that things needed to be this way or that way. My friends are really smart and know what they are talking about and so I would start to worry that maybe I was on the wrong track and I really should change course (sometimes drastically). However, once I took that individual nugget of feedback and put it up against all the other feedback I was getting I was able to remove my more emotional reactions to it and look things more objectively. This meant that even if my friends were right and I was wrong, I could deal with it in a better way by understanding how it fit in to the entire picture of collective user reaction. I could see patterns emerge across multiple testers that indicated that a particular piece was either very wrong or very right. I wasn’t doing game design by committee though. I still took minority advice sometimes when I felt it was the right thing to do and ultimately I had to veto some majority feedback when I truly felt that it didn’t mesh with the overlying game vision. I was willing to try anything though and I did in fact implement a lot of crazy feedback that my testers gave me just so that I could see what it felt like in action. An idea on paper and the same idea in implementation are often completely different things. I mean, just look at the “it’s just a big iPod Touch” iPad.

Building A Game For Me

The overall gameplay concept of Invader Zurp was originally inspired a lot by Ikaruga. Ikaruga is a game that you can completely play through in 25 minutes. But the REAL game is not simply completing the levels from start to finish, but rather it’s mastering the intricate chaining system and racking up huge scores. I thought that this was a really deep gameplay mechanic. One that really wouldn’t be appreciated unless the player invested some time into it. However, this deeper gameplay and Ikaruga as a whole is not regarded as being a very casual friendly game (casual gaming being what the iOS App Store seems to reward a lot). Treasure (the developer) is well known for catering towards the more “hardcore” elements in gaming. I initially designed Invader Zurp in a similar manner to Ikaruga in that you could easily burn through all 100 waves of structures in about 20 minutes. The REAL game and the mechanic that would add substantive depth would exist in a system that rewards you for making tricky mid-air block hits. Anyone could shoot the blocks and destroy the towers but it took real skill to hit things in such a way that the blocks would pop up into the air and you needed to be lighting fast in order to target them before they hit the ground. Doing so would reward the player with a lot of points. Coupled with this is an automatic upgrading system that directly ties to your score, the maximum number of missiles that you have to shoot, how fast the missiles regenerate after being shot, how fast your shields regenerate and how powerful your missiles are. The idea was to have a nice smooth power ramp up. You start out with only a few, slowly regenerating missiles and as you get more points, you gradually upgrade to become an uber powerful, unstoppable destruction machine. The thing is that you need to make sure you are scoring a lot of points so that your upgrade curve stays ahead of the difficulty curve. The waves coming at you steadily increase in turret number and rate of fire and so if you don’t make sure to rack up tons of points along the way you will eventually not be able to keep up with the onslaught. Learning the point-heavy, mid-air shot skill is really important because it compounds on itself very quickly. The more points you get, the more upgrades. The more upgrades you get, the higher potential for you to be able to milk points and stay in the game. At this point in development the player always started the game with the same upgrade levels every time. Because of this you could very clearly observe your own skill increase by seeing how far you got before death or how high a score you were able to rack up before finishing the game. It was a very pure game concept that I enjoyed quite thoroughly.

Building A Game For The Masses

However, like Ikaruga, this mechanic’s hardcore simplicity didn’t appeal to everyone. Many people thought it was too simple and they said they didn’t feel like they had a reason to play it again once they got a little taste of it. They kept wanting me to put in more stuff and add more to complexity to the gameplay. I didn’t want to complicate things up though. I wanted to keep things “Fruit Ninja” simple and I felt that every added gameplay intricacy would need to be baked in for a long time to see if it really worked in the game (idea vs implementation). I had a long talk with my friend Reed Olsen about it one day. We talked a lot about what kind of games are successful right now on the App Store and what kinds of psychology they were tapping into to breed their success. I didn’t want to simply follow a pattern and become a “me-too” game, but there were many clear examples of gaming hooks that were extremely effective in getting people to play and continue playing that I couldn’t ignore. I thought long and hard about these and tried to find a way to integrate some without losing the gameplay essence I had already refined. After a long period of agonizing I decided to test out an in-game currency system. This added a very valuable psychological hook of giving the player the feeling of progress every time they played the game. Regardless of whether they did poorly or totally rocked it, their total accrued money would still go up. They would be farther than they were last time. They would feel accomplishment. I was wary of adding this element to the game mainly because I didn’t want grinding to ultimately overcome skill and I was also keenly aware that in-game currency systems (especially the ways in which they are implemented in freemium games) are distasteful to many in the gaming community right now. But I decided that I was going to be willing to give anything a try. I allowed the player to purchase upgrades outside of the gameplay that would increase the base level that their in-game upgrade levels started at. This meant that I had to adjust the difficulty curve up so that the player would need to save currency up and purchase upgrades to (realistically) be able to finish the game. No longer would a very skilled player be able to just waltz in and finish the game with just the initial upgrade levels. They would need to put in some time and work to get accomplish that goal. In practice I found that this worked fairly well at providing a hook for the less “hardcore” players and didn’t detract as much from the pure gameplay mechanic as I thought it would. I eventually had to bump down the maximum missile regeneration level because once the player had max’d out all their upgrade levels they basically became an unstoppable block-killing machine. Skill kind of got thrown out the window for the high end players at that point. After making some small adjustments to the max upgrade levels I found a nice sweet spot that made the player feel like through their efforts they had grown into a powerful, planet ravaging machine but still left room for the high end players to compete against each other with their pure skill.

Further Motivation

Another gameplay addition I developed grew out of a conversation with my friend Mike Smith. Again, he wanted some additional gameplay element to increase the complexity and I was resistant. But in the course of our chat we came up with an idea that I thought meshed really well with the existing mechanic and wasn’t confusing or overwhelming. The idea was suggested that I hide three special blocks in every wave and tie some sort of bonus to hitting all of them. This was really appealing to me because it was super easy to implement and addressed a major complaint that a lot of people had up to that point which was that they always felt like they were out of missiles. I decided to put three shiny gold blocks into every wave and give the player a full missile reload if they were able to hit all three. This meant that now there was now an opportunity for a full missile reload at pretty much every moment. The player now had to balance whether they were going to take the risk of spending ammo to go after the gold blocks or write them off. It was a great improvement on the gameplay and also allowed for another progress-based psychological hook. I could keep track of how many blocks the player got in each wave and record those in a running stats menu outside of gameplay. That way the player can see the progress they are making towards getting all the gold blocks in every wave. This kind of optional “collect” mechanic is used to great effect in tons of games these days (in my mind most notably in the Mario franchise). I then layered on an additional mechanic of keeping track of how long the player can maintain getting all three blocks in the waves in a row and giving a bonus missile damage multiplier as their streak increases. This seemed like a very easy element to simply layer on that would add depth without adding complexity and confusion. I then did a similar thing with enemy turret destruction streaks and started keeping track of those stats as well. The feeling of having your accomplishments recorded can be pretty powerful and very motivating to people with completionist mindsets which brings me to the next element I layered on.

Achievement Unlocked: Make 50 Achievements, Ship Game

Achievements are a no-brainer. They are super easy to implement and you get a lot of psychological mileage out of them. I found that coming up with crazy achievements and writing their humorous descriptions was some of the most fun I had during the development of Cannonade and Invader Zurp. It is well documented that having a lot of easy early game achievements can do a lot to keep people invested in your game and motivate them to keep playing. Coming up with a nice curve of achievements for the beginners, intermediate, advanced and insane was pretty fun and actually not that hard. I didn’t need to worry about giving any skill level too many. I could just make whatever achievement popped into my head. I loved coming up with really random ones that players would accidentally run into during the course of the game. “Huh? What was that achievement? Eh whatever, cool!“. I was really proud of a lot of the locked/unlocked achievement descriptions that I came up with. Unfortunately Game Center has visually small spaces in their app to display those descriptions and so anything more than just a basic description gets truncated. So when perusing achievements, be sure to do it in the in-game menu where you can view the “Director’s Cut” achievement descriptions.

Future Plans

I had a lot of other cool ideas that I wanted to implement in Invader Zurp but I knew that I needed to pare things down and determine my exact 1.0 feature set or else I would never get around to shipping (“Sometimes you just need to shoot the engineers and ship the darn thing“). I had a lot of ideas like:

• In-App purchase to allow people to buy in-app currency (kind of a given these days on the App Store).
• I also wanted to rip out and incorporate the Cannonade level editor (what I used to make all the levels) into Invader Zurp so that the players could design and ulpoad their own building designs and have them trickle down into the game. It would be really cool to see a different set of towers every day, each with a little “Designed by GamerX” credit under their announcement title.
• I want to have alternate missile effect sets like psychedelic rocket contrails or themed missile explosions like a burst of hearts when missiles explode for Valentine’s day.
• I wanted to have a lot of analytics hooks and an App Store release “Feedback” button that the players could use to interact with me.
• I also wanted more Zurp character art, iCloud save game support, Game Center avatars, Twitter integration and a lot of other little things.

Many of these will find their way into a future update. Just need to prioritize them correctly.

Submission Deathmarch

About a month before release I was talking to my friend Mason Sheffield about what I felt I needed for a 1.0 release and how far off I thought I was. He challenged me to get 1.0 on to the App Store by Christmas (2011 ;)). I thought was a really unrealistic target. I looked at what still needed to be done and saw an unsurmountable mountain. But December 25/26th is the biggest day of the year for the App Store and it was also ahead of my own in-head release target. I decided that this challenge was just the kind of motivation I needed and it put a fire under me. The App Store review team was going to be shutting down on December 22nd and I thought that during this season there would be a lot of other developers also trying to make the deadline in order to get on to the App Store before Christmas. I conservatively estimated that a review would take two weeks and so that put my submission deadline at December 8th. So for the last month of 1.0 development I worked like crazy and started aggressively cutting things right and left. About two weeks before the deadline I hit a moment when I realized “Hey, this thing is actually coming together! I might actually make it!”. I was quickly heading toward the light at the end of the tunnel. I was seeding every two or three days (much faster than my usual goal of once a week) and felt like I was running a marathon. Soon enough though the day of truth arrived. I actually decided then to give myself two extra days to finalize a couple of things and squash as many bugs as I could before submission. On December 10th I finally submitted Invader Zurp version 1.0 to the App Store. It was amazing how many truly egregious bugs I found on the day of submission and was thankfully able to squash them right before submission. I figured that I would probably get approved (fingers crossed) just in time for December 25th and that would give me enough time to make a website, gameplay trailer and find reviewers to give promo codes to. To my surprise, only four days later the iTunes Connect app on my phone buzzes to tell me that Invader Zurp is “In Review” and only 40 minutes later it changed to “Ready For Sale”. This was a nice surprise and actually caught me a little off guard! So now that the game is finally for sale the time has come to start promoting it and preparing for the first update. I definitely want to be in the league of other great games that have quality content/features in every update. I want my users know that when they get an update from me it’s going to be something new and good to explore. Aright, enough writing, back to work!

(Interesting side note: I found out during app validation that you can’t submit an app with an unresolvable symlink in it. I was doing this intentionally though. Email me if you want to know why.)

This entry was posted on Thursday, December 15th, 2011 at 7:47 pm and is filed under Achievements, App Store, Bullet3d, Cannonade, Debugging, Game Center, Games, Graphics, Hacking, Humor, Indie, Invader Zurp, iOS, iPad, iPhone, Marketing, OpenGL, Performance, Postmortems, Programming, Psychology, Startups, Video Games, Weaponry. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response.