Build Engine

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Build Engine
Рушій гри (Список)
Ключовий програмістКен Сільверман
Підтримувана ОСDOS
Ліцензіякод від автора — під власницької BUILDLIC.TXT[1]
http://advsys.net/ken/build.htm

Build Engine — це рушій гри для шутерів від першої особи, створений Кеном Сільверманом для 3D Realms. Як і в грі Doom, рушій Build Engine проєктує ігровий світ на двомірну сітку з замкнутих фігур на площині, званих секторами, і використовує найпростіші плоскі об'єкти — спрайт, для заселення геометричного світу об'єктами.

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

Технічні характеристики

[ред. | ред. код]

Сектори

[ред. | ред. код]

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

Портали

[ред. | ред. код]

Для сортування площин в Z-порядку[en] рушій 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[en] використовує воксели для зброї, патронів, поліпшень, і різних прикрас (таких як надгробки на рівні 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 і ще пізніше для чистого Windows API (при складанні використовувався компілятор Watcom C++[en], який використовувався і для оригінальної 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-або 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[en] та WWII GI[en], що, можливо, спростило розробку. Також була спроба відтворити Blood на рушії DarkPlaces та назвати Transfusion, але на 2006 рік цей порт перебуває ще на стадії ранньої розробки. Існує ще недороблений порт Blood TC [Архівовано 14 квітня 2012 у Wayback Machine.].

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

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

Список ігор на рушії Build Engine

[ред. | ред. код]

Примітки

[ред. | ред. код]
  1. ↑ Ліцензія на сайті icculus.org
  2. ↑ Clint Basinger[en] [@lazygamereviews] (11 червня 2017). As a result, Legends of the Seven Paladins (illegally) became the first Build Engine game, using code they didn't have the rights to (Твіт). Процитовано 16 вересня 2022 — через Твіттер.
  3. ↑ TWIM. A History of Korean Gaming. Hardcore Gaming 101. Процитовано 1 липня 2017.

Посилання

[ред. | ред. код]
Отримано з https://uk.wikipedia.org/w/index.php?title=Build_Engine&oldid=40821220