(58)【調査した分野】(Int.Cl.,DB名)
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第1出力制御を行う出力手段と、
前記出力手段により第1出力制御が行われたことに応じて、前記ユーザの指示に基づいて、前記複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける受付手段と、を備え、
前記出力手段は、複数の入手経路の中で、前記受付手段により受け付けられた指示により指定されたオブジェクトである指定オブジェクトを入手可能な入手経路に前記ユーザを誘導するための操作対象を操作可能に表示させるための第2出力制御を行う、
情報処理装置。
前記出力手段は、前記受付手段により受け付けられた指示により指定されたオブジェクトである指定オブジェクトの入手経路に関する情報を表示させるための第3出力制御を行う、
請求項1に記載された情報処理装置。
前記第1出力制御は、表示対象となる前記複数のオブジェクトのうち前記ユーザが所持しているオブジェクトと前記ユーザが所持していないオブジェクトとを、前記ユーザに識別可能な表示形式で表示させる、
請求項1〜5のいずれか1項に記載された情報処理装置。
ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと、を含む情報処理システムであって、請求項1〜6のいずれか1項に記載された情報処理装置の各手段を、前記ユーザ端末又は前記サーバのいずれか一方が備えた、情報処理システム。
【発明を実施するための形態】
【0016】
(1)第1の実施形態
(1−1)ゲームシステムの構成
以下、情報処理システムの一実施形態として、ゲームシステム1について説明する。
【0017】
図1は、実施形態のゲームシステム1のシステム構成例を示している。
図1に示すように、このゲームシステム1は、ユーザ端末10a,10b,10c,…、および、ゲームサーバ20を含む。各ユーザ端末10a,10b,10cからゲームサーバ20に対しては、例えばインターネットなどの通信網NWを通してアクセス可能である。ゲームサーバ20は、情報処理装置の一例である。
各ユーザ端末10a,10b,10c,…はそれぞれ、個々のユーザによって操作される端末であり、例えば、フィーチャーフォン、スマートフォン、タブレット端末、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機(いわゆる多機能型のスマートテレビも含む。)、通信機能付き携帯ゲーム機などの通信端末である。以下の説明において、各ユーザ端末10a,10b,10c,…に共通して言及するときには、ユーザ端末10と表記する。
【0018】
ゲームサーバ20は、ゲームを実行するサーバである。ゲームサーバ20には、ウェブブラウザによって解釈可能な画像データ(例えばHTML、XMLなどの形式で記述された画像データのことである。本発明の実施形態では、HTMLデータを例として説明する。)を作成可能なプログラムが実装されている。
ユーザ端末10は、ゲームサーバ20によって提供されるHTMLデータを解釈して表示するウェブブラウザを備えており、ユーザ端末10によるウェブページ上のユーザの操作に基づく要求を、ネットワークを介してゲームサーバ20へ送信し、ゲームサーバ20による処理結果を受信することでゲームの処理を実行する。
通信網NWは、インターネット、WAN(Wide Area Network)、LAN(Local Area Network)、専用回線、または、これらの組み合わせによって構成される情報通信ネットワークである。
【0019】
(1−2)ユーザ端末の構成
図2を参照してユーザ端末10について説明する。
図2に示すように、ユーザ端末10は、CPU(Central Processing Unit)11、ROM(Read Only Memory)12、RAM(Random Access Memory)13、操作入力部15、表示部16、通信インタフェース部17、および、ストレージ18を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス19が設けられている。
【0020】
CPU11は、ROM12に格納されているプログラムやデータを読み出して、ユーザ端末10内の各部との制御信号やデータ信号のタイミング処理等、ユーザ端末10内の全体の動作を制御する。CPU11はまた、ストレージ18に記憶されているプログラムや、プログラムの実行に必要な各種データを読み出してRAM13に展開し、プログラムの実行に伴うデータの入出力処理、演算処理、判定処理等の各種処理を行う。RAM13は、CPU11による演算処理、判定処理等のために一時的にデータを記憶する。
【0021】
例えば、CPU11は、ストレージ18内に格納されているウェブブラウザをRAM13にロードして実行する。そして、CPU11は、操作入力部15等によってユーザに入力されるURL(Uniform Resource Locator)の指定に基づき、通信インタフェース部17を介して、ゲームサーバ20からウェブページを表示するためのデータ、すなわち、HTML(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ(以下、総称して適宜「HTMLデータ」と表記する。)を、通信インタフェース部17を介して取得し、ウェブブラウザを実行してHTMLデータを解釈する。なお、ユーザ端末10には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてもよい。そのようなプラグインの一例は、米国のアドビシステムズ社によるフラッシュプレイヤである。あるいは、本実施形態でのHTMLデータを、動画および音声の再生機能を備えたHTML5形式としてもよい。
【0022】
ウェブブラウザは、ゲームサーバ20とHTTP(HyperText Transfer Protocol)に従った通信を行う。ウェブブラウザは、ユーザによる操作入力部15の操作によってウェブページ上のURL(Uniform Resource Locator)または操作対象(例えば、ソフトウェアボタン(以下、単に「ボタン」と表記する。)等)が選択されると、ウェブページの更新のために、その選択結果を含むHTTPリクエストをゲームサーバ20に送信する。ウェブブラウザは、HTTPレスポンスとしてゲームサーバ20からHTMLデータを取得し、解釈して、ウェブページを表示部16に表示する。
【0023】
表示部16は、たとえば、LCD(Liquid Cristal Display)や有機EL(Electro Luminescence)ディスプレイ等の表示デバイスである。マトリクス状に画素単位で配置された薄膜トランジスタを含むLCD(Liquid Cristal Display)モニタを適用した場合、表示部16は、薄膜トランジスタを駆動することでウェブページの画像を表示画面に表示する。
【0024】
ユーザ端末10が釦入力方式のユーザ端末である場合、操作入力部15は、例えば、ユーザの操作入力を受け入れるための方向指示釦、決定釦、テンキーなどの複数の指示入力釦を備え、各釦の押下(操作)入力を認識してCPU11へ出力するためのインタフェース回路を含む。
ユーザ端末10がタッチパネル入力方式のユーザ端末である場合、操作入力部15は、主として表示画面に指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。
【0025】
ストレージ18は、例えばフラッシュメモリあるいはHDD(Hard Disk Drive)によって構成される記憶装置である。
【0026】
(1−3)ゲームサーバの構成
図3を参照してゲームサーバ20の構成について説明する。
図3に示すように、ゲームサーバ20は、CPU21、ROM22、RAM23、通信インタフェース部24、および、ストレージ25を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス26が設けられている。なお、ゲームサーバ20は、ハードウエアに関しては汎用のネットワークサーバと同一の構成をとることができる。
【0027】
CPU21は、ROM22に格納されているプログラムやデータを読み出して、ゲームサーバ20内の各部との制御信号やデータ信号のタイミング処理等、ゲームサーバ20内の全体の動作を制御する。CPU21はまた、ストレージ25に記憶されているプログラムや、プログラムの実行に必要な各種データを読み出してRAM23に展開し、プログラムの実行に伴うデータの入出力処理、演算処理、判定処理等の各種処理を行う。RAM23は、CPU21による演算処理、判定処理等のために一時的にデータを記憶する。
【0028】
例えば、ストレージ25には、クライアントであるユーザ端末10のウェブブラウザとの間でHTTPに従った通信を行ってウェブサービスを提供するプログラムが格納されている。CPU21は、ストレージ25に格納されているプログラムをRAM23に展開して、プログラムを実行する。プログラムの実行に伴ってCPU21は、通信インタフェース部24を介してユーザ端末10からHTTPリクエストを取得し、当該HTTPリクエストに応じた処理を実行し、その実行結果を含むHTMLデータ(後述する画像データの一例)をHTTPレスポンスとしてユーザ端末10へ返す。
【0029】
ストレージ25は、例えばフラッシュメモリあるいはHDD(Hard Disk Drive)によって構成される情報記録装置であり、上述したプログラムに加え、データテーブル群70を格納する。データテーブル群70(後述する)は、カードデータテーブル、進化合成データテーブル、クエストデータテーブル、所持カードデータテーブル、予約データテーブル、所持履歴データテーブル、および、カード流通データテーブルを含む。各データテーブルは、適宜CPU21からデータの読み書きのためにアクセスされる。
【0030】
(1−4)本実施形態のゲームのカードの入手条件の提示
本実施形態のゲームシステム1において実行されるゲームは、ユーザがオブジェクトとしてのカードを利用して実行するゲームである。このゲームでは、例えば、ユーザがゲーム上のエリアを探索してカードやアイテムを取得し、あるいはユーザが所持するカードを用いて他のユーザやNPC(Non-Player Character)と対戦するゲームである。
本実施形態のゲームにおいて、カードの進化合成処理(以下、適宜単に「進化合成」という。)とは、所定の条件を満足する場合に、ユーザが所持するカードを進化させる処理である。カードの進化合成は、本実施形態の例では後述するようにカードIDを変更する処理であるが、カードに対応するカードデータ(後述する)の少なくとも一部を変更する処理であってもよい。その場合、カードデータの変更対象は特に問わないが、例えば、カード名やカード画像、レアリティ等のカードパラメータである。カードの進化合成は、オブジェクトを変化させる処理の一例である。
進化合成を実行するには、ユーザは自身が所持するカード(以下、適宜「所持カード」という。)の中から、進化させたいカード(つまり、カードデータを変化させる処理の対象とするカード)としてベースカードを選択する。ベースカードとして選択されたカードは、選択オブジェクトの一例である。
進化合成では、ベースカードごとに、そのベースカードを進化させるのに必要な複数のカード(「参照カード」という。)の組合せ条件が決められている。進化合成が実行されると、その進化合成に使用された参照カードはユーザの所持カードから消失する。
本実施形態のゲームでは、ユーザによってベースカードとして選択されたカードに対応する組合せ条件となる複数の参照カードのすべてをユーザが所持していることが、選択されたカードを進化させるための条件(変化条件の一例)である。
【0031】
なお、本実施形態のゲームでは、ユーザが自身の所持カードを失う処理として、例えば、通常合成処理と売却処理が設けられる。通常合成処理を実行するには、ユーザは自身の所持カードの中から、成長させたいカードとしてベースカードを選択する。通常合成処理では、カードを変化させる処理(例えば、進化合成処理)を行うための条件が定義された変化条件がベースカードごとに決められておらず、ユーザは適宜参照カードを所持カードの中から選択することができる。通常合成処理が実行されると、ベースカードのカードパラメータが変化する(例えば、カードレベルやスキルレベルが増加する)代わりに、参照カードはユーザの所持カードから消失する。
売却処理では、ユーザの所持カードの中から選択されたカード(例えば、ユーザが不要とするカード)を、そのカードに対応する売却価格(例えば、ゲーム上のポイント)をユーザが得る代わりに、売却したカードはユーザの所持カードから消失する。
【0032】
本実施形態のゲームにおいて、ユーザが所望のカードを進化合成によって進化させたいが当該カードを進化させるのに必要な参照カードの一部、あるいはすべてをユーザが所持していない場合を考える。この場合、参照カードの組合せの条件を満たすための新しいカード(つまり、残りの参照カード)をユーザが入手できるまで所望のカードの進化合成を実行することを待機する必要がある。しかし、ユーザが、残りの参照カードを入手するための条件(以下「入手条件」という)を忘れてしまった場合、当該参照カードの入手は難しくなる。特に、入手したカードの数が多くなればなるほど、カード毎の入手条件を忘れてしまう可能性が高くなる。
そこで、本実施形態では、ベースカードを進化させるのに必要となる複数の参照カードのうち、ユーザが所持していない参照カード(未所持カードまたは未知カード)の入手条件を提示できるようにする。なお、未所持カードとは、ユーザにより所持されたことがあり、かつ、ベースカードを選択した時点でユーザが所持していないカードである。一方、未知カードとは、ユーザにより所持されたことがないカードである。
【0033】
参照カードの入手条件の提示について、
図4を参照して具体的に説明する。
図4は、参照カードの入手条件の提示を概念的に説明するための図である。
図4において、ユーザが自身の所持カードであるカードQを進化させたい場合を考える。ここでは、カードQを進化させるために、複数の参照カードとしてのカードA,B,Cの組合せが必要となる場合を想定する。ユーザは現時点でカードBを所持していないため、カードQに対して進化合成を実行することはできない。また、ユーザは、カードBの入手条件を忘れてしまったため、カードBを入手することも難しい。その場合に、本実施形態では、ユーザがカードBを容易に入手できるように、カードBの入手条件の提示の要求に応じて、カードBの入手条件がユーザに提示される。その結果、ユーザは、カードBを容易に入手できる。
【0034】
(1−5)データテーブルの構成
次に、ゲームサーバ20のストレージ25に格納されるカードデータテーブル、進化合成データテーブル、クエストデータテーブル、所持カードデータテーブル、予約データテーブル、所持履歴データテーブル、および、カード流通データテーブルについて、
図5〜11を参照して順に説明する。
【0035】
(i)カードデータテーブル
カードデータテーブルには、本実施形態のゲームで使用されるカードのデータが記録されている。
図5にカードデータテーブルの構成例を示す。
図5に示す例では、カードIDごとにカード名、カード画像、および、カードパラメータのデータが含まれる。
カードIDは、オブジェクトの一例であるカードを特定する識別情報である。カードIDは、カードごとに一意に付される。カードIDによって、複数のカードの中から1つのカードが特定される。つまり、カードIDは、オブジェクトを特定するオブジェクト識別情報の一例である。
カード名は、カードに表示されるキャラクタの名称を示す文字列である。カード画像は、カードに表示されるキャラクタの画像である。カードパラメータは、レアリティ、属性、コスト、スキル、売却価格、攻撃力、防御力、および、限定フラグの各データから構成されている。
レアリティは、カードの希少価値を示す指標であり、
図5に示す例ではR1〜R5の順にレアリティが高く設定されている。
属性は、カードに表示されるキャラクタの属性であり、
図5に示す例ではN1〜N3のいずれかである。
コストは、カードをユーザのカードチームに組み込むときに参照される値である。例えばカードチームによる対戦を行う場合には、カードチームに含まれるカードのコストの総和が所定値以下に制限される。
スキルは、カードを用いてゲームを実行するときに有利となる効果を示す情報であり、
図4に示す例では、SK1〜SK12の様々な効果を備えたスキルが各カードに設定されている。なお、すべてのカードがスキルを備えていなくてもよい。
売却価格は、ユーザが自身で所持しているカードを売却するときにユーザが得られるゲーム上のポイントである。
攻撃力および防御力は、カードを対戦で用いるときに参照されるパラメータである。
限定フラグは、期間限定で発行されたカードであるか否かを示すフラグである。
図4に示す例では、限定フラグが「1」であるカードは期間限定で発行されたカードであることを意味し、限定フラグが「0」であるカードは期間限定でないカードであることを意味する。
【0036】
(ii)進化合成データテーブル
進化合成データテーブルには、本実施形態のゲームのカードの進化合成の条件が記録されている。
図6に進化合成データテーブルの構成例を示す。
図6に示す例では、進化合成の内容を識別するための進化IDごとに、進化前カードID(つまり、進化前のベースカードとなるカードのカードID)、進化後のカードID(ベースカードの進化後のカードID)、および、進化合成を実行するために必要となる参照カードのカードIDの変化条件(C1〜C5の欄の5枚の参照カード)が記録されている。例えば、進化ID:0002が示す条件では、ユーザが所持カードの中からカードID:0072のカードをベースカードとして選択し、ユーザの所持カードの中にカードID:0025,0060,0070の3枚のカードの組合せが存在する場合には、進化合成を実行することによって、カードID:0072のカードをカードID:9072のカードに進化させることができる。
ここでは、オブジェクトを変化させる処理の一例として、オブジェクトの一例であるカードの進化合成の処理について説明する。上述した通り、カードIDは、オブジェクト識別情報の一例である。つまり、
図6は、オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報が変化条件に含まれることを示している。
なお、参照カードのカードIDの組合せを示すC1〜C5の欄には、少なくともいずれか2つの欄に同一のカードIDが記録されていることもある。例えば、ベースカードを進化合成するときに使用する参照カードの組合せに同一の参照カードが2枚以上含まれていてもよい。ベースカードを進化させるための参照カードの組合せ条件が、同一のカードIDである参照カードが所定数含まれることである場合には、
図6に示したようなデータ形式ではなく、参照カードのカードIDとその枚数とからなるデータ形式であってもよい。
【0037】
(iii)クエストデータテーブル
クエストデータテーブルには、本実施形態のゲームで実施されるイベントの1つであるクエストのデータが記録されている。クエストは、カードやアイテムを入手するために、ユーザがゲーム内のエリアを探索して、所定のクエスト条件を達成することを目的とするイベントである。
図7にクエストデータテーブルの構成例を示す。
図7に示す例では、クエストIDごとにエリア名、消費体力、入手可能なカードに関する情報(カードIDおよび入手率)、入手可能なアイテムに関する情報(アイテムIDおよび入手率)、ボスID、および、クエストUIデータが含まれる。
エリア名は、クエストで使用されるエリアの名称を示す文字列である。
消費体力は、クエストを実施するときに参照される値である。クエストを実施するには、ユーザのパラメータの1つである体力の値が消費体力の値以上である必要がある。クエストを実施すると、ユーザの体力の値が消費体力の値の分だけ消費される。
入手可能なカードに関する情報(入手カードデータ1,2…)は、カードIDおよび入手率から構成されている。カードIDは、クエスト条件を達成したときに入手可能なカードの識別情報である。入手率は、クエスト条件を達成したときにカードを入手できる確率を示す数値である。
入手可能なアイテムに関する情報(入手アイテムデータ1…)は、アイテムIDおよび入手率から構成されている。アイテムIDは、クエスト条件を達成したときに入手可能なアイテムの識別情報である。入手率は、クエスト条件を達成したときにアイテムを入手できる確率を示す数値である。
ボスIDは、クエスト内の対戦相手となるNPC(例えば、ボスキャラクタ)の識別情報である。クエスト条件は、例えばボスキャラクタとの対戦に勝利することにより達成される。
クエストUIデータは、クエストで使用されるユーザインタフェースのデータ(例えば、クエストで使用される画像データ)である。
【0038】
(iv)所持カードデータテーブル
所持カードデータテーブルは、ユーザの所持カードの情報が記録されている。
図8に所持カードデータテーブルの構成例を示す。
図8では1ユーザの分の所持カードデータテーブルを例示するが、所持カードデータテーブルは、ゲームに登録しているすべてのユーザに対応して設けられる。
図8に示す所持カードデータテーブルには、カードIDごとに、シリアル番号、カードレベル、スキルレベル、および、予約IDの各データが対応付けられて記録されている。シリアル番号は、ユーザにカードが付与された時点で決定される固有の番号である。同一のカードIDのカードに対しても異なるシリアル番号が付される。なお、カードが進化した場合には、そのカードの進化前後でシリアル番号を変化させてもよいし、変化させなくてもよい。
カードレベルはカードの育成レベルを示すパラメータであり、例えば上記通常合成を実行することによって増加する。ユーザがカードを取得した時点でのカードレベルの値(初期値)は1であり、ユーザは通常合成等を実行することでそのカードを成長(つまり、カードレベルを増加)させることができる。
スキルレベルはカードの育成レベルを示すパラメータであり、特にカードが備えるスキルのレベルを示すパラメータである。ユーザがスキルを備えたカードを取得した時点でのスキルレベルの値(初期値)は1であり、例えば所定の条件を満たすカードを参照カードとした通常合成を行うことによってカードのスキルレベルを増加させることができる。カードのスキルレベルが増加するにつれて、スキルによって発生する効果が増大する。
予約IDは、進化合成のための予約内容を識別するための識別情報である。予約済カードとなっているユーザの所持カードは、予約IDが対応付けられている。例えば、
図8に示す例では、カードID:0591,0010(2枚)、0033、2005の5枚のカードが予約済カードであることを示している。所持カードデータテーブルに記録されている予約IDは、後述する予約データテーブルに記録されている予約IDに対応している。
【0039】
(v)予約データテーブル
予約データテーブルは、ユーザの進化合成のための予約済カードの情報が記録されている。
図9に予約データテーブルの構成例を示す。
図9では1ユーザの分の予約データテーブルを例示するが、予約データテーブルは、ゲームに登録しているすべてのユーザに対応して設けられる。
図9において、予約IDは進化合成の予約が行われた順に発行されるIDである。
図9に示す例では、01,02,…といった具合に昇順に番号が記録される。進化IDは、進化合成データテーブルに示した進化IDに対応しており、進化合成の内容を特定するIDである。
予約済カードのシリアル番号のうち、進化前カードのシリアル番号は、進化合成のベースカードとしてユーザによって選択された所持カードのシリアル番号である。予約済みカードのシリアル番号のうち参照カードのC1〜C5の欄は、それぞれ、進化合成データテーブルの参照カードIDの組合せを構成するC1〜C5の欄に対応する。
予約済みの参照カードが所持カードである場合、当該参照カードのカードIDに対応する欄に所持カードデータのシリアル番号が記録される。予約済みの参照カードが未所持カードである場合、当該参照カードのカードIDに対応する欄に仮のシリアル番号(例えば、「00000000」)が記録され、当該参照カードが所持カードになった(つまり、当該参照カードのカードIDおよびシリアル番号によって特定される所持カードデータが追加された)後に、仮のシリアル番号が当該参照カードのシリアル番号に書き換えられる。予約済みでない参照カードのカードIDに対応する欄には、「予約無し」を示すデータ(例えば、NULL)が記録される。
なお、以下では、予約データテーブルを設ける場合について説明するが、予約データテーブルを独立して設けることは必須ではない。進化合成のための予約の管理方法として、予約データテーブルに記録すべきデータを、所持カードデータテーブルに記録してもよい。その場合には、所持カードデータテーブルにおいて、予約済カードのカードIDに対応付けて、予約ID、進化ID、C1〜C5のいずれかの文字列(進化合成データテーブルのC1〜C5の欄に対応する文字列であれば何でもよい。)が記録される。
【0040】
(vi)所持履歴データテーブル
所持履歴データテーブルには、ユーザが所持したことのあるカードの情報が記録されている。
図10に所持履歴データテーブルの構成例を示す。
図10では1ユーザの分の所持履歴データテーブルを例示するが、所持履歴データテーブルは、ゲームに登録しているすべてのユーザに対して設けられる。
図10に示す所持履歴テーブルには、カードIDごとに入手回数が対応付けられて記録されている。入手回数は、ゲーム内でユーザがカードを入手した回数を示す値である。入手回数が0回のカードは、未知カードである。
【0041】
(vii)カード流通データテーブル
カード流通データテーブルには、ゲーム内で流通しているカードに関する情報が記憶されている。
図11にカード流通データテーブルの構成例を示す。
図11に示す例では、カード流通データテーブルは、カードIDごとに、流通数および平均取引価格が記録されている。
流通数は、ゲーム内でユーザが取引(例えば、売買)の対象のカードとして設定したカードの総数を示す値である。流通数が多いほど、カードの入手難易度が低いことを意味する。
平均取引価格は、ユーザ間でカードを取引するときの価格の平均値である。平均取引価格が高いほど、カードの入手難易度が高いことを意味する。
【0042】
以下の説明では、カードデータテーブル、クエストデータテーブル、所持カードデータテーブル、所持履歴データテーブル、および、カード流通データテーブルにおいてカードIDに対応付けられた情報(例えば、カード名、カード画像、カードパラメータ、クエストID、エリア名、消費体力、入手率、ボスID、クエストUIデータ、シリアル番号、カードレベル、スキルレベル、予約ID、入手回数、流通数、および、平均取引価格)を総称して、適宜「カードデータ」という。カードデータは、オブジェクトを示す情報の一例である。
【0043】
(1−6)入手条件の提示処理および進化合成処理の具体例
以下、本実施形態のゲームのカードの入手条件の提示処理および進化合成処理の具体例について、
図12A、
図12B、
図13A、
図13B、および、
図14を参照しながら説明する。
図12A、
図12B、
図13A、
図13B、および、
図14はそれぞれ、本実施形態のゲームの処理を実行しているときのユーザ端末10に表示される画面の一例を示す図である。
【0044】
(1−6−1)入手条件の提示処理
(1−6−1−1)未所持カードの入手条件の提示処理(
図12Aおよび
図12B)
図12Aおよび
図12Bは、未所持カードの入手条件を提示するための入手条件の提示処理の一連の表示画面の変化を示している。
図12Aにおいて、画像P1は、本実施形態のゲームにおいてユーザがモンスターカード(以下、単に「カード」という。)について、処理の要求を行うときの画像である。画像P1には、ユーザの操作対象として、ボタンb1(「所持モンスターを見る」)、ボタンb2(「チーム編成」)、ボタンb3(「通常合成」)、ボタンb4(「進化合成」)、ボタンb5(「売却」)が設けられる。
ボタンb1は、ユーザの所持カードの閲覧処理の要求を行うときに操作されるボタンである。ボタンb2は、ユーザが自身の所持カードの中から他のユーザやNPCとの対戦において使用するカードを選択するときに操作されるボタンである。ボタンb3は、ユーザが所持カードの中からベースカードとして選択したカードの通常合成処理の要求を行うときに操作されるボタンである。ボタンb4は、ユーザが所持カードの中からベースカードとして選択したカードの進化合成処理の要求を行うときに操作されるボタンである。ボタンb5は、ユーザが所持カードの中から選択したカードに対して売却処理の要求を行うときに操作されるボタンである。
【0045】
画像P1においてボタンb4(「進化合成」)が操作されると、P2に示すように画像が変化する。画像P2では、ユーザの所持カードの中からいずれかのカードをベースカードとして選択するために、複数の所持カードが一覧表示される。なお、進化することができないカード(図示する例では、カードTOM,TED,DSG)についてはベースカードとして選択できないように、画像が構成されている。すなわち、画像P2では、ユーザの所持カードのうち進化可能なカードと進化不可能なカードとをユーザが識別可能な表示形式で示している。進化可能なカードと進化不可能なカードとをユーザが識別可能な表示形式で示す方法は、
図12Aの画像P2に示した例に限られない。所持カードの一覧は各カードのカード名の文字列の一覧であってもよく、その場合には、進化可能なカードと進化不可能なカードとを文字列の輝度、サイズ等によって識別できるようにしてもよい。
画像P2において、進化可能ないずれかのカードとして例えばカードKLMが選択されると、P3に示すように画像が変化する。画像P3には、選択したカードを進化合成のベースカードとして確定させるためのボタンb6(「選択する」)と、画像P2に戻って別のカードをベースカードとして選択するためのボタンb7(「戻る」)とが含まれる。
画像P3においてボタンb6が操作されると、ベースカードとして選択されたカードKLMが進化するために必要な参照カードの条件を満たしていない場合には、P4に示すように画像が更新される。画像P4は、ベースカードとして選択されたカードKLMが進化するために必要な参照カードのうち未所持カードの入手条件の提示を要求するための画像である。なお、画像P3においてユーザがボタンb6を選択した時点で、ベースカードとして選択されたカードKLMが進化するために必要な参照カードの条件を満たしている場合には、カードKLMの進化合成の実行を要求するための画像(図示せず)が表示される。
【0046】
画像P4には、進化前カード(ここでは、ベースカードであるカードKLM)と進化後カード(例えば、カードQRS)とを示す表示領域101、進化合成に必要な参照カードとその状態(所持、未所持、予約済、未知のいずれか)を示す表示領域102、および、参照カードの入手条件の提示を要求するためのボタンb8(「入手条件を表示する」)が含まれる。画像P4において、入手条件を表示すべき参照カード(ここでは、表示領域102に「未所持」の状態が示されたカードDSG)が選択され、且つ、ボタンb8が操作されると、
図12Bに示すように、ユーザによって選択された参照カードの入手条件を示す画像P5が表示される。
なお、当該ユーザによって選択された参照カードは、「ユーザによって指定された参照カード」ともいう。また、参照カードは、オブジェクトの一例であるので、「ユーザによって指定された参照カード」は、ユーザによって指定されたオブジェクトである「指定オブジェクト」の一例である。
【0047】
図12Bの画像P5には、ユーザによって選択された参照カード(ここでは、カードDSG)、ならびに、当該参照カードのカード画像、カード名、および、レアリティを示す表示領域103と、当該参照カードの入手条件を示す表示領域104と、を含む。表示領域104には、入手難易度に関する情報104a(ここでは、入手回数、流通数、および、平均取引価格)、および、入手経路に関する情報104b(ここでは、入手可能エリア)が示される。
【0048】
(1−6−1−2)未知カードの入手条件の提示処理(
図13Aおよび
図13B)
図13Aおよび
図13Bは、未知カードの入手条件を提示するための入手条件の提示処理の一連の表示画面の変化を示している。
図13Aの画像P1〜P3は、それぞれ
図12Aの画像P1〜P3と同様である。
図13Aの画像P4は、表示領域102に未知カードが示されている点において、
図12Aの画像P4と異なる。未知カードとは、未所持カードのうち、ユーザが1回も所持したことがない(例えば、所持履歴データテーブルにおける「入手回数」の値が0回である)カードである。画像P4において、入手条件を表示すべき参照カード(ここでは、表示領域102に「未知」の状態が示されたカード)が選択され、且つ、ボタンb8が操作されると、
図13Bに示すように、ユーザによって選択された参照カードの入手条件を示す画像P5が表示される。
【0049】
図13Bの画像P5は、表示領域103に、ユーザによって選択された参照カードが当該ユーザにとって未知カードであることを示す画像が示されており、且つ、表示領域104に、当該参照カードの入手条件のうち入手難易度に関する情報104b(ここでは、入手回数および流通数)のみが示されている(つまり、
図12Bの画像P5における入手経路に関する情報104aがマスクされている)点において、
図12Bの画像P5と異なる。
【0050】
(1−6−2)進化合成処理(
図14)
図14は、ユーザの操作に基づいて進化合成処理を実行するときの一連の表示画面の変化を示している。
図14において画像P10は、ユーザがゲームを実行中に新たなカードDSGを入手した場合に表示される画像の一例である。
この新たなカードDSGを入手したことで、予約済みの進化合成の変化条件が満たされるようになった場合には、新たなカードの入手によって、当該変化条件が満たされるようになったことをユーザに通知することが好ましい。より好ましくは、P11に示すように進化合成を実行するための画像を表示することが好ましい。
画像P11は、進化前カード(カードKLM)と進化後カード(カードQRS)とを示す表示領域101、進化合成に必要な参照カードとその状態(ここでは、所持)を示す表示領域102、および、進化合成を実行するか否かの要求を受け付けるためのボタンb20(「はい」)およびボタンb21(「いいえ」)が表示される。
画像P11においてボタンb20が操作されると、P12に示すように画像が変化する。画像P12の例では、進化後カードのカード画像、カード名、および、パラメータの少なくとも一部が表示される。
【0051】
(1−7)情報処理装置が備える機能の概要
次に、上述した本実施形態のゲームを実現するためにゲームサーバ20が備える機能について説明する。
図15は、本実施形態のゲームサーバ20で主要な役割を果たす機能を説明するための機能ブロック図である。
図15において、データテーブル群70は、前述したように、カードデータテーブル、進化合成データテーブル、クエストデータテーブル、所持カードデータテーブル、予約データテーブル、所持履歴データテーブル、および、カード流通データテーブルを含む。なお、
図15に示す機能ブロック図に含まれる手段のすべてが本発明に必須の要素とは限らない。
【0052】
受付手段51は、ユーザの操作入力に関する情報に基づいてユーザからの各種の要求を受け付ける機能を備える。本実施形態のゲームにおいてユーザからの要求としては、例えば、カードの入手条件の提示処理の要求、進化合成処理の要求、クエスト処理の要求、進化合成の予約処理の要求、進化合成の実行要求、ユーザの所持カードの閲覧処理の要求、ユーザの所持カードの売却処理の要求などがある。
入手条件の提示処理の要求は、出力手段56により画像データが出力されたことに応じて、ベースカードの進化合成に必要な参照カードの入手条件を提示させる要求である。
進化合成の予約処理の要求は、出力手段56により画像データが出力されたことに応じて、進化合成におけるベースカード、および、ベースカードに対応する複数の参照カードうち少なくともいずれかのカードを進化合成のために予約し、当該カードをユーザの所持カードから消失させることを条件として実行される処理のうち当該進化合成以外の処理(例えば、当該カードの売却処理、または、当該カードを他のユーザに譲渡する処理)に用いられることを制限させる要求である。進化合成の予約処理の要求には、予約の対象となる参照カードのカードIDが含まれる。
受付手段51の機能を実現するために、ゲームサーバ20は、通信インタフェース部24を介して、ユーザ端末10から画像であるウェブページ内のユーザによるボタンの操作入力に対応する要求を受信する。ゲームサーバ20のCPU21は、受信した要求に含まれる情報に基づいて、要求の内容を判別し、要求の受付処理を行う。受付処理では、要求がRAM13に記録される。CPU21は、受け付けられた要求に応じた処理を順に実行する。
【0053】
ゲーム処理手段52は、受付手段51にて受け付けたユーザからの要求および指示に基づいて、進化合成以外の様々なゲームの処理を実行する機能を備える。本実施形態のゲームの処理は、適宜設けられてよいが、例えば、ユーザ間の対戦処理、ユーザ対NPCの対戦処理、ユーザによるクエスト処理、ユーザの所持カードの通常合成の処理、ユーザの所持カードの売却処理である。
対戦処理については詳しく述べないが、例えば、ユーザは、コストの総和が所定の上限値以下となるように予め複数の所持カードからなるチームを編成し、チームによって他のユーザまたはNPCと対戦する。対戦結果は、チームを構成する各カードの攻撃力、防御力、スキルなどのパラメータによって決定される。
【0054】
クエスト処理を実行する場合のゲーム処理手段52の機能は、以下のようにして実現される。ゲームサーバ20のCPU21は、クエストIDを含むクエスト処理の要求を受け付けると、クエストデータテーブルから、当該クエストIDに対応付けられたクエストデータ(エリア名、消費体力、入手カードデータ(カードIDおよび入手率)、入手アイテムデータ(アイテムIDおよび入手率)、ボスID、および、クエストUIデータ)を読み出してRAM23に展開する。次いでCPU21は、クエストUIデータに基づいてクエストの実行画面を表示させるとともに、ユーザの操作に応じてクエストを進行させる。クエストが所定レベルまで進行すると、CPU21は、ボスIDに対応付けられたボスキャラクタとユーザとの対戦を実行する。ユーザが当該対戦において勝利条件を満たすと、CPU21は、クエストIDに対応付けられた「入手率」の値に応じてカードを付与する処理を実行する。カードを付与する処理では、CPU21は、クエストIDに対応付けられたカードIDを所持カードデータテーブルに書き込むとともに、所持履歴データテーブルにおいて当該カードIDに対応付けられた「入手回数」の値を増加させる。
なお、ユーザが当該対戦において勝利条件を満たした場合、アイテムを付与する処理も、カードを付与する処理と同様に実行される。
【0055】
ユーザの所持カードの通常合成の処理を実行する場合のゲーム処理手段52の機能は、以下のようにして実現される。ゲームサーバ20のCPU21は、ベースカードおよび参照カードについてのユーザの選択結果を含む通常合成の実行要求を受け付けると、所持カードデータテーブルからベースカードおよび参照カードのカードデータを読み出してRAM23に展開する。次いでCPU21は、ベースカードおよび参照カードのパラメータに基づいてベースカードのパラメータ(例えば、カードレベルやスキルレベル)を変更し、変更後のベースカードのパラメータを所持カードデータテーブルに書き込むとともに、所持カードデータテーブルから参照カードとした所持カードのカードデータを削除する。なお、ベースカードのカードレベルやスキルレベルは、通常合成を実行する度に常に増加するとは限らない。例えば、通常合成を実行する度にカードに対応付けられた育成パラメータの値を増加させ、その育成パラメータの値が所定値に達した場合にカードレベルを1つ増加させるとともに育成パラメータの値をゼロにリセットするようにしてもよい。
【0056】
ユーザの所持カードの売却処理を実行する場合のゲーム処理手段52の機能は、以下のようにして実現される。ゲームサーバ20のCPU21は、売却処理の要求を受け付け、売却対象のカードの選択結果を受け付けると、所持カードデータテーブルから売却対象のカードのカードデータを削除する。次いでCPU21は、カードデータテーブルから売却対象のカードの売却価格の値(ポイント)を読み出し、読み出したポイントをユーザに付与する処理を行う。ポイントをユーザに付与する処理は、例えば、ユーザデータベース(図示せず)に記録されているユーザの所持ポイントの値を更新する処理である。
【0057】
カードデータ変更手段54は、変化条件を満たす複数の参照カードの全てがユーザの所持カードに含まれる場合に、ベースカードのカードデータを変更する進化合成を実行する機能を備える。
本実施形態の例では、カードデータ変更手段54の機能を実現するために、ゲームサーバ20のCPU21は、進化合成の実行要求を受け付けると、所持カードデータテーブルにおいて、進化前カード(つまり、進化合成のベースカード)のカードデータを消去し、進化後カードのカードデータを新たに書き込む。それによって、ユーザの所持カードのベースカードが進化することになる。なお、進化合成データテーブルに示すように、進化前と進化後とでカードIDは異なるため、カード名、カード画像、および、カードパラメータのうち少なくともいずれかが進化合成によって変更されることになる。
【0058】
取得手段55は、ユーザによって選択されたベースカード(選択オブジェクトの一例)に対応する参照カードの組合せ条件(変化条件の一例)である複数の参照カードIDを、進化合成データテーブルから取得する機能を備える。また、取得手段55は、ユーザによって選択された参照カードが所持カードでない(例えば、未所持カードまたは未知カードである)場合に、当該参照カードのカードデータを、クエストデータテーブル、所持履歴データテーブル、および、カード流通データテーブルから取得する機能を備える。また、取得手段55は、進化合成のためにカードの予約をするに当たって、ユーザの操作入力に基づいて、ユーザの所持カードの中のいずれかのカードのシリアル番号(オブジェクトを示す情報の一例)を取得する機能を備える。
取得手段55が参照カードの組合せ条件である複数の参照カードIDを取得する場合、ゲームサーバ20のCPU21は、ユーザ端末10からベースカードの選択結果を取得したことに応じて、進化合成データテーブルを参照して、ベースカードに対応する組合せ条件を構成する複数の参照カードIDを読み出す。
取得手段55がユーザによって選択された参照カードのカードデータを取得する場合、ゲームサーバ20のCPU21は、ユーザ端末10から参照カードの選択結果を取得したことに応じて、クエストデータテーブル、所持履歴データテーブル、および、カード流通データテーブルを参照して、当該参照カードのカードデータを読み出す。
取得手段55がカードのシリアル番号を取得する場合、ゲームサーバ20のCPU21は、ユーザ端末10から進化合成の予約処理の要求を受け付けると、進化合成の対象となるベースカード、および、当該ベースカードに対応する複数の参照カードの中から、予約済みでない所持カードを、所持カードデータテーブルを参照して特定し、特定したカードのシリアル番号を読み出す。
【0059】
出力手段56は、取得手段55によって取得された変化条件に含まれる複数の参照カードのカードデータを用いて、当該複数の参照カードをユーザにそれぞれ識別可能な表示形式で表示させるための第1出力データ(例えば、画像データ)を出力する機能(以下「第1出力機能」という。)を備える。
本実施形態の例では、出力手段56の第1出力機能を実現するために、ゲームサーバ20のCPU21は、例えばユーザによってベースカードが選択されたときに、そのベースカードを進化させるために必要となる複数の参照カードIDの組合せを進化合成データテーブルから読み出し、各参照カードについて、所持カードデータテーブル、予約データテーブル、および、所持履歴データテーブルに記憶された情報に基づいて、カードの状態(「予約済」、「所持」、「未所持」、および、「未知」のいずれかの状態)を特定する。また、CPU21は、各参照カードの状態をユーザに識別可能な表示形式で表示させるための第1出力データを生成する。
例えば、
図9の予約データテーブルにおいて、ベースカードに対応する進化IDに対応付けられたC1〜C5の欄に所持カードデータに含まれるシリアル番号または仮のシリアル番号が記録されている場合には、該当する欄に対応するカードIDによって特定される参照カードの状態が「予約済」として特定される。
例えば、カードの状態が「予約済」以外のカードについて、
図6の進化合成データテーブルにおいて、ベースカードに対応する進化IDに対応付けられたC1〜C5の欄のカードIDが
図8の所持カードデータテーブルの「カードID」の欄に含まれている場合には、当該カードIDによって特定される参照カードの状態が「所持」として特定される。
例えば、カードの状態が「予約済」および「所持」以外のカードについて、
図10の所持履歴データテーブルにおいて、当該カードIDに対応する「入手回数」の欄が0でない場合には、当該カードIDによって特定される参照カードの状態が「未所持」として特定され、当該カードIDに対応する「入手回数」の欄が0である場合には、当該カードIDによって特定される参照カードの状態が「未知」として特定される。
第1出力データには、特定された参照カードの状態が示される。
【0060】
また、出力手段56は、取得手段55によって取得された参照カードIDに対応する参照カード(未所持カードまたは当該未知カード)の入手条件を提示するための第2出力データ(例えば、画像データ)を出力する機能(以下「第2出力機能」という。)を備える。
本実施形態の例では、出力手段56の第2出力機能を実現するために、ゲームサーバ20のCPU21は、例えば取得手段55によって参照カードIDが取得されたときに、取得された参照カードIDに基づいてクエストデータテーブル、所持履歴データテーブル、および、カード流通データテーブルを参照し、当該参照カードIDに対応する参照カードの入手条件を特定し、当該入手条件を提示するための第2出力データを生成する。
例えば、
図7のクエストデータテーブルにおいて、「入手カード」の「カードID」の欄に取得された参照カードIDが含まれるクエストIDに対応する「エリア名」の欄の情報が、入手可能エリアとして特定される。
図10の所持履歴テーブルにおいて、取得された参照カードIDに対応する「入手回数」の欄の値が、入手回数として特定される。
図11のカード流通データテーブルにおいて、取得された参照カードIDに対応する「流通数」および「平均取引価格」の欄の値が、それぞれ流通数および平均取引価格として特定される。
第2出力データには、特定された入手可能エリア、入手回数、流通数、および、平均取引価格の少なくとも1つが示される。
【0061】
記録手段57は、進化合成の予約処理の要求を受け付けたことに応じて、取得手段55によって取得されたシリアル番号をストレージ25内の予約データテーブルに予約済カードとして記録する機能を備える。本実施形態の例では、予約対象カードは、選択されたベースカードの進化合成以外の処理に用いられることが制限されるカードである。
【0062】
記録手段57の機能を実現するために、ゲームサーバ20のCPU21は、進化合成の予約処理の要求を受け付けると、予約データテーブルにアクセスし、予約対象カードのシリアル番号を書き込む。より具体的には、予約対象カードのうちベースカードとして選択されたカードのシリアル番号が予約データテーブルに記録されていない場合には、新たな予約IDを発行する。CPU21は、発行した予約IDに対応付けて、ベースカードとして選択されたカードのシリアル番号を「進化前カード」の欄に書き込む。さらに、予約対象カードのうち参照カードのシリアル番号に対応するカードIDと同一の「参照カードID」の欄(C1〜C5の欄のいずれか)を特定し、特定した欄に予約対象カードのうち参照カードのシリアル番号を書き込む。
一方、予約IDが発行済みである場合には、「進化前カード」の欄にはシリアル番号が既に記録されているため、CPU21は、予約対象カードのうち参照カードのシリアル番号の書き込みのみを行う。
【0063】
制限手段58は、予約データテーブルに予約済カードとして記録されているカードが、目的とする進化合成以外の処理に用いられることを制限する機能を備える。「目的とする進化合成以外の処理に用いられる」とは、目的とする進化合成に対応付けられて予約済カードとして記録されているカードが、その目的とする進化合成以外の進化合成や通常合成に用いられる場合も含まれる。
制限手段58による制限方法は様々な方法が考えられる。例えば、制限対象となるカードを、ユーザが目的とする進化合成以外の処理を禁止する方法や、制限対象となるカードが目的とする進化合成以外の処理のために選択されたときに、ユーザに対して、当該処理の続行を確認する処理を行う方法などである。
なお、予約済カードについて「処理に用いられることを制限する」とは、予約済カードを用いた、目的とする進化合成以外の処理自体が禁止されることに限られず、予約済カードを用いた、目的とする進化合成以外の処理は実行可能であるが、その処理の実行の手続をし難くする、あるいは処理の実行手続を煩雑にすることであってもよい。予約済カードについての「進化合成以外の処理」が、予約済カードをユーザの所持カードから消失させることを条件として実行される処理(つまり、予約済カードを未所持カードとすることを条件として実行される処理)である場合に、当該処理が制限されることが特に好ましい。
【0064】
例えば、ゲームサーバ20のCPU21は、本実施形態のゲームの様々な処理のいずれかの処理の実行要求を受け付けた場合、ユーザの所持カードが処理対象のカードとして選択されたときには、所持カードデータテーブルを参照して、当該選択されたカードのカードIDに予約IDが対応付けられているか否かについて判定する。CPU21は、選択されたカードのカードIDに予約IDが対応付けられ、かつ実行要求に係る処理が予約IDに対応する進化合成処理ではない場合には、当該処理を禁止してもよいし、選択されたカードが予約済カードであることをユーザに報知してもよい。あるいは、選択されたカードが予約済カードであることをユーザに報知するとともに、処理を続行するか否かについてユーザに確認してもよい。予約データテーブルには進化IDと予約済カードのシリアル番号が対応付けられているため、ゲームサーバ20のCPU21は、予約済カードに対応した、目的とする進化合成(つまり、特定の進化IDに対応した進化合成)を特定することができる。そのため、ユーザが特定の所持カードを用いて実行しようとする処理が、目的とする進化合成の処理であるか否かを判別することができる。
【0065】
記録手段57および制限手段58を設けることは必須ではないが、記録手段57および制限手段58を設けることで、例えば、進化合成に必要となる複数の参照カードのうち一部の参照カードを進化合成の実行前に予約し、残りの参照カードを入手するまで進化合成を待機しているユーザが、所持カードを誤って進化合成以外の処理に使用してしまうことを防止できる。
【0066】
(1−8)本実施形態のゲームの処理フロー
次に、本実施形態のゲームの処理フローの一例について、
図16A、
図16B、および、
図17のシーケンスチャートを参照して説明する。
図16Aおよび
図16Bは、入手条件の提示処理を示すシーケンスチャートである。
図17は、進化合成処理を示すシーケンスチャートである。
なお、各図において、
図12A、
図12B、
図13A、
図13B、および、
図14に示した各画像P1〜P5、および、P10〜P12が表示されるステップに各画像の符号を付してある。
【0067】
(1−8−1)入手条件の提示処理(
図16A〜
図16B)
以下で説明する入手条件の提示処理では、一例として、ユーザが、ベースカードと、当該ベースカードを進化合成させるための複数の参照カードの一部とを所持している場合に、未所持または未知の参照カードの入手条件の提示を要求する場合を想定する。
【0068】
図16Aにおいて、ユーザ端末10に表示された画像上で所定のボタン(例えば、
図12Aまたは
図13Aの画像P1のボタンb4)をユーザが操作することによって、ユーザ端末10のCPU11は進化合成処理の要求を受け付け(S10)、当該要求をゲームサーバ20へ送信する(S12)。
ゲームサーバ20のCPU21は、ユーザ端末10からの入手条件の提示処理の要求を受け付けると、進化合成データテーブルおよび所持カードデータテーブルを参照して、進化可能なユーザの所持カードを読み出す(S14)。すなわち、CPU21は、所持カードデータテーブルからユーザの所持カードのカードデータを読み出し、進化合成データテーブルの進化前カードID(つまり、進化可能なカードのカードID)をすべて読み出す。次いでCPU21は、ユーザの所持カードの中から進化可能なカード(つまり、ベースカード候補)を特定し、ベースカード候補のカードデータを含む画像データを生成し(S16)、当該画像データをユーザ端末10へ送信する(S18)。
なお、S16で生成される画像データは、
図12Aまたは
図13Aの画像P2に示したように、ユーザの所持カードのうち進化可能なカードの画像と進化不可能なカードの画像とが異なる表示態様となるようにして生成されることが好ましい。
【0069】
ユーザ端末10のCPU11は、S18で送信された画像データを受け付けると、当該画像データに基づいて画像を表示部16に表示する(S20)。S20で表示される画像には、
図12Aまたは
図13Aの画像P2に例示したように、ベースカード候補となる複数のカードの画像が含まれ、各カードの画像を操作することで各カードのシリアル番号が選択可能となるようにして構成されている。S20で表示された複数のベースカード候補の中でいずれかのカードがベースカードとして選択する操作がユーザにより行われると、CPU11は、ベースカードの選択結果(シリアル番号)を受け付け(S22)、当該選択結果をゲームサーバ20へ送信する(S24)。
【0070】
ゲームサーバ20のCPU21は、S24で送信された選択結果(シリアル番号)を受け付けると、進化合成データテーブルを参照し、ユーザによって選択されたベースカードのシリアル番号に対応付けられたカードIDと一致する進化前カードIDに対応する複数の参照カードID(C1〜C5の欄のカードID)を読み出す(S26)。次いでCPU21は、所持カードデータテーブルおよび予約データテーブルを参照して、S26で読み出した各参照カードIDに対応するカードの状態(未所持、所持、予約済、および、未知のいずれか)を特定し、当該特定結果に基づいて画像データを生成する(S28)。
【0071】
S28では、ゲームサーバ20のCPU21は以下のようにして各参照カードIDに対応するカードの状態を特定する。
CPU21は、予約データテーブルの「予約済カードのシリアル番号」の欄に記録されているシリアル番号を読み出し、所持カードデータテーブルを参照して、当該シリアル番号に対応付けられたカードIDを特定する。S26で読み出した参照カードIDと特定したカードIDとが一致する場合、または、当該シリアル番号が仮のシリアル番号である場合には、当該カードIDによって特定されるカードの状態を「予約済」として特定する。
CPU21は、「予約済」として特定したカード以外の参照カードについて、所持カードデータテーブルに記録されているカードIDの中に当該参照カードの参照カードIDが含まれている場合には、当該参照カードIDによって特定されるカードの状態を「所持」として特定する。
CPU21は、「予約済」および「所持」以外のカードについて、所持履歴データテーブルの「入手回数」欄の参照カードIDに対応付けられた値が0でない場合、当該参照カードIDによって特定されるカードの状態を「未所持」として特定し、所持履歴データテーブルの「入手回数」欄の参照カードIDに対応付けられた値が0である場合、当該参照カードIDによって特定されるカードの状態を「未知」として特定する。
【0072】
S28では、ゲームサーバ20のCPU21は、S26で読み出したすべての参照カードの状態が「所持」または「予約済」である場合には、カードKLMの進化合成を実行するか否かをユーザが指示するための画像データを生成する。CPU21は、S26で読み出した少なくともいずれかの参照カードの状態が「未所持」または「未知」である場合には、「未所持」または「未知」の状態の参照カードの入手条件を提示するための画像データを生成する。ここでは、
図12Aまたは
図13Aの画像P4の元になる画像データが生成された場合を想定する。
【0073】
次いでゲームサーバ20のCPU21は、S28で生成した画像データをユーザ端末10へ送信する(S30)。ユーザ端末10のCPU11は、S30で送信された画像データを受け付けると、当該画像データに基づく画像を表示部16に表示する(S32)。
【0074】
S32で表示される画像は、
図12Aまたは
図13Aの画像P4に示したように、S22で選択されたベースカードを進化合成するために必要となる複数の参照カードをユーザが識別できるように表示している。
図12Aまたは
図13Aの画像P4は、各々の参照カードの状態が参照カードに対応付けて表示されるとともに、未所持カードまたは未知カードの入手条件の提示処理の要求を受付可能に構成されている。ここで、
図12Aまたは
図13Aの画像P4が表示された後に、入手条件の提示処理の要求を行うための操作(例えば、
図12Aまたは
図13Aの画像P4のボタンb8の操作)がユーザによって行われると、ユーザ端末10のCPU11は、当該操作に対応するユーザの指示に基づいて、入手条件の提示処理の要求を受け付け(S34)、当該要求をゲームサーバ20へ送信する(S36)。S36でユーザ端末10からゲームサーバ20へ送信された要求には、ユーザによって選択された未所持カードまたは未知カード(つまり、入手条件の提示処理において入手条件を提示すべきカード)のカードIDが含まれる。
上述した通り、ユーザによって選択された参照カードは、ユーザによって指定されたオブジェクトである指定オブジェクトの一例である。つまり、S34およびS36の処理は、ユーザの指示に基づいて、複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける処理の一例である。
【0075】
ゲームサーバ20のCPU21は、S36で送信された入手条件の提示処理の要求を受け付けると、カードデータテーブル、クエストデータテーブル、および、カード流通データテーブルから、ユーザによって選択された参照カードのカードデータを取得する(S38)。カード名、カード画像、および、レアリティはカードデータテーブルから取得される。クエストIDおよび入手可能エリアのエリア名は、クエストデータテーブルから取得される。入手回数は、所持履歴テーブルから取得される。流通数および平均取引価格は、カード流通データテーブルから取得される。
【0076】
S28で特定されたカードの状態が「未知」である場合には(S40:YES)、S42へ進み、S28で特定されたカードの状態が「未知」でない場合には(S40:NO)、S44へ進む。
ここでは、カードの状態が「未知」でない場合(つまり、未知カード)の一例として、カードの状態が「未所持」である場合(つまり、未所持カード)の例を説明する。なお、「未知」および「未所持」は、いずれも、ユーザがカードを所持していない(つまり、カードIDが所持カードデータテーブルに含まれていない)状態を示す点で共通する。
【0077】
S42では、ゲームサーバ20のCPU21は、S38で取得したカードデータによって示されるカードに関する情報のうち、入手難易度に関する情報(ここでは、入手回数、流通数、および、平均取引価格)以外の情報(ここでは、カード名、カード画像、レアリティ、および、入手可能エリア)が表示されないように、画像に対してマスク処理を適用する。
なお、本実施形態において、未知カードの入手難易度に関する情報以外の情報が表示されないようにする目的は、ゲーム(特に、未知カードを入手すること)に対する期待感をユーザに与え、かつ、ゲームの趣向性を向上させることにある。
【0078】
S44では、CPU21は、S38で取得した参照カードのカードデータに基づいて、当該参照カードの入手条件(但し、S40において「未知」であると判定された場合には、入手難易度に関する情報)をユーザに提示するための画像データ(
図12Bまたは
図13Bの画像P5の元になる画像データ)を生成し、当該画像データをユーザ端末10へ送信する(S46)。
【0079】
ユーザ端末10のCPU11は、S46で送信された画像データを受け付けると、当該画像データに基づく画像を表示部16に表示する(S48)。
S40で「未知」でない(例えば、「未所持」である)と判定された場合、
図12Bの画像P5に示すように、カード画像、カード名、レアリティ、入手回数、流通数、平均取引価格、および、入手可能エリアが表示される。
一方、S40で「未知」であると判定された場合、
図13Bの画像P5に示すように、入手回数、流通数、および、平均取引価格は表示されるが、カード画像、カード名、レアリティ、および、入手可能エリアは表示されない。
換言すると、未知カードの入手条件として表示される情報は、未所持カードの入手条件として表示される情報より制限される。つまり、S48は、指定オブジェクトが、ユーザが所持したことがないオブジェクトである未知オブジェクトである場合、指定オブジェクトが未所持オブジェクトである場合に比べて、入手条件として表示される情報が制限される処理の一例である。
【0080】
以上の通り、本実施形態では、ユーザによって選択された参照カードをユーザが所持していない場合(当該参照カードが未知カードまたは未所持カードの場合)、当該参照カードの入手条件を表示する例を説明した。これは、指定されたオブジェクトである指定オブジェクトをユーザが所持していない場合、指定オブジェクトの入手条件を表示する処理の一例である。
【0081】
(1−8−2)進化合成処理(
図17)
例えば、ユーザが新たに入手したカードによって進化合成における参照カードの変化条件を満たすことになった場合には、進化合成処理が実行可能になる。
図17において、ユーザ端末10に表示された画像上で所定のボタン(例えば、
図14の画像P11のボタンb20)をユーザが操作することによって、ユーザ端末10のCPU11は、進化合成の実行要求を受け付け(S150)、当該要求をゲームサーバ20へ送信する(S152)。
【0082】
ゲームサーバ20のCPU21は、S152で送信された要求を受け付けると、所持カードデータテーブルにおいて、進化前カード(つまり、進化合成のベースカード)のカードデータを消去し(S154)、進化後カードのカードデータを新たに書き込む(S156)。
次いでゲームサーバ20のCPU21は、所持カードデータテーブルにおいて、進化合成に使用する参照カードのカードデータを消去する(S158)。
【0083】
次にゲームサーバ20のCPU21は、進化後カードのカードデータを含む画像データ(
図14の画像P12の元になる画像データ)を生成し(S160)、当該画像データをユーザ端末10へ送信する(S162)。ユーザ端末10のCPU11は、S162で送信された画像データを受け付けると、当該画像データに基づく画像(例えば、
図14の画像P12)を表示部16に表示する(S164)。
【0084】
以上説明したように、本実施形態のゲームシステムでは、オブジェクトを変化させる処理の一例であるカードの進化合成を実行するためには、進化合成の対象となるベースカードと、それに対応する複数の参照カードのすべてをユーザが所持していることが要件となる。従って、例えば、その複数の参照カードのうち一部の参照カードを所持していない場合には、ベースカードの進化合成を実行することができない。このとき、ユーザが所持していない参照カードの入手が、当該ユーザにとって不可能または困難である場合がある。しかし、当該参照カードの入手条件を知らないユーザは、当該参照カードの入手が不可能または困難であることを、当該参照カードを入手するための処理(例えば、クエスト処理)を実行するか否かを決断する時点で認識できない。このような場合、ユーザは、実際には参照オジェクトの入手が不可能または困難かもしれないという不安を抱えたまま、当該参照カードを入手するための処理を実行することになる。
本実施形態のゲームサーバ20は、ユーザによる要求に応じて、ユーザが所持していない参照カードの入手条件を提示する。そのため、進化合成の対象となるベースカードに対応する複数の参照カードの中に、ユーザにとって入手が不可能または困難な参照カードがあったとしても、ユーザは、当該参照カードの入手が不可能または困難であることを認識した上で、当該参照カードを入手するための処理を実行するか否かを決断できる。その結果、当該参照カードを入手するための処理を実行するユーザに安心感を与えることができる。
【0085】
また、未所持カードの入手条件としては、入手経路および入手難易度のうち少なくとも1つが提示されることが好ましい。この場合、ユーザは、当該未所持カードを入手するための処理(例えば、クエスト処理)を実行するユーザに安心感を与えることができる。
【0086】
また、未知カードの入手条件としては、入手難易度は表示されるが、入手経路は提示されない(すなわち、未知カードの入手条件として表示される情報は、未所持カードの入手条件として表示される情報に比べて制限される)ことが好ましい。この場合、ゲームの難易度を適切なレベルに保ちながら、当該未知カードを入手するための処理(例えば、クエスト処理)を実行するユーザに安心感を与えることができる。
【0087】
(1−9)本実施形態の変形例
以下、本実施形態の変形例について説明する。なお、以下の変形例は適宜組合せ可能である。
【0088】
(1−9−1)第1の変形例
図12Aまたは
図13Aの画像P4では、それぞれ、参照カードのカード画像のみを表示する表示形式を示しているが、本実施形態の表示形式はこれに限られるものではない。
例えば、カード画像のみを表示する表示形式に代えて、カード名のみを表示する表示形式であってもよいし、カード画像とカード名との組合せを表示する表示形式であってもよい。
つまり、本実施形態の表示形式は、参照カードをユーザにそれぞれ識別可能に表示する形式であれば、どのようなものでもよい。
【0089】
(1−9−2)第2の変形例
上述の実施形態では、
図16BのS42において、S38で取得したカードデータのうち入手難易度に関する情報以外の情報が表示されないようにするために、画像に対してマスク処理を適用する例について説明したが、当該情報が表示されないようにするための処理はこれに限られない。
例えば、マスク処理を適用する代わりに、入手難易度に関する情報以外の情報を削除してもよいし、当該情報を所定の記号に置き換えてもよい。
【0090】
(1−9−3)第3の変形例
上述の実施形態では、
図16BのS42において、カード名、カード画像、レアリティ、および、入手可能エリアが表示されないようにする例について説明したが、本実施形態はこれに限られない。
例えば、カード画像と入手可能エリアを表示されないようにし、カード名とレアリティは表示するようにしてもよい。
また、表示されないようにする情報は、ユーザが任意に設定できるようにしてもよい。
【0091】
(1−9−4)第4の変形例
上述の実施形態では、
図16BのS42において、S38で取得したカードデータによって示されるカードに関する情報のうち、入手難易度に関する情報以外の情報が表示されないようにする例について説明したが、S42は省略可能である。
S42を省略した場合、S38で取得したカードデータ(つまり、入手条件が提示された参照カードに関する情報)のすべてが表示されるので、ユーザに対して、当該参照カードを入手できる可能性がある、という期待感を与えることができる。
【0092】
(1−9−5)第5の変形例
ユーザが過去に所持したことがあり、且つ、ユーザが現在所持していない参照カードである未所持カードが入手条件を提示すべきカードとして選択された場合、当該カードの入手可能エリアおよび入手難易度に関する情報の少なくとも1つを入手条件として表示することが望ましい。
これは、指定オブジェクトが、ユーザが過去に所持したことがあり、且つ、ユーザが現在所持していないオブジェクトである未所持オブジェクトである場合、入手条件として、指定オブジェクトの入手経路および入手難易度の少なくとも1つを表示する処理の一例である。
本変形例によれば、ユーザは当該カードの入手難易度を容易に知ることができる。
【0093】
(1−9−6)第6の変形例
上述の実施形態では、未所持カードの入手条件を表示する例を示したが、未所持カード以外のカードの入手条件を表示してもよい。
一例として、所持カードの入手条件を表示してもよい。例えば、所持カードが多い場合、ある所持カードの入手条件をユーザが忘れていることがある。この場合、当該所持カードの入手条件を表示することにより、ユーザは、当該所持カードの入手難易度を再認識できる。仮に、ユーザが、当該所持カードの入手難易度が高いと認識した場合、当該所持カードの用途(例えば、どのベースカードの進化合成の処理の参照カードとして用いるか)を慎重に考えさせることのきっかけを与えることができる。一方、ユーザが、当該所持カードの入手難易度が低いと認識した場合、当該所持カードを気軽に使わせることのきっかけを与えることができる。
【0094】
(1−9−7)第7の変形例
上述の実施形態では、ベースカードに対応するすべての参照カードを所持している場合に変化条件を満たす例を説明したが、当該すべての参照カードを所持していることに加えて、所定の追加条件が成立する場合に変化条件が満たされてもよい。
例えば、追加条件は、すべての参照カードのカードレベルが最大レベルに達している場合に成立してもよいし、所定量のゲーム上のポイントをユーザが所有している場合に成立してもよい。
【0095】
(2)第2の実施形態
第1の実施形態では、未所持カードの入手条件を示す画像を表示する場合について説明したが、第2の実施形態では、当該入手条件に加えて、未所持カードの入手経路にユーザを誘導するための操作対象を含む画像を表示する場合の一例について説明する。なお、第1実施形態と同様の説明については適宜省略する。
【0096】
(2−1)入手条件の提示処理およびクエスト処理の具体例
以下、本実施形態のゲームのカードの入手条件の提示処理の具体例について、
図18を参照しながら説明する。
図18は、本実施形態のゲームの処理を実行しているときのユーザ端末10に表示される画面の一例を示す図である。
【0097】
(2−1−1)入手条件の提示処理(
図18)
第1の実施形態の
図12Aの画像P4において、入手条件を表示すべき参照カード(ここでは、表示領域102に「未所持」の状態が示されたカードDSG)が選択され、且つ、ボタンb8が操作されると、
図18に示すように、ユーザによって選択された参照カードの入手条件を示す画像P5が表示される。
【0098】
図18の画像P5は、表示領域103および104に加えて、ボタンb9(「入手可能エリアへ行く」)を含む点において、第1の実施形態(
図12Bの画像P5)と異なる。ボタンb9は、ユーザが未所持カードを入手するためのクエスト処理を要求するときに操作されるボタンである。
なお、ボタンb9は、ユーザを入手経路に誘導するための操作対象の一例である。
【0099】
(2−1−2)クエスト処理(
図18)
画像P5においてボタンb9(「入手可能エリアへ行く」)が操作されると、P6に示すように画像が変化する。画像P6では、クエストの実行画面が示される。ユーザは、画像P6において所定の操作を行うことで、クエストで使用されるエリア(ここでは、エリア1)を探索することができる。クエスト条件が達成されると、ユーザは、クエストデータテーブルの「入手率」の値に応じた確率に基づいて、未所持カードを入手することができる。
【0100】
(2−2)本実施形態のゲームの処理フロー
次に、本実施形態のゲームの処理フローの一例について、
図19のシーケンスチャートを参照して説明する。
図19は、クエスト処理を示すシーケンスチャートである。なお、
図19において、
図18に示した各画像P5〜P6が表示されるステップに各画像の符号を付してある。
【0101】
(2−2−1)入手条件の提示処理
本実施形態では、S44(
図16A)で、ゲームサーバ20のCPU21が、S38で取得した参照カードのカードデータに加えて、当該参照カードの入手経路(ここでは、入手可能エリア)へユーザを誘導するための操作対象を提示するための画像データ(
図18の画像P5の元になる画像データ)を生成する点において、第1実施形態と異なる。
【0102】
(2−2−2)クエスト処理(
図19)
図19において、ユーザ端末10に表示された画像上で所定のボタン(例えば、
図18の画像P5のボタンb9)が操作されると、ユーザ端末10のCPU11は、クエスト処理の要求を受け付け(S70)、当該要求をゲームサーバ20へ送信する(S72)。
【0103】
ゲームサーバ20のCPU21は、S72で送信された要求を受け付けると、クエストデータテーブルから、S38で取得したクエストIDに対応付けられたクエストデータ(エリア名、消費体力、入手カードデータ(カードIDおよび入手率)、入手アイテムデータ(アイテムIDおよび入手率)、ボスID、および、クエストUIデータ)に基づいて、クエスト処理の画像データ(
図18の画像P6の元になる画像データ)を生成し(S74)、当該画像データをユーザ端末10へ送信する(S76)。
【0104】
ユーザ端末10のCPU11は、S76で送信された画像データを受け付けると、当該画像データに基づく画像(例えば、
図18の画像P6)を表示部16に表示する(S78)。
【0105】
その後、ユーザ端末10のCPU11は、ユーザの操作に応じた指示をゲームサーバ20へ送信する。ゲームサーバ20のCPU21は、送信された指示に基づいて、クエストを進行させる。クエストが所定レベルまで進行すると、CPU21は、ボスIDに対応付けられたボスキャラクタとユーザとの対戦を実行する。ユーザが当該対戦において勝利条件を満たすと、CPU21は、クエストIDに対応付けられた「入手率」の値に応じてカードを付与する処理を実行する。カードを付与する処理では、CPU21は、クエストIDに対応付けられたカードIDを所持カードデータテーブルに書き込むとともに、所持履歴データテーブルにおいて当該カードIDに対応付けられた「入手回数」の値を増加させる。これにより、ユーザは、第1の実施形態の
図12Aの画像P4において選択したカード(入手条件を表示すべき参照カード)を入手することができる。
【0106】
以上説明したように、本実施形態のゲームサーバ20は、ユーザが所持していない参照カードの入手条件と共に、当該参照カードの入手経路へユーザを誘導するための操作対象を提示することで、ユーザは、上記操作対象を操作するだけでオブジェクトを入手するための処理の実行を要求できるため、当該処理の実行を要求するときの操作性を向上させることができる。
【0107】
(3)第3の実施形態
第2の実施形態では、未所持カードの入手経路にユーザを誘導するための操作対象を含む画像を表示する場合について説明したが、第3の実施形態では、未所持カードの入手経路にユーザを誘導するための操作対象に加えて、未所持カードの入手経路にユーザを誘導し、且つ、当該ユーザが当該未所持カードを入手した後に進化合成の予約処理を実行するための操作対象も含む画像を表示する場合の一例について説明する。なお、上述の実施形態と同様の説明については適宜省略する。
【0108】
(3−1)入手条件の提示処理、クエスト処理、および、進化合成の予約処理の具体例
以下、本実施形態のゲームのカードの入手条件の提示処理、クエスト処理、および、進化合成の予約処理の具体例について、
図20を参照しながら説明する。
図20は、本実施形態のゲームの処理を実行しているときのユーザ端末10に表示される画面の一例を示す図である。
【0109】
(3−1−1)入手条件の提示処理(
図20)
第1の実施形態の
図12Aの画像P4において、入手条件を表示すべき参照カード(ここでは、表示領域102に「未所持」の状態が示されたカードDSG)が選択され、且つ、ボタンb8が操作されると、
図20に示すように、ユーザによって選択された参照カードの入手条件を示す画像P5が表示される。
図20の画像P5は、表示領域103および104に加えて、ボタンb10(「予約しない/入手可能エリアへ行く」)と、ボタンb11(「予約する/入手可能エリアへ行く」)と、を含む点において、第1の実施形態(
図12Bの画像P5)と異なる。ボタンb10は、ユーザが未所持カードを入手するためのクエスト処理を要求するときに操作されるボタンである。ボタンb11は、当該クエスト処理および進化合成の予約処理の両方を要求するときに操作されるボタンである。
【0110】
(3−1−2)クエスト処理(
図20)
画像P5においてボタンb10(「予約しない/入手可能エリアへ行く」)が操作されると、P6に示すように画像が変化する。画像P6は、第2実施形態(
図18の画像P6)と同様である。
【0111】
(3−1−3)進化合成の予約処理(
図20)
画像P5においてボタンb11(「予約する/入手可能エリアへ行く」)が操作されると、クエスト処理とともに、ユーザが所持している参照カードについて予約処理が実行され、予約処理が完了したことを示す画像P7が表示される。
【0112】
(3−2)本実施形態のゲームの処理フロー(
図21)
次に、本実施形態のゲームの処理フローの一例について、
図21のシーケンスチャートを参照して説明する。なお、本実施形態の入手条件の提示処理およびクエスト処理は、第2の実施形態と同様に実行される。
図21は、進化合成の予約処理を示すシーケンスチャートである。なお、
図21において、
図20に示した各画像P5〜P7が表示されるステップに各画像の符号を付してある。
【0113】
以下で説明する予約処理では、一例として、ユーザが、ベースカードを進化合成させるための複数の参照カードのうち、ベースカードの進化合成のために未所持の参照カードを予約する場合を想定する。
【0114】
図21において、ユーザ端末10に表示された画像上で所定のボタン(例えば、
図20の画像P5のボタンb11)をユーザが操作することによって、ユーザ端末10のCPU11は、進化合成の予約処理の要求を受け付け(S50)、当該要求をゲームサーバ20へ送信する(S52)。当該要求には、
図20の表示領域103に表示された未所持の参照カードを特定するカードIDが含まれる。
なお、S52は、ユーザによる操作に基づいて、指定オブジェクトに対して、選択オブジェクトを変化させる処理以外の処理に用いられることを制限させるための要求を受け付ける処理の一例である。
【0115】
ゲームサーバ20のCPU21は、進化合成の予約処理の要求を受け付けると、予約データテーブルにアクセスし、S24(
図16A)で取得したベースカードのシリアル番号に対応する予約IDが発行済みであるか(つまり、「進化前カード」の欄に同一のシリアル番号が記録されているか)否か判定する(S54)。
予約IDが発行済みである場合には(S54:YES)、S58へ進み、予約IDが発行済みでない場合には(S54:NO)、予約IDを発行した後に(S56)、S58へ進む。S58では、CPU21は、予約データテーブルに、当該予約IDに対応付けて仮のシリアル番号を書き込む。このとき、CPU21は、予約IDを新たに発行した場合には、予約対象カードのうちベースカードのシリアル番号を「進化前カード」の欄に書き込み、かつ、その予約IDに対応するC1〜C5の欄のうち、予約対象カードではないカードのカードIDに対応する欄に、予約対象カードではないことを示すデータ(例えば、NULL)を書き込む。
【0116】
次に、ゲームサーバ20のCPU21は、所持カードデータテーブルにおいて、予約対象カードのカードIDに対応する「予約ID」の欄に、S58の書き込み対象とした予約IDを書き込む(S60)。
なお、S60は、指定オブジェクトに対して、選択オブジェクトを変化させる処理以外の処理に用いられることを制限する処理の一例である。
【0117】
次に、CPU21は、予約が完了したことを示す画像データを生成し(S62)、当該画像データをユーザ端末10へ送信する(S64)。ユーザ端末10のCPU11は、S66で送信された画像データを取得すると、当該画像データに基づいて画像(例えば、
図20の画像P7)を表示部16に表示する(S66)。
【0118】
その後、予約対象カードをユーザが入手すると(つまり、当該ユーザの所持カードデータに予約対象カードのカードIDおよびシリアル番号が対応付けて記録されると)、CPU21は、S58で予約データテーブルに書き込んだ仮のシリアル番号を、所持カードデータに含まれるシリアル番号に書き換える。
【0119】
なお、
図21において、ユーザ端末10に表示された画像上で所定のボタン(例えば、
図20の画像P5のボタンb10)が操作されると、第2実施形態と同様のクエスト処理(
図19)が行われる。
【0120】
以上説明したように、本実施形態のゲームサーバ20は、ユーザが所持していない参照カードの入手条件と共に、当該参照カードの入手経路へユーザを誘導し、且つ、当該参照カードを予約する処理を要求するための操作対象を提示することで、予約済カードが目的とする進化合成以外の処理に用いられることを制限可能にする。そのため、ユーザの所持していない残りの参照カードを入手するまでの待機期間において、ユーザが所持しているカードを誤って目的とする進化合成以外の別の処理に使用してしまうことを防止できる。
【0121】
(4)第4の実施形態
上述の実施形態では、参照カードの入手条件の提示を要求するためのボタンをユーザが操作したときに当該入手条件を示す画像を表示する場合について説明したが、第4の実施形態では、選択したカードを進化合成のベースカードとして確定させるためのボタンをユーザが操作したときに当該ベースカードの進化合成の変化条件を満たすための参照カードの入手条件を示す画像を表示する場合の一例について説明する。なお、上述の実施形態と同様の説明については適宜省略する。
【0122】
(4−1)入手条件の提示処理の具体例
以下、本実施形態のゲームのカードの入手条件の提示処理の具体例について、
図22を参照しながら説明する。
図22は、本実施形態のゲームの処理を実行しているときのユーザ端末10に表示される画面の一例を示す図である。
【0123】
・入手条件の提示処理(
図22)
図22は、未所持カードの入手条件を提示するための入手条件の提示処理の一連の表示画面の変化を示している。
図22の画像P1〜P3は、それぞれ第1の実施形態の
図12Aの画像P1〜P3と同様である。
【0124】
画像P3においてボタンb6が操作されると、ベースカードとして選択されたカードKLMが進化するために必要な参照カードの条件を満たしていない場合には、P4に示すように画像が更新される。画像P4は、ベースカードとして選択されたカードKLMが進化するために必要な参照カードのうちユーザが所持していないカードの入手条件を提示するための画像である。なお、画像P3においてユーザがボタンb6を選択した時点で、ベースカードとして選択されたカードKLMが進化するために必要な参照カードの条件を満たしている場合には、カードKLMの進化合成を実行するか否かをユーザが指示するための画像(図示せず)が表示される。
【0125】
図22の画像P4は、表示領域102において、進化合成に必要な参照カードおよびその状態(所持、未所持、予約済、未知のいずれか)に加えて、未所持カードまたは未知カードの入手条件が示される点が、第1〜第3の実施形態(
図12A、
図13A、および、
図21Aの画像P4)と異なる。表示領域102には、一例として、未所持カードの入手経路を示す情報(ここでは、エリア名「エリア1」)が示されている。
【0126】
(4−2)本実施形態のゲームの処理フロー(
図23)
次に、本実施形態のゲームの処理フローの一例について、
図23のシーケンスチャートを参照して説明する。
図23は、入手条件の提示処理を示すシーケンスチャートである。
なお、
図23において、
図22に示した各画像P1〜P4が表示されるステップに各画像の符号を付してある。また、
図23において、
図16Aおよび
図16Bと同一の処理については、同一の符合を付してある。
【0127】
以下で説明する入手条件の提示処理では、一例として、ユーザが、ベースカードと、当該ベースカードを進化合成させるための複数の参照カードの一部とを所持している場合に、未所持の参照カードの入手条件の提示を要求する場合を想定する。
【0128】
第1の実施形態のS26(
図16A)が実行された後、ゲームサーバ20のCPU21は、S26で読み出した複数の参照カードIDに基づいて、カードデータテーブル、クエストデータテーブル、および、カード流通データテーブルから、参照カードのカードデータ(カード名、カード画像、レアリティ、クエストID、入手可能エリアのエリア名、入手回数、流通数、および、平均取引価格)を取得する(S38)。カード名、カード画像、および、レアリティはカードデータテーブルから取得される。クエストIDおよび入手可能エリアのエリア名は、クエストデータテーブルから取得される。入手回数は、所持履歴テーブルから取得される。流通数および平均取引価格は、カード流通データテーブルから取得される。
【0129】
次いで、ゲームサーバ20のCPU21は、S40〜S42を、それぞれ、第1の実施形態のS40〜S42(
図16B)と同様に実行した後、S38で取得した参照カードのカードデータに基づいて、当該参照カードの入手条件をユーザに提示するための画像データ(
図22の画像P4の元になる画像データ)を生成し(S44)、当該画像データをユーザ端末10へ送信する(S46)。
【0130】
ユーザ端末10のCPU11は、S46で送信された画像データを受け付けると、当該画像データに基づいて画像(例えば、
図22の画像P4)を表示部16に表示する(S48)。
【0131】
以上説明したように、本実施形態のゲームサーバ20は、ユーザが所持しておらず、かつ、目的とする進化合成に必要な参照カードの入手条件を、進化合成の対象となるベースカードを選択するユーザの操作に応じて提示することで、ベースカードの進化合成に必要な参照カードの入手条件を提示させる操作の操作性を向上させることができる。
【0132】
(5)第5の実施形態
上述の実施形態では、未所持カードの入手条件を提示する画面を表示する例について説明したが、本実施形態では、所持カードの入手条件を提示する画面を表示し、かつ、当該画面において、ユーザが指定したカードが何らかの処理に用いられることで消失することを防ぐための処理の例について説明する。
【0133】
(5−1)本実施形態のゲームのカードの予約登録およびお気に入り登録(
図24)
本実施形態のゲームにおいて、ユーザが所望のベースカードを進化合成によって進化させたいが当該ベースカードを進化させるのに必要な参照カードの一部、あるいはすべてをユーザが所持していない場合を考える。この場合、参照カードの組合せの条件を満たすための新しいカード(つまり、残りの参照カード)をユーザが入手できるまで当該ベースカードの進化合成を実行することを待機する必要がある。しかし、ユーザが、残りの参照カードを入手する前に所持している参照カードを当該ベースカードの進化とは別の用途で使用することで消失させてしまい、かつ、当該参照カードの入手条件を満たすことが困難である場合、当該ベースカードを進化させることが難しくなる。例えば、進化合成を実行する前にユーザが操作を誤って参照カードを消失(一例として、売却)してしまったケースにおいて、当該参照カードを入手できる確率が低い場合、または、当該参照カードを入手できる期間が限られている場合、ユーザは所望のベースカードを進化させることが難しくなる。
そこで、本実施形態では、所望のベースカードを進化させるのに必要となる参照カードを、ユーザの意図に反して消失させてしまうことを確実に防げるようにする。
【0134】
参照カードの予約登録およびお気に入り登録について、
図24を参照して具体的に説明する。
図24は、参照カードの予約登録およびお気に入り登録を概念的に説明するための図である。
図24において、ユーザが自身の所持カードであるカードQを進化させたい場合を考える。ここでは、カードQを進化させるために、複数の参照カードとしてカードA,B,Cの組合せが必要となる場合を想定する。ユーザは現時点でカードBを所持していないため、カードQに対する進化合成を実行することはできない。また、カードAの入手条件を満たすことが困難である場合、ユーザが、カードAをカードQの進化以外の用途で使用することによって所持カードから消失させてしまうと、カードQを進化させることが難しくなる。そのため、本実施形態では、ユーザがカードAを意図せずに所持カードから消失させてしまうことを防ぐために、カードAの入手条件の提示をした上で、カードAに対して、予約登録またはお気に入り登録を受け付ける。
予約登録とは、カードAを、所持カードから消失させることを条件として実行される処理のうち、ベースカードとして選択されたカードQの進化合成以外の処理に用いることを制限する状態にすることである。
お気に入り登録とは、カードAを、所持カードから消失させることを条件として実行される処理(ベースカードとして選択されたカードQの進化合成も含む)に用いることを制限する状態にすることである。
なお、予約登録及びお気に入り登録は、ユーザによって指定されたオブジェクトである指定オブジェクトに対して、所定の処理に用いられることを制限させる処理の一例である。「所定の処理」とは、指定オブジェクトを所持オブジェクトから消失させることを条件として実行される処理である。つまり、ユーザが所持しているオブジェクトである所持オブジェクトの中から指定されたオブジェクトが、予約登録及びお気に入り登録による制限の対象となるオブジェクトになる。
【0135】
このように、カードAの入手条件を提示した上で、カードAに対する予約登録またはお気に入り登録を受け付けることにより、ユーザは、提示された入手条件からカードAが入手困難なカードであると認識した直後に、カードAが所持カードから消失させる処理に用いられることを制限するための要求を行うことができるようになる。したがって、カードAの意図に反する消失を確実に防ぐことができる。
【0136】
(5−2)データテーブルの構成
次に、ゲームサーバ20のストレージ25に格納される所持カードデータテーブルについて、
図25を参照して順に説明する。
【0137】
所持カードデータテーブルは、ユーザの所持カードの情報が記録されている。
図25に所持カードデータテーブルの構成例を示す。
図25では1ユーザの分の所持カードデータテーブルを例示するが、所持カードデータテーブルは、ゲームに登録しているすべてのユーザに対応して設けられる。
図25の所持カードデータテーブルは、カードIDごとに登録種別のデータが対応付けられて記録されている点において、
図8の所持カードデータテーブルと異なる。
登録情報は、所持カードデータに対して行われた登録の種別(予約登録またはお気に入り登録)と、当該登録の要求が行われた画面の種別(入手条件を提示する画面(以下「入手条件提示画面」という)またはベースカード毎の進化合成に必要な参照カード一覧画面」という))との組合せを示すデータである。
図25の例では、入手条件提示画面を経由して予約登録が行われたカードについては登録情報に「1」が記録され、入手条件提示画面を経由してお気に入り登録が行われたカードについては登録情報に「2」が記録され、覧画面を経由してお気に入り登録が行われたカードについては登録情報に「4」が記録され、予約登録およびお気に入り登録のいずれも行われていないカードには「N/A」が記録される。
【0138】
(5−3)本実施形態のゲームの表示処理の具体例
(5−3−1)本実施形態のゲームの入手条件提示画面の表示処理の具体例(
図26)
第1の実施形態の
図12Aの画像P4において、入手条件を表示すべき参照カードが選択され、且つ、ボタンb8が操作されると、
図26に示すように、ユーザによって選択された参照カードの入手条件提示画面に相当する画像P5が表示される。
【0139】
図26の画像P5は、ボタンb12(「予約登録」)およびボタンb13(「お気に入り登録」)を含む点において、第1の実施形態(
図12Bの画像P5)と異なる。
ボタンb12(「予約登録」)は、ユーザが所持カードの予約登録を要求するときに操作されるボタンである。
ボタンb13(「お気に入り登録」)は、ユーザが所持カードのお気に入り登録を要求するときに操作されるボタンである。
【0140】
画像P5においてボタンb12(「予約登録」)が操作されると、P21に示すように画像が変化する。画像P21では、予約登録の処理の実行結果が示される。
画像P5においてボタンb13(「お気に入り登録」)が操作されると、P22に示す
ように画像が変化する。画像P22では、お気に入り登録の処理の実行結果が示される。
【0141】
(5−3−2)本実施形態のゲームの変化条件一覧画面の表示処理の具体例(
図27A〜
図27C)
第1の実施形態の
図12Aの画像P1において、ボタンb4(「進化合成」)が操作されると、
図27Aに示すように、本実施形態の変化条件一覧画面に相当する画像P23aが表示される。画像P23aは、変化条件一覧画面ともいう。
【0142】
画像P23aは、表示領域105と、ボタンb12(「予約登録」)と、ボタンb13(「お気に入り登録」)とを含む。ボタンb12(「予約登録」)およびボタンb13(「お気に入り登録」)は、
図26の画像P5と同様である。
表示領域105には、ベースカードおよび参照カードのカード画像およびカード名が、ベースカードと参照カードの組合せ毎に表示される。換言すると、表示領域105には、ベースカード毎の参照カードが表示される。
図27Aの例では、カードKLMの進化合成に必要な参照カードがカードVIC、DSG、および、MITであり、カードSAMの進化合成に必要な参照カードがカードMIT、KAY、および、TEDである。
表示領域105では、参照カードについて、所持カードと未所持カードが識別可能に表示される。
図27Aの例では、カードVIC、DSG、MIT、および、KAYが所持カードであることを示す実線で表示され、かつ、カードTEDが未所持カードであることを示す破線で表示される。
また、表示領域105には、入手条件提示画面を経由して行われた予約登録の対象となったカードのカード画像上にマークm1が表示される。マークm1は、所持カードから消失させることを条件として実行される処理のうち、ベースカードの進化合成以外の処理に用いることが制限された状態にあるカードのカード画像上に表示されるマーク(「記号」、「印」などともいう。)である。
図27Aの例では、カードKLMのカード画像上、および、カードDSGのカード画像上にマークm1が表示されている。つまり、
図27Aは、カードDSGが、カードDSGを所持カードから消失させることを条件に実行される処理のうち、カードKLMの進化合成以外の処理に用いることが制限された状態にあることを示している。
また、表示領域105には、覧画面を経由して行われたお気に入り登録の対象となったカードのカード画像上にマークm2が表示される。マークm2は、所持カードから消失させることを条件として実行される処理(ベースカードの進化合成も含む)に用いることが制限された状態にあるカードのカード画像上に表示されるマークである。
図27Aの例では、カードKAYのカード画像上にマークm2が表示されている。つまり、
図27Aは、カードKAYが、カードKAYを所持カードから消失させることを条件に実行される処理の全て(例えば、カードSAMの進化合成の処理、および、カードKAYの売却処理)に用いることが制限された状態にあることを示している。
ユーザは、カード画像を選択することにより、当該カード画像に対応するカードを選択状態にするができる。
図27Aの例では、カード画像b14が選択された場合、カードKLMの進化合成に必要な参照カードとしてのカードMITが選択状態になり、カード画像b15が選択された場合、カードSAMの進化合成に必要な参照カードとしてのカードMITが選択状態になる。
ユーザは、カードを選択状態にした上でボタンb12(「予約登録」)またはボタンb13(「お気に入り登録」)を操作すると、選択状態にあるカードに対する予約登録またはお気に入り登録を要求できる。
図27Aの例では、カード画像b14を選択した上でボタンb12(「予約登録」)またはボタンb13(「お気に入り登録」)を操作すると、カードKLMの進化合成に必要な参照カードとしてのカードMITに対する予約登録また
はお気に入り登録が要求される。
【0143】
画像P23aにおいて、ユーザがカード画像b14を選択した上でボタンb12(「予約登録」)を操作すると、画像P23bに変化する。画像P23bは、マークm3が、カードKLMの進化合成に必要な参照カードとしてのカードMITのカード画像上に表示されている点において、画像P23aと異なる。マークm3は、変化条件一覧画面を経由して行われた予約登録の対象となった参照カードを示すマークである。
カードSAMの進化合成に必要な参照カードとしてのカードMITのカード画像上には、マークm4が表示される。マークm4は、他のベースカード(カードKLM)の進化合成に必要な参照カードとして予約登録が行われたことを示すマークである。
図27Bの例では、カードKLMの進化合成に必要な参照カードとしてのカードMITのカード画像上に、マークm3が表示され、かつ、カードSAMの進化合成に必要な参照カードとしてのカードMITのカード画像上に、マークm4が表示されている。この場合、カードMITに対して、カードMITを所持カードから消失させることを条件に実行される処理のうち、カードKLMの進化合成以外の処理に用いることが制限される。つまり、カードMITは、カードKLMの進化合成の処理に用いることはできるが、カードSAMの進化合成の処理や売却処理に用いることはできなくなる。
【0144】
画像P23aにおいて、ユーザがカード画像b14を選択した上でボタンb13(「お気に入り登録」)を操作すると、画像P23cに変化する。画像P23cは、マークm5がカードMITのカード画像上に表示されている点において、画像P23aと異なる。マークm5は、変化条件一覧画面を経由して行われたお気に入り登録の対象となった参照カードを示すマークである。
図27Bの例では、カードKLMの進化合成に必要な参照カードとしてのカードMITのカード画像、および、カードSAMの進化合成に必要な参照カードとしてのカードMITのカード画像上に、マークm5が表示されている。この場合、カードMITに対して、カードMITを所持カードから消失させることを条件に実行される処理の全てに用いることが制限される。つまり、カードMITは、カードKLMの進化合成の処理、カードSAMの進化合成の処理、および、売却処理のいずれにも用いることはできなくなる。
【0145】
画像P23a〜P23cにおいて、マークm1〜m5は、互いに識別可能な形状、パターン、または、それらの組合せにより表示される。これにより、ユーザは、入手条件提示画面を経由して行われた予約登録の対象となった参照カード、入手条件提示画面を経由して行われたお気に入り登録の対象となった参照カード、変化条件一覧画面を経由して行われた予約登録の対象となった参照カード、および、変化条件一覧画面を経由して行われたお気に入り登録の対象となった参照カードを容易に識別できるようになる。
具体的には、マークm1〜m5については、登録の種類(予約登録またはお気に入り登録)がマークの形状により識別され、かつ、登録の要求が行われた画面(入手条件提示画面、または、変化条件一覧画面)がマークのパターンにより識別される。
【0146】
(5−4)本実施形態の登録の処理の処理フロー(
図28)
次に、本実施形態のゲームの処理フローの一例について、
図28のシーケンスチャートを参照して説明する。
図28は、登録の処理を示すシーケンスチャートである。
なお、
図28において、
図26に示した各画像P5、P21、および、P22が表示されるステップに各画像の符号を付してある。また、
図28において、
図16Bと同一の処理については、同一の符合を付してある。
【0147】
以下で説明する登録の処理では、ユーザにより指定されたオブジェクトである指定オブジェクトに対して、所定の処理に用いられることを制限するための処理の一例として、予約登録の処理またはお気に入り登録の処理を要求する場合を想定する。
【0148】
第1の実施形態のS48(
図16B)が実行された後、ゲームサーバ20のCPU21は、
図26の画像P5上に表示されたボタンb12(「予約登録」)またはボタンb13(「お気に入り登録」)に対するユーザの操作に基づいて、予約登録の処理の要求またはお気に入り登録の処理の要求を受け付け(S170)、当該要求をゲームサーバ20に送信する(S171)。
なお、
図26の画像P5は、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトの入手条件を表示させるための出力データの一例である。
予約登録の処理の要求には、ユーザIDと、ベースカードのシリアル番号と、参照カードのシリアル番号と、予約登録の処理の要求が行われたときに表示されていた画像の種類(例えば、
図26の画像P5または
図27Aの画像P23a)を特定する情報(つまり、予約登録の処理の要求を行うために経由した画面の種類を特定する情報)と、予約登録の処理の要求であることを特定する情報とが含まれる。
お気に入り登録の処理の要求には、ユーザIDと、参照カードのシリアル番号と、お気に入り登録の処理の要求が行われたときに表示されていた画像の種類(例えば、
図26の画像P5または
図27Aの画像P23a)を特定する情報(つまり、お気に入り登録の処理の要求を行うために経由した画面の種類を特定する情報)と、お気に入り登録の処理の要求であることを特定する情報とが含まれる。
予約登録の処理の要求およびお気に入り登録の処理の要求は、ユーザにより指定されたオブジェクトである指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求の一例である。
【0149】
ゲームサーバ20のCPU21は、ユーザ端末10から要求を受け付けると、当該要求に応じた登録(予約登録、または、お気に入り登録)の処理を実行する(S172)。
なお、S172の処理は、指定オブジェクトに対して、所定の処理に用いられることを制限する処理の一例である。
【0150】
S170で受け付けられた要求が予約登録の処理の要求である場合、CPU21は、当該要求に含まれる参照カードのシリアル番号によって特定される所持カードデータに対して、入手条件提示画面を経由して行われた予約登録の対象となるカードであることを示す登録情報(
図25の登録情報「1」)を記録する。また、CPU21は、当該要求に含まれるベースカードのシリアル番号によって特定される予約データに対して、C1〜C5のうち当該参照カードのカードIDに対応する欄に、当該参照カードのシリアル番号を記録する。これにより、予約登録の対象となる参照カードのシリアル番号について、当該予約登録の対象となるベースカードのシリアル番号以外のシリアル番号によって特定される予約データに記録する(つまり、当該参照カードを、当該ベースカード以外のベースカードの進化合成のために予約する)こと、および、所持カードデータから削除すること(つまり、当該参照カードを所持カードから消失させる(例えば、売却処理を実行する)こと)が制限される。
一方、S170で受け付けられた要求がお気に入り登録の処理の要求である場合、CPU21は、当該要求に含まれる参照カードのシリアル番号によって特定される所持カードデータに対して、入手条件提示画面を経由して行われたお気に入り登録の対象となるカードであることを示す登録情報(
図25の登録情報「2」)を記録する。これにより、お気に入り登録の対象となる参照カードのシリアル番号について、予約データテーブルに対してシリアル番号を記録すること、および、所持カードデータから削除すること(つまり、当該参照カードを所持カードから消失させること)が制限される。
【0151】
次いで、CPU21は、登録の処理の実行結果をユーザ端末10に送信する(S173)。
【0152】
ユーザ端末10のCPU11は、ゲームサーバ20から登録の処理の実行結果を受け付けると、当該実行結果に基づく画面を表示する(S174)。これにより、ユーザ端末10の表示部16に、
図26の画像P21またはP22が表示される。
なお、S174は、予約登録による制限の対象となっているオブジェクトと、お気に入り登録による制限の対象となっているオブジェクトとを、ユーザにそれぞれ識別可能な表示形式で表示させるためのデータを出力する処理の一例である。
【0153】
図25の登録情報を用いることで、
図27A〜
図27Cに示すように、マークm1〜m5を用いて、登録の種類と、登録の要求が行われたときに表示されていた画面の種類とを、ユーザが識別できるように表示することができる。例えば、ユーザが、
図12Aの画像P1のボタンb4(「進化合成」)を操作すると、表示部16には、S172において予約登録の処理が実行された場合、
図27Bの画像P23bが表示され、S172においてお気に入り登録の処理が実行された場合、
図27Cの画像P23cが表示される。
【0154】
以上説明したように、本実施形態のゲームサーバ20は、入手条件提示画面において、所持している参照カードに対して、ベースカードの進化合成以外の処理に用いられることを制限するための予約登録の処理の要求、または、所持カードから消失させることを条件として実行される処理(ベースカードの進化合成の処理を含む)に用いられることを制限するためのお気に入り登録の処理の要求を受け付ける。
これにより、ユーザは、入手条件提示画面において、所持している参照カードの入手が困難であることを認識した直後に、当該参照カードが意図に反して消失しない状態にすることができるようになる。
特に、ベースカードとなるカードおよび当該ベースカードの進化合成に用いられる参照カードの所持数が多くなるほど、ユーザにとって、どの参照カードをどのベースカードの進化合成に使うべきかを管理することが困難になる。その結果、ユーザが、操作ミスや参照カードの用途の忘却により、ユーザの意図に反して参照カードを消失させてしまう虞が生じる。
これに対して、本実施形態では、ユーザが入手条件提示画面から入手が困難な参照カードであることを認識した直後に、当該参照カードに対して、当該参照カードを消失させることを条件として実行される処理に用いられることを制限するための要求を行うことができる。したがって、ユーザの意図に反する当該参照カードの消失を確実に防ぐことができる。
【0155】
また、本実施形態では、ユーザは、2種類の登録(予約登録およびお気に入り登録)の要求を行うことができる。したがって、ユーザは、目的に応じて登録を使い分ける(つまり、参照カードに対してかける制限の範囲を選択する)ことができる。例えば、参照カードを、特定のベースカードの進化合成で使用したいユーザは、予約登録の要求を行うことにより、特定のベースカードの進化合成以外の処理を実行することによる参照カードの消失を防ぐことができる。また、参照カードを用いて進化させるベースカードを決めずに、当該参照カードが消失することを防ぎたいユーザは、お気に入り登録の要求を行うことにより、当該参照カードの消失を確実に防ぐことができる。したがって、ユーザは、参照カードの用途を、柔軟に管理できるようになる。
【0156】
また、本実施形態のゲームサーバ20は、変化条件一覧画面において、変化条件一覧画面を経由して行われた予約登録の対象となった参照カードと、入手条件提示画面を経由して行われたお気に入り登録の対象となった参照カードとを、識別可能に表示する。
さらに、本実施形態のゲームサーバ20は、予約登録の対象となったベースカードおよび参照カードの組合せを識別可能に表示する。
さらに、本実施形態のゲームサーバ20は、予約登録の対象となった参照カードと、お気に入り登録の対象となった参照カードとを識別可能に表示する。
これにより、ユーザは、所持カードの用途(具体的には、特定のベースカードの進化合成に使用すること、または、用途は未定であるものの保持しておくこと)を視覚的に把握できるようになる。
【0157】
(5−5)本実施形態の変形例
以下、本実施形態の変形例について説明する。なお、以下の変形例は、適宜組合せ可能である。
(5−5−1)第1の変形例
本実施形態では、登録(予約登録、または、お気に入り登録)の対象となる参照カードが所持カードである場合について説明した。しかし、本実施形態は、登録の対象となる参照カードは、未所持カードであってもよい。
例えば、変化条件一覧画面を、予約登録の要求、または、お気に入り登録の要求を受付可能に構成する。変化条件一覧画面を経由して当該要求が受け付けられた場合、当該要求の対象となるカードをユーザが入手した(つまり、当該カードのカードIDおよびシリアル番号が所持カードデータテーブルに記録された)後に、当該カードについて、予約登録の処理、または、お気に入り登録の処理を実行する。
【0158】
(5−5−2)第2の変形例
本実施形態では、変化条件一覧画面にマークm1〜m5を表示する例を説明したが、変化条件一覧画面以外の画面にマークm1〜m5を表示してもよい。
【0159】
一例として、入手条件提示画面(例えば、予約登録の処理の実行結果が示される画像P21、または、お気に入り登録の処理の実行結果が示される画像P22)にマークm1〜m5を表示してもよい。
【0160】
別の例として、所持カードの一覧を示す画面(以下「所持カード一覧画面」という)にマークm1〜m5を表示してもよい。
具体的には、画像P1においてボタンb1(「所持モンスターを見る」)が操作されると、所持カード一覧画面が表示される。所持カード一覧画面には、
図27A〜
図27Cの変化条件一覧画面のように、所持カードに関する情報(例えば、カード画像およびカード名)が一覧表示される。所持カードのうち、予約登録またはお気に入り登録の対象となったカードのカード画像には、マークm1〜m5のいずれかが表示される。
【0161】
(5−5−3)第3の変形例
本実施形態では、選択状態にあるカードに対する予約登録またはお気に入り登録の要求を受け付ける例について説明したが、当該カードに対する登録の解除の要求を受け付けてもよい。
【0162】
例えば、
図27A〜
図27Cのマークm1〜m5のいずれかが表示されているカード画像がユーザによって選択された場合、選択されたカード画像に対応するカード(つまり、予約登録またはお気に入り登録された状態にあるカード)に対する予約登録またはお気に入り登録の解除の要求を受け付ける。具体的には、
図27Aにおいて、マークm1が表示されているカード画像が選択された場合、予約登録がなされたカードDSGが選択状態になり、かつ、登録の解除の要求を行うときに指定されるボタンが表示される。このとき、ユーザによって当該ボタンが操作されると、カードDSGに対してなされた予約登録が解除され、カード画像に表示されていたマークm1が消える。これにより、当該カードDSGは、何らの登録もなされていない状態(つまり、全ての処理に用いることができる状態)になる。
【0163】
本変形例によれば、用途が決まっていないときに行ったお気に入り登録の対象となる参照カードに対して、当該お気に入り登録を解除し、かつ、予約登録を行うことができる。また、特定のベースカードに対する進化合成に用いるという用途が決まっているときに行った予約登録の対象となる参照カードに対して、当該予約登録を解除し、かつ、お気に入り登録を行うことができる。したがって、ユーザは、参照カードの用途と当該参照カードにかける制限の範囲を、柔軟に管理できるようになる。
【0164】
(5−5−4)第4の変形例
本実施形態では、
図26、および、
図27A〜
図27Cに示すように、ボタンb12(「予約登録」)と、ボタンb13(「お気に入り登録」)とを並べて表示する例について説明したが、これらの2つのボタンについては、何れか一方のみを表示してもよい。
【0165】
(5−5−5)第5の変形例
本実施形態では、
図26の画像P5に示すような入手条件提示画面を経由して予約登録またはお気に入り登録の処理の要求が行われる例について説明したが、
図27の画像P23aに示すような変化条件一覧画面を経由して当該要求が行われてもよい。以下、変化条件一覧画面を経由して当該要求が行われる場合の登録の処理の例を、
図28を参照して説明する。
【0166】
具体的には、画像P23aのカード画像b14が選択された状態でボタンb12(「予約登録」)またはボタンb13(「お気に入り登録」)に対するユーザの操作が行われると、ユーザ端末10のCPU11は、当該操作に基づいて、予約登録の処理の要求またはお気に入り登録の処理の要求を受け付け(S170)、当該要求をゲームサーバ20に送信する(S171)。
【0167】
ゲームサーバ20のCPU21は、ユーザ端末10から要求を受け付けると、当該要求に応じた登録(予約登録、または、お気に入り登録)の処理を実行し(S172)、登録の処理の実行結果をユーザ端末10に送信する(S173)。
【0168】
ユーザ端末10のCPU11は、ゲームサーバ20から登録の処理の実行結果を受け付けると、当該実行結果に基づく画面を表示する(S174)。これにより、ユーザ端末10の表示部16に、
図27Bの画像P23bまたは
図27Cの画像P23cが表示される。
【0169】
以上の通り、本変形例における登録の処理は、4種類の登録(入手条件提示画面を経由して行われた予約登録、入手条件提示画面を経由して行われたお気に入り登録、変化条件一覧画面を経由して行われた予約登録、および、変化条件一覧画面を経由して行われたお気に入り登録)の処理を含む。各画面には、当該4種類の登録をユーザが識別できるような表示形式で、カードに関する情報が表示される。
【0170】
(6)第6の実施形態
上述の実施形態では、ユーザ端末10とゲームサーバ20との間でHTTPに従った通信が行われ、ユーザ端末10がゲームサーバ20から取得するHTML文書を解釈することでゲーム画像を表示する、いわゆるブラウザ形式によって本発明が実現される場合について説明したが、この場合に限られない。ユーザ端末10がダウンロードしたゲームプログラムを実行することでユーザ端末10が主体的にゲームの処理を実行し、ユーザ端末10とゲームサーバ20の間の送受信処理を抑制した、いわゆるネイティブアプリケーション形式によって実現してもよい。ネイティブアプリケーション形式では、ウェブブラウザを利用せずに、ユーザ端末10のCPU11が画像データを生成することで、表示部16に画像を表示する。
本実施形態では、上述の実施形態のゲームをネイティブアプリケーション形式によって実現する場合の一例について説明する。なお、本実施形態のハードウエア構成は、第1の実施形態と同じ構成でよい。本実施形態のネイティブアプリケーション形式では、処理のほとんどをユーザ端末10側で行うことを想定しているが、以下で説明しないゲームの処理の一部(例えば、ユーザに抽選によって付与する抽選処理や、ゲーム運営者がユーザにカードを付与するプレゼント処理等)については、ゲームサーバ20側で処理を実行し、ゲームサーバ20による処理結果をユーザ端末10へ送信するように構成してもよい。
【0171】
本実施形態では、ユーザ端末10がユーザによる所定の操作に基づいて、ゲーム運営者のサーバからゲームプログラムを受信し、受信したゲームプログラムがストレージ18に格納される。ユーザ端末10によってゲームが起動されると、ユーザ端末10とゲームサーバ20との間で通信が確立されてログイン処理が行われ、ゲームサーバ20からユーザ端末10へデータテーブル群(カードデータテーブル、進化合成データテーブル、所持カードデータテーブル、所持履歴データテーブル、および、カード流通データテーブル)が送信される。ユーザ端末10に送信されるデータテーブル群は、ユーザ端末10のストレージ18内に保持される。この場合、ストレージ18内のデータテーブル群は、ログインの度に更新される。
所持カードデータテーブルがユーザ端末10において改竄されることを防止するため、ユーザ端末10による所定の処理が終了する度、あるいは、ゲームからログアウトする時点で、ユーザ端末10内の所持カードデータテーブルがゲームサーバ20へ送信される。ゲームサーバ20では、受信した所持カードデータテーブルと、ストレージ25内の所持カードデータテーブルとを比較し、データの改竄が行われていないことを確認した後に、受信した所持カードデータテーブルに基づいて、ストレージ25内の所持カードデータテーブルを更新する。
【0172】
図29Aおよび
図29Bは、本実施形態の入手条件の提示処理を示すシーケンスチャートである。
図29Aおよび
図29Bの各図において、
図16Aおよび
図16Bと同一の処理については、同一の符合を付してある。
本実施形態の進化合成の予約処理(
図29Aおよび
図29B)では、例えばログイン時に、ゲームサーバ20はユーザ端末10へ、ストレージ25内のデータテーブル群(カードデータテーブル、進化合成データテーブル、所持カードデータテーブル、所持履歴データテーブル、および、カード流通データテーブル)を送信する(S8)。ユーザ端末10のCPU11は、受信したデータテーブル群をストレージ18に記憶するとともに、操作入力部15からの操作入力に基づいて、RAM13および表示部16等と協働してS14〜S48の処理を実行する。
なお、図示しないが、本実施形態では、進化合成処理、クエスト処理、および、進化合成の予約処理についても同様にして、ユーザ端末10が主体的に実行する。
本実施形態では、カードデータテーブル、進化合成データテーブル、クエストデータテーブル、所持カードデータテーブル、所持履歴データテーブル、および、カード流通データテーブルがゲームサーバ20において保持され、予約データテーブルがユーザ端末10において保持される場合について説明したが、この場合に限られない。ネイティブアプリケーション形式のゲームでは、各データテーブルの保持分担については適宜設定することが可能であって、ユーザ端末10およびゲームサーバ20の少なくともいずれかに保持されるようにすればよく、特定の保持態様に限定されるものではない。ゲームサーバ20にいずれかのデータテーブルが保持される場合には、ゲームの実行時にゲームサーバ20に保持されるデータテーブルがユーザ端末10へ送信され、ユーザ端末10内で行われるゲームの処理に利用される。
【0173】
(7)全ての実施形態に共通する変形例
(7−1)ゲーム以外のアプリケーションへの適用に関する変形例
上述した実施形態および変形例では、本発明がゲームに適用される場合について説明したが、他のアプリケーションに適用してもよい。例えばインターネット上のショッピングモールで商品を購入する度に複数種類の電子クーポン券を配布している場合、その電子クーポン券を本発明のオブジェクトの一例としてもよい。この場合、例えばベースオブジェクトとしてのクーポン券Qの特典内容をアップグレード(オブジェクトを変化させる処理の一例)するために、クーポン券Qに対応する参照オブジェクトとしてのクーポン券A〜Cをユーザが所持し利用することが考えられる。この例において、クーポン券Qをアップグレードすること目的として、そのために必要なクーポン券A〜Cのうち、ユーザが所持していないクーポン券(例えば、クーポン券B)の入手条件を提示する。
上述した例示以外の他のアプリケーションについても適宜適用可能である。
【0174】
(7−2)操作入力の方式に関する変形例
上述した実施形態では、ユーザ端末に対する所定の操作入力は、ユーザ端末に対する所定の指示釦の押下操作の入力や、タッチパネル機能を備えたユーザ端末に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えたユーザ端末を振ることによる操作入力、あるいはジェスチャによる操作入力(ジェスチャ入力)であってもよい。ジェスチャ入力では、撮像機能を備えたユーザ端末に対する所定のジェスチャを行うことでユーザ端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能なユーザ端末の場合には、操作入力は、音声を入力することにより行われてもよい。
【0175】
(7−3)ユーザIDの取扱に関する変形例
上述した実施形態では、ユーザ端末10からゲームサーバ20に送信される要求にユーザIDが含まれている(つまり、ゲームサーバ20は、ユーザ端末10から送信される要求に基づいて、処理の要求を行ったユーザを特定できる)ことを前提に説明したが、ゲームサーバ20が処理の要求を行ったユーザを特定する方法はこれに限られない。
例えば、ユーザ端末10とゲームサーバ20との間でユーザIDに基づくセッションが確立された場合、ゲームサーバ20は、当該ユーザIDによって、当該セッション以降の処理の要求を行うユーザを特定してもよい。この場合、ユーザ端末10からゲームサーバ20に送信される要求にユーザIDを含めなくてよい(つまり、ユーザ端末10からゲームサーバ20にユーザIDを送信しなくてよい)。
【0176】
(7−4)操作対象に関する変形例
上述した実施形態では、画像上に表示されたボタンをユーザによる操作対象の一例として示したが、ユーザによる操作が可能な形式であればどのような形式であってもよい。
【0177】
[発明のまとめ]
以上の記載から本発明は例えば以下のように把握される。
【0178】
本発明の一態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第1出力データを出力する出力手段(56)と、
前記出力手段(56)により前記第1出力データが出力されたことに応じて、前記ユーザの指示に基づいて、前記複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける受付手段(51)と、を備え、
前記出力手段(56)は、さらに、前記受付手段(51)により受け付けられた指示により指定されたオブジェクトである指定オブジェクトを前記ユーザが所持していない場合、当該指定オブジェクトの入手条件を表示させるための第2出力データを出力する、
情報処理装置。
【0179】
「情報処理装置」は、スタンドアローンのゲーム機、あるいはユーザ端末(例えば、携帯端末やパーソナルコンピュータ等)やネットワーク上のサーバなどであってもよい。ゲームの実現形態によって適宜情報処理装置の実体を定義することができる。例えば、ユーザがゲーム機やユーザ端末を操作することで情報処理装置の各部の機能が実現される場合には、ゲーム機やユーザ端末が本発明の情報処理装置に相当する。あるいは、クライアントであるユーザ端末がユーザからの操作入力の受付や画像の表示の機能を有し、情報処理装置の各部の機能が実質的にユーザ端末と通信可能なサーバによって実現される場合には、サーバが本発明の情報処理装置に相当する。
「記憶装置」は、例えばフラッシュメモリやHDD(Hard Disk Drive)等、如何なる構成のメモリデバイスであってもよい。また、記憶装置は、情報処理装置に内蔵された装置であってもよいし、情報処理装置から有線または無線でアクセス可能に構成された外部の装置であってもよい。
「入手条件」とは、主体的条件(例えば、オブジェクトを所持しているユーザに関する情報)、時期的条件(例えば、オブジェクトの入手可能期間)、内容的条件(例えば、平均取引価格、第1オブジェクト(例えば、カード)の入手に必要な第2オブジェクト(例えば、アイテム)、または、それらの組合せ)、場所的条件(例えば、入手可能なエリア)、または、それらの組合せであってもよい。
【0180】
上記情報処理装置において、選択オブジェクトを変化させる処理の実行は、少なくとも複数のオブジェクトを示す情報を含む変化条件と、ユーザの所持情報とに基づいて行われる。そのため、例えば変化条件を満たさない場合には、選択オブジェクトを変化させる処理の実行を実行することができない。このとき、ユーザが所持していない指定オブジェクトの入手が、当該ユーザにとって不可能または困難である場合がある。しかし、指定オブジェクトの入手条件を知らないユーザは、指定オブジェクトの入手が不可能または困難であることを、指定オブジェクトを入手するための処理(例えば、クエスト処理)を実行するか否かを決断する時点で認識できない。このような場合、ユーザは、実際には参照オジェクトの入手が不可能または困難かもしれないという不安を抱えたまま、指定オブジェクトを入手するための処理を実行することになる。
上記情報処理装置では、ユーザからの要求に応じて、ユーザが所持していない参照オブジェクトの入手条件を提示する。そのため、選択オブジェクトに対応する複数の参照カードの中に、ユーザにとって入手が不可能または困難な指定オブジェクトがあったとしても、ユーザは、指定オブジェクトの入手が不可能または困難であることを認識した上で、指定オブジェクトを入手するための処理を実行するか否かを決断できる。その結果、指定オブジェクトを入手するための処理を実行するユーザに安心感を与えることができる。
【0181】
前記受付手段(51)は、さらに、前記出力手段(56)により前記第2出力データが出力されたことに応じて、前記ユーザによる操作に基づいて、前記指定オブジェクトに対して、前記選択オブジェクトを変化させる処理以外の処理に用いられることを制限させるための要求を受け付け、
前記受付手段(51)により前記要求が受け付けられたことに応じて、前記指定オブジェクトに対して、前記選択オブジェクトを変化させる処理以外の処理に用いられることを制限する制限手段(58)をさらに備えてもよい。
「選択オブジェクトを変化させる処理とは異なる処理に用いられることを制限する」とは、選択オブジェクトを変化させる処理以外の処理自体が禁止されることに限られず、選択オブジェクトを変化させる処理は実行可能であるが、その処理の実行の要求に必要な要件を増やす、あるいは処理の実行の要求に必要な操作を煩雑にすることであってもよい。
これによって、ユーザからの要求に応じて、選択オブジェクトを変化させる処理以外の処理に指定オブジェクトが用いられることが制限される。そのため、変化条件を満たす前に、ユーザが誤って、選択オブジェクトを変化させる処理以外の処理に指定オブジェクトを使用してしまうことを防止できる。
【0182】
前記入手条件は、前記指定オブジェクトの入手経路であってもよい。
「入手経路」は、例えば、指定オブジェクトの入手可能エリアであってもよいし、ユーザ間でオブジェクトを取引可能なエリア(例えば、ゲーム内のショップ)であってもよい。
また、「入手経路」は、時期的条件と場所的条件の組合せ(例えば、指定オブジェクトが期間限定で発行されたものか否かを示す情報(一例として、限定フラグ)、期間限定の入手可能エリアの開催期間(一例として、期間限定クエストが開催される曜日)、または、それらの組合せ)であってもよい。
これによって、指定オブジェクトを入手するための処理を実行するユーザに安心感を与えることができる。特に、「入手経路」が時期的条件と場所的条件の組合せである場合には、ユーザが選択オブジェクトを変化させる処理の実行要求を行うときに、指定オブジェクトの入手が不可能または困難であるか否かをより正確に判断するための情報が提示されるので、特に有益である。
【0183】
前記第2出力データは、ユーザを前記入手経路に誘導するための操作対象を含んでもよい。
これによって、指定オブジェクトを入手するための処理の実行を要求するときの操作性を向上させることができる。
【0184】
前記第2出力データは、前記指定オブジェクトが、前記ユーザにより所持されたことがあり、且つ、前記取得手段(55)によって指定オブジェクトを示す情報が取得された時点で前記ユーザにより所持されていない、未所持オブジェクトである場合、前記指定オブジェクトの入手経路および入手難易度の少なくとも1つを含んでもよい。
これによって、未所持オブジェクトを入手するための処理を実行するユーザに安心感を与えることができる。
【0185】
前記入手条件として表示される情報は、前記指定オブジェクトが前記ユーザにより所持されたことがない未知オブジェクトである場合、前記指定オブジェクトが前記未所持オブジェクトである場合に比べて制限されてもよい。
これによって、ゲームの難易度を適切なレベルに保ちながら、未知オブジェクトを入手するための処理を実行するユーザに安心感を与えることができる。
【0186】
本発明の別の態様は、
ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと、を含み、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理システムであって、
前記ユーザ端末、および、前記サーバのいずれかが、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第1出力データを出力する出力手段(56)と、
前記出力手段(56)により前記第1出力データが出力されたことに応じて、前記ユーザの指示に基づいて、前記複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける受付手段(51)と、を備え、
前記出力手段(56)は、さらに、前記受付手段(51)により受け付けられた指示により指定されたオブジェクトである指定オブジェクトを前記ユーザが所持していない場合、当該指定オブジェクトの入手条件を表示させるための第2出力データを出力する、
情報処理システムである。
【0187】
本発明の別の態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能なコンピュータを、
ユーザの指示に基づいて、選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第1出力データを出力する手段(56)、
前記第1出力データが出力されたことに応じて、前記ユーザの指示に基づいて、前記複数のオブジェクトのいずれかのオブジェクトを指定する指示を受け付ける手段(51)、
前記受け付けられた指示により指定されたオブジェクトである指定オブジェクトを前記ユーザが所持していない場合、当該指定オブジェクトの入手条件を表示させるための第2出力データを出力する手段(56)、
として機能させるためのプログラムである。
【0188】
本発明の別の態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理装置において、
選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトの入手条件を表示させるための第1出力データを出力する第1出力手段と、
前記第1出力手段により前記第1出力データが出力されたことに応じて、ユーザにより指定されたオブジェクトである第1指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求を受け付ける第1受付手段と、
前記第1受付手段により前記要求が受け付けられたことに応じて、前記第1指定オブジェクトに対して、前記処理に用いられることを制限する第1制限手段と、
を備える、情報処理装置である。
【0189】
これによって、ユーザは、入手条件を提示する画面において参照カードの入手が困難であることを認識した直後に、当該参照カードが消失しない状態にすることができるようになる。したがって、参照カードの意図に反する消失を確実に防ぐことができる。
【0190】
また、複数のオブジェクトをユーザにそれぞれ識別可能な表示形式で表示させるための第2出力データを出力する第2出力手段と、
前記第2出力手段により前記第2出力データが出力されたことに応じて、前記複数のオブジェクトのうちユーザに指定されたオブジェクトである第2指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求を受け付ける第2受付手段と、
前記第2受付手段により前記要求が受け付けられたことに応じて、前記第2指定オブジェクトに対して、前記処理に用いられることを制限する第2制限手段と、をさらに備え、
前記第1出力データおよび前記第2出力データの少なくとも1つは、前記第1制限手段による制限の対象となっているオブジェクトと、前記第2制限手段による制限の対象となっているオブジェクトとを、ユーザにそれぞれ識別可能な表示形式で表示させるためのデータであってもよい。
【0191】
また、前記制限の対象とするオブジェクトは、前記ユーザが所持しているオブジェクトである所持オブジェクトの中から指定されたオブジェクトであり、
前記所定の処理は、前記指定されたオブジェクトを前記所持オブジェクトから消失させることを条件として実行される処理であってもよい。
【0192】
「前記指定されたオブジェクトを前記所持オブジェクトから消失させることを条件として実行される処理」とは、当該処理を実行した場合、指定されたオブジェクトが所持オブジェクトから消失する(つまり、指定されたオブジェクトが未所持オブジェクトになる)、処理である。
【0193】
また、前記第1受付手段によって受け付けられた要求または前記第2受付手段によって受け付けられた要求の少なくともいずれか一方は、前記制限の対象とするオブジェクトに対して、前記所持オブジェクトから消失させることを条件として実行される処理に用いられることを制限させるための第1要求と、前記所持オブジェクトから消失させることを条件として実行される処理のうち前記選択オブジェクトを変化させる処理以外の処理に用いられることを制限させるための第2要求とを含んでもよい。
【0194】
「選択オブジェクトを変化させる処理」および「選択オブジェクトを変化させる処理以外の処理」は、いずれも、「所持オブジェクトから消失させることを条件として実行される処理」の一態様である。
「第1要求」とは、第1指定オブジェクトを所持オブジェクトから消失させることを条件として実行される処理の全てに対する制限の要求である。
「第2要求」とは、第1指定オブジェクトを所持オブジェクトから消失させることを条件として実行される処理のうち、選択オブジェクトを変化させる処理以外の処理の全てに対する制限(換言すると、選択オブジェクトを変化させる処理のみを許可すること)の要求である。
【0195】
また、前記第2出力データは、前記第1要求の対象となっているオブジェクトと、前記第2要求の対象となっているオブジェクトとを、ユーザにそれぞれ識別可能な表示形式で表示させるためのデータであってもよい。
【0196】
「前記第1要求の対象となっているオブジェクト」とは、所持オブジェクトから消失させることを条件として実行される処理の全てに対する利用が制限されているオブジェクト(つまり、所持オブジェクトから消失し得ない状態に置かれたオブジェクト)である。
「前記第2要求の対象となっているオブジェクト」とは、選択オブジェクトを変化させる処理以外の処理に対する利用が制限されている(つまり、選択オブジェクトを変化させる処理への利用のみが許可されている)オブジェクトである。
【0197】
本発明の別の態様は、
ユーザ端末と、当該ユーザ端末と通信可能に構成されるサーバと、を含み、オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能な情報処理システムであって、
前記ユーザ端末、および、前記サーバのいずれかが、
選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトの入手条件を表示させるための第1出力データを出力する第1出力手段と、
前記第1出力手段により前記第1出力データが出力されたことに応じて、ユーザにより指定されたオブジェクトである第1指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求を受け付ける第1受付手段と、
前記第1受付手段により前記要求が受け付けられたことに応じて、前記第1指定オブジェクトに対して、前記処理に用いられることを制限する第1制限手段と、
を備える、情報処理システムである。
【0198】
本発明の別の態様は、
オブジェクトを特定するオブジェクト識別情報と、前記オブジェクトを変化させる処理に用いられる複数のオブジェクト識別情報を含む変化条件と、を対応付けて記憶する記憶装置にアクセス可能なコンピュータを、
選択されたオブジェクトである選択オブジェクトのオブジェクト識別情報に対応する変化条件に含まれる複数のオブジェクト識別情報によって特定される複数のオブジェクトの入手条件を表示させるための第1出力データを出力する手段、
前記第1出力データが出力されたことに応じて、ユーザにより指定されたオブジェクトである第1指定オブジェクトに対して、所定の処理に用いられることを制限させるための要求を受け付ける手段、
前記要求が受け付けられたことに応じて、前記第1指定オブジェクトに対して、前記処理に用いられることを制限する手段、
として機能させる、プログラムである。
【0199】
なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書きで記載しているが、これにより本発明に係る情報処理装置等が図示の態様に限定されるものではない。