Tag Archive: programming

This update is a couple days worth of work in one and it has good news and bad news. Let’s get the bad news out of the way first: We had to kill the Retina version. :( The way we did the animations turned out not to translate nicely to the pixel/point stuff Cocos2d uses. It looks like the animations line up right if we use the Retina art with the regular iPhone animation files, but then the menu and general “touching stuff” system gets all shot. It’s fixable, but it’d take a while and Derek has other projects to move onto and this project has gone on way longer than it was supposed to. I’m not super bothered by the lack of a Retina version because the art is hand-drawn so the lines are anti-aliased as it is, which means it looks good on an iPhone 4 anyway…the art is cel-shaded so there’s not a lot of need for the Retina resolution with cel-shading since everything is flat-shaded with big areas of one flat color, versus a game that uses photographs or heavily painted artwork. So visually, it’s not a big deal, though a bit of a bummer! On the plus side now that we know what happened with it, in future games I’ll be able to have a Retina version for sure! The other good part is that it chops the iPhone version down to well under the 20MB 3G transfer limit which means users won’t need to be near Wi-Fi to download it.

It also means the iPad version is officially the HD version:

I’ll throw an HD on the title and market it that way since the art is huge for the iPad version (well over the 20MB limit, but I figure people use their iPhones on the go so you want to be under 20MB there, but most people’s iPads are used at home where they’ll have Wi-Fi). So it’s not the worst thing ever in the long-run!

The good news is Derek is officially off the project (aside from going over the final source and helping me submit it to Apple in a bit). He’s moved on to work on Burrito Bison for Juicy Beast, which should be awesome! I’ve got the final source and I’m using my epically weak programming “skills” to tighten the controls and tweak the gameplay and add a little polish. The Macbook I bought way back at the start was bought specifically for this purpose because I figured I’d run into this situation, where I’d want to tinker with the source a bit…it’ll speed up testing and it means Derek doesn’t have to worry about the project. I’m basically taking the source, vanishing for a week, then bringing it back to him with it all balanced out and polished up. I don’t actually know how to use a Mac, or XCode, or how to program in C or C++ or C# or whatever this is, so I am pretty much completely winging this with good ol’ trial and error haha I change some numbers, or cut and paste some code, run it, see what changes, then change some more numbers, or un-cut and paste the code, until it works. It’s not fast, but it works, eventually. Google + tutorials are a massive help too.

The game is looking good, and I’m pretty psyched to get it out there! I’m hoping to get TestFlight going when I wake up later, then have some friends testing it through the week as I polish up some of the animations and create all the external stuff, then hopefully submit it on Monday. I’m playing this part by ear because I have no idea how long a lot of this is going to take…Making the ninja change to his idle animation when he bumps into the edge of the screen took me like 6 hours to figure out…but I added multi-touch support on the first attempt. So like, jeeze, who knows haha

- Quickdraw

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

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

As the work load increases, the falling-behind-on-updates increases haha Progress has been good, but we’ve been putting in a lot of hours and updating the blog is way lower priority than a lot of other stuff (making sure files are ready for Derek, or fixing animation bugs, changing how we do stuff, etc.). So I’ve decided to compact a bunch of days together instead of attempting to fill in all the missing days.

Choosing a title was a pain in the butt…everything short is taken already haha So I decided to go the opposite route and pick something overly elaborate. And so Elusive Ninja: The Shadowy Thief was born! I wanted to put a subtitle in because if I do a sequel, or a different type of game that uses the character, I can use the same Elusive Ninja title and just have a different subtitle.

The first rough idea for a title screen:

The final title screen:

The HUD has been solidified, and looks like so:

I went with blood and fire, and it stands out nicely on the dark blues/purples of the game’s background. I took the large blood splat and flipped and shrunk it to create a second smaller blood splat...I’m thinking it’d be cool to have announcements (“NEW RECORD!” for when you top the high score, “+1 LIFE” when you catch a Riceball, etc.). But I don’t know if this’ll make it in, I was just playing around.

I had to make a font sheet for the firey numbers, so on Derek’s recommendation I bought Glyph Designer for $29.99. It outputs stuff that can be used in Cocos2d, and was a huge time-saver and very easy to use.

This is just the HUD solo:

I wanted to make sure the game is polished and animated outside of just the main gameplay, so I whipped up this quick test of an idea for an intro transition animation:

I remember watching Capcom VS SNK in the arcades and the levels had these cool intros…it’d show a pixely Rad Racer looking game where the car explodes and flips and then cut to the actual level you fight in and there’s a blown-up flaming car in the background. I love that kind of thing so I’ve always wanted to do something along those lines.

Here’s a later version:

I’m really happy with how it came out, and with sound effects it’s even better. Originally the ninja just materialized in because I didn’t want to take time to draw a jumping silhouette frame, but Derek from Halfbot convinced me it would be cooler to have the ninja jump in from the distance so I went for it, and it definately looks way cooler.

I can’t fully remember because it was a while ago, but I think a friend and former co-worker, Wes, and I were up late blabbing about gamedev stuff and he said it’d be cool to make a game where everything is seamless…So when the user is done on the main menu, it unfolds and reveals the gameplay stage and everything jumps onto it and the gameplay begins. I dig that so I tried to orchestrate the menu design in this game to involve that. The background of the main menu is actually the gameplay stage’s roof zoomed in 300%…so when the scrolls on the menu fold up, the camera pans up the roof and zooms out and the ninja jumps onto the stage and the game begins. This was a really fun effect to do, but it was a pretty elaborate undertaking and I don’t know if I’d be quick to try it again without some serious planning ahead of time.

Here’s some gameplay footage:

When your Deflect Meter is full, you can swipe upward to deflect objects (though in this version you can do it whenever you want). The meter fills whenever you dodge an object and it takes 10 dodges to fill. This gives you a last-second desperation move. We went with an upward swipe because we figured that’d be cool on a touch-screen, but as I was testing it I found it wasn’t as good for the gameplay…swiping up means you’re no longer moving left/right, which is okay at the start when everything’s slow-paced…but when it speeds up a lot, it can get your ninja killed. So I’m thinking of changing it to a button you can tap with your hand that holds the iPhone.

This was the demo animation of the menus:

I like the idea of having the options light up as you drag over them, and then get swiped out with a blood streak when you let go on one. I think it works well with the scroll, and I like having stuff zoom in/out so I was happy to get a chance to have the scroll drop in from the foreground.

And here’s the menus working in-game:

It worked out pretty good so I’m happy! Everything’s coming together the way I pictured it in my head…it’s a pretty big relief because when you imagine it you never know for sure how it’s going to look when everything comes together toward the end. Epic props to Derek from Ravenous Games (go buy League of Evil for your iPhone if you haven’t yet, it’s easily the best platformer on the device) for putting up with my over-the-top artsy polish!

- Quickdraw

All the iPad animation files are fixed! I start with the iPad files, then scale the animations down to the iPhone 3′s screen and the iPhone 4′s retina screen, but we’re working on the iPhone 3 version first so I have to scale it down before we’ll know if the new changes will work out. Our custom animation tool allows us to add commands to the animation timeline, so when the animation reaches the end I can tack on a “gotoAnim:2″ to change animations or loop, or a “stopAnim” to freeze it on the frame, etc. We use this for checkDamage to run the function that detects if objects are colliding or not.

So basically grunt work today, haha Once this is scaled down to the iPhone I’ll be able to grab another video, so stay tuned!

- 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