After a long wait, the English translation of Remidoki – the full title being Ojousama no Dokidoki Daisakusen – is complete and ready for download! The game is a sidescrolling puzzle-based 2D platformer, released by Blue Mica at Comiket 78 in 2010. We’ve been working on the patch for some time, and it’s finally ready for release! You’ll want to make sure the game is fully patched to version 3.1.2 before installing the English patch. Major thanks go out to our long-suffering hacker mauve, Halbarad for the image work, Nazerine for the translation and HY for assistance with the translation editing! Mauve's ramblings---------------------------------------------------- All about cows with poverty games Retrospective: RemiDoki Translation Development Oh man this one took forever. Over a year ago, we decided to translate Blue Mica’s “Ojousama no Dokidoki Daisakusen“, which we had titled “The Mistress’ Heart-Throbbing Adventure.” And only now have we finally managed to get it released. But I’m not going to talk about why it took so long. Just like my previous retrospective articles, this will be about the technical difficulties the game posed. Data extraction, analysis, re-insertion Remidoki is a DXLib based game, which is a fairly common Japanese game development library, and so a lot of its data is relatively standardized. For example, it’s used in Rosenkreuzstilette and Koumajou Densetsu as well. So I already had unpackers for the data at the time we decided to start working on this, making it mostly a matter of re-insertion and analyzing what we had on our hands. This was actually the easiest part! DXLib’s packfiles consist of a starting header, file data, and then the index data contained at the end of the file. It’s surprisingly robust and even includes a simple directory tree format, even though we didn’t actually use any of that. Additionally, they’re fully encrypted with a 12-byte XOR key repeated for the entire file. Internally, this is generated by giving it a simple input string, which it will mangle into the resultant key value. If you download DXLib itself it even includes source code you can look at to see how it does it. Handy! It wasn’t too difficult to make it recognize a third pack file just for the English, either, so no fancy patching was needed. Once everything was pulled out, all of the dialogue scripts were in plain text, and the images were all plain old ordinary .png files. Nothing fancy here, fortunately. We did have some issues with the dialogue scripts where it would not correctly parse the scripts if you used spaces instead of tabs, and the game would just freeze instead of handling it gracefully. In a way that was probably a good thing since at least it made sure we caught them all. Executable woes This was an early project for my PE modifying patching and text reinsertion tool, so I hadn’t fully determined what all I would need at the time. Of course this led to a lot of extensions being added as I was going along, as pretty much all item and place names are contained within the executable. The achivements were in there too, as well as the strings pointing at which packfile each file was contained in. For the most part, there weren’t any real roadblocks on this. The text rendering is quite possibly the easiest I have ever come across in any doujin game! The game had VWF font rendering out of the box thanks to DXLib, and simply needed to be switched over to a decent font, in our case we used boring old Arial, and we were good to go. The most notable thing I needed to do was that a lot of the game’s strings are stored sequentially in one big array, and we needed to replicate this format when placing text back in. I resolved this by letting the editor tag a padding value to each string, which will designate a fixed length storage regardless of the content inside it. That was pretty much it! Of course, no project is really that easy. That’s a myth designed to lure prospective hackers in so that they may suffer defeat. In this case, there was one major problem for me… Every single bit of text in the game is manually placed. That’s right. Aside from the dialogue, every last piece of text you see is hardcoded into the display, and a great deal of it is manually centered. Plus, because of the font size change, since you always change font size coming from a blocky Japanese font, anything that wasn’t centered probably had to be moved around a couple pixels anyway. What does that mean? It means I had to go in and find every single individual usage of text and manually adjust the positioning. Every last one. At this count, I’m looking and seeing roughly 200 adjustments that had to be done by hand. And I’m pretty sure I missed a few. (I think there were a few that were changed very near to release that may not have gotten updated in time… Oh well?) Buh. Adding to that, there’s a lot of random little menus around the game you wouldn’t expect, so all menu paths had to be found just to they could be tested, which took some time in its own right. Again, all of them were manually aligned so I had to go reposition everything by hand. From a hacking perspective, this is not really interesting. It was just majorly tedious. Final analysis This really wasn’t the most difficult project I’ve ever worked on, SWR takes the cake for that, but it was definitely the biggest hassle for quite a few reasons and I’m glad to be done with it. At least it didn’t get patched again just before release. Maybe it will in a few days and I’ll be shaking my fist at the heavens. That’s been my luck, lately.