「Stellaris」開発日記#240――3.3でのスクリプトの改良

「Stellaris」の開発日記#240が公開されていましたので、その内容をご紹介。今回は3.3でのスクリプトの改良について。3.3リリース前の開発日記です。

前回：開発日記#239――AI

開発日記

開発日記#240は、3.3でのスクリプトの改良について。

• 今回は3.3でデビューするとてもスクリプトの素晴らしい改良について（オープンベータで試すことができる）。

スクリプトの値

• まずウェイトに関する話題から。つまり上のようなもののことだ。私たちはこのスクリプト構造の下にあるコードに一貫性がないことに気づいた。エンドユーザーであるスクリプターにはわかりにくいコード実装が多くあった。例えば、あるものは「factor」や「add」、あるものは「factor」や「weight」と入力していたが、そうすると時にはbase値を0に設定したときにゲームが1と認識したり、AIの性格では「factor」が「add」とカウントされたりした。
• 解決策はすべてのバリエーションを削除してひとつのコードに統合することだった。既存のバージョンの特異性を包含する（つまり膨大なスクリプトを壊さない）必要はあったが、ひとつのシステムにすることでゲーム内のあらゆる場所で使える改良を行える。
• 当初は問題があったが実施可能であることがわかり、私たちはさまざまな場所で異なる動作をするフィールドについて心配しなくてよくなった。基本的に残された違いは既定値が0か1かの違いだけだ。
• これをやったことで、システムにさらにいくつかのものを追加できた。例えば、減算・除算・剰余演算・最大・最小・絶対値・丸めなどを追加した。また、トリガーではなく常に適用されることを意図する場合はこうしたものを「modifier = {}」にする必要がなくなった。
• 3.3では「CVariableValue」というコンテナを作り、いくつかのオブジェクトを格納できるようにした。
  • 整数または固定小数点
  • スコープ/イベントターゲット
  • トリガー
  • 補正の定義
  • 変数文字列
  • スクリプトの値（これについては、後で説明する）
• 基本的にゲームがスクリプトの値を読むときはいつも、それがなんなのかを起動時に判断する。つまり、実際の値が必要なときは常に、単に値を与えるか、指定されたトリガーを呼び出すだけでよい。偶然にも、このシステムによって「trigger:<trigger>」を使用する機能をさまざまな場所で容易に展開できるようにもなった。
• Mod制作者のみなさんは私たちが途中で可能にした他のことにもお気づきだろう。まず「trigger:<trigger>」と同じように「modifier:<modifier>」を呼び出せる。Popが降伏度+20%の補正を適用されている場合、「modifier:pop_citizen_happiness」を使うと0.2を呼び出せる。
• 追加したもののもうひとつはスクリプトの値だ。これは新たなパラド社開発スタジオのゲームから得たアイディアで、その優れたスクリプト計算能力の要点は必要に応じて一連の計算を実行できるキーに値を代入できることだった。つまり「my_script_value」を57 + ( 24 * num_pops ) / num_coloniesとできるようなことだ。

• こうした「スクリプトの値」は最初に触れたようなweightのフィールドとなり、script_valuesディレクトリにおけるキーによって定義される（上がその例）。こうするとゲーム内のどこでも「value:leader_cost」で参照でき、必要に応じて値を計算してくれる。私たちはこれがゲームのスクリプト改良に非常に役に立つと気づいた。正しい値を取得しやすくなるだけでなく、weightフィールドにコピペされたスクリプトを大幅に削減できる。
• 便利なことに、スクリプトの値はトリガーと同様に読み込まれるため、パラメーターを与えることができる。例えば、value:my_value|PARAMETER|50|とすると、ゲームはすべての「$PARAMETER$」インスタンスに50を代入したスクリプトの値my_valueを使う。

• スクリプト言語にはまだ2つ追加できることがあった。ひとつはscript_valueとweightフィールドにcomplex_trigger_modifiersを追加したことだ。これは「trigger:<trigger>」で使うには複雑すぎるトリガーの値を使用できるようにするものだ。上がその例。
• これはexport_trigger_value_to_variableと同じトリガーで動作する。また、こうしたものにいいくつかのトリガーを追加した。特に、すべてのcount_xスクリプトリストのトリガー（例：count_owned_planet）と、「distance」トリガーだ。
• スクリプトの値でできることについての包括的なガイドをこの投稿に添付しておく（common/script_valuesにもある）。私たちはこの方法で、アンロックしたアセンションパークの数に応じて先住民のモニュメント（Autochthon Monument）の統合力（Unity）ブーストを変動させている。このリストはリリースごとに増えていく予定だ。

Modの上書き

• Mod制作者はゲームの各要素が上書きをどのように扱うかについて長く困惑させられてきた。残念ながらまだしばらくはそれが続きそうだが、なぜこのような問題が発生するのかを知っておくことはみなさんにとって興味深いことだろう。
• Mod制作者がバニラのファイルを上書きするとき、ファイル全体を上書きするか（これは常に機能する）、ファイル内の個々のエントリー（例えばminerの職）に上書きすることもある。ゲームが既存のエントリーのキーと一致する2つ目のエントリーを見つけたとき、さまざまなことが起こる。
  • 既存のエントリーを完全に置き換える（最後に読んだものを使う）
  • 既存のエントリーを置き換えるが不完全で、例えば職を上書きしたときに補正で参照できなくなる
  • 2番目のエントリーは無視される（最初に読んだものを使う）
  • 最初のエントリーと2番目のエントリーの両方が保持される
  • 既存のエントリに中の情報を追記する（on_actionの特殊なケース）
• なぜこのようなさまざまな動作をするのか？　C++のコードでどのようにデータベースを読み込むかという問題が大きい。ゲームがスクリプトファイルに出会うと、原則としてゲームはそのオブジェクト（例えばminer = { }）を読んで一致するデータベース（例えば職業種別のデータベース）に格納し、ゲームはその一致するオブジェクトタイプでなにかする必要があるときにさまざまな方法で使用する。
• ゲーム内でもっとも古いオブジェクトの多くの場合（技術や志向などリリース前からほぼ現在の形で存在しているもの）、カスタムメイドのデータベースにオブジェクトとしてコード化される。このデータベースを読むためのコードは新しいオブジェクトが定義されるたびに新しく書かれる（またはコピーされる）ため、ファイルを読む順番（AからZ、またはZからA）や重複の扱い方が異なることがあり、理想的ではない。
• ある場合ではこれは理にかなっている。例えば、on_actionsでは特別な処理を行う正当な理由がある。この意図はMod制作者がバニラの内容を気にせずにon_actionsを使えるようにすることだ。これは外交行動のようなコードに大きく依存するデータベースのケースでもあり、単にエントリーを追加して、コードがそれをどうするものかわかっていることを期待することはできない。
• ほとんどの場合、これは単に技術的負債の問題だ。現在では私たちにはデータベースでコーディングするもっといい方法がある。また、Mod制作者にとって最も重要なのは、既存のオブジェクトを削除して新しいオブジェクトに置き換えることで上書きを処理する点だ。これはMod制作者にとっては通常いい動作だが、そうではないケースもあり、職・区域・惑星クラスなどの場合は補正が壊れる。ここで起こっているのは、職が補正を作り、それがa) 補正データベースに追加され、b) ゲームの職の定義（スクリプトファイルではなく、プログラムがスクリプトファイルを読んで得たもの）に格納され、ゲームがその補正に効果を与えることができる（例えば、この職をx個もたらす）ということだ。
• その後その職は削除され、新たなものが作られ、これも同じように補正を作る。しかし、今度は補正のリストに同じキーを持つ2つのエントリーができることになる。スクリプトファイル内でそのような補正が使われるとき、ゲームはリストを見て最初にマッチしたものを見つけ、それが意図されたものであることを前提とする。だが残念ながら、その職は2番目の補正が適用されると考えている。その結果、この補正はMod制作者の意図と目的の点では使えないものとなる。
• しかし、私たちはこれを修正した。こうしたオブジェクトは安全に上書きできるようになったか、少なくともこれが上書きに失敗する原因にはならない。職や区域はおそらくもっとも改造したいオブジェクトなので、Mod制作者にとってとても便利なはずだ。
• Mod制作者向けに小さな贈り物もある。上書きに関する警告のエラーログメッセージはあいまいさを取り除くために正確に使用されているものを指定するようになった。
• 余談だが、3.3オープンベータのフィードバック期間を2月7日まで延長した。オープンベータブランチは3.3リリースまで残しておくので、現在プレイされている方は3.3リリースまでゲームを続けることができる。

質疑応答

Q：つまり3.3は月曜リリースなの？

A：違うが、ベータにはほとんどの変更が含まれている。

来週はオープンベータに関する考えについて。

次回：開発日記#241――統合力のオープンベータとthe Dev Clash