Сами игры (механики, балансы, графика , Unity, анимация) я могу делать просто что бы вывести демонстрацию работы сервера (те КЛИЕНТ игры я по сути сделать могу но это будет не игра а так....).
Те Сервер - это некий набор библиотек, фаилов - скриптов хранящихся на удаленном ресурсы
Если сейчас в том состоянии что есть сервер убрать все что я там химичу, оставить Redis и не тратить время на изменение архитектуры - можно сделать любую игру жанра ММО с онлайном до 500 человек и +- столько же NPC (не которые стоят а живых именно. если стоячих то там "условно" бесконечно можно было бы)
А еще НЕ грамотная архитектура это когда на Сервере выполняются сервисы (и он ждет эти 3-10 мс а не обрабатывает новые соединения) - это пример игры от workerman (в статье ссылка на нее).Ну и NPC там стоят пока их не дернуть
Хотя при малом количестве онлайна это работает на ура, а при большом...создается копия игры (те отдельный процесс выступавший вторым третьим и тп Сервером) и там свои игроки которые никогда не пересекаться
я считаю это грамотной архитектурой. А НЕ грамотной - когда один из игроков является сервером. и на клиенте рассчитывается все и шлется на сервер (то можно подделать) обновленное состояние мира. Dead By Daylight похожим образом работает (на демо серверах там игроки сами собой воскрешаются и летают по карте)
Сервер - один процесс, он не выполняет никакой логики и за это может 1млн соединения обрабатывать. И он знает только о websocket соединениях и если пришла команда - шлет ее в "сервисы"
Сервисы - ничего не знают от сервере , могут физически находится на разных серверах. Они работаю параллельно, запускаются по команде от игроков и уничтожаются по завершению. Сервисы читают из общего источника данных (база данных). Когда в них выполнится логика игровая, она выполняется например 3-10 мс - сервис вносить эти изменения в базу, шлет результат работы на Сервер (а он разошлет всем игрокам, тк результат должны все увидеть. например что игрок шагнул)
Процессы NPC - должны жить постоянно (тк игра не пошаговая и они должны работать не зависимо от того нажимает игрок сейчас кнопки или стоит). Эти процессы - некий один сервис который не завершает свою работу. Он обрабатывает все NPC и живые объекты , смотрит не пришла ли пора им двигаться или атаковать кого то а может быть самим нападать на друг друга и тп (те игровая логика) . И когда обработает - записать в бд (что бы и игроки новые запоганенные увидели новые что все npc уже на другой конец карты ушли или часть уже умерло) и отправить все изменения на Сервер (что бы игрокам разослать)
Я вижу много комментариев что так не надо и так не нужно.
Но за 9000 просмотров статей на 15.06.2022 я не увидел ни в одном комментарии как конкретно надо и почему именно (какие проблемы решатся и насколько станет лучше)
Ну вы сами пишите про Redis "вот тут ничего не скажу, вещь полезная" - получается информация была полезна
Я не навязываю своего мнения. Но аргументировано его отстаиваю.
Если считаете что есть решение лучше - скажите какое (какую базу для хранения использовать, как выстроить очередь отправки пакетов пользователям, покажите пример архитектуры ) или как минимум покажите статьи на эту же тему как с нуля писать сервера для игр и на каких технологиях
Если вы НЕ можете - значит ваше мнение субъективно и не обосновано
Следующая статья полагаю будет про ZeroMQ (очереди, что в замен REDIS Pub/Sub будут) и общую память Shared Memory - будем средствами PHP писать напрямую в блоки памяти оперативки
Я рассказываю как построить архитектуру. Как писать код - человек уже должен иметь навыки. Кому моя манера кажется не правильной, но и я программист, не блогер (у меня нет советующих навыков)
Но даже того малого что успел написать мне бы в начале пути очень бы помогло (тк статей про архитектуру попросту нет, никто не делится)
И считаю что бы сделать сервер с поддержкой 100.000 онлайн не нужно "понимать" игроков - для создания интересных игр есть гейм дизайнеры и др люди
По поводу куда правильнее - правильнее для чего ? Для уменьшения размера пакета да. Но сейчас режим разработки и читать такое в Debug затруднительно...следовательно правильнее в этот момент времени строками
Про черепашку - можно ткнуть на карту (координаты) пойдет туда. Играя джойстиком - надо указывать направление (джойстик - ваша "черепашка"). Я не делал диагональное движение пока.
Вы пишите что не должны влиять NPC (которые пишут в базу данные и читают из нее) на PING - любая строчка кода, любая переменная все это влияет на скорость работы сервера. И следовательно вообще ВСЕ влияет на пинг (сколько у вас процессоров, какое железо, где находится). Вы рассуждаете поверхностно.
Когда у вас игра на 100-500 игроков и на экране 10 NPC - вы можете не замечать влияния на игру и не увидите отличие при Ping 50ms и 60ms а вот если сразу на карте будет 1000 NPC у вас как минимум на клиенте игра начнет медленнее отрабатывать (надо же больше данных отрисовывать) и ping увеличится (тк сервер с большими данными работает)
Если вам действительно интересно подискутировать по поводу архитектурных решений и узнать получится или нет - можете подписаться на мой профиль и следить за новыми статьями точечно указывая что я делаю не так (если у Вас достаточно компетенции) или рассказать компетентным людям про проект.
Уже написана новая, как раз про архитектуру и скорость
Вы невнимательно читали статью. В ней я рассказываю что сам язык это "капля в море" влияние на скорость, а гораздо более важна скорость работа с базами , кеширование и построенная архитектура (вот человек писал на Си в видео - и что вышло)
Писать сервер можно на любом языке при грамотным подходе.
Ваше мнение что мой уровень низок -субъективно ,а Unity в статьях взят для демонстрации онлайна - я не профессионал и сами "игры" не умею делать. Клиент (а тк это клиент-серверное взаимодействие является Фронтом, а не бекендом как вы его сравниваете. Бекенд - сервер, на клиенте ничего не высчитывается, тока анимируется) можно писать на чем угодно (хоть игры на js, хоть на unreal engine) - там для взаимодействия с "сервером" всего один контроллер предполагается.
В добавок никто не спорит что нет готового решения.
Эго сделаю я
В серии статей (посмотреть можно в моем профиле) можно видеть скорость ping (10 мс на движение) и результаты работы (пока держит до 1000 онлайн)
Если вы считаете что у вас есть более разумный и лучший способ построения архитектуры сервера онлайн игр - дайте его миру. Я с радостью почитаю
2 года я занимаюсь СЕРВЕРНОЙ частью ДЛЯ игр :)
Сами игры (механики, балансы, графика , Unity, анимация) я могу делать просто что бы вывести демонстрацию работы сервера (те КЛИЕНТ игры я по сути сделать могу но это будет не игра а так....).
Те Сервер - это некий набор библиотек, фаилов - скриптов хранящихся на удаленном ресурсы
Есть хорошие игры. но нет публичной технологии на которую можно поставить игру и сделать в ней онлайн жанра ММО
Думал что https://www.photonengine.com/ единственная более менее, а там оказывается до 100 человек
Если сейчас в том состоянии что есть сервер убрать все что я там химичу, оставить Redis и не тратить время на изменение архитектуры - можно сделать любую игру жанра ММО с онлайном до 500 человек и +- столько же NPC (не которые стоят а живых именно. если стоячих то там "условно" бесконечно можно было бы)
Так Игорь же не закончен. BrowserQuest закончен. и там стоит фикс 50 игроков. Плюс на фото виден рассинхрон
Игра мне тоже понравилось. Но я делаю сервер. Сами игры я делать не умею (а то что сделал для демонстрации)
Идея в том что можно любую игру потом сделать с грамотным сервером и API к нему
А еще НЕ грамотная архитектура это когда на Сервере выполняются сервисы (и он ждет эти 3-10 мс а не обрабатывает новые соединения) - это пример игры от workerman (в статье ссылка на нее).Ну и NPC там стоят пока их не дернуть
Хотя при малом количестве онлайна это работает на ура, а при большом...создается копия игры (те отдельный процесс выступавший вторым третьим и тп Сервером) и там свои игроки которые никогда не пересекаться
я считаю это грамотной архитектурой. А НЕ грамотной - когда один из игроков является сервером. и на клиенте рассчитывается все и шлется на сервер (то можно подделать) обновленное состояние мира. Dead By Daylight похожим образом работает (на демо серверах там игроки сами собой воскрешаются и летают по карте)
Потому , что архитектура разделенная.
Сервер - один процесс, он не выполняет никакой логики и за это может 1млн соединения обрабатывать. И он знает только о websocket соединениях и если пришла команда - шлет ее в "сервисы"
Сервисы - ничего не знают от сервере , могут физически находится на разных серверах. Они работаю параллельно, запускаются по команде от игроков и уничтожаются по завершению. Сервисы читают из общего источника данных (база данных). Когда в них выполнится логика игровая, она выполняется например 3-10 мс - сервис вносить эти изменения в базу, шлет результат работы на Сервер (а он разошлет всем игрокам, тк результат должны все увидеть. например что игрок шагнул)
Процессы NPC - должны жить постоянно (тк игра не пошаговая и они должны работать не зависимо от того нажимает игрок сейчас кнопки или стоит). Эти процессы - некий один сервис который не завершает свою работу. Он обрабатывает все NPC и живые объекты , смотрит не пришла ли пора им двигаться или атаковать кого то а может быть самим нападать на друг друга и тп (те игровая логика) . И когда обработает - записать в бд (что бы и игроки новые запоганенные увидели новые что все npc уже на другой конец карты ушли или часть уже умерло) и отправить все изменения на Сервер (что бы игрокам разослать)
Я вижу много комментариев что так не надо и так не нужно.
Но за 9000 просмотров статей на 15.06.2022 я не увидел ни в одном комментарии как конкретно надо и почему именно (какие проблемы решатся и насколько станет лучше)
Ну вы сами пишите про Redis "вот тут ничего не скажу, вещь полезная" - получается информация была полезна
Я не навязываю своего мнения. Но аргументировано его отстаиваю.
Если считаете что есть решение лучше - скажите какое (какую базу для хранения использовать, как выстроить очередь отправки пакетов пользователям, покажите пример архитектуры ) или как минимум покажите статьи на эту же тему как с нуля писать сервера для игр и на каких технологиях
Если вы НЕ можете - значит ваше мнение субъективно и не обосновано
можете сомневаться, не верить, говорить что ничего не получится - это нормально (мне часто пишут в комментариях)
Главное - результат. Сейчас какой ни какой результат - есть.
Если вы внимательно смотрели мои предыдущие статьи то могли заметить что NPC в онлайн игре - эти те же игроки, с искусственным интеллектом
Они ходят по карте, смотрят кто на карте есть и кто это (запрашивая данные) , атакуют и тп
Следующая статья полагаю будет про ZeroMQ (очереди, что в замен REDIS Pub/Sub будут) и общую память Shared Memory - будем средствами PHP писать напрямую в блоки памяти оперативки
Я рассказываю как построить архитектуру. Как писать код - человек уже должен иметь навыки. Кому моя манера кажется не правильной, но и я программист, не блогер (у меня нет советующих навыков)
Но даже того малого что успел написать мне бы в начале пути очень бы помогло (тк статей про архитектуру попросту нет, никто не делится)
Я занимаюсь этим уже 2 года и работаю в геймдеве.
И считаю что бы сделать сервер с поддержкой 100.000 онлайн не нужно "понимать" игроков - для создания интересных игр есть гейм дизайнеры и др люди
По поводу куда правильнее - правильнее для чего ? Для уменьшения размера пакета да. Но сейчас режим разработки и читать такое в Debug затруднительно...следовательно правильнее в этот момент времени строками
Про черепашку - можно ткнуть на карту (координаты) пойдет туда. Играя джойстиком - надо указывать направление (джойстик - ваша "черепашка"). Я не делал диагональное движение пока.
Вы пишите что не должны влиять NPC (которые пишут в базу данные и читают из нее) на PING - любая строчка кода, любая переменная все это влияет на скорость работы сервера. И следовательно вообще ВСЕ влияет на пинг (сколько у вас процессоров, какое железо, где находится). Вы рассуждаете поверхностно.
Когда у вас игра на 100-500 игроков и на экране 10 NPC - вы можете не замечать влияния на игру и не увидите отличие при Ping 50ms и 60ms а вот если сразу на карте будет 1000 NPC у вас как минимум на клиенте игра начнет медленнее отрабатывать (надо же больше данных отрисовывать) и ping увеличится (тк сервер с большими данными работает)
ну при всем негативе с вашей стороны вы прочитали все мои статьи. Подписывайтесь что бы
обругатьне пропустить следующие :)Спасибо за идею к следующей статье
Если вам действительно интересно подискутировать по поводу архитектурных решений и узнать получится или нет - можете подписаться на мой профиль и следить за новыми статьями точечно указывая что я делаю не так (если у Вас достаточно компетенции) или рассказать компетентным людям про проект.
Уже написана новая, как раз про архитектуру и скорость
При всем пессимизме с вашей стороны я понял что Фотон переоценил, я думал там может быть большое количество онлайн
Это еще раз доказывает что реализации такого сервиса будет многим полезна у кого нет финансовых и технических возможности сделать свое
Вы невнимательно читали статью. В ней я рассказываю что сам язык это "капля в море" влияние на скорость, а гораздо более важна скорость работа с базами , кеширование и построенная архитектура (вот человек писал на Си в видео - и что вышло)
Писать сервер можно на любом языке при грамотным подходе.
Ваше мнение что мой уровень низок -субъективно ,а Unity в статьях взят для демонстрации онлайна - я не профессионал и сами "игры" не умею делать. Клиент (а тк это клиент-серверное взаимодействие является Фронтом, а не бекендом как вы его сравниваете. Бекенд - сервер, на клиенте ничего не высчитывается, тока анимируется) можно писать на чем угодно (хоть игры на js, хоть на unreal engine) - там для взаимодействия с "сервером" всего один контроллер предполагается.
В добавок никто не спорит что нет готового решения.
Эго сделаю я
В серии статей (посмотреть можно в моем профиле) можно видеть скорость ping (10 мс на движение) и результаты работы (пока держит до 1000 онлайн)
Если вы считаете что у вас есть более разумный и лучший способ построения архитектуры сервера онлайн игр - дайте его миру. Я с радостью почитаю
Это первая часть серии статей.
Если вам интересна эта тематика вы можете подписаться на мой профиль и посмотреть следующие части
Приходишь в банк брать кредит, а тебе оператор : "Вы не хотите сыграть в игру?!"