土屋つかさの技術ブログは今か無しか

土屋つかさが主にプログラミングについて語るブログです。

ゲームプログラミングが内包する課題に対する司エンジンのアプローチ(4・完結)

【司エンジン( https://github.com/t-tutiya/tsukasa )の特性について:ゲームプログラミングが内包する課題に対する司エンジンのアプローチ】の その4 です。引き続きデータ的な根拠はありませんのでよろしくです。

 今回で完結です。予定したのより5倍くらい長くなったのですが、おかげで土屋がこの10年間考え続けてきた「ノベルゲーム開発が抱える課題」をほぼ全部言語化することができました。お読み頂いた皆様に感謝!><

4・(補足)ノベルゲームに指向している理由と汎用エンジン化への拡張

 現在、司エンジンはノベルゲームの開発に指向して設計されていますが、将来的には汎用ゲームエンジンに進化させていきたいと考えています。
 なぜ現在ノベルゲームフレームワークとしての実装を優先しているのかというと、そもそも著者がノベルゲームを作る為に始めたのが司エンジンだというのもあるのですが、それとは別に、汎用ゲームエンジンを設計するにあたり、ノベルゲームのアーキテクチャを分析することが重要ではないかと考えているからです。
 日本では吉里吉里NScripterというノベルゲームエンジンの偉大な先達が存在し、とても手軽にノベルゲームを作れる環境が存在しました。この二つのエンジンはノベルゲームアーキテクチャデファクトスタンダートとなり、多くのフォロワーも生まれました。
 しかし、逆にこの二つがあまりに高性能で、移植の難易度もそれほど高くなかった為に「他のゲームジャンルに比べて、ノベルゲームのエンジンを実装するのが簡単ということはない」という事実がこれまで見過ごされてきたのではないかと著者は考えています。また、この問題がスルーされてきた問題が、ゲーム開発全体に影響していると考えています。
 ここでは補足として「カットシーンの普遍性」「文字列を出力することの難しさ」「データがフローを持つプログラムの特殊さ」の3点にわけて、ノベルゲームエンジンを実装する難しさ、そして、めざすべき汎用ゲームエンジンを考えていきたいと思います。

A:カットシーンの普遍性

 カットシーンというのは、RPGなどのゲームにおけるイベントパートのことを指す用語です。ポリゴン紙芝居と言われることもありますが、今はカットシーンが一般的かと思います。
 カットシーンはユーザーに物語の進行を説明する役割を持ちます。2Dではキャラ立ち絵、3Dではポリゴンとモーションを任意タイミングで変更し、セリフを表示したりボイスを喋らせ、背景やエフェクトを演出に応じて切り替えます。
 大抵の場合において、カットシーンの進行中はユーザーからのインタラクションは進行ボタンくらいしか受け付けません。要するに、カットシーンの構造は、ノベルゲームエンジンその物なのです。そして物語を持つタイプのゲームにおいて、カットシーンが存在しない物はほとんどないと思います。
 だから、ノベルゲームエンジンの完成度を上げ、カットシーンの開発コストを下げることは、ほぼ全てのゲームジャンルにとっても意義のある事なのです。

B:文字列を出力することの難しさ

 最近の商業ノベルゲームには、文字が数フレ遅れで1文字ずつフェードインしながら表示されるタイプの作品があります。画面上の文字列がすうっと浮かび上がる演出が美しく、ベタに文字を表示するよりも明らかに画面映えがします。
 このフェードイン処理は、一見それほど難しいロジックには感じられませんが、汎用的に作り込もうとすると様々な実装上の問題が発生します。なぜ難しいのかというと、1文字ずつが個別にフェードインする場合、それはつまり全ての文字がゲームキャラと同じ処理を要求するという事だからです。
 極端な例で言えば、仮に横20文字×縦12行で画面を構成するノベルゲームを作る場合は、文字表示だけで240個のオブジェクトが非同期的に動作するゲームを作るのと、難易度では差がない訳です。
 余談ながら、このフェードインは未改造の吉里吉里では実現できない筈です。対して司エンジンでは、個々の文字の表示開始、表示中、表示終了時のアクションを、スクリプトで記述することができます。

C:データがフローを持つプログラムの特殊さ

 ゲームプログラミングではシーン管理という概念があります。インターフェイスの形式が異なる画面ごとにシーンという単位でコードを区切り「メニューシーン」「ムービーシーン」「マップ移動シーン」「バトルシーン」「コンフィグシーン」のように作業分担を行います。
 「シーン」は、ビジネスアプリで言う「画面」とは論理単位の区切りが微妙に違います。というのも、例えばマップ移動シーンからコンフィグシーンに移動する場合も、背後ではBGMが常になっていますし、FPSのようにマップ移動からコンフィグに遷移してもマップ移動が停止しないタイプのゲームもあります。このようにシーンが並列実行されるのもゲームプログラミングが複雑になる原因の一つです。
 ノベルゲーム(カットシーン)ではこれに加えて、シナリオスクリプトがシーケンシャルに構成されるという特徴があります。ノベルゲームでは、画面に出力するテキストと画面演出指示が記述されたスクリプトを、ゲームエンジンが逐次パースして実行します。同時に、ユーザーの入力が必要になる際は、そこでパースを一時停止しなければなりません。
 スクリプトはそれ自体がプログラムなので、このエンジンのパース&一時停止の処理は、「2」で説明したコルーチンが持つ問題が同じように発生します。更に、先述したシーンの並列実行も同時に発生し、ゲームプログラミングは無限に混沌化していくのです。


 先に書いておくと、これらの問題全てを司エンジンが解決しているわけではありません。また、司エンジンではそもそも対応する予定のない課題もあります。この記事で提示された課題が共通認識となり、今後のゲーム開発環境構築に多少なりとも貢献できたなら、嬉しいです。