У разработчиков игр есть довольно странная профессиональная болезнь, когда после рабочего дня, проведенного за тасками и кодом хочется открыть ноутбук и снова писать код, только уже «для себя». Большинство моих коллег по цеху, придя домой тратят 1+ часов чтобы: поделать свой движок или переписать/помодить/любимую/старую/новую/другую (нужное подчеркнуть) игру или собрать какую‑нибудь библиотеку, или починить инструмент, который всех раздражает. Не знаю, может эта заразно и гуляет по студиям, а может это просто кусочек творческой атмосферы, который ты уносишь из офиса, и он некоторое время живет вне этого пространства.
Часто бывает что маленький проект, который был на «пару вечеров» внезапно превращается в несколько лет жизни. Я много раз видел это снаружи и изнутри: СorsixTH, 0AD, Akhenaten, Cytopia, StoneKingdoms, (тут больше open‑source‑games) очень разные проекты (из тех куда я комитил), но все они хорошо показывают одну и ту же вещь, что пет‑проект почти никогда не остаётся «просто маленькой штукой». Он либо умирает, либо начинает требовать от автора взрослого отношения и тянет за собой архитектуру, поддержку, документациу, общение с коллегами по цеху и теми кто просто играет, разбора багов, релизов и неприятных компромиссов.
И главный вопрос тут не «как найти мотивацию», а точно ли тебе это нужно?
С играми и тулами есть правило, которое может спасти не один день жизни: если можно не делать, то лучше не делать. Может это и звучит демотивирующе, но зато честно. Пет‑проект в геймдеве редко заканчивается на первом прототипе и даже маленькая библиотека тянет за собой тестирование на разных компиляторах, примеры, README, issue tracker, ожидания пользователей. А если это движок, редактор или реконструкция старой игры, масштаб быстро становится «промышленным» что‑ли.
Akhenaten (Pharaoh 1999©) для меня как раз из таких историй. И если на поверхности или в дискорде это может выглядеть как «ну, возьмем старую игру и восстановим/переосмыслим её поведение», то в реальности сталкиваешься даже не столько со старым кодом. Код можно написать и поменять, а вот понять старую логику, воспроизвести ощущения и при этом не сломать привычки игроков, разобраться с данными, UI, симуляцией, поиском пути и его багами это ой как не просто. Я уже не говорю про сохранения и тысячу тысяч мелких правил, которые нигде нормально не описаны, и в итоге любая «простая» механика оказывается клубком зависимостей, половину из которых ты помнишь не так, как другие люди. Вот такие были старые игры.
Слабая мотивация здесь не выживает и «хочу сделать для портфолио», «хочу разобраться, как устроены движки», «хочу свой unity, только проще» могут быть нормальными начальными импульсами, но... Но это плохое топливо для многолетнего проекта.
Гораздо лучше тут работает «мне самому этого не хватает», «я хочу, чтобы эта старая игра жила», «мне интересно проверить мою идею», «я хочу сделать маленький инструмент, который можно встроить куда угодно».
Насчет маленького инструмента: imspinner начался после того, как мне заказали несколько нестандартных анимашек загрузки на плюсах, ну вот была у человека такая хотелка. Это не была попытка построить игровой фреймворк или даже фреймворк вообще, это просто маленькая, понятная, встраиваемая вещь для Dear ImGui в виде набора индикаторов загрузки. У неё маленькая граница ответственности и её можно понять, использовать, доработать и не тащить за собой половину мира.
Пет‑проект и обучение это не одно и то же
Пет‑проекты часто оправдывают обучением вроде «я напишу свой движок, чтобы разобраться». Это не работает. Именно написать движок — не работает. Из порядка тысячи моих игровых контактов игровой движок до состояния «можно показать и потыкать» написали всего два человека (https://www.linkedin.com/in/zenkovich/ и https://github.com/o2-engine/o2) и (https://www.linkedin.com/in/tinaynox/ c Melted Kingdoms, добавьте в вишлист, Дима мне обещал поставить пару баночек пива за рекламу).
Два человека из более чем тысячи, меньше одной десятой процента, и это обычная зависимость начатых и завершенных «до рабочей фазы» пет‑проектов. Тут проблема не в том, чтобы разобраться, а в том, что если вы пишете игру целиком, то неизбежно будете больше времени проводить в тех областях, где уже чувствуете себя уверенно. Программист будет полировать архитектуру и код, художник пойдет в визуал, ГД упорется в механики, а слабые места так и останутся на «потом»: инструменты, ui, сборки, тесты, контентный пайплайн, документация и так далее
На open‑source поле это очень хорошо видно, таже Cytopia как city‑builder загнулась, потому из проекта выдавили пару сильных прогеров (не меня, я там лишь краешком помогал, но всю эту дичь в чатах читать тоже пришлось), а потом и автора проекта, а новые так и не пришли. И техническая часть провисла, утянув всю разработку на дно. Недостаточно написать код, нужно, чтобы другой человек смог собрать проект хотя бы в десять шагов по мало мальски читаемой документации, а еще лучше чтобы мог понять структуру, предложить изменение и не сломать при этом чужую работу. А сломав не потерять интерес к проекту после первых ревью.
StoneKingdoms/Augustus/Akhenaten/OpenTTD/OpenAge показывают другую сторону разработки. Когда работаешь с наследием старых игр, то обучение очень часто идёт, скажем так не по современным стандартам и приходится изучать древние форматы, поведение, инструменты, ограничения оригинала и ожидания сообщества. Это мало похоже на «курс по разработке игр, напишем крайзис за десять дней», скорее на кодо‑археологию пополам с костыле‑инженерией и тренировкой интуиции.
Чтобы поучиться, если хочется именно поучиться вместо большого пет‑проекта полезнее взять маленькую тему и изучить её отдельно: сериализация, ECS, UI layout, навигация, hot reload, локализация, профилирование. Но у маленьких упражнений есть минус, что они редко дают ощущение завершенного проекта и «выброс гормонов радости», которые появляются в живом проекте.
Не каждый проект должен становиться большим
Или движком... Новички, которые сейчас приходят в разработку и видят ландшафт игростроя с плеч гигантов вроде Unreal/Unity/Godot/Defold и собратьев по цеху движкостроения поменьше. И начинают мыслить крупными категориями: игра, движок, редактор, механики, нпс. Так делают все без исключений, что поделать... мы быстро привыкли к хорошему. Но между этими широкими мазками существует огромный слой маленьких инструментов и библиотек, знать которые оказывается полезнее, чем знать движок в целом
Маленькие библиотеки хороши тем, что заставляют думать о границах. Что проект делает? Чего он принципиально не делает? Как его подключить? Можно ли использовать только часть? Насколько он зависит от чужого стека?
Многие игровые пет‑проекты страдают от желания сразу стать фреймворком или движком. Автор начинает с маленькой полезной функции, а через месяц уже проектирует систему плагинов, редактор, свой формат ассетов и план «когда‑нибудь подключить скрипты». Иногда это оправдано, но маленькая библиотека с ясным API имеет больше шансов выжить, чем амбициозный комбайн без пользователей, пополнив кладбище комбайнов на гитхабе.
Ремейки старых игр тут на особом положении, потому что держатся на конкретном знании и памяти игроков. Их нельзя просто заменить generic‑системой и сказать, что стало лучше, потому что игроки чувствуют детали и помнят свои впечатления, вроде темпа симуляции или реакции интерфейса, странностей поиска пути, багов баланса или других ограничения. И здесь свой движок уже не недостаток и не оверинжиниринг, а часть духа старой игры, просто на анриале вы не сможете это все это повторить, как бы не старались.
C++ остаётся важным языком для геймдева, (а С++17 вообще железобетонный стандарт), особенно там, где нужны производительность, контроль памяти, интеграция с существующим кодом и платформами, но для хобби‑проектов у него есть цена, и она достаточно большая, чтобы оттолкнуть большинство новичков.
Много времени уходит не на идею проекта или игры, а на инфраструктуру вокруг языка: сборки, ABI, шаблоны, зависимости, платформенные различия, reflection, биндинги, кодогенерацию и отладку странных ошибок. Если проекту нужны свойства, события, сериализация, редакторские инспекторы или скриптинг, вы быстро начинаете строить поверх C++ свой маленький язык.
В рабочих и больших проектах С++ оправдан, в домашнем проекте редко, ну или если вы кроме С++ больше ничего не знаете. И если цель проекта не исследовать C++ как таковой, а сделать игру или инструмент, то просто положите код на с++ и толкните его в сторону любимого фреймворка, будет полезнее и быстрее. Странно, что после 20 лет кодинга на C++ я уже не уверен, что он является преимуществом при разработке, скорее просто привычкой.
При этом маленькие C++ библиотеки всё ещё могут быть отличным форматом, тот же imspinner хорошо зашел сообществу потому, что не пытается закрыть весь UI или претендовать на экосистему Dear ImGui, а просто дополняет её чем то полезным и решает понятную задачу.
Open‑source добавляет ещё одну игру поверх игры
Когда проект открыт, вы получаете не только код, но и людей. А еще Issues, pull requests, ожидания, вопросы, форки, случайных людей, которые приходят раз год и спрашивают, почему что‑то не собирается, и обижаются если не отвечаешь. Часто пара хороших issue или пулреквест возвращает мотивацию лучше любой внутренней дисциплины.
Но open‑source легко превращается в неоплачиваемую поддержку, особенно если проект выглядит «почти готовым», а у пользователей уже есть ожидания как от продукта. open‑source геймдев это не просто «пишем игру вместе», а вторая работа. И там тоже приходится принимать решения, ставить задачи, переписывать системы и объяснить новичкам, где маленькая задача, а в какую архитектурную трясину пока лучше не лезть.
В одиночных проектах проще принимать решения, а когда появляется, пусть даже небольшая команда, то появляются коммуникации и много времени нужно именно на общение. После нескольких таких историй я всё больше ценю проекты с «честными» границами, назовем это так.
Не обязательно делать игру, если можно сделать инструмент для игр. Не обязательно делать движок, если можно сделать библиотеку. Не обязательно... там еще очень много почему НЕ...
Лучше наверное так: пет‑проект живёт дольше всего когда за ним стоит не желание разобраться или собрать портфолио, а конкретная нехватка, что‑то чего тебе самому не хватает и что ты готов использовать, а ещё лучше когда рядом есть небольшая группа людей с теми же интересами и проект можно сделать полезным не только для себя. Но став полезным кому‑то, он также станет и второй работой, где мотивация, масштаб и личный интерес будут единственным вознаграждением.
Если проект не отпускает — делайте, но лучше заранее выбрать такую форму, в которой он сможет прожить долго, потому что любое хобби всегда оказывается больше, чем кажется в первый вечер.
З.Ы. Если кому интересно древнеегипетское градостроение, то я завел девблог, куда добавляю изменения в игре и просто интересные статьи.
