namco’s 1980 arcade cab tank battalion is a humble game. as its name suggests, it is populated with little cerulean tanks who trundle through a maze to the constant buzz of a revving motor. their aim is a flag at the bottom of the screen: to allow a bullet to hit this is as fatal as allowing a space invader to land, a technical game over regardless of how many tanks the player has left in stock. so the player maneuvers her tanks, bumblebee-yellow, through the maze, picking off enemy machines before they can get too far south.
what is memorable about this otherwise plain title is that the walls of the maze can be destroyed. enemy shots and player misfires eat at the bricks that make up the stage, opening new routes for tanks to steer and shoot through. busting walls isn’t just to the advantage of the enemy, as it’s often in the interest of the player - who is trying to fend off a number of enemies closing on the flag from a number of directions - to dig tunnels for quick movement and holes from which to snipe at enemies.
tank battalion’s maps - whose walls seem to be strewn at random, and the third of which is an open field with no cover whatsoever - don’t really explore the potential of this. that may be why the game warranted a sequel, 1985’s battle city for the famicom.
battle city correctly identifies the destructible walls as the central mechanic of tank battalion and expands on it, with the addition of indestructable blocks and other level elements as well as many maps full of walls to dig through, plan around and negotiate. the game is seemingly so proud of these maps that any can be selected straight from the title menu.
a home game, battle city also adds a number of other features: a greater variety of enemy tanks, power-ups, and two-player play. but the most significant addition a home platform allows is a level editor which lets players make their own maps: if the game is about changing terrain, after all, why not let the player build? more than a simple arcade port, battle city fills in the original title’s blueprint.
taito’s 1986 arkanoid updated the formula of atari’s breakout with power-ups and meaningful level design; since then it’s been among the most widely-imitated games. so many “ball & paddle” games have seen release that it’s easy to believe that the problems of many of them are endemic to the formula itself: since the player has only periodic control of the ball she must use to clear the screen of block targets, tedium frequently sets in as the player struggles to eliminate the last straggling hard-to-reach blocks on the screen.
nurium’s 2005 title breakquest tries to solve the problem by giving the player a small amount of direct control over the ball in the form of a gravity beam. arkedo’s ds effort nervous brickdown tries to evade tedium by presenting a variety of gameplay ideas, but the game is so badly organized that each, in isolation, quickly becomes tedious.
taito’s own arkanoid ds contains no more items or abilities than the original arkanoid; its stages are built of what are essentially three types of block. yet the game remains compelling and exhilerating, standing out in even as oversaturated a “genre” as the one it built.
the ways in which it manages this are subtle. the most obvious difference from the original is the screen size: arkanoid ds takes full advantage of the dual screens’ vertical space, placing the blocks on the top screen and the player’s paddle (the vaus) on the bottom. the ample space between blocks and paddle mean that when the game gets fast - and it does, quickly - the player has plenty of uncluttered space in which to track and return the ball. at high speed, the game becomes a kind of tennis match, serve and return.
less obvious is that the playspace isn’t just taller: it’s also more narrow. this means that the ball bounces more, covering a wider area, and also that there’s less area to cover. combined with the fast speed the dual screens allow, that means stages tend to go quickly. simple in design - and true to the game it emulates - arkanoid ds manages to retain the arcade pace that its series’s imitators, overcomplicated and slow, often lack.
in a further nod to its arcade legacy, arkanoid ds ships with (or without*) a paddle - a rotary dial - controller that plugs into the gameboy slot of the ds. though the weight the controller adds to a ds lite takes a little getting used to, the paddle feels great, and the dial spins with just the right amount of resistance and the cool rolling click of hidden ball bearings. i played through most of the game with the stylus prior to getting my hands on a paddle, and that worked just as well.
arkanoid ds, maybe more than anything, reminds me of pac-man: championship edition. while so many of the games that trail between these revisions and their progenitors add only more clutter, these sequels edit the original formula to be leaner, faster, more considered and compelling: a real update, not just new content.
* both arkanoid ds and the paddle controller are available seperately of one another.
dark fudd’s super mario bros. slimes hack for nintendo’s 1985 platformer does little more than (as its name implies) change the sprites of all enemies to resemble slimes from the dragon quest series. it’s absolutely appropriate, however: as the most basic enemy in its game, the slime is as ubiquitous in dragon quest as the goomba is in super mario bros. throughout the course of the dragon quest series, the developers themselves have given us such varieties as red, blue, gold and metallic slimes, slime riders and slime kings (all while the mario games were giving us winged goombas, giant goombas, tiny goombas, round goombas and goombas wearing pointy hats). replace super mario bros.’s entire bestiary with slimes? easy!
in the world of sega’s 1993 mega cd title switch! (released in the west by data east the following year as “panic!”), machines have gone haywire. cars eject their engines, televisions vomit green ooze, elevators, rather than conveying their passengers to their intended destinations, drop enormous moai statues onto their heads. while playing a videogame, a boy named “slap” (who is occasionally accompanied by his dog “stick”) is abducted by his television and tasked with finding the central computer and curing the virus that has been wreaking havoc on the world’s machines.
to reach the central computer slap must manipulate a variety of malfunctioning devices. on each screen the player is presented with a control panel covered in unlabelled buttons, each waiting to be pressed. pushing a button might result in an animation of the device misfiring in some absurd way (like a vacuum cleaner sucking up the entire screen), invoke an angel or devil to provide a useless taunt or word of advice, destroy a famous landmark, or transport slap to another screen and to the control panel of another deranged device.
the game, then, is essentially a maze, which the player navigates, at random, by pressing the buttons that will take her from screen to screen and, hopefully, to the central computer and the game’s conclusion. but switch! is also an absurd fable about the dangers of becoming dependent on technology. the powerlessness of the player in this maze of booby-trapped switches is the powerlessness of one whose only skill is the ability to press buttons. pushing buttons on a joypad, after all, is the player’s only option, and she’ll find it affords her little control over what happens on-screen.
in hal laboratory’s air fortress, released in 1987 for the famicom and two years later for the nes, the player must infiltrate a series of mechanized, bubble-encased space cities and destroy them from the inside. each stage consists of two parts: the first, the approach to the fortress, is played as a scrolling shooter, with the player flying into the city on her spacecraft; the second takes place inside the fortress, with the player searching on foot for the city’s robot core.
resources gathered during the scrolling part of the stage - bubbles marked with an E for “energy”, tucked in hard-to-reach places - are counted towards the search part, creating an implicit time limit: the player’s energy, tracked in triple digits at the corner of the screen, which decreases as she moves, flies, shoots, and suffers damage from the fortress’s security measures.
but the real time limit begins once the core is destroyed, and is not indicated by any number. rather, it is conveyed by a sinister rumbling which begins after a minute of wandering the suddenly-dark, quiet fortress, a rumbling that grows to a shaking, and then a flashing of failing lights which leaves the player momentarily in darkness, and finally, if the player is unfortunate enough to still have not located her spacecraft, a cacophony of 8-bit crashes as the screen glows white, then fades to the words “game over”. it is a more effective countdown than any clock in the corner of a screen could be.
despite an english script which gives us “where” instead of “were” and weapons like “lipp shoot” and “sleep launcher”, data east’s silent debuggers manages to be terrifying. the sudden beep of the enemy radar while creeping down a featureless metal corridor, the quick glimpse of a monster slip away down an adjacent hallway, turning around to see an alien face fill the camera - these are genuinely scary moments and silent debuggers manages to achieve them despite its hokey premise and awkward localization.
the 1991 pc-engine game tasks the player with hunting alien beasts in a first-person perspective that allows a short length of the unadorned space station corridor in front of the player to be seen and little else. she may turn only by ninety degrees at a time. but this ends up creating profound tension: monsters hide around corners, leaping out in front of the player with a roar noise as she approaches, or waiting for her to round the corner and find them standing right in front of her.
soon the player has a timer breathing down her neck as she chases aliens she can rarely glimpse through what used to be the only safe place on the station, and a few grammatical blunders do little to make the situation less tense.
bullet hell / danmaku shooters toss curtains of deadly bullets at the player, but compensate by giving her a small enough hitbox to squeeze between them unharmed, provided she has the skill to maneuver through. tehkan’s (now tecmo) 1984 arcade platformer, bomb jack, gives the player unprecedented control over her jump: use the joystick to control the height of the jump, the button to abandon a jump in mid-leap, flap to hover in the air before falling. in giving the player so much control, of course, the game expects her to use it.
as in pac-man, bomb jack’s stages contain lines of objects that must be collected before the game will continue: in this case they’re bombs. one bomb is lit at any given time, and the player can gain bonus points by grabbing bombs in the order they light. while trying to tag bombs in the right order, the player negotiates enemies who continually clutter the game’s airspace. to navigate the stages safely requires increasingly tricky mid-air acrobatics. it’s appropriate, then, that the protagonist wears a daredevil cape.
shooting games on handheld game machines, especially the nintendo gameboy, are rare. in addition to the small screen, the original gameboy has the additional problem of a slow refresh rate. making out tiny bullets is even harder when one can’t be exactly sure of where they are. hal laboratory’s trax, released in 1991 (not long before the release of kirby’s dream land) solves the problem of visibility by making its bullets big, round, eye-catching cannonballs (which some might recognize from that later, better-known game).
the rest of the game’s visual design is suitably big and cartoonish - the bosses are enormous and fill most of the screen - and full of recurring symbols which tell the game’s minimal story: a plump, adorable death tank with a swivelling cannon has been refitted by oppressed farmers to blast through an army of its identical brothers and sisters and smash the assembly line on which it was constructed, and which continues to roll out copies of its model, an endless if friendly-looking war machine.
as befits its handheld platform, trax is short, fast, and charming, the perfect length for a quick play on a short trip.
aleksi eeben’s redrunner (sequel to the earlier greenrunner) is a commodore 64 homebrew game, an homage to jeff minter’s gridrunner series. those games, inspired by atari’s centipede, realized while imitating centipede that that game could be broken down into its most basic elements, and then realized that those elements could be rearranged into a variety of different configurations. like the llamasoft games that inform it, redrunner is a shooter that reinvents itself in every stage.
as in a minter game like voidrunner, the challenge comes not just from dodging and shooting but from keeping up with the rules and demands of each new stage, hinted at by the stage title that flashes in the center of the screen like the hollar of a dance caller. it’s this voice that creates the feeling that the game’s author is present, acting through the game as a kind of emcee. it’s the reason jeff minter’s games have so much personality, and aleksi eeben’s homage has it too.