Новый день. Новое интервью. Новые 30 вопросов.
---
Краткая справка об основных действующих лицах:
Фото взято с домашней страницы интервьюируемого.
Кен Сильверман (Ken Silverman) – создатель игрового движка Build, а также ряда других технических решений вроде VOXLAP, на основе которых были созданы игры в диапазоне от Duke Nukem 3D (1996, DOS) и Blood (1997, DOS) до Ion Fury (2019), а также Electric Highways (2015) и Voxelstein 3D (2008, Windows). Домашняя страничка Кена – Ken Silverman's Official Home Page.
Над улучшенной версией перевода работали:
@WERTA - помогал в вопросе стилистической составляющей материала.
Вносили различные корректировки и обновления @Dimouse, @A National Acrobat, @Virgil и @kreol.
---
English text of the interview.
---
Вопрос. Что вдохновило вас на создание игрового движка Build? И касательно вашего участия в разработке игр - возможно, вы могли бы упомянуть несколько интересных фактов?
Ответ. Конечно, это был DOOM (1993, DOS). id Software стали публиковать первые скриншоты и информацию об их следующей игре почти тогда же, когда я завершил работу над Ken's Labyrinth (1993, DOS), то есть в начале 1993 года. Очевидно, я не мог пройти мимо, поскольку до этого почти год потратил на копирование Wolfenstein 3D (1992, DOS). Ваш второй вопрос слишком обобщённый. У нас же целое интервью, может быть, почитаем его?
---
taufan99 спрашивает: "С тех пор как я сыграл в Ken's Labyrinth и другие ваши шутеры, я влюбился в формат KSM. Однако я хотел бы узнать: можете ли вы выпустить конвертер для формата General MIDI, поскольку, хоть я и понимаю, что AdLib – хорошая звуковая карта, я сам больше являюсь поклонником General MIDI".
Ответ. Если вы хотите что-то немного отредактировать, вы можете использовать мою программу KS2.EXE для преобразования этих музыкальных форматов. Ищите её на моей домашней страничке в разделе утилит. Вам придётся вручную выбрать MIDI-инструменты и полностью переделать трек с перкуссией при помощи инструмента "Лассо". При некоторой настойчивости можно будет добиться хороших результатов. Да, КС2 давно не обновлялся и в современных версиях Windows имеет свойство мерцать. Я мог бы это исправить, если бы у меня было достаточно желания и времени.
---
vyruss спрашивает: "Что во время экспериментального этапа разработки движка Build привело вас к окончательному решению использовать именно порталы, а не другие технологии того времени? Я знаю о преимуществах порталов по сравнению с другими технологиями рендеринга того периода, а также знаю об ограничениях распространённого в то время оборудования у пользователей; был ли проведён расширенный анализ различных подходов для оценки их сильных и слабых сторон или идея зародилась сразу же в виде движка, не связанного конкретно с Build, а затем уже всё органично развилось из подобного решения? Я спрашиваю об этом лишь потому, что, согласно моим (смутным) воспоминаниям, чувствовался разный уровень возможностей у чего-то вроде Ken's Labyrinth, плавно переходящего в Duke Nukem 3D, и других громких тайтлов того времени".
Ответ. Когда у меня возникала идея, я создавал прототип на QuickBasic, так как в этой среде было очень легко писать код и проводить отладку. Мой самый ранний прототип того, что должно было стать движком Build, назывался PICROT4.BAS, который просто "выпускал" луч во множество стен. Очевидно, что это был слишком медленный подход для карт с открытыми пространствами. Моей следующей идеей было использовать регулярную сетку, где каждая ячейка содержит список всех стен (они будут линиями в 2D), которые её составляют. Это решало две проблемы: грубую сортировку стен в порядке от начала к концу и исключение всех стен, которые выходили за пределы пирамиды видимости. Можно было бы обойти эту проблему с помощью дополнительного кода для улучшения сортировки, но в то время я не знал, как это сделать. Это был слишком примитивный алгоритм со множеством визуальных "глюков".
Затем в декабре 1993 года Apogee позволили мне позвонить Джону Кармаку. Как и ожидалось, его ответ был сдержанный; он умолчал о многих моментах, не объясняя ничего подробно. Он вообще не обязан был отвечать на мой звонок, в конце концов. Например, я помню, как спрашивал его об одной из самых сложных вещей в Build Engine того времени: как растеризовать или заполнить пикселями потолки и полы. Он описал свой метод как обычную "заливку" (прим. пер.: в оригинале "flood-filling"), что не имело для меня особого смысла. В моём понимании термин «заливка» всегда был медленным алгоритмом, как у инструмента для рисования в Microsoft Paint. Ведь в BASIC можно было реально видеть, как программа выполняет рекурсивный поиск, наблюдая за этим на многих кадрах. Очевидно, что это работало не так. Так что у него было какое-то другое, своё определение того, что значит «заливка», насколько я могу судить.
Ещё я помню, как он дал мне идею и название для объекта – "сектор", который представляет собой структуру для хранения информации о стенах, являющихся общими для потолка и пола. Это не решило моих проблем с сортировкой стен, но заставило меня понять, насколько нелепо был спроектирован мой старый движок на основе регулярной сетки. Я хранил информацию о потолке и поле вместе с каждой стеной! Это не только расходовало существенное количество памяти, но и дополняло движок множеством визуальных сбоев: например, когда структура стены не соответствовала соседней стене в том же секторе.
Чтобы исправить сортировку стен, мне необходимо было немного подтянуть знания по математике: скалярные и векторные произведения. Я узнал о них в первом семестре в Брауне. Я был удивлён, что это не преподают в старшей школе. Теперь, с моим новым алгоритмом сортировки, у меня был способ сортировать стены без сбоев. Я не мог это обосновать, но не мог и найти никаких отклонений в моей тестовой программе... если только стены не пересекались, то есть... но это в любом случае считалось нереализуемой ситуацией.
Интересное отступление: много лет спустя я подумал, что смогу расширить идею сортировки "идеальной стены" (теперь это называется "полигон") до полного 3D. Я назвал её KENVEX – мое имя + выпуклость. Оказалось, что я ошибался, - или, по крайней мере, реализовать это было намного сложнее, чем я себе представлял ранее. У движка было и множество других проблем. И я понятия не имел, как сделать нормальный редактор.
---
DNSKILL5 спрашивает: "Движок Build на этапе разработки первого Blood. В сети имеется несколько противоречивая информация об этом периоде. Иначе говоря, похоже, дела с этим тайтлом шли не так, как ожидалось. Не могли бы вы немного рассказать нам о специфике работы над этим проектом?"
Ответ. Вы говорите о GEORGE.TXT и тираде Питера Фриза, написанной в июне 1995 года. Программисты Blood переопределяли мои внутренние (намеренно недокументированные) функции Build Engine своими собственными версиями. Полагаю, им некогда было ждать появления новых функций. Проблема была в том, что всякий раз, когда я что-то менял в движке, это ломало их код, и тогда им приходилось заново переписывать собственные "хаки". По сути, это почти как редактирование исполняемого файла в шестнадцатеричном формате. Практика переопределения функций может быть очень контрпродуктивной. Понятное дело, что мне нужно было что-то изменять в движке, для того чтобы улучшать его работу и исправлять ошибки.
Я уверен, что их система кэширования была лучше в то время. Проблема в том, что меня заваливали множеством более важных задач от других команд. Вам не нужна идеальная или даже хорошая система кэширования, чтобы тестировать игру во время её разработки. Если у вас недостаточно памяти, то ваш жёсткий диск работает немного дольше. Это раздражает, но что с того? У меня в то время была примитивная система кэширования, которая просто удаляла самые старые объекты, что можно было бы реализовать с помощью простого FIFO. Она была неэффективна в выборе наиболее подходящих объектов для последующего удаления. Позже, в 1995 году, я всё-таки написал улучшенную систему кэширования.
О, я полностью согласен с комментариями Питера о центрировании спрайтов, – это было ошибкой.
Что касается моих навыков разговора по телефону – да. Я не собираюсь «лгать во спасение» или обещать «что-то там сделать», если я никогда раньше не слышал о такой концепции. Мне следовало бы отвечать: «Конечно, я подумаю над этим». Но я был застенчивым 19-летним парнем с небольшим опытом ведения подобных разговоров. Я не очень хорошо соображал, что говорить в таких случаях. По сей день я предпочитаю давать интервью в текстовом формате. ;-) Кстати, когда мы с Питером встретились лично несколько месяцев спустя, мы прекрасно поладили.
---
Вопрос. The Legend of the Seven Paladins 3D (1994, DOS) считается первым коммерческим проектом, основанным на движке Build. Кроме того, в отличие от последующих работ, он основан на его ранней версии. Тем не менее сама история с игрой остается в тумане. Можете ли вы пролить свет на тот необычный проект?
Ответ. Всё, что я знаю, - это то немногое, что мне рассказали в Apogee, а именно – игра была выпущена нелегально. Это было до 2020 года, когда я неожиданно получил электронное письмо от какого-то парня по имени мистер Лин. Судя по всему, он и группа, состоящая из двух человек с Тайваня, приехали к Скотту Миллеру как раз перед Рождеством 1993 года. Лин поведал, что всё закончилось через несколько месяцев из-за проблемы языкового барьера. Что касается вопроса, почему они продолжали работать без надлежащего контракта, – тут ответа я не знаю.
---
Вопрос. На вашем сайте я заметил название Fate Fate (не издана, DOS) от Capstone, что довольно интересно, поскольку я никогда не слышал, чтобы там делали ставку именно на движок Build. Ведь в игре Corridor 8: Galactic Wars (не издана, DOS), которая является продолжением Corridor 7: Alien Invasion (1994, DOS), в конечном итоге использовался движок от Doom. Можете ли вы немного рассказать нам об игре Fate?
Ответ. Я всего лишь знаю, что так называлась третья игра от Capstone, планировавшаяся после Witchaven (1995, DOS) и William Shatner's TekWar (1995, DOS); на сайте игр JonoF есть её демоверсия.
---
Вопрос. Порты, являющиеся производными от ZDoom, поддерживают формат вокселей .kvx (и только его), делая этот древний формат из эпохи Blood единственным неоспоримым стандартом вокселей для сообщества Doom, которое, как известно, является наиболее активным из ему подобных (есть, конечно, DelphiDoom, который может "переваривать" .vox, но он экзотичен и имеет кучу своих ограничений). Существует множество форматов и редакторов вокселей. Но для того, чтобы поместить воксели в Doom, вам нужно преобразовать их с помощью редактора-конвертера в формат .kvx. Там вы можете выборочно подкрасить и отцентрировать их. Подобная программа – это ваш редактор SLAB6, разработанный в 2011 году, который давно уже доступен повсеместно. У SLAB6 есть ограничение на размеры моделей – 256x256x255 вокселей.
Mastermind, к примеру, мог бы вписаться в вышеозначенные ограничения. Но если его масштаб растянуть, то это, судя по всему, уже не будет соответствовать действительности. Более современных альтернатив на горизонте нет и, похоже, не предвидится – получается плохой прецедент, когда что-то современное привязано к древней, заброшенной программной основе.
К слову говоря, обойти подобное ограничение можно обойти через вашу утилиту POLY2VOX. Но для этого нужна шизофреническая схема преобразования воксель-модель-воксель c использованием недокументированных возможностей 3D-редактора, необходимых для центрирования. Что тоже плохо.
Тут длинное вступление заканчивается и начинается вопрос. Планируете ли вы выпустить более современную версию SLAB6?
Ответ. Вам следует рассмотреть PND3D как преемника SLAB6 и VOXLAP. Редактор менее функционален, поскольку им никто не пользовался, но он хорошо работает в качестве быстрого просмотрщика и конвертера форматов. К сожалению, PND3D в настоящее время не сохраняет в формате .KVX. Я мог бы добавить эту опцию, но возникнут некоторые проблемы, такие как квантование цвета и ограничения по размеру.
Формат KVX был разработан для Build Engine, который использовал 8-битную палитру цветов. Формат не нуждался в поддержке огромных моделей и всегда отображался вертикально (где вертикальный алгоритм RLE имеет смысл). В дизайне KVX есть некоторые странные вещи, такие как флаги видимости, которые определяются только для каждого слэба, и смещения, относящиеся к абсолютному положению файла. Кроме того, формат KVX ограничен 256 вокселями в высоту, и, хотя вы и можете расширить координаты x и y за пределы 256, при этом есть риск столкнуться с проблемами. Если спрайт недостаточно сжимаем, то в отношении различных объектов может возникать переполнение, поэтому это не очень хорошая идея. Если вам нужны большие модели, вам следует рассмотреть возможность использования формата KV6. Единственный недостаток KV6 в том, что он не сжимает 8-битную палитру спрайтов так же хорошо, как это делает KVX.
Кроме того, относительно POLY2VOX - не пробовали ли вы опцию /s#? Она предназначена для исправления как постоянного масштаба, так и центрирования в анимациях.
---
ck3D спрашивает: "По сей день Build выделяется своей необычностью на общем фоне игровых движков, которые чаще всего разрабатываются с учетом весьма узких задач практического применения. В особенности современные игры, как правило, полагаются на фотореализм гораздо больше, чем игры 1990-х годов, что необходимо для вовлечения пользователя в геймплей и улучшения восприятия, иногда даже в ущерб более творческим альтернативным подходам. В таких продуктах, как Duke Nukem 3D, не упущен ни один из этих параметров; каким-то образом в них сумели развить правдоподобное игровое окружение, при этом внедряя технические приёмы, искажающие реальность: «сектор на секторе» (это позволяет потенциально бесконечно накладывать невозможные пространства поверх общих координат) и стены, переписывающие своё положение во время исполнения, – всё это те особенности, благодаря которым движок Build также можно рассматривать не только как инструмент, предназначенный для создания уровней, но и как актуальную мини-среду разработки, и чаще всего для большинства устоявшихся мапперских сообществ он таковым и является.
Насколько эта творческая свобода была запланированной и, возможно, важной для вас при проектировании движка? Вы надеялись (или даже ожидали), что эти необычные и относительно экспериментальные функции будут приняты его пользователями? Знали ли вы, что они в конце концов будут настолько эффективны, что это до сих пор оказывает влияние на некоторые нишевые школы дизайна уровней? Или вы, не задумываясь, развлекались, пока это происходило, и всё ещё не знали, насколько негибкими станут компьютерные игры, как только возникнут новые тенденции в их развитии?
Вот ещё один связанный с этим вопрос. Хотя общепринятым каноном в качестве сильной стороны движка является «реализм», я склонен не согласиться с этим и утверждаю, что в действительности это базируется на тех или иных предположениях, а очевидная привлекательность большинства уровней в Build на самом деле достигается за счет методов работы с поверхностями, что приводит к более абстрактному их дизайну и творческим идеям в размещении объектов. Это во многом основано на эффектах маскировки, чтобы привести игроков в такие ситуации, в которые они обычно не попали бы, потому что подобные ситуации довольно искусственные в реализации (и поэтому, как ни парадоксально, для мапперов их очень весело придумывать). Что вы думаете насчёт всего этого?".
Ответ. Очевидно, я мыслю на более низком уровне, чем вы. Я занимаюсь алгоритмами и оптимизацией языка ассемблер. Я не беспокоился о том, как широкая публика воспримет те или иные решения. Многие вещи, которые я делаю, являются результатом развития и улучшения. Я пробую что-то. Если это хорошо, то я это сохраняю. Если нет, то – до свидания. Это хорошо работает, когда дело касается оптимизации. Это также обеспечивает гибкость проектирования. Проблема в том, что идей всегда больше, чем времени. Чтобы решить, над чем поработать, я бы использовал такую простую формулу: крутость, делённая на сложность реализации. Конечно, в итоге я всегда приходил к своему любимому занятию – необязательной оптимизации. ;-)
Ключ к успеху игр на Build Engine, имеющих этот самый "фотореализм", заключался в том, что многие части редактора работали в 3D-режиме. Насколько мне известно, движок Build был первым, где имелась подобная составляющая. Возможность просматривать и изменять игровую среду напрямую, не тратя время на создание BSP или чего-то ещё в этом роде, экономила массу времени (по той же причине я бы использовал QuickBasic для прототипирования вместо Cи, а сегодня это был бы EVALDRAW вместо Cи).
Идея трёхмерного редактора пришла мне в голову во время работы над движком на основе регулярной сетки в середине-конце 1993 года. В то время редактор назывался EDITBORD.BAS и был написан на QuickBasic. Предварительный просмотр в 3D исходно начинался как наспех сделанный хак. Я добавил параметр командной строки в трёхмерный просмотрщик, который у меня был на Cи; он переопределял начальную позицию. Мой редактор QuickBasic мог затем создавать исполняемый файл из любого места, где находился курсор мыши.
Конечно, запуск отдельной программы, когда вам нужен предварительный просмотр, - не лучший вариант для работы. Я знал, что мне придётся портировать редактор из QuickBasic на Cи. Как только у меня появился 2D-режим, работающий в программе на Cи, я понял, что было бы круто иметь возможность редактировать что-то прямо в 3D. Проблема была в том, что мне нужен был способ определить, над какой стеной / потолком / полом / спрайтом находится курсор мыши. В то время у меня ещё не было функции сканирования попаданий луча (в то время никто ещё не делал игр; они просто игрались в моих ранних редакторах для карт и графики). Я придумал способ обнаружения попаданий во время процесса рендеринга: сравнивая каждый горизонтальный или вертикальный промежуток с местоположением курсора мыши. Неказисто, но достаточно легко в плане реализации. Как только эта часть была готова, я начал перемещать как можно больше объектов в трёхмерный редактор. Всё, что связано с отображением текстур, лучше всего работало в режиме 3D. Поднятие/опускание для потолков/полов отлично функционировало в трёхмерном редакторе.
---
Вопрос. Каков был ваш опыт работы с 3D Realms над проектом Duke Nukem 3D (1996, DOS) касательно отзывов, которые вы получали напрямую от дизайнеров уровней? Вы подходили к своей задаче создания игрового движка исключительно с точки зрения кодирования/математики в соответствии с тем, что было нужно разработчикам, или активно смотрели на это так, как сделал бы дизайнер уровней/игрок? Дизайнеры уровней быстро поняли, как использовать редактор, или вам было трудно найти с ними общий язык либо доказать им свою точку зрения?
Ответ. Лучше всего я знал дизайнеров уровней из Duke Аллена Блума (Allen Blum) и Ричарда Грея (Richard Gray). Несколько дизайнеров карт были дополнительно привлечены для завершения издания Duke Nukem 3D: Atomic Edition (1996, DOS), но к тому времени я проводил бóльшую часть своего времени с Фрэнком Мэддином (Frank Maddin), помогая ему закончить Shadow Warrior (1997, DOS). Конечно, было круто наблюдать за тем, как дизайнеры карт делают свою работу. Я не помню, кто конкретно просил, но некоторые из функций в Build, которые появились именно благодаря дизайнерам карт, были такими: Alt+S – чтобы провернуть цикл; нажатие "V" один раз для текущих текстур или два раза для всех текстур (функция, которую я ненавидел); система тегов, несколько видов копирования и вставки; различные "глюки" рендеринга.
Не требовалось много времени, чтобы освоиться с редактором Build. Тогда людям не нужны были красивые меню или кнопки. Вы могли написать текстовый файл, и чаще всего люди его читали. Если вы не могли запомнить всю информацию, вы её распечатывали. Изучение приёмов в Build занимало больше времени, например объединение и разделение секторов без перерисовывания их с нуля.
---
Вопрос. Флагманские игры движка Build имели относительно длительные циклы разработки: начало проекта Shadow Warrior датируется 1993–1994 годами, а движок Build активно развивался все эти годы. Вы вообще играли в каждую из сборок Shadow Warrior и Duke Nukem 3D или это было задачей команды тестеров?
Ответ. На самом деле первым коллективом, использовавшим Build, была команда Blood (1997, DOS), которая начала работу в сентябре 1993 года. Тогда они были известны как "Horror". Конечно, я играл во многие версии игр. Иногда, когда кому-то нужно было показать мне ошибку, они отправляли мне копию по модему и я её просматривал. Если я был на месте, мы могли вести тестирование по IPX или нуль-модему. Часто мы играли ради развлечения по ночам. Хотел бы я сохранить копии каждой из версий игр, к которым у меня был доступ. Конечно, для этого потребовалась бы довольно большая пачка дискет!
---
Вопрос. Вы играли в Shaw's Nightmare (2013)? И если да, то что вы о ней думаете? Кажется, ей нужна некоторая оптимизация производительности.
Ответ. Нет. Видео на YouTube выглядит как уникальное ретро. Возможно, низкая частота кадров была задумана изначально?
---
Вопрос. В Powerslave (1996, DOS) не используются наклонные поверхности ни в одной из официальных карт, и долгое время считалось, что версия движка Build, на которой игра создана, ещё не имела этой функции. Однако недавно было обнаружено, что Powerslave на самом деле полностью поддерживает наклоны, и был создан специальный пакет карт, в полной мере использующий эту функцию. Поскольку наклонные поверхности кажутся логичным элементом в игре в сеттинге Древнего Египта (к примеру, для создания пирамид), сообщество предположило, что 3D Realms могли скрыть информацию о некоторых технических характеристиках, когда они сублицензировали движок Build, чтобы сохранить конкурентное преимущество за своими собственными продуктами. Можете ли вы как-то это прокомментировать?
Ответ. 3D Realms многое скрывали о своих отношениях с небольшими командами разработчиков. Я никогда не видел никаких контрактов, которые они заключали, если только специально не спрашивал об этом у них. Сублицензирование движка не упоминалось в моём первоначальном контракте, и они использовали этот момент в своих интересах. Что касается особенностей, то я знаю, что 3D Realms утаили программную поддержку наклонных поверхностей от Capstone. Что касается того, что случилось с Lobotomy, то я не могу сказать. Я помню, как в Lobotomy расстроились, когда узнали, что движок поддерживает наклонные поверхности. Это выглядит очень странно. Так что, возможно, вы правы – поддержку наклонных поверхностей от них утаили.
---
Вопрос. Если бы вы воссоздали что-то эквивалентное Build Engine, используя имеющиеся у вас на сегодня знания, вы бы внесли какие-либо изменения в дизайн?
Ответ. Конечно. Я бы это сделал, очистив код. Например, больше структур, меньше глобальных переменных, присвоение функциям возвращаемого типа и никаких типов "long" почти для всего. Что касается оптимизации, то я не думаю, что оставил много места для улучшения. Большáя часть моих новых знаний касается современных машин, таких как AVX2, многопоточности и 64-битных сборок. Этих вещей нет на 486-DX или Pentium. ;-) См. дальше список моих сожалений в ответе на двадцатый вопрос.
---
Вопрос. На рубеже 1997–1998 годов разработчикам компьютерных игр неизбежно пришлось переходить на полноценную 3D-графику. Возможно, вы планировали совершенно новый и по-настоящему трёхмерный движок вместо Build в то время, т. е. до наступления 2000-х? Кажется, что чуть позже Voxlap занял эту нишу.
Ответ. Конечно. POLYTEX (1995) был моей первой попыткой конкурировать с Quake. POLYTEX использовал BSP для сортировки полигонов в порядке от конца к началу. Рендеринг был простым, но в нём было много перерисовки. Затем в 1998 году я начал KENVEX, который должен был стать портальным движком. Я хотел, чтобы он работал как Build, с его идеальным удалением скрытых поверхностей, но оказалось, что попытка достичь этого "святого Грааля" для рендеринга полигонов так и не сработала. К сожалению, оба проекта не прошли стадию тестирования. Я понятия не имел, как сделать простой в использовании редактор, работающий в полностью трёхмерной среде.
---
Вопрос. В продолжение предыдущего вопроса. Похоже, вы поклонник вокселей; не было ли у вас соблазна больше работать с традиционным, полным 3D в целом, за исключением рендерера POLYMOST для Build?
Ответ. Есть BUILD2, но это едва ли традиционный вариант, и он появился на много лет позже. Нет, мои амбиции в попытке конкурировать с Quake умерли после моей попытки с KENVEX. К тому же не оставалось времени что-то предпринимать – было слишком поздно: повсюду была очень сильная конкуренция.
---
@drugon спрашивает: "Во второй половине 1990-х активно развивалась 3D-графика, и в какой-то момент показалось, что шутеры, использующие спрайтовых монстров, канут в лету, уступив место шутерам с 3D-моделями. Сами спрайтовые монстры, очевидно, были техническим компромиссом в то время, позволяя железу хоть как-то адекватно вытягивать игру, не жертвуя детализацией окружения, как и те ранние симуляторы, где использовались простые 3D-модели без спрайтов. Но, как это часто бывает с популярными играми, стеснёнными техническими ограничениями, подобные ограничения затем становятся образцом стиля для будущих разработчиков. Спрайтовые объекты в шутерах от первого лица являются ярким примером этого и часто используются в современных ретрошутерах: Mullet Madjack (2024), Warhammer 40,000: Boltgun (2023), Supplice (2023) и т. д. Представляли ли вы, Кен, на рубеже 1990-х и 2000-х годов, что подобное решение породит столько последователей и будет актуально по сей день?"
Ответ. Я не фанат "картонных" спрайтов. Художнику нужно много времени, чтобы их нарисовать, а если вы визуализируете их из 3D-моделей, то это занимает много дополнительной работы и ненужной квантизации. Когда я услышал о Quake, использующем 3D-полигональные модели, я попытался придумать своё собственное решение. Я никогда раньше не пользовался программой для моделирования полигонов, и мне казалось, что написать свою собственную будет непросто. Поэтому я воскресил старую идею, которая у меня была, – воксельные спрайты. Я был рад видеть, как они появляются в играх, пусть даже и в ограниченной форме. Было бы ещё более приятно увидеть тогда, как их используют для монстров... но, думаю, для этого всё было недостаточно быстрым.
---
@drugon спрашивает: "Ещё один конкретный вопрос, если можно. Думали ли вы, Кен, что движок Duke будет использоваться в какой-то степени десятилетия спустя? И не только во многих действительно достойных бесплатных работах фанатов - WG Realms, Duke Nukem Forever 2013 и т.д., - но и в коммерческих релизах?"
Ответ. 30 лет назад я больше бы беспокоился о завершении проектов игр, чем об их наследии. Мы знали, что если будем ждать слишком долго, то появится что-то (возможно, Quake), из-за чего наши игры будут выглядеть устаревшими.
---
Вопрос. Что вы думаете о трассировке лучей как об опции? В последние годы ей уделяется много внимания, что также имело место и в классических играх, включая Doom. Это просто очередная "дань моде" или действительно "стоящая вещь"?
Ответ. Трассировка лучей лучше всего работает, когда у вас есть высокопараллельный процессор, например на современном GPU. К сожалению, я никогда не углублялся в программирование для GPU. Теоретически не должно быть никакой разницы между двумя вариантами вывода. Всё сводится к выбору между использованием пикселя или графического примитива в качестве объекта для вашего внешнего цикла "for". На практике что-то проще в одном методе, а что-то в другом. Например, отражения реализовать проще с трассировкой лучей. Растеризация обычно происходит быстрее из-за того, что количество примитивов меньше количества пикселей на экране. Этот аспект может измениться, когда у вас больше деталей или установлено другое оборудование. Помимо этого, мне нечего больше сказать по этой теме - кроме того, что я так и не попробовал сделать общую трассировку лучей.
---
Вопрос. Если бы в 2024 году потребовалось сделать другой движок с программным рендерингом для нового 3D-шутера с нуля, в чём были бы основные отличия по сравнению с Build?
Ответ. Лучше спросить: кто был бы настолько сумасшедшим, чтобы "потребовать" подобного безумия? Чтобы ответить на ваш вопрос, моей первой задачей была бы необходимость выбирать между воксельным, полигональным или гибридным движками. Полигональный движок мог бы хорошо работать, если бы был элегантный, безошибочный способ выполнять операции CSG на лету. Воксельный движок мог бы хорошо работать, если бы был способ анимировать спрайты плавно, без необходимости делать отдельные кадры анимации. Очевидно, что я бы с самого начала разработал любой новый проект для компьютеров, используя 64-битный режим, AVX2 и многопоточность.
---
Вопрос. Есть ли у вас какие-либо сожаления относительно работы над Build - или, может быть, есть то, что вы хотели бы сделать по-другому? Этот вопрос включает в себя технические аспекты, связанные с движком Build.
Ответ. Конечно, вот список:
* Наложение текстур на наклонные поверхности. Мне не следовало прибегать к использованию инструкций FPU для получения дополнительного целочисленного регистра. Это убивало частоту кадров на 486-SX, когда на экране была наклонная поверхность.
* Наклонные поверхности с наложенными текстурами. Могло бы работать немного быстрее, если бы у меня было время, чтобы воплотить реализацию наложения текстур в горизонтальном направлении.
* Истинно-центральное центрирование: этот флаг не должен был оказаться в структуре спрайтов. Вместо этого его следовало предоставить в качестве макроса программисту игры.
* Полы с наложением высот (они же "groundraw"). Я так и не дошёл до исправления ошибок деления на ноль. Позже наклонные поверхности сделали этот компонент устаревшим.
* Сетевой код. Я мог бы сэкономить всем много времени, если бы всё сделал правильно с первого раза. Это было сделано уже в процессе проектирования игр, а не движка, поэтому мне пришлось потратить много времени на обучение программистов тому, как вносить каждое небольшое изменение, которое я придумывал.
* Режим «красный-синий». Должен был бы быть режим «красный-голубой». Зелёный канал в ауте! Хотя это же мелочь.
* Архивы. Я сохранил много вещей с тех времён, но хотел бы сохранить ещё больше. В частности, больше копий каждой коммерческой игры. Кроме того, было бы неплохо, если бы резервная копия моего жёсткого диска с 1995 года не погибла.
---
Вопрос. Что вы думаете о потенциале воксельных движков, таких как VOXLAP, сегодня? Voxelstein 3D был скорее технической демонстрацией, но всё равно довольно интересным экспериментом. Как вы думаете, у таких игр есть будущее?
Ответ. Когда вы говорите «как VOXLAP», я предполагаю, что вы имеете в виду маленькие воксели, а не большие, которые вы могли видеть в Minecraft / Roblox. Воксельные объекты хорошо работают на 3D-дисплее, и их легко генерировать из кода (например, в EVALDRAW). Они не имеют особого смысла, если вы ищете возможность отображать реалистичные пейзажи. Воксели плохо масштабируются при увеличении разрешения. Неважно, сколько бит [цвета] вы в них помещаете, – вы всё равно видите кубики. Конечно, вы можете скрыть это с помощью интерполяции, но это дорого вам обойдётся - во всяком случае, если вы не используете GPU.
---
Вопрос. В настоящее время Cheello работает над своим масштабным проектом Voxel Duke Nukem 3D, целью которого является воссоздание каждого спрайта (монстра) в игре. Вы видели другие работы Cheello: Voxel Doom, Voxel Blood?
Ответ. Да. Очень здорово видеть, как 2D-спрайты преобразуются в воксели и вручную редактируются до такого уровня точности. Это действительно выглядит аутентично по отношению к оригинальным играм.
---
Вопрос. Есть ли какая-то функция, которой не было в движке Build (до перехода проекта в открытый доступ) и которую вы хотели бы реализовать?
Ответ. Конечно. Вам стоит посмотреть Build 2. Вот несколько самых важных функций, которые я бы хотел видеть в Build:
* Полноценный взгляд вверх / вниз.
* Нативная поддержка комнаты поверх комнаты.
* Красивое освещение.
* Drop-in networking (прим. пер.: термин, определяющий взаимодействие различных беспроводных и проводных сетей связи с целью передачи данных между устройствами).
---
Вопрос. Если не секрет, почему вы решили уйти из крупной игровой индустрии? Из коммерческой, я имею в виду. Есть ли шанс, что вы вернётесь в неё, - может быть, даже к чему-то, связанному с Duke, или к новой игре на основе движка Build, как бы маловероятно это ни было, если кто-то попросит?
Ответ. В 1997 году я заметил, что спецу-одиночке по разработке движков уже нечего ловить. Конкуренция возросла многократно. Даже тогда я знал, что разработка нового движка займёт много лет... но всё же не 14 лет. ;-P. Я не хотел переезжать в Техас на постоянное место жительства и не рассматривал другие компании. В 2015 году Gearbox спросили, могу ли я как-то поучаствовать в ремейке Duke 3D, который позже стал изданием DN3D 20th Anniversary. Я не знал, каким образом мог бы внести в это дело свой вклад и при этом не слишком навредить своему графику. Запись звуковых эффектов может занять несколько дней. Создание карт или песен может занять несколько недель. Но написание нового движка может занять годы. Позже я понял, чего они на самом деле хотели, а именно порт на несколько консолей вместе с несколькими настройками. Я никогда не занимался программированием для консолей, так что, полагаю, ситуация сложилась к лучшему. Что касается возвращения в игровую индустрию, то я не вижу к тому предпосылок. К тому же делать трёхмерные дисплеи - это намного веселее. ;-)
---
Вопрос. Вы когда-нибудь представляли себе Build 2 как что-то большее, чем просто учебный проект для летнего лагеря? С какой игрой, по вашему мнению, он мог бы работать лучше, чем, скажем, с EDuke32? Что побудило вас выпустить Build 2 в 2018 году, почти через 10 лет после того, как вы перестали над ним работать?
Ответ. Поскольку я вложил в него много усилий, было бы неплохо увидеть полноценную игру, созданную с его помощью. Я полагаю, что никто не хочет использовать недоделанный движок, полный нечитаемого ассемблерного кода. Я выпустил его, потому что… а почему бы и нет. Это была клёвая штука, но сейчас он не имеет для меня никакой ценности. Мне следовало выпустить его на несколько лет раньше.
---
Вопрос. Что за история скрывается за таинственным Ken's Labyrinth II? Похоже, что проект находится в разработке с 2007 года, но у него почти не было рекламы. Вы участвуете / участвовали в нём каким-либо образом, кроме лицензирования персонажей? Разве не разочаровывает, что игра использует GZDoom, а не Build или другой ваш движок?
Ответ. Я никогда ничего не лицензировал. Всё, что я делал, это говорил что-то вроде "Да, конечно" в ответе по электронной почте. Ken's Labyrinth был демоверсией движка с кучей спонтанной ерунды внутри. Мне лестно, что кто-то хочет сделать шутер на основе первого "Лабиринта Кена". Некоторое время назад ребята попросили меня записать несколько звуковых эффектов для их игры, что я и сделал. Я понятия не имею, будут ли они на самом деле это использовать. Кроме этого, я не имею никакого отношения к проекту.
---
Вопрос. Кен, вы упоминаете свою любовь к картографии и картам, и среди текстур стен в Ken's Labyrinth есть изображения карты США. Было ли это ваше хобби полезным для проектирования карт в Ken's Labyrinth или для каких-либо других аспектов разработки игры/движка?
Ответ. Не совсем. В детстве мне нравилось рисовать и переписывать (но никогда не калькировать) карты. Я до сих пор могу нарисовать довольно хорошую карту пятидесяти штатов по памяти. Я не думаю, что это имеет большое отношение к дизайну движка, но могу сказать, что всё это подразумевает наличие развитого образного мышления, что всегда было моей сильной стороной (кстати, большинство карт для Ken's Labyrinth разработал Энди Коттер (Andy Cotter)).
---
Вопрос. Можете ли вы рассказать, чем сейчас занимаетесь, какие проекты вас интересуют? Разрабатываете ли вы сейчас какое-либо программное обеспечение для создания игр?
Ответ. Я работаю в Voxon Photonics уже более 10 лет. Мы делаем трёхмерные [объёмные] дисплеи. Моя работа в основном заключается в низкоуровневом программном обеспечении, но я также занимаюсь проектированием печатных плат. Я написал SDK, который включает в себя несколько простых демоигр. К сожалению, я давно не обновлял свой сайт, потому что был очень занят своей работой в Voxon.
---
Вопрос. Вы играли в Ion Fury? И если да, то что вы думаете об этой игре? Считаете ли вы её достойным духовным преемником Duke Nukem 3D? Считаете ли вы, что должно выйти больше игр, подобных Ion Fury?
Ответ. Конечно. Я считаю, что игра отличная. Мне понравились новые и очень детализированные карты. Воксельные объекты были хорошо сделаны. Приятно видеть, как моя работа с POLYMOST находит практическое применение. Кроме того, поезда с дробовиками – это весело. ;-)
---
Вопрос. Какие-нибудь слова напоследок для наших читателей?
Ответ. Конечно. Game over – Игра окончена.
---
Автор: UnknDoomer
Дата: 22.06.2024