Difference between revisions of "Raiden II"

From The Game-Maker Archive
Jump to navigationJump to search
 
Line 84: Line 84:
 
== Links ==
 
== Links ==
  
<videoflash>o_mFDShMEuk</videoflash>
+
<youtube>o_mFDShMEuk</youtube>
  
 
* [http://www.youtube.com/watch?v=Z4opNJFV0Vw Clip of older version (YouTube)]
 
* [http://www.youtube.com/watch?v=Z4opNJFV0Vw Clip of older version (YouTube)]

Latest revision as of 22:01, 2 July 2021

Raiden II
RaidenTitle.gif

Release type: Incomplete
Release date: 1994
Levels: 1
Author: Alan Caudel
Website: DummyDuck.com
Related games: N/A

A successful life is about hacking the system: working out how to do stuff with what limited resources you have, without regard to proper procedure. And hacking is about probing; feeling out the cracks in the system, watching what drips through, testing your whims and theories, and building your own meta-filter to slot on top.

Game-Maker's system is made for top-down adventure games like The Legend of Zelda; if you try something else, you're going to meet resistance. Try to make a shooter, and the system will say to you, that's a strange sort of adventure game. It will run what you plug into it, but it won't know what you're trying to do.

So, most scrolling shooters are kind of a mess on this engine. What Raiden II does a bit differently is it takes a step back to think about what it feeds into the engine and how that will be understood, then adapts its input accordingly.

RaidenSprite.gif

For a template, Alan Caudel broke down Seibu Kaihatsu's seminal Raiden series and tried to put it back together again. It was a good choice; the Raiden games are about as pure as a shooter comes. All you do is fly, dodge bullets, shoot enemy targets, and drop the occasional bomb. Power-ups are a simple affair that mostly just change your shot patterns.

So with that game as his model, Caudel came to focus on its main action: shooting. There are two components here; outgoing shots, and incoming ones. Game-Maker makes both of these a little twitchy, but one far easier than the other.

On the player's end, the ship has a choice of several shot patterns: bullets might go straight ahead, or spread like a fan, or other shapes and with different numbers of bullets per keypress. What should happen here is that as you collect power-ups you get to increase the power (i.e., bullet count) of your current shot pattern, or you pick a different pattern.

Screenshot from Raiden II

Although Caudel did a marvelous job at tracing bullet paths and layering them to create different shot levels, Game-Maker's design ensures that the upgrade path does not take the most logical route. In Character Maker, actions that use the same keystroke are tiered in priority. If you can do action 1, you do it; otherwise you do action 2, and so on. The variables that determine whether you can do an action are whether you have enough of the unique associated shot counter, whether you have the correct inventory item, or both. There is no ambiguity; if you fulfil the requirements, you will always do that action. You can't, for instance, select another inventory item or get a new power-up to switch actions -- unless that power-up knocks you up a level, qualifying you for a "better" action.

Even for levels of a single shot pattern, this structure causes problems. Each power-up you get can only increase a single counter, and each action has its own counter -- and the thing those counters determine is how many shots you have. Furthermore, Game-Maker does not display most counters in-game, so the player will never have a good idea how many shots are left. The best solution within an individual pattern, then, would be to layer power-ups on top of each other; each power-up would increase one counter of that pattern by a set amount, and the player would automatically use the strongest. When those shots were expired, the second-strongest would take over, and so on. This is a weird behavior, and far from ideal -- but just wait until different shot patterns get involved.

Basically, there is no way to dynamically switch weapons and increase the power of those weapons. So, what to do? The only thing available: assign each shot type to a different key. It's not elegant, but at least you'll get to use all the shot types. Maybe you can design a game that works around this concept, rather than trying to force a logic that will never work. Roll with the punches. Maybe in a follow-up project Caudel would have done just that. Here, we have an experiment.

The experiment continues with enemy shots. Game-Maker, is of course, a little wonky with its sprite logic. Whereas characters can birth a monster (e.g., a bullet or a melee weapon) as part of any animation sequence, monsters can only birth another monster at death. As a consequence, enemy sprites are unable to fire projectiles or otherwise attack by means outside their standard movement and animation. Yet, what is a shooter without shots to dodge? So, as Roger Levy separately did in Andy in Asunderland, Caudel figured it out.

Set background a block to birth a bullet monster at set a interval. Place a stationary monster of equal power level on top of that birthing block, and it appears that the monster is shooting. At death, cause the monster to birth a higher-level monster that blends into the background block, capping it off and killing the bullet monster in the same instant it would birth. It's an elegant solution, and with a couple of tweaks (say, making the first frame or two of the enemy bullet harmless) it would be perfect for stationary threats. The same logic might even extend to mobile threats, if one could carefully synchronize background and monster animations. Here, though, Caudel stopped at recognizing that in that single frame where the bullet is birthed and killed, it still causes damage -- invisible as it may be. So, he worked around it; he made the monsters solid. Therefore, for no clear environmental reason the player is unable to fly over destroyed installations. And you thought invisible walls were an innovation of the PlayStation era.

There are other issues and observations. As in other Game-Maker shooters, you can't shoot while you're moving or move while you're shooting. It's a limitation of RSD's engine, that takes some work to skirt around. The sprite and tile work here is really nice, copied as it may be from existing sources. It just goes to show how professional a Game-Maker game can look, with the proper attention.

Overall, Raiden II is a noble experiment that does an excellent job of showing what Game-Maker can do with a shooter. Add in the monster patterns of Pipes and Ego Force, and you've got the startings of a solid scrolling shooter. Though, come to mention it, that does leave the issue of scrolling...

Story[edit]

N/A

Instructions[edit]

There are weapon upgrades which flash yellow and blue scattered around the map. Which weapon you get depends on what color the block is when you pick it up. Yellow weapons have a wider spread range, but require repeated button pressing. Blue weapons have a more narrow range but you can down the button for automatic firing. There are three level upgrades for each weapon.

For best results, use the numerical keypad.

  • Arrow keys: Move your ship.
  • Q: Fire first level cannons.
  • W: Fire second level cannons.
  • E: Fire third level cannons.
  • B: Drop a bomb.

Credits[edit]

Game designed by Alan Caudel.

Background[edit]

Exploring power-ups in an early version of Raiden II

Alan Caudel:

One of the hard parts about making this game was making tanks that shoot at you, and then stop shooting once you blow them up. It required a background block that generated a "bullet" monster block, which was covered by a tank monster block.
If I remember correctly, the tank and the bullet had to be the same level or else one would kill the other upon contact. Then when the tank was destroyed, it was replaced with a "destroyed tank" monster block which was a higher level, and destroyed the bullets which kept generating from the background block underneath, so the destroyed tank would no longer fire bullets at you. This took a while to figure out how to get it working correctly, but I think the end result was good enough.
Also, I think I had a problem where if you flew over the destroyed tanks, you could still die if a bullet block generated and you touched it in the split second before the "destroyed tank" block killed the bullet. So... I had to make the destroyed tank monster blocks solid. That was kind of a hassle, because it meant the jet couldn't fly over a destroyed tank without running into it. But I sacrificed realism for playability I guess.

Availability[edit]

This game is not known to have been distributed in any form, prior to its addition to the Archive.

Archive History[edit]

There are two known versions of Raiden II, both very incomplete but one more developed than the other.

On October 20th, 2010, Alan Caudel commented on a YouTube clip of Peach the Lobster, mentioning that he had used RSD Game-Maker. On December 7th the site contacted Caudel for further comment. At that time he was uncertain if his Game-Maker material still existed.

On June 29th 2011, Adam Tyner located and passed on to Caudel a selection of his, Caudel's, and Yurik Nestoly's old games, including the simpler version of Raiden II. That version was uploaded to the archive on July 5th.

Later on July 13th, Caudel found and offered up a further selection games, including the second and more advanced version of Raiden II. After some restoration, that version of the game was uploaded to the Archive on January 28th, 2012.

Links[edit]

Downloads[edit]