I don’t know why this didn’t occur to me earlier, but I wanted to mention this in case some of you don’t visit the forums.

krfsm on the mirror moon forums has announced the creation of a patch which allows the importing of voices from the PS2 version.

While I haven’t had a chance to enjoy the patch yet (my game probably arrives next week), I can imagine it must be great!

Much thanks to krfsm for his contribution to the fan community!

Read the details here.

I just wanted to throw this out there…

Someone recently had the following complaint on the forum about the translation (I’m not picking on you, it just raised a good point):

——————–
I can kinda see stuff like daimyo and nii-san, changing daimyo to “lord”, “count”, or whatever would be appropriate would be kinda like changing “emporer” to “king”, and siblings always referring to each other as “brother” or “sister” in English sounds kinda odd, so stuff like that is alright as long as its not a dub.

But do they really have to leave words like “archer” untranslated? Its not like they’re “the Japanese equivalent to an archer”, they ARE archers, they use a bow and arrows, and that’s what they’d refer to them as in English, too.
——————–

But just to clear up some confusion…
Words like periyerai, aperyu, and many other words with furigana/kanji over them in the original game are NOT Japanese words. They were made up words used in the world of Utawarerumono that Japanese wouldn’t even be able to understand and had furigana over them in the original version. Some of these were modified versions of Japanese, Okinawan, or Ainu words; others were simply just made up. The only Japanese words that I can remember not translating and having furigana were the terms of address. The rest of them are made-up words or intentional variations on Japanese. There is one notable exception to this late in the game, but it’s a spoiler, so I won’t mention it here. In order to get the reference, I’ve left it in Japanese.

I’ve been cruising the internets when I’m not busy with mirror moon, work, or writing my own story, and I have stumbled across (with the nudge from Peorth and Graus) about Katawa Shoujo.

Katawa Shoujo (goddammit, I keep typing ‘Kawata’) is the biggest (known) Original English Language Visual Novel (more commonly known as OELVN) project to date. I believe they are approaching the 200,000 word mark, which is pretty big, considering it’s almost a third of the size of Tsukihime, quite hefty itself.

It is an eroge and is under development by Four Leaf Studios. KS was partially inspired by a thread on 4chan’s /a/ board, which is fairly amazing in my opinion, as you have to have balls of steel or lack of brains to take a page of doodles, character descriptions and ideas, scenarios and somehow compile it into a visual novel.

Katawa Shoujo’s main quirkiness (apart from the easily-typoable name; did it again :/) is that all of the main characters are disabled in some way. The main character you play, Hisao, has a heart condition; some are blind, some are without legs, and so on. The story is set in a school for the disabled. I thought it was initially odd at first to have a visual novel full of cripples, I gradually warmed up to the idea, as it brings out the idea that disabled people have feelings, too.

I have seen some of the character designs and I am definitely already liking some characters more than others (so sue me). Also, the backing music is composed by NicolArmarfi, and after hearing a sample (namely Romance in Andante II), I would have to say the music is probably one of the main things I’m looking forward to in Katawa Shoujo.

A demo is being worked on, although estimated time of completion is unknown.

I’ll be keeping an eye on this project, so I guess I’ll keep people posted.

Website: http://katawashoujo.blogspot.com/
Forum: http://ks.renai.us/
IRC: #zettai-shoujou on irc.rizon.net

I have done up a screencast of QED showcasing the basic features.

This is my first screencast so it’s terrible, some things bug out here and there, and I constantly have to switch between Dvorak and Qwerty otherwise you would be wondering why I’m saying L when it shows up as N, etc :p

Please be warned: This video contains POSSIBLE SPOILERS for ALL ROUTES IN FATE/STAY NIGHT!

I avoid the UBW and HF files, but the dashboard contains maybe ten lines out of HF Day 4. From what I read, it’s not that much different to the other Day 4s, so maybe not.

The screencast is encoded with H264 in the Quicktime container, so you’ll either need Quicktime or Quicktime Alternative to view it. The size is 31.3mb and the duration is 23 minutes and 39 seconds.

View

Enjoy!

Been a loooooooong while since I last posted a blog here.

Anyway, it’s 2008 and I’m working full time for a year. The sad thing is, I have more free time working full time than I had working three full days a week plus five units a semester at uni.

So with my free time, I’ve been getting back into the scene, catching up various things (which involve playing Tsukihime a whole year and a bit after it was originally released >_<, and playing Fate/stay night). One of the major things I'm working on, however, is this little fickle thing we call 'QED'. It's one of those weird acronyms that is out of sync with the words itself. It's an acronym for 'distributed quality enforcement', and also the codename of a fairly exciting tool that I'm developing for mirror moon. In a nutshell, it allows us to streamline the proofing/editing process by quite a lot. I'm estimating that it'll increase the ease of reporting errors in the text, as well as making the grue's (GRand Unifying Editor) job much easier. Previously, we have tried a variety of different solutions for proofing, including Trac, flyspray and are currently using just a forum thread for it. Trac and flyspray was too complex for what we wanted, but granted, they were full on issue reporting applications. I happened to browse the forums one day and came across the forum thread with a day of UBW's proofing. What I saw made me cringe: Each proofreader posted a few sentences of the original text that warranted a change and the proposed fix along with a reason (if needed). Then the master proofer (Message) would go through the posts and either agree or disagree with the change, and in the case of one that he can't decide (usually due to a translation styling thing), it goes to the grue (who happens to be TakaJun). After all THAT, then the grue looks at the thread, decides whether to implement the fix or not, opens up the diff, looks for the line, then changes the line. Repeat that by at least ten fixes per scene, around twenty scenes per day, then by however many proofers reported that change... it's a lot of boring and time-consuming work. There are also a few downsides that further slow down the process. The master proofer doesn't easily have access to context (as it's generally the line that needs changing), and he has to go look for it, which further wastes time. Then, the grue might have to scroll all over the place to make sure the same line isn't reported twice, as one might have a better fix than the other. I considered all this and decided that we needed a custom proofing solution. So I made one. QED began development on the 1st of December, coded in Ruby on Rails. It is fairly close to completion; I'm just implementing keyboard support for even faster proofing (thank you, Message, it is really a timesaver ;o). Each script file counts as a Section, and they have many Blocks (think chunks of text). The Block contains a copy of the original text and all the English lines within that block. Each Line then has Fixes, which are proposed fixes to the original line. Each Fix has a reason and comments. The proofer's general workflow is now:

1. Proofer sees a problem.
2. Proofer adds a fix.
3. Proofer moves on.
4. Proofer sees another problem, but this time, other proofers have suggested fixes.
5. Proofer can then vote on a fix, optionally comment on why, then continue.

And so on. This is already muchly improved compared to the old method already… no duplication of efforts (apart from more than one person proofing the same thing, but that’s what we want).

Lets look at the master proofer workflow:

1. MP sees an unresolved line (marked with an orange number on the left).
2. MP looks at the list of fixes.
3. MP looks at the context, which is above and below the line in question.
4. MP optionally looks at the original text (which is shown by a toggle link).
5. MP makes decision based on intuition and votes.
6. MP clicks a button next to the decided fix.
7. MP moves on.

How much time did we just save there? A lot.

Now, lets look at the grue’s workflow, which is really the above, plus this:

1. Grue makes sure everything is resolved by checking the stats at the top part of the page.
2. Grue clicks ‘Download Diff’, which depending on where he is, sends him a .txt in his chosen encoding or a zip file.

I’m pretty damn sure that saved a shitload of time there.

Plus, when keyboard shortcuts are done, things will be even faster. The whole thing also heavily uses AJAX to streamline the process even more. It also has versioning built in so we can see who made changes to what, and also revert if needed.

We will be using QED for HF, and I’m using it to report various bugs I’ve found in Fate as I’m playing along. QED also has project support, so we will be using this for future projects as well.

That rant was almost tooooooo long, but I hope you guys enjoyed a sneak peek into what goes on behind the scenes.