Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / насколько нужно углубляться в синхронизацию клиента с сервером?

насколько нужно углубляться в синхронизацию клиента с сервером?

Поделиться
is.ivanПользовательwww26 янв. 201720:08#0
В проектировании игры дошел до момента, на котором одно решение разбивает линейную архитектуру на два пути, а какой именно выбрать я не знаю и поэтому решил посоветоваться с Вами прежде чем сделать окончательный выбор. Дело вот в чем.. Есть игрушка, которая просчитывает модель полностью на сервере. Это моя первая мультиплеерная игра и поэтому я как и подобает пошел и прочел большую статью, в которой говорилось что для более реалистичной синхронизации нужно дублировать логику на клиенте и даже показывать пользователю немного прошлое время и естественно задавать uid для обновления чтобы если что то подгонять состояние.

И вот значит представьте ситуацию с суперспособностями, которые ограничены по времени использования и восстановления и игру с апдейтом, думаю, раз-два в секунду.
И вопрос - достаточно ли будет передавать только флаг, что способность используется или нет или же нужно передавать время которое эта способность активна?
Я очень туго представляю все это, но думаю что люди которые уже собаку съели на этом смогут оценить в уме и подсказать. Спасибо.

clcПостоялецwww26 янв. 201721:55#1
то, что ты читал - это для жёсткого реалтайма. Опиши задачу и среду, а не свои размышления.
ever123Пользовательwww27 янв. 20178:32#2
извиняюсь, я пока не делал мультиплеер......, но вопрос интересный и хочется поучаствовать в обсуждении на эту тему)) вот в нативной unity сети, а также в unity photon network логика обсчитывается на одном из клиентов (один из игроков в комнате становится мастер-клиентом, если он выходит, то мастером становится другой), через сервер идёт межклиентский трафик, это и так нагружает сервер, т.е. считать логику на сервере очень дорого. Какое API/фрэймворк вы используете, сначала надо определиться/разобраться с возможностями API, если никакого API нет, то лучше поискать какую-нибудь библиотеку для мультиплеера, должно быть много реализаций. Делать свой велосипед не просто долго, но и опасно тем, что на каком то этапе разработка может застрять в силу ограничений, которых раньше не знали. По сабжу имхо: делать очередь всех игровых состояний и растягивать её незаметно для пользователей при провалах связи, это как то слишком сложно, всёравно выйдет конфуз, если время между синхронизациями превысило допустимый порог, может показать на паузе "ожидание сервера" и откатить критичные игровые состояния назад из некоего back-буфера. т.е. уважаемые игроки, произошёл косяк, так, наверное, меньше раздражения будет, чем когда каждый играет в свою игру, где он выигрывал, а потом почему то резко проиграл
MANABПостоялецwww27 янв. 201710:34#3
is.ivan
Я бы делал апдейты чаще, раз 10-20 в секунду, но если игра неспешная, то можно и 1-2.
Насчет того что передавать - сервер ведь ваш знает, когда отсылает данные, какая суперспособность используется, сколько еще она будет активна, сколько после этого неактивна - эти данные и передавайте.
Клиент должен лишь учитывать задержку на передачу данных от сервера и к нему, чтобы игрок мог использовать свои абилки настолько рано, насколько это действительно возможно. А логика при этом так и останется параллельной. Просто передавайте все необходимые данные, чтобы эта логика работала синхоронно.
ZabПостоялецwww27 янв. 201711:33#4
Если основное моделирование централизованное, на сервере, синхронизация времени не очень важна. Если же моделирование распределено по клиентам, как раньше делали в шутерах, надо синхронизировать очень точно и постоянно контролировать, что оно не разошлось. Экстраполяцию иначе как делать? Клиент не знает, где сейчас находится объект, который моделирует не он. Ему было сообщение, что он находился где-то на какой-то момент в прошлом. Чтобы не было скачков, надо экстраполировать эту информацию в настоящее. Для этого ставятся временные метки в большинстве сетевых сообщений.
При централизованном моделировании иногда предполагают, что лаг постоянный, делают на него статическую поправку не пересылая время съема показаний. При распределенном моделировании так сделать не выйдет, объекты фиксируют свое состояние в разное время.

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

Правка: 27 янв. 2017 11:40

is.ivanПользовательwww27 янв. 201712:06#5
clc
> clc
Задачу я уже описал - выполнение суперспособности, а среда, если я Вас правильно понял, nodejs.
Я получил ответы - делай так, не делай так, ты дурак. Я думал что существуют устоявшиеся мнения
и решения, но видно ошибался и ответ придется искать на собственном опыте. Спасибо всем.
ПорядокПостоялецwww27 янв. 201714:17#6
is.ivan
> «»
это как если бы ты описал игру овервотч как "ребят, мне нужно синхронизировать способности, достаточно будет раз-2 в секунду проверять не использовалась ли она?". точно так же причём можно описать idle игру, в которой единственным твоим действием есть нажатие одной из двух "способностей".
для хорошего совета надо хорошо написать вопрос. удачи.

^ было слишком много мыслей в голове, построить правильные предложения не получилось, переписывать лень, надеюсь поймёшь.

PANDAПостоялецwww27 янв. 201715:19#7
is.ivan
Устоявшегося ответа нет, так как зависит от геймплея.
is.ivanПользовательwww27 янв. 201716:05#8
Порядок
Ну вот, опять проецирование настроения на человека! Мне не лень объяснять, я просто не знаю как это сделать.
Я делаю игру в которой одновременно играет много человек. Обновление я не думаю что нужно производить чаще чем
два раза в секунду. Но я не знаю может ли за эти полсекунды произойти что-то ТАКОЕ что сделает применение способностей
неестественными. Но скорее всего человек за полсекунды даже и не заметит разницы. Скорее всего так и есть, да и вчера казалось
что вопрос не лишен смысла. А сегодня уже кажется что все очевидно.
DekaSoftПостоялецwww27 янв. 201717:05#9
is.ivan
Никто ничего не проецировал. Порядок сказал, что ЕМУ лень объяснять подробнее. Просто из твоего описания игры не до конца понятно, какой вариант тебе подойдет больше, а не "ты дурак". Че сразу обиженку включать-то?
Sh.Tac.Постоялецwww28 янв. 20172:24#10
is.ivan
> игру с апдейтом, думаю, раз-два в секунду
событийная модель лучше, есть чего, взял и отправил, зачем ждать полсекунды?

> или же нужно передавать время которое эта способность активна?
с сервера нужно передавать два события, начало и окончание, причём слегка заранее, с отметками времени собственно начала/окончания в будущем
второе событие позволяет гибко настраивать длительность на ходу, например если спелл можно сбить другим

на клиенте который заказывает применение способности, время ожидания нужно "замазать" эффектом/анимацией кастования

ever123Пользовательwww28 янв. 201710:20#11
событийная модель звучит здраво, но сразу же захочется добавить событие "пинг", чтобы знать, что клиенты онлайн. и т.д. в итоге будет безконтрольное забитие канала чаще чем нужно, или безтолковые события будут забивать критичные, нужна ещё приоритезация тогда. На этапах отладки/ревью кода алгоритм от первоначального видоизменится до неузнаваемости)) Разве не полезнее было бы обсудить особенности конкретного api, эти генеральные идеи всё равно, что "хочу добавить мультиплеер"

Правка: 28 янв. 2017 10:23

Sh.Tac.Постоялецwww29 янв. 20170:17#12
ever123
> безконтрольное забитие канала чаще чем нужно
основной трафик это исходящий от сервера, сервер авторитарный разумеется, и сам осуществляет контроль, вплоть до отключения спамящего клиента

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

2001—2017 © GameDev.ru — Разработка игр