Nepostmortemゲーム「Roads of Rome」（「Roads of Rome」）

この記事では、カジュアルゲーム "Roads of Rome"（ "Roads of Rome"）の開発について簡単に説明します。

おそらく、これはゲームの開発を始めようとしている人たちにとって興味深いでしょう。 実際、プログラミングについてはほとんどなく、開発プロセスで使用されたものについてはほとんどありません。

ゲームについて簡単に

Roads of Romeは、カジュアルなクリックマネージャー/戦略ゲームです。 主な目標は、道路を建設することです。 途中で、瓦を解体し、建物を修理/建設/改善する必要があります。

ゲームの開発では、PopCap Frameworkが使用されました。

自分について簡単に

私は初心者デベロッパーではないことをすぐに明確にします。 以前はゲーム開発会社で働いていました。 そこで自分でゲームを作成するプロセスを見て感じました。 そして、この経験は私にとって非常に役に立ちました。 あなたがそれらに出くわすまで、多くのことは重要でないように思われます。 したがって、開発を開始する前に、さまざまな問題とこれらの問題の解決策、作業するツールの選択、パブリッシャーがゲームに提示する要件などについて熟考することをお勧めします。

プロジェクトでの役割について

このプロジェクトでは、Whiterraチームの一部としてプログラマーとして参加しました。 アート、音楽、レベルデザインなど 他の人によって実行されます。 開発はリモートで実行され、約6か月のカレンダー時間がかかりました。

開発

このプロジェクトでのコミュニケーションは、主にSkype、場合によってはJabberを介して行われました。

タスクのリストはGoogleドキュメントで管理されていました。 番号付きリストとタスクの優先順位が行の背景色によって決定される拡張ドキュメント。



私の主な懐疑論にもかかわらず、この仕事のやり方はそれほど悪くはありませんでした。 何らかの方法でも便利です（ワンクリックでproitiesを表示したい）。 はい、バグや機能の履歴はありませんが、非常に迅速かつ簡単に機能し、サーバーを維持する必要はありません。 プログラマーが1人いるこのレベルのプロジェクトでは、これで十分です。

コードとアートを無料のSVNストレージに保存します（500 MBのクォータがあり、十分です）。



プロジェクトは多言語で、ロシア語版と英語版があります。 テキストは外部XML（PopCapフレームワークの標準）で設定されているため、ロシア語バージョンでは、テキストとゲーム名の一部のアートが単純に置き換えられます。 しかし、以来 リソースのアイコンとファイルプロパティに表示されるテキストは異なります。つまり、これらの目的のための2種類のアセンブリ：Release（英語）とReleaseRus（ロシア語）です。



プロジェクトの最終アセンブリは、MSBuildを使用して行われます。 .NET Frameworkに付属しています。.NET4のバージョンを使用しています（2番目の.NETのバージョンは、Visual C ++ 2008 Expressの '.sln'を使用したくありませんでした）。 これは次のように行われます。



msbuild Game.sln /t:rebuild /p:Configuration=Release

msbuild Game.sln /t:rebuild /p:Configuration=ReleaseRus







もちろん、外部ファイルのMSBuild設定を理解することはできましたが、このソリューションで十分です。 実行後、エラーがなければ、2つの実行可能ファイルを取得します。



まだソースを送信する必要があります。 このタスクを簡素化するために、Pythonスクリプトが作成されました（これは調査を始めたばかりで、非常に便利でシンプルで便利なツールとして習熟することをお勧めします）。フォルダー。

プログラミング

このゲームの開発は、よく知られ確立されたPopCapフレームワーク上でWindowsの下で行われました。

Visual Studio 2008 Express（C＃およびC ++バージョン）がIDEとして選択されました。 ゲーム自体は、C ++、C＃のツールキット（レベルエディター、コミックブックエディター、小さなユーティリティ）で開発されました。

エディターは急いで作成されたので、もっと良くできたかもしれませんが、私たちが持っているのは私たちが得るものです。

レベルはC＃で作成され、C ++で読み取られることを考慮して、レベルはそれ自体でXMLに格納されます。

なぜC＃なのですか？ その開発は高速であり、コンパイルは（C ++と比較して）高速であるため、ビジュアルエディターは便利で、独自の古い開発があります。 まあ、言語はより厳密です、それはあなたが偶然にあなた自身を足で撃つことを許しません。





ゲームは、STLコンテナ（主にSTLPortのベクター、マップ、およびhash_map）を積極的に使用します。 Boostは原則としてそれを使いたくありませんでした。





ゲームエンティティ自体については、道路はおそらく興味深いものです-スプライン曲線に沿って描かれています。 曲線は基準点を使用して作成され、次に「三角形のテープ」がそれに対して相対的に作成されます（各点の法線に従って）。 そして、このテープはテクスチャリングされています。 したがって、道路のテクスチャは小さく、いくつかのレベルに適していることがわかります。 開発プロセス中に、このオプションはあまり良く見えないことが判明しました。 ゲーム内の光は常に1つのポイントからすべてのオブジェクトに当てられますが、回転したテクスチャはこの画像に収まりません。 この問題を解決するために、道路の高さマップ（通常の古い学校のバンプマッピング）で照明のソフトウェア計算を行い、2回目のパスで道路に正しい照明を描画する必要がありました。 シェーダーはありません（DirectX 7ではどこから来たのですか）。



水はとても簡単です。 最初に「下」を描画し、次に水テクスチャを描画し、次にマスクを使用して土地を描画します。



気象事象（雨/雪/砂嵐）は、従来の2D自己記述パーティクルによって作成されます。



地震も非常に簡単になります-レベルの一部は（残念ながらプログラムで）別のバッファーに描画され、画面上に半透明で重ねられ、レンダーの座標を特定の範囲で正弦によってシフトします。 対応する音とともに、かなり良い表面ジッタが得られます。



競技場自体は16x16ピクセルのセルに分割され、パス、移動ユニット、ゲーム要素の位置を検索します。 道を見つけるといえば。 *は、ユニットパスの検索に使用されます（ライブラリは以下にリストされています）。 ゲーム要素の可用性を判断するために、ウェーブアルゴリズム（最も単純な菱形のウェーブ）が使用されます。 シンプルで便利。



ダイアログ内のコントロールの便利な作業のために、コントロール、それらの位置とパラメーターがXMLからロードされるラッパーを作成する必要がありました。 このため、PopCap Frameworkの制御システムを少し振る必要がありました（int識別子を取り除き、文字列識別子に切り替える）。 しかし、それは便利であることが判明し、エディターを書く時間がなかったのは残念でしたが、コード内のボタンの位置を変更してから毎回再コンパイルするよりも便利です。



便利な調整のために、外部XMLでも絡み合わせ効果（減速/加速を伴う滑らかな動き）が調整を行いました。



私自身の経験から、小さな設定を変更してもプロジェクトのコンパイルを開始する必要がないように、最大​​設定を外部ファイルに転送しようとします（プロジェクトと変更の性質に応じて30秒から10分かかります）。 また、ゲームを再起動せずにゲームが外部設定を再ロードできることが非常に望ましいです（ゲーム内の画像の数に応じて20秒から1分に節約されます）。 些細なことのように思えますが、いくつかのパラメーターを5〜10回編集しなければならない場合（1つであれば）、かなりの時間が非常に速く流れ、仕事中の一定の一時停止は良い気分になりません。

プロジェクトの開始時には何をスクリプト化する必要があるか明確ではなく、プロジェクトの終了時にはこの時間はありませんでしたが、スクリプトを固定することができませんでした。

サードパーティのライブラリ

エディターはSourceGridグリッドコントロールを使用します。 そして少し後に、 OpenTKライブラリが関与しました（ところで、バージョン1.0が最近リリースされました）。



ゲーム自体で使用されました：

• STLPort-提出不要
• MicroPather-方法を検索し、本当に気に入って、うまく機能します。 オープンソース（zlib / libpngライセンス）
• PugiXMLは高速なXMLパーサーです。 便利で使いやすい。 オープンソース（MITライセンス）
• yasper-「非侵入型の参照カウントポインター」。 メモリリークの可能性のほとんどを見つけることから私を救った。 オープンソース（zlib-license）
• CppTweenerは便利なトゥイナーであり、ActionScriptでも同様の機能が好まれていましたが、それ以前はC ++でアナログが不足していました。 オープンソース（MITライセンス）
• PopCapフレームワーク-以下のコメント。 オープンソース（独自のライセンス）
• パイロ効果-パーティクル効果のエンジン。 専有、有料（最初のゲームは無料）
• Bass.dll-サウンドと音楽。 有償、有償

何かがあるので、各ライブラリについて少しずつ書くのは面白いと思います。

Popcapフレームワーク

この古いタイマーはいくつかの理由で選ばれました。 まず、このフレームワークの使用経験があるため、顧客はそれを望んでいました。 第二に、私自身も彼との仕事に十分な経験があり、どんな動物で、どんな動物と一緒に食べられたのかを知っていました。

このようなフレームワークは1か月の作業で書かれていると言うshkolotaの話を聞かないでください。 このフレームワークには、リソースマネージャー、個別のストリームへのリソースのロード、ウィジェットとコントロールのシステム、メモリリークの追跡、ビットマップフォントのレンダリングシステム、複数のリソースの1つのPAKファイルへのパッキング、統合XMLパーサー、統合プロファイラー、スタック-トレース、シンプルで便利なAPI、フレームワークコードは、多くの「特別な」状況などを考慮します。

もちろん、その中のすべてが完璧というわけではありません。 ロシア文字を使用するには、「パッチと更新」を少し行う必要があります（©「Bo Shop」）。 ビルトインパーサーにエラーがあり、それらも修正する必要があります。 最悪の部分は、PopCapがこのフレームワークの更新を停止したことです。 ただし、 1.34フレームワークの非公式バージョンがあります -いくつかの欠陥が修正されています（少なくともパーサーとロシア語の文字）。 ただし、主な欠点は残っています。フレームワークはDirectX 7用に作成されており、Windows Vista / 7にはそのようなアンティークを扱う際にいくつかの機能があります。 さらに、ドライバーのATI / AMDおよびNVidiaは、残留ベースでDX7をサポートしているため、多くのユーザーが問題を抱えています。 かつて、ATIカードでプレイすることは一般的に不可能でした（黒い画面が表示されていました）が、その後、通常のドライバーが登場しました。 NVidiaでは、一部のバージョンのドライバー（Vista / 7）で3Dのサポートが検出されなくなったため、ゲームはソフトウェアモードになり、それに応じて非常に遅くなりました。 したがって、現時点では、PopCapフレームワークで開発することはもはや不可能であると述べざるを得ません。開発者が解決できない問題の範囲は広すぎます。

興味のある方のために、PopCap Frameworkには非公式のフォーラムがあることに注意してください。

また、 SexyKanjiと呼ばれる漢字エンジンのラッパーであるフレームワークのバージョンもあり、同様の98％APIがあります。 廃止された問題を解決します（DirectX 8/9またはOpenGLで動作するため）。 さらに、クロスプラットフォームフレームワークは、喜ぶことはできません。 SexyKanjiアドオン自体はまだオープンソースですが、漢字エンジンは有料です（約300ドル）。 SexyKanjiは良いですが、それに切り替えると、いくつかのことを「終了」する必要があります。 また、このエンジンは別の会社に売却され、機能が同等のバージョンであるため、すでに1000ドルの費用がかかるという情報もありました（さらに、これは1つの職場のみです）。

Windows以外のプラットフォームで作業するためのPopCap Frameworkのバージョンもあります-これはTuxCap Frameworkです 。しかし、これを見る時間はありません。誰かがそれを使用した場合、コメントであなたの経験を説明してください。



ゲーム開発のための可能な無料の代替：

• HGE-プロから：DirectX8。 マイナスの点：DirectX8-Vista / 7ではクロスプラットフォームではなく、低レベル（IMHO）で問題が発生しますが、長い間更新されていないようです。
• Playground SDK-プロから：更新された、クロスプラットフォーム、洗練された。 マイナスのうち、1つだけですが、どれか：エンジン自体のソースコードが閉じられており、エンジンの何らかのバグに遭遇した場合、修正を待つ必要があるだけで、問題を自分で解決することはできません

STLPort

MS STLの交換。 なんで？ それから、それはより速く、より少ないメモリを消費します。 安定しており、苦情は発生しません。 お勧めです。

私はそれに慣れすぎて、 STLPortについて書くのをほとんど忘れていました 。

マイクロパス

PopCap Framework専用のフォーラムでのプロジェクトの作業の最初に、パスを見つけるためのライブラリが見つかりました： AStar Library 。

たぶん私の手は曲がっていますが、私は彼女を正常に働かせることができませんでした。 彼女は方法を見つけましたが、それはあまり最適ではありませんでした。 別の「パスファインダー」を探すことにしました。 それがMicropatherでした 。 最初は、パスキャッシングに問題がありましたが、キャッシュをどこかにドロップするのを忘れたのかもしれません。 しかし、キャッシュを無効にした後、すべてが期待どおりに機能しました。 ライブラリはシンプルで、ヘッダーファイルを含めるだけで済みます。 お勧めです。

Pugixml

このパーサーを使用して、すべてのXMLを読み取ります（PopCapフレームワークの標準であるものを除く）。 私はビルトインを使用しません あまり便利ではなく、まだエラーが発生していないかわかりません。 それに 、 PugiXMLは最速のパーサーの1つであり、速度も優れています:)

Cpptweener

C ++でパラメーターを結び付けるための類似物を見つけられなかったため、 このtweenerを使用しました 。 いくつかのエラーを修正するために何度も深くデバッグする必要がありましたが、今ではうまく機能しているように見えますが、正しい方法でコードを書き直したい場合があります。

ヤスパー

ちょうど良い非常にスマートなポインター 。 主なことは相互参照することではありません、そうでなければ動作しません、チェックされます:)しかし、PopCapはmem_leaks.txt（デバッグモード）でそれについて書き込みます。

Bass.dll

プロジェクトの初期段階では、 Audiere.dllが使用されていました。 無料で必要な機能を備えており、PopCap Frameworkとの完全な統合のためにAudiereMusicInterfaceを見つけました。 すべてうまくいきますが、いくつかのトリッキーな構成ではクラッシュします。 それは突然落ちます。 Athlon 64 X2とWindows XPで時々クラッシュしました。 有料のBass.dllに切り替えることが決定されました 。 うまく機能しているようです（致命的ではないバジャジクが1つありますが、許容できます）。 バージョン2.3.0.3を使用します-以前のバージョンには重大なバグがあり、新しいバージョンではPopCap Frameworkのライブラリサポートを書き直す必要があります。

このライブラリは、非営利目的での使用は無料です。

パイロ効果

最初に、エフェクトについては、別のOpenSourceフレームワーク（HGE）のエフェクトをねじ込むことが決定されました。 主な動機は、PopCapのエフェクトエンジン（ SexyHGEparticles ）のサードパーティポートと、HGEの無料のエフェクトエディタの存在です。 ほぼすぐに、ITを正常に使用することは不可能であることが明らかになりました。 エディターは不安定であり、エディターで複雑なことを行うことは不可能です。 また、エフェクトエンジンのポートはエディターのように機能しません。その結果、ゲーム内の重力が弱いかのようにエフェクトが奇妙な動作をしましたが、すぐには修正できませんでした。

これはしばらく続いた。 ある時点で、通常の効果がなければ、作業を続けることができなくなったため、他のライブラリとそれらのエフェクトエディタの研究を始めました。 必要なもの：PopCapフレームワークへの簡単な統合と、複雑な効果を作成する機能。

まず、 マジックパーティクルが検討されました。 強力なエディター、かなり複雑な効果を持つサンプルの大規模なデータベースのようです。 私はそれをねじ込み始めました。 画像を読み込む方法を確認するために登った理由を覚えていません。 しかし、エフェクトを作成するときに、最初にイメージをディスクに保存し、次にメモリにロードすることを見たとき（これはPopCap Frameworkに当てはまります。他のエンジンではすべて異なる可能性があります）...私はすぐにこのソリューションを拒否しました、私はそのようなものを信用しません「ハック」、そして私には通常のサポートを書く強さも欲求もありませんでした。 エディターは面白そうに見えましたが。

次の被験者はパイロです。 特にPopCapフレームワークの小さなラッパーがあるため、エフェクトのシステムを台無しにするのは非常に簡単であることが判明しました。 エディターも非常に想像されています。 しかし、それを使用した結果、次のことが判明しました：ゲーム内のすべてのエフェクトがエディターと同じように見えるわけではありません（視覚的に-色追加オプションに何か問題があります）、エディターで動作するという事実にもかかわらず、すべてのエフェクトがゲームで動作するわけではありません（たぶん何か間違ったことをしましたが、エフェクトにいくつかのオプションを含めると、ゲームでエフェクトが表示されなくなります）。 なぜなら 混乱する時間はもうありませんでしたし、パイロは私たちに適していました。



スパーク パーティクルエフェクト用のエンジンもあります。 彼は自分のネットワーク上にオープンソースのエディターさえ持っています。 しかし、私はそれをずっと後で見つけました（そして、それは私が必要とするより遅く出てきました）。 まだ使用できませんでした。エディターはすぐにはコンパイルされませんでした（一部のdllでは不十分でした）。 誰かが使用した場合-それがあなたのためにどのようにあるか教えてください。



雨/雪/砂嵐の影響のために、独自の粒子が使用されたため、よりシンプルでより普遍的なものになりました。

結論の代わりに

図書館を選ぶという私の経験によって誰かが助けられることを願っています。 結局のところ、それは言葉でのほんの数文であり、開発プロセスでは、他の誰かのコードを選んで、このコードが自分に合わないことに気付かないようにするために、いくつかの大げさなフレーズと数日間の作業です。

コメント内の質問と説明。



さて、 ゲーム自体へのリンク。