Thursday, November 20, 2014

A Little Help Would be Awesome!

Hi friends!  So if you have a little time to help out a struggling indie game developer - and you have an iOS device - I would really really appreciate it!  My new game Space Bot Alpha is out on the App Store, and *just got a feature at 9th position* in worldwide paid strategy games.

Its make or break time for my bid to be an indie game developer.  My app store feature only lasts a week, and thus *I have only that 7 days* to turn that exposure into actual success for our little heroic Space Bot.

What do you need me to do?

1) Find Space Bot Alpha on the App Store of your iOS device, or failing that on your iTunes by: App Store > Featured > Categories > Games > Strategy > Paid -- or -- by typing in the search box "Space Bot Alpha".  There's also the button on this page.

2) Play the preview video and check the screenshots and see what you think!  I'd love it if you'd play the game if it looks like fun.  I have a couple of promo codes if the $1.99US cost is an issue.  If it doesn't look like your thing, well, thanks for reading so far!

3) Share! If you get through 1) & 2) above then please please share.  The game has a built in sharing feature that takes a screenshot whenever you win a level, and tapping the share button on the score screen allows you to tout your victories on Twitter, Facebook and SinaWeibo.

4) Review!  This is sooo important to me.  Please please review!  If you liked the game, go and add a review by hitting the "Reviews" tab on the Space Bot Alpha page on the App Store.  Genuine reviews from players are huge for helping App Store browsers decide to spend their hard-earned coin. Note that the option to review is only available if you get the game.

5) Write a blog post, online review or even just talk about your experiences playing the game.  I have to be a publicity seeking firefly right now, so any bit of extra buzz is great!

6) Follow / subscribe / like on the Space Bot Alpha Google+ page.  A Facebook page is coming soon.

So, well - thanks for reading!  Got questions?  Check the FAQ or post below.


If you were on Android...

I'm a one woman coding team, and while I'm currently working hard on the Android port and have early builds working already, what I have right now available is the iOS version of the game.  If that fails in the App Store its possible the Android build will never eventuate.  Right now I need to hype the iOS side of things to pay for ramen and rent, so I can keep working on the Android build and the next update.

Great about your feature, why do you need us?

Yes, its great that Apple has featured the game!  Being at 9th position for paid strategy games is a huge deal.  It means I have a chance.  But that exposure means nothing if those folks browsing the new strategy games in the next week never wind up getting the game.  This is where *reviews and a good vibe on social media* come in.  Convincing those browsing folks to be Space Bot Alpha players is critical right now!

Couldn't see the Preview Video?

For some reason Apple uses the iPhone 4"/3.5" shots for the iTunes desktop, and since I only recorded game play videos for iPad, iPhone6, and iPhone6+ that may be empty when you view the game listing.  I'm on it - will be fixed for the next update.  In the meantime you can see the video on YouTube (embedded above) or on the Space Bot Alpha website.

Found a bug/crash!

Ah, the joys of being a solo indie developer!  Its really hard to test all corner cases on all devices and I'm already aware of a few crashes and niggles.  If you have time to report them you can do so on the support page: - also I should get reports sent to me from Apple.  I'm already working on the next update to the game which will have some fixes in it for these issues.

Can't Afford It!

I know, by the time $1.99USD gets translated in to local money it can be a bit of sticker shock compared to other online buys.  Especially if you're between jobs or otherwise doing it tough.  So, here's some promo codes:
  • M6TPRJPY6969
  • 9EH97PENY74T
If you use one please comment below so that other folks don't get the cold shoulder when they try it on the App Store.  Also, if you try a code and it doesn't work - maybe someone forgot to record it below, so if you could comment below on that too it would be super cool!

I don't have Time!

Its a problem!  Me too.  :-)  Don't worry about reviews or the other stuff if you have no time to play, or its not your thing, as what I am really after is genuine player feels for the game.  I would not ask that of you, so if you have no time I totally understand and you're off the hook!  Maybe someone you know does have the time so feel free to share this post!  Pass on the hype!

Thanks for Everything!

I could not have got here without my amazing Producer, business partner, hubby and best friend Raymond Smith.  He has put up with my tantrums, fits of despair and interminable 7 day weeks to get Space Bot Alpha to where it is now.  

My very close friends (hi Kahni especially) also have been a huge rock of support - so thank you all.  Also a big shout out to my folks Maxwell and Shirley Smith for being encouraging with this crazy game development effort.

Its tough being an indie developer with no marketing department and no AAA budget.   So thanks again, and wish me luck!

Wednesday, October 29, 2014

Space Bot Alpha

For the past six months I've been working on a touch device game called Space Bot Alpha.  Here's a video.

Late on Wednesday evening I pushed the final release candidate binary to Apple's App Store review pipeline.  If you want to check out the game I'm expecting it will go live around November 5th.  Doing a review, article or LetsPlay?  Ping me on Twitter and I can get you a access.

Whoa. What a totally weird feeling.

After 2013 and working really hard on Ethex2080 only to realise that I'd need a team of 2-3 people as well as me, and another 12 months to get it done, this year has been all about getting my feet on the ground and shipping a video game.

Now, I proved to myself I could do it, and even if your tastes in games are not aligned to space ships and strategy/puzzlers I hope you'll agree with me that the level of polish and completeness is pretty good for a solo indie developer's first published game.  I'm reaching around and patting myself on my back right now.  But its also weird after pushing so hard for so long to break thru and ship this thing.

Yes, I'm really pretty happy with how Space Bot Alpha has turned out, and although its the end of this stage of the Space Bot Alpha story, as the plucky little guy still has lots of work yet to go with Android releases, level packs and other stuff.  So no relaxing just yet.

But I have to say I'm really excited about what this uncorks for me going forward.  Pushing a build isn't everything: I know that.  If no-one likes the game, and no-one plays it then I am going to have to seriously rethink what I'm doing.  But I did a lot of testing and I've seen people have fun with it.  I've even had some fun with it myself which is pretty amazing considering the times I wanted to just throw my dev tablet across the room in frustration at some stupid bug.  I think this, right now, will be the moment I look back on as when my game development career kicked in to high gear.

In December I'm heading to the UK for a holiday and that'll give me a chance to reset my head.  In 2015 I'm planning to make a new game.  In October 2015 at PAX and GCAP I'm going to turn up there and belong; I'm going to have 2 published games under my belt.

Wanna know more about that new game?  Subscribe here and I'll dump some concepts in coming weeks and months.

In the mean time thanks to everyone that was so supportive and appeared just when I was on the ragged edge to say some nice things and keep me going.  I want to give a particular shout-out to my friends at Disparity Games, Nic and Jason and the rest of the Stark clan; and also +Cameron Owen and +James Bowling of AttractMode Games for making me feel like a real game developer.

And, hey - what are you doing just sitting there!  Go check out Space Bot Alpha!

Friday, July 25, 2014

Testing Games

How do you go about testing a game?  What makes a great game tester?  What is different about trying to improve the quality of a game compared to other software?  How can game studios large and small ship titles that turn out to have serious bugs?  Don't they test properly?

These are serious questions both for game developers at the indie level like me, and for larger organisations; but also for the game playing public spending their good coin on titles they expect to actually work.  The screenshot above showing a main character model collapsing under what looks like broken physics/ragdoll is from a video posted by dubesor on the Steam Community site, who found a number of pretty hilarious and also quite serious bugs in the game "Cognition" by Phoenix Online Studios.  I recommend checking out dubesor's post for the video.

I played Cognition on iPad and as soon as I started playing I ran into bugs - Erica's gun turned into a big black square, behaviour consistent with a missing sprite for a billboard, right at the beginning of the game.  Cognition was a great game with some innovative ideas, and beautiful realisations in artwork, animation and dialog.  Yet I found bugs, and others found different bugs, so how can a studio release a game with problems that are so obvious and widespread?

I'm going to take a stab at these questions and hopefully say something useful about game testing.  But first I want to say that Software QA is an enormous area, with hundreds of great books already in print about the subject, so I can't possibly give any kind of general coverage of that topic in this brief rant.  If you seriously want to be a great QA Engineer there are some excellent books on the subject.  Michael Feathers book "Working Effectively with Legacy Code" about how to get testing into an already running project is great.

Even the more specific subject of Games QA is massive and fraught with differences of approach.  Instead what I want to do is raise three things to get us thinking more deeply about these questions, and point the way to the answers.

Developers Should Test What Works

Its a developers job to test what works, not every edge case.  Ask someone who is early in their career as a developer how to put on their QA hat and test the following function:

// Given the width and height of a sprite rect, return its area
int getArea(int width, int height);

They'll probably say (especially if they didn't write that code) something like this:

Oh, right - we need to test what happens when width is the smallest it can possibly be, and also the largest; and the same for height - yeah, and let's test all the combinations of those.  Right - that is a good start.
Fair enough, but that is not a "good start".  Where you must start in my opinion is by doing what I call "testing the man page".  In Unix-like systems you can take a function and call the command-line tool man (short for manual) to tell you what it is supposed to do.  So for example here is a screenshot of what the man page for fmaxf(x, y) looks like on my computer:

Pretty specific isn't it?  If a function does not do what its man pages advertise it as doing, then its failed.  So we first need to make sure it at least does what is written on the outside of the box.  If you have a bunch of fancy ideas about testing the limits of the data types passed in, or passing random data into it that is fine - but you have not done your job as a test engineer if you have not tested that the function does what it is supposed to do when passed in typical end-use values.

Well, there's no man page for our getArea function above, but there is a comment above it, which shows what the author intended it to do.  First off its pretty clear that the area is intended to model what a rect of a sprite can be:  and for that it really makes little sense for width and height to be negative values.  Also given that the rect is for a sprite, we can guess at typical values, eg 640x480 and so on.

What's more if you wrote a test that included passing in INT_MAX for both those values the result would probably overflow and produce garbage.  You might conclude that your testing had found a fatal flaw; but really unless you ever plan to have sprites of tens-of-thousands of pixels in size that is probably not the case, and your test is probably not valid.  For the professed use case of the function int is probably fine - maybe uint would have been better - so the limits of the data type are not really a problem.

The thing about functions like this is that often there is fancy caching and optimisations, and various other things going on under the hood, which we should not need to know about - all we need to know is that the function does what is advertised.  My point here is that the man page, the box description, that should be your starting point, and the other stuff is typically not worth the time up-front, and sometimes even no use at all.

As developers we understand this at a pretty fundamental level, and thus when we have to test our own stuff, we usually start with testing that we have at least done our job and what we produced performs when asked to fulfil its brief.  Should we be testing a lot of corner cases and boundary values?  Are developers falling down on the job when they don't try hard to break what they have built?  No, because exhaustive suite based testing provided by complete unit testing, system testing and integration practices is a different endeavour from software development.

If you ask a developer "have you done X" where X is some bit of software functionality the answer you get will reflect whether they have written the code and tried it out on its core use case.  Doing full QA on X is a very different thing from "developer testing" which is not part of QA at all really.  A good QA engineer starts with the core use cases and goes from there.

What this means for game playing public is that if you find a bug on your particular platform, operating system release and engine version that seems so incredibly obvious to you, the question to ask is not "how could the developers have released this!" it is something more like "how could the publishers not have paid for exhaustive QA which covered my configuration!"

I'll just say one more quick thing about this topic before moving on:  random testing is also not a good start.  In the refined air of security theory we have a practice known as "fuzzing" which involves blasting large amounts of random data at an application (typically a web-app with a HTTP front end) in the hopes of getting it to break.  There are also suites of security testing tools that employ fuzzing, in combination with very large data buffers, unicode characters and a range of other malicious data intended to break the application.  If an app can be broken, then likely it can be exploited and that is bad in something that has your credit card details or personal information.

This kind of "penetration testing" or "white hat attacks" are not where you start in games QA testing.  I'm not even sure if there really is a place for this near the end of QA testing, even in the most well resourced games publisher's QA house.  Games QA is about making sure that the central game play works when taken down the path that players experience on their regular hardware.

An Aside: Aren't Developers Supposed to Write Tests?

As a Software Engineer the answer to this is "Yes, always!".  And here, tests means:

  • unit tests
    • that is per function tests like when testing our getArea() function above
  • integration tests
    • designed to catch problems when we check in our code into the project
  • system tests
    • designed to test on real hardware with networks and inputs and so on
Doing these things properly is the only way to ensure critical software projects work properly.  Mobile operating systems, production software, commercial projects - you don't know if they're actually working unless you do these things.

But in games and apps, the project has no spec as such; there is no framework or system - we're writing user or player experience right on top of a UI layer.  Testing would involve taking screenshots to see if they "looked right".  If our development schedule and project budget has allowed time for it then sure - off we go and do those tests.  But often in games development at the layer close to the player, these types of developer testing are just not feasible.

In framework or library code, yes: developers write tests.  In production systems you must write unit tests as part of development and the budget has to be made to stretch to those tests.

But if you're writing an app or a game, or some other consumer software its pretty tough to justify the expense of writing unit tests to check a screen looks right, let alone setting up integration and system testing.

As a software engineer I would always write tests for every piece of software, but as an indie game developer writing code that gets thrown away 5 times before it reaches production writing tests is not justifiable.  Hence as developers of games we rely on QA testers largely for our process.

Software Testing is an Adventure Game not a Combat Game

I've worked with some great QA guys in my time as a software engineer.  The very best QA guys could work across an incredible array of devices with ease, and juggle multiple different versions of OS on those devices, installing our new updates carefully so as not to leave artifacts from previous installs that could corrupt the results, and then delivering timely accurate reports of exactly where I had screwed up in my work.

The QA teams job is a tough one, and at times its thankless.  But its also essential.  Here's how to think of QA: its like an adventure game, where you have to go into every room, find every object in every drawer, behind every picture that swings out, and under every trapdoor, before you can say you won the game.  In combat games you beat the boss with that final swing of your sword and you're done, even if you cut straight through the instance without doing any side quests.

Some QA guys I worked with when they started out they'd come out triumphantly with something they'd managed to break, perhaps in an interesting way like the bug in Cognition above, and wave it around proudly.  We'd give them a pat on the back, smile a wry grin and give them their moment.  The QA guys who got the most respect were the ones who produced a large list of issues big and small, from all parts of the projects functionality - and who found ways to reach and test that functionality even when weird, or distracting bugs made it difficult to reach.

So if you're recruiting for great QA engineers, just remember this: you want adventure quest players with an eye for the long game, not the boss killers who think its time for a big-noting break whenever they kill a boss.

QA is Hard(TM) but Every Bit of QA Done Makes Things Better

Finally my third and last point: don't be discouraged.  If you're a player and you still see buggy games; or if you're a developer or studio producer and it feels like you'll never make the game perfect; remember that the perfect can be the enemy of the good.  Delivering and publishing are essential and there's a very real truth to the idea that the best software is the software that got delivered, when compared to the theoretical amazing software that didn't.

I hear student developers and those working on their vanity projects say 
But what is the point?  No testing is going to find every bug!  You can test yourself blue in the face and still miss bugs!  What good are QA procedures if its not going to stop the problems its supposed to fix?
Well, here's some tough news to hear:  nothing is going to stop all your bugs.  If you are writing software (and games are software) then you are writing bugs.  The only way to make no bugs is to make no software.
Why have laws against murder if people keep murdering?  Why have democracy and voting if corrupt politicians keep getting in and feathering their own nest?  Why do exercise and eat healthy if we're just going to die anyway?
The answer is in the title of this section:  we do what we can to make it better.  Every incremental improvement trends us closer to where we want to be.  That is what QA is about, that is what being a tester is about.  You don't get to kill the boss, you don't get to save the world, you just get to make things better than they might otherwise have been.

If great testers and awesome QA procedures mean that you ship your game and the number of players experiencing awful bugs is one less; then it was worth something.  That one player gets a great experience from your game, and played it how it was meant to be played.

Wednesday, March 26, 2014

Getting a Qt/C++ App in the Mac App Store

Short story: yes, despite what you may have heard getting a Qt/C++ application into the Mac App Store is possible.  Its not simple, there are some traps but my app, Plistinator, is proof it can be done even the new world of Mavericks with its increasingly more stringent sandboxing regime.

Update: 29 June 2015 - with Qt 5.4 the macdeployqt application has greatly improved and not only has many of the bugs fixed, it also can help with the actual signing.  I've left the links to scripts and patches on here, but you likely will not need them all.

Mac App Store?

Do you really want your app in the Mac App Store?  If  you can, in my opinion - yes.  The cost in terms of Apple's commission is very reasonable since you get
  • fulfillment
    • download to an end-user's hands in exchange for zapping their credit card
  • licensing
    • get a license receipt for the app so you can deal with usage issues
  • handle reviews, charge-backs, upgrades
    • charge-backs and other post-sale customer issues are a part of e-commerce
  • captive audience
    • App Store is on every Mac
Doing all these things to a commercial grade is Hard(TM).  Sure you can use PotionStore and dump some binaries on Amazon S3 but are you ready to take the phone calls if your instance goes down after the credit card is billed, but before the download is served up?

Matt Gemmell has written an excellent article on the pro's and con's and I agree with pretty much everything he says.  My conclusion was that I wanted to go with the Store still, but I also sell my other versions outside.  If you are not sure about the App Store read it and see where you fall on the issues he raises.

I want to clarify the licensing thing: licenses are not DRM, licenses are not evil, Open Source has licenses.  In the App Store drafting the legalese of the license is done for you, so you don't need to hire a lawyer for that.  When the packagemanager installs it from the store the app is receipted, with the system storing its license key automatically - you don't need to do anything to manage that.  If you want to check the license key (Apple calls it a receipt) you can use their API.

By way of comparison, if you use CocoaFob what you can do is create your own keys and make a nag screen to enter the key if it has not been receipted for that installation.  You'll need to store the receipted key into some prefs file yourself.

I think a nag screen is a good way of dealing with the license key entry issue, because you can just have a "Later" button and if the person has torrented your app they can click "Later", or when they're ready "Buy" to go and get a key.  Without this a person could have a copy of your app and never realise they were even supposed to pay for it, or if they do have no way to complete a transaction to "buy" the app.  License keys give you this.  It means torrents become another marketing channel for you, instead of a dead-end to any revenue from your app.

For my app store binaries I just decided not to bother with checking receipts.  If I get the feeling its becoming an issue I'll deal with it then.  For my Windows binaries I absolutely want to do license keys so I do that with CocoaFob.

Sand-Boxing your App

Before you start to build the .pkg file that you'll be pushing up for App Store review, you'll need to make sure your code is sand-boxing compliant.  I love this article by Cocoa-in-the-Shell which is not so happy about Mac sandboxing.  :-)

I used Qt 5.2 which includes the latest fixes to Qt and also has specific Qt for Mac features.  It seems to work well with Mavericks.

In the Digia article (which I suggest following as a general guide) it seems your only problem is the preferences file location, and the storage of cache files.  As of Qt 5.2 you really don't need to worry about these things.  Just make sure that you have lines like this in your main.cpp:


and Qt will put your preferences and settings in the right place.  Make sure your apps bundle id in the Info.plist file match this.  If you use the new QStandardPath API in Qt you'll get the right paths to things like caches and file stores.

As the Digia article says you may use the Qt File open dialog so that the user can by inference provide permission to access any files that your app wants to open that is outside the sandbox.

The issue with this is that the Qt file dialogs return a QString which means you cannot save the Security Scoped Bookmark.  Converting the QString to an NSURL does not fix this, because the original URL has magic pixie dust embedded in it so as to make the bookmark and the QString returned does not preserve that.

To fix this you'll need to build a small Qt C++ wrapper for NSOpenPanel and NSSavePanel which presents the dialog to get the users response (and sandbox permission) and then saves the Security Scoped Bookmark.

Note that in the case of the NSSavePanel, if the file has not been written to (because you got a name to save a file to but there's no file there yet) you will not be able to save a bookmark.  My workaround is to write a file with a single byte in it as a placeholder, then save the Security Scoped Bookmark, then return from the wrapper and save the users file by over-writing the placeholder back in your main app code.  See my gists for some ideas.

Times you'll need the Security Scoped Bookmarks are:

  • recent files menus
  • opening the last edited file on relaunch
  • re-displaying a directory view after relaunching the app
basically any time you need to open a file or folder that you did not have the user open via a dialog, and can not now logically display an open file dialog for.

How to Build your App for the Store

Follow the pointers in this excellent article by the folks who are now behind Qt, Digia plc.  There are a few gotchas and wrinkles, but unfortunately doing a complete step by step tutorial is not really possible for me right now, and making it very specific would mean it was out of date when Qt or Apple change something anyway.

Here are the gotcha's I am aware of (read the Digia article):
  • I suggest using bash to create a build script
    • instead of trying to put the signing into your pro file
  • Setting flags for debug symbols via your "" file
    • Qt mkspecs are a bit off and I had to patch them to get it to work.  
    • See this Qt-Project bug report for my patches
    • You can probably get it to work more simply by hard coding the switches
    • Use my qmake line as shown below in your build script
    • I create a "appstore" stanza in my .pro, used to switch on App Store specific code
  • Building - as per normal 
  • Running macdeployqt
  • Extract the dsym with the utility
    • see below
  • Sign the macdeployqt bundle - if it helps using my script here
  • Run the productbuild command to create a signed package of your app
    • see snippet below
It's not obvious where the dsym file should go.  It needs to be right next to your app, for productbuild to find it, that is


Here is my qmake line from my build script:

qmake $SRC_DIR/${DEV_APP}.pro CONFIG+=release CONFIG+=x86_64 CONFIG+=force_debug_info CONFIG+=appstore

Here is a snippet from my build scripts for making the package:

/usr/bin/productbuild \
    --component $TMP_APP /Applications \
    --sign "$PKG_SIGN_CERT" \
    --version "$VERSION_NO" \

Hope that all helps.  If you get stuck feel free to post a comment here, and I will try to assist.  I'll feel especially motivated to help if you tweet or G+ my little app for me!  :-D

Thanks for reading!