CRPG Combat & What a Combat Round Means

Never let it be said that I’m not alert to the benefits of reusing work.

I was just watching the beginning of Video Games 101’s first video, of four, of Final Fantasy IV née II, which was such a substantial jump over the first Final Fantasy that it instantly gained a bunch of admirers back then, including myself. It came out early in the SNES’ lifespan too, and I’d say it was instrumental to getting players interested in the system. Of course, it only seemed like such a great jump because Japanese Final Fantasy games II and III never made it to the US, and back then were barely even heard of at the time.

Around the 19 minute mark in the video (which I’m not embedding because it’s not actually the subject of this post), Professor Brigands mentioned how much better it was that FFIV, unlike the first game, didn’t adhere to a convention of earlier C/JRPGs: if a character tries to attack a monster that an earlier character to act has targeted and defeated, then that character’s turn is wasted. In FFIV and most games to follow, the character will instead pick another random opponent. FFIV marked a change in behavior for CRPGs in this, and it’s rare that you’ll find a later game where characters will waste turns like this.

I happen to know the justification behind those wasted turns, and in fact I think the change was for the worse, and being of an argumentative mood I made a comment on the video explaining it. That is what follows (edited slightly) below.

Combat in FFIV. Image from retroachievements.

Brigands called this ridiculous, and most people would agree with him, but I don’t. RPGs have, for a long time, decreased the function of actual strategy over time. This isn’t true just of turn-based games or JRPGs, but in general. They keep getting easier and simpler.

Losing a turn is, against most opponents, a really minor penalty anyway. It’s an incentive to spread out your attacks against weak foes, allowing the player to conserve a small amount of HP (from potential attacks from other monsters) through the use of good tactics, and it means you can’t just completely turn off your brain even against groups of the weakest foes. If you just pound the A button, you risk giving the other monsters free hits against you. It increases player engagement, not by a huge amount, granted, but by a smidge.

Before FFIV, most games applied this turn-wasting concept. So, why did so many games do this?

In some of the earliest days of RPGs, those of 1st Dungeons & Dragons*, a combat round was intended to be a full minute of time. This was explained in that attacks were intended to actually a sequence of combat moves: thrusts, slashes, feints, dodges and the like, that were elided in play in terms of just getting to the numerical effect of those actions.

That’s why fighters in those games could gain extra attacks per round: it wasn’t that they got more swings, but that they were more efficient in their actions, and could get in more telling blows. This is also why Armor Class doesn’t reduce damage, but instead decreases the enemy chance to hit. Damage came from the accumulation of telling blows.

And HP loss itself was also an abstraction, not entirely being directly hurt, but more like scratches, welts, getting worn out, the results of pressing your luck a bit too far, and then actual wounds. If staging an attack against a monster takes a full minute, it makes more sense that one character killing it would cause a following attack that turn to be wasted. In 1E D&D, players had to declare their actions at the start of a round before anyone acted, and the DM was also expected to record each monster’s plans at the start of the round and follow through with them when their turn came.

The page in question

The justification for all of this can be found on page 61 of the 1st edition Dungeons & Dragons DM’s Guide. Now I mention this not to say if it’s good or bad. It’s obvious that current-day D&D doesn’t adhere to this mental model of combat, probably because most players themselves didn’t understand Gary Gygax’s theory of play, but also because it made the game more complicated if everyone had to plan their actions ahead, at the start of each round.

But it does mean that video games from that era did tend to adopt those concepts. The original Final Fantasy is known to have copied many things from D&D, including many of its monsters, and other ideas too, and this seems to have been one of them. I mention all of this just to shed some light on why the original FF did this, and also that, in this one area, it makes the game slightly less thoughtful.

* This wasn’t actually true of the very earliest days of Original D&D, or OD&D, for it didn’t actually have a set combat system at all! Players were intended to use Chainmail, a previous system of medieval combat, to simulate battle. The system that we would recognize as the root of current-day D&D’s combat began in Greyhawk, OD&D’s first supplement.

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.