Evolution of Grimm

While Code Bandit is getting our Demo for Letter Quest ready, I thought that I would share the progression our hero Grimm has made. E:  Is what you’ll be seeing in the demo version. I felt he was lacking something. And with that in mind F was born. Once he’s completed and Code Bandit has him in game I’m sure you’ll all be very happy with him. A: This is the very first drawing I did of Grimm, more of a classic reaper, minus the jaw, I thought he looked less scary without it. B: Those following the blog will recognize him from a few short animation tests I did. I found this design too limiting and so explored other options. C: Was very short lived, this one was a bit too creepy. But I liked the idea of long lanky legs kinda like Jack Skeleton. I also was keeping with the jeans and hoodie look. D: After tweaking the scary Grimm I thought this Grimm had it all. Nice long limbs for some dramatic animation and strong silhouettes . The one big drawback with this design was that we wanted the enemies to feel more impressive beside him. So in the end he ended up just being too tall. E: After going back to the drawing board I wanted to make Grimm cute and appealing and yet still recognizable as a grim reaper.  Surprisingly this is reminiscent of the very first drawing of Grimm. The one thing I really liked about this look is his face being hidden. F: This look has it all. He’s cute, cuddly and ready to clean up some lost souls. I kept his face hidden and added a glow to the eyes. I also made his hood longer and hang down instead of up like in E, this also allowed me to work a skull back into his design. His outfit isn’t so simple either, now with a belt. This serves two purposes. One, it breaks up the all the blue in the body, and two, it serves as a nice place to hide where the upper and lower body meet. Back to the frying pan Art...

read more

iOS 7 Support

Updated to the beta version of Air 3.9 SDK today and did a new build to attempt to fix the super-cool bug where users are presented with a dialog asking them to enable the microphone the first time a sound is played. Now that sure looks professional! The new SDK did fix the bug thankfully! Everything else seemed fine on iOS 6 and iOS 7 and then I tested bringing up Notification Center…crash. Then I attempted an in app purchase…crash. Then restoring purchases…crash. Then simply backgrounding the game by hitting the home button…crash. What gives? After scratching my head for a few minutes, wondering what I could’ve done to have broken everything so badly, I was able to retrieve the error message from the crash log: “The Stage3D API may not be used during background execution on this operating system”. Hmm, interesting, didn’t Adobe *just* finish adding support for exactly this issue? And I certainly don’t recall turning on background execution of Stage3D content. Curious. A quick browse of the Starling forums led me to a post about the issue I was encountering. So it turns out that Adobe is aware of the issue and it should likely be part of the next prerelease. Cool. But what to do in the meantime? Luckily Daniel (the super-awesome author of the Starling framework!) already created a quick fix for the issue. All it requires is passing true to the call to starling.stop when Event.DEACTIVATE fires. I updated my Starling source, tested it out, and…success! Notification center now works again, as does backgrounding the game. Then I tried in app purchases…crash. Same error as before. “The Stage3D API may not be used during background execution on this operating system”. But I’m not using it! Or at least I’m not trying to! Half an hour of digging through in app purchasing code, double-checking callbacks, and adding a ton of debug logging, the problem is…my custom dialog/popup. Ouch. See, I don’t like to just leave players hanging when they’re waiting for a purchase or to restore purchases, so I show a super-spiffy “please wait for the purchase to complete…” dialog. As soon as I get the callback from StoreKit that the purchase succeeded, failed, or was cancelled, I dismiss the dialog. A little debugging later and I realize that I’m dismissing the dialog BEFORE starling.start is called, which kicks off disposal of the dialog, which results in a vertex buffer being disposed, which means that…yeah okay, so it is me that is attempting to do something with Stage 3D while the game is still in the background. Oops. The fix was a bit messy, but simple: if a “close dialog” request is received and starling is not currently started, set a flag in the dialog manager and do nothing. Then, as soon as the app is activated, and starling is started, tell the dialog manager to close any open dialogs but only if that flag is set (otherwise we’d auto-dismiss any other dialog that could be active, which could be the user attempting to delete their save file, purchase their way past a quest, etc.). All good. So that’s the extent of my iOS 7 woes. Pretty good actually, really just a few hours of debugging and forum browsing. Bring on iOS 8!...

read more

Early version of Android support!

I’ve been meaning to get things up and running on Android devices for a while. My friend Rudi loaned me his Nexus 7 tablet for the weekend (thanks bro!), so I figured it was time to get proper Android support going! This actually turned out to be fairly simple. We already had support for loading assets at 1x, 2x, 4x depending on device resolution. So it was just a matter of creating a new “platform type” of ANDROID, turning on Starling.handleLostContext (required for Android apps), and doing a few calculations to figure out what size of assets we should use. It’s not perfect yet – eventually I’d like to do further adjustments based on the dpi, whether or not it’s a tablet, etc. var serverString:String = unescape(Capabilities.serverString); var reportedDpi:Number = Number(serverString.split("&DP=", 2)[1]); var isTablet:Boolean = DeviceCapabilities.isTablet(stage); var divisor:Number = 1; var isRetina:Boolean = false; if (reportedDpi <= 120) // ldpi { divisor = 1; } else if (reportedDpi <= 160) // mdpi { divisor = 1; } else if (reportedDpi <= 240) // hdpi { divisor = 2; } else // xdpi { divisor = 4; isRetina = true; } Constants.DEVICE_DEF = new DefDevice(DeviceType.ANDROID, divisor, "Android_Device", largestResValue, largestResValue / divisor, smallestResValue / divisor, isTablet, isRetina); This gets us most of the way there. It certainly lets the game start up at any Android resolution, load some assets, and display correctly at most of the common resolutions. Unfortunately it’s never that simple though…there are many Android resolutions that cause headaches due to aspect ratios that are vastly different from those encountered on iOS (which is all we’ve cared about up to this point). A few places were pretty easy to fix, simply scaling images where necessary, doing a bit smarter positioning of some UI elements, etc. But our in-battle view is still a bit of an issue at many different resolutions. The fix for issues like the one in the picture above is not terribly difficult, it’s just tedious. I haven’t fixed it yet, I’m going to spend my time focusing on getting the game done and ready for release on iOS first, then will make the necessary adjustments to make everything look good at all resolutions. To fix the above problem, a good start would be to divide the screen roughly in half vertically. Then scale the background tiles (that have the torches, bricks, windows, etc. on them) to fit vertically. The top UI elements (health bar, progress bar, etc.) are okay since they’re positioned relative to the top and sides of the screen. Whatever value we scale the background by will have to be applied to Grimm and all monsters. To fix the bottom half, we can start by scaling the background image to fit vertically. Then we can look at scaling the tiles and tileboard. Finally we’ll need to figure out how much room we have for all of our buttons, and attempt to scale them to a decent size, and then position them relative to the sides of the screen and the tileboard. Again, not difficult, just takes time. In any case, I’m feeling confident about everything. All iOS devices are now working, and things are looking pretty nice on a Nexus 7 as well: For now, it’s back to tearing through the rest of my (now much smaller) task...

read more

1x, 2x, 4x, oh my!

Handling multiple devices and resolutions has been a part of development for many months now. It’s been working rather well, too. I’ve been using “Strategy 3: Smart Object Placement” as described in the Starling Manual for Multi-Resolution Development. Everything was looking and working great on all iOS devices, from the now-ancient iPhone 3GS at 480×320, to the retina iPhones at 960×640, the iPhone 5 at 1136×640, the iPads at 1024×768, and the retina iPads at 2048×1536. Whew! To support all of these devices, I naively started naming my images roughly according to iOS developer standards, that is, non-retina assets are just called filename.png, retina assets are filename@2x.png, and retina iPad could be filename@ipad2x.png, for example. That’s fine, it worked okay for supporting only iOS. Even so, it became very tedious because I had to write a bunch of custom code for adding the proper extension to every file name when attempting to load assets, based on what device was currently being used. Then I looked at the Starling mobile scaffold project, and realized that they simply separated their assets into 1x, 2x, and 4x directories, but kept their assets named identically. In other words, they had: /1x/filename.png, /2x/filename.png, etc. Well that would certainly make life easier for me! Let’s do it! Recently we decided that we want to release all of our games on Android as well as iOS, and the hacks and “fixes” we’ve done to get things working on all iOS devices are now coming back to bite us in the ass. One example of this is our in-game background tiles that make up our dungeon/stage view. Due to the aspect ratio difference of iOS phones and tablets, we used two different sizes of background tiles. The iPhone uses tiles like this: And the iPad uses tiles like this: So that right there is a bit of an issue if we’re going to attempt to move to the new 1x, 2x, etc. system because the iPhone retina and non-retina iPad are both technically going to use “2x” assets. So which tile do we use? The answer was actually quite simple, and very helpful when trying to think in terms of supporting any resolution: for the above issue with the bg tiles, I ended up discarding the iPhone tile completely, and just using the iPad tile as the /2x asset. Then I modified the code that positions the bg tiles to line up the bottom of the bg tiles with the lower portion of the screen, and everything works great – on the iPhone the top parts of the tiles are simply off the top of the screen, which is perfectly acceptable for what we’re doing. There were a few more places I had to make adjustments, like on the map screen. But overall it was pretty easy to get working, and it makes supporting various Android resolutions much easier. Also, Andreas (author of the awesome TexturePacker) replied to an email I sent him, and he offered a solution to another issue I was having – how can I leverage the auto-SD options in TexturePacker to export into my /1x, /2x, etc. directories? He suggested I try something like this: And it worked perfectly! Now my loading code is greatly simplified, it’s so much easier to exclude certain asset sizes from builds – say for example we wanted a web build with only 1x assets, all we have to do is go into our assets directly after doing a release build, and simply delete the 2x and 4x directories, and everything is ready to go. Awesome! The only...

read more

Enemy Concepts

I was digging through some old files and found this. These are some of the very first sketches I did for Letter Quest.  The only thing that has really survived is the round ghost. Who knows, maybe these other guys will come back in another title. For anyone that is interested, I do all the art in Flash including the sketching, I just find it faster for me since I’ve been working with Flash daily for about 12 years, ever since the Macromedia days and Flash 4. Back to the frying pan Art...

read more