作り手じゃないからこそ読んでほしい、タイピングゲーム開発の苦労話
この記事は「タイパー Advent Calendar 2021」の3日目の記事になります。
こんにちは。
今回の記事では、最近気合を入れて作っている自作タイピングゲームの開発の話をしてみます。
※できる限り数学要素などは省略して書いたつもりですが、わからないところがあったら「ふーん、そうなんだ～」くらいで読み飛ばしてください！ただの体験記みたいなものなので、すべてを理解する必要はありません！
つくったもの
ベータ版ですが、FoxTyping として公開してあります。
従来のタイピング練習ソフトやゲームサイトを踏襲しながらも、次のワード表示機能など、細かいところに気を配って、できるだけストレスなく快適に打てるように設計するのが目標となっています。
さらに、いままでほとんど実装されてこなかった、長文＆変換込みの練習を搭載するのが目標です。
実用入力勢（いわゆる、実際の文章入力に近い方式でタイピング競技を行う勢）を増やす目的があるほか、近年、高校の教育課程の変更で「国語」が「実用国語」寄りになることも示唆され、文学作品に触れる機会が減少することが予想されるため、文学作品に触れる機会をこちらから提供できればうれしいな、という教育方面に対する隠れた目的もあります。
作成が難しかった部分
エンジニアでない方からすると、どの辺で開発に苦労しているかなんて皆目見当もつかないと思いますが、こんな簡単そうに見えるところが実は難しい、というのをいくつか紹介してみます。
ローマ字のすでに打った文字を消す部分
上の画像の赤枠部分です。文字が打つと消えていく、とかどこまで打ったかわかるようになるアレです。 どの練習サイトでもしれっと実装されていますが、日本語、ローマ字入力になると実はちゃんと考えて実装しないとバグを量産します。
入力されたキーが正しければ消える、という基本方針で構わないのですが、ローマ字に限っては複数の入力方式があるため、そこに対応するのが少々難しいです。例えば次のような場合です。
いま、「しゅ」の部分は「syu」で表示されていますが、ここで shu と打った場合の表示や、silyuやsixyu、shilyu などたくさんある打ち方にちゃんと対応できるでしょうか？
正誤タイプの実装ロジックを正しく持てば実はそこまで実装は重たくありませんが、一から考えてみると結構難しい部分かと思います（興味がある方は考えてみてください）。
ワードセットの構築
タイピングを練習するには例文が必要になりますが、開発者はこれも作らないといけません。
日本語と英語のモードがあるとそれだけで2つ分用意することになります。
さらに、語彙の難易度もある程度絞らないといけません。あまりにも専門的過ぎるワードや、打つのが難しいワードは基本的にそういう趣旨のワードセットでない限り構築しないのが望ましいです。
開発者目線で行くと、どの文字は許容するかという問題も非常に重要です。 Unity （ゲームエンジンの一つ）だと実は記号関連の判定がUS配列基準になっているので、JIS配列ユーザーに配慮して作ろうと思うと、例文で使えない記号がいくつか存在します。
また、日本語でも、日本語ローマ字入力と、JISかな入力で同じワードセットを使いまわす場合、「ゐ」「ゑ」といった文字はJISかなでは扱うことができません。この辺もワード構築の際に配慮しないといけません（ローマ字日本語でも「ゐ」や「ゑ」を入力させるワードはめったに出てこないのですが）。
長文練習の諸々
今まで、長文練習＆変換込みで練習できるサイトというのはほとんどなかったと思われます。 FoxTyping では毎パソのように長文を変換込みで打ち込み、最後に採点する、というモードを搭載しています。 これも日本語圏のタイピング練習サイトの中では結構新しい試みをしていると思います（昔、毎パソトレーナーというものはありましたが...）
実際作ってみると結構問題点が出てきました。
長文練習での採点
まず採点方法です。基本方針としては、入力された文章と課題文の差分をとればよいとわかります。 アルゴリズムを勉強している方であれば、「編集距離」の計算が真っ先に浮かぶことと思います。
要するに、入力された文章に間違いがあったら、「削除」「置き換え」「余分な文字の除去」をそれぞれ1回分の操作として、課題文と同じものにするには何回操作すればいいか？ということを考えます。
例えば、「こんにちは」を「こんんにちわ」と打った場合は、
- 3文字目の「ん」を「削除」
- 6文字目の「わ」を「は」に「置き換え」
の2回となるので、毎パソではこの操作回数だけ打った文字数から引いています。
ところで、もっと長い文章になった場合、どうやって効率よく計算するのでしょう？
それが上記のサイトで紹介されている「編集グラフ」です。
詳しいことは数学的な要素を含むので今回は書きませんが、要するに、二つの文章の差分を入れてうまいこと計算してあげると「ここは削除」「ここは置き換え」「ここは余分な文字だから除去」という情報と、最短何回の操作で二つの文章のうち片方をいじればうまくいくかを計算してくれるとっても便利なものです。
ところが、これを計算してあげるだけだと実はダメなのです。 採点の仕方はたくさんありますが、この中で一番良い得点を1つ返すにはどうすればよいのでしょうか。
例えば、"To be or not to be." という課題文があったとして、入力された文章が "To be ot" だった時、どう採点するのが正しいのでしょうか？赤文字を間違いとして、
- To be or not
- To be or not t
- To be or not
などが考えられます。 この辺は、実は考えて丁寧に処理しようとすると非常にめんどくさいです。
（毎パソの体験版の注意書きに、厳密な採点ではないとありますが、もしかするとこの辺の処理のことを指しているのかもしれないと思いました。課題文によってはソフトウェアだけだと一番高い得点を出してくれるように計算してくれない、というのを自分の手元で一度確かめた記憶があります。）
長文のふりがな
FoxTyping でしれっと実装されている課題文のふりがな機能ですが、これ実はめっっっっっっっっっちゃめんどくさいです。ただ振るだけならそこまでではないですが、レイアウトが崩れないように細かい調整をするのが大変です。
FoxTyping の長文練習の日本語では、等幅フォントを用いて、1行あたり25文字となるように計算していますが、ふりがなを振ってない状態から愚直にふりがなを付け足すと横幅が足りない、熟語をひとまとまりでルビを振ってしまったなどの問題で、上記の画像のようにいとも簡単に表示が崩れてしまいます。この辺の実装は、POWER で解決してあります。
課題文章の改行箇所指示や日本語の禁則処理
禁則処理をご存じでしょうか。簡単に言うと「文の先頭に句読点が来ないようにする」といった日本語の文章における表記のルールをまとめたものです。小学生の時に作文用紙を用いて作文するときに、「一番上のマスに『、』『。』を置かず、最後のマスの右下に入れてください」とかそういうことを教えられた方も多いのではないでしょうか。
Unity の文字入力フォーム（InputField）で日本語入力をすると、右側の文章の2行目末尾のように、うまいこと「、」が先頭に来ないように勝手に禁則処理が施されるようになっているのです。 禁則処理されないようになっていれば少しは楽だったのですが、課題文側は単純に課題文を表示するだけでなく、ふりがな機能も存在するため、課題文側をうまく調節しないと、ふりがなの有無で課題文の表示が崩れてしまうので、対応せざるをえません。
また、上記画像の左側文章の5行目のように、改行場所を示す矢印の記号も、うまく挿入する必要があるのですが、この矢印も1文字としてカウントされてしまうので、丁寧に処理をしないといけません。
禁則処理と改行位置指定と、ふりがなと1行あたりの文字数を同じにする、というのを全部実現するのが細かいこだわりであり、必須対応なんですけど、めちゃくちゃ苦労しました。
長文入力の大変なところまとめ
まとめると
- 採点ロジックが細かく詰めると大変
- ふりがなデータ入れるのめっちゃ大変
- 禁則処理が勝手に Unity 側で行われるし、改行場所をしっかり表示しないといけないし、全部丁寧に場合分けする必要があって大変しんどい
という感じでしょうか。本当はもっと大変なところがたくさんあるのですが多すぎて忘れてしまいました。
この辺の細かいことを泥臭く試行錯誤して作り上げています。
いったんはうまく動いたかな、と思ったのですが、重たくてフリーズして動かないといった報告があるので、まだまだ改善が必要です。
入力方式
Unity にもキーボード入力を判定する機構はいくつかありますが、いろいろ問題点があります。
JIS かな入力を実装しようと思うと Unity で使える入力機構では以下の点が問題となります。
KeyCode: キーを押した / 離したなど、そのタイミングごとに判定してくれるが、JISかなの「ろ」や「ー」が判定できないし、US配列基準InputSystem: 「ろ」や「ー」を識別することはできるが、フレームレート依存なので、高速で打つと打ったのに判定してくれないという抜け落ちが発生する可能性がある
さらに、WebGL でブラウザでプレーできるようにするとなると、ブラウザごとにキーの割り当てが異なるという問題が発生しました。
FoxTyping での対策は Unity をあきらめて、JavaScript の力に頼ることによって解決しています。 JavaScript に頼れば、簡単に実装できます。
この Unity に頼るのをあきらめる、というところに至るまでの回り道が長かったです。
実はまだUS配列には対応できていないので、その辺もどうにかしないといけないですが、これは追って実装しようと思います。
作ってみて
作り手に立ってみると、
- しれっと実装されているところが実はめんどくさい
- 技術的障壁や対費用効果などの問題点が見えてきた
- そもそも一人で作るにはやることが多すぎるし、技術力がないと太刀打ちできない
というのを体験できて勉強になりました。
特に3つめの一人で作るにはやることが多すぎる点については、自分自身がイラストを描いたり、過去に企画のリーダーなど、さまざまな大変なことをこなしてきたつもりですが、こればかりは本当にやることが多すぎて、どうしても対応に時間がかかってしまうのがつらいです。
自分が開発に注力する理由
実は、2020年のタイパーアドベントカレンダーの24日目では
- 読み書き能力として今後もタイピングスキルは活用できるはずなのに、肝心の練習方法がまとめられていない（本などはあるが、一般の人に知れ渡っていない）
- タイピングの面白さを一番知っているであろう、タイパー層が面白さを伝えようとしていない
という感じの批評をちらっと書いていました。
この記事を書いた当時は、この批評に対して具体的に自分がどう行動していくかについてはあまり解像度が高くありませんでした。
コロナ禍による仕事、学校のリモート化の影響でタイピングスキルが見直されつつあるような風潮を感じ取ってからは、 自分自身が特にできることとしては、やはり情報系の学生という立ち位置を活かして、開発関連のノウハウを整備していくこと、 タイパーとしての経験を活かしたタイピングゲームの開発してみんなに遊んでもらうことが一番なのではないかなと考えました。
また、ここ数年タイパー界隈と関わってきて、古参タイパーたちが数十年前の練習ソフトやゲームに練習を依存しているという点もこれを確信に変えています。
タイピングゲームや練習サイトは検索すれば実は思ったよりたくさんでてくるのですが、古参タイパーの様子をみていると、もうアップデートの入っていないソフト、練習サイトに執着しているような傾向がみられます。
これはタイパーがいろんな練習サイトを触っていないのが悪い、というのではなく、むしろクオリティの高い作品、タイパーが没頭できるような作品が少ないからなのではないかと私は思います。
あとは、自分自身、UI（ユーザーインタフェース）に関心をもって勉強をしており、既存のタイピング練習ソフトのよくないデザインや機能について普段から文句をぶちまけているのもあるので、それを全部自分の手で解決してしまいたいというのもあります。いいデザインをこちら側から提示すれば、きっと後続のタイピング練習サイト、ゲームもそれに続いてくれるのではないかという期待もあります。
以上のことから、ぼくは最近タイピングそのものの練習以上に、より快適に楽しく遊べる環境づくりや、技術者に対しての土台の整備を地道に行っていくほうにモチベーションを注いでいます。
ちなみにですが、近年だと TypingTube （https://typing-tube.net/）さんあたりがすごく開発に力を入れていらっしゃるのを見て、開発のやる気をいただいている次第です。
本当は企業がこういう開発をやってほしいのですが
最近の情報系の学生の熱心な方なら、技術力とやる気があれば時間をかければ作れないことはないと思いますが、「できないことはない」と「時間をかければ実際にできる」は全然別問題ですし、実際めちゃくちゃ大変だと思います。
正直なところ、本当はこういう開発をやるのは企業レベルに任せたほうが良い案件で、個人製作はよほどのモチベーションがある人でない限り製作は無理だろうと思っています（2021年はなぜか個人レベルで製作されたタイピングゲームが豊作ですが...）。
しかし、企業に任せるとなると今度は収益化の問題が出てきます。
2019年のタイパーアドベントカレンダーでタイピング速度測定の開発者である Healer.O さんが述べていたように、昨今、スマホゲームが無料で遊べる時代になっている以上、タイピングゲームで収益をあげる、ということは難しく、ビジネスとしてやっていくには厳しいのが現状でしょう。ソシャゲのようにガチャでキャラが手に入る！というような課金システムが確立していればタイピングゲームもたくさん企業から出されるでしょうが、タイピングゲームに課金する要素を作るとなると、より高度な機能を利用できるようになるとか、より充実したワードセットで遊べるとか、いくつか自分でも思いつくことはありますが、本当にビジネスとして成立するまで収益があげられる見込みは厳しそうに感じます。
タイピングクエストという Nintendo Switch で遊べるタイピングゲームも発売されましたが、どれほど収益があったのかについてや、現在も続けて遊んでくれているアクティブプレイヤーがどれほどいるのかはわかりません。
なぜここで苦労話を書いたか
あまり最近はクリエイティブな活動をしていませんが、ツイッターでイラストを描かれる方が「アイコンくらい無償で描けよ」「絵なんてすぐ描けるでしょ」などと言われて悲しい思いをされているのを見かけて、自分もクリエイターとしては他人事ではないなと感じています。
タイピングゲーム開発だって、どの練習サイト、ゲームであれ開発にどんなに少なく見積もっても数週間～数か月、ものによっては年単位でかかってるものなのに、全然その辺の苦労が隠蔽されているような気がします。リリース後になると途端に開発者はいいコメントも悪いコメントも受けることになりますが、この時にいいコメントばかりをもらえる開発者も少ないわけです。大半はユーザーからのバグ報告になってしまいます。
もちろん、開発者側が十分なクオリティのものを提供していないのが悪いこともありますが、開発者側は悪いクオリティのものを出そうと思っていませんし、最初からバグを完全になくして開発を進めることはほぼ不可能です。バグ報告は真摯に受け止めて改善していけばよいですが、あまりにもユーザー側から批判コメントばかりが殺到するようだと、開発者も人なので、開発モチベーションが落ちてしまうことでしょう。
なので、この辺の苦労話を少し赤裸々に打ち明ける機会が一か所くらいあってもよいのではないかなと思い、今回記事にしてみました。 人によってはいわゆる「忙しいアピール」みたいにとらえる方がいらっしゃるかもしませんが、それはしょうがないかなと思っています。
また、これからタイピングゲームを作ろうと思っている方は、基礎的なゲームの土台は（知識やスキルがあれば）短期間でそれなりにできますが、新しさを突き詰めようとするとものによっては莫大なコストがかかることをしっかり覚悟したうえで臨みましょう。
おわりに
機能開発って一本道でできるわけじゃないんだな...とか、開発者ってやること多いんだなっていうことを感じていただければいいなと思います。
タイパーアドベントカレンダーは今年で3年目の参加となります。年々執筆内容に気合が入ってしまってなかなかライトに読めるものじゃないのですが、あたたかく見守っていただければ幸いです。
ベータ版をリリースしてから、たくさんのバグ報告が上がっており、日々それを修正しています。 なかなか大変ですが、テストプレーしてくださった方への感謝の気持ちや、ツイッター上でいただけた「新しいタイピング練習サイトをつくってくれてありがとう」の言葉で、製作者はモチベを保てています。むしろ、誰もプレーしてくれず、何もフィードバックが得られないのではないかという不安のほうが大きかったので、ここまで熱心にバグ報告や機能改善の要望を列挙してくださったのは大変幸せ者だなと感じております。この記事を通して感謝申し上げます。本当にありがとうございます。
12/4 はTEA_R@xan さんの 標準運指から始めなかった初心者タイパー＜1年目＞ です。
前日の記事：
