Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Толстый/тонкий сервер. Синхронизация состояние мира. Какие минусы видите в такой реализации? (11 стр)

Толстый/тонкий сервер. Синхронизация состояние мира. Какие минусы видите в такой реализации? (11 стр)

Поделиться
Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 4 ... 10 11 12 Следующая

i2um1Постоялецwww6 окт. 20163:30#150
tac
> Я не понимаю, что вы называете логами, поэтому не могу это прокомментировать.
Я исправил первый пункт.

tac
> разбирает и анализирует состояние объекта.
Как определить, что состояние объекта следует заблокировать не анализируя его? Как заблокировать состояние объекта не разбирая его? Как обновить состояние объекта разбирая его?

tac
> да, предложения?
Система предсказания и/или специальный вид сообщений от сервера клиенту о успешном выполнении действия. Есть еще варианты.

tac
> иначе это станет авторитарный сервер по определению
Эх, но еще вот-вот. Целость-то уже контролирует (правда пока не понятно как) и все данные через него ходят.

Правка: 6 окт. 2016 3:33

tacПостоялецwww6 окт. 20164:11#151
i2um1
> Как определить, что состояние объекта следует заблокировать не анализируя его?
> Как заблокировать состояние объекта не разбирая его? Как обновить состояние
> объекта разбирая его?

а где вы видели, что в указаном примере я его разбирал, я имел лишь идентификатор объекта и отметку времени изменения состояния. Блокируется доступ после изменения безусловно, вопрос в том когда он разблокируется. Самый простой вариант он может разблокироваться, через 5 сек после блокировки (т.е. перед отправкой в долговременное хранилище). Или хотим точнее, тогда оцениваем время за которое желающий сменить состояние способен получить уведомление от сервера, и понять он прислал понимая ситуацию или нет, если нет игнорируем его. Если да, разблокируем и меняем состояние (бизнес-логика клиента разрешила изменения). И совершенно не надо знать, что стало с этим объектом серверу.

Правка: 6 окт. 2016 5:10

tacПостоялецwww6 окт. 20164:14#152
i2um1
> Отдает только нужную информацию, запрашиваемую клиентом, который как-то ее
> узнает, не зная весь мир. Однако по непонятному критерию клиент определяет,
> когда ему вдруг надо запросить состояние всего мира.

Состояние всего мира ему знать надо только единожды, когда он ВПЕРВЫЕ зашел в игру. А потом он помнит состояние на момент когда он отключился от сети, и заходя снова с того времени просит изменения.

Правка: 6 окт. 2016 4:15

tacПостоялецwww6 окт. 20164:19#153
i2um1
> Система предсказания
Вообще не вариант, предсказать кто первый схватит камень невозможно. Конечно, я в курсе, что в задачах ИИ есть и такая - определяет как играть с человеком в камень, ножницы, бумага, исходя из статистики, но тут мы чаще имеем дело не с человеком, а с недетерминированной природой ) и не настолько это дешевая вещь, чтобы в доли секунд что-то предсказывать

> специальный вид сообщений от сервера клиенту о успешном выполнении действия.
А как сервер то это определит? Типа "молодец, ты взял этот камень", а через пару сек "А не слушай, все таки это был не ты" ))

(в моем решении, хоть мне пытались приписать этот же вариант, происходит по другому. Сервер просто делает так - "стопаньки, ты еще не мог посмотреть что стало с этим объектом, поэтому тебе игнор. А тому кто до этого изменил - подтверждение - все предыдущие сообщение по этому объекту от клиентов - фуфел, не верь. " )

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

>Есть еще варианты.
???

----------------------------------------------

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

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

Правка: 6 окт. 2016 5:43

tacПостоялецwww8 окт. 20162:06#154
итак видимо разобрались и остался лишь один вопрос от хакеров )

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

Ну и конечно, хакеру надо умудрится декомпилировать клиента, расшифровать сообщения посылаемые серверу, понять их формат, подменить их осмысленно - и при первой же кросспроверки получить автобан.

upd.
> Клиент никак не может понять чье состояние он просчитывает
ну разве что по координатам ... ну даже если случайно, он сейчас будет считать ближайшего монстра, то через некоторое время кого-то вдалеке, кого и не видно.

-----------------------------------

И еще мне даже стало интересно, если те кто так бояться что клиент хакнут, вы реально рассчитываете столкновение персонажа с коллайдерами на сервере? да, ладно ;)

Правка: 8 окт. 2016 2:42

MrShoorУчастникwww8 окт. 20163:02#155
tac
> Всего лишь подловить его, пару раз для сверки результатов попросив еще кого
> нибудь посчитать.
Та система, что ты описал - ничем не лучше. Код будет архисложный, сомневаюсь что ты напишешь подобное.

tac
> и при первой же кросспроверки получить автобан.
Автобан - борьба с последствиями. Любая незначительная бага в этой сложной системе - автобан чесному пользователю. Примеров полно. Вон тот же LA2.

tac
> вы реально рассчитываете столкновение персонажа с коллайдерами на сервере? да, ладно ;)
Да. Это работает быстро, потому что в 99% случаев персонаж - это одна капсула, и в 99% случаев - эта капсула взаимодействует со статик мешами мира. А частицы разлетающегося ящика/бочки - на геймплей никакого влияния не оказывают, считаются на каждом клиенте отдельно, и вообще не синхронизируются.
Конечно если геймплей основан исключительно на физике - то сервер может и не потянуть, но таких игр я пока не встречал.

tacПостоялецwww8 окт. 20163:23#156
MrShoor
> Да. Это работает быстро

у тебя есть такая игра? можно в неё сыграть?

MrShoor
> Та система, что ты описал - ничем не лучше. Код будет архисложный, сомневаюсь
> что ты напишешь подобное.

Не сложнее полновластного сервера. Главное мы пришли к тому, что альтернатива есть и она совсем не бесперспективная.

Правка: 8 окт. 2016 3:24

MrShoorУчастникwww8 окт. 20164:43#157
tac
> у тебя есть такая игра? можно в неё сыграть?
Есть, но она пока в разработке, и сыровата. Создам тему на форуме - когда будет более менее готовый прототип. Тогда и сыграешь. По крайней мере по сети у меня все отлично бегает уже.

tac
> Не сложнее полновластного сервера.
Ну ну.

tacПостоялецwww14 окт. 201612:26#158
MrShoor
> Автобан - борьба с последствиями. Любая незначительная бага в этой сложной
> системе - автобан чесному пользователю.

Меня осенило :). Все действительно проще, чем кажется. Надо просто продолжать думать в духе толстых клиентов и в этом вопросе. Пусть каждый клиент время от времени проверяет основные параметры своих оппонентов из сети. И тогда просто каждый игрок, который играет честно (его клиент не взломан) - ему сам клиент скажет - что вот этот товарищ из сети читер (и оповестит о достижениях читера всех), и уж каждый сам решит играть ли ему с читером. Если нет, его просто исключат из общей комнаты.

А проверять достаточно - параметры перса и появление вещей из воздуха. Ну и все по сути.

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

Правка: 14 окт. 2016 13:20

SlavaLiaПостоялецwww14 окт. 201615:14#159
tac
> ему сам клиент скажет - что вот этот товарищ из сети читер (и оповестит о
> достижениях читера всех)
Эм... Вы своими руками даёте  читеру инструмент банить неугодных ему игроков, просто разослав сообщение?
По логике, такой чит сам собой будет напрашиваться.

RavagerПостоялецwww14 окт. 201617:28#160
tac
> Но такое решение имеет ряд недостатков - думаю вы сами их назовете. Но главное
> - это необходимость иметь на сервере базу данных, а соответственно нагрузка на
> сервер.
>
> 2. Тонкий сервер
>
> Сервер не имеет базу данных, но тогда ему необходимо хранить весь лог сообщений
> от клиентов, чтобы можно было восстановить состояние мира на определенный
> момент времени.
есть еще 3 вариант: взять no sql in memory с WAL например Tarantool и начать жить.
а если еще открыть для себя асинхронное программирование, то можно жить еще веселее
tac
> И вот вам решение. Представьте, что ваш клиент просчитывает состояния вместо
> сервера, но сервер распределяет между клиентами онлайн состояния каких объектов
> просчитывать тому или иному клиенту (по сути работает в режиме распределенных
> вычислений).
т.е. я в этой схеме могу сделать пинг 200мс и наказать ни в чем неповинных игроков, чьи вычисления идут на мою машину?

Правка: 14 окт. 2016 17:44

tacПостоялецwww14 окт. 201617:43#161
SlavaLia
> Вы своими руками даёте  читеру инструмент банить неугодных ему игроков, просто
> разослав сообщение?
это конечно если верить одному клиенту, но это подтвердят все кто был онлайн /и беда если будеи хоть пару кто честный ;)/, и не банить а перестать с такими играть

Правка: 14 окт. 2016 17:45

tacПостоялецwww14 окт. 201617:47#162
Ravager
> наказать ни в чем неповинных игроков, чьи вычисления идут на мою машину?
каким образом?
tacПостоялецwww14 окт. 201617:49#163
Ravager
> no sql
чего вам дался этот бред )) файлами пользуйтесь и вот вам no sql ))
RavagerПостоялецwww14 окт. 201618:05#164
tac
> каким образом?
потому что если ты будешь ожидать подтверждение от сервера своих действий то время ожидания ответа у тебя будет равно = RTT1 + RTT2, где RTT1, RTT2 это время прохождения пакета туда-обратно от тебя(другого клиента) до сервера. т.е. наличие 1 игрока с лагом порождает минимум 2
если ты не ждешь подтверждений то у тебя будет жуткий рассинхрон, потому что картинка на компе у всех разная: у себя на компе ты перепрыгнул через забор а у соседа Васи ты еще перед ним стоишь. а у меня на компе сеть не очень, я тебя вижу на одном месте. кому верить, кто читерит?

>> чего вам дался этот бред )) файлами пользуйтесь и вот вам no sql ))
точно, расскажите об этом на highload. и чего это все не догадались до такого

Правка: 14 окт. 2016 18:07

Страницы: 1 2 3 4 ... 10 11 12 Следующая

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

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