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

[澤橋辰典・武上将樹，ITmedia]

第8回　90xiアプリのこれから 第7回　ネットワークiアプリのためのサーバサイド活用（2） 第6回　ネットワークiアプリのためのサーバサイド活用（1） 第5回　 スクラッチパッドへのデータ保存とダウンロードファイルの処理 第4回　カメラ機能を使ってカードを作ろう 第3回　簡単なゲーム作成の流れを身に付ける 第2回　カードゲームをつくってみよう 第1回　90xiの時代に何を作るか

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

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

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

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

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

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

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

CREATE TABLE waiting ( 　　　　#待合ID 　　　　waiting_id　　　INTEGER PRIMARY KEY AUTO_INCREMENT, 　　　　#ユーザーID 　　user_id　　　　　　INTEGER , 　　　　#対戦ID 　　　　duel_id　　　　INTEGER DEFAULT 0, 　　　　#登録時間 　　　　ins_date 　　　　TIMESTAMP, 　　　　INDEX(user_id) ) CREATE TABLE duel ( 　　　　#対戦ID 　　　　duel_id　　　INTEGER, 　　　　#ユーザーID 　　　　user_id　　　INTEGER, 　　　　#ターン番号 　　　　turn　　　　　　INTEGER DEFAULT 0, 　　　　#カードNO. 　　　　card　　　　　　INTEGER DEFAULT -1, 　　　　INDEX(user_id) );

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

1. 対戦相手検索

2. ネットワーク対戦

3. ゲーム終了処理

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