Build Engine

Сектори — основна складова геометрії рівня. З секторами можна працювати в реальному часі. Їх параметри (висоти, форма, кути нахилу) не вимагають перерахунку при зміні. Це дозволяє робити оточення в грі більш інтерактивним, наприклад, руйнівним, як в грі Blood. Розробники використовували зарезервований спрайт (секторефектори), яким присвоювалися спеціальні верхні (hi-tags) і нижні (lo-tags) теги (числа з певним змістом), які дозволяли робити світ динамічнішим (наприклад, двері, вибухи бочок і т. п.). Такі ж теги можуть бути задані підлозі та стелі сектора для додання особливих властивостей. Наприклад, гравець, що проходить по підлозі зі спеціальними тегами, провалювався вниз і випадав з іншого боку стелі зі спеціальними тегами. На практиці це застосовувалося для створення водойм. Сектору можуть бути присвоєні теги, які перетворюють його в двері або ліфт. Сектори можуть перекривати один одного, якщо в такій ситуації видно одразу два сектори, то з найсильнішими спотвореннями. Це дозволяло створювати, наприклад, вентиляційні шахти, що знаходяться над приміщеннями (правда це значно ускладнювало подальшу роботу з цією частиною рівня, оскільки майже весь час розробник проводить в двомірному режимі). Також це дозволяє створювати неможливі з точки зору фізики, світи (наприклад, система приміщень в будівлі, яка більше самої будівлі). Всі ці ефекти робили світ схожим на тривимірний.

Для сортування площин в 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.
• Нарешті, в портальному рушії попередні обчислення мінімальні — а значить, користувач може редагувати рівень в тривимірному режимі.

Пізніші версії рушію дозволяли замінювати зображення в грі на тривимірні об'єкти, зроблені з вокселів. Ця можливість з'явилася надто пізно для того, щоб використовувати її в Duke Nukem 3D, але була використана в інших іграх. Blood використовує воксели для зброї, патронів, поліпшень, і різних прикрас (таких як надгробки на рівні Cradle to Grave).

Кілька років Кен працював над рушієм Voxlap, який бере за основу воксельні технології.

Деякі ігри на рушії Build engine використовували трюк з об'єднанням підлоги та стелі у двох секторів. Створення таких конструкцій під час редагування рівня було ускладнене, тому часто сектора переміщалися під час завантаження рівня (що спрощувало розрахунки, що виконуються рушієм для відтворення). Технологія кімната-над-кімнатою застосовувалася в Shadow Warrior (зсув секторів під час завантаження карти) та Blood (без зміщення). Сама технологія не була закладена в рушій, до неї додумались творці рівнів.

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

Райан Гордій (icculus) зі сторонньою допомогою створив перший порт рушія з використанням SDL. Спочатку це був порт для Linux, після для Cygwin і ще пізніше для чистого Windows API (при складанні використовувався компілятор Watcom C++, який використовувався і для оригінальної DOS збірки (з точністю до того, що для Windows використовувався Watcom C++, а Build написаний на звичайному C). Йшли чутки про портуванні EDuke на Windows, але нічого не відбулося.

Другий порт на Windows та пізніше, на Linux від Джонатана Фаулера (JonoF). На відміну від icculus порту, цей порт використовує DirectDraw замість SDL на Windows та працює значно швидше. Довгий час рушій не підтримував багатокористувацькі ігри, потім з'явилася підтримка мультиплеєра тільки для двох гравців.

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

Коли 3D Realms опублікували сирцеві коди Duke Nukem 3D, я думав, хто-небудь зробить OpenGL-або DirectX-порт. Через кілька місяців я зрозумів, що ніхто не працює над використанням цього апаратного прискорення в 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 рік цей порт перебуває ще на стадії ранньої розробки. Існує ще недороблений порт Blood TC.

Вихідні коди Shadow Warrior були опубліковані 1 квітня 2005 року, і JonoF опублікував порт на гру 2 квітня 2005 року. Правда, він стверджує, що мав доступ до вихідного коду Shadow Warrior за тиждень до їх публікації.

Вихідні коди Witchaven, Witchaven II, Tekwar та Corridor 8 були також опубліковані. Правда, під питанням знаходиться легальність їх публікації.