Войти
ПрограммированиеФорумСеть

Одноранговые (p2p) сети в играх

Страницы: 1 2 Следующая »
#0
2:17, 2 апр. 2013

Добрый день!

Возникла следующая мысль:
Современные онлайн игры (имеются в виду различные mmo) работаю по принципу архитектуры клиент-сервер. Сервер обрабатывает логику, изменяет представление данных, клиент занимается визуализацией. Все круто, все счастливы.
Но верхний предел счастья будет ограничен ресурсами сервера, пропускным каналом и т.д.

Решение которое приходит в голову - разбить мир на части и отдать их симуляцию на клиент. Возможные проблемы с читерами не интересуют. Интересуют технические сложности в реализации протокола, методики синхронизации, обеспечения целостности данных и т.д.

Есть ли информация о том что кто-то этим занимался раньше, возможно были эксперименты ?


#1
4:33, 2 апр. 2013

То что ты хочешь почти не реально. Основная проблема в том, что все существующие распределённые сети имеют очень низкую скорость реакции (хотябы потому что они должны быть очень отказоустойчивыми (ну вылетел у Васи инет, что всю ММО ложить? а если Вася больше в сеть не зашел?)). И если для многих задач вроде файлообмена отклик в сесколько секунд не проблема, то для основной массы игр - проблема.

Если тебя интересуют алгоритмы - смотри в сторону реализации таких систем как BitCoin или DHT

#2
10:41, 2 апр. 2013

vugluskr86
> Интересуют технические сложности в реализации протокола
Их нет, реализация p2p сетей столь же проста, как и клиент-сервера.

> методики синхронизации
Те же, что на клиент-сервере.

> обеспечения целостности данных
Контрольные суммы.

> Есть ли информация о том что кто-то этим занимался раньше, возможно были эксперименты ?
Конечно были, наверняка многие школьники с этим экспериментировали, и достаточно быстро приходили к заключению, что такую сеть будет с ходу класть на лопатки, любой школото-любитель подмены трафика.

PS. Единственное, для чего p2p сети подходят в ММО - это для распространения контента.

#3
11:45, 2 апр. 2013

подписался.

по теме - конечно же нужна не p2p, а гибридная сеть. с делегированием клиентам просчета мира, причем клиент сам не знает какую часть мира он считает, и конечно же проверка просчета на сервере(например иногда проверять правильно ли клиент посчитал) и дублирование - просчет одного и того же на разных клиентах и сравнение.
и думаю это вполне реально, но сложно.

#4
14:42, 2 апр. 2013

kerch83
> и дублирование - просчет одного и того же на разных клиентах и сравнение.
а если не равно?

#5
14:54, 2 апр. 2013
Основная проблема в том, что все существующие распределённые сети имеют очень низкую скорость реакции .

Я понимаю про проблемы со скоростью реакции, но существует масса примеров игр с такой механикой, где это не будет критичным местом.
(хотябы потому что они должны быть очень отказоустойчивыми (ну вылетел у Васи инет, что всю ММО ложить? а если Вася больше в сеть не зашел?))

Вот это первая проблема. Положим есть определенное кол-во игроков, если представление мира они синхронизировали и алгоритмы обработки реализуют одинаково, то любой другой клиент станет сервером, в замен того Васи с его проблемным интернетом.
В идеальном случае они все являются серверами просто доверяют кому-то одному. Как выбрать, клиент с максимальным приоритетом ? На ум приходят системы с ранжированием или что-то в этом роде.
по теме - конечно же нужна не p2p, а гибридная сеть. с делегированием клиентам просчета мира, причем клиент сам не знает какую часть мира он считает, и конечно же проверка просчета на сервере(например иногда проверять правильно ли клиент посчитал) и дублирование - просчет одного и того же на разных клиентах и сравнение.

Согласен, это действительно получается гибридная сеть, а дублирование и сравнение расчетов уже есть часть задачи обеспечения целостности данных, т.е. для того чтобы 3 клиента в результате расчета получили одинаковый результат они должны иметь одинаковые данные на входе. Например  если они считаю мир в некий момент времени, то в этот момент времени все у них должно происходить одинаково, вплоть до того, что генератор случайных чисел должен выдавать одинаковые последовательности на всех клиентах (в один момент времени). Под временем я подразумеваю время мира а не часы клиента или сервера.

Одним из применений этому может быть параллельное хранение и обработка мира в песочницах по типу minecraft или подобных играх, где ограничения на размер мира и максимальный онлайн упрутся в кол-во оперативной памяти.
Тут получается что все хранят мир у себе, сами его считают и синхронизируют уже например по протоколу похожему на тот что применяется при файловом обмене в p2p сетях. В данном случает один из клиентов (имеющий наивысший приоритет, page rank и т.д) будет иметь эталонный мир, и если что на него можно будет ориентироваться.

#6
19:30, 2 апр. 2013

vugluskr86
> Я понимаю про проблемы со скоростью реакции, но существует масса примеров игр с
> такой механикой, где это не будет критичным местом.
А в надёжной сети такого класса скорость реакции будет в секундах измеряться, а то и больше. Для тех же игр где даже такие задержки не сущестенны... там обычно далеко не те нагрузки чтобы вообще мутить п2п сеть. Короче основная проблема будет такая: для тех игр для которых нужны сверхбольшие расчёты, оно не подойдёт из-за пинга. Для тех игр для пинг в несколько секунд не страшен... а нафига оно вообще надо?

>Вот это первая проблема. Положим есть определенное кол-во игроков, если представление мира они синхронизировали и алгоритмы обработки реализуют одинаково, то любой другой клиент станет сервером, в замен того Васи с его проблемным интернетом.
Т.е. у тебя все игроки имеют весь мир? Ведь для того чтобы заменить произвольную ноду, другая нода должна иметь её данные. Кроме того нужен постоянный сквозной контроль целостности, а так как игра это целостноя система (ну нельзя тут как в БитКоине не принять один платёж если его блок повреждён, тут или тик откатывать, или нужен источник верных данные) то расчёты одного и тогоже должны проводится множеством клиентов.

#7
22:55, 2 апр. 2013
А в надёжной сети такого класса скорость реакции будет в секундах измеряться, а то и больше. Для тех же игр где даже такие задержки не сущестенны... там обычно далеко не те нагрузки чтобы вообще мутить п2п сеть. Короче основная проблема будет такая: для тех игр для которых нужны сверхбольшие расчёты, оно не подойдёт из-за пинга. Для тех игр для пинг в несколько секунд не страшен... а нафига оно вообще надо?

Если рассматривать тот контекст применимости (minecraft и подобные игры) то вполне достаточно и таких задержек. Все что нужно для быстрых расчетов (коллизии и проч. может считать сам клиент). Все остальные расчеты вообще можно считать периодическими, по сути это даже не расчеты а синхронизация данных.
Т.е. у тебя все игроки имеют весь мир? Ведь для того чтобы заменить произвольную ноду, другая нода должна иметь её данные. Кроме того нужен постоянный сквозной контроль целостности, а так как игра это целостноя система (ну нельзя тут как в БитКоине не принять один платёж если его блок повреждён, тут или тик откатывать, или нужен источник верных данные) то расчёты одного и тогоже должны проводится множеством клиентов.

В данном случае все они имеют полностью ту часть мира на которой находятся в один момент времени, верные данные, это те, которые находились у ноды с максимальным page rank в последний момент (перед тем как она отвалилась или что-то в этом роде)
Прошло более 5 лет
#8
10:48, 6 фев. 2019

Bishop

Для тех игр для пинг в несколько секунд не страшен... а нафига оно вообще надо?

Для вечного сервера.
#9
12:51, 6 фев. 2019

vugluskr86
> Решение которое приходит в голову - разбить мир на части и отдать их симуляцию
> на клиент.
Малость не правильное решение.

Мир разбивают на части и симулируют на том же сервере. А вернее на кластере.

#10
12:53, 6 фев. 2019

vugluskr86
Для примера. В Eve под jita выделен даже отдельный сервер. Т.к. одновременно там дохрена клиентов.

#11
12:58, 6 фев. 2019

vugluskr86
> разбить мир на части и отдать их симуляцию на клиент.
Такое можно использовать, но не для реал-тайм. Для каких-нибудь пошаговых стратегий еще катит.
Т.к. в распределенной системе туева хуча времени тратится на

> синхронизацию, обеспечения целостности данных и т.д

#12
(Правка: 20:54) 20:51, 6 фев. 2019

Bishop
> И если для многих задач вроде файлообмена отклик в сесколько секунд не
> проблема, то для основной массы игр - проблема.
скажем сижу я на востоке на камчатском полу-острове и я клиент, а ты сервер имеешь на западе в москве и ты сервер,и это есть "тип-вид клиент-сервер", так например действия туда и сюда все равно же будут с паузой реально две секунды...это то есть ты тот регион не рассматриваешь как клиентуру и к ним не подключаешься , то есть это потенциально минус миллион клиентов(и как следствие скажем донат магазин супер меч 1рубль купить это потенциально минус миллион упущенная выгода) ?

#13
23:04, 6 фев. 2019

Rikk
> скажем сижу я на востоке на камчатском полу-острове и я клиент, а ты сервер
> имеешь на западе в москве и ты сервер,и это есть "тип-вид клиент-сервер", так
> например действия туда и сюда все равно же будут с паузой реально две
> секунды...
Я бы посмотрел на то как ты будешь нормально играть во что-то кроме пошаговых игр с таким пингом. Для примера в том же AION при пинге в 100мс в ПвП уже делать нечего было. Да и во многих данжах тоже, тупо не успевал скилы прожимать. Я уж молчу о том, что пигни в 2сек это из раздела фантастики или говноканалов. В реальности оттуда пинг будет около 200-300мс.

А для всяких браузерных пошаговых стратежек... оно не надо просто. Это как в истории про буханку хлеба и троллейбус.

Такие вещи решаются несколькими серверами. Вообще эффективный радиус для сервера - до 3000км. Собственно поэтому в тому же SC2 в StarBattle невозможно играть из европы в американсом регионе. Тупо тормоза, причём из-за физики.

#14
(Правка: 5:32) 5:28, 7 фев. 2019

При большом количестве игроков может получиться. Видимо сначала нужно довести популярность игры до какого-то уровня с использованием серверов. А потом уже p2p подключать. И не только p2p, но и mesh. Подбирать несколько самых быстрых цепочек, штук пять на игрока, и по ним гонять данные. Может даже и больше, или прозапас держать обновляемый список. Т.е. игроку приходит пять копий данных, используется первый пришедший пакет. Из-за многократного дублирования расчетов и передачи данных у людей с быстрым интернетом и процессором будет забиваться канал и сильно греться процессор.  Это может стать проблемой, как сделать так, чтобы не было недовольства и потенциального ухода из сети.

Страницы: 1 2 Следующая »
ПрограммированиеФорумСеть