動かし始めてからが本番、中核であるトラブル対応について。
今回起きたバグは、対応すべきレイヤーが少し普段よりも広い。

美しすぎるピタゴラ軌跡

・近接攻撃チップにも威力と近接強化チップを反映する
・後日、特定の順番で付け替えをすると延々と攻撃力が上がるバグ判明
・修正の際に内部データの更新処理を間違える
・中途半端な場所のため、エラーで止まらない
・しゃがみIIが外れない呪いのチップと化す
・さらに間違ったセーブデータが出力され、ID登録してセーブしていた場合に再度開けない

バグ自体は普段からある（アップデートの半分くらいはそうだ）し割とすぐに直せたけれど、今回はセーブデータに問題が出たという点がポイント。

錆びた歯車か、爆発物製造か

さて、普段からバグは発生しているし、データ間違いに至っては日常的に起こっている。うん、良くないのは分かっている。

基本的に対応としてはどれだけ致命的なものであるかで優先度を付けることが多く、処理が止まってしまうものは緊急対応、メッセージの句読点が違っているなんてのは後回しになりがちなのをあちこちで見ていると思う。
もう一つの基準が、そのままにした場合に後に影響が出るかどうか。画面表示がちょっとずれるなんてのは、直してしまえば以後は「昔の話」だ。しかし、記録したデータが壊れるといったその後にずっと影響を及ぼすものは非常にまずいことになる。
ゲームで無限にポイントが稼げてしまう場合、永続的な数値に影響があるものは（ネットゲーム時代は結構な割合でそうですな）プログラム修正だけでなく巻き戻しなりを受けるあれである。

当たり前すぎて意識しないだろうけれど、「正しく動く」という言葉にはプログラムとしての意味（※1）と、「正当に作られたデータを元に」という枕詞がついた運用としての意味がある。
ゲームだけでなく、というよりはむしろゲーム以外の業務システムでこそ違いは重くなり、場合によっては「ごくごく一時期だけ作られた可能性がある、間違ったデータ」のために特殊処理を入れたり、逆にシステムを導入したら何故か全伝票が手書きになって現場が怒髪天を衝いたりする。

（※1）
「ゴミを入力したら正当にゴミが出てくる」
超大量の株空売りとかのそもそもができて良いことなのかという点は、既にシステムとしての正当性以前の政治的な域なので見なかったことにしましょう。

で、処理したん？

前置きが無駄に長くなったけど、結論としては手でDBを直して対応した。所要時間1時間弱ほど。

これを読んでいるような人は物好…まあいい。意外に思われるかもしれないけど、実はID登録して毎日使っているような人というのはあまり多くない。そこまで使うのは多く見ても大体20ユーザーいないくらい。
おおよそはMAPが変わったり、使いたい新装備が出ると動く感じ。
この時は特に使う人が多い時間帯だったとはいえ、問題を起こすプログラムであった時間が1時間ないくらいだったので10ユーザーも対象はいなかった。

これらが判明した時点で、壊れたセーブデータのリセットから、セーブデータの手動修復に方針を変更。幸いにも壊れ方が手で簡単に修復できる形だったのですぐに作業に入れた。

この時の告知方法についても、色々と考えるべき点はあった。一度システムを落としてしまうのを選択肢として持つための仕組みがあるべきかなあ、とも思う。

被害を食い止めた物

実は食い止めた物に関しては、手で直しやすい単純な形の壊れ方だった、他のユーザーなりに影響を及ぼすような場所でなかった、アップデート後に素早くバグ連絡をくれるユーザーに恵まれている、という偶然だけ。

ただ、この時に対象データとユーザーを見つけるのはRDBをデータ保持に使っていたからこそ、というのは言える。たまに流行る（※1）ファイルに直接書きだそうぜ、はやめた方がいい。
レコード作成と更新時間に具体的な使い道を思いつかないかもしれないが、管理の面からだと時間軸というは時にほとんど唯一の解になってしまうことがある。作成、更新、削除時間とユーザー名をカラムに入れておくのは少なくとも悪のおまじないではない。

（※1）
直接ファイルにデータを冗長かつ平文で書き出し、（ファイル名での）検索も速くて何を示しているのかも一目瞭然でシステム更改の際もすぐに扱える、という謎の主張。
正にその「どこのデータかを指定して自分で中身を確かめる」方式のあまりの非効率からの解放として「どのデータが欲しいか」の思想を持つデータベース（RDB限定に非ず）が発明されたのだが…。なぜこいつらは何度墓穴に蹴り落としても復活してくるのだろうか。

被害を拡大した物

拡大した物は、意外なことに各ユーザーのキャッシュ。JavaScriptがキャッシュされたままで、壊れたデータがスクリプト修正後もセーブされたケースが実際にあった。
気が付いたから良かったものの、サーバ側の処理をおかしくして被害を拡大させる類だった場合に、もう正しいデータしか来ないという間違った前提を持っていたら大変なことになっていた。

これからウェブサービスが普及していくと、どこが壊れた場合にどこまで被害が広がりうるかとともに、どこまで修正が完了したとみなしうるか、なども問題になって行くと思う。

最後に

ご迷惑をおかけしました。
あと、毎度素早くバグの連絡をもらえるからこそ、何とか動いています。

余談、あるいは大急ぎ修正から垣間見える話

こういったシミュレータのiPhoneアプリ版が出にくい理由が、最初の審査だけではなく、バグ修正やデータ追加を即時にできない点にもあるのではないかと思う。処理とデータをサーバに持って行きすぎると正にブラウザ上で動かせという話になってしまうし。
もう少し、HTML5とともにクライアントサイドのデータ保持がまともにできてきていれば、ローカルで動かして「同期」ボタンで好きな情報だけセーブしたり公開しなかったりとかができるんだけどねえ。localStorageはまだ好きに使っていい段階じゃないと思う。

アドビ？エア？何のことです？