• Игролог
• Игры
• Об авторе

Player.IO. Сетевые архитектуры

Под сетевой архитектурой подразумевается способ подключения и общения клиентов (компьютеров игроков) между собой в многопользовательских играх. Как правило, для игр используется два способа подключения это: Peer-To-Peer и Client-Server.

Peer-To-Peer архитектура

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

Основная проблема P2P заключается в безопасности, вернее в отсуствии какой-либо безопасности вообще. То есть P2P — это невероятные возможности для хакера! Одним словом: золотая жила для читов и самоутверждения недобросовестных игроков. Но самое ужасное заключается в том, что используя P2P, мы не имеем почти никаких возможностей противостоять хакерам и читерам.

Давайте рассмотрим пример: два игрока играют в пошаговую игру, где каждый из них должен нападать на другого в свою очередь. Пусть первый игрок будет у нас хакером. Наступает ход первого игрока, он должен нанести некий произвольный урон второму игроку. То есть, на клиенте первого игрока вычисляется какой-то случайный урон, который отправляется второму игроку. Но поскольку это происходит локально, на машине хакера, то фактически он обладает этими данными и может подменить их. �?, опа! Второй игрок получает 9999 урона и проигрывает. Хакер писается от счастья!

Первое, что приходит в голову — это проверить получаемые данные на их корректность, и как минимум, следует проверить выход значений за пределы допустимого диапазона, и в случае выхода — проигнорировать их. Но давайте представим, что настал ход второго игрока и он пытается атаковать хакера, который решил злоупотребить правилом проверки данных и настроил свой клиент таким образом, что теперь отвергает все атаки второго игрока. Хакер становится непобедимым и сокрушает всех своих врагов. �? тут к нам приходит понимание того, что ни один клиент не должен нести отвественности за данные, иначе сложно быть уверенными в том, что данные достоверные.

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

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

Впрочем все эти примеры — это только верхушка айсберга проблем с P2P. �? теперь мы можем с уверенностью сказать что P2P не самое лучшее решение для онлайн игр. Пожалуй, единственный случай, когда вам следует использовать P2P архитектуру — это если вы не можете или не хотите создавать сервер.

Помните, в самом начале я писал о том, что вы можете использовать и Player.IO для создания многопользовательских игр с использованием подключения по P2P? Так вот, достаточно просто указать «Bounce» при подключении или создании игровой комнаты, и тогда все сообщения, отправляемые вами на сервер будут просто пересланы другим подключенным клиентам:

client.multiplayer.createJoinRoom([roomName], "Bounce", [restParams]);

Двухуровневая система

Возвращаясь к вопросу безопасности, если мы не можем доверять нашим клиентам, то кому же мы можем тогда доверять? Конечно, серверу! Если у вас есть сервер, на котором принимаются все решения на основе данных от клиентов, то можно сказать, что вы отняли у хакеров основные возможности для самореализации. �? это подводит нас к двухуровневой архитекутре, где сервер — это больше, чем просто почтальен. Он выполняет игровую логику и рассчитывает всю важную информацию. С таким подходом у нас получается уже две программы и код в двух местах. Давайте посмотрим, как это будет выглядеть:

Обратите внимание, только сервер и пользователь важны для правильной работы нашей игры, и это дает интересные последствия.

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

Таким образом клиент имеет две задачи:

1. Ввод данных: отправка необходимой информации на сервер, чтобы игра протекала так, как того желает игрок.
2. Вывод данных: получение информации об игре с сервера, чтобы показать игроку, что происходит, и чтобы можно было продолжать играть.

 

Возможно вам показалось это сложным, но на самом деле все проще, чем кажется. Если смотреть с точки программы клиента, то нам фактически ничего не нужно делать ровно до тех пор, пока сервер не сообщит об этом. �?наче мы просто отправляем действия игрока на сервер, когда тот нажимает какие-либо кнопки.

Client-Server архитектура

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

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

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

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

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

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

Теперь давайте еще раз вернемся к примеру с шашками и рассмотрим его с использованием клиент-серверной архитектурой.

�?грок хочет выполнить ход от A2 до C4. Как и прежде он должен отправить следующее сообщение серверу, чтобы сообщить о своих действиях:

connection.send("move", 1, 2, 3, 4);

Отправить сообщение о ходе игрока — это все, что мы должны сделать. Больше ничего не нужно делать, пока не получим от сервера сообщение о том, что ход выполнен.

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

broadcast("move", 1, 2, 3, 4);

Возвращаясь к клиенту: мы получаем сообщение от сервера в котором говорится, что мы должны переместить фишку из клетки (1,2) в клетку (3,4). К счастью, команду сервера мы должны выполнить обязательно, и так же будет каждый раз, когда какой-либо другой игрок сделает свой ход.

Следует придерживаться такого простого правила для каждого хода. Отправили-ждем-действуем — все решения принимает сервер. В таких случаях считается хорошей практикой показывать игроку, что его ход принят и он должен дождаться решения от сервера, чтобы увидеть результат. Не забывайте демонстрировать процесс ожидания решения от сервера, например, показывая классические песочные часы.

В следующей записи мы поговорим более детально о том, как можно реализовать безопасность данных в играх и каким образом мы можем усложнить жизнь хакерам.

Это вольный перевод статьи: «Building Flash Multiplayer Games — Network Architectures»

Содержание

1. Как создать онлайн игру? Анонс
2. Player.IO. Введение
3. Player.IO. Основы или первая онлайн игра
4. Player.IO. Пошаговые игры
5. Player.IO. Сетевые архитектуры
6. Player.IO. Безопасность в онлайн играх
7. Player.IO. Пример пошаговой игры
8. Player.IO. Онлайн игры в реальном времени
9. Player.IO. Синхронизация игроков
10. Player.IO. �?нтерполяция или удивительный мир обмана
11. Player.IO. Решение проблемы задержек
12. Player.IO. Советы и рекомендации