MMO RPGの開発は実用的なガイドです。 サーバー（パート1）

• ゲームバックエンド：どのモジュールで構成する必要がありますか？
• 文字パラメーターの計算：仮想メソッドまたは配列の追加？
• 動作のロジック：どのレベルにすべきか？
• キャラクターの移動：誰がそれを管理すべきですか？

今日は、スペースMMO RPG 「Starry Ghosts」を例として使用して、オンラインゲームの開発と設計に精通し続けます。 この記事では、C ++のバックエンドについて説明しますが、完全に技術的です。



テキストにはスターゴーストの機能への多くの参照がありますが、私たちの製品を掘り下げる（そして遊ぶ）必要がないように資料を提示しようとします。 ただし、素材の理解を深めるために、数分かけてすべてがどのように見えるかを確認することをお勧めします。



この記事では、MMO RPGのバックエンドに関連するアーキテクチャソリューションにリアルタイムで焦点を当てます。 多くのソースコードはなく、複数の継承やテンプレートなどのC ++固有のものは含まれません。 この記事の目的は、ゲームサーバーの設計を支援し、すべてのユーザーがゲームバックエンドの詳細を理解できるようにすることです。



説明したソリューションは非常に用途が広く、多くのRPGに非常に適しています。 例として、記事の最後に、ゲーム「エルフについて」で説明されているアーキテクチャを使用する例を示します。

技術の選択

考案したゲームプレイを実装するには、一定のソケット接続と、ユーザーのアクションに対する応答時間が十分に短いサーバーが必要でした（pingをカウントせずに50ミリ秒以内）。 そのような要件を満たすことを可能にした技術の選択はそれほど大きくありません。 当時、私たちのキャンペーンは、ゲーム以外のプロジェクトのためにC ++でバックエンドを実装した経験があったため、C ++を優先して選択しました。この技術には人と経験の両方がありました。



Java（または他のテクノロジー）が最良のソリューションかもしれませんが、私たちのチームには強力なJava開発者がいませんでした。サーバーソリューションの作成経験のあるアーキテクトは言うまでもありません。 そのような状況では、新しいスペシャリストを雇い、数ヶ月と数万ドルを費やしてどちらが良いかを確認し、簡単に再利用できる作業およびテスト済みのC ++コードを捨てる-これはすべて予算をはるかに超えており、開発に割り当てられた時間。



サーバーがJava（または他のテクノロジー）で出てきたかどうかを答えるのは難しいと思いますが、C ++では、必要なものを正確に取得できました。

一般的なサーバー図

サーバーは、次のモジュールで構成されています（図1を参照）。

• Shipには、デバイスのデータと船舶の現在のパラメーターが含まれ、インストールされているデバイスに応じてこれらのパラメーターの計算も処理します。 これは、他のすべてのサーバーモジュールが依存する最低レベルです。
• スペースは、世界と世界のオブジェクトを記述するためのモジュールです。 このレベルでは、オブジェクトは座標、現在のモーションベクトル、オブジェクトの相互作用（ショットの処理、損傷の発生など）を実装します。
• AIはAIモブと特定のNPCスキルを実装するモジュールです。
• クエスト -クエストシステムの実装。
• メイン -ユーザーとのやり取りを担当するすべての機能（ソケット、ストリームなど）、およびキャラクター固有の機能（スキル、バフ、アチーブメント、クラフティングなど）が含まれます。
• Packetsは、パッケージのラッパーを含み、RPCクライアント<->サーバーを実装する自動生成モジュールです。

記事のこのパートでは、ShipおよびSpaceモジュールのアーキテクチャを見ていきます。 残りのモジュールのアーキテクチャについては、この記事の次のパートで説明します。

船モジュール

オブジェクトとオブジェクトのプロトタイプ

このモジュールは、「オブジェクト」タイプのマテリアルオブジェクトで動作します。 つまり、ホールドに入れたり、スペースに投げ入れたり、店で購入したり、別のプレイヤーに移したりできるものすべてを備えています。 このモジュールはまた、設置されたデバイスからの船の基本的および派生的なパラメーターを考慮します。







図 図2は、クラス図を示しています（わかりやすくするために図は簡略化されています）。 クラスが2つの部分に分かれていることがわかります。オブジェクトのプロトタイプが下部にあり、オブジェクト自体が上部にあります。 プロトタイプは完全に静的で機能がありません-それらはデータベースからロードされ、変更できず、誰にも属していません。 逆に、オブジェクトのオブジェクト（すべてICargoの子孫）を変更して、特定のオブジェクトを識別し、それがどこにあるかを判別できる一意のIDを含めることができます（保留、倉庫、宇宙のコンテナ、店舗など）。 。 このアプローチにより柔軟性が増し、他のクラスに影響を与えることなくオブジェクトの機能を変更できます。



このソリューションでは、ICArgoの子孫のほとんど（または、TDeviceとTShipを除くすべて）は、プロトタイプのプロキシにすぎません。 その後、疑問が生じます。本当に必要なのでしょうか？ 結局のところ、プロトタイプの子孫を作成する方が簡単であり、識別用の一意のIDが追加されるため、問題は何ですか？ いいえ、簡単ではありません。 しかし、このアプローチでは、まず、サブジェクトに2つのクラス（プロトタイプと子孫）が必要です。次に、動的データと静的データを混在させます（プロトタイプが変更されていないため）。 それに加えて、もちろん、すべてのフィールドでプロトタイプを複製する必要があるため、アイテムのメモリ消費と作成時間が増加します。 上記をサポートするため、例を挙げます。最初はゲームにチップがありませんでしたが、登場したとき、すべての変更はTMicromodule / TMicromoduleProtoクラスのペアを追加し、TDeviceにインストールされたチップを計算する機能が追加されました。 TShipクラスは、他のすべてのクラスと同様、まったく影響を受けませんでした。



船舶および機器のパラメーターの計算

「スターゴースト」には、さまざまな種類のデバイス（砲塔、ロケット発射装置、レーダー、迷彩システム、防護フィールド、ダメージアンプなど）があります。 それぞれについて、TDeviceからストリームクラスを作成し、このデバイスに特定の機能を実装する必要があるようです。 しかし、一般的なサーバーダイアグラムとShipモジュールの説明をもう一度見てみましょう。このモジュールは基本的に、船の最終計算パラメーターをより高いレベルに提供するだけで、オブジェクトの機能は果たしません。 例で説明します。 TShipクラスには、ScanningRangeパラメーター（レーダーの半径）が含まれていますが、実際には範囲でオブジェクトをフィルター処理しません。 そして、最も重要なことは、Shipモジュールのレベルでは、オブジェクトは空間内に座標を持たないため、このフィルタリングは機能しません。 自問する時が来ました：いくつかのクラスTRadarPrototype（TProtoBaseの子孫として）およびTRadar（TDeviceの子孫として）、このクラスのデータベース内の個別のテーブル、および1つのScanningRangeフィールドのみの管理パネル内のページを作成する点はありますか？ 答えは明らかです。これらすべてのコード行とクラスの意味は非常に疑わしいです。 そのため、ゲーム内の任意のデバイスが持つことができるすべてのパラメーターを含むTStaticParamsクラスと、TStaticParamsをデータベースからロードできるTPrototypeModクラスを作成しました。



もちろん、これは不要ですが、それほど大きくはありません。現時点では、TStaticParamsクラスにはint型のフィールドが34個しか含まれていません。 しかし、見返りに、私たちはいくつかの素晴らしいグッズを手に入れました。 まず、変更の容易さ。 これで、新しいクラスを作成せずに、新しいタイプのデバイスとパラメーターを作成できます。 第二に、パラメータの計算のシンプルさ。 船内のすべてのTStaticParamsの同じ名前のすべてのフィールドを追加するだけで、最終的なパラメーターを取得できます！ 仮想呼び出しやダウンキャストはありません-ループ内の単純な操作「+ = "」。 第三に、ゲームデザインの柔軟性が得られました。 たとえば、ゲームには任意のデバイスにインストールできるチップがあり、HPを提供します。 このようなメカニズムにより、ゲームデザイナーは「ベイビー、マスキングデバイスに回避ボーナスを設定できるようにカパリクを追加してください」などの小さなことごとにプログラマーを引き裂く必要はありません。



それだけではありません。 任意のデバイスのパラメーターを持つ1つのクラスがあるため、パラメーターのランダム化とシャープニングを非常に実装できました。 TStaticParamsは配列なので、ゲームデザイナーは管理パネルで最大3つのパラメーター（配列内のインデックス）とデバイスの作成時にこれらのパラメーターの広がりの割合を指定できます。 アイテムを作成するとき、TDeviceは主にTPrototypeMod.TStaticParamsからTStaticParamsのインスタンスにデータをコピーします。 次に、彼は散布インデックスを確認し、設定されている場合は、ダイスを振ってパラメーターをランダム化します。 キューブの値はTDeviceフィールドに格納されるため、データベースからロードした後、パラメーターは変更されません。 シャープニングも同様に実行されます。管理パネルで、ゲームデザイナーはデバイスのMainParamを示します。 つまり、デバイスはパラメータインデックスを認識しており、シャープ化が成功するたびに+ 10％ずつ増やす必要があります。

ただし、武器のパラメーターを計算する際には1つの注意点があります。他のデバイスのパラメーターと単純に合計することはできません。 簡単にまとめると、複数の武器がインストールされている場合、搭載されているすべての銃のWeaponRangeなどのパラメーターを含めて合計することになりますが、これはすべきではありません。 一方、武器の範囲を広げるのがアーティファクトである場合、武器のWeaponRangeに追加する必要があります。 この問題を次のように解決しました。まず、TStaticParamsには2つの配列が含まれます。常に安全に折りたたむことができる一般的なパラメーター（たとえば、HP、ScanningRangeなど）と、一般に折りたたむことができないいわゆるWeaponParamsです。 デバイスが武器ではない場合にのみ、そのパラメーターを武器のパラメーターに追加する必要があります。 すべて次のようになります。

void TShip::Recalc() {       m_xStatic.Set(0);       TDevice* dev = NULL;       for(unsigned i=0;i<m_vSlots.size();i++) {             dev = m_vSlots[i].Device();             if( !dev || !dev->IsOnline() ) continue;             if( dev->IsWeapon() ) {                   m_xStatic.AddDevice( dev->Static() );// HP               } else {                   m_xStatic.Add( dev->Static() );             }       }//for i       if(m_pStaticModifier) m_xStatic.Add( *m_pStaticModifier );//   ,   ,          //      -      ,           for(unsigned i=0;i<m_vSlots.size();i++) {             dev = m_vSlots[i].Device();             if( !dev || !dev->IsOnline() || !dev->IsWeapon() ) continue;             dev->SetWeapon( &m_xStatic );       }//for i }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のサイクルでは、すべてのパラメーターを船の最終パラメーターにまとめますが、武器については、武器ではなく一般的なパラメーターのみを追加します。 次に、スキルのパラメーターを追加します。 そして最後に、武器にTStaticParamsへのポインタを与え、そこから武器パラメータのみを追加する必要があります。



ショット計算

TShipクラスは、デバイスのパラメーターの計算とスロットへの取り付けの可能性の確認に加えて、ショットのパラメーターの計算という別の機能を実行します。 これは、SFireResult TShip :: Fire（NSlotPlaceスロット）メソッドによって行われます。 この方法は、ショットの可能性（武器かどうか、デバイスのクールダウンが終了したかどうか、ショット用のカートリッジがあるかどうか）をチェックし、与えられたダメージ、発射されたショットの数を計算し、許容可能なショットフラグにダイスを振ります（クリティカルヒットなど）。 すべてのパラメーターはSFireResult構造に書き込まれ、デバイスはクールダウン状態になり、弾薬は書き込まれなくなり、ショットの結果が返されます。 同時に、TShipは、射撃しているオブジェクトの範囲もパラメーターもチェックできません（たとえば、オブジェクトに保護があり、ダメージを減らす必要がある場合）。 これにより、必要なすべてのデータを含むスペースの上位レベルが作成されます。



Shipモジュールの他のクラス

TProtoBaseクラスには、ImageID、Name、Levelなど、あらゆるアイテムの一般データが含まれています。



ICargoにはTProtoBaseへのポインターが含まれ、そのデータを外部にプロキシし、アイテムを作成するためのファクトリも提供します。 TDeviceHandbookシングルトンクラスは、これを支援します。データベースからすべてのプロトタイプをロードし、それらへのポインターを含みます。



TCargoBayクラスは、タイプICargoのオブジェクトストレージです。 彼はデータベースに自分の状態を保存する方法を知っており、次のような多くのサービス機能を提供します：最も近い空きスロットの検索、互換性のある積み重ね可能なアイテムの検索（たとえば、他のカートリッジと組み合わせるカートリッジ）など。 このクラスの子孫は、保管アイテムのタイプに制限を課します（たとえば、船だけが格納庫に保管でき、船以外はすべて倉庫に保管できます）。また、必要に応じて、保管可能なセルの数に制限を課します。

IShipNotifyReciverクラスはフロントエンドであり、より高いレベルのリンクを提供します。 たとえば、対応するパケットをクライアントに送信できるように、再生成の開始に関するメインレベルのメッセージを送信します。

宇宙モジュール

このモジュールは、宇宙船、小惑星、惑星などの宇宙オブジェクト（KO）で動作します。 すべてのKOには、空間内の現在の座標と動きのベクトルがあります。 クラス図を図3に示します（わかりやすくするために、図は多少簡略化されています）。







アルゴリズムの複雑さにもかかわらず、アーキテクチャの観点から、このモジュールは非常に単純です。 空間内のすべてのオブジェクト（船、小惑星、惑星、コンテナ、星）はTSpaceObjectの子孫であり、TSystem型のオブジェクトにあります。 TSpaceObjectには、現在の座標、サイズ、およびその動作を制御する2つのオブジェクトがあります。これは、FlyCommand（ISpaceFlyToの子孫）とAction（ISpaceActionの子孫）です。 FlyCommandは、オブジェクトの現在の座標と現在の速度（特定の時間）を計算します。 計算アルゴリズムはコマンドのタイプに依存します。軌道上を移動する場合は、1つ、もう一方を直線的に移動する場合、スムーズに回転する場合-3番目です。 アクションは、より複雑なオブジェクト移動アルゴリズムを担当します。 たとえば、TFollowShipActionは指定された目標を追求します。 これを行うには、Updateを呼び出すたびに、ターゲットの座標が変更されたかどうかを確認し、変更された場合は、OwnerのFlyCommandコマンドを（指定された新しいターゲット座標で）置き換えます。 Actionの実装により、AIの作成が大幅に簡素化され、コードの重複を回避できるようになりました。Actionに実装された機能は、プレイヤーの船とボットに必要なためです。



FlyCommandの存在により、空間内のオブジェクトに必要なモーションのタイプを簡単に設定し、このコマンドをモーションの方程式の係数の形式でクライアントに送信できます。 これにより、転送されるデータの量が大幅に削減され、新しいサーバー側の動作の実装が簡素化されます。



ダメージを与える

TSpaceObjectクラスには、CorrectDamageとApplyDamageの2つの仮想メソッドがあり、TSystemクラスにはDoDamageメソッドがあります。 オブジェクトが別のオブジェクトにダメージを与えたい（たとえば、小惑星が別のオブジェクトに衝突する）場合、TSystemにこれを伝えます。 システムはCorrectDamageを呼び出し、ダメージがゼロではない場合（たとえば、惑星があらゆる種類のダメージを受けない場合）、ダメージ「up」に関するメッセージを送信し（クライアントに送信する）、ApplyDamageを呼び出して、受信者が特定のアクションを実行するようにしますHPおよびHPがゼロの場合、船はコンテナを宇宙に投げます）。



TSpaceShipクラスにはFireSlotメソッドが含まれており、これは特殊な機能を備えたシューティングを実装します。 許容距離を確認し、TShip :: Fireを呼び出し、能力のタイプに応じて、さらにアクションを実行します。 たとえば、MissileLauncherはロケットを作成します。



Spaceモジュールの他のクラス

ISpaceShipNotifyReciverクラスは、TSpaceShipで「攻撃されました」、「殺されました」、「ハイパートランジションの準備ができています」などのメッセージを上位モジュールに送信するために使用されます。



ISpaceSystemNotifyReciverクラスは、TSystemで使用され、スペースオブジェクトの追加/削除、新しいFlyCommand、および損傷の発生に関するメッセージを送信します。



TGalaxyクラスはシングルトンであり、GalaxyのすべてのTSystemsのリストが含まれています。

続く

シリーズの次の記事では、AI、クエスト、メインモジュール、およびデータベースを操作するいくつかの側面について検討します。 そして、もちろん、「エルフについて」というゲームへの約束された適応。