Одного разу я почув у комп "ютерному магазині розмову, яка дуже мене розсмішила. Я зупинився з вітриною, щоб подивитися на десятку кращих ігор для PC і підслухав наступний діалог між двома хлопцями:
«Що ти думаєш про цю Age of Empires?», - запитав перший.
Його друг відповів: «Та ну, корпоративні роботи з Microsoft просто з'єднали Warcraft і Civilization, щоб стрясти трохи грошей».
Як завжди прагнучи збільшити наші продажі, я скористався можливістю і розповів цим хлопцям про те, що AoE була продуктом не величезної корпорації, а невеликої групи талановитих людей, які живуть з ними по сусідству.
Для нас Age of Empires стала не тільки грою епічних пропорцій, це була епічна подорож невеликої команди, які вирішили перетворити ідею на справжню компанію з розробки ігор. У цій подорожі ми сміялися і плакали, знищили тонни піци і кофеїну і багато чого дізналися про те, як робляться ігри.
Відтворення минулого
Очевидно, що Age of Empires спочатку виглядала зовсім інакше, ніж кінцевий продукт. Незважаючи на звинувачення, Dawn of Man (перша назва AoE) не повинна була стати клоном Warcraft II (насправді Warcraft II була випущена вже тоді, коли AoE перебувала в процесі розробки).
Дизайн з часом еволюціонував і поліпшувався. На цьому шляху відбулося кілька важливих подій. Мені здається, що найкраще, коли співробітники ігрової компанії багато грають в різні ігри.
Саме такими були співробітники Ensemble, і нам великою мірою допомагала звичка програміста Тіма Діна (Tim Deen) купувати майже кожну випущену для PC гру. Саме Тім звернув увагу іншої частини Ensemble на Warcraft II. У той час знайшли форму багато ігрових елементів AoE, такі як управління ресурсами, побудова імперії і дослідження технологій.
Однак ми не могли вирішити, що робити з боями. Warcraft II стала для нас холодним душем, вона розбудила нас і показала, наскільки цікавими можуть бути бої в реальному часі. Кілька разів на тиждень наша команда залишалася на роботі і грала в багатокористувацький Warcraft. Такі імпровізовані зустрічі тривали до тих пір, поки AoE не стала більш цікавою, ніж Warcraft.
Ще одна важлива зміна відбулася приблизно в середині процесу розробки, коли дизайнери подивилися на плани локалізації AoE. Вони усвідомили, що AoE буде продаватися в Азії, але в грі немає жодної культури з цього регіону.
Ми скликали загальні збори і вирішили додати до вже створених ранніх європейських, африканських і середньосхідних племен ще й азіатські цивілізації. Хоча таке доповнення зажадало ще більше праці художників і дизайнерів, підвищена увага, приділена грі в Азії, довела, що це стало вигідним рішенням.
Всі ці зміни вносилися тому, що дизайнери гри не боялися прислухатися до відгуків інших співробітників про дизайн. Ми прагнули створити гру, якою будуть пишатися всі в Ensemble, і це не було порожніми словами. Напевно, найкращим прикладом такої прихильності стало Чудо світу, будівлю яке гравець міг побудувати і використовувати для перемоги в грі.
На початку 1997 року AoE відмінно виглядала на тлі конкурентів, але всі відчували, що геймплею потрібно щось більше. Ми пробували і відкидали безліч ідей. Потім наш мережевий програміст Марк Террано (Mark Terrano) придумав ідею створення «Годин Судного дня», які змусять гравців кинути все і вирішувати нову проблему. В AoE купа дрібних ідей і штрихів, придуманих художниками і програмістами. Їхня участь у створенні дизайну помітно посилила почуття причетності та гордості за роботу над грою.
По-справжньому недооціненою залишилася робота дизайнера з балансування ігрового процесу. Дизайнери витратили довгі місяці на регулювання цін, сил, швидкості та інших параметрів, прагнучи створити гру, в яку буде цікаво грати, і в якій не буде всяких «лазівок» і читів.
На цьому етапі я усвідомив, що Тім Дін дійсно справжнісінький геймерський геймер. Якщо в процесі розробки якась ітерація дизайну AoE давала одному гравцеві переваги над іншими і робила гру одномірною, то Тім обов'язково це виявляв.
І коли ми не вірили його оцінкам, він доводив нам це, виграючи у нас за допомогою таких хитрощів. Більшу частину часу балансування геймплея було пріоритетним завданням, і це дало результати: AoE прожила довше і забезпечувала більш якісний геймплей, ніж інші ігри в жанрі RTS.
Стежкою мультиплеєра
Підтримка мультиплеєра була невід'ємною частиною дизайну з самого початку, і AoE будувалася таким чином, щоб більша частина гри не звертала уваги на відмінності між живими і комп'ютерними гравцями. Коли випустили DirectX, з'ясувалося, що DirectPlay буде найкращим вибором для реалізації передачі даних між різними варіантами з'єднань.
Для підтримки великої кількості рухомих юнітів ми використовували змінену синхронну модель гри, в якій вся гра одночасно виконувалася на всіх машинах. Машини обмінювалися між собою тільки рухами, змінами і командами. Такий підхід дозволяв мінімізувати обсяг переданих даних.
При використанні цієї моделі існувала небезпека виникнення стану, при якому гра на одній машині розсинхронізується з грою на інших машинах. Це призводило до дуже важко відстежуваних багів в AoE.
Процес визначення швидкості з'єднання, необхідної для передачі оновлень гри, виконувався до завершення роботи над комп'ютерним ШІ, і був заснований на моделі передачі даних, отриманої від живих гравців. В результаті ми спочатку упустили той факт, що комп'ютерні гравці можуть іноді давати велику кількість команд за короткий проміжок часу.
Однак ми виправили цю помилку першим патчем. AoE краще, ніж очікувалося, проявила себе в динамічній адаптації до затримок. Вікно окладувало застосування команди, тому всі гравці встигали отримувати команди і для їх виконання не були потрібні паузи.
Проблема обробки стану гравців, викинутих з гри, представляла для Марка Террано серйозну перешкоду. Оскільки вихід з гри передбачити неможливо, то зазвичай немає ніякого способу дізнатися, що сталося. Проблема могла полягати в ігровій логіці, Winsock, фізичному з'єднанні або провайдері, і виникала на боці відправника або одержувача. Дуже складно було змусити гру правильно обробляти вильоти гравців і передачу стану завжди і для всіх машин.
Одним з уроків, отриманих від процесу багатокористувацької гри, стало те, що потрібно максимально використовувати інструменти тестування обміну даними, такі як автоматизовані логи і перевірка контрольних сум. Крім того, ми виявили, що проста програма симуляції передачі даних дає великі переваги і ізолює мережевий код від решти гри.
У DirectPlay теж виникали проблеми. Насилу відтворювані баги, дивна поведінка і погана документація ще більше все ускладнювали. Одним з найпомітніших прикладів була гарантована доставка пакетів для IPX. На CGDC компанія Microsoft обіцяла додати цю функцію в DirectX 5 і навіть включила її в бета-версію.
Однак після випуску DirectX цієї функції ніде не було. Ціною відсутності єдиного елемента став час, який довелося витратити на написання власної системи гарантованої доставки пакетів і програми-генератора поганих пакетів для її тестування.
Розмальовуємо світ
Всі двомірні спрайти AoE починали своє життя як 3D-моделі. В Age of Empires було 20 МБ ігрової спрайтової графіки. Навіть незважаючи на те, що все було двомірним, ми з самого початку вирішили, що графіка в грі буде взята з тривимірних моделей. Для створення графіки ми використовували 3D Studio і 3D Studio MAX.
Оскільки 3D-рендеринг вимагав багато часу, кожен художник використовував по дві машини. Зазвичай це були 200-мегагерцеві Pentium Pro з 128 МБ ОЗУ. На той час таке «залізо» було потужнішим, ніж у наших програмістів. Об'єкти гри створювалися як 3D-моделі від двох тисяч до ста тисяч полігонів. Потім всі моделі текстурувалися, анімувалися і рендерилися у файл .FLC (Autodesk Animator) з фіксованою 256-кольоровою палітрою.
До цього етапу описаний мною процес схожий на використовуваний у багатьох інших іграх. Але після нього художники додали ще один довгий процес. Файли .FLC передавалися фахівцеві з 2D, який розділяв анімацію по кадрах і «очищав» кожне зображення в Photoshop.
Процес очищення полягав у виділенні деталей та згладжуванні кутів невідповідних форм. Оскільки більшість спрайтів AoE мала на екрані розмір всього 20-100 пікселів, удосконалення якості графіки було важливим етапом. Коли AoE показували на E3 1997 року, художники отримали безліч компліментів про свою роботу від їхніх колег з інших компаній.
Використання 3D-моделей для ігрових об'єктів давав переваги при роботі і над іншими художніми елементами: їх можна було використовувати в статичних фонових сценах, що з'являлися в меню, екранах статусу і різних кінематографічних вставках. Відеовставки, включаючи трихвилинний вступний ролик, самі по собі були повномасштабним проектом.
256-кольорова палітра (насправді 236-кольорова) теж становила проблему. Панель було обрано і прийнято на початку проекту, ще до створення більшості моделей і текстур. У результаті виявилося, що деякі частини колірного спектра, наприклад, коричневий для текстур дерева, мали недостатньо кольорів для забезпечення високої якості графіки.
Палітру не переглядали в процесі розробки, тому що це вимагало б повторного рендерінга і обробки всіх зображень у грі, а це занадто витратно за часом. З іншого боку, на палітрі був широкий і добре збалансований діапазон кольорів, що надавав графіці гри яскравий і привітний вигляд. Якби ми робили ще одну 8-бітну гру, то згенерували б палітру трохи пізніше в процесі розробки.
Розвиваємо швидкість
Продуктивність буває проблемою у всіх іграх, крім найбільш примітивних. Так сталося і з AoE. Коли я прийшов в Ensemble, гра все ще перебувала в початковій формі і сильно гальмувала. Двома найбільшими проблемами були графічний движок (він гальмував) і різні процедури оновлення, що призводили до випадкових паузів у грі аж до однієї секунди.
Якщо ми збиралися продавати гру не тільки власникам потужних комп'ютерів, то була потрібна серйозна оптимізація. Тут історія стає особистою, тому що більшу частину роботи над цією частиною AoE робив я.
Я почав з того, що постарався розібратися в роботі більше ста тисяч рядків коду на C++ (до кінця проекту вихідний код зріс до 220 тисяч рядків). Витративши на вивчення готового коду кілька тижнів, я запропонував провести масштабну переробку структури графічного движка, в тому числі переписати більшу частину на асемблері.
Команда розробників AoE запитала, чи можна збільшити частоту кадрів з поточних 7-12 fps до 20 fps. Я відповів позитивно. Але в душі я панікував і сподівався, що зможу впоратися з таким обсягом.
Я не міг просто взяти і вирізати весь старий графічний движок, інакше я завадив би роботі всіх інших, тому витратив наступні п'ять місяців в основному на створення нового движку. У процесі мені вдалося внести невеликі зміни, що підвищили частоту кадрів до 10-14 fps, але справжній прорив стався після однієї безсонної ночі, коли я реалізував останню частину нової архітектури.
На мій подив, бенчмарк тепер працював з частотою 55 fps. Було дивно повертатися в офіс наступного дня і бачити, як анімація, яка гальмувала раніше, стала програватися дуже плавно. Але моя робота полягала не тільки в графічному движку.
Багато часу я витратив на розбір і оптимізацію безлічі ігрових процесів. Гра проходила в реальному часі, тому багато удосконалення розподілялися на кілька циклів, а не зупиняли гру до свого завершення. Зрештою оптимізації виправдали себе і дозволили нам збільшити роздільну здатність за замовчуванням з 640x480 до 800x600.
З цього досвіду я виніс наступний урок: чим ближче до завершення, тим більш гальмівною і перевантаженою може ставати гра. Часто на ранніх етапах розробки движок демонстрував високу швидкість, але гра ще не була завершена. Потім прості тестові рівні замінювалися на складні остаточні, додавався AI, інтерфейс, різні функції і можливості, і продуктивність могла значно знизитися. З AoE була така ж історія. Перед завершенням проекту, коли ми робили всі діри, багато з трюків для підвищення продуктивності обміняли на нові функції.
Те, що нам вдалося
1. Гра була розбита на окремі компоненти движку і гри. Приблизно на середині процесу розробки у нас виникли думки, що кодова база в деяких частинах сильно розрослася, а кожна нова зміна і доповнення виглядало незграбним хаком. Провідний програміст Енджело Лоудон (Angelo Laudon) і Тім Дін за два тижні розділили кодову базу на дві окремі частини: рушій (Genie) і гру (Tribe).
Це перетворення виявилося дуже успішним і дозволило програмістам AoE домогтися якісного об'єктно-орієнтованого дизайну. Ми виграли в тому, що код стало набагато простіше змінювати і розширювати, і це заощадило програмістам купу часу.
2. Ми зробили гру керованою через базу даних. Завдяки об'єктно-орієнтованому підходу майже ніякі об'єкти AoE не були жорстко прописані в коді програми. Величезні таблиці інформації описували кожну з характеристик ігрових об'єктів. Для керування грою дизайнери використовували систему з більш ніж сорока таблиць Paradox. Тому вони могли постійно оновлювати і налаштовувати гру, а потім тестувати зміни без участі програмістів.
3. Ми підтримували тісний контакт і працювали разом з видавцем. Не можу знайти слів, щоб висловити, наскільки близький контакт з нашим видавцем, Microsoft, допоміг нам у розробці AoE. Завдяки тому, що вони перебували в циклі процесу, при виникненні проблем вони допомагали нам, а не заважали.
Найкращим прикладом такої допомоги в розробці є те, як ми керували зрушенням графіка випуску. Коли щось займало більше часу, ніж заплановано, або виникали нові проблеми, ми швидко повідомляли про затримку в Microsoft.
Завдяки чіткому розумінню того, що і чому відбувається, вони продовжували підтримувати нас, прагнучи до створення якісної гри, незважаючи на час, який для цього буде потрібно. Тому замість того, щоб панікувати і нервувати, ми залишалися професійними і зосередженими.
4. Ми грали в свою гру. Цей пункт може здаватися банальним, але це дуже важливо. У процесі розробки всі співробітники компанії не тільки тестували, але і грали в AoE з інтересу.
Тому ми чітко розуміли, що в грі розважає, і що в ній знаходять люди. Двадцять людей прагнули до того, щоб ігровий процес був сильним і не мав обмежень.
5. Ми досягли хорошої швидкості. Швидкість дуже важлива, якщо ви хочете домогтися широкої популярності гри. Age of Empires досить швидко працювала в грі з вісьмома гравцями на Pentium 120 з 16 МБ ОЗУ. Порівняйте з Total Annihilation, якій для восьми гравців потрібно було 32 МБ і не менше 200 МГц. Забезпечення такого рівня продуктивності потребувало загальних зусиль. Програмісти вкладали особливі зусилля до того, щоб зберегти низьке споживання пам'яті, і шукали вузькі місця, а художники урізали зайві кадри анімації, щоб звільнити пам'ять.
6. Компанія поважала своїх співробітників. Повинен сказати про те, як Ensemble Studios поводилася зі своїми співробітниками і їх сім'ями. Всім відомо, що розробка ПЗ, а особливо створення ігор, вимагає величезних жертв часу і може руйнувати особисті стосунки.
Розумне керівництво Ensemble розуміло це і запрошувало сім'ї на часті спільні вечері в компанії і на інші заходи і робило так, щоб вони відчували себе в офісі як вдома. Після напружених дедлайнів керівники наполягали, щоб співробітники брали відпустки на пару днів для зустрічі з сім'ями. Працівники могли при необхідності вибирати собі гнучкі графіки, а сім'ям періодично відправляли квіти та інші знаки вдячності.
Результати цих продуманих дій були очевидними: моральний дух і лояльність у компанії були вищими, ніж я бачив за чотирнадцять років розробки ПЗ. Моя дружина полюбила мою роботу так само, як і я.
7. Продумана локалізація. З самого початку ми знали, що Microsoft хоче випустити AoE шістьма мовами, в тому числі японською. Приблизно в середині процесу розробки ми додали в кодову базу повну підтримку локалізації. Для цього потрібно вирізати і замінити у вихідному коді всі текстові рядки та зберігати весь текст гри у зовнішньому файлі ресурсів.
Також існували суворі обмеження на відмальовування та відображення тексту. Нам можна було використовувати виключно Windows GDI, від якого багато розробників ігор бігли, як від чуми. Крім того, це означало, що елементи інтерфейсу (наприклад, кнопки) повинні були мати такі розміри, щоб у них вміщувалися найбільші переклади їх текстів. Це обмежувало список хитрощів, які можна було застосовувати в користувальницькому інтерфейсі.
Але ми закатали рукави і впоралися, точно дотримуючись інструкцій. На наш подив, такі перетворення виявилися безболісними і легкими. Ми відчули себе ще краще, коли перекладачі з Microsoft сказали нам, що локалізація AoE стала для них найбільш безпроблемним проектом.
Для нас такий підхід став величезною перевагою: для всіх перекладених версій гри у нас був єдиний виконуваний файл, що дозволило нам уникнути величезного головного болю від виловлювання багів і випуску оновлень для декількох версій.
8. Ми працювали як команда, що поважає всіх своїх членів. Проект розмірів AoE вимагав нашої довгої спільної роботи в тісному контакті. Одним із критеріїв найму нових людей була можливість поважати один одного.
Така повага, доповнена підтримкою співробітників компанією, створювала дивовижне відчуття сім'ї і командного духу. Ми уникали того, щоб у окремих груп створювалося почуття ізольованості від проекту, тому відносини і моральний дух залишалися на високому рівні навіть в моменти найбільш напруженої роботи.
Якби у нас виникали конфлікти і угруповання, то не думаю, що ми б встигли випустити AoE в 1997 році.
Що нам не вдалося або можна було зробити краще
1. Бета-тестування провели занадто пізно. Публічний бета-тест AoE почався в серпні 1997 року, але ми не змогли повністю використовувати його потенціал. Ми були занадто близько до кінця проекту, щоб вносити в гру якісь зміни, незважаючи на безліч корисних відгуків. Керівництва до гри вже були готові до друку, і майже весь дизайн не можна було змінити. Ми могли тільки виправити виявлені помилки. Для майбутніх проектів ми вирішили проводити бета-тестування раніше.
2. Обмін інформації з відділом контролю якості в Microsoft був побудований неправильно. Здебільшого система лід-репортів управлялася через базу даних і розробники не могли спілкуватися безпосередньо з тестерами. В результаті на усунення багатьох помилок знадобилося набагато більше часу, а нові функції не тестувалися.
Проміжної бази даних було недостатньо для обміну інформацією між тестерами та розробниками. У майбутніх проектах ми хотіли б призначити кожному програмісту окремого тестера, щоб вони зідзвонювалися і обмінювалися інформацією.
Ближче до кінця розробки таку систему реалізували для пари програмістів, і їх продуктивність у тестуванні та виправленні помилок сильно підвищилася.
3. Іноді нам не вдавалося забезпечувати координацію між лідерами груп. Ще одна область, в якій міжособистісна комунікація могла б поліпшити розробку - це наші власні групи розробників. У кожної з груп (програмістів, художників, гейм-дизайнерів і фахівців зі звуку) був лідер, який стежить за роботою кожного члена своєї команди. Саме до лідерів зверталися в разі появи нових запитів до команди зі сторони.
У процесі розробки AoE тиск збільшувався, і ця система зруйнувалася. Люди спілкувалися безпосередньо один з одним, щоб їхні запити виконувалися швидше. За це нам довелося заплатити. Люди не знали про зміни в коді або додавання нової графіки в гру, плутанина наростала, що призводило до витрат часу і відволікання уваги. Іноді всім нам доводилося зупиняти роботу, щоб з'ясувати, що відбувається.
4. Нам не вдалося адекватно протестувати багатокористувацький режим з модемними з'єднаннями. Середовище розробки було несхоже на типові системи кінцевих користувачів. У процесі розробки ми інтенсивно тестували багатокористувальні функції AoE.
Коли ми грали в офісі, наші швидкі машини з великими обсягами ОЗУ обмінювалися даними по високошвидкісній локальній мережі. Коли ми тестували гру по Інтернету, зв'язок забезпечувала мережа T1 компанії. Але в процесі тестування ми не здогадалися, що більшість гравців буде використовувати dial-up-модеми і повільне підключення до Інтернет-провайдерів.
І так сталося не тільки у нас, та ж ситуація виникла в тестових лабораторіях Microsoft. В результаті ми недостатньо добре протестували модемні з'єднання. Нешкідливі при низьких затримках баги приводили на повільних Інтернет-каналах до відключення користувачів від гри. І наша високошвидкісна мережа приховала той факт, що при певних, досить часто виникаючих умовах AoE могла бути потрібна частота передачі в 15 Кбіт/с. Така вихідна швидкість в шість разів більше, ніж міг забезпечити модем на 56 Кбіт/с.
Тому повідомлення про проблеми з багатокористувальницькою грою стали для нас неприємним сюрпризом. Хоч наш перший патч і вирішив цю проблему, ситуація була неприйнятною. Після цього кожен розробник почав використовувати модем і з'єднання декількох провайдерів, тому що перевірка роботи за модемом була важливою частиною процесу тестування.
5. Окремі етапи розробки залежали від продуктів, які не встигали випускати вчасно. Була ще одна причина того, що ігри за модемом тестувалися недостатньо: проблеми з випуском і якістю DirectPlay Microsoft. Функції, обіцяні і навіть додані в бета-релізи, були відсутні у випущеному із затримкою фінальному релізі.
Direct X 5a став доступний нам тільки за місяць до випуску гри. Тим часом наш мережевий програміст проводив безсонні ночі, реалізуючи обіцяні нам Microsoft, але не випущені функції. Очікування обіцяних драйверів і SDK - одне з важких випробувань для розробника. Нашим видавцем була сама Microsoft, але навіть у нас не було над цим контролю.
6. У нас не було планів випуску патчів. Патч версії 1.0a, хоча і був успішний, все одно викликав проблеми, тому що ми його не планували. Головний аргумент був таким: якщо ви знаєте, що збираєтеся робити патч, то не варто випускати гру взагалі.
Можна зрозуміти цю точку зору, але також ясно, що жоден розробник не зможе протестувати гру так, як перші 50 тисяч покупців. Покупці будуть пробувати такі речі, про які ви навіть не задумаєтеся, запускаючи гру на машинах і з драйверами, про які ви навіть не чули. Наскільки я знаю, майже для кожної великої гри, випущеної цього року, з'явився патч або оновлення.
Замість того, щоб заперечувати реальність, нам потрібно було виділити ресурси і підготуватися до майбутнього, щоб випустити всі необхідні оновлення через кілька днів або тижнів після початку продажів гри, а не через місяці.
7. У нас не виходило справлятися з «раптовими» подіями. У процесі розробки виникло кілька ситуацій, які призвели до тимчасового припинення роботи компанії. Наприклад, такими подіями були випуск демо-версії і підготовка матеріалів про AoE для преси.
Хоча багато з цих подій були для компанії сприятливими, ми не дуже справлялися з їх організацією і наші плани зривалися. Ці зриви в основному відбувалися на пізніх етапах розробки, коли їх вплив відчувався найбільш сильно. Одна з наших цілей при випуску майбутніх ігор - мінімізувати вплив незапланованих подій за допомогою попередніх повідомлень і обмеженням кількості людей, які повинні на них реагувати.
8. Ми недостатньо користувалися перевагами автоматичного тестування. В останні тижні розробки ми налаштували гру на автоматичну битву до восьми комп'ютерних гравців один проти одного. Крім того, за кожним штучним інтелектом спостерігав другий комп'ютер, оснащений платформою розробки і зневадником. Ці ігри генерувалися випадковим чином, але послідовність всіх дій фіксувалася, так що ми могли повторювати будь-яку гру знову і знову, поки не вдасться знайти причину проблеми.
Самі ігри можна було виконувати на підвищеній швидкості і їх залишали працювати на всю ніч. Це було дуже зручно і дуже допомогло нам у відтворенні проблем і визначенні їх причин. Але наша помилка була в тому, що це потрібно було зробити на більш ранніх етапах розробки. Так би ми заощадили величезний обсяг часу і праці. Тепер всі плани майбутніх розробок включають в себе автоматичне тестування з самого початку процесу.
Збірка розробників Age of Empires. Метт Прітчард в передньому ряду, другий праворуч.
Накладаємо латки
Після випуску в AoE виробництво ми закотили велику вечірку, щоб трохи скинути стрес. Але виявилося, що радіти поки ще рано. Незабаром після появи AoE на полицях магазинів ми почали отримувати повідомлення про проблеми з пошуком шляхів, поведінкою ШІ юнітів, обмеженнями кількості юнітів і багатокористувальницьким режимом.
Крім того, виявилися баги, що дозволяли гравцеві експлуатувати в грі нечесні переваги. Керівництво Ensemble і Microsoft прийшло в рух, і було прийнято рішення випустити для AoE патч.
Незважаючи на те, що довелося відволіктися від інших проектів і розробка тривала більше, ніж хотілося, патч був успішним. Він сильно поліпшив якість багатокористувальних ігор, виправив помилки і вирішив проблеми, що виникли в ігровому процесі. І так виникла сучасна версія AoE, яка, як я сподіваюся, зберігається у вас десь на жорсткому диску...
[Метт Прітчард створював графічний движок для Age of Empires. Також він працював над Age of Empires II, Age of Mythology і BlackSite: Area 51.]
