|
1: 2015-07-01 (水) 08:09:21 njf   |
| | + | 前の記事はこちら。[[Google App Engine for Python]] |
| | | | |
| | + | *ブラウザ上のカジュアルゲームデータの保存の概要 [#u36cbcbd] |
| | + | |
| | + | Flashで動作するゲームのユーザーデータは以前はSharedObjectで保存できましたが、セキュリティなどの問題から現在はSharedObjectはデフォルトでは定期的に消えるようになりました。 |
| | + | |
| | + | そこで、サーバー上で保存するわけですが、そのために必要なデータは最低限以下の物が必要です。 |
| | + | |
| | + | -ユーザーIDとパスワード |
| | + | -ゲームデータ |
| | + | |
| | + | ユーザーIDとパスワードはユーザーを区別するために必要です。メールアドレスや他のサービスのオープンIDを使ってパスワード忘れ対策などを行うと良いかも知れませんが、カジュアルゲーム程度でメールアドレスや他サービスのIDを必要とすると、ユーザーがいやがる場合があります。また、そこまでしても特に個人情報などの重要データがあるわけでも無くセキュリティ的なリスクはありません。またほとんどのユーザーは一通りゲームをプレイすると再び同じゲームをプレイすることはありません。どの程度まで実装するかは微妙なところです。 |
| | + | |
| | + | ここでは最も簡単な、サーバー側でIDとパスワードを発行してユーザー側でメモしてもらう方法をとります。パスワード変更処理やパスワード忘れ処理は無しにします。IDは通番にし、パスワードはランダムな整数にします。 |
| | + | |
| | + | ゲームデータはjson形式で送ることにします。FlashだとAMFという優れたデータシリアライズ方法があり、GAEでも利用できるのですが、Flash以外ではそのままでは使えないという欠点があります。たとえばアプリ版は他の言語で作る必要が出たときに面倒なことになります。Flashがだんだんと使われなくなってきている状況を鑑みて、汎用性からjsonでやり取りすることにします。 |
| | + | |
| | + | GAEのデータ設計において注意しないといけないのは、１レコード読み込みあたりに課金されると言うことです。また、複数レコードを読み込むと処理も重くなります。そこで一度の処理で読み込むデータは少ない方が望ましく、１ユーザー１レコードが理想です。通常のリレーショナルデータベースとは異なり、なるべく正規化はしないようにしましょう。 |
| | + | |
| | + | すると必要なテーブルは次の二つです。 |
| | + | |
| | + | -ユーザーID |
| | + | -ユーザーデータ |
| | + | |
| | + | ユーザーIDテーブルの方では通番のユーザーIDを作成するために最後のユーザーIDを保存しておきます。 |
| | + | ユーザーデータの方はユーザーIDとパスワードとゲームのデータを保存します。 |
| | + | |
| | + | --フレームワークの導入 |
| | + | |
| | + | 準備中 |
Counter: 3988,
today: 1,
yesterday: 1
下位
ページへ戻る
