第7回　ネットワークiアプリのためのサーバサイド活用（2）：90Xi専用ゲームiアプリ開発講座（1/4 ページ）

��8��@90xi�A�v���̂��ꂩ�� ��7��@�l�b�g���[�Ni�A�v���̂��߂̃T�[�o�T�C�h���p�i2�j ��6��@�l�b�g���[�Ni�A�v���̂��߂̃T�[�o�T�C�h���p�i1�j ��5��@ �X�N���b�`�p�b�h�ւ̃f�[�^�ۑ��ƃ_�E�����[�h�t�@�C���̏��� ��4��@�J�����@�\���g���ăJ�[�h����낤 ��3��@�ȒP�ȃQ�[���쐬�̗����g�ɕt���� ��2��@�J�[�h�Q�[�����‚����Ă݂悤 ��1��@90xi�̎���ɉ�����邩

　前回はネットワーク対戦iアプリを実現するために不可欠なサーバ環境の構築から、ダウンロード前のユーザー情報格納の遷移までを解説した（11月22日の記事参照）。今回は、まずアプリとサーバ間のやりとりについて考えていくうえで何が重要となるかについて検討し、それに基づいて、インタフェース部分の設計と、アプリ・サーバそれぞれの実装を行っていく。

アプリ・サーバ間通信で重要なこと

　確かに現状の900iユーザーは、非常に割安なプランでパケットを使っている。そのため多少のパケット数の増加を厭わないかもしれない。しかし、手頃なレンタルサーバなどでネットワーク対戦アプリを運用したいと考えている開発者にとっては、転送量の増加は非常に深刻な問題だろう。あまりパケット数が増えすぎると、安価なサーバでは負荷に耐えられなくなってしまう可能性がある。そこで、通信量・通信回数は必要最小限に絞らなくてはならない。

　また、携帯電話の場合、ユーザーが突然電波の届きにくい場所に入ってしまうこともよくある。アプリ使用中に電波が届かなくなったユーザーをどう処理するかも念頭に置いておかなければならない。この点に関して今回は、通信の戻り時間に制限を設けることで、電波が届かなくなり、一定時間の間に通信が戻ってこなかったユーザーは負けにすることとした。

アプリとサーバの間のインタフェース設計

　まず必要なものは、複数のアプリのセッション情報を格納するためのデータベースだ。前回作成したUSERテーブルに加えて、対戦を待っているユーザーの情報を格納するWAITINGテーブルと、対戦中のカードの値や、ターン数などを一時的に格納しておく、DUELテーブルを用意する。

　テーブルの構造をSQL文で表すと以下のようになる。

AMP 非対応のコンテンツです。こちらからご覧ください。

　また、アプリとサーバの通信は、以下のように流れていく。

1. 対戦相手検索

2. ネットワーク対戦

3. ゲーム終了処理

　上記の流れを踏まえながら、それぞれに応じて、アプリからどのようなデータが送られ、どのように処理を行い、どのような値を返すのかについて、仕様を解説していく。