Have you ever felt, when playing a game, that the dev was sitting behind you and telling you precisely what you needed to do next, and if you tried to deviate from that even by a little bit, you got smacked with a floppy pool noodle? Well, if that ever happened, it means you had a moment of clarity about the nature of the game you were playing. So let’s talk about problems and solutions to problems from a video game perspective.
The main thing to remember through all this is that games are finite. There are only so many things the developer can put into a game, and as such, the concept of a game with complete freedom is nonsensical. Then again, that concept is just nonsensical in general, but that might be a topic for a different time. However, despite this, there is still a vast difference between having no freedom at all vs having, what I’d call, a reasonable degree of freedom.
Right, with that out of the way, let’s get dug in.
Video games usually present the player with problems they need to solve to progress or even win the game. In Tetris, the problem is two-fold. The first is the cognitive challenge of determining the best position for the dropped block, and the second is the somatic challenge of manoeuvring the block into place using the game inputs. In an RPG (and RPG-like games), combat encounters are problems to be solved using the provided combat mechanics. In a story game, manoeuvring a conversation tree can be a problem that leads to different outcomes.
As such, we can define any problem we’re presented with in a video game in terms of our inputs – the means by which we control the game’s mechanics from our perspective as the player, the outputs of a problem – the various possible solutions, and the processes which translate our inputs into those outputs.
I want to explore the difference between games where all of these factors are very open and games where… they are not.
1) The solution
Suppose we apply what I described to the very first paragraph. In that case, we encountered a situation with very few (often just two) possible outputs and a rigidly defined process for reaching them. This is the unfortunate case where the solution to a problem has been baked into the very mechanics of the game. That, in and of itself, is not a problem. Instead, the issue is that you noticed and that you even felt frustrated by it when playing.
Ultimately, the limited nature of the game means that all interactions between mechanics and game content are pre-defined by those very mechanics. So nothing will happen spontaneously unless you count in bugs and particularly glitchy physics systems.
However, some developers take it too far and try to choreograph the player’s actions throughout the game. Essentially, this replaces the idea of having a toolset of mechanics (accessed through inputs) that are applied to the situation to resolve it and changes it into a kind of game of Simon Says, where the game instructs you on the inputs you have to make your monkey hands perform to succeed. Not that there’s anything wrong with dedicated Simon Says-style games. They mostly have their own niche for people who seek specific somatic challenges; these challenges are absent from these pre-baked solutions.
QTEs are the illogical end point of this mechanical degeneration. And let’s be honest, no one likes QTEs. So don’t be a contrarian; I know you’re being disingenuous. But there’s a whole range of situations that don’t reach such depths while still being flawed.
Before we get to that, though, let’s ask why exactly this happened.
2) They think you’re stupid
The developers think you’re stupid. Not you in particular, probably, but just in the sense of how the issue of the lowest common denominator is approached in modern game development. Essentially, games are made for the model consumer. And as far as game developers care (or are made to care by their financial overlords), that means something closely resembling a paraplegic, blind walrus. We’ll call the walrus Kevin.
So, if a game is done with the intent of the Kevin being able to experience it from beginning to end, at the very least, or maybe possibly even 100% the game in a single run. That means every problem in the game has to be tuned to be solvable by someone who has no idea what they are doing, and that might tempt the developer to just solve the problem for Kevin and only rely on Kevin to be able to follow on-screen instructions.
Though, to be honest, this is still the optimistic reading of the situation. It is also quite possible that the developer is at fault and that they simply cannot construct the systems (right, those inputs, processes and outputs I mentioned?) needed for their game to function outside of this context. See, the twist is that the developer can be the Kevin too, and might limit the game with their own inability to come up with mechanics that reach past imagining how the game might play out and then coding that into the game.
And while in reality, both instances happen quite often. The difference is that the latter is hopeless, while the first is sad. If someone can’t make a good game, they won’t, and there’s not much to be done about it. However, if someone is capable of, at the very least, attempting to build something of quality and doesn’t because they hamstring themselves with self-imposed limitations, that can be tragic. And that squarely falls into the field of the former issue, not the latter.
This is also the basis for the obnoxious, overly restrictive tutorialisation in modern games. Once a pamphlet explaining the control scheme was everything you got. Now, you’re lucky to start an FPS up and not get thrown into a many minutes long, unskippable, impossible-to-disable cinematic segment teaching you the basics of using a mouse to point at things. Understandably, games need to explain themselves to a new player; it’s very odd, though, that there’s very rarely any thought put into the player being already familiar with the basic workings of a computer, such as moving the mouse and pressing buttons on the keyboard.
3) A positive example
So, that’s enough complaining; let’s finish with a positive example or two of how this can be avoided.
So let’s take killing a zombie as an example, but there’s a caveat, a zombie may be only permanently killed with fire. Sounds like something that could be solved with a specific item or method for ending the zombie’s unlife.
But then there’s a game like Nox, an old Westwood action RPG which uses this same rule for a few of its undead enemies. However, the game is fully open to the usage of fire here. If there’s a fire in the environment (or lava), the corpse can be pushed into it to dispose of it. Any character class can use fire-based weapons and use them to kill zombies. Two of the three character classes also have fire magic. Ultimately, there’s nothing forcing the player to kill such zombies, and they can be navigated around, active or not, without any issue. The only loophole that might be handled better is that a zombie that’s temporarily dead (i.e. depleted of HP without being set on fire) cannot be struck with a fire weapon to kill it. But this would not come up that often.
Another game that uses similar rules is Rune, an action game on the Unreal 1.1 engine by Human Head Studios. However, this time we’re also allowed to decapitate the “zombies”, so we have a slightly different set of tools to work with. Once more, sources of environmental fire will work, though RuneGuy, unlike NoxBloke, cannot push the bodies around. He does have access to a flame weapon, though, and torches might work well too. On the other hand, the decapitation rule interacts with the player’s arsenal; 10 out of the 15 weapons at your disposal are bladed, but while only the maces and hammers won’t work, the different sharp implements of death have different attack patterns making it easier or harder to strike the neck. For what it’s worth, the only thing that feels strange here is the inability to somehow cup of grass (yes, I know) a temporarily downed zombie. Instead, we must wait for them to stand up and take another whack at the proper killing.
In both cases, how we dispatch these enemies requires a specific solution (but is it really?), yet it expresses this using general mechanics. In both games, fire is not particular to this enemy; it works on most enemies and the player. Decapitation in Rune is part of a broader system of dismemberment that works on most enemies too. In both cases, you can also often simply ignore the enemies.
Oh, and did I mention neither game necessarily says explicitly this is how you navigate the situation. Instead, they teach you about this through environmental clues and gameplay.
Esoteric Musings... 