【文献】
電撃PlayStation Vol.583,株式会社KADOKAWA,2015年 1月29日,第21巻/第4号/通巻694号,p.192−p.197,「ファンタシースターオンライン2」に関する記事
(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0011】
(ゲームシステムの概要)
図1に示すように、ゲームシステム10は、サーバ装置11と、複数の端末装置12と、を備える。
図1では簡便のため、3つの端末装置12を図示しているが、端末装置12の数は1つ以上であればよい。
【0012】
サーバ装置11は、例えばゲーム運営者が管理する情報処理装置である。端末装置12は、例えば携帯電話、スマートフォン、タブレット端末、PC(Personal Computer)、又はゲーム装置等の、ユーザによって使用される情報処理装置である。サーバ装置11及び端末装置12は、例えばインターネット等のネットワーク16を介して通信可能に接続される。例えば、サーバ装置11及び端末装置12が協働して、ゲームに関する多様な処理を実行する。
【0013】
(ゲームの概要)
ゲームシステム10で実行されるゲームは、多様なゲームコンテンツを含む。多様なゲームコンテンツのうち少なくとも一部のゲームコンテンツは、ゲーム媒体を用いて実行されてもよい。
【0014】
ゲーム媒体は、ゲームに使用される電子データであり、ユーザによってゲーム内で取得、所有、使用、管理、交換、合成、強化、売却、廃棄、又は贈与等され得る。例えば、ゲーム媒体は、カード、アイテム、仮想通貨、チケット、キャラクタ、アバタ、レベル情報、ステータス情報、及びパラメータ情報(体力値、攻撃力など)、能力情報(スキル、アビリティ、呪文、ジョブなど)等、任意の媒体を含む。ゲーム媒体の利用態様は本明細書で明示されるものに限られない。
【0015】
以下、特に明示した場合を除き、「ユーザが所有するゲーム媒体」とは、所有ゲーム媒体としてユーザを一意に識別可能なユーザIDに対応付けられたゲーム媒体を示す。また、「ゲーム媒体をユーザに付与する」とは、ゲーム媒体を所有ゲーム媒体としてユーザIDに対応付けることを示す。また、「ユーザが所有するゲーム媒体を売却する」とは、ユーザIDと所有ゲーム媒体との対応付けを解消し、かつ、ユーザIDに他のゲーム媒体(例えば、仮想通貨又はアイテム等)を所有ゲーム媒体として対応付けることを示す。
【0016】
ゲームコンテンツは、ゲーム内でユーザがプレイ可能なコンテンツであって、例えばクエスト、ミッション、ミニゲーム、ゲーム媒体の育成、強化、及び合成、ゲーム媒体入手イベント、仮想空間の探索イベント、並びに対戦相手(例えば、他のユーザ、敵キャラクタ、及び敵の建物等)との対戦イベント等を含む。例えば、ゲームコンテンツ毎に設定される1つ以上の所定の条件(ゲーム課題)の達成に成功したと判定された場合、ユーザに対して、例えばゲーム媒体等が報酬として付与されてもよい。ゲーム課題には、例えば敵キャラクタとの対戦に勝利するとの課題、及び仮想空間内のゴール地点まで到達するとの課題等、ゲームコンテンツの内容に応じた任意の課題が採用可能である。また、ゲームコンテンツに設定された1つ以上のゲーム課題のうち、特定の課題(クリア課題)が達成されることを、ゲームコンテンツのクリアともいう。ゲームコンテンツをプレイするユーザがクリア課題の達成に成功した場合、当該ゲームコンテンツのクリアと判定され、当該ゲームコンテンツが終了してもよい。
【0017】
多様なゲームコンテンツには、シングルプレイ用のゲームコンテンツと、マルチプレイ用のゲームコンテンツと、が含まれてもよい。シングルプレイ用のゲームコンテンツとは、1のユーザが使用する1の端末装置12に対するユーザ操作に基づいて実行されるゲームコンテンツ(例えば、一人用のゲームコンテンツ)である。1の端末装置12が単独で、又は1の端末装置12とサーバ装置11とが協働して、シングルプレイ用のゲームコンテンツを実行する。一方、マルチプレイ用のゲームコンテンツとは、2つ以上のユーザがそれぞれ使用する2つ以上の端末装置12に対するユーザ操作に基づいて実行される、当該2つ以上のユーザに共通のゲームコンテンツ(例えば、複数人用のゲームコンテンツ)である。2つ以上のユーザに共通のゲームコンテンツとは、例えば当該ゲームコンテンツの進行処理及び処理結果等の少なくとも一部が、当該2つ以上のユーザに対して共通して適用されるゲームコンテンツを含んでもよい。2つ以上の端末装置12が協働して、又は2つ以上の端末装置12とサーバ装置11とが協働して、マルチプレイ用のゲームコンテンツを実行する。
【0018】
本実施形態において、ゲームは、ユーザがゲーム媒体を操作して対戦を行うゲームコンテンツを含む。以下、当該ゲームコンテンツを対戦コンテンツともいう。対戦コンテンツに用いられるゲーム媒体は、例えばユーザがゲーム内で所有するキャラクタを含むものとして説明するが、これに限られない。また、対戦相手は、例えばノンプレイヤキャラクタ等の敵キャラクタを含むものとして説明するが、これに限られない。例えば、マルチプレイ用のゲームコンテンツにおいて、他のユーザが操作するゲーム媒体が対戦相手に定められてもよい。
【0019】
例えば、本実施形態におけるゲームの一つの対戦コンテンツは、ユーザが所有するキャラクタの中から所定の数のキャラクタを選択する。ここで、ユーザは助っ人キャラクタ(「ヘルパー」、単に「助っ人」とも呼ばれる)を選択してデッキに加えることで、デッキの対戦能力を向上させることが可能である。そして、ユーザはデッキの一部または全部のキャラクタを用いて敵キャラクタと対戦を行う。ここで、デッキを組むとは、ユーザが所有するキャラクタおよび助っ人キャラクタの中から選択したキャラクタで、対戦を行うパーティ(チームまたはグループ)を作ることである。
【0020】
(サーバ装置の構成)
サーバ装置11は、サーバ通信部13と、サーバ記憶部14と、サーバ制御部15と、を備える。
【0021】
サーバ通信部13は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。サーバ通信部13は、例えば無線LAN(Local Area Network)通信モジュール又は有線LAN通信モジュール等を含んでもよい。サーバ通信部13は、ネットワーク16を介して、端末装置12との間で情報を送受信可能である。
【0022】
サーバ記憶部14は、例えば一次記憶装置及び二次記憶装置を含む。例えばサーバ記憶部14は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。サーバ記憶部14は、ゲームの提供及び制御に必要な種々の情報及びプログラムを記憶する。サーバ記憶部14に記憶された情報及びプログラムの少なくとも一部が、端末装置12との間で共有及び同期されてもよい。例えばサーバ記憶部14は、1つ以上のユーザに関する情報を記憶する。
【0023】
また、サーバ記憶部14は、敵キャラクタの情報を記憶してもよい。敵キャラクタは、対戦において、ユーザが使用するキャラクタの対戦相手として用いられる。敵キャラクタの情報は、敵キャラクタの任意の情報を含む。
【0024】
また、サーバ記憶部14は、メッセージ設定情報を記憶してもよい。後述するように、メッセージ設定情報は、ユーザが設定したキャラクタ、メッセージを受信したいタイミングおよび特性パラメータ等を含む。
【0025】
サーバ制御部15は、特定のプログラムを読み込むことにより特定の機能を実現する1つ以上の汎用プロセッサ、及び特定の処理に特化した1つ以上の専用プロセッサのうち、少なくとも一方を含む。サーバ制御部15は、サーバ装置11全体の動作を制御する。
【0026】
サーバ制御部15は、ゲームの処理に必要な種々の情報及びプログラムを、サーバ記憶部14に記憶する。ゲームの処理に必要な情報には、上述したユーザに関する情報及び敵キャラクタの情報、並びに対戦の実行に必要な情報等が含まれてもよい。
【0027】
サーバ制御部15は、サーバ通信部13を介して情報の送受信を行う。例えば、サーバ制御部15は、サーバ記憶部14に記憶された情報の少なくとも一部を端末装置12へ送信してもよい。このようにして、サーバ記憶部14に記憶された情報と端末装置12に記憶された情報が共有及び同期される。情報の共有及び同期を行うタイミングは、例えばサーバ記憶部14に新たな情報が記憶されたタイミング、及びサーバ記憶部14に記憶された情報が更新されたタイミングを含み得るが、任意に定められてもよい。
【0028】
サーバ制御部15は、端末装置12と協働して、ゲームの処理を実行する。ゲームの処理には、例えばユーザがゲームシナリオを進行させることでカードを取得する処理と、取得したカードについて交換、売却、合成等を行う処理と、カードに対応するキャラクタでデッキを組んで敵キャラクタと対戦する処理と、が含まれてもよい。
【0029】
また、サーバ制御部15は、端末装置12と協働して、ゲームに関するメッセージを生成して送信する処理を実行する。本実施形態においては、サーバ制御部15が、端末装置12へのプッシュ通知として、メッセージを生成して送信する。ここで、サーバ制御部15は、別の情報処理装置にメッセージの生成(例えば内容の設定および送信時刻の演算)および送信の少なくとも一つを実行させてもよい。例えば、メッセージは、サーバ制御部15の指示に基づいて、別の情報処理装置から端末装置12に送信されてもよい。
【0030】
(端末装置の構成)
図1に示すように、端末装置12は、端末通信部17と、端末記憶部18と、表示部19と、入力部20と、端末制御部21とを備える。
【0031】
端末通信部17は、外部装置と無線又は有線によって通信し、情報の送受信を行うインタフェースを含む。端末通信部17は、例えばLTE(Long Term Evolution)(登録商標)等のモバイル通信規格に対応する無線通信モジュール、無線LAN通信モジュール、又は有線LAN通信モジュール等を含んでもよい。端末通信部17は、ネットワーク16を介して、サーバ装置11との間で情報を送受信可能である。
【0032】
端末記憶部18は、例えば一次記憶装置及び二次記憶装置を含む。例えば端末記憶部18は、半導体メモリ、磁気メモリ、又は光メモリ等を含んでもよい。端末記憶部18は、ゲームの処理に必要な種々の情報及びプログラムを記憶する。例えば端末記憶部18は、上述したユーザに関する情報の一部又は全部を記憶してもよい。また、例えば端末記憶部18は、上述した敵キャラクタの情報を記憶してもよい。また、例えば端末記憶部18は、上述したメッセージ設定情報を記憶してもよい。これらの情報の一部又は全部は、例えば端末制御部21によってサーバ装置11との間で送受信される。
【0033】
表示部19は、例えば液晶ディスプレイ又は有機ELディスプレイ等の表示デバイスを含む。表示部19は、多様な画面を表示可能である。
【0034】
入力部20は、例えば表示部19と一体的に設けられたタッチパネル等の入力インタフェースを含む。入力部20は、端末装置12に対するユーザ入力を受付可能である。本実施形態において、表示部19と入力部20とは一体化されてタッチパネルディスプレイを構成する。タッチパネルディスプレイは、入力部20として静電容量の変化を検出する透明なセンサー層を備え、静電容量の変化を検出することで、ユーザによって接触された位置を検出できる。ここで、静電容量方式以外の方式が採用されてもよい。また、入力部20は、物理キーを含んでもよいし、マウス等のようなポインティングデバイスをはじめとする任意の入力インタフェースをさらに含んでもよい。
【0035】
端末制御部21は、特定のプログラムを読み込むことにより特定の機能を実現する1つ以上の汎用のプロセッサ、及び特定の処理に特化した1つ以上の専用のプロセッサのうち、少なくとも一方を含む。端末制御部21は、端末装置12全体の動作を制御する。
【0036】
端末制御部21は、端末通信部17を介して情報の送受信を行う。例えば、端末制御部21は、ゲームの処理に必要な情報をサーバ装置11との間で送受信する。例えば、端末制御部21は、サーバ装置11から受信した情報を、端末記憶部18に記憶する。
【0037】
端末制御部21は、ユーザの操作に応じてゲームのアプリケーションを起動する。端末制御部21は、サーバ装置11と協働して、ゲームの処理を実行する。例えば、端末制御部21は、種々の画面を表示部19に表示させる。画面上には、例えばGUI(Graphic User Interface)が表示されてもよい。端末制御部21は、画面に対するユーザ操作を検出可能である。
【0038】
(記憶部に記憶される情報)
図2は、少なくとも3人のユーザを含むユーザに関する情報110を示す。ユーザに関する情報110は、例えばサーバ記憶部14に記憶されて、端末装置12との間で共有及び同期される。つまり、ユーザに関する情報110は、端末装置12の端末記憶部18に記憶される。ユーザに関する情報110はユーザの種々の情報を含む。本実施形態において、ユーザに関する情報110は、ユーザIDと、所有するカードの情報111(
図3参照)と、を含む。つまり、ユーザに関する情報110は、複数のユーザそれぞれと、所有するカードの情報111と、を対応付けている。
【0039】
ユーザIDは、上述したようにユーザを一意に識別可能な情報である。
【0040】
所有するカードの情報111は、ユーザがゲーム内で所有するカードの種々の情報を含む。カードがユーザに取得された場合、取得されたカードはユーザに対応付けられる。本実施形態において、カードはキャラクタカードである。そのため、所有するカードの情報111はカードに対応付けられたキャラクタの種類および特性に関する情報を含む。ここで、カードはキャラクタカードに限定されるものではない。
【0041】
図3は、所有するカードの情報111の詳細を例示する図である。
図3は、1人のユーザの所有するカードの情報111を示す。所有するカードの情報111は、カードIDと、キャラクタIDと、レベルと、レアリティと、属性と、対戦パラメータと、スキルIDと、に関するデータを含む。所有するカードの情報111は、これらのデータの全てを含むものに限定されない。また、所有するカードの情報111は、さらに別のデータを含んでもよい。
【0042】
カードIDは、ユーザが所有するカードを一意に識別するIDである。
図3の例では、カードIDとして重複しない数字が用いられている。以下、カードIDが1であるカードを、カード1のように表記する。
【0043】
キャラクタIDは、ゲームのキャラクタを一意に識別するIDである。本実施形態において、カードはキャラクタカードであるため、1つのカードIDに1つのキャラクタIDが対応付けられている。
図3の例では、キャラクタIDとして重複しない英文字が用いられている。以下、キャラクタIDがAであるキャラクタを、キャラクタAのように表記する。ここで、1つのキャラクタには複数のカードが対応し得る。
図3の例では、カード1およびカード20は、どちらもキャラクタAのカードである。
【0044】
レベルは、キャラクタの成長度を示す情報である。例えば、レベルの値が大きいほど、キャラクタの成長度が大きい。レベルの値は、例えば対戦パラメータの値に影響する。
図3の例では、キャラクタCのレベルは10である。レベルの値は、ユーザがキャラクタを成長させることによって上昇する。例えば、ユーザがキャラクタを使ってゲームコンテンツ(例えばクエスト)をクリアすること、キャラクタにアイテムまたは他のキャラクタをかけ合せることで成長させることができる。
【0045】
レアリティは、カードの希少性の度合いを示す情報である。例えば、レアリティの値が大きいほど、カードの希少性の度合いが高い。カードの希少性の度合いが高いとは、例えば、ゲーム運営者がゲーム内で提供する当該カードの枚数が少ないこと等である。レアリティは固定的であってもよい。また、レアリティは、カードに応じて初期値が決まっており、ユーザによるゲームのプレイに応じて変化してもよい。レアリティは、例えば対戦パラメータの最大値に影響する。
図3の例ではレアリティは数字を用いている。例えば、カード1およびカード20はどちらもキャラクタAのカードである。しかし、レアリティが2であるカード1よりもレアリティが4であるカード20の方が希少性の度合いが高い。ここで、別の例として、レアリティはキャラクタに応じて決まってもよい。
【0046】
属性は、キャラクタが有する対戦等に関する特性であって、キャラクタ間の優劣関係を示す情報である。
図3の例では、属性の種類として火、水、風、光等が使用される。例えば、火の属性を有するキャラクタは、風の属性を有するキャラクタからの攻撃に強く、水の属性を有するキャラクタからの攻撃に弱くてもよい。
【0047】
対戦パラメータは、ゲーム内の対戦で参照されるキャラクタの強さを示す情報である。本実施形態において、各キャラクタはHP(ヒットポイント)、MP(マジックポイント)、AT(攻撃力)およびDF(防御力)の対戦パラメータを有する。ここで、対戦パラメータはHP、MP、ATおよびDFに限られるものではない。対戦パラメータは、例えば素早さ等のゲーム内の行動に関する対戦パラメータをさらに含んでもよい。また、対戦パラメータは、HP、MP、ATおよびDFの一部を含まなくてもよい。
【0048】
HPは、キャラクタのヒットポイント(体力値)を示す情報である。
図3では、HPの最大値が示されている。例えば、キャラクタが敵キャラクタの攻撃動作によってダメージを受けると、HPがダメージ量だけ減少する。また、例えばキャラクタの回復動作によって、HPは回復量だけ増加する。また、HPがゼロでなければキャラクタは戦闘可能状態であり、例えば敵キャラクタを攻撃することができる。しかし、HPがゼロまで減少するとキャラクタは戦闘不能状態になる。キャラクタのHPが大きいほど、ゲームコンテンツのクリアに有利である。
【0049】
MPは、キャラクタのマジックポイントを示す情報である。
図3では、MPの最大値が示されている。例えば、キャラクタが単体で行う、通常の攻撃(装備した武器による攻撃、魔法攻撃等)とは異なる特別な攻撃(以下、スキルという)を発動すると、MPはスキルに応じた値だけ減少する。また、例えばキャラクタの回復動作によって、MPは回復量だけ増加する。キャラクタのMPが大きいほど、ゲームコンテンツのクリアに有利である。
【0050】
ATは、キャラクタの攻撃力を示す情報である。ATは、例えばキャラクタの攻撃によって対戦相手に与えるダメージ量に影響する。ATの値が大きくなるほど、対戦相手に与えるダメージ量が大きくなる。したがって、キャラクタのATが大きいほど、ゲームコンテンツのクリアに有利である。
【0051】
DFは、キャラクタの防御力を示す情報である。DFは、例えばキャラクタが対戦相手からの攻撃によって受けるダメージ量に影響する。DFの値が大きくなるほど、対戦相手から受けるダメージ量が小さくなる。したがって、キャラクタのDFが大きいほど、ゲームコンテンツのクリアに有利である。
【0052】
ここで、
図3の例では各キャラクタのHP、MP、ATおよびDFの値は一例である。HP、MP、ATおよびDFは独立した対戦パラメータであって、それぞれが独立に設定され得る。
【0053】
スキルIDは、カードのキャラクタが有するスキルを一意に識別するIDである。スキルはカード毎に設定されている。ここで、スキルは全カードに設定されなくてもよい。つまり、スキルのないカードが存在してもよい。上記のように、スキルの発動によってMPは減少する。MPの値が不足する場合、キャラクタは、スキルを発動することができない。以下、スキルIDがS1であるスキルを、スキルS1のように表記する。例えば、スキルS1は、キャラクタAが敵キャラクタ全体に対して、火属性の中ダメージを与える攻撃であってもよい。また、例えば、スキルS20は、キャラクタAが敵キャラクタ全体に対して、風属性の特大ダメージを与える攻撃であってもよい。
【0054】
図4は、メッセージ設定情報114を例示する図である。メッセージ設定情報114は、例えば端末記憶部18に記憶されて、サーバ装置11との間で共有される。メッセージ設定情報114は、本実施形態において端末装置12へのプッシュ通知として送信されるメッセージの設定に関する情報である。
【0055】
図4に示すように、メッセージ設定情報114は、キャラクタIDと、特性パラメータと、イベントと、タイミング設定と、を含む。後述するように、特性パラメータは、親密度と、最高レベルと、保有割合と、性格と、を含む。また、タイミング設定は、希望タイミングと、補正時間と、を含む。ここで、キャラクタID、イベント、および、希望タイミングは、後述するメッセージ設定画面におけるユーザの指定に基づいて設定される。その他の項目は、端末記憶部18に記憶されたゲームデータ(例えばキャラクタ設定、進行記録等)および所有するカードの情報111に基づいて、端末制御部21が抽出または演算することによって設定される。メッセージ設定情報114は、これらのデータ項目の全てを含むものに限定されない。例えば、メッセージ設定情報114は、最高レベルおよび保有割合を含まなくてもよい。また、メッセージ設定情報114は、さらに別のデータ項目を含んでもよい。例えば、メッセージ設定情報114は、さらにキャラクタIDに対応するキャラクタを使用してゲームをプレイした時間を含んでもよい。
【0056】
キャラクタIDはキャラクタを一意に識別するID(識別子)である。キャラクタIDは、所有するカードの情報111(
図3参照)のキャラクタIDと共通であってもよいし、異なる固有のIDが使用されてもよい。キャラクタIDは、ユーザが指定したお気に入りのキャラクタのIDであって、例えばメッセージ中のキャラクタ画像を指定するために使用される。本実施形態において、ユーザは後述するメッセージ設定画面でお気に入りのキャラクタを選択する。そして、選択されたキャラクタのIDがメッセージ設定情報114に設定される。
図4の例では、キャラクタBが選択されている。ここで、別の例として、ユーザはメッセージ設定画面でなく、ゲーム内のシステム設定でお気に入りのキャラクタを選択してもよい。また、さらに別の例として、例えばゲーム内でのデッキにおいてリーダに設定されたキャラクタが、自動的にお気に入りのキャラクタとなってもよい。これらの場合に、端末制御部21はゲームデータに基づいてメッセージ設定情報114のキャラクタIDを設定する。以下において、メッセージ設定情報114のキャラクタIDに対応するキャラクタを「お気に入りキャラクタ」という。
【0057】
ここで、お気に入りキャラクタを含む全てのキャラクタについて、ゲーム設定およびユーザのゲーム進行等に応じて変化する様々なパラメータがゲームデータ等で設定されている。本実施形態においては、メッセージ設定情報114の特性パラメータとして、お気に入りキャラクタについての親密度、最高レベル、保有割合および性格が用いられる。親密度は、ゲームにおけるユーザとお気に入りキャラクタとの親密さを、数値で示したものである。本実施形態においては、ユーザとお気に入りキャラクタとが親しいほど、親密度の数値が大きくなる。親密度はゲームの進行に応じて変化する。例えばユーザがお気に入りキャラクタを使用してゲームのシナリオを進行させたり、ゲーム内でお気に入りキャラクタにプレゼント(例えばアイテム等)をあげたりすると、親密度の数値が大きくなる。また、ユーザがお気に入りキャラクタに関するイベントを進行させることによって、親密度の数値が大きくなってもよい。お気に入りキャラクタに関するイベントは、例えば期間限定であって、そのストーリーにお気に入りキャラクタが主役として、または、準主役として登場するイベントである。ユーザがお気に入りキャラクタに関するイベントを進行させる場合に、親密度の数値は、ゲームの通常のシナリオの場合よりも大きくなってもよい。端末制御部21はゲームデータに基づいてメッセージ設定情報114の親密度を設定する。
図4の例では、親密度は9であり、初期状態(親密度が1)よりも親密さが向上している。
【0058】
最高レベルは、ユーザが所有するお気に入りキャラクタのカードのレベルのうち、最も値が大きいものである。最高レベルは、お気に入りキャラクタの成長度に関連する。最高レベルは、後述するようにメッセージの内容が設定されるときに、例えば親密度に代えて、または、親密度と共に参照されてもよい。端末制御部21は所有するカードの情報111に基づいてメッセージ設定情報114の最高レベルを設定する。
図4の例では、キャラクタBの最高レベルは5であり、初期状態(レベルが1)よりも成長している。
【0059】
保有割合は、ユーザが所有する全てのカードのうちお気に入りキャラクタのカードが占める割合を表す。保有割合は、ユーザがお気に入りキャラクタのカードを好んで収集しているか否かに関連する。保有割合は、後述するようにメッセージの内容が設定されるときに、例えば親密度に代えて、または、親密度と共に参照されてもよい。端末制御部21は所有するカードの情報111に基づいてメッセージ設定情報114の保有割合を演算する。
図4の例では、ユーザが所有するカードの12%がキャラクタBのカードである。
【0060】
性格は、お気に入りキャラクタのゲームにおける性質であって、ゲームデータで定められている。性格は、例えばメッセージの内容および後述する補正時間等に影響し得る。性格は、例えばのんびり、せっかち、および、几帳面等を含んでもよい。
図4の例では、キャラクタBの性格は「のんびり」である。性格は、後述するようにメッセージの送信時刻が演算されるときに、参照されてもよい。端末制御部21はゲームデータに基づいてメッセージ設定情報114の性格を設定する。
【0061】
イベントは、ユーザがメッセージ(例えばイベント開始を知らせるもの等)による通知を希望するイベントを示す。
図4の例では、イベントは「全て」である。そのため、実施される全てのイベントに関するメッセージが、ユーザの端末装置12にプッシュ通知として送信される。本実施形態において、ユーザは後述するメッセージ設定画面でイベントを選択する。そして、選択されたイベントがメッセージ設定情報114に設定される。ここで、別の例として、ユーザはメッセージ設定画面でなく、ゲーム内のシステム設定でイベントを選択してもよい。このとき、端末制御部21はゲームデータに基づいてメッセージ設定情報114のイベントを設定する。
【0062】
希望タイミングは、ユーザがメッセージを受信したいタイミングを示す。
図4の例では、希望タイミングはイベントの「開始時」である。つまり、ユーザはイベントが開始されると同時にメッセージを受信することを希望している。本実施形態において、ユーザは後述するメッセージ設定画面で希望タイミングを選択する。そして、選択された希望タイミングがメッセージ設定情報114に設定される。ここで、別の例として、ユーザはメッセージ設定画面でなく、ゲーム内のシステム設定で希望タイミングを選択してもよい。このとき、端末制御部21はゲームデータに基づいてメッセージ設定情報114の希望タイミングを設定する。
【0063】
補正時間は、メッセージ設定情報114におけるメッセージを受信したいタイミング(希望タイミング)と、端末装置12がメッセージを受信するタイミングと、の時間差に対応する。補正時間は、お気に入りキャラクタの性格に応じて定められる。
図4の例では、キャラクタBの性格がのんびりであるため、補正時間は「10分遅く」に設定される。つまり、メッセージは希望タイミングよりも10分遅く届けられる。補正時間は、例えばメッセージ設定情報114に設定されている性格に基づいて、端末制御部21によって演算される。ここで、端末装置12がメッセージを受信するタイミングと、送信元(例えばサーバ装置11)がメッセージを送信するタイミングとは、通信に要する時間だけ異なる。しかし、本明細書では説明をわかりやすくするために、端末装置12がメッセージを受信するタイミングと、送信元がメッセージを送信するタイミングとは同じであるとして説明する。
【0064】
ここで、性格および補正時間の少なくとも一方は、メッセージ設定情報114に含まれなくてもよい。後述するように、端末記憶部18に記憶されたメッセージ設定情報114は、端末装置12からサーバ装置11に送信される。性格および補正時間の少なくとも一方は、サーバ装置11がメッセージ設定情報114を取得した後に、サーバ制御部15が抽出または演算することによって設定されてもよい。例えば、サーバ制御部15は、メッセージ設定情報114からキャラクタIDを抽出する。そして、サーバ制御部15は、サーバ記憶部14に記憶されたゲームデータからキャラクタIDに対応する性格を抽出してもよい。また、例えばサーバ制御部15は、抽出した性格に応じて補正時間を演算してもよい。
【0065】
(画面表示例)
図5はメッセージ設定画面を例示する図である。端末装置12は、表示部19にメッセージ設定画面を表示して、メッセージ設定情報をユーザに設定させる。ユーザがメッセージ設定画面で選択した、お気に入り、イベントおよびタイミングは、それぞれ、メッセージ設定情報114(
図4参照)のキャラクタID、イベントおよび希望タイミングに反映される。
【0066】
端末装置12の表示部19に表示されるメッセージ設定画面は、画面の上部の領域で、お気に入りのキャラクタをユーザに選択させる。
図5に示すように、ユーザの選択に用いられるキャラクタのアイコン41が表示される。ユーザはアイコン41をタップすることによって、タップしたキャラクタをお気に入りキャラクタに指定することができる。
図5の例では、ユーザは8つのキャラクタA〜Hのうち、キャラクタBをお気に入りキャラクタに指定している。ここで、メッセージ設定画面においては、タップして選択した対象をもう一度タップすることによって、非選択状態に戻すことが可能である。つまり、ユーザは選択のやり直しが可能である。
【0067】
また、メッセージ設定画面は、画面の中央部分の領域で、イベントをユーザに選択させる。
図5に示すように、同領域には、ユーザが選択可能であるように、実施予定のイベントがリスト表示される。リストには、具体的なイベント名(例えばイベントX、イベントY等)だけでなく、対象とするイベントの範囲(例えば対戦イベントのみ、全てのイベント等)が表示される。
図5の例では、ユーザは「全てのイベント」を選択している。つまり、ユーザは実施予定の全てのイベントに関するメッセージ(例えばプッシュ通知)を受け取ることを選択している。
【0068】
また、メッセージ設定画面は、画面の下部の領域で、メッセージを受信したいタイミングをユーザに選択させる。
図5に示すように、同領域には、ユーザが選択可能であるように通知時間がリスト表示される。
図5の例では、ユーザは「開始時」を選択している。つまり、ユーザはメッセージをイベントの開始時に受け取ることを選択している。
【0069】
また、メッセージ設定画面の一番下には、設定ボタンとキャンセルボタンが設けられている。ユーザが設定ボタンをタップすると、ユーザがメッセージ設定画面で選択した内容が、メッセージ設定情報114に反映される。また、ユーザがキャンセルボタンをタップすると、メッセージ設定情報114は更新されずに、ユーザの選択内容がキャンセルされる。
【0070】
ここで、メッセージ設定画面でさらに期間が設定可能であってもよい。期間は、ユーザがメッセージ34を受信したい期間であって、例えば8月中、9月1日〜9月3日、今から1週間、休日だけ等の設定が可能であってもよい。期間が設定された場合に、期間外のメッセージ34は受信されない。そのため、ユーザは、メッセージ34の受信についてより細かく設定可能になる。例えば、仮にユーザが全てのイベントを選択していても、設定された期間を過ぎると、ユーザの端末装置12はメッセージ34を受信しなくてもよい。
【0071】
図6は、
図4のメッセージ設定情報114に対応するメッセージ34を例示する図である。本実施形態において、メッセージ34はプッシュ通知である。
図6に示すように、端末装置12でゲームのアプリケーションが起動していない状態(例えば画面がロックされた状態)であっても、ユーザにメッセージ34を通知することが可能である。後述するように、例えばサーバ装置11は、メッセージ設定情報114に基づいて、端末装置12に通知するメッセージ34の送信時刻を演算し、メッセージ34の内容を設定する。サーバ装置11が送信時刻に通知したメッセージは、
図6に示すように、端末装置12の表示部19に表示される。
【0072】
メッセージ34の内容は、お気に入りキャラクタの画像(アイコン41)と、送信時刻(または受信時刻)と、本文であるテキスト42と、を含む。
図6の例では、アイコン41はお気に入りキャラクタであるキャラクタBの画像である。また、テキスト42も、キャラクタBのゲーム内での口調等に合わせた記載になっている。ここで、
図4のように、キャラクタBの性格は「のんびり」であり、補正時間が「10分遅く」に設定されている。そのため、メッセージ34は、ユーザの希望タイミング(イベントXの開始時の○月○日00:00)から10分遅れた時刻に送信されている。
【0073】
ここで、
図7はメッセージ設定情報114の別の例を示す。
図7のメッセージ設定情報114では、お気に入りキャラクタはキャラクタAに設定されている。
図7の例では、キャラクタAの性格は「せっかち」である。そのため、補正時間は「10分早く」に設定されている。また、
図7の例では、希望タイミングはイベントの「1時間前」である。つまり、ユーザはイベントが開始される1時間前にメッセージを受信することを希望している。
【0074】
図8は、
図7のメッセージ設定情報114に対応するメッセージ34を例示する図である。
図8の例では、アイコン41はお気に入りキャラクタであるキャラクタAの画像である。また、テキスト42も、キャラクタAのゲーム内での口調等に合わせた記載になっている。また、
図8の例では、メッセージ34は、ユーザの希望タイミング(イベントXの開始の1時間前である○月×日23:00)から更に10分早い時刻(○月×日22:50)に送信されている。
【0075】
このように、メッセージ34は、お気に入りキャラクタの口調等に合わせた内容で、その性格を反映した時刻に送信される。そのため、ユーザは、メッセージ34に対して、指定時刻に画一的な文面で送信される広告ではなく、現実の人物からのメールを受け取ったときのような親近感を覚える。また、ユーザは、メッセージ34が自分だけに向けた内容であるかのように感じて、従来の画一的内容のメッセージにはなかった特別感を覚える。ここで、上記の例では、メッセージ34の送信時刻はユーザの希望タイミングと異なっている。しかし、例えばユーザがメッセージ設定画面で、性格が「几帳面」であるキャラクタCを選択した場合には、補正時間は「ちょうど」に設定される。つまり、例えばお気に入りキャラクタを変更することによって、ユーザの希望タイミング通りにメッセージ34を受信することが可能である。
【0076】
図9は、親密度とメッセージ34の内容との関係を説明するための図である。本実施形態において、メッセージ34の内容は、性格以外のお気に入りキャラクタの特性パラメータに影響される。
【0077】
図9は、親密度の高さに応じて切り替わる3つのメッセージ34を含む。以下において、3つのメッセージ34を上から順に、それぞれ、上段のメッセージ34、中段のメッセージ34、下段のメッセージ34という。お気に入りキャラクタの親密度が低い(例えば1〜5の範囲内である)とき、ユーザは上段のメッセージ34を受信する。上段のメッセージ34のアイコン41のお気に入りキャラクタの表情は例えば不機嫌な顔である。また、上段のメッセージ34のテキスト42の記載量は少ない。また、上段のメッセージ34のテキスト42の文面はよそよそしい印象を与えるものであってもよい。
【0078】
お気に入りキャラクタの親密度が中程度(例えば5〜9の範囲内である)とき、ユーザは中段のメッセージ34を受信する。中段のメッセージ34のアイコン41のお気に入りキャラクタの表情は例えばすました顔である。また、中段のメッセージ34のテキスト42の記載量は、上段のメッセージ34よりも多い。また、中段のメッセージ34のテキスト42の文面は知り合いとの会話であるような印象を与えるものであってもよい。
【0079】
お気に入りキャラクタの親密度が高い(例えば10以上である)とき、ユーザは下段のメッセージ34を受信する。下段のメッセージ34のアイコン41のお気に入りキャラクタの表情は例えば笑顔である。また、下段のメッセージ34のテキスト42の記載量は、中段のメッセージ34よりもさらに多い。また、下段のメッセージ34のテキスト42の文面は親友との会話であるような印象を与えるものであってもよい。
【0080】
本実施形態において、メッセージ34の内容は、後述するようにサーバ装置11によって設定される。サーバ装置11は、端末装置12から受け取ったメッセージ設定情報114の特性パラメータ(
図9の例では親密度)を抽出する。サーバ装置11は、抽出した特性パラメータに基づいてメッセージ34の内容を設定する(
図9の例では上段、中段または下段のメッセージ34を選択する)。そして、サーバ装置11は、特性パラメータに応じた内容のメッセージ34を端末装置12に送信する。ユーザは、お気に入りキャラクタとの親密度が高い程、より親近感を覚えるメッセージ34を受け取ることが可能である。ここで、親密度は、ユーザがゲームを進行させることによって高まる。したがって、上記のように特性パラメータに応じた内容のメッセージ34を用意することによって、ユーザにゲームへの一層の参加を促す効果が生じ得る。
【0081】
ここで、
図9の例では親密度に応じて、アイコン41(お気に入りキャラクタの表情)およびテキスト42が変化したが、一方だけが変化してもよい。例えば上段、中段および下段のメッセージ34のテキスト42は共通であって、アイコン41が親密度に応じて変化してもよい。また、
図9の例では親密度に応じたメッセージ34の変化は3段階であったが、これに限らない。例えば、親密度に応じた、より多くのメッセージ34の切り替えがあってもよい。また、例えば、親密度に応じて、2段階にメッセージ34が切り替えられてもよい。
【0082】
また、
図9の例では親密度に応じてメッセージ34が変化するが、親密度に代えて、または、親密度と共に他の特性パラメータ(例えば最高レベルおよび保有割合の少なくとも一方)が用いられてもよい。例えば、最高レベルが高い(例えば10以上である)とき、ユーザは
図9の下段のメッセージ34を受信してもよい。また、例えば、保有割合が高い(例えば20%以上である)とき、ユーザは
図9の下段のメッセージ34を受信してもよい。ここで、ユーザは、ゲームを進行させることによって、最高レベルおよび保有割合を高めることが可能である。したがって、この場合にも、ユーザにゲームへの一層の参加を促す効果が生じ得る。
【0083】
(シーケンス図)
図10は、情報処理装置(端末装置12およびサーバ装置11)が実行する上記のメッセージ34に関する制御方法を示すシーケンス図である。ここで、以下のシーケンス図の説明におけるゲーム媒体の具体例はキャラクタである。
【0084】
まず、端末装置12は、メッセージ設定情報114をユーザに設定させる(ステップS1)。端末装置12は、例えば表示部19にメッセージ設定画面を表示して、複数のゲーム媒体の中の少なくとも1つ(お気に入りキャラクタ)およびメッセージを受信したいタイミング(希望タイミング)を、ユーザに設定させる。端末装置12は、さらに、メッセージ34による通知を希望するイベントを、ユーザに設定させてもよい。端末装置12は、メッセージ設定情報114の全てをユーザに設定させる必要がない。つまり、端末装置12は、その一部をユーザに設定させるだけでよい。
【0085】
端末装置12は、メッセージ設定情報114を端末記憶部18に記憶する(ステップS2)。端末装置12は、例えばお気に入りキャラクタの特性パラメータおよび補正時間を加えて、
図4に示すようなメッセージ設定情報114を端末記憶部18に記憶してもよい。
【0086】
端末装置12は、端末記憶部18に記憶したメッセージ設定情報114を、端末通信部17によってサーバ装置11に送信する(ステップS3)。ここで、送信されるメッセージ設定情報114は、全ての項目を含んでいてもよいし、一部の項目だけを含んでいてもよい。
【0087】
サーバ装置11は、サーバ通信部13によって受信したメッセージ設定情報114を端末装置12のID(識別情報)に関連付けて、サーバ記憶部14に記憶する(ステップS4)。端末装置12のIDは、例えばメッセージ設定情報114と共に端末装置12から送信される。端末装置12のIDは、例えばトークンであってもよいし、端末装置12のユーザに関連づけられた識別情報等であってもよい。端末装置12のIDは、メッセージ34を送信する宛先を特定するのに使用される。
【0088】
サーバ装置11は、メッセージ設定情報114の特性パラメータ(例えば性格)、イベントおよび希望タイミング等に基づいて、メッセージ34の送信時刻を演算する(ステップS5)。例えば、
図6のメッセージ34では、送信時刻はユーザの希望タイミング(○月○日00:00)から10分遅れた時刻(○月○日00:10)である。また、例えば、
図8のメッセージ34では、送信時刻はユーザの希望タイミング(○月×日23:00)から10分早い時刻(○月×日22:50)である。
【0089】
サーバ装置11は、メッセージ設定情報114の特性パラメータ(例えば親密度)に基づいて、メッセージ34の内容を設定する(ステップS6)。例えば、
図9のメッセージ34では、お気に入りキャラクタの親密度が10以上であれば、サーバ装置11は下段のメッセージ34を選択する。
【0090】
サーバ装置11は、ステップS5で演算した送信時刻になった場合に、ステップS6で設定した内容のメッセージ34を、端末装置12に送信する(ステップS7)。ここで、サーバ装置11は、別の情報処理装置にメッセージ34の生成(例えば内容の設定および送信時刻の演算)および送信の少なくとも一方を実行させてもよい。つまり、ステップS5〜S7の少なくとも1つの処理は、サーバ装置11の指示に基づいて、別の情報処理装置が実行してもよい。
【0091】
端末装置12は、他の情報処理装置(例えばサーバ装置11または別の情報処理装置)からのメッセージ34を、端末通信部17によって受信する(ステップS8)。つまり、端末装置12は、他の情報処理装置がメッセージ設定情報114に応じて送信時刻および内容の少なくとも一方を調整したメッセージ34を受信する。
【0092】
端末装置12は、受信したメッセージ34をユーザに対して表示する(ステップS9)。本実施形態では、受信したメッセージ34は、プッシュ通知として表示部19に表示される。
【0093】
以上述べたように、本実施形態に係る情報処理装置(例えば端末装置12)は、複数のゲーム媒体(例えば複数のキャラクタ)を有するゲームの処理を実行する。情報処理装置は、記憶部(例えば端末記憶部18)と、通信部(例えば端末通信部17)と、制御部(例えば端末制御部21)と、を備える。制御部は、ゲーム内で、メッセージ設定情報114として、複数のゲーム媒体の中の少なくとも1つ(例えば、お気に入りキャラクタ)およびメッセージを受信したいタイミング(例えば、希望タイミング)を、ユーザに設定させる。また、制御部は、メッセージ設定情報114を、記憶部に記憶させる。また、制御部は、記憶部に記憶されたメッセージ設定情報114を、通信部を介して送信する。また、制御部は、メッセージを、通信部を介して受信する。また、制御部は、受信したメッセージをユーザに対して表示する。ここで、情報処理装置がメッセージを受信するタイミングおよびメッセージの内容の少なくとも一方は、メッセージ設定情報114に応じて異なる。
【0094】
ここで、従来のゲームにおいても、ゲームの実行中にキャラクタの画像と共にメッセージが表示される機能を備えるものがあった。しかし、ゲームの起動中でなければ、メッセージを表示することができなかった。そのため、例えばユーザがゲーム内のイベントの開始を忘れないように、所定のタイミング(例えばイベント開始の1時間前等)でメッセージを通知するといった用途(アラーム)では、確実性を欠くため使用できなかった。このような用途では、ゲームの起動を必要としない、ゲーム外のメッセージ機能(例えばプッシュ通知)を利用することが好ましい。しかし、メッセージの内容が画一的であるような場合には、ゲームの進行状況またはお気に入りキャラクタとの関連性が少なく、ユーザに親近感または特別感を与えることは困難であった。本実施形態に係る情報処理装置は、上記の構成によって、ゲーム内での設定に応じて内容が変化するメッセージの通知を実行できる。本開示によれば、メッセージ34を受信するタイミングおよびメッセージ34の内容の少なくとも一方は、メッセージ設定情報114に応じて異なる。例えば、メッセージ設定情報114の内容はゲームの進行に応じて変化するため、メッセージ34においてもゲームの進行状況が反映される。また、例えば、メッセージ34を受信するタイミング等はお気に入りキャラクタの性格を反映したものとなるため、ユーザに親近感または特別感を与えることが可能である。
【0095】
(変形例等)
本開示を諸図面および実施形態に基づき説明してきたが、当業者であれば本開示に基づき種々の変形および修正を行うことが容易であることに注意されたい。したがって、これらの変形および修正は本開示の範囲に含まれることに留意されたい。例えば、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段またはステップ等を1つに組み合わせたり、或いは分割したりすることが可能である。
【0096】
上記の実施形態において、メッセージ34はゲーム内のイベントに関連する内容である。そして、ユーザはメッセージ設定画面において、イベントおよびイベントを基準にした時刻の設定を実行する。ここで、メッセージ34はイベントとは関係のない内容であってもよい。例えば、ユーザのログイン状況、ゲームの進捗状況、特定の日に該当するか否か等に応じて、所定の頻度でメッセージが通知されてもよい。例えば、ユーザが最後にログインしてから所定期間(例えば3日)経過した場合に、お気に入りのキャラクタからログインを促すメッセージ34が所定の頻度で端末装置12に送信されてもよい。また、例えば、ユーザのクエストが停滞している(例えば2日間ステージが進まない)場合に、お気に入りのキャラクタから励ますメッセージ34が所定の頻度で端末装置12に送信されてもよい。また、例えば、ユーザのランキングが低下した(例えば100位より大きく低下した)場合にも、励ますメッセージ34が所定の頻度で端末装置12に送信されてもよい。ここで、所定の頻度は、特性パラメータ(例えば親密度)に応じて変化してもよい。例えば、親密度が高い(一例として10以上である)とき、1日に3回、メッセージ34が端末装置12に送信されてもよい。また、例えば、親密度が低い(一例として1である)とき、2日に1回、メッセージ34が端末装置12に送信されてもよい。つまり、親密度が高いほど、ユーザはメッセージ34をより多く受信できてもよい。また、休日または記念日(例えばお気に入りのキャラクタの誕生日)に該当する場合には、これらに該当しない日よりも、メッセージ34が送信される頻度が高くなってもよい。
【0097】
また、メッセージ34がイベントとは関係のない内容である場合に、ユーザは時間、期間、および頻度等の設定が可能であってもよい。本変形例において、例えばイベントおよびタイミングに代えて、時間、期間、および頻度が設定可能なメッセージ設定画面が使用されてもよい。時間は、ユーザがメッセージ34を受信したい時間であって、例えば12:00である。また、期間は、ユーザがメッセージ34を受信したい期間であって、例えば9月10日〜9月30日である。また、頻度は、ユーザがメッセージ34を受信したい頻度であって、例えば平日のみである。この例の場合、ユーザは上記期間の平日の12:00に、正午を知らせるメッセージ34(イベントとは無関係)を受信する。この場合にも、上記の実施形態と同様に、キャラクタの性格に応じて受信が早まる、または、遅くなるといった変化が生じてもよい。
【0098】
また、上記の実施形態において、お気に入りキャラクタはユーザによって指定されている。ここで、お気に入りキャラクタは特定の条件が満たされた場合に、自動的に変更されてもよい。例えば、ユーザまたはユーザと所定の関係にあるユーザ(例えば同じグループのユーザまたはフレンド)がレアリティの高いカードを取得した場合に、お気に入りキャラクタはそのカードのキャラクタに自動的に変更されてもよい。また、例えば、ゲーム内で期間限定のイベントが開催中である場合に、お気に入りキャラクタはそのイベントに関連したキャラクタに自動的に変更されてもよい。このとき、イベントの期間が終了した後に、お気に入りキャラクタは自動的にユーザ指定のキャラクタに戻ってもよい。例えば、上記のように、サーバ装置11はユーザ指定のキャラクタの特性パラメータに基づいてメッセージ34の内容を設定する。このとき、サーバ装置11は、イベントの開催期間およびイベントに関連したキャラクタの情報をさらに取得(例えばゲームのイベント情報から抽出)してもよい。そして、サーバ装置11は、特定の条件が満たされる場合に、ユーザ指定のキャラクタに代えて、イベントに関連したキャラクタをメッセージ34で用いてもよい。ここで、特定の条件は、例えばイベントの開催期間中であること、イベントの開催まであと3日以内であること、新規登場のキャラクタに関するイベントであること、または、これらの組み合わせ等であってもよい。ユーザが設定しなくても自動的にお気に入りキャラクタを変更することによって、この変形例に係る情報処理装置は、ユーザに変化のあるゲーム体験を提供することができる。また、類似の変形例として、情報処理装置は、自動的にお気に入りキャラクタを変更するのではなく、候補となるキャラクタをユーザが選択可能なように表示してもよい。候補となるキャラクタは、例えば親密度等のパラメータに基づいて定められてもよい。また、候補となるキャラクタは、例えばゲーム内で開催中、または、開催予定のイベントとの関連性に応じて定められてもよい。候補となるキャラクタが表示されるため、ユーザは、お気に入りキャラクタの選択が容易となり、ユーザビリティが向上する。
【0099】
また、上記の実施形態において、補正時間は、お気に入りキャラクタの性格に関連付けられていた。ここで、メッセージ設定情報114にお気に入りキャラクタの「状態」が設定されており、「状態」に応じて補正時間が調整されてもよい。例えば「状態」は忙しい、忙しくない、○○時に予定あり、○日まで予定なし等、お気に入りキャラクタのゲーム内でのスケジュールに応じて設定されてもよい。また、ユーザがお気に入りキャラクタを用いてゲームを進行させたか否かに応じて、「状態」として例えば忙しい、忙しくない等が設定されてもよい。例えばお気に入りキャラクタの「状態」が忙しい場合に、補正時間は「10分遅く」に設定されてもよい。逆に、例えばお気に入りキャラクタの「状態」が忙しくない場合に、補正時間は「10分早く」に設定されてもよい。メッセージ設定情報114にお気に入りキャラクタの「状態」が設定されている場合に、補正時間は、お気に入りキャラクタの「性格」および「状態」の少なくとも一方に基づいて設定されてもよい。例えば、お気に入りキャラクタの「性格」がのんびりで、かつ、「状態」が忙しい場合に、補正時間は両方に基づいて「20分遅く」に設定されてもよい。また、例えば、お気に入りキャラクタの「性格」がせっかちで、かつ、「状態」が忙しい場合に、補正時間は「10分早く」と「10分遅く」とが打ち消し合って、「ちょうど」に設定されてもよい。
【0100】
また、上記の実施形態において、メッセージ34はプッシュ通知である。ここで、端末装置12に送信されたメッセージ34は、ユーザ毎に記憶部(端末記憶部18およびサーバ記憶部14の少なくとも一方)に記憶されてもよい。通常、プッシュ通知は所定の時間が経過すると消去されるが、記憶されることによって、ユーザがお気に入りのキャラクタからのメッセージ34を収集することを可能にする。例えば、端末制御部21は、受信したメッセージ34を時刻情報と関連付けて端末記憶部18に記憶させてもよい。このとき、ゲームのアプリケーションは、メッセージ34を記憶させる一部のプログラムだけがバックグラウンドで動作(常時動作)していてもよい。そして、ユーザから要求があった場合に、端末記憶部18に記憶されたメッセージ34を、時刻情報に応じた順に表示させてもよい。例えば、メッセージ34を時刻情報に応じた順に表示させる処理は、ゲームの特定の画面から実行可能であってもよい。また、記憶部に記憶されたメッセージ34は、ゲーム媒体(キャラクタ)毎に抽出可能であってもよい。また、記憶部に記憶されたメッセージ34は、特定の条件(例えばイベントXに関する内容を含む等)で抽出可能であってもよい。ユーザは例えばゲームの特定の画面において、このような絞り込み条件を設定できてもよい。
【0101】
また、端末装置12に送信されたメッセージ34がユーザ毎に記憶部に記憶される場合に、メッセージ34の履歴に応じてゲームの進行が変化してもよい。例えば、端末装置12は、お気に入りキャラクタとして選択されたキャラクタとメッセージ34の受信回数を関連付けて記憶し、キャラクタ毎のメッセージ34の受信回数を演算する。そして、その受信回数に基づいて、キャラクタのパラメータ(例えば対戦パラメータ)または特定のイベント(例えば特定のキャラクタに関連付けられたイベント)の内容が変化する。また、端末装置12は、キャラクタ毎のメッセージ34の受信回数に応じて、ゲーム内で特別なイベントを実行してもよい。このように、キャラクタと、メッセージ34の受信回数と、ゲーム内でのイベントと関連付けることによって、ユーザに特別なゲーム体験を提供することができる。また、本変形例において、キャラクタ毎のメッセージ34の受信回数に代えて、メッセージ34を受信してからユーザがメッセージ34に対して反応するまで(例えばゲームを起動するまで)の時間が用いられてもよい。また、本変形例において、キャラクタ毎のメッセージ34の受信回数に代えて、メッセージ34を受信した場合にユーザがメッセージ34に対して反応した回数が用いられてもよい。また、本変形例において、キャラクタ毎のメッセージ34の受信回数に代えて、メッセージ34を介して(例えばメッセージ34の文中のリンク等をタップして)ゲームを起動した回数が用いられてもよい。
【0102】
また、上記の実施形態において、メッセージ34はユーザ自身の端末装置12へのプッシュ通知である。ここで、メッセージ34は、ユーザ自身だけでなく、他のユーザ(例えば、同じグループのユーザまたはフレンドであってもよい)へのプッシュ通知であってもよい。このとき、情報処理装置は、お気に入りキャラクタが送信先のユーザが所有していないキャラクタである場合に、例えば送信先のユーザがお気に入りキャラクタの詳細情報を閲覧できるように、メッセージ34の内容を設定してもよい。また、情報処理装置は、お気に入りキャラクタが送信先のユーザが所有していないキャラクタである場合に、例えば送信先のユーザがお気に入りキャラクタを獲得可能なゲーム内の場所に移動できるように、メッセージ34の内容を設定してもよい。通常の伝達内容だけではなく、ユーザのお気に入りキャラクタについての情報を含むメッセージ34が他のユーザにも送信されることによって、ユーザ間の交流が一層活性化される。
【0103】
また、上記の実施形態において、メッセージ34のアイコン41(お気に入りキャラクタの表情)およびテキスト42は特性パラメータ(例えば親密度)に応じて変化する。ここで、アイコン41およびテキスト42の少なくとも一方は、お気に入りキャラクタと、ゲーム内で開催中または開催予定のイベントと、の関連性に応じて変化してもよい。このとき、お気に入りキャラクタとイベントとの関連性の高さを示す「関連度」といったパラメータが設定されてもよい。関連度は、例えば親密度と同様に、関連性が高いほど数値が高くなってもよい。そして、特性パラメータ(例えば親密度)に代えて、または特性パラメータと共に、関連度が、メッセージ34の内容を設定するのに用いられてもよい。このとき、メッセージ34を受信したユーザは、例えばお気に入りキャラクタの表情(アイコン41)から、イベントと自身のお気に入りキャラクタとの関連性を容易に把握できる。よって、このようなメッセージ34によって、ユーザがイベントに関心を持ちやすくなり、ゲーム内のイベントの活性化が期待できる。
【0104】
また、上記の実施形態において、ゲーム画面の一部をサーバ装置11が生成したデータに基づいて端末装置12の表示部19に表示させるウェブ表示とし、ゲーム画面の一部を、端末装置12にインストールされているネイティブアプリによって表示させるネイティブ表示としてもよい。このように、上述した実施形態におけるゲームは、端末装置12およびサーバ装置11のそれぞれが処理の一部を担うハイブリッドゲームとすることもできる。また、上記の制御方法(
図10参照)において端末装置12またはサーバ装置11が実行する一部の処理を、他方の装置が実行してもよい。例えば、サーバ装置11が実行するメッセージの送信時刻の演算(ステップS5)を、端末装置12が実行して、演算結果をサーバ装置11に送信してもよい。
【0105】
また、サーバ装置11および端末装置12は、ゲームに関する多様な処理を協働して実行してもよい。例えば、サーバ装置11および端末装置12が、一連の処理を分担して実行してもよい。また、例えば、サーバ装置11および端末装置12それぞれが同一の処理を実行してもよい。当該同一の処理について、サーバ装置11と端末装置12との間で処理結果が一致する場合、サーバ装置11および端末装置12は、当該処理を完了してもよい。サーバ装置11と端末装置12との間で処理結果が一致しない場合、サーバ装置11および端末装置12は、一方(例えばサーバ装置11)の処理結果が正しいとして当該処理を完了してもよい。また、別の例として、サーバ装置11と端末装置12との間で処理結果が一致しない場合、サーバ装置11および端末装置12は、当該同一の処理の実行前にプロセスを巻き戻してもよい。かかる構成によれば、例えばサーバ装置11および端末装置12の間の通信品質が一時的に低下した場合であっても、直ちに処理が中断される蓋然性が低下する。また、端末装置12において、例えば対戦パラメータの書き換え等の不正処理が行われた場合であっても、当該不正処理を排除できる蓋然性が向上する。
【0106】
また、端末装置12またはサーバ装置11として機能させるために、例えばコンピュータ、携帯電話等を好適に用いることができる。端末装置12またはサーバ装置11は上記の各機能を実現する処理内容を記述したプログラムを、アクセス可能な記憶部に格納し、CPUによって当該プログラムを読み出して実行させることによって実現可能である。
【解決手段】記憶部(端末記憶部18)と、通信部(端末通信部17)と、を備え、複数のゲーム媒体を有するゲームの処理を実行する情報処理装置(端末装置12)に、ゲーム内で、メッセージ設定情報として、複数のゲーム媒体の中の少なくとも1つおよびメッセージを受信したいタイミングを、ユーザに設定させるステップと、メッセージ設定情報を、記憶部に記憶させるステップと、記憶部に記憶されたメッセージ設定情報を、通信部を介して送信するステップと、メッセージを、通信部を介して受信するステップと、受信したメッセージをユーザに対して表示するステップと、を実行させて、メッセージを受信するタイミングおよびメッセージの内容の少なくとも一方は、メッセージ設定情報に応じて異なる。