[Neverwinter Nights] Проблемы разработки сетевой игры

Пользовательское наполнение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наконец, требовалось сократить трафик во время игры, так как в 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) привлекло внимание толпы фанатов. И это накладывало определённый отпечаток на разработку. Например, если в игру не включили какое-то малопонятное исключение из настольных правил, знатоки (как в компании, так и со стороны) указывали на эту и другие ошибки до завершения разработки.

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

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

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

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

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

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

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

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

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

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

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

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

Приступая к проекту, мы решили выпустить игру на четырёх платформах: ПК, 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. ▲