Wearing Pixels

Coming from a video games background, the world of fashion appears otherworldly. A place full of lurid colours and fantastical designs springing off the pages of glossy magazines and posters. It often makes games look monochrome and unimaginative by comparison.

But the fashion world is also distant and disconnected from games. So when the chance came up to attend a Digital Fashion workshop in Prague at the start of the summer, I was intrigued. Could technology provide a bridge between these worlds? How was technology changing and being used in this different, but highly creative industry? Here’s what I found.

Hardcore Tech

Soon after the workshop started, I was introduced to a program called Clo3D, which allows fashion designers to create digital garments. On the one hand, it lets designers sketch out the traditional 2D patterns (templates) used to make and manufacture clothes. But, it’s real power lies in then giving preview of how those clothes will look in 3D, as worn by an avatar. Clo3D effectively simulates the folds and drapes of the cloth in real-time, meaning designers can see how their creations will look and move around on the wearer, before ever needing to cut and stitch a single piece of real material. It’s even possible to design garments in the 3D preview view, and then convert back to 2D patterns, for printing and making the clothes for real.


As a programmer, Clo3D impressed me a lot. It produces professional industry quality results whilst solving some very difficult maths and programming problems. Simulating different types of cloth / fabric in real time in a convincing way is definitely at the hardcore end of algorithm design and optimisation.

Hacking Concepts

I could see all these creative people making cool garments in Clo3D and similar programs. But then all they could do with them, it seemed, was just make a rendering of the clothes. Or export a static 3D model. That was no good if we ever wanted to arrive at our cyberpunk future of wearing digital clothes.

Coming from the technology side of things, I approached the workshop a bit like a hackathon or game jam. I wanted to produce something tangible, or at least try to make something and see if I could learn from it. Explore the space where fashion and technology intersect.

Since the theme of the workshop was “wearing pixels”, I set that as my goal. To see if by the end of the weekend, I could allow someone to “wear” a digital garment. To do this, there would be three parts to my plan:

1). Getting clothes others had designed into a general purpose package – in my case Unity3d, since that’s what I’m most familiar with.

2). Visualising the clothes on a person – To wear pixels, the wearer and others around them need to see the pixels somehow.

3). Giving the clothes life – To really feel like they were being worn, they should react and move in response to the wearer’s movements.

My original plan was to have the wearer see their digital clothes by way of an AR headset. When they looked down at themselves, they would see the digital garments superimposed on their body. (With the view of what the wearer was seeing duplicated on a monitor or TV for spectators). When the wearer moved their body, a Kinect (v2) sensor would track that movement and update the clothes to move correspondingly.

I figured out the easiest way to do this would be to make a “multiplayer game” in Unity. In this game, Player 1 would be a laptop + Kinect pointed at the wearer. The Kinect would track the wearer’s movements and use that to drive the movements of Player 1’s avatar in the virtual game world.

Player 2 would be the AR headset of the wearer, displaying the virtual game world superimposed over reality. In this way, the wearer would see Player 1’s virtual avatar moving around the world, copying their movements.

For the clothes, they would first be exported from Clo3D or wherever as fbx or obj models. Then physics added back on to them by applying Unity cloth physics components to the models. And finally placed onto Player 1’s avatar, so that when the avatar moved, so would the clothes.

Getting the wearer to stand a known distance from the Kinect, plus a bit of maths, would ensure the virtual world and real world lined up: Player 1’s avatar would appear over the top of the wearer’s own body. Finally, making the avatar, but not its clothes, invisible, and the wearer would see just the digital clothes being worn by them, moving when they move.

Purple Tai Chi Flags

Given the workshop was only 2 and a half days, I was very proud that I managed to mostly execute on the plan! I mashed up the demo project of off-the-shelf multiplayer game engine Photon, and amazingly, it played nicely with both the Kinect and the AR headset.

I ran out of time to get a proper 3D model moving with the Kinect, leaving the avatar as just the Kinect’s debug “skeleton” lines between the different joints and body parts. And I never got round to doing the maths for getting Player 1’s avatar to line up with the wearer’s body properly.

The result was a skeleton of purple lines and grey cubes, that the wearer could control with the Kinect, and see a short way off as an AR hologram in their headset. After getting various other workshop participants to try out the contraption, people seemed to actually prefer having the avatar not directly on themselves, treating it like looking at oneself in the mirror.

Wish I'd taken more screenshots during the event...

Wish I’d taken more screenshots during the event…

The network connection to the Photon multiplayer servers was also quite slow. The wearer would move one of their limbs, and their avatar would respond about half a second later. This may have been because of the crappy wifi connection at the workshop, or because I was using the free trial version of Photon. But either way, it helped slow down the whole experience and encouraged wearers to do more Tai Chi style moves, and less frantic disco dancing.

As well, the digital clothes themselves proved both a failure, and a happy accident. As a test, I made a simple plane (square) of Unity cloth physics, and attached it under the arm of the Kinect skeleton avatar. Once the wearer started moving their arms around, this square acted a bit like a flag, or the muleta (red cloth) a matador uses during a bullfight. It proved much more interesting to wave around than the “proper” garment I added: A simple Clo3D-made t-shirt I had placed around the core of the wearer’s body. Unlike the flowing plain square, the t-shirt jiggled around glitchily at best, and at worst, scrunched up into an unrecognisable jumble of pixels.

Quality That Never Came

After the workshop, I spent some further weekends trying to build on what I’d made. Without the time limits, I managed to get a male and female avatar to move around controlled by the Kinect. I made some clothes of my own in Clo3D, specifically designed so that importing them into Unity3D and adding cloth physics would be easy. And I spent ages tinkering with capsule and sphere colliders in Unity, trying to get my clothes to roughly stay on my avatars and not clip through them too much.

However, for all my extra efforts, the results never looked more than proof of concept. Usually with games, you can find some good smoke and mirrors tricks for making things look presentable. Or you can see that with the right application of skilled artists and programmers, the project will eventually reach a good level of visual quality. This was not the case for my wearing pixels project, and that proved quite disheartening. Our cyberpunk future is still some way off, at least for bedroom coders like me.

Photoshopping Fashion

This forced me to take a step back and re-think my approach. In the course of the workshop, we shared and discussed the work of many different people and projects that fell under the broad “digital fashion” umbrella.

In particular, I was very taken by the Digital Collection by Scandinavian fashion store Carlings. They designed a line of digital clothes in Clo3D (or whatever other program). But rather than print out the designs and make them for real, they instead got customers to pick one of the digital garments, and send in photos of themselves striking a pose. The designers would dress an avatar in Clo3D in the digital clothes the customer had bought. And match avatar’s pose to the pose of the customer in the photo. Next they took a screenshot/render, and cropped out the avatar and background, leaving just the clothes. Lastly, they pasted the clothes onto the customer’s photo. The customer got back in return the photo of them now magically wearing the digital clothes.


Initially, I thought this was a bit of a cheap trick. Aside from designing the clothes themselves, it was essentially something so simple, even I could do it with my rudimentary photoshopping skills. I started to think up how this could be automated. Using machine learning to detect poses in the photos sent by customers. Having a script to control the camera and avatar posing in Clo3D. Take a screenshot and use edge detection algorithms or again, machine learning to pick the clothes out of the screenshot. Apply some light feathering, paste onto the original photo. Voila!

It was only after struggling with my Kinect experiments that I realised I was missing the point. The Carlings Digital Collection was simple and effective.

Wear Next?

That’s not to say there aren’t others out there trying to solve the difficult technical problems I struggled with. However, they tend to have VC money or a PhD in Mathematics. Or both, which I don’t.

Moving forward, I want to make a “fashion game”, using the skills I’ve already honed, plus the new knowledge and connections I made at the workshop. Of course that raises the question of what a “fashion game” is, but that’s a fun question to answer for a future blog.

The Colour of Light

Apparently I wrote this blog when Flight of Light was launched way back in August 2017, but for some reason never published it. So here it is, looking back at one of the key aspects of the game’s evolution over its 3+ years development time!

Flight of Light was developed using an organic / evolutionary design method – At each stage of development, I took the work-in-progress game to a lot of different events and conventions. Allowing its design to be guided by feedback and suggestions from those who played it. During that process, one aspect of the game’s design came up time and again. In conversations with players, it’d usually go something like this:

“So, this game is all about matching colours?” Indeed. “Well actually, I’m colourblind. So how does that work for me….?”


The above picture gives an approximate idea of how people with Protanopia – one of the most common types of colourblindness – see colours differently. About 1% of men are colourblind, with many more having some reduced range of colours they can easily distinguish between. So it made sense that when showing my game to 200 odd people over a weekend at a games convention, statistically at least, one player would be affected.

A quick search of the internet gives plenty of good advice and examples of how to adapt a game so that colourblind people are not at a disadvantage. However, due to the aforementioned organic game design method used for Flight of Light, once I started considering colourblindness, it actually had a deeper impact on the core game design itself.

The game as it is today

 As the game looks today

Flight of Light is a rhythm game in which players travel on rails along a rollercoaster-style track, shifting from side to side in order to hit coloured objects coming towards them on the track. The objects hit in-time to the music/beat, and the closer the player is to hitting the objects dead-centre, the more points and bigger the speed boost they get. (Think Audiosurf but with motion controls).

However, the game started off as something very different: Way back in the early stages of development, players would be given a colour that they would have to match, using a colour picker, within a time limit. The closer to the colour they where when the time ran out, the more points they earned. (In the picture below, the target colour is on the right. The bar on the left is the colour picker, with the white selector indicating the player’s current colour. The player would move the Wii Remote up and down to move the selector up and down the spectrum bar and so change their colour).

In the beginning

 In the beginning…

This was problematic, as for colourblind players, two different colours could look identical, with no way to tell which was the “correct” one. The immediate solution was to only use colours that were easily distinguishable (for the most common types of colourblindness). So rather than use the RGB rainbow colour spectrum – red to green to blue, and whatever was in between – the game could use any colours and simply blend between them. Purple to yellow to blue to red for example.

However, the blend in-between colours were often a problem: Half way between, say purple and yellow could look very similar to half way between yellow and blue. When the game randomly selected one of these in-between colours as the next target to match, it caused confusion for all players.

Next idea was to design one special colour palette by hand, where everyone, including colourblind people, could unambiguously tell the difference between all the colours on the chosen spectrum. It worked great from a technical point of view. Colourblind players could play just like anyone else!

You can see the results below. (By now the bar had evolved into a colour wheel and the target colour into coloured blocks on the rollercoaster track):

Protanopia colour scheme

 Mustard blue and greyish-yellow.

Trouble was, colourblind players wanted to play the same game as everyone else. They didn’t want to be forced to play the “special” palette, as it just highlighted their disability, rather than taking it out of the equation. Moreover, colour-blind or not, people found the scheme I’d chosen downright ugly!

This became the catalyst for a series of design changes. Firstly, I flipped round how the colours the players were asked to match were selected by the game. Previously the game would have 3 or 5 colours, blend them together into a spectrum, then pick a random point along that spectrum.

Instead, the colours the players would have to match would only ever be the 3 or 5 or 8 pre-determined base colours, rather than the in-between colours.

Initially, to keep the game challenging, and still use the continuous range of input from the Wii Remotes, the colour spectrum was retained, now as a colour wheel the player rotated around their avatar. However, the game continued to evolve. The blocks were replaced by coloured segments pointing to where they were on the colour wheel around the player (see below). And from there, the colour wheel was itself replaced, with the player’s avatar moving side to side to physically hit the coloured blocks.

Evolution of the game's UI

 Evolving the game

The game still has its issues: Players can customise the colours before a game, and each coloured object has a unique pattern to help distinguish it. But some of the default colour choices aren’t the easiest to tell apart, especially on hard mode, where there are 8 different colours in total.

Flight of Light had many different, quite separate influences. But undoubtedly it’s course was altered in no small part by considering the needs of colourblind players.

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.



(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.


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.


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.


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.

My year as a Totem Pole

It’s been a year since Totem Topple came out, and six months since the patch that fixed it, so feels like a good time to take a step back and analyse what went right and wrong with the game.

The fact that it had to be extensively patched last summer attests to the issues with the original version that launched on PC and Wii U back in November 2015. You can read more about the making of the game, how it faltered, and efforts to rescue it, here.

However, I want to dig into the game design itself. For those unfamiliar with Totem Topple, it’s a tower defence game in which you literally play as a tower, in the form of a Totem Pole. Players select which heads to add to their Totem Pole. Each head on the totem pole has different abilities and stats. Some are turrets, others are heavily armoured or give bonuses to other heads:

I’m a What?

There is an immediate problem even with explaining the game. It’s not obvious who you are actually playing as. Totem Poles are inanimate objects, so it’s difficult to conceptualise being one. Nor do the individual heads have any character or personality or appear to be alive or anthropromorphised in any way. It might make sense if the totem pole was being built by someone, a tribe say, scurrying around at the base. But the game gives no indication that this might be the case.

It’s not clear who or what exactly the enemies are either. Nor what their motivations are for knocking down the Totem Pole. On occasion, some people watching the game’s trailer even thought they would be playing as the enemies, attacking the Totem Pole!

Equally, why do new heads appear from the sky and land on top of the Totem Pole? Usually Totem Poles are made from a single tree trunk, rather than separate blocks.

Furthermore, why do the enemies attack the base? It makes sense from a design point of view as it means enemies have to pass by all the turrets first. Plus the oldest heads are attacked first, meaning players have time to build new complex structures without feeling under attack constantly. Having the top attacked would mean mistakes or choices from early in the game, when the player might not have enough resources for an optimal setup, would linger at the base of the pole.

But having the base attacked instead makes no sense from an outside perspective. Once the head at the base of the Totem Pole is destroyed, players might reasonably expect the tower to tip over as physics (or the game’s name) might suggest. Rather than the whole tower falling down vertically by a single head’s height, as actually happens.

Probably a bit of story and exposition could have helped at least some of these issues. Even then, anyone who skips the story or doesn’t really bother with the narrative would be left somewhat lacking in agency / motivation. (It’s quite common for some players to want to just jump in and get their hands dirty when playing a new game, then worry about the why later).

This is further hindered by the art / theme. Players might be expected to come with a bit of background knowledge from the real world or playing other games. Shields = defence, swords = attack. But in Totem Topple, Bear = ??, Owl = ??. In fact, most of the heads are damage or defence modifiers, with the actual shooting done by the bird beaks attached to the sides.

Say instead, players are building and defending a spaceship, rather than a Totem Pole. Then things are a little easier. A deer becomes a “shield generator” and a bird beak becomes a “plasma turret”. I still stand by the decision to go with the Native American theme. Where the majority of games are set in space or medieval-fantasy land, having something else can help a game really stand out in the market. And I’m glad in the original game-jam where Totem Topple was born, we did manage to find a theme with a strong aesthetic, and that made sense for the core mechanic. In hindsight though, it brought as many problems as it solved.


The genre was another area where Totem Topple eschews tradition. It’s ostensibly a tower defence game, but attaching that label brought with it player expectations that simply weren’t matched by the design.

One case in point is the lack of geography in Totem Topple. There is no decision as to where to place the next Totem head. It will always be on the top of the pole. This simplification I feel works quite nicely, as it lessens the sharpness of the learning curve. In many tower defence games, poor placement in the early game can really harm the player. There’s no map to scroll around either. The whole game fits onto a single screen with ease. And there are simply less turrets to worry about. No complex mental calculations of “I have 6 plasma turrets and 5 railgun turrets and 8 beam turrets, so I need an extra flak turret and maybe 2 more power generators”.

That said, learning the nuances of a particular map can be one of the more fun aspects of some tower defence games. And where Totem Topple falls down in the simple / elegant stakes is with the wing and beak placement. It’s not at all intuitive to have the side-parts placed on the next-highest free slot on that side of the Totem Pole. (Even saying that sentence is a bit of a mouthful).

Another example of moving away from tradition is with combat in the game. In a normal tower defence game, turrets auto-aim, shooting enemies when they come into range, before turning to aim towards them until dead or out of range again. Whereas in Totem Topple, they simply shoot a constant stream of arrows horizontally until pointed by the player at a specific enemy.

I actually quite like this concept. By leaving the turrets to their own devices, they provide a screen against enemies that wears them down as they pass. Rather than having strong enemies suck up all the tower’s firepower whilst smaller enemies can just waltz through, as happens with many tower defence games. (As if whoever is manning the turret is completely unable to prioritise. To make an intelligent decision to just stop shooting that bullet sponge for just a second in order to kill the fast, weak, kamikazi enemy that is about to get through).

In Totem Topple, players can choose to target an enemy if they can see one is nearing the bottom of the tower or is taking more damage than just one side of the tower alone can handle. Then whilst making a decision on what to target next, the turrets all go back to auto-fire, helping take out the enemies that were previously getting away unharmed.

Post-Patch (or what went right!)

A number of other elements of the game were reworked and much improved once the game was patched and expanded in the summer of 2016. The enemies could have had a little more variation, but at least they had a series of different behaviours, stats and special abilities to provide a range of challenges to the player. The fire enemies in particular, cause a degree of panic once players realise they can set their Totem Pole on fire! And even more panic once the fire begins to spread.

The water and ice enemies are a little weaker conceptually. The ice enemy merely freezes the Totem Pole, preventing a few turrets near the base from firing for a short period. Whereas the water enemies simply spawn new miniature enemies every few seconds. This at least gives the player some thinking to do when picking what to shoot next.

The game economy in Classic mode is another part of the game design that worked well on the second iteration / post-patch. The game is quite generous with resources in the earlier part of the game, but those resources can quickly seep away if players spend rashly or fail to defend properly. The downside being, when playing with two players on Wii U, that the playing building the Totem Pole can put themselves out of a job for long periods of the game by being too good.

The tutorial I’ve written at length about in the past, but at least it seems to get the job done for the most part. Whilst the jump-through-hoops style isn’t ideal, it does teach players how to get going, even if it’s not great on many of the details or more subtle elements of the game.


For all it’s flaws, Totem Topple has some interesting design ideas, and still comes out as a fun, if slightly confusing game. In many ways it’s similar to Clash Royale, with that game’s simplified tower defence across two lanes. My hope for Totem Topple is that others will learn the lessons from the game and perhaps open up some new thinking when it comes to tower defence genre.

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.


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.

Side Quest: Valkea Vuori

Back in May, I went to Amsterdam for the Unite Europe conference, and whilst in the city, visited the Stedlijk design museum. It’s a weird collection of modern art and design, but well worth a visit if you’re into that sort of stuff. It’s also partly housed in a gigantic bathtub!

Anyway, whilst there, I found a piece of art called Valkea Vuori by a lady called Rut Bryk (below). It had a really strong aesthetic that was vaguely reminiscent of old school isometric strategy games like Transport Tycoon.


As a side project, I’m now attempting to procedurally generate a tiled world/map in video game form, which I then have a number of ideas about using for creating a strategy game. By happy coincidence, I’ve started working on this around the same time as procjam – the annual game jam around procedural generation. Whilst not technically part of procjam, since I started this a week or two early, I still feel it’s worth sharing with the rest of the community interested in procedural generation in video games.

To that end, I’ve so far produced two different algorithms for attempting to recreate the grid / world of varying square tile sizes. The first looks aesthetically the most pleasing and closest to the art work:


This is generated using a reverse quad tree. Quad trees are a useful data structure used for efficiently storing and quickly retrieving an array of points over a geographical area. However, in my case, rather than starting with a series of points and then trying to create a quad tree to store them, I’ve instead started with a single quad, split it, then randomly selected a new quad (including the just-split quads) to split again.

I also set a minimum width/height below which a quad can’t be split any further. The algorithm then just keeps going until it has performed a set number of splits (which can be adjusted as a parameter, along with the overall dimensions of the grid/map/world).

However, this often leads to a few big quad plus large areas of tiny quad, since the further the algorithm is along its path, the more small quad there are in the list of possible quads (so small quads tend to be more likely to be split, creating even more small quads).

Also, it failed to give the interesting forms in the Valkea Vuori artwork where some larger squares were offset from each other and didn’t always line up.

So I decided to try the reverse approach. Starting with a big grid of minimum-sized squares and merging them together where possible: Pick a random square, pick a random direction (top-left, bottom-left, bottom-right, top-right). Then see if all the neighbours of the square in that direction were the right size and position to be merged.

This proved a big headache, as there are a lot of cases where merging is not possible. It also meant that the aesthetically pleasing balanced-mix of large and small squares was missing – Most of the time it’d be a lot of small and medium sized squares and very few larger ones.

mergeI am though, inclined to stick with this latter algorithm and refine it. The algorithm eventually stops when it fails to find a suitable candidate for merging x times in a row (usually 50). I could simply brute-force search for any candidates it may have missed when picking randomly. More likely though, I plan to play about with adding extra parameters, such as a budget for the number and size of larger squares, to be created first, before randomly merging from the remaining tiny squares in-between the larger ones.

I also need to do the heights, though it should be relatively easy to create passable “hills” using Perlin noise and a few extra variables.

As for the game I plan to make with it, my thinking is at the moment, it’ll be a turn-based 4x-esque strategy game where you grow a little empire by claiming tiles around your home city. Much like how certain iterations of Civilisation series let you claim territory.

Then give players the option to split or merge tiles. Larger tiles may be more productive, but have a greater maintenance cost. Larger tiles also make army / unit movement quicker, since a unit’s maximum speed is measured in squares they can move per turn. That could be a good or a bad thing, depending on how you want to defend your territory or how easy you want to make it to get your troops to the front-line at the edge of your empire!

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.

Kickstarter Launch!

We’re raising funds for Flight of Light’s soundtrack over on Kickstarter! The money will be used to pay a number of different musicians to compose the game’s soundtrack. If all goes to plan, there’ll be four musicians creating two pieces of music each to fit the game’s initial nine levels. (The ninth music track has already been composed by freelance musician Lawrence Shahid, which you can listen to in the trailer above!)

For the next month, we’ll be putting out updates on how the kickstarter is progressing alongside the usual dev diaries and updates on the game’s progress.