パスワードを忘れた? アカウント作成
13456711 story
ゲーム

「ドラゴンボールZ」のスマホゲームで「ガチャ」でプレイヤーごとに提供割合が違う疑いが出る 80

ストーリー by hylom
突然のソースコード開示 部門より
あるAnonymous Coward 曰く、

人気アニメ「ドラゴンボールZ」のキャラクターを使ったスマートフォン向けゲーム「ドラゴンボールZ ドッカンバトル」で、いわゆる「ガチャ」で入手できるキャラクターの提供割合がプレイヤーごとに異なっている疑惑が出ている(ITmedia市況かぶ全力2階建日経新聞)。

この疑惑は、ゲーム内での「出現キャラクター一覧」画面での表示がアカウントごとに異なるという指摘で発生した。それぞれ異なる表示となってる画面キャプチャー画像も出回っている。

ドラゴンボールZ ドッカンバトルはバンダイナムコエンターテインメントが提供、開発はアカツキとなっている。バンダイナムコエンターテインメント側は「プログラムの不具合が原因」とし、誤表示だとしている。

また、11月16日12時55分付けで同問題に関する説明が発表された。これによると、キャッシュ関連の処理での不具合が原因で表示が不適当なものになっていただけだという。

  • 公式の説明で公開されたソースコード [bngames.net] は、サーバ側ではなくユーザーがダウンロードするアプリに含まれていたコードなので、アプリを逆コンパイルをすることで実際に使われていたコードであることを確認することができます。ただし、利用規約違反となる恐れがあります。

    当該のコードは、実際にユーザーに配信されたアプリに含まれていた [imgur.com] ようなので、公表されたソースコードが使われており、それにより表示上の不具合が発生したというのは真実だと思われます。

    ユーザー毎の確率操作が行われていたかは分かりませんが、仮に確率操作をしていたのだとしたら「出現キャラ提供割合」は完全な静的ページにするのが自然(不正が発覚しにくい)なので、今回の表示バグとは一切関係がありません。

    ここに返信
  • バグは、まあ、出ちゃったもんはしょうがないけど。
    負荷テスト以外でselect *なんてやっちゃうんだって感想しか。
    独自アロケータとか使わないのかな?

    ここに返信
    • 今回のは select * from ~ where id in (...) を、 order by id asc してなければ、入れる際に(レコード側の)idとチェックしてなかったというオチですからして。
      しかも sqlite だから、* のほうが下手すると早いんじゃないですかね。どうせオンメモリでしょうし。
      --
      -- To be sincere...
    • by Anonymous Coward

      というか、今回のように疑われる状況では、これが原因ですという主張には実は意味はないんですよね

      ・たとえばわざと今回のようなSQLソースにしておきつつ、実際にはレコードが入れ替わることなんてない作りにしておきます

      ・それとは別に、実質的にガチャの確率操作につながる実装も入れておきます

      ・後者がばれそうになったら、言い訳として「前者のせいです、表示の内容がおかしかっただけです」として逃げます

      こういうことをしていないのかを証明することは、信用を失った状況では非常に困難です

      ※ もっと言えば今回原因とされたソースが本当にすべてのゲームプレイヤーのゲームサーバ上で「このロジックだけで」動いていたかも証明がありません

      バグが多くてボロボロでひどいコードであるほど、上記のような逃げが使えることになってしまいます

      • by Anonymous Coward

        それをやる意味は?

        • by Anonymous Coward

          やっちゃったからには意味がないことを証明しないと信じてもらえないという話でしょ

  • ガチャで確率操作が行われていないことをユーザーが検証可能にすべきだと思います。

    技術的には特に難しくはなく、

    1. ユーザー側が、どの乱数に対して、どのアイテム(キャラクターやカードなど)が提供されるのかを決めて、対応表を作る。 例えば、SSレアの提供確率が1キャラにつき1%で合計3キャラの場合、52 が SSレアのキャラA、57がSSレアのキャラB、23がSSレアのキャラCなどと、ユーザー側で決める。
    2. 対応表のデータを、ソシャゲー運営者に共通鍵暗号方式で暗号化してから渡す。暗号鍵はこの時点では渡さない。
    3. 課金処理の後、ソシャゲー事業者が乱数を発生させ、抽選結果の乱数(例: 56)をユーザーに公開する。
    4. ユーザーが、抽選結果の乱数を確認後、暗号鍵をソシャゲー運営者に送信する。
    5. ソシャゲー運営者が、ユーザーから受け取った対応表を復号し、乱数に対応するアイテムを提供する。

    とすることで、どの乱数が「当たり」なのかは暗号鍵が無ければ分からないことから、ソシャゲー運営者による不正な操作を防ぐことができます。また、暗号化された対応表データはソシャゲー事業者側にもわたっているので、乱数の発生後にユーザーが対応表を書き換えることもできません。

    ユーザーがガチャを引くたびに行う、対応表の作成・暗号化・暗号化された対応表データの送信の方式については、標準化して RFC にして、ユーザーはオープンソースの信用できるアプリを使えば良いと思います。ここらへんのデータのやり取りは、アプリ間連携(Intent など)で自動化できるので、ユーザーの手間はインストールするアプリが1つ増えるだけです。

    こうすることで、今まで不透明だったガチャが透明になり、ユーザーは安心して納金できるし、それによりガチャ事業者も潤います。まさに、Win-Win ではないでしょうか。

    ここに返信
  • by Anonymous Coward on 2017年11月16日 13時38分 (#3313394)
    ナンか違う気がするんだけど
    ここに返信
  • by Anonymous Coward on 2017年11月16日 13時39分 (#3313395)

    キャッシュされて居たっていうことはそれだけ千差万別な結果を生成してキャッシュして居たことになるんだけどそんなわけないよね?
    千差万別な結果の出力をなぜ作って居たのか?を節美しなきゃだめじゃね?

    ここに返信
    • 端的に言うと「千差万別の結果の出力を作っていた」(=意図的だった)のではなく
      「千差万別の結果が生まれてしまった」(=バグだった)のですね。
      その説明としては納得がいく内容だと思いますよ。
    • by Anonymous Coward

      というか、このクソコードを見せられて信じろと言われてもって感じ
      何をどう言い繕ったとしても、ガチャの確率操作・テーブル操作をされているという疑念は晴れないでしょうね

      // 信じる人は信じるし、信じない人は信じない

      • 以前スマホゲーのガシャを作ったときは「課金額によって出すアイテム変えようか」という冗談に「でもそれデバッグが超めんどくさくね?」「それで課金が増えるかどうかのチェックってできなくね?」という当然の意見で却下されたのであった。
        有能なスタッフが山ほどいて開発の時間があって予算が潤沢なスマホゲーだったらできるかも知んないけどそういうスマホゲーはそこまで悪辣な事しなくても儲かるから不正は無いんじゃないのかな、というのが元中の人の感想(個人の感想です)

        • by Anonymous Coward

          ユーザーの1%だけに適用してガチャの判定ロジックにだけ細工をして入手後のアイテムにその情報は一切保持されないとかいくらでもやりようはあるし
          そもそもステータスA(課金額)でステータスB(レア入手率)を変動させるのなんて、攻撃力でダメージ値やクリティカル率を変動させるみたいにゲームならあちこちでやってるでだろう。
          全てのメーカーがコンシューマみたく、防御力が1の時に攻撃力1を受けた時のデバッグ、防御力が2の時に、攻撃力2の時にって全通りやってるならともかく
          売れてないマイナーなソシャゲならやってない所も普通にあるだろう。

          • by Anonymous Coward

            全部同じ会社内でやってたらできるかもしれないけどプログラム作成とゲームサーバーと課金サーバーが別会社なのが普通だからたいていうまくいかないんじゃないのかな

            • by Anonymous Coward

              ゲームサーバーの会社がaws、課金サーバーの会社がgoogleの事を指しているとして
              ガチャの判定コードの話なんだからプログラム作成してる会社だけで完結するでしょ。

      • by Anonymous Coward

        というか、このクソコードを見せられて信じろと言われてもって感じ

        スケープゴート用にクソコード書く奴をキープしていました
        ってくらいの黒さに期待

        # 発表までのラグの真相は。。。

      • by Anonymous Coward

        確率操作をやってたとしたら
        わざわざ証拠になるような複数の表記なんて作らないだろう。
        だから表記に関しては間違いなくバグだよ。

        確率操作をやってないと言うつもりはないが(やる意味は大してないが)
        表記を根拠にやってると主張するのは頭が足りないと言わざるを得ない。

        • by Anonymous Coward

          >確率操作をやってたとしたらわざわざ証拠になるような複数の表記なんて作らないだろう。
          激しく同意。

          「スポーツくじ「BIG」でランダムなはずの予測結果が2連続で一致するも「偶然」との回答」
          https://it.srad.jp/story/17/02/20/1619238/ [it.srad.jp]
          関連ストーリーでコレがないのが不思議なレベル。

          微妙な確率操作やってるなら、バレないようにするくらいはお手の物。
          検証して簡単にバレるくらい露骨な操作なら、やるメリットがまずない。

          #アプリ開発現場のクソッっぷりを知っていれば、むしろ綺麗なコードを出してきた時の方が、
          #人に見せるためだけに偽物の証拠を捏造したんじゃねと疑いたくなる。糞コードはデフォ。

        • by Anonymous Coward

          だから、
          「一律のはずなのに、なぜわざわざ複数の画面が用意されてるのか」
          の説明に全くなってないよね。
          一律なんだから、1種類の画面でいいはずで、そもそも複数用意する意味がない。

          #正直よういしたと言うよりも、人によってテーブルを変えていて、
          #そのテーブルから画面は自動生成していたと考えるのが一番しっくりくる。

          • by Anonymous Coward

            単にイベントごとにパラメータを変更したデータを食わせて表示してただけじゃないの。
            人によってテーブル変えるとかしてたとしてもそれを表に出す理由は全くない。

    • by Anonymous Coward

      ユーザの数だけパターンがあるわな。

    • by Anonymous Coward

      > 千差万別な結果を生成してキャッシュして居た

      キャッシュテーブルにデータを保存するのは新たに未所持カードを入手したタイミングなわけで、その順序は人によって異なる。
      SQLでは、返ってくる行の順序は保証されていなくて、レコードの追加された順序でも変わってしまうのが普通。
      こういうコードで使うなら、SELECTする際にORDER BY句を付けて特定の順序で返ってくることを保証すべき、という話。

      説明を好意的に(インチキがなかったと)受け取るならね。

      • by Anonymous Coward

        ん?
        「ガチャの確率」なんだから、所持カードも未所持カードも無関係でしょ。

        それが関係してしまうなら、それこそ「ユーザーごとに確率を操作している」にほかならない事になってしまう。
        同じように、「ガチャの確立表記画面のキャッシュ」は「未所持カードを入手したタイミング」ではダメでしょ。

        「確率変更されたとき、または新規カードがガチャに追加されたとき」でないと。

        でないとそもそも「デタラメな確立表記」になりますがな

  • by Anonymous Coward on 2017年11月16日 14時17分 (#3313413)

    アカウント…というか作るキャラ次第でドロップ品の確率どころか種類も変わるというのは
    PSOプレイヤーには当たり前の事じゃ

    #いろいろ違う

    ここに返信
    • by Anonymous Coward

      イエローポーズはメセタしか出ないんだよう。

      #最新作では、男好きとか、大物狙いとか、ツンデレとか
      #プレイヤーが複数のパターンから自由に選択出来るようになりました。

    • by Anonymous Coward

      それを言うならモンハンなら当たり前では。レアテーブル調べてマラソンするゲームだしさ。

      それにしてもガチャの提供割合で炎上しても売り上げが落ちないどころか上がるのが面白いよな。
      過去に炎上して天井つける事になったグラブルや運営自体に疑惑のかかったKOFなど他のゲームも、この手の騒ぎで売り上げが落ちた事ってないし。

  • by Anonymous Coward on 2017年11月16日 15時03分 (#3313439)

    ゲームサーバが内部で複数ノードに分かれており、
    各ノード上ではガチャ確率などに応じたページリソースを動的作成

    ただし、各ノード上で実は設定が違うのに、そうではなく均一設定になっているようにしたい場合には
    均一設定を踏まえて事前に作っておいたページリソースを読み込み専用(書き込み禁止)で配置しておく

    という運用で、ページリソースを読み込み専用(書き込み禁止)にするのを忘れたとか
    プロセスをroot権限(など、プラットフォーム上でのスーパーユーザ権限)で起動してしまったとかで、
    各ノード上の設定を踏まえて作成されたページリソースが本当に公開されてしまった、
    とかはありがちでしょうかね

    また、当初はそのようにページリソースを各ノードで動的生成で公開していたのだが、
    負荷分散などを目的に一部のリソースをそれ専用サーバで公開するようにしていた、
    ところがそこの設定を変えたとき、専用サーバに一律入るべきトラフィックが、各ノードに振られるようにデグレしてしまい
    各ノード上で動的生成されたページリソースが見えてしまった、
    なんてのもありがちです

    今回の件では、利用者ごとではなくゲームを起動してゲームサーバに接続するごとにガチャ確率表示内容が異なるという状況だったようですしね

    ここに返信
  • by Anonymous Coward on 2017年11月16日 15時03分 (#3313443)

    今度の不具合はどこだ!という発言と共に、すみません今回はここでミスりましたとネットでソースが飛び交う時代か。

    ここに返信
    • by Anonymous Coward

      詫びコースコード出すのは珍しい、よね

      • by heavensgate (21016) on 2017年11月16日 18時01分 (#3313602)
        風評被害で下手すりゃサービス停止どころか会社が潰れかねませんから、リスク管理としては正しいのでは。
        ※株価の変動を見るとねえ……

        ただまあ、煽ることがメインになってるようなニュース速報サイトだと、そもそもあの説明を見てもわからん→会社はごまかしている!、とさらに煽る(実態は無知を暴露しているだけだが)、というオチがありそうな気はするが。
        --
        -- To be sincere...
  • by Anonymous Coward on 2017年11月16日 15時54分 (#3313494)

    パパはクォーテーションとかセミコロン試しちゃうぞー(しない)

    ここに返信
  • by Anonymous Coward on 2017年11月16日 16時41分 (#3313525)

    不具合で本当はそんなこと置きてなかったけどガチャ停止するよ!
    不具合で本当はそんなこと置きてなかったけどガチャ石300個も配るよ!

    スマホゲーのガチャ厨は、石さえもらえれば何でもOKだってよく分かってるじゃない!

    ここに返信
  • by Anonymous Coward on 2017年11月16日 16時44分 (#3313528)

    一般ユーザも見る場所に置く社外向け報告にコードのエビデンス貼ってくるあたり、なんか「あー!もう!」って感じが伝わってきますね。

    「どうすんだよこれ」「これでまた、なんか有りもしない陰謀論的な事あちこちで言われるんだよ」「何言ったって信じちゃくれないだろう」「どうするマジバグなのに…」

    上長「ソースの該当箇所貼ったら?むしろ」「えっ」
    「わかる人にはわかるし、分からない人はどうせ何言ったって聞かないんだから、いいんじゃない?もう」

    こんな感じかな(笑)信用維持って大変。

    ここに返信
typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

読み込み中...