Goblin Wars II.NET-C＃でネットワークゲームをゼロから作成するストーリー

こんにちは、ハブロビテス。 私の小さなプロジェクト、C＃のネットワーク2Dシューティングゲームを紹介します。 ビジュアルコンポーネントは非常にシンプルであるにもかかわらず、今世紀には2Dゲームに興味がなくなるでしょうが、一部のアーキテクチャソリューションは、独自のゲームを作成しようとする人々に興味を抱くかもしれません。 記事では、ゲームのキーポイントを実装するためのオプションについて説明します。

背景

電子技術者になるずっと前から、純粋にソフトウェアプロジェクトを開発していました。 コードの最初の行（2番目のクラス、Turbo Basic、「Palace of Pioneers」のクラス）を書いたその瞬間から、ゲームを書くという欲求を残しませんでした。 プログラミングの学習を始めたほぼ全員がこれに直面したと思います。 もちろん、その後、大規模なものについては十分な知識がなく、同じTurbo BasicとQuick Basicには単純なテキストゲームしかありませんでした。 時々、私は貧弱なBASICグラフィックス出力機能を使用しました。たとえば、緑のピクセルを制御し、赤から逃げ、白のピクセルの形でトラップを設定する必要があるゲームがありました。 しかし、時間が経つにつれて、私はより多くを学び、最終的には、8年生で、2人用の2Dシューティングゲームを書くことにしました。 なぜ2人だけですか？ ネットワークはそれほど普及していなかったため、最も手頃なマルチプレイヤーモードはホットシートでした。 当時、私たちはこの方法でワームとヒーローの友人としばしば戦いましたが、私はリアルタイムで運転したかったです。 そこで、リアルタイムで実行したり、さまざまな武器から撃ったり、物資の入った箱を拾ったりできるゲームを書くことにしました。 -しかし、同時に、私たちは一緒に遊ぶことができました。 1人のプレーヤーにはキーボードのアルファベット部分が割り当てられ、もう1人のプレーヤーにはデジタル部分が割り当てられました。 マウスは単一であるため、プレーヤーの1人に利点を与えないように、マウスは使用されませんでした。 そして以来 モニターが1つあり、戦闘はスクロールできないクラタに限定されていました。

ゴブリン戦争が登場しました。





ゲームプレイ





彼は



ゲームは書かれていました-はい、それは私に慈悲を抱いているでしょう。 私は、タイルセットを含む3D Maxで、すべてのグラフィックを自分のスキルを最大限に引き出しました。 友達と一緒にゲームを表明しました。 ゲームには裏話もありました。要するに、ゴブリンはかつて地球に住んでいて、人々が来て彼らを破壊し始め、ゴブリンは地下に行かなければなりませんでした。 それ以来、ゴブリン都市は人々の大都市の下に存在してきました。 ゴブリンは、人々が投げ捨てた古いアイドルテレビなど、あらゆる種類の技術的なゴミを収集し、ロボットなどの工芸品を構築します。 そして、それらの数が少なかったため、都市間で生じる紛争は、血なまぐさい戦争ではなく、各都市が最高の戦闘機を送った特別なトーナメントによって解決されることに決めました。 これらのトーナメントはゴブリン戦争と呼ばれていました。

ゲームには、爆弾、手rena弾、ピストル、自動武器、ミサイル、距離爆弾、地雷、フェーズガン（テレポーター）、およびゲームの主な特徴-それに対するリンシラミ+武器-ABO。

ゴブリンがリンのシラミを発射した後、制御がそれに切り替わりました。 彼女を止めることは不可能で、動きの方向を変えるだけでした。 壁や他のゴブリンに衝突して爆発し、震源地に大きなダメージを与えました。 最も面白いのは、そのマネージャーであるゴブリンが殺されるか、ABOからシラミになった場合、「ワイルド」になったことです。速度が2倍になり、マップ上で制御不能に走り始めました。閉じて、それらに到達しようとしています。 さらに、箱の中に「ボーナス」が落ちて、カードに一ダースの野生のシラミを一度に投げたことがあり、これもドライブを追加しました。 試合後、ランクで統計が発行されました：



あなたは伝説の魔術師になれますか？



私たちは非常に頻繁にゴブリンを友人とプレイし、学校でも配布しました。コンピューターサイエンスのレッスンでは、私たちと並行クラスの人々がゴブリンを演奏し、「シラミが好きですか？」 一般に、このゲームは私たちに何かを掴んだので、長年経っても、Starcraft 2の間に、いやいや、昔を思い出すためにゴブリンで1つか2つの試合をしました。 ゴブリン戦争の最初のリリースから10年以上が経過しました。

ゴブリン戦争II.Net

私は長い間、2番目のバージョンを書くことを考えていました-今では高速ネットワーク接続はもはや問題ではないので、同じキーボードで1x1だけでなく、ネットワーク上の友人とプレイできるようになりたかったのです。 私がついに執筆のために成熟したとき、私はC ++でGWIIを書き始めました。 彼はアルファ版の状態に持っていき、何か熱意が薄れた。 少し前に、熱意が戻り、私は、今回はC＃を選択し、私が計画していたことを実現することにしました。 当初、計画はより野心的でした-少なくとも上面図をアイソメに置き換えました。 しかし、時間（仕事、他のプロジェクト）がほとんどなく、アーティストがいなかったため、最終的にこれを行うことにしました。完全に見えた点を除いて、古いグラフィックスから最大のグラフィックスを取り、再描画しますうんざり（たとえば、新しいバージョンのタイルは64x64になり、何らかの方法で再描画する必要がありました）、トップビューを残しますが、ネットワークゲームを実装し、未使用の武器（古い爆弾や手rena弾など）を削除します。

何が起きたかのスクリーンショットをすぐに提示します。



新しい光で



以下、読者のリクエストに応じて-ゲームプレイ動画、友人との3分間のテスト試合。

残念ながら、残りの友達は手の届かないところにあるので、1x1でプレイしなければなりませんでした。







ゴブリンウォーズIIとは何ですか？

ゲームはクライアントサーバーの原則に基づいて構築され、すべての計算はサーバー側で実行され、クライアントはレンダリングのみを目的としています。 レンダリングはOpenGLツールを使用して行われ、音声はOpenALを介して出力され、画像はDevILによってロードされます。 ネットワークライブラリ-Lindgrenネットワーク。 OpenGL、OpenAL、およびDevILは、Tao Frameworkラッパーを介してシャープに接続されています。

既製のエンジンは使用しませんでした。はい、おそらく既製の3Dエンジンを使用して最高の結果を得ることができますが、すべてを自分で書き、ゼロから「バイク」を楽しみたいと思いました。

この自転車のアー​​キテクチャについては、記事の以下の章で説明します。

ゲームアーキテクチャ：一般的な概要

まず第一に注意したいこと-ゲームはモジュール式です。 非常にモジュール式。 ゲームのすべてのサブシステムは別個のdllであり、そのほとんどは決して相互に接続されておらず、接続されているサブシステムはインターフェースのみを知っているという意味で。 これにより、システムの一部を簡単に破棄し、別の部分を交換できます。 UDPネットワーク、lindgrenネットワークが好きではありませんか？ INetworkClient、INetworkServerのインターフェイスの実装を忘れずに、1つのdll、Network.dllを使用して独自のDLLを作成してください。 たとえば、単一のプレーヤーを実装するために、いわゆるゼロネットワークが実装されました。これは、ネットワークなしのクライアントとサーバーの単なる接続であり、インターフェースメソッドの純粋な呼び出しです。 同時に、クライアントとサーバーは、Zero-Networkと実際のネットワークのどちらで動作するかを気にしません。

同じことが、例えばグラフィックスに関しても言える。 このアーキテクチャにより、Graphics.dllを書き換えて、OpenGL出力を少なくともWinAPI、少なくともD3Dに置き換えることができます。 また、1つのdllを置き換えることにより、原則として、そのような要望が生じた場合に平面図をアイソメ図に置き換えることができます。

以下は、アセンブリレベルの依存関係garfです。





ゲームアーキテクチャ



GoblinWarsII.exeおよびServer.exeは、実際には実行可能ファイルです。 数行しか含まれていません。なぜなら すべてのロジックはdllokにあります。 たとえば、すべてのサーバーコードは次のようになります。

class Program { static void Main(string[] args) { var game = new Game(); var networkServer = new UDPGameServer(game, int.Parse(args[2])); var matchParameters = new MatchParameters {Difficulty = DifficultyLevel.Easy, FragLimit=0, TimeLimit = uint.Parse(args[0]), MapName=args[1]}; game.StartMatch(matchParameters); networkServer.Start(); while (Console.ReadKey().KeyChar != 'q'); game.Halt(); networkServer.Stop(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Common.dllには、一般的な宣言と特別なタイマーなどのヘルパークラスが含まれています。 基本的に、データ構造の説明があります。たとえば、サーバーとクライアントの両方に必要なアイテムの列挙型です。

 public enum ItemType { PistolBullet, AKBullet, ShotgunBullet, Rocket, Louse, AVOBullet, PhaseBullet, Trapped, StronglyTrapped, WildLouse, LouslyTrapped, PoisonTrapped, FirstAid, MegaHealth, AVOModifier, Boost, LousePack, Equipment, GunabadianHello, LouseHunterEquipment }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Network.dllには、もちろん、クライアントとサーバーを接続するネットワークロジックが含まれています。

ServerLogic.dllはサーバーによってのみ使用され、すべてのゲームロジックが含まれます。ここで、ゲームオブジェクトのすべての計算が行われます。

Media.dllはクライアントによってのみ使用され、クライアント上にサーバーオブジェクトを表示するためのロジックが含まれています（これについては後で説明します）。

最後に、Graphics.dllにはオブジェクトを直接レンダリングするためのコードが含まれています。

ほとんどすべてのdllkaは独自の処理スレッドを開始し、他のスレッドを停止しません-ServerLogic-ゲームロジックを計算するスレッド、Network-受信および送信するスレッド、Media-メディアオブジェクト（クライアント上のサーバーオブジェクトを表す）を処理するスレッド、Graphics-レンダリングスレッド

特定の実装に移りましょう。サーバーの実装から始めましょう。

ゲームアーキテクチャ：サーバー

したがって、上記のコードからすでに明らかなように、サーバーの主なものはGameクラスであり、そのインスタンスはServer.exeバイナリで作成されます。

 var game = new Game();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

他のすべてのシステムは、次のようなサーバーロジックインターフェイスのみを表示できます。





サーバーアーキテクチャ



したがって、外部からゲームを開始したり、プレーヤーを追加または削除したり、試合に関するさまざまな情報を取得したり、最も重要なこととして、ゲームオブジェクトのすべての状態を取得したりできます。

 public IList<GameObjectState> GetAllObjectStates()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-ゲームの最も重要な機能の1つ。

完全にレンダリングできる世界のスナップショットを返すのは彼女です。 したがって、送信スレッドのネットワークシステムは、後でシリアル化し、圧縮してクライアントに送信するために、定期的にゲームの世界のスナップショットを要求します。

プレーヤー自体を表すゲームオブジェクトとの相互作用（たとえば、クライアントからのアクションの転送）も、直接ではなく、IPlayerDescriptorインターフェイスを介して行われます。

  public interface IPlayerDescriptor { void PerformAction(PlayerAction action); Tuple<double, double> GetLookCoords(); long GetId(); double GetLoginTime(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、上記の内容、つまりゲームロジックを備えた完全に分離されたサブシステムが得られます。 それでは、実際に内部でどのように機能するかを考えてみましょう。

「最上層」は、非常に標準的なスレッドセーフなディクショナリ<オブジェクトID、オブジェクト>に見えます-

 private readonly ConcurrentDictionary<ushort, GameObject> gameObjects;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、1秒あたりの指定回数と呼ばれる処理サイクルで、最後の誤算からの経過時間をカウントします。

 private void ObjectProcessingTaskRoutine() { quantTimer.Tick(); Statistics.TimeQuantPassed(quantTimer.QuantValue); if (currentMatchParameters.TimeLimit > 0 && Statistics.MatchTime > currentMatchParameters.TimeLimit) EndMatch(); foreach(var gameObject in gameObjects) { if (!gameObject.Value.Destroyed()) gameObject.Value.Process(quantTimer.QuantValue); else gameContext.RemoveObject(gameObject.Key); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GameContextはクラスであり、インスタンスへのリンクは作成されたすべてのゲームオブジェクトのコンストラクターに渡され、ゲームマップへのリンク、プレーヤーのリスト、リンクを渡す必要がないようにゲームに新しいオブジェクトを追加するメソッドなど、ゲームに関するすべての必要な情報が含まれます自分で

 ConcurrentDictionary<ushort, GameObject> gameObjects;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GameContextのすべてのフィールドは不変で読み取り専用であり、ゲームオブジェクトのコンテキストへの「損傷」を排除します。



しかし、ゲームオブジェクトの実装はより興味深いものです。 当初は、基本的なGameObjectを作成し、そこからPlayer、Bombなどの特定の実装を継承して、非常に簡単に行動するつもりでした。 しかし、このアプローチには欠点がないわけではありません。 多くのクラスがあり、特に「テレポート可能なオブジェクト」、「ヘルスを持つオブジェクト」などのサブクラスが多い場合-このアーキテクチャはすべて面倒で不便になります。

わずかな変更でも、最初から再描画する必要があります。 それで、私は彼のプレゼンテーションから学んだゲームDungeon Siegeの作成者の経験に目を向けました。

要するに、本質は次のとおりです。すべてのゲームオブジェクトは、ゲームコンポーネントのコンテナであり、メッセージングのロジックを除いて、ロジックとデータを含みません。 コンポーネントは、固定タスクに必要なロジックとデータを含む完全なブロックです。 オブジェクト間の相互作用は、コンポーネントにルーティングされるメッセージの交換を通じて発生します。



これにより何が得られますか？ これにより、非常に柔軟で便利なゲームロジックの実装方法が提供されます。 オブジェクトがゲームの世界でどうなるかは、そのコンポーネントのセットとそのコンストラクターパラメーターによってのみ決まります。 ロジックの一部でコンポーネントを実装したら、従来のアプローチとは対照的に、クラスを分解する方法について混乱することなく、ゲームオブジェクトにコンポーネントを押し込むことができます。

さらに、すべてのオブジェクトを1つのクラスGameObjectで作成し、外出先でいくつかの構成からコンポーネントのリストをダウンロードできるようになりました。



この場合、私はまだ最後のポイントを活用していません-構成からのダウンロードを「後で」残し、さまざまなクラスのオブジェクトを実行しましたが、気にしないでください-これは外部ファイルから構成をまだロードしないようにするためだけに行われました、 Player、Bomb、Bulletなどのクラスのその他の違い 存在せず、私の手がこれに達するとすぐに、それらはすべて単一のGameObjectに置き換えられます。

これがどのように実装されているかを詳しく見てみましょう。 したがって、すべての中心にあるのはIGameObjectインターフェイスです。

 internal interface IGameObject { void SendMessage(ComponentMessageBase msg); GameObjectState GetState(); IComponent[] GetComponents(); ushort GetId(); GameObjectType GetGOType(); IGameObject GetParent(); void Dispose(); bool Destroyed(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ゲームオブジェクトは、誤用に対する追加の保護を提供する別のオブジェクトのそのようなインターフェイスのみを取得できます-サードパーティのオブジェクトは、オブジェクトにコンポーネントを追加したり、何らかの方法でそれらと対話したりすることはできません、IComponentが存在する1つまたは別のコンポーネントの存在のみをチェックします[ ] GetComponents（）;



インターフェイスの実装であるGameObjectには、メッセージングと受信状態のロジックが含まれています（世界のスナップショットを受信するときに使用されます）。

 public void SendMessage(ComponentMessageBase msg) { messageQueue.Enqueue(msg); } public GameObjectState GetState() { var states = new List<ComponentState>(components.Count); lock (lockObj) { if (Destroyed()) return null; foreach (var component in components) { var state = component.GetState(); if (state != null) states.Add(state); } } return new GameObjectState(Id, type, states); } public void Process(double quantValue) { if (Destroyed()) return; lock (lockObj) { SendMessage(new MsgTimeQuantPassed(this, quantValue)); //    ,     while (messageQueue.Count > 0) { ComponentMessageBase msg; messageQueue.TryDequeue(out msg); foreach (var component in components) component.ProcessMessage(msg); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネットワーク要求時のオブジェクトの状態の不変性を保証するために、ブロッキングオブジェクトが必要です。



メッセージはフォームのCANCARENTキューに追加されます

プライベート読み取り専用ConcurrentQueue messageQueue;



一覧

  private readonly List<Component> components;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、オブジェクトのすべてのコンポーネントが含まれています。

ゲームアーキテクチャ：コンポーネント

コンポーネントの基本クラスには、まず3つの主要な機能が含まれます。

  public abstract void ProcessMessage(ComponentMessageBase msg); public virtual ComponentState GetState() { return null; } public virtual bool Probe() { return true; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ProcessMessageは、コンポーネントによって実装されるロジックを担当するので、必ず後継機で再定義する必要があります。

IComponentインターフェイスを介して外部システムに使用できる唯一の関数であるGetStateは、オブジェクトのパブリック状態（存在する場合）を返します（たとえば、ヘルスまたは座標）。 オブジェクトにパブリック状態がない場合、再定義することはできません。

プローブ機能は、コンポーネントの依存関係をチェックします。 コンポーネントが何にも依存していない場合は、それに触れることはできません。 たとえば、CollectorコンポーネントがInventoryコンポーネントに依存しているなど、依存関係がある場合は、この関数でチェックする必要があります。 これは、チェックだけでなく、対応する依存関係へのリンクのキャッシュにも使用され、毎回それらを再度検索しないようにします。

さて、上記はあいまいに見えるかもしれませんが、例を見てみましょう。すべてがはっきりしているはずです。

たとえば、そのようなアーキテクチャで弾丸を作るにはどうすればよいですか？ ロケット？



したがって、最初に実装されたコンポーネントはSolidBodyでした。 これは、ゲームワールドでのオブジェクトの物理的な具体化、つまり、座標、マップとの相互作用、およびディメンションを担当するコンポーネントです。

 public SolidBody(GameObject owner, GameContext gameContext, double x, double y, double sizeX, double sizeY, byte angle = 0, bool semisolid = false)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてのコンポーネントと同様に、Owner、ownerオブジェクト、およびgameContextは、ゲームのコンテキストであり、ここからGameMapへのリンクを取得し、コンストラクターに転送されます。

残りはすでにSolidBody固有のものです-オブジェクトの座標、その物理的寸法、回転角度、およびフラグのペア-計算を最適化するために、互いに衝突してはならないオブジェクトは半固体と呼ばれます-衝突は固体-固体および固体-半固体、2つの半固体に対してのみ計算されます衝突しないでください。 これらには、たとえば、互いに衝突できない弾丸が含まれます。



もちろん、箇条書きはSolidBodyになります。 座標と寸法があります。 さらに、相互の弾丸衝突の無駄な誤計算を必要としないため、半固体になります。これは覚えておく必要があります。



SolidBodyの実装は非常に大きいため、現時点では省略します。

計算を高速化するために、それに関連するオブジェクトのリストがマップの各タイルに添付されていることに注意してください。 マップ上でオブジェクトを移動すると、これらのリストが更新されます。 したがって、衝突を計算する場合、各オブジェクトから各オブジェクトまでの距離をカウントする必要はありませんが、まず関心のある半径内のタイルをすばやく選択し、それらに接触するオブジェクトについてのみ距離の計算を実行します。



次に、すべての弾丸、ミサイル、およびその他の砲弾のロジックの中心となるコンポーネントを実装します。これは、単純で均一な、簡単な飛行を担当します。

 internal class Projectile : Component { private SolidBody solidBody; //  ,    SolidBody! private readonly double speed; //  –   public Projectile(GameObject owner, double speed) : base(owner) { this.speed = speed; } public override void ProcessMessage(ComponentMessageBase msg) { //    –   ,        . if (msg.MessageType == MessageTypes.TimeQuantPassed) ProcessTimeQuantPassed(msg as MsgTimeQuantPassed); } //   .      ,      ,   ,     private void ProcessTimeQuantPassed(MsgTimeQuantPassed msg) { double dT = msg.MillisecondsPassed; var solidState = (SolidBodyState)solidBody.GetState(); byte angle = solidState.Angle; double dX = SpecMath.Cos(angle) * speed * dT, dY = SpecMath.Sin(angle) * speed * dT; // ,        –      ,        .         –     . solidBody.AppendCoords(dX, dY, angle); } //  ,    . GetOwnerComponent,    ,     .    ,   ,      .   . public override bool Probe() { solidBody = GetOwnerComponent<SolidBody>(); return solidBody != null; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これでより明確になるはずです。 完全に明確にするために、非常にシンプルで、依存関係のない別のコンポーネントDieOnTTLを紹介します。 名前が示すように、コンポーネントは指定された期間後のオブジェクトの死に責任があります。

 internal class DieOnTTL : Component { private readonly double ttl; private double lifetime; public DieOnTTL(GameObject owner, double ttl) : base(owner) { this.ttl = ttl; lifetime = 0.0; } public override void ProcessMessage(ComponentMessageBase msg) { if (msg.MessageType == MessageTypes.TimeQuantPassed) ProcessTimeQuantPassed(msg as MsgTimeQuantPassed); } private void ProcessTimeQuantPassed(MsgTimeQuantPassed msg) { var dT = msg.MillisecondsPassed; lifetime += dT; if (lifetime >= ttl) //     Owner.SendMessage(new MsgDeath(Owner)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それでは、箇条書きはどのようになりますか？ とても簡単です。 ここで、たとえば、ピストルの弾丸：

 class PistolBullet : GameObject { public PistolBullet(GameContext context, IGameObject parent, double x, double y, byte angle, double speed, double ttl) : base(context, GameObjectType.PistolBullet, parent) { AddComponents( new SolidBody(this, context.GameMap, x, y, 9, 9, angle, true), new DieOnTTL(this, ttl), new Projectile(this, speed), new DieOnCollide(this,new GameObjectType[]{GameObjectType.Player, GameObjectType.WildLouse}, true, new ushort[]{parent.GetId()}), new DecayOnDeath(this) ); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私が言ったように、手がまだ外部から設定の負荷に達していないという理由だけで、別のクラスが作成されました。 このコードは何をしますか？ まず、ゲームタイプをベースのGameObjectコンストラクター-GameObjectType.PistolBulletに渡します

クライアントでのレンダリングが行われるのはこのタイプであり、さまざまなコンポーネントによってチェックされるのは、弾丸との相互作用などの重要な衝突です。

残っているのは、弾丸を弾丸にするコンポーネントを追加することです。 この場合、パラメーターは外部からオブジェクト自体のコンストラクターに転送され、そこからコンポーネントコンストラクターに転送されます。 しかし、ここでコード内でそれらをハード記述したり、XMLのコンポーネントのリストと一緒にロードしたりすることは、誰も気にしません。

まず第一に、SolidBodyは、弾丸が座標を持ち、他と衝突する完全に物理的なオブジェクトであるためです。 semisolidパラメーターでtrueを指定することを忘れないでください-追加の計算は不要です。

弾丸は、たとえ何も衝突しなくても、一定の飛行時間後に消えます。 したがって、lifetimeパラメーターで既に作成したDieOnTTLオブジェクトを追加します。

弾丸は前方に飛ぶはずです。 これをProjectileに実装し、対応する速度で追加します。

弾丸は衝突により死ぬはずです。 DieOnCollideを追加します。 省略しましたが、完全に些細なことです。SolidBodyはMsgCollideメッセージを送信するため、何も再実装する必要はありません。MsgCollide.CollidedObjectを確認してください。 ここでのパラメーターは、無視できない衝突を示します。壁との衝突を示し、オブジェクトのIDを示します。無視する必要があります。この弾丸を作成した親のIDがそこに渡されるため、弾丸は傷つきません。

最後に、最後に行う必要があるのは、死んだメッセージに何らかの形で応答することです。DesayOnDeathは、MsgDeathメッセージを受信すると、オブジェクトを静かに強制終了します。

さて、ロケットが必要な場合はどうでしょうか？ 簡単なものはありません：

  class Rocket : GameObject { public Rocket(GameContext context, IGameObject parrent, double x, double y, byte angle, double speed, double ttl, double radius) : base(context, GameObjectType.Rocket, parrent) { AddComponents( new SolidBody(this, context.GameMap, x, y, 15, 15, angle, true), new DieOnTTL(this, ttl), new Projectile(this, speed), new DieOnCollide(this,new[]{GameObjectType.Player, GameObjectType.WildLouse}, true, new ushort[]{parrent.GetId()}), new ExplodeOnDeath(this,context, radius) ); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ロケットが弾丸より少し大きい（SolidBodyの幾何学的寸法が大きい）こと、ロケットがWildLouseなどのオブジェクトと衝突しなくなったことを除いて、同じことを行います。 DieOnCollideコンストラクターの弾丸によって、そして最も重要なこと-ロケットは死んで静かに死ぬのではなく、大声で爆発するので、DecayOnDeathの代わりに、半径パラメーターでExplodeOnDeathを追加します。 それだけです！ ほぼ同じコンポーネントでロケットを作りました-既存のコードの書き換えはありません。 必要なのは、死亡時の爆発の原因となる別のコンポーネントを作成することだけでした（DecayOnDeathと同じように動作しますが、死のポイントであるExplosionで新しいオブジェクトを作成します）。

はい。オブジェクトに適切なタイプを指定することも忘れないでください-GameObjectType.Rocket。



たとえば、テレポートの弾丸は、テレポーターコンポーネントの存在のみが異なります。

  AddComponents( new SolidBody(this, context.GameMap, x, y, 30, 30, angle,false, false, true), new DieOnTTL(this, ttl), new Projectile(this, speed), new Teleporter(this, context), new DieOnCollide(this, new GameObjectType[] {}, true, new ushort[] { parrent.GetId() }), new PhaseOnDeath(this, context, radius) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼は、Teleportableコンポーネントを含むオブジェクトをテレポートする責任があります。 オブジェクトをテレポート可能にするには、コンポーネントのリストにテレポートを追加するだけです。

コンポーネントの大部分は追加の継承さえ必要としないため、アーキテクチャ全体が非常に柔軟で透過的になります。



ゲームで使用されるコンポーネントのリストは次のとおりです。

• AOE-影響を受ける領域の責任。 効果フィールドを持つオブジェクトMsgAOEは、アクションの範囲内のオブジェクトに送信されます。これは、効果の効果の強さを示します（震源までの距離に応じて計算されます。効果プロファイルをコンポーネントコンストラクターに渡して、効果が距離とともにどのように変化するかをカスタマイズできます）。
  
  爆発、テレポートの弾丸によって使用されます。
• BaseModifierManager-修飾子を担当するコンポーネント。 つまり、アイテムを見つけた後にプレーヤーに表示され、一定の期間有効な「4倍のダメージ」、「加速」、およびその他の「バン」などです。 基本バージョンには関数のオーバーライドが含まれるため、継承が必要なコンポーネントの1つ：
  
  

   protected virtual void ProcessModifier(ItemType itemType, ModifierDescriptor modifier, double quantValue)
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  -すべての時間の量を操作するモディファイヤ（健康再生、毒）
  
  
  
  

   protected virtual void ModifierAcquired(ItemType itemType, ModifierDescriptor modifier)
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  -修飾子の取得時に発生するイベント
  
  
  
  

   protected virtual void ModifierLost(ItemType itemType, ModifierDescriptor modifier)
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  -修飾子が失われたときに発生するイベント
• BaseWeapon-武器を担当し、継承も必要です。 基本的なロジックには、武器のカートリッジである対応するアイテムの可用性の確認、クールダウンの確認が含まれます。この情報はWeaponDescriptorsに記録され、このコンポーネントが処理されます。 オーバーライドされたオーバーライド関数のプル
  
  

   protected abstract void Shoot(WeaponDescriptor weaponDescriptor, SolidBody solidBody)
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  -成功したショットで、そこから彼らが撃った武器のハンドルを渡す
  
  
  
  

   protected virtual void OutOfAmmo(WeaponDescriptor weaponDescriptor, SolidBody solidBody)
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  -カートリッジがない場合
  
  
  
  

   protected virtual void Cooldowning(WeaponDescriptor weaponDescriptor)
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  -クールダウン時
• 収集可能-MsgItemsAvailableメッセージを、Collectorコンポーネントと衝突するオブジェクトに送信し、「私はここにいます、迎えに来て」と叫ぶコンポーネント
• コレクター-MsgItemsAvailableを聞いたときに、アイテムをインベントリに入れるコンポーネント。
• さまざまなDecayOn ...およびDieOn ...はすでに上記で説明されています。
• 健康-健康と損傷に責任があります。 また、ヘルスが0に達したときにMsgDeathを送信します。
• インベントリは、アイテムのリストとその番号を格納するインベントリコンポーネントです。 コレクター、武器など、アイテムを使用するすべてのものが必要です。
• 発射物は単純な発射物です。
• SolidBody-前述の物理的な実施形態-座標、衝突。 また、マップ上のパスを検索するための静的FindPath関数も提供します。
• Walker-Projectileと似ていますが、「合理的な」オブジェクトの場合-MsgWalkメッセージで設定された特定の方向に移動します。 Direction.StopがMsgWalkの方向として指定されている場合に停止します。

これは、実装に関係のないゲームの主要コンポーネントのほぼ完全なリストです。これはエンジンの一部です。GoblinWarsに直接関連するいくつかのコンポーネントも実装しました。これには、具体的な処理を実装するBaseWeaponおよびBaseModidierManagerの子孫の実装、WildLouseLogic-野生のシラミなどの動作を担当するコンポーネントが含まれます。



既に述べたように、外部システム、またはネットワークは、同じメッセージでプレーヤーと対話します。これを行うために、ネットワークは、PerformAction（）メソッドの対応するPlayerDescriptorをヤンクします。

このメソッドの実装は、通常のメッセージの作成と、必要なアクションに応じてPlayerRescriptor.PlayerObject.SendMeddage（）に送信することです。

おわりに

ここでは、原則として、ServerLogic.dllの基礎を形成するすべてのもの。次の記事では、サーバーとクライアントのネットワーク部分と、他のサブシステムとの相互作用について説明します。

まだ完全なソースコードをアップロードするつもりはありませんが、実装に関する質問があれば、すぐに回答します。興味のある方は、前回の記事の最後にテスト用のゲームを投稿します。



グラフィックを再描画する喜びを純粋に用意しているアーティストがいれば、とても感謝します。ここでのグラフィックはすべて単純な2次元スプライトです。8方向にゴブリン、8方向にリンシラミ、そして最も重要なこととしてタイルを描画する必要がありますが、今では非常に不足しています。

また、原則として、クライアントを他のプラットフォームに移植することに興味がありますが、これを単独で行いたくはありません。誰かがHTML5でモバイルシステムまたはWebへの移植を試みたい場合-これについても説明します。

ご清聴ありがとうございました。