Top mistakes made by indie developers

For most businesses there is often a wealth of knowledge and constants out there to outline exactly what resources you need to achieve certain business goals. When someone choses to become an indie developer, they often don't have a detailed business model in front of them nor have done sufficient research to make great business decisions, in fact most don't change a thing in their work pattern form when they were just learning.

So what should a coder, designer, artist or all-rounder consider before going from enthusiast to full blown indie developer?

1. Plan projects based on your restraints and abilities - We often plan projects based on the desired outcomes we would like but this isn't always realistic. As an indie developer you need to consider the amount of time you have to commit to each project, your skill and how much that will slow you down or prohibit you from succeeding and the impact these restraints have on the game.
   
   A great example of this is "Flappy Bird", the developer said he didn't have a lot of time so he had to make a small, short, simple game. He also said he didn't have time to keep adding content so the way this impacted the game was he had to make it really difficult to generate longevity for the limited amount of content.
    
2. Set deadlines and milestone targets - If you were working in a big business you would have set timelines for all your projects and not meeting a timeline would have a negative effect on the business. It's easy as an indie to say "I have no real need to get it out by any specific date" or "It's done when it's done" but the impact can be big. You could be reducing your productivity by over 50% by not committing to a timeline. It also comes with other benefits such as knowing when you have to have the dialog ready to give to translators in order to get them back in time for release, plus producing localised marketing material. Reviewers will take you a lot more seriously if you can give them a date and you actually meet that date.
    
3. Plan your monetisation strategy from day one - Research business models and marketing strategies well enough to have a good plan to move forward with. Make a quick list of your products and services you can offer then start putting rough numbers next to them of how many you think you can sell based on marketing demand and do a quick calculation of your annual income. If it isn't what you expect to be making then rethink your strategy.
    
4. Plan to make money - In addition to the above, i know it is nice to give away software for free and get feedback but if you plan to have a business then eventually that business should be making money. Think of it this way, if you make enough money that you can quite your day job then you can spend more time making software and updating it and make your customers more happy. It's better for everyone if you are running a profitable business!
    
5. Be realistic - Rovio made over 50 games before they produced "Angry Birds", if you expect to get it right in the first year you will probably be very disappointed. If you expect to be rolling in cash in 2 years then (if you are good) you might be earning enough to get more equipment / software and produce better products but I wouldn't quit your day job. We are all learning, even the people who know everything about coding are learning, even the people who write programming languages cannot comprehend all the things it can be used for. Be patient. 
    
6. Be proud of your accomplishments - This tip is just from me, if you love what you do and love what you create, that love is often infectious and the community will get behind you and help support your products. You should also support your peers in the same way, some of the best developer friends I have are just people I've cold messaged saying "Hey, I tried your app you advertised on <forum name>, I really liked what you created because of <A B C D> and think you can improve on <E F G> but otherwise it was a great experience and I left you a review". People really appreciate community support and will most likely look at your apps and do the same for you.

Hope you find these comments helpful and as always leave a comment if you have anything you think I should add. I'd love to hear from you!

Create a scene helper class for iOS / Mac cross platform SpriteKit games

There was a lot of interest in my post giving a few vague suggestions for converting a sprite kit game from iOS to Mac. Since then I've refined my methods a bit and now work with a project which is targeted for both iOS and Mac to make it even easier to implement and test.

Even if you never plan to release your game on Mac OS X, the below is still useful. The iOS simulator is painful at times however running SpriteKit natively on the Mac is simply beautiful, it makes testing a lot more fun.

Getting Started

The first thing you need to do is make a project containing both a target for iOS and for Mac OS.

1. Create a new Xcode project
2. Select "Sprite Kit Game" from the iOS templates
3. Give it a name
4. Go to "File", "New", "Target..."
5. Select "Sprite Kit Game" from the Mac templates

You now have a template containing both two targets. If you are familiar with both Mac and iOS development it shouldn't take you too long to work out what is going on here. Have a look at your schemes and project settings.

I like to arrange my folders so that my Mac only code is in a "Mac" folder, the iOS only code is in a "iOS" folder and the shared game is in a "Shared" folder.

You can control which target has access to which game files via the "Target Membership" settings in the file inspector on the right.

Platform specific code

In iOS you are probably familiar with performing different code specific you wether you are running the application on an iPhone or iPad. You will run in to the same problems when coding for both Mac and iOS.

There are a lot of differences in the way you code between both platforms, even which classes you are using, so in most cases a standard IF statement won't be enough and you will need pre-processor #IF statements.

Example:

#if TARGET_OS_IPHONE
#endif

There is also a TARGET_OS_MAC but you will probably find that iOS devices respond to this as well, so it is a lot easier to just check !TARGET_OS_IPHONE.

It's a different world

Before going any further it is worth noting that you are working in two different worlds governed by two different HIG documents. What you know in iOS may not apply to Mac development. 

You are also working with a touch screen device without keyboard and a mouse and keyboard operated device. This is a simple fact but it will show in your game if you don't pay attention to it. I had an app rejected at review once for the reason my start screen said "Tap anywhere to begin" instead of "Click", a rather embarrassing mistake but one I make sure to prepare better for now.

Ok, enough of the lecture, you all want the helper class right?

A scene helper class to get you started

This is a very simple class but I want you guys to take it and add your own code to it. If your game uses a onscreen DPAD on iOS then it makes no sense do the same on Mac, you would need to monitor key presses instead.

This class helps for all other cases, it allows you to single methods for handling both screen clicks and screen taps. Great for games where screen presses translate easily in to screen clicks.

Create a class called SKMScene that inherits from SKScene.

Put the below in SKMScene.h:

“// Created by Neil North on 6/02/2014.
// Copyright (c) 2014 Neil North. All rights reserved.
//

#import

@interface SKMScene : SKScene


//Screen Interactions
-(void)screenInteractionStartedAtLocation:(CGPoint)location;
-(void)screenInteractionEndedAtLocation:(CGPoint)location;

@end”

And the below in the SKMScene.m file:

“// Created by Neil North on 6/02/2014.
// Copyright (c) 2014 Neil North. All rights reserved.
//

#import “SKMScene.h”

@implementation SKMScene

-(id)initWithSize:(CGSize)size {
if (self = [super initWithSize:size]) {
/* Setup your scene here */
/* Overridden by Subclass */

}
return self;
}

#if TARGET_OS_IPHONE
-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
UITouch *touch = [touches anyObject];
CGPoint positionInScene = [touch locationInNode:self];
[self screenInteractionStartedAtLocation:positionInScene];
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
UITouch *touch = [touches anyObject];
CGPoint positionInScene = [touch locationInNode:self];
[self screenInteractionEndedAtLocation:positionInScene];
}

- (void)touchesCancelled:(NSSet *)touches
withEvent:(UIEvent *)event
{
UITouch *touch = [touches anyObject];
CGPoint positionInScene = [touch locationInNode:self];
[self screenInteractionEndedAtLocation:positionInScene];
}
#else
-(void)mouseDown:(NSEvent *)theEvent {
CGPoint positionInScene = [theEvent locationInNode:self];
[self screenInteractionStartedAtLocation:positionInScene];
}

- (void)mouseUp:(NSEvent *)theEvent
{
CGPoint positionInScene = [theEvent locationInNode:self];
[self screenInteractionEndedAtLocation:positionInScene];
}

- (void)mouseExited:(NSEvent *)theEvent
{
CGPoint positionInScene = [theEvent locationInNode:self];
[self screenInteractionEndedAtLocation:positionInScene];
}
#endif

-(void)screenInteractionStartedAtLocation:(CGPoint)location {
/* Overridden by Subclass */
}

-(void)screenInteractionEndedAtLocation:(CGPoint)location {
/* Overridden by Subclass */
}

@end”

That's it, now all you have to do is make sure all your scenes inherit from SKMScene instead of SKScene and implement the two screenIntereaction methods.

There's a lot more to this process and I'm only just starting to learn to make cross platform games myself but I hope the above tips have helped you on your journey. Give it a go and see what you think.

You can also download a sample project on GitHub.

What can we learn from "Flappy Bird"?

My first encounter with Flappy Bird was checking the App Store's top free games list one morning then promptly wonder what on earth was going on. I could not understand how this game was top of the charts and why his other mini-games and rival games with "Flappy" in the title were not far behind.

The following controversies were also incredibly baffling, everyone loved this challenging yet very simple game, I could not work out why and for the most part, neither could anyone else. The creator himself also seemed very shocked by his instant fame and fortune, I really have to give kudos to the guy for how he has taken it all. He really is a nice bloke who quite simply wasn't in it for the money, just making fun games.

So what can we learn from the whole Saga?

• The nature of the App Store can be unpredictable, the precise events which have lead to the explosion of this game are untraceable. It went viral so quickly and so strongly I don't think anyone could have predicted it.
• Time != Sales, this point scares me. Flappy Bird was created in just a couple of days (hell, I made a version of Fish Slapped which emulated Flappy Bird and the total conversion took less than 4 hours). Sometimes these mini-game experiments can yield good results, even if the game is quite difficult.
• Be prepared for success. Someone has to get lucky and have their product go viral some times. Be prepared for potential success by keeping your business in order and being in control of your social media.
• Advertising is a great business model for mini-games. The developer was making 50k a day in google ads, that is incredible!

Most importantly, there really isn't anything we can learn from this experience. Just need to take it for what it is and keep working on making great games wether they be large scale or as small as flappy bird.

Peer review and beta testing is essential to all software businesses

I'm an indie developer in every aspect of the term 'indie', I'm not against working in a team, I love it in my day job but unfortunately there aren't many software developers in this town and even less available to sit down with me and let me bounce ideas off of them.

Sometimes being clever isn't enough, software is a marketplace where perspectives matter and getting as many perspectives on your product before dropping your MVP (minimum viable product) on the public is what can make or break your product releases.

So what can you do if you are like me and don't have people who can sit down and talk about your products readily available?

Beta testing!

It's not uncommon to perform beta tests within your small development group and yourself following good TDR (Test Driven Development) but there is so much more to a good product release than finding bugs, you need to find issues with your UX (User Experience).

How do I do a closed / public beta?

1. Pick a distribution platform - iOS has limited ways to you can beta test but if you have a way to collect UDIDs from potential participants then adhoc distributions are not that difficult and don't put too much stress on the participant. You can give them this website to make instructions easier. Look at other options as well, Test Flight has received good praise.
2. Get analytics - You can't rely on your beta testers to give you feedback, especially if you have never met them. Use a service like parse to feed back useful data such as how many levels were completed in your game, how many retries, how many error screens were presented, etc. 
3. Add a dummy payment system - In-app purchases need to be tested too, when designing your store kit classes be sure to implement a way to set a boolean switch for test mode where it can allow purchases separate to the actual store kit. Use compiler #if statements to make sure the code can't be manipulated in release.
4. Let the participants give you feedback - What I like to do is set up a form in google documents stored on my google drive. You can make fairly detailed forms, make them public and then see all the background data collected in a nice neat spreadsheet without spending a cent. Then pick a logical point in your game (such as at the end of the final level or after 20 attempts to then ask them if they would like to provide feedback and send them to the form. This is important as you are narrowing down the feedback to people who actually played the game to a specific point.
5. Ask for more feedback - In addition to the above, have a separate form for bad experiences. Measure the number of memory warnings, error screens, crashes, levels failed and then ask them if they would like to submit a bug / issue report. You will see this data in your analytics but its important to get the direct opinion of the user as well.

Hope you find this useful and is enough to get you started. Don't fall in to the "I know everything" trap.

It's going to be a busy month

I started this year with the goal of somehow juggling my main job, my contract work, my tutorials, training and of course making 12 games in 12 months. So far I think it's gone fairly well and that I can be on target to keep performing at this level but as with life, things come up which can severely offset your time.

I'm going to moving house soon, not far just from a rental to a house I am jumping through the hoops to buy on the other side of town. This is a very exciting process but also a very time consuming one and it's only going to get worse until I'm completely moved.

So... what's going to happen over the next month and a half with the business until I can get back to going full throttle? My main job and contract work will be unaffected but I may just have to either not have a March game, make a small March game or bend the rules a bit and just make additional content for the 2 games which have already been finished.

I'm still very eager to finish 12 games in 12 months and so far it has been an amazing learning opportunity. I don't want it to slow down or end and would recommend the experience to anyone. My apologies if content comes out a little slower over the next few weeks.

Converted a SpriteKit game from iOS to OS X

My February game for my one game a month challenge is now complete and in apple's hands for approval. In designing this game I always intended it to be available for both iOS and OS X even though I knew nothing about OS X development. I expected the conversion to be a complete disaster but everything actually went better than expected...

My preparations were actually quite simple:

• Minimised usage of UIKit until it was nearly completely unused.
• Made sure to use % of self.size coordinates instead of hard coded coordinates where possible.
• Made sure that any variables or defined code that relied on device type or screen size to be stored in my constants.h file so it could be easily modified.

As you can see, my preparations were rather minimal. We are talking about a very small time investment in order to get my game on another platform.

The conversion itself was rather painless:

• I created a new Mac OS X Sprite Kit project and dumped my game in to it.
• Setup the appDelegate to point to my first game scene.
• Went through each scene replacing Touch events with Mouse click events.
• Fixed links to plists, the way I referenced them in iOS didn't work for Mac OS, I believe using the code I changed it to in iOS as well will resolve this issue in the future.
• Fixed some game center differences.
• New Icons, profiles, settings, etc

The process took less than 4 hours and in the future I expect it to be a lot quicker now that I have learnt a few things. I plan to make all future SpriteKit games completely cross platform (assuming Mac OS X sales will be reasonable).

I know this post was vague, drop me a line if you want a tutorial.