Половину контрактов моего игрового сервера нельзя записать ассертом: исход живёт в ответе живого процесса, в разметке страницы и в кадре игры. Я записал их таблицами «дано → действие → ожидание», а прогоняет их агент. Рассказываю, как устроен контур проверки кода, который пишет ИИ: контракты вместо юнит-тестов, ревью, где находку надо доказать, и граница, за которую машину не пускают.

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

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

Несколько лет я в одиночку пишу сервер для своей 2D MMO RPG. Эта часть — про то, как изменился сам процесс разработки: игровую фичу я по-прежнему придумываю сам, а реализую её уже не один.

Это не демо в духе «модель выдала сниппет». Внутри — настоящая 2D MMO RPG: авторитарный сервер реального времени, тайловые карты, клиент на Unity. ИИ не создал эту систему, а ускорил: то, что раньше занимало дни и недели, теперь укладывается в часы и дни, и в одиночку я держу темп целой команды. Расскажу по порядку, как я к этому пришёл и где у подхода честная граница.

Готового сервиса для 2D MMO не нашлось ни в России, ни за рубежом — существующие рассчитаны на сессионные игры. Показываю, что собралось за три года: редактор механик, редактор существ, импорт карт, горизонтальное масштабирование и замеры, по которым видно, сколько игроков тянет одна машина.

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

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

Событийную архитектуру часто собирают вслепую, не зная, что у неё есть имя. Разбираю на схемах, как event-driven ложится на авторитарный игровой сервер, при чём тут JSON-RPC и почему сетевой и расчётный процессы не стали независимыми сервисами.

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

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

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

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

Сервер считает мир сам, клиент только показывает его и шлёт команды. Разбираю, что при этом обязан уметь клиент на Unity: держать постоянное соединение на ПК, мобильных и в браузере, переживать переход между локациями и не врать игроку при задержке сети.

Карта в 2D MMO — не картинка, а сетка тайлов с непроходимыми областями, объектами и анимацией. Показываю, как редактор Tiled отдаёт её в XML и как импорт такого файла в базу игрового сервера сводится к одной строке кода на PHP.

Сервер упирается в пятьсот игроков — и начинается перебор технологий: UDP вместо TCP, Node.js, Redis, очереди. Разбираю, почему ни одна из них не спасает плохую архитектуру, и показываю сущностно-компонентную схему, на которой держится сервер.

Игровые механики должны писать пользователи, но чужой код нельзя просто выполнить на сервере: одна бесконечная петля — и мир встал у всех разом. Сравниваю две песочницы для PHP, Lua и JavaScript, с замерами от 60 тысяч до 700 тысяч вызовов в секунду.

Игровому серверу нужна общая память: игроки и NPC читают и пишут одно состояние мира десятки тысяч раз в секунду. Разбираю, почему выбор пал на Redis, где проходит его потолок и как это уживается с требованием держать пинг в 60 миллисекунд.

HTTP-запрос заканчивается вместе с ответом — игровому серверу этого мало: он должен слать данные сам, не дожидаясь просьбы клиента. Разбираю, что даёт постоянное соединение поверх TCP, чем за него платишь и сколько запросов в секунду вытягивает демон на PHP.

Сервер считает ход игрока за 5–10 миллисекунд. Пока он занят одним, остальные ждут: при сотне игроков последний получает ответ почти через секунду. Разбираю, как PHP-сервер обслуживает всех сразу и во что это обходится по памяти и процессору.

Движки делают клиент. Серверную часть MMO каждый пишет заново — или платит за чужую инфраструктуру. Я решил закрыть эту дыру: универсальный сервер с админ-панелью и API, на PHP.