After a year in the works, ZoomZike’s epic in-depth series examining each game in the Mario Party series has reached the Nintendo DS version, and as always it’s very long (4½ hours this time!) and extremely detailed. The title makes it sound like it’s got a very narrow focus, but the Identifying Luck in Mario Party series is more like a comprehensive review of nearly every aspect of the Mario Party series. They’re among the best game breakdowns you can find on Youtube!
ZoomZike doesn’t just cover Mario Party games on his channel, and we linked to his video on Sonic Adventure 2’s Final Rush level, but the Mario Party series is probably his greatest achievement, and are like a complete strategy guide and a course on game design all in themselves.
This one, I won’t lie to you, is pretty dry. It’s an hour and a half of the Retro Game Mechanics Explained narrator describing, in precise detail, how Super Mario Bros. 2 builds each of its rooms from a couple hundred-or-so bytes in the game’s ROM. It’s an hour and 39 minutes, actually:
Even I began to drift off a few times through this one. It is exhaustive, and exhausting, but it’s very thorough.
I won’t even try to explicate it all in text, but here’s a few interesting tidbits of information:
Super Mario Bros., the original, built its levels on the fly. As you scrolled forward, the engine read the upcoming data and constructed it up ahead, off screen, in real time, always keeping ahead of the screen’s edge. This is why you can’t scroll backwards, the list is designed to be read going left to right. SMB2 instead includes extra RAM in the cartridge and uses it as a memory buffer to hold the entire current room, up to 10 screens in size. When you enter an area, the game takes a moment to construct the map in that buffer, and copies it to the PPU’s video RAM as you scroll around.
Instead of with stored as-is tilemaps, SMB2’s, as well as basically all of Nintendo’s scrolling games at the time, are constructed, made out of tile objects with different locations and parameters attached to them. This saves a substantial amount of ROM space, and functions as a kind of bespoke data compression.
The rooms are built screen by screen, although it’s possible for some items to extend horizontally or vertically outside of its home screen.
The format makes it seem like vertical rooms were designed first, and horizontal scrolling areas were then added to that functionality.
There are weird special cases everywhere in the building code! Some objects only work on certain levels, or serve different purposes in different worlds.
Birdo’s color, and behavior, depends on its initial spawning X tile position. If it’s 10 she’ll be a pink Birdo; if it’s 11 she’ll be red, and all other values mean a grey Birdo will be generated.
On the enemy list, entity numbers 92-127 are the same as the entities numbered 64 less than them, but with the property that, when they are despawned, the level ends! This property is used for world-ending bosses, but any entity in that range will end the level when it leaves play, even Mushrooms if one such existed.
Crawgrip, the boss to World 5, was added to Super Mario Bros. 2 during its conversion from Doki Doki Panic. The decorative rock background objects in its boss arena are especially hacky, like they were hastily added.
The stars in the sky in the night levels have a bug in their generation that prevents any from appearing on the first screen of their areas. They also aren’t placed specifically, but using a pseudo-random generation algorithm that always uses the same seed, so they’ll always appear in the same places in the sky.
It’s information I’d much rather see in text, and I find the video a bit annoying from a construction standpoint (the speaker has a bad case of Youtube Voice), but it’s really interesting information regardless. This video from Abyssoft contains a deep explanation of MK64’s opponent driving algorithm, and explains that the game selects two rivals for your character on each cup, and that opposing drivers pick one of three paths through the course, and can clip right through walls if needed to continue driving around the circuit.
ZoomZike’s back with another epic-length exhaustive examination of the hidden mechanics and math behind a Mario Party title, this time the Wii game Mario Party 8. At three hours and 34 minutes it’s not as long as the nearly five-and-a-half hour video on Mario Party 7, but it’s not any less detailed.
I can’t think of any more detailed descriptions of the hidden mechanics of such a complex game as these. The time and effort it takes to make them suggests mania on the part of the creator, but I’m still glad they do! It’s fascinating the care that these apparently-chaotic games were made with, and how their secrets were discovered by attentive players. I suggest not watching it all in one sitting, but in segments over several days. If you care about the subject at all, that is. But as should be evident, I do care, and I think you might as well if you’re interested in game design and give it a chance.
Here’s another of those deep-dive NES internal videos from Behind the Code, possibly the most complex one they’ve done to date. Most game engines, when you examine their basic logic, are basically physics simulations, with some AI included to determine how actors behave.
Not so with the Punch-Out!! games. They are essentially entirely different kinds of games from that. You have certain things you can do moment to moment, and opposing boxers do too. Each of those opponents basically runs a big script, made out of byte code, that determines their behavior throughout each round of each fight. I am struck both by the simplicity (no need to simulate gravity) and the complexity (boxers take all kinds of things into account) of the system.
One of the interesting things shown is that the engine can affect more than just the boxers, but can also subtly affect the crowd, which is how the previously-revealed fact that a specific camera person in the crowd uses his flash right at the moment the player must counter Bald Bull’s charge move. It turns out that this isn’t the only instance of this happening in the game!
You don’t need to know 6502 assembly code to get what the narrator is talking about, but a lot of code is shown, so those of you who understand it may get a bit more out of it. Here are a few basics to help you follow along.
The 6502 has only three registers (bits of memory internal to the CPU that can be accessed quickly), the Accumulator (sometimes called just A), the X register, and the Y register. Each is only one byte long. The Accumulator is by far the most flexible, but all three are general-purpose registers. The most common instructions are Loads (LDA, LDX, LDY), Stores (STA, STX, STY), Transfers between registers (TAX, TAY), Incrementing and Decrementing (INX, INY, DEX, DEY), Adding (ADC), Subtracting (SBC), Comparing (CMP), Branches (some of them, Branch Not-Equal to Zero: BNE, Branch Equal to Zero: BEQ, Branch of Carry Set: BCS, Branch on Carry Clear: BCC), Jump (JMP), Jump to Subroutine (JSR), and Return from Subroutine (RTS). While some instructions are just one byte long, the longest any 6502 instruction can be is three bytes, and the opcode (the command itself) is always just one.
(I wrote all of that from memory. I figured, I have all of this in my head from my coding youth, I might as well use some of it.)
The 6502 can only address 64K of memory, so often systems will use bank switching to connect various memories to it within that space. The great majority of NES/Famicom games had to do this. Punch-Out!! was unique on the NES in that it was the only game to use Nintendo’s MMC2 chip. (I wonder if the chip was designed ahead of time, and they made this game as an excuse to use it?) Punch-Out!! uses MMC2 to bank in each boxer’s large data script as needed.
