It’s a good one today folks. Modern Vintage Gamer had a look into how the CPU opponents of two of the most popular and foundational fighting games, Mortal Kombat 2 and Street Fighter 2, cheat against players trying to progress far into the game on their meager financial resources.
Their Mortal Kombat 2 video (11 minutes) is three years old now and has racked up 1.5 million views, but it’s well worth reviewing. While MK2’s source code is not known to the public, UK3 for the Playstation’s source is known, and is suspected to be similar to that of the earlier game, and uses a dynamic difficulty variable called diff. MVG uses this source to make an educated guess of how and when MK2 decides to cheat.
Lest you think it’s only us filthy Americans who would resort to such underhanded means to rob honest teenagers of their quarters, Street Fighter 2 does it too! Much more recent is MVG’s four month old video (9 minutes) on that game. (If you’d like to skip the video’s preamble, this link is queued up to the beginning of the cheat discussion.)
In brief, the games use input reading and the ability to perform complex moves lag-free to get an edge over human players. A player would have to enter moves on the joystick and with the buttons, while the CPU can just do them, without having to spend that time. And by reading the player’s inputs (like the Ironknuckles in Zelda II), they can react to player actions reliably, where a human opponent would have to judge based on vague visual indications, and then respond with a move to counter your action that was already in progress.
I know it’s great because it includes a few games already mentioned on this blog, like Gar-Type! Find it (the list) here! And consider following Dominic on Bluesky or (via BridgyFed) Mastodon!
What can you use as a focus image for a post like this? I guess a screenshot is fine.
The N64 came out after the release of the Sony Playstation, which had already begun its meteoric rise. The Playstation used optical disc media, and had no on-console memory for saving like the Saturn did, so memory cards were a necessity for saving game state. While the N64 didn’t absolutely need them, since the biggest advantage of cartridges as a game storage medium was the ability to include hardware like flash storage in the cartridge (a feature used in Super Mario 64, the first system pack-in), an iconic feature of the N64 was the controller ports, which allowed the use of flash memory cards that could hold save data for multiple games.
As the video demonstrates, memory cards were plugged directly into the controllers, and controller paks allowed for some nice features. My favorite was how Gauntlet Legends allowed players to save characters to their own memory card, so you could maintain state between games played on different cartridges. (This feature would be retained in the Dreamcast version of Gauntlet Legends, which also had controller port memory cards.)
The Nintendo 64 didn’t have a BIOS or other internal boot time code. Like with the SNES, all of its executable code was contained withing the cartridges, or “Game Paks.” (Nintendo certainly loved to call hardware “Paks.” Pak Chooie Umf!) This meant that controller management features couldn’t be included in the console itself as with the Playstation, and any management would have to be done in the cartridge itself.
I don’t know if it was a Nintendo mandate that all games that used memory cards had to include their own menu to manipulate saved data, but in practice that’s what happened. All those games with their own controller data managers! And many games didn’t even expose them in the menus. I suspect that to this day many former and current Nintendo 64 owners don’t know, if they want to check what data is on a card or delete something, they have to insert a card-supporting game and hold Start while turning the system on.
Not all games! Just games that use memory cards! And the weirdest thing, which the video makes a deal out of, is that every game uses its own assets to implement the menu: graphics, backgrounds, fonts and sounds. Dozens of bespoke UI implementations, all to provide the same functionality. Some games add extra features, like exposing a little extra data or letting you switch between controllers. Some games have separate menus available after their normal startup; Rare did this, and sometimes those used completely different menus. But as far as I know, if a game used memory cards, you could hold Start at boot time to manage them.
It’s just another oddity with what, in retrospect, has become one of Nintendo’s oddest consoles. More information on N64 controller pak management menus can be found at consolemods.org. Information on N64 controller paks themselves is at ultra64.ca, which includes Nintendo’s policies on what cartridges should do to facilitate N64 memory cards.
Gauntlet is one of the best games that Atari Games made, and is certainly one of the best known, but it’s interesting how little even people who played it know about it.
Gauntlet has 100 levels, although seven of them take the form of an in-game tutorial. The first level has three exits; one if market EXIT TO 4 and another EXIT TO 8. EXIT TO FOUR skips the player forward a bit, and EXIT TO 8 leaves the training levels entirely. This is how Atari Games’ standard difficulty selection is implemented in Gauntlet, the first levels introduce various game concepts gradually: Ghosts & Generators, Grunts, Demons, Lobbers, Deaths, and Sorcerers get their own spotlights.
Starting with Level 8 though, the remaining 93 levels are part of a great loop. Players will notice that the difficulty increases greatly with Level 8. Which level is 8 actually varies between plays. Gauntlet lasts forever, there is no ending level and the loop never ends. When the last player in the game runs out of health, the machine remembers which level in the loop the game ended on. The next game begins at the start of the tutorial levels again, and when that game reaches Level 8, it’ll be the map that the previous game ended on. (More information on arcade Gauntlet can be found in FalkentyneDragon’s classic infosheet on GameFAQs.)
More than that, the game is known to remove food from levels, depending on how many players are in the game (fewer players means less food), player scores, which characters are being played and how many credits have been inserted during the current game.
Later revisions of the game put the screws on more tightly to try to prevent marathon games. Despite this, very good players can play indefinitely with certain characters. In this ten hour Youtube video, mackey_special plays continuously with Elf through 474 levels.
If you want to find out more, watch the video. They have videos for all four characters on their channel, here.
Note: I am not sure this is arcade Gauntlet. It’s possible that it’s the Japanese Mega Drive version. The Arcade Mode of Genesis/Mega Drive versions of Gauntlet (known as Gauntlet IV in some territories) looks and plays very similarly to the arcade version.
We’ve linked to Iftkyro’s work before here, he created the mystifying (if you know much about how the C64’s video hardware works) demo Nine, where a system that should only be able to move eight sprites around appeared to display nine. How was that done? As it turns out, with great difficulty, and not a little sleight-of-hand!
Iftkyro’s back with another impossible demo, Quondam Tunneling (4½ minutes, download), which appears to display an animated sequence progressing down a 3D tunnel.
In brief, the tunnel itself only has four frames of animation. The demo keeps multiple fonts throughout most of memory, which are flipped between every eight scan lines, that basically allows it to display arbitrary graphics with each character row. The C64 doesn’t have quite enough memory to do that with all the rows in the full vertical extent of the animation, so another trick is used, taking advantage of palette swapping and the C64’s multicolor mode to store two different possible rows in each font. The horizontal scrolling is done by moving the characters that make up each row left and right in a typical C64 scrolling way; vertical scrolling is done by adjusting which fonts are used as the raster line descends the screen.
Of course nowadays we have computers that can display largely arbitrary graphics throughout the whole screen. Processor power is great enough now that we can even do this in software, but additional to that most desktop hardware has powerful hardware graphics included. Even if you don’t have a bespoke graphics card, major processors from Intel and AMD include substantial graphics capabilities built into the CPU. Such is the power of these chips, it’s easy to forget how difficult these things were in the microcomputer era.
Essentially all of the consumer computers from the C64’s era, and many years before and after it, split the system up into two major parts, the CPU and the graphics hardware. The very earliest home computers, like the Altair and the KIM-1, didn’t have graphics hardware at all without substantial hacks, because they weren’t intended to display their output on a video screen. That was really the innovation that opened computing up to the masses. Until monitor or TV output was possible, home computers were basically little more than glorified calculators to most people.
Having the CPU and graphics chips interact with each other was one of the most difficult parts of the design of these machines. Consoles like the Famicom/NES could give each of these two parts what amounted to its own memory, which simplified system design and helped to make possible its graphics power, but it also meant that programming it was more difficult. You can see this in the glitchiness of some early NES hardware (like in Displaced Gamers’ recent video on the jack of NES Commando, as linked here).
To properly use the NES’s PPU, graphics changes could only be made at a certain time each frame, during “VBLANK,” a time when the PPU wasn’t actively drawing the picture. That limited what changes could be made each frame. There were some tricky ways around this, but they all involved adding extra hardware onto the cartridge, increasing manufacturing costs. Home computers used their tilemaps for text display, meaning tile changes had to be less restricted of timing.
This meant some weird compromises were needed. On the C64, the CPU and the VIC-II operated asynchronously, opening up the potential for bus conflicts if they both tried to access memory at the same time. The VIC-II actually has the ability to put the CPU to sleep when it needs access. The C64’s designers rated the consistency of the video signal as a more important priority than the chip’s processor itself.
Even if the graphics hardware could display arbitrary bitmapped images, manipulating them quickly was difficult. The C64’s bitmap screen takes up 8K of memory. At 1 megahertz, the 6510 doesn’t have nearly enough time to update every byte in one video frame. In the following generation of machines, the Amiga was a lot more capable, but through the use of specialized hardware, its copper with its flexible video modes, and its blitter which could move memory around more rapidly.
That explains why, as Iftkyro states, that Amiga demos can generally do this kind of tunnel effect, but the Commodore 64 requires using a very specific memory layout, and rapid switching between fonts and graphics banks, to do something that superficially resembles it.
Sundry Sunday is our weekly feature of fun gaming culture finds and videos, from across the years and even decades.
I’ve posted TerminalMontage’s “Something About” series of satirical game animation videos before. The Fruitless Quests of Nabiu (8 item playlist) is another thing from them, but unlike those it doesn’t refer to any specific game. It just uses the tropes of various JRPGs in its animation and storytelling. This allows it to be much more accessible to non-game playing viewers, and I think it also makes it much better at storytelling. I quite like this new direction they’re going in, and recommend them! Please take a look.
The “main” episodes are much longer and tell a continuing story. Note that most of the dialogue in these animations are presented in JRPG-style text boxes. I don’t mind it myself, but I have heard a couple people express annoyance at the chattering noises they make as they speak. Please try to bear with them.
Episode 1 (21m) introduces Karoto the bard, and sets up what Nabiu, an intern “M.A.G.E.” working for Wizzro the Wizard, is doing, searching for a lost magical chair:
Episode 2 (20m, the most recent to date) continues the duo’s quest, where they encounter a very strange town, and are also joined by Brolly the Knight:
Displaced Gamers’ Behind the Code series is back, with an under-the-hood look at another NES Capcom game, following their examinations of Ghosts & Goblins and Strider, links are to our previous pointers to their peerless product.
G&G was implemented by popular early NES anonymous developer and target of player recrimination Micronics, but Commando can’t use them as an excuse, as it was developed in-house at Capcom. They were still learning the ropes of the NES at the time (Strider has no such excuse), and it shows. Displaced Gamers thinks that the game was shipped while the programmers were still working on optimizing it. As they do sometimes, DG implemented their own optimizations, improving the game substantially. You can see the product of their work in a 31-minute video they made about it, here. There is a substantial amount of 6502 assembly code involved, but if you skip around I think you might be able to get the gist of why the glitches happen, and how Displaced Gamers fixes them.
As was often the case with your jankier NES games, the scroll stutters and character chaos were caused by the game failing to make its VBLANK timing targets. Thing is, despite the glitches, NES Commando is arguably the best version of the game! Characters sometimes disappear from the screen and backgrounds turn into garbage, but there’s so many cool secrets and things to find in it that I can forgive Capcom for it.
Note that Displaced Gamers doesn’t release patches with their fixes, preferring to focus on making videos. Their code is presented on-screen though, so it’s possible for others to insert the changed programming on their own. I hope someone does this soon, as a fixed version of NES Commando would be nice to play.
Last night at our weekly movie watch group we saw Tilt (1979), one of those fad exploitation movies that Hollywood used to make, about pinball hustling, and with a surprisingly sweet ending, which felt earned because the first half of the movie is pretty sleezy, with an aspiring musician getting the money to make a demo tape by exploiting the pinball talents of a young girl, played by Brooke Shields, who’s got a crush on him. Tilt, BTW, has a prop pinball machine called Cosmic Venus as the centerpiece of the last third of the film, which judging by its art is set on a planet mostly dedicated to stripping.
The backglass to Cosmic Venus (from pinside.com), with typical bikini-wearing pinball centerpiece woman . Stay classy, Koala.
Anyway, that got me thinking about something to show after it, something from the world of real pinball. And I happened upon a promo tape that Bally made to promote the then-upcoming release of The Addams Family, which would go on to become the best-selling pinball machine of all time, with over 20,000 thousand tables sold. Meaning, if you’re going to learn to play any pinball table, Addams Family is still the one you’re the most likely to find out in the wild (although newer machines like Godzilla or Batman ’66 are also good bets).
When that was made, they didn’t know that, after designer Pat Lawlor’s earlier hits Earthshaker, Whirlwind and Funhouse, that his next game would become the greatest of all time.
Addams Family is a little simple compared to the games that would follow it, and especially the games released now by companies like Stern and Jersey Jack, but I think that adds to its appeal. It’s the perfect middle ground between the games that came before it, which were mostly about trying to achieve multiball as many times as possible, and current tables that devalue multiball, and push players towards very long games and wizard modes to get good scores.
AF has a wizard mode, Tour The Mansion, which you get by earning all 12 mansion rooms, but it also has a very lucrative multiball, and it’s the player’s choice if they want to focus on one, the other, or a combination of both. The Youtube channel of tournament organization PAPA has an excellent tutorial and demonstration of high level strategy and gameplay. (21 minutes)
Via Kottke on Mastodon.* Alex Harri wrote an image-to-ASCII renderer that can translate generated 3D models in realtime, and on this page they explain how it works and some of the finer points of that conversion, specifically how not to make the rendered images seem blurry, instead giving edges clean outlines. It’s worth a look even if you’re not a programmer, and just want to see how the process is done. While it does descend into pretty heavy math later on, it starts out pretty approachable, and has interactive demonstrations throughout.
Render captured from the interactive toy on the linked site.
* Bluesky has a lot more users, but Mastodon is used by a good number of highly interested and knowledgeable people, especially people who care about the health of the web, although that’s also because I follow a lot of people like that on Mastodon. Overall I find it a good idea to read both.
These days writing a command-line OS for 8-bit or 16-bit era computers is almost an old trick, but GNO/ME (any relation to GNOME is purely accidental) has the difference of both having Unix-like features like signals, pipes and multitasking, while also having been written back in the day, in the 90s. Author Jawald Bazyar shows it off here (26 minutes):
The story also includes a story of the author’s teenage dialup exploration, and stumbling upon a Unix system without a password on its root account, and other such young computing adventures.
GNO/ME can be obtained, for running in an emulator or on bare metal, here, if that’s your idea of a good time.
For this perceptive podcast, the YouTube channel Indie Enjoyer reached out to want to chat about covering indie games, and what it’s like to be a Youtuber today who enjoys talking about smaller and underrated games.
