How Skala surprised its own creator with its scale-shifting mechanics

This interview is part of our Road to the IGF series. The IGF (Independent Games Festival) aims to encourage innovation in game development and to recognize independent game developers advancing the medium. Every year, Game Developer sits down with the finalists for the IGF ahead of GDC to explore the themes, design decisions, and tools behind each entry.

Skala allows players to change the size and shape of the world and everything in it, asking them to solve puzzles by stretching and growing things.

Game Developer caught up with the creator of the Best Student Game-nominated title, Gustav Almström, speaking with him about how designing a custom engine really helped make the scale-shifting mechanic work well, bringing the appeal of looking into the night sky into this world, and how the surprises that came out of the game's mechanics delighted and mystified its own creator.

Who are you, and what was your role in developing Skala?

I'm Gustav Almström and I am the developer of Skala.

What's your background in making games?

One day I basically decided to Google "How to program" and I've been making games in my spare time ever since.

What thoughts went into the mechanics players could use to alter the scale of themselves and the world? Into making them intuitive to work with?

The core thought behind the design of Skala was to try to explore what actually happens in a world where things can change scale. By experimenting and playing around with the game's mechanics, I found things that stood out as interesting and made levels about them. An example is how the player falls slowly when they are short.

I always tried to explore the mechanics I had as deeply as possible, and only added new ones when I had squeezed a lot out of what I already made. The game took two years to make and good ideas always seemed to come in big bursts of inspiration. There where long periods of time when I couldn't come up with or design anything (which was a little stressful), and other periods where the game almost seemed to design itself.

What development tools were used to build your game?

The game was built with a custom engine based on C and Opengl. At first, the only reason for this was that I like writing engines, but for this particular game it turned out to be especially useful. There were a lot of bugs caused by floating-point precision issues, and the way that objects can change size created a lot of situations that I'm not sure regular physics systems could have handled.

So, by writing everything myself, I gained the control over the code I needed to deal with these types [of] issues effectively. It probably would have been possible to create the game with an already existing game engine, but I think that it would have been much more difficult.

What drew you to the visual style for the game?

The visual art style of the game is very simple. Most things in the world are just single-colored rectangles or basic shapes that indicate different types of objects. This art style is what could be described as "programmer art" and hasn't changed much since the beginning of the game's development even if I intended it to. It did, however end up having a very positive effect on the gameplay. Since things are drawn so simply, there isn't any visual noise that distracts the player from solving a puzzle, and the simplicity also lets them easily visualize the elements of a level and reason about them in their head.

What ideas go into designing the world around these kinds of scale-based puzzles?

I live out in the country where there isn't a lot of light pollution, which means that the stars are very clear and vivid. I spend a lot of time just sitting outside and watching the sky, and I wanted the overworld of Skala to sort of feel like this. I like looking for star constellations, and there are some in the game's sky, but they're quite subtle, and I'm pretty sure that very few people have noticed them.

Can you walk us through the design of a favorite puzzle? How you conceived it and the implemented it into the game?

My favorite level is probably "Rider." It came from asking the question, "What happens if the player is standing on a block that can change scale, and only does so when the player moves?" and the result was a level where you would sort of surf on a platform that could also float upwards as high as you wanted it to.

The platform could however only move upwards, and in the levels that follow, I tried to figure out ways of making the platform go downwards. I found that if you moved it into a field where its scaling direction changed, jumped, and moved it out of that field, it would start to fall and shrink rapidly until it disappeared. By experimenting with this interaction, I found that what happens when you jump out of the scale field depended heavily on the exact parameters of your jump. If you jumped in a very particular way, you could create a platform that would fall down slowly, but still could be moved upwards, which allowed the player to fly anywhere they wanted freely.

I honestly still don't quite understand exactly how the mechanism in these levels work, but I still put them in the game because they felt so interesting to play with and the mechanics in them can still be utilized predictably even if you don't understand how they work. This feeling of solving problems through the exploration and taming of an incomprehensible system is why these are my favorite levels.