JP6442061B2 - ゲームシステム、ゲーム処理方法、ゲームプログラム、およびゲーム装置 - Google Patents

Description

本発明は、対戦型ゲームシステム等に関し、より特定的には、対戦型ゲームにおけるプレイヤのレートを用いたゲームシステムに関する。

従来から、プレイの実力が拮抗したプレイヤ同士をより適切にマッチングさせるゲームシステムが知られている（例えば特許文献１）。このようなゲームシステムでは、プレイの強さであるプレイヤのプレイ能力を数値で表したものを実力レーティングとして用いている。そして、実力レーティングが拮抗した値であるプレイヤ同士を選択して、対戦プレイをする相手として決定している。

特開２０１４−１４４３６７号公報

上記のようなゲームシステムでは、単純に、対戦相手の選択のためにレートが用いられるに過ぎなかった。

それ故に、本発明の目的は、上記のようなレートを利用した今までに無い新たなゲームシステムを提供することである。

上記目的を達成するために、例えば以下のような構成例が挙げられる。

構成例の一例は、他のプレイヤとの対戦を行う対戦ゲームと、所定の育成対象を育成させる育成ゲームとを含むゲーム処理を実行するゲームシステムであって、対戦ゲーム処理手段と、指標データ記憶手段と、指標更新手段と、判定手段と、第１パラメータ変更手段と、提示手段とを備える、ゲームシステムである。対戦ゲーム処理手段は、他のプレイヤとの対戦ゲーム処理を実行する。指標データ記憶手段は、対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に応じて変動する指標データを記憶する。指標更新手段は、対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて前記指標データを更新する。判定手段は、指標データが所定の条件を満たしているか否かを判定する。第１パラメータ変更手段は、所定の条件を満たしていると判定した場合、前記所定の育成対象に含まれる第１オブジェクトに関連づけられた第１パラメータを変更する。提示手段は、変更されたパラメータが反映された第１オブジェクトの画像をプレイヤに提示する。なお、ここでいうオブジェクトには、複数のオブジェクトで構成されるオブジェクト群の意味も含まれる。

上記構成例によれば、対戦ゲームの勝敗結果に基づく指標を、対戦ゲーム以外のゲーム要素に反映することができる、新しい形態のゲームを提供することができる。

他の構成例として、ゲームシステムは、対戦ゲームと育成ゲームとを選択的に実行するゲーム選択手段を更に備えていてもよい。

上記構成例によれば、対戦ゲームと育成ゲームの双方に対するプレイヤのモチベーションを相乗効果的に高めることが可能となる。

他の構成例として、指標データは、プレイヤのゲームの実力を所定の値で示すレート（レーティングと呼ばれることもある）であってもよい。

上記構成例によれば、プレイヤのゲームの腕前や実力を、例えば所定のオブジェクトを育成するようなゲーム要素に反映することができる。また、対戦ゲームにおけるプレイヤの努力等をビジュアルでプレイヤに提示することができる。これにより、プレイヤのゲームに対するモチベーションを相乗効果的に向上させることができる。

他の構成例として、指標更新手段は、対戦ゲームの結果プレイヤが勝利したことに応じて指標データの値の上昇または下降のうちのいずれか一方を行い、当該対戦ゲームの結果プレイヤが敗北したことに応じて指標データの値の上昇または下降のうちの他方を行うようにしてもよい。更には、指標データの値は、対戦ゲームにおけるプレイヤの勝敗結果に応じて増加または減少する値であり、指標更新手段は、対戦ゲームの結果プレイヤが勝利したときは指標データの値を増加させ、敗北したときは当該指標データの値を減少させるようにしてもよい。

上記構成例によれば、指標についてプレイヤにわかりやすい形で提示することができる。

他の構成例として、ゲームシステムは、プレイヤの指標データと近い値を有する他のプレイヤを対戦ゲーム処理における対戦相手として選出する選出手段を更に備えていてもよい。また、選出手段は、複数の対戦相手を対戦候補として選出してもよく、ゲームシステムは、複数の対戦候補のうちのいずれかをプレイヤが選択可能なように当該複数の対戦候補を表示する候補表示手段と、プレイヤの操作に基づいて複数の対戦候補のうちのいずれかを選択する対戦相手選択手段を更に備えていてもよい。

上記構成例によれば、ゲームの実力が近いプレイヤ同士で対戦ゲームを行わせることができ、ゲームの興趣性を高めることができる。

他の構成例として、判定手段は、指標データの値が所定の閾値を超えたときに、所定の条件を満たしていると判定するよう構成してもよい。

上記構成例によれば、例えば指標の数値がどの程度の値になれば、所定のオブジェクトに関するパラメータを変更できるかについて、プレイヤに理解しやすい形で示すことが可能となる。

他の構成例として、第１パラメータ変更手段は、指標データが所定の条件を満たしていると判定されたとき、第１パラメータをプレイヤの操作を要することなく変更してもよい。また、提示手段は、第１パラメータの変更に基づいて所定のオブジェクトの外観を変更して提示するようにしてもよい。

上記構成例によれば、所定のオブジェクトの外観が自動的に変化するため、プレイヤに驚きを与え、また、ゲ−ムプレイへのモチベーションを高めることができる。

他の構成例として、ゲームシステムは、所定の育成対象に含まれる第２オブジェクトに関連づけられるパラメータであって、第１のパラメータとは異なるパラメータである第２のパラメータをプレイヤの操作に基づいて変更する第２パラメータ変更手段を更に備えていてもよい。また、提示手段は、第２パラメータ変更手段によって変更された第２のパラメータに基づいた第２のオブジェクトの画像を更にプレイヤに提示するようにしてもよい。更に、指標データが所定の条件を満たしていると判定されたときに、第２パラメータ変更手段によるプレイヤの操作に基づいた第２のパラメータの変更が可能となるようにしてもよい。

上記構成例によれば、指標を反映させるゲーム要素として、例えば、第１のオブジェクトに加えて第２のオブジェクトも提示することが可能となり、指標を反映させるゲーム要素についての興趣性をより高めることができる。

他の構成例として、第１パラメータの値は、一旦指標データが所定の条件を満たした後、当該指標データの変動によって当該所定の条件を満たさなくなっても、第１パラメータ変更手段による変更前の値には戻らないようにしてもよい。

上記構成例によれば、プレイヤのゲームに対するモチベーションを落とさずに維持することが可能となる。

他の構成例として、対戦ゲーム処理手段は、対戦ゲームにおけるプレイヤと対戦相手とのスコアを比較することで勝敗の決定を行い、指標更新手段は、指標データの変動量をプレイヤのスコアに基づいて決定するようにしてもよい。あるいは、指標更新手段は、指標データの変動量を対戦相手のスコアに基づいて決定するようにしてもよい。

上記構成例によれば、例えば、対戦ゲームに負けた場合は自分のスコアに基づく分だけ指標が減少し、勝った場合は、相手のスコアに基づく分だけ指標を増加させることができる。これにより、指標の変動についてプレイヤにわかりやすい形で提示することができる。

他の構成例として、ゲームシステムは、第１パラメータ変更手段によって変更された前記第１パラメータに基づいて、対戦ゲーム処理において用いられる対戦ゲーム用パラメータを変化させる対戦用パラメータ変化手段を更に備えていてもよい。

上記構成例によれば、対戦ゲームについてのモチベーションと、第１パラメータが反映される所定のオブジェクトを変化（例えば成長）させたいというモチベーションという２つのモチベーションを相乗効果的に上昇させることができ、ゲームの興趣性を更に高めることができる。

他の構成例として、所定の育成対象は、複数のオブジェクトから構成される街であってもよく、第１オブジェクトは、当該街に配置可能なオブジェクトであってもよい。

上記構成例によれば、例えば数々の建築物等のオブジェクトが含まれる「街」を成長させていく育成ゲームの興趣性をより高めることができる。

本実施形態によれば、対戦ゲームの勝敗結果に基づく指標を当該対戦ゲーム以外のゲーム要素に反映することが可能な今までにない新しいゲームを提供することができる。

図１は、本実施形態の一例であるゲームシステムの全体像を示す模式図である。 図２は、スマートデバイス１０２の機能ブロック図である。 図３は、サーバ１０１の機能ブロック図である。 図４は、本実施形態のゲーム処理におけるゲーム画面の一例である。 図５は、対戦相手選択画面の一例である。 図６は、対戦ゲームのプレイ画面の一例である。 図７は、リザルト画面の一例である。 図８は、城オブジェクト２０３の成長の一例を示す図である。 図９は、城オブジェクト２０３の成長の一例を示す図である。 図１０は、城オブジェクト２０３の成長の一例を示す図である。 図１１は、サーバ１０１のメインメモリ１２３に記憶されるプログラムおよび情報の一例を示す図である。 図１２は、スマートデバイス１０２のメインメモリ１１３に格納されるプログラムおよび情報の一例を示す図である。 図１３は、本実施形態にかかるゲーム処理の詳細を示すフローチャートである。 図１４は、街画面生成処理の詳細を示すフローチャートである。 図１５は、対戦ゲーム処理の詳細を示すフローチャートである。 図１６は、リザルト処理の詳細を示すフローチャートである。 図１７は、街エリアの他の例を示す図である。 図１８は、街エリアの他の例を示す図である。 図１９は、街エリアの他の例を示す図である。 図２０は、スマートデバイス１０２のメインメモリ１１３に格納されるプログラムおよび情報の他の一例を示す図である。

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

図１は、本実施形態に係るゲームシステムの全体像を示す模式図である。本実施形態のゲームシステム１００は、サーバ１０１と、情報処理装置の一例である複数の携帯型スマートデバイス１０２（以下では、単にスマートデバイスと呼ぶ）とを含んでいる。スマートデバイス１０２は、例えばスマートフォンやタブレット機等である。サーバ１０１と、スマートデバイス１０２とは、インターネットを介して通信可能に構成されている。

次に、上記システムにおける各ハードウェアの構成について説明する。図２は、スマートデバイス１０２の機能ブロック図である。図２において、スマートデバイス１０２は、プロセッサ部１１１と、内部記憶装置１１２と、メインメモリ１１３と、通信部１１４と、操作部１１５と、表示部１１６とを備えている。プロセッサ部１１１は、後述する情報処理を実行したり、スマートデバイス１０２の全体的な動作を制御したりするためのシステムプログラム（図示せず）を実行することで、スマートデバイス１０２の動作を制御する。なお、プロセッサ部１１１は、単一のプロセッサを搭載してもよいし、複数のプロセッサを搭載するようにしてもよい。内部記憶装置１１２には、プロセッサ部１１１によって実行される各種プログラムや当該プログラムで利用される各種データが格納されている。内部記憶装置１１２は、例えば、フラッシュＥＥＰＲＯＭやハードディスク装置である。メインメモリ１１３は、コンピュータプログラムや情報を一時的に記憶する。通信部１１４は、有線、または無線通信によってネットワークと接続し、上記サーバ１０１との間で所定のデータを送受信する。操作部１１５は、例えば、ユーザからの操作を受け付けるための入力装置である。表示部１１６は、典型的には液晶表示装置である。なお、本実施形態に係る処理では、操作部１１５及び表示部１１６として、液晶画面と一体化したタッチパネルを想定する。他の実施形態では、操作部１１５として、タッチパネル以外の所定のポインティングデバイスを用いてもよい。

次に、上記サーバ１０１の構成について説明する。図３は、サーバ１０１の機能ブロック図である。サーバ１０１は、プロセッサ部１２１と、内部記憶装置１２２と、メインメモリ１２３と、通信部１２４とを少なくとも備えている。プロセッサ部１２１は、サーバ１０１を制御するための各種プログラムを実行する。内部記憶装置１２２には、プロセッサ部１２１によって実行される各種プログラムや利用される各種データが格納されている。メインメモリ１２３は、コンピュータプログラムや情報を一時的に記憶する。通信部１２４は、有線、または無線通信によってネットワークと接続し、上記スマートデバイス１０２や他のサーバ（図示せず）との間で所定のデータを送受信する。

次に、本実施形態にかかるゲーム処理の動作概要を説明する。本実施形態にかかるゲーム処理は、対戦型アクションゲームと、所定の育成対象を育成する育成ゲームという２つの異なるゲームの要素を併せ持つゲーム処理である。また、本ゲームでは、対戦型アクションゲームと育成ゲームとを選択的に実行することが可能となっている。そして、本ゲームでは、対戦型アクションゲームにおいて他のプレイヤと対戦し、その勝敗結果に応じて「レート」と呼ばれる値が増減する。そして、このレートに基づいて、上記所定の育成対象の育成処理が実行される。すなわち、レートが育成対象の育成度合いに反映されるというゲームとなっている。

ここで、本実施形態におけるレートについて補足説明する。本実施形態におけるレートは、プレイヤのゲームの腕前や実力を数値で表したものである。つまり、プレイヤの腕前や実力の指標となるような値である。例えば、レートが１〜１０の１０段階で示されるとする。また、ゲームを新規に開始したときの初期レートが「５」であるとする。そして、対戦プレイを行い、勝利すれば、レートが１つ増加される。また、負けた場合は、レートが１つ減少される。そのため、勝ち続ければ、最終的にレートは「１０」となり、負け続ければ、最終的にレートは「１」となる。すなわち、レートが「１０」のプレイヤは、そのゲームの腕前が高いであろうことの指標となり、また、レートが「１」のプレイヤは、あまり腕前は高くないことの指標となる。このように、本実施形態におけるレートは、対戦ゲームの勝敗結果に応じて増減する値であり、プレイヤのゲームの腕前の指標的な意義を有する値である。なお、本実施形態では、当該レートは、後述する住民キャラクタの数（街の人口）として示される。

次に、本ゲームの大まかな流れについて、図面を用いて更に説明する。図４は、本実施形態にかかるゲーム処理におけるゲーム画面の一例である。当該画面は、本ゲームにおける、いわゆる「ホーム画面」に相当する画面である。図４において、画面には街エリア２０１とメニューエリア２０２の２つの表示領域が含まれている。街エリア２０１には、城オブジェクト２０３が表示されている。なお、本実施形態では、「街」は、いわばプレイヤの「王国」という意味合いを有する用語である。そして、本実施形態では、当該「街」を育成対象としており、より具体的には、城オブジェクト２０３を上記の育成対象としている（城オブジェクトの成長＝街の成長という捉え方である）。メニューエリア２０２には、２つのボタン画像２０４Ａ、２０４Ｂが表示されている。ボタン画像２０４Ａは、上述したようなアクションゲームを一人でプレイするためのボタン画像である。ボタン画像２０４Ｂは、上記アクションゲームを他のプレイヤと対戦形式でプレイするためのボタン画像である。つまり、当該ホーム画面から、対戦型アクションゲームを選択的に実行することが可能となっている。本実施形態では、この対戦形式でアクションゲームをプレイする場合を説明する。また、本実施形態では、横スクロール型のジャンプアクションゲームを用いて、１対１の形式での対戦プレイが行われる。制限時間内に、ステージ内に配置されたコインの数をより多く獲得したほうが勝ちとなるゲームである。なお、本実施形態では、横スクロール型のジャンプアクションゲームの例を示すが、対戦ゲームであればどのようなものでもよい。他の実施形態では、例えば、レースゲームや対戦格闘ゲームを採用しても良いし、アクションゲームに限らず、例えばカードゲーム等のテーブルゲームやクイズゲームを採用しても良い。

以下、上記のようなアクションゲームについて図面を用いて説明する。図４において、プレイヤがボタン画像２０４Ｂをタップすると、対戦プレイを希望する旨の指示がサーバ１０１に送信される。これに応じて、サーバ１０１において対戦相手の選出処理（マッチング処理）が行われる。そして、その結果がサーバ１０１から送信され、これに基づいて図５のような対戦相手の選択画面が表示される。ここで、当該選出は、上述したようなレートを利用して行われる。具体的には、プレイヤと近いレートの他のプレイヤをランダムで選択する処理がサーバ１０１において実行される。すなわち、腕前がある程度近いプレイヤ同士で対戦が行われるように選出がされる。

図５の対戦相手選択画面では、画面左上にプレイヤの情報が表示され、画面右側に５人分の対戦相手候補情報がリスト状で示されている。各候補の情報としては、プレイヤ名、そのプレイヤに関する画像（例えば似顔絵画像）、レートが示されている。プレイヤは、当該対戦候補の中から任意の相手をタップすることで、その相手との対戦プレイを開始することができる。

なお、他の実施形態では、上記のような複数人の対戦相手候補の選出は行わずに、一人だけ選出するようにしてもよい。この場合は、上記対戦相手選択画面は表示されず、対戦相手が選出されれば、その相手の情報を表示して対戦プレイが開始されるようにすればよい。

ここで、本実施形態での対戦は、リアルタイム形式の対戦ではなく、非同期型で対戦プレイが行われるものとする。具体的には、いわゆる「ゴーストデータ」と対戦する形式である。上記対戦候補選択画面から任意の候補をタップすると、その候補プレイヤのゴーストデータがサーバ１０１からダウンロードされる。このゴーストデータには、プレイしたステージの構成を示す情報と、プレイ内容（対戦相手がどのような操作を行ったか）を示す情報、そのプレイヤが獲得したコイン数、および後述する住民キャラクタ数を示す情報等が含まれている。そして、スマートデバイス１０２において、当該ゴーストデータに基づいてゲームステージ（仮想ゲーム空間）が生成され、プレイヤが、当該ステージをプレイするという流れとなる。つまり、ダウンロードした対戦相手と同じステージにおいて、同じ制限時間でコインをどれだけ獲得できるか、を非同期で競う形となる。なお、上記のようなゴーストデータは、上記アクションゲームを一人でプレイしたときのプレイ内容に基づいて適宜生成され、サーバ１０１にアップロードされる。また、他の実施形態では、上記のようなゴーストデータを使わない、リアルタイム形式の対戦ゲームを採用してもよい。

図６に、当該アクションゲーム（対戦ゲーム）のプレイ画面の一例を示す。上記のように、本アクションゲームは、横スクロール型のジャンプアクションゲームである。図６に示すゲーム画面には、プレイヤキャラクタ２２１、コイン２２２が示されている。また、図示は省略するが、敵キャラクタも存在している。プレイヤは、プレイヤキャラクタ２２１を操作して、制限時間内にコイン２２２を集めながらゲームステージを進んでいくことができる。

ところで、本実施形態では、コースを進めていく過程で、所定の条件を満たす等することで、上記コインとは別に「住民キャラクタ」を獲得することができる。当該住民キャラクタは、上述した城オブジェクト２０３の住民という位置づけのキャラクタである。そして、当該住民キャラクタの数が、城オブジェクトの育成（成長）と関連している。すなわち、ゲームを新規に開始した当初は、住民キャラクタは１人だけであり、プレイヤは、対戦プレイを繰り返すことで、住民キャラクタを集める（数を増やす）ことができる。そして、住民キャラクタの数(換言すれば、街の人口）が増えると、城オブジェクト２０３が成長する（具体的には、外観が変化していく）。城オブジェクト２０３の成長については後述する。

次に、対戦プレイの勝敗判定に関して説明する。上記アクションゲームをプレイし、制限時間が来ることで、上記ステージでのプレイは終了し、図７に示すようなリザルト画面が表示される。図７では、画面上半分にプレイヤに関する情報が示され、下半分に対戦相手に関する情報が示される。具体的には、プレイヤに関する情報として、プレイヤ名、プレイヤに関する画像２３１Ａ、プレイヤが集めた住民キャラクタ２３３Ａ、プレイヤが集めたコイン枚数２３２Ａが表示される。また、簡易リプレイ領域２３４Ａも表示されている。この表示領域では、プレイヤのプレイ内容が簡易的にリプレイ表示される。また、対戦相手に関する具体的な情報としては、対戦相手に関する画像２３１Ｂ、対戦相手が集めた住民キャラクタ２３３Ｂ、対戦相手が集めたコイン枚数２３２Ｂが表示される。また、対戦相手のプレイ内容が簡易的にリプレイ表示される簡易リプレイ領域２３４Ｂも表示されている。なお、当該リザルト画面の表示に際して、そのときの対戦プレイの結果を示すデータがサーバ１０１にアップロードされるように構成しても良い。

本ゲームでは、対戦の勝敗は、集めたコイン枚数の大小で決定される。図７の例では、プレイヤが６１枚、対戦相手は１０６枚のコインを集めたことが示される。そのため、この図の例では、対戦相手の勝利と判定される。そして、上記住民キャラクタに関しては、勝敗の結果に応じた次のような処理が行われる。まず、プレイヤが「勝利」した場合は、対戦相手が集めた住民キャラクタ２３３Ｂを獲得することができる。すなわち、自分の街の人口を増やすことができる。一方、プレイヤが「敗北」した場合は、そのプレイにおいてプレイヤが集めた住民キャラクタ２３３Ａの分だけ、現在の街の人口から減算される。つまり、対戦に勝てば、相手の集めた住民キャラクタを獲得でき、敗北すれば、そのプレイで自分が集めた分の住民キャラクタを失ってしまうことになる。そして、この住民キャラクタの数、すなわち街の人口が、上述したレートに相当するものである。つまり、対戦の勝敗結果に応じて増減するパラメータである。更に言うと、住民キャラクタの数は、プレイヤが敗北したときは、自分のプレイ結果（自分が集めた住民キャラクタ数）に基づいて減少し、勝利したときは、対戦相手のプレイ結果（対戦相手が集めた住民キャラクタ数）に基づいて増加するものといえる。すなわち、住民キャラクタは、自分と対戦相手のいずれか一方のプレイ結果に基づいて増減するパラメータともいえる。なお、他の実施形態では、住民キャラクタの増減については、自分のプレイ結果および対戦相手のプレイ結果の双方に基づいてその増減値を決定するようにしてもよい。

なお、本実施形態では、上記住民キャラクタの増減は、プレイヤに対してのみ影響し、対戦相手には影響を与えないものとする。つまり、プレイヤが勝利し、対戦相手の住民キャラクタを獲得したとしても、その対戦相手のデータから住民キャラクタの数が減算されることはないものとする。逆に、プレイヤが敗北し、住民キャラクタの数が減ったとしても、その減った分が対戦相手の住民キャラクタに加算されることもないものとする。上記のように、本実施形態ではゴーストデータを用いた非同期方式の対戦であり、同じゴーストデータが多数のプレイヤにダウンロードされることも想定されることから、対戦相手のデータにまでは影響を及ぼさないようにしている。

次に、城オブジェクト２０３（街）の成長に関して説明する。上記のように、対戦プレイの勝敗結果に応じて、住民キャラクタ２３３の数が増減する。そして、住民キャラクタの数が増えることで、城オブジェクト２０３が成長する。図８〜図１０に、城オブジェクト２０３の成長の一例を示す。図８は、ゲームを新規に開始した直後の城オブジェクト２０３を示す。この状態の城オブジェクト２０３は、その規模がかなり小さな状態となっている。以下では、この状態の城オブジェクト２０３を「ランク１」の城と呼ぶ。

「ランク１」の状態において、上記のような対戦を繰り返し、住民キャラクタを集めた結果、例えば住民キャラクタが１００人を越えたとき、図９に示すように、城オブジェクト２０３の外観が変化する。図９の例では、城オブジェクト２０３の規模が、図８のものよりも大きくなっている。なお、この外観の変化は、例えば住民キャラクタが１００人を越えた時点で自動的に変化する。換言すれば、プレイヤが例えば所定のポイントを消費して城オブジェクト２０３を成長させる、というようなものではなく、所定条件を満たした場合に、自動的に成長するものである。以下では、図９の状態の城オブジェクト２０３を「ランク２」の城と呼ぶ。

更に、「ランク２」の状態において、上記のような対戦を繰り返し、住民キャラクタを集めた結果、例えば住民キャラクタが５００人を越えたとき、図１０に示すように、城オブジェクト２０３の外観が更に変化する。図１０の例では、城オブジェクト２０３の規模が、図９のものよりも更に大きなものとなっている。以下では、図１０の状態の城オブジェクト２０３を「ランク３」の城と呼ぶ。

このように、住民キャラクタ２３３の数が増えていくことによって、城オブジェクト２０３が成長していくことになる。上記のように、住民キャラクタの数は上記レートの意義を有し、プレイヤのゲームの腕前や努力を示すという側面もある。そのため、ゲームが上手いプレイヤほど、城オブジェクト２０３の規模が大きなものとなり得る。このことは、換言すれば、対戦アクションゲームにおけるプレイヤのゲームの腕前・努力を、城オブジェクト２０３という形で視覚的に反映してプレイヤに提示するものともいえる。そのため、ゲームに対するプレイヤのモチベーションをより向上させることができる。また、プレイヤの腕前に応じたものとなるため、城オブジェクト２０３の成長度合いはプレイヤ毎に異なるものとなる。つまり、プレイヤ毎に異なる城オブジェクト２０３に成長することになる。なお、上記の例では、３段階の城オブジェクト２０３の成長例を示したが、成長の段階をより多く、細分化してもよいことは言うまでもない。

なお、本実施形態では、一旦成長した城オブジェクト２０３は、前のランクの状態に戻ることはないものとする。上記のように、住民キャラクタの数は対戦の勝敗結果に応じて増減するため、一旦１００人となったものが、その後、９０人に減ってしまうこともあり得る。このような場合でも、例えば、住民キャラクタが１００人を越えたため、城オブジェクト２０３が上記「ランク２」の状態に一旦成長すれば、その後住民キャラクタ２３３が９０人まで減ったとしても、上記「ランク１」の状態に戻ることはなく、「ランク２」の状態が維持される。換言すれば、城オブジェクトの成長度合いと住民キャラクタの数とは、完全に連動（一体化）するものではない。仮に両者を完全に連動させると、住民キャラクタ２３３が減った（レートが下がった）ときに城オブジェクト２０３のランクも下がってしまい、プレイヤの対戦プレイに対するモチベーションを低下させてしまう。そのため、上記のように住民キャラクタが減ったとしても、城オブジェクト２０３の成長度合いは維持することで、プレイヤのモチベーションの維持を図るものである。

次に、図１１〜図１６を参照して、本実施形態におけるゲーム処理の詳細を説明する。

図１１は、サーバ１０１のメインメモリ１２３に記憶されるプログラムおよび情報の一例を示している。サーバ１０１のメインメモリ１２３には、選出処理プログラム３０１、プレイヤデータベース３０２、対戦用ゴーストデータ３０３等が記憶されている

選出処理プログラム３０１は、スマートデバイス１０２からの要求を受けて、対戦相手の選出を行うためのプログラムである。

プレイヤデータベース３０２は、本ゲームをプレイしているプレイヤに関する情報が保存されているデータベースである。具体的には、各プレイヤを識別するためのＩＤ、住民キャラクタ数（すなわち、レート）や、現在の城ランク等のデータが、各プレイヤに対応づけられて記憶されている。

対戦用ゴーストデータ３０３は、上記のような対戦プレイの際に用いられるゴーストデータであり、複数のプレイヤにかかるゴーストデータが記憶されている。当該対戦用ゴーストデータは、上記アクションゲームを一人でプレイしたときのプレイ内容に基づいて適宜生成され、サーバ１０１にアップロードされて記憶される。対戦用ゴーストデータ３０３には、例えば、当該ゴーストデータにかかるプレイヤのＩＤ、そのゲームステージの構成を示すデータ、獲得したコイン枚数、獲得した住民キャラクタ数等を示すデータが含まれている。

図１２は、スマートデバイス１０２のメインメモリ１１３に格納されるプログラムおよび情報の一例を示している。メインメモリ１１３には、ゲーム処理プログラム３２１、操作データ３２２、住民キャラクタ数データ３２３、現在の城ランクデータ３２４、城オブジェクトデータ３２５、ランクアップ条件定義データ３２６、アクションステージ用データ３２７、対戦ワークデータ３２８等が格納される。

ゲーム処理プログラム３２１は、上述したようなゲーム処理を実行するためのプログラムである。具体的には、後述する図１３のフローチャート処理を実行するためのプログラムである。

操作データ３２２は、スマートデバイス１０２に対して行われた各種操作を示すデータである。本実施形態では、操作データ３２２には、ボタンデータやタッチパネルデータが含まれる。これらのデータは操作部１１５に対して行われた操作内容を示すデータであり、各種ボタンの押下状態やタッチパネルのタッチ座標やタッチ継続時間等を示すデータである。

住民キャラクタ数データ３２３は、上述したような住民キャラクタの数（街の人口）を示すデータである。また、本データは、上述のレートとしての意義も有するものである。

現在の城ランクデータ３２４は、上記城オブジェクト２０３の成長度合いを示すデータである。本実施形態では、上記のような「ランク」という概念で城オブジェクト２０３の成長度合いが示されるものとする。

城オブジェクトデータ３２５は、城オブジェクト２０３を描画するために用いられる画像データやモデルデータである。当該城オブジェクトデータ３２５には、上記「ランク」に対応した城オブジェクト２０３の画像データ等が記憶されている。

ランクアップ条件定義データ３２６は、城オブジェクト２０３を成長させる（ランクを上げる）ための条件を定義したデータである。例えば、「ランク１の状態で住民オブジェクト数が１００以上となったとき、ランク２に成長させる」等の条件が定義されているデータである。

アクションステージ用データ３２７は、上述したようなアクションゲームにかかる仮想ゲーム空間を構築するための各種データである。すなわち、各種地形オブジェクトや敵キャラクタ、プレイヤキャラクタ等のモデルデータ等が含まれている。

対戦ワークデータ３２８は、上記のような対戦ゲームを実行する際に一時的に生成されて用いられるデータである。対戦ワークデータ３２８には、獲得コイン数データ３２９、獲得住民数データ３３０、対戦相手ゴーストデータ３３１、ステージデータ３３２等が含まれる。獲得コイン数データ３２９は、上記のような対戦プレイ中にプレイヤが獲得したコイン数を示すデータである。獲得住民数データ３３０は、同様に対戦プレイ中にプレイヤが獲得した上記住民キャラクタ数を示すデータである。対戦相手ゴーストデータ３３１は、対戦相手にかかる上記対戦用ゴーストデータ３０３をサーバ１０１からダウンロードして記憶したデータである。その内容は、上記対戦用ゴーストデータ３０３と同内容である。ステージデータ３３２は、上記対戦相手ゴーストデータ３３１に基づいて生成される仮想ゲーム空間の構成を示すデータである。すなわち、地形オブジェクトや敵キャラクタ、コインや住民キャラクタの配置等を示すデータである。

次に、図１３のフローチャートを参照して、スマートデバイス１０２のプロセッサ部１１１によって実行されるゲーム処理の流れを説明する。図１３は、当該ゲーム処理の詳細を示すフローチャートである。

本ゲーム処理がプレイヤの起動指示操作に基づいて起動されると、まず、ステップＳ１で、プロセッサ部１１１は、初期処理を実行する。この処理では、各種データの初期化や、ログイン処理、ゲーム処理に必要なデータをサーバ１０１から取得する処理等が実行される。例えば、プレイヤデータベース３０２から、現在の住民キャラクタ数を取得して住民キャラクタ数データ３２３としてメインメモリ１１３に記憶したり、現在の城ランクを示すデータを取得して現在の城ランクデータ３２４としてメインメモリ１１３に記憶したりする処理等が実行される。

次に、ステップＳ２で、プロセッサ部１１１は、街画面生成処理を実行する。すなわち、上記図４の街エリア２０１に表示すべき画像を生成するための処理が実行される。図１４は、当該街画面生成処理の詳細を示すフローチャートである。図１４において、まず、ステップＳ１１で、プロセッサ部１１１は、現在の城ランクデータ３２４をメインメモリ１１３から取得する。次に、ステップＳ１２で、プロセッサ部１１１は、住民キャラクタ数データ３２３をメインメモリ１１３から取得する。次に、ステップＳ１３で、プロセッサ部１１１は、ランクアップ条件定義データ３２６を参照し、城オブジェクト２０３を成長させるための条件、すなわちランクアップの条件が満たされたか否かを判定する。例えば、現在の城が「ランク１」でかつ住民キャラクタ数が１００人以上である場合、「ランク２」へのランクアップ条件が満たされたと判定されることになる。当該判定の結果、ランクアップ条件が満たされていたときは（ステップＳ１３でＹＥＳ）、ステップＳ１４で、プロセッサ部１１１は、現在の城ランクデータ３２４をランクアップ後のランクを示す内容に更新する（なお、ここで更新された現在の城ランクデータ３２４については、適宜サーバ１０１にも送信され、プレイヤデータベース３０２の内容も適宜更新される）。一方、ランクアップ条件が満たされていないときは（ステップＳ１３でＮＯ）、当該ステップＳ１４の処理はスキップされる。

次に、ステップＳ１５で、プロセッサ部１１１は、現在の城ランクデータ３２４を再度取得し、その内容に対応する城オブジェクト２０３の画像データ等を、城オブジェクトデータ３２５から取得する。

次に、ステップＳ１６で、プロセッサ部１１１は、上記取得した画像データ等に基づき、城オブジェクト２０３の画像を生成する。以上で、街画面生成処理が終了する。

図１３に戻り、次に、ステップＳ３で、プロセッサ部１１１は、上記生成された城オブジェクト２０３の画像等に基づき、上記図４で示したようなホーム画面を生成して表示する。

次に、ステップＳ４で、プロセッサ部１１１は、操作データ３２２を取得する。続くステップＳ５で、プロセッサ部１１１は、操作データ３２２に基づき、対戦バトルの開始が選択されたか否かを判定する。すなわち、上記図４の画面で、ボタン画像２０４Ｂがタップされたか否かが判定される。当該判定の結果、対戦バトルの開始が選択されたときは（ステップＳ５でＹＥＳ）、ステップＳ６で、プロセッサ部１１１は、対戦ゲーム処理を実行する。

図１５は、上記対戦ゲーム処理の詳細を示すフローチャートである。図１５において、まず、ステップＳ２１で、プロセッサ部１１１は、対戦相手を探すための選出処理を実行する。具体的には、サーバ１０１に対して、プレイヤの住民キャラクタ数データ３２３（すなわち、レート）等の情報と共に、選出処理の依頼を送信する。これを受けて、サーバ１０１側で、プレイヤデータベース３０２が参照されて、住民キャラクタ数が近いプレイヤからランダムに５名抽出される。そして、当該抽出結果を示すデータがサーバ１０１からスマートデバイス１０２に送信される。当該データの受信完了をもって、当該選出処理は終了する。

次に、ステップＳ２２で、プロセッサ部１１１は、上記サーバ１０１から受信した抽出結果を示すデータに基づき、上記図５で示したような対戦相手選択画面を生成し、表示する処理を実行する。そして、この画面に対し、プレイヤが所定の対戦相手を選択する操作を行うと、ステップＳ２３で、プロセッサ部１１１は、アクションゲーム処理を実行する。当該処理をより具体的に説明すると、まず、選択された対戦相手にかかる対戦用ゴーストデータ３０３をサーバ１０１から取得する処理が実行される。そして、当該対戦用ゴーストデータ３０３に基づいて仮想ゲーム空間（ゲームステージ）が生成され、プレイヤキャラクタ等の各種キャラクタも配置される。そして、ゲーム画面が表示され、プレイヤの操作に基づくアクションゲーム処理が適宜実行される。この処理において、獲得コイン数データ３２９や獲得住民数データ３３０の内容は適宜更新される。

次に、予め設定されていた制限時間が経過することによってアクションゲーム処理が終了すると、ステップＳ２４で、プロセッサ部１１１は、リザルト処理を実行する。図１６は、当該リザルト処理の詳細を示すフローチャートである。図１６において、まず、ステップＳ３１で、プロセッサ部１１１は、獲得コイン数データ３２９と、対戦相手ゴーストデータ３３１に含まれる対戦相手の獲得コイン数のデータに基づいて、対戦の勝敗判定を行う。

次に、ステップＳ３２で、プロセッサ部１１１は、勝敗判定の結果、プレイヤの勝利であるか否かを判定する。当該判定の結果、プレイヤの勝利であるときは（ステップＳ３２でＹＥＳ）、ステップＳ３３で、プロセッサ部１１１は、対戦相手ゴーストデータ３３１で示される対戦相手の獲得住民キャラクタ数を、住民キャラクタ数データ３２３に加算する。一方、プレイヤの敗北であるときは（ステップＳ３２でＮＯ）、ステップＳ３４で、プロセッサ部１１１は、獲得住民数データ３３０で示される数を住民キャラクタ数データ３２３から減算する（なお、ここで更新された住民キャラクタ数データ３２３については、適宜サーバ１０１にも送信され、プレイヤデータベース３０２の内容も適宜更新される）。

次に、ステップＳ３５で、プロセッサ部１１１は、上記図７で示したようなリザルト画面を生成し、表示する。以上で、リザルト処理が終了する。

図１５に戻り、リザルト処理が終了すれば、対戦ゲーム処理も終了する。

図１３に戻り、上記ステップＳ５の判定の結果、対戦が選択されていなかったときは（ステップＳ５でＮＯ）、ステップＳ７で、プロセッサ部１１１は、操作データ３２２に基づいてその他のゲーム処理を適宜実行する。例えば、一人用のアクションゲーム処理の実行等が行われる。

次に、ステップＳ８で、プロセッサ部１１１は、本ゲームを終了する条件が満たされたか否かを判定し、当該条件が満たされていないときは（ステップＳ８でＮＯ）、上記ステップＳ２に戻り、処理を繰り返す。当該条件が満たされていたときは（ステップＳ８でＹＥＳ）、本ゲーム処理を終了する。以上で、本実施形態にかかるゲーム処理の説明を終了する。

このように、本実施形態のゲーム処理では、アクションゲームで対戦をプレイヤに楽しませると同時に、対戦結果に応じてレート（住民キャラクタ数）を増減させ、このレートを城オブジェクト２０３の成長に反映させている。これにより、プレイヤのゲームの腕前や実力や努力を示す指標（レート）に、成長要素の基準としての意義も持たせることで、対戦アクションゲームと城オブジェクト２０３の育成の双方に対するプレイへのモチベーションを相乗効果的に向上させることができる。また、上記のようなプレイヤの腕前を示す指標と、成長要素の基準となる要素とを「住民キャラクタ」として統一していることで、プレイヤに理解しやすい形で提示することができる。

なお、上記の例では、「街」の育成例として城オブジェクト２０３が成長する例を示した。この他、「街」の育成の他の例として、例えば、住民キャラクタの人口が増加するに連れて、城オブジェクト２０３の周囲に所定の建物オブジェクトが段階的に配置できるようにしても良い。図１７に、このような場合の街エリア２０１の画像の一例を示す。図１７では、街エリア２０１の中央部分に城オブジェクト２０３が表示される中央領域２５１がある。そして、その周囲を囲むようにして、点線で示される１２個の四角形の領域（以下、周辺領域）２５２が示されている。城オブジェクト２０３の成長については、上記と同様に、住民キャラクタの数が増えるに連れて、その外観が自動的に変化していく。すなわち、上記現在の城ランクデータ３２４に応じた外観となる。これに加えて、例えば、城オブジェクト２０３が「ランク１」の状態から「ランク２」に成長したとき、上記１２の周辺領域２５２の中から任意の１つの領域について、プレイヤの操作に基づいて所定の建物オブジェクトが配置できるようにしてもよい（図１８参照）。例えば、プレイヤが１２の周辺領域２５２の中から任意の１つの領域をタップすることで、その領域に配置する建物オブジェクトを選択する画面が表示されるようにすればよい。そして、城オブジェクト２０３が「ランク２」の状態から「ランク３」に成長したときにも、更にもう１つの領域について、所定の建物オブジェクトが配置できるようにしてもよい（図１９参照）。あるいは、城オブジェクト２０３のランクとは関係なく、住民キャラクタ数が所定数を越えたときに、上記１２の周辺領域２５２の中から任意の１つの領域について、プレイヤの操作に基づいて所定の建物オブジェクトが配置できるようにしてもよい。例えば、住民キャラクタ数が５０人以上になったときに、任意の１つの領域について建物オブジェクトを配置可能とする。その後、住民キャラクタ数が１００人以上となったときに、更にもう一つの領域について建物オブジェクトを配置可能とするようにしてもよい。つまり、住民キャラクタ数の増加に連れて、１２の周辺領域２５２について１つずつ段階的に、プレイヤの操作に基づいて所定の建物オブジェクトが配置できるようにしてもよい。逆に言うと、住民キャラクタ数が増加したからといって、自動的に配置されるものではない。すなわち、城オブジェクト２０３については自動的に成長するが、周辺領域２５２に関してはプレイヤが手動で建物オブジェクトを設置する必要があるという構成となる。このように、育成対象としての「街」として、城オブジェクト２０３と、上記のような周辺領域２５２の配置可能な建物オブジェクトの２種類のオブジェクトを含めるようにしてもよい。このことは、城オブジェクト２０３の成長も、建物オブジェクトとの配置も「街」の育成の一環であるといえる。

更に、上述したような「街」を構成する要素として、上記のような建物オブジェクトの他、例えば、花、池、畑、像、遊具等の、建物ではないオブジェクトを配置可能としてもよい。また、上記の例では、上記城オブジェクト２０３と周辺領域２５２に配置されるオブジェクトとは、別領域に配置される例となっていた。しかし、このような２種のオブジェクトについて別領域に配置される場合に限るものではなく、一方が他方の領域内に含まれるような配置形態としてもよい。例えば、城オブジェクト２０３の内部に「部屋」という領域を用意しておき、この「部屋」に他のオブジェクト（家具オブジェクト等）を配置可能な構成としてもよい。また、この場合は、城オブジェクト２０３が成長することで、城の内部の「部屋」の数が増えるようにしてもよい。

また、このように周辺領域２５２を利用する場合、当該城オブジェクト２０３に関連するデータとして、上記図１２に示したデータに加え、例えば、図２０に示すように周辺領域データ３４１を更に持たせるようにすればよい。図２０の周辺領域データ３４１には、上記１２の周辺領域２５２に対応する第１領域データ３４２Ａ〜第１２領域データ３４２Ｌが含まれている。各領域データ３４２には、その領域に建物オブジェクトが配置されているか否かを示す情報と、配置されている建物オブジェクト自身を示す情報等が含まれる。そして、当初は各領域データ３４２の変更はできない状態としておき、住民キャラクタ数の増加に伴って、１つずつ段階的に各領域データ３４２の変更を（ユーザの操作に基づいて）可能とするようにすればよい。そして、当該各領域データ３４２の内容に基づいて、対応する周辺領域２５２に、城オブジェクト２０３とは別の建物オブジェクトを追加表示するようにすればよい。これにより、街の育成に関して、より興趣性を高めることが可能となる。

また、育成対象については、上記のような城オブジェクト２０３の他、例えばタワー型のオブジェクトであってもよい。タワー型オブジェクトを育成対象とする場合は、例えば、住民キャラクタの増加に伴い、タワーの高さが伸びていくようにすればよい。また、上記の例では育成対象の「街」として、単一の城オブジェクト２０３だけの場合と、城オブジェクト２０３に加えて上記周辺領域２５２に配置されるオブジェクトも含めた場合とを例示していた。この他、育成対象である「街」は、例えば、上記のような城オブジェクト２０３は存在せずに、複数の住宅オブジェクトや店オブジェクト等の建物オブジェクトの他、道路オブジェクトや乗り物オブジェクト等の様々な種類のオブジェクトから構成されるような街であってもよい。このような場合は、例えば、ゲーム開始当初は、街には建物オブジェクトが２〜３個しかないという状態であり、住民キャラクタの増加に伴い、建物オブジェクトの数も自動的に増加していくようにすればよい。また、育成対象としては、「街」という形態に限らず、例えば、都市、村、島、部屋等の、所定の領域内に複数のオブジェクトが配置されるようなものであれば、どのような形態であってもよい。更には、その他の育成対象として、生き物をモチーフとしたオブジェクトを育成対象としてもよい。例えば、所定の動物オブジェクトや人物オブジェクトを育成対象として表示してもよい。

また、その他、アクションゲームにおけるプレイの内容に応じて、成長の方向性が変化するようにしてもよい。例えば、上記住民キャラクタについて、いくつかのタイプを出現させるようにする。一例として、「タイプＡ住民」、「タイプＢ住民」、「タイプＣ住民」の３種類の住民キャラクタが定義されているとする。それぞれの住民キャラクタ数は、上述したような処理と同様に、対戦の勝敗結果に応じて増減する。そして、アクションゲームにおいてプレイヤが獲得した住民キャラクタにおけるタイプの比率に応じて、城オブジェクト２０３の成長内容を異ならせるようにしても良い。つまり、同じ「ランク２」の状態の城オブジェクト２０３であっても、住民キャラクタのタイプの比率によって、その外観を異ならせるようにしても良い。例えば、住民キャラクタが１００人いるとして、そのうち８０人が「タイプＡ住民」である場合と、同じく８０人が「タイプＢ住民」である場合とでは、「ランク２」状態の城オブジェクト２０３の外観を異なるものとしてもよい。

また、例えば、城オブジェクト２０３に複数の成長パラメータを設定しておき、上記複数のタイプの住民キャラクタに応じて、当該成長パラメータに与える影響度を異ならせるようにしても良い。例えば、城オブジェクトの色に関するパラメータであるパラメータＡ、形に関するパラメータであるパラメータＢ、大きさに関するパラメータであるパラメータＣの３つのパラメータを、城オブジェクト２０３の外観に影響を及ぼすパラメータとして設定しておく。そして、個々のアクションゲームの終了時（リザルト画面時）に、そのときに獲得した各タイプの住民キャラクタ数に応じて、各パラメータの値を変更してもよい。例えば、タイプＡ住民の数をパラメータＡに加算し、タイプＢ住民の数をパラメータＢに加算し、タイプＣ住民の数をパラメータＣに加算する等である。そして、城オブジェクト２０３のランクアップ時に、当該３つのパラメータに基づいてランクアップ後の城オブジェクト２０３の外観を変化させるようにすればよい。これにより、プレイヤのアクションゲームにおけるプレイ内容に応じた、より個性的な城オブジェクト２０３を提示することができ、プレイヤのモチベーションを高めることが可能となる。また、上記のような複数のパラメータを用いる場合は、少なくともの一部のパラメータを上述したレート（住民キャラクタ数）以外の要素に基づいて変化させるようにしてもよい。例えば、ゲームのプレイ時間や、対戦ゲームにおける累計勝利数に基づいてパラメータを変化させるようにしてもよい。更には、一部のパラメータについては、その変化をランダムで変化させるようにしてもよい。例えば、城オブジェクト２０３の大きさに関する上記パラメータＣについては、住民キャラクタ数に基づいて変化するが、城オブジェクト２０３の色や形に関する上記パラメータＡ、Ｂに関してはランダムで変化させるようにしてもよい。

また、上述のような複数種類の住民キャラクタを用いる場合は、上述したレートとして、これら複数種類の住民キャラクタの総人口をレートとして用いても良いし、各種類の住民キャラクタそれぞれの人口をレートとして用いてもよい（後者の場合は、複数種類のレートが用いられることになる）。

また、アクションゲームの勝敗判定に関して、上記の例では獲得コイン枚数で勝敗を決めていたが、他の実施形態では、コインは用いずに、獲得した住民キャラクタの数で勝敗決定するようにしてもよい。

また、上記の例では、レート（住民キャラクタ数）、すなわち、プレイヤの腕前を示す指標を数値で示す例を示したが、この他、例えば「Ａ＋」、「Ａ」、「Ｂ＋」、「Ｂ」等のように、数値以外で当該指標を示すようにしても良い。また、この場合における指標の「上昇」「増加」とは、より高い腕前であることを示す指標に変化することである（例えば、「Ｂ＋」が「Ａ」に変化する場合）。また、指標の「下降」「減少」とは、より低い腕前であることを示す指標に変化することである（例えば、「Ｂ＋」が「Ｂ」に変化する場合）。また、その他、例えば、「段位」のように、数字が小さいものほど高い実力を有することを示すような指標を用いてもよい。この場合は、指標の「上昇」「増加」は、「３段」から「２段」に変化する場合に該当する。また、指標の「下降」「減少」は、「３段」から「４段」に変化する場合に該当する。

更に、他の実施形態では、上述のレート（住民キャラクタ数）が上がることに応じて、上記アクションゲームにおけるプレイヤキャラクタ２２１に関連づけられた所定のパラメータを変化させるようにしてもよい。例えば、住民キャラクタ数が増えることに応じて、プレイヤにとって有利な効果が得られるようにプレイヤキャラクタ２２１のパラメータを変化させても良い。例えば、プレイヤキャラクタ２２１のジャンプ力や移動速度を上昇させてもよい。あるいは、プレイヤキャラクタ２２１の体力や残機数を増やしても良い。あるいはゲームプレイの制限時間を初期値の時間から延長しても良い。また、その他、単純に、プレイヤキャラクタ２２１の外観を変化させるようにしてもよい（この場合は、必ずしも有利な効果を与えられるわけではないが、見た目上の変化を与えることができる）。より具体的には、次のような制御を行えば良い。まず、プレイヤキャラクタ２２１に関するデータとして上述したようなパラメータを用意しておく。そして、レート（住民キャラクタ数）が上がることに応じて、当該プレイヤキャラクタ２２１のパラメータを直接的に変更するという制御を行えば良い。また、他の制御例として、レート（住民キャラクタ数）が上がることに応じて、上記城オブジェクト２０３に関連づけられたパラメータが変化し、当該パラメータに基づいてプレイヤキャラクタ２２１のパラメータが変更されるような制御としてもよい。例えば、城オブジェクト２０３の「高さ」が所定値を超えることで、プレイヤキャラクタ２２１のジャンプ力が上昇する、というような制御としても良い。このような制御を行うことで、対戦ゲームにおいて有利となる効果が得られるため、対戦ゲームに対するプレイヤのモチベーションを上昇させることができる。更に、対戦ゲームについてのモチベーションと、城オブジェクト２０３を成長させたいというモチベーションとが１つのサイクルとして構築され、これら２つのモチベーションについて相乗効果的に上昇させることができ、ゲームの興趣性を更に高めることが可能となる。

本実施例にかかるゲームプログラム等は、プレイヤのゲームの実力を示す指標を用いた新たなゲーム処理を提供することができ、携帯型のスマートデバイスや各種ゲーム装置等の用途に有用である。

１０１ サーバ
１０２ スマートデバイス
１１１ プロセッサ部
１１２ 内部記憶装置
１１３ メインメモリ
１１４ 通信部
１１５ 操作部
１１６ 表示部
１２１ プロセッサ部
１２２ 内部記憶装置
１２３ メインメモリ
１２４ 通信部

Claims (21)

1. 他のプレイヤとの対戦を行う対戦ゲームと、所定の育成対象を育成させる育成ゲームとを含むゲーム処理を実行するゲームシステムであって、
   他のプレイヤとの対戦ゲーム処理を実行する対戦ゲーム処理手段と、
   前記対戦ゲーム処理手段による対戦ゲームにおけるプレイヤの勝敗結果に基づいて変動する指標データを記憶する指標データ記憶手段と、
   前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて前記指標データを更新する指標更新手段と、
   前記指標データが所定の条件を満たしたか否かを判定する判定手段と、
   所定の条件を満たしたと判定した場合、前記所定の育成対象に含まれる第１オブジェクトに関連づけられた第１パラメータを変更する第１パラメータ変更手段と、
   前記変更された第１パラメータが反映された前記第１オブジェクトの画像をプレイヤに提示する提示手段とを備え、
   前記対戦ゲーム処理手段は、前記対戦ゲームにおける前記プレイヤと対戦相手とのスコアを比較することで前記勝敗の決定を行い、
   前記指標更新手段は、前記プレイヤが勝利した場合は、前記対戦相手のスコアが高いほど前記指標データの増加量が多くなるように当該指標データの変動量を決定する、ゲームシステム。
2. 前記ゲームシステムは、前記対戦ゲームと前記育成ゲームとを選択的に実行するゲーム選択手段を更に備える、請求項１に記載のゲームシステム。
3. 前記指標データは、前記プレイヤのゲームの実力を所定の値で示すレートである、請求項１または２に記載のゲームシステム。
4. 前記指標更新手段は、前記対戦ゲームの結果前記プレイヤが勝利したことに基づいて前記指標データの値の上昇または下降のうちのいずれか一方を行い、当該対戦ゲームの結果当該プレイヤが敗北したことに基づいて前記指標データの値の上昇または下降のうちの他方を行う、請求項１ないし３のいずれかに記載のゲームシステム。
5. 前記指標データの値は、前記対戦ゲームにおける前記プレイヤの勝敗結果に基づいて増加または減少する値であり、
   前記指標更新手段は、前記対戦ゲームの結果前記プレイヤが勝利したときは前記指標データの値を増加させ、敗北したときは当該指標データの値を減少させる、請求項４に記載のゲームシステム。
6. 前記ゲームシステムは、前記プレイヤの指標データと近い値を有する他のプレイヤを前記対戦ゲーム処理における対戦相手として選出する選出手段を更に備える、請求項１ないし５のいずれかに記載のゲームシステム。
7. 前記選出手段は、複数の前記対戦相手を対戦候補として選出し、
   前記ゲームシステムは、
   前記複数の対戦候補のうちのいずれかをプレイヤが選択可能なように当該複数の対戦候補を表示する候補表示手段と、
   前記プレイヤの操作に基づいて前記複数の対戦候補のうちのいずれかを選択する対戦相手選択手段を更に備える、請求項６に記載のゲームシステム。
8. 前記判定手段は、前記指標データの値が所定の閾値を超えたときに、前記所定の条件を満たしたと判定する、請求項１ないし７のいずれかに記載のゲームシステム。
9. 前記第１パラメータ変更手段は、前記指標データが前記所定の条件を満たしたと判定されたとき、前記第１パラメータをプレイヤの操作を要することなく変更する、請求項１ないし８のいずれかに記載のゲームシステム。
10. 前記提示手段は、前記第１パラメータの変更に基づいて前記第１オブジェクトの外観を変更して提示する、請求項１ないし９のいずれかに記載のゲームシステム。
11. 前記ゲームシステムは、前記所定の育成対象に含まれる第２オブジェクトに関連づけられるパラメータであって、前記第１のパラメータとは異なるパラメータである第２のパラメータをプレイヤの操作に基づいて変更する第２パラメータ変更手段を更に備え、
    前記提示手段は、前記第２パラメータ変更手段によって変更された第２のパラメータに基づいた第２のオブジェクトの画像を更にプレイヤに提示する、請求項１ないし１０のいずれかに記載のゲームシステム。
12. 前記指標データが前記所定の条件を満たしたと判定されたときに、前記第２パラメータ変更手段による前記プレイヤの操作に基づいた前記第２のパラメータの変更が可能となる、請求項１１に記載のゲームシステム。
13. 前記第１パラメータの値は、一旦指標データが前記所定の条件を満たした後、当該指標データの変動によって当該所定の条件を満たさなくなっても、前記第１パラメータ変更手段による変更前の値には戻らない、請求項１ないし１２のいずれかに記載のゲームシステム。
14. 前記指標更新手段は、前記指標データの変動量を前記プレイヤのスコアに基づいて決定する、請求項１ないし１３のいずれかに記載のゲームシステム。
15. 前記指標更新手段は、前記プレイヤが敗北した場合、前記プレイヤのスコアが高いほど前記指標データの減少量が大きくなるように当該指標データの変動量を決定する、請求項１４に記載のゲームシステム。
16. 前記ゲームシステムは、前記第１パラメータ変更手段によって変更された前記第１パラメータに基づいて、前記対戦ゲーム処理において用いられる対戦ゲーム用パラメータを変化させる対戦用パラメータ変化手段を更に備える、請求項１ないし１５のいずれかに記載のゲームシステム。
17. 前記所定の育成対象は、複数のオブジェクトから構成される街であり、
    前記第１オブジェクトは、前記街に配置可能な前記オブジェクトである、請求項１ないし１６のいずれかに記載のゲームシステム。
18. 前記ゲームシステムは、
    前記対戦ゲーム中におけるプレイヤの操作が所定の条件を満たしたことに応じて、前記所定の育成対象の育成に影響を及ぼすキャラクタであって、複数の種類が予め設定されている育成関連キャラクタを獲得する育成関連キャラクタ獲得手段を更に備え、
    前記指標更新手段は、前記対戦ゲームの開始から前記勝敗結果の判定が行われるときまでに獲得された育成関連キャラクタの総数に応じて前記指標データを更新し、
    前記第１パラメータ変更手段は、前記複数の種類毎の育成関連キャラクタ数に基づいて前記第１パラメータを変更する、請求項１ないし１７のいずれかに記載のゲームシステム。
19. 他のプレイヤとの対戦を行う対戦ゲームと、所定の育成対象を育成させる育成ゲームとを含むゲーム処理を実行するゲームシステムのコンピュータを制御するためのゲーム処理方法であって、
    他のプレイヤとの対戦ゲーム処理を実行する対戦ゲーム処理ステップと、
    前記対戦ゲーム処理ステップによる対戦ゲームにおける前記プレイヤの勝敗結果に基づいて変動する指標データを記憶する指標データ記憶ステップと、
    前記対戦ゲーム処理ステップによる対戦ゲームにおける前記プレイヤの勝敗結果に基づいて前記指標データを更新する指標更新ステップと、
    前記指標データが所定の条件を満たしたか否かを判定する判定ステップと、
    所定の条件を満たしたと判定した場合、前記所定の育成対象に含まれる第１オブジェクトに関連づけられた第１パラメータを変更する第１パラメータ変更ステップと、
    前記変更されたパラメータが反映された前記第１オブジェクトの画像をプレイヤに提示する提示ステップとを前記コンピュータに実行させ、
    前記対戦ゲーム処理ステップでは、前記対戦ゲームにおける前記プレイヤと対戦相手とのスコアを比較することで前記勝敗の決定を行い、
    前記指標更新ステップでは、前記プレイヤが勝利した場合は、前記対戦相手のスコアが高いほど前記指標データの増加量が多くなるように当該指標データの変動量を決定する、ゲーム処理方法。
20. 他のプレイヤとの対戦を行う対戦ゲームと、所定の育成対象を育成させる育成ゲームとを含むゲーム処理を実行するゲームシステムのコンピュータに実行させるゲームプログラムであって、
    前記コンピュータを、
    他のプレイヤとの対戦ゲーム処理を実行する対戦ゲーム処理手段と、
    前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて変動する指標データを記憶する指標データ記憶手段と、
    前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて前記指標データを更新する指標更新手段と、
    前記指標データが所定の条件を満たしたか否かを判定する判定手段と、
    所定の条件を満たしたと判定した場合、前記所定の育成対象に含まれる第１オブジェクトに関連づけられた第１パラメータを変更する第１パラメータ変更手段と、
    前記変更されたパラメータが反映された前記第１オブジェクトの画像をプレイヤに提示する提示手段として機能させ、
    前記対戦ゲーム処理手段は、前記対戦ゲームにおける前記プレイヤと対戦相手とのスコアを比較することで前記勝敗の決定を行い、
    前記指標更新手段は、前記プレイヤが勝利した場合は、前記対戦相手のスコアが高いほど前記指標データの増加量が多くなるように当該指標データの変動量を決定する、ゲームプログラム。
21. 他のプレイヤとの対戦を行う対戦ゲームと、所定の育成対象を育成させる育成ゲームとを含むゲーム処理を実行するゲーム装置であって、
    他のプレイヤとの対戦ゲーム処理を実行する対戦ゲーム処理手段と、
    前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて変動する指標データを記憶する指標データ記憶手段と、
    前記対戦ゲーム処理手段による対戦ゲームにおける前記プレイヤの勝敗結果に基づいて前記指標データを更新する指標更新手段と、
    前記指標データが所定の条件を満たしたか否かを判定する判定手段と、
    所定の条件を満たしたと判定した場合、前記所定の育成対象に含まれる第１オブジェクトに関連づけられた第１パラメータを変更する第１パラメータ変更手段と、
    前記変更されたパラメータが反映された前記第１オブジェクトの画像をプレイヤに提示する提示手段とを備え、
    前記対戦ゲーム処理手段は、前記対戦ゲームにおける前記プレイヤと対戦相手とのスコアを比較することで前記勝敗の決定を行い、
    前記指標更新手段は、前記プレイヤが勝利した場合は、前記対戦相手のスコアが高いほど前記指標データの増加量が多くなるように当該指標データの変動量を決定する、ゲーム装置。

Images