Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
на php - не знаю как. 29.10.08 19:46 Число просмотров: 4585
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
на php - не знаю как.
Представь что твой cgi скрипт не выходит п оокончании работы, а завязывается в бесконечный цикл ожидания новостей. От юзера, от сервера, от кого угодно. При этом соединение остаётся открытым. Апплет на машине постоянно получает чего-то от сервера.
примерно так.
|
|
<theory>
|
Синхронизация в многопользовательских онлайн играх 29.10.08 09:53
Автор: Vedrus <Serokhvostov Anton> Статус: Member
|
Пытаюсь разобраться вот с какой вещью. Например, есть 3D сцена, по которой гуляют несколько человек (зарегистрированных пользователей), в том числе я.
Со мной понятно: когда я нажимаю на клавиатуру или мышь данные передаются серверу и он фиксирует моё перемещение. А как быть с другими пользователями, чтобы на моём компе их перемещения тоже отображались?
То, что придумал я – это несколько раз в секунду опрашивать сервер о текущем состоянии сцены и на основе полученных данных прорисовывать сцену. Но такой вариант трафика и других ресурсов очень много жрать будет.
Как можно решить такую проблему более цивилизованно?
|
|
Всем спасибо за много информации. Буду вникать. 30.10.08 02:24
Автор: Vedrus <Serokhvostov Anton> Статус: Member
|
|
|
|
Скорее не опрос, а push 29.10.08 17:45
Автор: PS <PS> Статус: Elderman
|
> Со мной понятно: когда я нажимаю на клавиатуру или мышь
> данные передаются серверу и он фиксирует моё перемещение. А
> как быть с другими пользователями, чтобы на моём компе их
> перемещения тоже отображались?
>
> То, что придумал я – это несколько раз в секунду опрашивать
> сервер о текущем состоянии сцены и на основе полученных
> данных прорисовывать сцену. Но такой вариант трафика и
> других ресурсов очень много жрать будет.
>
При действии пользователя данные отсылаются серверу. Сервер рассылает их всем подписчикам (другим пользователям).
Клиент умный. Клиент умеет вычислять возможную точку находжения объектов в последующие моменты времени.
Например от пользователя не передается информация о точке нахождения, а передается информация о действии. Я нахожусь там то и там то, и начал бежать на северо-восток, с такой-то скоростью. Все.
Все остальные клиенты начинают вычислять где этот перец сейчас может находится.
А вообще, самый простой способ разобраться - поставить любую online игру и проанализировать снятый сниффером траффик.
|
| |
Боюсь, снифить трафик бесполезно. Высоковероятно - данные криптуются для защиты от читеров. 29.10.08 19:45
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | |
Ну, всегда можно попробовать... 30.10.08 19:07
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
| |
"Сервер рассылает их всем подписчикам (другим... 29.10.08 17:48
Автор: Vedrus <Serokhvostov Anton> Статус: Member
Отредактировано 29.10.08 17:51 Количество правок: 1
|
"Сервер рассылает их всем подписчикам (другим пользователям)"
А про это можно поподробнее? Я всегда думал, что сервер инициативу не проявляет, а только по запросу клиента всё делает.
ЗЫ. Мне кажется не факт, что в игре, которая мне попадётся будет оптимальный алгоритм передачи данных.
|
| | |
Это как вариант 29.10.08 18:11
Автор: PS <PS> Статус: Elderman
|
> "Сервер рассылает их всем подписчикам (другим
> пользователям)"
> А про это можно поподробнее? Я всегда думал, что сервер
> инициативу не проявляет, а только по запросу клиента всё
> делает.
>
> ЗЫ. Мне кажется не факт, что в игре, которая мне попадётся
> будет оптимальный алгоритм передачи данных.
В отличие от web, online игра должна реагировать очень быстро. А пока клиент прочухается, пока отошлет запрос, пока сервер отработает пол миллиона запросов - ты, как игрок, уснешь перед монитором.
Как вариант: избавится от логики запросов. Клиенту все равно нужны свежие данные (иначе смысла в игре нет), так зачем от него ждать запросов? Можно при появлении обновлений в контексте - сразу поставлять их клиенту.
При этом сервер может даже не отслеживать положении игроков, или отслеживать их на отдельном сервере не в рилтайм режиме, с целью выискивания читтеров.
Например, если ты подменяешь стандартный игровой клиент своей чит-программой, которая игнорирует карту, и проходишь сквозь стены, летаешь по воздуху и т.д., то тебя засекут не сразу, а скажем, через пол часика. Это такой компромисный вариант между функциональностью и скорострельностью серверной части.
Как конкретно реализована каждая игра - можно разобраться по траффику.
|
| | | |
Пусть сервак все рассылает без запросов. 30.10.08 14:36
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 30.10.08 14:36 Количество правок: 1
|
> Как вариант: избавится от логики запросов.
Пусть сервак все рассылает без запросов.
> При этом сервер может даже не отслеживать положении
> игроков, или отслеживать их на отдельном сервере не в
> рилтайм режиме, с целью выискивания читтеров.
> Например, если ты подменяешь стандартный игровой клиент
> своей чит-программой, которая игнорирует карту, и проходишь
> сквозь стены, летаешь по воздуху и т.д., то тебя засекут не
Чтоб такого не было - вся игра идет на серваке, а клиенты посылают серваку сигналы управления (нажатия на кнопки и движения мышки). Сервак рассылает всем координаты и положения всех игроков и прочих подвижных предметов, которые находятся в пределах видимости.
|
| | | | |
Не соглашусь с последним утверждением 31.10.08 11:35
Автор: PS <PS> Статус: Elderman
|
> Чтоб такого не было - вся игра идет на серваке, а клиенты
> посылают серваку сигналы управления (нажатия на кнопки и
> движения мышки). Сервак рассылает всем координаты и
> положения всех игроков и прочих подвижных предметов,
> которые находятся в пределах видимости.
Пусть у тебя играют 500000 человек. Количество зон в игре не важно, т.к. все зоны в пределах сервера обрабатываются одной машиной. Кроме людей есть еще мобы и игровые предметы. Количество мобов примем три на человека.
Если ты решишь рассылать координаты всех подвижных участников игры: игроков и мобов, то тебе придется в рил-тайм обсчитывать полтора миллиона объектов. Причем не только их положение, но и зону видимости пол миллиона людей.
Ничего не настораживает ?
|
| | | | | |
Эта какая игра сейчас позволяет иметь полмиллиона участников в одном мире? [upd] 31.10.08 20:05
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 31.10.08 20:12 Количество правок: 1
|
> Пусть у тебя играют 500000 человек. Количество зон в игре
> не важно, т.к. все зоны в пределах сервера обрабатываются
> одной машиной. Кроме людей есть еще мобы и игровые
Нет, не одной. Вполне можно сделать распределенную считалку с синхронизацией на швах.
> предметы. Количество мобов примем три на человека.
> Если ты решишь рассылать координаты всех подвижных
> участников игры: игроков и мобов, то тебе придется в
> рил-тайм обсчитывать полтора миллиона объектов. Причем не
> только их положение, но и зону видимости пол миллиона
> людей.
Зону видимости можно только прикинуть - вместо обычной метрики sqrt(x^2 + y^2 + x^2) можно использовать метрикуx+y+z
> Ничего не настораживает ?
Ничего. Полтора миллиона объектов на сцене - вполне сопоставимо с числом полигонов в одном фрейме современной игрушки. Обсчитываются легко - рисовать то ничего не надо.
----------------------
Вот здесь http://en.wikipedia.org/wiki/Comparison_of_MMORPGs пишут о нагрузке примерно 36к игроков на один сервер в WoW. И это не тот результат, которого когда либо сможет достичь синглдевелопер. Так что ориентироваться нужно в лучшем случае на 1-2к
|
| | | | | |
Написание в расчете на 5, 50 и 500000 игроков должно иметь несколько... 31.10.08 15:52
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 31.10.08 15:54 Количество правок: 3
|
> Пусть у тебя играют 500000 человек. Количество зон в игре
Написание в расчете на 5, 50 и 500000 игроков должно иметь несколько разный подход.
Когда народа много (сомневаюсь, что активных плееров у Ведруса в игрушке достигет поллимона, но отрицать тоже нельзя), можно раскидывать народ по сервакам. Не обязательно всем в одной сцене/эпизоде/уровне участвовать.
> не важно, т.к. все зоны в пределах сервера обрабатываются
> одной машиной. Кроме людей есть еще мобы и игровые
> предметы. Количество мобов примем три на человека.
> Если ты решишь рассылать координаты всех подвижных
> участников игры: игроков и мобов, то тебе придется в
> рил-тайм обсчитывать полтора миллиона объектов. Причем не
> только их положение, но и зону видимости пол миллиона
> людей.
> Ничего не настораживает ?
Все зависит от узкого места. Если это вычислялка, а сетка сверхскоростная (80386 на гигабитке), то да, а если наоборот (многопроцовый многоядровый Коре2 на мегабитном интернете), то придется стараться уменьшать трафик.
|
| | | | | |
Настораживает 31.10.08 13:08
Автор: Heller <Heller> Статус: Elderman
|
> Пусть у тебя играют 500000 человек. Количество зон в игре
> не важно, т.к. все зоны в пределах сервера обрабатываются
> одной машиной. Кроме людей есть еще мобы и игровые
> предметы. Количество мобов примем три на человека.
> Если ты решишь рассылать координаты всех подвижных
> участников игры: игроков и мобов, то тебе придется в
> рил-тайм обсчитывать полтора миллиона объектов. Причем не
> только их положение, но и зону видимости пол миллиона
> людей.
> Ничего не настораживает ?
Отправлять надо только то, что для конкретного клиента актуально. Однако настораживает меня именно твой вариант, а не DPP. Если пользователь будет сам сообщать какую информацию ему отдать, появляется широкое поле для читерства. Все равно решать что кому отдать должен сервер.
|
| | | | | | |
Проблема читерства может быть решена другими способами 31.10.08 13:32
Автор: PS <PS> Статус: Elderman
|
> Отправлять надо только то, что для конкретного клиента
> актуально. Однако настораживает меня именно твой вариант, а
> не DPP. Если пользователь будет сам сообщать какую
> информацию ему отдать, появляется широкое поле для
> читерства. Все равно решать что кому отдать должен сервер.
Повторю еще раз: пол миллиона человек в online - высчитывать что для каждого из них актуально, а что нет - физически не возможно.
Проблема читерства может быть решена другим способом: есть back сервер, на котором неспешно проверяются команды и состояния игроков. Сервера загружены не постоянно, в ночное время, и рабочее дневное - количество игроков много меньше чем с 18 до 24 по москве. Значит именно в ночное время back сервер будет "догонять" текущую ситуацию. При обнаружение читеров back просто блокирует данный аккаунт. Все читерские последствия отменяются (если возможно). Например из счетчика побед игроков, с которым сражался читер - исключаются поражения, связаные с этим читером.
Так же в игре может быть предусмотрена команда: "Пожаловаться на читера".
Ну и напоследок - не совсем прозрачные протоколы между клиентом и сервером (это так, от школьников).
P.S. Такой алгоритм работы возможен для широкомаштабных игр, в которых люди проводят месяца или года (вряд ли кто пойдет ради выиграша одного двух боев на риск потерять персонажа на которого затрачено пол года сидения перед монитором). И совсем не подходит для локальных стрелялок (ну забанили твой аккаунт - завел новый и перестрелял всех). Однако в локальных стрелялках нет полу-миллионой аудитории :) А за 20ю человеками может и front последить в рил-тайме.
|
| | | | | | | |
Не вижу сложностей 31.10.08 15:11
Автор: Heller <Heller> Статус: Elderman
|
> Повторю еще раз: пол миллиона человек в online -
> высчитывать что для каждого из них актуально, а что нет -
> физически не возможно.
По-моему вполне возможно, главное грамотно локализовать данные (кластеризовать игроков или не знаю как правильнее сказать). Грубо говоря у тебя есть много локаций, и когда кто-то совершает некое действие, оно рассылается всем в пределах данной локации. Где сложности? А вот механизм с запрашиванием новых данных от сервера мне выглядит более трудоемким, причем ничем не упрощающим реализацию.
Мне моя реализация видится так:
Сервер - Игрок A двинулся в сектор Б.
Клиент - Ок, понял.
Сервер - Игрое Б замочил игрока Ц.
Клиент - Ок, понял.
Кому рассылать данные клиент решает просто пробегая по вектору игроков локации.
Твоя реализация:
Клиент - Ну че там, есть нового чо?
Сервер - Не-а, нету :-(
Клиент - Ну че там, есть нового чо?
Сервер - Не-а, нету :-(
Клиент - Ну че там, есть нового чо?
Сервер - Да, А двинулся в Б, Б замочил Ц.
Клиент - Ок, понял.
Клиент - Ну че там, есть нового чо?
Для реалтаймовой игрушки не особо скоростной подход получается даже на пальцах.
|
| | | | | | | | |
Я уже ничего не понимаю, споришь ты со мной или соглашаешся... 01.11.08 13:37
Автор: PS <PS> Статус: Elderman
|
> > Повторю еще раз: пол миллиона человек в online -
> > высчитывать что для каждого из них актуально, а что
> нет -
> > физически не возможно.
> По-моему вполне возможно, главное грамотно локализовать
> данные (кластеризовать игроков или не знаю как правильнее
> сказать). Грубо говоря у тебя есть много локаций, и когда
> кто-то совершает некое действие, оно рассылается всем в
> пределах данной локации. Где сложности? А вот механизм с
> запрашиванием новых данных от сервера мне выглядит более
> трудоемким, причем ничем не упрощающим реализацию.
Я об этом и говорю - действие рассылается всем (в пределах локации, зоны, класстера - это все оптимизация траффика).
Спор тут затевается о другом.
Мое утверждение: front не должен следить за ПРАВИЛАМИ.
Утверждение противоположной стороны: front должен рассылать данные только после необходимых проверок в их валидности.
P.S. Опять же оговорюсь, что следует иметь ввиду масштаб игры.
|
| | | | | | | | |
Можно и без подтверждения. Сам сетевой протокол... 31.10.08 16:01
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 31.10.08 16:03 Количество правок: 3
|
> Мне моя реализация видится так:
> Сервер - Игрок A двинулся в сектор Б.
> Клиент - Ок, понял.
> Сервер - Игрое Б замочил игрока Ц.
> Клиент - Ок, понял.
Можно и без подтверждения. Сам сетевой протокол подразумевает гарантированность доставки.
Сервер - Игрок A двинулся в сектор Б.
Сервер - Игрое Б замочил игрока Ц.
> Твоя реализация:
> Клиент - Ну че там, есть нового чо?
> Сервер - Не-а, нету :-(
> Клиент - Ну че там, есть нового чо?
> Сервер - Не-а, нету :-(
> Клиент - Ну че там, есть нового чо?
> Сервер - Да, А двинулся в Б, Б замочил Ц.
> Клиент - Ок, понял.
> Клиент - Ну че там, есть нового чо?
А здесь без запросов нельзя. Хотя зачем они нужны, если на них все равно идет ответ "Не-а, нету :-(". Зачем пустой инфой каналы забивать. Ее же все равно еще и обрабатывать надо. Хочется своевременно получать инфу - надо пулить с бешенной частотой, но своевременность получения "по прерыванию" будет всегда своевременнее чем "по запросу".
|
| | | |
Лучше взять простенькую open source online multiplayer игру... 29.10.08 20:12
Автор: amirul <Serge> Статус: The Elderman
|
> Как конкретно реализована каждая игра - можно разобраться
> по траффику.
Лучше взять простенькую open source online multiplayer игру и смотреть как это сделано у них. Первое, что пришло в голову:
http://teeworlds.com/
Очень хорошо модуляризовано, во всяком случае моды клепать довольно легко (сам я делал инстагиб, менял характеристики респавна и пр.), так что найти реализацию клиент-серверного протокола не составит труда. Игра довольно динамична, так что требования к протоколу жесткие.
|
| | | |
"В отличие от web, online игра должна реагировать очень... 29.10.08 18:25
Автор: Vedrus <Serokhvostov Anton> Статус: Member
|
"В отличие от web, online игра должна реагировать очень быстро. А пока клиент прочухается, пока отошлет запрос, пока сервер отработает пол миллиона запросов - ты, как игрок, уснешь перед монитором.
Как вариант: избавится от логики запросов. "
Может есть, что почитать по этому поводу? Я так понял, нужно игнорируя Apache свой сервер писать и ставить в идеале?
|
|
А что тут еще можно придумать... Можно еще учитывать вектор... 29.10.08 17:03
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> То, что придумал я – это несколько раз в секунду опрашивать
> сервер о текущем состоянии сцены и на основе полученных
А что тут еще можно придумать... Можно еще учитывать вектор скорости - величину и направление. Время так же надо синхронизировать. Это чтоб побороть латентность канала.
> данных прорисовывать сцену. Но такой вариант трафика и
> других ресурсов очень много жрать будет.
Какой трафик, какие ресурсы, десяток байт на опрос, десять опросов в секунду, сотня байт в секунду, килобит в секунду, да хоть в десять раз больше - десять килобит, такой трафик любой модем на коммутируемых линиях потянет.
|
| |
Ну оптимизация всё равно не повредит. 10 байт это на один движущийся объект. А если их сотня в одной сцене движется. Да и сервер наверно загудит, если 10 раз в секунду запросы к БД отсылать. Или я не прав? 29.10.08 17:50
Автор: Vedrus <Serokhvostov Anton> Статус: Member
Отредактировано 29.10.08 18:03 Количество правок: 1
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
