ガチャはソーシャルゲームの収益の柱ですが仕様が悪いとユーザさんが離れてしまう原因になってしまいます。

1万分ガチャしたのに、ゴミしかでなかった

というレビューが、ストアでチラホラ見られますからね。。。

ガチャはユーザさんにとってもお楽しみ要素が強いものですから、あまりにも出目が悪いと「せっかくお金を払ったのに、、、」とガッカリしてゲームの評価も下がってしまいます。
だからこそ、たとえお目当てのカードが手に入らなくても「まあこの結果ならいいか」と思ってもらえるような仕様を考えて置くことがベターです。

ということで、私が経験してきたガチャ施策とその設計についてご紹介いたします。

基本のガチャ設計

スキーマ

ガチャテーブル(ガチャID, 名称, 価格, 排出数, レアリティ設定ID, カード設定ID)
レアリティ設定テーブル(レアリティ設定ID, レアリティ, 重み)
カード設定テーブル(カード設定ID, レアリティ, カードID, 重み)
ガチャログテーブル(ユーザID, ガチャ設定ID, 実施回数)

実装

  1. ガチャテーブルに排出の設定を関連付ける
  2. レアリティ設定テーブルのデータで抽選処理を行いレアリティを決定する
  3. 2で決定したレアリティに従って、カード設定テーブルのデータで抽選処理を行い、排出するカードを決定する

抽選処理を「レアリティと実カードに分ける」理由は、レアリティに対する排出割合の調整を容易にするためです。

施策1:初回割引ガチャ

初回のガチャ価格を下げて、ガチャに対する障壁を下げる施策です。

スキーマ

ガチャテーブル(ガチャID, 名称, 価格, 割引価格, 排出数, レアリティ設定ID, カード設定ID)

「初回割引が1回」というケースの実装

  1. ガチャログテーブルをSELETする
  2. ログデータの有無から「そのガチャをはじめて実施する場合」に割引価格を適用します

“割引価格”カラムを数値型とします。

「割引が初回からN回まで」というケースの実装

ガチャの価格を段階的に引き上げていく施策で、”ステップアップガチャ”と言われますね。
私は、”割引価格”カラムを文字列型とし、「初回price=5」「2回目price=10」「3回目以降は通常価格」といった設計を行うことが多いです。

  1. ガチャログテーブルをSELETしガチャログテーブルのデータを”変数:実施回数”に代入する
  2. “変数:実施回数”を+1し、対応する価格設定を「今回の消費額」として適用する

施策2:1回だけお得ガチャ

お得な価格、お得な排出設定のガチャを回数限定で提供するガチャです。
キャンペーン用のお得なガチャとしてこういった要件が求められるケースが多いです。

スキーマ

ガチャテーブル(ガチャID, 名称, 価格, 実施可能回数, 排出数, レアリティ設定ID, カード設定ID)

基本のガチャテーブルに”実施可能回数”を追加しました。

実装

  1. 「実施可能回数 = 0」は制限なしと解釈する
  2. 「実施可能回数 >= 1」である場合、ガチャログテーブルをSELETする
  3. 実施可能回数の設定値と、ガチャログテーブルの実施回数を比較し「実施可能回数 > 実施回数」の場合はエラーとしてガチャの実行をSTOPする

施策3:重複排除ガチャ

これは「○連ガチャ」など、1回の実施で複数のリソースが排出されるガチャに対する施策で、1回あたりの排出物に重複がないようにするというものです。

ガチャの結果画面で「同じカード」が並ぶとガッカリ感がすごいんですよね。そのため、重複しにくくすることで心理的な負担を減らそうという施策です。
お手軽!

テーブル

変更なし

実装

  1. カード設定テーブルの抽選処理を行い、排出するカードを決定する
  2. 1で決定された排出データレコードを、次の抽選から除外する

施策4:レアリティ保障ガチャその1

「★3以上確定」など、必ず1枚はいいカードが排出されるようにする施策です。
これも連ガチャ向けの施策ですね。

必ず一定の対価が得られるため、ユーザさんの心理的負担はぐっと減ります。
逆に「連ガチャならこれ当たり前だろう!」という意見も多数です。

スキーマ

ガチャテーブル(ガチャID, 名称, 価格, 排出数, レアリティ設定ID, カード設定ID), 確定レアリティ, 確定レアリティ設定ID, 確定カード設定ID)

実装

  1. “排出数 -1″まで通常通りの抽選処理を行う
  2. その際、排出されたカードの最大レアリティを”変数:最大レアリティ”に代入する
  3. 最後の1枚を抽選する際、「”変数:最大レアリティ” >= “確定レアリティ”」が
    3-a. trueの場合、そのまま通常処理を行う
    3-b. falseの場合、”確定レアリティ設定ID”、”確定カード設定ID”のデータで抽選処理を行う

良心的な運営会社さんの場合、上記3-aの条件分岐を行わなかったりします。

施策5:レアリティ保障ガチャその2

例えば「10回に1回必ず★5が排出される」といった施策です。

上記の「レアリティ保障」が「対象ガチャ1回ごと」のものであるのに対し、こちらは「対象のガチャを複数回実施すると、もっともっといいカードが当たりますよ」というのが相違点です。
この施策の良いところは「1回目に★5が出れば、ユーザさんはそれ以上ガチャしなくても良い」し「9回目までに★5が出なくても、あと1回で必ず★5が手に入る」ことが保証される点にあります。

スキーマ

ガチャテーブル(ガチャID, 名称, 価格, 排出数, レアリティ設定ID, カード設定ID), 確定レアリティの保証回数, 確定レアリティ, 確定レアリティ設定ID, 確定カード設定ID)
ガチャログテーブル(ユーザID, ガチャ設定ID, 実施回数, 確定レアリティのチャレンジ回数)

実装

  1. ガチャログテーブルをSELECTし、”確定レアリティのチャレンジ回数”を得る
  2. 「”確定レアリティのチャレンジ回数 +1″ < “確定レアリティの保証回数”」が
    2-a. trueの場合、”変数:レアリティ保障発動フラグ”をfalseとする
    2-a. falseの場合、”変数:レアリティ保障発動フラグ”をtrueとする
  3. “排出数 -1″まで通常通りの抽選処理を行う
  4. その際、排出されたカードの最大レアリティを”変数:最大レアリティ”に代入する
  5. 最後の1枚を抽選する前段階で、「”変数:最大レアリティ” >= “確定レアリティ”」がtrueの場合、”変数:レアリティ保障発動フラグ”をfalseとする
  6. 最後の1枚を抽選するさい、”変数:レアリティ保障発動フラグ”が、
    6-a. trueの場合、そのまま通常処理を行う
    6-b. falseの場合、”確定レアリティ設定ID”、”確定カード設定ID”のデータで抽選処理を行い、”変数:最大レアリティ”に”確定レアリティ”を代入する
  7. 「変数:最大レアリティ」 >= “確定レアリティ”」が
    7-a. trueの場合、”確定レアリティのチャレンジ回数”を0にリセットし保存する
    7-b. falseの場合、”確定レアリティのチャレンジ回数”をインクリメントし保存する

ユーザさんに満足していただける施策を打って、愛されるコンテンツを提供していきましょう!

スポンサーリンク
ad_336
ad_336
  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存
スポンサーリンク
ad_336