JP7062311B2 - ゲームの評価方法、装置及びプログラム並びにアプリの評価方法 - Google Patents

Description

本開示は、ゲームの評価方法、装置及びプログラムに関する。

ゲームをリリース（発売）後に、そのゲームの売れ行きなどの営業情報又はプレイヤーの実際のプレイなどを評価して、ゲームの動作に必要なパラメータなどを変更することは、一部のゲームで行われていた。一方、ゲームをリリース（発売）前にプレイヤーの視点でそのゲームを評価して、その評価に基づいてゲームの各パラメータを視覚化し、それによってゲームのパラメータを変更又は調整することは従来行われていなかった。

ゲーム業界などでは、新しいゲームの開発段階で、プレイヤーがどのようにゲームを行うのかというゲームプレイ想定を作成することが多い。そして、作成したゲームプレイ想定に対するマスタのパラメータ設定値に基づいて、時間の経過に伴ってプレイヤーによってどれくらいのアイテムが獲得及び消費されるか、又はプレイヤーのステータスがどのぐらい成長するのかなどをシミュレーションすることは、部分的に行われていた。

例えば、あるゲームのクエスト１章の１で獲得できるアイテムが、アイテムＡが１個、アイテムＢが５個と設定した場合、クエスト１章の１を５回プレイした場合に、クエスト１章の１で獲得できるアイテム数は、アイテムＡが１個×５回＝５個で、アイテムＢが５個×５回＝２５個のようにシミュレーションすることはできる。しかしながら、このようなシミュレーションは、クエストの数やアイテムの数が多い場合には煩雑で手間が掛かる作業であるため、実際には行われていなかった。

特許文献１には、ゲームの販売後に、プレイヤーの操作入力のタイミングを評価して、その評価に基づいてゲームの難易度を変化させることが記載されている。しかしながら、特許文献１には、ゲーム販売前にゲームのパラメータを評価し、調整することは開示されていない（特許文献１）。

特開２０１９－４５７号公報

前述の通り、ゲームのプレイ想定を作成し、そのプレイ想定に基づいて各コンテンツにおけるアイテムなどの獲得量を計算することはできる。しかし、例えば、クエストも１章の中に１０個のクエストあり、章が１０章ある場合には、１０クエスト×１０章で合計１００個のコンテンツがあることになる。このような場合、プレイ想定を作ろうとすると、１００個のコンテンツに対する１００個もの詳細なプレイ想定を作らなければならい。また、通常のゲームでは、クエスト以外にも様々なコンテンツが有り、それらのコンテンツ毎に、難易度及びステージなどの詳細な区分単位でプレイ想定を作ることは手間がかかりすぎて現実的ではない。従って、こういったシミュレーションは、これまで、ゲーム販売前に行われなかったことも多く、又は行われたとしても、部分的かつ限定的であった。

一方、前述の従来の作業で可視化できるのはアイテムの獲得量のみであった。アイテムの消費量については、キャラクターの強化状況によっても変化するため、アイテムの消費量はどういう風にキャラクターを育成させるかなどの状況によっても左右される。ゲームのバランスで重要なのは、アイテムの獲得量単体よりも、アイテムの獲得量と消費量との収支である。このようなアイテムの収支を計算する場合、アイテムの獲得量と消費量を別々に算出し、それらを比較して収支バランスとして適切か見極める必要があるため、さらに手間がかかっていた。

また、パラメータ設定値などを記載するマスタのファイル中の各パラメータが他のパラメータと複雑に関係しており、さらに複数のマスタ間で入れ子構造になっている場合もある。例えば、クエスト１章の１で取れるアイテムを計算する場合、クエスト１章の１は、さらに細かく３ステージに分かれており、それぞれのステージには、敵となるモンスターが出現する。そして、それらのモンスターを倒すと、所定の確率で金・銀・銅の３つの宝箱が出現し、それぞれの宝箱を開けると、ぞれぞれの宝箱に応じたアイテムのセットが手に入る。それらのアイテムのセットのアイテム構成は、アイテムＡ、Ｂ、Ｃ…というように通常複数のアイテムを含むため、単純にこのクエストをクリアしたら各アイテムがどれくらい手に入るかという計算も複雑になる。さらに、コンテンツやゲームによって宝箱の構成にもかなり多様性があるため、ゲームが違う場合は当然ながら、同じゲーム内であっても異なるコンテンツの場合は、別々のシミュレーションロジックを使わなければならず、シミュレーションが煩雑で時間・労力が掛かる作業になってしまう。

これらの理由から、アイテムの収支を含めてゲーム全体のバランスを見ようとすると膨大な工数又は時間がかかる。その上、例えば、アイテムＡの獲得量を見るときに、異なる複数のコンテンツから同じアイテムＡが取得できるというようなケースが大半となっているため、前述の通りコンテンツが違うとマスタファイルの構造が異なり、同時にシミュレーションすることができない。そのため、個別のコンテンツのシミュレーション結果を別々に算出しなければならず、このアイテムはどのコンテンツからどれくらい取れるか、というのを一つのグラフで表すことは、非常に手間がかかる作業となっていた。

ゲームのバランスのシミュレーションを行おうとすると、詳細なプレイ想定を作るために膨大な工数がかかり、また、ゲームやコンテンツや機能が異なると、毎回異なるシミュレーションロジックを作らなければシミュレーションができないという問題があった。これらの結果として、従来は、ゲーム全体のバランスを包括的かつ詳細にシミュレーションをすることが事実上困難であつた。

結局、ゲームの収支バランスが悪いと、その結果、そのゲームの毎月の売上が不安定になったり、又は想定外に低い売上になったりして、そのゲームから得られる総収入が低迷する可能性が高い。

本開示が解決しようとする課題は、上述のように、ゲーム発売前にアイテムの収支を視覚化することによって、事前にゲームのパラメータを調整し、パラメータをより最適化することによって、ゲームの売上を最大化できない点である。

本開示によるゲームの評価方法は、コンピュータが、（Ａ）マスタのパラメータに基づいて、プレイヤーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記プレイヤーが行う想定回数との乗算を計算するステップと、（Ｂ）前記乗算の結果に基づいて、各アイテムの収支を視覚化するステップと、を実行する。

なお、これらの包括的又は具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、又は、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。

本開示によれば、ゲームのリリース前にゲームのバランスをシミュレーションすることによりそのゲームの収支バランスを容易に評価し、各パラメータに対する必要な調整をすることができる。そして、このようなゲーム発売前のパラメータの調整の結果、そのゲームは毎月安定して売上を上げることができ、その結果、そのゲームからの総売上を大きくすることが可能となる。

ゲームのレベルデザインの手順を示す図 ソーシャルゲームの売上推移の基本的なパターンを示す図 あるゲームのダンジョンの攻略時の各層のプレイヤーの被ダメージ量を示した図 マスタを整理することによるパラメータの可視化の例を示す図 本開示を適用してゲームの運用を改善した例を示す図 本開示を適用する前後のゲームにおける魔法石の収支を表す図 本開示の適用手順を示すフローチャート 従来の標準ではない入れ子構造のマスタを示す図 従来の標準ではない入れ子構造のマスタを示す図 本開示を適用した方法に従った標準のマスタを示す図 本開示の標準のマスタを示した図１０によって、各アイテムとその数量及び重みを整理して記載した表 本開示を適用したアウトプットを示す図１１から計算した各アイテムの期待値を示す図 標準ではないマスタを示した図 図１３の非標準のマスタを本開示を適用した標準のマスタに変換した図 図１４に示した本開示を適用した標準のマスタのアウトプットを示す図 図１４に示した本開示を適用した標準のマスタの期待値一覧を示す図 プレイ想定を示す図 各アクションにおける各アイテムの日毎の獲得個数を示す図 プレイ想定に従った各アイテムの日毎の獲得個数を集計した図 アイテムの消費量を説明する表 各アイテムの収支を示す表 本開示に従った動作を行うプログラムを実行するコンピュータのブロック図

本明細書において、「ゲーム」とは、何らかのコンピュータを使ったあらゆるタイプのコンピュータゲームを含み、制限なく、アーケードゲーム、コンシューマーゲーム、テレビゲーム、携帯型ゲーム、パソコンゲーム、携帯電話ゲーム、スマホゲーム、ソーシャルゲームを含む。

本明細書において、説明の便宜上、ゲームの例として主にソーシャルゲームを用いて説明するが、本開示の適用はソーシャルゲームに限定されず、あらゆるタイプのゲームに適用可能である。

本明細書において、「ソーシャルゲーム」とは、一人又は複数人のグループのユーザーで楽しむオンラインのゲームことであり、コミュニティ及びユーザー同士の協力又は対戦などの要素を含む。例えば、ソーシャルゲームは、ゲームの中で農園や街を造ったり、カードを集めてデッキで戦ったり、特定のパズルを解きながらステージを進んだりというアクションが行われる。ソーシャルゲームをプレイするための基本料金は通常は無料で、アイテムを購入する際の課金という形でゲームの提供者は利益を得ている。ソーシャルゲームは、「ソシャゲ」とも呼ばれる。

ソーシャルゲーム分野における基本用語は、必ずしも各ゲームメーカーで統一されていないので、本明細書における各用語を以下の通り定義する。

「キャラクター」とは、ゲームに登場する人物、動物、ロボット、機械又は架空の動物などのことであり、プレイヤーが操るなどしてゲームを成立させる、ゲームの物語に関わるキャラクターのことである。「キャラクター」は、「キャラ」又は「ゲームキャラ」とも呼ばれる。

「ガチャ」とは、元々「ガチャガチャ」又は「ガチャポン」という呼ばれる機械が名称の元になっており、ゲームにおいてはランダムに引いてアイテムなどを入手するための仕組みのことである。「ガチャ」は、通常、一部は無償で一部は有償である。

「カード」とは、ゲーム内で使用するプレイヤーの分身のようなものである。カードを複数枚集めてデッキ（又はチーム）を作成し、そのデッキを使用してゲーム内の敵又は他のプレイヤーと対戦するために使用する。カードは、ゲームによってはモンスターとも呼ばれる。

「カード」には一般に４つの要素があり、それらは、「レアリティ」、「コスト」、「パラメータ」及び「スキル」である。「レアリティ」は、カードの希少価値を表す。一般に、カードの希少価値が高いものほど、入手するのが困難である、すなわち、それを引く確率が低く、高価である。「コスト」は、複数のカードをデッキに並べる場合のカード全体のコストの上限である「コスト上限」として使用される。「パラメータ」は、カードに紐付けられた強さを表す値である。一般には、その他に「攻撃力」又は「防御力」などが設定されている。「攻撃力」が高いほど、攻撃によって相手に与えるダメージが強く、「防御力」が高いほど同じ攻撃力の相手から受けるダメージが小さい。「スキル」は、そのカードが使用できる固有の能力である。例えば、自分たちの攻撃力を上げたり、最初に攻撃できたりといった能力がある。

「クエスト」は、プレイヤーに出す課題のことであり、困っているキャラクターを助けるときなどに使用される。

「ステージ」は、ゲームの構成単位であり、一区切りのことである。

「ダンジョン」は、モンスターが出没するなどの仕掛けがあるエリアのことであり、ダンジョンはゲームの山場となっている。

「チャプター（章）」は、区切りのことであり、ステージと同義語である。

「アイテム」は、キャラクターがゲーム内で所有できる道具全般のことである。

「魔法石」は、アイテムの１つであり、ゲーム内で通貨のような役割を果たす。魔法石は、例えば、ガチャ、コンティニュー機能、スタミナ回復などに使用できる。

「ボス」は、各ステージの番人であり、このボスを倒すことによって次のステージに進むことができる。

図１は、ゲームのレベルデザインの手順を示す図である。一般に、ゲーム開発において、「レベルデザイン」とは、ゲームで使用される種々のパラメータの難易度（すなわち、数値）の調整を行う作業をいう。ソーシャルゲームなどのアプリでは、レベルデザイン＝パラメータ設定というイメージが強い。しかし、本明細書では、上流のＵＸ（Ｕｓｅｒ ｅＸｐｅｒｉｅｎｃｅ：ユーザー体験）ポリシー、つまりユーザーへどのような体験を届けるかの定義から、その先のデータ分析を含めて一連の流れをレベルデザインとして定義する。

上流のＵＸ（ユーザー体験）ポリシー決定１０１やゲームロジック設計１０２に問題があると、パラメータ設定１０３をいくら調整しても、売上が上がりにくい場合もあり得る。また、パラメータ設定１０３がＵＸ（ユーザー体験）を満たしているのかを分析して確認しないと、適切なパラメータ調整ができない場合もある。

本明細書において、レベルデザインは、図１に記載したように、ＵＸ（ユーザー体験）ポリシー決定１０１、ゲームロジック設計１０２、パラメータ設定１０３、ＵＸ（ユーザー体験）可視化１０４、ＫＰＩ設計１０５、ＵＸ（ユーザー体験）の確認１０６などのステップを含む。図１では、説明の便宜上６つのステップで説明しているかこれらのステップはさらに細かく分けられてもよく、６つのステップのいくつかは統合されてもよい。

本明細書では、上流のＵＸポリシー決定１０１、つまりユーザーへどのような体験を届けるかという定義から、その先のデータ分析を含めた一連の流れをレベルデザインに含めている。

ＵＸポリシー決定１０１は、ユーザー体験の方針、すなわちゲームの仕様を決定する段階である。

次のステップであるゲームロジック設計１０２では、ステップ１０１で決定したＵＸポリシーに基づいて、どういう仕組みでユーザーに楽しんでもらうかということを考える。すなわち、決定したＵＸポリシーをどんなロジックや式などで実現するかを検討する。例えば、グループでバトルを楽しんでもらう場面では、何人対何人で戦って、どれくらいの所要時間で、どういう攻撃方法があるか、などがゲームロジックに相当する部分である。一方、キャラクターの成長に関しては、どういう制約を入れて、どう試行錯誤してもらうか、というような事を決めることが、ゲームロジック設計１０２に含まれる。

ゲームロジック設計１０２において、難易度を表す式については、単調に時間と共に難易度を増加させていくのか、ゲームの後半から加速して難易度を上げるのか、又は難易度を最終的にある値に収束させるのか、というようなＵＸ（ユーザー体験）を数式などをベースで考える。ゲームロジックが破綻している、又は難易度を表す式の設定が不適切な場合、レベルデザインの上流で決定したＵＸポリシーがいくら良くても、そのようなゲームロジックに基づいて売れるゲームを実装することが困難となる。

次のステップであるパラメータ設定１０３では、それまでに決定したＵＸポリシー及び設計したゲームロジックに沿って各パラメータに数値を当てはめていく作業を行う。このパラメータ設定１０３では、ＵＸポリシーの大枠を、定量的にパラメータに変換していくことが必要となる。

例えば、街づくりゲームの場合、発生するあるアクシデントに関して、「そのアクシデントは、意外と頻発して起こる上に、ダメージも大きいのでスリリングな体験になる」というようなＵＸポリシーを仮定する。その場合は、「意外と頻発して起こる」という部分を、定量化して、例えば「６０分に１回発生する」としたり、「ダメージも大きい」という部分を定量化して、例えば、「最大でプレイヤーの所持金の７割が無くなる」という風に設定することができる。また、「スリリング」という部分を、例えば「ダメージがプレイヤーの所持金の１割から７割の間で毎回ランダムに変動する」というようにある程度の幅を持たせて設定してもよい。

このようにＵＸポリシーを決定することにより、このゲームのプレイヤーは、決定されたＵＸポリシーである「スリリングな体験」を経験することができる。また、このようにＵＸポリシーのパラメータへの定量化の作業を繰り返すことにより、ミスが発生しにくいパラメータ設定１０３が可能となる。

次のステップでは、ＵＸ可視化１０４を行う。ＵＸ可視化１０４では、パラメータの設定値が、決定したＵＸポリシー通りになっているかを可視化して、確認する。この場合、プレイヤーによるそのゲームのテストプレイは必要になるが、その前段階として、数値レベルでＵＸを可視化してパラメータを確認できるようにすると、パラメータの設定ミスという事故を大幅に減らすことができる。例えば、「あるキャラを育てるには何日掛かるか」のように、ＵＸを数値で大まかに表現する。これに対して、例えば、シミュレーションを行い、各パラメータを記述したマスタを整理することにより、ＵＸを可視化することができる。

シミュレーターを用いてＵＸの可視化を行うことによって、運用時のパラメータ設定ミスによる売上低下を防ぐ仕組みを提供することが可能となる。

例えば、あるゲームのあるダンジョンに入ってアイテムを取得する場面で、どのぐらいの時間でそのダンジョンで、どれくらいのアイテムが取れるかも重要なＵＸ（ユーザー体験）である。これはマスタを整理することにより可視化することができ、パラメータ設定ミスによる事故防止につながり得る。

次に、ＫＰＩ設計１０５で、ＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ：重要業績評価指標）を設計し、想定したＵＸとゲームをプレイした際の実際のＵＸの差分を確認するための準備を行う必要がある。例えば、「ヘビーユーザーは、一日に何回プレイして、何日間でここまでのクエストをクリアする」のようなイメージでゲームの想定が作られている場合、そのプレイヤー層のプレイ回数やクエストクリア状況が、そのＵＸを確認するためのＫＰＩになる。

最後のステップであるＵＸの確認１０６において、ゲームのリリース前に、前述の設計したＫＰＩを見ながら、想定したＵＸが提供できているかの確認を行う。その結果、ＵＸの確認１０６において、ＵＸポリシー決定１０１で決定したＵＸが提供できていない場合は、ゲームロジック設計１０２に戻ってゲームロジックを再設定し、又はパラメータ設定１０３に戻ってパラメータの再調整を行う。

図２は、ソーシャルゲームの売上推移の基本的なパターンを示す図である。図２において、横軸は時間を表し、縦軸はそのソーシャルゲームの売上を表す。

図２を参照すると、ゲームの売上に関して、ゲーム販売後から順番に「拡大期２０１」、「急減期２０２」及び「漸減期２０３」という３つのフェーズがあることが分かる。ゲームの発売後の最初の段階は、ユーザー数も客単価もどんどん上がり、その結果、ゲームからの売上がどんどん増えていく「拡大期２０１」である。その次は、ユーザーが急激に減って売上が急減する「急減期２０２」である。最後は、ある程度までユーザーが減ってさらに売上も減っていく「漸減期２０３」である。

良いゲーム、換言すれば売れるゲームは、リリース後にユーザー数及び売上が徐々に上がっていき、最大売上のピーク以降も売上低下が緩やかである（すなわち、急減期２０２が急に落ちない）。一方、売れないゲームは、リリース後にユーザー数及び売上が緩やかに立ち上がった後、ピークの最大売上も高くなく、その後、急速にユーザー数及び売上が減少することが多い。

売上の最大値（ピーク値）はゲーム自体のポテンシャル、すなわちゲーム自体の魅力に依存するところが大きいが、レベルデザイン（レベデザとも言う）をしっかり行うことで、拡大期２０１での売上の最大化の後押しや、売上がピークを迎えたあとの急減期２０２又は漸減期２０３でのユーザーの離脱や売上の低下をある程度防ぐことができ、その結果、長期的に見るとかなりの利益の向上が可能になる。

図２には、ゲームのレベルデザイン（レベデザ）が成功した例（実線）とレベルデザイン（レベデザ）が失敗した例（破線）が示されている。レベデザが成功した例（実線）では、拡大期２０１において、レベデザの成功により売上が最大化し（符号２１０）、急減期２０２及びその後の漸減期２０３においても売上が急激に落ち込むことはなく、ある程度維持することができる（符号２１１）。

前述のレベデザが成功した例（実線）に対して、レベデザが失敗した例（破線）では、拡大期２０１において、さほど売上の最大値は伸びず、売上のピーク値も低い（符号２２０）。そして、その後の急減期２０２及び漸減期２０３における売上の落ち込みが急である（符号２２１）。その結果、レベデザが失敗した例（破線）では、発売開始から最終的な発売終了までの売上総額も、レベデザが成功した例（実線）に対して小さいものになる。

ゲームのリリース前はそもそも売れるかどうか、すなわち、一定期間の最大売上額が重要と考えられがちであるが、昔と違って、現在は一度達成した売上を維持することがより重要になりつつあるので、適切なレベルデザインは従来以上に重要となっている。

図２に記載された拡大期２０１、急減期２０２及び漸減期２０３の３つのフェーズのそれぞれと関連する重要な要素がいくつかある。先ず、最初の拡大期２０１で大きく寄与するのが、「コアの楽しみ（２０４）」である。このコアの楽しみ（２０４）とは、アプリのインゲーム自体の面白さや、ＩＰやキャラクター、世界観の魅力などのことである。インゲームにおいても、ゲームロジックやパラメータ設定などで面白さを増加することはできるが、どうしてもコアの楽しみ（２０４）はレベルデザインだけではどうにもならない部分もあり得る。

インゲーム及びＩＰなどによるゲームのコアな楽しみ（２０４）の重要度は、図２の下の表を参照して、拡大期２０１が大きく（◎）、急減期２０２及び漸減期２０３では、ゲームのコアな楽しみ（２０４）の重要度が小さくなる（△）。

ステータスのインフレなどによる「成長実感（２０５）」の重要度は、急減期２０２が大きく（◎）、拡大期２０１及び漸減期２０３は中程度（○）である。

承認欲求や自己顕示欲などによる「英雄感（２０６）」の重要度は、拡大期（△）、急減期（○）、漸減期（◎）と時間の経過と共に徐々に大きくなっていく傾向がある。

各ゲームの売上は、もちろんそのゲーム自体のポテンシャル、すなわちゲーム自体の魅力に依存するが、同じゲームであっても、レベルデザインを適切に行うことによって、拡大期２０１において売上を早期に最大化でき、その後の急減期２０２及び漸減期２０３における減衰を遅らせることによって、１つのゲームから得られる収入を最大化することができる。

急減期２０２で重要なのが、「成長実感（２０５）」の要素になる。要するに、ゲームをやればやるほど強くなっていくような感覚をプレイヤーに常に体験してもらうことが重要である。例えば、これは、カードゲームでは、カードのステータスのインフレ（換言すれば、時間の経過と共にステータスや火力等が上がり続ける現象）などが相当するが、単にインフレさせるだけではなく、しっかりとその強さの体感がプレイヤーにフィードバックされる仕組み作りも重要になる。

最後の漸減期２０３で重要なのが、「英雄感（２０６）」という要素になる。この英雄感（２０６）は、プレイヤーが自分は活躍している、という感覚を持てるかどうかということである。例えば、プレイヤーがそのゲームのランキング上位に入賞するとか、又は、そのプレイヤーは良いカードやキャラを持っていてすごいな、と他のプレイヤーに思われるようなことである。

特に高い売上が長く続くゲームでは、この英雄感（２０６）の設計は長期的には非常に重要である。プレイヤー自身が英雄感（２０６）を感じることによって、長くそのゲームをプレイし、課金してくれる可能性が増加し、その結果、売上の上昇及び売上低下の抑制に繋がり得る。

これら３つの重要な要素である、コアの楽しみ（２０４）、成長実感（２０５）及び英雄感（２０６）は、互いに完全に切り分けられるものではないが、概ね前述のようにそれぞれ３つのフェーズである、拡大期２０１、急減期２０２及び漸減期２０３と対応していると考えられる。

図３には、あるゲームのあるダンジョンの攻略時の各層のプレイヤーの被ダメージ量、すなわち、勝率を示した図である。表の横軸には、プレイヤーのレベルが初心者、初級者、中級者、上級者、ランカーと、そのゲームが下手な人から上手い人へと５段階で順に記載されている。表の縦軸には、上から、エリア１からエリア７までのそのゲームの７つのエリアが記載されている。図３には、各レベルのプレイヤーの各エリアでの勝ち負けが、勝率（％）で記載されている。また，図３の右側の凡例を参照して、その勝率は、ＵＸ（ユーザー体験）として、上から、勝率の低い方から高い方へ、惨敗、惜敗、辛勝、勝利、楽勝の５段階に分類されている。

例えば、複数のエリアを探索するＲＰＧ（ロールプレーイングゲーム）がある場合、各エリアをクリアするまでに各層のプレイヤー又はパーティが受けるダメージ量（すなわち被ダメージ量）をシミュレートする。図３では、勝ち負けの境界をダメージ量で１００％とし、ダメージ量が１００を超えると負けであり、１００以下だと勝ちと仮定する。このシミュレーションにより、例えば、初級者は、エリア５はクリアできないが（被ダメージ量が１１０％、すなわち、惜敗する）、エリア５の一つ下のレベルのエリア４はギリギリクリアする（被ダメージ量が９０％、すなわち、辛勝する）。

一方、上級者は、エリア３は、容易にクリアでき（被ダメージ量が４０％、すなわち、楽勝する）、エリア６はぎりぎりクリアし、（被ダメージ量が７５％、すなわち、辛勝する）、エリア７もギリギリクリアする（被ダメージ量が９０％、すなわち、辛勝する）。

このようにプレイヤーのレベルと各エリアの難易度（すなわち、被ダメージ量）が表に記載され、ＵＸが網羅的に可視化されるので、図３のようにパラメータを可視化すると、パラメータの設定ミスによるパラメータ事故を大幅に減らすことができる。

実際のゲーム運用時に売上が大きく減る原因は、このパラメータ設定が上手く行っていないケースが多い。例えば、重要アイテムを配布しすぎて成長実感のバランスが壊れたり、特定のキャラクターがバランスを崩して英雄感が損なわれたりするなどのパラメータ設定ミスが起こって、長期的に売上が思ったほど上がらないというようなことが実際に起こり得る。

これらの原因は、結果的にはパラメータ設定ミスに起因するが、直接的には、ＵＸ（ユーザー体験）の可視化がなされていないことがその原因となり得る。

図４は、パラメータを定義するマスタ（又はマスタファイル）を整理することによるパラメータの可視化の例を示す図である。図４の左側の表（４１０）には、左側の列から順に、ゲームのマスタに含まれるクエストＩＤ、アイテムＩＤ、数量が記載されている。この左側の表（４１０）に基づいて、アイテムをクエスト毎に整理したのが右側の表（４２０）である。右側の表（４２０）は、左側の列から順番にＩＤ、アイテム名、クエスト名と並んでおり、クエスト名の大きなグループの中にさらに詳細なクエストの具体名が、草原、洞窟、鉱山と記載されている。

例えば、図４の右の表（４２０）において、ＩＤ＝１の行では、アイテム名は薬草であり、この薬草は、草原に１個、洞窟に２個、鉱山に３個あることが分かる。同様に、ＩＤ＝２の行では、アイテム名は小回復薬で、この小回復薬は、洞窟に２個あるが、草原及び鉱山にはないことが分かる。ＩＤ＝３の行では、アイテム名が欠片であり、この欠片は、草原に１個あるが、洞窟及び鉱山にはないことが分かる。ＩＤが４～６に対して、鉄鉱石、宝石、カードがそれぞれ、各クエストに何個あるかが右の表（４２０）に記載されている。

このようにゲームのマスタ形式の左の表（４１０）をアイテム毎に整理することによって作成した右の表（４２０）は、各アイテムがどのクエストで何個取得できるか、左の表（４１０）より、容易に理解することができる。

図５は、本開示を適用してゲームの運用を改善した例を示す図である。ゲームを設計する場合には、ユーザーをいくつかのカテゴリに分けて、それぞれのカテゴリのプレイヤーが楽しめるようなコンテンツをそれぞれ用意する必要がある。図５の例では、簡単のため、ユーザーをゲームの習熟度に応じて３つのカテゴリ、すなわち、初心者、中間層、コア層（上級者）に分けている。

例えば、発売前のゲーム設計の初期の段階で、そのゲームの各ユーザー層に対する難易度を評価した場合に、図５の左図（５１０）のように、初心者向けコンテンツをクリアできるプレイヤーが多いのに対して、中間層向けコンテンツをクリアできるプレイヤーが少ないという状況に陥る場合がある。このような場合、プレイヤーがゲームの全行程の中で途中の中間層で詰まってしまう状況が起こり得る。このような状況に陥ると、特に中間層プレイヤーは、中々より上位のコア層に上がれないので、このゲームを連続してプレイする意欲が低下し、数の多い中間層プレイヤーからの売上が減ることになり、ゲーム全体としての売上も減少する。

図５の左図（５１０）のように各層のプレイヤーがクリアできるバランスが悪い場合は、本開示のパラメータの評価をゲーム発売前にこのゲームに適用することによって、中間層向けのコンテンツを左図（５１０）より容易にすることにより、初心者、中間層向け及びコア層向けの各レベル向けのコンテンツをクリアできる人数のバランスを取ることが可能となる。右図（５２０）では、左図（５１０）より中間層向けコンテンツを容易にした結果、中間層向けのコンテンツをクリアできるプレイヤーの人数が多くなり（すなわち、コア層向けコンテンツに挑戦できるプレイヤーの人数が増え）、中間層プレイヤーがより継続してプレイしてくれるので、全体としてそのゲームから得られる収入がさらに最大化することが可能となる。

図６は、本開示を適用する前後のゲームにおける魔法石の収支を表す図である。魔法石は、上述の通りアイテムの１種であり、そのゲーム内で通貨のような役割をはたす。本開示の適用前のパラメータ調整前の図（６００）及び本開示の適用後のパラメータ調整後の図（６５０）の横軸は、いずれもプレイ日数を表しており、一番左側のプレイ日数１日目から一番右側のプレイ日数６０日目までを表す。本開示の適用前の図（６００）及び本開示の適用後の図（６５０）の縦軸は、いずれも魔法石の収支（個数）を表している。各図の各プレイ日数における３本の棒グラフの一番左の棒グラフは、魔法石の獲得量、真ん中の棒グラフは、魔法石の消費量、一番右の棒グラフは、魔法石の獲得量から消費量を引いた差（収支）を表す。図６の左図（６００）及び右図（６５０）から、いずれの場合も、プレイヤーのそのゲームのプレイ日数に従って、魔法石の獲得量及び消費量が増えていることが分かる。

本開示を適用する前の図６００を参照すると、プレイ日数１日、３日、５日、７日、１４日、３０日、６０日と経過日数に伴って、収支（獲得－消費）が増えていることが分かる。また、プレイ日数６０日の時点で、獲得量は、購入した有償石の４５００と、イベントの５０００と、通常クエストの３０００と、ログインボーナスの６００の合計である、１３１００となる。本開示を適用する前の図６００を参照すると、プレイ日数６０日の時点で、消費量は、イベントガチャ（イベガチャ）の６０００と、通常ガチャの２４００の合計である、８４００となる（ここでは、無料のガチャは考えない）。従って、本開示を適用する前のプレイ日数６０日時点での獲得量－消費量である収支は、４７００である。

これに対して、本開示を適用した後の図６５０を参照すると、プレイ日数１日、３日、５日、７日、１４日、３０日、６０日と経過日数に伴って、３日目で一旦増えた収支がその後、多少の増減はあるが、最終的には減っていることが分かる。また、プレイ日数６０日の時点で、獲得量は、購入した有償石の４５００と、イベントの２５００と、通常クエストの１０５０と、ログインボーナスの３００の合計である、８３５０となる。本開示を適用した後の図６５０を参照すると、プレイ日数６０日の時点で、消費量は、イベントガチャ（イベガチャ）の６０００と、通常ガチャの２４００の合計である、８４００となる。従って、本開示の適用した後の獲得量－消費量である収支は、－５０である。

このように本開示を適用する前のプレイ日数６０日目の収支は４７００となり、魔法石の獲得量と消費量のバランスが悪い（すなわち、消費量が獲得量に対して少なすぎる）。これに対して、本開示を適用した後のプレイ日数６０日目の収支は－５０となり、魔法石の獲得量と消費表の差が小さく（すなわち、消費量と獲得量のバランスが良い）、且つ魔法石の消費量も多く、ガチャでの課金が促進されるので、本ゲームからの収入をより最大化することができる。

図７は、本開示の適用手順を示すフローチャートである。ここで「マスタ」とは、ゲームで使用するパラメータなどを記述する表形式などのデータのことであり、「マスタ形式」とは、このマスタで使用される形式（フォーマット）のことである。

１つのマスタのみで、そのゲームで使用されるすべての要素のパラメータが記述される場合もあるが、通常は、親マスタの内容がさらに子マスタ、孫マスタなどによって段階的に記述される場合もあり、そのような場合は、マスタが複数段の入れ子構造になっている。マスタが入れ子構造になっている場合は、例えば、親マスタのアイテムが、さらに子マスタの中でさらに詳細に規定されており、このような場合は、親マスタだけを見てもそのアイテムの詳細が分からない。

先ず、本開示の方法によるプログラムはコンピュータによって実行されると、標準ではないマスタ形式のマスタを本開示が適用された標準のマスタ形式に変換する（Ｓ７０１）。標準ではないマスタ形式の標準のマスタ形式への変換（Ｓ７０１）は、コンピュータを用いて実行してもよいが、手作業で行ってもよい。通常は、標準でないマスタ形式で、ゲーム開発会社からそのゲームで使用するすべてのマスタが提供される。同じゲーム開発会社が開発したゲームであっても、ゲームが異なれば又は同じゲームであってもバージョンが異なれば、マスタ形式が統一されておらず、マスタの形式が異なっていることも多い。標準のマスタ形式としては、ゲーム制作会社、ゲーム又はゲームのバージョンなどが異なっても統一された同じ形式のものが使用される。

標準のマスタ形式に変換されたマスタを使用して、各要素（例えば、アイテム）の期待値×想定を計算する（Ｓ７０２）。ここで、期待値とは、プレイヤーがあるアクションをしたときに各アイテムを取得及び消費する値であり、想定回数は、アクションをプレイヤーが行うと推定した回数である。この期待値×想定を計算することにより、例えば、あるコンテンツにおいて、あるアイテムを何個取得できるかを予測することが可能となる。

次に、アイテムの獲得量、消費量、及び獲得量と消費量の収支をシミュレーションして、その結果を視覚化することによって、対象となるパラメータを使った結果を視覚化することができる（Ｓ７０３）。このようなアイテムの獲得量、消費量及び収支をシミュレーションした結果を視覚化した図が、例えば、既に説明した、図６に記載した図（６００）である。

最後に、シミュレーション結果によって視覚化されたアイテムの収支などに基づいて、パラメータを調整する（Ｓ７０４）。具体的には、図６に記載した図（６００）のゲーム開始からの各経過日数における、アイテムの獲得・消費による収支のバランスが取れているか否かを見る。図６の図（６００）を見ると、例えば、経過日数６０日目の獲得量が消費量に対して大きく、収支が＋４７００とバランスが悪くなっていることが分かる。

本開示を適用することによりゲームの開発者は、図６の左上の図（６００）のこの収支のアンバランスを見て、マスタ中の各パラメータを適切に調整することによって、アイテムの収支のバランスを改善することができる。このようにパラメータを調整して収支を改善した結果を示すのが図６の右下の図（６５０）である。図６の右下の図（６５０）を見ると、ゲーム開始からの各プレイ経過日数において、特に経過日数７日目以降の収支のバランスが取れており（すなわち、獲得量の棒グラフと消費量の棒グラフの高さに対して、収支の棒グラフの高さが相対的に低い）、売上の最大化に関して、調整後のパラメータがより適切であることが分かる。

Ｓ７０４でパラメータを調整した後、任意選択で、Ｓ７０２に戻って、再度、調整後のパラメータに基づいて、期待値×想定の値を計算し、Ｓ７０２で新たに計算された結果に基づいて、アイテムの収支を再度シュミレーションして、Ｓ７０３でパラメータを再度視覚化し、その結果、さらにパラメータの微調整が必要ならＳ７０４で、このシミュレーションの結果に基づいて、再度パラメータ調整の調整を行ってもよい。

再度のパラメータ調整の結果、必要ならもう一度Ｓ７０２からＳ７０４のステップを繰り返してもよい。

これから図８から図１６を使って、図７のＳ７０１及びＳ７０２に関連する処理についてさらに詳細に説明する。図８及び図９は、ゲームを作成する際にゲーム制作会社などが作る標準ではないマスタであり、図１０は、本開示を適用した標準のマスタである。

図８は、従来の標準ではない入れ子構造のマスタを示す図である。図８には、４つのマスタが記載されており、それぞれの関係についてこれから説明する。

図８の一番上の表は、あるゲームのマスタ（親マスタ）であり、ｓｔｏｒｙ＿ｑｕｅｓｔ＿ｍａｓｔｅｒ（８０１）と言う名前が付けられている。まず、このような統一されていない（すなわち、標準ではない）マスタの構造として、クエストやガチャを引いたときに、そのアクションをしたら、何を、どのような確率で、獲得できるかなどの情報がこのマスタの情報に含まれている。

１つのマスタの表で直接もらえるアイテムを指定している形式もあるが、報酬グループなどという形で間接的にもらえるアイテムのグループリストのｉｄを指定していることもある。そして、さらにマスタに記載された対象となるｉｄの詳細が書いてある別のマスタを参照すると、そこでさらに別のグループリストが指定されているという形で入れ子構造になっている事もある。

例えば、図８の例では、大本のマスタ（すなわち親マスタ）であるｓｔｏｒｙ＿ｑｕｅｓｔ＿ｍａｓｔｅｒ（８０１）という表があり、それぞれのストーリーのｉｄが「１０００１」、「１０００２」、「１０００３」と一番左のｉｄの列に書いてある。それぞれのストーリーのｉｄに対して、ｆｉｒｓｔ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｉｄという最初（初回）だけ取れるアイテムのｉｄと、ｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｉｄという毎回取れるアイテムのｉｄが記載されている。これらのそれぞれは、１０００１などのストーリーのｉｄの列の右の列に順番に記載されている。

例えば、図８では、ストーリーのｉｄが１０００１である場合、ｆｉｒｓｔ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｉｄが指定するアイテムのグループリストは、１００１であり、ｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｉｄが指定するアイテムのグループリストは、２０１である。

これに対して、初回だけの報酬のグループの場合、ｆｉｒｓｔ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｍａｓｔｅｒ（８０２）という別のマスタ（子マスタ）があり、その中でグループｉｄが「１００１」のものは、ｉｔｅｍ＿ｉｄが「１１」のものが「１０」個（ａｍｏｕｎｔ）取れるということが記載されている（８１０の流れ）。このように、２つ以上の複数のマスタを経由しないと（この場合は、親と子の２つのマスタ）、最終的に対象のクエストにおいて、いったいどれくらいのアイテムが取れるかというのを具体的に知ることができない場合がある。例えば、アイテム１１は、ｓｔｏｒｙ＿ｑｕｅｓｔ＿ｍａｓｔｅｒ（８０１）という親マスタからｆｉｒｓｔ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｍａｓｔｅｒ（８０２）という子マスタを参照すれば、アイテムの取得量が分かる。

次に、ｓｔｏｒｙ＿ｑｕｅｓｔ＿ｍａｓｔｅｒ（８０１）でｉｄが「１０００１」の場合、毎回取れるアイテムのｉｄ（ｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｉｄ）は、「２０１」である。このｉｄ「２０１」のアイテムは、さらに別のマスタ（子マスタ）ｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｍａｓｔｅｒ（８０３）を参照すると、ｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｉｄが「２００１」と分かる（８２０の流れ）。次に、別のマスタ（孫マスタ）ｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｍａｓｔｅｒ（８０４）を参照すると、ｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｉｄが「２００１」に対するアイテムｉｄ（ｉｔｅｍ＿ｉｄ）が「２１」であり、重み（ｗｅｉｇｈｔ）が１００００であり、数量（ａｍｏｕｎｔ）が「５」であることが分かる（８２５の流れ）。ｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｉｄに対しては、ｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｍａｓｔｅｒ（８０３）及びｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｍａｓｔｅｒ（８０４）という２つの別々のマスタ（子マスタと孫マスタ）を経由しないと（８２０及び８２５の流れ）、どのアイテムがどのぐらいの確率で取れるか分からない。すなわち、この場合は、マスタが３階層構造（すなわち、マスタが８０１、８０３及び８０４の３つ）になっている。

図９は、従来の標準ではない入れ子構造のマスタを示す図である。図９には、３つのマスタが記載されており、それぞれの関係についてこれから説明する。

図９は、ガチャのマスタの構造の一例を示す図である。図８はクエストのマスタ構造を示していたが、図９はガチャのマスタ構造を示している。ガチャのようにある確率で何がもらえるか分からないようなものも、通常は、図８と同様にマスタが何段階かの入れ子構造となっている。図９を参照して、先ず、ｇａｃｈａ＿ｍａｓｔｅｒ（９０１）というマスタに、ガチャのｉｄが「５０００１」、「５０００２」と記載されている。ガチャの各ｉｄに対してもらえるアイテムについてはｌｏｔ＿ｔａｂｌｅ＿ｉｄの列にそれぞれ「５０１」、「５０２」のように参照すべきグループが指定されている。すなわち、親マスタであるｇａｃｈａ＿ｍａｓｔｅｒ（９０１）だけを参照しても、何がどのような確率でもらえるのか分からない（すなわち、親マスタであるｇａｃｈａ＿ｍａｓｔｅｒ（９０１）にはｗｅｉｇｈｔ（重み）を表す列がない）。

次に、ｇａｃｈａ＿ｌｏｔ＿ｔａｂｌｅ＿ｍａｓｔｅｒ（９０２）というマスタを参照すると、ｉｄが「５０１」というガチャのグループの中に希少性（ｒａｒｉｔｙ）としてのレベルが、ＳＲ（Ｓｕｐｅｒ Ｒａｒｅ：極めて希少）、ＳＳＲ（Ｓｕｐｅｒ Ｓｕｐｅｒ Ｒａｒｅ：極めて極めて希少）、ＵＲ（Ｕｌｔｒａ Ｒａｒｅ：超希少）という３つがあることが分かる（９１０の流れ）。ガチャの場合は、ある重み（ｗｅｉｇｈｔ）で何かが取れるという形になっているので、例えば、ガチャｉｄが５０００１の場合、ＳＲというグループ、ＳＳＲというグループ、ＵＲというグループが取れる重み（ｗｅｉｇｈｔ）は、それぞれ８０、１５、５というようにｇａｃｈａ＿ｌｏｔ＿ｔａｂｌｅ＿ｍａｓｔｅｒ（９０２）に記載されている。

ここで、重み（ｗｅｉｇｈｔ）とは、無次元量であり、それぞれの事象が発生する相対比を表す。従って、それぞれの事象が発生する確率は、対象の事象の重みを同じグループの事象の重みの合計で割った値になる。例えば、この場合、ガチャｉｄ５０１に関して、ＳＲが発生する確率は、ＳＲ自身の重みをＳＲ、ＳＳＲ、ＵＲの３つすべての重みの合計、すなわち１００（＝８０＋１５＋５）で割った値であるので、ＳＲが発生する確率は、８０÷１００＝８０％となる。同様に、ＳＳＲの発生確率は、１５％であり、ＵＲの発生確率は、５％となる。ただし、重みを使わないで、直接発生確率をマスタに記載してもよい。

次に、希少性（ｒａｒｉｔｙ）については、ＳＲ、ＳＳＲ、ＵＲという各グループで何が取れるかを記述するマスタ、ｇａｃｈａ＿ｐｒｉｚｅ＿ｔａｂｌｅ＿ｍａｓｔｅｒ（９０３）を参照する。ｇａｃｈａ＿ｐｒｉｚｅ＿ｔａｂｌｅ＿ｍａｓｔｅｒ（９０３）を参照すると、ＳＲグループには「ＳＲ＿Ａ」、「ＳＲ＿Ｂ」、「ＳＲ＿Ｃ」という３種類のキャラクター（ｃｈａｒａ）が記載されており、それぞれの重み（ｗｅｉｇｈｔ）の値がいずれも「１０」となっている（９２０の流れ）。すなわち、「ＳＲ＿Ａ」、「ＳＲ＿Ｂ」、「ＳＲ＿Ｃ」という３種類のキャラクターの重みは、それぞれ、１０：１０：１０（すなわち、１：１：１）であり、各キャラクターは、３３．３％（＝１０÷（１０＋１０＋１０））の確率でもらえることが分かる。

このように、クエストのマスタに関しては、前述の図８のｆｉｒｓｔ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｉｄ（８０２）のように報酬のグループが指定されている場合や、図９に記載されたガチャのＳＲようにグループのマスタ（すなわち、ｇａｃｈａ＿ｌｏｔ＿ｔａｂｌｅ＿ｍａｓｔｅｒ（９０２））が指定されていてその中から、どれがどのくらいの割合で出るかという重み（ｗｅｉｇｈｔ）がかかっており、且つ個別のアイテム名ではなくて、ＳＲ、ＳＳＲ、ＵＲなどのグループ名を指定して、さらにその中で細かく指定していくような多重の入れ子構造になっていることもある。

このように通常、各ゲームの各マスタは、一段又は複数段の入れ子構造になっているが、どれが途中段階のグループのまとまりであり、どれが最終的に分解されたグループかということをそれぞれ指定することで統一性のある標準のマスタに変換することができると発明者は考えた。

図１０は、本開示を適用した方法に従った標準のマスタを示す図である。本開示の方法では、ｇｒｏｕｐ＿ｔｒａｎｓ＿１＿ｃｏｎｆ（１０１０）として大本のマスタを規定する。ｇｒｏｕｐ＿ｔｒａｎｓ＿１＿ｃｏｎｆ（１０１０）では大きい括りと小さい括りの列（カラム）はどれかを指定する。本開示を適用した方法に従った表では、一番左に入力元となるマスタ（ｉｎｐｕｔ＿ｆｉｌｅ）が指定される。この例のｇｒｏｕｐ＿ｔｒａｎｓ＿１＿ｃｏｎｆ（１０１０）では、４つの入力マスタが上から順にｓｔｏｒｙ＿ｑｕｅｓｔ＿ｍａｓｔｅｒ、ｓｔｏｒｙ＿ｑｕｅｓｔ＿ｍａｓｔｅｒ、ｇａｃｈａ＿ｍａｓｔｅｒ、ｇａｃｈａ＿ｍａｓｔｅｒである。ここで、ｓｔｏｒｙ＿ｑｕｅｓｔ＿ｍａｓｔｅｒとｇａｃｈａ＿ｍａｓｔｅｒは、二回出てくるが、各行で参照している子マスタが異なる。

２つのマスタ、ｓｔｏｒｙ＿ｑｕｅｓｔ＿ｍａｓｔｅｒとｇａｃｈａ＿ｍａｓｔｅｒは、それぞれ、図８に記載されたｓｔｏｒｙ＿ｑｕｅｓｔ＿ｍａｓｔｅｒ（８０１）と図９に記載されたｇａｃｈａ＿ｍａｓｔｅｒ（９０１）に対応している。

本開示の方法では、図１０の３つの入力マスタにあるグループｉｄの列（ｇｒｏｕｐ＿ｉｄ＿ｃｏｌｕｍｎ）はクエスト名で、その右の列でそのクエストでは何が取れるかというのを指定したのがｓｅｐａｒａｔｉｏｎ＿ｉｄ＿ｃｏｌｕｍｎになる。ストーリークエストの場合、大本のクエストのｉｄをｇｒｏｕｐ＿ｉｄ＿ｃｏｌｕｍｎにおいて指定して、取れる報酬をｓｅｐａｒａｔｉｏｎ＿ｉｄ＿ｃｏｌｕｍｎで指定してもよい。

本開示の方法では、ｇｒｏｕｐ＿ｔｒａｎｓ＿１＿ｃｏｎｆ（１０１０）として一番大きいマスタを規定する。ｇｒｏｕｐ＿ｔｒａｎｓ＿１＿ｃｏｎｆ（１０１０）では大きい括りと小さい括りのカラムはどれかを指定する。さらに、その中のｓｅｌｅｃｔ＿ｔｙｐｅ＿ｃｏｌｕｍｎでは初回のみ報酬を取れる場合を「ｆｉｒｓｔ」と指定し、毎回報酬を取れる場合を「ｌｏｏｐ」と指定する。この例では、ｓｅｌｅｃｔ＿ｔｙｐｅ＿ｃｏｌｕｍｎは、「ｆｉｒｓｔ（初回のみ）」と「ｌｏｏｐ（毎回）」の２種類を指定しているが、この種類は、３種類以上であってもよい。

図１０では、分解したグループｓｅｐａｒａｔｉｏｎ＿ｉｄ＿ｃｏｌｕｍｎとしてｆｉｒｓｔ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｉｄやｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｉｄを指定しているが、これらのグループｉｄ自体はｉｔｅｍ＿ｉｄという最小の単位にはなれないので、ｆｉｒｓｔ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｉｄやｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｉｄをさらに細かく規定するマスタをｓｅｐａｒａｔｉｏｎ＿ｉｄ＿ｍａｓｔｅｒの列で指定して、次に、ｓｅｐａｒａｔｉｏｎ＿ｉｄ＿ｍａｓｔｅｒで指定したマスタを参照する。

次に、ｇｒｏｕｐ＿ｔｒａｎｓ＿２＿ｃｏｎｆ（１０２０）中のｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｍａｓｔｅｒとｇａｃｈａ＿ｌｏｔ＿ｔａｂｌｅ＿ｍａｓｔｅｒを参照して、グループｉｄとしては何を持っていて、最終的にどのｉｄを見るかということを行う。ｆｉｒｓｔ＿ｒｅｗａｒｄ＿ｇｒｏｕｐ＿ｍａｓｔｅｒの場合、ｇｒｏｕｐ＿ｔｒａｎｓ＿２＿ｃｏｎｆ（１０２０）で最終的なｉｔｅｍ＿ｉｄがｓｅｐａｒａｔｉｏｎ＿ｉｄ＿ｃｏｌｕｍｎに記載されているので、分解先（参照先）としてはｇｒｏｕｐ＿ｔｒａｎｓ＿２＿ｃｏｎｆ（１０２０）の中の値が最終値になり、獲得個数を指定しているのはａｍｏｕｎｔ＿ｃｏｌｕｍｎになる。例えば、ａｍｏｕｎｔ＿ｃｏｌｕｍｎが空欄の場合は、数量は「１」と規定してもよい。

次に、ｇｒｏｕｐ＿ｔｒａｎｓ＿３＿ｃｏｎｆ（１０３０）中のｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｍａｓｔｅｒとｇａｃｈａ＿ｐｒｉｚｅ＿ｔａｂｌｅ＿ｍａｓｔｅｒを参照して、グループｉｄとしては何を持っていて、最終的にどのｉｄを見るかということを行う。ｒａｎｄｏｍ＿ｒｅｗａｒｄ＿ｍａｓｔｅｒの場合、ｇｒｏｕｐ＿ｔｒａｎｓ＿３＿ｃｏｎｆ（１０３０）で最終的なｉｔｅｍ＿ｉｄがｓｅｐａｒａｔｉｏｎ＿ｉｄ＿ｃｏｌｕｍｎに記載されているので、分解先としてはｇｒｏｕｐ＿ｔｒａｎｓ＿３＿ｃｏｎｆ（１０３０）の中の値が最終値になり、獲得個数を指定しているのはａｍｏｕｎｔ＿ｃｏｌｕｍｎであり、重みはｗｅｉｇｈｔ＿ｃｏｌｕｍｎで指定される。例えば、ａｍｏｕｎｔ＿ｃｏｌｕｍｎが空欄の場合は、数量は「１」と規定してもよい。

このような操作を繰り返す事でどのゲームメーカーのどのタイトルでも通用する標準のマスタを作成できる。図１０を参照して説明したように、一番大きいグループからより小さなグループに分解するマスタがｇｒｏｕｐ＿ｔｒａｎｓ＿１＿ｃｏｎｆ（１０１０）で、さらにそれを細かく分解するのがｇｒｏｕｐ＿ｔｒａｎｓ＿２＿ｃｏｎｆ（１０２０）で、さらにそれを細かく分解するがｇｒｏｕｐ＿ｔｒａｎｓ＿３＿ｃｏｎｆ（１０３０）という形で、同じ構造のマスタでどんどん連結できるという構造になる。この状態でマッピングすると、前述のロジックに従ってアウトプットとしてはｇｒｏｕｐ＿ｉｄがこれ、ｓｅｐａｒａｔｉｏｎ＿ｉｄがこれと表示され、さらにそれぞれ初回報酬なのか毎回もらえる報酬なのかによって参照先が分かれていく。

図１１は、本開示の標準のマスタを示した図１０によって、各アイテムとその数量及び重みを整理して記載した表である。図１１に記載の各表には、左の列から、行番号、ｇｒｏｕｐ＿ｉｄ、ｓｅｐａｒａｔｉｏｎ＿ｉｄ、ｓｅｌｅｃｔ＿ｔｙｐｅ、ａｍｏｕｎｔ（数量）、ｗｅｉｇｈｔ（重み）が記載されている。

図１１に記載した３つのマスタ、ｇｒｏｕｐ＿ｔｒａｎｓ＿１（１１１０）、ｇｒｏｕｐ＿ｔｒａｎｓ＿２（１１２０）、ｇｒｏｕｐ＿ｔｒａｎｓ＿３（１１３０）には、ｇｒｏｕｐ＿ｉｄの列で示されたアクションをすると、ｓｅｐａｒａｔｉｏｎ＿ｉｄの列に記載されたものがａｍｏｕｎｔの列に記載された量もらえるという形式になっている。次に、ｓｅｐａｒａｔｉｏｎ＿ｉｄになっているものが次のｇｒｏｕｐ＿ｔｒａｎｓ＿ｘ（ここでｘは１以上の整数）のｇｒｏｕｐ＿ｉｄになる。例えば、ｇｒｏｕｐ＿ｔｒａｎｓ＿１（１１１０）のｇｒｏｕｐ＿ｉｄが「１０００１」と指定されたものに対してｓｅｐａｒａｔｉｏｎ＿ｉｄが「１００１」となっているものは、次のｇｒｏｕｐ＿ｔｒａｎｓ＿２（１１２０）のｇｒｏｕｐ＿ｉｄが「１００１」ときて（１１１１の流れ）、さらにその「１１」というアイテムｉｄ（ｓｅｐａｒａｔｉｏｎ＿ｉｄ）に分解されるという形で、それぞれグループのもの、分解されたものという関係がどんどんでき上がっていく。このような形で、すべてのマスタは標準化されて、本開示を適用したテンプレートの標準のマスタに移行することができる。

これを元に「１０００１」というアクションを一回実行すると最終的なアイテムが期待値として何個取れるかという計算が行われる。

ｇｒｏｕｐ＿ｔｒａｎｓ＿１（１１１０）からｇｒｏｕｐ＿ｔｒａｎｓ＿３（１１３０）への流れは、以下の通りである。
ｇｒｏｕｐ＿ｉｄ（ｇｒｏｕｐ＿ｔｒａｎｓ＿１（以下最後の番号のみ表示する））→
ｓｅｐａｒａｔｉｏｎ＿ｉｄ（１）：ｒａｔｅ（１），ａｍｏｕｎｔ（１）
ｇｒｏｕｐ＿ｉｄ（２）→
ｓｅｐａｒａｔｉｏｎ＿ｉｄ（２）：ｒａｔｅ（２），ａｍｏｕｎｔ（２）
ｇｒｏｕｐ＿ｉｄ（３）→
ｓｅｐａｒａｔｉｏｎ＿ｉｄ（３）：ｒａｔｅ（３），ａｍｏｕｎｔ（３）

ここで、ｇｒｏｕｐ＿ｔｒａｎｓ＿ｘでｇｒｏｕｐ＿ｉｄ（ｘ）を獲得したときに、一つのｇｒｏｕｐ＿ｉｄ（ｘ）に対して、ｓｅｐａｒａｔｉｏｎ＿ｉｄ（ｘ，ｍ（１））、ｓｅｐａｒａｔｉｏｎ＿ｉｄ（ｘ，ｍ（２））、…ｓｅｐａｒａｔｉｏｎ＿ｉｄ（ｘ，ｍ（ｎ））というように複数手に入る場合があり、そのとき、ｒａｔｅ（ｘ，ｍ（ｋ））はｇｒｏｕｐ＿ｉｄ（ｘ）を獲得したときにｓｅｐａｒａｔｉｏｎ＿ｉｄ（ｘ，ｍ（ｋ））が手に入る確率と定義する。

このとき、各ｋ：１≦ｋ≦ｎ、W（ｓｅｐａｒａｔｉｏｎ＿ｉｄ（ｘ，ｍ（ｋ）））をｓｅｐａｒａｔｉｏｎ＿ｉｄ（ｘ，ｍ（ｋ））の重み（ｗｅｉｇｈｔ）とする。

このとき、式１は、

となる。

次に、以下のように仮定する。
Ａ：アクション
Ｉ：アイテム
Ｄｅｐｔｈ（Ａ，Ｉ）：アクションＡをしたときに式１でｓｅｐａｒａｔｉｏｎ＿ｉｄ（ｘ，ｍ（ｋ））＝アイテムＩとなるような変数ｘ（下図ではｘ＝３とする）
Ｅ（Ａ，Ｉ）：アクションＡをしたときに、アイテムＩが手に入る個数の期待値
ｓ（ｉ，ｋ）：アクションAをしたときにアイテムIが手に入る個数の期待値を計算する際にｇｒｏｕｐ＿ｔｒａｎｓ＿ｉにおいて計算に使用するｓｅｐａｒａｔｉｏｎ＿ｉｄ

となる。

以下で、図１１を参照して、いくつかの具体例について説明する。

＜クエスト報酬の場合＞
クエスト１０００１を１回プレイすると、アイテムグループ１００１及びアイテムグループ２０１が手に入るとする。それぞれグループの内訳は、
一回目に取れるアイテム（ｓｅｌｅｃｔ＿ｔｙｐｅがｆｉｒｓｔ）として、
アイテムグループ１００１＝アイテム１１×１０個（ｇｒｏｕｐ＿ｔｒａｎｓ＿２の行１参照）
毎回取れるアイテム（ｓｅｌｅｃｔ＿ｔｙｐｅがｌｏｏｐ）として、
アイテムグループ２０１＝アイテム２１×５個＋アイテム２２×５個（ｇｒｏｕｐ＿ｔｒａｎｓ＿２の行３及び行４並びにｇｒｏｕｐ＿ｔｒａｎｓ＿３の行１及び行２参照）
なので、両方を合計すると、
クエスト１０００１＝アイテム１１×１０個＋アイテム２１×５個＋アイテム２２×５個
となる。

＜ガチャの場合＞
クエスト１０００１で、ガチャ５０１を１回引いた場合のＵＲ＿Ａの期待値計算は、ｇｒｏｕｐ＿ｔｒａｎｓ＿１の行７を参照して、以下のようになる。
ガチャ５０１でＵＲは５％であり（ｇｒｏｕｐ＿ｔｒａｎｓ＿２の行１１参照）、ＵＲの中にはＵＲ＿Ａ、ＵＲ＿Ｂがあるので（ｇｒｏｕｐ＿ｔｒａｎｓ＿３の行１１及び１２参照）、
期待値＝１×０．０５×０．５＝０．０２５
となる。従って、ガチャ５０１を１回引いた場合のＵＲ＿Ａの期待値は０．０２５となる。

図１２は、本開示を適用したアウトプットを示す図１１から計算した各アイテムの期待値を示す図である。図１２で一番右の列「初回」にあるフラグは、そのアクションが初回である場合は「ＴＲＵＥ（真）」であり、２回目以降は「ＦＡＬＳＥ（偽）」になる。すなわち、「初回」の列がＴＲＵＥ（真）である行は、そのアクションが初回のみ与えられるアイテムを示し、「初回」の列がＦＡＬＳＥ（偽）である行は、そのアクションが２回目以降に対して与えられるアイテムを示している。

また、図１２の行１～行９は、クエストでもらえるアイテムを示し、行１０～行１７と行１９～行２６は、ガチャでもらえるアイテムを示している。すなわち、行１～行９では、アクション名の列にクエスト番号が入っており、行１０～行１７と行１９～行２６では、アクション名の列にガチャ番号が入っている。

例えば、図１２の行１を見ると、アクション１０００１を実行した場合に、アイテム１１が初回（すなわち、初回の列がＴＲＵＥ）のみ数量１０．０もらえる。そして、行２を見ると、行１と同じアクション１０００１を実行した場合でもそのアクションの実行が２回目以降（すなわち、初回の列がＦＡＬＳＥ）の場合は、アイテム２１が数量５．０もらえることが分かる。

一方、図１２の行１０を見ると、ガチャであるアクション５０００１を実行した場合に、アイテムＳＲ＿Ａが、２回目以降は、０．２６６の確率でもらえることが分かる。この例では、行１０から行２７に記載されたガチャの初回の列はすべて「ＦＡＬＳＥ（２回目以降）」になっている。

図８～図１２は、大本の図８及び図９のマスタが入れ子構造になっている例を説明したが、図１３～図１６は、大本の図１３のマスタが入れ子構造になっていない例を示す。

図１３は、標準ではないマスタを示した図である。図１３に記載のマスタは、標準ではないマスタであり、バトルに関連するマスタであるｂａｔｔｌｅ＿ｍａｓｔｅｒ（１３１０）とガチャに関連するマスタであるｅｖｅｎｔ＿ｇａｃｈａ＿ｍａｓｔｅｒ（１３２０）が記載されており、いずれのマスタも１つのマスタのみで、参照する子マスタなどがなく、入れ子構造（すなわち、階層構造）になっていない。

図１３のｂａｔｔｌｅ＿ｍａｓｔｅｒ（１３１０）のｉｄ（すなわち、３００１、３００２、３００３、３００４及び３００５）に紐付く形で、初回にもらえる最終的なアイテムのｉｄ及び数量及び２回目以降のもらえる最終的なアイテムのｉｄ及び数量が１つのマスタに記載されている。

例えば、バトル用のｂａｔｔｌｅ＿ｍａｓｔｅｒ（１３１０）を参照すると、初回にもらえるアイテムのｉｄは、ｆｉｒｓｔ＿ｔｒｅｓｕｒｅ＿ｉｄの列に上から順番に、１１１、１１１、１１１、１１１、１１１と記載されており、各ｉｄのもらえる数量は、ｆｉｒｓｔ＿ｔｒｅｓｕｒｅ＿ａｍｏｕｎｔの例に、上から順番に、５、１０、１５、２０、２５と記載されている。一方、毎回もらえるアイテムのｉｄが、ｒａｎｄｏｍ＿ｔｒｅｓｕｒｅ＿ｉｄの列に、上から順番に、２２２、２２２、２２２、２２２、２２２と記載されており、各ｉｄのもらえる数量がｒａｎｄｏｍ＿ｔｒｅｓｕｒｅ＿ａｍｏｕｎｔの例に、上から順番に５０、１００、１５０、２００、２５０と記載されている。

例えば、アイテムｉｄが３００１のバトルの場合は、初回にもらえるのはアイテムｉｄが１１１で、個数は５個であり、毎回もらえるアイテムｉｄは２２２で、個数は５０個である。

また、図１３のもう１つのマスタであるガチャ用のｅｖｅｎｔ＿ｇａｃｈａ＿ｍａｓｔｅｒ（１３２０）には、ｉｄである１００００１に紐付ける形で、各カード（ｃａｒｄ）の重み（ｗｅｉｇｈｔ）が記載されている。例えば、ガチャｉｄが１００００１で、カードがＵＲ＿ＡＡの場合は、重みは１となり、ガチャｉｄが１００００１で、カードがＳＳＲ＿ＡＡの場合は、重みは４となる。重みと確率の関係は、前述の通りである。

図１４は、図１３の非標準のマスタを、本開示を適用した標準のマスタに変換した図である。図１３のマスタであるｂａｔｔｌｅ＿ｍａｓｔｅｒ（１３１０）及びｅｖｅｎｔ＿ｇａｃｈａ＿ｍａｓｔｅｒ（１３２０）には、それぞれのアイテムが、どのくらいの数量又は重みづけでもらえるかについて、そのマスタ自体に最終的な情報が入っていて、階層化されていないシンプルな構造である。そのため、図１３のマスタのｂａｔｔｌｅ＿ｍａｓｔｅｒ（１３１０）及びｅｖｅｎｔ＿ｇａｃｈａ＿ｍａｓｔｅｒ（１３２０）を標準のマスタに変換してもマッピングに必要な表はｇｒｏｕｐ＿ｔｒａｎｓ＿１＿ｃｏｎｆが１つしかない。

図１４の基本な構造は、図１０の１０１０と同様であるので省略する。

図１３のマスタを本開示を適用した標準のマスタに変換すると、図８で示したマスタと同様に、図１５に示すようなアウトプットに整理できて、図１６に示すような期待値一覧を計算できる。

図１５は、図１４に示した本開示を適用した標準のマスタのアウトプットを示す図である。この図では、行１～行１０は、クエストを表し、行１１～行２６は、ガチャを表している。例えば、クエストの場合は、ｇｒｏｕｐ＿ｔｒａｎｓ１の行１を参照すると、ｇｒｏｕｐ＿ｉｄが３００１であり、ｓｅｐａｒａｔｉｏｎ＿ｉｄが１１１である場合、ｓｅｌｅｃｔ＿ｔｙｐｅは、ｆｉｒｓｔ（初回）であり、ａｍｏｕｎｔ（数量）は、５になっている。同様に、ガチャの場合は、行１１を参照すると、ｇｒｏｕｐ＿ｉｄが１００００１であり、ｓｅｐａｒａｔｉｏｎ＿ｉｄがＵＲ＿ＡＡである場合、ｓｅｌｅｃｔ＿ｔｙｐｅは、ランダムであり、ａｍｏｕｎｔ（数量）は１で、ｗｅｉｇｈｔ（重み）は１になっている。

行１で、ｓｅｌｅｃｔ＿ｔｙｐｅがｆｉｒｓｔ（初回）なのは、ｓｅｐａｒａｔｉｏｎ＿ｉｄが１１１だからではなく、単に設定として、ｇｒｏｕｐ＿ｉｄが３００１のクエストをやったときには、もらえるアイテムが設定されていて、ｓｅｐａｒａｔｉｏｎ＿ｉｄが１１１のものが、５個もらえるという設定値については、初回のみもらえる初回報酬であるというふうに元のマスタに設定している。ここでは、ｓｅｌｅｃｔ＿ｔｙｐｅをｆｉｒｓｔとして、初回報酬であることがわかるように書いてある。例えば、ｇｒｏｕｐ＿ｉｄが３００１のクエストをやったときには、ｓｅｐａｒａｔｉｏｎ＿ｉｄが１１１のアイテムが、初回（ｆｉｒｓｔ）は５個もらえて、それとは別に、周回報酬として、初回以外でも毎回（ｌｏｏｐ）１個もらえるという設定値になっている場合もあり得る。

図１６は、図１４に示した本開示を適用した標準のマスタの期待値一覧を示す図である。この図では、行１～行１０は、クエストを表し、行１１～行２６は、ガチャを表している。例えば、図１６の行１を参照すると、アクション名が３００１のとき、アイテム名１１１のものが、初回のみ（ＴＲＵＥ）、数量５．０でもらえるということが分かる。また、行１１を参照すると、アクション名が１００００１のとき、アイテム名がＵＲ＿ＡＡのものが、０．０１の期待値でもらえることが分かる。

図１７は、プレイ想定を示す図である。この表では、アクション毎に、日毎のアクション想定回数（すなわち、プレイ想定）を作成する。具体的には、クエストに関するｓｔｏｒｙ＿ｑｕｅｓｔ＿ｍａｓｔｅｒ（１７１０）の表と、ガチャに関するｇａｃｈａ＿ｍａｓｔｅｒ（１７２０）の表の２つのプレイ想定の表が記載されている。図１７の上側にあるｓｔｏｒｙ＿ｑｕｅｓｔ＿ｍａｓｔｅｒ（１７１０）のｉｄの列には、クエストのｉｄが、上から１０００１、１０００２、１０００３と記載されている。ｉｄの列の右側の３つの列には各日（ｄａｙ１（１日目）、ｄａｙ２（２日目）、ｄａｙ３（３日目））にプレイヤーが行う各クエストの回数が記載されている。例えば、クエストｉｄが１０００１のクエストを、プレイヤーは、ｄａｙ１で５回、ｄａｙ２で３回、ｄａｙ３では０回行うと仮定する。この場合、ａｃｔｉｏｎ＿ｎｕｍ（アクションの回数）の空欄は、０回を表す。

また、図１７の下側にあるｇａｃｈａ＿ｍａｓｔｅｒ（１７２０）のｉｄの列には、ガチャのｉｄが、上から５０００１、５０００２と記載されている。ガチャｉｄの右側の３つの列には各日（ｄａｙ１（１日目）、ｄａｙ２（２日目）、ｄａｙ３（３日目））にプレイヤーが行う各ガチャの回数が記載されている。例えば、ガチャｉｄが５０００１のガチャを、プレイヤーは、ｄａｙ１で２回、ｄａｙ２で３回、ｄａｙ３では０回行うと仮定する。この場合、ａｃｔｉｏｎ＿ｎｕｍ（アクションの個数）の空欄は、０回を表す。

図１８は、各アクションにおける各アイテムの日毎の獲得個数を示す図である。前述の図１２に記載の期待値に、図１７に記載のプレイ想定の日毎のアクション回数をかけ合わせて、それぞれのアクションとアイテムの組み合わせに対して、各日にどれくらいの量のアイテムが取れるのかを計算する。

図１８では、行１～行９は、クエストのアクションを表し、行１０～行２７は、ガチャのアクションを表している。

例えば、行１を見ると、このときのアクション名は「１０００１」であり、アイテム名は「１１」である。アクション回数は、上述の図１７を参照して、ｄａｙ１（１日目）は５回、ｄａｙ２（２日目）は３回、ｄａｙ３（３日目）は０回であるので、図１２の対応する行の量に各日のアクション回数を掛け合わせると、各日の獲得個数になる。例えば、行１の場合、ｄａｙ１の獲得個数は、１０×５＝５０、ｄａｙ２の獲得個数は、１０×３＝３０、ｄａｙ３の獲得個数は、１０×０＝０となる。

次に、例えば、行１０を見ると、このときのアクション名は「５０００１」であり、アイテム名は「ＳＲ＿Ａ」である。アクション回数は、ｄａｙ１（１日目）は２回、ｄａｙ２（２日目）は３回、ｄａｙ３（３日目）は０回であるので、図１２の対応する行の量に各日の回数を掛け合わせると、各日の獲得量になる。例えば、行１０の場合、ｄａｙ１の獲得量は、０．２６６×２＝０．５３２、ｄａｙ２の獲得個数は、０．２６６×３＝０．７９８、ｄａｙ３の獲得個数は、０．２６６×０＝０となる。

図１８では、同じアイテムが複数のアクションとの組み合わせで記載されている。例えば、アイテム名が「１１」については、行１、行４、行７、行１８にそれぞれ異なるアクション１０００１、１０００２、１０００３、５０００１と共に記載されている。

図１９は、プレイ想定に従った各アイテムの日毎の獲得個数を集計した図である。各アクションによって取れる同じアイテムを合計することで、複数日プレイした際の各アイテム獲得個数の予測をすることができる。図１９のｄａｙ１（１日目）、ｄａｙ２（２日目）、ｄａｙ３（３日目）の各例が、前述のプレイ想定回数×期待値の各日の計算結果をアイテム毎に整理して、合計を算出した数となる。一番右の例ｔｏｔａｌ（合計）は、各アイテムのｄａｙ１からｄａｙ３の３日間の合計を表す。

例えば、アイテム名が１１のアイテムは、ｄａｙ１（１日目）に計１０個取得でき、ｄａｙ２（２日目）に計２０個取得でき、ｄａｙ３（３日目）に計１３０個取得できるので、この３日間、このゲームをすると合計でアイテム１１が１６０個取得できることになる。

また、例えば、アイテム名がＳＲ＿Ａのアイテムは、ｄａｙ１（１日目）に計０．５３２の量を取得でき、ｄａｙ２（２日目）に計０．７９８の量を取得でき、ｄａｙ３（３日目）に計０．５３２の量を取得できるので、この３日間、このゲームをすると合計でアイテムＳＲ＿Ａが１．８６２の量を取得できることになる。

図１９では、アイテム名１１、２１、２２は、クエストで取れるアイテムであり、ＳＲ＿ＡからＵＲ＿Ｅは、ガチャで取れるアイテムを表している。

図２０は、アイテムの消費量を説明する表である。図１９では、各アイテムの獲得量を説明したが、図２０では、各アイテムの消費量を説明する。アイテムの消費についてもアイテムの獲得と同様で、図１２の期待値一覧で量の列がマイナスのものが消費個数を表すので、アイテム消費個数にプレイ回数を掛けることで、消費したアイテムの種類と量が分かる。期待値を表す図１２において、量がマイナスになっているのは、行１８のアイテム１１と、行２７のアイテム２１の２つのアイテムである。逆に言えば、アイテム１１とアイテム２１以外は、図１２の例では消費されていない。

図２０のアイテム１１の行を見ると、ｄａｙ１での消費は４０個で、ｄａｙ２での消費は６０個で、ｄａｙ３での消費は０個であるので、この３日間のアイテム１１の消費の合計は、１００である。

例えば、図２０に記載した例では、アイテム１１とアイテム２１は、３日間のトータルとしてそれぞれ１００個、４０個が消費されるが、その他のアイテムは消費されない（すなわち、トータルの消費個数がゼロ）であることが分かる。

図２１は、各アイテムの収支を示す表である。プレイ想定に従って図１９で計算された各アイテムの獲得量と、プレイ想定に従って図２０で計算された各アイテムの消費量から、アイテム別の収支（＝獲得量－消費量）が計算できる。このように、各アイテムの獲得個数と消費個数の差を求めることで、ゲームをプレイする上でのアイテムの収支が分かるようになる。

例えば、アイテム１１は、ｄａｙ１の収支が－３０で、ｄａｙ２の収支が－４０で、ｄａｙ３の収支が１３０なので、この３日間の収支は、６０となる。

例えば、アイテムＳＲ＿Ａは、ｄａｙ１の収支が０．５３２で、ｄａｙ２の収支が０．７９８で、ｄａｙ３の収支が０．５３２なので、この３日間の収支は、１．８６２となる。

図１２に記載された期待値を使って、図１４～図２０に関して説明した方法によって、図２１の各アイテムに対する収支が計算できる。このような方法で、クエスト及びガチャにおける、各アイテムの獲得量と消費量を計算し、その結果、獲得量から消費量を引いた収支を計算することによって、上述の図６で説明したような魔法石の収支などを計算することができる。

このように各アイテムの収支をパラメータ調整前後で比較し、パラメータ調整後の各アイテム又は全てのアイテムなどの収支のバランスを調整することによって、より良いパラメータ、すなわち、より稼げるゲームのパラメータを発見することが可能となる。

図２２は、本開示に従った動作を行うプログラムを実行するコンピュータのブロック図である。例えば、本開示によるプログラムを実行するコンピュータ２２００は、プロセッサ２２１０、グラフィックス２２２０、チップセット２２３０、メモリ２２４０、ネットワーク制御２２５０、キーボード／マウス２２６０、及びストレージ２２７０を備えてもよく、これらの構成要素は、通常互いに双方向のバスで接続されている。

プロセッサ２２１０は、メモリに記憶されたプログラムをチップセット２２３０と連携して実行する。チップセット２２３０は、プロセッサ２２１０から制御され、グラフィックス２２２０、メモリ２２４０、ネットワーク制御２２５０、キーボード／マウス２２６０、ストレージ２２７０の機能を制御する。

グラフィックスは、コンピュータ２２００の内部又は外部の表示装置を制御する。ネットワーク制御２２５０は、外部のネットワークに接続され、有線又は無線のＬＡＮなどを制御する。キーボード／マウス２２６０は、コンピュータ２２００を制御する入力手段であって、コンピュータ２２００と一体型でもよく、外部にあってもよい。ストレージ２２７０は、ハードディスクや光ディスクを含み、チップセット２２３０を経由して、プロセッサ２２１０によって制御され、データ及び／又は命令を保存する。

例えば、図７を参照して説明したステップＳ７０１、Ｓ７０２、Ｓ７０３、及びＳ７０４を実行する命令を含むプログラムを、図２２で説明したコンピュータ２２００を用いて実行してもよい。

本開示による方法は、機械学習又はディープラーニングを含むＡＩを利用して実行してもよい。

本開示は、説明の便宜のためゲームを前提として説明したが、本開示は、ゲームに限らず、例えば、Ｗｅｂサービスなどのシミュレーション全般にも適用可能である。例えば、ユーザーが記事を書くことができるサービスでは、ユーザーが記事を書くことにより、ログインボーナス的なゲームで使われる要素が入っている。また、ポイントなどを使ってマンガを読むことができるマンガ系のアプリでも、同じように、ログイン日数やアクションに応じてアイテムが貰えたり、使えたりする。このようなＷｅｂサービス又はアプリのようにゲームの仕組みを取り入れている分野にも、本開示は適用できる概念である。このようなサービス又はアプリ並びにゲームの分野であっても、プレイヤーはユーザーとも呼ばれる。

＜本開示のまとめ＞
本開示の実施例１に係るゲームの評価方法は、コンピュータが、（Ａ）マスタのパラメータに基づいて、プレイヤーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記プレイヤーが行う想定回数との乗算を計算するステップと、（Ｂ）前記乗算の結果に基づいて、各アイテムの収支を視覚化するステップと、を実行する。

本開示の実施例２に係るゲームの評価方法は、コンピュータが、（Ｃ）前記パラメータの変更指示に従って、前記パラメータを変更するステップと、（Ｄ）前記変更したパラメータに基づいて、前記期待値と前記想定回数との乗算を再計算し、前記乗算の再計算結果に基づいて、各アイテムの収支を視覚化するステップと、をさらに実行する実施例１に記載のゲームの評価方法。

本開示の実施例３に係るゲームの評価方法は、コンピュータが、前記（Ｃ）のステップから前記（Ｄ）のステップを、前記収支が所定の値以下になるまで繰り返す、実施例２に記載のゲームの評価方法。

本開示の実施例４に係るゲームの評価方法は、前記マスタは、複数のゲームで形式が統一されていない非標準のマスタから変換された前記複数のゲーム間で形式が統一されたマスタである実施例１に記載のゲームの評価方法。

本開示の実施例５に係るゲームの評価方法は、前記（Ｂ）のステップでは、前記各アイテムの収支の時間変化を視覚化する実施例１に記載のゲームの評価方法。

本開示の実施例６に係るゲームの評価方法は、前記（Ｂ）のステップでは、さらに前記各アイテムの獲得量及び消費量の時間変化を視覚化する実施例５に記載のゲームの評価方法。

本開示の実施例７に係るゲームの評価装置は、プロセッサ及び命令を記憶するメモリを備えるゲームの評価装置であって、（Ａ）マスタのパラメータに基づいて、プレイヤーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記プレイヤーが行う想定回数との乗算を計算し、（Ｂ）前記乗算の結果に基づいて、各アイテムの収支を視覚化する、ゲームの評価装置。

本開示の実施例８に係るゲームの評価プログラムは、（Ａ）マスタのパラメータに基づいて、プレイヤーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記プレイヤーが行う想定回数との乗算を計算するステップと、（Ｂ）前記乗算の結果に基づいて、各アイテムの収支を視覚化するステップと、を実行する命令をプロセッサによって実行させる、ゲームの評価プログラム。

本開示の実施例９に係るアプリの評価方法は、（Ａ）マスタのパラメータに基づいて、ユーザーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記ユーザーが行う想定回数との乗算を計算するステップと、（Ｂ）前記乗算の結果に基づいて、各アイテムの収支を視覚化するステップと、を実行する、アプリの評価方法。

本開示は、例えば、ゲームの評価を行う方法、装置又はプログラムに適用可能である。

１０１ ＵＸポリシー決定
１０２ ゲームロジック設計
１０３ パラメータ設定
１０４ ＵＸ可視化
１０５ ＫＰＩ設計
１０６ ＵＸの確認
２０１ 拡大期
２０２ 急減期
２０３ 漸減期
２０４ コアの楽しみ
２０５ 成長実感
２０６ 英雄感
２１０ レベデザによる売上最大化
２１１ レベデザによる売上維持
２２００ コンピュータ
２２１０ プロセッサ
２２２０ グラフィックス
２２３０ チップセット
２２４０ メモリ
２２５０ ネットワーク制御
２２６０ キーボード／マウス
２２７０ ストレージ

Claims (8)

1. コンピュータが、
   （Ａ）マスタのパラメータに基づいて、プレイヤーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記プレイヤーが行う想定回数との乗算を計算するステップと、
   （Ｂ）前記乗算の結果に基づいて、各アイテムの収支を視覚化するステップと、
   を実行し、
   前記マスタは、複数のゲームで形式が統一されていない非標準のマスタから変換された前記複数のゲーム間で形式が統一されたマスタである、ゲームの評価方法。
2. コンピュータが、
   （Ｃ）前記パラメータの変更指示に従って、前記パラメータを変更するステップと、
   （Ｄ）前記変更したパラメータに基づいて、前記期待値と前記想定回数との乗算を再計算し、前記乗算の再計算結果に基づいて、各アイテムの収支を視覚化するステップと、
   をさらに実行する、請求項１に記載のゲームの評価方法。
3. コンピュータが、
   前記（Ｃ）のステップから前記（Ｄ）のステップを、前記収支が所定の値以下になるまで繰り返す、請求項２に記載のゲームの評価方法。
4. 前記（Ｂ）のステップでは、前記各アイテムの収支の時間変化を視覚化する請求項１に記載のゲームの評価方法。
5. 前記（Ｂ）のステップでは、さらに前記各アイテムの獲得量及び消費量の時間変化を視覚化する請求項４に記載のゲームの評価方法。
6. プロセッサ及び命令を記憶するメモリを備えるゲームの評価装置であって、
   （Ａ）マスタのパラメータに基づいて、プレイヤーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記プレイヤーが行う想定回数との乗算を計算し、
   （Ｂ）前記乗算の結果に基づいて、各アイテムの収支を視覚化し、
   前記マスタは、複数のゲームで形式が統一されていない非標準のマスタから変換された前記複数のゲーム間で形式が統一されたマスタである、ゲームの評価装置。
7. （Ａ）マスタのパラメータに基づいて、プレイヤーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記プレイヤーが行う想定回数との乗算を計算するステップと、
   （Ｂ）前記乗算の結果に基づいて、各アイテムの収支を視覚化するステップと、
   を実行する命令をプロセッサによって実行させる、ゲームの評価プログラムであって、
   前記マスタは、複数のゲームで形式が統一されていない非標準のマスタから変換された前記複数のゲーム間で形式が統一されたマスタである、ゲームの評価プログラム。
8. コンピュータが、
   （Ａ）マスタのパラメータに基づいて、ユーザーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記ユーザーが行う想定回数との乗算を計算するステップと、
   （Ｂ）前記乗算の結果に基づいて、各アイテムの収支を視覚化するステップと、
   を実行し、
   前記マスタは、複数のゲームで形式が統一されていない非標準のマスタから変換された前記複数のゲーム間で形式が統一されたマスタである、アプリの評価方法。

Images