ページへ戻る
− Links
印刷
Google App Engine for Python その2
の編集 ::
NJF Wiki
xpwiki
:
Google App Engine for Python その2
の編集
# u36cbcbd の編集
ページ内容:
*ブラウザ上のカジュアルゲームデータの保存の概要 [#u36cbcbd] Flashで動作するゲームのユーザーデータは以前はSharedObjectで保存できましたが、セキュリティなどの問題から現在はSharedObjectはデフォルトでは定期的に消えるようになりました。 そこで、サーバー上で保存するわけですが、そのために必要なデータは最低限以下の物が必要です。 -ユーザーIDとパスワード -ゲームデータ ユーザーIDとパスワードはユーザーを区別するために必要です。メールアドレスや他のサービスのオープンIDを使ってパスワード忘れ対策などを行うと良いかも知れませんが、カジュアルゲーム程度でメールアドレスや他サービスのIDを必要とすると、ユーザーがいやがる場合があります。また、そこまでしても特に個人情報などの重要データがあるわけでも無くそもそもセキュリティ的なリスクはありません。さらにほとんどのユーザーは一通りゲームをプレイすると再び同じゲームをプレイすることはなく、SharedObjectが消える期間を超えてプレイする人は少数派です。どの程度まで実装するかは微妙なところです。 ここでは最も簡単な、サーバー側でIDとパスワードを発行してユーザー側でメモしてもらう方法をとります。パスワード変更処理やパスワード忘れ処理は無しにします。IDは通番にし、パスワードはランダムな整数にします。 ゲームデータはjson形式で送ることにします。FlashだとAMFという優れたデータシリアライズ方法があり、GAEでも利用できるのですが、Flash以外ではそのままでは使えないという欠点があります。たとえばアプリ版は他の言語で作る必要が出たときに面倒なことになります。Flashがだんだんと使われなくなってきている状況を鑑みて、汎用性からjsonでやり取りすることにします。XMLでも良いです。ただjsonだと数値や論理型が型付きで送れたり大抵データの容量が少なくなるので私はこちらを使っています。また、GAEにはjsonデータをそのまま保存するデータ型が用意されているのでこちらの方が便利です。 GAEのデータ設計において注意しないといけないのは、1レコード読み込みあたりに課金されると言うことです。また、複数レコードを読み込むと処理も重くなります。よって一度の処理で読み込むレコード数は少ない方が望ましいことから、1ユーザー1レコードが理想です。通常のリレーショナルデータベースとは異なり、なるべく正規化はしないようにしましょう。 すると必要なテーブルは次の二つです。 -ユーザーID -ユーザーデータ ユーザーIDテーブルの方では通番のユーザーIDを作成するために最後のユーザーIDを保存しておきます。 ユーザーデータの方はユーザーIDとパスワードとゲームのデータを保存します。
編集の要約:
Q & A 認証:
ページ更新時は次の質問にお答えください。(プレビュー時は必要ありません)
Q:
日本の首都は?(漢字で)
A:
お名前:
タイムスタンプを変更しない
テキスト整形のルールを表示する
[1]
Links list
(This host) = https://njf.jp
(This host)
/cms/modules/xpwiki/?cmd=edit&help=true&page=Google%20App%20Engine%20for%20Python%E3%80%80%E3%81%9D%E3%81%AE%EF%BC%92