Table of contents
No headings in the article.
With so many moving components during development, the games we create often contain unexpected behaviors. Some of these interactions pop up due to unintended gameplay states being allowed, while others appear from a hidden mechanic occurring between subsystems. In either regard, these “loopholes” present an interesting question for game developers - should we keep them as-is or dedicate time towards patching them out?
Keeping Loopholes In
Personally, I find the development process the most exciting when new ideas come up while implementing core features. You may suddenly think of a better approach to use, another way for systems to interconnect, or even a way to add more depth to a mechanic. The unexpected can be the special “sauce” that your game needs to feel complete.
Essentially, you want to keep loopholes present in your game when they open up additional gameplay options and enhance the player’s experience. A good example comes from one of my favorite games - Raft. As you float around the world, entering certain coordinates allows story-based islands to generate. These are meant to be linear in nature and grant items that help you progress at specific points in the story.
The “loophole” here is found in the loot that generates on the islands, as they can reappear whenever the player leaves a story island and then comes back. Narratively, this would not make sense as the player has already retrieved the items once. As a game developer I know this assumption skips many steps, but they could easily patch this out by tracking items picked up after leaving.
The developers purposely chose to leave loot respawning in place though, and there is a good chance that it came down to the gameplay value it adds:
- Players like collecting resources, so another method is enjoyable
- The exclusive items are more reliable to collect
- It opens up end-game content - players can now set up travel routes between story islands
- It gives replayability to story islands
I would not rule out the possibility that there was not enough time to address this loophole. However, once they saw how players responded by using the unintended feature to extend gameplay, there was likely less of a reason to address it.
Keeping Loopholes Out
Conversely, loopholes should be removed when they compromise the intended gameplay experience. If a loophole decreases engagement, then it is simply blocking what the player is trying to achieve in the game.
Imagine playing Super Mario Bros and a specific checkpoint accidentally turns the star ability into a permanent one. Certainly, the player will feel overpowered for a while, but as the element of challenge slips away they will quickly lose interest. It may even be fun for the entire gaming session, but when the player is trying to decide what to play the next day, there is a good chance they will pick up another game that still holds “mystery.” For a game that relies on the vulnerability of the character and the complexities of platforming, this loophole completely erases that intended experience.
There is a popular phrase within the development community that captures this sentiment perfectly - “It’s not a bug, it’s a feature.” At least in my experience, this phrase is used when a loophole appears and provides “valid” reasoning for avoiding the difficult task of making necessary changes. What that decision does however, is push the flaws of the game onto the player in order to explain why “it is not a big deal.”
Suddenly, that loophole causes the player to maintain two tasks. They need to progress through the game while also subconsciously finding ways to explain why a bug still fits. Even if they can look past it, you can begin to see how loopholes can compromise gameplay experiences by breaking immersion.
What About Time Constraints?
Game development is a dedicated process requiring tons of resources, time, motivation, energy, and more. When considering what loopholes to keep or remove from your game, you may also wonder if you have the time for it. Indeed, this can influence what decision you make! This is where the famous “minimum viable product” idea found on every indie game dev thread comes into play. Understanding where your game reaches a “1.0 version” or “pre-alpha state” provides an important threshold.
If you are just starting development, then you are more inclined to keep loopholes in. The goal is to spend the majority of your time achieving the baseline of your game. Unless they prove to be game-breaking, loopholes are oversights in design that are best addressed during the “polishing” stages of development. The best case scenario here is that leaving in loopholes will open up new design opportunities later in development that might not have been considered otherwise. Worst case scenario - you at least achieve a minimum viable product within a reasonable time and can afford to address it.
By the time you near the end of development, this is where you are more inclined to remove loopholes. With a nearly complete game, you are able to carry out testing far easier and have a better idea of how the indented gameplayer experience has translated over time. Essentially, you will have a stronger approach on how best to remove or change loopholes as compared to earlier development stages.
TL;DR
When faced with a loophole - i.e an “unintended gameplay feature” - it is worth considering if it should remain in-game or have it patched out. The best approach is to consider if the loophole adds value to the game without affecting the player’s intended experience. Beyond this, consider what stage of development you are in as a way of making a more informed decision.