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

• 差分^[1] を表示
• 現在との差分^[2] を表示
• バックアップ No.2 を復元して編集^[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とパスワードとゲームのデータを保存します。

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

準備中

• 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 njf^[9]
  • 3: 2015-07-02 (木) 14:45:17^[10] 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]