Приветствую, дамы и господа, я вам покушать принес.

Итак, Game Maker networking. Штука эта существует уже приличное время, но, тем не менее, русскоязычных уроков по ней в интернетах по непонятной мне причине не найти.

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

Начну с небольшой теории и терминологии.

В статье, под сервером я буду иметь в виду главную "управляющую" программу(не какой то мифический системный блок, нет нет!). Главная особенность сервера, и почему он нужен - тот кто его разработал, имеет над ним полный контроль. Никакой пользователь не может получить доступ к серверу, и менять по своей прихоти какие либо данные внутри него, в отличии от клиента(за исключением дыр которые допустил сам разработчик, конечно).

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

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

С прелюдией закончил, перейдем к делу. Для начала приведу список того что нам нужно для разработки. В конце статьи приложу исходники сервера\клиента и собранные сервер\клиент, которые можно протестировать у себя. Напомню, что использовать будем исключительно TCP протокол, не будем заниматься никакими оптимизациями и создавать сложных механик.

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

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

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

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

Для того, чтобы создать соединение, нам нужен сокет(socket). Его создает функция network_create_socket. В качестве параметра ей указываем тип соединения, которое наш сокет будет использовать. Далее, клиент осуществляет коннект с сервером с помощью функции network_connect(), один из параметров которой является сокет, созданный в предыдущем шаге, и теперь через него мы можем осуществлять передачу пакетов.

Во время исполнения коннекта на клиенте, на сервере студией генерируется структура, ds_map. Эта структура по сути является списком записей типа(<ключ> <значение>), где ключ - просто строковое значение, а значение - соответственно что угодно другое. Именно через эту самую ds_map с названием async_load и происходит обмен данные по TCP протоколу между сервером и клиентом. Именно в этом и есть основное отличие работы в networking в сравнении с другими популярными онлайн-библиотеками(типа 39dll).

Далее, мы начинаем обмен пакетами между сервером и клиентом. Осуществляется это с помощью записи данных в буфер, и последующей отправкой буфера с помощью network_send_packet(). Но обо всем по порядку.

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

Итак, работаем в 2 окна. Создаем в них по проекту, и называем - 1 сервер, второй - клиент. Начнем с разработки механики клиента.

для начала спрайт игрока. Рисуем какой нибудь спрайтик, или берем готовый, или берем мой красный треугольник. Не забываем задать точку вращения! Для моего спрайта она будет x = 9, y = 15. Создаем объект o_player и obj_othplayers. Все доп флаги(visible, solid) оставляем по умолчанию(для всех будущих объектов тоже не трогаем флаги, они нам незачем). Задаем им наш спрайт. Открываем o_player и создаем в create ему кусок кода, инициируем некоторые переменные:



Эти значения будут нам нужны только для игровой механики, и сеть пока мы никак не затрагиваем. Затем создаем ему же ивент Global left button(не pressed и не released), и записываем



Этот до жути простой код отвечает за движения нашего игрока-треугольника.

Наш игрок готов. Создаем комнату, создаем там игрока. Запускаем, убеждаемся что наш объект следует за мышкой.

Теперь там же, в клиенте, создаем объект(назову его o_netw), который уже будет отвечать за работу с сетью. В create ему запишем следующее:



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

Далее, мы туда же дописываем инициализацию буфера, через который будем отсылать данные на сервер:



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

Так же зададим переменную для того, чтобы не отсылать данные каждый такт:



Ну и последний пункт - инициируем наш массив, в котором будем хранить ссылки на объекты других игроков:



Наш массив будет содержать 10 элементов. Конечно правильней использовать ds_list для таких вещей, но мы обойдемся максимально простыми записями . Опять же, углубляться в лишние проверки для реального ограниченя не будем, так что можете поставить здесь число побольше.

Напомню, что весь этот код должен содержаться в Create объекта o_netw. Не забываем добавить его в игровую комнату.

Итак, первые шаги сделаны. Перейдем к серверу. После этого шага мы уже сможем увидеть наших запущенных клиентов на сервере(но не друг у друга!).

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

Итак, в первую очередь создаем объект o_server. Идем к нему в create и пишем следующий код:



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

Остановимся на минутку. Теперь мы имеем сервер, который ждет клиента, и клиент, который посылает коннект. Базовая связь, ничего лишнего. Чтобы проверить как все работает, нам остался лишь 1 шаг - нужно создать event в проекте-сервере, в объекте o_server. Открываем наш объект, жмем create event - Asyncronous - Networking. Именно через него происходят все обмены данными в GMS networking. Собственно теперь и начинается самое интересное.

итак, создаем код в networking:



Объясню что здесь происходит. Как только сервер улавливает сетевую активность(проще говоря, приходит сообщение), студия генерирует ds_map с названием async_load(то, о чем я писал в начале) и срабатывает ивент networking. Обращаясь к этой структуре, мы сразу забираем основные поля, нужные нам для дальнейшей работы, и созраняем их значения в переменные. Все пакеты мы теперь будем описывать здесь. Собственно, начнем с того что напишем обработку подключения клиента(то что нам сейчас и нужно):



Как видите, все просто. Мы просто создаем в середине экрана объект игрока если type = network_type_connect. network_type_connect - это встроенная константа, она означает что тип пришедшего сообщения - подключение. Помимо этого из нужных нам есть network_type_data, которая обозначает передачу данных - то есть собственно вся наша работа, и network_type_disconnect, означающая отключение клиента.

осталось только создать объект игрока o_player(напомню, в сервере), назначить ему спрайт, создать комнату с o_server внутри - и можно тестировать! Если по каким то причинам приложения не работают - попробуйте поменять 10001 в клиенте и сервере на какое нибудь другое число. Это номер порта, по которому происходит связь наших приложений. Про доступные порты можете поискать в гугле, но в принципе можно использовать практически любой число до 65536(если мне не изменяет память ).

Порядок теста - запускаем сервер, запускаем клиент. После запуска клиента в окне сервера должен появиться наш игрок. Если появился - значит все прошло как нало, если не появился - сверяйтесь с уроком, если зависло окно клиента - значит проблема с соединением. Меняйте номер порта, или опять же сверяйтесь с уроком. Имейте ввиду, что для гарантии работы IP должен быть тот что стоит по умолчанию - 127.0.0.1.

Окей, предположим что все хорошо и работает. Теперь научим наш объект двигаться!

Для этого нам просто нужно передать координаты на сервер, а на самом сервере - присвоить принятые координаты к объекту игрока. Обо всем по порядку. Возвращаемся к нашему окну клиента. Открываем объект o_netw, создаем ему step event. Пишем:



Разбираем написанное. Переменная delay отвечает за то, чтобы мы не перегружали сеть лишними данными. Благодаря ей, данные будут передаваться раз в 3 такта игры. Итак, если мы передаем данные(delay > 2) тогда обнуляем переменную. С помощью buffer_seek мы чистим буфер, для того чтобы там не было ненужного мусора. Это очень важно! Если мы не очистим буфер, тогда предыдущее и текущее сообщение перепутаются, и последствия могут быть самыми неожиданными. Поэтому перед формированием любого сообщения, в первую очередь выполняем buffer_seek. Константа buffer_seek_start в качестве параметра означает, что мы сбрасываем указатель записи на старт, а все "ячейки" буфера примут значение "0"(последний параметр). Функция - аналог функции 39dll_buffer_clear() из 39.dll.

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

Теперь идем в проект сервера. Нам нужно описать прием данных. Идем в event Networking в obj_server и немного модернизируем наш код в нем. А именно, дописываем в конец:



В принципе, ничего сложного в этом коде нет. Единственный момент, который нужно здесь запомнить - eventid - это идентификатор отправителя. Этот идентификатор приходит в переменную sock при коннекте клиента(смотри часть когда type = network_type_connect). В остальном - все легко и просто. Можно тестировать

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

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



Это наша заглушка, означающая что игрок только только подключился и пока не проявил активности. Теперь залезем в o_server и добавим в конец create еще 1 строку:



Эта переменная будет содержать в себе максимальный индекс подключенного клиента в массиве игроков. Говоря проще, нам незачем проверять все 10 элементов массива, если у нас подключено только 2 игрока, и эта переменная нам поможет.

Теперь нам понадобятся 2 скрипта, которые мы должны создать на сервере. Итак, создадим их.

Первый скрипт будет называться send_to_all_except_one_tcp. Создаем его и пишем в нем код:



Этот скрипт позволяет нам отослать сообщение, предварительно записанное в buffer_send всем игрокам, кроме того что указан в аргументе. Ничего сложного, если вдуматься.

Второй скрипт будет называться send_starting_info. Вот его код:



Этот скрипт формирует и отсылает нашему новому игроку данные обо всех игроках, которые уже на сервере.

Теперь нам нужно слегка модифицировать o_server в проекте сервера.

Ищем в его Networking строки



и меняем их на



Теперь при подключении к серверу нового клиента, все остальные клиенты будут об этом оповещены.



и заменяем их на



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

buffer_write(buffer_send, buffer_s16, eventid );
buffer_write(buffer_send, buffer_s16, 1 );

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

туда же, добавялем в конец строки:



Это обработка отключения игрока. Если к нам пришло сообщение с типом disconnect(оно автоматически генерируется например при закрытии окна с клиентом) - удаляем его объект с сервера, освобождаем его место в массиве игроков, и рассылаем всем игрокам сообщение о том, что наш клиент уехал к родственникам в Совнгард. Обратите внимание на то, что здесь в качестве идентификатора используется снова sock а не eventid.

Теперь нам нужно только добавить возможность клиентам понимать приходящие пакеты. Открываем проект-клиент, лезем в объект o_netw и создаем ему event Networking, как мы уже делали раньше для o_server.

Создаем в нем кусок кода, и пишем:



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

Вот собственно и все. теперь можете запустить свой проект и убедиться, что игроки стали видеть друг друга, что они могут появляться и исчезать, и все это ужасно дергано :)