本明細書において、「ゲーム」とは、何らかのコンピュータを使ったあらゆるタイプのコンピュータゲームを含み、制限なく、アーケードゲーム、コンシューマーゲーム、テレビゲーム、携帯型ゲーム、パソコンゲーム、携帯電話ゲーム、スマホゲーム、ソーシャルゲーム、ブラウザゲーム、NFTゲーム、ブロックチェーンゲーム、クリプトゲームを含む。また、NFTやブロックチェーン技術を用いたDeFi(分散型金融:Decentralized Finance)などにおいては、中央集権型の仕組みと異なり仲介者が存在しない、ユーザー間での取引が行われるが、中央集権型の仕組みのように、特定の誰かが取引仲介の各種コストを負担する代わりに報酬を受け取るという仕組みがないので、そのままだと取引が成立しにくい。そのため、こういったDeFiの分野においては、不特定多数間でも取引をスムーズに行えるように、不特定多数のユーザーが取引のコストを支払う代わりに、何かしら報酬を獲得できるような設計が必要であり、スマートコントラクト上で定義する報酬バランスを最適化する必要があるが、本願の技術はそういった分野にも適応可能である。
本明細書において、説明の便宜上、ゲームの例として主にソーシャルゲームを用いて説明するが、本開示の適用はソーシャルゲームに限定されず、あらゆるタイプのゲームに適用可能である。
本明細書において、「ソーシャルゲーム」とは、一人又は複数人のグループのユーザーで楽しむオンラインのゲームことであり、コミュニティ及びユーザー同士の協力又は対戦などの要素を含む。例えば、ソーシャルゲームは、ゲームの中で農園や街を造ったり、カードを集めてデッキで戦ったり、特定のパズルを解きながらステージを進んだりというアクションが行われる。ソーシャルゲームをプレイするための基本料金は通常は無料で、アイテムを購入する際の課金という形でゲームの提供者は利益を得ている。ソーシャルゲームは、「ソシャゲ」とも呼ばれる。
「キャラクター」とは、ゲームに登場する人物、動物、ロボット、機械又は架空の動物などのことであり、プレイヤーが操るなどしてゲームを成立させる、ゲームの物語に関わるキャラクターのことである。「キャラクター」は、「キャラ」又は「ゲームキャラ」とも呼ばれる。
「ガチャ」とは、元々「ガチャガチャ」又は「ガチャポン」という呼ばれる機械が名称の元になっており、ゲームにおいてはランダムに引いてアイテムなどを入手するための仕組みのことである。「ガチャ」は、通常、一部は無償で一部は有償である。
「カード」とは、ゲーム内で使用するプレイヤーの分身のようなものである。カードを複数枚集めてデッキ(又はチーム)を作成し、そのデッキを使用してゲーム内の敵又は他のプレイヤーと対戦するために使用する。カードは、ゲームによってはモンスターとも呼ばれる。
「カード」には一般に4つの要素があり、それらは、「レアリティ」、「コスト」、「パラメータ」及び「スキル」である。「レアリティ」は、カードの希少価値を表す。一般に、カードの希少価値が高いものほど、入手するのが困難である、すなわち、それを引く確率が低く、高価である。「コスト」は、複数のカードをデッキに並べる場合のカード全体のコストの上限である「コスト上限」として使用される。「パラメータ」は、カードに紐付けられた強さを表す値である。一般には、その他に「攻撃力」又は「防御力」などが設定されている。「攻撃力」が高いほど、攻撃によって相手に与えるダメージが強く、「防御力」が高いほど同じ攻撃力の相手から受けるダメージが小さい。「スキル」は、そのカードが使用できる固有の能力である。例えば、自分たちの攻撃力を上げたり、最初に攻撃できたりといった能力がある。
図1は、ゲームのレベルデザインの手順を示す図である。一般に、ゲーム開発において、「レベルデザイン」とは、ゲームで使用される種々のパラメータの難易度(すなわち、数値)の調整を行う作業をいう。ソーシャルゲームなどのアプリでは、レベルデザイン=パラメータ設定というイメージが強い。しかし、本明細書では、上流のUX(User eXperience:ユーザー体験)ポリシー、つまりユーザーへどのような体験を届けるかの定義から、その先のデータ分析を含めて一連の流れをレベルデザインとして定義する。
上流のUX(ユーザー体験)ポリシー決定101やゲームロジック設計102に問題があると、パラメータ設定103をいくら調整しても、売上が上がりにくい場合もあり得る。また、パラメータ設定103がUX(ユーザー体験)を満たしているのかを分析して確認しないと、適切なパラメータ調整ができない場合もある。
本明細書において、レベルデザインは、図1に記載したように、UX(ユーザー体験)ポリシー決定101、ゲームロジック設計102、パラメータ設定103、UX(ユーザー体験)可視化104、KPI設計105、UX(ユーザー体験)の確認106などのステップを含む。図1では、説明の便宜上6つのステップで説明しているかこれらのステップはさらに細かく分けられてもよく、6つのステップのいくつかは統合されてもよい。
本明細書では、上流のUXポリシー決定101、つまりユーザーへどのような体験を届けるかという定義から、その先のデータ分析を含めた一連の流れをレベルデザインに含めている。
UXポリシー決定101は、ユーザー体験の方針、すなわちゲームの仕様を決定する段階である。
次のステップであるゲームロジック設計102では、ステップ101で決定したUXポリシーに基づいて、どういう仕組みでユーザーに楽しんでもらうかということを考える。すなわち、決定したUXポリシーをどんなロジックや式などで実現するかを検討する。例えば、グループでバトルを楽しんでもらう場面では、何人対何人で戦って、どれくらいの所要時間で、どういう攻撃方法があるか、などがゲームロジックに相当する部分である。一方、キャラクターの成長に関しては、どういう制約を入れて、どう試行錯誤してもらうか、というような事を決めることが、ゲームロジック設計102に含まれる。
ゲームロジック設計102において、難易度を表す式については、単調に時間と共に難易度を増加させていくのか、ゲームの後半から加速して難易度を上げるのか、又は難易度を最終的にある値に収束させるのか、というようなUX(ユーザー体験)を数式などをベースで考える。ゲームロジックが破綻している、又は難易度を表す式の設定が不適切な場合、レベルデザインの上流で決定したUXポリシーがいくら良くても、そのようなゲームロジックに基づいて売れるゲームを実装することが困難となる。
次のステップであるパラメータ設定103では、それまでに決定したUXポリシー及び設計したゲームロジックに沿って各パラメータに数値を当てはめていく作業を行う。このパラメータ設定103では、UXポリシーの大枠を、定量的にパラメータに変換していくことが必要となる。
例えば、街づくりゲームの場合、発生するあるアクシデントに関して、「そのアクシデントは、意外と頻発して起こる上に、ダメージも大きいのでスリリングな体験になる」というようなUXポリシーを仮定する。その場合は、「意外と頻発して起こる」という部分を、定量化して、例えば「60分に1回発生する」としたり、「ダメージも大きい」という部分を定量化して、例えば、「最大でプレイヤーの所持金の7割が無くなる」という風に設定することができる。また、「スリリング」という部分を、例えば「ダメージがプレイヤーの所持金の1割から7割の間で毎回ランダムに変動する」というようにある程度の幅を持たせて設定してもよい。
このようにUXポリシーを決定することにより、このゲームのプレイヤーは、決定されたUXポリシーである「スリリングな体験」を経験することができる。また、このようにUXポリシーのパラメータへの定量化の作業を繰り返すことにより、ミスが発生しにくいパラメータ設定103が可能となる。
次のステップでは、UX可視化104を行う。UX可視化104では、パラメータの設定値が、決定したUXポリシー通りになっているかを可視化して、確認する。この場合、プレイヤーによるそのゲームのテストプレイは必要になるが、その前段階として、数値レベルでUXを可視化してパラメータを確認できるようにすると、パラメータの設定ミスという事故を大幅に減らすことができる。例えば、「あるキャラを育てるには何日掛かるか」のように、UXを数値で大まかに表現する。これに対して、例えば、シミュレーションを行い、各パラメータを記述したマスタを整理することにより、UXを可視化することができる。
シミュレーターを用いてUXの可視化を行うことによって、運用時のパラメータ設定ミスによる売上低下を防ぐ仕組みを提供することが可能となる。
例えば、あるゲームのあるダンジョンに入ってアイテムを取得する場面で、どのぐらいの時間でそのダンジョンで、どれくらいのアイテムが取れるかも重要なUX(ユーザー体験)である。これはマスタを整理することにより可視化することができ、パラメータ設定ミスによる事故防止につながり得る。
次に、KPI設計105で、KPI(Key Performance Indicator:重要業績評価指標)を設計し、想定したUXとゲームをプレイした際の実際のUXの差分を確認するための準備を行う必要がある。例えば、「ヘビーユーザーは、一日に何回プレイして、何日間でここまでのクエストをクリアする」のようなイメージでゲームの想定が作られている場合、そのプレイヤー層のプレイ回数やクエストクリア状況が、そのUXを確認するためのKPIになる。
最後のステップであるUXの確認106において、ゲームのリリース前に、前述の設計したKPIを見ながら、想定したUXが提供できているかの確認を行う。その結果、UXの確認106において、UXポリシー決定101で決定したUXが提供できていない場合は、ゲームロジック設計102に戻ってゲームロジックを再設定し、又はパラメータ設定103に戻ってパラメータの再調整を行う。
図2は、ソーシャルゲームの売上推移の基本的なパターンを示す図である。図2において、横軸は時間を表し、縦軸はそのソーシャルゲームの売上を表す。
図2を参照すると、ゲームの売上に関して、ゲーム販売後から順番に「拡大期201」、「急減期202」及び「漸減期203」という3つのフェーズがあることが分かる。ゲームの発売後の最初の段階は、ユーザー数も客単価もどんどん上がり、その結果、ゲームからの売上がどんどん増えていく「拡大期201」である。その次は、ユーザーが急激に減って売上が急減する「急減期202」である。最後は、ある程度までユーザーが減ってさらに売上も減っていく「漸減期203」である。
良いゲーム、換言すれば売れるゲームは、リリース後にユーザー数及び売上が徐々に上がっていき、最大売上のピーク以降も売上低下が緩やかである(すなわち、急減期202が急に落ちない)。一方、売れないゲームは、リリース後にユーザー数及び売上が緩やかに立ち上がった後、ピークの最大売上も高くなく、その後、急速にユーザー数及び売上が減少することが多い。
売上の最大値(ピーク値)はゲーム自体のポテンシャル、すなわちゲーム自体の魅力に依存するところが大きいが、レベルデザイン(レベデザとも言う)をしっかり行うことで、拡大期201での売上の最大化の後押しや、売上がピークを迎えたあとの急減期202又は漸減期203でのユーザーの離脱や売上の低下をある程度防ぐことができ、その結果、長期的に見るとかなりの利益の向上が可能になる。
図2には、ゲームのレベルデザイン(レベデザ)が成功した例(実線)とレベルデザイン(レベデザ)が失敗した例(破線)が示されている。レベデザが成功した例(実線)では、拡大期201において、レベデザの成功により売上が最大化し(符号210)、急減期202及びその後の漸減期203においても売上が急激に落ち込むことはなく、ある程度維持することができる(符号211)。
前述のレベデザが成功した例(実線)に対して、レベデザが失敗した例(破線)では、拡大期201において、さほど売上の最大値は伸びず、売上のピーク値も低い(符号220)。そして、その後の急減期202及び漸減期203における売上の落ち込みが急である(符号221)。その結果、レベデザが失敗した例(破線)では、発売開始から最終的な発売終了までの売上総額も、レベデザが成功した例(実線)に対して小さいものになる。
ゲームのリリース前はそもそも売れるかどうか、すなわち、一定期間の最大売上額が重要と考えられがちであるが、昔と違って、現在は一度達成した売上を維持することがより重要になりつつあるので、適切なレベルデザインは従来以上に重要となっている。
図2に記載された拡大期201、急減期202及び漸減期203の3つのフェーズのそれぞれと関連する重要な要素がいくつかある。先ず、最初の拡大期201で大きく寄与するのが、「コアの楽しみ(204)」である。このコアの楽しみ(204)とは、アプリのインゲーム自体の面白さや、IPやキャラクター、世界観の魅力などのことである。インゲームにおいても、ゲームロジックやパラメータ設定などで面白さを増加することはできるが、どうしてもコアの楽しみ(204)はレベルデザインだけではどうにもならない部分もあり得る。
インゲーム及びIPなどによるゲームのコアな楽しみ(204)の重要度は、図2の下の表を参照して、拡大期201が大きく(◎)、急減期202及び漸減期203では、ゲームのコアな楽しみ(204)の重要度が小さくなる(△)。
ステータスのインフレなどによる「成長実感(205)」の重要度は、急減期202が大きく(◎)、拡大期201及び漸減期203は中程度(○)である。
承認欲求や自己顕示欲などによる「英雄感(206)」の重要度は、拡大期(△)、急減期(○)、漸減期(◎)と時間の経過と共に徐々に大きくなっていく傾向がある。
各ゲームの売上は、もちろんそのゲーム自体のポテンシャル、すなわちゲーム自体の魅力に依存するが、同じゲームであっても、レベルデザインを適切に行うことによって、拡大期201において売上を早期に最大化でき、その後の急減期202及び漸減期203における減衰を遅らせることによって、1つのゲームから得られる収入を最大化することができる。
急減期202で重要なのが、「成長実感(205)」の要素になる。要するに、ゲームをやればやるほど強くなっていくような感覚をプレイヤーに常に体験してもらうことが重要である。例えば、これは、カードゲームでは、カードのステータスのインフレ(換言すれば、時間の経過と共にステータスや火力等が上がり続ける現象)などが相当するが、単にインフレさせるだけではなく、しっかりとその強さの体感がプレイヤーにフィードバックされる仕組み作りも重要になる。
最後の漸減期203で重要なのが、「英雄感(206)」という要素になる。この英雄感(206)は、プレイヤーが自分は活躍している、という感覚を持てるかどうかということである。例えば、プレイヤーがそのゲームのランキング上位に入賞するとか、又は、そのプレイヤーは良いカードやキャラを持っていてすごいな、と他のプレイヤーに思われるようなことである。
特に高い売上が長く続くゲームでは、この英雄感(206)の設計は長期的には非常に重要である。プレイヤー自身が英雄感(206)を感じることによって、長くそのゲームをプレイし、課金してくれる可能性が増加し、その結果、売上の上昇及び売上低下の抑制に繋がり得る。
これら3つの重要な要素である、コアの楽しみ(204)、成長実感(205)及び英雄感(206)は、互いに完全に切り分けられるものではないが、概ね前述のようにそれぞれ3つのフェーズである、拡大期201、急減期202及び漸減期203と対応していると考えられる。
図3には、あるゲームのあるダンジョンの攻略時の各層のプレイヤーの被ダメージ量、すなわち、勝率を示した図である。表の横軸には、プレイヤーのレベルが初心者、初級者、中級者、上級者、ランカーと、そのゲームが下手な人から上手い人へと5段階で順に記載されている。表の縦軸には、上から、エリア1からエリア7までのそのゲームの7つのエリアが記載されている。図3には、各レベルのプレイヤーの各エリアでの勝ち負けが、勝率(%)で記載されている。また,図3の右側の凡例を参照して、その勝率は、UX(ユーザー体験)として、上から、勝率の低い方から高い方へ、惨敗、惜敗、辛勝、勝利、楽勝の5段階に分類されている。
例えば、複数のエリアを探索するRPG(ロールプレーイングゲーム)がある場合、各エリアをクリアするまでに各層のプレイヤー又はパーティが受けるダメージ量(すなわち被ダメージ量)をシミュレートする。図3では、勝ち負けの境界をダメージ量で100%とし、ダメージ量が100を超えると負けであり、100以下だと勝ちと仮定する。このシミュレーションにより、例えば、初級者は、エリア5はクリアできないが(被ダメージ量が110%、すなわち、惜敗する)、エリア5の一つ下のレベルのエリア4はギリギリクリアする(被ダメージ量が90%、すなわち、辛勝する)。
一方、上級者は、エリア3は、容易にクリアでき(被ダメージ量が40%、すなわち、楽勝する)、エリア6はぎりぎりクリアし、(被ダメージ量が75%、すなわち、辛勝する)、エリア7もギリギリクリアする(被ダメージ量が90%、すなわち、辛勝する)。
このようにプレイヤーのレベルと各エリアの難易度(すなわち、被ダメージ量)が表に記載され、UXが網羅的に可視化されるので、図3のようにパラメータを可視化すると、パラメータの設定ミスによるパラメータ事故を大幅に減らすことができる。
実際のゲーム運用時に売上が大きく減る原因は、このパラメータ設定が上手く行っていないケースが多い。例えば、重要アイテムを配布しすぎて成長実感のバランスが壊れたり、特定のキャラクターがバランスを崩して英雄感が損なわれたりするなどのパラメータ設定ミスが起こって、長期的に売上が思ったほど上がらないというようなことが実際に起こり得る。
これらの原因は、結果的にはパラメータ設定ミスに起因するが、直接的には、UX(ユーザー体験)の可視化がなされていないことがその原因となり得る。
図4は、パラメータを定義するマスタ(又はマスタファイル)を整理することによるパラメータの可視化の例を示す図である。図4の左側の表(410)には、左側の列から順に、ゲームのマスタに含まれるクエストID、アイテムID、数量が記載されている。この左側の表(410)に基づいて、アイテムをクエスト毎に整理したのが右側の表(420)である。右側の表(420)は、左側の列から順番にID、アイテム名、クエスト名と並んでおり、クエスト名の大きなグループの中にさらに詳細なクエストの具体名が、草原、洞窟、鉱山と記載されている。
例えば、図4の右の表(420)において、ID=1の行では、アイテム名は薬草であり、この薬草は、草原に1個、洞窟に2個、鉱山に3個あることが分かる。同様に、ID=2の行では、アイテム名は小回復薬で、この小回復薬は、洞窟に2個あるが、草原及び鉱山にはないことが分かる。ID=3の行では、アイテム名が欠片であり、この欠片は、草原に1個あるが、洞窟及び鉱山にはないことが分かる。IDが4~6に対して、鉄鉱石、宝石、カードがそれぞれ、各クエストに何個あるかが右の表(420)に記載されている。
このようにゲームのマスタ形式の左の表(410)をアイテム毎に整理することによって作成した右の表(420)は、各アイテムがどのクエストで何個取得できるか、左の表(410)より、容易に理解することができる。
図5は、本開示を適用してゲームの運用を改善した例を示す図である。ゲームを設計する場合には、ユーザーをいくつかのカテゴリに分けて、それぞれのカテゴリのプレイヤーが楽しめるようなコンテンツをそれぞれ用意する必要がある。図5の例では、簡単のため、ユーザーをゲームの習熟度に応じて3つのカテゴリ、すなわち、初心者、中間層、コア層(上級者)に分けている。
例えば、発売前のゲーム設計の初期の段階で、そのゲームの各ユーザー層に対する難易度を評価した場合に、図5の左図(510)のように、初心者向けコンテンツをクリアできるプレイヤーが多いのに対して、中間層向けコンテンツをクリアできるプレイヤーが少ないという状況に陥る場合がある。このような場合、プレイヤーがゲームの全行程の中で途中の中間層で詰まってしまう状況が起こり得る。このような状況に陥ると、特に中間層プレイヤーは、中々より上位のコア層に上がれないので、このゲームを連続してプレイする意欲が低下し、数の多い中間層プレイヤーからの売上が減ることになり、ゲーム全体としての売上も減少する。
図5の左図(510)のように各層のプレイヤーがクリアできるバランスが悪い場合は、本開示のパラメータの評価をゲーム発売前にこのゲームに適用することによって、中間層向けのコンテンツを左図(510)より容易にすることにより、初心者、中間層向け及びコア層向けの各レベル向けのコンテンツをクリアできる人数のバランスを取ることが可能となる。右図(520)では、左図(510)より中間層向けコンテンツを容易にした結果、中間層向けのコンテンツをクリアできるプレイヤーの人数が多くなり(すなわち、コア層向けコンテンツに挑戦できるプレイヤーの人数が増え)、中間層プレイヤーがより継続してプレイしてくれるので、全体としてそのゲームから得られる収入がさらに最大化することが可能となる。
図6は、本開示を適用する前後のゲームにおける魔法石の収支を表す図である。魔法石は、上述の通りアイテムの1種であり、そのゲーム内で通貨のような役割をはたす。本開示の適用前のパラメータ調整前の図(600)及び本開示の適用後のパラメータ調整後の図(650)の横軸は、いずれもプレイ日数を表しており、一番左側のプレイ日数1日目から一番右側のプレイ日数60日目までを表す。本開示の適用前の図(600)及び本開示の適用後の図(650)の縦軸は、いずれも魔法石の収支(個数)を表している。各図の各プレイ日数における3本の棒グラフの一番左の棒グラフは、魔法石の獲得量、真ん中の棒グラフは、魔法石の消費量、一番右の棒グラフは、魔法石の獲得量から消費量を引いた差(収支)を表す。図6の左図(600)及び右図(650)から、いずれの場合も、プレイヤーのそのゲームのプレイ日数に従って、魔法石の獲得量及び消費量が増えていることが分かる。
本開示を適用する前の図600を参照すると、プレイ日数1日、3日、5日、7日、14日、30日、60日と経過日数に伴って、収支(獲得-消費)が増えていることが分かる。また、プレイ日数60日の時点で、獲得量は、購入した有償石の4500と、イベントの5000と、通常クエストの3000と、ログインボーナスの600の合計である、13100となる。本開示を適用する前の図600を参照すると、プレイ日数60日の時点で、消費量は、イベントガチャ(イベガチャ)の6000と、通常ガチャの2400の合計である、8400となる(ここでは、無料のガチャは考えない)。従って、本開示を適用する前のプレイ日数60日時点での獲得量-消費量である収支は、4700である。
これに対して、本開示を適用した後の図650を参照すると、プレイ日数1日、3日、5日、7日、14日、30日、60日と経過日数に伴って、3日目で一旦増えた収支がその後、多少の増減はあるが、最終的には減っていることが分かる。また、プレイ日数60日の時点で、獲得量は、購入した有償石の4500と、イベントの2500と、通常クエストの1050と、ログインボーナスの300の合計である、8350となる。本開示を適用した後の図650を参照すると、プレイ日数60日の時点で、消費量は、イベントガチャ(イベガチャ)の6000と、通常ガチャの2400の合計である、8400となる。従って、本開示の適用した後の獲得量-消費量である収支は、-50である。
このように本開示を適用する前のプレイ日数60日目の収支は4700となり、魔法石の獲得量と消費量のバランスが悪い(すなわち、消費量が獲得量に対して少なすぎる)。これに対して、本開示を適用した後のプレイ日数60日目の収支は-50となり、魔法石の獲得量と消費量の差が小さく(すなわち、消費量と獲得量のバランスが良い)、且つ魔法石の消費量も多く、ガチャでの課金が促進されるので、本ゲームからの収入をより最大化することができる。
図7は、本開示の適用手順を示すフローチャートである。ここで「マスタ」とは、ゲームで使用するパラメータなどを記述する表形式などのデータのことであり、「マスタ形式」とは、このマスタで使用される形式(フォーマット)のことである。
1つのマスタのみで、そのゲームで使用されるすべての要素のパラメータが記述される場合もあるが、通常は、親マスタの内容がさらに子マスタ、孫マスタなどによって段階的に記述される場合もあり、そのような場合は、マスタが複数段の入れ子構造になっている。マスタが入れ子構造になっている場合は、例えば、親マスタのアイテムが、さらに子マスタの中でさらに詳細に規定されており、このような場合は、親マスタだけを見てもそのアイテムの詳細が分からない。
先ず、本開示の方法によるプログラムはコンピュータによって実行されると、標準ではないマスタ形式のマスタを本開示が適用された標準のマスタ形式に変換する(S701)。標準ではないマスタ形式の標準のマスタ形式への変換(S701)は、コンピュータを用いて実行してもよいが、手作業で行ってもよい。通常は、標準でないマスタ形式で、ゲーム開発会社からそのゲームで使用するすべてのマスタが提供される。同じゲーム開発会社が開発したゲームであっても、ゲームが異なれば又は同じゲームであってもバージョンが異なれば、マスタ形式が統一されておらず、マスタの形式が異なっていることも多い。標準のマスタ形式としては、ゲーム制作会社、ゲーム又はゲームのバージョンなどが異なっても統一された同じ形式のものが使用される。
標準のマスタ形式に変換されたマスタを使用して、各要素(例えば、アイテム)の期待値×想定を計算する(S702)。ここで、期待値とは、プレイヤーがあるアクションをしたときに各アイテムを取得及び消費する値であり、想定回数は、アクションをプレイヤーが行うと推定した回数である。この期待値×想定を計算することにより、例えば、あるコンテンツにおいて、あるアイテムを何個取得できるかを予測することが可能となる。
次に、アイテムの獲得量、消費量、及び獲得量と消費量の収支をシミュレーションして、その結果を視覚化することによって、対象となるパラメータを使った結果を視覚化することができる(S703)。このようなアイテムの獲得量、消費量及び収支をシミュレーションした結果を視覚化した図が、例えば、既に説明した、図6に記載した図(600)である。
最後に、シミュレーション結果によって視覚化されたアイテムの収支などに基づいて、パラメータを調整する(S704)。具体的には、図6に記載した図(600)のゲーム開始からの各経過日数における、アイテムの獲得・消費による収支のバランスが取れているか否かを見る。図6の図(600)を見ると、例えば、経過日数60日目の獲得量が消費量に対して大きく、収支が+4700とバランスが悪くなっていることが分かる。
本開示を適用することによりゲームの開発者は、図6の左上の図(600)のこの収支のアンバランスを見て、マスタ中の各パラメータを適切に調整することによって、アイテムの収支のバランスを改善することができる。このようにパラメータを調整して収支を改善した結果を示すのが図6の右下の図(650)である。図6の右下の図(650)を見ると、ゲーム開始からの各プレイ経過日数において、特に経過日数7日目以降の収支のバランスが取れており(すなわち、獲得量の棒グラフと消費量の棒グラフの高さに対して、収支の棒グラフの高さが相対的に低い)、売上の最大化に関して、調整後のパラメータがより適切であることが分かる。
S704でパラメータを調整した後、任意選択で、S702に戻って、再度、調整後のパラメータに基づいて、期待値×想定の値を計算し、S702で新たに計算された結果に基づいて、アイテムの収支を再度シュミレーションして、S703でパラメータを再度視覚化し、その結果、さらにパラメータの微調整が必要ならS704で、このシミュレーションの結果に基づいて、再度パラメータ調整の調整を行ってもよい。
再度のパラメータ調整の結果、必要ならもう一度S702からS704のステップを繰り返してもよい。
これから図8から図16を使って、図7のS701及びS702に関連する処理についてさらに詳細に説明する。図8及び図9は、ゲームを作成する際にゲーム制作会社などが作る標準ではないマスタであり、図10は、本開示を適用した標準のマスタである。
図8は、従来の標準ではない入れ子構造のマスタを示す図である。図8には、4つのマスタが記載されており、それぞれの関係についてこれから説明する。
図8の一番上の表は、あるゲームのマスタ(親マスタ)であり、story_quest_master(801)と言う名前が付けられている。まず、このような統一されていない(すなわち、標準ではない)マスタの構造として、クエストやガチャを引いたときに、そのアクションをしたら、何を、どのような確率で、獲得できるかなどの情報がこのマスタの情報に含まれている。
1つのマスタの表で直接もらえるアイテムを指定している形式もあるが、報酬グループなどという形で間接的にもらえるアイテムのグループリストのidを指定していることもある。そして、さらにマスタに記載された対象となるidの詳細が書いてある別のマスタを参照すると、そこでさらに別のグループリストが指定されているという形で入れ子構造になっている事もある。
例えば、図8の例では、大本のマスタ(すなわち親マスタ)であるstory_quest_master(801)という表があり、それぞれのストーリーのidが「10001」、「10002」、「10003」と一番左のidの列に書いてある。それぞれのストーリーのidに対して、first_reward_group_idという最初(初回)だけ取れるアイテムのidと、random_reward_group_idという毎回取れるアイテムのidが記載されている。これらのそれぞれは、10001などのストーリーのidの列の右の列に順番に記載されている。
例えば、図8では、ストーリーのidが10001である場合、first_reward_group_idが指定するアイテムのグループリストは、1001であり、random_reward_group_idが指定するアイテムのグループリストは、201である。
これに対して、初回だけの報酬のグループの場合、first_reward_group_master(802)という別のマスタ(子マスタ)があり、その中でグループidが「1001」のものは、item_idが「11」のものが「10」個(amount)取れるということが記載されている(810の流れ)。このように、2つ以上の複数のマスタを経由しないと(この場合は、親と子の2つのマスタ)、最終的に対象のクエストにおいて、いったいどれくらいのアイテムが取れるかというのを具体的に知ることができない場合がある。例えば、アイテム11は、story_quest_master(801)という親マスタからfirst_reward_group_master(802)という子マスタを参照すれば、アイテムの取得量が分かる。
次に、story_quest_master(801)でidが「10001」の場合、毎回取れるアイテムのid(random_reward_group_id)は、「201」である。このid「201」のアイテムは、さらに別のマスタ(子マスタ)random_reward_group_master(803)を参照すると、random_reward_idが「2001」と分かる(820の流れ)。次に、別のマスタ(孫マスタ)random_reward_master(804)を参照すると、random_reward_idが「2001」に対するアイテムid(item_id)が「21」であり、重み(weight)が10000であり、数量(amount)が「5」であることが分かる(825の流れ)。random_reward_group_idに対しては、random_reward_group_master(803)及びrandom_reward_master(804)という2つの別々のマスタ(子マスタと孫マスタ)を経由しないと(820及び825の流れ)、どのアイテムがどのぐらいの確率で取れるか分からない。すなわち、この場合は、マスタが3階層構造(すなわち、マスタが801、803及び804の3つ)になっている。
図9は、従来の標準ではない入れ子構造のマスタを示す図である。図9には、3つのマスタが記載されており、それぞれの関係についてこれから説明する。
図9は、ガチャのマスタの構造の一例を示す図である。図8はクエストのマスタ構造を示していたが、図9はガチャのマスタ構造を示している。ガチャのようにある確率で何がもらえるか分からないようなものも、通常は、図8と同様にマスタが何段階かの入れ子構造となっている。図9を参照して、先ず、gacha_master(901)というマスタに、ガチャのidが「50001」、「50002」と記載されている。ガチャの各idに対してもらえるアイテムについてはlot_table_idの列にそれぞれ「501」、「502」のように参照すべきグループが指定されている。すなわち、親マスタであるgacha_master(901)だけを参照しても、何がどのような確率でもらえるのか分からない(すなわち、親マスタであるgacha_master(901)にはweight(重み)を表す列がない)。
次に、gacha_lot_table_master(902)というマスタを参照すると、idが「501」というガチャのグループの中に希少性(rarity)としてのレベルが、SR(Super Rare:極めて希少)、SSR(Super Super Rare:極めて極めて希少)、UR(Ultra Rare:超希少)という3つがあることが分かる(910の流れ)。ガチャの場合は、ある重み(weight)で何かが取れるという形になっているので、例えば、ガチャidが50001の場合、SRというグループ、SSRというグループ、URというグループが取れる重み(weight)は、それぞれ80、15、5というようにgacha_lot_table_master(902)に記載されている。
ここで、重み(weight)とは、無次元量であり、それぞれの事象が発生する相対比を表す。従って、それぞれの事象が発生する確率は、対象の事象の重みを同じグループの事象の重みの合計で割った値になる。例えば、この場合、ガチャid501に関して、SRが発生する確率は、SR自身の重みをSR、SSR、URの3つすべての重みの合計、すなわち100(=80+15+5)で割った値であるので、SRが発生する確率は、80÷100=80%となる。同様に、SSRの発生確率は、15%であり、URの発生確率は、5%となる。ただし、重みを使わないで、直接発生確率をマスタに記載してもよい。
次に、希少性(rarity)については、SR、SSR、URという各グループで何が取れるかを記述するマスタ、gacha_prize_table_master(903)を参照する。gacha_prize_table_master(903)を参照すると、SRグループには「SR_A」、「SR_B」、「SR_C」という3種類のキャラクター(chara)が記載されており、それぞれの重み(weight)の値がいずれも「10」となっている(920の流れ)。すなわち、「SR_A」、「SR_B」、「SR_C」という3種類のキャラクターの重みは、それぞれ、10:10:10(すなわち、1:1:1)であり、各キャラクターは、33.3%(=10÷(10+10+10))の確率でもらえることが分かる。
このように、クエストのマスタに関しては、前述の図8のfirst_reward_group_id(802)のように報酬のグループが指定されている場合や、図9に記載されたガチャのSRようにグループのマスタ(すなわち、gacha_lot_table_master(902))が指定されていてその中から、どれがどのくらいの割合で出るかという重み(weight)がかかっており、且つ個別のアイテム名ではなくて、SR、SSR、URなどのグループ名を指定して、さらにその中で細かく指定していくような多重の入れ子構造になっていることもある。
このように通常、各ゲームの各マスタは、一段又は複数段の入れ子構造になっているが、どれが途中段階のグループのまとまりであり、どれが最終的に分解されたグループかということをそれぞれ指定することで統一性のある標準のマスタに変換することができると発明者は考えた。
図10は、本開示を適用した方法に従った標準のマスタを示す図である。本開示の方法では、group_trans_1_conf(1010)として大本のマスタを規定する。group_trans_1_conf(1010)では大きい括りと小さい括りの列(カラム)はどれかを指定する。本開示を適用した方法に従った表では、一番左に入力元となるマスタ(input_file)が指定される。この例のgroup_trans_1_conf(1010)では、4つの入力マスタが上から順にstory_quest_master、story_quest_master、gacha_master、gacha_masterである。ここで、story_quest_masterとgacha_masterは、二回出てくるが、各行で参照している子マスタが異なる。
2つのマスタ、story_quest_masterとgacha_masterは、それぞれ、図8に記載されたstory_quest_master(801)と図9に記載されたgacha_master(901)に対応している。
本開示の方法では、図10の3つの入力マスタにあるグループidの列(group_id_column)はクエスト名で、その右の列でそのクエストでは何が取れるかというのを指定したのがseparation_id_columnになる。ストーリークエストの場合、大本のクエストのidをgroup_id_columnにおいて指定して、取れる報酬をseparation_id_columnで指定してもよい。
本開示の方法では、group_trans_1_conf(1010)として一番大きいマスタを規定する。group_trans_1_conf(1010)では大きい括りと小さい括りのカラムはどれかを指定する。さらに、その中のselect_type_columnでは初回のみ報酬を取れる場合を「first」と指定し、毎回報酬を取れる場合を「loop」と指定する。この例では、select_type_columnは、「first(初回のみ)」と「loop(毎回)」の2種類を指定しているが、この種類は、3種類以上であってもよい。
図10では、分解したグループseparation_id_columnとしてfirst_reward_group_idやrandom_reward_group_idを指定しているが、これらのグループid自体はitem_idという最小の単位にはなれないので、first_reward_group_idやrandom_reward_group_idをさらに細かく規定するマスタをseparation_id_masterの列で指定して、次に、separation_id_masterで指定したマスタを参照する。
次に、group_trans_2_conf(1020)中のrandom_reward_group_masterとgacha_lot_table_masterを参照して、グループidとしては何を持っていて、最終的にどのidを見るかということを行う。first_reward_group_masterの場合、group_trans_2_conf(1020)で最終的なitem_idがseparation_id_columnに記載されているので、分解先(参照先)としてはgroup_trans_2_conf(1020)の中の値が最終値になり、獲得個数を指定しているのはamount_columnになる。例えば、amount_columnが空欄の場合は、数量は「1」と規定してもよい。
次に、group_trans_3_conf(1030)中のrandom_reward_masterとgacha_prize_table_masterを参照して、グループidとしては何を持っていて、最終的にどのidを見るかということを行う。random_reward_masterの場合、group_trans_3_conf(1030)で最終的なitem_idがseparation_id_columnに記載されているので、分解先としてはgroup_trans_3_conf(1030)の中の値が最終値になり、獲得個数を指定しているのはamount_columnであり、重みはweight_columnで指定される。例えば、amount_columnが空欄の場合は、数量は「1」と規定してもよい。
このような操作を繰り返す事でどのゲームメーカーのどのタイトルでも通用する標準のマスタを作成できる。図10を参照して説明したように、一番大きいグループからより小さなグループに分解するマスタがgroup_trans_1_conf(1010)で、さらにそれを細かく分解するのがgroup_trans_2_conf(1020)で、さらにそれを細かく分解するがgroup_trans_3_conf(1030)という形で、同じ構造のマスタでどんどん連結できるという構造になる。この状態でマッピングすると、前述のロジックに従ってアウトプットとしてはgroup_idがこれ、separation_idがこれと表示され、さらにそれぞれ初回報酬なのか毎回もらえる報酬なのかによって参照先が分かれていく。
図11は、本開示の標準のマスタを示した図10によって、各アイテムとその数量及び重みを整理して記載した表である。図11に記載の各表には、左の列から、行番号、group_id、separation_id、select_type、amount(数量)、weight(重み)が記載されている。
図11に記載した3つのマスタ、group_trans_1(1110)、group_trans_2(1120)、group_trans_3(1130)には、group_idの列で示されたアクションをすると、separation_idの列に記載されたものがamountの列に記載された量もらえるという形式になっている。次に、separation_idになっているものが次のgroup_trans_x(ここでxは1以上の整数)のgroup_idになる。例えば、group_trans_1(1110)のgroup_idが「10001」と指定されたものに対してseparation_idが「1001」となっているものは、次のgroup_trans_2(1120)のgroup_idが「1001」ときて(1111の流れ)、さらにその「11」というアイテムid(separation_id)に分解されるという形で、それぞれグループのもの、分解されたものという関係がどんどんでき上がっていく。このような形で、すべてのマスタは標準化されて、本開示を適用したテンプレートの標準のマスタに移行することができる。
これを元に「10001」というアクションを一回実行すると最終的なアイテムが期待値として何個取れるかという計算が行われる。
group_trans_1(1110)からgroup_trans_3(1130)への流れは、以下の通りである。
group_id(group_trans_1(以下最後の番号のみ表示する))→
separation_id(1):rate(1),amount(1)
group_id(2)→
separation_id(2):rate(2),amount(2)
group_id(3)→
separation_id(3):rate(3),amount(3)
ここで、group_trans_xでgroup_id(x)を獲得したときに、一つのgroup_id(x)に対して、separation_id(x,m(1))、separation_id(x,m(2))、…separation_id(x,m(n))というように複数手に入る場合があり、そのとき、rate(x,m(k))はgroup_id(x)を獲得したときにseparation_id(x,m(k))が手に入る確率と定義する。
このとき、各k:1≦k≦n、W(separation_id(x,m(k)))をseparation_id(x,m(k))の重み(weight)とする。
次に、以下のように仮定する。
A:アクション
I:アイテム
Depth(A,I):アクションAをしたときに式1でseparation_id(x,m(k))=アイテムIとなるような変数x(下図ではx=3とする)
E(A,I):アクションAをしたときに、アイテムIが手に入る個数の期待値
s(i,k):アクションAをしたときにアイテムIが手に入る個数の期待値を計算する際にgroup_trans_iにおいて計算に使用するseparation_id
となる。
以下で、図11を参照して、いくつかの具体例について説明する。
<クエスト報酬の場合>
クエスト10001を1回プレイすると、アイテムグループ1001及びアイテムグループ201が手に入るとする。それぞれグループの内訳は、
一回目に取れるアイテム(select_typeがfirst)として、
アイテムグループ1001=アイテム11×10個(group_trans_2の行1参照)
毎回取れるアイテム(select_typeがloop)として、
アイテムグループ201=アイテム21×5個+アイテム22×5個(group_trans_2の行3及び行4並びにgroup_trans_3の行1及び行2参照)
なので、両方を合計すると、
クエスト10001=アイテム11×10個+アイテム21×5個+アイテム22×5個
となる。
<ガチャの場合>
クエスト10001で、ガチャ501を1回引いた場合のUR_Aの期待値計算は、group_trans_1の行7を参照して、以下のようになる。
ガチャ501でURは5%であり(group_trans_2の行11参照)、URの中にはUR_A、UR_Bがあるので(group_trans_3の行11及び12参照)、
期待値=1×0.05×0.5=0.025
となる。従って、ガチャ501を1回引いた場合のUR_Aの期待値は0.025となる。
図12は、本開示を適用したアウトプットを示す図11から計算した各アイテムの期待値を示す図である。図12で一番右の列「初回」にあるフラグは、そのアクションが初回である場合は「TRUE(真)」であり、2回目以降は「FALSE(偽)」になる。すなわち、「初回」の列がTRUE(真)である行は、そのアクションが初回のみ与えられるアイテムを示し、「初回」の列がFALSE(偽)である行は、そのアクションが2回目以降に対して与えられるアイテムを示している。
また、図12の行1~行9は、クエストでもらえるアイテムを示し、行10~行17と行19~行26は、ガチャでもらえるアイテムを示している。すなわち、行1~行9では、アクション名の列にクエスト番号が入っており、行10~行17と行19~行26では、アクション名の列にガチャ番号が入っている。
例えば、図12の行1を見ると、アクション10001を実行した場合に、アイテム11が初回(すなわち、初回の列がTRUE)のみ数量10.0もらえる。そして、行2を見ると、行1と同じアクション10001を実行した場合でもそのアクションの実行が2回目以降(すなわち、初回の列がFALSE)の場合は、アイテム21が数量5.0もらえることが分かる。
一方、図12の行10を見ると、ガチャであるアクション50001を実行した場合に、アイテムSR_Aが、2回目以降は、0.266の確率でもらえることが分かる。この例では、行10から行27に記載されたガチャの初回の列はすべて「FALSE(2回目以降)」になっている。
図8~図12は、大本の図8及び図9のマスタが入れ子構造になっている例を説明したが、図13~図16は、大本の図13のマスタが入れ子構造になっていない例を示す。
図13は、標準ではないマスタを示した図である。図13に記載のマスタは、標準ではないマスタであり、バトルに関連するマスタであるbattle_master(1310)とガチャに関連するマスタであるevent_gacha_master(1320)が記載されており、いずれのマスタも1つのマスタのみで、参照する子マスタなどがなく、入れ子構造(すなわち、階層構造)になっていない。
図13のbattle_master(1310)のid(すなわち、3001、3002、3003、3004及び3005)に紐付く形で、初回にもらえる最終的なアイテムのid及び数量及び2回目以降のもらえる最終的なアイテムのid及び数量が1つのマスタに記載されている。
例えば、バトル用のbattle_master(1310)を参照すると、初回にもらえるアイテムのidは、first_tresure_idの列に上から順番に、111、111、111、111、111と記載されており、各idのもらえる数量は、first_tresure_amountの例に、上から順番に、5、10、15、20、25と記載されている。一方、毎回もらえるアイテムのidが、random_tresure_idの列に、上から順番に、222、222、222、222、222と記載されており、各idのもらえる数量がrandom_tresure_amountの例に、上から順番に50、100、150、200、250と記載されている。
例えば、アイテムidが3001のバトルの場合は、初回にもらえるのはアイテムidが111で、個数は5個であり、毎回もらえるアイテムidは222で、個数は50個である。
また、図13のもう1つのマスタであるガチャ用のevent_gacha_master(1320)には、idである100001に紐付ける形で、各カード(card)の重み(weight)が記載されている。例えば、ガチャidが100001で、カードがUR_AAの場合は、重みは1となり、ガチャidが100001で、カードがSSR_AAの場合は、重みは4となる。重みと確率の関係は、前述の通りである。
図14は、図13の非標準のマスタを、本開示を適用した標準のマスタに変換した図である。図13のマスタであるbattle_master(1310)及びevent_gacha_master(1320)には、それぞれのアイテムが、どのくらいの数量又は重みづけでもらえるかについて、そのマスタ自体に最終的な情報が入っていて、階層化されていないシンプルな構造である。そのため、図13のマスタのbattle_master(1310)及びevent_gacha_master(1320)を標準のマスタに変換してもマッピングに必要な表はgroup_trans_1_confが1つしかない。
図14の基本な構造は、図10の1010と同様であるので省略する。
図13のマスタを本開示を適用した標準のマスタに変換すると、図8で示したマスタと同様に、図15に示すようなアウトプットに整理できて、図16に示すような期待値一覧を計算できる。
図15は、図14に示した本開示を適用した標準のマスタのアウトプットを示す図である。この図では、行1~行10は、クエストを表し、行11~行26は、ガチャを表している。例えば、クエストの場合は、group_trans1の行1を参照すると、group_idが3001であり、separation_idが111である場合、select_typeは、first(初回)であり、amount(数量)は、5になっている。同様に、ガチャの場合は、行11を参照すると、group_idが100001であり、separation_idがUR_AAである場合、select_typeは、ランダムであり、amount(数量)は1で、weight(重み)は1になっている。
行1で、select_typeがfirst(初回)なのは、separation_idが111だからではなく、単に設定として、group_idが3001のクエストをやったときには、もらえるアイテムが設定されていて、separation_idが111のものが、5個もらえるという設定値については、初回のみもらえる初回報酬であるというふうに元のマスタに設定している。ここでは、select_typeをfirstとして、初回報酬であることがわかるように書いてある。例えば、group_idが3001のクエストをやったときには、separation_idが111のアイテムが、初回(first)は5個もらえて、それとは別に、周回報酬として、初回以外でも毎回(loop)1個もらえるという設定値になっている場合もあり得る。
図16は、図14に示した本開示を適用した標準のマスタの期待値一覧を示す図である。この図では、行1~行10は、クエストを表し、行11~行26は、ガチャを表している。例えば、図16の行1を参照すると、アクション名が3001のとき、アイテム名111のものが、初回のみ(TRUE)、数量5.0でもらえるということが分かる。また、行11を参照すると、アクション名が100001のとき、アイテム名がUR_AAのものが、0.01の期待値でもらえることが分かる。
図17は、プレイ想定を示す図である。この表では、アクション毎に、日毎のアクション想定回数(すなわち、プレイ想定)を作成する。具体的には、クエストに関するstory_quest_master(1710)の表と、ガチャに関するgacha_master(1720)の表の2つのプレイ想定の表が記載されている。図17の上側にあるstory_quest_master(1710)のidの列には、クエストのidが、上から10001、10002、10003と記載されている。idの列の右側の3つの列には各日(day1(1日目)、day2(2日目)、day3(3日目))にプレイヤーが行う各クエストの回数が記載されている。例えば、クエストidが10001のクエストを、プレイヤーは、day1で5回、day2で3回、day3では0回行うと仮定する。この場合、action_num(アクションの回数)の空欄は、0回を表す。
また、図17の下側にあるgacha_master(1720)のidの列には、ガチャのidが、上から50001、50002と記載されている。ガチャidの右側の3つの列には各日(day1(1日目)、day2(2日目)、day3(3日目))にプレイヤーが行う各ガチャの回数が記載されている。例えば、ガチャidが50001のガチャを、プレイヤーは、day1で2回、day2で3回、day3では0回行うと仮定する。この場合、action_num(アクションの個数)の空欄は、0回を表す。
図18は、各アクションにおける各アイテムの日毎の獲得個数を示す図である。前述の図12に記載の期待値に、図17に記載のプレイ想定の日毎のアクション回数をかけ合わせて、それぞれのアクションとアイテムの組み合わせに対して、各日にどれくらいの量のアイテムが取れるのかを計算する。
図18では、行1~行9は、クエストのアクションを表し、行10~行27は、ガチャのアクションを表している。
例えば、行1を見ると、このときのアクション名は「10001」であり、アイテム名は「11」である。アクション回数は、上述の図17を参照して、day1(1日目)は5回、day2(2日目)は3回、day3(3日目)は0回であるので、図12の対応する行の量に各日のアクション回数を掛け合わせると、各日の獲得個数になる。例えば、行1の場合、day1の獲得個数は、10×5=50、day2の獲得個数は、10×3=30、day3の獲得個数は、10×0=0となる。
次に、例えば、行10を見ると、このときのアクション名は「50001」であり、アイテム名は「SR_A」である。アクション回数は、day1(1日目)は2回、day2(2日目)は3回、day3(3日目)は0回であるので、図12の対応する行の量に各日の回数を掛け合わせると、各日の獲得量になる。例えば、行10の場合、day1の獲得量は、0.266×2=0.532、day2の獲得個数は、0.266×3=0.798、day3の獲得個数は、0.266×0=0となる。
図18では、同じアイテムが複数のアクションとの組み合わせで記載されている。例えば、アイテム名が「11」については、行1、行4、行7、行18にそれぞれ異なるアクション10001、10002、10003、50001と共に記載されている。
図19は、プレイ想定に従った各アイテムの日毎の獲得個数を集計した図である。各アクションによって取れる同じアイテムを合計することで、複数日プレイした際の各アイテム獲得個数の予測をすることができる。図19のday1(1日目)、day2(2日目)、day3(3日目)の各例が、前述のプレイ想定回数×期待値の各日の計算結果をアイテム毎に整理して、合計を算出した数となる。一番右の例total(合計)は、各アイテムのday1からday3の3日間の合計を表す。
例えば、アイテム名が11のアイテムは、day1(1日目)に計10個取得でき、day2(2日目)に計20個取得でき、day3(3日目)に計130個取得できるので、この3日間、このゲームをすると合計でアイテム11が160個取得できることになる。
また、例えば、アイテム名がSR_Aのアイテムは、day1(1日目)に計0.532の量を取得でき、day2(2日目)に計0.798の量を取得でき、day3(3日目)に計0.532の量を取得できるので、この3日間、このゲームをすると合計でアイテムSR_Aが1.862の量を取得できることになる。
図19では、アイテム名11、21、22は、クエストで取れるアイテムであり、SR_AからUR_Eは、ガチャで取れるアイテムを表している。
図20は、アイテムの消費量を説明する表である。図19では、各アイテムの獲得量を説明したが、図20では、各アイテムの消費量を説明する。アイテムの消費についてもアイテムの獲得と同様で、図12の期待値一覧で量の列がマイナスのものが消費個数を表すので、アイテム消費個数にプレイ回数を掛けることで、消費したアイテムの種類と量が分かる。期待値を表す図12において、量がマイナスになっているのは、行18のアイテム11と、行27のアイテム21の2つのアイテムである。逆に言えば、アイテム11とアイテム21以外は、図12の例では消費されていない。
図20のアイテム11の行を見ると、day1での消費は40個で、day2での消費は60個で、day3での消費は0個であるので、この3日間のアイテム11の消費の合計は、100である。
例えば、図20に記載した例では、アイテム11とアイテム21は、3日間のトータルとしてそれぞれ100個、40個が消費されるが、その他のアイテムは消費されない(すなわち、トータルの消費個数がゼロ)であることが分かる。
図21は、各アイテムの収支を示す表である。プレイ想定に従って図19で計算された各アイテムの獲得量と、プレイ想定に従って図20で計算された各アイテムの消費量から、アイテム別の収支(=獲得量-消費量)が計算できる。このように、各アイテムの獲得個数と消費個数の差を求めることで、ゲームをプレイする上でのアイテムの収支が分かるようになる。
例えば、アイテム11は、day1の収支が-30で、day2の収支が-40で、day3の収支が130なので、この3日間の収支は、60となる。
例えば、アイテムSR_Aは、day1の収支が0.532で、day2の収支が0.798で、day3の収支が0.532なので、この3日間の収支は、1.862となる。
図12に記載された期待値を使って、図14~図20に関して説明した方法によって、図21の各アイテムに対する収支が計算できる。このような方法で、クエスト及びガチャにおける、各アイテムの獲得量と消費量を計算し、その結果、獲得量から消費量を引いた収支を計算することによって、上述の図6で説明したような魔法石の収支などを計算することができる。
このように各アイテムの収支をパラメータ調整前後で比較し、パラメータ調整後の各アイテム又は全てのアイテムなどの収支のバランスを調整することによって、より良いパラメータ、すなわち、より稼げるゲームのパラメータを発見することが可能となる。
図22は、本開示に従った動作を行うプログラムを実行するコンピュータのブロック図である。例えば、本開示によるプログラムを実行するコンピュータ2200は、プロセッサ2210、グラフィックス2220、チップセット2230、メモリ2240、ネットワーク制御2250、キーボード/マウス2260、及びストレージ2270を備えてもよく、これらの構成要素は、通常互いに双方向のバスで接続されている。
プロセッサ2210は、メモリに記憶されたプログラムをチップセット2230と連携して実行する。チップセット2230は、プロセッサ2210から制御され、グラフィックス2220、メモリ2240、ネットワーク制御2250、キーボード/マウス2260、ストレージ2270の機能を制御する。
グラフィックスは、コンピュータ2200の内部又は外部の表示装置を制御する。ネットワーク制御2250は、外部のネットワークに接続され、有線又は無線のLANなどを制御する。キーボード/マウス2260は、コンピュータ2200を制御する入力手段であって、コンピュータ2200と一体型でもよく、外部にあってもよい。ストレージ2270は、ハードディスクや光ディスクを含み、チップセット2230を経由して、プロセッサ2210によって制御され、データ及び/又は命令を保存する。
例えば、図7を参照して説明したステップS701、S702、S703、及びS704を実行する命令を含むプログラムを、図22で説明したコンピュータ2200を用いて実行してもよい。
本開示による方法は、機械学習又はディープラーニングを含むAIを利用して実行してもよい。
本開示は、説明の便宜のためゲームを前提として説明したが、本開示は、ゲームに限らず、例えば、Webサービスなどのシミュレーション全般にも適用可能である。例えば、ユーザーが記事を書くことができるサービスでは、ユーザーが記事を書くことにより、ログインボーナス的なゲームで使われる要素が入っている。また、ポイントなどを使ってマンガを読むことができるマンガ系のアプリでも、同じように、ログイン日数やアクションに応じてアイテムが貰えたり、使えたりする。このようなWebサービス又はアプリのようにゲームの仕組みを取り入れている分野にも、本開示は適用できる概念である。このようなサービス又はアプリ並びにゲームの分野であっても、プレイヤーはユーザーとも呼ばれる。
ここから、実施例2について説明する。実施例2は、例えば、本発明に従ったオートパラメータ(Auto Params)と呼ばれるプログラムによって実装されてもよい。
<実施例2の全体の概要>
上述の通り、一般にゲームの最適解の探索や、最適なマスタ設定を行うことは容易ではない。そこで、本発明によるオートパラメータ(Auto Params)は、一般のゲームに対する最適なプレイを探索し、その結果を元にして、さらにマスタを自動調整することにより、プレイヤーの成長度合いの調整を行う方法である。特に、最適なプレイの探索には、(1)ユーザーの行動が同じでもランダム性によって結果が変わる場合を考慮して行う場合と、(2)実用上の観点から計算量の負荷軽減のため、ユーザーの行動を期待値で代表して算出する場合の2パターンがあり、それぞれの最適プレイの探索において、AIの強化学習などを用いてもよい。
図23は、最適プレイを計算する方法の概要を示すフローチャートである。図23の場合、先ず、従来のような詳細なプレイ想定ではなく、大まかなプレイ想定を作成する(ステップ2301)。
次に、ゲームプレイは、ステータスの伸びとリソース集めの効率が重要なので、プレイ想定の条件でその効率が最大になるような、細かなプレイ想定を、強化学習εグリーディ法などで算出する(ステップ2302)。ここで効率とは、例えば、ある一定のプレイ時間、課金額において、ゲームの有利不利を表す各種カードやキャラクターなどのステータスのパラメータの上昇量及び、獲得するアイテムなどのリソースの価値の合計値が、最も高いことを示す。なお、基本的にはステータスのパラメータの上昇量の方を重視するが、重視する度合いについては、ゲームごとに変えてもよい。
図23の最後で、各コンテンツで、どのようなプレイをすると、平均的にステータスや獲得リソース量が同じ期間で最大になるか、という最適プレイを細かなプレイ想定に基づいて計算する(ステップ2303)。以下で、各ステップについて詳細に説明する。なお、ユーザーの行動は同じでも、ガチャやクエストの確率ドロップ報酬などのように、確率によって結果が左右されるのが通常なので、その結果の分布の影響を考慮したケースと、考慮せず期待値ベースで計算する2つの方法があるが、大半の部分で共通しているので、差異がある部分については必要に応じてその差異などについて記述する。
すなわち、最適プレイ想定作成は2パターンある。(1)計算量負荷高いけれど正確な方法と、(2)精度やや落ちるけれど計算量負荷少なめな方法である。(1)の詳細に算出する場合は、各コンテンツでの不確定要素、例えば、ガチャの当たり外れや、敵を倒したときに時々もらえる報酬などのように、当たりもあるし、外れもあるという条件で、モンテカルロ法で複数回プレイを行った場合のプレイの効率を、ばらつきも含めて分析を行い、効率が最大となるものや平均の効率、中央値の効率あるいはこれらと分布の標準偏差を組み合わせるなどをした指標を、プレイを行った際の効率と定義して、その結果を元に強化学習εグリーディ法などを組み合わせて最適プレイを見つけるような手法が望ましい。この(1)計算量負荷高いけれど正確な方法は、上記のようなやり方では計算負荷もかかり、実用上はここまで精度がなくても十分に通用するケースも多いので、各コンテンツをプレイしたときに消費及び獲得できるリソースの期待値を定義し、その期待値ベースでのプレイの効率を算出したときに、最大となるようなプレイ想定を、強化学習εグリーディ法などを用いて見つける手法が(2)の精度やや落ちるけれど計算量負荷少なめの手法となる。
<プログラムの構成>
本Auto Pramasプログラムは、構成として以下の要素の1つ以上を含んでもよい。
・一般ゲームモデル
・最適ゲームプレイ探索(欲張り(グリーディ)法、強化学習など)
・ガチャのランダム性を考慮したモンテカルロ・シミュレーション
・マスタ自動調整
<実行するための準備>
PYTHONプログラミング言語を使った実装方法の一例を示す。この実装方法では、以下のようにlocalディレクトリまで移動し、PYTHONPATHを実行する。
cd $auto_params/local
PYTHONPATH=$PWD/
これにより以下のように各種test関数の実行ができるようになる。
python tests/test_*py
<インプットファイル>
本プログラムの実行のためには共通して例えば以下のインプット(入力)ファイルが必要である。
・action.csv
・master_user_level_exp.csv
・resource.csv
・power.csv
・level_up.csv
・setting_value.pickle
・setting_time.pickle
<一般ゲームモデル>
本方法では、n枚のカードデッキを用いてクエストをクリアしていく汎用的なゲームを想定して実装を検討する。カードには、上述のようにレアリティ(Rarity)、レベル(Level)などがあり、それらの値により戦力値が決まってもよい。ゲームモデル(以下ゲーム関数ともいう)の中で、プレイヤーオブジェクト(以下単にプレイヤーともいう)が、その選択に従いゲームをプレイする。ゲーム関数によって、主として、例えば以下の行為が可能である。
・クエストをプレイする
・ガチャを引く
各種設定値は、例えば、出願人である株式会社Precious Analytics(以下、プレアナともいう)の標準マスタから読み込んでもよい。また、ゲーム中で消費又は獲得する全てのアイテムやデッキを構成するキャラクターには価値があらかじめ定められており、プレイヤーは獲得したアイテムとキャラクターの総合的価値を定められた期間プレイし、最大化することを目的としてもよい(以下、総価値を最大化するためにプレイすると仮定する)。
<クエスト>
図24は、クエストの区分とプレイ順番の関係を示す図である。クエストは、任意の種類が存在する区分(例えば、「ストーリーA」、「イベントA」、「イベントB」など)によって区別されている。それぞれの区分内でプレイ順番が設定されており、プレイ順番より前の順番が振られているクエストがクリアされて初めて、その次のプレイ順番のクエストは解放される(すなわち、プレイヤーがプレイできる状態になる)。また、それぞれのクエストには初回用、2回目以降用の異なるスタミナ消費値、プレイ報酬値が設定されており、プレイヤーは必要なスタミナ値を消費することによってクエストをプレイし、その結果プレイ報酬を受け取ることができるようにしてもよい。
例えば、図24の上半分を見るとクエストの区分としてストーリーAの第n章2401が記載されており、この段階では、ストーリーAの第n章2401は、未だプレイされていない(すなわち、未クリア状態)。次に、プレイヤーがこのストーリーAの第n章2401をプレイする(Action!)。そうするとプレイの結果ストーリーAの第n章2402は、クリアされ(クリア済みの状態)、プレイヤーは次のストーリーAの第n+1章2403をプレイできるようになる。また、プレイヤーが初めてストーリーAの第n章をクリアした場合は、初回報酬2404を得るようにしてもよい。実際には、そのストーリーAの第n章2401の1回目のプレイでそのストーリーをクリアできるとは限らないが、単純化のため1回目のプレイでその章をクリアできると仮定した。
一方、図24の下半分を見るとクエストの区分としてストーリーAの第n章2411が記載されており、この段階では、既にクリア済みであり、このプレイヤーは、このストーリーAの第n章を既にクリアしていることが分かる。次に、プレイヤーがこのストーリーAの第n章2411を再びプレイする(Action!)。そうするとプレイの結果ストーリーAの第n章2412は、再びクリアされ(クリア済みの状態)、今度は初回報酬ではなく2回目以降のクリアに対して与えられる周回報酬2413を得るようにしてもよい。この場合は、ストーリーAの第n章を2回以上クリアしているので、ストーリーAの第n+1章は、新規クエスト開放とはならないようにしてもよい。
<クエストプレイ制限>
クエストをプレイする上で、本開示によるプログラムでは必要に応じて、以下の制限をマスタ設定により設けてもよい。
・最低総戦力値:この最低総戦力値を設定することによって、あるクエストに到達したプレイヤーのその時点のデッキの総戦力値が予め設定された設定値未満の場合は、そのプレイヤーはその時点でそのクエストをプレイできない(例えば、クリアできないことを想定している)。
・プレイ回数上限:プレイヤーがそのクエストに対する設定されたプレイ回数上限を超えている場合は、そのクエストはプレイできない。(例えば、基本的に1回しか実行できないシナリオストーリーや、回数制限があるイベントクエストなどを想定している)
<ガチャやドロップ報酬など確率によって結果が左右される機能について>
本開示によるプログラムでは、例えばガチャについては、期待値ベースのガチャ(以下、期待値ガチャともいう)、ランダムガチャの2種類が実装されてもよい。また、クエストなどの報酬で確率によって獲得できるかどうかが変わるいわゆるドロップ報酬と呼ばれるようなものについても、期待値ベースドロップ報酬とランダムドロップ報酬の2種類が実装されても良い。
・期待値ガチャ:期待値ガチャの場合、カードは期待値として手に入る(例:レアリティ5が出る確率5%の10連ガチャを一回引いた場合、レアリティ5のカードは統計的には0.5枚手に入る)。プレイヤーは各レアリティのカード枚数累積値を保持しており、各レアリティのカード枚数累積値が1を超えた時に、レベル1のカード1枚が手に入り、そのレアリティのカード枚数累積値から1を引くものとする。
--gacha_type “expect”
により、期待値ガチャが指定可能である。
・ランダムガチャ:ランダムガチャでは、設定された排出確率により各レアリティのカードが排出される。
--gacha_type “random”
より、ランダムガチャが指定可能である。
<プレイヤー>
ゲームプレイヤーの一日の行動は、例えば、以下の通りである。
1.10日に一回10連ガチャを引く。
2.以下をスタミナがなくなるまで繰り返す。
・可能なクエストの中からプレイヤーの選択によって最適なクエストを選びプレイする
・マスタに従った成長判定、キャラクター強化
<キャラクター強化方法>
本開示による方法では、例えば、プレイヤーが所持するキャラクターのうち、そのキャラクターを1レベル上げるために消費する総価値と上昇する戦力値の比から最も効率良いレベルを上げる対象を決定し、そのキャラクターのレベルを上げる欲張り法を採用している。
<実行方法>
例えば、以下のtest関数によりgame playのテスト計算が可能である。
python tests/test_game_play.py \
--max_level 70 \
--deck_num 6 \
--action_type “greedy” \
--elapsed_days 60 \
--input_path “./input_csv” \
--output_path “./output_csv” \
--gacha_type “expect” \
--debug_mode false
2行目以降の引数は省略可能であり、一例として今回の設定値は全てデフォルト(default)値である。max_levelは、デッキのキャラクターの最大レベルで例えば70以下の自然数が指定可能ある。deck_numは、所持するデッキの枚数である。action_typeは、プレイヤーの行動指針で、ランダムに行動する「random(ランダム)」、欲張り法を用いる「greedy(グリーディ)」、及び強化学習を用いる「qlearning(キューラーニング)」が指定可能である。欲張り法、強化学習については後述する。input_path、output_pathは、それぞれ、入力のためのcsvファイルが存在するパスと、出力する場所のパスである。gacha_typeは、キャラクターのガチャのタイプで、期待値ベースの「expect」確率でランダムに1枚ずつ排出される「random」が指定可能である。debug_modeは、デバッグ用に用意された引数で、Trueにした場合、主な処理の処理時間などがログとして出力されるようにしてもよい。
<最適ゲームプレイ探索>
本方法では、例えば、ランダムにクエストをプレイ(random)、各クエストをプレイする効率が既知とした欲張り法によるゲームプレイ(greedy)、強化学習を用いた最適ゲームプレイ(qlearning)の3通りの方策の実装を行う。
・greedy:greedyでは、各クエストをプレイすることによって得られる総価値と消費するスタミナの比により最も効率的なクエストを選び行動する。各関数で、
--action_type “greedy”
とすることで指定できる。
・qlearning:最適プレイを探索するため、強化学習ε-greedy法を用いて、Q値の学習にはモンテカルロ法を用いてもよい。強化学習を適用する重要な利点として、あらかじめクエストから得られるアイテム量が分かっていなくても最適解の産出が可能な点がある。強化学習では一般に、その時点の環境や状況を示す状態s、そのとき、エージェント(本プログラムの場合、プレイヤー)がとった行動a、行動aによって得られる報酬が重要となる。状態sとしては、日付とスタミナをとり、行動aとしては、クエストのプレイをとってもよい。行動aにより、スタミナを消費し、報酬を得て、デッキが強化されてもよい。報酬は、獲得したアイテムとデッキ強化によって得られた総価値の増分としてもよい。
図25は、強化学習を示す図である。先ず、使用されるマスタが入力される(ステップ2501)。次に、最適プレイ又はランダム選択が選択され、ε-greedy法で強化学習が行われ、報酬が計算される(ステップ2511)。次に、計算された報酬を使用して、モンテカルロ法でQ値が更新される(ステップ2512)。強化学習でこのステップ2510の訓練がくり替えされる。そして、最終的にプレイ最適解が出力される(ステップ2502)。以下で図25の各ステップの詳細について説明する。
<ε-greedy法>
ε-greedy(イプシロンーグリーディ)法は、強化学習の一種で、初期値の偏りなどによって局所解に陥ることを避けるために、ある適当な起きにくい確率εでランダムな行動をとるようにするものである。学習するにつれてεは0に収束するように更新する。学習終了の判定は、例えば、εがある値以下となるときである。
<モンテカルロ法によるQ値の更新>
日付d、スタミナ値sの状態s=(d,s)の学習回数t回目の行動aにより、報酬r
tが得られたとすると、次回学習時のQ値、Q
s,a
(t+1)は以下のように計算される。
ただし、
は学習回数t回目に行動aが選択された回数である。本開示による方法では、例えば、強化学習の関数が用意されており、以下により実行できる。
python tests/test_qlearning.py \
--max_level 70 \
--deck_num 6 \
--elapsed_days 10 \
--input_path “./input_csv”
--output_path “./output_csv” \
--gacha_type “expect” \
--debug_mode True
なお、本開示の方法では、greedy法におけるクエストの効率、qlearningにおけるQ値をプレイヤーがpriority queue形式の行動方針として持つことにより、行動方針の追加、プレイヤーが取ることの出来る各選択肢などの行動施策同士の比較が行えるような汎用的な構造になっていてもよい。
<モンテカルロ・シミュレーション>
モンテカルロシミュレーションモジュールでは、ガチャが完全ランダムであるときの最高レアリティのカードを初めて入手する日付(以下day5(5日目))と総価値、デッキの総戦力値の関係をシミュレーションすることができる。本来であれば、シミュレーションをたくさん行なった場合、day5を日付ごとにカウントした分布は山形になり偏るが、データを均一に集めるために、あるゲームプレイについて、day5が指定できるように実装されている。
図26は、モンテカルロ法を用いた場合の手順を示すフローチャートである。先ず、マスタ及びシミュレーション回数が入力される(2601)。次に、最適プレイ又は総戦力値計算が選ばれる(2602)。最後に、最適プレイ結果の統計分布が出力される(2603)。
モンテカルロ法の実行方法は、例えば以下の通りである。
python tests/test_MonteCarlo.py 1000\
--max_level 70\
--deck_num 6\
--action_type “greedy”
--elapsed_days 60\
--input_path “./input_csv”\
--output_path “./output_csv”\
--debug_mode True
第一引数として、何サイクルモンテカルロシミュレーションを行うのかを指定する必要がある。それ以外はgame関数の引数と同じであるが、ガチャタイプは”random”で固定としてもよい。ただし、上書きを防止するため、output_pathによって指定されたアウトプットファイルのパスにインプットとして必要であったファイルが存在した場合、アウトプットファイルのパス上にあるファイルが読み込まれる。
<アウトプットファイル>
-output_pathによって指定されたパスにinput_pathにあるインプットファイルがコピーされ、さらに、montecalo.logが生成される。生成例を以下に示す。
上記生成例において、cycle,power,rare5_first,valuesはそれぞれ、シミュレーション回数、総戦力値、day5(レアリティ5を最初に取った日)、総価値を表す。例として、サンプルデータ、シミュレーション回数10,000回行なった場合、mpと総価値の散布図は図27の通りである。各day5に対する総価値の平均をとると図28のように分布していることがわかる。
図27は、総価値とレアリティ5のカードを始めて獲得した日の関係を表すグラフである。図27の縦軸は、総価値(総戦力値)を表し、横軸は、レアリティ5のカードを初めて獲得した日を表す。横軸の日数が0から60へと左から右に変化してくのに伴い、総戦略値も変化している。例えば、横軸の日数が0のときは、総戦力値が136000やその下の6つの値もあり得るが、横軸の日数が10を超えてくると、すなわち、10日目以降にレアリティ5のカードを始めて取得しても、総戦力値として136,000を超える確率が少なくなることが分かる。
図28は、図27の各日付の平均値を表すグラフである。図28の縦軸は、総価値(総戦力値)の各日の平均値を表し、横軸は、レアリティ5のカードを始めて獲得した日を表す。図28から分かるように、横軸の日が0から5日ぐらいまで総価値の平均値は上昇し、その後、日数が増えるにつれて、総価値の平均値は下がっていき、日数が40日を超えた辺りからまた波打ちながら平均値が上昇し、最後に55日を超えた当たりから平均値は急下降する。
図29は、実施例3の概略を示すフローチャートである。一度最適プレイの詳細を出して、そのときの獲得リソース量と伸長ステータス量、そして、それらの各コンテンツ(定常クエスト、イベントクエスト、PvP、ガチャなど)毎の獲得量(計算結果)とを、開発側が意図した値とを比較し、その結果、パラメータ設定値を変更して、差が小さくなるように学習させる(ステップ2901)。次に、その差が、ある一定値以下になったら、収束したとみなし、ユーザーが最適効率でプレイすると、アイテム獲得量とステータスの伸び、及び、コンテンツ毎の配布比率が、開発が意図したものに近づくようなパラメータ設定値が求まる(ステップ2902)。
<マスタ自動調整(auto params)>
本発明に従った「auto params(オートプログラム)」モジュールでは、最適なプレイをした場合に期待される総戦力値となるようにマスタ設定値を自動調整してもよい。その概略図を図30に示す。
図30は、本発明によるマスタの自動調整方法を示したフローチャートである。図30を参照して、先ず、マスタ及び想定戦力値が入力される(ステップ3001)。次に、最適プレイ及び総戦力値が計算される(ステップ3011)。そして、計算された最適プレイ及び総戦力値に基づいてマスタが調整される(ステップ3012)。このステップ3011及びステップ3012を含む自動調整を、差が所定の値に収束するまで繰り返す(ステップ3010)。その結果、調整されたマスタが出力される(ステップ3002)。
期待された戦力値P
e、現在のマスタ値の時の最適プレイにおける戦力値P
(t)とすると、調整する前のマスタ値のベクトルm
(t)の調整式は以下の通りでもよい。例えば、aが0.8とか1.2のように特定の値を決めて計算する。
ここで、Γ
j(x)は小数点j以上切り捨てし、さらに、それで値が0になった場合には小数点第j以上での最小単位とする関数である。これによりマスタ値で0になるような部分や小数点以下多く続くような値になるのを防ぐ。期待される総戦力値に対して実際に最適プレイをした時の戦力値との誤差が、今回の例では5%以下となった場合に繰り返し調整を終了する。なお、この誤差5%については、ケースによって他の値になるものであり、固定値ではない。
python tests/test_auto_parans.py 1000\
--criterion 3 \
--ncyc 15 \
--max_level 70 \
--deck_num 6 \
--action_type ”greedy”
--elapsed_days 60 \
--input_path ”./input_csv” \
--output_path ”./output_csv” \
第一引数として想定される最適プレイでの最高戦力値を指定してもよい。また、本方法では、ストーリーの種類、アイテムの種類を指定して調整することが可能となっており、これ以外で必要だったインプットファイルの他に、以下のような「auto_params.csv」ファイルを作成し指定してもよい。id、大区分名、Item、調整倍率はそれぞれ、インデックス、ストーリーの種類、調整したいアイテム、始めにあらかじめ調整する倍率である。調整倍率を0以上に指定することにより、はじめにあらかじめ指定されたアイテムの取得量を調整倍率倍する。0の場合には調整しない。モンテカルロ・シミュレーションと同様、上書きを防止するため、output_pathによって指定されたアウトプットファイルのパスにインプットとして必要であったファイルが存在した場合、アウトプットファイルのパス上にあるファイルが読み込まれる。
<アウトプットファイル>
戦力調整されたマスタファイルとともに、戦力値が調整されていく過程のログファイルであるparams.logが以下のような内容で生成されてもよい。以下の例は、調整前の最適プレイによる総戦力値が990であり、総戦力値が900になるように調整していく様子である。
調整される過程は図31及び図32に示されるようになる。図31は、回数の変化による戦力値の変化を表すグラフである。図31は、回数(Cycle)を繰り返すことによって、戦力値(Power)が段々400から300付近に収束していることがわかる。
図32は、本発明の自動調整方法での調整の前後のマスタを表す図である。図32を参照すると、左側の表(3210)は、調整前の各クエストのキャラクター強化素材の値を示し、右側の表(3220)は、調整後の各クエストのキャラクター強化素材の値を示す。常にこのような傾向があるとは限らないが、図32の場合は、各クエスト及びイベントのキャラクター強化素材の値が、調整前(3210)から調整後(3220)で、小さくなっていることが分かる。
図31及び図32の例は、調整前(すなわち回数0)の最適プレイによる総戦力値が399であり、最終的に(すなわち回数5)総戦力値が301(すなわち300±1)になるように調整していく様子(図31)と実際に変化したマスタ値の様子(図32)である。このように最適プレイでの総戦力値を調整することによって、所望の総戦略値に近づけることができることが分かる。
<本開示のまとめ>
本開示の実施例1に係るゲームの評価方法は、コンピュータが、(A)マスタのパラメータに基づいて、プレイヤーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記プレイヤーが行う想定回数との乗算を計算するステップと、(B)前記乗算の結果に基づいて、各アイテムの収支を視覚化するステップと、を実行する。
本開示の実施例2に係るゲームの評価方法は、コンピュータが、(C)前記パラメータの変更指示に従って、前記パラメータを変更するステップと、(D)前記変更したパラメータに基づいて、前記期待値と前記想定回数との乗算を再計算し、前記乗算の再計算結果に基づいて、各アイテムの収支を視覚化するステップと、をさらに実行する実施例1に記載のゲームの評価方法。
本開示の実施例3に係るゲームの評価方法は、コンピュータが、前記(C)のステップから前記(D)のステップを、前記収支が所定の値以下になるまで繰り返す、実施例2に記載のゲームの評価方法。
本開示の実施例4に係るゲームの評価方法は、前記マスタは、複数のゲームで形式が統一されていない非標準のマスタから変換された前記複数のゲーム間で形式が統一されたマスタである実施例1に記載のゲームの評価方法。
本開示の実施例5に係るゲームの評価方法は、前記(B)のステップでは、前記各アイテムの収支の時間変化を視覚化する実施例1に記載のゲームの評価方法。
本開示の実施例6に係るゲームの評価方法は、前記(B)のステップでは、さらに前記各アイテムの獲得量及び消費量の時間変化を視覚化する実施例5に記載のゲームの評価方法。
本開示の実施例7に係るゲームの評価装置は、プロセッサ及び命令を記憶するメモリを備えるゲームの評価装置であって、(A)マスタのパラメータに基づいて、プレイヤーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記プレイヤーが行う想定回数との乗算を計算し、(B)前記乗算の結果に基づいて、各アイテムの収支を視覚化する、ゲームの評価装置。
本開示の実施例8に係るゲームの評価プログラムは、(A)マスタのパラメータに基づいて、プレイヤーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記プレイヤーが行う想定回数との乗算を計算するステップと、(B)前記乗算の結果に基づいて、各アイテムの収支を視覚化するステップと、を実行する命令をプロセッサによって実行させる、ゲームの評価プログラム。
本開示の実施例9に係るアプリの評価方法は、(A)マスタのパラメータに基づいて、ユーザーがアクションをしたときに各アイテムを取得及び消費する期待値と、前記アクションを前記ユーザーが行う想定回数との乗算を計算するステップと、(B)前記乗算の結果に基づいて、各アイテムの収支を視覚化するステップと、を実行する、アプリの評価方法。
本開示の実施例2-1に係る方法は、プレイ想定を含むマスタを入力するステップと、
前記プレイ想定に基づいて、効率が最大になるように、さらに細かいプレイ想定を強化学習で算出するステップと、
前記さらに細かいプレイ想定に基づいて、所定の期間内のステータスの平均又は獲得リソース総量の価値の平均が最大になるような最適プレイを計算するステップと、
をコンピュータで実行する方法。
本開示の実施例2-2に係る方法は、εグリーディ法を使用する、実施例2-1に記載の方法。
本開示の実施例2-3に係る方法は、前記εグリーディ法は、プレイ想定又はランダム選択に基づいて報酬を計算する、実施例2-2に記載の方法。
本開示の実施例2-4に係る方法は、前記強化学習において、Q値の更新はモンテカルロ法によって計算される、本開示の実施例2-1~2-3の1項に記載の方法。
本開示の実施例2-5に係る方法は、プレイ想定を含むマスタを入力するステップと、前記プレイ想定に基づいて、効率が最大になるように、さらに細かいプレイ想定を強化学習で算出するステップと、をコンピュータで実行する方法。
本開示の実施例2-6に係る方法は、プレイ想定を含むマスタ、及びシミュレーション回数を入力するステップと、前記マスタ及びシミュレーション回数に基づいて、最適プレイ又は総戦力値を計算するステップと、最適プレイの計算結果の統計分布を出力するステップと、をコンピュータで実行する方法。
本開示の実施例2-7に記載のプログラムは、実施例2-1~2-6に記載の方法をプロセッサで実行するための命令を含むプログラム。
本開示の実施例2-8に記載の装置は、プロセッサ、及びメモリを備え、実施例2-1~2-6の方法を実行するための装置。
本開示の実施例3-1に係る方法は、所定のパラメータ設定値に基づいて最適プレイを計算するステップと、前記最適プレイの計算の結果得られた獲得リソース量、伸長ステータス量、又は各コンテンツの獲得量を、それぞれの所定の値と比較し、その結果に基づいて、前記所定のパラメータ設定値を変更して、前記獲得リソース量、前記伸長ステータス量、又は前記各コンテンツの獲得量と前記所定の値との差が小さくなるように学習するステップと、前記差が、所定の値以下になった場合、そのときのパラメータ設定値を出力するステップと、をコンピュータによって行う方法。
本開示の実施例3-2に係る方法は、(A)最適プレイを含むマスタ、及び想定戦力値を入力するステップと、(B)前記最適プレイに基づいて、総戦力値を計算するステップと、(C)前記総戦力値に基づいて、前記マスタの値を調整するステップと、をコンピュータによって実行する方法。
本開示の実施例3-3に係る方法は、前記総戦力値が所定の値以下になるまで前記(B)ステップと前記(C)ステップを繰り返す、実施例3-2に記載の方法。
本開示の実施例3-4に係るプログラムは、実施例3-1~3-3に記載の方法をプロセッサで実行するための命令を含むプログラム。
本開示の実施例3-5に係る装置は、1つ以上のプロセッサ、及びメモリを備え、実施例3-1~3-3の方法を実行するための装置。