48

最近作成された多くのゲームには、特定のタスクを達成したことに対してプレーヤー/ユーザーに報酬を与える独自のアチーブメントシステムが付属しています。ここでのstackoverflowのバッジシステムはまったく同じです。

しかし、私が良い解決策を見つけることができなかったいくつかの問題があります。

アチーブメントシステムは常に特定のイベントに注意する必要があります。たとえば、戦闘で20〜30のアチーブメントを提供するゲームを考えてみてください。サーバーは、これらのイベントを常にチェックする必要があります（たとえば、プレイヤーがこの戦闘で対戦相手のx攻撃を回避したか、プレイヤーがxマイル歩いた）。

  • サーバーは、速度を落としたり、クラッシュしたりすることなく、この大量の操作をどのように処理できますか？

アチーブメントシステムは通常、ゲームのコアエンジンでのみ使用されるデータを必要とし、それらの厄介なアチーブメントがなければ、とにかくそこからは必要ありません（たとえば、各戦闘中にプレーヤーがジャンプする頻度を考えてみてください。このすべての情報をデータベースに保存したくない。）つまり、アチーブメントを追加する唯一の方法は、現在の状態をチェックするコードをゲームコアに追加することであり、これは通常、非常に悪い考えです。

  • アチーブメントシステムは、後で不要な情報を保持するゲームのコアとどのように相互作用しますか？（上記の例を参照）

  • それらはゲームのコアからどのように分離されていますか？

私の例は「無害」に見えるかもしれませんが、たとえば、World of Warcraftで現在利用可能な1000以上の実績と、同時にオンラインになっている多くのプレーヤーについて考えてみてください。

4

4 に答える 4

28

アチーブメントシステムは、実際には単なるログの形式です。このようなシステムの場合、パブリッシュ/サブスクライブは適切なアプローチです。この場合、プレーヤーは自分自身に関する情報を公開し、関心のあるソフトウェアコンポーネント（個々の成果を処理する）をサブスクライブできます。これにより、コアゲームロジックに影響を与えることなく、特殊なロギングコードを使用してパブリック値を監視できます。

「プレーヤーがxマイル歩いた」例を見てみましょう。これは増分する単純な値であり、時間の経過とともにスペースを増やす必要がないため、プレイヤーオブジェクトのフィールドとして歩いた距離を実装します。10マイル歩くプレイヤーに報酬を与えるアチーブメントは、そのフィールドのサブスクライバーになります。多くのプレーヤーがいる場合は、この値を1つ以上の中間ブローカーレベルで集計するのが理にかなっています。たとえば、ゲームに100万人のプレーヤーが存在する場合、それぞれが1000人の個々のプレーヤーを追跡する責任がある1000人のブローカーで値を集計できます。アチーブメントは、すべてのプレーヤーに直接サブスクライブするのではなく、これらのブローカーにサブスクライブします。もちろん、最適な階層とサブスクライバーの数は実装によって異なります。

あなたの戦いの例の場合、プレイヤーはまったく同じ方法で最後の戦いの詳細を公開することができます。戦闘でのジャンプを監視するアチーブメントは、この情報をサブスクライブし、ジャンプの数を確認します。履歴状態は必要ないため、これも時間の経過とともに大きくなることはありません。繰り返しますが、コアコードを変更する必要はありません。一部の値にアクセスできる必要があるだけです。

ほとんどの報酬は即時である必要はないことにも注意してください。これにより、トラフィックの管理にある程度の余裕ができます。前の例では、プレーヤーが合計1マイル歩くまで、または最後の更新から1日が経過するまで（それまで内部的にインクリメント）、ブローカーの公開された移動距離を更新しない場合があります。これは実際には単なるキャッシュの形式です。正確なパラメータは問題によって異なります。

于 2010-02-26T18:53:56.410 に答える
4

たとえばビデオゲームエミュレーターでソースにアクセスできない場合でも、これを行うことができます。たとえば、表示されたスコアを見つけるための簡単なメモリスキャンツールを作成できます。一度達成システムは、フレームごとにそのメモリ位置をポーリングし、現在の「スコア」または最高スコアよりも高いものがあるかどうかを確認するのと同じくらい簡単です。ビデオゲームエミュレータの優れた点は、メモリの場所が決定論的である（オペレーティングシステムがない）ことです。

于 2014-06-12T03:33:55.743 に答える
3

これが通常のゲームで行われる2つの方法があります。

  1. オフラインゲーム：pub/subほど複雑なものはありません-それは大規模なやり過ぎです。代わりに、大きなマップ/辞書を使用して、「イベント」という名前のログを作成します。次に、XフレームまたはY秒ごと（または、通常は「何かが死ぬたびに、レベルの終わりに1回」）、アチーブメントを繰り返し処理して、簡単なチェックを行います。設計者が新しいイベントをログに記録したい場合、プログラマーがそれを記録するためのコード行を追加するのは簡単です。

注意：設計者は「player.distance = 50の場合」を望んでいないため、pub/subはこのIMEには適していません。彼らが実際に望んでいるのは、「画面を見ている人が知覚するプレーヤーの距離が最初の村を通り過ぎたように見えるとき、または少なくとも画面の幅が4つ右にあるとき」です。つまり、単純なカウンターよりもはるかに曖昧で抽象的なものです。

実際には、これは、変更が発生した時点（イベントが公開される前）でロジックが実行されることを意味します。これは、pub/subを使用するための不適切な方法です。「ロジックは受信時に実行される」（「サブ」部分）を簡単に実行できるゲームエンジンがいくつかありますが、それらは大多数ではありません、IME。

  1. オンラインゲーム：「カウンター」（上がるint）を保存することを除いて、ほぼ同じです。通常、「デルタ」（フレームごとに発生したものの循環バッファー）、および「イベント」（ゲームで発生した複雑なこと）もあります。これは、単一のIDと固定サイズのパラメーター配列にハードコーディングできます）。これらは、他のサーバーが低CPUコストで非同期に収集できるように、たとえばSNMPを介して公開されます。

つまり、上記の1とほぼ同じですが、次の2つのことに注意する必要があります。

  • 固定サイズのメモリ使用量。また、「読み取り」サーバーがしばらくオフラインになった場合は、その間に獲得したアチーブメントを再獲得する必要があります（ただし、通常、カスタマーサポート担当者がメインシステムのログを手動で調べて、アチーブメントが「おそらく」であると判断することができます。 「勝ちました、そして手動でそれを授与します）
  • 非常に低いオーバーヘッド。SNMPはこのための優れた標準であり、私が知っているほとんどのチームは最終的にSNMPを使用することになります。
于 2014-01-04T15:14:45.100 に答える
1

ゲームアーキテクチャがイベント駆動型の場合、有限状態マシンを使用してアチーブメントシステムを実装できます。

于 2010-07-15T07:10:07.063 に答える