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.

You will still need to follow the steps below to include Cocos2D in your project, or you can follow the instructions listed here to simply turn ARC off for just the Cocos2D files.

This is my very first post for #iDevBlogADay. I had been scheduled to do it earlier this year, but then something happened. I’m not exactly torn up about it.

In my last post, I mentioned a new project that we’re attempting to do before we hop back on to Sol Defender. We decided Cocos2D was the right fit for the project, as the game simply works better in 2D. We also really wanted to use a lot of the new features coming in iOS 5, which while technically accessible to Unity through plugin “glue code” is simply quicker and easier to access if you’re working entirely in Objective-C.

Due to the iOS 5 requirement, I specifically wanted to start using ARC (automatic reference counting) as I (and Apple) thinks this is the way to go moving forward regarding Objective-C. If you don’t know about ARC, I suggest you read up on it a bit, but in a nutshell, it reduces (eliminates?) memory leaks by removing the need for calls to retain, release, and autorelease as the compiler will handle inserting these calls for you. Apple even managed to get ARC backwards-compatible with iOS 4, so even if you’re not using any iOS 5 specific features, you may still want to make your next game with ARC.

The thing is, if you try to compile the Cocos2D files with ARC, you’ll be greeted by a nice big list of broke. So how do you get Cocos2D and ARC to play nicely together?

No ARC for Cocos2D

Unless you want to completely rewrite Cocos2D from the ground up to be ARC-compatible, you’re going to have to disable ARC for the Cocos2D source code. If you’re using one of the Cocos2D templates or have simply dragged the source code into your Xcode project, you’ll need to disable ARC for each of the .m Cocos2D source files by setting the compiler flags for each Cocos2D source file.

But there’s an easier way, and it uses something called cross-project references. For Cocos2D, this is actually quite simple to set up. In your Cocos2D source folder, you’ll find an Xcode project called cocos2d-ios.xcodeproj. Simply drag this into your Xcode project, and it’ll show up as a project within your project. You can then go into your project Build Phases settings and add the Cocos2D libs to the Link Binary With Libraries build phase.

After this, go to your project’s Build Settings, set Always Search User Paths to YES, and add your Cocos2D source directory to User Header Search Paths, and make sure it’s marked Recursive.

Now what was the benefit of doing all of this? Well, instead of going through all of the Cocos2D source files and disabling ARC compiling for each one of them, you can simply disable ARC compiling for just the Cocos2D project (and thus the Cocos2D static library it creates) and leave it enabled for the rest of your project. In fact, the Cocos2D project should already have ARC compiling disabled, so you’ll just need to make sure ARC is enabled for your parent project. (Note: While ARC itself isn’t under NDA as it’s a part of LLVM, the new Xcode which integrates ARC settings is, so you’ll have to figure out how to enable ARC for your project yourself. It’s pretty easy though, and you can always poke around the Apple Developer Forums to find what you’re looking for.)

Some Cocos2D Modifications

If you were to build your project as it is, you’ll notice that it still doesn’t compile, complaining about ARC stuff. What gives? I thought we turned off ARC compiling for Cocos2D? We did. The source files are not being compiled under ARC. What is being compiled under ARC is any header files you include in your ARC-compiled source files (i.e., cocos2d.h, and everything that it includes).

So what do we do? We’ll need to make some modifications to header files, but it’s only a few files. I’ve forked the main Cocos2D git repository and included these changes here, so if you want you can just download that and use the Xcode project in it instead of making these modifications by hand. I’ll try to keep this repo integrated with new versions of Cocos2D.

First, open up CCDirectorIOS.h. Find the CCDirectorFast interface, and remove the NSAutoreleasePool ivar. Switch over to CCDirectorIOS.m, and add the following somewhere:

static NSAutoreleasePool *autoreleasePool = nil;

Then, open up CCActionManager.h. Near the top, you’ll see a struct called tHashElement. This struct references some Objective-C objects, which is a no-no in ARC. To get around this, you simply want to add some modifiers to tell the compiler that we know what we’re doing and to not worry:

typedef struct _hashElement
{
	struct ccArray	*actions;
	__unsafe_unretained id			target;
	NSUInteger		actionIndex;
	__unsafe_unretained CCAction		*currentAction;
	BOOL			currentActionSalvaged;
	BOOL			paused;
	UT_hash_handle	hh;
} tHashElement;

And finally, the biggest change of them all. If you go to ccCArray.h, you’ll notice a similar situation to above, a struct with a reference to an Objective-C object, which can be easily solved with __unsafe_unretained:

typedef struct ccArray {
	NSUInteger num, max;
	__unsafe_unretained id *arr;
} ccArray;

But the bigger problem is the rest of the file. There’s a bunch of inline functions which do all sorts of un-ARC-able things. Unfortunately, the only real solution is to move the body of these functions into a new .m source file, and leave behind only the function prototypes in the header. For this, I strongly recommend just downloading the two files (here and here) directly from GitHub.

Retain Knowledge, Not Objects

After you’ve done these few modifications, you should be able to compile and bask in the glory that is ARC! Should you retain that CCSprite object? Who knows! You don’t have to worry about it anymore! You can create Cocos2D objects in your ARC code, and the compiler will handle all of the retain/release stuff for you. Meanwhile, the Cocos2D objects handle their own memory management internally. They both work together so that you can write your code faster and cleaner than before.

Note that you can also use this trick with other 3rd party libraries. As you might have noticed in the screens above, I have Objective-Chipmunk (an Objective-C version of the Chipmunk physics library) working with ARC as well, and it only required some minor changes in a single header file.

If you have any questions about this procedure, just post a comment below, and I’ll try to answer any questions to the best of my knowledge.

The other project I wanted to pursue was updating our existing games. It’s been a long time since we’ve pushed out any updates, and our games seriously needed them. As you may have seen from our news section, we managed to release an updated version of Sheepstacker. I’m going to go into a bit of what changed and what we had to do to get this update out the door.

Embracing UIKit

For both Sheepstacker and Word Monkey, we used a custom-built UI solution that used Unity’s built-in GUITexture and GUIText types. While I had gotten very good at manipulating it, it was still a pain to work with and not at all flexible. For version 1.4 of Sheepstacker, I decided to do something crazy and completely rewrite the UI (all of it) completely in UIKit.

The first step in this process was downloading and importing Prime31‘s excellent NativeToolkit plugin, which provided a simple interface for showing UIKit view controllers whenever necessary. I had to make some modifications to the Objective-C code, however, as I wanted to have a static background view that would stick around through navigation transitions (i.e., a “paused” image and dark background are always visible while the user is paused, even if he goes to the options screen).

Creating the screens in UIKit was a breeze, because I was able to use Interface Builder to lay everything out. Retina display support was handled automatically (I just had to supply an @2x version of each image). And the iPad UI was dead simple to implement as well, as I simply created separate XIBs and used the same classes to power them.

On the whole, I enjoyed the process, but it too much longer than I had anticipated it would. This mostly had to do with the fact that we already had a fully functional game set up in a particular way that was now having all of its UI rewritten. In fact, all of the old UI was removed. The only thing that remains is in the in-game HUD, as it would have been too much of a performance hit to have that handled in UIKit (would have to send the game state to native code each frame, which is a bit expensive to do).

Game Center and the End of AGON

Game Center was implemented through the use of another Prime31 plugin. For the most part, this process was straightforward, with the exception of having to serialize scores and achievements when there’s a network error.

My favorite new feature in the update is the display of your friends’ high scores when you finish a game. I saw this feature implemented in Retro Dreamer’s excellent Velocispider and though to myself, “This needs to be in Sheepstacker!” It really motivates you to keep playing the game when you see that your friend has a higher score than you, instead of some random username.

Another reason for pushing out this update now is that the AGON Online leaderboards and achievements platform is scheduled to shutdown on June 30th. While the AGON team gave us plenty of time to do something about this, what they didn’t provide was an updated library that worked with the latest version of Unity and Xcode. Unfortunately, this meant that we were unable to save any of our users scores or unlocked achievements.

While I’m personally deeply regretful about this, the fact is that we actually did make a few significant gameplay changes that might have made resetting the leaderboards a necessity anyways.

Gameplay Tweaks

The fact that the sheep spew forth nickels when you combo stack is really just a joke between my wife and myself. I asked what should spew out when a combo started (thinking of sparkles or something), and my wife said plainly, “Nickels.” And that was the end of that.

What I didn’t do a good job of was incorporating the nickels into the actual gameplay. The nickels were originally supposed to be another score type, as it was more indicative of how well you stacked instead of how high you stacked. However, most players were simply confused by their presence and referred to their stack height as their score. Even I did this.

In the new version, I wanted to make the nickels actually important to gameplay. We’d had this odd game rule where the user would get an extra heart every 50 sheep stacked (plus one at 25). In 1.4, that rule has been removed and extra hearts are now earned with every 250 nickels. This means that a player’s stack quality directly affects how high he can stack, because the better his stack, the more nickels he has, which means more hearts, which means more chances to keep stacking. I’m a bit irritated that I didn’t come up with the idea two years ago when we first released the game as it seems so obvious now. Nickels also add extra time to Speed Stack, again directly affecting gameplay.

The other tweak we made was reducing the maximum heart count from four to three. We had three hearts initially when we were developing the game, but felt that the game was too hard for newer players. After seeing more players play the game, I came to realize that the extra heart didn’t actually help that much. In fact, it seemed to have the opposite effect as players wouldn’t play as carefully as they did when there were only three hearts. The change just “feels” right. That’s really all there is to it.

Now What?

So Sheepstacker 1.4 is out, and I hope everyone is enjoying it. Unless necessary, the game probably won’t see another update until iOS 5 releases later this year (as we want to update the game to take advantage of some of the new Game Center features).

But what’s next? Back to Sol Defender? Not quite yet. We have an opportunity to be on the leading edge of iOS gaming. It’s an interesting opportunity, and it may not pan out, but we’ve got to try it. After we’re finished with that, I’ll be returning to Sol Defender, as it’s a game I’ve been wanting to make since the App Store launched.

I’m sad to say that in all my years, I’ve never tried to sit down and learn to play or write music. I knew I wanted to make my own games, but I just assumed someone else would write the music. After all, they have the talent… whoever “they” are. But I’ve been studying music for a long time. I enjoy the music I listen to, but oftentimes I’ll just sit, listen, and study the reason why a particular piece of music makes me feel the way I’m feeling.

Cut to January 2010. Shannon and I are working feverishly on Word Monkey, trying to tie up all the loose ends before sending it to the gatekeepers at Apple. One of the last things on the list is to find some music. I had assumed we would just license some music online, but after many days of searching, I just hadn’t found what I was looking for.

Then Shannon, wonderful wife that she is, decided she’d take a stab at making something in GarageBand.

The Gateway Drug

As I watched Shannon play around in GarageBand, I was impressed by what she was able to create with very little effort using the built-in Apple loops. After hearing a few things she had created, I decided I’d like to play around in GarageBand for a bit as well. I was bleary-eyed and worn out from UI coding marathons, so a bit of experimentation sounded like fun.

After a day of playing around (and a few tweaks thereafter), here is the main gameplay track you hear in Word Monkey today:

Granted, it’s all made from some edited and filtered Apple loops, but I was pleased with what we had created. It was new; it was created specifically for our game; and most importantly, it was what I was looking for!

From then on, I started studying music more seriously. I ran through the lessons included with GarageBand. I bought myself a MIDI keyboard from the local Apple Store. I remember the checkout clerk asking if I wrote music. I answered, “Not yet!” Unfortunately, it wouldn’t be until December that I would actually sit down and try to actually write anything substantial.

Sol Defender

I started what I would call “work” on Sol Defender in November 2010, and as I mentioned in a previous post got sidetracked by the Visualize plugin and holidays and such. But in December, I started to get the itch to write a little bit of music for the game.

I knew the style I was going for. I’m a big fan of David Bergeaud‘s work for the Ratchet & Clank series (a benefit of working at Insomniac was that I had direct access to the uncompressed music files) which tends to emphasize harsh brass (think Michael Giacchino’s work on the TV show Lost) with some drum loops to keep the pace with the on-screen action. I remember the first time the music was placed into the Kavu Island level of Ratchet & Clank: Up Your Arsenal and how it magnified the intensity of the battle tenfold. That was the effect I wanted to achieve with Sol Defender’s music.

So I grabbed the Orchestral Jam Pack for GarageBand and, being that drums are the instrument I actually know how to play, I started with a simple pounding beat.

From there, I added brass to the beat, with a little French horn crescendo to liven up the dead space between.

With just that, I was already pretty excited by what I had. It was actually starting to sound like something! Not much, but something! I added two drum loops after the eighth measure and threw in a little timpani transition to kick it off. And then… hmmm… there was a lot of blank space left to fill.

I still didn’t really know a lot of the fundamentals to music, so I just started playing some chords with the brass ensemble instrument. Hey, not bad! I kept going, and before long I had sixteen measures, and it even looped nicely!

I had actually thought about stopping there, but then I had a thought for a small cool-down section after the brass “chorus”. So I loaded up the string staccato instrument, and went to work:

At that point, I had the essentials to the very first track for Sol Defender. After a lot (a lot) of additional iteration, I now present the (hopefully) final version of “Final Hour”:

And here’s what the GarageBand window for this song looks like:

Click to enlarge

Something In Between

Here’s another track I’m working on for the game, which will go in the level selection screen, so it’s a pretty short loop. A bit of backstory: I remember the first time I heard Dream of the Shore from Chrono Cross after Serge crossed over into Another World where no one recognized him, even the girl who had just finished saying they would never forget that day (at least in my playthrough). It’s that sort of mood that I wanted to capture with this track. The first time you see this screen is after a pretty big story event during the prologue, and I wanted the music to reflect the mood of the story after that point.

I don’t think I’m quite finished with it yet. The problem is that anything I add to it seems to subtract more than add, so it may stay as it is.

More Tracks And Feedback

There are still a few more tracks I’d like to write for the game, like boss battle music and such. I may not have time (or talent) to create a new piece of music for each level, so I’m going to settle on a few moods that will be seen throughout the game and focus on those.

And of course, I welcome any feedback, especially from other musicians. You can be brutally honest too, just as long as it’s constructive and I learn something from it.

As it is currently prototyped, the mod system for (still tentatively titled) Sol Defender works like this: The player’s ship has a singular source of energy that powers all of its critical systems. This includes weapons, propulsion, shields, and even the item pick-up radius around the ship. As the player “levels up” his ship over the course of the game, more of this energy will be unlocked. The player can then equip mods to funnel this energy into any of the aforementioned systems in any manner he desires.

That’s the gist of the mod system, but to put it into more practical and tangible terms, I’ll go into a few examples.

Weapon Overload

Let’s talk about weapons first, since that’s easier to think about and show visually. Let’s say the player starts out with the standard slow-firing, slow-moving, short-lived pea-shot. He has leveled up and unlocked one “mod slot” in which he can equip a mod. Mods are purchased from an in-game store with in-game currency (don’t worry; no IAP mods).

If the player purchases and equips a Rapid Shot mod, his rate of fire will increase. If he equips a Split Shot mod, the shots will emit from the ship in a V-shape, effectively giving the player dual cannons. With only one mod slot, the player will have to choose which of these is more important to him at this point.

But fast forward to later in the game, when the player has the potential to have ten mod slots available. What would happen if he equipped ten Rapid Shot mods all at once? What about ten Split Shot mods? All mods in the game stack on top of each other with each mod’s effects being cumulative. Ten Rapid Shot mods would create almost a constant stream of bullets. Ten Split Shot mods creates this glorious image below:

Click to enlarge

Naturally, putting ten of any mod on your ship will put you at a disadvantage in other areas, but it leaves the control in the player’s hands, which is usually a good thing.

The video below shows one possible combination. Three Rapid Shot mods, four Split Shot mods, two Reverse Shot mods (which fires shots in the reverse direction), and one Reflect Shot mod (which causes bullets to bounce off of enemies on impact) will create something that looks a bit like this:

Shields Up (And Other Stuff)

So that’s how the mod system will work for weapons. But as I mentioned, the mods tap into the ship’s singular energy source to power a variety of different upgrades. There will also be mods that increase the strength or recharge rate of the player’s shields, mods that make the ship move faster, and even mods that multiply the experience points the player receives. Essentially, the mod system controls everything about the player’s ship, which means that the player is completely in control of how they want to progress in the game.

We’ll also be designing levels that are easier to complete when certain mods are favored over other ones. Imagine a fire planet with enemies engulfed in flames. The player might decide to stock up on Freeze Shot mods to cool the enemies down, or spend their mod allotment on shield upgrades to counteract the blistering heat of the environment.

More Work

While the implementation of the mods themselves is pretty straightforward, there’s a lot of side work that needs to be done for the whole package to come together nicely. There’s the interface for equipping and unequipping mods, the storefront for buying the mods themselves, and the ongoing process of balancing the mods over the course of the game.

I’ll write up another update on the mod system as it progresses. However, the next post is going to be about something I’m both very nervous and extremely excited about. I’ve taken it upon myself to write all of the music for the game! And I’m going to share a bit of what I have so far along with the process of how I made it. So stay tuned!

Since my last post, a lot of work has been done in a variety of areas, but I’m only going to focus on one for this post: the Shockbomber! If you’ve played Geometry Wars, then you know that sometimes you can just get overwhelmed by the massive amounts of enemies on screen, and sometimes you just need some help. The Shockbomber essentially fills that “screen killing” role, with a bit of a spherical world twist.

The Visuals

As mentioned earlier, the idea for the Shockbomber is to clear out a screen-full of enemies. Now the easiest way to do this would just be to flash the screen white and destroy all of the enemies on screen. But as the game takes place on a spherical world, I figured I could do something a little more interesting visually.

As you can see from the above video, the Shockbomber emits a shockwave spreading outwards from the player destroying anything in its path. You’ll notice that the shockwave actually wraps around the surface of the planet, creating a pretty cool visual effect. One bonus of creating the bomb like this is that it opens the door for enemies to “jump” over the shockwave! I probably won’t use this on standard enemies since the whole point of using the bomb is when you get overwhelmed. But it might be nice during a boss battle or something. Or hey, maybe I should add a jump button to the player… !

The Code

To get the ring around the planet effect, I used Unity’s Line Renderer component and set the vertex count and line width to something reasonable. The vertex positions are what give the ring its shape, so I needed a method that not only programmatically created a ring, but make the ring expand and wrap around a spherical body as it moved along its surface.

I decided to leverage what I already had with the bullets, whose movement code boils down to simply this:

sphericalMovement.Move(transform.forward);

I’ve moved all spherical movement code into its own script so I can simply added it as a component to anything that needs to move along a planet’s surface. Movement is then just a function call away.

So how do I use this to make a ring? Since bullets already move along the surface of the planet, what I needed to do was essentially fire a bullet that then emanated a ring from its position. To create the ring, I need an axis around which to create the ring:

function OnSpawn()
{
   axis = -sphericalMovement.GravityDirection;
}

GravityDirection is a property in the SphericalMovement component script, which essentially just gives the direction of gravity on the object. Taking the negative of this gives us the vector we’re looking for. OnSpawn is called after the projectile is spawned.

I now have everything I need to create the ring using a Line Renderer:

function Update()
{
   sphericalMovement.Move(transform.forward);
 
   for(var i = 0; i < kRingVertexCount; i++)
   {
      var vertexPosition = Quaternion.AxisAngle(i * (360.0f / (kRingVertexCount -1)), axis) * transform.position;
      lineRenderer.SetPosition(i, vertexPosition);
   }
}

And that’s really all there is to it. Collision detection is handled by doing Physics.RaycastAll() between each vertex in the line, get a list of hit GameObjects, and then calling damage functions on their appropriate components.

New Language

You may have noticed that this code was written in JavaScript instead of C# like my previous posts. I actually converted all of the scripts for the game to JavaScript over the weekend. While this may seem a bit insane, it was actually done for efficiency reasons.

I’m a bit OCD when it comes to object encapsulation and keeping everything properly private/protected/public, and C# simply gave me too much control over that. With JavaScript, most of that control is taken away from me, and I can get back to writing the game, not worrying about organization. Additionally, JavaScript is not nearly as verbose as C#, so I save some typing time too. There are a few things I can’t do in JavaScript, but I simply write those scripts in C# and place them in the Plugins folder (so they are compiled earlier, and thus exposed to JavaScript).

As a result, my scripts have become smaller and easier to read. Performance also hasn’t suffered since JavaScript and C# perform the same in Unity. Would I recommend this exercise to everyone that’s using C#? No. It’s purely for personal efficiency reasons, but I would recommend dipping your toe into Unity’s JavaScript from time to time as they improve the language quite a bit from version to version.

That’s all for now. Next post will be focusing on a very cool system I’ve been prototyping for this game… the Mod system! I’m pretty excited about this one.