#69807 - JoKyR - Thu Feb 02, 2006 1:28 am
Hello,
I'm obviously very new here. I'm not really trying to break into GBA Development. Instead, my goal is to deconstruct existing GBA ROMs to figure out exactly how they work. For instance, take an inside look into a game like Monster Rancher Advance and figure out things like how the game calculates a monter's lifespan, or what all the items actually do.
I realize this is pretty different than development, because I'm not trying to make my own games. However, of all the forums I've visited, this one seems to have the most similarities to what I'm trying to do.
So, here's where I'm at:
I've been steadily making my way through several online tutorials on various assembly languages.
I have VisualBoy Advance and the ability to make my own ROMs.
Where do I go from here?
If anyone could even give me a nudge in the right direction, I'd be incredibly appreciative.
Thanks in advance!
_________________
-Sincerely,
Joseph Kyle Rogan
http://www.jokyrandjesster.com
#69808 - sajiimori - Thu Feb 02, 2006 1:42 am
That's all, really. Just keep learning about ARM assembler and GBA programming. Use emulators to step through the code, and get ready to encounter a world of frustration as compiled ROMs are not meant to be navigated.
#69825 - quickcup - Thu Feb 02, 2006 5:53 am
What you are describing is a form of reverse engineering, if that helps any.
#69834 - chishm - Thu Feb 02, 2006 7:44 am
You may also want to try arm-elf-objdump. To convert a raw binary to ARM ASM code, try the command:
| Code: |
| arm-elf-objdump -D -b binary -m arm [infile.gba] > [outfile-arm.s] |
To get THUMB code, try:
| Code: |
| arm-elf-objdump -D -b binary -m arm -M force-thumb [infile.gba] > [outfile-thumb.s] |
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#69836 - Dwedit - Thu Feb 02, 2006 8:11 am
| JoKyR wrote: |
Hello,
I'm obviously very new here. I'm not really trying to break into GBA Development. Instead, my goal is to deconstruct existing GBA ROMs to figure out exactly how they work. For instance, take an inside look into a game like Monster Rancher Advance and figure out things like how the game calculates a monter's lifespan, or what all the items actually do.
I realize this is pretty different than development, because I'm not trying to make my own games. However, of all the forums I've visited, this one seems to have the most similarities to what I'm trying to do.
So, here's where I'm at:
I've been steadily making my way through several online tutorials on various assembly languages.
I have VisualBoy Advance and the ability to make my own ROMs.
Where do I go from here?
If anyone could even give me a nudge in the right direction, I'd be incredibly appreciative.
Thanks in advance! |
You'll need to map out the games first. Graphics data is really easy to find, just use a tile viewer program. You can use a corruptor tool to attempt to find other data.
To map out the game's RAM, you'll want a cheat finder to search for the game's variables. When you find the address, you can use a debugger to trap writes to there, then you can look at the ASM code that surrounds the area. You're going to want an emulator with a really good debugger.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#69850 - sgeos - Thu Feb 02, 2006 10:17 am
I think you'd be better off learning standard software developement techniques and reading about what the hardware can do. It doesn't really matter how one particular game gets the job done. There are usually many ways to get the same effect.
-Brendan
#69932 - tepples - Fri Feb 03, 2006 1:19 am
| sgeos wrote: |
| I think you'd be better off learning standard software developement techniques and reading about what the hardware can do. It doesn't really matter how one particular game gets the job done. |
Unless discovering the rules of a particular game is the object. For example, "how the game calculates a monster's lifespan, or what all the items actually do" is not part of interfacing with the hardware; it's part of the business logic.
Anyway, JoKyR: you might want to ask on the ROM hacking boards too.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#70096 - DakeDesu - Sat Feb 04, 2006 8:58 am
yeah, the name for this, as stated above is called reverse engineering.
Generally it is against just able every license out there to reverse engineer something, other than the Free Software based licenses.
I won't lecture you about logistics, just be careful.
_________________
[ Main Site | Kid Radd Fan Project | Forums ]
#70101 - tepples - Sat Feb 04, 2006 9:19 am
| DakeDesu wrote: |
| Generally it is against just able every license out there to reverse engineer something |
Many countries' legal systems refuse to enforce provisions of take-it-or-leave-it contracts that ban reverse engineering.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#70103 - sgeos - Sat Feb 04, 2006 9:37 am
| tepples wrote: |
| Unless discovering the rules of a particular game is the object. For example, "how the game calculates a monster's lifespan, or what all the items actually do" is not part of interfacing with the hardware; it's part of the business logic. |
You don't need to disassemble the ROM to figure out the game logic. Unless you are writing an in depth FAQ, you do not need to know exactly "how the game calculates a monster's lifespan" or how "all the items actually do" what they do. You can figure out more or less how it gets the job done by obseration and then use that information to write or own clone or what not.
-Brendan
#70106 - keldon - Sat Feb 04, 2006 10:18 am
| DakeDesu wrote: |
yeah, the name for this, as stated above is called reverse engineering.
Generally it is against just able every license out there to reverse engineer something, other than the Free Software based licenses.
I won't lecture you about logistics, just be careful. |
The law (in the UK at least) says that permitted acts are: backups, correcting errors decompiling software for format [providing the format is not known]
JoKyR, for what reason do you find it important to reverse engineer commercial games? What are you expecting to happen/learn when you do this?
#70107 - tepples - Sat Feb 04, 2006 10:30 am
| sgeos wrote: |
| Unless you are writing an in depth FAQ, you do not need to know exactly "how the game calculates a monster's lifespan" or how "all the items actually do" what they do. |
Problem is that a lot of people are writing for GameFAQs.
| Quote: |
| You can figure out more or less how it gets the job done by obseration and then use that information to write or own clone or what not. |
That's called the "black box" method of reverse engineering, which is lawful everywhere. But then you run into problems in finding 1. what corner cases exist and 2. what the correct behavior at these corner cases is. These problems are sometimes related to the player's skill level.
Case in point: Scoring in Compile's Puyo Puyo
The score for each step in a chain in Puyo Puyo is displayed as the product of two numbers, which I called ComboValue and ChainValue. ComboValue was easy to figure out: 10 times the number of blocks eliminated in that step times the current speed level. ChainValue, on the other hand, I found more mysterious.
My first explanation, based on my observations
For each combo unit (connected set of eliminated pieces of one color), if the size is 4, set the size to 3 for scoring purposes.
ChainBase equals 1 << (chain length so far - 2) << 3
gives 0, 8, 16, 32, 64 for step 1, 2, 3, 4, 5
Add all combo units' scores for this step in the chain and subtract 3. Then add ChainBase. If the result is 0 (i.e. first step a 4-combo), add 1. Result is ChainValue.
More accurate revelation from a Japanese fan page
Based on machine translation of this page
ChainValue of a step is the sum of three elements: score for step (ChainBase above), score for each combo unit, and score for colors.
Nth step of chain:
0, 8, 16, 32, increasing by 32 thereafter (linear, not exponential)
The score for a combo unit of size N+3: 0, 2, 3, 4, 5, 6, 7, 10, increasing by 0
N different colors within a step:
0, 3, 6, 12, 24
Why I thought my formula was correct
My formula happened to be accurate for for 5 or fewer steps and 3 or fewer combo units, each of size 7 or fewer, all of different colors within a step. I had no idea that the number of colors within a step affected anything. The corner cases where the formula broke down were beyond my skill at first, but after seeing the "correct" formula, I practiced until I could pull off some of the corner cases that the page revealed to me.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#70115 - DakeDesu - Sat Feb 04, 2006 12:23 pm
| tepples wrote: |
| DakeDesu wrote: | | Generally it is against just able every license out there to reverse engineer something |
Many countries' legal systems refuse to enforce provisions of take-it-or-leave-it contracts that ban reverse engineering. |
Depends on how you do it. In Canada part of how a patent becomes public domain is based on reverse engineering. However, this requires somebody making a device that behaves the exact same way as the patented one, without having access to the actual device that is being reversed engineered. Well access to its inner workings anyway.
Because there is already a method to reverse engineer put into the patent system, that does not involve taking the object apart, taking the object appart is frowned on generally in a court of law.
Also keep in mind that Nintendo doesn't keep their lawyers on very short leases.
_________________
[ Main Site | Kid Radd Fan Project | Forums ]
#70462 - JoKyR - Mon Feb 06, 2006 7:01 pm
| keldon wrote: |
JoKyR, for what reason do you find it important to reverse engineer commercial games? What are you expecting to happen/learn when you do this? |
My goals are simply to learn and enjoy the games I reverse engineer more thoroughly. I'm not really planning on cloning the game, writing my own version, or any kind of ROM distribution. This is just a hobby for me.
I mentioned Monster Rancher Advance in my original post because I think it's an excellent example of a game that really needs to be reverse engineered to understand how to play it effectively. Tecmo is notorious for providing incomplete and innaccurate information about the game mechanics of its Monster Rancher series. Plus, the games tend to hide a great deal of variables and information that is extremely difficult to determine through observation. If you take a walk around the internet looking at player written FAQs and Guides for these games, you'll see how much confusion and disagreement there is.
So, if I were to look at the code for the game, and figure out exactly how everything works, I'd be able to play the game more effectively. Knowing exactly what factors go into a monster's lifespan, what affects it, and what calculations are performed would allow me to raise a monster that lives longer.
As a side note, I would probably take the information and write a few Cheat Codes for the game, but this is really only a secondary goal.
I hope that clarifies things. Thank you, everyone, for all the help you've already given me. If anyone has anything more to add, you have my rapt attention.
_________________
-Sincerely,
Joseph Kyle Rogan
http://www.jokyrandjesster.com
#70485 - tepples - Mon Feb 06, 2006 9:25 pm
| JoKyR wrote: |
| So, if I were to look at the code for the game, and figure out exactly how everything works, I'd be able to play the game more effectively. |
So, Brendan, this is for an in-depth FAQ.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.