Disassembling games to find out the game logic?
 

A lot of real-time strategy games work on rules that aren't explained in the manual or anywhere, but which are very useful for calculating the most effective strategy. Things like weapon damage, a unit's hit points, or hit/miss chances.

I have trouble spotting game logic in disassembly of the game, because it's usually a very small piece of code (e.g. checking a single integer once in the game loop) and I'm not used to assembly.

Are there any tricks to finding game rules in the game code?

I don't think there's any trick to it. To me it all looks so generic until there's meaningful labels, so I tend to just plug away until it's obvious. It's like peeling away layers on an onion.

Not sure about individual games, but there are alot of tricks in coding that you can only learn from the programmers themselves. I personally hate trying to understand other peoples code (especially disassembled code).

As for the movement AI in RTS games, they basically use the A* pathfinding algorithm or a variation on it. There used to be pages documenting it on www.gamedev.net but I can't find them right now. I have them saved to my laptop, so if you are interested I can .lha the webpages and stick them in the zone.

Edit:

They moved it, it's now here:

http://www.gamedev.net/page/resource...eginners-r2003

A good start is to rename the labels of the source code first as far as you can. This helps a lot at least to separate the parts of the source which are not of interest for you.

This was helpful for me porting PacMania and Galaga 88 from the X68000 to the Atari Falcon.

Cheers
Sascha

What disassembler did you use? While X68000 is not a platform I am really interested in, I am curious whether it correctly identified all the OS calls or just dumped them as dc.w $Fxxx?

I'm currently working on a disassembler, and have added support for X68000 executable files, and it would be helpful to know for to allow for future expansion.

I have written an own M68000 disassembler so that you already get a good readable source to make easy modifications later on. In fact, the main goal wasn't porting X68000 games to the Atari either but this was a good proof of concept of the first step of the idea I have.

Yes, the Line-F calls are indeed only dumped as "dc.w $fxxx" in the source code but detecting its purpose was rather easy since the value is different for each DOS call.

Here's a snippet from Galaga 88:
I think representing Line-A and Line-F with "dc.w $xxxx" is fine since the main purpose is to have your own opcodes for which you would use macros for a better readability.

Cheers
Sascha

Ah, thanks, good to know :)

Is the %A0 register naming an Atari ST style? As far as I recall, we just go vanilla A0 style in Amiga land.

Coming back to this, I think that you have two options.

The currently most feasible tool, is to debug the program and get familiar with the code that way. Ideally you would have a debugger that let you relabel addresses, and basically acted as Resource+debugger. I think that Ollydbg is a PC debugger that lets you do this for PC programs. And IDA for the PC probably does the same, but I haven't used it much. But on the Amiga, I think you are out of luck. I know there was one debugger/disassembler combination for the Amiga, but it never worked for me when I tried it and I have no idea how you would obtain it anyway. I think it would not be that much work to disassemble an Amiga debugger and extend it with the ability to edit label/symbol names, and to allow saving of those and source. Another option is to use the WinUAE debugger, but I've always found using it somewhat inscrutable.

Another option that is not currently possible is to use a disassembler does some of the legwork for you. I don't know about you, but there's a step when I disassemble a program that was linked against a library where I go through and relabel all the routines that make library calls. Then I go through and relabel all the wrapper routines that call the routines that make library calls. And then I go through and relabel all the wrapper routines that call the wrapper routines.. There's an approach that I think is called library fingerprinting - where IDA Pro or some similar solution has a database of signatures for routines that get linked from the static libraries, and can automatically label them. And similarly, instead of you needing to go find all the "move.l 4.w, A6" and set the symbol for the call into exec or whatever, they also proactively detect these OS calls and automatically put the symbols in place and comments on the arguments passed on the stack.

Links:
Signatures for Library Functions in Executable Files (citeseer paper page).
Unstrip signature detection tool.
IDA Pro FLIRT signature detection.

Of course, another approach might be to do try IRA. Getting reassembleable source code, and debugging it in the assembler might be somewhat helpful.

Actually the style is a little awkward but this is accepted by the Human68k and the m68k-atari-mint toolchains as well so I can assemble the same source on both systems. ;)

The disassembler can, however, be configured to produce different styles.

Cheers
Sascha

What I've been doing so far is to disassemble with IRA, then when I work out what a label is for, I find-and-replace the label name with a more descriptive one. Amiga system library calls are easy to spot, and from there you can tell which parts of code probably deal with sound, graphics, disk IO, etc. It's like building a jigsaw by finding the edges and working inward.

Finding an individual line of game logic is like looking for a needle in a haystack. If only I had a magnet!

Is there any reason you don't use resource? The ability to jump around the source code, is quite handy and a lot more than doing it by hand ala ira.

I'm not sure. I think because I couldn't find a full version of ReSource at the time, so I just tried to see what could be done with IRA and the WinUAE debugger. I'm really an asm noob.

What about CALM (Common Assembly Language for Microprocessors) notation?

Out of curiosity, why would anyone support this?

Why wouldn't they? It's a bit pointless having to learn completely new syntax for every different CPU when they all carry out much the same operations, it makes it far easier to read code for unfamiliar CPUs, etc. I really can't think of a single advantage to manufacturer-specific notation (except that you can quickly tell in most cases what CPU the assembly code you are looking at is written for, because of the non-standardization. But generally one would know this in advance anyway).

It's not hard to support, eg. the disassembler subsystem of my emulator supports it for both the supported CPUs (2650 and 6802).

Anyway I won't rehash all the arguments in favour of it, I will just give some links which provide justification and reference:

http://calm.baillifard.com
http://www.pf-soft.ch/ascalm.php?L=E&C=W
http://www.didel.com/calm/