Build

Build — видеоигровой графический движок, используемый в играх жанра «Шутер с видом от первого лица». Является так называемым «псевдотрехмерным», или 2,5D-движком, то есть обеспечивает визуализацию картинки путём развёртывания двухмерной карты в двухточечной проекции графики. Build является самым технически совершенным 2,5D-движком: его возможности превосходят более старые графические движки от id Software (Wolf3D и Doom), в особенности в плане поддержки третьего измерения: в Build можно разместить один сектор над или под другим, а спрайтовые объекты могут перемещаться в 3D один над другим на произвольной высоте, не сталкиваясь, поэтому некоторые называли Build 2,75D-движком.

Загрузить видео YouTube YouTube might collect personal data. Политика конфиденциальности ПродолжитьDismiss (link) Краткая история версий Build

Сравнение с движком Doom

Несмотря на общее сходство самого концепта (оба движка реализуют псевдо-3D уровни из секторов), в целом движок Build является большим шагом вперёд: например, в нём появилась возможность делать полы и потолки секторов наклонными, а также добавлять анимированные декали, что позволило сильно оживить мир. Правда, вычислительных ресурсов это тоже требовало (относительно) некислых, так что Duke Nukem 3D, в отличие от Doom, на любом тостере не запустишь. Впрочем, подросшая за это время производительность процессоров избавила разработчиков Build от необходимости идти на крайние меры ради повышения производительности.

	Id Tech 1	Build
Автор	Джон Кармак (id Software)	Кен Сильверман (инди → 3D Realms)
Язык программирования	Написан на С, игровая логика пишется на нём же. В Hexen часть логики уровня может писаться специальным байт-кодом BEHAVIOR, реконструирован хакерами.	Написан на C, но изрядная часть игровой логики записана во внешних скриптах с расширением CON. Кроме того, с клиентами Сильверман исходниками не делился, отправляя им только собранные OBJ-файлы.
Системные требования	Для картинки 320×200 — старшие модели Intel 80356, 4 МБ оперативной памяти, что гораздо лучше Build. Современная версия с переменным разрешением экрана — Pentium Pro и 32 МБ оперативной памяти, что уже гораздо хуже.	Для картинки 320×200 — младшие модели Intel 80486, 8 МБ оперативной памяти. Для 640×480 — Pentium 133. В отличие от DOOM, поддержка видеодрайвером VESA 2.0 желательна, но не обязательна.
Графика	256-цветная; разрешение картинки изначально жёстко фиксированное 320×200, переделка потребовала много работы как над отрисовкой, так и над интерфейсом.	256-цветная, переменного разрешения. Были глюки с высокими разрешениями, но в современных версиях движка они большей частью закрыты.
Камера	В первой версии обзора вверх-вниз не было, позже — в двухточечной проекции (не полноценное 3D). Несмотря на это, трёхмерная физика стрельбы была всегда.	Обзор вверх-вниз в двухточечной проекции. В современных версиях — полноценное 3D.
Звук	Сложный звук со стерео и приоритетом одних звуков над другими. Реализован через внешнюю библиотеку — DMX в оригинале и Allegro в большинстве DOS-портов.	Сложный звук со стерео и приоритетом одних звуков над другими.
Геометрия уровня	Полы и потолки строго горизонтальные, стены строго вертикальные.	Полы и потолки могут быть наклонными, стены всё так же вертикальные.
	Многоэтажности нет (секторы не могут пересекаться из-за ограничений алгоритма отрисовки).	Есть зачатки многоэтажности — секторы могут быть расположены друг над другом, если они не видны оба сразу. Кроме того, потолок одного сектора может служить полом другого — в Duke Nukem 3D так реализованы лифты, трубы, подводный мир.
	Динамически может меняться только высота пола или потолка — именно поэтому в Doom двери открываются вверх. В Hexen добавили поддержку полиобъектов, которые могут ограниченно двигаться по горизонтали.	Поддерживается динамическое изменение высоты пола и потолка, а также произвольное движение сектора внутри другого, лишь бы пересечений не было — это позволило реализовать распахивающиеся двери, горизонтальные лифты, огромные крутящиеся шестерни из полов/потолков и даже подобие машинок.
	Разнообразные и красивые секторные эффекты: сектор может утонуть в лаве (или, наоборот, подняться из лавы), могут построиться ступеньки.	Здесь тоже много разных секторных эффектов, есть такие, которые невозможны в Doom (например, сектор, перемещающийся внутри другого сектора по заданному маршруту или даже по управлению с клавиатуры игрока)
	Масштаб текстур постоянный. Поворот текстур пола/потолка невозможен; в Heretic и Hexen реализовали сдвиг. С текстурами стен всё значительно свободнее.	Поддерживается переменный масштаб текстур: например, на менее детальной стене можно расположить детализированный плакат.
	—	Как развитие предыдущего пункта — поддерживаются декали на стенах, в том числе динамически появляющиеся. Через них можно реализовать, помимо прочего, следы крови и пуль на стенах; в Doom их нет.
Объекты	Спрайты, для каждого объекта задаются 1 или 8 поворотов.	Спрайты, для каждого объекта задаются 1 или 5 поворотов (остальные три — симметрично отражённые версии).
	Поддерживается перемещение по всем трём осям. Хитбокс каждого — параллелепипед со сторонами, параллельными осям X/Y/Z. В Doom в некоторых ситуациях хитбокс имеет бесконечную высоту.	Поддерживается перемещение по всем трём осям.
	Полупрозрачность реализована с помощью специальных цветовых таблиц, в которых записано, как будет выглядеть объект один цвет за полупрозрачным объектом другого цвета. Для нескольких уровней прозрачности нужно несколько таблиц — в некоторых портах Doom их число доходило до 5.
Освещение	Постоянное для каждого сектора. Чтобы сделать световое пятно, нужно создать несколько вложенных друг в друга секторов.
Рендеринг	Программный, от ближних секторов к дальним, с помощью двоичного разбиения пространства. Одновременно находит видимые объекты и рисует 64 ближайших от дальних к ближним. Это требует предварительной обработки перед построением геометрии, что делает редактирование в визуальном режиме (WYSIWYG, сделал изменение — сразу увидел результат) невозможным.	Программный, от ближних к дальним, с помощью порталов. Поэтому редактор там WYSIWYG, и одна стена — это всегда одна стена и никогда не разбивается на части (но дважды, трижды и т. д. рисуется, если смотрим на неё из-за колонны). В современных версиях движка есть поддержка аппаратного рендера через OpenGL.
Скорость игры	35 тактов в секунду (половина штатной частоты VGA). В портах для приставок пришлось снижать до 30 и пересчитывать скорости.	30 тактов в секунду.
Редактор уровней	Множество сторонних редакторов уровней, в том числе крайне дружественных пользователю.	Единственный и жутко неудобный редактор уровней — несмотря на этот самый WYSIWYG.
Лицензия	Изначально коммерческая, ныне — GNU GPL v2

История

Build появился на свет как результат трудов юного (на момент создания прототипа ему было всего 17 лет) американского программиста по имени Кен Сильверман. В 1992 году под впечатлением от Wolfenstein 3D он решил попробовать создать свою игру и написать для неё собственный графический движок. В июне того же года он закончил работу над прототипом, названным Walken (Walk+Ken). Осенью 1992 он значительно переработал игру, получившую новое название Ken’s Labyrinth, и по совету отца предложил эту игру всем фирмам-издателям программного обеспечения в Соединённых Штатах. Распространял он её сперва сам, затем «Лабиринтом Кена» заинтересовалась компания Epic MegaGames, которая и стала её издателем. Уже в этом продукте видны черты будущего Build: на обширных игровых уровнях встречается много анимированных и интерактивных объектов —— в частности, игровые автоматы, из которых можно выбивать случайные полезные предметы в обмен на собранные монеты и питьевые фонтанчики для восстановления здоровья.

Спустя несколько месяцев Сильверман подписал контракт с фирмой Apogee Software на разработку нового графического движка для видеоигры-шутера с видом от первого лица. Новейшее на тот момент детище Джона Кармака, Doom engine, компания id Software не планировала продавать для использования сторонними разработчиками, а потому свой графический движок Apogee был очень нужен. Впрочем, без участия автора Wolf3D всё равно не обошлось — по воспоминаниям самого Кена, именно телефонный разговор с Кармаком помог ему прийти к идее визуализации по секторам, после чего движок был переписан почти полностью.

Название движка появилось почти случайно: во время демонстрации в июне 1993 года прототипа движка Сильвермана спросили, как называется его движок. Кен до того никакого особенного названия не придумал, а потому предложил название исполняемого файла, который и запускал прототип движка — build.exe. Так и порешили.

Разработка Build шла с середины 1993 по декабрь 1995 года: ключевую часть работы по написанию движка выполнил именно Кен Сильверман, но ему также помогали программисты Apogee Тодд Реплогл, Аллен Блум, Джим Доуз и Марк Доктерманн.

Возможности

Исходный файл, который Build визуализирует, представляет собой двухмерную карту, состоящую из многоугольников-секторов. Каждый сектор имеет базовую форму в виде двухмерной фигуры, а также заданные для него трёхмерные свойства — высоту потолка, наклон пола, и так далее. Именно так реализовывается базовая геометрия уровня: полы, потолки, стены и колонны.

Такая структура имела и свои ограничения.

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

Во-вторых, таким образом нельзя сделать наклонный столб или стержень, торчащий из земли: любая поверхность, отличная от вертикальной, в Build реализовывается с помощью наклонных полов и потолков.

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

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

Технические подробности

Движок получился таким удачным из-за хорошей технологии визуализации. Движок Doom, к примеру, разбивал стены на части (т. н. «отрезки», SEGS); Build действовал по-другому. Он просто рисовал секторы, при том отмечая, видна граница секторов или нет. Если видна, то движок рисовал соседний сектор. Самое интересное, что для того, чтобы увидеть уровень в 3D, не нужно никакой предварительной обработки. Так что часть работ выполняется в 3D, в самом настоящем WYSIWYG (то, что интерфейс редактора неудобный — это уже другой вопрос). На словах просто, но есть несколько алгоритмических уловок, с которыми, видимо, Джон Кармак в своё время не справился.

Экономия памяти в id Tech 1 достигалась за счёт сборных текстур, а в Build это убрали; вместо них здесь объекты, прикреплённые к стенам. Так, например, устроены все кнопки.

Что на нём было

Первой игрой на графическом движке Build, если не считать прото-Build в «Валкене» и «Лабиринте Кена», стала выпущенная осенью 1994 года тайваньской конторой Accord Legend of the Seven Paladins 3D. Игра использовала нелицензированную и пожалуй, самую раннюю из доступных версий движка, отличалась запредельной сложностью и множеством багов.

Первыми официальными играми на Build стали две малоизвестные игры от Capstone Software — Witchhaven и William Shatner’s TekWar, выпущенные в 1995 году. Capstone, в отличие от тайваньцев, честно купили лицензию на движок у Apogee. Эти программные продукты использовали ранние версии движка Build, не способные, к примеру, отображать наклон горизонтальных поверхностей (пола или потолка).

Сама же Apogee (в 1996 году переименованная в 3D Realms) использовала Build в играх Duke Nukem 3D и Shadow Warrior, а также достаточно щедро продавала лицензию на его использование другими студиями: помимо вышеупомянутых Capstone Software, движок использовала Monolith Production, выпустившая игру Blood. Следует отметить, что все последующие игры, как правило, использовали не исходный игровой движок, а его модифицированную для Duke Nukem 3D версию. Такой вариант Build использовался в развесёлом стрелялове Redneck Rampage, в небезынтересной PowerSlave (в древнеегипетских декорациях), в пращурах микрожанра «военный шутер» NAM и WWII GI и в меметично ужасном многопользовательском FPS Extreme Paintbrawl.

Всего за пять лет коммерческой эксплуатации на графическом движке Build было выпущено 11 игр, что очень много: прямой его конкурент, полноценный трёхмерный движок Quake Engine за тот же период времени был использован всего в пяти играх. Традиционно из игр на «Билде» этого времени выделяют «Великую Тройку» — три игры, в разработке которых принимал участие сам Кен Сильверман: Duke Nukem 3D, Shadow Warrior и Blood. Эти игры отличаются высоким качеством изготовления и потому лучше всех сохранились в народной памяти. Впрочем, иногда «тройка» расширяется до «четвёрки», с включением в её состав Redneck Rampage, также очень хорошей игры на Build, хотя и с некоторыми огрехами гейм-дизайна. Остальное было или малоизвестно, или просто ужасно.

Дальнейшая судьба Build

Некоторое время спустя, в начале 2000-х, и Сильверман, и компании-разработчики выложили исходный код игрового движка в открытый доступ, что позволило многочисленному моддерскому сообществу начать деятельность по адаптации устаревшего уже Build к современным операционным системам. Из таких работ следует отметить самый первый порт движка Duke Nukem 3D, EDuke, а также JFDuke3D, в работе над которым принимал участие сам Кен Сильверман, сочинив рендерер Polymost для работы с w:OpenGL. В дальнейшем оба этих порта получили развитие в форме EDuke32, наиболее совершенного варианта движка Build на настоящий момент: именно этот порт использует самая последняя коммерческая игра на Build, Ion Fury.

В 2006—2011 Кен Сильверман разработал Build 2, который уже являлся полностью трехмерным движком, обратно совместимым с Build. Однако поезд ушел, войти дважды в одну реку не удалось, и интереса игроделы к этому движку уровня начала 2000-х не проявили. В 2018 году Build 2 был выпущен в открытый доступ — для некоммерческих проектов (с коммерческих проектов Сильверман по прежнему просит деньги за его использование — блажен, кто верует…).

Известные личности, связанные с движком Build

• Кен Сильверман — американский программист, автор движка.
• Ричард «Levelord» Грей — известный дизайнер игровых уровней. Начал свою карьеру и прославился именно как мастер выжимания всего возможного из дубовой геометрии Build.
• Мэтт «Matteus» Сеттлер — автор EDuke. До того работал в Microsoft, а затем в Monolith Production. Был продакт-менеджером Blood и Blood 2; к слову, также занимался локализацией первых «Аллодов» на английский, французский и немецкий языки.
• Джонотон(sic!) «JonoF» Фоулер — автор JFDuke3D. Также сделал Win-XP порт для Shadow Warrior.
• Ричард «TerminX» Гобейлль — автор EDuke32. Работал над портом Duke Nukem 3D: Megaton Edition для 3D Realms и Gearbox, на настоящий момент руководит небольшой компанией-разработчиком Voidpoint, выпустившей Ion Fury.

Примечания

Build входит в серию статей Видеоигры Посетите портал «Видеоигры», чтобы узнать больше.

	[ + ] Игровые движки
Страницы в категории «Игровые движки»  Build, Движок Doom