Начнём с базовых вещей. Как вкатиться в геймдев? Зачем? Почему не стоит? Обманутые ожидания и т. д.
Геймдев, по сути, то же IT, но тут почему-то у многих новичков очень идеализированные взгляды на индустрию.
Я, как и многие, мечтал делать игры ещё со школы.
Но в реальности тут очень много рутины. Как и у разработчиков, так у геймдизайнеров (которые ПРИДУМЫВАЮТ И СОЗДАЮТ МИРЫ).
И хорошо, если вы столкнётесь с тем, что в геймдеве просто сложно. Ведь скиллы и умения можно прокачать.
Но всё может быть несколько иначе...
И это не камень в огород мобильных игр (да, это он). Это про обманутые ожидания.
Реальность такова, что вряд ли на проекте вы будете заниматься по-настоящему креативной работой.
Это касается и разработчиков, и геймдизайнеров.
Факт в том, что в России сейчас преобладает мобильный геймдев, где в основе лежит копирование/клонирование.
И если вы не можете с этими смириться и не можете находить/придумывать интересные для себя задачи сами, то вас ждёт быстрое выгорание.
Поэтому рекомендую изначально над этим вопросом подумать.
Кому-то нравится именно процесс разработки. Даже если задача скучная, всегда можно что-то новое изучить, новые подходы, алгоритмы или ещё что-то.
Это всё зависит от вас. Не нужно ждать "интересных задач сверху".
Например, можно поразвлекаться с Блюпринтами в UE4 (¬‿¬)
Ну ладно. Мы уже поняли, что развлекать себя придётся самому. А как вкатиться то? Что изучать?
Программистам в этом плане попроще, т. к. они могут руку набить на пет проектах или поучаствовать в опенсорсе.
Но ведь "там нужны какие-то специализированные знание, матан с алгоритмами". Слышали такое?
На самом деле, вы почти не будете сталкиваться со всем этим в типовых задачах.
Правда жизни в том, что тормозить в игре будут совсем другие вещи.
К примеру, если мы говорим про Unity, то во многих играх лагает не физика или отрисовка самой игры, а GUI. Хотя, казалось бы, да?
Но про конкретные движки и оптимизацию мы ещё поговорим в другие дни. А пока вернёмся про то, как же начать.
Я лично в своё время работал над корпоративной системой документооборота, а параллельно изучал геймдев, делая клоны старых NES игр на LibGDX.
Даже туториалы делал suvitruf.ru/libgdx, за которые меня до сих пор благодарят.
Сейчас больно смотреть на эти уроки и код, но это хорошая отправная точка.
Поэтому советую завести блог на какой-либо из площадок.
Это поможет вам самим систематизировать многие вещи.
Я, правда, блог создавал с целью делиться знаниями с другими. Но пока пишешь статьи, то много информации перебираешь, что очень сильно и самому помогает.
А работодатели сейчас смотрят не только на твой Гитхаб профиль, но и на публичную деятельность.
"Личный бренд" — это не просто пустой звук. Ваше имя в какой-то момент будет работать на вас, если достаточно прокачать.
Возвращаясь к сложности... Если это простенькая 2d игра, то особых знаний математики не требуется, достаточно знать базу с векторами.
Всё остальное — это уже больше про логику.
А если на проекте занимаетесь UI, то вы даже векторами оперировать не будете.
Это я всё к тому, что для старта не нужны какие-то сверхъестественные знания того, как работает под капотом рендер и прочее. Да даже без знания многих фундаментальных вещей типа дроколов и прочего можно жить.
Всё этой можно набить за первый же месяц.
Тут вопрос лишь в том, готов ли работодатель брать человека на вырост. Мой опыт показывает, что даже небольшие студии могут на это пойти.
Тут ещё остаётся вопрос, готовы ли вы на старте на даунгрейд по з/п.
Видел примеры, когда люди перекатывались из IT (например, из банковской сферы) в геймдев с даунгрейдом в 2x по з/п и не жалели об этом.
Человек, любящий своё дело, довольно быстро пойдёт в гору. И если не сравняет, то, как минимум, приблизит з/п к прошлому уровню.
Что касается "вкатиться", то вам возможно даже не надо изучать именно геймдев, чтобы работать в геймдеве.
Студии частенько пишут внутренние инструменты. Так что, если вы фронтендщик/бекендщик, то можете слёту вкатиться.
Остаётся только как-то донести мысль до руководства, что им нужны эти инструменты🤔
Видели бы вы некоторые внутренние тулзы, которые пилят студии для своих нужд...
Представьте, что вам нужно написать туториал для игры. Я часто видел, как это всё хардкодилось. И если геймдизайнер решит что-то поменять, то он будет дёргать разработчика для этого.
Оптимально ли это? Часто ли будет меняться туториал?
А что мы будем делать в следующей игре? Хм, может стоит выносить это дело в какой-то конфиг? Хотя бы в видео Json'ов.
А может сделаем визуальную тулзу с кастомизируемым туториалом, которой смогут пользоваться ГД и не отвлекать разработчиков?
Я бы с радостью описал процесс, но с позиции геймдизайнеров, но, к сожалению, это не ко мне.
Про ГД могу лишь общие советы дать.
И главный из них: НАУЧИТЕСЬ РАБОТАТЬ С ДВИЖКОМ!
Нафантазировать вы себе можете что угодно, но куда важней, если вы это можете нормально объяснить, а ещё лучше — показать.
Поэтому в крупных студиях прямо в требованиях на вакансию ГД указывают, что нужно умение работать с движком.
Не нужно уметь писать код, достаточно базовых знаний. Полезным ещё будет изучение инструментов визуального программирования. В UE Блюпринты, а в Юнити есть Bolt.
Всё настраивается на уровне нод без кода вообще.
И, к слову, не обязательно это делать на том же движке, на котором пилится игра. Вот это неожиданность!
Для таких вещей может подойти что-то другое с низким порогом входа.
Например, Roblox. Там даже без кода можно много чего напрототипировать. Много компонентов есть из коробки, много чего сообщество уже сделало.
А если уж нужен код, то для логики там есть простой как пробка Lua.
Кстати, мы пока обсуждали то, как вкатиться в геймдев.
Но намного сложнее из него выкатиться.
Вот вам тру стори.
Меня однажды не взяли в IT компанию, потому что, цитирую: «У нас был опыт работы с людьми из геймдева, нам не понравилось. Поэтому больше с такими не работаем».
