if (blind) {
// код, отвечающий за закрашивание экрана белым
}
OpenSource сетевая игра, как избежать проблем с клиентской частью?
Подскажите, пожалуйста, как решить такую вот проблему:
разрабатывается игра (opensource проект, некоммерческий, без денежного оборота), ориентированная ИСКЛЮЧИТЕЛЬНО на мультиплеер;
как избежать жульничества со стороны пользователя (ведь он может редактировать и перекомпилировать программу-клиент) ?
разрабатывается игра (opensource проект, некоммерческий, без денежного оборота), ориентированная ИСКЛЮЧИТЕЛЬНО на мультиплеер;
как избежать жульничества со стороны пользователя (ведь он может редактировать и перекомпилировать программу-клиент) ?
очень просто. все расчеты, связаные с игровыми деньгами, экспой, местоположением игрока, урон и т.д. производятся на сервере.
т.е. например игрок нашел мешок золота. клиент не добавляет золото сразу в инвентарь. сначала посылается запрос на сервак, сервер проверяет действительно ли там лежит мешок золота (или другие твои расчеты) и только если все правильно добавляет золото в инвентарь игрока, который хранится на СЕРВЕРЕ. клиент только рисует инвентарь, а не хранит его.
роль клиента, это графика, посылать действия игрока на сервер, настройки и т.д.
т.е. например игрок нашел мешок золота. клиент не добавляет золото сразу в инвентарь. сначала посылается запрос на сервак, сервер проверяет действительно ли там лежит мешок золота (или другие твои расчеты) и только если все правильно добавляет золото в инвентарь игрока, который хранится на СЕРВЕРЕ. клиент только рисует инвентарь, а не хранит его.
роль клиента, это графика, посылать действия игрока на сервер, настройки и т.д.
Цитата: Free Thinker
очень просто. все расчеты, связаные с игровыми деньгами, экспой, местоположением игрока, урон и т.д. производятся на сервере.
т.е. например игрок нашел мешок золота. клиент не добавляет золото сразу в инвентарь. сначала посылается запрос на сервак, сервер проверяет действительно ли там лежит мешок золота (или другие твои расчеты) и только если все правильно добавляет золото в инвентарь игрока, который хранится на СЕРВЕРЕ. клиент только рисует инвентарь, а не хранит его.
роль клиента, это графика, посылать действия игрока на сервер, настройки и т.д.
т.е. например игрок нашел мешок золота. клиент не добавляет золото сразу в инвентарь. сначала посылается запрос на сервак, сервер проверяет действительно ли там лежит мешок золота (или другие твои расчеты) и только если все правильно добавляет золото в инвентарь игрока, который хранится на СЕРВЕРЕ. клиент только рисует инвентарь, а не хранит его.
роль клиента, это графика, посылать действия игрока на сервер, настройки и т.д.
C точки зрения безопасности это правильно, но тогда получится слишком большая нагрузка на сервер + может резко вырасти трафик.
Вряд ли такое понравиться потенциальным пользователям.
Думаю, что тонкие клиенты для серьезных игр не катят.
Если есть необходимость выложить исходники клиента (хотя лично я бы выбрал какую -нибудь бесплатную лицензию без открытия сорса), то можно сделать финт ушами. Выложи исходники, но сделай, некий интегральный хэш от имеющихся ресурсов/прочих характеристик клиента, и храни первоначальный (для правильного "исходного" исходника) как зеницу ока. Потом при каждом коннекте сервер запрашивает у клиента параметры, и по ним считает его хэш - и очень трудно будет сделать, чтобы у исправленного исходника он совпал с истинным.
Цитата: Free Thinker
очень просто. <...> роль клиента, это графика, посылать действия игрока на сервер, настройки и т.д.
Вот в этом тоже есть проблема: в игре есть реализация светошумовых гранат. Игрок может попросту вырезать из клиента код, отвечающий за "ослепление".
Цитата: Zorkus
<...>Выложи исходники, но сделай, некий интегральный хэш от имеющихся ресурсов/прочих характеристик клиента<...>
Спасибо, попробую.
Цитата: EASTPrince
Вот в этом тоже есть проблема: в игре есть реализация светошумовых гранат. Игрок может попросту вырезать из клиента код, отвечающий за "ослепление".
Объясни, зачем выкладывать код?? Можно сделать клиента бесплатным, но без открытия кода. От многих проблем избавашься.
Цитата:
Потом при каждом коннекте сервер запрашивает у клиента параметры, и по ним считает его хэш
Вот и именно, что у клиента запрашивает. А клиент не будь дурак, вернет ему изначальные параметры.
Подытожим:
:) Хэш не прокатит, можно обмануть;
:) Контролировать каждое действие серваком - огромный траффик;
Что делать?
А) открыть бОльшую часть кода и создать клиент-контроллер с закрытым кодом?
Б) вообще не открывать код?
P.S. Подскажите бесплатный компилятор С++ для FreeBSD. gcc?
:) Хэш не прокатит, можно обмануть;
:) Контролировать каждое действие серваком - огромный траффик;
Что делать?
А) открыть бОльшую часть кода и создать клиент-контроллер с закрытым кодом?
Б) вообще не открывать код?
P.S. Подскажите бесплатный компилятор С++ для FreeBSD. gcc?
Цитата: vasa_c
Вот и именно, что у клиента запрашивает. А клиент не будь дурак, вернет ему изначальные параметры.
Я имею в виду - запрашивает некоторый набор параметров программы, и от них считает хэш, причем клиент не знает, какие именно параметры запрашивает сервер. Клиент не знает -
1) Какие параметры у него запросит сервер (причем он может запрашивать разные параметры в разные коннекты).
2) Клиент не знает, как именно сервер считает хэш (хотя это конечно ненадежно, скрытие алгоритма, и противоречит принципу Керхгоффса:), но все же лишний слой защиты).
2) Клиент не знает, чему равен контрольный хэш (или из набор, в случае запроса переменных параметров).
Так что не все так плохо;).
[quote=EASTPrince]
Подытожим:
Хэш не прокатит, можно обмануть;
Контролировать каждое действие серваком - огромный траффик;
Что делать?
А) открыть бОльшую часть кода и создать клиент-контроллер с закрытым кодом?
Б) вообще не открывать код?[/quote]
Хэш - это лучшее, что мне приходит в голову, если надо открыть код.
Контолировать действия серваком это не только огромный и ненужный траффик - это еще и дикая нагрузка на сервер и страшные тормоза у клиета.
Лично я бы не открывал код вообще. Потому что если ты оставишь один класс закрытым, то его более реально дизассемблировать будет.
Цитата: Zorkus
Я имею в виду - запрашивает некоторый набор параметров программы, и от них считает хэш, причем клиент не знает, какие именно параметры запрашивает сервер. Клиент не знает -
1) Какие параметры у него запросит сервер (причем он может запрашивать разные параметры в разные коннекты).
2) Клиент не знает, как именно сервер считает хэш (хотя это конечно ненадежно, скрытие алгоритма, и противоречит принципу Керхгоффса:), но все же лишний слой защиты).
2) Клиент не знает, чему равен контрольный хэш (или из набор, в случае запроса переменных параметров).
Так что не все так плохо;).
Хэш - это лучшее, что мне приходит в голову, если надо открыть код.
Контолировать действия серваком это не только огромный и ненужный траффик - это еще и дикая нагрузка на сервер и страшные тормоза у клиета.
Лично я бы не открывал код вообще. Потому что если ты оставишь один класс закрытым, то его более реально дизассемблировать будет.
1) Какие параметры у него запросит сервер (причем он может запрашивать разные параметры в разные коннекты).
2) Клиент не знает, как именно сервер считает хэш (хотя это конечно ненадежно, скрытие алгоритма, и противоречит принципу Керхгоффса:), но все же лишний слой защиты).
2) Клиент не знает, чему равен контрольный хэш (или из набор, в случае запроса переменных параметров).
Так что не все так плохо;).
Хэш - это лучшее, что мне приходит в голову, если надо открыть код.
Контолировать действия серваком это не только огромный и ненужный траффик - это еще и дикая нагрузка на сервер и страшные тормоза у клиета.
Лично я бы не открывал код вообще. Потому что если ты оставишь один класс закрытым, то его более реально дизассемблировать будет.
проверка клиентами-соседями в общем случае и проверка сервером в частных случаях . так как на обычно в игре довольно много народу , то нагрузка на сервак снизится в несколько раз . трафик на клиенте конешно увеличится , но это не критично потому что всего на несколько процентов .
А это самая большая проблема вашей игры?
Игра уже написана?
Игра уже написана?
Цитата: koderAlex
проверка клиентами-соседями в общем случае и проверка сервером в частных случаях . так как на обычно в игре довольно много народу , то нагрузка на сервак снизится в несколько раз . трафик на клиенте конешно увеличится , но это не критично потому что всего на несколько процентов .
Это оптимально с точки зрения производительности, но с другой стороны - мы будем вынуждены вынести часть (или даже весь) проверяющий кода в клиента, это небезопасно.
представь алгоритм :при подключении очередного клиента сервак выбирает случайно из текущего списка клиентов с разными айпишками N клиентов проверки .
даже при N=5 вероятность обмана ничтожна .
а если добавить периодическое перераспределение клиентов проверки - то и невозможна .
даже при N=5 вероятность обмана ничтожна .
а если добавить периодическое перераспределение клиентов проверки - то и невозможна .
Цитата: Green
А это самая большая проблема вашей игры?
Игра уже написана?
Игра уже написана?
Никакая это не проблема. Игра почти уже дописана.
[quote=koderAlex]в принципе идею описал , её только до мелочей продумать надо .
1)при подключении нового клиента сервак выбирает несколько клиентов из уже подключенных с разными айпишками
2)выбранным клиентам проверки и подключаймому клиенту высылается объект пользователя (герой там или во что там игра идёт - в общем персонаж) и список клиентов проверки . активируем объект пользователя на сервере .
3) при использовании клиентом чего нить сигнал посылается всем клиентам проверки . они проверяют действие на его возможность (например клиент хочет использовать гранату на объект танк - проверяется есть ли у объекта пользователя гранаты и существует ли танк ) .
4) каждый из клиентов проверки посылает сигнал разрешения клиенту поверки который последний в списке (или сразу , или по цепочке)
5) если хотябы один сигнал отрицательный , то идёт сообщение серверу
6)если всё в поряде ,то последний в списке клиент проверки расчитывает действие ,а результат отсылается всем (изменения на карте , изменения в персе, ну и прочее)
7) смещается список клиентов проверки и этим клиентам рассылается .
примерно так . [/quote]
В принципе, идея конечно интересная, но есть несколько вопросов.
1 - Я правильно понял, что ты предлагаешь такую проверку на клиентах сделать при каждом игровом действии?
Насчет того, что вырастет незначительно траффик - это спорно (на мой взгляд - очень даже здорово вырастет), надо иметь какие -то результаты тестов, имхо.
Но вот пинг имхо, вырастет здорово. А для реалтаймных приложений это очень существенно. В варике, например, при 100 - нормально, а при 200 - уже плохо:).
2 - Допустим, что завелся среди юзеров хакер, который таки- хочет все это сломать. И вот он создает перса, и они изменяет код клиента, и пытается пробиться на сервер. Так как харки - клиента изменены, то и проверять других клиентов адекватно такой клиент не сможет, и велика вероятность, что значительное кол-во пользователей (легитимных) будут время от времени получать отказ. Это подорвет их интерес к игре.
3 - Когда выяснится защитная схема - кому надо, быстро узнают и могут порушить вообще весь сервис, ругулярно создавая мультов с неправильными параметрами в огромном кол-ве. Особенно учитывая, что часть проверяющего кода переносится в клиентов, и ее (если все это OpenSourse) тут же узнают.
1)при подключении нового клиента сервак выбирает несколько клиентов из уже подключенных с разными айпишками
2)выбранным клиентам проверки и подключаймому клиенту высылается объект пользователя (герой там или во что там игра идёт - в общем персонаж) и список клиентов проверки . активируем объект пользователя на сервере .
3) при использовании клиентом чего нить сигнал посылается всем клиентам проверки . они проверяют действие на его возможность (например клиент хочет использовать гранату на объект танк - проверяется есть ли у объекта пользователя гранаты и существует ли танк ) .
4) каждый из клиентов проверки посылает сигнал разрешения клиенту поверки который последний в списке (или сразу , или по цепочке)
5) если хотябы один сигнал отрицательный , то идёт сообщение серверу
6)если всё в поряде ,то последний в списке клиент проверки расчитывает действие ,а результат отсылается всем (изменения на карте , изменения в персе, ну и прочее)
7) смещается список клиентов проверки и этим клиентам рассылается .
примерно так . [/quote]
В принципе, идея конечно интересная, но есть несколько вопросов.
1 - Я правильно понял, что ты предлагаешь такую проверку на клиентах сделать при каждом игровом действии?
Насчет того, что вырастет незначительно траффик - это спорно (на мой взгляд - очень даже здорово вырастет), надо иметь какие -то результаты тестов, имхо.
Но вот пинг имхо, вырастет здорово. А для реалтаймных приложений это очень существенно. В варике, например, при 100 - нормально, а при 200 - уже плохо:).
2 - Допустим, что завелся среди юзеров хакер, который таки- хочет все это сломать. И вот он создает перса, и они изменяет код клиента, и пытается пробиться на сервер. Так как харки - клиента изменены, то и проверять других клиентов адекватно такой клиент не сможет, и велика вероятность, что значительное кол-во пользователей (легитимных) будут время от времени получать отказ. Это подорвет их интерес к игре.
3 - Когда выяснится защитная схема - кому надо, быстро узнают и могут порушить вообще весь сервис, ругулярно создавая мультов с неправильными параметрами в огромном кол-ве. Особенно учитывая, что часть проверяющего кода переносится в клиентов, и ее (если все это OpenSourse) тут же узнают.
1) в таком алгоритме получается распределённая вычислительная сеть .
2) суммарная пропускная способность каналов между клиентами больше чем эта же характеристика между сервером и клиентами .
3) на клиентах выясняется попытка обмана , уточнение (кто виноват и что делать) просходит на сервере .
4) перс хранится на серваке - пусть создают :)
5) алгоритм ещё не доработан , так что давайте критику :)
2) суммарная пропускная способность каналов между клиентами больше чем эта же характеристика между сервером и клиентами .
3) на клиентах выясняется попытка обмана , уточнение (кто виноват и что делать) просходит на сервере .
4) перс хранится на серваке - пусть создают :)
5) алгоритм ещё не доработан , так что давайте критику :)
хм. а зачем переносить все рассчеты на сервер? сервер должен ( ИМХО даже обязан) проводить верификацию и валидацию входных данных (проверка на вхождения в заданный диапазон для значений, проверка на переход в недостижимые состояния, если используешь ДКА, проверки идентичности CRC кода клиентов и т.п.).
Цитата:
Вот в этом тоже есть проблема: в игре есть реализация светошумовых гранат. Игрок может попросту вырезать из клиента код, отвечающий за "ослепление".
Помнится 3 Qauke позволял менять код. И что? Реализовывалось все это через packN. Делали лазерку с 3 отражениями и такое оружие появлялось у всех клиентов (загружалось перед входом в режим игры для каждого). Многое зависит от типа игры.
Кроме того код можно защитить сложностью алгоритма, сложностью представления исходного кода.
Лично мне еще нравится идея с цифровой подписью от Zorkus`a. Используется же цифровая подпись для валидации документа, закрой только исходный код создания этой подписи.
Цитата:
Вот и именно, что у клиента запрашивает. А клиент не будь дурак, вернет ему изначальные параметры.
Неужели это проблема не решена, ведь многие системы используют цифровую подпись ?
Цитата:
алгоритм ещё не доработан , так что давайте критику
Если есть сервер, то я так понимаю все общение идет через него? то есть клиенты не подозревают о существовании друг-друга?
нет , не через сервер . смысл как раз в освобождении сервака от работы с которой и клиенты прекрасно справятся .
Цитата: koderAlex
2) суммарная пропускная способность каналов между клиентами больше чем эта же характеристика между сервером и клиентами .
Это верно, но ширина каналов сервера и конечного пользователя часто несравнима, тем более, что в таких играх, естественно, у сервера анлим, а вот у клиентов часто нет.
Цитата: koderAlex
3) на клиентах выясняется попытка обмана , уточнение (кто виноват и что делать) просходит на сервере .
Я понял твою идею с распределенной проверкой. Мне интересно, как сервер будет противостоять деструктивным атакам с целью его уронить, путем запуска большого кол-ва "неправильных" клиентов - и соответственно, резкого возрастания собщения об ошибках, которые необходимо проверять, с одной стороны, и возможного (и вероятного) массового отказа клиентов, с другой?
Цитата: koderAlex
5) алгоритм ещё не доработан , так что давайте критику :)
Всегда пожалуйста;) Если буду неконструктивен - одергивайте:)
Цитата: Zorkus
Это верно, но ширина каналов сервера и конечного пользователя часто несравнима, тем более, что в таких играх, естественно, у сервера анлим, а вот у клиентов часто нет.
ширина каналов клиентов сравнима между собой - в данном случае это важнее . а увеличение трафика на клиента можно подсчитать .
Цитата: Zorkus
Я понял твою идею с распределенной проверкой. Мне интересно, как сервер будет противостоять деструктивным атакам с целью его уронить, путем запуска большого кол-ва "неправильных" клиентов - и соответственно, резкого возрастания собщения об ошибках, которые необходимо проверять, с одной стороны, и возможного (и вероятного) массового отказа клиентов, с другой?
ограничение кол-ва клиентов с одного айпишника например .узким местом в таких случаях становится как раз канал сервера .
можно разделить сервера по функцональности . нагрузка на канал сервера от одной ошибки - 5 байт данных (4 байта идентификатора ошибочного клиента и один байт кода ошибки ) - не так уж и много . значит чтобы задосить сервак таким методом надо очень много зомбиков сделать .
Цитата: koderAlex
ограничение кол-ва клиентов с одного айпишника например.
Мне кажется, что коннектится к серверу под разными IP для хорошего сетевика нетрудно? Но это уже техническая часть, хорошо бы еще высказался кто.
Еще я бы хотел услышать твое мнение о влиянии этой архитектуры на пинг, о чем я писал выше - это имхо, самый уязвимый момент твоей схемы.
Ты описал, как противодействовать нагрузкам, возникающим при спамообразных атаках - согласен:). Но остались неясности:
1) - Как бороться с проблемой ложных срабатываний защиты, при распространении фальшивых клиентов?
2) - Вынесение части проверяющего кода и открытие его в клиента, не приведет к тому, что некто сможет понять, как функционирует этот механизм в целом, и , не атакуя собственно сервер, создать связную группу фальшивых клиентов, которые при выборе этой группы для проверки, будут некоторое время казаться серверу группой корректных клиентов?
И - новый вопрос:) -
Как будет реагировать сервер, если некоторые проверяющие клиенты отвалятся в процессе проверки?
И кстати, зачем ты предлагаешь, как я понял, осущ. проверку при каждом действии каждого клиента? Достаточно в начале каждой сессии делать.
P.S. К моей идее - тоже буду рад услышать критику и комментарии, чтобы обсуждать и развивать ее.
Цитата: Zorkus
Мне кажется, что коннектится к серверу под разными IP для хорошего сетевика нетрудно? Но это уже техническая часть, хорошо бы еще высказался кто.
Еще я бы хотел услышать твое мнение о влиянии этой архитектуры на пинг, о чем я писал выше - это имхо, самый уязвимый момент твоей схемы.
Ты описал, как противодействовать нагрузкам, возникающим при спамообразных атаках - согласен:). Но остались неясности:
1) - Как бороться с проблемой ложных срабатываний защиты, при распространении фальшивых клиентов?
Еще я бы хотел услышать твое мнение о влиянии этой архитектуры на пинг, о чем я писал выше - это имхо, самый уязвимый момент твоей схемы.
Ты описал, как противодействовать нагрузкам, возникающим при спамообразных атаках - согласен:). Но остались неясности:
1) - Как бороться с проблемой ложных срабатываний защиты, при распространении фальшивых клиентов?
не понял вопрос : как срабатывание при фальшклиенте может быть ложным ?
при неэффективном фальшклиенте его никто распространять не будет .
Цитата: Zorkus
2) - Вынесение части проверяющего кода и открытие его в клиента, не приведет к тому, что некто сможет понять, как функционирует этот механизм в целом, и , не атакуя собственно сервер, создать связную группу фальшивых клиентов, которые при выборе этой группы для проверки, будут некоторое время казаться серверу группой корректных клиентов?
список создаётся на сервере генератором случайных чисел - так что это мало вероятно :) .
Цитата: Zorkus
И - новый вопрос:) -
Как будет реагировать сервер, если некоторые проверяющие клиенты отвалятся в процессе проверки?
И кстати, зачем ты предлагаешь, как я понял, осущ. проверку при каждом действии каждого клиента? Достаточно в начале каждой сессии делать.
P.S. К моей идее - тоже буду рад услышать критику и комментарии, чтобы обсуждать и развивать ее.
в случае нормального выхода клиента из игры - всё понятно : сервер выбирает новый список и клиент отключается . а вот в случае дисконнекта - это вот и есть недоработка алгоритма . надо обмозговать .
Цитата: koderAlex
не понял вопрос : как срабатывание при фальшклиенте может быть ложным ?
при неэффективном фальшклиенте его никто распространять не будет .
при неэффективном фальшклиенте его никто распространять не будет .
Что ты имеешь в виду под неэффективным фальшклиентом? И как я понимаю, ты предполагаешь, что все клиенты, которые участвуют в проверке другого клиента, сами уже прошли проверку, а самые "базисные" проверил сервер лично? Так? Иначе как гарантируется, что все проверяющие клиенты сами корректны?
Цитата: koderAlex
в случае нормального выхода клиента из игры - всё понятно : сервер выбирает новый список и клиент отключается .
Т.е. процесс такой - один из проверяющих клиентов отключился, мы выбрали нового клиента, для проверки (потому что переделывать весь список долго:)), выбрали еще одного недостающего клиента из активных, сервер его проверил, включил в пул проверяльщиков, и далее все работает, пока следующий проверяльщик не сдохнет? Вопрос такой - как это все скажется на пинге? Ты упорно обходишь молчанием этот момент;)
Цитата: koderAlex
а вот в случае дисконнекта - это вот и есть недоработка алгоритма . надо обмозговать .
В принципе, этот случай мало чем отличается от корректного отсоединения с точки зрения безопасности, все равно, даже если имела место атака, при следующем коннекте клиент будет проверен заново. Тут проблема вот в чем. Надо будет тогда ограничивать отклика время от проверяльщиков, иначе получится, что при дисконеекте другого все повиснет. Но время проверяльщиков зависит от пинге клиента, которого они проверяют - придется при таком подходе вырубать клиентов, чуть только у них начнет тормозить коннект.
Если, как я предлагаю, клиент проверяется только один раз, при коннекте, то вроде можно так сделать...
Цитата: Zorkus
Что ты имеешь в виду под неэффективным фальшклиентом? И как я понимаю, ты предполагаешь, что все клиенты, которые участвуют в проверке другого клиента, сами уже прошли проверку, а самые "базисные" проверил сервер лично? Так? Иначе как гарантируется, что все проверяющие клиенты сами корректны?
если кто то изменил клинт прогу (сделал фальшклиента) , а он не работает так как задумано , то это неэффективный фальшклиент .
Цитата: Zorkus
Т.е. процесс такой - один из проверяющих клиентов отключился, мы выбрали нового клиента, для проверки (потому что переделывать весь список долго:)), выбрали еще одного недостающего клиента из активных, сервер его проверил, включил в пул проверяльщиков, и далее все работает, пока следующий проверяльщик не сдохнет? Вопрос такой - как это все скажется на пинге? Ты упорно обходишь молчанием этот момент;)
это надо проверять практикой . теоретически - не очень . клиенты умирают не каждую милисекунду и даже не каждую секунду :)
Цитата: Zorkus
В принципе, этот случай мало чем отличается от корректного отсоединения с точки зрения безопасности, все равно, даже если имела место атака, при следующем коннекте клиент будет проверен заново. Тут проблема вот в чем. Надо будет тогда ограничивать отклика время от проверяльщиков, иначе получится, что при дисконеекте другого все повиснет. Но время проверяльщиков зависит от пинге клиента, которого они проверяют - придется при таком подходе вырубать клиентов, чуть только у них начнет тормозить коннект.
Если, как я предлагаю, клиент проверяется только один раз, при коннекте, то вроде можно так сделать...
таймаут - естественно нужен . а при плохом коннекте в онлайне мало кто играет ) . надо выработать для конкретной игры минимальную величину трафика , ну и боротся за неё при разработке игры :) .
Цитата: koderAlex
если кто то изменил клинт прогу (сделал фальшклиента) , а он не работает так как задумано , то это неэффективный фальшклиент .
Прости, я как-то тоже не до конца понимаю про фальшклиент. Если "хакер" напортачит что-то с клиентом, то этот препарированный клиент будет участвовать в проверке других клиентов и там сможет натворить немало зла.
Zorkus
А вот со всеми этими хэшами и цифровыми подписями:
в программе есть переменная blind, которая хранит информацию "ослеплен игрок или нет", сервер (даже так) эту информацию отправляет клиенту. В клиенте есть, например, такой кусок:
Код:
Пользователь (не будь дураком) берет и удаляет все, что в скобках. И какой тут подпись спасет?
Цитата: EASTPrince
Прости, я как-то тоже не до конца понимаю про фальшклиент. Если "хакер" напортачит что-то с клиентом, то этот препарированный клиент будет участвовать в проверке других клиентов и там сможет натворить немало зла.?
Ничего, если отвечу я?;) По идее, препарированный клиент априори не участвует в проверке. В ней участвуют только уже проверенные клиенты. Упрощенно говоря - при старте сервиса (игры), сервер проверяет некоторое кол-во клиентов "лично", и из них формирует проверяющую бригаду. И они проверяют вновь подключающихся клиентов. Далее, если какой-то проверяльщик из нее отключиться - тогда сервер выбирает нового, лично его проверяет, и включает в состав бригады.
Цитата: EASTPrince
Zorkus
А вот со всеми этими хэшами и цифровыми подписями:
в программе есть переменная blind, которая хранит информацию "ослеплен игрок или нет", сервер (даже так) эту информацию отправляет клиенту. В клиенте есть, например, такой кусок:
Код:
if (blind) {
// код, отвечающий за закрашивание экрана белым
}
// код, отвечающий за закрашивание экрана белым
}
Пользователь (не будь дураком) берет и удаляет все, что в скобках. И какой тут подпись спасет?
Ну, я с самого начала предлагал не открывать код:). Но в данном случае - пользователь-то изменить сможет. Но при этом он неизбежно изменит некоторые ключевые параметры. И при коннекте сервер зарегистрирует несовпадение их с набором имеющихся у него контрольных параметров и откажет в подключении.
P.S. Рекомендую изучить устройство цифровых подписей. Тогда это будет более понятно.
Zorkus, очень знакомый подход: "если условия задачи её усложняют, давайте упрощать условия." Я пятый год из своих орлов это выбиваю всеми путями.
В данном случае имеем условие: игра OS. А значит любой имеющий доступ к исходникам может модифицировать клиент. Значит нужно обеспечить чтобы изменённый клиент либо не мог подключаться, либо не мог получать преимущества от введённых изменений.
Другое условие: при коннекте к серверу возможно проверить только соответствие аккаунта. Никакой проверки лигитимности клиента. Никакая ЭЦП не даёт гарантии лигитимности запущенного клиента. У ЭЦП совершенно другие задачи. А значит вариант проверки при подключении отпадает.
Условие выводимое из предыдущего: клиент честен до первого нарушения. А значит необходимо обеспечение правил во время взаимодействия.
Примеряем конкретную задачку. Бросок ослепляющей гранаты(ОсГр) клиентом А(кА) в клиента Б(кБ).
Сразу разбиение на несколько мелких задач.
Задача: Есть ли вообще, что бросать?
Уточнение: Необходимо обеспечить достоверность информации о наличии/отсутствии ОсГр у кА для кБ одновременно не раскрывая факта её наличия до броска.
Решение(вариант): Имхо, такое возможно при аудите клиентом В(кВ) при помощи ЭЦП. А можно и без ЭЦП.
З: Позиционирование места разрыва.
У: Вряд ли разорвавшаяся за спиной ОсГр ослепит кБ.
Р: Это частный случай общей балистической задачи. При одинаковых алгоритмах точка и воздействие будут одинаковыми. Остаётся запротоколировать. Возможно и усложнение в виде возможности зажмурится...
З: Обеспечение ослепления.
У: При световом шоке допустима дискоординация. При этом кБ может продолжать огонь, но информации о том куда он стреляет у него нет, а информация о результатах доступна только в виде звука.
Р: Тупое отключение отображения, безусловно, не сработает. Значит ослепление на уровне алгоритма. Просто при ослеплении вводим случайную дельту координат не сообщаемую кБ. Также не сообщаем о передвижениях кА. При этом оставшееся на экране изображение сыграет злую шутку с кБ: кА он будет видеть, но там где он его видит с точки зрения алгоритма кА нет. Опять всё происходящее протоколируем на кВ. Относительно честного игрока повернувшегося примерно туда где противник, действует правило дезориентации тем большей, чем дальше от линии огня был противник. Идиот бросивший ОсГр и оставшийся на месте заслуживает пули безотносительно честно её всадили или с нарушением правил.
З: Обеспечение соблюдения правил кА после броска ОсГр.
У: Очевидно что без контроля кА может злоупотребить отсутствием у кБ части информации.
Р: Очевидно, что в отсутствии у кБ возможности исполнения балистического алгоритма рассчёты должен брать на себя кВ.
З: Обеспечение проверки честности кА и кБ.
Р: Проверка честности поединка может выполнятся и по его окончании. Или паралельно но с более низким приоритетом. Очевидно, что "погибший" клиент будет располагать временем для разбора полётов. При обнаружении нарушений информация от клиента и от арбитра передаётся серверу. После чего нарушитель блокируется.
З: Обеспечение честного арбитража кВ.
У: Возможна фальсификация протоколов при арбитраже.
Р: передавать все данные управления дважды. Один раз в рилтайме. Затем подписаным блоком. Причем блоки передаются к арбитру и от него. При расхождении блокировка поединка.
В данном случае имеем условие: игра OS. А значит любой имеющий доступ к исходникам может модифицировать клиент. Значит нужно обеспечить чтобы изменённый клиент либо не мог подключаться, либо не мог получать преимущества от введённых изменений.
Другое условие: при коннекте к серверу возможно проверить только соответствие аккаунта. Никакой проверки лигитимности клиента. Никакая ЭЦП не даёт гарантии лигитимности запущенного клиента. У ЭЦП совершенно другие задачи. А значит вариант проверки при подключении отпадает.
Условие выводимое из предыдущего: клиент честен до первого нарушения. А значит необходимо обеспечение правил во время взаимодействия.
Примеряем конкретную задачку. Бросок ослепляющей гранаты(ОсГр) клиентом А(кА) в клиента Б(кБ).
Сразу разбиение на несколько мелких задач.
Задача: Есть ли вообще, что бросать?
Уточнение: Необходимо обеспечить достоверность информации о наличии/отсутствии ОсГр у кА для кБ одновременно не раскрывая факта её наличия до броска.
Решение(вариант): Имхо, такое возможно при аудите клиентом В(кВ) при помощи ЭЦП. А можно и без ЭЦП.
З: Позиционирование места разрыва.
У: Вряд ли разорвавшаяся за спиной ОсГр ослепит кБ.
Р: Это частный случай общей балистической задачи. При одинаковых алгоритмах точка и воздействие будут одинаковыми. Остаётся запротоколировать. Возможно и усложнение в виде возможности зажмурится...
З: Обеспечение ослепления.
У: При световом шоке допустима дискоординация. При этом кБ может продолжать огонь, но информации о том куда он стреляет у него нет, а информация о результатах доступна только в виде звука.
Р: Тупое отключение отображения, безусловно, не сработает. Значит ослепление на уровне алгоритма. Просто при ослеплении вводим случайную дельту координат не сообщаемую кБ. Также не сообщаем о передвижениях кА. При этом оставшееся на экране изображение сыграет злую шутку с кБ: кА он будет видеть, но там где он его видит с точки зрения алгоритма кА нет. Опять всё происходящее протоколируем на кВ. Относительно честного игрока повернувшегося примерно туда где противник, действует правило дезориентации тем большей, чем дальше от линии огня был противник. Идиот бросивший ОсГр и оставшийся на месте заслуживает пули безотносительно честно её всадили или с нарушением правил.
З: Обеспечение соблюдения правил кА после броска ОсГр.
У: Очевидно что без контроля кА может злоупотребить отсутствием у кБ части информации.
Р: Очевидно, что в отсутствии у кБ возможности исполнения балистического алгоритма рассчёты должен брать на себя кВ.
З: Обеспечение проверки честности кА и кБ.
Р: Проверка честности поединка может выполнятся и по его окончании. Или паралельно но с более низким приоритетом. Очевидно, что "погибший" клиент будет располагать временем для разбора полётов. При обнаружении нарушений информация от клиента и от арбитра передаётся серверу. После чего нарушитель блокируется.
З: Обеспечение честного арбитража кВ.
У: Возможна фальсификация протоколов при арбитраже.
Р: передавать все данные управления дважды. Один раз в рилтайме. Затем подписаным блоком. Причем блоки передаются к арбитру и от него. При расхождении блокировка поединка.
Цитата: YJoudai
Zorkus, очень знакомый подход: "если условия задачи её усложняют, давайте упрощать условия." Я пятый год из своих орлов это выбиваю всеми путями.
Да я не не стремлюсь упрощать условия, вырабатывая какой то способ для одной ситуации - бросание светошоковой гранаты. А завтра будет ситуация с выстрелом из гаубицы, послезавтра - будет другая игра. Я хочу выработать общий и гибкий механизм проверок, а не узкоприменимый конкретный способ, и вот уже этот механизм проработать, настолько подробно, насколько это возможно, абстрагируясь от конкретного приложения.
Цитата: YJoudai
В данном случае имеем условие: игра OS. А значит любой имеющий доступ к исходникам может модифицировать клиент. Значит нужно обеспечить чтобы изменённый клиент либо не мог подключаться, либо не мог получать преимущества от введённых изменений.
Имхо, не надо, чтобы измененный клиент мог подключаться. Если же кто-то со стороны написал полезный патч или иное усовершенствование для клиента - пусть связывается с администраторами игры, и потом они этот вопрос решают организационно.
Цитата: YJoudai
Другое условие: при коннекте к серверу возможно проверить только соответствие аккаунта. Никакой проверки лигитимности клиента. Никакая ЭЦП не даёт гарантии лигитимности запущенного клиента. У ЭЦП совершенно другие задачи. А значит вариант проверки при подключении отпадает.
Почему? Это невозможно принципиально, очень трудоемко и дорого в реализации, или что? Мне кажется, такое вполне можно организовать.
Цитата: YJoudai
Условие выводимое из предыдущего: клиент честен до первого нарушения. А значит необходимо обеспечение правил во время взаимодействия.
Это конечно, я согласен. Но такое надо вынести в "Уголовный кодекс" игры. И там подробно расписать.
Цитата: YJoudai
Примеряем конкретную задачку. Бросок ослепляющей гранаты(ОсГр) клиентом А(кА) в клиента Б(кБ).
Сразу разбиение на несколько мелких задач.
Задача: Есть ли вообще, что бросать?
Уточнение: Необходимо обеспечить достоверность информации о наличии/отсутствии ОсГр у кА для кБ одновременно не раскрывая факта её наличия до броска.
Решение(вариант): Имхо, такое возможно при аудите клиентом В(кВ) при помощи ЭЦП. А можно и без ЭЦП.
А можно при аудите сервером.
Цитата: YJoudai
Р: Тупое отключение отображения, безусловно, не сработает. Значит ослепление на уровне алгоритма. Просто при ослеплении вводим случайную дельту координат не сообщаемую кБ. Также не сообщаем о передвижениях кА. При этом оставшееся на экране изображение сыграет злую шутку с кБ: кА он будет видеть, но там где он его видит с точки зрения алгоритма кА нет. Опять всё происходящее протоколируем на кВ.
Тупое отключение не сработает, но конкретные алгоритмы ослепления можно наверняка изучать по книгам по геймдеву или же по открытым исходникам (вовсе не обязательно онлайновой) другой игры, похожего типа и уровня.
Цитата: YJoudai
Относительно честного игрока повернувшегося примерно туда где противник, действует правило дезориентации тем большей, чем дальше от линии огня был противник. Идиот бросивший ОсГр и оставшийся на месте заслуживает пули безотносительно честно её всадили или с нарушением правил.
Вот это вообще не понял. Честный игрок - это тот, кто бросил гранату? ОН так же должен ослепляться, конечно (если нет спецзащиты), но дезориентация зависит от того, насколько был он сам далеко от места взрыва, а не от взаимного расположение эпицентра взрыва и противника.
И потом - что значит "идиот"?? Игрок может использовать оружие как
хочет и когда хочет, и вправе рассчитывать, что разработчик опирался при разработке и реализации логики таких вещей на объективные физические законы, а не на субъективные нравственные оценки програмиста (особенно учитывая, что разные разработчики будут такие ситуации оценивать по-своему!).
Цитата: YJoudai
З: Обеспечение соблюдения правил кА после броска ОсГр.
У: Очевидно что без контроля кА может злоупотребить отсутствием у кБ части информации.
Р: Очевидно, что в отсутствии у кБ возможности исполнения балистического алгоритма рассчёты должен брать на себя кВ.
Что значит - злоупотребить отсутствием информации к кБ? В этом смысл ослепления. Спроси у любого опытного CS:).
Цитата: YJoudai
З: Обеспечение проверки честности кА и кБ.
Р: Проверка честности поединка может выполнятся и по его окончании. Или паралельно но с более низким приоритетом. Очевидно, что "погибший" клиент будет располагать временем для разбора полётов. При обнаружении нарушений информация от клиента и от арбитра передаётся серверу. После чего нарушитель блокируется.
З: Обеспечение честного арбитража кВ.
У: Возможна фальсификация протоколов при арбитраже.
Р: передавать все данные управления дважды. Один раз в рилтайме. Затем подписаным блоком. Причем блоки передаются к арбитру и от него. При расхождении блокировка поединка.
Тут ты опираешься на то, что игровой процесс представляет собой схватки игроков? Причем, проходящие пошагово?
Тогда, два вопроса -
1) А как это предполагаешь модернизировать, если играет множество людей независимо, и игра, по сути, не останавливается вообще? Она не дискретна, в отличие от того же БК, например?
2)В случае онлайновой игры, как такие механизмы с двойными проверками, будут влиять на производительность?
Цитата: Zorkus
Да я не не стремлюсь упрощать условия, вырабатывая какой то способ для одной ситуации - бросание светошоковой гранаты. А завтра будет ситуация с выстрелом из гаубицы, послезавтра - будет другая игра. Я хочу выработать общий и гибкий механизм проверок, а не узкоприменимый конкретный способ, и вот уже этот механизм проработать, настолько подробно, насколько это возможно, абстрагируясь от конкретного приложения.
Налицо подмена понятий. Выработка способа решения для одной ситуации - упрощение решения. Отказ от принципа OpenSource - упрощение условия.
Условия задаются внешне, но бывает соблазн "незаметить" их сложность. Думается, условие OS может диктоваться обстоятельствами. И советовать отказаться это минимум бестактность. Кроме того, есть ещё имхо: метод сокрытия исходников не гарантирует безопасности. Реверс инженерию ещё никто не отменил, хотя и пытаются сделать незаконной.
Обобщение сценариев решений небольших задач может дать необходимые уровни абстракций. Если их конечно не получается выделить предварительно. Решение достаточно большой задачи вцелом как правило превышает интеллектуальные возможности человека. (Причём любого человека.)
Цитата: Zorkus
Имхо, не надо, чтобы измененный клиент мог подключаться. Если же кто-то со стороны написал полезный патч или иное усовершенствование для клиента - пусть связывается с администраторами игры, и потом они этот вопрос решают организационно.
Мы не можем избежать подключения изменённого клиента. Я такого решения не знаю. Очевидно, Вы тоже.
Цитата: Zorkus
Почему? Это невозможно принципиально, очень трудоемко и дорого в реализации, или что? Мне кажется, такое вполне можно организовать.
Нет ни одного решения. И это при том, что в исследованиях участвует огромное количество людей и они весьма щедро финансируются.
Цитата: Zorkus
Это конечно, я согласен. Но такое надо вынести в "Уголовный кодекс" игры. И там подробно расписать.
В правила пункт о блокировке аккаунтов на которых используется клиенты нарушающие правила. Но это только для формального обеспечения законности блокировки.
В данном случае это "данность" которую не изменить.
Цитата: Zorkus
А можно при аудите сервером.
Эт я недодумал. В данном случае только аудит на сервере.
Цитата: Zorkus
Тупое отключение не сработает, но конкретные алгоритмы ослепления можно наверняка изучать по книгам по геймдеву или же по открытым исходникам (вовсе не обязательно онлайновой) другой игры, похожего типа и уровня.
Теорией не владею. Но вариант предложил вроде жизнеспособный: отключение "отключения отображения" бессмысленно.
Цитата: Zorkus
Вот это вообще не понял. Честный игрок - это тот, кто бросил гранату? ОН так же должен ослепляться, конечно (если нет спецзащиты), но дезориентация зависит от того, насколько был он сам далеко от места взрыва, а не от взаимного расположение эпицентра взрыва и противника.
Как раз наоборот. Ослепление не означает лишение дееспособности. В реальной ситуации можно вести огонь вслепую. Особенно если противник до ослепления находился в точке прицеливания или недалеко от неё. Опять же веерный огонь по небольшому сектору может быть результативен.
Цитата: Zorkus
И потом - что значит "идиот"?? Игрок может использовать оружие как хочет и когда хочет, и вправе рассчитывать, что разработчик опирался при разработке и реализации логики таких вещей на объективные физические законы, а не на субъективные нравственные оценки програмиста (особенно учитывая, что разные разработчики будут такие ситуации оценивать по-своему!).
Это реальная тактика современных боевых действий. Не в играх. Смена позиции при ведении огня в условиях прямой видимости противником.
Реальность такова, если Ты не в укреплённой огневой точке, то после однократного применения оружия позиция меняется. Точка. Во всех инструкциях это условие выживания.
Цитата: Zorkus
Что значит - злоупотребить отсутствием информации к кБ? В этом смысл ослепления. Спроси у любого опытного CS:).
Ну если я слеп, то это не означает что не могу двигаться и стрелять. И если уж я попал в кого, пусть и случайно, то он минимум ранен, оглушён или убит к моей радости. Да и по двигающейся мишени попасть проблемно. Если данные не передаются мне, то кто помешает не засчитать попадание или объявить о попадании в меня??? В этом и смысл злоупотребления.
К тому же ослепление не эффективно при захвате заложников: вероятность тяжёлого ранения или убийства заложников при ослеплении террористов близка к ста процентам. Особенно если террористы не озабочены спасением своей шкуры или о этом спасении не идёт и речь.
Цитата: Zorkus
Тут ты опираешься на то, что игровой процесс представляет собой схватки игроков?
Упаси бог. В схватке может участвовать более двух игроков, принцип не сильно меняется: в общем случае мошенничество выявляется уже при обработке ситуации или когда становятся доступны рассчётные данные(задерживаемые, например, при ослеплении). Далее только разборки на мотив "кто мошенничает?"
Цитата: Zorkus
Причем, проходящие пошагово?
А что протоколировать можно только шахматную партию??? :)
Цитата: Zorkus
Тогда, два вопроса -
1) А как это предполагаешь модернизировать, если играет множество людей независимо, и игра, по сути, не останавливается вообще? Она не дискретна, в отличие от того же БК, например?
1) А как это предполагаешь модернизировать, если играет множество людей независимо, и игра, по сути, не останавливается вообще? Она не дискретна, в отличие от того же БК, например?
Онлайновые игры в основном детерминированы. Но всегда есть ситуации когда обсчёт игровой позиции не напрягает машину игрока. Почему не занять это время "разбором полётов". К тому же для конкретного игрока точно есть ситуации когда для него игра кончилась: он проиграл и убит. Самое оно подумать кто виноват и что делать. Может какой игрок нарушал логику игры и можно подать аппеляцию. Если аппеляция справедлива, то игрок нарушитель из неё выводится с блокировкой аккаунта. Дальше зависит от логики игры: возможен вариант когда мод был введён в схватку с целью аннулировать её результаты. К сожалению не знаю что ребята делают, а универсального решения тут нет.
Цитата: Zorkus
2)В случае онлайновой игры, как такие механизмы с двойными проверками, будут влиять на производительность?
Траффик между клиентами повысится точно.
Латентность(пинг, если угодно, хотя пинг, в его правильном понимании, уж точно не увеличится) при правильном проектировании незначително измениться. На время протоколирования, естественно.
Но, как я уже отметил, мошенничество выявляется сразу и можно ввести протокол арбитража. Если клиент проверил корректность действий оппонента(результаты рассчётов сошлись), то он уведомляет об этом арбитра. Арбитр удаляет протоколы если от всех заинтересованных сторон пришли подтверждения корректности.
Вот что может помешать создать мод управляющий стрельбой???
Ведь когда клиент получает координаты противника(надо ведь его отрисовать), ничто не мешает дописать функцию, которая прицелит и начнёт стрелять, как только противник будет в зоне поражения или, например, применит активные защитные меры сводящие результат атаки к нулю???
Цитата: YJoudai
Это реальная тактика современных боевых действий. Не в играх. Смена позиции при ведении огня в условиях прямой видимости противником.
Реальность такова, если Ты не в укреплённой огневой точке, то после однократного применения оружия позиция меняется. Точка. Во всех инструкциях это условие выживания.
:D
Где ты такое вычитал? При ведении какого боя?
В каких инструкциях? Инструкции в студию!
Цитата: YJoudai
К тому же ослепление не эффективно при захвате заложников: вероятность тяжёлого ранения или убийства заложников при ослеплении террористов близка к ста процентам. Особенно если террористы не озабочены спасением своей шкуры или о этом спасении не идёт и речь.
М-да... прямо форум спецназа... :)
Теперь по сути топика. Я не просто так задал вопрос о стадии разработки игры.
Какая информация приходит серверу от клиентов:
1. Текущее местоположение и вектор скорости игрока.
2. Информация о состоянии игрока (степень повреждения, активное оружие и т.п.).
3. Информация о применении оружия (тип, вектор).
Какая информация идет от сервера к клиентам:
1. Текущее местоположение игроков и векторы скорости игроков, на основе котрого происходит экстраполяция на клиентах между сетевыми фреймами.
2. Аналогично для всех подвижных элементов игры (лифты, двери, машины, механизмы и т.д.).
3. Информация о powerup-ах (аптечки, моды, оружие).
4. Информация о состоянии игроков (степень повреждения, активное оружие и т.п.).
5. Информация о применении оружия (тип, вектор).
При этом сервер может только пересылать данные, а может их контролировать и корректировать. Например, чтоб игроки не проходили сквозь стены или не перемещались мгновенно. В принципе, воздействие оружия на противников тоже хорошо бы обрабатывать на сервере, т.к. на нем проще синхронизировать информацию от двух игроков, просчитать попадание и вернуть им результаты ("ты попал"/"ты убит"), чем поручать эту задачу кому либо из игроков.
Т.о. можно посчитать и воздействие световой гранаты. Для этого требуется информация о выстреле гранаты (точка, вектор), информация об игроках (точка, вектор), что и так проходит через сервер.
Далее ослепленные игроки (например, те кто попали bsphere и вектор которых или даже раструб направлен к центру этой сферы), получают в очередном сетевом фрейме сигнал об ослеплении и не получают информации о местоположении объектов. Теперь клиент может либо рисовать белый экран (как в CS), либо рисовать статичную смазанную картинку на основе предыдущего фрейма(как в RB6). При этом никто не мешает клиенту продолжать передавать информацию на сервер о местоположении и статусе своего игрока.
Через некоторый интервал времени сервер возобновляет передачу информации об объектах.
Цитата: Green
:D
Где ты такое вычитал? При ведении какого боя?
В каких инструкциях? Инструкции в студию!
Где ты такое вычитал? При ведении какого боя?
В каких инструкциях? Инструкции в студию!
В интернете болтаются армейские инструкции пентагона. В прошлый раз я их скачал случайно. Возможно с НоНейма. Сейчас в упор не смог найти. Довольно большая серия. До того как грохнулся райд успел прочитать только "инструкция по подготовке снайперов", как самое интересное для себя. Пособие скучное и на англицком, но думаю недурно почитать прежде чем что-то сочинять.
Цитата: Green
М-да... прямо форум спецназа... :)
Просто логика. Местонахождение заложников это единственное о чём точно знает ослеплённый террорист.
Цитата: Green
Теперь по сути топика. Я не просто так задал вопрос о стадии разработки игры.
Допустим ещё не начато проектирование. :) Но это у нас.
Цитата: Green
При этом сервер может только пересылать данные, а может их контролировать и корректировать. Например, чтоб игроки не проходили сквозь стены или не перемещались мгновенно. В принципе, воздействие оружия на противников тоже хорошо бы обрабатывать на сервере, т.к. на нем проще синхронизировать информацию от двух игроков, просчитать попадание и вернуть им результаты ("ты попал"/"ты убит"), чем поручать эту задачу кому либо из игроков.
Необходимо по максимуму разгрузить сервер(а). Как вариант возможно даже делегирование функций арбитража. На сервере только хранение профилей, местонахождения, моделей пространства.
В теории нет большой разницы сервер выполняет проверку или оба клиента. До тех пор пока оба клиента выполняют один алгоритм и располагают одинаковыми данными, то рассчёты будут идентичны. Разница в результатах говорит о мухляже.
не верно . расчёты ведутся с участием генератора случайных чисел , а так как он на разных машинах будет выдавать разные последовательности , то и результат расчётов будет разный .
Цитата: YJoudai
В интернете болтаются армейские инструкции пентагона. В прошлый раз я их скачал случайно. Возможно с НоНейма. Сейчас в упор не смог найти. Довольно большая серия. До того как грохнулся райд успел прочитать только "инструкция по подготовке снайперов", как самое интересное для себя. Пособие скучное и на англицком, но думаю недурно почитать прежде чем что-то сочинять.
Ключевое слово - "снайперы".
Ведение боя снайпера в корне отличается от ведения боя, например, пулеметного расчета.
Цитата: YJoudai
Просто логика. Местонахождение заложников это единственное о чём точно знает ослеплённый террорист.
Логика... :)
Ослепленный и оглушенный взрывом и светом террорист некоторое время не знает точно кто он и где, а про существование заложников он вспомнит ещё позднее.
Цитата: YJoudai
Допустим ещё не начато проектирование. :) Но это у нас.
А у нас уже закончена разработка: http://creatstudio.com/games/ca2.html
Хотя там схема иная в виду специфичности платформы.
Цитата: YJoudai
Необходимо по максимуму разгрузить сервер(а). Как вариант возможно даже делегирование функций арбитража. На сервере только хранение профилей, местонахождения, моделей пространства.
В теории нет большой разницы сервер выполняет проверку или оба клиента. До тех пор пока оба клиента выполняют один алгоритм и располагают одинаковыми данными, то рассчёты будут идентичны. Разница в результатах говорит о мухляже.
Есть огромная разница. В первую очередь, не следует забывать про ВРЕМЯ! Обмен информацией по сети - процесс далеко не мгновенный.
Для того, чтобы хотябы два клиента выполнили одни вычисления необходимо 4 сетевых фрейма:
1) отправка данных на сервер,
2) отправка данных на др. клиент,
3) отправка данных обратно на сервер,
4) отправка результата клиентам.
При этом следует учесть, что процесс попадания выстрела был несколько фреймов назад, поэтому либо клиенты должны хранить у себя информацию о предыдущих фреймах (и о всех других игроках!), либо получать эту инф. с сервера.
Кроме того, из-за неточности в определении времени, данные на разных машинах всегда будут (немного) различаться.
В идеале IMHO определяться попадание должно на машине стреляющего, т.к. мы должны стрелять и попадать в то, что видим. Далее эта инф. должна перепроверяться на сервере и рассылаться др. клиентам. Т.о. укладываемся в 2 фрейма:
1) отправка данных на сервер,
4) отправка результата клиентам.
Вот, кстати, статейка по теме:
http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html
Я так понимаю, что мы тут все под "сервером" понимаем всю доступную создателям/администраторам игру инфраструктуру? Все, что они непосредственно контролируют?
Тогда есть такой вариант. Все согласны с тем, что что реализации того варианта с взаимопроверкой клиентов нам нужны априори корректные клиенты. Если это игры не типа CS, которая существуют в контексте раундов только, а мир свой полноценный имеет , то что мешает разработчикам подвесить некоторое кол-во ботов (странников, богов, бродячих торговцев, агентов коалиции XXX, главарей Аль-Каиды (раз уж свели все к терроризму..) и т.д.)? Они и будут этими базисными клиентами.
И все же мое мнение: чем более будут разгружены сервера - тем менее производительно все это будет. Приоритет - это быстродействие и безопасность (не говорю тут о геймплее и т.п., это частности) , причем безопасность должны быть реализована просто и понятно для пользователя. Апелляции и жалобы на других тут не рулят;) если конечно вся игра - не симулятор суда. Все проверки должны производиться незаметно для игроков и не грузить их орг. вопросами. Если же при таких приоритетах не хватит мощностей чтобы запустить сервис - то это уже орг. проблема.
Тогда есть такой вариант. Все согласны с тем, что что реализации того варианта с взаимопроверкой клиентов нам нужны априори корректные клиенты. Если это игры не типа CS, которая существуют в контексте раундов только, а мир свой полноценный имеет , то что мешает разработчикам подвесить некоторое кол-во ботов (странников, богов, бродячих торговцев, агентов коалиции XXX, главарей Аль-Каиды (раз уж свели все к терроризму..) и т.д.)? Они и будут этими базисными клиентами.
И все же мое мнение: чем более будут разгружены сервера - тем менее производительно все это будет. Приоритет - это быстродействие и безопасность (не говорю тут о геймплее и т.п., это частности) , причем безопасность должны быть реализована просто и понятно для пользователя. Апелляции и жалобы на других тут не рулят;) если конечно вся игра - не симулятор суда. Все проверки должны производиться незаметно для игроков и не грузить их орг. вопросами. Если же при таких приоритетах не хватит мощностей чтобы запустить сервис - то это уже орг. проблема.
Цитата: koderAlex
не верно . расчёты ведутся с участием генератора случайных чисел , а так как он на разных машинах будет выдавать разные последовательности , то и результат расчётов будет разный .
Что мешает добавить случайные последовательности в пакеты обмена???
Green, за статью спасибо. Многие непонятки прояснились.
Идея работы без сервера нежизнеспособна по вполне примитивным соображениям. Немного переиначив статью можно сказать, что для каждого дополнительного противника полоса должна расширяться минимум на 10kbps. Что ограничивает число противников шестью для 64К полосы. И это в лучшем случае. :(
Цитата:
Кроме того, из-за неточности в определении времени, данные на разных машинах всегда будут (немного) различаться.
И зачем только сетевики выдумывали протоколы синхронизации времени???
Кроме того в той же статье речь идёт о дискретных тиках продолжительностью 30ms. Рассинхронизация врядли будет настолько большой.
Цитата:
В идеале IMHO определяться попадание должно на машине стреляющего, т.к. мы должны стрелять и попадать в то, что видим. Далее эта инф. должна перепроверяться на сервере и рассылаться др. клиентам.
В идеале. До тех пор пока стреляющий не "слеп".
[SIZE="1"]Про ослепление. Когда-то в глупом детстве попало нам грам 200-300 магния. Оный был превращён в опилки и подожжён в смеси с марганцовкой. В принципе это аналог ослепляющей гранаты? Вспышка сначала была абсолютного белого цвета, потом стала чёрной. Чёрным стало и солнечное зимнее утро. Но никто не только не забыл как кого зовут, но и вполне прилично унесли ноги, хотя и видели только пульсации света.
Про тактику. Поведение снайпера и пехотинца в стрелковой ячейке отличается выбором целей. В других случаях разница более ощутима. Но суть одна: позиция доступная для поражения должна меняться. Поэтому к фразе "после броска ослепляющей гранаты игрок волен оставаться на месте..." я не могу не добавить "...и получить свою законную пулю, если его было видно до броска гранаты."[/SIZE]
И всё-таки объясните. Что помешает написать функцию автоприцеливания, если известны координаты всех участников?!!
В концепции нашей игры FPS элементы не столь существенны, но их результаты могут здорово изменить ход игры. (гм...) Ну это вроде как во время Великой Отечественной пробраться в ставку Гитлера и перестрелять всю верхушку германского командования.
Так вот имея мод автоустраняющий противника, можно резко сменить баланс. Что не есть гуд.
[QUOTE=Zorkus]Апелляции и жалобы на других тут не рулят[/QUOTE]
Ну я и не имел в виду, что сам игрок побежит жаловаться. А всего лишь его клиент при выявлении жульничества имеет возможность обратиться к серверу-арбитру.
[QUOTE=Zorkus]Все, что они непосредственно контролируют?[/QUOTE]
Теперь именно так.
[QUOTE=Zorkus]что мешает разработчикам подвесить некоторое кол-во ботов (странников, богов, бродячих торговцев, агентов коалиции XXX, главарей Аль-Каиды (раз уж свели все к терроризму..) и т.д.)?[/QUOTE]
Да не суть как их назвать. В любом случае это будут принадлежащие разработчику или подконтрольные ему сервера. Именно их количество должно быть минимально. Большая часть задач должна решаться за счёт компьютеров игроков. Это и повысит неубиваемость игры, и её распределённость по сети, и обеспечит некоторую кластеризацию в территориальных сетях.
Цитата: YJoudai
И зачем только сетевики выдумывали протоколы синхронизации времени???
А есть механизмы синхронизации до миллисекунд?
Цитата: YJoudai
Кроме того в той же статье речь идёт о дискретных тиках продолжительностью 30ms. Рассинхронизация врядли будет настолько большой.
Выдержка из той же статьи:
Цитата:
Client and server hitboxes don't exactly match because of small precision errors in time measurement. Even a small difference of a few milliseconds can cause an error of several inches for fast-moving objects. Multiplayer hit detection is not pixel perfect and has known precision limitations based on the tickrate and the speed of moving objects.
Цитата: YJoudai
В идеале. До тех пор пока стреляющий не "слеп".
А какой смысл менять алгоритм, точнее место его исполнения, в зависимости от того "ослеп" игрок или нет?
Цитата: YJoudai
[SIZE="1"]Про ослепление. Когда-то в глупом детстве попало нам грам 200-300 магния.
[/SIZE]
Когда-то в курсантской молодости мне перепало от обычного взрыв-пакета, взорвавшегося у ног. Если к этому добавить вспышку света в разы превышающую вспышку магния, то эффект будет ошеломляющим.
Цитата: YJoudai
[SIZE="1"]
Про тактику. Поведение снайпера и пехотинца в стрелковой ячейке отличается выбором целей. В других случаях разница более ощутима. Но суть одна: позиция доступная для поражения должна меняться.
[/SIZE]
Ты представляешь себе бойцов обороняющейся стороны перебегающих между стрелковыми ячейками во время боя? :)
А как же сектора обстрелов, карточка огня и пр. элементы оборонительного боя.
В наступательном же бою перемещение происходит, но не потому, что надо просто менять позицию, а потому, что надо двигаться к цели. Если бы можно было наступать оставаясь на месте, такая бы тактика с успехом применялась бы. :)
Позицию доступную для поражения, конечно, менять надо, но только по команде или по заранее назначенной схеме действий.
Цитата: YJoudai
[SIZE="1"]
Поэтому к фразе "после броска ослепляющей гранаты игрок волен оставаться на месте..." я не могу не добавить "...и получить свою законную пулю, если его было видно до броска гранаты."
[/SIZE]
Бросок любой гранаты происходит из укрытия или вне зоны действия гранаты. Здесь вопросов нет.
Цитата: YJoudai
И всё-таки объясните. Что помешает написать функцию автоприцеливания, если известны координаты всех участников?!!
Да ничего (почти) не мешает. Это и называется "читерством".
Цитата: YJoudai
Большая часть задач должна решаться за счёт компьютеров игроков. Это и повысит неубиваемость игры, и её распределённость по сети, и обеспечит некоторую кластеризацию в территориальных сетях.
А какая именно часть задач? А сколько всего может быть игроков?
Количество игроков - это очень важный момент, который должен опредяться ещё на этапе составления GDD и уточняться во время написания TDD. От количества игроков зависит gameplay, сама суть игры. Если игроков много, а карты маленькие, это будет просто мясо... никакой тактики. Если карты огромные, а игроков мало, то это будет ужасно скучно. Поэтому задача Гейм-дизайнера определить балланс, в т.ч. исходя из возможностей системы. Например, PSP ну не поддерживает больше 8 коннектов. Значит в мультиплеере будет не больше 8 игроков, а сл-но и карты должны быть пропорциональными.
Создавать же абстрактную модель для неогранниченного числа игроков - бессмысленно. В геймдеве, вообще, на первом месте скорость и играбельность, а не универсальность (хотя и ей место находится).
Цитата: Green
А есть механизмы синхронизации до миллисекунд?
Протокол NTP обеспечивает синхронизацию часов с точностью до нескольких милисекунд. Причём с дифференцированием заложеным в принципе работы.
Цитата: Green
Выдержка из той же статьи:
Человек бегущий со скоростью 4-5м/с пробежит максимум 16см за 30ms. Цена милисекунды 5мм. Причём это компенсируется разными путями. К томуже, если отсчёты идут с одинаковыми интервалами и помечаются временным штампом, то для расчётов не очень важна рассинхронизация. Другое дело что опережающий клиент будет быстрее реагировать. Но смещение можно отрегулировать также как это реализовано в NTP. Это если не задаваться целью синхронизировать часы.
Цитата: Green
А какой смысл менять алгоритм, точнее место его исполнения, в зависимости от того "ослеп" игрок или нет?
У клиента ослепшего игрока нет информации для расчётов попадания.
Цитата: Green
Когда-то в курсантской молодости мне перепало от обычного взрыв-пакета, взорвавшегося у ног. Если к этому добавить вспышку света в разы превышающую вспышку магния, то эффект будет ошеломляющим.
Ну если доверять фантастическим фильмам, то ослепляющая граната действует почти без звуковых эффектов. Это преподносится как её преимущество. Типа, не услышит кому не надо. Шоковый же канал преимущественно звуковой.
Цитата: Green
Ты представляешь себе бойцов обороняющейся стороны перебегающих между стрелковыми ячейками во время боя? :)
А как же сектора обстрелов, карточка огня и пр. элементы оборонительного боя.
А как же сектора обстрелов, карточка огня и пр. элементы оборонительного боя.
Не видел ни одной реализации оборонительного боя в играх. Это мысль, кстати. В рамки концепции укладывается вроде.
Цитата: Green
В наступательном же бою перемещение происходит, но не потому, что надо просто менять позицию, а потому, что надо двигаться к цели. Если бы можно было наступать оставаясь на месте, такая бы тактика с успехом применялась бы. :)
Игровой бой чаще всего подразумевает рейнджерские методы. В лобовую атаку никто не ходит.
Цитата: Green
Позицию доступную для поражения, конечно, менять надо, но только по команде или по заранее назначенной схеме действий.
"Любой план сражения хорош... ...до первого соприкосновения с противником."
Цитата: Green
Бросок любой гранаты происходит из укрытия или вне зоны действия гранаты. Здесь вопросов нет.
Постановка вопроса подразумевала, что бросающего видно до срабатывания гранаты.
Цитата: Green
Да ничего (почти) не мешает. Это и называется "читерством".
Можно поподробнее про "почти"? Мешает только необходимость реверса программы или какие-то сложности существуют?
Цитата: Green
А какая именно часть задач? А сколько всего может быть игроков?
Количество игроков - это очень важный момент, который должен опредяться ещё на этапе составления GDD и уточняться во время написания TDD. От количества игроков зависит gameplay, сама суть игры. Если игроков много, а карты маленькие, это будет просто мясо... никакой тактики. Если карты огромные, а игроков мало, то это будет ужасно скучно. Поэтому задача Гейм-дизайнера определить балланс, в т.ч. исходя из возможностей системы. Например, PSP ну не поддерживает больше 8 коннектов. Значит в мультиплеере будет не больше 8 игроков, а сл-но и карты должны быть пропорциональными.
Количество игроков - это очень важный момент, который должен опредяться ещё на этапе составления GDD и уточняться во время написания TDD. От количества игроков зависит gameplay, сама суть игры. Если игроков много, а карты маленькие, это будет просто мясо... никакой тактики. Если карты огромные, а игроков мало, то это будет ужасно скучно. Поэтому задача Гейм-дизайнера определить балланс, в т.ч. исходя из возможностей системы. Например, PSP ну не поддерживает больше 8 коннектов. Значит в мультиплеере будет не больше 8 игроков, а сл-но и карты должны быть пропорциональными.
Игра класса MMORPG. FPS только её часть. Соответственно, в схватке может участвовать столько игроков, сколько сможет оказаться рядом.
До момента непосредственного соприкосновения с противником игрок будет в РПГ или РТС слое и только при подходе к противнику он подключается к серверу, где и будет обрабатываться поединок. Думаю допустимо сделать ограничение на количество участвующих игроков, но оно должно соотносится только с возможностями обрабатывающего сервера. Дополнительно нужно иметь в виду, что на любой из сторон будет некоторое количество ботов.
Условный сценарий.
Игрок контролирующий (далее властитель) некоторую ключевую территорию строит базу. С территории базы его аватар управляет войсками ведущими боевые действия. (Типичная RTS.) У претендента на эту территорию есть несколько вариантов действий. Он может собрать войска и начать войну. Но собранная армия будет слабее, так как эта территория даёт возможность содержать более крупные силы. В этой ситуации победа возможна только за счёт искусности претендента в управлении войсками или(и) группы рейнджеров заброшеной к базе.
Соответственно у властителя тоже есть выбор. Можно наводнить базу войсками (в FPS будут ботами), которые гарантированно раздавят возможный десант, но это оттянет силы с передовой и лишит численного преимущества. А можно на охрану также нанять рейнджеров.
(Подразумевается, что аватар управляемый игроком имеет некоторое преимущество перед ботами.)
В результате, судьба территории возможно будет решаться и в боях армий (RTS), и в действиях небольших групп(FPS). Возможны и другие варианты, т.к. соц.правила (да и, вообще, правила) в игре задаваться не будут.
Есть мнение, что основным серверам игры за глаза хватит хранения объектов мира и их обработки. Занимать их ещё и обработкой RTS или FPS выйдет весьма накладно. Вот и предлагается вариант "большой брат". (Оруэлл "1984". Если вдруг кто не понял.)