Что будет, если открыть код игры

Почти 6 лет как я открыл исходный код Сказки под BSD-3 лицензией. Давно пора рассказать как это отразилось на игре и её разработке.

Вводная

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

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

Итак, контекст.

Я в сообществах геймдева и open source скорее всего типичный noname. Никогда не занимался мощным пиаром себя или игры. Большинство людей не знает ни об игре ни об её исходниках. Хотя на части площадок: Хабре, gamedev.ru, etc — я светился и люди, которые непосредственно заинтересованны в этом деле, посты должны были видеть.

До меня доходили слухи, что для каких-то сообществ открытие исходников Сказки стало «заметным событием», но я там свечку не держал, обсуждений не видел.

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

Игра нишевая, как по жанру, так и по реализованным фичам. Концепт-документ я публиковал.

Статистика игры открыта, метрики следующие, включая твинков:

• максимум MAU: 5000;
• максимум DAU: 2000;
• Всего зарегистрировано: ~28000;
• Платило хоть раз: 2130;
• Максимум единовременных подписчиков: ~600;

Сейчас MAU ~ 1700, DAU ~ 700.

Код игры изначально представлял собой монорепозиторий с монолитным проектом. Бэкенд на Python и Django. Фронтенд на jQuery.

При этом:

• В отдельные репозитории выделялись вспомогательные библиотеки: генераторы имён, карты, заданий, текста, etc.
• После открытия монолит дробился на микросервисы, которые лежат в монорепозитории рядом с основным проектом. Сейчас дробление завершено где-то на половину.

Сложность кода я бы оценил как среднюю. Есть откровенно сложные части: генерация заданий, текста, логика действий героев, но большей частью код довольно тривиален для веб-проекта.

Открыты код игры и графика, но не текстовый контент: описания монстров, артефактов, etc. Впрочем, добавление текстового контента не выглядит неподъёмной задачей.

Наблюдения

Писать код за вас не будут

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

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

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

У игры заметнее разделение между интересными (геймдизайн, геймплей) и неинтересными (инфраструктура) частями. Все хотят писать интересные и никто не хочет писать инфраструктуру. А надо наоборот :-)

В итоге опытные разработчики к вам не идут, так как они и своё могут написать, если захотят. Иногда — пару раз в год — приходят новички для «потренироваться», делают несколько минорных задач, если вообще делают, и пропадают.

Проще писать «не код»

Разработчиков, которые мотивированы на помощь вам, всегда будет мало среди игроков.

А вот игроков, которые не знакомы с разработкой, или знакомы поверхностно, или знакомы с другими технологиями, хватает.

Такие игроки, если заинтересуются, будут стараться помочь вам по мере сил и возможностей. Задача разработчика в этом случае: найти подходящие задачи и оформить в удобном для «простых смертных» виде.

Самый заметный пример из истории Сказки — перевод генератора имён на русский язык с учётом родов и падежей.

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

Более приземлённый пример: исправление опечаток сразу в коде игры. Не очень частое явление, но бывает.

Минуса тут два:

1. Выделить подобные задачи сложно.
2. Игроки не склонны проверять свою работу и вообще запускать код игры. Часто делают правки прямо на github, проверять их валидность приходится разработчику. Сейчас, благодаря github actions, делать это должно быть намного проще.

Код будут читать

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

Этим любят увлекаться:

• Манчкины (в широком смысле) — для хардкорного взаимодействия с игрой и написания мануалов.
• Разработчики расширений и прочего сопутствующего софта.

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

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

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

В частности, надо помнить, что некоторый сленг разработчиков может обижать людей извне сообщества. У меня случился подобный инцидент, когда опубликовал на хабре рассказ о работе с сообществом игроков. Если задуматься, то недавняя эпопея с выпиливанием master/slave того же рода.

В целом, доступность кода для чтения дала позитивный эффект:

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

Минусов не заметил.

Риском может быть демонстрация дыр в балансе и безопасности, обманных / манипулятивных механик. О первом вы быстрее узнаете как раз с открытыми исходниками. Вторым лучше не заниматься вовсе.

Issues будут обсуждать

Открытый список задач и багов — это возможность игрокам высказать своё мнение там, где вы его не ожидаете.

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

Доступ к задачам даёт игрокам удобный способ отслеживать их выполнение. Особенно это касается сообщений об ошибках и забытых разработчиком фичах.

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

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

У вас появится дополнительная нагрузка

Открывая код вы неявно берёте на себя дополнительные обязательства. Как минимум по обеспечению «доступности» кода для работы над ним сторонних людей.

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

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

Очень важна сложность входа в проект

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

В этом плане важно:

• Делать подробные мануалы на каждую операцию контрибьютора.
• Дробить проекта на малые части. Люди пугаются больших объёмов информации: длинных исходников, сложных инструкций, сложных иерархий каталогов, etc.
• Использовать популярные технологии. Утрируя, проект на Haskell под Linux найдёт меньше контрибьютеров, чем проект на JavaScript под Windows.

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

Альтернативный сервер так никто и не поднял

На сколько я знаю, локальные версии игры люди успешно поднимали, но до запуска альтернативного сервера никто так и не дошёл.

Предполагаю, из-за того, что оперирование игрой: наполнение её контентом, работа с сообществом —  не менее простые занятия, чем написание кода.

Код — лишь один из компонентов игры.

Также очевидно, что для поднятия альтернативных серверов не было финансового стимула. Если бы это был какой-нибудь WoW, то сервера появились бы моментально.

В любом случае, я не считаю, что «пиратские» сервера несут существенный финансовый риск для разработчика.

Если вы оперируете своей игрой настолько плохо, что люди, которые понимают её хуже вас, переманивают от вас игроков, то следует задуматься о компетентности команды и улучшении процессов (которые можно заимствовать у «пиратов»).

Пираты скорее расширяют рынок для вас и держат команду в тонусе.

Выводы

Открывать код полезно, но не обязательно открывать весь код.

Следует понимать, какого рода пользу его открытие несёт и какого рода нагрузку на разработчиков создаёт:

• Если вы не можете позволить себе нагрузку — не открывайте код.
• Если подобная польза для вас несущественна — не открывайте код.

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

Ценность вашей игры не только в коде и ресурсах, но и в вашей команде, в процессах разработки — воспроизвести их не просто. Также ценно само сообщество игроков.

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

А вот если ваш бизнес спорен с этической точки зрения, например, вы делаете free-2-play pay-to-win, то открывать что-либо, связанное с логикой игры, не стоит — пострадает ваша репутация, а энтузиасты быстро сделают клон, в который можно играть без страданий :-D

Открытие некоторых частей проекта я считаю особенно перспективным:

• Вспомогательных библиотек и/или библиотек с чётко очерченной логикой. Для таких проектов проще найти контрибьюторов. Плюс такие библиотеки хорошо чешут самолюбие разработчиков без риска для бизнеса.
• Открывать «не код», контент. Многие инди проекты давно делают локализации с помощью сообщества игроков.
• Код клиента, для некоторых многопользовательских игр. Если ваша серверная логика не верит клиенту на слово. Для клиента проще найти контрибьюторов, чем для сервера. Код клиента станет хорошим подспорьем для авторов проектов-спутников игры: рейтингов, статистики, etc.

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