自宅で古典的なRTSをゼロから作成するストーリー（パート2：「復活」）

約1年前、私の記事が出てきました。これはこの記事の「 最初の部分 」と呼ぶことができます。 最初の部分では、できる限り、熱心な開発者の困難な道を整理しました。 これらの努力の結果、自宅でエンジン、デザイナー、その他の最新の開発ツールなしで作成されたRTSジャンル「 Land of Onimode 」のゲームができました。 プロジェクトでは、 C ++とAssemblerが使用され、メインツールとして私自身の頭が使用されました。
この記事では、私がどのように「蘇生者」の役割を引き受け、このプロジェクトを「復活させる」ことを決めたかについてお話します。 独自のゲームサーバーの作成には、多くの注意が払われます。


記事の続き：GUI
記事の終わり：ネットワーク

記事に短いビデオを添付して、何が問題になっているかがすぐにわかるようにします。

エントリー

この話全体は、ITの世界が完全に異なっていた1998年にさかのぼります。 もちろん、このゲームはもともと当時の既存の状況に合わせて設計されました。 特に、グラフィックを表示するためにアセンブラーを使用し始めることはほとんどありませんでしたが、その瞬間にはほとんど唯一の解決策に思えました。 この仕組み（ゲームメカニクス、AIなど）の仕組みや、前世紀の終わりにロシアのゲームの「出版社」がどうなったかに興味がある人は、この記事の最初の部分を参照してください 。

また、RTS用に開発したことがあるパス検索アルゴリズムの個別の説明もあります。 この記事は10年以上にわたって書かれており、むしろ「私自身のために」書かれていますが、十分に詳細に書かれているので、私自身がすべての仕組みを覚えています。 私の意見では、使用されたソリューションは速度の点で非常に効果的であり、障害物の位置をある程度難易度を持ってセルフィールドにターゲットへのパスを構築することが保証されています。 ここで 、この方法に慣れることができます 。

なぜこの「叙事詩」全体を続けることにしたのですか？ 経済的な理由から、この規模の仕事が一度に私に一時的に埋もれてしまったことに気づくのは、いつもつらいことでした。 そして、このゲームにもう一度挑戦する機会が少なくともあるように思えたとき、私は自然にそれを試みました。 私の人生の最後の年、私はほぼ完全にこの問題に専念しました。 主に記事の最初の部分の読者のサポートのおかげで、ゲームはGreenlightを通過し、すべてを整理するという通常の決意で決めました。 そして、この記事は私の活動にぴったりのものです。 最初は、プロセス全体を詳細に説明し、独自のGUI （グラフィカルユーザーインターフェイス）の作成からゲームサーバーの作成までを考えていました。 しかし、残念ながら、私はこの情報が過剰に取得されていることを発見しました。 その結果、このトピックは多くの人にとってより興味深いものであるように思えたので、ネットワークの説明にもっと注意を払いました。 実際に何らかの形で適用できるような方法で説明を試みました。 しかし、その結果、記事が理解のためにわずかに「重く」なるとは思われませんでした。

C ++ソースコードでダウンロードして表示できるゲームまたは何かの「シェル」

奇妙なことに、このセクションは記事の冒頭にあり、最後に書きました。 この記事を書く過程で、少なくとも「内側から」何かを示す必要があることに気付きました。そうしないと、すべての説明に実用的な意味がなく、実際には冗長になります。 そして、私はそれがあまり好きではありません。

したがって、私はさらに、大規模なプロジェクトを書くための私のアプローチのいくつかの側面を誰もが知ることができるように、例を使用して記事を提供しました。



視覚的には、この例は私のゲームのようには見えませんが、実際にはゲームはこのコードを使用しますが、異なる「装飾テーマ」を使用しています。 ゲームでゲームセッションを設定する方法は次のとおりです。



また、念のため、これらは「Windowsボタン」ではなく、誰かが考えているように、ゲームに必要なボリュームで作成した独自のコンポーネントであることを明確にします。

例は単なる「正式な」例ではなく、ゲームの一部として使用するために作成したシェルを含んでいます。 この製品には名前はありませんが、おそらくゲームを別のプラットフォームに移植する必要があるという事実を考慮して作成されました。 現在、完全に動作可能な状態では、 Windowsバージョンしかありませんが、オペレーティングシステムへのすべての呼び出しは、置き換え可能な仮想関数を介して行われます。 実際には、ゲームサーバーをインターネットに配置するときが必要でした。 無料のテストでは、 UnixのようなOSによって制御されるサーバーオプションにのみアクセスできました。 その結果、 Unix用のブランチをシェルに追加する必要がありました。 同時に、サーバー自体はまったく変更せず、サーバーがOSと対話するために必要な機能のみを置き換えました。 私は特にUnix APIに精通していませんが、このトピックを非常によく理解している親友プログラマー（このリソースでコード名Komeiを持っている）がいます。 その助けにより、サーバーは数日以内に移植されました。 さらに、私の友人は私のゲーム用インターネットサーバーを起動してテストするために彼のUnixサーバーを親切に提供してくれました。これは、少なくとも、自分の専用サーバーを維持することはそれほど安くないので、私のプロジェクトに対するまともな財政支援でした。

記事の第2部全体がネットワークゲームの構築に専念しているという事実のために、記事の構成に例を必要としました。 そして、説明のコードに定期的に切り替えることを余儀なくされています。 そして、それ自体では、コードの別々の部分はかなり無意味に思えます。 私はゲームのソースコードのリリースを「過剰」と考えましたが、それは私にとって商用製品であり、さらに、比較的小さな例がはるかに理解しやすいようです。 そのため、シェルのソースコードを公開し、わかりやすいように独自の例を提供することにしました。 この例は、 GUIでの作業を示し、サウンドを再生し、ネットワーク接続を示しています。 つまり ユーザーは[ネットワークを有効にする]ボタンをクリックし、[作成]ボタンをクリックするとゲームセッションが作成されます。これは別のコンピューターで実行されているサンプルから参加できます。 セッションでのプレーヤーの構成は、色を変更する機能に依存しますが、これは原理を示すのに十分です。

GUIの構成については詳しく説明しませんでしたが、これが誰にとっても非常に興味深いものであるかどうかは不明であり、記事は非常に大きなものであることが判明しました。 いずれの場合でも、この例は、 GUIで使用可能なすべてのコンポーネントを操作する方法を示しています。

私の仕事を利己的または無関心な目的で利用する人はいません。 しかし、私はこのプロジェクトを開発すること、または現在のバージョンとの互換性を維持することを約束しません。 また、 GUIは速度のためではなく、汎用性のために設計されていることも明確にしています。これは私の場合に必要でした。 さらに、ゲームに必要な16ビットカラーでのみ動作するブランチを実装しましたが、32ビットカラーで動作するコードブランチを追加したり、可能な場合はGPUハードウェアアクセラレーションを使用したりする人はいません。 。 こちらからこのプロジェクトをダウンロードしてください 。

サンプルプロジェクトはVisual Studio 2008に実装され、 C ++言語とDirectX9を使用しています。

解決しなければならなかった問題

はじめに、1年前にゲームに存在していた問題のリストを以下に示します。

• このゲームはWindows XPでのみ完全に機能しました。 Windows 7では、ゲームは正常に開始されましたが、ローカルネットワークはまったく機能しませんでした。 また、 Windows 8/10は単にゲームの実行を拒否しました。
• このゲームは、 Windowsプラットフォームにしっかりと「固定」されていました。 アクティブに使用されたDirectXとMFC 。
• 私の意見でも、メニューのデザインは非常に「愚か」でした。 これは、私がプログラミングに携わっており、描画とは非常に遠い関係にあるという事実によるもので、すでにゲームを完成させました。
• 視覚的には、「研究アイコン」の場合、状況はメニューの場合よりもさらに悪化しました。
• 穏やかにそれを置くために、演技の声は残された、多くが望まれる。
• RTSで最もおもしろいことはネットワーク上のゲームだと信じているので、私が常に望んでいたインターネットサーバーはありませんでした。

徐々に、これらの問題を段階的に解決し、最終的には結果が完全にうまくいくと感じました。 しかし、これは常にそうではありませんでした...

どこから始めるか

ゲームプロジェクトは、かつてVisual Studio C ++ 6.0で作成されました。 現在、このVisual Studio C ++ 6.0はWindows 8でも動作しませんでした。 したがって、まず、プロジェクトを彼のために新しい環境に移す必要がありました。 一方で、 Visual Studioは以前のバージョンのプロジェクトを独自の形式に変換できるため、すべてがシンプルである必要がありましたが、そうではありませんでした。 実際、私はtasm32アセンブラーを使用して、 objファイルを作成しました。 このファイルはVisual Studio C ++ 6.0とシームレスにリンクしていましたが、 Visual Studio 2008にはまったくリンクしませんでした。 世界にはtasm32の新しいバージョンはありませんでした。何らかの理由でmasmのような他のアセンブラーは、激しい憎悪を伴うtasm32構文で輝いており、 asmファイルを挿入しようとすると多くのエラーを生成しました。

熟考すると、この段階ではアセンブラーコードを別の構文に書き換える準備ができていないと判断しました。最初は正しい方向に進んでいるかどうかがまったくわからなかったからです。 その結果、次の決定を下しました： Windows XPをインストールし、 Visual Studio C ++ 6.0をインストールし、 DLLタイプのプロジェクトを作成し、自分でアセンブラー関数を呼び出すエクスポート関数を作成し、アセンブラーobjファイルをリンクしました。これはWindows XPでは問題ありません。 tasm32.exeを介して作成されます 。 その結果、 asm.dllライブラリを取得しました 。これは、 Visual Studio 2008の新しいプロジェクトに問題なく接続できました。 この決定は、ほぼ即座に機能し、今のところ私はそれを詳しく検討することにしました。 当然、このソリューションは他のプラットフォームに絶対に移植できないことを理解していますが、移植の問題が実際に発生した場合は、「意志を拳に集めて」アセンブラを別の構文に変換できます。 それまでの間、このゲームの運命は私にとって漠然としているが、私はこの一年で間違いなく復活させた。 いずれにせよ、私はすでにこのプロジェクトに十分なエネルギーを費やして、この問題について最終的に宇宙から明確な答えを得ることができました。

Visual Studio 2008を使用してWindows 8でゲームを実行できるようになった後、しばらくの間、デバッガが手元に現れました。 まず、新しいバージョンのWindowsがゲームを開始したくない理由を理解する必要がありました。 私は長い間ゲームをプレイしておらず、 Windowsが古いプログラムの作業に課し始めた制限の進化に特に従いませんでした。 個人的には、この理由は非常に予想外でした。 ゲームで使用していた16ビットカラーモードがWindows 8/10から削除されたことがわかりました 。 いくつかの「魔法の儀式」の後、私はまだゲームを開始し、少しでもプレイすることができましたが、すべてが恐ろしくゆっくりと動作し、画面の主な部分は純粋で美しい黒でした。 私自身は、16ビットモードがエミュレートされ、使用に制限があることに注意しました。

16ビットビデオモードの戦い

この問題に対処する方法は？ 少なくとも2つの出力があります。

1. ゲーム内のすべてのグラフィックをやり直して、24ビット解像度で動作するようにします。 私の場合、すべてのグラフィックが圧縮形式で保存され、アセンブラーによって描画されたため、このオプションは不適切です。 すべてのアセンブラー関数は16ビットグラフィックスでしか動作できませんでした。多くの関数自体があり、非常に高速に動作しました。描画時に多くのニュアンスを想定していました。最も重要なことは、何年もかけてすべてが詳細に機能することを忘れていました。
2. RAMに独自のサーフェスを作成します。これはゲームの画面メモリになります。 この表面にすべてを描画してから、実際の画面にコピーします。 私はこのオプションを唯一の真のオプションとして選択しました。 このソリューションでは、大胆なプラスも登場しました。グラフィックスを操作するためにDirectXを必要とすることはほとんどありませんでした。 しかし、このようなソリューションには明らかなマイナスはありません。DirectXを使用すると、テキストを簡単に表示でき、もちろんできました。 そして今、それは判明した：「 DirectXなし-テキストなし」。

その結果、ゲームをオペレーティングシステムと通信する「シェル」のようなものを作成するために、次のことを行うことにしました。 仮想関数を介してOSリソースへの呼び出しを実行します。その場合、それらを置き換えることができます。 実際には、これにより、ゲームを別のOSに比較的迅速に移植することができますが、いつものように、物事はそれほど単純ではありません...ユーザーと通信するほとんどすべてのプログラムは何らかの形でインターフェースを必要とします。 インターフェイスは、「 テキストボックス 」、「 リスト 」、「 ツリー 」、「 ダイアログボックス 」などのさまざまな小さな（しかしかわいい）要素で構成されています。 言い換えれば、この方法を使用する場合、独自のGUIを作成する必要があります。これはどのOSでも同じように動作します。 さらに、サウンドの再生とネットワーク接続の問題を何らかの形で解決する必要があります。

サウンドについては、 Squallライブラリーを使用することにしました。 それを使用することにはいくつかの利点がありました...第一に、このライブラリはゲームの古いバージョンで既に使用されていました、そして第二に、他の無料の同様のソリューションと比較して、私がそれにスリップしたほとんどすべてのwavファイルを再生し、第三に、私は個人的にセシウムの作者にも精通しており、これも重要です。 Squallの主な欠点は、長い間開発されておらず、 Windowsでのみ存在することです。 しかし、最近、外部ライブラリを何らかのアナログに置き換えるのが比較的簡単になるように、私のプログラムにそのような構造を作成しようと試み始めました。 その結果、自分のクラスの小さなレイヤーを介してSquallとのやり取りをすべて行いました。 後で、実験として、 SquallをBASSに置き換えましたが、この置き換えの利点を実際に感じていなかったため、 Squallを返しました。 しかし、別のプラットフォームが必要な場合は、どこにでもあるBASSを使用できることがわかりました 。

ゲームの一部として実質的にDirectXを削除する必要があったため、最初はすべてのDirectX h-ファイルをコメントアウトしました。 [ ビルド]をクリックして、 DirectX関数を自分のものに置き換える作業の量を評価する準備ができました。 長い「問題のリスト」がようやく停止したとき、合計で見つかったエラーの数は9千を少し超えて非常に雄弁に表示されました。 マウスとキーボードからのデータ入力はコードの比較的小さな部分であるため、すべてのエラーのほとんどはDirectInputに関連していましたが、 DirectDrawとDirectPlayは 「完全に」と言われているように注意されました。

別の強力な問題がありました。 実際には、マップおよびキャンペーンエディターがゲームに添付されています。 そして、それは完全にMFCを使用して記述されており、実際にはWindowsウィンドウアプリケーションであるため、エディターが将来別のプラットフォームで動作する可能性についてさえ考えないことにしました。 しかし、実際には、ゲームとエディターの両方が私のプロジェクトでは同じプロジェクトであったということです（文字通り、異なるパラメーターで起動されたのは同じexeファイルでした）。 したがって、このプロジェクトを2つの部分に分割する必要がありました。ゲームはWindowsからほぼ完全に独立して動作するはずでしたが、対照的にエディターはMFCプロジェクトのままでした。 その結果、 MFCフレームワークからゲームを取り出したときに、これらのプロジェクトに共通の機能がタスクを異なる方法で実行しなければならない状況にしばしば遭遇しました。 条件付きコンパイルをコードに埋め込み、2つ目のコードブランチを作成する必要がありました。

最初にしたことは、 DirectXの依存関係を解消するのに役立つ独自のシェルを作成することでした。 16ビットの解像度で動作し、インターフェイスを形成するための標準コンポーネントがあり、テキストを出力できるシェルが必要でした。

「シェル」の構造

GGameクラスをシェル全体の基本クラスにしました。これには他のすべての重要なオブジェクトが既に含まれています。 GPlatformクラスは 、グラフィック操作を除く、OSとの通信を担当します。 ただし、ファイルシステムの操作、メッセージループの処理、アプリケーションの終了、スレッドとプロセスの開始に関連するすべてはGPlatformを参照します。 GSoundクラスはサウンドを担当し、 GNetクラスはタスクに応じてGNetServerサーバーまたはGNetClientクライアントのいずれかです。 最も難しいのは、グラフィックを管理するGDeviceクラスでした。

GDeviceクラスはGSurfaceサーフェスで機能します。 これらの表面は私によって非常に抽象的に定義されています。 ピクセルあたりのビット数に関するヒントはありませんが、多くの抽象的な関数が定義されており、標準のGDIを置き換える必要があります。 ただし、実際には、 GSurfaceタイプのオブジェクトはゲームで作成されることはなく、代わりにGSurface16タイプの子オブジェクトが使用されます 。これは、16ビットサーフェスに関するGDI作業の実行方法を知っているだけです。 シェルに24ビットグラフィックスを使用できるようにする必要がある場合は、常に同様のクラスGSurface24を作成できるため、シェルの一般的な構造をグローバルに変更する必要はないと推論しました。

GDeviceクラスは 、画面解像度の操作も担当し、使用可能な画面解像度を決定する抽象的な機能を備えており、新しい解像度を選択できます。 GDeviceは 、シーンのサイズをモニターのサイズに拡大縮小することもできます。 たとえば、ゲームはプレイフィールドの表示領域を増やすだけで任意の解像度を使用しますが、メニューは常に1920 x 1080の解像度でのみ機能します。 ただし、モニターの実際の解像度が低い場合、 GDeviceはメニューをモニターの現在の解像度に合わせてスケーリングします。 さまざまなモニター解像度用のいくつかのタイプのメニューを作成する方が良いソリューションかもしれませんが、私はまだ企業ではなく、私の場合、そのようなソリューションは単に非合理的です。 いずれにせよ、 1366 x 768の解像度のラップトップでは、メニューはまったく問題ありません。

これらの基本クラスはすべてGPlatform 、 GDevice 、 GNetなどです。 多くの抽象関数が含まれています。 実際のプログラムでは、 GPlatformクラスの代わりに、 GNetクラス、 GNetServerLibUVクラスまたはGNetClientLibUVクラスの代わりに、 GDeviceクラス、 GDeviceOnimodLandDX9クラスの代わりに子クラスGPlatformWindowsが使用されます。 目的のプラットフォームとゲームに既に適合しているクラスオブジェクトを使用します。 「シェル」自体は、ゲームについてもOSについても考えていません。

そして、最も基本的なクラスは、実際にはGGameからGGameOnimodLandDX9クラスに変わります。 これはどのように結合しますか？ 答えは、 new演算子を介してプログラム内に重要なオブジェクトを直接作成しないことです。 代わりに、目的のタイプのオブジェクトを作成する仮想関数があります。 たとえば、 GGameクラスの抽象関数：

//   virtual GPlatform* GGame::NewPlatform(GGame* owner, const char* game_name)=0; //   virtual GSound* GGame::NewSound()=0; 

次のようなGGameOnimodLandクラスを探します。

 //   GPlatform* GGameOnimodLand::NewPlatform(GGame* owner, const char* game_name) { return new GPlatformWindows(owner, game_name); } //   GSound* GGameOnimodLand::NewSound() { #ifdef SQUALL_SOUND return new GSoundSquall(); #endif #ifdef BASS_SOUND return new GSoundBass(); #endif } 

そして今、これらすべてが基本クラスを通してどのように作成されるか：

 //  ,     bool GGame::CreateGame(void* init, int view_width, int view_height) { platform=NewPlatform(this, game_name.c_str()); platform->Create(); device=NewDevice(init); device->Create(view_width, view_height); sound=NewSound(); .... .... .... } 

したがって、OSまたはグラフィックスAPIの詳細を詳しく調べることなく、基本クラスが必要なオブジェクトを作成することがわかります 。 このアプローチにより、メインプログラムコードをランタイムの機能から分離できます。 また、ランタイム環境のすべての仕様が小さく完全に別個のクラスとその機能にあるため、別のプラットフォームへの移植やDirectXの OpenGLへの置き換えが比較的容易になります。

記事の続き：GUI
記事の終わり：ネットワーク