Tuesday, April 1, 2014

Adding Mooks To Gold Box Games

I'm a strong believer in the thematic usefulness of an unbalanced adventuring party in RPGs. That is, I think every party should have both junior members (Merry and Pippin) and senior members (Aragorn and Gandalf) with substantial power differentials. This is contrary to the design of most modern games (tabletop or computer), but it solves a range of design problems:
  • It provides some weaker characters who need to be protected by the stronger ones, which feels heroic (or if that's not your style, a group of hapless meatshields you can sacrifice to escape, which feels ruthless!)
  • It helps to differentiate characters from one another by seniority, to give them more personality
  • It contributes to verisimilitude in the sense that it's how any real-world teams would work, with weaker and stronger contributors
  • Most importantly, it provides weaker characters who can be injured or die to create a sense of genuine peril and malice, but without risking a total party kill situation
The old Gold Box game Pool of Radiance was unique in allowing you to add low level generic henchman to your party who would actually fight for you (unlike the ones in the Might and Magic series). But later games in the series removed this option. I'm convinced that it's still there hiding somewhere in the code, though. Let's try to use a hex editor to find it! Then we can create custom mooks for the other Gold Box games. This is a critical element of my new project to create a hybrid tabletop/electronic RPG option to allow solo play in my own campaign, so that characters can be moved back and forth into CRPG modules to have their adventures.

I'm using the Gold Box Companion, a nice freeware hex editor by Jhirvonen. It's pretty experimental in that no one really knows much about the internal memory allocation structure of these old games, but with a little experimentation it's usually possible to spot some effects. The GBC has already located (and provided a nice front-end interface for) the bytes that control things like stats, levels, spells, and saving throws. I think I can use this interface to totally overwrite the usual classes and define my own class advancement tables for experience, levels, spell slot availability, thief skills, and throws, so I can implement some custom classes that will be leveled "by hand". (Alas, the spells themselves are hardcoded.)

But we need to find something totally unknown-- the location of the bytes that define hired henchmen, and distinguish them from player characters. The only one actually labeled in the interface is the AI switch, which is near the end of the memory block and controls whether a character is under human control or uses "quickfight" instead.

Let's open a saved game and inspect the characters. First, use the checkboxes in the lower left to screen out all known bytes of data, and also anything boring set to "00". Here's the the array of bytes:

After comparing the memory dump of some PCs and NPCs, there are three sequences that stand out:

The two sequences in red and the third one in blue are always present for every hireling, but never present for any player character. One of them must be it!

The block in blue is clearly controlling the treasure shares claimed by the NPCs after combat ("Warrior takes and hides his shares"). In this example, we can see that the code "5A" tells us that the character will claim a choice of magical items (greedy!) and also a full 5 shares of treasure! If we wanted to make him less greedy, we could change the 5A to a 23 (no magical items claimed), and reduce the shares to 01.

The block in red starts with a "04", which is actually present for player characters as well. It's always equal to the level of the character (the highest level, for multiclass characters). The "FF" bytes don't seem to do anything but might be special flags for some game events, perhaps telling when characters will be removed from the party by certain plot twists.

The most important place to look is that "A5" in the lower line. It determines what type of hireling or NPC you have in your party. In this case, it's identifying this as a "curate" NPC, a fourth-level priest. It seems to be shared by all NPCs that behave the same way, so I think it's specific to an AI behavior pattern or scripting response. Whatever it is, setting it to anything but "00" will tell your computer this character is a mook.

To test this, take one of your regular characters (where this block is "00") and change it to "A5" or anything else. Now you don't have a party of 5 PCs, but a party of 4 PCs and a mook! So you can add another PC to your party! This effectively allows your party to break the six character cap on PCs. You can even change the flag back to "00" when you're done adding more PCs, and run with an oversized group of eight player characters instead. Or you can demote this character permanently to an NPC by setting all the other flags (the "FF" and treasure ones) and turning on the AI switch. Your choice.

Does this code still exist in other Gold Box series games? I haven't found it in all of them yet, but here's where you can find it in the sequel, Curse of the Azure Bonds. Below I'm zooming the new location in the (slightly larger) Azure Bonds memory block:

You can see that the "max-level indicator" of "06" in the top line has been shifted over by one column to make room for something new, but the bottom row is still the same format and now has a "B2" in it. This is the code for the two plot NPCs, Alias and Dragonbait. But I think you could easily change it to anything else, if you wanted to avoid having your hirelings removed from the party by plot events. (Or maybe the "4D" is controlling that, I'm not sure.) The important thing is that it be non-zero, I think, so the game knows this is not a player character. Unfortunately, I have no idea if the "treasure shares" code is still present, or where its storage bytes are located. But maybe by this level, surviving henchmen have become more loyal!

I haven't checked this to see if this ad hoc editing causes any additional weirdness during play; if it does, I'll update the post. For now, it looks like I can continue using henchmen in Azure Bonds, and maybe other sequels as well.

No comments:

Post a Comment