devdiary/030

原文
Simulationian.com

イベントスクリプト

同志の皆さん、別の開発日記へようこそ！今日は、CK3のイベントの構造、それらがスクリプトでどのように組み立てられるか、およびCK2とどのように異なるかを見ていきます。

イベントの構造

標準のキャラクターイベントのコアは、お馴染みのスタイルです。イベントのタイトル、説明、そして通常はポートレート、下部に1つ以上の選択肢があります。

ただしスクリプトでは機能性、読みやすさ、およびスクリプト全体の可読性の改善を目指して、いくつかの点を変更しました。以下は、CK2とCK3でのイベントの開始の比較です。

最初に気付くのは、イベントタイプとイベントIDを入れ替えたことです。これでイベントはネームスペース（各ファイルの先頭で定義されています）と一意のID、およびイベント内で定義されたタイプによって作成されます。逆ではなく、つまりイベント自体を折りたたんだ後でも、イベントIDを読み取ることができます。

次に、トリガーされたテキストの動作を変更しました。CK2では、これはフレーバーがプレーヤーの状況に適切にローカライズされることを保証するための本当に便利なツールであり、ユニークさを保ちながらイベントを非常に広く適用できるようにします。ただし、トリガーされるテキストを簡単に相互排他的にする方法がなく、時々次のような状況につながるため、少し面倒になる可能性があります。

世界で最悪というわけではありませんが、私たちが実際に何をしたいのかについてはかなりぎこちないです。

CK3では、トリガーされたテキストブロック内のfirst_validブロックを使用して（図の最初の画像のように）、一連の条件を満たすリストから最初のエントリを選択することで、これを削減できます。これは、トリガーされたテキストブロックがトリガーに従って常に相互に排他的であることを確認する必要がないこと（およびトリガーされたテキストの数とともに複雑さが増す傾向があるもの）の代わりに、適切なテキストに従って論理的に優先テキストを順序付けることができることを意味します単純なトリガー。

たとえば、フランス語の文字、アシャリの文字、80歳以上の文字のコピーが異なるトリガーテキストブロックがあり、それらのカテゴリに該当しない人のためのフォールバックがある場合、次のようなスクリプトを作成します。

これにより、リストが自動的に下に移動します。フランス人のキャラクターはあるものを見、非フランスのアシャリは別のものを見、80歳以上の非フランスの非アシャリは3番目のものを見、そして他のすべての人は4番目を見ます。これにより、状況に応じた新しいコピーをイベントの説明とタイトルの両方に非常に簡単に追加できます。

さらにマイナーなポイントですが、トリガーされたテキストも上位ブロックの本文内に保持されるようになったため、その場で並べ替えるのがはるかに簡単になりました。トリガーされたテキストがいくつあっても、クリックするだけでファイルの本文を折りたたむことができます1ダース以上ではなく、選択したエディター。クリック数を最小限に抑える場合、少しでも役立ちます。

イベントのテーマと背景

CK3形式の注目すべきいくつかの欠如は、画像と境界線ブロックです。

まあ、それは正当な理由があります！これらは主に新しいイベントテーマシステムに組み込まれています。これは、上記の最初のCK3スクリプトの例で確認できます。

テーマは、左上に表示されるイベントアイコンを決定するものであり、幅広いテーマのイベントのセットをグループ化し、イベントに関連することが期待できるものをプレーヤーに知らせるのに役立ちます。また、状況に応じて変化するデフォルトの適切な画像の背景（それ自体がキャラクターのポートレートで使用される照明を設定します）と、周囲のSFXのさまざまなセットも提供します。

より適切なものを表示する必要があると感じた場合は、必要に応じてスクリプトの手動行を介して背景とテーマのアイコンをオーバーライドできます。そのため、システムは、作業の量を減らすように設定されていますが各イベントに追加のフレーバーを追加しても、必要な場合に実際に含めるフレーバーを完全に制御できます。

言うまでもなく、イベントテーマは完全にスクリプト化可能です。好きなアイコン、デフォルトの背景、キャラクターモデルのライティング、アンビエントSFXを変更したり、テーマを簡単に作成および調整したりできます。

ポートレートとアニメーション

良いもの！新しいシステムのポートレートは、驚くべきことに、CK2の場合よりもいくぶん動的であり、特定のイベントでは、合計0～5個のポートレートが存在する可能性があります。これらのうち、2つは完全にアニメーション化され（それぞれ左と右に配置されます）、3つはイベントの下部に沿って均等に並べられたヘッドショットです。これらは、あなたが取得したい任意の組み合わせで使用することができますちょうどイベントのために右を見て。

左と右のポートレートでは、リリース用に作成されたかなり幅広いアニメーションを使用できます。ヘッドショットはアニメーション化されず、代わりにイベントの説明で言及されている補助キャラクターを視覚化できます。

すべてのアクションについて！

すべてのイベントはどこかから発生します。CK2（特にタイトルのライフサイクルの初期）では、これは平均発生時間システムを通じて行われることが多く、イベントが（通​​常）ヶ月で起動するのにかかる時間を大まかに定義できます。残念ながら、非常に多数のイベントを相互にバランスさせる場合、このシステムの柔軟性は何よりも不利になり、特に厳密なトリガーなしでイベントを生成する頻度を管理することが難しくなります。それはまた、純粋な確率と完全にタンクされたパフォーマンスの効果により、多くの奇妙な統計的異常を引き起こしました。

CK2の長い寿命の中で、私たちはon_actions、機能に接続されたコード内の小さなフック、またはそのフックが呼び出されるたびにイベント（および必要に応じて効果）をアクティブにする通常のパルスを介して、イベントをトリガーする方向に動き始めました。これらはバランスを取るのに少し手間がかかりますが、イベントが呼び出される方法とタイミングをより詳細に制御できるだけでなく、調整が非常に簡単になり、パフォーマンスの点で超高速です。

CK3の場合、イベントを発生させるために完全にon_actionsを使用します。コードから接続された配列がかなりあり、特定のアクションが世界で発生したとき（たとえば、キャラクターが生まれたとき）または定期的なパルス（たとえば、5年ごと）でイベントをトリガーできます。これらは、on_actionが発生するたびにオフになるように設定したり、発生する可能性のある潜在的なイベントの加重リストに配置したりできます（この場合、加重乗数が適用され、通常の要因などをサポートします）。

CK2のon_actionsに対する1つの大きな改善（より徹底した合理化された使用システム以外は非常にエキサイティングだと思いますが、他の人が私よりもはるかに興味深い人生を送っていて、より厳しい基準を持っていることもあります）は、スクリプト化されたon_actionsの追加です！これらにより、常にハードコーディングされたon_actionsに依存する必要がなく、通常のon_actionsとして動作するスクリプト内でon_actionsを完全に作成してフックすることができます。スクリプト化されたon_actionsは、コード化されたon_actionsとまったく同じように動作し、重み付けされた、および重み付けされていないイベント/効果の複合体として機能し、アクセス不能コードではなく、アクセス可能スクリプトのどこかから呼び出されます。

たとえば、内戦後の和解に関する一連の新しいイベントを作成したとします。隣人は反対の嘘をつくために戦った後、隣同士で生活することを学び、そのようなことを行い、それを実現したいと思います。内戦が終わる時はいつでも。そのフローをセットアップするために私がしなければならないすべては、関連する戦争の終末効果にこのようなものを追加することです：

次に、これを含むファイルを適切なディレクトリに作成します。

エフェクトをスクリプト化できる場所ならどこでも、新しい（または既存のスクリプト化された）on_actionへの参照をスクリプト化できます。

即時ブロックとあなた即時ブロック

で非常に規則的に使用するCKスクリプトの主な新機能は、スクリプトリストです。

これらは、私たちは、様々なグループを分類基準のセットに一致する関連する文字を選ぶ、その後、ソート関連の文字のリストの中にできるようにするだけで簡単に。

たとえば、家臣や廷臣の中からすべての老人を掴みたいとしたら、漠然と次のように書きます。

そして、私はそれらの中から最も怒りと最もふさわしい2つを選んで、イベントやあなたが何をしているのかを議論させます：

ソートされました！次に、ローカライズでこれらの2つのキャラクターを参照し、エフェクトを適用したり、ポートレートキャラクターにしたりすることができます。クールな新しいAlternative_limit機能に注意してください。これらは、すぐ上の制限が失敗した場合にチェックされる制限です。

とは言っても、不必要なメンテナンスを最小限に抑え、潜在的なバグをそれらが存在する前に排除することを目的としています。このスクリプトは、同じ状態を使用する2つの個別のリストを呼び出すことで、警報ベルを鳴らします。別のスクリプト化されたトリガー。

これを解決する方法はいくつかありますが、ordered_in_listエフェクトを使用して、いくつかの新しい機能を披露しましょう。

Ordered_in_listはリストを受け取り、script_mathsというシステムを使用して（別の時間について話す時間があると思います）、そのリスト内の項目に数値を割り当てます。次に、ブロック内のすべての効果を通常どおりリスト内の最も高い値のアイテムに適用します（ただし、ここでは、リスト内の任意の数のアイテムに効果を適用するように指示できます）。ここでは、かなり限られた一連の要素によって比較的少量のリストアイテムを並べ替えていましたが、この並べ替え機能は、必要に応じて複雑かつ広範囲に及ぶ可能性があります。

他の即時ブロック関連のニュースでは、スコープ（以前のイベントターゲット、上記の例で少しわかります）と変数を簡単に保存し、このブロックを使用して、最大の音楽ストリングを定義します。ドラマ。標準の即時ブロック機能（イベントが表示される前に実行されます）は変更されていません。イミディエイトで実行された可視効果は、すべてのイベントオプションツールチップの[Has Happened]ヘッダーの下に表示されます。

オプション：AIパーソナリティを与え、プレイヤー

にストレスを与える最後に、オプション。オプションはCK2と同様に動作し、表示されるイベントごとに最低1つ、各オプションにはテキストラベルが必要ですが、それ以外の場合は、好みのさまざまな効果を入力できます。
&attachref(011.png
);

この領域への2つの主な追加は、ai_chanceの大幅に拡張された使用であり、かなり一般的には、stress_impactです。

CK2と同様に、AIの確率は、NPCキャラクターがそのオプションを選択するおおよその確率を決定します。CK3では、このブロックと公開されているai_value_modifiers（各キャラクターの特性の大小に基づいて各キャラクターの性格を構築します）をより広範囲に使用して、それを確実にしますキャラクターは、適切なai_value_modifiersに基づいて、ほぼすべてのイベントオプションを上下に重み付けすることにより、可能な限りその性格に従って行動します。ブロックは他のトリガーも引き受けます。そのため、AIが、戦っている場合、ライバルに関連する場合など、特性に基づいてオプションを多かれ少なかれ優先することができます。

一方、Stress_impactは、新しいストレスメカニズムを編成する方法です。これは、以前の日記から覚えているかもしれません。ストレスを感じない（* ahem *）場合：ストレスは、一言で言えば、性格に反するアクションを実行したときにキャラクターが得る悪影響の尺度です（たとえば、思いやりのあるキャラクターは拷問を楽しんでいません）人）。

ここでは、特定のオプションの選択に関連する性格特性をtress_impactブロックに入力し、スクリプト化されたtress_impact値を使用して、それを確認します。賢いオートマジックのため、stress_impactブロックで得られたストレスと失われたストレスをいくつでも組み合わせることができ、イベントオプションで1つの数に計算されます。

ストレスを通常の効果として、stress_impactブロックの外に追加することもできます。その場合、結合されません。必要に応じて、複数の応力インパクトブロックを追加して、個々の応力修正子のみを組み合わせるか、ブロックを完全に省略することもできます。スクリプトボートを浮かせるものは何でも。

これで、別の開発日記が終わりました。私はあなたが持っているかもしれない質問に答えるために数時間

滞在します、そして私たちはあなたに会うのを楽しみにしています-トリガーをカバーするつもりはありませんか？
ハ、あなたは私の狡猾な陰謀のツイストに落ちました。以前のスクリーンショットでステルストリガースポイラーに気づいた人に手を差し伸べると、インターネットポイントを1つ獲得できます。

他の皆のために、もう一度スクリーンショットを撮りましょう：

簡単にまとめると、CK2のスクリプトトリガーは、要件の長いリストを1つの参照の下にグループ化し、確認する必要があるときにその参照を参照する方法でした。

たとえば、20以上の条件をチェックする必要があるイベントに2か所あるとします。これらの条件をすべて2回スクリプト化すると、イベントは完全に機能しますが、将来誰かが1セットのトリガーを更新しても、その他？バグの即時ソース。次に、これらのトリガーを2回以上、または複数のイベントにわたって、または最大のサディズムのために、異なるファイルの複数のイベントにわたってチェックする必要がある場合はどうなりますか？

ご想像のとおり、それは急速に混乱に発展します。ただし、それほど複雑ではないトリガーを使用することは望まない。これは、タイトルが悪化し、誰にとっても面白くなくなるためです（本当に CKは具体的な特殊性がないのですか？）、そしてそれは問題の規模を縮小するだけなので、それを修正していません。

代わりに、スクリプト化されたトリガーを作成します。これは、1回書き出されたトリガーのリストです。他のファイルから参照できるファイル内。次に、これらのトリガーを確認する必要がある場所で、スクリプトトリガーを呼び出して、その内容を確認します。トリガーを更新または修正する必要があるときはいつでも、スクリプトトリガーを1回修正するだけで、通常、スクリプトトリガーをチェックする後続のすべての場所もプロキシによって修正されます。即時のメンテナンスの節約、バグの可能性の大幅な削減！

ただし、CK2では、これらのスクリプト化されたトリガーは、それらが参照するイベント（および他のスクリプト）とは別に、/ commonの特定のフォルダー内に格納する必要がありました。これは大したことのように聞こえないかもしれませんが、スクリプト化されたトリガーの作成と維持に少し余分な手間を追加し、実際にはスクリプト化されたトリガーの膨大なリストを提供するだけです。いくつかの場所。

CK3では、インラインスクリプトトリガーを追加することでこれを改善しています。つまり、スクリプトトリガーは、そのファイルでのみ使用される場合に、それらを使用するファイルに直接書き込むことができます。複数のファイルで使用する必要があるより実用的なスクリプトトリガーの場合、古いフォルダーシステムは引き続き機能します。これにより、メジャーとマイナーのスクリプトトリガーを分割し、スクリプトトリガー（さらに言えば、スクリプトエフェクト）をタイトル全体で大幅に徹底的に使用できるため、私たち（そしてあなた！）は、維持が容易でありながら、複雑さや詳細について妥協する。

そしてでそれ、私たちは、DEV日記の実際の終わりに来ます。来週お会いできるのを楽しみにしています