Taco Graveyard

Penumbear will be released next week on February 28th.

I am a firm believer in using the right tools for the job even if I have to pay for them. I generally prefer open source tools so I can modify them if need be, but the development process would have been much slower without purchasing TexturePacker, ParticleDesign, GlyphDesigner, Spriter, and a number of other utilities. Level design was a huge part of making Penumbear and without a level editor we would never have finished. There are a few level editors out there with tight cocos2d integration, but I didn't love any of them. I decided that for Penumbear I would pay the cost by developing our own level editor.

In an early build of Penumbear we had simple level editor that could be used directly on the iPad. We used UIKit for all of the textfields, sliders, toggles, and selectors to avoid reinventing the wheel. This was a great start but positioning elements with your finger was not always precise enough. It also took a long time to build levels due to swapping between views and dragging pieces into position.

Soon after I ported Penumbear so that it would run on OSX as well. Being able to test things immediately on the desktop without having to load it onto the iPad with every change sped up development by an order of magnitude. The OSX build also spawned its own level editor because running the UIKit version wasn't an option. I maintained both the OSX and iOS level editors for awhile, but it quickly became apparent that we were building all of the levels on the OSX build so I stopped development of the iOS level editor.

Playtesting While Designing

When you shorten the wait times new behaviors develop whether it be from coding to testing, writing to publishing or ordering to having. This held true for level design. Having an editor that supported instant switching between edit mode and play mode allowed me to vigorous test every section of every level as it was built. If a jump distance didn't feel just right or the timing of an event was off, I could immediately edit the level and test it again. Having the editor at my finger tips at all times also allowed me to tweak levels on every single play through of the game. If I ran into a section that didn't look as pretty as I wanted it to, I could open up the editor, clean things up, and then continue on my way.

Keyboard Shortcuts

I am a big fan of the keyboard. Visual UI is great for new users and for certain task types, but when creating (and especially when coding) nothing beats quick access a key stroke away. I added in shortcuts for all sorts of behavior:

• copying objects
• deleting objects
• nudging objects around
• moving the viewport
• zooming
• rotating objects
• locking object positions
• toggling edit/play mode
• changing z-order & layer
• moving Penumbear

Lighting System

The Penumbear lighting system has a ton of variables:

• radius
• starting on/off state
• color
• emission angle
• type: toggle, always on, grow, blink, swing, switched, rotating and timed
• blink rate and delay
• grow to and starting radius
• grow speed
• timed light duration
• starting and ending rotation
• other alternate light type settings ie lasers
• positioning
• various performance settings

All of these variables needed to be accessible in the editor. Additionally we needed lights to update in real time so we could see the effect they would have on the geometry of the level as we moved them around.

Sounds

One of the features I added into the editor was a interface for swapping sound effect files into the game. This was added so that Josh (@OpenHeartSound) could test out sound effects in game without having to wait for a release. One of the great things about building your own editor is that you can add in features like this one to smooth out parts of the development process.

Shortfalls

Despite all the great things about the editor, it is full of warts and subpar behavior. I limited myself to fixing up and improving things in the editor that would save us time developing levels. Making Penumbear was a primary goal so with a programming staff of one, I had to sacrifice the level of polish that I would have liked to put into the editor.

OSX Release

We will be running a beta of the OSX version of Penumbear very soon. We will include the level editor with the beta so testers can play around with the editor. I don't think it is polished enough to be released with the Mac App Store version, but we may sell a special edition of Penumbear off our site that includes the editor, the OST, and a few other things for buying it direct. If interest in an editor totally explodes, then I'll dust off my toolmaker hat and make it consumer ready.

This is part of our series on Penumbear. Check out our introduction to the series.

Since we are sharing the development process of Penumbear as we build, I thought it would be good start with the tools and technology that we are building with.

FRAMEWORKS

Penumbear will be coming to iOS, so we chose a framework that we already have a lot of experience with on that platform: cocos2d. Cocos2d is an excellent framework for 2d games and a great community has built up around it. Many common problems that you will encounter while creating a game have already been solved by the community.  There are also a number of great tools that have cocos2d support built in that will save lots of time. If you are just getting started with cocos2d, then you can check out Part 1, Part 2, and Part 3 of our letter to a cocos2d noob. Also be sure to read the tutorials on Ray Wenderlich's site.

We've decided to use cocos2d 2.0 for this project. This buys us OpenGL ES 2.0 support (and therefore shaders), particle batch nodes, and number of other improvements. We lose support for the iPhone 3G, 2nd gen iPods, and iOS 3.x.

In addition to cocos2d, we are also using UIKit as part of an in-game level editor. We aren't worried about tight integration with cocos2d or skinning the controls because the editor is for development purposes and not part of the final game.

TOOLS

Quick rundown of the tools we are using:

TexturePacker - Packs assets into a sprite sheet.

PhysicsEditor - Used to trace shapes to define the polygons for sprites. Also allows you to edit other properties related to your physics engine of choice. We are using it in conjunction with chipmunk. There are a number of approaches to use when building a platformer. In a later post we will talk about how Physics Editor fits into the approach we are using.

ParticleDesigner - Allows you to see the results of modifying particle system configs without having to restart the simulator over and over.

GlyphDesigner - Convert TTF and other fonts into bitmaps. We convert all our fonts to bitmaps because updating BMFont labels is much faster than updating TTF in cocos2d. Updating TTF labels has the same cost as constructing a new label every update.

Spriter - An animation tool we helped fund through Kickstarter. Steve is currently leaning towards hand animating most of the koala's frames, but Spriter is still extremely useful for menu animations and other parts of the game.

Q/A

If you have any questions, let us know and we will do our best to answer them. We hope to be as open about the development process of Penumbear as possible.

We would also love your feedback on the project. If you aren't already, follow us on Twitter for regular updates.

You've finally wrapped up that first game and want to show it to the world. Time to make a trailer! Most advice about contacting reviewers suggests providing a link to a gameplay video. I understand why. I am not a professional reviewer, but when someone sends me a link to a new game I want to see it in action.

There are a wide array of tools available for recording trailers and what works best for you will depend on your needs and your budget. Two of the tools I have used are Sound Stage and iSimulate.

Sound Stage

Sound Stage is an OS/X app that allows you to screen capture your entire desktop, a specified region, or the iPhone Simulator output. It is available on the Mac App Store and only costs $5.

Pros

• Easy to use
• Optimized for utility apps
• Fair price
• Designed for capturing from the iPhone simulator

Cons

• No simulator audio capture
• Optimized for utility apps

Using the App

There are a number of options that allow you to set the quality, output file, viewing area, and touch indicators. One option that is lacking is simulator audio capture. This isn't a big deal for utility apps, but as game developer it is a feature I miss. They do provide audio capture from the built-in mic or the input jack so I could jerry-rig something, but it would be nice to have it baked in.

The best thing about the app is that it is very easy to get up and running. Just click the big red record button:

The app also allows you to select a soundtrack and drop in images so you could build an entire trailer using it. I prefer to use it for screen capture only and edit video in a more powerful solution.

This approach began to fall down for me when I needed to record footage from an app that required me to touch the screen in multiple places at once. I'm just not that fast with the mouse. This isn't a Sound Stage problem, it extends right through to testing on the simulator. There are shortcuts for the basic multi-touch gestures, but games often move beyond that.

The approach I used for Four Hats was to port it to OS/X and then map keyboard controls so I could simulate touches in all the right places. Cocos2d makes this pretty simple but it still takes some work and isn't going to work for every game. Then I discovered iSimulate.

iSimulate

iSimulate allows you to send the multitouch, GPS, accelerometer, and compass data from your iPhone to the iPhone simulator. The SDK is free but to use it you need to purchase an app from the iOS App Store that costs $16. I have to admit there was a bit of sticker shock looking at an app that costs 16X most of my App Store purchases. I then felt pretty ridiculous for feeling shocked about spending $16 on something that will save me hours. I believe in using good tools to magnify the effect of your time and this is one that is well worth it. This is a great tool not only for recording footage but also for debugging.

Pros

• Easy to get up and running
• Multi-use tool: gameplay trailers, faster debugging
• Good documentation

Cons

• Sticker shock (for an iPhone app)
• A bit laggy
• Ugly UI

Using The App

It is simple to set up an app to work with the iSimulate SDK. Download it. Link to it. You are done. One thing to note is that if you are not using CoreLocation in your app you will still need to link to it while linking to the iSimulate SDK or you will get a few linker errors that look like this:

Undefined symbols for architecture i386:

 "_OBJC_CLASS_$_CLHeading", referenced from:

_OBJC_CLASS_$_iSimulateCLHeading in libisimulate-4.x-opengl.a(libisimulate-opengl.a-i386-master.o)

Once you have your app up and running in the simulator you can launch iSimulate on an iDevice on the same WIFI network. You should see your computer in the list. Tap it to connect and then the data starts streaming.

Don't be scared off by the UI. It is one of the ugliest apps that I have purchased, but it works. I definitely suggest you read the documentation here. They have a few screenshots with legends that will help you get around.

If you are using iSimulate to record gameplay footage, then one of the first things you will want to do is remove or change the touch indicators. The default ones are giant gray circles.

You can remove them entirely by adding the following code to your AppDelegate's applicationDidFinishLaunching method:

if (NSClassFromString(@"iSimulate")) {

[NSClassFromString(@"iSimulate") disableTouchesOverlay];

}

If you want to replace the touch indicator simply add an image to your project named "isimulate-touch.png". There is a lot more useful information in the provided documentation so I suggest you check it out.

There is also an option to stream simulator output back to the iPhone which I can definitely see being useful.

I found that if I used iSimulate in conjunction with the simulator for more than 5 minutes the target app would start to slow down to a crawl. This happened both while connected to the debugger and while running the app independent of the debugger. I tested the same app without iSimulate connected and there was no lag.

Summary

I recommend adding both Sound Stage and iSimulate to your indie game dev toolkit. Both have flaws but save more than enough time to outweigh their cost.

If there are tools out there that fill these gaps at a lower cost or more completely, please share.