News: 11 March 2016 - Forum Rules

Author Topic: How did a translation cause this bug in Dark Cloud?  (Read 1745 times)

McKnight

  • Sr. Member
  • ****
  • Posts: 250
    • View Profile
    • Dreamwidth
How did a translation cause this bug in Dark Cloud?
« on: October 10, 2021, 02:15:41 pm »
I'm asking this, because I would like not to worry about one thing someone I commission does somehow modifying something else such as an item's drop rate from a given enemy.

Basically, how did translating Dark Cloud into English reduce the Flapping Duster's appearance rate to 0, and instead of finding the value pertaining to it, why did the localizers have to create an entire bonus dungeon to "make up" for that?

I also understand that, in Earthbound, changing Threek's K to a D somehow modified the colors in Snow Wood Boarding House.  To such a subtle degree that you'd have to compare screenshots between EB and Mother 2 to notice, but it is mentioned in Legends of Localization Book 2.

How do changes in bit values like those come about while modifying a game, be it hacking or localization?

tc

  • Hero Member
  • *****
  • Posts: 1228
  • Lum Fan
    • View Profile
    • Eon Blog
Re: How did a translation cause this bug in Dark Cloud?
« Reply #1 on: October 10, 2021, 05:40:45 pm »
I couldn't tell you much about how or why.

Look no further than Pokemon, Missingno is one of the best known instances of glitches impacted by localization.
Surfing the Cinnabar Island east coast does not spawn wild encounters in the Japanese version.

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 7415
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: How did a translation cause this bug in Dark Cloud?
« Reply #2 on: October 10, 2021, 05:59:12 pm »
Especially if the devs were doing things "the ROM hack way" rather than actual source code edits, it's easy to change something, assume it's correct, or it's not, not bother to change back since there was no immediately apparent change.

I don't recall exactly the technical reason for the surfable tiles, but I do know the Pokemon games have had different memory maps between Japanese and English.
"My watch says 30 chickens" Google, 2018

[Unknown]

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
    • PPSSPP
Re: How did a translation cause this bug in Dark Cloud?
« Reply #3 on: October 10, 2021, 10:10:57 pm »
People sometimes don't realize how often bugs cancel out bugs.  That can cause this problem as well.

In theory, it could be that the Flapping Duster's drop rate was accidentally overwritten by a Japanese character.  Even though the drop rate was incorrect, it still dropped (just not exactly the correct percentage) so no noticed.  Then the translation changed that Japanese character to an English one, which happened to guarantee it never dropped.

Again, that's a hypothetical example - not the real explanation.

The point is that all software has bugs - certainly the original Japanese game had some.  But you have to realize some bugs don't have an immediate observable effect.  They are there and wrong, but aren't noticeable or are balanced out by a separate bug that happens to cover it up.  A translation sometimes changes that balancing factor.  It can be simple as that.

-[Unknown]

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 7415
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: How did a translation cause this bug in Dark Cloud?
« Reply #4 on: October 10, 2021, 11:51:25 pm »
Really, the Flapping Duster NEVER drops? I could've sworn I got it ONCE when I played the game.
"My watch says 30 chickens" Google, 2018

[Unknown]

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
    • PPSSPP
Re: How did a translation cause this bug in Dark Cloud?
« Reply #5 on: October 11, 2021, 02:19:59 am »
Well, that's what I'd heard, says it here too:

https://tcrf.net/Dark_Cloud#Inaccessible_Area
https://www.romhacking.net/hacks/3405/

Maybe never is an exaggeration and it just much more rarely drops.

-[Unknown]

FAST6191

  • Hero Member
  • *****
  • Posts: 3529
    • View Profile
Re: How did a translation cause this bug in Dark Cloud?
« Reply #6 on: October 11, 2021, 04:35:08 am »
We are heading down the "more art than science" parts of coding at this point, though choice phrase tends to be "falling debris" (as in watch for it). This is also ignoring that localisation need not be just changing text around (maybe changing script to appeal to the imaginary local kids as well) and can include bug fixes, rebalancing (which can include harder) and censorship things.

I am not sure where to start with this one.

Bug fixing, including "it is 5pm on a Friday and I want to go home" methods appear here. One that sticks was I think from a GDC talk where a guy was talking about his time making the Tron game that appeared alongside the film a few years back. They were using unreal or something and turned out a given item was invisible. Turns out in whatever version of unreal was used an item of a given number was forced invisible by the original base game bodging some code that was spun out into the engine. Solution from Unreal themselves was "don't worry, just make item number blah a basic cube or something knowing it will be invisible, don't use it in the game and go from there".

Still from a ROM hacking perspective there are two primary suspects if I was to investigate things.
1) Weird memory read issues.
Usually seen more in devices with bankswitching, especially if code was duplicated between areas as a safeguard that was skipped when either the translating company opted for a cheaper bank setup (or maybe just a different one) or did not immediately become apparent.

2) Timing issues.
https://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/ is probably one of the more noted examples of such a thing in games/emulation, and nicely covered. Comes in other forms as well https://hackaday.com/2015/10/26/killed-by-a-machine-the-therac-25/ .
More generally there is a reason why most instruction lists come with cycle times, DMA reads will have times associated with them and latency is a thing taught early in electrical engineering (though more likely to be called circuit hazard at that point).


1) and 2) can sort of combine as well, especially if the original devs did some kind of http://www.catb.org/jargon/html/story-of-mel.html shenanigans and were all "ooh that text routine is this far away from my drop rate, let's use it to calculate a jump" and other sorts of things that leave us with https://www.loekalization.com/mistakes.html type setups in more general discussions. Get enough of that and things still making it through play testing

If you are not familiar with coding errors in general then might want to sort that too if going to be going too much further into this sort of discussion
https://textexpander.com/blog/the-7-most-common-types-of-errors-in-programming-and-how-to-avoid-them (7 might be a few more than some try to categorise them as, few less than others). It is not anywhere near as arcane as some of the other links I have dropped so far either; it is often the sort of thing taught maybe not to day one codes but definitely first week.
I would also flank it with https://www.joelonsoftware.com/2010/01/26/why-testers/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ as again it is really useful to know, even if you are not a coder (not to mention coders don't always make the best testers, and testers don't need to be coders).


and as far as "because I would like not to worry about one thing someone I commission does somehow modifying something else" then nothing you can do. Most times it won't be an issue as the way games are coded tends to mean things are fairly obvious and unlikely to happen owing to being isolated. Can go one further as well. I have all those links either in my bookmarks or found them first go in a search engine from memory, and would say I will pit my skills against any of those people, might not always win but it would be a proper fight for them. I can't be sure either outside of an insane degree of testing (and even then I probably have to worry about console manufacturing variances*) that nobody does, possibly even for the medical machines -- if you have ever been bored (even as someone that likes fiddling with things enough to be on a site like this) by good boy coders prattling on about testing oriented approaches to coding, unit testing, the importance of a good specification and the like then you have seen nothing yet for the sort of insanity required here. Though I will at least give them one the importance of good specifications; most professional failures and nightmare projects have been because I did not secure one or push for one. Given most localisation teams would be happy to have Japanese comments, never mind a nice full code listing, systems overview, coding philosophy and all that jazz, then... yeah.
More generally this is games. There will be bugs. Nobody will be hurt, fixing them might even be fun.


*actually a thing that has come up, and I can't wait for it to appear when FPGA stuff happens in a few years as those kinds of pedants are some of my favourite to wind up. Usual examples if you wanted them would be go look at the controversies surrounding gamecube pads in Smash brothers tournaments, and costs of some of those that happen to fall into the desired regime and also the original xbox and slow RAM (they were building them on the cheap and using RAM that might not have made the higher grades so some of the earlier models were slower than nominally the same devices in later batches/models, and this can have effects in games). Lesser versions for different clock speeds between devices with backwards compatibility (and failures thereof). Sort of related is also the floating point error in Wii emulated version of Super Mario 64 vs original, and comes up in certain speedruns/challenge runs as it allows some different techniques.

Couple of other links that are of passing relevance here
https://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/
https://www.youtube.com/watch?v=fWqBmmPQP40

We have not even talked about malicious actors/trolls, covert anti piracy (some do like the challenges of the subtly break the game versions),

McKnight

  • Sr. Member
  • ****
  • Posts: 250
    • View Profile
    • Dreamwidth
Re: How did a translation cause this bug in Dark Cloud?
« Reply #7 on: October 11, 2021, 06:12:45 am »
Okay, so I've just taken some time to figure out what I'd actually want verified for each ROMhack completed, and it's mostly randomized events, along with any gameplay effects no one actively observes (such as how defense spells in Suikoden I and II fail to work at all).

Now that I've narrowed that down, I suppose it is common for ROMhackers to seek beta testers for a finished product, no?

I'm also pretty sure that offering money would not be the best way to go on about finding any, because people can say whatever they need to if that's all they want.  This would be the most likely reason why only people with earned priveleges get to test new features for a website, and why you need to pay in order to be allowed to beta-test a crowdsourced game.

Would anyone here know the best way to find people interested in looking over whatever I specify, through actual gameplay, to ensure that nothing is overriding a given thing's specified bit value?

FAST6191

  • Hero Member
  • *****
  • Posts: 3529
    • View Profile
Re: How did a translation cause this bug in Dark Cloud?
« Reply #8 on: October 11, 2021, 07:50:51 am »
There are all sorts of slipped by the testers type things, sometimes even wrapping round into "that's not a bug, it's a feature" territory; can't remember what but some 8-16 bit ninja game got a translation but owing to a bug in the text handler (and it being one of the very few games that won't just crash on you) the main ninja became the strong, silent, "...." type and apparently everybody loved it. Might speak to redundant text in the story but hey.

Beta tests... in a way anybody that uses it is a beta tester. More commonly though it is only really found in translation hacks wherein the aim is usually to look for typos, new line issues, bursting out of text boxes and maybe continuity/that all the same terms were used (two translators, one romanised a given term, the other tweaked it to be something more linguistically satisfying for the native audience, now a part of the game references it). Similar perhaps for total conversions. Have met a few super challenge run type hacks that had a friend go through it but far less formal than translations I have seen.

Paid stuff in ROM hacking gets tricky, mainly as that is where lawyers perk up (second being he said, she said and sites having to deal with that drama when payments get involved). Now paid testing would probably be far less tricky than commissioning hacks in the same way that "you are not paying for the software as much as paying someone to install/support it" when it comes to installing a bunch of open source software one someone's machine.

Really though I would say you are overthinking things here; 99.999% of the time translations done by ROM hackers will not unintentionally mess in the slightest with anything that touches gameplay. You are more likely to discover a screw up by the original developers that caused a mechanic to behave differently to what the manual/in game text*/presumed intent. Indeed if you wanted to spearhead a group project trying to uncover those, or at least give plausible actual equations for things, whether something is truly random, and maybe calling in hackers when something interesting shows up, that might actually gain some traction. Those playing would not necessarily have to be great hackers, or hackers at all, to do useful work; basic play gains some things, master savestates** and better still, gain basic cheat searching and you are almost there really as you control it all for most games once you have that, the hackers then come in to look at the actual equations if something interesting appears or people are just curious ( https://www.dragonflycave.com/mechanics/gen-i-capturing https://www.youtube.com/watch?v=FeemO9yW-hs ).

*I would be willing to be everybody here, having all presumably played a RPG or three over the years, has failed a 99% chance to hit/steal/defend/uncover two times in a row on multiple occasions despite the technical odds being way outside that, possibly even three.
For observed statistics then https://www.youtube.com/watch?v=8Ko3TdPy0TU https://www.youtube.com/watch?v=s9-b-QJZdVA

**be somewhat careful here for while most things are calculated after a button press in games then some games have things calculated ahead of time (start of turn, as you enter a room, as soon as it is highlighted...).

As far as paying to beta test a game back in normal games world. I detect the foul scent of marketing slimes on that one, possibly social psychology as well and likely a dose of boring greed as well (not that the other two lack incentives in that direction). Paying to leak things is harder in closed cases, and there is also sunk cost fallacy and other things where people have paid out already so presumably early buzz will be from super fans.

Worrying about paper mills taking your money and fabricating things is a real concern. However testing is a real skill (see the Joel on software links earlier) so it is easier said than done, though far from impossible. Would be possible to structure things, though for the amount of effort I would probably look at automated testing there (is starting to be a thing in general games, tool assisted speedrunning is basically this by another name, and test rigs*** as it were have been done for a lot longer but are more limited in scope).

***you figure out a list of mechanics to check in the game and between a combo of turbo, cheats, savestates and a big list of tests to do you have your answer.