With that said, we’ve got a lot of things in the works for this year. So stay tuned!

You can check out TouchArcade’s first look at the game here. Still a ways to go on it yet, but it should be out near the end of this Summer.

Development hasn’t gone quite as fast as I would like, as implementing the game’s progression system was more complex than I had originally thought. But there are lots of other things happening with the game to keep motivation levels high.

Hiring Artists on oDesk

We took a big step in development a few weeks ago and decided to post a job on oDesk. As this was the first time we had ever attempted to work with others who we hadn’t actually worked with before in some other capacity, I was a bit skeptical that we would actually be able to find what we needed. However, the experience so far has been incredible!

We initially started with only a single job posting for a background artist, as we wanted to see what kind of response we would get. Over a single weekend, we had more than 70 applicants, and we ironically had a very long “short list” of applicants who we thought would fit the style we were looking for.

At the end of the day, we could only pick one applicant. So we narrowed down the short list, and came down to the two strongest ones. We asked them each to perform a (paid) test job, with the same tasks and requirements, and see how they handled it. Here’s the result of the background artist who we didn’t go with:

A test background from an oDesk applicant.

Now, if you’re like us, you probably think that looks really awesome! However, after a lot of deliberation, we decided the other artist’s test was much closer to what we were looking for. And very shortly, we had hired our very first art contractor! So far we have seven completed backgrounds (out of roughly 30 or so), and they all look amazing… but we’re not going to show our hand just yet.

A pleasant side effect of having so many applicants is that we actually found an artist to draw up the rest of our game’s monsters. We simply created a private job in oDesk and invited the artist to it directly. We’re now on the second batch of monsters, and so far all of them are looking fantastic.

I think one of the reasons why we had such a strong response to our job posting is that we actually included a fair amount of reference art from the artist who had previously worked on the game (but who was sadly unavailable to finish — pesky day jobs with good pay). This let prospective artists immediately see the requirements for the job, as well as advertising how fun and rewarding the job could be. So if you’re on the lookout for contract artists, definitely include some reference art for your game. Remarkably, artists tend to be visual people!

Marketing Opinions

One of the things I’ve been wrestling with is how to market our game. We’ve got a unique gameplay mechanic that we need to make sure gets presented to players without having to explain it too much. We’ve got a couple of ideas on how to do this, but we’re a bit concerned on when we should start marketing blitz.

In the indie circles, it’s been said that talking early and often is the way to go, and I understand the reasoning behind it. However, I’m still concerned about showing our hand too early, partially because of our gameplay mechanic, but I also don’t like promising stuff and then not delivering it (something we’ve done in the past, unfortunately). Although, for that last one, we’ve gone past the point of no return considering how much we’ve put into the game. It’s really only a matter of time now…

So here’s my question to other developers in the audience: We’re about 2 to 2 1/2 months out from release; when would you suggest we start talking about the game? I realize we’ve already been talking about the game, but only in the vaguest terms — this would be more like, an actual name, trailers, images, and gameplay specifics. Should we start now? A month out from release? Four months ago? What?

That’s all for now. There’s a lot of work left to be done on Game 3, but it’s slowly starting to come together!

Storyboarding in iOS 5 is really neat. It allows you to lay out nearly your entire interface visually, and gives you some neat features that simply make your life as a developer easier. Since our next game (an RPG) is going to be extremely UI-heavy, naturally we wanted to use Storyboarding to create our interface. The problem comes when it’s time to fire up Cocos2D and display our battle scenes.

However, with Cocos2D 2.0 (the OpenGL ES 2.0 version) and iOS 5′s view controller containment functionality, integrating Cocos2D in a Storyboard is actually very trivial.

Containing Cocos2D

Let’s start by creating a new class called CocosViewController, which derives from UIViewController. It should also conform to the CCDirectorDelegate protocol.

#import "cocos2d.h"
 
@interface CocosViewController : UIViewController <CCDirectorDelegate>
 
@end

So far, so good. Now, there’s something important to note about Cocos2D 2.0′s director, especially if you’re used to 1.x: The 2.0 director actually derives from UIViewController! This makes it incredibly easy to add a Cocos2D view to our hierarchy.

Over in the implementation file, you’ll want to set up your viewDidLoad method like so:

- (void)viewDidLoad
{
    [super viewDidLoad];
 
    CCDirector *director = [CCDirector sharedDirector];
 
    if([director isViewLoaded] == NO)
    {
        // Create the OpenGL view that Cocos2D will render to.
        CCGLView *glView = [CCGLView viewWithFrame:[[[UIApplication sharedApplication] keyWindow] bounds]
                                       pixelFormat:kEAGLColorFormatRGB565
                                       depthFormat:0
                                preserveBackbuffer:NO
                                        sharegroup:nil
                                     multiSampling:NO
                                   numberOfSamples:0];
 
        // Assign the view to the director.
        director.view = glView;
 
        // Initialize other director settings.
        [director setAnimationInterval:1.0f/60.0f];
        [director enableRetinaDisplay:YES];
    }
 
    // Set the view controller as the director's delegate, so we can respond to certain events.
    director.delegate = self;
 
    // Add the director as a child view controller of this view controller.
    [self addChildViewController:director];
 
    // Add the director's OpenGL view as a subview so we can see it.
    [self.view addSubview:director.view];
    [self.view sendSubviewToBack:director.view];
 
    // Finish up our view controller containment responsibilities.
    [director didMoveToParentViewController:self];
 
    // Run whatever scene we'd like to run here.
    if(director.runningScene)
        [director replaceScene:[MyScene scene]];
    else
        [director runWithScene:[MyScene scene]];
}

And so that we’re nice and polite programmers, we’ll clean up after ourselves:

- (void)viewDidUnload
{
    [super viewDidUnload];
 
    [[CCDirector sharedDirector] setDelegate:nil];
}

And that is quite literally all of the code that you need to write to get the basics up and running. Let me explain a little bit about what’s going on.

In viewDidLoad, we first check to see if the director’s view has been loaded. Remember that the Cocos2D director is now simply a subclass of UIViewController, so we can use methods like isViewLoaded to get information that we need. If the view hasn’t been loaded, that means we haven’t created an OpenGL view for the director yet, so we do that if necessary.

After that, we do the real magic, which uses iOS 5′s view controller containment. We first add the director as a child view controller. Doing this means that the director’s viewWillAppear:, viewWillDisappear:, et al will be called properly, and in Cocos2D 2.0, that means that the director will automatically pause and unpause itself when the view controller disappears or appears. Awesome!

We then add the director’s view (the OpenGL view) to our view controller’s view hierarchy and send it to the back. Sending it to the back allows us to place buttons and other UIKit stuff on top of the OpenGL view in Interface Builder. Finally, we need to call the director’s didMoveToParentViewController: method, as required for view controller containment. We then run our scene, and that’s it!

Adding Cocos2D to a Storyboard

Here we have a perfectly normal Storyboard, with a navigation controller and a view controller that has a simple button.

Now let’s drag a new view controller onto the canvas,

and assign its class to the one we just created.

Set up a segue between the button and our new view controller. Set the segue type to “Push” for now.

And now, just build and run! You should be able to press the button to load your Cocos2D scene, press the back button to stop it, and repeat the process over and over again! You can even add a button to the CocosViewController if you’d like.

Some Notes

As you may have noticed, Cocos2D’s initialization happens whenever CocosViewController is first pushed onto the navigation stack (aka, lazy loading). You may prefer to initialize Cocos2D right at launch to minimize the initial delay.

Also note that if you want to have Cocos2D in the background and have a navigation controller on top (so that you can have a navigation structure for your pause menu, for example), you’ll need to add another navigation controller as a child view controller. View controller containment isn’t really supported in Interface Builder, sadly, so if you do this, you’ll probably want to create another storyboard file and load it as your child view controller.

Additionally, there may be some gotchas with this code that I just don’t know about, as it’s only had minimal testing. So let me know if you run into any troubles, and I’ll try to keep the post updated.

There was a bit of a setback on progress as my daughter, my wife, and myself all got the nasty stomach virus that’s been sweeping across the country lately. While it was only a 24-hour illness, recovery took quite a bit longer. However, unlike before when I would have a break in development and have trouble getting started again, I was able to jump right back into it once I was able. How was I able to accomplish this seemingly impossible task?! Why, through planning, of course!

Having A Plan

It’s important to note that both Sheepstacker and Word Monkey were made without any planning or design documents. I began work on their prototypes, saw that they were good, and just continued on until we said, “Now this is a game!” Essentially, the entirety of the game designs had to be kept in my brain. And as you may know, the brain can sometimes conveniently forget things (especially my brain).

For this new game (which I’m calling TTG3 until its official unveiling), I realized that this method of scattershot design just simply wasn’t going to work. The game is somewhat of an RPG, and it’s made up of many independent gameplay systems and stats that all need to work together in a logical way. Additionally, we’ve decided that we’re going to hire contractors for the artwork instead of using pre-made art, and working with contractors means you really need to have a clear plan. Otherwise, you’re wasting the contractor’s time and your money.

So I started by creating a bunch of tickets in my issue tracker. I use Lighthouse due to the fact that it’s incredibly streamlined, allowing me to focus on the tasks and not on management. Each of these tickets is something like, “Create the design for the battle system” or “Create the design for player progression”. In other words, each ticket is focused on a single chunk of the game’s complete design.

At first, I began assembling a massive “game design bible” that was to include every minute detail of the game, down to the very stats of each character in the game. I quickly found that I was spending more time trying to organize the document than actually trying to write it. Instead, I decided to create a single document for each of the tickets I had created earlier. This way, each document remained focused on a single gameplay system. I also decided to keep the design documents in Google Docs so I can access and make changes to them from anywhere. Additionally, I can link to the actual documents in the tickets to easily reference them.

So far, this has worked wonderfully. It has not only kept me focused on a single task at a time, but it’s also helped me to plan out every feature of the game ahead of time. It’s important to note that these documents won’t always be strictly adhered to (as game development requires fluidity and adaptability); they’re simply guides for when I inevitably get to a point in production where I don’t know what to work on next.

Executing the Plan

Naturally, the next phase of development is to actually execute the plan I’ve laid out. Since we already know the requirements for the in-game art, we’ll be able to start the search for artists as early as next week.

We’ll be handling UI art a bit differently. Since the game is an RPG and is thus very menu- and UI-based, we’re going to prototype all of the UI for the entire game with temp art, work out the kinks, and then finalize our design before sending it off to someone to beautify it.

The overall plan for the next phase of development is to have all gameplay systems implemented and all UI prototyped in roughly a month. We’ve got a lot of work ahead of us, but with a good solid plan in place, I think we’ll definitely be able to do it!

This post is going to be about my indie game development New Year’s Resolutions; three things that I’ve resolved myself to doing in 2012 for Tiny Tim Games. If nothing else, it’ll give a sense of where I would hopefully like to go this year, and also possibly motivate you to make your own indie game dev resolutions.

1. Release at least one new game in 2012

So 2011 was a rough year for Tiny Tim Games, as we had no new releases, lots of false starts, and lots of things to distract us from working on games (daughter, day job, etc). The thing is, these things are still here, and until we make bajillions from one of our future breakout hits, that situation isn’t going to change.

But I still have the passion to be creative. I still want to create my own worlds for others to play in and enjoy. So my first resolution is to release a brand new Tiny Tim Game in 2012. Hopefully, giving ourselves an entire year to accomplish the goal will help the time not be so stressful. After all, our 9 month old daughter is about one step away from walking, so finding additional development time isn’t going to come easy.

2. Work on the game I WANT to make

This sounds like a natural thing to do. I mean, isn’t that why you become indie? To make the games you actually want to make? Well, after the very modest success of Sheepstacker and Word Monkey, I had wanted to make a few games that were quick and simple and could possibly generate some cash flow for us to work on some of our more ambitious projects.

The problem with this is that I didn’t really have any passion for those projects. Safety First, Sol Defender. While they each had some interesting qualities about them, and I may want to return to parts of them in the future, there has been one game I’ve been wanting to do since mid-2009.

It’s always seemed too ambitious though, at least from an artistic standpoint. We’ve already spent quite a lot of money trying to bring the game to life, only to end up with 1/3 of the art we need, and no way of funding the remainder of the project. But it’s the project I most want to do and have wanted to do for a year and a half now. So I’m committing myself to finding some way to make it happen.

One thing I’ll be doing to make this happen is to leverage pre-made art from online sources. Personally, I’d rather have completely original art, but as I’m not an artist and I can’t afford one, I don’t really see any other option. I’m guessing the greater population of iOS gamers don’t browse TurboSquid or the Unity Asset Store, so the chance of them running into these assets in the wild is pretty small.

3. Be more social

As I’m quite shy, I’m really bad a networking. I just don’t have the ability to walk into a room full of people and join in on a conversation. Unfortunately, if no one knows about you, it’s really hard to get the word out about games.

So I’m challenging myself to be more active in the indie game dev community. I haven’t been to any of the conferences over the past few years (partially due to lack of funds), but I never really placed them as a priority. My plan this year is to hit both GDC and WWDC, and maybe a smaller conference here or there. I’ll also be trying to blog more regularly (with the help of #iDevBlogADay), especially about the new project.

That’s all for this time. Hopefully, my next post will have some tantalizing information about the new game. See  you then!

So you’re writing your Unity plugin to do some cool native functionality, but you really need it to do some work right when the app launches. There are usually two ways to solve this problem: 1) Create an “init” function that you call from Unity script when your first scene is loaded, or worse 2) modify application:didFinishLaunchingWithOptions: directly. Technically, there’s a third option too, involving creating a category of the AppController delegate and “overriding” application:didFinishLaunchingWithOptions:. The OpenFeint Unity plugin uses this method, actually, but as I mentioned in a previous post, this has some serious drawbacks, especially if you want to use the technique more than once (and yes, I realize I’m the one who originally wrote that plugin… I didn’t know!).

I’d like to introduce you to the UIApplicationDidFinishLaunchingNotification key, something which has become a good friend of mine.

It always bugged me that the UIApplicationDidFinishLaunchingNotification key existed. I couldn’t possibly think of a use for it. In my mind, the first place that any application code could ever run was in application:didFinishLaunchingWithOptions: (or its precursor, applicationDidFinishLaunching:), and so the key was not necessary. I assumed it was just some thing require by the OS that we weren’t really supposed to use.

But one day, I decided to actually investigate the uses of this key instead of basing my assumptions on pure speculation. I found the NSObject class method load. Suddenly, the key started to make sense.

The documentation for load says that the method is “invoked whenever a class or category is added to the Objective-C runtime; implement this method to perform class-specific behavior upon loading.” Essentially, what this means is that any code inside your class’s load class method will be executed before application:didFinishLaunchingWithOptions:. If you want to write any startup code, this seems like it would be the place to do it. But there is a caveat: Other classes may not have loaded themselves yet, so it’s not safe to do too much in this method.

Instead, you should add your class as an observer of the UIApplicationDidFinishLaunchingNotification key with an action method to do any initialization you want. This will allow all classes to be fully loaded, but still allow for initialization code to be run without having to have either an initialization function in Unity script or by modifying AppController’s application:didFinishLaunchingWithOptions:.

Here’s an example:

@interface MyCoolPlugin : NSObject
 
// Class stuff.
 
@end
 
static MyCoolPlugin *_sharedInstance = nil;
 
@implementation MyCoolPlugin
 
+ (void)load
{
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(createMyCoolPlugin:)
        name:UIApplicationDidFinishLaunchingNotification object:nil];
}
 
+ (void)createMyCoolPlugin:(NSNotification *)notification
{
    // This code will be called immediately after application:didFinishLaunchingWithOptions:.
    // You could use this to create an instance of your plugin class, like so:
    _sharedInstance = [[MyCoolPlugin alloc] init];
}
 
// Your plugin methods.
 
@end
 
// C functions to access your plugin from Unity script.

Not only can you use UIApplicationDidFinishLaunchingNotification, but you can also observe keys like UIApplicationDidEnterBackgroundNotification. Essentially, you can plug into most of UIApplicationDelegate‘s methods without having to modify Unity’s AppController. And naturally, if you’re creating standalone Objective-C libraries, this method is essentially required unless you want your users to modify their app delegate.

That’s all for this week. For my next post in two weeks, we should have some very exciting news to share about a project we’ve been working on!

But what if you need to extend CCNode itself? You could subclass CCNode, but then CCSprite and other subclasses wouldn’t get the benefits of your subclass. You could modify the CCNode source code, but if you update to a future version of Cocos2D, you’re likely to run into merge problems or (worse) lose all of your changes.

This is where we can leverage the fact that Cocos2D is written in Objective-C. The language provides lots of excellent features that allow us to extend a pre-existing class without subclassing.

Category Extensions

If you’ve been working with Objective-C for very long, you’ve probably come into contact with the concept of categories. In a nutshell, a category allows you to add methods to an existing class, even if you don’t have the source code for that class. Categories are simple enough to use. In your header file, you simply declare the category like so:

@interface CCNode (MyExtensions)
 
- (void)myExtensionMethod;
 
@end

In this example, MyExtensions is the name of the category. Then, in your implementation file:

@implementation CCNode (MyExtensions)
 
- (void)myExtensionMethod
{
 
// Do something interesting here.
 
}
 
@end

So now, on any CCNode (or any subclass derived from CCNode, including CCSprite), you can do something like this:

CCSprite *aSprite = [CCSprite spriteWithFile:@"test.png"];
[aSprite myExtensionMethod];

You can also override methods in CCNode with a category, but you have to be very careful with this. In fact, Apple says this is “strongly discouraged”. The problem arises when you have two categories trying to override the same method. The method that takes precedence is not defined.

So as you see, categories can be pretty useful, but they do have one particularly annoying limitation: You can’t add member variables to a class through a category. This becomes extremely limiting when you need to add something like per-instance storage of an array or reference. However, there’s another (more advanced) feature of Objective-C we can use to get around this limitation.

Associative References

There is a set of Objective-C runtime functions that allows you to create associative references. Basically, it allows you to make an association between one object and another, usually to simulate the addition of object instance variables to an existing class without having to modify the original class.

Let’s use an example from CCKit to illustrate how to get this working. In CCGestureRecognizer, we need to keep track of all of the gesture recognizers that have been added to a CCNode. Before, we would have to go into the CCNode code and add an NSMutableArray to the class declaration. However, since CCKit is a set of standalone classes, this approach wouldn’t work.

So in the addGestureRecognizer: method (which is part of a CCNode category called GestureRecognizerAddtions), we do something like this:

// A key to access the associative reference.
static char CCNodeGestureRecognizerAdditionsKey;
 
NSMutableArray *gestureRecognizers = [[NSMutableArray alloc] init];
[gestureRecognizers addObject:gestureRecognizer];
 
objc_setAssociatedObject(self, &CCNodeGestureRecognizerAdditionsKey, gestureRecognizers, OBJC_ASSOCIATION_RETAIN);

As you can see, we created an NSMutableArray, added an object to it, and then called the Objective-C runtime function objc_setAssociatedObject. The first parameter is the object you want to associate with (in this case, a CCNode), the second is a key with which you’ll access the associated object (the key must be a void pointer, so we create a static variable here for simplicity), the third is the actual object we want to associate, and the last parameter is the association policy. As you can probably guess, the association policy is similar to property attributes. The above is essentially like declaring this:

@property (retain) NSMutableArray *gestureRecognizers;    // "strong" would replace "retain" in ARC.

So we’ve set up the association. How do we access the object?

NSMutableArray *gestureRecognizers = objc_getAssociatedObject(self, &CCNodeGestureRecognizerAdditionsKey);

And that’s it! We just added a member variable to CCNode without actually changing its source code! Additionally, the array will be released when the CCNode is deallocated, so it even cleans up after itself.

Of course, you’ll only want to use this in certain situations. But if you need to extend the functionality of CCNode by adding member variables, and a subclass won’t work for you, associative references are an excellent way to accomplish what you need.

CCKit Updates

If you’ve been watching the CCKit project over on GitHub, you may have noticed a flurry of commits in the past few days. A few of those commits were critical bug fixes, so I suggest you grab the latest. But there was also some new functionality included: the CCNavigationController class!

This class is a Cocos2D version of UINavigationController. It was designed with menu sequences in mind, but it could be used for almost anything I suppose. Basically, you create the navigation controller with a root node (any CCNode-derived subclass that implements the CCRGBAProtocol will work, i.e., CCSprite or CCMenu). You can then push and pop nodes onto and off of the navigation stack, just like with a UINavigationController. There’s even an appropriate animation effect to go with it.

So if you need to create a hierarchical main menu for your next game, CCNavigationController may fit your needs.

What I’m going to talk about in this #iDevBlogADay post is a new set of classes I’m calling CCKit. The purpose of the library is to bridge the gap between Cocos2D and Apple’s UIKit classes. The library includes classes like CCScrollLayer (UIScrollView emulation) and CCTableLayer (UITableView emulation) which should give very close approximations to the UIKit equivalents. Additionally, the library is open source and hosted on GitHub, so feel free to include it in your own projects and even contribute if you’d like.

CCScrollLayer

The CCScrollLayer class (and both CCTableLayer and CCTableLayerCell classes) are derived from code written by Sangwoo Im in his CCTableViewSuite. The original code has provided a lot of Cocos2D-based games with good UITableView approximations. While the table view implementation feels pretty good, I felt that the scroll view implementation could go a bit further.

The CCScrollLayer class in CCKit supports nearly all of the features of Apple’s UIScrollView class, including bouncing, deceleration, and pinch-to-zoom. There are a few features missing (such as paging and directional lock) that will be added over time. I spent a lot of time playing around with values trying to get the bouncing and deceleration to feel correct. The zoom also properly mimics zooming in and out from the centroid of the two touches on the screen instead of just from the center of the screen (which is a personal pet peeve of mine).

Panning and zooming are implemented with gesture recognizers. I apologize to those wanting to deploy for targets below 3.2, but the benefits of using gesture recognizers are too numerous. For one, you can use your own gesture recognizers in cooperation with the recognizers for the scroll layer, and even set up dependencies between them (i.e., don’t pan if a long press is detected first).

Other than the aforementioned features, a CCScrollLayer works pretty much like any other CCLayer, which means you can add all of your sprites (and even other layers) to it. Here’s how to set one up:

CCScrollLayer *scrollLayer = [CCScrollLayer scrollLayerWithViewSize:[[CCDirector sharedDirector] winSize]];
scrollLayer.contentSize = CGSizeMake(5000, 5000);
 
// Add whatever you want to the scroll layer using addChild:
 
// Add the layer to the scene.
[scene addChild:scrollLayer];

CCTableLayer

CCTableLayer is still a work-in-progress, and as such isn’t ready for primetime yet. We need a UITableView implementation for our game, though, so it should be coming soon.

CCGestureRecognizer

This class was originally written by Joe Allen. Most of my changes involved cleaning up the public interface so only the functionality necessary to use the class was exposed. The original implementation also required modifying code in CCNode. I’ve removed that requirement by putting the changes in a category extension.

The class essentially acts as a wrapper for a UIGestureRecognizer. In fact, the only real functionality this class provides is the ability for your gesture recognizers to respond to node touches instead of just view touches. Now, for instance, you can set up UITapGestureRecognizers on your sprites and have each sprite respond to the tap only if it was touched.

Here’s how to set one up:

- (void)onEnterTransitionDidFinish
{
   [super onEnterTransitionDidFinish];
 
   UITapGestureRecognizer *tapGestureRecognizer = [[UITapGestureRecognizer alloc] init];
 
   // Set up the tap gesture recognizer like you normally would.
 
   // You'll want to retain ccRecognizer for later use.
   CCGestureRecognizer *ccRecognizer = [CCGestureRecognizer recognizerWithRecognizer:tapGestureRecognizer target:self action:@selector(handleTapGesture:)];
   [self addGestureRecognizer:ccRecognizer];
}
 
- (void)onExit
{
   [super onExit];
 
   [self removeGestureRecognizer:ccRecognizer];
}
 
- (void)handleTapGesture:(UITapGestureRecognizer *)gestureRecognizer
{
   // Do something when this sprite/node is tapped on!
}

If you look in the CCScrollLayer.m file, you’ll see that it’s using the CCGestureRecognizer class to set up its UIPanGestureRecognizer and UIPinchGestureRecognizer.

More To Come

For the time being, the code is made with ARC in mind. If you try to run this in a non-ARC project, you’ll probably leak memory everywhere. Apple has made it clear that ARC is the future of iOS development. There’s going to be a dearth of ARC-compatible source code samples when iOS 5 is made public, so I’m hoping we can start filling that void.

As mentioned before, this library is a work-in-progress and will be added to on a constant basis. I can tell you that from our end, we’ll add things as we need them in our own games. However, if you have something you’d like to contribute, then feel free to send a pull request. Just remember that the library is solely for mimicking or allowing access to Apple’s UIKit functionality in Cocos2D.