JP5291823B1 - ゲーム管理サーバ装置、ゲーム管理サーバ装置用プログラム、および、端末装置用プログラム - Google Patents

Abstract

【課題】ゲーム世界におけるプレイヤ間のバランスを確保できる仕組みを提供する。
【解決手段】プレイヤが操作する複数の端末装置１がネットワークを介して接続され、端末装置１にゲームサービスを提供するソーシャルゲーム管理サーバ４であって、プレイヤ間を関連付けて登録し、プレイヤ間の関連付けを管理するプレイヤ管理手段と、ゲーム内において、所定のイベントを発生させる制御を行うイベント発生制御手段と、各プレイヤの強さパラメータを管理するプレイヤ強さパラメータ管理手段とを備え、イベント発生制御手段は、プレイヤ強さパラメータ管理手段により管理される各プレイヤの強さパラメータを参照することで、プレイヤ管理手段において相互に関連付けられて登録された各プレイヤの強さパラメータの優劣を判定し、判定結果に基づいてイベントの発生を制御する。
【選択図】図４

Description

本発明は、ソーシャルゲーム（ソーシャルネットワークゲーム）等の制御技術に関する。

ソーシャルゲームは、ソーシャルネットワーキングサービス（ＳＮＳ）上で提供され、他のプレイヤとコミュニケーションをとりながらプレイするオンラインゲームである（例えば、非特許文献１を参照。）。従前のオンラインゲームにも他のプレイヤとコミュニケーションをとる機能が設けられているものはあるが、ソーシャルゲームはコミュニケーションを本来の目的としたＳＮＳ上に設けられている点で高いコミュニケーション性を有している。

また、ソーシャルゲームの１ジャンルとして、ソーシャルＲＰＧ（Role Playing Game）ゲームがある。ソーシャルＲＰＧゲームでは、ゲーム進行の一局面として、マップの所定のエリア内を進行していくクエスト（ミッション）がある。

このクエストにおいては、プレイヤ（ユーザ）が操作するキャラクタが、行動力ポイントを消費しながら所定のエリア内を進む最中に種々のイベントが出現する。例えば、途中で敵と遭遇してその敵を倒したり、ボーナスアイテムに遭遇することで魔法や技等の能力を習得したりする。また、ボスが配置されたエリア内でクエストをクリアするとボスが出現し、ボスと戦闘する。ボスを倒すと武器や報酬が得られる。

このように、プレイヤは、所定のイベントを通じて、能力や武器、報酬等を得られることを期待しながらクエストを進めることになる。

特に、ボスとの遭遇は、ゲームにおいて重要な局面であり、プレイヤはボスの出現を楽しみにゲームをプレイする。

通常、ボスには、強さや出現頻度に応じて、ノーマル（Ｎ）、レア（Ｒ）、スーパーレア（ＳＲ）といったランクが設定されている。ランクが高いボスを倒すほど、強い武器や高い報酬を取得することができる。

「怪盗ロワイヤル公式ガイドブック」（２０１０年１２月２９日第１刷発行 株式会社宝島社）

上述したように、プレイヤはボスを含むイベントの出現を大事な局面として捉えているが、ゲーム世界においては、強いプレイヤと弱いプレイヤが存在するため、強いプレイヤはランクの高いボスを容易に倒し、弱いプレイヤはランクの低いボスでさえ倒すことが困難な状況が生じうる。ただし、プレイヤが単独でプレイしている場合には問題はない。単に、強いボスであるとか弱いボスであるとかと認識するだけだからである。同様に、プレイヤの戦況の優劣に関わらずに、出現するボスが固定されているとしても、プレイヤが単独でプレイしている場合には問題はない。

しかし、ソーシャルゲームでは他のプレイヤと頻繁にコミュニケーションが行われ、また、チームを組んで他のチームと競う形態もあるため、どのボスはどの程度で倒せたかといったことを知ってしまうことが多い。そのため、プレイヤ間のレベル差が拡大し、ゲーム世界におけるプレイヤ間のバランスが崩れ、結果としてゲーム自体の面白みが低減する可能性も生じうる。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、ゲーム世界におけるプレイヤ間のバランスを確保できる仕組みを提供することにある。

上記の課題を解決するため、本発明にあっては、プレイヤが操作する複数の端末装置がネットワークを介して接続され、前記端末装置に全プレイヤが管理されるソーシャルＲＰＧであって、プレイヤ同士が直接には対戦せずに、少なくともゲームの獲得ポイントにより競い合うゲームサービスを提供するゲーム管理サーバ装置であって、プレイヤ間を関連付けて登録し、プレイヤ間の関連付けを管理するプレイヤ管理手段と、ゲーム内において、所定のイベントを発生させる制御を行うイベント発生制御手段と、各プレイヤの強さパラメータを管理するプレイヤ強さパラメータ管理手段とを備え、前記イベント発生制御手段は、前記プレイヤ強さパラメータ管理手段により管理される各プレイヤの強さパラメータを参照することで、前記プレイヤ管理手段において相互に関連付けられて登録された各プレイヤの強さパラメータの優劣を判定し、プレイヤの強さパラメータの優劣に対して候補となる複数のイベントのタイプおよび重みが対応付けられたテーブルを参照し、プレイヤの強さパラメータの優劣が該当する複数のイベントのタイプにつき設定された重みにより抽選を行ってイベントのタイプを決定し、決定したイベントのタイプに基づいてイベントの発生を制御するようにしている。

本発明のゲーム管理サーバ装置、ゲーム管理サーバ装置用プログラム、および、端末装置用プログラムにあっては、ゲーム世界におけるプレイ間のバランスを確保することができる。

本発明の一実施形態にかかるシステムの構成例を示す図である。 端末装置のハードウェア構成例を示す図である。 ソーシャルゲーム管理サーバのハードウェア構成例を示す図である。 端末装置およびソーシャルゲーム管理サーバの機能構成例を示す図である。 プレイヤ情報のデータ構造例を示す図である。 シナリオ情報のデータ構造例を示す図である。 発生イベント決定テーブルのデータ構造例を示す図である。 イベント属性管理テーブルのデータ構造例を示す図である。 実施形態の処理例を示すフローチャート（その１）である。 実施形態の処理例を示すフローチャート（その２）である。

以下、本発明の好適な実施形態につき説明する。

＜構成＞
図１は本発明の一実施形態にかかるシステムの構成例を示す図である。

図１において、システムは、プレイヤ（ユーザ）が所持するスマートフォン、携帯電話等の端末装置１と、移動無線基地局やＷｉ−Ｆｉステーション等のアクセスポイント２と、インターネット等のネットワーク３と、複数のプレイヤがネットワークを介してゲームプレイを行うソーシャルゲームの管理（制御）を行うソーシャルゲーム管理サーバ４とを備えている。

図２は端末装置１のハードウェア構成例を示す図である。

図２において、端末装置１は、電源システム１０１と、プロセッサ１０３、メモリコントローラ１０４、周辺インタフェース１０５を含むメインシステム１０２と、記憶部１０６と、外部ポート１０７と、高周波回路１０８と、アンテナ１０９と、オーディオ回路１１０と、スピーカ１１１と、マイク１１２と、近接センサ１１３と、ディスプレイコントローラ１１５、光学センサコントローラ１１６、入力コントローラ１１７を含むＩ／Ｏサブシステム１１４と、タッチ反応型ディスプレイシステム１１８と、光学センサ１１９と、入力部１２０とを備えている。

図３はソーシャルゲーム管理サーバ４のハードウェア構成例を示す図である。

図３において、ソーシャルゲーム管理サーバ４は、システムバス４０１に接続されたＣＰＵ（Central Processing Unit）４０２、ＲＯＭ（Read Only Memory）４０３、ＲＡＭ（Random Access Memory）４０４、ＮＶＲＡＭ（Non-Volatile Random Access Memory）４０５、Ｉ／Ｆ（Interface）４０６と、Ｉ／Ｆ４０６に接続された、キーボード、マウス、モニタ、ＣＤ／ＤＶＤ（Compact Disk/Digital Versatile Disk）ドライブ等のＩ／Ｏ（Input/Output Device）４０７、ＨＤＤ（Hard Disk Drive）４０８、ＮＩＣ（Network Interface Card）４０９等を備えている。

図４は端末装置１およびソーシャルゲーム管理サーバ４の機能構成例を示す図である。

図４において、端末装置１は、プレイヤ操作入力部１１とゲームロジック実行部１２とサーバアクセス部１３と画面表示部１４とを備えている。

プレイヤ操作入力部１１は、端末装置１を操作するプレイヤ（ユーザ）からの操作を入力（受付）する機能を有している。

ゲームロジック実行部１２は、プレイヤ操作入力部１１により入力されたプレイヤの操作に応じ、画面遷移を行ってゲームを進行する機能を有している。

サーバアクセス部１３は、ゲームロジック実行部１２の処理の過程でソーシャルゲーム管理サーバ４へのアクセスが必要になった場合に、ソーシャルゲーム管理サーバ４に対してリクエストを送信し、処理結果等をレスポンスとして受信する機能を有している。ここで、リクエストとしては、更新系と参照系とがある。更新系のリクエストは、プレイヤ情報の更新を伴うものである。参照系のリクエストは、プレイヤ情報を参照するものである。

画面表示部１４は、ゲームロジック実行部１２の制御のもと、画面表示を行う機能を有している。

一方、ソーシャルゲーム管理サーバ４は、リクエスト処理部４１とプレイヤ情報管理部４２とプレイヤ情報データベース４３とクエスト／イベント管理部４４とクエスト／イベント情報保持部４５とを備えている。

リクエスト処理部４１は、端末装置１からのリクエストを受信して対応する処理を行い、リクエストの処理結果をレスポンスとして端末装置１に送信する機能を有している。更新系のリクエストであればプレイヤ情報の更新を伴う処理を行ない、処理により変更されたプレイヤ情報等を処理結果とする。参照系のリクエストであれば該当するプレイヤ情報を参照し、取得したプレイヤ情報の値を処理結果とする。また、レスポンスには、要求された処理結果だけではなく、次にプレイヤが操作対象とすることのできる画面情報が含まれる。

プレイヤ情報管理部４２は、ゲームに参加している全プレイヤの各種の情報をプレイヤ情報データベース４３に保持して管理する機能を有しており、リクエスト処理部４１もしくはクエスト／イベント管理部４４からの要求に応じてプレイヤ情報の参照もしくは更新を行う。プレイヤ情報のデータ構造例については後述する。

クエスト／イベント管理部４４は、クエスト／イベント情報保持部４５にシナリオ情報、発生イベント決定テーブルおよびイベント属性管理テーブル等を保持して管理する機能を有している。リクエスト処理部４１は、端末装置１から受信したリクエストに基づき、クエスト／イベント管理部４４を介してクエスト／イベント情報保持部４５に保持したシナリオ情報、発生イベント決定テーブルおよびイベント属性管理テーブル等の情報を取得・更新し、端末装置１でのゲーム進行に応じてクエストやイベントの発生を制御する。シナリオ情報、発生イベント決定テーブルおよびイベント属性管理テーブルのデータ構造例については後述する。

図５はプレイヤ情報データベース４３に保持されるプレイヤ情報のデータ構造例を示す図である。

図５において、プレイヤ情報は、「プレイヤＩＤ」「アイコン情報」「プレイヤ名」「プレイヤ強さ」「チーム」「ステータス」「イベント発生状況」「対戦履歴」「点数」等の項目（フィールド）を有している。

「プレイヤＩＤ」は、プレイヤを特定する情報である。「アイコン情報」は、当該プレイヤの表示アイコンを特定する情報である。「プレイヤ名」は、当該プレイヤの表示名の情報である。「プレイヤ強さ」は、当該プレイヤのゲーム上の強さを示す情報（強さパラメータ）であり、レベル、ＨＰ（Hit Point）、攻撃力、素早さ等を含んでいる。レベルが上がると、ＨＰ、攻撃力、素早さ等の上限値が引き上げられる。

「チーム」は、当該プレイヤが所属するチームおよび対抗（共通のボスを巡って競争）するチームを示す情報である。「ステータス」は、当該プレイヤのゲーム進行状況を示す情報である。「イベント発生状況」は、当該プレイヤに対して発生したイベントの状況を示す情報である。なお、「ステータス」に「イベント発生状況」も含まれる場合には、「イベント発生状況」は省略することができる。

「対戦履歴」は、ボス等の対戦を要するイベントにおける対戦結果の情報であり、勝敗と撃破された時間（負けた場合）と制限時間とを含んでいる。「点数」は、当該プレイヤの獲得している点数を示し、バトルの戦況を示すことになる。

図６はクエスト／イベント情報保持部４５に保持されるシナリオ情報のデータ構造例を示す図である。

図６において、シナリオ情報は、ステータス（主にステージ）に選択可能なエリア（クエストが行われるマップ上の領域）が対応付けられている。通常、エリアは攻略が易しいものから難しい順に配列されており、最初は易しいエリアしか選べない。

図７はクエスト／イベント情報保持部４５に保持される発生イベント決定テーブルのデータ構造例を示す図である。

図７において、発生イベント決定テーブルは、「タイムゾーン」「優劣」「ボス発見状態」「ボスタイプ」「重み」等の項目（フィールド）を有している。

「タイムゾーン」は、現在時刻が属する時間帯を特定する情報であり、多数のプレイヤが参加することが予想される「コアタイム」、プレイヤ数が少ないと予想される「非コアタイム」、運営者側のメンテナンスが行われる「メンテナンスタイム」等が含まれる。なお、時刻とタイムゾーンとの対応付けは、図示しないテーブル等により管理される。

「優劣」は、自チームに属するプレイヤの強さの総合値と相手チームに属するプレイヤの強さの総合値とから決まる相対的な優劣を示す情報である。「優勢」「劣勢」という２区分（同等を含めると３区分）に限らず、より細かく強さ・弱さの関係を示す値としてもよい。または、「優劣」は、各チームの戦況の優劣を示す情報であってもよい。

「ボス発見状態」は、自チームおよび相手チームがボスを発見しているか否かを示す情報であり、「自チーム発見済」「相手チームのみ発見」「両チーム未発見」等が含まれる。

「ボスタイプ」は、出現させるボスのランクを含めたボスの種類を示す情報である。「重み」は、ボスを含めたイベントが抽選により決定される確率に応じた値である。

図８はクエスト／イベント情報保持部４５に保持されるイベント属性管理テーブルのデータ構造例を示す図である。

図８において、イベント属性管理テーブルは、対戦する２つのチームの組毎に、ボス等のイベント（個々のイベントを特定してもよいし、イベントの種類のみを特定してもよい）と当該イベントのレベルとが対応付けられている。対戦する２つのチームに対してボス等のイベントを発生する場合、このイベント属性管理テーブルで規定されるレベルに応じた強さに設定される。

＜動作＞
＜処理パターン＃１＞
図９は上記の実施形態の処理例を示すフローチャートである。なお、端末装置１を操作するプレイヤは予めソーシャルゲーム管理サーバ４に対してログインの操作を行ない、ソーシャルゲーム管理サーバ４はプレイヤＩＤを特定できるものとする。

図９において、端末装置１側のプレイヤ操作入力部１１によりプレイヤからのゲーム開始の操作が受け付けられ、ゲームロジック実行部１２がゲーム開始の操作であると認識してサーバアクセス部１３からソーシャルゲーム管理サーバ４にゲーム開始を伝えることで、リクエスト処理部４１はゲーム開始の操作を認識し、処理を開始する（ステップＳ１０１）。

リクエスト処理部４１は、先ず、当該プレイヤによる初回のゲームであるか否か判断する（ステップＳ１０２）。これは、プレイヤＩＤに基づいて、プレイヤ情報管理部４２を介してプレイヤ情報データベース４３のプレイヤ情報（図５）を参照し、該当するプレイヤのステータスが初回以外の値であるか否か判断することで行うことができる。

初回のゲームであると判断した場合（ステップＳ１０２のＹｅｓ）、リクエスト処理部４１は、当該プレイヤをいずれかのチームに割り当ててチーム割り当て画面を端末装置１に表示させる（ステップＳ１０３）。チームの割り当ては、所定のルールに基づいて、または、プレイヤ情報管理部４２を介してプレイヤ情報データベース４３のプレイヤ情報から既割当人数に余裕のあるチームを選択し、当該プレイヤのチームを更新することで行う。チームの割り当ては、プレイヤ間の関連付けとみることができる。割当結果の画面情報が端末装置１に送信され、サーバアクセス部１３により受信されると、ゲームロジック実行部１２の制御のもと、画面表示部１４により表示される。なお、チーム割り当ての実行処理は、チーム割り当て画面やプレイヤの確認等の画面を表示しなくとも、自動的にバックグラウンドでなされてもよい。

次いで、端末装置１のプレイヤ操作入力部１１によりプレイヤによる確認等の操作が受け付けられ、ゲームロジック実行部１２の制御のもと、サーバアクセス部１３からソーシャルゲーム管理サーバ４のリクエスト処理部４１に確認等の操作が伝わることで（ステップＳ１０４）、後続の処理に移行する。

初回のゲームでないと判断した場合（ステップＳ１０２のＮｏ）、チームの割り当ては済んでいるため上記の処理は行わず、前回の中断箇所から処理を再開する（ステップＳ１０５）。処理の再開は、当該プレイヤのプレイヤＩＤに基づいて、プレイヤ情報管理部４２を介してプレイヤ情報データベース４３のプレイヤ情報からステータスを参照し、そのステータスに相当する処理を特定することで行う。

チームの割り当ての確認等（ステップＳ１０４）の後もしくは当該箇所からの再開の場合、リクエスト処理部４１は、クエストを行うエリアを選択させるクエスト開始画面を端末装置１に表示させる（ステップＳ１０６）。すなわち、リクエスト処理部４１は、当該プレイヤのプレイヤＩＤに基づいて、プレイヤ情報管理部４２を介してプレイヤ情報データベース４３のプレイヤ情報を参照し、ステータスを取得する。また、リクエスト処理部４１は、取得したステータスに基づいて、クエスト／イベント管理部４４を介してクエスト／イベント情報保持部４５のシナリオ情報（図６）を参照し、ステータス（ステージ）に対応する選択可能エリアを取得する。そして、リクエスト処理部４１は、取得した選択可能エリアから所望のエリアを選択するクエスト開始画面を生成し、端末装置１に送信する。端末装置１のサーバアクセス部１３がこれを受信すると、ゲームロジック実行部１２の制御のもと、画面表示部１４により表示される。

次いで、端末装置１のプレイヤ操作入力部１１によりプレイヤによるエリア選択の操作が受け付けられ、ゲームロジック実行部１２の制御のもと、サーバアクセス部１３からソーシャルゲーム管理サーバ４のリクエスト処理部４１にエリア選択の操作が伝わることで（ステップＳ１０７）、クエストが開始する。

クエストが開始すると、リクエスト処理部４１は、エリア内をキャラクタが進行する画像を含むクエスト途中画面を端末装置１に表示させる（ステップＳ１０８）。すなわち、リクエスト処理部４１は、クエスト途中画面を端末装置１に送信し、端末装置１のサーバアクセス部１３がこれを受信すると、ゲームロジック実行部１２の制御のもと、画面表示部１４により表示される。

次いで、端末装置１のプレイヤ操作入力部１１によりプレイヤによる進む等の操作が受け付けられ、ゲームロジック実行部１２の制御のもと、サーバアクセス部１３からソーシャルゲーム管理サーバ４のリクエスト処理部４１に進む等の操作が伝わることで（ステップＳ１０９）、後続の処理に移行する。クエスト途中画面が連続する場合は、上記の処理を繰り返す。

次いで、リクエスト処理部４１は、当該プレイヤのプレイヤＩＤに基づいて、プレイヤ情報管理部４２を介してプレイヤ情報データベース４３のプレイヤ情報を参照し、自チームと相手チームを認識した上で、それぞれのチームに属するプレイヤのプレイヤ強さを取得して優劣を取得するとともに、それぞれのチームに属するプレイヤのイベント発生状況を取得してボス発見状態を取得する（ステップＳ１１０）。各チームの強さは、各プレイヤのレベルの合計、平均、最大強さを基に算出し、両チームの強さを比較し、自チームが強ければ「優勢」、自チームが弱ければ「劣勢」とする（強さが同程度であれば「同等」を導入可）。または、「優劣」は、両チームの戦況を比較し、自チームが優勢に進んでいれば「優勢」、自チームが劣勢に進んでいれば「劣勢」とすることもできる。また、ボス発見状態については、例えば、各チームに属するいずれかのプレイヤのイベント発生状況が「ボス発見」であれば、そのチームについてはボス発見とし、自チームのみがボス発見であればボス発見状態を「自チーム発見済」とし、相手チームのみがボス発見であればボス発見状態を「相手チーム発見済」とし、両チームともボス未発見であればボス発見状態を「両チーム未発見」とする。

次いで、リクエスト処理部４１は、現在時刻を取得し、タイムゾーンとの対応付けから現在時刻の属するタイムゾーンを取得する（ステップＳ１１１）。

次いで、リクエスト処理部４１は、上記の処理で取得した優劣とボス発見状態とタイムゾーンに基づき、クエスト／イベント管理部４４を介してクエスト／イベント情報保持部４５の発生イベント決定テーブル（図７）を参照し、ボスタイプと重みを取得する（ステップＳ１１２）。

次いで、リクエスト処理部４１は、取得した重みに比例する確率で抽選を行い、発生させるイベント（ボス）を決定する（ステップＳ１１３）。例えば、優劣が「優勢」でボス発見状態が「自チーム発見済」でタイムゾーンが「コアタイム」の場合、図７の発生イベント決定テーブルの上から２個のレコードが条件に該当し、重みの合計９０＋１０＝１００に対するそれぞれの重みの比を確率とした抽選を行い、いずれかのイベント（ボス）に決定する。

なお、図７の発生イベント決定テーブルでは、自チームが劣勢の場合にレアボスが出やすくなるよう（逆に自チームが優勢の場合はレアボスが出にくくなるよう）に重みが設定されており、相対的に劣勢のチームはレアボスが出現しやすく、これを倒すことにより大きな能力等を得ることが可能になり、相対的に優勢の相手チームとのバランスを解消し、接戦となる方向に作用する。また、ボス発見状態により、自チームが相手チームよりも先にボスを発見している場合には、自チームが強い方向に評価され、それに応じた重みが設定される。タイムゾーンについては、運用方針により重みが設定される。

次いで、リクエスト処理部４１は、上記の処理で決定したイベントの画像を含むイベント画面を端末装置１に表示させる（ステップＳ１１４）。すなわち、リクエスト処理部４１は、イベント画面を端末装置１に送信し、端末装置１のサーバアクセス部１３がこれを受信すると、ゲームロジック実行部１２の制御のもと、画面表示部１４により表示される。

次いで、端末装置１のプレイヤ操作入力部１１によりプレイヤによるイベントに対する操作が受け付けられ、ゲームロジック実行部１２の制御のもと、サーバアクセス部１３からソーシャルゲーム管理サーバ４のリクエスト処理部４１にイベントに対する操作が伝わることで（ステップＳ１１５）、後続の処理に移行する。イベント画面が複数からなる場合は、上記の処理を繰り返す。

その後、プレイヤの操作に応じてイベントに決着が付いた場合、リクエスト処理部４１は、イベントの結果を含むイベント結果画面を端末装置１に表示させる（ステップＳ１１６）。すなわち、リクエスト処理部４１は、イベント結果画面を端末装置１に送信し、端末装置１のサーバアクセス部１３がこれを受信すると、ゲームロジック実行部１２の制御のもと、画面表示部１４により表示される。イベント結果として、魔法や技等の能力を習得したり、武器や報酬が得られたりする。

次いで、端末装置１のプレイヤ操作入力部１１によりプレイヤによる確認等の操作が受け付けられ、ゲームロジック実行部１２の制御のもと、サーバアクセス部１３からソーシャルゲーム管理サーバ４のリクエスト処理部４１に確認等の操作が伝わることで（ステップＳ１１７）、後続の処理に移行する。

その後、リクエスト処理部４１は、クエストが終了したか否か判断する（ステップＳ１１８）。クエストの終了は、エリアの終端に到達したか否かで判断することができる。

クエストが終了していないと判断した場合（ステップＳ１１８のＮｏ）、プレイヤ情報の参照（ステップＳ１１０）に戻る。

クエストが終了したと判断した場合（ステップＳ１１８のＹｅｓ）、クエスト開始画面の表示（ステップＳ１０６）に戻る。

なお、上記の処理において、端末装置１を操作するプレイヤは、操作の前後でゲームを止めることができ、再開した場合は同じ状態からその続きを実行することができる。

また、優劣とボス発見状態とタイムゾーンを用いて発生イベント決定テーブルを参照してイベント（ボス）を決定しているが、優劣が最も重要な要素であり、ボス発見状態とタイムゾーンの一方もしくは両方は省略してもよい。

＜処理パターン＃２＞
上述した処理パターン＃２では自チームと相手チームの優劣等に基づいて発生するイベント（ボス）のタイプを決定したが、この処理パターンでは、ボス等との対戦履歴に基づいてイベント（ボス）のレベルを変更するようにしている。

図１０は実施形態の他の処理例を示すフローチャートである。なお、端末装置１を操作するプレイヤは予めソーシャルゲーム管理サーバ４に対してログインの操作を行ない、ソーシャルゲーム管理サーバ４はプレイヤＩＤを特定できるものとする。

図１０において、端末装置１側のプレイヤ操作入力部１１によりプレイヤからのゲーム開始の操作が受け付けられ、ゲームロジック実行部１２がゲーム開始の操作であると認識してサーバアクセス部１３からソーシャルゲーム管理サーバ４にゲーム開始を伝えることで、リクエスト処理部４１はゲーム開始の操作を認識し、処理を開始する（ステップＳ２０１）。

リクエスト処理部４１は、先ず、当該プレイヤによる初回のゲームであるか否か判断する（ステップＳ２０２）。これは、プレイヤＩＤに基づいて、プレイヤ情報管理部４２を介してプレイヤ情報データベース４３のプレイヤ情報（図５）を参照し、該当するプレイヤのステータスが初回以外の値であるか否か判断することで行うことができる。

初回のゲームであると判断した場合（ステップＳ２０２のＹｅｓ）、リクエスト処理部４１は、当該プレイヤをいずれかのチームに割り当ててチーム割り当て画面を端末装置１に表示させる（ステップＳ２０３）。チームの割り当ては、所定のルールに基づいて、または、プレイヤ情報管理部４２を介してプレイヤ情報データベース４３のプレイヤ情報から既割当人数に余裕のあるチームを選択し、当該プレイヤのチームを更新することで行う。チームの割り当ては、プレイヤ間の関連付けとみることができる。割当結果の画面情報が端末装置１に送信され、サーバアクセス部１３により受信されると、ゲームロジック実行部１２の制御のもと、画面表示部１４により表示される。なお、チーム割り当ての実行処理は、チーム割り当て画面やプレイヤの確認等の画面を表示しなくとも、自動的にバックグラウンドでなされてもよい。

次いで、端末装置１のプレイヤ操作入力部１１によりプレイヤによる確認等の操作が受け付けられ、ゲームロジック実行部１２の制御のもと、サーバアクセス部１３からソーシャルゲーム管理サーバ４のリクエスト処理部４１に確認等の操作が伝わることで（ステップＳ２０４）、後続の処理に移行する。

初回のゲームでないと判断した場合（ステップＳ２０２のＮｏ）、チームの割り当ては済んでいるため上記の処理は行わず、前回の中断箇所から処理を再開する（ステップＳ２０５）。処理の再開は、当該プレイヤのプレイヤＩＤに基づいて、プレイヤ情報管理部４２を介してプレイヤ情報データベース４３のプレイヤ情報からステータスを参照し、そのステータスに相当する処理を特定することで行う。

チームの割り当ての確認等（ステップＳ２０４）の後もしくは当該箇所からの再開の場合、リクエスト処理部４１は、クエストを行うエリアを選択させるクエスト開始画面を端末装置１に表示させる（ステップＳ２０６）。すなわち、リクエスト処理部４１は、当該プレイヤのプレイヤＩＤに基づいて、プレイヤ情報管理部４２を介してプレイヤ情報データベース４３のプレイヤ情報を参照し、ステータスを取得する。また、リクエスト処理部４１は、取得したステータスに基づいて、クエスト／イベント管理部４４を介してクエスト／イベント情報保持部４５のシナリオ情報（図６）を参照し、ステータス（ステージ）に対応する選択可能エリアを取得する。そして、リクエスト処理部４１は、取得した選択可能エリアから所望のエリアを選択するクエスト開始画面を生成し、端末装置１に送信する。端末装置１のサーバアクセス部１３がこれを受信すると、ゲームロジック実行部１２の制御のもと、画面表示部１４により表示される。

次いで、端末装置１のプレイヤ操作入力部１１によりプレイヤによるエリア選択の操作が受け付けられ、ゲームロジック実行部１２の制御のもと、サーバアクセス部１３からソーシャルゲーム管理サーバ４のリクエスト処理部４１にエリア選択の操作が伝わることで（ステップＳ２０７）、クエストが開始する。

クエストが開始すると、リクエスト処理部４１は、エリア内をキャラクタが進行する画像を含むクエスト途中画面を端末装置１に表示させる（ステップＳ２０８）。すなわち、リクエスト処理部４１は、クエスト途中画面を端末装置１に送信し、端末装置１のサーバアクセス部１３がこれを受信すると、ゲームロジック実行部１２の制御のもと、画面表示部１４により表示される。

次いで、端末装置１のプレイヤ操作入力部１１によりプレイヤによる進む等の操作が受け付けられ、ゲームロジック実行部１２の制御のもと、サーバアクセス部１３からソーシャルゲーム管理サーバ４のリクエスト処理部４１に進む等の操作が伝わることで（ステップＳ２０９）、後続の処理に移行する。クエスト途中画面が連続する場合は、上記の処理を繰り返す。

次いで、リクエスト処理部４１は、当該プレイヤのプレイヤＩＤに基づいて、プレイヤ情報管理部４２を介してプレイヤ情報データベース４３のプレイヤ情報を参照し、自チームと相手チームを認識した上で、それぞれのチームの対戦履歴を取得する（ステップＳ２１０）。

次いで、リクエスト処理部４１は、取得した対戦履歴からイベント（ボス）のレベルを変更すべきか否か判断し、変更が必要と判断したクエスト／イベント管理部４４を介してクエスト／イベント管理部４４のイベント属性管理テーブルの該当するイベント（ボス）のレベルを更新する（ステップＳ２１１）。例えば、ボスが前回の戦いにおいて、自チームもしくは相手チームのうちのいずれかにより、６０分の制限時間のうち５分で撃破されたとする。このように短い時間で撃破された場合には、ボスのレベルを上昇させる。また、例えば、制限時間の９０％以上の時間を要して撃破された場合は、ボスのレベルを一定にする。なお、撃破時間に応じてボスのレベルの上下幅が決まるようなテーブルを用いてレベルを決定することもできる。また、制限時間内にボスが撃破されていない場合にはボスのレベルを下げることもできる。

次いで、リクエスト処理部４１は、イベントの画像を含むイベント画面を端末装置１に表示させる（ステップＳ２１２）。すなわち、リクエスト処理部４１は、イベント画面を端末装置１に送信し、端末装置１のサーバアクセス部１３がこれを受信すると、ゲームロジック実行部１２の制御のもと、画面表示部１４により表示される。

次いで、端末装置１のプレイヤ操作入力部１１によりプレイヤによるイベントに対する操作が受け付けられ、ゲームロジック実行部１２の制御のもと、サーバアクセス部１３からソーシャルゲーム管理サーバ４のリクエスト処理部４１にイベントに対する操作が伝わることで（ステップＳ２１３）、後続の処理に移行する。イベント画面が複数からなる場合は、上記の処理を繰り返す。

その後、プレイヤの操作に応じてイベントに決着が付いた場合、リクエスト処理部４１は、イベントの結果を含むイベント結果画面を端末装置１に表示させる（ステップＳ２１４）。すなわち、リクエスト処理部４１は、イベント結果画面を端末装置１に送信し、端末装置１のサーバアクセス部１３がこれを受信すると、ゲームロジック実行部１２の制御のもと、画面表示部１４により表示される。イベント結果として、魔法や技等の能力を習得したり、武器や報酬が得られたりする。

次いで、端末装置１のプレイヤ操作入力部１１によりプレイヤによる確認等の操作が受け付けられ、ゲームロジック実行部１２の制御のもと、サーバアクセス部１３からソーシャルゲーム管理サーバ４のリクエスト処理部４１に確認等の操作が伝わることで（ステップＳ２１５）、後続の処理に移行する。

その後、リクエスト処理部４１は、クエストが終了したか否か判断する（ステップＳ２１６）。クエストの終了は、エリアの終端に到達したか否かで判断することができる。

クエストが終了していないと判断した場合（ステップＳ２１６のＮｏ）、プレイヤ情報の参照（ステップＳ２１０）に戻る。

クエストが終了したと判断した場合（ステップＳ２１６のＹｅｓ）、クエスト開始画面の表示（ステップＳ２０６）に戻る。

なお、上記の処理において、端末装置１を操作するプレイヤは、操作の前後でゲームを止めることができ、再開した場合は同じ状態からその続きを実行することができる。

＜総括＞
以上説明したように、本実施形態によれば、ゲーム世界におけるプレイ間のバランスを確保することができる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

１ 端末装置
１１ プレイヤ操作入力部
１２ ゲームロジック実行部
１３ サーバアクセス部
１４ 画面表示部
２ アクセスポイント
３ ネットワーク
４ ソーシャルゲーム管理サーバ
４１ リクエスト処理部
４２ プレイヤ情報管理部
４３ プレイヤ情報データベース
４４ クエスト／イベント管理部
４５ クエスト／イベント情報保持部

Claims (7)

1. プレイヤが操作する複数の端末装置がネットワークを介して接続され、前記端末装置に全プレイヤが管理されるソーシャルＲＰＧであって、プレイヤ同士が直接には対戦せずに、少なくともゲームの獲得ポイントにより競い合うゲームサービスを提供するゲーム管理サーバ装置であって、
   プレイヤ間を関連付けて登録し、プレイヤ間の関連付けを管理するプレイヤ管理手段と、
   ゲーム内において、所定のイベントを発生させる制御を行うイベント発生制御手段と、
   各プレイヤの強さパラメータを管理するプレイヤ強さパラメータ管理手段と
   を備え、
   前記イベント発生制御手段は、前記プレイヤ強さパラメータ管理手段により管理される各プレイヤの強さパラメータを参照することで、前記プレイヤ管理手段において相互に関連付けられて登録された各プレイヤの強さパラメータの優劣を判定し、プレイヤの強さパラメータの優劣に対して候補となる複数のイベントのタイプおよび重みが対応付けられたテーブルを参照し、プレイヤの強さパラメータの優劣が該当する複数のイベントのタイプにつき設定された重みにより抽選を行ってイベントのタイプを決定し、決定したイベントのタイプに基づいてイベントの発生を制御する
   ことを特徴とするゲーム管理サーバ装置。
2. プレイヤが操作する複数の端末装置がネットワークを介して接続され、前記端末装置に全プレイヤが管理されるソーシャルＲＰＧであって、プレイヤ同士が直接には対戦せずに、少なくともゲームの獲得ポイントにより競い合うゲームサービスを提供するゲーム管理サーバ装置であって、
   プレイヤ間を関連付けて登録し、プレイヤ間の関連付けを管理するプレイヤ管理手段と、
   ゲーム内において、所定のイベントを発生させる制御を行うイベント発生制御手段と、
   各プレイヤの戦況を管理するプレイヤ戦況管理手段と
   を備え、
   前記イベント発生制御手段は、前記プレイヤ戦況管理手段により管理される各プレイヤの戦況を参照することで、前記プレイヤ管理手段において相互に関連付けられて登録された各プレイヤの戦況の優劣を判定し、プレイヤの戦況の優劣に対して候補となる複数のイベントのタイプおよび重みが対応付けられたテーブルを参照し、プレイヤの戦況の優劣が該当する複数のイベントのタイプにつき設定された重みにより抽選を行ってイベントのタイプを決定し、決定したイベントのタイプに基づいてイベントの発生を制御する
   ことを特徴とするゲーム管理サーバ装置。
3. 請求項１または２のいずれか一項に記載のゲーム管理サーバ装置において、
   前記プレイヤ管理手段において相互に関連付けられて登録されるプレイヤには、同じチームに属するプレイヤと、当該チームと対戦を行う他のチームに属するプレイヤとを含む
   ことを特徴とするゲーム管理サーバ装置。
4. 請求項１乃至３のいずれか一項に記載のゲーム管理サーバ装置において、
   各プレイヤに発生したプレイヤ別イベント発生状況を管理するイベント発生状況管理手段を更に備え、
   前記テーブルは、プレイヤ別イベント発生状況により区分され、
   前記イベント発生制御手段は、前記テーブルからプレイヤ別イベント発生状況に該当する候補のイベントからイベントを決定する
   ことを特徴とするゲーム管理サーバ装置。
5. 請求項１乃至４のいずれか一項に記載のゲーム管理サーバ装置において、
   前記テーブルは、現在時刻の属するタイムゾーンにより区分され、
   前記イベント発生制御手段は、前記テーブルから現在時刻の属するタイムゾーンに該当する候補のイベントからイベントを決定する
   ことを特徴とするゲーム管理サーバ装置。
6. プレイヤが操作する複数の端末装置がネットワークを介して接続され、前記端末装置に全プレイヤが管理されるソーシャルＲＰＧであって、プレイヤ同士が直接には対戦せずに、少なくともゲームの獲得ポイントにより競い合うゲームサービスを提供するゲーム管理サーバ装置を構成するコンピュータを、
   プレイヤ間を関連付けて登録し、プレイヤ間の関連付けを管理するプレイヤ管理手段、
   ゲーム内において、所定のイベントを発生させる制御を行うイベント発生制御手段、
   各プレイヤの強さパラメータを管理するプレイヤ強さパラメータ管理手段
   として機能させ、
   前記イベント発生制御手段は、前記プレイヤ強さパラメータ管理手段により管理される各プレイヤの強さパラメータを参照することで、前記プレイヤ管理手段において相互に関連付けられて登録された各プレイヤの強さパラメータの優劣を判定し、プレイヤの強さパラメータの優劣に対して候補となる複数のイベントのタイプおよび重みが対応付けられたテーブルを参照し、プレイヤの強さパラメータの優劣が該当する複数のイベントのタイプにつき設定された重みにより抽選を行ってイベントのタイプを決定し、決定したイベントのタイプに基づいてイベントの発生を制御する
   ゲーム管理サーバ装置用プログラム。
7. プレイヤが操作する複数の端末装置がネットワークを介して接続され、前記端末装置に全プレイヤが管理されるソーシャルＲＰＧであって、プレイヤ同士が直接には対戦せずに、少なくともゲームの獲得ポイントにより競い合うゲームサービスを提供するゲーム管理サーバ装置を構成するコンピュータを、
   プレイヤ間を関連付けて登録し、プレイヤ間の関連付けを管理するプレイヤ管理手段、
   ゲーム内において、所定のイベントを発生させる制御を行うイベント発生制御手段、
   各プレイヤの戦況を管理するプレイヤ戦況管理手段
   として機能させ、
   前記イベント発生制御手段は、前記プレイヤ戦況管理手段により管理される各プレイヤの戦況を参照することで、前記プレイヤ管理手段において相互に関連付けられて登録された各プレイヤの戦況の優劣を判定し、プレイヤの戦況の優劣に対して候補となる複数のイベントのタイプおよび重みが対応付けられたテーブルを参照し、プレイヤの戦況の優劣が該当する複数のイベントのタイプにつき設定された重みにより抽選を行ってイベントのタイプを決定し、決定したイベントのタイプに基づいてイベントの発生を制御する
   ゲーム管理サーバ装置用プログラム。

Images