Jeff Hangartner, the founder of the gaming start-up, Bulletproof Outlaws has been a professional developer of games over the last half a decade. Creator of Pixelation, the 1st Pixel Art Forum and also originator of the Pixel tutorials which have been published in the form of a book. Jeff has always been a pioneer of the gaming industry.
CG Today is proud to present Jeff’s exploration as he shares the whole process of creating a start-up right from day 1. With the belief that gaming development is coming back to its original “one programmer in the basement roots” idea, Bulletproof Outlaws is chronicling every step of its start-up process from strategies, to marketing, setting goals and outsourcing, successes and failures. The aim is to help other developers who have ideas but are intimidated by the whole start-up process and are not sure how to go about it.
So the way we’re going about things, we want to get Derek off the project as soon as possible because he has other projects lined up and this went on longer than it was supposed to. Normally toward the end of the project there’s a bunch of testing where I’d basically play the game and tell him “hey, can you shift this 3 pixels to the left?” and he’d go fix it, then compile a new build, then send it to me, then I’d check it out and say “actually how about just 2 pixels?” and then he kills me in a fit of programmer-rage.
Fortunately, over the years I’ve acquired some programming skills. Nothing amazing, but I get general code logic and I can make some simple games and handle scripting and stuff. So in the interest of saving time and getting Derek off the project quickly, when he wraps up the major stuff so the game is playable but needs tweaking, he’s going to pass the source onto me and I’m going to set up my MacBook with “programming stuff” and tweak/polish the game myself. So I’ll be able to play and if the ninja moves too slow, change his speed and re-compile myself a build to test again, no help from Derek necessary.
I figure I’ll take a week and test/tweak/polish while Derek can focus on his other work and forget this project even exists for a week, and then when I’m done I’ll get back in touch with him and he’s going to check over the final code and help me submit it to Apple. I won’t be doing any epic coding that’ll break anything, mostly just tweaking numbers/variables to get the speeds and such the way I want. I’m shooting for 60 – 120 second gameplay. No one wants to spend 3 minutes at slow speeds in a game before it gets challenging, and I don’t want people to all die in the first 10 seconds, so I’ll have to play with the balance and difficulty curve to ensure a fun experience.
In terms of testing, the only real method I’m aware of beyond handing my phone to people and asking their opinion (incidentally I learned this weekend that showing a girl at the bar a build of your iPhone game does NOT get you laid haha), is to use this TestFlight service. I don’t have any experience with it yet, so I’ll be reading up on it and giving it my first go this week. I’ll get it running with a couple friends just to make sure it’s working and then figure out how I want to go about the testing from there. It’s a pretty simple game/concept so I don’t expect to need much testing, I could probably do it all solo but I figure it’s good to get a few people who’ve never played it to try it out and just make sure their experience correlates with what I expect. I heard Shigeru Miyamoto was a big fan of standing behind people’s shoulders watching them play his games and noting where they had problems or what was fun and what wasn’t, etc.
Before the advent of technology like TestFlight I figured my testing method would be “spam the local university with flyers saying “want a free lunch? Come play my game for an hour and fill out a questionnaire!” and have a bunch of devices for people to test on, but 1) that’d cost money, and 2) I’d have to put on pants. This seems much easier, though less personal.
On a side note, even if you think your game plays solid, get people to test it who haven’t played it before. You can get used to the nuances of the gameplay/controls during development and what becomes intuitive to you may be completely unintuitive for new people and then when you find out no one else can play it like you can you have to scramble and release a revision/update that fixes the controls you didn’t even realize were bad. You don’t necessarily need thousands of hours of testing from thousands of different people, and you don’t have to listen to every suggestion…but it’s important to look for trends across the board that a few tweaks might solve or enhance. I plan to use a crap-ton of Flurry analytics to collect data on stuff like if no one can make it past the first 2 speed increases, or if people bother checking out the Bonus Features so on future games I’ll know if I should spend time including them, etc., which I’ll write a post about in-depth another time!