exploiting kid icarus for metroid hack purposes (long read)

[Stinktier]

With Kid Icarus and Metroid being developed at the same time, by the same people, at the same nintendo departments (r&d1 and intelligent systems), it should come as no surprise that a lot of the code is similiar or even the same. Playing the games, there are some indicies and even dead giveaways. If you remove the side walls in a vertical corridor in metroid, you'll see the same horizontal wrapping of the player position action t
at kid icarus is known for. The one sort of scrolling at a time (much due to the limitations of the mmc1 mapper)-thing. The save or password pak system is another thing. Design ideas constantly reoccur, as permanent upgrades and mazelike dungeon areas. They even, probably as a reference joke and/or cross-advertising effort, included not-so-fearsome infant metroids as an enemy in icarus. 

The purpose of this thread is to discuss possible ways to benefit from the two games' similarities. I'm convinced that the study of kid icarus will lead to better and more varied hacking possibilites of Metroid (and vice versa, but that's not the focal point).

Hardware notes:
[spoiler]The aim is to deduce if hardware limitations may have affected design choices for the two games, but since both were released on famicom disk system which i know nothing about, this whole section might be overkill. Skip this section if it doesn't interest you.

Both games, naturally, use the same MMC (1) and the same datasize for prg eproms. char RAM chips seems to be a bitt different, as they are configured precisely as ram and not rom; to my understanding using only 8KBs. The chr CMOS chip from SHARP used in european metroid cartridges, for example, state in their datasheets that they can be used as ROM with a capacity of 64KB (only half of what an expando needs).

There are some variations: Kid icarus cartridges from spain, the rest of europe, and the US use a RICOH rom mask at a speed of 250 ns for PRG (that's 4mHz) and two Mitsubichis @ 150 ns (~6.7mHz) for CHR ram and WRAM respectively. The canadian release uses components from SHARP at a speed of 180ns. I'm not sure if the difference in terms of performance is detectable or even applicable.
Metroid cartridges sold in N. America has NEC chips at a lowly speed of 200ns for CHR RAM and WRAM, while the spanish version was eqipped with for its time high-speed 70ns (~14.3mHz) chips from phillips. The rest of europe carts contained SHARP LH5164D3-L:s with a quite good access time of 100ns. Callan, a repro builder, states that games should have a speed of 100ns or higher but i believe he may have mistaken a higher number for greater speed. It's really the opposite. Again, I can't say if the difference is that noticable, with other bottlenecks in the system, but north americans will have a better specced kid icarus cartridge than a metroid cartridge. The opposite goes for spanish pal-b cartridges.

Both the CPU and the PPU could benefit from faster memory access time (like in spanish metroid cartridges), but then there's the program cycle and possibly bus speed problems. All in all, i know too little about these kinds of things.[/spoiler]

Here's my notes on a complete play-through of Kid Icarus; attempting to pin down designs of interest. I tried to note down every thing that came to mind; the approach being that everything is assumed to be possible to do, even things that go well beyond vanilla metroid's software capabilities.
Some/a lot of stuff may require some serious restructuring. other things may be minor tweaks. Hopefully, some stuff may be of the plug-and-play variety. Real programmers will see this much more clearly than i do.

Enemies and hurting blocks (the interesting ones are bolded):
[spoiler]
This bit is a little like reinventing the wheel with all the wrong names on the enemies since there are perfectly clear strategies online describing enemy mechanisms. It is mostly an autography in which i attempted to note down if there was some certain enemy scripts and/or inspiration sources for tampering with the enemy setup in metroid.

-snakes fall and crawl
-reaper calls up four hovering  minions when met face to face. shanges animation and runs faster. also changes music ... this should be disabled if implemented into a metroid context
-sweeping eye squid thingies... meh. basic shmup enemy.
-reaper's minions seem to do basically the same thing as the eye squid thingies
-evil fire lay hidden in the ground and ambushes (sometimes from behind) and throws a fire projectile. possibly good in a metroid context.
-frogs... duck and walk? meh.
-hermit crab without a shell-flying-things? No, apparently they're called specnoses and i couldn't see what they resembled until i read about it  :eyeroll:. appears out of thin air with a special animation. 8 at a time!
   would be a great addition to boss fights if it weren't for probable slowdowns and/or projectile maxcount.
-octopuses attacks in groups of four from below with 'swimming pushes' moving upward. Changes pattern when close to
Pit. should be great in vertical corridors.
-divine training blocks. behaves pretty much like hermit crabs but a different movement pattern, and seems to
respawn. even better for our purposes.
More research has to be done but i think either a timer or a death count causes a trigger. i counted to 29 or 30
enemies killed. the trigger could release doors, make ridley/kraid appear, make an item appear etc.
From fortress:
-fortress octoidskulls. much like training blocks, but doesn't reappear.
-fortress monocle grunts. very basic and boring. unlike frogs, they avoid falling off platforms.
-fortress spear traps. has a certain pattern.
-eggplant wizards. seriously, what's upp with all games containing eggplants? Commander keen, ice climber...
Walks around throwing eggplants. pretty useless given samus is much more sturdy and agile, if it weren't for
the very interesting eggplant curse which disables shooting. a shop removes the curse.
-dog from hell boss. not too clever, not too interesting, but the fireball pattern it exhibits may prove useful.
-falling rock men. perhaps usful albeit simple.
-antlions. pretty much the same as evil fires, but with other graphics.
-seahorsey bubbles - shows up from below like octopuses, though individually upon horizontal proximity. doens't do
too much after the appearane sequence.
-flying piranha plants. not much fun

-snowmen. basically an eggplant variation with different projectile trajectory more suitable for horizontal play.
-jumpy froggy. jumps, short idle animation, jumps, short idle animation...
-jumping gnomes/thieves. not much fun. much like jumpy froggy but with lower jump trajectory.

-2nd fortress hovering mushrooms. pretty shure these are a reskin.
-2nd fortress walking mushrooms. reskin of 1st fortress grunts.
-2nd fortress spear traps behave differenty; jabbing in a serial sequence. the speartrap behaviour, as i think it becomes clear in the 3rd fortress, is dependent on the number of speartraps in a single room.
-2nd fortress Boss: jumping dragon/snake. Really cool stuff - and it would fit right into a metroid scenario with altered sprites.

-templar angels - stationary enemies
-flying mini eyes - trajectory from side to side of templar angels. not dependent on the templar per se.
-spike heads. evil fire reskin once again
-flying gnomes. slow, gets faster within proximity of Pit.
-metroids. seriously, they look exactly like metroids, only smaller and without the latching/sucking capability. Seems to share the pattern of death's minions.
-angry jellyfishies - behaves much like the octopuses, but i think they had a different, more jumpy frog-like
mode after their initial move.
-wall tentacloids - looks very cool, even metroidy. Nice inspiration. These aren't really enemies but (air-passable?) hurting tiles.
-barbed tangleweedy stuff. graphical variant of wall tentacloids.
-upside down jellyfishes. yet another variant of the two described above.

-3rd fortress spike balls that behaves MUCH like super metroid puffers in the quicksand falls,
only more dangerous. Nice! Comes in lots of 8 without slowdown. I really wonder how that is done?
-3rd fortress bubble armor grunts - not interesting. btw, all these grunts are falling when spawned from mid-air,
though they never walk off platforms.
-3rd fortress boss basically involves two small, nondestructable lower norfair bouncing spheres (though slower)  and one bigger, even slower moving dito with a face. this boss design is pretty generic. It has the power to camouflage its sprite to complete blackness, though it is still visible when floating over other objects as it is rendered after the 'world'. The lesser balls can change in 8 directions when they bounce. The boss itself makes a pretty rad explosion when it is defeated.

-last level creatures:
--falling blocks. falls in sequence in groups of four at the same horizontal position. staples up on each other if they reach the ground.
--ambushing-from-behind flower-looking things. if they fly past Pit, they slow down, change direction and fly off-screen from where they came.
--exploding guy who throws fireballs at you. when killed it splits into three flying enemies.
--diving angel squad. comes in groups of four in an upside-down arc.
--flowers, again - these jump up from below screen and hover around until killed.
--ghosts - your average shootemup sinoid pattern obstacle.
--last level boss: medusa. not completely unlike mother brain. hurls bouncing reptiles and shoot stare-waves in
Pit's general direction. stationary.

The main issues are how to 1) make metroid recognize more enemy variations 2)squeeze their graphical data into the rom. 3)allow for more enemies to be able to spawn 4)figure out why some enemies don't cause slowdown even when they're in big quantities. 5)How to squeeze in more bosses. the snake boss is of particular interest as it seemingly only uses 4x2 tiles for head animation and 1 tile reproduced for every tail part.
[/spoiler]

Game engine/Level design notes/other stuff:
[spoiler]
-different rendering order. in icarus, contrary to metroid, Pit can stand 'in front of' some sprites and 'behind'
others. In vanilla metroid, samus is always 'written' before area sprites and thus always stand behind stuff.
while this is effectful for 'hidden' passageways, it reduces the background to always being black and sterile.
Unsure how the rendering order is implemented in icarus, but it _could_ be a palette variable property, ie.
palette a and b are rendered before samus, palette x and y are rendered afterwards, a and x / b and y
representing the same colours.

-Pause screen shows inventory list.

-the stair object in fortresses trigger a room swap that is vertical -very useful! One needs to apply the scrolling
from normal doors for it to feel metroidy, though. Possibly though, they may be just the same as normal fortress
doors but with a trascending/descending movement enabler tied to the blocks directly above/below

-kid icarus' doors are very unmetroidy to their appearance, but their function could still be used.
for instance, in a metroid hack with a single-screen room, an object with icarus door propertys could act
as a 'teleport' to an almost identical room, and therefore act as an illusion that it is the same room, only
more dynamic. the wait time sequence has to be nulled for this to work fluently.

-upside down pots. seems to be nothing more than a solid block. the snakes "falling out of" them have an interesting mechanism though: in metroid, you can reset enemies to respawn upon death. these keep spawning at an interval until a max counter is met. reacts upon proximity. unsure if this is a property of the pot or a variation in the snake enemy.

-onscreen amount of enemies seems to be less limited, although 8-9 enemies combined with shooting will cause slowdowns in some occasions. Strangely, this doesn't seem to apply in the room with the 8 hermit crabs, spikeball-puffers and some more. Two highly speculative thoughts: a set of enemies may use the same calculation, thus saving juice. Or; the slowdown is only apparent when juice is needed for scrolling.



to save juice for the number of enemies.

-MOVING PLATFORMS!! they sense obstacles and turn around. comes in right/left and up/down varieties depending
on horizontal/

-boutiques: they feel like they don't belong in a metroid game. the mechanisms may be used in some hack if someone wanted to, in a different graphical representation. essentially, hitting a certain block refills ammo, life, etcat the cost of hearts, the currency in angel land. The code could be facilitated as refill stations we know from super metroid etc. More importantly, the hitting a block triggers x-function may potentially be used for triggering other things, like swapping a structure to create passages (swap a solid structure to breakable/air/door, swap acid to water...)


-the ability to "wrap" player positions horizontically  in vertical rooms. This is still left in metroid.
It almost works the other way around to, i.e vertical wrapping in horizontal rooms, but samus sometimes get stuck
and takes damage that way. The latter is not recommended without reprogramming.

-The harp: makes all enemises turn into pickups. Could be used much like the crucifix in castlevania, ie.
kills all enemies within view (possibly undestructable platformers too). Could possibly be presented as either
an enemy drop or orb contained/destrucable block-hidden, non-storeable item. However, the limited enemy count
makes this item somewhat useless as an 'action' item.

-Some platforms are through-jump ones. they also have the property of dropping through when pushing down on the
d-pad (at least in fortresses). Some are 1-tile high, others 2-tile, which indicates mixed property blocks (if icarus
uses a similar structuring system).

-statues in fortresses are smashed with a special weapon. maybe some blocks could be converted to only be destroyed by missiles.

-angels rescued counter that sticks regardless of room swapping.

-score and total score system. not very metroidy and defenitely more arcadey but could probably be implemented.

-not much to say about permanent upgrades. the two spinning fireballs around Pit are pretty cool, though, because it is switched on/off by the game depending on area.
[/spoiler]

That should be some food for thought. Please pardon the notes being a bit unpolished. I wrote them in a contious flow.

As for the game code itself, i can't get Tracer disassembler to work on windows 8. Bummer.

Here's a little something i found by quick-googling:
http://www.thealmightyguru.com/Games/Hacking/Wiki/index.php?title=Kid_Icarus:_Angel_Land_Story

[mrrichard999]

Does this possibly mean you can take some of the enemy behavior and add that to Metroid from Kid Icarus? Snarfblam is working on expanding the ROM even more at the moment. Maybe some interesting new things could be taken from one and added to the other :D

[Stinktier]

Hopefully, yes (with many maybes, haha). To my understanding it's not as much (expanded) metroid's filesize which is the problem (or, well, the amount of program code which can be added to the engine is pretty limited if i remember it right), but the structuring of the program in itself. For instance, there is a bit of code which in some way checks if each of the six 'enemy slots' are preoccupied. if so, a new enemy with the same number doesn't generate. Except keeping slowdowns at bay, i think it is also what helps the engine remember not to spawn multiple instances of the same enemy object upon scrolling forth and back in the same corridor.
However, clearly kid icarus has another solution to this scenario; or it has more enemy slots. And it certainly has more enemy AI classes to cycle through, and plenty of 'skins' to go with these AI classes. The programming _could_ be applicable to metroid, but i'm not sure. The puffer-behaving enemies of the 3rd fortress (apparently known as Tros) would work REALLY well in a metroid context, aswell as the 2nd Fortress boss. The mini-metroids could be graphically ripped. Here's a more orderly enemy list with the correct names and descriptions. http://strategywiki.org/wiki/Kid_Icarus/Enemies - the best thing is to see them in action and judge for oneself what enemy behaviour would fit nicely or not.

Personally, i'm very interested in vertical room transitions, aswell as the rendering order, ie. if it's possible to assign certain structures to be written to the nintendo's video ram (or however that works) earlier in sequence than the samus and enemy sprites in a cycle, thus creating the effect of backgrounds. It certainly works that way in KI (mountain backdrops being the most notable example). It would help make planet zebes feel much less sterile. It's just one tiny literal bit of data that needs to be processedm and KI (and many other games) does it, presumably by calling the area draw routine twice and let the area draw routine branch if certain conditions are met. Or, background tiles could have its own small routine altogether. we'll see.


Using Cortez Ralph's 6502 disassembler i got the opcodes to more readable mnemonics. Now to analyze it...  :blush:

[mrrichard999]

With this news,the new Editroid being worked on, and Snarfblams further expansion of the ROm, maybe the combination of these could create a really awesome Metroid! If there were another level for Samus to go to were added (Maridia in NES?) a possible addition of a new boss using the kid icarus code would be really great!

[Stinktier]

As for a 'maridia' theme, it isn't entirely impossible to replace the two gravity constants (which determines the length of normal and hi-jump) with variables, enabling different modes of gravity. Heck, even enabling gravity suit if you have an item slot to spare.

[Meeptroid]

Now that would be cool, Maridia in NEStroid and Gravity Suit as well, that would be really cool, sadly I just don't have the hacking skills to do that one......yet