Итак, вас ждёт рассказ об источниках финансирования Blizzard, о том, как Стю Роуз устроил дизайнерский переворот, о тумане войны и, самое главное, о впечатлениях автора статьи от самой первой мнопользовательской игры и о её неожиданных итогах.
За всем этим добро пожаловать за хабракат.
Это мой первый перевод, так что я буду рад всем сообщениям об ошибках, замечаниям и исправлениям.

Самая первая многопользовательская игра в Warcraft обернулась сокрушительной победой, ужасным поражением и ничьей, всем сразу. Но как же это стало возможно? Здесь есть о чём рассказать. Этот рассказ будет включать в себя описание ИИ, экономики игры, тумана войны и ещё много чего. Читайте, если у вас есть много свободного времени.

После шести месяцев разработки, которая началась в сентябре 1993, Warcraft: Orcs vs. Humans был окончательно превращён из расширенной демонстрации технологии в игру.

В течение нескольких месяцев я был единственным работником, полностью занятым на этом проекте, что сильно ограничивало скорость разработки. К счастью, с проектированием мне помогали другие члены компании, включая Рона Миллара, Стю Роуз и других. И ещё несколько художников, которые прототипировали художественное оформление, когда они находили время между майлстоунами на других проектах.

В команде было так мало людей, потому что разработка Warcraft спонсировалась самой компанией из её прибылей, полученных за разработку игр для сторонних издательств, таких как Interplay или SunSoft, поэтому накопления компании были невелики.

В это время мы разрабатывали четыре 16-битных консольных игры: The Lost Vikings 2 (продолжение к нашему хорошо встреченному, но плохо продаваемому сайд скроллеру), Blackthorne (сайд скроллер, где главный герой бегает с шотганам), Justice League Task Force (клон Street Fighter во вселенной DC Comics), and Death and Return of Superman (сайд скроллер, основанный на одноимённой серии комиксов во вселенной DC).

С деньгами, полученными за разработку этих игр и за другие случайные подработки, компания получила возможность оплатить начальную стоимость разработки.

Экономика разработки игр

В течение всей истории игровой индустрии независимые студии — разработчики игр(те студии, которыми не владеют издательские компании) обычно оплачивают свои проекты, подписывая контракты с этими самыми издательскими компаниями. Издатели дают «аванс» на разработку проекта. В дополнение к авансу издательства ответственны за связи с общественностью, маркетинг, изготовление, распространение, поддержку клиентов и так далее.

В 90-ых было намного больше издательств чем сегодня, но увеличение стоимости разработки и, особенно, издательства игр вызвало цепочку банкротств и поглощений, что привело к большому числу объединений компаний. Поэтому сегодня, говоря об игровых издательствах, вы, скорее всего, подразумеваете Activision-Blizzard, EA или Ubisoft вместо мириада компаний среднего размера, которые существовали двадцать лет назад.

Как и везде, условия контрактов составляются в пользу людей с деньгами. Есть золотое правило: «тот, у кого есть деньги, устанавливает правила». Несмотря на то, что в теории эти соглашения организованы так, что разработчик награждается, когда игра хорошо продаётся, так же как в музыкальной и кино- индустриях издатель собирает большую часть прибыли, а разработчик, если повезёт, получает достаточно денег, чтобы дожить до следующего подписания контракта.

Хотя я упомянул об «авансе», выплачиваемом издателем, более правильным термином было бы «аванс вместо роялти», когда разработчик фактически получает кредит, который будет выплачен из гонорара за продажи игры. Звучит отлично: разработай игру, получи плату за каждую проданную копию. Но механизм разработан так, что большинство игр никогда не заработают столько денег, сколько необходимо для выплаты аванса. Так как зачастую студиям приходится отдавать права на свои игры и их продолжения, эти соглашения часто являются скрытыми соглашениями о работе по контракту.

Для получения более выгодных условий соглашений разработчики обычно использовали следующую схему: на собственные средства разрабатывали первоначальный прототип игры, затем использовали этот прототип чтобы «продавить» сделку с издателем. Чем дольше разработчик сможет сам оплачивать разработку, тем лучше будут условия контракта.

Возможно, лучшим примером этой стратегии явлются Valve Software, где Гейб Ньюэлл использовал деньги, заработанные им в Microsoft, чтобы оплачивать разработку Half Life. Тем самым он получил необходимый контроль над временем выпуска игры: вместо того чтобы торопиться с выпуском игры только лишь для того, чтобы выполнить цели по квартальным доходам, как того хотела Sierra Entertainment (издатель игры), он выпустил игру только тогда, когда она стала высококачественным продуктом. Что ещё более важно, сбережения Гейба позволили получить права на сетевое распространение Half Life, в то время как цифровое распространение становилось жизнеспособной стратегией для продажи игр, что, в конечном итоге, и привело студию к ошеломительному успеху.

Недостатком такой самостоятельной оплаты прототипа является риск того, что издатель не подпишет контракт на выпуск игры, что очень часто приводит к смерти студии.

Компания, на которую я работал (в это время она называлась Silicon and Synapse), оплачивала Warcraft вместе с другим проектом, называвшимся Games People Play, который должен был включить в себя кроссворды, боггл и другие похожие игры, которые можно найти на полках в аэропорту для развлечений бедных путешественников.
Разрабатывая две игры, которые были ориентированы на абсолютно разные аудитории, владельцы компании надеялись создать несколько источников дохода, что было бы менее рисковано, чем если бы компания нацеливалось только на ядро рынка развлечений (на заядлых геймеров, как вы или я).

Конечно, распределение ставок между различными игровыми жанрами так же имеет риски, ввиду того, что престиж бренда компании может быть размыт теми продуктами, которые не оправдывают ожидания её аудитории. Одно из главных преимуществ Blizzard сегодня — это то, что пользователи купят их игру ещё до того, как поиграют в неё, потому что они верят в дальновидность и репутацию компании. Такую репутацию было бы намного тяжелей создать, если бы компания выпускала и низкобюджетные казуальные поделки и высокобюджетные игры класса ААА+, как это делала Sierra Entertainment, которая обанкротилась после неоднократных попыток найти свою аудиторию

Так или иначе, создание Games People Play стало ошибкой, потому что разработка казуального развлекательного продукта так деморализующе подействовала на главного программиста, что проект так и не достиг зрелой стадии и был позже отменён. А может быть, это всё-таки не было ошибкой, потому что сочетание Warcraft и Games People Play убедило Davidson & Associates, бывшую в то время второй по величине компанией, занимающейся образовательным ПО, приобрести Silicon & Synapse.

Наши новые сюзерены

Davidson & Associates, основанные Джейн Девидсон, к которой позднее присоединился её муж Боб, была многосторонней компанией, чей рост был обусловлен успехом игры Math Blaster, в которой игрок решал математические примеры, чтобы взорвать астероиды до того, как они уничтожат корабль игрока. Это было хорошее сочетание образования и развлечения, и компания получила множество премий за неё.

Отступление: при правильном использовании Math Blaster могла иметь некоторую образовательную ценность, но мне довелось увидеть ужасающе глупое её использование. В старших классах наш журналистский кружок писал статьи для школьной газеты в компьютерной комнате, которую мы делили с учебным классом для отстающих. Мы в ужасе наблюдали, как эти ученики играли в Math Blaster при помощи калькуляторов. Когда астероиды, содержащие выражения вроде «3+5» или «2*3» приближались, эти ученики быстро вбивали эти выражения в калькуляторы и затем вводили полученные результаты, чтобы уничтожить астероиды. Возможно, они учились чему-то, предполагая, что они обманывают учителей, но я не уверен, что это было лучшее применение тому времени, которое осталось до их стремительно приближающегося вступления во взрослую жизнь.

С хорошим управляющим и агрессивным руководителем Math Blaster развились в производителя (создание и упаковка), распространителя (отправка розничным торговцам и промежуточным распространителям) и прямого поставщика обучающих материалов для школ. Они видели для себя возможности расширения и на развлекательный бизнес, но их ранние оценки по созданию развлекательных продуктов своими силами убедили их, что выгодней купить опытную студию-разработчик, чем продолжать разрабатывать свои игры командой, которая больше знает про обучение, чем про мечи и магию.

Так что финансовые проблемы, которые препятствовали росту команды разработчиков Warcraft были внезапно решены приобретением компании. Финансы Davidson & Associates дали возможность Silicon & Synapse (которые после приобретения были переименованы в Blizzard) сфокусироваться на своих собственных разработках вместо того, чтобы искать низкоприбыльные сделки с другими игровыми издателями. А они были действительно низкоприбыльными: в 1993, даже создав две высоко оцененные игры, которые принесли компании звание «Разработчик года для Nintendo», компания не получила никаких роялти.

Разработку удалось сильно ускорить, используя деньги от приобретения для найма новых, и привлечения к проекту уже работающих в компании сотрудников.

«Процесс» проектирования

Подход к проектированию и построению игр в Blizzard в его ранние годы лучше всего может быть описан как «естественный». Это был хаотичный процесс, который протекал и во время формальных встреч по проектированию, но, в основном, во время спонтанных собраний в холле или за обедом.

Некоторые фичи приходили из проектировочных планов, тогда как другие были добавлены самими программистами. Часть артов по игре были запланированы и регулярно создавались, тогда как другие работы создавались поздно ночью, потому что у художника появлялась отличная идея или он просто хотел попробовать что-нибудь другое. Некоторые элементы были полнейшей импровизацией, например, история мира Warcraft окончательно сформировались только в последние несколько месяцев до запуска.

Несмотря на то что процесс был непредсказуемый, результаты получились впечатляющие. Так как команда состояла из фанатов компьютерных игр, наши игры эволюционировали во время разработки в нечто такое, во что геймеры хотели играть, играть и играть. А Warcraft, наша первая собственная игра для IBM PC, демонстрировавшая лучшие(а иногда и худшие) черты этого процесса, определённо получилась образцовой игрой (по крайней мере для своих дней).

Как появилась система создания юнитов в Warcraft

Биологам известно, что процесс эволюции включал в себя фальстарты, когда целые ветви эволюционного дерева оказывались неудачными. То же самое происходило и во время разработки. Так как у нас не было выверенных спецификаций, нам приходилось много экспериментировать и отбраковывать сущности, которые не работали. Я хочу сказать, что в каждом случае это был выверенный, осмысленный процесс, но много раз он начинался со случайностей, споров и конфликтов.

Один случай, который я хорошо запомнил, связан с созданием игровых юнитов. Во время ранних фаз разработки юниты создавались, используя коды, набранные в консоли, потому что не было другого пользовательского механизма для их создания. Во время обсуждения лучшего способа для производства юнитов были предложены различные идеи.
Рон Миллар, художник, который много сделал в плане создания идей и дизайна для ранних игр Blizzard, предложил следующую идею: игроки должны будут строить фермы, и (как в игре Populous) эти фермы будут периодически производить рабочих юнитов называемых пейзане (для людей) и пеоны (для орков). У игрока будет возможность использовать эти юниты для добычи золота, дерева и постройки зданий, но они не будут столь хороши как военные юниты.

Игрок может направить этих «пеонов» на военную тренировку в барак, где они на какое-то время исчезнут с карты и, в итоге, появятся как обученные бойцы. Другие тренировочные области будут использоваться для создания более продвинутых военных юнитов, таких как катапульты или волшебники.

Идея не была полностью готова, что было одним из основных недостатков нашего процесса проектирования: отсутствовала финальная документация, которая должна была объяснять как идея должна реализовываться. Так что она обсуждалась всей командой по проектированию (в которой состояло большинство работников компании) до того, как мы начинали кодить(программировать) реализацию.

До того как мы начали работать над кодом, Рон поехал на торговое шоу (возможно, на зимний CES — Шоу Потребительской Электроники) вместе с Алленом Адамом, президентом компании. И за время их отсутствия произошло событие, которое установило направление для всей серии Warcraft, событие, которое я называю «успех в проектировании Warcraft».

Стю Роз, другой художник, который присоединился к компании в самом начале (работник №6, я полагаю) пришёл однажды днём в мой офис, чтобы предложить другой подход. Сту чувствовал, что механизм создания юнитов, предложенный Роном, имел множество ещё не решённых сложностей реализаций. Больше того этот подход прямо противоположен тому типу контролю, который мы должны давать игрокам в RTS.

В этом новом жанре требования к игрокам были намного строже, чем в других и внимание игроков не может быть сфокусировано на одном месте долгое время. Это вызвано тем, что есть множество задач: планирование дерева построек/усовершенствований, контроль за развитием экономики, создание юнитов, размещение зданий, разведка карты, контроль за битвой и применение способностей каждого юнита. В RTS наиболее ограниченным ресурсом является внимание игрока, так что добавление непрямого механизма создания юнитов увеличит дефицит внимания и сложность игры.

Чтобы построить «гранта» — основной боевой юнит игры необходимо будет выбрать простаивающего рабочего и отправить его тренироваться. Такой процесс безо всякой необходимости (по мнению Стю) добавляет сложности игре.

Я был благодарным слушателем для таких размышлений, так как у меня были похожие (хотя и менее продуманные) беспокойства, и я не считал, что создание юнитов было той областью, где нам стоит придумывать серьёзные изменения. Dune 2, игра из которой игровая механика Warcraft была унаследована, имела намного более простой механизм создания юнитов: просто нажимаем на кнопку в панели фабричного здания, и юнит появляется через некоторое время. Это не было их нововведением – идея была скопирована из ещё более старых игр, но это работало.

Стю настаивал, что мы должны использовать этот подход и, вместо дальнейших обсуждений, просто взять и сделать его. Так что за пару следующих дней и вечеров я расширил код игры и пользовательского интерфейса для реализации механизма создания юнитов, так что наша задумка стала свершившимся фактом. К тому времени как Рон и Аллан возвратились, в игру уже можно было играть в однопользовательском режиме, если не принимать во внимание тот факт, что ИИ был крайне далёк от завершения.

Теперь Warcraft стал игрой, в которую легко, и, что более важно, весело играть. Мы никогда не оглядывались назад.

Первая многопользовательская игра в Warcraft

В июне 1994 после десяти месяцев разработки движок игры был готов для мультиплеера. С всё возрастающим чувством возбуждения делал я изменения в коде, которые позволяли сыграть первую многопользовательскую игру в Warcraft. Пока я писал ядро игровой логики (цикл событий, управление юнитами, нахождение пути, тактический ИИ для юнитов, строку состояния, внутри игровой интерфейс, высокоуровневый сетевой код), другие программисты работали над компонентами для сетевой игры.

Джесси МакРейнольдс, выпускник Калтеха, написала низкоуровневую сетевую библиотеку для пересылки IPX пакетов по локальной сети. Код писался с помощью знаний, полученных из исходного кода Doom, который был позже открыт Джоном Кармаком из idSoftware. Хотя интерфейсный слой IPX состоял всего из нескольких сотен строчек сишного кода, это был код, который взаимодействовал с драйвером сетевой карты, чтобы убедиться, что сообщения, созданные в одном клиенте игры, будут посланы другому игроку.

А Боб Флитч, который получил степень магистра в Cal State Fullerton, разрабатывал экраны создания и подключения к многопользовательской игре. Мой кабинет был прямо напротив кабинета Боба, что было весьма удобно, так как было необходимо тесно сотрудничать, чтобы интегрировать его код в мой.

После внесения изменений я скомпилировал клиент игры и скопировал его на сетевой диск, в то время пока Боб бежал обратно в свой кабинет чтобы запустить игру. Это было небольшим чудом: код, который мы только что написали, работал и у нас появилась возможность сыграть в самую первую сетевую игру в Warcraft.

Когда мы начали играть я почувствовал сильное возбуждение, которого никогда не испытывал, играя в другие игры. Часть возбуждения была вызвана тем, что я сам написал этот код, но были и ещё факторы, которые создавали ощущение страха: то, что я играл против живого человека, а не против компьютерного ИИ, и то, что из-за тумана войны я не знал, что делает противник.

Туман войны

Одной из идей, позаимствованной из ранних игр, была идея прятать юниты и здания от взгляда вражеского игрока. Тёмный туман скрывал области игровой карты, пока дружественный юнит не разведал эти области, что было призвано эмулировать обрывочность информации, которую получает генерал о вражеских операциях и войсках в ходе настоящих битв.
Empire, пошаговая многопользовательская стратегия, написанная почти семнадцать лет до того великолепным Вальтером Брайтом (создателем языка программирования “D”), использовала туман войны для этой же цели. Когда область карты была разведана, она оставалась видимой навсегда, так что важной частью стратегии было пораньше разведать достаточно большой кусок карты, чтобы получить информацию о передвижении вражеских войск до того, как они смогут нанести урон важной инфраструктуре или экономике.

Ужас, вызванный неосведомлённостью о действиях врага, стал причиной смерти множества генералов в истории. Добавление такого элемента в жанр RTS — это отличный способ повысить уровень увлечения (и страха). Спасибо Вальтеру и создателям Dune II — ребятам из Westwood за изобретательность.

Компьютерный ИИ

Как известно многим геймерам, в стратегиях игрок под управлением компьютерного искуственного интеллекта (ИИ) часто получается слабым. Игроки привыкли находить стратегии, противодействовать которым ИИ не был запрограммирован и это позволяло им уничтожить компьютерного игрока без особых проблем. Так что для того чтобы представлять для игрока серьёзного противника, ИИ обычно полагается на превосходство в войсках, позиции или на «асимметричный правила».

На старте большинства миссий в Warcraft компьютерным игрокам даются целые города и армии. Больше того, Warcraft содержит несколько асимметричных правил, которые облегчают компьютерным игрокам сражение, хотя, возможно, большинство игроков сочтут эти правила прямым обманом.

Одно из правил, которые мы ввели в помощь компьютерному ИИ – уменьшение количеств золота, которое изымается из шахт. Когда рабочие игрока выходят из золотой шахты, эти рабочие забирают из неё 100 единиц руды и доставляют её в ратушу игрока, очевидно, что такие ходки истощают шахту. Однако, когда рабочий компьютерного игрока совершает такой рейс, из шахты он забирает всего 8 единиц руды, а в свою сокровищницу ИИ доставляет всё те же 100 единиц.

Это асимметричное правило делает игру веселей сразу в двух аспектах: предотвращает «закукливание» игрока в обороне, тактика которая заключается в том, чтобы построить непроходимую защиту, а затем использовать свои превосходные стратегические навыки, чтобы превзойти компьютерного игрока. Очевидно, что такая тактика обречена на провал, так как золото у игрока кончится намного раньше чем у компьютера.

Во-вторых, когда игрок разрушает базу компьютера, там ещё остаётся золото, которое можно будет собрать. Это делает игру быстрей и интересней, чем если бы победу приходилось зарабатывать с ограниченным числом ресурсов.

Большинство игроков в курсе более серьёзных нарушений духа честных состязаний: компьютерный ИИ может видеть через туман войны, ИИ точно знает, что игрок делает в конкретный момент. В действительности это не такое уж большое преимущество для компьютера и, в основном, служило для того чтобы он не выглядел слишком уж глупо.

Интересно, что за долгое время популярности Starcraft (вышел уже более 14 лет назад и в него до сих пор играют) группа программистов ИИ устроила состязание по написанию не мошенничающего ИИ. С помощью библиотеки BWAPI эти программисты написали код, который может вставлять команды прямо в движок StarCraft. Программисты устроили соревнование между своими ИИ, для того чтобы определить победителя. Несмотря на то, что эти ИИ хороши, опытный игрок легко побеждает лучших из них.

Игра против человека

Как человек, который сыграл во много (очень много) стратегических игр перед разработкой Warcraft, я был хорошо осведомлён обо всех ограничениях компьютерного ИИ той эры. Пока я сражался с компьютерными ИИ, иногда проигрывая, много чаще выигрывая, я никогда не был напуган мощью ИИ. Даже когда играл против ужасающих армад Русских в игре Криса Кроуфорда Eastern Front, в которую я играл на Atari 800 друга, до тех пор пока аудиокассета(!) с игрой не перестала читаться из-за старости.

Эти игры были весёлыми, увлекательными и, определённо, напряжёнными, но не страшными. Но что-то поменялось, когда я играл в первую многопользовательскую игру в Warcraft.

Осознание того, что моим противником был человек, не только с точки зрения умения и стратегии, но и с точки зрения скорости реакции, да ещё и того, что я был ограничен в оценке его действий туманом войны, было одновременно и стимулирующим и ужасающим. За всю свою карьеру я не чувствовал такого возбуждения, играя в одиночную игру, какое я ощущал, первый раз играя в Warcraft, когда нельзя было узнать выигрывал я или проигрывал.

Моя кровь получила большой впрыск адреналина, я делал всё, что мог для того чтобы эффективно собирать золото и дерево, строить фермы и бараки, увеличивать наступательные возможности, исследовать карту и, самое главное, для того чтобы сокрушить армию Боба до того, как он сможет проделать то же самое со мной.

Это был не просто матч для тестирования игрового движка, я знал, что он ощущает такое же желание заполучить титул победителя первой в истории многопользовательской игры в Warcraft. Больше того, раньше, когда мы играли в офисе в Doom вместе я завоевал определённую известность после того как по окончании достаточно напряжённой игры Боб настолько разозлился на меня за то, что я частенько убивал его из рокета, что он пообещал никогда со мной больше не играть. Я знал, что он жаждет отыграться.

Когда наши армии встретились в битве, мы удвоили наши усилия по постройке юнитов. Когда я обнаружил его базу и начал атаку, я почувствовал надежду. Действия Боба выглядели дезорганизованными и было похоже на то, что я смогу сокрушить его силы, но я не хотел оставлять ему ни малейшего шанса, так что я продолжал в бешеном ритме атаковать его юниты и постройки везде, где находил.

А затем… крэш:

Любой программист знает, что вероятность того, что новый код будет работать правильно с первого раза, близка к нулю, поэтому не было ничего удивительного в том, что игра упала. Графика игры проскользила до верха экрана и была заменена текстом DOS4GW «экрана смерти», так знакомого геймерам эпохи до Windows. Сейчас у нас есть намного более утончённый Windows диалог об ошибке, который позволяет игроку отправить отчёт, хотя иногда игроки ещё могут увидеть ужасающий «синий экран смерти», который поразительно похож на старый.

После ошибки я вскочил со своего кресла и побежал в кабинет Боба, крича: «Это было пооооооооотрясноооо!», и сразу затем: «… я тебя делал!». Я был очень удивлён, когда тут же услышал опровержение Боба: наоборот, это Боб побеждал меня.

Нашим взвинченным нервам понадобилось несколько минут, чтобы вернуться в норму, но вскоре мы осознали, что у нас была не только ошибка с падением программы, но ещё и проблема с синхронизацией состояний, то, что я назвал «ошибкой синхронизации»: два компьютера показывали полностью разные битвы. Т.е. несмотря на то что игры начались одинаково, проходили они в полностью разных вселенных.

Те, кто не работал над сетевым кодом, могут предположить, что два клиента Warcraft пересылают полное состояние игры туда и обратно каждый шаг игры. Т.е. каждый шаг компьютеры посылают позиции и действия для каждого юнита в игре. В неторопливых играх, с небольшим количеством возможных позиций, таких как шахматы или шашки, это могло бы сработать, но в играх вроде Warcraft, где единовременно могут принимать участие до 600 юнитов, было невозможно посылать такой объём информации через сеть.

Мы предполагали, что многие будут играть с модемами на 2400 бод, которые могли передавать до нескольких сотен знаков в секунду. Молодые геймеры, которые никогда не использовали модемы, должны почитать об этой технологии, которая недалеко ушла от дымовых сигналов и была лишь немного продвинутей стука камней друг о друга. Поймите, это было до Амазона, Гугла и Нетфликса, мы говорим о тёмных веках.

Портируя до того Battle Chess с DOS на Windows, я ознакомился с тем, как могут игры связываться через модем. Я знал, что из-за ограниченной пропускной способности модема будет невозможно пересылать игровое состояние по сети, так что моё решение состояло в том, чтобы пересылать только команды каждого игрока, а затем сделать так, чтобы оба клиента исполняли эти команды одновременно.

Я знал, что это решение сработает потому что компьютеры великолепно выполняют в точности то, что им говорят. К сожалению, выяснилось, что мы, люди, которые их программируют, отнюдь не так хорошо говорим им что делать и это является основным источником ошибок. Когда два компьютера должны делать одно и то же, но из-за ошибки происходит рассинхронизация – это проблема.

Ошибка синхронизации происходит тогда, когда два компьютера, симулирующие игру, выбирают разные ответы на один и тот же вопрос и таким образом расходятся всё дальше и дальше. В фильмах о путешествиях во времени, таких как «Назад в будущее», маленькие изменения, произведённые путешественниками во времени, в прошлом приводят к абсолютно разным будущим. Похожим образом расходятся игры и при игре в Warcraft. На моём компьютере мой эльфийский лучник увидит вашего оркского пеона и атакует, тогда как на вашем компьютере пеон не заметит атаку и отправится собирать древесину. Без механизма по обнаружению и исправлению таких расхождений наши две игры быстро станут полностью различными.

Так что первая игра в Warcraft закончилась вничью, но в то же самое время она стала громадной победой для всей команды – это было невероятно интересно! Вскоре остальные члены команды играли в неё по сети и нашли, что это было вроде «Синего Неба» — чистейшего метамфетамина, который производил Вальтер Вайт из сериала «Во все тяжкие». После того как люди пристрастились к многопользовательской игре, ничто другое не могло с ним сравниваться. Даже несмотря на регулярные вылеты мы знали, что мы делаем что-то грандиозное.

Всё, что нам было нужно – доделать игру.

Вскоре мы сделали ещё более неприятное открытие: у нас было не только бесчисленное количество ошибок синхронизации, но у этих ошибок были так же многочисленные причины. Если бы все такие ошибки были вызваны похожими условиями, мы бы попытались устранить единственный источник проблем. Вместо того, оказалось, что у нас огромное количество разныхтипов проблем, каждая из которых вызывает свой тип ошибки, и каждая нуждается в отдельном решении.

Почему происходят синхронизационные ошибки.

Пока я разрабатывал Warcraft я спроектировал решения для минимизации количества данных, которые необходимо передать по сети, посылая только команды, которые вызвал сам пользователь, такие как «выбери юнит №5», «передвинься на 650,1224», «атакуй юнит 53». Многие программисты самостоятельно проектировали похожие системы, это очевидное решение для проблемы синхронизации двух компьютеров без пересылки всего состоянии игры каждый ход.

Отступление: сейчас, наверное, существует несколько патентов, которые пытаются заявить права на этот подход. С течением времени я пришёл к мнению, что нельзя патентовать программное обеспечение, ведь почти каждая идея в ПО является чем-то, что программист со средним опытом может придумать, а определение патента требует, чтобы патент был неочевиден. Но довольно об этом.

Я ещё не реализовал механизм для контроля синхронизации между компьютерами, так что любая ошибка в коде игры, из-за которой компьютеры сделают разные выборы, побудит игру «раздвоиться», т.е. разделиться на два слабо связанных мира, которые будут продолжать обмениваться информацией, но удаляться друг от друга со всё возрастающей скоростью.

Очевидно, что создание системы для обнаружения ситуаций десинхронизации было следующим заданием в моём длинном списке вещей, которые необходимо сделать для выпуска игры.

Вы знаете конец истории: Warcraft вышел только спустя пять месяцев. Это казалось вечностью, потому что мы работали так много часов каждый день, преодолевали так много препятствий, превозмогли столько испытаний, и создали нечто, о чём мы заботились так трепетно. Я продолжу обозревать эти оставшиеся месяцы в следующих статьях моего блога, так как в это время уместилось столь много всего, что невозможно впихнуть эти воспоминания в эту, и без того слишком длинную статью.

Источник: habrahabr.ru