JP2020199316A - 情報処理システム、情報処理プログラム、情報処理方法、および情報処理装置 - Google Patents

Abstract

【課題】コンテンツを十分に所有していないため、グループにコンテンツを追加できないユーザであっても、ゲームを満足に楽しむことのできる機会を与えることが可能な情報処理システムを提供すること。【解決手段】まず、ユーザが所有する所有コンテンツから、当該ユーザの操作に基づいて選択されたコンテンツをグループに追加する。次に、当該追加の結果、さらにグループにコンテンツを追加することが可能な場合、所有コンテンツとは異なる非所有コンテンツから、所定のコンテンツを当該グループに追加する。そして、当該グループに含まれるコンテンツを用いたゲームを実行する。【選択図】図１７

Description

本発明は、ユーザが所有する複数のコンテンツで構成されたグループを用いたゲームを実行するゲーム処理の制御に関する。

従来から、ユーザが選択したキャラクタを含む複数のキャラクタによって編成されるグループを用いて進行させるゲームが知られている（例えば、特許文献１）。

特開２００８−２６４１８２号公報

上記のようなゲームでは、十分な数のコンテンツを有しないユーザは、グループに追加できるコンテンツ数が足りず、ゲームを満足に楽しむことができなかった。

それ故に、本発明の目的は、コンテンツを十分に所有していないため、グループにコンテンツを追加できないユーザであっても、ゲームを満足に楽しむことのできる機会を与えることが可能な情報処理システム、情報処理プログラム、情報処理装置を提供することである。

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

構成例の一例は、第１追加手段と、第２追加手段と、ゲーム実行手段とを備える、情報処理システムである。第１追加手段は、ユーザが所有する所有コンテンツから、当該ユーザの操作に基づいて選択されたコンテンツをグループに追加する。第２追加手段は、第１追加手段による追加の結果、さらにグループにコンテンツを追加することが可能な場合、ユーザが所有しない非所有コンテンツの中から、所定のコンテンツを当該グループに追加する。ゲーム実行手段は、グループに含まれるコンテンツを用いたゲームを実行する。

上記構成例によれば、ユーザ操作による所有コンテンツの追加の結果、さらにグループにコンテンツを追加することが可能な場合には、ユーザは自身が所有しないコンテンツの中からコンテンツをグループに追加してゲームを実行することができる。そのため、コンテンツの所有数が十分ではないためにグループに十分なコンテンツを追加できないユーザに対しても、ゲームを満足に楽しむことのできる機会を提供することができる

他の構成例として、第２追加手段は、ユーザの操作の後、グループにコンテンツを追加することが可能な場合、非所有コンテンツの中から追加可能な分の所定のコンテンツを当該グループに追加してもよい。

上記構成例によれば、ユーザは自身の所有しないコンテンツの中から追加可能な分のコンテンツをグループに追加するため、グループ編成操作にかかるユーザ操作の煩雑さを解消し、利便性を高めることができる。例えば、グループの編成枠の全てを埋めることが要求されるゲームにおいては、グループ編成操作にかかるユーザ操作が煩雑となるが、上記
構成例によれば、ユーザ操作の後、非所有コンテンツから追加可能な分の所定のコンテンツを当該グループに追加するため、グループ編成操作にかかるユーザ操作の煩雑さを解消し、利便性を高めることができる。

他の構成例として、第２追加手段は、ユーザの操作の後、グループにコンテンツを追加することが可能な場合、所定の規則に従って、非所有コンテンツから所定のコンテンツを自動で当該グループに追加するようにしてもよい。

上記構成例によれば、所定の規則に従い、ユーザが所有しないコンテンツから追加可能な分の所定のコンテンツをグループに追加することができるため、ユーザは複雑な操作を必要とせずに非所有コンテンツをグループに追加することができる。これにより、グループ編成にかかるユーザの操作の負担を軽減でき、利便性を高めることができる。

他の構成例として、第２追加手段は、ユーザの操作の後、グループにコンテンツを追加することが可能な場合、非所有コンテンツの中からランダムに選択したコンテンツを自動で当該グループに追加してもよい。

上記構成例によれば、ユーザは自身が所有しないコンテンツの中からランダムに選択したコンテンツをグループに追加することができるため、グループ編成にかかるユーザの操作の負担を軽減でき、利便性を高めることができる。

他の構成例として、第２追加手段は、第１追加手段による追加の結果、さらにグループにコンテンツを追加することが可能な場合、非所有コンテンツの中から所定のコンテンツを生成して当該グループに追加するようにしてもよい。

上記構成例によれば、ユーザは自身が所有しないコンテンツを生成してグループに追加することができるため、コンテンツの所有数が十分ではないためにグループに十分なコンテンツを追加できないユーザに対しても、ゲームを満足に楽しむことのできる機会を提供することができる。

他の構成例として、第２追加手段は、第１追加手段による追加の結果、さらにグループにコンテンツを追加することが可能な場合、所定の設定に基づいて非所有コンテンツの中から所定のコンテンツを生成し、生成した当該所定のコンテンツを当該グループに追加するようにしてもよい。

上記構成例によれば、ユーザは自身が所有しないコンテンツを生成してグループに追加することができるため、コンテンツの所有数が十分ではないためにグループに十分なコンテンツを追加できないユーザに対しても、ゲームを満足に楽しむことのできる機会を提供することができる。

他の構成例として、第２追加手段は、第１追加手段による追加の結果、さらにグループにコンテンツを追加することが可能な場合、ゲーム実行手段が実行するゲームに応じた設定に基づいて非所有コンテンツの中から所定のコンテンツを生成し、生成した当該所定のコンテンツを当該グループに追加するようにしてもよい。

上記構成例によれば、ゲームに応じた設定に基づいてユーザが所有しないコンテンツを生成し、生成したコンテンツを当ループに追加することができる。これにより、コンテンツの所有数が十分ではないためにグループに十分なコンテンツを追加できないユーザに対しても、ゲームを満足に楽しむことのできる機会を提供することができる。本発明によれば、これに限られない一例として、グループにコンテンツを追加する際に、ユーザ自身の
選択によらずにコンテンツが追加された場合に、例えば性能が低いキャラクタばかりが追加されてしまい、ゲームが十分に楽しめないという状況を回避することが可能となる。これにより、ユーザが所有しているコンテンツ数が少ない場合、あるいは、コンテンツ自体の、例えば性能面においてゲームを楽しむのに十分ではないような場合であっても、ユーザにゲームを楽しませることが可能となる。

他の構成例として、第１追加手段は、ユーザが所有する所有コンテンツから当該ユーザの操作に基づいて選択されたコンテンツを、グループに追加する前の状態のまま当該グループに追加してもよい。

上記構成例によれば、ユーザは自身が所有するコンテンツの中から選択したコンテンツを、グループに追加する前の状態のままグループに追加することができる。これにより、ユーザ自身で選択してグループに追加したコンテンツに関しては、それまでに使用していた状態で使用することができる。つまり、ユーザが使い慣れたコンテンツをそのまま利用させることができる。

他の構成例として、第２追加手段は、第１追加手段による追加の結果、さらにグループにコンテンツを追加することが可能な場合、他のユーザが所有する非所有コンテンツの中から所定のコンテンツを当該グループに追加してもよい。

上記構成例によれば、他のユーザが所有する他のコンテンツからコンテンツをグループに追加することができるため、コンテンツの所有数が十分ではないためにグループに十分なコンテンツを追加できないユーザに対しても、ゲームを満足に楽しむことのできる機会を提供することができる。

他の構成例として、第２追加手段は、第１追加手段による追加の結果、さらにグループにコンテンツを追加することが可能な場合、ユーザと関連づけられた他のユーザが所有する非所有コンテンツの中から所定のコンテンツを当該グループに追加してもよい。

上記構成例によれば、ユーザと関連づけられた他のユーザが所有するコンテンツからコンテンツをグループに追加することができため、コンテンツの所有数が十分ではないためにグループに十分なコンテンツを追加できないユーザに対しても、ゲームを満足に楽しむことのできる機会を提供することができる。

他の構成例として、第２追加手段は、第１追加手段による追加の結果、さらにグループにコンテンツを追加することが可能な場合、ユーザと関連づけられた、複数の他のユーザが各々所有する複数の他のコンテンツの中から所定のコンテンツを当該グループに追加してもよい。

上記構成例によれば、ユーザと関連づけられた複数の他のユーザ、例えばいわゆる「フレンド」がそれぞれ所有するコンテンツをグループに追加できるため、コンテンツの所有数が十分ではないためにグループに十分なコンテンツを追加できないユーザに対しても、ゲームを満足に楽しむことのできる機会を提供することができる。

他の構成例として、情報処理システムは、第２追加手段によってグループに追加された所定のコンテンツのゲームに関する設定を変更したうえでゲーム実行手段が実行するゲームにおいて登場させる、コンテンツ設定変更手段をさらに備えていてもよい。

上記構成例によれば、第２追加手段によってグループに追加されたコンテンツを、ゲームに関する設定を変更したうえでゲームに登場させることができる。これにより、グルー
プにコンテンツを追加する際、ユーザ自身の選択によらずにコンテンツが追加された場合に、例えば性能が低いキャラクタばかりが追加されてしまい、ゲームが十分に楽しめないという状況を回避することが可能となる。

他の構成例として、第２追加手段は、第１追加手段によるコンテンツの追加が完了した後、ゲーム処理の実行開始前に、非所有コンテンツの中から所定のコンテンツを当該グループに追加してもよい。

上記構成例によれば、ゲームの実行開始前に、他のユーザが所有するコンテンツの中からコンテンツをグループに追加することができるため、コンテンツの所有数が十分ではないためにグループに十分なコンテンツを追加できないユーザに対しても、ゲームを満足に楽しむことのできる機会を提供することができる。また、例えば、ユーザが所有するコンテンツを追加した後、他のコンテンツがグループに追加されて、速やかにゲーム処理を開始できるため、ユーザの操作にかかる煩雑さも軽減できる。

他の構成例として、第２追加手段は、第１追加手段によるコンテンツの追加の結果、さらにグループにコンテンツを追加することが可能な場合、非所有コンテンツの中から所定のコンテンツを当該グループに追加し、当該追加後のグループに含まれるコンテンツを、ゲーム実行手段によるゲームの実行開始前に当該ユーザに提示するようにしてもよい。

上記構成例によれば、他のユーザが所有するコンテンツの中からコンテンツをグループに追加した場合には、追加したコンテンツをユーザに提示することができる。これにより、ユーザの選択によらずにグループに追加された他のコンテンツについて、ゲームの開始前にユーザに確認させることができる。

他の構成例として、第１追加手段は、ユーザが所有する所有コンテンツおよび非所有コンテンツの中から、当該ユーザの操作に基づいて選択されたコンテンツをグループに追加するようにしてもよい。

上記構成例によれば、ユーザは自身の操作に基づき、自身が所有するコンテンツだけでなく、ユーザ自身は所有していない非所有コンテンツもグループに追加することができる。これにより、コンテンツの所有数が十分ではないためにグループに十分なコンテンツを追加できないユーザに対しても、ゲームを満足に楽しむことのできる機会を提供することができる。

他の構成例として、第１追加手段は、ユーザが所有する所有コンテンツ、および、当該ユーザに関連付けられた他のユーザが所有する非所有コンテンツの中から、当該ユーザの操作に基づいて選択されたコンテンツをグループに追加してもよい。

上記構成例によれば、ユーザは自身の操作に基づき、自身が所有するコンテンツだけでなく、ユーザに関連付けられた他のユーザが所有するコンテンツもグループに追加することができる。これにより、コンテンツの所有数が十分ではないためにグループに十分なコンテンツを追加できないユーザに対しても、ゲームを満足に楽しむことのできる機会を提供することができる。

他の構成例として、第１追加手段は、ユーザが所有する所有コンテンツ、および、当該ユーザに関連付けられた複数の他のユーザの各々が所有する複数の非所有コンテンツの中から、当該ユーザの操作に基づいて選択された少なくとも２のコンテンツをグループに追加してもよい。

上記構成例によれば、ユーザが所有する所有コンテンツ、および、当該ユーザに関連付けられた複数の他のユーザ（例えばいわゆるフレンド）がそれぞれ所有する複数の非所有コンテンツの中から、当該ユーザの操作に基づいて選択された複数のコンテンツをグループに追加できるため、コンテンツの所有数が十分ではないためにグループに十分なコンテンツを追加できないユーザに対しても、ゲームを満足に楽しむことのできる機会を提供することができる。

他の構成例として、ゲーム実行手段は、グループに含まれる第１コンテンツに関連するパラメータと、当該グループに含まれる当該コンテンツとは異なる第２コンテンツに関連するパラメータとが重複する場合、当該ゲーム実行手段によるゲームの開始を制限するようにしてもよい。

上記構成例によれば、重複するコンテンツがグループ内に含まれないようにできるため、より多種のコンテンツの使用機会をユーザに提供できる。これにより、所有していないコンテンツを所有することに対するユーザのモチベーションが低下することを防ぐことができる。

他の構成例として、情報処理システムは、グループに含まれるコンテンツがゲーム実行手段によって実行されるゲームに登場する順序を設定する登場順序設定手段をさらに備え、ゲーム実行手段は、グループに含まれるコンテンツを順序に従ってゲームに登場させて、当該コンテンツを用いたゲームを実行するようにしてもよい。

上記構成例によれば、ゲームの戦略性を高め、ひいては、ゲームの興趣性をより高めることが可能となる。

他の構成例として、ゲーム実行手段は、所定の登場条件を満たす場合に、グループに含まれるコンテンツを順序に従ってゲームに登場させてもよい。

上記構成例によれば、所定の登場条件を満たす場合に、グループに含まれるコンテンツを順序に従ってゲームに登場させることがあるため、ユーザに対し、順序を考慮してグループにコンテンツを追加させるインセンティブを与えることができる。例えば、グループ同士で対戦するゲームにおいて、ユーザは、コンテンツの登場順を考慮しながらグループ編成を行うことができる。これにより、ゲームの戦略性を高め、ひいては、ゲームの興趣性をより高めることが可能となる。

他の構成例として、ゲーム実行手段は、ゲームに登場しているコンテンツについて、ゲームから退場するための退場条件を満たしたか否かを判定し、当該退場条件を満たしたコンテンツをゲームから退場させた場合に、グループに含まれるコンテンツから所定のコンテンツを順序に従ってゲームに登場させてもよい。

上記構成例によれば、コンテンツのゲームからの退場条件を満たす場合に、グループに含まれるコンテンツを順序に従ってゲームに登場させることがあるため、ユーザに対し、順序を考慮してグループにコンテンツを追加させるインセンティブを与えることができる。例えば、グループ同士で対戦するシミュレーションゲームにおいて、ユーザ側のコンテンツが対戦相手に倒されたときに、控えのコンテンツから所定の順序に従ってコンテンツを登場させることができる。そのため、ユーザは、登場順番を考慮しながらグループ編成を行うことができ、ゲームの戦略性を高め、ひいては、ゲームの興趣性をより高めることが可能となる。

他の構成例として、情報処理システムは、ゲームに登場させるコンテンツ同士の組み合
わせに応じて、当該ゲーム上の設定を、ユーザにとって有利となるように変更するゲーム設定変更手段をさらに備えていてもよい。

上記構成例によれば、ゲームに登場させるコンテンツの組み合わせによっては、ゲーム上の設定をユーザにとって有利となるように変更するため、ユーザに対し、追加するコンテンツや、ゲームに登場する順序を考慮してグループにコンテンツを追加させるインセンティブを与えることができる。これにより、コンテンツの組み合わせを意識したグループ編成をユーザに楽しませることができ、ゲームの戦略性を高め、ひいては、ゲームの興趣性をより高めることが可能となる。

本実施形態によれば、ユーザが所有する所有コンテンツをグループに追加した後、グループに更にコンテンツを追加することが可能な場合、ユーザが所有していないコンテンツ、例えばユーザに関連付けられた他のユーザが所有するコンテンツを追加することができる。そのため、コンテンツを十分に所有していないためにグループにコンテンツを追加できないユーザに対しても、ゲームを楽しむ機会を提供することができる。

本実施形態の一例である情報処理システムの全体像を示す模式図 サーバ１０１のハードウェア構成を示すブロック図 情報処理端末１０２のハードウェア構成を示すブロック図 ゲーム画面の一例 部隊編成画面の一例 部隊編成画面の一例 部隊編成画面の一例 部隊編成画面の一例 部隊編成画面の一例 サーバ１０１のメモリ１１２に記憶されるデータの一例 ユーザデータ４０４のデータ構成の一例 ユーザ所有ユニットデータ４０７のデータ構成の一例 情報処理端末１０２のメモリ１２２に記憶されるデータの一例 ユニットマスタデータ５０２のデータ構成の一例 自軍部隊データ５０３のデータ構成の一例 本実施形態にかかるゲーム処理の詳細を示すフローチャート 部隊編成処理の詳細を示すフローチャート 部隊編成処理の詳細を示すフローチャート 部隊編成処理の詳細を示すフローチャート 部隊確定処理の詳細を示すフローチャート ＴＢＳＧ処理の詳細を示すフローチャート ＴＢＳＧ処理の詳細を示すフローチャート

以下、本発明の一実施形態について説明する。図１は、本実施形態に係る情報処理システムの全体像を示す模式図である。本実施形態の情報処理システム１００は、サーバ１０１と、複数の情報処理端末１０２とを含む。サーバ１０１と、情報処理端末１０２とは、インターネット１０３を介して通信可能に構成されている。本実施形態では、このような構成で、情報処理が実行されるが、以下では、当該情報処理の一例として、ゲーム処理を例として説明する。具体的には、情報処理端末１０２上にゲームプログラムがインストールされ、必要に応じてサーバ１０１と通信を行いながら実行されるゲーム処理を例示する。

［サーバのハードウェア構成］
次に、上記サーバ１０１のハードウェア構成について説明する。図２は、サーバ１０１のハードウェア構成を示すブロック図である。サーバ１０１は、プロセッサ部１１１と、メモリ１１２と、通信部１１３とを少なくとも備えている。プロセッサ部１１１は、サーバ１０１を制御するための各種プログラムを実行する。メモリ１１２には、プロセッサ部１１１によって実行される各種プログラムおよび利用される各種データが格納される。通信部１１３は、有線、または無線通信によってネットワークと接続し、上記情報処理端末１０２または他のサーバ（図示せず）との間で所定のデータを送受信する。

［情報処理端末のハードウェア構成］
図３は、本実施形態に係るゲーム処理が実行される情報処理端末１０２のハードウェア構成を示すブロック図である。ここで、本実施形態では、情報処理端末１０２として、例えば、スマートフォンやタブレット等のスマートデバイスや、据置型ゲーム装置や携帯型のゲーム装置や、パーソナルコンピュータ等を想定している。本実施形態の説明では、表示画面とタッチパネルを一体型の態様で備えている情報処理端末（例えばスマートフォン）を一例として説明する。そのため、主に、入力操作は、タッチパネルへの入力となっている。但し、他の実施形態では、入力操作については、情報処理端末と無線あるいは有線で接続された物理的なコントローラを用いる形態でもよいし、例えば、情報処理端末と一体となるよう構成された入力装置を用いる形態でもよい。

図３において、情報処理端末１０２は、プロセッサ部１２１と、メモリ１２２と、操作部１２３と、表示部１２４とを備えている。プロセッサ部１２１は、後述するゲーム処理を実行したり、情報処理端末１０２の全体的な動作を制御するためのシステムプログラム（図示せず）を実行したりすることで、情報処理端末１０２の動作を制御する。なお、プロセッサ部１２１は、単一のプロセッサを搭載してもよいし、複数のプロセッサを搭載するようにしてもよい。メモリ１２２は、プロセッサ部１２１によって実行される各種プログラムおよび当該プログラムで利用される各種データが格納される。メモリ１２２は、例えば、フラッシュＥＥＰＲＯＭやハードディスク装置である。操作部１２３は、ユーザからの操作を受け付けるための入力装置であり、本実施形態では、主にタッチパネルを想定する。他の実施形態では、各種ポインティングデバイスや、各種押下式のボタンや、アナログスティック等であってもよい。表示部１２４は、典型的には液晶表示装置である。

［本実施形態のゲーム処理の概要］
次に、本実施形態で実行されるゲーム処理の概要について説明する。本実施形態では、ターン制ストラテジータイプのシミュレーションゲーム（以下、ＴＢＳＧと呼ぶ）を想定している。また、本実施形態では、自軍と敵軍とが１つずつの、合計２つの軍で戦闘が行われるＴＢＳＧを想定する。また、本ＴＢＳＧでは、ユーザが所有する「ユニット」をシミュレーションゲームにおける駒として用いるものとする。なお、本実施形態において、ユーザが「所有」するユニットとは、データ上、そのユーザと関連づけられているユニットのことを指すものとする。すなわち、所定のユーザが「所有者」としてデータ的に関連づけられているユニットである。ユニットの入手方法に関しては後述する。

［ゲーム画面の構成］
図４に、本実施形態にかかるＴＢＳＧ処理のゲーム画面の一例を示す。図４において、表示部１２４に表示されるゲーム画面では、ゲームフィールドとなる「マップ」として、８×１０マスで構成されたマップ２０１が用意されている。図示は省略しているが、各マスにはそれぞれ、「平地」、「山」、「森」、「川」等の各種の地形の属性が設定されている。また、マップ上には、自軍本拠地２０２と、敵軍本拠地２０３とが配置されている。自軍本拠地２０２は、マップ２０１の下端付近に配置されており、敵軍本拠地２０３は
マップ２０１の上端付近に配置されている。また、自軍のユニットとして、マップ２０１の下端付近に、８体の自軍ユニット２０４Ａ〜２０４Ｈが配置されている（以下、総称して自軍ユニット２０４と呼ぶこともある）。なお、図面上では、自軍ユニット２０４を識別するため、各ユニットに「Ａ１」〜「Ａ８」の識別子を割り当てている。また、この図面では自軍ユニット２０４を五角形のユニットとして示しているが、実際のゲーム画面では、そのゲームの世界観などに応じた外観画像が表示される。例えば、中世ヨーロッパ風のファンタジー世界を題材にしたＴＢＳＧであれば、ユニットの画像は、歩兵、騎馬兵、弓兵、魔法使い等の各種キャラクタの外観画像が表示されてもよい。

また、敵軍のユニットとして、マップ２０１の上端付近に、８体の敵軍ユニット２０５Ａ〜２０５Ｈが配置されている（以下、総称して敵軍ユニット２０５と呼ぶこともある）。こちらも、図面上では、敵軍ユニット２０５を識別するため、「Ｅ１」〜「Ｅ８」の識別子を割り当てている。また、この図では敵軍ユニット２０５として三角形のユニットとして示しているが、こちらも実際のゲーム画面では、例えば、各種キャラクタの外観画像が表示されてもよい。

また、マップ２０１の上部には、例えばタップ操作で選択されたいずれかのユニットのステータス等のユニット詳細情報を示す詳細情報部２０８も表示される。また、マップの下部には、ゲームの進行に利用可能な各種コマンドのボタンを提示するメニュー部２０９も表示されている。例えば、自分のターンを終了するためのターン終了ボタン等がメニュー部２０９に表示される。

なお、本実施形態では、自軍、敵軍共に、それぞれ２０体のユニットを有するものとする。以下の説明では、この２０体のユニットの集合のことを「部隊」と呼ぶ。つまり、本実施形態のＴＢＳＧは、２０体のユニットで構成される「部隊」と呼ばれるグループ同士の戦いとなっている（この「部隊」の編成処理に関しては、後述する）。また、マップ２０１に同時に存在できるのは、自軍・敵軍のそれぞれで８体までとなっている。本例では、ゲーム開始時に、初期メンバーとしての８体のユニットが初期位置に配置される。そして、この初期メンバー８体のうちのいずれかが倒された場合は、例えばターンの終了時に、未配置の残りのユニット（以下、控えユニット群）の中から所定の順番（後述）で選ばれたユニットが、上記のように同時存在数８体を上限として、マップ２０１上に配置される。以下、このように控えユニット群からユニットをマップ２０１上に配置することを「ユニットの補充」と呼ぶ。また、ユニットが補充される位置については、例えば次のような優先順位で配置される。まず、最優先の配置位置として、自軍本拠地２０２上に配置される。補充数が１体だけの場合は、これで補充が終わる。補充数が２体〜５体の場合は、自軍本拠地２０２に隣接する上下左右の４マスに、例えば時計回りの順に配置される。更に、補充数が６〜８体の場合は、上下左右４マスの配置の後、自軍本拠地２０２の左上、右上、右下となるマスに配置される。

なお、本例では、部隊が「２０体」のユニットで構成され、マップ上での同時存在数は「８体」である例を挙げているが、これらの数値に限られるものではないことは言うまでもない。

ここで、本実施形態に係るＴＢＳＧにおけるユニットの入手方法について補足説明する。本ＴＢＳＧは、ファンタジー世界観のＴＢＳＧを想定する。また、ユニットについては、当該世界観における登場人物である「キャラクタ」であるものとする。また、初期状態、例えば、当該ＴＢＳＧの製品パッケージをユーザが購入した直後の状態では、ユーザは、１体も「キャラクタ」を所有していない状態であるとする。そして、本ＴＢＳＧには、「ストーリーモード」と呼ばれる、所定のシナリオを進めていくタイプのゲームモードが用意されており、ストーリーの進行に伴って、適宜そのシナリオに関連したマップを用い
てＴＢＳＧ処理が行われる。そして、このストーリーの進行に伴い、所定の「キャラクタ」、すなわちユニットをユーザの「仲間」として入手可能である。この「キャラクタ」は、例えば歩兵、魔法使い、騎兵、弓兵等の様々な種類のユニットとして用意されている。

また、「ストーリーモード」の他、「イベントモード」と呼ばれるゲームモードもある。このモードは、例えば運営が用意した所定のマップを用いるＴＢＳＧであり、これをクリアすることで、クリア報酬としての所定のユニットを入手可能である。また、その他、例えば、「運営からの配布キャラ」という態様で、所定のキャラクタがユーザ全員に配布されることでもユーザはユニットを入手可能である。更に、本ＴＢＳＧでは、いわゆる「ガチャ」と呼ばれる手段でもユニットを入手可能である。ユーザは、有料あるいは無料ガチャを行うことで、ランダムに選ばれた所定のユニットを入手可能となっている。そのため、本ＴＢＳＧをプレイしているユーザのそれぞれで、所有しているキャラクタの数やその内容が異なるものとなり得る。

なお、本実施形態で説明するＴＢＳＧは、主に、上記「イベントモード」におけるＴＢＳＧ処理を想定している。例えば、上記図４で示したようなマップが期間限定でサーバ１０１から配信され、当該期間中だけ、このマップを用いたＴＢＳＧがプレイできる、というものである。

本実施形態のＴＢＳＧは、上記のような各種の入手方法によってユーザが入手したユニットを用いて遊ぶゲームである。すなわち、ユーザは、上記「ストーリーモード」や「イベントモード」をこなしたり、「ガチャ」を行ったりすることで各種のユニットを入手する。更に、このように入手したユニットを用いて「部隊」を編成し、上記のマップ２０１に「出撃」させる。そして、各ユニットを操作して敵軍ユニットと戦闘させていくことでゲームを進行させるものである。各ユニットには、それぞれ移動範囲、ＨＰ、攻撃力、スキル（例えば魔法や技等）、レアリティ等のステータスが設定されている。また、本実施形態に係るＴＢＳＧでは、各ユニットは成長要素を有するものとして定義されている。具体的には、「レベル」の概念が定義されており、戦闘を繰り返していくことで、ユニットのレベルが上がり、レベルの上昇と共に、そのユニットのパラメータ値（各ステータスの具体的な値等）も高くなっていく。また、レベルの上昇と共に、例えば新たなスキルを取得する。そして、本実施形態のＴＢＳＧは、これらユニット同士で戦闘を行いながら、勝利条件の達成を目指すものである。なお、本実施形態では、敵軍ユニット２０５の制御は、プロセッサ部１２１が行うものとする。つまり、ＴＢＳＧをユーザ一人で遊ぶ場合を例に説明する。

本実施形態に係るＴＢＳＧでは、勝利条件として、次の２つの条件がある。
＜勝利条件１＞１０ターン以内に、敵軍本拠地を制圧すること。
＜勝利条件２＞１０ターン経過後、それまでの行動を評価して、「優勢」であると判定されること。
つまり、本実施形態のＴＢＳＧは、１０ターン経過すれば、ゲーム終了となる。そのため、１０ターンに以内に敵軍本拠地２０３を制圧できれば、その時点で「勝利」することができる。一方、１０ターン経過しても、敵軍本拠地２０３を制圧できていない場合は、それまでの行動内容や戦局が評価され、自軍が敵軍よりも「優勢」であるか「劣勢」であるかが判定される。例えば、倒した敵軍ユニット２０５の数や、倒された自軍ユニット２０４の数等を用いて判定される。

また、敗北条件としては、上記勝利条件の裏返しとなり、以下の条件となる。
＜敗北条件１＞１０ターン以内に、自軍本拠地が制圧されること。
＜敗北条件２＞１０ターン経過後、それまでの行動を評価して、「劣勢」であると判定されること。

なお、勝利・敗北の判定については、上記のものに限られない。例えば、他の実施形態では、上記、＜勝利条件１＞および＜敗北条件１＞を、１０ターン経過前におけるゲーム終了のための条件として扱い、その時点における優劣判定を行って「勝利」または「敗北」を判断するような構成としてもよい。この場合は、例えば、自軍が先に敵軍本拠地を制圧したものの、この点も含めた優劣判定の結果、「劣勢」と判定され、「敗北」となることもあり得る

なお、敵軍本拠地２０３の制圧方法として、本実施形態では、３回攻撃を加えることで、敵軍本拠地２０３を制圧できるものとする。また、このことの裏返しとして、自軍本拠地２０２が３回攻撃されると、敵軍に制圧されるものとする。

また、本実施形態のＴＢＳＧでは、ユニットの組み合わせにより有利な効果が発動する「組み合わせ効果」というギミックを備えている。例えば、「騎馬Ａ」と「騎馬Ｂ」とがマップ２０１に同時に存在している状態のときは、双方のユニット性能が通常より高くなる。また、例えば、親友や恋人という設定がなされている２つの特定のユニットが同時にマップ２０１に存在している状態のとき、これらユニットの性能が通常より高くなる、等である。そのため、どのユニットをどのような順番でマップ２０１に登場させるかという点は、ゲームの進行上重要な要素でもあり、ゲームの戦略性をより高めることにもなっている。以下に説明する部隊編成においても、ユーザに、このような登場させる順番も考慮しながら部隊編成の操作を行うという楽しみを提供することができる。

［部隊編成について］
次に、上述したような自軍の「部隊」を編成するための操作や編成画面の概要について説明する。上記のように、本実施形態のＴＢＳＧでは、２０体のユニットで構成される部隊を用いてプレイする。そのため、ユーザは、ゲームの開始前に、出撃させる部隊を編成する必要がある。そして、本実施形態では、ユーザは、そのユーザ自身が所有しているユニット（以下、ユーザ所有ユニット）を用いて部隊編成を行うことができる。更に、本実施形態では、そのユーザが所有していないユニット（以下、ユーザ非所有ユニット）をも用いた部隊編成も可能とするものである。このユーザ非所有ユニットは、ユーザの所有にかからないユニット全般のことを指す。本実施形態では、ユーザ非所有ユニットの一例として、後述する「フレンドユニット」と「自動生成分ユニット」を例に挙げて説明するが、他の実施形態では、ユーザの所有にかからないものであれば、これら以外のユニットを用いてもよい。

本実施形態では、実際のＴＢＳＧ処理が開始される前に、部隊編成画面を用いた部隊編成用の処理が実行される。図５に、部隊編成用の画面の一例を示す。図５に示す画面例では、表示部の略上半分に部隊枠画面３０１が表示され、当該部隊枠画面３０１の下に、選択用画面３０２が表示され、更にその下には、各種コマンドのボタンを表示する編成メニュー部３０３も表示される。

部隊枠画面３０１では、５列×４行の合計２０個の部隊枠３０５が表示されている。また、各部隊枠３０５の左上部分には、マップ２０１に登場する順番（以下、出撃順番）を示す１〜２０まで番号も表示されている。この画面における基本的な操作は、選択用画面に一覧表示されるユニット画像をタップすることで、部隊枠画面３０１の部隊枠３０５を、上記出撃順番に沿って順に埋めていく、という操作となる。但し、詳細は後述するが、このよう操作によらずに「自動編成」の機能を用いて編成することも可能である。以下、ユーザのタップ操作に基づく部隊編成を「手動編成」と呼び、後述する自動編成機能を用いた部隊編成を「自動編成」と呼ぶ。

次に、選択用画面３０２には、ユニット一覧表示部３０６と、自軍から編成ボタン３０７（以下、自軍編成ボタンと呼ぶ）、フレンドから編成ボタン３０８（以下、フレンド編成ボタンと呼ぶ）、並び替えボタン３０９、出撃ボタン３１０とが表示されている。ユニット一覧表示部３０６は、部隊に編成可能なユニットの画像を一覧表示するための表示領域であり、複数の枠３１１が表示されている。また、当該領域は、左端部分に配置されているスクロールバーを用いて、上下スクロールが可能となっている。このユニット一覧表示部３０６に表示される内容については、自軍編成ボタン３０７およびフレンド編成ボタン３０８を用いて切換えることが可能である。具体的には、ユーザが自軍編成ボタン３０７をタップ操作した場合は、ユニット一覧表示部３０６には、そのユーザが所有しているユニット、すなわち、上記ユーザ所有ユニットが表示される。一方、フレンド編成ボタン３０８をタップした場合は、図６に示すように、そのユーザとフレンド関係にある他のユーザが所有するユニットの一部、具体的には、下記のリーダーユニットとして設定されているユニット（以下、フレンドユニットと呼ぶ）の画像が表示される。なお、初期状態では、ユーザ所有ユニットがユニット一覧表示部３０６に表示される。また、並び替えボタン３０９がタップされた場合は、「並び替えモード」となり、ユーザは、部隊枠画面３０１においてドラッグ操作等を行うことで、ユニットの出撃順番を変更することができる。出撃ボタン３１０がタップされると、当該編成にかかる処理は終了して、上記図４で示したようなマップ２０１を用いたＴＢＳＧ処理が開始される

ここで、上記フレンドおよびリーダーユニットに関して補足説明する。本実施形態におけるＴＢＳＧでは、ユーザは、複数の他のユーザをいわゆる「フレンド」として登録することが可能である。このフレンドの情報は「フレンドリスト」として、当該ユーザに関連づけられてサーバに保存されてもよいし、情報処理端末１０２内に保存されるようにしてもよい。そして、本実施形態では、上記「部隊」を編成する際に、上記ユーザ所有ユニットだけではなく、上記フレンドユニットも部隊に編成することが可能となっている。換言すれば、ユーザは、上記ユーザ所有ユニットに加えて、ユーザと所定の関係にある他のユーザ（本実施形態ではフレンド）が所有する上記フレンドユニットをも用いて部隊を自由に編成することが可能となる。

次に、リーダーユニットについて説明する。これは、ユーザが所有するユニットの中から、「リーダー」として設定されたユニットである。ユーザは、自身が所有するユニットの中から１体だけを、リーダーとして設定することができる。そして、上記ユニット一覧表示部３０６には、このリーダーユニットとして設定されているユニットが表示される。例えば、フレンド数が５人の場合、上記図６で示したように、各フレンドがリーダーユニットとして設定しているユニットが５体分、ユニット一覧表示部３０６に表示されることになる。図６では、ユニット一覧表示部３０６の最上行の５つの枠３１１が埋められた状態で表示されている。また、各枠の下部に、そのユニットを所有するフレンド名も表示されており、どのフレンドが所有するユニットであるかが把握可能になっている。

このように、本実施形態における「部隊」には、複数のユーザ所有ユニットと複数のフレンド所有ユニットとを混在して編成することができる。これは、いわゆる「助っ人枠」や「フレンド枠」にフレンドのキャラを借りて設定する場合とは異なるものである。例えば、ある戦闘に参加させるパーティーとして、ユーザが所有するキャラクタを４体選択し、更に、フレンドのキャラクタを１体だけ選択するようなゲームも知られている。このようなゲームにおいては、フレンドのキャラクタを設定する枠と、ユーザ所有のキャラクタを設定する枠とは明確に区別されて扱われている。これに対し、本実施形態における「部隊」は、その全ての枠のそれぞれについて、ユーザ所有ユニットを設定することもでき、また、フレンドユニットを設定することもできる。例えば、フレンドが２０人以上いる場合であれば、全員フレンドユニットで構成した部隊を編成することも可能である。

［手動編成について］
次に、手動編成の流れと、これに伴う画面の一例を挙げる。ここでは、一例として、まず、ユーザ所有ユニットから２体を部隊に入れ、その後、フレンドユニットを４体、部隊に入れるという操作を例示する。まず、上記図５のように、ユーザ所有ユニットの一覧（ここでは３体だけとする）がユニット一覧表示部３０６に表示されている状態で、ユーザは、ユニット一覧表示部３０６の、一番左上の枠３１１をタップ操作する。これにより、１体目のユニットが、部隊枠画面３０１における一番左上の部隊枠３０５、すなわち、出撃順番が「１番目」の部隊枠３０５に表示される。続けて、ユーザが、先ほど選択した枠の右隣の枠３１１に表示されている２体目のユニットをタップ操作することで、当該ユニットが、出撃順番が「２番目」の部隊枠３０５に表示される。なお、ユニット一覧表示部３０６において、選択済みのユニットの枠については、選択済みであることを示すように表示態様を変化させてもよい。図７は、このようにユーザ所有ユニットから２体だけ部隊に追加した状態の画面例である。

次に、図７の状態から、ユーザは、フレンド編成ボタン３０８をタップする。これにより、図８で示すように、ユニット一覧表示部３０６には、そのユーザのフレンドのリーダーユニット、すなわち上記フレンドユニット一覧が表示される。ここではフレンドは５人であるものとする。そして、上記と同様に、部隊に編成したいフレンドユニットの枠３１１をユーザがタップすることで、タップされたフレンドユニットが順番に部隊枠画面３０１の部隊枠３０５に追加されて表示される。一例として、図９に、５体のフレンドユニットのうち、４体のフレンドユニットを更に部隊に追加した状態の画面例を示す。そのため、この時点では、部隊枠画面３０１で示される部隊には、合計６体のユニットが編成されていることになる。ユーザ所有ユニットの数やフレンドの数が十分にある場合は、上記のような操作を繰り返すことで、２０体分の部隊枠３０５を埋めることができる。そして、部隊枠３０５が全て埋まった後、ユーザは、出撃ボタン３１０をタップすることで、当該編成画面を終了し、上述したようなマップを用いたＴＢＳＧ処理を開始することができる。

なお、本実施形態では、この編成画面（および後述の自動編成）において、いわゆる「同じユニット」を２体以上部隊に追加することはできないものとする。本実施形態でいう「同じユニット」とは、ゲーム内のデータとして同じデータとなるようなものを指す。例えば、ゲームデータ上（例えば後述のユニットマスタデータ５０２）、同じＩＤ（例えば後述するユニットＩＤ５１１）が割り当てられているようなユニットのことである。つまり、部隊を構成する２０体のユニットは、それぞれが実質的に異なるユニット（異なるユニットデータに基づいたユニット）となる。上記のように、本ＴＢＳＧでは、ユニットは「キャラクタ」として設定されている。そのため、全く同じ「キャラクタ」、より正確には、全く同じキャラクタデータに基づいた「キャラクタ」を２体以上部隊に追加することはできない。例えば、「同名」のキャラクタは、２体以上追加することはできないものとする。そのため、例えば、同じユニットを部隊に追加しようとする操作を行った場合は、「同じユニットは追加できません」等の警告メッセージを提示する等で、追加できないことをユーザに提示する処理も行われる。また、その他、同じユニットを部隊に一旦は追加した状態として、画面でもそのような表示を行うが、ゲームの開始は制限されるようにしてもよい。例えば、同じユニットが２体以上部隊に存在している状態で、出撃ボタン３１０がタップされたとき、上記の警告メッセージを提示するようにしてもよい。なお、他の実施形態では、ゲームの内容に応じて、このような実質的に同じ内容となるユニットであっても、２体以上部隊に追加した状態でゲームを開始可能な構成としてもよい。

［自動編成について］
次に、上述した「自動編成」の機能に関して説明する。これは、上記部隊枠３０５にまだ空きがある状態、すなわち、２０体の部隊枠３０５の全ては埋められていない状態で、
出撃ボタン３１０がタップされた場合に実行される機能である。例えば、上記図９のように部隊枠が６体分だけ埋まっている状態で、ユーザが出撃ボタン３１０をタップしたとする。このような場合に、残り１４体分の空枠について、ユーザが所有していないユニット、すなわち、上記ユーザ非所有ユニットで埋める、という機能である。本実施形態では、ここで用いられるユーザ非所有ユニットの一例として、プロセッサ部１２１が所定の条件に基づいて自動生成するユニット（以下、自動生成分ユニットと呼ぶ）を用いるものとする。すなわち、本実施形態では、プロセッサ部１２１が自動生成分ユニットを１４体生成して、この不足分を埋める処理を行う。換言すれば、２０体の部隊枠３０５を全て埋めた状態で、ＴＢＳＧが開始されるといえる。

なお、この自動編成機能を用いることで、ユーザは、例えば、上記手動編成におけるユニットの選択人数が０人の場合であっても、ＴＢＳＧを開始することも可能である。つまり、上記図５のような部隊枠３０５が全て空欄のままで、出撃ボタン３１０をタップすることでも、当該自動編成機能によって２０体全てが自動生成分ユニットで埋められて、ＴＢＳＧが開始されることになる。

この自動生成分ユニットは、当該ＴＢＳＧのゲームデータとして予め記憶されているユニットデータ、例えば、後述するユニットマスタデータ５０２に基づいて生成される。詳細は後述するが、例えばキャラクタの基本パラメータや画像データがこのユニットマスタデータ５０２で定義されている。そして、この定義内容を基に、キャラクタに所定のレベルやスキルを設定することで、ユニットが自動生成される。そのため、当該ＴＢＳＧに登場し得るユニット全てについて、部隊への追加対象となり得ることになる。換言すれば、ユーザが所有していないユニットも部隊に追加され得ることになる。つまり、この自動編成の場合も、上記手動編成におけるフレンドユニットの利用の場合と同様に、上記ユーザ非所有ユニットを用いた部隊編成が行われ得ることとなる。また、このような自動生成分ユニットは、どのユーザにも関連づけられていないユニットであるともいえる。

但し、本実施形態では、上記のように「同じユニット」についての制限があるため、既に部隊に入っているユニットと同じユニットについては、自動生成されないような制御も行われる。なお、他の実施形態では、自動編成機能による自動生成の制御において、ユーザ所有ユニットについては全て、自動生成の対象から外れるような制御が行われても良い。また、同じユニットでも２体以上部隊に追加可能としている他の実施形態であれば、ユーザ所有ユニット／ユーザ非所有ユニットの区別無しで、単純に、ゲームデータとして予め記憶されているユニットデータの全てを自動生成の対象としてもよい。

また、上記のような自動編成機能を用いた場合、ユーザは、部隊の不足分の枠にどのようなユニットが入っているのかは把握できていない状態ともなる。すなわち、自動生成分ユニットが実際にマップ上に登場するまでは、どのようなユニットが部隊に追加されたのかユーザにはわからない。上記図９の状態でユーザが出撃ボタン３１０をタップした場合を例にすると、ゲーム開始時点では、例えば、上記図４における自軍ユニット２０４Ａ〜２０４Ｆ（「Ａ１」〜「Ａ６」のユニット）については、ユーザが手動編成したユーザ所有ユニットおよびフレンドユニットが配置される。一方、自軍ユニット２０４Ｇ〜２０４Ｈ（「Ａ７」および「Ａ８」のユニット）としては、自動生成分ユニットが配置される。つまり、ユーザにとっては、自軍ユニット２０４Ｇ〜２０４については、この時点で初めて、どのようなユニットが部隊に追加されたのかを把握可能となる。

ここで、上記ユニットの性能や成長度合い、ステータスに関しては、部隊編成の際に、ゲーム内容に応じて調整を加えるようにしても良い。例えば、上記ストーリーモードを進めることで取得した「ユニットＡ」があり、この「ユニットＡ」を用いて引き続きストーリーモードを進めた結果、「レベル１０」まで成長したとする。この状態で、上記イベン
トモードとして、上記図４で示したようなマップ２０１を用いたＴＢＳＧを行う場合を想定する。そして、この際に、「ユニットＡ」を上記部隊に加えたとする。この場合に、イベントの内容やＴＢＳＧの難易度等に応じて、「ユニットＡ」のレベルを一時的に変更するようにしてもよい。例えば、本実施形態では、当該マップ２０１を用いたＴＢＳＧを行う間だけ、レベルを最大の状態に変更する。すなわち、レベルを最大の状態にして、部隊に加えるようにしている。また、このような変更は、ユーザ所有ユニットだけに限らず、上記フレンドユニットや、自動生成分ユニットに対しても行われる。すなわち、フレンドユニットを上記部隊に加える場合、そのレベルを最大の状態として部隊に加える処理が行われる。また、自動生成分ユニットの場合は、自動生成する際に、レベルが最大の状態となるように自動生成する。これにより、例えば難度の高いゲームにおいて、自動生成分ユニットとして「弱い」ユニットが自動的に生成されてしまうことで、ゲームの進行が困難となり、ユーザを十分に楽しませることができなくなってしまうという状況を回避することが可能となる。

もちろん、他の実施形態では、このような調整として、レベルを最大にすることに限らない。実行されるＴＢＳＧの難易度等に応じて、例えば一律にレベル１の状態としてもよい。また、例えば、フレンドユニットや自動生成分ユニットについては、ユーザ所有ユニット、すなわち、ユーザ自身で育てたユニットよりも少し弱い性能となるように調整してもよい。また、例えば、ユーザ所有ユニットに関しては、このようなレベル等の調整は行わないようにしてもよい。この場合は、ユーザ所有ユニットに関しては、今まで使っていた状態のまま利用できるため、自分の所有ユニットについては使い慣れた状態でのプレイを可能とする。また、ユーザ所有ユニットおよびフレンドユニットの双方について、このようなレベル等の調整は行わないようにしてもよい。つまり、ユーザ・フレンドがそれぞれ育てたユニットについては、その育てた状態のままでプレイできるようにしてもよい。

このように、本実施形態のＴＢＳＧでは、ユーザが所有しているユニットとは異なるユニットを用いた部隊編成が可能となっている。これにより、例えば上記のような２０体のユニットで構成される部隊を用いたＴＢＳＧを提供する際に、ユーザが所有するユニットが少ない場合であっても、フレンドユニットや自動生成ユニットを用いることで、当該ＴＢＳＧをプレイさせることを可能とする。

例えば、上記「手動編成」の場合は、ユーザ所有ユニットと、ユーザ非所有ユニットも含む場合があるフレンドユニットをユーザの操作に基づいて部隊に加えることができる。これにより、自身が使い慣れたユーザ所有ユニットを用いた部隊も編成でき、かつ、フレンドユニットについても、ユーザ自身でユニットの性能等を把握しながらの部隊編成が可能となる点で有利である。特に、本実施形態にＴＢＳＧでは、上述したような「組み合わせ効果」があるため、意図的に「組み合わせ効果」を発動させるという観点から、どのユニットをどの順番で登場させるかという点でも戦略性が高くなっている。そのため、各ユニットを把握しながら手動で部隊編成できる点で有利である。また、多くのフレンドを作ることで、より多くのフレンドユニットも利用可能となるため、ユーザのフレンド作成へのモチベーションを高めることも可能となる。

また、「自動編成」の場合は、上記のようにユーザが所有するユニット数やフレンド数が少ないような場合でも、ＴＢＳＧを楽しませることができる点で有利である。また、本実施形態では、部隊については２０体の枠を全て埋めなければＴＢＳＧを開始することができないところ、部隊編成にかかる手間を省くことができるという点でも有利である。例えば、ユーザ所有キャラは２０体以上有しているが、手動編成の手間を避けたいと考えるユーザは、敢えて部隊枠３０５を全て空欄のままにして「出撃」することでも、ＴＢＳＧを開始することができる。このように、手動編成の手間を省いて、手軽にＴＢＳＧを始めたいユーザに対して、その利便性を高める点でも有利である。また、上記自動編成を用い
て「出撃」した場合は、ユーザは、自軍のユニットがどのような内容であるかを把握しないままプレイを開始することになる。これにより、例えば、ユーザが意図的に部隊を全て空枠のまま「出撃」できるようにすることで、自分の部隊の内容が分からないまま戦わせるというような、緊張感のあるプレイをユーザに楽しませることも可能である。

また、上記のようなフレンドユニットや自動生成分ユニットを利用できることは、ユーザが、ユーザ非所有ユニットを「試用」できることでもある。これにより、自身が所有していないユニットの性能等を体験してもらい、このようなユーザ非所有ユニットを獲得することへのモチベーションを高め、ひいてはゲームの興趣性を高めることも可能となる。

なお、「手動編成」では、ユーザと所定の関係にある他のユーザ、ここでは「フレンド」の所有するユニットを利用可能な例を示した。他の実施形態では、いわゆる「フレンド」関係、すなわち、相互に認証しあっている関係にある他のユーザに限らず、例えば、ユーザが一方的にフォローしている他のユーザや、逆に、ユーザが一方的にフォローされている場合の他のユーザが所有しているユニットも利用可能な構成としても良い。また、その他、例えば、「トップランカー」や「トッププレイヤー」等と呼ばれるような、所定の条件を満たした一部の特定のユーザが所有するユニットについても利用可能な構成としても良い。

また、上記の一方的にフォローしている／されている関係のユーザの所有ユニットや、「トップランカー」等の所有ユニットについては、「自動編成」において利用可能としてもよい。すなわち、自動編成機能によって追加されるユーザ非所有ユニットとして、これらのユーザの所有ユニットを所定の条件で選択して追加するような構成としてもよい。

また、「手動編成」に際しては、上記のようなフレンドユニットやフレンドではない特定のユーザの所有ユニットに限らず、何らかのユーザ非所有ユニットをユーザに提示し、選択可能なようにしてもよい。例えば、特段ユーザとはフレンド関係等ではない、直近１時間以内にログインした他のユーザのリーダーキャラをユニット一覧表示部３０６に一覧表示して、複数のリーダーキャラを部隊に追加可能なようにしてもよい。この場合、そのときに表示された他のユーザのリーダーキャラが、たまたま全て「弱い」ユニットであった場合でも、これらを部隊に編成して出撃ボタン３１０をタップすることで、ゲームを開始することは可能である。

［本実施形態のゲーム処理の詳細］
次に、図１０〜図２２を参照して、本実施形態におけるＴＢＳＧ処理についてより詳細に説明する。

［使用データについて］
まず、本ＴＢＳＧ処理にて用いられる各種データに関して説明する。まず、サーバ１０１で用いられるデータに関して説明する。図１０は、サーバ１０１のメモリ１１２に記憶される各種データの一例を示すメモリマップである。サーバ１０１のメモリ１１２には、サーバ側プログラム４０１、ユーザデータベース４０２、自動生成条件データ４０３等が記憶されている。

サーバ側プログラム４０１は、本実施形態におけるＴＢＳＧに関する処理を実行するためのプログラムである。例えば、ユーザのログイン処理や、ユーザデータベース４０２に含まれる所定のユーザデータを情報処理端末１０２に送信あるいは受信する処理や、ＴＢＳＧに必要な各種データを適宜情報処理端末１０２に送信するための処理を実行するためのプログラムである。

ユーザデータベース４０２は、ＴＢＳＧをプレイする各ユーザに関するデータの集合となるデータベースである。本実施形態では、ユーザデータベース４０２は、図１１で示されるようなユーザデータ４０４を１レコードとして構成されたデータベースである。情報処理端末１０２では、ログイン処理が行われた後、そのユーザに対応したユーザデータ４０４をサーバ１０１から取得する処理等が行われる。

図１１を用いて、ユーザデータ４０４のデータ構成について説明する。図１１で示すユーザデータ４０４には、ユーザＩＤ４０５、プロフィール情報４０６、ユーザ所有ユニットデータ４０７、フレンドデータ４０８、進行状況データ４０９等で構成されている。ユーザＩＤ４０５は、各ユーザを一意に識別するためのＩＤである。プロフィール情報４０６には、ログイン処理に必要な各種情報や、各ユーザのハンドルネーム等のユーザ個々に関する情報が含まれる。

ユーザ所有ユニットデータ４０７は、そのユーザが所有しているユニットを示すデータである。図１２は、ユーザ所有ユニットデータ４０７のデータ構成の一例を示す図である。ユーザ所有ユニットデータ４０７は、所有番号４１１、ユニットＩＤ４１２、現在Ｌｖ４１３、装備スキル４１４、リーダーフラグ４１５等の項目を有するテーブル形式のデータである。所有番号４１１は、ユーザ所有ユニットを一意に識別するための番号である。例えば、ユニットの入手順に割り当てられる番号である。ユニットＩＤ４１２は、後述するユニットマスタデータ５０２におけるユニットＩＤ５１１と対応するものである。現在Ｌｖ４１３は、そのユニットの現在のレベルを示すデータである。装備スキル４１４は、そのユニットが現在有しているスキルを示すデータである。リーダーフラグ４１５は、そのユニットが、上記リーダーユニットとして設定されているか否かを示すためのデータである。また、ここに示したデータの他、例えは、各ユニットの入手日を示すデータ等もユーザ所有ユニットデータ４０７には含まれる。

図１１に戻り、フレンドデータ４０８は、そのユーザが「フレンド」として登録している他のユーザを示すためのデータである。いわゆる「フレンドリスト」のデータである。

進行状況データ４０９は、そのユーザのゲームの進行状況を示すためのデータである。例えば、ストーリーモードでどこまで進んでいるか等を示すデータである、このデータに基づいて、ユーザは、前回中断したゲームを、その続きから再開することが可能となる。

次に、情報処理端末１０２のメモリに記憶される各種データについて説明する。図１３は、情報処理端末１０２のメモリ１２２に記憶される各種データの一例を示すメモリマップである。情報処理端末１０２のメモリ１２２には、端末側ゲームプログラム５０１、ユニットマスタデータ５０２、自軍部隊データ５０３、敵軍部隊データ５０４、操作データ５０５、編成モード５０６、マップデータ５０７等が記憶されている。

端末側ゲームプログラム５０１は、本実施形態に係るゲーム処理を実行するためのプログラムである。すなわち、上述したような部隊編成のための処理や、上記図４で示したようなマップ２０１を用いたＴＢＳＧ処理を実行するためのプログラムである。

ユニットマスタデータ５０２は、本ＴＢＳＧに登場する全てのユニットについて定義したデータベースである。なお、当該データは、サーバ１０１から送信される更新データに基づいて適宜更新可能とし、更新の度に、新たなユニットのデータが追加されてもよい。図１４に、ユニットマスタデータ５０２のデータ構造の一例を示す。図１４において、ユニットマスタデータ５０２は、ユニットＩＤ５１１、画像音声データ５１２、初期パラメータ５１３、各レベルでのパラメータ定義データ５１４、組み合わせ効果定義データ５１５等の項目を有するテーブル形式のデータとなっている。

ユニットＩＤ５１１は、そのユニットを識別するためのＩＤである。画像音声データ５１２は、そのユニットの外観画像のデータや、例えばユニットがキャラクタである場合は、そのキャラクタボイスのデータである。初期パラメータ５１３は、そのユニットの初期状態（例えばレベル１のとき）における能力値を定義したデータである。各レベルでのパラメータ定義データ５１４は、各ユニットの成長度合いについて定義したデータであり、レベル毎の能力値を定義したデータである。組み合わせ効果定義データ５１５は、上述したような「組み合わせ効果」の発動条件等を定義したデータである。

上述した自動編成機能による自動生成処理では、当該ユニットマスタデータ５０２に基づいて、所定のユニットが生成されることになる。例えば、ランダムでいずれかのユニットＩＤ５１１が選択され、各レベルでのパラメータ定義データ５１４が参照されることでレベルが最大の状態のときの能力値が設定されたユニットのデータが生成されて、後述の自軍部隊データ５０３に追加されることになる。

図１３に戻り、自軍部隊データ５０３は、上述した自軍の部隊を示すためのデータである。上述した「手動編成」操作や、「自動編成」機能によって生成されるものである。図１５に、自軍部隊データ５０３のデータ構造の一例を示す。自軍部隊データ５０３は、出撃順番５２１、ユニットデータ５２２の項目を有するテーブル形式のデータであり、合計２０ユニット分のレコードが用意されている。出撃順番５２１は、上述したような出撃順番を示すデータであり、かつ、自軍部隊の各ユニットを識別するための番号でもある。ユニットデータ５２２は、自軍部隊の各ユニットを示すためのデータである。例えば、ユーザ所有ユニット、あるいはフレンドユニットが部隊に追加された場合は、その追加されたユニットのユニットＩＤ５１１やそのレベルを示す情報が当該ユニットデータ５２２として設定される。また、自動生成分ユニットの場合は、自動生成されたユニットのユニットＩＤ５１１やレベル等を示す情報が設定される。

図１３に戻り、敵軍部隊データ５０４は、敵軍部隊を示すためのデータである。そのデータ構成は、基本的には、上記自軍部隊データ５０３と同じであるものとする。但し、その内容については、プロセッサ部１２１が２０体全てのユニット分のデータを自動生成するものとする。

操作データ５０５は、操作部１５に対して行われた各種操作内容を示すデータである。本実施形態では、操作部１５としてのタッチパネルへの入力の有無、そのタッチ座標等を示すデータや、図示しない各種ボタンの押下状態等を示すデータが含まれている。

編成モード５０６は、後述する部隊編成処理において用いられるデータであり、現在の操作モードが「並び替えモード」であるか否かを示すためのデータである。

マップデータ５０７は、上述したマップ２０１の構成を定義したデータである。例えば、サーバ１０１から配信されたデータを記憶したものである。

その他、メモリ１２２には、例えばサーバ１０１から取得したユーザデータ４０４が一時的に格納される。また、本処理で用いられる各種の作業用データ等も適宜格納される。

［プロセッサ部１２１が実行する処理の詳細］
次に、図１６〜図２２のフローチャートを参照して、本実施形態にかかるゲーム処理の詳細を説明する。なお、ここでは、主に情報処理端末１０２における処理を説明する。サーバ１０１における処理については、必要に応じて適宜説明を加える。また、主に上述した部隊編成に関する処理および、上記マップ２０１を用いたＴＢＳＧ処理について説明し
、その他のゲーム処理については、説明を割愛する。また、この処理に先立って、ユーザデータ４０４がサーバ１０１から取得され、メモリ１２２に格納されている状態であるとする。

図１６は、本実施形態におけるゲーム処理の全体像を示すフローチャートである。まず、ステップＳ１において、部隊編成処理が実行され、その後、ステップＳ２で、当該処理で生成された部隊を用いるＴＢＳＧ処理が実行される。

図１７は、部隊編成処理の詳細を示すフローチャートである。まず、ステップＳ１１で、部隊編成用の初期の画面を表示するための処理が行われる。具体的には、プロセッサ部１２１は、サーバ１０１から取得してメモリ１２２に格納されているユーザデータ４０４のユーザ所有ユニットデータ４０７を参照して、ユーザが所有するユニットを特定する。更に、ユニットマスタデータ５０２を参照して、ユーザ所有ユニットの画像を含むユーザ所有ユニットの一覧を生成する。そして、当該ユーザ所有ユニット一覧を選択用画面３０２に表示する処理を行う。また、自軍部隊データ５０３を初期化する処理も行われる。

続いて、ステップＳ１２で、プロセッサ部１２１は、編成モード５０６に「追加」を示すデータを設定する。

次に、ステップＳ１３で、プロセッサ部１２１は、編成モード５０６が「追加」であるか否かを判定する。「追加」ではないときは（ステップＳ１３でＮＯ）、「並び替えモード」であるため、後述するステップＳ２６の処理に進められる。一方、「追加」であるときは（ステップＳ１３でＹＥＳ）、ステップＳ１４で、プロセッサ部１２１は、操作データ５０５を取得する。次に、ステップＳ１５で、プロセッサ部１２１は、操作データ５０５で示されるユーザの操作の内容が、上記自軍編成ボタン３０７をタップした操作であるか否かを判定する。当該判定の結果、自軍編成ボタン３０７のタップ操作が行われていた場合は（ステップＳ１５でＹＥＳ）、ステップＳ１６で、プロセッサ部１２１は、ユーザ所有ユニットの一覧を生成し、選択用画面３０２に表示する処理を実行する。その後、上記ステップＳ１３に戻り、処理を繰り返す。

一方、ステップＳ１５の判定の結果、自軍編成ボタン３０７のタップ操作が行われていなかった場合は（ステップＳ１５でＮＯ）、次に、ステップＳ１７で、プロセッサ部１２１は、操作データ５０５で示されるユーザの操作の内容が、上記フレンド編成ボタン３０８をタップした操作であるか否かを判定する。当該判定の結果、フレンド編成ボタン３０８のタップ操作が行われていた場合は（ステップＳ１７でＹＥＳ）、プロセッサ部１２１は、選択用画面３０２にフレンドユニット一覧を表示するための処理を実行する。具体的には、まず、ステップＳ１８で、プロセッサ部１２１は、サーバ１０１と協働して、次のような処理を行う。まず、サーバ１０１において、フレンドデータ４０８を参照して、そのユーザのフレンドが特定する処理が実行される。次に、サーバ１０１において、ユーザデータベース４０２から、特定されたフレンドそれぞれのユーザ所有ユニットデータ４０７を参照し、リーダーフラグ４１５がオンに設定されているユニット、すなわち、リーダーユニットのデータが取得される。そして、各フレンドのリーダーユニットを示す一覧データが、サーバ１０１から情報処理端末１０２に送信される。プロセッサ部１２１は、当該送信されてきたデータに基づいて、フレンドユニットの一覧を生成する。その後、ステップＳ１９で、プロセッサ部１２１は、当該フレンドユニット一覧を選択用画面３０２に表示する処理を実行する。その後、上記ステップＳ１３に戻り、処理を繰り返す。

一方、ステップＳ１７の判定の結果、フレンド編成ボタン３０８のタップ操作が行われていなかった場合は（ステップＳ１７でＮＯ）、次に、図１８のステップＳ２０で、プロセッサ部１２１は、操作データ５０５で示されるユーザの操作の内容が、並び替えボタン
３０９のタップ操作であるか否かを判定する。当該判定の結果、並び替えボタン３０９のタップ操作である場合は（ステップＳ２０でＹＥＳ）、ステップＳ２１で、プロセッサ部１２１は、編成モード５０６に「並び替え」を示すデータを設定する。その後、上記ステップＳ１３に戻り、処理を繰り返す。

一方、ステップＳ２０の判定の結果、並び替えボタン３０９のタップ操作が行われていなかった場合は（ステップＳ２０でＮＯ）、次に、ステップＳ２２で、プロセッサ部１２１は、操作データ５０５で示されるユーザの操作の内容が、部隊へのユニットの追加の操作であるか否かを判定する。具体的には、選択用画面３０２においてユニットが表示されている枠３１１のいずれかをタップする操作が行われたか否かを判定する。当該判定の結果、ユニットの追加操作である場合は（ステップＳ２２でＹＥＳ）、ステップＳ２３で、プロセッサ部１２１は、操作内容に基づいて、選択用画面３０２からタップされたユニットに対応するユニットを示すデータを、自軍部隊データ５０３に順番に追加する処理を行う。選択用画面３０２にユーザ所有ユニット一覧が表示されていた場合は、タップにより選択されたユーザ所有ユニットが自軍部隊データ５０３に追加されることになる。また、選択用画面３０２にフレンドユニット一覧が表示されていた場合は、タップにより選択されたフレンドユニットが自軍部隊データ５０３に追加されることになる。また、プロセッサ部１２１は、この追加の際に、上述したようなレベルの調整処理も行う、本実施形態では、ユーザ所有ユニットおよびフレンドユニットの実際の育成状況に関わらず、レベルを最大の状態に変更したうえで、部隊に追加する処理が行われる。また、操作内容が、上述した「同じ」ユニットを部隊に追加する操作に該当する場合は、「追加できない」旨のメッセージを表示し、当該追加にかかる操作をキャンセルする処理も実行される。そして、プロセッサ部１２１は、最新の自軍部隊データ５０３に基づいて、部隊枠画面３０１の表示内容を更新する処理を行う。その後、上記ステップＳ１３に戻り、処理を繰り返す。

一方、ステップＳ２２の判定の結果、自軍部隊へのユニット追加の操作が行われていなかった場合は（ステップＳ２２でＮＯ）、次に、ステップＳ２４で、プロセッサ部１２１は、操作データ５０５で示されるユーザの操作の内容が、出撃ボタン３１０のタップ操作であるか否かを判定する。当該判定の結果、出撃ボタン３１０のタップ操作ではない場合は（ステップＳ２４でＮＯ）、上記ステップＳ１３に戻り、処理を繰り返す。一方、出撃ボタン３１０のタップ操作であった場合は（ステップＳ２４でＹＥＳ）、ステップＳ２５で、プロセッサ部１２１は、部隊確定処理を実行する。

なお、本実施形態においては、上記ステップＳ２４までの処理における、ユーザが所有する所有コンテンツ（ユーザ所有ユニット）から当該ユーザの操作に基づいて選択されたコンテンツをグループ（部隊）に追加する処理は、第１の追加処理と言える。一方、上記フレンドユニットからの追加は、いわば、当該ユーザが所有しない非所有コンテンツの中から所定のコンテンツを当該グループに追加する第２の追加処理と言えるものである。また、次に説明するステップＳ２５にかかる処理についても、第２の追加処理と言えるものである。

図２０は、部隊確定処理の詳細を示すフローチャートである。まず、ステップＳ４１で、プロセッサ部１２１は、自軍部隊データ５０３を参照し、まだユニットが追加されていない枠（以下、空枠）の数を確認する処理を実行する。

次に、ステップＳ４２で、プロセッサ部１２１は、空枠数が０であるか否かを判定する、その結果、０ではない場合は（ステップＳ４２でＮＯ）、空枠について自動生成分ユニットを追加するための処理を実行する。具体的には、ステップＳ４３で、プロセッサ部１２１は、ユニットマスタデータ５０２を参照して、ランダムでいずれか一つのユニットデータを選択する。この際、既に自軍部隊に追加済みのユニットを同じユニットＩＤとなる
データは選択しないように制御される。

次に、ステップＳ４４で、プロセッサ部１２１は、所定条件に基づいて、上記ステップＳ４３で選択されたユニットのレベルを決定する処理を実行する。例えば、プロセッサ部１２１は、サーバ１０１から自動生成条件データ４０３を取得してメモリ１２２に格納する。そして、当該自動生成条件データ４０３を参照し、当該データで定義されている条件に基づいて上記レベルを決定する。本実施形態では、所定条件として、最大レベルにするという条件が定義されているものとする。また、その他、自動生成条件データ４０３での定義内容に基づき、例えば、そのユニットが備えるスキル内容等も適宜決定する処理も行われる。そして、プロセッサ部１２１は、これら決定した内容を反映した自動生成分ユニットを生成する。

次に、ステップＳ４５で、プロセッサ部１２１は、上記生成した自動生成分ユニットを示すデータを、自軍部隊データ５０３に順番に追加する処理を実行する。０１３０その後、上記ステップＳ４１に戻り、処理を繰り返す。

一方、上記ステップＳ４２の判定の結果、空枠数が０であるときは（ステップＳ４２でＹＥＳ）、自軍部隊に２０体のユニットが追加された状態であるため、次に、ステップＳ４６で、プロセッサ部１２１は、敵軍部隊の生成処理を行う。すなわち、敵軍部隊データ５０４に、２０体分のユニットデータを設定する処理を実行する。基本的には、上記自動生成分ユニットの生成の場合と同じ処理で、敵軍部隊データ５０４に２０体分のユニットデータを追加する処理が行われる。当該処理が終了すれば、部隊確定処理は終了する。

図１８に戻り、部隊確定処理が終了すれば、部隊編成処理は終了する。

一方、図１７の上記ステップＳ１３の判定の結果、編成モード５０６が「追加」ではないときは（ステップＳ１３でＮＯ）、図１９のステップＳ２６で、プロセッサ部１２１は、操作データ５０５を取得する。次に、ステップＳ２７で、プロセッサ部１２１は、操作データ５０５で示されるユーザの操作の内容が、並び替えモードを終了することを示す操作であるか否かを判定する。例えば、並び替えモード中に、「並び替え終了」ボタンを表示するようにしておき、このボタンがタップされた場合に、並び替えモードを終了することを示す操作が行われたと判定する。当該判定の結果、並び替えモードの終了操作が行われていない場合は（ステップＳ２７でＮＯ）、ステップＳ２８で、プロセッサ部１２１は、操作データ５０５で示される操作内容に基づき、自軍部隊データ５０３における各ユニットの順番を変更する処理、および、その変更内容に基づく画面の更新処理を実行する。その後、上記ステップＳ２６に戻り、処理を繰り返す。一方、並び替えモードの終了操作が行われていた場合は（ステップＳ２７でＹＥＳ）、ステップＳ２９で、プロセッサ部１２１は、編成モード５０６に「追加」を設定する。その後、上記ステップＳ１３に戻り、処理を繰り返す。

以上で、部隊編成処理の説明を終了する。

次に、部隊編成処理に続いて実行されるＴＢＳＧ処理の詳細を説明する。なお、当該ＴＢＳＧ処理では、自軍のターンから開始する。図２１は、上記ステップＳ２にかかるＴＢＳＧ処理の詳細を示すフローチャートである。まず、ステップＳ６１で、プロセッサ部１２１は、準備処理を実行する。具体的には、以下のような処理がプロセッサ部１２１によって実行される。まず、マップデータ５０７に基づいて、当該ＴＢＳＧ処理で用いるマップ２０１を生成し、仮想ゲーム空間に配置する処理が実行される。更に、自軍部隊データ５０３を読み込み、出撃順番が１番目〜８番目のユニットデータに基づいて、８体の自軍ユニットをマップ２０１上の所定の位置に配置する処理が実行される。更に、敵軍部隊デ
ータ５０４を取得して、同様に、出撃順番が１番目〜８番目となる８体の敵軍ユニットをマップ２０１上の所定の位置に配置する処理も実行される。そして、上記図４で示したようなゲーム画面を生成し、表示部１２４に表示する処理が実行される。

次に、ステップＳ６２で、プロセッサ部１２１は、操作データ５０５を取得する。次に、ステップＳ６３で、プロセッサ部１２１は、操作データで示される操作内容に基づくいずれかの自軍ユニットの制御処理を実行する。更に、その制御を反映したゲーム画面の表示処理を実行する。例えば、自軍ユニットの移動、敵軍ユニットや敵軍本拠地２０３への攻撃、各種スキルの使用、等の制御が行われる。また、その他、上述した「組み合わせ効果」の発動条件が満たされているか否かの判定と、満たされている場合はその組み合わせ効果を発動する処理も実行される、また、敵軍ユニットを攻撃した結果、例えば反撃を受けて自軍ユニットが撃破された場合は、その自軍ユニットをマップ上から消去したり、関連する「組み合わせ効果」を消去したりする制御も実行される。

次に、ステップＳ６４で、プロセッサ部１２１は、ユーザが敵軍本拠地２０３を制圧したか否かを判定する。当該判定の結果、制圧している場合は（ステップＳ６４でＹＥＳ）、後述するステップＳ７３の処理に進められる。一方、まだ制圧していない場合は（ステップＳ６４でＮＯ）、次に、ステップＳ６５で、自軍のターンが終了したか否かを判定する。例えば、「ターン終了」ボタンがタップされたか否かが判定される。また、マップ上の全ての自軍ユニットが行動終了していた場合も、自軍のターンが終了したものとして判定される。当該判定の結果、まだ自軍ターンが終了していない場合は（ステップＳ６５でＮＯ）、上記ステップＳ６２に戻り、処理が繰り返される。

一方、自軍ターンが終了した場合は（ステップＳ６５でＹＥＳ）、次に、敵軍のターンにかかる処理が実行される。まず、ステップＳ６６で、プロセッサ部１２１は、マップ上に存在するいずれかの敵軍ユニットの行動制御を行う。すなわち、敵軍ユニットの移動、自軍ユニットや自軍本拠地２０２への攻撃等の行動の制御が実行される。また、自軍ユニットが攻撃された結果、自軍ユニットが撃破された場合は、上記と同様に、その自軍ユニットをマップ上から消去したり、関連する「組み合わせ効果」を消去したりする制御も実行される。更に、プロセッサ部１２１は、上記制御の結果を反映したゲーム画面の表示処理も行う。

次に、ステップＳ６７で、プロセッサ部１２１は、自軍本拠地２０２が敵軍部隊に制圧されたか否かを判定する。その結果、制圧されていた場合は（ステップＳ６７でＹＥＳ）、後述のステップＳ７４に処理が進められる。まだ制圧されていないときは（ステップＳ６７でＮＯ）、ステップＳ６８で、プロセッサ部１２１は、敵軍のターンが終了したか否かを判定する。すなわち、マップ上に存在する全ての敵軍ユニットについて、上記のような制御を行ったか否かを判定する。その結果、敵軍ターンが終了していない場合は（ステップＳ６８でＮＯ）、上記ステップＳ６６に戻り、敵軍ターンにかかる処理が繰り返される。

一方、敵軍ターンが終了した場合は（ステップＳ６８でＹＥＳ）、次に、ステップＳ６９で、プロセッサ部１２１は、１０ターンが経過したか否かを判定する。その結果、まだ１０ターンが経過していない場合は（ステップＳ６９でＮＯ）、ステップＳ７０で、プロセッサ部１２１は、ユニット補充処理を実行する。すなわち、今回のターンにおいて撃破されたユニットがある場合に、撃破された数に応じて、控えユニットから出撃順番に沿ってユニットを補充する処理が実行される。この処理は、自軍、敵軍の双方について実行される。その後、ターンを１ターン進めて、上記ステップＳ６２に戻り、処理が繰り返される。

一方、上記ステップＳ６９の判定の結果、１０ターンが経過している場合は（ステップＳ６９でＹＥＳ）、図２２のステップＳ７１で、プロセッサ部１２１は、自軍が優勢であるか否かを判定するための優劣判定処理を実行する。すなわち、１０ターン経過しているが、自軍・敵軍いずれの本拠地も制圧されていないため、判定による決着をつけるための処理が行われる。具体的には、お互いのユニットの撃破数や、お互いの本拠地への攻撃回数等を比較する処理が行われ、例えば、敵軍ユニットを撃破した数が、自軍ユニットの撃破された数より多い場合は、自軍が優勢であると判定される。逆に、自軍ユニットが撃破された数の方が多い場合は、自軍が劣勢であると判定される。

上記判定の結果、自軍が優勢であると判定された場合は（ステップＳ７２でＹＥＳ）、ステップＳ７３で、プロセッサ部１２１は、勝利時の処理を実行する。例えば、勝利演出を表示したり、所定の報酬を示すデータをユーザデータ４０４に追加したりする処理等が実行される。一方、自軍が優勢ではない、すなわち劣勢であると判定された場合は（ステップＳ７２でＮＯ）、ステップＳ７４で、プロセッサ部１２１は、敗北時の処理を実行する。例えば、勝利演出を表示する処理等が実行される。以上で、ＴＢＳＧ処理は終了する。

このように、本実施形態では、例えば２０体のユニットで構成される部隊同士を戦わせるようなＴＢＳＧにおいて、上記フレンドユニットや自動生成分ユニットを用いることで、ユーザ自身が所有しているユニットだけではなく、ユーザが所有していないユニットをも用いた部隊編成が可能である。これにより、ユーザ自身が所有しているユニット数が少ない状態、例えば、ゲームを遊び始めたばかりで、まだユニットが十分に集まっていない状態のユーザに対しても、このような部隊同士を戦わせるＴＢＳＧをプレイしてもらうことが可能となる。

［変形例］
なお、上記実施形態では、２０体のユニットで構成される「部隊」同士を戦わせるＴＢＳＧを例に挙げた。すなわち、ユニットという「コンテンツ」を複数含んでいる、「グループ」同士を戦わせるようなゲームを例に挙げた。このようなゲームの他、例えば、カードゲームにおける「デッキ」の編成の場合でも、上述したような処理は適用可能である。この場合は、グループとしての「デッキ」にコンテンツとしての「カード」を追加することになるが、この際に、ユーザ自身が所有するカードの他、フレンドが所有するカードを複数枚用いて、自身のデッキを構成できるようにすればよい。もちろん、上記自動編成機能によりカードデータを自動生成し、デッキに加えるようにしてもよい。また、その他、スポーツゲーム等における「チーム」の編成についても、上述したような処理を適用し、ユーザ自身が所有している「選手」だけでなく、所有していない「選手」を用いてのチーム編成が可能なようにしてもよい。また、その他、例えば、３ＤのＦＰＳ（ファーストパーソンシューティング）やＴＰＳ（サードパーソンシューティング）において、チーム単位で対戦するようなゲームにおいても適用可能である。例えば、ユーザが操作する１体のユーザキャラクタと、プロセッサ部１２１により自動的に制御される複数体の味方キャラクタで構成されるチーム対戦型のＦＰＳを想定する、この場合に、味方キャラクタとして、上記ガチャ等でユーザが入手したキャラクタの他、上記フレンドユニットに相当するキャラクタや自動生成分ユニットに相当するキャラクタを用いてチームが編成できるようにしてもよい。

また、上記グループを用いるゲーム処理について、上記のＴＢＳＧやカードゲーム、スポーツゲームのようなグループ同士を戦わせるゲームに限るものでもなく、グループを用いて所定のミッションをクリアするようなゲームに対しても、本実施形態の処理は適用可能である。例えば、リズムゲームであって、複数のキャラクタで構成されるグループ（例えば仮想的なアイドルグループ等）を用いて所定の楽曲の演奏に挑戦するようなゲームに
ついても適用可能である。この場合、グループに編成するキャラクタについて、自身が所有するキャラクタだけでなく、フレンド等が有するキャラクタを、グループに複数編成できるようにすればよい。

また、上記コンテンツに関しては、上記のユニット、キャラクタやカード等の他、例えば、「国家」、「戦艦」、「兵器」、「武器」、「乗り物」等であってもよい。

また、部隊の編成に関しては、いわゆるコスト制を利用してもよい。例えば、上記ユニットにそれぞれコストを設定しておき、部隊の上限コスト値を予め定めておく。そして、当該コストの範囲内で編成するようにしてもよい。例えば、１５体のユニットを追加した時点で、コストが上限となった場合は、ユニット数が１５体である部隊として出撃可能なようにしてもよい。

また、上記では、自動編成機能で用いられるユーザ非所有ユニットの例として、ユニットマスタデータ５０２に基づいて生成される自動生成分ユニットの例を示した。この他、ユーザ非所有ユニットは、以下のようなものであってもよい。例えば、成長要素のないユニットを用いるゲームの場合、上記のようなユニットマスタデータ５０２から単純にランダム選択されたユニットであってもよい。また、例えば、サーバ１０１に予め記憶されている所定のユニットデータ（ユニットマスタデータ５０２に含まれていないユニットであってもよい）を取得して、これに基づいて生成したユニットであってもよい。すなわち、サーバ１０１からユニットをレンタルするような構成でもよい。また、以前に使用されたフレンドユニットを「使用履歴」として情報処理端末１０２に記憶させておき、この履歴の中からランダムで選択されたユニットであってもよい。また、その他、ユーザ非所有ユニットとして、例えば、名前や外観が設定されている「キャラクタ」を固定的に追加し、各追加キャラクタの能力値等は、当該追加の際にランダムな能力値を生成するようにしてもよい。

また、上記自動生成の処理に関して、部隊に編成するユニットの条件をより細かく条件付けしてもよい。例えば、上記マップの内容に応じて、攻撃力に優れたユニットを優先的に部隊に編成したり（攻撃力重視）、防御力に優れたユニットを優先的に部隊に編成したり（防御力重視）する制御を行ってもよい。また、男性キャラクタのみ、あるいは、女性キャラクタのみを自動生成するような制御を行っても良い。その他、例えば、そのマップに合わせて運営が予め用意したユニットを編成するような制御を行ってもよい。これらの条件については、上記自動生成条件データ４０３で定義するように構成すればよい。

また、上記フレンドユニットや自動生成分ユニットに関して、他の実施形態では、ユーザが所有済みのユニットと重複しないユニットだけを、フレンドユニットとして一覧表示したり、自動生成分ユニットとして生成したりするようにしてもよい。上記の例では、例えばユーザとフレンドとの双方が所有しているユニットであって、ユーザが自分で部隊に手動追加していない場合であれば、フレンドユニットとして当該ユニットを部隊に追加できる。この点について、他の実施形態では、例えばフレンドユニット一覧には、ユーザが所有済みのユニットと重複しないユニットだけが表示されるような構成としてもよい。また、自動生成分ユニットについても、ユーザが所有済みのユニットと重複しないユニットのみを対象として自動生成されるようにしてもよい。

また、他の実施形態では、フレンドユニットを対象とした自動選択を可能なようにしてもよい。例えば、「フレンドからの自動編成」ボタンを提示し、これがタップ等された場合は、部隊に追加するユニットをフレンドユニット一覧から、例えばランダムで選択して部隊に追加するようにしてもよい。

また、上述したユニットの「補充」について、上記の例では、ターン終了時に、そのターンで撃破されたユニット数分が出撃順に沿って補充される例を示した。この他、補充を行うトリガとしては、例えば敵軍ユニットを倒したことをトリガとしてもよいし、スコアが一定以上になったことをトリガとしてもよい。また、撃破されたユニット数が一定数以上になったことをトリガとしてもよい。

また、上記自動編成機能において、一律にレベルを最大にして部隊に追加する例を挙げた。この他、例えば、出撃順番に応じてレベルを調整してもよい。例えば、出撃順番が後になるユニットほど、レベルが高くなるように設定したり、逆に、出撃順番が後になるユニットほど、レベルが低くなるように設定したりしてもよい。前者の場合、ゲームに不慣れなユーザでも、ゲームクリアさせやすくすることができる。逆に後者の場合は、ユニットが撃破されていくほど戦況が厳しくなっていくため、できるだけ当初のユニットが撃破されないような立ち回りが要求され、（例えば上級者向けに）緊張感の高いゲームを提供できる。いずれの場合も、ゲームの興趣性を高めることが可能となる。

また、上記実施形態では、部隊枠３０５に空枠がある状態で「出撃」すると、自動編成が行われ、そのままＴＢＳＧが開始される例を示した。つまり、実際にマップ上に登場するまで、自動生成分ユニットについてはユーザが把握できない例を示した。他の実施形態では、ＴＢＳＧが開始される前に、自動生成分ユニットで埋められた部隊の内容をユーザに提示するような構成としてもよい。例えば、部隊枠３０５に空枠がある状態で出撃ボタン３１０がタップされた場合、上述の自動編成にかかる処理を実行した後、自動生成分ユニットで埋められた部隊の内容を部隊枠画面３０１に表示するようにしてもよい。更に、「この部隊で出撃しますか？」等の問い合わせをユーザに行うようにしてもよい。そして、ユーザの了承が得られなかった場合は、再度自動編成にかかる処理が実行可能なように構成してもよい。これにより、手動編成にかかる手間を省きつつ、ユーザが部隊の内容を把握した状態で「出撃」させることができ、ユーザの利便性を高めることができる。

また、上記のような処理を実行する主体に関しても、上記のような構成に限らない。例えば、上記情報処理システムにおいて、サーバ側のシステムは、複数の情報処理装置によって構成され、サーバ側で実行するべき処理を複数の情報処理装置が分担して実行してもよい。また、例えば、上記端末側ゲームプログラム５０１および操作データ５０５以外のデータについてもサーバ１０１に記憶させておき、必要に応じて情報処理端末１０２がサーバ１０１にアクセスして当該データを参照するような構成としてもよい。この場合、例えば、情報処理端末１０２は、ユーザの操作を示す操作データ５０５をサーバ１０１に送り、サーバにおいて各種ゲーム処理を実行し、その実行結果を情報処理端末１０２が受け取り、当該実行結果を反映したゲーム画面を生成して表示するような構成としてもよい。

また、例えば、フレンドに関するデータの送受信処理のみサーバ１０１と行い、それ以外の処理は情報処理端末１０２だけで実行するような構成でもよい。この場合、各人のユーザデータ４０４を各情報処理端末１０２に記憶させておき、フレンドユニットの情報の取得に関する処理のみサーバ１０１を利用するような構成とすればよい。また、例えば、登録したフレンドのユーザデータについても情報処理端末１０２に記憶させておき、サーバ１０１を用いないような構成でもよい。この場合は、例えば、情報処理端末１０２同士で直接的にお互いのユーザデータ４０４を交換して、情報処理端末１０２内に記憶させておけば良い。

１０１ サーバ
１０２ 情報処理端末
１１１ プロセッサ部
１１２ メモリ
１１３ 通信部
１２１ プロセッサ部
１２２ メモリ
１２３ 操作部
１２４ 表示部

Claims (25)

1. ユーザが所有する所有コンテンツから、当該ユーザの操作に基づいて選択されたコンテンツをグループに追加する第１追加手段と、
   前記第１追加手段による追加の結果、さらに前記グループにコンテンツを追加することが可能な場合、前記ユーザが所有しない非所有コンテンツの中から所定のコンテンツを当該グループに追加する第２追加手段と、
   前記グループに含まれるコンテンツを用いたゲームを実行するゲーム実行手段とを備える、情報処理システム。
2. 前記第２追加手段は、前記ユーザの操作の後、前記グループにコンテンツを追加することが可能な場合、前記非所有コンテンツの中から追加可能な分の前記所定のコンテンツを当該グループに追加する、請求項１に記載の情報処理システム。
3. 前記第２追加手段は、前記ユーザの操作の後、前記グループにコンテンツを追加することが可能な場合、所定の規則に従って、前記非所有コンテンツの中から前記所定のコンテンツを自動で当該グループに追加する、請求項１または２に記載の情報処理システム。
4. 前記第２追加手段は、前記ユーザの操作の後、前記グループにコンテンツを追加することが可能な場合、前記非所有コンテンツの中からランダムに選択したコンテンツを自動で当該グループに追加する、請求項３に記載の情報処理システム。
5. 前記第２追加手段は、前記第１追加手段による追加の結果、さらに前記グループにコンテンツを追加することが可能な場合、前記非所有コンテンツの中から前記所定のコンテンツを生成して当該グループに追加する、請求項１乃至４のいずれかに記載の情報処理システム。
6. 前記第２追加手段は、前記第１追加手段による追加の結果、さらに前記グループにコンテンツを追加することが可能な場合、所定の設定に基づいて前記非所有コンテンツの中から前記所定のコンテンツを生成し、生成した当該所定のコンテンツを当該グループに追加する、請求項５に記載の情報処理システム。
7. 前記第２追加手段は、前記第１追加手段による追加の結果、さらに前記グループにコンテンツを追加することが可能な場合、前記ゲーム実行手段が実行する前記ゲームに応じた設定に基づいて前記非所有コンテンツの中から前記所定のコンテンツを生成し、生成した当該所定のコンテンツを当該グループに追加する、請求項５に記載の情報処理システム。
8. 前記第１追加手段は、ユーザが所有する前記所有コンテンツから当該ユーザの操作に基づいて選択されたコンテンツを、前記グループに追加する前の状態のまま当該グループに追加する、請求項７に記載の情報処理システム。
9. 前記第２追加手段は、前記第１追加手段による追加の結果、さらに前記グループにコンテンツを追加することが可能な場合、他のユーザが所有する非所有コンテンツの中から前記所定のコンテンツを当該グループに追加する、請求項１乃至８のいずれかに記載の情報処理システム。
10. 前記第２追加手段は、前記第１追加手段による追加の結果、さらに前記グループにコンテンツを追加することが可能な場合、前記ユーザと関連づけられた他のユーザが所有する前記非所有コンテンツの中から前記所定のコンテンツを当該グループに追加する、請求項９に記載の情報処理システム。
11. 前記第２追加手段は、前記第１追加手段による追加の結果、さらに前記グループにコンテンツを追加することが可能な場合、前記ユーザと関連づけられた、複数の他のユーザが各々所有する複数の前記非所有コンテンツの中から前記所定のコンテンツを当該グループに追加する、請求項１０に記載の情報処理システム。
12. 前記情報処理システムは、前記第２追加手段によって前記グループに追加された前記所定のコンテンツの前記ゲームに関する設定を変更したうえで前記ゲーム実行手段が実行するゲームにおいて登場させる、コンテンツ設定変更手段をさらに備える、請求項１乃至１１のいずれかに記載の情報処理システム。
13. 前記第２追加手段は、前記第１追加手段によるコンテンツの追加が完了した後、前記ゲーム処理の実行開始前に、前記非所有コンテンツの中から前記所定のコンテンツを当該グループに追加する、請求項１乃至１２のいずれかに記載の情報処理システム。
14. 前記第２追加手段は、前記第１追加手段によるコンテンツの追加の結果、さらに前記グループにコンテンツを追加することが可能な場合、前記非所有コンテンツの中から前記所定のコンテンツを当該グループに追加し、当該追加後のグループに含まれるコンテンツを、前記ゲーム実行手段によるゲームの実行開始前に当該ユーザに提示する、請求項１乃至１２のいずれかに記載の情報処理システム。
15. 前記第１追加手段は、前記ユーザが所有する前記所有コンテンツおよび前記非所有コンテンツの中から、当該ユーザの操作に基づいて選択されたコンテンツを前記グループに追加する、請求項１乃至１４のいずれかに記載の情報処理システム。
16. 前記第１追加手段は、前記ユーザが所有する前記所有コンテンツ、および、当該ユーザに関連付けられた前記他のユーザが所有する前記非所有コンテンツの中から、当該ユーザの操作に基づいて選択されたコンテンツを前記グループに追加する、請求項１乃至１４のいずれかに記載の情報処理システム。
17. 前記第１追加手段は、前記ユーザが所有する前記所有コンテンツ、および、当該ユーザに関連付けられた複数の前記他のユーザの各々が所有する複数の前記非所有コンテンツの中から、当該ユーザの操作に基づいて選択された少なくとも２のコンテンツを前記グループに追加する、請求項１６に記載の情報処理システム。
18. 前記ゲーム実行手段は、前記グループに含まれる第１コンテンツに関連するパラメータと、当該グループに含まれる当該コンテンツとは異なる第２コンテンツに関連するパラメータとが重複する場合、当該ゲーム実行手段によるゲームの開始を制限する、請求項１乃至１７のいずれかに記載の情報処理システム。
19. 前記情報処理システムは、前記グループに含まれるコンテンツが前記ゲーム実行手段によって実行されるゲームに登場する順序を設定する登場順序設定手段をさらに備え、
    前記ゲーム実行手段は、前記グループに含まれるコンテンツを前記順序に従ってゲームに登場させて、当該コンテンツを用いたゲームを実行する、請求項１乃至１８のいずれかに記載の情報処理システム。
20. 前記ゲーム実行手段は、所定の登場条件を満たす場合に、前記グループに含まれるコンテンツを前記順序に従ってゲームに登場させる、請求項１９に記載の情報処理システム。
21. 前記ゲーム実行手段は、前記ゲームに登場しているコンテンツについて、ゲームから退
    場するための退場条件を満たしたか否かを判定し、当該退場条件を満たしたコンテンツをゲームから退場させた場合に、前記グループに含まれるコンテンツから前記所定のコンテンツを前記順序に従ってゲームに登場させる、請求項１９または２０に記載の情報処理システム。
22. 前記情報処理システムは、前記ゲームに登場させるコンテンツ同士の組み合わせに応じて、当該ゲーム上の設定を、前記ユーザにとって有利となるように変更するゲーム設定変更手段をさらに備える、請求項１９乃至２１のいずれかに記載の情報処理システム。
23. 情報処理システムのコンピュータに実行させる情報処理プログラムであって、
    前記コンピュータを、
    ユーザが所有する所有コンテンツから、当該ユーザの操作に基づいて選択されたコンテンツをグループに追加する第１追加手段と、
    前記第１追加手段による追加の結果、さらに前記グループにコンテンツを追加することが可能な場合、前記ユーザが所有しない非所有コンテンツの中から、所定のコンテンツを当該グループに追加する第２追加手段と、
    前記グループに含まれるコンテンツを用いたゲームを実行するゲーム実行手段として機能させる、情報処理プログラム。
24. 情報処理システムを制御するコンピュータが実行する情報処理方法であって、
    前記コンピュータに、
    ユーザが所有する所有コンテンツから、当該ユーザの操作に基づいて選択されたコンテンツをグループに追加する第１追加ステップと、
    前記第１追加ステップによる追加の結果、さらに前記グループにコンテンツを追加することが可能な場合、前記ユーザが所有しない非所有コンテンツの中から、所定のコンテンツを当該グループに追加する第２追加ステップと、
    前記グループに含まれるコンテンツを用いたゲームを実行するゲーム実行ステップとを実行させる、情報処理方法。
25. ユーザが所有する所有コンテンツから、当該ユーザの操作に基づいて選択されたコンテンツをグループに追加する第１追加手段と、
    前記第１追加手段による追加の結果、さらに前記グループにコンテンツを追加することが可能な場合、前記所有コンテンツとは異なる前記ユーザが所有しない非所有コンテンツの中から、所定のコンテンツを当該グループに追加する第２追加手段と、
    前記グループに含まれるコンテンツを用いたゲームを実行するゲーム実行手段とを備える、情報処理装置。

Images