Pixeljima Dev-Blog: Tutorials

In Pixeljima there is a mechanic of collecting stars.  Feedback from playtesting revealed at least one player who did not find it obvious that stars should be collected.  After some time, they did work this out, but they said it would have been nice to be told.

tutorial collect.png

The concept we came up with for tutorials was to have a "flight manual" appear on screen, open to a page with a tutorial message.   The tutorial messages use as least text as possible, from zero to one word.  For example, the collect tutorial looks like the picture to the right.

We worked through the other key concepts of the game and came up with this list:

  • "Red Planes" should be shot to drop a POW, and POW's should be collected to increase fire-power
  • "Medals" should be collected to restore health
  • The Douglas SBD Dauntless has a rear gunner turret, and we wanted to communicate the arc of fire.
  • Later in the game, when bomb upgrades are unlocked, the player has a target reticle.  This needs to be placed over ground targets, like factories, in order to trigger dropping bombs.
  • Two of the aircraft can upgrade to have a radar.  We want to show that the colours indicate different aircraft types.

The Red Planes tutorial image is shown here, to the left.

Each message only appears once, and appears contextually, just as each concept becomes relevant to the player.

The tutorial messages are experimental, and we haven't had enough testing and feedback yet to know how effective they are.

Also, for this first MVP (Minimum Viable Product) version, we didn't create a mechanism to re-set the tutorial messages, or a help area where the player could page through the flight manual - but both of these are on our ideas list.

Our hope is that by providing a minimum of hints early on in a players experience, we can eliminate some unknown and/or frustration, and increase retention.

A reasonable amount of play is required to understand and appreciate the game progression mechanics (collecting stars to rank up, and buy upgrades; achieving certain levels with certain planes to unlock others; working towards achieving medals and achievements; competing on the score leader board with others).  We don't have tutorial messages for these meta-game concepts.  Perhaps we should?

It would be great to hear your experiences around creation of tutorials in mobile games - please feel free to leave a comment.

By Stephen McIntyre

Pixeljima on App Store

Pixeljima on Google Play Store


Pixeljima Dev-Blog: Lessons from creating a leader board and achievements



From previous research on achievements, I knew that top games have between 30-40 achievements.  Also, that of the 1000 points available for your achievements, you should perhaps use about 700-800 of them with the first release, to allow for additional achievements in later releases.


I built out an achievement list of 30 items, spread across categories of completing levels, completing levels with certain aircraft, earning medals, unlocking upgrades and planes, ranking up, and high scores.

Apart from the obvious achievements of doing something for the first time, or fully completing something, I added achievements designed to encourage certain play behaviors.  For example, there are pre-requisites in the game before you are able to unlock the Boeing B-17 Flying Fortress or the Vaught F4U Corsair - so I made achievements specifically for unlocking those.  Also, there is a Public Service Award Medal in the game for sharing from the app, and rating the app - and to encourage this I added a Community Minded achievement to earning that medal.

Entering the achievement data into Google Game Services and App Store Game Center is about forty-five minutes of data entry each.  The Game Services were a little friendlier with a bulk export/import feature which can be used to make updates via CSV files.  I discovered that Game Center setup requires a translation for each achievement for it to appear in that users locale - so that added a translation task onto the todo list.

The great thing about both stores is that you can test achievements before they are live to public.  In my Closed Alpha build, and Test Flight build, I ran tests with two users in each, in different game states, to check the achievements were being awarded correctly.

One issue I had was that my testers were good at the game by this point, so were able to obtain the first two or three achievements in under five minutes.   My expectation is that new players will struggle much longer to get their first one and I should be able to monitor this in analytics.

Unity's cross-platform social features worked better than expected and I was able to get from zero to working on both platforms in about a week.  My first pass was just to see what happens (because you can't test in the Unity editor), then a bug fix pass, then addition of required features, such as remembering the users login preference - if they cancel a login - then don't auto-login next time they start the game.

There are additional features I left for a future update - such as awarding achievements to the player, earned while they were offline (no wifi, or no roaming data, or just not logged-in for example).  The app can be smart enough to note the award of the achievement failed, and re-send it once the user is online again.  I feel this needs some username recording to avoid accidentally sending player A's achievements to player B who happens to login to the device.  Also, to avoid intentional misuse of this.

Leader Board


Creating the leader board was straight forward on both platforms.  The only complication was that the game stores a top 10 table of local high scores.

I decided to send any score earned while logged in to a game service - but not to try and send the previous high score entries on the table (which might be higher) - because we don't know if they belong to the currently logged-in user.

In testing I found a bug where if you achieve 25,000 points, it wasn't awarding the 10,000 point achievement.  So, as a rule I send all achievements up to the one you just achieved.  This avoids missing one, and makes the system self-correcting if you advance further after you did something while offline.

Additional Notes

While you can use the art provided by Game Services for the leader board and achievement icons, you don't need to.  As Pixeljima is a cross-platform game, I wanted consistent icons so Zak, our art-guy, created some for the occasion in the games art-style.  He is also working through creating a set of achievement icons, examples of which are included above.

My tips for others embarking on setting up achievements are:

* Do your planning first - make the achievement list - with achievement names - conditions to achieve them - and point value - to fit within the 700-800 point budget.

* After getting data entry and coding done - allow time for testing.  Expect that at least one of the achievements is going to be bugged and need fixing - and your task is to be systematic until you find it!

* Be aware you will need translations of your achievement names and descriptions if you want them to be widely accessible.  Also, creating icons takes time - and you might consider purchasing one of the many achievement icon sets available.

By Stephen McIntyre


Pixeljima on App Store

Pixeljima on Google Play Store


Pixeljima Dev-Blog: Lessons from user experience testing

During the development of Pixeljima, we had a small number of volunteer, part-time testers.  Apart from direct feedback from these players, watching these players play was quite valuable.


In the game we have a screen where there is a picture of a hangar with a tempting question mark in the middle.  At the bottom of the screen is a button to spend 100 stars (in-game currency) to buy a random prize.  We observed players touching the question mark to activate the purchase, so simply added that as a hot-spot that did the same thing as pressing the button.

Other screens had timers which would move on to another screen after some animation.  When the timer was too long, the player would touch the screen or press the back button to try and move the action along.  The threshold for this "what's next" response is sensitive to within a second.  e.g. shortening the delay of moving on to the next screen by a second, removed the "whats next" response.

The game was designed to be hard.  In game design terms this is the concept of Fiero, hard fun.  There are only six levels, and there is a progression system in the game where you get better planes, better armour, better firepower, etc.  Also, they player's skill gets better as they learn the levels and the hazards to avoid.  One direct tester feedback we has was to make the start of the game easier.  Another direct feedback was to make the start of the game harder!

We found it depends on the player skill level.  A skilled player can take a non-upgraded plane through to level 4.  This kind of player wanted more challenge up front.  Lower skilled players were getting destroyed in a few seconds, and getting frustrated.

We solved this in two ways:  First we made the first half of the first level much easier.  It ramps-up in difficulty.  e.g. the first wave of planes don't shoot at you, the next wave only shoots after 12 seconds, the next wave after 9 seconds, etc.  The first waves that shoot fire half-speed bullets.  Then three-quarter speed, etc.  It's not until half-way through level one that you encounter "normal" strength enemies.  This gives new players more hope, it gives them longer to practice basic skills, and importantly - gives them access to the first mini-boss, and first POW pickup.

The second way was built into the game design, as players unlock new planes - they will encounter planes that are weaker at the start - which are much harder to get through the levels - which provides a greater challenge to experienced players.  So, the player that could breeze through to level 4 with an un-upgraded Lockheed P-38 Lightning, would be happy to reach the first POW pickup with a Brewster F2A Buffalo.

A friend of mine pounded the desk with his first and exclaimed, "I hate you!", because they couldn't get passed the first level.  I said if you hate me because the game is hard, I'm ok with that, but if its because of bugs then that's not ok.  His main complaint was that he couldn't see his plane under his finger, and additionally couldn't see enemy aircraft coming up from behind.  I inquired if he had discovered the control scheme setting in the pause menu.  He hadn't.  He changed control to "relative", then he could fly with his finger beside or under the plane.  He found that so much better.  The lesson here was to change the default control scheme to relative.

Another tester spent the first few games avoiding stars, which are dropped in-game and meant to be collected.  These provide currency to buy upgrades and new planes, and rank up the player.  To help with this we put a spin and sparkle animation on the stars, and we added a "tutorial message" system for new players - which offers advice like "collect stars", "avoid bullets", "POW's increase firepower", etc. at the start of each new game. 

One of my friends, after the game was in soft-launch, said, "I'm not buying your upgrades!".  I told him he didn't need to because he can get them for free.  "What?".  Yes, if you collect 100 stars, you can unlock a random plane or upgrade for free.  He hadn't noticed that option.  The banners at the end of game are random, and so you aren't always offered the option to spend your stars on a prize.  So I decided to make the banner always appear the first time you have 100 stars or more, and to grey out the rest of the game and make the player purchase a prize - in that way showing them an important game mechanic - and one of the key reasons to collect more stars.  Given that he is already frustrated by level one, and now knows he can get upgrades, I'm sure in time he will actually purchase something after perhaps another 40 games.

Finally, younger players can provide good unfiltered feedback on your games.  I've had a nine-year-old player play for 50-minutes in one session, and note that they were "determined!" to reach level 2 (this was before the difficulty level of level one was reduced).  Also, 50-minutes is pretty near the maximum attention span for a child of that age, so a good indication the game was engaging enough to keep trying.

Some feedback we haven't been able to address (yet).  For example, we haven't been pedantic in the resolution or colour palette - and have identified a few UI elements that we want to improve.  One screen has an annoying response delay which requires code to fix.  So things get prioritised, and worked on as we are able - but we felt it was better to get the game out and continue to iterate, rather than keep it under wraps and get buried under the always growing list of enhancements that could be made.

One thing is for certain though - user feedback, and observation of user interaction with your game, is a fantastic source of information to make your game better.

By Stephen McIntyre


Pixeljima on App Store

Pixeljima on Google Play Store

Pixeljima Dev-Blog: Lessons from our first app with in-app purchases

purchase button.png

We are using Unity, which provides an excellent "codeless" plugin for in-app purchase.  However, things are never that simple, and if you want to support restoring purchases (required for App Store), then you need to punch a few keys.

Our implementation started as a "codefull" implementation, were we set up a catalog in code, and made our own purchase buttons.  We had a default price shown of $0.99, built into a nice pixel-art button.  It worked great in the editor.

However, when you set up the products on the app store side, you realise there are local prices, and you need to be able to display a lot of local currency symbols, which we didn't want to make art for - so we switch to a localisation-friendly font called Noto.  So, now we had a string value of $0.99 showing on the button in that font if the local price could not be obtained from the store.  In editor mode, Unity's IAP provides a placeholder price of $0.01, so we could see which prices had been replaced correctly.

The first challenge came when trying to get local prices for products in Closed Alpha, on Google Play Store, and in Test Flight on App Store.  It didn't work and this resulted in our in-app buttons showing the default $0.99 - which turned out to be very confusing for users - because it indicates something is purchasable, but really it isn't.

Once things are working in test, it was time to push to production.  In our first release version for App Store we missed attaching the in-app items to the version submission.  The binary passed, but none of the in-app products were available, because they weren't associated with the build and approved.

Our next iteration replaced the default $0.99 with helpful and informative "No Price. Try Later" message, in contemplation of someone being on a WiFi only iPad without the network, their purchases might work later when connected.  However, this doesn't get past Apple's app review (we got rejected with "price is not shown" issue), so we settled on the better (best?) practice of hiding any in-app purchase button unless that purchase was available.

Also, this story is difficult to tell in a linear fashion, because we could quickly push updates to the Google Play store along the way (sometimes two or three in a day), but the cycle time to find out the build was rejected for App Store was a day or two.  While we were solving in-app purchase issues, there were also minor bug fixes we wanted to get out.  So a week in, we ended up with a nicely working Google Play version, but an App Store version we couldn't update with the latest bug fixes because we couldn't get the in-app purchase passed review. [UPDATE: Next day, all sorted on App Store!]

This release was "soft-launch", only live in New Zealand, Australia, and Singapore.  However, we probably went public with our soft-launch about a week too early.  Next time I'd try having a week on the store under the radar to check things before telling friends!

After four-weeks in soft-launch, we plan to go live world-wide (this article having been written at the end of week one).

By Stephen McIntyre


Pixeljima on App Store

Pixeljima on Google Play Store


Solitaire Classic now in open beta (for Android)

Solitaire Classic by Redfox is now in open beta on the Google Play Store (in these countries: Australia, New Zealand, Czech Republic, Singapore, Spain, and Taiwan).

We would really love to hear your feedback to make the game better.

Opt in here: https://play.google.com/apps/testing/com.owairakasoft.solitairefree



Note: Solitaire Classic will be released to App Store for iOS devices a few weeks after the Android release is live.

Studio News - June 2017

Solitaire Classic

I'm really pleased to give a heads up that Solitaire Classic is set for soft launch on the New Zealand Google Play Store at the end of June.  Other regions and platforms to follow after a few weeks in soft launch.

We are using GameSparks back end for daily challenge, winning deals, leaderboards, and player profile data.  Working with them now on the go-live process.


Pixeljima™ 1942

A vertical scrolling shooter inspired by the classic Midway 1942 arcade game from the 1980's.  Six levels are built and the next piece of work is on being able to fly different aircraft with various upgrade options.

It is intentionally quite difficult - I can't make it past the start of stage 4 without upgrades. 

We have two game play experiments to try; a "panic start" to get the player into immediate action, and a "reaction finish" where the play needs to pull the eject lever after getting hit before crashing to save some of their progress.


Nakomo™ Kingdom TD

The graphics for the demo are done, and a proof of concept spike is running.  Completing the demo build is in the development queue.  Meanwhile, you can check out Kingdom: New Lands to get a sense of the game play style.

We will release on Steam via the Steam Direct process once it is ready.



REDFOX switches to Unity

Change is in the air at REDFOX HQ! On 12 September we heard from Marmalade (the cross-platform middleware we've been using for months) that they will no longer be supporting the Marmalade Platform from March 2017. We made the decision that day to move to Unity middleware.

Earlier in 2016 we build a simple Coin Flip app, with analytics and advertising, and published it to the Google Play Store and iOS App Store.  This was to prove our tool chain. We decided to use the same approach to validate using Unity.  By 23 September, we'd completed our new Unity Coin Flip app, with analytics and advertising - but also with localisation (English, Spanish, Russian, Philippines) of text and graphics, cloud build, and Unity's new Collab source control replacing our SVN source control.

Unity and C# are easier to develop in, have tons of online resources to learn from, and are widely used in New Zealand and the wider game industry.  Although using Unity does have an impact on install sizes and performance, the team is positive about the change. After our two-week re-tool and learning sprint, we're back into production of our upcoming titles.