Создание сервера для Российских онлайн ММО игр на PHP ч. 1 — Импортозамещение
Мой первый пост и я хочу поделиться с вами своей идеей создание сервиса предоставляющего разработчикам игр и студиям платформу для создания онлайн игр! Поехали!
Зачем?
В большинстве своей при создании онлайн взаимодействия (не пошаговые, не где сервер - это один из клиентов, и не PVP, а прям ММО) в мобильных играх (да и не только) есть несколько путей:
- использовать игровой движок в качестве экземпляра сервера (типа тот же UNITY в качестве сервера из коробки или с плагинами типа Mirror) - нужно когда у тебя есть OFFLINE версия игры параллельно (тогда да, иначе никак)
- писать свое (те не универсальный, заточенный под игру)
- использовать сервис типа https://www.photonengine.com/ (аналог которого я и делаю)
Как было бы здорово если был бы простенький сервис с API , да что и написан был на простом языке типа РНР да и что бы к нему была админ панель, куда можно было бы добавлять карты, предметы, анимации, создавать квесты, редактировать баланс...И что бы это это работало с мобильными приложениями на Android , IOS и игры были прям реалтайм рпг, где все друг друга видят и взаимодействуют, что бы не требовало много ресурсов сервера и работало быстро
Как ?
Посмотрев информацию в интернете (найдя лишь эту https://habr.com/ru/company/vk/blog/220359/ старую статью) про то как строится архитектура программы - сервера (не путайте с клиентами, как делать сами игры статей множество) , открыв русскоязычный youtube (где все пересказывают либо эту статью, либо используют игровой движок как сервер) я полез в англо-саксонский :)
Вот пример Человек делал несколько лет на С# но в итоге все работало настолько медленно что он снял эмоциональное видео "Почему делать мультиплееры игры - КАКАШКА"
Исторически сложилось что такие вещи пишутся на том же языке что сделан клиент (и теми же людьми), те обычно на С#, C++ .... более редко мне кажется на Nodejs (может для браузерок) и Golang (знал бы его - писал на нем).
Что вроде как код должен компилироваться, что все остальное - медленное для пошаговых и однотипных браузеров и не компилируемые языки - не годятся ! C чем я не согласен и вот вам видео почему :)
Не получится?!
Я уже предчувствую желание пролистать вниз к комментариям, рассказать про свой опыт в php и каком то другом языке, рассказать почему именно на нем и только нем надо писать, а все остальное - не будет работать или будет , но медленно :)
Но где эти все технологии ? Мне известен https://www.photonengine.com/ , со сложной документацией, с серьезной работой в клиенте с глубокими познаниями в C# как мне кажется...
Да, php не компилируется , но это капля в море по скорости что забирает сервер (остальное - базы, кеширование, асинхронность, канал связи и тп) ... А с php 7.4 (и далее 8) появились такие вещи как opcache, JIT компиляция ..
В добавок используются такие технологии как Redis, Websocket (UDP / TCP ) и сервис предполагается для 2Д мобильных игр
Я считаю что человеку разрабатывающему клиент для онлайн не должен разбираться в хитросплетениях работы сервера : библиотеки для установления соединения с сервером и API список методов с принимаемыми и возвращаемыми параметрами - достаточно. А Вы ?
В добавок дать разработчикам легкий и понятный ГШ интерфейс для работы с игровым миром, например загрузка карт (отрисованные, например, в программе Tiled https://www.mapeditor.org/) как в видео
Есть результат?
В настоящий момент реализована авторизация, регистрация, загрузка мира (карта с анимациями из админ панели), движение , жизни игрока, смерть игрока , враждебные NPC с поиском пути до игрока минуя объекты и это только начало. Я постоянно придумываю все новые механики и способы убыстрить работу сервера, пример игры на видео:
Буду рад лайку если вам нравится идея моего творчества . Планирую снимать продолжение данной рубрики, где более подробно углубляться в технические аспекты, демонстрировать примеры кода, сравнивать технологии и языки...
Подписывайтесь на мой профиль что бы не пропустить новые статьи
История:
- Введение
- Масштабируемость и асинхронность
- 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
если вам интересно я в статье ниже сравниваю языки программирования и технологии https://dtf.ru/gamedev/1865728-sozdanie-servera-dlya-rossiyskih-onlayn-mmo-igr-na-php-ch-6-arhitektura-servera
Комментарий недоступен
как вы открыли в себе дар предвиденья?
Пока остальные статьи не читал, но сервер на пхп планируется делать как long life приложение с подключенным экстеншеном реактом для асинхронщины? Потому что я не могу представить нормальный сервер, где на каждый коннект будет создаваться отдельный процесс без возможности синкать потоки, потому что они изолированы.
У пхп специфика такая, что кто-то когда-то решил, что поднимать приложение с нуля на каждый запрос это круто, теперь от этой концепции никуда не уйдешь. Даже если у тебя родраннер под капотом. Для веб-приложений ещё куда ни шло, где настолько не важна задержка, что у тебя картинка из CDN дольше будет запрашиваться, чем ответ на HTTP-запрос от веб-приложений. Но прям для онлайн-игр... Ну не знаю.
Те же мьютексы. как ты будешь ставить блокировки, чтобы исключить race condition и корректно авторизовать игрока один раз, даже если он захотел создать 3-4 одновременных коннекта? Вроде как за это должен отвечать прям отдельный модуль, который все коннекты потоках обрабатывает в отдельной очереди и потом футболит коннект в отдельный поток игровой логики, где есть лютейшая синхронизация потоков между собой с гарантией консистентности данных в хранилище, компенсациями, ACID и все такое. Кажется, на пхп это не сделать, и никакой опкеш с джит-компиляцией тебе никак не поможет. Можешь рассказать, как ты планируешь разделять потоки и синхронизировать их?
Не то что бы я критиковал, ты молодец и действительно, дело не в языке, а в архитектуре. Но, также не следует забывать про платформу, на которой твоя архитектура будет крутиться, ее возможности и ограничения. Исходя из этого кажется, что изначальная технология была выбрана неверно. Для веб-приложений или простых проектов да, другу там показать, перед женой похвастаться, но для чего-то более существенного оно не подходит и очень быстро деградирует, даже железом масштабировать не получится, так как упрешься в одно ядро цпу или накладные расходы на обвязку вокруг на совершенно других технологиях, чтобы хоть как-то засинкать происходящее хотя бы у двух игроков между собой.
Сервер будет один раз запущенный (а значит и скомпелированный в машинный код в оперативной памяти процесс)
Мьютексы и семаформы я не использую однако да - паралельные потоки у меня есть и они синхронизируются по шини типа Channel в Go (это позволяет сделать библиотека Parallel в php написанная как модуль на С++, да и вообще из под php можно вызывать код Си для сложных вычислений из коробки). Пока у меня 3 потока - websocket сервер что обрабатывает пакеты, сервер обсчета физики и команд ироков, поток записи логов в фаил (тк это осень долго). В будущем планирую добавить к серверу обсчета физики вычисления на gpu
Что касательно попытки авторизации - у одного игрока может быть лишь 1 websocket соединение. При попытке подключит второе программа просто закроет предыдущие и передаст контроль новому (игрок даже из изры не выйдет) . Сама авторизауия по http (на который проверяется логин и пароль и выдается уникальный ключ для подключения по websocket, а аот при пожключении к последнему он смотрит есть ли уже у игрока соединение в массиве игроки-соединения)