Среди игровых разработчиков распространено своего рода профессиональное «искажение»: после изнурительного дня, наполненного корпоративными задачами и отладкой кода, рука сама тянется к ноутбуку, чтобы заняться чем-то «своим». Многие мои коллеги тратят часы свободного времени на написание собственного движка, моддинг любимых игр или создание вспомогательных инструментов, чтобы хоть немного облегчить себе жизнь. Сложно сказать, то ли это заразная «офисная болезнь», то ли естественный отклик творческой натуры, которая не готова расставаться с процессом созидания даже за пределами рабочего места.
Зачастую проект, задуманный как «развлечение на пару вечеров», постепенно поглощает годы жизни. Я не раз наблюдал этот процесс — как со стороны, так и будучи участником: СorsixTH, 0AD, Akhenaten, Cytopia, StoneKingdoms и другие проекты из сферы open-source. Несмотря на всю их специфичность, их объединяет общая судьба: пет-проект редко остается «просто маленькой затеей». Он либо быстро сходит на нет, либо перерастает в серьезную ответственность, требуя проработки архитектуры, качественной документации, выстраивания комьюнити, оперативного исправления багов и порой болезненных компромиссов.
Ключевой вопрос здесь не в том, как поддерживать мотивацию, а в том, действительно ли вам это нужно.
В разработке игр и инструментов существует принцип, способный сэкономить немало сил: если можно не делать — не делайте. Звучит несколько демотивирующе, но это честный подход. Любой пет-проект в геймдеве редко ограничивается прототипом: даже самая простая библиотека быстро обрастает необходимостью тестирования под разные компиляторы, написанием руководств, ведением трекера задач и учетом пользовательских ожиданий. Если же речь заходит о движке или реконструкции классики, масштаб неизбежно становится индустриальным.
Проект Akhenaten (ремейк Pharaoh 1999 года) — наглядный тому пример. Для наблюдателя в Discord это может выглядеть как попытка вдохнуть жизнь в старую механику, но на деле ты сталкиваешься не столько с самим кодом, сколько с необходимостью «раскодировать» логику прошлого. Понять принципы симуляции, воспроизвести тот самый «геймплейный дух» оригинала, не разрушив привычки ветеранов жанра, разобраться в запутанных данных, UI и навигации — задача монументальная. Старые игры — это клубок зависимостей и неписаных правил, где любая кажущаяся простота скрывает множество нюансов.
Слабая мотивация здесь не выживет. Желание «набить портфолио», «понять, как работают движки» или «сделать свой Unity» — неплохие стартовые импульсы, но они служат крайне плохим топливом для марафона длиною в годы.
Куда эффективнее работают прикладные запросы: «мне не хватает этого инструмента», «хочу спасти любимую игру от забвения», «хочу протестировать смелую идею» или «хочу создать компактный утилитарный модуль для встраивания».
Пример такого подхода — imspinner. Проект вырос из частного запроса на нестандартную анимацию загрузки. Я не стремился создать фреймворк или претендовать на глобальное решение: это просто легкий, встраиваемый набор индикаторов для Dear ImGui с четко очерченными границами ответственности, который можно легко внедрить и адаптировать.
Пет-проект — это не синоним обучения
Многие оправдывают отсутствие прогресса в пет-проектах фразой «я пишу свой движок ради обучения». Но практика показывает, что это не работает. Сделать движок «играбельным» удается единицам — меньше 0.1% от моих коллег. Яркие примеры — это работы Zenkovich, движок o2 и Melted Kingdoms (рекомендую добавить в список желаемого!).
Проблема в том, что, разрабатывая проект в одиночку, вы неизбежно будете застревать в зонах комфорта, игнорируя критически важные аспекты: инструменты, UI, пайплайны сборки, тестирование и документацию. В open-source это приводит к стагнации. Например, проект Cytopia как амбициозный градостроитель заглох, когда из него ушли ключевые разработчики — некому стало поддерживать технический фундамент и выстраивать понятную структуру для новых контрибьюторов.
Проекты вроде Augustus или OpenTTD демонстрируют обратную сторону — кодовую археологию. Работа с наследием — это не про современные курсы «как сделать игру за неделю», а про глубокое изучение устаревших форматов и ограничений ради сохранения аутентичного опыта.
Хотите учиться? Изучайте конкретные темы: ECS, сериализацию, профилирование, навигацию. Но будьте готовы к тому, что локальные упражнения лишены того гормонального драйва, который дает ощущение полноценного продукта.
Не каждый проект обязан становиться великим
Или становиться движком. Новички часто подпадают под влияние гигантов вроде Unreal или Unity и начинают мыслить категориями «игра» и «движок». Но между этими крайностями есть огромная ниша компактных библиотек и инструментов, знание которых зачастую важнее, чем поверхностное владение мощным движком.
Прелесть малых библиотек — в их сфокусированности. Они приучают к дисциплине: что делает этот инструмент? чего не делает? каковы границы его использования? Многие проекты гибнут, пытаясь сразу стать «комбайнами» с плагинами и редакторами, в то время как решение с ясным API имеет гораздо больше шансов на жизнь.
Ремейки — отдельная история, где собственный движок оправдан. Игроки чувствуют детали: отклик интерфейса, нюансы баланса, специфику поиска пути. Это невозможно имитировать «в лоб» на универсальных движках, не потеряв дух оригинала.
C++ остается фундаментом индустрии, но его цена для пет-проектов высока. Инфраструктура, шаблоны, управление памятью и платформенные различия — это колоссальный пласт работы, который зачастую превращает хобби в бесконечную борьбу со сложностью языка. Если ваша цель — создать игру, возможно, стоит использовать инструменты проще. После 20 лет с C++ я не уверен, что это всегда преимущество, скорее — привычка.
Open-source — это вторая работа
Открывая исходный код, вы открываете двери для сообщества: issues, pull requests, ожидания, форки. Это может стать колоссальным источником мотивации, но легко превращается в неблагодарную поддержку продукта. Разработка open-source геймдева требует управленческих навыков, терпения при общении с новичками и готовности брать на себя роль ментора.
В итоге, пет-проект живет долго, когда в его основе лежит не абстрактное желание «разобраться», а конкретная личная потребность, подкрепленная интересом единомышленников. Становясь полезным другим, ваш проект превращается в полноценную работу, где вознаграждением служат лишь ваш энтузиазм и развитие навыков. Если проект не отпускает — дерзайте, но осознанно выбирайте форму его существования, потому что хобби всегда оказывается сложнее и масштабнее, чем кажется на старте.
P.S. Если вас интересует градостроительство в сеттинге Древнего Египта, приглашаю в мой девблог, где я делюсь прогрессом разработки и интересными находками.
