Добро пожаловать, berk
Twitter Группа Steam Страница Вконтакте Группа C.O.R.E. Dragon Age Контакте Новостная лента RSS
/ Статьи / Игры и игровые серии / Neverwinter Nights

[Neverwinter Nights] Проблемы сетевого проектирования

Автор: Scott Greig | Добавил: m00n1ight, 03.05.2016 | Просмотры: 605

Neverwinter Nights

Год назад на сайте появился перевод статьи о трудностях разработки Neverwinter Nights. Если вы её пропустили, самое время ознакомиться, ведь сегодня мы начнём подробный рассказ о создании сетевого режима, подарившего игре столь долгую жизнь.

Вернёмся в 1998 год. Миллениум грозил сожрать все наши компьютеры, поэтому все программисты, знавшие, что означает акроним COBOL, переводили все даты в базах данных на четырёхзначный формат отображения года. Большинство игроков, не знакомых с программированием, не обращали на это никакого внимания, с головой погрузившись в миры Starcraft и Half-Life. BioWare только что выпустила игру под названием Baldur’s Gate, и мы, слегка измождённые, вернулись с рождественских каникул в январе 1999 года, чтобы заняться следующим проектом: Neverwinter Nights.

Neverwinter Nights (NWN) задумывалась как лучшая из всех существовавших на тот момент многопользовательских ролевых игр на базе D&D. Мы стремились не просто рассказать нашу историю, но и дать возможность всем остальным рассказывать свои истории на своих серверах. Чтобы ведущие (Dungeon Masters) могли заходить на сервер и помогать (или мешать) игрокам сколько им вздумается. Чтобы разработчики легко переносили свои модули из настольной D&D в игровой мир с помощью созданного нами редактора. Всё это звучало очень круто — пока мы не осознали, за что взялись! Первые сомнения появились, когда остальные разработчики начали говорить, как им не терпится сыграть в нашу игру, и как они рады, что не они занимаются её созданием.

Baldur’s Gate получилась очень хорошей однопользовательской ролевой игрой, но, в то же время, мы допустили целый ряд серьёзных ошибок, стремясь достичь грандиозных и амбициозных целей в Neverwinter Nights. Мы рассмотрим следующие основные проблемы (одни нам удалось разрешить, другие нет): дизайн пользовательского игрового содержимого; ограничения, связанные с многопользовательским режимом игры; подбор персонала для реализации этого режима; одновременная разработка игры для разных платформ и системы репутации. Надеемся, что и вы найдёте что-нибудь полезное для себя в нашем обзоре удачных решений и проблем, возникших в процессе разработки.

Пользовательское игровое содержимое

В основе каждой игры лежат несколько ключевых требований, определяющих всю её структуру. В одной ситуации основополагающим фактором выступают технологии, в другой — пользовательский интерфейс и игровой процесс. Структуру Neverwinter Nights диктовало наше видение игры — мы хотели сделать материалы, создаваемые пользователями и разработчиками, одинаково важной составляющей игрового мира. Возникла необходимость набрать большое количество игроков, заинтересованных в разработке любительского содержимого. Мы знали, что желающих немало — у каждого первого фаната D&D на дальней полке завалялся старый модуль для настольной игры. От нас требовалось только создать систему, позволяющую фанатам сдуть пыль со своих старых модулей и перевести их формат Neverwinter Nights.

Neverwinter Nights была не первой игрой с подобным подходом. Adventure Construction Set от Стюарта Смита, выпущенный Electronic Arts в 1987 году, стал первым полноценным коммерческим набором для создания ролевых игр. Игроки могли составлять карты, рисовать собственное графическое оформление, редактировать параметры существ и вещей. В программе даже был пример небольшого приключения. Самая большая проблема состояла в том, что игроки могли поделиться собственноручно созданным приключением только со своими друзьями. В лучшем случае, была возможность загружать горстку файлов через модем на электронную доску объявлений.

Neverwinter Nights даже не стала первым набором для создания ролевых игр на основе D&D. В 1993 году SSI выпустила Unlimited Adventures, используя классический движок и содержание золотого издания игр AD&D. Так же как и «Набор для создания приключений» — это классический пример, когда идея обогнала своё время. Только с повсеместным распространением интернета каждый игрок получил доступ ко всему многообразию созданных пользователями приключений.

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

Когда мы только начали размышлять о создании Neverwinter Nights, существовало активное сообщество создателей любительских модификаций для Quake и позже Halflife. Многие модификации отличались профессиональным качеством, но их количество не оправдывало усилий, необходимых для разработки редактора для создания ролевых игр. Многие пользователи, желающие создавать модификации для Quake и Halflife не обладали нужными техническими навыками. Тем не менее, в то же время процветало сообщество разработчиков карт для Starcraft. Каким-то образом мы должны были совместить возможность создания трёхмерных уровней, как в Quake, с редактором для составления ролевых игр так, чтобы системой могли пользоваться все, кто делал карты для Starcraft.

После нескольких экспериментов с произвольными сетками и полем высот (heightfield), мы решили создать систему, использующую трёхмерные плитки. Главным достоинством данной системы являлась простота создания местности. Пользователи могли выбрать кисть с определённым шаблоном и рисовать реки, мосты, коридоры и дороги. Чтобы вашим редактором пользовалось много людей, результат его работы должен быть виден после первого применения, иначе большинство сразу разочаруются в системе.

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

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

Иногда пользователи редактора оказываются опасно умными (как для самих себя, так и для нас). Когда мы выпустили «Трон Баала» — дополнение к Baldur’s Gate II, среди игроков была популярна одна модификация игровых правил. К сожалению, эта модификация появилась как раз между официальным выходом дополнения и его появлением в магазинах. Проблема заключалась в том, что наш установочный файл не перезаписывал файлы, добавленные после установки игры. В результате, у всех, кто пользовался модификацией, программа установки выдавала ошибку.

Разрабатывая Neverwinter Nights, мы стремились предоставить игрокам возможность создавать полноценные модификации без разрушения базовой структуры игры и без вылетов при подключении обычных клиентов к модифицированному серверу. В результате получился файл hack pak (названный так по своему расширению — .hak) — контейнер для всех нестандартных файлов (созданных пользователями с нуля или модифицированных игровых), ассоциируемый только с определёнными модулями приключений. При попытке подключения к модифицированному серверу, появлялось оповещение о необходимости установки hak pak, и стандартный клиент вежливо отключался.

С одной стороны, система hak pak выполняла все вышеперечисленные действия. С другой стороны, возникла большая проблема добавления визуальных ресурсов в Neverwinter. Для уменьшения загрузки сети, визуальные параметры помечались индексными номерами. Например, внешний вид существа определялся его идентификационным кодом. Все коды находились в единой таблице внешних характеристик. В неё входило название трёхмерной модели, информация об озвучке, скорости передвижения, занимаемом пространстве и другая подобная информация. Для создания пользовательской модели существа добавлялась новая запись в таблице. Сохранение нового существа в файле hak pak не представляло проблемы, так как он также содержал модифицированную таблицу внешних характеристик. К сожалению, по мере того, как мы создавали новых существ, и пользователи пытались объединить несколько hak pak файлов, появлялись конфликты в нумерации записей таблицы внешних характеристик. В результате, чтобы решить данную проблему, нам пришлось выпустить программу по объединению hak pak файлов. Если бы у нас была возможность всё переделать, мы бы создали систему отдельных файлов, содержащих информацию о существах, не привязывая их внешний облик к индексам в таблице. При загрузке местности сервер бы сообщал, каким индексированным файлам соответствуют новые существа, чтобы каждый клиент мог верно связать ресурсы hak pak с индексами сервера.

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

Сложности с многопользовательским режимом игры

Мы чётко осознавали все проблемы многопользовательской версии Baldur’s Gate, появившиеся сразу после её выхода. За две недели до появления игры на прилавках, мы всё ещё вносили ключевые изменения в движок. Оставалось очень мало времени, чтобы исправить все недочёты и сделать все кампании доступными как в одиночном, так и в многопользовательском режимах.

Сокращение сетевого трафика стало первостепенной задачей. Многопользовательский режим был основной особенностью NWN, и мы делали всё возможное, чтобы сократить трафик, потребляемый каждым клиентом. В Baldur’s Gate трафик на пользователя в среднем превышал 2 килобайта в секунду, обычно мы посылали каждому клиенту файлы сохранений размером 100 KB, пока другие подключались к серверу. В NWN мы рассчитывали поддерживать шесть или семь клиентов через один 56-килобитный сервер. По грубым подсчётам, трафик на один клиент составил бы 500 байт в секунду. Ранее использованный в Baldur’s Gate подход требовал тщательной переработки.

Пересылка одного игрового ресурса размером 100 килобайт через 56-килобитный сервер заняла бы 3 минуты, что недопустимо для большинства пользователей. Поэтому все данные должны были находиться на компьютере во время игры, что создавало конфликт с пользовательскими материалами. Мы отказались от идеи автоматической загрузки файла hak pak с сервера во время игрового процесса, так как это заняло бы гораздо больше времени, чем скачивание с сайта. После выхода игры мы обнаружили, что отсутствие автоматической загрузки hak pak файла сильно ограничивает доступ к многопользовательскому режиму, так как почти каждый модуль использует свой hak pak. В настоящий момент данный вопрос ещё не решён, но должен быть решён к моменту выхода этой статьи [прим. пер. — 6 марта 2003 года]!

Так как игровой мир делился на несколько местностей, мы искали способ пересылать описание местности с минимальным использованием трафика. Мы уже говорили выше о системе трёхмерных плиток, но недостаточно просто определить «плитка 432 в положении x = 20, y = 30». Отображение светотени в каждой области должно соответствовать пропускной способности сервера. Иногда требуются сотни точек освещения, чтобы местность выглядела красиво. Так как видеокарты не в состоянии достаточно быстро обрабатывать динамическое освещение, понадобилась система статического освещения. Стандартные инструменты, такие как теневые карты, изначально работали слишком медленно, чтобы создавать освещение в реальном времени, и объём данных на выходе получался слишком большим, чтобы загружать его в процессе игры. В качестве решения мы включили информацию об освещении в сами плитки. Таким образом, мы могли просто указывать, какие плитки подсвечены и каким цветом. Получив описание местности с сервера, клиент подсчитывал значения вершин освещения для всего диапазона вершин данного освещения. В то же время подсчитывались значения теней для луны или солнца. Мы обнаружили, что мощные персональные компьютеры могут создавать тени на лету в ограниченном наборе освещений, что обеспечило выразительность теням в Neverwinter Nights.

Наконец, требовалось сократить трафик, потребляемый во время игрового процесса, так как в Baldur’s Gate сервер пересылал много резервных данных каждому клиенту, чтобы каждый подключённый компьютер мог автономно использовать ИИ. В NWN сервер самостоятельно управляет ИИ. Это позволило построить модель сети по образцу Tribes [Frohmayer00].

Несколько параметров, необходимых для правильного отображения существа, не должны перегружать сервер многопользовательской игры, и сначала проблем не возникало. Однако мы хотели показать не только расположение, ориентацию и движение существ, но и разнообразные визуальные эффекты. Каждое существо могло обладать несколькими визуальными эффектами для отображения его различных состояний — например, у личей было семь визуальных эффектов. Для игровых существ мы создали длинные списки подготовленных, хранящихся в памяти заклинаний и полезных умений. Сервер регулярно проверял эти списки на предмет изменений, которые необходимо отобразить в игре. Таким образом, клиент проводил множество ресурсоёмких сравнений длинных списков существ. У нас не хватало времени на оптимизацию до выхода игры, когда мы обнаружили, что перестарались с сокращением трафика, и производительность ЦП стала основным ограничением работы сервера. Даже самые современные компьютеры не могли поддерживать более чем 40 игровых персонажей.

Вопреки ограничению на скачивание файлов во время игрового процесса, требовалось пересылать некоторые данные (файл персонажа) с клиента на сервер. Для сравнения, то же самое делали участники настольных ролевых игр, передавая Ведущему листы со своими персонажами на одобрение. Конечно же существовало множество ограничений. На большинстве серверов не было активных Ведущих, способных визуально оценить и одобрить персонажей, поэтому требовался сценарий для проверки соответствия созданного персонажа и игрового стиля пользователя установленным правилам. Мы рассчитывали написать сценарий проверки за пару недель, совершенно упустив из виду сложности правил D&D. В конце концов, нам пришлось убрать несколько проверок повышения уровня, чтобы уложиться в график. К сожалению, нехватка этих проверок сразу дала о себе знать, и мы добавили их в одном из первых переизданий.

С какими сложностями мы столкнулись? В ролевых играх персонаж включает в себя и все вещи, которые он носит на себе или в своём походном мешке. Основную информацию о существе составляет список его вещей! Тем не менее, стандартные вещи не представляли проблемы. Существовала возможность проверить, обладает ли существо необходимыми навыками для обладания той или иной вещью. Более того, каждый предмет проверялся на соответствие параметрам существа! Персонаж первого уровня не может носить Вострый меч, добавляющий +5 к отрубанию головы. Поэтому на сервере нужна автономная система, предотвращающая случаи подобного рода. Данная система должна работать не только при добавлении персонажа на сервер, но и в процессе обмена вещами.

Мы применили систему ограничения вещей по уровню (ILR), позволяющую оснащать персонажей только предметами определённой стоимости. Если вы находили слишком дорогостоящую вещь, сервер включал IRL, запрещая экипироваться или даже носить данный предмет с собой, чтобы передать кому-нибудь! В то же время, объекты, необходимые для прохождения сюжета, также обладали определёнными характеристиками, поэтому им присваивалась нулевая стоимость. Таким образом, персонажи первого уровня могли пользоваться всеми сюжетными предметами. Тем не менее, мы использовали единую систему проверки экипированных и носимых вещей. Наши изобретательные специалисты из отдела тестирования обнаружили, что могут создать «сюжетный» Вострый меч и благополучно экипировать им персонажа первого уровня или положить клинок в инвентарь! Поэтому нам пришлось опять переделать систему, ограничивая экипировку вещей по уровню, но оставляя их нулевую стоимость.

Кроме того, инвентарь содержал скрытые ячейки для шкур, когтей и челюстей разных существ. С помощью них мы смогли воплотить самые необычные эффекты от атак монстров Dungeon & Dragons. В игре эти ячейки были заблокированы, однако пользователи обнаружили, что могут взломать файл персонажа и поставить Вострый меч в ячейку «когти», предоставляя своему монстру хороший шанс убить противника одним ударом лапы. Возможно, эту лазейку бы ещё долго не обнаружили, не предоставь мы все необходимые инструменты, демонстрирующие «скрытые» ячейки в профиле существ!

Мы не могли запретить пользователю составить сценарий, способный убить сервер, записать этот сценарий в параметры персонажа и испортить удовольствие от игры всем остальным. Поэтому мы запретили клиентам посылать на сервер исполняемые сценарии, исключив их из файлов персонажей. Такое решение привело к множеству ограничений в структуре игры. В The Sims каждый объект содержит весь код для взаимодействия с персонажами. В NWN каждый игровой модуль обладает глобальным сценарием с информацией о поведении всех объектов, появляющихся в игре. Так как пользователи могли создавать свои предметы, существовала возможность появления дубликатов (по внешнему виду и цвету) ключевых объектов в модуле. Чтобы избежать конфликта между одинаковыми предметами, мы предоставили пользователям систему паролей (ярлыков) — предмет действовал согласно модулю только при совпадении паролей. Тем самым мы значительно усложнили систему интеграции пользовательских предметов — чтобы добавить свой объект в игру, пользователь должен был скопировать и вставить часть сценария объекта из одного модуля в другой и перенести файл объекта в следующий по ходу игры модуль. Тем не менее, в многопользовательской игре безопасность сервера решает всё.

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

По нашему изначальному плану сюжет NWN состоял примерно из 30 двухчасовых миссий — пользователи могли пройти их сообща, насладиться игровым процессом и выйти из игры. Однако изучение рынка сбыта убедило нас в необходимости создания полноценного сюжета для одиночного прохождения. Игроки не хотели участвовать в миссиях в стиле Mechwarrior — получить инструктаж, безумной толпой напасть на врагов, убить всех, обыскать трупы и вновь собраться в таверне за кружкой медовухи. Мы разделили сюжет на четыре части — а это значит, добавилось в шесть раз больше существ и объектов при том же количестве используемой оперативной памяти!

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

Более серьёзной проблемой стала стабильность сервера. Теперь он должен был работать без перебоев не два часа до выхода из кампании, а выживать по десять часов в том же игровом мире, а если он выдержал 10 часов без вылетов, то обязан продержаться и в режиме 24 часа 7 дней в неделю! К сожалению, у нас не хватило времени реорганизовать все системы для обеспечения очень продолжительной работы сервера.

Сколько нужно программистов, чтобы напортачить в Neverwinter Nights?

Neverwinter Nights стала самым большим проектом BioWare за всю историю студии. К моменту её выхода практически каждый работник компании внёс свою лепту в создание игры. Одновременно над проектом работали до 25 программистов. В этом состояло радикальное отличие от Baldur’s Gate — нашего предыдущего крупнейшего проекта, над которым работали только 7 программистов. Нам понадобилось очень много людей, чтобы воплотить невероятно большое количество игровых особенностей за сравнительно короткий срок в три с половиной года. Для сравнения, программирование Baldur’s Gate заняло почти три года. По наилучшим подсчётам в Neverwinter Nights вдвое больше строк кода и индивидуальных особенностей. Одновременно мы выяснили ещё одну интересную «истину» — если старший программист управляет работой как минимум четырёх младших программистов и предоставляет им технические данные, сам он созданием кода не занимается. Даже в команде опытных разработчиков нужен ответственный за каждую основную систему, чтобы весь проект не пошёл крахом.

После четырёхкратного увеличения штата возникла необходимость перераспределения обязанностей и сфер ответственности. Мы успешно разделились на команды по разработке редактора и графического оформления, так как все понимали, как их системы связаны с основной игрой. Разделение программного кода представляло совершенно иную задачу. Опыт Baldur’s Gate подсказывал, что многопользовательский режим должен быть вписан в игру с самого начала. Разрабатывая Baldur’s Gate, мы начали программировать многопользовательский режим, уже наполовину завершив весь проект. Одному нашему программисту пришлось пересмотреть все системы и добавить в них поддержку многопользовательского режима, борясь со стандартными для таких случаев проблемами. В Neverwinter мы программировали многопользовательский режим с первого дня. Мы создали две команды — одну для клиента, другую для сервера с требованием, чтобы модули сервера и клиента сообщались только на сетевом уровне. В первый год у нас были только автономные версии клиента и сервера. Разделение продолжилось даже после создания встроенного исполняемого модуля клиента/сервера. Над клиентом и сервером работали разные программисты, поэтому они практически не пытались «общаться через стену» и делиться данными напрямую. Нам удалось создать игру, полностью построенную на многопользовательском режиме, что помогло избежать многих типичных проблем. К сожалению, в результате данного решения усложнилась реализация систем и организация деятельности. Мы могли проверить работоспособность систем только одновременно на клиенте и сервере, поэтому несколько раз возникали задержки в программировании, пока одна команда дожидалась другую. Вдобавок при таком подходе ставились под сомнения авторские права на каждую систему. Ни один из программистов не чувствовал себя в полной мере ответственным за систему, что неизменно снижало мотивацию и интерес к работе.

Намного лучше прошло разделение программистов на команды по разработке игры и редактора. Основное отличие заключалось во взаимодействии систем. Во-первых, редактор и игру связывал однонаправленный процесс. Редактор создавал файлы, а игра читала из них данные. Редактор также требовался для чтения данных при редактировании, он подтверждал целостность информации без изменения игрового кода. Во-вторых, большинство данных записывалось в файлы формата Generic File. Этот файловый формат с тегами позволяет добавлять и удалять поля, не уничтожая оригинальных файлов. Благодаря ему старая версия игры могла читать новые версии файлов, созданные редактором. Сравним эту ситуацию с двунаправленной взаимосвязью клиента и сервера. Ширина пропускной линии играла здесь решающую роль, поэтому приходилось побитно упаковывать пересылаемые форматы файлов. Любые изменения сервера или клиента полностью нарушали систему, пока не обновлялись оба компонента.

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

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

Выпуск редактора

Вдобавок ко всему вышесказанному, разработку редактора Neverwinter Nights тоже сопровождало множество трудностей. Мы быстро осознали, насколько сложно создать полноценный редактор ролевых игр, доступный для широкой аудитории. В то время как для Baldur’s Gate редактор разрабатывал один программист, над Neverwinter трудились семеро, и мы всё равно выпустили некоторые дополнительные инструменты, такие как мастер сюжета, уже после выхода основного редактора.

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

Мы рассчитывали на большое количество изменений интерфейса, поэтому решили программировать редактор в среде быстрой разработки приложений. Так как мы хотели использовать один и тот же исходный код для игры и редактора, выбор ограничился средой с поддержкой С/С++. Мы остановились на Borland’s C++ Builder. Эта программа оказалась замечательным инструментом для создания редактора, хотя и не обладала полной совместимостью со средой разработки игры, Microsoft Visual C++.

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

Огромной проблемой стало добавление последних правок. График разработки редактора позволял беспрепятственно трудиться максимальному количеству дизайнеров, потому что они старались уложиться в самые жёсткие временные рамки. Если кто-нибудь из дизайнеров не мог продолжать работу из-за возникающей ошибки или отсутствия необходимых функций, сразу же выходила исправленная версия редактора. Ничто не могло воспрепятствовать этому плану — залатать дыры, и снова вперёд на всех парусах!

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

В руководстве для игрока написано…

Мы достаточно открыто общались с сообществом игроков от лица BioWare, к тому же, использование лицензированного набора правил от популярной настольной игры (в частности, Dungeon & Dragons) привлекло внимание толпы фанатов. Однако, это накладывает дополнительные требования к реализации игры. Например, если мы не реализовали непонятное нам исключение, которое может быть упомянуто в описании той или иной способности, знатоки правил (как в компании, так и со стороны) обязательно укажут на это и другие ошибки подобного рода, до того, как игра окажется на прилавках.

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

Художественное оформление

Как и дизайнеры, художники работали в жёстких временных рамках. Neverwinter Nights обладала сомнительным преимуществом над другими проектами, будучи одновременно полноценной ролевой игрой и редактором по созданию ролевых игр. Только единицы из игроков способны самостоятельно создавать трёхмерные объекты, поэтому возникла необходимость составить как можно более полный набор элементов оформления. Естественно, мы никаким образом не могли воспроизвести всё разнообразие монстров, персонажей и местностей, сформировавшееся за двадцать пять лет творчества фанатов Dungeons & Dragons, но мы стремились предоставить пользователям внушительный набор образцов. На его создание у художников ушло полных три года. Возникла только одна сложность — параллельно в течение двух лет мы программировали графический движок. Чтобы быстрее подключить художников к работе, мы, как могли, определили ограничения к графическому оформлению и соглашались на определённые упущения в создании игровых объектов, когда движок уже был готов. Мы снова жертвовали качеством, чтобы уложиться в сроки.

Спросив нескольких дизайнеров, работавших над нашим следующим проектом, как бы они оценили его по сравнению с Neverwinter Nights, мы получили единогласный ответ: «Он намного легче! Нам не приходится учитывать систему репутации NWN!» Нас это сильно удивило — почему система репутации оказалась не в чести у всех разработчиков?

Подробное описание системы репутации NWN уже есть в сети [Brockington03], но мы попробуем вкратце объяснить, почему она вызвала такую ненависть масс. Каждый персонаж в игре принадлежит к определённой фракции, и каждая фракция обладает набором стандартных реакций на другие фракции в игре. Реакции фракций могут изменяться согласно стандартным механикам (например, в результате помощи представителю фракции или нападения на него). Каждый игровой персонаж (PC) относится к определённой фракции, поэтому все неигровые персонажи (NPC) по-разному относятся к нему. Мы начали с четырёх фракций — простолюдины, торговцы, защитники и монстры, — позволив дизайнерам добавить сколько угодно дополнительных фракций.

Начнём с двухчасовых миссий. Дизайнеры хотели, чтобы все монстры вели себя по-разному. Например, чтобы монстр вёл себя дружелюбно по отношению к игроку и нападал только по окончании диалога. Следовательно, все монстры подразделяются на фракции. Животные должны действовать независимо друг от друга, поэтому, например, олени и коровы относятся к разным фракциям. Вдобавок, сюжетные существа образуют свои собственные фракции. В результате, в каждой двухчасовой миссии присутствовало приблизительно 20 фракций, за которыми необходимо следить, и устанавливать им соответствующее поведение. А это значит, надо создать 380 различных «реакций», или, как минимум, 190, если возможно использовать парные действия. Пока что всё выглядит не слишком страшно.

Затем все двухчасовые миссии объединили в части. Большинство фракций не совместимы друг с другом, поэтому в четырёх двухчасовых миссиях оказалось 80 фракций. Вместо того, чтобы ввести 190 реакций, дизайнеру модуля пришлось реализовать 3 160 реакций и следить за ними. Под конец разработки Часть 2 (самая большая) включала более 180 фракций (для тех, кто продолжает вести счёт, это 42 000 индивидуальных реакций или 21 000, если допустимы парные действия). Только на их загрузку и анализ в старом формате общего файла требовалось 3 секунды и 2 мегабайта на сохранение. Мы изменили формат файла, чтобы убыстрить процесс, но конвертация прошла не так гладко, как планировалось — часть данных пропала. Дизайнеры получили задание: подтвердить наличие 21 000 реакций.

Итак, у нас на руках оказалось 180 различных фракций, которые, в тот или иной момент, могут быть враждебны игроку. Вдобавок каждая из этих фракций может быть враждебна любой другой из оставшихся 179 фракций. Это привело к одной из самых популярных ошибок системы репутации: исчезающим оркам. Помещаем орков в редактор Aurora, дизайнер модуля начинает играть, проверяя баланс части. К тому времени, как он добирается до местности с орками, на земле остаются только сокровища, а монстров и след простыл. Сначала во всём обвинили ИИ — будто бы существа сбрасывают свои сокровища и убегают согласно своему сценарию. Дальнейшее исследование показало, что ситуация несколько сложнее. В то время как орк мирно «бродит» по своей местности, из леса неподалёку постоянно выбегает олень. Увидев добычу, орк решает позавтракать на скорую руку. Всё бы хорошо, но только олени теперь настроены против орков. При их встрече система репутации диктует оленю «перед тобой враг», и он бежит сломя голову на противника. Орк радостно думает: «Отлично! Оленье рагу №2 на подходе!» и бьётся с рогатым. И так продолжается без конца. К сожалению, орк не умеет бесконечно подлечивать себя. Справившись с двадцатью пятью оленями, он падает замертво от полученных ранений. В довершение этой трагичной истории местность уничтожает бездействующего оленя, чтобы он не пасся на ресурсах ЦП. Поэтому, когда игрок наконец приходит, он видит только лежащее на земле сокровище и никаких следов павшего орка или победившего его оленя!

Ещё одна интересная ошибка возникает, когда представители одной фракции населяют несколько местностей. Допустим орки и олени мирно соседствуют по всему игровому миру. При этом орки ненавидят игровых персонажей. И вот в одной битве орк насылает на игрока заклятие, которое попутно убивает пасшегося неподалёку оленя. Конец мирной жизни, теперь олени и орки заклятые враги. В этот же момент на противоположном конце света олень опускает рога и бросается на первого попавшегося ему орка. Бедный орк не понимает, что происходит… и внезапно идиллическая сцена превращается в поле боя, усеянное трупами орков и оленей. Поэтому большинство фракций, населявших несколько территорий, дополнительно разделялись по месту обитания, чтобы предотвратить неадекватное поведение. А это значит, снова требовалось добавить и проверить новые параметры!

Каждое изменение системы репутации оказывало глобальное воздействие на игровой процесс. Разве можно было подозревать, что изменение ИИ напарников заставит оленей и орков воевать друг с другом? А ведь так и вышло…

Каждый раз, когда дизайнеры вносили изменения в систему репутации, им приходилось заново проверять 21 000 реакций, тестировать все местности и удерживать фракции на достаточном расстоянии друг от друга, чтобы они не устроили кровавый хаос (Монтекки и Капулетти хотя бы разделяла стена)… нетрудно догадаться, почему систему репутации все возненавидели.

Давайте добавим ещё одну ОС!

Приступая к проекту, мы решили реализовать игру на четырёх разных платформах: PC, Macintosh, Linux и BeOS. Теоретически это было возможно, потому что нам удалось отделить машинно-зависимые библиотеки от независимых. Казалось, мы учли всё. Один программист следил за развитием проекта и говорил, как необходимо реализовывать последнюю версию игры на каждой платформе. Запуск базы данных на трёх различных компиляторах с предустановленными настройками (CodeWarrior, Visual C 6 и gcc) позволил избежать многих критических ошибок.

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

Наконец, у нас возникли проблемы с редактором. Мы программировали редактор Aurora в Borland C++ Builder, основываясь на слухах, что существуют версии Builder для Linux и Macintosh. В последствии, весь процесс разработки превратился в сплошное мучение. C++ Builder показывал исключения с плавающей запятой посреди работы графического движка, а они не возникали при прогоне той же библиотеки через Visual C. Мы не могли связать графическую библиотеку с Builder без обращения к DLL, поэтому пришлось обеспечить работу дерева исходного кода графической библиотеки на C++ Builder. Версия Builder для Macintosh растворилась в тумане, и мы остались при своём интересе.

Код сервера изначально пытался изолировать некоторые правила в классах, которые мог использовать Builder, но делу помешал игровой код. В начале разработки мы приняли решение не включать набор правил D&D, основу игры, в редактор Aurora. После этого код игры наводнил компоненты правил, как покупатели гипермаркет накануне Нового Года. Когда стало ясно, что идея ограничения использования правил провалилась, нам оставалось только включить весь сервер в редактор Aurora. Сейчас мы дублируем код правил в C++ Builder и Visual C для всех важных компонентов. Также мы ищем альтернативы C++ Builder для будущих проектов.

Когда подошёл срок выхода игры, мы бросили все силы на завершение клиента и сервера на ОС Windows, отложив все остальные версии. Нам хватило ресурсов, чтобы подготовить автономный Linux сервер к официальному появлению игры на прилавках, но создание клиентов под Mac и Linux заняло ещё полгода, сейчас они находятся на финальной стадии разработки (на момент написания статьи).

Заключение

В июне 2002 года наш издатель сообщил, что версия Neverwinter Nights для Windows (на английском, немецком и корейском языках) вышла на рынок, увенчав три с половиной года тяжких трудов. Нам не только удалось выпустить игру в срок, не разорив при этом компанию, но и провести успешную рекламную кампанию. Мы с гордостью предоставили фанатам D&D полноценную однопользовательскую игру и достаточно стабильную многопользовательскую систему для прохождения той же истории в компании при участии или отсутствии Ведущего. А с помощью нашего редактора только в первые шесть месяцев после выхода игры было создано 2 000 модулей.

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

Надеемся, вы смогли многое подчерпнуть для себя из нашего описания сложного процесса создания Neverwinter Nights.

Перевод: Никита Осколков

При поддержке наших вкладчиков на

Поддержать C.O.R.E. на Patreon


Обсудить статью на форуме

Обновления форума

Копирайты

  • C.O.R.E. © 2009 – 2016
Система Orphus Creative Commons License
Войти на сайт?
Логин:
Пароль: