Позавчера, 4 августа, на irc.pcgnetworks.com #halflife2news состоялась большая конференция с разработчиками самого ожидаемого скивела этого года - HalfLife-2. Со стороны Valve участвовали:
Gabe Newell - Valve's founder and big cheese.
Chris Bokitch - autolycus from VERC.
Yahn Bernier - Software Development Engineer
Gary McTaggart - Software Developer, Engine Programming
Ken Birdwell - Senior Software Development Engineer
David Speyrer - Software Developer
Из их ответов на многочисленные вопросы стали известны следующие интересные факты:
Карты для HalfLife-2 будут по-прежнему основаны на BSP, но возможности значительно расширены. Будет улучшена связка BSP и AI. Теперь разработчики модов могут получить информацию об окружении через множество функций. Это очень важно для построения "географических" алгоритмов AI, например, выбор оружия в зависимости от величины помещения, в котором находится враг, или выбора наиболее безопасного пути отступления. В это верится с трудом, но до сентября осталось не так много времени. Правда оговаривалось, что такую информацию в карту должны заложить мапмейкеры. Помимо этого, для разработчиков модов будет расширен статус функции перемещения объекта по карте, чтобы авторы знали с чем пришлось "столкнуться" боту.
В игре будет практиковаться для программирования окружения и монстров, как скриптование, так и написание специальных алгоритмов. Благодаря алгоритмам боты, например, могут стрелять в бочки с горючим, находящиеся рядом с врагом. А скрипты нужны, чтобы можно было исправлять ляпы "универсальных" алгоритмов или описывать какие-то специальные ситуации, что значительно экономит процессорное время. Скрипты можно писать, не имея исходных текстов мода или игры.
vehicles - транспортные средства. По умолчанию, они в игре могут быть двух типов: "ползающие", т.е. наземные, и летающие, т.е. воздушные, транспортные средства. Однако разработчики модов могут создавать свои типы транспортных средств, например, плавающие или подземные. Для них тоже можно писать скрипты.
Сетевой код. В отличие от Doom-III, Valve предпочла использовать клиент-серверную технологию, немного напоминающую Quake III Arena. Т.е. клиентская часть обменивается с серверной частью системой сообщений и snapshot-ов. Сообщения могут быть, как широковещательные (для всех игроков или объектов), так и только для одного объекта или типа объектов. Например, выстрел из шотгана условно можно разбить на два сообщения одиночное сообщение о попадании тому, в кого попал выстрел, на "групповое" сообщение тем кто этот выстрел слышал. Такое "осложнение" помогает сильно сократить сетевой траффик между сервером и клиентами. Также в игру сразу будет включен lag-compensation код, т.е. предсказание тех событий в игре, которые могут произойти или происходят. Причем это не просто интерполяция позиций игрока, а это большая система предсказаний поведения тех или иных объектов. Предусмотрен также новый специальный режим, который определяет основные ошибки предсказания в сетевом коде, что позволит лучше настроить сетевую часть игры.
Движок игры может использовать пиксельные шейдеры, как версии 1.0, так и 1.1, 1.4 и 2.0, в зависимости от используемого оборудования. Также была исправлена проблема FSAA и MSAA на всех видео-карточках, совместимых с DirectX 8.0, о которой так много было написано в интернете. Для большей совместимости с видеокартами, движок использует для шейдеров язык DirectX HLSL. Другое заметное нововвидение в графический движок - это изминение свойств PVS. Давным-давно, когда Кармак придумал Quake, была реализована такая фишка, что на клиенте "живут" только те объекты, которые видит игрок. Это значительно уменьшило время рендеринга сцены, но увеличило сетевой траффик. Поэтому в современных играх, если вы играете по Интернету и у вас сильные лаги, то когда вы "поворачиваете голову" начинаются тормоза и связаны они не с рендерингом, а с тем что с сервера передаются объекты, которые надо нарисовать. Проще говоря, в современных играх тест на видимость объекта происходит на сервере и видимые объекты передатся клиенту, а невидмые уничтожаются на клиенте. Valve решила не делать этого. Теперь объекты "не умирают" на клиенте, когда пропадают из его поля зрения. Они остаются жить, но не прорисовываются. С точки зрения сетевого трафика это есть гуд, потому что современные процессоры и видео-ускорители могут справиться с очень сложными сценами. Но это очень плохо с точки зрения безопасности, т.е. облегчает создание читов по типу wallhack.
Все графические объекты в игре имеют много уровней детализации, которые используются не только для задания качества графики в игре, но и для рендеринга "далеких" объектов. Помимо этого, карты освещенности (litghmap) также имеют разные разрешения. Максимально возможное разрешение текстур 2048x2048. Для описания звуковых эффектов игра использует тэги(индексы), как в Quake3, вместо символьных имен как в HL1. Для более качественного воспроизведения звука нужна карточка, понимающая DolbySorround 5.1, но по-минимуму достаточно EAX и двух колонок. Вместо WAV файлов игра может использовать MP3 файлы. Сами объекты в игре могут быть иерархичными и иметь триггера. Например, есть триггера для некоторых объектов в игре, которые позволяют "ломать" объекты на неcколько мелких или полностью уничтожать объект. Skybox, та оболочка что "за уровнем", теперь стал частью карты и на нем можно распологать текстурные объекты, которые, например, могут пермещаться или показывать какой-нибудь "мультик" или спецэффект. Для более естественной прорисовки людей и монстров в игре используется система "Half-Life Face Poser".
Демки, расширение vdm Valve Demo Metafile, в игре можно не просто просматривать в разном темпе (timescale), но и делать настояющую паузу, перемотку назад-вперед и перемещение камеры в деме, видео fade in/out и звуковой fade in/out.
Я постарался выделить наиболее интересные и понятные мне данные. Все вопросы относительно редактора уровней, деталей звукового движка, особенностей системы эмуляции работы мускулов людей, конвертации карт и объектов из HalfLife-1 я пропустил.
progamer.ru |
