Игровой движок : Сеть

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

Играть по сети можно разными вариантами: bluetooth, локальная сеть и интернет. Вариант bluetooth рассматривать не будем, он подходит для игры между 2-я устройствами. Особый интерес это локальная сеть и интернет.

Существует сервер который хранит состоянии игры и игроков и общается с игроками, передает данные. Для карточных и игр в слова не требуется быстрого обмена данных и проблем передачи данных стоит не так остро, как если бы игра была сетевая игра по типу Counter Strike.

Есть несколько вариантов обмена и хранения данных состояния. К примеру клиент (игра) передает свое состояние серверу - я нахожусь здесь, у меня столько то патронов и жизни. А сервер полностью доверяет ему и просто сохраняет и отправляет другим участникам игры. При таком варианте появляется такое явление как читеры. Такие пользователи могут передать 100 жизней, подкрутить значение в памяти игры и уже у них будет 1000 жизней. Доверчивый сервер проглотит это значение и уже будет неравный бой в игре. Могут быть написаны боты, которые повторяют игрока и будут читерить без участия в игре. В современных играх используется другой вариант взаимодействия сервера и клиентов, в котором игрок сообщает только изменения своих данных, а сервер уже решает и проверяет полученные данные. Такой сервер называется "авторитарным сервером".

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

Протоколы обмена

Как известно существует несколько протоколов передачи данных по сети. Одними из нужных нам - UDP и TCP. Первый не гарантирует доставку данных, второй же напротив - гарантирует, что данные придут в нужном порядке и с определенным размером. Протокол TCP требует подготовку к обмену - подключение. После того как сервер и клиент пожмут друг другу руки - можно обмениваться данными. Если произойдет ошибка данных или интернет пропадет на некоторое время, нужно будет переподключиться. Для игр, которые не требуют быстрой отзывчивости и динамичного обмена TCP вполне подойдет для решения сетевого взаимодействия. Если же игры имеют очень динамичный обмен - нам больше подойдет UDP протокол. Данный протокол не требует момента соединения и не гарантирует доставку сообщений. Т.е. по пути к серверу пакет может потеряться, но сам обмен происходит быстрее, т.к. не требует подключения. Данный протокол требует более разумного решения в плане архитектуры, но позволяет достичь нужного эффекта. Сам момент доставки и проверка доставки лежит на плечах разработчика и не гарантируется сетью, поэтому отправка может повторится для нужного пакета, если он не дошел. Весь обмен данных происходит через сокеты - каналы данных. Сокеты доступны во всех современных ОС и языках программирования. В основном сервера для игр пишут на C++, C Sharp и Java. Разработка сетевых приложений сложное и интересное занятие, которое требует наличия опыта и определенных знаний.

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

9090 показов
593593 открытия
Начать дискуссию