SI業界からネットゲーム業界に移った知人に色々話を聞いてきた その２

ふと思い出したので、あまり注目されなさそうなタイミングで。もう2年も前になるが、下記の話の続きの話。

SI業界からネットゲーム業界に移った知人に色々話を聞いてきた。

簡単に書くと、SI会社畑の知人がネットゲーム業界に転職してみたらDBとかネットワークとか色々凄絶でしたよ、という話である。上記エントリーで書かなかったエピソードがもう少しあるので書いておこうと思った。

引き続き、これはあくまで、「当時の(もう6,7年前の筈である)」「その友人の会社の」話なのであって、一切一般化出来る様な話ではないし、最近似た様な話があるのかどうかも知ったことではない、ということは事前に断りを入れさせて頂く。


・ゲーム内通貨の扱いについて。プレイヤーが持っている所持金データについて、「現在の所持金」しかデータが保持されていなかった。つまり、ゲーム内通貨の「出入り」が一切記録されない状態だったので、RMTや不正取引を追う方法がなかった。

・その為、知人が新たにテーブルを一個用意し、お金の出入りは一つ一つレコードとして保存し、現在金額はそこから集計した値を別に保持し、かつ定期的にチェック処理を走らせるよう変更した。(金融系のオンラインシステムでは多分ごく常識的な実装)

・ついでに、各プレイヤーの一日ごとの現金残高とお金の出入りを集計して、おかしな点がないかどうか集計・確認する簡単なバッチ処理を作った。

・ざくざく異常が見つかった。

・笑えることに、上記変更を行った週から「不正取引撲滅キャンペーン」のようなものが始まった(社内での話)。結果、不正業者がじゃかじゃか発見された。

・ただ、この段階では不正業者はマークするだけで、アカウント停止措置が行われたのは随分後のことだったらしい。不正業者は複数アカウントを保持するのが常で、それによる収入も馬鹿にはならないので、タイミングを見ることが必要だ、ということだったそうだ。

・データの推移からbot(プログラムで動く自動プレイヤー。これが多くなると他のプレイヤーが大変迷惑する)を発見する、ということが出来るようになったのもこの変更があってからのことだったとか。詳しくは聞いてないが。


・ちなみに、当時そこの開発現場では、「バッチ処理」という概念も無かったそうな。その為、ボス敵の出現条件のリセットといった定型業務が、メンテナンス時に手動でupdate文を流すことによって行われていたらしい。今からではちょっと考えられないことである。

・で、お約束の様にwhere条件をつけ忘れて、一度に出現してはいけないボスが一斉出現祭り発生。当然の如くサーバ落ちのコンボ。凄絶過ぎる。流石にトランザクション処理や同時実行制御くらいは分かる人がいた筈だが。


・ちょっと詳細はボカさせて頂くが、「攻撃力がパワーアップするアイテム」(注：イメージである)というようなものを導入した際のバグも内部的には凄絶だったらしい。誤って「何度も当該アイテムが使えてしまう」というようなバグが発生してしまった際、当時のデータ保持方法だと現在値しか保持していなかったので、どこまで巻き戻しを行えばいいかよく分からない。

・そこで、「そのアイテムが出回った数」から逆算して一斉に当該値を減算する処理をしたら、関係ないプレイヤーまでどかすか当該値が減ってしまって、仕方ないのでゲーム全体のバランス調整ということにしたそうだ。

・履歴の保持って大事ですよね、という話。

・DBのER図を見せてください、という話をしたらExcelの図表のようなものが出てきたのだが、普通のER図ならある筈のテーブル関連のようなものが全くない。なんじゃらほい、と思ったらどうも外部キーが一切設定されていなかったらしい。

・DBのチューニングについても相当色々触る部分があったようだが、流石に以前書いたこれ程ではなかったらしいので割愛する。ただ、殆どのデータをinsertではなくupdateで処理していた(つまり履歴がとれない)らしいので、レコード量がそこまで多くならなかったのは(パフォーマンス的には)不幸中の幸いだったそうな。

・この辺は、通常のOLTPと、既存のRPGのデータの概念の違いのような感じがして面白いなーと思った。


ちなみに、この知人は今では更に別の会社にいらっしゃり、元気にDBやネットワークをいじくっておられる。年明けに飲む予定があるので、また何か面白そうな話があったら聞いてこようと思う次第である。