「電車でタイピング」は、最初、英語に全く対応していませんでした。外国人が思った以上に遊びに来ることを想定できておらず、実際に来てもらってから急いで英語対応を入れることになりました。ただ、後から振り返ると、足りなかったのは画面に表示する英語だけではありません。日本語をローマ字で入力する仕組み自体に、日本語で普段タイピングしている側の常識がかなり入っていました。
そのことが早くも出たのが、最初の駅を入力するところです。ここがアルファベット入力に対応していなかったため、急遽対応する必要がありました。最初の駅を入力する欄なのに、アルファベットでは駅名を入れられない状態でした。英語対応を急いでも、入力欄がアルファベットを受け付けるまでは、英語で駅名を入れたい人に使ってもらえません。最初の駅の入力だけを見ても、必要だったのは表示の英訳だけではありませんでした。
もっと難しかったのは、アルファベットを受け付ければ解決するわけではなかったことです。一番分かりやすいのが「東京」でした。英語で見慣れた表記はTokyoです。一方、日本語のローマ字入力で「とうきょう」と打つなら、Toukyouと入力する必要があります。Tokyoと打っても「とうきょう」にはならないので、日本語を入力する側から見るとToukyouの方が自然です。しかし、外国人にとって見慣れているのはTokyoで、Toukyouは不自然に見えます。
同じ駅名なのに、駅名を読むためのアルファベットと、日本語を一文字ずつ入力するためのアルファベットが一致していませんでした。
自分にとってのローマ字は、日本語を打つためのキーの並びでもあります。けれど、外国人が見るローマ字は、既に知っている駅名の綴りです。Toukyouと入力すれば、「と」「う」「きょ」「う」を日本語として打てます。その代わり、Tokyoを知っている人にToukyouを求めると、知っているはずの地名が急に見慣れないものになります。Tokyoなら駅名としては自然ですが、そのまま同じキーを押しても日本語の「とうきょう」にはなりません。この違いは、英語へ翻訳するだけでは表に出てこないものでした。
この違いを考えるとき、駅名の表記とタイピングの判定を分けておく必要があります。Tokyoは海外の案内で見慣れた地名の綴りで、Toukyouは「とうきょう」を日本語入力として一音ずつ打つときのキー列です。画面の名前をTokyoにしただけでは、ゲーム内の読みが自動で「とうきょう」へ変換されるわけではありません。逆に、入力の判定にToukyouを用意したからといって、その綴りが旅行者に見慣れた駅名の表示になるとも限りません。
海外から来た人にとっては、Tokyoと書いてある駅を探すこと、画面に出た読みを押せること、自分のキーボードで記号を出せることが連続した一つの遊びです。作る側が翻訳、検索、ローマ字判定を別々に実装していても、遊ぶ人はその境界を意識しません。どこか一箇所で止まれば、そこから先へ進めない。同じ「英語対応」という言葉で済ませていたときには、そのどこで止まったのかが見えにくくなっていました。
ローマ字の方式についても、同じずれがありました。当初は訓令式で書いていましたが、ヘボン式で書いてほしいという声が殺到しました。自分の中で一つの規則に揃えていても、それを読む人が普段から見慣れている綴りと違えば、不自然さは残ります。入力の仕組みとして整っていることと、外国人が読み慣れていることは同じではありませんでした。
訓令式かヘボン式かは、作る側から見ると表記規則の選択です。遊ぶ側から見ると、目の前に出ている駅名をどう読めばよいか、そのまま入力してよいかという問題になります。ヘボン式を求める声が殺到した以上、少数の人だけが気にする表記の好みとして扱うこともできませんでした。それだけ多くの人にとって、見慣れているのはヘボン式だったということです。しかも、TokyoとToukyouの例では、外国人が見慣れた綴りと、日本語として必要な入力がまだずれています。日本語の音を一文字ずつ打つゲームである以上、見慣れた英語表記と、実際に押してもらうキーをどう繋ぐかは残ります。どちらか一つを正しいものとして置けば終わる話ではありませんでした。
日本語入力にも一つだけのキー列があるわけではありません。例えば「し」はこのゲームでshi、si、ciを受け付けます。キーを一つ押すたび、残っている候補のどれかと先頭から一致するかを見ています。sの後にhを押したらshiの候補が残り、sの後にiを押したらsiで確定します。cの後にiならciです。画面に代表として一つの綴りが出ていても、それだけが正解という意味ではありません。
Mozcのローマ字かな変換表にもshi、si、ciから「し」への対応があります。これは日本語入力の実装の一例であり、全てのキーボードやIMEが同じキーを受け付けると断定する資料ではありません。ゲームでは、使い慣れた打ち方が突然ミスになるのを避けるため、同じかなへ進める候補を持たせています。ローマ字入力表で候補を確認できます。
代表の綴りを一つ表示するのは、初めて見る人に何を押せばよいかを示すためです。候補を全部画面に並べると、駅名より入力方法の一覧が目立ってしまいます。ただ、表示した綴りしか受け付けないわけではありません。慣れている人は別のキー列で進められます。見せる文字列を一つに絞る判断と、判定を一つに絞る判断を分けたことで、画面の読みやすさと入力の自由度を両方残しています。
画面の代表表記と違うキーを押したときに、すぐミスとして止めるかどうかは、この仕組みの使い心地を決めます。候補の先頭に一致している間は入力を進め、どの候補にも繋がらなくなったときだけミスにします。途中の一文字だけを見て判定すると、shiのhやciのcが不正解になってしまうからです。
shiなら三つ、siとciなら二つのキーで「し」まで進みます。入力候補を広くすると、同じ読みを打ち終えるまでのキー数も変わります。ゲームのWPMは正しく受け付けたキーを数えるので、ひらがなの文字数だけから速さを比較していません。複数の打ち方を認めることと、全ての打ち方を同じ打鍵数へ換算することは別です。
「し」以外にも「つ」はtsuとtu、「ふ」はfuとhuを候補にしています。「きょ」はkyoでまとめて打つ方法に加え、小さい「ょ」を分けて打つ方法もあります。「ん」は後ろに来る音によって単独のnを許す場合と、nnなどが必要な場合を分けています。候補を増やすことは、何を押しても正解にすることとは違います。日本語の読みを保ったまま、そこへ至るキーの並びだけに幅を持たせています。
「ん」の直後に母音が来るとき、nだけで確定させると次の音との境目が曖昧になります。そこで後続の音を見て、単独のnを許せる場合だけ許し、それ以外ではnnやnとアポストロフィなどの入力を求めています。「っ」は後続の子音を重ねる方法と、xtuのように小さい文字を先に打つ方法があります。どちらもゲーム側の候補として扱い、読みの途中で勝手に別の音へ進めないようにしています。
最初にshi、si、ciをそろえたのは、日本語を普段から打つ人が、このゲームだけで「し」の打ち方を変えなくて済むようにするためでした。その後に海外から人が来て、同じアルファベットでも駅名の表示、かなへ変換するキー列、手元のキーボード配列が別々の問題になると分かりました。日本語入力の候補を増やす判断と、外国語の駅名をどう見せるかという判断を、一つのローマ字ルールへ押し込めることはできません。
「・」は、ローマ字の候補を増やすだけでは解けない問題でした。キーボードにその記号を直接打つキーがない環境では、ゲームが文字として受け付けても入力方法が分かりません。どの環境で何を押せるかを確認しないまま、判定だけを「対応済み」と呼んでいた部分です。
現在は、読みの中の「・」に対してスラッシュのキー「/」を一回押す形にしています。表示には「・」を残し、入力するキーは日本語配列でも英語配列でも出せる記号に分けました。以前の問い合わせを、説明文を増やすだけで済ませなかった変更です。ただし、キーボード配列や入力方法は人によって違うため、ここでも画面に表示した記号と、実際に押せるキーを同じものだと決めつけないようにしています。
英語の文章を用意することは、実際に急いで必要になりました。それと同時に、タイピングゲームでは、説明の意味が伝わることと、その通りにキーを押せることの間に差がありました。最初の駅はアルファベットを受け付けず、TokyoとToukyouは同じにならず、「・」はゲーム側で受け付けても問い合わせが続きます。英語へ直した後にも、入力の問題がそのまま残っていました。
外国人から届いた声は、日本版を英語で遊ぶためのものだけに留まりませんでした。自分の国でも実装してほしいという声も多く来ました。英語で説明できれば日本の駅を遊んでもらえる、という範囲よりも先を求められていたことになります。同じゲームを自分の国の駅で遊びたいと言われた時、対象を増やすことと、表示だけを英語にすることが別の話だとはっきりしました。
さらに、自分の国の駅でも遊びたいという要望は、日本の駅名を英語で表示するだけでは満たせません。駅の一覧、読み、隣の駅への繋がりまで、その国のデータとして整える必要があります。表示の翻訳、読める綴り、実際に押せるキー、遊ぶ対象の駅。外国人向けの対応として一括りにしていたものが、プレイヤーの声によって別々の作業だと分かりました。
開始駅の検索では、漢字・よみ・ローマ字の一部から候補を探せます。ただ、現行の東京駅の代表ローマ字はToukyouなので、Tokyoだけを入力しても東京駅は候補に出ません。アルファベットを受け付ける検索欄があることと、旅行者が見慣れた綴りで探せることは別です。さらに、検索で駅を見つけることと、プレイ中に日本語の読みをローマ字で打ち切ることも違います。入口の検索と一駅ずつ進む入力の双方を確かめる必要がありました。
英語画面に切り替えたとき、駅名と路線名は同じ方法で英語へ置き換えているわけではありません。駅名は保存済みの英語名をそのまま出すのではなく、駅の「よみ」からゲームが採用する代表のローマ字を作ります。路線名は個別に登録した英語名があればそれを表示し、なければ日本語名を残します。英語画面でも漢字の路線名が出ることがあるのは、この段階的な対応のためです。駅名の表示、路線名の表示、入力判定は、それぞれ別の情報を見ています。
検索の対象はさらに別です。駅の漢字名、よみ、よみから作る代表ローマ字に加え、英字名が登録されている駅ならその文字列の一部でも探せます。英字名の検索では大文字と小文字、記号の違いをある程度吸収します。ただし、英字名が登録されていなければ、旅行者が期待する綴りの全てを拾うわけではありません。英語画面に切り替えたというだけで、世界中の案内板にある駅名と検索語が一致する状態にはならないのです。
遊ぶ人が詰まった場所を調べるときも、「英語が出ているか」だけでは原因を絞れません。検索候補が出なかったのか、候補を選べた後に読みのキー列で止まったのか、記号を押す方法が分からなかったのかを分けて確かめる必要があります。前者は駅名の索引、真ん中はかなとローマ字の判定、最後はキーボード配列に関わります。画面の文字だけを直しても、止まった箇所が違えば解決しません。この区別は、日本以外の駅を収録するときにも必要になります。
最初は英語に全く対応しておらず、必要になってから急いで直していきました。その中で見えたのは、こちらが正しいローマ字を用意するだけでは、外国人にとって自然な入力にはならないということでした。訓令式には訓令式の規則があり、日本語入力としてのToukyouにも必要な文字があります。それでも、遊びに来た人が見慣れているのはヘボン式であり、Tokyoです。画面に出した文字を相手が見慣れた綴りとして読めて、その人のキーボードで実際に打てるところまで確かめて、初めて外国人向けの入力対応になります。