Google App Engine for Python　その２ のバックアップソース(No.3) :: NJF Wiki

• 差分^[1] を表示
• 現在との差分^[2] を表示
• バックアップ No.3 を復元して編集^[3]
• Google App Engine for Python　その２^[4] へ行く。

前の記事はこちら。[[Google App Engine for Python]]

*ブラウザ上のカジュアルゲームデータの保存の概要 [#u36cbcbd]

Flashで動作するゲームのユーザーデータは以前はSharedObjectで保存できましたが、セキュリティなどの問題から現在はSharedObjectはデフォルトでは定期的に消えるようになりました。

そこで、サーバー上で保存するわけですが、そのために必要なデータは最低限以下の物が必要です。

-ユーザーIDとパスワード
-ゲームデータ

ユーザーIDとパスワードはユーザーを区別するために必要です。メールアドレスや他のサービスのオープンIDを使ってパスワード忘れ対策などを行うと良いかも知れませんが、カジュアルゲーム程度でメールアドレスや他サービスのIDを必要とすると、ユーザーがいやがる場合があります。また、そこまでしても特に個人情報などの重要データがあるわけでも無くそもそもセキュリティ的なリスクはありません。さらにほとんどのユーザーは一通りゲームをプレイすると再び同じゲームをプレイすることはなく、SharedObjectが消える期間を超えてプレイする人は少数派です。どの程度まで実装するかは微妙なところです。

ここでは最も簡単な、サーバー側でIDとパスワードを発行してユーザー側でメモしてもらう方法をとります。パスワード変更処理やパスワード忘れ処理は無しにします。IDは通番にし、パスワードはランダムな整数にします。

ゲームデータはjson形式で送ることにします。FlashだとAMFという優れたデータシリアライズ方法があり、GAEでも利用できるのですが、Flash以外ではそのままでは使えないという欠点があります。たとえばアプリ版は他の言語で作る必要が出たときに面倒なことになります。Flashがだんだんと使われなくなってきている状況を鑑みて、汎用性からjsonでやり取りすることにします。XMLでも良いです。ただjsonだと数値や論理型が型付きで送れたり大抵データの容量が少なくなるので私はこちらを使っています。また、GAEにはjsonデータをそのまま保存するデータ型が用意されているのでこちらの方が便利です。

GAEのデータ設計において注意しないといけないのは、１レコード読み込みあたりに課金されると言うことです。また、複数レコードを読み込むと処理も重くなります。よって一度の処理で読み込むレコード数は少ない方が望ましいことから、１ユーザー１レコードが理想です。通常のリレーショナルデータベースとは異なり、なるべく正規化はしないようにしましょう。

すると必要なテーブルは次の二つです。

-ユーザーID
-ユーザーデータ

ユーザーIDテーブルの方では通番のユーザーIDを作成するために最後のユーザーIDを保存しておきます。
ユーザーデータの方はユーザーIDとパスワードとゲームのデータを保存します。
*処理の流れ [#z08eead8]
全体の処理の流れは以下の通りです。

**登録処理 [#n8d8c653]
+ユーザーが新規登録を選んだ場合、サーバーで登録処理を行う
+サーバーから戻されたIDとパスワードをSharedObjectで保存する

**ログイン処理 [#vfb97bf8]
+ShareObjectでローカルにIDとパスワードが保存されている場合や、ユーザーが手動でIDとパスワードを入力した場合、サーバーでログイン処理を行う
+サーバーから戻されたゲームデータでゲームを開始する
+ユーザーがIDとパスワードを入力していた場合は、それをSharedObjectに保存しておく

**データの保存 [#n64bc982]
+IDとパスワードとゲームデータをサーバーへ送信する
+サーバーではデータの整合性をチェックし、保存して結果を戻す


よって、ゲーム側には新規登録画面、ユーザーIDとパスワードを表示する画面、ユーザーIDとパスワードを入力してログインする画面が最低限必要です。もちろん、エラー表示画面なども必要に応じて作成します。

また、サーバー側には登録処理、ログイン処理、セーブ処理をするAPIが必要です。

*フレームワークの導入 [#w185f5fa]

HTMLの入出力部分などを自分で一から作るのは面倒なので、GAEで用意されているフレームワークを使います。いろいろな物が用意されていますが、ここではwebapp2を使います。これを選んだのにはそれほど深い意味はありません。Googleの公式チュートリアルでこれが採用されていて資料が見つかりやすいのが理由です。ゲームデータを保存するだけで実際のWebページを作成するわけでは無いので、フレームワークについてはどれを使ってもそれほど差は出ないと思います。

これを使って前回の記事で作ったHello Worldを作り直すと以下のようになります。

準備中

• Google App Engine for Python　その２ のバックアップ一覧^[7]
• Google App Engine for Python　その２ のバックアップソース(No. All)
  • 1: 2015-07-01 (水) 08:09:21^[8] njf^[9]
  • 2: 2015-07-01 (水) 08:47:37^[10] njf^[9]
  • 3: 2015-07-02 (木) 14:45:17 njf^[9]
  • 4: 2015-07-13 (月) 06:40:05^[11] njf^[9]
  • 5: 2015-07-14 (火) 10:19:20^[12] njf^[9]
  • 6: 2015-07-15 (水) 18:46:46^[13] njf^[9]
  • 7: 2015-07-20 (月) 17:01:01^[14] njf^[9]
  • 8: 2015-07-31 (金) 17:50:04^[15] njf^[9]
  • 9: 2015-08-01 (土) 17:31:58^[16] njf^[9]
  • 10: 2015-08-10 (月) 10:06:08^[17] njf^[9]
  • 現: 2015-08-15 (土) 16:34:45^[18] njf^[9]