Синзронизация на AS3 - Страница 6

undefined · 24.05.2017, 03:14

Цитата:

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

Так если сервер таки должен уметь считать симуляцию сам,почему бы ему это не делать в realtime без запарок что что-то там может разойтись.

Цитата:

подсовывая кривые инпуты или уводя свою симуляцию к заведомо выигрышному результату, например увеличивая скорость своих юнитов. представим что одна сторона говорит что она выиграла, а другая говорит что она и непонятно кто прав и кому выдавать награду/репутацию

скорость юнитов - фиксированная хар-ка этих юнитов как клиент может на нее влиять?

caseyryan · 24.05.2017, 06:14

Цитата:

то он на основании этих инпутов симулирует всю игру и решает кто прав, а кто читер, и наказывает их.

Ну, эта задача, мягко говоря, очень трудновыполнимая. Собирание абсолютно всех инпутов на протяжении всей игры, каждое перемещение, каждый выстрел, каждый бросок гранаты и т.д., а потом повторно прогонять и смотреть где и что пошло не так... Что-то я тоже не представляю как это может помочь в решении спорной ситуации. Кинул игрок поддельный инпут, сервер его записал у себя, потом воспроизвел, получил ту же картину. Всем хорошо, читеров нет, бессмысленная двойная работа выполнена) Все эти проверки можно делать прямо в процессе игры.
Плюс к тому, довольно проблематично собирать все это и симулировать, если это не какие-нибудь нарды, а, скажем, World Of Wartanks.
Звучит утопически

Цитата:

Так если сервер таки должен уметь считать симуляцию сам,почему бы ему это не делать в realtime без запарок что что-то там может разойтись.

Отчасти соглашусь. Но по опыту могу сказать, что это не всегда возможно, некоторые расхождения неизбежны. Вот пример ситуации, которая была у меня: есть скорострельный пулемет. Игрок берет его и начинает стрелять. Пулемет совершает по 15 - 20 выстрелов в секунду. Вопрос: Как отправлять эти выстрелы серверу? Первое, что попытался сделать я - это решение "в лоб" создать короткий пакет, который содержал, позицию солдата игрока и направление выстрела. Стал слать эти пакеты для каждого выстрела. И быстро понял, что вариант этот очень плохой. Трафика сразу копится столько, что сеть начинает тормозить, а сервер не успевает принимать и обрабатывать все эти пакеты. Помножь все это хотя бы на несколько десятков игроков, я не говорю о сотнях, и получишь Denial of Service на своем серваке.
Второе решение было - послать направление выстрела и положение игрока при начале стрельбы, а так же количество патронов, которое есть на клиенте, а потом событие завершения стрельбы, так же с количеством патронов. Это дало некоторые преимущества: сеть перестала забиваться и сервер смог без проблем обрабатывать стрельбу и считать возможные попадания без особых напрягов. Но тут же всплыли и недостатки:
1) Так как сервер теперь сам считал расход патронов, а клиент сам, то появились рассинхроны. Я решил, что можно сделать допущение, если расхождение в контрольных суммах патронов будет + / - 5, то считать что клиент не читер и можно верить тому количеству, которое пришло с него. А если больше, то сервер шлет клиенту апдейт и количество патронов у него корректируется.
Казалось бы, все круто, проблема решена. Но не тут то было. Ситуации со сбоями в сети и тормозами железа никто не отменял. Стали всплывать ситации, когда событие завершения стерльбы просто где-то терялось и сервер не прекращал стрельбу, пока не кончались патроны, а клиент даже не подозревал об этом и бегал где-то в другом месте локации. Пришлось делать каждую секунду дополнительную проверку со стороны сервера. Он слал клиенту доп. сообщение heart_beat и если не получал ответа, то прекращал стрельбу и на всякий случай слал клиенту апдейт с текущим состоянием его боепрпасов.
Это улучшило положение, но проблему рассинхронов не решило на 100%.
Так что для некоторых видов игр, (особенно с активной движухой) никак нельзя быть уверенным, что всё на 100% синхронизировано. А значит и нельзя на 100% избежать читеров

undefined · 24.05.2017, 08:24

caseyryan,nooob отстаивает позицию что для стратегий с небольшим числом участников "тонкий" сервер незнающий ситуацию на поле, дает некие преимущества. Т.е. отслеживать каждую пульку не требуется. Собственно основной тезис почему лучше на сервере стейт не держать: из-за разных реализаций арифметики на клиенте и сервере неизбежно будут накапливаться расхождения между серверной симуляцией и клиентской.

caseyryan · 24.05.2017, 11:07

Цитата:

Собственно основной тезис почему лучше на сервере стейт не держать: из-за разных реализаций арифметики на клиенте и сервере неизбежно будут накапливаться расхождения между серверной симуляцией и клиентской.

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

undefined · 24.05.2017, 13:28

так клиент как ни крути тоже должен считать симуляцию,с чего сервер с этим не справится?

Nooob · 25.05.2017, 00:41

Цитата:

Сообщение от undefined

скорость юнитов - фиксированная хар-ка этих юнитов как клиент может на нее влиять?

Я имею ввиду игры типа стратегий, где один инпут отправить юнитов туда то, а логика юнита в смуляторе. стало быть параметры юнита храняться на клиенте (в конфигах, в байткоде, в памяти) которые не сложно подменить.

Цитата:

Сообщение от caseyryan

Если сервер будет тормозить, от этого будут страдать все. Я лично считаю, что пусть лучше будет больший процент читеров, но сервер будет летать, чем небольшой процент читеров и тормозящий сервер.

Да все верно, я тоже так считаю. но думаю что все же есть схема которая позволит выявлять читеров

undefined · 25.05.2017, 06:42

Цитата:

Я имею ввиду игры типа стратегий, где один инпут отправить юнитов туда то, а логика юнита в смуляторе. стало быть параметры юнита храняться на клиенте (в конфигах, в байткоде, в памяти) которые не сложно подменить.

Если уж на то пошло клиент вообще может только притворяться что что-то считает, а в конце сказать что я победил

caseyryan · 25.05.2017, 07:49

Цитата:

Сообщение от undefined

так клиент как ни крути тоже должен считать симуляцию,с чего сервер с этим не справится?

Справится, если речь идет об одном, ну может десятке одновременных симуляций (если речь идет об одном сервере, а не о целом облаке с огромной вычислительной мощностью). Если симуляций много, он начнет безбожно тормозить. И, разумеется это коснется всех игровых сессий, а не каких-то отдельных.
Я делал симуляцию боя на сервере по упрощенной схеме. Если на клиенте, скажем, вся физика считалась с учетом форм объектов (например при полете пули), то на сервере это были просто круги, и пересечения считались очень приближенно, по радиусу, то есть все сводилось к расчету вроде "а мог ли он вообще хотя бы теоритически попасть туда-то, оттуда-то". И даже такая схема начинала тормозить на дедике с двумя 4х ядерными процессорами Intel Xeon по 3.9 и 16Гб оперативки уже при 30 - 40 одновременных боях по 16 игроков в каждом. Конечно, многое еще зависит от реализации самой программы. Не думаю, что у меня было все очень круто реализовано) Но тем не менее, это все равно большая нагрузка на сервер. Я придерживаюсь позиции, что в подобных играх максимально возможное количество логики нужно передавать клиентам. На сервере считать только самые критические моменты.

Цитата:

Если уж на то пошло клиент вообще может только притворяться что что-то считает, а в конце сказать что я победил

В некоторых видах игр может. А что будет, если игрок явно видит, что он убил всех солдат противника, а ему вылетает сообщение "ты проиграл"? Просто потому, что на сервере происходило что-то другое

undefined · 25.05.2017, 12:19

на сервере ничего не происходит т.к. он вообще не в курсе что в игре творится.

Nooob · 25.05.2017, 23:20

Цитата:

Сообщение от undefined

Если уж на то пошло клиент вообще может только притворяться что что-то считает, а в конце сказать что я победил

Я как то размышлял по поводу такой схемы: сервер кидает рандом с определенной вероятностью победы (к прмеру кто больше задонатил/потратил времени тот вероятнее выиграет), и клиенты запускают бой с колоссальной детализацией, с кучей юнитов, эффектами, магией, физикой и тд. и есть какая-то внешняя сила которая влияет на перевес силы к примеру катапульты вне карты. каждое использование чего значимого юзером то спела/магии/атомная бомба сервер опять подкидывает рандом где вероятность победы увеличена. и симуляция выравнивается для нового результата. только представь как оперировать вероятностями круто имея на руках аналитику, не проходят люди сюжетку, подкрутил коэффициенты, не платят опять подкрутил, уменьшился конверт трафика снова подкрутил. лепота)
но проблема такой схемы что она не может стать e-sport игрой, где действия пользователя определенно имеют вычисляемое/предположительное/сбалансированное последствие для остальных. и чем больше деталей симуляции (SimCity например) тем глубже геймплей