Создание сервера для Российских онлайн ММО игр на PHP ч. 6 — Выбор технологий,протокола и шаблон Entity Component System
Правительство РФ анонсировало выделение до $50 млрд для выхода РФ в топ-20 стран—разработчиков Игр к 2030 году. Возможно в скором времени разрабатываемый мной сервис наконец увидит свет
В этой статье я расскажу как сделать архитектуру приложения игрового сервера быстрой и что использует Unity. Эта статья результаты исследований предыдущих так что в ней будет много ссылок на них
Зачем это надо знать?
Скажу сразу что знать это не обязательно (да и при разработке игровых серверов часто привлекаются разработчики непосредственно самой игры не имеющих экспертизы в архитектуре приложений). Вы можете по разному выстроить процесс взаимодействия ваших игроков с сервером и это будет работать. Иногда это приводит к "лапшакогду" , а иногда применяются известные шаблоны проектирования, но в конечном итоге с великой долей вероятности проект не держит более 500 игроков (а иногда и меньше), что в свою очередь приводит к тому что начинается :
- TCP начинают заменять где это возможно на UDP обуславливая что "так быстрее" ...
Действительно быстрее...На 0.02 мс по данным моих исследований (данные приблизительные и сильно зависят от размера пакета и других факторов, но измерения лежат в долях миллисекунды), но на TCP у меня есть механики которые отрабатывают от 0.001мс до 4мс и на фоне этого UDP капля в море даже в шутерах (есть момент в блокировке TCP сообщениями сервера, проверки на получения данных, повторные отправки пакетов, но и не нужно отправлять пакеты в ветке Thread процесса сервера игровых механик о чем пойдет речь ниже)
2. Выбирают Node JS как один из быстрых решений сервера
Да быстрый, но почему ? Несомненно Node JS использует быстрый движок V8 о котором я рассказал в предыдущей статье однако при всей быстроте - это капля в море, а более важно что он использует обертку над websocket (что это такое я так же рассказывал в другой статье) - Socket IO и это не что то присущее только Node JS или Java Script в целом, а некий архитектурный подход в клиент-серверном взаимодействии. Одним из главных его преимуществ является добавление неких каналов "Channel" являющиеся второстепенными websocket серверами в которые вы шлете ОДИН большой пакет со списком кому его отправить, а Channel в свою очередь рассылают ВСЕМ , тем самым ваш игровой сервер тратит время только на отправку одного TCP пакета (условно их может быть несколько , например разным группам пользователей), а время на отправку непосредственно игрокам тратится в другом потоке Thread не тормозя игровой сервер. И этот подход вы можете реализовать на другом языке программирования без изменения стека (я рассказал в одной из первых статей что это большой обман что игровые сервера можно писать только на С++, С#, Go, Node JS и др )
3. Встраивают realtime систему логирования что пишет в каком месте кода какие временные затраты
Это является хорошим решением, но важно учесть что синхронная запись логов в фаилы (например) - это дополнительное время (~80 000 запросов в секунду по результатам тестов) и усеяв все логированием вы сильно затормозите игровой сервер. Выход - использовать корутины (например Swoole или ее форк OpenSwoole) - своего рода "асинхронная" запись
4. Добавлять все технологии, что на слуху, например:
- Redis - из статьи про производительность вы знаете что его производительность Perfomance +- 60.000 запросов в секунду, при пропускной способности TCP (Websocket) канала ~1 500 000 (зависит от железа и его пропускной способности Ethernet) - тем самым вы резко занижаете скорость вашего игрового сервера (есть возможность использовать корутины "Coroutines" и сделать Redis асинхронным если он работает не через socket, а по TCP тем самым не блокируя скрипт...тем не менее постоянное его использование сильно тормозит работу сервера)
- Добавлять очереди , например Rabbit MQ - я не делал статьи насчет него тк после Redis уже внимательнее отношусь к выбору технологий, но его Perfomance в целом схож с ним
- Так как написать хороший продукт ?
- Как сделать что бы он был быстрый даже при 5000 игроков онлайн ?
- Какие технологии выбрать?
На этот и вопрос я могу сказать - грамотная архитектура и есть технология!
В своем проекте сервиса для добавления мультиплеера в игры (адрес проекта http://my-fantasy.ru) использую стек:
И самое главное - Сущностно-компонентный архитектурный шаблон представленный ниже
Я постараюсь изложить как он работает простым языком:
- Ваш игрок (клиент игры) делает запрос на сервер они ставятся в очередь на исполнение в следующем кадре (вам не нужен никакой Rabbit или Laravel с его очередями для этого - достаточно поместить в массив данные)
- Systems (в примере с картинки) - это ваш сервер работающий в бесконечном цикле while. Каждый такой цикл - это как кадр , только без графики (тк сервер рассчитывает данные, например физику. А вся графика - она в клиенте, хотя часто сервера работают с графикой и это их быстрее не делает)
- У сервера есть игровые события (Respawn System, Move System и др с картинки) заложенные разработчиком чье количество не меняется в процессе игры (новое событие - новый код в сервере и соответственно его перезапуск).
- Каждый кадр наш сервер обходит игровые события с помощью цикла while и запускает их код
- Игрового события (например Move System) запускает цикл while внутри себя и смотрит какие игровые объекты (Entity) сейчас (тк у событий должна быть пауза, например: регенерация раз в 30 секунд) должны исполнить на себе это игровое событие
- У каждого игрового объекта есть компоненты (Components с картинки) которые по сути являются данными конкретной сущности (жизни , координаты, и прочее) - так вот любая игровая механика (Move System и др) это смена этих данных (когда изменения передадутся на клиент игроку у него изменится игровой мир: персонаж двинется, количество жизней увеличится, появится вмятина на танке и др)
- Если компонент (Components) сложный (не скалярный int string float double bool), например это объект или массив (в php массивом может быть то что в других языках, например в JS, называют объектом, но у которого нет методов ['bar'=>['foo1', 'foo2'...], ...]) то у него есть свойства Properties - нет нужды всегда группировать свойства делая Components как группу с единственным скалярным Properties, поэтому Components может быть как группой свойств, так и одни единственным (например в моем проекте жизни hp - это один компонент, максимальное число жизней hpMax - другой. Эксперименты с группировками скалярных компонентов лишь усложнили мне жизнь работая над кодом демонстрационной версии игры - клиентской части)
Признаюсь честно я об этом архитектурном шаблоне узнал не сразу. Сперва мне пришлось его вывести самому путем долгих экспериментов и у меня был перепутан местами пункт 4 и 5 - сначала в кадре сервера обрабатывались игровые объекты (Entity), а после обрабатывались их игровые события. Это работало отлично, но было весьма медленно тк каждый раз надо было запускать песочницы где выполнялся пользовательский код игровых механик (весьма в моем понимании дополнительные 0.1мс на объект)
Этот архитектурный шаблон используется в таком популярном движке как Unity, вот ссылка на его описание https://docs.unity3d.com/Packages/[email protected]/manual/index.html
Я искренне надеюсь что мои статьи принесут пользу читателю, сэкономят время разработки его сервера, а так же усилия нескольких лет не окажутся напрасными и будут полезными разработчикам РФ так и за рубежом (в настоящий момент я работаю над получением гранта для развития проекта)
Буду признателен за лайк к статье и рекомендации моего творчества заинтересованным людям, так же я выкладываю видео о своих исследованиях в сфере разработки игрового сервера на youtube.
История:
- Введение
- Масштабируемость и асинхронность
- WebSocket
- Redis
- LUA и JavaScript
- Выбор технологий, протокола и архитектурный шаблон Entity Component System
- Игровые локации (тайловые карты)
- Клиентская часть на Unity
- Игровые серверные механики
- Открытый бесшовный мир в 2D игре
- FPS, Ping, паузы между командами, интерполяция и экстраполяция
- Очереди и параллельное программирование на CPU
- Event-driven паттерн, JSON-RPC и почему не сервисная (SOA) архитектура
- Сетевая карта и задержка кадра (Latency frame) по RFC 2544 (1242)
- Создание сервера для онлайн ММО игр на PHP
- Готовое MVP сервиса 2D MMO RPG игр (realtime)
На PHP? Ну сразу бы сказал, что участвуешь в схеме по распилу.
А потом удивляются, почему для игр от таких погромистов нужна 4090 и сервера больше 50 игроков не держат ;)
нет не участвую. то что никто это не делал не значит что это не будет работать.
у меня же работает . прототип есть рабочий на http://my-fantasy.ru
эх щас бы все в распилы записывать.
есть момент в блокировке TCP сообщениями сервера, проверки на получения данных, повторные отправки пакетов, но и не нужно отправлять пакеты в ветке Thread процесса сервера игровых механик о чем пойдет речь ниже
Неблокирующий ввод/вывод есть как для tcp так для udp. Минус tcp для систем реального времени является продолжением его плюсов - подтверждение доставки, сохранения порядка следования данных, гарантия целостности данных. Работа этих механизмов в условиях нестабильной сети приводит к непредсказуемым задержкам при доставке данных, которые для пользователя выглядят как глюки игры. Минус udp в усложнении сетевого кода, т.к. часть фичей tcp приходится реализовывать самостоятельно
вы правы в TCP есть асинхронные режим отправки данных часто с callback функциями. Но проверка на то отправился ли пакет происходит раз в тик процессора и при этой проверки процесс что ее запрашивает блокируется хоть и на гораздо меньшее время.