Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

Как построить карьеру в геймдеве. Рассказ Lead Unity Dev

Меня зовут Максим Пивоварчик, в ІТ работаю более 10 лет. Сейчас занимаю позицию Lead Unity Developer в Gismart, которая разрабатывает и издает мобильные игры и приложения. До этого работал в разных компаниях — продуктовых и аутсорс, благодаря чему знаком с абсолютно разными подходами к разработке игр. О том, как я строил свою карьеру на заре геймдева, и о том, как войти в индустрию сегодня, вы узнаете из моей истории.

Как все начиналось

Сколько я себя помню, мне всегда нравились игры, но я никогда не думал, что смогу сделать свое хобби работой. Когда мне было 15 лет, мы с приятелем заработали репутацию местных хакеров. В те времена доступ к интернету был далеко не у всех, хотя поиграть в легендарные Lineage II и World of Warcraft хотели многие. Мы с другом нашли выход из положения. У нас на районе была локальная сеть, в которой были объединены пару десятков домов.

Мы начали искать в интернете, как можно запустить Lineage II в локальной сети. На тот момент я только знал, что есть сервер и клиент игры. Клиент у нас уже был, оставалось найти и развернуть сервер. Сложностей возникло масса, но были и другие ребята, которые делали что-то подобное. Мы общались с ними на форумах.

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

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

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

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

Важно самостоятельно попробовать сделать небольшую игру, чтобы разобраться в деталях на практике. Вот хороший сервис, где можно поучиться программированию в рамках «игровой песочницы» — screeps.com.

Первый офер

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

Когда я пришел на собеседование, то мне сразу дали тестовое задание. Компания занималась мобильными играми — и для меня стало открытием, что можно создавать игры не только для компьютера. Я загорелся. Тестовое я делал на месте — у меня было два часа. Мне показали демо игры, где на экране телефона из стороны в сторону двигался шар.

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

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

Формат работы мне подходил. Свои положенные 40 часов в неделю я мог отрабатывать в любое удобное время. Иногда, правда, приходилось приезжать в офис по два раза в день: до и после учебы. Я проработал в этой компании полутора года, получил хороший опыт и понял, что надо двигаться дальше: мы писали игры на Java, в то время как вышла уже третья версия Unity.

Путь от Junior до Team Lead

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

Я сдал экзамен по Unity, когда они только запустили систему сертификации в 2017 году. Подготовиться к нему несложно. После внесения оплаты вам присылают материалы для этого. Базовый курс недорогой и подойдет тем, кто хочет войти в геймдев.

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

Это была аутсорсинговая геймдев-компания, мы делали игры для заказчиков из США, Канады, Бразилии, Европы. Зачастую я вел по 3–4 проекта одновременно, при этом часто общался с клиентами напрямую. Я был разработчиком, но иногда приходилось выполнять функции проджект-менеджера, гейм-продюсера и даже гейм-дизайнера. Это было не просто, но опыт ценный.

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

В 2013 году вакансий уже стало значительно больше, глаза разбегались. Я успел поработать на проекте Bubbles для Facebook. А позже друг меня пригласил в одну крупную продуктовую компанию, где он на тот момент работал. Основные проекты — игры по мотивам мультфильмов, таких как Winx и Slugterra. Тут я чувствовал уже большую свободу в плане разработки. Мог применять новые подходы, экспериментировать.

Я постоянно следил за новыми релизами от Unity. Ежегодно они проводят конференцию Unity Unite, где рассказывают о новых фичах. Если я понимал, что в чем-то не разбираюсь, тут же подтягивал свои знания в этой области. Мне помогали видео на YouTube и книги. Их списком я поделюсь ниже. Конечно, я прочитал гораздо больше литературы, но считаю, что начать нужно с базы.

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

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

Еще через два года меня начали активно хантить. Так я начал работать в одной из крупнейших компаний в индустрии. Тут было мощно развито направление R&D, мы были чем-то вроде лаборатории для экспериментов. У нас была прямая поддержка от Unity. Они часто давали нам тестировать новый функционал до официального релиза.

Мы пробовали новое, делали игры, смотрели, что работает, а что нет. Конечно, большая часть проектов не доходила до глобального релиза. Но R&D на то и R&D, нашей задачей были исследования прежде всего. Успешные наработки уже реализовывали другие наши команды.

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

R&D-офис Gismart в Киеве открылся только в начале 2020 года, и мне нравится участвовать в построении процессов в новой команде. И сама работа увлекает. Секрет успеха гиперказульных игр в скорости. Мы не тратим месяцы на разработку игры, которая может не выйти в глобальный релиз. Стратегия заключается в том, чтобы быстро сделать прототип, протестировать его, внести правки в зависимости от фидбэка аудитории, а после уже на основе аналитики принимать решение о ее будущем.

Литература и другие источники для самообразования

Книги:

  • «CLR via C#» Дж. Рихтера;
  • «Head First. Паттерны проектирования» Эрика Фримена, Элизабет Робсон;
  • «Алгоритмы: построение и анализ» Томаса Х. Кормена, Чарльза И. Лейзерсона, Рональда Л. Ривеста, Клиффорда Штайна;
  • «Совершенный код» Стива Макконела;
  • «Рефакторинг: улучшение проекта существующего кода» Мартина Фаулера;
  • «Адаптивный код: гибкое кодирование с помощью паттернов проектирования и принципов SOLID» Гэри М. Холла.

Ресурсы:

Список курсов для геймдев-разработчиков:

Геймдев сегодня развивается очень активно, это перспективная ниша. Она подойдет тем, кто любит активный темп работы, эксперименты и, конечно, сам причисляет себя к геймерам. Количество вакансий на рынке огромное, при этом наиболее ценными специалистами считаются Unity-разработчики. Поэтому смело приступайте к построению карьеры в этом направлении. Удачи!

👍НравитсяПонравилось1
В избранноеВ избранном1
Подписаться на тему «gamedev»
LinkedIn

Похожие статьи



37 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
В те времена, а это далекий 2010 год, геймдев был в зачаточном состоянии

Це вже після Козаків і Сталкера? :)

Ждалкера
Если быть точнее он умер

GSC показал пример того, как можно разрабатывать игры в СНГ. В 2010 количество таких компаний можно было измерять пальцами рук, сейчас в любом большом городе можно найти игровую студию. Порог входа гораздо ниже, а выбор намного больше

Да их и сейчас посчитать можно пальцами одной руки. Продуктовых ААА студий тут практически нет.

..и после метро 2033 ) но человек увлекался Java и хотел в геймдев ¯\_(ツ)_/¯

Свою первую коммерчески успешную игру писал на ассемблере для советского ПК-01 Львов (Привет, армейка: dou.ua/...​enta/articles/it-in-army).
После этого все навороченные фреймворки объясняют проблему, когда примитивная игрушка требует от компьютера очень серьезных мощностей. Формула кривизны рук гемдевов рассчитывается по формуле (совокупная мощность минимальных требований) / (техническая сложность игры).

когда примитивная игрушка

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

AmongUs смотрит на комментарий с желанием вытолкнуть его в шлюз

Она 2д и в ней почти ничего нет. Такое тяп ляпом писали на флеше лет 10 назад, и оно не лагало. С чего бы сейчас такому лагать?

И не смотря на эту простоту — в нее играют.

И она представитель тяпляпа, не вылизанной поделки.

Сейчас коммерчески успешные игры, которые создавал один человек, вообще большая редкость. За каждым успехом стоит целые команды из разных отделов (art, development, game design, marketing, anlytics, etc.), еще есть огромное количество сторонних факторов (договора с партнерами, рекламные акции, продвижение в сторах и тд).
Все сводится к трем основным факторам: скорость, качество и цена. Выбирая любых два — страдает третий.

Считать кривизну рук бессмысленно. Других рук в геймдеве все равно нет.

«Фреймворки» решают проблему постоянно меняющихся требований от ПМов и дизайнеров. Конечно, если никаких таких лиц у вас нет, вы действительно можете писать хоть в машкодах, было бы желание.

Раньше писали без фреймворков и руки прямые тоже водились

Насколько раньше?

Super Mario Bros. делали два года. Сейчас код подобного платформера пишется за вечер (ассеты, конечно, создавать чуть дольше). Разве это не прогресс?

А теперь сравните оптимизацию по железу

после очередного отпуска я решил, что пора что-то менять

Ага, жизненная ситуация, приходишь такой после отпуска и не понимаешь, что ты тут вообще делаешь, зачем это все))
Я бы добавил, что на мобильных юнити играх свет клином не сошелся. Во-первых, кто-то должен и сами движки делать. Пусть сейчас in-house движки есть в основном только у ААА, либо тех, кто начал очень давно, ценность от понимания внутреннего устройства движков будет даже если потом писать на юнити. Поэтому мой совет начинающим, особенно студентам у кого есть свободное время — пишите свои велосипеды (лучше не писать свой первый ренер на Vulkan — можно навсегда отбить интерес. Для начала лучше OpenGL/Direct3D11). Юнити после этого осваивается за пару недель. Ну и опять же, если выбирать между юнити и анрилом, я бы выбрал анрил потому что там C++ и открыты исходники — можно увидеть как внутри устроен движок. Что, несомненно, принесет больше опыта.
Кроме того, нанять толкового программиста на движок в текущее время вообще не тривиальная задача. С появлением юнитей/анрилов, число людей, разбирающихся в низкоуровневой кухне стремительно сокращается. Так что это становится узкой нишей, в которой можно заработать больше, чем типичным геймплей прогером. А знания и опыт, полученные в процессе, помогут потом работать вообще в любой области. Пример: SpaceX ищет программистов ракеты на GDC, тк современные студенты не умеют работать с памятью (habr.com/...​pany/dcmiran/blog/530446) :)

PS Начать советую с этой книги www.goodreads.com/...​-game-engine-architecture
Очень толковая, половина про то, как работает компьютер, вторая про собственно движки и разные подсистемы, с примерами из реальных проектов.

что на мобильных юнити играх свет клином не сошелся.

 ну как раз таки сошёлся

кто-то должен и сами движки делать.

экономически не целесообразно если вы не рокстар. Сейчас бы писать свой движок для убийцы сабвей серфа.

Поэтому мой совет начинающим, особенно студентам у кого есть свободное время — пишите свои велосипеды

пропущено слово «не».

потому что там C++

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

Не согласен с каждым пунктом :) мой совет подразумевает развитие в сторону «рокстар», что бы это не значило. Если нет желания заниматься Software engineering в котором engineering не пустой звук, то юнити и мобильные дрочилки это вариант.

заниматься Software engineering в котором engineering не пустой звук

и

кто-то должен и сами движки делать

это вещи немного разные. Теоретическое CS мало пригодно для непосредственного написания движков, особенно теория Б. Кое что из теории А, можно применять. Чтобы

Во-первых, кто-то должен и сами движки делать.

Нужно выучить несколько фундаментальных вещей ещё и со стороны математики: 0) Мат. базу под все следующее 1) Аналитическую геометрию 2) Дифференциальную геометрию 3) Теормех(+ ODE) 4) Урматфиз(+ PDE, + функан под совершенные методы), если есть желание писать «рендеринг». 5) МПВ, очень много МПВ(+ функан, под современные методы). Все это учить по говнокоду в сорсах анрилы не самая оптимальная идея из возможных. Все, без исключения мои знакомые кто «пишет сами движки» и в этом хорошо преуспели имели хоть какой-то математический бекграунд.

Очень толковая, половина про то, как работает компьютер,

Эти вещи обычно описывают в книгах по системному программированию, но тут лучше начинать с машин тьюринга и плавно двигаться в сторону amd64 или arm, что больше нужно.

современные студенты не умеют работать с памятью

Студенты никогда не умели работать с памятью. Да и не студенты тоже, никто не умеет работать с памятью, все новое на С и С++ течет, и в ближайшее время эта ситуация меняться не собирается, ибо комитетчикам пофиг, а раст да ещё и в геймдеве не особо силен. Всякие К-фреймворки те же студенты знать не знали и слыхать не слыхивали, по этому можно спокойно забыть и забить. Можно конечно затыкать дырку в тулинге скилом разрабов но это очень экстенсивный путь.

Теоретическое CS мало пригодно для непосредственного

Ты видимо перепутал software engineering и computer science.

Математику знать тоже надо. Особенно, для рендера. Но рендер это ещё более узкая область.

Все это учить по говнокоду в сорсах анрилы не самая оптимальная идея из возможных

Вообще-то я говорил про выбор между юнити и анрилом, а не про изучение матана по сорцам лол.

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

хорошо подумать куда идти и чем заниматься в будущем.

В финтех конечно же, там платят больше, просят меньше. Если есть мозги и себя не жалко, в ФААНГ и прочие большие технокомпании.

Здесь геймдев вроде обсуждаем

Ты видимо перепутал software engineering и computer science.

он постоянно это путает :)
не только он, но на ДОУ самый яркий представитель этих путающих :)
люблю ДОУ именно за это, почти весь спектр вавок в головах представлен.

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

Г-н Камышан, зачем вы продолжаете с таким апломбом публично рассуждать о вещах, в которых вы не понимаете ровным счётом ничего (геймдев)? Вам же какая-нибудь заблудшая душа и поверить может. Зачем? Вам это доставляет удовольствие?

Кому нужно учить про N-мерные симплектические многообразия? Как это делать по сорцам Unreal?

Тред не читай @ сразу отвечай @ переходи на личности. Г-н Сидоренко ворвался с шашкой в тред и срубил с горяча — ваш геймплей программинг это уныло, низкооплачиваемо и путь в никуда. Я же заметил, что на самом деле, если цель — зарелизить игру и сорвать с неё денег, то вовсе не нужно вникать в глубины строения движков и что-то делать «как следует», метод костылей и победятла в этом случае сработает достаточно хорошо. Если же писать движки — то из каждого угла торчит по куску из математики. В пейперах по тому как из функции плотности построить поверхность уровня и так далее понарисовано каких-нибуть формул из дифференциальной геометрии. Для эффективного понимания того что там написано, это действительно надо. С другой стороны можно сказать что это уже НЕ геймдев, а разработка движков — и вы будете правы. Но Г-н Сидоренко говорил о разрботке движков а не прямом таки победятельном геймдеве?

нанять толкового программиста на движок в текущее время вообще не тривиальная задача
Пример: SpaceX ищет программистов ракеты на GDC, тк современные студенты не умеют работать с памятью

И так далее.

По моему опыту, движки это больше работа для C++ generalist, математика торчит, но не из каждого угла. Рендер больше про матан, который надо парсить в различных пейперах. Ну и с шашкой ворвался как раз господин Иван, видимо, считая, что он д’Артаньян, а все остальные — нет :)
Если цель просто херачить простые игры в продакшен — ну ок бери юнити. Если хочется делать более интересную работу (на мой вкус), пиши движки. Это тема про геймдев, банки и другие грустные места не рассматриваем.

все новое на С и С++ течет

Что бы это значило? Ладно работать с памятью, на первых порах было бы хорошо поработать с мыслью.

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

НАУ на программную инженерию.
много интересных домашних заданий по применению искусственного интеллекта в играх.
Мы занимались конструированием роботов

учился в НАУ пару лет назад, такого уже не застал

В начале много больших компаний поддерживали наше направление(Soft Serve, Miratech, Luxsoft, Epam, Microsoft), отправляли своих разработчиков, менеджеров, и даже сами владельцы приходили к нам, что бы прочитать лекции на разные темы.
Робота с роботами была в рамках изучения AI и Microsoft Robotics Studio(Microsoft Ukraine дали нам несколько модульных роботов)

Да, раньше было явно лучше. Может, спрос тогда был выше или универ настолько упал. Даже те полтора препода, которые шарили и чисто на энтузиазме вывозили, поувольнялись. А из искусственного интеллекта — матлаб, лабы из методички, и 1 пара в неделю практики.

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

Программная инженерия в НАУ это еще то дно.К примеру есть предмет придуманый лично деканом -«Екологія пз» ,та еще хрень.А web програмирование и еще один безполезный предмет про госты используемые при документации и разработке, вел чувак который был вроде как доктор медицины в какой то там области связанной с фармакологией.Постоянно рассказывал как он собирал травы где то там в горах. Вот кстате и он на видео youtu.be/fo_6gTaqbHY 1.41 мин

да, это одна из живых легенд. таким преподам сдавали полную дичь. копипастишь код на javascripte любой из интернета, можно побольше, чтоб внушительнее было. а отступая пару экранов вниз пишешь лабораторную в пару строк на jquery. или вместо ассемблера — с++... всё равно никто ничего не понимает, а так можно время больше ГОСТам уделить...

у него страничка в ВК еще была, он случайно порно на стену репостнул, и когда студентка сказала, «вы же преподаватель...», он не удалил, а просто отписал «очень жаль. наверное, вирус». это был тот еще мем у нас

Аххах про пост в вк я не слышал)

Подписаться на комментарии