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

約1年前、私の記事が出てきました。これはこの記事の「 最初の部分 」と呼ぶことができます。 最初の部分では、できる限り、熱心な開発者の困難な道を整理しました。 これらの努力の結果、自宅でエンジン、デザイナー、その他の最新の開発ツールなしで作成されたRTSジャンル「 Land of Onimode 」のゲームができました。 プロジェクトでは、 C ++とAssemblerが使用され、メインツールとして私自身の頭が使用されました。



この記事では、私がどのように「蘇生者」の役割を引き受け、このプロジェクトを「復活させる」ことを決めたかについてお話します。 独自のゲームサーバーの作成には、多くの注意が払われます。



これは記事の続きであり、 ここから始まります 。



→ 記事の冒頭：ゲームの復活

→ 記事の終わり：ネットワーク

私のGUIについて少し

GUIでは 、ゲームで使用する必要なすべてのコンポーネントを作成する必要がありました。



1） テキストフィールド/ GStatic-テキストを表示できます。 さらに、テキストにはいくつかのプロパティがあります-テキストの色とフォントはどこでも変更できます。 最初は、私はこの機会が必要かどうか確信が持てませんでしたが、それは有用以上のものであることが判明しました。







2） 入力フィールド/ GEdit -1行のテキストエディター。 Windowsの同様のコンポーネントと同様の機能を実現しようとしました。 最終的に、彼はクリップボードでの作業も追加しました。 ライセンスキーを入力するだけで、これを強制されました。







3） / GButtonボタンは、マウスのホバリングと押下に応答する通常のボタンです。







4） グラフィックボタン/ GButtonImage-通常のボタン。外観のみが4つのグラフィックイメージによって決まります（通常の状態、マウスの下、押されて非アクティブ）。







5） フラグフィールド/ GCheckBox -YES / NOの原則にチェックマークを付けることができるフィールド。 フィールドの右側に説明があります。







6）リスト/ GListBoxは単なるテキスト文字列のリストです。 リスト内の任意の行を選択できます。







7） ドロップダウンリスト/ GComboBox-コンポーネントは入力フィールドのように見え、リストを開く追加のボタンがあります。 編集を無効にすると、ドロップダウンリストを使用してのみフィールド値を選択できます。 一般的に、これは、 入力フィールド 、 リスト、およびボタンの 3つのコンポーネントを一度に含むため、実装用の「ダム」コンポーネントです。







8） Configurator / GDiscretBox-コンポーネントは、 音量やマウス速度などのレベルを調整するために使用されます。







9） Picture / GPicture-このコンポーネントを使用すると、同じサイズのグラフィックイメージをいくつでもダウンロードして、表示用にそれらを選択できます。







10） ツリー/ GTree-ノードで構成される複雑なコンポーネントで、内部には他のノードが存在する場合があります。 一般に、難点は、階層全体を作成できることです。これもグラフィカルに表示する必要があります。 アイコンを使用することもできます。







11） ポップアップメニュー/ GMenu-右クリックすると通常Windowsに表示されるメニューの類似物。 主な難点は、マルチレベルメニューを作成する能力にあります。







12） ダイアログボックス/ GDialog-他のコンポーネントをその中に配置するためのタイトル付きまたはタイトルなしのウィンドウ。



13） Message / GMessageBoxは、タイトル、テキスト、およびOKおよびCancelタイプのボタンの存在に基づいて自動的に構築されるダイアログボックスの特殊なケースです 。







14） Scene / GScene-ダイアログボックスの特殊なケースで、通常はモニターの領域全体をカバーします。 シーンの背景画像を設定し、他のコンポーネントを上に配置できます。 シーンコンポーネントは常に存在します。 実際には、メニュー画面の変更は、さまざまなシーンの変更です。







一部のコンポーネントには1つの重要な機能があります。コンポーネントウィンドウに収まらない可能性がある任意の量の情報が含まれている場合があります。 これは、 Text Box 、 List 、およびTreeコンポーネントに適用されます。 この場合、スクロールバーを使用してコンポーネントのコンテンツをスクロールする必要があります。 複雑さでは、スクロールバーの実装は通常、コンポーネント自体の実装の複雑さを超えています。

GUI実装のいくつかのより重要なポイント

• OSの機能に強く結び付けられないように、メインウィンドウを1つだけ作成します。 次に、このウィンドウでマウスの動きをキャッチし、マウスが入るコンポーネントを特定します。
  
  
  
  
• ゲームの標準的な描画ロジックとは異なり、シーン全体が完全に再描画される場合、再描画が必要なコンポーネントのみを再描画しようとします。 たとえば、マウスがボタンの上に移動した場合、ボタンを再描画するだけで済みます。
  
  
  
  
• まだ必要な場合、これが移植を複雑にすることを考慮して、「正直な」モダリティを実装しませんでした。 モダリティとは何ですか？ これは、一部のコンポーネントがマウスをキャプチャし、他のコンポーネントがこのマウスに応答しない場合です。 私もこれをすべて持っていますが、心の中では、モーダルコンポーネントには、コンポーネントが閉じられるまで制御を保持する独自の処理サイクルが必要です。
  
  
  
  例を挙げて説明します。 MFCでは、次のようなMessageBoxを出力できます。
  
  
  
  

  if (MessageBox(" C:\Temp\test.avi .    ?", "", MB_OKCANCEL | MB_ICONQUESTION)==IDOK)
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  その結果、次のメッセージボックスが表示されます。
  
  
  
  
  
  
  
  しかし、重要なことは、「 OK 」または「 キャンセル 」 ボタンをクリックするまで、私が呼び出したMessageBox（）関数は完了しないことです。 そして、それは非常に便利です。 GUIにもメッセージが表示され、マウスとキーボードもこのMessageBoxにのみ応答しますが、プログラムは閉じるまで待機せず、メインの処理サイクルを使用します。 したがって、各MessageBoxの「 OK 」または「 キャンセル 」ボタンを押したときの反応を個別に記述する必要があります。 私の意見では、これは私のGUIの不快なマイナスですが、幸いなことにゲームではそれほど一般的ではありません。
  
  
  
  
• 内部では、 GUIはWindowsで行われている「メッセージ」の概念を使用しません。
  
  
  
  
• GUIの現在のバージョンには、親コンポーネントでハンドラーをホストする機能がありません。 たとえば、 Windowsでは、ダイアログボックスにボタンを配置し、ダイアログボックスのクラスのボタンクリックに対する応答を配置できます。 私の場合、ボタン専用のOnLButtonClick（）応答を作成する必要があります。
  
  
  
  
• 「 テーマ 」の概念は、 GUIコンポーネントの設計のために実装されています。 テーマは、 Windowsのテーマと同様に機能します 。 コンポーネントの外観を完全に変更できます。 私の最初のトピックはWindowsで「なめられ」、それはGThemeWindowsと呼ばれていました 。
  
  
  
  メニューは非常に機能的でしたが、次のように見えました。
  
  
  
  
  
  
  
  ゲームのために、私はGThemeOnimodテーマを作成しました。これは私の場合により適しています。 ここで、私はすでに縁石や他のきれいなものに透明性を使用し始めました。 テーマを置き換えると、すべてのコンポーネントの外観が完全に置き換えられることが重要です。

ゲームメニューの再描画について

メニューの背景画像をなじみのないアーティストからリモートで注文しました。 最初の段階では、彼は私のゲームが好きだったという事実だけで団結していましたが、ゆっくりと私たちの関係は非常に友好的になりました。



長い間、メニューの背景に何を表示するかを決定することはできませんでした。 ゲームには2つのレースがあり、1つは宇宙船で飛行し、2つ目はまだ弓から射撃しているため、これら2つの概念を背景画像でつなぐ方法は明確ではありませんでした。 いくつかの写真が拒否された後、「フレスコ画」とアイデアが議論されたことを思い出しました。 その結果、「フレスコ画」は「洞窟壁画」に変わり、比較的簡単に描くことができました。 高度な技術から、メニューは定期的に「洞窟絵画」をスキャンし、新しいものを発見するスキャナーを受け取りました。 ダイナミクスを追加するために、メニューの右側に3つの装飾的なコンポーネントを挿入しました。これらのコンポーネントは、常にある種の暴力的な活動を行いますが、その意味は私にはあまりわかりません。 一般的に、宇宙飛行士が宇宙服を通して寺院の入り口を見るという考え方でしたが、私の意見では、この視覚効果は得られませんでした。







メニューのシーン間の遷移の瞬間に、「ズームイン」の効果をプログラムしようとしました。 そして、ここでは、私は望ましい目標を達成することができたようです。少なくとも個人的には、「観察者」が前進しており、実際には寺院の中に入っているという印象を受けます。



メニューの問題が解決した後、ゲームのアップグレード用のアイコンの外観に戸惑いました。 この「ugさ」は非常に印象的であるため、この形式でこれを残してはならないことを理解しました。



既存のアイコンの外観が私を非常に憂鬱に振る舞う理由を明確にするために、それらの外観を示します。







記事の最初の部分から次のように、アーティストはプロジェクトが完成するずっと前にプロジェクトを去りましたが、アイコンを実際に扱った人はいませんでした。



再描画後、同じアイコンの新しいバージョンは次のようになりました。







このオプションは、使用に非常に適しているように思えます。 ところで、ゲームにはそのようなアイコンがたくさんあります-約80個です。 幸いなことに、それらの多くは外観が似ていました。たとえば、 第1レベルの鎧と第2レベルの鎧は、一部の詳細と背景色のみが異なります。

フォント

Windowsフォントを使用することは今では不可能になっています。 それで、あなたは再び何かをいじらなければなりませんでした。 最も明白なオプションは、画像の形式でフォントを事前生成し、この画像の各文字の座標をテキストファイルに個別に保存することです。 次に、これらの座標がわかれば、キャラクターを1つずつ描くことができます。 幸いなことに、数年前、私はそれを行う小さなユーティリティを作成しました。 ユーティリティはここからダウンロードできます 。





（感情：うーん、スクリーンショットで左から下に気付いたところです... 2006年にすでにそれをやったことがわかりました。そして、それほど時間が経っていないように思えました。）



ユーティリティの使用方法はほぼ明確だと思います。 フォントとその特性、およびテクスチャの長さを選択します。 カーニングフィールドに1を入力することをお勧めします。そうしないと、キャラクターが触れ始める可能性があり、これは完全に悪いです。 ユーティリティはテクスチャをTGAファイルとして保存し、画像自体はアルファチャンネル上にあるため、アルファチャンネルを表示しないプログラムでは空白の白いシートが作成されます。 それでも、画像はアルファチャネルに存在します。



結果のテクスチャは、別のウィンドウで確認できます。 一般に、結果が多少なりとも快適になるまで設定を試し、テクスチャを保存します。







サードパーティのAPIなしで簡単に保存できるため、 TGA形式を使用しました。

蘇生ゲーム

Windowsスタイルのテーマを使用したGUIが多少なりとも「息を吹き始めた」とき、ついにWindows 8/10でゲームの蘇生を開始する機会を得ました 。 しかし、初期段階では、自分のネットワークを持っていなかったため、ゲーム自体のやり直しを開始できませんでした。 そのため、マップエディターを使用して計画を実装し始めました。 彼はネットワークやこれまでのGUIを必要としませんでした。また、 DirectInputを使用せず、マウスとキーボードから標準のWindowsメッセージを介してすべてのデータを受け取りました 。 しかしその後、彼は積極的にアセンブラを使用してゲームオブジェクトを描画しました。



そして、小さなことから始めるのは論理的でした。なぜなら、もし私がすべてを台無しにし始めたら、そこに「終わりが見つからない」と理解したからです。 一般に、プロジェクトからDirectX h-ファイルを再度削除しましたが、作業の範囲を評価するだけでなく、この作業も行う必要がありました。



まず、 IDirectDrawSurfaceサーフェス上のすべてのポインターをGSurfaceOL自身のサーフェスへのポインターに置き換えました。 GSurfaceOLクラスで、 DirectDrawサーフェスの動作をエミュレートすることになっている関数を追加しました。

 long BltFast(unsigned int dwX, unsigned int dwY, GSurfaceOL* lpDDSrcSurface, RECT* lpSrcRect, unsigned int dwFlags);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチは、コンパイラーによって生成されるエラーの数をすぐに大幅に削減しました。これは、自分のサーフェスとそれらに対する関数の両方が存在するためです。



次に、残りのエラー（数百件）をすべて調べ、特定の各ケースを分析しました。 幸いなことに、ほとんどのエラーは同じ理由で発生したため、同じソリューションを注意深く適用するだけで済みました。



一般的には、現在のように思えますが、エディターからDirectXへのすべての参照を削除することができたのは約1週間前です。 さらに、関数が機能するのに時間がかかり、最終的に、最初の重要な結果が得られました。



ここで簡単に説明したように、すべてがそれほど単純ではないことは明らかであり、多くの場合、進行を非常に遅くするいくつかの小さな困難に直面しなければなりませんでした。 たとえば、これはすでに機能しているエディターのスクリーンショットですが、欠陥があり、赤い下線で書き留めています。







アセンブラーによって描画されたセグメントで構成される寿命インジケーターは、画像が非常にぼやけていることを示しています。 ポイントが最終段階にあることに気づくまで、私は長い間愚かでした。最終段階はDirectXによって制御されていました。



先ほど言ったように、RAM内の16ビットの表面に画像全体をペイントしました。 また、 DirectXを介して既にビデオメモリにフルスクリーンサイズでA1R5G5B5テクスチャを作成しました（最初はX1R5G5B5形式を使用していましたが、幸いなことに、一部のコンピューターはこの形式を理解しないことに気付きました）次に、 DirectXテクスチャでLock（）を実行します-a、およびmemcpy（）関数を使用してRAMからテクスチャをコピーします。 Unlock（）を介してDirectXのテクスチャをリリースし、実際には、 DirectXの標準テクスチャでイメージを取得します。 そして今、それは2つのテクスチャ付き三角形の形で描くことができます。 確かに、このテクスチャのサイズは16ビットで、画面の解像度は24ビットです。 しかし、ここではDirectX9が最上位にあることが判明しました。問題なく三角形のレンダリングの瞬間に色変換を実行します。 最初に、この変換を自分で行ってRAMからセカンダリビデオバッファーに直接データを移動しようとしたことを認めなければなりませんが、 DirectXと比較した結果は私を満足させませんでした。



だから、ぼやけた画像のためにすべてを説明し始めました。 だから...最初、私はこのチェーンの問題を持続的に検索しました。 しかし、セカンダリバッファーからプライマリへのイメージの最終転送を実行するDirectX関数Present（）が正しく構成されていないことが判明しました。



私にとって、この関数は次のように見えました。

 device_3d->Present(NULL, NULL, NULL, NULL);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、ウィンドウモードでは、最初の2つのパラメーターにNULLを指定できません。ここでは、「from」と「where」の長方形がコピーされます。 急いで、 Present（）関数をフルスクリーンソリューションからコピーしましたが、NULLを使用するのは非常に普通でした。



そして、そのような些細なことは常に出くわすので、プログラマの仕事の評価は明確な時間枠には向いていません-どんな些細なことでも開発を無期限に遅らせることができます。 個人的には、「見かけの用語に3を掛ける必要がある」というルールを常に守ってきました。 開発者の主なタスクは、「できるだけ早くエラーを修正する」ことではなく、「1つのエラーを修正するときに新しいエラーを作成しないこと」です。 約1年間ゲームを手探りして、ゲーム自体にはほとんど触れませんでしたが（ネットワークインタラクションとメニューを除く）、普遍的な「シェル」を作成する間接的なタスクを解決しただけです。



エディターを起動した後、私はついにゲームに移りました。 しかし、ここでは、あるものを別のものに置き換えるだけでなく、それをやり直す必要がありました。 総作業量ははるかに重要でした。 メニューは、コンポーネントの配置が類似しているにもかかわらず、ほぼ完全にやり直されました。 たくさん改善できたことを願っています。



しかし...私はすでにGUIについて十分に話し合ったので、今度はこの記事をシェルでの作業に関するドキュメントに変えるか、誰かが必要とするかもしれないときにこのトピックを残す必要があります。



しかし、私はネットワークにとどまることにしました。 前回の記事では、 ネットワークについて非常に簡単に説明し、RTSに関連するネットワークゲームの機能に関しては、ネットワークの相互作用を作成することにあまり注意を向けませんでした。 また、前回の記事の読者の中には、この主題に関する少量の情報を後悔している人もいることに気付きました。 したがって、今回は、インターネットサーバーとネットワーククライアントの記述に使用した原則を説明することにしました。 私の意見では、この資料は「本質を理解する」ことを決めた人に比べてはるかに「過酷」です。



→ 記事の冒頭：ゲームの復活

→ 記事の終わり：ネットワーク