‘Held to ransom by our own mechanic’: Overcoming the technical hurdles of Hue

Coming up with a great game idea is the (relatively) easy part. Implementing it is a different story entirely.

Henry Hoffman and Dan Da Rocha, co-founders of UK indie studio Fiddlesticks, discovered this for themselves when they began work on Hue: a puzzle platformer that revolves around swapping the colour of the background.

The premise is that switching to a different colour reveals objects that were previously invisible. Conversely, matching the background to the obstacle ahead of you makes it blend in and disappear, allowing the player to progress.

The duo has been honing this concept over the past two years, touring various developer conferences and indie showcase on their quest for feedback, adding new features like a symbol system that opens up the game to the colourblind and making Hue compatible with accessories where the LEDs will match the colour shown on screen.

Hue is finally available via Steam today, with Xbox One, PS4 and Vita versions on the way. We caught up with Hoffman, who also served as creative director, to find out more about the work that went into this innovative game mechanic.

Where did the inspiration for Hue and its colour-swapping mechanic come from?
Coming from a design background, I spend a lot of time in image editing apps, so often find myself changing the hue, saturation and lightness of images.

One day I was messing around with the background of an image, and thought it was interesting how objects seemed to melt into the background when they matched the hue. It got me thinking: “By making an object resemble a background, you can make it visibly disappear. What if it could also physically disappear?”

This very simple premise laid the groundwork for Hue, and you’ll see its influence right throughout the game.

The game has been on tour for a few years now. How did feedback and each public showing influence the design going forward?
We’ve been doing a few events a month, all over the world, pretty much solidly for two years now. For the first year, Dan (pictured below right) and myself (pictured below) went to all the events together. He was great at talking to people, and it was really valuable for me to watch players to get a better idea of what needed refining. Those events really served as our milestones, with public showings of the work proving so much more motivating than self-imposed, often arbitrary deadlines.

Puzzle design was probably the biggest challenge when developing the game. For every good puzzle we made, an older one was rendered bad. We were stuck in a quality-control endless loop.

This was great at first, especially for really refining the feel of the game, the progressive disclosure of mechanics, and some of the tutorials at the start. After a while though, especially after the first year, it felt like we were creating a more and more polished vertical slice. We were completely pandering to short, thirty-minute playthroughs, and were still lacking a really solid overarching vision.

The release of the game felt so far away at the start of development, but by this point it was becoming increasingly real. Winning both awards at the Develop Indie Showcase was what really knocked it home for me. I found myself saying: “I’m no longer building a polished demo for events – people are actually expecting a good game.”

After that, I locked myself away. Dan still went to events, and he would record video sessions and document needed changes as best as possible, while I worked really hard on turning what was essentially a demo, into a fully fleshed-out game.

What was the biggest technical challenge of implementing this and how did you overcome it?
Our biggest technical challenge was one we didn’t actually overcome. Very early on I had this idea for a mechanic where you could overlap coloured objects and they would blend together. Our idea was to use that new blended colour as a shape of its own, so you could do all sorts of crazy subtractive geometry. It was a gameplay mechanic which hadn’t been done before and I was completely enamoured by it.

In the end I think we burnt two months trying to get it to work, but there were so many of these fringe cases that made it frustrating and confusing for the player. Ultimately it was a mess, and we had to scrap it. Included in the final game is the visual blending effect though, as kind of a memento of the mechanic not-to-be.

Aside from our failed mechanics, we had a bunch of other technical hurdles. Me not being a very good programmer was a pretty big hurdle. Also, shaders remain a mystery. Overall though, there’s so much support out there, and the game development community is so friendly, someone was always willing to offer a helping hand when we got stuck.

We were even hoping to target platforms like iOS and Android. Instead of binding ourselves to hardware, we just explored what worked best for the mechanic – Hue now targets more of a hardcore gamer type than we perhaps envisaged.

What tech is Hue built on? How did this help achieve your vision?
Like a lot of indies, we work primarily with the Unity game engine. I come from more of a design background, and I suppose you could say this is the first ‘real’ game I’ve programmed. Before this, I worked a lot in more visual engines, like Construct 2, which allowed me to create quite complex games using more visual scripting methods. In fact, the original prototype for Hue was developed using Construct 2.

As our game developed though, we wanted to ensure we could support major consoles. Unity seemed like the perfect fit, especially as the new 2D tools got announced right before we started development. It was still pretty early for the 2D stuff at that point, and we found we were missing some features like masking and 9-slice textures, so rolled our own solutions. Unity seemed great at anticipating those sorts of gaps in functionality though, and pretty much everything we had to do ourselves is now available in Unity releases or experimental betas.

Unity really thrives with the addition of the Asset Store too. There’s a whole bunch of stuff that we’re using, from animation tools, visual effects to input management and more, which would have simply been impossible for us to do ourselves.

How did you decide on the game’s art style?
We were held to ransom by our own mechanic!

In all seriousness, the mechanic only really works if there are a number of visual constraints. The ‘magic’ happens, when a coloured object matches the background and visibly disappears. This means that we needed a flat background colour, with no mid-ground elements or parallaxed environment to ruin the effect. Secondly, the background colour was in the control of the player, so the only colours we could use for the environment were black and white.

Working within these limitations, we naturally developed a bright silhouetted style. We looked at illustration which worked within similar constraints, like the minimalist work of Saul Bass. Emulating various aspects of his work, we quickly found that the dense, cut-out style was really limiting when trying to communicate diverse environments.

We kind of adapted our style and drew more inspiration from Jan Pienkowski and shadow puppetry. We found it much better communicated intricate details, and the silhouettes were really delicate and had this nice lacy feel, which I can’t quite pinpoint. I kind of adapted the style and pulled some of that intricate silhouette detail into the blacks of the environment, by cutting it out as negative space.

It’s been such an evolutionary process, but it’s been very much this crossover between game mechanic and sourced illustrative references, and then ultimately putting our own spin on it to make it work within a game context.

The ‘magic’ happens, when a coloured object matches the background and visibly disappears. This means that we needed a flat background colour, with no mid-ground elements or parallaxed environment to ruin the effect. 

Why was it important to give the game a story, rather than present it as a simple puzzle game?
When we first started on Hue, we had very humble ambitions for the narrative. A lot of the story was going to be implicit and open to interpretation.

However, I thought it was perhaps necessary to read more about colour theory to inform my design decisions, and I found it fascinating. It took me to all these interesting places, like The Knowledge Argument: a philosophical thought experiment that questions whether knowledge is gained through experience. Or this excellent Radiolab podcast called Colors, which made me question whether colour existed in my mind or in the world. My brain was abuzz with all this new information, making me ask questions of myself and my existence that I hadn’t considered before.

The story which developed was really just an outlet for me to explore these ideas, as well as trying to tackle some deeper personal issues. It was in many ways cathartic, but I found it worked contextually so we let it naturally inform the game design and vice versa.

How did you manage to secure voice talent to portray this story? Why was this important?
We worked with a recording studio called OMUK and they are great for helping with sourcing voice talent. We sent them a script and they provided a bunch of samples, but there was one actress that completely stood out for us: Anna Acton, an accomplished British television actress known for roles in EastEnders and The Bill. There was this emotional resonance in her voice – a real depth and layering to the emotion which completely captured the role of Hue’s mother.

Directing voice actors was a complete first for me, but having written the script I sort of had a vision of what I was hoping to achieve. What I found really surprising was how much control Anna had over the various aspects of her delivery. She could tweak and refine it on request, like an audio mixer, twiddling dials and moving sliders. It was an eye-opening experience for me, and really made me appreciate the fine-tuned control that experienced actors have.

Overall, it was a really fantastic experience, and the results add a real emotional connection in the game, which could otherwise perhaps feel too empty, or lacking in real purpose.

How did you balance the game’s difficulty curve when it comes to puzzles? What audience did you have in mind when developing this, e.g. Casual or core gamers?
Puzzle design was probably the biggest challenge when developing the game. For every good puzzle we made, an older one was rendered bad. We were stuck in a quality-control endless loop. About halfway through though, we must have reached some sort of equilibrium where the quality was more consistent.

Once we had what we felt was a good spread of mechanics throughout puzzles, we worked on the overarching flow, how mechanics were introduced and taught, how those mechanics could be combined, and finally more action-oriented variations.

Generally our flow looks like this:

• Introduce the mechanic
• Present the player with a simple puzzle
• Present them with a harder puzzle
• Finish off with an action sequence 

We would then use that core loop again and again as we introduced new mechanics. We also found it really important to add downtime, so the intensity is broken up by dialogue sequences where the player has no puzzle solving to do at all.

When we started the project, our target audience was much more casual. We were even hoping to target platforms like iOS and Android. Instead of binding ourselves to hardware, or a specific audience, we just explored what worked best for the mechanic. I think because of that, the game now targets more of a hardcore gamer type than we perhaps envisaged. It’s definitely to the benefit of the game as a whole though.

We had a bunch of other technical hurdles. Me not being a very good programmer was a pretty big one. Also, shaders remain a mystery.

Why make the game compatible with colour-centric hardware like Razer Chroma and Corsair RGB? Do these devices have enough of an installbase to warrant the time needed?
We did this for fun. We used some middleware called LEDL.io which made the whole process very simple when working with Unity. Overall development time was probably only a couple of days and I think there’s probably a business argument that we could cross-promote with these hardware manufacturers around launch. My reason, though, was just becaus it was fun.

The hardware was really well-suited to our colourful mechanic, and the little touches in the game are really exciting – so why not the touches outside the game too? I really want to take it even further, and allow the game to control your Philips Hue lighting too – so your house lights can change colour with the game. It’s something I’ve been working on and really excited to start testing soon after launch.