Новый день. Новое интервью. Новые 30 вопросов.
Краткая справка об основных действующих лицах:
Ken Silverman - создатель Build, а также ряда иных решений, вроде VOXLAP, на основе которых в последующем были созданы игры в диапазоне от Duke Nukem 3D (1996) и Blood (1997) до Ion Fury (2019), а также Electric Highways (2015) и Voxelstein 3D (2008) в отдельности. Домашняя страница - Ken Silverman's Official Home Page.
Вопрос. Что-то вдохновило вас на создание движка Build? И, касательно вашего участия в разработке конкретных игр, возможно вы могли бы упомянуть несколько интересных фактов?
Ответ. Конечно - Doom. Я начал публиковать информацию и скриншоты об их следующей игре как раз тогда, когда я закончил Ken's Labyrinth (1993) в начале 1993 года. После того, как я потратил почти год на копирование Wolfenstein 3D (1992), он, очевидно, привлёк моё внимание. Ваш второй вопрос немного общий. Как насчёт того, чтобы прочитать остальную часть интервью? ;-)
taufan99 спрашивает: "С тех пор, как я поиграл в Ken's Labyrinth и другие ваши программы, я влюбился в формат KSM. Однако я хотел бы узнать, можете ли вы выпустить конвертер в формат General MIDI, потому что, хотя я и признаю, что AdLib — хорошая звуковая карта, я сам больше поклонник General MIDI".
Ответ. Если вы не против небольшого редактирования, то вы можете использовать мою программу KS2.EXE для преобразования данных музыкальных форматов. Ищите её на моей домашней странице, в разделе утилит. Вам придётся вручную выбирать инструменты MIDI и полностью переделывать перкуссионный трек с помощью инструмента лассо. При некоторой настойчивости вы сможете получить хорошие результаты. Да, KS2 давно не обновлялся и он имеет свойство мерцать в современных версиях Windows. Я мог бы это исправить, если бы у меня было достаточно мотивации и времени.
vyruss спрашивает: "Во время экспериментальной стадии создания Build, что привело к окончательному решению использовать именно порталы среди других технологий того времени? Я знаю об их преимуществах по сравнению с другими технологиями рендеринга того периода, а также об ограничениях основного пользовательского оборудования — был ли проведён значительный анализ различных подходов для измерения их сильных и слабых сторон, или идея началась в одной итерации как движок, не связанный конкретно с Build, а затем органически выросла из этого подхода? Я спрашиваю об этом, потому что мои (смутные) воспоминания демонстрируют разные уровни возможностей между чем-то вроде Ken's Labyrinth, плавно переходящим в Duke Nukem 3D и другими громкими именами того времени".
Ответ. Когда у меня возникала идея, я писал прототип на QuickBasic, так как в этой среде было очень легко писать код и проводить тестирование. Мой самый ранний прототип того, что должно было стать Build, назывался PICROT4.BAS, который просто транслировал лучи в месиво из стен. Очевидно, что это слишком медленный подход для большой карты. Моей следующей идеей было использовать сетку, где каждая ячейка содержит список всех стен (линий в 2D), которые её касаются. Это решало две проблемы: грубую сортировку стен в порядке от начала к концу и исключение всех стен, которые выходили за пределы пирамиды видимости. Можно было обставить этот вопрос с помощью дополнительного кода для уточнения сортировки, но в то время я не знал, как это сделать. По сути это был алгоритм не слишком подкованного художника и он был полон визуальных глюков.
Затем в декабре 1993 года Apogee попросил меня позвонить Джону Кармаку. Как и ожидалось от такого холодного звонка, он умолчал о многих темах, не объясняя их подробно. В конце концов ему пришлось ответить на звонок более предметно. Например я помню, как спрашивал его об одной из самых сложных вещей в Build Engine того времени — как растеризовать или заполнить потолки и полы. Он описал свой метод как простую "заливку", что не имело для меня особого смысла. Для меня заливка всегда была медленным алгоритмом, как инструмент рисования в Microsoft Paint. Или в Basic вы могли видеть, как он фактически выполняет свой рекурсивный поиск, наблюдая за ним на многих кадрах. Очевидно, что это не так. Так что у него было другое определение того, что означает заливка, на сколько я могу судить.
Ещё я помню, как он дал мне идею и название для "сектора", который представляет собой структуру для хранения информации о потолке и поле для списка общих стен. Это не решило моих проблем с сортировкой стен, но заставило меня понять, насколько нелепо был спроектирован мой старый движок на основе сетки. Я хранил информацию о потолке и поле вместе с каждой стеной! Это не только тратило существенное количество памяти, но и дополняло движок множеством визуальных сбоев — например, когда структура стены не соответствовала её соседу в том же секторе.
Чтобы исправить сортировку стен, мне нужно было выучить немного новой математики: двумерные точечные и векторные произведения. Я узнал об этом во время моего первого семестра математики в Брауне. Я был удивлен, что они не преподают это в старшей школе. Теперь с моим новым алгоритмом сортировки у меня был способ сортировать стены без сбоев. У меня не было доказательств, но я не мог найти никаких контрпримеров в моей тестовой программе... если только стены не пересекались, то есть... но это в любом случае не считалось применимым случаем.
Интересное отступление: много лет спустя я подумал, что могу расширить эту идею сортировки идеальной стены (теперь полигональной) до полного 3D. Я назвал её KENVEX — мое имя + выпуклость. Оказалось, что я ошибался, или, по крайней мере, это было намного сложнее, чем я себе представлял ранее. У движка было и множество других проблем. Я понятия не имел, как сделать нормальный редактор.
DNSKILL5 спрашивает: "Build во время разработки первого Blood. В сети есть некоторая противоречивая информация об этом периоде. Иначе говоря похоже дела с этим тайтлом пошли не так как ожидалось. Не могли бы вы немного рассказать нам о специфике работы над этим проектом?".
Ответ. Вы говорите о GEORGE.TXT, тираде Питера Фриза, написанной в июне 1995 года. Программисты Blood переопределяли мои внутренние (намеренно недокументированные) функции Build Engine своими собственными версиями. Полагаю они не могли дождаться появления новых функций. Проблема была в том, что всякий раз, когда я что-то менял в движке, это ломало их код и тогда им приходилось заново проводить обратную разработку (прим. пер.: reverse engineering) своих хаков. По сути почти как редактирование исполняемого файла в шестнадцатеричном формате. Практика переопределения функций может быть очень контрпродуктивной. Очевидно, мне нужно было что-то изменить в движке, чтобы улучшить его и исправить ошибки.
Я уверен, что их система кэширования была лучше в то время. Проблема в том, что меня бомбардировали множеством других высоко приоритетных задач от других команд. Вам не нужна идеальная или даже хорошая система кэширования, чтобы тестировать игру во время её разработки. Если у вас недостаточно памяти, то ваш жёсткий диск работает немного дольше. Это раздражает, но что с того. У меня была примитивная система кэширования в то время, которая просто удаляла самые старые вещи, что можно было реализовать с помощью простого FIFO. Она была неэффективна в выборе наиболее подходящих вещей для последующего удаления. Позже, в 1995 году, я всё-таки написал улучшенную систему кэширования.
О, я полностью согласен с комментариями Питера о центрировании спрайтов — это было ошибкой.
Что касается моих навыков разговора по телефону — да. Я не собираюсь лгать во спасение и обещать что-то сделать, когда я никогда раньше не слышал об этой концепции. Мне следовало бы сказать: "Конечно, я подумаю над этим". Но я был застенчивым 19-летним парнем с небольшим опытом разговоров. Я не очень хорошо соображал, что говорить в таких случаях. По сей день я предпочитаю давать интервью в текстовом формате ;-) Кстати, когда мы с Питером встретились лично несколько месяцев спустя, мы прекрасно поладили.
The Legend of the Seven Paladins 3D (1994).
Вопрос. The Legend of the Seven Paladins 3D (1994) считается первым коммерческим проектом, основанным на Build. Кроме того, в отличие от последующих работ, он основан на ранней версии Build. Тем не менее, сама его история остается в тумане. Можете ли вы пролить свет на этот необычный проект?
Оригинальный куб - https://coub.com/view/1dl7et.
Ответ. Всё, что я знаю, это то немногое, что мне рассказала Apogee, а именно, что игра была выпущена нелегально. Это было до 2020 года, когда я получил спонтанное электронное письмо от какого-то парня по имени мистер Лин. Судя по всему он и группа из двух других парней из Тайваня посетили Скотта Миллера как раз перед Рождеством 1993 года. Он сказал, что всё закончилось через несколько месяцев из-за языкового барьера. Что касается того, почему они продолжали работать без надлежащего контракта, то не знаю.
Вопрос. На вашем сайте я заметил название Fate от Capstone, что интересно, потому что я никогда не слышал, чтобы они делали ставку именно на Build. Corridor 8: Galactic Wars, который должен был стать продолжением Corridor 7: Alien Invasion (1994), в конечном итоге использовал движок Doom. Можете ли вы немного рассказать об этом этой игре?
Ответ. Всё, что я знаю, это то, что так называлась третья игра Capstone, планировавшаяся после после Witchaven (1995) и William Shatner's TekWar (1995) и на сайте игр JonoF есть её демоверсия.
Вопрос. Порты, являющиеся производными от ZDoom, поддерживают формат вокселей .kvx (и только его), делая этот древний формат из эпохи Blood единственным, неоспоримым стандартом вокселей для сообщества Doom, которое, как известно, является самым живучим (есть, конечно, DelphiDoom, который может поедать .vox, но он экзотичен и имеет кучу своих ограничений). Существует множество форматов и редакторов вокселей. Но для того, чтобы поместить воксели в Doom, вам нужно пропустить их через редактор-конвертер в .kvx. Там вы можете опционально подкрасить и отцентрировать их. Подобный редактор — ваш редактор SLAB6, программного обеспечения 2011 года, давно валяющегося неподалёку. У SLAB6 есть ограничение на размеры модели вокселей 256x256x255 пикселей.
Mastermind, например, мог бы вместиться. Но если вы промасштабируете его, то он больше не впишется в имеющиеся рамки, или, по крайней мере, такое складывается впечатление. Более современных альтернатив на горизонте не видно и, похоже, не предвидится - создаётся плохой синдром, когда что-то современное привязано к древней, заброшенной инфраструктуре.
К слову говоря. Обойти ограничение можно через вашу утилиту POLY2VOX. Но для этого нужна шизофреническая схема преобразования воксель-модель-воксель с довольно грязными хаками в 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 выделяется своей необычностью в общем ландшафте игровых движков, которые, чаще всего, разрабатываются с учетом довольно неизбежных проблем практического применения. В особенности, современные игры, как правило, полагаются на фотореализм гораздо больше, чем игры 90-х годов, для погружения пользователя и понятности ему, иногда в ущерб более креативным, альтернативным подходам. Такие игры, как Duke Nukem 3D, не упустили ни одного из этих параметров и каким-то образом сумели продвинуть правдоподобные среды, при этом технически внедряя трюки, искажающие реальность: "сектор на секторе" (что позволяет потенциально бесконечно накладывать невозможные пространства поверх общих координат) и стены, переписывающие своё положение во время исполнения, — это особенности, благодаря которым, помимо того, что он является инструментом, предназначенным для обслуживания разработки, Build также можно рассматривать как собственную мини-среду, и, как правило, для большинства старожилов в картографических сообществах он таковым и является.
Насколько эта творческая свобода была преднамеренной и, возможно, важной для вас при проектировании? Вы надеялись (или даже ожидали), что эти необычные и относительно экспериментальные функции будут приняты его пользователями? Знали ли вы о том, какой посыл они в итоге принесут и что, в конечном счёте, будут влиять на некоторые нишевые школы дизайна уровней? Или вы не задумываясь развлекались и всё ещё не знали, насколько негибкими станут игры, как только появятся следующие несколько тенденций в их развитии?
Подвопросы, которые также связаны с этим. Хотя общепринятым каноном является "реализм" как сильная сторона Build, я бы склонен не согласиться с этим и утверждать, что в действительности это основано на тех или иных предположениях, а очевидная привлекательность большинства уровней в Build на самом деле достигается за счет методов работы с поверхностями, что приводит к более абстрактному дизайну уровней и креативным идеям в расположении объектов на таковом. Этот факт во многом полагается на маскировку, дабы привести игроков в ситуации, в которые они обычно не попадают, потому что указанные ситуации обычно довольно технические (и поэтому, как это ни парадоксально, для картографов их очень весело придумывать). Что вы думаете на этот счёт?".
Ответ. Очевидно, я мыслю на более низком уровне, чем вы. Я занимаюсь алгоритмами и оптимизацией языка ассемблера. Я не беспокоился о том, как широкая публика воспримет те или иные вещи. Многие вещи, которые я делаю, являются результатом эволюции. Я пробую что-то. Если это хорошо, я это сохраняю. Если нет, то до свидания. Это хорошо работает, когда дело касается оптимизации. Это также работает для изменений в вопросе дизайна. Проблема в том, что идей всегда больше, чем времени. Чтобы решить, над чем работать, я бы использовал такую простую формулу: крутость, деленная на сложность реализации. Конечно, я обычно в конечном итоге делал то, над чем мне хотелось работать в тот момент, что обычно было ненужной оптимизацией ;-).
Ключ к играм на Build Engine, имеющим этот предполагаемый "фотореализм", заключался в том, что большие части редактора работали в 3D-режиме. Насколько мне известно, Build был первым, где имелась подобная составляющая. Возможность просматривать и изменять игровую среду напрямую, не тратя время на создание BSP или что-то в этом роде, экономила массу времени (по той же причине я бы использовал QuickBasic для прототипирования вместо C, а сегодня это был бы EVALDRAW вместо C).
Идея трёхмерного редактора пришла мне в голову во время работы над движком на основе сетки в середине-конце 1993 года. В то время редактор назывался EDITBORD.BAS и был написан на QuickBasic. Предварительный просмотр в 3D исходно начинался как наспех сделанный хак. Я добавил параметр командной строки в трёхмерный просмотрщик, который у меня был на C, он переопределял начальную позицию. Мой редактор QuickBasic мог затем создавать исполняемый файл из любого места, где находился курсор мыши.
Конечно, компиляция программы каждый раз, когда вам нужен предварительный просмотр, не было самым быстрым способом запуска. Я знал, что мне придётся портировать редактор из QuickBasic в C. Как только у меня появился 2D-режим, работающий в программе на C, я понял, что было бы круто иметь возможность редактировать что-то прямо в 3D. Проблема была в том, что мне нужен был способ определить, над какой стеной / потолком / полом / спрайтом находится курсор мыши. В то время у меня ещё не было функции сканирования попаданий (в то время никто ещё не делал игр; они просто игрались в моих ранних редакторах карт и графики). Я придумал способ обнаружения попаданий во время процесса рендеринга — сравнивая каждый горизонтальный или вертикальный промежуток с местоположением курсора мыши во время рендеринга. Неказисто, но достаточно легко в вопросе реализации. Как только эта часть была готова, я начал перемещать как можно больше вещей в трёхмерных редактор. Всё, что связано с отображением текстур, лучше всего работало в режиме 3D. Поднятие / опускание потолков / полов отлично функционировало в трёхмерном редакторе.
Вопрос. Каков был ваш опыт работы с 3DR над Duke Nukem 3D (1996) в отношении отзывов, которые вы получали напрямую от дизайнеров уровней? Вы подходили к своей задаче создания игрового движка исключительно с точки зрения кодирования / математики в соответствии с тем, что было нужно разработчикам, или вы активно смотрели на это так, как это сделал бы дизайнер уровней / игрок? Дизайнеры уровней быстро поняли, как использовать редактор, или вам было трудно найти общий язык / показать им свою точку зрения?
Ответ. Дизайнерами уровней из Duke, которых я знал лучше всего, были Аллен Блум и Ричард Грей. Несколько дизайнеров карт были добавлены для завершения издания Duke Nukem 3D: Atomic Edition (1996), но к тому времени я проводил большую часть своего времени с Фрэнком Мэддином, помогая закончить Shadow Warrior (1997). Конечно, было круто наблюдать за тем, как дизайнеры карт делают свою работу. Я не помню, кто конкретно просил, но некоторые из функций в Build, которые пришли от дизайнеров карт, были такими: Alt+S, чтобы сделать петлю красной, нажатие "V" один раз для текущих текстур или два раза для всех (функция, которую я ненавидел), система тегов, несколько видов копирования и вставки, различные глюки рендеринга.
Не потребовалось много времени, чтобы освоиться с редактором Build. Тогда людям не нужны были замысловатые меню или кнопки. Вы могли написать текстовый файл и чаще всего люди его читали. Если вы не могли запомнить всё написанное в текстовом файле, вы распечатывали его. Изучение трюков Build заняло больше времени, как пример объединение и разделение секторов, без перерисовывания их с нуля.
Вопрос. Флагманские игры на движке Build имели относительно длительные циклы разработки, Shadow Warrior датируется 1993-1994 годами, а движок Build активно развивался все эти годы. Вы играли в каждую сборку Shadow Warrior и Duke Nukem 3D или это было делом команды тестирования?
Ответ. На самом деле, первой командой, которая использовала Build, была команда Blood (1997), которая начала работу в сентябре 1993 года. Тогда они были известны как команда "Horror". Конечно, я играл во многие версии игр. Иногда, когда кому-то нужно было показать мне ошибку, они отправляли мне копию по модему, и я её просматривал. Если я был на месте, мы могли вести тестирование по IPX или нуль-модему. Часто мы играли ради развлечения по ночам. Хотел бы я сохранить копии каждой версии, к которой у меня был доступ. Конечно, для этого потребовалась бы довольно большая коробка дискет!
Вопрос. Вы играли в Shaw's Nightmare (2013)? И если да, что вы о ней думаете? Кажется, что ей нужна некоторая оптимизация производительности.
Ответ. Нет. Видео на YouTube выглядит как уникальное ретро. Возможно низкая частота кадров является намеренной?
Вопрос. Powerslave (1996) не использует наклонные поверхности ни в одной из официальных карт и долгое время считалось, что версия движка Build, на которой он работает, ещё не имела этой функции. Однако недавно было обнаружено, что Powerslave на самом деле полностью поддерживает наклоны и был создан специальный пакет карт, чтобы в полной мере воспользоваться этой функцией. Поскольку наклонные поверхности кажутся логичным элементом в игре на тему Древнего Египта (к примеру для создания пирамид), сообщество предположило, что 3D Realms могла скрыть информацию о некоторых технических характеристиках, когда она сублицензировала движок Build, чтобы сохранить конкурентное преимущество со своими собственными продуктами. Можете ли вы как-то это прокомментировать?
Ответ. 3D Realms многое скрывали о своих отношениях с небольшими игровыми командами. Я никогда не видел никаких контрактов, которые они заключали, если только я специально не спрашивал о них. Сублицензирование движка не упоминалось в моём первоначальном контракте и они использовали этот факт в своих интересах. Что касается особенностей, то я знаю, что 3D Realms удержали склоны от передачи Capstone. Что касается того, что случилось с Lobotomy, то я не могу сказать. Я помню, как Lobotomy расстроились, когда узнали, что движок поддерживает склоны. Я нахожу этот вопрос очень запутанным. Так что, возможно, вы правы — склоны были удержали от них.
Вопрос. Если бы вы воссоздали что-то эквивалентное Build Engine, используя имеющиеся у вас сейчас знания, вы бы внесли какие-либо изменения в дизайн?
Ответ. Конечно. Я бы это сделал, очистив код. Например больше структур, меньше глобальных переменных, присвоение функциям возвращаемого типа, за вместо "long" почти для всего. Что касается оптимизации, то я не думаю, что я оставил много места для улучшения. Большая часть моих новых знаний касается современных машин, таких как AVX2, многопоточность и 64-битная сборка. Этих вещей нет на 486-DX или Pentium ;-). Смотрите список моих сожалений в моём ответе на двадцатый вопрос.
Вопрос. На рубеже 1997-1998 годов разработчикам компьютерных игр неизбежно приходилось переходить на полноценную 3D-графику. Возможно, вы планировали совершенно новый и по-настоящему трёхмерный движок вместо Build в то время, т.е. до наступления 00-х? Кажется позже Voxlap занял эту нишу.
Ответ. Конечно. POLYTEX (1995) был моей первой попыткой конкурировать с Quake. POLYTEX использовал BSP для сортировки полигонов в порядке от конца к началу. Рендеринг был простым, но в нём было много перерисовки. Затем в 1998 году я начал KENVEX, который должен был стать портальным движком. Я хотел, чтобы он работал как Build, с его идеальным далением скрытых поверхностей, но оказалось, что попытка достичь этого святого Грааля рендеринга полигонов так и не сработала. К сожалению, оба проекта не прошли стадию тестирования. Я понятия не имел, как сделать простой в использовании редактор, работающий в полностью трёхмерной среде.
Вопрос. В продолжение предыдущего. Похоже, вы поклонник вокселей, не было ли у вас соблазна больше работать с традиционным, полным 3D в целом, за исключением рендерера POLYMOST для Build?
Ответ. Есть BUILD2, но это едва ли традиционный вариант и он появился на много лет позже. Нет, мои амбиции в попытке конкурировать с Quake умерли после моей попытки с KENVEX. К тому времени что-то предпринимать было слишком поздно — конкуренция была острой.
drugon спрашивает: "Во второй половине 90-х активно развивалась 3D-графика и в какой-то момент показалось, что шутеры, использующие спрайтовых монстров, канут в лету, уступив место шутерам с 3D-моделями. Сами спрайтовые монстры, очевидно, были техническим компромиссом в то время, позволяя железу хоть как-то адекватно вытягивать игру, не жертвуя детализацией окружения, как те же ранние симуляторы, где использовались простые 3D-модели без спрайтов. Но как часто бывает с популярными играми, стесненными техническими ограничениями, эти ограничения затем становятся стилистическим ориентиром для будущих разработчиков. Спрайтовые объекты в шутерах от первого лица являются ярким примером этого и часто используются в современных ретро-шутерах (Mullet Madjack (2024), Warhammer 40,000: Boltgun (2023), Supplice (2023) и т. д.). Представлял ли Кен на рубеже 90-х и 00-х, что такой приём породит столько последователей и будет актуален по сей день?".
Ответ. Я не фанат картонных спрайтов. Художнику нужно много времени, чтобы их нарисовать, а если вы визуализируете их из 3D-моделей, это много дополнительной работы и ненужной квантизации. Когда я услышал о Quake, использующем 3D-полигональные модели, я попытался придумать своё собственное решение. Я никогда раньше не пользовался программой для моделирования полигонов и мне казалось, что написать свою собственную будет непросто. Поэтому я воскресил старую идею, которая у меня была — воксельные спрайты. Я был рад видеть, что они попадают в игры, даже в ограниченной форме. Было бы приятнее увидеть, как их используют для врагов... но, думаю, для этого он был недостаточно быстр.
drugon спрашивает: "Ещё один конкретный вопрос, если можно. Думал ли Кен, что движок Duke будет использоваться в какой-то степени десятилетия спустя? И не только во многих действительно достойных бесплатных работах фанатов (WG Realms, Duke Nukem Forever 2013 и т. д.), но и в коммерческих релизах?".
Ответ. 30 лет назад я бы больше беспокоился о завершении игр, чем о наследии. Мы знали, что если будем ждать слишком долго, то появится что-то (возможно Quake), из-за чего наши игры будут выглядеть устаревшими.
Вопрос. Что вы думаете о трассировке лучей как об опции? В последние годы ей уделяется много внимания, что также имело место быть и в классических играх, включая Doom. Это просто ещё один проходящий "шум модерна" или что-то из разряда того, что именуют как "real deal"?
Ответ. Трассировка лучей лучше всего работает, когда у вас есть высоко параллельный процессор, например, на современном GPU. К сожалению, я никогда не углублялся в программирование GPU. Теоретически не должно быть никакой разницы в выводе между ними. Все сводится к выбору между использованием пикселя или примитива в качестве вашего внешнего цикла "for". На практике некоторые вещи проще в одном методе, чем в другом. Например отражения реализовать проще с трассировкой лучей. Растеризация обычно происходит быстрее из-за того, что количество примитивов меньше количества пикселей на экране. Этот аспект может измениться, когда у вас больше деталей или другое оборудование. Помимо этого, мне нечего больше сказать по этой теме, кроме того, что я не пробовал общую трассировку лучей.
Вопрос. Если бы в 2024 году потребовалось бы сделать другой движок с нуля, с программным рендерингом, для нового 3D-шутера, в чём были бы основные отличия по сравнению со Build?
Ответ. Лучше спросить: кто был бы настолько сумасшедшим, чтобы "потребовать" подобного безумия? Чтобы ответить на ваш вопрос, моей первой задачей было бы выбрать между воксельным, полигональным или гибридным движком. Полигональный движок мог бы хорошо работать, если бы был элегантный, безошибочный способ выполнять операции CSG на лету. Воксельный движок мог бы хорошо работать, если бы был способ анимировать спрайты плавно, без необходимости делать отдельные кадры анимации. Очевидно, что я бы спроектировал любой новый проект для компьютеров, используя 64-битный режим, AVX2 и многопоточность с самого начала.
Вопрос. Есть ли у вас какие-либо сожаления относительно работы над Build или может быть того, что вы хотели бы сделать по-другому или нет? Это вопрос включает в себя технические аспекты, связанные с Build.
Ответ. Конечно. Вот список:
* Наложение текстур на уклон. Мне не следовало прибегать к использованию инструкций FPU для получения дополнительного целочисленного регистра. Это убивало частоту кадров на 486-SX, когда на экране был уклон.
* Наклоны с наложением текстур. Могло бы работать немного быстрее, если бы у меня было время, чтобы воплотить реализацию наложения текстур в горизонтальном направлении.
* Реальное центрирование: этот флаг в структуре спрайтов никогда не должен был существовать. Вместо этого его следовало предоставить в качестве макроса программисту игры.
* Полы с наложением высот (они же "groundraw"). Я так и не дошел до исправления ошибок деления на ноль. Позже наклоны сделали эту деталь устаревшей.
* Сетевой код. Я мог бы сэкономить всем кучу времени, если бы я просто сделал всё правильно с первого раза. Этот аспект был проделан в играбельной области, а не в движке, поэтому мне пришлось потратить много времени, обучая каждого программиста конкретной игры, как вносить каждое небольшое изменение, которое я придумал.
* Режим "Красный-синий". Должен был быть режим "Красный-голубой". Зелёный канал был потрачен впустую! Да, очень незначительно.
* Архивы. Хотя я сохранил много вещей с тех времен, я хотел бы сохранить ещё больше. В частности больше копий каждой коммерческой игры. Кроме того, было бы неплохо, если бы резервная копия моего жёсткого диска с 1995 года не была уничтожена при перемотке.
Продолжение (десять оставшихся вопросов) в части 3.2 ввиду ограничения в 30000 символов на статью.
