Research
プログラマは要らない
恋愛ゲームNextage 第8回
0.概要
標準的なアドベンチャーおよびノベルタイプの恋愛ゲームにおいて、プログラムの出来は、使いやすくて当然であり、出来が酷ければ叩かれる一方で、よく出来ていてもほとんど評価の対象とならない。メーカは、プログラムに無駄なリソースを割くことなく、自らの「ウリ」に集中すべきである。
2002/07/20初版
1.プログラマは報われない
先日、恋ZEROはプレイアビリティ2002年基準「Playability2002」を提案した。アドベンチャーおよびノベルタイプの恋愛ゲームでは、読むテキストの量も多く、快適なプレイ環境が重要であるにも関わらず、十分なプレイアビリティを確保できていないゲームが少なからず存在している、という思いが強いためである。
プレイアビリティはどうすれば改善されるだろうか。現在のほぼ全てのアドベンチャーおよびノベルタイプの恋愛ゲームは、シナリオスクリプト、画像、音楽、音声といったデータと、それを再生するシナリオスクリプトエンジン（以下単にプログラムとする）で構成されており、プレイアビリティの大部分は、このプログラムの出来、すなわちプログラマの腕にかかっている。
そしてこのレベルでのプログラムの出来不出来というのは、判断基準が極めてはっきりしている。絵やシナリオの場合、人によって好みがあり、ある程度普遍的な上手下手は存在するにせよ、それ以上に、自分はこの人が好きだが、他の人はそうではないといったように、個人差が大きい。しかしプログラムの出来はほとんどがその機能が「ある」か「ない」かである。バックログ機能がないよりある方がいい。セーブ数は多い方がいい。重いプログラムより軽い方がいい。こういった良し悪し（「好き嫌い」になっていないことに注意）は評価軸が1次元であり、どんな機能を重視するかといった違いこそあれ、万人が共通である。
プログラムの完成度が1次元と言ってしまっても構わない以上、ユーザは一旦出来の良いプログラムに出会うと、出来の悪いプログラムは耐え難くなる。その一方で、プログラムはプログラマがかわいそうになるぐらいに、全くと言っていいほど評価されない。確かに、バグが多かったり、必須機能が欠けていたりすると、こっぴどく叩かれる。しかしそれ以前に絵なりシナリオなりに魅力がなければ、そもそもそのゲームは見向きもされない。話題になるのは、昨年の「秋桜の空に」のように全体としては評価の高い作品であってかつプログラムが酷い場合であり、いくらプログラマが頑張って素晴らしいスクリプトエンジンを作ろうとも、話題にかすりもしないのである（話題にもならないのでそもそもそんなプログラムがあるかどうかも分からないが）。
いいモノを作るのに技術は当然必要だが、同じくらいに作る人間のモチベーションが重要だ。しかし標準的なアドベンチャーおよびノベルタイプの恋愛ゲームに要求されている機能は先に「Playability2002」で挙げているようにすでにほぼ固まりつつあり、創造性を発揮する余地も限られている。それでいて頑張っていいモノを作ってもまるで評価されない。これでプログラマのモチベーションを高めろという方が無理と言うものだろう。品質が低下するのも当然だ。
2.車輪の再発明は要らない
前項で書いたように、プログラムは恋愛（ビデオ）ゲームにとってなくてはならないが、恋愛ゲームの価値を生み出す源泉ではない。少し前に「コアコンピタンス」という言葉が流行ったが、要はあなたのメーカは、あるいはその作品は、何がウリなんですか、と言うことだ。それも他のメーカでは提供できないものでなくてはならない。「ウリ」は、絵であってもシナリオであってもエロであっても何でも構わない。他社がマネできない「ウリ」を徹底的に追求していくことが、恋愛ゲームメーカや恋愛ゲームが氾濫している状況では必要になってくる。そして、プログラムが「ウリ」たりえない以上、そこにリソースを割くのは勿体無い。そう考えると、現状のそれぞれのメーカが独自のスクリプトエンジンを作っている状況は全くもって不思議と言うしかない。ただ要件を満たしたプログラムを外部から調達してくればいいはずだ。
多様性が損なわれる？ それもおかしな話だ。OSのような完成形が未だ見えていない複雑なシステムとは訳が違う。恋愛ゲームに求められているシステム要件は明確であり、それを実装した、似たようなスクリプトエンジンが何十と存在している必要が本当にあるのか疑わしいものだ。困ったことに、プログラマと言う人種は得てして他人が作ったコードを使いたがらず、イチイチ自分で作りたがる。車輪の再発明はバグを作り込みやすいだけで単なる工数の無駄である。もしかしてこの手のゲームの経営者は人件費はタダというつもりなのだろうか。
とはいえ、独自開発に全く見るべきものがないという訳でもない。スクリプトエンジンを自社開発および外部調達する場合のメリットとデメリットを表1にまとめた。
| - | 独自開発 | 外部調達（汎用エンジン） |
|---|---|---|
| メリット |
|
|
| デメリット |
|
|
確かにアージュのAGESやLittlewitchのFFDのように、演出力を強化するため、特殊な演出効果を出すためということであれば独自開発する納得性も高い。しかしそこまで到達できない、あるいは到達する必要がないのであれば、外部調達（汎用エンジン）のメリットの方が遥かに上回るだろう（注1）。必然的に、プレイアビリティも一定水準以上のものが期待できる（しかもメニュー体系が同じなので操作が分かりやすいというオマケつきだ）。
理想的には、アドベンチャーゲームやノベルゲームを実現するオープンソースプロジェクトが生まれてくれば面白い（注2）が、現状でもNScripterという選択肢がある（商用レベルに耐えられるのは今のところ他にはない？（注3））。お世辞にも十分に快適なシステムとは言いがたいが、1から作るよりはずっとマシだ。コンテンツさえよければ十分にカバーできることは「月姫」や「みずいろ」が実証済みである。
以上見てきたように、特別なことをしたい場合や、長期のチーム育成計画を立てている場合を除いて、スクリプトエンジンは買ってきた方が安く、そうなってくればプログラマは要らない。スクリプタだけで十分だ。悪しき自前主義を排そう。評価に繋がらない部分は、外部から調達し、浮いたリソース（特に予算）を、自社の「ウリ」につぎ込んで欲しいところだ。
注1 有志による他OSへの移植が期待できる、というのは少々補足が必要かもしれない。世の中にはスキルの高いプログラマがいるもので、人気の高いゲームのスクリプトエンジンは、しばしば他のOSに移植されている。千熊屋氏の娯楽用アプリケーションの異機種間データ共有の試みが詳しい。「データが大事なのです。実行バイナリではなく。」とタイトルにあるが、御意。
注2 ソフ倫もたまにはユーザのためになること、しませんか。
注3 北楽師門氏のDigital Novel Streetにまとまっている。（追記(2003/10/31): 現在は閉鎖。旧サイトは残されている。）