JP6363767B2 - コンピュータシステム - Google Patents

Description

本発明は、ゲームの攻略情報を提供するコンピュータシステムに関する。

人気のゲームジャンルとして、プレーヤが有するキャラクタ（自分のオブジェクト：自オブジェクト）を自由に組み合わせてデッキ（自オブジェクト群：チームに相当）を編成して敵と戦うゲームがある。
例えば、パズルゲームと、デッキをパーティと見立てたＲＰＧ（ロールプレイングゲーム）風の戦闘ゲームとが組み合わされたゲームとして、パズルゲームの成績によってデッキに組み込まれた各キャラクタの戦闘行動が変化するように構成された非特許文献１のゲームが知られている。

こうしたゲームでは、パズルを解く楽しみと同時に、どのようなデッキを構成してダンジョンを攻略するか、パズルゲームとＲＰＧ風戦闘ゲームとの２つの要素を同時に楽しめるので人気が高い。特に、後者に関しては、登場するキャラクタには、交戦時に有利／不利が生じるいわゆる「三竦みの相性関係」となる「属性」が設定されており、どのような属性のキャラクタでデッキを構成するかを考える攻略性もゲーム興趣を高める要因となっている。

また、プレーヤがキャラクタの属性を考慮するなどの攻略性を有するゲームに関しては、ゲームを攻略する上でのヒント、つまり攻略情報を提供する技術も知られるところである（例えば、特許文献１、特許文献２を参照）。

特開２００２−１９１８６８号公報 特開２００７−２６００１２号公報

ガンホー・オンライン・エンターテイメント株式会社、ゲームアプリ「パズル＆ドラゴン」、２０１２年２月２０日配信開始、関連ＵＲＬ：http://www.gungho.jp/pad/

本発明は、相互の組み合わせで有利／不利の相性関係が生じる属性が付与されたキャラクタを編成してデッキ（チーム、手札群）を用いるゲームにおいて、ゲーム攻略に関する情報を提供する等して、ユーザビリティを向上させることを目的とする。

上述した課題を解決するための第１の発明は、登場する対戦相手オブジェクト群が予め定められたゲームをプレーヤが編成した自オブジェクト群で攻略する際の攻略情報を提供するコンピュータシステムであって、オブジェクトには属性が定められており、前記対戦相手オブジェクト群を構成するオブジェクト（例えば、図３の敵キャラクタ５）の属性と、前記自オブジェクト群を構成するオブジェクト、例えば、図３のプレーヤキャラクタ４ａ〜４ｄ）の属性とに基づいて、前記自オブジェクト群への編入を推奨する推奨オブジェクトを判定する判定手段（例えば、図１のサーバシステム１１００、図１０のサーバ処理部２００、ゲーム管理部２１０、サポート制御部２３０、推奨キャラクタ判定部２３２、図１５のステップＳ４０）と、
前記推奨オブジェクトを前記プレーヤに向けて報知する制御を行う報知制御手段（例えば、図１のサーバシステム１１００、図１０の推奨キャラクタ報知制御部２３６、図１５のステップＳ４２）と、を備えたコンピュータシステムである。

この別発明として、コンピュータに、登場する対戦相手オブジェクト群が予め定められたゲームをプレーヤが編成した自オブジェクト群で攻略する際の攻略情報を提供させるためのプログラムであって、オブジェクトには属性が定められており、前記対戦相手オブジェクト群を構成するオブジェクトの属性と、前記自オブジェクト群を構成するオブジェクトの属性とに基づいて、前記自オブジェクト群への編入を推奨する推奨オブジェクトを判定する判定手段、前記推奨オブジェクトを前記プレーヤに向けて報知する制御を行う報知制御手段、として前記コンピュータを機能させるためのプログラムを構成できる。

「オブジェクト」は、ゲームに登場するゲームプレイの要素となる存在である。登場人物となるキャラクタは勿論のこと、当該キャラクタが使用する武器や防具などのアイテムなども該当する。レースゲームなどではレーシングカーがこれに該当する。野球やサッカーなどのスポーツゲームでは、選手がこれに該当する。
「オブジェクト群」は、単数または複数のオブジェクトで構成された単位である。ゲーム内容によってはチーム、パーティ、デッキ、部隊、グループとも呼べる。よって「対戦相手オブジェクト群」はゲームの内容によっては、プレーヤの敵として登場するオブジェクト群である。「自オブジェクト群」はプレーヤが選択したり操作できるオブジェクト群である。

第１の発明及び別発明によれば、対戦相手オブジェクト群を構成するオブジェクトの属性と、自オブジェクト群を構成するオブジェクトの属性とに基づいて、ゲームを攻略するのに役立つ推奨オブジェクトを判定してプレーヤに知らせることができる。つまり、ゲーム攻略に関する情報を提供することができる。

第２の発明は、前記コンピュータシステムが、プレーヤ端末と通信可能に構成されたサーバシステムであり、前記報知制御手段は、前記プレーヤ端末に前記推奨オブジェクトを通知して当該プレーヤ端末に表示させるための制御を行う、第１の発明のコンピュータシステムである。

また、第３の発明は、第第２の発明のコンピュータシステムに通信する通信部と、前記プレーヤが有するオブジェクトの情報を記憶する記憶部とを備えたプレーヤ端末を、前記コンピュータシステムから前記推奨オブジェクトの識別情報を受信する制御を行う受信制御手段、前記記憶部の記憶内容を照査し、前記プレーヤが前記推奨オブジェクトを有しているか否かに応じて、当該推奨オブジェクトの前記自オブジェクト群への編入を推奨する報知を行う推奨報知制御手段（例えば、図１４の処理部２００、プレーヤ端末演算部２６０、ゲーム画面表示制御部２６２、推奨報知表示制御部２６４）、として前記プレーヤ端末を機能させるためのプログラムである。

第２または第３の発明によれば、推奨オブジェクトを自オブジェクト群に編入するように促す報知表示を、プレーヤが使用するコンピュータ、すなわちプレーヤ端末にて行うことができる。

第４の発明は、ランダム抽選によって付与オブジェクトを選択し、前記プレーヤに付与する抽選手段（例えば、図１９の課金抽選部２１４）、前記推奨オブジェクトが前記付与オブジェクトとして選択されるまで前記課金抽選手段による抽選を実行させる抽選制御手段（例えば、図１９の課金抽選制御部２３８）、として前記プレーヤ端末を機能させるための第３の発明のプログラムである。

第４の発明によれば、抽選で推奨オブジェクトを獲得しようとしたときのプレーヤの手間を低減し、ユーザビリティを向上できる。

第５の発明は、前記ゲームが、複数のオブジェクトを一のオブジェクトに合成可能なゲームであり、前記記憶部の記憶内容を照査し、前記プレーヤが有しているオブジェクトを合成することで前記推奨オブジェクトを生成することが可能であるか否かを判定する合成生成可否判定手段（例えば、図１９の合成生成可否判定部２３４）として前記プレーヤ端末を更に機能させ、前記推奨報知表示制御手段が、前記合成生成可否判定手段により可能と判定された場合に、合成するオブジェクトの組み合わせを報知する制御を行う、第３または第４の発明のプログラムである。

第５の発明によれば、推奨オブジェクトをオブジェクトの合成で入手可能であることをプレーヤに知らせることができる。

第６の発明は、前記記憶部に前記推奨オブジェクトの情報が新たに記憶された場合に、当該推奨オブジェクトを前記自オブジェクト群に編入して前記ゲームを攻略する試みを推奨する報知を行う取得時報知制御手段（例えば、図１９の取得時報知制御部２３９）として前記プレーヤ端末を機能させるための第３〜第５の何れかの発明のプログラムである。

第６の発明によれば、更に推奨オブジェクトの入手が完了したことをプレーヤに知らせることができる。

第７の発明は、前記ゲームの攻略に成功した自オブジェクト群の情報を記憶したデータベース（例えば、図１１のデータベース５５０）を更に備え、前記判定手段は、前記データベースを参照して前記推奨オブジェクトを判定する、第１または第２の発明のコンピュータシステムである。

また、第８の発明は、前記ゲームの攻略に有効な予め設定されたオブジェクト群の情報を記憶したデータベースを更に備え、前記判定手段は、前記データベースを参照して前記推奨オブジェクトを判定する、第１又は第２の発明のコンピュータシステムである。

また、第９の発明は、前記データベースが、前記ゲームの攻略に成功した前記自オブジェクト群の情報と、当該ゲームのプレイ課程とを関連づけて記憶する、第７の発明のコンピュータシステムである。

第７〜第９の発明によれば、データベースに含まれる攻略に有効な情報に基づいて推奨オブジェクトを判定することができる。

第１０の発明は、前記推奨オブジェクトの前記報知を行うか否かを判断する報知是非判断手段（例えば、図１０のサポート是非判定部２３１、図１５のステップＳ１１）を更に備え、前記報知制御手段は、前記報知是非判断手段による判断結果が肯定の場合に、前記報知を行う制御をする、第１，第２，第７，第８又は第９の発明のコンピュータシステムである。

また、形態違いの別発明として、前記推奨オブジェクトの前記報知を行うか否かを判断する報知是非判断手段として前記プレーヤ端末を更に機能させ、前記推奨報知制御手段は、前記報知是非判断手段による判断結果が肯定の場合に、前記推奨する報知を行う、第３〜第６の何れかの発明のプログラムとして構成することもできる。

第１０の発明及びこの別発明によれば、推奨オブジェクトの報知を実行するか否かを判定することができる。

自オブジェクトを仮想的なカードオブジェクトとするならば、第１３の発明として、自オブジェクトは仮想的なカードオブジェクトであり、前記プレーヤの操作入力に基づいて、カードデッキとして前記自オブジェクト群を編成する編成手段（例えば、図１０のゲーム実行部２２０）として前記コンピュータを機能させるための第３〜第６、第１１及び第１２のうちの何れかの発明のプログラムを構成することができる。

第１実施形態におけるコンピュータシステムの構成の一例を示す図。 プレーヤ端末の構成例を示す正面外観図。 ゲーム画面例を示す図。 キャラクタに付与される属性について説明するための図。 第１のサポート機能について説明するための図。 第１のサポート機能について説明するための図。 第２のサポート機能について説明するための図。 第３のサポート機能について説明するための図。 第４のサポート機能について説明するための図。 第１実施形態におけるサーバシステムの機能構成例を示す図。 第１実施形態におけるサーバ記憶部に記憶されるプログラムやデータの例を示す図。 ゲームステージ初期設定データのデータ構成の一例を示す図。 ユーザ登録データのデータ構成の一例を示す図。 第１実施形態におけるプレーヤ端末の機能構成の一例を示す機能ブロック図。 第１実施形態におけるサーバシステムのサポート機能に係る処理の流れについて説明するためのフローチャート。 図１５より続くフローチャート。 図１６より続くフローチャート。 第２実施形態におけるサーバシステムの機能構成例を示す機能ブロック図。 第２実施形態におけるプレーヤ端末の機能構成例を示す機能ブロック図。 第２実施形態における記憶部に記憶されるプログラムやデータの例を示す図。 第２実施形態におけるプレーヤ端末のサポート機能に係る処理の流れを説明するためのフローチャート。 図２１より続くフローチャート。 図２２より続くフローチャート。 変形例におけるサーバシステムの機能構成例を示す機能ブロック図。 変形例におけるプレーヤ端末の機能構成例を示す機能ブロック図。 変形例におけるプレーヤ端末のサポート機能に係る処理の流れを説明するためのフローチャート。

〔第１実施形態〕
本発明を適用した第１実施形態として、プレーヤが有する（より正確には使用権を有する。以下同じ。）複数のキャラクタ（ゲームで使用するオブジェクト）の中から、キャラクタを選抜してデッキ（自オブジェクト群、チーム）を構成してプレイするゲームについて、ゲーム攻略の情報を提供する例について説明する。

［ゲームシステムの説明］
図１は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態のゲームシステムは、通信回線Ｎに接続することのできるサーバシステム１１００と、プレーヤ２（２ａ，２ｂ，２ｃ，…）毎に用意されるプレーヤ端末１５００（１５００ａ，１５００ｂ，１５００ｃ，…）とを備えて構成される。

サーバシステム１１００は、単数又は複数のサーバシステムや記憶装置等を含んで構成されたコンピュータシステムであって、ＳＮＳ（ソーシャルネットワーキングサービス）等の会員登録制のコミュニティ型ウェブサイトを運営するための各種サービスを実現する。

具体的には、会員登録を済ませたユーザにはそれぞれ固有のアカウント（ハンドルネームと読み替えることもできる）を発給し、登録済みユーザに係る情報はサーバシステム１１００がユーザ登録データ５３０で一元的に管理する。そして、ユーザ登録データ５３０に基づいて当該ウェブサイトにおける様々なサービスを提供する。本実施形態の対戦ゲームも、登録ユーザへのサービスの一環として提供・実現される。すなわち、各プレーヤ２（２ａ，２ｂ，２ｃ，…）は登録ユーザである。各プレーヤ２（２ａ，２ｂ，２ｃ，…）は、それぞれのプレーヤ端末１５００（１５００ａ，１５００ｂ，１５００ｃ，…）を使用してサーバシステム１１００にアクセスし、本実施形態のゲームを楽しむ。

サーバシステム１１００は、本体装置１１０１と、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを備える。本体装置１１０１には、制御基板１１５０が搭載されている。制御基板１１５０には、ＣＰＵ（Central Processing Unit）１１５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１１５２、通信装置１１５３が搭載されている。

そして、本実施形態のゲームに関する機能として、アカウント登録やログイン／ログアウトに関係する処理を担うアカウント管理機能と、プレーヤ端末１５００にてゲームをプレイするのに必要なデータを随時管理・配信するゲーム管理機能と、を有する。

図示の例では、サーバシステム１１００は単体として記しているが、サーバシステム１１００には複数のブレードサーバを搭載し、アカウント管理機能及びゲーム管理機能を分担して担い、相互に内部バスを介してデータ通信可能に接続された構成であっても良い。或いは、離れた場所に設置された独立した複数のサーバを、通信回線Ｎを介してデータ通信させることで、全体としてサーバシステム１１００として機能させる構成であっても良い。

図２は、プレーヤ端末１５００の構成例を示す正面外観図である。
プレーヤ端末１５００は、通信回線Ｎに接続してサーバシステム１１００にアクセスすることができるコンピュータであり電子装置（電子機器）である。本実施形態のプレーヤ端末１５００はいわゆるスマートフォンとして分類される装置であるが、携帯型ゲーム装置、据置型家庭用ゲーム装置、据置型家庭用ゲーム装置のゲームコントローラ、業務用ゲーム装置、パソコン、タブレット型コンピュータ、などに分類される装置でもよい。

本実施形態におけるプレーヤ端末１５００は、方向入力キー１５０２と、ボタンスイッチ１５０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１５０６と、スピーカ１５１０と、内蔵バッテリー１５０９と、マイク１５１２と、制御基板１５５０と、コンピュータ読み出し可能な記憶媒体であるメモリカード１５４０からデータを読み書きできるメモリカード読取装置１５４２と、を備える。その他、図示されていない電源ボタン、音量調節ボタン等が設けられている。

制御基板１５５０は、ＣＰＵ１５５１やＧＰＵ，ＤＳＰなどの各種マイクロプロセッサと、ＡＳＩＣ，ＶＲＡＭ，ＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１５５２と、通信回線Ｎに接続する携帯電話基地局や無線ＬＡＮ基地局などと無線通信するための無線通信モジュール１５５３とが搭載されている。その他、タッチパネル１５０６のドライバ回路、方向入力キー１５０２及びボタンスイッチ１５０４からの信号を受信する回路、スピーカ１５１０へ音声信号を出力する出力アンプ回路、マイク１５１２で集音した音声の信号を生成する入力信号生成回路、メモリカード読取装置１５４２への信号入出力回路といった所謂Ｉ／Ｆ回路１５５７（インターフェース回路）等が搭載されている。これら制御基板１５５０に搭載されている各要素は、それぞれバス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。

制御基板１５５０は、ゲームクライアントプログラムやデータをＩＣメモリ１５５２に一時記憶する。そして、プログラムを実行して演算処理を実行し、方向入力キー１５０２やボタンスイッチ１５０４，タッチパネル１５０６からの操作入力に応じてプレーヤ端末１５００の各部を制御してゲームプレイ可能にする。本実施形態では、プレーヤ端末１５００は必要なプログラムや各種設定データをサーバシステム１１００から取得する構成としているが、別途入手したメモリカード１５４０から読み出す構成としても良い。

なお、通信回線Ｎは、データ通信が可能な通信路を意味する。すなわち、通信回線Ｎとは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。

［ゲーム内容の説明］
図３は、本実施形態におけるゲーム画面例を示す図である。
本実施形態のゲームでは、パズルゲームと、当該パズルゲームにおける成績に応じた行動力が付与されるプレーヤキャラクタ４（４ａ，４ｂ４ｃ，４ｄ）が敵キャラクタ５と戦うステージ形式のＲＰＧ風戦闘ゲームとが実行される。つまり、２種類のゲーム要素が組み込まれたハイブリッドタイプのゲームである。よって、タッチパネル１５０６に表示されるゲーム画面は、パズルゲームに係る画像を表示する第１表示部１０と、戦闘ゲームに係る画像を表示する第２表示部２０とを有する。
なお、パズルゲームは、例えば、仮想のメダルゲームや、三竦みの関係の何れかを選択操作するジャンケンゲーム、複数の絵柄を揃える仮想のスロットマシン、などに適宜置き換え可能である。

本実施形態のゲーム開始前には、プレーヤは戦闘ゲームでプレイするゲームステージを選択する。ゲームは、パズルゲームがプレイアブルで、戦闘ゲームがノンプレイアブルな状態から開始される。パズルゲームがプレイ中断条件を満たすとパズルゲームはノンプレイアブル状態となり、代わりに戦闘ゲームがプレイアブルになる。そして、戦闘ゲームでプレイ中断条件を満たすと、戦闘ゲームは再びノンプレイアブルに戻り、パズルゲームのプレイ中断が解かれ再びプレイアブルに戻る。こうしたプレイアブル／ノンプレイアブルの交互切り替えは、戦闘ゲームにてゲームステージをクリアするか、ゲームオーバーとなるかするまで繰り返される。

パズルゲームの内容は適宜選択可能である。
本実施形態では、格子状にランダム配列されている複数種類の貯留子９（遊技媒体；図では四角タイル型をベースにして、丸や三角などのマークの有無で種類を分けて表記）を揃えて消すパズルゲームである。プレーヤがある貯留子９をタッチして配置を入れ替えたいと思う隣の格子位置へ向けてスライド操作をすると、スライド操作されている貯留子と、スライド操作した先の位置に元々あった隣の貯留子との位置が入れ替わる。

貯留子９の入れ替わりの結果、縦方向又は横方向に同種の貯留子による３つ以上の並び（以降、「貯留子セット」と呼ぶ）が成立すると、該当する貯留子９は自動的に消される。貯留子９が消えた格子位置には空間が生じるので、それより上側（第１表示部１０における上側）に有った貯留子９がその空間を埋めるように画面上側から下側へ自動的に移動するように制御される。そして、当該移動が終了してなお残っている空間へは、第１表示部１０の画面外から新たな貯留子９が出現して補充される。つまり、同種の貯留子９の並びを作って消すことが、当該パズルゲームにおいて「パズルを解く」ことに当たる。

そして、３つ以上の同種の貯留子９を並べて消すことが、パズルゲームにおけるプレイ中断条件を満たすことと同義であり、戦闘ゲームを進行させる起因となる。第１表示部１０で貯留子消去の検知に伴う演出表示や通知表示が終わるとパズルゲームは一時的にノンプレイアブルとなり、代わりに第２表示部２０で表示される戦闘ゲームがプレイアブルとなる。戦闘ゲームにおいて、パズルゲームの成績に応じて付与された行動力を消費して戦闘が行われると、戦闘ゲームにおけるプレイ中断条件が満たされたと見なされ、戦闘ゲームはノンプレイアブルに戻され、パズルゲームが再びプレイアブルになる。

戦闘ゲームは、各プレーヤが有している仮想的なカードオブジェクトであるキャラクタの中から所定数（図の例では４体）選択してデッキを構成してプレイする。デッキは、自オブジェクト群でありチームに相当する。
戦闘ゲームがプレイアブルになると、デッキを構成するプレーヤキャラクタ４が、敵キャラクタ５と戦闘をする。図の例では、敵キャラクタ５を一体として描いているが、複数であってもよい。以降、敵キャラクタ５は、単数または複数の対戦相手オブジェクトで構成された対戦相手オブジェクト群と読み替え可能とする。

第２表示部２０は、デッキ表示部２１と、戦闘表示部２２とを有する。デッキ表示部２１には、自プレーヤ２ａのデッキを構成するプレーヤキャラクタ４のステータスが表示される。戦闘表示部２２には、仮想カメラで仮想三次元空間に配置されたキャラクタオブジェクトの様子を撮影した画像いわゆる３ＤＣＧをベースとした戦闘の様子が表示される。次々に出現する敵キャラクタ５を撃破し、ボスキャラクタを討伐すれば当該ゲームステージはクリアとなる。途中、プレーヤキャラクタ４が全て戦闘不能になるとゲームオーバーとなる。

デッキ編成の元になるキャラクタの入手つまり使用権の獲得は、公知のデッキ編成タイプのゲームと同様に実現できる。例えば、（１）オンラインショッピングで購入、（２）ログイン時に実行される無料抽選で獲得、（３）課金を伴うランダム抽選によって付与キャラクタ（付与オブジェクト）が選択・付与される課金抽選で獲得、（４）キャラクタＩＤを担持するトレーディングカードを入手して、そのキャラクタＩＤを登録することで獲得する、（５）既に有しているキャラクタの育成又は合成（複数のキャラクタを消費して、それらとは異なる種類のキャラクタと交換）により獲得、などの方法で実現される。なお、これら全ての方法は公知技術と同様に実現可能であり、本実施形態ではこれら全ての方法が利用可能である。

［キャラクタの属性についての説明］
戦闘ゲームに登場するキャラクタは、プレーヤ２が獲得し得るキャラクタは勿論のこと敵キャラクタ５に対しても、それぞれに「属性」が予め付与されている。本実施形態では、図４に示すように「火」「水」「木」の３つの属性が設定されており、火属性は木属性に対して強く、木属性は水属性に対して強く、水属性は火属性に対して強い、三竦みの相性関係を成している。

例えば、図４（１）のように、プレーヤのデッキを火属性のプレーヤキャラクタ４ａを主体に構成して、水属性の敵キャラクタ５と交戦すると、プレーヤ側からの攻撃は敵キャラクタ５に小ダメージしか与えられないが、逆に敵キャラクタ５の攻撃はプレーヤキャラクタ４ａに大ダメージを与えることができる。よって、このようなデッキ構成ではゲームステージの攻略は難しくなる。逆に図４（２）のように、木属性のプレーヤキャラクタ４ｄを主体にデッキを構成すると有利／不利の関係が逆転し、ゲームステージの攻略が容易となる。このように敵キャラクタ５の属性と、プレーヤデッキを構成するプレーヤキャラクタ４の属性との組み合わせによって攻略の難易度が変わることになる。

なお、属性の内容や種類の数はこの例に限らず適宜設定可能である。
また、属性間の有利／不利の関係は一対一の関係に限らず適宜設定可能である。例えば、第１属性は、第２属性に対して単独では不利であるが、第１属性と第３属性との組み合わせでは、第２属性に対して有利となるなどの一対多の関係が設定可能である。以降、属性についての有利／不利の関係について述べる場合、こうした複数種類の属性の組み合わせも含まれるものとする。

［プレーヤへのサポート機能の説明］
さて、本実施形態では様々なプレーヤをサポートする機能が実現される。
第１のサポート機能として、キャラクタの属性を考慮した攻略情報の提供を行うことができる。

具体的には、現在プレイ中のゲームステージに登場する敵キャラクタ５（単数でも群れでも良い）の属性と、プレーヤのデッキを構成するプレーヤキャラクタ４の属性とに基づいて、当該ゲームステージの攻略に際してプレーヤのデッキへの編入を推奨する推奨キャラクタ（推奨オブジェクト）を判定し、判定した推奨キャラクタをプレーヤに向けて報知することができる。

推奨キャラクタを判定する基準となるデータとして、サーバシステム１１００は、ゲームステージ毎に攻略に成功した過去のプレーヤ（誰でもよい）のデッキ情報を記憶したデータベース５５０（図５）と、ゲームステージ初期設定データ５２０（図６）とを記憶・管理する。また、サーバシステム１１００は、ユーザ登録データ５３０にてプレーヤそれぞれが編成したプレーヤデッキデータ５３２をプレーヤ個別に管理している（図１）。

先ず、図５を参照しながらデータベース５５０を用いる場合について説明する。
ゲームステージをクリア（＝攻略に成功）すると、サーバシステム１１００は、そのときプレイ過程を記述する情報をクリア事例過程データ５５１として追加し、更にその時のプレーヤのプレーヤデッキデータ５３２の複製をクリア事例デッキデータ５５２としてデータベース５５０に追加する。つまり、成功事例を集めて登録する。

そして、データベース５５０におけるクリア事例デッキデータ５５２の登録数が統計的に有意な値に達すると、クリア事例デッキデータ５５２を統計処理して「統計ベース基準属性配分」を判定する。統計ベース基準属性配分は、例えば、統計的に最多の属性配分や、上位所定数の属性配分、などとしてもよい。そして、判定した統計ベース基準属性配分とプレーヤ２のプレーヤデッキの属性配分とを比較し、前者にあって後者に無い属性を「推奨属性」として決定する。そして、推奨属性が付与されているキャラクタを検索し、検索されたキャラクタすなわち「推奨キャラクタ」をデッキに編入するように推奨する報知３０をプレーヤ端末１５００で実行させる。

本実施形態では、報知３０として、推奨属性と推奨キャラクタの情報（例えば、キャラクタＩＤやキャラクタのアイコンなど）を表示させる。また、報知３０では、現在のプレーヤが獲得しているキャラクタの中に推奨キャラクタが含まれていなければその旨を告げる内容が表示され、含まれている場合には推奨キャラクタをプレーヤデッキに編入するように進める内容が表示される。サーバシステム１１００が提供するオンラインショッピングサイトにて当該推奨キャラクタを購入するための特定ページへのリンクを含めるとしてもよい。

一方、データベース５５０への登録数が統計的に有意な値に達するまでは、図６に示すように、ゲームステージ初期設定データ５２０の敵デッキデータ５２２を参照して推奨キャラクタを決定する。

敵デッキデータ５２２には、当該敵デッキを構成する敵キャラクタ毎の属性に関する情報が格納されている。サーバシステム１１００は、敵デッキデータ５２２を参照して当該ゲームステージの敵キャラクタ５の属性に対して有利な属性すなわち「推奨属性」を判定する。そして、サーバシステム１１００は、プレーヤのデッキに含まれるプレーヤキャラクタ４の属性と推奨属性とを比較し、推奨属性が含まれていなければ、この含まれていなかった推奨属性が付与されているキャラクタを検索し、検索されたキャラクタすなわち推奨キャラクタをデッキに編入するように推奨する報知３０をプレーヤ端末１５００で実行させる。

報知３０を見たプレーヤは、推奨キャラクタを自らのデッキに編入すれば、キャラクタ属性の点からより有利にそのゲームステージを攻略できることを理解する。もし、推奨キャラクタを有していなくとも、プレーヤに対して推奨キャラクタを新たに獲得することが攻略の鍵となることを示すことができる。つまりは、プレーヤに攻略に関する情報を提供することができる。

なお、推奨属性および推奨キャラクタには、それぞれ「該当なし」が含まれる。つまり、プレーヤデッキの属性配置がすでに統計ベース基準属性配分と同じ場合や、プレーヤデッキの属性配置がすでに敵デッキの属性配置に対して優位な属性で占められている場合（あるいは優位な属性を十分含んでいる場合）、がそれに該当する。

本実施形態は、第２のサポート機能として、推奨キャラクタの課金抽選による入手をサポートすることができる。

具体的には、図７（１）に示すように、サーバシステム１１００は、推奨キャラクタの識別情報を含む推奨キャラクタ登録データ５３８を、ユーザ登録データ５３０に含めプレーヤ毎に管理することができる。また、自動課金抽選の停止条件設定画面３４を表示させてプレーヤに課金抽選の連続実行を停止する条件を入力させ、入力結果を同じくユーザ登録データ５３０に停止条件データ５４０として格納することができる。

停止条件としては、抽選の上限回数（または上限金額）や、抽選結果として得られる付与キャラクタの種類すなわち獲得目標とするキャラクタが設定可能である。後者については、本実施形態では推奨キャラクタ登録データ５３８が示す推奨キャラクタの何れかから選択可能とされる。

そして、プレーヤによる課金抽選の開始操作入力を検出すると、サーバシステム１１００は課金抽選の実行を開始し、図７（２）に示すように、プレーヤ端末１５００では抽選の様子が表示される。サーバシステム１１００は設定されている停止条件が満たされるまで自動的に課金抽選を連続実行する。抽選により得られた付与キャラクタの識別情報は、プレーヤが既に獲得しているキャラクタの識別情報を含む獲得済キャラクタＩＤリスト５３６へ自動的に追加登録されるので、それ以降プレーヤはいつでも当該キャラクタを使用可能となる。
つまり、第２のサポート機能を利用すれば、プレーヤは一々抽選実行操作を繰り返す必要がなくなる。

また、本実施形態は、第３のサポート機能として、推奨キャラクタの合成による入手をサポートすることができる。

具体的には、図８に示すように、サーバシステム１１００は、合成に必要なキャラクタと合成されるキャラクタの組み合わせを定義した合成設定データ５１２を記憶している。また、推奨キャラクタの識別情報を含む推奨キャラクタ登録データ５３８を、ユーザ登録データ５３０に含めてプレーヤ毎に管理することができるとともに、プレーヤが既に有しているキャラクタの識別情報を含む獲得済キャラクタＩＤリスト５３６を管理できる。

サーバシステム１１００は、合成設定データ５１２を参照して、推奨キャラクタが合成され得るキャラクタであるかを判定する。もし、肯定ならば、獲得済キャラクタＩＤリスト５３６を照査し、プレーヤが既に有しているキャラクタを合成することで推奨キャラクタを生成することが可能であるか否かを判定する。そして、可能であると判定された場合には、プレーヤ端末１５００にて推奨キャラクタが合成可能である旨の報知３２をさせる。

また、本実施形態では、第４のサポート機能として、推奨キャラクタが使用可能になったことを検出してプレーヤに報知することができる。これを「取得時報知」と呼ぶ。
具体的には、図９に示すように、獲得済キャラクタＩＤリスト５３６を照査し、推奨キャラクタが当該リストに追加されたことを検出すると、プレーヤ端末１５００にて、推奨キャラクタをデッキに編入してゲームステージを攻略することを推奨する報知３６を表示させる。

次に、こうしたサポート機能を実現するための機能構成について説明する。

［サーバシステムの機能構成の説明］
図１０は、本実施形態におけるサーバシステム１１００の機能構成例を示す機能ブロック図である。本実施形態におけるサーバシステム１１００は、操作入力部１００ｓと、サーバ処理部２００ｓと、画像表示部３７２ｓと、通信部３７４ｓと、サーバ記憶部５００ｓとを備える。

操作入力部１００ｓは、サーバの管理のための各種操作を入力するための手段である。図１のキーボード１１０６がこれに該当する。

サーバ処理部２００ｓは、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００ｓやサーバ記憶部５００ｓを含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００ｓからの操作入力信号、プレーヤ端末１５００から受信したデータに基づいて各種の演算処理を実行して、サーバシステム１１００の動作を統合的に制御する。

そして、本実施形態のサーバ処理部２００ｓは、アカウント管理部２０１と、オンラインショッピング管理部２０２と、ゲーム管理部２１０と、画像生成部２７２ｓと、通信制御部２７４ｓとを含む。

アカウント管理部２０１は、ユーザ登録手続きに係る処理を行う。登録手続きを経たユーザすなわちプレーヤに対して固有のアカウントを発給し、ユーザ登録データ５３０をサーバ記憶部５００ｓに生成してその管理を行う。また、ログインに関する処理を実行する。

ユーザ登録データ５３０は、例えば図１３に示すように、アカウント５３１と、単数または複数のプレーヤデッキデータ５３２と、獲得済キャラクタＩＤリスト５３６と、推奨キャラクタ登録データ５３８と、停止条件データ５４０と、プレイ履歴データ５４２と、を含む。勿論、これら以外のデータも含めることができる。

１つのプレーヤデッキデータ５３２は、デッキを構成するキャラクタを定義する単数または複数のデッキ構成キャラクタデータ５３４を含む。１つのデッキ構成キャラクタデータ５３４は、登録順位と、キャラクタＩＤと、当該キャラクタの属性と、キャラクタの各種能力パラメータ値を格納する。能力パラメータ値は、例えば、キャラクタの成長度合いや進化度合いを示すレベル、ＨＰ（ヒットポイント、体力値）、攻撃力、防御力などであってゲーム内容に応じて適宜設定される。

獲得済キャラクタＩＤリスト５３６は、当該プレーヤが有しているキャラクタの識別情報のリストである。新たに取得したキャラクタの識別情報は、オンラインショッピングで購入、無料抽選での獲得、課金抽選での獲得、トレーディングカードが担持するキャラクタＩＤの登録、既に有しているキャラクタの育成や合成、の各方法にかかわらず登録される。

推奨キャラクタ登録データ５３８は、推奨キャラクタが判定される都度、推奨キャラクタ毎に生成される。一つの推奨キャラクタ登録データ５３８は、推奨キャラクタのキャラクタＩＤと、当該推奨キャラクタのデッキ編入が必要と判断されたゲームステージのステージＩＤとを含む。推奨キャラクタの登録は、当該推奨キャラクタが獲得済キャラクタＩＤリスト５３６に新たに登録されると抹消される。つまり、対応する推奨キャラクタをアカウント５３１のプレーヤが獲得すると抹消される。

停止条件データ５４０は、第２のサポート機能に関連するデータであって、課金抽選の連続実行を停止させるための条件を定義する。本実施形態では、連続実行する上限抽選回数と、獲得対象とする推奨キャラクタＩＤとを格納する。推奨キャラクタＩＤは、課金抽選が実行される都度、課金抽選で得られた付与キャラクタ（付与オブジェクト）と照合され、一致した場合に課金抽選の連続実行が停止される。

プレイ履歴データ５４２は、ゲームプレイ毎に生成される。一つのプレイ履歴データ５４２には、プレイ日時と、プレイしたゲームステージＩＤ、ステージクリア／ゲームオーバーの結果、所要時間、ステージクリアまでの所要攻撃回数、使用したアイテムの種類、ゲーム内課金によるアイテム購入履歴に関する情報、などが格納される。勿論、ゲーム内容に応じてこれら以外の情報を適宜含めることができる。

図１０に戻って、オンラインショッピング管理部２０２は、本実施形形態に登場するキャラクタやアイテムなどのオンラインショッピングを実現する。公知のオンラインショッピングに関する技術を用いることで実現できる。

ゲーム管理部２１０は、ゲームプレイに関する各種処理を実行する。本実施形態では、無料抽選部２１２と、課金抽選部２１４と、キャラクタＩＤ登録制御部２１６と、合成制御部２１８と、ゲーム実行部２２０と、サポート制御部２３０と、を含む。

無料抽選部２１２は、無料でランダム抽選を実行してプレーヤに付与する付与キャラクタ（付与オブジェクト）を決定する。公知の技術を適宜利用することで実現できる。

課金抽選部２１４は、所定の課金を行い、その対価としてランダム抽選によって付与オブジェクトを選択しプレーヤに付与する、いわゆる課金抽選、有料抽選を実行する。

キャラクタＩＤ登録制御部２１６は、トレーディングカードに担持されているキャラクタＩＤを登録するための制御を行う。

ゲーム実行部２２０は、本実施形態のゲームをプレーヤ端末１５００でプレイするための様々な情報管理と情報提供に係る処理を実行する。例えば、（１）プレーヤによる操作入力に応じて戦闘ゲームで使用するデッキを編集する制御、（２）パズルゲームの実行制御、（３）パズルゲームにおけるプレイ成績に応じて戦闘ゲームでのプレーヤキャラクタ４の行動力を算出する処理、（４）戦闘ゲームの実行制御、に係る各種演算処理を実行する。

合成制御部２１８は、戦闘ゲームに登場するキャラクタの合成に関する制御をする。
サポート制御部２３０は、前述の第１のサポート機能〜第４のサポート機能を実現するための各種処理を実行する。本実施形態では、サポート是非判定部２３１と、推奨キャラクタ判定部２３２と、合成生成可否判定部２３４と、推奨キャラクタ報知制御部２３６と、課金抽選制御部２３８と、取得時報知制御部２３９と、を有する。

サポート是非判定部２３１は、第１のサポート機能〜第４のサポート機能の実行の是非、サポートの要否を判定する。肯定判定（是：サポート要）された場合に、サポート制御部２３０は、第１のサポート機能〜第４のサポート機能を実現するための処理を実行し、否定判定された場合は実行しない。

サポート是非判定部２３１の判定基準は、プレーヤのユーザ登録データ５３０に格納されるデータから判定される条件を適宜設定可能である。例えば、プレイ履歴データ５４２には、ゲーム内課金による購入履歴が含まれるので課金率を算定できる。よって、高課金率認定基準値を予め設定しておいて、当該基準値を超える場合には否定、超えなければ肯定判定するとしてもよい。勿論この逆でも良い。また、同様に低課金率認定基準値を設けても良い。また、基準値所要時間についても、所定の長時間認定基準値を予め設定しておいて、最新所定回数のプレイの所要時間平均が当該基準値を超える場合には肯定、超えなければ否定と判定するとしてもよいであろう。同様に、アイテムの使用回数、使用されたアイテムの種類、クリアに要した攻撃回数などに基づいて是非を判定するとしてもよい。

推奨キャラクタ判定部２３２は、対戦相手オブジェクト群を構成するオブジェクトの属性と、プレーヤの自オブジェクト群を構成するオブジェクトの属性とに基づいて、ゲームステージの攻略に際して自オブジェクト群への編入を推奨する推奨オブジェクトを判定する。本実施形態では、プレーヤのデッキに不足する推奨属性の判定と、推奨属性を有しプレーヤのデッキに編入するべき推奨キャラクタを判定することができる。そして、推奨キャラクタ登録データ５３８（図７）に登録する。

合成生成可否判定部２３４は、プレーヤが既に有しているキャラクタの情報を照査し、それらのキャラクタを合成することで推奨キャラクタを生成することが可能か否かを判定する。具体的には、記憶部５００ｓに合成設定データ５１２が記憶されている。当該データには、合成する複数のキャラクタの組み合わせの情報と、合成によって生成される合成キャラクタの情報とが格納されている。合成生成可否判定部２３４は、合成キャラクタが推奨キャラクタに一致し、当該合成キャラクタに対応する合成する複数のキャラクタの組み合わせが、獲得済キャラクタＩＤリスト５３６に含まれていれば生成可能と肯定判定する。

推奨キャラクタ報知制御部２３６は、推奨キャラクタ（推奨オブジェクト）をプレーヤに向けて報知する制御を行う。
本実施形態では、通信可能に接続されたプレーヤ端末１５００に推奨キャラクタを通知して当該プレーヤ端末１５００にて表示させるための制御を行う。
その際、獲得済キャラクタＩＤリスト５３６を照査して、当該リストに推奨キャラクタが含まれていなければ「未入手」である旨の報知を行い、含まれていれば「入手済」である旨報知するとともに、当該推奨オブジェクトをデッキへ編入するように推奨する報知を行う推奨報知制御を行うことができる。
また、合成生成可否判定部２３４により可能と判定された場合には、推奨キャラクタが合成により入手可能である旨の報知と、合成するキャラクタの組み合わせを報知するための制御を行うことができる。

課金抽選制御部２３８は、プレーヤが予め設定した停止条件を満たすまで、課金抽選部２１４による抽選を自動実行制御する。
本実施形態では、所定操作を検出すると、自動連続実行条件を設定する画面を表示制御する。当該画面では、上限抽選回数の入力欄（または上限金額の入力欄）と、推奨キャラクタ登録データ５３８の示す推奨キャラクタの中から獲得対象とするキャラクタを選択する選択欄とを表示する。そして、入力結果や選択結果を停止条件データ５４０に格納する。そして、プレーヤの操作指示に従って停止条件が満たされたのを検出するまで課金抽選を実行させる。具体的には、所与の上限抽選回数に到達、或いは、推奨オブジェクトが課金抽選よる付与オブジェクトとして選択される、の何れかが成立するまで抽選を実行させる。

取得時報知制御部２３９は、推奨オブジェクトをプレーヤが獲得した場合、換言すれば、獲得済キャラクタＩＤリスト５３６に推奨キャラクタのＩＤが新たに記憶された場合に、当該推奨オブジェクトをプレーヤのデッキ（自オブジェクト群）に編入してゲームステージを攻略することを推奨する報知を行う。

画像生成部２７２ｓは、サーバシステム１１００の保守に関する画像を生成し、画像表示部３７２ｓへ出力することができる。

画像表示部３７２ｓは、画像生成部２７２ｓから入力される画像信号に基づいてシステム管理のための各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図１のタッチパネル１１０８がこれに該当する。

通信制御部２７４ｓは、データ通信に係るデータ処理を実行し、通信部３７４ｓを介して外部装置とのデータのやりとりを実現する。

通信部３７４ｓは、通信回線Ｎと接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。図１の通信装置１１５３がこれに該当する。

サーバ記憶部５００ｓは、サーバ処理部２００ｓにサーバシステム１１００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームを管理するために必要なプログラム、各種データ等を記憶する。また、サーバ処理部２００ｓの作業領域として用いられ、サーバ処理部２００ｓが各種プログラムに従って実行した演算結果などを一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図１では本体装置１１０１が搭載するＩＣメモリ１１５２やハードディスクなどの記憶媒体、及びストレージ１１４０がこれに該当する。

図１１は、サーバ記憶部５００ｓに記憶されるプログラムやデータの例を示す図である。
本実施形態のサーバ記憶部５００ｓは、サーバシステムプログラム５０１と、アカウント管理プログラム５０３と、オンラインショッピング管理プログラム５０５と、ゲーム管理プログラム５０７と、配信用ゲームクライアントプログラム５０９と、を予め記憶する。
また、キャラクタ初期設定データ５１０と、合成設定データ５１２と、ゲームステージ初期設定データ５２０とが予め記憶される。
また、ユーザ登録やゲーム進行に応じて生成・管理されるデータとして、ユーザ登録データ５３０と、プレイデータ５６０と、データベース５５０とが記憶される。また、その他、タイマやカウンタ、各種フラグなどの情報が適宜記憶される。

サーバシステムプログラム５０１は、サーバ処理部２００ｓが読み出して実行することでサーバシステム１１００にコンピュータとして必要な基本的な入出力機能を実現する為のシステムプログラムである。

アカウント管理プログラム５０３は、サーバ処理部２００ｓが読み出して実行することで、アカウント管理部２０１としての機能を実現させるためのプログラムである。

オンラインショッピング管理プログラム５０５は、サーバ処理部２００ｓが読み出して実行することで、オンラインショッピング管理部２０２としての機能を実現させるためのプログラムである。

ゲーム管理プログラム５０７は、サーバ処理部２００ｓが読み出して実行することで、ゲーム管理部２１０としての機能を実現させるためのプログラムである。

配信用ゲームクライアントプログラム５０９は、プレーヤ端末１５００へ提供されるゲームクライアントプログラム５０４（図１４参照）のオリジナルである。

キャラクタ初期設定データ５１０は、ゲームに登場するキャラクタ毎に設定される。プレーヤが取得することのできるキャラクタ及び敵キャラクタ５に関する基礎的なデータとなる。１つのキャラクタ初期設定データ５１０は、キャラクタＩＤと、キャラクタ表示用データ（キャラクタを表示・動作させるためのデータ、例えばキャラクタオブジェクトのモデルデータや、モーションデータなど）と、初期状態の能力パラメータ値とを格納する。

合成設定データ５１２は、キャラクタ合成の条件と合成結果との組み合わせ毎に用意される。一つの合成設定データ５１２は、合成に必要なキャラクタを定義する所要キャラクタＩＤリストと、合成結果としてプレーヤに付与されるオブジェクトを定義する合成キャラクタＩＤとを含む。

ゲームステージ初期設定データ５２０は、戦闘ゲームのゲームステージ毎に用意される。
例えば、図１２に示すように、ステージＩＤ５２１と、敵デッキデータ５２２と、ゲームステージとなるゲーム空間を構成・表示するためのゲーム空間初期設定データ５２７と、を含む。

敵デッキデータ５２２は、敵キャラクタ群を定義するデータである。ゲームステージの最後に待ち構えるボスキャラクタの一つのデッキとして定義される。
一つの敵デッキデータ５２２は、当該ゲームステージにおける出現順番５２３と、当該デッキを構成する敵キャラクタを定義する単数または複数のデッキ構成キャラクタデータ５２４とを含む。１つのデッキ構成キャラクタデータ５２４は、登録順位と、敵キャラクタ５となるキャラクタＩＤと、当該キャラクタの属性と、キャラクタの各種能力パラメータ値とを格納する。

図１１に戻って、ユーザ登録データ５３０は、前述のようにアカウント管理部２０１により、ユーザ登録したプレーヤ毎に用意される。例えば図１３に示すように、一つのユーザ登録データ５３０は、ユーザすなわちプレーヤのアカウント５３１と、プレーヤデッキデータ５３２と、獲得済キャラクタＩＤリスト５３６と、推奨キャラクタ登録データ５３８と、停止条件データ５４０とを含む。

図１１に戻って、プレイデータ５６０は、本実施形態のゲームがプレイされる毎に用意され、各ゲームの進行状況を記述する各種データを格納する。

［プレーヤ端末の機能構成の説明］
図１４は、本実施形態におけるプレーヤ端末１５００の機能構成の一例を示す機能ブロック図である。本実施形態のプレーヤ端末１５００は、操作入力部１００と、処理部２００と、音出力部３７０と、画像表示部３７２と、通信部３７４と、記憶部５００とを備える。

操作入力部１００は、自プレーヤによって為された各種の操作入力に応じて操作入力信号を処理部２００に出力する。例えば、プッシュスイッチや、ジョイスティック、タッチパッド、トラックボール、加速度センサ、ジャイロ、ＣＣＤモジュール、などによって実現できる。図２の方向入力キー１５０２や、ボタンスイッチ１５０４、タッチパネル１５０６がこれに該当する。

処理部２００は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や記憶部５００を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００からの操作入力信号、サーバシステム１１００から受信した各種データに基づいて各種の演算処理を実行して、プレーヤ端末１５００の動作を制御する。図２の制御基板１５５０がこれに該当する。そして、本実施形態における処理部２００は、プレーヤ端末演算部２６０と、音生成部２７０と、画像生成部２７２と、通信制御部２７４とを備える。

プレーヤ端末演算部２６０は、操作信号送信制御部２６１と、ゲーム画面表示制御部２６２とを含み、適宜計時等のその他の機能に係る処理を行う。

操作信号送信制御部２６１は、操作入力部１００へ為された操作に応じて、各種データやリクエストをサーバシステム１１００へ送信するための処理を実行する。

ゲーム画面表示制御部２６２は、サーバシステム１１００から受信した各種データに基づいてゲーム画面を表示するための制御を行う。当該構成では、ゲーム空間画像（例えば、３ＤＣＧなど）をサーバシステム１１００にて生成する構成とするが、ゲーム空間画像をプレーヤ端末１５００で生成する構成も可能である。その場合、ゲーム画面表示制御部２６２は、３ＤＣＧを生成するための仮想３次元空間に配置されたオブジェクトの制御を含むこととなる。

本実施形態では、推奨キャラクタに係る報知をゲーム画面での表示により実現するので、ゲーム画面表示制御部２６２は、報知３０（図５）、報知３２（図８）、報知３６（図９）の表示制御をする推奨報知表示制御部２６４として機能する。

音生成部２７０は、例えばデジタルシグナルプロセッサ（ＤＳＰ）や、音声合成ＩＣなどのプロセッサ、音声ファイル再生可能なオーディオコーデック等によって実現され、ゲーム画面表示制御部２６２による処理結果に基づいてゲームに係る効果音やＢＧＭ、各種操作音の音信号を生成し、音出力部３７０に出力する。

音出力部３７０は、音生成部２７０から入力される音信号に基づいて効果音やＢＧＭ等を音出力する装置によって実現される。図２のスピーカ１５１０がこれに該当する。

画像生成部２７２は、例えば、ＧＰＵ、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、ビデオ信号ＩＣ、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。
そして、画像生成部２７２は、プレーヤ端末演算部２６０による処理結果に基づいて１フレーム時間（例えば１／６０秒）で１枚のゲーム画面の画像を生成し、生成したゲーム画面の画像信号を画像表示部３７２に出力する。

画像表示部３７２は、画像生成部２７２から入力される画像信号に基づいて各種ゲーム画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。本実施形態では、図２のタッチパネル１５０６がこれに該当する。

通信制御部２７４は、データ通信に係るデータ処理を実行し、通信部３７４を介して外部装置とのデータのやりとりを実現する。通信部３７４は、通信回線Ｎと接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現され、図２の無線通信モジュール１５５３がこれに該当する。

記憶部５００は、処理部２００にプレーヤ端末１５００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームプレイに必要なプログラム、各種データ等を記憶する。また、処理部２００の作業領域として用いられ、処理部２００が各種プログラムに従って実行した演算結果や操作入力部１００から入力される入力データ等を一時的に記憶する。こうした機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図２の制御基板１５５０が搭載するＩＣメモリ１５５２やメモリカード１５４０がこれに該当する。

本実施形態の記憶部５００には、端末システムプログラム５０２と、ゲームクライアントプログラム５０４とが記憶される。

端末システムプログラム５０２は、プレーヤ端末１５００のコンピュータとしての入出力の基本機能を実現するためのプログラムである。

ゲームクライアントプログラム５０４は、処理部２００が読み出して実行することによってプレーヤ端末演算部２６０としての機能を実現させるためのアプリケーションソフトであるが、端末システムプログラム５０２の一部として組み込まれた構成であっても良い。ゲームクライアントプログラム５０４は、オンラインゲームを実現する技術手法に応じて専用のクライアントプログラムであっても良いし、ウェブブラウザプログラム及びインタラクティブな画像表示を実現するプラグインなどにより構成するとしても良い。

ゲームクライアントプログラム５０４は、ゲームステージ初期設定データ５２０やキャラクタ初期設定データ５１０とともに、サーバシステム１１００からダウンロードして記憶される。

［処理の流れの説明］
図１５〜図１７は、本実施形態におけるサーバシステム１１００のサポート機能に係る処理の流れについて説明するためのフローチャートである。ここで説明する処理の流れは、サーバ処理部２００ｓがサーバシステムプログラム５０１を実行した状態で、ゲーム管理プログラム５０７を実行することにより実現される。そして、サーバシステム１１００が起動している間、プレーヤがログアウトするまで繰り返し実行される。

図１５に示すように、サーバシステム１１００のサーバ処理部２００ｓは、プレーヤ端末１５００からゲーム開始リクエストを受信すると、プレーヤの選択操作に応じて戦闘ゲームでプレイするゲームステージを選択しゲーム実行処理をする（ステップＳ２）。

ゲームが終了し、その結果がゲームクリアであれば（ステップＳ４のＹＥＳ）、当該プレイにおけるクリア事例過程データ５５１をデータベース５５０に新たに追加するとともに、当該プレーヤのプレーヤデッキデータ５３２（図１３）をデータベース５５０に新たなクリア事例デッキデータ５５２（図１１）として追加する（ステップＳ６）。

次に、プレーヤ端末１５００から第１のサポートを要求する第１サポートリクエストを受信すると（ステップＳ１０のＹＥＳ）、サーバシステム１１００のサーバ処理部２００ｓは、サポートの是非判定処理を実行する。肯定判定すなわちサポート要と判定されたならば（ステップＳ１１のＹＥＳ）、データベース５５０のクリア事例デッキデータ５５２の登録数をカウントする。

そして、登録数が統計的に有意な所定の基準値に達していれば（ステップＳ１２のＹＥＳ）、クリア事例デッキデータ５５２を統計処理して基準となる属性配分「統計ベース基準属性配分」を求める（ステップＳ１４）。本実施形態では、クリア事例デッキデータ５５２の中で最も多い最多属性配分を求めることとするが、多い順に所定順位まで求めるとしても良い。

そして、サーバシステム１１００は、プレーヤデッキデータ５３２を参照してプレーヤのデッキにおける属性配分を求め（ステップＳ２０）、先に求めた統計ベース基準属性配分と比較して推奨属性を判定する（ステップＳ２２）。例えば、統計ベース基準属性配分には有るが、プレーヤデッキの属性配分に無い属性を推奨属性と判定する。あるいは、両属性配分における各属性の数を比較して、前者より後者が数で劣っている属性を推奨属性と判定するとしてもよい。あるいは、これらの判定方法の両方を適用してもよい。

もし、登録数が統計的に有意な所定の基準値に達していなければ（ステップＳ１２のＮＯ）、直前にプレイしたゲームステージのゲームステージ初期設定データ５２０の敵デッキデータ５２２（図１２）に基づいて基準となる属性配分「敵デッキ属性配分」を求める（ステップＳ３０）。
そして、サーバシステム１１００は、プレーヤデッキデータ５３２を参照してプレーヤのデッキにおける属性配分「プレーヤデッキ属性配分」を求め（ステップＳ３２）、先に求めた敵デッキ属性配分とプレーヤデッキ属性配分とを比較して推奨属性を判定する（ステップＳ３４）。例えば、敵デッキの敵キャラクタ毎にその属性に対して優位な属性を判定し、判定した優位な属性のうちプレーヤデッキ属性配分に含まれていないものを推奨属性とする。

ステップＳ２２またはステップＳ３４によって推奨属性を判定したならば、サーバシステム１１００は、次にキャラクタ初期設定データ５１０（図１１）から、判定した推奨属性に該当するキャラクタ、すなわち推奨キャラクタを検索し、検索された推奨キャラクタのＩＤを含む推奨キャラクタ登録データ５３８（図１３）を生成する（ステップＳ４０）。

そして、サーバシステム１１００は、判定した推奨属性と検索された推奨キャラクタとの情報をプレーヤに知らせる報知３０（図５）をプレーヤ端末１５００で行わせる（ステップＳ４２）。

図１６のフローチャートに移って、サーバシステム１１００は第３のサポート機能に係る処理として、合成設定データ５１２（図１１）を参照して、今回検索された推奨キャラクタが、合成キャラクタとして設定されているかを判定する。そして、当該判定が肯定ならば（ステップＳ５０のＹＥＳ）、サーバシステム１１００は、合成設定データ５１２から推奨キャラクタの合成に要する所要キャラクタのＩＤを参照し、ユーザ登録データ５３０の獲得済キャラクタＩＤリスト５３６と照合する（ステップＳ５２）。

獲得済キャラクタＩＤリスト５３６に推奨キャラクタの合成に要する所要キャラクタが登録されていれば、推奨キャラクタを合成するのに必要な全てのキャラクタは入手済みであると見なし（ステップＳ５４のＹＥＳ）、サーバシステム１１００は、プレーヤ端末１５００にて推奨キャラクタが手持ちのキャラクタの合成により入手できる旨告げる報知３２（図８）を表示させる（ステップＳ５６）。

もし、プレーヤ端末１５００からキャラクタ合成のリクエストを受信したならば（ステップＳ７０のＹＥＳ）、サーバシステム１１００はキャラクタの合成処理を実行する（ステップＳ７２）。キャラクタの合成処理は、公知技術により実現できるので詳細な説明は省略する。合成されたキャラクタのキャラクタＩＤは、獲得済キャラクタＩＤリスト５３６に格納される。

これで推奨キャラクタが使用可能になったので、サーバシステム１１００は、推奨キャラクタの入手完了を告げる報知３６（図９）をプレーヤ端末１５００にて表示させ（ステップＳ７４）、合成した推奨キャラクタの推奨キャラクタ登録データ５３８を抹消する（ステップＳ７６）。

プレーヤ端末１５００から課金抽選のリクエストを受信した場合は（ステップＳ９０のＹＥＳ）、サーバシステム１１００のサーバ処理部２００ｓは、第２のサポート機能に係る処理を実行する。

すなわち、プレーヤ端末１５００にて自動課金抽選の停止条件設定画面３４（図７）を表示させる停止条件を設定する処理を実行する（ステップＳ９２）。当該画面での入力の結果をプレーヤ端末１５００から受信すると、サーバシステム１１００はユーザ登録データ５３０に停止条件データ５４０を生成する。

そして、プレーヤ端末１５００から所定の抽選実行リクエストを受信したならば、サーバシステム１１００は停止条件データ５４０で定義された停止条件が満たされるまで課金抽選の連続実行を開始する（ステップＳ９４）。課金抽選にともなう課金に係る処理は公知技術と同様である。また、課金抽選により得られたキャラクタ（付与オブジェクト）は、自動的に獲得済キャラクタＩＤリスト５３６（図１３）に登録される。

次に、第４のサポート機能に係る処理として、サーバシステム１１００は推奨キャラクタ登録データ５３８のキャラクタＩＤを、獲得済キャラクタＩＤリスト５３６と照合する（ステップＳ９６）。
そして、当該リストに推奨キャラクタが含まれていれば、推奨キャラクタの入手が完了したと見なし（ステップＳ９８のＹＥＳ）、サーバシステム１１００は、当該リストに含まれていた推奨キャラクタの入手完了を告げる報知３６（図９）をプレーヤ端末１５００にて表示させ（ステップＳ１００）、当該リストに含まれていた推奨キャラクタの推奨キャラクタ登録データ５３８を抹消する（ステップＳ１０２）。

図１７のフローチャートに移って、プレーヤ端末１５００からプレーヤデッキの編集リクエストを受信した場合は（ステップＳ１２０のＹＥＳ）、サーバシステム１１００は、プレーヤの操作入力に応じてプレーヤデッキの構成を変更するための処理を実行する（ステップＳ１２２）。

ステップＳ２〜Ｓ１２２は、プレーヤがログアウトするまで繰り返される（ステップＳ１３０）。

以上、本実施形態によれば、相互の組み合わせで有利／不利の相性関係が生じる属性の何れかが付与されたキャラクタを編成してデッキ（チーム、手札群）を用いるゲームにおいてゲーム攻略に関する情報を提供し、ユーザビリティを向上させる

〔第２実施形態〕
次に、本発明を適用した第２実施形態について説明する。なお、以降では主に第１実施形態との差異について述べることとし、同様の構成要素については同じ符号を付与して説明は省略するものとする。

第１実施形態が、ゲーム実行とサポート機能に係る演算をサーバシステム１１００にて実行する構成であったのに対して、本実施形態は各プレーヤ端末１５００にて実行する構成である。

図１８は、本実施形態におけるサーバシステム１１００の機能構成例を示す機能ブロック図である。本実施形態のサーバ処理部２００ｓは、オンラインショッピング管理部２０２と、データベース管理部２５０と、統計ベース基準属性配分判定部２５２と、画像生成部２７２ｓと、通信制御部２７４ｓとを有する。

データベース管理部２５０は、クリアされたゲームステージＩＤと、そのときのプレーヤデッキデータ５３２と、プレイ履歴データ５４２とをプレーヤ端末１５００から受信して、前者をクリア事例デッキデータ５５２として、後者をクリア事例過程データ５５１として追加登録する。データベース管理部２５０は、サーバ処理部２００ｓがデータベース管理プログラム５９０を実行することにより実現される。

統計ベース基準属性配分判定部２５２は、第１実施形態のステップＳ１２〜Ｓ１４に相当する処理を実行する機能部であって、データベース５５０に登録されているクリア事例デッキデータ５５２の登録数が基準値に達している場合に、統計処理して統計ベース基準属性配分（図５）を判定し、プレーヤ端末１５００へ提供する制御を行う。もし、クリア事例デッキデータ５５２の登録数が基準値に達していなければ、提供できない旨の所定信号をプレーヤ端末１５００へ送信する。なお、統計ベース基準属性配分判定部２５２は、サーバ処理部２００ｓが統計ベース基準属性配分判定プログラム５９２を実行することにより実現される。

図１９は、本実施形態におけるプレーヤ端末１５００の機能構成例を示す機能ブロック図である。図２０は、本実施形態における記憶部５００に記憶されるプログラムやデータの例を示す図である。

本実施形態の処理部２００には、第１実施形態におけるプレーヤ端末演算部２６０に代えて、アカウント管理部２０１と、ゲーム管理部２１０Ｂとが含まれる。

ゲーム管理部２１０Ｂは、第１実施形態におけるゲーム管理部２１０に相当するが、サポート制御部２３０に代えてサポート制御部２３０Ｂを有する。そして、サポート制御部２３０Ｂは、基本的には第１実施形態のサポート制御部２３０と同様の機能を有するが、本実施形態のサーバシステム１１００から推奨オブジェクトの識別情報を受信する制御を行うことができる。更にクリア事例データ提供部２４２と、推奨属性判定基準情報取得部２４４とを有する。

クリア事例データ提供部２４２は、ゲームプレイ終了時に当該ゲームプレイに関する情報をサーバシステム１１００へ提供する。具体的には、ゲームをクリアした場合に、プレーヤデッキデータ５３２と、最新のプレイ履歴データ５４２と、クリアしたゲームステージＩＤとをサーバシステム１１００へ送信するための処理をする。

推奨属性判定基準情報取得部２４４は、推奨属性を判定するための基準となる情報をサーバシステム１１００から取得するための制御を行う。具体的には、統計ベース基準属性配分５９４（図２０）の情報取得に係る制御をする。

ゲーム管理プログラム５０７Ｂは、ゲーム管理部２１０Ｂとしての機能を処理部２００にて実現させるためのプログラムである。

図２１〜図２３は、本実施形態におけるプレーヤ端末１５００のサポート機能に係る処理の流れを説明するためのフローチャートである。
基本的には、第１実施形形態における図１５〜図１７のフローチャートと同様の流れを有するが、各リクエストに関するステップ（例えば、ステップＳ１０、ステップＳ７０、ステップＳ９０、ステップＳ１２０）についてはプレーヤ端末１５００で各リクエストの検出と読み替えるものとする。

また、本実施形態がゲーム実行とサポート機能をプレーヤ端末１５００にて実行する構成であることから、第１実施形態のステップＳ６に代えて、プレーヤ端末１５００がプレーヤデッキデータ５３２（図１３参照）と、そのときクリアしたゲームステージのステージＩＤ５２１（図１２参照）とをサーバシステム１１００へ送信する（ステップＳ７）。

また、第１実施形態のステップＳ１２〜Ｓ１４は省略され、プレーヤ端末１５００の処理部２００は、統計ベース基準属性配分の情報をサーバシステム１１００へ要求し（ステップＳ１６）、統計ベース基準属性配分が返信されてくれば（ステップＳ１８のＹＥＳ）、ステップＳ２０〜Ｓ２２を実行する。もし、統計ベース基準属性配分が返信されなければ（ステップＳ１８のＮＯ）、ステップＳ３０〜Ｓ３４を実行する。
本実施形態においても、第１実施形態と同様の効果が得られる。

〔変形例〕
以上、本発明を適用した実施形態について説明したが、本発明の形態はこれらに限定されるものではなく、適宜構成要素の追加・省略・変更を施すことができる。

［その１］
例えば、サポート機能の全てを、第１実施形態ではサーバシステム１１００にて実行し、第２実施形態ではプレーヤ端末１５００にて実行する構成としたが、サーバシステム１１００とプレーヤ端末１５００とに機能を分散させることもできる。

具体的には、第２実施形をベースとすれば、図２４，図２５に示すように、推奨キャラクタ判定部２３２をサーバシステム１１００にて実現する構成が可能である。

当該構成では、サーバシステム１１００は、プレーヤ端末１５００からのリクエストに応じて第１実施形態におけるステップＳ１２〜Ｓ４０に相当する処理を実行し、推奨属性と推奨キャラクタに関する情報をプレーヤ端末１５００へ提供することができる。
当然、プレーヤ端末１５００では第２実施形態のように統計ベース基準属性配分を取得するのではなく、推奨属性と推奨キャラクタとを取得できることになる。つまり、当該構成の場合、図２６に示すように、図２１のステップＳ１６〜Ｓ４０に代えて、プレーヤ端末１５００は推奨属性と推奨キャラクタの情報をサーバシステム１１００へリクエストし取得する処理（ステップＳ４１）に置き換えすれば良いことになる。

［その２］
また、第２実施形態のプレーヤ端末１５００は、スマートフォンとしての形態を有していたが、その他のコンピュータ、例えば電子機器の形態であってもよい。例えば、制御基板を搭載した装置本体と、当該装置本体と無線接続される複数台のタッチパネル搭載型ゲームコントローラとを備えた構成据え置き型家庭用ゲーム装置とすることもできる。当該構成の場合、装置本体を上記実施形態の制御基板１５５０相当とし、ゲームコントローラを無線通信式のタッチパネル１５０６と見立てればよい。よって、据え置き型家庭用ゲーム装置の機能構成は、図１９〜図２０と同様となる。

［その３］
同様に、プレーヤ端末１５００をアーケードゲーム装置（業務用ゲーム装置）としての形態を有するとしてもよい。その場合、アーケードゲーム装置は、キャラクタに係るデータを担持するトレーディングカードからデータを読み取る装置を搭載し、トレーディングカードから読み取ったキャラクタＩＤに基づいてプレイ毎にプレーヤデッキを構成するとしてもよい。この場合、読み取ったデータに基づくキャラクタをプレーヤの手札とすると好適である。

［その４］
また、上記実施形態のパズルゲームは、その他のジャンルのゲーム、例えば仮想のメダルゲームやシューティングゲームなどとすることもできる。更には、パズルゲームを省略した構成も可能である。対戦ゲームについても、ＲＰＧ風の戦闘ゲームに限らず、プレーヤが有する手札でデッキを構成して対戦する要素を含むならば、格闘ゲームタイプやシューティングゲームタイプなどその他のタイプのゲームであってもよい。

［その５］
また、上記実施形態ではオブジェクトとしてキャラクタを例に挙げたが、ゲーム内容に応じて適宜変更可能である。例えば、武器などのアイテム類、乗り物、パーツ、などとすることもできる。より具体的には、戦闘ゲームの代わりにレースゲームとし、プレーヤは自レーシングカーに、コースの特性（コーナリング重視コース、直線重視コース、コーナリング＋直線のミックスコース、など）に対応するパーツ（タイヤ、ブレーキ、エンジン、空力パーツのセッティングなど）を組み合わせてセッティングしてプレイするものとする。この場合、パーツをオブジェクト、コースの特性を属性とすればよい。

［その６］
また、上記実施形態では第１のサポート機能の発動は、プレーヤによる第１サポートを求める所定の操作入力を必要としたが（図１５のステップＳ１０）これに限らない。例えば、ステップＳ１０を省略し、第１のサポート機能は常時実行されることとしてもよい。また、第１のサポート機能の発動は、ゲーム開始前であってもよい。
更には、ゲーム内のイベント発生タイミングや、何らかの操作の区切りに第１のサポート機能を発動させるとしてもよい。ゲーム内容によっては、それは新たな戦闘を開始するタイミングであったり、他プレーヤとのアイテムの交換をするタイミングとすることができるであろう。

［その７］
また、上記実施形態のデータベース５５０については、クリア事例を追加登録する構成ではなく、予めゲーム管理者やゲーム制作者が用意したクリア事例の雛形が格納されている構成に置換することができる。この場合、データベース５５０の管理に係る機能を省略して処理負荷を低減できる。

２…プレーヤ
４…プレーヤキャラクタ
５…敵キャラクタ
３０，３２，３６…報知
３４…停止条件設定画面
２００…処理部
２００ｓ…サーバ処理部
２１０，２１０Ｂ…ゲーム管理部
２１４…課金抽選部
２１８…合成制御部
２２０…ゲーム実行部
２３０，２３０Ｂ…サポート制御部
２３２…推奨キャラクタ判定部
２３４…合成生成可否判定部
２３６…推奨キャラクタ報知制御部
２３８…課金抽選制御部
２３９…取得時報知制御部
２４２…クリア事例データ提供部
２４４…推奨属性判定基準情報取得部
２５０…データベース管理部
２５２…統計ベース基準属性配分判定部
２６０…プレーヤ端末演算部
２６１…操作信号送信制御部
２６２…ゲーム画面表示制御部
２６４…推奨報知表示制御部
５００…記憶部
５００ｓ…サーバ記憶部
５０４…ゲームクライアントプログラム
５０７，５０７Ｂ…ゲーム管理プログラム
５１０…キャラクタ初期設定データ
５１２…合成設定データ
５２０…ゲームステージ初期設定データ
５２２…敵デッキデータ
５２４…デッキ構成キャラクタデータ
５３０…ユーザ登録データ
５３２…プレーヤデッキデータ
５３４…デッキ構成キャラクタデータ
５３６…獲得済キャラクタＩＤリスト
５３８…推奨キャラクタ登録データ
５４０…停止条件データ
５５０…データベース
５５２…クリア事例デッキデータ
５９０…データベース管理プログラム
５９２…統計ベース基準属性配分判定プログラム
５９４…統計ベース基準属性配分
１１００…サーバシステム
１１０１…本体装置
１１４０…ストレージ
１１５０…制御基板
１５００…プレーヤ端末
１５５０…制御基板
１５５３…無線通信モジュール

Claims (3)

1. 登場する単数又は複数の対戦相手オブジェクト（以下包括して「対戦相手オブジェクト群」という）が予め定められたゲームをプレーヤが選択した単数又は複数の自オブジェクト（以下包括して「自オブジェクト群」という）で攻略する際の攻略情報を提供するコンピュータシステムであって、
   オブジェクトには属性間で有利又は不利の相性関係が定められた何れかの属性が定められており、
   前記ゲームの攻略に成功したプレーヤの前記自オブジェクト群の情報を成功オブジェクト群情報として記憶したデータベースと、
   前記データベースに記憶された前記成功オブジェクト群情報に係るオブジェクトの属性のうち、前記ゲームを攻略しようとするプレーヤの前記自オブジェクト群を構成するオブジェクトの属性にはない属性のオブジェクトを前記推奨オブジェクトとして判定する判定手段と、
   前記推奨オブジェクトを前記プレーヤに向けて報知する制御を行う報知制御手段と、
   を備えたコンピュータシステム。
2. 前記データベースは、前記成功オブジェクト群情報と、当該成功オブジェクト群情報に係る攻略に成功したゲームのプレイ課程とを関連づけて記憶する、
   請求項１に記載のコンピュータシステム。
3. 前記推奨オブジェクトの前記報知を行うか否かを判断する報知是非判断手段を更に備え、
   前記報知制御手段は、前記報知是非判断手段による判断結果が肯定の場合に、前記報知を行う制御をする、
   請求項１又は２に記載のコンピュータシステム。

Images