Build Engine

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск
Build Engine
Тип

Игровой движок

Разработчик

Кен Сильверман

Операционная система

DOS

Аппаратная платформа

MS-DOS

Последняя версия
Лицензия

код от автора — под собственнической BUILDLIC.TXT[1]

Сайт

advsys.net/ken/build.htm

Build Engine — это игровой движок шутера от первого лица, созданный Кеном Сильверманом для 3D Realms. Как и в игре Doom, движок Build Engine проецирует игровой мир на двухмерную сетку из замкнутых фигур на плоскости, называемых секторами, и использует простейшие плоские объекты, называемые спрайты, для населения геометрического мира объектами.

Build Engine относится к классу так называемых «2,5-мерных движков», потому как в основе игрового мира лежит плоскость с добавленной компонентой высоты. Каждый сектор может иметь разную высоту пола и потолка, а также разный наклон пола и потолка. В результате рендеринга мир выглядит трёхмерным. Обсчёт перспективы основывается только на горизонтальном расстоянии — поэтому вертикальные линии, соответствующие вершинам, строго вертикальны вне зависимости от угла зрения. Это вызывает значительные искажения перспективы при взгляде вверх или вниз на большие углы в большинстве игр на движке Build.

Технические характеристики[править | править исходный текст]

Сектора[править | править исходный текст]

Сектора — основная составляющая геометрии уровня. С секторами можно работать в реальном времени. Их параметры (высоты, форма, углы наклона) не требуют пересчета при изменении. Это позволяет делать окружение в игре более интерактивным, например разрушаемым (как в Blood).

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

Порталы[править | править исходный текст]

Для сортировки плоскостей в Z-порядке Doom использовал BSP-дерево, строившееся каждый раз при сохранении WAD’а. В отличие от Doom, Build использовал механизм порталов.

Отрезки, разделяющие два сектора, объявляются «порталами». Движок сначала рисует сектор, в котором находится зритель, запоминая все порталы. После этого он рекурсивно запускает рендеринг секторов, которые видны сквозь порталы (не трогая того, что уже нарисовано).

В 2,5-мерном движке этот метод оказался лучше BSP-дерева по таким причинам:

  • Сектора можно двигать и вращать. Пускай это движение очень ограниченно (движение возможно только в пределах одного сектора) — даже это прогресс по сравнению с Doom’ом. Что привело к очень «живому» миру — горизонтальные «лифты» (повсеместно во 2 части Duke Nukem 3D — Lunar Apocalypse), вагон метро (Duke Nukem 3D — уровень Rabid Transit), разрушаемые объекты (Blood) и т. д.
  • Doom разбивает стены (linedefs) на сегменты (segs). Портальный движок никогда не делит стены на части — что приводит к более высокой скорости рендеринга на сложных сценах. К тому же, сложность невидимых частей уровня никоим образом не влияет на производительность рендерера. На машинах класса Pentium-100 можно свободно запускать Duke Nukem 3D в разрешении 640×480 — ни один порт Doom’а на такое не способен.
  • Наконец, в портальном движке предварительные вычисления минимальны — а значит, пользователь может редактировать уровень в трёхмерном режиме.

Воксели[править | править исходный текст]

Поздние версии движка позволяли заменять изображения в игре на трёхмерные объекты, сделанные из вокселей. Эта возможность появилась слишком поздно для того, чтобы использовать её в Duke Nukem 3D, но была использована в других играх. Blood использует воксели для оружия, патронов, улучшений, и различных украшений (таких как надгробия на уровне Cradle to Grave).

Несколько лет Кен работал над движком Voxlap, берущим за основу воксельную технологию.

Комната над комнатой[править | править исходный текст]

Некоторые игры на движке Build engine использовали трюк с объединением пола и потолка у двух секторов. Создание таких конструкций во время редактирования уровня было затруднено, поэтому часто сектора перемещались во время загрузки уровня (что упрощало расчёты, выполняемые движком для отрисовки). Технология комната-над-комнатой применялась в Shadow Warrior (смещение секторов во время загрузки карты) и Blood (без смещения). Сама технология не была заложена в движок, до неё додумались создатели уровней.

Дальнейшее развитие[править | править исходный текст]

20 июня 2000 года Кен Сильверман открыл исходные коды движка Build Engine.

Версия 2.0 (первый и единственный официальный релиз) EDuke от Мэтта Сетлера (порт для запуска Duke Nukem 3D под современными операционными системами) был отослан в 3D Realms (исходники Duke Nukem 3D и EDuke были по-прежнему в закрытом доступе). Работая с бета-версией 2.1, Мэтт пытался встроить исходники Build в исходники Duke, но проект был закрыт, прежде чем появились отлаженные публичные версии. Несколько команд, занимавшихся тотальной конверсией игр на Build, решили работать прямо с исходниками Build Engine Кена, а не исходниками Duke. Позже, в результате работы появился редактор mapster. Долгое время портирование движка Build на многозадачные операционные системы было затруднено из-за необходимости очень больших участков памяти компьютера, которых не было в многозадачных ОС. Проблема решалась подключением виртуальной памяти.

Исходные коды Duke Nukem 3D[править | править исходный текст]

1 апреля 2003 года 3D Realms опубликовали исходные коды движка Duke Nukem 3D, несмотря на то что на протяжении длительного времени утверждали, что этого никогда не случится. После этого очень скоро появились порты Icculus и JonoF. Стало возможно без проблем играть в Duke Nukem 3D на GNU/Linux, Windows NT и других платформах, и интерес к портам усилился.

Порт icculus.org[править | править исходный текст]

Райан Горден (icculus) с посторонней помощью создал первый порт движка с использованием SDL. Изначально это был порт для Linux, после для Cygwin и ещё позднее для чистого Win32 (при сборке использовался компилятор Watcom C++, который использовался и для оригинальной DOS сборки (с точностью до того, что для Windows использовался Watcom C++, а Build написан на обычном C). Шли слухи о портировании EDuke на Windows, но ничего не произошло.

Порт JonoF[править | править исходный текст]

Второй порт на Windows и позднее, на Linux от Джонатана Фаулера (JonoF). В отличие от icculus порта, этот порт использует DirectDraw вместо SDL на Windows и работает значительно быстрее. Долгое время движок не поддерживал мультиплеер, потом появилась поддержка мультиплеера только для двух игроков.

Система Polymost (Полимост)[править | править исходный текст]

Автор движка взялся за задачу обновления Build Engine до полноценного трёхмерного движка. В примечаниях к релизу JFDuke3D Сильверман пишет:

Когда 3D Realms опубликовали исходные коды Duke Nukem 3D, я думал, кто-нибудь сделает OpenGL- или Direct3D-порт. Через несколько месяцев я понял, что никто не работает над использованием настоящего аппаратного ускорения в Build, люди просто говорят, что это невозможно. Позже я осознал, что единственный способ чего-либо добиться, — это сделать всё самому.

Система отрисовки полимост использует OpenGL для аппаратного 3D ускорения. Также введена технология хайтайл (hightile), позволяющая заменять стандартные игровые ресурсы более качественными в различных форматах.

Полимост был использован в JFBuild от Джонатана Флауера, JFDuke3D, JFSW, и других портов основанных на этой кодовой базе.

Другие порты[править | править исходный текст]

Публикация исходных кодов EDuke 2.0 позволила добавить к EDuke возможности порта JonoF и движка Build Engine 2.1, вскоре появился EDuke32, но на сегодняшний день в разработке находится только EDuke.

Исходник последней личной бета-версии EDuke 2.1 (которая никогда не была доведена до релиза) был также опубликован после исходных кодов EDuke 2.0. Также появился порт, основанный на Icculus, имеющий кодовое название wineduke, разработка которого на сегодняшний день не ведётся.

EDuke содержал элементы исходных кодов Nam и WW2 GI, что, возможно, упростило разработку. Также была попытка воссоздать Blood на движке DarkPlaces и назвать Transfusion, но на 2006 год этот порт находится ещё на стадии ранней разработки.

Исходные коды Shadow Warrior были опубликованы 1 апреля 2005 года, и JonoF опубликовал порт на игру 2 апреля 2005 года. Правда, он утверждает, что имел доступ к исходным кодам Shadow Warrior за неделю до их публикации.

Исходные коды Witchaven, Witchaven II, Tekwar и Corridor 8 были также опубликованы. Правда, под вопросом [источник не указан 1295 дней] находится легальность их публикации.

Список игр на движке Build Engine[править | править исходный текст]

Примечания[править | править исходный текст]

Ссылки[править | править исходный текст]