Elusive Ninja: The Shadowy Thief is the first game released by Bulletproof Outlaws, a newly formed “one guy contracting out help” indie game studio. I’ve got some actual industry experience, but BPO is an attempt to go it solo and have more creative freedom and choice in what I create!

Since I was a kid, I’ve wanted to make my own games for a living, and the barrier of entry into the mobile market is so low these days that this felt like the perfect opportunity to give it a go. I signed up for a crash-course in business entrepreneurship and documented everything almost daily all the way from Day 1 of the course till the completion of this first game. There’s over 100+ updates with plenty of behind-the-scenes info on everything from the game’s development, to managing finances, to avoiding legal issues, to game design philosophy, etc. at the Elusive Ninja devBlog.

I’ve always been a big fan of Post-Mortems because I think they help the developers writing them learn to streamline their work-flow and iron out kinks, and they help developers reading them avoid making the same mistakes and learning things the hard way. So on that note, let’s look at what went right and wrong with Elusive Ninja!

What Went Right:

 1) Animation Tool
Before starting the project, I contracted out a custom Animation Tool that essentially works like Flash: I can drag, scale and rotate art around the screen visually, keyframing it to a timeline, and it spits out an .XML file full of coordinates and timings. The game engine reads these numbers and fills in all the in-between frames and information.  Very little in the game is hard-coded, the Animation Tool even calls functions so I can make an attack animation and on the last frame tell it to call something like “checkDamage:ninja:explosive” which’ll run something in the game’s code that checks for collision between the ninja and the explosive, etc. I even use it to play sound effects on certain frames and load other animation files!

This eliminates a ton of “Could you shift that graphic 2 pixels to the left? hmmm…no that’s still not quite right, how about moving it back 1 pixel to the right?” requests on the art side, and eliminates a ton of suicide and manslaughter on the programming side haha It also means the final result looks a lot more like the artist envisions, and in the polish stages the artist can make a lot of changes and tweaks without having to bother the programmer. I can throw a 2 frame walk cycle with a stick-man into the main character’s animation, and then down the road turn it into a 10 frame walk cycle with final art and all the programmer has to do is overwrite the .XML file and re-compile!

It can take a little extra time to develop a tool like this, but the time it saves on a game’s actual development is phenomenal. Having to enter co-ordinates and frame timings in by hand is slow, tedious, and soul-sucking, both on the art and the programming side. I’d like to expand on this tool in the future and I can’t imagine going back to a work-flow that DOESN’T have an Animation Tool!

Thanks to the Animation Tool I was able to cram tons of flashy art in!

2) Work Is Fun!
It really makes a difference to be working on something you enjoy working on. Everything in the game is the way I wanted it, and even at the most stressful points of development there was still an underlying “but MAN is it cool to see this shaping up” feeling. A lot of developers in large companies are stuck working on games they don’t care about or know from Day 1 are going to be terrible, and you run into the same types of stress except it’s more depressing because you know when you finish the game you won’t even be proud of it. I don’t expect this game to make me a bajillion dollars, I’ll be happy if it just covers it’s own development costs and I can break even…but this is a game that I would show people and say “Look, I made this!!” whereas some of the projects I worked on in the industry before, I almost didn’t even want my name in the credits haha

3) Play-testing Is Vital
I made sure to have a solid 10 people (some friends, some strangers) test out my game pretty thoroughly and give me honest feedback. I actually thought I had the gameplay pretty solid the first go and figured I could release it as-is…but when my testers played it I found there were a TON of problems! People were trying to control the game in ways I didn’t intend, holding the devices in ways that were natural for them but not for me! That was my fault for not explaining how to play and just assuming everyone would naturally pick the device up the same way I do…but touch devices have no real standard control scheme to them so you never know what people will do. Aside from the controls, the difficulty ramped up in ways that felt unfair to them, and by recording analytics I was able to see that no one was getting past certain points in the game.

Turns out people hold touch devices all SORTS of crazy ways!

As a result I ended up having to add an animated visual tutorial to ensure people were playing the way the controls were designed and I spent a solid week ironing out the game’s AI and making it smarter instead of just impossibly faster, so the difficulty would increase but in a way that the players felt they could still beat it if they were skilled enough!

In the end the game is balanced great, but the difficulty curve now is incredibly different compared to the first version. I can’t imagine submitting a game without getting a handful of testers to give it a go. If I had submitted the game as-is, I would have gotten a ton of “this controls bad” and “this is unfair” reviews because everyone would have had the same problems those testers did. Why shoot yourself in the foot like that when you can take a week or two and tweak things?

4) Financial Planning
I saved up a solid chunk of money to live off through development, and I tried to keep development costs low. I made the sound effects or purchased them cheaply, I called in favors from friends, I did some cross-promotion exchanges. My thinking was that the lower I can keep the development costs, the less I have to make to cover them and start actually making money for the next game. Down the road when I have a few games out, I’ll be able to afford making a larger game, but I’m approaching this very patiently.

I read a lot of Post-Mortems in the past where a developer spends 2 or 3 years on their game, and sometimes they hit and the person becomes a millionaire, but a lot of time the game tanks and financially cripples the developer! I want to make an epic 40 hour RPG or 100+ level platformer magnum opus like any other developer, but I want to wait to attempt that until I have some more experience and stable finances where I can take a year to develop a game and won’t be obliterated if it doesn’t sell.

Because I went into this with a financial plan I never had to stress whether I could pay my rent, or if I needed to take a part-time job, or if I couldn’t pay people what I owed them. It’s a lot easier to focus on the game itself when you don’t have money troubles lurking over your shoulder!

5) Business Training
I took a really compact grueling 6 month business course and it was probably one of the most important things I’ve done. We were forced to do a ton of research into markets and development costs and marketing strategies, and all of that has been a big help. A lot of people go by their gut when they make business decisions and that can work out, but often our guts can be influenced by our own personal biases or perspectives, and looking into it we find the actual research and statistics end up telling a different story.

The business course also stressed the importance of continuous marketing. I can’t count the number of Post-Mortems I’ve read where someone spends years working on their dream project but they don’t bother marketing it at all and just trust that “if it’s good, people will find it”. And time and time again those projects never actually pick up any exposure and the developer is crushed because they didn’t make enough to even cover their game’s development costs, let alone fund another game.

This is the age of word-of-mouth advertising. Social media and the Internet in general allow us so much free marketing that we should be doing it constantly in the background. I know developers who have a couple games out and still only have like 25 followers on Twitter. I had 200 before this game was even finished. That’s not a ton, but it IS a possible 200 people who will re-tweet my announcements and spread word-of-mouth to help me out because they’ve been following my progress. And in turn I help them out when I can too, it’s win-win for everyone! It’s probably not necessary to do as in-depth a blog as I’ve done with my project, but at the very least every developer should set themselves up a free blog and a Twitter account.

In the future I hope to have a message board forum for my games where people can discuss them and share tips & tricks, submit fan-art, enter contests to win free stuff, suggest ideas, and basically build a community!

What Went Wrong:

 1) Feature Creep
The original plan was for the game to take a month or two max from start to finish. It was just going to be a nice simple bare-bones project to get used to iOS development. And in theory, it was possible to do that…but as an artist, I got suckered into how beautiful the iDevice screens are! All the colors come out so vibrant and colorful that I sort of fell into the trap of “But it’d be cool if this explosion had like 3 layers to it…” and “there’s lots of space left, why not have another power-up?” and “It’d be awesome if the menus had transition animations between all of them…” There was a point where I was planning to have like 8 different level backgrounds and fully animated cut-scenes in-between each level, etc. and that was around the time I realized the game’s design was getting over-ambitious and I started trying to cut stuff back!

Fire Arrows? Dynamite? Parallax backgrounds? Feature creep in action!

In the end the game took a solid 5 months from start to finish. And in retrospect, some of the stuff that was added wasn’t really necessary. The menus could have been a lot simpler, animations probably didn’t need quite as many frames as they have, etc. This didn’t get as out of hand as it could have, but it was a pretty big wake-up call that when you’re the only one planning out the design you should step back and look at things objectively once in a while and keep yourself in check! It’s good to have friends to bounce ideas off and who’ll be honest with you and say “Man, this sounds cool, but do you REALLY think you can do up 8 unique backgrounds in a week?”

2) Not Enough Manpower
I took a business course before starting Bulletproof Outlaws up and they drilled into us the importance of marketing during development of your product instead of waiting till it’s done and playing catch-up. I also had a big drive to blog about the progress of the game on an almost daily basis because I’ve always been a fan of reading development blogs and I’m a huge fan of sharing information and experience with other developers…plus I figured I could package the development blog up as a Bonus Feature in the game.

The problem is between doing all the paperwork for setting up a business, managing the money, blogging regularly, doing the game design, all the art, all the marketing, Tweeting, posting on message boards, making banners and movies, even a little of the programming towards the end to polish things up…that’s a LOT of hats for one person to wear! I knew going in that it was going to be a lot of work, because that’s just the nature of starting your own business, but it got pretty overwhelming. In the future I’d like to be able to outsource a lot of stuff, like blog updates, marketing, making trailers, etc. just to keep my personal To-Do list from being insane. And I don’t even have a day job outside of this, so I give a ton of props to anyone who’s attempting serious game development while also working a full-time job!

3) Lack of Stress Management
This one sounds over-dramatic at first, and I know I pooh-pooh’ed it back when I was reading advice about it from other start-up entrepreneurs. Stuff like “Make a separate room in your house your office, don’t use your bedroom. Don’t make the place you work the same place you relax.” made me roll my eyes. But by the end of development I was in crunch mode, basically napping a few hours at a time, then waking up and flipping my laptop on, working till I was exhausted, then napping again. I didn’t leave my room for a solid week at a time, and I was working on weekends! Basically every waking moment I was on my laptop in my room working.

It turned out to really take a toll on me, because what was fun and exciting started to feel suffocating and inescapable, especially with no days off to relax. The stress of always having to work started to carry over into my personal life too, and I became irritable and depressed to the point where friends noticed and pointed it out to me…I hadn’t even realized the stress was affecting me that bad!

I believe the trick is to be able to separate your work and your home life. Turn off the computer at 5pm, go out in the sunshine and relax on the weekends, etc. Start work again at 8am Monday morning feeling fresh and relaxed instead of burnt out and exhausted. This isn’t something you can always get away with in a traditional “working for a large company” office environment, so part of the point of being independent is that you CAN set your own schedule and ensure you have downtime on each project.

Next game I develop, I plan to make a steadfast rule that no matter how chaotic things get, I won’t work on the weekends. We make videogames, it’s supposed to be fun, not stressful!

4) No Experience on the Platforms
All I really knew about the iDevices was that they can push some pretty big graphics around and creatively you have a ton of freedom. There’s no 16×16 tile restrictions or 256 color palette restrictions…But as development got closer to the end we started running into the limitations of each device. The iPad was a big one, it turns out it’s only about as powerful as an iPhone 3GS, except the screen is twice as big. So while the game runs on an iPhone 3GS, the iPad struggles trying to push around art that’s twice as big!

Different sizes, same amount of power, who'd've thunk it?

On top of that there’s a 20MB file size limit for iDevices to download an App over 3G…if the App is bigger than 20MB, the user needs to be connected to Wi-Fi to download it. The App Store tends to be very “impulse buy” oriented, so if a user can’t buy your game when they first attempt to, odds are a lot of them probably won’t bother to hunt it down when they get home to Wi-Fi because the moment of “I want this!!” has passed.

Then you throw in Retina art for a game, which is double the size of normal iPhone art…except that you have to include both the normal art and the Retina art in the game. So your iPhone game came out to 8 megs, and the Retina version ends up at 16 megs…then you combine them and you end up with a 24MB App that’s way over the 20MB limit!

So in the future I’ll have to take these things into consideration when I’m designing the game, especially if I’m adding cutscenes, voice-acting, lots of songs, etc. I’ll be keeping a pretty keen eye on file sizes right from Day 1!

5) Animation Tool
Unfortunately the wonderful awesome fantastic Animation Tool that did save a ton of time, wasn’t fully tested and had a handful of bugs that took forever to figure out. On top of that it was very picky about exactly how it wanted things done to spit the information out right and it took a while to learn all the little nuances to get things on the devices to look like what was showing on my laptop screen. I was attempting to do a lot of the animations before hiring a programmer to save time, but there was a point where I had to redo a TON of animations when we put them in-game and found out we needed them arranged in a different way to work right.

Then when we started working on the Retina version we found out that the Tool and the way we had duct-taped around it’s issues made the Retina version go completely haywire with everything mis-aligned dramatically. By that point we were running out of time and I decided to drop the Retina version entirely.

Now that the Tool is working right and I’ve got all the nuances down, the next game should go way smoother, but all these little problems set us back a solid month behind schedule and it was pretty demoralizing to keep running into bugs and have to drop the Retina version!

Conclusion:

I learned a ton from this project, and while it was stressful at times, the rewarding feeling of finishing a game that’s completely my design from start to finish is completely worth it. I figured I’d want to take a month off when my game was done to relax, but honestly seeing the game on the App Store, I’m just more pumped and motivated to get going on the next game!

I expect to tighten up my work-flow with each project, and to someday expand into working in an office with a small in-house team instead of working with a contractor or two over the Internet…but I don’t think it’s wise to rush that. I learned a lot about avoiding feature creep and dealing with scheduling issues on this game and that’s going to help me when I’m managing more than just myself and a programmer. Better to make the mistakes now when I’m a small developer and the mistakes don’t cost me much money, than to make them down the road where the consequences are more severe.

Thanks for reading! I hope other developers can avoid some of the mistakes I made, and that you guys follow along as I blog about the development of my next game!

- Jeff

Data Box

- Developers: Bulletproof Outlaws and Ravenous Games

- Release date: June 5, 2011

- Development time: 5 months

- Team size: 2 full-timers (I did the art, Derek of Ravenous Games did the programming)

- Development cost: About $3500

- Extra stuff used: Cocos2d and a custom Animation Tool

- Primary tools: Xcode, Adobe Photoshop, Adobe After Effects, Audacity