Я считаю что создавать для каждого коннекта отдельный процесс или thread параллели как либо это не нужной задачей.
И даже не потому что игра на 3 человека - явно игроки шлют небольшие пакеты до 100 байт, и на получение этого пакета уйдет менее 1мс и можно делать в одном потоке. ну и пауза между следующим пакетом у вас явно есть (если конечно пакеты не летят как в стриминг сервере без пауз, что неправильно)
Вы потеряете куда больше времени на синхронизацию данных между этими потоками/процессами . Я полагаю можно реализовать на питоне подписку на каждый сокет которая при приеме пакетов отправляет в очередь команду игрока и продолжает слушать.
Я рекомендую делать 2 процесса - первый на websocket соединения, второй для расчета команд из очереди (если у вас там npc есть - там же будут расчитываться вместе со всей физикой)
Статья про frame latency , а не про нагрузку заголовков tcp и я как раз НЕ смешиваю их. В конце концов мне решать как подавать материал о котором я рассказываю
На них* (описался). Тут речь про то, что в классическом http взаимодействии вы отправляете запрос и ждете ответа (например когда ждете загрузку страницы).
А с WebSocket у вас нет блокировки - вы отправляете пакет и возвращается управление (и у вас приходят пакеты , хотя ваш еще может и не быть обработан, но спустя какое то время и результат на ваш запрос придет и других игроков пакетом. Например когда много игроков отправили команды движения)
Людей "Персонажами" не называют. К вопросу у кого чвс и хамство. Вы завидуете, как еще объяснить внимание к лично моей персоне (а не к тому, о чем пишу). И сайт опубликовал и работу продолжил и завершу несмотря на критику
И сервер авторитарный. Это посложнее чем на клиенте расчитывать и просто готовые пакеты передавать. Так что ненадо сравнивать известный ммо (название которого вы боитесь сказать) и мой проект , где я делюсь всем с другими
Я незнаю вашу область и игру. А это 14 по счету статья и 3й год моих исследований в этой области и имеется игра прототип в которой видно как все работает и она realtime
В третьих на устройства игроков должны приходить пакеты обновления мира в постоянном режиме. В четвертых есть очереди. Игры типа запрос-ответ на http делают разве что пошаговые.
Медленно для игр. Не про какие базы и 10мс речи на одну команду быть не может в ММО играх - это во первых. А во вторых игровой сервер это постоянно работающий процесс где обрабатываются и команды других игроков и npc
Сами игровые механик - их код на разных языках доступен в админ панели на моем сайте. Исходный код (актуальный) игры так же есть в git https://bitbucket.org/_catalogs/unity/src
Я считаю что создавать для каждого коннекта отдельный процесс или thread параллели как либо это не нужной задачей.
И даже не потому что игра на 3 человека - явно игроки шлют небольшие пакеты до 100 байт, и на получение этого пакета уйдет менее 1мс и можно делать в одном потоке. ну и пауза между следующим пакетом у вас явно есть (если конечно пакеты не летят как в стриминг сервере без пауз, что неправильно)
Вы потеряете куда больше времени на синхронизацию данных между этими потоками/процессами . Я полагаю можно реализовать на питоне подписку на каждый сокет которая при приеме пакетов отправляет в очередь команду игрока и продолжает слушать.
Я рекомендую делать 2 процесса - первый на websocket соединения, второй для расчета команд из очереди (если у вас там npc есть - там же будут расчитываться вместе со всей физикой)
Я делаю так в своем проекте с 2D открытым миром
Статья про frame latency , а не про нагрузку заголовков tcp и я как раз НЕ смешиваю их. В конце концов мне решать как подавать материал о котором я рассказываю
На них* (описался). Тут речь про то, что в классическом http взаимодействии вы отправляете запрос и ждете ответа (например когда ждете загрузку страницы).
А с WebSocket у вас нет блокировки - вы отправляете пакет и возвращается управление (и у вас приходят пакеты , хотя ваш еще может и не быть обработан, но спустя какое то время и результат на ваш запрос придет и других игроков пакетом. Например когда много игроков отправили команды движения)
Если безразличен какое вам дело о моем Вузе, что я там хочу/нехочу, что я там сайт сделал и вообще предыдущей комментарий только обомне лично
Я рассказываю о своей работе. А вы даже сами себе врете что вам безразлично.
Пытаться оскорблять авторов лично не признак большого ума знаете ли
Людей "Персонажами" не называют. К вопросу у кого чвс и хамство. Вы завидуете, как еще объяснить внимание к лично моей персоне (а не к тому, о чем пишу). И сайт опубликовал и работу продолжил и завершу несмотря на критику
Вот без теории у человека - только код на C#. Но через 3 года оказалось все еле работает.
Есть выражение : не указывайте человеку что ему делать, а он не будет говорить куда идти.
Мои статьи содержать отметку не "туториал", а "роадмап" и читать Вас их никто не заставлят.
И сервер авторитарный. Это посложнее чем на клиенте расчитывать и просто готовые пакеты передавать. Так что ненадо сравнивать известный ммо (название которого вы боитесь сказать) и мой проект , где я делюсь всем с другими
Я незнаю вашу область и игру. А это 14 по счету статья и 3й год моих исследований в этой области и имеется игра прототип в которой видно как все работает и она realtime
В третьих на устройства игроков должны приходить пакеты обновления мира в постоянном режиме. В четвертых есть очереди. Игры типа запрос-ответ на http делают разве что пошаговые.
Медленно для игр. Не про какие базы и 10мс речи на одну команду быть не может в ММО играх - это во первых. А во вторых игровой сервер это постоянно работающий процесс где обрабатываются и команды других игроков и npc
Http протокол , а с ним и его сервера слишком медленные
исходный код первых версий (старых) я jпубликовал в git https://github.com/webrobot1
Сами игровые механик - их код на разных языках доступен в админ панели на моем сайте.
Исходный код (актуальный) игры так же есть в git https://bitbucket.org/_catalogs/unity/src
если я привожу в пример в своих статьях библиотеки - они так же для PHP
Эта статья 14-ая по счету. Я рассказываю только об архитектуре. Сам проект имеет прототип на моем сайте (http://my-fantasy.ru/) и написан на PHP
В языке на котором я работаю есть функции по сериализации и десериализации JSON .
json_encode (сериализация) выполняется на скорости 1 800 000 вызовов в секунду на небольших пакетов (около 60 байт)
json_decode (десериализация) - на скорости 600 000 вызовов в секунду (тот же пакет)
Я провожу замеры отдельных функций языка для нахождения "узких мест" (записываю их на своем сайте красным цветом что бы не забыть http://my-fantasy.ru/articles/frontend/index/eyJpZCI6MjN9 )
Эта скорость примерно 600.000 небольших пакетов в секунду
Http протокол для игр не рассматриваю
Я про веб сервера не пишу , но и одно другому не мешает: знаю тесты веб серверов способных до 2млн RPS обработать
Спасибо. То о чем пишу можно реализовать на любом языке тк пишу я про архитектуру