ソーシャルゲーム（オンラインゲーム）実装時の注意点

よくある 更新系 の話になります。
設計が絡んでくる話になりますが、「ユーザー視点」での考え方。

##「減らしてから増やす」が基本？

例えば、 ショップで100Gを使用して回復薬を1個購入するというシミュレーション で説明。

考えられるシナリオは、
・回復薬を1個増やす
・100Gを減らす
となる。

そうすると、やり方としては二つのパターンを上げられる

1. 増やしてから減らす
2. 減らしてから増やす

さて、アナタならどちらを選びますか？

増やす処理を先に行う場合

※事前に個数／所持Gチェックを行っている物とする

1.回復薬を1個増やす

UPDATE user_item SET num = num + 1 WHERE user_id = xxxx AND item_id = 1;

2.100Gを減らす

UPDATE user_param SET gold = gold - 100 WHERE user_id = xxxx;

1の処理後に、 何らかの問題 が生じて、途中でエラー（Exception）となった場合に何が起こるか。
再度、ユーザーが操作を行うとどういう事が起きるかを考えてほしい。
※ 何らかの問題 ・・・アクセス負荷により、Webサーバー／DBサーバーのレスポンスが極端に遅くなったりとか。

【結論】

回復薬の 無限増殖(デュープ) が起きてしてしまう
特定のユーザーに対して 利益 となり、他のユーザーからすると 不利益（損） となる

【一次対応、二次対応...】

プロジェクトにより色々考え方があるが、確実な方法として

1. 増減にあたる機能（ショップ機能、アイテム）の停止
2. プログラムの改修を行う
3. ログの調査を行う
4. 増えてしまったアイテムの回収

1は発覚時点で対応を行う。
なぜか？
無限増殖(デュープ) が起こる状況のままにしてしまうと、
被害が増え続けてしまう。
なので、確実に無限増殖が行われない状況にする事が大事。
2.3.4は後回し。
4の増えてしまったアイテムの回収が厄介。

---

減らす処理を先に行う場合

※事前に個数／所持Gチェックを行っている物とする

1.100Gを減らす

UPDATE user_param SET gold = gold - 100 WHERE user_id = xxxx;

2.回復薬を1個増やす

UPDATE user_item SET num = num + 1 WHERE user_id = xxxx AND item_id = 1;

こちらも同様に1の処理後に、 何らかの問題 が生じて、途中でエラー（Exception）となった場合に何が起こるか。
再度、ユーザーが操作を行うとどういう事が起きるかを考えてほしい。

【結論】

Gだけが失ってしまい、 損 となる。
ちょっとおかしな話かもしれないが、Gを失い、
本来、獲得出来る筈の 回復薬 が手元にないと、
二重で損した気持ちになる。

【一次対応、二次対応...】

1. 増減にあたる機能（ショップ機能、アイテム）の停止
2. プログラムの改修を行う
3. ログの調査を行う
4. G、回復薬の「個別」もしくは「一括」補填を行う

プロスペクト理論

この辺は「プロスペクト理論」が絡んでくるのかな。
簡単に説明すると、金額が同じでも 「利益」 と 「損失」 とでは、
「損失」の方が強く印象に残る。
人はそれを回避しようとする行動を取るという記載があります。

意外と、 投資 と ゲーム内通貨(アイテム) は似ているのかな。

プロスペクト理論とは何か？
プロスペクト理論に学ぶFXにおける心構え