「ドラゴンボールZ」のスマホゲームで「ガチャ」でプレイヤーごとに提供割合が違う疑いが出る 80
ストーリー by hylom
突然のソースコード開示 部門より
突然のソースコード開示 部門より
あるAnonymous Coward 曰く、
人気アニメ「ドラゴンボールZ」のキャラクターを使ったスマートフォン向けゲーム「ドラゴンボールZ ドッカンバトル」で、いわゆる「ガチャ」で入手できるキャラクターの提供割合がプレイヤーごとに異なっている疑惑が出ている（ITmedia、市況かぶ全力２階建、日経新聞）。
この疑惑は、ゲーム内での「出現キャラクター一覧」画面での表示がアカウントごとに異なるという指摘で発生した。それぞれ異なる表示となってる画面キャプチャー画像も出回っている。
ドラゴンボールZ ドッカンバトルはバンダイナムコエンターテインメントが提供、開発はアカツキとなっている。バンダイナムコエンターテインメント側は「プログラムの不具合が原因」とし、誤表示だとしている。
また、11月16日12時55分付けで同問題に関する説明が発表された。これによると、キャッシュ関連の処理での不具合が原因で表示が不適当なものになっていただけだという。
公表されたソースコードが使われていたことは恐らく真実 (スコア:3)
公式の説明で公開されたソースコード [bngames.net] は、サーバ側ではなくユーザーがダウンロードするアプリに含まれていたコードなので、アプリを逆コンパイルをすることで実際に使われていたコードであることを確認することができます。ただし、利用規約違反となる恐れがあります。
当該のコードは、実際にユーザーに配信されたアプリに含まれていた [imgur.com] ようなので、公表されたソースコードが使われており、それにより表示上の不具合が発生したというのは真実だと思われます。
ユーザー毎の確率操作が行われていたかは分かりませんが、仮に確率操作をしていたのだとしたら「出現キャラ提供割合」は完全な静的ページにするのが自然（不正が発覚しにくい）なので、今回の表示バグとは一切関係がありません。
Re:公表されたソースコードが使われていたことは恐らく真実 (スコア:2)
当該コードについては、ソシャゲ事業者のサーバ上のデータベースではなく、ユーザーの端末のストレージ上に存在する SQLite データベースに接続して cache.cards テーブルからデータを取得しているだけなので、特に問題無いと思います。
Re:公表されたソースコードが使われていたことは恐らく真実 (スコア:1)
引数が整数なのでインジェクションの心配がない、という点については同意なんですが
必要最小限(キャッシュにないデータ)だけを取ってくるのではなく、キャッシュから取得済のIdも含めた全Idを IN に入れたSQLを発行するなんて、とても「パフォーマンス重視」とは思えないですね。パフォーマンスを気にするなら、キャッシュになかったIdだけを指定して取得するSQLを発行しないと。
単に「引数個数不定だからプリペーアドステートメントが使えないのでSQL文字列生成した」だけで「パフォーマンスのことなんか何も考えてないだけ」に一票入れたい。
さすがに概念コードだよね？ (スコア:2)
バグは、まあ、出ちゃったもんはしょうがないけど。
負荷テスト以外でselect *なんてやっちゃうんだって感想しか。
独自アロケータとか使わないのかな？
Re:さすがに概念コードだよね？ (スコア:1)
しかも sqlite だから、* のほうが下手すると早いんじゃないですかね。どうせオンメモリでしょうし。
-- To be sincere...
Re: (スコア:0)
というか、今回のように疑われる状況では、これが原因ですという主張には実は意味はないんですよね
・たとえばわざと今回のようなSQLソースにしておきつつ、実際にはレコードが入れ替わることなんてない作りにしておきます
・それとは別に、実質的にガチャの確率操作につながる実装も入れておきます
・後者がばれそうになったら、言い訳として「前者のせいです、表示の内容がおかしかっただけです」として逃げます
こういうことをしていないのかを証明することは、信用を失った状況では非常に困難です
※ もっと言えば今回原因とされたソースが本当にすべてのゲームプレイヤーのゲームサーバ上で「このロジックだけで」動いていたかも証明がありません
バグが多くてボロボロでひどいコードであるほど、上記のような逃げが使えることになってしまいます
Re: (スコア:0)
それをやる意味は？
Re: (スコア:0)
やっちゃったからには意味がないことを証明しないと信じてもらえないという話でしょ
Re:さすがに概念コードだよね？ (スコア:2)
「やっちゃった」からには「やったのだ」と主張されても反論できないよね、
と(#3313456)は言ってるんだと思いますが
(#3313456)自体が「これはわざとやったのだ」と主張してるとは思いません
ので、「やった理由」を問うても出せないと思います
どこで(#3313456)を「わざとやったんだろう」と主張してると解釈したんですかね
ガチャで確率操作が行われていないことをユーザーが検証可能にすべき (スコア:2)
ガチャで確率操作が行われていないことをユーザーが検証可能にすべきだと思います。
技術的には特に難しくはなく、
とすることで、どの乱数が「当たり」なのかは暗号鍵が無ければ分からないことから、ソシャゲー運営者による不正な操作を防ぐことができます。また、暗号化された対応表データはソシャゲー事業者側にもわたっているので、乱数の発生後にユーザーが対応表を書き換えることもできません。
ユーザーがガチャを引くたびに行う、対応表の作成・暗号化・暗号化された対応表データの送信の方式については、標準化して RFC にして、ユーザーはオープンソースの信用できるアプリを使えば良いと思います。ここらへんのデータのやり取りは、アプリ間連携（Intent など）で自動化できるので、ユーザーの手間はインストールするアプリが1つ増えるだけです。
こうすることで、今まで不透明だったガチャが透明になり、ユーザーは安心して納金できるし、それによりガチャ事業者も潤います。まさに、Win-Win ではないでしょうか。
Re:ガチャで確率操作が行われていないことをユーザーが検証可能にすべき (スコア:2)
ユーザが後で渡すカギを細工して「もらった番号があたり」に解読できるような手法を編み出すことが考えられますね。
ハッシュ入れとけとか最初に業者からnonce的なものを渡すとか(どうせ範囲とか確率とか要るし)になるんですかね
Re:ガチャで確率操作が行われていないことをユーザーが検証可能にすべき (スコア:2)
さすがにユーザの操作は増えないでしょ
あるとすればプラットフォームかゲームSDKに装備されるんだろうし
気にするほどTATが長くなることもないんじゃないすか
CardDataの複数形はCardDatas (スコア:0)
Re:CardDataの複数形はCardDatas (スコア:1)
スーパー戦隊のソシャゲならあながち間違いではなかったかもしれないです
https://www49.atwiki.jp/aniwotawiki/pages/24351.html [atwiki.jp]
一人以外は全員敗者
それでもあきらめるより熱くなれ
Re:CardDataの複数形はCardDatas (スコア:1)
Dataは複数形であり単数形はdatumなんだけどね。
Re:CardDataの複数形はCardDatas (スコア:1)
Media（複）・Medium(単) もその類ですね。
Re: (スコア:0)
違うけど、Personの複数形はPeopleとか知るかボケって思いながら日々コードを書いてます。
Re: (スコア:0)
少なくとも米国では、personの複数はpersonsって書くこともあるぞ。
Re:CardDataの複数形はCardDatas (スコア:1)
Re:CardDataの複数形はCardDatas (スコア:1)
その通り、若干異なります。
親コメ(#3313425)ではコードを書く場合に person データありきの複数形表現で悩む、
という状況のようですので、persons は people より相応しいのではないかと。
Re: (スコア:0)
少なくとも米国では、personの複数はpersonsって書くこともあるぞ。
意味違うよね。
Re: (スコア:0)
ただ、personを含む文章のpersonのところを複数で言う場合にpeopleとした方が、 文意として正しい場合が多いというだけ。
dataがdatumの複数形というのとは別の話。
Re: (スコア:0)
oneの複数形はones
Re: (スコア:0)
existsがカードが存在するかしないかの真偽値じゃなくて
存在するカードの数なのも……
キャッシュ？そんなバカな (スコア:0)
キャッシュされて居たっていうことはそれだけ千差万別な結果を生成してキャッシュして居たことになるんだけどそんなわけないよね？
千差万別な結果の出力をなぜ作って居たのか？を節美しなきゃだめじゃね？
Re:キャッシュ？そんなバカな (スコア:1)
「千差万別の結果が生まれてしまった」(＝バグだった)のですね。
その説明としては納得がいく内容だと思いますよ。
Re: (スコア:0)
というか、このクソコードを見せられて信じろと言われてもって感じ
何をどう言い繕ったとしても、ガチャの確率操作・テーブル操作をされているという疑念は晴れないでしょうね
// 信じる人は信じるし、信じない人は信じない
チェック環境がないのでたぶんやらない (スコア:2)
以前スマホゲーのガシャを作ったときは「課金額によって出すアイテム変えようか」という冗談に「でもそれデバッグが超めんどくさくね？」「それで課金が増えるかどうかのチェックってできなくね？」という当然の意見で却下されたのであった。
有能なスタッフが山ほどいて開発の時間があって予算が潤沢なスマホゲーだったらできるかも知んないけどそういうスマホゲーはそこまで悪辣な事しなくても儲かるから不正は無いんじゃないのかな、というのが元中の人の感想(個人の感想です)
Re: (スコア:0)
ユーザーの1%だけに適用してガチャの判定ロジックにだけ細工をして入手後のアイテムにその情報は一切保持されないとかいくらでもやりようはあるし
そもそもステータスA(課金額)でステータスB(レア入手率)を変動させるのなんて、攻撃力でダメージ値やクリティカル率を変動させるみたいにゲームならあちこちでやってるでだろう。
全てのメーカーがコンシューマみたく、防御力が1の時に攻撃力1を受けた時のデバッグ、防御力が2の時に、攻撃力2の時にって全通りやってるならともかく
売れてないマイナーなソシャゲならやってない所も普通にあるだろう。
Re: (スコア:0)
全部同じ会社内でやってたらできるかもしれないけどプログラム作成とゲームサーバーと課金サーバーが別会社なのが普通だからたいていうまくいかないんじゃないのかな
Re: (スコア:0)
ゲームサーバーの会社がaws、課金サーバーの会社がgoogleの事を指しているとして
ガチャの判定コードの話なんだからプログラム作成してる会社だけで完結するでしょ。
Re: (スコア:0)
というか、このクソコードを見せられて信じろと言われてもって感じ
スケープゴート用にクソコード書く奴をキープしていました
ってくらいの黒さに期待
# 発表までのラグの真相は。。。
Re: (スコア:0)
確率操作をやってたとしたら
わざわざ証拠になるような複数の表記なんて作らないだろう。
だから表記に関しては間違いなくバグだよ。
確率操作をやってないと言うつもりはないが(やる意味は大してないが)
表記を根拠にやってると主張するのは頭が足りないと言わざるを得ない。
Re: (スコア:0)
＞確率操作をやってたとしたらわざわざ証拠になるような複数の表記なんて作らないだろう。
激しく同意。
「スポーツくじ「BIG」でランダムなはずの予測結果が2連続で一致するも「偶然」との回答」
https://it.srad.jp/story/17/02/20/1619238/ [it.srad.jp]
関連ストーリーでコレがないのが不思議なレベル。
微妙な確率操作やってるなら、バレないようにするくらいはお手の物。
検証して簡単にバレるくらい露骨な操作なら、やるメリットがまずない。
＃アプリ開発現場のクソッっぷりを知っていれば、むしろ綺麗なコードを出してきた時の方が、
＃人に見せるためだけに偽物の証拠を捏造したんじゃねと疑いたくなる。糞コードはデフォ。
Re: (スコア:0)
だから、
「一律のはずなのに、なぜわざわざ複数の画面が用意されてるのか」
の説明に全くなってないよね。
一律なんだから、1種類の画面でいいはずで、そもそも複数用意する意味がない。
＃正直よういしたと言うよりも、人によってテーブルを変えていて、
＃そのテーブルから画面は自動生成していたと考えるのが一番しっくりくる。
Re: (スコア:0)
単にイベントごとにパラメータを変更したデータを食わせて表示してただけじゃないの。
人によってテーブル変えるとかしてたとしてもそれを表に出す理由は全くない。
Re: (スコア:0)
ユーザの数だけパターンがあるわな。
Re: (スコア:0)
> 千差万別な結果を生成してキャッシュして居た
キャッシュテーブルにデータを保存するのは新たに未所持カードを入手したタイミングなわけで、その順序は人によって異なる。
SQLでは、返ってくる行の順序は保証されていなくて、レコードの追加された順序でも変わってしまうのが普通。
こういうコードで使うなら、SELECTする際にORDER BY句を付けて特定の順序で返ってくることを保証すべき、という話。
説明を好意的に(インチキがなかったと)受け取るならね。
Re: (スコア:0)
ん？
「ガチャの確率」なんだから、所持カードも未所持カードも無関係でしょ。
それが関係してしまうなら、それこそ「ユーザーごとに確率を操作している」にほかならない事になってしまう。
同じように、「ガチャの確立表記画面のキャッシュ」は「未所持カードを入手したタイミング」ではダメでしょ。
「確率変更されたとき、または新規カードがガチャに追加されたとき」でないと。
でないとそもそも「デタラメな確立表記」になりますがな
Re:キャッシュ？そんなバカな (スコア:1)
「ガチャの確率」とかどこから湧いてきた情報だよ。
「出現キャラクター一覧」の表示がユーザ毎に異なってたのを、きみらが勝手に「ガチャの確率」がユーザ毎に違ってると妄想してただけでしょ？
えー (スコア:0)
アカウント…というか作るキャラ次第でドロップ品の確率どころか種類も変わるというのは
PSOプレイヤーには当たり前の事じゃ
＃いろいろ違う
Re: (スコア:0)
イエローポーズはメセタしか出ないんだよう。
#最新作では、男好きとか、大物狙いとか、ツンデレとか
#プレイヤーが複数のパターンから自由に選択出来るようになりました。
Re: (スコア:0)
それを言うならモンハンなら当たり前では。レアテーブル調べてマラソンするゲームだしさ。
それにしてもガチャの提供割合で炎上しても売り上げが落ちないどころか上がるのが面白いよな。
過去に炎上して天井つける事になったグラブルや運営自体に疑惑のかかったKOFなど他のゲームも、この手の騒ぎで売り上げが落ちた事ってないし。
まぁ、たとえばの例ですが (スコア:0)
ゲームサーバが内部で複数ノードに分かれており、
各ノード上ではガチャ確率などに応じたページリソースを動的作成
ただし、各ノード上で実は設定が違うのに、そうではなく均一設定になっているようにしたい場合には
均一設定を踏まえて事前に作っておいたページリソースを読み込み専用（書き込み禁止）で配置しておく
という運用で、ページリソースを読み込み専用（書き込み禁止）にするのを忘れたとか
プロセスをroot権限（など、プラットフォーム上でのスーパーユーザ権限）で起動してしまったとかで、
各ノード上の設定を踏まえて作成されたページリソースが本当に公開されてしまった、
とかはありがちでしょうかね
また、当初はそのようにページリソースを各ノードで動的生成で公開していたのだが、
負荷分散などを目的に一部のリソースをそれ専用サーバで公開するようにしていた、
ところがそこの設定を変えたとき、専用サーバに一律入るべきトラフィックが、各ノードに振られるようにデグレしてしまい
各ノード上で動的生成されたページリソースが見えてしまった、
なんてのもありがちです
今回の件では、利用者ごとではなくゲームを起動してゲームサーバに接続するごとにガチャ確率表示内容が異なるという状況だったようですしね
詫びソースコード (スコア:0)
今度の不具合はどこだ！という発言と共に、すみません今回はここでミスりましたとネットでソースが飛び交う時代か。
Re: (スコア:0)
詫びコースコード出すのは珍しい、よね
Re:詫びソースコード (スコア:1)
※株価の変動を見るとねえ……
ただまあ、煽ることがメインになってるようなニュース速報サイトだと、そもそもあの説明を見てもわからん→会社はごまかしている！、とさらに煽る（実態は無知を暴露しているだけだが）、というオチがありそうな気はするが。
-- To be sincere...
よーし (スコア:0)
パパはクォーテーションとかセミコロン試しちゃうぞー(しない)
不具合だけど！ (スコア:0)
不具合で本当はそんなこと置きてなかったけどガチャ停止するよ！
不具合で本当はそんなこと置きてなかったけどガチャ石300個も配るよ！
スマホゲーのガチャ厨は、石さえもらえれば何でもOKだってよく分かってるじゃない！
なんか雰囲気察する (スコア:0)
一般ユーザも見る場所に置く社外向け報告にコードのエビデンス貼ってくるあたり、なんか「あー!もう!」って感じが伝わってきますね。
「どうすんだよこれ」「これでまた、なんか有りもしない陰謀論的な事あちこちで言われるんだよ」「何言ったって信じちゃくれないだろう」「どうするマジバグなのに…」
上長「ソースの該当箇所貼ったら？むしろ」「えっ」
「わかる人にはわかるし、分からない人はどうせ何言ったって聞かないんだから、いいんじゃない？もう」
こんな感じかな(笑)信用維持って大変。