各セルは、特定のリソース、またはクリーンフィールドを表します。 ゲームの開始時に、プレイヤーには管理棟と2つの区画が与えられ、そこにリソース抽出構造を構築できます。 すべての建物は時間の経過とともに崩壊し、修理が必要になります-リソースの販売から得たお金のためです。 管理棟が主な建物です-その修復が不可能であることはゲームの終わりにつながります。
収入を増やすのは簡単ではなく、まれであるが高価な行政の修理は、しばしば美しく構築された計画を破ります。
むかしむかし、グリゴリー・ズムレフスキーのサハリン植民地の経済戦略が本当に好きでした。 今、彼女から、私は最初に終わらせるゲームを書いて、同時にC＃のさまざまな側面を研究することにしました。 著者から彼のゲームをコピーすることについての質問に対して簡潔な「もちろん」を受け取ったので、私は仕事に取り掛かりました。
C ++ソースは著者のウェブサイトで入手できます。これらのオブジェクトをコピーするように頼みました-コスト、オブジェクトがどれだけ住んでいるか、どのような状況で破壊されるかなど。 そうでなければ、私は自分だけに頼ろうとしました。
クロムと合わせて、オリジナルのサイズは640x480です。 同じアプリケーションサイズを選択しましたが、クロムは使用していません。 このため、スペースのより最適な使用と同様に、マップセルのサイズを2ピクセル増やすことができました。 少しだけでなく、良い。
ゲームの内部ロジックはほぼ完全に保持されます。 簡単なヘルプを追加しました。
開発の進捗状況に関する簡単な情報。
全般
特にXNAでゲームを作成することが決定されました。彼にとっては、GUIのノウハウが既にあったからです。
実装には、かなり単純なアーキテクチャが選択されました。
特定のXNAクラスを使用しないゲームクラス。将来の別のエンジンへの可能なポートの簡素化のために：
- マップへのリンクを持つゲームクラス
- セルの配列を参照するマップクラス
- データと建物へのリンクを持つセル
- データとセルインデックスを使用して構築する
- 以下を含むすべての不変データを含む静的クラス 転送します。
Xnaクラスゲーム：
- update（）-ダイアログフォームを開く/閉じる、更新コントロールを呼び出します。
- 描画（）-ゲーム要素のレンダリング、描画コントロールの呼び出し。
クラスevent_handlers：
- ゲームクラスとゲームクラス間の中間層クラス。 ゲームメソッドの呼び出しは、それを通してのみ実行されます。 繰り返しますが、簡単にするために、別のエンジンへの可能なポートを示します。 その中で、スレッドを操作します。
Xmlクラス：
- データの保存、読み取りに取り組みます。
連載
理論上のシリアル化は、XmlDocumentを使用して面倒なデータストレージ/読み取りクラスを放棄するのに役立ちます。
しかし、実際には、シリアル化機能を実装する際に、それなしでは機能しない多くのタスクに遭遇しました。
特に、ほとんどの静的クラスを公開する必要がありました。 結果は、ゲームのパブリッククラスへのリンクを含む静的なトップレベルクラスです。 このアプローチにより、一方では必要なデータへのアクセスの単純さを維持し、他方ではシリアル化を使用することができました。 プログラミングおよび中間テスト中に、データを開いたり保存したりするときにプログラムの奇妙な動作に遭遇しました-すべてが開発用コンピューターで動作しましたが、他方ではシリアル化まで常にゲームがクラッシュしました。 try catch構造をゲームに追加し、エラーに関する情報を取得してファイルに出力することができました。 クライアントコンピューター上のシリアライザー（のみ！）が一部の静的クラスを解析できなかったことが判明しました。 問題はフィールドにあることが判明しました-補助静的クラスで宣言されている列挙です。 長い検索の後、[XmlIgnore]属性を使用してシリアル化から除外することをお勧めしました。 それでも、これらのフィールドはロジックに必要なので、それらを文字列フィールドに複製し、xmlを読み取った後、文字列表現を対応する列挙にすぐに解析することにしました。 うまくいきました。
内容
最初は、インターネットから無料でマークされた画像でゲームを埋めることを計画しました。 彼は絵を描く方法を知らなかったが、適切な写真の検索
驚くほど複雑であることが判明しました。 その結果、自分でアイコンを描いてみたところ、（私の意見では）問題なく動作し、インターネット上でアイコンを探すよりも時間の早いものを見つけました。 現時点では、ゲームにはインターネットからの3枚の写真（お金、食べ物、金）しかありません。 残りは点で描かれています。 より深刻なエディターでの後処理は非常に小さいです。 実際、土地や建物のアイコンはすべて、ゲームに表示されるアイコンの2倍です。したがって、それらを描くのは簡単でした。 さらに、このサイズのアイコンは将来使用しやすくなります。 減らすことは増やすことよりも簡単です。
テクスチャマップ
最初は、すべてのグラフィックコンテンツが壊れていました。各ボタンには1つのファイルがあります。 さらに、組み込みのXNAコンテンツメカニズムは使用されませんでした。すべてのテクスチャはC＃の標準的な方法でゲームにロードされ、Streamを介してTexture2dに変換されました。 テクスチャは名前付き配列に保存されていました。 多数のファイルとパブリッシングの問題により、テクスチャマップについて考えるようになりました。 （ほぼ）すべてを収集した
カードのテクスチャにより、アプリケーションのメモリ消費がほぼ10メガバイト削減されました（マネージャーの「割り当てられたメモリ」列の値が69から60 mbに減少しました）。 名前付き配列もn個の個別の変数に置き換えられました。
インターフェース
残念ながら、XNAには独自のGUIがありません。 winフォームまたはwpfを接続すると、その制限が課せられます。 なぜなら プロジェクトの目標の1つは、C＃で一般的に、特にゲーム環境でプログラミングを教えることです。XNAのGUIである比較的古いバイクを思い出すことにしました。
当初、このネバネバしたものは非常に強力なメカニズム、つまりインターフェイスデザイナーとして考えられていました。 そのパワーは、見つけるのが難しいエラーと遅い動作で、コードの巨大なブロックに変わりました。 多くのコードを削減し、作業を簡素化し、更新時に補助関数の呼び出し回数を減らす必要がありました。
エディットコントロールも作成されました-数字、小数点、プラス記号とマイナス記号のみを受け入れます（追加キーボードのプラス記号とマイナス記号を除く-XNAキーのリストにそれらが見つかりませんでした）。 必要に応じて、GUIの助けを借りて、追加のテクスチャが作成されます-押す、ホバリング、アクセスできない状態。 小さいながらも非常に機能するGUIであることが判明しました。
ストリーム
アプリケーションは、ウィンドウを含めて使用します。 モーダル。 質問ウィンドウ、メッセージ、および取引形態は、処理されるプログラムに情報を送信する必要があります。
作業の過程で、次の解決策が見つかりました。別のストリームでウィンドウがアクティブになると、たとえば建物の修理などのターゲットメソッドが呼び出されます。 修復コストが計算され、ウィンドウ起動フラグと質問のテキスト自体が静的質問クラスに渡されます。
構造を修復する方法（フローと呼ばれる）は、フラグ（ユーザーの応答を受信する兆候）によってサイクルに入ります。 このサイクルの実行と並行して、Updateメソッド（メインスレッド）で、ウィンドウ（ダイアログ）が開かれ、GUIが実行されます。ユーザーがyesまたはnoキーを押すと、対応するフラグが静的質問クラスに設定されます。 子ストリームはサイクルを終了し、ユーザーの応答に焦点を合わせて建物の修復方法を実行し続けます。
多数の並列スレッドを生成しないため、および他の考えられる問題を選別するために、質問がアクティブになると、すべてのゲームボタンがブロックされます。 システムボタンはブロックされません。特に、アプリケーションを完全にブロックする標準のウィンドウダイアログを使用するためです。
アプリ
勝利7の下で書かれて、XNAコンポーネント、.net 4.0フレームワークをインストールする必要があります-必要なものはすべてインストールプロセス中に自動的にダウンロードされます。
XNAコンポーネントは個別にダウンロードできますwww.microsoft.com/en-us/download/details.aspx?id=27598
エグゼ： rusfolder.com/35736586
セットアップ： rusfolder.com/35736588