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

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

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

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

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

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

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

※事前に個数／所持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を失い、
本来、獲得出来る筈の 回復薬 が手元にないと、
二重で損した気持ちになる。

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

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

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