[チート対策] ガチャサイトの抽選ロジックを実装しようとした時に気をつけたこと

これはno plan inc.の Advent Calendar 2023の9日目の記事です。

どもー、皆さん。no plan inc.のおかむーです。
最近ガチャ系の実装を設計から実装までやったのですが、その際に
ガチャのロジックについて結構ディスカッションしたことがあるので、
このガチャロジックについて知見を共有できたらと思っています。

前提条件

• Firebase firestoreとCloud Functions for Firebase のサーバーレス構成
• SSR, SR, R, N のガチャが用意されている
• クレカやPayPayなどのオンライン決済で購入を想定
  • もし決済がキャンセル、失敗した場合も考慮したい
• SSR、SRの残り枚数を動的に表示したい(SSR, SRにはさらにその中に種類という概念があります)
• 基本的には重複を防ぐためトランザクションを張ります

この記事でわかること

• ガチャサイトを実装しようとした時に気をつけたほうがよさそうなことがわかります
• 同時に引かれた時
• リアルタイムが故のなやみ

がわかります

結論

• ①抽選方式は何がいいか
  • あらかじめ在庫を生成し、抽選時に在庫を減らしてそこからランダムで当選する

①抽選方式は何がいいか

ひとえに言ってもガチャの抽選方法はいくつかあります

抽選方式A案: 完全確率の場合 ○

これは SSR:1% SR:29% R:70%などのような抽選確率を簡単に定めることができます

完全確率のメリット

• 排出のパーセントがわかりやすい
• 比較的実装が簡単なのでコストは安い
• 決済が失敗キャンされるされても問題ない

デメリット

• 限定枚数が存在するとダルい
  • 例えば500枚限定で完全確率ガチャを導入してしまうと起こりうるリスクとしては
    • SSRが絶対に1枚出ないかもしれないし、SSRが500枚出てしまうかもしれない
      => これは運営にとっていろいろリスクがあります
• 数量が限られているモノとの交換だったりすると多く出た場合は返金対応などになってしまいます
• 残り枚数が表示できない(bizでこの仕様を切り捨てれるなら最適)

抽選方式B案: 完全確率+限定数制御 ▲

A案にSSR,SRに関しては設定上限が過ぎたら抽選しない(設定上限を超えたら抽選しない)

メリット

• 排出のパーセントがわかりやすい
• ちょっと実装大変かもしれない

デメリット

• まだ限定枚数が存在するとダルい

  • 例えば500枚限定で完全確率ガチャ+限定数制御を導入してしまうと起こりうるリスクとしては
    • 500枚引かれたとしても、SSRが絶対に1枚出ないかもしれない
      => これはまだ運営にとって、天井したのに！！何で出ないんだ！！

• 決済が失敗キャンセルされると、また制限数を戻す、もしくは仮予約状態などを考慮しないといけない
  => SSRの残り枚数が0だったり、1だったり最後決済しなかった人がいた場合数字が上下する
  => SSR残り枚数が出ると、仮予約で在庫数をディクリメンとすると当選したかわかってしまいSRなどで注文キャンセルされることが想定される

などのリスクがあります
さあややこしくなってきました

抽選方式C案: 順序配分方式 ×

別口の案ですが参考として、
抽選を行わずに当選の順番を定義しておいて、先頭から当選を割り当てていく

メリット

• あんまりフェアじゃない

デメリット

• 当たりを最後とか任意のタイミングで仕込まれてしまう可能性がある
  • サイトの信用が落ちる可能性がある

抽選方式D案: あらかじめ在庫を生成し、抽選時に在庫を減らしてそこからランダムで当選する ○

いわゆる一番くじの要領で、最初から箱の中にものが入っています
決済前に、あらかじめ当選数を予約して、決済が完了したcallbackを元にその予約済み当選を確定します
10分程度決済がなかったら決済のタイムアウトとし在庫に戻します

注意

• もし、予約済みをフロントの数字反映させてしまうと、決済画面まで飛んで、SSRの在庫が減ったか確認して決済を取り止めれば確実にSSRを当てることができます

• 今回firestoreを使っています。DBにだれでもgetの権限があると予約中かどうかもみられてしまいます、なのでこの辺の抽選のDBはget listで見られないようにfirebase ruleをしっかり設定しましょう

メリット

• 実装が大変
• 残り枚数も表示できる
  • 残り枚数は、予約済み枚数は表に表示せず、決済済みの数字を表示することとしました

デメリット

• 実装工数がかかる

まとめ

• 「抽選方式D案: あらかじめ在庫を生成し、抽選時に在庫を減らしてそこからランダムで当選する」を今回は採用しました

まさかり受け付けます

• この手のロジック周りは炎上することが予想されます。もし誤字脱字、不可解なことがあれば、優しくご指摘いただけますと幸いですww(おかむーはガラスのハートです！！)

no plan inc.で扱っているTechに関する様々なジャンルをアウトプットします!!

no plan株式会社について

• no plan株式会社は 「テクノロジーの力でZEROから未来を創造する、精鋭クリエイター集団」 です。
• ブロックチェーン/AI技術をはじめとした、Webサイト開発、ネイティブアプリ開発、チーム育成、などWebサービス全般の開発から運用や教育、支援なども行っています。よくわからない、ふわふわしたノープラン状態でも大丈夫！ご一緒にプランを立てていきましょう！
• no plan株式会社について
• no plan株式会社 | web3実績
• no plan株式会社 | ブログ一覧
  エンジニアの採用も積極的に行なっていますので、興味がある方は是非ご連絡ください！
• CTOのDMはこちら