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

1. Bluetooth - наиболее удобный для игр способ соединения устройств. Большинство новых телефонов имеют Bluetooth адаптеры.
2. TCP/IP sockets - Вы можете соединиться через интернет, используя GPRS. Этим способом не всегда удается соединить устройства напрямую. Предпочтительней создать web сервер, к которому будут подключаться пользователи.
3. IrDA - это худший вариант, поскольку соединение очень чувствительно к взаимному нацеливанию устройств и расстоянию между ними. В последнее время IrDA вытесняется Bluetooth. Многие новые телефоны вообще не имеют инфракрасного порта.

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

Разработка среды коммуникации (Communication Framework)

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

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

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

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

• Устройство 1 шлет данные Устройству 2 отдельным блоком.
• Устройство 2 шлет данные Устройству 1 отдельным блоком. (Это может быть ответ на сообщение первого устройства, а может и не быть. Устройство 1 не ждет ответа от второго устройства - оно просто как-то реагирует на полученный блок информации.)

Игровой движок для взаимодействия с сетью использует Контроллер. Взаимодействие между Контроллером и движком обычно реализуется через callback механизм. Controller должен предоставить простой интерфейс и пользователю не обязательно обладать какими-либо знаниями о его внутренней работе. В случае использования Bluetooth и IrDA, достаточно использовать только четыре метода.

• CmyController::SeekDevices: Ищет доступные Bluetooth/IrDA устройства и возвращает список доступных устройств.
• CmyController::ConnectToDevice: Соединяется с полученными устройствами и уведомляет движок об успешности соединения.
• CmyController::SendMessage: посылает сообщение устройству, с которым была установлена связь.
• CmyController::Disconnect: разрывает соединение с устройством.

При использовании TCP/IP SeekDevices не требуется, а в остальном структура Контроллера такая же.

Все приведенные выше методы, за исключением Disconnect, являются асинхронными и Контроллер передает результат своей работы движку через callback:

• MmyController::Event: это уведомление позволяет передавать сообщение об ошибке (если соединение сорвалось) либо просто информировать о попытке соединения. Контроллер должен сам позаботиться об обработке ошибок, поэтому это сообщение носит чисто информативный характер. В идеале движок должен знать как можно меньше о тонкостях работы с сетью.
• MmyController::MessageReceived: это сообщение, полученное от удаленного устройства (например, статус игры). Сообщение обрабатывается контроллером, а затем передается игровому движку.

Я не буду приводить пример работы с сетью, поскольку это лежит за рамками данного документа. Скажу только, что Bluetooth, IrDA и TCP/IP можно использовать через Sockets Client API (Rsocket):

• Bluetooth sockets API реализует соединение через уровни L2CAP и RFCOMM, а также позволяет осуществлять поиск Bluetooth устройств.
• IrDA sockets API, с протоколами IrMUX и IrTinyTP. Используя IAS, Вы без труда сможете связаться с устройствами, работающими под управлением Windows OS.
• TCP/IP sockets позволяют работать с доменными именами, Ipv4 и Ipv6 (для Series 60 Developer Platform 2.0).

Вы можете использовать, например, IrDA serial API через Comms Server, но это достаточно сложно. При использовании общих Sockets API проще реализовать поддержку приложением разных способов коммуникации. К примеру, для того чтобы перейти от Bluetooth к TCP/IP потребуется незначительная модификация кода.

Получение игровых данных

Иногда бывает необходимо, например, обновить игру или добавить новый уровень после того как игра проинсталлирована. Необходимые данные можно прикрепить к Email письму, передать через IrDA или с помощью MMS. Series 60 позволяет зарегистрировать типы файлов, так что полученные файлы будут автоматически копироваться в требуемую папку, где игра сможет найти их.

Чтобы позволить игре получать дополнительные данные Series 60 Developer Platform позволяет ей зарегистрировать в системе собственный формат файла, на основе Multipurpose Internet Mail Extensions (MIME). Тип MIME обычно используется приложениями, работающими с коммуникационными возможностями устройства (например, WML браузер или ICQ клиент). Это позволяет им легко находить сохраненные файлы. Думаю вам не надо говорить, что в таком файле можно передать новый уровень для игры, оружие, графику и т.д.

В Series 60 внутри MIME находятся данные в форматеapplication/x-NokiaGameData-<APPLICATION-ID>, где <APPLICATION-ID> - это последние восемь знаков UID вашего Symbian OS приложения. MIME тип объявляется внутри информационного файла Symbian OS приложения (*.aif) (Более подробно об этом будет рассказано в следующей части)

RESOURCE AIF_DATA
{
app_uid=0x12345678;// UID приложения
datatype_list=
{
DATATYPE
{
priority= EdataTypePriorityHigh;
type= “application/x-NokiaGame-Data-12345678”;
}
};
}

Параметр priority структуры DATATYPE определяет приоритет важности этих данных для приложения. EdataTypePriorityHigh говорит о том, что другие приложения не имеют права управлять данными этого типа.

Параметр-путь, где нужно разместить полученные файлы определяется в файле с именем <APPLICATION-ID>.ini. Этот файл должен иметь Unicode кодировку и содержать строку SDDataDir=<GAME-PATH>, где <GAME-PATH> - путь куда нужно помещать полученные файлы. Этот путь указывается относительно папки приложения. При инсталляции игры ini файл нужно скопировать в папку \System\SharedData. Это легко можно сделать, задав путь в pkg файле игры.

Series 60 Developer Platform определяет стандартную структуру заголовка для игровых файлов данных, которой нужно придерживаться. Структура проиллюстрирована ниже. ПолеData type можно использовать для внутреннего разделения типов игрового файла.Name - строка в формате Unicode, которую можно поместить в меню, чтобы дать пользователю возможность управлять файлами.Data ID иData version - уникальные номера, определяющие тип и версию данных. ПолеNGDX должно содержать ASCII строку “NGDX.”

Перевод:aRix