The core concept of the game is that its set in a world where life has evolved mechanically, rather than organically. Evolution has shaped the mechanical eco-system over millions of years, and created a living breathing (sentient, refuelling?) environment. The first level is set in the equivalent of a mechanical jungle.

The idea behind these ‘Flowers’ is that they use their petals like funnels to collect and process falling fluids. Over years of use the erosion has caused the petals to become more colourful. As the environment they exist in is filled with predators and prey, the creatures will retract their petals by reflex when they sense movement nearby.

What do you think? What are some small details you’ve used in the background to help flesh out the worlds that you are working on?

I wanted to talk a little bit about how, when we see a finished feature in a game, we don’t see the months of prototyping that goes behind it, and how each of those prototypes helps to solve a problem and builds upon each other to get to an end goal. The video attached shows some of the protoypes we went through while developing a pitchable demo for our game - Mechinus - as a bit of a case study.

I think people new to the games industry don’t necessarily know what we mean when we say “start small” and want to just start working on their dream game straight away – but you’d be amazed at how creating simple prototypes to focus in on one aspect of your game and drilling down into that can help you build something much bigger.

In Mechinus, the main character is a cog that rolls around the world. It was important to us that he had a very particular feel to his movement – there needed to be a good feeling of weight, inertia and momentum, but as a puzzle platformer, he still needed to feel responsive and easy to control.

We started off with a 2d prototype to try and get a base movement system that felt representative of what we were looking for, and also felt fun – one thing that really helped the workflow was providing lots of tweakable values to experiment with whilst playing the game as it vastly improved iteration time. I think we went through something like 9 or 10 different builds trying to get to point where we felt pretty happy with it. At that point we shared the build with the rest of our company to get feedback - and then inevitably had to iterate a bit more as a consequence.

Once we had a 2d prototype signed off, we moved over to 3d and tried to replicate the same feel across a 3d spline. Often when you see 2.5d games the characters still travel from left to right, just in a more 3d environment – it was important to us that the character’s path could bend to allow the character to move into and out of the camera, allowing him to turn corners – similar to old platformers like Pandemonium or Klonoa. This caused lots of headaches, and a few changes of tactic - moving from a spline based system to making a custom track editor for example – but we eventually got something that looked pretty interesting and felt pretty cool. If we had been trying to do this, whilst also trying to work out how we wanted the controls to feel, it would have been a nightmare, but breaking down the issues into separate prototypes helped us solve one problem at a time.

From there we created a block out of the level we were planning on building – this in turn caused us to rethink a couple of things, and tweak values even further. This process continued all the way up to creating the final build.

- Peter Gomer, Head of Design, Huey Games