JP6467012B1 - プログラム、制御方法、および情報処理装置 - Google Patents

Abstract

【課題】ゲーム内での設定に応じて内容が変化するメッセージの通知を実行するプログラム、制御方法、および情報処理装置を提供する。
【解決手段】記憶部（端末記憶部１８）と、通信部（端末通信部１７）と、を備え、複数のゲーム媒体を有するゲームの処理を実行する情報処理装置（端末装置１２）に、ゲーム内で、メッセージ設定情報として、複数のゲーム媒体の中の少なくとも１つおよびメッセージを受信したいタイミングを、ユーザに設定させるステップと、メッセージ設定情報を、記憶部に記憶させるステップと、記憶部に記憶されたメッセージ設定情報を、通信部を介して送信するステップと、メッセージを、通信部を介して受信するステップと、受信したメッセージをユーザに対して表示するステップと、を実行させて、メッセージを受信するタイミングおよびメッセージの内容の少なくとも一方は、メッセージ設定情報に応じて異なる。
【選択図】図１

Description

本開示は、プログラム、制御方法、および情報処理装置に関する。

アプリケーションにおけるグループのメンバーがオフライン状態である場合に、アプリケーションの起動を促すため、プッシュ通知が利用されることがある。例えば、特許文献１には、チャットグループに属するユーザ端末がオフラインとなっている場合に、プッシュ通知を送信することが記載されている。

特開２０１４−２３２４５９号公報

ゲームのアプリケーションにおいてもプッシュ通知が利用されることがある。例えば、キャラクタの画像等を伴うプッシュ通知によって、ゲーム内のイベントの開催をユーザに通知することがある。しかし、このようなプッシュ通知の内容は画一的であった。

かかる事情に鑑みてなされた本開示の目的は、ゲーム内での設定に応じて内容が変化するメッセージの通知を実行するプログラム、制御方法、および情報処理装置を提供することにある。

一実施形態に係るプログラムは、記憶部と、通信部と、を備え、複数のゲーム媒体を有するゲームの処理を実行する情報処理装置に、前記ゲーム内で、メッセージ設定情報として、前記複数のゲーム媒体の中の少なくとも１つおよびメッセージを受信したいタイミングを、ユーザに設定させるステップと、前記メッセージ設定情報を、前記記憶部に記憶させるステップと、前記記憶部に記憶された前記メッセージ設定情報を、前記通信部を介して送信するステップと、前記メッセージを、前記通信部を介して受信するステップと、受信した前記メッセージを前記ユーザに対して表示するステップと、を実行させて、前記メッセージを受信するタイミングおよび前記メッセージの内容の少なくとも一方は、前記メッセージ設定情報に応じて異なる。

一実施形態に係る制御方法は、記憶部と、通信部と、を備え、複数のゲーム媒体を有するゲームの処理を実行する情報処理装置の制御方法であって、前記ゲーム内で、メッセージ設定情報として、前記複数のゲーム媒体の中の少なくとも１つおよびメッセージを受信したいタイミングを、ユーザに設定させるステップと、前記メッセージ設定情報を、前記記憶部に記憶させるステップと、前記記憶部に記憶された前記メッセージ設定情報を、前記通信部を介して送信するステップと、前記メッセージを、前記通信部を介して受信するステップと、受信した前記メッセージを前記ユーザに対して表示するステップと、を含み、前記メッセージを受信するタイミングおよび前記メッセージの内容の少なくとも一方は、前記メッセージ設定情報に応じて異なる。

一実施形態に係る情報処理装置は、複数のゲーム媒体を有するゲームの処理を実行する情報処理装置であって、記憶部と、通信部と、制御部と、を備え、前記制御部は、前記ゲーム内で、メッセージ設定情報として、前記複数のゲーム媒体の中の少なくとも１つおよびメッセージを受信したいタイミングを、ユーザに設定させて、前記メッセージ設定情報を、前記記憶部に記憶させて、前記記憶部に記憶された前記メッセージ設定情報を、前記通信部を介して送信し、前記メッセージを、前記通信部を介して受信し、受信した前記メッセージを前記ユーザに対して表示し、前記メッセージを受信するタイミングおよび前記メッセージの内容の少なくとも一方は、前記メッセージ設定情報に応じて異なる。

本開示によれば、ゲーム内での設定に応じて内容が変化するメッセージの通知を実行するプログラム、制御方法、および情報処理装置が提供可能である。

一実施形態に係る情報処理装置を備えるゲームシステムを説明する図である。 ユーザに関する情報を例示する図である。 所有するカードの情報を例示する図である。 メッセージ設定情報を例示する図である。 メッセージ設定画面の一例を示す図である。 図４のメッセージ設定情報に対応するメッセージを例示する図である。 メッセージ設定情報の別の例を示す図である。 図７のメッセージ設定情報に対応するメッセージを例示する図である。 特性パラメータとメッセージの内容との関係を説明する図である。 一実施形態に係る情報処理装置の制御方法のシーケンス図である。

（ゲームシステムの概要）
図１に示すように、ゲームシステム１０は、サーバ装置１１と、複数の端末装置１２と、を備える。図１では簡便のため、３つの端末装置１２を図示しているが、端末装置１２の数は１つ以上であればよい。

サーバ装置１１は、例えばゲーム運営者が管理する情報処理装置である。端末装置１２は、例えば携帯電話、スマートフォン、タブレット端末、ＰＣ（Personal Computer）、又はゲーム装置等の、ユーザによって使用される情報処理装置である。サーバ装置１１及び端末装置１２は、例えばインターネット等のネットワーク１６を介して通信可能に接続される。例えば、サーバ装置１１及び端末装置１２が協働して、ゲームに関する多様な処理を実行する。

（ゲームの概要）
ゲームシステム１０で実行されるゲームは、多様なゲームコンテンツを含む。多様なゲームコンテンツのうち少なくとも一部のゲームコンテンツは、ゲーム媒体を用いて実行されてもよい。

ゲーム媒体は、ゲームに使用される電子データであり、ユーザによってゲーム内で取得、所有、使用、管理、交換、合成、強化、売却、廃棄、又は贈与等され得る。例えば、ゲーム媒体は、カード、アイテム、仮想通貨、チケット、キャラクタ、アバタ、レベル情報、ステータス情報、及びパラメータ情報（体力値、攻撃力など）、能力情報（スキル、アビリティ、呪文、ジョブなど）等、任意の媒体を含む。ゲーム媒体の利用態様は本明細書で明示されるものに限られない。

以下、特に明示した場合を除き、「ユーザが所有するゲーム媒体」とは、所有ゲーム媒体としてユーザを一意に識別可能なユーザＩＤに対応付けられたゲーム媒体を示す。また、「ゲーム媒体をユーザに付与する」とは、ゲーム媒体を所有ゲーム媒体としてユーザＩＤに対応付けることを示す。また、「ユーザが所有するゲーム媒体を売却する」とは、ユーザＩＤと所有ゲーム媒体との対応付けを解消し、かつ、ユーザＩＤに他のゲーム媒体（例えば、仮想通貨又はアイテム等）を所有ゲーム媒体として対応付けることを示す。

ゲームコンテンツは、ゲーム内でユーザがプレイ可能なコンテンツであって、例えばクエスト、ミッション、ミニゲーム、ゲーム媒体の育成、強化、及び合成、ゲーム媒体入手イベント、仮想空間の探索イベント、並びに対戦相手（例えば、他のユーザ、敵キャラクタ、及び敵の建物等）との対戦イベント等を含む。例えば、ゲームコンテンツ毎に設定される１つ以上の所定の条件（ゲーム課題）の達成に成功したと判定された場合、ユーザに対して、例えばゲーム媒体等が報酬として付与されてもよい。ゲーム課題には、例えば敵キャラクタとの対戦に勝利するとの課題、及び仮想空間内のゴール地点まで到達するとの課題等、ゲームコンテンツの内容に応じた任意の課題が採用可能である。また、ゲームコンテンツに設定された１つ以上のゲーム課題のうち、特定の課題（クリア課題）が達成されることを、ゲームコンテンツのクリアともいう。ゲームコンテンツをプレイするユーザがクリア課題の達成に成功した場合、当該ゲームコンテンツのクリアと判定され、当該ゲームコンテンツが終了してもよい。

多様なゲームコンテンツには、シングルプレイ用のゲームコンテンツと、マルチプレイ用のゲームコンテンツと、が含まれてもよい。シングルプレイ用のゲームコンテンツとは、１のユーザが使用する１の端末装置１２に対するユーザ操作に基づいて実行されるゲームコンテンツ（例えば、一人用のゲームコンテンツ）である。１の端末装置１２が単独で、又は１の端末装置１２とサーバ装置１１とが協働して、シングルプレイ用のゲームコンテンツを実行する。一方、マルチプレイ用のゲームコンテンツとは、２つ以上のユーザがそれぞれ使用する２つ以上の端末装置１２に対するユーザ操作に基づいて実行される、当該２つ以上のユーザに共通のゲームコンテンツ（例えば、複数人用のゲームコンテンツ）である。２つ以上のユーザに共通のゲームコンテンツとは、例えば当該ゲームコンテンツの進行処理及び処理結果等の少なくとも一部が、当該２つ以上のユーザに対して共通して適用されるゲームコンテンツを含んでもよい。２つ以上の端末装置１２が協働して、又は２つ以上の端末装置１２とサーバ装置１１とが協働して、マルチプレイ用のゲームコンテンツを実行する。

本実施形態において、ゲームは、ユーザがゲーム媒体を操作して対戦を行うゲームコンテンツを含む。以下、当該ゲームコンテンツを対戦コンテンツともいう。対戦コンテンツに用いられるゲーム媒体は、例えばユーザがゲーム内で所有するキャラクタを含むものとして説明するが、これに限られない。また、対戦相手は、例えばノンプレイヤキャラクタ等の敵キャラクタを含むものとして説明するが、これに限られない。例えば、マルチプレイ用のゲームコンテンツにおいて、他のユーザが操作するゲーム媒体が対戦相手に定められてもよい。

例えば、本実施形態におけるゲームの一つの対戦コンテンツは、ユーザが所有するキャラクタの中から所定の数のキャラクタを選択する。ここで、ユーザは助っ人キャラクタ（「ヘルパー」、単に「助っ人」とも呼ばれる）を選択してデッキに加えることで、デッキの対戦能力を向上させることが可能である。そして、ユーザはデッキの一部または全部のキャラクタを用いて敵キャラクタと対戦を行う。ここで、デッキを組むとは、ユーザが所有するキャラクタおよび助っ人キャラクタの中から選択したキャラクタで、対戦を行うパーティ（チームまたはグループ）を作ることである。

（サーバ装置の構成）
サーバ装置１１は、サーバ通信部１３と、サーバ記憶部１４と、サーバ制御部１５と、を備える。

サーバ通信部１３は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。サーバ通信部１３は、例えば無線ＬＡＮ（Local Area Network）通信モジュール又は有線ＬＡＮ通信モジュール等を含んでもよい。サーバ通信部１３は、ネットワーク１６を介して、端末装置１２との間で情報を送受信可能である。

サーバ記憶部１４は、例えば一次記憶装置及び二次記憶装置を含む。例えばサーバ記憶部１４は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。サーバ記憶部１４は、ゲームの提供及び制御に必要な種々の情報及びプログラムを記憶する。サーバ記憶部１４に記憶された情報及びプログラムの少なくとも一部が、端末装置１２との間で共有及び同期されてもよい。例えばサーバ記憶部１４は、１つ以上のユーザに関する情報を記憶する。

また、サーバ記憶部１４は、敵キャラクタの情報を記憶してもよい。敵キャラクタは、対戦において、ユーザが使用するキャラクタの対戦相手として用いられる。敵キャラクタの情報は、敵キャラクタの任意の情報を含む。

また、サーバ記憶部１４は、メッセージ設定情報を記憶してもよい。後述するように、メッセージ設定情報は、ユーザが設定したキャラクタ、メッセージを受信したいタイミングおよび特性パラメータ等を含む。

サーバ制御部１５は、特定のプログラムを読み込むことにより特定の機能を実現する１つ以上の汎用プロセッサ、及び特定の処理に特化した１つ以上の専用プロセッサのうち、少なくとも一方を含む。サーバ制御部１５は、サーバ装置１１全体の動作を制御する。

サーバ制御部１５は、ゲームの処理に必要な種々の情報及びプログラムを、サーバ記憶部１４に記憶する。ゲームの処理に必要な情報には、上述したユーザに関する情報及び敵キャラクタの情報、並びに対戦の実行に必要な情報等が含まれてもよい。

サーバ制御部１５は、サーバ通信部１３を介して情報の送受信を行う。例えば、サーバ制御部１５は、サーバ記憶部１４に記憶された情報の少なくとも一部を端末装置１２へ送信してもよい。このようにして、サーバ記憶部１４に記憶された情報と端末装置１２に記憶された情報が共有及び同期される。情報の共有及び同期を行うタイミングは、例えばサーバ記憶部１４に新たな情報が記憶されたタイミング、及びサーバ記憶部１４に記憶された情報が更新されたタイミングを含み得るが、任意に定められてもよい。

サーバ制御部１５は、端末装置１２と協働して、ゲームの処理を実行する。ゲームの処理には、例えばユーザがゲームシナリオを進行させることでカードを取得する処理と、取得したカードについて交換、売却、合成等を行う処理と、カードに対応するキャラクタでデッキを組んで敵キャラクタと対戦する処理と、が含まれてもよい。

また、サーバ制御部１５は、端末装置１２と協働して、ゲームに関するメッセージを生成して送信する処理を実行する。本実施形態においては、サーバ制御部１５が、端末装置１２へのプッシュ通知として、メッセージを生成して送信する。ここで、サーバ制御部１５は、別の情報処理装置にメッセージの生成（例えば内容の設定および送信時刻の演算）および送信の少なくとも一つを実行させてもよい。例えば、メッセージは、サーバ制御部１５の指示に基づいて、別の情報処理装置から端末装置１２に送信されてもよい。

（端末装置の構成）
図１に示すように、端末装置１２は、端末通信部１７と、端末記憶部１８と、表示部１９と、入力部２０と、端末制御部２１とを備える。

端末通信部１７は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。端末通信部１７は、例えばＬＴＥ（Long Term Evolution）（登録商標）等のモバイル通信規格に対応する無線通信モジュール、無線ＬＡＮ通信モジュール、又は有線ＬＡＮ通信モジュール等を含んでもよい。端末通信部１７は、ネットワーク１６を介して、サーバ装置１１との間で情報を送受信可能である。

端末記憶部１８は、例えば一次記憶装置及び二次記憶装置を含む。例えば端末記憶部１８は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。端末記憶部１８は、ゲームの処理に必要な種々の情報及びプログラムを記憶する。例えば端末記憶部１８は、上述したユーザに関する情報の一部又は全部を記憶してもよい。また、例えば端末記憶部１８は、上述した敵キャラクタの情報を記憶してもよい。また、例えば端末記憶部１８は、上述したメッセージ設定情報を記憶してもよい。これらの情報の一部又は全部は、例えば端末制御部２１によってサーバ装置１１との間で送受信される。

表示部１９は、例えば液晶ディスプレイ又は有機ＥＬディスプレイ等の表示デバイスを含む。表示部１９は、多様な画面を表示可能である。

入力部２０は、例えば表示部１９と一体的に設けられたタッチパネル等の入力インタフェースを含む。入力部２０は、端末装置１２に対するユーザ入力を受付可能である。本実施形態において、表示部１９と入力部２０とは一体化されてタッチパネルディスプレイを構成する。タッチパネルディスプレイは、入力部２０として静電容量の変化を検出する透明なセンサー層を備え、静電容量の変化を検出することで、ユーザによって接触された位置を検出できる。ここで、静電容量方式以外の方式が採用されてもよい。また、入力部２０は、物理キーを含んでもよいし、マウス等のようなポインティングデバイスをはじめとする任意の入力インタフェースをさらに含んでもよい。

端末制御部２１は、特定のプログラムを読み込むことにより特定の機能を実現する１つ以上の汎用のプロセッサ、及び特定の処理に特化した１つ以上の専用のプロセッサのうち、少なくとも一方を含む。端末制御部２１は、端末装置１２全体の動作を制御する。

端末制御部２１は、端末通信部１７を介して情報の送受信を行う。例えば、端末制御部２１は、ゲームの処理に必要な情報をサーバ装置１１との間で送受信する。例えば、端末制御部２１は、サーバ装置１１から受信した情報を、端末記憶部１８に記憶する。

端末制御部２１は、ユーザの操作に応じてゲームのアプリケーションを起動する。端末制御部２１は、サーバ装置１１と協働して、ゲームの処理を実行する。例えば、端末制御部２１は、種々の画面を表示部１９に表示させる。画面上には、例えばＧＵＩ（Graphic User Interface）が表示されてもよい。端末制御部２１は、画面に対するユーザ操作を検出可能である。

（記憶部に記憶される情報）
図２は、少なくとも３人のユーザを含むユーザに関する情報１１０を示す。ユーザに関する情報１１０は、例えばサーバ記憶部１４に記憶されて、端末装置１２との間で共有及び同期される。つまり、ユーザに関する情報１１０は、端末装置１２の端末記憶部１８に記憶される。ユーザに関する情報１１０はユーザの種々の情報を含む。本実施形態において、ユーザに関する情報１１０は、ユーザＩＤと、所有するカードの情報１１１（図３参照）と、を含む。つまり、ユーザに関する情報１１０は、複数のユーザそれぞれと、所有するカードの情報１１１と、を対応付けている。

ユーザＩＤは、上述したようにユーザを一意に識別可能な情報である。

所有するカードの情報１１１は、ユーザがゲーム内で所有するカードの種々の情報を含む。カードがユーザに取得された場合、取得されたカードはユーザに対応付けられる。本実施形態において、カードはキャラクタカードである。そのため、所有するカードの情報１１１はカードに対応付けられたキャラクタの種類および特性に関する情報を含む。ここで、カードはキャラクタカードに限定されるものではない。

図３は、所有するカードの情報１１１の詳細を例示する図である。図３は、１人のユーザの所有するカードの情報１１１を示す。所有するカードの情報１１１は、カードＩＤと、キャラクタＩＤと、レベルと、レアリティと、属性と、対戦パラメータと、スキルＩＤと、に関するデータを含む。所有するカードの情報１１１は、これらのデータの全てを含むものに限定されない。また、所有するカードの情報１１１は、さらに別のデータを含んでもよい。

カードＩＤは、ユーザが所有するカードを一意に識別するＩＤである。図３の例では、カードＩＤとして重複しない数字が用いられている。以下、カードＩＤが１であるカードを、カード１のように表記する。

キャラクタＩＤは、ゲームのキャラクタを一意に識別するＩＤである。本実施形態において、カードはキャラクタカードであるため、１つのカードＩＤに１つのキャラクタＩＤが対応付けられている。図３の例では、キャラクタＩＤとして重複しない英文字が用いられている。以下、キャラクタＩＤがＡであるキャラクタを、キャラクタＡのように表記する。ここで、１つのキャラクタには複数のカードが対応し得る。図３の例では、カード１およびカード２０は、どちらもキャラクタＡのカードである。

レベルは、キャラクタの成長度を示す情報である。例えば、レベルの値が大きいほど、キャラクタの成長度が大きい。レベルの値は、例えば対戦パラメータの値に影響する。図３の例では、キャラクタＣのレベルは１０である。レベルの値は、ユーザがキャラクタを成長させることによって上昇する。例えば、ユーザがキャラクタを使ってゲームコンテンツ（例えばクエスト）をクリアすること、キャラクタにアイテムまたは他のキャラクタをかけ合せることで成長させることができる。

レアリティは、カードの希少性の度合いを示す情報である。例えば、レアリティの値が大きいほど、カードの希少性の度合いが高い。カードの希少性の度合いが高いとは、例えば、ゲーム運営者がゲーム内で提供する当該カードの枚数が少ないこと等である。レアリティは固定的であってもよい。また、レアリティは、カードに応じて初期値が決まっており、ユーザによるゲームのプレイに応じて変化してもよい。レアリティは、例えば対戦パラメータの最大値に影響する。図３の例ではレアリティは数字を用いている。例えば、カード１およびカード２０はどちらもキャラクタＡのカードである。しかし、レアリティが２であるカード１よりもレアリティが４であるカード２０の方が希少性の度合いが高い。ここで、別の例として、レアリティはキャラクタに応じて決まってもよい。

属性は、キャラクタが有する対戦等に関する特性であって、キャラクタ間の優劣関係を示す情報である。図３の例では、属性の種類として火、水、風、光等が使用される。例えば、火の属性を有するキャラクタは、風の属性を有するキャラクタからの攻撃に強く、水の属性を有するキャラクタからの攻撃に弱くてもよい。

対戦パラメータは、ゲーム内の対戦で参照されるキャラクタの強さを示す情報である。本実施形態において、各キャラクタはＨＰ（ヒットポイント）、ＭＰ（マジックポイント）、ＡＴ（攻撃力）およびＤＦ（防御力）の対戦パラメータを有する。ここで、対戦パラメータはＨＰ、ＭＰ、ＡＴおよびＤＦに限られるものではない。対戦パラメータは、例えば素早さ等のゲーム内の行動に関する対戦パラメータをさらに含んでもよい。また、対戦パラメータは、ＨＰ、ＭＰ、ＡＴおよびＤＦの一部を含まなくてもよい。

ＨＰは、キャラクタのヒットポイント（体力値）を示す情報である。図３では、ＨＰの最大値が示されている。例えば、キャラクタが敵キャラクタの攻撃動作によってダメージを受けると、ＨＰがダメージ量だけ減少する。また、例えばキャラクタの回復動作によって、ＨＰは回復量だけ増加する。また、ＨＰがゼロでなければキャラクタは戦闘可能状態であり、例えば敵キャラクタを攻撃することができる。しかし、ＨＰがゼロまで減少するとキャラクタは戦闘不能状態になる。キャラクタのＨＰが大きいほど、ゲームコンテンツのクリアに有利である。

ＭＰは、キャラクタのマジックポイントを示す情報である。図３では、ＭＰの最大値が示されている。例えば、キャラクタが単体で行う、通常の攻撃（装備した武器による攻撃、魔法攻撃等）とは異なる特別な攻撃（以下、スキルという）を発動すると、ＭＰはスキルに応じた値だけ減少する。また、例えばキャラクタの回復動作によって、ＭＰは回復量だけ増加する。キャラクタのＭＰが大きいほど、ゲームコンテンツのクリアに有利である。

ＡＴは、キャラクタの攻撃力を示す情報である。ＡＴは、例えばキャラクタの攻撃によって対戦相手に与えるダメージ量に影響する。ＡＴの値が大きくなるほど、対戦相手に与えるダメージ量が大きくなる。したがって、キャラクタのＡＴが大きいほど、ゲームコンテンツのクリアに有利である。

ＤＦは、キャラクタの防御力を示す情報である。ＤＦは、例えばキャラクタが対戦相手からの攻撃によって受けるダメージ量に影響する。ＤＦの値が大きくなるほど、対戦相手から受けるダメージ量が小さくなる。したがって、キャラクタのＤＦが大きいほど、ゲームコンテンツのクリアに有利である。

ここで、図３の例では各キャラクタのＨＰ、ＭＰ、ＡＴおよびＤＦの値は一例である。ＨＰ、ＭＰ、ＡＴおよびＤＦは独立した対戦パラメータであって、それぞれが独立に設定され得る。

スキルＩＤは、カードのキャラクタが有するスキルを一意に識別するＩＤである。スキルはカード毎に設定されている。ここで、スキルは全カードに設定されなくてもよい。つまり、スキルのないカードが存在してもよい。上記のように、スキルの発動によってＭＰは減少する。ＭＰの値が不足する場合、キャラクタは、スキルを発動することができない。以下、スキルＩＤがＳ１であるスキルを、スキルＳ１のように表記する。例えば、スキルＳ１は、キャラクタＡが敵キャラクタ全体に対して、火属性の中ダメージを与える攻撃であってもよい。また、例えば、スキルＳ２０は、キャラクタＡが敵キャラクタ全体に対して、風属性の特大ダメージを与える攻撃であってもよい。

図４は、メッセージ設定情報１１４を例示する図である。メッセージ設定情報１１４は、例えば端末記憶部１８に記憶されて、サーバ装置１１との間で共有される。メッセージ設定情報１１４は、本実施形態において端末装置１２へのプッシュ通知として送信されるメッセージの設定に関する情報である。

図４に示すように、メッセージ設定情報１１４は、キャラクタＩＤと、特性パラメータと、イベントと、タイミング設定と、を含む。後述するように、特性パラメータは、親密度と、最高レベルと、保有割合と、性格と、を含む。また、タイミング設定は、希望タイミングと、補正時間と、を含む。ここで、キャラクタＩＤ、イベント、および、希望タイミングは、後述するメッセージ設定画面におけるユーザの指定に基づいて設定される。その他の項目は、端末記憶部１８に記憶されたゲームデータ（例えばキャラクタ設定、進行記録等）および所有するカードの情報１１１に基づいて、端末制御部２１が抽出または演算することによって設定される。メッセージ設定情報１１４は、これらのデータ項目の全てを含むものに限定されない。例えば、メッセージ設定情報１１４は、最高レベルおよび保有割合を含まなくてもよい。また、メッセージ設定情報１１４は、さらに別のデータ項目を含んでもよい。例えば、メッセージ設定情報１１４は、さらにキャラクタＩＤに対応するキャラクタを使用してゲームをプレイした時間を含んでもよい。

キャラクタＩＤはキャラクタを一意に識別するＩＤ（識別子）である。キャラクタＩＤは、所有するカードの情報１１１（図３参照）のキャラクタＩＤと共通であってもよいし、異なる固有のＩＤが使用されてもよい。キャラクタＩＤは、ユーザが指定したお気に入りのキャラクタのＩＤであって、例えばメッセージ中のキャラクタ画像を指定するために使用される。本実施形態において、ユーザは後述するメッセージ設定画面でお気に入りのキャラクタを選択する。そして、選択されたキャラクタのＩＤがメッセージ設定情報１１４に設定される。図４の例では、キャラクタＢが選択されている。ここで、別の例として、ユーザはメッセージ設定画面でなく、ゲーム内のシステム設定でお気に入りのキャラクタを選択してもよい。また、さらに別の例として、例えばゲーム内でのデッキにおいてリーダに設定されたキャラクタが、自動的にお気に入りのキャラクタとなってもよい。これらの場合に、端末制御部２１はゲームデータに基づいてメッセージ設定情報１１４のキャラクタＩＤを設定する。以下において、メッセージ設定情報１１４のキャラクタＩＤに対応するキャラクタを「お気に入りキャラクタ」という。

ここで、お気に入りキャラクタを含む全てのキャラクタについて、ゲーム設定およびユーザのゲーム進行等に応じて変化する様々なパラメータがゲームデータ等で設定されている。本実施形態においては、メッセージ設定情報１１４の特性パラメータとして、お気に入りキャラクタについての親密度、最高レベル、保有割合および性格が用いられる。親密度は、ゲームにおけるユーザとお気に入りキャラクタとの親密さを、数値で示したものである。本実施形態においては、ユーザとお気に入りキャラクタとが親しいほど、親密度の数値が大きくなる。親密度はゲームの進行に応じて変化する。例えばユーザがお気に入りキャラクタを使用してゲームのシナリオを進行させたり、ゲーム内でお気に入りキャラクタにプレゼント（例えばアイテム等）をあげたりすると、親密度の数値が大きくなる。また、ユーザがお気に入りキャラクタに関するイベントを進行させることによって、親密度の数値が大きくなってもよい。お気に入りキャラクタに関するイベントは、例えば期間限定であって、そのストーリーにお気に入りキャラクタが主役として、または、準主役として登場するイベントである。ユーザがお気に入りキャラクタに関するイベントを進行させる場合に、親密度の数値は、ゲームの通常のシナリオの場合よりも大きくなってもよい。端末制御部２１はゲームデータに基づいてメッセージ設定情報１１４の親密度を設定する。図４の例では、親密度は９であり、初期状態（親密度が１）よりも親密さが向上している。

最高レベルは、ユーザが所有するお気に入りキャラクタのカードのレベルのうち、最も値が大きいものである。最高レベルは、お気に入りキャラクタの成長度に関連する。最高レベルは、後述するようにメッセージの内容が設定されるときに、例えば親密度に代えて、または、親密度と共に参照されてもよい。端末制御部２１は所有するカードの情報１１１に基づいてメッセージ設定情報１１４の最高レベルを設定する。図４の例では、キャラクタＢの最高レベルは５であり、初期状態（レベルが１）よりも成長している。

保有割合は、ユーザが所有する全てのカードのうちお気に入りキャラクタのカードが占める割合を表す。保有割合は、ユーザがお気に入りキャラクタのカードを好んで収集しているか否かに関連する。保有割合は、後述するようにメッセージの内容が設定されるときに、例えば親密度に代えて、または、親密度と共に参照されてもよい。端末制御部２１は所有するカードの情報１１１に基づいてメッセージ設定情報１１４の保有割合を演算する。図４の例では、ユーザが所有するカードの１２％がキャラクタＢのカードである。

性格は、お気に入りキャラクタのゲームにおける性質であって、ゲームデータで定められている。性格は、例えばメッセージの内容および後述する補正時間等に影響し得る。性格は、例えばのんびり、せっかち、および、几帳面等を含んでもよい。図４の例では、キャラクタＢの性格は「のんびり」である。性格は、後述するようにメッセージの送信時刻が演算されるときに、参照されてもよい。端末制御部２１はゲームデータに基づいてメッセージ設定情報１１４の性格を設定する。

イベントは、ユーザがメッセージ（例えばイベント開始を知らせるもの等）による通知を希望するイベントを示す。図４の例では、イベントは「全て」である。そのため、実施される全てのイベントに関するメッセージが、ユーザの端末装置１２にプッシュ通知として送信される。本実施形態において、ユーザは後述するメッセージ設定画面でイベントを選択する。そして、選択されたイベントがメッセージ設定情報１１４に設定される。ここで、別の例として、ユーザはメッセージ設定画面でなく、ゲーム内のシステム設定でイベントを選択してもよい。このとき、端末制御部２１はゲームデータに基づいてメッセージ設定情報１１４のイベントを設定する。

希望タイミングは、ユーザがメッセージを受信したいタイミングを示す。図４の例では、希望タイミングはイベントの「開始時」である。つまり、ユーザはイベントが開始されると同時にメッセージを受信することを希望している。本実施形態において、ユーザは後述するメッセージ設定画面で希望タイミングを選択する。そして、選択された希望タイミングがメッセージ設定情報１１４に設定される。ここで、別の例として、ユーザはメッセージ設定画面でなく、ゲーム内のシステム設定で希望タイミングを選択してもよい。このとき、端末制御部２１はゲームデータに基づいてメッセージ設定情報１１４の希望タイミングを設定する。

補正時間は、メッセージ設定情報１１４におけるメッセージを受信したいタイミング（希望タイミング）と、端末装置１２がメッセージを受信するタイミングと、の時間差に対応する。補正時間は、お気に入りキャラクタの性格に応じて定められる。図４の例では、キャラクタＢの性格がのんびりであるため、補正時間は「１０分遅く」に設定される。つまり、メッセージは希望タイミングよりも１０分遅く届けられる。補正時間は、例えばメッセージ設定情報１１４に設定されている性格に基づいて、端末制御部２１によって演算される。ここで、端末装置１２がメッセージを受信するタイミングと、送信元（例えばサーバ装置１１）がメッセージを送信するタイミングとは、通信に要する時間だけ異なる。しかし、本明細書では説明をわかりやすくするために、端末装置１２がメッセージを受信するタイミングと、送信元がメッセージを送信するタイミングとは同じであるとして説明する。

ここで、性格および補正時間の少なくとも一方は、メッセージ設定情報１１４に含まれなくてもよい。後述するように、端末記憶部１８に記憶されたメッセージ設定情報１１４は、端末装置１２からサーバ装置１１に送信される。性格および補正時間の少なくとも一方は、サーバ装置１１がメッセージ設定情報１１４を取得した後に、サーバ制御部１５が抽出または演算することによって設定されてもよい。例えば、サーバ制御部１５は、メッセージ設定情報１１４からキャラクタＩＤを抽出する。そして、サーバ制御部１５は、サーバ記憶部１４に記憶されたゲームデータからキャラクタＩＤに対応する性格を抽出してもよい。また、例えばサーバ制御部１５は、抽出した性格に応じて補正時間を演算してもよい。

（画面表示例）
図５はメッセージ設定画面を例示する図である。端末装置１２は、表示部１９にメッセージ設定画面を表示して、メッセージ設定情報をユーザに設定させる。ユーザがメッセージ設定画面で選択した、お気に入り、イベントおよびタイミングは、それぞれ、メッセージ設定情報１１４（図４参照）のキャラクタＩＤ、イベントおよび希望タイミングに反映される。

端末装置１２の表示部１９に表示されるメッセージ設定画面は、画面の上部の領域で、お気に入りのキャラクタをユーザに選択させる。図５に示すように、ユーザの選択に用いられるキャラクタのアイコン４１が表示される。ユーザはアイコン４１をタップすることによって、タップしたキャラクタをお気に入りキャラクタに指定することができる。図５の例では、ユーザは８つのキャラクタＡ〜Ｈのうち、キャラクタＢをお気に入りキャラクタに指定している。ここで、メッセージ設定画面においては、タップして選択した対象をもう一度タップすることによって、非選択状態に戻すことが可能である。つまり、ユーザは選択のやり直しが可能である。

また、メッセージ設定画面は、画面の中央部分の領域で、イベントをユーザに選択させる。図５に示すように、同領域には、ユーザが選択可能であるように、実施予定のイベントがリスト表示される。リストには、具体的なイベント名（例えばイベントＸ、イベントＹ等）だけでなく、対象とするイベントの範囲（例えば対戦イベントのみ、全てのイベント等）が表示される。図５の例では、ユーザは「全てのイベント」を選択している。つまり、ユーザは実施予定の全てのイベントに関するメッセージ（例えばプッシュ通知）を受け取ることを選択している。

また、メッセージ設定画面は、画面の下部の領域で、メッセージを受信したいタイミングをユーザに選択させる。図５に示すように、同領域には、ユーザが選択可能であるように通知時間がリスト表示される。図５の例では、ユーザは「開始時」を選択している。つまり、ユーザはメッセージをイベントの開始時に受け取ることを選択している。

また、メッセージ設定画面の一番下には、設定ボタンとキャンセルボタンが設けられている。ユーザが設定ボタンをタップすると、ユーザがメッセージ設定画面で選択した内容が、メッセージ設定情報１１４に反映される。また、ユーザがキャンセルボタンをタップすると、メッセージ設定情報１１４は更新されずに、ユーザの選択内容がキャンセルされる。

ここで、メッセージ設定画面でさらに期間が設定可能であってもよい。期間は、ユーザがメッセージ３４を受信したい期間であって、例えば８月中、９月１日〜９月３日、今から１週間、休日だけ等の設定が可能であってもよい。期間が設定された場合に、期間外のメッセージ３４は受信されない。そのため、ユーザは、メッセージ３４の受信についてより細かく設定可能になる。例えば、仮にユーザが全てのイベントを選択していても、設定された期間を過ぎると、ユーザの端末装置１２はメッセージ３４を受信しなくてもよい。

図６は、図４のメッセージ設定情報１１４に対応するメッセージ３４を例示する図である。本実施形態において、メッセージ３４はプッシュ通知である。図６に示すように、端末装置１２でゲームのアプリケーションが起動していない状態（例えば画面がロックされた状態）であっても、ユーザにメッセージ３４を通知することが可能である。後述するように、例えばサーバ装置１１は、メッセージ設定情報１１４に基づいて、端末装置１２に通知するメッセージ３４の送信時刻を演算し、メッセージ３４の内容を設定する。サーバ装置１１が送信時刻に通知したメッセージは、図６に示すように、端末装置１２の表示部１９に表示される。

メッセージ３４の内容は、お気に入りキャラクタの画像（アイコン４１）と、送信時刻（または受信時刻）と、本文であるテキスト４２と、を含む。図６の例では、アイコン４１はお気に入りキャラクタであるキャラクタＢの画像である。また、テキスト４２も、キャラクタＢのゲーム内での口調等に合わせた記載になっている。ここで、図４のように、キャラクタＢの性格は「のんびり」であり、補正時間が「１０分遅く」に設定されている。そのため、メッセージ３４は、ユーザの希望タイミング（イベントＸの開始時の○月○日００：００）から１０分遅れた時刻に送信されている。

ここで、図７はメッセージ設定情報１１４の別の例を示す。図７のメッセージ設定情報１１４では、お気に入りキャラクタはキャラクタＡに設定されている。図７の例では、キャラクタＡの性格は「せっかち」である。そのため、補正時間は「１０分早く」に設定されている。また、図７の例では、希望タイミングはイベントの「１時間前」である。つまり、ユーザはイベントが開始される１時間前にメッセージを受信することを希望している。

図８は、図７のメッセージ設定情報１１４に対応するメッセージ３４を例示する図である。図８の例では、アイコン４１はお気に入りキャラクタであるキャラクタＡの画像である。また、テキスト４２も、キャラクタＡのゲーム内での口調等に合わせた記載になっている。また、図８の例では、メッセージ３４は、ユーザの希望タイミング（イベントＸの開始の１時間前である○月×日２３：００）から更に１０分早い時刻（○月×日２２：５０）に送信されている。

このように、メッセージ３４は、お気に入りキャラクタの口調等に合わせた内容で、その性格を反映した時刻に送信される。そのため、ユーザは、メッセージ３４に対して、指定時刻に画一的な文面で送信される広告ではなく、現実の人物からのメールを受け取ったときのような親近感を覚える。また、ユーザは、メッセージ３４が自分だけに向けた内容であるかのように感じて、従来の画一的内容のメッセージにはなかった特別感を覚える。ここで、上記の例では、メッセージ３４の送信時刻はユーザの希望タイミングと異なっている。しかし、例えばユーザがメッセージ設定画面で、性格が「几帳面」であるキャラクタＣを選択した場合には、補正時間は「ちょうど」に設定される。つまり、例えばお気に入りキャラクタを変更することによって、ユーザの希望タイミング通りにメッセージ３４を受信することが可能である。

図９は、親密度とメッセージ３４の内容との関係を説明するための図である。本実施形態において、メッセージ３４の内容は、性格以外のお気に入りキャラクタの特性パラメータに影響される。

図９は、親密度の高さに応じて切り替わる３つのメッセージ３４を含む。以下において、３つのメッセージ３４を上から順に、それぞれ、上段のメッセージ３４、中段のメッセージ３４、下段のメッセージ３４という。お気に入りキャラクタの親密度が低い（例えば１〜５の範囲内である）とき、ユーザは上段のメッセージ３４を受信する。上段のメッセージ３４のアイコン４１のお気に入りキャラクタの表情は例えば不機嫌な顔である。また、上段のメッセージ３４のテキスト４２の記載量は少ない。また、上段のメッセージ３４のテキスト４２の文面はよそよそしい印象を与えるものであってもよい。

お気に入りキャラクタの親密度が中程度（例えば５〜９の範囲内である）とき、ユーザは中段のメッセージ３４を受信する。中段のメッセージ３４のアイコン４１のお気に入りキャラクタの表情は例えばすました顔である。また、中段のメッセージ３４のテキスト４２の記載量は、上段のメッセージ３４よりも多い。また、中段のメッセージ３４のテキスト４２の文面は知り合いとの会話であるような印象を与えるものであってもよい。

お気に入りキャラクタの親密度が高い（例えば１０以上である）とき、ユーザは下段のメッセージ３４を受信する。下段のメッセージ３４のアイコン４１のお気に入りキャラクタの表情は例えば笑顔である。また、下段のメッセージ３４のテキスト４２の記載量は、中段のメッセージ３４よりもさらに多い。また、下段のメッセージ３４のテキスト４２の文面は親友との会話であるような印象を与えるものであってもよい。

本実施形態において、メッセージ３４の内容は、後述するようにサーバ装置１１によって設定される。サーバ装置１１は、端末装置１２から受け取ったメッセージ設定情報１１４の特性パラメータ（図９の例では親密度）を抽出する。サーバ装置１１は、抽出した特性パラメータに基づいてメッセージ３４の内容を設定する（図９の例では上段、中段または下段のメッセージ３４を選択する）。そして、サーバ装置１１は、特性パラメータに応じた内容のメッセージ３４を端末装置１２に送信する。ユーザは、お気に入りキャラクタとの親密度が高い程、より親近感を覚えるメッセージ３４を受け取ることが可能である。ここで、親密度は、ユーザがゲームを進行させることによって高まる。したがって、上記のように特性パラメータに応じた内容のメッセージ３４を用意することによって、ユーザにゲームへの一層の参加を促す効果が生じ得る。

ここで、図９の例では親密度に応じて、アイコン４１（お気に入りキャラクタの表情）およびテキスト４２が変化したが、一方だけが変化してもよい。例えば上段、中段および下段のメッセージ３４のテキスト４２は共通であって、アイコン４１が親密度に応じて変化してもよい。また、図９の例では親密度に応じたメッセージ３４の変化は３段階であったが、これに限らない。例えば、親密度に応じた、より多くのメッセージ３４の切り替えがあってもよい。また、例えば、親密度に応じて、２段階にメッセージ３４が切り替えられてもよい。

また、図９の例では親密度に応じてメッセージ３４が変化するが、親密度に代えて、または、親密度と共に他の特性パラメータ（例えば最高レベルおよび保有割合の少なくとも一方）が用いられてもよい。例えば、最高レベルが高い（例えば１０以上である）とき、ユーザは図９の下段のメッセージ３４を受信してもよい。また、例えば、保有割合が高い（例えば２０％以上である）とき、ユーザは図９の下段のメッセージ３４を受信してもよい。ここで、ユーザは、ゲームを進行させることによって、最高レベルおよび保有割合を高めることが可能である。したがって、この場合にも、ユーザにゲームへの一層の参加を促す効果が生じ得る。

（シーケンス図）
図１０は、情報処理装置（端末装置１２およびサーバ装置１１）が実行する上記のメッセージ３４に関する制御方法を示すシーケンス図である。ここで、以下のシーケンス図の説明におけるゲーム媒体の具体例はキャラクタである。

まず、端末装置１２は、メッセージ設定情報１１４をユーザに設定させる（ステップＳ１）。端末装置１２は、例えば表示部１９にメッセージ設定画面を表示して、複数のゲーム媒体の中の少なくとも１つ（お気に入りキャラクタ）およびメッセージを受信したいタイミング（希望タイミング）を、ユーザに設定させる。端末装置１２は、さらに、メッセージ３４による通知を希望するイベントを、ユーザに設定させてもよい。端末装置１２は、メッセージ設定情報１１４の全てをユーザに設定させる必要がない。つまり、端末装置１２は、その一部をユーザに設定させるだけでよい。

端末装置１２は、メッセージ設定情報１１４を端末記憶部１８に記憶する（ステップＳ２）。端末装置１２は、例えばお気に入りキャラクタの特性パラメータおよび補正時間を加えて、図４に示すようなメッセージ設定情報１１４を端末記憶部１８に記憶してもよい。

端末装置１２は、端末記憶部１８に記憶したメッセージ設定情報１１４を、端末通信部１７によってサーバ装置１１に送信する（ステップＳ３）。ここで、送信されるメッセージ設定情報１１４は、全ての項目を含んでいてもよいし、一部の項目だけを含んでいてもよい。

サーバ装置１１は、サーバ通信部１３によって受信したメッセージ設定情報１１４を端末装置１２のＩＤ（識別情報）に関連付けて、サーバ記憶部１４に記憶する（ステップＳ４）。端末装置１２のＩＤは、例えばメッセージ設定情報１１４と共に端末装置１２から送信される。端末装置１２のＩＤは、例えばトークンであってもよいし、端末装置１２のユーザに関連づけられた識別情報等であってもよい。端末装置１２のＩＤは、メッセージ３４を送信する宛先を特定するのに使用される。

サーバ装置１１は、メッセージ設定情報１１４の特性パラメータ（例えば性格）、イベントおよび希望タイミング等に基づいて、メッセージ３４の送信時刻を演算する（ステップＳ５）。例えば、図６のメッセージ３４では、送信時刻はユーザの希望タイミング（○月○日００：００）から１０分遅れた時刻（○月○日００：１０）である。また、例えば、図８のメッセージ３４では、送信時刻はユーザの希望タイミング（○月×日２３：００）から１０分早い時刻（○月×日２２：５０）である。

サーバ装置１１は、メッセージ設定情報１１４の特性パラメータ（例えば親密度）に基づいて、メッセージ３４の内容を設定する（ステップＳ６）。例えば、図９のメッセージ３４では、お気に入りキャラクタの親密度が１０以上であれば、サーバ装置１１は下段のメッセージ３４を選択する。

サーバ装置１１は、ステップＳ５で演算した送信時刻になった場合に、ステップＳ６で設定した内容のメッセージ３４を、端末装置１２に送信する（ステップＳ７）。ここで、サーバ装置１１は、別の情報処理装置にメッセージ３４の生成（例えば内容の設定および送信時刻の演算）および送信の少なくとも一方を実行させてもよい。つまり、ステップＳ５〜Ｓ７の少なくとも１つの処理は、サーバ装置１１の指示に基づいて、別の情報処理装置が実行してもよい。

端末装置１２は、他の情報処理装置（例えばサーバ装置１１または別の情報処理装置）からのメッセージ３４を、端末通信部１７によって受信する（ステップＳ８）。つまり、端末装置１２は、他の情報処理装置がメッセージ設定情報１１４に応じて送信時刻および内容の少なくとも一方を調整したメッセージ３４を受信する。

端末装置１２は、受信したメッセージ３４をユーザに対して表示する（ステップＳ９）。本実施形態では、受信したメッセージ３４は、プッシュ通知として表示部１９に表示される。

以上述べたように、本実施形態に係る情報処理装置（例えば端末装置１２）は、複数のゲーム媒体（例えば複数のキャラクタ）を有するゲームの処理を実行する。情報処理装置は、記憶部（例えば端末記憶部１８）と、通信部（例えば端末通信部１７）と、制御部（例えば端末制御部２１）と、を備える。制御部は、ゲーム内で、メッセージ設定情報１１４として、複数のゲーム媒体の中の少なくとも１つ（例えば、お気に入りキャラクタ）およびメッセージを受信したいタイミング（例えば、希望タイミング）を、ユーザに設定させる。また、制御部は、メッセージ設定情報１１４を、記憶部に記憶させる。また、制御部は、記憶部に記憶されたメッセージ設定情報１１４を、通信部を介して送信する。また、制御部は、メッセージを、通信部を介して受信する。また、制御部は、受信したメッセージをユーザに対して表示する。ここで、情報処理装置がメッセージを受信するタイミングおよびメッセージの内容の少なくとも一方は、メッセージ設定情報１１４に応じて異なる。

ここで、従来のゲームにおいても、ゲームの実行中にキャラクタの画像と共にメッセージが表示される機能を備えるものがあった。しかし、ゲームの起動中でなければ、メッセージを表示することができなかった。そのため、例えばユーザがゲーム内のイベントの開始を忘れないように、所定のタイミング（例えばイベント開始の１時間前等）でメッセージを通知するといった用途（アラーム）では、確実性を欠くため使用できなかった。このような用途では、ゲームの起動を必要としない、ゲーム外のメッセージ機能（例えばプッシュ通知）を利用することが好ましい。しかし、メッセージの内容が画一的であるような場合には、ゲームの進行状況またはお気に入りキャラクタとの関連性が少なく、ユーザに親近感または特別感を与えることは困難であった。本実施形態に係る情報処理装置は、上記の構成によって、ゲーム内での設定に応じて内容が変化するメッセージの通知を実行できる。本開示によれば、メッセージ３４を受信するタイミングおよびメッセージ３４の内容の少なくとも一方は、メッセージ設定情報１１４に応じて異なる。例えば、メッセージ設定情報１１４の内容はゲームの進行に応じて変化するため、メッセージ３４においてもゲームの進行状況が反映される。また、例えば、メッセージ３４を受信するタイミング等はお気に入りキャラクタの性格を反映したものとなるため、ユーザに親近感または特別感を与えることが可能である。

（変形例等）
本開示を諸図面および実施形態に基づき説明してきたが、当業者であれば本開示に基づき種々の変形および修正を行うことが容易であることに注意されたい。したがって、これらの変形および修正は本開示の範囲に含まれることに留意されたい。例えば、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段またはステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。

上記の実施形態において、メッセージ３４はゲーム内のイベントに関連する内容である。そして、ユーザはメッセージ設定画面において、イベントおよびイベントを基準にした時刻の設定を実行する。ここで、メッセージ３４はイベントとは関係のない内容であってもよい。例えば、ユーザのログイン状況、ゲームの進捗状況、特定の日に該当するか否か等に応じて、所定の頻度でメッセージが通知されてもよい。例えば、ユーザが最後にログインしてから所定期間（例えば３日）経過した場合に、お気に入りのキャラクタからログインを促すメッセージ３４が所定の頻度で端末装置１２に送信されてもよい。また、例えば、ユーザのクエストが停滞している（例えば２日間ステージが進まない）場合に、お気に入りのキャラクタから励ますメッセージ３４が所定の頻度で端末装置１２に送信されてもよい。また、例えば、ユーザのランキングが低下した（例えば１００位より大きく低下した）場合にも、励ますメッセージ３４が所定の頻度で端末装置１２に送信されてもよい。ここで、所定の頻度は、特性パラメータ（例えば親密度）に応じて変化してもよい。例えば、親密度が高い（一例として１０以上である）とき、１日に３回、メッセージ３４が端末装置１２に送信されてもよい。また、例えば、親密度が低い（一例として１である）とき、２日に１回、メッセージ３４が端末装置１２に送信されてもよい。つまり、親密度が高いほど、ユーザはメッセージ３４をより多く受信できてもよい。また、休日または記念日（例えばお気に入りのキャラクタの誕生日）に該当する場合には、これらに該当しない日よりも、メッセージ３４が送信される頻度が高くなってもよい。

また、メッセージ３４がイベントとは関係のない内容である場合に、ユーザは時間、期間、および頻度等の設定が可能であってもよい。本変形例において、例えばイベントおよびタイミングに代えて、時間、期間、および頻度が設定可能なメッセージ設定画面が使用されてもよい。時間は、ユーザがメッセージ３４を受信したい時間であって、例えば１２：００である。また、期間は、ユーザがメッセージ３４を受信したい期間であって、例えば９月１０日〜９月３０日である。また、頻度は、ユーザがメッセージ３４を受信したい頻度であって、例えば平日のみである。この例の場合、ユーザは上記期間の平日の１２：００に、正午を知らせるメッセージ３４（イベントとは無関係）を受信する。この場合にも、上記の実施形態と同様に、キャラクタの性格に応じて受信が早まる、または、遅くなるといった変化が生じてもよい。

また、上記の実施形態において、お気に入りキャラクタはユーザによって指定されている。ここで、お気に入りキャラクタは特定の条件が満たされた場合に、自動的に変更されてもよい。例えば、ユーザまたはユーザと所定の関係にあるユーザ（例えば同じグループのユーザまたはフレンド）がレアリティの高いカードを取得した場合に、お気に入りキャラクタはそのカードのキャラクタに自動的に変更されてもよい。また、例えば、ゲーム内で期間限定のイベントが開催中である場合に、お気に入りキャラクタはそのイベントに関連したキャラクタに自動的に変更されてもよい。このとき、イベントの期間が終了した後に、お気に入りキャラクタは自動的にユーザ指定のキャラクタに戻ってもよい。例えば、上記のように、サーバ装置１１はユーザ指定のキャラクタの特性パラメータに基づいてメッセージ３４の内容を設定する。このとき、サーバ装置１１は、イベントの開催期間およびイベントに関連したキャラクタの情報をさらに取得（例えばゲームのイベント情報から抽出）してもよい。そして、サーバ装置１１は、特定の条件が満たされる場合に、ユーザ指定のキャラクタに代えて、イベントに関連したキャラクタをメッセージ３４で用いてもよい。ここで、特定の条件は、例えばイベントの開催期間中であること、イベントの開催まであと３日以内であること、新規登場のキャラクタに関するイベントであること、または、これらの組み合わせ等であってもよい。ユーザが設定しなくても自動的にお気に入りキャラクタを変更することによって、この変形例に係る情報処理装置は、ユーザに変化のあるゲーム体験を提供することができる。また、類似の変形例として、情報処理装置は、自動的にお気に入りキャラクタを変更するのではなく、候補となるキャラクタをユーザが選択可能なように表示してもよい。候補となるキャラクタは、例えば親密度等のパラメータに基づいて定められてもよい。また、候補となるキャラクタは、例えばゲーム内で開催中、または、開催予定のイベントとの関連性に応じて定められてもよい。候補となるキャラクタが表示されるため、ユーザは、お気に入りキャラクタの選択が容易となり、ユーザビリティが向上する。

また、上記の実施形態において、補正時間は、お気に入りキャラクタの性格に関連付けられていた。ここで、メッセージ設定情報１１４にお気に入りキャラクタの「状態」が設定されており、「状態」に応じて補正時間が調整されてもよい。例えば「状態」は忙しい、忙しくない、○○時に予定あり、○日まで予定なし等、お気に入りキャラクタのゲーム内でのスケジュールに応じて設定されてもよい。また、ユーザがお気に入りキャラクタを用いてゲームを進行させたか否かに応じて、「状態」として例えば忙しい、忙しくない等が設定されてもよい。例えばお気に入りキャラクタの「状態」が忙しい場合に、補正時間は「１０分遅く」に設定されてもよい。逆に、例えばお気に入りキャラクタの「状態」が忙しくない場合に、補正時間は「１０分早く」に設定されてもよい。メッセージ設定情報１１４にお気に入りキャラクタの「状態」が設定されている場合に、補正時間は、お気に入りキャラクタの「性格」および「状態」の少なくとも一方に基づいて設定されてもよい。例えば、お気に入りキャラクタの「性格」がのんびりで、かつ、「状態」が忙しい場合に、補正時間は両方に基づいて「２０分遅く」に設定されてもよい。また、例えば、お気に入りキャラクタの「性格」がせっかちで、かつ、「状態」が忙しい場合に、補正時間は「１０分早く」と「１０分遅く」とが打ち消し合って、「ちょうど」に設定されてもよい。

また、上記の実施形態において、メッセージ３４はプッシュ通知である。ここで、端末装置１２に送信されたメッセージ３４は、ユーザ毎に記憶部（端末記憶部１８およびサーバ記憶部１４の少なくとも一方）に記憶されてもよい。通常、プッシュ通知は所定の時間が経過すると消去されるが、記憶されることによって、ユーザがお気に入りのキャラクタからのメッセージ３４を収集することを可能にする。例えば、端末制御部２１は、受信したメッセージ３４を時刻情報と関連付けて端末記憶部１８に記憶させてもよい。このとき、ゲームのアプリケーションは、メッセージ３４を記憶させる一部のプログラムだけがバックグラウンドで動作（常時動作）していてもよい。そして、ユーザから要求があった場合に、端末記憶部１８に記憶されたメッセージ３４を、時刻情報に応じた順に表示させてもよい。例えば、メッセージ３４を時刻情報に応じた順に表示させる処理は、ゲームの特定の画面から実行可能であってもよい。また、記憶部に記憶されたメッセージ３４は、ゲーム媒体（キャラクタ）毎に抽出可能であってもよい。また、記憶部に記憶されたメッセージ３４は、特定の条件（例えばイベントＸに関する内容を含む等）で抽出可能であってもよい。ユーザは例えばゲームの特定の画面において、このような絞り込み条件を設定できてもよい。

また、端末装置１２に送信されたメッセージ３４がユーザ毎に記憶部に記憶される場合に、メッセージ３４の履歴に応じてゲームの進行が変化してもよい。例えば、端末装置１２は、お気に入りキャラクタとして選択されたキャラクタとメッセージ３４の受信回数を関連付けて記憶し、キャラクタ毎のメッセージ３４の受信回数を演算する。そして、その受信回数に基づいて、キャラクタのパラメータ（例えば対戦パラメータ）または特定のイベント（例えば特定のキャラクタに関連付けられたイベント）の内容が変化する。また、端末装置１２は、キャラクタ毎のメッセージ３４の受信回数に応じて、ゲーム内で特別なイベントを実行してもよい。このように、キャラクタと、メッセージ３４の受信回数と、ゲーム内でのイベントと関連付けることによって、ユーザに特別なゲーム体験を提供することができる。また、本変形例において、キャラクタ毎のメッセージ３４の受信回数に代えて、メッセージ３４を受信してからユーザがメッセージ３４に対して反応するまで（例えばゲームを起動するまで）の時間が用いられてもよい。また、本変形例において、キャラクタ毎のメッセージ３４の受信回数に代えて、メッセージ３４を受信した場合にユーザがメッセージ３４に対して反応した回数が用いられてもよい。また、本変形例において、キャラクタ毎のメッセージ３４の受信回数に代えて、メッセージ３４を介して（例えばメッセージ３４の文中のリンク等をタップして）ゲームを起動した回数が用いられてもよい。

また、上記の実施形態において、メッセージ３４はユーザ自身の端末装置１２へのプッシュ通知である。ここで、メッセージ３４は、ユーザ自身だけでなく、他のユーザ（例えば、同じグループのユーザまたはフレンドであってもよい）へのプッシュ通知であってもよい。このとき、情報処理装置は、お気に入りキャラクタが送信先のユーザが所有していないキャラクタである場合に、例えば送信先のユーザがお気に入りキャラクタの詳細情報を閲覧できるように、メッセージ３４の内容を設定してもよい。また、情報処理装置は、お気に入りキャラクタが送信先のユーザが所有していないキャラクタである場合に、例えば送信先のユーザがお気に入りキャラクタを獲得可能なゲーム内の場所に移動できるように、メッセージ３４の内容を設定してもよい。通常の伝達内容だけではなく、ユーザのお気に入りキャラクタについての情報を含むメッセージ３４が他のユーザにも送信されることによって、ユーザ間の交流が一層活性化される。

また、上記の実施形態において、メッセージ３４のアイコン４１（お気に入りキャラクタの表情）およびテキスト４２は特性パラメータ（例えば親密度）に応じて変化する。ここで、アイコン４１およびテキスト４２の少なくとも一方は、お気に入りキャラクタと、ゲーム内で開催中または開催予定のイベントと、の関連性に応じて変化してもよい。このとき、お気に入りキャラクタとイベントとの関連性の高さを示す「関連度」といったパラメータが設定されてもよい。関連度は、例えば親密度と同様に、関連性が高いほど数値が高くなってもよい。そして、特性パラメータ（例えば親密度）に代えて、または特性パラメータと共に、関連度が、メッセージ３４の内容を設定するのに用いられてもよい。このとき、メッセージ３４を受信したユーザは、例えばお気に入りキャラクタの表情（アイコン４１）から、イベントと自身のお気に入りキャラクタとの関連性を容易に把握できる。よって、このようなメッセージ３４によって、ユーザがイベントに関心を持ちやすくなり、ゲーム内のイベントの活性化が期待できる。

また、上記の実施形態において、ゲーム画面の一部をサーバ装置１１が生成したデータに基づいて端末装置１２の表示部１９に表示させるウェブ表示とし、ゲーム画面の一部を、端末装置１２にインストールされているネイティブアプリによって表示させるネイティブ表示としてもよい。このように、上述した実施形態におけるゲームは、端末装置１２およびサーバ装置１１のそれぞれが処理の一部を担うハイブリッドゲームとすることもできる。また、上記の制御方法（図１０参照）において端末装置１２またはサーバ装置１１が実行する一部の処理を、他方の装置が実行してもよい。例えば、サーバ装置１１が実行するメッセージの送信時刻の演算（ステップＳ５）を、端末装置１２が実行して、演算結果をサーバ装置１１に送信してもよい。

また、サーバ装置１１および端末装置１２は、ゲームに関する多様な処理を協働して実行してもよい。例えば、サーバ装置１１および端末装置１２が、一連の処理を分担して実行してもよい。また、例えば、サーバ装置１１および端末装置１２それぞれが同一の処理を実行してもよい。当該同一の処理について、サーバ装置１１と端末装置１２との間で処理結果が一致する場合、サーバ装置１１および端末装置１２は、当該処理を完了してもよい。サーバ装置１１と端末装置１２との間で処理結果が一致しない場合、サーバ装置１１および端末装置１２は、一方（例えばサーバ装置１１）の処理結果が正しいとして当該処理を完了してもよい。また、別の例として、サーバ装置１１と端末装置１２との間で処理結果が一致しない場合、サーバ装置１１および端末装置１２は、当該同一の処理の実行前にプロセスを巻き戻してもよい。かかる構成によれば、例えばサーバ装置１１および端末装置１２の間の通信品質が一時的に低下した場合であっても、直ちに処理が中断される蓋然性が低下する。また、端末装置１２において、例えば対戦パラメータの書き換え等の不正処理が行われた場合であっても、当該不正処理を排除できる蓋然性が向上する。

また、端末装置１２またはサーバ装置１１として機能させるために、例えばコンピュータ、携帯電話等を好適に用いることができる。端末装置１２またはサーバ装置１１は上記の各機能を実現する処理内容を記述したプログラムを、アクセス可能な記憶部に格納し、ＣＰＵによって当該プログラムを読み出して実行させることによって実現可能である。

１０ ゲームシステム
１１ サーバ装置
１２ 端末装置
１３ サーバ通信部
１４ サーバ記憶部
１５ サーバ制御部
１６ ネットワーク
１７ 端末通信部
１８ 端末記憶部
１９ 表示部
２０ 入力部
２１ 端末制御部
３４ メッセージ
４１ アイコン
４２ テキスト
１１０ ユーザに関する情報
１１１ 所有するカードの情報
１１４ メッセージ設定情報

Claims (7)

1. 記憶部と、通信部と、を備え、複数のゲーム媒体を有するゲームの処理を実行する情報処理装置に、
   ユーザによって設定された前記複数のゲーム媒体の中の少なくとも１つおよびメッセージを受信したいタイミングと、ユーザによって設定されたゲーム媒体に関連付けられた特性パラメータと、を含むメッセージ設定情報を、前記記憶部に記憶させるステップと、
   前記記憶部に記憶された前記メッセージ設定情報を、前記通信部を介してサーバに送信するステップと、
   前記メッセージ設定情報に含まれる前記タイミングと特性パラメータとに応じて決定されるタイミングに基づいて前記サーバから送信されたメッセージを、前記通信部を介して受信するステップと、
   受信した前記メッセージを前記ユーザに対して表示するステップと、
   を実行させるためのプログラム。
2. 前記特性パラメータは、前記ユーザと前記ユーザが設定したゲーム媒体との前記ゲームにおける親密さを示す親密度を含む、請求項１に記載のプログラム。
3. 前記メッセージの内容は、前記メッセージ設定情報において前記ユーザが設定したゲーム媒体の画像を含み、
   前記親密度に応じて、前記画像が異なる、請求項２に記載のプログラム。
4. 前記親密度が高いほど、前記メッセージをより多く受信できる、請求項２または３に記載のプログラム。
5. 前記情報処理装置に、
   受信した前記メッセージを、時刻情報と関連付けて前記記憶部に記憶させるステップと、
   前記ユーザから要求があった場合に、前記記憶部に記憶された前記メッセージを、前記時刻情報に応じた順に表示させるステップと、を実行させる、請求項１から４のいずれか一項に記載のプログラム。
6. 記憶部と、通信部と、を備え、複数のゲーム媒体を有するゲームの処理を実行する情報処理装置の制御方法であって、
   ユーザによって設定された前記複数のゲーム媒体の中の少なくとも１つおよびメッセージを受信したいタイミングと、ユーザによって設定されたゲーム媒体に関連付けられた特性パラメータと、を含むメッセージ設定情報を、前記記憶部に記憶させるステップと、
   前記記憶部に記憶された前記メッセージ設定情報を、前記通信部を介してサーバに送信するステップと、
   前記メッセージ設定情報に含まれる前記タイミングと特性パラメータとに応じて決定されるタイミングに基づいて前記サーバから送信されたメッセージを、前記通信部を介して受信するステップと、
   受信した前記メッセージを前記ユーザに対して表示するステップと、
   を含むことを特徴とする制御方法。
7. 複数のゲーム媒体を有するゲームの処理を実行する情報処理装置であって、
   記憶部と、
   通信部と、
   制御部と、を備え、
   前記制御部は、
   ユーザによって設定された前記複数のゲーム媒体の中の少なくとも１つおよびメッセージを受信したいタイミングと、ユーザによって設定されたゲーム媒体に関連付けられた特性パラメータと、を含むメッセージ設定情報を、前記記憶部に記憶させて、
   前記記憶部に記憶された前記メッセージ設定情報を、前記通信部を介してサーバに送信し、
   前記メッセージ設定情報に含まれる前記タイミングと特性パラメータとに応じて決定されるタイミングに基づいて前記サーバから送信されたメッセージを、前記通信部を介して受信し、
   受信した前記メッセージを前記ユーザに対して表示する
   ことを特徴とする情報処理装置。

Images