前回の続き。

　作業が思うように進まなかった原因は、個人的な事情だけでなく方法それ自体も悪かったんじゃないか、と前回締め括っていた。じゃあ具体的にはどういう問題があったのかというと、これがなかなか難しい。

　今回改訂した点は多岐にわたるので、網羅的な列挙は不可能だけど、ひとまず着手したときの考えに限って言えば、（1）テキストや演出などイベント周りの改訂、（2）ゲームバランスの改善、のふたつをやりたかったのは確かだ。「それじゃあほとんど全部じゃん」と言われそうだが、変えなかったところはちゃんとあって、たとえばプロットや設定は変えないようにした。ほかにも高校のころの自分がどんなことを考えていたかとか、そういうのが表れている部分はなるべくそのまま残しておいた。

（1）テキストや演出などイベント周りの改訂

　初版は、「人にテキストを書いてもらう」→「チェックして、確認をとる」→「確認がとれたらエディタに入力する」という手順で最初はやっていた。「チェック」というのは、誤字脱字衍字だけでなく、イメージと違うとか、マップはどういう配置なのかとか、この言い回しはどうなのか、このキャラはこんなことを言うのか等々の確認なのだけど、まあ案の定、確認は徐々にとらなくなった。

　単純に手順として煩瑣だったというのもあるけれど、それ以上に「コメント見て！」って言ったのに見てくれなかったりとか、連携がうまくとれなかったのが最大の要因だった。いまならGoogleドキュメントか何かに書いてコメントをつけていく、といった方法がとれるだろうが、制作当時は2010年とかで「世の中にはクラウドというすごいものがあるらしい」ぐらいの認識しかなかった。だいたい52万字にもなると、クラウドを使おうが使わまいが、人間がふたりで管理するには少々手に余る量だろう。共同制作でテキストをどう管理するのがベターなのかは正直いまもわからない。

　なお余談だが、テキストは「NanaTree」というアウトラインプロセッサを使って編集していた。Evernoteなどがある現在となってはもう使う意味はほとんどないと思うけど、複数のテキストをツリー化して、一元的に管理できるのはとても魅力的だった。ひとつのテキストが一定字数（4096字ぐらい）を超えると挙動がやや不安定になるという欠点はあったものの、便利なのは間違いなかったし、ゲーム制作以外にもさまざまなネタをストックしておくノートのように愛用していた。ファイル自体は残してあるので、今でもときどき見返している。

　初版のテキスト処理についてはだいたいこんな感じだったと思う。で、改訂作業ではどうしたのかというと、じつは正直あまり特筆に値することはない。

　当たり前だが、52万字近くあるテキストを全部チェックするのは厳しい。制作ツールは「RPGツクールVX Ace」だけど、こいつには検索機能も置換機能もない。頑張ればゲームデータ内の「文章の表示」コマンドを全部テキストに出力することもできるらしいが、これは使わなかった。もちろん「御前」を「お前」に全部直したいとか、表記ゆれのチェックとか、そういう目的にとっては有用だけれど、今回のテキスト改訂はそういうわけにもいかない。冗長な表現を削るとか、言葉足らずだったところを補足するとか、そういうのが主目的だったからだ。それに、テキストだけではなく演出も調整したかったから、結局は（2）のゲームバランスの改善と併せて、「とりあえずプレイしてみて気になったところを片っ端から修正していく」という何の工夫もない力技をとってしまった。

　ところがテキストの改訂というのは、なまじ手軽にやれてしまうところがあるせいで際限がない。今回のように制作が長期化すると、言語感覚もかなり変わってくるので、間が空くたびにかなり修正したくなってしまう。このへんは短期的にカタをつけてしまうのが正解だったんだろうと思う。

　演出の改訂にしても、なるべく深入りしないようにしたものの、かなり時間をとられてしまった。とくにウェイト処理については肌感覚で調整しなければならないし、（SFCごろのRPGや多くのツクール作品にみられる）人形劇的な動きも、キャラクターが何マス移動するか、それはどれぐらいの移動速度・移動頻度なのかなどを決めなければならず、かなり苦労させられた。マップデザインも考慮しないといけないし、移動するマスの数や移動スピードを計算するのはとにかく面倒だ。もちろんうまく完成したら嬉しいけど、これについては苦痛のほうが上回るのでやりたくない。動作確認が本当につらい。

　他にも大変だったことはあるけど、「テスト中にひとつでも気に入らない箇所があったらすぐに修正しないと落ち着かない」という自分の性格がいちばん面倒だったかもしれない。落ち着かないのは気の短さみたいなものもなくはないけど、修正したい点をちゃんと覚えてられないのが大きい。ツクールはテストプレイ中エディタを操作することができないので、初版制作時はすぐにゲームを閉じて修正していたが、これではあまりにも進みが悪い。今回の改訂作業時はツクールのテストプレイ機能を使わずに、「Game.exeを直接起動してプレイしながら適宜ツクールで修正していく」というやり方で対処した。これはけっこう良かったと思う。

　プレイ中にデータを編集するとか大丈夫なの？って人もいるかもしれないけど、大丈夫です。ツクール製ゲームがたとえばフレームごとに読み込みながら実行しているみたいな仕様であればちょっとヤバいかもしれないけど、マップならマップに入ったタイミングで、データベースならタイトル画面に遷移したタイミングでロードされるので、それに合わせていれば心配はまったくいらない、はず。そんな都合の悪いタイミングで保存することってかなり頑張らないとできないだろうし。いや、万が一破損したりしたら責任とれないからアレだけど……でもこのやり方で五年ぐらいやってて、いちどもデータが壊れたことはないので大丈夫だと思います。試す場合は念のためバックアップもとっておいてくださいね。

　とまあ、演出周りは画面の色調とか選曲とか効果音とか、ほかにも書いておきたいことはいろいろあるけど、このへんで。

（2）ゲームバランスの改善

　初版がどんなバランスだったのかを振り返るのは恥ずかしいのだけど、一言でいうと「高難易度」志向だった。「そりゃおまえセラブルの影響なだけだろ」って言われたら、まあ否定はしづらいのだけど、ちょっと違う。いずれちゃんと言葉にしておきたいのだが、（いわゆるマゾ仕様とかそういうのではなく）ゲームオーバーになるのが面白いゲームを作りたかったのだ。ゲーム作ってみたいと初めて思ったときからこれは一貫している。

　で、実際できあがった作品はどうだったのかというと、ハチャメチャでした。とにかくバランスが悪かった。負けてもなんで負けたのかいまいち分析できないし。高難易度とか言っといて運ゲー。ゲームにとって運は重要だと思うけど、それにしてもね……レベルデザインとかも考えていなかっただろと言いたくなる出来。

　そういうわけなので改訂にあたっては、「RPGが初めてでもクリアできそう」ぐらいを目指すことにした。もうちょっと具体的にコンセプトを言うこともできるけど、ゲーム公開前に種明かししてしまう感じになりそうなのでやめておく。そのうち書くかも。

　あとホントに不評だったのが属性と状態異常。これは改訂前に自分でも「気持ち悪すぎるな～」と思ってしまうぐらいダメダメだった。何がダメなのかというと意味もなく多かったり体系があまり一般的ではなかったりするとこ。というわけで、まずはそこをスッキリまとめてしまおうと決めた。が、ゲーム作ったことのある人なら想像がつくかもしれないけど、これはけっこうな大改訂で、属性や状態異常を変えるというのは、要は技や装備も全部手を加える必要があるので、結果的に初版とはかなり別物になってしまった。

　とはいえ、これでもあまり深入りはしないようにした。たとえば「最初のダンジョンは事実上の属性チュートリアルの役割を担っている」みたいなのを決め始めると、完全にプロットとの相談になってくる。だいたい、ちゃんとバランスを整えようとしたら、ダンジョンの数や敵の種類、どういうグループで出現するか、どれぐらいサイズのマップをどれぐらい歩かせるか、など考えなければいけないことは尽きない。かなり不満点は残ったままだけど、まあ高校のころの自分が悪い。

　という具合になるべく作業が軽くなるように多くのことを諦めたつもりだったけど、長いゲームなのでそれでもつらかった。次なにか作るときはExcelとかもっと使おうと思う（いちおう改訂作業で使ってみたけどぜんぜん活用できなかった）。長編RPGは当分作らないと思うけど、ある程度小規模の作品でそういう方法を（長編制作を見据えてモジュール的に）確立しておくのは大切だろうし。だいたいツクールのデータベースって高級で作っていて楽しいように工夫がされていると思うけど管理にはあまり向かない。

　書きたいことはまだまだあるけど、長くなってきたし（2）についてはこのへんにしておこう。中途半端かな。

　しかし（1）にも（2）にも言えることだけど、デバッグに時間を割きすぎなのではと思った。ゲーム制作の肝はデバッグにあると考えているが、これはデバッグの回数を増やしたらいいという話ではなく、むしろ最小限の回数・負担で済むように仕様を考えたい、ということだ。たとえばイベントシーンの動作確認にしても、いちいちプレイヤーの初期位置を設定したり、イベントシーンのマップに移動するためのイベントを作ったりするのは面倒すぎる。初めからもっとスムーズにできるよう設計しておきたい。戦闘のテストもそう。ツクール側でバトルテストは用意されているけれど、デフォルトと少しでも違った装備システムだったりするとまったく使えない。もっとお手軽テスト機構を用意したい。

　あと、正直作業が滞っていたのはそもそも方法がちゃんと整理・確立されていなかったせいだと言っても過言ではないように思う。今回書いていて、かなり行き当たりばったりでやっていたのだろうと思わされた。何事も雰囲気でやるのは安定しない。コンディションが多少悪くても再現可能なように方法をきちんと言語化しておくこと。ちょっと作業から離れて戻ってきたときに「あれ、これどうやるんだっけ」ってなるのがいちばんダメ。制作記録とかちゃんとつけたほうがいい。