死後のエイジオブエンパイア

コンピューター店で会話を聞いて、とても笑いました。 私はショーケースで立ち止まって、PC向けのトップ10ゲームを見て、2人の男の間の次の会話を耳にしました。



「このエイジオブエンパイアについてどう思いますか？」最初の質問。



彼の友人は答えました：「ああ、マイクロソフトの企業ロボットは、単にWarcraftとCivilizationを組み合わせてお金を盗みました。」



いつものように、売り上げを伸ばそうとして、私はこの機会を利用して、 AoEは巨大企業の製品ではなく、近所に住む才能のある小さな人々のグループだと話しました。



私たちにとって、 エイジオブエンパイアは壮大なゲームであるだけでなく、アイデアを実際のゲーム開発会社に変えることにした小さなチームの壮大な旅でした。 この旅で、私たちは笑って泣き、たくさんのピザとカフェインを破壊し、ゲームの作り方について多くを学びました。

過去を再現する

明らかに、 Age of Empiresは最初は最終製品とは完全に異なって見えました。 告発にもかかわらず、Dawn of Man（名AoE ）はWarcraft IIのクローンではないはずでした。 （実際、 AoEがまだ開発中であったときにWarcraft IIがリリースされました）。



デザインは時間とともに進化し改善されてきました。 このパスに沿っていくつかの重要なイベントが発生しました。 ゲーム会社の従業員が多くの異なるゲームをプレイするのが最善のように思えます。



それはまさにEnsembleの従業員であり、私たちはPC向けにリリースされたほぼすべてのゲームを購入するプログラマーTim Deenの習慣に大いに助けられました。 アンサンブルの残りをWarcraft IIに変えたのはティムでした。 リソース管理、帝国の構築、技術研究など、多くのAoEゲーム要素がその時に形になりました。



しかし、私たちは戦いをどうするかを決めることができませんでした。 Warcraft IIは私たちにとって冷たいシャワーになり、目を覚まし、リアルタイムの戦闘がどれほど面白いかを示しました。 週に数回、私たちのチームは仕事を続け、マルチプレイヤーWarcraftをプレイしました。 このような即席の会議は、 AoEがWarcraftよりも興味深いものになるまで続きました。



デザイナーがAoEローカリゼーションプランを検討したときに、開発プロセスの途中で別の大きな変更が発生しました。 彼らは、 AoEがアジアで販売されることに気づきましたが、その地域のゲームには単一の文化はありませんでした。



私たちは総会を招集し、すでに作成された初期のヨーロッパ、アフリカ、中東の部族にアジア文明を追加することを決めました。 このような追加にはアーティストやデザイナーによるさらに多くの作業が必要でしたが、アジアでのゲームに対する注目が高まったことから、これが有益なソリューションであることが証明されました。



これらの変更はすべて、ゲームの設計者が設計に関する他の従業員のレビューを聞くことを恐れなかったために行われました。 Ensembleの誰もが誇りに思うゲームを作成することを目指しましたが、それは単なる空の言葉ではありませんでした。 おそらく、そのようなコミットメントの最良の例は、Wonder of the World、プレイヤーがゲームに勝つために構築して使用できる建物です。



1997年の初め、 AoEは競合他社に比べて見栄えが良かったが、ゲームプレイにはもっと何かが必要だと誰もが感じていた。 私たちは多くのアイデアを試し、捨てました。 その後、ネットワークプログラマーであるMark Terranoが、Doomsday Clockを作成するというアイデアを思い付きました。これにより、プレイヤーは終了して新しい問題を解決できます。 AoEには 、アーティストやプログラマーが発明した小さなアイデアやタッチがたくさんあります。 彼らがデザインの作成に参加したことで、所有感とゲームでの作業に対する誇りが著しく高まりました。



ゲームプレイのバランスに関するデザイナーの仕事は、本当に過小評価されたままでした。 デザイナーは、価格、力、速度、その他のパラメーターの調整に何ヶ月も費やし、プレイするのが面白く、「抜け穴」やチートのないゲームを作成しようとしました。



この時点で、私はティムディーンが本当に本物のゲーマーであることに気付きました。 開発プロセス中に、 AoEデザインのある種の反復により、あるプレイヤーが他のプレイヤーよりも有利になり、ゲームを1次元にした場合、ティムは確かにこれを見つけました。



そして、私たちが彼の見積もりを信じなかったとき、彼はそれを私たちに証明し、そのようなトリックの助けを借りて私たちに勝ちました。 ほとんどの場合、ゲームプレイのバランスをとることが優先事項であり、結果が得られました。RTSジャンルの他のゲームよりもAoEの寿命が長く、より優れたゲームプレイを提供しました。

マルチプレイヤートレイル

マルチプレイヤーのサポートは最初からデザインの不可欠な部分であり、 AoEはほとんどのゲームがライブプレイヤーとコンピュータープレイヤーの違いに注意を払わないように構築されました。 DirectXがリリースされたとき、DirectPlayは異なる接続オプション間のデータ転送を実装するための最良の選択であることが判明しました。



多数のモバイルユニットをサポートするために、すべてのマシンでゲーム全体が同時に実行される修正された同期ゲームモデルを使用しました。 車同士は、動き、変化、コマンドのみを交換しました。 このアプローチにより、送信されるデータの量を最小限に抑えることができました。



このモデルを使用する場合、あるマシン上のゲームが他のマシン上のゲームと同期していない状態の危険がありました。 これにより、 AoEのバグを追跡するのが非常に難しくなりました。



ゲームの更新の送信に必要な接続速度を決定するプロセスは、コンピューターAIでの作業が完了する前に実行され、ライブプレーヤーから受信したデータ転送モデルに基づいていました。 その結果、コンピュータープレーヤーが短時間で多数のチームを支援できる場合があるという事実を最初に見逃しました。



ただし、最初のパッチでこの見落としを修正しました。 AoEは 、遅延に動的に適応する際に予想よりも優れています。 変化するウィンドウはチームの使用を覆い隠したので、すべてのプレイヤーはチームを獲得することができ、チームを完了するために一時停止する必要はありませんでした。



ゲームから投げ出されたプレイヤーのステータスを処理する問題は、Mark Terranoにとって重大な障害でした。 ゲームの終了を予測することは不可能であるため、通常、何が起こったのかを知る方法はありません。 問題は、ゲームロジック、Winsock、物理的な接続またはプロバイダーにあり、送信者または受信者の側で発生した可能性があります。 すべてのマシンで常にプレイヤーのクラッシュと状態の移行を適切に処理するゲームを作成するのは非常に困難でした。



マルチプレイヤーゲームプロセスから学んだ教訓の1つは、自動ログやチェックサムなどのデータ交換テストツールを最大限に使用する必要があるということです。 さらに、単純なデータ転送シミュレーションプログラムが大きなメリットを提供し、ネットワークコードをゲームの残りの部分から分離することがわかりました。



DirectPlayにも問題がありました。 再現が難しいバグ、奇妙な動作、不十分なドキュメントにより、事態はさらに複雑になりました。 最も注目すべき例の1つは、IPXのパケット配信の保証です。 CGDCで、Microsoftはこの機能をDirectX 5に追加することを約束し、さらにベータ版に含めました。



ただし、DirectXのリリース後、この機能はどこにも見つかりませんでした。 単一の要素がないことの代償は、保証されたパッケージ配信のための独自のシステムと、テスト用の不良パッケージを生成するプログラムの作成に費やさなければならなかった時間でした。

世界を彩る

すべての2次元AoEスプライトは、3Dモデルとして始まりました。 Age of Empiresには、20 MBのゲームスプライトグラフィックスがありました。 すべてが2次元でしたが、ゲームのグラフィックスは最初から3次元モデルから取得することに決めました。 グラフィックを作成するために、3D Studioおよび3D Studio MAXを使用しました。



3Dレンダリングには時間がかかるため、各アーティストは2台のマシンを使用しました。 通常、128 MBのRAMを搭載した200 MHz Pentium Proでした。 当時、そのような「ハードウェア」はプログラマーのそれよりも強力でした。 ゲームオブジェクトは、2,000〜10万ポリゴンの3Dモデルとして作成されました。 次に、すべてのモデルがテクスチャ化され、アニメーション化され、固定の256色パレットで.FLCファイル（Autodesk Animator）にレンダリングされました。



このステップの前に、私が説明したプロセスは、他の多くのゲームで使用されているプロセスに似ています。 しかし、彼の後、アーティストは別の長いプロセスを追加しました。 .FLCファイルは、アニメーションをフレームに分割し、Photoshopで各画像を「クリーニング」する2Dスペシャリストに転送されました。



クリーニングプロセスは、パーツを強調表示し、不適切な形状の角を滑らかにすることで構成されていました。 ほとんどのAoEスプライトは画面上で20〜100ピクセルしかないため、グラフィック品質の向上は重要なステップでした。 1997年にE3でAoEが上映されたとき、アーティストは他の会社の同僚から作品について多くの賞賛を受けました。



ゲームオブジェクトに3Dモデルを使用すると、他の芸術的要素を操作するときに利点が得られました。メニュー、ステータス画面、さまざまな映画の挿入に表示される静的な背景シーンで使用できます。 3分間の入門ビデオを含むビデオ挿入物は、それ自体が本格的なプロジェクトでした。



256色パレット（実際には236色）も問題を引き起こしました。 パレットは、ほとんどのモデルやテクスチャを作成する前であっても、プロジェクトの最初に選択され採用されました。 その結果、カラースペクトルの一部（たとえば、木目テクスチャの茶色）には、高品質のグラフィックスを確保するのに十分な色がなかったことが判明しました。



パレットは、ゲーム内のすべての画像の再レンダリングと処理を必要とするため、開発プロセス中に修正されませんでした。これには時間がかかりすぎます。 一方、パレットには色の幅が広くバランスのとれた範囲があり、ゲームのグラフィックスを明るく心地よい外観にしました。 別の8ビットゲームを作成する場合、開発プロセスの少し後にパレットを生成します。

スピードアップ

パフォーマンスは、最も原始的なものを除くすべてのゲームの問題です。 それでAoEで起こりました。 私がEnsembleに来たとき、ゲームはまだ初期の形であり、非常に遅かった。 最大の2つの問題は、グラフィックエンジン（速度が低下）とさまざまな更新手順で、ゲーム内で最大1秒のランダムな一時停止が発生しました。



強力なコンピューターの所有者だけでなくゲームを販売する場合、深刻な最適化が必要でした。 AoEのこの部分でほとんどの作業を行ったため、ここでストーリーが個人的になります。



10万行を超えるC ++コードの作業を理解することから始めました（プロジェクトの終了まで、ソースコードは22万行に成長しました）。 既製のコードの研究に数週間を費やしてから、私はグラフィックエンジンの構造の大規模な処理を実行することを提案しました。



AoE開発チームは、現在の7-12 fpsから20 fpsにフレームレートを上げることが可能かどうかを尋ねました。 私は肯定的に答えました。 しかし、心の中で私はパニックに陥り、そのようなボリュームを処理できることを望みました。



古いグラフィックエンジン全体を取り除いてカットすることはできませんでした。そうしないと、他の全員の作業に干渉するため、主に新しいエンジンの作成に5か月を費やしました。 その過程で、なんとかフレームレートを10〜14 fpsに上げる小さな変更を加えることができましたが、本当のブレークスルーは、新しいアーキテクチャの最後の部分に気付いたある眠れぬ夜の後に起こりました。



驚いたことに、ベンチマークは55 fpsで実行されました。 翌日にオフィスに戻って、先ほどスローダウンしていたアニメーションが非常にスムーズに再生されるようになったのを見るのは驚くべきことでした。 しかし、私の仕事はグラフィックエンジンだけではありませんでした。



多くのゲームプロセスの解析と最適化に多くの時間を費やしました。 ゲームはリアルタイムで行われたため、多くの改善が複数のサイクルに分散され、ゲームが完了するまで停止しませんでした。 最終的に、最適化によって成果が上がり、デフォルトの解像度を640x480から800x600に上げることができました。



この経験から、次の教訓を学びました。完了に近づくほど、ゲームのブレーキングとオーバーロードが多くなる可能性があります。 多くの場合、開発の初期段階で、エンジンは高速を示しましたが、ゲームはまだ完了していません。 その後、単純なテストレベルが複雑な最終レベルに置き換えられ、AI、インターフェイス、さまざまな機能と機能が追加され、パフォーマンスが大幅に低下する可能性がありました。 AoEも同じ話をしました。 プロジェクトが完了する前に、すべての穴を閉じたときに、生産性を高めるための多くのトリックが新しい機能に交換されました。

私たちが管理したこと

1.ゲームは、エンジンとゲームの別々のコンポーネントに分割されました。 開発プロセスの途中で、一部の部分のコードベースが大きく成長し、新しい変更や追加がそれぞれ不器用なハックのように見えるという考えがありました。 主要なプログラマーであるアンジェロラウドン（アンジェロラウドン）とティムディーンは、2週間でコードベースを2つの部分に分割しました。エンジン（Genie）とゲーム（Tribe）です。



この変換は非常に成功し、 AoEプログラマーは高品質のオブジェクト指向設計を実現できました。 コードの修正と拡張がはるかに簡単になり、プログラマーの時間を大幅に節約できるという点で私たちは勝ちました。



2.データベースを介してゲームを管理しやすくしました。 オブジェクト指向のアプローチのおかげで、プログラムコードにハードコードされたAoEオブジェクトはほとんどありませんでした。 膨大な情報のテーブルには、ゲームオブジェクトの各特性が記述されていました。 ゲームを制御するために、設計者は40を超えるParadoxテーブルのシステムを使用しました。 したがって、彼らは絶えずゲームを更新およびカスタマイズし、プログラマーの参加なしに変更をテストすることができました。



3.緊密な連絡を維持し、出版社と協力しました。 出版社であるマイクロソフトとの密接な接触がAoEの開発にどれほど貢献したかを表す言葉が見つかりません。 それらがプロセスサイクルにあったという事実により、問題が発生したときに、干渉することなく、助けてくれました。



このような開発支援の最良の例は、リリーススケジュールのシフトをどのように制御したかです。 予定よりも時間がかかったり、新しい問題が発生した場合、マイクロソフトはすぐに遅延を報告しました。



何が起こっているのか、なぜ起こっているのかを明確に理解してくれたおかげで、彼らは私たちをサポートし続け、時間がかかっても質の高いゲームの作成に努めました。 したがって、私たちはパニックに陥り、緊張する代わりに、専門的で集中しました。



4.ゲームをプレイしました。 このアイテムはありふれたように見えるかもしれませんが、非常に重要です。 開発プロセス中に、会社のすべての従業員がテストしただけでなく、興味のないAoEをプレイしました。



したがって、私たちはゲームで何が面白いか、そして人々が何を見つけたかを明確に理解しました。 20人は、ゲームプレイを強力で無制限にすることを望んでいました。



5.良好な速度を達成しました。 ゲームの人気を広めたい場合、スピードは非常に重要です。 Age of Empiresは、16 MBのRAMを搭載したPentium 120の8プレイヤーゲームで非常に迅速に機能しました。 Total Annihilationと比較してください。これは8人のプレーヤーで32 MBと少なくとも200 MHzが必要でした。 このレベルのパフォーマンスを提供するには、共通の努力が必要でした。 プログラマは低メモリ消費を維持するために特別な努力を払い、ボトルネックを探しました。また、アーティストはメモリを解放するためにアニメーションの余分なフレームをカットしました。



6.会社は従業員を尊重しました。 Ensemble Studiosが従業員とその家族をどのように扱ったかを言わなければなりません。 ソフトウェア開発、特にゲームの作成には多大な時間の犠牲が必要であり、個人的な関係を破壊する可能性があることは誰もが知っています。



Ensembleの優れたリーダーシップはこれを理解し、家族を会社での頻繁な共同夕食や他のイベントに招待し、オフィスでくつろいだ気分にさせました。 厳しい締め切りの後、マネージャーは従業員が家族と会うために数日休むことを主張しました。 必要に応じて、労働者は自分自身で柔軟なスケジュールを選択でき、花やその他の感謝の兆候が定期的に家族に送られました。



これらの意図的な行動の結果は明らかでした。会社の士気と忠誠心は、14年間のソフトウェア開発で見たよりも高かったです。 私の妻は私と同じように私の仕事を愛していました。



7.思慮深いローカリゼーション。 当初から、Microsoftは日本語を含む6つの言語でAoEをリリースしたいと考えていました。 開発プロセスの約半分で、コードベースに完全なローカライズサポートを追加しました。 これを行うには、ソースコード内のすべてのテキスト行を切り取って置き換え、ゲームのすべてのテキストを外部リソースファイルに保存する必要がありました。



テキストのレンダリングと表示にも厳しい制限がありました。 多くのゲーム開発者がペストのように逃げ出したWindows GDIのみを使用できました。 さらに、これは、インターフェイス要素（ボタンなど）が、テキストの最大の翻訳に合わせてサイズ変更する必要があることを意味しました。 これにより、ユーザーインターフェイスに適用できるトリックのリストが制限されました。



しかし、私たちは袖をまくり、指示に従って正確に対処しました。 驚いたことに、そのような変換は簡単で痛みがありませんでした。 Microsoftの翻訳者から、 AoEのローカライズが最も手間のかからないプロジェクトだと言われたとき、私たちはさらに気分が良くなりました。



私たちにとって、このアプローチは大きな利点でした。ゲームのすべての翻訳バージョンについて、唯一の実行可能ファイルがあり、バグをキャッチしたり、いくつかのバージョンのアップデートをリリースしたりする大きな頭痛を回避できました。



8.私たちは、すべてのメンバーを尊重するチームとして働きました。 AoEサイジングプロジェクトでは、長く緊密なコラボレーションが必要でした。 新しい人を雇うための基準の1つは、お互いを尊重する能力でした。



この尊重は、会社の従業員のサポートによって補完され、家族とチームの精神の驚くべき感覚を生み出しました。 特定のグループがプロジェクトから隔離された感覚を作り出すことを回避したため、最も激しい仕事が行われたときでも、人間関係と士気は高いレベルのままでした。



対立やグループがあった場合、1997年にAoEをリリースできたとは思いません。

失敗したか、改善できた可能性があるもの

1.ベータテストが遅すぎた。 AoEパブリックベータは1997年8月に開始されましたが、その潜在能力を十分に活用することはできませんでした。 多くの有益なフィードバックにもかかわらず、私たちはプロジェクトに近づきすぎてゲームに変更を加えることができませんでした。 ゲームのマニュアルは印刷する準備ができており、デザイン全体をほとんど変更できませんでした。 検出されたエラーのみを修正できました。 将来のプロジェクトでは、ベータテストを以前に実施することにしました。



2. Microsoftの品質管理部門との情報交換が正しく構築されていません。 ほとんどの場合、バグ報告システムはデータベースを介して管理されており、開発者はテスターと直接通信できませんでした。 その結果、多くのエラーを修正するのにはるかに長い時間がかかり、新しい機能はテストされませんでした。



中間データベースは、テスターと開発者の間で情報を交換するには不十分でした。 将来のプロジェクトでは、各プログラマーに個別のテスターを割り当てて、情報を呼び出して交換するようにします。



開発の終わりに向かって、このようなシステムは数人のプログラマー向けに実装され、バグのテストと修正における生産性が大幅に向上しました。



3.グループリーダー間の調整を保証できない場合がありました。 対人コミュニケーションが開発を改善できる別の分野は、私たち自身の開発チームです。 各グループ（プログラマー、アーティスト、ゲームデザイナー、サウンドスペシャリスト）には、チームの各メンバーの作業を監視するリーダーがいました。 外部からチームへの新しいリクエストがあった場合にアプローチされたのはリーダーです。



AoEの開発中、圧力が高まり、このシステムは崩壊しました。 人々はお互いに直接連絡を取り合ったため、リクエストはより迅速に処理されました。 このために私たちは支払わなければなりませんでした。 人々はコードの変更やゲームへの新しいグラフィックスの追加について知らなかったため、混乱が大きくなり、時間と注意散漫になりました。 時々、何が起こっているのかを知るために、私たち全員が仕事を止めなければなりませんでした。



4.モデム接続でマルチユーザーモードを適切にテストできませんでした。 開発環境は、典型的なエンドユーザーシステムとは異なりました。 開発プロセス中に、マルチユーザーAoE機能を集中的にテストしました。



オフィスでプレイすると、大量のRAMを搭載した高速マシンが高速ローカルネットワークを介してデータを交換しました。 インターネットでゲームをテストしたとき、通信は会社のT1ネットワークによって提供されました。 しかし、テストプロセスでは、ほとんどのプレーヤーがダイヤルアップモデムを使用し、インターネットプロバイダーへの接続が遅いことを認識していませんでした。



これは私たちだけでなく、Microsoftのテストラボでも同じ状況が発生しました。 その結果、モデム接続を十分にテストしませんでした。 低速のインターネットチャネルでの低遅延のバグは、ユーザーをゲームから切断しました。 また、当社の高速ネットワークは、特定の非常に頻繁に発生するAoE条件下で、15 Kbpsの伝送周波数が必要になる可能性があるという事実を隠しました。 このような発信速度は、56 Kbpsモデムが提供できる速度の6倍です。



したがって、マルチプレイヤーゲームに関する問題の報告は、私たちにとって不快な驚きでした。 最初のパッチはこの問題を解決しましたが、状況は受け入れられませんでした。 その後、各開発者はモデムと複数のプロバイダーの接続を使用し始めました。これは、モデムのチェックがテストプロセスの重要な部分だったためです。



5.開発の個々の段階は、時間どおりにリリースする時間がない製品に依存していました。 モデムゲームが十分にテストされていない別の理由がありました：Microsoft DirectPlayのリリースと品質に関する問題。 約束され、ベータリリースに追加された機能も、最終リリースの遅延から欠落していました。



Direct X 5aは、ゲームのリリースの1か月前に利用可能になりました。 その間、ネットワークプログラマーは、Microsoftから約束されているがリリースされていない機能を実現するために、眠れない夜を過ごしました。 約束されたドライバーとSDKを待つことは、開発者にとって最も難しいテストの1つです。 マイクロソフトは私たちの出版社でしたが、私たちでさえそれを制御することはできませんでした。



6.パッチをリリースする予定はありませんでした。 パッチバージョン1.0aは成功しましたが、計画していなかったため、依然として問題を引き起こしました。 主な論点は次のとおりです。パッチを作成することがわかっている場合は、ゲームをまったくリリースしないでください。



この観点は理解できますが、最初の5万人の顧客のように開発者がゲームをテストできないことも明らかです。 購入者は、マシンでゲームを開始するときや、聞いたこともないドライバーと一緒にゲームを開始するときに、考えもしないことを試します。 私の知る限り、今年リリースされたほぼすべての主要なゲームにはパッチまたはアップデートがあります。



現実を否定する代わりに、数か月後ではなく、ゲームの販売開始から数日または数週間後にすべての必要な更新をリリースするために、リソースを割り当て、将来に備える必要がありました。



7.「突然の」イベントに対処することができませんでした。 開発プロセスでは、いくつかの状況が発生し、会社が一時的に停止されました。 たとえば、そのようなイベントは、デモ版のリリースと報道機関向けのAoE材料の準備でした。



これらのイベントの多くは会社にとって好ましいものでしたが、私たちは彼らの組織をうまく管理できず、私たちの計画はfru折しました。 これらの混乱は主に、影響が最も強く感じられた開発の後期に発生しました。 将来のゲームをリリースするときの私たちの目標の1つは、事前の通知を通じて、またそれらに応答する必要がある人の数を制限することにより、予定外のイベントの影響を最小限に抑えることです。



8.自動テストの利点を十分に活用していません。 開発の最後の数週間で、最大8人のコンピュータープレイヤーが互いに自動的に対戦するようにゲームを設定しました。 さらに、各人工知能は、開発プラットフォームとデバッガーを備えた2台目のコンピューターによって監視されました。 これらのゲームはランダムに生成されましたが、すべてのアクションのシーケンスが修正されたため、問題の原因が見つかるまで何度でもゲームを繰り返すことができました。



ゲーム自体を高速で実行することができ、一晩中働かせることができました。これは非常に便利で、問題を再現して原因を特定するのに大いに役立ちました。しかし、私たちの間違いは、開発の初期段階で行わなければならなかったことです。そのため、時間と労力を大幅に節約できます。現在、すべての将来の開発計画には、プロセスの最初からの自動テストが含まれています。





開発チーム Age of Empires 。最前列のマットプリチャード、右から2番目。

パッチを適用する

AoEプロダクションでリリースした後、ストレスを和らげるために大きなパーティーを開きました。しかし、喜ぶには時期尚早であることが判明しました。店舗の棚にAoEが登場して間もなく、パスの検索に関する問題、ユニットAIの動作、ユニット数の制限、マルチユーザーモードに関するメッセージを受け取り始めました。



さらに、プレーヤーがゲーム内で不公平な利点を活用できるバグが発見されました。 EnsembleとMicrosoftのリーダーシップが動き出し、AoEのパッチをリリースすることが決定されました。



他のプロジェクトから注意をそらさなければならず、開発が思ったよりも長く続いたという事実にもかかわらず、パッチは成功しました。彼はマルチプレイヤーゲームの品質を大幅に改善し、バグを修正し、ゲームプレイで発生した問題を解決しました。そのため、AoEの最新バージョンがありました。これはハードドライブのどこかに保存されていると思います...



[Matt Pritchardが Age of Empiresのグラフィックエンジンを作成しました。彼はまた、エイジオブエンパイアII 、エイジオブミソロジー、 BlackSite：Area 51 にも取り組みました。 ]