WO2013183622A1

WO2013183622A1 - ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム、情報処理装置

Info

Publication number: WO2013183622A1
Application number: PCT/JP2013/065445
Authority: WO
Inventors: 鈴木　英之; 暢也北村
Original assignee: 株式会社コナミデジタルエンタテインメント
Priority date: 2012-06-04
Filing date: 2013-06-04
Publication date: 2013-12-12
Also published as: JP5529923B2; JP2013248315A

Abstract

　本発明のゲーム制御装置は、第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する第１情報提供手段と、前記第１ゲームと、前記ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報を取得する取得手段と、前記関連度に関する情報に基づいて、前記ユーザに対する前記第１情報の情報量を制限する制限手段と、を備える。

Description

ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム、情報処理装置

　本発明は、ユーザの操作に基づいて、当該ユーザによるゲームやアプリケーション等のソフトウェアの利用を制御する技術に関する。

　近年、ソーシャルネットワーキングサービス（ＳＮＳ）において実行されるアプリケーションとして、いわゆるソーシャルゲーム（Social Game）が普及している。

　上述したソーシャルゲームの一例として、非特許文献１に開示されているデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。この公知のデジタルカードゲームは、ユーザが様々なエリアを探索して新たなカードやアイテムを取得するクエスト処理を行うメニューが設けられている。ソーシャルゲームでは、例えば、他のユーザ（仲間）との協力プレイのほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。

アプリＳＴＹＬＥ　Vol.5（株式会社イースト・プレス）、7-8頁

　従来のソーシャルゲームでは、例えばゲームを初めて実行するユーザに対して、当該ゲームの仕様を説明するためのチュートリアルを行うように構成されている。ところで、従来のソーシャルゲームでは、例えば単なる釦の押下操作などの簡易な操作でゲームを進行させるものが多く存在し、それ故、ユーザは、例えば操作手順などの仕様が関連又は共通する複数のゲームの各々を、同じような操作手順で実行することができる。ここで、例えば、ユーザが、互いに仕様が関連又は共通する２つのゲームのうち一方のゲームを実行した後に他方のゲームを初めて実行する場合に、当該ユーザに対して他方のゲームにおけるチュートリアルが行われると、当該ユーザは、既に理解している仕様について再度説明を受けることになる。この場合、ユーザは、他方のゲームを円滑に進行する（つまり、短時間で開始する）ことができないので、仕様の説明に対する煩わしさを感じ、ひいては他方のゲームに対する興味を持たなくなるおそれがある。

　本発明は上述した観点に鑑みてなされたもので、ユーザに対してゲームやアプリケーション等のソフトウェアの仕様を説明する場合に当該ユーザが感じる煩わしさを低減できるようにしたゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム、情報処理装置を提供することを目的とする。

　本発明の第１の観点は、ゲーム制御装置である。
　当該ゲーム制御装置は、
　第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する第１情報提供手段と、
　前記第１ゲームと、前記ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報を取得する取得手段と、
　前記関連度に関する情報に基づいて、前記ユーザに対する前記第１情報の情報量を制限する制限手段と、
　を備える。

　ここで、「仕様」には、例えば、ゲームの操作手順に関する情報や、ゲームの構成に関する情報（例えば、ゲームのコンセプト、ゲーム上の世界観、ゲームのルールなど）や、ゲームの内容に関する情報（例えば、ゲーム上のエリア、キャラクタ、アイテムなどに関する情報）などが含まれてもよい。また、キャラクタとは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカード等に表示されているものをも含む。さらに、アイテムとは、例えば、ユーザがゲーム上保有することができるものであってもよいし、ユーザがゲーム上で収集する必要があるものであってもよいし、ユーザがゲーム上で有利な効果を得られるものなどであってもよい。

　このゲーム制御装置では、第１ゲームを実行するユーザに対して第１ゲームの仕様を説明するための第１情報が提供される際に、第１ゲームと、ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報に基づいて、第１情報の情報量が制限される。この場合、ユーザは、第１ゲームの仕様についての説明を例えば省略することができ、第１ゲームを円滑に進行することができる。これにより、ユーザは、第１ゲームの仕様についての説明に対する煩わしさを低減することができ、さらには、第１ゲームに対するユーザの興味を維持することができる。

　上記ゲーム制御装置において、前記関連度に関する情報に基づいて、前記ユーザに対して前記第１情報を提供するか否かの選択を受け付ける受付手段を備え、前記制限手段は、前記ユーザに対して前記第１情報を提供しないように選択された場合に、前記ユーザに対する前記第１情報の情報量を制限してもよい。
　この場合、例えば、ユーザが第２ゲームの仕様を理解していた場合であっても、ユーザは、第１情報の情報量を制限するか否か、すなわち第１ゲームの仕様について詳しい説明を受けるか否かを自ら選択する仕組みとすることができる。

　上記ゲーム制御装置において、前記取得手段は、前記ユーザによる前記第２ゲームの実行状況に基づいて、前記関連度に関する情報を取得してもよい。
　ここで、「第２ゲームの実行状況」とは、例えば、ユーザが、第２ゲーム上で制覇（クリア）したパートの数であってもよいし、ユーザが、第２ゲーム上の対戦において他のユーザあるいはキャラクタに勝利した数であってもよい。また、「第２ゲームの実行状況」とは、例えば、ユーザが第２ゲーム上で獲得した特定のアイテムの数であってもよいし、第２ゲームの進行度や技能レベルの高さなどであってもよい。
　例えば、ユーザによる第２ゲームの実行状況がある程度進んでいる場合、第２ゲームの仕様に対する当該ユーザの理解度が高いと考えられる。また、第１ゲームと第２ゲームの仕様が関連又は共通する場合には、当該ユーザは、関連度に関する情報に基づいて第１情報の情報量が制限されたとしても、第２ゲームの仕様に基づいて第１ゲームの仕様を想定することが可能である。一方、ユーザによる第２ゲームの実行状況が進んでいない場合、当該ユーザは、第２ゲームの仕様に対する理解度が低いと考えられる。この場合、ユーザは、関連度に関する情報に基づいて第１情報の情報量が制限されると、第１ゲームの仕様を理解することが困難になり、結果として第１ゲームを実行しなくなるおそれがある。
　このゲーム制御装置では、関連度に関する情報を取得するか否か、すなわち関連度に関する情報に基づいて第１情報の情報量を制限するか否かを、ユーザによる第２ゲームの実行状況、すなわち第２ゲームの仕様の理解度に基づいて決定する仕組みとすることができる。

　上記ゲーム制御装置において、前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの実行回数を含み、前記取得手段は、前記ユーザによる前記第２ゲームの実行回数が所定回数以上の場合に、前記関連度に関する情報を取得してもよい。
　例えば、ユーザによる第２ゲームの実行回数が多いほど、第２ゲームの仕様に対する当該ユーザの理解度が高いと考えられる。このゲーム制御装置では、ユーザによる第２ゲームの実行回数が所定回数以上の場合に、関連度に関する情報が取得され、当該関連度に関する情報に基づいて第１情報の情報量が制限される。これにより、第２ゲームの仕様を理解しているユーザは、第１ゲームの仕様についての説明に対する煩わしさを低減することができる。

　上記ゲーム制御装置において、前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間を含み、前記取得手段は、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間が所定時間以内の場合に、前記関連度に関する情報を取得してもよい。
　例えば、ユーザによる第２ゲームの最新の実行時期からの経過時間が短いほど、当該ユーザは第２ゲームの仕様の記憶の程度が高いと考えられる。このゲーム制御装置では、ユーザによる第２ゲームの最新の実行時期からの経過時間が所定時間以内の場合に、関連度に関する情報が取得され、当該関連度に関する情報に基づいて第１情報の情報量が制限される。これにより、第２ゲームの仕様の記憶の程度が高いユーザは、第１ゲームの仕様についての説明に対する煩わしさを低減することができる。

　上記ゲーム制御装置において、前記制限手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの実行状況とに基づいて、前記ユーザに対する前記第１情報の情報量を制限してもよい。
　例えば、第１ゲームと第２ゲームの仕様が関連又は共通し、且つ、ユーザによる第２ゲームの実行状況がある程度進んでいた（つまり、第２ゲームの仕様を理解していた）場合、当該ユーザにとっては、第２ゲームの仕様に基づき第１ゲームの仕様を想定できるので第１情報が不要であり、逆に第１情報が提供されることによって煩わしさを感じることが考えられる。
　このゲーム制御装置によれば、関連度に関する情報と、ユーザによる第２ゲームの実行状況とに基づいて、第１情報の情報量を制限することができるので、例えば第２ゲームの実行状況がある程度進んでいることにより第２ゲームの仕様を理解しているユーザは、第１ゲームの仕様についての説明を例えば省略することができ、当該説明に対する煩わしさを低減することができる。

　上記ゲーム制御装置において、前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの実行回数を含み、前記制限手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの実行回数とに基づいて、前記ユーザに対する前記第１情報の情報量を制限してもよい。
　例えば、ユーザによる第２ゲームの実行回数が多いほど、第２ゲームの仕様に対する当該ユーザの理解度が高いと考えられる。このゲーム制御装置では、例えば、ユーザによる第２ゲームの実行回数が多いほど（第２ゲームの仕様に対する当該ユーザの理解度が高いほど）、第１情報の情報量を多く制限することができる仕組みとすることができる。この場合、ユーザは第１ゲームの仕様についての説明をほぼ省略することができるので、当該ユーザに煩わしさを感じさせないようにすることができる。

　上記ゲーム制御装置において、前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間を含み、前記制限手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間とに基づいて、前記ユーザに対する前記第１情報の情報量を制限してもよい。
　例えば、ユーザによる第２ゲームの最新の実行時期からの経過時間が短いほど、当該ユーザは第２ゲームの仕様の記憶の程度が高いと考えられる。このゲーム制御装置では、例えば、ユーザによる第２ゲームの最新の実行時期からの経過時間が短いほど（第２ゲームの仕様に対する当該ユーザの記憶の程度が高いほど）、第１情報の情報量を多く制限することができる仕組みとすることができる。この場合、ユーザは第１ゲームの仕様についての説明をほぼ省略することができるので、当該ユーザに煩わしさを感じさせないようにすることができる。

　上記ゲーム制御装置において、前記関連度に関する情報に基づいて、前記第２ゲームに関する第２情報を前記ユーザに提供する第２情報提供手段を備えてもよい。
　このゲーム制御装置では、ユーザには、第１ゲームと、当該ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報に基づいて、第２ゲームに関する第２情報が提供される。この場合、ユーザは、第２ゲームの実行経験を有することにより、第２ゲームの仕様を理解していると考えられる。このため、ユーザは、第１情報が提供される際に、第２ゲームの仕様に基づいて第１ゲームの仕様を想定することができる。

　上記ゲーム制御装置において、前記第２情報提供手段は、前記第２ゲームが複数存在する場合に、複数の第２ゲームのうち前記第１ゲームの仕様との関連度が所定の条件を満たすゲームについての前記第２情報を、前記ユーザに提供してもよい。
　例えば、ユーザが複数の第２ゲームの仕様を理解していた場合には、複数の第２ゲームのうち第１ゲームの仕様との関連度が高い（所定の条件を満たす）ゲームについての第２情報が提供されることにより、ユーザは、複数の第２ゲームの中から第１ゲームの仕様との関連度が高い第２ゲームを絞り込むことができる。これにより、ユーザは、絞り込まれた第２ゲームの仕様に基づいて第１ゲームの仕様を早期に想定することができる。

　上記ゲーム制御装置において、前記第２情報提供手段は、前記第２ゲームが複数存在する場合に、複数の第２ゲームのうち前記ユーザによる実行状況が所定の条件を満たすゲームについての前記第２情報を、前記ユーザに提供してもよい。
　例えば、ユーザに対して、複数の第２ゲームのうちユーザによる実行状況がある程度進んだ（所定の条件を満たす）ゲームについての第２情報が提供されることにより、ユーザは、複数の第２ゲームの中から、仕様を理解している第２ゲームを絞り込むことができる。これにより、ユーザは、第２ゲームの仕様に基づいて第１ゲームの仕様を早期に想定することができる。

　本発明の第２の観点は、ゲーム制御方法である。
　当該ゲーム制御方法は、
　第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供するステップと、
　前記第１ゲームと、前記ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報を取得するステップと、
　前記関連度に関する情報に基づいて、前記ユーザに対する前記第１情報の情報量を制限するステップと、
　を備える。

　本発明の第３の観点は、コンピュータに、
　コンピュータに、
　第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する機能、
　前記第１ゲームと、前記ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報を取得して記憶装置に記憶する機能、及び
　前記記憶装置を参照して、前記関連度に関する情報に基づいて、前記ユーザに対する前記第１情報の情報量を制限する機能、
　を実現させるためのプログラムである。

　コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ－ＲＯＭやＣＤ－ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。すなわち、本発明の第４の観点は、前記プログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体である。

　本発明の第５の観点は、通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
　第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する第１情報提供手段、
　前記第１ゲームと、前記ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報を取得する取得手段、
　前記関連度に関する情報に基づいて、前記ユーザに対する前記第１情報の情報量を制限する制限手段、
　の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。

　通信端末は、例えば携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機、通信機能付きゲーム装置等であってよい。

　本発明の第６の観点は、情報処理装置である。
　当該情報処理装置は、
　第１ソフトウェアを利用するユーザに対して、前記第１ソフトウェアの仕様を説明するための第１情報を提供する第１情報提供手段と、
　前記第１ソフトウェアと、前記ユーザが利用経験を有する第２ソフトウェアとの間の仕様の関連度に関する情報を取得する取得手段と、
　前記関連度に関する情報に基づいて、前記ユーザに対する前記第１情報の情報量を制限する制限手段と、
　を備える。

実施形態のゲームシステムの基本構成を示す図。実施形態の通信端末の外観の一例を示す図。実施形態の通信端末の外観の他の例を示す図。実施形態の通信端末の構成を示すブロック図。実施形態のゲームサーバの構成を示すブロック図。実施形態のデータベースサーバの構成を示すブロック図。ゲームＡのユーザデータベースの構成例を示す図。ゲームＢのユーザデータベースの構成例を示す図。仕様データのデータ構成例を示す図。実施形態の統括サーバの構成を示すブロック図。関連度データのデータ構成例を示す図。実行状況管理データのデータ構成例を示す図。ゲームＡのトップページを表示する通信端末の表示画面の一例を示す図。ゲームＡの実行中にユーザの通信端末に表示されるウェブページを例示する図。ゲームＢのトップページを表示する通信端末の表示画面の一例を示す図。ゲームＢの実行中にユーザの通信端末に表示されるウェブページを例示する図。ゲームＡのチュートリアルにおいてユーザの通信端末に表示される一連のウェブページを例示する図。実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。変形例においてユーザの通信端末に表示されるウェブページを例示する図。変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。変形例においてユーザの通信端末に表示されるウェブページを例示する図。変形例においてユーザの通信端末に表示されるウェブページを例示する図。通信端末及びゲームサーバの各々における各機能の構成例を示す図。通信端末及びゲームサーバの各々における各機能の構成例を示す図。

　本発明は、２０１２年６月４日に日本国特許庁に出願された特願２０１２－１２６７９５の特許出願に関連しており、この出願の内容がこの明細書に参照によって組み込まれる。

　以下、本発明の実施形態について説明する。
　ここで、本実施形態では、ユーザが、自ら保有する通信端末を用いて、ソフトウェアの一例であるゲーム用アプリケーションを利用する場合を例に挙げて説明する。なお、ソフトウェアは、ゲーム用アプリケーションに限られず、例えばＯＳ(Operating System)や文書作成用ソフトウェアなどのように、コンピュータ上で何らかの処理を行うように構成されたものであれば何でもよい。

　（１）ゲームシステムの構成
　図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０ａ及びデータベースサーバ３０ａ，ゲームサーバ２０ｂ及びデータベースサーバ３０ｂ，…と、統括サーバ４０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）などの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。

　このゲームシステムにおいて、ゲームサーバ２０ａ及びデータベースサーバ３０ａは、ゲームＡ（第１ゲーム）の実行について、ネットワークを介したサービスを通信端末１０に提供するために設けられている。ゲームサーバ２０ｂ及びデータベースサーバ３０ｂは、ゲームＡと異なるゲームＢ（第２ゲーム）の実行について、ネットワークを介したサービスを通信端末１０に提供するために設けられている。ここで、「第１ゲーム」は、本発明の「第１ソフトウェア」の一例であり、「第２ゲーム」は、本発明の「第２ソフトウェア」の一例である。
　なお、以下の説明において、各ゲームサーバ２０ａ，２０ｂ，…に共通して言及するときには、ゲームサーバ２０と表記する。同様に、各データベースサーバ３０ａ，３０ｂ，…に共通して言及するときには、データベースサーバ３０と表記する。ゲームサーバ２０には、ゲーム用プログラムとしてウェブブラウザによって解釈可能な文書を作成するプログラムが実装されている。データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのために、対応するゲームサーバ２０と例えば有線で接続される。
　通信端末１０は、ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末１０でウェブページに対する操作を行うことにより、ゲーム用アプリケーションを実行する。

　また、図１には図示していないが、ゲームサーバ２０とは別に各通信端末１０のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末１０からのアクセスを受け入れるために複数のゲームサーバ２０を設ける場合は、その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ２０は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。

　統括サーバ４０は、複数のゲームサーバ２０ａ，２０ｂ，…を管理するために設けられている。各ゲームサーバ２０は、処理対象となるゲームについて登録したユーザの情報を保持しているが、統括サーバ４０は、特定のゲームに依存しないユーザの情報や、ゲームごとのユーザの情報を一元的に管理することによって、例えば、ユーザによる新たなゲームの登録サービスや、ゲームコミュニティの形成を支援する等のために設けられている。
　なお、本実施形態のゲームシステムでは、統括サーバ４０を含む場合を一例として説明しているが、例えば複数のゲームサーバ２０ａ，２０ｂ，…の何れかが統括サーバ４０の機能を実現可能に構成されている場合には、統括サーバ４０をゲームサーバとは独立した装置として設けなくてもよい。

　（２）通信端末の構成
　図２Ａ、図２Ｂ及び図３を参照して通信端末１０について説明する。
　図２Ａ、図２Ｂはそれぞれ、通信端末１０の外観の例を示す図である。図２Ａは、例えば折り畳み式の携帯端末（携帯電話機）などの釦入力方式の通信端末を例示したものである。図２Ｂは、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図３は、通信端末１０の内部構成を示すブロック図である。
　図３に示すように、通信端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、画像処理部１４、指示入力部１５、表示部１６、及び、通信インタフェース部１７を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１８が設けられている。

　ＣＰＵ１１は、ＲＯＭ１２内のウェブブラウザをＲＡＭ１３にロードして実行する。そして、ＣＰＵ１１は、指示入力部１５等によってユーザに入力されるＵＲＬ(Uniform Resource Locator)の適切な指定に基づき、通信インタフェース部１７を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を、通信インタフェース部１７を介して取得し、そのＨＴＭＬデータを解釈する。なお、通信端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。
　なお、ＨＴＭＬデータの取得に当たって、ＣＰＵ１１は、予め登録されたユーザＩＤ（ユーザ識別情報）、あるいは指示入力部１５を介して入力されるユーザＩＤを含むアクセス要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０へ通知する。

　ウェブブラウザは、画像処理部１４を介して、取得したＨＴＭＬデータに基づき、ゲームサーバ２０から提供されるウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが指示入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニュー（例えば、指示釦等）が選択されると、その選択に応じたウェブページを表示するための新たなＨＴＭＬデータの送信（つまり、ウェブページの更新）をゲームサーバ２０へ要求する。

　画像処理部１４は、ＨＴＭＬデータの解析結果としてＣＰＵ１１から与えられる表示用画像データに基づいて、表示部１６にウェブページを表示する。表示部１６は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。

　通信端末１０が釦入力方式の通信端末（図２Ａに示す）である場合、指示入力部１５は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群１５ａ、及び、テンキーなどの複数の指示入力釦を含む釦群１５ｂを備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部１６に表示されているウェブページをスクロールして表示することをＣＰＵ１１へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示（例えば強調表示）されている１つのハイパーリンクまたはメニューをユーザが選択することをＣＰＵ１１へ指示するために設けられる。なお、通信端末１０を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末１０を片手で保持したままその親指で操作（クリック）しやすいように、通信端末１０の前面に配置されていることが好ましい。図２Ａに示す例では、釦群１５ｂは、釦群１５ａの下方に配置され、「０」～「９」、「＊」、「＃」（テンキー）が表記された複数の指示入力釦を含む。

　通信端末１０がタッチパネル入力方式の通信端末（図２Ｂに示す）である場合、指示入力部１５は、主として表示画面１６ａに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図２Ｂに示すように、通信端末１０がタッチパネル入力方式の場合であっても釦群１５ａが設けられる場合もある。

　通信端末１０に表示されるウェブページ上のメニューの選択操作は、例えば通信端末１０が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末１０がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面１６ａ上のメニューの位置を指あるいはペンで指示（タッチ操作）することによって行われる。

　（３）ゲームサーバの構成
　図４を参照してゲームサーバ２０の構成について説明する。
　ゲームサーバ２０は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末１０に対してゲームのウェブサービスを提供する。図４に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、及び、通信インタフェース部２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

　ＲＯＭ２２には、クライアントである通信端末１０のウェブブラウザに対してＨＴＭＬ文書や画像などのオブジェクトの表示（ウェブページの表示）のサービスを提供するアプリケーションプログラムが格納されている。ＲＯＭ２２には、アプリケーションプログラム以外にもＣＰＵ２１によって参照される各種データが格納されている。
　ＣＰＵ２１は、ＲＯＭ２２内のゲームプログラムをＲＡＭ２３にロードして実行し、通信インタフェース部２５を介して、各種の処理を行う。

　例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、ＨＴＭＬデータを通信端末１０宛に送信する。なお、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
　ＣＰＵ２１は、通信端末１０に表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなＨＴＭＬデータの送信、または、ゲームサーバ２０内の演算処理あるいはデータ処理などを含む。
　データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。

　（４）データベースサーバの構成
　データベースサーバ３０は、大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の記憶装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
　図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。

　本実施形態のゲームサーバ２０ａ及びデータベースサーバ３０ａによって提供されるゲームＡのタイプは特に限定されるものではないが、以下では、説明の便宜上、戦士カードを用いたデジタルカードゲームとする。ゲームＡは、ユーザの実行対象となる以下の処理を含む。
・クエスト処理：
　少なくとも一枚の戦士カードからなる自らのチームを作り上げていくために、ゲームＡ上で設定されている複数のエリアを探索して戦士カードを得る処理である。ゲームＡでは、クエスト処理を実行することで一定量の体力ポイント（後述する）を消費するが、合成ポイント（後述する）が得られるようになっている。
・合成処理：
　２枚以上の戦士カードを一体化して特定の戦士カードの能力を上昇させる処理である。ゲームＡでは、ユーザが合成処理を実行するには一定量の合成ポイント（後述する）が必要となる。
・バトル処理：
　他のユーザのチームとバトル（対戦）を行う処理である。ゲームＡでは、バトル処理を実行することで攻撃ポイント（後述する）を消費するが、バトルに勝利すれば合成ポイントが例えば一定量増加する。なお、バトル処理については、ここでは詳しく述べないが、例えばユーザがバトルで使用する戦士カードの能力を示すパラメータ（例えば、攻撃力、防御力を示す値）の大小に基づいて、バトルの結果が決定されるように構成される。例えば、パラメータの値の大きい戦士カードをバトルに使用したユーザが、それよりパラメータの値の小さい戦士カードをバトルに使用した他のユーザに対して勝利する可能性が高くなるように設定されてもよい。この場合、ユーザの保有する戦士カードのパラメータの値が大きいほど、他のユーザと比べてゲームＡをより優位に進められるようになる。

　また、本実施形態のゲームサーバ２０ｂ及びデータベースサーバ３０ｂによって提供されるゲームＢのタイプは特に限定されるものではないが、以下では、説明の便宜上、野球形式のデジタルカードゲームとする。ゲームＢは、ユーザの実行対象となる以下の処理を含む。
・スカウト処理：
　自らのチームを作り上げていくために、ゲームＢ上で設定されている複数のエリアを探索して選手カードを得る処理である。ゲームＢでは、スカウト処理を実行することで一定量の行動ポイント（後述する）を消費するが、強化ポイント（後述する）が得られるようになっている。なお、後述するように、本実施形態では、スカウト処理の操作手順などの仕様は、ゲームＡのクエスト処理の仕様と関連又は共通するように構成されている。
・強化処理：
　２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる処理である。ゲームＢでは、ユーザが強化処理を実行するには一定量の強化ポイント（後述する）が必要となる。なお、ここでは詳しく述べないが、本実施形態では、強化処理の操作手順などの仕様は、ゲームＡの合成処理の仕様と関連又は共通するように構成されている。
・試合処理：
　他のユーザのチームと試合を行う処理である。ゲームＢでは、試合処理を実行することで攻撃ポイント（後述する）を消費するが、試合に勝利すれば強化ポイントが例えば一定量増加する。なお、試合処理については、ここでは詳しく述べないが、例えばユーザが試合で使用する選手カードの能力を示すパラメータ（例えば、走力、打力、守備力などを示す値）の大小に基づいて、試合の結果が決定されるように構成される。例えば、試合で使用する選手カードのパラメータの合計の大きいユーザが、それよりパラメータの合計の小さい他のユーザに対して勝利する可能性が高くなるように設定されてもよい。この場合、ユーザは、選手カードのパラメータの合計が大きいほど、他のユーザと比べてゲームＢをより優位に進められるようになる。
　また、本実施形態では、試合処理の操作手順などの仕様は、ゲームＡのバトル処理の仕様と関連又は共通するように構成されている。

　図６に、本実施形態のゲームＡにおいて適用されるデータベースサーバ３０ａ内のユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名、表示画像、技能レベル、体力ポイント、攻撃ポイント、合成ポイント、戦士数、仲間のユーザＩＤ及び保有カードのデータの各項目についての情報を含む。図６に例示したユーザデータベース３１に含まれる情報は、ゲームサーバ２０ａによって逐次更新されうる。
　なお、ユーザが複数のゲーム（ゲームＡ、ゲームＢ、…）の各々を実行する場合、当該ユーザのユーザＩＤは、各ゲーム間で共通に用いられてもよい。

　データベースサーバ３０ａ内のユーザデータベース３１に含まれる各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
　ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名は、例えばユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・技能レベル
　ゲームＡ上のユーザの技能レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。例えば、クエスト処理が継続的に実行されることで、順次技能レベルが上がるように構成されてもよい。
・体力ポイント
　ゲームＡにおいて、クエスト処理を実行する上で必要となるポイントである。体力ポイントは、クエスト処理において探索を行うことで例えば一定量減少し、所定の時間が経過する毎に回復（増加）する値である。
・攻撃ポイント
　ゲームＡにおいて、バトル処理を実行する上で必要となるポイントである。攻撃ポイントは、他のユーザのチームとのバトルによって低減し、所定の時間が経過する毎に回復（増加）する値である。
・合成ポイント
　ゲームＡにおいて、合成処理を実行する上で必要となるポイントである。合成ポイントは、戦士カードの強化を行うことで低減し、他のユーザのチームとのバトルで勝利することで増加する値である。
・戦士数
　ユーザが保有する戦士カードの数である。戦士数の最大値（例えば、６０）は予め規定されている。
・仲間のユーザＩＤ
　仲間のユーザのユーザＩＤのデータである。
・保有カードのデータ
　ユーザが保有する戦士カードごとに、例えば、戦士のキャラクタの画像や、戦士のキャラクタの能力を示すパラメータ（例えば、攻撃力、防御力を示す値）等のデータが含まれる。

　図７に、本実施形態のゲームＢにおいて適用されるデータベースサーバ３０ｂ内のユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名、表示画像、技能レベル、行動ポイント、運営ポイント、強化ポイント、選手数、仲間のユーザＩＤ及び保有カードのデータの各項目についての情報を含む。図７に例示したユーザデータベース３１に含まれる情報は、ゲームサーバ２０ｂによって逐次更新されうる。

　データベースサーバ３０ｂ内のユーザデータベース３１に含まれる各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
　ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名及び表示画像である。なお、ユーザが複数のゲーム（ゲームＡ、ゲームＢ、…）の各々を実行する場合、当該ユーザのユーザ名／表示画像は、各ゲーム間で共通に用いられてもよい。
・技能レベル
　ゲームＢ上のユーザの技能レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。例えば、スカウト処理が継続的に実行されることで、順次技能レベルが上がるように構成されてもよい。
・行動ポイント
　ゲームＢにおいて、スカウト処理を実行する上で必要となるポイントである。行動ポイントは、スカウト処理において探索を行うことで例えば一定量減少し、所定の時間が経過する毎に回復（増加）する値である。
・運営ポイント
　ゲームＢにおいて、試合処理を実行する上で必要となるポイントである。運営ポイントは、他のユーザと試合を行うことによって低減し、所定の時間が経過する毎に回復（増加）する値である。
・強化ポイント
　ゲームＢにおいて、強化処理を実行する上で必要となるポイントである。強化ポイントは、選手カードの強化を行うことで低減し、他のユーザとの試合で勝利することで増加する値である。
・選手数
　ユーザが保有する選手カードの数である。選手数の最大値（例えば、６０）は予め規定されている。
・仲間のユーザＩＤ
　仲間のユーザのユーザＩＤのデータである。なお、ユーザがゲームＡとゲームＢに登録している場合、当該ユーザの仲間は各々のゲームで異なっていてもよい。つまり、当該ユーザの仲間のユーザＩＤは、図６に例示したユーザデータベース３１内の当該ユーザのユーザＩＤに対応する仲間のユーザＩＤと異なっていてもよい。
・保有カードのデータ
　ユーザが保有する選手カードごとに、例えば、選手のキャラクタの画像や、選手のキャラクタの能力を示すパラメータ（例えば、選手が野手である場合には、走力、打力、守備力を示す値であってもよいし、選手が投手である場合には、球速、制球力、スタミナを示す値であってもよい）等のデータが含まれる。

　図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ユーザによるゲームの実行状況に関する情報を記憶、更新する。ゲームの実行状況に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームＡの場合を例に挙げれば、ゲームの実行状況に関する情報は、クエスト処理の進行状況を示す情報や、他のユーザとのバトル結果についての情報などを含む。また、本実施形態のゲームＢの場合を例に挙げれば、ゲームの実行状況に関する情報は、スカウト処理の進行状況を示す情報や、他のユーザとの試合の結果についての情報などを含む。
　また、後述するように、本実施形態のゲームでは、ゲームを実行するユーザに対して、当該ゲームの仕様を説明するためのチュートリアルが行われるようになっている。そのため、ゲームデータベース３２には、ゲームの仕様を説明するための説明情報（第１情報）が記述された仕様データが記憶されている。ゲームＡの仕様データの例を図８に示す。

　仕様データは、ゲーム上でチュートリアルが行われる際に例えばＲＡＭ２３にロードされ、記憶されるデータである。仕様データは、ゲームに含まれる処理ごとに、当該処理の仕様を説明するための説明情報を含む。ここで、「仕様」には、例えば、ゲームの操作手順に関する情報や、ゲームの構成に関する情報（例えば、ゲームのコンセプト、ゲーム上の世界観、ゲームのルールなど）や、ゲームの内容に関する情報（例えば、ゲーム上のエリア、キャラクタ、アイテムなどに関する情報）などが含まれてもよい。また、キャラクタとは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカード等に表示されているものをも含む。さらに、アイテムとは、例えば、ユーザがゲーム上保有することができるものであってもよいし、ユーザがゲーム上で収集する必要があるものであってもよいし、ユーザがゲーム上で有利な効果を得られるものなどであってもよい。
　なお、図８に例示した仕様データは、ゲームに含まれる処理（図の例では、クエスト処理、合成処理、バトル処理）ごとに説明情報が対応付けられるように構成されているが、仕様データは、例えば一つのゲーム全体の仕様が一つの説明情報としてまとめられた状態で構成されてもよい。また、図８に例示した仕様データの説明情報は、テキストデータで構成されているが、例えば、画像データや音声データなどで構成されてもよい。

　（５）統括サーバの構成
　図９を参照して統括サーバ４０の構成について説明する。
　統括サーバ４０は、複数のゲームサーバ２０ａ，２０ｂ，…と通信可能に接続されている。図９に示すように、統括サーバ４０は、ＣＰＵ４１、ＲＯＭ４２、ＲＡＭ４３、ＨＤＤ(Hard Disk Drive)４４、及び、通信インタフェース部４５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス４６が設けられている。なお、統括サーバ４０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

　ＲＯＭ４２には、ＣＰＵ４１によって実行される各種プログラムのほか、プログラムの実行に伴ってＣＰＵ４１によって参照される各種データが格納されている。
　ＣＰＵ４１は、ＲＯＭ４２内のプログラムをＲＡＭ４３にロードして実行し、各種の処理を行う。ＣＰＵ４１によって実行される処理には、通信インタフェース部４５を介して、各ゲームサーバ２０から、対象となるゲームの情報と、対象となるユーザの情報（ユーザＩＤ及びユーザ名のうち少なくともいずれか、ユーザによるゲームの実行状況など）とを取得し、取得した情報をＨＤＤ４４内の実行状況管理データ（後述する）に書き込む処理や、ゲームサーバ２０からの要求に基づいて関連度データ（後述する）内の情報を要求元のゲームサーバ２０宛に送信する処理などが含まれる。

　図１０に、関連度データのデータ構成例を示す。図１０に示すように、関連度データは、複数のゲームサーバ２０ａ，２０ｂ，…で実行されるゲームごとに、当該ゲームの処理と、当該処理と仕様が関連又は共通する他のゲームの処理とが対応付けて記述されているデータである。図１０の例を参照して説明すると、ゲームＡの「クエスト」処理の仕様は、ゲームＢの「スカウト」処理の仕様、及びゲームＣの「ミッション」処理の仕様の各々と関連している。なお、ここでは、ゲームＣについての詳細な説明は省略する。また、図１０の例では、ゲームＡの「合成」処理の仕様はゲームＢの「強化」処理の仕様と関連しており、ゲームＡの「バトル」処理の仕様はゲームＢの「試合」処理の仕様と関連している。ここで、複数のゲーム間における処理の関連付けは、例えば、ゲーム提供者などによって任意に設定されてもよい。
　また、関連度データには、複数のゲームサーバ２０ａ，２０ｂ，…で実行されるゲームごとに、他のゲームの仕様との関連度合いを示す関連度が対応付けて記述されている。この関連度は、例えば、他のゲームの仕様との関連性が高いほど大きくなるように設定されてもよい。本実施形態のゲームの場合を例に挙げれば、関連度は、ゲームに含まれる処理数に対する、他のゲームの処理との間で仕様が関連する処理の数の割合としてもとめられてもよい。図１０の例を参照して説明すると、ゲームＡに含まれる処理数は３つ（クエスト処理、合成処理、バトル処理）であり、各処理の仕様は何れもゲームＢに含まれる処理（スカウト処理、強化処理、試合処理）の仕様と関連している。この場合、ゲームＡとゲームＢの仕様の関連度は、３／３＝１となる。また、図１０の例では、ゲームＡの処理のうち、ゲームＣとの間で仕様が関連する処理の数が１つ（クエスト処理）であるため、ゲームＡとゲームＣの仕様の関連度は、１／３≒０．３となる。また、関連度は、所定の演算式等を用いて、ゲームに含まれる処理数と、他のゲームの処理との間で仕様が関連する処理の数とを当該演算式に当てはめることで求められてもよい。
　なお、本実施形態では、関連度の最大値が１となる場合を一例として説明したが、関連度の最大値は任意に設定されてもよい。また、ゲーム間の仕様の関連度は、例えば、ゲーム提供者などによって任意に設定されてもよい。

　図１１に、実行状況管理データのデータ構成例を示す。図１１に示すように、実行状況管理データは、ユーザ（ユーザＩＤ）ごとに、複数のゲームサーバ２０ａ，２０ｂ，…で実行されるゲームの実行状況が対応付けて記述されているデータである。ここで、ゲームの実行状況とは、例えば、ユーザがゲーム上で制覇（クリア）したパートの数であってもよいし、ユーザが、ゲーム上の対戦において他のユーザあるいはキャラクタに勝利した数であってもよい。また、ゲームの実行状況とは、例えば、ユーザがゲーム上で獲得した特定のアイテムの数であってもよいし、ゲームの進行度や技能レベルの高さなどであってもよい。
　統括サーバ４０のＣＰＵ４１は、例えば、所定時間が経過するごとに、複数のゲームサーバ２０ａ，２０ｂ，…に対し、各ユーザによるゲームの実行状況に関する情報の送信を要求する。そして、ＣＰＵ４１は、各ユーザによるゲームの実行状況に関する情報を各ゲームサーバ２０ａ，２０ｂ，…から受信すると、当該情報に含まれるゲームの実行状況を実行状況管理データ内の対応するユーザＩＤごとに記録する。
　また、ＣＰＵ４１は、各ユーザによるゲームの実行状況に関する情報の送信を要求しない場合であっても、当該情報が各ゲームサーバ２０ａ，２０ｂ，…から任意のタイミングで送信されたときには、当該情報を受信し、当該情報に含まれるゲームの実行状況を実行状況管理データ内の対応するユーザＩＤごとに記録してもよい。
　なお、ＣＰＵ４１は、ユーザがゲームの実行経験を有していない場合には、実行状況管理データ内の対応するユーザＩＤの当該ゲームの実行状況の項目にＮＵＬＬデータを記録してもよい。

　（６）本実施形態のゲーム
　次に、本実施形態のゲームＡについて、図１２～１３を参照しながら説明する。図１２は、本実施形態のゲームＡにおいて通信端末１０上に表示されるトップページの一例を示す図である。図１３は、クエスト処理が実行されるときの通信端末１０上に表示されるウェブページの例を示す図である。
　また、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネルの操作によるウェブページのスクロール操作によって変化しうる。
　図１２に例示するゲームＡのトップページは、個々のユーザＩＤに応じたウェブページで構成される。図１２の例では、ユーザデータ表示領域、戦士画像表示領域及びメニュー表示領域を含む。
　ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、体力ポイント、攻撃ポイント、合成ポイント、戦士数、仲間の各項目のデータ（図６参照）が表示される領域である。なお、図１２において、戦士数の一例として「５／６０」と表記されているが、これは、ユーザが保有する戦士カードが５枚であり、最大で保有可能な戦士カードの枚数が６０枚であることを示す。
　戦士画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
　メニュー表示領域は、ゲームＡに設けられる複数の機能（クエスト処理、合成処理、バトル処理）に対応した基本メニューとして、「クエスト」、「合成」、「バトル」のテキストが表記された各メニューｍ１～ｍ３が表示される領域である。
　このトップページ上で、メニューｍ１～ｍ３の何れかが選択操作されることで、ゲームＡの実行が開始される。
　なお、ゲームＡでは、ユーザがゲームＡに登録した後に初めてゲームＡを実行する場合に、当該ユーザに対してゲームＡの仕様を説明するためのチュートリアルが行われるようになっている。チュートリアルの詳細については、後述する。

　図１２のトップページ上でメニューｍ１が選択操作されると、クエスト処理が実行される。この場合、図１３に示すようにウェブページが更新される。図１３のウェブページには、探索の対象となるエリア（図１３の例では、エリア１）の進行度合いを示す探索率のゲージ、探索処理を実行するための「探索する」と表記されたメニューｍ１０などが含まれる。
　クエスト処理では、メニューｍ１０が選択操作されると、この操作を契機として、探索の対象となるエリアについての戦士カードの探索が行われる。このとき、メニューｍ１０が選択操作されて探索が行われる度に、「探索率」（％）の値が一定の、あるいはランダムな増加量で増加する。探索率が１００％に達した場合には、対象となるエリアの探索が終了したことになり、次のエリア（ここでは、エリア２）の探索に移る。上述したように、ゲームＡでは、１回の探索につき、所定量（例えば５ポイント）の体力ポイントが減少するように構成されており、体力ポイントの値が所定量よりも少なくなった場合には、探索処理を実行することができない。この場合、ユーザは、体力ポイントの値が回復（増加）するまで待機する必要がある。なお、図１３に例示したウェブページは、１回の探索に要する体力ポイントの値や、１回の探索で得られた合成ポイントの値などが表示されるように構成されてもよい。

　次に、本実施形態のゲームＢについて、図１４～１５を参照しながら説明する。図１４は、本実施形態のゲームＢにおいて通信端末１０上に表示されるトップページの一例を示す図である。図１５は、スカウト処理が実行されるときの通信端末１０上に表示されるウェブページの例を示す図である。

　図１４に例示するゲームＢのトップページは、個々のユーザＩＤに応じたウェブページで構成される。図１４の例では、ユーザデータ表示領域、選手画像表示領域及びメニュー表示領域を含む。
　ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、行動ポイント、運営ポイント、強化ポイント、選手数、仲間の各項目のデータ（図７参照）が表示される領域である。
　選手画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の選手カードのうちユーザによって予め指定された選手カードの画像が表示される領域である。
　メニュー表示領域は、ゲームＢに設けられる複数の機能（スカウト処理、強化処理、試合処理）に対応した基本メニューとして、「スカウト」、「強化」、「試合」のテキストが表記された各メニューｍ２１～ｍ２３が表示される領域である。
　このトップページ上で、メニューｍ２１～ｍ２３の何れかが選択操作されることで、ゲームＢの実行が開始される。

　図１４のトップページ上でメニューｍ２１が選択操作されると、スカウト処理が実行される。この場合、図１５に示すようにウェブページが更新される。図１５のウェブページには、探索の対象となるエリア（図１５の例では、エリア９）の進行度合いを示す探索率のゲージ、探索処理を実行するための「探索する」と表記されたメニューｍ２４などが含まれる。
　スカウト処理では、メニューｍ２４が選択操作されると、この操作を契機として、探索の対象となるエリアについての選手カードの探索が行われる。このとき、メニューｍ２４が選択操作されて探索が行われる度に、「探索率」（％）の値が一定の、あるいはランダムな増加量で増加する。探索率が１００％に達した場合には、対象となるエリアの探索が終了したことになり、次のエリア（ここでは、エリア１０）の探索に移る。上述したように、ゲームＢでは、１回の探索につき、所定量（例えば５ポイント）の行動ポイントが減少するように構成されており、行動ポイントの値が所定量よりも少なくなった場合には、探索処理を実行することができない。この場合、ユーザは、行動ポイントの値が回復（増加）するまで待機する必要がある。なお、図１５に例示したウェブページは、１回の探索に要する行動ポイントの値や、１回の探索で得られる強化ポイントの値が表示されるように構成されてもよい。
　図１３及び図１５を参照して説明したように、ゲームＢのスカウト処理の仕様は、ゲームＡのクエスト処理の仕様と関連又は共通するように構成されている。

　次に、ゲームＡにおいて行われるチュートリアルについて、図１６を参照しながら説明する。図１６は、本実施形態のゲームＡのチュートリアルにおいて通信端末１０上に表示される一連のウェブページの一例を示す図である。
　例えば、ユーザがゲームＡに登録した後に初めてゲームＡを実行する場合、図１２に示すトップページ上でユーザがメニューｍ１～ｍ３の何れかの選択操作を行うと、図１６のステップＳ１に例示するウェブページが当該ユーザの通信端末１０上に表示される。ステップＳ１のウェブページは、クエスト処理の仕様の説明が行われるように構成されている。ステップＳ１のウェブページには、クエスト処理の仕様を説明するための説明情報（図８参照）が表示される表示領域１００と、「次へ」と表記されたメニューｍ１１などが含まれる。
　ここで、ユーザがゲームＢの実行経験を有している場合には、ゲームＡとゲームＢとの間の仕様の関連度に基づいて、表示領域１００に表示される説明情報の情報量が制限されるようになっている。ユーザがゲームＢの実行経験を有していることを前提として説明すると、ステップＳ１のウェブページに示されるように、表示領域１００に表示されるクエスト処理の説明情報は、図８に例示したクエスト処理の説明情報の一部のみとなる。本実施形態の例では、ユーザがゲームＢの実行経験を有し、且つ、ゲームＡのクエスト処理とゲームＢのスカウト処理の仕様が関連又は共通しているため（図１０参照）、当該ユーザは、ゲームＢのスカウト処理の仕様に基づき、ゲームＡのクエスト処理の仕様を想定し得ると考えられる。そこで、クエスト処理の説明情報の情報量が制限されることにより、ユーザは、図８に例示したスカウト処理の説明情報が全て表示される場合と比較して、スカウト処理の仕様についての説明を省略することができ、ゲームＡを円滑に進行することができる。これにより、ユーザは、クエスト処理の仕様の説明に対する煩わしさを低減することができる。
　なお、ユーザがゲームＢの実行経験を有しているが、ゲームＡのクエスト処理との間で仕様が関連又は共通する処理がゲームＢに設けられていない場合、表示領域１００には、図８に例示したスカウト処理の説明情報が全て表示されてもよい。

　次に、ステップＳ１のウェブページ上でユーザがメニューｍ１１を選択操作すると、図１６のステップＳ２に示すように、合成処理の仕様の説明が行われるウェブページに更新される。ステップＳ２に示すウェブページの表示領域１００には、合成処理の仕様を説明するための説明情報（図８参照）が表示される。
　ここで、上述したクエスト処理と同様に、ユーザがゲームＢの実行経験を有し、且つ、ゲームＡの合成処理とゲームＢの強化処理の仕様が関連又は共通しているため（図１０参照）、表示領域１００に表示される合成処理の説明情報は、図８に例示した合成処理の説明情報の一部のみとなる。
　このように、合成処理の説明情報の情報量が制限されることにより、ユーザは、図８に例示した合成処理の説明情報が全て表示される場合と比較して、合成処理の仕様についての説明を省略することができ、ゲームＡを円滑に進行することができる。これにより、ユーザは、合成処理の仕様の説明に対する煩わしさを低減することができる。
　なお、ユーザがゲームＢの実行経験を有しているが、ゲームＡの合成処理との間で仕様が関連又は共通する処理がゲームＢに設けられていない場合、表示領域１００には、図８に例示した合成処理の説明情報が全て表示されてもよい。

　さらに、ステップＳ２のウェブページ上でユーザがメニューｍ１１を選択操作すると、図１６のステップＳ３に示すように、バトル処理の仕様の説明が行われるウェブページに更新される。ステップＳ３に示すウェブページの表示領域１００には、バトル処理の仕様を説明するための説明情報（図８参照）が表示される。
　ここで、上述したクエスト処理と同様に、ユーザがゲームＢの実行経験を有し、且つ、ゲームＡのバトル処理とゲームＢの試合処理の仕様が関連又は共通しているため（図１０参照）、表示領域１００に表示されるバトル処理の説明情報は、図８に例示したバトル処理の説明情報の一部のみとなる。
　このように、バトル処理の説明情報の情報量が制限されることにより、ユーザは、図８に例示したバトル処理の説明情報が全て表示される場合と比較して、バトル処理の仕様についての説明を省略することができ、ゲームＡを円滑に進行することができる。これにより、ユーザは、バトル処理の仕様の説明に対する煩わしさを低減することができる。
　なお、ユーザがゲームＢの実行経験を有しているが、ゲームＡのバトル処理との間で仕様が関連又は共通する処理がゲームＢに設けられていない場合、表示領域１００には、図８に例示したバトル処理の説明情報が全て表示されてもよい。

　以上説明したように、本実施形態では、ゲームＡとゲームＢとの間の仕様の関連度が高いほど（つまり、仕様が関連又は共通する処理の数が多いほど）、ゲームＡ全体の説明情報の情報量が制限されるようになっている。なお、１つの処理の説明情報のうち制限される情報の量は、ゲームＡとゲームＢとの間の仕様の関連度が高いほど、多くなるように構成されてもよい。

　（７）ゲーム制御装置における各機能の概要
　本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。ここで、ゲーム制御装置は、本発明の「情報処理装置」の一例である。以下では、上述した本実施形態のゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図１７を参照して説明する。図１７は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
　なお、図１７の機能ブロック図において、第１情報提供手段５３、取得手段５４及び制限手段５５が本発明の主要な構成に対応している。その他の手段は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成である。

　登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの要求を認識し、登録処理（ユーザ登録）を行う機能を備える。
　なお、登録手段５１は、本発明に必須の構成要素ではないが、本発明をさらに好ましくするための構成要素である。

　登録手段５１の機能は、例えば以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して通信端末１０から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ２０から提供されるウェブページ上での通信端末１０に対する所定の操作（例えば、所定のメニューの選択操作やユーザが指定するユーザＩＤやパスワード等のテキスト入力等）によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末１０を特定するための情報（例えば、ＵＩＤ（Unique Identifier）などの端末の個体識別情報、ＩＰアドレス、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。
　ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。
　登録が完了すると、ＣＰＵ２１は、ユーザＩＤに対応するユーザデータを生成し、ユーザデータベース３１に格納する。登録が完了すると、ユーザは、本実施形態のゲームを実行することが可能となる。

　また、登録手段５１は、ユーザ同士を関係付ける機能を備えてもよい。具体的には、登録手段５１は、例えばユーザＩＤに基づく申請を契機として、当該ユーザＩＤを他のユーザＩＤと関係付けて登録する。すなわち、登録手段５１は、ユーザＩＤに基づく申請を契機として、他のユーザＩＤ（つまり、他のユーザ）を「仲間」として登録する。
　この場合における登録手段５１の機能は、例えば以下のとおり実行される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されてもよい。
　ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示するためのＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間のユーザＩＤ」の箇所（図６参照）にデータ（相手のユーザＩＤ）を書き込む。なお、ＣＰＵ２１は、仲間申請先のユーザの承認を不要とする場合は、ゲームを実行中のユーザによる所定の操作を契機として、両者を仲間として登録してもよい。
　なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限られず、ゲーム上の同一のステージやエリアなどを実行するユーザやバトルを行ったユーザを、ユーザとゲーム内で関係付けられたユーザ、つまり仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間でバトルを行うゲーム上のモードが存在する場合には、所定回数以上バトルを行ったユーザ同士を自動的に仲間として登録してもよい。
　また、ユーザ同士を直接的に対応付けるのではなく、各ユーザを同一のグループ（ギルド等）と対応付けることで、そのグループ内のユーザ同士を関係付けても良い。例えば、ユーザＡが所定のグループと対応付けられたユーザ内の特定のユーザＢに対して上記のような申請を行い、当該特定のユーザＢの承認を得ることができると、当該所定のグループとユーザＡとを対応付ける。このようにすることによって、所定のグループ内の特定のユーザに対して申請と承認を行うことで、所定のグループに所属する直接的に申請と承認を行っているかいないかに関わらず同一グループ内のユーザ同士を関係付けるようにしても良い。
　本実施形態では、ユーザ同士の仲間関係の登録をユーザデータベース３１にデータを書き込むことによって実現する例を示したが、この例に限られない。仲間関係に関するデータは、ゲームサーバ２０からアクセス可能なネットワーク上の外部の記憶装置に書き込まれるようにしてもよい。

　ゲーム実行手段５２は、ゲームを実行する機能を備える。例えば、ゲーム実行手段５２は、通信端末１０に対するユーザのウェブページ上の選択操作に基づいてＨＴＴＰリクエストを受信し、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータ（つまり、ＨＴＴＰレスポンス）を送信することで、ウェブサービスにより本実施形態のゲームを実行する。
　なお、ゲーム実行手段５２は、本発明に必須の構成要素ではないが、本発明をさらに好ましくするための構成要素である。

　また、ゲーム実行手段５２は、ユーザが本実施形態のゲームを実行するに当たって、ユーザのログイン時の認証処理を実行する機能を備えてもよい。
　この機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、各ユーザの通信端末１０からのＨＴＴＰリクエストを受信すると、当該ＨＴＴＰリクエストから個体識別情報、あるいはユーザＩＤ及びパスワードを取得し、その個体識別情報、あるいはユーザＩＤ及びパスワードを、例えばユーザデータベース３１に記録済みのデータと照合して認証処理を行う。

　ここでは、ゲーム実行手段５２がゲームＡを実行する場合を一例として説明する。
　ゲーム実行手段５２は、通信端末１０に表示されたメニューｍ１～ｍ３のいずれかに対するユーザの選択操作に基づいて、クエスト処理、合成処理あるいはバトル処理を実行する。好ましくは、各処理が実行された場合、さらに細分化された複数のメニューを含む新たなウェブページが表示されるように、階層的に各処理が実行される。

　ゲーム実行手段５２がクエスト処理を実行する機能は、以下のようにして実現される。
　ゲームサーバ２０のＣＰＵ２１は、図１２のトップページ上でメニューｍ１が選択操作されたことを認識すると、図１３に示すウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。また、ＣＰＵ２１は、メニューｍ１０が選択操作されることを認識すると、ユーザデータベース３１にアクセスし、対象となるユーザＩＤの体力ポイントの値を更新する（減少させる）。なお、クエスト処理において、探索対象となるエリアごとに、１回の探索に要する体力ポイントが異なってもよい。つまり、探索対象となるエリアごとに、１回の探索で減少する（消費される）体力ポイントの量が異なってもよい。例えば、ユーザの技能レベルが上がるごとに、消費される体力ポイントの量を多くしてもよい。

　クエスト処理において、ゲームサーバ２０のＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、クエスト処理用に予め設けられた複数の戦士カードの中から所定の、あるいはランダムな確率で戦士カードを抽選して出現させる。ＣＰＵ２１は、戦士カードを出現させた（発掘した）場合には、データベースサーバ３０ａ内のユーザデータベース３１にアクセスし、対象となるユーザＩＤのデータに対して、出現した新たな戦士カードのデータを追加して、戦士数の値を１だけ増加させる。ユーザによるメニューｍ１０に対する選択操作が繰返し行われ、図１５のウェブページにおいてエリアの探索率が１００％に達すると、探索対象となるエリア（この場合、エリア１）についての探索は終了し、探索対象は次のエリア（この場合、エリア２）に移る。

　クエスト処理では、メニューｍ１０に対する選択操作を行う度に体力ポイントが減少していくため、クエスト処理が実行された直後にトップページが表示される場合には、そのトップページに表示される体力ポイントがクエスト処理の実行前よりも減少されて表示されることになる。なお、体力ポイントは、例えば所定時間（例えば３分）が経過する度に１ポイントずつ回復（増加）する。

　また、ゲーム実行手段５２は、ユーザによるゲームの実行状況をゲームデータベース３２に記憶する機能を備えてもよい。この場合、ＣＰＵ２１は、ユーザがクエスト処理、合成処理、あるいはバトル処理を実行するごとに、その実行結果（例えば、エリアの探索率、合成処理の実行回数、バトル処理の実行回数、バトルの結果など）を、当該ユーザのユーザＩＤと対応付けてゲームデータベース３２に記憶する。
　また、ＣＰＵ２１は、各ユーザによるゲームの実行状況に関する情報の送信要求を統括サーバ４０から受け付けた場合、ゲームデータベース３２に記憶された各ユーザの実行結果を抽出して、統括サーバ４０に送信する。なお、ＣＰＵ２１は、所定時間が経過するごとに、ゲームデータベース３２に記憶された各ユーザの実行結果を抽出して、統括サーバ４０に送信してもよい。

　第１情報提供手段５３は、ゲームＡ（第１ゲーム）を実行するユーザに対して、ゲームＡの仕様を説明するための説明情報（第１情報）を提供する機能を備える。
　第１情報提供手段５３の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、図１２のトップページ上でメニューｍ１～ｍ３の何れかが選択操作されたことを認識すると、選択操作を行ったユーザがゲームＡを初めて実行したか否かを判別する。この判別処理の一例を説明すると、ＣＰＵ２１は、データベースサーバ３０ａ内のゲームデータベース３２にアクセスして、選択操作を行ったユーザによるゲームＡの実行結果が記憶されていない場合には、当該ユーザがゲームＡを初めて実行したと判別してもよい。
　ＣＰＵ２１は、選択操作を行ったユーザがゲームを初めて実行したことを判別すると、仕様データからスカウト処理の説明情報を抽出し、説明情報を含むウェブページ（例えば図１６のステップＳ１のウェブページ）を表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。なお、図１６のステップＳ１に例示したウェブページでは、スカウト処理の説明情報の一部が表示領域１００に表示されているが、これは、後述する制限手段５５の機能によって説明情報の情報量が制限されたことを示している。また、ＣＰＵ２１は、ステップＳ１のウェブページ上でメニューｍ１１が選択操作されると、仕様データから合成処理の説明情報を抽出し、説明情報を含むウェブページ（例えば図１６のステップＳ２のウェブページ）を表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。なお、図１６のステップＳ２に例示したウェブページでは、スカウト処理と同様に、合成処理の説明情報の一部が表示領域１００に表示される。さらに、ＣＰＵ２１は、ステップＳ２のウェブページ上でメニューｍ１１が選択操作されると、仕様データからバトル処理の説明情報を抽出し、説明情報を含むウェブページ（例えば図１６のステップＳ３のウェブページ）を表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。なお、図１６のステップＳ３に例示したウェブページでは、スカウト処理と同様に、バトル処理の説明情報の一部が表示領域１００に表示される。
　なお、ユーザが、ゲームＡと仕様が関連又は共通するゲーム（例えばゲームＢ）の実行経験を有していない場合には、図１６のステップＳ１～Ｓ３に示すウェブページの各々には、対応する処理の説明情報が全て表示されてもよい。
　なお、本実施形態では、ユーザがゲームを初めて実行した場合に説明情報を提供する場合を一例として説明したが、説明情報を提供するタイミングはこれに限られない。例えば、第１情報提供手段５３は、ユーザの必要に応じて説明情報を提供するようにしてもよい。この場合、ゲームの仕様を説明するためのメニューを例えば図１２のトップページに設け、ＣＰＵ２１は、ユーザが当該メニューの選択操作を行ったときに、図１６のステップＳ１のウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信してもよい。

　取得手段５４は、ゲームＡ（第１ゲーム）と、ユーザが実行経験を有するゲームＢ（第２ゲーム）との間の仕様の関連度に関する情報を取得する機能を備える。
　取得手段５４の機能は、例えば以下のようにして実現される。
　ゲームサーバ２０ａのＣＰＵ２１は、ユーザに対して説明情報を提供する場合（本実施形態の例では、ユーザがゲームを初めて実行したことを判別した場合）、通信インタフェース部２５を介して、統括サーバ４０に対し実行状況管理データの送信を要求する。そして、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０から実行状況管理データを取得すると、実行状況管理データを参照して、ユーザがゲームＢの実行経験を有するか否かを判別する。例えば、ＣＰＵ２１は、当該ユーザのユーザＩＤに対応するゲームＢの実行状況の項目にＮＵＬＬデータが記録されていない場合に、当該ユーザがゲームＢの実行経験を有すると判別してもよい。
　そして、ＣＰＵ２１は、ユーザがゲームＢの実行経験を有すると判別すると、通信インタフェース部２５を介して、統括サーバ４０に対し関連度データの送信を要求する。そして、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０から関連度データを取得すると、関連度データをＲＡＭ２３、あるいはデータベースサーバ３０ａ内のゲームデータベース３２に記憶する。

　制限手段５５は、関連度に関する情報に基づいて、ユーザに対する説明情報（第１情報）の情報量を制限する機能を備える。
　制限手段５５の機能は、例えば以下のようにして実現される。
　ゲームサーバ２０ａのＣＰＵ２１は、関連度データを取得すると、関連度データを参照して、ゲームＡとゲームＢの仕様の関連度に基づいて説明情報の情報量を制限する。具体的には、ＣＰＵ２１は、例えば、ゲームＡとゲームＢの仕様の関連度が高いほど（実施形態の例では、仕様が関連又は共通する処理の数が多いほど）、説明情報の情報量を制限してもよい。より詳細には、例えば、ゲームＡとゲームＢとの間で仕様が関連する処理の数が２つの場合には、仕様が関連する処理の数が１つの場合と比較して、説明情報の情報量が制限されるようにしてもよい。さらに、仕様が関連する処理の数が３つの場合には、仕様が関連する処理の数が２つの場合と比較して、説明情報の情報量がさらに制限されるようにしてもよい。例えば、ＣＰＵ２１は、ゲームＡとゲームＢとの間で仕様が関連する処理ごとに、当該処理の説明情報の情報量を制限してもよい。これにより、仕様が関連する処理の数が多いほど、ゲームＡ全体の説明情報の情報量を制限することができる。
　また、１つの処理の説明情報のうち制限される情報の量は、ゲームＡとゲームＢとの間の仕様の関連度が高いほど、多くなるように構成されてもよい。
　なお、説明情報の情報量を制限するとは、伝達される説明情報の情報量を小さくする（説明情報を簡略化する）ことであってもよく、例えば、説明情報がテキストデータで構成されている場合には、テキストの長さを短くすることであってもよいし、説明情報がテキストデータと音声データ又は画像データとの組み合わせによって構成されている場合には、音声データ又は画像データを省略することであってもよい。
　ＣＰＵ２１は、説明情報の情報量を制限すると、情報量が制限された説明情報を表示領域１００に含むようにＨＴＭＬデータを生成する。

　（８）本実施形態のゲーム制御装置の主要な処理のフロー
　次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１８のフローチャートを参照して説明する。図１８のフローチャートは、ゲームＡにおいて、ゲームＡの仕様を説明するためのチュートリアルが行われる場合の処理の一例を示すフローチャートである。なお、ここでは、ユーザがゲームＡに登録した後に初めてゲームＡを実行するときに、ゲームＡのチュートリアルが行われる場合を一例として説明する。

　先ず、図１２に示すトップページ上でユーザがメニューｍ１～ｍ３の何れかの選択操作を行うと（ステップＳ１００：ＹＥＳ）、ゲームサーバ２０ａのＣＰＵ２１は、選択操作を行ったユーザがゲームＡを初めて実行したか否かを判別する（ステップＳ１１０）。この判別処理の一例を説明すると、ＣＰＵ２１は、データベースサーバ３０ａ内のゲームデータベース３２にアクセスして、選択操作を行ったユーザによるゲームＡの実行結果が記憶されていない場合には、当該ユーザがゲームＡを初めて実行したと判別してもよい。

　ＣＰＵ２１は、選択操作を行ったユーザがゲームを初めて実行したことを判別すると（ステップＳ１１０：ＹＥＳ）、通信インタフェース部２５を介して、統括サーバ４０に対し実行状況管理データの送信を要求する。そして、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０から実行状況管理データを取得すると、実行状況管理データを参照して、ユーザがゲームＢの実行経験を有するか否かを判別する（ステップＳ１２０）。例えば、ＣＰＵ２１は、当該ユーザのユーザＩＤに対応するゲームＢの実行状況の項目にＮＵＬＬデータが記録されていない場合に、当該ユーザがゲームＢの実行経験を有すると判別してもよい。
　そして、ＣＰＵ２１は、ユーザがゲームＢの実行経験を有すると判別すると（ステップＳ１３０：ＹＥＳ）、通信インタフェース部２５を介して、統括サーバ４０に対し関連度データの送信を要求する。そして、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０から関連度データを取得すると（ステップＳ１４０）、関連度データをＲＡＭ２３、あるいはデータベースサーバ３０ａ内のゲームデータベース３２に記憶する。
　なお、ＣＰＵ２１は、ユーザがゲームＢの実行経験を有していないと判別すると（ステップＳ１３０：ＮＯ）、ステップＳ１４０の処理を行わずに（つまり、関連度データを取得せずに）、ステップＳ１５０の処理に移行する。

　次に、ＣＰＵ２１は、仕様データから各処理（本実施形態の例では、クエスト処理、合成処理、バトル処理）の説明情報を抽出する（ステップＳ１５０）。また、ＣＰＵ２１は、関連度データを参照して、ゲームＡとゲームＢとの間の仕様の関連度に基づいて、各処理の説明情報の情報量を制限する（ステップＳ１６０）。なお、ＣＰＵ２１は、ユーザがゲームＢの実行経験を有していない場合（ステップＳ１３０：ＮＯ）、関連度データを取得していないため、各処理の説明情報の情報量を制限しない。つまり、後述するステップＳ１７０の処理において各処理の説明情報が提供される際、各処理の説明情報が全て提供されることになる。
　そして、ＣＰＵ２１は、クエスト処理について、情報量が制限された説明情報を含むウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する（ステップＳ１７０）。この場合、図１６のステップＳ１に示すウェブページがユーザの通信端末１０上に表示される。なお、ユーザがゲームＢの実行経験を有していない場合には（ステップＳ１３０：ＮＯ）、クエスト処理の説明情報の全てを含む（つまり、クエスト処理の説明情報の情報量が制限されていない）ウェブページがユーザの通信端末１０上に表示される。また、ＣＰＵ２１は、メニューｍ１１が選択操作されると（ステップＳ１８０：ＹＥＳ）、全ての処理について説明情報が提供されたか否かを判別する（ステップＳ１９０）。ここでは、各処理のうちクエスト処理についての説明情報しか提供されていないので、ＣＰＵ２１は、全ての処理の説明情報を提供していないと判別し、ステップＳ１７０の処理に移行する。
　ＣＰＵ２１は、ステップＳ１７０の処理に移行すると、合成処理について、情報量が制限された説明情報を含むウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。この場合、図１６のステップＳ２に示すウェブページがユーザの通信端末１０上に表示される。なお、ユーザがゲームＢの実行経験を有していない場合には（ステップＳ１３０：ＮＯ）、合成処理の説明情報の全てを含む（つまり、合成処理の説明情報の情報量が制限されていない）ウェブページがユーザの通信端末１０上に表示される。また、ＣＰＵ２１は、メニューｍ１１が選択操作されると（ステップＳ１８０：ＹＥＳ）、全ての処理について説明情報が提供されたか否かを判別する（ステップＳ１９０）。ここでは、各処理のうちバトル処理についての説明情報が提供されていないので、ＣＰＵ２１は、全ての処理の説明情報を提供していないと判別し、ステップＳ１７０の処理に移行する。
　ＣＰＵ２１は、ステップＳ１７０の処理に再度移行すると、バトル処理について、情報量が制限された説明情報を含むウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。この場合、図１６のステップＳ３に示すウェブページがユーザの通信端末１０上に表示される。なお、ユーザがゲームＢの実行経験を有していない場合には（ステップＳ１３０：ＮＯ）、バトル処理の説明情報の全てを含む（つまり、バトル処理の説明情報の情報量が制限されていない）ウェブページがユーザの通信端末１０上に表示される。また、ＣＰＵ２１は、メニューｍ１１が選択操作されると（ステップＳ１８０：ＹＥＳ）、全ての処理について説明情報が提供されたか否かを判別する（ステップＳ１９０）。ここで、ＣＰＵ２１は、全ての処理の説明情報を提供した判別する（ステップＳ１９０：ＹＥＳ）。
　次に、ＣＰＵ２１は、全ての処理の説明情報を提供した判別すると、ステップＳ１００で選択操作されたメニューに対応する処理の実行を開始する。なお、ＣＰＵ２１は、ステップＳ１１０においてユーザがゲームＡの実行経験を有すると判別した場合（ステップＳ１１０：ＮＯ）、ステップＳ１００で選択操作されたメニューに対応する処理の実行を開始する。

　なお、上述したフローでは、ユーザが実行経験を有する他のゲーム（ゲームＢ）に関する情報（実行状況管理データ）を取得した後に、関連度データを取得して、他のゲームとゲームＡとの仕様の関連度に基づいて説明情報の情報量を制限する場合を一例として説明したが、処理内容はこの場合に限られず、上記フローと異なっていてもよい。例えば、上記フローのステップＳ１２０の処理とステップＳ１４０の処理の順序を入れ替えてもよい。この場合における処理内容の一例を説明する。先ず、関連度データを取得して、ゲームＡと仕様の関連度の高い他のゲームを関連度データから抽出する。そして、実行状況管理データを取得して、ユーザによる他のゲームの実行経験の有無を判別し、当該他のゲームの実行経験を有する場合に、当該他のゲームとゲームＡとの仕様の関連度に基づいて説明情報の情報量を制限するようにしてもよい。

　上述したように、実施形態のゲーム制御装置によれば、ゲームＡを実行するユーザに対してゲームＡの仕様を説明するための説明情報が提供される際に、ゲームＡと、ユーザが実行経験を有するゲームＢとの間の仕様の関連度に関する情報に基づいて、説明情報の情報量が制限される。この場合、ユーザは、ゲームＡの仕様についての説明を例えば省略することができ、ゲームＡを円滑に進行することができる。これにより、ユーザは、ゲームＡの仕様についての説明に対する煩わしさを低減することができ、さらには、ゲームＡに対するユーザの興味を維持することができる。

　（９）変形例
　上述した実施形態では、ゲームＡにおけるチュートリアルにおいて、ゲームＢとの間の仕様の関連度に基づいてチュートリアルの情報量が制限される場合を例として説明したが、これに限られない。例えば、ユーザがゲームＡの実行経験を有する場合に、ゲームＢにおけるチュートリアルにおいて、ゲームＡとの間の仕様の関連度に基づいて、ゲームＢの仕様についての説明情報の情報量が制限されるように構成されてもよい。

　また、上述した実施形態では、ゲーム制御装置を情報処理装置の一例として説明したが、これに限られない。例えば、ユーザがソフトウェアＣの利用経験を有する場合に、ソフトウェアＤにおけるチュートリアルにおいて、ソフトウェアＣとソフトウェアＤとの間の仕様の関連度に基づいて、ソフトウェアＤの仕様についての説明情報の情報量が制限されるように構成されてもよい。ここで、ソフトウェアの仕様についての説明情報には、例えば、当該ソフトウェアの利用手順に関する情報や、ソフトウェアの構成（例えば、対応する周辺機器、ユーザインタフェースなど）、機能、性能、アルゴリズムなどが含まれてもよい。
　以下、上述した実施形態の変形例について説明する。

　（９－１）変形例１
　上記実施形態のゲーム制御装置の変形例１の機能ブロック図を図１９に示す。図１９に示すように、この機能ブロック図は、図１７に示したものとは受付手段５６が追加された点で異なる。受付手段５６は、関連度に関する情報に基づいて、ユーザに対して説明情報（第１情報）を提供するか否かの選択を受け付ける機能を備える。
　また、本変形例において、制限手段５５は、ユーザに対して説明情報を提供しないように選択された場合に、前記ユーザに対する説明情報の情報量を制限する機能を備える。
　この場合、例えばユーザがゲームＢの仕様を理解していた場合であっても、ユーザは、ゲームＡの仕様についての説明情報の提供を受けるか否かを自ら選択することができる仕組みとすることができる。

　本変形例における受付手段５６の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、例えば、図１８のフローのステップＳ１４０の処理において関連度データを取得すると、関連度データを参照して、ゲームＡとゲームＢの仕様の関連度が所定の閾値（例えば０．５）以上であるか否かを判別する。そして、ＣＰＵ２１は、関連度が所定の閾値以上であると判別した場合に、図２０に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。図２０に例示したウェブページには、ゲームＡの仕様を説明するためのチュートリアルを省略するか否かの選択を促すためのメッセージと、「省略する」と表記されたメニューｍ１２と、「省略しない」と表記されたメニューｍ１３などが含まれる。なお、図２０のウェブページには、例えば「ゲームＡの進め方はゲームＢと同じです。」などのように、ゲームＡとゲームＢの仕様が関連していることを通知するためのメッセージなどが含まれてもよい。
　ここで、ユーザがメニューｍ１２を選択操作した場合には、本変形例の制限手段５５では、ＣＰＵ２１は、例えばチュートリアルを終了して、ステップＳ１００で選択操作されたメニューに対応する処理の実行を開始してもよい。
　一方、ユーザがメニューｍ１３を選択操作した場合には、ＣＰＵ２１は、ステップＳ１４０の処理に移行してもよい。

　（９－２）変形例２
　上記実施形態において、取得手段５４は、ユーザによるゲームＢ（第２ゲーム）の実行状況に基づいて、関連度に関する情報を取得してもよい。
　ここで、「ゲームＢの実行状況」とは、例えば、ユーザが、ゲームＢ上で制覇（クリア）したパートの数であってもよいし、ユーザが、ゲームＢ上の対戦において他のユーザあるいはキャラクタに勝利した数であってもよい。また、「ゲームＢの実行状況」とは、例えば、ユーザがゲームＢ上で獲得した特定のアイテムの数であってもよいし、ゲームＢの進行度や技能レベルの高さなどであってもよい。
　例えば、ユーザによるゲームＢの実行状況がある程度進んでいる場合、ゲームＢの仕様に対する当該ユーザの理解度が高いと考えられる。また、ゲームＡとゲームＢの仕様が関連又は共通する場合には、当該ユーザは、関連度に関する情報に基づいてゲームＡの説明情報の情報量が制限されたとしても、ゲームＢの仕様に基づいてゲームＡの仕様を想定することが可能である。一方、ユーザによるゲームＢの実行状況が進んでいない場合、当該ユーザは、ゲームＢの仕様に対する理解度が低いと考えられる。この場合、ユーザは、関連度に関する情報に基づいてゲームＡの説明情報の情報量が制限されると、ゲームＡの仕様を理解することが困難になり、結果としてゲームＡを実行しなくなるおそれがある。
　本変形例では、関連度に関する情報を取得するか否か、すなわち関連度に関する情報に基づいてゲームＡの説明情報の情報量を制限するか否かを、ユーザによるゲームＢの実行状況、すなわちゲームＢの仕様の理解度に基づいて決定する仕組みとすることができる。

　本変形例における取得手段５４の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、図１８のフローのステップＳ１２０の処理において実行状況管理データを取得すると、実行状況管理データを参照して、ユーザによるゲームＢの実行状況が所定の条件を満たすか否かを判別する。ここで、所定の条件とは、例えば、ゲームＢ上で制覇（クリア）したパートが所定数以上であることとしてもよいし、ユーザが、ゲームＢ上の対戦において他のユーザあるいはキャラクタに勝利した数が所定数以上であることとしてもよい。また、所定の条件とは、例えば、ユーザがゲームＢ上で獲得した特定のアイテムの数が所定数以上であることとしてもよいし、ゲームＢの進行度や技能レベルの高さなどが所定の閾値以上であることとしてもよい。
　ＣＰＵ２１は、ユーザによるゲームＢの実行状況が所定の条件を満たす場合、ステップＳ１４０の処理に移行して、関連度データを取得する。
　一方、ＣＰＵ２１は、ユーザによるゲームＢの実行状況が所定の条件を満たしていない場合、ステップＳ１４０の処理を行わず（つまり、関連度データを取得せず）にステップＳ１５０の処理に移行する。この場合、図１６のステップＳ１～Ｓ３のウェブページでは、それぞれの処理に対応する説明情報の全てが表示領域１００に表示される。

　（９－３）変形例３
　上記変形例２において、ゲームＢ（第２ゲーム）の実行状況は、ユーザによるゲームＢの実行回数を含み、取得手段５４は、ユーザによるゲームＢの実行回数が所定回数以上の場合に、関連度に関する情報を取得してもよい。
　例えば、ユーザによるゲームＢの実行回数が多いほど、ゲームＢの仕様に対する当該ユーザの理解度が高いと考えられる。本変形例では、ユーザによるゲームＢの実行回数が所定回数以上の場合に、関連度に関する情報が取得され、当該関連度に関する情報に基づいて説明情報の情報量が制限される。これにより、ゲームＢの仕様を理解しているユーザは、第１ゲームの仕様についての説明に対する煩わしさを低減することができる。

　本変形例における取得手段５４の機能を実現するに当たり、実行状況管理データには、ユーザＩＤごとに、複数のゲーム（ゲームＡ、ゲームＢ、…）それぞれの処理の実行回数が記録されてもよい。例えば、ゲームＡのクエスト処理の実行回数は、図１３に示すウェブページにおけるメニューｍ１０の選択回数を計数することによりもとめられてもよいし、ゲームＢのスカウト処理の実行回数は、図１５に示すウェブページにおけるメニューｍ２４の選択回数を計数することによりもとめられてもよい。
　ゲームサーバ２０ａのＣＰＵ２１は、図１８のフローのステップＳ１２０の処理において実行状況管理データを取得すると、実行状況管理データを参照して、当該ユーザによるゲームＢの実行回数が所定回数以上であるか否かを判別する。ここで、ゲームＢの実行回数は、例えば、ゲームＢに含まれる複数の処理（スカウト処理、強化処理、試合処理）の実行回数の合計であってもよいし、当該複数の処理のうち少なくとも一つの処理の実行回数の合計であってもよい。
　ＣＰＵ２１は、ユーザによるゲームＢの実行回数が所定回数以上である場合、ステップＳ１４０の処理に移行して、関連度データを取得する。
　一方、ＣＰＵ２１は、ユーザによるゲームＢの実行回数が所定回数未満である場合、ステップＳ１４０の処理を行わず（つまり、関連度データを取得せず）にステップＳ１５０の処理に移行する。

　（９－４）変形例４
　上記変形例２または変形例３において、ゲームＢ（第２ゲーム）の実行状況は、ユーザによるゲームＢの最新の実行時期からの経過時間を含み、取得手段５４は、ユーザによるゲームＢの最新の実行時期からの経過時間が所定時間以内の場合に、関連度に関する情報を取得してもよい。
　例えば、ユーザによるゲームＢの最新の実行時期からの経過時間が短いほど、当該ユーザはゲームＢの仕様の記憶の程度が高いと考えられる。本変形例では、ユーザによるゲームＢの最新の実行時期からの経過時間が所定時間以内の場合に、関連度に関する情報が取得され、当該関連度に関する情報に基づいて説明情報の情報量が制限される。これにより、ゲームＢの仕様の記憶の程度が高いユーザは、ゲームＡの仕様についての説明に対する煩わしさを低減することができる。

　本変形例における取得手段５４の機能を実現するに当たり、実行状況管理データには、ユーザＩＤごとに、複数のゲーム（ゲームＡ、ゲームＢ、…）それぞれの処理の最新の実行時期が記録されてもよい。例えば、ゲームＡのクエスト処理の最新の実行時期は、図１３に示すウェブページにおけるメニューｍ１０の最新の選択日時であってもよいし、ゲームＢのスカウト処理の最新の実行時期は、図１５に示すウェブページにおけるメニューｍ２４の最新の選択日時であってもよい。
　ゲームサーバ２０ａのＣＰＵ２１は、図１８のフローのステップＳ１２０の処理において実行状況管理データを取得すると、実行状況管理データを参照して、当該ユーザによるゲームＢの最新の実行時期からの経過時間が所定時間（例えば７２時間）以下であるか否かを判別する。ここで、ゲームＢの最新の実行時期からの経過時間は、例えば、ゲームＢに含まれる複数の処理（スカウト処理、強化処理、試合処理）の実行時期のうち最新の実行時期からの経過時間であってもよい。
　ＣＰＵ２１は、ユーザによるゲームＢの最新の実行時期からの経過時間が所定時間以下である場合、ステップＳ１４０の処理に移行して、関連度データを取得する。
　一方、ＣＰＵ２１は、ユーザによるゲームＢの最新の実行時期からの経過時間が所定時間を越えた場合、ステップＳ１４０の処理を行わず（つまり、関連度データを取得せず）にステップＳ１５０の処理に移行する。

　（９－５）変形例５
　上記実施形態又は変形例１において、制限手段５５は、関連度に関する情報と、ユーザによるゲームＢ（第２ゲーム）の実行状況とに基づいて、前記ユーザに対する説明情報の情報量を制限してもよい。
　例えば、ゲームＡとゲームＢの仕様が関連又は共通し、且つ、ユーザによるゲームＢの実行状況がある程度進んでいた（つまり、ゲームＢの仕様を理解していた）場合、当該ユーザにとっては、ゲームＢの仕様に基づきゲームＡの仕様を想定できるのでゲームＡの説明情報が不要であり、逆にゲームＡの説明情報が提供されることによって煩わしさを感じることが考えられる。
　本変形例によれば、関連度に関する情報と、ユーザによるゲームＢの実行状況とに基づいて、ゲームＡの説明情報の情報量を制限することができるので、例えばゲームＢの実行状況がある程度進んでいることによりゲームＢの仕様を理解しているユーザは、ゲームＡの仕様についての説明を例えば省略することができ、当該説明に対する煩わしさを低減することができる。

　本変形例における制限手段５５の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、例えば、図１８のフローのステップＳ１６０の処理において、ユーザによるゲームＢの実行状況と、ゲームＡとゲームＢとの間の仕様の関連度とに基づいて、説明情報の情報量を制限する。例えば、ゲームＢの実行状況が進むほど（例えば、ゲームＢ上で制覇（クリア）したパートの数、ゲームＢ上の対戦において他のユーザあるいはキャラクタに勝利した数、あるいはゲームＢ上で獲得した特定のアイテムの数など多いほど）、及び、仕様の関連度のうち少なくともいずれかが高いほど、説明情報の情報量が多く制限されるようにしてもよい。また、説明情報のうち制限される情報の量は、所定の演算式等を用いて、ゲームＢの実行状況の進度と、仕様の関連度とを当該演算式に当てはめることで求められてもよい。

　また、制限手段５５は、ゲームＡ以外の他のゲームであって、ユーザが実行経験を有する他のゲームが複数存在する場合には、複数の他のゲームのうち、ゲームＡとの間の仕様の関連度が所定の閾値（例えば０．５）以上のゲームの数に基づいて、ゲームＡの説明情報の情報量を制限してもよい。例えば、複数の他のゲームのうち、ゲームＡとの間の仕様の関連度が所定の閾値以上のゲームの数が多いほど、説明情報の情報量が多く制限されてもよい。
　さらに、制限手段５５は、ゲームＡ以外の他のゲームであって、ユーザが実行経験を有する他のゲームが複数存在する場合には、複数の他のゲームのうち、ゲームＡとの間の仕様の関連度が所定の閾値（例えば０．５）以上であり、且つ、当該ユーザによる実行状況が所定の条件を満たすゲームの数に基づいて、ゲームＡの説明情報の情報量を制限してもよい。

　（９－６）変形例６
　上記変形例５において、ゲームＢ（第２ゲーム）の実行状況は、ユーザによるゲームＢの実行回数を含み、制限手段５５は、関連度に関する情報と、前記ユーザによるゲームＢの実行回数とに基づいて、前記ユーザに対する説明情報（第１情報）の情報量を制限してもよい。
　例えば、ユーザによるゲームＢの実行回数が多いほど、ゲームＢの仕様に対する当該ユーザの理解度が高いと考えられる。本変形例では、例えば、ユーザによるゲームＢの実行回数が多いほど（ゲームＢの仕様に対する当該ユーザの理解度が高いほど）、ゲームＡの説明情報の情報量を多く制限することができる仕組みとすることができる。この場合、ユーザはゲームＡの仕様についての説明をほぼ省略することができるので、当該ユーザに煩わしさを感じさせないようにすることができる。

　本変形例における制限手段５５の機能は、例えば以下のようにして実現される。なお、ここでは、上述した変形例３と同様に、ユーザＩＤごとに、複数のゲーム（ゲームＡ、ゲームＢ、…）それぞれの処理の実行回数が実行状況管理データに記録されてもよい。ゲームサーバ２０ａのＣＰＵ２１は、例えば、図１８のフローのステップＳ１６０の処理において、ユーザによるゲームＢの実行回数と、ゲームＡとゲームＢとの間の仕様の関連度とに基づいて、説明情報の情報量を制限する。例えば、ゲームＢの実行回数、及び、仕様の関連度のうち少なくともいずれかが高いほど、説明情報の情報量が多く制限されるようにしてもよい。また、説明情報のうち制限される情報の量は、所定の演算式等を用いて、ゲームＢの実行回数と、仕様の関連度とを当該演算式に当てはめることで求められてもよい。

　（９－７）変形例７
　上記変形例５又は変形例６において、ゲームＢ（第２ゲーム）の実行状況は、ユーザによるゲームＢの最新の実行時期からの経過時間を含み、制限手段５５は、関連度に関する情報と、前記ユーザによるゲームＢの最新の実行時期からの経過時間とに基づいて、前記ユーザに対する説明情報（第１情報）の情報量を制限してもよい。
　例えば、ユーザによるゲームＢの最新の実行時期からの経過時間が短いほど、当該ユーザはゲームＢの仕様の記憶の程度が高いと考えられる。本変形例では、例えば、ユーザによるゲームＢの最新の実行時期からの経過時間が短いほど（ゲームＢの仕様に対する当該ユーザの記憶の程度が高いほど）、ゲームＡの説明情報の情報量を多く制限することができる仕組みとすることができる。この場合、ユーザはゲームＡの仕様についての説明をほぼ省略することができるので、当該ユーザに煩わしさを感じさせないようにすることができる。

　本変形例における制限手段５５の機能は、例えば以下のようにして実現される。なお、ここでは、上述した変形例４と同様に、ユーザＩＤごとに、複数のゲーム（ゲームＡ、ゲームＢ、…）それぞれの処理の最新の実行時期が実行状況管理データに記録されてもよい。ゲームサーバ２０ａのＣＰＵ２１は、例えば、図１８のフローのステップＳ１６０の処理において、ユーザによるゲームＢの最新の実行時期からの経過時間と、ゲームＡとゲームＢとの間の仕様の関連度とに基づいて、説明情報の情報量を制限する。例えば、ゲームＢの最新の実行時期からの経過時間が短いか、又は、仕様の関連度が高いほど、説明情報の情報量が多く制限されるようにしてもよい。また、説明情報のうち制限される情報の量は、所定の演算式等を用いて、ゲームＢの最新の実行時期からの経過時間と、仕様の関連度とを当該演算式に当てはめることで求められてもよい。

　（９－８）変形例８
　上記実施形態のゲーム制御装置の変形例８の機能ブロック図を図２１に示す。図２１に示すように、この機能ブロック図は、図１７に示したものとは第２情報提供手段５７が追加された点で異なる。第２情報提供手段５７は、関連度に関する情報に基づいて、他のゲーム（第２ゲーム）に関する関連ゲーム情報（第２情報）をユーザに提供する機能を備える。
　本変形例では、ユーザには、ゲームＡと、当該ユーザが実行経験を有する他のゲーム（ここでは、ゲームＢとする。）との間の仕様の関連度に関する情報に基づいて、ゲームＢに関する関連ゲーム情報が提供される。この場合、ユーザは、ゲームＢの実行経験を有することにより、ゲームＢの仕様を理解していると考えられる。このため、ユーザは、ゲームＡの仕様についての説明情報が提供される際に、ゲームＢの仕様に基づいてゲームＡの仕様を想定することができる。

　第２情報提供手段５７の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、関連度データを取得すると、関連度データを参照して、ゲームＡとゲームＢの仕様の関連度が所定の閾値（例えば０．５）以上であるか否かを判別する。そして、ＣＰＵ２１は、仕様の関連度が所定の閾値以上であると判別した場合に、ゲームＢに関する関連ゲーム情報を生成する。ここで、関連ゲーム情報は、ゲームＡとゲームＢの間で仕様が関連又は共通する処理を対応付けるように生成されてもよく、例えば『「クエスト」の進め方は、ゲームＢの「スカウト」と同じです。』などのメッセージが含まれるように生成されてもよい。また、関連ゲーム情報は予め生成された状態でデータベースサーバ３０ａ内のゲームデータベース３２に記憶されていてもよく、ＣＰＵ２１は、仕様の関連度が所定の閾値以上であると判別した場合に、ゲームデータベース３２から関連ゲーム情報を取得してもよい。
　また、ＣＰＵ２１は、関連ゲーム情報を生成すると、第１情報提供手段５３の機能により表示されるウェブページに関連ゲーム情報を含むようにＨＴＭＬデータを生成する。この場合、通信端末１０上に表示されるウェブページの例を、図２２Ａ，図２２Ｂにそれぞれ示す。例えば、図１６のステップＳ１に示すウェブページの代わりに、図２２Ａに示すウェブページが表示されてもよい。図２２Ａのウェブページには、表示領域１００と、ゲームＡと異なる他のゲーム（図の例ではゲームＢ）に関する関連ゲーム情報が表示される表示領域１０１と、「次へ」と表記されたメニューｍ１１などが含まれる。また、例えば、説明情報の情報量がゼロになるように制限された場合には、図２２Ｂに示すように、説明情報をウェブページに含まなくてもよい。
　なお、本実施形態では、関連ゲーム情報がテキストデータで構成された場合を一例として説明したが、関連ゲーム情報は、例えば、画像データや音声データなどで構成されてもよい。

　（９－９）変形例９
　上記実施形態において、第２情報提供手段５７は、ゲームＡ（第１ゲーム）と異なる他のゲーム（第２ゲーム）が複数存在する場合に、複数の他のゲームのうちゲームＡの仕様との関連度が所定の条件を満たすゲームについての関連ゲーム情報（第２情報）を、ユーザに提供してもよい。
　例えば、ユーザが複数の他のゲームの仕様を理解していた場合には、複数の他のゲームのうちゲームＡの仕様との関連度が高い（所定の条件を満たす）ゲームについての関連ゲーム情報が提供されることにより、ユーザは、複数の他のゲームの中からゲームＡの仕様との関連度が高い他のゲームを絞り込むことができる。これにより、ユーザは、絞り込まれた他のゲームの仕様に基づいてゲームＡの仕様を早期に想定することができる。

　本変形例における第２情報提供手段５７の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、図１８のフローのステップＳ１４０の処理において関連度データを取得すると、関連度データを参照して、ゲームＡとゲームＡ以外の他のゲームの仕様の関連度が所定の条件を満たすか否かを判別する。ここで、所定の条件とは、例えば、ゲームＡとの間の仕様の関連度が所定の閾値（例えば０．５）以上であることとしてもよいし、ゲームＡとの間の仕様の関連度が大きい順に所定番目位内であることとしてもよい。
　そして、ＣＰＵ２１は、ゲームＡとの間の仕様の関連度が所定の条件を満たす他のゲームを抽出する。また、ＣＰＵ２１は、図１８のフローのステップＳ１６０の処理において、抽出した他のゲームについての関連ゲーム情報を生成して、ユーザの通信端末１０宛に送信する。なお、ゲームＡとの間の仕様の関連度が所定の条件を満たす他のゲームが複数存在する場合には、それぞれの他のゲームに関する関連ゲーム情報を生成して、ユーザに提供してもよい。

　（９－１０）変形例１０
　上記実施形態において、第２情報提供手段５７は、ゲームＡ（第１ゲーム）と異なる他のゲーム（第２ゲーム）が複数存在する場合に、複数の他のゲームのうち、ユーザによる実行状況が所定の条件を満たすゲームについての関連ゲーム情報（第２情報）を、前記ユーザに提供してもよい。
　例えば、ユーザに対して、複数の他のゲームのうちユーザによる実行状況がある程度進んだ（所定の条件を満たす）ゲームについての関連ゲーム情報が提供されることにより、ユーザは、複数の他のゲームの中から、仕様を理解しているゲームを絞り込むことができる。これにより、ユーザは、仕様を理解している他のゲームの仕様に基づいてゲームＡの仕様を早期に想定することができる。

　本変形例における第２情報提供手段５７の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、図１８のフローのステップＳ１２０の処理において、統括サーバ４０から実行状況管理データを取得すると、実行状況管理データを参照して、当該ユーザによるゲームＡ以外の他のゲームの実行状況が所定の条件を満たすか否かを判別する。ここで、所定の条件とは、例えば、ゲーム上で制覇（クリア）したパートが所定数以上であることとしてもよいし、ユーザが、ゲーム上の対戦において他のユーザあるいはキャラクタに勝利した数が所定数以上であることとしてもよい。また、所定の条件とは、例えば、ユーザがゲーム上で獲得した特定のアイテムの数が所定数以上であることとしてもよいし、ゲームの進行度や技能レベルの高さなどが所定の閾値以上であることとしてもよい。
　ＣＰＵ２１は、ユーザによる他のゲームの実行状況が所定の条件を満たし、且つ、当該他のゲームとゲームＡの仕様の関連度が所定の閾値（例えば０．５）以上である場合に、当該他のゲームに関する関連ゲーム情報を生成すればよい。なお、実行状況が所定の条件を満たし、且つ、ゲームＡとの間の仕様の関連度が前記閾値以上の他のゲームが複数存在する場合には、それぞれの他のゲームに関する関連ゲーム情報を生成して、ユーザに提供してもよい。

　以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。上記実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。

　例えば、上述した実施形態では、実行対象のゲームがデジタルカードゲームである場合の例について説明したが、これに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲーム、テーブルゲーム、パズルゲーム、スポーツゲーム、レースゲーム、シューティングゲーム、アクションゲーム、アドベンチャーゲーム、シミュレーションゲームなどの各種ジャンルのゲームにおいて、ゲームを実行するユーザに対して、当該ゲームの仕様を説明するための情報が提供されるように構成されている場合には、上記実施形態の構成を好適に適用することができる。

　上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインコミュニケーションシステムにおいても、上述した実施形態と同様に、ユーザによるゲームの進行を制御できることは言うまでもない。
　また、例えば、家庭用ゲーム機がオフライン状態の場合であっても、上述した実施形態と同様に、ユーザによるゲームの進行を制御することができる。この場合における一つの具体例を説明すると、例えば、ゲームＸのソフトウェア、及びゲームＸとゲームＹとの間の仕様の関連度に関する情報が記憶された記憶媒体（例えば半導体メモリや光ディスクなど）と、家庭用ゲーム機とを用いて、ユーザがゲームＸを実行する場合、家庭用ゲーム装置は、ゲームＸのソフトウェアの実行に基づいて、当該家庭用ゲーム機に設けられた記憶装置を参照して、ゲームＹの実行履歴が存在するか否かを判別するように動作する。そして、ゲームＹの実行履歴が存在する場合には、ゲームＸとゲームＹとの間の仕様の関連度に関する情報に基づいて、ゲームＸにおけるチュートリアルの情報量が制限される。このように、家庭用ゲーム機がオフライン状態の場合であっても、上記実施形態と同様の制御を行うことが可能である。

　上述した実施形態では、例えば選択肢の選択操作などの所定の操作入力は、ユーザの通信端末に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えた通信端末を振ることによる操作入力、あるいはジェスチャによる操作入力（ジェスチャ入力）であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末に対する所定のジェスチャを行うことで通信端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能な通信端末の場合には、操作入力は、音声を入力することにより行われてもよい。

　上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、第１情報提供手段５３、取得手段５４及び第２情報提供手段５７の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。例えば、図２４Ａ，図２４Ｂにはそれぞれ、図１８に示した機能ブロック図の各機能について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との機能分担の例を示す。なお、上述した実施形態では、各種データ（例えば、仕様データや関連度データなど）を、データベースサーバ３０（ゲームデータベース３２）あるいは統括サーバ４０（ＨＤＤ４４）が記憶している構成としたが、通信端末１０内の記憶装置に記憶させてもよい。その場合には、記憶装置は、通信端末１０内のＲＡＭ１３や図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置やフラッシュメモリ等であってよい。

Claims

　第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する第１情報提供手段と、
　前記第１ゲームと、前記ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報を取得する取得手段と、
　前記関連度に関する情報に基づいて、前記ユーザに対する前記第１情報の情報量を制限する制限手段と、
　を備えた、ゲーム制御装置。
　前記関連度に関する情報に基づいて、前記ユーザに対して前記第１情報を提供するか否かの選択を受け付ける受付手段を備え、
　前記制限手段は、前記ユーザに対して前記第１情報を提供しないように選択された場合に、前記ユーザに対する前記第１情報の情報量を制限することを特徴とする、
　請求項１に記載されたゲーム制御装置。
　前記取得手段は、前記ユーザによる前記第２ゲームの実行状況に基づいて、前記関連度に関する情報を取得することを特徴とする、
　請求項１または２に記載されたゲーム制御装置。
　前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの実行回数を含み、
　前記取得手段は、前記ユーザによる前記第２ゲームの実行回数が所定回数以上の場合に、前記関連度に関する情報を取得することを特徴とする、
　請求項３に記載されたゲーム制御装置。
　前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間を含み、
　前記取得手段は、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間が所定時間以内の場合に、前記関連度に関する情報を取得することを特徴とする、
　請求項３または４に記載されたゲーム制御装置。
　前記制限手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの実行状況とに基づいて、前記ユーザに対する前記第１情報の情報量を制限することを特徴とする、
　請求項１または２に記載されたゲーム制御装置。
　前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの実行回数を含み、
　前記制限手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの実行回数とに基づいて、前記ユーザに対する前記第１情報の情報量を制限することを特徴とする、
　請求項６に記載されたゲーム制御装置。
　前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間を含み、
　前記制限手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間とに基づいて、前記ユーザに対する前記第１情報の情報量を制限することを特徴とする、
　請求項６または７に記載されたゲーム制御装置。
　前記関連度に関する情報に基づいて、前記第２ゲームに関する第２情報を前記ユーザに提供する第２情報提供手段を備えたことを特徴とする、
　請求項１～８のいずれかに記載されたゲーム制御装置。
　前記第２情報提供手段は、前記第２ゲームが複数存在する場合に、複数の第２ゲームのうち前記第１ゲームの仕様との関連度が所定の条件を満たすゲームについての前記第２情報を、前記ユーザに提供することを特徴とする、
　請求項９に記載されたゲーム制御装置。
　前記第２情報提供手段は、前記第２ゲームが複数存在する場合に、複数の第２ゲームのうち前記ユーザによる実行状況が所定の条件を満たすゲームについての前記第２情報を、前記ユーザに提供することを特徴とする、
　請求項９または１０に記載されたゲーム制御装置。
　第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供するステップと、
　前記第１ゲームと、前記ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報を取得するステップと、
　前記関連度に関する情報に基づいて、前記ユーザに対する前記第１情報の情報量を制限するステップと、
　を備えた、ゲーム制御方法。
　コンピュータに、
　第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する機能、
　前記第１ゲームと、前記ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報を取得して記憶装置に記憶する機能、及び
　前記記憶装置を参照して、前記関連度に関する情報に基づいて、前記ユーザに対する前記第１情報の情報量を制限する機能、
　を実現させるためのプログラム。
　請求項１３に記載されたプログラムを記録したことを特徴とする、コンピュータ読み取り可能な記録媒体。
　通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
　第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する第１情報提供手段、
　前記第１ゲームと、前記ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報を取得する取得手段、
　前記関連度に関する情報に基づいて、前記ユーザに対する前記第１情報の情報量を制限する制限手段、
　の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
　ゲームシステム。
　第１ソフトウェアを利用するユーザに対して、前記第１ソフトウェアの仕様を説明するための第１情報を提供する第１情報提供手段と、
　前記第１ソフトウェアと、前記ユーザが利用経験を有する第２ソフトウェアとの間の仕様の関連度に関する情報を取得する取得手段と、
　前記関連度に関する情報に基づいて、前記ユーザに対する前記第１情報の情報量を制限する制限手段と、
　を備えた、情報処理装置。