In need of someone with PERL skills

[Duncan Idaho]

A long time ago I teamed with an old friend of mine, helltoast on neoseeker to see if we could try to decipher the game Yu Gi Oh! Forbidden Memories, given our lack of hacking knowledge we did little progress until we found two interesting things, what was used to draw the game and that the game was apparently written entirely in PERL. So I was wondering if any one here had some knowledge of PERL and if he or she could lend us some time to see if they can unravel the game.

Here is the thread Checking by sheer coincidence I found the tool to hack the games, the file is the WA_MRG.MRG. that seems to contain the data of the cards.

[Pyriel]

Trigger warning for honest assessment.

You guys went about this in the most backwards way you could have. Rather than looking up how to reverse-engineer a PSX game, or actual technical details of the system, you relied on google-fu for file extensions, and Dunning-Krugered your way to the conclusion that the game was coded in Perl on a Macintosh system instead of MS-DOS.

That SYSTEM.CNF file is a required file that the Playstation's rudimentary OS looks for when a CD is loaded. Its entire content is a line that tells the PSX where to find the initial executable for the game, followed by a few other settings. It is assuredly not a MySQL configuration file. A "stack" in this context likely has nothing to do with decks of Yu Gi Oh cards, and instead refers the stack in memory. It's a smallish portion of memory set aside for general use like variables with limited scope and values preserved across function calls.

I sincerely doubt the developers created a Perl interpreter for this game. They would have been daft to roll their own for a game. There's no Perl.org version for the PSX, and I'm certainly not aware of even a hobby, homebrew implementation of one to this day. I'm fairly certain a full-featured interpreter for Perl, even in that era, would have burst the 2 MB of RAM available on the PSX. It's possible that somebody on the Dev team fancied Perl so much that they created something with syntax similar to Perl as a scripting language for the game, but past a few superficial similarities, it probably would have been mostly custom and purpose-built.

I wouldn't say even that last option is likely. Given the space limitations, unless the game is ridiculously simple, it would be a massive waste to have game scripts stored as text. I'm thinking it's more likely you guys saw file paths and debug strings that looked reminiscent of Perl strings and just inferred. What about the game data gave you the idea anyway?

[Duncan Idaho]

Trigger warning for honest assessment.

I have 0 problems with this. We are really n00bs at reverse engineering, and we weren't aware of romhacks back then.

You guys went about this in the most backwards way you could have. Rather than looking up how to reverse-engineer a PSX game, or actual technical details of the system, you relied on google-fu for file extensions, and Dunning-Krugered your way to the conclusion that the game was coded in Perl on a Macintosh system instead of MS-DOS.

Eh i'd have to ask Helltoast what made him conclude that, I don't remember.

That SYSTEM.CNF file is a required file that the Playstation's rudimentary OS looks for when a CD is loaded. Its entire content is a line that tells the PSX where to find the initial executable for the game, followed by a few other settings. It is assuredly not a MySQL configuration file. A "stack" in this context likely has nothing to do with decks of Yu Gi Oh cards, and instead refers the stack in memory. It's a smallish portion of memory set aside for general use like variables with limited scope and values preserved across function calls.

Yeah, the brazil team figured that one, the deck strings are in WA_MRG.mrg which there are now tools for editing, but no one has figured out how the game determines how it loads, I figured that the game loads a set number of drops, but again no idea how it picks the drops to load or to give to the player.

I sincerely doubt the developers created a Perl interpreter for this game. They would have been daft to roll their own for a game. There's no Perl.org version for the PSX, and I'm certainly not aware of even a hobby, homebrew implementation of one to this day. I'm fairly certain a full-featured interpreter for Perl, even in that era, would have burst the 2 MB of RAM available on the PSX. It's possible that somebody on the Dev team fancied Perl so much that they created something with syntax similar to Perl as a scripting language for the game, but past a few superficial similarities, it probably would have been mostly custom and purpose-built.

As I said we had no idea and we are mostly people who simply dug blindly inside the game back then.

I wouldn't say even that last option is likely. Given the space limitations, unless the game is ridiculously simple, it would be a massive waste to have game scripts stored as text. I'm thinking it's more likely you guys saw file paths and debug strings that looked reminiscent of Perl strings and just inferred. What about the game data gave you the idea anyway?

If I recall correctly somehwere in the files we looked using, text editors and the such near the end it had several references to PERL, we assumed there are at least three languages involved, PERL, RUBY and C, but given what you said that its unlikely to be done on perl, It only leaves C or Ruby.

[Pyriel]

Ruby is in the same category as Perl. My understanding of it is that it can be interpreted or compiled to byte-code, with some implementations being capable of creating machine code with a JIT. The latter would make it somewhat more practical as a scripting language for the Playstation (minus the JIT), but there's no PS implementation of which I'm aware. They might have borrowed elements of the syntax for the game's scripting language, but I doubt it. Ruby wasn't particularly mature around the turn of the century, so I'm a bit doubtful that you'd find a team of game developers who were familiar enough with it to want to imitate it.

You have to remember that consoles, especially in this era, are fairly custom pieces of hardware. If you're going to write software for it, you need a library that includes functions for interfacing with the peculiar kernel the console has; interfacing with controllers rather than standard input devices; rendering output for region-specific televisions rather than computer monitors; handling hardware for memory cards, in an era where 3.5" floppies were still the most common form of removable, rewritable storage on PCs generally; communicating with the sound processing unit, which is analogous but not all that similar to a sound card; managing the IPU which handled FMV playback. In order to use Ruby for any of that, you either have to build in the functionality yourself or be able to interface with library code in the SDK from Ruby. Modern Ruby can do that with appropriate extensions installed, but I'm not sure how bulletproof it is, or if it was even available around the time this game would have been developed. Alternatively, you could just hire C programmers and use the SDKs exactly as provided and shave months off your development timeline.

Do you have a specific aspect of the game you want investigated? People here are often willing to help others with their first steps, but it has to be rather narrow. Unless one of the more experience people also enjoys the game, it's unlikely anybody will want to partner up to just unravel it generally. If you're looking to do some sort of translation, or a full-on modification, rather than codes or small tweaks, you might have better luck at romhacking.net.

[Duncan Idaho]

Do you have a specific aspect of the game you want investigated? People here are often willing to help others with their first steps, but it has to be rather narrow. Unless one of the more experience people also enjoys the game, it's unlikely anybody will want to partner up to just unravel it generally. If you're looking to do some sort of translation, or a full-on modification, rather than codes or small tweaks, you might have better luck at romhacking.net.

Yes, I have an aspect I want investigated, how the game selects what cards will give you after a duel and what card will give you, as far as I know the game pre loads a set of cards and itll give you a different one depending on your last turn of actions, but I have no idea what criteria it uses to pick them or to select which card of the set the player will get.

Tweaks can be done with a tool that edits the WA_MRG.mrg file values and there are a few others that edit the MODEL.mrg so I am not after that.

[Helder]

Don't people use debuggers like no$psx or MESS? Find the ram address for the actual card you get then do a break on it then trace back and look at the trace log. Eventually you will likely come to some table (data table) with the card values and if you observe enough you can see what is checking the actions you do to generate the card chosen.

This sounds easy to do but will likely require some time and a little dedication to crack it but I gave you an idea in a way to actually find the info you need so hopefully someone (even yourself) can try this and you might get some results (I have no interest or time to invest in this endeavor in case you were wondering).

[Duncan Idaho]

Don't people use debuggers like no$psx or MESS? Find the ram address for the actual card you get then do a break on it then trace back and look at the trace log. Eventually you will likely come to some table (data table) with the card values and if you observe enough you can see what is checking the actions you do to generate the card chosen.

This sounds easy to do but will likely require some time and a little dedication to crack it but I gave you an idea in a way to actually find the info you need so hopefully someone (even yourself) can try this and you might get some results (I have no interest or time to invest in this endeavor in case you were wondering).

Thanks.

I'll try it soon.