JP7383414B2 - ゲームプログラム、ゲーム処理方法、情報処理装置 - Google Patents

Description

本発明は、ゲームプログラム、ゲーム処理方法、及び情報処理装置に関する。

サーバ装置からネットワークを介して端末装置にゲームデータを提供し、当該端末装置において提供されたゲームデータを用いてゲームが実行される、いわゆるオンラインゲームが知られている。

このようなオンラインゲームにおいて、敵キャラクタのそれぞれにドロップするアイテムの種類とドロップする確率が予め設定され、プレイヤが操作キャラクタを操作して敵キャラクタを倒した場合に、上記確率に基づいてプレイヤにアイテムが付与されるゲームがある。例えば、特許文献１には、複数のプレイヤがそれぞれ操作キャラクタを操作して敵キャラクタを倒した場合に、アイテムを付与する対象となるプレイヤを特定し、当該特定された一部のプレイヤに対してアイテムが付与されるゲームシステムが開示されている。

特開２０１８－５７８５３号公報

上記従来技術では、敵キャラクタからドロップされたアイテムが、当該アイテムを要望するプレイヤには付与されず、要望していないプレイヤに付与される場合がある。このため、欲しいアイテムを入手するために何度も敵キャラクタを倒す必要が生じる等、プレイヤの負担の増大を招くという課題があった。

本発明はこのような問題点に鑑みてなされたものであり、オンラインゲームにおいてプレイヤが要望する報酬を効率良く入手することができるゲームプログラム、ゲーム処理方法、情報処理装置を提供することを目的とする。

上記目的を達成するために、本発明のゲームプログラムは、複数の端末装置と通信可能に接続された情報処理装置を、所定のゲーム内グループに属する複数のゲームキャラクタを操作する複数のプレイヤの少なくとも１人から、前記ゲーム内グループが報酬を取得した場合に受け取りたい前記報酬を指定する操作を、前記ゲーム内グループが前記報酬を取得する前に受け付ける報酬指定受付処理部、受け付けた操作内容に基づいて、どのプレイヤがどの報酬を要望しているかを表す報酬要望情報を登録する情報登録処理部、前記ゲーム内グループが前記報酬を取得した際に、当該報酬を前記報酬要望情報に基づいて決定した前記プレイヤに付与する報酬付与処理部、として機能させる。

また、上記目的を達成するために、本発明のゲーム処理方法は、複数の端末装置と通信可能に接続された情報処理装置によって実行されるゲーム処理方法であって、所定のゲーム内グループに属する複数のゲームキャラクタを操作する複数のプレイヤの少なくとも１人から、前記ゲーム内グループが報酬を取得した場合に受け取りたい前記報酬を指定する操作を、前記ゲーム内グループが前記報酬を取得する前に受け付けるステップと、受け付けた操作内容に基づいて、どのプレイヤがどの報酬を要望しているかを表す報酬要望情報を登録するステップと、前記ゲーム内グループが前記報酬を取得した際に、当該報酬を前記報酬要望情報に基づいて決定した前記プレイヤに付与するステップと、を有する。

また、上記目的を達成するために、本発明の情報処理装置は、複数の端末装置と通信可能に接続された情報処理装置であって、所定のゲーム内グループに属する複数のゲームキャラクタを操作する複数のプレイヤの少なくとも１人から、前記ゲーム内グループが報酬を取得した場合に受け取りたい前記報酬を指定する操作を、前記ゲーム内グループが前記報酬を取得する前に受け付ける報酬指定受付処理部と、受け付けた操作内容に基づいて、どのプレイヤがどの報酬を要望しているかを表す報酬要望情報を登録する情報登録処理部と、前記ゲーム内グループが前記報酬を取得した際に、当該報酬を前記報酬要望情報に基づいて決定した前記プレイヤに付与する報酬付与処理部と、を有する。

本発明のゲームプログラム等によれば、オンラインゲームにおいてプレイヤが要望する報酬を効率良く入手することができる。

一実施形態に係るゲームシステムの全体構成の一例を表すシステム構成図である。 端末装置の構成の一例を表す構成図である。 サーバ装置の機能的構成の一例を表すブロック図である。 アイテム指定画面の一例を表す説明図である。 アイテム指定画面の他の例を表す説明図である。 アイテム要望リストの一例を表す説明図である。 アイテム要望リストの他の例を表す説明図である。 アイテム要望リストのさらに他の例を表す説明図である。 アイテム要望リストのさらに他の例を表す説明図である。 サーバのＣＰＵによって実行される処理手順の一例を表すフローチャートである。 一度に多数のアイテム取得対象に対して受け取りたいアイテムを指定することが可能な変形例におけるアイテム指定一覧画面の一例を表す説明図である。 一度に多数のアイテム取得対象に対して受け取りたいアイテムを指定することが可能な変形例におけるアイテム要望一覧リストの一例を表す説明図である。 一度に多数のアイテム取得対象に対して受け取りたいアイテムを指定することが可能な変形例におけるサーバのＣＰＵによって実行される処理手順の一例を表すフローチャートである。 サーバのハードウェア構成の一例を表すブロック図である。

以下、本発明の一実施の形態について図面を参照しつつ説明する。

＜１．ゲームシステムの全体構成＞
まず、図１及び図２を用いて、本実施形態に係るゲームシステム１の全体構成の一例について説明する。図１に示すように、ゲームシステム１は、複数の端末装置３と、サーバ装置５を有する。複数の端末装置３とサーバ装置５は、例えばＬＡＮやインターネット等のネットワークＮＷを介して通信可能に接続されている。なお、図１ではサーバ装置５が１台のコンピュータで構成されているが、複数台のコンピュータで構成されてもよい。

図２に示すように、各端末装置３は、ゲームコントローラ７と表示装置９に有線又は無線により通信可能に接続されている。

端末装置３は、例えば据え置き型のゲーム機である。但しこれに限定されるものではなく、例えば入力部や表示部等を一体に備えた携帯型のゲーム機でもよい。また、ゲーム機以外にも、例えば、サーバコンピュータ、デスクトップ型コンピュータ、ノート型コンピュータ、タブレット型コンピュータ等のように、コンピュータとして製造、販売等されているものや、携帯電話、スマートフォン、ファブレット等のように、電話機として製造、販売等されているものでもよい。

プレイヤは、ゲームコントローラ７を用いて各種の操作入力を行う。図２に示す例では、ゲームコントローラ７は例えば十字キー１１や複数のボタン１３等を有する。なお、ゲームコントローラ７は上記に代えて又は加えて、例えばジョイスティックやタッチパッド等を有してもよい。

表示装置９は、例えばブラウン管、液晶、プラズマ、有機ＥＬ、プロジェクター等によるディスプレイ装置である。表示装置９は、音声を出力するスピーカー（図示省略）等を一体又は別体として備えてもよい。

サーバ装置５（情報処理装置の一例）は、ゲームサービスを受ける各プレイヤの端末装置３からのネットワークＮＷを介したアクセスを受け付けて、各プレイヤのゲーム情報を記憶装置に蓄積して管理し、各プレイヤにネットワークＮＷを介したゲームサービス（オンラインゲーム）を提供する。

サーバ装置５によるゲームサービスの提供の形態としては、ゲームプログラム（アプリケーションソフトウェアともいう）がサーバ装置５に実装されており、端末装置３でのプレイヤの操作入力に応じてサーバ装置５でゲームを実行し、その実行結果を各プレイヤの端末装置３に送信する形態がある。例えば、各プレイヤの端末装置３に搭載されたウェブブラウザによってゲームをプレイできる、いわゆるブラウザゲームをサーバ装置５が提供してもよい。また、サーバ装置５でゲームを実行した結果のゲーム映像を、例えばストリーミング形式等で端末装置３に送信する、いわゆるクラウドゲームをサーバ装置５が提供してもよい。あるいは、ＳＮＳ（ソーシャルネットワーキングサービス）においてウェブブラウザ上で動作するＡＰＩ（アプリケーションプログラミングインタフェース）などの動作環境を基に作成されるアプリケーションソフトウェアによって実行される、いわゆるソーシャルゲームをサーバ装置５が提供してもよい。なお、端末装置３にゲームプログラムの一部をインストールし、サーバ装置５だけでなく端末装置３においても部分的にゲーム処理が実行されるようにしてもよい。

＜２．サーバの機能的構成＞
次に、図３及び図４～図９を用いて、サーバ装置５の機能的構成の一例について説明する。

図３に示すように、サーバ装置５は、報酬指定受付処理部１５と、情報登録処理部１７と、報酬付与処理部１９とを有する。

報酬指定受付処理部１５は、所定のゲーム内グループに属する複数のゲームキャラクタを操作する複数のプレイヤの少なくとも１人から、ゲーム内グループが報酬を取得した場合に受け取りたい報酬を指定する操作を、ゲーム内グループが報酬を取得する前に受け付ける。ここで「ゲーム内グループ」とは、ゲーム内で結成される、複数のゲームキャラクタが属するグループであり、例えば複数のゲームキャラクタが行動を共にするパーティや、プレイヤ同士で結成するコミュニティ（例えばギルド）等である。本実施形態では、ゲーム内グループがパーティである場合について説明する。

また「報酬」とは、ゲーム内グループが所定の行動を実行することによって取得する仮想的な見返りであり、例えばアイテムである。アイテムは、ゲーム内で使用することによって何らかの効果が得られる仮想的な道具全般をいい、例えば武器、防具、装具、機器、飲食物、薬、これらを生成するための素材や材料、ゲーム内通貨等が含まれる。なお、「報酬」に、プレイヤが操作するゲームキャラクタと協力して行動可能な、ゲームプログラムにより規定される所定のアルゴリズムにより自動制御されるキャラクタ（いわゆるノンプレイヤキャラクタ）を含めてもよい。

また「報酬を取得」には、例えば、ゲーム内グループが敵キャラクタを討伐してアイテムを獲得したり、所定のミッションやクエストを達成することでアイテムを獲得したり、例えば洞窟、森、山、塔、要塞、城、ダンジョン等の所定のエリアを攻略することでアイテムを獲得したり、宝箱や隠し場所等を探し出してアイテムを入手すること等が含まれる。本実施形態では、敵キャラクタを討伐してアイテムを獲得する場合について説明する。具体的には、敵キャラクタのそれぞれにドロップするアイテムの種類とドロップする確率が予め設定されており、ゲーム内グループが敵キャラクタを倒した際に、上記確率に基づいてドロップされたアイテムがゲーム内グループに付与される。したがって、報酬指定受付処理部１５は、複数のプレイヤの少なくとも１人から、ゲーム内グループが倒した敵キャラクタがアイテムをドロップした場合に受け取りたいアイテムを指定する操作を、ゲーム内グループが敵キャラクタと戦闘する前に受け付ける。

なお、本実施形態では、報酬指定受付処理部１５が、ゲーム内グループに属する複数のゲームキャラクタをそれぞれ操作する複数のプレイヤの全員から受け取りたい報酬を指定する操作をそれぞれ受け付ける場合について説明するが、これに限定されるものではない。例えば、複数のプレイヤのうちの少なくとも１人のプレイヤ（パーティのリーダやギルドマスタ等のグループの上位メンバ）が、グループを代表して各メンバの受け取りたい報酬を指定してもよい。

図４及び図５に、アイテム指定画面の具体例を示す。図４は、パーティの討伐対象が１種類のアイテムをドロップする敵キャラクタに決定された場合のアイテム指定画面であり、パーティの各プレイヤの表示装置９にそれぞれ表示される。図４に示す例では、アイテム指定画面２１に、討伐対象の敵キャラクタ（この例ではドラゴンＡ）、倒したときにアイテムをドロップする確率（この例では７０％）、ドロップされるアイテムの種類（この例ではドラゴン石ａ）、ドロップする個数（この例では１個）、及び「受け取る」ボタン２３が表示されている。パーティの各プレイヤは、パーティが当該敵キャラクタを倒した際にアイテムを受け取りたい場合には、「受け取る」ボタン２３を操作してアイテムを指定することができる。

図５は、パーティの討伐対象が複数種類のアイテムをドロップする敵キャラクタに決定された場合のアイテム指定画面であり、パーティの各プレイヤの表示装置９にそれぞれ表示される。図５に示す例では、アイテム指定画面２５に、討伐対象の敵キャラクタ（この例ではドラゴンＢ）、倒したときにアイテムをドロップする確率（この例では５０％）、ドロップされるアイテムの種類（この例ではドラゴン石ｂ１，ｂ２，ｂ３の３種類）、ドロップする個数（この例では各１個）、及び「受け取る」ボタン２７が表示されている。パーティの各プレイヤは、パーティが当該敵キャラクタを倒した際にいずれかのアイテムを受け取りたい場合には、「受け取る」ボタン２７を操作してアイテムを種類ごとに指定することができる。なお、アイテムの指定は１種類又は複数種類の指定が可能である。

なお、各プレイヤによる上記アイテムの指定操作は、パーティが討伐対象の敵キャラクタと戦闘する前に行われる。また、図４及び図５では、敵キャラクタを討伐してアイテムを獲得する場合のアイテム指定画面を一例として図示したが、これに限定されるものではなく、例えば所定のミッションやクエストを達成することでアイテムを獲得したり、例えば所定のエリアを攻略することでアイテムを獲得する場合のアイテム指定画面としてもよい。これらの場合には、敵キャラクタの欄をミッションやエリアの種類等とすればよい（ドロップ確率は削除）。

図２に戻り、情報登録処理部１７は、上記報酬指定受付処理部１５により受け付けた操作内容に基づいて、どのプレイヤがどの報酬を要望しているかを表す報酬要望情報を生成し、適宜の記録手段（例えば後述のＲＡＭ５０５や記録装置５１７等）に登録する。登録された報酬要望情報は、必要に応じて各プレイヤが閲覧できるようにしてもよい。また、他のプレイヤの合意が得られない場合にはアイテムの指定をキャンセルする等の補正を可能としておき、合意が得られた場合に初めて登録されるようにしてもよい。本実施形態では、「報酬要望情報」として、どのプレイヤがどのアイテムを要望しているかを示すアイテム要望リストが登録される場合について説明する。

報酬付与処理部１９は、ゲーム内グループが報酬を取得した際に、当該報酬を付与するプレイヤを上記報酬要望情報に基づいて決定し、決定したプレイヤに報酬を付与する。

図６～図９に、アイテム要望リストの具体例を示す。図６～図９では、パーティの構成メンバが例えば４人のゲームキャラクタであり、各メンバがプレイヤＡ～Ｄによりそれぞれ操作される場合について説明する。なお、パーティの構成メンバは４人以外（例えば２人又は３人、あるいは５人以上）でもよい。

図６は、例えば１種類のアイテムを１人のプレイヤが要望している場合のアイテム要望リストである。図６に示すアイテム要望リスト２９は、１種類のドラゴン石ａ（第１の報酬の一例）を１人のプレイヤＢ（第１のプレイヤの一例）が要望していることを表している。すなわち、図４に示すアイテム指定画面において、プレイヤＢのみが「受け取る」ボタン２３を操作し、他のプレイヤＡ，Ｃ，Ｄは「受け取る」ボタン２３を操作しなかった場合（図６では「パス」と図示）のアイテム要望リストである。この場合には、報酬付与処理部１９は、パーティがドラゴン石ａを取得した際に、当該ドラゴン石ａをプレイヤＢに付与する。

これにより、プレイヤＢは、パーティがドラゴンＡを倒してドラゴン石ａを取得した際に、当該ドラゴン石ａを確実に受け取ることができる。したがって、例えばパーティの中に敵キャラクタが１個だけドロップするアイテムをどうしても欲しいプレイヤが１人いるような場合に、上記アイテム要望リスト２９等によるアイテム付与は有効である。また、本実施形態ではドラゴンＡが１個のドラゴン石ａをドロップすることとしたが、例えばドラゴンＡがドラゴン石ａを複数個ドロップする場合には、プレイヤＢが１人で全部受け取ることができる。このため、例えばプレイヤＢが所定のアイテムを生成するための素材として大量のドラゴン石ａを集めているような場合には、上記アイテム要望リスト２９等によるアイテム付与は特に有効である。

図７は、例えば１種類のアイテムを複数のプレイヤが要望している場合のアイテム要望リストである。図７に示すアイテム要望リスト３１は、１種類のドラゴン石ａ（第２の報酬の一例）を３人のプレイヤＡ，Ｂ，Ｄ（複数の第２のプレイヤの一例）が要望していることを表している。すなわち、図４に示すアイテム指定画面において、プレイヤＡ，Ｂ，Ｄが「受け取る」ボタン２３を操作し、プレイヤＣのみが「受け取る」ボタン２３を操作しなかった場合（図７では「パス」と図示）のアイテム要望リストである。この場合には、報酬付与処理部１９は、パーティがドラゴン石ａを取得した際に、当該ドラゴン石ａを３人のプレイヤＡ，Ｂ，Ｄの中からランダムに決定した１人のプレイヤに付与する。

これにより、パーティがドラゴンＡを倒してドラゴン石ａを取得した際に、当該ドラゴン石ａを要望する３人のプレイヤＡ，Ｂ，Ｄのうちランダムで決定された１人のプレイヤが、ドラゴン石ａを受け取ることができる。したがって、例えばパーティの中に敵キャラクタがドロップする１種類のアイテムを欲しいプレイヤが複数人いるような場合に、上記アイテム要望リスト３１等によるアイテム付与は有効である。例えば、新しい敵キャラクタがリリースされた直後等においては、当該敵キャラクタがドロップするアイテム等を多くのプレイヤが欲しがることから、上記アイテム要望リスト３１等によるアイテム付与は特に有効である。また、例えばプレイヤＣのように、既にアイテムを入手し終えたプレイヤは当該アイテムを指定しないことによって自分に付与されることを防止できるので、アイテムを要望する他のプレイヤＡ，Ｂ，Ｄが受け取る可能性が高まり、欲しいアイテムを効率良く入手することができる。

図８は、例えば複数種類のアイテムを複数のプレイヤが要望している場合のアイテム要望リストである。図８に示すアイテム要望リスト３３は、３種類のドラゴン石ｂ１，ｂ２，ｂ３（第３の報酬の一例）のうち、ドラゴン石ｂ１（一の種類の第３の報酬の一例）をプレイヤＣのみ（１人の第３のプレイヤの一例）が要望しており、ドラゴン石ｂ２（一の種類の第３の報酬の一例）を４人のプレイヤＡ，Ｂ，Ｃ，Ｄ（複数の第３のプレイヤの一例）が要望しており、ドラゴン石ｂ３（一の種類の第３の報酬の一例）を２人のプレイヤＢ，Ｃ（複数の第３のプレイヤの一例）が要望していることを表している。

すなわち、図５に示すアイテム指定画面において、プレイヤＣのみがドラゴン石ｂ１の「受け取る」ボタン２７を操作し、プレイヤＡ，Ｂ，Ｄがドラゴン石ｂ１の「受け取る」ボタン２７を操作しなかった場合（図８では「パス」と図示）、且つ、プレイヤＡ，Ｂ，Ｃ，Ｄの全員がドラゴン石ｂ２の「受け取る」ボタン２７を操作した場合、且つ、プレイヤＢ，Ｃがドラゴン石ｂ３の「受け取る」ボタン２７を操作し、プレイヤＡ，Ｄがドラゴン石ｂ３の「受け取る」ボタン２７を操作しなかった場合（図８では「パス」と図示）のアイテム要望リストである。

この場合には、報酬付与処理部１９は、パーティがドラゴン石ｂ１，ｂ２，ｂ３を取得した際に、ドラゴン石ｂ１をプレイヤＣに付与し、ドラゴン石ｂ２を４人のプレイヤＡ，Ｂ，Ｃ，Ｄの中からランダムに決定した１人のプレイヤに付与し、ドラゴン石ｂ３を２人のプレイヤＢ，Ｃの中からランダムに決定した１人のプレイヤに付与する。

これにより、パーティがドラゴンＢを倒して３種類のドラゴン石ｂ１，ｂ２，ｂ３を取得した際に、１人のプレイヤＣのみが要望しているドラゴン石ｂ１についてはプレイヤＣが確実に受け取ることができる。また、複数のプレイヤが要望しているドラゴン石ｂ２，ｂ３については、それぞれについてランダムで決定された１人のプレイヤが受け取ることができる。このようにして、複数種類のアイテムを取得した場合に複数のプレイヤに最適化して配分することができる。したがって、例えば知り合いや友人等でない初見のプレイヤ同士でパーティを構成した場合等において（いわゆる野良パーティ）、各プレイヤが全種類のアイテムを指定したような場合に、上記アイテム要望リスト３３等によるアイテム付与は有効である。また、知り合いや友人等でパーティを構成する場合には、強いプレイヤや既にアイテムを入手し終えたプレイヤは当該アイテムを指定しないので、アイテムを要望するプレイヤが受け取る可能性が高まり、欲しいアイテムを効率良く入手することができる。

図９は、例えば複数種類のアイテムを１人のプレイヤが要望している場合のアイテム要望リストである。図９に示すアイテム要望リスト３５は、３種類のドラゴン石ｂ１，ｂ２，ｂ３（第４の報酬の一例）を１人のプレイヤＣのみ（１人の第４のプレイヤの一例）が要望していることを表している。すなわち、図５に示すアイテム指定画面において、プレイヤＣがドラゴン石ｂ１，ｂ２，ｂ３の「受け取る」ボタン２７を全て操作し、プレイヤＡ，Ｂ，Ｄがドラゴン石ｂ１，ｂ２，ｂ３の「受け取る」ボタン２７を全て操作しなかった場合（図９では「パス」と図示）のアイテム要望リストである。この場合には、報酬付与処理部１９は、パーティがドラゴン石ｂ１，ｂ２，ｂ３を取得した際に、当該ドラゴン石ｂ１，ｂ２，ｂ３を全てプレイヤＣに付与する。

これにより、プレイヤＣは、パーティがドラゴンＢを倒して３種類のドラゴン石ｂ１，ｂ２，ｂ３を取得した際に、当該ドラゴン石ｂ１，ｂ２，ｂ３の全部を確実に受け取ることができる。したがって、パーティの中に、例えばプレイヤＣのように、初心者やレベルの低いプレイヤがおり、当該プレイヤが操作するゲームキャラクタに全部のアイテムを付与して育成したいような場合に、上記アイテム要望リスト３５等によるアイテム付与は特に有効である。その結果、プレイヤが初心者やライトユーザ等である場合でも、気軽にパーティに参加できるようになり、オンラインゲームを活性化できる。

なお、以上説明した各処理部における処理等は、これらの処理の分担の例に限定されるものではなく、例えば、更に少ない数の処理部（例えば１つの処理部）で処理されてもよく、また、更に細分化された処理部により処理されてもよい。また、上述した各処理部の機能は、後述するＣＰＵ５０１（後述の図１４参照）が実行するゲームプログラムにより実装されるものであるが、例えばその一部がＡＳＩＣやＦＰＧＡ等の専用集積回路、その他の電気回路等の実際の装置により実装されてもよい。さらに、以上説明した各処理部は、全部がサーバ装置５側に実装される場合に限定されるものではなく、その一部又は全部が端末装置３側に実装されてもよい。

＜３．サーバが実行する処理手順＞
次に、図１０を用いて、サーバ装置５のＣＰＵ５０１によって実行される処理手順の一例について説明する。

ステップＳ１０では、サーバ装置５は、パーティに属する複数のゲームキャラクタを操作する複数のプレイヤの少なくとも１人から、討伐対象となる敵キャラクタを指定する操作を受け付けて、当該受け付けた操作内容に基づいてパーティで討伐する敵キャラクタを決定する。

ステップＳ２０では、サーバ装置５は、報酬指定受付処理部１５により、上記パーティに属する各プレイヤから、当該パーティが敵キャラクタを倒してアイテムを取得した場合に受け取りたいアイテムを指定する操作を受け付ける。

ステップＳ３０では、サーバ装置５は、情報登録処理部１７により、上記ステップＳ２０で受け付けた操作内容に基づいて、どのプレイヤがどのアイテムを要望しているかを表すアイテム要望リストを生成して登録する。

ステップＳ４０では、サーバ装置５は、パーティがステップＳ１０で決定した敵キャラクタと戦闘して討伐したか否かを判定する。敵キャラクタを倒していない場合には（ステップＳ４０：ＮＯ）、本ステップを繰り返し、敵キャラクタを倒した場合には（ステップＳ４０：ＹＥＳ）、ステップＳ５０に移る。

ステップＳ５０では、サーバ装置５は、討伐した敵キャラクタがアイテムをドロップしたか否かを判定する。アイテムがドロップされなかった場合には（ステップＳ５０：ＮＯ）、本フローチャートを終了する。一方、アイテムがドロップされた場合には（ステップＳ５０：ＹＥＳ）、ステップＳ６０に移る。

ステップＳ６０では、サーバ装置５は、報酬付与処理部１９により、上記ステップＳ３０で登録したアイテム要望リストに基づいて、討伐した敵キャラクタがドロップしたアイテムを付与するプレイヤを決定する。

ステップＳ７０では、サーバ装置５は、報酬付与処理部１９により、上記ステップＳ６０で決定したプレイヤに、討伐した敵キャラクタがドロップしたアイテムを付与する。そして、本フローチャートを終了する。

なお、以上では、敵キャラクタを討伐してアイテムを獲得する場合の処理手順を一例として説明したが、これに限定されるものではなく、例えば所定のミッションやクエストを達成することでアイテムを獲得したり、例えば所定のエリアを攻略することでアイテムを獲得する場合に適用してもよい。これらの場合には、上記ステップＳ１０において、クリア対象のミッションやエリアを決定し、上記ステップＳ２０において、各プレイヤから、パーティがミッションやエリアをクリアした場合に受け取りたいアイテムを指定する操作を受け付け、上記ステップＳ４０及びステップＳ５０において、パーティがミッションやエリアをクリアしたか否かを判定すればよい。

また、上述した処理手順は一例であって、上記手順の少なくとも一部を削除又は変更してもよいし、上記以外の手順を追加してもよい。また、上記手順の少なくとも一部の順番を変更してもよいし、複数の手順が単一の手順にまとめられてもよい。

＜４．実施形態の効果＞
本実施形態のゲームプログラムは、複数の端末装置３と通信可能に接続されたサーバ装置５を、所定のパーティに属する複数のゲームキャラクタを操作する複数のプレイヤの少なくとも１人から、パーティがアイテムを取得した場合に受け取りたいアイテムを指定する操作を、パーティがアイテムを取得する前に受け付ける報酬指定受付処理部１５、受け付けた操作内容に基づいて、どのプレイヤがどのアイテムを要望しているかを表すアイテム要望リストを登録する情報登録処理部１７、パーティがアイテムを取得した際に、当該アイテムをアイテム要望リストに基づいて決定したプレイヤに付与する報酬付与処理部１９、として機能させる。

オンラインゲームにおいて、複数のプレイヤにより操作される複数のゲームキャラクタが属するパーティが敵キャラクタを倒してアイテムを取得した場合に、当該アイテムがパーティの一部のメンバに付与される場合がある。アイテムが付与されるメンバは、例えばランダムに、あるいは、敵キャラクタを倒した際に攻撃に成功した者等の一定のルールにしたがって決定される。

しかしながら、この場合には、パーティが取得したアイテムが、当該アイテムを要望するプレイヤには付与されず、要望していないプレイヤに付与される可能性がある。このため、欲しいアイテムを入手するために何度も同じ敵キャラクタを討伐する必要が生じる等、プレイヤの負担の増大を招く可能性がある。

本実施形態では、パーティがアイテムを取得する前に、プレイヤから受け取りたいアイテムを指定する操作を受け付け、どのプレイヤがどのアイテムを要望しているかを表すアイテム要望リストを予め登録しておく。そして、パーティがアイテムを取得した際に、当該アイテムをアイテム要望リストに基づいて決定したプレイヤに付与する。これにより、パーティが取得したアイテムを、当該アイテムを要望するプレイヤに付与することが可能となるので、プレイヤは要望するアイテムを効率良く入手することができる。また、欲しいアイテムを入手するためのプレイヤの負担を軽減できるので、プレイヤがアイテムの入手を途中で諦めることを防止でき、プレイヤのモチベーションを維持することができる。

なお、例えばパーティがアイテムを取得した際に、プレイヤから当該アイテムを受け取るか否かを指定する操作をその場で受け付けて、アイテムを付与するプレイヤを決定するゲームシステムも考えられる。しかしながら、このゲームシステムの場合には、アイテムを取得したその場で各プレイヤの意思を確認することとなるために、予想外のプレイヤがアイテムを欲しがったり、当該アイテムを必要とするプレイヤ以外のプレイヤが横取りをする等が生じうり、プレイヤ間でトラブルが発生する要因となる。本実施形態では、パーティがアイテムを取得する前に事前にアイテム要望リストを生成するため、他のメンバのアイテム指定状況を把握したり、パーティに属するメンバの合意を得た上で登録すること等が可能となるため、そのようなトラブルの発生を防止できる。

また、本実施形態では特に、報酬付与処理部１９は、アイテム要望リストが、１種類のアイテムを１人のプレイヤが要望していることを表す場合には、パーティが上記１種類のアイテムを取得した際に、当該アイテムを上記１人のプレイヤに付与する。

これにより、上記１人のプレイヤは、パーティが上記１種類のアイテムを取得した際に、当該アイテムを確実に受け取ることができる。したがって、例えばパーティの中に敵キャラクタが１個だけドロップするアイテムをどうしても欲しいプレイヤが１人いるような場合に、本実施形態は有効である。また、例えば敵キャラクタが同じ種類のアイテムを複数個ドロップする場合には、上記プレイヤが１人で全部受け取ることができる。このため、例えば特定のプレイヤが所定のアイテムを生成するために大量の素材を集めているような場合には、本実施形態は特に有効である。

また、本実施形態では特に、報酬付与処理部１９は、アイテム要望リストが、１種類のアイテムを複数のプレイヤが要望していることを表す場合には、パーティが上記１種類のアイテムを取得した際に、当該アイテムを上記複数のプレイヤの中からランダムに決定したプレイヤに付与する。

これにより、パーティが上記１種類のアイテムを取得した際に、当該アイテムを要望する複数のプレイヤのうちランダムで決定された１人のプレイヤが、上記１種類のアイテムを受け取ることができる。したがって、例えばパーティの中に敵キャラクタがドロップする１種類のアイテムを欲しいプレイヤが複数人いるような場合に、本実施形態は有効である。例えば、新しい敵キャラクタがリリースされた直後等においては、当該敵キャラクタがドロップするアイテム等を多くのプレイヤが欲しがることから、本実施形態は特に有効である。また、既にアイテムを入手し終えたプレイヤは当該アイテムを指定しないことによって自分に付与されることを防止できるので、アイテムを要望するプレイヤが受け取る可能性が高まり、欲しいアイテムを効率良く入手することができる。

また、本実施形態では特に、報酬付与処理部１９は、アイテム要望リストが、複数種類のアイテムを複数のプレイヤが要望していることを表す場合には、パーティが上記複数種類のアイテムを取得した際に、上記複数種類の中の一の種類のアイテムを複数のプレイヤが要望している場合には上記一の種類のアイテムを上記複数のプレイヤの中からランダムに決定したプレイヤに付与し、上記一の種類のアイテムを１人のプレイヤが要望している場合には上記一の種類のアイテムを上記１人のプレイヤに付与する。

これにより、パーティが上記複数種類のアイテムを取得した際に、複数種類の中の一の種類のアイテムを複数のプレイヤが要望している場合にはその中からランダムで決定された１人のプレイヤが、上記一の種類のアイテムを受け取ることができる。また、上記一の種類のアイテムを１人のプレイヤのみが要望している場合には、当該１人のプレイヤは上記一の種類のアイテムを確実に受け取ることができる。このようにして、複数種類のアイテムを取得した場合に複数のプレイヤに最適化して配分することができる。したがって、例えば野良パーティを構成した場合等、各プレイヤが全種類のアイテムを指定したような場合に、本実施形態は有効である。また、知り合いや友人等でパーティを構成する場合には、強いプレイヤや既にアイテムを入手し終えたプレイヤは当該アイテムを指定しないので、アイテムを要望するプレイヤが受け取る可能性が高まり、欲しいアイテムを効率良く入手することができる。

また、本実施形態では特に、報酬付与処理部１９は、アイテム要望リストが、複数種類のアイテムを１人のプレイヤが要望していることを表す場合には、パーティが上記複数種類のアイテムを取得した際に、当該複数種類のアイテムを上記１人のプレイヤに付与する。

これにより、上記１人のプレイヤは、パーティが複数種類のアイテムを取得した際に、当該複数種類のアイテムの全部を確実に受け取ることができる。したがって、パーティの中に例えば初心者やレベルの低いプレイヤがおり、当該プレイヤが操作するゲームキャラクタに全部のアイテムを付与して育成したいような場合に、本実施形態は特に有効である。その結果、プレイヤが初心者やライトユーザ等である場合でも、気軽にパーティに参加できるようになり、オンラインゲームを活性化できる。

また、本実施形態では特に、報酬指定受付処理部１５は、複数のプレイヤの少なくとも１人から、パーティが倒した敵キャラクタがアイテムをドロップした場合に受け取りたいアイテムを指定する操作を、パーティが敵キャラクタと戦闘する前に受け付け、情報登録処理部１７は、受け付けた操作内容に基づいて、アイテム要望リストをパーティが敵キャラクタと戦闘する前に登録し、報酬付与処理部１９は、パーティが倒した敵キャラクタがアイテムをドロップした際に、当該アイテムをアイテム要望リストに基づいて決定したプレイヤに付与する。

これにより、パーティが敵キャラクタから取得したアイテムを、当該アイテムを要望するプレイヤに付与することが可能となるので、プレイヤは要望するアイテムを効率良く入手することができる。また、各々のプレイヤが欲しいアイテムを入手するためにパーティで何度も同じ敵キャラクタを討伐する等の必要性が減少するので、欲しいアイテムを入手するためのプレイヤの負担を軽減できる。その結果、プレイヤがアイテムの入手を途中で諦めることを防止でき、プレイヤのモチベーションを維持することができる。

＜５．変形例等＞
なお、本発明は、上記の実施形態に限られるものではなく、その趣旨及び技術的思想を逸脱しない範囲内で種々の変形が可能である。

例えば、上記実施形態では、最初にパーティでアイテムを取得する対象（例えば敵キャラクタ、ミッション、エリア等）を決定した後に、当該対象について各プレイヤが受け取りたいアイテムを指定するようにしたが、これに限定されるものではない。例えば、様々なアイテム取得対象を含めたアイテム指定一覧画面を用意しておき、各プレイヤが適宜のタイミングで様々なアイテム取得対象について受け取りたいアイテムを指定できるようにしてもよい。

図１１に、アイテム指定一覧画面の一例を示す。図１１に示す例では、アイテム指定一覧画面３７に、例えばゲーム内のエリア（この例ではエリアＡ、エリアＢ等）ごとに、アイテムの入手方法（この例ではミッションの達成、宝箱、敵キャラクタの討伐、ダンジョンの攻略等）、アイテムの種類（この例ではアイテムａ～ｅ）、入手可能な個数、及びアイテムごとに設けられた「受け取る」ボタン３９が表示されている。各プレイヤは、パーティが入手方法により取得した場合に受け取りたいアイテムがある場合には、当該アイテムの「受け取る」ボタン３９を操作してアイテムを指定することができる。なお、アイテムの指定は１個又は複数個の指定が可能である。

なお、上記ではエリアごとに分けてアイテムを表示したが、これ以外にも、例えばパーティやゲームキャラクタのパラメータ（レベル、強さ等）、ゲーム中のストーリの区切り（レベル、章、チャプタ等）等、他の種類の区分によってアイテムを分けて表示してもよい。

図１２に、アイテム要望一覧リストの一例を示す。図１２に示すアイテム要望一覧リスト４１（報酬要望情報の一例）は、どのプレイヤがどのアイテムを要望しているかをアイテムごとに表している。図１２に示す例では、アイテムｃ，ｄについては要望するプレイヤが１人であるため、報酬付与処理部１９は、パーティがアイテムｃ，ｄを取得した場合際には、該当するプレイヤＡ，Ｃにそれぞれ付与する。一方、アイテムａ，ｂ，ｅについては要望するプレイヤが複数であるため、報酬付与処理部１９は、パーティがアイテムａ，ｂ，ｅを取得した場合には、該当するプレイヤの中からランダムに決定した１人のプレイヤに付与する。

図１３に、本変形例のサーバ装置５のＣＰＵ５０１によって実行される処理手順の一例を示す。

ステップＳ１１０では、サーバ装置５は、報酬指定受付処理部１５により、パーティに属する各プレイヤから、当該パーティがアイテムを取得した場合に受け取りたいアイテムを指定する操作を受け付ける。当該指定操作は、各プレイヤによりアイテム指定一覧画面３７を用いて行われる。また、当該指定操作は、各プレイヤが任意のタイミングで行えるようにしてもよいし、例えばゲームの進捗度やパーティ（ゲームキャラクタ）の成長度等に応じて、所定の区分（例えばエリア、パーティやゲームキャラクタのパラメータ、ゲーム中のストーリの区切り等）ごとに指定できるようにしてもよい。

ステップＳ１２０では、サーバ装置５は、情報登録処理部１７により、上記ステップＳ１１０で受け付けた操作内容に基づいて、どのプレイヤがどのアイテムを要望しているかを表すアイテム要望一覧リスト４１を生成して登録する。

ステップＳ１３０では、サーバ装置５は、パーティがアイテムを取得したか否かを判定する。アイテムを取得していない場合には（ステップＳ１３０：ＮＯ）、本ステップを繰り返し、アイテムを取得した場合には（ステップＳ１３０：ＹＥＳ）、ステップＳ１４０に移る。

ステップＳ１４０では、サーバ装置５は、パーティが取得したアイテムが上記ステップＳ１２０で登録したアイテム要望一覧リスト４１に含まれるか否かを判定する。取得したアイテムがアイテム要望一覧リスト４１に含まれない場合には（ステップＳ１４０：ＮＯ）、ステップＳ１５０に移り、アイテムを付与するプレイヤをランダムに決定する。その後、後述のステップＳ１７０に移る。一方、取得したアイテムがアイテム要望一覧リスト４１に含まれる場合には（ステップＳ１４０：ＹＥＳ）、ステップＳ１６０に移る。

ステップＳ１６０では、サーバ装置５は、報酬付与処理部１９により、上記ステップＳ１２０で登録したアイテム要望一覧リスト４１に基づいて、取得したアイテムを付与するプレイヤを決定する。

ステップＳ１７０では、サーバ装置５は、報酬付与処理部１９により、上記ステップＳ１６０で決定したプレイヤに、パーティが取得したアイテムを付与する。そして、本フローチャートを終了する。

以上説明した変形例によっても、上記実施形態と同様の効果を得ることができる。また、一度に多数のアイテム取得対象（入手方法）に対して各プレイヤが受け取りたいアイテムを予め指定することができるので、パーティで所定の行動（敵キャラクタの討伐等）を実行する度にアイテムを指定する必要が無くなり、プレイヤの負担を軽減できると共に、ゲームの操作性を向上できる。

また、以上既に述べた以外にも、上記実施形態や各変形例による手法を適宜組み合わせて利用しても良い。その他、一々例示はしないが、上記実施形態や各変形例は、その趣旨を逸脱しない範囲内において、種々の変更が加えられて実施されるものである。

＜６．サーバのハードウェア構成＞
次に、図１４を用いて、上記で説明したＣＰＵ５０１が実行するプログラムにより実装された各処理部を実現するサーバ装置５のハードウェア構成の一例について説明する。なお、端末装置３が同様のハードウェア構成を有してもよい。

図１４に示すように、サーバ装置５は、例えば、ＣＰＵ５０１と、ＲＯＭ５０３と、ＲＡＭ５０５と、ＧＰＵ５０６と、例えばＡＳＩＣ又はＦＰＧＡ等の特定の用途向けに構築された専用集積回路５０７と、入力装置５１３と、出力装置５１５と、記録装置５１７と、ドライブ５１９と、接続ポート５２１と、通信装置５２３を有する。これらの構成は、バス５０９や入出力インターフェース５１１等を介し相互に信号を伝達可能に接続されている。

ゲームプログラムは、例えば、ＲＯＭ５０３やＲＡＭ５０５、ハードディスク等の記録装置５１７等に記録しておくことができる。

また、ゲームプログラムは、例えば、フレキシブルディスクなどの磁気ディスク、各種のＣＤ、ＭＯディスク、ＤＶＤ等の光ディスク、半導体メモリ等のリムーバブルな記録媒体５２５に、一時的又は永続的（非一時的）に記録しておくこともできる。このような記録媒体５２５は、いわゆるパッケージソフトウエアとして提供することもできる。この場合、これらの記録媒体５２５に記録されたゲームプログラムは、ドライブ５１９により読み出されて、入出力インターフェース５１１やバス５０９等を介し上記記録装置５１７に記録されてもよい。

また、ゲームプログラムは、例えば、ダウンロードサイト、他のコンピュータ、他の記録装置等（図示せず）に記録しておくこともできる。この場合、ゲームプログラムは、ＬＡＮやインターネット等のネットワークＮＷを介し転送され、通信装置５２３がこのプログラムを受信する。そして、通信装置５２３が受信したプログラムは、入出力インターフェース５１１やバス５０９等を介し上記記録装置５１７に記録されてもよい。

また、ゲームプログラムは、例えば、適宜の外部接続機器５２７に記録しておくこともできる。この場合、ゲームプログラムは、適宜の接続ポート５２１を介し転送され、入出力インターフェース５１１やバス５０９等を介し上記記録装置５１７に記録されてもよい。

そして、ＣＰＵ５０１が、上記記録装置５１７に記録されたプログラムに従い各種の処理を実行することにより、前述の報酬指定受付処理部１５、情報登録処理部１７、報酬付与処理部１９等による処理が実現される。この際、ＣＰＵ５０１は、例えば、上記記録装置５１７からプログラムを、直接読み出して実行してもよく、ＲＡＭ５０５に一旦ロードした上で実行してもよい。更にＣＰＵ５０１は、例えば、プログラムを通信装置５２３やドライブ５１９、接続ポート５２１を介し受信する場合、受信したプログラムを記録装置５１７に記録せずに直接実行してもよい。

また、ＣＰＵ５０１は、各端末装置３のゲームコントローラ７からネットワークＮＷを介して入力される信号に加えて、必要に応じて、例えばマウス、キーボード、マイク等の入力装置５１３から入力する信号や情報に基づいて各種の処理を行ってもよい。

ＧＰＵ５０６は、ＣＰＵ５０１からの指示に応じて例えばレンダリング処理などの画像表示のための処理を行う。

そして、ＣＰＵ５０１及びＧＰＵ５０６は、上記の処理を実行した結果を、ネットワークＮＷを介して各端末装置３の表示装置９に出力すると共に、必要に応じて、例えばスピーカーやヘッドフォン等の音声出力部（図示せず）を含む、出力装置５１５から出力する。さらにＣＰＵ５０１及びＧＰＵ５０６は、必要に応じてこの処理結果を通信装置５２３や接続ポート５２１を介し送信してもよく、上記記録装置５１７や記録媒体５２５に記録させてもよい。

３ 端末装置
５ サーバ装置（情報処理装置）
１５ 報酬指定受付処理部
１７ 情報登録処理部
１９ 報酬付与処理部
２９ アイテム要望リスト（報酬要望情報）
３１ アイテム要望リスト（報酬要望情報）
３３ アイテム要望リスト（報酬要望情報）
３５ アイテム要望リスト（報酬要望情報）
４１ アイテム要望一覧リスト（報酬要望情報）

Claims (8)

1. 複数の端末装置と通信可能に接続された情報処理装置を、
   所定のゲーム内グループに属する複数のゲームキャラクタを操作する複数のプレイヤの少なくとも１人から、前記ゲーム内グループが報酬を取得しようとする取得対象を指定する操作を受け付けて決定する取得対象決定処理部、
   前記複数のプレイヤの少なくとも１人から、前記ゲーム内グループが前記取得対象から前記報酬を取得した場合に前記複数のプレイヤの各々が受け取りたい前記報酬を前記取得対象ごとに設定された報酬リストから指定する操作を、前記ゲーム内グループが前記報酬を取得する前に受け付ける報酬指定受付処理部、
   受け付けた操作内容に基づいて、どのプレイヤがどの報酬を要望しているかを表す報酬要望情報を登録する情報登録処理部、
   前記ゲーム内グループが前記報酬を取得した際に、当該報酬を前記報酬要望情報に基づいて決定した前記プレイヤに付与する報酬付与処理部、
   として機能させる、ゲームプログラム。
2. 前記報酬付与処理部は、
   前記報酬要望情報が、１種類の第１の報酬を１人の第１のプレイヤが要望していることを表す情報である場合には、前記ゲーム内グループが前記第１の報酬を取得した際に、当該第１の報酬を前記第１のプレイヤに付与する、
   請求項１に記載のゲームプログラム。
3. 前記報酬付与処理部は、
   前記報酬要望情報が、１種類の第２の報酬を複数の第２のプレイヤが要望していることを表す情報である場合には、前記ゲーム内グループが前記第２の報酬を取得した際に、当該第２の報酬を前記複数の第２のプレイヤの中からランダムに決定した前記第２のプレイヤに付与する、
   請求項１又は２に記載のゲームプログラム。
4. 前記報酬付与処理部は、
   前記報酬要望情報が、複数種類の第３の報酬を複数の第３のプレイヤが要望していることを表す情報である場合には、前記ゲーム内グループが前記複数種類の第３の報酬を取得した際に、前記複数種類の中の一の種類の前記第３の報酬を複数の前記第３のプレイヤが要望している場合には前記一の種類の第３の報酬を前記複数の第３のプレイヤの中からランダムに決定した前記第３のプレイヤに付与し、前記一の種類の前記第３の報酬を１人の前記第３のプレイヤが要望している場合には前記一の種類の第３の報酬を前記１人の第３のプレイヤに付与する、
   請求項１乃至３のいずれか１項に記載のゲームプログラム。
5. 前記報酬付与処理部は、
   前記報酬要望情報が、複数種類の第４の報酬を１人の第４のプレイヤが要望していることを表す情報である場合には、前記ゲーム内グループが前記複数種類の第４の報酬を取得した際に、当該複数種類の第４の報酬を前記第４のプレイヤに付与する、
   請求項１乃至４のいずれか１項に記載のゲームプログラム。
6. 前記報酬指定受付処理部は、
   前記複数のプレイヤの少なくとも１人から、前記ゲーム内グループが倒した敵キャラクタがアイテムをドロップした場合に受け取りたい前記アイテムを指定する操作を、前記ゲーム内グループが前記敵キャラクタと戦闘する前に受け付け、
   前記情報登録処理部は、
   受け付けた操作内容に基づいて、前記報酬要望情報を前記ゲーム内グループが前記敵キャラクタと戦闘する前に登録し、
   前記報酬付与処理部は、
   前記ゲーム内グループが倒した前記敵キャラクタが前記アイテムをドロップした際に、当該アイテムを前記報酬要望情報に基づいて決定した前記プレイヤに付与する、
   請求項１乃至５のいずれか１項に記載のゲームプログラム。
7. 複数の端末装置と通信可能に接続された情報処理装置によって実行されるゲーム処理方法であって、
   所定のゲーム内グループに属する複数のゲームキャラクタを操作する複数のプレイヤの少なくとも１人から、前記ゲーム内グループが報酬を取得しようとする取得対象を指定する操作を受け付けて決定するステップと、
   前記複数のプレイヤの少なくとも１人から、前記ゲーム内グループが前記取得対象から前記報酬を取得した場合に前記複数のプレイヤの各々が受け取りたい前記報酬を前記取得対象ごとに設定された報酬リストから指定する操作を、前記ゲーム内グループが前記報酬を取得する前に受け付けるステップと、
   受け付けた操作内容に基づいて、どのプレイヤがどの報酬を要望しているかを表す報酬要望情報を登録するステップと、
   前記ゲーム内グループが前記報酬を取得した際に、当該報酬を前記報酬要望情報に基づいて決定した前記プレイヤに付与するステップと、
   を有する、ゲーム処理方法。
8. 複数の端末装置と通信可能に接続された情報処理装置であって、
   所定のゲーム内グループに属する複数のゲームキャラクタを操作する複数のプレイヤの少なくとも１人から、前記ゲーム内グループが報酬を取得しようとする取得対象を指定する操作を受け付けて決定する取得対象決定処理部と、
   前記複数のプレイヤの少なくとも１人から、前記ゲーム内グループが前記取得対象から前記報酬を取得した場合に前記複数のプレイヤの各々が受け取りたい前記報酬を前記取得対象ごとに設定された報酬リストから指定する操作を、前記ゲーム内グループが前記報酬を取得する前に受け付ける報酬指定受付処理部と、
   受け付けた操作内容に基づいて、どのプレイヤがどの報酬を要望しているかを表す報酬要望情報を登録する情報登録処理部と、
   前記ゲーム内グループが前記報酬を取得した際に、当該報酬を前記報酬要望情報に基づいて決定した前記プレイヤに付与する報酬付与処理部と、
   を有する、情報処理装置。

Images