Это не проблема конкретно tcp , у вас и udp может так же не дойти (его сервер вообще не переотправит) и информация устареет.
Из за этого в играх происходит так называемый freez, что следствие высокого ping (в следующих статьях я раскажу как с этим бороться), тк в обычных случаях эта переотправка занимает микросекунды
Я не углубляюсь в подвиды "базовых" протоколов , но упомянул что можно создать свой, в тч и для udp, вопрос какие задачи преследуются (для игр с большим экшоном и где потеря одного двух пакетов не важна - подойдёт он).
Я не профессионал в Unity3D и игровые клиенты созданные мной служат для демонстрации работы сервера, например:
В игре есть алтарь воскресения слева внизу, стоя на нем вы сможете воскресить и заметить как 300 гоблинов под управлением сервера двинутся на вас выбирая кратчайший путь - это демонстрация работы "пулов".
Так же можно кликать на область и сервер (не сам клиент) рассчитает ближайший путь
Карта мира - портирована из программы Tiled (https://www.mapeditor.org/) в бд mysql и передаётся в клиент игры при входе на локацию (те ее можно динамически менять на сервере без обновления уже скаченных клиентских приложений)
И самое главное - все действия видят все игроки на карте (которых может быть много)
Есть и игры заказчиков, в тч связанные с криптой, где технология прижалась
Когда я начинал мне было бы полезной информация что есть редактор игровых карт Tiled , что его можно парсить на php и хранить карты в базе что даже если писать на низкоуровневых языках типа C# - это не гарантия успеха и скорости, что рационально использовать Nosql совместно с Sql и тп...
Поэтому посчитал что для начала серии статей (а это именно первая часть из нескольких) стоит начать с этой части :)
Т.е. я стараюсь донести именно архитектурные идеи и описать те логические трудности с которыми предстоит столкнуться ... над подачей еще стоит поработать...
Буду надеется что мое дальнейшее творчество вас не разочарует :)
Ну про rust сказать ничего не скажу (не работал) , а phpReact брать не стал (тк не понимая как устроен весь механизм Фреймворка сложно найти архитектурное решение лучше. а изучать само ядро фреймворков довольно сложно и удерживать в голове идею создателей)
С самым простеньким сервером (1 ядро 2 гб RAM ) удалось держать ~300 игроков онлайн (роботов которые постоянно ходили и атаковали ближайшую цель следуя за ней искав ближайший путь)
Столкнулся с проблемой когда было куча процессов которые обрабатывали NPC (асинхронных) , решил объединение этих процессов в пулы и стало гораздо лучше
думаю вы правы. Но информации по теме как "создать cервер для игр с нуля" почти нет, так что для многих (я надеюсь) кто ищет - найдет и оно будет полезно
что же касается Redis при всей его быстроте он рассчитан на нагрузку (данные взяты с оф сайта https://redis.io/docs/reference/optimization/benchmarks/) на 60.000 запросов в секунду на хороших машинах , при этом заявлено что и пользователей может держать столько же без особой потери в скорости
На среднем сервере (и опять же данные с того же сайта) там ~20000 запросов в секунду (у меня и того меньше было на тесте)
так что полагаю он был бы самым медленным решением
По поводу библиотеки apc_cache (или новой apcu) у нее есть существенный минус - данные храниться либо в FPM (и делаться между всеми другими php-FPM процессами не уничтожаясь при завершении работы скрипта) , а в CLI (а workerman и сервер в целом это CLI процесс - те демон некий в) что что создано остается в cli (и уничтожается когда этот cli завершает свою работу и между другими cli не передается)
Вообще мне кажется ради сжатия данных используя на +100500 запросах pack (вот как за первые места) будет существенная потеря в скорости на время сжатия (плюс там куда вы их передаете так же на распаковку)
Приходишь в банк брать кредит, а тебе оператор : "Вы не хотите сыграть в игру?!"
Я планирую несколько десятков статей на эту тему, боюсь ВСЕ ссылки будет сильно спамно.
Если вам интересно мое творчество полный список статей можно найти во вкладке Публикации нажав на мой профиль
Так же полагаю в Хабре есть система подписки на автора
Это не проблема конкретно tcp , у вас и udp может так же не дойти (его сервер вообще не переотправит) и информация устареет.
Из за этого в играх происходит так называемый freez, что следствие высокого ping (в следующих статьях я раскажу как с этим бороться), тк в обычных случаях эта переотправка занимает микросекунды
Я не углубляюсь в подвиды "базовых" протоколов , но упомянул что можно создать свой, в тч и для udp, вопрос какие задачи преследуются (для игр с большим экшоном и где потеря одного двух пакетов не важна - подойдёт он).
Я не профессионал в Unity3D и игровые клиенты созданные мной служат для демонстрации работы сервера, например:
В игре есть алтарь воскресения слева внизу, стоя на нем вы сможете воскресить и заметить как 300 гоблинов под управлением сервера двинутся на вас выбирая кратчайший путь - это демонстрация работы "пулов".
Так же можно кликать на область и сервер (не сам клиент) рассчитает ближайший путь
Карта мира - портирована из программы Tiled (https://www.mapeditor.org/) в бд mysql и передаётся в клиент игры при входе на локацию (те ее можно динамически менять на сервере без обновления уже скаченных клиентских приложений)
И самое главное - все действия видят все игроки на карте (которых может быть много)
Есть и игры заказчиков, в тч связанные с криптой, где технология прижалась
Vector Games был одним из подрядчиков СберИгр
Когда я начинал мне было бы полезной информация что есть редактор игровых карт Tiled , что его можно парсить на php и хранить карты в базе что даже если писать на низкоуровневых языках типа C# - это не гарантия успеха и скорости, что рационально использовать Nosql совместно с Sql и тп...
Поэтому посчитал что для начала серии статей (а это именно первая часть из нескольких) стоит начать с этой части :)
Т.е. я стараюсь донести именно архитектурные идеи и описать те логические трудности с которыми предстоит столкнуться ... над подачей еще стоит поработать...
Буду надеется что мое дальнейшее творчество вас не разочарует :)
Забавное у меня было собеседование на Senior PHP developer :
- У вас онлайн игра будет ? (начал я)
- Да, с огромным миром где надо ходить и качаться
- А как игроки буду встречаться?
- В PVP боях созданных вручную по приглашению...
- А почему на карте они не могут встречаться?
- Ну это сложно, долго и планируется года через 3 начать делать
- Я могу начать делать в Вашем проекте уже сейчас, есть опыт наработки
- Допустим , а вы знаете (спрашивают меня) как уровнять игроков с медленным Ping ?
- Да, для таких целей есть 2 пути интерполяция и экстраполяция
- Нет! Надо что бы просто раньше давать игрокам отправлять команды к серверу если пинг высокий...
- Вы описываете мне (говорю я) интерполяцию...
- Нет, я описываю вам как уровнять игроков ...
- Ок....так я подхожу вам?
- Мы решили что будем искать на GO программиста....
Добавил. Я на Хабре 2й день, опыта мало
Ну про rust сказать ничего не скажу (не работал) , а phpReact брать не стал (тк не понимая как устроен весь механизм Фреймворка сложно найти архитектурное решение лучше. а изучать само ядро фреймворков довольно сложно и удерживать в голове идею создателей)
С самым простеньким сервером (1 ядро 2 гб RAM ) удалось держать ~300 игроков онлайн (роботов которые постоянно ходили и атаковали ближайшую цель следуя за ней искав ближайший путь)
Столкнулся с проблемой когда было куча процессов которые обрабатывали NPC (асинхронных) , решил объединение этих процессов в пулы и стало гораздо лучше
думаю вы правы. Но информации по теме как "создать cервер для игр с нуля" почти нет, так что для многих (я надеюсь) кто ищет - найдет и оно будет полезно
что же касается Redis при всей его быстроте он рассчитан на нагрузку (данные взяты с оф сайта https://redis.io/docs/reference/optimization/benchmarks/) на 60.000 запросов в секунду на хороших машинах , при этом заявлено что и пользователей может держать столько же без особой потери в скорости
На среднем сервере (и опять же данные с того же сайта) там ~20000 запросов в секунду (у меня и того меньше было на тесте)
так что полагаю он был бы самым медленным решением
По поводу библиотеки apc_cache (или новой apcu) у нее есть существенный минус - данные храниться либо в FPM (и делаться между всеми другими php-FPM процессами не уничтожаясь при завершении работы скрипта) , а в CLI (а workerman и сервер в целом это CLI процесс - те демон некий в) что что создано остается в cli (и уничтожается когда этот cli завершает свою работу и между другими cli не передается)
Поправка:
вы устанавливаете (по тексту) библиотеку Event (https://www.php.net/manual/ru/book.event.php) в workerman подключаете Ev (https://www.php.net/manual/ru/book.ev.php) и пишите про libevent (ne вы наверно переработанный Event имели в виду но тем не менее это отдельная старая библиотека http://php.adamharvey.name/manual/ru/book.libevent.php)
Вообще мне кажется ради сжатия данных используя на +100500 запросах pack (вот как за первые места) будет существенная потеря в скорости на время сжатия (плюс там куда вы их передаете так же на распаковку)
Первый пост - как и писал. С опытом писать лучше научусь
Моя задача была идею донести. А так - это моя манера повествования :)
Ну во первых оскорблять людей не хорошо
Во вторых я начал блог о возможности создания сервера игр на php
Ну а в третьих еще в начале указано что хочу делиться идеей.