1. Вступление
Эта статья — не попытка доказать, что на Cristalix плохо абсолютно всё, и не расследование того, как устроена вся разработка платформы.
Я могу подробно рассказать только о том опыте, который был у меня самого.
Несколько месяцев я разрабатывал для Cristalix игровой режим. За это время успел пройти получение доступов, работу с геймдизайнером и внутренней документацией, знакомство с инфраструктурой и API, обсуждение финансовых условий, несколько месяцев самой разработки — и в конечном итоге потерю статуса разработчика без какого-либо официального объяснения причины.
Часть событий у меня сохранилась в переписках. Некоторые разговоры остались в записях Discord. От части внутренней документации сохранились отдельные фрагменты. Что-то спустя месяцы я могу восстановить только по памяти.
Поэтому дальше я постараюсь придерживаться простого принципа:
если что-то можно подтвердить — я это показываю; если чего-то не знаю — так и пишу; если строю предположение — называю его предположением.
Это особенно важно потому, что в этой истории я сам далеко не всегда поступал идеально.
Я был начинающим разработчиком внутри незнакомой мне инфраструктуры. Иногда принимал спорные технические решения. После того как обнаружил возможность выдавать себе персонализацию, воспользовался ей больше одного раза, хотя уже понимал ценность этих предметов. После неудачной первой выплаты сам больше не возвращался к вопросу денег. Со временем мой темп работы значительно упал, а режим так и не был доведён до релиза.
Я не собираюсь вырезать эти моменты из истории только потому, что без них моя позиция выглядела бы удобнее.
Но наличие моих ошибок не означает, что остальные проблемы автоматически исчезают.
Разработчику всё равно нужно каким-то образом получить рабочие доступы. Ему всё равно нужно понимать, какая документация актуальна. Кто отвечает за геймдизайн. Где публикуются обязательные изменения API. Какие действия запрещены. Что происходит, если разработчика снимают. Кто и на каких условиях оплачивает работу, если режим ещё не вышел.
Именно об этом дальше и пойдёт речь.
Я не призываю воспринимать мой опыт как универсальный опыт каждого разработчика Cristalix. У других людей он вполне мог быть совершенно другим, а некоторые процессы с тех пор могли измениться.
Тем более я не собираюсь доказывать, что на Cristalix невозможно нормально работать.
Но если вы рассматриваете разработку на этой платформе, я бы хотел, чтобы до первой строки кода вы знали, какие вопросы вообще стоит задать.
Потому что большую часть этих вопросов я начал задавать уже после того, как ответы стали для меня проблемой.
2. Первый месяц разработки: сначала получи доступы
Моя разработка режима началась с довольно неожиданной проблемы: прежде чем разбираться с API, архитектурой или самим геймдизайном, мне сначала пришлось разобраться, как вообще получить всё необходимое для работы.
Нельзя сказать, что у Cristalix совсем отсутствует онбординг.
Когда 9 февраля мне наконец выдали основные права, я получил сообщение с данными для подключения к внутренней инфраструктуре и адресом сервера для разработки. На самом сервере находился README, где были описаны доступные базы данных и некоторые особенности окружения: MongoDB, Redis и другие сервисы, а также предупреждения о специфике работы тестовой машины.
В GitLab существовала и отдельная техническая документация. Например, там были инструкции по созданию плагина, подключению внутренних зависимостей, настройке Gradle, запуску DiamondPaper, регистрации сервера в Tower и использованию приватных тестовых реалмов.
То есть проблема была не в том, что разработчику вообще не дали никаких инструкций.
Проблема начиналась раньше.
Как получить то, к чему написана инструкция?
Ещё 1 января мне переслали список данных, необходимых для оформления доступов.
Нужно было указать ник, GitLab, контактные данные, публичный SSH-ключ, ID в dev-боте, куратора, описание того, чем я буду заниматься, и перечислить необходимые ресурсы.
Я передал запрошенную информацию.
После этого мне оставалось ждать.
Через несколько дней мой геймдизайнер неожиданно спросил:
Я не сразу понял, о чём речь.
Ему, в свою очередь, сказали, что я должен был каким-то образом самостоятельно податься на доступы.
Мне до этого такого процесса никто не объяснял.
У меня уже был Cristalix Dev Bot, но воспользоваться им я тоже не мог. Когда я спросил другого разработчика, почему бот не работает, тот объяснил, что меня сначала должен кто-то туда добавить.
Так постепенно и выяснялись отдельные части процесса.
«Может, я что-то ещё должен был заполнить?»
Прошла ещё почти неделя, но доступов всё ещё не было.
В какой-то момент я уже сам начал предполагать, что проблема находится на моей стороне:
Это довольно хорошо описывает ситуацию.
У меня не было страницы или статуса заявки, где было бы написано:
заявка создана → данные получены → ожидается ответственный → права будут выданы.
Поэтому невозможно было понять, происходит ли вообще что-нибудь.
16 января я снова пошёл выяснять причину задержки и получил новую информацию: оказывается, для выдачи прав кому-то должна была быть передана внутренняя задача.
Дальше возник новый вопрос — была ли эта задача вообще создана и какие данные в неё попали.
Мы с геймдизайнером обсуждали даже то, откуда в ней могли появиться мой ID в dev-боте и SSH-ключ, поскольку ему самому я эти данные не отправлял.
В итоге выяснилось, что задача всё-таки существовала.
Права всё равно пришлось ждать дальше.
Месяц до первой нормальной разработки
Основные права я получил только 9 февраля.
То есть между началом обсуждения работы в начале января и моментом, когда я смог нормально развернуть сервер и приступить к разработке, прошло больше месяца.
Причём это не было проблемой только моего конкретного аккаунта. В переписке обсуждалось, что доступа одновременно ждут и другие разработчики.
В какой-то момент мой геймдизайнер прямо сформулировал последствие:
После получения доступов ситуация стала значительно понятнее.
Я смог зайти на сервер, открыть README, посмотреть внутреннюю документацию, разобраться со сборкой проекта, подключить зависимости и запустить свой тестовый реалм.
И здесь важно провести границу.
Техническая документация на Cristalix существовала.
Разработчику действительно предоставлялись инструкции по запуску сервера и базовой работе с платформой.
Но до момента, когда я смог ими воспользоваться, мне пришлось больше месяца выяснять совершенно другой набор вопросов:
кто должен оформить мне доступы, должен ли я сам создавать заявку, кто создаёт её внутри, почему не работает dev-бот и на каком этапе вообще находится процесс.
Получается довольно странный онбординг: документация объясняет, как запустить сервер, но сначала разработчик должен самостоятельно выяснить, как получить возможность этот сервер запустить.
И это оказалось не последним случаем, когда необходимые для работы правила и процессы приходилось собирать по разным источникам.
3. «Тебе даже не придётся задумываться»: что происходит, когда разработка начинается раньше спецификации
Перед началом разработки мне описали довольно привлекательную модель работы.
Моим геймдизайнером был piwich. Формально для работы на Cristalix мне также требовался официальный куратор-разработчик — им стал Virum. Но почти всё общение по самому режиму, его механикам, документации и визуальной части шло именно через piwich. Virum в моей работе участвовал значительно меньше: помог с формальным оформлением и доступами, а непосредственно геймдизайном режима, насколько я видел, не занимался.
Моя задача как разработчика при этом должна была сводиться в первую очередь к технической реализации уже продуманной игры.
Именно piwich в первом голосовом разговоре описал это буквально так:
Эта цитата важна не потому, что я ожидал получить документ, в котором заранее описана каждая строка кода.
Речь о другом разделении ответственности.
Геймдизайнер определяет, что должно происходить в игре: правила, прогрессию, экономику, взаимодействие игрока с механиками, параметры баланса.
Разработчик уже решает, как это реализовать технически.
Именно такой формат я ожидал увидеть на практике.
Документация действительно была
Сразу оговорюсь: утверждать, что мне дали «пустой Notion», было бы неправильно.
В документации существовали вполне конкретные разделы.
Например, игровые события были описаны довольно подробно: указывался их эффект, продолжительность, период срабатывания и вероятность.
Для события «Денежный рай», например, было прописано увеличение получаемого золота на 100%, продолжительность в 15 минут, запуск каждый час и вероятность 50%.
Аналогично были описаны «Благословение удачи», изменения скорости мобов, временное усиление и ослабление башен.
Такой документ уже даёт разработчику достаточно понятное представление о желаемом поведении системы.
Но детализация сильно отличалась от раздела к разделу.
Описание мобов целиком сводилось примерно к следующему: вынести мобов в конфиг, указать здоровье, скорость, защиты, награду и модель, а траекторию движения хранить в локации.
Документ про сами локации был ещё короче:
Это уже описывает общую идею механики, но оставляет огромное пространство между словами «поддержка перехода» и готовым поведением режима.
Как игрок выбирает новую локацию?
Переход происходит автоматически или вручную?
Сохраняется ли прогресс старой?
Как выглядит интерфейс?
Когда новая локация открывается?
Что происходит с текущей волной?
Должен ли игрок физически перемещаться между разными игровыми пространствами или меняется состояние одного сервера?
Все эти варианты технически возможны и при этом дают совершенно разный игровой опыт.
Именно поэтому для меня разница между описанием концепции и спецификацией механики оказалась довольно существенной.
Разработка началась до того, как документация была закончена
Это проявилось буквально в первый день нормальной разработки.
9 февраля, сразу после получения доступов, я написал, что запустил сервер и собираюсь начинать писать код. Следом спросил, закончено ли ТЗ.
Ответ был прямым:
То есть разработка режима фактически стартовала в тот момент, когда документация ещё предполагала дописывание отдельных механик по мере того, как я до них дохожу.
Сам по себе такой подход не обязательно неправильный.
В обычной разработке требования действительно уточняются постепенно, а большой продукт редко проектируется полностью до первой строки кода.
Но тогда это уже заметно отличается от первоначально описанной мне модели, в которой режим заранее продуман настолько подробно, что разработчику остаётся только реализация.
Источник истины тоже не всегда был очевиден
11 февраля возник ещё один небольшой, но показательный пример.
В основном документе было указано 15 локаций.
В отдельном документе про локации — 10.
Когда я спросил об этом, мне объяснили, что основной документ делался для владельца сервера и относился к предыдущей версии концепции.
Такое расхождение само по себе не является серьёзной проблемой. Документация меняется.
Проблема появляется, когда разработчик не может сразу понять, какой документ актуален.
В нормальном рабочем процессе старая версия либо помечается как устаревшая, либо актуальные требования собираются в одном месте.
В моём случае определить это пришлось вопросом в личной переписке.
Чем дальше я проектировал систему, тем больше появлялось вопросов
13 февраля я уже начал проектировать архитектуру проекта и оставил в Notion комментарии к местам, которые, на мой взгляд, требовали уточнения.
Один из примеров касался прогрессии сложности волн.
Я сформулировал вопрос довольно конкретно: должна ли сложность расти линейно, экспоненциально или ступенчато.
В ответ получил примерно такую идею:
С точки зрения геймдизайна я понимаю смысл такого ответа: нужна гибкая формула, коэффициенты которой потом можно балансировать.
Но для разработчика следующий вопрос возникает моментально:
какая именно часть формулы должна быть изменяемой?
Можно вынести в конфигурацию коэффициенты, базовые значения и параметры кривой.
Можно поддержать несколько заранее определённых функций роста.
Можно вообще создать отдельную систему вычисления сложности.
Но выражение «формула, с которой потом можно будет играться» само по себе ещё не определяет интерфейс этой системы.
И здесь разработчик уже начинает не только реализовывать готовое решение, но и самостоятельно проектировать пространство будущих геймдизайнерских изменений.
Вопросы из Notion постепенно сменились объяснением голосом
После моих комментариев геймдизайнер действительно отвечал и предлагал уточнять непонятные моменты.
В какой-то момент он предложил снова сходить в Discord и объяснить общую концепцию режима, чтобы вопросов дальше возникало меньше.
Это помогало понять замысел.
Но насколько я помню, после этого сама документация уже практически не менялась.
Получалась довольно характерная модель:
документ описывает механику на верхнем уровне → при реализации возникает неоднозначность → я задаю вопрос → ответ приходит в комментарии или голосовом разговоре → код пишется уже с учётом устного контекста.
И именно здесь возникает проблема долговременной документации.
Через месяц разработчик ещё может помнить, что имелось в виду в Discord.
Через полгода — уже не обязательно.
Другой разработчик, который откроет тот же Notion, вообще этого разговора не слышал.
Где заканчивается реализация и начинается геймдизайн
К концу февраля эта граница стала ещё менее чёткой.
27 февраля, рассказывая о состоянии проекта, я сам написал, что основная техническая база уже готова, а дальше мне необходимо:
В качестве примера я прямо приводил вопрос: каким образом игрок должен запускать волну — через NPC или каким-то другим способом. Затем планировал переходить к меню.
Для меня это уже важный момент.
Написать обработчик нажатия на NPC — техническая реализация.
Но решить, должен ли там вообще быть NPC, кнопка в интерфейсе, автоматический запуск или совершенно другой сценарий, — это уже решение о пользовательском опыте режима.
И таких решений потенциально было много.
Я не утверждаю, что геймдизайнер обязан заранее определить расположение каждой кнопки и каждый технический нюанс.
Разработка почти всегда требует совместного обсуждения.
Но тогда корректнее и сам процесс описывать как совместное проектирование механик, а не как схему, где одна сторона полностью продумывает игру, а другая занимается исключительно реализацией.
И здесь появляется вопрос о 50%
В моей договорённости геймдизайнер piwich должен был получать половину той доли режима, которая оставалась команде.
Причём разделение обязанностей и финансовые условия мне изначально описывались вместе: piwich сначала объяснял, что полностью берёт на себя проработку режима, а затем предложил делить причитающиеся команде 30% поровну.
Сам по себе процент ничего не доказывает.
Геймдизайн — реальная работа. Кроме правил режима сюда могут входить экономика, баланс, UI, координация моделей, карт и других ресурсов.
И я не утверждаю, что piwich ничего не делал.
Это было бы неправдой: документация существовала, часть механик была описана достаточно подробно, он отвечал на вопросы, объяснял концепцию и занимался визуальной частью режима.
Мой вопрос в другом.
Если изначальная модель звучит как:
геймдизайнер полностью определяет игру → разработчик её реализует → доход делится пополам,
то естественно ожидать, что большая часть продуктовых решений будет определена до того момента, когда они блокируют разработку.
В моём случае часть этих решений продолжала формироваться уже параллельно с кодом.
После определённого момента документация практически перестала обновляться, а дальнейшие уточнения происходили преимущественно в переписке и голосом.
Поэтому проблема для меня заключалась не в том, что «ТЗ было пустым».
Проблема была в несоответствии между заявленным форматом работы и тем, как эта работа фактически происходила.
Мне обещали режим, в котором я практически не должен буду задаваться вопросами «что?» и «как?».
В реальности именно с этих вопросов и началась разработка.
4. Где разработчик должен узнавать, как здесь всё устроено
После получения основных доступов работать стало значительно проще: существовала документация по запуску сервера, внутренним зависимостям, Tower и базовой инфраструктуре.
Но довольно быстро выяснилось, что техническая документация — это только одна часть информации, которая нужна разработчику.
Помимо неё существовали изменения API, инфраструктурные работы, правила использования отдельных сервисов, дополнительные доступы и организационные процедуры. И вся эта информация могла находиться уже совсем в других местах.
Чат «Важная инфа», в котором меня не было
О существовании отдельного Telegram-чата с говорящим названием вроде «Важная инфа» я узнал от другого разработчика.
Сам я туда добавлен не был.
Причина мне до сих пор неизвестна.
Я пытался понять хотя бы принцип, по которому туда добавляют людей. От других разработчиков я слышал версию, что доступ может быть связан с уже выпущенным режимом, однако подтвердить это правило я не могу. Более того, по чужим сообщениям состав участников не всегда выглядел даже так: встречались случаи, когда в чате был стажёр разработчика, а самого разработчика там не было. Поэтому делать вывод о формальном критерии вступления я не берусь.
Самое показательное — содержание этого чата.
Например, там публиковалось предупреждение о планировавшемся вайпе и технических работах на:
Последняя фраза здесь особенно интересна.
Сам автор сообщения фактически учитывает, что часть Junior-разработчиков может отсутствовать в канале, где публикуется предупреждение о потенциальном удалении их данных.
То есть доставка важной информации строится примерно так:
сообщение появляется в закрытом чате → куратор должен увидеть его → вспомнить о своих Junior-разработчиках → переслать им информацию.
Если на каком-то этапе эта цепочка ломается, разработчик просто ничего не узнаёт.
Позже сообщение о вайпе отменили, но сам принцип от этого не меняется.
В этом же чате объявлялись изменения API
Речь шла не только о технических работах.
Например, там заранее предупредили, что возможность перемещать игрока через Client API — методы вроде, , , и — будет удалена и разработчикам необходимо заранее обновить свои моды.
Там же появлялись сообщения с просьбой проверить режимы на Java 25 перед будущим переходом всей инфраструктуры и информация об установке Java 25 и на машины разработки.
То есть это был не просто чат с новостями сообщества.
В нём находилась информация, которая потенциально напрямую влияет на код и инфраструктуру режима.
У меня к этому чату доступа не было.
На практике проблему частично решал мой знакомый разработчик: зная, что меня там нет, он пересылал мне сообщения, которые считал важными.
В какой-то момент я буквально написал ему:
Позже, иронично, примерно это и произошло с сервисом персонализации.
Конечно, я не могу утверждать, что наличие этого чата само по себе предотвратило бы историю с. Но сам факт хорошо показывает проблему: разработчик должен был надеяться, что другой разработчик заметит нужную информацию и перешлёт её ему.
Дополнительные инструменты тоже появлялись постепенно
Похожим образом выглядела работа с другими ресурсами.
Например, когда мне понадобилась Figma с дизайном режима, у меня не было прямого доступа к основному рабочему пространству Cristalix.
Сначала мой геймдизайнер предложил временную схему:
Позже меня добавили в отдельную Figma, куда он переносил нужные материалы. Насколько я помню, полноценного доступа к основному рабочему пространству Cristalix я так и не получил.
Сам по себе такой временный способ не является большой проблемой. В разработке постоянно возникают временные решения.
Но он снова показывает ту же модель: нужный инструмент не является частью заранее подготовленного рабочего окружения. Потребность появляется уже во время разработки, после чего начинается выяснение, кто должен предоставить доступ и каким способом это вообще делается.
Так происходило не со всем. Например, Cristalix Dev Bot содержал вполне понятные категории запросов: доступ к Grafana, машине, MongoDB, расширение прав, ревью кода, профилирование, проблемы с Core, клиентом и другими компонентами.
То есть определённая система поддержки разработчиков существовала.
Проблема скорее заключалась в том, что начинающий разработчик сначала должен был узнать о существовании конкретного ресурса, понять, что он ему нужен, а затем разобраться, через кого или через какую задачу его получать.
Даже доступ к исходникам зависел от уровня разработчика
Внутри Cristalix существовали уровни разработчиков — как минимум Junior, Middle и Senior.
Мой статус Junior отображался прямо в игре, и я видел разработчиков с более высокими рангами.
При этом чётких критериев повышения я нигде не видел.
Я слышал различные версии — например, что до Middle можно дорасти после выпуска собственного режима, — но не могу представить это как официальное правило, потому что соответствующей документации у меня не было.
Насколько я понимал по доступным ресурсам, статус разработчика был связан и с уровнем доступа к инфраструктуре.
Например, у меня был доступ к серверной части некоторых инструментов, но не ко всему клиентскому коду. Я мог использовать Enginex и даже изучать доступный мне собранный, однако репозитория с его исходным кодом у меня не было. Аналогично с WADA: серверную часть можно было изучать значительно свободнее, чем клиентскую реализацию визуальных механизмов.
Само ограничение здесь вполне понятно.
Разработчику необязательно выдавать исходники всей инфраструктуры только потому, что он пишет один игровой режим. Особенно когда речь идёт о клиентской части.
Вопрос снова возникает не к самому существованию уровней доступа, а к прозрачности системы.
Что доступно Junior? Что появляется у Middle? За что разработчика повышают? Кто принимает это решение? Какие дополнительные возможности появляются после релиза первого режима?
Ответов на эти вопросы у меня не было.
Большая часть моего понимания этой системы складывалась из разговоров с другими разработчиками.
Информация существовала — но не как единая система
Поэтому было бы неправильно сказать, что на Cristalix отсутствует документация.
Техническая документация была.
Был README на машине разработки.
Был GitLab с инструкциями.
Был Dev Bot с категориями запросов.
Существовали люди, которым можно было задавать вопросы.
Существовал отдельный чат с важными изменениями.
Проблема заключалась в том, что все эти элементы не складывались для меня в единый понятный процесс.
Один источник рассказывал, как запустить сервер.
Из другого можно было узнать об изменении API.
Третий разработчик сообщал о существовании второго источника.
Куратор помогал получить четвёртый доступ.
Критерии получения пятого ресурса оставались неизвестными.
В результате значительная часть знакомства с платформой происходила не по принципу:
«вот структура разработки Cristalix и всё, что тебе необходимо знать»,
а по принципу:
«столкнулся с необходимостью → спросил знакомого → узнал о новом инструменте или правиле → выяснил, у кого запросить доступ».
Пока речь идёт о Figma или дополнительном инструменте, это просто неудобство.
Гораздо интереснее становится тогда, когда таким же способом распространяются правила использования API, нарушение которых потенциально может закончиться полной потерей доступа к разработке.
Именно это, насколько я могу судить, произошло со мной несколькими месяцами позже.
5. «За что меня сняли?» — правило, о котором я узнал уже после снятия
В какой-то момент я просто перестал быть разработчиком Cristalix — по крайней мере, именно так это выглядело с моей стороны.
Утром друг прислал мне скриншот моего профиля и обратил внимание, что у меня исчезла привилегия разработчика. Я проверил сам: ранг действительно пропал, подключиться к тестовому серверу я больше не мог, а доступ к части внутренней инфраструктуры был отозван.
При этом мне никто ничего не написал.
Не было сообщения о снятии, причины, предупреждения или хотя бы формального уведомления о том, что я больше не являюсь разработчиком. Поэтому я до сих пор не могу достоверно утверждать, за что именно меня сняли.
Но есть одно обстоятельство, которое по совокупности событий выглядит наиболее вероятной причиной.
: метод, который я решил проверить
За некоторое время до снятия я изучал классы одного из внутренних плагинов Cristalix, доступного разработчикам.
Среди сервисов я обнаружил метод примерно следующего вида:
Никаких JavaDoc-комментариев, предупреждений или у него на тот момент, насколько я помню, не было.
Метод позволял выдать игроку персонализацию.
Персонализация на Cristalix — это не просто тестовый предмет. Значительная её часть приобретается за донатную валюту, получается из платных кейсов, за события или за высокие результаты на режимах. Я это понимал, поскольку сам играл на сервере много лет.
Именно поэтому наличие такого метода в доступном разработчику сервисе меня заинтересовало.
Я предположил, что он либо не позволит выдать настоящую глобальную персонализацию, либо будет работать только внутри тестового окружения. Тем более существовал отдельный тестовый сервер с бесплатной персонализацией, предназначенный именно для проверки моделей.
Я вызвал метод на себе.
Персонализация действительно выдалась и сохранилась после переподключения.
После этого я уже понимал, что речь идёт не о временном тестовом эффекте, и всё равно выдал себе ещё несколько предметов персонализации.
Это было моей ошибкой.
Техническая доступность метода сама по себе не означала, что я имел право использовать его как угодно. Сервис работал с ценными внутриигровыми предметами, и мне стоило отнестись к этому осторожнее.
Но именно здесь возникает другой вопрос: какое правило я нарушил и где разработчик должен был узнать о нём заранее?
Эту проблему я уже разбирал в предыдущей главе. В моём случае рядом с не было предупреждения о запрете самостоятельной выдачи, а отдельные правила использования подобных сервисов распространялись через внутренние каналы, к которым у меня не всегда был доступ.
Сам факт, что код режима может выдавать персонализацию, при этом не является чем-то невозможным: персонализация действительно используется как награда в игровых механиках. Поэтому из одной только сигнатуры метода невозможно понять, где именно проходит граница между допустимой выдачей игроку, тестированием и запрещённой выдачей самому себе.
Что произошло после этого
Насколько я сейчас помню хронологию, после первой выдачи прошло около двух недель.
Затем тестовый выделенный сервер на некоторое время стал недоступен. Позже через другого разработчика я узнал, что там проводятся технические работы; напрямую меня об их причине никто не уведомлял.
Примерно через неделю сервер снова стал доступен.
Я снова воспользовался выдачей персонализации.
А уже следующим утром обнаружил, что лишился прав разработчика.
В тот же день друг переслал мне сообщение из закрытого чата разработчиков, в котором меня самого не было.
В нём сообщалось об изменении сервиса персонализации: старый объявлялся устаревшим, вместо него вводился новый , а при каждой выдаче теперь требовалось указывать — понятную причину, по которой игрок получил персонализацию.
Также сообщалось, что через некоторое время выдача без заполненной причины перестанет работать.
Совпадение по времени выглядит показательно. Поэтому выдачу персонализации я считаю наиболее вероятной причиной своего снятия.
Но это всё ещё только версия.
Официальную причину мне никто не сообщил.
Новое API добавило учёт причины, но не объяснило само правило
Требование указывать выглядит логично: если внутриигровой предмет имеет реальную ценность, администрация должна иметь возможность понять, кто, кому и по какой причине его выдал.
При этом такой параметр решает прежде всего вопрос атрибуции и журналирования. Он не объясняет саму политику использования сервиса и не определяет автоматически, какие выдачи разрешены, а какие нет.
Разработчик всё ещё может передать произвольный текст. Значит, корректность действия по-прежнему зависит от внутренних правил.
Именно поэтому я не спорю с тем, что за самостоятельную выдачу ценной персонализации права могли отозвать. Я спорю с тем, что серьёзное правило, нарушение которого потенциально заканчивается полной потерей доступа к разработке, может оставаться для самого разработчика неочевидным до момента санкции.
Моя ошибка никуда не исчезает
Я не хочу строить эту историю вокруг тезиса «мне дали метод — значит, я имел право делать что угодно».
Нет.
Я должен был осторожнее относиться к сервису, который работает с ценной персонализацией. Если бы мне заранее прямо сказали, что выдавать её себе запрещено и за это можно лишиться статуса разработчика, я бы этого не делал.
Но даже если считать само снятие полностью оправданным, остаётся ещё один вопрос, не связанный уже с API.
Почему мне никто не написал о решении?
Если разработчик нарушил правило и за это лишается доступа, он как минимум должен получить сообщение:
что он нарушил, какое решение было принято и почему его доступы были отозваны.
В моём случае этого не произошло.
Я просто однажды перестал иметь доступ к инструментам, которыми пользовался ещё вчера.
6. Финансовая модель: 30%, 50/50 и первая выплата, которая так и не пришла
Финансовые условия моей работы тоже не были оформлены каким-либо договором или единым документом.
Основную схему мне объяснил piwich ещё во время первого голосового разговора.
По его словам, разработчику режима на Cristalix полагается 30% дохода от режима, после чего эта доля уже распределяется внутри команды — например, между разработчиком и куратором либо между разработчиком и геймдизайнером.
Я не могу подтвердить, что схема «30% команде» является официальным и неизменным правилом Cristalix для всех разработчиков.
В моём случае это информация, которую мне озвучил piwich.
30% команде и 50/50 между нами
Для нашего режима piwich предложил следующую схему:
100% дохода режима → 30% команде → эти 30% делятся между нами пополам.
То есть в случае релиза каждый из нас должен был получать по 15% от исходного дохода режима.
Оставшиеся 70%, соответственно, не входили в нашу долю.
Сам по себе такой процент я не считаю автоматически плохим.
Cristalix предоставляет аудиторию, инфраструктуру, серверы, платёжную систему, клиент, внутренние библиотеки и остальные ресурсы платформы. Поэтому тот факт, что платформа получает большую часть дохода, сам по себе ничего не говорит о справедливости или несправедливости модели.
Для меня интереснее была именно внутренняя договорённость 50/50.
piwich объяснял её тем, что с его стороны будет полностью проработан сам режим: экономика, механики и остальные элементы геймдизайна, а с моей стороны останется реализация.
Как я уже показывал в главе про ТЗ и геймдизайн, на практике граница между этими ролями оказалась менее чёткой.
Но финансово договорённость оставалась именно такой: после релиза мы делим командную долю пополам.
Пока режима нет, процентов тоже нет
Возникала очевидная проблема.
Разработка режима может занять месяцы, а процент от доната появляется только после релиза.
piwich отдельно объяснил мне, что, по его словам, сам Cristalix за период разработки режима ничего не платит.
Поэтому он предложил другую схему на время разработки — небольшую ежемесячную выплату уже из собственных денег.
Формулировка из разговора была не похожа на жёсткий трудовой договор с заранее зафиксированной суммой.
Он говорил примерно о:
и приводил ориентир:
Взамен предполагался простой отчёт: в конце месяца я показываю, что было сделано, желательно так, чтобы результат можно было посмотреть непосредственно на сервере, а при необходимости — и в коде.
То есть корректнее говорить не о строго установленной зарплате в 5 000 рублей, а об ориентировочной ежемесячной выплате порядка $50, о которой мы договорились устно.
Раньше я сам переводил эту сумму в рубли и поэтому описывал её как примерно 5 000 ₽. Но это создаёт ложное впечатление, будто именно 5 000 ₽ были жёстко зафиксированы.
Это не так.
8 марта: первая попытка получить оплату
Основные права разработчика я получил 9 февраля.
Примерно через месяц, 8 марта, я написал piwich:
Вместо того чтобы просто назвать заранее установленную сумму, он попросил меня залить актуальный код в GitLab, расписать, что сделано, показать состояние режима и отдельно спросил:
Это хорошо показывает, насколько неформальной была наша финансовая договорённость.
Если бы речь шла о строго установленной ставке в $50, вопрос «сколько ты хочешь» был бы довольно странным.
Я отправил отчёт.
К этому моменту были реализованы базовое ядро режима, система волн с динамической сложностью, башни с различными типами урона и стратегиями выбора целей, конфигурации мобов и башен, синхронизация настроек между серверами, игровые события и часть системы прогрессии.
После этого я назвал сумму:
Почему именно 7 500, а не эквивалент первоначально обсуждавшихся $50, сейчас я уже точно не восстановлю.
Скорее всего, я воспринимал первоначальную сумму именно как ориентир, а не фиксированную ставку, и учитывал объём сделанной за первый месяц работы.
Важно другое: в переписке piwich не возразил против названной суммы и не указал, что она расходится с нашей договорённостью.
Следующий его вопрос был уже о способе выплаты:
Это не доказывает отдельного формального согласования суммы, но показывает, что на этом этапе спор о её размере в переписке не возник.
Выплата через криптовалюту
Самостоятельно принять криптовалюту я тогда не мог.
В результате piwich сказал, что у него основная сумма находится именно в криптовалюте, а на банковской карте почти ничего нет, поэтому ему сначала необходимо вывести деньги.
По его словам, это должно было занять от одного до шести часов.
Через несколько часов он прислал скриншот процесса вывода и отдельно пошутил про обещанные сроки.
Я не могу по этому скриншоту установить, каким именно сервисом он пользовался, какая сумма выводилась и что в итоге произошло с транзакцией.
Поэтому утверждать, что история с выводом была выдумана, у меня оснований нет.
9 марта: деньги всё ещё не пришли
На следующий день piwich написал уже сам:
То есть он не отрицал саму выплату.
Наоборот, он прямо признавал, что деньги должен отправить мне после завершения вывода.
Я ответил:
После этого к вопросу оплаты мы больше не возвращались.
Я сам ему не напоминал.
Он тоже больше не написал ни о статусе вывода, ни о новой попытке перевода, ни о том, что выплата отменяется.
Денег я в итоге не получил.
Здесь важно не преувеличивать претензию
Я не могу написать, что месяцами требовал оплату, а меня месяцами игнорировали.
Такого не было.
После 9 марта я сам не поднимал этот вопрос снова.
Но есть другая последовательность, которую можно установить достаточно точно:
я попросил оплату за месяц работы;
по просьбе piwich показал состояние проекта и залил код;
назвал сумму около 7 500 ₽;
возражений по сумме в переписке не последовало;
piwich попытался организовать выплату;
затем сам написал о проблеме с выводом и пообещал отправить деньги, когда они придут;
после этого вопрос больше не поднимался ни одной стороной;
выплату я так и не получил.
Для меня проблема здесь даже не столько в самой сумме.
Проблема в том, что вся финансовая договорённость существовала практически полностью на уровне голосового разговора и нескольких сообщений.
Что произошло с мотивацией после этого
После марта я не бросил режим сразу.
Я продолжал писать код и ещё некоторое время рассчитывал довести проект до состояния, когда можно будет снова показать большой объём работы и уже нормально вернуться к разговору об оплате.
Но темп заметно снизился.
Это сложно свести к одной причине.
Были рефакторинги, сама разработка становилась тяжелее, а общение с геймдизайнером практически прекратилось.
Но неоплаченная первая выплата тоже явно не добавляла уверенности в том, что дальнейшие месяцы работы вообще имеют финансовый смысл.
К концу весны проект уже двигался значительно медленнее.
В июне я, насколько помню, занимался им лишь эпизодически.
До полноценного релиза режим так и не дошёл.
Что в итоге представляла собой финансовая модель
Если убрать эмоции, моя схема работы выглядела следующим образом.
До релиза Cristalix, по словам piwich, напрямую мне ничего не платил.
На время разработки сам piwich предложил небольшую ежемесячную выплату порядка $50 из собственных денег.
Размер при этом, судя по дальнейшей переписке, не был жёстко закреплён и мог обсуждаться в зависимости от выполненной работы.
После релиза режим должен был получать 30% своего дохода, а эта доля делилась между мной и геймдизайнером 50/50 — по 15% каждому от исходной суммы.
Ни один из этих пунктов у меня не был оформлен договором.
Я также не получил документа, который бы объяснял:
кто официально считается плательщиком;
когда именно наступает дата выплаты;
какой объём работы считается месяцем;
что происходит с оплатой, если режим не выходит;
что происходит при прекращении работы разработчика;
и кто отвечает за уже выполненную, но ещё не оплаченную работу.
Когда всё идёт хорошо, такие детали могут казаться бюрократией.
Когда первая же выплата не доходит, они внезапно становятся всей финансовой системой.
7. Что я бы хотел знать до начала разработки на Cristalix
Если свести всю эту историю к тезису «Cristalix плохой», получится слишком простая и, на мой взгляд, бесполезная статья.
У платформы есть собственная инфраструктура, внутренние библиотеки, техническая документация, инструменты для разработчиков, аудитория и возможность сделать режим, который сразу получит игроков.
Я видел работающие части этой системы и пользовался ими сам.
Проблемы начинались там, где техническая система встречалась с организационной.
Документация могла существовать, но до необходимых правил ещё нужно было добраться.
Доступы существовали, но процесс их получения приходилось выяснять по ходу дела.
У режима был геймдизайнер, но часть продуктовых решений всё равно переходила к разработчику уже во время реализации.
Существовал отдельный канал с важными изменениями, но меня в нём не было.
За действие с внутренним API я, вероятно, лишился статуса разработчика, однако официальной причины снятия так и не получил.
Финансовые условия были понятны ровно до того момента, пока первая реальная выплата не застряла и вся договорённость не оказалась несколькими сообщениями и голосовым разговором.
Ни одна из этих проблем по отдельности не выглядит катастрофой.
И, наверное, именно поэтому их легко игнорировать.
Можно один раз подождать доступы.
Можно спросить геймдизайнера в Discord.
Можно попросить друга переслать важное сообщение.
Можно поверить, что деньги придут позже.
Можно решить, что отсутствие уведомления о снятии — просто странность.
Но когда весь рабочий процесс постоянно держится на том, что разработчик сам найдёт нужного человека, задаст правильный вопрос и случайно не пропустит правило, совокупность таких мелочей становится уже не мелочью.
Что бы я спросил сейчас
Если бы я снова собирался начинать разработку режима на подобной платформе, до начала работы я бы хотел получить ответы хотя бы на следующие вопросы:
Если на эти вопросы нельзя получить нормальный ответ до начала работы, для меня теперь это уже причина задуматься, стоит ли вообще начинать.
Что я думаю о своём опыте сейчас
Я не считаю себя полностью правым во всех событиях этой истории.
Самый очевидный пример — персонализация. После первого вызова я уже понимал, что предметы сохраняются на аккаунте, и всё равно продолжил эксперимент. Даже при отсутствии явного запрета это было не самым разумным решением.
Я также мог настойчивее возвращаться к вопросу оплаты.
Мог быстрее закончить режим.
Мог раньше задавать некоторые вопросы.
Наверняка сейчас, имея больше опыта, часть технических решений я сделал бы иначе.
Но я не думаю, что нормальный процесс разработки должен работать только в том случае, если разработчик заранее угадывает все неписаные правила.
И именно это для меня осталось главным впечатлением от работы на Cristalix.
Слишком многое зависело не от явно описанного процесса, а от того, знаешь ли ты нужного человека, видел ли нужное сообщение, спросил ли вовремя и правильно ли понял устный ответ.
Если бы сегодня мне предложили снова работать на тех же условиях, я бы отказался.
Не потому, что считаю Cristalix абсолютно плохой платформой.
А потому, что после этого опыта для меня цена неопределённости стала слишком высокой: неопределённости в требованиях, правилах, доступах, ответственности и оплате.
Я не могу решать за другого разработчика, стоит ли ему идти туда работать.
Но могу посоветовать не воспринимать сам факт доступа к большой платформе как достаточную причину согласиться.
Сначала стоит понять, на что именно вы соглашаетесь.
Если эта статья заставит хотя бы одного разработчика задать все эти вопросы до начала нескольких месяцев работы, а не после них, значит, я написал её не зря.
Эта статья — не попытка доказать, что на Cristalix плохо абсолютно всё, и не расследование того, как устроена вся разработка платформы.
Я могу подробно рассказать только о том опыте, который был у меня самого.
Несколько месяцев я разрабатывал для Cristalix игровой режим. За это время успел пройти получение доступов, работу с геймдизайнером и внутренней документацией, знакомство с инфраструктурой и API, обсуждение финансовых условий, несколько месяцев самой разработки — и в конечном итоге потерю статуса разработчика без какого-либо официального объяснения причины.
Часть событий у меня сохранилась в переписках. Некоторые разговоры остались в записях Discord. От части внутренней документации сохранились отдельные фрагменты. Что-то спустя месяцы я могу восстановить только по памяти.
Поэтому дальше я постараюсь придерживаться простого принципа:
если что-то можно подтвердить — я это показываю; если чего-то не знаю — так и пишу; если строю предположение — называю его предположением.
Это особенно важно потому, что в этой истории я сам далеко не всегда поступал идеально.
Я был начинающим разработчиком внутри незнакомой мне инфраструктуры. Иногда принимал спорные технические решения. После того как обнаружил возможность выдавать себе персонализацию, воспользовался ей больше одного раза, хотя уже понимал ценность этих предметов. После неудачной первой выплаты сам больше не возвращался к вопросу денег. Со временем мой темп работы значительно упал, а режим так и не был доведён до релиза.
Я не собираюсь вырезать эти моменты из истории только потому, что без них моя позиция выглядела бы удобнее.
Но наличие моих ошибок не означает, что остальные проблемы автоматически исчезают.
Разработчику всё равно нужно каким-то образом получить рабочие доступы. Ему всё равно нужно понимать, какая документация актуальна. Кто отвечает за геймдизайн. Где публикуются обязательные изменения API. Какие действия запрещены. Что происходит, если разработчика снимают. Кто и на каких условиях оплачивает работу, если режим ещё не вышел.
Именно об этом дальше и пойдёт речь.
Я не призываю воспринимать мой опыт как универсальный опыт каждого разработчика Cristalix. У других людей он вполне мог быть совершенно другим, а некоторые процессы с тех пор могли измениться.
Тем более я не собираюсь доказывать, что на Cristalix невозможно нормально работать.
Но если вы рассматриваете разработку на этой платформе, я бы хотел, чтобы до первой строки кода вы знали, какие вопросы вообще стоит задать.
Потому что большую часть этих вопросов я начал задавать уже после того, как ответы стали для меня проблемой.
2. Первый месяц разработки: сначала получи доступы
Моя разработка режима началась с довольно неожиданной проблемы: прежде чем разбираться с API, архитектурой или самим геймдизайном, мне сначала пришлось разобраться, как вообще получить всё необходимое для работы.
Нельзя сказать, что у Cristalix совсем отсутствует онбординг.
Когда 9 февраля мне наконец выдали основные права, я получил сообщение с данными для подключения к внутренней инфраструктуре и адресом сервера для разработки. На самом сервере находился README, где были описаны доступные базы данных и некоторые особенности окружения: MongoDB, Redis и другие сервисы, а также предупреждения о специфике работы тестовой машины.
В GitLab существовала и отдельная техническая документация. Например, там были инструкции по созданию плагина, подключению внутренних зависимостей, настройке Gradle, запуску DiamondPaper, регистрации сервера в Tower и использованию приватных тестовых реалмов.
То есть проблема была не в том, что разработчику вообще не дали никаких инструкций.
Проблема начиналась раньше.
Как получить то, к чему написана инструкция?
Ещё 1 января мне переслали список данных, необходимых для оформления доступов.
Нужно было указать ник, GitLab, контактные данные, публичный SSH-ключ, ID в dev-боте, куратора, описание того, чем я буду заниматься, и перечислить необходимые ресурсы.
Я передал запрошенную информацию.
После этого мне оставалось ждать.
Через несколько дней мой геймдизайнер неожиданно спросил:
«ты на доступы подавался?»
Я не сразу понял, о чём речь.
Ему, в свою очередь, сказали, что я должен был каким-то образом самостоятельно податься на доступы.
Мне до этого такого процесса никто не объяснял.
У меня уже был Cristalix Dev Bot, но воспользоваться им я тоже не мог. Когда я спросил другого разработчика, почему бот не работает, тот объяснил, что меня сначала должен кто-то туда добавить.
Так постепенно и выяснялись отдельные части процесса.
«Может, я что-то ещё должен был заполнить?»
Прошла ещё почти неделя, но доступов всё ещё не было.
В какой-то момент я уже сам начал предполагать, что проблема находится на моей стороне:
«Я хз мб мне что то еще надо было заполнить»
Это довольно хорошо описывает ситуацию.
У меня не было страницы или статуса заявки, где было бы написано:
заявка создана → данные получены → ожидается ответственный → права будут выданы.
Поэтому невозможно было понять, происходит ли вообще что-нибудь.
16 января я снова пошёл выяснять причину задержки и получил новую информацию: оказывается, для выдачи прав кому-то должна была быть передана внутренняя задача.
Дальше возник новый вопрос — была ли эта задача вообще создана и какие данные в неё попали.
Мы с геймдизайнером обсуждали даже то, откуда в ней могли появиться мой ID в dev-боте и SSH-ключ, поскольку ему самому я эти данные не отправлял.
В итоге выяснилось, что задача всё-таки существовала.
Права всё равно пришлось ждать дальше.
Месяц до первой нормальной разработки
Основные права я получил только 9 февраля.
То есть между началом обсуждения работы в начале января и моментом, когда я смог нормально развернуть сервер и приступить к разработке, прошло больше месяца.
Причём это не было проблемой только моего конкретного аккаунта. В переписке обсуждалось, что доступа одновременно ждут и другие разработчики.
В какой-то момент мой геймдизайнер прямо сформулировал последствие:
«режим на месяц по факту задерживается»
«из-за прав»
После получения доступов ситуация стала значительно понятнее.
Я смог зайти на сервер, открыть README, посмотреть внутреннюю документацию, разобраться со сборкой проекта, подключить зависимости и запустить свой тестовый реалм.
И здесь важно провести границу.
Техническая документация на Cristalix существовала.
Разработчику действительно предоставлялись инструкции по запуску сервера и базовой работе с платформой.
Но до момента, когда я смог ими воспользоваться, мне пришлось больше месяца выяснять совершенно другой набор вопросов:
кто должен оформить мне доступы, должен ли я сам создавать заявку, кто создаёт её внутри, почему не работает dev-бот и на каком этапе вообще находится процесс.
Получается довольно странный онбординг: документация объясняет, как запустить сервер, но сначала разработчик должен самостоятельно выяснить, как получить возможность этот сервер запустить.
И это оказалось не последним случаем, когда необходимые для работы правила и процессы приходилось собирать по разным источникам.
3. «Тебе даже не придётся задумываться»: что происходит, когда разработка начинается раньше спецификации
Перед началом разработки мне описали довольно привлекательную модель работы.
Моим геймдизайнером был piwich. Формально для работы на Cristalix мне также требовался официальный куратор-разработчик — им стал Virum. Но почти всё общение по самому режиму, его механикам, документации и визуальной части шло именно через piwich. Virum в моей работе участвовал значительно меньше: помог с формальным оформлением и доступами, а непосредственно геймдизайном режима, насколько я видел, не занимался.
Моя задача как разработчика при этом должна была сводиться в первую очередь к технической реализации уже продуманной игры.
Именно piwich в первом голосовом разговоре описал это буквально так:
«вся экономика, весь режим, полностью будет прописан мной, просто целиком и полностью, каждая деталь будет продумана до момента, что тебе даже не придется задумываться, "а что?", "а как мне сделать?", ну, только реализация будет на тебе»
Эта цитата важна не потому, что я ожидал получить документ, в котором заранее описана каждая строка кода.
Речь о другом разделении ответственности.
Геймдизайнер определяет, что должно происходить в игре: правила, прогрессию, экономику, взаимодействие игрока с механиками, параметры баланса.
Разработчик уже решает, как это реализовать технически.
Именно такой формат я ожидал увидеть на практике.
Документация действительно была
Сразу оговорюсь: утверждать, что мне дали «пустой Notion», было бы неправильно.
В документации существовали вполне конкретные разделы.
Например, игровые события были описаны довольно подробно: указывался их эффект, продолжительность, период срабатывания и вероятность.
Для события «Денежный рай», например, было прописано увеличение получаемого золота на 100%, продолжительность в 15 минут, запуск каждый час и вероятность 50%.
Аналогично были описаны «Благословение удачи», изменения скорости мобов, временное усиление и ослабление башен.
Такой документ уже даёт разработчику достаточно понятное представление о желаемом поведении системы.
Но детализация сильно отличалась от раздела к разделу.
Описание мобов целиком сводилось примерно к следующему: вынести мобов в конфиг, указать здоровье, скорость, защиты, награду и модель, а траекторию движения хранить в локации.
Документ про сами локации был ещё короче:
«На режиме есть 10 локаций, на каждой локе свои мобы/карта/путь мобов. В целом нужно сделать поддержку перехода по локациям и смену мобов».
Это уже описывает общую идею механики, но оставляет огромное пространство между словами «поддержка перехода» и готовым поведением режима.
Как игрок выбирает новую локацию?
Переход происходит автоматически или вручную?
Сохраняется ли прогресс старой?
Как выглядит интерфейс?
Когда новая локация открывается?
Что происходит с текущей волной?
Должен ли игрок физически перемещаться между разными игровыми пространствами или меняется состояние одного сервера?
Все эти варианты технически возможны и при этом дают совершенно разный игровой опыт.
Именно поэтому для меня разница между описанием концепции и спецификацией механики оказалась довольно существенной.
Разработка началась до того, как документация была закончена
Это проявилось буквально в первый день нормальной разработки.
9 февраля, сразу после получения доступов, я написал, что запустил сервер и собираюсь начинать писать код. Следом спросил, закончено ли ТЗ.
Ответ был прямым:
«нет, скажи с какой механики хочешь начать, я ее напишу полностью»
То есть разработка режима фактически стартовала в тот момент, когда документация ещё предполагала дописывание отдельных механик по мере того, как я до них дохожу.
Сам по себе такой подход не обязательно неправильный.
В обычной разработке требования действительно уточняются постепенно, а большой продукт редко проектируется полностью до первой строки кода.
Но тогда это уже заметно отличается от первоначально описанной мне модели, в которой режим заранее продуман настолько подробно, что разработчику остаётся только реализация.
Источник истины тоже не всегда был очевиден
11 февраля возник ещё один небольшой, но показательный пример.
В основном документе было указано 15 локаций.
В отдельном документе про локации — 10.
Когда я спросил об этом, мне объяснили, что основной документ делался для владельца сервера и относился к предыдущей версии концепции.
Такое расхождение само по себе не является серьёзной проблемой. Документация меняется.
Проблема появляется, когда разработчик не может сразу понять, какой документ актуален.
В нормальном рабочем процессе старая версия либо помечается как устаревшая, либо актуальные требования собираются в одном месте.
В моём случае определить это пришлось вопросом в личной переписке.
Чем дальше я проектировал систему, тем больше появлялось вопросов
13 февраля я уже начал проектировать архитектуру проекта и оставил в Notion комментарии к местам, которые, на мой взгляд, требовали уточнения.
Один из примеров касался прогрессии сложности волн.
Я сформулировал вопрос довольно конкретно: должна ли сложность расти линейно, экспоненциально или ступенчато.
В ответ получил примерно такую идею:
«Вообще можно просто поставить формулу, с которой я потом буду играться, прогрессия будет по формуле схожей с экспоненциальной, но со своими особенностями, просто скейли ХП по формуле».
С точки зрения геймдизайна я понимаю смысл такого ответа: нужна гибкая формула, коэффициенты которой потом можно балансировать.
Но для разработчика следующий вопрос возникает моментально:
какая именно часть формулы должна быть изменяемой?
Можно вынести в конфигурацию коэффициенты, базовые значения и параметры кривой.
Можно поддержать несколько заранее определённых функций роста.
Можно вообще создать отдельную систему вычисления сложности.
Но выражение «формула, с которой потом можно будет играться» само по себе ещё не определяет интерфейс этой системы.
И здесь разработчик уже начинает не только реализовывать готовое решение, но и самостоятельно проектировать пространство будущих геймдизайнерских изменений.
Вопросы из Notion постепенно сменились объяснением голосом
После моих комментариев геймдизайнер действительно отвечал и предлагал уточнять непонятные моменты.
В какой-то момент он предложил снова сходить в Discord и объяснить общую концепцию режима, чтобы вопросов дальше возникало меньше.
Это помогало понять замысел.
Но насколько я помню, после этого сама документация уже практически не менялась.
Получалась довольно характерная модель:
документ описывает механику на верхнем уровне → при реализации возникает неоднозначность → я задаю вопрос → ответ приходит в комментарии или голосовом разговоре → код пишется уже с учётом устного контекста.
И именно здесь возникает проблема долговременной документации.
Через месяц разработчик ещё может помнить, что имелось в виду в Discord.
Через полгода — уже не обязательно.
Другой разработчик, который откроет тот же Notion, вообще этого разговора не слышал.
Где заканчивается реализация и начинается геймдизайн
К концу февраля эта граница стала ещё менее чёткой.
27 февраля, рассказывая о состоянии проекта, я сам написал, что основная техническая база уже готова, а дальше мне необходимо:
«продумать как игрок должен взаимодействовать с этими механиками»
В качестве примера я прямо приводил вопрос: каким образом игрок должен запускать волну — через NPC или каким-то другим способом. Затем планировал переходить к меню.
Для меня это уже важный момент.
Написать обработчик нажатия на NPC — техническая реализация.
Но решить, должен ли там вообще быть NPC, кнопка в интерфейсе, автоматический запуск или совершенно другой сценарий, — это уже решение о пользовательском опыте режима.
И таких решений потенциально было много.
Я не утверждаю, что геймдизайнер обязан заранее определить расположение каждой кнопки и каждый технический нюанс.
Разработка почти всегда требует совместного обсуждения.
Но тогда корректнее и сам процесс описывать как совместное проектирование механик, а не как схему, где одна сторона полностью продумывает игру, а другая занимается исключительно реализацией.
И здесь появляется вопрос о 50%
В моей договорённости геймдизайнер piwich должен был получать половину той доли режима, которая оставалась команде.
Причём разделение обязанностей и финансовые условия мне изначально описывались вместе: piwich сначала объяснял, что полностью берёт на себя проработку режима, а затем предложил делить причитающиеся команде 30% поровну.
Сам по себе процент ничего не доказывает.
Геймдизайн — реальная работа. Кроме правил режима сюда могут входить экономика, баланс, UI, координация моделей, карт и других ресурсов.
И я не утверждаю, что piwich ничего не делал.
Это было бы неправдой: документация существовала, часть механик была описана достаточно подробно, он отвечал на вопросы, объяснял концепцию и занимался визуальной частью режима.
Мой вопрос в другом.
Если изначальная модель звучит как:
геймдизайнер полностью определяет игру → разработчик её реализует → доход делится пополам,
то естественно ожидать, что большая часть продуктовых решений будет определена до того момента, когда они блокируют разработку.
В моём случае часть этих решений продолжала формироваться уже параллельно с кодом.
После определённого момента документация практически перестала обновляться, а дальнейшие уточнения происходили преимущественно в переписке и голосом.
Поэтому проблема для меня заключалась не в том, что «ТЗ было пустым».
Проблема была в несоответствии между заявленным форматом работы и тем, как эта работа фактически происходила.
Мне обещали режим, в котором я практически не должен буду задаваться вопросами «что?» и «как?».
В реальности именно с этих вопросов и началась разработка.
4. Где разработчик должен узнавать, как здесь всё устроено
После получения основных доступов работать стало значительно проще: существовала документация по запуску сервера, внутренним зависимостям, Tower и базовой инфраструктуре.
Но довольно быстро выяснилось, что техническая документация — это только одна часть информации, которая нужна разработчику.
Помимо неё существовали изменения API, инфраструктурные работы, правила использования отдельных сервисов, дополнительные доступы и организационные процедуры. И вся эта информация могла находиться уже совсем в других местах.
Чат «Важная инфа», в котором меня не было
О существовании отдельного Telegram-чата с говорящим названием вроде «Важная инфа» я узнал от другого разработчика.
Сам я туда добавлен не был.
Причина мне до сих пор неизвестна.
Я пытался понять хотя бы принцип, по которому туда добавляют людей. От других разработчиков я слышал версию, что доступ может быть связан с уже выпущенным режимом, однако подтвердить это правило я не могу. Более того, по чужим сообщениям состав участников не всегда выглядел даже так: встречались случаи, когда в чате был стажёр разработчика, а самого разработчика там не было. Поэтому делать вывод о формальном критерии вступления я не берусь.
Самое показательное — содержание этого чата.
Например, там публиковалось предупреждение о планировавшемся вайпе и технических работах на
Код:
mokou.dedi.c7x.dev«Ожидаемый вайп+техработы на31 числа, пожалуйста заберите все свои данные. Кураторы — передайте джунам которых тут может не быть».Код:mokou.dedi.c7x.dev
Последняя фраза здесь особенно интересна.
Сам автор сообщения фактически учитывает, что часть Junior-разработчиков может отсутствовать в канале, где публикуется предупреждение о потенциальном удалении их данных.
То есть доставка важной информации строится примерно так:
сообщение появляется в закрытом чате → куратор должен увидеть его → вспомнить о своих Junior-разработчиках → переслать им информацию.
Если на каком-то этапе эта цепочка ломается, разработчик просто ничего не узнаёт.
Позже сообщение о вайпе отменили, но сам принцип от этого не меняется.
В этом же чате объявлялись изменения API
Речь шла не только о технических работах.
Например, там заранее предупредили, что возможность перемещать игрока через Client API — методы вроде
Код:
setMotion Код:
setMotionX Код:
setMotionY Код:
setMotionZ Код:
teleportТам же появлялись сообщения с просьбой проверить режимы на Java 25 перед будущим переходом всей инфраструктуры и информация об установке Java 25 и
Код:
async-profilerТо есть это был не просто чат с новостями сообщества.
В нём находилась информация, которая потенциально напрямую влияет на код и инфраструктуру режима.
У меня к этому чату доступа не было.
На практике проблему частично решал мой знакомый разработчик: зная, что меня там нет, он пересылал мне сообщения, которые считал важными.
В какой-то момент я буквально написал ему:
«Вдруг там важное будет, а я не узнаю и хуйню сделаю».
Позже, иронично, примерно это и произошло с сервисом персонализации.
Конечно, я не могу утверждать, что наличие этого чата само по себе предотвратило бы историю с
Код:
giveModelДополнительные инструменты тоже появлялись постепенно
Похожим образом выглядела работа с другими ресурсами.
Например, когда мне понадобилась Figma с дизайном режима, у меня не было прямого доступа к основному рабочему пространству Cristalix.
Сначала мой геймдизайнер предложил временную схему:
«я тебе буду в локальную фигму дизайн закидывать с фигмы кристы, а ты уже оттуда брать будешь»
Позже меня добавили в отдельную Figma, куда он переносил нужные материалы. Насколько я помню, полноценного доступа к основному рабочему пространству Cristalix я так и не получил.
Сам по себе такой временный способ не является большой проблемой. В разработке постоянно возникают временные решения.
Но он снова показывает ту же модель: нужный инструмент не является частью заранее подготовленного рабочего окружения. Потребность появляется уже во время разработки, после чего начинается выяснение, кто должен предоставить доступ и каким способом это вообще делается.
Так происходило не со всем. Например, Cristalix Dev Bot содержал вполне понятные категории запросов: доступ к Grafana, машине, MongoDB, расширение прав, ревью кода, профилирование, проблемы с Core, клиентом и другими компонентами.
То есть определённая система поддержки разработчиков существовала.
Проблема скорее заключалась в том, что начинающий разработчик сначала должен был узнать о существовании конкретного ресурса, понять, что он ему нужен, а затем разобраться, через кого или через какую задачу его получать.
Даже доступ к исходникам зависел от уровня разработчика
Внутри Cristalix существовали уровни разработчиков — как минимум Junior, Middle и Senior.
Мой статус Junior отображался прямо в игре, и я видел разработчиков с более высокими рангами.
При этом чётких критериев повышения я нигде не видел.
Я слышал различные версии — например, что до Middle можно дорасти после выпуска собственного режима, — но не могу представить это как официальное правило, потому что соответствующей документации у меня не было.
Насколько я понимал по доступным ресурсам, статус разработчика был связан и с уровнем доступа к инфраструктуре.
Например, у меня был доступ к серверной части некоторых инструментов, но не ко всему клиентскому коду. Я мог использовать Enginex и даже изучать доступный мне собранный
Код:
.jarСамо ограничение здесь вполне понятно.
Разработчику необязательно выдавать исходники всей инфраструктуры только потому, что он пишет один игровой режим. Особенно когда речь идёт о клиентской части.
Вопрос снова возникает не к самому существованию уровней доступа, а к прозрачности системы.
Что доступно Junior? Что появляется у Middle? За что разработчика повышают? Кто принимает это решение? Какие дополнительные возможности появляются после релиза первого режима?
Ответов на эти вопросы у меня не было.
Большая часть моего понимания этой системы складывалась из разговоров с другими разработчиками.
Информация существовала — но не как единая система
Поэтому было бы неправильно сказать, что на Cristalix отсутствует документация.
Техническая документация была.
Был README на машине разработки.
Был GitLab с инструкциями.
Был Dev Bot с категориями запросов.
Существовали люди, которым можно было задавать вопросы.
Существовал отдельный чат с важными изменениями.
Проблема заключалась в том, что все эти элементы не складывались для меня в единый понятный процесс.
Один источник рассказывал, как запустить сервер.
Из другого можно было узнать об изменении API.
Третий разработчик сообщал о существовании второго источника.
Куратор помогал получить четвёртый доступ.
Критерии получения пятого ресурса оставались неизвестными.
В результате значительная часть знакомства с платформой происходила не по принципу:
«вот структура разработки Cristalix и всё, что тебе необходимо знать»,
а по принципу:
«столкнулся с необходимостью → спросил знакомого → узнал о новом инструменте или правиле → выяснил, у кого запросить доступ».
Пока речь идёт о Figma или дополнительном инструменте, это просто неудобство.
Гораздо интереснее становится тогда, когда таким же способом распространяются правила использования API, нарушение которых потенциально может закончиться полной потерей доступа к разработке.
Именно это, насколько я могу судить, произошло со мной несколькими месяцами позже.
5. «За что меня сняли?» — правило, о котором я узнал уже после снятия
В какой-то момент я просто перестал быть разработчиком Cristalix — по крайней мере, именно так это выглядело с моей стороны.
Утром друг прислал мне скриншот моего профиля и обратил внимание, что у меня исчезла привилегия разработчика. Я проверил сам: ранг действительно пропал, подключиться к тестовому серверу я больше не мог, а доступ к части внутренней инфраструктуры был отозван.
При этом мне никто ничего не написал.
Не было сообщения о снятии, причины, предупреждения или хотя бы формального уведомления о том, что я больше не являюсь разработчиком. Поэтому я до сих пор не могу достоверно утверждать, за что именно меня сняли.
Но есть одно обстоятельство, которое по совокупности событий выглядит наиболее вероятной причиной.
Код:
giveModelЗа некоторое время до снятия я изучал классы одного из внутренних плагинов Cristalix, доступного разработчикам.
Среди сервисов я обнаружил метод примерно следующего вида:
Код:
giveModel(UUID unitId, int amount)Никаких JavaDoc-комментариев, предупреждений или
Код:
@DeprecatedМетод позволял выдать игроку персонализацию.
Персонализация на Cristalix — это не просто тестовый предмет. Значительная её часть приобретается за донатную валюту, получается из платных кейсов, за события или за высокие результаты на режимах. Я это понимал, поскольку сам играл на сервере много лет.
Именно поэтому наличие такого метода в доступном разработчику сервисе меня заинтересовало.
Я предположил, что он либо не позволит выдать настоящую глобальную персонализацию, либо будет работать только внутри тестового окружения. Тем более существовал отдельный тестовый сервер с бесплатной персонализацией, предназначенный именно для проверки моделей.
Я вызвал метод на себе.
Персонализация действительно выдалась и сохранилась после переподключения.
После этого я уже понимал, что речь идёт не о временном тестовом эффекте, и всё равно выдал себе ещё несколько предметов персонализации.
Это было моей ошибкой.
Техническая доступность метода сама по себе не означала, что я имел право использовать его как угодно. Сервис работал с ценными внутриигровыми предметами, и мне стоило отнестись к этому осторожнее.
Но именно здесь возникает другой вопрос: какое правило я нарушил и где разработчик должен был узнать о нём заранее?
Эту проблему я уже разбирал в предыдущей главе. В моём случае рядом с
Код:
giveModelСам факт, что код режима может выдавать персонализацию, при этом не является чем-то невозможным: персонализация действительно используется как награда в игровых механиках. Поэтому из одной только сигнатуры метода невозможно понять, где именно проходит граница между допустимой выдачей игроку, тестированием и запрещённой выдачей самому себе.
Что произошло после этого
Насколько я сейчас помню хронологию, после первой выдачи прошло около двух недель.
Затем тестовый выделенный сервер на некоторое время стал недоступен. Позже через другого разработчика я узнал, что там проводятся технические работы; напрямую меня об их причине никто не уведомлял.
Примерно через неделю сервер снова стал доступен.
Я снова воспользовался выдачей персонализации.
А уже следующим утром обнаружил, что лишился прав разработчика.
В тот же день друг переслал мне сообщение из закрытого чата разработчиков, в котором меня самого не было.
В нём сообщалось об изменении сервиса персонализации: старый
Код:
giveModel Код:
giveP13n Код:
commentТакже сообщалось, что через некоторое время выдача без заполненной причины перестанет работать.
Совпадение по времени выглядит показательно. Поэтому выдачу персонализации я считаю наиболее вероятной причиной своего снятия.
Но это всё ещё только версия.
Официальную причину мне никто не сообщил.
Новое API добавило учёт причины, но не объяснило само правило
Требование указывать
Код:
commentПри этом такой параметр решает прежде всего вопрос атрибуции и журналирования. Он не объясняет саму политику использования сервиса и не определяет автоматически, какие выдачи разрешены, а какие нет.
Разработчик всё ещё может передать произвольный текст. Значит, корректность действия по-прежнему зависит от внутренних правил.
Именно поэтому я не спорю с тем, что за самостоятельную выдачу ценной персонализации права могли отозвать. Я спорю с тем, что серьёзное правило, нарушение которого потенциально заканчивается полной потерей доступа к разработке, может оставаться для самого разработчика неочевидным до момента санкции.
Моя ошибка никуда не исчезает
Я не хочу строить эту историю вокруг тезиса «мне дали метод — значит, я имел право делать что угодно».
Нет.
Я должен был осторожнее относиться к сервису, который работает с ценной персонализацией. Если бы мне заранее прямо сказали, что выдавать её себе запрещено и за это можно лишиться статуса разработчика, я бы этого не делал.
Но даже если считать само снятие полностью оправданным, остаётся ещё один вопрос, не связанный уже с API.
Почему мне никто не написал о решении?
Если разработчик нарушил правило и за это лишается доступа, он как минимум должен получить сообщение:
что он нарушил, какое решение было принято и почему его доступы были отозваны.
В моём случае этого не произошло.
Я просто однажды перестал иметь доступ к инструментам, которыми пользовался ещё вчера.
6. Финансовая модель: 30%, 50/50 и первая выплата, которая так и не пришла
Финансовые условия моей работы тоже не были оформлены каким-либо договором или единым документом.
Основную схему мне объяснил piwich ещё во время первого голосового разговора.
По его словам, разработчику режима на Cristalix полагается 30% дохода от режима, после чего эта доля уже распределяется внутри команды — например, между разработчиком и куратором либо между разработчиком и геймдизайнером.
Я не могу подтвердить, что схема «30% команде» является официальным и неизменным правилом Cristalix для всех разработчиков.
В моём случае это информация, которую мне озвучил piwich.
30% команде и 50/50 между нами
Для нашего режима piwich предложил следующую схему:
100% дохода режима → 30% команде → эти 30% делятся между нами пополам.
То есть в случае релиза каждый из нас должен был получать по 15% от исходного дохода режима.
Оставшиеся 70%, соответственно, не входили в нашу долю.
Сам по себе такой процент я не считаю автоматически плохим.
Cristalix предоставляет аудиторию, инфраструктуру, серверы, платёжную систему, клиент, внутренние библиотеки и остальные ресурсы платформы. Поэтому тот факт, что платформа получает большую часть дохода, сам по себе ничего не говорит о справедливости или несправедливости модели.
Для меня интереснее была именно внутренняя договорённость 50/50.
piwich объяснял её тем, что с его стороны будет полностью проработан сам режим: экономика, механики и остальные элементы геймдизайна, а с моей стороны останется реализация.
Как я уже показывал в главе про ТЗ и геймдизайн, на практике граница между этими ролями оказалась менее чёткой.
Но финансово договорённость оставалась именно такой: после релиза мы делим командную долю пополам.
Пока режима нет, процентов тоже нет
Возникала очевидная проблема.
Разработка режима может занять месяцы, а процент от доната появляется только после релиза.
piwich отдельно объяснил мне, что, по его словам, сам Cristalix за период разработки режима ничего не платит.
Поэтому он предложил другую схему на время разработки — небольшую ежемесячную выплату уже из собственных денег.
Формулировка из разговора была не похожа на жёсткий трудовой договор с заранее зафиксированной суммой.
Он говорил примерно о:
«какой-то символической сумме»
и приводил ориентир:
«что-то типа долларов 50»
Взамен предполагался простой отчёт: в конце месяца я показываю, что было сделано, желательно так, чтобы результат можно было посмотреть непосредственно на сервере, а при необходимости — и в коде.
То есть корректнее говорить не о строго установленной зарплате в 5 000 рублей, а об ориентировочной ежемесячной выплате порядка $50, о которой мы договорились устно.
Раньше я сам переводил эту сумму в рубли и поэтому описывал её как примерно 5 000 ₽. Но это создаёт ложное впечатление, будто именно 5 000 ₽ были жёстко зафиксированы.
Это не так.
8 марта: первая попытка получить оплату
Основные права разработчика я получил 9 февраля.
Примерно через месяц, 8 марта, я написал piwich:
«Привет, можно щас оплату за месяц получить?»
Вместо того чтобы просто назвать заранее установленную сумму, он попросил меня залить актуальный код в GitLab, расписать, что сделано, показать состояние режима и отдельно спросил:
«и скок ты хочешь денег»
Это хорошо показывает, насколько неформальной была наша финансовая договорённость.
Если бы речь шла о строго установленной ставке в $50, вопрос «сколько ты хочешь» был бы довольно странным.
Я отправил отчёт.
К этому моменту были реализованы базовое ядро режима, система волн с динамической сложностью, башни с различными типами урона и стратегиями выбора целей, конфигурации мобов и башен, синхронизация настроек между серверами, игровые события и часть системы прогрессии.
После этого я назвал сумму:
«по деньгам гдет 7.5к+-»
Почему именно 7 500, а не эквивалент первоначально обсуждавшихся $50, сейчас я уже точно не восстановлю.
Скорее всего, я воспринимал первоначальную сумму именно как ориентир, а не фиксированную ставку, и учитывал объём сделанной за первый месяц работы.
Важно другое: в переписке piwich не возразил против названной суммы и не указал, что она расходится с нашей договорённостью.
Следующий его вопрос был уже о способе выплаты:
«у тебя крипта есть?»
Это не доказывает отдельного формального согласования суммы, но показывает, что на этом этапе спор о её размере в переписке не возник.
Выплата через криптовалюту
Самостоятельно принять криптовалюту я тогда не мог.
В результате piwich сказал, что у него основная сумма находится именно в криптовалюте, а на банковской карте почти ничего нет, поэтому ему сначала необходимо вывести деньги.
По его словам, это должно было занять от одного до шести часов.
Через несколько часов он прислал скриншот процесса вывода и отдельно пошутил про обещанные сроки.
Я не могу по этому скриншоту установить, каким именно сервисом он пользовался, какая сумма выводилась и что в итоге произошло с транзакцией.
Поэтому утверждать, что история с выводом была выдумана, у меня оснований нет.
9 марта: деньги всё ещё не пришли
На следующий день piwich написал уже сам:
«привет, оч сильно извиняюсь, тут пи##ец какой-то с выводом, я в тп писал типы такие деньги должны прийти, я думал я проебался, проверил данные - все правильно, я понимаю, что это не твоя проблема вообще, как только деньги придут - я тебе сразу закину, ещё раз сорри»
То есть он не отрицал саму выплату.
Наоборот, он прямо признавал, что деньги должен отправить мне после завершения вывода.
Я ответил:
«Не срочно в принципе. Все норм».
После этого к вопросу оплаты мы больше не возвращались.
Я сам ему не напоминал.
Он тоже больше не написал ни о статусе вывода, ни о новой попытке перевода, ни о том, что выплата отменяется.
Денег я в итоге не получил.
Здесь важно не преувеличивать претензию
Я не могу написать, что месяцами требовал оплату, а меня месяцами игнорировали.
Такого не было.
После 9 марта я сам не поднимал этот вопрос снова.
Но есть другая последовательность, которую можно установить достаточно точно:
я попросил оплату за месяц работы;
по просьбе piwich показал состояние проекта и залил код;
назвал сумму около 7 500 ₽;
возражений по сумме в переписке не последовало;
piwich попытался организовать выплату;
затем сам написал о проблеме с выводом и пообещал отправить деньги, когда они придут;
после этого вопрос больше не поднимался ни одной стороной;
выплату я так и не получил.
Для меня проблема здесь даже не столько в самой сумме.
Проблема в том, что вся финансовая договорённость существовала практически полностью на уровне голосового разговора и нескольких сообщений.
Что произошло с мотивацией после этого
После марта я не бросил режим сразу.
Я продолжал писать код и ещё некоторое время рассчитывал довести проект до состояния, когда можно будет снова показать большой объём работы и уже нормально вернуться к разговору об оплате.
Но темп заметно снизился.
Это сложно свести к одной причине.
Были рефакторинги, сама разработка становилась тяжелее, а общение с геймдизайнером практически прекратилось.
Но неоплаченная первая выплата тоже явно не добавляла уверенности в том, что дальнейшие месяцы работы вообще имеют финансовый смысл.
К концу весны проект уже двигался значительно медленнее.
В июне я, насколько помню, занимался им лишь эпизодически.
До полноценного релиза режим так и не дошёл.
Что в итоге представляла собой финансовая модель
Если убрать эмоции, моя схема работы выглядела следующим образом.
До релиза Cristalix, по словам piwich, напрямую мне ничего не платил.
На время разработки сам piwich предложил небольшую ежемесячную выплату порядка $50 из собственных денег.
Размер при этом, судя по дальнейшей переписке, не был жёстко закреплён и мог обсуждаться в зависимости от выполненной работы.
После релиза режим должен был получать 30% своего дохода, а эта доля делилась между мной и геймдизайнером 50/50 — по 15% каждому от исходной суммы.
Ни один из этих пунктов у меня не был оформлен договором.
Я также не получил документа, который бы объяснял:
кто официально считается плательщиком;
когда именно наступает дата выплаты;
какой объём работы считается месяцем;
что происходит с оплатой, если режим не выходит;
что происходит при прекращении работы разработчика;
и кто отвечает за уже выполненную, но ещё не оплаченную работу.
Когда всё идёт хорошо, такие детали могут казаться бюрократией.
Когда первая же выплата не доходит, они внезапно становятся всей финансовой системой.
7. Что я бы хотел знать до начала разработки на Cristalix
Если свести всю эту историю к тезису «Cristalix плохой», получится слишком простая и, на мой взгляд, бесполезная статья.
У платформы есть собственная инфраструктура, внутренние библиотеки, техническая документация, инструменты для разработчиков, аудитория и возможность сделать режим, который сразу получит игроков.
Я видел работающие части этой системы и пользовался ими сам.
Проблемы начинались там, где техническая система встречалась с организационной.
Документация могла существовать, но до необходимых правил ещё нужно было добраться.
Доступы существовали, но процесс их получения приходилось выяснять по ходу дела.
У режима был геймдизайнер, но часть продуктовых решений всё равно переходила к разработчику уже во время реализации.
Существовал отдельный канал с важными изменениями, но меня в нём не было.
За действие с внутренним API я, вероятно, лишился статуса разработчика, однако официальной причины снятия так и не получил.
Финансовые условия были понятны ровно до того момента, пока первая реальная выплата не застряла и вся договорённость не оказалась несколькими сообщениями и голосовым разговором.
Ни одна из этих проблем по отдельности не выглядит катастрофой.
И, наверное, именно поэтому их легко игнорировать.
Можно один раз подождать доступы.
Можно спросить геймдизайнера в Discord.
Можно попросить друга переслать важное сообщение.
Можно поверить, что деньги придут позже.
Можно решить, что отсутствие уведомления о снятии — просто странность.
Но когда весь рабочий процесс постоянно держится на том, что разработчик сам найдёт нужного человека, задаст правильный вопрос и случайно не пропустит правило, совокупность таких мелочей становится уже не мелочью.
Что бы я спросил сейчас
Если бы я снова собирался начинать разработку режима на подобной платформе, до начала работы я бы хотел получить ответы хотя бы на следующие вопросы:
- Какие конкретно доступы мне положены и кто отвечает за их выдачу?
- Где находится единый актуальный источник правил для разработчиков?
- Какие каналы или чаты обязательны и как туда попасть?
- Что означают Junior, Middle и Senior и какие ограничения связаны с каждым статусом?
- Кто отвечает за требования к режиму: куратор, геймдизайнер или сам разработчик?
- Какие решения я должен принимать самостоятельно, а какие должны быть описаны до реализации?
- Какие внутренние API имеют ограничения, неочевидные из самой документации?
- За какие действия можно получить предупреждение, ограничение или полное снятие?
- Получу ли я объяснение, если доступы будут отозваны?
- Кто конкретно платит мне во время разработки?
- Как определяется сумма и дата выплаты?
- Что происходит с уже выполненной работой, если режим не выходит или команда распадается?
- Как именно делится доход после релиза и где эта договорённость зафиксирована?
Если на эти вопросы нельзя получить нормальный ответ до начала работы, для меня теперь это уже причина задуматься, стоит ли вообще начинать.
Что я думаю о своём опыте сейчас
Я не считаю себя полностью правым во всех событиях этой истории.
Самый очевидный пример — персонализация. После первого вызова
Код:
giveModelЯ также мог настойчивее возвращаться к вопросу оплаты.
Мог быстрее закончить режим.
Мог раньше задавать некоторые вопросы.
Наверняка сейчас, имея больше опыта, часть технических решений я сделал бы иначе.
Но я не думаю, что нормальный процесс разработки должен работать только в том случае, если разработчик заранее угадывает все неписаные правила.
И именно это для меня осталось главным впечатлением от работы на Cristalix.
Слишком многое зависело не от явно описанного процесса, а от того, знаешь ли ты нужного человека, видел ли нужное сообщение, спросил ли вовремя и правильно ли понял устный ответ.
Если бы сегодня мне предложили снова работать на тех же условиях, я бы отказался.
Не потому, что считаю Cristalix абсолютно плохой платформой.
А потому, что после этого опыта для меня цена неопределённости стала слишком высокой: неопределённости в требованиях, правилах, доступах, ответственности и оплате.
Я не могу решать за другого разработчика, стоит ли ему идти туда работать.
Но могу посоветовать не воспринимать сам факт доступа к большой платформе как достаточную причину согласиться.
Сначала стоит понять, на что именно вы соглашаетесь.
Если эта статья заставит хотя бы одного разработчика задать все эти вопросы до начала нескольких месяцев работы, а не после них, значит, я написал её не зря.
