Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт. Можно уволить программиста и на его место придет другой и через условные месяц-два-полгода начнет закрывать таски не хуже. Если увольняется дизайнер, его монстр, пушка или контент повисает без хозяина и без "видения". Если её не перехватил сосед (а у соседа свой монстр), то в большинстве случаев его работа просто уходит в стол и монстра пишут заново на тех же ассетах и принципах, но заново.

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

Что вообще тут делают програмеры?

Когда я получил свою работу мечты в Ea Spb тоже думал, что "вот щас" буду делать игры - нести светлое, доброе и вечное через уникальные механики. Но увяз в куче кода на с/с++, поиске ботлнеков на лоуенд девайсах и получил в саппорт кривой индусский (его действительно в Индии разрабатывали) фреймворк для показа рекламы на 5 дюймах экрана.

Так для примера, код из парсера значений, которые вычитывались из json'a рекламного блока. Пару раз даже менял код, но с обновлениями все возвращалось как было. А лид получил гневное письмо, с просьбой не менять ничего, потому что это будет сложно поддерживать.

if(value1 == "-0")
   value1 = "+0";
 if(value2 == "-0")
   value2 = "+0";

 if(value1 == "-0.0")
   value1 = "+0.0";
 if(value2 == "-0.0")
   value2 = "+0.0";

 if(value1 == "-0.00")
   value1 = "+0.00";
 if(value2 == "-0.00")
   value2 = "+0.00"; 

оттуда же в другой функции, и так было везде - что не открой.

switch (*p) {
    case '0': id += 0; break;
    case '1': id += 1; break;
    case '2': id += 2; break;
    case '3': id += 3; break;
    case '4': id += 4; break;
    case '5': id += 5; break;
    case '6': id += 6; break;
    case '7': id += 7; break;
    case '8': id += 8; break;
    case '9': id += 9; break;
    case 'a': case 'A': id += 10; break;
    case 'b': case 'B': id += 11; break;
    case 'c': case 'C': id += 12; break;
    case 'd': case 'D': id += 13; break;
    case 'e': case 'E': id += 14; break;
    case 'f': case 'F': id += 15; break;
    case 'g': case 'G': id += 16; break;

И на чём?

С++ уже десятки лет без альтернатив является основным языком игростроя. Как он занял свою нишу где-то в начале нулевых, так и остается главным инструментом для создания игр. Выкладывал недавно статью, где описал с какими движками сталкивался для разработки (Не Unity единым…), все что более-менее используется сообществом и развивается написано на плюсах. Весь "кровавый ентрепрайз пота, слёз и пикселей" и подавно.

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

UCLASS()
class UTeaOptions : public UObject
{
    GENERATED_BODY()

public:
    UPROPERTY()
    int32 MaximumNumberOfCupsPerDay = 10;

    UPROPERTY()
    float CupWidth = 11.5f;

    UPROPERTY()
    FString TeaType = TEXT("Earl Grey");

    UPROPERTY()
    EDrinkingStyle DrinkingStyle = EDrinkingStyle::PinkyExtended;
};

TMap<FString, int32> MyMap;
for (auto It = MyMap.CreateIterator(); It; ++It)
{
    UE_LOG(LogCategory, Log, TEXT("Key: %s, Value: %d"), It.Key(), *It.Value());
}

for (TFieldIterator<UProperty> PropertyIt(InStruct, EFieldIteratorFlags::IncludeSuper); PropertyIt; ++PropertyIt)
{
    UProperty* Property = *PropertyIt;
    UE_LOG(LogCategory, Log, TEXT("Property name: %s"), *Property->GetName());
}

// Find first Thing whose name contains the word "Hello"
Thing* HelloThing = ArrayOfThings.FindByPredicate([](const Thing& Th){
  return Th.GetName().Contains(TEXT("Hello"));
});

// Sort array in reverse order of name
Algo::Sort(ArrayOfThings, [](const Thing& Lhs, const Thing& Rhs){ 
  return Lhs.GetName() > Rhs.GetName(); 
});

Но если вы хорошо знаете С, то вас с удовольствием возьмут для перекапывания legacy кода. А еще есть Git, JVM, MySQL, Nginx, PostgreSQL, tarantool, tensorflow и море другого c-кода, которое используется и встроено зачастую в сами игровые движки, функционал этих компонентов тоже надо менять и подстраивать под запросы команды разработки.

Справедливости ради стоит упомянуть, что С все еще используется в движке Unity (наравне с С++), как для написания модулей движка, так и для основной логики. Весь рендер юньки был написан на чистом C. Мои данные могли устареть, с движком я работал в 2014-16, но обычно коркомпоненты движка переписывают в крайних случаях. Как вариант можно пойти работать туда.

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

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

Есть и другая сторона, часто игровому программисту даже ничего и не надо писать вообще. Больше важны навыки тестирования и анализа, улучшения существующего кода из движка, интеграция тулов, обработки данных телеметрии. Какие-то решения и подходы можно взять из других движков или ядра ОС (например linux), на удивление там есть много пересекающихся тем, особенно по управлению ресурсами и памятью. Так, например, если вы используете системный менеджер памяти, то теряете до трети (30%) перформанса, у Unity менеджер памяти вообще самописный по принципу memory arena, у Unreal форк от dlmalloc, Dagor тоже его использует.

Собеседования

Собеседования вообще больная тема из-за отсутствия людей, штаты пылесосят рынок уже третий год, в этом плане европейский игрострой оказался в очень уязвимом положении, потому что не может предложить 1.5-2x зп и вынужден терять разработчиков, и что еще хуже дизайнеров. Гугл конечно может уволить 10к ит-людей, но в игрострое как был дефицит около 70к людей на всех позициях от программеров до арта, так и остался. Проблему с дизами я описал в начале, остается молиться на старичков, лидов и кор команду, которых не так легко перехантить. Вопрос денег здесь уходит на второй план, потому что эти люди уже делают свою игру мечты.

Затравочный вопрос, который обычно задают всем претендентам звучит так:
 — Есть ли доведенные до релиза проекты?

Если ответили нет, считайте что дальше количество кругов собеседования увеличится вдвое. Людей «с улицы» студии берут очень неохотно, есть большая вероятность, что человек сольется через полгода, не зная специфики области. На этом многие обжигались, что и привело к таким странностям.

Второй вопрос обычно:
 — Готов работать с legacy кодом?

Это, напомню, на позицию, где основные задачи будут по написанию нового функционала.

Третий уже как‑то ближе к теме. Звучит обычно так:
 — Готов ли разбираться со смежными задачами вне своей области экспертизы?
 — Согласен заниматься анализом решений/reverse engineering?

Если ответов больше НЕТ чем ДА, то с лидом вы, скорее всего, не подружитесь.

Переработки

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

Как устроиться

Что забавно, на европейском рынке gamedev компаний есть одна любопытная особенность, чем более крупный и известный проект, тем проще туда попасть на практически любую открытую позицию. А на какой-нить стартап или инди разработку из пяти студентов будут гонять по всем темам игростроения, Computer Science, захватят немного звука и AI, а потом выясняется, что компания делает очередной три-в-ряд на Unity. В Arkane на тогда еще начинавшийся Deathloop вместо техревью получил разговор по душам с техлидом (engine team, лид наш соотечественник из Казахстана), а когда пытался договориться о сотрудничестве с Triskell Interactive не спросили разве что, какого цвета глаза у лошади Вронского. И все равно вышло, что моего опыта разработки не хватает для клона одного старого ситибилдера про египет на Unity, может и к лучшему, игру "слили" мобильными механиками и идеями.

Юниттесты

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

Ситуация лучше разве что у Larian/Dice и крупных студий. Они пишут движки, которые изначально исповедуют другой принцип разработки на основе (TDD) или чего-то похожего. Чинить все баги за месяц до майлстоуна и сейчас в порядке вещей, увы. Большие компании еще хоть как-то следят за этим, а средние и инди просто делают игры. Как умеют так и делают. Отчасти это вина многократно ускорившегося пайплайна разработки и мощных движков комбайнов, которые ограждают от возможности выстрелить в ногу, в худшем случае будет сообщение в лог, но игра продолжит работать, хоть и не всегда правильно.

Вот тут lead gameplay Ларианов рассказывает, как они такого добились. Это традиция студии, о традициях ниже.

Но, не все так плохо! Ситуация меняется и к нам пролезают общие механизмы безопасной разработки ПО. В gamedev программисту очень трудно убедить студию начать использовать новые инструменты. Что-то по мелочи - без проблем, новый моник, комп, клаву, смузи утром на кухне. Продавить инструменты статического анализа, если он не встроен в пайплайн, практически нереально, пишите таску на QA.

Отношения с инди-разработчиками

С одиночками еще хуже. Если взять инди разработчика и поместить его в общепринятую модель производства игры, с нашими ежедневными планерками по 5-7 минут, сборке на билдферме, qa-командами, ревью комитов, модульными тестами и прочее, то выяснится, что он (программист, дизайнер, художник) вообще не может решить ни одной задачи. Это не просто слова, в студиях пробовали неоднократно брать ребят с инди-разработки, их приходится переучивать работать в команде и по плану, не всегда это проходит успешно и приходится расставаться, потому что они не смогли в планирование и компромисы, пишут игру как пишется, как делали это во времена дикого игростроя 90-х.

Можете почитать, как делали Казаков.

Традиции

Зато в каждой студии сложился целый пласт традиций. Тут речь идет не о тех традициях, чтобы облить новичка Шато десятилетней выдержки (одна французская компания) или сходить всем отделом в баню и выпить пива (Remedy, эти своей гордятся). Традиции спускаются вплоть до кодстайла, которым пользовались отцы-основатели (отступ с табом в пустой строке после имени функции и кеширование значений в объектах, Unity) или CamelCase, использование префиксов для идентификации типа объекта: "A" для акторов, "U" для объектов, наследующих UObject (Unreal). Хуже, если в традициях узаконены не самые лучшие практики, вроде устных задач, которые могут быть не заведены тасками в jira, или передача таски другому исполнителю без ведома автора (питерская студия, которая делала xcom на мобилки).

Фреймворки и кодовая база.

Тут вообще полная анархия, кроме крупных открытых игровых движков и опенсорс проектов нет доверенной покрытой тестами кодовой базы. Есть EASTL, но не все готовы его использовать в силу нелюбви к EA, платформенные std не любят из-за привязки к вендорам и тормозам. Вроде бы и алгоритмы одинаковые, да вот реализация разная на боксе и плойке. Про злую memcpy на плойке я уже как-то писал, это системный вызов, который проверяет пересечение используемых адресов с защищенными областями памяти консоли. Не готовы что memcpy тормозит? Пишите свою.

Легенды игростроя вроде Кармака, Суини, Кейна так вообще увлекались повальным велосипедостроением. Нужен vector? Давайте напишем свой с преферансом и дамами, и пофиг, что в третий раз. Unity/Frostbite/Unreal/CryEngine/Dagor - везде написаны свои стандартные библиотеки алгоритмов. То есть нет тех самых кирпичей, из которых можно было бы гарантированно собирать работающее переносимое решение, добавьте сюда различия в реализациях под платформы. Нет никакой общей культуры разработки движков (разве что кроме god object, этот шаблон есть везде), нет преемственности, нет общей терминологии. Везде свой фольклор и богатый внутренний мир.

На моей памяти в Unreal уже четвёртая смена идеологии развития, Tim Sweeney - программер старой школы, если вы посмотрите на код образца 2007 года, когда были первые утечки, то движок представлял собой монолит с кучей велосипедов. Потом настал черёд Jim Brown и движок двинулся в сторону стандартных компонентов и унификации кода, но часть великов заботливо припаркована, а про другую вообще забыли. Потом пришёл Nick Penwarden, движок вывели в опенсорс, стали разворачивать анриал в сторону мобилок, что потребовало переделки внутренней архитектуры, наворотили кучу новых фичей и сломали не меньше старых. Сейчас у руля Mike Fricker и движок двигается в сторону плагинов и AI контейнеризации всего до чего дотянутся, посмотрим к чему это приведёт. Все еще верите, что Unreal хороший выбор? Посмотрите на архитектуру clang'a, а потом загляните под капот Unreal. Такое чувство иногда появляется, что его пишут студенты

Привет, сосед

До ковида в основном в офисе, сейчас с разрешения на удалёнке, обычно программист работает в небольших группах по интересам (4-5 человек). Интересы у всех разные, у кого AI, у кого движок и тулы, у кого редактор. Часто задачи перемежаются с соседними отделами и надо разбираться с багом рендера, который внезапно вылез из-за ошибок в загрузке ресурсов, но кадров так на пять десять позже, и колстек к рендеру вообще отношения не имеет. Случайных людей здесь мало, всё начальство программистов в четырёх случаях из пяти - это в прошлом коллеги-программеры из этой же области, о программировании они знают намного больше, но либо выгорели и ушли на админские должности, либо остаются на позициях играющего тренера и решают сложные таски, которые не осиливают другие.

Также они часто уходят в ресерч и реализацию новых технологий, выхлоп от которых будет видно хорошо если через год. Так что готовьтесь часто слышать: "Твой код - @#$%^&" и улетать на респ, т.е. на переделку комита. В силу большого опыта они предпочитают проверенные простые инструменты и скрипты, вместо солюшенов и IDE.

C git'ом, кстати, тоже есть проблема, он хорошо подходит для сорцов, а вот что делать с гигабайтными текстурами или файлами модели по 100мб, или луашником/json'ом уровня размером под 20-30 мб текста? Тут либо держишь 2 cvs - одну для сорцов, вторую для контента, либо пишешь своё решение.

Будьте готовы, что вас не раз ткнут носом в незнание алгоритмов, кодовой базы или традиций студий, слабое знание векторной математики или специфику области. Если ты попал к хорошему лиду, который знает свою область движка, будь готов плакать ночами над комитами, которые вернули в десятый раз. Если выживешь и останешься в отделе, будешь делать движок игры наравне с отцами-основателями. Среднее время работы программиста в студии год-полтора. На группу 40-50 человек, коркоманда составляет 10-15 человек, это люди, которые работают больше 4 лет и являются носителями знаний и технологий, ещё 2-3 техлида, которые определяют, куда движок развивается.

Дизайнеры

С дизайнерами разговор отдельный, дизайнеров надо любить, потому что, как я уже сказал выше, игру делает дизайнер. Разговаривать, учить, помогать, не давать делать @#$%&. Дизайнеры должны быть творческими людьми, иначе игра не получится, даже три-в-ряд. Для дизайнера умение писать стихи и рисовать гораздо важнее, чем умение писать код. Писать код можно научиться, умение писать стихи и делать игры даровано природой.
Дизайнеры придут к вам со своими идеями, вопросами и багами, если дизайнер пишет багу, это уже не его проблема, а программиста. Иногда последней защитой от дизайнера будет только лид, который сумеет объяснить, почему мы так сделать не можем, ну или волевым решением отправить таску в бэклог.

Хорошим дизайнерам вообще прощают очень много, их "код" (BT, скрипты, AI) не изучают, не анализируют, не тестируют. Вряд ли вы услышите от них такие слова как "архитектура", "тесты", "кодревью". Интерес представляет только готовое поведение в игре. Дело в том, что обычно дизайнер полностью отвечает за свою область на карте, логику, пропсы и если заставляют подгонять качество под стандарты, то оно в итоге только ухудшается. Поэтому дизайнеров в студиях ценят выше, чем программистов. Программистов можно заменить дешёво, дизайнера заменить дорого.

Как в итоге пишут код/бт/аи дизайнеры никого, в общем-то, не волнует. Главное - результат. Эта логика никого кроме одного-двух дизайнеров, которые сапортят фичу, не интересует. В одной питерской студии (та, которая xcom на мобилы делала) дизайнер называл функции в скриптах именами героев из "Атаки Титанов" и это никого вообще не волновало, так как кроме него с этим кодом никто не работал. При этом он был на хорошем счету в проекте, и на этот бзик закрывали глаза, равно как и на поздний приход на работу и желание разогреть рыбу в микроволновке в обед.

Школы разработки и их влияние на студии

Из-за соло-разработки движков и принципиальной закрытости и секретности разработки игр, сложились множество различных движкостроительных школ. Можно условно их назвать Unreal/Unity и Housemade/Solo. Причём Unreal/Unity больше распространены в Европе и Азии, а housemade в Штатах. БОльшая концентрация gamedev студий в штатах делала разработку собственного движка одним из знаков качества и статусности студии. Unreal школа больше ориентирована на мелкокомандную работу и модульные проекты, которые легко прототипировать, насобирать асетов и сделать на коленке mvp, а дальше уже разбираться, как придать проекту уникальности. Ответственность разделена между всеми участниками, минимум использования труда программиста в доработке движка, и больше упор в игровые механики.

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

Довелось поработать в компаниях, где применяют оба этих подхода и могу сказать, что возникают серьёзные конфликты между представителями разных школ внутри одной группы, и тут надо искать компромиссы, причём последователи Unreal последнее время побеждают. Это как споры между приверженцами Windows и Linux.

Заметил ещё одну особенность: если студия переезжает на другой движок вместо своего, значит, развалилась коркоманда (https://gamerant.com/cd-projekt-red-explains-using-unreal-engine-5-the-witcher-4/) и в игре не будет оригинальных решений. Это не хорошо и не плохо, просто пришло другое поколение разработчиков, которые не умеют работать со сложными вещами, но умеют делать хорошие игры. И наоборот, если студия начала писать или форкнула один из движков, значит, там выросли спецы, которые умеют писать вещи сравнимые с Unity\Unreal, а зачастую и лучше.

Первая часть Cities Skylines написана на Unity, программисты взяли движок и переписали его под игру. Вторая часть игры написана на ядре Unity 2206 и судя по тому, что я увидел - его даже не пробовали дорабатывать под игру. Проблемы вы видели сами (Почему Cities: Skylines 2 так тормозит), хотя надо было всего лишь сохранить старую команду.

Мало общения на работе

Как правило, на одну фичу сажают одного человека, командная работа в рамках одной задачи затруднена их большим числом. Поэтому программистами в игрострое работают обычно интроверты, мизантропы и социопаты, да простят меня мои коллеги. Общаться с ними не всегда комфортно, порой сложно и приходится идти на компромиссы, а также помнить цвет и особенности тараканов. У большинства программистов напрочь отсутствуют Soft Skills, потому что больше ценятся технические качества и умение решать поставленную задачу, что еще больше культивируется руководством студий приемом в команду суперстаров. Написать в чат в пять утра и обсудить решение бага - в порядке вещей. У меня тоже есть свои тараканы, обычно ревью уходит с апрувом на 5-6 доработку.

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

Промышленная разработка housemade движков в индустрии похожа на времена дикого запада. Каждый шериф строит своих индейцев по-разному и радуется, если они начинают петь в унисон. Каждый раз из проекта в проект шериф начинает героически решать одни и те же задачи. У программистов в gamedev нет менеджера пакетов, нет общих решений, как это повсеместно в ентерпрайзе, или в разработке на Python. Поэтому каждый раз в каждом новом проекте мы вынуждены проходить от первых шагов младенца до Майкла Джексона. Или тащить свое наследие из предыдущих проектов. Вам нужно вытащить данные из influxdb? Извольте написать это сами и желательно на плюсах.

Развитие поколениями

В gamedev, как в деревне, ничего не меняется десятилетиями. Не мы в этом виноваты, что-то действительно новое выходит примерно через поколение консолей, а это 7-10 лет. Что уж говорить, если на плойке до сих пор не полностью завезли 14 стандарт в соневском компиляторе, про свич и мобилки отдельная тема. Постоянный консерватизм в наборе технологий, в то же время взрывной рост стека в моменты смены поколений приводит вот к такому странному состоянию. Что в 2014 в Unity я боролся с ботлнеками на iPhone 4S на загрузке уровня, что сейчас нам не хватает шины ps5 на загрузке сейва. В то же время эта работа требует непрерывно доучиваться чему-либо, чтобы сделать наш массив еще более оптимальным и нереально быстрым.

Девочкам тут не место

Они есть среди дизайнеров, художников, но их практически нет среди разработчиков движков. Могут случайно заскочить на полгода, или появляются по ошибке и недоразумению, но надолго не задерживаются. Знаю профессионалов девушек-программисток в банках, CAD и embedded разработке, не знаю их в gamedev.

Знания и экспертиза

Вы вряд ли услышите такие слова как FrameWork, boost, std::map, std::thread. Более того, если вы попробуете протащить это через ревью, то коллеги строго на вас посмотрят и скажут "Вай-вай, убери это @$%^&, дорогой друг". Фреймворки не возбраняются, но если этого еще нет в движке, то его можно написать и незачем тянуть новую зависимость. Хотя список зависимостей от SDK у движков обычно под сотню разных либ, но это все проверенные временем библиотеки и технологии, которые достигли зрелости, вроде zlib, squish, lua. Главный принцип в разработке - это должно быть быстро и своё. Никаких бантиков и стразиков в движке не будет, ибо это снижает перформанс. У нас тут только один шаблон: это должно работать быстро и только одна абстрактная структура данных - это массив. Все остальное сделано с использованием этих двух компонентов.

Слишком мрачно?

Что-то я всё мрачно описал, на самом деле есть много положительных моментов, которые компенсируют сложности.

В игры играют люди

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

Я тут хозяин

Главное достоинство - это возможность влиять на разработку практически с самых нижних позиций. Вряд ли где-то еще вам дадут поресерчить и переписать реализацию спинлока в готовом движке на котором уже выпущена игра(https://habr.com/ru/articles/689310/), все завязано на ваши знания и умение питчить свои решения. На консолях ближе вашего игрового кода только ОС, есть полный контроль за девкитом (пк пока оставим за скобками), и даже ОС пляшет под вашу дудку. Всё можно измерить, любые параметры снять через SDK и посмотреть, а девкоманда консолей всегда готова помочь с разработкой под свое железо.

Тебя слушают

Работа программистом в gamedev заставляет тебя показывать и доказывать свои решения. Решение, которое тащишь в движок придется защищать перед людьми намного умнее и опытнее. Как я уже писал выше, лиды - это вчерашние программисты, с хорошим бекграундом, которые хорошо понимают код и знают движок. В 8 случаях из 10 никто не будет говорить тебе под руку, что делать и стоять над душой. Поправят на ревью.

Маленький уютный мирок

С момента как я заскочил в большой gamedev в 2014 году, каждый год появляется один-два новых знакомых из разных студий, но и старые связи тоже сохраняются. Все, кто делал игры так и продолжают их делать, несколько людей переметнулись в финтех или совсем в другое, но потом вернулись. Если у вас получилось тут поработать, в других местах будет чего-то не хватать.

З.Ы.

Gamedev-мир отстает от "большого IT". У нас есть все, от систем контроля версий сорцов до сборки из скриптов, есть подобие командной работы, планёрок, авто тестов, но это все свое, домостройное. Зарплаты программистов в gamedev средние по рынку, но ниже чем в WEB(е)/FinTech или enterprise. Если сравнивать создание игр с web/fintech, это как водитель болида формулы-1 и водитель комфортабельного седана S-class. Жесткий кузов, минимум удобств, зато быстро и Шумахера знают все. Но попробуйте уместить всю вашу логику в 15мс, с обработкой четырехсот NPC на уровне, физики, музыки, рендером на экран без просадок фпс.

Все это ради совместного фото команды на релизе игры и твоего имени в титрах. Приходите в gamedev, тут делают игры.

З.З.Ы.
Много в личку спрашивают как устроиться. Пишите письма напрямую в студии, даже если там нет приглянувшейся позиции. Людей всегда не хватает, а задач всегда много, впрочем как и везде в IT. ЗП, говорить могу только за себя. Если нет опыта, шипнутых проектов и горят глаза соглашайтесь на то, что дают (спорно конечно). Отработаете полгода-год и поймете что к чему, как правильно сказал @Eltayв коментах.

Зарплаты - да средние по рынку, но найти компанию с достойной оплатой в целом реально. Хотя золотых гор вы тут не получите в найме.