JP7430032B2 - コンピュータシステム、ゲームシステムおよび制御方法 - Google Patents

Description

本発明は、ゲームの実行を制御するコンピュータシステム等に関する。

ビデオゲームにユーザを惹き付ける魅力の１つが、ゲーム世界でのアイテムの扱いである。特にアイテムの「開発」や「合成」、「生成」と呼ばれる仕組みは、ゲームのやり込み要素の１つであり、ゲームを制作・開発する上では特に力が注がれる。

アイテムの開発や合成、生成（以下総称して「開発」という。）は、時間の経過や素材アイテムの消費、仮想通貨の消費などを対価にして、新たな種類のアイテムを使用可能にする仕組みである。

例えば、『プレーヤが所有する「鉄の剣」をベースアイテムとし、「雷魔法石」を素材アイテムとして合成開始操作や開発開始操作入力をすると、「鉄の剣」から新たな「雷撃の剣」を生成する』といったものがこれに該当する。また例えば、『「鉄」の素材アイテムと、「Ｉ型戦車」の設計図アイテムとに基づく開発開始操作入力をすると、「開発時間」と称する時間経過を対価として新たな「ＩＩ型戦車」を開発する。』といったものもこれに該当する。

特許文献１には、素材アイテムに、プレーヤが保有していた時間に応じて変化する品質パラメータ値を設定することで、合成によって生成されるアイテムに変化をつける技術が開示されている。

特開２０１７－０１２４２２号公報

従来の開発の仕組みは、プレーヤ個々が楽しむゲームプレイ要素であった。複数人のプレーヤが参加可能なマルチプレイゲームであったとしても、開発の仕組みは各プレーヤが個人的に独立して行うものであって、プレーヤ別に行っている開発が相互に影響を及ぼすことは無かった。

本発明が解決しようとする課題は、マルチプレイゲームにおいて、アイテムの開発に新たな興趣を付加する技術を提供すること、である。

上記した課題を解決するための第１の発明は、各プレーヤがアイテムの開発、合成、又は生成（以下総称して「開発」という。）と開発したアイテムを用いたゲームプレイとを楽しむことができる複数のプレーヤが参加可能なゲームの実行を制御するコンピュータシステムであって、
第１のプレーヤによる第１の開発目的アイテムの設定を行う第１の開発目的アイテム設定手段（例えば、図１０のサーバ処理部２００ｓ、ゲーム管理部２１０、開発管理部２１１、第１開発目的アイテム設定部２１２、図１６の開発管理データ７４０、開発目的アイテム種類７４４、図２０のステップＳ５２）と、
前記第１のプレーヤのゲームプレイに基づいて前記第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に前記第１の開発目的アイテムを開発完了として前記第１のプレーヤの所有アイテムとする第１の開発遂行手段（例えば、図１０のサーバ処理部２００ｓ、ゲーム管理部２１０、開発管理部２１１、第１開発遂行部２１４、図１９のステップＳ１１０～ステップＳ１１４）と、
第２のプレーヤによる第２の開発目的アイテムの設定を行う第２の開発目的アイテム設定手段（例えば、図１０のサーバ処理部２００ｓ、ゲーム管理部２１０、開発管理部２１１、第２開発目的アイテム設定部２１６、図１６の開発管理データ７４０、開発目的アイテム種類７４４、図２０のステップＳ５２）と、
前記第２のプレーヤのゲームプレイに基づいて前記第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に前記第２の開発目的アイテムを開発完了として前記第２のプレーヤの所有アイテムとする第２の開発遂行手段（例えば、図１０のサーバ処理部２００ｓ、ゲーム管理部２１０、開発管理部２１１、第２開発遂行部２１８、図１９のステップＳ１１０～ステップＳ１１４）と、
前記第１の開発目的アイテムと前記第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、前記第１の開発遂行条件および前記第２の開発遂行条件を変更する開発遂行条件変更手段（例えば、図１０のサーバ処理部２００ｓ、ゲーム管理部２１０、開発管理部２１１、開発遂行条件変更部２２２、図２０のステップＳ５４～ステップＳ６０）と、を備えたコンピュータシステムである。

ここで言う「コンピュータシステム」とは、単数のコンピュータは勿論、複数のコンピュータが連携して構成されるものでもよい。
また、ここで言う「開発」とは、プレーヤに時間の経過や素材アイテムなどの消費を対価にして、新たなアイテムを使用可能にするゲームルール上の仕組みである。

第１の発明によれば、第１のプレーヤと、第２のプレーヤとが参加するマルチプレイゲームにおいて、各プレーヤは、各々が開発目的アイテムの種類を指定した上で開発を開始し、当該開発に設定された所与の開発遂行条件が満たされると（開発の対価の支払が完了したことに相当する状態になると）、開発目的アイテムをゲームで利用できるようになる。第１のプレーヤの開発目的アイテムと、第２のプレーヤの開発目的アイテムとで、所与のアイテム共通条件を満たす場合に、それぞれの開発遂行条件を変更することができる。つまり、マルチプレイゲームにおいて、アイテムの開発について新たな興趣を付加する技術を実現することが可能となる。

第２の発明は、前記第１の開発遂行条件および前記第２の開発遂行条件には、開発目的アイテムが設定されてから開発完了するまでの時間長条件（例えば、図１２の初期時間長条件５２６ａ、図１６の適用時間長条件７４５ａ）が少なくとも含まれ、前記開発遂行条件変更手段は、前記時間長条件を変更する、第１の発明のコンピュータシステムである。

第２の発明によれば、プレーヤ別の開発行為が相互に及ぼす影響として、開発遂行・開発完了までの時間を変更することができる。

第３の発明は、前記第１の開発遂行条件および前記第２の開発遂行条件には、開発進捗に応じて必要となるリソースの条件である必要リソース条件（例えば、図１２の初期必要リソース条件５２６ｂ、図１６の適用必要リソース条件７４５ｂ）が少なくとも含まれ、前記開発遂行条件変更手段は、前記必要リソース条件を変更する、第１又は第２の発明のコンピュータシステムである。

第３の発明によれば、プレーヤ別の開発行為が相互に及ぼす影響として、開発進捗に応じて必要となる資材や費用といったリソースに係る条件を変更することができる。

第４の発明は、前記第１の開発遂行条件および前記第２の開発遂行条件には、開発目的アイテムの開発が成功する確率に関する開発成功確率条件が少なくとも含まれ、前記開発遂行条件変更手段は、前記開発成功確率条件を変更する、第１～第３の何れかの発明のコンピュータシステムである。

第４の発明によれば、開発が必ずしも成功するとは限らず、ある程度の失敗する可能性を含んだアイテムの開発の仕組みとすることができる。不確定要素を適度に組み込むことで、ゲームの興趣を高めることができる。

第５の発明は、前記ゲームは、各プレーヤが複数の勢力の何れかに所属するゲームであり（例えば、図１４の所属勢力種類６１１）、前記勢力には、開発目的アイテムとすることができる勢力別の開発候補が複数関連付けられており（例えば、図１１の初期開発候補管理データ５４２）、前記第１の開発目的アイテム設定手段は、前記第１のプレーヤが所属する勢力の前記開発候補の中から前記第１の開発目的アイテムを設定し、前記第２の開発目的アイテム設定手段は、前記第２のプレーヤが所属する勢力の前記開発候補の中から前記第２の開発目的アイテムを設定する、第１～第４の何れかの発明のコンピュータシステムである。

第５の発明によれば、プレーヤ各々が勢力別に開発候補が関連づけられているため、アイテム共通条件が満たされることに適当な難易度を設定することが可能になり、ゲームの興趣をより高めることができる。

第６の発明は、前記ゲームが、各プレーヤが複数の勢力の何れかに所属するゲームであり、前記第１のプレーヤと前記第２のプレーヤとが、同じ勢力に所属するプレーヤである、第１～第５の何れかの発明のコンピュータシステムである。

また、第７の発明は、前記ゲームが、各プレーヤが複数の勢力の何れかに所属するゲームであり、前記開発遂行条件変更手段は、前記第１のプレーヤが所属する勢力と前記第２のプレーヤが所属する勢力とが同じ場合にのみ、前記第１の開発遂行条件および前記第２の開発遂行条件の変更内容を可変に制御する、第１～第５の何れかの発明のコンピュータシステムである。

第６または第７の発明によれば、同じ勢力の仲間同士で協力してアイテムの開発をすると、開発においてメリットが得られるシチュエーションを作り出すことができる。

第８の発明は、前記ゲームが、各プレーヤが複数の勢力の何れかに所属するゲームであり、前記開発遂行条件変更手段が、前記第１のプレーヤが所属する勢力と前記第２のプレーヤが所属する勢力との勢力関係に基づいて、前記第１の開発遂行条件および前記第２の開発遂行条件の変更内容を可変に制御する、第１～第５の何れかの発明のコンピュータシステムである。

ここで言う「勢力関係」とは、同盟関係、敵対関係、中立関係、兄弟関係、親戚関係、親子関係、主従関係、などである。

第８の発明によれば、第１のプレーヤが所属する勢力と第２のプレーヤが所属する勢力との勢力関係に基づいて、開発遂行条件を変更することができる。

第９の発明は、前記開発遂行条件変更手段が、前記第１のプレーヤと前記第２のプレーヤとの関係性に基づいて、前記第１の開発遂行条件および前記第２の開発遂行条件の変更内容を可変に制御する、第１～第５の何れかの発明のコンピュータシステムである。

第９の発明によれば、プレーヤ間の関係性を開発遂行条件を変更する要素とすることで、アイテムの開発の仕組みの興趣性を向上させることができる。

第１０の発明は、前記第１のプレーヤのゲームプレイに基づく前記第１の開発遂行条件を緩和するための所与の条件緩和条件を満たす場合に、前記第１の開発遂行条件を緩和する第１の条件緩和手段（例えば、図１０のサーバ処理部２００ｓ、ゲーム管理部２１０、第１条件緩和部２２０、図１８のステップＳ９４～ステップＳ９６）、を更に備え、
前記開発遂行条件変更手段が、前記アイテム共通条件を満たす場合に、前記第１の条件緩和手段による前記第１の開発遂行条件の緩和に応じて、前記第２の開発遂行条件を緩和する条件変更波及手段（例えば、図１０の条件変更波及部２２４、図１９のステップＳ９８）を有する、第１～第９の何れかの発明のコンピュータシステムである。

第１０の発明によれば、第１のプレーヤが条件緩和条件を満たしたならば、その影響が、アイテム共通条件を満たしている第２のプレーヤの第２の開発遂行条件の緩和として現れるようになる。つまり、共通性のあるアイテムを開発するプレーヤ同士で、相互に協力関係のようなメリットを享受できるようになる。

第１１の発明は、前記条件変更波及手段が、前記第１のプレーヤのパラメータ値と前記第２のプレーヤのパラメータ値との差に基づいて、前記第２の開発遂行条件を緩和する程度を変更する第１０の発明のコンピュータシステムである。

第１１の発明によれば、第１のプレーヤが条件緩和条件を満たした影響が、第２の開発遂行条件の緩和として現れる程度を、第１のプレーヤのパラメータ値と第２のプレーヤのパラメータ値との差に応じて異なるものとすることができる。

プレーヤのパタメータ値は、例えばプレーヤレベルなどとすれば、第１のプレーヤと第２のプレーヤとの技量差に応じて第２の開発遂行条件を緩和する程度を増減できる。例えば、第１のプレーヤを上級者と仮定し、第２のプレーヤが上級者である場合と初心者である場合との２パターンを想定する。第２のプレーヤが上級者である場合の緩和の程度よりも、初心者である場合の緩和の程度の方を大きくすれば、上級者が初心者を補助する作用効果が副次的にあらわれるような仕組みとなる。

第１２の発明は、前記開発遂行条件変更手段が、前記第１のプレーヤおよび前記第２のプレーヤ以外に、前記アイテム共通条件を満たすアイテムを開発目的アイテムとしているプレーヤの人数に基づいて、前記第１の開発遂行条件および前記第２の開発遂行条件を変更する、第１～第１１の何れかの発明のコンピュータシステムである。

第１２の発明によれば、アイテム共通条件を満たすアイテムを開発目的アイテムとしているプレーヤの人数に基づいて、開発遂行条件を変更することができる。

第１３の発明は、前記第１の開発目的アイテムと前記第２の開発目的アイテムとが前記アイテム共通条件を満たす場合に、前記第１の開発目的アイテムの開発完了時に所与の特典を前記第１のプレーヤに付与する特典付与手段（例えば、図１０のサーバ処理部２００ｓ、ゲーム管理部２１０、特典付与部２２８、図１１の特典定義データ５６２、図１９のステップＳ１１６～ステップＳ１１８）、を更に備えた第１～第１２の何れかの発明のコンピュータシステムである。

また、第１４の発明は、前記特典付与手段が、前記第１の開発目的アイテムのパラメータ値を向上させること、及び／又は、前記第１の開発目的アイテムに所与の能力を付加すること、を前記特典として前記第１のプレーヤに付与する、第１３の発明のコンピュータシステムである。

第１３、または第１４の発明によれば、アイテム共通条件を満たすような開発の仕方を推奨するような仕組みを実現できる。

第１５の発明は、複数のユーザ端末と、前記ユーザ端末と通信可能な第１～第１４の何れかの発明のコンピュータシステムであるサーバシステムと、を具備したゲームシステムである。

第１５の発明によれば、第１～第１４の何れかの発明と同様の効果が得られるゲームシステムを実現できる。

ゲームシステムの構成例を示す図。 ユーザ端末の構成例を示す正面図。 ゲームの概要について説明するための図。 プレーヤキャラクタの構成と開発について説明するための図。 複数のプレーヤの開発目的アイテムの関係性に基づく開発遂行条件について説明するための図。 軽減率の例を説明するための図。 開発設定画面の表示例を示す図。 承認画面の表示例を示す図。 開発遂行条件の変更の波及について説明するための図。 サーバシステムの機能構成例を示す機能ブロック図。 サーバ記憶部が記憶するプログラムやデータの例を示す図。 開発候補アイテム定義データのデータ構成例を示す図。 開発遂行条件変更パターン定義データのデータ構成例を示す図。 ユーザ管理データのデータ構成例を示す図。 プレイデータのデータ構成例を示す図。 開発管理データのデータ構成例を示す図。 ユーザ端末の機能構成の一例を示す機能ブロック図。 サーバシステムにおける１つのゲームプレイに係る処理の流れを説明するためのフローチャート。 図１８より続くフローチャート。 開発設定処理の流れを説明するためのフローチャート。

以下、本発明の実施形態の一例を説明するが、本発明を適用可能な形態が以下の実施形態に限られないことは勿論である。

図１は、ゲームシステムの構成例を示す図である。ゲームシステム１０００は、ネットワーク９を介して相互にデータ通信が可能に接続されたサーバシステム１１００と、ユーザ端末１５００（１５００ａ，１５００ｂ，…）とを含み、プレーヤ２（２ａ，２ｂ，…）が各々のユーザ端末１５００でゲームをプレイするコンピュータシステムである。なお、プレーヤは、コンピュータが制御する架空のプレーヤであってもよい。

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

サーバシステム１１００は、例えば、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを有し、本体装置には制御基板１１５０を搭載する。

制御基板１１５０には、ＣＰＵ（Central Processing Unit）１１５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１１５２、通信装置１１５３が搭載されている。なお、制御基板１１５０の一部又は全部は、ＡＳＩＣ（Application Specific Integrated Circuit）や、ＦＰＧＡ（Field-Programmable Gate Array）、ＳｏＣ（System on a Chip）により実現するとしてもよい。

そして、サーバシステム１１００は、制御基板１１５０が所定のプログラムおよびデータに基づいて演算処理することにより、ユーザ端末１５００（１５００ａ，１５００ｂ，…）にてゲームを実行可能にする。具体的には、ユーザ端末１５００にて実行可能なプログラムやデータを配信する。

なお、サーバシステム１１００を、１台のサーバ装置であるかのように描いているが、複数の装置で実現する構成であってもよい。例えば、サーバシステム１１００は各機能を分担する複数のブレードサーバを搭載して相互に内部バスを介してデータ通信可能に接続した構成であっても良い。また、サーバシステム１１００を構成するハードウェアの設置場所は問わない。離れた場所に設置された独立した複数のサーバを、ネットワーク９を介してデータ通信させることで、全体としてサーバシステム１１００として機能させる構成であっても良い。

ユーザ端末１５００（１５００ａ，１５００ｂ，…）は、登録ユーザであるプレーヤ２（２ａ，２ｂ，…）が、本実施形態のゲームをプレイするために使用するコンピュータであって、ネットワーク９を介してサーバシステム１１００にアクセスできる電子装置（電子機器）である。本実施形態のユーザ端末１５００は、いわゆるスマートフォンと呼ばれる装置であるが、手持ち可能な携帯型のコンピュータであれば、携帯型ゲーム装置や、タブレット型コンピュータ、などでもよい。

図２は、本実施形態におけるユーザ端末１５００の構成例を示す正面図である。
ユーザ端末１５００は、方向入力キー１５０２と、ボタンスイッチ１５０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１５０６と、スピーカ１５１０と、内蔵バッテリー１５０９と、マイク１５１２と、カメラ１５２０と、制御基板１５５０と、コンピュータ読み出し可能な記憶媒体であるメモリカード１５４０からデータを読み書きできるメモリカード読取装置１５４２と、を備える。その他、図示されていない電源ボタン、音量調節ボタン等が設けられている。また、システム利用対価の支払いが可能なＩＣカード型のクレジットカードやプリペイドカードに対して非接触にデータの読み書きが行えるＩＣカード読取装置などを設けるとしてもよい。

制御基板１５５０は、ＣＰＵ１５５１やＧＰＵ，ＤＳＰなどの各種マイクロプロセッサ、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１５５２、ネットワーク９に接続する携帯電話基地局や無線ＬＡＮ基地局などと無線通信するための無線通信モジュール１５５３、インターフェース回路１５５７、などを搭載する。

インターフェース回路１５５７には、タッチパネル１５０６のドライバ回路、方向入力キー１５０２およびボタンスイッチ１５０４からの信号を受信する回路、スピーカ１５１０へ音声信号を出力する出力アンプ回路、マイク１５１２で集音した音声の信号を生成する入力信号生成回路、メモリカード読取装置１５４２への信号入出力回路、などが含まれている。

制御基板１５５０に搭載されているこれらの要素は、バス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。なお、制御基板１５５０の一部又は全部をＡＳＩＣやＦＰＧＡ、ＳｏＣにて構成してもよい。そして、制御基板１５５０は、ユーザ端末としての機能を実現させるためのプログラムや各種データをＩＣメモリ１５５２に記憶する。

なお、本実施形態では、ユーザ端末１５００はプログラムや各種設定データをサーバシステム１１００からダウンロードする構成としているが、別途入手したメモリカード１５４０などの記憶媒体から読み出す構成としても良い。

図３は、本実施形態のゲームの概要について説明するための図である。
本実施形態のゲームは、各プレーヤ２（２ａ，２ｂ，…）が複数の勢力の何れかに所属して対戦するチーム対戦型マルチプレイゲームである。図３の例では、勢力は「ＲＥＤ」と「ＢＬＵＥ」の２つとしているが、３以上の勢力が同時に存在するゲームであってもよい。勿論、プレーヤ２の人数や、１勢力あたりのプレーヤ数は適宜設定可能である。

各プレーヤ２（２ａ，２ｂ，…）は、それぞれ単数又は複数のプレーヤキャラクタ４（４ａａ，４ａｂ，…）を操作して対戦する。

図４は、プレーヤキャラクタ４の構成と開発について説明するための図である。プレーヤキャラクタ４は、装備変更可能なロボット兵器という設定である。プレーヤ２は、ゲームプレイが開始されると任意のタイミングでプレーヤキャラクタ４の追加を行うことができる。その際、プレーヤ２は、機体ベース４１に、所有アイテムの中から、攻撃アイテム４２、防護アイテム４３、移動アイテム４４、をそれぞれ選択してプレーヤキャラクタ４をカスタマイズして設定することができる。

そして、攻撃アイテム４２と、防護アイテム４３と、移動アイテム４４は、ゲーム内での兵器開発行為に相当する「開発」の対象とされる。

プレーヤ２は、任意のタイミングで「開発」を設定・開始することができる。本実施形態の「開発」は、勢力別に管理されている開発候補アイテムの中から、開発目的アイテムを指定し、当該開発目的アイテムに設定されている開発遂行条件が満たされると、プレーヤ２は当該開発目的アイテムを利用可能になる。本実施形態では、開発完了すると、開発目的アイテムを少なくとも１つ、プレーヤ２に付与し所有させる。
なお、開発完了した開発目的アイテムは、同じ勢力内で共通利用できるようにしてもよい。例えば、同じ勢力内のプレーヤ２同士であれば、開発完了したアイテムを、所与の対価を支払うことでプレーヤキャラクタ４のカスタマイズに利用できるようにしてもよい。

「開発遂行条件」は、１）プレーヤ２が所有する素材アイテムの消費やゲーム内通貨の消費、開発場所の占有、といった必要リソースに関する条件、２）時間経過、３）撃墜数や所定イベントのクリアなどゲーム進行状況についての条件、４）電子決済媒体による支払、の少なくとも１つ又は複数の組み合わせで記述される。

開発候補アイテムは、攻撃・防護・移動のカテゴリー別に能力違いで種類用意されている。また、開発候補アイテムには、系譜が設定されており、同じ系譜における下位の開発候補アイテムが開発完了済、或いはプレーヤ２の所属勢力において利用可能に設定さている場合に、それより上位の開発候補アイテムを開発目的アイテムとして設定することができる。

図４の例では、防護アイテム４３（４３ａ，４３ｂ，…）として、能力順にレベル「１」の防護アイテム４３ａ、レベル「２」の防護アイテム４３ｂ、…がゲームの設定上用意されているものとする。ゲーム開始当初は、レベル「１」の防護アイテム４３ａのみが開発完了されており利用可能に設定されている。これより能力が高いレベル「２」の防護アイテム４３ｂは、「開発」することで利用可能になる。更に能力が高いレベル「３」の防護アイテム４３ｃは、防護アイテム４３ｂが利用可能になってから再度「開発」を行うことで利用可能になる。

攻撃アイテム４２（４２ａ，４２ｂ，…）についても同様である。移動アイテム４４については図示を省略しているが、同様に能力違い且つレベル違いの移動アイテム４４を開発することができる。

なお、攻撃アイテム４２と、防護アイテム４３と、移動アイテム４４の種類や、系譜の設定は、図４の例に限らない。実際の運用にあたっては、各カテゴリーのアイテムは、初期状態から幾つも開発完了状態で利用可能であり、それらに独自の系譜が設定されているとしてもよい。つまり、プレーヤ２は、初期状態から様々なアイテムを選択することで、プレーヤキャラクタ４を独自仕様にカスタマイズできるようにしてもよい。

図５は、複数のプレーヤ２の開発目的アイテムの関係性に基づく開発遂行条件について説明するための図である。

「開発」の設定は、プレーヤ２（２ａ，２ｂ，…）がそれぞれ任意のタイミングで設定するが、サーバシステム１１００は、複数のプレーヤ２が個々に開発している開発目的アイテムの関連性を常時監視している。そして、関連性がアイテム共通条件を満たした開発目的アイテムの開発遂行条件を変更する。

具体的には、図５（１）に示すように、開発目的アイテムに係る情報を比較して、アイテム共通条件を満たさない場合、サーバシステム１１００は、それらの開発は個別開発と見なし、初期設定の開発遂行条件をそのまま適用する。

図５（２）に示すように、開発目的アイテムに係る情報を比較して、アイテム共通条件を満たす場合、サーバシステム１１００はそれらを共通開発と見なす。そして、該当する開発を設定したプレーヤ２（２ａ，２ｂ，…）に、共通開発に係る承認操作を求め、承認したプレーヤ２の開発遂行条件を軽減するように変更する。

「アイテム共通条件」は、本実施形態では「プレーヤが同勢力」且つ「開発目的アイテムが同種」である場合とする。
勿論、アイテム共通条件は、これ以外にも設定可能である。例えば、「開発目的アイテムが同種」のみに単純化してもよい。また例えば、「プレーヤが同勢力」且つ「開発目的アイテムが同系統」としてもよい。或いは、開発目的アイテムに係る所定種類の情報を比較して、共通する情報の数の閾値をアイテム共通条件としてもよい。その場合、開発目的アイテムに係る情報としては、例えば、アイテムのカテゴリー、アイテムの種類、アイテムのレベル、アイテムに設定されている特殊能力、当初開発候補として許可されている種類、開発遂行に要求されるリソースアイテムの種類、開発コスト、などを用いることができる。つまり、アイテム共通条件は、複数の開発設定を「共通開発」と見なす条件である。以降、アイテム共通条件を満たす開発を「共通開発」とも呼ぶ。

なお、ここで言う「リソースアイテム」は、鉄・水などのマテリアルに限らず、エネルギー、技術者、開発場所、魔法力、などを含めることができる。
また、「開発コスト」は、ゲーム内通貨であったり、勢力別に時間経過や有料アイテムの使用で増加する経済力パラメータ値、所定のアイテム、などである。
また、「アイテム共通条件」は、１つに限らない。開発目的アイテム毎に設定してもよい。また、ゲームプレイ開始からの時間経過により変化するとしてもよい。

開発遂行条件の変更は、例えば軽減率Ｒを乗じることで実現される。
図６は、軽減率Ｒの例を説明するための図である。
軽減率Ｒは、複数の変数Ｘｎ（ｎ＝１，２，…）を用いた所定の算出関数ｆ（Ｘｎ）により決定される。
変数Ｘｎは適宜設定可能であるが、本実施形態では、プレーヤ数Ｘ１と、プレーヤレベルＸ２と、初期開発遂行条件負荷度Ｘ３と、開発残割合Ｘ４と、勢力関係度Ｘ５と、を用いる。

プレーヤ数Ｘ１は、アイテム共通条件を満たす開発目的アイテムの開発を設定したプレーヤ２の人数である。そして、プレーヤ数Ｘ１が大きいほど、軽減率Ｒも大きく設定される。なお、プレーヤ数Ｘ１は、逆説的に、アイテム共通条件を満たさない開発目的アイテムの開発を設定したプレーヤ２の人数とすることも可能である。その場合、プレーヤ数Ｘ１が小さいほど、軽減率Ｒは大きく設定される。

プレーヤレベルＸ２は、アイテム共通条件を満たす開発目的アイテムの開発を設定したプレーヤ２のプレーヤレベル（プレイ技量を表すパラメータ値で、過去のプレイ成績に応じて自動設定される）の合計又は平均値である。プレーヤレベルＸ２が大きい程、軽減率Ｒは大きく設定される。或いは、逆にプレーヤレベルＸ２が大きい程、軽減率Ｒを小さく設定してもよい。プレーヤレベルの合計又は平均値ではなく、プレーヤレベルＸ２をプレーヤレベル差としてもよい。この場合、プレーヤレベルＸ２が大きい程、軽減率Ｒは大きく設定することで、上級者が初心者をサポートすることを推奨する効果が期待できる。

初期開発遂行条件負荷度Ｘ３は、初期開発遂行条件の数値（例えば、要求される素材数、コスト、経過時間）などが大きいほど、軽減率Ｒは大きく設定される。勿論、その逆でも良い。

開発残割合Ｘ４は、アイテム共通条件を満たす開発目的アイテムが有ると判定された時点で、それぞれの開発の初期の開発遂行条件のうち、満たされずに残っている割合である。例えば、経過時間１００分が初期の開発遂行条件とされるならば、アイテム共通条件を満たす開発目的アイテムが有ると判定された時点で１０分しか経過していない場合のほうが、５０分経過している場合よりも、軽減率Ｒが大きく設定される。これにより、開発初期からアイテム共通条件を満たせるように、開発目的アイテムの選択を考慮するようにプレーヤに促し、開発に係る興趣を高める効果が期待できる。

勢力関係度Ｘ５は、２つの勢力間に設定されるパラメータ値であって、友好関係・信頼関係が高いほど高い数値が設定される。プレーヤ２間の友好度や信頼度などに置き換えても良い。そして、勢力関係度Ｘ５が大きい程、軽減率Ｒは大きく設定される。

なお、開発遂行条件の変更は、開発遂行条件を記述するパラメータ値に軽減率Ｒを適用して更新する手法に限らず、そもそも記述するパラメータ値が異なる別の開発遂行条件に差し替えるとしてもよい。

図７は、開発設定画面の表示例を示す図である。開発を設定したいと望むプレーヤ２は、ユーザ端末１５００にて所定の開発設定開始操作を入力する。ユーザ端末１５００は、これに応じて所定の開発設定リクエストをサーバシステム１１００へ送信する。すると、サーバシステム１１００は、リクエストしたユーザ端末１５００にて、開発設定画面Ｗ７を表示させる。

開発設定画面Ｗ７は、カテゴリー選択部７１と、開発目的アイテム選択部７２と、開発遂行条件表示部７３と、共通開発情報表示部７４と、を含む。

カテゴリー選択部７１は、開発目的アイテムのカテゴリーの選択を受け付ける。

開発目的アイテム選択部７２は、プレーヤ２が所属する勢力の開発候補アイテムのうち、カテゴリー選択部７１で選択されているカテゴリーに属する開発候補アイテムを表示し、選択操作指示を受け付ける。

開発遂行条件表示部７３は、開発目的アイテム選択部７２で選択されている開発目的アイテムの開発遂行条件を表示する。

共通開発情報表示部７４は、開発目的アイテム選択部７２で選択されている開発目的アイテムが、アイテム共通条件を満たしていることを通知する。つまり、他プレーヤとの共通開発に該当する旨を告げる。そして、共通開発情報表示部７４には、共通開発が成立する相手プレーヤアカウント７５と、変更後開発遂行条件７６と、承認して開発設定を完了する承認操作アイコン７７と、共通開発を拒否して開発設定を完了する拒否操作アイコン７８と、が表示される。プレーヤ２が、承認操作アイコン７７を操作すると、変更後開発遂行条件７６が適用された開発が設定される。

図８は、承認画面の表示例を示す図である。既存の開発がある状況で、新たに設定された開発と、既存の開発との間でアイテム共通条件を満たすことを検出すると、サーバシステム１１００は、既存の開発を設定したプレーヤ２のユーザ端末１５００にて、承認画面Ｗ８を表示させる。

承認画面Ｗ８は、現在の開発遂行条件に対する最新進捗状況８１と、共通開発の影響を受けることを承認した場合に適用される変更後開発遂行条件を表示する効果予測８２と、承認情報表示部８３と、を含む。

承認情報表示部８３は、共通開発が成立する相手プレーヤアカウント８４と、承認して開発設定を完了する承認操作アイコン８５と、共通開発の影響を受けることを拒否して開発設定を完了する拒否操作アイコン８６と、が表示される。プレーヤ２が、承認操作アイコン８５を操作すると、現在進行中の開発の開発遂行条件が変更される。

さて、共通開発の影響を受けることが承認されると、それらの開発は、共通開発状態になったと見なされる。そして、それらの開発遂行条件が変更されるだけではなく、一方の開発に係る行為が他方の開発に影響を及ぼす。

図９は、開発遂行条件の変更の波及について説明するための図である。第１のプレーヤ２ａが設定した開発の開発目的アイテムと、第２のプレーヤ２ｂが設定した開発の開発目的アイテムとが、アイテム共通条件を満たしている。つまり、両者は共通開発状態にある。そして、プレーヤは、開発に作用効果を及ぼす開発関連アイテム７を未遂行の開発に対して使用することができる。開発関連アイテム７の作用効果は、例えば、開発完了後に開発目的アイテムの能力を、開発関連アイテム７が未使用のまま開発完了した場合の能力より向上させる、開発進行中の開発遂行条件を緩和する、などが設定されている。

もし、第１のプレーヤ２ａと第２のプレーヤ２ｂとが、共に開発を設定して進行中であったとしても、両者が共有開発状態になければ（両者の開発が個別開発ならば）、第１のプレーヤ２ａが使用した開発関連アイテム７の作用効果は、第１のプレーヤ２ａの開発に限定して適用される。しかし、両者が共有開発状態にある場合において、第１のプレーヤ２ａが開発関連アイテム７を使用すると、その作用効果は共有開発状態にある第２のプレーヤ２ｂの開発にも及ぶ。

この時の波及効果は、第１のプレーヤ２ａのパラメータ値と第２のプレーヤ２ｂのパラメータ値との差に基づいて変更される。例えば、パラメータ値をプレーヤレベルとし、第１のプレーヤ２ａのプレーヤレベルが、第２のプレーヤ２ｂのプレーヤレベルより大きい場合に、その差が大きい程、波及効果を大きく設定することができる。この場合、上級者が初心者をサポートするような効果が期待される。言い換えると、上級者が初心者をゲームに誘い易くなり、新たなユーザの増加という副次的効果が期待できる。

図１０は、サーバシステム１１００の機能構成例を示す機能ブロック図である。
サーバシステム１１００は、操作入力部１００ｓと、サーバ処理部２００ｓと、音出力部３９０ｓと、画像表示部３９２ｓと、通信部３９４ｓと、サーバ記憶部５００ｓとを備える。

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

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

そして、サーバ処理部２００ｓは、ユーザ管理部２０２と、オンラインショッピング管理部２０４と、ゲーム管理部２１０と、計時部２８０ｓと、音生成部２９０ｓと、画像生成部２９２ｓと、通信制御部２９４ｓとを含む。勿論、これら以外の機能部も適宜含めることができる。

ユーザ管理部２０２は、ユーザ登録手続きに係る処理及びユーザアカウントに紐付けられる各ユーザのデータの管理を行う。本実施形態では、ユーザ管理部２０２は、１）登録ユーザへの固有のユーザアカウントの付与と、２）ユーザアカウント別に個人情報（例えば、アカウント名）を登録管理する登録情報管理と、３）課金要素（本実施形態ではオンラインショッピングなど）の支払いで消費される電子決済媒体の帳簿管理と、４）利用履歴管理と、の各機能を有する。勿論、これら以外のアカウントに紐付けられる他のデータの管理機能も適宜含めることができる。

オンラインショッピング管理部２０４は、オンラインショッピングに関する制御を担う。公知のオンラインショッピング技術を適宜利用して実現できる。本実施形態では、ユーザは、オンラインショッピングによって、開発関連アイテム７（図９参照）を購入することができる。勿論、オンラインショッピングにおける販売対象は、これら以外にも適宜設定可能である。

ゲーム管理部２１０は、ゲームの進行制御に関する各種処理を実行する。具体的には、ゲーム管理部２１０は、開発管理部２１１を有する。開発管理部２１１は、ゲームにおける開発に係る各種処理を行う。具体的には、開発管理部２１１は、第１開発目的アイテム設定部２１２と、第１開発遂行部２１４と、第２開発目的アイテム設定部２１６と、第２開発遂行部２１８と、第１条件緩和部２２０と、開発遂行条件変更部２２２と、勢力別開発候補管理部２２６と、特典付与部２２８と、を有する。勿論、これら以外の機能部も適宜含めることができる。

第１開発目的アイテム設定部２１２は、第１のプレーヤによる第１の開発目的アイテムの設定を行う。具体的には、勢力には、開発目的アイテムとすることができる勢力別の開発候補が複数関連付けられており、第１開発目的アイテム設定部２１２は、第１のプレーヤが所属する勢力の開発候補の中から第１の開発目的アイテムを設定する。

第１開発遂行部２１４は、第１のプレーヤのゲームプレイに基づいて第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に第１の開発目的アイテムを開発完了として第１のプレーヤの所有アイテムとする。

第２開発目的アイテム設定部２１６は、第２のプレーヤによる第２の開発目的アイテムの設定を行う。具体的には、勢力には、開発目的アイテムとすることができる勢力別の開発候補が複数関連付けられており、第２開発目的アイテム設定部２１６は、第２のプレーヤが所属する勢力の開発候補の中から第２の開発目的アイテムを設定する。

第２開発遂行部２１８は、第２のプレーヤのゲームプレイに基づいて第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に第２の開発目的アイテムを開発完了として第２のプレーヤの所有アイテムとする。

第１条件緩和部２２０は、第１のプレーヤのゲームプレイに基づく第１の開発遂行条件を緩和するための所与の条件緩和条件を満たす場合に、第１の開発遂行条件を緩和する。本実施形態における開発関連アイテム７の使用に伴って、当該アイテムの使用対象とされた開発の開発遂行条件を緩和することがこれに該当する（図９参照）。

開発遂行条件変更部２２２は、第１の開発目的アイテムと第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、第１のプレーヤの承認操作指示に応じて第１の開発遂行条件を変更し、第２のプレーヤの承認操作指示に応じて第２の開発遂行条件を変更する。

具体的には、第１の開発遂行条件および第２の開発遂行条件に、開発目的アイテムが設定されてから開発完了するまでの時間長条件が含まれている場合、開発遂行条件変更部２２２は、その時間長条件を変更することができる。

また、第１の開発遂行条件および第２の開発遂行条件に、開発進捗に応じて必要となるリソース（資材や費用）の条件である必要リソース条件が含まれている場合、開発遂行条件変更部２２２は、その必要リソース条件を変更することができる。

また、開発遂行条件変更部２２２は、第１のプレーヤが所属する勢力と第２のプレーヤが所属する勢力との勢力関係に基づいて、第１の開発遂行条件および第２の開発遂行条件の変更内容を可変に制御する。

また、開発遂行条件変更部２２２は、アイテム共通条件を満たす場合に、第１条件緩和部２２０による第１の開発遂行条件の緩和に応じて、第２の開発遂行条件を緩和する。本実施形態で開発関連アイテム７の使用に伴って、開発遂行条件を緩和することがこれに該当する（図９参照）。

また、開発遂行条件変更部２２２は、第１のプレーヤおよび第２のプレーヤ以外に、アイテム共通条件を満たすアイテムを開発目的アイテムとしているプレーヤの人数に基づいて、第１の開発遂行条件および第２の開発遂行条件を変更する。

そして、開発遂行条件変更部２２２は、条件変更波及部２２４を有する。
条件変更波及部２２４は、アイテム共通条件を満たす場合に、第１条件緩和部２２０による第１の開発遂行条件の緩和に応じて、第２の開発遂行条件を緩和する（図９参照）。

勢力別開発候補管理部２２６は、勢力別の開発候補を管理する。そして、ゲームプレイにおいて相手勢力のアイテムを奪取したと認められる場合、例えば第１の勢力が第２の勢力のアイテムを奪取した場合に、勢力別開発候補管理部２２６は、第１の勢力の開発候補に、奪取した第２の勢力のアイテムを追加する。

特典付与部２２８は、第１の開発目的アイテムと第２の開発目的アイテムとがアイテム共通条件を満たす場合に、第１の開発目的アイテムの開発完了時に所与の特典を第１のプレーヤに付与する。具体的には、特典付与部２２８は、第１の開発目的アイテムのパラメータ値を向上させること、及び／又は、第１の開発目的アイテムに所与の能力を付加すること、を特典として前記第１のプレーヤに付与する。

計時部２８０ｓは、システムクロックを利用して現在日時や制限時間等の計時を行う。

音生成部２９０ｓは、音声データの生成やデコードをするＩＣやソフトウェアの実行により実現され、サーバのシステム管理や操作音、ゲームに係るＢＧＭや効果音などの音声データを生成或いはデコードする。そして、システム管理に関する音声信号は音出力部３９０ｓへ出力する。

音出力部３９０ｓは、音声信号を放音する。図１の例では本体装置やタッチパネル１１０８が備えるスピーカ（不図示）がこれに該当する。

画像生成部２９２ｓは、画像の生成を行い、生成した画像を画像表示部３９２ｓに表示させるための信号を出力する。本実施形態では、サーバのシステム管理に関する画像や、ゲーム画面の画像、ゲーム画面をユーザ端末１５００で表示させるためのデータ、などを生成する機能を担う。

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

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

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

図１１は、本実施形態におけるサーバ記憶部５００ｓが記憶するプログラムやデータの例を示す図である。本実施形態におけるサーバ記憶部５００ｓは、サーバプログラム５０１と、配信用ゲームクライアントプログラム５０３と、ゲーム初期設定データ５１０と、ユーザ管理データ６００と、プレイデータ７００と、現在日時８００と、を記憶する。

サーバプログラム５０１は、サーバ処理部２００ｓが読み出して実行することで、ユーザ管理部２０２と、オンラインショッピング管理部２０４と、ゲーム管理部２１０としての機能を実現させるためのプログラムである。なお、３つの管理部は、１つのサーバプログラム５０１で実現するのではなく、３つのプログラムで実現するとしてもよい。

配信用ゲームクライアントプログラム５０３は、ユーザ端末１５００へ提供されるゲームクライアントプログラムのオリジナルである。

ゲーム初期設定データ５１０は、ゲーム実行に必要な各種初期設定データを格納する。
具体的には、ゲーム初期設定データ５１０は、キャラクタ定義データ５１２と、開発関連アイテム定義データ５１４と、開発候補アイテム定義データ５２０と、初期開発完了アイテムリスト５３８と、系譜定義データ５４０と、初期開発候補管理データ５４２と、開発遂行条件変更パターン定義データ５５０と、初期勢力関係定義データ５６０と、特典定義データ５６２と、を含む。勿論、これら以外のデータも適宜含めることができる。

キャラクタ定義データ５１２は、プレーヤキャラクタ４の種類毎に用意され、当該キャラクタに係る各種初期設定データを格納する。本実施形態では、機体ベース４１（図４参照）毎に用意される。１つのキャラクタ定義データ５１２は、キャラクタ種類と、キャラクタ属性と、初期キャラクタレベルと、初期能力パラメータ値と、を含む。勿論、これら以外のデータも適宜含めることができる。

開発関連アイテム定義データ５１４は、開発関連アイテム７（図９参照）の種類毎に用意され、当該アイテムに係る各種初期設定データを格納する。１つの開発関連アイテム定義データ５１４は、例えば、アイテム種類と、プレーヤレベル別作用効果データと、を含む。プレーヤレベル別作用効果データとは、プレーヤレベルの閾値や範囲と対応づけた複数の作用効果の定義データ群である。閾値を境とする作用効果を設定したり、範囲別に作用効果を設定する。本実施形態では、プレーヤレベルが低い程、より高い作用効果が得られるように設定されている。

開発候補アイテム定義データ５２０は、開発に係るアイテムの種類毎に用意される。ゲーム初期段階から開発完了扱いのアイテムも含まれる。
１つの開発候補アイテム定義データ５２０は、例えば図１２に示すように、固有の開発候補アイテム種類５２１と、カテゴリー５２２と、モデルデータ５２３と、アイテムレベル５２４と、初期能力パラメータ値リスト５２５と、初期開発遂行条件５２６と、を含む。勿論、これら以外のデータも適宜含めることができる。

初期開発遂行条件５２６は、初期時間長条件５２６ａと、初期必要リソース条件５２６ｂと、を含む。

初期必要リソース条件５２６ｂは、リソースの種類毎に用意され、リソース種類と、消費形式と、リソース量と、が、設定される。消費形式は、開発設定時点での一括消費、分割消費、開発開始から所定時間毎に消費される経過消費、などが設定される。

図１１に戻って、初期開発完了アイテムリスト５３８は、開発候補アイテム定義データ５２０で定義されるアイテムのうち、ゲーム開始当初から開発完了として扱われる開発候補アイテムのリストである。本実施形態では、初期開発完了アイテムリスト５３８は固定リストとされるが、適宜、参加プレーヤの情報に基づいて変更することができる。例えば、勢力別にプレーヤレベルを比較して、劣る側にハンディキャップとしてゲーム開始当初から開発完了として扱われる開発候補アイテムを増やすとしてもよい。或いは、ゲーム運営者が設定したイベント期間のみ増やすとしてもよい。勿論、減らす事も可能である。

系譜定義データ５４０は、開発候補アイテムの開発系譜毎に用意され、当該系譜を定義する各種データを格納する。１つの系譜定義データ５４０は、系譜種類と、連鎖順アイテム種類リストと、を含む。連鎖順アイテム種類リストは、当該系譜に属する開発候補アイテムの種類を親子の連鎖順にリストアップした情報である。

開発遂行条件変更パターン定義データ５５０は、どのような条件が満たされるとどのように開発遂行条件を変更するかのパターン毎に用意され、当該パターンを定義する各種データを格納する。
１つの開発遂行条件変更パターン定義データ５５０は、例えば図１３に示すように、固有の条件変更パターンＩＤ５５１と、適用要件５５２と、開発遂行条件変更内容データ５５４と、を含む。勿論、これら以外のデータも適宜含めることができる。

適用要件５５２は、当該定義データが適用されるために満たすべき条件を定義している。適用要件５５２は、１つのサブ条件、或いは複数のサブ条件をＡＮＤまたはＯＲで組み合わせて記述する。

サブ条件は適宜設定可能である。本実施形態では、サブ条件として、第１アイテム共通条件５５２ａと、第２アイテム共通条件５５２ｂと、同勢力条件５５２ｃと、所属勢力関係条件５５２ｄと、ゲームプレイ状況条件５５２ｅと、プレーヤパラメータ値差条件５５２ｆと、プレーヤ数条件５５２ｇと、開発関連アイテム利用条件５５２ｈと、を用いる。

第１アイテム共通条件５５２ａは、開発候補アイテムの種類が同種であることを示す条件である。

第２アイテム共通条件５５２ｂは、開発候補アイテムの系譜が同種であることを示す条件である。第１アイテム共通条件５５２ａを省略または全種類として、第２アイテム共通条件５５２ｂに特定の系譜を設定すると、開発候補アイテムの種類が異なっても系譜が同じならば、開発遂行条件が変更されるパターンを作ることができる。

同勢力条件５５２ｃは、第１のプレーヤ２ａの所属勢力と、第２のプレーヤ２ｂの所属勢力とが同じであることを条件とする。または、同勢力が占めるべき割合や、勢力別の割合で当該条件を記述してもよい。同勢力条件５５２ｃを適切に設定すれば、例えば、４人のプレーヤが同種の開発候補アイテムを開発している状況で、全員が同勢力の場合と、半数が敵対勢力である場合とで、関係遂行条件の変更パターンが異なるようにできる。
同勢力条件５２２ｃは、適宜省略する事も可能であるが、あえて必須のサブ条件とするならば、仲間同士の絆感をゲームで醸し出すことができるので好適である。

所属勢力関係条件５５２ｄは、第１のプレーヤ２ａの所属勢力と、第２のプレーヤ２ｂの所属勢力との関係性の条件である。例えば、同盟／敵対／中立などである。或いは、勢力の組み合わせ毎にプレイ状況に応じて自動的に友好度を設定するならば、当該友好度の閾値や範囲で、所属勢力関係条件５５２ｄを記述してもよい。

所属勢力関係条件５５２ｄを適切に設定することで、友好な関係の勢力のプレーヤ間で成立した共通開発と、敵対する勢力のプレーヤ間で成立した共通開発とで、異なる開発遂行条件の変更パターンを設定できる。

ゲームプレイ状況条件５５２ｅは、ゲームプレイの状況に関する条件である。例えば、ゲーム開始からの経過時間、残存しているプレーヤ数、残存している勢力数、勢力間のパワーバランス、クリアされたイベントの種類や数、などの閾値や範囲を設定する。

プレーヤパラメータ値差条件５５２ｆは、第１のプレーヤ２ａと第２のプレーヤ２ｂとのそれぞれに設定されているパラメータ値の差についての条件である。ここで言うパラメータ値には、例えば、過去のプレイ成績に基づいて自動的に付与されるプレーヤレベルなどを用いることができる。

プレーヤ数条件５５２ｇは、第１アイテム共通条件５５２ａを満たしているプレーヤの人数についての条件である。

開発関連アイテム利用条件５５２ｈは、開発関連アイテム７の利用の有無、利用数、利用されたアイテムの種類などについての条件である。

開発遂行条件変更内容データ５５４は、変更対象とされる開発遂行条件の条件項目別に用意される。１つの開発遂行条件変更内容データ５５４は、変更対象条件項目５５４ａと、軽減率算出関数５５４ｂと、軽減率の変数を算出するための軽減率変数定義データ５５４ｃと、を含む。

図１１に戻って、初期勢力関係定義データ５６０は、勢力の組み合わせ別に初期の勢力関係を定義する。

特典定義データ５６２は、開発完了時に、当該開発を設定したプレーヤに付与される特典の内容毎に用意される。１つの特典定義データ５６２は、当該定義データが適用されるために実行されるべき開発遂行条件の変更パターンを示す適用条件変更パターンと、特典内容と、を対応付けて格納する。特典内容としては、例えば、開発完了した開発目的アイテムの能力パラメータ値の向上、アイテムの付与（例えば、新たな開発候補アイテムの付与）、新しい能力の付与、勢力関係の友好化、などの１つまたは複数の組み合わせを設定するとよい。

ユーザ管理データ６００は、プレーヤとなり得る登録ユーザ毎に用意され、固有の識別情報であるユーザアカウントと紐付けられる各種データを格納する。
１つのユーザ管理データ６００は、例えば図１４に示すように、固有のアカウント６０１と、決済媒体帳簿データ６０３と、プレイ履歴データ６０５と、ゲームセーブデータ６１０と、を含む。勿論、これら以外のデータも適宜含めることができる。

決済媒体帳簿データ６０３は、当該ユーザに紐付けられる電子決済用の決済媒体（例えば、仮想通貨、ゲーム内通貨、特定のアイテム、行動力などの特定のパラメータ値など）の補充／消費の量と、補充／消費の事由と、変更日時と、の情報を対応づけて格納する所謂帳簿である。課金履歴データ或いは課金履歴情報と読み替えることができる。

プレイ履歴データ６０５は、何時ゲームプレイをしたか、どのようなプレイ成績であったか、などを記述するデータを、プレイした時系列に格納するデータであって、ログイン／ログアウトのタイミングで自動的に更新される。

ゲームセーブデータ６１０は、所属勢力種類６１１と、プレーヤレベル６１３と、所有アイテム管理データ６１４と、を含む。勿論、これら以外のデータも適宜含めることができる。

所有アイテム管理データ６１４は、当該ユーザが所有するアイテム毎に用意され、その最新状態を記述する各種データを格納する。１つの所有アイテム管理データ６１４は、例えば、アイテムＩＤ、アイテム種類、アイテムレベル、能力パラメータ値、などを含む。

図１１に戻って、プレイデータ７００は、ゲームプレイ毎に用意され、そのゲーム進行状況を記述する各種データや、各キャラクタの制御データなどゲーム画面の表示等に関する各種情報を格納する。

一つのプレイデータ７００は、例えば図１５に示すように、固有のプレイＩＤ７０１と、開始日時７０３と、プレーヤ管理データ７１０と、開発完了アイテムリスト７２８と、開発候補管理データ７３０と、開発管理データ７４０と、共通開発登録データ７５０と、を含む。勿論、これら以外のデータも適宜含めることができる。

プレーヤ管理データ７１０は、プレーヤ毎に用意され、当該プレーヤに係る各種データを格納する。１つのプレーヤ管理データ７１０は、プレーヤアカウント７１１と、所属勢力７１２と、プレーヤ属性７１３と、リソース管理データ７１５と、キャラクタ管理データ７１６と、設定開発ＩＤリスト７１７と、所有アイテム管理データ７１８と、を含む。勿論、これら以外のデータも適宜含めることができる。

プレーヤ属性７１３は、ゲーム開始前にゲームセーブデータ６１０（図１４参照）から読み込むとしても良いし、プレイの都度、複数種類の候補のなかからプレーヤ２が選択して設定するとしてもよい。

リソース管理データ７１５は、開発を遂行するのに必要とされるリソース（例えば、資源アイテム、技術者アイテム、資金、エネルギーなど）の種類毎に用意され、当該リソースの残量や、状態を表す数値を格納する。

キャラクタ管理データ７１６は、当該プレーヤのプレーヤキャラクタ４毎に作成され、当該プレーヤキャラクタの最新状況や制御を行うための各種データを格納する。

設定開発ＩＤリスト７１７は、当該プレーヤが設定した開発の識別情報のリストである。

所有アイテム管理データ７１８には、ゲーム開始前に、当該プレーヤのユーザ管理データ６００の所有アイテム管理データ６１４（図１４参照）がコピーされ、ゲームプレイに使用される。そして、ゲームプレイ後にユーザ管理データ６００の所有アイテム管理データ６１４を、ゲーム終了時の所有アイテム管理データ７１８で更新する。

開発完了アイテムリスト７２８は、開発完了と見なされる開発候補アイテムの登録リストである。開発完了アイテムリスト７２８には、ゲーム開始時点に初期開発完了アイテムリスト５３８（図１１参照）がコピーされ、ゲームプレイ中に開発遂行条件が満たされた開発の開発目的アイテムが追加登録される。

開発候補管理データ７３０は、勢力別に用意され、当該勢力で開発の設定時に利用可能な開発候補アイテムを示すデータ、例えば、開発候補アイテム種類５２１（図１２参照）を格納する。開発候補管理データ７３０には、ゲーム開始前に、初期開発候補管理データ５４２（図１１参照）がコピーされて、ゲームに使用される。

開発管理データ７４０は、開発が設定される毎に作成され、当該開発の進捗状況に関する各種データを格納する。
１つの開発管理データ７４０は、例えば図１６に示すように、固有の開発ＩＤ７４１と、開発開始日時７４２と、開発設定プレーヤアカウント７４３と、開発目的アイテム種類７４４と、適用開発遂行条件７４５と、最新進捗状況７４６と、適用条件変更パターンＩＤ７４７と、を含む。

適用開発遂行条件７４５には、当該開発の設定時に、開発目的アイテムの開発候補アイテム定義データ５２０（図１２参照）から、初期開発遂行条件５２６がコピーされ、それぞれ適用時間長条件７４５ａ、適用必要リソース条件７４５ｂとなる。そして、開発の完了判定等に使用される。当該開発に係り開発遂行条件を変更する場合は、適用開発遂行条件７４５が変更される。

最新進捗状況７４６は、当該開発の進捗状況を示す各種データを格納する。最新進捗状況７４６は、例えば、開発時間経過割合（開発開始日時７４２から現在日時８００までの経過時間の適用時間長条件７４５ａの示す時間に対する割合）と、必要リソース消費割合７４６ｂ（各リソース毎の、適用必要リソース条件７４５ｂが示すリソース量に対する現在までに消費された量の割合）と、を含む。

適用条件変更パターンＩＤ７４７は、当該管理データが定義する開発に適用された開発遂行条件の変更パターンを示す。当該管理データが生成された初期状態では、未定を意味する所定値であるが、適用開発遂行条件７４５が変更される毎に、条件変更パターンＩＤ５５１が追加登録される。

共通開発登録データ７５０は、複数の開発それぞれの設定を比較照合した結果、開発遂行条件変更パターン定義データ５５０（図１３参照）の適用要件５５２を満たすと判定された開発およびその開発を設定したプレーヤの登録データである。適用要件５５２を満たすことで「共通開発」と認定された開発の登録データであり、それらを設定した「共通開発者」と認定されたプレーヤの登録データである。共通開発登録データ７５０は、登録されている全ての開発が開発完了になると、自動的に抹消される。

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

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

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

ユーザ端末演算部２６０は、操作信号送信制御部２６１と、画面表示制御部２６２とを含む。

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

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

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

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

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

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

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

本実施形態の端末記憶部５００は、ゲームクライアントプログラム５０４、を記憶する。勿論、これら以外のプログラムやデータも適宜記憶することができる。

ゲームクライアントプログラム５０４は、端末処理部２００が読み出して実行することによってユーザ端末演算部２６０としての機能を実現させるためのアプリケーションソフトウェアである。本実施形態では、サーバシステム１１００から提供される配信用ゲームクライアントプログラム５０３（図１１参照）のコピーとする。

なお、ゲームクライアントプログラム５０４は、オンラインゲームを実現する技術手法に応じて専用のクライアントプログラムであっても良いし、ウェブブラウザプログラム及びインタラクティブな画像表示を実現するプラグインなどにより構成するとしても良い。

次に、本実施形態のゲームシステム１０００の動作について説明する。
図１８～図１９は、サーバシステム１１００における１つのゲームプレイに係る処理の流れを説明するためのフローチャートである。ここで説明する処理の流れは、サーバ処理部２００ｓがサーバプログラム５０１を実行することにより実現される。

図１８に示すように、サーバシステム１１００は、マッチング処理を実行し（ステップＳ１０）、ゲームプレイを開始する（ステップＳ１２）。

ゲームが開始されて、プレーヤ２は、プレーヤキャラクタ４の設定を変更したいと思ったならば、ユーザ端末１５００にて所定の設定変更リクエスト操作を入力する。ユーザ端末１５００は、当該操作を検出すると、サーバシステム１１００へ、プレーヤキャラクタの設定変更リクエストを送信する。

サーバシステム１１００は、設定変更リクエストを受信すると、プレーヤキャラクタの設定操作を検出したと見なし（ステップＳ２０のＹＥＳ）、送信元のユーザ端末１５００にて所定のキャラクタ設定画面を表示させ、設定変更するプレーヤキャラクタ４のカスタマイズを受け付ける（ステップＳ２２）。この時、プレーヤ２は、自身が所有するアイテムの中から、プレーヤキャラクタ４が装備する攻撃アイテム４２や、防護アイテム４３、移動アイテム４４を選択する（図４参照）。サーバシステム１１００は、プレーヤによる選択操作に従って、プレーヤキャラクタ４の装備を設定する。

設定が完了したら、サーバシステム１１００は、設定変更を適用するための対価の支払を実行する（ステップＳ２４）。そして、支払いが無事完了すれば、プレーヤキャラクタ４の設定変更を適用する（ステップＳ２６）。なお、対価の支払いは、決済用媒体で行うか、所定のアイテムで支払う。対価の支払いが失敗した場合は、設定変更は行われないのは勿論である。

自身が所有するアイテムでは、プレーヤキャラクタ４のカスタマイズが不十分と考えるプレーヤ２は、ユーザ端末１５００にて所定の開発リクエスト操作を入力する。ユーザ端末１５００は、当該操作を検出すると、サーバシステム１１００へ、開発リクエストを送信する。

サーバシステム１１００は、開発リクエストを受信すると、開発設定操作有りと見なし（ステップＳ３０のＹＥＳ）、開発設定処理を実行する（ステップＳ３２）。

図２０は、サーバシステム１１００における１つの開発設定処理の流れを説明するためのフローチャートである。
同処理において、サーバシステム１１００は、開発設定画面Ｗ７を表示させ、その開発目的アイテム選択部７２にて、所属勢力が開発可能な開発候補アイテムを提示する（ステップＳ５０；図７参照）。具体的には、開発リクエストをしたユーザ端末１５００のプレーヤ２が所属する勢力の開発候補管理データ７３０（図１５参照）を参照して、当該管理データに登録されている開発候補アイテムのうちカテゴリー選択部７１で選択されているカテゴリーの開発候補アイテムを提示する。但し、開発完了アイテムリスト７２８に登録されている開発候補アイテムより、１つだけ下位の開発候補アイテムを選択可能に提示する。

そして、サーバシステム１１００は、開発目的アイテムの選択を受け付け、新たな開発管理データ７４０（図１６参照）を作成して、開発を一旦設定する（ステップＳ５２）。

次いで、サーバシステム１１００は、既設の開発の開発管理データ７４０（図１６参照）等を参照して、適用要件５５２が満たされている開発遂行条件変更パターン定義データ５５０を検索する。言い換えると、共通開発が成立する相手（第２のプレーヤ）を検索する。

そして、該当する定義データがあれば、サーバシステム１１００は、今回設定された開発は、共通開発が成立すると判断し（ステップＳ５４のＹＥＳ）、開発リクエストをしたプレーヤに向けて共通開発に基づく開発遂行条件の変更を予告し、承認を求める（ステップＳ５６）。開発設定画面Ｗ７では、共通開発情報表示部７４が表示されることになる（図７参照）。

そして、プレーヤによる承認操作の入力があれば（ステップＳ５８のＹＥＳ）、適用要件５５２が満たされている開発遂行条件変更パターン定義データ５５０の開発遂行条件変更内容データ５５４に従って、ステップＳ５２で一旦設定した適用開発遂行条件７４５（図１６参照）を更新する（ステップＳ６０）。承認操作がなければ、変更はされない。

次に、サーバシステム１１００は共通開発が成立する相手（第２のプレーヤ）となるプレーヤ毎に、そのユーザ端末１５００にて、承認画面Ｗ８（図８参照）を表示させて、共通開発に係る承認を受け付ける（ステップＳ７０）。そして、承認操作指示があれば（ステップＳ７２のＹＥＳ）、サーバシステム１１００は、承認した相手となるプレーヤの開発遂行条件を変更し（ステップＳ７４）、開発設定処理を終了する。

図１８に戻って、ゲーム開始後、プレーヤキャラクタ４が鹵獲される状況が発生したならば（ステップＳ９０のＹＥＳ）、鹵獲されたプレーヤキャラクタ４が装備している攻撃アイテム４２・防護アイテム４３・移動アイテム４４を、鹵獲したプレーヤの所属勢力の開発候補管理データ７３０（図１５参照）に追加登録する（ステップＳ９２）。これにより、他の勢力に所属するプレーヤキャラクタ４を鹵獲することで、鹵獲した側のプレーヤ２は、本来であれば開発できない開発候補アイテムを、これ以降は開発できるようになる。

また、ゲーム開始以降、プレーヤ２は、自身が所有する開発関連アイテム７（図９参照）を使用することができる。
サーバシステム１１００は、開発関連アイテム７（緩和アイテム）を使用したプレーヤがいるかを監視している。そして、該当するプレーヤがいれば、サーバシステム１１００は、条件緩和条件を満たしたプレーヤ有りと判断して（ステップＳ９４のＹＥＳ）、当該プレーヤの適用開発遂行条件７４５を変更し、最新進捗状況７４６を更新する（ステップＳ９６）。

図１９に移って、更に、サーバシステム１１００は、開発関連アイテム７（緩和アイテム）を使用したプレーヤの開発と、何れかの開発遂行条件変更パターン定義データ５５０の適用要件５５２（図１３参照）を満たす開発を有するプレーヤすなわち共通開発者プレーヤを検索する。そして、共通開発者プレーヤの適用開発遂行条件７４５を変更し、最新進捗状況７４６を更新する（ステップＳ９８）。つまり、共通開発者の開発への波及効果を実現する。その際、共通開発者プレーヤであっても、開発関連アイテム７（緩和アイテム）を使用したプレーヤとプレーヤ属性が異なるプレーヤや、異勢力のプレーヤについては、ステップＳ９６を適用外としてもよい。

サーバシステム１１００は、適用開発遂行条件７４５（図１６参照）を満たす開発があるかを常時監視している。もし、適用開発遂行条件７４５を満たす開発が有れば（ステップＳ１１０のＹＥＳ）、当該開発は完了したと見なして、該当する開発目的アイテムを、当該開発を設定したプレーヤすなわち開発設定プレーヤへ付与する。つまり、開発目的アイテムを所有アイテムとする（ステップＳ１１２）。そして、サーバシステム１１００は、該当する開発目的アイテムを開発完了として登録し（ステップＳ１１４）。

次に、サーバシステム１１００は、特典定義データ５６２（図１１参照）の中から、今回適用開発遂行条件７４５を満たした開発の適用条件変更パターンＩＤ７４７（図１６参照）に適合する定義データを抽出する。そして、定義データに定義される特典内容を、開発設定プレーヤへ提示し、選択操作を受け付ける（ステップＳ１１６）。

サーバシステム１１００は、選択された特典を開発設定プレーヤへ付与し（ステップＳ１１８）、ステップＳ１１０で該当した開発の開発管理データ７４０（図１５参照）をプレイデータ７００から削除する（ステップＳ１２０）。

次に、サーバシステム１１００は、既設の未だ完了していない開発に係り、時間経過に応じて必要とされるリソースの徴収を行い、それぞれの最新進捗状況を更新する（ステップＳ１３０）。

サーバシステム１１００は、ステップＳ２０～ステップＳ１３０を、ゲームが終了するまで繰り返す（ステップＳ１３２のＮＯ）。
そして、ゲームが終了したならば（ステップＳ１３２のＹＥＳ）、サーバシステム１１００は、ゲームセーブデータの更新を行って（ステップＳ１３４）、一連の処理を終了する。

以上、本実施形態によれば、マルチプレイゲームにおいて、アイテムの開発について新たな興趣を付加する技術を実現できる。
すなわち、従来の開発の仕組みは、プレーヤ個々にとってのゲームプレイ要素であり、同時に複数人のプレーヤが参加するマルチプレイゲームであっても、プレーヤ別の開発が相互に影響を及ぼすことは無かった。

しかし、本実施形態によれば、第１のプレーヤが指定した開発目的アイテムと、第２のプレーヤが指定した開発目的アイテムとで、アイテム共通条件を満たす場合に、それぞれの開発遂行条件が変更される。つまり、マルチプレイゲームにおいて、プレーヤ別の開発行為が相互に影響を及ぼすこととなり、新たなゲームの興趣となる。

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

（変形例その１）
例えば、上記実施形態では、クライアント・サーバ型のコンピュータシステムにてオンラインゲームを実現する例を挙げたが、複数のユーザ端末１５００をピアツーピア接続したコンピュータシステムにおいて実現するとしてもよい。

（変形例その２）
また、上記実施形態では、ゲーム管理部２１０の機能を全てサーバシステム１１００に担わせる構成であったが、一部をユーザ端末１５００に担わせるとしてもよい。

（変形例その３）
また、上記実施形態では、プレーヤキャラクタ４をロボット兵器として説明したが、これに限らない。戦士、戦車、戦闘機、軍艦、召喚獣、などゲーム内容に応じて適宜設定可能である。

（変形例その４）
また、開発遂行条件には、開発目的アイテムの開発が成功する確率に関する開発成功確率条件を含めることができる。
開発遂行条件に、開発成功確率条件を含める場合、サーバシステム１１００は、ステップＳ１１０（図１９参照）において、開発成功確率条件以外の開発遂行条件の要素が満たされたならば、開発成功確率条件とされる確率を当選確率としてランダム抽選を実行する。そして、サーバシステム１１００は、ランダム抽選で当選したならば、当該開発が成功で完了したとみなし（ステップＳ１１０のＹＥＳ）、開発目的アイテムをプレーヤに付与する。しかし、ランダム抽選で当選しなければ、当該開発は失敗で完了したとみなし（ステップＳ１１０のＮＯ）、開発目的アイテムをプレーヤに付与することはしない。

そして、開発遂行条件変更パターン定義データ５５０（図１３参照）の開発遂行条件変更内容データ５５４にも、開発成功確率条件の変更を設定する。適用要件５５２と、それに対応付けられる開発成功確率条件の変更の設定を適切に行うことで、ある条件が整うと、開発成功確率が上昇したり、逆に開発成功確率が下降したりする変更が可能になり、ゲームの興趣を高めることとなる。

（変形例その５）
また、適用要件５５２（図１３参照）のサブ条件は、適宜追加や省略ができる。例えば、プレーヤ同士の関係性についてのサブ条件を追加することができる。例えば、サーバシステム１１００がフレンド登録機能を提供している構成では、フレンド登録の有／無を条件の内容とすることができる。或いは、プレーヤ間に友好関係が良好と見なされるほど高い値となる連続的或いは断続的に変化する数値（友好度）が設定される構成であれば、友好度の範囲や閾値を条件の内容とすることができる。なお、プレーヤ同士の関係性は、外部のＳＮＳ（ソーシャルネットワークサービス）における関係性を流用してもよい。

また、サーバシステム１１００が、課金履歴をプレーヤ毎に記録管理する構成では、所与の算定期間における課金頻度や、課金額、などをサブ条件に加えてもよい。

２…プレーヤ
２ａ…第１のプレーヤ
２ｂ…第２のプレーヤ
４…プレーヤキャラクタ
７…開発関連アイテム
４１…機体ベース
４２…攻撃アイテム
４３…防護アイテム
４４…移動アイテム
７２…開発目的アイテム選択部
７３…開発遂行条件表示部
７４…共通開発情報表示部
７７…承認操作アイコン
２００ｓ…サーバ処理部
２１０…ゲーム管理部
２１１…開発管理部
２１２…第１開発目的アイテム設定部
２１４…第１開発遂行部
２１６…第２開発目的アイテム設定部
２１８…第２開発遂行部
２２０…第１条件緩和部
２２２…開発遂行条件変更部
２２４…条件変更波及部
２２６…勢力別開発候補管理部
２２８…特典付与部
５００ｓ…サーバ記憶部
５０１…サーバプログラム
５１０…ゲーム初期設定データ
５１２…キャラクタ定義データ
５１４…開発関連アイテム定義データ
５２０…開発候補アイテム定義データ
５５０…開発遂行条件変更パターン定義データ
５５２…適用要件
５５２ａ…第１アイテム共通条件
５５２ｂ…第２アイテム共通条件
５５２ｃ…同勢力条件
５５２ｄ…所属勢力関係条件
５５２ｅ…ゲームプレイ状況条件
５５２ｆ…プレーヤパラメータ値差条件
５５２ｇ…プレーヤ数条件
５５２ｈ…開発関連アイテム利用条件
５５４…開発遂行条件変更内容データ
５６２…特典定義データ
７００…プレイデータ
７１０…プレーヤ管理データ
７１２…所属勢力
７１３…プレーヤ属性
７１５…リソース管理データ
７１６…キャラクタ管理データ
７１８…所有アイテム管理データ
７２８…開発完了アイテムリスト
７３０…開発候補管理データ
７４４…開発目的アイテム種類
７４５…適用開発遂行条件
１０００…ゲームシステム
１１００…サーバシステム
１５００…ユーザ端末

Claims (20)

1. 各プレーヤが、アイテムの開発、合成、又は生成（以下総称して「開発」という。）と開発したアイテムを用いたゲームプレイとを楽しむことができる複数のプレーヤが参加可能なゲームの実行を制御するコンピュータシステムであって、
   第１のプレーヤの操作に基づいて開発候補アイテムの中から指定されたアイテムを第１の開発目的アイテムとして設定する第１の開発目的アイテム設定手段と、
   前記第１のプレーヤのゲームプレイに基づいて前記第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に前記第１の開発目的アイテムを開発完了として前記第１のプレーヤの所有アイテムとする第１の開発遂行手段と、
   第２のプレーヤの操作に基づいて開発候補アイテムの中から指定されたアイテムを第２の開発目的アイテムとして設定する第２の開発目的アイテム設定手段と、
   前記第２のプレーヤのゲームプレイに基づいて前記第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に前記第２の開発目的アイテムを開発完了として前記第２のプレーヤの所有アイテムとする第２の開発遂行手段と、
   前記第１の開発目的アイテム設定手段により設定された前記第１の開発目的アイテムと、前記第２の開発目的アイテム設定手段により設定された前記第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、前記第１のプレーヤによる承認操作指示に応じて前記第１の開発遂行条件を変更し、前記第２のプレーヤによる承認操作指示に応じて前記第２の開発遂行条件を変更する開発遂行条件変更手段と、
   を備えたコンピュータシステム。
2. 前記第１の開発遂行条件および前記第２の開発遂行条件には、開発目的アイテムが設定されてから開発完了するまでの時間長条件が少なくとも含まれ、
   前記開発遂行条件変更手段は、前記時間長条件を変更する、
   請求項１に記載のコンピュータシステム。
3. 前記第１の開発遂行条件および前記第２の開発遂行条件には、開発進捗に応じて必要となるリソースの条件である必要リソース条件が少なくとも含まれ、
   前記開発遂行条件変更手段は、前記必要リソース条件を変更する、
   請求項１又は２に記載のコンピュータシステム。
4. 各プレーヤが、アイテムの開発、合成、又は生成（以下総称して「開発」という。）と開発したアイテムを用いたゲームプレイとを楽しむことができる複数のプレーヤが参加可能なゲームの実行を制御するコンピュータシステムであって、
   第１のプレーヤによる第１の開発目的アイテムの設定を行う第１の開発目的アイテム設定手段と、
   前記第１のプレーヤのゲームプレイに基づいて前記第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に前記第１の開発目的アイテムを開発完了として前記第１のプレーヤの所有アイテムとする第１の開発遂行手段と、
   第２のプレーヤによる第２の開発目的アイテムの設定を行う第２の開発目的アイテム設定手段と、
   前記第２のプレーヤのゲームプレイに基づいて前記第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に前記第２の開発目的アイテムを開発完了として前記第２のプレーヤの所有アイテムとする第２の開発遂行手段と、
   前記第１の開発目的アイテムと前記第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、前記第１の開発遂行条件および前記第２の開発遂行条件を変更する開発遂行条件変更手段と、
   を備え、
   前記第１の開発遂行条件および前記第２の開発遂行条件には、開発目的アイテムの開発が成功する確率に関する開発成功確率条件に基づく抽選により開発に成功したと判定されることが少なくとも含まれ、
   前記第１の開発遂行手段は、前記第１の開発遂行条件に含まれる前記開発成功確率条件に基づく抽選により開発の成否を判定し、成功と判定したことを含む前記第１の開発遂行条件を満たした場合に、前記第１の開発目的アイテムを前記第１のプレーヤに付与し、
   前記第２の開発遂行手段は、前記第２の開発遂行条件に含まれる前記開発成功確率条件に基づく抽選により開発の成否を判定し、成功と判定したことを含む前記第２の開発遂行条件を満たした場合に、前記第２の開発目的アイテムを前記第２のプレーヤに付与し、
   前記開発遂行条件変更手段は、前記アイテム共通条件を満たす場合に前記開発成功確率条件を変更する、
   コンピュータシステム。
5. 前記ゲームは、各プレーヤが複数の勢力の何れかに所属するゲームであり、
   前記勢力には、開発目的アイテムとすることができる勢力別の開発候補が複数関連付けられており、
   前記第１の開発目的アイテム設定手段は、前記第１のプレーヤが所属する勢力の前記開発候補の中から前記第１の開発目的アイテムを設定し、
   前記第２の開発目的アイテム設定手段は、前記第２のプレーヤが所属する勢力の前記開発候補の中から前記第２の開発目的アイテムを設定する、
   請求項１～４の何れか一項に記載のコンピュータシステム。
6. 前記ゲームは、各プレーヤが複数の勢力の何れかに所属するゲームであり、
   前記第１のプレーヤと前記第２のプレーヤとは、同じ勢力に所属するプレーヤである、
   請求項１～５の何れか一項に記載のコンピュータシステム。
7. 前記ゲームは、各プレーヤが複数の勢力の何れかに所属するゲームであり、
   前記開発遂行条件変更手段は、前記第１のプレーヤが所属する勢力と前記第２のプレーヤが所属する勢力とが同じ場合にのみ、前記第１の開発遂行条件および前記第２の開発遂行条件の変更内容を可変に制御する、
   請求項１～５の何れか一項に記載のコンピュータシステム。
8. 各プレーヤが、アイテムの開発、合成、又は生成（以下総称して「開発」という。）と開発したアイテムを用いたゲームプレイとを楽しむことができる複数のプレーヤが参加可能なゲームの実行を制御するコンピュータシステムであって、
   第１のプレーヤによる第１の開発目的アイテムの設定を行う第１の開発目的アイテム設定手段と、
   前記第１のプレーヤのゲームプレイに基づいて前記第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に前記第１の開発目的アイテムを開発完了として前記第１のプレーヤの所有アイテムとする第１の開発遂行手段と、
   第２のプレーヤによる第２の開発目的アイテムの設定を行う第２の開発目的アイテム設定手段と、
   前記第２のプレーヤのゲームプレイに基づいて前記第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に前記第２の開発目的アイテムを開発完了として前記第２のプレーヤの所有アイテムとする第２の開発遂行手段と、
   前記第１の開発目的アイテムと前記第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、前記第１の開発遂行条件および前記第２の開発遂行条件を変更する開発遂行条件変更手段と、
   を備え、
   前記ゲームは、各プレーヤが複数の勢力の何れかに所属するゲームであり、
   前記開発遂行条件変更手段は、前記第１のプレーヤが所属する勢力と前記第２のプレーヤが所属する勢力との勢力関係に基づいて、前記第１の開発遂行条件および前記第２の開発遂行条件の変更内容を可変に制御する、
   コンピュータシステム。
9. 前記開発遂行条件変更手段は、前記第１のプレーヤと前記第２のプレーヤとの関係性に基づいて、前記第１の開発遂行条件および前記第２の開発遂行条件の変更内容を可変に制御する、
   請求項１～５の何れか一項に記載のコンピュータシステム。
10. 各プレーヤが、アイテムの開発、合成、又は生成（以下総称して「開発」という。）と開発したアイテムを用いたゲームプレイとを楽しむことができる複数のプレーヤが参加可能なゲームの実行を制御するコンピュータシステムであって、
    第１のプレーヤによる第１の開発目的アイテムの設定を行う第１の開発目的アイテム設定手段と、
    前記第１のプレーヤのゲームプレイに基づいて前記第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に前記第１の開発目的アイテムを開発完了として前記第１のプレーヤの所有アイテムとする第１の開発遂行手段と、
    第２のプレーヤによる第２の開発目的アイテムの設定を行う第２の開発目的アイテム設定手段と、
    前記第２のプレーヤのゲームプレイに基づいて前記第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に前記第２の開発目的アイテムを開発完了として前記第２のプレーヤの所有アイテムとする第２の開発遂行手段と、
    前記第１の開発目的アイテムと前記第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、前記第１の開発遂行条件および前記第２の開発遂行条件を変更する開発遂行条件変更手段と、
    前記第１のプレーヤのゲームプレイに基づく前記第１の開発遂行条件を緩和するための所与の条件緩和条件を満たす場合に、前記第１の開発遂行条件を緩和する第１の条件緩和手段と、
    を備え、
    前記開発遂行条件変更手段は、前記アイテム共通条件を満たす場合に、前記第１の条件緩和手段による前記第１の開発遂行条件の緩和に応じて、前記第２の開発遂行条件を緩和する条件変更波及手段を有する、
    コンピュータシステム。
11. 前記条件変更波及手段は、前記第１のプレーヤのパラメータ値と前記第２のプレーヤのパラメータ値との差に基づいて、前記第２の開発遂行条件を緩和する程度を変更する
    請求項１０に記載のコンピュータシステム。
12. 前記開発遂行条件変更手段は、前記第１のプレーヤおよび前記第２のプレーヤ以外に、前記アイテム共通条件を満たすアイテムを開発目的アイテムとしているプレーヤの人数に基づいて、前記第１の開発遂行条件および前記第２の開発遂行条件を変更する、
    請求項１～１１の何れか一項に記載のコンピュータシステム。
13. 各プレーヤが、アイテムの開発、合成、又は生成（以下総称して「開発」という。）と開発したアイテムを用いたゲームプレイとを楽しむことができる複数のプレーヤが参加可能なゲームの実行を制御するコンピュータシステムであって、
    第１のプレーヤによる第１の開発目的アイテムの設定を行う第１の開発目的アイテム設定手段と、
    前記第１のプレーヤのゲームプレイに基づいて前記第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に前記第１の開発目的アイテムを開発完了として前記第１のプレーヤの所有アイテムとする第１の開発遂行手段と、
    第２のプレーヤによる第２の開発目的アイテムの設定を行う第２の開発目的アイテム設定手段と、
    前記第２のプレーヤのゲームプレイに基づいて前記第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に前記第２の開発目的アイテムを開発完了として前記第２のプレーヤの所有アイテムとする第２の開発遂行手段と、
    前記第１の開発目的アイテムと前記第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、前記第１の開発遂行条件および前記第２の開発遂行条件を変更する開発遂行条件変更手段と、
    前記第１の開発目的アイテムと前記第２の開発目的アイテムとが前記アイテム共通条件を満たす場合に、前記第１の開発目的アイテムの開発完了時に所与の特典を前記第１のプレーヤに付与する特典付与手段と、
    を備えたコンピュータシステム。
14. 前記特典付与手段は、前記第１の開発目的アイテムのパラメータ値を向上させること、及び／又は、前記第１の開発目的アイテムに所与の能力を付加すること、を前記特典として前記第１のプレーヤに付与する、
    請求項１３に記載のコンピュータシステム。
15. 複数のユーザ端末と、
    前記ユーザ端末と通信可能な請求項１～１４の何れか一項に記載のコンピュータシステムであるサーバシステムと、
    を具備したゲームシステム。
16. 各プレーヤが、アイテムの開発、合成、又は生成（以下総称して「開発」という。）と開発したアイテムを用いたゲームプレイとを楽しむことができる複数のプレーヤが参加可能なゲームの実行をコンピュータシステムが制御する制御方法であって、
    第１のプレーヤの操作に基づいて開発候補アイテムの中から指定されたアイテムを第１の開発目的アイテムとして設定する第１の開発目的アイテム設定と、
    前記第１のプレーヤのゲームプレイに基づいて前記第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に前記第１の開発目的アイテムを開発完了として前記第１のプレーヤの所有アイテムとする第１の開発遂行処理と、
    第２のプレーヤの操作に基づいて開発候補アイテムの中から指定されたアイテムを第２の開発目的アイテムとして設定する第２の開発目的アイテム設定と、
    前記第２のプレーヤのゲームプレイに基づいて前記第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に前記第２の開発目的アイテムを開発完了として前記第２のプレーヤの所有アイテムとする第２の開発遂行処理と、
    前記第１の開発目的アイテム設定で設定された前記第１の開発目的アイテムと、前記第２の開発目的アイテム設定で設定された前記第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、前記第１のプレーヤによる承認操作指示に応じて前記第１の開発遂行条件を変更し、前記第２のプレーヤによる承認操作指示に応じて前記第２の開発遂行条件を変更する開発遂行条件変更と、
    を実行する制御方法。
17. 各プレーヤが、アイテムの開発、合成、又は生成（以下総称して「開発」という。）と開発したアイテムを用いたゲームプレイとを楽しむことができる複数のプレーヤが参加可能なゲームの実行をコンピュータシステムが制御する制御方法であって、
    第１のプレーヤによる第１の開発目的アイテムの設定を行う第１の開発目的アイテム設定と、
    前記第１のプレーヤのゲームプレイに基づいて前記第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に前記第１の開発目的アイテムを開発完了として前記第１のプレーヤの所有アイテムとする第１の開発遂行処理と、
    第２のプレーヤによる第２の開発目的アイテムの設定を行う第２の開発目的アイテム設定と、
    前記第２のプレーヤのゲームプレイに基づいて前記第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に前記第２の開発目的アイテムを開発完了として前記第２のプレーヤの所有アイテムとする第２の開発遂行処理と、
    前記第１の開発目的アイテムと前記第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、前記第１の開発遂行条件および前記第２の開発遂行条件を変更する開発遂行条件変更と、
    を実行し、
    前記第１の開発遂行条件および前記第２の開発遂行条件には、開発目的アイテムの開発が成功する確率に関する開発成功確率条件に基づく抽選により開発に成功したと判定されることが少なくとも含まれ、
    前記第１の開発遂行処理は、前記第１の開発遂行条件に含まれる前記開発成功確率条件に基づく抽選により開発の成否を判定し、成功と判定したことを含む前記第１の開発遂行条件を満たした場合に、前記第１の開発目的アイテムを前記第１のプレーヤに付与することを含み、
    前記第２の開発遂行処理は、前記第２の開発遂行条件に含まれる前記開発成功確率条件に基づく抽選により開発の成否を判定し、成功と判定したことを含む前記第２の開発遂行条件を満たした場合に、前記第２の開発目的アイテムを前記第２のプレーヤに付与することを含み、
    前記開発遂行条件変更は、前記アイテム共通条件を満たす場合に前記開発成功確率条件を変更することを含む、
    制御方法。
18. 各プレーヤが、アイテムの開発、合成、又は生成（以下総称して「開発」という。）と開発したアイテムを用いたゲームプレイとを楽しむことができる複数のプレーヤが参加可能なゲームの実行をコンピュータシステムが制御する制御方法であって、
    第１のプレーヤによる第１の開発目的アイテムの設定を行う第１の開発目的アイテム設定と、
    前記第１のプレーヤのゲームプレイに基づいて前記第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に前記第１の開発目的アイテムを開発完了として前記第１のプレーヤの所有アイテムとする第１の開発遂行処理と、
    第２のプレーヤによる第２の開発目的アイテムの設定を行う第２の開発目的アイテム設定と、
    前記第２のプレーヤのゲームプレイに基づいて前記第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に前記第２の開発目的アイテムを開発完了として前記第２のプレーヤの所有アイテムとする第２の開発遂行処理と、
    前記第１の開発目的アイテムと前記第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、前記第１の開発遂行条件および前記第２の開発遂行条件を変更する開発遂行条件変更と、
    を実行し、
    前記ゲームは、各プレーヤが複数の勢力の何れかに所属するゲームであり、
    前記開発遂行条件変更は、前記第１のプレーヤが所属する勢力と前記第２のプレーヤが所属する勢力との勢力関係に基づいて、前記第１の開発遂行条件および前記第２の開発遂行条件の変更内容を可変に制御することを含む、
    制御方法。
19. 各プレーヤが、アイテムの開発、合成、又は生成（以下総称して「開発」という。）と開発したアイテムを用いたゲームプレイとを楽しむことができる複数のプレーヤが参加可能なゲームの実行をコンピュータシステムが制御する制御方法であって、
    第１のプレーヤによる第１の開発目的アイテムの設定を行う第１の開発目的アイテム設定と、
    前記第１のプレーヤのゲームプレイに基づいて前記第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に前記第１の開発目的アイテムを開発完了として前記第１のプレーヤの所有アイテムとする第１の開発遂行処理と、
    第２のプレーヤによる第２の開発目的アイテムの設定を行う第２の開発目的アイテム設定と、
    前記第２のプレーヤのゲームプレイに基づいて前記第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に前記第２の開発目的アイテムを開発完了として前記第２のプレーヤの所有アイテムとする第２の開発遂行処理と、
    前記第１の開発目的アイテムと前記第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、前記第１の開発遂行条件および前記第２の開発遂行条件を変更する開発遂行条件変更と、
    前記第１のプレーヤのゲームプレイに基づく前記第１の開発遂行条件を緩和するための所与の条件緩和条件を満たす場合に、前記第１の開発遂行条件を緩和する第１の条件緩和処理と、
    を実行し、
    前記開発遂行条件変更は、前記アイテム共通条件を満たす場合に、前記第１の条件緩和処理による前記第１の開発遂行条件の緩和に応じて、前記第２の開発遂行条件を緩和することを含む、
    制御方法。
20. 各プレーヤが、アイテムの開発、合成、又は生成（以下総称して「開発」という。）と開発したアイテムを用いたゲームプレイとを楽しむことができる複数のプレーヤが参加可能なゲームの実行をコンピュータシステムが制御する制御方法であって、
    第１のプレーヤによる第１の開発目的アイテムの設定を行う第１の開発目的アイテム設定と、
    前記第１のプレーヤのゲームプレイに基づいて前記第１の開発目的アイテムに関連付けられた第１の開発遂行条件を満たすかを判定し、満たす場合に前記第１の開発目的アイテムを開発完了として前記第１のプレーヤの所有アイテムとする第１の開発遂行処理と、
    第２のプレーヤによる第２の開発目的アイテムの設定を行う第２の開発目的アイテム設定と、
    前記第２のプレーヤのゲームプレイに基づいて前記第２の開発目的アイテムに関連付けられた第２の開発遂行条件を満たすかを判定し、満たす場合に前記第２の開発目的アイテムを開発完了として前記第２のプレーヤの所有アイテムとする第２の開発遂行処理と、
    前記第１の開発目的アイテムと前記第２の開発目的アイテムとが所与のアイテム共通条件を満たす場合に、前記第１の開発遂行条件および前記第２の開発遂行条件を変更する開発遂行条件変更と、
    前記第１の開発目的アイテムと前記第２の開発目的アイテムとが前記アイテム共通条件を満たす場合に、前記第１の開発目的アイテムの開発完了時に所与の特典を前記第１のプレーヤに付与する特典付与と、
    を実行する制御方法。

Images