There. That feels good to get out. But it’s true. Starting in July, I’m on my own again, without the safety net of a guaranteed paycheck every week. Of course, paychecks are never guaranteed, especially in the technology business. But those of us with full-time jobs like to think there’s more stability there than there actually is.

Anyways, some of you who follow me may be a bit confused by this turn of events. So allow me to explain…

A few weeks ago, I made this bold claim on Twitter:

So yeah, I think I'm done trying to be an independent game developer.

— Jerrod Putman (@jerrodputman) April 28, 2013

After literally years of trying to work a full-time job and do part-time independent game development, I had become so frustrated that I finally just snapped and decided to stop trying. What followed was a long period of thought, soul searching, and prayer.

For two years, starting in 2009, I tried to make it as an indie game developer. In that time, we did manage to release two iOS games that I’m proud of. They never made enough for us to live off of, though, so when my wife and I found out mid-2010 that we were going to have a baby, I knew I needed to do something else. And thus I returned to full-time employment.

I’ve been at this job for over two years now, and I actually really enjoy the work. I don’t like the commute that much, but the work itself is actually pretty rewarding, as I get to develop iOS apps that specifically require the use of UIKit and all of Apple’s libraries.

With that said, this isn’t why I became a programmer. I went to Full Sail because I wanted to get into games. But at the same time, I’ve worked in the AAA games industry, and I never ever want to go back into that sort of life: the long hours, never getting to see my family, the poor management. The only way I would ever tolerate any of that is if it were my own game that I had complete control over.

And so, I’m going to give it another shot. And I’m going to give it the best shot I can. I’ve already got office space rented so I have a dedicated space to work (as opposed to a bedroom). In fact, here’s a shot of the office:

 

I’ve also decided that I’m done with iOS-only games. We already use Unity for everything we do, so we might as well go multiplatform. And I’m not just talking about Android or even OUYA (which we have a devkit for), but also PC, Mac, and even the big consoles (of which we’re already a licensed developer of one, and pending approval for a few others).

With that said, it takes a long time to develop games, and we don’t really have that much money saved up for me to do indie game development completely full-time, so I’m also looking for contract work. So if you need or know anyone who needs an experienced iOS or Unity developer, be sure to send them my way.

Anyways, this is a big step. I’m both utterly terrified and completely excited. Hopefully, it won’t be long before you hear about some of our new projects that result from this.

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.