Avoiding Filler in Game Design


Role-playing survival game is willing to take risks

Anime has been one of those mediums ingrained in gamer culture; a suitable fit as many gamers’ first exposure to games came from Japan. It may surprise you, but I don’t watch a lot of anime these days due to the issue of filler.

Most mainstream anime is based off of an existing manga (Japanese comic book,) and it is usually created at the same time that the manga is being written. What happens however is that the anime development overtakes the manga, leaving the studio producing the anime in a position where they have to wait for the manga to continue before they can continue the story development of the anime. The thought of going a month or so without any new episodes is not a good prospect, so the writers create a filler episode. Filler episodes have no plot or character development and most often, there is nothing actually gained from watching these episodes.

There are usually three tiers of filler, an episode, movie and the worse: a filler arc. If you ever watched an episode dealing with a flashback, clip show, or everyone stopping what they’re doing and go shopping, that is a filler episode. A movie in an anime usually involves the same pattern:

1. A new character/characters and setting are introduced that once the movie is over, will never be seen again (unless there is a sequel.)

2. Characters will not use any new powers or knowledge, if there is a case that they’ll use something new, it will be a onetime use and not used again.

3. The status quo is always restored by the end of the movie.

If you have watched any of the Dragon Ball Z movies then you know what I’m talking about. I’ve sat through four of them which the basic summary is that,” Goku gets beaten up , then hits the bad guy one time and wins at the 59 minute mark”

Filler arcs however are the worse as they combine the qualities from a movie, but go on for far longer. Another name for these is a “side-story”, but they still do nothing towards development. Naruto is perhaps one of the worst offenders of this and where I first heard the term filler hell. What happened in the series is that at the end of the main story, there is a five year gap story wise, between when the second big arc starts. However the manga was still being written, so the anime writers made around 100 episodes of filler. Think about that for a second, that’s 50 hours that nothing happened that would ever be referenced or used again. For those wondering, yes there were filler episodes within the filler arcs, transforming into some kind of filler squared situation. By the time the second arc officially aired, I was so sick of the anime that I stopped watching all together.

Before we get started I do want to make one point, the same kind of filler does exist within many animated series in the US as well. The difference is that most cartoons are not created with a serialized story line, as the majority of their episodes (except for two parters,) are standalone.

Now, after what could be considered a filler intro, it’s time to talk about how this relates to game design. Filler in terms of game design can be anything that adds tedium to the game and there are a lot of examples to go by. Essentially, whatever keeps the player from the main gameplay in the design can be considered filler, such as in a RPG, having to stop after every battle and go through several inventory screens to heal your party. Most acts of filler in game design are usually in the UI and innocuous, but the more the player is expose to it, the more it can take a toll.

If you ever played a game where you are just tired of dealing with it and turn it off, that is when tedium sets in. The act of tedium also goes back to an earlier entry, when I talked about how games have about 15 minutes to hook me before I lose interest. Finding any tedium within that time is usually the nail in the coffin for the game for me. Now the big question is how do you reduce filler or tedium?

What works for one genre doesn’t necessary work for another. In my article on skill abstraction I talked about how different gamers expect different elements in their design. When I’m playing an action game, I want information to be as clear as possible, and found easily. However, if I’m playing a game where there are a lot of stats, I want that information to be detailed, yet easy to thumb through. The trick is to understand the main focus of your design, and try to figure out what elements in your game distract from it.

If it’s an RPG where turn based combat and exploration is the focus, then anything that keeps the player from those two elements can cause tedium. Going back to the health recovery example further up, one way to make that painless is simply have the option to auto use enough health items or skills to recover your group at a push of a button, or just auto heal after the end of the battle. Now, the concept of tedium and automation go hand in hand, as the designer is adding automation to reduce the tedious actions the player has to deal with. However like all things, there is a line to watch out for when reducing tedium.

While automating actions is a great way to keep the player focused on the game, having too much automation can lead to another bad scenario, a game that plays itself. The first sign that something like this is happening, is when there is automation built into the focus of the design and not the elements that distract it. Dungeon Siege, which was an action RPG several years back allowed players to preset commands for their AI partners and their character, putting them into a situation where they can just sit back and watch the combat play out.

The second remake of Prince of Persia from a few years ago met similar criticism, but with a different design. In the game, the player could not fail any jumps or platforming maneuvers, as the AI partner would rescue the player each and every time.

Now in both examples, what happened was that too much automation was added to the focus of each game: Combat in Dungeon Siege and platforming in Prince of Persia. You don’t want to downplay what gamers have bought the game for, or in other words, order a pizza and get a cheeseburger instead. The Zelda series since Ocarina of Time has automated jumping by making Link just jump whenever he runs off an edge, and that’s fine because the gameplay pulls in the Zelda series are combat, exploration and puzzle solving.

Of course, some tedium or player control can be a good thing. In games that give the player the option to automate climbing up ladders or even adjust tax rates in a strategy game, sometimes you want to be able to control that. Automation’s biggest advantage is that it allows players a chance to learn the game piece by piece, but sometimes expert players who have a greater insight compared to novice gamers, will want to act on their own.

The last concept of tedium for this entry is one of the hardest to nail down: progressive tedium. Sometimes mechanics that started out fine become tedious as the game progresses due to more things to examine or deal with. For example, managing one city in Civilization 4 was fine; managing 10 cities was another story. While examining the early game content for tedious mechanics is important, designers also need to examine late game play to see if there are any hang ups. UI features like auto-sorting and detailed screens may not seem that big of a deal in the early game, but they can be used as a way of preventing problems down the line.

Tedium is one of those traps that designers have to watch out for and being able to differentiate between a tedious action and a meaningful one is a challenge. More gameplay mechanics doesn’t always make the game better, as hiding gameplay underneath tedium is never a good thing. The same goes for most animes as well, usually ones that have less than 70 episodes are pretty tight, which is not what you can say about the ones that are 200+ episodes. While the thought of having 100+ hours of game is an appealing one, the question however, is how many of those hours are actually meaningful?

Josh