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!

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.

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.

As I mentioned last time, enemies are next on the agenda. While writing enemy AI on a spherical world is mostly the same as it would be on a flat plane, the biggest difference is determining where the player is and then finding the shortest path to him. Since the planets in our game aren’t going to have any obstacles (at least, not yet), all enemies simply need a direct path to the player. But how can you get a straight path on a sphere?

Spherical Tracking

The key to spherical tracking is getting the player’s position and then calculating the direction on the sphere that the enemy needs to move in order to gain ground on its prey. Luckily, there’s a function in the Unity scripting API that will give us the exact results we want:

Vector3.OrthoNormalize(ref Vector3 normal, ref Vector3 tangent)

Looking at the Unity documentation, we find that the function “normalizes tangent and makes sure it is orthogonal to normal (that is, angle between them is 90 degrees)”. So what does all of that mean to us?

What we’re looking for is a directional vector that will tell us what direction on the sphere to move. To get this, we’ll be passing in our enemy’s up transform vector as the normal. This is because we want to find a direction to move in from our current orientation.

The tangent will be a vector from the attractor’s center to the target (the player). When we pass this into the OrthoNormalize method, this tangent is adjusted to be orthogonal to the normal (the up vector). What this means is that we’ll end up with a vector which points (mostly) along the surface of the sphere.

Vector3 transformUp = transform.up;
Vector3 attractorToTarget = target.transform.position - attractor.transform.position;
 
Vector3.OrthoNormalize(ref transformUp, ref attractorToTarget);

We now use this vector to move our enemy, which we learned how to do in my last post.

Vector3 movementDirection = attractorToTarget;
transform.position += movementDirection * movementVelocity * Time.deltaTime;

If you were to try this, you’d see the enemy following the player all over the planet with very little trouble. You can see it in action in the following video:

Swarming

One thing you’ll notice in the video is how the enemies sort of swarm all around the player even though they’re all using the basic code above. This is a neat trick called swarming that I learned way back in my Ratchet & Clank days (in fact, we called most enemies that used this method of movement simply “swarmers”, even though there were many varieties of them throughout the Ratchet series).

Enemies moving in a straight line just is boring from a gameplay perspective. It also looks weird as enemies tend to bunch up on top of each other or have trouble moving if you are using collision. Swarming looks to solve this problem by having each “swarmer” randomly curve around the location of the target. This gives the impression that the enemies are trying to surround the player from all sides.

To do this swarming movement, add this code just above where you actually move the enemy’s transform:

movementDirection = Quaternion.AngleAxis(swarmAngle, transform.up) * movementDirection;

Essentially, this creates a rotation of swarmAngle degrees, and then rotates the previously calculated movementDirection by this rotation.

And that’s it! No, really! As the enemy gets closer to its target, the rotation adjustment will appear to affect the movement direction less and less. But this is just how the math works out. Like I said, very simple to implement, but it adds so much to the gameplay.

To really get the “from all sides” effect, you’ll want to give each swarmer a random swarm angle. Additionally, don’t go too overboard on the swarm angle. After a certain point, the rotation will overpower the movement direction and the enemy will never reach its target. Just start out with something small like 5 or 10 degrees and experiment from there.

Next Steps

That’s all for this post. We’re going to be bulking up on enemies for a while, creating various types for the player to shoot at. We’ll then discuss setting up enemy waves so that we can have some sort of flow to the level instead of just randomly creating waves of enemies or trying to create them procedurally.

As promised, here is the first in a series of posts talking about another of our games that we currently have in development. This one doesn’t have an official name yet. We’ve been calling it “Sol Defender” for the time being, though it may not ship with that name. Here’s a very early screen with some temp art to show you what we’re shooting for:

Click to enlarge

As you can probably tell, it’s a dual-stick space shooter (stay with me) set on spherical worlds (like Super Stardust HD, Super Mario Galaxy, or Ratchet & Clank). We’ve got an interesting gameplay twist that we’re working on that uses the spherical worlds in a neat way, but I’ll save that for another post. For now, I want to give a little background on the project itself, along with some code that shows how we’re pulling off the spherical world effect.

Spherical Dreams

I first encountered the concept of “spherical worlds” in games while playing Ratchet & Clank: Going Commando way back in early 2004, and immediately fell in love with the concept. Indeed, I fell in love with the rest of the game as well, so much so that I ended up working at Insomniac Games (the developers) for over two years. Spherical worlds made an appearance in Up Your Arsenal (but not in Deadlocked, sadly).

I’ve basically been enamored with the concept of spherical worlds in games ever since. I understand the physical impossibility of a small planet-like body not being able to sustain any meaningful gravitational pull, but I’m not in the games business to make simulations!

After the release of Sheepstacker, I began developing a prototype for a tower defense-ish game set on a spherical world. Then ngmoco released Star Defense. Irritating. The gameplay was actually going to be significantly different between the two games, but I decided to move on anyways.

I then began working on a prototype I called “iArena”. It was going to be a dual-stick shooter with fully animated characters running around on spherical worlds blowing things up, with full online multiplayer. We had a successful prototype and even showed it off to a few people, including publisher Chillingo. However, the game was just too much for us to pull off at the time, and probably still is. Additionally, I’m not sure the iOS devices at the time could have handled the full game anyways.

Finally, we scaled the spherical world concept all the way back to space ships waging war around a planet. In the interest of worrying more about the technical aspects of the game rather than the artistic aspects like I had for our previous two games, I bought a big pack of low-poly ship models online and some skyboxes. Here’s a test video of what we currently have (no enemies in this particular video):

Spherical Movement

Now that you have the story thus far, I’d like to delve a bit into how we’re handling the spherical movement aspect of the game. The concept is actually fairly simple: The gravity vector for all objects in a normal game world points downwards, and all physics simulations are based on this single vector. On a spherical world, however, the gravity vector for each object is a vector from the object to the center of the spherical attractor (e.g., a planet).

For our game, we were able to simplify the simulation. As all ships and objects will be at a constant distance from the surface of the planet, we don’t need to actually apply a gravity force toward the center of the attractor for each object. We simply need to orient the object to the gravity vector and lock the object to a specific distance from the center of the attractor.

Vector3 gravityDirection = Vector3.Normalize(attractor.transform.position - transform.position);
transform.rotation = Quaternion.FromToRotation(transform.up, -gravityDirection) * transform.rotation;
 
// "kDistanceFromAttractorCenter" is a float marking the radius of the "sphere"
// that the ships move on top of.
transform.position = attractor.transform.position + (-gravityDirection * kDistanceFromAttractorCenter);

That’ll handle the positioning and orientation of any object in the game, including ships, bullets, and anything else. For movement, take your standard movement vector and multiply it by the object’s rotation:

// "movementVector" is a vector whose z will move the ship forward along
// the sphere and whose x will move the ship side-to-side.
transform.position += movementVector * transform.rotation * Time.deltaTime;

While the math here isn’t entirely accurate, it’s good enough for our purposes. And that’s pretty much all we need for the spherical effect.

In my next post about this game, I’ll go into the development of some of our enemy ships. It should illuminate just how enemies can track a player when they’re on a spherical world (it’s much easier than you might think).

In Other News

In my previous post, I mentioned that we would be putting Safety First on the backburner for a while due to some level design issues. Well, level designer (and good friend of mine) Larry Charles from GoPlay Games contacted me to take a stab at it, so it’s back on! I’ll be posting updates on that game as well as development progresses on it.