This summer, I spent a lot of time playing video games. Is this article an excuse to validate the tens of hours I spent on my PS4 playing Horizon: Forbidden West? Probably. But it’s true that, as a Computer Science student, my interest in technology and programming began with a love for video games. Specifically, breaking them.
When playing games I would always try to glitch myself out of bounds, break AI behaviour, and disrupt the intended sequence of events enough to make the whole game freak out. Doing this can be really interesting because you get a sense of the game’s internal logic. That is, the code that’s doing all the hard work behind the scenes to hold the game together.
So, what does playing fast have to do with this? Well, the goal of video game speedrunners is to get from the beginning of the game to the credits as fast as possible, utilising the often vast array of the glitches and logical oversights in the game’s underlying code. Speedrunning has a huge community behind it – if you can think of a game, it probably has a speedrun and a dedicated community of players. Yes, even Shrek 2.
These expert players essentially reverse the game development process. They take a lovingly crafted piece of interactive software and pick it apart piece-by-piece.
Things get weird, fast.
Games that take the average player tens of hours to complete can be completed by speedrunners in just a few minutes (e.g. Prey, 2017) by exploiting glitches in the physics engine to clip through walls and soar across the map. Other players take advantage of oversights in memory storage, by entering specific inputs and performing something called a buffer overflow, where the game’s allocated memory is filled up and begins spilling out into adjacent, restricted areas of memory, overwriting important code and causing unintended behaviour. In Paper Mario, this trick can be used to transport the player straight to the credits! In Dark Souls 2, players found a way to run super fast, but only when your character uses a pair of binoculars, because of a mistake in the underlying code that alters the character’s speed value. All this is possible because of programming oversights that allow players to interact with the game in unintended ways.
‘Well-designed’ games will put in safeguards for players who glitch out of bounds and try to access parts of the game out of order. If you’ve played a lot of video games you might have come across the dreaded ‘invisible wall’ that can block access to certain areas. When designing a game, just like designing any kind of software, you need to consider all the different ways that a user might interact with your code. If you don’t, as is the case in glitchy video games, your code might produce unexpected behaviour and break down.
When testing code to make sure it runs correctly, it is important to consider what we call ‘edge cases.’ In a programming context, an edge case is a rare or unexpected input.
A simple example is a program that asks for the user to enter a number which is then stored in the program and used to perform calculations. What if the user enters a letter? If you don’t have the correct safeguards in place (i.e. the logical equivalent of an ‘invisible wall’) then the program will try to store that letter as a number, and when it tries to, say, multiply it with another value, the program will throw an error and crash! So, the program should check what the user enters, and if it isn’t a number, ask them to try again.
An analogy to this in the world of video games could be accessing an area of the game earlier than you’re meant to. In the code, there should be something checking whether you have done all the stuff you’re supposed to do first (i.e. completed a certain quest or picked up a certain item). If it doesn’t, you’ve performed what is called a ‘sequence break’ and, depending on the way that the game is designed, you might be able to continue playing in this glitchy state while skipping previous sections of the game (very useful for speedrunners!), or you might enter something called a ‘soft-lock’ where you have thoroughly broken the game’s logic and there is no way to progress.
The principles of dealing with unpredictable user behaviour is the same from the simplest of interactive programs to the most complex open world games. If you want your software to stay intact, whether from speedrunners, hackers, or people who get letters and numbers mixed up, you need to consider all the ways that a user might engage with the system.
Playing video games and learning about all the weird glitches used in speedruns is what got me interested in programming, and now I find myself going into games thinking ‘but what if I did this’ and trying to leverage common oversights that game developers make in their code. It also helps when I’m approaching coding assignments at uni to consider how the most disruptive ‘player’ might try to get my code logic to break, making more robust software in the process.
Now, the best way to get better at programming is to learn how to code, but if you’re like me and you love playing video games, have a think next time you’re playing about what the underlying logic might be doing, and the ways you might be able to break it!
About Olivia: Olivia studies Computer Science, majoring in Artificial Intelligence. In the future, she hopes to contribute to projects in AI and software engineering that make the world better! When she’s not studying you will find her painting (digitally), writing (sci-fi!), or watching Doctor Who.