以下、添付図面を参照しながら各実施形態について詳細に説明する。
(ゲームシステムの概要)
図1を参照して、本実施形態に係るゲームシステム1の概要について説明する。図1は、本実施形態に係るゲームシステム1のブロック図である。ゲームシステム1は、サーバ装置10と、1つ以上の端末装置20と、を備える。図1では簡便のため、3つの端末装置20を図示しているが、端末装置20の数は2つ以上であればよい。
サーバ装置10は、例えばサービス運営者が管理するサーバ等の情報処理装置である。本実施形態では、一例として、サーバ装置10は、いわゆるサービスプラットホームを実現し、サービスプラットホームを介して、各種のサービスを提供する。具体的には、サーバ装置10は、一例として、アプリポータルサイト(以下、単に「サイト」とも称する)と、アプリケーション・ソフトウェア(以下、単に「アプリケーション」とも称する)と、ソーシャルネットワーク機能(以下、単に「SNS機能」とも称する)とを、登録ユーザ(及び必要に応じてゲストユーザ)に提供する。以下、登録ユーザ(及び必要に応じてゲストユーザ)について、単に「ユーザ」とも称する。
サーバ装置10が提供するサイトの数は、任意であるが、本実施形態では、一例として、1つのサイト(以下、「サイトA」とも称する)であるものとする。
サーバ装置10が提供するアプリケーションの種類や数は、任意であるが、本実施形態では、一例として、サーバ装置10が提供するアプリケーションは、1つ以上のゲーム用のアプリケーション(以下、単に「ゲームアプリ」とも称する)を含み、その他、デジタルコンテンツ(ゲームアプリ以外のデジタルコンテンツ)を利用するための各種のアプリケーションを含んでよい。ゲームアプリ等は、サイトAを介して実行可能とされてもよいし、オフラインで実行可能とされてもよい。以下、ゲームとは、サーバ装置10が提供するゲームアプリに係るゲームを指す。
サーバ装置10が提供するSNS機能の種類や数は、任意であるが、ここでは、日記や、チャット、伝言板/掲示板(コミュニティ)、コメント、メッセンジャー、友達リクエスト、オブジェクトの送信(贈り物の送信)等のような機能であってよい。SNS機能は、サイトAを介して実行可能とされてよい。
端末装置20は、例えば携帯電話、スマートフォン、タブレット端末、PC(Personal Computer)、又はゲーム装置等の、ユーザによって使用される情報処理装置である。端末装置20は、本実施形態に係る各種アプリケーションを実行可能である。各種アプリケーションは、ネットワーク3を介してサーバ装置10又は他の所定のアプリケーション配信サーバから端末装置20に受信されてもよく、あるいは端末装置20に備えられた記憶装置又は端末装置20が読取可能なメモリカード等の記憶媒体に予め記憶されていてもよい。サーバ装置10及び端末装置20は、ネットワーク3を介して通信可能に接続される。例えば、サーバ装置10及び端末装置20が協働して、サービスに関する多様な処理を実行する。
なお、ネットワーク3は、無線通信網や、インターネット、VPN(Virtual Private Network)、WAN(Wide Area Network)、有線ネットワーク、又はこれらの任意の組み合わせ等を含んでよい。
(サーバ装置の構成)
サーバ装置10の構成について具体的に説明する。サーバ装置10は、サーバコンピュータにより構成される。サーバ装置10は、複数台のサーバコンピュータにより協動して実現されてもよい。
サーバ装置10は、サーバ通信部11と、サーバ記憶部12と、サーバ制御部13と、を備える。
サーバ通信部11は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。サーバ通信部11は、例えば無線LAN(Local Area Network)通信モジュール又は有線LAN通信モジュール等を含んでもよい。サーバ通信部11は、ネットワーク3を介して、端末装置20との間で情報を送受信可能である。
サーバ記憶部12は、例えば一次記憶装置及び二次記憶装置を含む。例えばサーバ記憶部12は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。サーバ記憶部12は、サービスに関する処理に用いられる種々の情報及びプログラムを記憶する。サーバ記憶部12に記憶された情報及びプログラムの少なくとも一部が、端末装置20との間で共有及び同期されてもよい。以下、サーバ記憶部12が記憶する情報の例について具体的に説明する。
サーバ制御部13は、1つ以上のプロセッサを含む。プロセッサは、特定のプログラムを読み込むことにより特定の機能を実現する汎用プロセッサ、及び特定の処理に特化した専用プロセッサを含んでもよい。サーバ制御部13は、サーバ装置10全体の動作を制御する。サーバ制御部13の詳細は後述する。
(端末装置の構成)
端末装置20の構成について具体的に説明する。図1に示すように、端末装置20は、端末通信部21と、端末記憶部22と、表示部23と、入力部24と、端末制御部25とを備える。
端末通信部21は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。端末通信部21は、例えばLTE(Long Term Evolution)(登録商標)等のモバイル通信規格に対応する無線通信モジュール、無線LAN通信モジュール、又は有線LAN通信モジュール等を含んでもよい。端末通信部21は、ネットワーク3を介して、サーバ装置10との間で情報を送受信可能である。
端末記憶部22は、例えば一次記憶装置及び二次記憶装置を含む。例えば端末記憶部22は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。端末記憶部22は、サーバ装置10から受信する、サービスに関する処理に用いられる種々の情報及びプログラムを記憶する。サービスに関する処理に用いられる情報及びプログラムは、端末通信部21を介して外部装置から取得されてもよい。例えば、ゲームアプリが、所定のアプリケーション配信サーバから取得されてもよい。
表示部23は、例えば液晶ディスプレイ又は有機EL(Electro−Luminescence)ディスプレイ等の表示デバイスを含む。表示部23は、多様な画面を表示可能である。
入力部24は、例えば表示部23と一体的に設けられたタッチパネルを含む入力インタフェースを含む。入力部24は、端末装置20に対するユーザ入力を受付可能である。また、入力部24は、物理キーを含んでもよいし、マウス等のようなポインティングデバイスをはじめとする任意の入力インタフェースを更に含んでもよい。
端末制御部25は、1つ以上のプロセッサを含む。端末制御部25は、端末装置20全体の動作を制御する。以下、端末制御部25の動作の例について具体的に説明する。
端末制御部25は、端末通信部21を介して情報の送受信を行う。例えば、端末制御部25は、サービスに関する処理に用いられる種々の情報及びプログラムを、サーバ装置10及び他の外部サーバの少なくとも一方から受信する。端末制御部25は、受信された情報及びプログラムを、端末記憶部22に記憶する。
端末制御部25は、ユーザの操作に応じて、サイトAや、サイトA内のゲームアプリ等を起動する。端末制御部25は、サーバ装置10と協働して、サービスに関する処理を実行する。例えば、端末制御部25は、サービスに関する処理に係る種々の画面を表示部23に表示させる。画面上には、例えばユーザ操作を検出するGUI(Graphic User Interface)が表示されてもよい。端末制御部25は、入力部24を介して、画面に対するユーザ操作を検出可能である。
本実施形態では、一例として、サイトAを介して各ユーザがプレイ可能なゲームは、1つ以上である。各種のゲームのうちの1つは、例えば、図2を参照して以下で説明するようなゲームである。
(ゲームアプリの概要)
本実施形態に係るゲームアプリの一例の概要について説明する。本実施形態に係るゲームは、1つ以上のゲームパートを含む。1つ以上のゲームパートのうち少なくとも1つのゲームパートは、ゲーム媒体を用いて実行されてもよい。
ゲーム媒体は、ゲームに使用される電子データであり、例えば、カード、アイテム、ポイント、仮想通貨、チケット、キャラクタ、アバタ、パラメータ等、任意の媒体を含む。また、ゲーム媒体は、レベル情報、ステータス情報、パラメータ情報(体力値及び攻撃力等)又は能力情報(スキル、アビリティ、呪文、ジョブ等)のような、ゲーム関連情報であってもよい。また、ゲーム媒体は、ユーザによってゲーム内で取得、所有、使用、管理、交換、合成、強化、売却、廃棄、又は贈与等され得る電子データであるが、ゲーム媒体の利用態様は本明細書で明示されるものに限られない。
以下、特に明示した場合を除き、「ユーザが所有するゲーム媒体」とは、当該ユーザを一意に識別可能なユーザIDに所有ゲーム媒体として対応付けられたゲーム媒体を示す。また、「ゲーム媒体をユーザに付与する」とは、ゲーム媒体を所有ゲーム媒体としてユーザIDに対応付けることを示す。また、「ユーザが所有するゲーム媒体を破棄する」とは、ユーザIDと所有ゲーム媒体との対応付けを解消することを示す。また、「ユーザが所有するゲーム媒体を消費する」とは、ユーザIDと所有ゲーム媒体との対応付けの解消に応じて、何らかの効果又は影響をゲーム内で発生させ得ることを示す。また、「ユーザが所有するゲーム媒体を売却する」とは、ユーザIDと所有ゲーム媒体との対応付けを解消し、且つ、ユーザIDに他のゲーム媒体(例えば、仮想通貨又はアイテム等)を所有ゲーム媒体として対応付けることを示す。また、「ユーザAが所有するゲーム媒体をユーザBに譲渡する」とは、ユーザAのユーザIDと所有ゲーム媒体との対応付けを解消し、且つ、ユーザBのユーザIDに当該ゲーム媒体を所有ゲーム媒体として対応付けることを示す。また、「ゲーム媒体を作成する」とは、ゲーム媒体に関する情報の少なくとも一部を定義又は決定することを示す。
ゲームパートは、ゲーム内でユーザがプレイ可能なコンテンツであって、例えばクエスト、ミッション、ミニゲーム、ゲーム媒体の育成、強化、及び合成、ゲーム媒体入手イベント、仮想空間の探索イベント、並びに対戦相手(例えば、他のユーザ、敵キャラクタ、及び敵の建物等)との対戦イベント等を含む。各ゲームパートには、1つ以上の所定の課題(ゲーム課題)が設定されてもよい。例えば、ユーザによってプレイされるゲームパートに設定された1つ以上のゲーム課題の達成に成功したと判定された場合、ユーザに対して、例えばゲーム媒体等が報酬として付与されてもよい。ゲーム課題には、例えば敵キャラクタとの対戦に勝利するとの課題、仮想空間内のゴール地点まで到達するとの課題、及び所定時間が経過するまでユーザのキャラクタが所定の状態(例えば、行動不能の状態)にならないとの課題等、ゲームパートの内容に応じた任意の課題が採用可能である。また、ゲームパートに設定された1つ以上のゲーム課題のうち、特定の課題(クリア課題)が達成されることを、ゲームパートのクリアともいう。ゲームパートをプレイするユーザがクリア課題の達成に成功した場合、当該ゲームパートのクリアと判定され、当該ゲームパートが終了してもよい。
1つ以上のゲームパートには、シングルプレイ用のゲームパートと、マルチプレイ用のゲームパートと、が含まれてもよい。シングルプレイ用のゲームパートは、例えば、1人のユーザが使用する1つの端末装置20に対するユーザ操作に基づいて実行されるゲームパート(例えば、一人用のゲームパート)を含んでもよい。例えば、1つの端末装置20が単独で、又は1つの端末装置20とサーバ装置10とが協働して、シングルプレイ用のゲームパートを実行する。一方、マルチプレイ用のゲームパートは、例えば、2人以上のユーザがそれぞれ使用する2つ以上の端末装置20に対するユーザ操作に基づいて実行される、当該2人以上のユーザに共通のゲームパート(例えば、複数人用のゲームパート)を含んでもよい。2人以上のユーザに共通のゲームパートは、例えば、当該ゲームパートの進行処理の少なくとも一部及び処理結果の少なくとも一部が、当該2人以上のユーザに対して共通して適用されるゲームパートを含んでもよい。例えば、2つ以上の端末装置20が協働して、又は2つ以上の端末装置20とサーバ装置10とが協働して、マルチプレイ用のゲームパートを実行する。1つのゲームパートが、シングルプレイ及びマルチプレイの両方に対応してもよい。
本実施形態に係るゲームの1つは、一例として、例えば横スクロール型のアクションゲームの要素と、ゲーム媒体を用いて対戦相手と対戦する対戦ゲームの要素と、を有する対戦ゲームパートを含む。ユーザは、自身が所有するゲーム媒体(所有ゲーム媒体)のうちから、対戦ゲームパートに使用する1つ以上のゲーム媒体を選択する。以下、対戦ゲームパートに使用される各ゲーム媒体を、第1ゲーム媒体ともいう。当該1つ以上の第1ゲーム媒体を纏めてデッキ又はチームともいう。対戦相手は、例えばNPC(Non−Player Character)等の自動的に操作されるゲーム媒体であるが、これに限られない。例えば、対戦相手は、他のユーザによって操作されるゲーム媒体であってもよい。1つの対戦ゲームパートにおいて、対戦相手の数は任意に定められてもよい。
本実施形態に係る対戦ゲームパートの概要について図2を参照して概説する。図2は、対戦ゲームパートの概要の説明用のプレイ画面の一例を示す。
端末装置20を用いてシングルプレイ用の対戦ゲームパートをプレイするユーザは、例えば仮想空間内に配置された移動オブジェクト140を操作して、障害物等を避けつつ所定のアイテムを取得する。移動オブジェクト140は、所定のゲーム媒体(第2ゲーム媒体)に対応する。第2ゲーム媒体は、例えば、路面141上を走行するバイク、自動車、又は人物等を含んでもよい。アイテム142の取得に応じて、デッキに含まれるゲーム媒体(第1ゲーム媒体A1、B、C、D、E)が、所定の行動(例えば、対戦相手に対する攻撃)を行う。第1ゲーム媒体の行動によって、対戦相手(図2では、対戦相手に係るオブジェクト144が表示)にダメージを与えられ得る。一方、対戦相手は、例えば所定の時間間隔で、所定の行動(例えば、ユーザに対する攻撃)を行う。対戦相手の行動によって、ユーザ(図2では、ユーザに係るオブジェクト143が表示)にダメージが与えられ得る。ユーザ及び対戦相手それぞれには、与えられたダメージの量だけ減少する所定のパラメータ(合計HP及びHP)が設定されている。なお、図2において、画像領域145は、合計HPの残りをゲージで表示する領域であり、画像領域148は、対戦相手のHPの残りをゲージで表示する領域であり、画像領域149は、デッキに含まれる各第1ゲーム媒体の状態を示す領域である。対戦相手の当該パラメータが所定値(例えば、ゼロ)まで減少すると、ユーザの勝利と判定される。一方、ユーザの当該パラメータが所定値(例えば、ゼロ)まで減少すると、ユーザの敗北と判定される。ユーザの勝利又は敗北と判定された場合、当該対戦ゲームパートが終了してもよい。
一方、マルチプレイ用の対戦ゲームパートは、2人以上のユーザが共通の対戦相手と対戦する点を除き、上述したシングルプレイ用の対戦ゲームパートと同様に実行される。具体的には、2人以上のユーザそれぞれは、自身の端末装置20を用いて、共通の対戦ゲームパートをプレイする。当該2人以上のユーザそれぞれは、上述のように仮想空間内の第2ゲーム媒体を操作する。当該2人以上のユーザに共通の仮想空間が用いられてもよいし、ユーザごとに独立した仮想空間が用いられてもよい。当該2人以上のユーザそれぞれのデッキに含まれる第1ゲーム媒体が、例えば共通の対戦相手に対して攻撃を行う。対戦相手の上述したパラメータは、2人以上のユーザに対して共通に適用される。例えば、2人以上のユーザがそれぞれ使用する複数の端末装置20の間で、対戦相手の当該パラメータが同期されてもよい。対戦相手の当該パラメータが所定値(例えば、ゼロ)まで減少すると、2人以上のユーザの勝利と判定される。一方、2人以上のユーザそれぞれの当該パラメータが所定値(例えば、ゼロ)まで減少すると、2人以上のユーザの敗北と判定される。2人以上のユーザの勝利又は敗北と判定された場合、当該対戦ゲームパートが終了してもよい。
なお、上述したゲームは、あくまで一例であり、本実施形態は、一般的なRPG(Role Playing Game)以外にも、釣りゲーム、ランゲーム、ダンジョンゲーム、オセロゲーム、格闘ゲーム、街づくりゲーム、競馬ゲーム、野球ゲームのようなスポーツゲーム、シューティングゲーム等にも適用できる。
(継続促進処理)
本実施形態では、サーバ装置10は、更に、特定ユーザに対してゲームのプレイを継続する動機付けを与えるための機能(以下、「継続促進機能」とも称する)を有する。以下では、説明上、特に言及しない限り、ある特定の一のゲーム(サイトAでプレイ可能な1つ以上のゲームのうちの一のゲームであり、例えば図2を参照して上述したようなゲーム)に関する継続促進機能について説明する。継続促進機能は、ゲームごとに実現されてもよいし、サイトAでプレイ可能な1つ以上のゲームのうちの特定のゲームに対してのみ実現されてもよい。以下、ゲームとは、特に言及しない限り、ある特定の一のゲームを指す。
図3は、サーバ装置10が実現する各種機能のうちの、継続促進機能に関連する機能に関する機能ブロック図である。図4は、ユーザ情報データベース50内のデータの説明図である。図4(後出の図5や、図6等も同様)において、「***」は、何らかの情報が格納されていることを意味し、「・・・」は、同様の情報の繰り返しを意味する。図5は、ゲームに関する情報の説明図である。図6は、ログ情報データベース52内のデータの説明図である。図7は、指標値データベース54内のデータの説明図である。図8は、グループ化処理の説明図である。図9は、特定イベントデータベース56内のデータの説明図である。
サーバ装置10は、各端末装置20と協動して、以下で説明する各種機能を実現する。サーバ装置10は、図3に示すように、ユーザ登録部30と、ゲーム処理部31と、課金処理部32と、ログ情報蓄積部34と、ログ情報取得部36と、指標値算出部37と、グループ化部38と、特典付与部39と、特定イベント発生部40と、通知部41と、ユーザ情報データベース50と、ログ情報データベース52と、指標値データベース54と、特定イベントデータベース56とを含む。ユーザ登録部30から通知部41は、上述したサーバ通信部11及びサーバ制御部13により実現でき、ユーザ情報データベース50から特定イベントデータベース56は、上述したサーバ記憶部12により実現できる。
なお、ユーザ登録部30から通知部41の各機能部の区別は、説明の都合上であり、特定の一の機能部の機能(以下で説明する機能)の一部又は全部が、他の一の機能部により実現されてもよい。ユーザ情報データベース50から特定イベントデータベース56についても同様であり、特定の一のデータベースの機能(以下で説明する機能)の一部又は全部が、他の一のデータベースにより実現されてもよい。
ユーザ登録部30は、サイトAを利用するユーザに係るユーザ情報をユーザ情報データベース50に登録する。なお、ユーザ情報データベース50に登録されたユーザは、登録ユーザの一例である。
ユーザ情報は、図4に示すように、ユーザID(ユーザ識別情報の一例)に対応付けられる態様で、ユーザ名、パスワード、電話番号、所持コイン、ゲームに関する情報、SNSに関する情報等を含む。ユーザ情報は、例えば、ユーザIDやユーザ名のような初期的に登録される情報とともに、ゲームに関する情報のような、事後的に蓄積される情報を含んでよい。また、ユーザ情報は、その他、ユーザのメールアドレス等を含んでよい。
ユーザIDは、ユーザを一意に識別可能な情報である。以下、ユーザIDを単にユーザともいう。
ユーザ名は、ユーザの名前を示す情報である。ユーザ名は、ユーザIDとは異なり、ユーザを一意に識別可能でなくてもよい。ユーザ名は、端末装置20に対するユーザ操作に応じて任意に決定及び変更が可能であってもよい。なお、ユーザ名は、初期的に登録される情報であり、登録すべき必須情報であってよい。
パスワードは、ユーザ名によるサイトAへのログインを可能とするためのパスワードである。パスワードは、用途に応じて複数種類設定されてもよい。パスワードは、初期的に登録される情報であり、登録すべき必須情報であってよい。
電話番号は、例えばショートメッセージサービス(SMS)認証用の電話番号である。電話番号は、初期的に登録される情報であり、登録すべき必須情報であってもよいし、任意的な情報であってよい。
所持コインは、ユーザが所持するコイン数(現在利用可能なコインの数)を表す。また、本実施形態では、一例として、サイトAで利用できるコイン(以下、「Aコイン」と称する)であるとし、ユーザは、所持するAコインを消費することで、デジタルコンテンツの提供や、ゲーム内での各種対価を受けることができる。例えば、ユーザは、所持するAコインを消費することで、所望の第1ゲーム媒体を獲得したり、所望のアイテムを獲得したり等することができる。また、所持するAコインを消費することで、例えばガチャを回すことができる。なお、この場合、Aコインは、ゲーム媒体の一例である。変形例では、Aコインは、ゲーム内でのみ使用可能なゲーム媒体であってもよい。ユーザは、所持コインの初期値は、例えば0である。所持コインは、後述のように、課金処理部32により更新されうる。
ゲームに関する情報は、図5に示すように、ユーザIDごとに、ランクと、所有ゲーム媒体に関する情報と、使用ゲーム媒体に関する情報と、フレンド情報とを含んでよい。
ランクは、ゲームに関するユーザの熟練度を示すパラメータである。本実施形態において、ランクの値は、ユーザによるゲームのプレイに応じて増加してもよい。ランクが高いほど、ゲームに関するユーザの熟練度が高い。
所有ゲーム媒体に関する情報は、ユーザがゲーム内で所有するゲーム媒体(所有ゲーム媒体)に固有の種々の情報を含む。ゲーム媒体がユーザに取得された場合、当該ゲーム媒体は、所有ゲーム媒体としてユーザに対応付けられる。所有ゲーム媒体に関する情報の詳細は省略するが、ゲーム媒体IDごとに、ゲーム媒体名や、レアリティ、レベル、コスト、HP(HitPoint)、攻撃力、回復力等を含んでよい。
使用ゲーム媒体に関する情報は、対戦ゲームパートにおいてユーザに使用させるゲーム媒体(第1ゲーム媒体)を示す情報である。第1ゲーム媒体は、所有ゲーム媒体のうちから選択される。本実施形態において、1つ以上の所有ゲーム媒体のうちから選択された、例えば最大5つのゲーム媒体が、それぞれ第1ゲーム媒体としてユーザに対応付けられる。従って、1つのゲーム媒体が、所有ゲーム媒体であると同時に第1ゲーム媒体でもあり得る。第1ゲーム媒体は、例えば専用のゲームパートにおいて、自動的に又はユーザ操作に応じて選択されてもよい。例えば、当該専用のゲームパートは、いわゆるデッキ編成又はチーム編成等を行うゲームパートを含んでもよい。使用ゲーム媒体に関する情報に示される最大5つの第1ゲーム媒体が、1つのデッキを構成する。使用ゲーム媒体に関する情報は、複数のデッキの情報を含んでもよい。
フレンド情報は、ゲームにおけるフレンド関係にあるユーザIDを表す。例えば、ユーザAが、ユーザB、Cとフレンド関係である場合、ユーザAに対応付けられたフレンド情報は、ユーザB、CのユーザIDを含む。なお、フレンド関係は、フレンド申請等を介して実現される。このように、フレンド情報は、ユーザとの間で一方向的又は双方向的に関連付けられた他のユーザのユーザIDを含む。なお、フレンド関係にあるユーザ同士は、例えばゲーム中、メッセージの送受信等のコミュニケーションが可能であってもよい。なお、ユーザに関する情報において、フレンド情報に代えて又は加えて、所属するグループ(例えばギルドやパーティ)を示す情報が含められてもよい。
なお、ゲームに関する情報の内容は、上述したものに限られない。例えば、ユーザに関する情報は、ユーザがゲーム内で保有する所定のポイントを示す情報を更に含んでもよい。当該ポイントは、ユーザがゲームパートをプレイするために消費される。ゲームパートごとに、当該ポイントの消費量が異なってもよい。当該ポイントは、例えば時間経過に応じて、又は所定のゲーム媒体の使用に応じて、増加してもよい。
SNSに関する情報は、SNS機能に関連する各種情報を含んでよい。例えば、SNSに関する情報は、ユーザIDごとに、アバタに関する情報や、友達情報等を含んでよい。アバタに関する情報は、着せ替え用の衣類情報等を含んでよい。友達情報は、SNS機能を介してつながるユーザIDやグループIDを表してよい。友達情報は、ゲームにおけるフレンド情報と同一であってもよいし、別であってもよい。
ゲーム処理部31は、ゲームに関する各種の処理を行う。ゲームに関する各種の処理は、端末装置20からの操作情報に基づいて、ゲームのプレイを開始するとともにゲームを進行する処理等を含む。なお、ゲームを進行する処理は、ゲーム画面を生成することや、各種のパラメータを更新する処理等を含む。
また、ゲーム処理部31は、定期的に又は不定期的に通常イベントを発生させる。通常イベントは、後述する特定イベントとは異なり、すべてのユーザが参加可能なイベントである。通常イベントは、例えば、月に4回発生(開催)される。通常イベントの形態は任意であり、例えば、ゲーム媒体入手イベント、仮想空間の探索イベント、並びに対戦相手(例えば、他のユーザ、敵キャラクタ、及び敵の建物等)との対戦イベント等であってよい。
また、ゲーム処理部31は、特定イベント発生部40により発生される特定イベントに係る処理を実行する。ゲーム処理部31は、後述の特定ユーザに対してのみ特定イベントの参加を許可する。例えば、特定イベントが、特別なカードやアイテムが取得可能なボーナスステージを備えるゲームパートである場合、ゲーム処理部31は、特定ユーザに係る端末装置20からの操作情報に基づいて、当該ゲームパートを開始するとともにゲームを進行する。
課金処理部32は、課金サービスに関する処理を実行する。本実施形態では、一例として、サイトAではAコインが利用可能である。この場合、課金処理部32は、ユーザからAコインの提供(購買)の要求を受けると、所定条件の下で、ユーザにAコインを提供する。なお、課金処理部32は、後払いによらず、その時点での決済を条件として、ユーザにAコインを提供してもよいし、後払いによりユーザにAコインを提供してもよい。
また、課金処理部32は、ユーザからAコインの消費の要求を受けると、Aコインの消費を実現する。なお、ユーザは、上述のように、所望の第1ゲーム媒体を獲得したり、所望のアイテムを獲得したり、ガチャを回したりする際等に、Aコインを消費してもよい。
ログ情報蓄積部34は、サイトAを利用する各ユーザのログ情報を収集し、ユーザIDごとにログ情報をログ情報データベース52内に蓄積する。蓄積対象のログ情報は、すべてのログ情報であってもよいし、特定のログ情報(例えば操作ログに関するログ情報や、後述の指標値算出部37により利用されるログ情報)であってもよい。ログ情報は、各ユーザIDに基づくサイトAにおける各種活動(ログインや、ログアウト、デジタルコンテンツの利用、SNS機能へのアクセス/利用、課金等)を表す。本実施形態では、蓄積対象のログ情報は、ゲームのプレイに関するログ情報を含む。
図6には、ログ情報データベース52に蓄積されるログ情報の一例が示される。図6では、ユーザID(U01、U02等)ごとに、操作日時を表す情報と操作内容を表す情報とがセットとなって蓄積されている。なお、このようなログ情報に係る一のセットは、操作ごとに生成される。ログ情報データベース52内に蓄積されるログ情報は、生データであってもよいし、加工されたデータであってもよい。なお、本実施形態では、蓄積対象のログ情報は、上述のように、ゲームのプレイに関するログ情報を含む。ゲームのプレイに関するログ情報の場合、操作日時を表す情報や操作内容を表す情報は、ゲームのプレイの日時や、プレイの回数等に関する情報を含んでよい。
ログ情報取得部36は、判定対象のユーザに係るログ情報をログ情報データベース52から取得(抽出)する。判定対象のユーザは、ユーザ情報データベース50内のすべてのユーザであってもよいし、一部のユーザであってもよく、一部のユーザの場合は、当該一部のユーザは、適宜、決定されてもよい。なお、ログ情報データベース52には、上述したように、ユーザIDに紐付けられる態様でログ情報が蓄積されている。なお、ログ情報取得部36は、ユーザIDに紐付けられるログ情報のすべてを抽出してもよいし、一部(例えば特定の期間のログ情報のみ)を抽出してもよい。
指標値算出部37は、判定対象のユーザが所定期間内に所定アクションを実行しない可能性を表す指標値を算出する指標値算出処理を実行する。なお、指標値算出処理は、定期的又は不定期的に実行されてもよい。例えば、指標値算出処理は、日ごとに実行されてもよいし、それよりも長い期間ごとに実行されてもよい。所定期間は、任意であるが、好ましくは2週間から6週間の間であり、例えば1ヶ月である。所定アクションは、サイトAに関連するアクション等、任意である。例えば所定アクションは、サイトAへのログインや、サイトA内の特定ページを開くこと、Aコインの購入、Aコインの消費、ゲームアプリの起動、ゲームのプレイ、ゲーム内での所定イベントの参加、ゲームのプレイ中のアクション(例えば所定アイテムの取得や、所定ミッションをクリアするアクション)等であってよい。
本実施形態では、一例として、所定アクションは、ゲームへの参加に関するアクションであるものとする。ゲームへの参加に関するアクションとは、当該ゲームの起動や、当該ゲームのプレイ等である。
指標値算出部37は、ユーザごとに、判定対象のユーザに係るログ情報に基づいて、判定対象のユーザが所定期間内に所定アクションを実行しない確率(以下、「離脱確率」とも称する)を算出する。より具体的には、離脱確率は、判定対象のユーザが所定頻度で継続していた所定アクションを所定頻度で継続しなくなる可能性を表す。所定頻度は、例えば1ヶ月にM回以上といった頻度であり、この場合、例えばM回は、1回であってもよいし、2回以上であってもよい。
本実施形態では、指標値算出部37は、所定アクションに関するログ情報に基づいて、離脱確率を算出する。所定アクションに関するログ情報は、例えば、所定アクションを行ったか否かを表す。ただし、変形例では、所定アクションに関するログ情報とともに、所定アクションに関連するログ情報や、他のログ情報(例えば他のゲームに関するログ情報)が利用されてもよい。
ここで、所定アクションに関するログ情報と離脱確率との間には比較的高い相関性がある。従って、かかる相関性を利用して、所定アクションに関するログ情報に基づいて離脱確率を算出できる。なお、この場合、人工知能を利用して、ログ情報を入力して離脱確率を出力(算出)することも可能である。人工知能の場合は、機械学習により得られる畳み込みニューラルネットワークを実装することで実現できる。機械学習では、例えば、多数のユーザのログ情報に係る実績データを用いて、誤差が最小になるような畳み込みニューラルネットワークの重み等が学習されてよい。なお、ここでいう誤差とは、所定期間内に所定アクションを実行しなくなったユーザに係る、当該所定期間よりも前のログ情報に基づいて、比較的低い離脱確率を出力することと、所定期間内に所定アクションを実行するに至ったユーザに係る、当該所定期間よりも前のログ情報に基づいて、比較的高い離脱確率を出力することとを含む。
また、本実施形態では、指標値算出部37は、所定アクションに関するログ情報に加えて、後述する特定イベントに関するログ情報に基づいて、離脱確率を算出してもよい。特定イベントに関するログ情報は、例えば、特定イベントに参加したか否か(又は等価的に、所定特典を利用したか否か)を表す。また、特定イベントに関するログ情報は、特定イベントに参加したか否かを表す情報に加えて、特定イベントで得た報酬の内容を表す情報を含んでよい。特定イベントは、後述するように、ユーザが今後所定アクションを行うように促進する効果を有する。従って、特定イベントに参加したユーザ、又は、当該特定イベントで相当の報酬を得たユーザは、今後所定アクションを行う可能性が高いことが期待される。このため、指標値算出部37は、特定イベントに参加したユーザ、又は、当該特定イベントで相当の報酬を得たユーザについては、離脱確率を低めに算出(補正)してもよい。ただし、特定イベントの参加が所定アクションの実行を常に伴う場合(例えば所定アクションが任意のイベントに参加するアクションを含む場合)は、この限りではない。
指標値算出部37は、上述のようにして指標値(離脱確率)を算出すると、指標値データベース54内の指標値データを更新する。図7に示す例では、指標値データベース54内には、ユーザごとに、各種の離脱確率が記憶されている。各種の離脱確率は、N(N=1、…、60)日後の離脱確率(以下、単に「離脱確率PN」とも称する)である。離脱確率PNは、本日からN日後においてその日から所定期間内に所定アクションを実行しない確率(離脱確率)を表す。このように、指標値算出部37は、複数のNについて、離脱確率PNを算出してもよい。この場合、よりきめ細やかに離脱確率を算出できるので、継続促進機能の有効性を高めることができる。
グループ化部38は、指標値算出部37により算出された離脱確率に基づいて、各ユーザを、離脱確率に応じてグループ化するグループ化処理を行う。本実施形態では、一例として、グループ化部38は、後述の最も優先して所定特典(又は最も有利な効果を発生させる所定特典)を付与すべきユーザ群を、“グループA”にグループ化し、次に優先して所定特典を付与すべきユーザ群を、“グループB”にグループ化し、所定特典を付与する必要性が低いユーザ群を、“グループX”にグループ化するものとする。この場合、グループA、B、Xの順で、優先順位が高いものとする。
図8に示す例では、3日後離脱確率が最も高いユーザID“7”から“10”が“グループA”とされている。なお、グループ化の方法は、任意であり、例えば、離脱確率PNのいずれかが所定閾値Th1(例えば80%)を超えるユーザを、“グループA”にグループ化し、他のユーザを“グループX”にグループ化してもよい。また、グループ数も任意であり、3つ以上のグループに分けてもよい。例えば、60日後離脱確率が所定閾値Th2(例えば70%)を超えるユーザを、“グループB”にグループ化してもよい。この場合、一のユーザが2種類以上のグループに属するようにグループ化処理が実行されてもよい。なお、2種類以上のグループに属するようにグループ化されたユーザは、最も優先順位の高いグループに属するものとして扱われてよい。
特典付与部39は、指標値算出部37により算出された離脱確率に基づいて、特定ユーザに所定特典を付与する。所定特典は、ゲーム内で有利となるような任意の特典である。例えば、所定特典は、ゲーム内で使用可能な特定のゲーム媒体を獲得できる特典や、同特定のゲーム媒体が獲得しやすくなる特典や、特定イベント(後述)に参加できる特典、特定イベントに参加しやすくなる特典(参加条件が緩くなる特典)等であってよい。特定のゲーム媒体は、例えば、ゲーム内で有利な効果を発生させることができるゲーム媒体であり、体力値や攻撃力の比較的高いゲーム媒体やアイテム等の形態や、特殊なスキルを有するゲーム媒体の形態、レアリティの比較的高いゲーム媒体の形態等であってよい。従って、特定のゲーム媒体を獲得できると、当該特定のゲーム媒体をゲームで使用することで、使用しない場合に比べてゲーム内で有利になる。
本実施形態では、一例として、所定特典は、特定イベントに参加できる特典であるものとする。すなわち、特典付与部39は一の特定ユーザに所定特典を付与することは、実質的には、当該特定ユーザが参加可能な特定イベントを特定イベント発生部40が発生させることに対応する。
また、所定特典は、特定イベントにおいて取得可能な報酬の数や価値が増加することであってよい。例えば、所定特典は、報酬の取得の難易度(取得条件の厳しさ)は変わらないが、取得できる報酬の最大数が増加することであってもよい。
なお、変形例では、所定特典は、特定イベントにおいて有利となる効果を発生させる特典あってもよい。特定イベントにおける有利となる効果は、特定イベントの属性に応じて決定されてもよい。例えば、特定イベントが、特定のゲーム媒体が取得可能となるイベントである場合、特定イベントにおける有利となる効果は、特定のゲーム媒体が取得しやすくなる効果であってよい。例えば、特定のゲーム媒体がクエストをクリアすることで得られる報酬の形態である場合、クエストをクリアしやすくなる効果であってよい。具体的には、この場合、所定特典は、例えば、クエストのクリアに必要な又は有用なアイテムが付与されることや、特別なスキルや能力が付与されること等であってもよい。また、特定イベントが特別なガチャを回すことができるイベントである場合、特定イベントにおける有利となる効果は、特別なガチャで排出される特別なゲーム媒体の価値が高くなる効果や、特別なガチャで特別なゲーム媒体が排出される確率が増加する効果等であってもよい。
また、他の変形例では、所定特典は、ゲーム内のプレイやガチャ、課金等とは無関係な特典であってもよい。この場合、例えば所定特典は、ログインボーナスの形態、デイリーボーナスの形態、又はその類の形態であってもよい。ログインボーナスとは、所定の期間(1日)毎に、ログインした場合、与えられる報酬を指す。例えば、ログインボーナスは、ゲーム内で使用可能な特定のゲーム媒体を付与することや、Aコインを付与すること等であってよい。デイリーボーナスは、1日ごとに又は所定日数(2日以上)ごとに1回又は所定回獲得できる報酬である。なお、デイリーボーナスの場合は、ログインボーナスとは異なり、ログイン時ではなく、ユーザが任意に獲得する操作を行うと報酬が与えられる。デイリーボーナスに係る報酬は、ログインボーナスの場合と同様、ゲーム内で使用可能な特定のゲーム媒体や、Aコイン等であってよい。Aコインを付与することは、Aコインの消費によってゲーム内で使用可能な特定のゲーム媒体を取得できることを可能とするので、間接的に“ゲーム内で有利となる特典”である。なお、所定特典が特定イベントと無関係である場合、後述する特定イベント発生部40は省略されてもよい。なお、更なる他の変形例では、所定特典は、このような各種の特典が適宜選択的に利用されてもよい。
なお、所定特典は、有効期限(使用制限)があってもよいし、有効期限(使用制限)がなくてもよい。例えば、所定特典は、後述の特定イベントであって、直近の一の特定イベントに対してのみ有効な特典であってもよいし、その後の任意の特定イベントに対しても有効な特典であってもよい。なお、所定特典は、典型的には、1度利用することで消滅する特典(すなわち1つの特定イベントに参加できる特典)である。ただし、所定特典は、複数の特定イベントに参加できるような特典であってもよい。
特典付与部39は、指標値算出部37により算出された各ユーザの離脱確率に基づいて、各ユーザのうちから、特定ユーザを決定する。この際、特典付与部39は、各ユーザの離脱確率に基づいて、離脱確率が高いユーザほど特定ユーザに決定されやすくなる態様で、各ユーザのうちから、特定ユーザを決定する。例えば、特典付与部39は、離脱確率が所定閾値Th3以上のユーザを、特定ユーザとして決定してもよい。所定閾値Th3は、一定値であってもよいし、可変値であってもよい。また、所定閾値Th3は、離脱確率PNに係る“N”に応じて異なってもよい。1年後における離脱確率P365に対する所定閾値Th3と、30日後における離脱確率P30に対する所定閾値Th3は、離脱を効果的に抑制する観点からは異ならせてもよい。あるいは、特典付与部39は、離脱確率が高い順に所定数のユーザを、特定ユーザとして決定してもよい。
また、特典付与部39は、グループ化部38によりグループ化されたグループに基づいて、特定ユーザを決定してもよい。この場合、特典付与部39は、“グループA”に属するユーザを、特定ユーザとして決定してもよい。あるいは、特典付与部39は、“グループA”及び“グループB”に属するユーザを、特定ユーザとして決定してもよい。この場合、特典付与部39は、“グループA”に属するユーザ(所定ユーザの一例)に、“グループB”に属するユーザ(他のユーザの一例)よりも有利な所定特典を付与してもよい。
特定イベント発生部40は、定期的又は不定期的に、特定イベントを発生させる。本実施形態では、特定イベントは、所定特典が付与された特定ユーザのみが参加できるイベントであってよい。特定イベントは、好ましくは、特定ユーザのみに通知(後述の通知部41による通知)が行われる非公開タイプであってよい。この場合、所定特典が付与されないユーザ(特定ユーザ以外のユーザ)に対して配慮することができる。なお、変形例では、特定イベントは、特定ユーザ以外の一部のユーザ(ただし、全員ではなく、例えば参加条件を満たすユーザ)が参加できるイベントであってよい。
特定イベントが発生されると、対応する特定ユーザは、当該特定イベントに参加可能となる。特定イベントは、特別なカードやアイテムが取得可能なボーナスステージを備えるゲームパート(イベント)や、特別なガチャを回せるイベント等のような、任意の属性であってよい。
例えば、特定イベント発生部40は、特定ユーザに紐付けられたゲーム画面に、特定イベントに係る参加ボタン(図示せず)を発生させる。この場合、参加ボタンは、特定イベントを発生させる前から出力されてもよい。この場合、特定イベントの発生期間中(すなわち開催期間中)にのみアクティブになり、ユーザにより操作可能となる。参加ボタンが操作されると、特定イベントへの参加が開始される。
本実施形態では、一例として、特定イベントは、報酬(特定のゲーム媒体)を取得できるボーナスステージを備えるゲームパートであり、報酬の相違に応じて複数種類あるものとする。具体的には、特定イベントは、かなり良い報酬が得られるボーナスステージAを含むイベントと、良い報酬が得られるボーナスステージBを含むイベントと、普通の報酬(ただし、通常イベントで得られる報酬よりも良い報酬)が得られるボーナスステージCを含むイベントと、いった具合に、報酬の相違に応じて複数種類存在する。
ここで、本明細書において報酬の良し悪しについては、報酬の属性に応じて異なるが、例えば報酬がAコインである場合は、量が多いほど良い報酬となる。また、報酬が特定のゲーム媒体である場合、得られる特定のゲーム媒体の数が同じであるときは、得られる特定のゲーム媒体の価値が高いほど良い報酬となり、得られる特定のゲーム媒体の価値が同じであるときは、得られる特定のゲーム媒体の数が多いほど良い報酬となる。
この場合、特典付与部39は、離脱確率が高い特定ユーザほどボーナスステージAに参加しやすくなる態様で、各特定ユーザに対して参加可能な特定イベント(所定特典)の種類を決定する(割り当てる)。例えば、“グループA”に属するユーザが参加可能な特定イベントは、ボーナスステージAを含むイベントであり、“グループB”に属するユーザが参加可能な特定イベントは、ボーナスステージBを含むイベントである、といった具合である。なお、変形例では、各ボーナスステージAからCで得られる最大の報酬は、同じであるが、報酬の取得確率が異なってもよい。すなわち、ボーナスステージAで取得確率が一番高く、ボーナスステージB、Cとなるにつれて取得確率が低下する形態であってもよい。この場合、例えば、“グループA”に属するユーザに課される報酬の取得条件が、“グループB”に属するユーザに課される報酬の取得条件よりも緩く設定され、“グループB”に属するユーザに課される報酬の取得条件は、“グループC”に属するユーザに課される報酬の取得条件よりも緩く設定される。これにより、“グループA”に属するユーザは、“グループB”に属するユーザよりも特定のゲーム媒体を取得しやすくなり、“グループB”に属するユーザは、“グループC”に属するユーザよりも特定のゲーム媒体を取得しやすくなる。
特定イベントは、設定された開催期間(例えばその日、一日)中はいつでも参加可能とされる。開催期間を比較的長く設定する場合、事前の告知(通知)によって参加率を効果的に高めることができる。この場合、特定ユーザごとに開催期間が異なってもよいし、グループごとに共通の開催期間が設定されてもよいし、すべての特定ユーザに対して共通の開催期間が設定されてもよい。また、特定イベントは、通常イベントに付随する態様で発生されてもよいし、通常イベントとは無関係に発生されてもよい。また、開催時期は、複数の期間にわたって設定されてもよい(すなわち特定イベントが複数回セットで設定されてもよい)。
通知部41は、特定イベントへの招待のための通知(開催通知)を、特定ユーザに対してのみ実行する。通知は、例えばプッシュ通知や、サイトAでの通知、対応する電話番号へのショートメッセージ、対応するメールアドレスへのメール等により実現されてもよい。また、通知は、対応する電話番号にコールセンター等からオペレータ(人)が電話をかけることや、対応付けられた電話番号を発呼して自動音声を流すこと等により実現されてもよい。
なお、通知部41は、好ましくは、サイトAでの通知に加えて又は代えて、サイトAを利用しない通知(例えば、上述した対応する電話番号へのショートメッセージ等)を行う。これにより、サイトAにログインしない特定ユーザにも、特定イベントの開催を伝えることが容易となる。
ユーザ情報データベース50には、上述のように、ユーザ情報(図4参照)が格納される。
ログ情報データベース52には、上述のように、ユーザごとにログ情報(図6参照)が格納される。ログ情報データベース52内のログ情報は、上述のように、随時更新される。なお、ログ情報データベース52内のログ情報は、格納されてから比較的長い期間経過した後は、破棄されてもよいし、別のデータベースに移管されてもよい。
指標値データベース54には、上述のように、各指標値(算出結果)(図7参照)が格納される。
特定イベントデータベース56には、上述のように、特定イベントに関する情報が記憶される。図9に示す例では、特定イベントに関する情報は、特定イベントIDごとに、特定イベントに招待された特定ユーザのユーザID(1つ以上のユーザID)と、報酬内容と、終了条件とを含む。報酬内容は、報酬の内容のみならず、報酬の取得条件等を含んでもよい。終了条件は、開催時期の終了時点が到来した場合であってもよい。あるいは、終了条件は、特定ユーザごとに、参加した特定ユーザに対してのみ当該参加により成立してもよい。なお、本実施形態では、一例として、各特定イベントIDに係る特定イベントの開催時期は、毎日であるものとする。
本実施形態では、一例として、特定イベントIDは、3種類であり、特定イベントID“000A”は、グループAに属する各特定ユーザが参加可能な特定イベントを表し、特定イベントID“000B”は、グループBに属する各特定ユーザが参加可能な特定イベントを表し、特定イベントID“000C”は、グループCに属する各特定ユーザが参加可能な特定イベントを表す。
このように、本実施形態によれば、各ユーザのログ情報に基づいて各ユーザの離脱確率が算出され、各ユーザの離脱確率に基づいて特定ユーザに所定特典が付与され、所定特典が付与されたユーザのみが特定イベントに参加可能となる。この際、離脱確率が比較的高いユーザが特定ユーザとして決定されるので、離脱確率が比較的高いユーザに、所定特典を付与することができる。離脱確率が比較的高いユーザに所定特典を付与することで、当該ユーザに対してゲームのプレイを継続する動機付けを与えることができる。すなわち、ユーザは、付与された所定特典に魅力を感じると、所定特典に係る利益(特定イベントで得られる報酬)を享受することで、再びゲームのプレイの楽しさを感じ、ゲームのプレイを継続する意欲が湧く可能性がある。このようにして、本実施形態による継続促進機能によって、離脱確率が比較的高いユーザにゲームのプレイを継続する動機付けを与えることができる。
なお、本実施形態は、上述のように、所定特典は、特定イベントに参加できる特典であるが、所定特典が上述したような他の特典である場合であっても、上述した同様の効果が奏される。
また、本実施形態によれば、特定ユーザ(すなわち、離脱確率が比較的高いユーザ)に対してだけ選択的に上記のような処理を実施することにより、全ユーザに対して同様の処理を実施することに比較して、サーバ装置10の処理負荷を低減しつつ、ユーザのゲームのプレイを継続する動機づけを与えることができる。
また、本実施形態によれば、上述したように、グループ化部38は、最も優先して所定特典(又は最も有利な効果を発生させる所定特典)を付与すべきか否かの観点からグループ化処理を行う。従って、本実施形態では、例えば、1日後の離脱確率P1が50%のユーザ群と、1週間後の離脱確率P7が90%のユーザ群とが、同一のグループにグループ化される場合がありうる。これは、期間(離脱確率PNに係る“N”)が異なっても離脱の潜在的な可能性としては同等に扱えるグループが存在すると考えられためである。これにより、グループ数を不要に多くすることを抑制でき、処理負荷を低減できる。特に、グループごとに所定特典の種類を異ならせる場合は、グループ数が増加するほど処理負荷(又は設計負荷)が高くなるが、本実施形態によれば、かかる負荷を効率的に低減できる。ただし、変形例では、グループ化部38は、異なるグループに属する特定ユーザに同一の所定特典が付与されうる態様で、グループ化処理を行ってもよい。
なお、本実施形態では、指標値算出部37は、上述のように、特定ユーザが、所定特典を付与されかつ当該所定特典に係る利益を享受すると(すなわち特定イベントに参加し報酬を得ると)、当該特定ユーザに係る離脱確率を比較的低い値に更新する。これは、特定ユーザが所定特典に係る利益を享受すると、所定期間内に所定アクションを実行する可能性が高くなるためである。換言すると、所定特典による効果(すなわち特定イベントで得られる報酬)は、好ましくは、ユーザが再び所定期間内に所定アクションを実行したくなるように適合される。具体的には、ボーナスステージA、B、C等で得られる報酬は、好ましくは、次回以降の通常イベントで利用可能でありかつ利用時に有利な効果をもたらすものであってよい。例えば、報酬は、次回又はそれ以降の通常イベントで有利な効果をもたらすカードやアイテム等のような特定のゲーム媒体である。これにより、ボーナスステージA、B、C等で報酬を得たユーザによる次回又はそれ以降の通常イベントへの参加が効果的に促進される。なお、変形例では、ボーナスステージA、B、C等で得られる報酬は、任意の通常イベントで利用可能であってもよい。例えば、その時点で開催中の通常イベントがある場合、ボーナスステージA、B、C等で得られる報酬は、現在開催最中の通常イベント(今回の通常イベント)で利用可能でありかつ利用時に有利な効果をもたらすものであってもよい。
ここで、本実施形態では、上述したように、離脱確率は、離脱確率PNとして複数種類算出される。この場合、よりきめ細やかに離脱確率を算出できるので、継続促進機能の有効性を高めることができる。すなわち、離脱確率PNに応じて所定特典を変化させることで、所定特典を与える必要性の比較的低いユーザに過剰な所定特典を与えることなく、所定特典を与える必要性の比較的高いユーザに対してのみ適切な所定特典を与えることができる可能性を、高めることができる。また、ゲーム内のユーザに関するパラメータの過剰なインフレーションの抑制や、適切なゲームバランスの維持などを図ることもできる。
例えば、図10Aに示す例では、グループ化部38は、各ユーザを、4つのグループであるグループA、B、C、Xに分けている。グループAは、“明日から離脱するユーザ群”として、1日後の離脱確率P1が所定閾値Th4(例えば95%)以上であるユーザが属し、グループBは、“1週間後に離脱するユーザ群”として、7日後の離脱確率P7(すなわち1週間後の離脱確率P7)が所定閾値Th5(例えば95%又は所定閾値Th4未満)以上であるユーザが属し、グループCは、“1ヶ月後に離脱するユーザ群”として、30又は31日後の離脱確率P30又はP31(すなわち1ヶ月後の離脱確率P30又はP31)が所定閾値Th6(例えば95%又は所定閾値Th5未満)以上であるユーザが属し、グループXは、“1ヶ月後も離脱しないユーザ群”として、その他のユーザが属する。この場合、グループA、B、Cに属する各ユーザが特定ユーザとして決定され、所定特典が付与される。ただし、グループAに属するユーザに付与される所定特典は、グループBに属するユーザに付与される所定特典よりももたらす効果が有利であり、グループBに属するユーザに付与される所定特典は、グループCに属するユーザに付与される所定特典よりももたらす効果が有利である。これにより、離脱確率が同じである場合でも、離脱確率PNのNが小さくなるにつれて(すぐに緊急性が高くなるにつれて)段階的に所定特典がもたらす効果を高めることで、所定特典を与える必要性の比較的低いユーザに過剰な所定特典を与えることなく、所定特典を与える必要性の比較的高いユーザに対してのみ適切な所定特典を与えることができる可能性を、高めることができる。また、ゲーム内のユーザに関するパラメータの過剰なインフレーションの抑制や、適切なゲームバランスの維持などを図ることもできる。
また、図10Bに示す例では、図10Aに示す例と同様、グループ化部38は、各ユーザを、4つのグループであるグループA、B、C、Xに分けている。ただし、図10Bに示す例では、図10Aに示す例とは異なり、所定特典は、ログインボーナスの形態である。この場合、グループAに属するユーザに付与されるログインボーナスは、例えば7日間だけ有効であり、グループBに属するユーザに付与されるログインボーナスは、例えば30日間だけ有効であり、グループCに属するユーザに付与されるログインボーナスは、例えば50日間だけ有効である。なお、グループXに属するユーザには、かかるログインボーナスは付与されない。このような態様によっても、特定ユーザ(グループAからCに属するユーザ)に対してゲームのプレイを継続する動機付けを与えることができる。
次に、図11以降を参照して、サーバ装置10による継続促進処理に関連する動作例について説明する。以降の処理フロー図(フローチャート)においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。
図11は、サーバ装置10による継続促進処理に関連する処理の一例を示す概略フローチャートである。
ステップS111では、サーバ装置10の指標値算出部37は、離脱確率の更新タイミングが到来したか否かを判定する。離脱確率の更新タイミングは、任意であるが、ここでは、一日の開始時点(0時0分)であるものとする。判定結果が“YES”の場合、ステップS112に進み、それ以外の場合は、ステップS117に進む。
ステップS112では、サーバ装置10のログ情報取得部36及び指標値算出部37は、協動して、ユーザ情報データベース50内の各ユーザに係る離脱確率の算出処理を実行する。離脱確率の算出処理の一例は、図12を参照して後述する。
ステップS113では、サーバ装置10のグループ化部38は、指標値データベース54内のデータに基づいて、グループ化処理を実行する。グループ化処理の一例は、図13を参照して後述する。
ステップS114では、サーバ装置10の特典付与部39は、ステップS113のグループ化処理の結果に基づいて、特定ユーザに対して所定特典を付与する特典付与処理を実行する。特典付与処理の一例は、図14を参照して後述するが、特定イベントデータベース56内のデータの更新を伴う。
ステップS115では、サーバ装置10の通知部41は、ステップS114での特典付与処理の結果に基づいて、通知処理を行う。具体的には、特定イベントID“000A”に紐付けられた各特定ユーザには、当該特定イベントID“000A”に係る特定イベントの発生を通知し、特定イベントID“000B”に紐付けられた各特定ユーザには、当該特定イベントID“000B”に係る特定イベントの発生を通知し、以下同様である。なお、通知方法は、上述したとおりである。なお、上述のような各種通知は、その属性に応じて適宜繰り返し実行されてもよい。例えば、サイトAでの通知は、特定ユーザのログイン状況に応じて、特定ユーザがサイトAにログインした際に実行されてもよいし、他のタイミングで実行されてもよい。また、特定ユーザがサイトAにログインしない場合に、メールによる通知を行うといった具合に、複数の通知方法を適宜使い分けることも可能である。
ステップS116では、サーバ装置10の特定イベント発生部40は、各特定イベントID(“000A”、“000B”、及び“000C”)に係る特定イベントを、対応する特定ユーザのみが参加可能な態様(例えば対応する特定ユーザのみに係る端末装置20上に、参加ボタンが描画される態様)で、発生させる。
ステップS117では、サーバ装置10の課金処理部32は、適宜、課金処理を行う。
ステップS118では、サーバ装置10のゲーム処理部31は、各種のゲーム処理を行う。この際、ゲーム処理部31は、特定イベントに参加した特定ユーザに対しては、当該特定ユーザに係る端末装置20からの操作情報に基づいて、特定イベントに関するゲーム処理を行う。ゲーム処理部31は、特定イベントデータベース56内のデータに基づいて、一の特定ユーザによる特定イベントの参加が所定回数Npだけ許可されるように、特定イベントへの参加要求を処理する。例えば、特定イベントID“000A”に係る特定イベントへの参加要求を受信すると、参加要求を行ったユーザIDが、特定イベントID“000A”に対応付けられているか否かをチェックし、対応付けられている場合は、所定回数Npまで参加を許可する。所定回数Npは、1以上であり、固定値であってよいし、特定イベントの属性に応じて変化してもよい。
ステップS119では、サーバ装置10のユーザ登録部30は、適宜、ユーザ登録処理を行う。
ステップS120では、サーバ装置10のログ情報蓄積部34は、最新のログ情報をログ情報データベース52内に蓄積する。
図12は、離脱確率の算出処理(図11のステップS112)の一例を示す概略フローチャートである。
ステップS202では、ログ情報取得部36は、ユーザ情報データベース50内の各ユーザのうちから、所定順序で一のユーザを選択する。
ステップS204では、ログ情報取得部36は、ステップS202で選択したユーザに係るログ情報を、ログ情報データベース52から抽出(取得)する。
ステップS206では、指標値算出部37は、ステップS204で抽出されたログ情報に基づいて、選択したユーザに係る指標値、すなわち離脱確率を算出する。なお、離脱確率は、上述のように、離脱確率PNとして複数のNに対して算出される。
ステップS208では、指標値算出部37は、ステップS206で算出した離脱確率PN(選択したユーザに係る離脱確率PN)を指標値データベース54内に記憶(更新)する。
ステップS210では、ユーザ情報データベース50内のすべてのユーザを選択したか否かを判定する。判定結果が“YES”の場合、終了し、それ以外の場合は、ステップS212を介してステップS204からの処理を繰り返す。
ステップS212では、ログ情報取得部36は、ユーザ情報データベース50内の各ユーザのうちから、所定順序で次の一のユーザ(新たな一のユーザ)を選択する。
図13は、グループ化処理(図11のステップS113)の一例を示す概略フローチャートである。
ステップS302では、グループ化部38は、ユーザ情報データベース50内の各ユーザのうちから、1日後の離脱確率P1が所定閾値Th4(例えば95%)以上であるユーザを抽出する。
ステップS304では、グループ化部38は、“明日から離脱するユーザ群”として、ステップS302で抽出した各ユーザを、グループAにグループ化する。
ステップS306では、グループ化部38は、ユーザ情報データベース50内の各ユーザのうちの、グループAにグループ化されたユーザを除く各ユーザのうちから、7日後の離脱確率P7が所定閾値Th5(例えば95%又は所定閾値Th4未満)以上であるユーザを抽出する。
ステップS308では、グループ化部38は、“1週間後に離脱するユーザ群”として、ステップS306で抽出した各ユーザを、グループBにグループ化する。
ステップS310では、グループ化部38は、ユーザ情報データベース50内の各ユーザのうちの、グループA又はグループBにグループ化されたユーザを除く各ユーザのうちから、30又は31日後の離脱確率P30又はP31(すなわち1ヶ月後の離脱確率P30又はP31)が所定閾値Th6(例えば95%又は所定閾値Th5未満)以上であるユーザを抽出する。
ステップS312では、グループ化部38は、“1ヶ月後に離脱するユーザ群”として、ステップS310で抽出した各ユーザを、グループCにグループ化する。
ステップS314では、グループ化部38は、ユーザ情報データベース50内の各ユーザのうちの、残りの各ユーザを、グループXにグループ化する。なお、ステップS314は省略されてもよい。
図14は、特典付与処理(図11のステップS114)の一例を示す概略フローチャートである。
ステップS400では、特典付与部39は、グループAに属する各ユーザを、グループAに係る特定ユーザとして決定する。
ステップS402では、特典付与部39は、グループAに係る特定ユーザに、グループAに係る所定特典を付与する。具体的には、特典付与部39は、特定イベントデータベース56において、特定イベントID“000A”に、グループAに係る特定ユーザの各ユーザIDを対応付ける。これにより、グループAに係る特定ユーザは、特定イベントID“000A”に係る特定イベント(ステップS116で発生された特定イベントID“000A”に係る特定イベント)に参加可能となる。
ステップS404では、特典付与部39は、グループBに属する各ユーザを、グループBに係る特定ユーザとして決定する。
ステップS406では、特典付与部39は、グループBに係る特定ユーザに、グループBに係る所定特典を付与する。具体的には、特典付与部39は、特定イベントデータベース56において、特定イベントID“000B”に、グループBに係る特定ユーザの各ユーザIDを対応付ける。これにより、グループBに係る特定ユーザは、特定イベントID“000B”に係る特定イベント(ステップS116で発生された特定イベントID“000B”に係る特定イベント)に参加可能となる。
ステップS408では、特典付与部39は、グループCに属する各ユーザを、グループCに係る特定ユーザとして決定する。
ステップS410では、特典付与部39は、グループCに係る特定ユーザに、グループCに係る所定特典を付与する。具体的には、特典付与部39は、特定イベントデータベース56において、特定イベントID“000C”に、グループCに係る特定ユーザの各ユーザIDを対応付ける。これにより、グループCに係る特定ユーザは、特定イベントID“000C”に係る特定イベント(ステップS116で発生された特定イベントID“000C”に係る特定イベント)に参加可能となる。
このようにして、図11から図14に示す処理によれば、所定時間ごと(本例では一日ごと)に離脱確率PNが算出(更新)されるので、所定時間ごとに、特定イベントへの各特定ユーザの参加状況に係るログ情報を、離脱確率PNの算出結果に反映させることができる。これにより、離脱確率PNの算出結果の精度を高め、上述した継続促進処理の実効性を高めることができる。
なお、図11から図14に示す処理において、特定イベントID“000B”又は特定イベントID“000C”に係る特定イベントに参加した特定ユーザに関する離脱確率PNは、当該参加に起因して減少されるので、複数種類の特定イベントに参加できる可能性は低い。すなわち、特定イベントID“000C”に参加した特定ユーザは、特定イベントID“000A”及び特定イベントID“000B”に係る特定イベントへの参加が抑制され、特定イベントID“000B”に参加した特定ユーザは、特定イベントID“000A”に係る特定イベントへの参加が抑制される。
この点、特定イベントID“000A”に係る特定イベントに1回だけ参加することで得られる報酬に対して、特定イベントID“000B”又は特定イベントID“000C”に係る特定イベントに1回だけ参加することで得られる報酬が有意に低い場合、不公平感が生じるおそれがある。
従って、かかる不公平感が生じないように、所定特典は、特定イベントID“000B”又は特定イベントID“000C”に係る特定イベントに複数日連続して参加できる特典とされてもよい。例えば、グループBに属する特定ユーザに付与される所定特典は、特定イベントID“000B”に係る特定イベントに7日間連続して参加できる特典であってもよい。この場合、7日間、特定イベントID“000B”に係る特定イベントに毎日参加することで得られる全体としての報酬は、特定イベントID“000A”に係る特定イベントに1回だけ参加することで得られる報酬に対して、有意に良好(例えば、報酬として得られる特定のゲーム媒体についてその数やその価値の増加)であってもよい。これにより、グループBに属する特定ユーザが、特定イベントID“000B”に係る特定イベントに毎日参加した場合と、グループAに属する特定ユーザが、特定イベントID“000A”に係る特定イベントに1日だけ参加した場合とで、後者の場合の方が報酬が良好となることによる不公平感を、なくすことができる。すなわち、早めの特定イベントの参加を促進し、上述した継続促進処理の実効性を高めることができる。ただし、変形例では、7日間、特定イベントに毎日参加することで得られる全体としての報酬は、特定イベントID“000A”に係る特定イベントに1回だけ参加することで得られる報酬に対して、同じであってもよいし、有意に劣ってもよい。
同様に、グループCに属する特定ユーザに付与される所定特典は、特定イベントID“000C”に係る特定イベントに30日間又は31日間連続して参加できる特典であってもよい。この場合、30日間又は31日間、特定イベントID“000C”に係る特定イベントに毎日参加することで得られる全体としての報酬は、特定イベントID“000A”に係る特定イベントに1回だけ参加することで得られる報酬及び特定イベントID“000B”に係る特定イベントに7回だけ参加することで得られる報酬に対して、有意に良好であってもよい。これにより、グループCに属する特定ユーザが、特定イベントID“000C”に係る特定イベントに毎日参加した場合と、グループAに属する特定ユーザが、特定イベントID“000A”に係る特定イベントに1日だけ参加した場合又はグループBに属する特定ユーザが特定イベントID“000B”に係る特定イベントに毎日参加した場合とで、後者の場合の方が報酬が良好となることによる不公平感を、なくすことができる。すなわち、早めの特定イベントの参加を促進し、上述した継続促進処理の実効性を高めることができる。ただし、変形例では、30日間又は31日間、特定イベントに毎日参加することで得られる全体としての報酬は、特定イベントID“000A”に係る特定イベントに1回だけ参加することで得られる報酬又は特定イベントID“000B”に係る特定イベントに7回だけ参加することで得られる報酬に対して、同じであってもよいし、有意に劣ってもよい。
また、早めの特定イベントの参加を促進するために、特定イベントID“000B”又は特定イベントID“000C”に係る特定イベントに参加した特定ユーザに関する離脱確率PNは、当該参加に起因して減少されるものの、その減少量は比較的少なくされてもよい。例えば、特定イベントID“000C”に係る特定イベントに参加することに起因した離脱確率PNの減少量は、特定イベントID“000B”に係る特定イベントに参加することに起因した離脱確率PNの減少量よりも有意に小さく、特定イベントID“000B”に係る特定イベントに参加することに起因した離脱確率PNの減少量は、特定イベントID“000A”に係る特定イベントに参加することに起因した離脱確率PNの減少量よりも有意に小さく設定されてもよい。この場合、早めの特定イベントの参加によっても、その後の特定イベントに参加できる可能性が残り、上記のような不公平感を低減できる。
なお、図11から図14に示す処理では、グループ化処理が実行されるが、グループ化処理は、省略されてもよい。この場合、特典付与部39は、1日後の離脱確率P1が所定閾値Th4(例えば95%)以上であるユーザを、第1の特定ユーザとして決定し、当該第1の特定ユーザに係るユーザIDを、特定イベントデータベース56において、特定イベントID“000A”に対応付ける。同様に、特典付与部39は、7日後の離脱確率P7が所定閾値Th5(例えば95%又は所定閾値Th4未満)以上であるユーザを、第2の特定ユーザとして決定し、当該第2の特定ユーザに係るユーザIDを、特定イベントデータベース56において、特定イベントID“000B”に対応付ける。同様に、特典付与部39は、30又は31日後の離脱確率P30又はP31(すなわち1ヶ月後の離脱確率P30又はP31)が所定閾値Th6(例えば95%又は所定閾値Th5未満)以上であるユーザを、第3の特定ユーザとして決定し、当該第3の特定ユーザに係るユーザIDを、特定イベントデータベース56において、特定イベントID“000C”に対応付ける。
以上、各実施形態について詳述したが、特定の実施形態に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、前述した実施形態の構成要素を全部又は複数を組み合わせることも可能である。
例えば、上述した実施形態において、グループ化部38は、指標値算出部37により算出された離脱確率とともに、SNSに関する情報のような他の情報に基づいて、グループ化処理を行ってもよい。例えば、SNSに関する情報に基づいて、あるユーザと、当該ユーザとつながりが深いユーザとが、別のグループに属さないように、グループ化処理を行ってもよい。この場合、特定イベントの非公開性を維持することが容易となる。ただし、この場合、同一のグループに属する各ユーザのうち、離脱確率が低いユーザに付与される所定特典は、他のユーザほど有利な効果を生じるものでなくてよい。
また、上述した実施形態において、特典付与部39は、指標値算出部37により算出された離脱確率に加えて、他のパラメータに基づいて、特定ユーザに所定特典を付与してもよい。この場合、他のパラメータに基づいて特定ユーザの決定態様を変化させてよいし、及び/又は、他のパラメータに基づいて所定特典を変化させてよい。この場合、他のパラメータは、離脱確率の変化傾向(例えば増加傾向か低下傾向)や、課金額、所持コイン、特定イベントの参加回数(過去の参加回数)等であってもよい。また、同様の観点から、グループ化部38は、指標値算出部37により算出された離脱確率に加えて、他のパラメータに基づいて、グループ化を行ってもよい。この場合も、他のパラメータは、離脱確率の変化傾向(例えば増加傾向か低下傾向)や、課金額、所持コイン、特定イベントの参加回数(過去の参加回数)等であってもよい。
また、上述した実施形態において、端末装置20に表示される画面の少なくとも一部を、サーバ装置10が生成したデータに基づいて端末装置20に表示させるウェブ表示とし、画面の少なくとも一部を、端末装置20にインストールされているネイティブアプリケーションによって表示させるネイティブ表示としてもよい。このように、上述した実施形態に係るゲームは、サーバ装置10及び端末装置20のそれぞれが処理の一部を担うハイブリッドゲームとすることもできる。この場合、所定アクションは、サイトAに関連するアクションでなくてもよく、例えば、端末装置20におけるネイティブアプリケーションに係るアクション(例えば所定操作)であってもよい。この場合、指標値算出部37は、ネイティブアプリケーションに係るログ情報に基づいて、離脱確率を算出してもよい。また、この場合、指標値算出部37の機能の一部又は全部は、端末装置20により実現されてもよい。例えば、所定操作の実施を端末装置20上で取得して、所定操作を実施したという情報がサーバ装置10に送信され、サーバ装置10でログ情報としてログ情報データベース52内に記録されてもよい。
なお、以上の実施形態に関し、さらに以下の付記を開示する。
[付記1]
複数の登録ユーザに係るユーザ識別情報に対応付けられたログ情報を取得するログ情報取得部と、
前記登録ユーザによる操作情報に基づいて、ゲームのプレイを開始するとともにゲームを進行するゲーム処理部と、
前記登録ユーザごとに、前記ログ情報取得部により取得された前記ログ情報に基づいて、前記登録ユーザが所定期間内に所定アクションを実行しない可能性を表す指標値を算出する指標値算出部と、
前記指標値算出部により算出された前記登録ユーザごとの前記指標値に基づいて、前記複数の登録ユーザのうちの、特定ユーザに、前記ゲーム内で有利となる所定特典を付与する特典付与部とを含む、ゲーム装置。
[付記2]
前記所定アクションは、前記ゲームへの参加に関するアクション、前記ゲームのプレイ中のアクション、及び、前記ゲームに関連する所定のゲーム媒体の消費、のうちの少なくともいずれか1つを含む、付記1に記載のゲーム装置。
[付記3]
定期的又は不定期的に、前記複数の登録ユーザのうちの限定された一部の登録ユーザのみが参加可能な特定イベントを発生させる特定イベント発生部を更に含み、
前記所定特典は、前記特定イベントに参加できる特典、前記特定イベントに参加しやすくなる特典、及び、前記特定イベントにおいて有利となる効果を発生させる特典のうちの、少なくともいずれか1つを含む、付記1又は2に記載のゲーム装置。
[付記4]
前記特定イベントは、参加すると無条件に又は参加して所定の取得条件を満たすと、前記ゲームのプレイ時に利用可能な特定のゲーム媒体を取得できるイベントであり、
前記特典付与部は、前記特定イベントにおいて有利となる効果を発生させる特典として、前記所定の取得条件を緩和させる、付記3に記載のゲーム装置。
[付記5]
前記ゲーム処理部は、前記特定イベントとは異なるイベントであって、前記複数の登録ユーザが参加可能なイベントを、定期的又は不定期的に発生させ、
前記特定のゲーム媒体は、今回又は次回以降の前記イベントで利用可能でありかつ利用時に有利な効果をもたらす、付記4に記載のゲーム装置。
[付記6]
前記特典付与部は、前記複数の登録ユーザのうちから、前記可能性が所定閾値以上の登録ユーザを、前記特定ユーザとして決定する、付記1〜5のうちのいずれか1項に記載のゲーム装置。
[付記7]
前記複数の登録ユーザを、前記可能性に応じて複数のグループに分けるグループ化部を更に備え、
前記特典付与部は、前記可能性の相対的に高い第1グループに属する前記登録ユーザを、前記特定ユーザとして決定し、決定した前記特定ユーザのうちの、所定ユーザに他のユーザよりも有利な前記所定特典を付与する、付記1〜5のうちのいずれか1項に記載のゲーム装置。
[付記8]
前記指標値は、前記登録ユーザが所定頻度で継続していた前記所定アクションを前記所定頻度で継続しなくなる可能性を表す、付記1〜7のうちのいずれか1項に記載のゲーム装置。
[付記9]
前記指標値算出部は、現時点以後の複数の時点のそれぞれでの前記可能性を表す前記指標値を算出する、付記1〜8のうちのいずれか1項に記載のゲーム装置。
[付記10]
複数の登録ユーザに係るユーザ識別情報に対応付けられたログ情報を取得し、
前記登録ユーザによる操作情報に基づいて、ゲームのプレイを開始するとともにゲームを進行し、
前記登録ユーザごとに、前記ログ情報に基づいて、前記登録ユーザが所定期間内に所定アクションを実行しない可能性を表す指標値を算出し、
算出した前記登録ユーザごとの前記指標値に基づいて、前記複数の登録ユーザのうちの、特定ユーザに、前記ゲーム内で有利となる所定特典を付与することを含む、コンピュータにより実行されるゲーム方法。
[付記11]
複数の登録ユーザに係るユーザ識別情報に対応付けられたログ情報を取得し、
前記登録ユーザによる操作情報に基づいて、ゲームのプレイを開始するとともにゲームを進行し、
前記登録ユーザごとに、前記ログ情報に基づいて、前記登録ユーザが所定期間内に所定アクションを実行しない可能性を表す指標値を算出し、
算出した前記登録ユーザごとの前記指標値に基づいて、前記複数の登録ユーザのうちの、特定ユーザに、前記ゲーム内で有利となる所定特典を付与する、
処理をコンピュータに実行させるゲームプログラム。