A fun 16-minute video from outsidexbox with 7 examples of videogame bugs where the game creators not only owned up to their mistakes, but creatively acknowledged or remixed those bugs in subsequent versions:
I didn’t know about most of these, so I did some googling and created a list for reference:
Off the top of my head, I cannot think of any non-videogame software that received a similar “bugs as lore” treatment from people responsible for the bug in the first place.
Microsoft made a blue-screen-of-death screensaver, but it was originally third-party, and kind of a prank? A mean-spirited one? I didn’t find this particularly good.
The 2016 launch of No Man’s Sky and the 2020 launch of Cyberpunk 2077 were catastrophes. No Man’s Sky fell so incredibly short of the promises the founder shared over the years – from smaller ones like rivers on the surface of planets, to huge ones like seeing other players – that some people felt it must have been a scam all along.
The other game was a simpler case study: Cyberpunk was buggy as hell. Not just the abysmal performance, but also the overall quality. People called it “the Hindenburg of videogames” and made YouTube compilations and listicles of its often hilarious bugs: cars exploding for no reason with perfect comedic timing, intimate body parts protruding through the clothes, and the infamous T poses.
In an unprecedented move, Microsoft slapped a big warning atop Cyberpunk’s app store listing, and Sony pulled it from their store altogether.
Over a decade on from its initial reveal, No Man’s Sky both manages to remain the same game it was at launch while also bringing almost every single missing feature (and dozens of new surprise ones) into the title – implementing them intelligently and with great consideration for how it will affect the core of the game. They achieved their redemption years ago, yet continue diligently with massive update after massive update.
No other title has done what Hello Games have managed to achieve. And the best part? Every single update, patch and addition to the game was and is 100% free, with no falsified hype or build-up to each update.
Cyberpunk 2077 had a redemptive arc of its own, too, highlighted and contextualized in this 17-minute video from gameranx. Today, both games are rated “very positive” on Steam, and are actually still gaining daily players.
So, wonderful comeback stories, right? Depends on how you look at it. It’s great that both these games ended up being good products, but perhaps not as great that it was all happening in the open.
The videogame industry tried to get creative about it and established an idea of “early access”: being able to purchase an incomplete game earlier, and watch it get better while the publisher receives funding to keep going. But for every Minecraft there is Godus, and for every Kerbal Space Program there is The Day Before. Plus, neither No Man’s Sky nor Cyberpunk launched in early access with attendant caveats and discounts. (By the way, Wikipedia’s entry for early access is worth checking out – it’s so eloquent I’m surprised not to see any warning boxes.)
There seems to be ongoing and perhaps rising frustration with companies releasing software products too early and fixing them in flight, if at all. Already in 1996, Geoff Duncan wrote about his annoyances with that:
What Beta Means Now: […] In many cases – particularly with Mac Internet software – “beta” doesn’t mean anything close to what it used to. We’ve seen programs in public beta that not only contain innumerable known bugs the developers are aware of and plan to fix, but also accumulate major new features through subsequent releases. Similarly, we’ve seen products that change fundamental system and technology requirements during beta – details which should have been etched in stone long before. Beta often means what “alpha” or even “development build” used to mean.
Subsequently, Google and other web-first companies diluted the meaning of beta labels even more.
The trend of premature launches extended to devices, too. About two years ago, AI assistant gizmos from Humane and Rabbit were pilloried by audiences for launching in an effectively unfinished form. Both devices failed in the market; MKBHD’s video reviews of Humane AI Pin and Rabbit R1 remain both entertaining and informative watches.
Reading between the lines, Mehotra’s interview paints a picture that I think many tech workers will find familiar: features are conceived, coded, and shipped as quickly as possible. He is happy to admit that the feature was a mistake… in retrospect. But in the moment it actually mattered, critical thinking was swept away by the false urgency of pushing things out.
It is worth reading in full and following the links, too; I watched the mentioned (tense) interview, and was similarly frustrated with the CEO’s lack of accountability or even a hint of an explanation of why the feature was launched to begin with. Key line from Samsonov’s post:
If you don’t know what are you trying to learn when you ship a prototype, do not ship a prototype.
This becomes even more important as the difference between a prototype and a final product is now thinner than a retina pixel. Both No Man’s Sky and Cyberpunk had, at least, well thought through foundations.
I understand that for some people gen AI software building tools is a discovery – perhaps for the first time – of a genuine joy of creation. But there’s also the other, newish side, a sort of “cult of velocity” where people show screens filled with agents coding things as if the world needed every possible app right this second.
Velocity and urgency can be important, but it’s hard to be careful and thoughtful when you’re going really fast; unsurprisingly, some don’t know what to do with that newfound AI-powered speed or realize the importance of thinking about crucial aspects other than time to market. (When digital cameras came around, the barrier to entry for photography was drastically lowered – it was possible to take a lot of photos without worrying about cost or quality. Tons of people took tons of objectively subpar photos; some were the end goal, some were a stepping stone toward more photographic mastery. However, I am not sure I remember people on either side ever bragging “I took over 1,200 photos today!”)
All this could be contrasted with movement of slow software (the name is part of a bigger slow movement although has unfortunate connotations in tech – it’s slow as in “speech,” not slow as in “beer”). Jared White in 2023 defined it as:
Sustainable software. Architecting and writing code in ways which are easily understandable and maintainable over time, requiring few dependencies and a rate of change that is healthy for the underlying ecosystem.
Thoughtful software. Working through feature development and making decisions based on what will benefit the userbase over the long term, placing mental and social health as priority over immediate gains or selfish interests.
Careful software. Seeking to understand the ways software might be used for harm, or itself be harmful by taking attention away from more important concerns in the broader culture.
Humanist software. Recognizing that most software—at least in application development—is primarily written for humans to understand and reason about with ease across a wide array of skill levels, and that relying on complex code generators or “generative AI” tooling to resolve complexity instead of simply building simpler human-scale tools is an industry dead-end.
Open software. Looking to established collaborative software movements like open source and the standards bodies responsible for open protocols to inspire how we build and maintain software (regardless of licensing).
I don’t really have a conclusion for this meandering post, as I am not sure a snappy conclusion is possible. Perhaps some of the links above can provide inspiration or food for thought about urgency, reputation, and doing things in the open.
Some patterns I’m noticing are:
Velocity is never an end goal.
Velocity is only one of many ingredients of software building.
It is necessary to think of people who will experience your work-in-progress as it is, not as it might one day be.
In short: One of the professional teams in the FPS game Squad built a sophisticated set of scripts that made it easier to use the game for esports tournaments by adding additional UI, useful stats, a floating camera, an extra over-the-shoulder view, and so on. The community embraced the scripts as they genuinely made the spectating much better.
Months later, it turned out that the creators not only hardcoded easier rules for their own team, but even added a pretty comprehensive set of cheating keyboard shortcuts.
The useful esports spectating scripts were, in effect, a trojan horse. A fascinating story, plus an interesting case of psychology of cheating.
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.”
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.
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.
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.
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.
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:
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”:
“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…
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.)
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.
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.
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 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.
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 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
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
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.
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?
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.)
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…
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.
