In the 90′s, Capcom produced a plethora of side-scrolling beat-’em-ups. They were all pretty fun, but my favourite was an unlikely-branded D&D title, Tower of Doom.
The TSR/Capcom partnership actually spawned two individual games, but here are the notable bits for the first one:
— The most famous feature of ToD is the branching path structure. Periodically, the player is presented with 2-3 options of how to proceed, with each choice leading to a different area and boss. All these paths converge fairly quickly, but the extra choices are a nice feature and encourage multiple playthroughs.
— ToD’s overall structure is very similar to a typical beat-’em-up, but the game also contains lots of streamlined D&D/P&P RPG elements. Characters gain experience and grow stronger by leveling up, keys (or a thief character) are needed to open some chests, traps are virtually everywhere, there’s lots of treasure to collect, etc. There’s even a troll boss that needs to be burned once his health is depleted or he’ll simply regenerate.
— There are very few health-recovery items in the levels themselves, but the player can heal by collecting loot and purchasing health potions in shops. The shops appear in between levels and also allow the player to restock on usable items such as daggers and arrows.
— ToD contains lots of nice, little touches: the characters start the levels with their weapons sheathed (and the player can walk around unarmed until he presses the attack button), enemies can be damaged by traps, an extra victory animation accompanies a boss’ defeat, and all major stages and events are framed using unique illustrations. The game even contains some unique “Game Over” pop-ups that — if triggered during a boss fight — have the player’s enemy openly mocking him.
— Magic spells execute a flashy animation while pausing the gameplay, and their effects occasionally carry on once the game has been unpaused. This works fine for the most part, but due to the rule of only-one-spell-at-a-time, it’s occasionally possible to not be able to cast a spell while walking around without having a clear idea as to why it’s not working.
— Like many other beat-’em-ups, ToD’s attacks are accompanied by hit-flashes that indicate successful hits and mask collision issues. However, unlike most other titles in the genre, the player can attack downed enemies, but can’t actually grab or throw them.
— If timed properly, it’s possible to slash projectiles out of the air with a basic attack.
— Non-usable/equipable items are fairly rare, but they do provide passive bonuses such as extra attack and defense boosts. These items don’t usually last very long, though, as they get “broken” or “lost” if the player gets hit a couple of times.
Split-screen modes in videogames are often pejoratively labeled as the “little brother” feature. I think the association was always there, but only recently has the term itself gained popularity.
With the advent of XBLA, PSN, etc., console gamers are playing multiplayer titles the same way their PC counterparts have been for years: online. Supporting both online and split-screen modes is not a trivial task, so the older brother — much to the younger one’s assumed chagrin — ends up hogging the console. If a split-screen feature is present, though, both can enjoy the game at the same time, hence the “little brother” moniker.
Of course developing multiplayer games for a single screen has been around for ages. Shmups, puzzle games, rhythm titles, rail shooters, etc., often only require a single screen to accommodate all the participants. Other genres like scrolling beat-’em-ups or fighting games tend to lock or stretch the playing field to attain similar results. However, when a title requires a large physical separation between the players (such as in a racing game), console titles have generally relied on a split-screen approach.
Split-screens (especially with 3D games) are computationally expensive, so their implementation tends to be quite basic: each player gets his own personal rectangle of real-estate. In two-player games, this means dividing the screen into two portions with either a horizontal or a vertical line.
On older, squarish TVs neither the horizontal nor the vertical approach could really be that graceful, but the horizontal split became a de facto standard. It made sense since much like human vision, games were more horizontally oriented. It was the lesser of two evils.
With the rising popularity of co-op and the advent of widescreen HD TVs, though, I assumed this would change. My HD TV’s picture-in-picture option allows me to vertically split the screen between two visual streams, and it works quite well. After all, 8:9 is a lot closer to 4:3 than 16:4.5. It’s something developers have started to address — despite the fact that many current games are designed for a 16:9 aspect ratio — but split-screens still tend to be a bit of a mess.
To improve their implementation, I would suggest the following:
— Provide an option for either a horizontal or a vertical split-screen mode. Automatically selecting one might seem user-friendly, but it’s also a very divisive issue. Once split-screen is implemented, it should be relatively simple to support both modes, so why not let the player choose which one he prefers?
— There’s no rule that says 100% of the screen real-estate must be taken up by the players’ viewports. This can often produce a warped and cropped appearance, so why not try to maintain correct aspect ratio (in either mode), and use the remaining space to display a minimap, the inventory, HUD components, etc.?
— The major issue with vertical split-screens seems to be the lack of peripheral vision. It’s a legitimate complaint, but one that also seems easy to address with a little bit of field-of-view tweaking. FPS games in particular have been reducing the FOV for quite a while now, and widening it for split-screen modes should be very simple to do.
Jedi Knight came out just a year after the original Quake, and was already showing its age upon release. Its development team was wise enough to include support for hardware acceleration and mouse-look controls (complete with a neat if archaic calibration of the axes that allowed for some very sensitive camera movement), but the low- poly count was much harder to mask.
Jedi Knight still received very positive reviews, though, and rightfully so. It wasn’t perfect, and hasn’t aged particularly well, but I had a blast with it.
Here are some of the points that stuck out upon replaying it:
— The level design in Jedi Knight is fantastic, and probably its biggest strength. Of course level design was a bit of a different beast back then: areas tended to be much larger with fewer scripted events, the player had an inventory of keys and other usable items that facilitated environmental traversal, platforming puzzles were quite common (although usually disliked), movement was much, much quicker, etc.
Within that framework, though, the levels were a treat.
Despite the game’s low-poly count, its geometry was quite complex and varied. Textures were often repeated, but new ones trickled in periodically and every map had its own unique motif. The player was also constantly operating large-scale machinery that dynamically changed the landscape.
It all made for a nice combination of action, exploration and some occasional head-scratching. The only complaint I had with the levels were the large, industrial looking doors that were virtually indistinguishable from walls. Since these had to be opened with a button press, there were too many instances where the player could easily get stuck simply due to dodgy visuals.
— In-between level cinematics consisted of live-action actors superimposed over CG backdrops. They were rather silly and pretty low-budget, but did a decent job of conveying the story while showcasing certain visuals that were not possible to render within the game engine.
— The player was able to carry 10 weapons at any one time, and many of them shared the same ammo source. The limited ammo made becoming a Jedi and obtaining a lightsaber all the more rewarding. Visually speaking the lightsaber wasn’t anything fantastic, but it had unlimited power and the added advantage of lighting up dark areas and deflecting smaller enemy shots.
— Jedi powers were earned as the player progressed through the game, and they could be focused on neutral abilities, the light path, or the dark side. The powers themselves were a nice addition to both the singleplayer and the multiplayer, and were sometimes necessary to progress through a level (or at least take a short cut).
Force Pull was a particularly fun one as it allowed you to snatch weapons out of the enemies’ hands or grab healing items from far away.
— All the enemies responded to basic in-world physics, even after death, which made for some cool effects like a dead body sliding along the current of a pipeline.
— A lot of the audio was taken straight from the Star Wars movies, including the iconic sound effects and the famous scores by John Williams. These greatly enhanced the atmosphere and helped Jedi Knight stand out from other FPS titles of the era.
— The way the game’s secret rooms were placed was quite clever as they followed a pattern that went against the common funneling/guiding techniques of level design, e.g., a small nook embedded into the wall just above the entrance to a room was very easy to miss if the player ran right in without looking up and behind.
Enemies were often utilized to help the player spot these locations as they would often be placed in seemingly inaccessible locations, but with enough sleuthing, the player could always discover a way to reach his foes. A tally at the end of each level also informed the player as to whether he missed any secrets.
The impetus to discover the secret areas was very good as well. Not only did these locations often contain health, armour and ammo, but finding all the secrets in a level rewarded the player with extra force powers.
Jedi Knight is available for cheap on Steam, although everyone should keep in mind that it’s a very lazy port/re-release. None of the GUI elements have been updated for higher resolutions, the title screen and in-game cinematics must be viewed in a windowed mode, and the game doesn’t come with its original music. There’s a fix for that, but make sure to check out the forums first to get a better idea if it’s worth your money.
Sub-Terrania is a physics based, side-view shooter in vein of such titles as Thurst and Gravity Force. It was developed by Zyrinx, a studio composed of demo scene veterans, and was a difficult but enjoyable Genesis title.
- Sub-Terrania has something of a photo-realistic aesthetic that’s also reflected in its gameplay. The physics require pin-point thrusts due to limited fuel supplies, gravity drags down projectiles, momentum dictates collision damage, attachable items add extra weight and inertia, etc.
- Although there are only 3 tile-sets for all the maps, each level contains unique puzzles and visuals. These can vary anywhere from a laser-reflecting mirror to a giant hopping robot. Although the functionality of these elements is reused, none of the assets ever appear twice, and even the enemies and environmental objects are changed up pretty frequently.All these concepts make for a very nice, non-repetitive experience where the player knows something new is lurking around every turn.
- All the destructible elements are man/alien made, and are composed of dozens of tiny tiles. Each one of these tiles has its own collision box and health value, adding granularity and creating a very gradual and satisfying sense to the destruction.
- The overall game can be quite unforgiving. The ship’s shields are drained whenever it comes in contact with anything on the map (except when landing on flat surfaces which provide a much needed respite), the player’s shots can destroy precious powerups, and — unfortunately — the level maps only are only shown in between stages.
- Whenever the player’s ship explodes, it releases a shower of particles. Each one of these obeys collision checks and plays a sound effect whenever it comes in contact with the environment, putting a cacophonous exclamation point on the player’s death.
- If the player runs out of fuel, his ship begins to billow out smoke and proceeds to plummet to its demise (all the while accounting for its previous trajectory). In this state, the ship blows up as soon as it touches anything, which can happen mercifully quick or last quite a few seconds.The small touch creates a dreadful but aesthetically pleasing game death effect.
- Some of the enemies’ physical attacks carry a tremendous force that can send the player rocketing across the map (often to an almost-instant death). These moments can be quite surprising considering the somewhat plodding pace of the game, and add a menacing touch to the numerous adversaries.
- As the player journeys further and further underground, satellite data becomes increasingly sparse. At first, key locations on the map stop being pinpointed, but soon the mission-goals themselves become garbled up, and eventually the briefings disappear altogether. Rather organically, this creates a feeling of foreboding and also reinforces a sense of progression.
- The last levels of the game increase the pull of gravity, but also introduce underwater areas that constantly drag the player’s buoyant ship to the surface. Although the player can obtain an item that — when manually used — pressurizes the ship and temporarily inverts its underwater handling, it’s only of small aid (especially when the water is eventually replaced by hazardous pools of acid).
- Early on in the 9th and final stage, the player can obtain an item that grants him unlimited fuel. This is an extremely helpful and empowering upgrade, especially considering the game-wide scarcity of the resource.
- In something of a twist on punishing the player, the end-game boss battle is not restarted if the player dies. Instead, if there are any lives left, the ship simply respawns right in the middle of the fight.