Battle Master

Battle Master aka Battlemaster is a fantasy RPG emphasizing realtime combat between squad-sized armies and played from an overhead perspective. It was created in 1990 by long-defunct British developer Mirrorsoft, originally for PC systems and later ported to Sega Megadrive/Genesis, with its PC-ish interface intact.

Before there was Fallout and Diablo and Baldur's Gate, there were games like Battle Master. It's not a good game. It's ugly, the AI is horrible, and the lag is insane. The cover is badass though.

No, I didn't get the free poster.

I was introduced to it a long time ago by an older friend named Zach, who later gave me his collection. Zach didn't exactly have the best taste in video games. They included Might and Magic 2, The Immortal, and Sword of Sodan, the last of which I think is the worst of all the hundreds of games I've played. (Incidentally all of those are Western PC to console ports.) I suppose Zach wasn't being generous so much as cleaning house.

When you write a guide for an obscure game, you can expect a trickle of desperate feedback over the years. Players who need help have nowhere to turn but you, since there isn't any other source of info out there. The latter part of Battle Master gets really hard and it's unclear what you are supposed to do to survive.

Incited by an email inquiry last month, I embarked on the questionable task of renovating a gamefaqs guide, originally from 2004. Gens-rr has a trace function that reveals every instruction that the CPU performs, and Lua functions that can be triggered by specific memory or instruction addresses. The trace dumps are similar the output of MAME's debugger, which I've been using to study hitboxes. I applied my new debugging ability to studying the differences between the weapon and armor types, finding out what the mysterious rings and jewelry do, and deriving the formulas for damage and chance-to-hit.

So, I gradually broke the game down and revealed its secrets. It may seem easy with these powerful tools, but it ain't. Trace dumps really dump every little thing. It's too much information, in too cryptic a format, and too time-consuming to decipher, to make any sense unless you know what to look for. Getting useful conclusions requires an careful mix of intuition (devising theories) and empiricism (testing them). And before you can get anywhere, you need to decide what game events and parts of memory to examine. That requires probing with memsearch to find relevant addresses, which itself requires experimentation.

Besides the trace dumps, the main tool of research was a Lua script developed for the purpose. Gens has a cheat code system but it's cumbersome to add and edit codes. It's easier to use Lua to poke and force memory values, though this is nothing new after dealing with FBA-rr. So this was useful for things like stage select and preventing enemy hostility. Gens also lacks a memory browser, and memwatch is unsuited for viewing more than a few bytes at a time. One of the first tasks was to make Lua read memory from specified addresses and graffiti the results onto the screen. Ugly and inconvenient but I didn't know how else to deal with it. The resulting tables helped me see the function of memory addresses more easily.

Having figured out what some addresses were for, I developed a particular Lua function to help crack the combat system. I wasn't sure about all the factors contributing to damage in combat, but I knew from the traces that there are certain parts of the game code that get executed whenever an attack is underway. I used emulua's memory.registerexec() to call functions whenever these instructions were run. The functions load certain memory registers and use the numbers to predict what the damage ought to be according to my suspicions at the time. When they started printing out figures that matched the actual damage, I knew my theories were correct.

A further development was a HUD drawn with gui.text() that, besides giving basic quantities like HP and equipment types, predicts the modifier that will be applied to the base damage on any given enemy. Another HUD function draws the base damage over any active attack.

The most enigmatic thing was the function of those rings and jewels. They seem important, but whatever they do, they do it passively. And I couldn't figure out with memwatch what picking them up and dropping them actually changed. It turns out they don't set any flags, but the code checks all the items in inventory individually whenever they might be used, which is every frame. (The game isn't very efficiently programmed.) By effectively putting a watchpoint with memory.registerread() on their "plus" values I was able to determine at least when their power was checked, and from there determine their uses in combat.

Another function, bound to a Lua hotkey, examines all the enemy groups in a stage and outputs a summary that can be copypasted into the guide, which must be plain text. It also tabulates all the treasures available in the stage and their locations, eliminating any uncertainty there.

Some findings:

The first chapter is called "The Southlands". There's no way to determine that without cheats.
Damage and hit chance depend strongly on the weapon/armor matchup of the attacker and defender.
Armor power can't reduce damage but armor type can.
Rings and jewels work by reducing the chance to get hit, and most of them are effectively worthless.
Some equipment types are unavailable to the player but are used by enemies, and some are completely absent.
The hit chance depends in part on the matchup between the attacker and defender's army formations.

So, with this info and that Lua script (I added a routine that eliminates most of the lag), the game is as playable as it's going to get. If I had written this twenty years ago I'd print the guides up and sell them for $9.95 apiece.

And I'd sell, like, a dozen of them. More importantly I had a shot at the Gens tracer, which turns out to be pretty similar to the MAME tracer.