How McPixel 3 incentivized failure by being funny

McPixel 3 is about a hero trying to avert disaster, usually by creating several other disasters that kind of cancel one another out. Or you choose the least disastrous thing to happen to yourself in its fast-paced, adventure game-like puzzles. You’ve got seconds to figure out which items or interactions will save the day or doom you, and they are rarely what you expect. Thankfully, getting it wrong is just as fun and funny as getting it right.

Game Developer spoke with Sos Sosowski, creator of McPixel 3, to talk about making a game you could play on almost any device (including a phone landline), filling moments where you ‘fail’ a puzzle with a feeling of discovery, and how he manages to create so many jokes that catch the player off-guard.

Game Developer: It's been a long time since you made the original McPixel. What made the time feel right for McPixel 3?

Sos Sosowski: I know, right? I was reluctant to make a sequel to McPixel because making the first game left me burnt out a bit. Even though I make art and music myself, I am predominantly a programmer, and 90 percent of McPixel 1 development was drawing the animations, which drained me a lot. People would ask me if I ever want to make a McPixel 2, and I always said no (I keep my promises). But after some time, I realized that people really really liked McPixel, and perhaps I was able to take the concept further.

The first game was initially created for a game jam called Ludum Dare 21 in 2011. It consisted of six levels and a very simple engine that used mostly only graphics to represent the stages. And even though the fully released game had 100 levels, the underlying tech remained largely unchanged, with me trying to work my way around the limitations instead of extending them.

This time, I wanted McPixel with no limitations. McPixel where everything can happen and where, if I wanted to add something, I could just add it. So, I rebuilt the engine from scratch and tried to make it scalable enough to be able to keep adding different features. I wanted to be able to create a McPixel game that the fans truly deserved, no strings attached.

The silliness of McPixel 3 isn't just the game itself, as you've also produced some goofy ads and other silly content. What was the appeal of making all of these other funny things in other mediums (as this isn't the first time you've done some interesting things outside the game, as you did with Mosh Pit Simulator)?

Hats off to the lovely folk of Devolver Digital for making these possible and absolutely vibing with the bizarre style of McPixel. It was their idea to make fake infomercial videos for McPixel and we even set up an actual hotline you can call to play a level of McPixel 3 over a landline. I loved these crazy ideas and had tons of fun shooting the videos. [I] Couldn't believe that this is my job!

The game features one hundred stages of oddball events. What sorts of things inspired these many absurd stages? Can you tell us about some particularly interesting inspirations that formed a stage?

For the first McPixel, it was much harder to come up with all these ideas because of the limitations. Anything that wasn't a bomb blowing up in a random place was really hard, if not impossible, to pull off. This time, thanks to the new tech, I was able to have all kinds of catastrophes. And hey, we lived through 2020, 2021, and 2022 now; it's not that hard to come up with 100 disaster scenarios.

Additionally, this time I wanted to have thematic rounds, so there's a round of sport-themed levels, a round of TV show spoofs, and rounds where McPixel gets shrunk down or sent back in time! With that kind of variety, it wasn't that hard to come up with the scenarios.

McPixel 3 has many funny ways to solve its puzzles, but even more funny ways to fail them. What thoughts went into incentivizing failure? Into making it as fun to screw up as it is to complete the level?

I loved point-and-click adventures when I was younger—Teenagent, Discworld, Simon the Sorcerer. But they had one major flaw. You could only do the right thing. Whenever you would do something that the developers did not intend you to do, the main character would just say a default one-liner and move on. I wanted the players to be able to do everything. Combine every item. In other games, if you take a wrong corridor that doesn't progress you further, you will usually get a treasure chest. I wanted McPixel to feel the same! There's no failure in McPixel, there's only discovery.

Every stage is crammed with different things to interact with. What thoughts go into designing so many different outcomes in each situation and giving players so many things to play around with?

Usually, I would start by laying out the level with all the items in it and have a general idea as to what solves it. Then, I would go through all the items and interactions one by one and add an interaction animation to them, usually trying to be unpredictable in the outcomes to catch people off guard.

The comedic timing on many of the outcomes is incredible, and it often blindsided me with funny outcomes. What thoughts go into timing something ridiculous just right? Can you walk us through the process of putting one of these silly outcomes together, and the work you did on tweaking the timing to create a hilarious gut punch?

Most of the animations are frame-by-frame animations, and they are controlled by a scripting system I came up with. Basically, the entire game engine is just a giant interpreter for the myriad interaction scripts I wrote. Each gag in the game consists of small animations chained together. Think about the sequence where McPixel falls out of the window in the train level (above). McPixel jumping out is one animation, falling on the outside is another, then every time he hits the ground, bouncing is another animation. These tiny bits allow me to control the flow of the show with precision, and as editing scripts might not sound too appealing to an animation designer, I, as I mentioned before, am a programmer.

Additionally, music plays a major part in the timing. Most of the animations you see on the screen while playing are synced to the beat one way or another. Sometimes it's people vibing, sometimes it's a pole zooming outside the window with the beat of the snare drum, sometimes it's clouds in the background moving one pixel every beat. It's not something most people notice, but I believe it adds a lot to the game.

Likewise, many of the jokes in the game caught me by surprise. What thoughts went into creating surprising outcomes and keeping the outcomes from being what the player expects?

I believe that, for comedy, you must have something relatable and something that is out of place. Not everything can be abstract. So, when the player picks up a fish and tries putting it in a fishbowl, McPixel jumps inside instead. When you jump out the window, McPixel runs to the front to try to stop the train with his bare hands but falls down with the train. There is a part that you find relatable, and then it tries to catch you off guard.

McPixel 3 can run on some downright ancient hardware. Why did you want to design it to run as lean as possible? How hard was it to get the game to do everything you wanted within these limitations?

When I started production, I was considering what kind of tech to use, but I had two rules. First, it must be portable. Secondly, it must not be overkill for this kind of project. The only sensible solution seemed to be to write my own software renderer and engine. This way, I could make sure that every pixel on the screen was exactly the same on every single platform. This also allowed me to have automatic testing, where the game 100 percent tests itself after every build automatically, catching some critical errors in the process.

The engine being written in C, a low-level programming language, and the low resolution of the game made it naturally possible for it to run on all those old machines. Compatibility like this was nice to have, but it wasn't my first priority. That's why, in some levels, I have blending, special effects, and things that were not present on old computers. But the game still runs! I have an old Pentium-3 PC and a bunch of different processors to test, which is the slowest thing that can run McPixel 3 in full 60 FPS, and it appears to run for the most part smoothly on as little as a Pentium III 800MHz.

Anything lower than this, and the game simply runs out of memory bandwidth to display things on the screen. The game logic itself is not very demanding, but the rendering sometimes puts a couple of dozen layers on the screen, and even at low resolutions, that's a lot of data for an old computer to process.