Fixed and Flexible

Last week, I went to Amaze Festival in Berlin. It was fun to meet up with lots of developers from around Europe, and the event’s focus on the more artistic side of game making was refreshing.

In particular, I went to a talk by Jenny Jiao Hsia on prototyping her personal games. Interestingly, she had both a fixed art style and set theme (dieting) that she pursued throughout the many prototypes she made. Her aim in experimenting with different mechanics was thus to find how best to fit the theme and communicate her message, whilst still having a game that was fun, deep, intuitive etc.

18056954_10155253312747258_522062468082670765_n

 

(this was the best logo I could find for the festival…)

Whilst it sounds simple enough, I realised that it stands in marked contrast to my own approach up till now, of making games. Typically, when I sit down to prototype a new project, I have in mind a “game idea”. This idea has various things bundled into it: Mechanics, theme or setting, genre (in the sense of first-person-shooter or turn-based-strategy). And perhaps a story or art style as well.

Being a programmer, I then start with the core mechanic(s) and continue from there until I’m happy that this is a game worth taking into full production and spending to get professional quality art assets for. Or, when, as often happens, the core mechanic turns out not to be as fun as hoped, the whole thing gets tossed aside.

But perhaps, rather than getting rid of everything, I can take an approach more like Jenny’s. Pick a theme and art style, but then be super-flexible about the game mechanics. I’m usually terrible at letting go of a flawed game or failed prototype, and having now thought about it, that might be down to subconsciously thinking that some parts of the “game idea” weren’t so bad. Elements that could have work are being unnecessarily junked.

As it happens, I still have all the art assets from years ago when I made Executive Star. That game failed on multiple counts, but the art and theme were well received. Once Flight of Light is finished, I think it’ll be an interesting exercise to return to Executive Star and see if I can’t make a new game out of its salvaged remains. I can use the theme and art as a jumping off point for prototyping lots of new mechanics. Those fixed assets should also give constraints, in an almost game-jam like way, for fostering creativity. And hopefully, I can also bring in some of the criteria from my previous post when picking prototypes to move forward with into full products.

Too often I go to games conferences and events, and come away feeling motivated and raring to go, but perhaps without clear, practical, actionable tasks for harnessing that new found enthusiasm and knowledge. This time, at least, I have a plan!

Inseparable Marketing

Recently read BadgerHammer’s blog on video game marketing. Like them, I’ve been pressing all the marketing buttons prescribed by industry “conventional wisdom”, yet getting nowhere. This spurred me to write down some ideas I’ve had mulling in my head for a while now about indie game marketing.


Marketing is usually referred to as something game developers do during and/or after game development. As if it’s a parallel process to the nuts and bolts of making a game. It isn’t.

Way back when I was at school, I did business studies and learned about the 4 P’s – Price, Promotion, Place and Product. They are all interconnected, but the focus of most indies is on promotion and price.

Indies are oft advised to think about who the audience for their game is. This is usually an oblique way of criticising a game’s lack of appeal. However, it can be easily misinterpreted as a retrospective task. To figure out who might want to buy the game, after having already started, or even finished making it.

Go a step further, and developers can see which groups of people are responding to the game, and tweak the game here and there to make it more appealing. It’s an attractive idea, as it allows the developer to still make what they want, but also feel like they’re doing that “marketing” stuff.

In reality, the big changes in direction needed to do this effectively run up against a whole lot of resistance. They compete with the creative vision for the game, and the need to iterate on the core mechanics to find the fun. Added to that, most games aren’t coded with the flexibility to allow quick pivots. Then there’s the sunk cost fallacy at work – developers don’t want to ‘waste time’ ditching a large chunk of their game to go in a different direction.

At the other end of the spectrum, you can’t just arbitrarily pick a group of people and design a game for them. Fifty year old self-employed Mums in Hawaii when you specialise in pixel art isn’t going to fly. It also supposes that imaginary group are homogeneous – all have similar gaming tastes, habits etc.

Asking the Questions

The product – the game – is an inseparable part of the marketing mix. So how to square that with the need to make a fun game? For me, I start by prototyping game mechanics, then seeing which prototypes have the most potential for success if turned into full games.Is the core mechanic fun, does it have depth? Etc. I’m now starting to mix in business-related questions to that list.

Will the game look appealing in video form? With Totem Topple, if you were just watching the game, without having played it, it’s not at all clear what’s going on. With Flight of Light, it looks like a whole lot of other similar games, and without playing, it’s not obvious how it’s any different.

With Atlantis Dare, the disasters both grab the attention within a few seconds of watching a video, and clearly differentiate the game from the competition.

As well, with Atlantis Dare, I have a far clearer idea of who it appeals to. The game looks similar to Civilization and Endless Legend, and it’s fans of that 4x strategy genre who’ve been drawn to it. In testing, those players have played it for the longest. That’s helped validate the game mechanics, but also that there is an existing interested audience out there.

The next question being if I can actually reach those people. Where do they hang out? What sort of media do they consume? If the best way to reach an audience is through TV adverts, I don’t have the budget for that.

When one or more of those questions comes up negative, it’s time to drop the game. This is where I’ve struggled in the past personally. Arguably it’s easier to let go of a game when it isn’t that fun. Less so when I can see people are enjoying a game, but that it’s also unmarketable. My aim for the future is to get much quicker at getting prototypes to the stage where I can assess them. Creatively, moving on from a game is easier if, on failing to tick all the boxes, I’ve invested less time and emotional energy into it.

Where are They?

A note on Place though. In video games, this means platform (or digital storefront). For the last couple of years, I’ve been focused on console, as I think there is less competition on console. However, the experience on Wii U has been disappointing. For both Totem Topple and Gear Gauntlet, there was a mismatch with the console audience. Gear Gauntlet was billed as a Gamer’s game – Hardcore, twitch reactions, fast paced, no faffing around with story. Totem Topple, a weird stylised tower-defence game. Looking at successful indie games from other developers on Wii U, they tended to be narrative driven pixel art platformers – The Shovel Knights and Axion Verges of this world.

From a development point of view, interface usually dictates platform – Is this game better with a mouse, or on touchscreen or with a console controller? That shouldn’t change, but if the game can’t reach it’s intended audience because they aren’t on the target platforms, it’s reason enough to not continue that prototype into full production.

To be clear, I’m not saying to stop doing all those other things like contacting youtubers and press, building a community, being active on social media, and so forth. Simply to stop thinking of making and marketing the game as two separate things.

 

Not on the program

Maybe like me, you’re an indie game developer, and looking over at the imminent Nintendo Switch launch. A golden opportunity! If only Nintendo would let you onto their developer program, they’d have an extra indie game to help sell the new console. And you’d have a great chance to stake your claim to virgin territory on a new frontier of the ever more crowded video-games scene.

Fitting

Firstly, Nintendo have some good reasons for not just letting anyone on the program, at least prior to launch. Many of the Nintendo API’s and services are not going to have yet been finalised, or will have significant bugs in them. That means Nintendo have even fewer resources for dealing with a large number of 3rd party developers and the support issues they raise.

Furthermore, they need to be able to trust those developers who are on the program not to leak vital details of the Switch, thus damaging Nintendo’s ability to effectively control the marketing message around the console’s vital launch period.

Nintendo also need to ensure developers can actually finish the games to a high quality level in-time for the launch. Especially so since those titles that are released at or around launch will be under particular scrutiny.

As well, Nintendo need to ensure that they have both games which will appeal to their target markets and fit well with the marketing push being made around launch. And that also provide a broad enough range of experiences and genres to ensure the system’s game library has an appeal as an overall package.

Therefore, they are only going to pick developers they have a history of working alongside, who have a proven sales track record, and who are making games that fit with what they’re trying to achieve.

Mirage

However, it’s also worth bearing in mind that being a platform launch title is rarely the golden opportunity it at first seems. This is even more so for smaller and indie developers.

Clearly, the size of the market will be limited at first, as only so many consoles can be made and sold in the time immediately around launch. Moreover, the big budget titles released as (hopefully for Nintendo) system sellers at launch will dominate the conversation and the available free time of those who do have the system. Releasing on a Nintendo console in the same week as Mario-Kart or Zelda is not all that smart, especially given the (perceived or otherwise) notion that most hardcore Nintendo fans only care for Nintendo 1st party releases.

On top of that, the system itself will be being reviewed. These days that means not just the hardware specs, but the software services that modern consoles all have. Friends lists, achievements, social integration, etc. All that conspires to suck oxygen away from smaller titles.

Yes, the increased attention will land on all launch titles, but hoping that excited new console owners will go “ooh, I’m going to buy Zelda, Mario and… hmm.. maybe this other random indie game for $5 looks kinda cool?” It’s a very risky, one-dimensional marketing strategy.

Moreover, even if Nintendo were to have approached you last year (or earlier?), that’s not actually all that long to make and produce a quality, finished game. Chances are, that unless by chance, you happen to already be working on the right kind of game, at the right stage of development to hit the launch window, what appears to be a great opportunity is in fact a mirage.

Aftermath

For myself, even though I’ve made a number of games for Wii U, none of them have exactly set the world on fire. I was never going to have a Switch launch title. However, that doesn’t mean I’ve not thought about Switch development.

I figure that once Nintendo are ready to accept more developers onto their program (i.e. spring time / post-Switch launch), then I want to have a game ready to pitch to them, with a view to releasing in the traditionally quiet summer time.

And more importantly, have a game that solves a problem for Nintendo, or helps plug a gap in the console’s lineup.

Quick Reaction: Nintendo Switch

A number of people have chatted to me since the Nintendo Switch was announced a few days ago and been surprised by my ambivalence. This despite me making a big deal of working on Wii U for the last 2+ years.

I’ve never owned a handheld, aside from a brief few months when I had a 3DS. I bought it figuring I could play all those Nintendo and Japanese games I’d missed as a child growing up without a console or handheld in the house. But it wasn’t to be. The games were expensive and I was poor at the time, plus I was too busy with work to sink 30 hours into the epic JRPGs I’d picked up for it.

Since then, I’ve struggled to work out just why 3DS has sold so well, considering the rise of mobile gaming should be eating its lunch! I found this Guardian article very influential in my subsequent thinking about both handhelds and Nintendo.

The basic premise is that the 3DS is cute, both the form factor, and the games on it (like Animal Crossing). Plus in Japan, it’s seen as more younger kid-friendly than a smartphone. Nintendo Switch doesn’t appear to have any of those same qualities. From the marketing material, it seems to be aimed at lapsed Nintendo fans. The same people who remembered Pokemon from their childhood and downloaded Pokemon Go in record numbers when the series arrived on their mobiles.

tumblr_mg91isVOAw1qipfj6o1_500

Bringing those players from mobile across to the new device will be the real test of whether Nintendo Switch can succeed. The AAA gaming world isn’t interested in creating gaming experiences that transect devices. Neither are indies, who largely want to recreate the retro pixel art gaming of their childhood.

Therein lies an opportunity, to create a game that appeals to players beyond the traditional “core” audience, and that works to bridge the gap between mobile gaming and more involved console-like experience of the Switch.

neko-atsume-tips-tricks-01_w720Neko Atsume (pictured above) is a typical mobile type game: Lots of wait timers, micro-transactions, core game loop that can be played in 2 minutes whilst waiting for the bus. However, it’s also mind-bendingly cute. The internet loves cats, and moreover, people generally have a soft spot for pets. If I were going to make a game for Nintendo Switch, it’d basically be all about taking two or three of your cute virtual pets for walks and/or playing with them outside. At least that’d be the mobile version. Buy the Switch version and you can have a whole house full of different pets and a huge array of toys for them, things for them to do. (Maybe you work for a pet rescue centre as normal people don’t have 10 cats and 17 dogs in their house).

Unfortunately, I don’t have the money nor the team to go out and make such a game. I’m currently fully committed to finishing Flight of Light. That will take until February, just a month before Switch comes out. And after that, I’m considering going back to developing strategy games. A genre I have a lot of experience in making and playing. However, without knowing if the Switch has a touchscreen, it makes it hard to add it into development plans.

Also, I was a bit naive before with Wii U, in thinking I could make something innovative and that would really show off the unique capabilities of the GamePad. It’s easier said than done, and even if the motivation is there, the best ideas don’t necessarily come straight away. Plus I was burned with my experience of the OUYA, chasing a new platform and the opportunities inherent within. When in fact, I didn’t really have the resources to take that opportunity. It was just a mirage.

Nintendo Switch remains a big question mark for me. It doesn’t seem like a fit for me, but at the same time, having invested heavily in working with Nintendo on Wii U, seems a shame to let that all slip. Something to think about between now and February.

Wii U has all the toys!

The Wii U is reaching the end of its lifetime, soon we assume to be replaced by the as-still mysterious NX. I’ve spent nearly three years making games for Wii U in one way or another, and I plan to continue that for as long as Nintendo will let me. Why?

The Wii U has all the toys a game designer could want. Both touchscreen and buttons. Motion control as well as more standard console controller setup. This range of choice when it comes to input methods means a much wider variety of genres become possible. I grew up as a PC gamer and I love strategy games like Civilisation and Total War series. It’s just plain hard to do turn based strategy when all you have are buttons and sticks.

My first console game, Executive Star, was a case in-point. A local multiplayer strategy, made for the OUYA. Its design was based off board-games like Settlers of Catan, where trading resource cards between players is as simple as handing them across the table. Whereas for the console/TV experience, Executive Star had a great big grid that players would have to tab through in order to trade with each other – Use the left stick to go down to player 3, then across to the resource they wanted to trade. Press a button to increment the amounts. Then do same all over again for the other player’s half of the trade…

When making tower defence game Totem Topple for Wii U, the touchscreen allowed players to see all build options concurrently and pick which turret to build next with a tap of a finger. Rather than tabbing slowly through each option with buttons and menus. Adding in a Player 2, who could aim the game’s turrets, proved relatively painless with the Wii U’s support for extra controllers: Point the Wii Remote at the enemy you want to target and pull the trigger!

Two Sides

The Wii U’s much-maligned second screen may never have set the world alight, but it’s still by far and away the easiest way to build second screen experiences. Making games with multiple screens teaches a lot about what information to show or hide from players at which times. It also allows for experiments with asymmetry in (local) multiplayer gaming. Simply the fact that just one player has the GamePad, and the rest of the players don’t, has a huge impact on the dynamics of both the game, and the social interactions between players.

There have been a few brave attempts to explore the possibilities of second screen gaming on the Wii U. Affordable Space Adventures and ZombiU being notable examples, along with NintendoLand, which is still regularly discussed at length whenever I talk to Wii U owners about their thoughts on second-screen gaming. But it feels like the industry never really embraced the challenge.

In Motion

Motion control gaming is another area I feel has not been allowed to run its full course. For all the fuss about Star Fox: Zero showing off what could really be done with the GamePad, Splatoon gets far more mentions when talking to regular gaming fans about Wii U. Many fps players really love being able to use the motion controls to spin round quickly when shot in the back.

With my current project, Flight of Light, it’s always fun to hand a skeptical looking “gamer” a Wii Remote at a convention, and see their reactions upon enjoying the game more than they expected. Equally, the sight of a Wii Remote, sat on a table, waiting to be played, still draws in a particular crowd. Especially young kids and their parents (much to my frustration: Flight of Light requires fine motor skills and quick reactions, both of which kids below a certain age really struggle with. Often resulting in disappointment).

That said, it’s taken years and endless iteration cycles to really nail down the controls. And I’ve been lucky in that having designed for Wii Remotes from the ground up, the game translates to other control schemes (mouse for PC, 6-axis motion control for PS4). As motion control has made a bit of a comeback due to VR, it’s been useful to have that experience of what works, and a lot more of what doesn’t.

Plain Sailing

There’s still more toys in the box I’ve yet to play with. Amiibo, and NFC “toys-to-life” in general are one I’d particularly like to have a go with. And something I don’t think has reached its real potential yet.

It’s also worth pointing out that console development is not always plain sailing from a programmers point of view. And as much as it might be fun for game developers to mess around with their hardware, platform holders are running a business – What works from a technical perspective might be a security risk or cause legal issues (no standing on GamePads please!)

We can debate why the Wii U has struggled commercially till the cows come home. It’s certainly however, provided opportunities to do some really interesting things in game design, and hopefully will continue to be a great device in the future!

Flight of Light is currently on kickstarter. You can find out more here.

Why I’m making a motion control game in 2016

When I first started developing for the Wii U, it had already been struggling for the couple of years since its release. Nintendo were keen for more games to showcase the console’s GamePad, and being the bright-eye’d naive young developer I was, I arrogantly thought I could step up to that challenge!

After spending a bit of time getting the devkit and tools up and running, I realised the Wii U also supported Wii Remotes as well. I wrote out a list of game concepts for both GamePad and Wii Remotes to prototype when my current project was completed. Well that project fell through, and added to that, I’d got the devkit on a deferred payment scheme. So the clock was ticking to get a game finished and released, and make the cash needed to pay for the kit.

I decided to start with Wii Remotes, and an idea I’d had when first exploring the Wii U’s API’s. Wii Remotes at their most basic level output 3 floats to represent x,y,z rotation, and it seemed like most games simply mapped these real-world movement values one-to-one to movement in the game. Swing a tennis racket or aim a gun. Instead, I mapped those values to colour.


Change the hue, saturation and lightness. That was rapidly boiled down to just controlling hue in one dimension, as otherwise people would get lost in an ocean of grey, unable to work out how each movement corresponded to altering the lightness or saturation.

The simplest game I could make from that was matching colours. Players would be given a target colour, and have to rotate their Wii Remote in order to change their own colour to match. Point one end of the Wii Remote up and it outputs a 1. That translates into one end of the colour spectrum – red. Point the other end up, and you get 0, which translates as blue. Rotate between the two in order to cycle through the whole colour spectrum.

Flight of Light has evolved much since then, but in many ways, it is still the same fundamental game, underneath the many layers of visual abstraction that now separate it from those roots. Along that journey, I’ve been advised many times to change the game’s control scheme. Use discreet lanes, or discreet buttons, like guitar hero. Have the colours snap into solid bands. However, I’m glad I resisted those calls, as the game wouldn’t be where it is today otherwise. It’d be just another clone of the many rhythm games that have come before it.

Equally, having that continuous range of input has opened up paths that otherwise wouldn’t be there. Being able to race in-time to the music is now an integral feature, but may never have come about were it not for the way the game is controlled.

More over, it’s allowed the game to spread to multiple different platforms and control schemes. The game can be played with exotic devices like Kinect and Leap Motion, or more traditional mouse or console controller analogue stick. Or even touchscreens on mobile phones.

Why stick with motion control then, if more conventional controls are available? Firstly, motion feels the most natural to play with. That may be a consequence of having spent more time perfecting the control system with Wii Remotes than anything else, but for the most part, it’s intuitive. It’s a lot more approachable to non-gamers. When I take the game to conventions, people still associate the Wii Remote as something that let them be kinda good at games without needing to invest too much time mastering a complex rule set or sequence of actions to perform.

The downside is that Flight of Light isn’t nearly as kid-friendly as I’d hoped. Anyone below a certain age struggles to play, as the game requires fine motor skills and quick reactions. Little kids have neither.

Secondly, and somewhat related to the first point, I feel quite strongly that motion controlled gaming was never given the chance to fully run its course. It feels like most of the industry treated it like something outside of their comfort zone, and something they were all too happy to drop when the chance came. A lot of people bought Kinects and Wii’s, but how many developers stepped up to the plate to serve that audience?

I’m not pretending Flight of Light is anything revelatory or unique, but at least by experimenting with motion controls, I can say I’ve taken a different path to create something people have enjoyed.

 

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.

My Gaming Year

Inspired by this tweet from Edge magazine, I’m putting down my thoughts on video gaming in the last year.

The last year has been a bit underwhelming. I’ve come to terms with not having enough time between work and social commitments to sink 30 hours into epic open world games. Even so, no game really grabbed me and said “you need to play this!”

My job in the industry as an indie game developer, I’m probably more than a touch jaded at this point, but it was still disappointing to watch the various E3 presentations and think “none of this stuff is really aimed at me”. In contrast to last year, whereupon Mirror’s Edge elicited a “Yes!” and Splatoon, a “Hell Yes!”

The latter I dutifully bought on launch day and thoroughly enjoyed. As someone who had never owned a Nintendo system before Wii U, Splatoon was the first game where I didn’t feel disenfranchised at not having not played and grown up with the sequels. This year I actually bought and played my first ever Legend of Zelda game – A Link to the Past – on Virtual Console. It was quite fun! But also elicited the odd feeling of having played it before vicariously through the many games it inspired down the years. And being subconsciously aware of that as I played took the edge off it.

Though having said all that, Splatoon reminded me a lot of playing endless hours of counterstrike back when I was a teenager, which probably helped my enjoyment of it. I can’t really pretend I’m not immune to the nostalgia, just that it’s nostalgia for different games.

The other big wins for me were Endless Legends and Big Pharma, both of which I did find the opportunity to sink inordinate amounts of time into, on the occasions where I had a whole weekend free to binge game.

More widely, I played a lot of VR demos and games this year. I’m increasingly convinced VR has huge commercial and industrial applications, but that for gaming, it’ll initially only sell to a few million “core” gamers. Various VR games I’ve tried have all attempted some trick or another to get around or sidestep the problem of being unable to move without getting sick. I’ve yet to play a VR game that really works within the constraints of the device in that sense, which has hardened my skepticism towards the tech.

My other disappointment was Cities: Skylines. You have to be in the right mood for those sorts of games, and maybe when I bought it on Steam sale, it just wasn’t quite the right time. But it played almost identical to many of the other city builders I’ve tried over the years. After all the hype, I was expecting something a little different.

I also made an attempt to get into mobile gaming this year, but the games I played felt kind of missing something. On the one hand, Monument Valley was excellent, but I powered through it in under a day as I wasn’t expecting it to be so short. Conversely, I played Disco Zoo and Neko Atsume, both of which made for great little time killer games. But if my bus ride was more than 5 minutes, or I came back to the game more than a couple of times in the same day, I just ran out of things to do in the game.

The year isn’t entirely over yet. Last Christmas, I got a Wii U eShop card and bought a bunch of games on sale, a couple of which I had great fun with (in particular, Child of Light I completed before the holidays were over!) So here’s hoping to a future filled with more pleasant gaming surprises!

f2p needn’t be all bad

Whether you like or dislike the way any particular game uses f2p, there’s nothing fundamentally wrong with the concept.

For those not familiar, f2p stands for “free to play”, and is a shorthand for any monetisation system that gives the base game away for free, then seeks to make money through the purchase of additional stuff for the game.

That stuff can come in two main forms: “Consumables” covers things that have a one-time use in game, such as power ups or in-game currency. “Unlockables” are thing that can be used repeatedly, such as new levels or game modes.

price question

Unlockables are the easier to understand from a consumer perspective. I pay some money, and now I “own” the product I paid for. Not really all that removed from how games have always been sold. The difference being that the game is now atomised – split up into individual chunks of content, rather than simply sold as a single job lot.

This gives more power to the customer, letting them decide which parts of the game they want to play. If they’re just interested in the single player campaign, they pay just for that, rather than subsidising the multiplayer modes that they have no desire or intention to play.

From a developer/publisher perspective, it means they can see which types of content are more or less popular and concentrate on making more of that. It means they can get the game out earlier, then add content as they go. This helps both cash flow, and reduce risk, as if the game turns out not to be all that popular or good, they can cut their losses before having sunk vast amounts into making levels and characters for a game no one really wants.

Consumables by contrast are a little harder to grasp, as what they really represent is time using a service. In the past, customers might have inserted a coin to keep playing an arcade machine. They didn’t own the machine, but rather paid for the right to play on it for a certain length of time. The clever part being that the time length isn’t fixed, but rather depends on the player’s skill. This incentivises players to improve their skills at the game, so as to get more value per consumable purchased and used. And it sidesteps the feeling of resentment that the game is just for rich people, with no real skill, where you just “pay to win”. Whilst of course still letting people do exactly that.

Everyone wins, in theory. In practice, it’s very difficult for consumers to make an informed choices about their purchases. Developers usually have complete control over the in-game store and accidentally or otherwise, information can be obfuscated or left incomplete. In the past, independent review magazines and websites might have helped bridge the gap. But why spend time finding and reading a review when people can just download the (base) game for free and find out for themselves? With most f2p games, there are a vast number of items on offer, and those items are constantly being tweaked and changed by the developers, making reviews of each item impractical in any case.

It’s painfully obvious why developers take this attitude to f2p, but it really needn’t be all bad. My hope is that more small studios and independent developers get over their f2p hangups and instead innovate and push f2p in new directions. Whilst it doesn’t make sense for every game, f2p is the dominant model in mobile and PC gaming. I for one would like to see more discussion about how to improve f2p, and I hope to add my own experience to that in future games.

Technical: Unity to Android

This will be a semi-technical piece, in a departure from the normal things I write about. It was initially a reply to a facebook post, but having poured all my knowledge into a single, comprehensive reply, I discovered I’d misread the initial question posed. So instead I’m posting it here. The question I thought I was answering was “What should I know about putting my Unity game on Android”

There are a few odd little technical things that can crop up when you first switch platform to Android in Unity. Mostly it’s solveable stuff though and no more than a couple of day’s work to get a build running on an Android device (or less if you’ve already downloaded and set up all the Android SDK’s, installed java sdk, set up environment variables etc). You may also find as you release, certain devices have odd bugs that are unique to them. They’re usually fixed after a quick search of stackoverflow but not before some user has got pissed off and left a 1 star review. You can head that off to an extent by looking up the lists of the most common Android devices, and using them against services that let you remotely test on different devices. But you’ll still be getting crash reports from your analytics package and/or messages from users of the most obscure devices for months after launch.

The big problem is resolution and screen size. In Unity you can force the game to stick in landscape or portrait, so you don’t need to account for both. But really, you need to have designed the game and especially the UI to be flexible and work at any given resolution and dimensions. (I prefer to do all my UI layouts in percentages of width and height when possible, but even then, things like text being too long for its surrounding box can easily crop up).

unity_remote_android

The game needs to work with a touch screen interface as well. Unity has Input.touch, which is fairly easy to figure out and Unity’s in built UI elements will mostly pick up touch automatically and treat it broadly the same as a mouse click. Some things will likely break or need some fixing from you though (e.g. drag & drop. Mouse hover doesn’t make sense either in a touch environment).

If you’ve made the game to use console controls, the good news is that Android supports many 3rd party Bluetooth controllers and Unity will automatically pipe through that stuff into your existing code, again using the Input class! Bad news is few people bother to connect their controller as it’s a pain to set up outside the game and can be really flakey in terms of reliability. So you’re going to have to do horrible stuff like virtual dpads (not recommended) or have a major rethink of your whole UI, both for gameplay and menus etc. As said before, Unity’s touch input is easy to get, but having to retrofit code to use it has potential to be a right pain depending on what you’ve done before and how much UI code their is to modify.

Performance is also an issue for many people with older or cheaper devices. You could pitch the game at the “check out how shiny this game on my brand new super expensive xyz phone that I just bought is!” Or you can, in the web portal you use to upload your game to Google play (app store), specify that you need a minimum Android OS version. Usually, lower end phones can’t handle an OS upgrade, so you naturally filter them out. You can also filter so only owners of particular devices can download the game but the list is as long as my arm and 5 columns wide, and you’ll always disappoint some users. Plus so many new devices are coming out, you’ll be continually be adding to the list forever after. I don’t recommend that approach.

There is no approvals process. You just sign up for an account with Google, pay a one time fee, upload your game, and a couple of hours later, your game is available to everyone in the whole world, from Poland to Pitcairn island.

There is some extra effort to put in In app purchase or advertising API’s, but it’s fairly easy stuff with a bunch of tutorials on the web on how to do it in Unity. (Forget premium pricing on Android. It just doesn’t work). Same with leaderboards and achievements, which take maybe a couple of days to do tops. You can spend more time putting in analytics engines, and again, all the good ones have quick, easy to implement Unity API’s or plugins you just download from the asset store.

Different countries also have different expectations of how to pay. India for example is all adverts and no one pays by IAP, whilst other countries IAP is the norm. Many places don’t have credit cards or don’t use Google Play, so telco/carrier billing is the way. Again there are a myriad of companies offering to help with that, all with their own API’s that if they’re worth their salt, will run in Unity.

Piracy is an issue. Even with Unity, it’s fairly easy for someone to reverse engineer your game, get hold of all your assets or hack the game to circumvent IAP checks. Pirating premium games is as simple as copy-pasting the right file from someone who has bought the game. You have to be prepared that once your game is out on Android, you may be unable to stop people using everything in it however they want.

519QRk-AYWL._SX522_

Also, don’t forget stuff like Amazon app store and other odd non-google play 3rd party app stores, which can be more profitable than Google play (or totally useless depending). Don’t forget either Android TV stuff like FireTV or NVidia Shield or other Android set top boxes. They’re all a risk but could get you some good sales for just a few day’s work if your game is a good match. Again, they’ll all have their own API’s and plugins or packages you can download from the asset store or their websites, for Unity, with instructions, and should only take a couple of days to implement.

So overall, Android with Unity is easy to get started, but there are lots of little things to consider, depending on how professional / in deep you want to get.