What is a Jagen?

Let’s jump right to the subject. A “Jagen” is a type of character in Fire Emblem games, named after a character from the very first game. Here is ActualLizard’s video on the subject (19 minutes), which has a lot of interesting things to say about strategy.

Jagens are characters, often given to you in the early game, sometimes available even from the very first battle. They have high stats for the early game, and are often already promoted, of the advanced classes that your other troops will have to use a special item to obtain. Jagens often have little to fear from the enemy hordes, at least in the early game.

Jagens are very useful characters, but are kind of a trap. They’re already promoted so they get few experience points from battling lesser foes, and when they do gain a level, they tend to have very low growth rates in their stats. If you over-rely on Jagens, your other characters will be underleveled, and eventually a Jagen’s slow stat gains will cause it to be unable to keep up with the increasing power of the enemies in the advanced levels. That doesn’t mean they shouldn’t be used at all, but they’re best purpose is to take the edge off of the difficulty curve and supporting your other troops. Since the original Jagen was a mentor figure to Marth and his allies, it’s an excellent case of the game’s story mirroring its design: Jagen’s days of glory are past, his true purpose to help shield and guide the next generation into becoming the best fighters they can be.But! Each game is different, and not all early game powerhouses neatly fit into the Jagen archtype. Some such characters don’t actually stay competitive for long at all, while others (like the awesome Titania in Path of Radiance ) have a strong chance of being useful for the entire game.

You should know a few things about how Fire Emblem’s character growth works. Every character has a number of stats: HP, Strength, Speed, Defense, things like that. The Fire Emblem series is defined, in terms of combat design, by its slow character growth. Every time a character gains an experience level, it only has a chance of gaining a single point in each stat. This chance is preset for each character, and gives everyone a tendency towards certain destination stats, an average spread throughout its 40 potential experience levels. What its actual stats will become will be different each game, depending on what that character rolls upon growth. While many characters have a chance of really great stats, whether they’ll achieve them differs on every playthrough. Growth rates affect that likelihood.

Fire Emblem games tend to put characters right on the edge of survival. When you go up against a boss, you may only have a handful of characters who are capable of denting its high armor, or surviving its counterattack. (Remember, in classic Fire Emblem, is a character dies, it’s gone permanently. If you want to keep using the character, you’ll have to go back to the save before the battle!) This makes it possible to get into situations where all of your characters, even if they’re of decent level, aren’t strong enough to safely defeat a boss.

Characters who join at a high level, or pre-promoted, are a solution to this. The story will sometimes hand you a new recruit to help you keep going, in the event that your party’s been betrayed by the RNG. Whether you should keep using them is something that only experience (and multiple playthoughs, or, let’s be honest, FAQs and walkthroughs) will tell you.

The Perils of Social Media for Gamedevs

Christina Pollock of the blog Load-bearing Tomato has an insightful essay about how opinions shared on social media can come to shape, and often ruin, the work of unseasoned (and even well-seasoned) developers, letting the guiding design principles of their work get blown to the winds because of internet randos forming ill-considered opinions about them.

It’s a link to a blog post, what else am I supposed to put in as an image than a screenshot?

It’s related to something I’ve said for a long time: people don’t know what they’ll like. Statistically, your favorite game probably lies out there, miles away from your field of view, and you may well never hear of it before it (or you) expires. But beyond that, the way punchy memes and quickly-thought opinions on social media snowball can rapidly turn someone’s casual observance into obvious truth results in games slowly being ruined, over successive updates, into a bland design paste.

Take for instance Navi from Ocarina of Time, and how some decided that her occasional annoying cries of “Hey! Listen!” made her a nearly game-ruining feature. Her annoyingness was even referenced on The Powerpuff Girls (video, 40 seconds) at one point.

What kind of post would it be without an embedded video?

Sometimes the crowd has good points, yes. But also sometimes they turn molehills into mountains. Taken too far this line of thinking can turn into Always Trust The Dev, which can also be false. The answer, as it is with many things, is it’s complicated. Turn to Pollock’s article for a lot of examples of how it’s complicated.

An Indie Game For Everybody

The weekly indie game showcases highlight the many games we check out on the channel. (JH: That would be Game Wisdom, please consider dropping by there!) Please reach out if you would like to submit a game for a future one. All games shown are either press keys, demos, or games from my own collection.

00:00 Intro
00:14 Mech Shuffle
2:06 Karate Survivor
3:51 Neva
5:36 Anomaly Collapse
7:48 Feed the Deep
9:56 Phantom Spark

NES Games & State Machines

A couple of years ago gamedev channel NesHacker did a video on how everything in your typical NES game is really a pile of state machines, concurrent ones, nested ones, bunches and bunches of them. If you have any interest in NES coding at all, it’s worth a look. (8½ minutes)

The chief difference between normal, sequential programming and game programming is that most video games have to make a framerate target, and have to split their processes between frames. Lots of little things are usually happening concurrently, and you can’t rely on normal program flow to keep track of things. Instead, each of those little processes has to remember what it’s doing between frames, and that memory takes the form of state machines, reminders of what each routine is in the middle of doing.

Drawing it out with circles like in this video I think makes it seem a bit more complicated than it actually is, but it does require a different way of thinking about your code than you may be used to in other programming disciplines.

Sundry Sunday: Lego 8-Bit Trip

Sundry Sunday is our weekly feature of fun gaming culture finds and videos, from across the years and even decades.

A bit of an oldie this time, and in more ways than one, a four minute stop motion animation from Rymdreglage made with Lego bricks, from way back in 2009. It’s still great though! By “8-bit,” in this case, they mean specifically the Commodore 64 end of the swimming pool, especially as concerns the game International Karate+. Even though this video is 16 years old, Ryndreglage is still making videos now! Have a look for yourself if you like.

Fighting Games That Cheat

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.

Dominic Tarason’s Huge List of Free PC Games

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.

Secret Controller Pak Maintenance Menus in N64 Games

(EDIT: Fixed misspelling in title argh.)

Why are these a thing? Retro Game Attic takes a look at the secret Controller Pak menus included in many (all?) memory card supporting games for the Nintendo 64. (14 minutes)

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.

10-hour Superplay of Arcade Gauntlet

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.

A Technically Proficient Commodore 64 Demo Explained

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.

He’s now also uploaded a video explaining how it was done (14 minutes):

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: The Fruitless Quests of Nabiu

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.

So far, Jeremy Chinshue has released two main episodes of The Fruitless Quests of Nabiu, and six promo shorts.

The shorts: Potion Practice (44s), Beastiary Update (1m), Wandering Doortal of Rescue (1m), Fatigued Fungi Story (46s), Nabiu Stepped on a Plush Trap (38s, ad for merch) and Nabiu’s Off-Meta TCG Duel Deck (1m)

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: