Multibowl is one of my favourite emulation projects because it’s a rare example of using emulators creatively, rather than for nostalgia or research.

It’s a 2016 game by Bennett Foddy and AP Thompson that reimagines older existing games as smaller pieces of a new, Super Mario Party-like experience. Two players randomly join one of 300 games – sometimes in medias res – with a small explicit goal that can be accomplished in about ~30 seconds, after which a point is awarded, another game is loaded, and so on.

All of this is done through actual emulation and fast switching of games’s original code:

Regarding the game choices, at the outset, I wanted to curate a list of moments of gameplay that would be meaningful if played for just a short period of time. Sometimes it’s obvious – you can take a moment from a fighting game where both players are low on health, or play a sports game from the start until the first point is scored. So that’s where I started. Over time, I figured out that you could make exciting moments in games that are not otherwise interesting for a competitive duel. For example, in Dodonpachi (a bullet hell game) we take away the player’s guns and challenge them to stay alive in a huge hail of bullets.

For games that were designed as cooperative experiences, I eventually gravitated toward the structure ‘score more points but do not die’, which forces the players to calibrate how much risk they take relative to the other player.

This excerpt is from a 2017 interview of Foddy by Seb Chan from ACMI. There are many interesting moments in that interview, such as the issue of curation:

Multibowl is not a very precise historical curation like you might make for a museum exhibition, where you can only show a couple of dozen things at most. It’s a huge driftnet of games. There is no quality or historical significance standard, and no attempt to balance out the games in terms of nationality or gender. The only curatorial instinct that it follows is to find the most diverse set of game ideas. With each piece distilled down to a randomly-selected 30-second slice, there’s room for an infinite number of them.

In fact, contrary to a museum curation, the point of Multibowl is to have too many games for a single player to see. It’s best when it feels too big to grasp. I think, now that there are 300 games in there, it’s starting to feel that way.

Unfortunately, it is not possible to actually play Multibowl outside of special events, given copyright issues. In addition to general emulation copyright murkiness, Foddy adds, “I don’t think the actual bits of actual games have ever been used as the fabric of a larger game before.”

However, a really fun introduction to Multibowl is another art project from a now-defunct comedy duo Auralnauts, who actually played Multibowl pretending to be Kylo Ren and Bane, to hilarious results:

In the Fallout 3: Broken Steel addition, the team wanted to introduce a moving subway train under Washington, D.C.:

However, the engine did not have any moving vehicles. Instead of adding a new kind of primitive into the game engine, the creators… made the player character itself become the subway car when in motion:

This was done by removing freedom of movement from the player, forcing the character to slide on the floor, and equipping him with… a “metro hat.”

The visuals of people hacking this to use it outside of the subway area are really funny:

Technically, it was not a hat, but a right-arm armor, as you can see from the right hand missing in the above picture.

The FPS genre is filled with all sorts of hacks for hand-held weapons, to compensate for the challenges of depicting things accurately not feeling as great…

…but I have never heard of someone “wearing a train.”

(The title comes from this post.)

It is common knowledge that Luigi is just a palette-swapped Mario, and that the characters facing left are the same characters as those facing right, only rendered mirrored.

This interesting 9-minute video from Core-A Gaming explains how this can be kind of tricky for fighting games in particular:

Suddenly, a character with a claw on one hand, or a patch on one eye, becomes a more complex situation – without redrawing, the claw or the patch move from one side of the body to another. Then there’s the issue of open stance toward the player, turning left-handed characters into right-handed ones just when they switch to the other side.

3D fighting games can, in theory, fix all of this with more ease, as instead of redrawing hundreds of sprites they can just introduce one change to a model… but they often choose not to. Enter the issues of 2.5D fighters vs. 3D fighters, 2D characters in 3D spaces, and lateralized control schemes.

It’s a small thing that quickly becomes a huge thing.

Here’s an object in Figma with one rounded corner. Notice how the UI always tries to match the rounded corner value based on where it is physically on the screen…

…which makes for a fun demo and feels smart, but: why don’t width and height do the same?

Turns (heh) out that this is a similar set of considerations as those in fighting games: both thinking deep about what is an intrinsic vs. derived property of an object, and what is the least confounding thing to present to the user. Since objects usually have noticeable orientation – text inside, or another visual property – width still feels like width and height like height even if they’re rotated. The same, however, isn’t necessarily true for four rounded corners. Or, perhaps, the remapping of four “physical” corners to four “logical” corners can be more error-prone.

Then, of course, there’s a question of what to do when the object doesn’t have a noticeable orientation. Like with many of the things on this blog, there are no “correct” answers. This too is a small thing that quickly becomes a huge thing.

I mentioned before how the old-fashioned pixels on CRT screens have little in common with pixels of today. The old pixels were huge, imprecise, blending with each other, and requiring a very different design approach.

Some years ago, the always-excellent Tech Connections also had a great video about how in the era of analog television, pixels didn’t even exist.

But earlier this month, MattKC published a fun 8-minute video arguing that for early video games it wasn’t just pixels that were imprecise. It was also colors.

What was Mario’s original reference palette? Which shade of blue is the correct one? Turns out… there isn’t one.

Come to learn some details about how the American NTSC TV standard (“Never The Same Color”) worked, stay for a cruel twist about PAL, its European equivalent.

RuneScape is a popular MMORPG that reached its peak popularity in the late 2000s.

In the game, combat – colloquially known as PvP, or player vs. player – is limited to a specific map area (called the Wilderness) and otherwise people’s houses.

On 6/6/6 (sic!) a bug in RuneScape made it possible for a few players to start killing others outside of designated areas, without them being able to defend themselves. One of these players, Durial321, gained a lot of notoriety:

A player called Cursed You had invited some friends to his in-game house once he had maxed his construction skill, but decided to eject them all from the premises. Things turned sour, however, as a group of players marked as PvP in the house didn’t lose this PvP flag when ejected, allowing them to storm through Falador and massacre whoever they pleased. The most notorious of these players was named Durial321.

This event went down in internet infamy and meant that many players lost their items when killed as well as the banning of those involved.

I don’t have any context of RuneScape and I found it really funny to learn about this event from different retellings of the story.

This wiki entry reads almost as journalism:

Several others were able to use this glitch, but Durial321 abused it the most. His rampage lasted for about an hour, starting at Rimmington, where the house party was, then proceeding to Falador and subsequently Edgeville. At Edgeville, he gave Voodoolegion the green partyhat, who never gave it back to him. Soon after, he finally encountered a Jagex Moderator, Mod Murdoch, who disconnected him and locked his account. Durial321 was later permanently banned from RuneScape. In a 2006 interview, he said that player killing outside of the Wilderness was exciting, although he felt bad for the players who lost their belongings.

The 2006 incident later became known as the Falador Massacre.

(The tone is even more funny if you actually read the interview.)

There is also this more modern retelling that feels like scary story time by the campfire:

Reactions from players were initially kind of incredulous. Plenty of people were shocked and found the whole incident quite funny. Durial had essentially broken the game, after all. Some players wanted to be like him, whipping strangers to death and taking their items. But soon, as more players started hearing about what had happened and seeing the video, the mood shifted. Players wanted Durial321 hung, drawn and quartered, with his head displayed on a pike outside Lumbridge Castle.

You can witness the event PC Gamer called “one of the best all-time MMO bugs” by yourself since there is video capture of the Falador Massacre taken by one of the witnesses. At least to me, it’s rather incomprehensible.

Fear not, however, because there are many (!) documentaries. This recent one is reportedly the best one and also goes into the technical details:

Without spoiling too much, the bug was a classic Swiss cheese situation involving a new untested item, a race condition, peculiar timing, and a player with an unusually high uptime and a whole lotta luck.

I’ve learned recently that “rubber banding” can mean at least three different things in the context of UI/UX design:

• whatever happens at the edges of your scroll container when you’re using elastic scrolling, which started on the first iPhone and have spread more widely since
• in videogames, balancing the difficulty in real-time so that inexperienced players stand a chance and good players are not bored (a classic example in any racing game is computer-controlled cars slowing down if they are running too far ahead, as if held by a rubber band, to give you a chance to catch up)
• in multiplayer experiences (mostly videogames, too), the experience of snapping back and forth (example) during gameplay when your connection speed is low and the game has to reconcile your predicted position with your real one

Each one is interesting in its own way. (Each one is also controversial, although for a different reason!) But what I understand they all have in common is – well, obviously – the specific mechanics of rubber banding.

I imagine many reading this are familiar with basic interpolation between A and B using curves like ease in, ease out, and so on. But in gaming and I think increasingly in UI design, that’s not enough. When coding stuff related to movement – imagine dragging an elastic scrolling view near its edge – the challenges compound:

• the object might already be in motion
• its destination might also be in motion
• the load or framerate can vary, so calculations have to take that into account

With that in mind, I found these two videos helpful and informative:

• an 8-minute video by SimonDev
• a 50-minute talk by Freya Holmér (with a 10 minute Q&A session you can skip)

The videos together start with basic lerp (linear interpolation), then move to lerp smoothing, and then arrive at frame-independent lerp smoothing. There’s light math/​physics here, but that’s to be expected, as all these experiences are meant to feel like real-life objects would.

I found especially lerp smoothing where you feed a lerp into itself particularly conceptually beautiful.

This video from Marblr about adding fall damage to Overwatch is really intense – 45 minutes of length and a lot of footage of frantic gameplay – but really informative, too.

It’s a great case study of how something seemingly really simple – deducting health from the player as they fall from height – can be a complicated thing to figure out in all the detail.

I never played Overwatch and rarely play videogames anymore, but many of the lessons here more universal for any sort of UI and system design:

• You will have to introduce tactical inconsistencies for the system to feel consistent, but be careful as there might be a point those inconsistencies start to outweigh the whole thing.
• Wanna learn how you and others feel about something? Overcrank it to make the feelings come out more easily. (And to find bugs.)
• There will always be tensions between what the data says and how you feel about something. (I was surprised how often the word “intuitive” entered the picture.)

Also, it’s just a really well-made video, filled with little presentation and storytelling details that elevate it. I wish more videos like this existed for UI mechanics.

But maybe the most important takeway? You don’t have to choose between rigor and fun. You can have both.

Before computer graphics, movies relied on matte paintings to extend or flesh out the background. This is perhaps my favourite matte painting, from the end credits of Die Hard 2:

Turns out, videogames do something similar, except the result is called a skybox, since it has to encompass the player from all sides. It’s another way to use cheap trickery to pretend the world is larger than it is.

This 9-minute video by 3kliksphilip shows a few more advanced skybox tricks from Counter Strike games using the Source engine:

I particularly liked two discoveries:

• In real world, you wouldn’t style backfacing parts, because the player will never be allowed to see from the other side. Here, you don’t even have to render them.
• Modern skyboxes have layers and layers of deceptions: more realistic 3D buildings closer to you, and completely flat bitmaps far away. It almost feels like each skybox contains the history of skybox technology that preceded it.

On the other hand, seeing clouds as flat bitmaps was really disappointing.

When you start a new game in SimCity 2000 (you can try it in the browser yourself), as the city is generated, you see a few messages fly by: Creating Hills, Tracing Rivers, Smoothing. Among them, for a bit, one can see “Reticulating Splines”:

If it was not obvious from seeing Smoothing followed by More Smoothing and then Yet More Smoothing, the phrase is a joke. From The Official SimCity 2000 Planning Commission Handbook:

“Reticulating splines” is a giant pulling of our legs. Will and some others made up the phrase because they thought it looks and sounds as if it means something. It might: the word “reticulate” means to divide something so that it looks like, or appears to be, a net or a network generating, perhaps, from a single point; a “spline” can be an irregular curve or the approximation of a curve. Individually the terms have meaning. Together – in the case of SimCity 2000 – they don’t. It’s just a prank and a joke.

In some versions of the game, there was also a seductive woman’s voice saying the phrase out loud, which presumably made it even more memorable.

The phrase moved to other Maxis games, notably The Sims…

…and subsequently Minecraft…

…and then tons of other places.

I’ve heard the argument that it wasn’t just Reticulating Splines – that Will Wright’s joke was the beginning of the habit of putting “cute” loading messages in apps, including actual not-game and definitely-not-cute applications. I am 100% sure there are some earlier examples of “funny” loading or error states, but I also see how this one attained a certain critical mass and influence.

I hate these cute loading strings with passion. I think I’m in the minority. It’s a topic for a future time, but it was fun at least to trace some part of its history, sifting through hundreds of pages earnestly explaining the concept of “reticulating splines” to people. Whether they’re in on the joke, I am not sure.

Also, okay. Fair enough. I chuckled just now when I saw this:

A really interesting 28-minute video by daivuk about making a first-person shooter game QUOD that fit in just 64 kilobytes:

I found watching it strangely enthralling and even nerve racking. The creator keeps adding stuff that seemingly has no chance of fitting into such a small space – textures! sounds effects! music! his own language! – and somehow finds a way to squeeze them all in.

This is inspiring, but also practically useful: even though you and I are maybe never likely to need such high optimization, some of these techniques alone could be useful in some tight quarters like a load-bearing CSS file, or embedded software.

As an example, the author wrote his own “music tracker,” which is a clever way to reduce the weight of music: instead of the tune being one big audio file, only the instruments are sampled, and then arranged in repeating patterns.

Except in his case, there were no instruments… just audio effects already existing in the game. And audio effects themselves were generated in a similar way, by combining smaller waves and effects.

The same was done for textures: the creator wrote a bespoke text editor that saves each texture as smaller pieces and combination instructions – a sort of a “PDF” of a texture rather than a more costly scan of the printed page – and re-generates it on entry.

Lastly, this debug view of “cost” was really interesting. (Good debug views, in my opinion, are generally underrated.)

A 12-minute video from Tech Rules about how the 2000 PlayStation game Spyro: Year of the Dragon dealt with software piracy:

The video extends upon a 2001 Game Developer article by Gavin Dodd, but Tech Rules adds a good intro about PlayStation’s modchips, and then actually shows the piracy protection in action.

I’m not going to spoil the surprise. Am I fully supportive of the approach? Not sure. PlayStation’s region protection complicates my feelings, and any sort of DRM-esque approach eventually backfires when it comes to software preservation. But you can’t deny what Spyro developers did is a really fascinating and weird approach.

The quote in the title of this post refers to the hackers who eventually did conquer the Spyro’s copy protection system. I guess – and I apologize in advance – game recognize game.

An interesting 14-minute video about a bug in Grand Theft Auto: San Andreas:

San Andreas was released in 2004, but the game started breaking only after Windows got updated… in 2024. Turns out the bug was sort of a ticking time bomb just waiting for the right set of conditions. We covered one similar bug before, in Half-Life 2 – but this investigation goes deeper, and shines a light on the difficulty of making Windows, whose backwards compatibility comes at a price.

I have zero nostalgia for Mario, and yet I was surprised how much I enjoyed this 30-minute video by Sheddux:

It serves as a bit of design history and even critique of early Mario games, and then in the middle it turns into an analysis of the Mario port on Game & Watch – an obsolete technology even in the 1980s, and something that could have been an easy cash grab, except someone cared.

Translating Mario’s mechanics to a much inferior tech is an interesting design challenge, plus there’s just this universal pleasure of seeing someone go extra. And the video has a nice ending message, too.

This 9-minute video from the fun game show Lateral (with Tom Scott!) covers a particularly interesting bug in the 1984 game Karateka:

If you don’t want to watch the video and try to figure it out alongside contestants, you can read more about it here, and also see it in action.

Karateka was made by Jordan Mechner and I bet his name will come up again.

This is a really funny story happening in the online universe of Final Fantasy 11:

Once killed, a notorious monster shouldn’t respawn until after the next monthly tally, but lately defeated notorious monsters in Limbus have been reappearing early. That’s because, Square Enix said, “the server-side data recording the defeat status of notorious monsters is unexpectedly being cleared.”

Thus, there’s only one way to guarantee no players are robbed of hard-earned Limbus loot: Square Enix is dispatching Game Masters to personally murder every notorious monster in Limbus so the FF11 servers can properly verify that they’re really, truly dead.

“To achieve this, Game Masters will visit each World in sequence and defeat each motorious monster individually,” Square Enix said. “We apologize for the inconvenience.”

I know this is not a bug fix per se, but it’s interesting to be doing some bug cleanup from the inside.

A nice counterpart to my post from a few days ago – a 5-minute video by philive of more kill screens from various classic arcade games, with simple explanations.

I’d guess a lot of people know that the original 1980 Pac-Man ends accidentally with an iconic, glitchy, and impassable “kill screen.” Many people will also nod with recognition at hearing the kill screen is level 256, a number that immediately gives some ideas on what might have happened.

But this fun 11-minute video from 2017 by Retro Game Mechanics Explained doesn’t stop there. It shows, step by step, exactly what is going on when you reach level 256, and how each one of the glitchy things appear on the screen.

It’s a little mesmerizing, like watching a building demolition in slow motion.

I saw this screenshot the other day (link):

I never particularly liked those “cute” app updates that were all the rage some… 10 years ago? Or app updates that are too generic. I always felt the updates should be informative, and I occasionally like seeing what’s actually being fixed, and sometimes learning from it.

The post above is about a game called Dwarf Fortress that I have never heard of, despite it going on since 2006. In that game, actual descriptions of bug fixes often feel better than those creative app updates. Some examples:

• Zombies start conversation with necromancer adventurer who tries to sleep in their house
• Cats dying for no reason - alcohol poisoning?
• Giraffe is trainable for war
• Added mouths

PC Gamer some fun ones in 2016, or you can just go to Dwarf Fortress Wiki and explore on your own.

The game seems fascinating, by the way.

I mentioned speedrunning before in the context of mastery, but there is the other side of speedrunning that’s equally interesting: that utilizing bugs (or, glitches) to get the fastest possible time.

This 17-minute video by Msushi covers “one of the most loved and broken glitches in Portal 2” and the strange relationship the community has in following a bug to its conclusion – which, in this case, is not fixing it, but creatively using it to shave of speedrunning time. (There is an element of mastery there too, with spawning and despawning, but I don’t want to spoil the surprise.)

A 16-minute video from Ahoy from last year about Chris Sawyer, creator of Transport Tycoon and Rollercoaster Tycoon games from the late 1990s.

The video focuses more on the economics of the industry and some technical details, but what’s interesting to me was how tight those two games felt in terms of UI. They have a shared custom GUI, they are assembly-coded, and they felt perhaps like the last instance of a graphical user interface where it felt there was nothing standing between you and the pixels.

I know those are games and not productivity apps, but they can be inspiring for those, too. You can download OpenTTD, which is a modern recreation of Transport Tycoon Deluxe that doesn’t require emulation, and it still captures the snappy and tight feeling very well.

I’m thinking about it in particular because the web took a lot of that away. The web loves latency and loose interactions and reflow and temporary fonts and CSS leaks and text sticking out of the box and many other papercuts. It’s nice to be reminded of the world where things were closer to the metal, and how that felt as a user.

A 6-minute video from JHR about the 1980s British game Jet Set Willy, a big prize for its completion, the bug that made it unplayable, the copy protection, the hackers, and the mess of it all.

Perhaps the only ever musical that’s about a buggy piece of software. From the inimitable Cabel Sasser, this 2006 video about Saints Row, with three songs and a goddamn reprise at the end.

It’s very good.

my car door’s freaking out
it seems to be forever in the concrete barricade
I wonder how I’m ever gonna drive away
this really is isn’t my day
the sparks are flying
people dying
metal frying
and I wonder if there’s more to life
or if I’ll find that this is really it
this game is a piece of work

A really fun 2021 story by Fabien Sanglard at the perfect-for-me intersection of bugs and typography.

In 1991, just days before the final deadlines, Akira Nishitani, one of the graphic designers of the absolutely seminal arcade game Street Fighter II realized they misspelled the world “Warrior” as “Warrier.”

The typo was there for months and no one noticed. But the moment it was noticed, the graphic ROMs were already burned and impossible to change, and the code was due in three days.

What would you do? I’ll let you click through to read, but I really enjoyed this short story.

I have recently been on a bit of a Japan kick, and someone on social sent me this 2018 article from Clyde Mandelin about translating Japanese videogames:

There’s a common assumption that when you translate something from English into another language, there shouldn’t be any English left when you’re done. Otherwise it would be an incomplete translation, right? And you’d feel like you got cheated out of the money you spent on translation, right?

If you’re translating into Japanese, then that assumption is wrong. English makes up a significant portion of the Japanese language today, and on top of that, English has been a major part of Japanese video games since the very beginning.

I have been thinking a lot about translation ever since in the 1990s, both Windows and Mac OS have been translated to Polish, and while Windows felt okay, people at Apple used more “proper,” but often strangely archaic words for the Mac OS translation that were absolutely readable, but made the Mac felt a bit… I don’t know… medieval? (I saved both of the translations and put them up online long ago. They are still online.)

It is so hard to explain unless someone knows both languages in question, but so important to understand all these little nuances to get it right.

In the world of typing, for example, right-to-left writing systems are not just “going the other way,” but also have to accomodate LTR snippets. Similarly, is perfectly fine in Japanese to see Western words – not just next to Japanese writing, but sometimes inside it. For those working on these, it must be annoying that you already have to do more work with more complex writing, encodings, and stuff (most languages to me feel more complicated than English) – but now you also have to include entry points for other writing systems.

The issues of translation are fascinating to me. Please send more if you see them.

September 6, 2014, was a landmark day in speedrunning history.

I like Summoning Salt’s videos about speedrunners because they manage to add a great dose of storytelling to what otherwise would be boring, mundane events, and this one about Punch-Out is no exception. It’s Rocky meets Moneyball, in a way.

This pairs well with the previous review of the “Pilgrim in the microworld” book because speedrunning feels very connected to mastery and to quality – whether it’s because of the old-fashioned grind to be better, or by exploiting all sorts of glitches in the game to shave off sometimes milliseconds. The video above is in the former category, or what speedrunners would call “glitchless.” It’s also just really fun to watch. (The book wasn’t fun to read.)

If you’re new to learning about speedrunning/​glitchless, this video about “rolling” in Tetris (which itself is kind of mindblowing), and then this one about new Tetris developments from aGameScout are a great entry point.

A fun and short video from Juniper Dev about how Undertale is a fantastic game despite being fantastically poorly written:

When you make dialogue in a video game you have a distinct file that has all the possible text that can pop up in your game. This is usually a CSV file, or a JSON, and you can think of it as basically a database for text. So then at different parts in your code, you extract specific parts of this file, and that’ll depend on what character you’re talking to, if you have a certain item, whatever, and that’s one of the most efficient and common ways to do it.

But the way that Undertale handles dialogue is much worse. All of the dialogue in the entire game, every text box that pops up, is handled in one massive if statement. […] case 737 out of what must have been at least 1,000 lines.

This reminded me a little of my first week with my personal computer, when I didn’t yet know you can write IF X <> 3 THEN, so I spent half a day writing statements like IF X = 1 OR X = 2 OR X = 4 OR X = 5…

Vibe coding was there long before AI.

I gave a talk about the craft of pixel fonts at Config last year, and this fresh YouTube video by Noodle seems to be a great and quirky companion to the whole issue of “how did pixels look on old CRTs,” including many examples from modern games.

Tom Forsyth wrote about a fun bug in a Half-Life 2 reissue, of a particular flavour I have never heard before.

So I started it up, selected new game, played the intro section. It’s a fairly well-known section - you arrive at the train station with a message from Breen, a guard makes you pick up a can, and then you have to go into a room and... uh... I got stuck. I wasn’t dead, I just couldn’t go anywhere. I was stuck in a corridor with a guard, and nowhere to go. Bizarre.