В предыдущей статья я рассказал о протоколах клиент-серверного взаимодействия и о нагрузке которую может выдержать TCP соединения . А так же рассказал что для сервера более важно как вы работаете с данными и как устроена архитектура, чем язык на котором вы пишите сервер
В этой части серии статей мы рассмотрим технологию для хранения , записи и публикации данных клиентам - Redis , разберем сколько игроков и NPC мы можем держать с демонстрацией онлайн игры "Игорь" , затронем архитектурные принципы построения приложений и известные мне серверные движки для онлайн игр
Что такое Redis в двух словах
По сути это технология хранения данных в виде плоской таблицы, те NoSQL, с простыми структурами (текстовыми в тч JSON, числовыми), где данные хранятся в блоке оперативной памяти сервера где установлен Redis с возможность сброса данных на диск (что нам точно не подойдет это сбрасывание на диск из за скорости этой операции).
При разработке приложений очень выгодно комбинировать это как временный кеш (продолжительность жизни которого больше чем работа скрипта в классических Web приложениях) и комбинировать со Sql базами (например Mysql или Redis) собрав из них информацию при старте , обновляя ее при работе (тк скорость в десятки и даже сотни раз выше при работе с классическими Sql базами) и сбрасывая обратной через интервал времени .
Так же из отличительной особенности в Redis есть поддержка работы с GEO координатами (что важно в ряде игровых механик, таких как найти рядом с точкой NPC ближайших игроков в радиусе) , а так же Pub/Sub - если кратко это возможности из одного запушенного скрипта (которые может в тч физически быть на другом сервере) отправить пакет данных в другой скрипт (который скажем работает в режиме CLI и слушает канал.
На скриншоте ниже (где Source - клиенты игры с мобильного приложениями или играющие через WEB версию с сайта, BUS - наш сервер, Chanel - Redis pubSub , а Listener - наши скрипты - сервисы который обрабатывают запрос пользователь, те логику)
И каналов может быть несколько) что обеспечивает межпроцессорной взаимодействие. Те нам не надо "ожидать" ответа скрипта ,после отправки запроса (как например часто сделано в схеме запрос - ответ в "REST FULL" модели построения API), технически возможно послать команду и пока нет ответа - делать другое полезное действие скриптом (например посмотреть не пришло ли на других каналах что то), а скрипт когда обработает команду, выполнит действия - сам отправит нам ответ (или может быть пошлет запросы куда то далее) или передаст в другой процесс (который так же может быть на другом сервере) .
Демонстрация ниже (файлы взяты из интернета и здесь Source - это наш Client , Pipe - Redis Pub Sub, а фильтр - скрипт где находится логика, ну а Sink может выступать , не на этой картинке а вообще - тем же или другим клиентом подключённому к нашему серверу )
Именно поэтому на него и пал выбор при разработке игрового сервера . Остается вопрос - получится ли сделать игровой сервер с redis и сколько игроков сможет играть в онлайне?
Redis benchmark
Согласно официальному сайту диапазон запросов в секунду колеблется от 10 000 до 80 000 запросов в секунду (а зависимости от процессора на сервере), при этом способен держать такое же количество пользователей, что является неплохим показателям в highload где скорость ответа от севера является допустимой и 100+ миллисекунд (что является малозначимым при разработке тех же сайтов, объективно пользователи ждут загрузи страницы часто более секунды что в 10 раз больше)
Однако при разработчик игр хорошим показателем PING является 60 мс, идеальным 30мс терпимым 100мс (но уже заметны фризы).
Что такое ping я постарался простым и понятным языком описать в видео:
Есть разные пути уменьшить скорость ping теми или иными способами и оптимизациями но что касается Redis у нас есть определенный явный потолок его пропускной способности - 80 000 (за раз один запрос клиента может быть 3 и более запросов в Redis), при том что пропускная способность нашего Websocket сервера построенного на базе фреймворка workerman лежит в гораздо большем диапазоне (при том что сравнение даны в качестве HTTP сервера)
Поимо прочего не только игроки используют redis но и NPC которые живут на сервере как отдельные процессы (те сервер сам рассчитывает куда им идти, на сколько атаковать и что вообще делать на карте) и им так же нужен доступ к данным игроков и эти данные нужны актуальные (ведь мы не можем просто взять и положить в переменную игроков , тк не только NPC могут атаковать игрока но и игроки, да сами NPC не читают pub/sub тк это накладывало бы большой overhead на то что им знать не нужно, например когда игрок далеко и что то делает и весь redis бы медленно перекочевал копией в оперативную память процессов NPC)
Есть и другие более быстрые способы раздельной памяти между процессами, правда ряд их них не масштабируемы , однако позволяет обрабатывать 700 000 + запросов в секунду, о которых я буду рассказывать в следующих статьях
А почему бы не вызывать Контроллеры/Модели в одном месте и не морочится с разными процессами (потоками) ?
Эта модель имеет право на существование. Мало того что часто архитектура серверов для онлайн игр что используют архитектурный шаблон "Монолит" , без каких либо понятиях об MVC (MVP) в одном фаиле объединяя множество if-else-switch (лапшакод) или, что лучше но не идеально, модель догружаемых библиотек (require кода в php можно привести как аналог или множественное вложенное "new Class(...)" с передачей результата в следующий new класс )
В таких моделях сервера обычно не масштабируемые (те у вас может быть копия сервера со своей базой и своими игроками которые не пересекаются) и при загрузки один раз загружает все данные из фаила или базы , куда раз в интервал скидывает на сохранение.
Однако когда все обработки npc, игроков с данными пришедшими от них, сохранение обрабатываясь в одном процессе делает приложение синхронным и к моменту когда скрипт закончит цикл всех этих действий пройдет достаточно много времени, которое пропорционально растет с объемом наполнения игрового мира , а такие циклы должны идти постоянно
Т.е. имеется лимит на размер данных которые могут быть в игровом мире тк оперативная память сервера считается "дорогим" ресурсом.
Примеры онлайн игр
Я приведу несколько онлайн игр, архитектура сервера и которая мне известна (тут нет рейтинга хуже - лучше - интереснее, а исключительно обзор технических подходов)
№ 1 Fallout online: Requiem - это движок (название движка "fonline engine") 15 летней давности, сделан еще 32 битной архитектуре (те 4Гб - максимум поддерживаемой оперативки сервера), написанный на C++, работает в несколько потоков (процессов), каждый из которых обрабатывает или сохраняет свою часть игрового мира.
Проблемы возникают при отправке пакетов игрокам (тк пакет высылается игрокам потоком, те через каждые 2-10 миллисекунд, хотя за это время видимых глазу изменений не происходит на карте, и за чего эти пакеты засоряют канал ненужными данными), в добавок потребление CPU без игроков 40% (на обработку всех npc и объектов которых насчитывается несколько тысяч) , а к после 200 онлайн достигает - 99%
№ 2 BrowserQuest - PHP - браузерная игра написанная на JS (клиентская часть) и PHP (серверная часть) человеком что создал фреймворк workerman (о нем я упомянул выше) с использованием его для установки Websocket соединений имеется демо.
К игре нет документации , однако изучив кодовую базу могу рассказать немного и о ней.
Архитектура этой игры в некотором роде зеркальна: все выполняется в одном потоке (процессе) в классе севера, в котором шаблоном Sigleton создаются экземпляры классов при запросе от клиентов , выполняется игровая логика, ответ отправляется обратно.
Каждые 20 миллисекунд (прописано в коде) по таймеру (является частью фреймворка workerman) который имеет callback функцию запускаемую в этом же потоке что обрабатывает жизнь всех npc, предметов и после отправляет всем игрока. Как ? В php есть так называемые тики, если простыми словами - при каждом обращении к переменным, вызовом функций (грубо говоря с каждой новой строчкой кода) можно повесить вызов функции , которая как раз может как раз проверить не пришлось ли ей выполнится. При этом новый процесс не создается, а текущий ставится на паузу до окончания выполнения callback (так же работают и обработчики сигналов под капотом и, полагаю, все EventLib библиотеки в php), те происходит передача управления.
Игра предусматривает создание нескольких "миров" и да, тогда это будет отдельный процесс но но сути ... это будет копия игры со своими игроками (один мир поддерживает 1000 игроков если верить конфигурационному файлу. Однако я полагаю при таком же количестве NPC в мире, в котором же и происходит обработка помимо команд игроков и жизненный цикл NPC, будет не очень хороший пинг).
Так же не очень удобно когда привычный REST API со строковыми названиями методов что нужно запустит заменяются на числовые. Например [4,47,170] значит идти в позицию 47х170, а [8, "1122"] атаковать объект объект 1121, что полагаю , если не продумать защиту, можно атаковать с другого конца карты не находясь у него (гораздо более безопасно ,как мне кажется, делать команды на сервер типа ["atack_right"] или ["move_down"]). В добавок на фото виден рассинхрон получаемого NPC урона (те игрок ударил, отошел и только отойдя пришло сообщение о нанесении урона).
№ 3 Игорь - демонстрационная игра на Unity (клиент) и PHP (сервер, использующий workerman и архитектурные решения описываемые в серии статей.)
Моя идея заключается сделать облачный сервис для создания онлайн игр, способный держать 100.000 + игроков . Этот сервис позволит разработчикам и студиям у которых нет финансовой и технической возможности писать свое решение годами воспользоваться им по подписке для разработки свой MMO RPG.
Самой главной задачей стоит не разработка самих игровых механик , а грамотной архитектуры (к слову думать над оптимизацией нагрузки я могу неделями, а написать сервис отвечающий за воскрешения игроков - за день).
Подписывайтесь на мой профиль что бы не пропустить новые статьи, плюс бонус - видео рассказ описанного в этой статье с демонстрацией работы текущей версии:
Буду признателен за лайки - так я могу видеть интересна ли вам данная тематика и стоит ли ее продолжать.
Приветствуются аргументированные комментарии что по вашему мнению было бы хорошим архитектурным решением.
Комментарии (34)
sunnybear
13.06.2022 22:05Сделайте хороший разбор, исправьте лексику/грамматику. Сложные вещи выносите в отдельные блоки/статьи (не видео). И будет счастье.
А блок подписки можно в конце добавить
BIOACE
15.06.2022 14:13+2Я желаю успехов в ваших начинаниях, да и в принципе всем кто хоть что-то желает, ибо не ошибается тот кто ничего не делает.
Но. Как и сказал 'iamkisly' в комментариях к 1 статье - у вас нет понимания как и что происходит в геймдеве. Складывается ощущение что вы наспех прочитали несколько статей и теперь пытаетесь пересказать нам то как вы их поняли.
Команды вида [8,117,17] труднее читаются чем move_right, но куда правильнее, имхо. Я бы вообще использовал бы пакеты вида '13FFAC0D'.
Дальше вы утверждаете 'но так же можно атаковать через всю карту' и тут вы правы только частично. Можно попробовать атаковать через всю карту, но задача сервера как раз проверить может ли игрок атаковать, хватает ли дальности, можно ли вообще атаковать данный объект и т.д. и желательно ещё вести статистику таких вот выкрутасов от игрока. Если их много то кик с сервера, если это повторяется регулярно там бан.
В вашем же апи используют команды 'иди влево', 'иди вправо', 'иди вверх', 'иди вниз'. Это конечно прекрасно (нет), но мы пишем не 'черепашку' а ММО (хотя на вашем бы месте прежде чем бросаться такими словами, я бы попробовал написать сервер хотя бы на пару десятков человек).
Тут я вижу 2 варианта на какие пакеты заменить: 1) это координаты и дальше сервер уже двигает персонажа постепенно туда (как в стратегиях например, или в МОБА), и вариант 2) это вектор куда и с какой скоростью движется персонаж.
Идём дальше, редис.. вот тут ничего не скажу, вещь полезная, и когда я занимался попытками создать сервер для игры, то я о подобных технологиях не знал. Но имхо вы используете редис не правильно. Незачем хранить там то, что и так может лежать в оперативной памяти.
Количество НПС влияет на пинг - а вот так быть не должно. Это говорит нам о том, что у вас неправильная архетиктура.
П.с. читаются ваши статьи достаточно трудно, ибо то что связано с сетью и разработкой сетевых игр вы пытаетесь объяснить словно маленьким детям (и делаете это на техническом ресурса, как сказали ранее), а то, что на мой взгляд не относится к разработке сервера напрямую, а скорее имеет отношение именно к PHP вы наоборот описываете наиболее подробно, только вот не понятно зачем. Мы и так поняли что PHP вы знаете. Но к разработке ММО это именно очень посредственное отношение.
Будь я на вашем месте, то писал бы статью которая не привязана к языку, и если были бы какие-то ключевые моменты в языке который использую я, то выносил бы это под спойлер отдельно.
Ну как то так. Жду вашу 5 статью.
webrobot Автор
15.06.2022 14:24Я занимаюсь этим уже 2 года и работаю в геймдеве.
И считаю что бы сделать сервер с поддержкой 100.000 онлайн не нужно "понимать" игроков - для создания интересных игр есть гейм дизайнеры и др люди
По поводу куда правильнее - правильнее для чего ? Для уменьшения размера пакета да. Но сейчас режим разработки и читать такое в Debug затруднительно...следовательно правильнее в этот момент времени строками
Про черепашку - можно ткнуть на карту (координаты) пойдет туда. Играя джойстиком - надо указывать направление (джойстик - ваша "черепашка"). Я не делал диагональное движение пока.
Вы пишите что не должны влиять NPC (которые пишут в базу данные и читают из нее) на PING - любая строчка кода, любая переменная все это влияет на скорость работы сервера. И следовательно вообще ВСЕ влияет на пинг (сколько у вас процессоров, какое железо, где находится). Вы рассуждаете поверхностно.
Когда у вас игра на 100-500 игроков и на экране 10 NPC - вы можете не замечать влияния на игру и не увидите отличие при Ping 50ms и 60ms а вот если сразу на карте будет 1000 NPC у вас как минимум на клиенте игра начнет медленнее отрабатывать (надо же больше данных отрисовывать) и ping увеличится (тк сервер с большими данными работает)
BIOACE
15.06.2022 14:34При грамотной архитектуре на клиенте не должно быть разницы 1 НПС или 1000, или вы на движение каждого НПС собираетесь слать отдельный пакет на клиент ?
Ладно бы вы сказали 1000 игроков, там то хоть понятно, что количество пакетов будет N*(N-1), из-за чего собственно и случаются лаги в людных местах в мморпг.
Зачем у вас НПС что-то читают и пишут в базу тоже не понятно.
В общем я начинаю сомневаться в вашей квалификации на счёт геймдева.
webrobot Автор
15.06.2022 14:38Если вы внимательно смотрели мои предыдущие статьи то могли заметить что NPC в онлайн игре - эти те же игроки, с искусственным интеллектом
Они ходят по карте, смотрят кто на карте есть и кто это (запрашивая данные) , атакуют и тп
BIOACE
15.06.2022 14:47Тем не менее вы так и не ответили причём тут база данных и зачем что-то читать из неё.
И что значит НПС это те же игроки ? Допустим у вас есть сущность character с набором действий от которой наследуются персонажи игрока и НПС, но это не делает НПС игроком и обращаться к базе или гонять пакеты по сети им тоже не нужно. (Есть конечно исключения, но не в данном случае).
webrobot Автор
15.06.2022 15:01Потому , что архитектура разделенная.
Сервер - один процесс, он не выполняет никакой логики и за это может 1млн соединения обрабатывать. И он знает только о websocket соединениях и если пришла команда - шлет ее в "сервисы"
Сервисы - ничего не знают от сервере , могут физически находится на разных серверах. Они работаю параллельно, запускаются по команде от игроков и уничтожаются по завершению. Сервисы читают из общего источника данных (база данных). Когда в них выполнится логика игровая, она выполняется например 3-10 мс - сервис вносить эти изменения в базу, шлет результат работы на Сервер (а он разошлет всем игрокам, тк результат должны все увидеть. например что игрок шагнул)
Процессы NPC - должны жить постоянно (тк игра не пошаговая и они должны работать не зависимо от того нажимает игрок сейчас кнопки или стоит). Эти процессы - некий один сервис который не завершает свою работу. Он обрабатывает все NPC и живые объекты , смотрит не пришла ли пора им двигаться или атаковать кого то а может быть самим нападать на друг друга и тп (те игровая логика) . И когда обработает - записать в бд (что бы и игроки новые запоганенные увидели новые что все npc уже на другой конец карты ушли или часть уже умерло) и отправить все изменения на Сервер (что бы игрокам разослать)
webrobot Автор
15.06.2022 15:04я считаю это грамотной архитектурой. А НЕ грамотной - когда один из игроков является сервером. и на клиенте рассчитывается все и шлется на сервер (то можно подделать) обновленное состояние мира. Dead By Daylight похожим образом работает (на демо серверах там игроки сами собой воскрешаются и летают по карте)
webrobot Автор
15.06.2022 15:09А еще НЕ грамотная архитектура это когда на Сервере выполняются сервисы (и он ждет эти 3-10 мс а не обрабатывает новые соединения) - это пример игры от workerman (в статье ссылка на нее).Ну и NPC там стоят пока их не дернуть
Хотя при малом количестве онлайна это работает на ура, а при большом...создается копия игры (те отдельный процесс выступавший вторым третьим и тп Сервером) и там свои игроки которые никогда не пересекаться
BoShurik
15.06.2022 15:22При этом, надо сказать, что лично у меня сложилось ощущение, что BrowserQuest сильно выигрывает у вашего Игоря по отзывчивости (и там и там было по одному игроку).
Вам нужно сделать что-то аналогичное, потому что техническая демка - это не то, чем нужно заманивать, а вот на BrowserQuest я залип надолго (и соответственно тыкался в ней минут 30, в отличие от вашей игры, где меня хватило на пару минут)
webrobot Автор
15.06.2022 15:30Так Игорь же не закончен. BrowserQuest закончен. и там стоит фикс 50 игроков. Плюс на фото виден рассинхрон
Игра мне тоже понравилось. Но я делаю сервер. Сами игры я делать не умею (а то что сделал для демонстрации)
Идея в том что можно любую игру потом сделать с грамотным сервером и API к нему
BIOACE
15.06.2022 16:07Я занимаюсь этим уже 2 года и работаю в геймдеве.
Сами игры я делать не умею
Ну вы уж определитесь пожалуйста
И может всё таки стоит сделать что-то более менее рабочее и похожее на BrowserQuest. А не то что есть сейчас, и потом уже писать статьи ?
webrobot Автор
15.06.2022 16:292 года я занимаюсь СЕРВЕРНОЙ частью ДЛЯ игр :)
Сами игры (механики, балансы, графика , Unity, анимация) я могу делать просто что бы вывести демонстрацию работы сервера (те КЛИЕНТ игры я по сути сделать могу но это будет не игра а так....).
Те Сервер - это некий набор библиотек, фаилов - скриптов хранящихся на удаленном ресурсы
webrobot Автор
15.06.2022 15:34Есть хорошие игры. но нет публичной технологии на которую можно поставить игру и сделать в ней онлайн жанра ММО
Думал что https://www.photonengine.com/ единственная более менее, а там оказывается до 100 человек
Если сейчас в том состоянии что есть сервер убрать все что я там химичу, оставить Redis и не тратить время на изменение архитектуры - можно сделать любую игру жанра ММО с онлайном до 500 человек и +- столько же NPC (не которые стоят а живых именно. если стоячих то там "условно" бесконечно можно было бы)
BIOACE
15.06.2022 16:16Давайте определимся что мы имеем ввиду под онлайном. Ибо онлайн может быть общий (на условных 10 серверах).
Онлайн на 1 сервере (но при этом игроки распределены по серверу равномерно) (тут кстати сервер тоже может быть на нескольких физических машинах)
Онлайн а 1 локации.
Онлайн на 1 локации где все игроки видят друг друга.
Если вы думаете что у Фотона ограничение в 100 человек из-за того что сервер не тянет, то вы ошибаетесь.
100 человек это всего лишь бесплатная лицензия, ибо люди хотят денег за свой труд и я их понимаю.
Я даже готов поспорить что если вы сделаете своё популярное решение на уровне Фотона, то вы тоже рано или поздно захотите с этого иметь денег.
Кстати хочу заметить что Фотон делал явно не один человек. Думаете в одиночку сможете лучше ?
webrobot Автор
15.06.2022 16:38Да вот нет, там не бесплатно а в прицепе это максимум (я честно сказать не вникал , ссылку взял из кометов)
Разумеется, в задумке есть и коммерческая выгода. Онлайн имеется в виду 1 сервер, одно ядро 4 Гб оперативной памяти (на одной локации или разбросанных по миру 500 игроков по моим подсчётам сервер выдержит и в текущем состоянии, но я ориентируюсь на другие цифры)
Ну а почему бы не сделать. Время тут главный ресурс. Определюсь с архитектурой и технологиями - пойдет дело быстрее (сами игровые механики делаются за пару дней. с технологиями для хранения данных сижу неделю с тестами и исследованиями)
BIOACE
15.06.2022 16:52Да вот нет, там не бесплатно а в прицепе это максимум (я честно сказать не вникал , ссылку взял из кометов)
'Я не вникал, но буду спорить'.
Если вы всё же прочтёте то что вы скинули то заметите что речь во первых про Photon Cloud, во вторых там говорится что для одной игры бесплатный лимит это 100 человек, а следующий (уже платный) доступный пакет это 500 человек. А в третьих там же на примере комнат говорится что считать количество подключений несколько не правильно, и правильнее будет считать количество пакетов за единицу времени.
Ну и извиняюсь если где обидел или могу обидеть в спорах, просто очень люблю дискутировать на интересующие меня темы.
П.с. ваши статьи мотивируют, но скорее мотивируют сделать и показать 'как надо' ????
webrobot Автор
15.06.2022 17:00у меня тоже будет Облачное решение. Как сервис. И мне кажется что фотон основан на том что сервером выступает экземпляр игры...что довольно требовательно по ресурсам
Плюс мне показалось достаточно сложно интегрировать в клиент...Те там библиотеки определенные
Я же смотрю в стороны REST API которая возвращает и получает только текстовые даныне. А тот кто делает игру сам решает что с ними делать и как там строить анимации и тп
webrobot Автор
15.06.2022 17:00в любом случае второй сервис , для простеньких 2Д игр сделать оказалось сложнее чем это кажется на первый взгляд
BoShurik
15.06.2022 16:57Ну, кстати, из этого FAQ видно, что для вашей целевой аудитории не особо важно количество игроков онлайн
Most Photon multiplayer games have 2-16 players
There are Photon games live with 32 or even 64 playersОткуда желание повысить онлайн? Это какой-то запрос от реальных разработчиков игр? Или просто цель с потолка?
webrobot Автор
15.06.2022 17:06Я исследую технологии (типа Redis и фреймворки типа workerman), сравниваю что сколько может обработать в секунду. И если что то сильно отстаёт - смотрю чем заменить
Отсюда берутся цифры (например есть возможность второй сервер сделать где будут хранится данные и обращаться к нему по тому же websocket смогут Сервисы. но насколько это будет лучше redis - надо смотреть ) https://github.com/walkor/GlobalData
BoShurik
15.06.2022 17:12Мне кажется, вы отбрасываете саму игровую логику, которая и будет бутылочным горлышком. Я бы сначала сделал игру, со всеми фичами, которые хочу видеть. И уже на ней бы экспериментировал с технологиями
webrobot Автор
15.06.2022 17:15я не могу придумать такиех фичей и логик которые бы нельзя было реализовать если сервер быстрый...поэтому...делаю сервер )
webrobot Автор
15.06.2022 17:19плюс не только сервером будет хорош будущий сервис а админ панелью (не знаю есть ли в фотоне такое - скажите)
Админка позволяет редактировать контент игрового мира (новые карты добавлять . npc и тп). Притом игра может быть как браузерной так и устанавливаться на устройства
webrobot Автор
15.06.2022 14:42можете сомневаться, не верить, говорить что ничего не получится - это нормально (мне часто пишут в комментариях)
Главное - результат. Сейчас какой ни какой результат - есть.
webrobot Автор
15.06.2022 14:27Я рассказываю как построить архитектуру. Как писать код - человек уже должен иметь навыки. Кому моя манера кажется не правильной, но и я программист, не блогер (у меня нет советующих навыков)
Но даже того малого что успел написать мне бы в начале пути очень бы помогло (тк статей про архитектуру попросту нет, никто не делится)
BIOACE
15.06.2022 14:37Если кому-то поможет то что вы написали в текущих 4 статьях, то я ему сочувствую, ибо эта информация есть в открытом доступе в куда более понятном и более информативном виде.
А по именно архитектуре вы пока что ничего толкового не написали.
Так же вы говорите что вы программист а не блогер, но при этом ведёте себя полностью противоположно. Задумайтесь.
webrobot Автор
15.06.2022 14:49Ну вы сами пишите про Redis "вот тут ничего не скажу, вещь полезная" - получается информация была полезна
Я не навязываю своего мнения. Но аргументировано его отстаиваю.Если считаете что есть решение лучше - скажите какое (какую базу для хранения использовать, как выстроить очередь отправки пакетов пользователям, покажите пример архитектуры ) или как минимум покажите статьи на эту же тему как с нуля писать сервера для игр и на каких технологиях
Если вы НЕ можете - значит ваше мнение субъективно и не обосновано
webrobot Автор
15.06.2022 14:52Я вижу много комментариев что так не надо и так не нужно.
Но за 9000 просмотров статей на 15.06.2022 я не увидел ни в одном комментарии как конкретно надо и почему именно (какие проблемы решатся и насколько станет лучше)
webrobot Автор
15.06.2022 14:32Следующая статья полагаю будет про ZeroMQ (очереди, что в замен REDIS Pub/Sub будут) и общую память Shared Memory - будем средствами PHP писать напрямую в блоки памяти оперативки
iamkisly
Вы опять наступаете на те же грабли. На овертехническом ресурсе рассказывать что такое ping и как он работает, да еще и в формате видео. В прошлый раз вы в картинках рассказывали, чем udp от tcp отличается.
В общем как вам еще в первой статье заметил MegaMANGO, это не статья, а реклама своего ютубканала. Тут такому
как правилоне рады.webrobot Автор
ну при всем негативе с вашей стороны вы прочитали все мои статьи. Подписывайтесь что бы
обругатьне пропустить следующие :)