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.

Flight of Light Demo

Flight of Light demo version now available for Windows, Mac and Linux

A number of people have asked if there is a demo for Flight of Light. In particular youtubers and streamers have been keen to get a hold of a playable version of the game. So made a demo version for Flight of Light!


You can download it from indiedb, itch.io or gamejolt. There are also mac and linux versions on the itch.io download page, though the linux version is currently untested. If anyone is brave enough to give it a go, or if you find any problems or issues with the demo, definitely get in touch either through email or social media!


In other news, the kickstarter campaign has been going well. Thanks to some very generous donations from a number of people (in fact, from everyone really!) at time of writing, the campaign is over 60% funded. It’s going to be tight, but with any luck, it should make it!


Flight of Light will also be at EGX this weekend (22nd September – 25th September). It’s exciting as it’ll be the biggest show/convention that any of Crystalline Green’s games has ever been shown at! If you want to play the game there and/or have a chat, come down to the Rezzed zone and look out for the big “Flight of Light” banner.


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.

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.


Shiny Circles

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

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

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

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

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

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

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

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

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

Change of Direction

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

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

Flight_of_Light_byCrystalline_Green_neon_1_720p(from this..)

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

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


(to this…)

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

Fly Faster – FoL Update

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

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

Elements of Damage

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

ice arrows 1

Change of Plan

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

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

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

ice enemies

Limited Tension

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

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

Ready, Aim, Fire!

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

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


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