衒思力発電所

タイピング入力判定ライブラリ Tsuikyo JavaScript 版

アルゴリズム的な講義を聞いているとロジックの世界を旅したい気分になるので授業中現実逃避にちょくちょく書いてたんだけど，形にはなったような感じ^*1なのでお披露目． 駒場祭だし？ みたいな．

D 言語で書きましたとかただのオナニーというか自分の学習のための習作以外のなんでもなかったので，時代はオンブラウザだろ，という最近の宗旨変えに素直になって js で． ちょい直すだけで as として flex 開発にぶち込めるというのも理由のひとつ^*2．

一応改めてざっくり言うと，ひらがなを与えるとタイピングゲームに必須の柔軟なローマ字キー入力判定を提供するよというもの^*3． そんなものライブラリにする間でもないわいって思った時代が俺にもありましたが，柔軟にやろうとすると適当その場コードでなんとでもなるっていうほど簡単ではなくて．完全に形式的に処理できてると後からもっと複雑なギミック入れるときに助かるしね．

今回 js にするにあたって suikyo に依存しないようにフルスクラッチしたので晴れて自由の身^*4．あと前にとりのさんが話題にしていた従来より一層柔軟な判定を実装……したつもり．遅くなりました．

とりあえず利用サンプル．

例によってやる気ないサンプル．デバッグコードまとめたものともいう．例によって打てるよーってだけ．

まあタイパーなら 「じゅ」が j i u で通過できたり，「っこ」 が ckko で通過できたりするのを見て喜べるんじゃないかと^*5．

以下興味ある人にしか面白くない技術的なあれ．

-

非決定性オートマトンはこうやれば決定性オートマトンに構成しなおせるから等価だよっていう証明とかを授業で習ったんだけど，その考え方ひとつでスマートに実装できたので先人の知恵は偉大だなぁとか，理情の授業は役に立っていいなぁとか，これくらいのアルゴリズムも知らない/思いつかない俺はやっぱ文系ですなぁとか思わないでもない．

詳しくは完成してからドキュメントでも書くかと思ってるけど簡単に書くと，ひらがなからオートマトンを作るとこまでは特に変わったこともないんだけど，状態遷移していくときの処理にひと工夫した．

入力に対して遷移先が複数ある場合にそれぞれの遷移先状態を並列して扱う（これで tu と tsu どっちでも，とかが実現）ことはもちろん，他にも遷移先が考えられる場合には元の状態も並列させ判定対象＝仮想状態として残し（これにより ckko の類が実現），またさらにひらがな単位で確定したというだけでは対象状態以外の仮想状態を捨てることはせず，「対象状態よりも進んだ状態にその対象状態を経由せずに到達する経路が存在しない」 ような場合に限って状態を確定し仮想状態を破棄する（これにより jiu とか実現）ようにした．

一言でいうと簡単にはルート確定せず 「今押されたキーは確かに受理できるし受理するけど，なにも確定はしないわよ． まだ別の状態にこの先何がやってくるかなんてわからないんだからねっ」 っと仮想状態をたくさん持ったまま，オートマトンをあちこち塗り塗り進むイメージです．経路が収束する地点（「にっぴょう」 なら に/っぴょ/う/ ）にたどり着いた時にはちゃんと確定して仮想状態を破棄してるんで，長いワードになると仮想状態の数が発散するっていうようなことは起きないんですが，しかし 「っぴょ」 程度の枝分かれでもひらがなレベルで戻って打っていい（ppi ltu pyo と打つと ltu pyo が採用）っていうのは，今までの感覚からするとこんなのアリかよｗ柔軟すぎじゃねｗ って変な気分になる．

とりのさんもどうすんのって言ってた話としては，ミス関連．

あと些細な点で zjyu とかどう処理しようかと、成立はさせるにしても、ミスが1とも2とも化けるのはちょっとね。TW憲法のような無駄判定を使えばいいのかな。ついでに jzyu との差とかどうしようか。

今のやつではミス数が最小になるような判定を選ぶようになっていて，「じゅ」 を zjyu と打った場合ミスは 1 打．本当は ju と打つつもりだったのに j のあとに y を誤打して，偶然こういう打ち方になりましたという確率は低い（jyu か zyu を意識した確率のほうが遙かに高い）し，どのみちもうミスしてるわけなので，ミス数最小になるように判定くらいはしてあげていいだろうという妥当なやさしさ．

ちなみに上記でどちらで判定してもミス数が同じ zyu と jyu のどちらが採用されるかというと jyu で，さらに jzyu と打っても jyu 採用なんだけど，これは jyu の方がインデクス的に先にあるから（という手抜き）．

もっと複雑なもので同じ状況になることもあるので，「誤打による正打の分断され度」^*6が小さい方を採用するのはどうよと思っているが，はて． jzyu なら zyu ，「っぴょ」 ppiltyupyo なら，ltupyo ． うーん，微妙？ どちらの入力方法にも貢献していない完全な誤打が入ってくるとまたややこしくなる．

まあこう考え出すと迷うけど，冷静に考えると，本来 4 打で打てるものをむちゃくちゃ誤打鍵しまくりながらきもい打ち方してるってことなので，どっちを採用しようがこんな打ち方するやつは構うまいよ，とも思う．インデクス小さい方採用ってのはさすがにないけどさ．

そんなことよりゲームにする上で問題なのは，こういうキャンセル入力とでも言おうかしらな入力ができると，ある打鍵が，それ自体が入力された瞬間にはミスじゃなかったけど，その後棄却されてミスになりましたってことがあるわけで，キーを押した瞬間に音なりビジュアルなりで正打誤打を伝えることが難しいってあたり．

誤打鍵したらその瞬間にそれを通知するっていうことが常識化してるけど，それは（どの仮想状態にも受理されなかった場合はいいけど）無理，でもって後から誤打扱いになったのに通知なしじゃやったぜノーミス！ と思ったらキャンセル分で 2 ミスでした，みたいな残念な事態を生んでしまうし，キャンセルが発生した瞬間にミス音を鳴らすとかしたらその瞬間に打っていたキーが誤打なのかと思ってしまうし．

音なりビジュアルなりを通常のミスとキャンセルによるミスでは違うものにすればなんとかって解決策はぽんと浮かんだが，他になんも浮かばないなぁ．っていうかこれしかないよね，多分．

そんなことを考えながらぼちぼち使い物になるライブラリを目指しそのうちちゃんと配布します． いや，しばらくはゲーム本体書いてる暇ないんだもん．ほんと．

1. まだ実装してないことばっかだけど動くことは動く的な意味で． [↩]
2. そんなことしないでも as 内から外部 js 利用する方法が用意されてるみたいだ． [↩]
3. 一例であって，厳密には変換定義を書きさえすれば与えるのはひらがなじゃなくてもよく，任意の文字列を指定のキーストロークに対応させ受理するもの．漢字かな交じりを T-Code で打つとか． [↩]
4. GPLv2 的な意味で． [↩]
5. 何を言ってるのかわからない場合は色んなタイピングゲームで遊んで出直そうね！ [↩]
6. 学問的にこれなんていえばいいのかしら．いくつに分割されているかだけ見るか，分断されてる距離の和を見るかとかで名前違いそうだけど． [↩]

Trackback URL

コメント (3) to タイピング入力判定ライブラリ Tsuikyo JavaScript 版

コメントをどうぞ