Clever Geek Handbook

戦争ロボットで能力がどのように機能するか





こんにちは！私の名前はウラジミールポポフです。WarRobotsプロジェクトのクライアント開発者です。



War Robotsは数年前から存在しています。この間、ゲームには数十の新しいメカが登場しました。そしてもちろん、それらのどれもが独自の能力のセットなしではユニークではありません。



この記事では、私たちのゲームの能力システムがどのように機能し、それがどのように進化したかを、技術的な詳細なしで簡単に説明します。



まず、歴史を掘り下げて、古い実装を見てみましょう。現在、プロジェクトでは使用されていません。



古い能力は非常に些細なものでした。ロボットにぶら下がっているコンポーネントが1つありました。それは、プログラマーが能力がどのように機能するか、つまりその流れ、どのように、そして何と相互作用するかを完全に説明したモノリシック構造でした。すべてのロジックは1つのコンポーネント内に記述されており、ゲームデザイナーはロボットにぶら下がってパラメーターを調整するだけで済みます。フロー能力を変更する方法はありませんでした。ゲームデザイナーはパラメーターとタイミングしか変更できませんでした。



古い能力は、アクティブと非アクティブの2つの状態でのみ存在できました。各州には、独自のアクションを割り当てることができます。







ジャマー能力の例を考えてみましょう。彼女はかつて、例えばロボットストーカーでした。彼女は次のように働いた：



  1. アビリティがアクティブな場合、アニメーションが再生され、ロボットはジャマー状態になります。この状態では、ロボットをターゲットにすることはできません。
  2. 能力が非アクティブの場合、何も起こりません。
  3. 能力を発動しようとすると、最後の発動からn秒以上経過しているかどうかがチェックされます。
  4. 非アクティブ化は、m秒後に自動的に行われます。


長い間、この機能で十分でした。しかし、時間が経つにつれて、すべてが変化しました。ゲームの設計者とプログラマーの両方が、このアプローチにもはや満足していませんでした。コードが巨大になり、それぞれの状況を説明しなければならない非常に長い継承の連鎖があったため、プログラマーがそのような能力を維持することは困難でした。ゲームデザイナーはシステムの柔軟性に欠けていました。つまり、能力を変更するために、隣接する能力にまったく同じ機能が存在する場合でも、プログラマーに改訂を注文する必要がありました。



それから私たちは何かを変える必要があることに気づきました。そして彼らは新しいシステムを開発しました。その中で、各能力はいくつかの関連するオブジェクトのセットとして表され始めました。機能は、状態、能力、状態の構成要素に分けられました。



使い方？



どの能力にも マスターがいます。これが彼女の中心的なオブジェクトです。残りの能力オブジェクトを外の世界に接続し、その逆も同様です。そして彼はまたすべての主要な決定をします。



状態はいくつでもかまいません。本質的に、ここでの状態は、古いバージョンの「アクティブ」/「非アクティブ」状態と大差ありません。しかし、今ではそれらはいくつでも存在する可能性があり、それらの目的はより抽象的なものになっています。一度にアクティブにできる状態は1つだけです。



古いシステムに対する主な革新は コンポーネントでした。コンポーネントは、ある種のアクションを記述します。各状態には、任意の数のコンポーネントを含めることができます。







新しい能力はどのように機能しますか？



この能力は、一度に1つの状態にしか存在できません。マスターはそれらの切り替えに従事しています。状態にリンクするコンポーネントは、状態のアクティブ化/非アクティブ化に反応し、これに応じて、アクションの実行を開始するか、実行を停止することができます。



すべてのオブジェクトがカスタマイズ可能になりました。ゲームデザイナーは、状態とコンポーネントを任意の方法で組み合わせることができるため、事前にインストールされたブロックから新しい機能を取得できます。プログラマーは、新しいコンポーネントまたは状態を作成するだけで済み、コードの記述が大幅に容易になります。現在、彼らは小さなエンティティで動作し、いくつかの単純な要素を記述し、能力自体を組み立てません-ゲームデザイナーはこれを始めました。



フローは次のようになりました。



  1. マスターは最初の状態をアクティブにします。
  2. ;
  3. ;
  4. ;
  5. ;
  6. ;
  7. .


その後、この手順が何度も繰り返されます。使いやすさのために、状態はコンポーネントのコンテナであるだけでなく、いつ別の状態に切り替えるかを決定し、マスターに切り替えるように要求します。



時間が経つにつれて、これは私たちにとって十分ではなくなり、能力のスキームは次の形式に変換されました：







マスター、状態、およびコンポーネントはそれらの場所に残りましたが、新しい要素がそれらに追加されました。



最初に目を引くのは、各状態とコンポーネントに条件を追加したことです。州の場合、州を離れるための追加要件を定義します。コンポーネントの場合、コンポーネントがそのアクションを実行できるかどうかを決定します。



料金のコンテナ（料金）には、料金が含まれ、それらを再充電し、必要に応じて再充電を停止し、使用するために州に料金を提供します。



タイマーは、複数の状態に共通の実行時間が必要であるが、それら自体の実行時間が定義されていない場合に使用されます。



すべての能力オブジェクトはオプションであることに注意することが重要です。技術的には、マスターと1つの状態だけで十分に機能します。



プログラマーの関与なしに完全に組み立てられる能力はそれほど多くありませんが、プログラマーが非常に小さなものを書くようになったため、開発は一般に著しく安価になりました。たとえば、1つの新しい状態または2つのコンポーネント、残りは再利用されます。



私たちが持っている能力の構成要素とそれらが何であるかを要約しましょう：



  • マスターはステートマシンとして機能します。それは州と構成要素に世界と世界についての情報、つまり能力についての情報を提供します。マスターは、能力の状態、コンポーネント、およびサービス部分（充電と外部タイマー）間のリンクとして機能します。
  • 状態は、マスターからのアクティブ化と非アクティブ化のコマンドをリッスンし、それに応じてコンポーネントをアクティブ化および非アクティブ化し、マスターに別の状態に切り替えるように要求します。州は、いつ次のものに切り替える必要があるかを決定します。これを行うために、彼は自分の内部条件（プレーヤーが能力ボタンをクリックしたかどうか、状態がアクティブ化されてから一定時間が経過したかどうかなど）と、状態にリンクされた外部条件を使用します。
  • : . : , , .
  • , , . . , . , . — , .
  • 料金のコンテナには料金が含まれ、それらを再充電し、必要に応じて再充電を停止し、州に料金を付与します。プレイヤーに数回使用する機会を与える必要があるが、連続してn回以下にする必要がある場合に、マルチチャージ能力で使用されます。
  • タイマーは、複数の状態に共通の期間があるが、それぞれが有効である期間がわからない場合に使用されます。どの状態でもn秒間タイマーを開始できます。関心のあるすべての州は、タイマーの終了についてイベントをサブスクライブし、終了時に何かを実行します。


それでは、能力図に戻りましょう。彼女はどのように行動し始めましたか？



  1. ゲームの開始時に、マスターは最初の状態を選択してアクティブにします。
  2. 状態は、そのすべてのコンポーネントをアクティブにします。
  3. ;
  4. ;
  5. , ;
  6. ;
  7. .


州は、追加の移行条件として料金を使用できます。このような移行が発生すると、課金の数が減少します。また、州は共通のタイマーを使用できます。この場合、それらの実行の合計時間はタイマーによって決定され、各状態は個別にいつでも続くことができます。



UIにまったく新しいものは思いつきませんでした。このようにアレンジしてくれます。 マスターは独自のUIを持っています。これは、常にUIに存在する必要があり、現在アクティブな状態に依存しないいくつかの要素を定義します。 それぞれの 状態







UIにはいくつかあります。状態UIは、その状態がアクティブな場合にのみ表示されます。彼は自分の状態に関するデータを受け取り、それらを何らかの方法で表示できます。たとえば、期間状態には通常、残り時間を表すバーとテキストがUIにあります。



状態が外部コマンドが機能を継続するのを待っている場合、そのUIはボタンを表示します。そしてそれを押すと、コマンドが状態に送信されます。







それでは、具体的な例を使って能力の働きを見てみましょう。Inquisitorというロボットから始めましょう。



次々と変化する4つの状態があります。状態の上に、UIでそれらの表示を見ることができます。それらのうちの2つでは、それらを参照するコンポーネントを確認できます。他の2つの状態には、単にコンポーネントがありません。



能力のワークフロー：



  1. WaitForClick. .
  2. , . WaitForGrounded.
  3. . , . , , Jammer, .
  4. .
  5. : Sound Jammer, Shake, n.
  6. Duration, n , .
  7. Duration, : .
  8. 完了すると、能力は最初の状態に戻ります。






別の例はファントムです。ここではInquisitorと同様に多くのことが起こりますが、まだいくつかのニュアンスがあります。



  1. WaitForClickから始めます。
  2. 次に、テレポートが設定されている期間、メカの統計が変更され、サウンドとアニメーションが再生されます。
  3. その後-毛皮の統計が変更されるDurationOrClick、アニメーションとFXが再生されます。
  4. クリックが行われた場合は、別の期間に移動します。この期間では、毛皮がテレポートされ、統計が変更され、アニメーション、FX、およびサウンドが再生されます。
  5. この状態の後、またはDurationOrClick時間の終了後、Durationに移動します。


主な違いは、分岐状態がここに表示されることです。DurationOrClickはに行く 状態A指定した時間が経過している場合、またはに、 状態Bプレーヤーが前に能力のボタンをクリックする時間を持っていた場合は、。







したがって、私たちのシステムは単純なものから複雑なものへと進化したように見えますが、それによってプログラマーとゲームデザイナーの両方の生活が簡素化されました。前者の助けは、小さなコンポーネントを追加するときに主に必要になりますが、後者はより大きな自律性を受け取り、既存の状態やコンポーネントから独立して新しい能力を組み立てることができるようになりました。同時に、プレイヤーはまた、メカのより多様で複雑な能力の形で利益を受け取りました。


More articles:


All Articles