Interview: Chris Hoopes, Lead Developer of Ghost Crab Games

Welcome to Philly Cocoa interviews, Chris.  Still working on the title.  Please describe what you do for us.
Ghost Crab Games FoundersI am the lead programmer and co-owner of Ghost Crab Games, a two man independent game development studio here in Philadelphia.  My partner is long-time friend Dustin Twilley who handles visual design and music.  We’ve been good friends for over two decades and decided last year to give game development a shot.  It’s something I’ve always wanted to try, and with my programming background and his visual expertise and hobbyist game design interests we thought we’d give this a shot.
You are a regular at Cipher Prime’s Dev night and a 2 time game jam winner.  How do you find the time to work, make your game, and make 12 hour game jam masterpieces?
It’s really, really tough.  I’ve actually had to skip the past three or four game jams exactly for that reason.  Giving up even six hours of possible dev time is something that I just can’t do since besides working a full-time job I’m also married (to a nurse in grad school no less) and own a house.  I sometimes don’t get to start on my own development until 10pm and by then I might be so tired from other things I can barely concentrate.  But as tough as its been I think I’ve reached a decent equilibrium.  Now if there were kids in the picture that’d be a different story but for now that’s not an issue.
You are currently working on a top-down shooter of sorts called “Drive to Hell”.  Can you provide a better description of the game for our audience?
Drive To HellDrive to Hell is a twin-stick vertical scrolling shooter in the vein of Raiden or other arcade classics.  However those games have to primarity firing straight forward.  In Drive to Hell you have full 360 degrees of firing free like Smash TV.  It’s a mixture of the two genres that you don’t see too often.  The game features 25 levels and 4 difficulties along with 5 survival missions and lots of vehicles to unlocks and demons to destroy.


It’s coming out for both OSX and iOS, with the primary difference between them lying in the controls. In the iOS version your car is locked to the center of the screen and you fire at enemies coming from all sides. In the OSX version you have full range of movement in your vehicle.  Enemy patterns have been completely reworked as a result and there’s also 4-player co-op!
How long have you’ve been working on Drive From Hell?
Screenshot
We started in May 2013 but as it was our first Unity project a lot of that time has been getting familiar with the platform and the devices on which we’re releasing.  The community around Unity is great and Matt Rix, the creator of the 2D framework Futile that we use, has been an invaluable help to us.  We’ve lost other time in there as well due to Dustin getting married and the whole setting up a business process.  It’s been very much a learning experience.
You chose to use Unity 3D to do your development. What was your reason for using Unity 3D as oppose to say Cocos2D or Game Maker?
Unity’s cross-platform portability is the main reason we went with that engine.  I wasn’t familiar with any of those at all but after weighing our options (and a failed start at using Torque2D) we realized that Unity is very much the indie dev engine of the future.  With some smart coding and asset use you can easily have the same game running on Android, iOS, Windows, OSX, or in a browser if that’s your thing. We want our games to be as universal as possible but we don’t have the resources to handle porting to various engines ourselves.  With Unity we don’t have to worry about that.
What kinda game mechanic challenges did you come across to get the iOS interface to work properly?  Did you include any iOS specific technologies like Game Center for example?
Game Center isn’t implemented yet but we’re very much considering it.  We can use it for the high-scores yes but we also have an in-game trophy system that we can tie into Game Center. Other than that there haven’t really been any iOS interface specific issues or limitations — it’s been pretty smooth.
What is your process for prepping deployments to iOS builds?  What kinda gotchas did you run into?
A big one actually. Drive to Hell’s art assets are stores in texture atlases or sprite sheets.  These are managed by a program called TexturePacker. We wanted to have nice high-res art for the game without having to scale our assets but there’s a bit of a fragmentation issue.  It used to be that all iOS devices were very much on the same level power and display-wise but that’s no longer the case.  Games are expected to run on an original iPhone 4 along with the newest retina iPads, and the discrepancies in available memory, processor speeds, and resolution is incredible. There’s also the issue of max image size.  The iPhone 4 can only handle displaying images of 2048x2048 or smaller so that had to be the max size of our texture atlases.  We have some big road and background pieces so those all had to be smartly carved up and packaged in a way that was efficient.  We’re loading as few atlases into memory as possible, and the assets stored within are structured in a way that from the topmost rendering layer to the bottom there are very few atlas changes. Clustering assets in accordance to the order they’re layered in a scene is crucial to limiting your draw calls which is a major performance factor.  Even with hundreds of bullets and enemies and the HUD and backgrounds all going at once Drive to Hell at most hits 13 or so draw calls per from.  It averages about 9.  For as much art that we have that’s very good and learning to both structure our texture atlases and our code in such a way to get to that point was a major, major learning experience.


Screenshot 2There was also the issue of the image files themselves.  Everything in the atlas is stored in the PNG format.  This is fine for Windows and OSX and Android but iOS and Apple’s hardware has a really hard time with PNGs.  I don’t fully understand the technical details behind it but it’s basically like this; when you package up an IPA file using raw PNGs everything is fine.  Drive to Hell clocks in around 56MB on mobile. However when your iPhone or iPad installs and unpacks that app it also decompresses all of the PNG files.  This suddently turns your 56MB game into a 600+ megabyte monstrosity on the disk. Your performance tanks, your memory use is through the roof and you’re never going to run on older devices.  Plus the user is now upset that you’re eating up all of their space!


The answer was that we had to tell Unity to compress all of our iOS assets using the DXT5 algorithm.  I’m sure there are plenty of whitepapers you can read on exactly what that is and how it works but the end result is that our iOS image assets take up very little space on disk and compared to raw PNG files which use 32MB of memory per 2048 image, that same image in DXT5 allocates something like 16KB (that’s kilobytes!) in memory. It’s kind of insane how efficient it is.  It takes forever to convert though. We don’t have asset servers and all that storing all these versions separately so when I want to build for iOS it takes my Macbook about a half-hour to compress about 22 2048x2048 PNG files into DXT5.  It’s some seriously intense stuff.
When can we expect Drive From Hell to be on the App Store?
The OSX version of Drive to Hell comes out on February 15th and should be hitting the Mac App Store along with other storefronts at that time.  We’re shooting to have to mobile version of Drive to Hell ready for early March.
Thanks again for taking the time.  Please let know where we learn more about your game and your company.
The pleasure’s all mine!  Our company website is GhostCrabGames.com and there’s lots of media and information about Drive to Hell on its own website at DriveToHell.com. For anyone reading this feel free to hit us up on Twitter (@GhostCrabGames) or one of our other social media sites listed in the links above. We’ll gladly answer any questions anyone might have about the game or its development process.
Read More