Перейти к содержанию

D1gaTel

Создатель
  • Постов

    1 257
  • Зарегистрирован

  • Посещение

  • Победитель дней

    45

Весь контент D1gaTel

  1. Лагать будет, если будет стоять на хосте, там, где все сервера. Играл на таком сервере.
  2. Кстати, на смену ника тоже действует акция :D
  3. Она вообще бесплатна будет, если успеешь добавить ее к себе в аккаунт. Плохо то, что в стиме ее не активировать.. DRM-Free
  4. Игры полученные после регистрации на gog.com: 1. TEENAGENT 2. TYRIAN 2000 3. LURE OF THE TEMPTRESS 4. BENEATH A STEEL SKY 5. DRAGONSPHERE 6. ULTIMA™ 4: QUEST OF THE AVATAR 7. WARSOW 8. WORLDS OF ULTIMA: THE SAVAGE EMPIRE 9. ULTIMA WORLDS OF ADVENTURE 2: MARTIAN DREAMS 10. TREASURE ADVENTURE GAME Оказывается 10 игр, точнее 10 + TORCHLIGHT
  5. На сайте GOG.COM стартовала летняя распродажа игр «2013 #NoDRM Summer Sale». В том числе, только до конца 20 июня будет доступна для бесплатного скачивания известная Diablo-like игра от Runic Games Torchlight. Игра доступна для Windows (XP, Vista, 7, 8) и Mac OS X (10.6.8 или выше). В качестве бонуса к игре Вы получаете мануал, обои, саундтрек, аватарки и редактор уровней. P.S. При регистрации вы получите 8 игр в добавок.
  6. Сегодня мы представляем вам перевод очень познавательной статьи за авторством человека, который восемь лет проработал в Blizzard Entertainment и участвовал в создании таких легендарных проектов, как Warcraft, Diablo и Starcraft. Патрик Уайетт не только причастен к этим мастодонтам игростроения, он также является одним из основателей ArenaNet, создавшей Guild Wars. Заметка посвящена трудностям, которые встали на пути программистов, делавших Starcraft. Но, как бы невзначай, автор умудрился охватить всю картину того, что происходило тогда в фирме Blizzard с точки зрения разработчика. Если будет положительный фидбек, мы переведем и продолжение. Итак! Хотите узнать про то, сколько часов подряд может работать программист из Близзард, кто придумал Diablo, или про встроенный голосовой чат в первом старике? Тогда - вперед! Начало После двух с половиной лет упорной работы над Starcraft, игра все еще была настолько багована, что словами не передать. А времени до релиза оставалось все меньше и меньше, и если игры серии Warcraft отличались своей надежностью, то со Starcraft вплоть до момента выхода не могла нормально работать даже команда тестировщиков. Игра продолжала падать! Да и с выпуском игры беды не закончились: нам потребовалось приложить массу усилий для того, чтобы залатать дыры с помощью патчей. Почему? На то была масса причин. Орки в космосе Изначально Starcraft планировался как относительно небольшой проект, на разработку которого потребуется не больше одного года. Мы рассчитывали выпустить игру к Рождеству 1996. Руководство проекта состояло из людей, работавших до этого над Shattered Nations и над пошаговой стратегией по мотивам X-COM, которую Blizzard анонсировала в мае 1995, но затем отказалась от ее разработки. Эти ребята были готовы сделать игру очень быстро - так, чтобы у студии не возникло большой паузы между релизами: Q4 1994 - Warcraft. Q4 1995 - Warcraft II. Q4 1996 - Плановая дата выхода Starcraft. В реальности, как мы знаем, игра вышла во втором квартале 1998. Сейчас запланированные сроки кажутся абсурдными, но тогда президент компании Allen Adham находился перед лицом необходимости увеличить доходы. Первые игры Blizzard принесли бОльшие дивиденды, чем от них ожидалось, и это разожгло у некоторых людей некоторые аппетиты. Идеология нового проекта была такова - вот вам немного ресурсов и времени, сделайте нам "орков в космосе". Картинка с E3 1996 года иллюстрирует путь, по которому пошли разработчики. Да, я бы в такое играть не стал. В это время у Blizzard появился новый проект, который стал оттягивать и без того скромные силы от Starcraft. История такова - одна небольшая фирма под названием Condor Studios начала разработку RPG под названием... Diablo. Ресурсы, которыми обладали их разработчики, были, даже по тем временам, весьма скудны - 1.2 миллиона долларов. Этих денег явно не хватало на завершение проекта. Когда это стало окончательно ясно, на сцене появились люди из Blizzard, и студия Condor сменила вывеску на Blizzard North. Работников, которые трудились над Starcraft, стали переводить в новое подразделение для работы над Diablo. Этот процесс продолжался до тех пор, пока в старкрафт-команде не осталось буквально ни одного человека. Даже директор проекта Starcraft был занят на доделке инсталлера Diablo, который начал делать я, но из-за большой занятости не успел дописать до конца. После выпуска Diablo в 1996 году у нас появилось время, чтобы вернуться к Starcraft и посмотреть на проект свежим взглядом. И то, что мы увидели, нас не обрадовало. Игра выглядела очень плохо, даже по сравнению с демо-версией какой-нибудь Dominion Storm, представленной на Е3 в том же году. Успех Diablo повысил планку, и по Starcraft было принято решение, которое подтвердило кредо компании - не выпускать игры, пока они не готовы. Но на пути реализации этого решения нас ждали многие трудности. Все видели, что Starcraft в его нынешнем виде недостаточно хорош, чтобы задать тон в жанре RTS, в котором мы уже достигли успеха, выпустив игры серии Warcraft. В тот момент, когда мы начали перезапуск проекта, согласно данным Computer Gaming World Magazine, по всему миру в разработке находилось более 80 игр в жанре RTS. В гонке участвовала и сама Westwood Studio, которая и придумала этот жанр. Мы должны были сделать что-то, что могло бы всех сразить наповал. После успеха Warcraft и Diablo мы могли рассчитывать на самое пристальное внимание прессы и игроков. В нашей индустрии о студии судят по ее последнему проекту. Мы должны были двигаться дальше, и принимать связанные с этим риски. Новые лица В создании Warcraft II участвовали всего шесть программистов и два помощника. Для работы над Starcraft нам понадобилась команда побольше. А это значит, что в коллектив влилось много сотрудников без нашего опыта работы. Мы немного растерялись, и эти новые программисты часто учились на своих ошибках, которых лучше было бы избежать в таком проекте. Но гонка была такая, что некогда было разбирать чужой код и натаскивать менее опытных товарищей. Все писали код как сумасшедшие, у нас не было времени на то, чтобы остановиться и посмотреть на то, что уже написано. Проблема была не только с рядовыми программистами. Даже руководитель разработки не имел опыта по созданию нормального игрового движка. Bob Fitch занимался написанием игр несколько лет, и достиг больших успехов, но в прошлом он больше портировал игры и никогда не создавал игру такого масштаба с нуля. Он руководил работами над Shattered Nations, но этот проект был заморожен и никто теперь не скажет, была ли архитектура той игры удачной. Команда выкладывалась по полной, часто в ущерб здоровью и личной жизни. Никогда не видел такого самоотверженного труда. Но некоторые решения, которые были приняты тогда, создали разработчикам очень много проблем. Перемены После месяцев работы над созданием Diablo и выпуском исправительных патчей я вернулся в команду Starcraft. Я не ожидал, что буду снова заниматься латанием дыр, но именно так и получилось. Я думал, что это будет легко, поскольку знал буквально каждый функциональный блок в Warcraft, но, к моему ужасу, я обнаружил, что большая часть нашего движка была выброшена на помойку. Структура классов, отвечающая за юниты, была полностью переписана, а их диспетчер вообще удален из проекта. Диспетчер был моим творением. Он отвечал за то, как юниты планировали свои действия. Каждая боевая единица периодически посылала запрос этому диспетчеру: "что мне делать сейчас?", "надо ли пересчитать мой путь заново?", "нет ли более подходящей цели для атаки?", "поступали ли новые команды от игрока?", "не умер ли я, и не пора ли мне освободить память?" и так далее. Часто есть причины, по которым стоит полностью переписать некоторый код, но это всегда несет некоторые риски. В своей книге "Вещи, которые вам никогда не следует делать" Джоэл Спольски выразил это более красноречиво: "То, что вы сделаете заново, необязательно будет лучше, чем было сделано до этого. Если у вас будет новая команда программистов, возможно они повторят ошибки, которые совершила первая команда, и добавят своих." Месяцы ушли на то, чтобы заставить движок Warcraft работать так, как следует. А новая команда вместо того, чтобы приспособить его под новые задачи, решила учиться писать движки заново. Архитектура игрового движка Я написал движок Warcraft под MS-DOS на Watcom C. Для перехода на Windows Боб решил использовать Visual Studio и перейти на C++. Решение обоснованное, но надо признаться, мало кто из разработчиков хорошо знал особенности этого языка. C++ это мощный инструмент, но в неумелых руках... Как выразился его создатель Бьёрн Страуструп: "При помощи С легко ранить себя в ногу; с С++ это сложнее, но если уж случится, то вы отстрелите себе всю конечность." Опыт показывает, что программисты чувствуют себя обязанными попробовать все возможности нового языка в первом же проекте. Так это случилось и у нас с механизмом наследования. Опытный программер содрогнется, если встретит такую иерархию классов: CUnit < CDoodad < CFlingy < CThingy Объекты класса CThingy отвечали за спрайты, которые могли появляться в любом месте, но не могли сами двигаться или выполнять какие-то задачи. CFlingy отвечали за обломки, которые получаются во время взрыва и, кувыркаясь, разлетаются в разных направлениях. CDoodad, дай бог памяти, был абстрактным и совершенно ненужным классом. Ну а поверх всего этого горделиво взгромоздился класс CUnit. Поведение юнитов было размазано понемногу по всем этим классам, поэтому вы должны были знать их все, если хотели что-то сделать с боевой единицей. Кроме этого бардака в структуре классов, определение класса CUnit было разбросано по множеству файлов: class CUnit ... { #include "header_1.h" #include "header_2.h" #include "header_3.h" #include "header_4.h"}; Каждый из этих файлов содержал несколько сотен строк, которые могли ссылаться, как это не удивительно, на родительский класс. Тогда еще не была в ходу мантра "предпочитай композицию наследованию", но программисты Blizzard выучили этот урок одними из первых. Два месяца до запуска Вот с таким наследием мы подошли к моменту, когда до выхода игры осталось всего два месяца. С учетом того, какие работы предстояло провести (переход на изометрию, новый редактор карт, режим игры через battle.net), стало понятно, что игра не выйдет вовремя. А ведь еще требовалось время для художников, дизайнеров, специалистов по звуку, тестировщиков и так далее. Но команда программистов продолжала работать в режиме аврала в течение последующих 14 месяцев. Некоторые работали по 40 или даже по 48 часов подряд. Больше я нигде не видел таких припадков мазохистского энтузиазма. Мой опыт ночного программирования при создании Warcraft и Diablo показывает, что в этом нет никакого смысла. Все потом приходилось переписывать при свете дня и с ясной головой. Экстремальный режим работы неприемлем там, где требуются знания и творческий подход. Это приводит к множеству ошибок. Такой режим нам никто не навязывал, мы просто хотели делать самые лучшие игры. Но, оглядываясь назад, понимаешь, что это было глупо. Можно было бы достигнуть лучшего результата меньшими усилиями. Сейчас я горжусь тем, что моя команда, которая работает над Guild Wars, по ночам просто спит. Причины падений Starcraft В сферу моей ответственности входили: туман войны, определение зоны видимости, поведение летающих юнитов, голосовой чат и т.д. Но все чаще мне приходилось исправлять чужие ошибки. Стоп! Голосовой чат в 1998 году? Да я сделал такую систему, основанную на кодировании голоса в фонемы при помощи сторонней библиотеки, в декабре 1997. Но каждая звуковая карта в нашем офисе требовала обновлений драйверов для того, чтобы голосовой чат начал на ней работать. Мы бы потратили на техподдержку больше денег, чем заработали на игре. От голосового чата пришлось отказаться. В общем, я исправлял все больше ошибок. Иногда это были и мои ошибки, но чаще - странные конструкции, порожденные мозгами уставших программистов. После окончания работы все были поражены, сколько ошибок мне пришлось в итоге исправить. Вы можете подумать, что при таком количестве багов будет сложно назвать какой-то один их источник? Вовсе нет. Больше всего проблем доставляли связные списки. Они активно использовались для отслеживания поведения связанных юнитов. Всего в Starcraft могло быть до 1600 юнитов, что вдвое больше, чем в Warcraft 2, и было важно быстро находить юниты определенного типа, держа их в связанных списках. Там были списки всех возможных видов: все юниты, все строения, все "генераторы энергии" и многие другие. Все списки были двусвязными, чтобы облегчить удаление или добавление одного элемента. К сожалению, каждый программист сам работал, как мог, с этими списками. Не было единого для всех набора функций. А такой подход всегда хуже, чем наличие хорошо отлаженной библиотеки. Чтобы безопасно убрать элемент из списка, надо было каждый раз учитывать, что на него могут ссылаться поля других списков. Поэтому игра постоянно вылетала. Кто виноват? Самое смешное, что эти проблемы возникли на ровном месте. Еще до всех этих событий была написана библиотека Storm.dll, которая использовалась в том же Diablo. Она отлично работала с двусвязными списками при помощи шаблонов С++. В начале разработки Starcraft она использовалась, но новая команда, как мы помним, решила изобрести велосипед, и выкинула в том числе и эти функции под предлогом того, что они мешают создавать файлы сохранения. Файлы сохранения Многие игры, в которые я играл до создания Warcraft, имели очень плохой механизм сохранения. Особенно долго сохранялись игры фирмы Origin, даже если учитывать мощность тогдашнего железа. У Warcraft этих проблем не было. Нам пришлось применить некоторые уловки, чтобы игра писала сразу большие блоки данных, а не рыскала по памяти и не писала на диск в час по чайной ложке. Массив с юнитами мог быть выгружен за один раз. И другие статические переменные можно было выгрузить так же: данные о ландшафте или зонах тумана войны. К тому же, код, отвечавший за эту функцию, был прост и понятен. Но этот способ работал, потому что в Warcraft не использовались указатели. Starcraft, со своими указателями на списки юнитов, это совсем другое дело. Надо было позаботиться обо всех указателях, чтобы выгрузить 1600 юнитов за один раз. Такие вот пироги. Верни, как было! После исправления множества ошибок со связными списками, я стал упорно настаивать на том, чтобы мы вернулись к использованию функций из библиотеки storm при работе со списками, даже если это усложнит процесс сохранения. Под словом "упорно" нужно понимать "нахально" и "грубо". По другому спорить мы тогда и не умели, если только дело не касалось того, что заказать на обед. Я проиграл этот спор, поскольку "до выхода игры осталось всего два месяца". Было принято решение продолжать латать этот тришкин кафтан, что доставило нам кучу неприятностей в будущем. Это стало хорошим уроком и для меня, как программиста. Алгоритм поиска пути Хочу привести еще один пример, когда вместо исправления ошибок мы занимались латанием дыр. Когда мы перешли на изометрию, рендер заднего плана остался прежним. А написан он был еще в 1993 году. Рендерить изометрию при помощи старого движка было несложно. Были небольшие трудности с редактором карт, где игроки оперировали объектами, повернутыми по диагонали. Проблема была с поиском пути. Вместо области 32 на 32, которая была или проходимой или нет, теперь мы имели дело с микро-областями 8 на 8 пикселей, что резко увеличило число вариантов при переборе. К тому же, стали возникать ситуации, когда путь был, но являлся слишком узким для больших юнитов. Если бы не талант наших программистов, эти проблемы могли стать непреодолимой преградой. Но получилось так, что система была окончательно готова перед самым выходом. О проблеме поиска пути, пожалуй, стоит написать больше в следующей статье. Конец первой части На этом я пока свое нытье заканчиваю. Сделать Starcraft было трудно, и главным образом из-за неверных решений, принимаемых на всех уровнях компании - решений, относящихся к концепции игры, технологиям и дизайну. К счастью для нашей команды, мы перестали добавлять новые фишки в тот момент, когда у нас еще оставалось достаточно времени до даты выхода. И я рад, что мы писали не на скриптовом языке, поэтому игроки не могут видеть, какие кучи мусора скрываются под красивой оболочкой. В следующий раз я расскажу о том, какие решения использовались при работе над Diablo, Battle.net и Guild Wars. Источник: noob-club.ru
  7. Я очень люблю игры компании Blizzard и, наткнувшись недавно на блог одного из из создателей серии Warcraft — Патрика Вайата, решил перевести третью заметку о создании первой части этой замечательной игры. Перевод первых двух (первая, вторая) уже есть на хабре. Итак, вас ждёт рассказ об источниках финансирования Blizzard, о том, как Стю Роуз устроил дизайнерский переворот, о тумане войны и, самое главное, о впечатлениях автора статьи от самой первой многопользовательской игры и о её неожиданных итогах. За всем этим добро пожаловать за хабракат. Это мой первый перевод, так что я буду рад всем сообщениям об ошибках, замечаниям и исправлениям. Самая первая многопользовательская игра в Warcraft обернулась сокрушительной победой, ужасным поражением и ничьей, всем сразу. Но как же это стало возможно? Здесь есть о чём рассказать. Этот рассказ будет включать в себя описание ИИ, экономики игры, тумана войны и ещё много чего. Читайте, если у вас есть много свободного времени. Это третья часть истории. Часть 1, Часть 2 После шести месяцев разработки, которая началась в сентябре 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
  8. Dexter_Morgan, смотря какая модель видюхи. У меня гиг, на зомби 15фпс
  9. fraerook, Так вроде всё нормально. С профилем я химичил, добавлял аватарку
  10. fraerook, Стиль адаптирован под разрешение 1280x1024+, в ближайшее время постараюсь исправить. Кстати, можешь скриншот сайт скинуть? C H E M O D A N, добавил аватарку.
  11. , сделал, кэш почисти иконки появятся. fraerook, какое разрешение?
  12. C H E M O D A N, дошло, сделаю. , сделаю.
  13. C H E M O D A N, что то я тебя не понял. Где мини аву сделать? На предыдущем стиле?
×
×
  • Создать...