Мао Цзэдун: «Революция – это не званый обед, не литературное творчество, не рисование или вышивание; она не может совершаться так изящно, так спокойно и деликатно, так чинно и учтиво. Революция — это восстание, это насильственный акт одного класса, свергающего власть другого класса».

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

Несмотря на то, что 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 может и моя бабушка! Кстати, в крупных организациях сотрудники редко позволяют себе такую свободу, в небольших же компаниях подобное случается довольно часто.

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

Планирование и отчетность

Сами по себе планирование и создание отчетов игру не разработают, скажу больше, они не помогут ее разработать и к этому даже не стремятся. Планирование стоит рассматривать, как организацию последовательности стадий или задач (тасков) в разработке. Это последовательная запись предстоящих задач с упорядочиванием по срочности и важности. Процесс разработки видеоигры — длинная вереница сложных задач, преследующих одну цель. Поэтому планирование должно стать неотъемлемой его частью. Необходимо документировать каждую стоящую реализации мысль. Без этого не получится создать сколько-нибудь сложную интерактивную историю — видеоигру.

Создание, написание отчетов, как мне кажется, менее важное занятие. При правильном планировании, отчет почти полностью вытекает из плана, не требуя переделывания или переписывания. И во многих случаях сводится к перетаскиванию таска из столбца To-do в столбец Completed системы управления проектами. Я приветствую подробные отчеты о выполненных заданиях, особенно, когда последние имеют специфическую природу, а их решения потребовали значительные промежутки времени. В то же время, написание отчета не должно выполняться из-под палки и демотивировать разработчика. Также не должно быть написание отчета ради написания отчета, другими словами, должна быть реальная оценка труда разработчика, а не размера написанного им отчета. Приятно оформленный, хорошо написанный отчет может помочь самому разработчику, его написавшему, через несколько недель/месяцев вернувшегося к этому блоку кода/задаче для изменения/модификации или в решении подобной задачи в будущем.

GameDev в одиночку

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

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

Разработка игр в одиночку? Уже не кажется такой безумной идеей.