English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 15 November 2012, 04:36   #1
Jonathan Drain
YARDS NEED MORE BYTANIUM
 
Join Date: Sep 2009
Location: Sector K240
Posts: 338
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?
Jonathan Drain is offline  
AdSense AdSense  
Old 15 November 2012, 05:51   #2
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 280
Quote:
Originally Posted by Jonathan Drain View Post
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.
copse is offline  
Old 15 November 2012, 23:33   #3
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 38
Posts: 1,917
Quote:
Originally Posted by Jonathan Drain View Post
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?

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

Last edited by Lonewolf10; 15 November 2012 at 23:43.
Lonewolf10 is offline  
Old 16 November 2012, 08:05   #4
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 154
Quote:
Originally Posted by Jonathan Drain View Post
Are there any tricks to finding game rules in the game code?
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
AnimaInCorpore is offline  
Old 16 November 2012, 08:17   #5
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 280
Quote:
Originally Posted by AnimaInCorpore View Post
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.
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.
copse is offline  
Old 16 November 2012, 11:28   #6
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 154
Quote:
Originally Posted by copse View Post
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 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:
Code:
...
L_0003200A:
    move.w  %D0,WORD_00041424.l                     | 0x0003200A 33C0 0004 1424           |
    move.w  #0x0,-(%A7)                             | 0x00032010 3F3C 0000                |
    move.l  %A0,-(%A7)                              | 0x00032014 2F08                     |
    dc.w    0xFF3D                                  | 0x00032016 FF3D                     | _OPEN

    addq.l  #0x6,%A7                                | 0x00032018 5C8F                     |
    tst.l   %D0                                     | 0x0003201A 4A80                     |
    bmi.s   LOAD_FILE                              | 0x0003201C 6BC2                     |

    move.w  %D0,FILE_HANDLE.l                     | 0x0003201E 33C0 0004 1422           |

    move.w  WORD_00041424.l,%D0                     | 0x00032024 3039 0004 1424           |
    beq.w   L_00031DB8                              | 0x0003202A 6700 FD8C                |

    subq.w  #0x1,%D0                                | 0x0003202E 5340                     |
    beq.w   L_00031DE6                              | 0x00032030 6700 FDB4                |

    subq.w  #0x1,%D0                                | 0x00032034 5340                     |
    beq.w   L_00031E3A                              | 0x00032036 6700 FE02                |

    bra.w   L_00031E74                              | 0x0003203A 6000 FE38                |

L_0003203E:
    move.w  FILE_HANDLE.l,-(%A7)                  | 0x0003203E 3F39 0004 1422
    dc.w    0xFF3E                                  | 0x00032044 FF3E                     | _CLOSE
...
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
AnimaInCorpore is offline  
Old 16 November 2012, 21:49   #7
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 280
Quote:
Originally Posted by AnimaInCorpore View Post
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.
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.
copse is offline  
Old 16 November 2012, 22:08   #8
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 280
Quote:
Originally Posted by Jonathan Drain View Post
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?
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.
copse is offline  
Old 16 November 2012, 23:00   #9
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 154
Quote:
Originally Posted by copse View Post
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.
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
AnimaInCorpore is offline  
Old 17 November 2012, 06:02   #10
Jonathan Drain
YARDS NEED MORE BYTANIUM
 
Join Date: Sep 2009
Location: Sector K240
Posts: 338
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!
Jonathan Drain is offline  
Old 17 November 2012, 06:43   #11
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 280
Quote:
Originally Posted by Jonathan Drain View Post
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.
copse is offline  
Old 18 November 2012, 22:10   #12
Jonathan Drain
YARDS NEED MORE BYTANIUM
 
Join Date: Sep 2009
Location: Sector K240
Posts: 338
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.
Jonathan Drain is offline  
Old 19 November 2012, 08:23   #13
Minuous
Coder/webmaster/gamer
Minuous's Avatar
 
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 1,658
Quote:
Originally Posted by AnimaInCorpore View Post
The disassembler can, however, be configured to produce different styles.
What about CALM (Common Assembly Language for Microprocessors) notation?
Minuous is offline  
Old 20 November 2012, 01:42   #14
copse
Registered User
 
Join Date: Jul 2009
Location: Lala Land
Posts: 280
Quote:
Originally Posted by Minuous View Post
What about CALM (Common Assembly Language for Microprocessors) notation?
Out of curiosity, why would anyone support this?
copse is offline  
Old 20 November 2012, 03:24   #15
Minuous
Coder/webmaster/gamer
Minuous's Avatar
 
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 1,658
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/

Last edited by Minuous; 20 November 2012 at 08:59.
Minuous is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Games which defy logic!! (any platform) Paul_s Nostalgia & memories 181 17 March 2016 23:02
Disassembling resource copse Coders. General 1 02 April 2012 04:36
Disassembling and reassembling absence Coders. General 7 22 September 2009 16:30
Disassembling games for fun crabfists Coders. General 69 29 October 2008 12:20
A Space Game? FIND and get a GAME [Found: Moon City] Dr. Dude Looking for a game name ? 69 22 April 2007 22:01

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 23:44.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.26065 seconds with 12 queries