These days game developers spend quite the amount of time polish their products to perfection. Readily available engines, for example  Unity3D or Unreal Engine, leaves implementation of gameplay critical features such as collision to a dedicated team of experts, leaving us developers with a near perfect platform to build a game on. With minor tweaking glitches such as clipping through walls are practically extinct. Is this good or bad? A little bit of both.

For the speedrunning community this is a disaster. For those of you who do not know, speedrunning generally denotes clearing a game (or equivalent goal) as fast as possible given certain restrictions or sub-goals (e.g. any%, 100%, no save+quit/deaths etc.). The reason these categories exists is mostly because of the abundance of glitches prevalent in games. Patching non-critical glitches would be detrimental to the speedrunning community and would effectively alienate them.

Critical glitches?

Critical glitches would be glitches that occur seemingly randomly to a player and hinder gameplay. Non-critical glitches however defines glitches that require a certain knowledge of the inner workings of the game and would be unlikely to occur during normal gameplay. Sometimes these types overlap, i.e. you might find a glitch which appears to add no value but during a single point in the game could change everything.

Example of non-critical glitch

This glitch is predictable, requires specific input and resources, is a valuable time-saver and would not be likely to occur randomly in any given regular play session.

Example of critical glitch

The glitch here is that the pickups (blue packages) appears to randomly have solid collision with the player. This causes the player (boat) to bump and potentially, as in this case, get knocked out of the water. This glitch appears to occur randomly and has little to no value. Even if it would be valuable to get bumped off water a boat cannot move on land anyways, giving no purpose to this glitch.

Patches

Even if glitches are discovered after release, platforming tools such as Steam makes it seamless for developers to push out fixes silently to all users. Speedrunners are deliberately playing on older version in order to preserve glitches otherwise fixed in later releases. For reference, check out the “exclusive glitches” for the different original Legend of Zelda: Ocarina of Time versions here on zeldaspeedruns.com. A more modern example is Borderlands 2, in which several valuable glitches have been patched over time which causes avid speedrunners to stay on version 1.1 (latest version as of this post is 1.8).

Exception: multiplayer games

Multiplayer games are tricky. Generally, all bugs should be fixed in multiplayer-only games so that no player can take advantage of exploits in an unfair way. Singleplayer games should follow the rules I made up above, but games that include both singleplayer and Player-vs-Player oriented multiplayer fall into a sort of gray-zone where some non-critical glitches may be allowed and some might not. Co-op games still benefit from having these glitches (e.g. Borderlands 2) but PvP games have to tackle this on a per-glitch basis. Historically, players in multiplayer games have been close-knit and decide upon the unofficial rules unanimously (e.g. Mario Kart, where certain glitches can skip a lap), but with todays online connectivity the safer route (better game, more player, more revenue etc.) would be to patch these glitches no matter the severity and accept that all games are not made for speedrunning.

Why design for speedrunners?

Mostly to appeal to a broader audience and to extend the longevity of your product. Players today still find crucial glitches in popular games including Legend of Zelda: Ocarina of Time (1998) and GTA: Vice City (2002).

As long as you provide an official service for a user to acquire the game (e.g. Steam) you will also have an extended stream of revenue. It is hard, if not impossible to come across a legit N64 game sale which still generates revenue for Nintendo.

If done correctly then there is no harm in it. As long as the glitches do not interfere with your average casual gameplay then you essentially have created two games at the cost of one as the rules of the later (glitched version) are determined and understood by those who it concerns, leaving you as a developer with no responsibility that it is a rich enough experience.

You should not go as far as to design gameplay elements specifically around glitches though. What you will end up with is a cryptic game mechanic which in it self is a valid topic, but unrelated to the glitches spoken of in the speedrunning community. If you however find a glitch during development then note it down but leave it be unless it causes major nuisance.

AGDQ, a speedrunning charity that raised over $1m for the 2014 run.

Other design aspects

Though glitches make up the majority of the “speedrunnable” factor some considerations should be taken when designing games to allow for a more fluid gameplay experience. Some examples include:

• Skippable cutscenes
• “Skippable” dialogs (fast text)
• Depending on the game, provide timing options (e.g. time played, best time for a map etc.) (sometimes this is not relevant, here is why).
• A clear end-goal (e.g. defeat the final boss)
• Optional goals (for more diverse categories)

About Kenth Ljung

2012 Programming

View all posts by Kenth Ljung →