Archive for March, 2009

Wonder Project J bits.

Wonder Project J is a “raising simulation” (think Tamagotchi) originally released on the Super Famicom.

wonder project j 0031 Wonder Project J bits.

The titular Wonder Project.

wonder project j 0053 Wonder Project J bits.

Until Pino gets smarter, expect him to do a lot of clumsy things.

I actually first heard about Wonder Project J when GameFan magazine previewed the second game in the series. Just like the original, the sequel never ended up being released outside of Japan, but both titles got fan translations. Now WPJ2 certainly didn’t seem to have the same Lolita complex that plagued Princess Maker 2 (although there were traces of it), but I still wanted to check out the original.

And I did, so here are the notable bits:

  • The presentation is pretty unique for a SNES game. The sprites are quite varied in size and contain lots of frames of animation. The backdrops are also — for the most part — hand-drawn and not tiled.
  • The premise of the game is basically a spin on the tale of Pinocchio. This provides an instantly recognizable setup and work well with the raising simulation aspect, i.e., Pino, the Wonder Project, needs to become the equivalent to a real boy, and this is done by completing various tasks that are based on his numerous statistics.
  • There’s a significant separation between the player and Pino. The player directly “communicates” with a robotic fairy, who also serves as the game’s cursor, and then she in turn gives suggestions and interacts with the boy-robot himself. There’s some heavy breaking of the fourth wall here, too, as both Pino and the fairy tend to directly address the player.

    wonder project j 0232 Wonder Project J bits.

    Pino reigns supreme at the robot sportsfest. Instead of fireworks, though, there's gunfire.

  • Pino starts off as an incredibly naive and charming little boy. Without the player’s guidance, he’ll run into walls, attack animals, and try to consume all sorts of inedible objects.
  • Pino is largely autonomous and will automatically approach and investigate the things that interest him. If you leave him alone long enough, he’ll even travel from one area to another.
  • The fairy can be used to make Pino — if he’s trusting enough and not in a foul mood — approach specific items or pieces of scenary. This results in a short sequence where Pino attempts to puzzle out the function of said object, after which the player, via the fairy, can either approve or deplore his actions. This is a central mechanic of the game, and it works fairly well. Pino’s actions are based on his statistics, but there’s still quite a bit of randomization, and the setpieces themselves are pretty entertaining. Putting the player in the role of a caretaker also works to create a bond between himself and Pino.

    wonder project j 0295 Wonder Project J bits.

    Apparently no one expected them to pull it off.

  • Pino’s statistics are in a constant flux as virtually every action in the game changes multiple variables. There’s still an overall progression to his growth, but it’s filled with lots of fluctuations on a micro-level. Even the game’s numerous items enforce this principle.
  • Various cutscenes are employed in the game, often to present a challenge and outline its requirements. During these segments, the fairy addresses the player and tells him to sit back and watch how Pino reacts. These setpieces not only serve as goal-dispensers, but are also used to further the storyline and character progression.
  • Whenever Pino fails a challenge, the fairy offers up clues as to how to beat it, and even mentions other NPCs that can provide further advice.
  • WPJ itself is split up into chapters, and at the end of each one a new “circuit” is activated. These circuits represent Pino’s human-ness and the player’s progression in the overall quest. The chapters themselves also require various tasks to be completed, and this approach provides the player with a constant stream of mini-goals that are tied together by an overarching story.

, , , , , , , , ,

1 Comment

The 1-pixel collision box.

In the early 90s, a trend developed among shoot-’em-ups that was affectionately (or was it rancorously?) dubbed “bullet hell.”

touhou10fs4 The 1 pixel collision box.

An example of bullet hell. It gets worse. Much worse.

The impetus behind it was to add visual flair to 2D games in order to compete with the craze surrounding 3D games. Arcade cabinets were more powerful than ever before, so these shooters could handle more sprites and the extra calculations required for the accompanying collision checks. The approach worked relatively well, providing plenty of “Holy Shit!” moments. However, there was one major issue: playability.

ikaruga2 The 1 pixel collision box.

Ikaruga's dual colour scheme was central to the gameplay throughout the whole game.

Shoot-’em-ups tended to be one-hit kill games, and simply saturating the screen with harmful projectiles would’ve made them incredibly difficult (if not downright impossible). Now arcade games are meant to take your money, but that wouldn’t happen if no one played ‘em. In order to implement bullet hell without alienating customers, something had to give.

Part of Ikaruga’s solution was to make all bullets and your ship one of two colours, and then simply ignore collisions between like-coloured objects. Other titles used shields and various powerups, but the original solution, and, in a way, the purest to the genre, was the 1-pixel collision box.

Instead of surrounding the majority of the player’s ship with an area susceptible to fire, a single pixel was used to indicate its vulnerable spot. This was a rather elegant solution as it required no other changes and didn’t present an extra hit to performance. Players were also less likely to feel cheated if they came out on the positive end of some collision-fiddling. The end result looked something like this:

saint dragon 03 The 1 pixel collision box.

Saint Dragon's eponymous lead actually looked pretty good in motion.

The visual oddity of having the player’s ship fly straight through harmful projectiles was lessened by the nature of the top-down perspective. This view had issues with representing depth/elevation, and that actually made it easier to imagine bullets just skimming over the player’s ship. The 1-pixel collision box also had the side-effect of making the player feel more skilled at the game, which, in the very least, provided the illusion of empowerment.

As a side note, something of a similar concept was used in an old Amiga shooter called Saint Dragon. The player’s ship, the Saint Dragon, consisted of a head and spiraling tail. The head used regular collision detection, but the tail was purely aesthetic. This added scale and personality, and allowed the player to control a vehicle that seemed grandiose despite being virtually identical to countless other shoot-’em-up ships. The head could be easily destroyed, but the tail would actually absorbed many types of bullets and even damage most of the enemies it touched.

Supplemental:

Since I’ve posted this article, it’s gotten a lot of attention from numerous shmup enthusiasts. Many have been eager to bring up the specifics of the tiny-collision-box phenomenon, as well as variations on the theme. I think that’s great, and one of the sites that has been pointed out to me contains a lot of interesting information on the genre. Of particular note are its threads on shmup strategies, the dos and don’ts of good shmups, and the glossary of common shmup terms.

, , , , , , , , , , , , , , , ,

43 Comments

Robotron: 2084 bits.

Before Geometry Wars and the dawn of the twin-stick shooter, even before Smash TV, there was Robotron: 2084.

robotron2084 title Robotron: 2084 bits.

Robotron: 2084 in all its glory.

robotron Robotron: 2084 bits.

A typically hectic scene from the original Robotron: 2084.

At its time, it was quite innovative and considered an instant classic. It also went on to influence many other games, and even got an XBLA port. These bits, though, are based on the original arcade version:

  • The brain-child of Eugene Jarvis, Robotron: 2084was the first action/shooter to feature two joysticks. One was used for moving the player character, and the other for choosing the direction in which he fired.
  • There was no scrolling and the game’s background was entirely black, providing a high contrast for the on-screen action.
  • Each of the game’s enemies had a unique look and behaviour. Grunts endlessly pursued the player, their speed increasing as they got closer to their prey; green Hulks stalked the remaining human survivors and could not be destroyed — only slowed down — by the player’s shots; Enforcers flew around and peppered the player’s vicinity with harmful projectiles (which, unintuitively, also traveled faster the further they were away from the player); Tanks fired bouncing shells that rebounded off of the screen’s edges; and Brains launched homing missiles and could reprogram humans to turn on the player.
  • The Quarks and Spheroids were some of the earliest examples of spawning machines, a prevelent aspect of the eventual Gauntlet.

    simrobotron2084001 Robotron: 2084 bits.

    The game's Xbox Live Arcade port.

  • Since many enemies materialized in waves and didn’t continuously fire at the player, they would often end up turning the empty arena into a dynamic maze. Walls composed of grunts would close in on the player, forcing him to avoid the obstacles and blast through the oncoming danger.
  • Electrodes were somewhat representative of static but harmful environmental objects. The interesting thing about them, though, was that the player could not only destroy them, but also use them to kill other enemies.
  • Adding a bit of a defensive element, Robotron: 2084 allowed the player to shoot down the enemies’ projectiles with his own.
  • The game had a rather dystopian vibe with the player attempting to save the last humans from the “robocalypse.” More specifically, he was saving the last human clones, suggesting that it might’ve already been too late.

, , , , , , , , , , , , , , ,

4 Comments

You got RPG in my fighting game.

Combining genre staples has been around for a long time. It’s a technique that, when well executed, can create some really interesting experiences.

But is it applicable to fighting games?

snap00065 You got RPG in my fighting game.

Are character-levels a good idea in a fighting game?

Read the rest of this entry »

, , , , , , , , , , , , , , , , , , ,

33 Comments

Strange Adventures in Infinite Space bits.

Strange Adventures in Infinite Space is an tongue-in-cheek indie game in the vein of Star Control and Starflight. You travel around a large galaxy, meet alien species, discover powerful artifacts, etc. The thing that sets it apart, though, is that playing through the whole game lasts roughly 5-15 minutes.

sg08 Strange Adventures in Infinite Space bits.

SAIIS' quirky splash screen.

Much like some other titles, SAIIS distills the gameplay of the games that inspired it and streamlines the overall experience. This shortened and simplified approach might seem a bit off-putting at first, but the fast, score-based playthroughs can quickly become addictive.

The important parts:

Read the rest of this entry »

, , , , , , ,

3 Comments