【文献】
徳岡 正肇,「ソーシャルゲーム業界最新事情」,日本,ソフトバンク クリエイティブ株式会社,2011年 4月 1日,初版,第9〜13、27〜35頁
【文献】
モンスターハンター フロンティア オンライン 魁!!スキル塾,LOGiN,日本,株式会社エンターブレイン,2008年 2月 1日,第27巻第2号通巻383号,第68、73頁
(58)【調査した分野】(Int.Cl.,DB名)
【発明の概要】
【発明が解決しようとする課題】
【0004】
近年のSNS(Social Networking Service)などコミュニティ型のウェブサイトでは、サービスの一環として複数のゲームを用意して、ユーザが任意にゲームを選択してプレイできるようになっており、こうしたゲームはSNSゲーム或いはソーシャルゲームなどと呼ばれている。SNSゲームは、マルチプレイオンラインゲームなどとは異なり、各ユーザのプレイは完全に独立し非同期である。ゲーム同士は連動することが無く、パラメータの変更はそのゲーム内に限られていた。
【0005】
それでも、SNSゲームをプレイするユーザ間では、お互いのゲーム内での体験や感想、攻略法のヒントやコツなどを話題として頻繁にコミュニケーションし、非同期ゲームでありながらもマルチプレイオンラインゲームのプレーヤ同士のような連帯感を持ち、強い友好関係を築くことができる。そして、コミュニケーションが高まると、互いのプレイに刺激され、SNSゲームがより楽しく感じられるようになる。
【0006】
本発明は、上述した技術背景及び課題に鑑みてなされたものであり、非同期のゲームにおいて、ユーザ同士が互いの存在を感じられるようにして、ユーザ間のコミュニケーション活性化や連帯感の向上を図ることを目的とする。なお、本発明の課題は、SNSゲームに限られるわけではないのは勿論である。
【課題を解決するための手段】
【0007】
上述した課題を解決するための第1の形態は、各プレーヤのプレーヤ端末から送信される操作入力に従って、各プレーヤに係るゲーム進行を非同期に制御するサーバシステムであって、
各プレーヤそれぞれのパラメータを管理するパラメータ管理手段(例えば、
図4のサーバ処理部200s、第1ゲーム管理サーバ制御部210、プレイデータ管理部214、
図8のステップS42)と、
各プレーヤそれぞれについて、当該プレーヤに関係する関係プレーヤを記憶する関係プレーヤ記憶手段(例えば、
図4のサーバ処理部200s、ユーザ登録情報管理部202、フレンドリスト管理部203、サーバ記憶部500s、
図5のユーザ登録データ520、フレンドリスト525)と、
一のプレーヤの前記パラメータを変更する処理を発動させる所与の発動条件を満たしたことを検出する発動検出手段(例えば、
図4のサーバ処理部200s、第1ゲーム管理サーバ制御部210、発動検出部220、
図8のステップS50)と、
前記発動検出手段の検出がなされた場合に、前記一のプレーヤの前記パラメータを変更するパラメータ変更制御手段(例えば、
図4のサーバ処理部200s、第1ゲーム管理サーバ制御部210、パラメータ向上制御部226、
図8のステップS54)と、
前記発動検出手段の検出がなされた場合に、前記一のプレーヤの関係プレーヤの前記パラメータを変更する波及制御を実行する波及制御手段(例えば、
図4のサーバ処理部200s、第1ゲーム管理サーバ制御部210、波及制御部227、
図8のステップS57〜S60)と、
を備えたサーバシステムである。
【0008】
第1の形態によれば、一のプレーヤのゲームプレイ中に発動条件が満たされると、当該一のプレーヤのゲームに係るパラメータを変更するとともに、当該一のプレーヤの関係プレーヤ(例えば、フレンドユーザ)に係るパラメータをも変更することができる。つまり、プレーヤ間の関係に基づいて非同期のゲーム間でパラメータ変更効果の波及を実現することができる。よって、一のユーザと関係する関係ユーザとが互いの存在を感じられるようにして、ユーザ間のコミュニケーション活性化や連帯感の向上を図ることができる。
【0009】
発動条件に関しては、第2の形態として、前記発動検出手段は、前記一のプレーヤの前記パラメータを変更する所与のアイテムの使用或いは所与の動作の実行の指示操作入力がなされたことを前記発動条件として検出する、第1の形態のサーバシステムを構成することができる。
【0010】
また、第3の形態として、前記発動検出手段が、前記一のプレーヤに係るゲーム進行が所与の条件を満たしたことを前記発動条件として検出する第1の形態のサーバシステムを構成することができる。
ここでいう、所与の条件とは、例えばアイテムを取得した、特定の敵キャラクタを倒した、同じゲームをプレイするプレーヤ100人と友達になれた、ステージをクリアした、など、ゲーム中にプレーヤにとって良いことがあった状況を設定すると、ユーザ間のコミュニケーション活性化の観点から好適である。
【0011】
波及の程度に着目すると、第4の形態として、前記波及制御手段が、前記パラメータ変更制御手段による前記パラメータの変更幅よりも小さい変更幅で前記一のプレーヤの関係プレーヤの前記パラメータを変更する制御を前記波及制御として実行する変更幅調整手段(例えば、
図4のサーバ処理部200s、第1ゲーム管理サーバ制御部210、向上幅調整部230、
図8のステップS58)を有する第1〜第3の何れかの形態のサーバシステムを構成することができる。
【0012】
第4の形態によれば、第1〜第3の形態の何れかと同様の効果が得られるとともに、波及効果を本来の変更幅より小さくできる。
【0013】
さらには、第5の形態として、前記波及制御手段が、前記発動検出手段の検出がなされた後、前記一のプレーヤの関係プレーヤがログインした際に、当該関係プレーヤの前記パラメータを変更し、前記変更幅調整手段は、前記発動検出手段の検出がなされてから、前記一のプレーヤの関係プレーヤがログインするまでの時間経過に応じて、当該関係プレーヤの前記プレーヤを変更する変更幅を調整する、第4の形態のサーバシステムを構成することができる。
【0014】
第5の形態によれば、第4の形態と同様の効果が得られるとともに、波及効果を時間経過で減少させることができる。
【0015】
また、同じく波及の程度に着目すると、第6の形態として、各プレーヤそれぞれについて、当該プレーヤと当該プレーヤの関係プレーヤとの友好度を記憶する友好度記憶手段(例えば、
図4のサーバ処理部200s、ユーザ登録情報管理部202、フレンドリスト管理部203、サーバ記憶部500s、
図6のフレンドリスト525、友好度525b)を更に備え、前記変更幅調整手段は、前記一のプレーヤの関係プレーヤの前記パラメータの変更幅を、当該一のプレーヤとの友好度を用いて変更する、第4又は第5の形態のサーバシステムを構成することができる。
【0016】
第6の形態によれば、第5の形態と同様の効果が得られるとともに、プレーヤ同士の友好度に基づき変更幅を可変にすることができる。
【0017】
また、第7の形態として、前記変更幅調整手段が、前記一のプレーヤの関係プレーヤの人数を用いて、当該関係プレーヤの前記パラメータの変更幅を変更する手段を有する、第4〜第6の何れかの形態のサーバシステムを構成することができる。
【0018】
第7の形態によれば、第4〜第6の形態の何れかと同様の効果が得られるとともに、関係プレーヤの人数に応じて、関係プレーヤそれぞれの変更幅を変更することができる。
【0019】
また、波及効果の時間的要素に着目して、第8の形態として、前記波及制御手段が、前記発動検出手段の検出がなされた場合に、前記一のプレーヤの関係プレーヤの前記パラメータを所与の期間一時的に変更する時限制御手段(例えば、
図4のサーバ処理部200s、ユーザ登録情報管理部202、時限制御部233)を有する、第1〜第7の何れかの形態のサーバシステムを構成することができる。
【0020】
第8の形態によれば、第1〜第7の形態の何れかと同様の効果が得られるとともに、波及効果を一時的なものにできる。
【0021】
更には、第9の形態として、各プレーヤそれぞれについて、当該プレーヤと当該プレーヤの関係プレーヤとの友好度を記憶する友好度記憶手段を更に備え、前記時限制御手段が、前記一のプレーヤの関係プレーヤの前記パラメータを変更する時限を、前記一のプレーヤとの友好度を用いて変更する(例えば、
図15のステップS68))、第8の形態のサーバシステムである。
【0022】
第9の形態によれば、第8の形態と同様の効果が得られるとともに、友好度に基づき波及効果の及ぶ時間を可変にすることができる。
【0023】
また、波及先自体に着目するならば、第10の形態として、前記一のプレーヤの関係プレーヤのうち、前記波及制御手段による波及制御の対象とする関係プレーヤ(以下「波及先プレーヤ」という。)を選択する波及先選択手段(例えば、
図4のサーバ処理部200s、ユーザ登録情報管理部202、波及先選択部229、
図8のステップS57)を更に備え、
前記波及制御手段は、前記波及先選択手段により選択された波及先プレーヤの前記パラメータを対象に前記波及制御を実行する、第1〜第9の何れかの形態のサーバシステムを構成することができる。
【0024】
第10の形態によれば、第1〜第9の形態の何れかと同様の効果が得られるとともに、関係プレーヤの中から波及効果が及ぶ相手を選択することができる。
【0025】
また、選択に係る要素に着目すれば、第11の形態として、各プレーヤそれぞれについて、当該プレーヤと当該プレーヤの関係プレーヤとの友好度を記憶する友好度記憶手段を更に備え、前記波及先選択手段が、前記一のプレーヤと当該関係プレーヤとの友好度を用いて、波及先プレーヤを選択する、第10の形態のサーバシステムを構成することができる。
【0026】
第11の形態によれば、第10の形態と同様の効果が得られるとともに、友好度に基づいて波及先とするプレーヤを選択することができる。
【発明を実施するための形態】
【0028】
〔第1実施形態〕
本発明を適用した第1実施形態として、登録ユーザに第1ゲームと第2ゲームを提供する例について説明する。なお、以下では、ゲームに係る場合を含む一般的な意味として「ユーザ」という用語を用い、ゲームに係る場合に「プレーヤ」として適宜使い分けているが、同一に扱うことができるため、どちらか一方の用語に置き換えて読むこととしても勿論よい。
【0029】
[システムの構成の説明]
図1は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態のゲームシステムは、通信回線1に接続することのできるサーバシステム1100と、ゲームのプレーヤ2(2a,2b,2c,・・・)毎に用意されるプレーヤ端末であるユーザ端末1500(1500a,1500b,1500c,・・・)により構成される。
【0030】
通信回線1は、データ通信が可能な通信路を意味する。すなわち、通信回線1とは、直接接続のための専用線(専用ケーブル)やイーサネット(登録商標)等によるLAN(Local Area Network)の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線/無線を問わない。
【0031】
サーバシステム1100は、単数又は複数のサーバシステムや記憶装置等を含んで構成され、コミュニティ型ウェブサイトやオンラインゲームを運営するための各種サービスを提供し、ゲーム実行に必要なプレイデータの管理や、クライアントプログラム及び各種データ等を配信することができる。
【0032】
本実施形態では、サーバシステム1100は、筐体1102と、キーボード1106と、タッチパネル1108と、ストレージ1140とを備える。筐体1102には、複数のブレードサーバ1104が内蔵されている。
【0033】
ブレードサーバ1104は、例えば、(1)ユーザ登録やプレーヤキャラクタの初期設定、及びログイン/ログアウトに関係する処理を担うアカウント管理サーバシステム1110と、(2)ゲーム内で使用するアイテムを購入できるオンラインショッピングサービス処理を担うオンラインショッピングサーバ1112と、(3)ログインしてオンラインゲームに参加中のユーザ端末1500へゲームを実行するのに必要なデータを随時管理・配信するゲーム管理サーバシステム1114と、を有して構成される。
【0034】
ゲーム管理サーバシステム1114は、ゲーム種類毎に第1ゲーム管理サーバシステム1115、第2ゲーム管理サーバシステム1116、・・・と言った具合に設けられており、互いにサーバシステム1100の内部回線を通じてデータ通信可能に接続されている。
【0035】
尚、ブレードサーバ1104を構成するそれぞれのサーバは、通信回線1を介してデータ通信可能な独立したサーバシステムとして実現しても良い。例えば、第1ゲーム管理サーバシステム1115と第2ゲーム管理サーバシステム1116を、独立した第1ゲーム管理サーバシステム1117と第2ゲーム管理サーバシステム1118としたシステム構成でも良い。
【0036】
ユーザ端末1500は、ユーザそれぞれに1台ずつ用意されるコンピュータであり、電子装置(電子機器)である。例えば、スマートフォンや、携帯型ゲーム装置、据置型家庭用ゲーム装置、業務用ゲーム装置、パソコン、タブレット型コンピュータなどにより実現される。そして、通信回線1に接続し、サーバシステム1100にアクセスすることができる。
【0037】
図2は、ユーザ端末1500の構成例を示す図であって、(1)正面外観図、(2)背面外観図である。本実施形態におけるユーザ端末1500は、方向入力キー1502と、ホームキー1504と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル1506と、スピーカ1510と、マイク1512と、GPS(Global Positioning System)アンテナ1514と、CCDカメラモジュール1516と、制御基板1550と、コンピュータ読み出し可能な情報記憶媒体であるメモリカード1540からデータを読み書きできるメモリカード読取装置1542と、を備える。その他、図示されていない内蔵バッテリーや電源ボタン、音量調節ボタン等が設けられている。
【0038】
CCDカメラモジュール1516は、オートフォーカス機構と、CCDイメージセンサと、イメージ信号生成チップとを搭載したモジュールであって、ユーザ端末1500の背面側を撮影できるように配置されている。尚、イメージセンサ素子はCCDに限らない。
【0039】
制御基板1550は、CPU(Central Processing Unit)1551やGPU(Graphics Processing Unit)、DSP(Digital Signal Processor)などの各種マイクロプロセッサ、ASIC(Application Specific Integrated Circuit)、VRAMやRAM,ROM等の各種ICメモリ1552を搭載する。
【0040】
そして、制御基板1550には、携帯電話基地局や無線LAN基地局などと無線接続するための無線通信モジュール1553と、GPSモジュール1554と、電子コンパス1555と、3軸ジャイロ1556と、3軸加速度センサ1557とが搭載されている。その他、タッチパネル1506のドライバ回路、方向入力キー1502及びホームキー1504からの信号を受信する回路、スピーカ1510へ音声信号を出力する出力アンプ回路、マイク1512で集音した音声の信号を生成する入力信号生成回路、メモリカード読取装置1542への信号入出力回路といった所謂I/F回路(インターフェース回路)、等が搭載されている。これら制御基板1550に搭載されている各要素は、それぞれバス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。
【0041】
GPSモジュール1554は、GPSアンテナ1514とともにGPSを利用した位置情報を取得する手段を構成する。GPSモジュール1554は、GPSアンテナ1514で受信したGPS衛星3からの信号に基づいて、所定時間毎(例えば、1秒毎)に、位置情報(例えば、緯度・経度)及びその他の情報(絶対時間)を、制御基板1550で演算処理可能なデータとして出力する。尚、測位に利用するシステムはGPSに限らない。その他の衛星測位システムでも良いし、衛星を用いない測位システムを用いることもできる。後者の例としては、例えば、無線通信モジュール1553が無線接続できる携帯電話基地局からの信号に基づいて三角測量の原理で測位して、位置情報を取得するとしても良い。
【0042】
制御基板1550は、サーバシステム1100から取得したゲームクライアントプログラムやデータをICメモリ1552に一時記憶する。そして、プログラムを実行して演算処理を実行し、方向入力キー1502やホームキー1504、タッチパネル1506からの操作入力に応じてユーザ端末1500の各部を制御して、オンラインRPGを実行する。尚、本実施形態では、ユーザ端末1500は必要なプログラムや各種設定データをサーバシステム1100から取得する構成としているが、別途入手したメモリカード1540から読み出す構成としても良い。
【0043】
[非同期のゲーム間での波及効果についての説明]
本実施形態では、ユーザはサーバシステム1100が提供するサービスを利用するには、所定の手続きを行ってユーザアカウントを取得する必要がある。取得したユーザアカウントと対応づけられるパスワードをもってログインすることで、アイテムのオンライショッピングや、登録ユーザ間でのメッセージ交換、フレンドユーザの登録、ゲームプレイなどのサービスが利用可能となる。
【0044】
メッセージ交換は、ログインしているユーザ間でのショートメール等のメッセージの送受をサポートするサービスであり、例えばプッシュ通知などにより実現される。そして、ユーザはメッセージのやりとりを通じて気の合った他ユーザを所定の登録手続きによって「フレンド」として登録する機能を提供する。以降、一のユーザにより「フレンド」として登録された関係ユーザを「フレンドユーザ」と呼ぶ。
【0045】
また、ユーザは、所定のゲーム利用登録をすることで、複数のゲームの中から任意のゲームを好きな時に好きな時間だけ遊ぶことが可能である。例えば、とあるユーザは、第1ゲームと第2ゲームとを利用登録しているとする。そして、本実施形態では、第1ゲームのゲーム進行状況に応じて、第2ゲームで使用されるパラメータを変更し、非同期のゲーム間におけるパラメータ変更の波及を実現することができる。
【0046】
図3は、本実施形態における非同期のゲーム間におけるパラメータ変更の波及について説明するための図である。
本実施形態では、あるユーザが第1ゲームをプレイしている際に、ゲーム進行状況が所定の発動条件を満たすと、第2ゲームをプレイするフレンドユーザのパラメータが、プレーヤにとって有利な方向に変更される。
なお、あるユーザがプレイするゲームと、フレンドユーザがプレイするゲームとは同じであっても勿論構わない。しかし説明上の混乱を避けるために、第1ゲームと第2ゲームとに分けて説明する。
【0047】
発動条件としては、例えば、所定アイテムの使用・入手・購入、所定ステージの攻略、所定のNPC(ノンプレーヤキャラクタ)の撃破、魔法や技などの習得、特殊コマンドの取得、必殺技の実行、などを適宜設定することができる。また、可変されるパラメータも適宜設定可能である。
【0048】
より具体的には、本実施形態では、第1ゲームと第2ゲームでは、共にプレーヤキャラクタの行動に関するパラメータとして行動ポイント(AP:Action Point)が与えられるものとする。行動ポイントAPは、プレーヤキャラクタが何らかの行動をとる際に消費されるポイントであって、行動の種類によって消費されるポイントが異なる。例えば、移動なら2ポイント消費、攻撃なら4ポイント消費、アイテム使用なら1ポイント消費、・・・と言った具合である。行動ポイントAPは、時間とともに自動的に回復するが、所定のAP回復アイテムの使用により瞬時に回復を図ることもできる。そして、このAP回復アイテは、オンラインショッピングサービスで購入できる所謂「課金アイテム」である。
【0049】
例えば、ゲーム画面W2には、最新の行動ポイントAPの最大値と現在の残AP値を示す行動ポイントメータ4が表示される。ちなみに、
図3の例では網掛けされたマスが残AP値を示している。
【0050】
プレーヤが第1ゲームにおいて、このAP回復アイテムの使用指示操作入力をしたならば(ゲーム画面W4参照)、当該アイテムの直接的な効果として、第1ゲームに係るプレイデータ540に含まれる残AP544が加算され行動ポイントAPが回復・向上される(ゲーム画面W4の例では「1」から「10」まで回復)。
【0051】
また、第1ゲームのゲーム画面には、発動条件を満たしたことを通知する発動通知表示W12が表示される(ゲーム画面W6参照)。当該通知表示では、波及効果に関するアナウンスが通知される。
【0052】
そして、当該第1ゲームをプレイしているユーザ2(2a)のフレンドユーザの中から、波及対象のフレンドユーザが選択され(
図3の例ではフレンドユーザ2(2c))、当該フレンドユーザの第2ゲームに係るプレイデータ540の残AP544を回復・向上させる(
図3の例では「2」から「7」まで回復)。
【0053】
フレンドユーザ2(2c)が第2ゲームをプレイすると、前回プレイ終了した時点では行動ポイントAPが「2」であったところが「7」まで回復していることとなる(ゲーム画面W8参照)。そして、第2ゲームのゲーム画面W8には、波及到達通知W14が表示され、プレーヤへ波及効果の影響を受けた旨のアナウンスが表示される。
【0054】
このように、本実施形態では、ユーザ2(2a)及びそのフレンドユーザ2(2c)にとってみれば、ユーザ2(2a)による第1ゲームでのAP回復アイテムの使用による直接的効果とともに、第2ゲームにおける行動ポイントAPの回復という波及効果が得られることになり、またその旨が双方に通知される。第1ゲームと第2ゲームとは、本来非同期で独立したゲームであるが、こうした波及効果と通知とにより、互いの存在を感じることができる。そして、「AP回復の効果そっちに届いた?あれ結構高額だったんだけど、どの程度そっちで効果あった?」或いは「AP回復効果届いたよ!あのときピンチでさ。助かったよ。所で・・・」と言った、ユーザ間のコミュニケーション活性化や連帯感の向上を図ることができる。
【0055】
尚、発動条件や、発動条件が満たされた時に第1ゲームで変更されるパラメータ(第1パラメータ)、波及効果として第2ゲームで変更されるパラメータ(第2パラメータ)は適宜設定可能である。
例えば、発動条件をゲーム進行状況とすることができる。より具体的には、第1ゲームでプレーヤにとって有益なアイテムを取得した、特定の敵キャラクタを撃破した、ゲーム内パズルを解いた、新しい呪文を憶えた、必殺技を実行した、等であっても良い。より具体的には、発動条件を、効力に制限時間があるアイテム(例えば、第1の所与時間だけ移動速度が増加するアイテムなど)とすることもできる。その場合には、第1ゲームでは、当然当該アイテムの使用に伴い第1の所与時間の間だけ対応する第1パラメータ(例えば、移動力、回復力など)を向上し、時間経過すると向上前の状態に戻すように制御すると良い。そして、第2ゲームにおいても同じアイテム効果が適用さることとし、同じように第2の所与時間(第1ゲームにおける第1の所与時間と異なるとしても可)の間、対応する第2パラメータが向上され、時間経過すると向上前の状態に戻すように制御する構成とすれば良い。勿論、第2パラメータを第1パラメータと異なる種類とすることもできる。
【0056】
また、第2ゲームにおける波及効果、具体的には第2ゲームに適用されるパラメータの向上幅は、基本的には第1ゲームと同様又は劣るものとする。
具体的には、AP回復アイテムであれば、第1ゲームでは10ポイント回復するところを、第2ゲームでは8ポイントといった具合に、第1ゲームでの効果よりも低減させる。この例では向上幅は第1ゲームよりも20%ダウンさせる。制限時間のあるアイテムならば、第1ゲームなら100秒間効果が持続するが、第2ゲームならば50秒間(向上幅が第1ゲームより50%ダウン)だけ効果が持続する等とすると良い。
【0057】
更には、第2ゲームに適用されるパラメータの向上幅を、ユーザ2(2a)とフレンドユーザ2(2b)との関係性の高さ(例えば、コミュニケーション頻度に応じて自動的に付与される好感度、プレイしているゲームの共通数など)に応じて決定することもできる。本実施形態では、第1ゲームと第2ゲームそれぞれのプレイデータ540に格納される同じ種類のパラメータ(例えば、プレーヤレベル、経験値、仮想マネー残高、プレイ日時など)の値を比較し、その差に応じて向上幅を決定することもできる。具体的には、例えば、第1ゲームのプレーヤレベルと、第2ゲームのプレーヤレベルとを比較して、差が大きいほど適用される効果度合を低くする。或いは単純に第2ゲームのプレーヤレベルが小さい(低い)程効果度合をより低くするとしても良い。
こうすることで、異なるユーザや異なるゲーム間でゲームの進捗度合や、プレーヤの習熟度、ゲームの「やり込み」度合に差があっても、一方のゲームのパラメータがゲームバランスを崩すほど過度に変更されないようにできる。
【0058】
また、パラメータ変更の波及先となるフレンドユーザの人数は、適宜設定可能である。そして、もし波及先となるフレンドユーザが複数の場合には、波及効果を人数に応じて分配する構成も可能である。例えば、波及効果を行動ポイントAPを100ポイント回復させるとして、波及先となるフレンドユーザの人数が5人ならば、一人当たり20ポイント回復するように均等に分配するとしても良い。或いは、第1ゲームをプレイするユーザ1(2b)と波及先となるフレンドユーザとの関係性(例えば、好感度)の程度に応じて波及効果を分配するとしても良い。
【0059】
また、上述したように、ユーザ2(2a)とフレンドユーザ2(2b)とがプレイしているゲームを異なるゲーム(第1ゲームと第2ゲームとで異なるゲーム)としたが、同じゲームであってもよい。その場合であっても、勿論、各ユーザのゲームは個別(非同期)に進行制御される。そのため、ユーザ2(2a)とフレンドユーザ2(2b)とがプレイしているゲームそれぞれを便宜的に第1ゲーム、第2ゲームと呼ぶこととして、本実施形態を読んでも同じである。
【0060】
尚、本実施形態では、ユーザ2(2a)及びフレンドユーザ2(2b)それぞれのパラメータをプレーヤにとって有利な方向へ変更するとしているが、両方或いは一方のパラメータをプレーヤにとって不利な方向へ変更する構成も可能である。
【0061】
[機能ブロックの説明]
次に、本実施形態を実現するための機能構成について説明する。
図4は、本実施形態におけるサーバシステム1100の機能構成の一例を示す機能ブロック図である。サーバシステム1100は、操作入力部100sと、サーバ処理部200sと、画像表示部360sと、通信部370sと、サーバ記憶部500sとを備える。
【0062】
操作入力部100sは、サーバオペレータによって為された各種の操作入力(プレーヤキャラクタの行動の指示操作入力を含む)に応じて操作入力信号をサーバ処理部200sに出力する。例えば、キーボードや、タッチパネル、マウス、トラックパッドなどによって実現できる。
図1ではキーボード1106やタッチパネル1108がこれに該当する。
【0063】
サーバ処理部200sは、例えばCPUやGPU等のマイクロプロセッサや、ASIC、ICメモリなどの電子部品によって実現される。サーバ処理部200sは、各機能部との間でデータの入出力制御を行い、所定のプログラムやデータ、操作入力部100sからの操作入力信号や、通信部370sを介して外部からアクセスしてきた外部装置(他コンピュータ)等からのリクエストに応じて各種の演算処理を実行して、サーバシステム1100の動作を制御する。
図1ではブレードサーバ1104、より具体的にはその制御基板がこれに該当する。
【0064】
そして、本実施形態のサーバ処理部200sは、ユーザ登録情報管理部202と、ログイン処理部204と、第1ゲーム管理サーバ制御部210と、第2ゲーム管理サーバ制御部240と、画像生成部260sと、通信制御部270sとを備える。尚、プレイ可能なゲームの種類に応じてゲーム管理サーバ制御部の数を適宜加減することができる。
【0065】
ユーザ登録情報管理部202は、ユーザアカウントの新規発行、パスワードの登録など各種ユーザ情報の取得・登録管理に関する処理を実行する。尚、ユーザ登録情報管理部202は、公知のコミュニティ型のウェブサイトやオンラインゲームにおけるユーザ登録関連技術を適宜応用することで実現できる。そして、本実施形態のユーザ登録情報管理部202は、フレンドリスト管理部203を含み、フレンドユーザの登録・抹消に関する処理を実行する。
【0066】
ログイン処理部204は、通信接続したユーザ端末1500からのリクエストに応じて所謂ログインを制御する。当該処理部は、公知のコミュニティ型のウェブサイトやオンラインゲームにおけるログイン制御技術を適宜利用することで実現できる。
図1の例では、アカウント管理サーバ1110がユーザ登録情報管理部202と、ログイン処理部204とを担う。
【0067】
第1ゲーム管理サーバ制御部210及び第2ゲーム管理サーバ制御部240は、それぞれ第1ゲーム、第2ゲームの進行制御並びにユーザ端末1500にてゲーム画像等を表示させるのに必要な処理を実行する。すなわち、常時機能している状態にあって、ユーザ端末1500からゲーム開始リクエストを受けると新たなプレイデータ540を生成して、個別にゲーム進行制御することができる。そして、これら両制御部は、ゲーム内容が異なるだけで基本的には同じ構成を有する。以降、両ゲーム管理サーバ制御部を代表して、第1ゲーム管理サーバ制御部210について説明する。
【0068】
第1ゲーム管理サーバ制御部210は、プレイデータ管理部214と、発動検出部220と、第2ゲームデータ取得制御部222と、第2ゲームプレイ日時取得制御部224と、パラメータ向上制御部226と、波及制御部227と、発動通知制御部236と、受動実行制御部238とを含む。
【0069】
プレイデータ管理部214は、当該ゲーム管理サーバ制御部で進行制御するゲームの進行状況を記述するデータ、所謂プレイデータを管理する。本実施形態では更に、行動パラメータ管理部216と、プレイ日時管理部218とを含む。
【0070】
行動パラメータ管理部216は、プレーヤキャラクタの行動パラメータを管理する。本実施形態では、ゲームにおける行動の指示操作入力がなされる毎に行動ポイントAPを行動種類に応じた値だけ減算し消費する。また、時間経過又はAP回復アイテムの使用により加算・回復させる。
【0071】
プレイ日時管理部218は、プレーヤのプレイ日時を管理する。具体的には、プレイ開始日時と、プレイ終了日時とを対応づけ記憶・管理するための制御をする。1回1回のプレイ毎にログインがなされる形態であれば、1回1回のプレイされた(ログインされた)日時をプレーヤ毎に対応づけて記憶・管理する。
【0072】
発動検出部220は、一のプレーヤの第1のパラメータを向上させる処理を発動させる所与の発動条件を満たしたことを検出する。本実施形態では、少なくともAP回復アイテムの使用指示操作入力がなされたことを発動条件として検出する
【0073】
第2ゲームデータ取得制御部222は、第2ゲームのゲーム進行を管理するサーバシステムから、第1ゲームのプレーヤに関係するフレンドユーザの第2ゲームにおけるプレイデータを取得するための制御を行う。
【0074】
第2ゲームプレイ日時取得制御部224は、第2ゲームのゲーム進行を管理するサーバシステム(第2サーバシステム)から、第1ゲームのプレーヤに関係するフレンドユーザの第2ゲームに関するプレイ日時のデータを取得するための制御を行う。
【0075】
パラメータ向上制御部226は、発動検出部220による検出がなされた場合に、プレーヤの第1パラメータを変更する。本実施形態では、第1パラメータとして行動ポイントAPを設定し、AP回復アイテムの使用指示操作入力がなされた場合に、所与の回復量分だけプレーヤの行動ポイントAPに加算・回復させる。つまり、向上方向へ変更する。
尚、第1パラメータは、ゲーム内容に応じて適宜設定可能である。例えば、攻撃力や防御力といった戦闘に関する能力パラメータ値、ゲーム内又はゲーム開始前の抽選に適用される当選確率、プレーヤキャラクタの好感度や経験値、成長度数などをゲーム内容に応じて設定できる。そして、設定したパラメータの意味するところに応じて向上させるように、つまりはプレーヤにとって利するように処理すると良い。例えば、第1パラメータを能力パラメータや当選確率とした場合には、発動検出部220の検出がなされた場合に、それらのパラメータを所与の期間一時的に向上させると良い。
【0076】
波及制御部227は、第1ゲームのプレーヤの関係プレーヤ(フレンドユーザ)のパラメータを変更する波及制御を実行する。すなわち、他ゲームへの波及に関する処理を実行する。
本実施形態では、パラメータを向上する方向へ変更する。より具体的には、発動検出部220の検出がなされた場合に、第2ゲームに係る各プレーヤの第2パラメータを管理するとともに第2ゲームを進行制御するサーバシステム(第2サーバシステム)に対して、第1ゲームのプレーヤの関係プレーヤ(フレンドユーザ)の第2パラメータを向上させるように、つまりはフレンドユーザにとって利するようにパラメータを変更させる波及制御を実行する。
本実施形態では、第2パラメータとして、行動ポイントAPを設定し、第1ゲームにおける行動ポイントAPのアイテムによる回復が第2ゲームにおける行動ポイントAPにも波及するように第2パラメータを変更させる。
【0077】
尚、第2パラメータは、第1パラメータと異なる種類を設定することができるのは勿論である。そして、第2パラメータの変更は、その設定により適宜変更できる。例えば、第2パラメータを能力パラメータ値や、ゲーム開始前やゲーム中に実行される抽選に適用される当選確率とした場合には、それらのパラメータを所与の期間一時的に向上させるように変更すると良い。
【0078】
もし、第1ゲーム管理サーバシステム1115と第2ゲーム管理サーバシステム1116が互いに独立したサーバシステムの場合には、外部からシステムを制御できる共通のAPI(Application Program Interface)いわゆる外部APIを実装させ、当該APIを用いて外部から第2パラメータを変更可能にすることで波及制御部227を実現すると良い。
【0079】
そして、本実施形態の波及制御部227は、波及先選択部229と、向上幅調整部230と、時限制御部233とを含む。
【0080】
波及先選択部229は、第2ゲームのプレイデータを変更する対象、パラメータ変更の波及先を、第1ゲームをプレイするユーザ(プレーヤ)のフレンドユーザの中から選択する。選択人数は、適宜設定可能である。所定数でも良いし、所定割合(例えば、フレンドユーザの10%)、フレンドユーザ全員でも良い。また、第1ゲームのゲーム進行状況(例えば、プレーヤレベル、経験値など)に応じて、プレーヤキャラクタが成長したりゲームが進行するにつれて波及先とするフレンドユーザの数を増加させるとしても良い。
【0081】
向上幅調整部230は、第2パラメータの向上幅すなわち変更幅を、パラメータ向上制御部226による第1パラメータの向上幅よりも原則として小さい向上幅とする。更には、向上幅調整部230は、プレイデータ基準変更幅決定部232と、プレイ頻度基準変更幅決定部234とを含む。
【0082】
プレイデータ基準変更幅決定部232は、第2ゲームのプレイデータに基づいて向上幅(変更幅)を決定する。本実施形態では、第1ゲームのプレーヤのプレイデータと、第2ゲームデータ取得制御部222により取得されたフレンドユーザに係る第2ゲームのプレイデータとの差を用いて第2パラメータの変更幅を決定する。
【0083】
プレイ頻度基準変更幅決定部234は、第2ゲームのプレイ日時の履歴に基づいて向上幅(変更幅)を決定する。本実施形態では、プレイ日時管理部218で管理されているプレーヤの第1ゲームのプレイ日時と、第2ゲームプレイ日時取得制御部224の制御により取得されたフレンドユーザの第2ゲームに係るプレイ日時とに基づいて、第1ゲームのプレーヤのプレイ頻度と、フレンドユーザのプレイ頻度の差を求め、当該プレイ頻度の差を用いて第2のパラメータの向上幅すなわち変更幅を決定する。具体的には、例えば、前者よりも後者が低いほど向上幅を小さくする。或いは、後者の方が高ければ、向上幅を低くしない又は若干高くするとしても良い。
【0084】
これらの変更幅決定部は、プレイデータ540に含まれるプレーヤレベルやプレイ回数、或いはプレイ日時など、プレイ習熟度やプレイ進捗度を推し量るパラメータを比較し、第1ゲームのプレーヤに比べて、フレンドユーザのプレイ習熟度やプレイ進捗度が低い場合には変更幅を第1ゲームと同程度とする、又は変更幅を小さくする。
【0085】
また、本実施形態では、波及先となるフレンドユーザは、皆同じ波及効果を受けることができる構成とするが、向上幅調整部230に、第1ゲームをプレイするユーザ(プレーヤ)の関係プレーヤ(フレンドユーザ)の人数を用いて、当該関係プレーヤのパラメータの変更幅を変更する機能を適宜持たせ、波及先となるフレンドユーザ個別に受ける波及効果の程度を変更することができる。例えば、波及先となるフレンドユーザが複数の場合には、波及効果を人数に応じて均等配分、或いはフレンドユーザに関するパラメータ(例えば、第1ゲームをプレイするユーザ2との好感度などの関係性、アイテム購入履歴、プレーヤレベルなど)に応じて波及効果を配分する(例えば、好感度が高い程、アイテム購入額や購入回数が多いほど、プレーヤレベルが高い程、交配分を受けるように設定する)としても良い。
【0086】
時限制御部233は、一のプレーヤの関係プレーヤ(フレンドユーザ)の波及先のパラメータを向上させる際に、そのパラメータが能力パラメータ値や、ゲーム開始前やゲーム中に実行される抽選に適用される当選確率(例えば、アイテムの出現率なども含まれる)であった場合には、所与の期間一時的に向上させる制御を行う。具体的には、向上前のパラメータ値を一時記憶するとともに当該パラメータ値を向上させる。そして、所与の期間を計時するタイマーを起動させ、計時が完了したらパラメータ値を向上前の値に戻す。なお、向上させるパラメータを行動ポイントAPのみとするのであれば、時限制御部233の機能を無効とし、向上前の値に戻す処理を省略してもよい。
【0087】
発動通知制御部236は、発動条件を満たしたこと、それに伴いプレーヤの第1パラメータが向上されること、またそれに伴いフレンドユーザの第2パラメータ(本実施形態では、第2ゲームでの行動ポイントAP)が変更されること、等をプレーヤのユーザ端末1500に表示させる制御を行う。例えば、
図3の発動通知表示W12を表示させる制御を行う。尚、第1パラメータの変更が時限制の場合には、第1パラメータが変更されている期間に限って通知制御する構成や、変更されるタイミングの開始当初に限定的に通知制御する構成も可能である。
【0088】
受動実行制御部238は、他サーバシステムからの波及制御に従って、他サーバシステムでプレイ中のプレーヤのフレンドユーザ(第1ゲーム管理サーバ制御部210にとってのプレーヤ)に係る第1パラメータを変更する。また、受動実行制御部238は、波及到達通知制御部239を含む。
【0089】
波及到達通知制御部239は、フレンドユーザのゲームプレイに基づく波及効果によりパラメータが変更される旨をプレーヤにアナウンスする波及到達通知W14(
図3参照)をユーザ端末1500に表示させる制御を行う。尚、波及効果が時限制の場合には、パラメータが変更されている期間に限って通知制御する構成や、変更されるタイミングの開始当初に限定的に通知制御する構成も可能である
【0090】
画像生成部260sは、例えば、GPU(Graphics Processing Unit)、デジタルシグナルプロセッサ(DSP)などのプロセッサ、ビデオ信号IC、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ICメモリ、テクスチャデータの展開用に使用されるICメモリ等によって実現される。画像生成部260sは、サーバ処理部200sによる処理結果に基づいて1フレーム時間(例えば1/60秒)で1枚の画面を生成し、生成した画面の画像信号を画像表示部360sに出力する。
【0091】
画像表示部360sは、画像生成部260sから入力される画像信号に基づいて各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管(CRT)、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。本実施形態では、
図1のタッチパネル1108がこれに該当する。
【0092】
通信制御部270sは、データ通信に係るデータ処理を実行し、通信部370sを介して外部装置とのデータのやりとりを実現する。
これに関連する通信部370sは、通信回線1と接続して通信を実現する。例えば、無線通信機、モデム、TA(ターミナルアダプタ)、有線用の通信ケーブルのジャックや制御回路等によって実現される。
【0093】
サーバ記憶部500sは、サーバ処理部200sに諸機能を実現させるためのプログラムやデータを記憶する。また、サーバ処理部200sの作業領域として用いられ、各種プログラムに従って実行した演算結果や、ユーザ端末1500から受信した情報等を一時的に記憶する。こうした機能は、例えばRAMやROMなどのICメモリ、ハードディスク等の磁気ディスク、CD−ROMやDVDなどの光学ディスクなどによって実現される。
図1では、ブレードサーバ1104に搭載されているICメモリ等の情報記憶媒体や、ストレージ1140がこれに該当する。
【0094】
図5は、本実施形態におけるサーバ記憶部500sが記憶する情報の構成例を示す図である。本実施形態のサーバ記憶部500sは、サーバシステムプログラム503と、ゲーム管理サーバプログラム505と、第1ゲームクライアントプログラム507と、第1ゲーム実行用データ509と、第2ゲームクライアントプログラム511と、第2ゲーム実行用データ513と、第1ゲームプレイ中端末リスト515と、第2ゲームプレイ中端末リスト517とを記憶する。また、ユーザ登録データ520と、プレイデータ540と、を記憶する。その他ゲームの管理や、フレンドログインボーナスの付与等に必要な、所定期間のカウント値、各種フラグなどを適宜記憶する。
【0095】
サーバシステムプログラム503は、コンピュータにサーバとしての基本的な機能を実現させるためのプログラムである。サーバ処理部200sに、ユーザ登録情報管理部202、ログイン処理部204、としての機能を実現させることもできる。
【0096】
ゲーム管理サーバプログラム505は、サーバ処理部200sに、ゲーム管理サーバ制御部(本実施形態では、第1ゲーム管理サーバ制御部210、第2ゲーム管理サーバ制御部240)としての機能を実現させるためのプログラムである。
【0097】
第1ゲームクライアントプログラム507は、第1ゲームのプレイを希望するユーザ端末1500に提供するクライアントプログラムの原本である。ユーザ端末1500は、これをダウンロードして、ユーザ端末1500の搭載する情報記憶媒体に記憶させて実行する。第1ゲームクライアントプログラム507は、専用のプログラムや、ウェブブラウサプログラム及びウェブブラウザプログラム上で動的な表示を実現するためのプラグインなどにより実現される。後者の構成は、オンラインゲームを所謂ブラウザゲームとして実現する場合に利用可能である。第2ゲームをユーザ端末1500でプレイするための同様のプログラムが、第2ゲームクライアントプログラム511である。
【0098】
第1ゲーム実行用データ509は、第1ゲームを実行するために必要な各種データを格納する。例えば、ゲームフィールドを設定するためのデータや、プレーヤキャラクタ及び敵キャラクタのモデルデータやモーションデータ、テクスチャデータ、キャラクタの初期能力パラメータ値、ゲーム中で使用可能なアイテムの設定データなどが含まれる。第2ゲームを実行するための同様のデータが、第2ゲーム実行用データ513である。
【0099】
第1ゲームプレイ中端末リスト515と第2ゲームプレイ中端末リスト517は、それぞれ第1ゲーム、第2ゲームをプレイしているユーザ端末1500のリストデータであって、各端末毎のユーザアカウントや、IPアドレスなどを対応づけて格納する。
【0100】
ユーザ登録データ520は、登録ユーザすなわちプレーヤ別に用意され、当該プレーヤに係わる各種情報を格納する。例えば、ログインするために必要なユーザアカウント522とパスワード523を格納する。また、ログイン履歴データ524と、フレンドリスト525と、プレイ登録済ゲームリスト526とを格納する。
【0101】
ログイン履歴データ524は、ログイン、ログアウトの日時等の履歴である。
フレンドリスト525は、フレンドとして登録されている他ユーザに係る情報を格納する。例えば、
図6に示すように、フレンドユーザのユーザアカウント525aと、友好度525bと、チャット履歴データ525cとを対応づけて格納する。
【0102】
プレイ登録済ゲームリスト526は、同一ユーザアカウントでプレーヤ登録したゲームの識別情報を格納する。本実施形態では、第1ゲームと第2ゲームの識別情報が格納されていることになる。
【0103】
プレイデータ540は、ゲームとプレーヤの組み合わせ毎に用意され、当該ゲームの進行状況を記述する各種データを格納する。
例えば
図7に示すように、プレーヤの識別情報であるユーザアカウント541と、ゲームID542と、行動ポイントAPの残り値を格納する残AP544と、ゲーム成績等に応じて自動的に設定されるプレーヤレベル546と、プレーヤキャラクタが得たゲーム世界内での経験値548と、ゲーム世界で使用できるアイテムを購入するための仮想マネー残高550と、プレイした日時のデータを蓄積したプレイ日時履歴552と、所持アイテムリスト554と、プレーヤキャラクタの能力パラメータ値テーブル556と、を格納する。勿論、その他のタイマー値や、各種フラグなどのゲーム進行制御に必要な各種情報を格納することができる。
【0104】
[処理の流れの説明]
次に、
図8を参照しながら、第1ゲームを実行するサーバシステム(本実施形態では、第1ゲーム管理サーバシステム1115)における処理の流れについて説明する。尚、プレーヤは既にユーザアカウントを取得し、何人かの関係ユーザをフレンド登録しているものとする。尚、フレンドリストへのフレンドユーザの登録/抹消は公知技術を適宜利用可能なので、ここでの説明は省略する。
【0105】
第1ゲーム管理サーバ制御部210は、ユーザ端末1500からゲーム開始リクエストを受信すると(ステップS2のYES)、当該ユーザ端末1500を第1ゲームプレイ中端末リスト515に登録し、プレイデータ540のプレイ日時履歴552を更新する(ステップS4)。
【0106】
そして、もしリクエストしてきたユーザ端末1500のプレーヤのユーザアカウントと一致する第1ゲームのプレイデータ540が無ければ(ステップS6のNO)、第1ゲーム管理サーバ制御部210は新規に当該プレーヤのプレイデータ540を生成する(ステップS8)。
【0107】
次に、第1ゲーム管理サーバ制御部210は、プレイ中のゲーム毎にループAを実行する(ステップS40〜S84)。
ループAでは、先ず操作入力に応じたゲーム進行制御を行う(ステップS42)。上述のように、本実施形態のゲームは行動ポイント制なので、プレーヤキャラクタの行動に伴い行動ポイントAPが消費制御される。その一方で、所定単位時間の経過毎に行動ポイントAPの自動回復を行う(ステップS44)。尚、ゲーム進行制御(ステップS42)では、アイテムを購入する操作があればアイテム購入額だけ仮想マネー残高550を減算・更新し、敵キャラクタを倒すことができれば経験値548を高めることができる。
【0108】
次に、第1ゲーム管理サーバ制御部210は、発動検出処理を実行する(ステップS50)。本実施形態では、所定のアイテム使用(AP回復アイテム)を使用する操作入力を検出するが、発動条件の設定によって異なる。例えば、発動条件を特定キャラクタ(例えば、ダンジョンのボスキャラ)の攻略とするならば、当該特定キャラクタのライフポイントが「0」になったことを検出すれば良い。また、発動条件を所定のアイテムの入手とするならば、当該所定アイテムの取得を検出すれば良い。
【0109】
そして、もし発動を検出したならば(ステップS52のYES)、第1ゲーム管理サーバ制御部210は、第1ゲームのプレーヤキャラクタの第1パラメータを向上させる(ステップS54)。本実施形態では、行動ポイントAPを回復させる。もし、発動条件を特定キャラクタの攻略などアイテム以外に設定している場合には、代わりに適宜、経験値548(
図7参照)を向上させるなどの処理を行うと良い。
【0110】
次に、第1ゲーム管理サーバ制御部210は、プレーヤのユーザ端末1500に、発動通知表示W12(
図3参照)を表示させる表示制御を実行する(ステップS56)。
次いで、波及先とするフレンドユーザの選択を行う(ステップS57)。具体的には、例えば第1ゲーム管理サーバ制御部210は第1ゲームのプレーヤのフレンドリスト525を参照し、登録されているフレンドユーザのうち、友好度526b(
図6参照)の大きい順に所定数選択する。或いは、所定の高友好度基準値に達しているフレンドユーザをもれなく選択するとしても良い。或いは別の選択方法として、フレンドユーザのプレイデータ540のプレイ日時履歴552を参照して、プレイ頻度(例えば、所定の単位期間の間のログイン回数)を算出し、プレイ頻度が高い順に所定数のフレンドユーザを選択するとしても良い。
【0111】
次に、第1ゲーム管理サーバ制御部210は、選択した波及先毎にパラメータの向上幅を決定する(ステップS58)。
本実施形態では、現在第1ゲームで使用中のプレイデータ540と、波及先のフレンドユーザのプレイデータ540とを参照して向上幅を決定する。より具体的には、第1ゲーム管理サーバ制御部210は、第2ゲーム管理サーバ制御部240から波及先のフレンドユーザのプレイデータ540を取得する。そして、第1ゲームにおけるプレーヤレベル546と、フレンドユーザの第2ゲームにおけるプレーヤレベル546とを比較する。前者と後者とが同レベルと見なせる場合、又は前者の方が後者より大きい時には向上幅(変更幅)を所定の標準値とする。標準値は、AP回復アイテムの種類によるとしても良い。もし、後者の方が前者よりも大きい場合には、向上幅(変更幅)を、例えばプレーヤレベル546の値の差を変数とする関数によって、そのレベル差が大きい程向上幅が標準値より小さくなるように変更する。
【0112】
更に、第1ゲームにおけるプレイ日時履歴552と、フレンドユーザの第2ゲームにおけるプレイ日時履歴552とから、第1ゲームのプレイ頻度と、フレンドユーザの第2ゲームのプレイ頻度とを求め、前者と後者とが同一と見なせる場合、又は前者の方が後者より頻度が高い場合には、プレーヤレベル546に基づいて決定した向上幅(変更幅)をそのままとする。もし、後者の方が前者よりも高い場合には、先に決定した向上幅(変更幅)を、小さくなるように変更する。
【0113】
尚、このようなプレーヤレベル546やプレイ頻度に基づく向上値の設定に代えて次の方法を採用することもできる。すなわち、第2ゲームの内容に応じて予めプレーヤレベル546と向上幅とを対応づけたテーブルデータを用意しておいて、当該テーブルデータを参照して決定する構成としても良い。具体的には、例えば、第2ゲームにおけるフレンドユーザのプレーヤレベル546がレベル「1」〜レベル「5」まで設定可能な仕様として、レベル「3」なら向上幅を標準値とし、レベルが下がる程標準値より小さい値を設定し、レベルが上がるにつれて標準値より大きい値を設定する。この場合、第1ゲームにおけるプレーヤの習熟度や進捗度、やり込み度合などに関わりなく、第2ゲームにおけるフレンドユーザそれぞれのプレーヤレベルに応じた適当な向上幅を決定できる。
【0114】
或いは、また別の選択肢として、フレンドユーザの第2ゲームのプレイ頻度が所定の希望頻度よりも低い場合には、向上幅(変更幅)を標準値より小さくし、第1ゲームのプレイ頻度と第2ゲームのプレイ頻度がともに希望頻度に達している場合には、標準値よりも大きくする、といった構成も可能である。更に別の選択肢としては、単に第1ゲームのプレーヤレベルの大小に比例して、第2ゲームのパラメータの向上幅を増減するとしても良い。
【0115】
また、向上幅の決定に際して参照するプレイデータ540のデータは、プレーヤレベル546に限らず、経験値548や、仮想マネー残高550を用いることもできる。
また、波及効果を波及先で分け合う構成とする場合には、当該ステップにて波及先個別にパラメータの向上幅を決定することとする。
【0116】
さて、向上幅を決定したならば、第1ゲーム管理サーバ制御部210は、決定した向上幅を用いて波及制御処理を実行する(ステップS60)。
すなわち、第2ゲーム管理サーバシステム1116を外部制御して、第2ゲームにおける波及先に選択されたフレンドユーザのユーザアカウント522のプレイデータ540の残AP544に、ステップS58で個別に決定した向上幅(変更幅)分を加算する。つまりは第2ゲームの行動ポイントAPを回復させる。波及先となる第2パラメータを行動ポイントAP以外に設定している場合、例えば、能力パラメータを第2パラメータとしている場合には、当該ステップにおいて、能力パラメータ値テーブル556の該当値に、先に決定した向上幅(変更幅)分を加算することとする。
もし、波及効果の内容を時限制の内容(例えば、能力パラメータ値や、ゲーム前やゲーム中の抽選で適用される当選確率などを一定時間向上させる内容)の場合には、例えば、向上前のパラメータ値を一時記憶するとともに当該パラメータ値を向上させる。そして、所与の期間を計時するタイマーを起動させ、計時が完了したらパラメータ値を向上前の値に戻す。
【0117】
波及制御処理を実行したならば、第1ゲーム管理サーバ制御部210は、次にゲーム終了条件を満たすかを判定する(ステップS80)。ゲーム終了の操作入力が有った場合、ユーザ端末1500との通信が所定時間以上途絶した場合、ゲームのストーリの最後まで到達した場合など、にゲーム終了条件を満たすと判定する。
そして、もし満たしたならば(ステップS80のYES)、当該ユーザ端末1500を第1ゲームプレイ中端末リスト515から除外して(ステップS82)、ループAを終了する(ステップS84)。
【0118】
実行中の全てのゲームについてループAを実行したならば、第1ゲーム管理サーバ210は、再びステップS2に戻る。
【0119】
図9は、受動実行処理の流れを説明するためのフローチャートである。ここでは、第2ゲーム管理サーバ制御部240が受動実行処理を行うものとして説明する。同処理では、第2ゲーム管理サーバ制御部240は、他ゲーム管理サーバシステム(この場合は、第1ゲーム管理サーバ制御部210、第1ゲーム管理サーバシステム1115)から波及制御のリクエストを受信した場合(ステップS90のYES)、他ゲーム管理サーバシステムからの制御に応じてパラメータを変更する(ステップS92)。本実施形態では、残AP544に、指定された向上幅(変更幅)分を加算して行動ポイントAPを回復させる。
【0120】
そして、第2ゲーム管理サーバ制御部240は、ユーザ端末1500にて波及到達通知W14(
図3参照)を表示させて(ステップS94)、受動実行処理を終了する。
【0121】
以上、本実施形態によれば、一のプレーヤの第1ゲームにおけるゲーム進行状況が、当該第1ゲームと非同期である第2ゲームのフレンドユーザのゲーム進行状況に波及するといった従来に無い機能を実現できる。
より具体的には、第1ゲームで一のプレーヤがAP回復アイテムを使用するなどしてプレーヤにとってメリットのある進行状況が変化し、それが検出されると、第1ゲームにおいて行動ポイントAPが回復するなどのパラメータの向上が行われる。加えて、当該プレーヤのフレンドユーザの第2ゲームでの行動ポイントAPが回復するなどのパラメータの向上(波及制御)が行われる。そして、そのことが発動通知表示W12により第1ゲームのプレーヤのユーザ端末1500に通知される。また、波及先のフレンドユーザのユーザ端末1500においては波及到達表示W14が表示される。よって、一のユーザと関係する関係ユーザとが互いの存在を感じられるようにして、ユーザ間のコミュニケーション活性化や連帯感の向上を図ることができる。
【0122】
また、波及効果を奏する要素をAP回復アイテムなど仮想マネーによる購入の対象とすることとすれば、プレーヤに、自分自身の他、フレンドのためにも使えるアイテムとして認識させることができ、お買い得感を与え、当該アイテムの購入を促進できる。
【0123】
また、第2ゲームのパラメータに波及効果があるといっても、第1ゲームにおけるパラメータ向上幅よりも第2ゲームにおけるパラメータ向上幅は、基本的には同じかそれより下回るように設定されるので、第2ゲームのゲームバランスをいたずらに崩すようなことは起こらない。
【0124】
尚、本実施形態では、第1ゲームから第2ゲームへの波及について述べたが、第1ゲーム管理サーバ制御部210と第2ゲーム管理サーバ制御部240は、同じ機能構成を有しているので、第2ゲームから第1ゲームへの波及も可能である。すなわち、
図8の処理フローの「第1ゲーム」と「第2ゲーム」を逆にして読み替えた処理を第2ゲーム管理サーバ制御部240が実行するとともに、第1ゲーム管理サーバ制御210は
図9の処理を実行する。これにより、第2ゲームから第1ゲームへの波及がなされる。
【0125】
また、本実施形態では波及先を第2ゲーム単独として説明したが、波及先に第3ゲームや第4ゲームと言った具合にその他のゲームを追加設定することもできる。本実施形態における第1ゲームと第2ゲームが同じゲームであっても差し支えないのは勿論である。
【0126】
〔第2実施形態〕
次に、本発明を適用した第2実施形態について説明する。
本実施形態は基本的には第1実施形態と同様の構成を有するが、第2ゲームのパラメータの変更を、第1ゲームを実行するプログラムによる機能の発現としてではなく、第2ゲームを実行するプログラムによる機能の発現として実現する点が異なる。尚、第1実施形態と同様の構成要素については同じ符合を付与して説明は省略するものとする。
【0127】
図10と
図11は、本実施形態における非同期のゲーム間におけるパラメータ変更の波及について説明するための図である。
本実施形態の第1ゲーム管理サーバ制御部210は、第1実施形態のそれのように、第2ゲームのゲームプレイデータ540のパラメータは変更しない。代わりに、
図10に示すように、本実施形態では第1ゲームの進行制御をする第1ゲーム管理サーバ制御部210は、ユーザ2(2a)がプレイする第1ゲーム内で波及効果を発動させるための発動条件が満たされた場合、当該ユーザのプレイデータ540に発動履歴データ560を登録する。
【0128】
発動履歴データ560は、例えば、発動条件ID562と、発動日時564と、波及先ユーザアカウント566とを含む。発動条件ID562は、例えば、発動要件とされるアイテムの種類や、倒すべきキャラクタIDなどである。本実施形態では、第1実施形態と同様にAP回復アイテムとする。発動日時564は、発動条件を満たしたときの日時である。波及先ユーザアカウント566は、波及先とされたフレンドユーザのユーザアカウントのリストである。
【0129】
一方、
図11に示すように、フレンドユーザ2(2c)が、第2ゲームのプレイを開始すると、第2ゲームを進行制御する第2ゲーム管理サーバ制御部240は、ゲーム開始とともに、フレンドユーザ2(2c)のフレンドユーザ(この場合、第1ゲームをプレイしていたユーザ2(2a)が含まれる)のプレイデータ540を参照する。当該プレイデータは、他ゲーム管理サーバ制御部から取得するとしても良い。
【0130】
そして、該当するプレイデータ540に、発動履歴データ560が有り、且つ波及先ユーザアカウント566にフレンドユーザ2(2c)が登録されている場合(
図10参照)、発動条件ID562に応じて第2ゲームのパラメータを変更する。本実施形態では、残AP544を回復させる。すなわち、波及制御を実現できる。
【0131】
そして、第2ゲームのパラメータを変更する際、第2ゲーム管理サーバ制御部240は、第1ゲームの発動履歴データ560の発動日時564からの経過時間に応じてパラメータの変更量を可変する。
例えば、経過時間から所定の全波及発生基準時間(例えば30分)以内であれば、発動条件ID562に応じた向上幅(変更幅)の100%を、第2ゲームのパラメータ変更に適用する。もし、全波及発生基準時間を超過している場合には、超過分に応じて発動条件ID562に応じた向上幅(変更幅)を低減させて第2ゲームのパラメータ変更に適用する。更には、波及中止基準時間(例えば、24時間)を超過した場合には、非同期のゲーム間のパラメータ変更の波及に関する処理をスキップし波及を無効とする。
【0132】
図12は、本実施形態におけるサーバシステム1100の機能構成例を示す機能ブロック図である。本実施形態における機能構成は、基本的には第1実施形態と同様であるが、幾つかの差異がある。
【0133】
先ず、本実施形態のフレンドリスト管理部203は、フレンド登録を、ユーザ相互承諾を経て実行する。すなわち、第1のユーザが第2のユーザをフレンド登録しようとする場合、第2のユーザに承諾が要求される。第2のユーザが承諾すると、第1のユーザと第2のユーザの双方のフレンドリスト525に互いがフレンド登録される。
【0134】
また、本実施形態のプレイデータ管理部214は、発動履歴登録部219を含む。発動履歴登録部219は、発動検出部220により発動条件を満たしたことを検出した場合に、プレーヤのプレイデータ540に発動履歴データ560(
図10参照)を登録する。
【0135】
また、第1実施形態の第2ゲームデータ取得制御部222及び第2ゲームプレイ日時取得制御部224に代えて、これらに相当する他ゲームプレイデータ取得制御部225を有する。他ゲームプレイデータ取得制御部225は、他のゲーム(第2ゲーム管理サーバ制御部240にとっては第1ゲーム、第1ゲーム管理サーバ制御部210にとっては第2ゲーム)のプレイデータ540を取得或いは参照するための制御をする。
【0136】
また、本実施形態では、第1実施形態の波及制御部227に代えて、能動波及制御部227Bを有する。
能動波及制御部227Bは、更に発動履歴検出部228を含む。能動波及制御部227Bは、発動履歴検出部228によって他ゲームプレイデータ取得制御部225により取得・参照可能となったフレンドユーザのプレイデータ540から発動履歴データ560を検出する。そして、発動履歴データ560がある場合には、自ゲームのパラメータを向上幅調整部230で求めた向上幅の分だけ能動的に変更する。
【0137】
加えて、本実施形態の向上幅調整部230は、他ゲームで発動条件を満たした時点からの経過時間に応じて、自ゲームのパラメータ変更に適用される向上幅(変更幅)を決定する経過時間基準変更幅決定部235を含む。
また、本実施形態では、受動実行制御部238は省略されるが、波及到達通知制御239が能動波及制御部227Bに含まれる。
【0138】
尚、第2ゲーム管理サーバ制御部240が第1ゲーム管理サーバ制御部210と同様の機能構成を有するのは第1実施形態と同様である。
【0139】
次に、本実施形態における第2ゲーム管理サーバ制御部240における処理の流れについて説明する。上述のように、第1ゲーム管理サーバ制御部210は第2ゲーム管理サーバ制御部240と同様の機能構成を有するので、ここで説明する処理の流れは、第1ゲーム管理サーバ制御部210における処理の流れと見ることもできる。
【0140】
図13は、本実施形態における第2ゲーム管理サーバ制御部240における処理の流れを説明するためのフローチャートである。基本的には、第1実施形態における処理の流れと同様であるが、本実施形態ではループAを実行する前処理、すなわちゲーム開始前処理として、能動波及制御処理を実行する(ステップS10)。
【0141】
図14は、能動波及制御処理の流れを説明するためのフローチャートである。
同処理において、第2ゲーム管理サーバ制御部240は先ず、ゲーム開始リクエストをしてきたユーザ端末1500のプレーヤのフレンドユーザのプレイデータ540を取得・参照し(ステップS12)、参照先のプレイデータ540に発動履歴データ560が有るかを判定する(ステップS14)。
【0142】
もし、発動履歴データ560があれば(ステップS14のYES)、第2ゲーム管理サーバ制御部240は、発動履歴データ560毎にループBを実行する(ステップS15〜S23)。
ループBでは、第2ゲーム管理サーバ制御部240は、ループBの処理対象とする発動履歴データ560の発動日時564から現在までの経過時間を算出し、所定の波及中止基準時間を経過しているかを判定する(ステップS16)。そして、経過していなければ(ステップS16のNO)、第2ゲーム管理サーバ制御部240は、パラメータの向上幅(変更幅)を1次決定する(ステップS18)。具体的には、自ゲームにおけるプレーヤレベル546や、経験値548、仮想マネー残高550、プレイ日時履歴552から求められるプレイ頻度、などに基づいて、それらが大きい程、大きい向上幅(変更幅)を決定する。
【0143】
次いで、第2ゲーム管理サーバ制御部240は、発動履歴データ560の発動日時564からの経過時間に応じて先に1次決定した向上幅(変更幅)を補正して最終決定し(ステップS20)、最終決定した向上幅(変更幅)だけ自ゲームのパラメータを変更し(ステップS22)、ループBを終了する(ステップS23)。
そして、フレンドユーザのプレイデータ540に含まれていた全ての発動履歴データ560についてループBを実行したならば、第2ゲーム管理サーバ240は、能動波及制御処理を終了する。
【0144】
また、
図13のフローチャートにおいて、本実施形態ではゲーム内で発動条件が満たしたと検出された場合、第1実施形態のステップS58〜S60に代えて、プレーヤのプレイ中のゲームプレイデータ540に発動履歴データ560を登録し(ステップS62)、また既に存在する発動履歴データ560のうち、その発動日時564を起点として所定の保存期間を過ぎた発動履歴データ560を消去する(ステップS64)。
【0145】
〔変形例〕
以上、本発明を適用した2つの実施形態について説明したが、本発明の形態はこれらに限定されるものではなく、適宜構成要素の追加・省略・変更を施すことができる。
【0146】
例えば、第2実施形態において、発動履歴データ560を、プレイデータ540内に格納する構成としているが、ユーザ登録データ520(
図5参照)に格納する構成としても良い。その場合、能動波及制御処理(
図14参照)のステップS12では、ユーザ登録データ520を参照するようにすると良い。
【0147】
また、第2実施形態における発動履歴データ560を、第1実施形態に用いることで、波及制御部227を、プレーヤの第2のパラメータを所与の期間一時的に変更させる制御を実行する一時変更手段として機能させることができる。前提として、第2ゲームにおけるパラメータの変更は、能力値やゲームに関連して適用される当選確率などを一時的に向上させるものとする。
【0148】
具体的には、
図15のフローチャートに示すように、第1実施形態の処理の流れをベースとして、ステップS52に次いで、第1ゲーム管理サーバ制御部210が、波及先を選択して(ステップS53a;第1実施形態のステップS57相当)発動履歴データ560を登録する(ステップS53b)。そして、ステップS58に次いで、第1実施形態のステップS60に代えて、登録されている発動履歴データ560に対応するように波及制御を実行することとする(ステップS66)。具体的には、そのとき発動履歴データ560が有れば、能力値やゲームに関連して適用される当選確率などを向上させ、発動履歴データ560の発動日時564から一定時間が経過していれば、向上させていた能力値や当選確率などを初期値に戻す。そして、第1ゲーム管理サーバ制御部210は、発動日時564から友好度525bに応じた制限期間を過ぎた発動履歴データ560を消去することで(ステップS68)、次のループAの処理タイミングでは発動から一定時間過ぎると第2パラメータ(この場合、能力値や当選確率など)は変更されなくなる。
尚、ステップS68における制限時間は、ループA処理対象のゲームのプレーヤと、波及先のフレンドユーザとの友好度525b(
図6参照)が高いほど(友好度合いが高いほど)、より長い時間となるように所定の関数等で導くと好適である。