As an avid computer gamer, I came across the speedrunning scene around 2017, which is about playing through a video game (or parts of it) as quickly as possible using glitches.
"Glitches? That's nothing more than a programming error!"
As a developer, I thought "Glitches? That's nothing more than a programming error!" And so I began to see speedruns not just through the eyes of a player, but through the eyes of a developer. One of my realizations - game development and frontend development share certain concepts and thoughts - is that there are frontend javascript frameworks that can be used to develop video games.
Both development environments have stores to hold data and use events to process user input, and both have similar pitfalls if a user triggers certain events at the wrong time. For both, the store should be centrally managed and only be able to accept defined, clear states.
An example of a glitch that can be mapped to front-end applications is one of the most famous glitches of all time - the Backwards Longjump (BLJ for short) from Super Mario 64.
In this game, the speed that Mario can build up is limited at the top - but you can go backwards as fast as you like if you press the correct buttons on the controller. This allows you to become so fast that Mario can cheat his way backwards through an invisible wall, which should always put him back at the top of a staircase.
Due to the speed, you are in front of the wall in one frame and behind it in the next frame, the collision itself never takes place. Examples like this remind me as a programmer that I should not use shortcuts when validating user input, nor should I assume that the user only sends data that I expect, but that theoretically any value could be sent.
Features that are added "just in a hurry"
Other problems in development are often features that are added "just in a hurry", which are well-intentioned but perhaps not one hundred percent necessary or according to the usual quality standard. It can then happen that the new code has side effects that the developer did not expect. An example of this is the game The Legend of Zelda - Link's Awakening, which is full of such features. Originally the game was supposed to be a "demake" of a Zelda game on the Super Nintendo, but the developers implemented a few features to make it stand out from the original.
One of these features is the bomb arrow - if you use a bomb within a few frames of an arrow, the bomb is attached to the arrow and explodes on contact. The flaw here is that if you manage to place two bombs in succession within this short period of time (e.g. through a hole in the ground or a screen change), the game does not know where to attach the second bomb and triggers a cutscene of a game object at a certain point in the code. In the case of collectable items, this means that you can collect them from any distance and through walls. At other points in the game, you can use it to unlock paths that should only be opened later or by other, longer-lasting methods. Examples like this show me that "just a quick one" is a phrase that you should think about very carefully.
Whether backend or frontend - everyone cooks with water
In addition, frontend developers should always remember that the executed code can be viewed in the browser at any time, and that the various build tools such as WebPack, Rollup and Vite are often set by the developers themselves to generate source maps that make the code explicitly readable. Of course, this means that even the best security measures in the code can be traced at any time, and it is better to rely on the security in the backend code.
In the case of video games, this can be seen in two ways. Firstly, it is possible to look at the working memory of the executed game in order to understand which value represents, for example, the health points, ammunition or similar. If you understand these values and can even manipulate them at best, you can create "perfect" speedruns. On the other hand, there are projects that analyze the compiled code of games and explain the processes. In this way, internal aspects such as the random generator used or the behavior of opponents and other game mechanics are made known, allowing new glitches and strategies to be developed.
All in all, it can be said that all programmers - be it backend, frontend, games, desktop applications, ... - also only boil with water and have to pay attention to fairly similar problems. So why not play with fun and speed?
Questions about front-end development?
Contact us directly if you have any questions about development.
Old certainties are crumbling, new questions are emerging. Who actually decides on technology? How independent are we really? And what role does open source still play? We share our observations from a year that has reorganized many things.
Working at punkt.de - getting started and the first few months
I've been at punkt.de for four months now and in that time I've already taken part in the team days, the Just Do It Day, as a helping hand at a conference and experienced a project going live.
