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

ВНИМАНИЕ! Дальше вас ждет простыня текста без юмора. Душнилово так же присутствует. Я не буду называть некоторые компании, в том числе и ту, в которой я работаю сейчас, чтобы, если меня понесёт, я не переписывал статью. Из песни слов не выкинешь. Позже, когда уволюсь, отредактирую добавив название компании. По тем же соображениям, чтобы не нарушать права на интеллектуальную собственность я не выкладываю куски кода, о которых пишу в статье. Опять же в будущем может быть добавлю.

Я сам люблю игры. Всегда интересовался разработкой игр. В детстве я посещал кружок программирования в местном Доме Детского Творчества. Там я написал первую игру ещё на БК-0010. Но это была не моя игра. Я скопировал чужой код. Так нас учили программировать. Хотелось написать, что мой путь программиста начался оттуда, но это не так. По настоящему заниматься программированием я стал только в 2015 году. До этого я скорее проявлял интерес к этому, при этом, в 2008 году, учясь в ВУЗе на кафедре Информационных технологий я посещал курс Программирования на C++. То есть тогда программированием я не грезил, а вот играми очень. И какой-то период времени плотно занимался моддингом игр (но в то время интернет был по карточкам, поэтому многие мои моды потерялись на поломанных жестких дисках старых компьютеров). Half-life, Max Payne, Quake, Doom, Unreal, Morrowind, Neverwinter Nights (и все продолжения этих игры в том числе) - только малая часть тех игр, над которыми я «издевался». Я делал карты и модельки оружий (отвратительного качества) на Counter-Strike. Поэтому желание состряпать свою игру у меня было всегда. Но были проблемы. Лень одна из них. Хотя она не мешала, это скорее больше влияло на то, что я каждый раз откладывал свой путь в «Разработку Игр». Типа «есть ещё время», «успею». И потому полноценно в разработку игр я влился только в 2020 году. В ковид от дикой скуки. До этого я продолжал заниматься экспериментами с модами, и тыкал в некоторые игровые движки. Но не было полноценных результатов, так как моды я не доводил до рабочего состояния, когда их можно было бы закинуть на тот же, известный среди модеров Nexus Mods. А игровые движки часто требовали серьезного изучения, чтобы получить первый вменяемый результат. То есть нужно было вкапываться в документацию и(или) в исходный код для понимания того, как начать в них что-то делать. Это сейчас даже raylib можно взять с наскока, так как порог входа на низком уровне, а в былые времена для того же Allegro требовались недели экспериментов, чтобы понять как и что работает. И часто именно «горящие глаза» энтузиазма не давали мне забросить работу над изучением очередного движка. К слову упомянуть, что в итоге я всё же забрасывал изучение, и полноценных знаний я не получал. Но получаемый опыт оседал в голове.

Как упоминалось выше, программированием я стал серьезно заниматься в 2015 году. Тогда я устроился на новую работу, где я по своему собственному желанию начал создавать программы. Это не было моей должностной обязанностью. Но подразумевалось по должности «Инженера автоматизации». Почему такое несоответствие требованиям я опишу ниже. В период работы на этой должности до 2020 года я более значимо для себя занимался поддержкой опенсорс проектов. Я контрибьютил в разные проекты, но важным для статья является один из них, который был форком проекта распознания лиц на видео для создания анимации YerFace. Сам форк уже в 2021 году сгинул. Автор форка из-за стагнации оригинального проекта в 2020 году не стал брать на себя ответственность за развитие, и я сам так и не понял почему он сделал форк, так как различий с оригинальным проектом было мало. Мне тогда казалось, что автор форка хотел развивать проект, поэтому я влился в него. А возможно он просто хотел скопировать готовый продукт и коммерциализировать его. Тут, я честно признаюсь, правды не знаю. Мой вклад в форк был мизерный, я интересовался больше областью распознавания лиц, нежели анимацией, так как на работе в то время я занимался проектом распознания людей по видео. Руководство компании, в которой я тогда работал хотело по видеонаблюдению видеть кто из работников где находится. И для этого создавалась система распознания. Именно из-за этого я влился в некоторые опенсорс проекты, чтобы увидеть как это реализуют другие. Но с анимацией я всё же имел дело, когда изучал код форка YerFace, и там была компьютерная графика.

В это время я плотно познакомился с OpenGL. Оказалось, что OpenGL не такой уж и сложный API (в ретроспективе можно уточнить, что по моему мнению OpenGL самый простой графический API из существующих). Я для себя тогда сделал замечание, что только моя лень раньше не давала мне прийти к написанию своей игры. Ничего не мешало. Проблемой был только я сам. И в 2020 году на волне опыта работы с OpenGL я взялся за написание своего игрового движка. Может показаться, что это уже сотни раз обмусоливали. И таких «амбициозных», как я, сотни. Тот же 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. То есть даже в самых плохих ситуациях я получал опыт, чтобы он помогал в дальнейшем.

Вместо выводов я бы хотел дать совет. Не останавливаться. Если у вас есть цель. Достигайте её. Я бы мог в статье написать о том, что создавать игры была моей мечтой, но в моём случае это не так. Я хотел делать игры, но не мечтал об этом. Только дойдя до цели вы поймёте нужно это вам, или вы просто подверглись мимолётному желанию. Может так сложиться, что повседневные заботы занимают всё время, отодвигая вашу цель всё дальше. И может показаться, что это не то, что вы на самом деле хотите. Типа, раз вы сами не находите время для достижения этой цели, значит это вам на самом деле не нужно. Но это может быть ошибкой. Выражение «догору осилит идущий» здесь вполне подходит. Нужно начать движение к цели. Мой путь до разработки игр оказался очень длинным, но всё же к этому я пришёл. Важно не забрасывать.

На этом всё. Спасибо, что дочитали

update:

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

Комментарии (25)


  1. Poitreqm
    18.10.2023 05:59

    что можете сказать про Unreal Engine?


    1. AnimeSlave Автор
      18.10.2023 05:59

      А что вы хотите узнать?


      1. Poitreqm
        18.10.2023 05:59

        Ваше мнение о нем или вы его не щупали?


        1. AnimeSlave Автор
          18.10.2023 05:59
          -1

          Я могу только общими фразами описать. У меня лично отрицательно отношение к Epic Games. Они похоронили серию Unreal Tournament. Из-за чего я не много уделял внимания движку. А когда его пробовал, могу написать, что он очень мощный. В этом его как положительная черта, так и отрицательная. То есть делать на нём что-то уровня AAA по графическому наполнению в самый раз, а вот уже что-то простенькое уже слишком громоздко, функционал движка будет простаивать. Мне понравилась концепция Blueprint. Сильно упрощает работу


        1. MrBrooks
          18.10.2023 05:59
          -1

          8 лет за ним. Отличный движок, вакансии есть, платят хорошо. Программистам особенно. Не вникайте в слова этого человека.


  1. AndrewAlexArt
    18.10.2023 05:59
    +3

    Перестаю читать полотна о том как "я хотел делать игры" когда вижу "начал с написания своего движка" :D


    1. AnimeSlave Автор
      18.10.2023 05:59
      -1

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


      1. danil_gazizov
        18.10.2023 05:59

        Создание игры - это не создание движка


        1. AnimeSlave Автор
          18.10.2023 05:59

          Зависит от того, что вы делаете. Точнее как вы делаете игру. Если вы используете готовый игровой движок, и пользуетесь его интерфесами для работы с ресурсами будущей игры. То да, вы правы. Вам не нужно создавать движок, так как он уже есть. Но, если вы используете графическую или мультимедийную библиотеку (типа SDL, SFML, raylib, ClanLib, Allegro, сотни их, или, вообще что-то типа GLFW) и с нуля формируете внутренние процессы загрузки и использования игровых ресурсов, взаимоотношения игровых объектов в коде, создание, хранение и загрузка уровней и тд., то вы фактически вместе с игрой пишете игровой движок. И если для вас это будет новостью, но некоторые разработчики игр так и делают. Они разрабатывают движки под конкретную игру сразу в процессе разработки игры


          1. wavan2012
            18.10.2023 05:59

            Я всю свою жизнь мечтаю создать игру, к сожалению при поиске инструментов для её создания я пришел к выводу что мне прийдётся делать движок самому, есть советы?


            1. AnimeSlave Автор
              18.10.2023 05:59
              -1

              Для начала мне нужно понять, что вы конкретно хотите сделать и что вы умеете, чтобы дать более конкретный совет.

              Моё желание сделать игровой движок было связано больше с желанием опыта поднабраться. Типа выстроить путь [программирование] -> [игровой движок] -> [игра]. И на каждом этапе улучшить знания. Сейчас я пишу игры на других движках. Не на своём. Так как того, что мне нужно достаточно на том же godot. И с недавних пор взялся за raylib, чтобы попробовать идею генерации игровых звуков на лету. Эту же идею я намереваюсь в будущем перенести в один из проектов на godot. То есть у меня есть определённые цели


              1. wavan2012
                18.10.2023 05:59

                Ооо, я мечтаю стать программистом, но по воле судьбы отучился на преподавателя физики и информатики, прошел онлайн курсы по QA automation на Java, сейчас прохожу по Data Science, играми никогда не занимался, но у меня есть несколько книг на тему их разработки, в данный момент отрабатываю бесплатное образование в связи с тем что живу в Беларуси


                1. AnimeSlave Автор
                  18.10.2023 05:59

                  Если вы хотите стать программистом, то мой совет прост. Программируйте. Это как с рисованием. Хотите научиться рисовать - рисуйте. И чтобы стать хорошим художником нужно много практики, экспериментов со стилями. При этом в программировании работают те же правила, что и в рисовании. Чтобы понять как правильно - копируйте чужие работы. Анализируйте результат. Обращайтесь к опытным коллегам за советами и помощь, если не понимаете что-то. Сейчас с наличием интернета и доступностью информации нет проблем изучить что-то, нужно лишь желание научиться. По QA и Data Science я советов увы не могу дать, но по разработке игры вполне. Начните с изучения какого-нибудь движка. Любого. Unity, Unreal Engine, Godot, Defold, LÖVE. Но есть проблема, хорошие обучающие материалы в большинстве своем на английском. Есть на русском, но хороших их них единицы, и они уже к сегодняшнему дню несколько устарели. По крайней мере по тому же Unity я хороших уроков современного Unity на русском я не знаю. Могу посоветовать этот.
                  По Godot могу посоветовать этот. Возможно есть хорошие платные курсы, но я увы на русском таких не проходил. Движки я изучаю в основном по документации на английском


                  1. wavan2012
                    18.10.2023 05:59
                    +1

                    Спасибо за развернутый ответ


                    1. AnimeSlave Автор
                      18.10.2023 05:59

                      Пожалуйста


      1. MrBrooks
        18.10.2023 05:59
        -1

        Абсолютно неправильная позиция. Написание своего движка лишь дает возможность понять технические аспекты реализации, а не научиться делать игры. Более того, вы своим... мнением (?) просто отталкиваете тех, кто реально может стать крутым программистом в геймдеве, но увидев эту... текст, испугается.

        Делать игры - легко. Вы сами себе сломали свое представление, зайдя через задний двор. Не надо теперь вешать этот ярлык другим. Проблема в вас, уж извините =)


        1. AnimeSlave Автор
          18.10.2023 05:59
          -1

          Здесь я вам отвечу. Легко делать игры, когда у вас уже есть всё для этого. Вся логика написана, все игровые ассеты (2D-3D объекты, звуки, музыка), есть сценарий, и если есть движок. Особенно легко, когда это делаете не вы. Когда же человек только начинает свой путь в разработке игр. У него ничего нет. Знаю, есть такая группа разработчиков игр, которые на коленке из готовых ассетов делают игры. Но опять же для начала, чтобы стать таким же нужно хотя бы изучить какой-нибудь игровой движок.

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


          1. MrBrooks
            18.10.2023 05:59
            -1

            Легко-легко-легко. Вы как будто сами напрашивайтесь на "тяжело". Хотите "тяжело" - пишите свой движок дальше. Но студии берут в работу анрил не для того, чтобы было тяжело, а чтобы было легко, быстро и дешевле, чем с вами.

            Вы как будто с неба свалились. У меня знакомый С++ изучал: ушел в ассемблер и сказал, что С++ это сложно, ну его в баню.
            Причем тут Ассемблер, я так и не понял, но С++ он не выучил, программистом не стал. Пошел в операторы на звонки отвечать.

            И вы вот один в один поступаете - зашли с движка и такой: "геймдев - это ад, ребятки. Так сложно, так сложно!"

            Удивительно, что вы после этого вообще пробрались куда-то и стали делать игры. Хотя, судя по тому месту, что вы описали - просто нашли себе таких же.

            Легко делать игры, когда понимаешь - как их делать. Тяжело делать игры, когда начинаешь изучать то, как работает серверный мост в купе с CPU и RAM. Причем тут они - я так и не понял, но геймдевом вы явно не занялись.


            1. AnimeSlave Автор
              18.10.2023 05:59
              -1

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

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

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

              Второй подход используется тогда, когда разработчики игры хотят реализовать конкретные идеи, которые они не могут реализовать на существующих, готовых движках. При этом существуют компании, который разрабатывают свои движки, чтобы не зависеть от других. Чтобы не раскрывать внутренние механизмы, например. Такое тоже бывает. К примеру в упомянутой мной в статье компании Playrix используется движок собственного написания. Небезызвестный Кодзима использовал движок созданный конкретно под его игру, вот только я не помню под какую из ему движок разрабатывали с нуля. В компании, где я работаю сейчас движок тоже самописаный. То есть это не уникальное явление, а вполне нормальная практика.


              1. MrBrooks
                18.10.2023 05:59
                -1

                Не, уважаемый господин, вы не поняли, что я вам пытаюсь донести.

                Вы утверждаете, что геймдев - это тяжело. Но это не так. Геймдев - это легко. Это вы не не с того начали.

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

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

                Далее.

                Вы привели примеры студий, которые имеют бюджеты на поддержание своего движка на десятилетия вперед.

                При этом какая-нибудь инди-студия со своим движком - это риск рискованный из рисков созданный. Упьется СТО и уволится нафиг - этот движок никто не сможет больше поддерживать, и компания загнулась.

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

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

                Даже инвесторы просто не будут вкладывать деньги в самопальные движки, потому что если вдруг не станет разработчика - не будет и проекта.


                1. wavan2012
                  18.10.2023 05:59

                  Оххх, а чем мне тогда воспользоваться чтобы сделать игру(идея которой у меня висит в голове уже больше 10 лет) наиболее близкую по принципам к dwarf fortress, но далёкую от rimworld, я тоже думаю что понимание работы движка мне поможет сделать эту игру и скорее всего мне прийдётся её делать не полагаясь на существующие движки


                1. AnimeSlave Автор
                  18.10.2023 05:59

                  А. Я кажется понял. Но я оставлю выводы при себе.

                  вы это выставляете это, как правильный путь

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


  1. 7Euro
    18.10.2023 05:59

    Спасибо за статью!

    Я сам еще студент, но только год назад определился с направлением, в котором хочу идти. Мне, честно говоря, эта статья помогла прояснить пару моментов, которым стоит уделить внимание.


    1. AnimeSlave Автор
      18.10.2023 05:59

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


  1. MrBrooks
    18.10.2023 05:59

    .