Непроизвольное интервью Эрика Броса

Недавно в реддите произошёл любопытный диалог. Один из разработчиком Minecraft, Эрик Брос (Grum) прокомментировал сообщение о характере предстоящих изменений в Minecraft Java Edition  1.13. После этого, другой участник сообщества, высказал своё недовольство тем как идёт разработка игры и Эрик ему ответил. И вопросы и ответы довольно интересны, поэтому я решил их оформить в виде интервью и предложить вашему вниманию. Поскольку речь не идёт о классическом интервью, мне пришлось переработать и вопросы и ответы и кое-где поменять порядок их следования. Очень надеюсь, что общий смысл от этого не пострадал, но всех кого заинтересовала беседа приглашаю ознакомиться с источником (ссылка, как всегда, в конце статьи).

---

 

Всё началось с того, что один пользователь высказал утверждение, которое нашло возражение у Эрика Броса.

capfan67: [В Minecraft 1.13 будут следующие изменения:] технические возможности (наборы данных, датапаки), исправление идентификаторов блоков и повышение производительности.

Эрик: Откуда люди берут информацию об улучшении производительности? У нас нет каких-то планов, кроме как сохранить всё на текущем уровне!

После этого в дискуссию вступил другой участник — continous, и дальнейший разговор вёлся уже с ним.

continous: Это ужасно! Мы долго ждали переработки движка Майнкрафта, но всё что мы видим — это обновление посвящённое исправлению старых ошибок и очередные костыли!
Сейчас только загрузка и генерация чанков, насколько я знаю, производится в многопоточном режиме…

К вашему сведению, загрузка чанков (как и генерация) не производится в отдельном потоке, как вы полагаете.

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

Использование многопоточности обычно рассматривается как волшебный способ решения проблем, хотя как правило добавляет их не меньше. Безусловно есть вещи, которые нужно перенести в отдельные потоке, но текущая архитектура не  рассчитана на использование многопоточности, и реализация отдельных задач в потоках становится нетривиальной задачей. Мы работаем над разделением задач, если это не вызывает больших проблем, но как правило всегда возникает что-то, что вызывает большие проблемы. Мы определённо должны реализовать работу ряда задач в параллельных потоках: обсчёт миров, генерацию чанков и загрузку различных данных.

А визуальное освещение и уровень освещённости в мире, позволяющий мобам спавниться, — это абсолютно разные вещи. И сравнивать другие игры с Майнкрафтом — это тоже самое что сравнивать яблоки с грушами. Вряд ли общие подходы применимы к Майнкрафту, поскольку здесь сам мир может меняться и постоянно это делает. Большинство стандартных решений основано на предварительных вычислениях множества различных вещей и здесь такое просто невозможно.

Я понимаю вашу мысль, но мне кажется, что вы просто лукавите.  Меняется мир или нет — не имеет никакого значения. Производится ли просчёт освещения заранее или нет — тоже не важно. Трассировка лучей позволяет делать это в реальном времени, даже при наличии множества источников света. Это гораздо сложнее, чем текущая система освещения в Майнкафте. И для этого достаточно ресурсов центрального процессора. Думаю, проблема в том, что просчёт света в Майнкрафте тоже не выделен в отдельный поток.

Многопоточность — это стандартная практика. Это не что-то уникальное или специфичное для какого-то движка, это просто отличный способ увеличить общую производительность. И отмахиваться от него нельзя.

Обычно в играх освещённость не используется для того, чтобы выяснить можно ли заспавнить что-либо в определённой точке. И это одна из основ механики игры, которая не может быть заменена чем-то другим. И это значит, что у сервера всегда будет эта дополнительная нагрузка по расчёт освещённости каждого блока мира.

В соответствии с тем, как устроено освещение в игре, при наихудших условиях, может возникнуть необходимость просчитать целиком до двух чанков блоков, чтобы определить уровень освещения одного единственного блока. Поскольку последовательность расчётов может возвращаться к уже просчитанным блокам, то разделение задачи на потоки тут не поможет. Но даже для мира мира с высотой 256 блоков, даже при возникновении наихудших вариантов, всё работает вполне приемлемо. Расчёт освещения — это не самая большая проблема в игре.

В большинстве обычных игр множество заранее подготовленных вещей: карты освещения, карты взаимодействий, препятствия, уровни детализации данных рендеринга, компрессия текстуры и т.п. Большинство этих техник сложно применять, если у вас есть постоянно изменяющийся мир. Поэтому в таких играх как Minecraft, используют другие или даже уникальные способы решения этих задач. Это, конечно, не является причиной, по которой игра может работать не оптимально, но вносит свой вклад в то, почему решение ряда задач может быть сложнее чем в других играх.

Да, конечно, можно использовать трассировку лучей в реальном времени, но не на том оборудовании, которое мы хотим поддерживать, которое использует порядка 20% наших пользователей. Это значит, что мы должны перейти с OpenGL 1 на OpenGL 2.1 и, возможно, со временем сможем сделать некоторые вещи более эффективными.

Но давайте просто признаем, что освещение — это не корень всех проблем; плавное освещение можно сделать и шейдерами, правда мы до этого ещё не добрались ;)

Согласен. Но уверен, расчёт освещения — это одна из самых простых задач, которую можно решить, добавив в движок Майнкрафта поддержку многопоточности.

Конечно, расчёт освещения можно производить в другом потоке, который выполнялся бы после произошедших изменений всех блоков. Однако есть ещё и сущности, которые, в свою очередь, тоже вносят изменения. Поэтому многопоточность применительно к индивидуальным источникам освещения — это не вариант, всегда будут возникать конфликты при записи в соседние блоки.

Не забывайте, мы по горло сидим в коде, который создавался без учета возможности многопользовательской игры.  В этом коде жестко закодировано всё, что только возможно, включая 256 уникальных текстур для блоков и 256 текстур для предметов, и всё это на основе устаревшего OpenGL 1.4.

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

Просто чтобы завершить картину, у нас 2202 java-файла и две ветви разработки содержат следующее число изменений:

• 3274 модифицированных файлов, 27334 вставок, 28421 удалений (из которых 643 — это отдельные java-файлы);
• 488 модифицированных файлов, 20494 вставок , 13454 удалений.

Так что — да, в настоящее время наша цель состоит не в том, чтобы сделать игру быстрее. Мы стремимся, чтобы всё работало также как и раньше, но уже на более удобоваримом коде.

В последний раз я насчитал не меньше 20 программистов в Mojang. Вы показали порядка 90 000 изменений за 57 дней. Это, грубо говоря, порядка 79 изменений на человека в день. Простите, но это очень жалкое оправдание. 

В настоящее время у нас 5 человек работает над кодом Minecraft Java, и эти две ветви были сделаны двоими из них. Да, в офисе у нас гораздо больше людей, а ещё больше есть в Майкрософте. Но только часть из них работает на Minecraft Java.

И некоторые внутренние изменения, которые произойдут в 1.13, приблизят реализацию этих задач.

Грустно видеть, как изменилось соотношение версий Java и Bedrock.

Ага, над Bedrock’ом работает больше 40 разработчиков.

Вообще, сейчас у нас больше людей работает на Java-версией, чем это было годами ранее и нам всё ещё есть над чем работать. Да, Microsoft сосредоточен на Bedrock, но команда занимающаяся обновлениями Java никуда не делась!

 

Where do people get performance from, that is not the goal other than at minimum keeping it the same!