Герои умирают
Коллекционное издание
Игровые студии
Activision Blizzard вылетела с рынка Китая из-за глупого недопонимания
В ноябре прошлого года Activision Blizzard приняла шокирующее решение - внезапно разорвала партнерство с NetЕase спустя 14 лет сотрудничества. Именно благодаря ей Blizzard могла продавать в Китае такие игры, как Overwatch и World of Warcraft. Теперь мы знаем, что было яблоком раздора. Согласно информации New York Times, NetЕase предположила, что может повлиять на китайские регулирующие органы в процессе запланированного приобретения Microsoft Activision. Это заявление, по словам NetEase, было задумано как примирительный жест, но руководство Activision интерпретировало его как угрозу. Через месяц после этой ситуации компании прекратили сотрудничество.
Две стороны обсуждали условия продления своего контракта через Zoom, время от времени используя переводчиков для облегчения общения. Исполнительный директор NetEase Уильям Дин хотел, чтобы их компании переключились на «лицензионную» сделку, а не на отношения, основанные на дистрибуции. Это изменение было бы более выгодным для NetEase, а также, как утверждала компания, лучше соответствовало бы новым правительственным постановлениям. В сентябре 2021 года капитализация NetEase снизилась на 60 миллиардов долларов после того, как китайские регуляторы объявили об ограничениях на количество часов, в течение которых дети могут играть в видеоигры. Таким образом, на издателя оказывалось финансовое давление, чтобы прийти к более выгодной сделке.
Хоть Бобби Котик и был готов к этому соглашению, он оставался обеспокоенным тем, что лицензионная сделка повлияет на переговоры регулирующих органов, связанные с приобретением Microsoft. В ответ на эти опасения Дин предложил Котику повлиять на китайское правительство, чтобы оно либо предотвратило покупку, либо разрешило приобретение Microsoft, которое в то время рассматривалось китайскими регулирующими органами.
Согласно источникам из NetEase, Microsoft пришлось бы иметь дело с китайскими нормативными правовыми актами, если бы она не передала собственность Activision Blizzard в NetEase.
The Times утверждает, что руководители Activision посчитали угрозой ответ NetEase Котику. После встречи Activision предложила NetEase лицензионную сделку, если компания заплатит 500 миллионов долларов авансом, чтобы компенсировать затраты на сложности с регулированием. Сообщается, что NetEase отклонила это предложение, назвав его «коммерчески нелогичным».
Продажа игр в Китае — драконовский процесс по сравнению с другими рынками. Как отечественным, так и зарубежным издателям игр приходится бороться с Национальным управлением печати и публикаций Китая (NPPA). Оно утверждает отдельные бренды, которые могут быть проданы китайским потребителям. С июля 2021 года по апрель 2022 года управление вообще прекратило согласовывать игры, в результате чего почти 14 000 игровых компаний ушли с китайского рынка.
Ранее у двух компаний также были разногласия. В 2018 году NetEase инвестировала в Bungie 100 миллионов долларов, что, как сообщается, вызвало недовольство Котика. Activision была партнером Destiny, а Bungie отставала от графика в разработке нового контента для своего популярного шутера, поэтому Котик считал, что внедрение NetEase потенциально может отвлечь разработчика от выполнения этой задачи. В том же году NetEase инвестировала в игровую компанию, основанную бывшим сотрудником Activision. The Times сообщила, что эти инвестиции заставили Котика рассмотреть возможность досрочного прекращения их партнерства.
«К сожалению, Activision Blizzard продолжает изводить и издеваться над компаниями и регуляторами по всему миру, выдвигая необоснованные обвинения, чтобы отвлечь всех от своих реальных проблем», — написала NetEase в заявлении для Kotaku. «Наши недавние переговоры выявили явное несоответствие между двумя компаниями как в коммерческом плане, так и в корпоративных ценностях. Поэтому мы решили, что не в наших долгосрочных интересах служить краткосрочным целям нынешнего руководства Activision Blizzard или отклоняться от наших основополагающих принципов». Приобретение Microsoft компании Activision Blizzard — это бардак, за который платят обычные люди. NetEase уволила или переназначила большую часть персонала из команды, которая работала над играми Activision Blizzard в Китае. И эти игры пользовались огромной популярностью в китайском игровом сообществе. Игрок World of Warcraft из Пекина сказал, что MMO поддерживала его связь с «тысячами людей с 2005 года». «Больше всего меня сейчас беспокоит то, что эта дружба исчезнет», — сказал он Times.
PS: перевёл статью с сайта Kotaku. Попытался найти данную новость на Пикабу, но не нашёл. Заранее извиняюсь, если похожий пост всё же есть.
Еще больше новостей, в моем Telegram-канале.
Трудные времена на пути к Starcraft 3/3
Patrick Wyatt, бывший вице-президент и старший разработчик Blizzard, рассказывает о кошмарном пути разработки Starcraft.
Часть 3/3
Прокладка путей для игровых юнитов это что-то, что игроки не замечают, пока все работает как надо, но малейшие баги в этой системе могут вызывать настоящую ярость. В ходе разработки Старкрафта были времена, когда прокладка путей не работала вообще.
Разработка Стракрафта волочилась, и временами казалось, что мы никогда его не закончим: игра все время была “в двух месяцах до старта”, при этом совершенно не приближаясь к мифической дате выхода. “К счастью” — я употребляю этот термин обдуманно — у Blizzard был богатый опыт затяжки сроков сдачи игр.
Мы всегда держали в уме цели по датам выхода (или лучше сказать желания), но мы старались ничего публично не анонсировать, пока не были уверены в высокой вероятности, что все будет действительно готово в нужный момент. Политика Blizzard “когда будет готово” это отражения того, что никто толком не знал, когда именно все будет готово и результат желания выпускать качественные продукты.
На каждом этапе движения проекта к его завершению появлялась кипа проблем, которые задерживали выпуск. Как любая игра на поздних этапах разработки, наша изобиловала дефектами, которые следовало найти и исправить до выхода игры. Счет багов шел на тысячи.
Многие из них были весьма тривиальными и не требовали большого труда для исправления. Но к сожалению не все баги можно было отнести к таковым.
Некоторые, как к примеру баги синхронизации в мультиплеерных играх, выскакивали и требовали привлечения от нескольких разработчиков и, иногда, недель усилий для исправления. Другие разработчики тоже упоминали о подобных проблемах с синхронизацией игр: например Age of Empires и Supreme Commander.
Некоторые проблемы были вызваны самим ходом процесса разработки. К примеру авианосец протосов постоянно запаздывал по отношению к другим юнитам, так как отличным от других образом делал... все. В какой-то момент код Авианосца отделился от основного кода безо всякой надежды на реинтеграцию. Каждый раз, когда остальные юниты получали новую фичу, её приходилось отдельно внедрять для авианосца. И когда мы исправляли баг в юнитах, позже он всплывал отдельно для авианосца, только найти и поправить его было труднее.
Но самой большой проблемой тормозящей процесс разработки на месте была прокладка путей.
Не то чтобы прокладка путей вообще не работала, в большинстве случаев все работало как надо. Но было огромное количество пограничных ситуаций, которые удерживали игру от выхода.
Юниты застревали и останавливались посреди поля боя. Часто они с неимоверными усилиями продвигались вперед дюйм за дюймом или зацикливались и ходили кругами, отказываясь отправляться к указанным целям, а иногда их заклинивало и они застревали на месте. Целые армии увязали на месте, как будто решили устроить пикник.
Эта проблема портила настроение игроков, а также сильно ослабляла ИИ, делая невозможным сбалансировать миссии.
Хотя я никогда не был игроком RTS высшего уровня, я стал неплохо играть, поскольку обнаружил, что Голиаф был сделан сильно имбалансным, чтобы компенсировать его проблемы с продвижением по карте. Они были больше других наземных юнитов и требовали более широких пространств для прохода, но я научился протаскивать их через все преграды, доставляя из огневую мощь туда, куда мне было необходимо, и обыгрывать макро-игроков, которые в другой ситуации порвали бы меня в клочья. Увы, мое счастье длилось недолго: Голиафы довели до ума и понёрфили. Эх...
Ранняя прокладка путей была примерной — хотя были выбраны хорошие алгоритмы, управлявшие движением юнитов, кое-какие плохие решения, сделанные в процессе разработки поломали малину.
Как мы до такого дошли?
В ранних статьях я упоминал сложности с прокладкой путей. Старкрафт был сделан на движке Варкрафт, который отрисовывал рисунок местности на используя алгоритм, оптимизированный для вывода квадратных “плиток” 32х32 пикселя, состоявших из 16 клеток 8х8 пикселей. Я создал движок Варкрафта таким образом, поскольку такой подход отлично работал на всех наших изданиях для Super Nintendo и Genesis. Эти консоли имели аппаратную поддержку отрисовки плиток 8х8 пикселей, которую мы могли легко програмно эмулировать на PC.
Перспектива в Варкрафт I и II была практически вертикальной и грани объектов (лесов, ландшафта, зданий) были горизонтальными или вертикальными, так что восприятие мира графическим движком вполне подходило и для прокладки путей. В тех играх каждый квадрат 32х32 был либо проходимым, либо непроходимым. Внизу я показал границы некоторых квадратов. Некоторые, которые с первого взгляда кажутся проходимыми, на самом деле таковыми не являются. Бараки на рисунке не влезают на площадку 48х48 целиком, из за чего два красных квадрата только кажутся проходимыми.
Однако по ходу дела команда разработчиков переключилась на изометрическое изображение, которое дело игру визуально привлекательнее. Но графический движок не был переписан, художники просто перерисовали все эскизы соответствующим образом.
Новый вид отлично выглядел, но чтобы заставить прокладку путей работать, пришлось увеличить разрешение квадратов. Теперь квадраты 8х8 были проходимыми или непроходимыми, что увеличило размер карты прокладки путей в 16 раз. Новое разрешение позволило размещать на карте больше юнитов, но также увеличило количество вычислений для прокладки путей в новом пространстве.
Самой большой проблемой оказалось то, что диагональные границы, нарисованные художниками делили квадраты на неравные части, делая трудным определение того, проходим квадрат или нет. Обеспечить корректную разметку проходимости требовало чудовищных усилий.
А редактор карт в Старкрафт писать было невообразимо сложно поскольку постоянно возникало огромное число коллизий на границе квадратных полей в которые были вписаны изометрические рисунки. Написание кода подгонки границ квадратов потребовало месяцев программистских усилий.
В отличие от Diablo, использовавшего изометрический графический движок, команда Старкрафта упорно придерживалась квадратной отрисовки, хотя новые проблемы с этим подходом возникали каждую неделю.
На рисунке показано, как мост разбивается на квадраты 8х8 пикселей и близкое к изометрическому изображение делит квадраты на неравные части, формируя “лесенку” непроходимых квадратов на каждой стороне моста, там где вы видите, как красная линия режет квадраты на неправильные фигуры.
Поскольку проект завис в состоянии “двух месяцев до выхода”, у нас не было возможности создать заново движок построения местности, который облегчил бы задачу нахождение путей, стояла задача просто во что бы то не стало заставить прокладку путей работать. Пришлось учитывать все возможные граничные случаи, из-за чего код прокладки путей взрывообразно разросся в машину состояний, содержащую самые разнообразные приемы выхода из сложных ситуаций. (Народ изучавший, код Стракрафт пишет, что было прописано 35 состояний двигающегося юнита - masuk0)
Час пик
Если можно назвать еще одну крупную проблему с прокладкой путей, то это будет толкучка, создававшаяся харвестрами (КСМ терранов, зонд протоссов и дрон зергов), собиравшими кристаллы (позже названные минералами) и газ беспен, из-за чего добыча иногда просто останавливалась. Пока игрок руководил атакой, ставил эксп, рабы создавали пробку и приток минералов прерывался. Впоследствии игрок обнаруживал, что весь его билд полетел к черту из-за дефицита средств.
Основная проблема была в том, что игроки старались максимизировать число рабочих на дозу, чтобы увеличить доход. Рабочие бегали от доз к базе и обратно, сталкиваясь на пути со своими собратьями, спешащими в обратном направлении. Когда в небольшом пространстве скапливается достаточно рабочих вполне возможно, что некоторые из них намертво застрянут и будут стоять пока какую-нибудь дозу полностью не выработают.
(Почему беспен? Газ же называется веспен! В комментариях Патрик признается, что это оговорка не спроста. Газ веспен назван по аналогии с планетой Беспин из Звёздных Войн, на которой Ландо Калриссиан в Облачном городе добывал газ тибанна. Да пребудет с вами сила! - masuk0)
Как выйти из положения?
То ли я вызвался добровольцем, то ли меня попросили заняться этой проблемой, через столько лет я уже просто не помню. Тщательно изучив код прокладки пути, я пришел к выводу, что я ни разу не достаточно умён, чтобы взять и разобраться с этой проблемой. Так что я придумал грязный трюк.
Вообще программисты бывают одержимы желанием находить чистое, идеализированное, совершенное решение проблемы, но иногда настают времена, когда чем-то приходится жертвовать. Если все правильно сделать никто не узнает об этих сделках с совестью, как это можно сказать о хаках описанных Brandon Sheffield в его статье “Грязные приём программирования”. (Сcылка перестала быть доступна на момент этой публикации - masuk0)
Моя идея была проста: когда харвестр едет добывать минералы или едет с добычей на базу, они должны игнорировать столкновения с харвестрами в том же состоянии (всеми юнитами). Исключив столкновения мы полностью избавились от пробок и заставили харвестры работать с максимальной эффективностью.
Этот эффект можно наблюдать, выбрав группу рабов, добывающих минералы и приказать им остановиться. Они немедленно рассредоточатся на местности в поисках свободных от соседей квадратов.
Это поведение очевидно, если присмотреться, но скрыто от поверхностного взгляда — не все знают об этой особенности, но профессиональные игроки, картоделы и создатели модов, конечно, знают об этом.
Данный трюк прост и он полностью снимает проблему — а это лучший вид хака.
Оставалось еще полно работы, которую надо было сделать, чтобы выпустить игру, и этот хак позволил нам избавиться от огромных, пожирающих время переделок.
(Но в Старкрафт харвестер с командой добычи игнорирует столкновения со всеми юнитами, а не только со своими коллегами по добыче! В комментах Патрик пишет, что за прошествием лет уже не помнит, как так вышло. Его идея касалась только самих харвестеров в этом состоянии. Любители Старкрафта знают, что этот элемент геймплея перенесён во второй Старкрафт, и хак теперь - фича. Но кое-что поправлено, например трюк, когда раб мог растолкать стену из юнитов противника на входе на базу, выключив свой бестелесный режим в нужный момент.- masuk0)
Команда разработчиков смогла разрешить многие другие проблемы нахождения пути и вынуждена была проигнорировать оставшиеся, к примеру, драгун протоссов заполучил дурную репутацию. Будучи самым крупным наземным юнитом он часто терпел неудачи в поисках пути к месту назначения.
Конечный результат был достаточно неплох, и мы все получили жестокий урок о надеждах и выдавании желаемого за действительное, как основах планирования.
Трудные времена на пути к Starcraft 2/3
Patrick Wyatt, бывший вице-президент и старший разработчик Blizzard, рассказывает о кошмарном пути разработки Starcraft.
Часть 2/3
Старкрафт: Орки в космосе падают, объятые пламенем.
В своей предыдущей статье о Старкрафте я рассказывал почему мы перезапустили проект, превратив его из продолжения Warcraft, условно названного “Орки в космосе”, которое мы планировали выпустить в 1996, в ту, выигравшую множество призов, игру, которую мы выпустили через два года каторжного труда. Но один важный источник вдохновения не нашел отражения в предыдущей статье, и о нем я хочу рассказать сейчас.
Blizzard впервые продемонстрировала Старкрафт общественности в июне 1996 на выставке Electronic Entertainment Expo (E3). В то время игра еще была в разработке всего несколько месяцев и нет ничего странного в том, что она мало отличалась от своего предшественника, Warcraft II.
После успеха серий Warcraft и Command&Conquer от Westwood Studios жанр RTS привлек много соперников. Гонка за то, кто выпустит новую классную RTS была в разгаре и Blizzard была близка к тому, чтобы опозориться, показав игру которая еще на такой ранней стадии разработки. В нескольких шагах от будки Blizzard на выставке демонстрировалась другая игра, которая била Старкрафт во всех отношениях. Dominion: Storm over Gift 3, от Ion Storm.
“Возможно вы не в курсе текущий событий, но нам только что надрали задницу”
Рядовой Хадсон из “Чужых”
Сейчас 1996 год и вы хотите купить RTS. Вы заплатили бы деньги за это:
... или за это:
Шпионаж на выставках
В ранние годы Blizzard, которая еще даже так не называлась, мы выезжали всей командой разработчиков на основные выставки в отрасли, такие как Consumer Electronics Show (CES) и E3. Мы распределялись по павильонам и “исследовали” (ну то есть рубились) в игры конкурентов, изучая ранние версии игр, которые планировались к выходу в течении следующего года. Это было важной возможностью исследовать тренды игрового мира, узнать о технологических новинках, посмотреть геймплей. Более того, наши конкуренты облегчали нам задачу, демонстрируя игры и отвечая на наши вопросы. Конечно мы делали то же для них в своей кабине. Естественно между разработчиками на выставках складывались отношения по принципу “любовь-война”. Вдобавок, аренда площади на выставки очень недешева (десятки тысяч долларов за несколько квадратных футов пола) и для команд было полно отвлекающих моментов, так что участники на таких мероприятиях похожи на голодных волков в поисках добычи.
На заре игровой индустрии, когда игры писались для 16-битных консолей, наша команда пересматривала несколько близких к выходу изданий для Super Nintendo (SNES), и пытались разобраться с помощью какой магии их разработчики добивались тех или иных эффектов. SNES был странной комбинацией невыносимо медленного 2,58 мегагерцового (не гигагерцового) процессора связанного с 64 килобайтами (не мегабайтами и не гигабайтами) памяти на экзотических микрочипах, разработанных чтобы быстро выплевывать биты на экран — если конечно ты умел применять правильные заклинания, чтобы заставить все это работать.
Мы стояли и пялились на игры, разговаривая фразами, в которых всего несколько тысяч человек в мире могли что-то понять, и большинство из них работало на Nintendo. Кто-то произносил что-то вроде “Скорее всего, они используют прерывание hblank, чтобы установить регистр прокрутки для подстройки видовой дистанции в режиме 7” и мы собирались чтобы обмозговать эту идею, обучаясь в процессе. Наши художники и дизайнеры точно также частенько офигевали от открытий в своем поле.
Это было волнующим опытом увидеть так много новых идей за несколько дней и мы возвращались с выставок одновременно воодушевленные нашими находками и удрученные великолепием и смекалкой наших конкурентов.
Еще лучше было то, что такие мероприятия обычно устраивались в экзотических местах вроде Лас Вегаса, и мы могли собраться вечером за бутылкой и азартными играми прежде чем потащить свои непохмеленные тушки обратно в выставочный павильон. Найти человека для своей будки в утренние часы было непросто и требовало принятия непростых решений - кто сможет лучше представлять наши продукты после тяжелой ночки? Кого выбрать - заядлого любителя вечеринок с его устойчивостью к алкоголю или более воздержанных членов команды вроде меня? Хотя более скромные парни казались очевидным решением, частенько одна лишняя рюмка для них могла угробить утренние мероприятия из-за катастрофического похмелья.
Ради привилегии покрутиться в закулисье игровой индустрии наша команда была вынуждена штабелями укладываться в дешевых комнатах мотелей на большом удалении от центра конференции, дабы сэкономить деньги кампании. Наш отель был так далеко на окраинах Чикаго, что несколько ребят носили с собой ножи для стэйков на случай ограбления в темной подворотне. А как забыть случай, когда из-за пожара в отеле отключили два лифта, заставляя каждое утро и вечер совершать прогулку по лестнице на 14 этаж?
Возвращаясь на выставку после всех этих эскапад ребята из Blizzard находили новые отличные игры и, как пчелы возвращаясь в улей, рассказывали о своих открытиях остальным разработчикам, после чего их снова отправляли найти что-нибудь интересненькое.
Так как будка Ion Storm была рядом с нашей, мы быстро обнаружили что Dominion Storm на эпоху опережает наши слабые потуги в жанре RTS, что было достаточно унизительно, так как Старкрафт был уже нашей третьей работой на этом поле.
Как Битва на Хоте, только интерактивная.
И хотя мы не смогли поиграть в Dominion Storm, так как к нему не разрешали прикасаться, это не выглядело необходимым. Демонстрация игры от Ion Storm была поразительным зрелищем. В ней были отлично выглядящие юниты, особенно один, напоминавший шагающие AT-AT из “Империя наносит ответный удар”, показанные во время битвы на Хоте. Вместе с другими впечатляющими юнитами всех видов и размеров, а также электро-изгородями, которые можно было соединять вместе, создавая непроходимые барьеры, изометрической графикой, показывающей юниты с более зрелищной перспективы, чем наша плоская графика, Ion Storm надрал нам задницу по каждому пункту.
В мрачном настроении команда поехала назад зализывать раны и строить планы на будущее. Фундаментальной проблемой было то, что Старкрафт не задумывался как игра класса ААА, а как заплатка, призванная заполнить дыру в расписании выхода игр в 1996 году и дать в этот период хоть какую-то выручку.
Оглядываясь назад это можно назвать явной ошибкой, и мне следует объяснить почему мы, я имею виду руководство Blizzard, позволили такому случиться. Но сначала отступление: события о которых я говорю происходили в 1996 и их уже затянула дымка времени. Я не обсуждал эти темы с ребятам из Blizzard с 2000 года, когда я ушел оттуда чтобы создать ArenaNet. Сомневаюсь также, что парни из Blizzard стали бы со мной обсуждать такие вещи, если бы я попросил. В последующие годы мы стали соперниками, и, как всем известно, они держат рот на замке в вопросах касающихся их бизнеса не без хорошей причины. Они предпочитают умалчивать обо всех ошибках и концентрировать внимание на удачах. Но я не имею подобных обязательств, так что вы можете видеть мои весьма субъективные оценки, которыми я с вами делюсь... в качестве терапии, наверное. Может другие участники тех событий выйдут и поделятся своим мнением об этой стародавней истории.
Так что с “Орками в космосе”?
Бизнес-стратегией Blizzard управлял Allen Adham, президент кампании. Аллен изучал как игры, так и бизнес под руководством Bob Davidson (Главный исполнительный директор Davidson&Associates кампании образовательного ПО, которая поначалу помогала Blizzard). Они планировали расписание разработок весьма тщательно с тем, чтобы максимизировать выручку и доходы нашей студии, как сделал бы любой корпоративный лидер. Однако команду разработчиков в первую очередь двигало желание делать офигенные игры, а Аллен хотел построить четкий план с предсказуемыми датами релизов, включавшие проекты, которые не вызывали у команды большого энтузиазма.
Некоторые проекты проталкивались против воли разработчиков, вроде таких проектов как Games People Play (головоломка-кроссворд, которая умерла от того что команда разработчиков была совершенно немотивирована), Warcraft Adventures (Квест-адвентура в стиле Sierra, которая, какой хорошей адвентура не оказалась бы, никогда не смогла бы стать игрой от Blizzard с большой буквы), Diablo Hellfire (дополнение к Diablo, разрабатывавшееся сторонней командой, выбранной не по мастерству, а по доступности), Crixa (усовершенствованный клон SubSpace кампании Virgin Games, который был слишком поверхностный и аркадный, чтобы полюбиться фанатам Blizzard). Когда возникало единодушие против какой-либо идеи, стратегия Аллена летела в тартарары, как в случае когда команда разработчиков восстала против плана создания мини-гольф франшизы.
В период после выхода Warcraft II Аллену необходимо было найти что-нибудь для выпуска в 1996. Так как проект Shattered Nations развалился, в расписании возник пробел. Собрать какой-нибудь проект чтобы заполнить эту дырку стало основным приоритетом. В этом свете решение Аллена сделать игру скромного масштаба выглядело разумным, но и этот план рухнул под давлением обстоятельств.
В то время в индустрии происходили большие перемены. С внедрением CD-ROM вместо дискет и картриджей студии начали наперегонки создавать массивные игры, использовавшие это пространство. Чтобы отвечать на эти вызовы размеры команды разработчиков стали расти как на дрожжах и бюджеты разработки быстро взлетели до небес.
Проекты, достигавшие уровня искусства, могли тянуться годами, потом такие проекты перекрывались более технически продвинутыми новинками, заставляя авторов расширять масштаб, изменять дизайн, перезагружать проекты и вливать новые ресурсы, чтобы догнать конкурентов. Старкрафт был трудным ребенком Blizzard из этой категории.
Многих в команде, включая меня, усилия по созданию двух RTS, одну за другой, всего за два года, истощили до предела. Время последних доработок перед выходом игр было физически трудным и многих болезнь сваливала прямо после выпуска из-за переутомления.
На горьком опыте я узнал сторонние эффекты недостатка сна, такие как потеря памяти, ведь сон нужен в том числе для упорядочивания памяти. Также недостаток сна приводит к депрессии, которая имеет гораздо больше последствий, чем просто плохое настроение, как я думал по наивности, а серьезно изменяет физиологические процессы в мозгу, из-за чего тот просто перестает функционировать.
Хотя мне не кажется, что кто -либо из команды страдал от клинической депрессии, в послевыпускной период нам серьезно не хватало энергии в течении недель или месяцев в зависимости от продолжительности “предвыпускной горячки”. Но больше к этой статье имеют отношения те перемены в отношении, которые вызывает такое состояние. Споры о стратегии, которые раньше выливались в горячие дискуссии, после выхода игр ввергали людей в апатию.
Со своей стороны я хорошо помню, как я противился идее спешно разрабатывать Старкрафт в рамках одного года. До этого я также сопротивлялся в начале разработки Warcraft II, который был еще одним однолетним проектом, непосредственно по стопам своего предшественника. В ретроспективе создание Warcraft II за один год, которое очень дорого обошлось мне и другим участникам проекта, стало тем, что удержало Blizzard во главе индустрии, так что, возможно, оно того стоило.
Противясь ускоренному созданию Starcraft, я уже был не так горяч. Я перешел к другим обязанностям, и, вследствие своего чрезвычайного утомления, я снял с себя ответственность за проект и отстранился от непосредственной разработки Старкрафта. В действительности, я вообще мало чем занимался в течении нескольких месяцев после выхода Warcraft II, я был слишком изнурен. Моя неудача в том, чтобы направить проект Старкрафта по верному пути позже плохо для меня обернулась, так как впоследствии я был вынужден заняться операцией по спасению Старкрафта, но только после того как я закончил операцию по спасению Diablo.
Еще одно обстоятельство, которое мы сильно недооценили это муки необходимости разрабатывать несколько игр одновременно. Blizzard как раз пыталась перерасти масштаб студии одной игры в масштаб студии многих игр. Мы предприняли попытку работать над несколькими проектами и немедленно столкнулись с необходимостью разделить одну сильную команду, получая две посредственные команды. Команде, которая разрабатывала до этого великие игры, даже усиленной новыми опытными членами, приходится заставлять многих людей заниматься тем, чем они ранее не занимались, а это несет некоторый риск.
Выпустить на рынок одну игру уже достаточно сложно, и неудивительно, что кампания не смогла адекватно функционировать, разрабатывая несколько игр одновременно, без увеличения сроков, бюджета и обучения — такой роскоши у нас не было. Это так очевидно теперь, но тогда давление необходимости выпускать игры было огромным. В конечном счете произошло событие, которое изменило параметры этого уравнения: мы продали так много копий следующих игр, что смогли позволить себе тратить больше времени на разработку новых.
Будьте уверены, когда я ушел к новыми партнерам чтобы основать ArenaNet мы хорошо помнили эти уроки, и проделали лучшую работу, строя кампанию, не испытывающую подобных проблем.
Что стало с Dominion Storm?
Blizzard после тяжелого процесса разработки и затянувшейся на четырнадцать месяцев предвыпускной горячки, в конце концов выпустила Старкрафт в мае 1998. Dominion Storm, если верить Википедии вышел вскоре после этого, в июне.
Так почему Dominion Storm, который выглядел так отлично, что заставил перезапустить Старкрафт, занял больше времени в разработке? И почему добился нулевого успеха, когда вышел? Если вы не читали статью в Dallas Observer про внутренний хаос в Ion Strom вы будете шокированы. Это самая ужасающая история о разработке игр, которую я слышал, и автор заслуживает благодарности. Если вы её прочтете, у вас сложится отчетливое мнение отчего команда разработчиков испытывала проблемы. Чтобы вы почувствовали, о чем речь, приведу любимую цитату оттуда: ”You better be fucking glad we wrote off your car and house, you fucking rat-faced bitch!” (Тебе, блядь, нужно порадоваться, что мы уже списали твой дом и тачку, сука крысиномордая!).
Узрите
Насколько все плохо было в Ion Storm выяснилось, когда один грязный секрет выплыл наружу. Много лет позже демонстрации Dominion Storm на выставке Е3 1996 года, мы выяснили, что демо, которое мы видели, было фэйком.
Ion Strom начал разваливаться из-за финансовых и политических проблем, члены команды убегали чтобы поискать другие возможности. Из той команды Blizzard удалось подобрать Mark Skelton и Patric Thomas двух отличных специалистов по анимации, которые создали несколько эпических заставок для Blizzard. Я проводил с аниматорами много времени, благо поселились они недалеко от меня, и болтался с Марком и Патриком, часто отправляясь на сёрфинг в Лагуна-бич или Хантингтон-бич.
Как-то раз я болтал с Марком и Патриком о том, как Dominion Storm переполошил нас в свое время, и они открыли мне страшную тайну: все демо было заранее рендеренным видео, а люди которые проводили демонстрацию лишь делали вид, что играли в игру! Я думаю вам ясно, насколько мы были шокированы — они заставили нас перезапустить Старкрафт, в результате чего тот стал “определяющей игрой для своего жанра. Эталонным стандартом по меркам которого будут судиться все стратегии реального времени.”(GameSpot)
Теперь трудно смотреть назад без того чтобы чувствовать благодарность за пинок под зад, который мы получили от Dominion Storm. И хотя мне и многим другим пришлось поучаствовать в самой трудной и длинной эпопее по разработке в своей жизни результат можно по праву назвать чудом.
Но есть еще кое-что!
Тут собственно можно было и закончить, но я не могу сопротивляться соблазну рассказать еще об одну историю о фэйковой демке, которую я недавно узнал. Она случилась уже после того как я покинул Blizzard, так что пересказываю её из вторых рук.
Каждый разработчик игр знает, что хотя дата выхода игры - вещь условная, даты игровых выставок отлиты в граните. Если игровая студия потратила сотни тысяч долларов на выкуп и обустройство выставочной площадки, заказала все принты и рекламу, сделала анонс для прессы, разработчики должны продемонстрировать ЧТО-ТО или полетят головы.
Так получилась что Warcraft III нуждался в дополнительной помощи на одной из выставок. Движек Warcraft III, написанный с нуля, без использования кода из прошлых “крафтов”, был настолько сложным и непонятным, что многие разработчики называли его между собой “мозгоёб”, и программисты не смогли толком наладить нахождение пути и столкновения, чтобы все работало к началу Е3.
За данный им отрезок времени, они так и не создали устойчивого примера и пришлось запретить фанам и прессе прикасаться к созданной демке. Вместо этого демонстрация была тщательно сдирижирована разработчиками, которые старательно обводили юниты вокруг всех объектов на местности, которые могли выявить существовавшие дыры. К чести Blizzard надо сказать, что игра была выпущена только тогда, когда все проблемы были разрешены, и Warcraft III получился великолепной игрой.
Делать игры, особенно делать их так, чтобы они обладали достаточными визуальными возможностями для демонстрации их аудитории жутко тяжело. Я желаю всем, кто хочет делать отличные игры, удачи в ваших начинаниях, надеюсь что вы не окажетесь в такой ситуации, когда вам нечего показать.
Трудные времена на пути к Starcraft 1/3
Patrick Wyatt, бывший вице-президент и старший разработчик Blizzard, рассказывает о кошмарном пути разработки Starcraft.
Часть 1 / 3
Трудные времена на пути к Старкрафту.
Я уже писал о ранней поре разработки Warcraft, но последний пост, который я прочел, заставил меня в гневе взяться за перо и результатом стала это трехчастная двадцатистраничная статья о разработке Starcraft, вместе с моими мыслями о том как писать более надежный игровой код. Я опубликую остальные части в течении нескольких дней.
Начало Starcraft
В течении разработки Starcraft, двухлетней изнурительной работы и года предвыпускной горячки, в игре было больше багов, чем в муравейнике. Между тем, его предшественники (Warcraft I и Warcraft II) были значительно надежнее, чем их конкуренты в игровом мире. Старкрафт падал так часто, что тестирование было очень трудным до самого момента выхода, а после игра требовала постоянного выпуска патчей.
Почему? На это оооочень много причин.
Орки в космосе.
Старкрафт изначально планировался как современная игра, разработка которой могла уложиться в один год и быть выпущена к рождеству 1996.
Игрой занимались те же ребята которые начали проект Shattered Nations, пошаговую стратегию из линейки X-COM, которую Blizzard анонсировала в 1995, но отменила через несколько месяцев.
Члены команд были перемешаны, чтобы создать что-то, что можно было быстро выпустить на рынок, дабы у Blizzard не было длинного перерыва между выходами игр.
1994 - Warcraft
1995 - Warcraft II
1996 - запланированная дата выхода Starcraft
1998 - реальная дата выхода Starcraft
Оглядываясь назад, решение разрабатывать игру в сверх-сжатые сроки выглядит нелепым, но Allen Adham, президент кампании, испытывал острую необходимость в увеличении доходов. И хотя предыдущие игры Blizzard оказались гораздо успешнее чем ожидалось, это серьезно подняло будущие ожидания публики.
Был отведен короткий запас времени и ограниченная команда для разработки скромной игры — чего-то что можно было бы описать как “Орки в космосе”. Картинка с выставки Е3 во втором квартале 1996 показывает путь которым изначально пошли разработчики:
Старкрафт, как он был показан в июне 1996 на Electronic Entertainment Expo - да, я тоже не стал бы в это играть.
Но проект с более высоким приоритетом затмевал Старкрафт и крал его разработчиков одного за другим. Diablo. РПГ, разрабатываемая Condor Studios в Редвуде Калифорния, требовал дополнительных усилий. Condor, кампании созданной Dave Brevik вместе с Max Schafer, был выделен бюджет 1,2 миллиона долларов - смешной даже по меркам того дня.
У Condor не было шансов в одиночку создать ту игру, которая от них требовалась, но они проделали такую потрясающую работу по разработке чего-то очень захватывающего, что Blizzard решила поглотить Condor, переименовать его в Blizzard North и начать вливать в проект те деньги и ресурсы, которые он действительно заслуживал.
Изначально Collin Murrey, программист Старкрафта, и я полетели в Редвуд помогать, пока остальные разработчики в штаб-квартире Blizzard в Ирвине, Калифорния работали над сетевыми провайдерами для battle.net, модемами, LAN играми, экранами интерфейса, ответственными за создание персонажа, присоединению к игре и другими мета-функциями.
По мере того как Diablo рос, все в Blizzard: художники, программисты, дизайнеры, инженеры по звуку, тестеры; начали работать над ним, и в конце концов в штаб-кваритре Blizzard не осталось никого, кто работал бы на Starcraft. Даже глава проекта был переведен, чтобы помочь закончить инсталлятор игры, который я написал наполовину, но был слишком занят, чтобы закончить.
После выхода Diablo в конце 1996 разработка Старкрафта была начата заново. Все увидели во что превращается игра и это никому не понравилось. Игра была устаревшей, совершенно не впечатляющей, особенно в сравнении с проектами вроде Dominion Storm, который выглядел превосходно в демо-версии, показанной на E3 шестью месяцами ранее.
Огромный успех Diablo повысил ожидания от проекта следующей игры Blizzard. Старкрафт стал игрой, которая определила политику Blizzard не выпускать игр, пока они не будет полностью готовы. Но много неприятностей случилось на пути к осуществлению этой стратегии.
Есть что доказывать
Все смотрели на Старкрафт очень критически, было очевидно, что проект должен быть гораздо амбициознее, чем наши предыдущие потрясающие достижения, определившие облик RTS, которыми были первые два Warcraft.
На момент перезагрузки Старкрафт по данным John Wilson, главного редактора Computer Gaming World, самого многотиражного журнала о компьютерных играх того времени, в разработке находилось более 80 (!!!) RTS. Имея столько конкурентов, включая Westwood Studios, кампании которая буквально придумала жанр RTS, мы должны были сделать что-то, что надрало бы всем задницы.
Мы больше не были темной лошадкой: после успеха Diablo и Warcraft нам не было бы никакой поблажки от игровой прессы и игроков. В мире игр ты хорош настолько насколько хороша была твоя последняя игра. Нам нужно было шагнуть гораздо дальше чем ранее, и для этого нужно было пойти на риск.
Новые лица.
У Warcraft II было только шесть программистов, которые работали над движком и два программиста поддержки. Этого было явно недостаточно для масштаба Старкрафт, так что команда разработчиков получила пополнение - новых и непроверенных программистов, которым еще предстояло научиться писать игровой код без постоянного руководства.
Но наше управление было слабовато: мы сами еще не поняли как важно дать нужные наставления менее опытным членам команды, чтобы они могли выучить важные уроки ДО того как игру нужно выпустить, так что во многом это было предложением типа “выплыви или утони” для новых падаванов. Большую проблему представляло то, что под нами горела земля - каждый программист кодил как сумасшедший, чтобы выполнить поставленные задачи, не отвлекаясь на то, чтобы перепроверить код или на обучение.
Но опыта недоставало не только молодым членам команды. Ведущим программистам Старкрафт до тех пор ни разу не приходилось разрабатывать полностью готовый к выпуску игровой движок. Bob Fitch писал игры уже несколько лет и с большим успехом, но он только портировал игры, где он работал с уже готовым движком, он разрабатывал вспомогательные элементы Warcraft I и II, не занимаясь полномасштабным написанием движка. И хотя он был главным программистом Shattered Nations, этот проект был отменен, и никакой проверки разработанной архитектуры не проводилось.
Команда проекта проявляла небывалую самоотдачу и прилагала неслыханные усилия чтобы завершить проект, жертвуя своим здоровьем и личным временем. Никогда более я не работал над проектом, где каждый проявлял бы такую самоотдачу. Однако несколько ключевых решений этого проекта, которые я хочу описать, будут преследовать команду разработчиков до самого выхода игры.
Кое-что надо поменять.
Итак, потратив месяцы на выпуск Diablo, и еще месяцы на зачистку концов и выпуск патчей, я вернулся, чтобы помочь перезапустить Старкрафт. Я не предполагал, что меня бросят в полный багов муравейник, но так оно и вышло.
Я думал, что без труда погружусь в этот проект, поскольку великолепно знал код Warcraft - я сам работал над всеми компонентами игры. Но вместо этого я в ужасе выяснил, что большинство компонентов движка были выброшены и переписаны.
Классы юнитов были написаны с чистого листа, диспетчер юнитов выброшен и переписан. Диспетчер юнитов — это механизм, который обеспечивал выделение каждому юниту времени, чтобы он мог осуществить планирование своего поведения. Каждый юнит периодически спрашивает: “Что я должен делать, когда закончу делать то, что я делаю?”, “Нужно ли мне пересчитать путь туда, куда я направляюсь?”, “Нет ли цели получше той, которую я атакую сейчас?”, “Не дал ли мне пользователь новую команду?”, “Я умер. Как мне прибрать за собой?” и так далее.
Есть хорошие причины на то, чтобы переписать код, но это несет огромные риски. Как отлично сказал Joel Spolsky в “Вещах которые тебе не следует делать” :
“Важно помнить, что когда вы начинаете с чистого листа нет никакой гарантии, что вы сделаете все лучше, чем в прошлый раз. Во-первых у вас скорее всего не совсем та команда, что в прошлый раз, так что неверно говорить что “теперь у нас больше опыта”. Вы заново сделаете все старые ошибки и добавите несколько новых проблем, которых не было в оригинале”
Месяцами движок Warcraft доводился до ума, и хотя его надо было переработать, чтобы добавить в игру новые фичи, новой команде программистов предстояло потратить очень много времени чтобы на своей заднице понять как был создан движок Warcraft и почему его архитектура такова как она есть.
Архитектура движка игры
Я написал оригинальный движок Warcraft для MS DOS на С, использовав компилятор Watcom. C переходом на Microsoft Windows Боб выбрал компилятор Visual Studio и переделал движок на С++. И то и другое было разумным решением, но факт был в том, что на тот момент у немногих разработчиков был опыт работы с этим языком и всеми его ловушками.
С++ имеет преимущества, но его легко использовать неверно. Как сказал создатель языка Bjarne Sroustrup : “На С легко выстрелить себе в ногу. На С++ это сложнее, но если это произойдет, вам оторвет всю конечность”
Опыт говорит, что программисты чувствуют обязанность использовать каждую фишку нового языка во время первого же проекта, и именно так произошло с наследованием классов в Старкрафт. Опытный программист вздрогнет, когда увидит дерево наследования юнитов старкрафта:
CUnit < CDoodad < CFlingy < CThingy
CThingy были спрайтами, которые могли появляться в любом месте карты, но не двигались и не имели поведения, CFlingy использовались для создания частиц, когда происходил взрыв несколько разлетались в разных направлениях. CDoodad (по прошествии 14 лет мне кажется, что именно так назывался этот класс) был абстрактным классом содержащим важные поведения, необходимые для функционирования экземляров наследуемых классов. А CUnit был поверх всего этого нагромождения. Его поведение было разбросано по всем этим модулям и необходимо было полное понимание как работает каждый из них, чтобы добиться от него хоть чего-нибудь.
А поверх всего ужаса сложной иерархии наследования сам класс CUnit был богомерзким нагромождением разбросанным по множеству файлов:
class CUnit ... {
#include "header_1.h"
#include "header_2.h"
#include "header_3.h"
#include "header_4.h"
};
Каждый из этих заголовков содержал по несколько сот строк, так что объявление класса можно назвать, мягко говоря, занимательным.
Лишь много лет спустя мантра “структура превыше наследования” (favor composition over inheritance) набрала авторитет среди программистов, но те, кто работал на Старкрафтом выяснили это тяжелым путем гораздо раньше.
Два месяца до выхода
Испытывавшая проблемы с самого начала, после перезагрузки команда разработчиков находилась под огромным давлением. Чтобы сдать игру вовремя, сроки были сжаты до предела — по плану до выхода игры оставалось два месяца.
С учетом количества поведений, которые предстояло еще дописать, изменений необходимых, чтобы перейти от плоских макетов к изометрическим, с новым редактором карт и добавлением battle.net для игры по интернету это было совершенно нереально, даже если предположить что художники, дизайнеры, ответственные за баланс и тестеры могли завершить свою работу к сроку. Но команда программистов постоянно работала исходя из предпосылки о выходе игры через два месяца в течении четырнадцати месяцев!
Вся команда работала сверхурочно, а Боб программировал по 40, 42 и даже 48 часов к ряду. На моей памяти никто не более не предпринимал более подобные мазохистские попытки, каждый перерабатывал огромное, нереальное количество времени.
Мой опыт разработки Warcraft и Diablo с частым всенощным программированием, когда я кодил по 14 лишних часов кряду 7 дней в неделю, заставили меня думать, что такое геройство совершенно бессмыленно. Весь код, написанный после какой-то точки, будет проклят и переписан на свежую голову следующим днем.
Отрабатывая такие длинные часы люди переутомляются, а это плохо, когда требуется решать задачи, требующие знаний, интеллекта и креативности, так что не приходится удивляться количеству ошибок, багов и неверных решений.
Кстати, никто не принуждал нас работать сутками — мы сами так делали, потому что хотели делать великолепные игры. Задним умом ясно, что это было глупостью. Мы могли достичь лучших результатов меньшими усилиями.
Моим лучшим достижением я считаю выпуск четырех частей Guild Wars за два года, не ведя команду разработчиков по этому темному пути.
Наиболее распространенные причины вылета в Старкрафт
И хотя я разработал такие важные компоненты Старкрафта как туман войны, линия видения, поиск пути и столкновение летающих юнитов, голосовой чат, точки для подкреплений ИИ и многое другое, моей главной работой был отлов багов.
Стоп? Голосовой чат?! В 1998?! Ага — я проделал всю работу в декабре 1997. Я использовал компрессор стороннего разработчика, и написал код рассылки фонем на компьютеры семи остальных игроков, распаковки и проигрывания.
Но каждая звуковая карта в нашем офисе потребовала обновления драйверов чтобы это работало, даже если она имела полный дуплекс (возможность писать и проигрывать звук одновременно). И я с сожалением принял решение отказаться от этой идеи. Тех. поддержка была бы так завалена работой, что мы потратили бы больше денег на неё чем заработали от продажи игры.
Как бы то ни было я пофиксил кучу багов. Некоторые, конечно, свои, но в основном сложные для поимки ошибки написанные усталыми программистами. Один из лучших комплиментов я получил всего несколько месяцев назад, когда Brian Fitzgerald, один из двух лучших программистов с которыми мне довелось работать упомянул об обзоре кода Starcraft. У них крышу снесло от количества исправлений и изменений, которые я сделал по всему базовому коду. Ну хоть с опозданием я получил должную оценку!
С учетом всех описанных проблем, вам может показаться сложным идентифицировать единый источник большинства багов, но по моему опыту самые большие проблемы в Старкрафте были связаны со списками с двойным связыванием.
Связные списки активно использовались в движке для отслеживания юнитов с совместным поведением. Так как Старкрафт имел максимум в 1600 юнитов, вдвое больше, чем в его предшественнике - Warcraft II, стало необходимым оптимизировать поиск юнитов определенных типов с помощью содержания их в связных списках.
Насколько я помню, там были списки юнитов и строений каждого игрока, списки генерирующих зданий, списки перехватчиков каждого авианосца и многие другие.
Все они были списками с двойным связыванием, дабы можно было добавлять и удалять элементы за постоянное время, не проматывая все элементы с первого, чтобы найти элемент для удаления.
К сожалению каждый список создавался вручную без использования единого набора функций для привязывания и отвязывания элемента от списка — программисты каждый раз вручную писали такие методы, когда возникала необходимость. Такой код гораздо больше подвержен ошибкам, чем использование единого набора отлаженных функций.
Многие связи были общими для нескольких списков, так что было необходимо точно знать к какому списку привязан объект, чтобы безопасно исключить его из списка. А некоторые связи хранились в объединениях Си (unions) вместе с другими данными, чтобы свести к минимуму использование памяти.
Так что, игра падала все время. Все время.
Так зачем вы сделали это таким образом?
Трагедия в том, что не было никакой особой причины для всех этих проблем со связными списками. Mike O’Brien, который вместе со мной и Jeff Strain основал ArenaNet, написал библиотеку под названием Storm.DLL которая поставлялась вместе с Diablo. Помимо многих других вещей она содержала отличную реализацию списков с двойным связыванием на основе шаблонов С++.
На ранних этапах разработки Старкрафт мы использовали эту библиотеку. Но в какой-то момент команда разработчиков выкинула эту библиотеку и вручную реализовала все связные списки, это помогло, к примеру, упростить сохранение игры.
Позвольте немного подробнее сказать о сохранении, чтобы прояснить это.
Сохранение игр.
У многих игр в, которые я играл, был дерьмовый функционал сохранения. Игроманы, которые играли в любую игру от Orign помнят, как доооолго записывался сэйв. Понятно, их писали медленные микропроцессоры на жесткие диски которые по сегодняшним стандартам выглядят как трехколесные велосипеды по сравнению с мотоциклом. Но не было реальных причин для них быть таким отстоем. Я сразу решил что в Warcraft не будет подобных проблем.
Warcraft использовал пару приемчиков, чтобы писать большие блоки данных одним куском, вместо того, чтобы метаться по памяти, записывая байт там, байт здесь. Весь массив юнитов (600 юнитов по паре сотен байтов на юнит) должен был записываться в один проход. И все глобальные переменные, не основанные на указателях, тоже писались в один проход — как местность и туман войны на картах.
Удивительно, что способность писать все юниты на диск разом не так уж влияла на скорость записи сохранений, но драматически упрощала код. Это работало в основном из-за того, что юниты Warcraft не содержали указателей.
Юниты Старкрафт, как я уже сказал, были совсем другим зверем и содержали кучу указателей для реализации связных списков. Необходимо было произвести адресную привязку для всех этих указателей (а еще были поля указателей в объединенниях), записать 1600 юнитов за один раз, а потом вернуть указатели на место, чтобы продолжить игру. Всего-то.
Вернемся назад!
Так что, пофиксив много много много багов в связных списках, я неистово убеждал всех, что мы должны вернуться к использованию Storm.DLL, даже если это усложнит код сохранения. Когда я говорю “неистово убеждал”, я должен упомянуть, что это единственный способ спорить, который использовался в Blizzard - со всей юношеской горячностью и заносчивым высокомерием. Единственным вопросом, по которому в Blizzard не возникало неистовых споров это то, что есть на ланч.
Я не выиграл тот спор. Так как до выхода оставалось всего “два месяца” никто не хотел переписывать движок, довольствуясь местным заплатками: псевдо-оптимальное решение, которое породило месяцы страданий и кардинально повлияло на мой личный подход к программированию.
Еще заплатки: нахождение пути в Старкрафт
Хочу привести еще пример того как залатывание дырок выбирается вместо устранения источника проблемы: когда Старкрафт переключился от плоской графики к изометрической, основанный на разбитом на квадраты поле движок рендеринга, который основывался на коде, написанным мною в 1993/94 остался неизменным.
Рендерить изометрически нарисованные квадратики используя такой движок не так сложно, но возникают проблемы если вы хотите заставить работать такие вещи как редактор карт: разместив один такой квадрат рядом с другим, нужно применить много исправлений стыков, так как редактор пытается разместить диагональные картинки в квадратные поля.
И хотя с рендерингом не все так плохо, прокладка изометрического пути по плоскому полю по настоящему сложна. Вместо крупных (32х32 пикселя) квадратов, которые были либо проходимы, либо непроходимы карты были разбиты на маленькие (8х8) квадраты — умножив сложность нахождения пути на 16, а также создавая проблемы, когда крупные юниты не могли протиснуться в узкие проходы.
Если бы Brian Fitzerald не был звездой программирования, проблема прокладки пути не давала бы выпустить игру неопределенно долго.
Так как пути были проблемой с которой нам удалось разобраться только к самому выходу игры, я хочу как-нибудь написать отдельную статью о прокладке путей в Старкрафт, поскольку мы применили много интересных решений.