Мой тернистый путь в «Разработке Игр»
Этой статьёй я бы хотел рассказать свой небольшой опыт поиска работы и непосредственно самой работы в области разработки игр, в частности игровых движков. Может быть статья поможет тем, кто только собирается войти в эту область, понять, что эта область имеет свои особенности и многое может казаться слишком романтизированным.
ВНИМАНИЕ! Дальше вас ждет простыня текста без юмора. Душнилово так же присутствует. Я не буду называть некоторые компании, в том числе и ту, в которой я работаю сейчас, чтобы, если меня понесёт, я не переписывал статью. Из песни слов не выкинешь. Позже, когда уволюсь, отредактирую добавив название компании. По тем же соображениям, чтобы ненарушать права на интеллектуальную собственность я не выкладываю куски кода, о которых пишу в статье. Опять же в будущем может быть добавлю.
Я сам люблю игры. Всегда интересовался разработкой игр. Какой-то период времени плотно занимался моддингом игр (но в то время интернет был по карточкам, поэтому многие мои моды потерялись на поломанных жестких дисках старых компьютеров). Half-life, Max Payne, Quake, Doom, Unreal, Morrowind, Neverwinter Nights (и все продолжения этих игры в том числе) — только малая часть тех игр, над которыми я «издевался». Поэтому желание состряпать свою игру у меня было всегда. Но были проблемы. Лень одна из них. Хотя она не мешала, это скорее больше влияло на то, что я каждый раз откладывал свой путь в «Разработку Игр». Типа «есть ещё время», «успею». И потому полноценно в разработку игр я влился только в 2020 году. В ковид от дикой скуки. До этого я продолжал заниматься экспериментами с модами, и тыкал в некоторые игровые движки. Но не было полноценных результатов, так как моды я не доводил до рабочего состояния, когда их можно было бы закинуть на тот же, известный среди модеров Nexus Mods. А игровые движки часто требовали серьезного изучения, чтобы получить первый вменяемый результат. То есть нужно было вкапываться в документацию и (или) в исходный код для понимания того, как начать в них что-то делать. Это сейчас даже raylib можно взять с наскока, так как порог входа на низком уровне, а в былые времена для того же Allegro требовались недели экспериментов, чтобы понять как и что работает. И часто именно «горящие глаза» энтузиазма не давали мне забросить работу над изучением очередного движка. К слову упомянуть, что в итоге я всё же забрасывал изучение, и полноценных знаний я не получал. Но получаемый опыт оседал в голове.
До 2020 года я занимался опенсорс проектами. Я контрибьютил в разные проекты, один из которых был форком проекта распознания лиц на видео для создания анимации YerFace. Сам форк уже в 2021 году сгинул. Автор проекта из-за стагнации оригинального проекта не стал брать на себя ответственность за развитие, и я сам так и не понял почему он сделал форк, так как различий с оригинальным проектом было мало. Мой вклад был мизерный, я интересовался больше областью распознавания лиц, нежели анимацией, так как на работе в то время я занимался проектом распознания людей по видео. Руководство компании, в которой я тогда работал хотело по видеонаблюдению видеть, кто из работников где находится. И для этого создавалась система расползания. И из-за этого я влился в некоторые опенсорс проекты, чтобы увидеть как это реализуют другие. Но с анимацией я всё же имел дело и там была компьютерная графика.
В это время плотно познакомился с OpenGL. Оказалось, что OpenGL не такой уж и сложный API (в ретроспективе можно уточнить, что по моему мнению OpenGL самый простой API из существующих). Я для себя тогда сделал замечание, что только моя лень раньше не давала мне прийти к написанию своей игры. Ничего не мешало. Проблемой был только я сам. И в 2020 году я взялся за написание своего игрового движка. Я уже тогда понимал, что это очень амбициозный проект. И таких «амбициозных», как я, сотни. Тот же GitHub полон игровыми движками разной степени готовности. А уж сколько их в «столах» на домашних компьютерах можно только догадываться. И поэтому может показаться странным, что я не взял готовые решения, или не совсем законченые. Это же проще, с учётом моих же слов выше о лени. Но тут всё стало несколько сложнее. Я хотел сделать игру. Но на пути к своей игре, я так же ставил цель набраться опыта разработки. Но не только игровых движков, а сложных проектов в общем смысле. Столкнуться так сказать с проблемами, которые помогли бы мне в понимании собственного уровня как программиста. Это было связано с тем, что в тот период я работал в компании, где программисты были не разработчиками, а в большей степени поддержкой существующей кодовой базы. И многие проекты были маленькими и локальными. И я не занимался полноценной разработкой, только доработкой. У меня было желание развиваться, чтобы не стагнировать. Поэтому и появился проект игрового движка с учётом его «сложности». Это дало свои плоды. Я на работе с нуля разработал два программных продукта. Что для меня было уже шагом вперёд. Но мои рабочие проекты к тому времени были никому не нужны. Под конец сотрудничества с той компанией в 2021 году произошли изменения. Случился управленческий кризис. И я принял решение менять работу. Оставаться на той уже было нельзя, если бы я хотел дальше развиваться, как программист. Руководству нужен был специалист поддержки проектов, и видело во мне именно этого специалиста. Стоит упомянуть, что этот социальный лифт тоже выглядел неплохо. Потому что дальше по должности руководитель отдела, подразделения и там да заместителя директора недалеко. Но это хорошо выглядело только со стороны. Знакомые с работой в гос. учреждениях или подрядчиками для них уже понимают, что я имею в виду. Поэтому оставаться там было бы ошибкой.
Когда я менял работу, я искал чисто программистскую должность. И искал я в основном в компаниях, которые занимались разработкой программных продуктов. И на тот момент для меня не было принципиальной разницы в какую компанию идти. Я в любом случае был бы для них джуном. Но выйдя из предыдущей компании оказалось, что мой опыт настолько маленький, что уровень джуна мне можно было давать с большой натяжкой. То чем я занимался на прошлом месте работы было каплей в море тех задач, с которыми я должен был сталкиваться в нормальной компании. Так я считал, когда проходил собеседования. И каждое новое собеседование только сильнее ломало мою самооценку. Это сейчас я знаю, что всё это было «игрой», в которую нужно «сыграть» с HR, чтобы пройти их отсев. Так как на новом рабочем месте действительно сложных и интересных задач оказалось не много. Но во время поисков работы у меня даже в какой-то момент стала появляться мысль, что я сделал ошибку уволившись с предыдущего места работы. Эти мысли порочны и ошибочны. Спустя несколько месяцев поиска я вспомнил о том, что я всё же хочу сделать игру. Мысль о своей игре не оставляла меня долгое время. И поэтому я решил, что раз уж я всё равно ищу работу, то почему бы не пойти в разработку игр. До этого момента я вообще не рассматривал вакансии в компаниях разрабатывающих игры. Мне тогда казалось, что это не то чем я хотел заниматься. Так как разработка своей игры для меня была на уровне хобби. А сам я хотел заниматься разработкой прикладных программ с GUI в большей части. Мобильная разработка была в интересах, но на тот момент мой уровень в ней был невысок. И относительно провалов на собеседованиях по разработке для ПК, где меня рвали на части, в мобильной разработке я бы вообще был бы никем, в лучшем случае на уровне «вайтишника» с сертификатом за трехмесячный курс. Поэтому я начал искать вакансии уже конкретно в области разработки игр.
Мне не повезло. 2022 год начался «великолепно». Я именно в период начала СВО искал работу. И больша часть неудач можно, наверное, списать из-за этого. Рынок схлопнулся моментально. Я в режиме «реального времени» видел, как вакансии исчезают из агрегаторов. Вакансии для джунов исчезали самыми первыми. Была полноценная борьба за рабочие места. И я тогда чётко понял, что нужно быть более настырным. Браться за все тестовые задачи, каким бы они странными не были, так как это давало мне возможность увидеть свои слабые стороны, а значит я должен был эти места подтянуть. К примеру, одним из заданий было написать игру Арканоид за четыре часа. Такое задание мне выдали на собеседовании в Gaijin. Мне был представлен исходный код тестового движка. И я не справился. То есть что-то я написал, но полноценным арканоидом это не назвать. Можно ли написать полноценный арканоид за четыре часа? В теории можно, но только если уже такое делал ранее. А когда делаешь это впервые, да ещё и на движке который так же видишь впервые, то четыре часа это мало. Но я решил проверить свои силы. Можно было пойти другим путём, договорится об увеличении срока. Пошли бы на это с стороны рекрутеров? Я не знаю. Есть предположение, что врядли. Так как джунов много. Один не «справился» — найдётся другой.
Другим заданием было создать игру в Unity с определенной игровой механикой. С Unity я был знаком. Я уже не помню название компании, которая выдала это задание, но раньше, до собеседования, я видел это же задание в интернете, и даже видел в телеграм каналах по Unity вопросы о готовом решении этого задания. То есть я был не первый, либо просто разные компании хотели одного и того же — скопировать успешную игровую механику, под которую набирали команды. И в этот раз я то же не справился. Я не стал копировать те решения, которые я нашел в интернете. Я заданием проверял сам себя. Было ли правильным решение не копировать чужой код? Возможно нет. Так как, взяв чужое решение, поменяв кое-что, я мог бы уже тогда получить работу. Но всё же, получив работу, за меня будет её выполнять не другой человек, а я сам. Проверяя себя я пытался понять потяну ли. И понимал, что нужно свои силы рассчитывать. Проблема с этим заданием была в том, что задание я понимал буквально. В разговоре с рекрутером было оговорено, что нужно повторить игровую механику точь-в-точь. А повторить её так, как она выглядела на видео, которое мне предоставили, как референс, я не смог. Я честно написал, что выполнить задание не удалось. На этом общение в этим рекрутером сразу прекратилось. Что понятно, какой смысл тратить время на кандидата, который не справился. Я мог бы быть более настойчивым, что задание я выполнял, вот результат, но само общение мне понравилось, поэтому не стал продолжать.
Я после этого абзаца напишу ещё о собеседованиях в игровые компании подробнее, но вы не подумайте, что их было мало. Этим абзацем я немного отдохну и соберу мысли. Собеседований было много. Общее количество всех собеседований за всё время поиска работы переваливало за 100. То есть джунам всегда найти работу было сложно. Не невозможно, но много сложнее. Особенно тем, кто из глубинки ищет работу на удалёнке. Особенно в то время — начало СВО. И я читал советы, в которых описывали, что сто собеседований это ещё только начало. На некоторые позиции конкурс 1000:1, отсев дикий. И, например, в тот же Сбер в то время хотели попасть все. Там платили очень жирные деньги по меркам рынка того времени. И не пытаться туда попасть было бы глупо даже с учётом огромной конкуренции. Я пытался попасть в VK, Касперский, 2Гис, Авито. Список крупных IT-компаний был большим. Даже Яндекс фигурировал. И я пытался попасть в эти компании не сколько из-за денег (не в последнюю очередь), но из-за того, что там предлагали удалённую работу даже джунам. Это было не во всех подразделениях, но в некоторых. Для людей из глубинки это огромный плюс, так как желание связать свою жизнь с IT в таких местах разбивается о реальность, что нет вакансий. Чтобы найти работу нужно переезжать в крупный город, областной центр, столицу региона, либо искать удалёнку. Я же в тот период не мог переехать (не было денег), хотя ряд компаний готовы были меня взять на работу с условием моего переезда в город с их офисом. Поэтому я мог рассчитывать только на удалённую работу. Были и другие варианты. Но на тот момент для меня это было, фактически, как шаг назад. Который я не хотел делать.
Третье запомнившееся собеседование в игровую компанию было в компанию Playrix. На нём я делал игру типа арканоида, но с немного другой механикой, больше похожей на механику игры Space Invaders. Игру удалось сделать, так как времени на выполнение дали достаточно (две недели). Но техническому специалисту не понравился результат, либо просто они уже к тому времени нашли подходящего кандидата, а мне просто не хотели резко отказывать, что то же понятно. Истинные причины для меня неизвестны. Я лишь получил обратную связь. И тут стоит упомянуть, что общение с рекрутерами Playrix было одно из самых адекватных и приятных за все собеседования, пройденные мной. Таким же по уровню было общение с VK. Но в VK я жёстко провалился, так как это было одно из первых собеседований. Я тогда ещё не умел правильно собеседоваться. О Playrix я ещё упомяну ниже.
Но не всегда всё шло гладко в общении. Например, компания Unigine вообще отказывала сразу без каких-либо этапов общения, а у них в вакансии был флеш рояль: джун, удалёнка и всякие плюшки. Упомянутая ранее компания Gaijin давала долгий ответ на вопрос уже после провала собеседования. Я хотел получить разрешение разместить скриншоты сделанной игры в портфолио. Ответ пришел спустя четыре дня, что упоминать о том, что это было задание на собеседование в компанию нельзя по соглашению. По какому соглашению я так и не понял. Так как я ничего не подписывал. Но раз уж их так заботило это, то я ни стал использовать готовый результат.
Последнее собеседование, после которого я получил работу я практически не помню. Помню только то, что я изначально его провалил, игру я делал на SFML, и то, что мне не давали обратную связь. Что за игру я делал я не помню. Даже исходников не нашёл, ни в переписке, ни в своих бекапах. Обратную связь я попросил самостоятельно отдельным письмом. Это один из самых важных моментов, правильный, я бы даже добавил — спрашивать рецензию за выполнение задание и обратную связь на пройденное собеседование. Ответ я получил быстро, но полученный ответ был фигней, практически отпиской. И к нему я написал, что советы, которые мне дали в обратной связи, хрень полнейшая, эти советы ничего мне не говорят, ни от том, как прошло собеседование, ни о том какие ошибки я совершил выполняя задание. После чего меня позвали на второе собеседование, где меня взяли на работу. Для меня это было удивлением. То ли моя прямолинейность и наглость взяла верх, то ли им отказал другой кандидат. Но всё прошло буквально за два дня. Это удивляет.
И тут стоит вернуться к моему желанию сделать игру. Свой движок я так и не дописал до сих пор. К времени последнего собеседования я третий раз пересоздавал репозиторий на GitHub с кодом своего игрового движка. Всё потому, что несколько раз рефакторил код движка, узнавая новые «методики» написания движков, которые я тут же хотел попробовать в своём. Из-за чего он становился всё более запутанным. И чтобы как-то привести его в нормальный читаемый вид, я удалял старый репозиторий и пересоздавал с новой структурой, чтобы на собеседовании можно было показать более менее рабочий вариант. И при этом, чтобы его старые варианты не мешали. И вы правильно заметите, что теряется суть контроля версий, что можно было бы создать отдельные ветки. Всё верно. Я тогда знал о git, мог им пользоваться, но не имел серьезного опыта работы с ним и его разными подходами к разработке в несколько веток. И потому не доконца понимал логику веток и их удобство. Сейчас всё иначе. Хотя я уже к fossil больше проникаюсь симпатией. Сейчас, поработав в большой команде я научился работать с большим, постоянно меняющимся кодом с кучей (около 30) веток.
Я снова перестал работать над своим движком. Отложил его, потому что новая работа начала отнимать свободное время. Это было моё личное желание быстрее вкатиться в работу и понимание того как всё в новой компании устроено. За тот период я понял, что оказывается я структурировал код своего движка нормально. То с чем я столкнулся было куда хуже. И я был поражён, так как компания существует не один год на рынке. Единой структуры в движке не было. Старые версии движка находились в той же папке исходного кода, что и текущий, никто не удалял его оттуда просто потому, что никто не понимал почему этот код находится там. Считалось, что если он там, то значит он кем-то используется. Только спустя время, когда начался рефакторинг кода и повсеместное использование git для версионирования, стало понятно, что старые версии кода никем не используются. Здесь стоит упомянуть Playrix, код движка которого ставили в пример. Я лично сам его в глаза не видел, но коллеги, которые работали в Playrix до текущего места работы отмечали, что движок Playrix очень хорошо структурирован и имеет удобную и подробную документацию. Уж простите, что раскрываю такие подробности. Но я считаю, что так должно быть везде. И мне [не] повезло работать с движком, у которого очень много пустых мест в документации, а та, что есть обновляется очень редко. У меня были задачи, где я как археолог или спелеолог спускался в глубь движка снимал слой за слоем абстракции для того, чтобы понимать, что вообще происходит. Так, например, я возненавидел директивы #define, которые в одном куске кода стреляли в ногу, но в совершенно случайный момент. Поэтому поймать эту проблему было невероятно тяжело. И что самое интересное. Визуально кусок кода показывал проблему, что падение должно было происходить каждый раз при выполнении этого кода. Но не происходило. И это как раз поражало больше всего. Будто оптимизации во время компиляции несколько меняли выполнение, что приводило к такому странному поведению.
То есть за время работы на текущем месте я получил большой опыт работы с плохим движком. То, как не нужно делать. И это с одной стороны хорошо. Опыт. С другой стороны — плохой код усложняет работу с ним. Очень серьёзно. И эта особенность сильно мешает выполнять задачи в короткие сроки. Некоторые задачи просто не возможно выполнять в сроки, которые хотят руководители. Это приводит к тому, что некоторые задачи выполняются плохо, ухудшая и без того плохой код. Растёт технический долг. Из-за чего растёт время выполнения задач. Но время на выполнение новых задач не увеличивают. Что приводит к ухудшению результата выполнения задачи. И так далее. Всё взаимосвязано. И это ещё только работа с кодом в движке. Становится [не] интереснее, если описывать работу, когда движок используется для создания продукта. Эта область может вообще никак не быть связана с движком. Так как в некоторых игровых движках взаимодействие с движком может происходить на уровне дополнительной абстракции в виде скриптового языка, который сам выполняет требуемое в продукте. И разработчики игры (гейм-дизайнеры) могут не понимать как работает движок. То есть движок выступает в роли черного ящика. И здесь может быть проблема, когда ошибка движка наложенная на ошибку в скрипте порождает конфликт интересов. Решить проблему на уровне движка нельзя, так как это может затронуть работу всех, растянет сроки выполнения задач. Решить проблему на уровне скрипта не хотят, так как раньше (год-два назад) этот же скрипт работал. Такое было в моей практике, и не раз.
Большая часть работы в игровой индустрии — банальная рутина, которая при отсутствии удобного инструментария может сильно портить желание ей заниматься, но понимая, что за эту рутину платят деньги, ей продолжают заниматься несмотря на «боль». Инструментарий это самое важное. В любой профессии. Хороший инструмент залог приятной работы. Но бывает так, что из инструментария только приложение «Блокнот» в Windows. С ним можно писать программы, но не очень удобно. Я только могу посочувствовать тем, кто занимается написанием скриптов для игр без удобного инструментария. Или, например, платформа Android. Её официальный инструментарий Android Studio. Для не просвещенных это один из самых конфликтных IDE с которым мне приходилось работать. Я читал о том, что XCode называют худшим, но для меня Пальму Первенства держит именно Android Studio. И это единственный IDE для системы Android. До недавнего времени был Visual Studio, но они свое решение пометили как deprecated.
Это я к тому, что некоторые считают, что разработка игр это весело. Но это не всегда так. Весело это тогда, когда интересно этим заниматься. Это относится вообще к любой работе. Но интерес может быстро пропасть, когда приходит понимание, как например у меня, что нельзя исправить проблему (или проблемы), так как исправление проблемы долгий процесс, который повлияет на работу коллег, который займёт время, и на это не дадут разрешения и даже не будут выделять время, так как важнее выпустить продукт на движке, а не исправлять движок. И с этой проблемой придётся жить дальше. Эта проблема будет только мешать каждый момент взаимодействия. И можно было бы сделать «грязный» трюк, исправить проблему никому не сказав. Это работает, когда оно на самом деле исправит проблему и будет незаметно для всех коллег. Но бывает и так, что так сделать не получится. Исправленная проблема может обнажить скрытые проблемы, которые только усугубят ситуацию. То есть без гарантий успеха инициатива в особо плачевных ситуациях может быть отплачена отрицательным балансом.
Сейчас я уже не трачу свободное время на работу. Так можно делать только на страте карьеры, чтобы быстрее войти в работу на новом месте работы. Но никогда не проявляйте это перед руководством, так как хорошим это может не кончится. Выгорание это не пустые слова. Важно не терять интерес к работе, потому что это сильно скажется на вашей же производительности. Сейчас я трачу свободное время на разработку своих игр. Спустя столько лет. Здесь я сбрасываю рутину, и как раз получаю то веселье, которое не достаёт на работе. Я решил отложить разработку своего движка дальше во времени. Так как решил, что пока поизучаю другие движки (raylib, godot), чтобы понахватать в них интересных решений, чтобы можно было снова сесть и зарефракторить свой. Raylib, кстати, я очень рекомендую для использования тем, кто хочет написать свою игру, без использования больших игровых движков. Порог входа этой библиотеки относительно низкий, а большое количество существующих биндингов позволяет использовать её на разных языках программирования. Так же я начал изучать новые для себя языки программирования. Один из которых Zig. Я о нём пару статей выпустил здесь на Хабре. Занятный язык. На текущем месте работы я прокачался в kotlin. То есть даже в самых плохих ситуациях я получал опыт, чтобы он помогал в дальнейшем.
На этом всё. Спасибо, что дочитали
