Spiiin's blog

Соберу здесь несвязанные заметки за длительное время насчёт мотивации работы над пет-проектами. Что-то из этого покажется очевидным, что-то может быть неверным, что-то — очень ситуативным. Что-то может быть и демотивирующим, но людей с горящими глазами не зацепят чужие рассуждения.

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

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

Вначале будет “а точно вам нужен этот геймдев вообще?”, затем всё же немного и про него.

Моя позиция#

Прежде чем рассуждать, или приводить примеры, опишу, как я отношусь к пет-проектам в геймдеве/в общем.
Если кратко, моё правило простое:

Делать только то, что не можешь не делать, во всех остальных случаях — отказываться.

перефразированная цитата “если можете не делать игры — не делайте их”

Даже если что-то кажется очень привлекательным, но “не цепляет” — не браться за это. Пет-проекты сжигают всё свободное время, и практически бесконечны, поэтому делать что-то без уверенности, что ты будешь получать от этого удовольствие на протяжении длительного времени. Как только интерес начнёт пропадать, это вызовет проблемы, если нет другой мотивации (а откуда ей взяться?)

Кроме этого простого правила, у меня есть ещё несколько проверок:

📍 Насколько будут отвлекать другие приоритеты в жизни (семья, отдых, здоровье, эмиграция, другие хобби). Пет-проекты плохо совмещаются с другими планами.
📍 Есть ли у проекта вообще цель быть нужным автору. “Разобраться, как правильно сделать такую программу” — это цель процесса, не связанная с результатом (при этом исследовать что-то новое вполне может быть интересной целью — разница в том, хочет ли автор сделать что-то, что еще не делал он сам, или что-то, что ещё не делал вообще никто).
📍 Если предполагается, что проект будет нужен другим людям, а не автору — сразу много вопросов, откуда вообще предположение, что это кому-нибудь будет нужно. Ну и вообще, если цель не сделать хорошо для себя, то тут должна включаться логика стартапов/lean development для изучения потенциальной аудитории и/или привлечения ресурсов. Почему это вообще пет-проект тогда, и как именно он должен трансформироваться во что-то другое? Вдвойне пугают планы на b2b, а не b2c.

И еще много всяких нюансов.

Плохие цели (для проекта, персонально для авторов может и норм):

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

Хорошие цели:

• Попробую что-нибудь, что еще никто не пробовал
• Сделаю что-то что поможет мне и другим (+ исследование, общение с пользователями)
• Дизайн на композицию с другими системами

Пет-проекты VS изучение#

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

От этого не защищает ни высокая техническая должность, ни высокая управленческая. В обоих случаях “интересы бизнеса” скорее всего уведут в специфические дебри проблем компании. Это нормально для карьеры (бизнес — про доставку клиентам фич, а не про развитие), но прокачивает очень специфические навыки.
How I decide what to work on at large tech companies — объяснение, как это происходит.

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

Изучение — не однозначно лучшая альтернатива, и обладает своими минусами. Во-первых, выполненные проекты проще “продать” при поиске работы. HR больше впечатляет “сделал свой движок” в резюме, даже если движок посредственный, чем “прочитал книгу про обработку столкновений в реальном времени и реализовал основные алгоритмы”. Хотя если изучение завернуто в какие-нибудь платные курсы с сертификатами, ситуация может быть другой. Во-вторых, какие-то из приобретенных навыков просто не получится применить на практике. В-третьих, самообразование либо занимает много времени на практику, либо предполагает большое количество опыта, с которым можно сверять новую информацию. Ну и в принципе, на изучение в геймдеве, как и на пет-проекты, надо закладывать годы.

• Эволюция программиста в геймдеве — я писал когда-то про модели развития программиста в геймдеве с широким набором навыков, принятые в некоторых компаниях. Это не стандартный корпоративный формат, где больше любят специализации.
• The Abstraction Layers of Game Developer Skills — примерный список навыков разных уровней. Не всё нужно, например, для работы над мобильными казуальными 2d играми, но так или иначе когда-то возможно столкнуться с тем, что для рабочих задач нужны навыки, которых нет, а читать несколько книг по теме будет некогда.
• Плюсовики в геймдеве + материалы по геймдеву — немного хаотические заметки на тему “программист на C++ != программист в геймдеве”.
• Геймдизайн, заметки — материалы по гейм-дизайну, для базового понимания того, как игры работают вообще. Если заниматься не только программированием, список материалов только растёт.

Не держать яйца в одной корзине#

Это выражение подходит и для пет-проектов. Точно ли после работы хочется потом еще заниматься этим же вечером дома “для души”? Как альтернатива — если просто тратить доп. время на работе, может ли это привести к карьерному росту?

📍 Разработка как игры, так и движка — чертовски трудоёмкий процесс. Для каких-то мелких пет-проектов реально собрать прототип за пару выходных. Для игр это скорее будут месяцы или годы. Отдельная сфера — всякие джемы, работа на износ в сжатые сроки, с 99% выбросом прототипа.

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

Примеры моих “не геймдев” пет-проектов:

Проект: CadEditor — тут описывал свою мотивацию при работе над редактором уровней для старых консолей, в несколько этапов. Моддинг игр — отдельная субкультура, связанная с играми. Эмуляция старых консолей и ромхакинг — еще более узкая категория. Существует множество ниш, не связанных непосредственно с разработкой, менее трудоёмких и с возможностью относительно быстро собрать полезный себе или другим прототип проекта. Старый проект, которым занимался несколько лет.

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

Бизнес-ландшафт геймдева#

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

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

Видение гейм-дизайнеров и продюсеров — твит-заметка, и дискуссия в комментариях. “есть арт-проекты, мобильный f2p и AAA (“большие проекты”). Всякие промежуточные и эзотерические направления тоже есть. Я пришел в эту индустрию, чтобы делать шутеры, потому что лучше, чем Дум, игры до сих пор не придумали. Но каждый вечер, чтобы у меня были деньги в том числе на инди-проекты, я программирую матч-3 про сука котиков”.

Пет-проекты могут касаться в том числе и этой эзотерики — vr/ar, nft, игры внутри платформ (roblox, можно посмотреть какой-нибудь hype-hype)

С точки зрения производства игру можно делить по Джесси Шеллу на эстетику/механику/технологию/нарратив.
“Пет-проекты” геймдева с точки зрения программиста — это либо что-то что может вырасти в целую игру, либо “технология” — очень размытое определение технической части игры, куда можно вписать вообще всё — как движок с инструментарием (в эпоху unreal/unity часто подразумевается такой монолитный комплект из движка и wysiwyg-редактора с модулями для работы всех специалистов), так и отдельные сервисы и библиотеки.

Взаимодействие команды#

Чем выше по должностям в корпоративном мире (в том числе и в геймдеве), тем меньше люди связаны с производством, и больше — с управлением своей командой и общением с другими. Большая часть работы сводится к взаимодействию между людьми. Еще выше люди всё меньше связаны с играми, и больше — с деньгами.

Для пет-проектов не работают никакие средства корпоративного взаимодействия, т.е. всё общение должно строиться по другому с нуля. Не особо работают и попытки привлекать сторонних исполнителей — есть риск получить одновременно и негативные стороны бизнес-разработки (не полную вовлеченность) и любительских проектов (невысокое качество). Чёрт его знает, что работает. Серьёзный интерес нескольких людей к одной теме (что редко бывает в пет-проектах, ориентированных на последующий переход к заработку), и дружба/доверие/четко прописанные планы на будущий доход. Возможно, ещё необходимо сочетание навыков, дающее синергию.

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

Движки#

Лет 20 назад можно было написать движок и продать студии по разработке игр за 4-значную (или если повезет, даже 5-значную) сумму. Сейчас компании или имеют свои движки с многолетней историей, или предпочтут проверенные. В существующие движки вложено столько человеко-часов, и там накоплено столько функционала, что угнаться одному за этим невозможно. В то же unity/unreal задали тренд на то, как выглядит архитектура и интерфейс редактора. Я пытался расписать на русском и английском развернуто (очень развернуто!) одну мысль — движок и инструментарий должны выглядеть не “как Unity”, а в зависимости от команды, которая предполагается что будет его использовать.

• Game Development: History, Industry, and Engine Design - тут на английском, с замахом на историю всего геймдева
• Ещё о проектировании (движки и история) - тут на русском, немного в рок-н-рольном стиле

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

• ИИ может поменять состав команд
• Для “больших” игр конфигурация команд более-менее стандартная, но для инди обходятся меньшим количеством людей — могут существовать различные конфигурации

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

Игры без движков#

Для инди-команд существует вариант создания игры без движка. Однако, тут как с отказом от маркетинга издателя — всё нужно будет сделать самим. Такой подход в плане движка окупится где-то игре к третьей.
Solodevs and the trap of the game engine
Write Games, Not Engines
Making Video Games in 2025 (without an engine)

C++#

Я много писал про C++ в геймдеве, и много мог бы написать ещё, но попробую кратко, в контексте пет-проектов

• С++ в геймдеве
• Рандомные мысли про код, дизайн, C++ и геймдев

C++ — стандарт в бизнесе, но часто не удобен как язык для написания игровой логики. Осилить поддержку для хорошего скриптинга (не просто прикручивания биндингов для функций) или визуального программирования достаточно сложно для пет-проекта. Кроме того, одна из задач редактора — создание визуальной среды, в которой часто еще и используется рефлексия (фактически, еще один язык над C++). Как скриптовые языки, так и визуальное программирование — огромные области для исследований и улучшений относительно существующих.

Кроме того, C++ слишком низкоуровневый для построения на нём хорошей рефлексии, да и просто как база для движка. Скорее всего придётся изобретать (для библиотек движка, рефлексии и возможно кастомных языков скриптов) такие вещи как свойства, события, колбеки, атрибуты, а также более сложное, вроде рантайм генерик функций/типов и ast-макросов, и т.д.

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

Если, конечно, пет-проект нацелен на встраивание в C++-код, или предполагает использование в AAA-играх или запуск на критически слабых устройствах, то можно по прежнему воспринимать С++ как неизбежное зло, но не норму

Нужно больше хороших и разных примеров “наша команда взяла язык X и сделала всё на нём, получилось быстрее, лучше и вдвое меньшим составом чем конкуренты”.

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

Пет-проект как отдельная библиотека#

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

Зарабатывать на библиотеках еще сложнее, чем на движках. Casey Muratori часто выступает с рассказами о том, как проектировать библиотеки, которые будут взаимодействовать с различными движками. Я ни разу не встречал среди знакомых попыток делать небольшие библиотеки. Движки и игры почему-то выглядят для них амбициознее. Хотя будто бы могу назвать с десяток библиотек, сервисов или инструментов, которые были бы полезны мне (особенно если бесплатно). И знаю несколько библиотек, которые прибиты гвоздями к движкам, и оторвать их невозможно.

10 years of Dear ImGui — история о том, как Omar Cornut собирает донаты на самый используемый пет-проект в геймдеве. Open source — отдельный мир со своими правилами.

Для заработка используется какой-нибудь вариант “вот наш сервис (какой-нибудь аналитики), вот sdk для встраивания его в вашу игру в виде небольшой библиотеки, платите за доступ”. Такого существует относительно много. Или “наша программа будет на каждый чих стучаться к серверу лицензии” (привет, Spine).

Вывод#

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