JP2014147558A - ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム - Google Patents

Abstract

【課題】ユーザが既に進行させたことがあるゲームのパートを再度進行させる場合に、パート間のゲームの進行の連続性を損なうことなく、かつ比較的簡易に進行させることができるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供すること。
【解決手段】本発明のゲーム制御装置は、複数のパートからなるゲームの実行を制御するものであって、ユーザの操作入力に基づいて、ユーザによって複数のパートを進行させる第１進行手段と、複数のパートの各パートについて、ユーザが終了条件を満たしたか否かを判定する判定手段と、ユーザが終了条件を満たしたと判定されたパートのうち、ユーザの操作入力によらずに進行可能なパートを特定する特定手段と、特定手段によって特定されたパートについて、所定の進行条件でユーザの操作入力によらずに進行させる第２進行手段と、を備える。
【選択図】図１３

Description

本発明は、例えば複数のステージ、複数のエリア等の、複数のパートからなるゲームの実行を制御する技術に関する。

近年、特定のサービス提供者によるソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であって、かつウェブブラウザが搭載された通信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。

ソーシャルゲームの一例が下記の非特許文献１に記載されている。非特許文献１に記載されているソーシャルゲームは、複数のステージ（ダンジョン）で構成されており、ユーザが特定のステージ（ダンジョン）で敵キャラクタと遭遇し、その敵キャラクタを倒した場合にはモンスターキャラクタを入手できることや、得られるモンスターキャラクタはステージごとに決まっているため、繰り返し挑戦して目的のモンスターキャラクタを入手できることなどが記載されている。

スマホGameR Vol.01（株式会社 主婦と生活社、2013年1月2日発行）、36-37頁

上述した従来のソーシャルゲームのように、ステージ（ダンジョン）等のゲームのパートが複数設けられており、ユーザの操作入力に基づいて進行させていくゲームでは、各ステージでキャラクタ、アイテムあるいはポイントが得られるように構成されているため、ユーザはキャラクタ、アイテムあるいはポイントを取得する目的で、既にクリアしたステージを再度進行させたい場合がある。しかし、クリア済みのステージを進行させるために再度操作を行うことは、ユーザにとって面倒であり、かといってそのステージを再度進行させることなくキャラクタ、アイテムあるいはポイントが得られるようにしたのでは、ステージ間のゲームのシナリオの連続性を損ない、また再度進行させるステージの難易度の設定が適切でなくなる虞がある。

本発明は上述した観点に鑑みてなされたもので、ユーザが既に進行させたことがあるゲームのパートを再度進行させる場合に、パート間のゲームの進行の連続性を損なうことなく、かつ比較的簡易に進行させることができるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、複数のパートからなるゲームの実行を制御するゲーム制御装置である。
このゲーム制御装置は、
ユーザの操作入力に基づいて、前記ユーザによって前記複数のパートを進行させる第１進行手段（５１）と、
前記複数のパートの各パートについて、前記ユーザが終了条件を満たしたか否かを判定する判定手段（５２）と、
前記ユーザが終了条件を満たしたと判定されたパートのうち、前記ユーザの操作入力によらずに進行可能なパートを特定する特定手段（５３）と、
前記特定手段（５３）によって特定されたパートについて、所定の進行条件で前記ユーザの操作入力によらずに進行させる第２進行手段（５４）と、
を備える。

このゲーム制御装置において「パート」は、例えばダンジョン、ステージ、エリア、フロア等の、ゲームの一定の区切りとなる部分である。このゲーム制御装置において「ユーザの操作入力によらずに進行可能である」とは、進行の契機となる操作入力を排除するものではない。例えば、「ユーザの操作入力によらずに進行可能なパート」は、当該パートを複数のパートの中から選択する操作入力や、当該パートに対する進行開始を指示する操作入力が行われた後に、ユーザの操作入力によらずに進行可能なパートであればよい。
このゲーム制御装置において「終了条件」は、特に限定するものではない。例えば、ユーザが特定のパートをクリアした場合、若しくはクリアできなかった場合、又は特定のパートにおいて目標となっている条件（例えば、パラメータの上昇やアイテムの取得等）を満たした場合に、そのパートについての終了条件を満たしたと判定してもよい。
このゲーム制御装置において「進行条件」は、特に限定するものではない。例えば、一定の基準を満足する仮想的な操作入力となるように条件を決定することができる。この場合、一定の基準とは、例えば、ゲーム上のルールに基づく基準、ユーザに関するパラメータ、若しくはユーザがゲーム上で保有するオブジェクト（アイテム、キャラクタ等）のパラメータに基づく基準、又はゲームに設定されたパラメータ（例えば、残ＨＰや残り時間等）などに関する基準であってよい。

このゲーム制御装置で実現されるゲームでは、ユーザが複数のパートを順次進行させていき、各パートが終了条件を満たしたか否か判定される。例えば、特定のパートが終了条件を満たした場合、その次のパートに進行可能となる構成とすることができる。そしてユーザが終了条件を満たしたパートのうち特定のパートについては、ユーザは操作を行うことなく所定の進行条件で進行（以下、「自動進行」という。）させることができる。そのため、ユーザは、ユーザが既に進行させたことがあるゲームのパートを再度進行させる場合に、パート間のゲームの進行の連続性を損なうことなく、かつ比較的簡易に進行させることができるようになる。

上記ゲーム制御装置において、前記ユーザの操作入力に基づき、前記特定手段（５３）によって特定されたパートについて、前記ユーザの操作入力に基づいて進行させる第１進行モードと、前記ユーザの操作入力によらずに進行させる第２進行モードとの間で切り替える切り替え手段（５５）、を備えてもよい。
ユーザが自動進行させる場合には、予め決定された所定の進行条件で進行がなされるため、必ずしもユーザにとって有利に進行しない場合もある。そのような場合に、上記構成では、例えば第２進行モードから第１進行モードに切り替えて、進行中にユーザの操作を随時介入可能とすることができる。これによって、ユーザは、自身の操作を伴わない簡易なゲーム進行を行いつつ、必要に応じてゲームの進行に影響を与えるようにすることができ、簡易なゲームの進行中にもゲームへの没入感を維持することができる。

上記ゲーム制御装置において、前記ユーザがゲームを開始するときに、前記特定手段（５３）によって特定されたパートを前記ユーザに提示する提示手段（５６）、を備えてもよい。
この構成では、ユーザがゲームを開始する時点で、ユーザが自動進行可能なパートが提示されるため、当該パートを複数のパートの中から選択することが容易となる。

上記ゲーム制御装置において、前記特定手段（５３）によって特定されたパートについて、当該パートが終了条件を満たした時刻、若しくは当該パートが最初に特定された時刻から所定時間経過した場合、又は、前記第２進行手段（５４）による当該パートの進行が所定回数行われた場合に、前記第２進行手段（５４）による進行を制限する制限手段（５７）、備えてもよい。
ユーザが終了条件を満たしたパートについて制限なく何度でも自動進行させることができるとした場合には、ユーザにゲームの操作に慣れてもらうという観点では好ましくない場合がある。例えば、特定のパートを進行させるときに、アイテムやポイントを取得することが可能である場合、ユーザは既に終了条件を満たしたパートを繰り返し自動進行させることで、何度でもアイテムやポイントを取得することが可能となってしまい、結果的にゲームにおけるユーザの操作回数が減る虞がある。そこで、本構成では、一定の条件が成立する場合に、特定のパートを自動進行させることを制限することで、ユーザのゲームに対する習熟を促すようにする。

上記ゲーム制御装置において、ユーザ間を関係付ける関係付け手段（５８）、を備え、
前記特定手段（５３）は、前記ユーザと関係付けられたユーザの各パートの実行状況又は進行状況に基づいて、前記ユーザの操作入力によらずに進行可能なパートを特定してもよい。
この構成では、ユーザと関係付けられた他のユーザ（仲間という。）の実行状況又は進行状況に基づいてユーザが自動進行可能なパートが特定される。そのため、例えば、ユーザのゲームの進行状況では自動進行することができないパートに対しても、仲間のゲームの進行状況によっては、自動進行させることができるようになる。つまり、複数の関係付けられた仲間の間で協力してゲームを自動進行させることができるようになる。
なお、パートの「実行状況」は、例えばそのパートの仲間のアクセス履歴や実行結果等であってもよい。

上記ゲーム制御装置において、前記ゲームは、各パートを進行させることで、前記ユーザに関連付けられたパラメータ、又は前記ユーザが前記ゲーム上で保有するオブジェクトに関連付けられたパラメータが変動するようにしてもよい。
特定のパートを進行させることによってパラメータが変動するゲームの場合、ユーザは所望のパラメータ変動を実現する目的で、終了条件を満たしたパートを再度進行させることを動機付けられる。本発明のゲーム制御装置では、パートを再度進行させるときに自動進行可能であるため、上述したゲームで特に、パート間のゲームの進行の連続性を損なうことなく、かつ比較的簡易に進行させることができるという点がユーザにとってより効果的なものとなる。

本発明の第２の観点は、複数のパートからなり、かつ各パートを進行させることで前記ユーザに関連付けられたパラメータ、又は前記ユーザが前記ゲーム上で保有するオブジェクトに関連付けられたパラメータが変動するゲームの実行を制御するゲーム制御装置である。
このゲーム制御装置は、
ユーザの操作入力に基づいて、前記ユーザによって前記複数のパートを進行させる第１進行手段（５１）と、
前記複数のパートの各パートについて、前記ユーザが終了条件を満たしたか否かを判定する判定手段（５２）と、
前記ユーザが終了条件を満たしたと判定されたパートのうち、前記ユーザの操作入力によらずに進行可能なパートを特定する特定手段（５３）と、
前記特定手段（５３）によって特定されたパートについて、所定の進行条件で前記ユーザの操作入力によらずに進行させる第２進行手段（５４）と、
前記ユーザの操作入力に基づき、前記特定手段（５３）によって特定されたパートについて、前記ユーザの操作入力によらずに進行させる第１進行モードと、前記ユーザの操作入力に基づいて進行させる第２進行モードとの間で切り替える切り替え手段（５５）と、
を備える。

本発明の第３の観点は、複数のパートからなるゲームの実行を制御するゲーム制御方法である。
このゲーム制御方法は、
ユーザの操作入力に基づいて、前記ユーザによって前記複数のパートを進行させるステップと、
前記複数のパートの各パートについて、前記ユーザが終了条件を満たしたか否かを判定するステップと、
前記ユーザが終了条件を満たしたと判定されたパートのうち、前記ユーザの操作入力によらずに進行可能なパートを特定するステップと、
前記特定されたパートについて、所定の進行条件で前記ユーザの操作入力によらずに進行させるステップと、
を含む。

本発明の第４の観点は、複数のパートからなるゲームの実行を制御するために、コンピュータに、
ユーザの操作入力に基づいて、前記ユーザによって前記複数のパートを進行させる機能、
前記複数のパートの各パートについて、前記ユーザが終了条件を満たしたか否かを判定する機能、
前記ユーザが終了条件を満たしたと判定されたパートのうち、前記ユーザの操作入力によらずに進行可能なパートを特定する機能、及び、
前記特定されたパートについて、所定の進行条件で前記ユーザの操作入力によらずに進行させる機能、
を実現させるためのプログラムである。

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ−ＲＯＭやＣＤ−ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。

本発明の第５の観点は、通信端末（１０）と、当該通信端末（１０）との間で通信可能なサーバ（２０）とを含み、複数のパートからなるゲームの実行を制御するゲームシステムである。
このゲームシステムでは、
ユーザの操作入力に基づいて、前記ユーザによって前記複数のパートを進行させる第１進行手段（５１）、
前記複数のパートの各パートについて、前記ユーザが終了条件を満たしたか否かを判定する判定手段（５２）、
前記ユーザが終了条件を満たしたと判定されたパートのうち、前記ユーザの操作入力によらずに進行可能なパートを特定する特定手段（５３）、及び、
前記特定手段（５３）によって特定されたパートについて、所定の進行条件で前記ユーザの操作入力によらずに進行させる第２進行手段（５４）、
の各手段を、前記通信端末（１０）又は前記サーバ（２０）のいずれか一方が備える。

なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書きで記載しているが、これにより本発明に係るゲーム制御装置等が図示の態様に限定されるものではない。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、ユーザが既に進行させたことがあるゲームのパートを再度進行させる場合に、パート間のゲームの進行の連続性を損なうことなく、かつ比較的簡易に進行させることができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の外観の別の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 ユーザデータベースの構成例を示す図。 カード設定データの構成例を示す図。 ゲーム進行データの構成例を示す図。 ユーザの通信端末において表示されるゲーム画像を例示する図。 ユーザの通信端末において表示されるゲーム画像を例示する図。 ユーザの通信端末において表示されるゲーム画像を例示する図。 ユーザの通信端末において表示されるゲーム画像を例示する図。 ユーザの通信端末において表示されるゲーム画像を例示する図。 実施形態のゲーム制御装置の機能ブロック図。 実施形態のゲームの実行時に行われる処理（手動対戦）を示すフローチャート。 実施形態のゲームの実行時に行われる処理（自動対戦）を示すフローチャート。 実施形態のゲームの実行時に行われる処理を示すシーケンスチャート。 実施形態の変形例に係るゲーム制御装置の機能ブロック図。 実施形態の変形例においてユーザの通信端末において表示されるゲーム画像を例示する図。 実施形態の変形例に係るゲーム制御装置の機能ブロック図。 ゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。 ゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。

以下、本発明の実施形態について説明する。

１．第１の実施形態
（１）ゲームシステムの構成
図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）などの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。
このゲームシステムにおいて、ゲームサーバ２０は、クライアントである通信端末１０と通信可能に構成されており、通信端末１０がゲームの進行に必要なデータや、ゲームに付随したサービス（例えば、ソーシャルネットワーキングサービス等）を提供する。データベースサーバ３０は、ゲームに関連する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ２０と例えば有線で接続される。
通信端末１０は、ゲームサーバ２０によって提供されるゲーム用のデータを基にゲームを実行するためのゲーム用プログラムを備えている。ユーザは、通信端末１０に対して所定の操作を行ってゲームを実行する。

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

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

ＣＰＵ１１は、ＲＯＭ１２に記憶されているゲーム用プログラムをＲＡＭ１３にロードして実行する。ゲーム用プログラムの実行では、指示入力部１５からのユーザの操作入力の受付処理、通信インタフェース部１７を介したゲームサーバ２０との間のデータの送受信処理、ＲＯＭ１２からのデータの読み出し処理、ＲＡＭ１３のデータの読み書き処理、及び所定の演算処理等が行われる。ＣＰＵ１１はまた、各処理の結果を表示するためのゲーム画像用の画像データを生成して画像処理部１４に出力する。

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

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

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

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

（３）ゲームサーバの構成
図４を参照してゲームサーバ２０の構成について説明する。
ゲームサーバ２０は、クライアントである各ユーザの通信端末１０のゲーム起動時の認証、ゲームの進行に必要なデータの通信端末１０への提供、及び、ユーザ間のメッセージの送受信やアイテム交換等のソーシャルネットワーキングに関連する処理を実行する。
図４に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、及び、通信インタフェース部２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のネットワークサーバと同一の構成をとることができる。

ＲＯＭ２２には、上述したゲームサーバ２０の処理を実行するためのプログラムが格納されている。ＲＯＭ２２には、プログラム以外にもＣＰＵ２１によって参照される各種データが格納されている。
ＣＰＵ２１は、ＲＯＭ２２内のプログラムをＲＡＭ２３にロードして実行し、各種の処理を行う。ＣＰＵ２１は、処理内容に応じて、データベースアクセス部２４を介したデータベースサーバ３０からのデータの読み出し処理や、データベースサーバ３０へのデータの書き込み処理を行う。ＣＰＵ２１は、処理内容に応じて、通信インタフェース部２５を介して、各ユーザの通信端末１０との間のデータの送受信の処理を行う。例えば、ＣＰＵ２１は、通信端末１０から送信されるデータ要求メッセージに応じて、所定の処理によって得られたデータや、データベースサーバ３０から読み出したデータを含む応答メッセージを要求元の通信端末１０へ送信する。

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

本実施形態のゲームシステムによって実現されるゲームのタイプは特に限定されるものではないが、以下では、本実施形態のゲームの一例として、複数のステージからなる対戦ゲーム（以下、適宜「本実施形態のゲーム」という。）を採り上げる。本実施形態のゲームは、トランプゲームのポーカーの要素と、カードコレクションゲーム（本実施形態では、一例としてモンスターカードのコレクションとする。）の要素とを含むものである。
より詳細には後述するが、本実施形態のゲームにおいて、ユーザとその対戦相手には、対戦に使用する所定数の保有カード（モンスターカード）からなるグループ（「デッキ」ともいう。）が設定されている。モンスターカードには、ポーカー役に応じたダメージ値が設定されている。対戦では、ユーザとその対戦相手が交互にトランプカードをマトリクス状のマスに配置させる。ユーザと対戦相手のうち一方のトランプカードの配置によってポーカー役が成立した場合には、そのポーカー役に対応するグループ内のモンスターカードのダメージ値の総和が他方に与えられる（つまり、ＨＰ（Hit Point；体力）が低下する）。ユーザと対戦相手のうちＨＰがゼロになった方が負けとなる。

図６に、本実施形態のゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名、進行レベル、ＨＰ、経験値、アクションポイント、通貨ポイント、仲間のユーザＩＤの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。
以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目の情報は、以下のとおりである。

・ユーザ名
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名である。ユーザ名はユーザによって予め指定される所定長以下のテキストである。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・進行レベル
ゲーム上のユーザの進行レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。
・ＨＰ
ユーザの対戦時のＨＰの初期値である。例えば、進行レベルが増加する度に、ＨＰの値が増加するように設定してもよい。なお、ＨＰは進行レベルに応じて決定されても良い。ユーザ毎ではなくモンスターカード毎にＨＰを設定して、グループに含まれるモンスターカードのＨＰの合計値をそのグループを使用したときのユーザのＨＰとしても良い。
・経験値
経験値は、対戦で勝利することによって増加する値である。経験値が一定量に達すると、進行レベルが１つ増加するとともに経験値はリセットされる（つまり、ゼロになる）。
・アクションポイント
本実施形態のゲームを進行させる上で必要となるポイントである。アクションポイントは、１回の対戦の実行により所定量低減し、所定の時間が経過する毎に所定量回復（増加）する値である。
・通貨ポイント
通貨ポイントは、対戦で勝利することによって取得できるポイントである。通貨ポイントは、ゲーム上で使用可能な仮想通貨である。
・仲間のユーザＩＤ
対象となるユーザＩＤと関係付けられた他のユーザＩＤのデータである。

図５に戻り、ゲームデータベース３２は、カード設定データとゲーム進行データを記憶する。
カード設定データは、各ユーザの保有モンスターカードとそのカード設定を示すデータである。
図７に、カード設定データのデータ構成例を示す。図７に例示するカード設定データには、ユーザＩＤごとに、ユーザが保有する各モンスターカードのカードＩＤ（Ｃ００１等）と、グループフラグと、ダメージ値とが対応付けて記述されている。グループフラグは、対戦に使用される所定数のモンスターカードからなるグループに、対応するモンスターカードが含まれるか否かを示すフラグである。グループフラグは、例えば、グループに含まれる場合には「１」であり、グループに含まれない場合には「０」である。
各モンスターカードのダメージ値は、モンスターカードがグループに含まれる場合に、本実施形態のゲームにおいてポーカー役が成立した場合に、そのモンスターカードによって与えるポーカー役ごとのダメージ値を示している。例えば、ユーザＩＤ：０００００１のユーザの保有モンスターカードＣ０２４はグループに含まれているため、ユーザＩＤ：０００００１のユーザが対戦においてツーペアのポーカー役が成立した場合、対戦相手に対して「４」のダメージ値が与えられることを示す。なお、ユーザＩＤ：０００００１のユーザの保有モンスターカードＣ０２４には、「ワンペア」に対応する値が設定されていないため、対戦中に「ワンペア」が成立した場合であっても、このモンスターカードによって対戦相手に与えるダメージ値はゼロである。
なお、ポーカー役が成立しない場合であってもダメージ値が設定されていてもよい。また、モンスターカードのポーカー役ごとのダメージ値は、ポーカー役と関連付けて設定されていてもよい。より具体的には、ポーカー役ごとのダメージ値を、基準値に対してポーカー役に対応する係数を乗算した値としてもよい。例えば、以下のようにダメージ値を設定することで、高いポーカー役が成立するほどダメージ値が大きくなるようにすることができる。
［ダメージ値の設定例］
・役が成立せず：ダメージ値＝基準値×０．８
・ワンペア ：ダメージ値＝基準値×１．０
・ツーペア ：ダメージ値＝基準値×１．２
・スリーカード：ダメージ値＝基準値×１．６
…

ゲーム進行データは、各ユーザのゲームの進行状況を示すデータである。なお、本実施形態のゲームは、複数のステージからなり、各ステージがさらに複数のエリアに細分化されている。
図８に、ゲーム進行データのデータ構成例を示す。図８に例示するゲーム進行データには、ユーザＩＤごとに、エリア単位でユーザがクリアしたか否かを示すフラグが記述されている。ユーザがエリアをクリア済みの場合には、そのエリアに対応するフラグが「１」であり、ユーザがエリアをクリア済みでない場合には、そのエリアに対応するフラグが「０」である。
本実施形態において特定のエリア（パート）をクリアしたことは、本発明においてユーザが終了条件を満たしたことの一例である。
なお、本実施形態のゲームでは、ユーザが特定のステージ、特定のエリアをクリアすることが、その次のステージ、その次のエリアにゲームを進行させるための条件となっている。そのため、図８の例では、ユーザＩＤ：０００００１，０００００２，０００００３の各ユーザがそれぞれ、ステージ３のエリア３−２、ステージ１のエリア１−３、ステージ２のエリア２−２までゲームを進行させていることがわかる。

（５）本実施形態のゲーム
以下、本実施形態のゲームの内容について、図９〜１２を参照しながら説明する。図９は、本実施形態のゲームにおいて、ユーザがグループ編成を行うときに通信端末１０上に表示される一連のゲーム画像を示す図である。図１０は、本実施形態のゲームにおいて、ユーザが実行対象のエリアを選択するときに通信端末１０上に表示される一連のゲーム画像を示す図である。図１１Ａ及び図１１Ｂは、本実施形態のゲームにおいて、ユーザが対戦を行うときに通信端末１０上に表示される一連のゲーム画像を示す図である。図１２は、本実施形態のゲームにおいて、ユーザがクリア済みのステージを進行するときに通信端末１０上に表示されるゲーム画像を示す図である。
なお、各図では、処理対象のユーザがユーザ名：ＡＢＣのユーザ（以下、「ユーザＡＢＣ」という。）である場合を例にして説明する。

（５−１）グループ編成
図９のゲーム画像Ｄ０は、ユーザＡＢＣがゲームを起動したときに表示される。ゲーム画像Ｄ０には、ユーザＡＢＣのユーザデータを表示する表示領域１０１と、ゲームに用意されているメニュー群を表示する表示領域１０２とが設けられている。表示領域１０２には、メニューｍ１（「グループ編成」）とメニューｍ２（「クエスト」）が設けられている。なお、クエストとは、ユーザがステージを進行させていくための処理である。
ゲーム画像Ｄ０においてメニューｍ１（「グループ編成」）が選択されると、ゲーム画像Ｄ１が表示される。ゲーム画像Ｄ１において、表示領域２０１はユーザＡＢＣの現在のグループに含まれるモンスターカード群を表示する。表示領域２０２はユーザＡＢＣの保有モンスターカードであって現在のグループに含まれていないモンスターカード群を表示する。表示領域２０１，２０２に表示されているモンスターカード群からそれぞれ１枚のモンスターカードを入れ替えるために選択することができる。表示領域２０３は、ポーカー役ごとに現在のグループによって対戦相手に与えられるダメージ値の合計値が表示される。表示領域２０４は、表示領域２０１，２０２でそれぞれ選択されている１枚ずつのモンスターカードＣｘ，Ｃｙを入れ替えたときのグループによって、ポーカー役ごとに対戦相手に与えられるダメージ値の合計値が表示される。表示領域２０３，２０４によって、ユーザはモンスターカードを入れ替えたときの対戦能力の変化を認識することができる。
表示領域２０１，２０２においてそれぞれ１枚のモンスターカードが選択されている状態でメニューｍ３（「入れ替える」）が選択されると、選択されているモンスターカード同士の入れ替えが行われる。

（５−２）ステージ、エリアの選択
図１０のゲーム画像Ｄ０においてメニューｍ２（「クエスト」）が選択されると、ゲーム画像Ｄ２が表示される。ゲーム画像Ｄ２では、本実施形態のゲームに設けられる複数のステージ（ステージ１、ステージ２、ステージ３、…）を選択するメニューｍ１０，ｍ２０，ｍ３０，…が表示される。ゲーム画像Ｄ２において例えばメニューｍ３０（「ステージ３」）が選択されると、ゲーム画像Ｄ３が表示される。ゲーム画像Ｄ３には、選択されたステージ３に含まれる複数のエリア（エリア３−１、エリア３−２、エリア３−３）を選択するメニューｍ３１，ｍ３２，ｍ３３が表示される。ゲーム画像Ｄ３において例えばメニューｍ３３（「エリア３−３」）が選択されると、ゲーム画像Ｄ４が表示される。ゲーム画像Ｄ４には、エリア３−３内のマップと、エリア３−３で得られたもの（通貨ポイント、経験値、アイテム等）とが表示される。マップには、ユーザのエリア上の地点が示される。図１０に示す例では、エリア３−３では、地点Ｐ３３１，Ｐ３３２，Ｐ３３３，Ｐ３３４（ボス戦）の各地点を順にユーザが進行する。各地点での対戦に勝利しなければ次の地点に進むことはできない。各地点で勝利すると、所定の、あるいはランダムに決定される量の通貨ポイント、経験値や、アイテム（モンスターカードを含む）が得られる。ゲーム画像Ｄ４には、ユーザＡＢＣの現在のアクションポイントの値が表示されてもよい。

（５−３）対戦
図１１Ａのゲーム画像Ｄ５は、ユーザＡＢＣが自身で選択したエリア内の特定の地点において、対戦を行う場合のゲーム画像の一例である。対戦相手は他のユーザ又はＮＰＣであるが、本実施形態のゲームは、ユーザ間の対戦が、各ユーザの通信端末を同期させることなく（つまり、非同期で）行われる。そのため、対戦相手が他のユーザの場合であっても他のユーザの通信端末に対戦経過を表示することなく、他のユーザに設定されているグループのデータを利用して対戦が行われる。なお、対戦相手がＮＰＣの場合、予めゲームの運営者によって設定されているグループのデータを利用してもよいし、他の任意のユーザのグループのデータをコピーしてＮＰＣとして使用してもよい。

ゲーム画像Ｄ５には、トランプカードを置くための５×５のマスのマトリクス３０１が表示される。５×５のマスのマトリクス３０１の中央の３×３のマスには、対戦の開始時にトランプカードが配置されており、残りの１６個のマスにユーザＡＢＣ及び対戦相手のトランプカード（手札）が配置可能になっている。ユーザＡＢＣと対戦相手（この場合、ユーザＸＹＺ）には４枚のトランプカード（手札）が配られており、それぞれ領域３０３，３０５に表示される。領域３０２，３０４には、ユーザＡＢＣと対戦相手のＨＰ（現在の残りＨＰ／初期のＨＰ）が表示される。
ユーザＡＢＣのターンの場合、ユーザＡＢＣが自身の手札から２枚のトランプカードを５×５のマスの中の未だ配置されていないマスに配置してポーカー役を成立させる。ポーカー役の成立の判定は、マトリクス３０１のいずれかの縦、横、又は斜めに隣接する５マスに置かれた５枚のトランプカードによって行われる。ポーカー役が成立しないマスにトランプカードを配置させることはできない。なお、図示しないが、ポーカー役が成立するようにトランプカードが配置できない場合には、ユーザはゲーム画像上のパスの釦を操作することでパスすることができる。その場合には、攻撃のターンが対戦相手に移る。

ポーカー役が成立した場合、ユーザＡＢＣのグループ内の各モンスターカードの、そのポーカー役に応じたダメージ値の合計値が、対戦相手のＨＰから減算される。
例えば図１１Ａのゲーム画像Ｄ６では、ゲーム画像Ｄ５の状態から、ユーザＡＢＣが自身の手札から「スペードの９」と「ダイヤの１０」を選択してゲーム画像Ｄ６に示すように配置した場合が示される。ゲーム画像Ｄ６に示すようにトランプカードが配置された場合、横一列の５枚のトランプカードによってワンペアのポーカー役が成立する。この場合には、図１１Ｂのゲーム画像Ｄ７に示すように、ワンペアのポーカー役に対応するダメージ値の分、対戦相手のＨＰが減少する（８０→６５）。このダメージ値は、ユーザＡＢＣのグループに含まれるモンスターカードのワンペアに対応するダメージ値の合計値である。

ユーザＡＢＣの２枚のトランプカードの配置が終了すると、対戦相手のターンとなる。同様にして、対戦相手もマトリクス３０１内の未配置のマスにトランプカードを配置させることで、ユーザＡＢＣを攻撃する。次にユーザＡＢＣのターンとなる場合には、新たに２枚のトランプカードがランダムに決定されてユーザＡＢＣに配布され、４枚の手札の中から再度２枚のトランプカードを配置させる。
以上説明したようにして、ユーザＡＢＣと対戦相手のターンが交互生ずるターン制の対戦となっており、ユーザＡＢＣ又は対戦相手のいずれか一方のＨＰがゼロになるまで対戦が続く。なお、マトリクス３０１内のすべてのマスにトランプカードが配置された場合には、中央の３×３のマスのトランプカードを新たな組合せに更新し、かつ中央の３×３のマス以外のマスは未配置の状態にして対戦を継続する。その結果、ＨＰがゼロになった方が負けとなる。なお、所定の対戦時間を設定して、その対戦時間が経過した時点での残りＨＰが大きい方を勝ちとしてもよい。
ユーザが勝利した場合には、エリア内の次の地点へゲームを進行させることができる。

なお、ポーカーを利用した対戦は一例に過ぎず、トランプカードの手札の枚数、マトリクスのマスの数の設定、マトリクス上のトランプカードの初期配置等は、適宜変更することができる。例えば、ユーザ及び対戦相手の手札の枚数は４枚である場合に限られず、任意の枚数に設定してもよい。ユーザが１度に未配置のマスに配置可能なトランプカードの枚数は２枚に限られず、手札として設定された枚数の中から任意の枚数に設定することができる。
例えば、１０×１０のマスのマトリクスにおいて中央の２×２のマスにトランプカードが初期配置されている場合、２回以上のマスへの２枚のトランプカードの配置の結果、１０×１０のマスのマトリクス内のいずれかの位置で縦、横、又は斜めの隣接する５マスに置かれた５枚のトランプカードによってポーカー役の成立可否を判定してもよい。つまり、１回のトランプカードの配置によってポーカー役を成立させてなくてもよい。
ポーカー役が成立しないマスにトランプカードを配置させることはできない場合に限られない。ポーカー役が成立しないマスにもトランプカードを配置させてもよいが、ダメージ値はゼロであるとしてもよい。前述したように、ポーカー役が成立しない場合にダメージ値が設定されている場合には、ポーカー役が成立しないマスにトランプカードを配置可能とし、設定されているダメージ値の分、対戦相手のＨＰを減少させてもよい。

（５−４）クリア済みのステージの進行
本実施形態のゲームでは、ユーザがクリア済みのステージを再度進行させるときには、そのステージ内の対戦で、ユーザの操作入力によらないで対戦（以下、適宜「自動対戦」という。）を行うことができる。例えば図１２のゲーム画像Ｄ８に示すように、自動対戦を行うためのメニューｍ５０（「ＡＵＴＯ」）が設けられる。ユーザがメニューｍ５０を選択すると、所定の進行条件で自動対戦が行われる。つまり、ユーザが何らの操作を行うことなく、対戦を実行することができる。
以下、自動対戦によってゲームを進行させることを、適宜「自動進行」という。

（６）ゲーム制御装置における各処理の概要
次に、上述した本実施形態のゲームを実現するためゲーム制御装置における各処理について説明する。
本実施形態では、ユーザの通信端末１０、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述したゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図１３を参照して説明する。図１３は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。

第１進行手段５１は、ユーザの操作入力に基づいて、ユーザによって複数のエリアを進行させる機能を備える。エリアは、本発明のパートの一例である。
第１進行手段５１の機能は、以下のようにして実現できる。通信端末１０のＣＰＵ１１は、ユーザによる指示入力部１５に対する所定の操作入力に基づいてＲＯＭ１２からゲームプログラムをＲＡＭ１３してロードして起動する。ＣＰＵ１１は、プログラムを起動するとゲームサーバ２０との間で認証処理を行う。例えば、ＣＰＵ１１が通信インタフェース部１７を介してＵＩＤ（User Identifier）を送信し、ゲームサーバ２０のＣＰＵ２１が取得したＵＩＤを基に認証処理を行う。認証処理が完了すると、ゲームサーバ２０のＣＰＵ２１は、ゲームを進行させるためのデータとして、例えば、処理対象のユーザに対応する部分のユーザデータ、カード設定データ、及びゲーム進行データを通信端末１０へ送信する。

通信端末１０のＣＰＵ１１は、ユーザデータ、カード設定データ、及びゲーム進行データを受信すると、これらのデータをＲＡＭ１３に展開してユーザの操作入力を待つ。ユーザの操作入力がステージ、エリアの選択入力である場合には、ＣＰＵ１１は、例えばＲＡＭ１３内のゲーム進行データに基づいて、ユーザが実行可能なステージ、エリアを認識してゲーム画像を生成する。ユーザの操作入力がエリア内の特定の地点である場合には、ＣＰＵ１１は対戦処理を実行する。

対戦処理の実行に当たってＣＰＵ１１は、ゲームサーバ２０に対して、対戦処理の対象となるエリア内の特定の地点を指定して対戦相手のデータを要求し、当該要求に応じてゲームサーバ２０が通信端末１０に対して対戦相手のカード設定データ（より具体的には、モンスターカードのグループのデータ）を返す。通信端末１０へ送信されるカード設定データは、ＮＰＣとして予めエリアに対応付けて記憶されているグループのデータであってもよいし、予めエリアに対応付けて記憶されている複数のモンスターカードから所定の、又は、ランダムな条件で選択されたグループのデータであっても良いし、又は、カード設定データに記録されている他の任意のユーザのグループのデータをコピーして作成したものであってもよい。
ＣＰＵ１１は、処理対象のユーザと対戦相手の各ターンで入力データ（操作情報）を生成し、その入力データに基づいて所定の演算処理を実行する。ここで本実施形態のゲームでは、入力データは、処理対象のユーザ又は対戦相手の手札の４枚のトランプカードのうちの２枚のトランプカードと、その２枚のトランプカードを５×５のマスのマトリクスの中に配置させる位置とに対応するデータである。
処理対象のユーザの入力データは、そのユーザの指示入力部１５に対する操作入力信号に基づいて生成される。対戦相手の入力データは、所定の条件に従うようにして決定される。例えば本実施形態のゲームでは、対戦相手の入力データは、対戦相手の手札である４枚のトランプカードの中から最も高いポーカー役が成立するようなマスに２枚のトランプカードが配置されるようにして決定されてもよい。

本実施形態のゲームの場合、処理対象のユーザの入力データに基づく演算処理は、成立したポーカー役に対応する、当該ユーザのグループ内の各モンスターカードの、そのポーカー役に応じたダメージ値の合計値の算出処理、及び、対戦相手のＨＰからのその合計値の減算処理を含む。また、対戦相手の入力データに基づく演算処理は、成立したポーカー役に対応する、対戦相手のグループ内の各モンスターカードの、そのポーカー役に応じたダメージ値の合計値の算出処理、及び、処理対象のユーザのＨＰからのその合計値の減算処理を含む。

図１４に、処理対象のユーザのターンにおける対戦処理のフローチャートを示す。図１４のフローチャートは、通信端末１０のＣＰＵ１１によって実行される。
図１４において先ず、ＣＰＵ１１は、ユーザのターンである場合（ステップＳ１０：ＹＥＳ）、ユーザに配布する２枚のトランプカードを所定の規則に従って、あるいは無作為に選択する（ステップＳ１２）。次いでＣＰＵ１１は、ユーザによってパスの釦が選択されない場合（ステップＳ１４：ＮＯ）、ユーザの操作入力に基づいて、ユーザの手札の４枚のトランプカードの中から２枚のトランプカードのマスへの配置の入力処理を行う（ステップＳ１６）。ＣＰＵ１１は、５×５のマスのマトリクス内の縦、横、又は斜めのいずれか５枚のトランプカードによっていずれかのポーカー役が成立するか否かを判定する（ステップＳ１８）。ポーカー役が成立しない場合には（ステップＳ１８：ＮＯ）、ＣＰＵ１１はステップＳ１６のマスへの入力処理を無効としてステップＳ１４に戻り、ユーザの操作入力を待つ。

ポーカー役が成立する場合には（ステップＳ１８：ＹＥＳ）、ＣＰＵ１１はＲＡＭ１３内のカード設定データを参照して、ステップＳ１６で成立したポーカー役に対応する、処理対象のユーザのグループ内の各モンスターカードの、そのポーカー役に応じたダメージ値の合計値を算出する。次いでＣＰＵ１１は、対戦相手のＨＰからのその合計値を減算することによって、対戦相手のＨＰを更新する（ステップＳ２０）。最後にＣＰＵ１１は、対戦相手のＨＰがゼロに達したか否かを判定する対戦終了判定の処理を行って（ステップＳ２２）、終了する。なお、ユーザのターンでない場合（ステップＳ１０：ＮＯ）、及び、ユーザがパスの釦が選択された場合（ステップＳ１４：ＹＥＳ）も終了する。
ＣＰＵ１１は、上述したようにして対戦処理を実行することによって、ユーザによる各ステージ及び各エリアにおけるゲームを進行させる。

判定手段５２は、複数のエリアの各エリアについて、ユーザが終了条件を満たしたか否かを判定する機能を備える。
判定手段５２の機能は、以下のようにして実現できる。ユーザがエリアの最後の地点の対戦（ボス戦）で勝利した（つまり、エリアをクリアした）と判断した場合、通信端末１０のＣＰＵ１１は、ＲＡＭ１３内のゲーム進行データを更新する。具体的には、ＣＰＵ１１は、ユーザがクリアしたエリアのフラグを「０」（クリア済みでない）から「１」（クリア済み）に書き換える。ＣＰＵ１１は、ゲーム進行データにおいて各ステージ内のエリアに対応するフラグの値に基づいて、ユーザが各エリアについて終了条件を満たしたか否かを判定する。

ＣＰＵ１１は、対戦が終了するとＲＡＭ１３内のゲーム進行データを更新し、更新後のゲーム進行データを通信インタフェース部１７を介してゲームサーバ２０へ送信する。ゲームサーバ２０は、受信したゲーム進行データを基にゲームデータベース３２内のゲーム進行データを更新する。これによって、ゲーム実行中のゲーム進行データの同期が行われる。そのため、ユーザがゲームを中止してゲームの進行を停止させた後にゲームの進行を再開する場合には、ゲームサーバ２０から最新のゲーム進行データを取得してゲームの進行を継続させることができる。

特定手段５３は、ユーザが終了条件を満たしたと判定されたエリアのうち、自動進行可能なエリアを特定する機能を備える。本実施形態の一例では、すべてのエリアがクリア済みのステージ内の各エリアが自動進行可能なエリアとして特定される。
特定手段５３の機能は、以下のようにして実現できる。通信端末１０のＣＰＵ１１は、ＲＡＭ１３内の処理対象のユーザに対応するゲーム進行データを参照し、各ステージのすべてのエリアに対応するフラグが「１」（クリア済み）であるか否かを判定する。次いでＣＰＵ１１は、すべてのエリアに対応するフラグが「１」（クリア済み）であるステージの各エリアについて自動進行可能であると判断し、すべてのエリアに対応するフラグが「１」（クリア済み）でないステージの各エリアについて自動進行不可であると判断する。

例えば、図８のゲーム進行データの例では、ユーザＩＤ：０００００１のユーザに対しては、ステージ１，２の各エリアが自動進行可能であると判断され、ステージ３については自動進行不可であると判断される。ユーザＩＤ：０００００２のユーザに対しては、ステージ１〜３について自動進行不可であると判断される。ユーザＩＤ：０００００３のユーザに対しては、ステージ１の各エリアが自動進行可能であると判断され、ステージ２，３については自動進行不可であると判断される。

第２進行手段５４は、特定手段５３によって特定されたエリアについて、所定の進行条件でユーザの操作入力によらずに進行させる機能を備える。本実施形態のゲームでは、「所定の進行条件」の一例は、マトリクス上のマスへのトランプカードの配置が、最も高いポーカー役が成立するようにして行われるという進行条件である。
第２進行手段５４の機能は、第１進行手段５１と同様にして実現可能であるが、自動進行させる点が第１進行手段５１と異なる。なお、自動進行は、例えばゲーム画像上の所定のメニュー（例えば、図１２のメニューｍ５０）を選択することで開始される。

図１５に、処理対象のユーザのターンにおける自動対戦処理のフローチャートを示す。図１５のフローチャートは、通信端末１０のＣＰＵ１１によって実行される。
図１５において先ず、ＣＰＵ１１は、ユーザのターンである場合（ステップＳ３０：ＹＥＳ）、ユーザに配布する２枚のトランプカードを所定の規則に従って、あるいは無作為に選択する（ステップＳ３２）。
次いでＣＰＵ１１は、ユーザの手札の４枚のトランプカードの中から２枚のトランプカードの組合せを選択する（ステップＳ３４）。この場合、６通りの組合せが選択される。この６通りの組合せのトランプカードに対して順に、ステップＳ３６の処理が行われる。すなわち、ＣＰＵ１１は、処理対象となる組合せの２枚のトランプカードを５×５のマトリクス上で配置可能なすべてのマスに配置させ、マトリクス内の縦、横、又は斜めのいずれか５枚のトランプカードによっていずれかのポーカー役が成立するか否かを判定する。そして、成立した最も高いポーカー役と、そのときに２枚のトランプカードが配置されるマスの位置とをＲＡＭ１３に記録する（ステップＳ３６）。
すべての組合せのトランプカードに対してステップＳ３６の処理が終了していない場合には（ステップＳ３８：ＮＯ）、ステップＳ３４へ戻って処理が終わっていない組合せのトランプカードを選択する（ステップＳ３４）。すべての組合せのトランプカードに対してステップＳ３６の処理が終了した場合には（ステップＳ３８：ＹＥＳ）、ステップＳ４０へ進む。

ＣＰＵ１１は、ユーザの手札の４枚のトランプカードによってポーカー役が成立した場合（ステップＳ４０：ＹＥＳ）、その中で最も高いポーカー役を決定し、そのポーカー役が成立するマスに、ユーザの手札の４枚のトランプカードの中から選択された２枚のトランプカードを配置させる（ステップＳ４２）。ＣＰＵ１１は、ＲＡＭ１３内のカード設定データを参照して、ステップＳ４２で決定したポーカー役に対応する、処理対象のユーザのグループ内の各モンスターカードの、そのポーカー役に応じたダメージ値の合計値を算出する。次いでＣＰＵ１１は、対戦相手のＨＰからのその合計値を減算することによって、対戦相手のＨＰを更新する（ステップＳ４４）。最後にＣＰＵ１１は、対戦相手のＨＰがゼロに達したか否かを判定する対戦終了判定の処理を行って（ステップＳ４６）、終了する。なお、ユーザのターンでない場合（ステップＳ３０：ＮＯ）、及び、ユーザの手札の４枚のトランプカードによってポーカー役が成立しない場合（ステップＳ４０：ＮＯ）、つまりＲＡＭ１３に成立したポーカー役が記録されていない場合も終了する。
なお、図１５に示すＣＰＵ１１の処理は一例に過ぎず、他の処理方法を採ってもよい。図１５に示したフローチャートでは、ユーザの手札の中からすべてのマスへの配置を総当たりで行って、成立するポーカー役をチェックする方法であるが、この方法に限られない。高いポーカー役から順に、各ポーカー役が成立する２枚のトランプカードがユーザの手札の中に含まれているかチェックし、ポーカー役が成立する２枚のトランプカードが含まれていると判定された場合にチェックを終了してもよい。この方法では、すべてのマスへの配置を総当たりでチェックする必要がない。

（７）通信端末１０とゲームサーバ２０の間の主要な処理のフロー
次に、本実施形態の通信端末１０とゲームサーバ２０の間の主要な処理のフローの一例について、図１６のシーケンスチャートを参照して説明する。

先ず通信端末１０のＣＰＵ１１は、ユーザによる指示入力部１５に対する所定の操作入力に基づいてＲＯＭ１２からゲームプログラムをＲＡＭ１３してロードして起動する（ステップＳ５０）。ＣＰＵ１１は、プログラムを起動するとゲームサーバ２０との間で認証処理を行う（ステップＳ５２）。例えば、ＣＰＵ１１は通信インタフェース部１７を介して通信端末１０のＵＩＤを送信し、ゲームサーバ２０のＣＰＵ２１は、取得したＵＩＤを、予め記録してあるＵＩＤと照合することで認証処理を行う。認証処理が正常に完了すると、ゲームサーバ２０のＣＰＵ２１は、ゲームを進行させるためのデータとして、例えば、処理対象のユーザに対応する部分のゲーム進行データ、ユーザデータ、及びカード設定データをデータベースサーバ３０から読み出して（ステップＳ５４）、通信端末１０へ送信する（ステップＳ５６）。

ＣＰＵ１１は、ユーザデータ、カード設定データ、及びゲーム進行データを受信すると、これらのデータをＲＡＭ１３に展開し、ＲＡＭ１３内のゲーム進行データの各エリアに対応するフラグの値を参照して、自動進行可能なエリアを特定する（ステップＳ５８）。次いでＣＰＵ１１は、ユーザの進行対象となるステージ、エリアについてのユーザの操作入力を待つ。ユーザの操作入力に基づいてステージ、エリア、エリア内の地点が選択されると、ＣＰＵ１１は、ＲＡＭ１３内のゲーム進行データに基づいて、ＣＰＵ１１は当該地点についての対戦を開始する（ステップＳ６０）。

対戦に先立ってＣＰＵ１１は、ゲームサーバ２０に対し、対戦処理の対象となるエリア内の地点を指定して対戦相手のデータを要求し（ステップＳ６２）、当該要求に応じてゲームサーバ２０が通信端末１０に対して対戦相手のカード設定データ（より具体的には、モンスターカードのグループのデータ）を返す（ステップＳ６４）。通信端末１０へ送信されるカード設定データは、ＮＰＣとして予めエリアに対応付けて記憶されているグループのデータであってもよいし、カード設定データに記録されている他の任意のユーザのグループのデータをコピーして作成したものであってもよい。

対戦が開始されるとＣＰＵ１１は、処理対象のユーザのターンの対戦処理（ステップＳ６６）と対戦相手のターンの対戦処理（ステップＳ６８）を交互に行う。ユーザの対戦処理（ステップＳ６６）では、例えば図１４のフローチャートに示したように、ユーザの操作入力に基づいて、処理対象のユーザの手札の４枚のトランプカードのうちの２枚のトランプカードを５×５のマスのマトリクスの中に配置させ、マトリクス上でポーカー役が成立した場合に、対戦相手のＨＰを低下させる処理を行う。また、対戦相手の対戦処理（ステップＳ６８）では、対戦相手の手札の４枚のトランプカードのうちの２枚のトランプカードを、ポーカー役が成立するように５×５のマスのマトリクスの中に配置させ、処理対象のユーザのＨＰを低下させる処理を行う。対戦処理を交互に行った結果、処理対象のユーザ又は対戦相手のいずれか一方のＨＰがゼロになったと判断した場合、ＣＰＵ１１は対戦を終了させる。なお、ユーザの対戦処理では、ＣＰＵ１１は、ＲＡＭ１３内のユーザデータの更新（例えば、アクションポイントの更新等）を行う。

ユーザがエリア内の各地点で対戦を繰り返し行い、エリアの最後の地点の対戦（ボス戦）で勝利した場合、ＣＰＵ１１は、ＲＡＭ１３内のゲーム進行データを更新する（ステップＳ７０）。つまりＣＰＵ１１は、対象となるエリアに対応するフラグを「０」（クリア済みでない）から「１」（クリア済み）に書き換えることでゲーム進行データを更新する。また、ＣＰＵ１１は、ユーザが対戦で勝利した場合に、所定の、あるいはランダムな確率で、所定量の通貨ポイントや経験値、あるいはアイテムをユーザに付与することを決定する。通貨ポイントや経験値、あるいはアイテムを付与することを決定すると、ＣＰＵ１１はＲＡＭ１３内のユーザデータを更新する。なお、図示しないが、図９に示したようにユーザがグループ編成を行った場合には、ＣＰＵ１１は、ＲＡＭ１３内のカード設定データを随時更新する。
ＣＰＵ１１は、例えば対戦が終了する度に、ＲＡＭ１３内のゲーム進行データ、ユーザデータ、及びカード設定データを、通信インタフェース部１７を介してゲームサーバ２０へ送信する（ステップＳ７２）。ゲームサーバ２０のＣＰＵ２１は、受信したデータに基づいて、データベースサーバ３０内のゲーム進行データ、ユーザデータ、及びカード設定データを更新する（ステップＳ７４）。

なお、ＣＰＵ１１は、対戦に先立ってユーザが選択したエリアが、ステップＳ６４で特定したエリア（つまり、自動進行可能なエリア）に含まれる場合には、対戦処理のゲーム画像において、自動対戦を実行するためのメニュー（例えば図１２のメニューｍ５０）を表示させる。ＣＰＵ１１は、ユーザのターンの対戦処理（ステップＳ６６）において、ユーザが自動対戦を選択した場合、ユーザの操作入力によらずに、対戦相手の手札の４枚のトランプカードのうちの２枚のトランプカードを、ポーカー役が成立するように５×５のマスのマトリクスの中に配置させ、対戦相手のＨＰを低下させる処理を行う。自動対戦では、ユーザは自身でトランプカードを配置させる位置を検討する必要がないため、対戦自体が素早く進行する。

以上詳述したように、本実施形態のゲーム制御装置で実現されるゲームでは、ユーザが複数のエリア（パート）を順次進行させていき、各エリアが終了条件を満たしたか否か（本実施形態の例では、エリアをクリアしたか否か）について判定される。例えば、特定のエリアが終了条件を満たした場合、その次のエリアに進行可能となる構成とすることができる。そしてユーザが終了条件を満たしたエリアのうち特定のエリアについては、ユーザは自動進行させることができる。具体的には、本実施形態のゲームでは、ユーザがステージ内のすべてのエリアについて終了条件を満たした場合に、そのステージ内のすべてのエリアについて所定の進行条件で自動進行させることが可能となる。そのため、ユーザは、自身が既に進行させたことがあるエリアを再度進行させる場合に、エリア間のゲームの進行の連続性を損なうことなく、かつ比較的簡易に進行させることができるようになる。

上述した実施形態のゲームは、各エリア（パート）を進行させることで、ユーザに関連付けられたパラメータ（例えば、通貨ポイントや経験値）が変動するゲームである場合について説明したが、本発明が適用されるゲームはかかるゲームに限られない。ユーザが保有するモンスターカードやアイテム等のオブジェクトのパラメータが変動してもよい。
特定のエリアを進行させることによってパラメータが変動するゲームの場合には、ユーザは所望のパラメータ変動を実現する目的で、終了条件を満たしたエリアを再度進行させることを動機付けられる。本実施形態のゲームでは、エリアを再度進行させるときに自動進行可能であるため、エリア間のゲームの進行の連続性を損なうことなく、かつ比較的簡易に進行させることができるという点がユーザにとってより効果的なものとなる。

上述した実施形態では、自動進行における進行条件が、マトリクス上のマスへのトランプカードの配置が、最も高いポーカー役が成立するようにして行われる条件とし、対戦処理では、当該条件によって決定される入力データ（操作情報）を決定し、その入力データに基づいて所定の演算処理を実行する場合について説明した。つまり、第２進行手段５４は、所定の進行条件によって決定される入力データ（操作情報）に基づいて、ゲームを進行する場合について説明した。しかし進行条件は、この場合に限られない。ユーザの過去の対戦が再現されるように、進行条件を設定してもよい。例えば、以下のように進行条件を設定することができる。

(i) ユーザの操作履歴に基づく進行条件
例えば、特定のエリアに対してユーザが複数回進行を行った場合には、その中のいずれかの進行時のユーザの操作履歴に基づいて進行条件を設定してもよい。上述した実施形態のゲームの例では、対象となるエリア内の地点におけるユーザの対戦時の操作履歴として、例えば各ポーカー役を成立させた回数あるいは頻度に関する情報を記憶しておく。そして、同一の地点での自動対戦では、記憶しておいた各ポーカー役の回数と同一の回数、又は、頻度で成立するように、通信端末１０のＣＰＵ１１が対戦処理を実行する。

(ii) ユーザが終了条件を満たしたときの操作履歴に基づく進行条件
例えば、特定のエリアに対してユーザが終了条件を満たしたときの操作履歴に基づいて進行条件を設定してもよい。この場合も同様に、対象となるエリアをクリアしたときの各地点におけるユーザの対戦時の操作履歴として、例えば各ポーカー役を成立させた回数あるいは頻度に関する情報を記憶しておく。そして、同一の地点での自動対戦では、記憶しておいた各ポーカー役の回数と同一の回数、又は、頻度で成立するように、通信端末１０のＣＰＵ１１が対戦処理を実行する。

(iii) ユーザの終了条件を満たしたときのパラメータの変動結果に基づく進行条件
例えば、特定のエリアに対してユーザが終了条件を満たしたときのパラメータの変動結果に基づいて進行条件を設定してもよい。パラメータとしては、例えばユーザの残ＨＰや勝利時の残り時間等である。例えば、特定のエリアをクリアしたときの各地点の対戦時のユーザの残ＨＰや残り時間を記憶しておく。そして、同一の地点での自動対戦では、記憶しておいたユーザの残ＨＰが大きい場合、例えば対戦相手のポーカー役が成立し難くい位置にユーザの手札のトランプカードが配置されるように、通信端末１０のＣＰＵ１１が対戦処理を実行する。また、記憶しておいた残り時間が長い場合には、ユーザのターンの対戦処理の待機時間を長くする。

（８）変形例
上述した実施形態では、エリアが本発明のパートの一例である場合について説明したが、この場合に限られない。パートは、例えばダンジョン、ステージ、フロア等の、ゲームの一定の区切りとなる部分であれば如何なる部分であってもよい。上述した実施形態では、エリア内の各地点の対戦を１つのパートとして捉えてもよい。
上述した実施形態では、エリアをクリアすることを終了条件の一例としたが、終了条件はこれに限られない。終了条件は、ユーザがゲーム内で最も進行させた位置で対戦に敗北したことであってもよい。例えば、図８のユーザＩＤ：０００００１のユーザがエリア３−２のいずれかの地点での対戦で敗北した場合、その地点において終了条件を満足したと判定してもよい。このとき、自動進行可能なエリアを、ステージ１〜２のすべてのエリアとしてもよいし、エリア３−１までのすべてのエリアとしてもよい。

さらに以下において、上述した実施形態の変形例について説明する。
本変形例に係るゲーム制御装置の機能ブロック図を図１７に示す。図１７の機能ブロック図は、図１３に示したものと比較して、切り替え手段５５、提示手段５６、制限手段５７、及び関係付け手段５８が追加された点が異なる。なお、これらの追加の構成要素は各変形例ですべて必須ではない。各変形例では、関連のある追加の構成要素にのみ言及して説明する。なお、追加の構成要素は適宜、組合せて適用することもできる。

（８−１）変形例１
本変形例では、ユーザの操作入力に基づき、変更手段５３によって特定されたパートについて、ユーザの操作入力に基づいて進行させる第１進行モード（いわば、手動対戦による手動進行のモード）と、ユーザの操作入力によらずに進行させる第２進行モード（つまり、自動対戦による自動進行のモード）との間で切り替える切り替え手段５５、が設けられる。
ユーザが自動進行させる場合には、予め決定された所定の進行条件で進行がなされるため、必ずしもユーザにとって有利に進行しない場合もある。例えば上述した実施形態のゲームの自動対戦の処理では、図１５のフローチャートに関連付けて説明したように、最も高い役が成立するようにして２枚のトランプカードの５×５のマトリクスへの配置が行われる例を示したが、このような配置方法では、ダメージ値がポーカー役の高さに応じて設定されていない場合には、対戦相手に与えるダメージ値が最大になるとは限らない。そのため、自動対戦によってユーザの対戦中の形勢が不利となる場合がある。そのような場合に、上記構成では、例えば第２進行モードから第１進行モードに切り替えて、進行中にユーザの操作を随時介入可能とすることができる。そのため、ユーザは、自身の操作を伴わない簡易なゲーム進行を行いつつ、必要に応じてゲームの進行に影響を与えるようにすることができ、簡易なゲームの進行中にもゲームへの没入感を維持することができる。

本変形例を実現するために、例えば図１２に示したメニューｍ５０（「ＡＵＴＯ」）を第１進行モード（自動進行のモード）と第２進行モード（手動進行のモード）の間で、ユーザの操作入力に応じて切り替え可能な切り替える切り替えスイッチに代える。通信端末１０のＣＰＵ１１は、切り替えスイッチの動作状態に応じて、ユーザの対戦処理をユーザのターンごとに切り替える。例えば、自動対戦が選択されているときには、図１５に示したフローチャートに従って処理を行い、手動対戦が選択されているときには、図１４に示したフローチャートに従って処理を行う。

なお、上述した実施形態において、第１進行手段５１による進行では、ユーザは対戦処理において、ダメージ値が最も大きくなるポーカー役となるように検討して操作入力を決定する。一方、第２進行手段５４による進行では、上述したように、最も高いポーカー役が成立するようにして行われる条件で入力データが決定されるが、この条件では必ずしもダメージ値が大きくなるとは限らない。つまり、第２進行手段５４における進行条件は、第１の進行手段５１における進行条件よりも制限されたものとなっている。この場合、自動進行中にユーザが進行モードを切り替えることで、ユーザにとってより好ましい対戦結果に導くことができるようになるため、自動進行中であってもユーザのゲームへの没入感を高めることができる。

（８−２）変形例２
本変形例では、ユーザがゲームを開始するときに、特定手段５３によって特定されたエリア（パート）をユーザに提示する提示手段５６、が設けられる。この構成では、ユーザがゲームを開始する時点で、ユーザが自動進行可能なエリアが提示されるため、当該エリアを複数のエリアの中から選択することが容易となる。
図１８に、本変形例においてユーザによって進行対象のステージが選択されるときのゲーム画像の一例を示す。図１８に例示するゲーム画像Ｄ２ａは、図１０のゲーム画像Ｄ２に対応する画像である。上述した実施形態のゲームでは、ステージ内のすべてのエリアをクリアした場合に、そのステージのすべてのエリアについて自動進行させることが可能であるため、図１８では、ステージ単位で自動進行が可能であることを示すテキスト（「Ａｕｔｏ可能！」）が表示される。このような表示態様によって、ユーザは進行対象のステージを選択する時点で、自動進行可能なステージを認識することができる。
本変形例を実現するために、通信端末１０のＣＰＵ１１は、ＲＡＭ１３内のゲーム進行データの各エリアに対応するフラグの値を参照して、自動進行可能なステージを特定した後に、ステージ選択のためのゲーム画像用の画像データを生成する。

（８−３）変形例３
本変形例では、特定手段５３によって特定されたエリア（パート）について、当該エリアが終了条件を満たした時刻、若しくは当該エリアが最初に特定された時刻から所定時間経過した場合、又は、第２進行手段５４による当該エリアの進行が所定回数行われた場合に、第２進行手段５４による進行を制限する制限手段５７、が設けられる。
ユーザが終了条件を満たしたエリアについて制限なく何度でも自動進行させることができるとした場合には、ユーザにゲームの操作に慣れてもらうという観点では好ましくない場合がある。例えば、上述した実施形態では、エリアを進行させるときにアイテムやポイント（通貨ポイントや経験値）を取得することが可能であるが、ユーザは既に終了条件を満たしたエリアを繰り返し自動進行させることで、何度でもアイテムやポイントを取得することが可能となってしまい、結果的にゲームにおけるユーザの操作回数が減る虞がある。そこで、本構成では、一定の条件が成立する場合に、特定のエリアを自動進行させることを制限することで、ユーザのゲームに対する習熟を促すようにする。また、本変形例では、過度に安易にユーザがアイテムやポイントを取得することを防止することができる。

本変形例を実現するために、通信端末１０のＣＰＵ１１が、ユーザが自動進行させたエリアとその時刻、あるいはそのエリアについて最初に終了条件を満たした時刻を逐次ＲＡＭ１３内のゲーム進行データに記録するようにする。そのゲーム進行データは、対戦終了後にゲームサーバ２０へ送信されて、データベースサーバ３０内のゲーム進行データに反映される。そしてＣＰＵ１１は、進行対象となるエリアについて、最初に終了条件を満たした時刻、最初に自動進行させた時刻、又は自動進行させた回数に基づいて、そのエリアを自動進行可能とするか否か判定する。

（８−４）変形例４
本変形例では、ユーザ間を関係付ける関係付け手段５８が設けられる。また、特定手段５３は、ユーザと関係付けられた仲間の各エリア（パート）の実行状況又は進行状況に基づいて、ユーザの自動進行可能なエリアを特定する。
この構成では、ユーザと関係付けられた仲間の実行状況又は進行状況に基づいてユーザが自動進行可能なパートが特定される。つまり、ユーザは仲間の状況次第で自身が自動進行可能なエリアが決定されるようになるため、複数の関係付けられた仲間の間で協力してゲームを進行させている感覚が得られるようになる。なお、仲間の各エリアの実行状況又は進行状況に関する情報は、ユーザに提示されることが好ましい。

関係付け手段５８の機能は以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージを受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に表示されるゲーム画像上の所定のメニューを操作することで行われるように構成される。ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するためのメッセージを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間のユーザＩＤ」の箇所（図６参照）にデータを書き込む。

なお、ユーザ同士を関係付ける条件は、上述したものに限られず、同一のステージ若しくはエリアを進行させるユーザ同士を仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間で対戦や敵キャラクタとの対戦を行うゲーム要素が設けられている場合には、所定回数以上対戦を行ったユーザ同士や、協力して敵キャラクタと対戦をしたユーザ同士を自動的に仲間として登録してもよい。
ゲーム内でユーザ同士のグループ（ギルド等）が設定されている場合、例えば、あるユーザ（「ユーザＡ」とする。）があるグループへの参加が承認されたときに、当該グループ内の他のユーザ（「ユーザＢ」とする。）のユーザＩＤをユーザＡのユーザデータに書き込むとともに、ユーザＢのユーザデータにユーザＡのユーザＩＤを書き込んでもよい。
ユーザ同士の仲間関係の登録はユーザデータベース３１にデータを書き込むことによって実現する例に限られない。仲間関係に関するデータは、ゲームサーバ２０からアクセス可能なネットワーク上の外部の記憶装置に書き込まれるようにしてもよい。

本変形例は、様々な方法が考えられる。
例えば、仲間の各エリアの実行状況に関する情報は、例えば、各エリアにおける仲間のアクセス履歴や実行結果等であってもよい。仲間のアクセス履歴が多いほど、又は仲間の実行結果が良好であるほど、ユーザが自動進行可能なエリアの数を多くしてもよい。なお、アクセス履歴は、ゲーム起動時に認証処理を伴うログイン履歴でもよいし、対戦ごとのアクセス履歴でもよい。仲間のアクセス履歴や実行結果は、ユーザが進行中のステージ又はエリアと同一のステージ又はエリアに限定してもよい。
例えば、ユーザが終了条件を満たしたエリアがステージ１〜１０のすべてのエリアである場合、仲間のステージ１〜１０に対するアクセス回数に応じて、自動進行可能なステージを以下に例示するように決定することができる。
・アクセス回数が少ない … ステージ１〜４で自動進行可能
・アクセス回数が中程度 … ステージ１〜７で自動進行可能
・アクセス回数が多い … ステージ１〜１０で自動進行可能

実行結果は、例えば、短い対戦時間で勝利した場合、大きい残ＨＰの値で勝利した場合、あるいは大きなポーカー役で勝利した場合に、良好であると判断してもよい。例えば、自動進行可能なステージを以下に例示するように決定することができる。
・仲間の対戦時間が長い … ステージ１〜４で自動進行可能
・仲間の対戦時間が中程度 … ステージ１〜７で自動進行可能
・仲間の対戦時間が短い … ステージ１〜１０で自動進行可能

なお、仲間のアクセス履歴が多いほど、又は仲間の実行結果に応じて、ユーザが自動進行可能なエリアをより細分化して決定してもよい。その場合も、仲間のアクセス履歴や実行結果は、ユーザが進行中のステージ又はエリアと同一のステージ又はエリアに限定してもよい。
例えば、ユーザが終了条件を満たしたエリアが、ステージ１〜９の全エリアと、ステージ１０内のエリア１〜９のうちエリア１〜７である場合、仲間のステージ１〜１０の各エリアに対するアクセス回数に応じて、自動進行可能なステージ及びエリアを、ステージ１〜９の全エリアに加えて、以下に例示するように決定することができる。
・アクセス回数が少ない … ステージ１０では自動進行不可（ステージ１〜９のみで可）
・アクセス回数が中程度 … ステージ１０のエリア１〜３で自動進行可能
・アクセス回数が多い … ステージ１０のエリア１〜７で自動進行可能

例えば、仲間の各エリアの進行状況に関する情報は、例えば、各エリアを進行中の仲間の数であってもよい。ここで、仲間の数をカウントするタイミングは、ユーザが各エリアについて終了条件を満たした時点でもよいし、ユーザが既に終了条件を満たしたエリアを自動進行させる時点でもよい。
例えば、ユーザが終了条件を満たしたエリアがステージ１〜１０のすべてのエリアである場合、ステージ１〜１０の各エリアを進行中の仲間、あるいはユーザと同一ステージを進行中の仲間の数に応じて、自動進行可能なステージを以下に例示するように決定することができる。
・仲間の数が少ない … ステージ１〜４で自動進行可能
・仲間の数が中程度 … ステージ１〜７で自動進行可能
・仲間の数が多い … ステージ１〜１０で自動進行可能
なお、ステージ１〜１０の各エリアを進行中の仲間、あるいはユーザと同一ステージを進行中の仲間の数に応じて、上述したのと同様にして、ユーザが自動進行可能なエリアをより細分化して決定してもよい。

本変形例の特定手段５３を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザごとに、当該ユーザのユーザデータによって特定される仲間のアクセスログを記録する。そして、ＣＰＵ２１は、アクセスログを基に処理対象のユーザの仲間のアクセス回数や、ゲーム進行データを参照して得られる、各エリアを進行中の仲間の数等を計数する。ＣＰＵ２１は、その計数結果を例えば所定の閾値と比較し、比較結果に基づいて処理対象のユーザが自動進行可能なエリアを決定する。

本変形例において、判定手段５２は、複数のエリアの各エリアについて、ユーザに関連付けられた仲間が終了条件を満たしたか否かを判定し、特定手段５３は、ユーザに関連付けられた仲間が終了条件を満たしたと判定されたエリアのうち、ユーザの操作入力によらずに進行可能なエリアを特定するようにしてもよい。例えば、ユーザの仲間の中で、あるいはユーザが所属しているギルド内のメンバーの中で、終了条件を満たしたエリア（つまり、クリアしたエリア）が最も先のエリアに基づいて、ユーザが自動進行可能なエリアを決定してもよい。
例えば、上述した実施形態では、ユーザがクリアしたエリアがステージ１〜３の全エリアである場合には、そのユーザはステージ１〜３が自動進行可能である。ここでさらに、このユーザが所属しているギルド内の他のメンバーがクリアしたエリアがステージ１〜５の全エリアである場合には、ユーザが自動進行可能なエリアをステージ１〜３からステージ１〜５まで拡張してもよい。このようにすることで、ギルド内の各メンバーは、ギルドのメンバー全体でゲームを進めている感覚を得ることができるとともに、ギルド内の他のメンバーのゲームの進行を補助することができるため、ギルド内のメンバー間のコミュニケーションが促進される。
ギルド内のメンバーの進行状況によってギルド内のメンバーが自動進行可能なエリアを決定するために、ゲームサーバ２０のＣＰＵ２１は、ギルド内のいずれかのメンバーからゲームの開始のためのアクセスがあったときに、処理対象のユーザが所属しているギルドの各メンバーについてのゲーム進行データを参照し、ギルド内のメンバーで最も先まで進行させているメンバーのクリア済みのエリアを特定する。そして、ゲームサーバ２０はアクセスするユーザの通信端末１０に対して、特定したエリアを通知する。通信端末１０のＣＰＵ１１は、ゲームサーバ２０によって特定されたエリアに基づいて、自動進行可能なエリアを決定する。

２．第２の実施形態
上述した第１の実施形態及び各変形例では、ゲームのパート単位（例えば第１の実施形態では、エリア単位）でユーザが終了条件を満たしたか否かについて判定し、その判定結果に応じて自動進行可能なパートを特定する場合について説明した。この考え方を拡張して、開始位置から順に進行させるゲームにおいて、一定の区切りであるパート単位ではなく、ゲーム上の位置でユーザが終了条件を満たしたか否かについて判定し、終了条件を満たした位置に応じて、開始位置から自動進行可能となる位置を特定してもよい。ゲーム上の位置は、ゲームが複数のパートからなる場合には特定のパート内の位置であってもよいし、ゲームが１つのシナリオに沿って進行する場合にはそのシナリオ上の位置であってもよい。

本実施形態に係るゲーム制御装置は、開始位置から順に進行させるゲームの実行を制御するものであって、その機能ブロック図を図１９に示す。
図１９に示すように、本実施形態に係るゲーム制御装置は、
ユーザの操作入力に基づいて、前記ユーザによって前記ゲームを進行させる第１進行手段６１と、
前記ゲームについて、前記ユーザが終了条件を満たし、かつ前記開始位置から最も離れたゲーム上の位置を特定する第１特定手段６２と、
前記第１特定手段６２によって特定された位置に基づいて、前記ユーザの操作入力によらずに進行可能な位置を特定する第２特定手段６３と、
前記第２特定手段６３によって特定された位置まで、所定の進行条件で前記ユーザの操作入力によらずに前記ゲームを進行させる第２進行手段６４と、
を備えたものである。

第１の実施形態のゲームに適用した場合、各手段は以下のようにして実現できる。なお、開始位置は、ステージ１のエリア１−１の最初の地点としてもよい。
第１進行手段６１は、第１の実施形態の第１進行手段５１と同様にして実現できる。
第１特定手段６２の終了条件の一例は、ユーザのＨＰがゼロとなって敗北したことであってもよい。例えば、上述した実施形態のゲームでは、第１特定手段６２によって特定される位置は、ユーザが最も進行したエリア内の地点での対戦においてユーザのＨＰがゼロとなったときの対戦の局面が終了条件を満たした位置となる。第１特定手段６２の機能を実現するために、通信端末１０のＣＰＵ１１は、例えば、ゲーム進行データとして、ユーザにとって最も先に進んだステージ及びエリア内の特定の地点におけるユーザの攻撃のターンの数をＲＡＭ１３に記憶する。例えば、ステージ３のエリア３−２の第２地点の１０ターン目、といった具合である。
第２特定手段６３を実現するために、ＣＰＵ１１は、終了条件を満たした位置に基づいて、自動進行可能な位置を特定する。例えば、終了条件を満たした位置として、ＲＡＭ１３が「ステージ３のエリア３−２の第２地点の１０ターン目」を記憶している場合、その位置までを自動進行可能としてもよい。
第２進行手段６４は、第１の実施形態の第２進行手段５４と同様にして実現できる。

本実施形態によれば、ユーザが終了条件を満たすゲーム上の位置、つまりユーザが進行することができたゲーム上の位置を記録しておき、当該位置までを所定の進行条件でユーザが自動進行可能とすることができる。そのため、ユーザは、自身が既に進行させたことがある位置まで再度進行させる場合に、ゲームの進行の連続性を損なうことなく、かつ比較的簡易にその位置まで進行させることができるようになる。

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

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

上述した実施形態では、通信端末で実行されるゲームの場合を例として説明したが、これに限られない。例えば、すべてのゲーム情報をサーバからダウンロードすることでその後サーバとの同期をとらないようなプログラムやＲＯＭ等からゲーム情報を読み込むスタンドアローンのゲーム機に適用してもよいし、ネットワーク上に置かれたサーバ装置と通信機能を備えたゲーム機とを接続した、いわゆるオンラインゲームシステムに適用してもよい。すなわち、上述した実施形態では、ユーザ間の対戦が非同期で行われる場合について説明したが、この場合に限られない。ユーザ間の対戦において、各ユーザの通信端末の間で同期をとり、対戦相手の操作入力も受け入れるようにして対戦を実行してもよい。

上述した実施形態では、図２０Ａに示すように、主として通信端末１０によって、図１３に示した各手段の機能を実現する構成としたが、この構成に限られない。これらの手段のうち少なくとも一部、又はすべての手段をゲームサーバ２０及びデータベースサーバ３０によって実現する構成としてもよい。主としてゲームサーバ２０及びデータベースサーバ３０によって実現する場合には、ブラウザゲームとして実現してもよい。通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との間で機能分担を図る場合の例を図２０Ｂに示す。図２０Ｂに示す例では、判定手段５２及び特定手段５３の各機能がゲームサーバ２０及びデータベースサーバ３０によって実現される。この場合には、通信端末１０によるゲームプログラムの起動後に、ゲームサーバ２０がデータベースサーバ３０内のゲーム進行データを基に、処理対象のユーザが自動進行可能なエリアを特定して、通信端末１０へ通知する。通信端末１０は、通知されたエリアに基づいて、自動進行可能なエリアを認識する。

上述した実施形態のゲームは、カードゲームのポーカーを利用したものとしたが、他のカードゲームとして、ブラックジャックやスピード、大富豪等のカードゲームを利用したゲームを利用したものとしてもよく、あるいは、麻雀やウノ等の他の様々な種類のテーブルゲームを利用したものとしてもよい。例えば、ブラックジャックを利用する場合、場に配置したトランプカードの合計点数が２１点以下である場合に、その合計点数と２１点との差に対応付けて各モンスターカードのダメージ値を設定すればよい。スピード、大富豪、ウノを利用する場合、本実施形態のポーカー役に代えて、１回のターンにおいて連続で場に出すカードの枚数に対応付けて各モンスターカードのダメージ値を設定すればよい。麻雀を利用する場合、本実施形態のポーカー役に代えて麻雀の役に対応付けて各モンスターカードのダメージ値を設定すればよい。
上述した実施形態のゲームは、アクションゲーム、シューティングゲームを利用してもよい。例えば、シューティングゲームでは、本実施形態のポーカー役に代えて、ユーザの操作入力に基づいて所定時間内に射撃対象のゲームキャラクタへヒットさせた数に対応付けて各モンスターカードのダメージ値を設定してもよい。
ポーカー以外のゲームを利用する場合、第２進行手段５４は、利用対象のゲームの内容に応じて適宜その実現方法を決定することができる。例えば、公知の自動実行アルゴリズムを利用してもよい。そのときに、所定の進行条件として、ユーザが終了条件を満たしたときの操作回数や頻度（例えば、場に出すカードの枚数の頻度）が再現されるように実行してもよい。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…第１進行手段
５２…判定手段
５３…特定手段
５４…第２進行手段
５５…切り替え手段
５６…提示手段
５７…制限手段
５８…関係付け手段
６１…第１進行手段
６２…第１特定手段
６３…第２特定手段
６４…第２進行手段

Claims (10)

1. 複数のパートからなるゲームの実行を制御するゲーム制御装置であって、
   ユーザの操作入力に基づいて、前記ユーザによって前記複数のパートを進行させる第１進行手段と、
   前記複数のパートの各パートについて、前記ユーザが終了条件を満たしたか否かを判定する判定手段と、
   前記ユーザが終了条件を満たしたと判定されたパートのうち、前記ユーザの操作入力によらずに進行可能なパートを特定する特定手段と、
   前記特定手段によって特定されたパートについて、所定の進行条件で前記ユーザの操作入力によらずに進行させる第２進行手段と、
   を備えたゲーム制御装置。
2. 前記ユーザの操作入力に基づき、前記特定手段によって特定されたパートについて、前記ユーザの操作入力に基づいて進行させる第１進行モードと、前記ユーザの操作入力によらずに進行させる第２進行モードとの間で切り替える切り替え手段、を備えたことを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記ユーザがゲームを開始するときに、前記特定手段によって特定されたパートを前記ユーザに提示する提示手段、を備えたことを特徴とする、
   請求項１又は２に記載されたゲーム制御装置。
4. 前記特定手段によって特定されたパートについて、当該パートが終了条件を満たした時刻、若しくは当該パートが最初に特定された時刻から所定時間経過した場合、又は、前記第２進行手段による当該パートの進行が所定回数行われた場合に、前記第２進行手段による進行を制限する制限手段、備えたことを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
5. ユーザ間を関係付ける関係付け手段、を備え、
   前記特定手段は、前記ユーザと関係付けられたユーザの各パートの実行状況又は進行状況に基づいて、前記ユーザの操作入力によらずに進行可能なパートを特定することを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. 前記ゲームは、各パートを進行させることで、前記ユーザに関連付けられたパラメータ、又は前記ユーザが前記ゲーム上で保有するオブジェクトに関連付けられたパラメータが変動することを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. 複数のパートからなり、かつ各パートを進行させることで前記ユーザに関連付けられたパラメータ、又は前記ユーザが前記ゲーム上で保有するオブジェクトに関連付けられたパラメータが変動するゲームの実行を制御するゲーム制御装置であって、
   ユーザの操作入力に基づいて、前記ユーザによって前記複数のパートを進行させる第１進行手段と、
   前記複数のパートの各パートについて、前記ユーザが終了条件を満たしたか否かを判定する判定手段と、
   前記ユーザが終了条件を満たしたと判定されたパートのうち、前記ユーザの操作入力によらずに進行可能なパートを特定する特定手段と、
   前記特定手段によって特定されたパートについて、所定の進行条件で前記ユーザの操作入力によらずに進行させる第２進行手段と、
   前記ユーザの操作入力に基づき、前記特定手段によって特定されたパートについて、前記ユーザの操作入力によらずに進行させる第１進行モードと、前記ユーザの操作入力に基づいて進行させる第２進行モードとの間で切り替える切り替え手段と、
   を備えたゲーム制御装置。
8. 複数のパートからなるゲームの実行を制御するゲーム制御方法であって、
   ユーザの操作入力に基づいて、前記ユーザによって前記複数のパートを進行させるステップと、
   前記複数のパートの各パートについて、前記ユーザが終了条件を満たしたか否かを判定するステップと、
   前記ユーザが終了条件を満たしたと判定されたパートのうち、前記ユーザの操作入力によらずに進行可能なパートを特定するステップと、
   前記特定されたパートについて、所定の進行条件で前記ユーザの操作入力によらずに進行させるステップと、
   を含む、ゲーム制御方法。
9. 複数のパートからなるゲームの実行を制御するために、コンピュータに、
   ユーザの操作入力に基づいて、前記ユーザによって前記複数のパートを進行させる機能、
   前記複数のパートの各パートについて、前記ユーザが終了条件を満たしたか否かを判定する機能、
   前記ユーザが終了条件を満たしたと判定されたパートのうち、前記ユーザの操作入力によらずに進行可能なパートを特定する機能、及び、
   前記特定されたパートについて、所定の進行条件で前記ユーザの操作入力によらずに進行させる機能、
   を実現させるためのプログラム。
10. 通信端末と、当該通信端末との間で通信可能なサーバとを含み、複数のパートからなるゲームの実行を制御するゲームシステムであって、
    ユーザの操作入力に基づいて、前記ユーザによって前記複数のパートを進行させる第１進行手段、
    前記複数のパートの各パートについて、前記ユーザが終了条件を満たしたか否かを判定する判定手段、
    前記ユーザが終了条件を満たしたと判定されたパートのうち、前記ユーザの操作入力によらずに進行可能なパートを特定する特定手段、及び、
    前記特定手段によって特定されたパートについて、所定の進行条件で前記ユーザの操作入力によらずに進行させる第２進行手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    ゲームシステム。

Images