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

Несмотря на то, что GameDev – тесная тусовка, к своему огорчению я увидел: в GameDev-сообществе в большинстве своем такие же показушные дураки, как везде, они не обладают ни умением, ни желанием разбираться в том, с чем и над чем работают, о чем говорят, только подсирают друг друга на местах, выдавая чужие заслуги за свои.

О рейтрейсинге и видеокартах его поддерживающих

Понятие трассировки лучей появилось в кибернетике задолго до зарождения информатики, 3D-игр и ее использования в качестве метода визуализации. Но мы не будем погружаться в длинную историю, а сразу перейдем к зарождению трехмерных игр, тогда еще 2.5D. Юный Джон Кармак использовал метод рейтрейсинга для обнаружении столкновения выпущенного снаряда со спрайтом персонажа. Именно спрайтом, а не мешем или моделью, потому что псевдо-3D. Без 3D ускорителей игроделы выживали, как могли. 

В самом общем понимании, рейтрейсинг — это математическая операция для вычисления столкновения луча, что в математическом понимании бесконечная прямая, ограниченная с одного конца, другими словами, имеющая точку – определенное начало, с треугольном — базовым примитивом, из множества которого строятся все остальные объекты.

Когда рейтрейсинг стал применяться в качестве способа визуализации еще не существовало подходящих 3D-акселлераторов, поэтому вычисления проводились на центральном процессоре. Трассировка лучей может быть любой по сложности. Если взять упомянутый выше пример со снарядом, это наипростейший случай, так как используется только один вектор. Тогда, как при освещении методом трассировки лучей для создания реального изображения луч, имеющий свойства источника, соприкасаясь с поверхность (определенным пикселем), отдает ей свои свойства, принимает ее и, в соответствии с реальным поведением фотонов, отскакивает в направление к другой поверхности виртуальной сцены. И так продолжается определенное количество раз, зависимое от мощности источника света и многих других условий: затемненности игрового пространства, свойств материалов, с которыми луч соприкасается. В результате, из простого математического выражения образуется сложнейшее уравнение с десятками и сотнями переменных! Необходимо учесть, что освещение — это огромное количество лучей, влияющих на цвет каждого пикселя! 

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

С появлением многоядерных процессоров интерес игроделов к рейтрейсингу вновь проснулся. Теперь можно было поручить выполнение вычислений нескольким полностью равноценным ядрам. Но недолго длилось счастье, вскоре стало очевидно, что даже восьми ядер мало!

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

Плодом этих рассуждений и разработок стала микроархитектура Turing, реализованная в видеокартах Nvidia GeForce RTX 20XX. В ней используются десятки RT-ядер, в задачи которых входит исключительно просчет трассировки лучей. Благодаря их большому количеству, они одновременно просчитывают трассы для многих лучей, из-за чего скорость визуализации с применением рейтрейсинга возросла во много раз!

В итоге, получается, что рейтрейсинг представляет собой алгоритм смешения цветов.

Определение вомглы

Вомгла - потомок зверька писец. Проживает в недрах российской игровой индустрии почти с самого начала 21-го века. Отличительной особенностью вомглы является то, что все будет сделано лучшим образом тогда, когда наступит благоприятный момент. А он все никак не наступает, поэтому вомгла не может творчески раскрыться. Поэтому индустрия вомгле.

GameDev-апокалипсис

Игроделы пожаловались президенту на то, что у них могут отобрать Unity и Unreal Engine, в результате чего они не смогут разрабатывать игры, и наступит gamedev-апокалипсис. Как-будто на этих двух движках средства разработки игр исчерпаны. Для исправления ситуации конкретно этим игроделам нужно много бабосиков и 2-3 года. Во-первых, сколько бы не было у них бабосиков, движок уровня Unity/Unreal они за 2-3 года не разработают. Во-вторых, лишение россиян этих движков равносильно отключению ГитХаба, ибо Unreal частично Open Source, и Windows. А так же удаленной активации инструкций судного дня, что приведет к самоуничтожению процессоров.

Берешь средства операционной системы, плюс, по желанию, DirectX/OpenGL/Vulkan и пилишь свой движок, делов-то.

Не зря я в детстве до появления всех этих фреймворков и движков кодил игры под DirectX и OpenGL. Я знал, это необходимо. Этот день наступит!

Острее стоит проблема недоступности площадок цифровой дистрибуции и невозможность выхода на китайский рынок по причине того, что нам нечего им предложить!

О работе процессоров и выполнении программного кода

По словам Джима Келлера, известного проектировщика процессоров, приложившего руку к чипам в Intel и AMD: независимо от микропроцессорной архитектуры 80% всего рабочего времени процессор выполняет только 8 команд из своего набора инструкций. Эти команды должны быть максимально оптимизированы.

Мои изыскания в области работы процессоров и выполнения программного кода подтверждают его слова: загрузка, пересылка значений, математические операции (сложение, вычитание, умножение, деление), команда сравнения и пара переходов в зависимости от установки битов в регистре флага. Остальное применяется значительно реже.

Индустрия вомгле...

Я тут пишу рассуждения про GameDev. Но если задуматься, мои советы подходят для разработки любого малого или среднего по размеру программного проекта. В большом – вещи приобретают иной оборот.

Об атмосфере внутри команды разработки я уже говорил, поговорим об атмосфере внутри помещения, где эта команда находится. Речь не пойдет о протекании крыши в комнате или о мощности компьютеров для программистов, дизайнеров и моделлеров. Разговор пойдет о поведении сотрудников, самом сотрудничестве и взаимоуважении. Только не надо невоспитанность называть творческим началом. А какой будет конец?

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

Невозможно полноценно использовать свой мозг, когда в комнате находится несколько человек. Каждый из них издает свои звуки, пускай, клацание мышью, печать на клавиатуре, да, хоть дыхание. Ситуация становится еще хуже, когда начинаются перемещения по офису и/или разговоры. Если бы был правильно выполнен этап планирования, никакие разговоры были бы не нужны. За что я люблю удаленную работу, так это отсутствие ненужных разговоров. Я могу временно отключить мессенджер, чтобы никто меня не отвлекал, а вдоволь пообщаться с коллегами во время следующего этапа планирования.

Раздражают моменты, когда сотрудники не только беспричинно ходят по комнате, в которой развертывается разработка видеоигры или какого-то другого проекта, но и без всякой просьбы (или даже разрешения) заглядывают в твой экран, высматривая, что на нем происходит. Совсем выводят из себя последующие комментарии: «А я тоже так смогу». После таких слов охота на этом же месте разбить его голову клавиатурой или чем-нибудь потяжелее. Запустить Unity может и моя бабушка! Кстати, в крупных организациях сотрудники редко позволяют себе такую свободу, в небольших же компаниях подобное случается довольно часто.

Еще одна крайне мерзкая штука, имеющая место быть, когда приходишь в уже длящуюся какое-то время разработку, это сокрытие деталей «ветеранами». Обо всем приходится догадываться самостоятельно, а спрашивать только о том, чего недопонял. Это съедает катастрофическое количество времени! Ведь можно же поступить по хорошему, для вновь прибывшего сотрудника всецело рассказать о проекте, и уже на этом этапе позволить ему задать вопросы про специфические детали. Но у нас все делается через жопу! Создается впечатление, что никто из «ветеранов» не обладает знаниями о проекте, который они разрабатывают! И, чтобы не показывать из себя дураков, разработчики стараются по минимуму обсуждать связанные с проектом вещи. Во время этапов планирования необходимы «тесные» беседы о разных частях проекта, обмен информацией, опытом не только текущим, но и, возможно, полученным во время предыдущих разработок и собственных исследований.