Archive for May, 2011


Today we were trying to get the thing working on the iPad, and we did a little tweaking to the Options menu. Derek got the Options Music/SFX sliders set up, and we were having problems with the iPad blowing up and looking for ways to reduce the art. Derek set things up so that the non in-game textures (aka .PNG files, aka the art) were forcibly purged when the in-game stuff started up, to free up some memory and that was a good step toward getting it working and apparently the magical epic awesome Cocos2D setting that helped save the day is the CC_TEXTURE_NPOT_SUPPORT setting, which “If enabled, NPOT textures will be used where available. Only 3rd gen (and newer) devices support NPOT textures.” (NPOT = Non Power Of Two textures, so .PNG files that don’t have dimensions of 8, 16, 32, 64, 128, 256, 512, 1024, 2048)

If you don’t know what the NPOT stuff means, allow me to illustrate:

If you’ve got an image with a Width or Height that isn’t a power of 2, it gets padded with extra space to become the next power of 2 up. So in the example above, the top-left sprite has a width of 256 but a height of 241, so the height gets stretched to 256, making the final sprite 256×256, a power of 2 sprite. Follow me? So now say you made your sprite 279×263 like in the bottom example…both of those are over 256, so they both get padded to the next power of 2 up which is 512×512. Now your tiny little sprite has become this massive waste of space/memory.

So the option we’re looking at ignores the padding up to powers of 2, but the catch to this is that it’ll make the game only work on 3rd gen and newer devices…fortunately Derek was able to set it up so that it only does this for the iPad version of the game and not for the iPhone version. The end result should theoretically be that the game works on all systems, even the older iPhone/Touch devices, AND the iPad.

…fingers crossed! haha

- Quickdraw

We’re running into some problems getting things going on the iPad. The intro/menus load fine but when it goes to load the gameplay it blows up. Derek suspects that it might be a memory issue, which would make sense…if the iPad is only about as powerful as a 3Gs, but the art we’re loading into it is like twice the size, it’s no surprise it’s going haywire. The iPad 2 would probably have no problems since it’s more powerful, but this is kind of unfortunate. We also figure the iPhone 4 will have no problems with the huge art because it’s pretty powerful, but this iPad lack of power is something to keep in mind in future games.

It also reflects in file size…There’s a 20 meg limit on an App’s size for it to be downloadable over 3G (which is very important when you consider how “impulse buy” the App Store is…if someone gets an error message they probably won’t go out of their way to remember to download your game when they get somewhere with a better connection). So you could have this phenominally graphical iPhone game where the art only comes to 8 megs. But then you port that same game to iPad and bam, that’s 16 megs of art.

On top of all that, after talking to Derek it looks like the “iPhone” version of the game will have to contain both the non-retina and the retina art. That’s unfortunate, because the retina art is only about 7% smaller than the iPad art and the iPad art is huge as it is…I don’t think there’s any way the iPhone version of the game will be under the 20 meg limit! At least the sound and music don’t need duplicate versions!

So this is something I’ll have to keep in mind when I design future games, in terms of adding voice acting, cutscenes, etc. (all the extra visual frills)…is it better to make all versions toned down, or put out an iPad version that’s missing stuff the other versions have? An interesting dilemma!

This might turn out to just be a code issue, Derek’s checking into it but this was our Crisis Of The Day today, haha

- Quickdraw

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!

- Quickdraw

While Derek works on the iPhone version of the game, I’m busy scaling the animations up to iPad size and retina screen size. I actually think the game could get away without a retina version because everything is anti-aliased and cell-shaded so all the retina will do is make things a little sharper (vs a game with photographic elements or 3d, where there are tons of different shades/textures/details), but if it’s an easy port then why not! I have to say once again that I love the iDevice screens…they’re so vibrant and the game looks really good in action with all the glows and such.

Next up is to scale the animations to retina size. Then I have to do a bunch of non-directly related work, like create a Bug Report form, a Trailer, fill in the “Get More Games” page, etc. I’ve got a lot of Bonus Features in the game, but most of them will be external links (like linking to this devBlog you’re reading right now haha) so I basically have to create the content in those external links. Plus I should probably do my taxes soon, haha

My days pretty much consist of working whenever I’m awake. I roll out of bed, flip on the laptop, start working, take breaks to eat and down an energy drink or two, then work till I pass out. It’s a lot of work, but at the same time it’s hard to call it “work” because it’s awesome. I’m creating stuff that I want to create. Working on a project you hate or aren’t interested in is rough, because when you work long hours on it the fact that you don’t care about it just compounds the fact that you’re stuck working on it. But when the project is something you’re proud of, it’s a lot easier to put in a few more hours. I’ve definately learned some lessons about scheduling and feature-creep and my next game will be way smaller/simpler (unless like, this game sells a jillion copies, haha but I don’t expect it to do that). I’m excited to start designing it, I have a ton of ideas, just have to sit down and go through them and decide which ones will be small projects and then flesh them out…but I’m trying not to get ahead of myself so I’m forcing myself to focus 100% on finishing this game. One thing at a time!

And now…some much needed sleep!

- Quickdraw

Today was messing with image reduction. We’re running into some issues with the iPad version which we suspect might be memory issues because the art for the iPad is epically huge and the iPad isn’t really a super powerful machine compared to, like, an iPhone 3G. So I popped a look into the \Art\ directory and holy crap, the art totals 15.7megs! There’s a 20 meg theoretical limit on iOS games, so that doesn’t leave much room for anything else in the game.

I remembered back when I worked in the game industry on old mobile phones (before Smartphones existed, we’re talking Nokia S40s and stuff), we had a handful of programs that would reduce .PNG files. PNGcrush, OptiPNG, Smush.it, PNGGauntlet, there’s a bunch of free programs that’ll squish .PNG files down. Unfortunately most of them don’t seem to allow drag & drop of multiple .PNG files, which means either doing each file individually or making a .BAT file that goes through a directory blah blah blah too much effort haha PNGGauntlet, thankfully, allows multiple image files to be dragged & dropped in it, nice and simple and effortless.

The end result is the \Art\ directory going from 15.7 megs down to 13.1 megs, woohoo! That’s still not fantastically awesome, but considering how art-intensive the game is, I don’t think it’ll get much smaller than that. Some of the reduced files it spits out tend to be kind of strange looking:

Which from back in the pixel art days I know means some of the files with low variation of colors are being converted to a .GIF style 256 (or less) Indexed color mode. So the weird stuff in the background, when viewed in a program that supports the alpha stuff disappears so it ends up being displayed like so:

But the end result is that there’s essentially one big “invisible pixel color”, which obliterates the dozens of different opacity levels you get in a normal RGB color mode…in plain-speak Indexed results in pixely “aliased” outside edges instead of smooth anti-aliased ones.

The place I used to work actually had a fantastic program from Nintendo for GBA/DS development called Optpix Image Studio that had security key-dongles you had to plug in to use it and they were like $2000 a key or something insane. But that program was AMAZING…you could reduce .PNG files with anti-aliasing and control exactly how many levels of opacity go into the anti-aliasing and stuff. It’s a phenomenal program, but I’m pretty sure you can only get it through Nintendo by developing on one of their systems, so us normal peasant-folk have to make do with the free programs haha

- Quickdraw

Powered by WordPress | Theme: Motion by 85ideas.
©2010 Bulletproof Outlaws[ Back to top ]
Rss Feed Tweeter button Facebook button Reddit button Delicious button Digg button Stumbleupon button Youtube button