This interview is part of our Road to the IGF series. You can find the rest by clicking here.

Noita simulates every pixel of its expansive world, allowing players to break walls, set fire to oil, melt ice, and generally change the environments around them as they explore procedural places.

Gamasutra had a chat with Petri Purho, one of the developers behind the Seumas McNally Grand Prize-, Excellence-in-Design-, and Nuovo Award-nominated Noita, to talk about the appeal of simulating every aspect of the game, how this kind of play allows for a constant feeling of rediscovery and creativity in how the player handles problems, and how the whole thing has come from a game jam that has gotten far out of hand.

Pixel programmers

Hi, I'm Petri Purho. I am one of the three persons working on Noita. The other two are Olli Harjola (of The Swapper fame) and Arvi Teikari (of Baba is You fame). I'm mostly known for my long and luxurious
hair, but I did also make Crayon Physics Deluxe a long time ago.

I dipped my toes into the game development industry back in 2005 when I interned and then worked part-time at Frozenbyte on Shadowgrounds and then on Shadowgrounds: Survivors.

In 2006 (inspired by Experimental Gameplay Project) I started doing a game a month at my blog Kloonigames. One of the games I made for it was called Crayon Physics (it was a 5-day prototype). That got a really good reception, so I decided to make a bigger version of it. While that game (named Crayon Physics Deluxe) was in development, I submitted it to the IGF. And it got nominated and eventually won the IGF Seumas McNally Grand Prize in 2008.

Anyway from that point on, I've been a "full-time" indie. Mainly because I figured I'd work on my own games until I ran out of money and then I'd cut my hair and get a proper job. Luckily I haven't run out of money yet.

Born with Bloody Zombies

Noita has had a really long and complicated process of getting to where it is now. It can be traced back to one of the monthly games I did for my blog called Bloody Zombies. That game was made for Gamma 256, which had the restriction that you had to make a game that had a resolution of 256x256 or less. I figured that doing such a low resolution would allow you to use a lot of CPU power per pixel. So, I figured I'd make a game in which all the blood was simulated.

In that game, you used a lawn mower to mow down zombies and they would leak huge amounts of blood. Then you used the blood to platform into places. You could also use the lawn mower in the blood to blood surf.

Anyway making that game in 7 days left me always wondering if there would be more things that could be simulated in a similar fashion. Namely, I was really curious if rigid bodies could be simulated at the resolution. The idea of having ragdoll zombies that would you could shoot legs off of and see them drag their way towards the player seemed like a lot of fun.

In 2011, I started playing around with that stuff. It was 2012 when I asked Arvi Teikari if he would do some pixel art for a game that turned out to be a title in which a wizard would cast spells to manipulate the world. The gameplay never quite worked, but it was really fun to mess around in it.

In 2013 Olli Harjola joined our team. We tested a few different game ideas during that time, including a 2D God game, a Terraria/Minecraft type of game, an RTS. It was Olli's prototype in which you controlled a character directly with WASD + mouse that had the most immediate fun.

Pixel simulation tools

We have a custom engine called Falling Everything. It's written in C++ and it uses a few 3rd party libraries:

For writing code, I use Sublime Text 3, and to compile and debug, we use Visual Studio 2013. For graphics, we use all kinds of things like Photoshop, Multimedia Fusion, Aseprite, and Krita.

The interesting surprises that come from simulating everything

On the most superficial level, it creates a unique look for the game. On a deeper level, having a highly-simulated world feels much richer and much more interesting to explore. Not just explore in the spatial
way, but to explore as a set of systems.

It functions as this emergence-generating machinery that keeps on generating these interesting situations of play. There's always something new to be discovered, even for us. Like, yesterday I was playing the game and I killed an enemy that was above me, his body fell down and broke an oil lantern, the oil spilled on me and I was set ablaze. That had never happened to me before.

The challenges of Noita's design

There were a bunch of technical problems that we had to solve. But the real difficulties have been in the game design. Technical questions are much easier to answer. Is this running 60fps? Yes, then it's working.

The game design is much more difficult. Is this fun to play? Well, it depends who is playing. Maybe I find it really interesting, fun, and engaging. But will our players? Will they understand what's going on? Is it too difficult or frustrating?

Creating interesting gameplay in a simulated world

It's easy to think that having a complex or highly realistic simulation will auto-magically result in interesting gameplay. Often, that's not the case. The simulation can, in fact, be in the way of more interesting gameplay.

Like, if in Bloody Zombies I would have added IK-based enemies. Simulating their limbs physically to make them walk. You could chop off their legs and arms and they'd still come at you. In theory, that sounds like really cool and interesting gameplay. But what if, in practice, the enemies are just really cumbersome and they just keep falling over each other. It would be fun to watch for a while, but do they really provide a formidable and interesting enemy for a game?

There are tons of examples like that from the development of Noita. One of the ideas we tested was having buildings where you'd fight enemies. And the buildings were all simulated and could collapse. That sounded really cool in theory. In practice, you very often ended up with just a bunch of rubble at the bottom of the screen.

So, the process of working Noita has been one of implementing things and then testing them to see what worked and what didn't. Not just in terms of simulation, but more often in terms of how it affects the gameplay.

Spelunky influences

Derek Yu's Spelunky is one of the games that's influenced me and Noita a lot. One of the beautiful things that Spelunky did was it forced you, as a player, to learn how the world worked in a more systemic and deeper level than traditional linear games.

So, in order to achieve that, we decided to do a permadeath game with procedural generation. That way, when the player learns things, they'll learn them not just through rote memorization, but in a way that allows them to apply that knowledge to a variety of situations. That's the theory, at least.

Everything in our game is already very dynamic, so adding procedurally generated environments hasn't been all that big of a problem. Using Sean Barrett's Herringbone Wang Tiles has also allowed us to control the generation in a pretty nice way.

One of the benefits of procedural level generation is that it has kept the game fun to play for us throughout the development process. I still really enjoy playing the game, which is a rare pleasure when you consider that I've worked on this game for like 6 years now.

How the player's perception changes when they can affect the environments

The player needs to have a high degree of environmental awareness, so they can use the environment to their advantage. And also to avoid the hazardous bits (e.g. shooting ice to make it break to drop on top of enemies and kill them). Or, if there's an enemy that's drenched in oil, you can set the oil on fire to kill the enemy. Or, if there's treasure in an inaccessible location, you can use the enemies that shoot acid balls to dissolve the barrier and help you get access to it.