Уже написано немало интересных игр для мобильных телефонов. К сожалению, большинство из них рассчитаны на одного игрока, а между тем, мобильные телефоны являются великолепной платформой для многопользовательских приложений.
В этой статье в обзорной форме рассказывается о технологиях, которые может использовать разработчик при написании многопользовательских MIDP игр.
Предполагается, что читатель знаком с языком Java и основами MIDP программирования.
Этот подход можно использовать в пошаговых многопользовательских играх. Он заключается в том, что сделав свой ход, игрок передает телефон другому игроку.
HTTP поддерживается всеми MIDP телефонами. Фактически MIDLet-ы могут работать как Web браузеры. Они посылают запросы HTTP серверу, и получают от них HTTP ответ. К сожалению, это все, что может сделать MIDLet. Некоторые разработчики допускают ошибки, пытаясь использовать возможности Internet реализации HTTP, которые обычно не поддерживаются мобильными сетями:
HTTP сервер не имеет возможности инициировать соединение с клиентом, поэтому Ваш MIDlet должен периодически посылать запросы на сервер и следить, не изменилась ли игровая обстановка. Использование HTTP протокола в играх стоит довольно дешево, объемы передаваемых данных, как правило, не велики, а цена за килобайт информации не так уж высока.
MIDP 1.0 не поддерживает никакие другие протоколы кроме HTTP, однако некоторые производители телефонов включают поддержку TCP сокетов. Вы можете использовать их, если уверены, что ваше приложение не будет запускаться на других устройствах.
HTTPS – это защищенный HTTP протокол. Он широко используется в электронной коммерции.
Transmission Control Protocol (TCP) является одним из базовых протоколов сети Интернет. Протокол TCP обеспечивает надежную передачу данных:
Наиболее близкая аналогия соединения по TCP протоколу – разговор по телефону. Интернет реализация протокола HTTP строится именно на этом протоколе.
Понятие «сокет» («socket») обозначает один из концов TCP соединения. «Server socket» на TCP сервере принимает запросы на новые соединения и создает сокет для каждого из них.
Надежность TCP значительно упрощает разработку программ, однако при работе в ненадежных сетях протокол TCP работает намного хуже, чем User Datagram Protocol (UDP, см. ниже). В случае потери пакета, TCP пытается послать его повторно. Все последующие пакеты не посылаются, пока не будет получено подтверждение удачной передачи потерянного пакета. Если Вам не требуется такая надежность, имеет смысл использовать более быстрый протокол UDP.
MIDP 1.0 вообще не поддерживает TCP. В MIDP 2.0 регламентируется поддержка TCP, но она идет как дополнительная возможность, и производители оборудования сами решают, включать ли ее.
Помимо TCP в сети Интернет очень часто используется протокол UDP. UDP – пакетно-ориентированный протокол, не обеспечивающий надежную передачу данных. Другими словами:
В качестве аналогии связи по UDP можно привести отправку писем (бумажных через почту :) ). Термин «датаграмма» (datagram) обозначает пакет данных.
UDP наиболее эффективная и быстрая технология передачи данных. Многие приложения не требуют надежности, обеспечиваемой TCP. Например, когда данные чувствительны ко времени. При передаче потока видео данных гораздо лучше потерять один кадр, чем затормозить всю передачу, но получить все кадры.
Вопрос о том, какой из протоколов нужно использовать в играх, широко обсуждается в сети. Специфика мобильной сети еще более усугубляет различия между протоколами.
Существует два решения:
Когда передача пакетов реализуется на основе GPRS, использование UDP для передачи небольших объемов данных оказывается очень дешевым и эффективным решением. Игры обычно не требуют передачи больших объемов данных, однако частота передачи может составлять до одного пакета в секунду. Если Ваше приложение использует частую передачу данных, обратите особое внимание на размер пакетов.
MIDP 1.0 вообще не поддерживает UDP. В MIDP 2.0 регламентируется поддержка UDP, но она идет как дополнительная возможность, и производители оборудования сами решают, включать ли ее.
Последовательный кабель можно использовать для соединения близко расположенных телефонов.
В MIDP 2.0 работа с последовательным кабелем осуществляется через интерфейсSerialPortConnection. На момент написания статьи этот интерфейс не поддерживался телефонами Nokia, поэтому мы не будем рассматривать работу с этим интерфейсом
С помощью IrDA можно соединить два расположенных близко телефона. Телефоны должны быть фиксированы друг относительно друга для обеспечения визуального канала. Поскольку инфракрасный порт может быть расположен в любом месте телефона, иногда совсем непросто найти удобное положение для игры.
В MIDP 2.0 работа с инфракрасным портом осуществляется через интерфейсSerialPortConnection. На момент написания статьи этот интерфейс не поддерживался телефонами Nokia, поэтому мы не будем рассматривать работу с этим интерфейсом.
MIDP коммуникационные возможности, реализуемые через «дополнительные пакеты»
MIDP 1.0 и 2.0 телефоны могут поддерживать некоторые дополнительные коммуникационные возможности. Давайте рассмотрим наиболее распространенные из них.
Bluetooth – это технология передачи данных на небольшие расстояния (порядка десяти метров) по радио каналу. Благодаря надежности и быстроте передачи данных, эта технология широко используется в многопользовательских играх. Телефоны не нужно ориентировать друг относительно друга. Передача данных осуществляется во всех направлениях.
В MIDP телефонах Bluetooth можно использовать с помощью дополнительного пакета Java APIs for Bluetooth [JSR-82]. Более подробную информацию об его использовании можно получить здесь:http://www.mobilab.ru/articles/63/ .
Технология Short Message Service (SMS) позволяет посылать короткие сообщения на другой телефон или на какой-нибудь сервер. Всем известно, что с помощью SMS можно посылать текстовые сообщения, однако эта технология поддерживает и передачу бинарных данных (например, рингтонов или игровых данных). SMS работает по схеме сохранил-передал, то есть все сообщения поступают в Short Message Service Center (SMSC), где они сохраняются, а затем передаются конечному адресату. В случае если адресат включен и доступен, а SMSC не перегружен, передача SMS занимает несколько секунд. В менее благоприятных условиях, сообщения могут запоздать на день или не прийти вообще.
В MIDP телефонах поддержка SMS реализуется через дополнительный пакет Wireless Messaging API [JSR-120]. На момент написания статьи пакет поддерживался не всеми телефонами. Более подробную информацию об использовании SMS можно найти здесь:http://www.mobilab.ru/articles/12/.
Если Вы собираетесь использовать SMS в игре, помните, что каждое SMS сообщение стоит денег. Вряд ли пользователь будет в восторге, если через пол часа игры у него кончатся все деньги на счете.
MMS это улучшенная версия SMS. Она позволяет посылать сообщения, состоящие из нескольких частей: текста, рисунков, звука и видео. Как и SMS, MMS работает по принципу сохранил-передал.
В основе MMS лежит сочетание технологий SMS и HTTP. Для игр имеет смысл использовать SMS и HTTP, а не связываться с MMS, поскольку не все телефоны поддерживают эту технологию.
В MIDP телефонах поддержка MMS реализуется через дополнительный пакет Wireless Messaging API 2.0 [JSR-205].
На стороне сервера Вы можете использовать любые технологии, поддерживающие работу с HTTP, например CGI, ASP, PHP, Java servlet, JSP. Java разработчики обычно используют java servlet-ы. Для того чтобы сервер мог с ними работать, можно установить бесплатный Apache Tomcat сервер.
Более подробно о написании java serclet-а и MIDlet-а для работы с ним рассказано здесь:http://www.mobilab.ru/articles/8/.
В момент написания статьи платформа Java 2 не имела готовой модели, позволяющей servlet-ам работать с TCP и UDP протоколами. Так что если вы решите писать серверное приложение на Java, вам придется либо писать собственную реализацию работы с этими протоколами, либо использовать коммерческие решения.
С другой стороны, такие языки как C++ и Delphi позволяют очень просто и быстро написать приложения, работающие с TCP и UDP протоколами.
Написанию SMS и MMS серверных приложений посвящен раздел Messaging форума Nokia (http://www.forum.nokia.com/messaging ) Кроме того, многие фирмы предлагают свои серверные решения для этих технологий.
Mobile Games Interoperability Forum (MGIF), входящий в настоящее время в Open Mobile Alliance's (OMA's) Game Services Working Group, опубликовал спецификацию стандарта для игровых серверов, названную MGIF Platform Specification [MGIF-SPEC]. MGIF-SPEC включает поддержку SMS и MMS. К сожалению, на момент написания статьи не было доступно ни одной реализации этой спецификации.
Этот краткий обзор видов многопользовательских игр основан на материале документа «Introduction to Mobile Game Development» с сайтаhttp://www.forum.nokia.com. Мы постарались проанализировать и подобрать наиболее подходящую коммуникационную технологию для каждого вида игры.
Игра состоит из отдельных раундов. Каждый раунд играет один игрок, затем сравниваются результаты раундов (очки, время). Фактически в самой игре не реализована многопользовательность. Она нужна только во время сравнения результатов. Очевидно, что для игр данного типа скорость соединения не играет никакого значения.
Удачным решением будет использование протокола HTTP и сервера для сохранения результатов. Однако помните, что сервер не может связаться с вашим телефоном и сообщить, что все участники закончили игру. Ваша игра должна сама периодически обращаться к серверу с запросом: «а не закончили ли игру другие игроки?». В MIDP 2.0 эта проблема может быть решена с помощью TCP (После установки TCP соединения сервер в любое время может послать сообщение клиенту).
В пошаговых играх все игроки ходят по очереди.
К этому виду относятся такие известные игры, как шахматы, покер, бридж. Самый простой (но не самый хороший) способ – использовать один телефон и передавать его после хода другому игроку.
В MIDP 1.0 можно использовать HTTP, однако тут опять всплывает существенный недостаток: сервер не может сообщить клиенту, что ход сделан. Во время ожидания своего хода игрок должен видеть соответствующий индикатор (например, текстовое сообщение «ходит другой игрок») и иметь возможность разорвать связь и выйти из игры.
Неплохим вариантом является использование SMS, но позаботьтесь о том, чтобы игрок понимал, что каждый его ход стоит реальных денег.
Лучшим вариантом является разработка игры под MIDP 2.0 и использование TCP. Для игр этого типа также не критична скорость соединения, но важна правильность передаваемой информации.
Все игроки делают ходы одновременно, в конце раунда сравниваются результаты действия. Наиболее известной игрой данного типа является «камень, ножницы, бумага».
На самом деле, программирование этих игр практически не отличается от программирования пошаговых. Все изложенные соображения для пошаговых игр справедливы и для игр данного вида.
Это долго длящиеся игры (день, неделя, месяц, вечность). Пользователь может в любое время подключиться к игре и совершить какое-нибудь действие.
Если это не real-time игра, удачным решением будет использование HTTP. Если игра подразумевает передачу небольшого объема данных, можно использовать SMS.
Для real-time игры оптимальным решением будет использование TCP, UDP или их комбинации. Не забывайте о том, что скорость передачи данных в мобильных сетях все еще не достаточна для быстро протекающих real-time игр (например, для гонок, шутеров)
Это подвид игр с «действием в произвольное время». Пользователь может действовать в любое время, запустив игру. «Агент» игрока продолжает жить в игровом мире, даже когда игрок отсоединен от игры. Запустив игру, игрок может, например, проверить состояние своего государства, издать указы, изменить налоги, и отсоединиться, а его виртуальное государство будет жить дальше, учитывая сделанные пользователем изменения.
Удачным решением для данного типа игр является HTTP, поскольку скорость связи и отклика не критична.
Для этих игр очень важна скорость передачи информации, поэтому наилучшим вариантом будет использование Bluetooth или последовательного кабеля. Последний способ имеет существенные недостатки: Вы можете соединить только два телефона; Вы должны иметь кабель, подходящий к телефонам данной модели.
В зависимости от используемой вами бизнес модели, вы можете захотеть выделить каждому пользователю персональную учетную запись. Чтобы упростить процесс включения в игру новых пользователей, позвольте им регистрироваться прямо из вашей игры. Имя пользователя и пароль можно сохранить в телефоне, используя Record Management System (RMS)http://www.mobilab.ru/articles/40/ . Однако, пользователи должны иметь возможность менять учетную запись и пароль, не забудьте об этом.
Данные пользователя можно хранить не сервере или в памяти телефона RMS. В последнем случае при смене телефона пользователь потеряет все данные.
Подключившись к серверу, пользователь должен иметь возможность получить информацию о других пользователях, чтобы начать приватную игру или решить, хочет ли он сейчас подключиться к игре.
Многие игры имеют таблицы рекордов. Они должны храниться на сервере. Имеет смысл использовать таблицы рекордов, если Ваши пользователи имеют постоянные учетные записи.
Для повышения интереса к таблице рекордов подводите итоги по результатам дня. Таким образом, больше игроков смогут увидеть свое имя в списке.
Как правило, пользователи хотят обмениваться в процессе игры короткими сообщениями. Используйте высокоуровневые классы пользовательского интерфейса (TextField или TextArea). Не пытайтесь написать собственную реализацию, это плохо скажется на переносимости игры.
Неплохим решением будет отображать каким-либо образом информацию о текущей скорости обмена данных и состоянии соединения.
В основе статьи лежат материалы сайтаwww.forum.nokia.com.
Перевод:aRix.
