(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-09-25
(45)【発行日】2024-10-03
(54)【発明の名称】情報処理装置、情報処理方法及びプログラム
(51)【国際特許分類】
A63F 13/5375 20140101AFI20240926BHJP
A63F 13/79 20140101ALI20240926BHJP
A63F 13/69 20140101ALI20240926BHJP
A63F 13/533 20140101ALI20240926BHJP
【FI】
A63F13/5375
A63F13/79
A63F13/69 510
A63F13/533
(21)【出願番号】P 2022160423
(22)【出願日】2022-10-04
(62)【分割の表示】P 2021057650の分割
【原出願日】2020-06-02
【審査請求日】2023-04-04
(73)【特許権者】
【識別番号】500033117
【氏名又は名称】株式会社MIXI
(72)【発明者】
【氏名】尾崎 悠
【審査官】宇佐田 健二
(56)【参考文献】
【文献】特開2017-124199(JP,A)
【文献】特開2020-074925(JP,A)
【文献】特開2015-150114(JP,A)
【文献】特許第6522215(JP,B1)
【文献】特開2017-006280(JP,A)
【文献】特開2020-009236(JP,A)
【文献】特開2020-057382(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
A63F 13/00-13/98,9/24
G06F 3/048-3/04895
(57)【特許請求の範囲】
【請求項1】
プロセッサを備え、前記プロセッサは、
プレイヤから所定の操作を受け付けた場合に表示される複数のキャラクタの中に、現在開催中又は今後開催される
抽選のイベントにより入手可能なキャラクタが
1体含まれている場合に
は第1画面を、複数体含まれている場合には第2画面を表示させ、
前記第1画面には、前記イベントにおける抽選要求を行うためのボタンを表示させ、
前記第2画面には、前記複数のキャラクタのうち、第1イベントで入手可能な第1キャラクタについて第1のアイコンを、第2イベントで入手可能な第2キャラクタについて第2のアイコンを表示させる、
情報処理装置。
【請求項2】
プロセッサが、プレイヤから所定の操作を受け付けた場合に表示される複数のキャラクタの中に、現在開催中又は今後開催される
抽選のイベントにより入手可能なキャラクタが
1体含まれている場合に
は第1画面を、複数体含まれている場合には第2画面を表示させ、
プロセッサが、
前記第1画面には、前記イベントにおける抽選要求を行うためのボタンを表示させ、
プロセッサが、前記第2画面には、前記複数のキャラクタのうち、第1イベントで入手可能な第1キャラクタについて第1のアイコンを、第2イベントで入手可能な第2キャラクタについて第2のアイコンを表示させる、
情報処理方法。
【請求項3】
プレイヤから所定の操作を受け付けた場合に表示される複数のキャラクタの中に、現在開催中又は今後開催される
抽選のイベントにより入手可能なキャラクタが
1体含まれている場合に
は第1画面を、複数体含まれている場合には第2画面を表示させ、
前記第1画面には、前記イベントにおける抽選要求を行うためのボタンを表示させ、
前記第2画面には、前記複数のキャラクタのうち、第1イベントで入手可能な第1キャラクタについて第1のアイコンを、第2イベントで入手可能な第2キャラクタについて第2のアイコンを表示させる、
処理をプロセッサに実行させるプログラム。
【請求項4】
サーバと端末とを備え、
前記サーバは、
プレイヤから所定の操作を受け付けた場合に表示される複数のキャラクタの中に、現在開催中又は今後開催される
抽選のイベントにより入手可能なキャラクタが
1体含まれている場合に
は第1画面を、複数体含まれている場合には第2画面を前記端末に表示させ、
前記第1画面には、前記イベントにおける抽選要求を行うためのボタンを表示させ、
前記第2画面には、前記複数のキャラクタのうち、第1イベントで入手可能な第1キャラクタについて第1のアイコンを、第2イベントで入手可能な第2キャラクタについて第2のアイコンを表示させる、
システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【0002】
デッキと呼ばれる、複数のキャラクタから構成されるチームを用いて、クエストと呼ばれるミッションをクリアしていくゲームが知られている。また、特許文献1には、現時点までにユーザが獲得したポイント、プレイ期限の終了までにポイント獲得条件の成立によって獲得可能なポイント、及び、各抽選ゲームの必要ポイントに基づいて、プレイ期限の終了までに到達可能な必要ポイントのうちの最大の必要ポイントが設定された種類の抽選ゲームを特定し、その特定された種類の抽選ゲームのプレイを勧める通知をユーザに対して行なう技術が開示されている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
デッキを構成するためには複数のキャラクタが必要になる。また、クエストを有利に進めるためには、プレイヤは、多様なキャラクタを所有し、クエストの特性に応じたデッキを編成してクエストをプレイすることが望ましい。
【0005】
そこで、本発明は、画面に表示されるキャラクタが、所定条件を満たすキャラクタなのか否かをプレイヤに容易に把握させることを目的とする。
【課題を解決するための手段】
【0006】
本発明の一態様に係る情報処理装置は、プレイヤが所有するキャラクタを記憶する記憶部と、前記プレイヤから所定のキャラクタの情報を表示させるための操作を受け付けた場合に、前記所定のキャラクタの中に所定条件を満たすキャラクタが含まれているときに、当該所定条件を満たすキャラクタを入手可能なイベントの情報を通知するための通知画面を表示させる表示制御部と、を備え、前記所定条件を満たすキャラクタは、前記イベントで入手可能なキャラクタであって、かつ、前記プレイヤが所有していないキャラクタである。
【発明の効果】
【0007】
本発明によれば、所有していないキャラクタを容易に入手できる方法をプレイヤに通知することができる。
【図面の簡単な説明】
【0008】
【
図1】本実施形態に係るゲームシステムのシステム構成の一例を示す図である。
【
図2】ゲームサーバ及び端末のハードウェア構成の一例を示す図である。
【
図3】ゲームサーバの機能ブロック構成例を示す図である。
【
図4】プレイヤ管理DB及び所有キャラクタ管理DBの一例を示す図である。
【
図5】デッキ管理DB、使用デッキ履歴DB、キャラクタ状況管理DB及びイベン ト設定DBの一例を示す図である。
【
図7】ゲームサーバが行う処理手順の一例を示すフローチャートである。
【発明を実施するための形態】
【0009】
添付図面を参照して、本発明の実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。
【0010】
<システム構成>
図1は、本実施形態に係るゲームシステム1のシステム構成の一例を示す図である。
図1に示すゲームシステム1は、ゲームサーバ10(ゲーム装置)と、複数の端末20とを備える。ゲームサーバ10及び端末20は、インターネット、イントラネット、無線LAN又は移動通信等の通信ネットワークNを介して互いに通信可能に接続されている。
【0011】
ゲームサーバ10は、例えば、プレイヤに関する各種情報を管理したり、ゲームの一部の処理を実行したりする等、端末20がゲームを提供する上でその一部の機能を担う装置である。ゲームサーバ10は、1又は複数の情報処理装置から構成されていてもよいし、仮想的なサーバ(クラウドサーバ等)を用いて構成されていてもよい。
【0012】
端末20は、ゲームをプレイヤに提供する情報処理装置であり、プレイヤは、端末20を操作することで本実施形態に係るゲームを実行することができる。端末20は、例えば、携帯電話(スマートフォンを含む)、タブレット、パーソナルコンピュータ、アーケードゲーム装置、又は、コンシューマゲーム装置等のコンピュータである。端末20は、GPS(Global Positioning System)等を用いて検出した自身の位置をゲームサーバ10に通知する。
【0013】
<ゲーム概要>
続いて、本実施形態に係るゲームシステム1が提供するゲームの概要を説明する。ゲームシステム1が提供するゲーム(以下、「本ゲーム」と言う。)では、プレイヤは、所有している複数のキャラクタの中から選択したキャラクタでデッキを編成し、編成したデッキを用いてクエストをクリアすることで、新たなキャラクタやアイテムを入手することができる。また、プレイヤは、入手した複数のキャラクタを合成することでより強いキャラクタに成長させたり、アイテムを用いてキャラクタの属性を強化したりすることで、より難易度の高いクエストに挑戦することができる。
【0014】
ここで、クエストとは、予め定められた一定の条件を満たすことがクリア条件であるミッションを意味する用語である。クエストは、探索や課題と呼ばれることもある。クエストに参加したプレイヤは、当該一定の条件を満たすことでクエストをクリアすることができ、クエストをクリアすると、プレイヤに報酬が与えられたり、本ゲームのストーリーが進行したりする。
【0015】
また、デッキとは、複数のキャラクタを組み合わせたグループを意味する用語である。プレイヤは、クエストを実行する際、当該クエストをクリアするために適した能力を持つキャラクタを選択してデッキを編成してクエストを実行する。ゲームサーバ10には、プレイヤが編成した複数のデッキを記憶しておくことができ、プレイヤは、クエスト実行時に、記憶された複数のデッキの中から一のデッキを選択してクエストを実行することも可能である。
【0016】
プレイヤがクエストを実行する際、「スタミナ」と呼ばれる、プレイヤが有する所定のパラメータが消費される。消費されるスタミナの量はクエストごとに異なる。また、スタミナの上限は、プレイヤのレベル及び経験値等に応じて上限値が定められている。クエストをプレイすることで消費されたスタミナは、時間の経過とともに自動的に回復する。
【0017】
プレイヤは、他のプレイヤと、所定の関係(以下、「フレンド関係」と言う。)を構築することができる。フレンド関係は、お互いのプレイヤが承認をすることで構築することができる。プレイヤのゲーム画面には、フレンド関係にある他のプレイヤ一覧が表示される。
【0018】
デッキは、プレイヤ自身が所有するキャラクタの中からプレイヤが選択したキャラクタと、他のプレイヤが所有するキャラクタとから編成される。各プレイヤは、他のプレイヤのデッキに編成可能なキャラクタ(以下、「フレンド使用キャラ」と言う。)を予め設定しておく。プレイヤがクエストを実行する際、プレイヤは、クエストに使用するデッキを編成するとともに、ゲーム画面に一覧表示される複数の他のプレイヤの中から、他のプレイヤを一人選択する。プレイヤが他のプレイヤを一人選択すると、選択された他のプレイヤのフレンド使用キャラがデッキに設定されてクエストが開始される。なお、ゲーム画面に一覧表示される複数の他のプレイヤは、フレンド関係にあるプレイヤ、又は、ゲームサーバ10が任意に選択した他のプレイヤである。
【0019】
また、プレイヤは、フレンド関係にあるプレイヤから、フレンド関係にあるプレイヤが所有するキャラクタをレンタルする(借りる)ことができる。キャラクタをレンタルしたプレイヤは、所定の期間の間、レンタルしたキャラクタをデッキに組み込んでクエストを実行することが可能である。
【0020】
プレイヤは、ゲーム中の様々な場面(例えばクエストをクリアした場合等)でキャラクタを入手することができる。また、プレイヤは、ゲーム内で開催されている、キャラクタが当たるイベント(例えばガチャ等であり、以下、「イベント」と呼ぶ)でキャラクタを入手することもできる。どのキャラクタが当たるのかはイベントごとに異なり、通常は、予めイベントに対応づけられた複数のキャラクタの中から1体のキャラクタが抽選によりランダムに選択される。なお、イベントによっては、複数のキャラクタのうち特定のキャラクタの抽選確率が高く設定されている(つまり、当たりやすいキャラクタが設定されている)。本ゲームでは、同時期に複数のイベントが行われることもある。
【0021】
本ゲームでは、ゲーム画面において、プレイヤから、所定のキャラクタの情報を画面に表示させるための操作を受け付けた場合、当該所定のキャラクタの中に、イベントで入手可能なキャラクタであってプレイヤが所有していないキャラクタ(以下、「所定条件を満たすキャラクタ」と言う。)が含まれているとき、当該所定条件を満たすキャラクタを入手可能な当該イベントの情報を通知するための画面(以下、「イベント通知画面」と言う。)を表示する。ここで、「所定のキャラクタ」とは、本ゲームに登場するキャラクタのうち、何らかの条件に該当する一部のキャラクタを意味する。例えば、所定のキャラクタとは、本ゲームに新たに追加されたキャラクタであってもよいし、ステータスが所定の値以上であるキャラクタであってもよいし、特定の属性を有するキャラクタであってもよい。また、後述する人気キャラクタ及び/又は人気急上昇中キャラクタであってもよい。これにより、プレイヤは、所有していないキャラクタを入手できるイベントが開催される(又は開催されている)ことを認識することができる。
【0022】
<ハードウェア構成>
図2は、ゲームサーバ10及び端末20のハードウェア構成の一例を示す図である。ゲームサーバ10及び端末20は、CPU(Central Processing Unit)11、メモリ、HDD(Hard Disk Drive)及び/又はSSD(Solid State Drive)等の記憶装置12、有線又は無線通信を行う通信IF(Interface)13、入力操作を受け付ける入力デバイス14、及び情報の出力を行う出力デバイス15を有する。入力デバイス14は、例えば、キーボード、タッチパネル、マウス及び/又はマイク等である。出力デバイス15は、例えば、ディスプレイ及び/又はスピーカ等である。
【0023】
<機能ブロック構成>
(ゲームサーバ)
図3は、ゲームサーバ10の機能ブロック構成例を示す図である。ゲームサーバ10は、記憶部100と、ゲーム制御部110とを含む。記憶部100は、ゲームサーバ10が備える記憶装置12を用いて実現することができる。また、ゲーム制御部110は、ゲームサーバ10のプロセッサ11が、記憶装置12に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体(Non-transitory computer readable medium)であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、USBメモリ又はCD-ROM等の記憶媒体であってもよい。
【0024】
記憶部100は、プレイヤ管理DB100a、所有キャラクタ管理DB100b、デッキ管理DB100c、使用デッキ履歴DB100d、キャラクタ状況管理DB100e及びイベント設定DB100fを記憶する。
【0025】
図4は、プレイヤ管理DB100a及び所有キャラクタ管理DB100bの一例を示す図である。プレイヤ管理DB100aは、プレイヤ毎に所有されるゲームデータを管理する。また、プレイヤ管理DB100aは、プレイヤが所有するキャラクタのうち、他のプレイヤのデッキに編成可能なフレンド使用キャラを記憶する。プレイヤ管理DB100aには、例えば、プレイヤを一意に識別するID(プレイヤID)、プレイヤの呼び名(ニックネーム)、フレンド関係にあるプレイヤとして登録されている他のプレイヤのプレイヤID、プレイヤが利用する端末20の現在位置、プレイヤの経験値、プレイヤのランク及びプレイヤのスタミナ、及び、イベントを実行する際に消費されるアイテム(イベント実行アイテム)の所有数が対応づけられて格納される。
【0026】
所有キャラクタ管理DB100bは、プレイヤが所有するキャラクタを管理する。所有キャラクタ管理DB100bには、プレイヤを一意に識別するID(プレイヤID)、キャラクタを一意に特定するID(キャラクタID)、入手容易なキャラクタなのか入手困難なキャラクタなのかをランク、キャラクタの強さを示す各種パラメータ(レベル、ラック(運)、HP(ヒットポイント)、攻撃力、スピード等)等が格納される。
【0027】
図5は、デッキ管理DB100c、使用デッキ履歴DB100d、キャラクタ状況管理DB100e及びイベント設定DB100fの一例を示す図である。
【0028】
デッキ管理DB100cは、各デッキを編成するキャラクタを管理する。デッキ管理DB100cには、例えば、プレイヤを一意に識別するID(プレイヤID)、各プレイヤのデッキを一意に識別するID(デッキID)、及び、各デッキを編成するキャラクタを一意に識別するID(キャラクタID)が対応づけられて格納される。
【0029】
使用デッキ履歴DB100dは、各プレイヤが、過去に各クエストを実行した際に、どのデッキでクエストを実行したのかを示す履歴(デッキの履歴)を記録する。使用デッキ履歴DB100dには、例えば、プレイヤを一意に識別するID(プレイヤID)、クエストを一意に識別するID(クエストID)、クエストを実行した際に使用された1以上のデッキを編成した複数のキャラクタ(キャラクタID)の履歴が対応づけられて格納される。使用デッキ(前回)には、前回クエストを実行した際に使用されたデッキのキャラクタが格納される。使用デッキ(前々回)には、2回前にクエストを実行した際に使用されたデッキのキャラクタが格納される。
【0030】
キャラクタ状況管理DB100eは、本ゲームに登場する各キャラクタに関する状況を示す情報を管理する。「人気キャラクタランキング」には、本ゲームにて人気のあるキャラクタのキャラクタIDが、人気順に所定数(例えば上位10体など)格納される。人気キャラクタとは、具体的には、所定期間に、各プレイヤがプレイするクエストで使用された回数の合計が多い順に、所定数のキャラクタであってもよい。また、「人気急上昇中キャラクタランキング」には、所定期間に人気ランキングが大きく上昇した順に所定数(例えば上位10体など)のキャラクタのキャラクタIDが格納される。
【0031】
イベント設定DB100fは、本ゲームで開催されるイベントに関する情報を管理する。イベント設定DB100fには、イベントを一意に識別するID(イベントID)、イベントの開催期間、イベントで入手可能なキャラクタ(抽選により当たる可能性があるキャラクタ)、入手可能なキャラクタの中で、所定のランク以上のキャラであり、かつ抽選確率が高く設定されているキャラクタ(以下、「ピックアップキャラクタ」と言う。)が設定される。
【0032】
図3に戻り説明を続ける。ゲーム制御部110は、本ゲームを実行するために必要な各種の機能を提供する。ゲーム制御部110は、受付部111と、実行部112と、表示制御部113とを含む。
【0033】
受付部111は、プレイヤから、実行するクエストの選択、クエストに使用するデッキの選択等を受け付ける。また、受付部111は、プレイヤから所定のキャラクタの情報を表示させるための画面の操作を受け付ける。所定のキャラクタの情報とは、本ゲームに登場するキャラクタのうち、何らかの条件に該当する一部のキャラクタの情報を意味する。例えば、所定のキャラクタの情報は、人気キャラクタのランキングを示す情報や、人気急上昇中のキャラクタのランキングを示す情報であってもよい。
【0034】
実行部112は、受付部111が受け付けたクエストを実行する。
【0035】
表示制御部113は、受付部111が、プレイヤから所定のキャラクタの情報を表示させるための操作を受け付けた場合に、所定のキャラクタの中に、所定条件を満たすキャラクタが含まれているときに、イベント通知画面(当該所定条件を満たすキャラクタを入手可能なイベントの情報を通知するための画面)を表示させる。
【0036】
(端末)
図6は、端末20の機能ブロック構成例を示す図である。端末20は、記憶部200と、通信部201と、UI(User Interface)部202と、ゲーム制御部203とを含む。記憶部200は、端末20が備える記憶装置12を用いて実現することができる。また、通信部201と、UI部202と、ゲーム制御部203とは、端末20のプロセッサ11が、記憶装置12に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、USBメモリ又はCD-ROM等の記憶媒体であってもよい。
【0037】
記憶部200は、ゲーム制御部203が本ゲームを実行するために必要なゲームデータを記憶する。ゲームデータには、キャラクタの画像データ、ゲームシナリオ等が格納される。
【0038】
通信部201は、通信IF13を用いてゲームサーバ10との間で各種の通信を行う機能を有する。
【0039】
UI部202は、プレイヤから各種の入力を受け付ける処理と、ディスプレイに各種のゲーム画面を表示させる機能とを有する。また、UI部202は、ゲームサーバ10の指示に従い、ゲーム画面を表示する。
【0040】
ゲーム制御部203は、ゲームサーバ10と連携することで、本ゲームを実行するために必要な各種の機能を提供する。例えば、ゲーム制御部203は、ゲーム画面に描画するための各種の情報(アイコン画像データ、テキストデータ等)をゲームサーバ10から取得する機能等を提供する。
【0041】
以上説明した機能ブロック構成について、ゲームサーバ10に含まれる受付部111と、実行部112と、表示制御部113とのうち全部又は一部を、端末20のゲーム制御部203に備える構成とするようにしてもよい。
【0042】
<処理手順>
図7は、ゲームサーバ10が行う処理手順の一例を示すフローチャートである。受付部111が、プレイヤから所定のキャラクタの情報を表示させるための画面の操作を受け付けると、
図7に示す処理手順が開始される。
【0043】
まず、表示制御部113は、本ゲームに登場するキャラクタのうち、所定のキャラクタに該当するキャラクタに関する情報を取得する(S10)。例えば、所定のキャラクタが、人気キャラクタや人気急上昇中キャラクタである場合、表示制御部113は、キャラクタ状況管理DBを参照することで、人気キャラクタや人気急上昇中キャラクタに関する情報を取得する。
【0044】
続いて、表示制御部113は、イベント設定DBを参照することで、現在開催中又は今後開催されるイベントで入手可能なキャラクタを取得する(S11)。続いて、表示制御部113は、所定のキャラクタの中に、所定条件を満たすキャラクタが含まれているか否かを判定する(S12)。所定条件を満たすキャラクタが含まれている場合(S12-YES)、表示制御部113は、イベント通知画面を、端末20のディスプレイに表示させる(S13)。所定条件を満たすキャラクタが含まれていない場合(S12-NO)、表示制御部113は、イベント通知画面を表示せずに、処理を終了する。
【0045】
図8は、ゲーム画面の一例を示す図である。
図8(a)に示す画面のボタンB10が押下されると、
図8(b)に示す画面に遷移する。
図8(b)の画面でボタンB20が押下されると、表示領域B21に人気キャラクタの上位10体が表示され、表示領域B22に人気急上昇中キャラクタの上位10体が表示される。
図8(a)に示す画面のボタンB10が押下されることは、プレイヤから所定のキャラクタの情報を表示させるための画面の操作を受け付けることに対応する。
【0046】
図8(b)の画面には、キャラクタアイコンC1が表示されている。キャラクタアイコンC1は、人気キャラクタの上位10体の中に、所定条件を満たすキャラクタが存在することを示している。キャラクタアイコンC1が押下されると、
図8(c)に示す画面に遷移する。
図8(c)に示す画面には、所定条件を満たすキャラクタを入手可能なイベントの実行をプレイヤに勧めるメッセージが表示されており、ボタンB30が押下されると、当該イベントを実行する画面(例えばガチャを引く画面)である
図8(d)に遷移する。
図8(d)では、表示領域B40に、イベントで入手可能なキャラクタのアイコンが表示
される。
【0047】
イベント通知画面は、
図8(c)に示す画面に対応することとしてもよい。若しくは、イベント通知画面は、所定条件を満たすキャラクタが存在することを示すアイコンC1が表示された
図8(b)に示す画面に対応することとしてもよい。
【0048】
図8の例において、画面遷移は上述の説明に限定されない。例えば、
図8(a)に示す画面のボタンB10が押下されると、
図8(b)を省略して
図8(c)に示す画面に遷移するようにしてもよい。また、
図8(b)の画面は、人気キャラクタ及び人気急上昇中キャラクタを表示することに限定されない。所定のキャラクタを並べて複数表示できる画面であればどのような画面であってもよい。
【0049】
<処理手順の変形例>
[変形例(その1)]
所定条件を満たすキャラクタは、更に、ピックアップキャラクタ(イベントで入手可能な所定のランク以上のキャラクタであり、かつ、該所定のランク以上のキャラクタの中で更に抽選確率が高く設定されているキャラクタ)であってもよい。ピックアップキャラクタは、クエストを有利に進めることが可能な強力なキャラクタに該当することが多い(ただし本実施形態がこれに限定されるものではない)。これにより、プレイヤは、所有していないキャラクタのうち、ピックアップキャラクタを容易に入手することが可能になる。
【0050】
また、所定条件を満たすキャラクタは、更に、ピックアップキャラクタのうち、プレイヤがプレイしたことがない所定数のクエストと所定の関係性を有するキャラクタであってもよい。所定の関係性とは、キャラクタのステータスやキャラクタそのものの属性等に基づき、クエストを有利に進めることが可能なキャラクタであるとして予め定義されたキャラクタであってもよい。例えば、木の属性を有するモンスターが多く出現するクエストをプレイしする場合、炎の属性を有するキャラクタをデッキに組み込むと、当該クエストを有利に進めることができると仮定する。この場合、表示制御部113は、プレイヤがプレイしたことがないクエストが木の属性を有するモンスターが多く出現するクエストである場合で、かつ、炎の属性を有するキャラクタがピックアップキャラクタに存在する場合に、当該キャラクタを入手可能なイベントの情報を端末20に通知するようにしてもよい。
【0051】
また、所定の関係性とは、プレイヤがクリアしたことがないクエストについて、他のプレイヤが当該クエストをクリアした際に使用したキャラクタを、キャラクタごとに使用回数を集計したデータのうち、上位所定数(例えば上位1~3位など)に含まれるキャラクタであってもよい。例えば、プレイヤがクリアしたことがないクエストAについて、他のキャラクタC1がクエストAをクリアした際にデッキに含まれていたキャラクタがキャラクタU1~U4であり、他のキャラクタC2がクエストAをクリアした際にデッキに含まれていたキャラクタがキャラクタU4~U7であったとする。この場合、キャラクタU1~U3の使用回数は1回であり、キャラクタU4の使用回数は2回であり、キャラクタU5~U7の使用回数は1回であると集計される。
【0052】
これにより、プレイヤは、所有していないキャラクタのうち、今後プレイするクエストと関連のあるピックアップキャラクタを容易に入手することが可能になる。
【0053】
[変形例(その2)]
所定条件を満たすキャラクタは、人気キャラクタ(所定期間にクエストで使用された回数の合計数が多い順に所定数のキャラクタ)であってもよい。これにより、プレイヤは、所有していないキャラクタのうち、クエストで多く使用されているキャラクタを容易に入手ことが可能になる。
【0054】
[変形例(その3)]
所定条件を満たすキャラクタは、プレイヤが過去にクエストで使用したデッキに組み込まれていた、他のプレイヤが所有しているキャラクタ(例えばフレンド使用キャラ)又は他のプレイヤからレンタルしたキャラクタであってもよい。これにより、プレイヤは、過去にクエストで使用したデッキに組み込まれていたキャラクタであって、他のプレイヤが所有するキャラクタ又はレンタルしたキャラクタと同一のキャラクタを、容易に入手することが可能になる。
【0055】
[変形例(その4)]
所定条件を満たすキャラクタは、プレイヤがクリアできなかったクエストをクリアした他のプレイヤが、該クエストで使用したキャラクタであってもよい。他のプレイヤが、該クエストをクリアした際に使用したキャラクタは、当該クエストをクリアする際に有利な効果を発揮するキャラクタであると想定される。これにより、プレイヤは、クリアすることができなかったクエストを、容易にクリアすることが可能になる。
【0056】
[変形例(その1~その4)の補足事項]
本実施形態において、キャラクタは、クエストで使用されることで経験値を積むことや、他のキャラクタと合成される等により、より強力な他のキャラクタに変身(以下、「進化」と言う。)可能であってもよい。
【0057】
この場合、変形例(その1~その4)における「所定条件を満たすキャラクタ」には、イベントで入手可能であり、かつプレイヤが所持していないキャラクタであって、かつ、進化することで変形例(その1~その4)に示す条件(つまり、イベントで入手可能であり、かつプレイヤが所持していないキャラクタであること以外の条件)を満たすキャラクタが含まれることとしてもよい。例えば、進化することでキャラクタMになるキャラクタmが存在するとする。また、キャラクタmは、イベントで入手可能でありかつプレイヤが所持していないキャラクタであるとする。この場合において、キャラクタMがフレンド使用キャラである場合、表示制御部113は、キャラクタmは変形例(その3)に該当するものとして、イベント通知画面を、端末20のディスプレイに表示させるようにしてもよい。
【0058】
[変形例(その5)]
ピックアップキャラクタは、イベントにおいて周期的に繰り返し現れるように設定されていてもよい。また、表示制御部113は、通知画面を表示させた後でプレイヤがイベントを実行した場合、ピックアップキャラクタ(抽選確率が高く設定されているキャラクタ)が、再度ピックアップキャラクタに設定されたタイミング(再度抽選確率が高く設定されたタイミング)で、イベント通知画面を再度表示させるようにしてもよい。また、表示制御部113は、イベント通知画面を表示させた後でプレイヤがイベントを実行していない場合、ピックアップキャラクタが再度ピックアップキャラクタに設定されたタイミングであっても、イベント通知画面を表示させないようにしてもよい。
【0059】
例えば、キャラクタA、B、Cが入手可能に設定されているイベントにおいて、第1週目、第4週目、第7週目はキャラクタAがピックアップキャラクタに設定され、第2週目、第5週目、第8週目はキャラクタBがピックアップキャラクタに設定され、第3週目、第6週目、第9週目はキャラクタCがピックアップキャラクタに設定されるというように、同一のピックアップキャラクタが周期的に繰り返し現れるように設定されるイベントを仮定する。
【0060】
また、プレイヤはキャラクタAを所有しておらず、表示制御部113は、キャラクタAがピックアップキャラクタに設定された第1週目に、キャラクタAをイベントで入手可能なことを示すイベント通知画面(例えば
図8(c)の画面)を表示させたとする。この場合において、プレイヤがイベントを実行した場合(つまり、イベント通知画面を見て、キャラクタAを入手したいと思い、ガチャを実行した場合)、第4週目及び第7週目についても、キャラクタAをイベントで入手可能なことを示すイベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示するようにしてもよい。
【0061】
一方、プレイヤがイベントを実行しなかった場合(つまり、イベント通知画面を見ても、キャラクタAを入手したいと思わず、ガチャを実行しなかった場合)、第4週目及び第7週目については、キャラクタAをイベントで入手可能なことを示すイベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示しないようにしてもよい。これにより、ピックアップキャラクタが周期的に高確率で入手できるイベントにおいて、プレイヤがイベントを実行したか否かに応じて、当該イベントを再度プレイヤに通知するか否かを切り替えることが可能になる。
【0062】
以上説明した変形例(その5)において、表示制御部113は、プレイヤの端末20にイベント通知画面を表示させた後、プレイヤが当該イベントを実行した回数、プレイヤが所持しているキャラクタの数、そのキャラクタのパラメータ、及び/又は、クエストでの使用状況に応じて、イベント通知画面を再度表示させるか否かを切り替えるようにしてもよい。例えば、プレイヤはキャラクタAを所有しておらず、表示制御部113は、キャラクタAがピックアップキャラクタに設定された第1週目に、キャラクタAをイベントで入手可能なことを示すイベント通知画面(例えば
図8(c)の画面)を表示させたとする。
【0063】
この場合において、プレイヤがイベントを所定回数(1回、2回、3回等)以上実行したとする。この場合、第4週目及び第7週目についても、キャラクタAをイベントで入手可能なことを示すイベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示するようにしてもよい。
【0064】
また、この場合において、プレイヤがイベントを所定回数以上実行し、かつ、キャラクタAを所定数(1体、2体、3体等)以上手に入れたとする。この場合、第4週目及び第7週目についても、当該イベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示するようにしてもよい。
【0065】
また、この場合において、プレイヤがイベントを所定回数以上実行し、キャラクタAを所定数以上手に入れており、かつ、キャラクタAのうち少なくとも1体のパラメータが所定以上であるとする(つまり、プレイヤは入手したキャラクタAを何らかの方法で強化している)。この場合、第4週目及び第7週目についても、当該イベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示するようにしてもよい。
【0066】
また、この場合において、プレイヤがイベントを所定回数以上実行し、キャラクタAを所定数以上手に入れており、かつ、キャラクタAをクエストで所定回数以上使用しているとする(つまり、プレイヤは入手したキャラクタAをクエストで使用している)。この場合、第4週目及び第7週目についても、当該イベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示するようにしてもよい。
【0067】
また、この場合において、プレイヤがイベントを所定回数以上実行し、キャラクタAを所定数以上手に入れており、キャラクタAのうち少なくとも1体のパラメータが所定以上であり、かつ、キャラクタAをクエストで所定回数以上使用しているとする。この場合、第4週目及び第7週目についても、当該イベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示するようにしてもよい。
【0068】
また、この場合において、プレイヤがイベントを所定回数以上実行してなかった場合、表示制御部113は、第4週目及び第7週目については、当該イベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示しないようにしてもよい。
【0069】
また、この場合において、プレイヤが、キャラクタAを所定数以上入手したものの、その後売却した等の理由で保有していない場合、表示制御部113は、第4週目及び第7週目については、当該イベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示しないようにしてもよい。
【0070】
また、この場合において、プレイヤが、キャラクタAを所定数以上入手したものの、いずれのキャラクタAのパラメータも変更されていない場合(つまりキャラクタAを強化していない)、表示制御部113は、第4週目及び第7週目については、当該イベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示しないようにしてもよい。
【0071】
また、この場合において、プレイヤが、キャラクタAを所定数以上入手したものの、いずれのキャラクタAもクエストで使用していない場合(つまりキャラクタAを強化していない)、表示制御部113は、第4週目及び第7週目については、当該イベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示しないようにしてもよい。
【0072】
一方、プレイヤがイベントを実行したものの、キャラクタAを手に入れることができなかったとする。この場合、第4週目及び第7週目については、キャラクタAをイベントで入手可能なことを示すイベント通知画面(例えば
図8(c)の画面)をプレイヤの端末20に表示しないようにしてもよい。
【0073】
[変形例(その6)]
表示制御部113は、所定条件を満たすキャラクタが複数である場合と、所定条件を満たすキャラクタが1体である場合とで、イベント通知画面の態様を変更するようにしてもよい。
【0074】
例えば、
図7のステップS12において、表示制御部113は、所定のキャラクタの中に、所定条件を満たすキャラクタが複数存在する場合、
図8(b)に示すように複数のキャラクタを表示可能な画面を、イベント通知画面として表示するようにしてもよい。また、当該イベント通知画面において、所定条件を満たすキャラクタを示すアイコン(例えばキャラクタアイコンC1の形状のアイコン)を複数表示するようにしてもよい。また、アイコンが押下されると、そのアイコンが示すキャラクタを入手可能なイベントに対応するイベント通知画面(
図8(c)に示す画面)が表示されるようにしてもよい。また、このとき、所定条件を満たすキャラクタが複数存在する場合、アイコンC1の形状を、所定条件を満たすキャラクタが複数存在することを示す形状(例えば、2体の場合は「!!」等)にするようにしてもよい。なお、
図8(b)の画面においてアイコンC1は1つのキャラクタに1つ付与されることから、「!!」が表示される場合には、
図8(b)の画面にて2か所に「!!」のアイコンが表示されることになる。同様に、「!!!」が表示される場合には、
図8(b)の画面にて3か所に「!!!」のアイコンが表示されることにな
る。アイコンをより目立たせることができる。
【0075】
また、表示制御部113は、所定のキャラクタの中に、所定条件を満たすキャラクタが複数存在する場合において、各々が異なるイベントで入手できるキャラクタである場合、イベント通知画面を、入手できるイベントが識別できる態様で表示するようにしてもよい。例えば、
図8(b)の画面において、イベントAで入手できるキャラクタについては、「A」のアイコンを表示し、イベントBで入手できるキャラクタについては、「B」のアイコンを表示するようにしてもよい。
【0076】
一方、表示制御部113は、所定のキャラクタの中に、所定条件を満たすキャラクタが1体である場合、
図8(c)に示すように、単にイベントの実行をプレイヤに勧めるメッセージ(ガチャを勧めるメッセージ)を表示する画面を、イベント通知画面として表示するようにしてもよい。若しくは、表示制御部113は、
図8(d)に示すように、イベントを実行する画面(ガチャを引く画面)を、イベント通知画面として表示するようにしてもよい。
【0077】
これにより、プレイヤは、所有していないキャラクタのうち入手可能なキャラクタが複数であるのか否かを容易に把握することが可能になる。
【0078】
[変形例(その7)]
表示制御部113は、プレイヤから所定のキャラクタの情報を表示させるための画面の操作を受け付けた場合(例えば
図8(a)のボタンB10が押下された場合)、所定のキャラクタの情報を表示させるキャラクタ一覧画面(例えば
図8(b)の画面)を表示させ、キャラクタ一覧画面にて所定操作が行われた場合(例えば
図8(b)の画面でキャラクタアイコンC1が押下された場合)に、イベント通知画面(
図8(c)の画面)を表示させるようにしてもよい。
【0079】
また、表示制御部113は、キャラクタ一覧画面にて、所定条件を満たすキャラクタが選択される操作が1回目に行われた場合にはイベント通知画面を表示させ、キャラクタ一覧画面にて当該選択される操作が2回目以降に行われた場合は同一のイベント通知画面を表示させないようにしてもよい。
【0080】
例えば、
図8(a)の画面でボタンB10が押下され、
図8(b)の画面が表示されたとする。また、
図8(b)の画面でキャラクタアイコンC1が押下されたことにより、
図8(c)の画面が表示されるとする。また、
図8(c)の画面でボタンB30が押下されたことにより、
図8(d)の画面が表示されたとする。この場合において、何らかの画面操作が行われ、再度
図8(b)の画面が表示されたとする。この場合、
図8(b)の画面でキャラクタアイコンC1が押下されると、
図8(c)の画面を表示せずに、
図8(d)の画面が表示されることとしてもよい。これにより、同一内容のイベント通知画面を何度も表示させないようにすることが可能になる。また、プレイヤに対して、同一内容のイベント通知画面が何度も表示されることで、プレイヤが鬱陶しく感じてしまうことを抑制することが可能になる。
【0081】
[変形例(その8)]
表示制御部113は、変形例(その7)で説明したキャラクタ一覧画面において、所定のキャラクタを、少なくとも、所定条件を満たさないキャラクタ、及び、所定条件を満たすキャラクタに分けて表示するようにしてもよい。
【0082】
また、表示制御部113は、キャラクタ一覧画面において、所定条件を満たさないキャラクタが選択された場合には、所定条件を満たさないキャラクタに関する情報を端末20に表示させ、所定条件を満たすキャラクタが選択された場合には、イベント通知画面を端末20に表示させるようにしてもよい。所定条件を満たさないキャラクタに関する情報は、当該キャラクタのステータス詳細(スペック詳細)を表示する画面であってもよい。
【0083】
例えば、キャラクタ一覧画面は
図8(b)に示す態様であり、表示領域B21に人気キャラクタの上位10体が表示され、表示領域B22に人気急上昇中キャラクタの上位10体が表示されるとする。表示制御部113は、
図8(b)に表示される各キャラクタを、所定条件を満たすキャラクタと、所定条件を満たさないキャラクタとを識別可能な態様で表示するようにしてもよい。
【0084】
また、表示制御部113は、変形例(その7)で説明したキャラクタ一覧画面において、所定のキャラクタを、以下の3パターンに区別して表示するようにしてもよい。
【0085】
パターン1:「イベントで入手可能なキャラクタであり、プレイヤが所持しておらず、かつ、当該イベントでピックアップキャラクタとして設定されているキャラクタ」
パターン2:「イベントで入手可能なキャラクタであり、プレイヤが所持しておらず、かつ、当該イベントでピックアップキャラクタとして設定されていないキャラクタ」、及び、「イベントで入手できないキャラクタであり、かつ、プレイヤが所持していないキャラクタ」
パターン3:「プレイヤが所持しているキャラクタ」
これにより、プレイヤは、キャラクタ一覧画面に表示される各キャラクタが、所定条件を満たすキャラクタなのか否か等を容易に把握することが可能になる。
【0086】
[変形例(その9)]
イベントには、複数のイベントが含まれており、表示制御部113は、プレイヤがイベントを実行するために必要なアイテムの所有数に応じて、複数のイベントのうちプレイヤが実行可能な1以上のイベントであって、かつ、所定条件を満たすキャラクタを入手可能な1以上のイベントを抽出し、抽出した1以上のイベントの情報を通知する画面を表示させるようにしてもよい。
【0087】
例えば、イベントAを実行するためにはアイテムを5個消費し、イベントBを実行するためにはアイテムを10個消費すると仮定する。また、プレイヤはアイテムを8個保有していると仮定する。また、所定条件を満たすキャラクタとしてキャラクタA及びキャラクタBが存在し、キャラクタAはイベントAで入手可能であり、キャラクタBはイベントBで入手可能であるとする。この場合、プレイヤは、アイテムを8個しか保持していないため、イベントAを実行することは可能であるが、イベントBを実行することはできない。そこで、表示制御部113は、プレイヤが実行可能なイベントAを通知するイベント通知画面を端末20に表示させるようにしてもよい。また、変形例(その7)で説明したキャラクタ一覧画面を表示する場合、表示制御部113は、キャラクタ一覧画面において、キャラクタAを所定条件を満たすキャラクタとして表示し、キャラクタBは所定条件を満たさないキャラクタとして表示するようにしてもよい。
【0088】
また、例えば、イベントA及びイベントBを実行するためにはアイテムを5個消費すると仮定する。また、所定条件を満たすキャラクタとしてキャラクタX、キャラクタY及びキャラクタZが存在し、キャラクタX及びYはイベントAで入手可能であり、キャラクタZはイベントBで入手可能であるとする。もし、プレイヤが、アイテムを10個以上保持している場合、表示制御部113は、プレイヤが実行可能なイベントA及びイベントBの両方を通知するイベント通知画面を端末20に表示させるようにしてもよい。
【0089】
一方、プレイヤが、アイテムを5~9個保持している場合、表示制御部113は、プレイヤが実行可能なイベントとして、イベントA及びイベントBのうちいずれか一方を通知するイベント通知画面を端末20に表示させるようにしてもよい。通知するイベントは、ランダムに決定されるようにしてもよいし、所定の優先度に基づいて決定されるようにしてもよい。所定の優先度は、例えば、所定条件を満たすキャラクタのうち入手可能なキャラクタが多いイベント順であってもよい。ここでは、イベントAは、キャラクタX及びYの2体を入手可能であり、イベントBは、キャラクタZの1体のみを入手可能である。従って、表示制御部113は、所定条件を満たすキャラクタのうち入手可能なキャラクタが多いイベントAを通知するイベント通知画面を端末20に表示させるようにしてもよい。
【0090】
これにより、イベントを実行するために必要なアイテムの所有数に応じて、プレイヤが実行可能なイベントの情報を通知することが可能になる。
【0091】
[変形例(その10)]
イベント通知画面で通知されるイベントは、抽選によってキャラクタを入手可能なイベントのうち、所定条件を満たすキャラクタが最も多いイベントであってもよい。これにより、プレイヤは、所定条件を満たすキャラクタが最も多いイベントを容易に把握することが可能になる。
【0092】
<まとめ>
以上説明した実施形態によれば、所有していないキャラクタを容易に入手できる方法をプレイヤに通知することが可能になる。
【0093】
以上説明した実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。実施形態で説明したフローチャート、シーケンス、実施形態が備える各要素並びにその配置、材料、条件、形状及びサイズ等は、例示したものに限定されるわけではなく適宜変更することができる。また、異なる実施形態で示した構成同士を部分的に置換し又は組み合わせることが可能である。
【0094】
<付記>
<付記1>
プレイヤが所有するキャラクタを記憶する記憶部と、
前記プレイヤから所定のキャラクタの情報を表示させるための操作を受け付けた場合に、前記所定のキャラクタの中に所定条件を満たすキャラクタが含まれているときに、当該所定条件を満たすキャラクタを入手可能なイベントの情報を通知するための通知画面を表示させる表示制御部と、を備え、
前記所定条件を満たすキャラクタは、前記イベントで入手可能なキャラクタであって、かつ、前記プレイヤが所有していないキャラクタである、
情報処理装置。
【0095】
付記1によれば、所有していないキャラクタを容易に入手できる方法をプレイヤに通知することが可能になる。
【0096】
<付記2>
前記所定条件を満たすキャラクタは、更に、所定のランク以上のキャラクタであり、かつ、該所定のランク以上のキャラクタの中で更に抽選確率が高く設定されているキャラクタである、
付記1に記載の情報処理装置。
【0097】
付記2によれば、プレイヤは、所有していないキャラクタのうち、所定のランク以上のキャラクタを容易に入手することが可能になる。
【0098】
<付記3>
前記所定条件を満たすキャラクタは、更に、前記抽選確率が高く設定されているキャラクタのうち、前記プレイヤがプレイしたことがないクエストと所定の関係性を有するキャラクタである、
付記2に記載の情報処理装置。
【0099】
付記3によれば、プレイヤは、所有していないキャラクタのうち、所定のランク以上のキャラクタであって、今後プレイするクエストと関連のあるキャラクタを容易に入手することが可能になる。
【0100】
<付記4>
前記抽選確率が高く設定されているキャラクタは、前記イベントにおいて周期的に繰り返し現れるように設定されており、
前記表示制御部は、
前記通知画面を表示させた後、前記プレイヤが前記イベントを実行した場合、前記通知画面を、前記抽選確率が高く設定されているキャラクタが、再度、前記抽選確率が高く設定されたタイミングで表示させ、
前記通知画面を表示させた後、前記プレイヤが前記イベントを実行していない場合、前記通知画面を表示させない、
付記2又は3に記載の情報処理装置。
【0101】
付記4によれば、所定のランク以上のキャラクタが周期的に高確率で入手できるイベントにおいて、プレイヤがイベントを実行したか否かに応じて、当該イベントを再度プレイヤに通知するか否かを切り替えることが可能になる。
【0102】
<付記5>
前記所定条件を満たすキャラクタは、更に、所定期間にクエストで使用された回数の合計数が多い順に所定数のキャラクタである、
付記1~4のいずれか一項に記載の情報処理装置。
【0103】
付記5によれば、プレイヤは、所有していないキャラクタのうち、クエストで多く使用されているキャラクタを容易に入手ことが可能になる。
【0104】
<付記6>
前記所定条件を満たすキャラクタは、更に、前記プレイヤが過去にクエストで使用したデッキに組み込まれていた他のプレイヤが所有又は他のプレイヤからレンタルしたキャラクタである、
付記1~5のいずれか一項に記載の情報処理装置。
【0105】
付記6によれば、プレイヤは、過去にクエストで使用したデッキに組み込まれていたキャラクタであって、他のプレイヤが所有するキャラクタ又はレンタルしたキャラクタを容易に入手することが可能になる。
【0106】
<付記7>
前記所定条件を満たすキャラクタは、更に、前記プレイヤがクリアできなかったクエストをクリアした他のプレイヤが、該クエストで使用したキャラクタである、
付記1~6のいずれか一項に記載の情報処理装置。
【0107】
付記7によれば、プレイヤは、クリアできなかったクエストをクリア可能にするキャラクタを、容易に入手することが可能になる。
【0108】
<付記8>
前記表示制御部は、前記所定条件を満たすキャラクタが複数である場合と、前記所定条件を満たすキャラクタが1体である場合とで、前記通知画面の態様を変更する、
付記1~7のいずれか一項に記載の情報処理装置。
【0109】
付記8によれば、プレイヤは、所有していないキャラクタのうち入手可能なキャラクタが複数であるのか否かを容易に把握することが可能になる。
【0110】
<付記9>
前記表示制御部は、
前記操作を受け付けた場合、所定のキャラクタの情報を表示させるキャラクタ一覧画面を表示させ、
前記キャラクタ一覧画面にて、前記所定条件を満たすキャラクタが選択される操作が1回目に行われた場合に、前記通知画面を表示させ、前記キャラクタ一覧画面にて前記選択される操作が2回目以降に行われた場合は前記通知画面を表示させない、
付記1~8のいずれか一項に記載の情報処理装置。
【0111】
付記9によれば、同一内容の通知画面を何度も表示させないようにすることが可能になる。
【0112】
<付記10>
前記表示制御部は、
前記キャラクタ一覧画面において、前記所定のキャラクタを、少なくとも、前記所定条件を満たさないキャラクタ、及び、前記所定条件を満たすキャラクタに分けて表示し、
前記所定条件を満たさないキャラクタが選択された場合には、前記所定条件を満たさないキャラクタに関する情報を表示し、前記所定条件を満たすキャラクタが選択された場合には、前記通知画面を表示させる、
付記1~9のいずれか一項に記載の情報処理装置。
【0113】
付記10によれば、プレイヤは、所定条件を満たすキャラクタなのか否かに応じて、異なる情報を把握することが可能になる。
【0114】
<付記11>
前記イベントには、複数のイベントが含まれており、
前記表示制御部は、前記プレイヤがイベントを実行するために必要なアイテムの所有数に応じて、前記複数のイベントのうち前記プレイヤが実行可能な1以上のイベントであって、かつ、前記所定条件を満たすキャラクタを入手可能な1以上のイベントを抽出し、抽出した前記1以上のイベントの情報を通知する画面を表示させる、
付記1~10のいずれか一項に記載の情報処理装置。
【0115】
付記11によれば、イベントを実行するために必要なアイテムの所有数に応じて、プレイヤが実行可能なイベントの情報を通知することが可能になる。
【0116】
<付記12>
情報処理装置が行う情報処理方法であって、
プレイヤが所有するキャラクタを記憶部に記憶するステップと、
前記プレイヤから所定のキャラクタの情報を表示させるための操作を受け付けた場合に、前記所定のキャラクタの中に所定条件を満たすキャラクタが含まれているときに、当該所定条件を満たすキャラクタを入手可能なイベントの情報を通知するための通知画面を表示させるステップと、を有し、
前記所定条件を満たすキャラクタは、前記イベントで入手可能なキャラクタであって、かつ、前記プレイヤが所有していないキャラクタである、
情報処理方法。
【0117】
付記12によれば、所有していないキャラクタを容易に入手できる方法をプレイヤに通知することが可能になる。
【0118】
<付記13>
コンピュータに、
プレイヤが所有するキャラクタを記憶部に記憶するステップと、
前記プレイヤから所定のキャラクタの情報を表示させるための操作を受け付けた場合に、前記所定のキャラクタの中に所定条件を満たすキャラクタが含まれているときに、当該所定条件を満たすキャラクタを入手可能なイベントの情報を通知するための通知画面を表示させるステップと、を実行させ、
前記所定条件を満たすキャラクタは、前記イベントで入手可能なキャラクタであって、かつ、前記プレイヤが所有していないキャラクタである、
プログラム。
【0119】
付記13によれば、所有していないキャラクタを容易に入手できる方法をプレイヤに通知することが可能になる。
【符号の説明】
【0120】
1…ゲームシステム、10…ゲームサーバ、11…プロセッサ、12…記憶装置、13…通信IF、14…入力デバイス、15…出力デバイス、20…端末、100…記憶部、100a…プレイヤ管理DB、100b…所有キャラクタ管理DB、100c…デッキ管理DB、100d…使用デッキ履歴DB、100e…キャラクタ状況管理DB、100f…イベント設定DB、110…ゲーム制御部、111…受付部、112…実行部、113…表示制御部、200…記憶部、201…通信部、202…UI部、203…ゲーム制御部