Last week I attended the Digital Distribution Summit here in Melbourne with fellow Escape Factory collaborator John. Even though the name makes you think it would be terribly boring, (it probably should have been called the Digital Games Distribution Summit, bit I digress) it was actually very good.

You can watch all of the speakers on the DDSummit site, which you should go and do now, and not bother reading this silly post.

If you are still reading, I will give you my belated thoughts on the content provided in the summit. If you did not attend or have no idea what I am talking about then here is the very brief overview:

The DDSummit was geared towards indie level game developers who are looking to take advantage of the increasingly popular and available digital distribution methods (like XBLA, PSX, WiiWare, AppStore etc..) The talks ranged all over but ultimately were there to help the little guy (thats us!) succeed in this new marketplace. There is a smaller barrier to entry to the indie game market now than any other time in history.

So that is the overview, what are some of the specifics?

Since I am an iPhone developer (so far) I mostly tried to apply everything that was being said to my situation (which is: zero budget development for iPhone).

The biggest thing that I took away from this event was that marketing is the single most important thing you can be doing right now. (cynically, I might even say that it is more important than having a good game) This is of course not really news to me, but having it laid out so many times and so clearly, it really hit home the fact that we are not marketing our stuff enough. This is a common problem with the indies, we are all very good at what we do (which might be programming, artwork, game design, sound, etc..) but we are not really very good at marketing (otherwise we would be professional marketing types right?)

The presenters made many good points re: marketing. If you make the best game ever and nobody knows about it, then nobody will buy it.

That begs the question: How do we, as indie developers who suck at marketing.... how do we get the word out?

This is a summary, in no particular order of the hints, suggestions and tips to better marketing. Some of these are directly from the talks and others are things that I synthesized from my notes.

• Start your marketing on day one. Do not build a protorype, do not write a design document, do not brainstorm game mechanics. The very first thing you need to do is start the marketing process. Write a blog post, tweet, whatever. Then start the actual development. Well, ok that might be a bit hyperbolic, but marketing needs to be in your plan from the very start.
• Marketing should be part of your dev process. Just like everything else you are doing to build your game. Add marketing tasks into the flow. Blog about what you are doing, tweet your advances and your challenges, solicit gamer feedback from your early design ideas
• Define your target audience. Figure out who is going to care about this game you are making. Define a narrow group of people (dont say: this game is for everyone! because it isn't.) focus on a realistic group and cater your marketing to that group.
• Define your brand. As indies this tends to get lost. Also often the brand become synonymous with the first successful game you develop. As indies, our brand is our individual style and story. Half of selling your games and ideas as an indie is having a compelling story. By story I mean who you are and what it is you do.
• Twitter. I think I heard the word twitter or tweet about 900 times. Twitter is the current social networking fad, and you should be using it. Twitter is a multiplier for word of mouth. Similarly, you should be abusing your facebook friends and using all those digital contacts to help push your game.
• Blog. You should have some sort of web site/blog for your game or development studio. (like this one! hello!) Try to keep your blog fairly up to date with current topical posts that people will hopefully find interesting. This will help keep your name and game in the tops of people's minds.
• Make good gameplay videos. Sometime after day 1, when you already started your marketing and everyone is anticipating your game release, you will need to make a good gameplay video. Again, tailor this to your target audience. Be sure to show some actual gameplay though. There is nothing more annoying than a game trailer that has no actual game footage.
• Enter every festival and contest you can. Do you qualify for the entry requirements? then enter it. Even if you don't get in, or don't win you will generally get some exposure and some good game player feedback.
• Engage the community Go and be active in the forums and the blogs that are specific to your target audience. Be a part of the gamer community. Give back via your blog. Post how-tos and code snippets.

That is a pretty good list to start.

Trust me when I tell you that I sympathize with all the indies out there who are already busy just trying to build their games, let alone do all that other stuff. It took me a week just to write this post because I was too busy with other projects. However, in order to be a successful game developer you need to also be a successful marketer.

Cheers!
-B

There is a new player in the iPhone-support website game: PlayHaven. They are similar to Openfeint and Agon in that they provide some 3rd-party support for your game. Unlike OF and Agon, Playhaven does not provide leaderboards and that sort of thing, instead they are trying to build a gaming community around guides, hints, and forums.

In any case, back in the early days of the iPhone game development (like half a year ago) there were far fewer choices for adding leaderboard/achievement support to your app via 3rd party. So after looking at the early OF and others and not being very happy with what they offered (at the time) we decided to go ahead and build our own leaderboards.

So, why playhaven then?

Well, ultimately it comes down to them emailing me and asking me to try it out. We dont currently have any of the features they offer, so the fit seemed good. Also, one nice thing about playhaven is that they are basing their entire 'api' (if you could call it that) around the UIWebView. In other words there is no actual SDK to add to your code, you just whip open an in-app web view and there is the community.

For a programmer this is very nice. I really really do not like to add 3rd party code to my apps unless i really really need to (less code == less bugs). Especially in cases like OF and Agon, who (much to their credit) are releasing new patches fairly quickly. This is great from a feature standpoint, but bad from a trying-to-keep-my-code-up-to-date standpoint.

Once you get two or three games going, just keeping up with the iPhone SDK changes is hard enough (not to mention we need to be generating new content and add polish to our apps every couple of weeks to keep sales up) adding yet another chunk of software that I have to keep up to date is yet another thing I have little time for. From the start with our own leaderboards we tried to offload as much of the process as possible to the webservers so that we could easily and quickly update and change things without having to change the game code, Playhaven fits well with this line of thinking.

With Playhaven, I just add a webview and a URL. And we are going to put a redirect script on our site and call that URL instead, so if the playhaven URL api gets changed or updated, then we just have to update our redirector and all of our games will continue to work.

Ok, now for the bad news: opening up a UIWebview from within Unity is a non-trivial task. You cant actually do it from the unity engine. (well, not yet in any case, those Unity guys are adding new stuff constantly) Well, OK that is not entirely true. If you have Unity iPhone Advanced then you can add a plugin that calls out to the ObjC/cocoa stuff and does all your web ui view stuff from there. but you still need to write some ObjC/Cocoa.

So how do we do this? How do we get the Playhaven page to open overtop of the unity view?

The simplest way is to use the tried and true 'user prefs' hack. Since the advent of Unity iPhone Support, there have been a few enterprising developers who pioneered the technique of using the User Prefs as a communications link between Unity and Cocoa.

(There have been quite a few people who discussed this technique in the unity forums and I dont want to make light of their contributions, but I want to make a special shout out to blipRob aka stinkbot, who produces the fantastic Unity iPhone Enhancement pack, which I recommend as it allows you to do so many more things than just open a UIWebView, and makes integrating the playhaven stuff as simple as adding a dozen or so lines to the enhancement pack code. In fact he probably already has stuff in there to do it, I have an early version of the EP that I have hacked into my own thing so I havent updated recently. But really, buy a copy of the EP and this becomes much much simpler.)

OK, so how does this work?

From unity we set a value to the PlayerPrefs, like so:

   PlayerPrefs.SetString("bbcommand", "BBWebUI|"+fullUrl);

Note: you will need to have some well-formed URL in the fullUrl variable.

The PlayerPrefs are actually stored in the NSUserDefaults dictionary, so we can get that out from the Cocoa side like so:

 
 
NSString* commandString = [[NSUserDefaults standardUserDefaults] objectForKey:@"bbcommand"];
 

So that is how we can get information back and forth between the Unity world and the Cocoa world. But how do we use this to our benefit? We need to be looking for that command to show up in the NSUserDefaults dictionary and then act on it when we see it.

For this to happen we need to have some extra code running besides the standard Unity stuff. There are a few ways of handling this but the lease destructive and easiest to add into your game is to add a category extension to the AppController object in the unity code.

For our purposes I am going to presume that you are updated to the 1.5 unity iPhone and if you havent, then why not? go do that now.

Here it is: the absolute simplest way to insert your own code into the unity code:

 
#import "AppController.h"
#import "BBUnityHandler.h"
 
void UnityInitApplication(const char* appPathName);
void UnitySetAudioSessionActive(bool active);
void UnityPause(bool pause);
 
@interface AppController (BBUnity)
// our two 'public' methods
- (void)pauseUnity;
- (void)resumeUnity;
 
@end
 
@implementation AppController (BBUnity)
 
// override the app did finish launch method and add our single line of code
- (void) applicationDidFinishLaunching:(UIApplication*)application
{
	[self startUnity:application];
	// start our custom code here
	[[BBUnityHandler sharedHandler] startHandler:self];
}
 
// this will resume the unity engine after we have paused it
-(void)resumeUnity
{
	[[UIApplication sharedApplication] setStatusBarOrientation:
                 UIInterfaceOrientationLandscapeRight];
 
	UnitySetAudioSessionActive(true);
	UnityPause(false);
}
 
// this will pause the unity engine
- (void)pauseUnity
{
	UnitySetAudioSessionActive(false);
	UnityPause(true);
}
 
@end
 

OK, what is this doing? Basically this is putting a hook into the unity startup process that also starts up our custom code. In this case it calls my BBUnityHandler object and starts it up with a reference to the app controller.

This method is a bit different from the other unity AppController addons I have seen. I like this way because it is clean and simple. It keeps my code nicely separated from the AppController code.

So lets have a look and see what the BBUnityHandler is doing:

Lets us look at the first two methods we have seen: the class method: sharedHandler and the instance method startHandler:

 
// Singleton accessor.  this is how you should ALWAYS get a reference
// to the sound controller.  Never init your own.
+(BBUnityHandler*)sharedHandler
{
  static BBUnityHandler *sharedHandler;
  @synchronized(self)
  {
    if (!sharedHandler)
      sharedHandler = [[BBUnityHandler alloc] init];
 
    return sharedHandler;
  }
	return sharedHandler;
}
 
- (void)startHandler:(AppController*)aController;
{
	self.unityController = aController;
	[[NSUserDefaults standardUserDefaults] addObserver:self
             forKeyPath:@"bbcommand"
             options:NSKeyValueObservingOptionNew context:nil];
}
 

First up we have a simple singleton accessor method, this creates a new object if there is not one and stashes the reference in a static variable so that you always get the same one every time you call it.

Second we have our own start method. This simple retains a reference to the AppController so that we can make calls against it later. Then we hook up our key value observer to keep an eye on the NSUserDefaults dictionary so we will get a notification if our command ever changes.

In order for the KVO to work we need to add our callback method:

 
- (void)observeValueForKeyPath:(NSString *)keyPath
               ofObject:(id)object
               change:(NSDictionary *)change
               context:(void *)context
{
	NSString* commandString = [[NSUserDefaults standardUserDefaults]
                       objectForKey:@"bbcommand"];
 
	if ((commandString == nil) || ([commandString lenght] < 1))return;
 
	[self performSelectorOnMainThread:@selector(handleCommand:)
                      withObject:commandString waitUntilDone:NO];
}
 

This is pretty simple: grab the command string from the dictionary, check to make sure it is legit and dispatch it. The last line is important, we jump off this thread and jump to the main thread. Mostly we want to do this because we are going to be doing UI stuff and that is best handled on the main thread. Why do we need to do this? The KVO stuff is handled straight away on the same thread that the change was made, and I have no insight into the Unity black box, so I dont really know what thread I am on when this gets called so I want to get off of it and onto a known thread as quickly as I can.

OK, now we move to the handleCommand method which is being called on the main thread.

 
-(void)handleCommand:(NSString*)commandString
{
	NSArray *args = [commandString componentsSeparatedByString: @"|"];
 
	if (([[args objectAtIndex:0] isEqualToString:@"BBWebUI"]) && ([args count] > 1)) [self openWebUI:args];
 
	[[NSUserDefaults standardUserDefaults] setObject:@"" forKey:@"bbcommand"];
}
 

Pretty simple, just parse the args into a nice array, check to make sure our command is roughly formatted right (ie there is at least one argument) and pass it on to the web ui method. Finally we reset our command back to a blank command. (note: this will actually cause our KVO method to get called again, but it will shunt out since there is no command there)

 
-(void)openWebUI:(NSArray*)args
{
	[unityController pauseUnity];
 
	// alloc a new window for my web view
	overlayWindow = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
 
	// make a toolbar and add a button right in the center
	UIToolbar * toolbar = [[UIToolbar alloc] initWithFrame:CGRectMake(0, 431.0, 320, 49.0)];
 
	UIBarButtonItem * okButton = [[UIBarButtonItem alloc]
                   initWithTitle:@"Back to Snowferno"
                   style:UIBarButtonItemStyleBordered
                   target:self action:@selector(closeWebUI)];
	UIBarButtonItem * flexiSpaceItem = [[UIBarButtonItem alloc]
                   initWithBarButtonSystemItem:UIBarButtonSystemItemFlexibleSpace
                   target:nil action:nil];
	UIBarButtonItem * flexiSpaceItem2 = [[UIBarButtonItem alloc]
                   initWithBarButtonSystemItem:UIBarButtonSystemItemFlexibleSpace
                   target:nil action:nil];
 
	toolbar.items	= [NSArray arrayWithObjects:flexiSpaceItem,okButton,flexiSpaceItem2,nil];
	[okButton release];
	[flexiSpaceItem release];
	[flexiSpaceItem2 release];	
 
	// add the toolbar to the new window and release it
	[overlayWindow addSubview:toolbar];
	[toolbar release];
 
	// make my webview, assign self as the delegate
	UIWebView * webView = [[UIWebView alloc] initWithFrame:CGRectMake(0, 0, 320, 431.0)];
	webView.scalesPageToFit = YES;
	webView.delegate = self;
	[overlayWindow addSubview:webView];
 
	// add a spinner so the user is not waiting looking at nothing
	spinner = [[UIActivityIndicatorView alloc]
              initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleWhiteLarge];
	spinner.center = CGPointMake(160.0, 240.0);
	spinner.autoresizingMask = UIViewAutoresizingFlexibleRightMargin |
             UIViewAutoresizingFlexibleLeftMargin |UIViewAutoresizingFlexibleTopMargin |
             UIViewAutoresizingFlexibleBottomMargin;
	[spinner startAnimating];
	[overlayWindow addSubview:spinner];
 
	// show the window
	[overlayWindow makeKeyAndVisible];
 
	//Create a URL object.
	NSURL *url = [NSURL URLWithString:[args objectAtIndex:1]];
 
	//URL Requst Object
	NSURLRequest *requestObj = [NSURLRequest requestWithURL:url];
 
	//Load the request in the UIWebView.
	[webView loadRequest:requestObj];
 
	[webView release]; // the overlay window owns it now
}

Finally, the meat of our code: the actual web ui view. The first thing we do in the longish method is pause unity. Here is where our reference to the app controller is required. This causes the unity engine to basically just freeze. Now we can safely overlay our views without worrying what is going on in the engine.

In order to do this with minimal effect on the Unity code we are actually going to make a new window (which is fairly rare on the iPhone, you really should not need to do this very often)

OK, so we make a new window, then we make a toolbar with a back button and add that to our window. Finally we add on our UIWebView and kick off the initial request. (which is the URL that we get from the args array).

Since the web view will take some time to load the content, we also add a spinny indicator so that the user knows something is happening. Otherwise they have to sit and stare at a blank view for a few seconds while the URL loads.

OK, great! nearly done!

The first thing we need to do now is remove the spinner after the loading is done. Handily we told the webview that we would be the delegate, so we get told when it has finished loading.

- (void)webViewDidFinishLoad:(UIWebView *)webView;
{
	[spinner removeFromSuperview];
	[spinner release];
	spinner = nil;
}

Ok, that was easy. Now the user is happily surfing the web inside our game. We added a nice 'Back to the game' button so that after they are done reading tips on how to slay that big bad dragon or solve that hard puzzle or whatever, they can get back into Unity.

 
- (void)closeWebUI;
{
	[overlayWindow release];
	overlayWindow = nil;
	[unityController resumeUnity];
}

That is it. We release the window, which makes it go away and clean up all of it's own memory, then we resume the unity engine.

Here it all is in one big file:
AppController_BBUnity.mm.zip

This is all going to be in the Snowferno 1.1 release which we are submitting in the next few days, so if you want to see this in action, then pick up a copy of Snowferno! :-) (or if you find it useful, then help up out by picking up a copy and tell your friends :-)

UPDATE: we had a bit of a burp with our wordpress so you could not download the file. That should be all fixed now! Thanks Brent!

Cheers!
-ben

Well, Brent and I spend the better part of the first day of release filling in webforms and following complicated email submission rules for probably two dozen sites. A few have already given us a mention, so we wanted to say Thanks!

In no particular order:

MacObserver:
http://www.macobserver.com/tmo/article/snowferno_gives_a_snowball_a_chance_in_hell

MacNN:
http://www.macnn.com/iphoneappupdates/9/

AppShopper:
http://appshopper.com/games/snowferno

And as i mentioned before:
No dpad:
http://nodpad.com/2009/09/01/snowferno-rolls-into-app-store/

The noDpad one is a followup for the exclusive that they did for us earlier, so it is sorta a review. The others are pretty much just blurbs, mostly taken from the media kit page or the app store page. But we appreciate them no matter what!

Hopefully we will get a few more reviews in the coming weeks, and hopefully they will be positive!

Cheers!
-B

Daniel, at no dpad wasted no time with a nice release post:

Snowferno Rolls into App Store

Nice turn of phrase, I am totally stealing that.

Cheers!
-B

Had a lovely surprise this morning while waiting for app store approval, we got our very first review from nodpad.com.

http://nodpad.com/2009/07/24/exclusive-hands-on-with-snowferno/

One thing I do really like about it is that he goes fairly in depth about the control system and how the game actually works. I hadn't really thought about it until I read it there, but while we have a few places that show and kinda say how the game controls function, we have never really spelled it out like Daniel at nodpad. So from now on I will just direct people there :-)

Not only that, but he enjoyed the game, so that is great!

Go and check it out! it is good! yay!

-B

So, there was a big ole' critical issue with the throttle widget. it works very nice now, but it was getting dealloced after you fallout (or meltout) and the touch manager was still trying to access it.. bad. crash.

fixed now!

You should go and get it here: http://www.snowferno.com/current-beta/.

ChangeLog:

• fixed the big critical crasher
• made some cosmetic changes to the score board settings
• fixed an issue on The Wall where you could hit a switch more than once

Hello all you beta testers! Beta 4 (Release Candidate 1) is ready!

You should go and get it here: http://www.snowferno.com/current-beta/.

ChangeLog:

• Added final scene, for those of you who have finished the last level, you can go right there from the world map, the rest of you slackers have to finish before you can see the final scene. Final scene includes it's own custom music track and a groovy 'cutscene' kinda thing, as well as your final game time (all the best level completions added up) and your final game ranking.
• added all sound fx
• Changed the way the throttle works again, so it should not get stuck anymore (again)
• fixed the fire wheel, now you will always hit the platform when shot from the cannon
• added external linkage to the score board settings panel, now you can get to your user account page (which will eventually allow you to change your screen name)
• added external linkage to the score board settings panel, now you can get to your leaderboard page, which shows all your stats
• fixed some issues with the moving boxes, now they stay put better in level 12 when on the moving platform.
• yet more performance tweaks, the internal builds were quite smooth on 3g phones.
• changed the way the ball interacts with the walls to make it less jarring when you roll along a wall (it is still somewhat jarring, but now less so)
• scads of changes and updates to the website. the summary: leaderboards are all working and have lots of cool stats. still to come: account changes (ie change yer screen name)

Cheers! and as always let me know if you have any comments/problems/anything.

-ben

Hello all you beta testers! Beta 3 is ready!

B096 is uploading as I write this. Lots of changes since B094: You should go and get it here: http://www.snowferno.com/current-beta/.

This will most likely be the final beta release. If there are no show stoppers then we will most likely be able to add the final few sound FX and the end of game cutscene and submit late in the week!

ChangeLog:

• Compressed most all textures just a little bit more.
• turned the FPS counter off
• Changed the way the throttle works, so it should not get stuck anymore
• turned down the physics calculation rate (for performance reasons), this affected the way the accelerometer works slightly. I tried to bring it back in line with how it should feel.
• fix the post scores setting, now you can opt-out of posting your scores on the leaderboards (which will be turned on this week - watch this space.
• fixed the Firewheel level so that there is no longer a crash if you get into the flamethrower, and now the wheel is spinning again.
• changed the way the buttons work in level 12 linking rings. now it doesn't suck.
• fixed level 10 clock, now the exit passage is slightly wider and the middle ring should not get out of sync.
• fixed level 18 Infernal Machine, now the 'gears' should always spin fully 90 degrees instead of sometimes getting stuck on the last frame of animation
• fixed the popups so that they are visible again

Also, for those of you who managed to finish level 2 in under 10 seconds, how the hell did you manage that?

Cheers!
-Ben

Had a great week of beta, found a few bugs and lots of good suggestions, keep them coming!

Login now to download the latest build of Snowferno (b0.9.4). We emailed you the login info -- let me know if you need it re-sent (or if you want to join the beta program).

b0.9.4 Changelog

• At the end of a level, the scores formatting has been fixed, ranking has been added, screen name has been added, as well as the name of the level. (so now you guys can tell us which leve it was that you hate, instead of ' that one level, with the spinny thing in the middle')
• Added the level name to the main interface, upper left corner. just plain text for now.
• Adjusted the way the snowball reacts with the terrain to make the walls less 'jittery'. and to make it harder to accidentally roll over raised edges.
• Adjusted the terrain model for level 05 so that you cant get stuck on the first block.
• Changed the throttle control and the clock to match the rest of the interface buttons.
• Modified the terrain model for level 10 Clock so that the narrow passage to the exit platform is not nearly as narrow.
• changed the way that fires and snowpiles work so that they are more performance friendly (ie only doing stuff when you are rolling on them)

b0.9.4 Known Issues

• On level 10 Clock, if you spin the middle ring enough times, it will get out of sync with the other platforms. This will be fixed in the next release. Also, the model modification for level 10 above should help to mitigate this.
• there appears to be an issue with the throttle getting 'stuck'. We think we have fixed this but could never replicate it consistently, so if you run into this let us know
• On level 12 Linking Rings, there is a bug in the button scripts. If you (or a box) triggers a switch over and over again before the moving platform comes to a stop, then the platform gets out of sync and can go all sorts of odd places. I have tracked the cause down and there will be a fix in the sunday release.

b0.9.2 Known Issues

• The number readout in the upper left is a Frames Per Second meter to gauge performance. This is for beta only.
• Settings > Control > "Post Score" toggle does not connect to the online API yet.
• Online account management stuff isn't ready yet. (Settings > Control > "My Leaderboard Settings" takes you to a placeholder page.)
• There are some text-overlay "story" elements and SFX still missing, but nothing that affects gameplay.
• If you make it all the way to the end, it will be obvious that something fancier will replace the final screen.

Please post your thoughts in the comments section below, or email me at support@benbritten.com.

So, I have been adding all the little fiddly bits today, and fixing the little bugs that Brent and Mike have found in the pre-beta release. Mostly stuff like: I forgot to set the audio clip for an object in level 5 so it crashes out, things like that.

Also I have taken out all the old scratch buttons and put in some super-simple big target squares.

The old scratch buttons were sorta 2.5d arcade style with scratchy, gothy textures on them.. and they looked kinda cool, but didnt really fit with the emerging look and feel of the GUI. (you can actually see them on the 'Not That Way' trailer video, when Snowy rolls off the edge of the cliff) The new ones are not very special, just big boxes, nice and easy to hit with my big fat fingers. and while they dont really add any ambience to the GUI they dont really take much away from it either... they are just there..

This is why we need to make scads of money so that I can hire on the very talented illustrators that I know to do these things for me.

Anyway... let's talk FPS for a moment. On the most recent build, I am seeing frame rates around 22 - 28 on my iPhone 3G, and Brent is reporting similar results on his 3G. This is right about what I expected and not so bad that I feel like I need to hunker down for a few days just optimizing (tho I am sure I will do some of that).. In any case it is quite smooth and playable on the 3G.

I dont yet have a 3Gs to play with, but I did load it onto my Second Gen Touch and boy-howdy! rates in the low to upper 30s on the Touch. I am going to be using the touch to crush all the beta testers in the leaderboards that is for sure..

Astute readers will notice the oddly places '100.00' up in the upper left corner of the screenshot. This is the FPS. Visible only for the beta test. And before you freak out, that is the FPS in the Unity editor, not the phone.

Cheers!
-B