Wizardry VI & VII Complete - Translation project

While I had already announced this on the Discord server some days ago, I've since reached an important milestone and so I feel this project now deserves its own thread.

I'll be translating VI first by using the official English script found in the original DOS version. Then, depending on how this goes, I'll decide if I want to tackle VII's script too.

First off, this was made possible by the findings made by Gertius for their Wizardry VII PSX translation patch, the source code of which can be found here (I'll publish mine too once I have a patch ready to be released). As the Saturn version employs the same Huffman-encoded text file formats as the DOS and PSX versions, I was able to roll my own Huffman decoder/encoder to reencode the English script with my edits.

Here's a quick rundown of the relevant files:
  • msg6j.dbs -> contains the majority of the game's text (dialogues, descriptions, etc.) encoded with Huffman. The actual decompressed text is Shift-JIS encoded
  • msg6j.hdr -> contains headers referencing the strings in msg6j.dbs by so-called indices (integer numbers)
  • misc6j.hdr -> Huffman table used to encode/decode
  • msgj.dbs, msgj.hdr, miscj.hdr -> Wizardry VII equivalents of the above
  • wiz6.bin -> contains both code and hardcoded strings (in plaintext, fortunately) specific to Wizardry VI (enemies, items, spells, combat log, UI, class information, etc.)
  • wizardry.bin -> more code and strings, shared by both games (character creation)
  • sl.bin -> from what I've gathered, it's a Wizardry VII file analogous to wiz6.bin, but I haven't looked much into it
  • font_1.dbb -> font tiles used for UI and menus only. Does not contain any kanji, only ASCII chars and kanas
  • kanji12.fon -> this one's obvious, but it also contains latin letters used for dialogues. It's encoded in a proprietary format that I still haven't been able to reverse engineer. The only thing I know is that it uses '\' and '/' as separators between groups of glyphs
Now, you'd think that the devs would place all or at least most of the strings used by both games in a common file, but instead they chose to duplicate them and then scatter them throughout the binaries that I mentioned above. Nice.

So, I've mentioned that the Huffman-compressed files of the Saturn port follow the same exact format as their DOS equivalents, so why not try and brutally patch the original English files in, just like that?
If only it were that simple:

Screenshot_20250701_014120.png


This is supposed to be the very first dialogue that plays at the start of the game. Pressing C like 20-30 times will exhaust all invisible text and resume the game. For reference, the actual EN dialogue is made of 6 lines each filling the entire box, which means 6 presses should have been enough.
The reason for this behavior is to be found in the code of the print function. Using Ghidra to decompile it, I've found that almost all ASCII characters are outright ignored, whereas some few special symbols are used for formatting, such as whitespace triggering a line break.
To tell you the truth, I only discovered this about 3 days ago. When I first started this project, I chose the lazy route and actively avoided decompiling the game. I've since changed my mind, but only after trying everything that I could and finally hitting an insurmountable wall.

When I was presented with that blank dialogue box, I simply thought ASCII characters where being ignored or something, so I tried converting all characters to their full-width Shift-JIS equivalents and compressed the text using the JP Huffman table. This is what I got:

Screenshot_20250628_022404.png


This garbled phrase is supposed to appear much later on in the game. I found out by cutting like 80% of the text that this was due to the size of the newly encoded DBS file (166 KB), which was almost double that of the original (84 KB).
I tried to optimize the Huffman table: the one used by the Saturn version understandably encodes latin letters to very long bit sequences, so I grabbed the DOS one and replaced all ASCII characters with their SJIS equivalents, while also associating byte '0x82' to the shortest possible encoding. This strategy saved me about 50 KB and let the game show the actual starting dialogue:

Screenshot_20250628_024553.png


(Btw, the text is all uppercase because that's just how the DOS script is.)

However, the file still being too large meant that, eventually, we'd hit a point in the game where we're again shown the wrong text. For instance, the game showed this instead of "You detect something":

Screenshot_20250628_024839.png


By comparing the EN and JP scripts, I discovered that a *lot* of NPC dialogues were either shortened or cut out entirely. I suspect this was done because, contrary to the DOS version where you ask NPCs specific information by typing relevant topical words, the Saturn version will simply make NPCs say all that they have to say as some kind of weird monologue. Also, as I mentioned before, many strings have been hardcoded into the binaries, specifically, everything with an index smaller than 8179 (save for a couple of strings). With this knowledge, I deleted all unused strings and also many control characters that made sense in the DOS version, but which the Saturn one either ignores or interprets in a different way. With this, I managed to shrink the text file to about 88 KB.

With 4 KB left to shave off and me being short on ideas, I embarked on the excruciatingly boring task of condensing much of the game's flavor text that does not contain any relevant details.
As an example of what I mean, let's look at this string:

Screenshot_20250701_015212.png


... which I condensed to this:

Screenshot_20250630_143021.png


(Don't mind the missing spaces, that's due to how I handle line breaks.)

I recognize that my version sounds drier, but I figured this would be the best approach to save on valuable space without omitting important information. I've also decided not to touch any lines spoken by NPCs, as I know I'm not that good of a writer to properly replicate their style and tone.
And so, after shortening many, *many* strings that I deemed were too verbose, I finally got that file to under 84 KB. Mission accomplished?

I then wondered if the same thing could be feasibly done to the script of Wizardry VII. The original JP encoded file is 224 KB. So I grabbed the English script, deleted all strings with index < 8000, reencoded the text to SJIS using my optimized Huffman table and managed to obtain a humongous 300 KB file. If cutting all that text from VI's script just to save on 4 KB was painful, well, cutting 66 KB from VII's script would be absolute torture.

With this approach clearly not being good enough anymore, I made a dump of the high working RAM while a dialogue box was open, analyzed it with Ghidra and found where the print function was stored.
Here's a very small excerpt of decompiled code:

Screenshot_20250630_145419.png


Basically, relative to the current 16-bit character in the string that the function needs to print, it takes both its high and low bytes and passes them to another function (which I'm going to refer to as "classifier") that returns a number between 0 and 11 defining how that character should be handled. If that number is 0, that means the character is printable, otherwise it could be a control character, a null terminator character or even a printable character that has to be replaced with another (e.g. three dots will be replaced by an ellipsis).
If the classifier receives a pair of ASCII characters as input, it may either decide that they must be ignored (returning 11) or, if one of them is a control character, it returns the appropriate number. Unfortunately, we cannot simply edit this function to make it return 0 with either SJIS or ASCII chars: if a character is deemed printable, the print function will *always* assume it's a 16-bit character and pass it to another function that renders its glyph, then increases the current character index by 2 to parse the next pair of bytes.

Thus, I chose to remove some of the code handling certain control characters (the one that handles ellipsis, one that replaces the current character with a dot, and one that handles the control character '@', which works in a rather weird way and I've never managed to use it properly) to make room for the new code, and then made it so that, before the classifier is called, ASCII letters are converted to SJIS; at the same time, I made sure that the current character index is increased by 1 instead of 2. Otherwise, if the character is already SJIS or it's not an ASCII letter, then the print function handles it like it did previously.

Why am I ignoring numbers and symbols? Well, not all numbers should be subjected to this conversion at runtime, as the game requires to interpret certain strings with ASCII numbers in a very specific way to handle player choices in dialogues, a relic from the DOS version. If a sequence of numbers is actually supposed to be shown to the player, then I simply encode it to SJIS beforehand, and do the same for punctuation marks since there's not much space left to handle them in the print function (well, there is enough to handle dots and commas at least, but it'll be for another time).

With these edits and even without the shortened strings that I had worked on previously, I managed to bring VI's text file down to about 71 KB! I guess all that rewriting work has been for nothing lmao.
As for VII, its text file is now 237 KB! Still 10 KB too large, but I haven't yet compared it to the JP script for cut lines. I can definitely work with this.

While I was at it, I found a way to reduce the absolutely excessive letter spacing, which in turn also increased the maximum number of characters per line from 13 to 17! I think there's potential to add support for VWF, but I'm not sure I wanna deal with that.
Look at this! It's... kinda readable now, at least:

Screenshot_20250630_190347.png


The real issue here though is the atrocious font. Since the relevant glyphs are stored in kanji12.fon, I have no way of editing them at this time. I can, however, make it so that the text gets proper capitalization, as I've seen how the lowercase font looks and it's not too bad.

But then, it happened: while I was messing around in the game and reached the first NPC, I discovered the most maddening bug that would only occur when some (not all) text is encoded to ASCII instead of SJIS. In essence, when entering the room where that NPC is located, I would normally be met with his dialogue located at index 12000, and then, when pressing the "TALK" button, he would start reciting his monologue, which the above screenshot is part of. If the text involving these dialogues is ASCII-encoded instead of SJIS, then the first line that he speaks when entering the room is actually the one at index 12002, and when pressing "TALK", the dialog box does not even show up. I naively tried to put all the text at index 12000 into index 12002 and then also into 19998 and 12001, but then other completely different strings would be shown.

Later, something occurred to me: the line at index 12002, the only one that was shown, began with a SJIS-encoded exclamation mark. That was left over by my encoder because I messed up the code used to trim trailing characters, which in turn made that string the only one containing a SJIS character. With this detail in mind, I made the encoder replace the first character of each string belonging to that NPC to its SJIS equivalent, and that actually fixed the issue!

What did ASCII ever do to Data East to deserve this much hate and contempt?

As for hardcoded strings, there's not much that's worth talking about that you haven't already seen in other translation projects. Having added ASCII support has allowed me to use ASCII characters almost everywhere though, so instances where I have to mess around with pointer tables to carve out extra space are actually pretty rare now. I say 'almost' because some specific strings, like the one that shows up when an encounter begins, use YET ANOTHER print function that shows filled rectangles instead of ASCII characters. However, since such strings are not too frequent, I don't really care to investigate for now.

I guess I can showcase how the combat UI and log look like:

Screenshot_20250701_004152.png
Screenshot_20250701_004103.png
Screenshot_20250701_004245.png


Player choices:

Screenshot_20250701_005029.png


And that's it! I've skimped over many details in an effort to make this post as brief as I could. I will release a patch once I've at least managed to translate the whole of Wizardry VI.

If there are any new notable developments, I'll make sure to post about them.
 
Last edited:
I took a quick look at KANJI12.FON using CrystalTile2 and, if you want, you can modify it without having to write your own graphics tools.

Nothing special. Set width to 16px, height to 12px, and use "solid 1bpp" mode.

At a minimum, I would suggest moving each glyph to the far left of the tile box. Then, reducing the tile spacing with your assembly hack so that each gylph is rendered as close to the next one as possible without touching. Based on the existing font, that would be 11px for Latin glyphs. Of course, you could draw up your own custom font (or borrow one from elsewhere) to go even narrower, if you so desired.

1751893277579.png
 
Huh. I had tried opening that file with CrystalTile before posting, but it would just give me an error no matter what. I guess it simply doesn't work correctly under Linux?

Anyway, thanks for the heads-up! I've actually already managed to edit the glyphs using an hex editor (had to set it to binary mode and to show only two bytes per row), but it's been a pretty miserable experience. I'll have to set up a Windows VM just for CrystalTile, I guess.

Here's how the modified lowercase font looks in action:

Screenshot_20250707_154035.png


The 'm' is still too wide (same thing with the 'w', not shown here), but I haven't yet managed to make it look good with a width of 6 pixels instead of 7, as the part in the middle will then appear to be slightly more to the right or to the left, depending on how you draw it.
 
You're welcome.

In case you find it useful, I whipped together two tools for you to convert to/from the original FON file format and PNG. They're written in Perl and can be used in Linux with nothing except satisfying module requirements via cpan. You probably only need to install the GD module.

Note that png2fon will throw a warning, but you can safely ignore it.
 

Attachments

So, I've been working on something.

First, I'm going to get one thing out of the way, and then proceed with the actual post.

It's gonna be a long read, so TL;DR: this game is unfinished and I'm doing my best to restore its contents.

Translation accuracy

I said in my first post that the plan is to use the DOS script since it's the official English version of the text. If, like me, you were worried that this patch might not do justice to what the Japanese developers envisioned, well, don't be: apart from a different approach to NPC encounters, the Saturn port features a basically 1:1 translation of the DOS script.

Regarding NPCs, the JP localizers have cut various lines of dialogue to make certain conversations shorter and more streamlined (the ones that you'd normally trigger with the "TALK" command), since this port does not provide you with a list of talking points like the PSX version of W7 does. Where I've felt that they cut too much and omitted important lines, I have reinserted those. These "monologues" actually sound pretty disconnected in Japanese, like no effort was put in ensuring that NPCs jump from one topic to the next in a natural-sounding way. I'm fixing this myself, so don't worry.

Some player choices have also been sligthly edited and new ones added, so those I had to take straight from the JP script.

Overall, as far as the translation part goes, it can't get any more accurate than using the actual source material.

(Speaking of W7, apparently not a single line of dialogue has been cut, which I think is a very strange choice considering that many NPCs have A LOT of things to say and I'm not sure players are willing to endure absurdly long lore drops in a single sitting. In some cases, they even left in phrases like "I don't know about this" without having NPCs mention which topic they're referring to... This means it will be entirely on me to summarize the original dialogues without leaving important stuff out.)

Busted questlines

While testing, I discovered a pretty bad issue from a game design standpoint that is not present in the DOS and SNES versions of W6.

In the original DOS version, some questlines rely on the fact that the player has to provide the answer to some questions asked by NPCs by manually typing them in. If the player hasn't found and read the relevant notes that contain those answers, it's highly unlikely they can correctly guess them unless they're relying on a walkthrough. On the other hand, the SNES version forces the player to explore by explicitly keeping track of whether or not those notes have been found (or at least that's how it looks to me based on a walkthrough I've watched).

Wanna know how the Saturn port handles all this? Well, it kinda doesn't: when the player is asked to provide an answer, the game will list a series of dialogue choices to select from, and that list will ALWAYS contain the correct answer, even if the player doesn't have the necessary knowledge or hasn't yet found it through exploration. This reduces the "puzzles" to merely trying out every answer until you land on the correct one.

Can you see how problematic this is? The player is not given any prior context as to how they could possibly know the correct answer in advance and the Japanese script has not even been readapted to reflect this, so it all results in a very confusing experience.

To help you better understand just how bad this is, I'll use a very early-game questline as an example that will also serve to highlight how this can simultaneously affect multiple related interactions. It's completely irrelevant to the main story, but if you want to go in with absolutely no knowledge of the game, you may want to stop reading here.

(I've tried this on an unpatched version of the game to rule out any potential bugs with my hack.)

Early on in the game, you have to gain access to a place called the Captain's Den. As soon as you approach its entrance, a pirate will ask you for the password. Normally, you would obtain the password from an NPC called Queequeg, located about two rooms away from the Den. Before revealing the password, Queequeg asks you to find out where the Captain's treasure is hidden and to tell him its location. This involves finding an encrypted log left by another pirate mentioning said location, finding the cipher and finally decrypting the text. Only then will you be able to get the password and enter the Den.

In the Saturn port, if you go straight to the Den after starting a new game, you get this list of answers:

Screenshot_20250712_153902.png


If you can't read katakana, these are all different "spellings" of the words "Skeleton Crew", which is the password required to enter the Den. Of course, one of them is correct, so you can just try them all out and effectively bypass the entire process, just like that.

To add insult to injury, Queequeg still mentions that he will tell you the password if you find out about the treasure, but 1) you don't really need to do any of this because the game reveals the password to you anyway, and 2) the dialogue where Queequeg asks you if you've found the treasure simply doesn't trigger and he never actually tells you anything. Even if I've made a mistake and Queequeg does actually tell you at some point, you can clearly see that it changes nothing.

If you also consider what I said at the beginning of this post, that the localizers didn't even readapt the NPCs' talking points so that they flow in a natural-sounding way, you may begin to formulate the thought that this port was released unfinished. And you would not be wrong.

So... can anything at all even be done at this point, besides rewriting parts of the text so that those interactions somehow make logical sense?

Fixing the mess

The issue here is that this game just wasn't programmed to keep track of every progress that you make. Every list of answers is always predetermined and doesn't vary depending on what you accomplished. I guess one could go in and add support for tracking things by introducing specific flags, making sure that those are read by the question/answer system and then properly memorized when saving the game, but just how long would this endeavour take? When properly functioning versions of this game already exist, why even bother?

However... what if I told you that there is a way, and that it doesn't involve rewriting the game's code? At least, not assembly code?

I'll spare you the details on how I discovered this. In short: the Saturn port reuses both the same scripting "language" and scripts of the DOS version, which means we can mod the hell out of it using already existing tools!

The best (and only?) one is Cosmic Forge, created by Mad God. It's an editor for W6, 7 and 8 that lets you modify almost every aspect of these games. The author has managed to reverse engineer most of the scripting language used by W6 and 7 and implemented an event editor. This is what we're mainly going to use.

Well, not directly of course, as Cosmic Forge was made with the file structure of the original in mind, so there's a lot of copy-pasting involved to bring the edits made in the tool into the Saturn version. I'll write a simple conversion tool when I'm absolutely sure I have understood how the scripts are structured and which blocks require an endianness swap (not all of them do).

It's time to put my plan into motion: we'll do away with the question/answer events and instead use other types of events to enforce the intended progression experience. Instead of having players answer the questions directly, they will have to use new key items that I will introduce specifically for these interactions: for instance, to have the pirates unlock the door to the Den, players will have to present an item that represents the password, which could be a note with said password written on it. The items in question essentially act as flags: if players haven't acquired them, they will simply not be able to proceed.

Opening up the event editor on the Castle Basement map, this is what we're presented with:

Screenshot_20250712_010905.png


The first thing we need to pay attention to is the number of free event slots on the map (upper right corner): there's only one, so we have to be conservative with our edits.

We'll start with the events that trigger in front of the Captain's Den entrance. This is how they're structured by default:

Screenshot_20250712_005553.png


We see a Question event, which is what we have to delete and replace. However, we need to make sure that we can replicate its effects: a correct answer activates the event with ID 39, which apparently unlocks the door, while a wrong answer will activate all events with ID 5. These last two events are active by default though and, after being deactivated by providing the correct answer, there's no way to reactivate them because the Question event itself will automatically deactivate too. Thus, we only need to ensure that event 39 is activated and events with ID 5 deactivated on success and that the substitute event for Question will automatically deactivate itself.

There are two candidates for this: one event type is typically used to unlock doors using specific keys (called "Item Usage" by Cosmic Forge), but it can also be used to trigger whatever other event we want. Another type is the so-called "Item Equip Check", which, despite the name, can also check if at least one of your characters is carrying a specific item in their inventory, and can be programmed to trigger other events based on the result of that check.

As much as I wanted to use Item Equip Check to require no inputs by the player, it cannot be made to trigger when facing only a specific direction, and will instead trigger whenever the player steps onto that cell. This is not ideal, as we want the interaction to occur only when facing the door. Thus, with Item Usage being the only viable choice here, we modify the script like so:

Screenshot_20250712_124908.png


Why "Garland of Roses"? This is an unused item in W6 DOS that we're recycling to be our password note item. I mean, if the state of the game is any indicator, I doubt the devs wasted their time restoring cut content from the original, so it should be safe to do this. I've also deleted the Text event that triggered when selecting a wrong answer because there is no way to make Item Usage call it. It's a bit unfortunate, but I can add some explanatory text mentioning that one specific item has to be used here, so at least players will know.

You may notice that the event ID for Item Usage is now 5 instead of 4. This changes absolutely nothing and, what's more, it frees up one precious event ID (all of them had already been used in this map) that we'll need in a second.

Now comes the part where I've had to make some sacrifices. In the original, you find both the decoder ring and the Deadman's Log (the pirate's notes) on this map, located in different rooms. It doesn't matter if you get one before the other, because both items can be picked up and then "combined" when you have both of them.
This is how the cell containing the ring is scripted:

Screenshot_20250712_105336.png


After using the ring, you'd typically return to Queequeg to obtain the password.

Unfortunately, Cosmic Forge does not support editing events that occur when combining items (or maybe I somehow missed this), so this means I cannot, say, have the player receive a "treasure location" item when they're done decoding the text. The only alternatives I could come up with are the following:
  1. making the ring "static", that is, it cannot be picked up anymore and the Log will have to be brought to the room where the ring is located. In other words, the ring becomes a map event that checks if you have the book and, if you do, trigger its decoding and give you the key item; requires explaining why the ring can't be picked up
  2. same as above, but the Log is made static instead
  3. I leave this as-is and drop the whole "finding the treasure location" subquest, and instead directly place the password note somewhere on the map; requires explaining why Queequeg is not interested in finding the treasure anymore
For now, I'm going with 1:

Screenshot_20250712_130558.png


This may force the player to backtrack a little if they haven't found the Deadman's Log, but it is what it is. If it's too annoying, I could move the ring to a room that's more easily accessible from where the Log is located.

You can see that I've added an extra event with a unique ID. It's not the same ID as the one I freed up in the previous script block because I had originally freed up another by deleting an unimportant event from another room. I later restored everything, but swapped the event IDs. Not really important.

Notice that the event that gives players the treasure location item is a "Loot" event. Such events cannot reference specific items directly, but will instead need a "loot table" to be defined separately. I have created one that spawns the key item with a 100% chance and referenced it here. These are stored in SCENARIO.DBS in the DOS version, and in db_trea6.bda (treasure?) in the Saturn port.

The final edit that we need to apply is related to Queequeg's encounter. We want to make it so that, when you give him the note with the treasure location written on it, he'll give you the password in return. To do this, we need to edit what the editor calls an "incident":

Screenshot_20250712_113832.png


This is not part of the event editor. In fact, these scripts are stored in SCENARIO.DBS in the DOS version, and in wiz6.bin in the Saturn port. We're free to add many new events here because we're not constrained by map limits.

This is what I did that you can already see in the above screenshot:
  • key items cannot be normally dropped or given to NPCs, but this can be bypassed by marking the treasure location item as a "wanted" item (left side of the screenshot)
  • Queequeg now reacts to the player selling or giving him the "TREASURE LOC" item by calling script block 3, which will now reward the player with a "PASSWORD TO DEN" item
Script block 2 would be the one where Queequeg normally asks the player if they've discovered the treasure location, but I haven't yet found where it is called from and so I cannot simply restore it and have it perform an inventory check to see if the player has the key item. The current approach works fine, anyway.

Unrelated, but I've noticed that script block 4 should be called automatically after block 1. Block 4 has a 20% chance of triggering a dialogue where Queequeg tells you to try his Mystery Oil, which is a key item needed for another subquest. This actually never triggers in the Saturn port, so I'll have to see if I can restore it.

Aaand now comes the boring part: we've got all edits applied to the DOS version, but we need to replicate them for the Saturn version.

We'll start by modifying a couple of unused items ("Garland of Roses" and "Key of Nothing") to become key items with new names ("Password to Den" and "Treasure Loc", respectively). Their stats are stored in db_item6.bda:

Screenshot_20250712_122305.png


Each entry is 56 bytes long and the first thing they all reference is the address in wiz6.bin containing the name of the item. Each of these pointers comes with an offset applied: for some it's +0xb080, for others it's different and so far I haven't exactly noticed a pattern. Items have unique IDs determined by their position in this file, starting from 0 (same as the DOS version).
The item I've highlighted was once "Garland of Roses" (ID 260), whose name has been repointered to become "Password to Den". All the stats have been edited too because this item was supposed to be a piece of equipment, while now it does nothing except existing. "Key of Nothing" (ID 467) is stored at address 0x6628 and has been modified to become "Treasure Loc". Names could be 15 chars long at most in the DOS version, but I haven't yet experimented to see if this limit has been lifted for the Saturn port.

Now we're gonna edit loot tables in db_trea6.bda:

Screenshot_20250712_123602.png


These are 54 bytes long. The one I've highlighted is the new table containing "TREASURE LOC": 0x0104 is the item ID, while the rest means that the table will spawn 1 unit of this item with a 100% chance. These have a different endianness compared to the DOS equivalents, but only regarding item IDs and quantities, not spawn chances.

As for Queequeg's scripts, they can be found in wiz6.bin scattered between two different locations (don't know why they're split like this). You'll see in the following screenshots that I've already ported the edits to wiz6.bin, but I wanted to highlight how the two blocks require a different endianness in some parts:

Screenshot_20250712_141758.png
Screenshot_20250712_141821.png


(wiz6.bin on the left, SCENARIO.DBS on the right)

Finally, the last file to be readapted is db_spec6.bda. This one will require a lot of copy-pasting and endianness swapping, but we can make our lives easier by marking where certain blocks begin, where they end and determining which ones actually require an endianness swap:

Screenshot_20250712_141157.png
Screenshot_20250712_141215.png


(db_spec6.bda on the left, NEWGAME.DBS on the right)

These two blocks are 288-bytes long and have a different endianness. I wrote a rudimentary tool for myself that swaps the endianness of a sequence of 16-bit words so I can do this faster.

Other blocks are 144-bytes long instead, and these can be directly copy-pasted without an endianness swap:

Screenshot_20250712_142006.png
Screenshot_20250712_141954.png


After the last block of the Castle Basement map, we find a short sequence presumably containing some metadata:

Screenshot_20250712_161111.png
Screenshot_20250712_161231.png


Well, there's nothing more left to do than just launching the game and see if it all works. This short video shows the interactions with Queequeg and the Den pirate, but not the events related to the decoder ring, as I've yet to start an actual playtest and reach that point (I could move everything to a nearby room just for the sake of testing, but I'm feeling lazy now, so I simply gave myself the "TREASURE LOC" item by cheating).
The first thing I try is using the wrong item in front of the Den, and you can see that nothing happens. Then I got to Queequeg, give him the item and receive the password. Finally, I return to the Den and use the right item to progress:



This also showcases the new font I'm working on, which is supposed to be a simplified version of the one used by W7 DOS (thanks again to derek for the tools!).

This has been such a mess from start to finish. This "guide" too is super messy, but it wasn't meant to even be a guide originally. I'll write a better one once I'll have proper tooling that people can use, so you'll have to forgive me for any mistakes or inconsistencies you may have spotted.

I guess this localization patch is slowly turning into an actual restoration patch. I could have never predicted it would have come to this, but here we are. I had somewhat high expectations for this port when I first started working on it, but whatever, I'll try to fix what I can. There's another questline farther in the game that is for sure going to require the same treatment, but it will hopefully be an easier fix.

One interaction that I won't fix is when you first meet L'Montes. In the original, he refuses to let you into his "home" unless you type the words beloved or Snoopcheri, which you can learn by talking to Queequeg. Of course, the Saturn port pulls the same trick as before and just provides you with a list of three different spellings of the word Snoopcheri. I don't think this is that important of a dialogue to warrant a proper fix, so I simply have L'Montes say this before the player is presented with the list of choices (the first line is already present in the game, I'm just reporting it here for context):

I'm not coming out, whoever you are, and you can't make me!
Unless... you found my Snoopcheri?!


To which you can answer:
  • Say you did not
  • Say you did
  • Leave
So now the player has knowledge of what this NPC is looking for and can decide if they want to fool him or not. Then the interaction resumes exactly as in the original. The last screenshot of my first post actually showed a first crappy attempt at working around this issue, but I've since landed on a better version.

If you have any suggestions for improving what I've done, please let me know and I'll see if I can implement them.
 

Attachments

  • Screenshot_20250712_161128.png
    Screenshot_20250712_161128.png
    26.9 KB · Views: 0
Last edited:
Wow, it’s incredible that 1) you know the game well enough to see what this port is lacking in Japanese, and 2) you’re actually going to the effort to fix the port’s shortcomings.

On one hand, I think it would be fine to give us the original experience of playing this port, warts and all, just in a language we can understand. On the other hand, you’re making this a better game, and if you’re motivated to do that, then you should carry on.
 
It might be quite confusing to someone following a guide trying to beat the game post translation. I think your fixes are better for quality of life, but may I suggest writing up a walkthrough/faq/guide based on the changes?


Also, keep track of all the cut content you had to restore and put it on TCRF.net Also also, great write up.
 
may I suggest writing up a walkthrough/faq/guide based on the changes?

Yeah, I was thinking of compiling all changes that affect progression into a small walkthrough-agnostic guide, at the very least. I could also see if I can get permission to use and edit somebody else's walkthrough to have a sort of "official" reference document, but I'm not sure how that will go.

Also, keep track of all the cut content you had to restore and put it on TCRF.net Also also, great write up.

Didn't think about contributing to TCRF. I'll definitely do that!
 
So, I had two questions.
1) I went through the trouble of getting a Saturn, a 3-in-1 localization cartridge, and the game. Am I going to be able to do something to patch it so I can play on the Saturn, or am I going to have to pick up an emulator?

2) am I still going to be able to off queequeg to get the entire treasure?
 
Am I going to be able to do something to patch it so I can play on the Saturn, or am I going to have to pick up an emulator?
I don't have a Saturn to try the patch on, so I can't answer that. I would need somebody else to chime in and tell me if there's anything I should be aware of regarding compatibility with the hardware.

am I still going to be able to off queequeg to get the entire treasure?
There shouldn't be any problem with that. He'll drop the password note instead of the ticket stub, so you'll still be able to progress. If you're asking whether the game properly checks if he's dead or not when you get to the treasure, I would first have to reach that point and see for myself.
 
So, I had two questions.
1) I went through the trouble of getting a Saturn, a 3-in-1 localization cartridge, and the game. Am I going to be able to do something to patch it so I can play on the Saturn, or am I going to have to pick up an emulator?

2) am I still going to be able to off queequeg to get the entire treasure?

You'd have to patch the game on PC and burn it to a disc. But a stock Action Replay cartridge can't play burned CDs — you need to flash the firmware with PseudoSaturn Kai. (If the cartridge you bought already has PseudoSaturn Kai loaded onto it, though, then you're good to go.)
 
Back
Top