Tuesday, August 2, 2016

Pandora's Books Coming Soon!

Lately all my time has been devoted to Game Development so I have not been posting much.  What have I been up to?

Since January 2016 with Space-Bot Alpha behind me, I expanded the studio and bet the farm on a new game Pandora's Books.

It's a game about Pandora who opens the wrong book and releases the chaos wizard & his minions onto the worlds of classic stories.  As a player your job is to unscrambled the mixed up words, to defeat the wizard & his minions, and save the cities of these timeless tales.  The game ships with War of the Worlds unlocked and as you play you collect clues that can be used to help when you're stuck on a word, and also saved up to unlock books.

The team has been amazing, and last week we pushed the game to Apple's App Store editorial team in the hope of getting a feature!  This is the "big time" for me, and I guess even if we don't get the much-vaunted Apple feature we still have a great game which will go live on August 18th.

If you want to follow my journey as an Indie Game Developer why not subscribe to follow this blog and keep up with future posts?

Thanks for reading!

Sprite Kit for the Win

My game development work these days is all done in Apple's Sprite Kit, which is a dedicated 2D game development technology.  To my knowledge Apple is the only device vendor making game APIs like Sprite Kit.  Google has some back-end stuff but nothing to put sprites on the screen.

Sprite Kit is a "no engine solution".

The correct term for it is framework: Sprite Kit is not an "Engine".  You hear that as a common term around game dev circles: "what engine are you using?".  Sprite Kit is a "no engine solution".  In this article I lay out my reasons for choosing Sprite Kit for my professional studio's development, and what this distinction means in practice.

Editing a Sprite Kit Scene in Xcode

In game dev you try to separate code from assets, functionality from data, as you do in regular programming or good software engineering.  A key difference is the degree of separation and what role your game plays on the device when you use a framework rather than an engine.

  • With a framework you are actually writing a computer program,  in essence, and that program is an executable, which runs on the platform making calls via a framework API to load assets and data.  There may be tools to create data like levels and maps into a form that the framework API calls can consume.  But those tools only exist as part of a set of programmer's productivity helpers, and typically its possible to edit that data using other tools if needed.  
  • Essentially in the engine case, your game is NOT a program, its all data.  The engine is in charge, and you provide your game as a package of data for the engine to operate on.  The engine has a combined editor and previewer that encapsulates the entirety of your creative process, capturing your scripts, assets and other inputs into a package and giving an almost-real-time view of the game.

What is it that we get from game engine makers, like GameMaker, Adventure Game Studio, Unity3D, Unreal Engine or CryEngine?  They ship pre-packaged functionality, such as "place that quad over there with this texture on it", and "apply that animation to this object node".  You provide a package of data, which includes visual assets such as images & models, and logic assets such as scripts, that the game engine loads and at various times to render and evaluate.

Framework eg Sprite Kit vs an Engine
What is the real-world implication of this?  Basically you can only do (easily) what the engine provides for.  If you write a script or make an object that invokes cool engine functionality you can move mountains and make magic.  But when you try to just make a button behave like you want, and the engine doesn't support that it becomes ridiculously painful.  Mountains of code or even an external plugin has to be used.

  • With an engine
    • some incredible things are easy, and 
    • easy things are (often) strangely hard. 
    • publishing/shipping is way harder than it should be 
  • With a framework API 
    • everything is possible, and 
    • easy things are (often) a bit hard
    • shipping is what they do best
These attributes mean that engines are great for prototyping (as long as your prototype is a game that the engine can easily make) but things get hard quickly when you try to exert your will and design intent over the game; and also when you start to get closer to publishing and want to integrate platform API's for things like In-App Purchases.

Having said that engines like Unity are incredibly powerful and talented 3D programmers have produced a lot of common 3D rendering functionality into a tightly honed and well-documented beast which you can call on to get your game up and running quickly.  Of course you don't get this for free: a professional studio has to pay $1500 USD for each of Unity Pro, Unity iPhone and Unity Android - so a total bill of $4500 USD (or around $6000 AUD) per seat.  And then you pay that again when Unity goes up a major version number.  Its worth every penny - if you need that 3D functionality.

The essential trade-off is that particular engines are well-suited to producing a particular type of game.  In fact most engines already have a type of game in mind.  Unity is ideally suited to games where a 3D avatar in either 1st person or 3rd person is running around a world, followed by a camera.

You can of course fix that camera, get rid of the avatar, and place a 2D orthographic scene in the view to thereby construct a 2D game.  This is kind of like using a Mack truck as a garden shed: you've got all this powerful 3D architecture under the hood, and your fixing most of it in place so that you just use the 2D side of it.  But as mobile devices get bigger and more powerful, and include 3D rendering hardware it turns out you can get away with doing this.

As a programmer however, you can do away with all this extra baggage and enjoy the following benefits:

  • faster load times (no 3D engine to load)
  • zero cost per seat development
  • less licensing hassles
  • traction with Apple
  • immediate access to Platform API's
    • App Slicing
    • In-App Purchases
  • open source community
    • 3rd party stuff often $0
What are the drawbacks:
  • You need a programmer
  • Non-tech team member friction
  • Less off-the-shelf "store" assets
  • Code is not cross-platform
One of the difficulties with Sprite Kit is that many artists, animators and other creative professionals who are not programmers do not have experience with it yet, and thus find it hard to directly contribute their assets to it, and work with the tool set.

However I think this will change as Apple has a huge commitment to making coding with Swift and Xcode more open and available to the wider creative community.

The Sprite Kit route was a no-brainer for me as I have a career as a software engineer behind me in my game development.  Also I had my previous experience with Cocos2D which has a very similar API.  I don't need the features that Unity excels in such as 3D.  As a founder of a studio I don't want our IP saddled permanently with the licensing and lock-in hassles of being welded to Unity3D - which is a proprietary technology.  Unity also likes to monitor your games so that it can tell if you're adhering to the licensing conditions and it requires you to notify your players of this.  Basically for me its about having control over my game and my IP.

Swift, and pretty much all the Xcode & Apple toolchain is Open Source and Xcode itself is at the end of the day just an IDE, so there is nothing stopping me editing my code in JetBrains AppCode or other tools.  I could edit my assets in other tools such as for example Texture Packer, and TileEd.

Want to give Sprite Kit a serious try for your studio's next game?  I strongly suggest going and buying Ray Wenderlich's PDF book "2D iOS & tvOS Games by Tutorials".  They update their stuff and you get the updates for free, and despite the title its not just a starter book, it teaches you 90% of what you need to get going, and gives a huge bunch of sample code as well.

Your mileage may vary.  But have a look at the pros and cons, and especially try to think of the longer game if you're a professional studio, or consider that you might want to be a buy out option so that you can at some point exit your studio.  Due diligence and buy-out exits are much easier when you have the fewest possible licensing hassles linked to your IP.

I hope this article helps, and if you share some of the same aspects that I do when it comes to game development you can be clearer about your choice of engine or framework.

Thanks for reading!

Sunday, October 25, 2015

Block Twitter Trolls with GGAutoblocker

Because I'm an indie game developer, social media is basically the only way I can afford to promote my games, and thus pay the rent.

Without the budget of a big studio to pay for advertising & marketing getting on Twitter, Facebook, Google Plus and a bunch of other sites and forums is the only way I have of effectively communicating to folks about the games I build.  That means "just get off the Internet" is not an option for me.

But guess what else - apart from the game playing public who might be interested in my stuff - is on the internet?
https://youtu.be/TLEo7H9tqSM - Troll Hunter
Trolls.  Folks who love to attack, based on gender, or anything they perceive as weakness, and who use tactics ranging from obscure ranting arguments to outright threats to make life on the Internet into a living hell.

Well, it turns out there is something you can do about it - block them!  

But wait I hear you say, can't they just change from the last anonymous account they used to yet another new one?  Aren't I just going to be playing whack-a-mole waiting for these idiots to crop up on my feed before I block them?

This is where you need some help from the professionals!  An engineer named Randi Harper has come up with a tool called GGAutoBlocker which automates the pain of keeping up with block lists, at least so far as Twitter is concerned.

Here's how to use it. You might want to keep this page open on say the left side of your screen, while you open a new browser window on the right side. Then start by right-clicking (and choose open a new window) this link to GGAutoBlocker which will take you to step 1.

This is the GGAutoBlocker.com site (which is actually a page in Randi's blog) which has two links you need.  Right-click the first one and open in a new tab, to get to step 2.

By following the link from the GGAutoBlocker page you'll find yourself on BlockTogether.org's website where you can sign up to use their Twitter blocking services, by hitting the sign-up button.

The sign-up button will take you to a page that allows BlockTogether.org's web-app to access Twitter on your behalf.  Sign in here with your Twitter credentials.  Make sure you use the Twitter credentials - username & password - that you use for the account you want to be protected by the block list. Is it safe?  Its as safe as any service these days, and if you later decide you don't want BlockTogether.org doing stuff on your behalf you can go into your settings on Twitter.com and nix the permissions.

Now you are all signed up to use BlockTogether, you need to get to the specific GGAutoBlocker block list.  Go back to the tab from Step 1 with the GGAutoBlocker page, and click the link for the actual block list. You're one step away from blocking Twitter trolls!

You should now have the GGAutoBlocker block list page up on BlockTogether.org listing thousands of trolls to block.  Now you can just click the blue button to block all the trolls on the list!

What if Someone is Wrongly Blocked?

What BlockTogether.org and GGAutoBlocker is doing is recording & automatically blocking all the trolls that were identified by Randi's automated scripts.  Its really the same thing you can do manually by blocking someone on Twitter.  Now there's of course a chance someone you really wanted to hear from was blocked but you can fix that in a second by just using Twitter to unblock them.  There's more advice about how that works on BlockTogether.org's website.

This Only Works for Twitter - what about Facebook & other sites?

That's true.  You could support Randi and other's in their work on OAPI which is trying to do more to prevent online abuse. Until more tools become available there are still good privacy controls in Facebook, Google and other services that you can use to block people.  Sorry its so horrible out there.

Isn't it Wrong to just Block People?

No, you don't have to listen to people whose goal it is to hurt you.  They might have a bunch of free speech arguments, but really they don't care about anyone's freedom except their own ability to freely cause harm.  Randi has a bunch more on this topic on her "Frequently Yelled Statements" page.  I like how its called that instead of "Frequently Asked Questions".

Sarah, you're a Terrible Person for Supporting This

No, actually I'm really not.  For anyone determined to push this line I say "Just go ahead and make a comment so I can block you".  :-)

But seriously your freedom to speak does not extend to this forum which is my own blog.  Here I can block comments if I like.  If you want freedom to attack people go and do it elsewhere.

Freedom of speech does not guarantee me - or anyone else - listening.

The People behind this GGAutoBlocker are Terrible People.

That's what's called an Ad Hominem attack.  There's a lot of inflated claims, and just plain falsehoods generated by the very trolls who are blocked by this tool.  The internet troll's stock in trade is fabricating things & wildly exaggerating others to attack, defame, gaslight & discredit anyone they take aim at.  Blocking such liars is the first step to taking away their power to hurt folks.


I hope this guide helps someone and if you have any relevant comments feel free to leave them below.

Tuesday, September 8, 2015

CPAN modules on Mac OSX

Got problems with PKG_CONFIG_PATH on Mac when trying to install Perl modules via CPAN?

Update: take care, see message at the bottom of this post BEFORE typing any of the commands listed here.

Maybe this will help.  First some background.

I wanted to write a Perl script and use the Text::Hunspell perl module plus whatever dependencies it required.  I know from experience its a pain to install a module with all its dependencies, so I usually use CPAN for that stuff.

To access CPAN on Mac just open a Terminal window and type

perl -MCPAN -e shell

That will take you into a shell environment for the CPAN command line utility, from where you can first configure CPAN (usually pretty much automatically by hitting return to accept all its defaults) then install packages via:

install Text::Hunspell

You can discover the names of packages you might want by browsing CPAN itself using your web browser.  For example if you're looking for XML parser modules just type "xml parser" in the search box.  There heaps and heaps of great free modules there for just about anything you can imagine.

Now the problem comes on Mac where your module you want to install depends on some binary program that you've installed, but which Perl cannot find.  Because Perl is built on C and has a Unix like behavior for compiling and otherwise dealing with binary programs it will fall back to trying to use the pkg-config utility to find the binary programs.

In my case I had installed Hunspell from the source package available on their website.  Once I had downloaded the .tar.gz file I built it via:

cd ~/build
tar xf ~/Download/hunspell-1.3.3.tar
cd hunspell-1.3.3
sudo make install

If you're trying to do the same thing, or trying to build some other software and are getting errors about the compiler and toolchain, make sure that first you have installed the command line version of the Xcode tools.  There's a good guide on this Rails site.  If you can type

gcc -v

and get something like

Apple LLVM version 7.0.0

Then you already have the tools.  Otherwise follow the guide to make sure you have Xcode installed and then run

xcode-select --install

...to install then.

OK.  We have a new binary program - in my case hunspell - installed in /usr/local - and now we want to hook up Perl to it but there is a problem.  Perl won't look in /usr/local by default and thus you will get failures from CPAN's shell when you try to install.

To fix this in my case I installed pkg-config from the handy installer on this page.  You want the link that says Download: PkgConfig.pkg - once downloaded install it as usual for .pkg files but note you'll need to right-click and "Open" it as its not signed.  Note that pkg-config gets installed under /opt/pkgconfig/bin.

Once its installed you'll need to tell your shell how to find the relevant files: add these lines to your bash profile by editing the appropriate file:


...and adding the following lines:

export PATH="$PATH:/opt/pkgconfig/bin"
export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"

Now you're ready to run the Perl CPAN shell again.  One more thing however:  if you are going to install CPAN modules for the whole of your Mac OS X system, rather than just to your local user account you may run into issues.

If you run the following command:

sudo perl -MCPAN -e shell

to install as root, or if you ask Perl to go to sudo for you, then your build environment may not get the environment variable that you so painstakingly added to your bash profile.  To fix this pass the -E switch to sudo like this:

sudo -E perl -MCPAN -e shell

Now you should be good to go ahead and install loads of cool Perl modules!  Have fun.

Update: If you run perl unprivileged by typing 

perl -MCPAN -e shell

Then you will get a prompt inside CPAN asking you if you want to use local::lib - if you accept that you'll get a mysterious environment variable added to your .bashrc that causes your perl installs to go into your home directory, e.g. ~/perl5

This just wasted several hours as following that CPAN could not find those modules and you get piles of errors about modules not found, wrong versions, and missing dependencies.  It's because the MakeMaker is installing its stuff into the ~/perl5 directory as instructed by PERL_MM_OPT.  But CPAN is not looking there.

To discover if you've hit this issue type 


in a Terminal and check if one of the variables is PERL_MM_OPT.  If it is then local::lib as implemented by the CPAN shell has modified your .bashrc for you.  Nice.

Just edit .bashrc to remove the offending lines (they're documented here) and then start a new Terminal window to get the shell environment minus the option.  Now to be safe delete the ~/perl5 directory, the ~/.cpan directory and start again from scratch with your privileged CPAN using sudo as above:

sudo -E perl -MCPAN -e shell

If you really want to use local::lib then try looking up separate doc for that.  Its beyond the scope of this post.

Thursday, August 6, 2015

Fixing SKLabelNode performance issues

I'm loving working with the Sprite Kit API for game development.  Using all the tools I'm effective with, that other software dev folks would know: a good code editor, nice tool chain and a well-documented API; I can really get stuff done.

In a primarily graphical environment sure you can lay things out visually, but for the thing I'm currently trying to do - layout a virtual keyboard for a game - I need to do it programmatically so I can cope with changes in screen size.

But: I found some issues with the layout code pausing big time, during the load sequence.  This was revealed by testing on a 3 year old iPad Mini that I keep around just because its great at exposing these sorts of problems.

Folks, do not EVER rely on testing your game or app in the simulator.  Use a device ALWAYS.  Once you have your project mostly done and discover you've introduced some horrible performance issue, its going to be impossible to find.

This one manifested as an ugly lag in the response after hitting the "Play" button and it needed to be fixed.  I used the Xcode tool "Instruments" and fired up the Time Profiler to drill and find the culprit.  If you've never used Time Profiler before there's a good Ray Wenderlich tutorial on it.  I also used a home grown time logging tool, the code for which I have stuck up on GitHub.  Being able to instrument my code by hand is a great complement to using the Instruments tool.  Here's some of the output from my tool:

Time stamps:
    Before press play button - 0.0
    Play button pressed - 0.00773762501194142
    Starting transition - 0.322784499992849
    Game Scene didMoveToView start - 0.323094458348351
    Scheduled music - 0.323781083337963
    setupGamePlay: done setupCarousel - 0.329451166675426
    setupGamePlay: done setupMonsters - 0.678052625007695
    setupGamePlay: done setupMissile - 0.945051541668363
    setupGamePlay: done targetMissileAt - 0.94512124999892
    Setup Gameplay - 0.945148375001736
    About to create keyboard - 1.07598399999551
    addKeys: About to calculateKeyCapMetrics - 1.07624216665863
    About to create SKLabelNode - 1.07625199999893
    About to set label text - 1.07641391665675
    About to set font size - 4.5479717499984
    About to set font color - 4.55641954168095
    Done with label - 4.55644533334998
    calculateKeyCapMetrics: about to setup frame - 4.56316420834628
    calculateKeyCapMetrics: about to calculate frame - 4.60020420834189

    calculateKeyCapMetrics: done - 4.60023920834647

There's a 3-4 second delay there while the SKLabel's text is set! That's crazy!

Luckily that is a one off, and subsequent calls to set the text with the same font turn out to be fast. Very interesting. More investigation with the Time Profiler:

It reveals that the iOS True Type font system is having to load the font - its a custom one that I added to the project, not one that ships with iOS. Its during the first load and unpacking all the font information that the delay is incurred. I guess there might be some reading from flash of the iOS device in that as well.

Right: so that makes it a good candidate for pre-loading after the start scene has been displayed but before the player presses the start button.

So, off I got and implement pre-loading of the font.
    func preloadResources() {
        let label = SKLabelNode(fontNamed: "Ancona-Ex")
        label.text = "preload"

    override func update(currentTime: NSTimeInterval)
        if !preload

With that done, time to run a new profile session:

Time stamps:
    Before press play button - 0.0
    Play button pressed - 0.00989962500170805
    Starting transition - 0.318517291656462
    Game Scene didMoveToView start - 0.318650125002023
    Scheduled music - 0.318978958326625
    setupGamePlay: done setupCarousel - 0.324560000008205
    setupGamePlay: done setupMonsters - 0.69843762498931
    setupGamePlay: done setupMissile - 0.969889125000918
    setupGamePlay: done targetMissileAt - 0.969957374996739
    Setup Gameplay - 0.969982250011526
    About to create keyboard - 1.11275391667732
    addKeys: About to calculateKeyCapMetrics - 1.11366166666267
    About to create SKLabelNode - 1.11367308333865
    About to set label text - 1.11383529167506
    About to set font size - 1.11686108334106
    About to set font color - 1.12038704167935
    Done with label - 1.1204140833288
    calculateKeyCapMetrics: about to setup frame - 1.12638933333801
    calculateKeyCapMetrics: about to calculate frame - 1.1502004583308

    calculateKeyCapMetrics: done - 1.15022912499262

Time to create the label text has now dropped away to nothing! Nice.

Hope that helps someone else working with SKLabelNode and custom fonts.

Sunday, June 28, 2015

Unity is not Free

As I work towards getting my new game Word Monsters! published on the various mobile app stores, I'm mulling over the decision I made to go with Unity for this game.

Update 2: I contacted Unity's sales manager in Australia for clarification and there are a couple of things that makes this picture better than the scary thing it seems at first blush.  If you have questions, contact them via the Unity website: they're very helpful!  (Thanks Patrick).  Also, I should clarify that for hobbyists who NEVER really plan to make a living out of Unity games then the issues here may also not really be a problem.  If like me you're a serious indie developer who spends their days writing games and has to make a living out of it, especially if you do so through a Pty Ltd company then READ THE EULA and inform yourself.  You also might want to consider getting your lawyer to look at it: I am not a lawyer and this is not legal advice.

The Elephant in the Room
Its more and more obvious to me that the naive idea that a lot of developers go with around Unity - that its "free" - is completely wrong, and a bit dangerous.  For me the cost is around $6k by the time I convert into my local currency.  Let's break this down.

Non-Dollar Costs

First let's look at a couple of non-monetary costs.  I have noticed that load times are longer than native, and by an amount that might cause some players to drop off.  Also app bundle sizes are large: I'm struggling to get the size down.  I'm sure there's lots of things I can do.  I believe in "premature optimisation is bad" and as a result I'm looking to these things as I get closer to publishing, but its a real issue.  This could translate into a monetary cost if potential players are put off from the game - some players just delete a game if it takes ages to download or start-up.

Another cost:  calling out to iOS platforms like Social and Store is a pain from Unity.  Same for Android API's.  You need to use various wonky plugins from 3rd parties, and those might not play well with your existing plugins, and can add to your load time/app size headaches.

Is Unity free?

But the elephant in the room is that people treat Unity as "Free" - its not.  

I'm not saying its not worth what they're asking for it: around $6k AUD.  Its got amazing power and is a very feature-ful product.  Compared to other large software suites like the various 3D editors, like Adobe's products and other creative industry software its reasonably priced.

But wait, you say $6,000?  Unity Pro is only $1500, and you can pay a subscription of only $75 a month!

And then you say:
Well, it is $0, as long as you earn less that $100,000 - and wouldn't that be a nice problem to have.  Yeah, amirite?  Grin!
Not so fast.  OK - let's say I want to try to eke out a living making games, and I think "OK, lets meet Unity's conditions for the Personal Edition".  To do that I have to make less than $100,000 in a given financial year, so July 2014 - June 2015 for example.  But that is gross revenue, across all the Unity titles I have in the store, for my entity.  In my case the "entity" is Smithsoft, my company.  

The $100,000 is gross revenue.  Go and read the licensing conditions.  They're well written and worth a read.  So Unity is coming in to check on you before you get to deduct any of your costs.

How Much Can I Make Before Paying for Unity?

UPDATE 1: After a discussion with some game dev colleagues this first paragraph looks to be wrong.  If you don't receive the money in your bank account then it doesn't count as revenue.  So if the App Store takes it cut before passing on the rest to you, then "revenue" for the purposes of Unity's $100k calculation may be more forgiving.  My advice: check with your lawyer or accountant first.

UPDATE 2: The following paragraphs in this section have been reworded after clarification from Unity that "revenue" does mean money remitted to your bank account from, for example, the App Store.  But while you do get to effectively deduct App Store costs, you don't get to factor in all the other costs of developing the game.

Let's say that in a financial year after Apple takes its cut I get a smidgin under the Unity cut-off of $100,000USD as revenue in my bank account from sales of my premium iOS game.  That's around $130k AUD.

Out of that I have to pay for

  • contract developers 
  • artwork/artists/animators/modellers
  • voice acting, musicians
  • pre-made assets costs / Unity assets store purchases
  • work-space rentals
  • software costs
  • registering domains & running up a website
  • accountants
  • promotional video
  • advertising...
  • on and on it goes

anything else that it cost me to build my game.  There's a ton of hidden costs.

For some of us we do our own coding, art and so on.  Great, right - don't need no stinking contract developers.  But doing it yourself doesn't mean its free, as our time has value.  I could be working elsewhere as a Software Engineer at whatever the going rate is.  If instead you're working full-time for 6 months on no pay, that has a cost.  If you don't know how much it really costs to make games do some research, its not cheap.  Let's say its a casual game with one person full-time, and a few casual contractors bought in as needed to do art, etc, and took 6 months from go to whoa.  Total cost to make the game, conservatively $AUD80k.

Here at River City Labs over the past 3 years I have made my own game, and worked alongside teams of developers working on at least a dozen other titles to go to market.  I think $AUD80k is pretty fair on average for a casual game over 6 months right now.

Now out of the $130k I'm left with $AUD50,000 in my pocket - Software Engineers make twice that in a regular paying job.   And out of that I have to pay the Australian Tax Office its cut.  I'm not saying its a bad lurk, and it would be great to be that successful.

All I'm saying is that "making $100,000 a year" is not a path to fame and fortune that it sounds like.  By the time you factor in the costs of making the game its barely a living wage if you are trying to make a living so you can actually be a full-time game developer.  What I'm saying is that that figure is out of your gross revenue.  Do your sums first before you plan to "be successful" by sneaking in under the Unity revenue watershed.

If you want to take home enough money to actually pay rent, and put food on your table at home, then your gross revenue is going to be more like $200k AUD minimum so that by the time you pay your game dev bills you actually have something left to pay for food.

After Flappy Bird and A Dark Room it seems like you can make some game on zero budget but make out like a bandit on the App Store.  For every Flappy Bird there's millions of low-budget, low-quality games on the stores that languish and never make a cent.  You'd be better off packing grocery shelves for that time, and spending the money on a Lotto ticket for the chance you have to get paid that way.

The reality is that games with modest production values and good development teams behind them are the ones that succeed, and those games cost to build.

So Let's Buy Unity

Or, you can make more than $100k revenue, and go and buy Unity Pro.  I guess you can do that after you make the $100k threshold right?  Be careful - you can't use non-Pro stuff alongside the Pro stuff. There's caveats.  Read the license.  But anyway, we're assuming we're going to buy it.

Update 2: I contacted the Unity guys and they clarified that the intent of the "no mixing Pro and non-Pro" clause is just to make sure that everyone on the team doing development does have the Pro license.  You are totally fine to switch to Pro later in your games cycle.

So how much is Unity?  Let's assume you require Unity Pro because you broke through the $100,000 gross revenue watershed.  Further lets assume you got Unity because you thought it was so awesome that Unity lets you publish to both iOS and Android, and that's what you did.  Well you need to get:

  • Unity Pro - $US1500, 
  • Unity iOS Pro - $US1500, and 
  • Unity Android Pro - $US1500.  

And the costs add to a total of $4500 US - which is $5857.35 in Australian dollars.  That's the lion's share of $6k depending on exchange rate.  Before you click that buy button check what your local spend is going to convert to.

If I buy Unity 5 right now, for around $US4.5k, I get to keep and use it for ever.  Usually that's what buy means.  Nice.  If I'm grossing $US100k then that $US4,500 is not so bad.

But when Unity 6 comes along, all bets are off and I have to buy it all over again.  Note that the cost to upgrade from a previous version is cheaper.  But you do have to get your credit card out again.  Maybe the subscription option is looking good?

What About Renting it?

If I go the rental route I pay $75 a month, for each of the 3 items, and that is a total of $225 a month, and when Unity 6 comes out I just start subscribing to that.  Great.

And as soon as I stop paying I don't have Unity Pro any more.  Its like a spring-loaded trap if you don't set up your payments right.  I don't like that.  I'd prefer to buy up front and know I'm clear, but its a pain that I have to re-buy if I want the new hotness in later releases.

Is it really a trap?  In fact is it really so bad, if I don't get Pro and kind of fudge around that fact?  Nudge, nudge, wink, wink.

Unity Knows...

First thing you should know is this phrase from the license:
...may send data to Unity to: (a) check for Software updates; (b) provide aggregated usage statistics of your use of the Software and the use of your Licensee Content by end users; (c) provide analytics and advertising services; and (d) validate license keys
So how does Unity know that you're making more than $100,000 from your Unity games?  By having monitoring code in your games.  
  • You are required to have that code in there
  • you can't (legally) remove or circumvent it, and 
  • you are required to inform your players that its there as part of the privacy policy
Update 2:  If you get Pro then you have the option to turn off Unity's monitoring, and if you do that then there's no privacy policy requirement to inform your players.  Obviously if you have your own analytics you should check the privacy laws in your country.

So how scary could Unity's lawyers really be?  I don't know - and I don't want to find out.  The prospect of even some sort of shadow coming down over my games which are published on the Play Store or App Store is just terrifying.  I love being a game developer.  Unity's lawyers contact the App & Play Stores and say there's an issue with my games - what happens to my account on those stores?  That could be game development over unless I change my name, move countries type stuff.

Not to mention that being non-compliant with licensing means that if I decide to sell my IP, or my company which holds the games, or seek investment based on a stake in my company, then due diligence is going to close over my limbs like a bear-trap.  Here's me waiting for my nice check for Activision buying my company, and instead I get served a writ for failing to own everything I said I owned.

Due Diligence Bug-Bear

If you work for a company and expose your employer to due diligence issues you could be in trouble personally, depending on what your employment contract says, and what kind of shares you have.  If you've never heard of due diligence before, go and Google it - know about it before it bites you.

As a little guy, you might think "its no problem - none of that could ever happen to me".  Maybe.  If you want to stay a little guy.  Maybe Dong Nguyen, the author of Flappy Bird thought like that.  Or insert any other game dev success story.

And success only to have it all taken away by some legal nightmare is almost worse than no success at all, in my view - you might lose your reputation as well.

All I'm saying is if you actually want to succeed in game development you don't just brush aside legal concerns about licensing and think you'll solve them down the track.

Things that make you go Hmmm

So coming back full-circle - what are the options then?  Do we have to pay thousands for Unity if we want to go to iOS and Android?

Update 2:  Its possible to wait until some later time in your games development cycle, such as when it looks like you will make over $100,000USD and then buy Unity Pro.  The fact that you can still pocket say $50k for a years revenue without triggering the "Unity Pro" condition makes it viable to take the risk.  But in my opinion unless you're a hobbyist with no serious intent to try to be a full-time indie game developer, you REALLY want to read up all the Unity licensing, get advice, make sure you budget for that $6000 spend and be ready with your credit card for that day.

I'm wondering if it makes more sense to ship the iOS game using native frameworks like Sprite Kit.  If it makes any money on iOS, take the $6000 you saved by not buying Unity and get someone on UpWork to build the Android port, using for example Cocos2D-X or libGDX.

In the end the goals & drivers you might have, including targeted platforms, existing team skill-sets and so on are what dictates what you choose.  Unity is definitely worth the money, but just remember - its not free, so don't decide to go for Unity thinking its free.

Thursday, May 21, 2015

HeyZap Integration

Getting linker errors when trying to make Xcode build your Unity project after integrating HeyZap then Facebook?

Undefined symbols for architecture arm64:
  "_kUTTagClassFilenameExtension", referenced from:
      -[HZAFStreamingMultipartFormData appendPartWithFileURL:name:error:] in libHeyzapAds.a(HZAFURLRequestSerialization.o)
  "_kUTTagClassMIMEType", referenced from:
      -[HZAFStreamingMultipartFormData appendPartWithFileURL:name:error:] in libHeyzapAds.a(HZAFURLRequestSerialization.o)
  "_UTTypeCreatePreferredIdentifierForTag", referenced from:
      -[HZAFStreamingMultipartFormData appendPartWithFileURL:name:error:] in libHeyzapAds.a(HZAFURLRequestSerialization.o)
  "_UTTypeCopyPreferredTagWithClass", referenced from:
      -[HZAFStreamingMultipartFormData appendPartWithFileURL:name:error:] in libHeyzapAds.a(HZAFURLRequestSerialization.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Its because the MobileCoreServices framework now needs to be included. See the images below.
Select the libHeyZapAds.a file in the Project

Ensure MobileCoreServices is checked