(57)【特許請求の範囲】
【請求項１】
複数のプレイヤーの夫々の操作を受付けてゲームを実行し得る複数の端末の夫々と通信し、前記複数のプレイヤーのうち少なくとも１人以上が参加者として参加するランキング指標を複数種類管理し、複数種類の前記ランキング指標毎に前記参加者のランキングを算出するサーバであって、
前記複数のプレイヤーのうち、処理対象として注目すべきプレイヤーを注目プレイヤーとして、前記複数種類のランキング指標のうちの少なくとも一部の夫々に対して、当該注目プレイヤーが参加した場合の順位を予想順位として算出する予想手段と、
前記予想順位に基づいて、前記注目プレイヤーに推薦すべきランキング指標を推薦ランキング指標として決定する決定手段と、
前記推薦ランキング指標を前記注目プレイヤーの端末に対して提示する提示手段と、
所定のランキング指標に対して予め定義されたスコアの算出手法に従って、当該所定のランキング指標に参加する１以上の参加者のスコアを夫々算出し、当該スコアに基づいて、当該１以上の参加者の順位を夫々特定する処理を、前記複数種類のランキング指標毎に繰り返して実行する特定手段と、
を備え、
前記予想手段は、
前記複数種類のランキング指標のうち、処理対象として注目すべきランキング指標を注目ランキング指標として、
前記注目ランキング指標における過去の所定の時間範囲の複数回のスコアのログの時系列に基づいて、予想順位の指標として想定される想定スコアを第１位乃至第ｎ位まで設定し、
前記注目ランキング指標に対して予め定義されたスコアの算出手法に従って、前記注目プレイヤーのプレイログに基づく現状スコアを算出し、
第１位乃至第ｎ位の前記想定スコアと、前記注目プレイヤーの前記現状スコアとに基づいて、前記注目プレイヤーの前記予想順位を算出する、
サーバ。
【請求項２】
前記決定手段は、前記予想順位が所定の要件を満たすランキング指標を、前記推薦ランキング指標として１以上決定し、
前記提示手段は、１以上の前記推薦ランキング指標を、前記予想順位が高い順にソートして、前記注目プレイヤーの端末に対して提示する、
請求項１に記載のサーバ。
【請求項３】
前記予想手段は、前記注目プレイヤーが過去に参加済みの前記ランキング指標のうち所定の要件を満たすものを、前記注目ランキング指標から除外する、
請求項１又は２に記載のサーバ。
【請求項４】
複数のプレイヤーの夫々の操作を受付けてゲームを実行し得る複数の端末の夫々と通信し、前記複数のプレイヤーのうち少なくとも１人以上が参加者として参加するランキング指標を複数種類管理し、複数種類の前記ランキング指標毎に前記参加者のランキングを算出するサーバを制御するコンピュータに、
前記複数のプレイヤーのうち、処理対象として注目すべきプレイヤーを注目プレイヤーとして、前記複数種類のランキング指標のうちの少なくとも一部の夫々に対して、当該注目プレイヤーが参加した場合の順位を予想順位として算出する予想ステップと、
前記予想順位に基づいて、前記注目プレイヤーに推薦すべきランキング指標を推薦ランキング指標として決定する決定ステップと、
前記推薦ランキング指標を前記注目プレイヤーの端末に対して提示する提示ステップと、
所定のランキング指標に対して予め定義されたスコアの算出手法に従って、当該所定のランキング指標に参加する１以上の参加者のスコアを夫々算出し、当該スコアに基づいて、当該１以上の参加者の順位を夫々特定する処理を、前記複数種類のランキング指標毎に繰り返して実行する特定ステップと、
を含む制御処理を実行させるプログラムであって、
前記予想ステップは、
前記複数種類のランキング指標のうち、処理対象として注目すべきランキング指標を注目ランキング指標として、
前記注目ランキング指標における過去の所定の時間範囲の複数回のスコアのログの時系列に基づいて、予想順位の指標として想定される想定スコアを第１位乃至第ｎ位まで設定し、
前記注目ランキング指標に対して予め定義されたスコアの算出手法に従って、前記注目プレイヤーのプレイログに基づく現状スコアを算出し、
第１位乃至第ｎ位の前記想定スコアと、前記注目プレイヤーの前記現状スコアとに基づいて、前記注目プレイヤーの前記予想順位を算出する、
ステップを含むプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ及びプログラムに関する。
【背景技術】
【０００２】
従来から、スマートフォン等の端末で実行可能なゲームとして、マルチバトル等複数のプレイヤーが参加可能なゲームが存在する（例えば特許文献１参照）。
このようなゲームの多くは、ランキング機能を備えている。換言すると、ランキング機能は、このようなゲームにとって、基本的でかつ本質的な機能である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−１９２１４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のゲームでは、１つのランキング指標を用いたデイリーランキングや総合ランキング等の提供に留まっている。このような従来のゲームにおけるランキングの上位者は、いわゆるヘビープレイヤーにほぼ独占されているといっても過言でない状況である。
このため、従来のゲームにおいて、ランキング機能は、大多数のカジュアルプレイヤーにとって馴染みの薄い機能となってしまっている。
このため、ランキング機能を、幅広いプレイヤーにとってのゲームの面白さに繋げるべく、各プレイヤーにランキングへの参加の動機付けを与える技術の確立が要望されている。
【０００５】
本発明は、このような状況に鑑みてなされたものであり、各プレイヤーにランキングへの参加の動機付けを与える技術を確立することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、本発明の一態様のサーバは、
複数のプレイヤーの夫々の操作を受付けてゲームを実行し得る複数の端末の夫々と通信し、前記複数のプレイヤーのうち少なくとも１人以上が参加者として参加するランキング指標を複数種類管理し、複数種類の前記ランキング指標毎に前記参加者のランキングを算出するサーバであって、
前記複数のプレイヤーのうち、処理対象として注目すべきプレイヤーを注目プレイヤーとして、前記複数種類のランキング指標のうちの少なくとも一部の夫々に対して、当該注目プレイヤーが参加した場合の順位を予想順位として算出する予想手段と、
前記予想順位に基づいて、前記注目プレイヤーに推薦すべきランキング指標を推薦ランキング指標として決定する決定手段と、
前記推薦ランキング指標を前記注目プレイヤーの端末に対して提示する提示手段と、
を備える。
【発明の効果】
【０００７】
本発明によれば、各プレイヤーにランキングへの参加の動機付けを与える技術を確立することができる。
【図面の簡単な説明】
【０００８】
【図１】本発明の一実施形態に係る情報システムの構成を示すブロック図である。
【図２】図１の情報処理システムのうち、本発明の端末の一実施形態としてのサーバのハードウェア構成を示すブロック図である。
【図３】図２のサーバの機能的構成例を示す機能ブロック図である。
【図４】プレイヤーのランキングへの参加に関するユーザインタフェースの一例を示す図である。
【図５】図３のサーバのうち参加ランキング指標ＤＢの構造例を示す図である。
【図６】一般的なログのデータベースの構造体、即ちログ構造体の例を示す図である。
【図７】図６のログ構造体のログの１つのエントリの具体例を示す図である。
【図８】プレイヤーが回復魔法や回復アイテムを用いて味方の体力を回復した場合に生成される、図６のログ構造体のログの１つのエントリの具体例を示す図である。
【図９】ランキング指標の具体的な実装例、即ちランク構造体の一例を示す図である。
【図１０】図９のランク構造体のランキング指標の１つのエントリの具体例を示す図である。
【図１１】注目プレイヤーが未参加のランキング指標を注目ランキング指標とした場合における、注目プレイヤーの予想順位の算出手法の一例を説明する図である。
【図１２】注目ランキング指標に関する過去のスコアのログの時系列情報の例を示す図である。
【図１３】ゲームのダメージ系に関するランキング指標を自動生成するためのテンプレートの一例を示す図である。
【図１４】図１３の例とは異なる応用例であって、とある特定のキャラクタを使いこなしたプレイヤーが上位にランキングされるタイプのテンプレートの一例を示す図である。
【図１５】図１３及び図１４の各例とは異なる応用例であって、ダメージ以外のスコアを用いたランキング指標を自動生成するためのテンプレートの一例を示す図である。
【図１６】図３の機能的構成を有するサーバの処理のうち、推薦ランキング処理の流れの一例を説明するフローチャートである。
【図１７】図１６の推薦ランキング処理のステップＳ１の予想順位算出処理の詳細の一例を説明するフローチャートである。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について、図面を用いて説明する。
【００１０】
なお、以下において、単に「画像」と呼ぶ場合には、「動画像」と「静止画像」との両方を含むものとする。
また、「動画像」には、次の第１処理乃至第３処理の夫々により表示される画像を含むものとする。
第１処理とは、平面画像（２Ｄ画像）におけるオブジェクト（例えばゲームキャラクタ）の夫々の動作に対して、複数枚からなる一連の静止画像を時間経過と共に連続的に切り替えて表示させる処理をいう。具体的には例えば、２次元アニメーション、いわゆるパラパラ漫画的な処理が第１処理に該当する。
第２処理とは、立体画像（３Ｄモデルの画像）におけるオブジェクト（例えばゲームキャラクタ）の夫々の動作に対応するモーションを設定しておき、時間経過と共に当該モーションを変化させて表示させる処理をいう。具体的には例えば、３次元アニメーションが第２処理に該当する。
第３処理とは、オブジェクト（例えばゲームキャラクタ）の夫々の動作に対応した映像（即ち動画）を準備しておき、時間経過と共に当該映像を流していく処理をいう。
【００１１】
図１は、本発明の一実施形態に係る情報処理システムの構成を示している。
図１に示す情報処理システムは、ｎ人（ｎは１以上の任意の整数値）のプレイヤーの夫々により使用されるプレイヤー端末１−１乃至１−ｎと、サーバ２とを含むシステムである。プレイヤー端末１−１乃至１−ｎの夫々と、サーバ２とは、インターネット等の所定のネットワークＮを介して相互に接続されている。
【００１２】
サーバ２は、プレイヤー端末１−１乃至１−ｎの夫々に対してゲームの実行環境を提供し、プレイヤー端末１−１乃至１−ｎの夫々において実行されるゲームに関する各種各様のサービスを提供する。このようなサービスの１つとして、本実施形態では、多種多様なランキング指標を用いる新たなランキング機能のサービスが採用されている。
【００１３】
なお、以下、プレイヤー端末１−１乃至１−ｎの夫々を個々に区別する必要がない場合、これらをまとめて「プレイヤー端末１」と呼ぶ。
【００１４】
図２は、図１の情報処理システムのうち、本発明の一実施形態としてのサーバ２のハードウェア構成を示すブロック図である。
【００１５】
サーバ２は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）５１と、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）５２と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）５３と、バス５４と、入出力インターフェース５５と、出力部５６と、入力部５７と、記憶部５８と、通信部５９と、ドライブ６０と、を備えている。
【００１６】
ＣＰＵ５１は、ＲＯＭ５２に記録されているプログラム、又は、記憶部５８からＲＡＭ５３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ５３には、ＣＰＵ５１が各種の処理を実行する上において必要なデータ等も適宜記憶される。
【００１７】
ＣＰＵ５１、ＲＯＭ５２及びＲＡＭ５３は、バス５４を介して相互に接続されている。このバス５４にはまた、入出力インターフェース５５も接続されている。入出力インターフェース５５には、出力部５６、入力部５７、記憶部５８、通信部５９及びドライブ６０が接続されている。
【００１８】
出力部５６は、ディスプレイやスピーカ等で構成され、各種情報を画像や音声として出力する。
入力部５７は、キーボードやマウス等で構成され、各種情報を入力する。
記憶部５８は、ハードディスクやＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部５９は、インターネットを含むネットワークＮを介して他の装置（図１の例ではプレイヤー端末１）との間で行う通信を制御する。
【００１９】
ドライブ６０は、必要に応じて設けられる。ドライブ６０には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア７１が適宜装着される。ドライブ６０によってリムーバブルメディア７１から読み出されたプログラムは、必要に応じて記憶部５８にインストールされる。また、リムーバブルメディア７１は、記憶部５８に記憶されている各種データも、記憶部５８と同様に記憶することができる。
【００２０】
このような図２のサーバ２側の各種ハードウェアと各種ソフトウェアとの協働により、プレイヤー端末１でのゲームの実行の管理や支援が可能になる。
本実施形態では、マルチバトル等の複数のプレイヤーが参加するゲームが対象である。
【００２１】
対象となるゲームでは、多種多様なランキング指標を用いるランキング機能が提供される。
そこで、サーバ２は、多種多様なランキング指標の中から、プレイヤーのプレイスタイルに適合するものを推薦対象として決定して、適合する順にソートした上で、当該プレイヤーのプレイヤー端末１に提示する。これにより、多数のカジュアルプレイヤーにランキングへの参加を動機付けることが可能になる。
【００２２】
ここで、本実施形態のゲームにおける、プレイヤーとランキング指標の関係の前提事項について説明する。
【００２３】
先ず、１つ目の前提事項は、本実施形態ではオプトイン方式が採用されていることである。
即ち、従来においては、オプトアウト方式が採用されていた。換言すると、従来においては、ランキング指標の種類数は１つか少数であった。このため、自動的に参加対象のランキング指標が決定され、当該ランキング指標におけるランキングが自動的に集計され、そのランキングにプレイヤー本人のデータが表示されるか否かのみが制御可能であった。
これに対して、本実施形態のゲームでは、ランキング指標の種類数ｍは数百から数千にも上る。プレイヤーは、このような多種多様なｍ種のランキング指標の全てに参加することは現実的でなく、幾つかのランキング指標に絞って参加することになる。
この場合、プレイヤーが参加するランキング指標の決定方式は、本実施形態では、自動的に参加対象のランキング指標が決定される手法ではなく、プレイヤーの意思で所望のランキング指標を参加対象として決定する方式、即ちオプトイン方式が採用されている。
【００２４】
２つ目の前提事項は、本実施形態では１人のプレイヤーが一度に参加可能なランキング指標の上限数が規定されていることである。
これにより、ある特定のランキング指標のみに参加者数が偏ってしまうことを防止することができる。また、とあるランキング指標の参加者数を容易に見積もることも可能である。
【００２５】
３つ目の前提事項は、本実施形態のランキング指標は、既存の種類が用いられる他、新たな種類が自動的に生成され得ることである。
つまり、上述したように、本実施形態では、ランキング指標の種類数ｍは数百から数千と膨大な数に上る。しかしながら、このような多種多様なｍ種類のランキング指標の全てを人手で設定することは現実的ではない。
そこで、本実施形態のサーバ２は、既存のゲームデーからランキング指標を自動生成する機能を有している。なお、ランキング指標の自動生成の手法については、後述する。
【００２６】
このような前提の下、サーバ２は、ｎ人のプレイヤー（例えばｎ＝５００万以上）と、ｍ種類のランキング指標（例えばｍ＝数百から数千）との、ｎ×ｍ通りの組合せにおける適合性（ｒｅｌｅｖａｎｃｅ）を算出する。そして、サーバ２は、ｎ人のプレイヤーの夫々に対して、適合性の高い順にランキング指標をソートして、そのソート結果を、夫々のプレイヤー端末１−１乃至１−ｎに提示する。また、サーバ２は、適合性の高いもののうち上位の幾つかのランキング指標を推薦対象として、夫々のプレイヤー端末１−１乃至１−ｎに提示する。
これにより、ｎ人のプレイヤーの夫々は、ランキング指標群の全容を把握せずとも、自身のプレイスタイルに適合したランキング指標を参加対象として容易に決定することができる。
【００２７】
つまり、従来のソーシャルゲーム等におけるランキング機能は、自動推薦機能を有していない。このため、１件から数件のごく少数の予め決められたランキング指標を用いたランキング、例えばデイリーランキングや総合ランキングのみが提供さている。
これに対して、本実施形態では、多種多様なｍ種類のランキング指標を用いたランキングが提供される。
そこで、本実施形態では、所定のランキング指標がプレイヤーのプレイスタイルにどの程度適合しているのかを示す度合として、ランキング指標に現在参加していないプレイヤーが、当該ランキング指標に参加した場合の予想順位を採用する。
つまり、サーバ２は、とあるランキング指標に現在参加していないプレイヤーが、当該ランキングに参加した場合の予想順位を算出する。
そして、サーバ２は、この予想順位が小さい順（上位の順）、換言するとプレイヤーが参加した場合により上位にランクインする可能性が高い順に、多種多様なランキング指標をソートする。サーバ２は、そのソート結果に基づいて、例えば上からｋ件（ｋ＝５等の任意の整数値）のランキング指標を、例えば「おまかせ選択」されたランキング指標としてプレイヤーに自動推薦する。つまり、当該プレイヤーのプレイヤー端末１には「おまかせ選択」されたランキング指標が提示される。
従って、当該プレイヤーは、膨大なｍ種類のランキング指標の全てを確認せずとも、自らが競争力を持つ（つまり上位を狙えそうな）ランキング指標を参加対象とすることが容易に可能となる。これにより、多数のカジュアルプレイヤーにランキングへの参加を動機付けることが可能になる。
【００２８】
なお、このようなサーバ２の一連の処理、即ち、ランキング指標とプレイヤーの適合性（各ランキング指標の予想順位）を算出して、その算出結果に基づいて、ランキング指標をソートした上で、所定種類のランキング指標を推薦対象として当該プレイヤーに提示するまでの処理を、以下、「推薦ランキング指標提示処理」と呼ぶ。
図３は、サーバ２の機能的構成のうち、推薦ランキング指標提示処理の実行時の機能的構成を示す機能ブロック図である。
【００２９】
図３に示すように、サーバ２のＣＰＵ５１においては、ランキング参加管理部１０１と、時間管理部１０２と、ランキング順位特定部１０３と、ランキング指標推薦部１０４と、推薦結果提示部１０５と、ランキング指標生成部１０６とが機能する。
サーバ２の記憶部５８の一領域には、参加ランキング指標ＤＢ１２１と、全プレイヤーログＤＢ１２２と、ランキング結果ＤＢ１２３と、スコアＤＢ１２４と、ランキング指標ＤＢ１２５とが設けられる。
【００３０】
ランキング参加管理部１０１は、プレイヤー端末１のプレイヤーのランキング指標への参加状況を管理する。
例えば、ランキング参加管理部１０１は、図４に示す様なユーザインタフェース、即ちプレイヤーのランキング手法への参加に関するユーザインタフェースを、当該プレイヤーのプレイヤー端末１に表示させる制御を実行する。
【００３１】
図４（Ａ）は、所定の観点でソートされたランキング指標の中からプレイヤーが参加するものを選択するためのユーザインタフェース２０１を示している。
ユーザインタフェース２０１には、ランキング指標をソートするための「観点」を選択する部として、選択操作部２１１が設けられている。図４（Ａ）の例では、「可能性が高い順」が選択されているので、複数種のランキング指標が、（プレイヤーがランクインする）可能性が高い順にソートされる。
ここで、（プレイヤーがランクインする）可能性が高い順にソートする処理は、後述するランキング指標推薦部１０４（図３）により実行される。即ち、詳細については後述するため簡単に記載するが、ランキング指標推薦部１０４は、とあるプレイヤー（後述する注目プレイヤー）がとあるランキング指標（後述する注目ランキング指標）に参加した場合の予想順位を算出する。ここで、予想順位が上位（低い値）であることは、（プレイヤーがランクインする）可能性が高いことを意味する。そこで、ランキング指標推薦部１０４は、予想順位が上位になる順（低い値になる順）、換言すると、（プレイヤーがランクインする）可能性が高い順に、ランキング指標をソートする。
このようなランキング指標推薦部１０４によるソート結果は、ランキング指標表示領域２１２に表示される。
ただし、多種多様なｍ種類のランキング指標を一画面に表示することは困難である。そこで、ランキング指標表示領域２１２には、所定種類数（図４（Ａ）の例では２０種類）のランキング指標が、選択操作部２１１により選択された観点でソートされた順番でリスト表示される。即ち、図４（Ａ）の例では、（プレイヤーがランクインする）可能性が高い順にソートされたｍ種類のランキング指標のうち、上位２０種類のランキング指標（アイコン）が、ソート順に表示される。
なお、より正確には、後述するようにｍ種類のランキング指標の全てがソート対象になる必要は特にない。ただし、ここでは説明の便宜上、ｍ種類のランキング指標の全てがソート対象になるとしている。
このように、ランキング指標表示領域２１２は、ｍ種類のうち２０種類程度の限定された種類のランキング指標しか一度に表示できない。そこで、ランキング指標表示領域２１２の表示対象を変更させる操作部２１３も設けられている。
また、プレイヤーが所定のキーワードを入力して所望のランキング指標を検索できるように、キーワード検索を行うための操作部２１４も設けられている。
【００３２】
図４（Ｂ）は、プレイヤーが参加するランキング指標を確定すると共に、当該ランキング指標の説明を表示するユーザインタフェース２０２を示している。
上述したように、本実施形態では、プレイヤーが参加するランキング指標を自己の意思で決定するオプトイン方式が採用されており、プレイヤーが参加可能なランキング指標の上限数も規定されている。
そこで、プレイヤーは、図４（Ｂ）のユーザインタフェース２０２を用いて、自己が参加するランキング指標として所望のものを例えば３種類決定することができる。具体的には、プレイヤーは、ランキング参加登録のボタン２２１を押下操作する。これにより、当該ランキング指標へのプレイヤーの参加が確定する。
この場合、プレイヤーが参加するランキング指標の説明画像２２２，２２３，２２４は、ユーザインタフェース２０２内に表示される。
なお、各ランキング指標には固有の集計期間があるため、一度所定のランキング指標に参加した場合、当該ランキング指標の集計期間（例えば、２４時間や、１か月）に応じて、当該ランキング手法への登録の解除が不可能になる実装が好ましい。
【００３３】
ここで、説明画像２２２，２２３，２２４の夫々が示す３種類のランキング指標は、図４（Ａ）のユーザインタフェース２０１のランキング指標表示領域２１２からプレイヤーにより選択されたものでもよいし、図４（Ｂ）のおまかせ選択のボタン２２６の押下の結果としてサーバ２により自動選択されたものでもよい。
後者のおまかせ選択のボタン２２６が押下されると、上述した推薦ランキング指標提示処理が実行されて、プレイヤーに適合するランキング指標のうち、例えば上位３種類のランキング指標、即ちプレイヤーが上位入賞する可能性の高い３種類のランキング指標が推薦され、夫々の説明を示す説明画像２２２，２２３，２２４がユーザインタフェース２０１に自動的に表示される。
これにより、プレイヤーは、膨大な種類数ｍのランキング指標の全てを確認せずとも、自らが競争力を持つランキング指標を容易に見つけ出すことが可能となる。
【００３４】
説明画像２２２、２２３、及び２２４の夫々は、ランキング指標毎に、期間、ランキング条件、及び現在の順位を含む画像となっている。
例えば説明画像２２２は、Ｄａｉｌｙランキングの説明を示す画像であり、「Ｄａｉｌｙ  水属性武器の使い手（水属性の武器／アビリティで与えたダメージ数の累計でランキング）  ２７位」という説明内容が含まれている。つまり、説明画像２２２で説明するランキング指標は、２４時間以内にプレイヤーが水属性の武器とアビリティで与えたダメージの累計をスコアとして、順位が算出されるものである。
ここで、ボーナス説明画像２２５は、当該ランキング指標を参加対象とした場合に獲得できるボーナスの内容を説明する画像である。
つまり、プレイヤーは、図４のユーザインタフェースを用いることで、自分が入賞する可能性が高いランキング指標を参加対象として登録して、ボーナスを獲得しながらゲームをプレイすることができる。このようにランキングの順位に応じてボーナスを付与することにより、プレイヤーのモチベーションを向上させることが出来る。
【００３５】
以上まとめると、本実施形態のサーバ２は、従来よりも圧倒的に多いｍ種類のランキング指標を各プレイヤーに提供し、かつ、これらのランキング指標のうち、各プレイヤーのプレイスタイルに適合したランキング指標への参加をプレイヤーに強く動機付けることが可能になる。
つまり、従来よりも圧倒的多数のｍ種類のランキング指標をプレイヤーに提供することで、カジュアルプレイヤーであっても自らのプレイスタイルに応じて上位入賞を狙えるランキング指標、即ち、各プレイヤーのプレイスタイルに適合したランキング指標を用意することができる。
ただし、各プレイヤーが、自らのプレイスタイルに適合したランキング指標を、従来よりも圧倒的多数のｍ種類のランキング指標の中から闇雲に見つけ出すことは非常に困難である。
そこで、本実施形態のサーバ２は、プレイヤーのプレイスタイルに適合する順番、換言すると、そのようなプレイスタイルを持ったプレイヤーが参加すればランキング（順位）が上位になると期待される順番で、例えばｍ種類のランキング指標をソートする。なお、後述するように、ソート対象は必ずしもｍ種類である必要はない。
このソート結果が、図４（Ａ）のユーザインタフェース２０１によりプレイヤーに提示される。従って、プレイヤーは、多種多様なｍ種類のランキング指標の中から、自らのプレイスタイルに応じて、上位入賞を期待できるランキング指標を容易かつ即座に見つけ出すことができる。
さらに、プレイヤーが図４（Ｂ）のおまかせ選択のボタン２２６を押下するだけで、多種多様なｍ種類のランキング指標のうち、当該プレイヤーのプレイスタイルに適合する幾つかのランキング指標、換言すると、そのようなプレイスタイルを持ったプレイヤーが参加すればランキング（順位）が上位になると期待される幾つかのランキング指標が、自動的に推薦される。
このようにして、各プレイヤーは、多種多様なｍ種類のランキング指標の中から、自らのプレイスタイルに応じて、上位入賞を期待できるランキング指標を容易かつ即座に選択することができるようになる。これにより、多数のカジュアルプレイヤーにランキングへの参加を動機付けることが可能になる。
【００３６】
図３に戻り、参加ランキング指標ＤＢ１２１は、プレイヤー端末１−１乃至１−ｎの夫々の各プレイヤーと、参加対象のランキング指標とを対応付けて記憶する。
図５は、参加ランキング指標ＤＢ１２１の構造例を示している。
図５の参加ランキング指標ＤＢ１２１において、Ｕｓｅｒ  ＩＤは、各プレイヤーを一意に識別可能なＩＤである。Ｒａｎｋｉｎｇ  Ｃｒｉｔｅｒｉａ  ＩＤは、各ランキング指標を一意に識別可能なＩＤである。Ｕｓｅｒ  ＩＤとＲａｎｋｉｎｇ  Ｃｒｉｔｅｒｉａ  ＩＤとを同一行にて対応付けることにより、１のプレイヤーと、当該プレイヤーが参するランキング指標との関連性の管理を行うことが可能になる。
所定行のＢｅｇｉｎは、当該行のプレイヤーについての当該行のランキング指標のランキングに関するスコアの収集開始時間を示している。当該行のＥｎｄは、その収集終了時間である。このＢｅｇｉｎとＥｎｄの夫々の値が示す時間内のプレイログから、当該行のランキング指標における当該行のプレイヤーのスコアが算出される。なお、詳細については後述するが、所定のランキング指標におけるプレイヤーのスコアは、当該ランキング指標における当該プレイヤーの順位を決定するために用いられる。
【００３７】
図３に戻り、時間管理部１０２は、各ランキング指標毎の順位決定に必要なスコアの集計頻度を制御する。
例えば、ランキングの途中経過をプレイヤーに伝えるべく、Ｄａｉｌｙランキングであっても、１日に数回、ランキングを更新すると好適である。そこで、時間管理部１０２は、一定時間毎に、具体的には例えばＤａｉｌｙランキングであれば４時間に１度等の頻度で、後述のランキング順位特定部１０３を起動させる。つまり、ランキング順位特定部１０３は、時間管理部１０２の管理に基づいて、一定時間毎に起動して、スコアを集計する等の処理（詳細な処理は後述する）を実行する。
なお、図３には図示していないが、時間管理部１０２により管理される集計頻度については、ランキング参加管理部１０１を介してプレイヤー端末１に対して例えば「次の更新まで：あと２時間」等と表示させることにより、プレイヤーに通知してもよい。
ここで、時間管理部１０２は必須な構成要素ではなく、ランキング順位特定部１０３はランキング集計をリアルタイムに実行してもよい。しかしながら、本実施形態のように時間管理部１０２を設け、ランキング集計をリアルタイムに行わず、一定時間毎にに更新するようにすることで、ランキングの集計がサーバ２のシステムへ与える負荷を低減することが可能になる。
【００３８】
ランキング順位特定部１０３は、参加ランキング指標ＤＢ１２１を参照し、処理対象として注目すべきプレイヤー（以下、「注目プレイヤー」と呼ぶ）が参加するランキング指標の夫々について、スコアを算出し、当該スコアに基づいて順位を特定する。
具体的には例えば、ランキング順位特定部１０３は、全プレイヤーログＤＢ１２２から注目プレイヤーのプレイログを抽出する。
ランキング順位特定部１０３は、注目プレイヤー」と呼ぶ）が参加するランキング指標の夫々を順次、処理対象として注目すべきランキング指標（以下、「注目ランキング指標」と呼ぶ）に設定し、次のような一連の処理を各ランキング指標毎に繰り返し実行する。
ランキング順位特定部１０３は、注目ランキング指標の集計手法を、ランキング指標ＤＢ１２５から獲得する。
ランキング順位特定部１０３は、獲得したスコアの集計手法に従って、注目プレイヤーのプレイログから、注目ランキング指標についての注目プレイヤーのスコアを算出する。算出されたスコアは、スコアＤＢ１２４に格納される。
そして、ランキング順位特定部１０３は、当該スコアに基づいて、注目ランキング指標についての注目プレイヤーの順位を特定する。
【００３９】
つまり、注目プレイヤーとしてプレイヤー端末１−１乃至１−ｎの各プレイヤーの夫々を順次設定し、注目プレイヤーが参加する１以上のランキング指標の夫々を順次注目ランキング指標に設定することで、各プレイヤー毎に、夫々が参加する１以上のランキング指標についての各スコアと各順位が夫々算出される。
【００４０】
全プレイヤーログＤＢ１２２は、プレイヤー端末１−１乃至１−ｎの各プレイヤー毎に、ゲーム中のプレイログ、例えばゲーム内のアイテムの使用履歴や戦闘履歴等、ランキングに関連する全ての活動のログを格納する。なお、全プレイヤーログＤＢ１２２の具体的な構造例については、図６乃至図８を参照して後述する。
ランキング指標ＤＢ１２５は、ｍ種類のランキング指標毎に、スコアの集計手法等の各種情報を格納する。なお、ランキング指標ＤＢ１２５の具体的な構造例については、図９及び図１０を参照して後述する。
【００４１】
ランキング結果ＤＢ１２３は、ランキング順位特定部１０３によるランキング集計の途中計算結果を保存するためのキャッシュデータベースである。
即ち本実施形態では、全プレイヤーログＤＢ１２２は多数のプレイログを含む大きなデータベースとなるため、ランキング集計を都度行うことは現実的ではない。そこで、一定期間毎のランキングの途中集計結果がランキング結果ＤＢ１２３に格納される。ランキング順位特定部１０３は、スコア集計をする際に、前回の集計結果をランキング結果ＤＢ１２３から抽出し、当該前回のスコア集計結果に対する差分値のみを加算することで、今回のスコア集計結果を算出する。
【００４２】
これにより、スコア集計の負荷を大きく低減することができる。
具体的には例えば、１分間に１０万件のプレイログを集計する必要があるときに、ランキング結果ＤＢ１２３を設けずに途中結果をキャッシュしないと仮定すると、時間に比例して集計コストが増大するため、２４時間後には、８６億４千万件のプレイログを、一度に集計しなければならない。
これに対して、ランキング結果ＤＢ１２３を有する本実施形態では、例えば１時間に１度の途中計算結果をキャッシュし再利用することとした場合、３億６千万件のプレイログの集計を２４時間で２４回行うだけで済む。
【００４３】
ランキング指標推薦部１０４は、予想順位算出部１１１と、推薦ランキング指標決定部１１２とを含む。
予想順位算出部１１１は、注目プレイヤーとして、ｍ種類のランキング指標のうちの少なくとも一部の夫々に対して、当該注目プレイヤーが参加した場合の順位を予想順位として算出する。
推薦ランキング指標決定部１１２は、各ランキング指標の予想順位に基づいて、各ランキング指標をソートした上で、注目プレイヤーに推薦すべきランキング指標を推薦ランキング指標として決定する。
【００４４】
推薦結果提示部１０５は、各ランキング指標のソート結果や、推薦ランキング指標を注目プレイヤーのプレイヤー端末１に対して提示する。
なお、各ランキング指標のソート結果や推薦ランキング指標の提示タイミングや提示手法は特に限定されない。
本実施形態では、例えば上述の図４（Ａ）のユーザインタフェース２０１において、選択操作部２１１により「可能性が高い順」が選択されたタイミングで、各ランキング指標のソート結果がランキング指標表示領域２１２に表示される。
また例えば、図４のおまかせ選択のボタン２２６が押下されたタイミングで、推薦ランキング指標の説明内容が、説明画像２２２，２２３，２２４として表示される。
【００４５】
さらに以下、ランキング順位特定部１０３、ランキング指標推薦部１０４、及び推薦結果提示部１０５について詳細に説明する。
【００４６】
上述したように、ランキング順位特定部１０３は、所定のランキング指標に対して予め定義されたスコアの算出手法（スコアの集計手法）に従って、当該所定のランキング指標に参加する１以上の参加者のスコアを夫々算出し、当該スコアに基づいて、当該１以上の参加者の順位を夫々特定する処理を、ｍ種類のランキング指標毎に繰り返して実行する。
このとき算出された各参加者のスコアは、スコアＤＢ１２４に格納される。
即ち、スコアＤＢ１２４は、ｍ種類のランキング指標毎に、過去の参加者によるスコアの履歴を格納する。
【００４７】
そこで、予想順位算出部１１１は、ｍ種類のランキング指標のうち少なくとも一部の夫々を、注目ランキング指標として順次設定し、次のような一連の処理を繰り返し実行する。
即ち、予想順位算出部１１１は、注目ランキング指標における過去の複数回のスコアに基づいて、予想順位の指標として想定される想定スコアを第１位乃至第ｎ位まで設定する。
予想順位算出部１１１は、注目ランキング指標に対して予め定義されたスコアの算出手法（スコアの集計手法）に従って、注目プレイヤーの現状スコアを算出する。
予想順位算出部１１１は、第１位乃至第ｎ位の想定スコアと、注目プレイヤーの現状スコアとに基づいて、注目プレイヤーの予想順位を算出する。
さらに以下、本段落に記載の注目プレイヤーの予想順位の算出手法について、図６乃至図１２を参照して具体的に説明する。
【００４８】
上述したランキング指標推薦部１０４と推薦結果提示部１０５の特徴は、注目プレイヤーのプレイスタイルと各ランキング指標との適合性を、注目プレイヤーの予想順位という観点で自動的に計算する点である。つまり、注目プレイヤーの予想順位が上位になるランキング指標ほど、当該注目プレイヤーのプレイスタイルとの適合性がよいということになる。
この点を前提として、ランキングの基礎となるデータであるプレイログとランキング指標との関係について述べる。
【００４９】
図６は、一般的なログのデータベースの構造体（以下、「ログ構造体」と呼ぶ）の例を示している。
図６に示すログ構造体は、全プレイヤーログＤＢ１２２（図３）の１つのエントリに対応するデータ構造である。
つまり、全プレイヤーログＤＢ１２２は、図６のログ構造体のログの集合として定義することができる。
図６に示すログ構造体は、ｅｖｅｎｔ＿ｔｙｐｅ、ｔｉｍｅｓｔａｍｐ、及びｃｏｎｔｅｎｔｓの３要素から構成される。ｅｖｅｎｔ＿ｔｙｐｅは、ログが記録するイベントの種類を示す文字列である。ｔｉｍｅｓｔａｍｐは、ログに対応するイベントが発生した時刻を示すタイムスタンプである。ｃｏｎｔｅｎｔｓは、ログ情報の内容を定義したサブ構造体である。ログ情報の内容は、ｋｅｙとｖａｌｕｅとの組の配列として定義される。
【００５０】
図７は、図６のログ構造体のログの１つのエントリの具体例を示している。
図７の例では、ｅｖｅｎｔ＿ｔｙｐｅ（イベントの種類）がｂａｔｔｌｅＡｔｔａｃｋとされている。ｔｉｍｅｓｔａｍｐ（ログに対応するイベントが発生した時間）は、２０１５／０２／０２  ２１：３６：５９：２３と定義されている。
また、当該イベントの内容については、サブ構造体ｃｏｎｔｅｎｔｓの属性として、次のように定義されている。即ち、ｃｈａｒａｃｔｅｒがプレイヤキャラ１と、ｃｈａｒａｃｔｅｒＡｔｔｒｉｂｕｔｅが水属性と、ｔａｒｇｅｔＥｎｅｍｙが敵モンスター２と、与えたｄａｍａｇｅが２１００と、夫々定義されている。
【００５１】
サブ構造体ｃｏｎｔｅｎｔｓが内包する属性は、ログ構造体のｅｖｅｎｔ＿ｔｙｐｅの属性の値に応じて変化する。
図８は、プレイヤーが回復魔法や回復アイテムを用いて味方の体力を回復した場合に生成される、図６のログ構造体のログの１つのエントリの具体例を示している。
図８の例では、ｅｖｅｎｔ＿ｔｙｐｅ（イベントの種類）がｂａｔｔｌｅＨｅａｌとされている。ｔｉｍｅｓｔａｍｐ（ログに対応するイベントが発生した時間）は、２０１５／０２／０２  ２１：３７：１１：４３と定義されている。
また、当該イベントの内容については、サブ構造体ｃｏｎｔｅｎｔｓの属性として、次のように定義されている。即ち、ｃｈａｒａｃｔｅｒがプレイヤキャラ２と、ｃｈａｒａｃｔｅｒＡｔｔｒｉｂｕｔｅが光属性と、ｔａｒｇｅｔがプレイヤキャラクタ４と、ｍｅｔｈｏｄが回復魔法と、回復量のｈｅａｌが１０００と、夫々定義されている。
【００５２】
以上、図６乃至図８に示すログ構造体のＩｎｖｅｎｔｉｏｎ  Ｐｒｏｐｏｓａｌでは、ｅｖｅｎｔ＿ｔｙｐｅの文字列を用いて構造を識別可能な柔軟な構造体として、ログ情報を定義する例を示した。
これとは異なる実装として、予めすべての属性を列挙し、リレーショナルデータベースのテーブル属性と対応付ける実装方法でもよい。
【００５３】
このようなログ構造を採用することで、ランキングの集計は、ゲームサービスを提供するサーバ２側のデータベース（図３の全プレイヤーログＤＢ１２２）に蓄積されたログから、集計対象となるエントリを抽出する操作として実装することができる。
具体的な実装例として、次に示すように、３つの情報からなるデータ構造として、ランキング指標を定義することができる。
ランキング指標＝｛集計期間、対象スコア、ボーナス情報｝
集計期間は、ＤａｉｌｙやＭｏｎｔｈｌｙ、Ｔｏｔａｌ（全期間の累計）といった期間を示すデータである。
対象スコアは、例えば、「水属性の武器／アビリティで与えたダメージ数」のように、集計の対象となるスコアを示すデータである。
ボーナス情報は、当該ランキングの上位入賞した場合に（例えば、上位３位以内にランクする等）、プレイヤーへ与えられるボーナスを示すデータである。例えば、「戦闘開始時に回復アイテムＡを１つ獲得」といったボーナスが考えられる。
つまり、上述のランキング指標に対して予め定義されたスコアの算出手法（スコアの集計手法）とは、これら３つの情報を用いた算出手法をいう。
【００５４】
図９は、ランキング指標の具体的な実装例、即ちランキング指標を定義する構造体（以下、「ランク構造体」と呼ぶ）の一例を示している。
即ち、ランキング指標は、図９に示すランク構造体として定義することができる。
図９の例では、ランキング指標を構成する３つの情報のうち、集計期間は、ｄｕｒａｔｉｏｎ＿ｂｅｇｉｎと、ｄｕｒａｔｉｏｎ＿ｅｎｄとして表現される。ｄｕｒａｔｉｏｎ＿ｂｅｇｉｎは、対象の集計期間の開始時刻を示す６４ビット整数である。ｄｕｒａｔｉｏｎ＿ｅｎｄは、対象の集計期間の終了時刻を示す６４ビット整数である。
また、ランキング指標を構成する３つの情報のうち対象スコアについては、ｔａｒｇｅｔｓとｑｕｅｒｙとにより定義される。即ち、集計の対象とする属性は、図６乃至図８を例として上述したログの構造体内の属性名の配列として定義される。ここで、図９のランク構造体の大きな特徴は、集計の対象とするログの条件を、一般に、ｋｅｙ−ｖａｌｕｅ  ｐａｉｒとして知られる、属性名（ｋｅｙ）と値（ｖａｌｕｅ）との対を用いて指定する点にある。このｋｅｙ−ｖａｌｕｅ  ｐａｉｒを定義するサブ構造体が、ｑｕｅｒｙ構造体である。
【００５５】
具体的には例えば、「水属性の武器／アビリティで与えたダメージ数」を集計する場合には、「水属性の武器／アビリティ」が条件となるため、図１０に示すように定義されたｑｕｅｒｙ構造体を有するランク構造体のランキング指標が用いられる。
図１０は、図９のランク構造体のランキング指標の１つのエントリの具体例を示している。
図１０の例では、ｑｕｅｒｙ構造体において、ｅｖｅｎｔ＿ｔｙｐｅ＝ｂａｔｔｌｅＡｔｔａｃｋが、戦闘時のログを対象として集計することを指定している。また、ｃｈａｒａｃｔｅｒＡｔｔｒｉｂｕｔｅ＝水属性が、水属性の武器やアビリティを用いて行われた操作であることを指定している。また、ｔａｒｇｅｔｓ：｛ｄａｍａｇｅ｝という指定により、集計対象を、上述の条件下において、敵に与えたダメージ値としている。
このような図１０のランク構造のランキング指標を用いることにより、ランキング順位特定部１０３や予想順位算出部１１１は、当該ランキング指標のスコアを演算するに際し、全プレイヤーログＤＢ１２２（図３）に蓄積されたプレイログの中から「水属性の武器／アビリティで与えたダメージ数」のみを集計することが可能になる。
【００５６】
ランキング指標推薦部１０４の予想順位算出部１１１は、上述の図６乃至図８に示すログ構造体のプレイログを有する注目プレイヤーが、図９及び図１０に示すランク構造体の注目ランキング指標に参加した場合に、獲得することが予想される順位、即ち予想順位を算出する。
予想順位算出部１１１は、ｍ種類のランキング指標のうち少なくとも一部の夫々を、注目ランキング指標として順次設定し、このような処理を繰り返すことで、注目プレイヤーについての、ｍ種類のランキング指標のうち少なくとも一部の夫々の予想順位を算出する。
【００５７】
そこで、推薦ランキング指標決定部１１２は、例えば予想順位の高い順、即ち、より上位にランクインする可能性が高い順にランキング指標をソートし、そのソート結果に基づいて、注目プレイヤーに対する推薦ランキング指標を決定する。
【００５８】
図１１は、注目プレイヤー（プレイヤーＡ）が未参加のランキング指標を注目ランキング指標とした場合における、注目プレイヤーの予想順位の算出手法の一例を説明する図である。
【００５９】
図１１（Ａ）は、注目ランキング指標についての、予想順位の算出時点（以下、「現在」と呼ぶ）のランキング参加者のスコアの時間的な推移を示している。
図１１（Ａ）に示す様に、注目ランキング指標において、所定順位（例えば第１位）を獲得するために必要なスコアの値は、集計時期に応じて変化するものである。そのため、当該注目ランキング指標の中で、特定のプレイヤーが獲得し得る順位を推定するためには、第１位から第ｎ位までの各順位を獲得するために必要なスコアを見積もる必要がある。
この見積りの算出手法は、過去のスコアのログの時系列を用いる手法であれば特に限定されないが、本実施形態では、過去の所定の時間範囲における、各順位に対応するスコアのログの中央値を算出する手法が採用されている。
【００６０】
過去の所定の時間範囲における、各順位（当該順位を獲得するプレイヤー）のスコアのログは、例えば図１２に示す様な構造でスコアＤＢ１２４（図３）に格納されている。
図１２は、注目ランキング指標に関する過去のスコアのログの時系列情報の例を示している。
【００６１】
予想順位算出部１１１は、図１１（Ｂ）に示す様に、注目ランキング指標への過去の参加者によるスコアの履歴から、第１位から第ｎ位までの夫々の中央値を算出する。
具体的には例えば、予想順位算出部１１１は、スコアＤＢ１２４から図１２に示す各順位のスコアのログの時系列情報を、図１１（Ｂ）に示す各順位の中央値の配列へ変換する処理を実行する。なお、以下、この中央値の配列を「想定スコアｐ」と呼ぶ。
【００６２】
次に、予想順位算出部１１１は、全プレイヤーログＤＢ１２２から注目プレイヤー（図１１の例ではプレイヤーＡ）のプレイログを抽出し、当該プレイログから、注目ランキング指標に対応するスコアを算出する。
スコアの算出手法は、ランキング順位特定部１０３における算出手法と同様であり、本実施形態では上述した様に、図６乃至図８に示すログ構造体のプレイログを用いて、図９及び図１０に示すランク構造体の注目ランキング指標に対応するスコアを算出する手法が採用されている。
なお、このようにして算出された注目プレイヤーについての注目ランキング指標に対応するスコアを、以下、「現状スコアｃ」と呼ぶ。
【００６３】
そして、予想順位算出部１１１は、第１位乃至第ｎ位の想定スコアｐ（図１１（Ｂ）参照）と、注目プレイヤーの現状スコアｃ（図１１の例ではプレイヤーＡのスコアα）との大小関係を比較する。
予想順位算出部１１１は、想定スコアｐよりも現状スコアｃのほうが大きく、かつ、想定スコアｐと現状スコアｃの差分が最小（ｃ＞ｐ  ∧  ＭＩＮ（ｃ−ｐ））となる順位を、注目プレイヤーの予想順位として算出する。
【００６４】
以上のような予想順位算出部１１１の一連の処理は、ｍ種類のランキング指標のうち少なくとも一部の夫々が、注目ランキング指標として順次設定される毎に実行される。
これにより、ｍ種類のランキング指標のうち少なくとも一部の夫々について、注目プレイヤーの各予想順位が算出される。
ここで、「ｍ種類のランキング指標のうち少なくとも一部の夫々」とは、例えば、注目プレイヤーに対する推薦ランキング指標の候補として既に第１位を獲得したことがあるランキング指標を除外して、当該注目プレイヤーにとって常に新しいランキング指標を推薦ランキング指標として提示することを可能にする意である。
つまり、ｍ種類のランキング指標の全ての予想順位を算出する必要は特になく、例えば既に第１位を獲得したことがあるランキング指標については予想順位の算出対象から除外するようにしてもよい。
【００６５】
推薦ランキング指標決定部１１２は、予想順位が小さい順（上位になる順）にソートし、そのソート結果に基づいて推薦ランキング指標を決定する。
【００６６】
以上説明したように、本実施形態のサーバ２は、推薦ランキング指標の決定処理を伴う、多種多様なｍ種類のランキング指標を用いたランキング機能を発揮するための処理を実行する。
このため、サーバ２の運用時の負荷を考慮したシステム設計が必要になる。
この点、本実施形態のサーバ２における、１つ１つのランキング指標の計算コストは、従来のランキング機能を搭載する従来のサーバ等と比較して遥かに少ない、という特徴がある。
この特徴を有する要因は、ランキング指標の種類数ｍが非常に多く、かつ、プレイヤー毎に異なるランキング指標を推薦ランキング指標として提示する必要があるため、１つのランキング指標の参加者数は、従来の総合ランキングと比較して少なくなることである。
このような特徴により、とあるランキング指標に関する演算を行うとき、参照すべきデータベースの数が少なくなるため、分散データベース環境におけるログ集計の負荷を大きく減少させることが可能になる。
【００６７】
具体的なログの集計コストの例としては次の通りである。
即ち、例えば、プレイヤーのアクティブ数が１００万人であるとして、１人のプレイヤーが５つのランキング指標に参加している状況において、１時間毎にデイリーランキングを更新するときのコストを考える。
各プレイヤーの夫々が１時間に平均して１００件のログを残すと仮定する。
この場合のログの集計コストは、１００（ログ件数）×５（ランキング参加数）×１００万人（プレイヤー数）＝５億回の加算処理である。
これらの加算処理は、プレイヤー毎に計算することができ、仮にログデータベースが分散化されている状況においても、単一のデータベース（本実施形態の図３の全プレイヤーログＤＢ１２２に相当）内の集計処理として実装することができる。
また、途中集計結果は、上述した様にランキング結果ＤＢ１２３に保存される。これにより、常に差分計算を行うだけで最新の順位（ランキング）を演算することが容易に可能になる。
【００６８】
このように、本実施形態では多種多様なｍ種のランキング指標のうち、プレイヤーのプレイスタイルに適合するランキング指標が推薦ランキング指標として、当該プレイヤーに提示される。
しかしながら、ｍ種のランキング指標の全てを人手により定義することは煩雑である。
このため、図３に示す様に、新たなランキング指標を自動生成する機能を有するランキング指標生成部１０６がサーバ２に設けられている。
具体的には、ランキング指標生成部１０６は、図１３乃至図１５に示す様なごく少数のテンプレートから、新たなランキング指標を自動生成することができる。
【００６９】
図１３は、ゲームのダメージ系に関するランキング指標を自動生成するためのテンプレートの一例を示している。
図１３の例のテンプレートにおいて、％ＡＴＲＲＩＢＵＴＥＳ％は、ゲーム内の属性情報の種類に応じて展開されるものである。つまり、属性毎に異なるランキング指標が生成される。
【００７０】
図１４は、図１３の例とは異なる応用例であって、とある特定のキャラクタを使いこなしたプレイヤーが上位にランキングされるタイプのテンプレートの一例を示している。
図１４の例のテンプレートにおいて、％ＣＨＡＲＡＣＴＥＲＳ％は、ゲーム中に登場する味方キャラクタの種類に応じて展開されるものである。つまり、キャラクタ毎に異なるランキング指標が生成される。
【００７１】
図１５は、図１３及び図１４の各例とは異なる応用例であって、ダメージ以外のスコアを用いたランキング指標を自動生成するためのテンプレートの一例を示している。
図１５の例では、ｑｕｅｒｙ：｛ｅｖｅｎｔ＿ｔｙｐｅ  ＝  ｂａｔｔｌｅＡｔｔａｃｋ｝と指定することにより、バトル中の回復イベントを対象として、ｔａｒｇｅｔｓ：｛ｈｅａｌ｝と指定することにより、回復したＨＰの量を集計するといったランキング手法が生成される。
【００７２】
このような図１３乃至図１５等のテンプレートをごく少数予め用意するだけで、多種多様なランキング指標を、ゲームシステムが既に有する情報から自動的に生成することが容易にできる。
【００７３】
以上、サーバ２の機能的構成について説明した。
次に、図１６及び図１７を参照して、このような機能的構成を有するサーバ２が実行する処理のうち、推薦ランキング指標提示処理について説明する。
図１６は、サーバ２が実行する推薦ランキング処理の流れを説明するフローチャートである。
【００７４】
推薦ランキング処理は、所定タイミングをトリガとして、例えばプレイヤー端末１−１乃至１−ｎのうち所定の１つにおいて図４（Ｂ）のおまかせ選択のボタン２２６が押下されたタイミングをトリガとして、所定プレイヤー（例えばおまかせ選択のボタン２２６を押下したプレイヤー）が注目プレイヤーに設定されて、次のような一連の処理が実行される。
【００７５】
ステップＳ１において、図３のランキング指標推薦部１０４の予想順位算出部１１１は、多種多様なｍ種類のランキング指標のうち少なくとも一部の夫々について、注目プレイヤーの予想順位を算出する。
このようなステップＳ１の処理を、以下、「予想順位算出処理」と呼ぶ。
図１７は、予想順位算出処理の詳細の一例を説明するフローチャートである。
【００７６】
ステップＳ２１において、予想順位算出部１１１は、ｍ種類のランキング指標のうち所定の要件を満たすランキング指標を、推薦対象から除外する。
なお、ｍ種類のランキング指標の全てが推薦対象となり得るならば、ステップＳ２１の処理は不要である。
また、推薦対象から除外するための所定の要件は、特に限定されず、ゲーム設計者やサーバ２の管理者等により任意に設定可能なものであり、例えば上述した様に、注目プレイヤーが既に第１位を獲得したことがあるランキング指標といった要件を採用することができる。
【００７７】
ステップＳ２２において、予想順位算出部１１１は、ｍ種類のランキング指標のうちステップＳ２１で除外された以外の所定のランキング指標を、注目ランキング指標に設定する。
【００７８】
ステップＳ２３において、予想順位算出部１１１は、注目ランキング指標について、第１位乃至第ｎ位までの想定スコアｐを算出する。
ステップＳ２４において、予想順位算出部１１１は、注目ランキング指標について、注目プレイヤーの現状スコアｃを算出する。
ステップＳ２５において、予想順位算出部１１１は、想定スコアｐと現状スコアｃとに基づいて、注目ランキング指標における、注目プレイヤーの予想順位を算出する。
【００７９】
ステップＳ２６において、予想順位算出部１１１は、ｍ種類のランキング指標のうちステップＳ２１で除外されたもの以外の全てのランキング指標を、注目ランキング指標に設定したか否かを判定する。
未だ注目ランキング指標に設定されていないものがある場合、ステップＳ２６においてＮＯであると判定されて、処理はステップＳ２２に戻され、それ以降の処理が繰り返される。
【００８０】
即ち、ｍ種類のランキング指標のうちステップＳ２１で除外された以外のものの夫々について、ステップＳ２２乃至Ｓ２６のループ処理が繰り返されて、注目プレイヤーの予想順位が順次算出される。
その結果、全てのランキング指標が注目ランキング指標に設定されたことになるので、ステップＳ２６においてＹＥＳであると判定されて、予想順位算出処理が終了する。これにより、処理は図１６のステップＳ１からステップＳ２に進む。
【００８１】
ステップＳ２において、図３のランキング指標推薦部１０４の推薦ランキング指標決定部１１２は、各予想順位に基づいて、多種多様なｍ種類のランキング指標のうち少なくとも一部の中から、推薦ランキング指標を決定する。
ステップＳ３において、推薦結果提示部１０５は、推薦ランキング指標を、注目プレイヤーのプレイヤー端末１に提示する。
これにより、推薦ランキング指標提示処理は終了となる。
【００８２】
以上本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。
【００８３】
例えば、図３の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図３の例に限定されない。また、機能ブロックの存在場所も、図３に特に限定されず、任意でよい。例えば、サーバ２の機能ブロックをプレイヤー端末１等に移譲させてもよい。逆に図３には図示せぬ端末１の機能ブロックをサーバ２等に移譲させてもよい。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。
【００８４】
各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。
【００８５】
このようなプログラムを含む記録媒体は、プレイヤーにプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でプレイヤーに提供される記録媒体等で構成される。
【００８６】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。
【００８７】
換言すると、本発明が適用される情報処理システム内のサーバは、上述の図２や図３の実施形態としてのサーバ２を含め、次のような構成を有する各種各様の実施形態を取ることができる。
即ち、本発明が適用されるサーバ（例えば図１のサーバ２）は、
複数のプレイヤーの夫々の操作を受付けてゲームを実行し得る複数の端末（例えば図１のプレイヤー端末１−１乃至１−ｎ）の夫々と通信し、前記複数のプレイヤーのうち少なくとも１人以上が参加者として参加するランキング指標を複数種類管理し、複数種類の前記ランキング指標毎に前記参加者のランキングを算出するサーバであって、
前記複数のプレイヤーのうち、処理対象として注目すべきプレイヤーを注目プレイヤーとして、前記複数種類のランキング指標のうちの少なくとも一部の夫々に対して、当該注目プレイヤーが参加した場合の順位を予想順位として算出する予想手段（例えば図３の予想順位算出部１１１）と、
前記予想順位に基づいて、前記注目プレイヤーに推薦すべきランキング指標を推薦ランキング指標として決定する決定手段（例えば図３の推薦ランキング指標決定部１１２）と、
前記推薦ランキング指標を前記注目プレイヤーの端末に対して提示する提示手段（例えば図３の推薦結果提示部１０５）と、
を備える。
【００８８】
これにより、従来よりも圧倒的多数種類（ｍ種類）のランキング指標をプレイヤーに提供し、かつ、これらのランキング指標のうち推薦ランキング指標への参加をプレイヤーに強く動機づけることが可能になる。
つまり、従来よりも圧倒的多数種類（ｍ種類）のランキング指標をプレイヤーに提供することで、カジュアルプレイヤーであっても自らのプレイスタイルに応じて上位入賞を狙えるランキング指標、即ち、各プレイヤーのプレイスタイルに適合したランキング指標を用意することができる。
ただし、各プレイヤーが、自らのプレイスタイルに適合したランキング指標を、従来よりも圧倒的多数種類（ｍ種類）のランキング指標の中から見つけ出すことは非常に困難である。
そこで、本発明が適用されるサーバは、注目プレイヤーのプレイスタイルに適合したランキング指標、換言すると、そのようなプレイスタイルを持った注目プレイヤーが参加すればランキング（順位）が上位になると期待されるランキング指標を、推薦ランキング指標として自動的に決定する。そして、当該サーバは、当該注目プレイヤーの端末に対して、当該推薦ランキング指標を提示する。
即ち、各プレイヤーにとっては、自らのプレイスタイルに適合したランキング指標を自ら検索することなく、サーバから推薦ランキング指標として提示される。このようにして、各プレイヤーは、多種多様なｍ種類のランキング指標の中から、自らのプレイスタイルに応じて、上位入賞を期待できるランキング指標を容易かつ即座に選択することができる。
これにより、多数のカジュアルプレイヤーにランキングへの参加を動機付けることが可能になる。
【００８９】
さらに、本発明が適用されるサーバは、従来より低い運用コストで実現することができる。
即ち、１つ１つのランキング指標の計算コストが、従来のランキングよりもはるかに少なくなる。これは、ランキング指標の種類数は従来より圧倒的に多く、かつ、プレイヤー毎に異なるランキング指標を推薦するため、１つのランキング指標に参加するプレイヤーの数は、従来の総合ランキングと比較して少なくなるためである。
これにより、とあるランキング指標に関する演算を行うとき、参照すべきデータベースの数が少なくなるため、分散データベース環境におけるログ集計の負荷を大きく減少させることができる。
【００９０】
また、本発明が適用されるサーバにより管理される新たな多種多様なランキング指標は、従来の総合ランキングの存在を妨げることはない。つまり、カジュアルプレイヤーでも上位入賞を狙えるランキング指標が、多種多様なプレイスタイルに応じて選択可能なように、多数のランキング指標が用いられると共に、従来の総合ランキングも用いられる。これにより、従来のランキング上位者のプレイスタイルを妨げない。
つまり、多数のカジュアルプレイヤーにランキングへの参加を動機付けることが可能になるばかりではなく、ランキングそのものへの注目度が高まれば、従来の総合ランキング上位者への動機付けにも繋がる。
このように、本発明が適用されるサーバが管理する多種多様なランキング指標を用いたランキングと、従来の総合ランキングとは、相補的な関係にある。
【００９１】
また、本発明が適用されるサーバが管理する多種多様なランキング指標を用いたランキングは、高いプレイヤービリティを提供する。
即ち、上述した様に、本発明が適用されるサーバは、プレイヤー毎に異なるプレイスタイルに応じてランキング指標を自動的に推薦する。これにより、各プレイヤーは、数多くのランキング指標の中から、自分のプレイスタイルにあったランキング指標を容易に選択することができる。
これにより、特定のランキング指標に参加者数が偏る事態に陥ることを防止することができる。
【００９２】
また、本発明が適用されるサーバが管理する多種多様なランキング指標を用いたランキングは、ゲームに登場する多数のキャラクタの中でも特に「キャラクタＡの使い手」という観点でのランキングを実現することができる。この場合、「キャラクタＡ」を使い込むといった、こだわりのある優れたプレイスタイルを評価することに繋がる。その結果、ゲームタイトルの楽しみ方を多様化させる効果も生じる。
さらに言えば、本発明が適用されるサーバが管理する多種多様なランキング指標として、例えば、キャラクタやアイテムの種別毎に設定することができる。
具体的には例えば、「水属性武器の使い手（水属性の武器を装備して獲得した経験値でランキング）」、「キャラクタＡ・マスター（キャラクタＡを使用して敵に与えたダメージの累計でランキング）」、「回復スキルＢの達人（回復スキルＢを使って回復したＨＰの累計でランキング）」等の各種各様なランキング指標を設定することができる。
また、これらのランキング指標を組み合わせ、別の新たなランキング手法を定義することも容易にできる。例えば、「キャラクタＣとキャラクタＤの連携の達人（キャラクタＣとキャラクタＤが同一パーティに編成されている状態で、敵に与えたダメージの累計でランキング）」等を定義することができる。
【００９３】
なお、本発明が適用されるサーバが管理する多種多様なランキング指標を用いたランキングに対して、いわゆるプレイ動画を紐づけることもできる。
この場合、各プレイヤーは、「自分が興味を持つプレイスタイルにおける上級者」の動画を即座に獲得し、競い合うことができるようになる。
また例えば、多様化したランキングの上位者のプレイ動画を、ランキング指標のユーザインタフェース（図４参照）から直ちに閲覧できる導線を用意することにより、「キャラクタＡの使い手」第１位の優れたプレイを、同じキャラクタを使うプレイヤーが学習する等の新たなゲームの楽しみ方を産出することもできる。
【００９４】
ここで、前記決定手段は、前記予想順位が所定の要件を満たすランキング指標を、前記推薦ランキング指標として１以上決定し、
前記提示手段は、１以上の前記推薦ランキング指標を、前記予想順位が高い順にソートして、前記注目プレイヤーの端末に対して提示する、
ことができる。
【００９５】
このように、推薦ランキング指標はお薦め順に１種類以上注目プレイヤーに提示される。従って、各プレイヤーは、多種多様なｍ種類のランキング指標の中から、自らのプレイスタイルに応じて、上位入賞を期待できるランキング指標としてより相応しいものを容易かつ即座に選択することができる。
【００９６】
また、所定のランキング指標に対して予め定義されたスコアの算出手法に従って、当該所定のランキング指標に参加する１以上の参加者のスコアを夫々算出し、当該スコアに基づいて、当該１以上の参加者の順位を夫々特定する処理を、前記複数種類のランキング指標毎に繰り返して実行する特定手段（例えば図３のランキング順位特定部１０３）をさらに備え、
前記予想手段は、
前記複数種類のランキング指標のうち、処理対象として注目すべきランキング指標を注目ランキング指標として、
前記注目ランキング指標における過去の複数回のスコアに基づいて、予想順位の指標として想定される想定スコアを第１位乃至第ｎ位まで設定し（例えば図１７のステップＳ２３）、
前記注目ランキング指標に対して予め定義されたスコアの算出手法に従って、前記注目プレイヤーの現状スコアを算出し（例えば図１７のステップＳ２４）、
第１位乃至第ｎ位の前記想定スコアと、前記注目プレイヤーの前記現状スコアとに基づいて、前記注目プレイヤーの前記予想順位を算出する（例えば図１７のステップＳ２５）、
ことができる。
【００９７】
これにより、注目プレイヤーの予想順位が精度よく算出することが可能になる。その結果、注目プレイヤーにより適切な推薦ランキング指標を提示することが可能になる。
【００９８】
また、前記予想手段は、前記注目プレイヤーが過去に参加済みの前記ランキング指標のうち所定の要件を満たすものを、前記注目ランキング指標から除外する、
ことができる。
ここで、推薦ランキング指標の候補（注目ランキング指標）から除外するための所定の要件は、特に限定されず、ゲーム設計者やサーバの管理者等により任意に設定可能なものであり、例えば、注目プレイヤーが既に第１位を獲得したことがあるランキング指標といった要件を採用することができる。
このような要件を採用することで、未だ第１位を獲得したことはないが、獲得の可能性が高い（上位入賞を狙える）ものを推薦ランキング指標として注目プレイヤーに提示することができる。その結果、注目プレイヤーがゲームを実行するモチベーションに繋がる。
【符号の説明】
【００９９】
１、１−１乃至１−ｎ・・・プレイヤー端末、２・・・サーバ、５１・・・ＣＰＵ、１０１・・・ランキング参加管理部、１０２・・・時間管理部、１０３・・・ランキング順位特定部、１０４・・・ランキング指標推薦部、１０５・・・推薦結果提示部、１０６・・・ランキング指標生成部、１１１・・・予想順位算出部、１１２・・・推薦ランキング指標決定部、１２１・・・参加ランキング指標ＤＢ、１２２・・・全プレイヤーログＤＢ、１２３・・・ランキング結果ＤＢ、１２４・・・スコアＤＢ、１２５・・・ランキング指標ＤＢ
【要約】
【課題】各プレイヤーにランキングへの参加の動機付けを与える技術の確立すること。
【解決手段】ランキング順位特定部１０３は、複数種類のランキング指標毎に参加者の順位を特定する。ランキング指標推薦部１０４の予想順位算出部１１１は、複数種類のランキング指標のうちの少なくとも一部の夫々に対して、注目プレイヤーが参加した場合の順位を予想順位として算出する。推薦ランキング指標決定部１１２は、予想順位に基づいて、注目プレイヤーに推薦すべきランキング指標を推薦ランキング指標として決定する。推薦結果提示部１０５は、推薦ランキング指標を注目プレイヤーのプレイヤー端末１に対して提示する。
【選択図】図３【図１】
0005933083.tif 000002
【図２】
0005933083.tif 000003
【図３】
0005933083.tif 000004
【図４】
0005933083.tif 000005
【図５】
0005933083.tif 000006
【図６】
0005933083.tif 000007
【図７】
0005933083.tif 000008
【図８】
0005933083.tif 000009
【図９】
0005933083.tif 000010
【図１０】
0005933083.tif 000011
【図１１】
0005933083.tif 000012
【図１２】
0005933083.tif 000013
【図１３】
0005933083.tif 000014
【図１４】
0005933083.tif 000015
【図１５】
0005933083.tif 000016
【図１６】
0005933083.tif 000017
【図１７】
0005933083.tif 000018