The Cool Factor

Words: 2705 Approximate Reading Time: 20-25 minutes

Video games are as much audial and visual spectacles as they are vehicles for active engagement. And as such spectacles, one thing that some developers chase is the idea of making games look or feel “cool.”

There is not an exact descriptor of “coolness” in and of itself, and ultimately what a designer considers to be cool will be the main driver. But nevertheless, it is still possible to discern some common factors that come into play when a developer aims at coolness.

Such factors include things speed, danger, and complexity. Often things like moving quickly, having to narrowly avoid danger, or being able to pull off complex attack combinations can be seen when a developer has this coolness in mind.

Trying to make a game look or feel cool is not a bad thing. A core component of games is to spark enjoyment, and coolness is very effective method for sparking enjoyment. Coolness can often feel like a distillation of fun, compressing it down to its purest element. And so there’s a reason why players so often gravitate toward such games, and there is a reason why developers make them.

I have no issue with the attempt to make games look or feel cool, and have certainly enjoyed plenty of games that fall into this category. But chasing coolness can pose a kind of danger for a game.

Specifically, there is a fine line that can be very easy to cross between chasing coolness to make a game fun and chasing coolness at the expense of fun. This line is so fine that games that exist within the same basic genre – using the same basic factors to introduce coolness into the game – can end up hitting different marks: one fails and the other succeeds, for what might seem like almost arbitrary reasons.

And so for this essay, I want to examine that coolness factor in a bit more detail to help explain those differences. Why do some games end up capturing coolness in a successful way, compared to those that don’t?

Crossing the Line

While I noted at the beginning that video games are spectacles to some degree, and thus the visual and audial elements are important, it shouldn’t be forgotten that they are still games at the end of the day. As a consequence, the “game” component still needs to feel good, attached in some coherent way to the sights and sounds provided to the player.

Coherence requires that the player not simply understand what’s going on, but feel in control in some way. So when I press a button, I should be able to know what’s going to happen and be able to get some kind of feedback that I’m expecting. If the game starts to feel out of my control, especially when the coolness of the game is going to really rely on that control – or put another way, on the player playing effectively – then the game is sacrificing part of itself for the sake of the coolness.

But this sacrifice, in turn, makes the game less fun. Instead, it just becomes aggravating.

It’s most useful to look at this problem through a common element of coolness: speed. One way to make a game look cool is by having the player move quickly, sometimes needing to pull off complex tasks such as platforming.

An old example here is the various Sonic games, stretching all the way back to the original games for the Sega Genesis. These games were platformers, but the premise of the platforming was that your character could move incredibly quickly. This would give rise to interesting scenes where you could zip through parts of the level.

But the problem with the premise – and this is something that plenty of critics have pointed out numerous times before now – is that the platforming essentially gets in the way of moving quickly. The game has all sorts of jumps that you cannot react to, and hazards that can bring you to a complete halt. The problem isn’t that the game necessarily kills you at every turn and thus is unfair, but that the game’s premise is being undercut by the level design. Of course, you could imagine the reverse – there being no hazards or jumps at all – but that hypothetical game wouldn’t be particularly interesting.

And this is what I mean by the game chasing coolness at the expense of the game’s fundamental playability. Because even when the game doesn’t kill you, running into an enemy that you couldn’t react to or just being stopped by a wall isn’t fun. It basically takes the fun the player is having when the game goes fast and then applying the brakes.

There is an exception to this: the game does look really cool when all of the hazards are avoided and the game is continually moving quickly. That is, when the game’s premise is fulfilled. But in order to accomplish this, the player needs to essentially memorize the hazards and jumps in each level, which most players aren’t going to be willing to do.

So the core issue to think about is if you want to make a game cool, how do you plan on making it cool? That is, what is the major factor that is supposed to make the game look or feel cool to the player?

After that, ask how the game supports that coolness. If the game is about going fast, does the game support the player’s rapid movement, or continually halt them? If the game is about rapid reactions, does the game make it clear to the player when they should react? If the game is about fancy combo attacks, does the player have some way of understanding how to perform these combos?

Because all of these factors relate back to that idea of player control. When the game undercuts its core premise, control is being stolen from the player. Which means the game is undermining itself.

Treading the Line

Let’s shift our focus to a different method of bringing coolness into games, and some more recent examples.

There is a certain genre of games that is designed around very quick play. Specifically, these are games that are designed to be difficult, you could almost say designed for the player to mess up, but where failure is not really “punished.” The player’s objective is usually to overcome some small set of obstacles: clear a single short level, or kill a handful of enemies. These small objectives are coupled with an immediate ability to restart the section of the game the player is attempting. So if you mess up and die, you can simply press a button and instantly restart, without having to wait through a tedious loading screen. Let us, for the sake of this essay, refer to these as “rapid respawn” games.

The premise of rapid respawn games is that they’re supposed to be difficult, but that difficulty is then combined with the player’s ease of retrying and the shortness of the objectives. Any given death might set you back a couple minutes at most, and in many cases you might only lose 20-30 seconds.

But this combination leads to an experience that can look and feel cool when everything is done right. And often the game might even give the player the ability to record a given cleared section to watch it over. Essentially, the game wants to reward the player for success by allowing them to look back and say “wow, that was really awesome, let’s look at that again.” The player, of course, doesn’t need to review these recordings, but the point is to allow for players to share these “cool” experiences.

The rapid respawn genre can span multiple different gameplay methods. Examples include games such as Super Meat Boy as a 2D platformer, Hotline Miami as a top-down shooter, and most recently Ghostrunner as a first-person platforming and combat game.

I think it most useful to compare the last two games here to explain how this rapid respawn game, and the ways in which games can strive to be cool, can end up creating problems.

I’ll start with Hotline Miami as a successful endeavor. The game’s setup is that the player progresses through levels by taking on a succession of “floors.” The objective is to kill every enemy on each floor, with the caveat that it is very easy for your character to end up dead in the process. The game is very quickly paced, and usually beginning a fight against one enemy can alert other enemies, so you need to have some awareness of what you’re about to get into and what you can do to respond to problems.

The success of Hotline Miami lies in how well the challenge is set up. As easy as it is to die, and as frustrating as failure can feel, the repetition still feels fair at the end of the day. When you die, it commonly feels like an error on your part: you should have been more careful, or should have waited a moment, or should have been more aggressive, or should have taken better advantage of the game’s systems. The fast pace of the game means that you can’t be careless in playing, and the game is very punishing of careless play. But that punishment, at the end of the day, feels fine, because everything – or almost everything – gets traced back to the player.

In other words, the player is in control at all times, and feels in control at all times. You know what you need to do, how the game works, and what to expect as a result of your actions. After that, any failure is a failure of the player. Not to say that such failure is therefore not frustrating. But simply that the frustration is kept in check, essentially. It’s a good frustration. The kind of frustration that might drive you to keep trying.

So allow me to compare this with Ghostrunner. Ghostrunner has the player shift between platforming sections where they must navigate a path using various parkour techniques and other abilities to traverse hazards, and combat where the player uses the same techniques to evade enemy fire while getting in close enough to kill the enemies with a sword. The rule of the game is that a single hit is immediate death. So falling into gaps, getting shot, touching a hazard, or anything else potentially dangerous means reloading the last checkpoint. Of course, as I said, the respawn is immediate, and the sections are broken up in such a way that you usually don’t lose much time.

But while some of the core elements of Ghostrunner work well, there are a lot of little details that get in the player’s way. By this I don’t mean that these appear to be intentional hazards thrown at the player, but instead issues that contradict the player’s expectations.

As an example, the game relies quite a bit on running on walls to get around. The player jumps at a wall, and will begin running on it until they jump off or reach the end of the wall and thus can’t run any further. This basic mechanic is iterated on in a variety of ways, but the fact that it is so central to how the player gets around signifies how important it is to get the wallrunning right.

But running on walls can feel frustrating, which isn’t something you might expect. A lot of the walls you run on are actually panels that jut out of the wall itself. Which might seem fine, but it means that when you’re running around quickly, you can end up turning and jumping only to leap straight into a tiny corner created by the wall and the panel. Which means you fall to your death.

In addition, since so many of the “walls” are really panels, those panels have a top, which the player can walk on. Usually the player isn’t going to be able to walk on them, but since it’s possible to jump from wallrunning panel to wallrunning panel, one thing that often happens as a consequence of that jumping is that you gain height. Which means that sometimes you can be wallrunning on one panel, then jump to the next panel expecting to continue your wallrunning, only to accidentally reach the top of the panel and jump on it (or in many cases, over it). Which can set you off your expectations and lead you to making a mistake that gets you killed (or if you jump over the panel, you’ve probably ended up in a pit and thus already died).

And speaking of that jumping from panel to panel, the game doesn’t quite seem to help the player understand how this jumping works: sometimes the character jumps at an angle toward the next panel, making progression easy, and sometimes the angle basically means that the player will end up falling into a pit. It’s never clear what’s going to happen when you jump, or what you should do to get a consistent result (experimenting on the same basic section never gave any useful information). So getting through certain sections can feel like it takes luck.

All of this means that a core element of the game feels out of the hands of the player. Whether you’ll succeed depends more (or at least feels like it depends more) on the game allowing you to win, rather than how well you know the rules of the game.

That doesn’t mean, of course, that the game is impossible. And in fact, there’s no doubt that a player could gain an extensive knowledge of the game (much like a player could gain an extensive knowledge of the Sonic levels) in order to pull everything off flawlessly. Which would certainly look cool.

But it means that the player – or more specifically the average player – isn’t ultimately in control. When you die, sometimes it can be the result of your own error, and sometimes it can be the result of the game acting in a way you weren’t expecting. If we could put it more colloquially, sometimes it’s the game’s fault that you die. And what you want from this experience – any game experience, really – is that failure should always feel like it’s the player’s fault. When death becomes the game’s fault, it causes frustration, but specifically a bad kind of frustration. The kind of frustration that might drive you to just shut off the game and not touch it again.

Concluding Remarks

Trying to make a video game cool is, by no means, a bad approach. Games do not have to be profound in their design and ask stabbing philosophical questions. Sometimes they can just be pure fun.

But while making games cool is a worthwhile endeavor, it is one that must be approached carefully, just like any aspect of game design. Just because something seems cool in theory does not necessarily mean it will actually be cool in practice. And just because something looks cool when done well does not mean that players will innately be able to pull off the same maneuvers necessary to replicate it.

So in chasing coolness, it’s important to think about how much control the player ultimately has over everything. Control is often important in general for video games, but in these kinds of games it becomes especially important. Because an interesting spectacle that feels unattached to the player’s input will be little more than random noise: it will look interesting, but the player’s enthusiasm is going to fade over time. Whereas being able to say “this is a cool spectacle, and I caused it” will tap into the player’s desire to have fun and keep playing.

Therefore, when thinking about designing a game around mechanics that will look cool, it’s important to be wary of the pitfalls that can cause the game to backfire by removing this control from the player. Even just a handful of little foibles can transform that feeling of being in control – that success and failure depend on the player – into a feeling of being helpless – that success and failure depend on the game.