Emulating Classic Games in HD – Part 2

Last time, we learned the basics of the Game Boy hardware, and tried a simple strategy for rendering games with high-res graphics. Sometimes this simple approach worked well:

but other times it didn’t work at all:

In this part we’ll look at the timing of the Game Boy display hardware, and see how this interferes with our simple scheme.

Horizontal Blank

Computing the appropriate color for a pixel, given the background and sprites, takes time. As such, the graphics hardware does not compute colors for the entire screen simultaneously, but instead render pixels one at a time via raster scanning.

If we imagine how an old-fashioned CRT display scans out an image, there is an “electron gun” that scans each row of pixels from left to right, and proceeds down the screen through the rows. While the GameBoy uses an LCD screen rather than a CRT, it employs a similar notion of how the screen is scanned. Pixels are scanned from left to right in each horizontal line, and lines are scanned from the top down.

After the each line has been scanned, it takes time for the “electron gun” to move back to the start of the next line; this time is called the horizontal blank. At the end of the last line, it takes an even longer time to scan back to the start of the first line; this time is called the vertical blank.

During the two blanking periods, no rendering takes place. Because the rendering hardware is idle during this time, it is possible for software to safely change the values of hardware registers and affect how the next line will be drawn. For example, in Super Mario Land, the level scrolls from right to left as the player progresses, but the status/score display does not. In order to achieve this effect, the game changes the horizontal background-scroll register at the end of line 15.

A Less Simple Renderer

Now it should be clear why our simple rendering approach has problems: it only looks at the values of the hardware registers at the end of a frame (vertical blank), but those registers might have changed on each and every scan line (horizontal blank). Once we realize this, though, it is really quite simple to work around

First, we need to “snapshot” the state of the graphics registers at the end of each scan line. A clever implementation might only take a new snapshot when one or more registers actually change, or might store compact deltas, but my implementation takes a pretty naive snapshot at the end of each line.

Next, instead of rendering a textured quad for every tile, we can simply render a one-scan-line tall textured quad for every tile for every scan-line. On each line we render the tile using the state snapshot for that line.

This approach is somewhat wasteful of CPU and GPU time, but it rectifies the problems we saw before:

Try It Out!

I’ve gone ahead and thrown the code (such as it is) up on GitHub, just to prove I have nothing up my sleeves. You can also download a pre-built binary of the emulator for Mac (I haven’t had time to work on a Windows build yet, sorry).

Keep in mind that this is only a proof of concept; the controls are hard-wired, there is no support for save states or save slots, and it only supports a handful of Game Boy games.

Next Steps

My goal here was to show that this kind of graphics replacement was possible in theory, and I hope I’ve achieved that. I don’t have the kind of time it would take to turn this project into a real, usable emulator, so if you want to fork the code and run with it, feel free.

Scaling this approach up to a more powerful console would bring some interesting challenges, so I’ll throw out a few notes for anybody who might be interested in trying. Readers should feel free to bail out now if none of this makes sense:

  • I dealt with palettes in the easiest possible fashion: I use a 4-channel image to store weights for each of the colors in a 4-color palette (effectively treating the palette as a basis). For 16-color palettes this would involve 16-channel images, which is still pretty tractable. Beyond that, you’ll probably need a new technique.
  • Because the GameBoy is pure grayscale, it was easy to “project” arbitrary grayscale images into this basis by expressing them as a weighted sum of colors from the palette. For more complex palettes this runs the risk of being over- or under-constrained, so you’d likely want a tool to directly edit replacement images in a paletted fashion.
  • More accurate emulation is often required for more interesting consoles. In order to handle mid-scan-line effects on things like the NES, you might need to draw the replacement graphics on a per-pixel basis, rather than the per-line approach I use. In that case, it would help to detect when the graphics registers change, and only do the more expensive rendering when/where required.
  • I’ve ignored relative sprite priorities in my emulator, but I know that subtle priority details often have big effects (e.g., the clipping for item blocks in Mario 3). The key to getting priority right while still using replacement graphics is to cast the pixel-compositing operations usually applied into something like the Porter-Duff algebra, which will naturally scale to images and alpha transparency.
  • Many SNES games use HDMA to make rounded shapes (e.g., the Power Bomb in Super Metroid) or wavy distortion effects (e.g., Phantoon). If these kind of scanline effects get scaled up, they will become blocky. Ideally, an emulator should be able to interpolate between the state of registers at different scanlines to smooth out these shapes. The challenge then is figuring out when not to interpolate.

Emulating Classic 2D Games in HD – Part 1

Many emulators for 3D consoles support rendering games at higher resolutions than supported by the original hardware. Some emulators for older 3D consoles even support replacing the texture maps used in games with higher-resolution versions. Emulators for 2D consoles, such as the venerable Super NES, have no such functionality. Frames are rendered at the original native resolution, and then may be upsampled to higher resolutions using a handful of simple filters.

Why can’t we play classic 2D games in HD? Couldn’t we take the same concept of replacing low-resolution texture maps and apply it to inserting high-resolution sprites or background tiles into 2D games?

I’ve seen comments from emulator creators that this just isn’t possible, but I hadn’t really seen a solid technical explanation. So I decided to find out the answer for myself. Just as a little teaser, though, I’ll say that I was pleasantly surprised by what I could achieve (my own poorly-drawn programmer art aside):



Super Mario Land, now at 4 times the resolution!

The Game Boy

In order to understand both the opportunities and challenges, we need to cover some background on sprite-based 2D graphics hardware. To keep things simple, both for my implementation and for this article, I’ve chosen to focus on the original Nintendo Game Boy.

The Game Boy has a 160×144 pixel LCD screen, and uses 4 grayscale colors (2-bit color). Rather than store the image to be displayed in a frame buffer, the hardware renders the image by compositing three kinds of elements: the background, sprites, and window. For simplicity, I’ll only talk about the first two.

Background Tile Map

The background is a 32×32 grid of tiles, where each tile is an 8×8 pixel image. Thus the background defines a conceptual 256×256 pixel image.. We can represent the background as a 32×32 array of tile indices (the tile map) along with an array of the corresponding tile images.

uint8_t tileMap[32][32];
TileImage tileImages[256];

Since the background is larger than the screen, two 8-bit hardware registers are used to scroll the background and select what part will be visible. As we scroll past the edge of the background, it repeats. A game can replace tile indices that are out of view to implement a continuously-scrolling map.

Sprites

The sprites are defined by a structure called the Object Attribute Map (OAM). The Game Boy supports 40 sprites, and each sprite has an X and Y position, flags for horizontal and vertical flip, and the index of the tile image to use:

struct Sprite {
    uint8_t x;
    uint8_t y;
    bool flipX;
    bool flipY;
    uint8_t tileIndex;
};
Sprite oam[40];

Tiles

Both the background and sprite use tiles to define their image data. Each tile is a 2-bit-per-pixel paletted image (yes, even though the Game Boy only supports 2-bit color, it uses paletted images). An 8×8 pixel tile takes up 8x8x2=128 bits (16 bytes). There are distinct color palettes for sprites and the background:

Color bgPalette[4];
Color spritePalette[4];

In the sprite palette, color index zero is special: it indicates a transparent pixel.

Take-Away

There are, of course, a lot more details to the Game Boy rendering hardware, and other 2D platforms will of course have different designs. Still, these basic concepts – tile maps, sprites, and paletted tile images – are shared by many different 2D consoles.

Tile Replacement

In order to render a Game Boy game at higher resolution, we must find a way to map the existing 8×8 tiles to high-res replacements. A simple approach would be to hash the contents of the tile image, and use the resulting hash as a key for a table of replacements. In the case of the Game Boy, tile images are only 16 bytes, so we can just use the tile data itself as our hash key. Of course we also need the replacement images; for now I’ll be using my own programmer art:

On the left we have an original sprite from Super Mario Land, and on the right we have my replacement. The use of paletted images complicates this process somewhat, but let’s ignore those details for right now.

A Simple Scheme

At first blush it seems like we could accomplish our goal with a relatively simple renderer. Whenever a frame needs to be drawn we can:

  • Iterate over the background tile map, and draw one textured quad per background tile.
  • Iterate over the sprites, and draw one textured quad per sprite.

We need a cache that maps tile images to texture maps, but that can easily be folded into our tile-replacement step.

Let’s try this scheme out on a few games (note, I’m only replacing a subset of tiles right now – even programmer art takes time to create):




Link's Awakening

Those results seem good (my terrible art skills aside). Suspiciously good, in fact, if I’m claiming that this problem merits a whole article. And yes, if we look a little harder we can find examples where the results of our simple renderer are not as satisfying:




Super Mario Land again, not looking as good




Castlevania II looks like a complete mess

What is going on in these images that makes them fail? In Part 2 of this series, we will discuss the timing of sprite hardware, and see how to resolve these graphical issues.

Metroid: Other M

When I find that my feelings towards a game are ambiguous, I like to look at its design decisions (whether gameplay, technology, art direction, or narrative) and categorize them into “what worked” and “what didn’t work.” In the case of Other M, though, I found that my “what worked” pile was pretty thin.

Other M is a competently made game (though not, obviously, without bugs). As with almost any Nintendo-published game, it has that layer of polish and an overall cohesiveness that make it stand out from the pack. But these are not enough to make a game good – competence and cohesiveness should be the least we demand from our games.

The best thing I can say about Other M is that it is very aware that it is a Metroid game. It’s overall structure (both in narrative and world design) is an obvious homage to Metroid Fusion. Samus’ powers are precisely those she acquired in Super Metroid. The morph-ball sequences show a clear influence from the Prime games. The best enemy designs are those lifted from prior games, and the best boss fights are effectively cameos. Other M even acknowledges some of the more silly aspects of the series mythology (e.g., the “evolved” forms of Metroids) which had been quietly ignored by the Prime games (over the course of which series the story has increasingly been sanitized into generic sci-fi pablum).

Put that kind of pastiche before a dedicated Metroid fan, and they might play through the whole thing on auto-pilot. Samus is a fun character to control; her full suite of abilities allow most situations to be tackled in a variety of ways, and so mastering her moveset lends a sense of fluency to interactions that most characters lack.

Once Other M steps out of these narrow confines of emulation and homage, though, things get rockier. The modifications and extensions to the Metroid formula all serve to compromise the fluency of the interface between the player and Samus. Perhaps this was intentional – calling attention to and disrupting the interface between the player and Samus as avatar to serve the narrative goals of portraying Samus as Other.

I could almost believe that if the storytelling on display wasn’t so painfully clumsy and ham-fisted at every term.

I’m definitely in the crowd that doesn’t feel that the Samus we see in Other M is the same woman we saw in the other games. It isn’t that the other games were laden with characterization, but what was there (even in the story-heavy Fusion) is almost entirely contradictory with Other M.

My wife, for her part, sees the portrayal of Samus in Other M as part of an overall downward trend in Nintendo’s handling of the character, that started with the introduction of the “Zero Suit.” Samus has always stood out as gaming’s first, and for a long time, best, female role-model character; now she is portrayed in-canon as walking around in a skin-tight leotard and desperately seeking male approval. One can’t really expect female gamers to respond any better to this than toward Aya Brea’s revamped in-game portrayal.

(I’ll leave aside the issue of the Justin Bailey code and the uncomfortable strip-tease that has become a hallmark of Metroid endings. Maybe objectification of Samus has been with us from the start, but it was easier to overlook when it was restricted to low-fi graphics in an “easter egg” or special ending.)

I’ve played enough games with embarrassing or poorly translated stories in my time that I might have been able to give Other M a pass if the gameplay had held up. Unofortunately, once you get out of the “auto-pilot” situation I describe above and look at things carefully, it doesn’t hold up.

Moment to moment, playing Other M gives you the sense that a really great 2.5D Metroidvania could be built on this engine. The same could be said of Chair’s Shadow Complex. The problem for both games is that the world map and player progression just don’t live up to the promise of the moment-to-moment gameplay.

Like Metroid Fusion, Other M actively thwarts attempts by the player to explore out of the prescribed sequence. Arbitrary locked doors that only open on storyline triggers (the so-called “broken bridge” trope) are a distinctly un-Metroid concept. While Fusion also succumbed to this problem, it also used the design trick of letting the player think they were going “off the rails” even when they were following the designated path (an approach used to great effect in Portal). In contrast, Other M never really tries to give the player this sense of subversion (with one late-game exception: using the power bomb to break out of a stalled elevator), and as a result the player is left with the impression that the designers are leading them on a short leash from one expository cut-scene to another.

Other M has innumerable other gameplay foibles that further limit the potential for enjoyment:

  • The first-person view is tedious and clumsy to use in battle (leading to many cheap hits from enemies while waiting for the Wii remote sensor to register a perspective change), and leads to the most frustrating and horribly un-Metroid gameplay bottlenecks with the mandatory pixel-hunting sequences. The battle sequences that played out in first-person were a frustrating exercise as the player had no way to avoid damage but to expertly use the clumsy controls. That these unnecessary and unusable first-person elements were used to advertise the game in a world where Metroid Prime had already showed just how well a first-person Metroid could play was unbelievable.
  • The fact that most of the hidden items can only be acquired in the late- or post-game as part of a fetch-quest “cleanup” pass is irritating for fans of the classic Metroid formula (although Zero Mission commits this same sin). Putting the last few power-ups behind power-bomb-able panels that trigger pointless button-mashing QTE-laden fights was also a kick in the teeth.
  • For that matter, all of Other M‘s combat “innovations” were pretty lackluster. The idea of giving Samus more melee options might have sounded good on paper, but the implementation basically boiled down to QTE finishers plus a “mash me to not die” button. An even more egregious sin was that the game would sometimes expect QTE input during what looked to the player like a cutscene (without any on-screen prompt), so that a player would never know which threats Samus faced in a cut-scene needed to be dodged, and which were just scripted choreography.
  • This final point leads to the most important realization that led me to conclude that Other M is not a good game (whether interpreted as a Metroid game or not): Other M sets up a contract with the player and then violates its own rules. I’ll get to how in a second, but let’s talk about the “authorization” system:

    The presentation of authorization is patently ridiculous (which negates its purported benefit of “finally” explaining how Samus loses all her powers between games). It also breaks the important link between exploration and discovery that is the core of the Metroidvania genre. Other M doesn’t reward exploration with new abilities for Samus – at best it awards her with a few more missiles, a longer health bar, or shorter charge times – and so exploration is no longer the driving force behind the player’s progression. Instead, abilities are tied to story progression, and so the player’s first priority is (nominally) to advance the story. Unfortunately, the way that new powers are almost always given out right after they would be useful leads players to feel resentful when a new ability is authorized, rather than excited to try out the new tool.

    This is the opposite of how a traditional Metroidvania works. Usually you’d notice ledges you can’t reach or walls you can’t break through, and upon getting the item that would render those impediments surmountable you’d be excited to go back and see where they lead. In Other M you are just annoyed at Adam; his stinginess has forced you to backtrack again.

    For all its faults, though, the authorization system sets up one important and immutable rule – a contract with the player: a new ability can only be used when the requisite “authorization” cut-scene has played, hilighting the new item in Samus’ inventory. As a player you can count on the fact that any puzzle and any battle that you are expected to tackle along the main story-line can be bested with just those abilities that have been explicitly enabled.

    That is, until the very end of the game, where you are suddenly required to make use of Power Bombs, without any prompting, within a limited timeframe, or else Samus will die. Before this point you have probably already seen Samus die rather than use her Varia suit, so why are players expected to know that Samus should now use her Power Bombs without permission rather than die a pointlessly noble death? Once players do figure out this ridiculous “press X to not die” QTE they are rewarded with a post-facto authorization cut scene, but the damage has already been done: the game has violated its contract with the player.

    And for what?

    This scene was probably meant to be a cathartic one for the player: the culmination of the marriage of story and mechanics that the “authorization” system had represented. Unfortunately, the game designers crafted an ending that relied on players feeling a particular way: they wanted players to think that they had nothing to lose and could thus finally cut loose and use the most destructive weapon in their arsenal without concern – Samus finally acting like the independent and resourceful bounty hunter we had always thought her to be.

    Speaking for myself, though, this wasn’t how the game made me feel. I had spent hours of time with the game, in which Other M struck down my every attempt to break out of the strictures of its narrow world design, and had listened to its plodding narrative tell me that Samus was incapable or unwilling to act on her own. Other M had left me feeling powerless and without direction – it had turned me (and Samus) into the kind of person who would sit patiently in the stomach of a monster, waiting for death, not even thinking to use the one weapon in my arsenal that might have saved my life, because the arbitrary fiat of my commanding officer (or rather, of the game designer, finally revealed once the mask of Adam had been cast aside) had not explicitly sanctioned it.

    So there’s another “positive” thing to say about Other M: it would make a good tool for inculcation of recruits into a regimented military organization or totalitarian regime in which independent thought must be supressed, even to the point of death.

    Final Fantasy XIII

    It should no longer be surprising when a new Final Fantasy game leads to violent disagreement among fans of the series. The characteristic marriage of over-the-top production values and highly experimental game design remains a winning formula in spite of – or perhaps because of – the controversy surrounding each new release.

    I still haven’t made up my mind about FF13; both the supporters and detractors make valid points. There are some things the game does brilliantly, and other areas where it just falls flat. Given this situation, I thought it would be appropriate to look at some of the design choices made in this game, talking about which of them worked, and which of them didn’t.

    What Worked

    Automatic Recovery after Battles

    Halo brought automatic health recovery to the FPS genre, and now FF13 might bring it to RPGs.

    I have maintained (even before FF13) that this is just the Right Way to build an RPG in the modern era. If you look at the trend over the entire Final Fantasy series (which is in many ways representative of the entire JRPG genre), you would see that post-battle recovery has become easier with each installment. FF13 simply jumps to the end-point of this trajectory.

    Some hardened RPG vets might complain that automatic recovery robs the game of its challenge. Such a complaint, though, completely misses the point. In older RPGs, surviving to the end of a massive dungeon was always a matter of attrition. Would the little nuisance encounters along the way drain your health, MP and stock of items enough to make the boss fight unwinnable? FF13 does abandon this kind of attrition challenge, but in return it adds a new challenge:

    More Difficult Battles

    Even in the early/mid game, the no-longer-random battles between boss fights can pose a real challenge in FF13. Enemies hit for a lot more and soak up a lot more damage than in any recent Final Fantasy. Coming into battle with the wrong strategy, or holding to a damage-dealing Paradigm just a bit too long, can quickly bring up the Game Over screen.

    The battles are never overly cheap, though, as the more challenging random battles in the earliest JRPGs tended to be. You are unlikely to fall victim to a one-hit KO in the first round of battle, and almost every battle in the story progression can be won on a second or third try by bringing a better strategy to the table. And speaking of second tries…

    No Penalty for Failure

    Losing a battle in FF13 simply resets your party to a point right before that battle. At most you have to contend with a (skippable) cutscene before you can dive right back into the encounter with your new strategy.

    Once again, the old-fashioned RPG vanguard might balk, but FF13 is simply subscribing to a more modern design ethos. Today’s players (if they are anything like me) have less free time, and thus have far less patience for being forced to replay an hour-long slog through a dungeon because of a single mistake made in a boss encounter.

    Boss encounters in FF13 can be truly intimidating. Failure is never far away (see More Difficult Battles above), and victory usually depends on an understanding of the new battle mechanics that FF13 brings to the table. This brings us to:

    Chaining, Stagger and Launch

    The Chain Gauge is the key to victory in FF13’s hardest encounters, and adds a welcome layer of complexity to the battle system.

    Every enemy has a Chain Gauge, initially empty. Attacks from a Ravager (aka Black Mage) fill the gauge, but it will quickly drain. Attacks from a Commando (aka Fighter) do little to fill the gauge, but slow its rate of decay. Once the gauge is filled to the top the enemy temporarily enters a Stagger state in which it is more susceptible to attacks of all kinds. Some enemies, when staggered, can be Launched into the air and juggled by successive attacks, preventing them from acting.

    The stagger system is a great addition, and really forms the meat of FF13’s combat. Many enemies are effectively impervious to attack until staggered, while others can have their devastating offensive abilities completely shut down by a timely Launch. Mages and fighters feel balanced, without being interchangeable, because both play essential roles in the stagger mechanic.

    Roles and Character Differentiation

    A big problem looming over the 3D Final Fantasy games has been how to allow players to personalize their character development while still giving each character unique strengths and weaknesses. Final Fantasy VII and VIII occupy one extreme, where characters are nothing more than their base stats and a place to junction materia or spells. Final Fantasy IX stands at the other extreme, with each character belonging to a single designer-selected class (thief, knight, black mage, etc.) and only able to learn abilities appropriate to that class.

    On this spectrum, FF13 occupies a nice middle ground. Every character is allowed to use any class, but has inherent aptitudes that make them most effective in certain roles. These aptitudes aren’t just a matter of their base stats, but are also reflected in the relative cost to upgrade them in each class, as well as the order in which they receive each class’s abilities (if at all). Because of these aptitudes, and because a character can only use one class at a time in battle, the game encourages players to specialize each character in a role that suits them.

    What Didn’t Work

    The Story

    Final Fantasy XIII has an interesting setting (the dual worlds of Cocoon and Pulse) and a somewhat compelling scenario; ordinary people pressed into the service of warring deities, forced to fulfill their proscribed task or suffer a terrible curse. What it lacks, however, is any kind of story arc. After the initial early-game gauntlet is cleared, the protagonists blunder forward without any clear purpose. They don’t even know what task they are supposed to perform, let alone whether they intend to defy it. Once the antagonist steps forward, things only get worse. Even at the end of the game, it is unclear precisely how the protagonists’ ambitions differ from the antagonist.

    All of this might not be so bad if the dialogue didn’t consist entirely of the various characters taking turns suffering crises of faith; questioning the morality/feasibility of their nebulously-defined mission. These crises are inevitably resolved with meaningless anime-inspired platitudes (e.g. “We can do it – we just need to believe in each other!”), and do nothing to further the plot or characterization.

    The only visible purpose these ridiculous dialogues serve is to set up the reworked summons:

    The Summons

    There really isn’t anything about FF13’s “eidolons” that was executed well. First, they are clumsily shoehorned into the narrative; despite characters talking about how important they are, they could be completely excised from the story without any impact. The only time the eidolons appear outside of the scenes that introduce them is in a few style-over-substance cutscenes.

    The (non-optional) battles to acquire each eidolon are tedious, and come at the end of some of the most insipid dialogue scenes in the game (see “The Story” above). The idea of a “puzzle battle” probably sounded good on paper, but in practice is just boring. The conditions for victory are so obtuse that the only way to find them is with a guide or the “Libra” technique. At that point, however, you are just applying a set formula, and your intelligence isn’t really being tested.

    Your reward for acquiring each eidolon is underwhelming. Each can only be summoned by one character, and then only when that character is the party leader. The summons are barely powerful enough to take down ordinary enemy mobs, but they do have the side-effect of recovering the health and status of the party. As a result, the only reason to use a summon in practice is for its ancillary healing effect in major encounters.

    The final nail in the coffin for FF13’s eidolons, though, is the patently ridiculous “Transformers” thing they have going. From a bright red race car to a disturbingly misogynistic motorcycle, these alternate forms for the summons look comically out of place in the game’s setting, and completely shatter suspension of disbelief.

    Battle System Design

    This might seem confusing after I talked up the whole Chain/Stagger/Launch thing earlier. While FF13 did make some interesting strategic additions to the battle system, it also took several missteps.

    FF13 encourages players to lean on the “Auto-Battle” feature, letting the AI select which commands to use and on which targets, and reserving player control for “Paradigm Shifts.” Most battles can be won without any manual command entry, and the game’s creators have even commented about how manual command entry is neither practical (because of the speed of battles) nor desirable (since the AI can exploit nuances of the battle system that are not explained to the player).

    Why, then, do I have to sit there and repeatedly press the X button to tell the party leader’s AI to do its job? Why, if I decide to input a command manually, can’t I pause the action while I buffer up commands? Why do I get a Game Over if my party leader falls in battle? Why can’t the non-leader characters use items? Why can’t I switch leaders in battle, or at least manually enter commands for non-leader characters? Why can’t I instruct the AI to favor reviving fallen characters over healing only moderately-wounded ones? Why can I only switch character classes in bulk, instead of for each character?

    It may sound like I am just picking nits, but these are all things that Final Fantasy XII – its immediate predecessor – got right! FF13 inherits the emphasis on AI-controlled characters in battle, but robs the system of the extra degree of control (and hence of user-friendliness) that was present in FF12.

    End-Game Tedium

    In the early game, FF13 seemed to breathe new life into stagnant JPRG conventions. Minor battles can be cleared in tens of seconds (or less), and even boss encounters can be dealt with in mere minutes with the right strategy. It is unfortunate that by the end game, things have changed for the worse.

    Random enemy mobs in the late game can take several minutes to clear (which makes grinding for experience more tedious than it needs to be), and boss battles can take 20 minutes or more if your team is even slightly under-leveled. Once your party has gained access to the most important abilities in the Synergist and Saboteur roles, most battles fall into a predictable and tired cycle of (de)buffing, attacking, and healing.

    By this point, strategic decision making is largely absent from the picture. The player is responsible for switching Paradigms at the right time, but the set of Paradigms used in each enemy encounter rarely changes – only the particular attacks, buffs and debuffs used by the characters vary. But when the AI characters automatically “learn” what elements and status effects work best in each encounter, that leaves the player with very little to do during these 10-minute-plus battles.

    Conclusion

    In the end, lucky number XIII isn’t going to be remembered as one of the best Final Fantasies. It takes a bold stand on where JRPGs might go in the future – aspiring for accessibility with streamlined mechanics – but it stumbles in just as many places as it succeeds.

    In Defense of Explosive Barrels

    I’m always a little confused when people talk about “realism” in games. Maybe it started with Old Man Murray’s famous screed about the medium’s overreliance on crates.

    As comedy, this kind of analysis works. More worrying, though, is when players, critics and designers decide that the conceits of the medium, or of a particular genre, should be excised in the name of “realism.”

    The classic elemental environments (fire level, ice level, etc.) have already fallen out of favor. Characters being obstructed by knee-high fences is unforgivable in the era of open-world games. RPG loot drops must be rationalized because a celebrity game designer noticed that birds don’t carry swords. And the explosive barrel – stalwart vetran of FPS design – is now seen as a ridiculous affront to realism.

    What the detractors fail to acknowledge is that explosive barrels are fun. Very fun. I’d go so far as to say that the explosive barrel is one of the fundamental elements in the Periodic Table of Interactivity.

    Just trying to enumerate the possible uses for a well-realized explosive barrel (like the version in Half-Life 2) reveals how much interactivity is packed into each:

    The barrel is a physics object, and thus can be stacked or climbed upon. It can be thrown with the game’s gravity gun, wherupon it explodes on impact, providing an impromptu grenade launcher. It can be exploded with a burst of gunfire, but a few careful shots with the pistol will start it burning, creating a timed explosive used by player and enemy alike. Finally, the barrel can be triggered by other explosions, leading to the possibilty of chain reactions engineered by the level designer, or savvy players.

    The explosive barrel is a powerful tool of player expression. It elevates the vocabulary afforded to the FPS player beyond just “point” and “shoot.”

    I could go on raving about the merits of the explosive barrel, or describe how other “unrealistic” conceits like elemental levels/abilities or double-jumping benefit their respective genres, but I hope my point is clear.

    These “cliches” persist because they are more fun than the monotonous grey “realism” of so many of today’s games.

    [Note: I do give the TV Tropes site credit for understanding that tropes are not bad. Now we just need to get the players out there to understand it.]

    The Inevitable Fall of Link and Samus

    When I first played through The Legend of Zelda: The Wind Waker, I felt the nagging sense that something was wrong. Despite the beautiful art style and excellent combat mechanics, the game didn’t seem to live up to the standard set by Ocarina of Time and Majora’s Mask. At the time I dismissed these concerns; nostalgia has a tendency to cloud judgment, and my own nostalgia for the N64 Zelda games is pretty hefty.

    When I had the same reaction to Twilight Princess, I began to worry. Were my expectations for the Zelda series so high that no game could meet them? Or was there something real, something identifiably lacking in these games as compared to their predecessors?

    When I dug into Nintendo’s Metroid Prime Trilogy for the Wii, I noticed a similar pattern. The first Metroid Prime is a brilliant game; carefully blending new mechanics and abilities with homage to Super Metroid (itself as close to perfection as is possible). Playing the Prime sequels, Echoes and Corruption, shortly after the original led to the same sense of hollowness I’d felt with Zelda. Though the gameplay mechanics are the same throughout, the latter two games seem to lack the magic of the first Prime.

    So what is happening?

    The core design of the Zelda games and the entire “Metroidvania” sub-genre are pretty consistent (once you strip away the differences in presentation, perspective, combat, and story – you know, the small stuff). Under the hood, these games are about the interplay between exploration and discovery.

    The player is presented with a large, varied environment to explore, and given an initial set of tools and abilities (I’ll refer to these uniformly as “items”). Invariably, some parts of the world are inaccessible at first; the player might take note of a ledge just out of reach, or a suspicious crack in a wall of stone. The reward for diligent exploration is then discovery – of new items that render those parts of the environment accessible.

    It is this cyclic relationship – exploration leads to discovery, discovery enables exploration – that drives the experience. Clever designers can gently guide players towards the right discoveries in the right order, all while giving them the impression that they are in control; that the discoveries are theirs.

    But the converse is also true, and this is the crux of the problem: careless design gives the player a strong sense of being led on a leash. If every attempt to explore out of the proscribed sequence is impeded by artificial barriers, then exploration ceases to be fun. If each discovered item serves only to lower the next designer-imposed barrier, then discovery ceases to be rewarding.

    Once I came to understand these things, I was able to identify the issues that had troubled me in the most recent Zelda and Metroid games. As a service to any game designers listening, I will provide a handy list of things not to include in your games.

    Proceeding from least to most egregious:

    Items that only work where the designer intends

    The hookshot in Ocarina of Time could latch on to almost anything with a wood material applied, whether the designer had consciously planned for it or not. Starting with Wind Waker, however, the hookshot can only latch onto specific designer-placed targets.

    Limiting the applicability of an item in this way dumbs down gameplay. The player never has to think about when to use the item; whenever they see the telltale marker, they respond. The rest of the time, the item goes unused. With this kind of design every challenge admits only one solution – the one the designer intended.

    Of course, this is precisely why designers employ this approach. When you are planning an elaborate puzzle, you don’t want to think about how it could be approached with every possible combination of items. It is much simpler to just rule out whatever items you don’t want the player to use.

    In the limit, though, you end up with:

    Items that are only useful for a limited time

    This has unfortunately become one of the hallmarks of the Zelda series. Upon receiving a new dungeon item, you can expect to see several brilliant set-piece puzzles using the new item, along with a boss battle in which the item will be critical to success. But once you leave the dungeon, your shiny new toy finds itself relegated to the inventory with the other trinkets.

    If you are lucky, the designers might throw you a bone, making the item useful for unlocking a few upgrades, or opening the way to a new area of the world. But because the item can only be used where the designer intends, it eventually loses all utility and just sits in your inventory wasting space.

    Twilight Princess is chock full of items like this. The Spinner only works on special “rails,” and there are almost none of these outside of the dungeon where it is found. The horse whistle gets special mention for being useless from the instant it is given to the player. The Dominion Rod is particularly reviled – it’s only post-dungeon utility is for a late-game fetch quest.

    Speaking of the Dominion Rod, lets talk about:

    Items that only work as keys

    Getting a new item is supposed to be exciting. It might make your player character more effective in combat. It might be used to destroy obstructions or pass obstacles. It might speed up navigation, or enable the use of new shortcuts. The best items do all these things.

    Alternatively, you could just make your item a stupid key, uninteresting to use and with no other functions.

    The modern Zelda and Metroid games all have their fair share of late-game fetch quests for meaningless MacGuffins. The older Zelda games may have had the standard “collect the 8 Bafmodads to kill the evil Foozle” plot, but at least along with each Bafmodad you got a fun new dungeon item.

    The Metroid Prime sequels are the worst offenders here. The primary player task in each region of Echoes is to collect three keys – really, the designers just call them “keys” and move on. Corruption, tries to dress up its keys in the form of the “Hyper-Mode” abilities. With few exceptions, though, these abilities are only useful at painfully obvious choke points. Both games feature a missile “upgrade” that locks on to targets and fires a five missile burst. Of course, the only time players every use this ability, is to open a handful of locked doors.

    The most brazen, nonsensical example of this has to be the “Translators” in Echoes. After the defeat of each main boss, the guide NPC gives the player a new Translator which allows the player to read certain messages and open certain doors. Each translator has a color, and can only work with like-colored messages/doors.

    Take a second to think about that.

    How does it make sense that you need new translation software to read messages in different colors? And even then, what possible reason does this NPC have for teaching you his language in this piecemeal fashion? The only purpose it serves it to corral the player, and that brings us to:

    Artificially controlling access to the world

    Exploration-based games work best when the player can actually, you know, explore. Unfortunately, some designers have decided that their carefully crafted narrative would be ruined if the player were allowed to access regions of the world even a little bit earlier than intended.

    This is of course patently ridiculous, but it doesn’t stop the Zelda games from holding the player’s hand and carefully leading them through the first 10 or more hours of the narrative. In Metroid Fusion and the Metroid Prime sequels, Samus can only explore in those places that her orders have explicitly unlocked.

    What are these designers afraid of? Sure, a small number of die-hard players are going to look for opportunities to “sequence break” the game. But the dedication of players like these is a sign of just how much they enjoy a game (look at speed runs for Super Metroid or Castlevania: SOTN and tell me those aren’t labors of love), and their antics do nothing to diminish the enjoyment of less hardcore players.

    Wrapping up

    What’s happening here is simple – by limiting the options available to the player, you can produce a more streamlined game, at the expense of its depth. While these newer games may superficially resemble the classics from which they are derived, they have sacrificed some of the core design principles in order to make the production easier (and one assumes, cheaper).

    Nintendo still produces some of the best games out there, and the recent Zelda and Metroid games are still a lot of fun. I’ll just have to learn to live with that sense of hollowness when I play them.