Shiny Circles

Upgrading Flight of Light’s graphics had major and unexpected effects on the game’s playability

Previously, most of the game’s art was cobbled together placeholder assets, many of which had gone through multiple iterations of gameplay alterations, to the point where they no longer made sense or didn’t fit with everything else. That was fine for when the game was constantly changing. With the game’s recent change of direction, it also became clear the game’s graphics needed a major overhaul. However, having swapped out the old assets for shiny new ones, it quickly became apparent that the playability of the game had been impacted far beyond what we expected.

The biggest change came from trying to give the player a sense of speed. Pulling back the camera and widening the field of view as the player’s speed was boosted gave a great sense of acceleration. However it left the actual playable area of the game confined to a tiny portion of the screen.

The first instinct was to simply make the notes larger, so they could be seen from a greater distance. This worked, but the extra-large notes would frequently clip through the new scenery. The scenery also needed to be relatively close to the track to help with the sense of speed – trees and rock faces rushing past the player at close quarters.

Reducing the amount of camera shifting,combined with a slight increase in note size made the game much easier to play. No more squinting into the screen to try and make out the tiny notes in the centre. However, that really killed the sense of speed.

Actually increasing the speed (as opposed to simply the illusion of speed) helped, but also brought problems of its own. If corners were too tight, it would cause sudden jarring changes in direction. The notes would travel along the track so fast that the player would barely have any time to react. In the next blog, I’ll detail more about the process of re-making the track and forest level to fix that.

Adding in the new spaceship model also threw up unexpected issues. Being far bigger and, more importantly, wider, than the old placeholder model meant players would often think they had just clipped the edge of a note, only for the game to tell them they had missed. The game doesn’t use physics to calculate the collision of notes with the ship, but rather relies on timings, and on knowing what angle the ship is at versus the angle of the note.If the difference between the two angles is too great, the game will take that as a miss, regardless of what model is being used and how things may appear to the player.

Making the angle range within which the game recognised a hit had the knock-on effect of making the game that much easier. However, we’d noticed already that the effects used to show the player they had missed were already on the extreme side. Violent screenshake and asudden slowdown that really made players feel they were being punished harshly. We’re currently working on a way to make those effects more of a sliding scale, so that a small, occasional miss will still be noticeable to players, but not completely kill the flow of the game.

In the end, it’s been a combination of changes and small compromises in different areas made a huge improvement to the game’s feel and ease of play. And also a lesson learned about just how clousely coupled graphics and gameplay can be.

Change of Direction

Back in May, we pitched Flight of Light to a number of potential investors. However, none of them were particularly interested in the game. A disappointing experience, but on reflection came the realisation the game lacked focus. It felt schizophrenic, two competing personalities and styles, neither of which was really fulfilling its potential.

We decided to redirect attention towards the futuristic neon racer side of the game. The simple reason that it was the closer of the two to being finished. It’s also much more technically within reach to make a really good job of it. I initially spent a number of days trying to improve the algorithm for the unfolding triangles on the Autumn level. So that it could unfold into any given shape, allowing for a whole landscape to unfold in-front of the player. Sadly, it was just beyond my capabilities, and left me banging my head against the wall, going nowhere fast.

Flight_of_Light_byCrystalline_Green_neon_1_720p(from this..)

We’ve also had issues for years with trying to illustrate how Flight of Light is played through video. Incremental changes are slowly making it easier to learn the game without instruction. That’s having a positive knock-on effect that it’s also easier to work out what is going on just from watching the game. However, even if it’s still a little hard to work out precisely what the game is all about, if it looks good, that at least encourages people to want to find out more about it.

Graphics really do matter, especially when selling a game, and it’s easier to create a futuristic racing game than an artsy, low-poly procedural musical experience. Furthermore, the audience for the former is arguably larger and easier to reach with the sorts of tools available to low-budget independent developers like us.


(to this…)

The aim is now to release version one of the the game by end of January 2017 (or thereabouts). That will then provide a platform from which the game can potentially be expanded to include different styles and new modes of play.

Fly Faster – FoL Update

We’ve produced a short teaser trailer for Flight of Light. This shows the latest gameplay and much improved graphics. We’ve also updated the Flight of Light website and presskit with new screenshots and information about the game:

We’ll be going into more detail on how the game has changed in future blogs and videos over the next couple of months.

Elements of Damage

Introducing damage types into Totem Topple proved to be a relatively quick way of creating more variety and dynamism within the game. It allowed for new and interesting enemies to emerge later on in the game, and added an extra dimension to the game without burdening the player with too much extra to learn.

ice arrows 1

Change of Plan

Originally, the plan was that whatever damage type was selected when the player placed a beak (turret) or wing, that would be it’s damage type for life. However, this lead to issues whereby players would be stuck with a lot of ineffectual turrets that didn’t match the damage type of the latest wave of enemies. Or worse, not have enough supplies to build more beaks for the incoming enemy damage type, and be unable to collect any more due to being unable to kill those enemies!

Furthermore, it hugely complicated the tower building elements of the game. Since the game doesn’t have an undo function or any way to adjust the tower once built, having to account for different damage types in different places on the tower just put the game that bit beyond the player’s easy understanding. Placing mismatched wings and beaks on either side of a head because you forgot you’d changed damage types gets old really fast.

As well, firing in Totem Topple is done by simply aiming all the turrets at a single target. It doesn’t make much sense firing every damage type at an enemy when the player knows only a few arrows will have an effect. Especially if there are, say, both fire and ice enemies on screen, the player is better off letting the arrows shoot their respective damage types automatically. Rather than half their effective firepower by targeting a single enemy on which half their arrows will be ineffectual. That takes away the fun and point to being able to target specific enemies in the first place.

ice enemies

Limited Tension

Instead, having a single damage type fired by all beaks made both play and implementation that much easier. However, allowing players to constantly switch damage types made things too easy. It took away the challenge of managing damage types, as the player could just spam the button to change damage type to whatever.

The idea of giving the player a limited number of changes in a given time period came about more by accident than design. Copying the other buttons used to build heads/wings/etc meant the change damage type button inherited a cool-down timer. That on its own was too harsh on the player, as often they needed to cycle between a couple of damage types to get to the one they wanted. Giving them a small number of changes, that would then replenish slowly over time, gave just the right balance. Forcing the player to be conservative with their damage type changes, but not to the point of being punishing.

Ready, Aim, Fire!

Some years ago, I participated in a game jam using Eye Tracking technology. My team’s game was a horrible mess, but the eye tracking technology itself was far more responsive and accurate than I anticipated.  When it came time to port Totem Topple over to PC, I decided to have a go at integrating eye tracking, just for fun.

I used the eye tracking to let the player target enemies and shoot all arrows towards that chosen enemy until it was dead. After which the arrows would revert to their usual patterns until a new enemy was targeted. The result was really fun, to the point that people would forget the actual tower-defence and building aspect of the game, especially in Classic mode, and just have a great time shooting as many enemies as they could.


Later on, when creating the Wii U updates for Totem Topple, Wii Remotes proved a relatively straight forward substitute in for eye tracking (which Wii U doesn’t support). Pointing the Wii Remote at the TV and letting one player direct fire, whilst a friend or family member concentrates on building the tower and controlling damage type dealt, added a surprise extra social dimension to the game. In Off-TV mode, the enemies are seen on the Wii U GamePad, and the player can tap on the GamePad touchscreen to target them. Equally for the non-eye tracker PC version, players click with the mouse on enemies they wish to shoot.


Totem Tutorial the 3rd

(Epilepsy warning: Contains flashing images)

The tutorial system in Totem Topple is something that we’ve wrestled with over a number of iterations. In the launch version of Totem Topple, it worked, in the sense that it gave players enough of an understanding of how the game’s basic mechanics worked to be able to play. Similarly, the complimentary Help system worked well in allowing players to see the underlying stats and numbers for the various heads and enemies.

However, the fact that many players resorted to using the Help showed how much the game was lacking in visual feedback. Many of the minor changes made to Totem Topple for the 2.0 release try to give players a better sense of how their actions affect the game.

Circular Confusion

For example, some heads give a bonus to their neighbours, as indicated by the radius wheel behind them. Unfortunately, the wheel itself, whilst it is clear where it is coming from, it’s not clear what it actually does. There are no visible links or changes on the heads it affects. In fact, some players confused it for some sort of shield or radial attack.


Instead, now indicator arrows point between heads, wings and beaks, allowing players to see when any one element on the totem pole affects another. For health buffs, the affected heads gain a purple glow as a show of high strength, at least give some indication to the player that this head is different to others. However, we’re still looking at ways to make it even more obvious when one head or wing afftects the health of another.

Go Faster

When it comes to rate of fire changes, the differential between the lowest and highest rates was not big enough previously. Whilst the way the game was balanced, a higher rate of fire made a big difference to the player’s ability to kill lots of enemies, unless they looked really closely, players were unlikely to be able to tell that.

To improve this, firstly the balance of the game was changed so that low rate of fire really did mean one measly arrow every couple of seconds, whilst the highest rate creates an almost constant stream. Further to this, a higher rate of fire actually means the arrow physically moves faster. The arrows also gain “go faster stripes” or speed lines as they are called by illustrators. These emphasise the speed, but also give an extra visual pointer to show that things have changed when adding a wing, or that this head-beak combo is better than another.

rof motion stripes 1

Adding in a simple, two step animation of the bird beaks opening and closing every time an arrow fired also helped to give players an extra visual clue that one head/beak is a lot more active than the others. Especially so when arrows are flying in all directions.

beaks open


There were also a few combinations where beaks would have a zero rate of fire or arrows would do negative damage. To represent this, beaks would be closed, or fire broken arrows. Even so, this is probably a bit confusing for the player, so long term, we’re aiming to remove the need for these by rebalancing.

broken arrow 2

Flaming Arrows

For damage, arrows now start off black and then slowly turn more and more brightly coloured depending on the damage type being fired. The highest damage dealing arrows are then given spectacular trails of flame, snowflakes or water jets to really drive home that these arrows were specially powerful.

flame arrows 1


Another problem was simply telling heads apart from each other. It’s not intrinsically clear what a bear or a wolf or an eagle does or represents. Unlike, say, a scifi themed game, where the players can work things out using existing knowledge: That gun-looking structure is probably a turret, and the box that emits a glowing shield is probably a defensive mod.

Previously we’d coloured the heads according to function. Blue for defensive and orange for offensive. However, players didn’t pick up on that, viewing each head individually, and trying to work out what each did one at a time.


So we gave each one a unique colour. We also simplified the designs. A lot of detail was getting lost or creating a pixellated mess on lower resolution screens, which made the heads all blur into one. Simplifying the graphics also helped to make the overall game aesthetic look cleaner. We did the same for the enemies, using the original higher-resolution enemy images for the much larger, newly created boss enemies. This had the added bonus of making them appear more special compared to their smaller, plainer counterparts.


Another complaint from the launch version of the game was that the hitboxes were too small. Players would see their arrows whisk right through enemies, apparently failing to hit them unless the arrow hit dead centre. However, increasing the enemy hitbox size caused a different problem, whereupon enemies would often hit the second bottom totem head as they moved into the base of the tower. The game is programmed as such to ignore these hits (as it massively complicates the game and its coding if non-bottom heads / heads half-way through the stack can be killed). As a result, the new enemies would often completely fail to knock the totem pole down.

The solution was actually to make the arrow hitboxes significantly larger instead. Some re-balancing in other areas made sure that the game didn’t become too easy as a result.


Some aspects of the game didn’t get a mention in the tutorial, yet were not common features to other games in the genre. For these, rather than let the player figure it out for themselves as before, “interrupt” style tutorial messages would pop up informing the user of key bits of information the first time they did something significant but otherwise non-obvious.

For example, the placing of towers and turrets is a key part of most tower defence games, yet Totem Topple eschews this as one of the limiting factors of the game, forcing players to plan ahead a bit more than they might otherwise need to. That’s all very well except that most players didn’t understand that, especially with placing wings.

nextwing indicators_3

So when a wing is first placed, the game now informs the player both about the functions wings perform and where they will be placed by the game on the totem. Small graphical indicators have also been added to help players subsequently quickly see where the next wing will be placed.


The other related issue is with the height warning. Way back when the game was first created, it would let players simply keep building up and up ad-infinitum. However, this meant players could for the most part mash the place head buttons (at least in frantic mode), and it didn’t really matter what heads they placed, just how quickly they could throw them down.

To get around this, a mechanic was added in which players were punished for this mode of behaviour, spawning huge waves of super-hard enemies if they built beyond the red flashing warning line near the top of their screen.

punish spawn

This rightly confused the hell out of most players, who did not make the connection between building “too high” and the game suddenly ramping up to impossible difficulty levels. This threat of “angering the spirits” and super-hard enemies did not raise the tension of the game as hoped. Rather, the seemingly arbitrary nature of the players’ demise just as they seemed to be making progress left many frustrated and feeling cheated.

So we simply placed a hard limit on how high players could build. No more than 10 heads, and then the first time they hit that limit, an interrupt would inform them of the limit. The red warning line was kept in, but now as a reminder of that limit rather than as an easily mis-interpreted signal of impending doom.

Sharpening Edges

The game’s UI was also subject to improvements. On the tutorial, enemies would flash and buttons “ping” and scale to help cement the messages in the tutorial text, and better guide players towards the buttons they needed to press or things they needed to be aware of.

ui flashing enemies

Various factors meant we were stuck with using Unity’s less than perfect legacy GUI. However, even simple changes, like using a font other than default Arial also made a big difference. Or adjusting the UI buttons and panels to have angular corners to fit better with the angular background art style.

Overall, the various systems that help the player learn now feel like they do a much better job, working together and in different ways to convey information. There are still many more improvements to be made, but with the changes made, the game doesn’t leave players so lost and confused as it once did.

Rescuing Totem Topple

I was pretty gutted with how Totem Topple was received after it launched back in November, both in terms of poor reviews and poor sales. The first reaction is always to get angry, but looking back on the comments, I quickly realised that most of the criticism was justified. When placing myself in the shoes of reviewers or players coming to the game with fresh eyes, the responses to the game were perfectly rational.

One video of the game was particularly telling: I watched as the player died, died again, died again. Then they checked the in-game help, compared what all the different totem heads did. They devised a strategy, and I’m sitting there thinking “Looks like they’ve got it now. Should be ok this time!”. Only to be taken out by chance enemy spawn that really, they couldn’t do anything to mitigate. The video ended there. Although there was no commentary, I could almost hear them thinking “I did everything the game told me to and still died every single time. **** this.”

The proper, professional response to this is to learn the lessons and bring them to the next game, but otherwise move on. Instead, here I am, still working on the game 6 months later. A mix of sunken cost fallacy and bruised pride sucking me in, leading me to try and rescue Totem Topple. This is the story of how I’ve reached this point.


For those not familiar with Totem Topple, the premise is players add different heads, wings or bird beaks to their totem pole. These represent the turrets, walls and stats boosters of more traditional tower defence games. Demon spirit enemies then float down from the top of the screen, attacking the base of the totem pole.

When the bottom head on the pole has taken enough damage, it is destroyed, and the whole tower drops down one level. When all heads are destroyed, it’s game over.

King Jam

Totem Topple, like so many games these days, was born in the fires of a game jam. Over 2 days, myself and 3 fellow indie devs poured our efforts into creating a little mobile tower defence game at a game jam curiously sponsored by King, of Candy Crush Saga fame. After the jam, all the other team members had full time jobs, so I took on the task of polishing up our creation and putting it on Google Play. That took about 2 weeks, and whilst it got a smattering of downloads, it largely went unnoticed, another drop in the ocean app store.


I’ve heard a number of theories about why jam games do not make good candidates for full-production games. I personally subscribe to the idea that the best jam games really drill down to one central, super-polished mechanic, but as a result lack depth. Fun for 5 minutes, but without the larger game loops that keep the player engaged on an hour-by-hour basis, or make them spend their lunch break devising strategies for when they get home to the game.

Custom Game

This, plus a nagging feeling that the audience for console games would reject anything that looked too much like a “crappy mobile port” lead me to spend a lot of time creating a complicated “custom game” system. Players could tinker with all the variables behind the scenes, add new heads and enemies, re-order when different waves spawned, and so on.

I was encouraged when a couple of months into development, Nintendo announced Mario Maker. Suddenly, level editors were all the rage and the custom game feature felt like a part of a wider movement around giving players more control to modify and create content in-game.

screenshot 13-02-15 05

In retrospect, I was putting too much time into a feature that very few people were ever likely to actually use. It also allowed me to fool myself when it came to balancing the game, allowing me to say “Oh, well balancing the game is hard, so I’ll throw it open to players and they’ll appreciate being part of the development process, with a developer who is humble enough to admit (by implication) that they don’t know all the answers.”

When really, the game would eventually release without the Custom Game feature, owing to the difficulty of making the user experience feel really smooth. And due to the difficulty to keep it maintained every time something else in the game changed.

As for the balance (or lack thereof), that would turn out to be the biggest issue people had when the game did eventually launch.

Down to Earth

Six months after its inception, the game was “finished”, and I was busy trying to drag the it through Wii U lotcheck process. One of the reasons for bringing the game to Wii U was to go through the process at least once, with what I thought was a relatively small, simple game. Use the lessons learned in helping bring the bigger, more ambitious Flight of Light to the Wii U, whilst also hopefully earning enough money from it to pay some of the artists and musicians that game would need to get it completed.

And I have learned a huge amount about that process, to the point that I’m confident in taking on projects like porting Gear Gauntlet to Wii U, or in simply offering up my experiences and advice to other developers going through the process for the first time.

big indie pitch brighton 2015

However, I didn’t make things easy for myself, insisting on adding odd features like Miiverse integration, leaderboards and analytics packages. Whilst I was wading through all that, I took the game to Pocket Gamer Big Indie Pitch, at which the judges eviscerated the game for its various flaws.

I went away and decided the game needed some big changes. I removed the Custom mode and added in a “Classic” mode to replace it. The theory being that it was closer to more traditional tower defence games, and would be a good way for people to learn the game before going on to the original game, now rebranded “Frantic” mode.


When the game did come out, Classic mode had had far less time put into its balancing. Whereas most of the reviewers who actually played Frantic mode preferred it, universally, they all struggled with Classic mode. I’d pushed Classic mode to the fore of the game, placing it first on the menu, plus the name itself suggested it was a more logical place to start the game. Consequently a majority of reviewers took Frantic mode, which had far more time put into its balance, as more of a bonus mode, rather than the real core of the game.


The game also came out at a bad time. Right in the middle of the Christmas/holiday season, a day before two big 1st party Nintendo titles landed on the system, in a period full of the latest AAA games arriving on other platforms.


In terms of marketing, I stood on my virtual soapbox shouting at social media, but got nothing back. I wrote a bunch of blog posts about what I felt were interesting aspects of the game – It’s Navite American Inspirations, it’s day/night cycle, the differences between frantic and classic modes. Few beyond my immediate circle of friends read those posts, and certainly none of the reviewers picked up on the subtle things I’d included in the game, that to me represented the love and attention I’d put into it. Like how the music changed when the enemies started getting harder, then changed back when they got easier again. In fact, one reviewer claimed the game only had one single repetitive song on a loop. Which annoyed me intensely until I realised they probably never got past the first few waves, and so never heard the change.

Just Ship It

The other reason I gave up on making all those blog posts was that in the time between the game getting approved, and actually being available to buy, I’d run out of stuff to talk about. I thought I was being smart, storing up things to talk about with regards to the game. Keeping my power dry until the last couple of weeks before release. Only to find being approved does not mean the game is on the store next week (or anything close to that).

That exhausting process and a feeling like I’d already spent way too long on the game contributed to an attitude in the weeks leading up to the release of “just ship it”, and “so what if it was the wrong time of year”. I was determined to get the game out and into the world, and not be one of the long line of indies who never actually finish a game.


Another marketing fail was the video / trailer for the game. It just did not show what it was like to actually play the game, or even whether the player was trying to knock the tower down or build it up or quite what they were supposed to be seeing and doing.

Finally, I’d decided that getting youtubers and streamers to play the game was all the rage, and would make the big difference. So I planned to spend the couple of weeks preceding launch just handing out as many codes to as many people as I could persuade to give the game a try. However, Nintendo only gave me the codes 3 weeks before launch day, giving me just enough time to contact those specialist Nintendo review sites who I knew could make a real difference to the game’s reception.

Once their less than stellar reviews started trickling in, I immediately paused all my marketing plans, and determined that I must find and correct what was wrong with the game before continuing.

Christmas Patch

Another lesson learned the hard way was that patching is its own entire thing, and not simply a case of changing a few variables in Unity and pushing a fresh build to the game via Nintendo. In the heat of the game’s launch and the days after, I made a series of rushed changes to quickly re-balance the game and sent them off to be approved. The resulting patch did not arrive until end of January, long after the game’s fleeting moment in the spotlight of Nintendo fan interest had long since flickered out.


In fairness, a couple of reviewers did the game a decent service and took a second look, or waited till after the patch before giving their verdicts. But for it to have any impact on the game’s overall reception and sales, that ship had long since sailed.

Onward Totems

That brings me to today. The second patch is now out on Wii U, and the changelog is as long as my arm. New features, new enemies, improved tutorial and UI, and everything rebalanced from the ground up. The game is releasing in new territories (Australia and New Zealand). Taking advantage ofUnity3d’s cross-platform building, the game now runs on PC, and hoping now to pass Steam Greenlight. You can see some of the changes made in the new trailer below:

(You can vote on greenlight here:

Will it rescue Totem Topple? Financially, the chances of even modest success are vanishingly small at this point. However, the game as it is now, at least I can be proud of it, and give those who do take a chance with it a fun time.


Closing the Loop

In many ways, Nintendo have been playing catch up with the rest of the industry in the last few months, with their new account system and first mobile app Miitomo launching recently. Nothing exemplifies this more so than the website, which finally allows people to buy digital download games without having to log onto their console. For most consumers it’s a cool, if minor added convenience. However, for developers it represents a major fix to a once horribly convoluted purchasing process.

Essentially, developers and publishers can now link directly to a place where people can actually buy their games, no matter what device they are on. This opens up an array of new options for marketing eShop games. Whereas before, by the time the potential customer gets home and/or has time spare to log onto their console, they might have forgotten the game they saw advertised. Now, mobile and web-based ads become far more viable, as clicking through leads straight to the store page and the chance of an actual conversion.

price question

Currently, I suspect that most eShop sales, particularly of indie titles, come from a small pool of highly active Nintendo fans. Consider a well received indie game can struggle to rack up 10k sales, whereas Nintendo 1st party titles can shift tens or hundreds of times that. Clearly there is an audience out there and willing to spend in the right circumstances.

Smaller developers in particular can now promote their games directly from their own websites, from their youtube channels, twitch streams, email lists, social media channels, and so on. Even when demoing at games conventions, developers/publishers can still direct people to the nintendo website and in theory make a sale on the spot.


Of course, it’s not perfect, as potential customers can still be lost in the in-between steps from landing on the store page, logging in, entering payment details, and so forth. However, it’s still infinitely better than what was there before.

With any luck, indie developers in particular will embrace this and factor it into their less conventional marketing plans. Certainly for our games, when we do have a cool and unusual idea for promoting our games, we’ll have a much more flexible, versatile way to convert an interested person into a sale and (hopefully) satisfied customer.

Soft Price Control

Nintendo recently launched a new customer loyalty scheme in Japan, My Nintendo, alongside the release of their first mobile game/app, Miitomo. In the scheme, players are rewarded with “platinum” coins for various activities centred around encouraging engagement with Miitomo and other Nintendo services. These coins can then be redeemed to get discounts on certain games or other digital trinkets like background themes for the 3DS console.

However, like all good mobile games, Miitomo has a second premium currency. At time of writing, spending these “gold” coins gives much bigger discounts to a wider selection of games. Unlike other mobile games, Gold coins are earned purely by buying other games on Nintendo eShop for 3DS and Wii U. The higher the cost of the game bought, the more coins are gained.

Interestingly, there is a minimum price bracket of 500 yen (~$4.50), below which the player receives no gold coins at all. If as expected, most Nintendo fans and regular eShop customers sign up to My Nintendo, then any games below the minimum price will become less attractive, due to them not coming with any gold coin rewards.

In effect, it introduces a soft floor on prices. Developers/publishers could still opt to price their games lower than the floor, but understand that there would be a disincentive to do so.

Nintendo have said in the past that they see price deflation as a problem. The eShop has a wide range of titles, but many are low price, short, quick experiences. That makes more sense for the portable 3DS. For the Wii U though, there’s more of an expectation that games are longer, more substantial games that players can sit down and play in longer sessions relaxing at home in front of the TV. By introducing a disincentive for developers to price low, it should mean that smaller games get squeezed out of the market.

Arguably more worrying for Nintendo has been the recent trend of regular, deep discounting of eShop games by 3rd party developers/publishers. Putting a game on Sale not only makes it more attractive from a pure price vs value perspective. But is also one of the few ways to increase visibility post-launch, with possible eShop store page placement and listings in Nintendo fan press.

Presumably, if games give gold coins based on the discounted price, it’ll give developers/publishers pause for thought when considering a sale. Whereas at the moment, there really is no reason not to regularly put the game on sale.

Just how intentional these changes are is hard to gauge with Nintendo. And how much Nintendo fans will place getting gold coins above paying less for a title, we’ll have to wait and see. Still, it’s a different way of tackling the problem of price deflation as seen on mobile, or the culture of deep discounting, as seen on Steam.

From my perspective, might even consider raising the price of Totem Topple on the eShop. At least once the new update for it comes out with all the new features etc. It’ll certainly have the content to justify doing so, and may also be that by pricing the game at a relatively modest $2.99 to begin with has given the impression of the game being a bit lower quality than maybe it really is. It’s a decision for another day, and My Nintendo is not even out yet here in the west, but it’ll certainly be something to factor in for the future.

Gear Gauntlet Coming to Wii U

We’ve teamed up with UK based studio Drop Dead Interactive to bring their game, Gear Gauntlet, to the Wii U. It’s a fun but rage inducing 2D action arcade game that we think will be right at home on the Nintendo console.


We’ve been hard at work porting it to Wii U for the last few months, adapting it to work with the Wii U’s unique GamePad controller, integrating Nintendo leaderboard API’s and adding a few extras like Miiverse functionality, Wii U Pro and Classic Controller support. Over the coming weeks and months, we’ll be ensuring Gear Gauntlet passes all the requisite Nintendo checks, as well as promoting it, with the game eventually being published under the Crystalline Green Ltd. banner on the eShop.

However, that’s not to take away from the imagination and skills of Drop Dead Interactive, which have truly brought this title to life. We’re just proud to be helping it reach a greater audience.

An OUYA Story

Adventures on the Ground Floor

In the summer of 2012, I was down the pub after an Android meetup, talking to this guy who reckoned OUYA was a big deal. This was two or three weeks into their kickstarter campaign and whilst I’d read about it, it had kinda passed me by up till that point. Next day, I gave it a lot of thought, properly checked out their kickstarter campaign and decided to give it a shot.

Back then, I’d already been an indie game developer for over a year, struggling away making a game for Android in my own home-built java/openGL engine. Yes you may laugh, but I’d effectively come straight out of university to do this, driven by the narrative that the industry had come round full cycle, back once again to the days of bedroom coders. The app store meant anyone could make a million with the right game. Recently though, that faith had started to be tested. Going to Android conventions, talking with a lot of people, seeing the statistics. I was just a drop in the app store ocean.

OUYA was a chance to get in on the ground floor with a new platform, and if it took off, ride that rocket. It was a calculated risk for sure (as people at the time kept reminding me). A sort of all-or-nothing strategy, but better than the app store lottery. Plus my family, especially my Dad, were on my back about how I’d wasted over a year of my life doing the indie thing without success, and how I should quit and get a real job (which I’ve still not done!) OUYA was the last chance. If it didn’t work out, then I could at least say I’d given it my best shot and move with my head high.

I backed at the $700 “devkit” level, ditched the previous game I was working on (after 18 months! Though that’s a story for another day), and decided to make a new game just for the OUYA. I polished up my existing Android-based engine and set about crafting this new project.

By new year 2013, everything had gone a bit quiet. The buzz and hype had dissipated and the OUYA was for most, out of sight and out of mind. This was slightly alarming, since the devkits were due to be delivered imminently. I decided to throw myself into changing that. I joined twitter, started following and messaging anyone and everyone I could find about OUYA. Over a couple of months, I organised two meetups in London, with over 50 people at each one! With developers bringing along their little see-through plastic boxes, talking about and demoing their games. I’d never done anything like it before, and it was hugely exciting and rewarding to see all the hard work come together and be a success!

In fact I organised a third meetup in Leeds, but only a handful of people turned up. It was an exhausting experience, trying to drum up support both online and through repeatedly driving round an unfamiliar Leeds city centre late at night, going to meetups, finding a venue and so on.

I changed tack and started instead going to conventions and shows. I demoed my in-development game at an anime convention. At the time, I was the only indie there, in amongst all the comic book and t-shirt stalls with my basic stall and home-made setup, right opposite the shiny professionally constructed booths of Nintendo and Crytek.

I went to the enormous Gadget Show convention and was picked up by one of the researchers for the TV show of the same name. I went to their studios, told them all about it and my OUYA got on TV! I walked into a branch of the retailer, GAME, after talking to them via twitter, and arranged for myself and several other indie developers to demo their games in store!

The OUYA was my secret weapon. I used it to open doors and squeeze every opportunity I could from it, and it was a thrill to be able to do that. To take something and run with it, since the small startup that was OUYA Inc. was based in the US, with almost no presence in the UK what so ever.

I was even invited to do a couple of weeks contract work for OUYA, helping squash bugs in the time before the first wave of consoles were released to general backers. But I’d not really worked in that sort of SCRUM, daily-standups, team environment before. I’d just been doing my own thing as an indie, and found myself a bit out of my depth most of the time.

There were also a few own goals. I was approached by a company who did hardware benchmarking, and naively agreed to help them get their software running on my “devkit”. The results were not exactly cutting edge, and the fallout helped feed into the very negative narrative that surrounded the OUYA at the time.

As for my game, I had a very clear, immoveable deadline. The OUYA would launch in stores on this date and missing that would negate the whole point of making an OUYA game, which was to be a launch title on a new platform. I hit that deadline with a few days to spare, something I’m still immensely proud of.


The Hate Awakens

It’s hard to pinpoint where the hate for OUYA first started. The internet always has its garden variety trolls who will pick on whatever, but even to this day, people who never even used an OUYA still seem to take a measure of delight in hammering down on it. I think a couple of things in particular did for it.

Playstation 4 was announced with much fanfare just a month or so before the OUYA was due to be delivered to the bulk of those who backed it at the reward $100 tier. PS4 was everything that OUYA wasn’t. Big, powerful, shiny and polished. This was the real deal, was what gamers, tired of the ageing previous generation really wanted. More of the same, but faster, better looking, and with all the mod-cons: Friends lists, leaderboards and video sharing etc.

PS4 and later Xbox One’s appearances also reignited the age-old console wars, and OUYA was a convenient target to which both sides could be unified in deriding.

The other big factor was in part of OUYA’s own making. On the kickstarter page, there was a due date for the console to be delivered. Backers expected their OUYA’s to drop through the letterbox on that day. OUYA, for whatever operational reasons, took that day to be the day when the first batch of several hundred units would leave the factory and start the long process of winding their way to people’s homes.

The alternative – delaying delivery – would have doubtless caused an almighty furore, However, the communication was not handled well at all. OUYA’s customer support melted under the pressure of 60,000 people all asking why their OUYA hadn’t arrived, all at the same time. The lack of response that resulted lead people to further complain, and so compound the issue. And then shortly, take their complaints online to find they were not alone.

There were some other factors as well. The bombastic claims about “The Revolution will be Televised” probably did more to hinder than help in the long term, feeding the perception of over-promise and under-deliver that turned many off from OUYA. The company, in my opinion, was also not able to separate the messages it sent to the investor community, from those it sent to the consumers. OUYA was trying to be a disruptive force, and needed to hype itself up to attract investors. But such was the intensity of the spotlight on the company, that those interviews on Bloomberg or Forbes aimed at securing further funds would get repeated by gaming sites and thrown into the internet echo chamber.

After the debacle with delivering to backers, it was all downhill. The circle of toxic negativity became infectious, spiralling into one big hate-fest. Even I was caught up a little by it. Spending all day trying to defend the OUYA and reason with people, you pick up on a lot of their grievances. A month or two after OUYA’s retail launch, I wrote an article entitled “The Revolution is Dead“. In it I argued OUYA had lost the core gamer market and should pivot towards more casual consumers. Of course people just read the first half or even just the title, and I think a number of people at OUYA who I’d previously got on quite well with felt hurt and a touch betrayed by the article. I managed to undo an awful lot of that good will that I’d worked so hard and enthusiastically to build up.


The Lean Startup

I’m convinced OUYA were following the Lean Startup by the book. Release a minimum viable product (MVP), find a product-market fit, and build from there. It failed for three reasons:

1). Gamers weren’t expecting an MVP – Look at the history of video games consoles. It’s only really in the last couple of generations that consoles have been online, and liable to get occasional updates and patches. Before that, and still to this day, consoles and games are judged as they are found on day 1, and that perception sticks for the lifetime of the product. They don’t magically get better after you’ve bought them.

Most consumers looked at the OUYA, especially in marked contrast to the PS4, and decided “this looks a bit shitty”. And that was that. End of story, as far as that consumer was concerned. When it first started turning up in the wild, the interface was nowhere near complete. It was being tested and tweaked and underwent a number of major revisions in the months after release.

You could argue that OUYA was a bit before its time, and that gamers are slowly getting more used to the idea of games and platforms as services, rather than products. Or equally, you could argue OUYA simply misread their audience. Either way, once they started getting 3/10 reviews, there was little hope of coming back from that.

2). The Anti-Fit - The nature of an MVP is that it’s not necessarily released with a specific solution or target audience in mind. It’s a product looking for a solution. This was one of the criticisms levelled at OUYA at the time of its launch. Actually that’s fine, because, with the right attitude / setup, the idea is to let the market and the real users help guide development to eventually find that fit. That point where it clicks and starts gaining traction. (Or so goes the Lean Startup theory).

Most companies start off with a few customers / users and grow from there. OUYA on the other hand went from zero to 60k customers overnight. They almost certainly weren’t expecting more than a few thousand early adopters if you look at their initial kickstarter target amount. They were left trying to do the whole process backwards. To work out what exactly their newly found customers were expecting from a product that mostly existed just on paper.

The problem was, different people had read different things into what the limited and slightly vague campaign material had said. It was an indie games box, it was a TV/media streaming box, it was a device for tinkerers and android modders. Or it was just something that seemed cool and was an impulse purchase, made in a rush of excitement.

OUYA had to narrow that down over time, as it couldn’t be all those things, and with each turn, instead of getting closer to product-market-fit, it lost another group of users, who in turn became disgruntled complainers on social media.

3). Scaling and Kickstarter – The other problem with going from zero to 60k customers in an instant is in scaling the business correspondingly. In OUYA’s case, this hit home when their customer support system was overwhelmed in the days after they started shipping to backers. When a business grows slowly, you can see when the customer support department is starting to struggle. When their KPI’s begin to drop, take action. Or anticipate when they’ll no longer be able to cope given current growth in customer numbers. And so train up more support staff in advance.

Not in OUYA’s case, where their growth was represented by a single big step, both in terms of numbers, but also in terms of how much support they needed. When backers were waiting for the delivery deadline to arrive, they had no reason to contact OUYA. So to have hired a bunch of staff, sitting doing nothing, would have been pointless. Equally, if they had have hired large numbers, and the anticipated demand had failed to materialise, they would have faced accusations of wasting money, ironically from the backers/customers who fronted that money.

Ultaimtely, all these things fed into the perception of the console, which in turn fed into sales and developer support (or lack thereof).


A Legacy of Sorts

OUYA may live on in name as the western publishing arm of Razer Forge TV, it’s staff and technology integrated into that product, but the box, and in many ways, the dream it represented, are no longer.

It’ll always retain at least an odd place in video games history. A sort of “do you remember that!? Hah!”. How much it contributed to the big 3 console makers opening up their platforms to indies, versus how much it just rode the existing wave of indie games popularity is open to debate. And wherever you stand on the issue of quality control and which games are or aren’t allowed onto a platform, the OUYA certainly delivered when it came to making life easy for developers.

OUYA probably can claim credit at least for, if not inventing, then certainly popularising the notion of microconsoles. Those that came after it, the FireTV’s and AppleTV’s of this world, probably would have happened anyway, but undoubtedly the makers of those took a long hard look at the OUYA to see what practical and technical lessons it could teach.

For myself, my OUYA game didn’t sell well at all. It was a great achievement to have both hit the deadline, and in doing so, release my first commercial game. But between OUYA’s own issues and some fairly fundamental game design flaws, it never really stood a chance. In hitting that deadline, I kinda skipped out on all the usual testing and prototyping, instead going for a reskinned clone of an existing board game, which I falsely believed would translate over to the console format. It didn’t, and to say I was a bit foolish would be an understatement, going from being a lifelong PC gamer, having never owned a console myself, to trying to make a console game solo in 9 months.

In the aftermath, I attended a talk where each of Sony, Microsoft and Nintendo laid out their respective “we’re indie friendly” stalls. I now do console porting, and make games for the Wii U, with plans to expand into PS4 later this year.

I learned a lot in my year of OUYA. Experiencing the internet hate, seeing a tech startup go from boom to bust at close quarters, project management and hitting deadlines, experiments in marketing. Above all I learned from OUYA that perception is everything.