Эта статья — про инженерные решения, а не про их детали. Мы сознательно держимся высокого уровня: пишем о том, как и почему думали, а не о том, что лежит под капотом.
TL;DR
Небольшая команда сделала мод-социальную-сеть для Minecraft, который объединяет в общий граф друзей игроков на любых поддерживаемых версиях клиента — от 1.7.10 до 1.21.1. Поддерживаются три популярных загрузчика модов и любые клиенты Minecraft, как лицензионные, так и офлайн. Серверная часть, веб-админка, обвязка и документация — всё своё.
Главное, что хотелось рассказать: дисциплина (не скорость) была решающим ресурсом, и категория продукта изменила правила игры настолько, что классическая формула «MVP на одной версии — потом расширяемся» оказалась контрпродуктивной.
Почему мы это начали
В Minecraft есть структурная проблема, которая обычно формулируется не так, как реально болит. Её часто описывают как «трудно договориться» — но это побочный симптом. Если у тебя уже есть друзья и есть их контакты, договориться можно за пару сообщений в любом мессенджере. Реальная проблема глубже и лежит до этого этапа: в Minecraft нет центрального места, где можно увидеть других игроков и понять, можешь ли ты с ними играть в принципе.
Конкретнее, у задачи две стороны:
Поиск. Где искать новых игроков, если хочется расширить круг? На форумах, в Дискорд-комьюнити, на серверных чатах, в комментариях у инфлюэнсеров? Всё это — разрозненные осколки, у каждого свой формат, своя аудитория, и ни в одном из них нет ни «онлайн ли он сейчас», ни «совместим ли он со мной». Ты тратишь часы на разведку, а возвращаешься с двумя-тремя случайными контактами.
Совместимость. Даже когда ты находишь интересного игрока, всё ещё непонятно главное: на чём он играет. На какой версии Minecraft, на каком загрузчике, лицензионный у него клиент или офлайн, какой модпак. Это не вопросы вкуса — это жёсткие ограничения, после которых либо вы можете играть вместе, либо нет, без полутонов. Спрашивать вручную — долго, неловко и не работает на масштабе.
Эти две стороны умножаются друг на друга: даже когда ты что-то находишь, шанс наткнуться на совместимого человека — мал, потому что Minecraft фрагментирован между 13 живыми версиями, тремя загрузчиками модов, двумя ветками клиентов (лицензия и офлайн) и сотнями активных модпаков. Любая случайная встреча с игроком — это лотерея, и без специального инструмента у этой лотереи плохие шансы.
Это и есть проблема, которую мы решали инженерно. Не «как помочь людям договориться» — а как построить единый каталог игроков с явно показанной совместимостью. Каталог, в который заходишь и сразу видишь: вот человек, он онлайн, он на 1.20.1, у него тот же модпак, цвет совместимости — зелёный, ему можно писать. А вот человек на 1.7.10 на офлайн-клиенте — цвет красный, у него другой кластер, на сервере вы не пересечётесь, но переписываться можно. Информация, которой раньше не было нигде в открытом доступе, у нас становится первичной структурой данных.
Когда мы начали смотреть, какие моды это решают, наткнулись на одну очень крупную западную систему — она занимает значительную долю рынка, но имеет два архитектурных ограничения:
работает только с лицензионным клиентом (по их же документации, при наличии следов офлайн-клиента в системе мод просто отказывается работать);
не поддерживает версии Minecraft до 1.8.
не имеет общего каталога игроков, только локально.
В русскоязычном пространстве (где значительная часть аудитории играет на офлайн-клиентах и на старых сборках типа 1.7.10/1.12.2) этот мод физически отсутствует как опция. Про него просто никто не слышал, потому что у всех «hosts hijacked», и он не запускается.
Это и есть гэп, в который мы пошли.
Архитектурный принцип, который сделал проект возможным
Главное, что нужно понимать про моддинг Minecraft — это что не существует «одной версии». Каждая мажорная версия игры (1.7, 1.12, 1.16, 1.18, 1.19, 1.20, 1.20.4, 1.20.6, 1.21) — это другой набор API. Они не совместимы между собой. Класс, имя метода, сигнатура, поведение тика клиентского цикла, способ регистрации звуков, способ открытия GUI, способ отправки чат-сообщения — всё это меняется между версиями. И, плюс, каждая версия может существовать в трёх «диалектах» — три популярных загрузчика модов, у которых тоже свой API, свои подходы к жизненному циклу мода и свои ограничения.
Если делать мод напрямую под каждую комбинацию, у тебя получается 13 копий одной и той же логики, расходящихся со временем. Каждое исправление бага надо делать 13 раз. Каждое улучшение фичи — 13 раз. Через полгода у тебя 13 разных продуктов, и это конец дороги.
Поэтому первое решение, которое мы приняли, было: вся бизнес-логика мода живёт в едином ядре, не зависящем от Minecraft. Этот код умеет держать соединение с сервером, рисовать UI собственными примитивами, обрабатывать события, вести список друзей, отображать сообщения. Он не знает ни про Minecraft, ни про загрузчик. Он просто принимает на вход «контекст» — абстракцию, которую обязан предоставить тонкий платформенный слой.
Каждая из 13 версий-загрузчиков — это тонкий слой (буквально несколько файлов), задача которого «прокинуть» вызовы между Minecraft API текущей версии и обобщённым ядром. Этот слой делает три вещи:
ловит события Minecraft и отдаёт их ядру в обобщённой форме;
получает от ядра запросы «нарисуй» / «открой UI» / «сыграй звук» и переводит их в API конкретной версии;
предоставляет ядру информацию о текущем игроке, версии, загрузчике.
Главный плюс: исправление любой фичи делается в одном месте. Все 13 модулей мгновенно получают новое поведение. Никакого drift’а, никаких 13 копий одной логики.
Главный минус: дисциплина выше. Ядро не может «срезать угол» и спросить про конкретный класс Minecraft, иначе абстракция течёт. Каждая платформенно-зависимая операция должна быть названа в виде метода контекста, и в каждой из 13 реализаций этот метод должен быть написан правильно. Это терпение, и в день первой ошибки кажется, что проще «забить и сделать ifdef’ом», но довольно быстро понимаешь, что вся структура работает только потому, что себе не дали срезать.
Что мы поняли про темп
Главный сюрприз для команды: на проект ушло меньше времени, чем казалось при планировании. Не потому что работали с какой-то экстремальной скоростью — а потому что не писали ничего лишнего.
Что значит «не писали ничего лишнего»:
Не делали «универсальных решений». Каждая фича делалась под конкретный сценарий конкретного экрана, и потом, если оказывалось, что её можно переиспользовать, она экстрагировалась. Это противоположно тому, как часто делают опытные разработчики: сначала «правильную абстракцию», потом «использование».
Не правили то, что и так работало. Это звучит банально, но при ревью своего кода через неделю каждый раз ловишь себя на желании «сделать чище». Учили себя останавливать руку и идти писать следующий экран.
Не делали собственных велосипедов там, где есть стандартные решения. Если задача похожа на «реальные времена двух тысяч пользователей в WebSocket» — это решённая задача, бери стандартный паттерн и используй.
И — это, наверное, главное — писали handoff’ы перед кодом, а не после.
Handoff’ы как архитектурный инструмент
Под каждую новую версию Minecraft, которую надо было поддержать, мы писали отдельный документ длиной 1200–1500 строк. В нём:
что меняется в API между текущей версией и базовой (которую уже умеешь);
какие именно классы переехали или были переименованы;
какие сигнатуры стали другими;
какие константы стали другими;
какие подводные камни — про конкретные изменения, которые легко пропустить.
Только после написания такого документа писался код. И код шёл как по нотам — два-три часа на новую платформу, включая отладку.
Это противоположно тому, что обычно делают: пишут код, ловят ошибку, гуглят, фиксят, ловят следующую, гуглят, фиксят. Пишут код, исследуя на ходу. Это и есть основной источник трат времени в моддинге Minecraft, и его удалось обойти, унося исследование в текст перед тем, как открыть IDE.
Побочный плюс: эти handoff’ы — теперь часть проекта. Если через год понадобится делать новую версию, у нас уже есть шаблон, как это делается, и не повторяются собственные ошибки. Если присоединится кто-то новый — у него есть введение в проблему, которое ему не надо искать по чатам и устным рассказам.
Server-side: о чём думали, когда выбирали, что туда положить
Серверная часть — это, пожалуй, та область, про которую публично говорить хочется наименее подробно. Мод-социалка — это мишень: при первом росте аудитории появятся попытки подменить идентификаторы, обойти ограничения, наспамить, проэкслуатировать любую механику, которую публично описываешь. Поэтому ограничимся принципами:
Принцип 1: бесплатно — значит дёшево обслуживать. Любая операция, которую сервер делает чаще одного раза в секунду, не делается на стороне сервера, если её можно сделать на клиенте или вообще не делать. Это касается и пинга/keep-alive, и проверки статуса, и любых счётчиков.
Принцип 2: identity-привязка ≠ идентификация. Мы не пытаемся определить «кто этот человек на самом деле». Мы пытаемся определить, что этот сеанс связан с этим устройством так, что украденный токен не работает на другом устройстве. Это разная задача, и она решается без логина/пароля и без обязательной привязки к Mojang. Подробности — в TOS.
Принцип 3: публичный API и админский API — это два разных сервиса. Они на разных портах, на них разная логика аутентификации, разные ограничения скорости, разные эндпоинты. Атакующий, нашедший дырку в публичном API, не получает шага к админскому. Это банально, но удивительно часто этим правилом пренебрегают.
Принцип 4: каждое действие пользователя — идемпотентно. Если пользователь дважды нажал «отправить сообщение» (а он будет это делать), сервер не должен прислать на сервер два сообщения. Это не optimization, это требование UX. И решается оно в одном простом месте.
Принцип 5: реалтайм через постоянный канал, а не через poll. Вся доставка обновлений — push. Это меняет всю модель сервера и требует аккуратности с числом одновременных соединений, но без этого «социалка» не имеет смысла: если друг зашёл online, ты должен это увидеть сейчас, а не «через 30 секунд по таймеру». Это ощущается на клиенте — это разница между «работает» и «вяло».
Принцип 6: всё, что хранится — должно ужиматься. Не storage за деньги, а внутреннее представление: индексы строятся под реальные query, а не «на всякий случай», статистика — в облегчённых структурах, журналы — с автоматическим вычищением старого. Без этого через полгода у тебя 100 ГБ данных и 10 МБ полезной информации.
Принцип 7: кратковременные вещи — в кэш, долговременные — в базу, и эти миры не пересекаются. Если хочется узнать «онлайн ли пользователь», это вопрос к кэшу, не к базе. Если хочется узнать «когда он зарегистрировался» — к базе. Это очевидно, но в реальности постоянно соблазн «положить и туда, и туда, чтобы не забыть».
Этого набора принципов хватило, чтобы серверная часть осталась маленькой и простой, и при этом покрывала все пользовательские сценарии без затыков.
Самое интересное наблюдение про многоверсионность
Когда у вас 13 разных версий клиента, и каждая обновляется в своём ритме, появляется неочевидная проблема: что считать «свежей» функциональностью?
Допустим, мы хотим добавить кнопку «найти случайного игрока». На современной версии — легко: есть нормальный UI, шрифт с правильной шириной, виджет кнопки с правильным narration для accessibility. На старой версии — ничего этого нет, есть голые примитивы 2014 года, и каждая фича рисуется руками поверх минимума.
Было два варианта: либо ограничивать функциональность по нижней планке (тогда у современных версий теряется свежесть), либо делать разную глубину интерфейса в зависимости от того, что доступно на платформе.
Выбрали второе. Это значит, что ядро экспонирует UI-примитивы по уровням:
базовые (доступны всегда, на самой старой версии);
расширенные (доступны там, где платформа их поддерживает);
продвинутые (доступны только на самых свежих платформах).
Каждая версия предоставляет своему ядру тот «уровень виджетов», который она физически может реализовать. Ядро видит, какой уровень доступен, и адаптирует экраны.
Эффект: на 1.7.10 интерфейс выглядит простым, но всё работает. На 1.21.1 интерфейс выглядит современным, и работает то же самое. Граф друзей у этих двух игроков — общий. Они могут переписываться. Они могут видеть друг друга. Но визуально каждый получает то, что соответствует его эпохе.
Это, кстати, и есть главная фича, которую мы не видели ни в одном конкуренте. Они либо «сегодняшние» (1.16+), либо «вчерашние» (только 1.7), но не оба. У нас — оба, и они общаются.
Что не получилось
Честно: некоторые вещи отложили на «после релиза» и будем об этом жалеть.
Тесты. Автотесты написаны только на самые опасные участки (там, где логика меняется в зависимости от внешнего ввода и где промах = проблема безопасности). Остальное — ручные чек-листы. Это нормально для интенсивного спринта, но это техдолг. Самый дорогой класс техдолга, потому что он растёт квадратично от количества фич.
CI/CD. На момент написания статьи катаем руками. Это работает, пока проект небольшой. Как только потребуется серьёзный rollback или присоединится несколько новых разработчиков — без автоматики попадаем в стрессовую ситуацию.
Observability. Мы знаем, что у нас всё работает. Но мы не всегда знаем как оно работает в каждый конкретный момент. Это надо чинить до того, как первый большой запуск. Метрики, дашборды, алерты — всё это идёт в первые дни после релиза.
Систематический бэкап БД. Есть автоматические снимки на хостинге. Этого недостаточно. Должен быть отдельный, регулярный, проверяемый бэкап с восстановительной репетицией. Это будет.
Описываем это честно, потому что хочется, чтобы у читателя сложилось правильное впечатление: за интенсивный спринт можно сделать очень много, но это не значит, что всё. Удалось удержать качество там, где оно критично — в core-логике, в безопасности identity, в UX, в покрытии версий. Но операционная зрелость идёт следующим шагом, не в первом.
Лицензия и офлайн-клиент: тема, к которой подходили очень осторожно
Часть значимой русскоязычной MC-аудитории играет на офлайн-клиентах. Это юридически и культурно отдельная история, и мы были намерены её решать, а не игнорировать.
Технически это сводится к одному простому решению: мы не привязываем идентификацию пользователя в Сервисе к идентификации Mojang. Игровой UUID Minecraft — необязательное поле. Может быть указан, может не быть указан. Сервис от этого не разваливается. Идентификация устройства строится на параметрах, которые не зависят от того, аутентифицирован ли клиент через Mojang или нет.
В TOS это легализовано: Пользователь сам заявляет, какой у него тип клиента (лицензионный или офлайн), и Сервис никак не проверяет это заявление и не передаёт его никому, включая Mojang. Это не «дырка в защите от пиратства Minecraft» — это сознательная архитектурная позиция: мы не игровая платформа, мы социальная сеть поверх игровой платформы. Кому Microsoft продаёт лицензии — это вопрос между Microsoft и пользователем, а не между нами и пользователем.
Эффект: наша адресуемая аудитория — больше, чем у похожих западных продуктов. Не потому что мы лучше, а потому что мы не отрезаем себе ногу архитектурным решением, которое в их случае было осознанным выбором, а в нашем — было бы добровольным самоограничением.
Что мы поняли про категорию
Когда команда начинала, казалось: «социалка в Minecraft — пустая категория». Это было отчасти верно. Действительно, глобальной соцсети как продукта — с открытым каталогом игроков, лентой новостей, моделью discovery — не существовало. Существуют friend-list’ы, чаты, voice-mod’ы, но это другие продукты.
Но один очень крупный продукт существует и закрывает значительную часть смежного рынка. У него почти 30 миллионов скачиваний и десятки тысяч одновременных пользователей. И он не соцсеть в строгом смысле — он скорее «сервис друзей», работающий по модели peer-to-peer хостинга миров. И он не работает на офлайн-клиентах и не работает на 1.7.
Когда мы это увидели, поняли две вещи. Первая: мы не пионеры в смежных категориях, есть проверенный спрос на «социальное в MC». Это хорошо — не надо создавать категорию с нуля. Вторая: мы первые в своей конкретной нише — глобальной соцсети с поддержкой 1.7.10 и офлайн-клиентов. Это идеальная ситуация: спрос подтверждён, конкретная ниша свободна.
Это, кстати, типовая структура «найти крепкое место для запуска»: не пустая категория (там тебя ждёт расход бюджета на образование рынка), но и не центр существующей категории (там тебя ждёт лобовое столкновение с лидером). А смежная ниша, в которую лидер не идёт по архитектурной причине.
Что мы поняли про инженерную работу
Главное профессиональное наблюдение этого спринта: дисциплина важнее скорости.
Скорость — это «сколько строк в день». Получалось много, и в основном потому, что не лежали без дела. Но скорость — это не то, что сделало проект жизнеспособным.
Дисциплина — это «не сворачивать». Не переписывать то, что и так работает. Не делать ускоренных решений в обход архитектуры, которые «потом исправлю». Не лениться писать handoff перед сменой версии. Не забыть включить ratelimit на каждом новом эндпоинте. Не публиковать миграцию без down-парного скрипта. Каждое из этих решений выглядит как «мелочь, которую можно отложить», и каждое из них через неделю превращается в «эту мелочь теперь чинить полдня».
Это знакомо теоретически каждому опытному разработчику. Прожить это в режиме активного спринта — отдельное упражнение. И, наверное, главный гик-результат — не код и не запущенный сервис, а знание, как такую интенсивность поддерживать, не сжигая качество.
Мы не повторяли бы такой темп каждый раз. Это режим спринта, не марафона. Но факт, что небольшая команда может за интенсивный спринт сделать продукт, который выглядит как многомесячная командная работа, теперь нам известен изнутри, а не из чужих рассказов.
Что дальше
Сейчас идёт тестирование на разных версиях. Дальше — публичный запуск.
Что мы не будем делать в первый месяц после запуска: новые фичи. Только укрепление того, что уже есть — тесты, CI.
Что мы будем делать: писать в публичные русскоязычные MC-каналы и пробовать набрать первую тысячу. Это та фаза, в которой большинство социалок умирают (никому не интересно быть первым в пустом баре), и к ней готовились ещё на этапе дизайна (поэтому в продукте есть лента новостей — она работает как «занятость» для пользователя, у которого ещё нет друзей).
Несколько замечаний коллегам, которые читают это и думают повторить
Не выбирайте универсальность ради универсальности. Каждый поддерживаемый сценарий стоит времени, и это время надо чем-то оправдать. 13 версий мы поддержали потому, что в социалке 13 версий = 13 потенциальных гетто, и любое из них убивает product-market-fit. У вашего продукта может быть 1 сценарий, но глубокий.
Не доверяйте «MVP в одну версию», если у вас сетевой эффект. Социалки фрагментируются. Игры с друзьями — тоже. Любой продукт, в котором ценность одного пользователя зависит от наличия других, нельзя проверить на одной аудитории. У вас должны быть обе стороны, иначе тест ничего не покажет.
Документируйте до того, как пишете код. Не вместо ответа на вопрос «как это сделать», а вместо самого кода. Текст в Markdown пишется в 5 раз быстрее, чем код, и в 5 раз легче ревьюится самим собой. Большинство ошибок ловится в тексте, до их появления.
Безопасность — это не одна фича, это десять одновременных фич. Каждый эндпоинт должен быть прикрыт во многих местах. Каждая операция должна быть дороже для атакующего, чем для пользователя. Если у вас есть один защитный слой — у вас нет защиты, у вас есть препятствие. Это не паранойя — это математика scale: при 1000 пользователей у вас уже 5–10 атак в день, и атаки не обязательно умные, просто их много.
Вы не умнее лидера рынка, но вы можете быть в другом месте. Это другой урок, чем «найди что-то, что не делает большой». Большой не делает много чего по архитектурной причине, и это именно то, во что стоит идти. Если большой не работает на офлайн-клиентах — это не дырка в их продукте, это их выбор. Этот выбор закрыт для них и открыт для вас.
Не отдавайте операционные навыки на аутсорс, особенно в первый год. Вы должны уметь поднять прод с нуля одной командой. Должны знать, как откатить миграцию. Должны знать, что покажет ваш дашборд при инциденте. Должны уметь объяснить себе, почему вы доверяете своему бэкапу. Без этого один сбой в выходные — и вы потеряете доверие пользователей быстрее, чем напишете извинение в ленту.
P.S.
Спасибо всем, кто читает Habr ради таких историй. Если у вас есть свой проект, который вы хотите дотянуть до релиза в небольшой команде — попробуйте написать собственный handoff к нему. Не ради проекта (хотя ради него тоже). Ради того, чтобы посмотреть на него глазами стороннего инженера, которому надо за час всё понять.
Если вы не можете написать такой handoff — вы не понимаете свой проект. Это не страшно. Это начало работы.
Всего хорошего!
