JP2023123018A - ゲームの評価方法、装置及びプログラム - Google Patents

Abstract

【解決手段】本開示による方法は、プレイ想定を含むマスタを入力するステップと、プレイ想定に基づいて、効率が最大になるように、さらに細かいプレイ想定を強化学習で算出するステップと、さらに細かいプレイ想定に基づいて、所定の期間内のステータスの平均又は獲得リソース総量の価値の平均が最大になるような最適プレイを計算するステップと、をコンピュータで実行する。【効果】ゲームのリリース前にゲームのバランスをシミュレーションすることによりそのゲームの収支バランスを容易に評価し、各パラメータに対する必要な調整をすることができる。【選択図】図２３

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

従来の方法では、構造化したマスタを使ってプレイの想定を使ってシミュレーションを行う方法が行われていた。そこでは、どういう風にユーザーがプレイしていく予想自体は開発者が考えて細かく設定しなくてはいけなかった。例えば、クエストが１－１から１－１０まであって、それが５章あった時の５０個のクエストについて何日目にどこのクエストを何回プレイするかの粒度で設定しなくてはいけなかった。しかしながら、現実的にはそこまで細かく設定するのは厳しいので、本発明では、その設定値（プレイ想定）を自動的に作れるようにした。

さらに、プレイ想定を作った上で、実際にそのプレイ想定を作ったら、そのときにこっちの意図したパラメータのバランスになっているように自動的にチューニングする方法を発明した。つまり、設計者が希望するゲームの難易度になるようなパラメータの設定値を本発明の方法によって自動的に作れるようになる。

本発明の別の態様によれば、大まかなプレイ想定に基づいて最適プレイを計算することが可能となる。

本発明の別の態様になれば、最適プレイに基づいてパラメータ値を調整することが可能となる。

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

本開示による別の方法は、プレイ想定を含むマスタを入力するステップと、前記プレイ想定に基づいて、効率が最大になるように、さらに細かいプレイ想定を強化学習で算出するステップと、前記さらに細かいプレイ想定に基づいて、所定の期間内のステータスの平均又は獲得リソース総量の価値の平均が最大になるような最適プレイを計算するステップと、をコンピュータで実行する。

本開示によるまた別の方法は、所定のパラメータ設定値に基づいて最適プレイを計算するステップと、前記最適プレイの計算の結果得られた獲得リソース量、伸長ステータス量、又は各コンテンツの獲得量を、それぞれの所定の値と比較し、その結果に基づいて、前記所定のパラメータ設定値を変更して、前記獲得リソース量、前記伸長ステータス量、又は前記各コンテンツの獲得量と前記所定の値との差が小さくなるように学習するステップと、前記差が、所定の値以下になった場合、そのときのパラメータ設定値を出力するステップと、をコンピュータによって行う。

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

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

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

本明細書において、「ゲーム」とは、何らかのコンピュータを使ったあらゆるタイプのコンピュータゲームを含み、制限なく、アーケードゲーム、コンシューマーゲーム、テレビゲーム、携帯型ゲーム、パソコンゲーム、携帯電話ゲーム、スマホゲーム、ソーシャルゲーム、ブラウザゲーム、ＮＦＴゲーム、ブロックチェーンゲーム、クリプトゲームを含む。また、ＮＦＴやブロックチェーン技術を用いたＤｅＦｉ（分散型金融：Decentralized Finance）などにおいては、中央集権型の仕組みと異なり仲介者が存在しない、ユーザー間での取引が行われるが、中央集権型の仕組みのように、特定の誰かが取引仲介の各種コストを負担する代わりに報酬を受け取るという仕組みがないので、そのままだと取引が成立しにくい。そのため、こういったＤｅＦｉの分野においては、不特定多数間でも取引をスムーズに行えるように、不特定多数のユーザーが取引のコストを支払う代わりに、何かしら報酬を獲得できるような設計が必要であり、スマートコントラクト上で定義する報酬バランスを最適化する必要があるが、本願の技術はそういった分野にも適応可能である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このとき、式１は、

となる。

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

となる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここから、実施例２について説明する。実施例２は、例えば、本発明に従ったオートパラメータ（Ａｕｔｏ Ｐａｒａｍｓ）と呼ばれるプログラムによって実装されてもよい。

＜実施例２の全体の概要＞
上述の通り、一般にゲームの最適解の探索や、最適なマスタ設定を行うことは容易ではない。そこで、本発明によるオートパラメータ（Ａｕｔｏ Ｐａｒａｍｓ）は、一般のゲームに対する最適なプレイを探索し、その結果を元にして、さらにマスタを自動調整することにより、プレイヤーの成長度合いの調整を行う方法である。特に、最適なプレイの探索には、（１）ユーザーの行動が同じでもランダム性によって結果が変わる場合を考慮して行う場合と、（２）実用上の観点から計算量の負荷軽減のため、ユーザーの行動を期待値で代表して算出する場合の２パターンがあり、それぞれの最適プレイの探索において、ＡＩの強化学習などを用いてもよい。

図２３は、最適プレイを計算する方法の概要を示すフローチャートである。図２３の場合、先ず、従来のような詳細なプレイ想定ではなく、大まかなプレイ想定を作成する（ステップ２３０１）。

次に、ゲームプレイは、ステータスの伸びとリソース集めの効率が重要なので、プレイ想定の条件でその効率が最大になるような、細かなプレイ想定を、強化学習εグリーディ法などで算出する（ステップ２３０２）。ここで効率とは、例えば、ある一定のプレイ時間、課金額において、ゲームの有利不利を表す各種カードやキャラクターなどのステータスのパラメータの上昇量及び、獲得するアイテムなどのリソースの価値の合計値が、最も高いことを示す。なお、基本的にはステータスのパラメータの上昇量の方を重視するが、重視する度合いについては、ゲームごとに変えてもよい。

図２３の最後で、各コンテンツで、どのようなプレイをすると、平均的にステータスや獲得リソース量が同じ期間で最大になるか、という最適プレイを細かなプレイ想定に基づいて計算する（ステップ２３０３）。以下で、各ステップについて詳細に説明する。なお、ユーザーの行動は同じでも、ガチャやクエストの確率ドロップ報酬などのように、確率によって結果が左右されるのが通常なので、その結果の分布の影響を考慮したケースと、考慮せず期待値ベースで計算する２つの方法があるが、大半の部分で共通しているので、差異がある部分については必要に応じてその差異などについて記述する。

すなわち、最適プレイ想定作成は２パターンある。（１）計算量負荷高いけれど正確な方法と、（２）精度やや落ちるけれど計算量負荷少なめな方法である。（１）の詳細に算出する場合は、各コンテンツでの不確定要素、例えば、ガチャの当たり外れや、敵を倒したときに時々もらえる報酬などのように、当たりもあるし、外れもあるという条件で、モンテカルロ法で複数回プレイを行った場合のプレイの効率を、ばらつきも含めて分析を行い、効率が最大となるものや平均の効率、中央値の効率あるいはこれらと分布の標準偏差を組み合わせるなどをした指標を、プレイを行った際の効率と定義して、その結果を元に強化学習εグリーディ法などを組み合わせて最適プレイを見つけるような手法が望ましい。この（１）計算量負荷高いけれど正確な方法は、上記のようなやり方では計算負荷もかかり、実用上はここまで精度がなくても十分に通用するケースも多いので、各コンテンツをプレイしたときに消費及び獲得できるリソースの期待値を定義し、その期待値ベースでのプレイの効率を算出したときに、最大となるようなプレイ想定を、強化学習εグリーディ法などを用いて見つける手法が（２）の精度やや落ちるけれど計算量負荷少なめの手法となる。

＜プログラムの構成＞
本Ａｕｔｏ Ｐｒａｍａｓプログラムは、構成として以下の要素の１つ以上を含んでもよい。
・一般ゲームモデル
・最適ゲームプレイ探索（欲張り（グリーディ）法、強化学習など）
・ガチャのランダム性を考慮したモンテカルロ・シミュレーション
・マスタ自動調整

＜実行するための準備＞
ＰＹＴＨＯＮプログラミング言語を使った実装方法の一例を示す。この実装方法では、以下のようにｌｏｃａｌディレクトリまで移動し、ＰＹＴＨＯＮＰＡＴＨを実行する。
ｃｄ ＄ａｕｔｏ＿ｐａｒａｍｓ／ｌｏｃａｌ
ＰＹＴＨＯＮＰＡＴＨ＝＄ＰＷＤ／
これにより以下のように各種ｔｅｓｔ関数の実行ができるようになる。
ｐｙｔｈｏｎ ｔｅｓｔｓ／ｔｅｓｔ＿＊ｐｙ

＜インプットファイル＞
本プログラムの実行のためには共通して例えば以下のインプット（入力）ファイルが必要である。
・ａｃｔｉｏｎ．ｃｓｖ
・ｍａｓｔｅｒ＿ｕｓｅｒ＿ｌｅｖｅｌ＿ｅｘｐ．ｃｓｖ
・ｒｅｓｏｕｒｃｅ．ｃｓｖ
・ｐｏｗｅｒ．ｃｓｖ
・ｌｅｖｅｌ＿ｕｐ．ｃｓｖ
・ｓｅｔｔｉｎｇ＿ｖａｌｕｅ．ｐｉｃｋｌｅ
・ｓｅｔｔｉｎｇ＿ｔｉｍｅ．ｐｉｃｋｌｅ

＜一般ゲームモデル＞
本方法では、ｎ枚のカードデッキを用いてクエストをクリアしていく汎用的なゲームを想定して実装を検討する。カードには、上述のようにレアリティ（Ｒａｒｉｔｙ）、レベル（Ｌｅｖｅｌ）などがあり、それらの値により戦力値が決まってもよい。ゲームモデル（以下ゲーム関数ともいう）の中で、プレイヤーオブジェクト（以下単にプレイヤーともいう）が、その選択に従いゲームをプレイする。ゲーム関数によって、主として、例えば以下の行為が可能である。
・クエストをプレイする
・ガチャを引く

各種設定値は、例えば、出願人である株式会社Ｐｒｅｃｉｏｕｓ Ａｎａｌｙｔｉｃｓ（以下、プレアナともいう）の標準マスタから読み込んでもよい。また、ゲーム中で消費又は獲得する全てのアイテムやデッキを構成するキャラクターには価値があらかじめ定められており、プレイヤーは獲得したアイテムとキャラクターの総合的価値を定められた期間プレイし、最大化することを目的としてもよい（以下、総価値を最大化するためにプレイすると仮定する）。

＜クエスト＞
図２４は、クエストの区分とプレイ順番の関係を示す図である。クエストは、任意の種類が存在する区分（例えば、「ストーリーＡ」、「イベントＡ」、「イベントＢ」など）によって区別されている。それぞれの区分内でプレイ順番が設定されており、プレイ順番より前の順番が振られているクエストがクリアされて初めて、その次のプレイ順番のクエストは解放される（すなわち、プレイヤーがプレイできる状態になる）。また、それぞれのクエストには初回用、２回目以降用の異なるスタミナ消費値、プレイ報酬値が設定されており、プレイヤーは必要なスタミナ値を消費することによってクエストをプレイし、その結果プレイ報酬を受け取ることができるようにしてもよい。

例えば、図２４の上半分を見るとクエストの区分としてストーリーＡの第ｎ章２４０１が記載されており、この段階では、ストーリーＡの第ｎ章２４０１は、未だプレイされていない（すなわち、未クリア状態）。次に、プレイヤーがこのストーリーＡの第ｎ章２４０１をプレイする（Ａｃｔｉｏｎ！）。そうするとプレイの結果ストーリーＡの第ｎ章２４０２は、クリアされ（クリア済みの状態）、プレイヤーは次のストーリーＡの第ｎ＋１章２４０３をプレイできるようになる。また、プレイヤーが初めてストーリーＡの第ｎ章をクリアした場合は、初回報酬２４０４を得るようにしてもよい。実際には、そのストーリーＡの第ｎ章２４０１の１回目のプレイでそのストーリーをクリアできるとは限らないが、単純化のため１回目のプレイでその章をクリアできると仮定した。

一方、図２４の下半分を見るとクエストの区分としてストーリーＡの第ｎ章２４１１が記載されており、この段階では、既にクリア済みであり、このプレイヤーは、このストーリーＡの第ｎ章を既にクリアしていることが分かる。次に、プレイヤーがこのストーリーＡの第ｎ章２４１１を再びプレイする（Ａｃｔｉｏｎ！）。そうするとプレイの結果ストーリーＡの第ｎ章２４１２は、再びクリアされ（クリア済みの状態）、今度は初回報酬ではなく２回目以降のクリアに対して与えられる周回報酬２４１３を得るようにしてもよい。この場合は、ストーリーＡの第ｎ章を２回以上クリアしているので、ストーリーＡの第ｎ＋１章は、新規クエスト開放とはならないようにしてもよい。

＜クエストプレイ制限＞
クエストをプレイする上で、本開示によるプログラムでは必要に応じて、以下の制限をマスタ設定により設けてもよい。
・最低総戦力値：この最低総戦力値を設定することによって、あるクエストに到達したプレイヤーのその時点のデッキの総戦力値が予め設定された設定値未満の場合は、そのプレイヤーはその時点でそのクエストをプレイできない（例えば、クリアできないことを想定している）。
・プレイ回数上限：プレイヤーがそのクエストに対する設定されたプレイ回数上限を超えている場合は、そのクエストはプレイできない。（例えば、基本的に１回しか実行できないシナリオストーリーや、回数制限があるイベントクエストなどを想定している）

＜ガチャやドロップ報酬など確率によって結果が左右される機能について＞
本開示によるプログラムでは、例えばガチャについては、期待値ベースのガチャ（以下、期待値ガチャともいう）、ランダムガチャの２種類が実装されてもよい。また、クエストなどの報酬で確率によって獲得できるかどうかが変わるいわゆるドロップ報酬と呼ばれるようなものについても、期待値ベースドロップ報酬とランダムドロップ報酬の２種類が実装されても良い。
・期待値ガチャ：期待値ガチャの場合、カードは期待値として手に入る（例：レアリティ５が出る確率５％の１０連ガチャを一回引いた場合、レアリティ５のカードは統計的には０．５枚手に入る）。プレイヤーは各レアリティのカード枚数累積値を保持しており、各レアリティのカード枚数累積値が１を超えた時に、レベル１のカード１枚が手に入り、そのレアリティのカード枚数累積値から１を引くものとする。
－－ｇａｃｈａ＿ｔｙｐｅ “ｅｘｐｅｃｔ”
により、期待値ガチャが指定可能である。
・ランダムガチャ：ランダムガチャでは、設定された排出確率により各レアリティのカードが排出される。
－－ｇａｃｈａ＿ｔｙｐｅ “ｒａｎｄｏｍ”
より、ランダムガチャが指定可能である。

＜プレイヤー＞
ゲームプレイヤーの一日の行動は、例えば、以下の通りである。
１．１０日に一回１０連ガチャを引く。
２．以下をスタミナがなくなるまで繰り返す。
・可能なクエストの中からプレイヤーの選択によって最適なクエストを選びプレイする
・マスタに従った成長判定、キャラクター強化

＜キャラクター強化方法＞
本開示による方法では、例えば、プレイヤーが所持するキャラクターのうち、そのキャラクターを１レベル上げるために消費する総価値と上昇する戦力値の比から最も効率良いレベルを上げる対象を決定し、そのキャラクターのレベルを上げる欲張り法を採用している。

＜実行方法＞
例えば、以下のｔｅｓｔ関数によりｇａｍｅ ｐｌａｙのテスト計算が可能である。
ｐｙｔｈｏｎ ｔｅｓｔｓ／ｔｅｓｔ＿ｇａｍｅ＿ｐｌａｙ．ｐｙ ＼
－－ｍａｘ＿ｌｅｖｅｌ ７０ ＼
－－ｄｅｃｋ＿ｎｕｍ ６ ＼
－－ａｃｔｉｏｎ＿ｔｙｐｅ “ｇｒｅｅｄｙ” ＼
－－ｅｌａｐｓｅｄ＿ｄａｙｓ ６０ ＼
－－ｉｎｐｕｔ＿ｐａｔｈ “．／ｉｎｐｕｔ＿ｃｓｖ” ＼
－－ｏｕｔｐｕｔ＿ｐａｔｈ “．／ｏｕｔｐｕｔ＿ｃｓｖ” ＼
－－ｇａｃｈａ＿ｔｙｐｅ “ｅｘｐｅｃｔ” ＼
－－ｄｅｂｕｇ＿ｍｏｄｅ ｆａｌｓｅ
２行目以降の引数は省略可能であり、一例として今回の設定値は全てデフォルト（ｄｅｆａｕｌｔ）値である。ｍａｘ＿ｌｅｖｅｌは、デッキのキャラクターの最大レベルで例えば７０以下の自然数が指定可能ある。ｄｅｃｋ＿ｎｕｍは、所持するデッキの枚数である。ａｃｔｉｏｎ＿ｔｙｐｅは、プレイヤーの行動指針で、ランダムに行動する「ｒａｎｄｏｍ（ランダム）」、欲張り法を用いる「ｇｒｅｅｄｙ（グリーディ）」、及び強化学習を用いる「ｑｌｅａｒｎｉｎｇ（キューラーニング）」が指定可能である。欲張り法、強化学習については後述する。ｉｎｐｕｔ＿ｐａｔｈ、ｏｕｔｐｕｔ＿ｐａｔｈは、それぞれ、入力のためのｃｓｖファイルが存在するパスと、出力する場所のパスである。ｇａｃｈａ＿ｔｙｐｅは、キャラクターのガチャのタイプで、期待値ベースの「ｅｘｐｅｃｔ」確率でランダムに１枚ずつ排出される「ｒａｎｄｏｍ」が指定可能である。ｄｅｂｕｇ＿ｍｏｄｅは、デバッグ用に用意された引数で、Ｔｒｕｅにした場合、主な処理の処理時間などがログとして出力されるようにしてもよい。

＜最適ゲームプレイ探索＞
本方法では、例えば、ランダムにクエストをプレイ（ｒａｎｄｏｍ）、各クエストをプレイする効率が既知とした欲張り法によるゲームプレイ（ｇｒｅｅｄｙ）、強化学習を用いた最適ゲームプレイ（ｑｌｅａｒｎｉｎｇ）の３通りの方策の実装を行う。
・ｇｒｅｅｄｙ：ｇｒｅｅｄｙでは、各クエストをプレイすることによって得られる総価値と消費するスタミナの比により最も効率的なクエストを選び行動する。各関数で、
－－ａｃｔｉｏｎ＿ｔｙｐｅ “ｇｒｅｅｄｙ”
とすることで指定できる。
・ｑｌｅａｒｎｉｎｇ：最適プレイを探索するため、強化学習ε－ｇｒｅｅｄｙ法を用いて、Ｑ値の学習にはモンテカルロ法を用いてもよい。強化学習を適用する重要な利点として、あらかじめクエストから得られるアイテム量が分かっていなくても最適解の産出が可能な点がある。強化学習では一般に、その時点の環境や状況を示す状態ｓ、そのとき、エージェント（本プログラムの場合、プレイヤー）がとった行動ａ、行動ａによって得られる報酬が重要となる。状態ｓとしては、日付とスタミナをとり、行動ａとしては、クエストのプレイをとってもよい。行動ａにより、スタミナを消費し、報酬を得て、デッキが強化されてもよい。報酬は、獲得したアイテムとデッキ強化によって得られた総価値の増分としてもよい。

図２５は、強化学習を示す図である。先ず、使用されるマスタが入力される（ステップ２５０１）。次に、最適プレイ又はランダム選択が選択され、ε－ｇｒｅｅｄｙ法で強化学習が行われ、報酬が計算される（ステップ２５１１）。次に、計算された報酬を使用して、モンテカルロ法でＱ値が更新される（ステップ２５１２）。強化学習でこのステップ２５１０の訓練がくり替えされる。そして、最終的にプレイ最適解が出力される（ステップ２５０２）。以下で図２５の各ステップの詳細について説明する。

＜ε－ｇｒｅｅｄｙ法＞
ε－ｇｒｅｅｄｙ（イプシロンーグリーディ）法は、強化学習の一種で、初期値の偏りなどによって局所解に陥ることを避けるために、ある適当な起きにくい確率εでランダムな行動をとるようにするものである。学習するにつれてεは０に収束するように更新する。学習終了の判定は、例えば、εがある値以下となるときである。

＜モンテカルロ法によるＱ値の更新＞
日付ｄ、スタミナ値ｓの状態ｓ＝（ｄ，ｓ）の学習回数ｔ回目の行動ａにより、報酬ｒ^ｔが得られたとすると、次回学習時のＱ値、Ｑ_ｓ，ａ ^{（ｔ＋１）}は以下のように計算される。

ただし、

は学習回数ｔ回目に行動ａが選択された回数である。本開示による方法では、例えば、強化学習の関数が用意されており、以下により実行できる。
ｐｙｔｈｏｎ ｔｅｓｔｓ／ｔｅｓｔ＿ｑｌｅａｒｎｉｎｇ．ｐｙ ＼
－－ｍａｘ＿ｌｅｖｅｌ ７０ ＼
－－ｄｅｃｋ＿ｎｕｍ ６ ＼
－－ｅｌａｐｓｅｄ＿ｄａｙｓ １０ ＼
－－ｉｎｐｕｔ＿ｐａｔｈ “．／ｉｎｐｕｔ＿ｃｓｖ”
－－ｏｕｔｐｕｔ＿ｐａｔｈ “．／ｏｕｔｐｕｔ＿ｃｓｖ” ＼
－－ｇａｃｈａ＿ｔｙｐｅ “ｅｘｐｅｃｔ” ＼
－－ｄｅｂｕｇ＿ｍｏｄｅ Ｔｒｕｅ
なお、本開示の方法では、ｇｒｅｅｄｙ法におけるクエストの効率、ｑｌｅａｒｎｉｎｇにおけるＱ値をプレイヤーがｐｒｉｏｒｉｔｙ ｑｕｅｕｅ形式の行動方針として持つことにより、行動方針の追加、プレイヤーが取ることの出来る各選択肢などの行動施策同士の比較が行えるような汎用的な構造になっていてもよい。

＜モンテカルロ・シミュレーション＞
モンテカルロシミュレーションモジュールでは、ガチャが完全ランダムであるときの最高レアリティのカードを初めて入手する日付（以下ｄａｙ５（５日目））と総価値、デッキの総戦力値の関係をシミュレーションすることができる。本来であれば、シミュレーションをたくさん行なった場合、ｄａｙ５を日付ごとにカウントした分布は山形になり偏るが、データを均一に集めるために、あるゲームプレイについて、ｄａｙ５が指定できるように実装されている。

図２６は、モンテカルロ法を用いた場合の手順を示すフローチャートである。先ず、マスタ及びシミュレーション回数が入力される（２６０１）。次に、最適プレイ又は総戦力値計算が選ばれる（２６０２）。最後に、最適プレイ結果の統計分布が出力される（２６０３）。

モンテカルロ法の実行方法は、例えば以下の通りである。
ｐｙｔｈｏｎ ｔｅｓｔｓ／ｔｅｓｔ＿ＭｏｎｔｅＣａｒｌｏ．ｐｙ １０００＼
－－ｍａｘ＿ｌｅｖｅｌ ７０＼
－－ｄｅｃｋ＿ｎｕｍ ６＼
－－ａｃｔｉｏｎ＿ｔｙｐｅ “ｇｒｅｅｄｙ”
－－ｅｌａｐｓｅｄ＿ｄａｙｓ ６０＼
－－ｉｎｐｕｔ＿ｐａｔｈ “．／ｉｎｐｕｔ＿ｃｓｖ”＼
－－ｏｕｔｐｕｔ＿ｐａｔｈ “．／ｏｕｔｐｕｔ＿ｃｓｖ”＼
－－ｄｅｂｕｇ＿ｍｏｄｅ Ｔｒｕｅ
第一引数として、何サイクルモンテカルロシミュレーションを行うのかを指定する必要がある。それ以外はｇａｍｅ関数の引数と同じであるが、ガチャタイプは”ｒａｎｄｏｍ”で固定としてもよい。ただし、上書きを防止するため、ｏｕｔｐｕｔ＿ｐａｔｈによって指定されたアウトプットファイルのパスにインプットとして必要であったファイルが存在した場合、アウトプットファイルのパス上にあるファイルが読み込まれる。

＜アウトプットファイル＞
－ｏｕｔｐｕｔ＿ｐａｔｈによって指定されたパスにｉｎｐｕｔ＿ｐａｔｈにあるインプットファイルがコピーされ、さらに、ｍｏｎｔｅｃａｌｏ．ｌｏｇが生成される。生成例を以下に示す。

上記生成例において、ｃｙｃｌｅ，ｐｏｗｅｒ，ｒａｒｅ５＿ｆｉｒｓｔ，ｖａｌｕｅｓはそれぞれ、シミュレーション回数、総戦力値、ｄａｙ５（レアリティ５を最初に取った日）、総価値を表す。例として、サンプルデータ、シミュレーション回数１０，０００回行なった場合、ｍｐと総価値の散布図は図２７の通りである。各ｄａｙ５に対する総価値の平均をとると図２８のように分布していることがわかる。

図２７は、総価値とレアリティ５のカードを始めて獲得した日の関係を表すグラフである。図２７の縦軸は、総価値（総戦力値）を表し、横軸は、レアリティ５のカードを初めて獲得した日を表す。横軸の日数が０から６０へと左から右に変化してくのに伴い、総戦略値も変化している。例えば、横軸の日数が０のときは、総戦力値が１３６０００やその下の６つの値もあり得るが、横軸の日数が１０を超えてくると、すなわち、１０日目以降にレアリティ５のカードを始めて取得しても、総戦力値として１３６，０００を超える確率が少なくなることが分かる。

図２８は、図２７の各日付の平均値を表すグラフである。図２８の縦軸は、総価値（総戦力値）の各日の平均値を表し、横軸は、レアリティ５のカードを始めて獲得した日を表す。図２８から分かるように、横軸の日が０から５日ぐらいまで総価値の平均値は上昇し、その後、日数が増えるにつれて、総価値の平均値は下がっていき、日数が４０日を超えた辺りからまた波打ちながら平均値が上昇し、最後に５５日を超えた当たりから平均値は急下降する。

図２９は、実施例３の概略を示すフローチャートである。一度最適プレイの詳細を出して、そのときの獲得リソース量と伸長ステータス量、そして、それらの各コンテンツ（定常クエスト、イベントクエスト、ＰｖＰ、ガチャなど）毎の獲得量（計算結果）とを、開発側が意図した値とを比較し、その結果、パラメータ設定値を変更して、差が小さくなるように学習させる（ステップ２９０１）。次に、その差が、ある一定値以下になったら、収束したとみなし、ユーザーが最適効率でプレイすると、アイテム獲得量とステータスの伸び、及び、コンテンツ毎の配布比率が、開発が意図したものに近づくようなパラメータ設定値が求まる（ステップ２９０２）。

＜マスタ自動調整（ａｕｔｏ ｐａｒａｍｓ）＞
本発明に従った「ａｕｔｏ ｐａｒａｍｓ（オートプログラム）」モジュールでは、最適なプレイをした場合に期待される総戦力値となるようにマスタ設定値を自動調整してもよい。その概略図を図３０に示す。

図３０は、本発明によるマスタの自動調整方法を示したフローチャートである。図３０を参照して、先ず、マスタ及び想定戦力値が入力される（ステップ３００１）。次に、最適プレイ及び総戦力値が計算される（ステップ３０１１）。そして、計算された最適プレイ及び総戦力値に基づいてマスタが調整される（ステップ３０１２）。このステップ３０１１及びステップ３０１２を含む自動調整を、差が所定の値に収束するまで繰り返す（ステップ３０１０）。その結果、調整されたマスタが出力される（ステップ３００２）。

期待された戦力値Ｐ_ｅ、現在のマスタ値の時の最適プレイにおける戦力値Ｐ^（ｔ）とすると、調整する前のマスタ値のベクトルｍ^（ｔ）の調整式は以下の通りでもよい。例えば、ａが０．８とか１．２のように特定の値を決めて計算する。

ここで、Γ_ｊ（ｘ）は小数点ｊ以上切り捨てし、さらに、それで値が０になった場合には小数点第ｊ以上での最小単位とする関数である。これによりマスタ値で０になるような部分や小数点以下多く続くような値になるのを防ぐ。期待される総戦力値に対して実際に最適プレイをした時の戦力値との誤差が、今回の例では５％以下となった場合に繰り返し調整を終了する。なお、この誤差５％については、ケースによって他の値になるものであり、固定値ではない。
ｐｙｔｈｏｎ ｔｅｓｔｓ／ｔｅｓｔ＿ａｕｔｏ＿ｐａｒａｎｓ．ｐｙ １０００＼
－－ｃｒｉｔｅｒｉｏｎ ３ ＼
－－ｎｃｙｃ １５ ＼
－－ｍａｘ＿ｌｅｖｅｌ ７０ ＼
－－ｄｅｃｋ＿ｎｕｍ ６ ＼
－－ａｃｔｉｏｎ＿ｔｙｐｅ ”ｇｒｅｅｄｙ”
－－ｅｌａｐｓｅｄ＿ｄａｙｓ ６０ ＼
－－ｉｎｐｕｔ＿ｐａｔｈ ”．／ｉｎｐｕｔ＿ｃｓｖ” ＼
－－ｏｕｔｐｕｔ＿ｐａｔｈ ”．／ｏｕｔｐｕｔ＿ｃｓｖ” ＼

第一引数として想定される最適プレイでの最高戦力値を指定してもよい。また、本方法では、ストーリーの種類、アイテムの種類を指定して調整することが可能となっており、これ以外で必要だったインプットファイルの他に、以下のような「ａｕｔｏ＿ｐａｒａｍｓ．ｃｓｖ」ファイルを作成し指定してもよい。ｉｄ、大区分名、Ｉｔｅｍ、調整倍率はそれぞれ、インデックス、ストーリーの種類、調整したいアイテム、始めにあらかじめ調整する倍率である。調整倍率を０以上に指定することにより、はじめにあらかじめ指定されたアイテムの取得量を調整倍率倍する。０の場合には調整しない。モンテカルロ・シミュレーションと同様、上書きを防止するため、ｏｕｔｐｕｔ＿ｐａｔｈによって指定されたアウトプットファイルのパスにインプットとして必要であったファイルが存在した場合、アウトプットファイルのパス上にあるファイルが読み込まれる。

＜アウトプットファイル＞
戦力調整されたマスタファイルとともに、戦力値が調整されていく過程のログファイルであるｐａｒａｍｓ．ｌｏｇが以下のような内容で生成されてもよい。以下の例は、調整前の最適プレイによる総戦力値が９９０であり、総戦力値が９００になるように調整していく様子である。

調整される過程は図３１及び図３２に示されるようになる。図３１は、回数の変化による戦力値の変化を表すグラフである。図３１は、回数（Ｃｙｃｌｅ）を繰り返すことによって、戦力値（Ｐｏｗｅｒ）が段々４００から３００付近に収束していることがわかる。

図３２は、本発明の自動調整方法での調整の前後のマスタを表す図である。図３２を参照すると、左側の表（３２１０）は、調整前の各クエストのキャラクター強化素材の値を示し、右側の表（３２２０）は、調整後の各クエストのキャラクター強化素材の値を示す。常にこのような傾向があるとは限らないが、図３２の場合は、各クエスト及びイベントのキャラクター強化素材の値が、調整前（３２１０）から調整後（３２２０）で、小さくなっていることが分かる。

図３１及び図３２の例は、調整前（すなわち回数０）の最適プレイによる総戦力値が３９９であり、最終的に（すなわち回数５）総戦力値が３０１（すなわち３００±１）になるように調整していく様子（図３１）と実際に変化したマスタ値の様子（図３２）である。このように最適プレイでの総戦力値を調整することによって、所望の総戦略値に近づけることができることが分かる。

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

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

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

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

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

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

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

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

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

本開示の実施例２－１に係る方法は、プレイ想定を含むマスタを入力するステップと、
前記プレイ想定に基づいて、効率が最大になるように、さらに細かいプレイ想定を強化学習で算出するステップと、
前記さらに細かいプレイ想定に基づいて、所定の期間内のステータスの平均又は獲得リソース総量の価値の平均が最大になるような最適プレイを計算するステップと、
をコンピュータで実行する方法。

本開示の実施例２－２に係る方法は、εグリーディ法を使用する、実施例２－１に記載の方法。

本開示の実施例２－３に係る方法は、前記εグリーディ法は、プレイ想定又はランダム選択に基づいて報酬を計算する、実施例２－２に記載の方法。

本開示の実施例２－４に係る方法は、前記強化学習において、Ｑ値の更新はモンテカルロ法によって計算される、本開示の実施例２－１～２－３の１項に記載の方法。

本開示の実施例２－５に係る方法は、プレイ想定を含むマスタを入力するステップと、前記プレイ想定に基づいて、効率が最大になるように、さらに細かいプレイ想定を強化学習で算出するステップと、をコンピュータで実行する方法。

本開示の実施例２－６に係る方法は、プレイ想定を含むマスタ、及びシミュレーション回数を入力するステップと、前記マスタ及びシミュレーション回数に基づいて、最適プレイ又は総戦力値を計算するステップと、最適プレイの計算結果の統計分布を出力するステップと、をコンピュータで実行する方法。

本開示の実施例２－７に記載のプログラムは、実施例２－１～２－６に記載の方法をプロセッサで実行するための命令を含むプログラム。

本開示の実施例２－８に記載の装置は、プロセッサ、及びメモリを備え、実施例２－１～２－６の方法を実行するための装置。

本開示の実施例３－１に係る方法は、所定のパラメータ設定値に基づいて最適プレイを計算するステップと、前記最適プレイの計算の結果得られた獲得リソース量、伸長ステータス量、又は各コンテンツの獲得量を、それぞれの所定の値と比較し、その結果に基づいて、前記所定のパラメータ設定値を変更して、前記獲得リソース量、前記伸長ステータス量、又は前記各コンテンツの獲得量と前記所定の値との差が小さくなるように学習するステップと、前記差が、所定の値以下になった場合、そのときのパラメータ設定値を出力するステップと、をコンピュータによって行う方法。

本開示の実施例３－２に係る方法は、（Ａ）最適プレイを含むマスタ、及び想定戦力値を入力するステップと、（Ｂ）前記最適プレイに基づいて、総戦力値を計算するステップと、（Ｃ）前記総戦力値に基づいて、前記マスタの値を調整するステップと、をコンピュータによって実行する方法。

本開示の実施例３－３に係る方法は、前記総戦力値が所定の値以下になるまで前記（Ｂ）ステップと前記（Ｃ）ステップを繰り返す、実施例３－２に記載の方法。

本開示の実施例３－４に係るプログラムは、実施例３－１～３－３に記載の方法をプロセッサで実行するための命令を含むプログラム。

本開示の実施例３－５に係る装置は、１つ以上のプロセッサ、及びメモリを備え、実施例３－１～３－３の方法を実行するための装置。

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

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

Claims (8)

1. プレイ想定を含むマスタを入力するステップと、
   前記プレイ想定に基づいて、効率が最大になるように、さらに細かいプレイ想定を強化学習で算出するステップと、
   前記さらに細かいプレイ想定に基づいて、所定の期間内のステータスの平均又は獲得リソース総量の価値の平均が最大になるような最適プレイを計算するステップと、
   をコンピュータで実行する方法。
2. 前記強化学習は、εグリーディ法を使用する、請求項１に記載の方法。
3. 前記εグリーディ法は、プレイ想定又はランダム選択に基づいて報酬を計算する、請求項２に記載の方法。
4. 前記強化学習において、Ｑ値の更新はモンテカルロ法によって計算される、請求項１～３のいずれか１項に記載の方法。
5. プレイ想定を含むマスタを入力するステップと、
   前記プレイ想定に基づいて、効率が最大になるように、さらに細かいプレイ想定を強化学習で算出するステップと、
   をコンピュータで実行する方法。
6. プレイ想定を含むマスタ、及びシミュレーション回数を入力するステップと、
   前記マスタ及びシミュレーション回数に基づいて、最適プレイ又は総戦力値を計算するステップと、
   最適プレイの計算結果の統計分布を出力するステップと、
   をコンピュータで実行する方法。
7. 請求項１～６のいずれか１項に記載の方法をプロセッサで実行するための命令を含むプログラム。
8. プロセッサ、及びメモリを備え、請求項１～６のいずれか１項に記載の方法を実行するための装置。

Images