JP6678867B2 - サーバ、制御プログラム - Google Patents
サーバ、制御プログラム Download PDFInfo
- Publication number
- JP6678867B2 JP6678867B2 JP2015193862A JP2015193862A JP6678867B2 JP 6678867 B2 JP6678867 B2 JP 6678867B2 JP 2015193862 A JP2015193862 A JP 2015193862A JP 2015193862 A JP2015193862 A JP 2015193862A JP 6678867 B2 JP6678867 B2 JP 6678867B2
- Authority
- JP
- Japan
- Prior art keywords
- user
- battle
- users
- game
- support
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000004891 communication Methods 0.000 claims description 137
- 238000000034 method Methods 0.000 claims description 71
- 230000008569 process Effects 0.000 claims description 60
- 238000012545 processing Methods 0.000 claims description 46
- 230000001186 cumulative effect Effects 0.000 claims 1
- 241000086550 Dinosauria Species 0.000 description 172
- 230000006870 function Effects 0.000 description 41
- 230000004048 modification Effects 0.000 description 29
- 238000012986 modification Methods 0.000 description 29
- 238000010586 diagram Methods 0.000 description 18
- 230000007423 decrease Effects 0.000 description 16
- 230000008901 benefit Effects 0.000 description 9
- 230000004044 response Effects 0.000 description 9
- 230000000694 effects Effects 0.000 description 8
- 230000009467 reduction Effects 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 4
- 230000008859 change Effects 0.000 description 4
- 238000003825 pressing Methods 0.000 description 4
- 238000004904 shortening Methods 0.000 description 4
- 230000008034 disappearance Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000008450 motivation Effects 0.000 description 3
- 238000003860 storage Methods 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 2
- 239000013256 coordination polymer Substances 0.000 description 2
- 230000007123 defense Effects 0.000 description 2
- 239000010409 thin film Substances 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000008033 biological extinction Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 210000003811 finger Anatomy 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 230000008054 signal transmission Effects 0.000 description 1
- 210000003813 thumb Anatomy 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Description
る技術に関する。
おいてウェブブラウザ上で動作するAPI(Application Programming Interface)などの
動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソー
シャルゲーム(Social Game)が普及している。ソーシャルゲームは、不特定多数のユー
ザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言え
る。ユーザは、インターネットに接続可能であって、かつウェブブラウザが搭載された通
信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。
るためのコミュニケーション機能が充実している点が特徴の1つとなっている。ソーシャ
ルゲームでは、例えば、関係付けられたユーザ(仲間)間で協力したゲームの実行のほか
、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間と
の間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。この
ようなソーシャルゲームの一例として、下記の非特許文献1に記載されたデジタルカード
ゲーム(ドラゴンコレクション(登録商標))が知られている。
たゲームが存在する。例えば、所定の期間内で特定のユーザが他のユーザと協力して敵キ
ャラクタを攻撃するように構成されているゲームが知られている。しかしながら、このよ
うな従来のゲームでは、常に固定化した仲間のユーザ同士で協力してゲームを行う傾向に
あり、コミュニケーションの程度が低い他のユーザ、あるいは今までコミュニケーション
をとったことがない他のユーザと協力してゲームを行うように動機付ける仕組みとなって
いなかった。つまり、従来の協力プレイを利用したゲームでは、十分にソーシャル性を発
揮できる仕組みとなっていなかった。
場合に、コミュニケーションの程度が低いユーザ同士、あるいは今までコミュニケーショ
ンをとったことがないユーザ同士で協力してゲームを行うように動機付けることができる
ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的と
する。
ームの実行を制御するゲーム制御装置である。
このゲーム制御装置は、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける対応付け手段(
53)と、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を
実行する実行手段(52)と、
前記イベントに対応付けられたユーザの数に関する情報を取得する取得手段(54)と
、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当
該ユーザに対して、前記取得手段(54)によって取得されたユーザの数に関する情報に
応じた特典を付与する特典付与手段(55)と、
を備える。
協力プレイによるものだけでなく、ユーザの単独プレイによるものが含まれてもよい。
このゲーム制御装置において、「ユーザの数に関する情報」とは、ユーザの数自体を示
す数値データに限られず、当該数値データと同一の値でなくとも当該数値データと連動し
て変動する情報や、当該数値データに対応付けられた情報であってもよい。
ントに参加しているユーザ)の数に応じて、そのイベント内の処理の実行に伴う特典が付
与される。つまり、イベントに対応付けられるユーザが多いほどイベント内の処理の実行
に伴って多くの特典が付与されることになる。つまり、固定化した仲間のユーザ同士でイ
ベント内の処理を実行するよりも、より多くのユーザがイベントに参加することが有利と
なる仕組みとなっている。そのため、このゲーム制御装置によれば、複数のユーザが協力
してイベント内の処理を行う場合に、コミュニケーションの程度が低いユーザ同士、ある
いは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うよ
うに動機付けることができる。
から所定時間が経過したときに、ユーザの前記イベントへの対応付けを解除してもよい。
この構成により、イベントに参加しているユーザの数に応じて特典を得られるという有
利な効果が持続する時間が制限されるため、限られた時間内でのユーザ間のコミュニケー
ションが促進されるとともに、有利な効果が持続し過ぎることないようにゲーム進行にお
けるユーザ間の公平性が担保される。
数)のユーザが前記イベントに対応付けられ、かつ当該ユーザがN−1番目に前記イベン
トに対応付けられたユーザと異なる場合に、前記N番目のユーザが対応付けられてから、
又は前記N番目のユーザによる前記処理の実行が開始若しくは終了してから所定時間が経
過したときに、ユーザの前記イベントへの対応付けを解除してもよい。
この構成により、イベントに対応付けられるユーザが連続して同一ユーザでない場合に
は、既に対応付けられている複数のユーザのイベントへの対応付けは解除されず、イベン
トに対応付けられたユーザの数に応じて特典を得られるという有利な効果が持続する。そ
のため、異なるユーザが入れ替わりイベント内の処理を実行するように動機付けられるこ
とになり、例えばイベントに対応付けられているユーザ間でコミュニケーションをとるこ
とが促進される。
多いほど、前記所定時間を短くしてもよい。
イベントに対応付けられているユーザの数が多いほどより多くの特典が得られる状況と
なるが、そのような状況が長く継続すると、ゲーム進行におけるユーザ間の公平性が担保
されない場合がある。そのため、ユーザの数が多いほど上記所定時間を短くすることで、
ゲーム進行におけるユーザ間の公平性を担保することが好ましい。
行回数が多いほど、前記所定時間を短くしてもよい。
イベントに対応付けられているユーザの数が多いほど、つまりイベント内の処理の実行
回数が多くなるほど、より多くの特典が得られる状況となるが、そのような状況が長く継
続すると、ゲーム進行の公平性が担保されない場合がある。そのため、イベント内の処理
の実行回数が多いほど上記所定時間を短くすることで、ゲーム進行の公平性を担保するこ
とが好ましい。
を受け付けるタイミングで、前記取得手段(54)によって取得されたユーザの数に関す
る情報を、当該ユーザに提示する提示手段(57)を備えてもよい。
このような提示手段(57)を備えることで、例えばイベントに参加する(対応付けら
れる)前にユーザは、既にイベントに参加しているユーザの数がわかるため、これからイ
ベントに参加しようとするときに、ユーザの数に応じた特典の大小を推定できるようにな
る。そのため、ユーザがイベントに参加することに対する動機付けがより強く働かせるこ
とができるようになる。
定の条件を満たす場合に、前記イベントに対応付けられたユーザに対して、さらに特典を
付与してもよい。「所定の条件」は、イベントの種別に応じて適宜決定してよいが、例え
ば、イベントが複数ユーザで協力してバトルを行うことである場合には、「所定の条件」
は、そのバトルで勝利することであってもよい。
この構成では、イベントの結果次第でイベントに参加する(対応付けられる)ユーザに
対して追加の特典が付与されるか否かが決定されるため、既にイベントに参加済みのユー
ザ間で、イベントの結果が所定の条件を満たすように、コミュニケーションをとることが
促進される。
了した時点において前記取得手段(54)によって取得されたユーザの数に関する情報に
応じた特典であってもよい。
この構成では、イベントが終了する時点までにできるだけ多くのユーザがイベントに参
加する(対応付けられる)ことが、既にイベントに参加しているユーザにとって有利であ
る。そのため、ユーザ間で、より多くのユーザがイベントに参加するよう働きかけが行わ
れるようにコミュニケーションをとることが促進される。
数)のユーザが前記イベントに対応付けられ、かつ当該ユーザがN−1番目に前記イベン
トに対応付けられたユーザと同一である場合に、当該ユーザの前記イベントへの対応付け
を解除してもよい。
この構成では、同一のユーザが連続してイベントに対応付けられた場合には、当該ユー
ザのイベントへの対応付けが解除され、イベントに対応付けられたユーザの数が低減する
ことになる。そのため、より多くのユーザの間で入れ替わり対応付けが行われてイベント
内の処理を実行することが動機付けられ、ユーザ間でコミュニケーションをとることが促
進される。
数)のユーザが前記イベントに対応付けられ、かつ当該ユーザがN−1番目までに前記イ
ベントに対応付けられたユーザのうちいずれかのユーザと同一である場合に、当該ユーザ
の前記イベントへの対応付けを解除してもよい。
この構成では、既にイベントに参加済みのユーザが再度イベントに参加して処理を実行
した場合には、当該ユーザのイベントへの対応付けが解除され、イベントに対応付けられ
たユーザの数が低減することになる。つまり、固定化した仲間のユーザ同士で入れ替わり
イベントに参加しても多くの特典を得ることができなくなるため、固定化した仲間のユー
ザ同士でイベント内の処理を実行することが回避される。結果として、複数のユーザが協
力してイベント内の処理を行う場合に、コミュニケーションの程度が低いユーザ同士、あ
るいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行う
ように動機付けることができる。
数)のユーザが前記イベントに対応付けられ、かつ当該ユーザがN−1番目までに前記イ
ベントに対応付けられたユーザのうちいずれかのユーザと同一である場合に、前記所定時
間を短くしてもよい。
この構成では、既にイベントに参加済みのユーザが再度イベントに参加して処理を実行
した場合、イベントに参加しているユーザの数に応じて特典を得られるという有利な効果
が持続する時間が短くなる。そのため、固定化した仲間のユーザ同士で入れ替わりイベン
トに参加しても多くの特典を得る機会が少なくなるため、固定化した仲間のユーザ同士で
イベント内の処理を実行することが回避される。結果として、複数のユーザが協力してイ
ベント内の処理を行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今
までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動
機付けることができる。
ームの実行を制御するゲーム制御方法である。
このゲーム制御方法は、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付けるステップと、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を
実行するステップと、
前記イベントに対応付けられたユーザの数に関する情報を取得するステップと、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当
該ユーザに対して、前記取得するステップによって取得されたユーザの数に関する情報に
応じた特典を付与するステップと、
を備える。
ームの実行を制御するプログラムである。
このプログラムは、
コンピュータに、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける機能、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を
実行する機能、
前記イベントに対応付けられたユーザの数に関する情報を取得する機能、及び、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当
該ユーザに対して、前記取得する機能によって取得されたユーザの数に関する情報に応じ
た特典を付与する機能、
を実現させるためのプログラムである。
プログラムは、DVD−ROMやCD−ROM等のコンピュータが読み取り可能な情報記
憶媒体に格納されてもよい。
(20)とを含み、複数のユーザの協力によって処理が行われるイベントを含むゲームの
実行を制御するゲームシステムである。
このゲームシステムは、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける対応付け手段(
53)、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を
実行する実行手段(52)、
前記イベントに対応付けられたユーザの数に関する情報を取得する取得手段(54)、
及び、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当
該ユーザに対して、前記取得手段(54)によって取得されたユーザの数に関する情報に
応じた特典を付与する特典付与手段(55)、
の各手段を、前記通信端末(10)又は前記サーバ(20)のいずれか一方が備えた、
を備えた、ゲームシステムである。
なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書
きで記載しているが、これにより本発明に係るゲーム制御装置等が図示の態様に限定され
るものではない。
数のユーザが協力してゲームを行う場合に、コミュニケーションの程度が低いユーザ同士
、あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを
行うように動機付けることができる。
図1は、実施形態のゲームシステムのシステム構成例を示している。図1に示すように
、このゲームシステムは、例えばインターネットなどの通信網NW(ネットワーク)に接
続可能な通信端末10a,10b,10c,…と、通信網NWに接続されているゲームサ
ーバ20と、データベースサーバ30とによって構成されている。各通信端末10a,1
0b,10c,…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携
帯端末、スマートフォン、PDA(Personal Digital Assistant)、パーソナルコンピュー
タ、双方向の通信機能を備えたテレビジョン受像機(いわゆる多機能型のスマートテレビ
も含む。)などの通信端末である。なお、以下の説明において、各通信端末10a,10
b,10c,…に共通して言及するときには、通信端末10と表記する。
このゲームシステムにおいて、ゲームサーバ20は、クライアントである通信端末10
と通信可能に構成されており、通信端末10に対してゲーミングサービスを提供する。ゲ
ームサーバ20には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なア
プリケーションが実装されている。データベースサーバ30は、ゲームを実行する上での
後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ20
と例えば有線で接続される。
通信端末10は、ゲームサーバ20によって提供されるウェブページを表示可能なウェ
ブブラウザを備えており、ユーザは、通信端末10でウェブページに対する操作をしてゲ
ームを実行する。
を認証するための認証サーバを設けてもよい。また、多くの通信端末10からのアクセス
を受け入れるために複数のゲームサーバ20を設ける場合は、その複数のゲームサーバ2
0間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ20は
単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構
成してもよい。
図2及び図3を参照して通信端末10について説明する。
図2は、通信端末10の外観の例を示す図であって、(a)は、例えば折り畳み式の携
帯端末(携帯電話機)などの釦入力方式の通信端末を例示したものであり、(b)は、例
えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図3
は、通信端末10の内部構成を示すブロック図である。
図3に示すように、通信端末10は、CPU(Central Processing Unit)11、RO
M(Read Only Memory)12、RAM(Random Access Memory)13、画像処理部14、指示
入力部15、表示部16、及び、信号送受信部としての通信インタフェース部17を備え
ており、各部間の制御信号あるいはデータ信号を伝送するためのバス18が設けられてい
る。
して、CPU11は、指示入力部15等によってユーザに入力されるURL(Uniform Res
ource Locator)の適切な指定に基づき、通信インタフェース部17を介して、ゲームサー
バ20からウェブページを表示するためのデータ、すなわち、HTML(HyperText Marku
p Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ(以下、
総称して適宜「HTMLデータ」と表記する。)を通信インタフェース部17を介して取
得し、そのHTMLデータを解釈する。なお、通信端末10には、ウェブブラウザのブラ
ウザ機能を拡張するための様々なプラグインが実装されていてよい。
なお、HTMLデータの取得に当たって、CPU11は、予め登録されたユーザID(
ユーザ識別情報)、あるいは指示入力部15を介して入力されるユーザIDを含むアクセ
ス要求メッセージを、通信インタフェース部17を介してゲームサーバ20へ通知する。
ムサーバ20から提供されるウェブページを表示部16に表示する。また、ウェブブラウ
ザは、ユーザが指示入力部15の操作によってウェブページ上のハイパーリンク(Hyperli
nk)またはメニューが選択されると、その選択に応じたウェブページを表示するための新
たなHTMLデータの送信(つまり、ウェブページの更新)をゲームサーバ20へ要求す
る。
画像データに基づいて、表示部16にウェブページを表示する。表示部16は、例えば、
マトリクス状に画素単位で配置された薄膜トランジスタを含むLCD(Liquid Cristal Di
splay)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウ
ェブページの画像を表示画面16aに表示する。
ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む
釦群15a、及び、テンキーなどの複数の指示入力釦を含む釦群15bを備え、各釦の押
下(操作)入力を認識してCPU11へ出力するためのインタフェース回路を含む。例え
ば、方向指示釦は、表示部16に表示されているウェブページをスクロールして表示する
ことをCPU11へ指示するために設けられる。また、決定釦は、例えばウェブページ上
で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示(例えば強
調表示)されている1つのハイパーリンクまたはメニューをユーザが選択することをCP
U11へ指示するために設けられる。なお、通信端末10を小型の携帯端末によって構成
する場合には、これらの釦は、ユーザが通信端末10を片手で保持したままその親指で操
作(クリック)しやすいように、通信端末10の前面に配置されていることが好ましい。
図2(a)に示す例では、釦群15bは、釦群15aの下方に配置され、「0」〜「9」
、「*」、「#」(テンキー)が表記された複数の指示入力釦を含む。
部15は、主として表示画面16aに指先あるいはペンで触れることによるタッチパネル
方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよ
い。なお、図2(b)に示すように、通信端末10がタッチパネル入力方式の場合であっ
ても釦群15aが設けられる場合もある。
0が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦
の押下操作によって、選択したメニューを確定することによって行われる。また、選択操
作は、例えば通信端末10がタッチパネル入力方式の場合には、ウェブページが表示され
ている表示画面16a上のメニューの位置を指あるいはペンで指示(タッチ操作)するこ
とによって行われる。
図4を参照してゲームサーバ20の構成について説明する。
ゲームサーバ20は、例えば階層構造の複数のウェブページからなるゲームのウェブサ
イトを管理しており、通信端末10に対してゲームのウェブサービスを提供する。図3に
示すように、ゲームサーバ20は、CPU21、ROM22、RAM23、データベース
(DB)アクセス部24、及び、通信インタフェース部25を備えており、各部間の制御
信号あるいはデータ信号を伝送するためのバス26が設けられている。なお、ゲームサー
バ20は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる
。
文書や画像などのオブジェクトの表示(ウェブページの表示)のサービスを提供するアプ
リケーションプログラムが格納されている。ROM22には、アプリケーションプログラ
ム以外にもCPU21によって参照される各種データが格納されている。
CPU21は、ROM22内のゲームプログラムをRAM23にロードして実行し、通
信インタフェース部25を介して、各種の処理を行う。
末10宛に送信する。なお、ゲームサーバ20が通信端末10のユーザの認証処理を行う
場合には、CPU21はその認証処理を行う。
CPU21は、通信インタフェース部を介して、通信端末10で表示されるウェブペー
ジ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その
処理は、例えば、新たなHTMLデータの送信、または、ゲームサーバ20内の演算処理
あるいはデータ処理などを含む。
データベースアクセス部24は、CPU21がデータベースサーバ30に対してデータ
の読み書きを行うときのインタフェースである。
データベースサーバ30(記憶装置)は、大容量のハードディスク装置やRAID(Re
dundant Arrays of Inexpensive Disks)等の形態の装置等、汎用ストレージで実現でき
る。データベースサーバ30内の各データベースは、ゲームサーバ20のデータベースア
クセス部24を介してCPU21からのデータの読み書きが可能となるように構成されて
いる。
図5に、データベースサーバ30の構成の一例を示す。図5に示すように、データベー
スサーバ30は、ユーザデータベース31と、ゲームデータベース32とを備える。
ではないが、以下では、本実施形態のゲームの一例として、ユーザの通信端末10に対す
る操作に応じて、ユーザがゲーム上で仮想的に保有する戦士カードを用いてエリアを探索
するクエストを実行するデジタルカードゲーム(以下、適宜「本実施形態のゲーム」とい
う。)を採り上げる。後述するように、クエストの途中でゲーム上の恐竜キャラクタとの
間で他のユーザと協力してバトルを行う仕組みとなっている。
。この例では、ユーザデータベース31は、ユーザID(ユーザ識別情報)ごとに、ユー
ザ名、進行レベル、体力ポイント、攻撃ポイント、特典ポイント、恐竜撃破数、仲間のユ
ーザID、保有カードの各項目についてのデータを含む。ユーザデータベース31に含ま
れるデータは、ゲームサーバ20によって逐次更新されうる。
定するユーザ名(後述する)ごとのデータを総称してユーザデータという。ユーザデータ
を構成する各項目のデータの内容は、以下のとおりである。
・ユーザ名
ゲームの実行時に通信端末10のユーザを特定するために表示されるユーザ名である。
ユーザ名はユーザによって予め指定される所定長以下のテキストである。ユーザ名は、ゲ
ームサーバ20によって提供されるネットワーク環境(あるいはゲームコミュニティ)上
でユーザを特定する名称である。
・進行レベル
ゲーム上のユーザの進行レベル示すデータである。例えばLv1(レベル1)からLv
100(レベル100)までの範囲のレベル値である。ユーザがクエストを実行すること
で経験値が増加し、経験値が一定値に達すると進行レベルが1だけ増加し、経験値がリセ
ットされる(ゼロになる)。
・体力ポイント
クエストを実行する毎に所定量減少し、所定の時間が経過する毎に回復(増加)するポ
イントである。ユーザがクエストを実行するときの体力の値を示している。
・攻撃ポイント
本実施形態のゲームにおいて、戦士カードを使用した恐竜キャラクタとのバトルを行う
上で必要となるポイントである。ユーザは、1又は複数の保有カードによって恐竜キャラ
クタとバトルを行うときの攻撃チームを組むことができるが、攻撃チームに含まれる保有
カードのポイント消費量(攻撃ポイントの消費量)の総和が攻撃ポイントを超えることは
できない。攻撃ポイントは、恐竜キャラクタと1回のバトルを行うことで、攻撃チームに
含まれる保有カードのポイント消費量の総和が低減し、所定の時間が経過する毎に回復(
増加)する。
・特典ポイント
恐竜キャラクタとバトルを行ったときに恐竜キャラクタに与えたダメージに応じて得ら
れる特典である。
・恐竜撃破数
本実施形態のゲームにおいて、ユーザがバトルによって撃破した恐竜キャラクタの数で
ある。
・仲間のユーザID
対象となるユーザIDと関係付けられた他のユーザIDのデータである。
・保有カードのデータ
保有カードのデータは、ユーザが保有している戦士カード(保有カード)のデータであ
り、例えば、図6に示すように、戦士カードのカードID(WR080等)と、ポイント
消費量(攻撃ポイントの消費量)と、攻撃力及び防御力のパラメータの値とから構成され
る。本実施形態のゲームでは、戦士カードが恐竜キャラクタとバトルを行うときに、攻撃
力の値が大きいほど恐竜キャラクタに対して多くのダメージを与えることができ、防御力
の値が大きいほど恐竜キャラクタから攻撃を受けたときにダメージを受け難くすることが
できる設定となっている。
ゲームサーバ20によって実行されたゲームの進行に関する情報、恐竜キャラクタに関す
るデータ(恐竜キャラクタデータ)、バトル管理データを記憶する。ゲームの進行に関す
る情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例
に挙げれば、ゲームの進行に関する情報は、各ユーザのクエストの実行結果や、恐竜キャ
ラクタとのバトルの詳細情報などを含んでもよい。
なる恐竜キャラクタに関するデータを含む。恐竜キャラクタデータは、恐竜キャラクタに
固有のキャラクタID(DC1,DC2,DC3,…)ごとに、恐竜キャラクタの画像と
、恐竜キャラクタの体力を示すHP(Hit Point)の値とが対応付けられている。例えば、
図7に示す例では、各恐竜キャラクタのHPは1500〜2000の範囲内であるが、こ
の範囲の中からバトルを行うときにランダムにHPの値が設定されてもよい。
後述するように、恐竜キャラクタデータの中からバトル相手となる恐竜キャラクタが選
択されると、その恐竜キャラクタのデータが例えばRAM23にロードされる。
にバトル管理データのデータ構成例を示す。図8に示すバトル管理データでは、ユーザ(
ユーザ名又はユーザID)ごとに、バトルID、バトル相手、消滅時刻、バトル履歴、残
HP、追撃レベル、追撃終了時刻、及び、撃破フラグの各項目についてのデータを含む。
各項目のデータの内容は、以下のとおりである。
恐竜キャラクタが出現したときに、その恐竜キャラクタと行われる一連のバトルを識別
するための識別情報(図8の例では、識別番号)である。本実施形態のゲームでは、ユー
ザがクエストを実行中に恐竜キャラクタと遭遇し、その恐竜キャラクタとのバトルが開始
されるが、恐竜キャラクタと遭遇したユーザを、以下の説明では「発見ユーザ」という。
バトル管理データでは、バトルIDは、発見ユーザに対応付けて記述される。
発見ユーザと恐竜キャラクタとの間のバトル、及び、後述する支援ユーザと恐竜キャラ
クタとのバトルはすべて、共通のバトルIDに対応付けて管理される。なお、発見ユーザ
と恐竜キャラクタとの間のバトル、及び、後述する支援ユーザと恐竜キャラクタとのバト
ルを総称して、「恐竜キャラクタとのバトル」と適宜表記する。なお、本発明のイベント
は、複数のユーザによって処理が行われるイベントであるが、本実施形態において、発見
ユーザ及び支援ユーザによる共通の恐竜キャラクタとのバトルは、イベントの一例である
。
・バトル相手
特定のバトルにおいてバトルの相手となる恐竜キャラクタを示す。
・消滅時刻
特定のバトルにおいてバトル相手の恐竜キャラクタが消滅する時刻である。本実施形態
のゲームでは、恐竜キャラクタを消滅時刻までに撃破した場合に、恐竜撃破数が増加する
。
・バトル履歴
本実施形態のゲームでは、発見ユーザが恐竜キャラクタを撃破できなかった場合には、
発見ユーザは他のユーザに対して支援要請を行うことができ、支援要請を受諾したユーザ
がその恐竜キャラクタとバトルを行うことができるように構成されている。支援要請を受
諾してバトルを行うユーザを、以下の説明では「支援ユーザ」という。
バトル履歴の項目には、発見ユーザ(図8の例では、ユーザKNM)と、バトルに対応
付けられた1又は複数の支援ユーザ(図8の例では、ユーザABC,ユーザQRS)が順
に記述されている。また、発見ユーザと支援ユーザの各々と恐竜キャラクタとのバトルに
よる恐竜キャラクタのHP低下量が記述される。
・残HP
バトル相手の恐竜キャラクタの残りのHPを示す。図8の例では、発見ユーザであるユ
ーザKNMと恐竜キャラクタのバトルの結果、恐竜キャラクタの残HPが2000から1
100まで低下したことを意味している。
・追撃レベル
特定のバトルにおいて、支援を行ったユーザの数(つまり、特定のバトルに対応付けら
れた、異なるユーザIDの支援ユーザの数)と同一の値である。追撃レベルは、後述する
追撃終了時刻まで上昇可能な値である。本実施形態のゲームでは、同一の攻撃チームを使
用する場合に、追撃レベルが増加すればするほど、恐竜キャラクタに与えるダメージ(つ
まり、HPの低下量)がより大きくなるように構成されている。
・追撃終了時刻
追撃レベルが上昇可能な追撃期間の終期である。追撃終了時刻に達すると、追撃レベル
がリセットされる(つまり、ゼロに戻る)。
・撃破フラグ
バトル相手の恐竜キャラクタが撃破されたか否かを示すフラグである。撃破フラグが「
0」である場合には恐竜キャラクタが撃破されていないことを意味し、撃破フラグが「1
」である場合には恐竜キャラクタが撃破されたことを意味する。
以下、本実施形態のゲームの恐竜キャラクタとのバトル処理について、図9〜14を参
照しながら説明する。
図9は、ユーザがクエスト実行中に恐竜キャラクタと遭遇するときのウェブページの表
示例を示す図である。図10は、発見ユーザが恐竜キャラクタとバトルを行うときのウェ
ブページの表示例を示す図である。図11は、発見ユーザが支援要請を行うときのウェブ
ページの表示例を示す図である。図12は、1番目の支援ユーザが恐竜キャラクタとバト
ルを行うときのウェブページの表示例を示す図である。図13は、2番目の支援ユーザが
恐竜キャラクタとバトルを行うときのウェブページの表示例を示す図である。図14は、
バトルに参加しているユーザ間でメッセージの送受信を行うときのウェブページの表示例
を示す図である。
なお、以下の説明において、通信端末10に表示されるウェブページ上で表示されるメ
ニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末1
0で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいは
タッチパネル操作によるウェブページのスクロール操作によって変化しうる。
図9のトップページP0は個々のユーザIDに応じたウェブページで構成されるが、図
9の例では、ユーザKNMのトップページP0を示している。
図9の例では、トップページP0は、ユーザデータ表示領域、戦士画像表示領域及びメ
ニュー表示領域を含む。ユーザデータ表示領域は、対象となるユーザIDのユーザデータ
に含まれる、進行レベル、体力ポイント、攻撃ポイント、特典ポイント、恐竜撃破数の各
項目のデータ(図6参照)が表示される領域である。
戦士画像表示領域は、対象となるユーザIDのユーザデータに含まれる複数の戦士カー
ドのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
メニュー表示領域は、本実施形態のゲームにおいて、クエスト処理の実行を開始するた
めのメニューm1を含む複数のメニュー(メニューm1以外は図示せず)が表示される領
域である。なお、クエスト処理とは、アイテムを取得するためにエリアを探索する処理で
ある。
うにウェブページが更新される。このウェブページP1には、ユーザがクエストとしてエ
リアを探索するためのメニューm5(「探索する」)が含まれる。メニューm5が選択操
作される度に、所定の、あるいはランダムな確率で、ゲーム上で用意されている様々なア
イテムのいずれかをユーザが入手できるように構成してもよい。メニューm5が選択操作
される度に一定の、あるいはランダムな増加量で進行度の値が増加し、進行度が100%
に達するとエリアの探索が終了する。メニュー5が選択操作される度に、ユーザKNMの
体力ポイントが所定量だけ消費され(図9の例では、−5)、ユーザKNMの経験値が所
定量だけ増加する(図9の例では、+8)。探索対象のエリアは、複数設けられてもよく
、実行中のエリアの達成率が100%に達すると次のエリアに移動できるとしてもよい。
体力ポイントが上記所定量未満になった場合にはクエスト処理を実行することはできな
い。その場合には、体力ポイントが回復するまでユーザKNMは待機する必要がある。
のクエストが完了すると、ユーザKNMは恐竜キャラクタに遭遇する仕組みとなっている
。例えば、図9のウェブページP2では、ユーザKNMが遭遇した恐竜キャラクタDC1
(「恐竜DC1」)の画像と、メニューm10(「バトルする」)及びメニューm11(
「バトルしない」)とが含まれる。この場合、発見ユーザは、ユーザKNMである。ウェ
ブページP2においてメニューm10が選択操作されると、P3に示すようにウェブペー
ジが更新される。このウェブページP3では、例えば、遭遇した恐竜キャラクタが消滅す
るまでの時間(つまり、消滅時刻までの時間)と、プルダウンメニューm15とが表示さ
れる。
かを選択することができるように設定されている。この場合、プルダウンメニューm15
に設定される複数の攻撃チームは、例えば、以下のように予め設定されてもよいが、ウェ
ブページP3が表示される時点でユーザKNMの攻撃ポイントが少ない場合には、選択で
きない攻撃チームもありうる。
・攻撃チーム1:ユーザの攻撃ポイントの最大値の100%を消費して、ユーザが保有
する戦士カードの中から編成した攻撃チーム
・攻撃チーム2:ユーザの攻撃ポイントの最大値の60%を消費して、ユーザが保有す
る戦士カードの中から編成した攻撃チーム
・攻撃チーム3:ユーザの攻撃ポイントの最大値の30%を消費して、ユーザが保有す
る戦士カードの中から編成した攻撃チーム
図9のウェブページP3においてユーザKNMの攻撃チームが選択操作されると、図1
0のP4に示すようにウェブページが更新される。すなわち、選択された攻撃チームに含
まれる戦士カードを使用してユーザKNMが恐竜キャラクタDC1との間でバトルを実行
するためのウェブページに切り替わる。
ウェブページP4は、ユーザKNMがバトルで使用する複数枚の戦士カードからなる攻
撃チームTMの画像と、バトル相手の恐竜キャラクタDC1の画像と、恐竜キャラクタD
C1のHP(Hit Point)を示すHPゲージと、メニューm20(「攻撃する」)とを含む
。HPは、恐竜キャラクタの体力を示す値である。ユーザKNMが使用する戦士カードが
すべて倒される前に恐竜キャラクタのHPをゼロにできれば、ユーザKNMがバトルに勝
利して恐竜キャラクタDC1を撃破したことを意味し、ユーザKNMが使用する戦士カー
ドがすべて倒された時点で恐竜キャラクタのHPがゼロになっていなければ、ユーザKN
Mがバトルで敗北したことを意味する。
ブページが更新される。ウェブページP5では、ウェブページP4と比べて、ユーザKN
Mがバトルに使用する戦士カードによって恐竜キャラクタDC1に対する攻撃が行われ、
その結果、恐竜キャラクタのHPが低下した場合が示されている。なお、メニューm20
が選択操作される度にバトル相手の恐竜キャラクタから戦士カードに対して攻撃が加えら
れる。
ウェブページP6に示すように、恐竜キャラクタDC1のHPがゼロに達した時点で攻
撃チーム内のいずれかの戦士カードが倒されずに残っていれば、ユーザKNMがバトルに
勝利し、恐竜キャラクタDC1が撃破されたことになる。
にすべての戦士カードが倒されると、ユーザKNMがバトルに敗北したことになる。ウェ
ブページP7では、ユーザKNMとのバトルによって恐竜キャラクタDC1が怯んだ状態
となっていることが通知される。恐竜キャラクタが怯んだ状態となっている期間が、追撃
レベルが上昇可能な追撃期間である。ウェブページP7の例では、追撃期間が8分である
こと(「復活まで、あと8分!」)と表示されている。この追撃期間内に、恐竜キャラク
タに対して攻撃が行われた場合には、通常よりも多くのダメージを恐竜キャラクタに与え
られるように構成されている。また、恐竜キャラクタDC1の消滅時刻までの時間(ウェ
ブページP7の例では、20分)も表示されている。ウェブページP7が表示される時点
では、支援ユーザが1度もバトルを実行していないため、追撃レベルが「0」と表示され
ている。
ウェブページ7には、他のユーザに対して支援要請を行うためのメニューm21(「支
援要請する」)と、再度自ら攻撃を行うためのメニューm22(「もう一度攻撃する」)
とが表示される。例えば、図9のウェブページP3において攻撃チーム3を選択した場合
等、少ない攻撃ポイントを消費してウェブページP4,P5での攻撃を行った場合には、
ユーザKNMの攻撃ポイントが十分に残っている場合がある。その場合には、ユーザKN
Mは、メニューm22を選択して直ちに恐竜キャラクタDC1と再度バトルを行うことが
できる。
なお、ウェブページP7では、メニューm21及びメニューm22を設けた例について
説明したが、これに限られない。ユーザKNMが敗北した場合に、自動的に他のユーザに
支援要請が行われるようにしてもよい。その場合には、ウェブページP7には、ユーザK
NMが敗北したため支援要請が行われたことを通知するテキストが表示される。
図11のウェブページP7(図10のウェブページP7と同じ)において、メニューm
21(「支援要請する」)が選択操作されると、P8に示すようにウェブページが更新さ
れて、ユーザKNMの支援要請が受け付けられたことが通知される。
なお、図9〜11に関連付けて、発見ユーザが恐竜キャラクタを撃破できなかったとき
に、発見ユーザが他のユーザに対して支援要請を行う場合について説明したが、これに限
られない。発見ユーザは、自ら恐竜キャラクタとのバトルを行わずに支援要請を行うこと
ができるようにしてもよい。その場合には、図9のウェブページP2において、支援要請
を行うためのメニューを設けるようにすればよく、当該メニューの選択操作に応じて、ユ
ーザKNMの支援要請が受け付けられる。
図12に示す例では、1番目の支援ユーザがユーザABCである場合を例にしている。
ユーザKNMによる支援要請が受け付けられると、その支援要請を例えばクエストを実
行中の他のユーザが閲覧することができる仕組みとなっている。図12のウェブページP
9は、ユーザABCがクエストを実行中に表示されるウェブページであり、ユーザKNM
からの支援要請を受諾するか否かを選択するためのメニューm31(「受諾する」)及び
メニューm32(「受諾しない」)が表示されている。好ましくは、ウェブページP9で
は、支援対象のバトルについての情報として、バトル相手の恐竜キャラクタ及び残HPの
データ、恐竜キャラクタの消滅時刻までの残り時間(20分)、追撃終了時刻までの残り
時間(8分)、及び現在の追撃レベル(0)の例が表示されている。
のウェブページP3に示したのと同様に攻撃チームを選択するためのウェブページ(図示
せず)が表示され、ユーザABCと恐竜キャラクタDC1とのバトルが開始される。恐竜
キャラクタDC1のHPゲージは、図10のウェブページP7で表示されているものと同
じ値となっている。バトルが開始された後のウェブページの表示の変化は、発見ユーザと
恐竜キャラクタDC1とのバトルと同様であるが、ウェブページP10では、追撃レベル
が0→1に上昇して表示される。つまり、支援ユーザABCによるバトルの開始によって
、支援ユーザの数が0→1と変化したため、追撃レベルが0→1に上昇している。
た場合の表示例がウェブページP11に示されている。ウェブページP11に示すように
、恐竜キャラクタDC1のHPがゼロに達する前にすべての戦士カードが倒されると、ユ
ーザABCがバトルに敗北したことになる。ウェブページP11では、ユーザABCとの
バトルによって恐竜キャラクタDC1が怯んだ状態となっていることが通知される。ウェ
ブページP11の例では、追撃期間が3分であること(「復活まで、あと3分!」)と表
示されている。この追撃期間内に、恐竜キャラクタに対して攻撃が行われた場合には、通
常よりも多くのダメージを恐竜キャラクタに与えられるように構成されている。また、恐
竜キャラクタDC1の消滅時刻までの時間(ウェブページP11の例では、15分)も表示
されている。ウェブページP11が表示される時点では、支援ユーザが1人であるため、
追撃レベルが「1」と表示されている。
ウェブページP11には、再度自ら攻撃を行うためのメニューm22(「もう一度攻撃
する」)が表示される。ユーザABCの攻撃ポイントが十分に残っている場合には、ユー
ザABCは、メニューm22を選択して直ちに恐竜キャラクタDC1と再度バトルを行う
ことができる。
図13に示す例では、2番目の支援ユーザがユーザQRSである場合を例にしている。
2番目の支援ユーザは、発見ユーザによる支援要請を2番目に受諾したユーザである。
図13のウェブページP12は、ユーザQRSがクエストを実行中に表示されるウェブ
ページであり、ユーザKNMからの支援要請を受諾するか否かを選択するためのメニュー
m31(「受諾する」)及びメニューm32(「受諾しない」)が表示されている。好ま
しくは、ウェブページP12では、支援対象のバトルについての情報として、バトル相手
の恐竜キャラクタ及び残HPのデータ、恐竜キャラクタの消滅時刻までの残り時間(15
分)、追撃終了時刻までの残り時間(3分)、及び現在の追撃レベル(1)の例が表示さ
れている。
9のウェブページP3に示したのと同様に攻撃チームを選択するためのウェブページ(図
示せず)が表示され、ユーザQRSと恐竜キャラクタDC1とのバトルが開始される。恐
竜キャラクタDC1のHPゲージは、図12のウェブページP11で表示されているもの
と同じ値となっている。バトルが開始された後のウェブページの表示の変化は、1番目の
支援ユーザと恐竜キャラクタDC1とのバトルと同様であるが、ウェブページP13では
、追撃レベルが1→2に上昇して表示される。つまり、支援ユーザQRSによるバトルの
開始によって、支援ユーザの数が1→2と変化したため、追撃レベルが1→2に上昇して
いる。
ジP14に示されている。ウェブページP14に示すように、恐竜キャラクタDC1のH
Pがゼロに達した時点で攻撃チーム内のいずれかの戦士カードが倒されずに残っていれば
、ユーザQRSがバトルに勝利し、恐竜キャラクタDC1が撃破されたことになる。
「バトルに参加しているユーザ」とは、発見ユーザと支援ユーザを意味する。
本実施形態のゲームでは、恐竜キャラクタに遭遇してからその恐竜キャラクタが撃破さ
れるか、消滅するまでの間(つまり、恐竜キャラクタとのバトルが行われている間)、そ
のバトルに参加しているユーザ間でメッセージの送信及び受信が可能となるように構成さ
れている。図14では、発見ユーザKNMと1番目の支援ユーザABCとの間で、メッセ
ージの送信及び受信が行われる場合が例示されている。
けのウェブページ上では、特定のバトルに参加しているユーザ(発見ユーザと支援ユーザ
)のリストが表示される。発見ユーザであるユーザKNM向けのリストには、支援ユーザ
であるユーザABC,ユーザQRSが選択操作可能に表示される。ウェブページP15に
おいて例えばユーザABCが選択操作されると、P16に示すようにウェブページが更新
される。ウェブページP16には、選択されたユーザABC宛てのメッセージを入力する
ためのテキストボックスb1とメニューm40(「送信」)が表示されている。
した状態でメニューm40が選択操作されると、メッセージがゲームサーバ20へ送信さ
れる。メッセージがゲームサーバ20に正しく受信されると、そのメッセージがゲームサ
ーバ20に受け付けられる。
ユーザKNMからのメッセージが受け付けられた後、例えばクエストを実行中のユーザ
ABC向けのウェブページが更新されると、更新後のウェブページには、P17に示すよ
うにユーザKNMからのメッセージが表示される。
次に、上述した本実施形態のゲームを実現するためゲーム制御装置における各処理につ
いて説明する。
本実施形態では、ゲームサーバ20及びデータベースサーバ30によってゲーム制御装
置が構成されている。以下では、上述したデジタルカードゲームが適用される場合を例と
して、本実施形態のゲーム制御装置で実現される機能について、図15を参照して説明す
る。図15は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための
機能ブロック図である。なお、図15の機能ブロック図中、登録手段51及び通信手段5
6は、必ずしも必須の構成要素ではない。
適切な操作入力に基づいてユーザの登録要求を認識し、登録処理を行う機能を備える。こ
の登録処理は、ユーザが本実施形態のゲームにユーザ登録を行うときに実行される。
登録手段51の機能は、例えば以下のように実現される。ゲームサーバ20のCPU2
1は、通信インタフェース部25を介して通信端末10から登録要求メッセージを受信す
る。登録要求メッセージは、ゲームサーバ20から提供されるウェブページ上での通信端
末10に対する所定の操作(例えば、所定のメニューの選択操作やユーザが指定するユー
ザIDやパスワード等のテキスト入力等)によって自動的に生成されるように、ウェブペ
ージが構成されていてもよい。登録要求メッセージには、送信元の通信端末10を特定す
るための情報(例えばUID(Unique Identifier)などの端末の個体識別情報、メール
アドレス等)が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者によ
る他のゲームを利用している場合には、そのユーザIDが含まれていてもよい。
れていない場合には、ユーザIDを新規に発行してそのユーザIDの登録処理を行った後
、登録処理が完了した旨のメッセージを通信端末10へ送信する。CPU21は、登録要
求メッセージを受信し、登録要求メッセージにユーザIDが含まれている場合には、その
ユーザIDの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを
通信端末10へ送信する。
登録が完了すると、CPU21は、ユーザIDに対応するユーザデータを生成し、ユー
ザデータベース31に格納する。登録が完了すると、ユーザは、本実施形態のゲームを実
行することが可能となる。
つまり、登録手段51は、例えばユーザIDに基づく申請を契機として、当該ユーザID
を他のユーザIDとを関連付けて記録してもよい。すなわち、登録手段51は、ユーザI
Dに基づく申請を契機として、他のユーザID(つまり、他のユーザ)を「仲間」として
記録してもよい。
この場合の登録手段51の機能は例えば、以下のように実現される。ゲームサーバ20
aのCPU21は、通信インタフェース部25を介して、あるユーザIDに対応するユー
ザの通信端末10から、仲間になりたいユーザID(あるいは、対応するユーザ名)を指
定した申請メッセージ(仲間申請)を受け付ける。この申請メッセージの送信は、ユーザ
の通信端末10に提供されるウェブページの機能として予め設定されてもよい。
CPU21は、申請メッセージを受け付けると、申請先ユーザのユーザデータの「仲間
申請」の項目に申請元ユーザのユーザIDを書き込む。さらにCPU21は、申請メッセ
ージに含まれるユーザIDに基づくアクセスがあったタイミングで、そのユーザIDに対
応する通信端末10宛に、他のユーザIDに基づく申請を承認するか否かを返信すること
を要求するウェブページを表示するためのHTMLデータを送信する。その申請を承認す
ることが返信されれば、CPU21は、両者を仲間として登録する。具体的には、CPU
21は、ユーザデータベース31内の対応する2つのユーザIDのユーザデータの「仲間
のユーザID」の箇所(図6参照)にデータ(相手のユーザID)を書き込む。なお、C
PU21は、仲間申請先のユーザの承認を不要とする場合は、ゲームを実行中のユーザに
よる所定の操作を契機として、両者を仲間として登録しても良い。
ゲーム実行手段52の機能は、例えば、通信端末10に表示するウェブページを、通信
端末10からの要求に応じて逐次更新させることによって、ゲーム上のバトルを実行する
ようにしてもよい。この場合、ゲーム実行手段52の機能を実現するために、ゲームサー
バ20のCPU21は、通信端末10からHTTPリクエストを受信し、そのHTTPリ
クエストに応じてゲーム上の所定の処理を行い、ゲームの実行結果としてのHTMLデー
タを含むHTTPレスポンスを通信端末10へ返信する。
実行対象のゲームの内容が例えば図9に関連付けて説明したクエストである場合、ゲー
ムサーバ20のCPU21は、ユーザによるメニューm5(「探索する」)の選択操作結
果を含むHTTPリクエストを受信すると、処理対象のユーザの進行度、体力ポイント、
及び経験値を更新する処理を行う。CPU21は、ユーザの進行度、体力ポイント、及び
経験値のデータを、クエストの実行開始時(メニューm1の選択時)にデータベースサー
バ30からRAM23に転送し、クエスト中はRAM23内のデータに対して更新処理を
行い、クエスト終了時に、RAM23内の更新後のデータをデータベースサーバ30内の
データに上書きするようにしてもよい。
メニューm5の選択操作に応じてランダムなタイミングで、あるいは、所定数のエリア
のクエストが完了すると、CPU21は、ユーザを恐竜キャラクタに遭遇させることを決
定する。このとき、CPU21は、恐竜キャラクタデータにアクセスして遭遇対象(つま
りバトル相手)となるいずれかの恐竜キャラクタを例えばランダムに選択する。
ゲーム実行手段52は、恐竜キャラクタとのバトル処理において、特定のバトル(イベ
ント)の発見ユーザ及び支援ユーザ(イベントに対応付けられたユーザ)の入力情報に基
づいて、当該バトル内の処理を実行する機能を備える。本実施形態では、入力情報は、ユ
ーザの選択操作結果を含むHTTPリクエストである。
とができる。ゲームサーバ20のCPU21は先ず、実行対象のゲームの内容が例えば図
10に関連付けて説明した恐竜キャラクタとのバトルである場合、選択した恐竜キャラク
タとのHPを恐竜キャラクタデータから読み出してRAM23に記憶させるとともに、読
み出したデータに基づいてHTMLデータを生成する。
ザが保有する戦士カードの中からバトルで使用される戦士カードを選択する。
例えば、上述した攻撃チーム1が選択された場合には、CPU21は、ユーザの攻撃ポ
イントの最大値の100%を消費してユーザの保有カードの中から戦士カードを選択する
。このとき、CPU21は、例えば攻撃力の高い戦士カードから順に選択するとともにポ
イント消費量を積算していき、その積算値が攻撃ポイントの最大値の100%を超えない
範囲で最大枚数の戦士カードを選択する。戦士カードを選択した後は、CPU21は、ユ
ーザの現在の攻撃ポイントからポイント消費量の積算値を減算して新たな攻撃ポイントを
算出し、ユーザデータに記憶する。
上述した攻撃チーム2が選択された場合には、CPU21は、ユーザの攻撃ポイントの
最大値の60%を消費してユーザの保有カードの中から戦士カードを選択する。このとき
、CPU21は、例えば攻撃力の高い戦士カードから順に選択するとともにポイント消費
量を積算していき、その積算値が攻撃ポイントの最大値の60%を超えない範囲で最大枚
数の戦士カードを選択する。戦士カードを選択した後は、CPU21は、ユーザの現在の
攻撃ポイントからポイント消費量の積算値を減算して新たな攻撃ポイントを算出し、ユー
ザデータに記憶する。
上述した攻撃チーム3が選択された場合には、CPU21は、ユーザの攻撃ポイントの
最大値の30%を消費してユーザの保有カードの中から戦士カードを選択する。このとき
、CPU21は、例えば攻撃力の高い戦士カードから順に選択するとともにポイント消費
量を積算していき、その積算値が攻撃ポイントの最大値の30%を超えない範囲で最大枚
数の戦士カードを選択する。戦士カードを選択した後は、CPU21は、ユーザの現在の
攻撃ポイントからポイント消費量の積算値を減算して新たな攻撃ポイントを算出し、ユー
ザデータに記憶する。
き込む。このとき、恐竜キャラクタのデータのHPの初期値がランダムに決定される。例
えば、恐竜キャラクタデータにおいて恐竜キャラクタDC1のHPが1500〜2000
の範囲として設定されているが、実際のバトル処理を行うときに使用されるHPの初期値
として、1500〜2000の範囲の中からランダムに1つの値が決定される。
トルで使用される戦士カードのデータをユーザデータから読み出して、RAM23に記憶
させ、以下のバトル処理を実行する。
具体的には、恐竜キャラクタとのバトルにおいて例えばメニューm20(「攻撃する」
)が選択操作され、ユーザが戦士カードを使って恐竜キャラクタを攻撃するとき(例えば
図10のウェブページP4,P5等)には、CPU21は、使用される攻撃チームを構成
する戦士カードの攻撃力の総和に応じて恐竜キャラクタのHPを低減させる処理を行う。
なお、バトル中に倒された戦士カードの攻撃力については、攻撃力の総和の算出対象とは
ならない。以下、メニューm20(「攻撃する」)に対する操作を「攻撃操作」という。
例えば、攻撃チームの攻撃力の総和をPaとし、追撃レベルに応じて決定される係数を
kとすると、1回の攻撃操作によって、恐竜キャラクタのHPに対して行われる演算は、
例えば以下の式(1)に従って行われるようにしてもよい。更新されたHPの値は、バト
ル実行中に逐次RAM23に上書きされる。
HP=HP−Pa×k …(1)
・追撃レベルが0のときに、k=1.0
・追撃レベルが1のときに、k=1.2
・追撃レベルが2のときに、k=1.4
・追撃レベルが3のときに、k=1.6
などとテーブル形式で規定してもよい。
また、追撃レベルをLとしたときに、k=(1+L)と演算式によって求めるようにし
てもよい。いずれの場合も、追撃レベルが上昇するほど、つまり支援ユーザの数が増加す
るほど、ユーザの攻撃チームによる攻撃によって、より多くのダメージ(HPの低下量)
が恐竜キャラクタに与えられるような仕組みとなっている。
、あるいはランダムな値の攻撃力にて攻撃が加えられる。恐竜キャラクタの攻撃力は、H
Pに概ね比例した値としてもよいし、一定の、あるいはランダムな値であってもよい。C
PU21は、例えば、恐竜キャラクタから攻撃チームに対して加える攻撃力、あるいはそ
の攻撃力の積算値(複数回の攻撃操作に伴う攻撃力の積算値)に応じて、ユーザの攻撃チ
ームのうち倒される戦士カードの枚数を決定する。倒される戦士カードの枚数は、例えば
、戦士カードに含まれる戦士カードの防御力の総和が大きいほど少なくしてもよい。
CPU21は、攻撃チームに含まれる戦士カードがすべて倒され、かつ恐竜キャラクタ
のHPがゼロになっていない場合には、ユーザの敗北であると判断する。他方、CPU2
1は、攻撃チームに含まれる少なくとも1枚の戦士カードが倒されずに残っており、かつ
恐竜キャラクタのHPがゼロになった場合には、ユーザの勝利であると判断する。
ば、上記式(1)におけるPaは戦士カードの攻撃力ではなく、所定の範囲の中から攻撃
操作に応じてランダムに決定される数値としても良い。その場合も、追撃レベルが上昇す
ればするほど恐竜キャラクタのHPの低下量が大きくなるように設定する。
定のバトル(イベント)に対応付ける機能を備える。
対応付け手段53の機能は、以下のようにして実現することができる。ゲームサーバ2
0のCPU21は、発見ユーザからの支援要請を受け付けると、例えばRAM23内に、
発見ユーザのユーザIDと対応付けて支援要請フラグをセットする。発見ユーザ以外のユ
ーザであって、かつクエストを実行中のユーザの通信端末10からHTTPリクエストを
受信した場合、CPU21は、発見ユーザと対応付けられた支援要請フラグがセットされ
ているか否かを判定し、セットされている場合には、発見ユーザからの支援要請を受諾す
るか否かを問い合わせるためのメニューを含むHTMLデータを生成して、HTTPリク
エストに対する返信を行う。それによって、発見ユーザ以外のユーザであって、かつクエ
ストを実行中のユーザの通信端末10には、例えば図12のP9に例示したウェブページ
が表示される。この問い合わせに対して、支援要請を受諾することを含むHTTPリクエ
ストを受信した場合には、CPU21は、HTTPリクエストの送信元の通信端末10の
ユーザを支援ユーザとして、対象となるバトルに対応付ける。この対応付けは、具体的に
は、後述するように、対象となるバトルIDに対応付けて支援ユーザのユーザIDがバト
ル管理データに書き込まれることによって行われる。
に関する情報として、追撃レベルの情報を取得する機能を備える。本実施形態では、「特
定のバトルの支援ユーザの数」は、特定のバトルIDのバトルにおいて、重複しないユー
ザIDを備えた支援ユーザの数であり、追撃レベルに相当する。
取得手段54の機能を実現するために、ゲームサーバ20のCPU21は、ユーザが恐
竜キャラクタに遭遇した時点、発見ユーザ及び支援ユーザと恐竜キャラクタのバトルが開
始及び終了する時点で、バトル管理データを更新する処理を行う。具体的には、以下のと
おりである。
ル管理データに書き込む。CPU21は、バトル相手の恐竜キャラクタを恐竜キャラクタ
データから選択すると、その恐竜キャラクタのキャラクタIDをバトルIDと対応付けて
バトル管理データに書き込む。CPU21は、消滅時刻として例えばユーザが恐竜キャラ
クタに遭遇した時点から起算して所定時間後(例えば30分後)に設定して、バトル管理
データに書き込む。
CPU21は、発見ユーザ及び支援ユーザの各々と恐竜キャラクタのバトルが開始する
時点で、発見ユーザ及び支援ユーザの各々のユーザIDをバトルIDと対応付けてバトル
管理データに書き込む。
時点で、発見ユーザ及び支援ユーザの各々のユーザIDと対応付けて、追撃レベルをバト
ル管理データに書き込む。このとき、CPU21は、発見ユーザ(図8の例では、ユーザ
KNM)に対応する追撃レベルを「0」とし、1番目の支援ユーザ(図8の例では、ユー
ザABC)に対応する追撃レベルを「1」とする。CPU21は、N番目(N:2以上の
整数)の支援ユーザに対応する追撃レベルは決定するに当たって、N番目の支援ユーザの
ユーザIDと、既に書き込み済みの発見ユーザ及び1〜N−1番目の支援ユーザの各々の
ユーザIDとを比較する。その結果、一致するユーザIDが存在する場合には、CPU2
1は、N番目の支援ユーザに対応する追撃レベルを、N−1番目の支援ユーザに対応する
追撃レベルと同一とする。他方、一致するユーザIDが存在しない場合には、CPU21
は、N番目の支援ユーザに対応する追撃レベルを、N−1番目の支援ユーザに対応する追
撃レベルに1加えた値とする。このような算出方法により、特定のバトルIDのバトルで
は、追撃レベルは、重複しないユーザIDを備えた支援ユーザの数と同一となる。
時点で、RAM23内のデータを基に、発見ユーザ及び支援ユーザの各々のユーザIDと
対応付けて、恐竜キャラクタのHP低下量と残HPをバトル管理データに書き込む。CP
U21は、バトル相手の恐竜キャラクタが撃破されたか否か(つまり、HPがゼロになっ
たか否か)に応じて、撃破フラグをバトル管理データに書き込む。
また、CPU21は、恐竜キャラクタが撃破された場合(つまり、HPの値がゼロにな
った場合)には、発見ユーザ及び支援ユーザの各々のユーザデータの恐竜撃破数を1だけ
増加させる。
、バトル管理データに書き込む。追撃終了時刻の設定時刻は、特に限定されるものではな
いが、例えば、ユーザが恐竜キャラクタに遭遇した時点から起算して所定時間後(例えば
20分後)の時刻であってもよい。また、後に変形例で述べるように、追撃終了時刻の設
定時刻は、支援ユーザのバトル実行状況に応じて設定されてもよい。
なお、CPU21は、現在時刻が追撃終了時刻に達した場合には、追撃レベルとしてゼ
ロを書き込む。
ユーザのバトル内の処理の実行によって、当該ユーザに対して、取得手段54によって取
得された支援ユーザの数に関する情報、つまり追撃レベルに応じた特典を付与する機能を
備える。本実施形態では、「バトル内の処理の実行」は、例えば攻撃操作の実行に相当す
る。
追撃レベルに応じた特典の一例は、特定のバトルにおいて、発見ユーザ及び支援ユーザ
の各々に対して、各ユーザが恐竜キャラクタに与えたダメージ(つまり、HP低下量)に
応じた特典であってもよい。式(1)により示したように、HP低下量は、Pa×k(P
a:攻撃チームの攻撃力の総和、k:追撃レベルに応じて増加する係数)によって定まる
ため、追撃レベルが上昇するほど多くのダメージを恐竜キャラクタに与えることができ、
より大きい特典をユーザが得ることができる。
特典は、例えばゲーム上の特典ポイントとして付与することができる。特典ポイントは
、その大きさに応じて例えば体力ポイントやゲーム上の様々なアイテムと交換可能であっ
てもよい。
0のCPU21は、例えばバトルが終了したタイミングで、バトル管理データにアクセス
し、発見ユーザ及び支援ユーザの各々のHP低下量を読み出す。次いでCPU21は、読
み出したHP低下量に基づいて、発見ユーザ及び支援ユーザの各々に付与すべき特典ポイ
ントを算出する。特典ポイントを算出するに当たって、CPU21は、HP低下量と特典
ポイントの関係を記述したROM22内のデータ(図示せず)を参照してもよいし、HP
低下量に対して所定の演算式を当てはめて特典ポイントを算出する。いずれの場合でも、
HP低下量が大きいほど特典ポイントが大きくなるように設定される。
なお、ユーザに特典ポイントを付与するタイミングは、適宜設定することができる。C
PU21は、バトルが終了する都度に、算出した特典ポイントをユーザに付与してもよい
し、恐竜キャラクタとのバトルの結果が決定するか、あるいは恐竜キャラクタが消滅した
後に、一括して(つまり、それまで算出した特典ポイントを積算して)ユーザに付与して
もよい。なお、ユーザへの特典ポイントの付与は、例えばユーザデータに特典ポイントを
記憶させることであってもよい。特典ポイントがユーザに付与された場合には、その都度
ユーザに通知することが好ましい。
通信手段56の機能は、例えば、図14に示したユーザKNMとユーザABC間のメッ
セージの送受信を例にすると、以下のようにして実現できる。ゲームサーバ20のCPU
21は、ユーザKNMの通信端末10から、入力されたメッセージとその送信先のユーザ
(この場合、ユーザABC)の情報を含むHTTPリクエストを受信すると、メッセージ
とその送信先のユーザの情報を一時的に記憶する。次いでCPU21は、ユーザABCの
通信端末10からクエストについてのHTTPリクエスト(例えば、図9のメニューm1
又はm5の選択操作結果を含むHTTPリクエスト)を受信すると、そのHTTPリクエ
ストに応じた実行結果とともに、一時的に記憶しておいたユーザKNMからのメッセージ
を含むようにしてHTMLデータを生成して、ユーザABCの通信端末10へ送信する。
それによって、ユーザABCの通信端末10に、ユーザKNMからのメッセージが表示さ
れる。
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について
、図16A及び図16Bのシーケンスチャートを参照して説明する。図16A及び図16
Bは、本実施形態のゲーム制御装置によって行われる、本実施形態のゲームのバトル処理
を示している。図16A及び図16Bでは、図11〜13に記載された各ウェブページが
表示されるタイミングを符号により示している。なお、図16A及び図16Bでは、図9
〜13で示したように、発見ユーザがユーザKNMであり、1番目の支援ユーザがユーザ
ABC、2番目の支援ユーザがユーザQRSである場合を例として示している。
れることが想定されている(ステップS100)。このバトル処理では、ゲームサーバ2
0のCPU21は、ユーザKNMによる攻撃操作結果を含むHTTPリクエストを受信す
ると、例えば上記式(1)に従って、ユーザKNMによって予め選択された攻撃チームを
構成する戦士カードの攻撃力の総和に応じて恐竜キャラクタDC1のHPを低減させる処
理を行う。また、CPU21は、攻撃操作に応じてバトル相手の恐竜キャラクタDC1か
ら攻撃チームに対して、一定の、あるいはランダムな値の攻撃力にて攻撃を加える処理を
行う。例えば、CPU21は、恐竜キャラクタDC1から攻撃チームに対して加える攻撃
力を例えばランダムに決定し、その攻撃力あるいはその攻撃力の積算値(複数回の攻撃操
作に伴う攻撃力の積算値)に応じて、ユーザの攻撃チームのうち倒される戦士カードの枚
数を決定する。
CPU21は、図8に例示したバトル管理データのユーザKNM(ユーザID:0000
01)に対応付けて記載されているように、HP低下量、残HP、追撃終了時刻、撃破フ
ラグの値を書き込むことによってバトル管理データを更新する(ステップS110)。こ
こでは、発見ユーザであるユーザKNMがバトルに敗北した場合が想定されており、撃破
フラグには「0」が書き込まれる。
ユーザKNMが敗北した後、支援要請を行うためのメニューの選択操作に応じて、ユー
ザKNMの通信端末10は、支援要請を行うためのメニューの選択操作結果を含むHTT
Pをゲームサーバ20へ送信する(ステップS120)。ゲームサーバ20は、ユーザK
NMからの支援要請を受け付けると、支援要請を受け付けたことを示すテキストを含むH
TMLデータを生成して、ユーザKNMの通信端末10へ送信する(ステップS130)
。次いで、CPU21は、例えばRAM23内に、発見ユーザであるユーザKNMのユー
ザIDと対応付けて支援要請フラグをセットする(ステップS140)。
中の他のユーザの通信端末10からHTTPリクエストを受信した場合、CPU21は、
発見ユーザと対応付けられた支援要請フラグがセットされているか否かを判定し、セット
されている場合には、発見ユーザからの支援要請を受諾するか否かを問い合わせるための
メニューを含むHTMLデータを生成して、HTTPリクエストに対する返信を行う(ス
テップS150)。この問い合わせに対して、支援要請を受諾することを含むHTTPリ
クエストを受信した場合には、CPU21は、HTTPリクエストの送信元の通信端末1
0のユーザを支援ユーザとして、対象となるバトルに対応付ける。図16Aの例では、ユ
ーザABCが、ユーザKNMからの支援要請を受諾するメニューを選択操作し(ステップ
S160:YES)、それによってユーザABCの通信端末10は、その選択操作結果(
支援要請の受諾)を含むHTTPリクエストをゲームサーバ20へ送信する(ステップS
170)。このHTTPリクエストを受信すると、ゲームサーバ20は、バトル履歴の欄
に1番目の支援ユーザであるユーザABCのユーザIDを書き込み、かつ追撃レベルを「
1」と書き込むことによって、バトル管理データを更新する(ステップS180)。
プS190)。CPU21は、ステップS190のバトル処理における恐竜キャラクタの
初期HPとして、発見ユーザであるユーザKNMに対応する残HPをバトル管理データか
ら読み出し、RAM23に転送してから処理を行う。ステップS190のバトル処理の内
容は、ステップS100と同様であるが、追撃レベルが「1」であるため、追撃レベルが
「0」のときよりも上記式(1)におけるkが増加し、ユーザABCは、恐竜キャラクタ
DC1に対してより多くのダメージ(Pa×k)を与えやすくなっている。
、バトル管理データを更新する(ステップS200)。具体的には、CPU21は、図8
に例示したバトル管理データのユーザABC(ユーザID:000333)に対応付けて
記載されているように、HP低下量、残HP、追撃終了時刻、撃破フラグの値を書き込む
ことによってバトル管理データを更新する。ここでは、1番目の支援ユーザであるユーザ
ABCがバトルに敗北した場合が想定されており、撃破フラグには「0」が書き込まれる
。
仮に、ユーザABCがバトルに勝利した場合には(つまり、撃破フラグ=1の場合には
)、支援要請フラグがリセットされるが(ステップS210)、この例では、撃破フラグ
=0であるため、支援要請フラグはリセットされない。
諾するメニューを選択操作し(ステップS220:YES)、それによってユーザQRS
の通信端末10は、その選択操作結果(支援要請の受諾)を含むHTTPリクエストをゲ
ームサーバ20へ送信する(ステップS230)。このHTTPリクエストを受信すると
、ゲームサーバ20は、バトル履歴の欄に2番目の支援ユーザであるユーザQRSのユー
ザIDを書き込み、かつ追撃レベルを「2」と書き込むことによって、バトル管理データ
を更新する(ステップS240)。
プS250)。CPU21は、ステップS250のバトル処理における恐竜キャラクタの
初期HPとして、直前の1番目の支援ユーザであるユーザABCに対応する残HPをバト
ル管理データから読み出し、RAM23に転送してから処理を行う。ステップS250の
バトル処理の内容は、ステップS190と同様であるが、追撃レベルが「2」であるため
、追撃レベルが「1」のときよりも上記式(1)におけるkが増加し、ユーザQRSは、
恐竜キャラクタDC1に対してより一層多くのダメージ(Pa×k)を与えやすくなって
いる。
、バトル管理データを更新する(ステップS260)。具体的には、CPU21は、図8
に例示したバトル管理データのユーザQRS(ユーザID:123455)に対応付けて
記載されているように、HP低下量、残HP、追撃終了時刻、撃破フラグの値を書き込む
ことによってバトル管理データを更新する。ここでは、2番目の支援ユーザであるユーザ
QRSがバトルに勝利した場合が想定されており、撃破フラグには「1」が書き込まれ、
それによって支援要請フラグがリセットされる(ステップS270)。支援要請フラグが
リセットされると、発見ユーザ(この例では、ユーザKNM)以外のユーザ向けのHTM
Lデータに、発見ユーザからの支援要請を受諾するか否かの問い合わせが含まれないよう
になる。
ため、CPU21は、特典ポイントを算出し(ステップS280)、算出したポイントを
通知するためのHTMLデータを生成して、バトルに参加したユーザ(発見ユーザKNM
、1番目の支援ユーザABC、2番目の支援ユーザQRS)の通信端末10へ送信する(
ステップS290)。なお、CPU21は、例えば、バトル管理データにアクセスし、発
見ユーザKNM、1番目の支援ユーザABC、2番目の支援ユーザQRSの各々に対応付
けられたHP低下量(つまり、恐竜キャラクタDC1に与えたダメージ)のデータを読み
出し、そのHP低下量に応じた特典ポイントを算出する。
支援ユーザとして対応付けられるユーザの数(あるいは、バトルに参加しているユーザ数
)に応じて、そのバトルにおいて恐竜キャラクタに与えたダメージに応じた特典ポイント
(イベント内の処理の実行に伴う特典)が付与される。つまり、支援ユーザの数が多いほ
どバトルにおける攻撃操作によって恐竜キャラクタに与えるダメージが大きくなり、それ
によって多くの特典ポイントがユーザに付与されることになる。支援ユーザの数が多いほ
ど有利となるため、バトルに参加していないユーザがバトルに参加することが動機付けら
れる。言い換えれば、固定化した仲間のユーザ同士でイベント内の処理を実行するよりも
、より多くのユーザがイベントに参加することが有利となる仕組みとなっている。そのた
め、本実施形態のゲーム制御装置によれば、複数のユーザが協力して恐竜キャラクタに対
するバトルを行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今まで
コミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動機付
けることができる。
P12に示したように、発見ユーザからの支援要請を受諾するか否かの問い合わせを表示
するウェブページにおいて、現在の追撃レベルを含むバトルについての情報を表示する好
ましい表示形態の例を示しているが、このようなバトルについての情報は表示しなくても
よい。なお、このウェブページにおいて、現在の追撃レベルを表示することで、バトルに
参加する(支援ユーザとして対応付けられる)前にユーザは、既に支援ユーザとして対応
付けられているユーザの数がわかるため、これからバトルに参加しようとするときに、ユ
ーザの数に応じた特典ポイントの大小を推定できるようになる。そのため、ユーザがバト
ルに参加することに対する動機付けがより強く働かせることができるようになる。
ブロック図は、図15に示したものと比較して、提示手段57が追加された点が異なる。
提示手段57は、ユーザを特定のバトル(イベント)の支援ユーザとして対応付けるた
めのユーザの入力を受け付けるタイミングで、取得手段54によって取得された支援ユー
ザの数に関する情報、つまり追撃レベルの情報を、当該ユーザに提示する機能を備える。
この「ユーザの入力」は、例えば図12のウェブページP9、及び図13のウェブページ
P12に示したように、他のユーザからの支援要請を受諾するか否かについての選択を行
うためのユーザの操作入力である。提示手段57の機能を実現するために、ゲームサーバ
20のCPU21は、支援要請を含むHTMLデータを生成するに当たって、バトル管理
データの追撃レベルの値を読み出して、HTMLデータに含めるようにする。
以下、上述した実施形態の変形例について説明する。
上述した実施形態では、支援ユーザの数を追撃レベルとしたが、単に支援ユーザの数に
よって追撃レベルを決定するのではなく、支援ユーザのうち、ある程度の攻撃ポイントを
消費して攻撃を行った支援ユーザの数を追撃レベルとしてもよい。例えば、支援ユーザが
恐竜キャラクタとのバトルを行うに当たって、攻撃チーム1(ユーザの攻撃ポイントの最
大値の100%を消費)又は攻撃チーム2(ユーザの攻撃ポイントの最大値の60%を消
費)を選択した支援ユーザの数を追撃レベルとしてもよい。つまり、攻撃チーム3(ユー
ザの攻撃ポイントの最大値の30%を消費)を選択した支援ユーザは、恐竜キャラクタに
対する攻撃に積極的に関与しなかったものとして、追撃レベルを算出する上で除外する。
このような構成とすることで、積極的にバトルに参加するユーザ同士のコミュニケーシ
ョンを活性化させることができる。
本変形例を実現するために、ゲームサーバ20のCPU21は、追撃レベルを更新する
に当たって、支援ユーザの攻撃チームの選択結果に基づいて、バトル管理データにその支
援ユーザのユーザIDを書き込むか否かを決定する。あるいは、CPU21は、支援ユー
ザの攻撃チームの選択結果如何に関わらず、すべての支援ユーザのユーザIDと選択した
攻撃チームとをバトル管理データに書き込んでおき、攻撃チーム3を選択した支援ユーザ
を、追撃レベルの算出の基礎としないようにしてもよい。
上述した実施形態において、対応付け手段53は、特定のバトル(イベント)の開始時
刻から所定時間が経過したときに、ユーザのバトルへの支援ユーザとしての対応付けを解
除してもよい。なお、「全ての支援ユーザとしての対応付けの解除」は、実質的に追撃レ
ベルをゼロにすることに等しい。
この構成により、バトル(イベント)に対応付けられたユーザの数に応じて特典を得ら
れるという有利な効果が持続する時間が制限されるため、限られた時間内でのユーザ間の
コミュニケーションが促進されるとともに、有利な効果が持続し過ぎることないようにゲ
ーム進行におけるユーザ間の公平性が担保される。
本変形例を実現するために、ゲームサーバ20のCPU21は、例えば、発見ユーザが
恐竜キャラクタと遭遇した時刻、又は発見ユーザと恐竜キャラクタとのバトルの開始時刻
を起点として、所定時間後を追撃終了時刻として設定する。CPU21は、追撃終了時刻
までに支援要請を受諾したユーザを支援ユーザとして対応付け、それによって追撃レベル
を上昇させる。
また、CPU21は、所定時間が経過し追撃終了時刻に達した場合には、支援要請は行
わず、追撃レベルをリセットする(ゼロにする)。あるいは、CPU21は、所定時間が
経過し追撃終了時刻に達した場合には、追撃レベルを直ちにゼロにするのではなく、段階
的に低下させてもよい。例えば、CPU21は、追撃終了時刻に達してから所定時間毎に
追撃レベルを1つずつ低下させてもよいし、恐竜キャラクタと、当該バトルに支援ユーザ
として対応付けられるユーザをランダムに、又は、所定の規則(例えば、対応付けられた
順序等)に基づいて、解除しても良い。
上述した実施形態において、対応付け手段53は、N番目(N:2以上の整数)のユー
ザが特定のバトル(イベント)に支援ユーザとして対応付けられ、かつ当該ユーザがN−
1番目にバトルに支援ユーザとして対応付けられたユーザと異なる場合に、N番目のユー
ザが対応付けられてから、又はN番目のユーザによる処理の実行が開始若しくは終了して
から所定時間が経過したときに、ユーザのバトルの支援ユーザとしての対応付けを解除し
てもよい。なお、「全ての支援ユーザとしての対応付けの解除」は、実質的に追撃レベル
をゼロにすることに等しい。
この構成により、バトル(イベント)に支援ユーザとして対応付けられるユーザが連続
して同一ユーザでない場合には、既に対応付けられている複数のユーザのバトルへの対応
付けは解除されず、バトルに支援ユーザとして対応付けられたユーザの数に応じて特典を
得られるという有利な効果が持続する。そのため、異なるユーザが入れ替わりバトル内の
処理を実行するように動機付けられることになり、例えばバトルに支援ユーザとして対応
付けられているユーザ間でコミュニケーションをとることが促進される。
図18を参照して説明する。図18は、本変形例において、バトル管理データの更新例を
説明するための図である。図18(a)は、特定のバトルにおいて発見ユーザ及び支援ユ
ーザの各々のバトル期間、及び追撃終了時刻の変化の一例を時間軸に沿って示しており、
図18(b)は、追撃レベルの変化の一例を時間軸に沿って示している。
る。ユーザU1が支援ユーザとして対応付けられると、追撃レベルが「1」に上昇すると
ともに、その対応付けの時点から追撃終了時刻が例えば10分間(所定時間)に設定され
る。
次に、ユーザU2が支援ユーザとして対応付けられると、追撃レベルが「1」から「2
」に上昇するとともに、その対応付けの時点から追撃終了時刻が例えば10分間(所定時
間)に設定される。つまり、追撃レベルが上昇可能な追撃期間が延長される。ここで、ユ
ーザU2がバトルに敗北した後に再度自らバトルを行う場合を想定する。この場合には、
2番目と3番目の支援ユーザが同一であるため、追撃レベルは上昇せずに「2」のままで
あり、かつ追撃終了時刻が変更されない(*1)。つまり、追撃期間が延長されない。
」に上昇するとともに、その対応付けの時点から追撃終了時刻が例えば10分間(所定時
間)に設定される。つまり、追撃レベルが上昇可能な追撃期間がさらに延長される。
次の支援ユーザであるユーザU1は直前の支援ユーザであるユーザU3と異なるユーザ
であるため、追撃終了時刻が変更される(追撃期間が延長される)が、1番目の支援ユー
ザと同一であるため、追撃レベルは上昇せずに「3」のままである。最後に、ユーザU4
が支援ユーザとして対応付けられると、追撃レベルが「3」から「4」に上昇するととも
に、その対応付けの時点から追撃終了時刻が例えば10分間(所定時間)に設定される。
つまり、追撃レベルが上昇可能な追撃期間がさらに延長される。
撃期間は、その直前の支援ユーザと同一のユーザでない場合に延長してもよい。これによ
って、追撃レベルがリセットされない有利な状況を継続させることを目的として、異なる
ユーザが入れ替わり支援ユーザとなってバトルを行うように動機付けられる。
本変形例を実現するために、ゲームサーバ20のCPU21は、同一の支援ユーザが連
続してバトルを行う場合(例えば、図12のメニューm22が選択操作された場合)、又
は、同一のユーザが連続して支援ユーザとして対応付けられた場合には、追撃終了時刻を
変更せず、そうでない場合に追撃終了時刻を更新してバトル管理データに書き込む。更新
後の追撃終了時刻は、最新の支援ユーザが対応付けられてから、又は、その支援ユーザに
よる攻撃操作が行われたときから、若しくはその支援ユーザによるバトルが終了してから
所定時間が経過した時刻に設定される。
上述した変形例3において、取得手段54によって取得されたユーザの数が多いほど、
すなわち追撃レベルが大きいほど、変形例3における所定時間を短くしてもよい。
上述した実施形態の構成では、バトル(イベント)に支援ユーザとして対応付けられて
いるユーザの数が多いほどより多くの特典が得られる状況となるが、そのような状況が長
く継続すると、ゲーム進行におけるユーザ間の公平性が担保されない場合がある。そのた
め、ユーザの数が多いほど変形例3における所定時間を短くすることで、ゲーム進行にお
けるユーザ間の公平性を担保することが好ましい。
本変形例を実現するために、ゲームサーバ20のCPU21は、追撃終了時刻を更新し
てバトル管理データに書き込む場合に、追撃レベルの大きさに応じて追撃終了時刻までの
時間を設定する。追撃終了時刻までの時間を設定するに当たって、CPU21は、追撃レ
ベルと追撃終了時刻までの時間の予め既知の関係を参照してもよいし、追撃レベルを所定
の演算式に当てはめて追撃終了時刻までの時間を算出してもよい。
上述した実施形態において、ゲーム実行手段52による特定のバトル(イベント)内の
処理の実行回数が多いほど、前記所定時間を短くしてもよい。
上述した実施形態の構成では、バトル(イベント)に支援ユーザとして対応付けられて
いるユーザの数が多いほど、つまりバトルの処理の実行回数が多くなるほど、より多くの
特典が得られる状況となるが、そのような状況が長く継続すると、ゲーム進行の公平性が
担保されない場合がある。そのため、バトルの処理の実行回数が多いほど上記所定時間を
短くすることで、ゲーム進行の公平性を担保することが好ましい。
本変形例を実現するために、ゲームサーバ20のCPU21は、特定のバトルが開始さ
れてから攻撃操作結果を含むHTTPリクエストの受信回数をカウントする。そしてCP
U21は、追撃終了時刻を更新してバトル管理データに書き込む場合に、受信回数のカウ
ント値の大きさに応じて追撃終了時刻までの時間を設定する。追撃終了時刻までの時間を
設定するに当たって、CPU21は、受信回数のカウント値と追撃終了時刻までの時間の
予め既知の関係を参照してもよいし、受信回数のカウント値を所定の演算式に当てはめて
追撃終了時刻までの時間を算出してもよい。
上述した実施形態において、特典付与手段55は、特定のバトル(イベント)の結果が
所定の条件を満たす場合に、当該バトルに対応付けられたユーザに対して、さらに特典を
付与してもよい。「所定の条件」は、本実施形態の場合、バトル相手の恐竜キャラクタを
撃破してバトルで勝利することである。
特典は、例えばゲーム上の特典ポイントとして付与することができる。特典ポイントは
、その大きさに応じて例えば体力ポイントやゲーム上の様々なアイテムと交換可能であっ
てもよい。
この構成では、バトルの結果次第でバトルに参加するユーザ(発見ユーザ及び支援ユー
ザ)に対して追加の特典が付与されるか否かが決定されるため、既にバトルに参加済みの
ユーザ間で、バトル相手の恐竜キャラクタを撃破してバトルで勝利するように、コミュニ
ケーションをとることが促進される。
本変形例における特典付与手段55の機能は、例えば以下のようにして実現することが
できる。ゲームサーバ20のCPU21は、例えばバトルが終了したタイミングで、バト
ル管理データにアクセスし、撃破フラグを確認し、撃破フラグが「1」である場合には、
発見ユーザ及び支援ユーザの各々に追加の特典ポイントを付与することを決定する。特典
ポイントの量及び配分方法は、適宜決定することができる。1つのバトルについて勝利し
たときに付与される特典ポイントの量が固定である場合には、CPU21は、その特典ポ
イントを、発見ユーザ及び支援ユーザの各々に均等配分してもよいし、HP低下量に応じ
た比率(つまり、貢献度合い)に基づいて配分してもよい。
上述した変形例6において、特定のバトル(イベント)の結果が所定の条件を満たす場
合に付与される特典は、当該バトルが終了した時点において取得手段54によって取得さ
れたユーザの数に関する情報、すなわち追撃レベルに応じた特典であってもよい。
この構成では、バトルが終了する時点までにできるだけ多くのユーザがバトルに参加す
る(対応付けられる)ことが、既にバトルに参加しているユーザにとって有利である。そ
のため、ユーザ間で、より多くのユーザがバトルに参加するよう働きかけが行われるよう
にコミュニケーションをとることが促進される。
本変形例では、ゲームサーバ20のCPU21は、1つのバトルについて勝利したとき
に付与される追加の特典ポイントの量を、バトル終了時点の追撃レベルによって決定する
。つまり、CPU21は、バトル終了時点の追撃レベルが大きいほど、特典ポイントの量
を多くする。CPU21は、特典ポイントを算出するに当たって、追撃レベルと特典ポイ
ントの予め既知の関係を参照してもよいし、追撃レベルを所定の演算式に当てはめて特典
ポイントを算出してもよい。CPU21は、算出した特典ポイントを、発見ユーザ及び支
援ユーザの各々に均等配分してもよいし、HP低下量に応じた比率(つまり、貢献度合い
)に基づいて配分してもよい。
上述した実施形態において、対応付け手段53は、N番目(N:2以上の整数)のユー
ザが特定のバトル(イベント)に対応付けられ、かつ当該ユーザがN−1番目にバトルに
対応付けられたユーザと同一である場合に、当該ユーザのバトルへの対応付けを解除して
もよい。
この構成では、同一のユーザが連続してバトルに支援ユーザとして対応付けられた場合
には、当該ユーザのバトルへの対応付けが解除され、バトルに対応付けられたユーザの数
が低減することになる。そのため、より多くのユーザの間で入れ替わり対応付けが行われ
てバトルの処理を実行することが動機付けられ、ユーザ間でコミュニケーションをとるこ
とが促進される。
本変形例を実現するために、ゲームサーバ20のCPU21は、バトル管理データにお
いて同一のユーザIDのユーザが連続して支援ユーザとして対応付けられた場合、そのユ
ーザIDのデータをバトル管理データから削除する(つまり、対応付けを解除する)。
上述した実施形態において、対応付け手段53は、N番目(N:2以上の整数)のユー
ザが特定のバトル(イベント)に対応付けられ、かつ当該ユーザがN−1番目までにバト
ルに対応付けられたユーザのうちいずれかのユーザと同一である場合に、当該ユーザのバ
トルへの対応付けを解除してもよい。
この構成では、既にバトルに参加済み(つまり、支援済み)のユーザが再度バトルに参
加して処理を実行した場合には、当該ユーザのバトルへの対応付けが解除され、バトルに
対応付けられたユーザの数が低減することになる。つまり、固定化した仲間のユーザ同士
で入れ替わりバトルに参加しても多くの特典を得ることができなくなるため、固定化した
仲間のユーザ同士でバトルの処理を実行することが回避される。結果として、複数のユー
ザが協力してバトルの処理を行う場合に、コミュニケーションの程度が低いユーザ同士、
あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行
うように動機付けることができる。
本変形例を実現するために、ゲームサーバ20のCPU21は、ユーザを新たに支援ユ
ーザとしてバトルに対応付けるときに、そのユーザのユーザIDと、それまでに支援ユー
ザとして既に対応付けられているユーザIDと順に比較する。その結果、一致するユーザ
IDが存在する場合には、CPU21は、新たに支援ユーザとして対応付けることを許可
せず、かつ既に対応付けられている同一のユーザIDの対応付けを解除する。
上述した変形例2又は変形例3において、対応付け手段53は、N番目(N:2以上の
整数)のユーザが特定のバトル(イベント)に対応付けられ、かつ当該ユーザがN−1番
目までにバトルに対応付けられたユーザのうちいずれかのユーザと同一である場合に、前
記所定時間を短くしてもよい。
この構成では、既にバトルに参加済み(つまり、支援済み)のユーザが再度バトルに参
加して処理を実行した場合、バトルに参加しているユーザの数に応じて特典を得られると
いう有利な効果が持続する時間が短くなる。そのため、固定化した仲間のユーザ同士で入
れ替わりバトルに参加しても多くの特典を得る機会が少なくなるため、固定化した仲間の
ユーザ同士でバトルの処理を実行することが回避される。結果として、複数のユーザが協
力してバトルの処理を行う場合に、コミュニケーションの程度が低いユーザ同士、あるい
は今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うよう
に動機付けることができる。
本変形例を実現するために、ゲームサーバ20のCPU21は、ユーザを新たに支援ユ
ーザとしてバトルに対応付けるときに、そのユーザのユーザIDと、それまでに支援ユー
ザとして既に対応付けられているユーザIDと順に比較する。その結果、一致するユーザ
IDが存在する場合には、CPU21は、変形例2又は変形例3における所定時間を短く
して、追撃終了時刻を設定する。このとき、所定時間を短くする度合いは適宜予め決定し
ておくようにする。
ない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更
をしてもよいのは勿論である。例えば、上記実施形態及び各変形例に記載された技術的事
項は適宜組合せて適用してもよい。
例えば、ウェブページを用いたユーザへの通知方法は、テキスト形式の視覚的情報に限
られず、音声などの聴覚的情報であってもよい。
たが、これに限られない。カードでなく、例えば、ユーザのアバタ画像等の他のオブジェ
クトであってもよい。あるいは、カード等のオブジェクトを使用せずにバトル処理を行っ
てもよい。
信端末に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末に
対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操
作入力は、加速度センサを備えた通信端末を振ることによる操作入力、あるいはジェスチ
ャによる操作入力(ジェスチャ入力)であってもよい。ジェスチャ入力では、撮像機能を
備えた通信端末に対する所定のジェスチャを行うことで通信端末がそのジェスチャを画像
認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラ
ムを実行可能な通信端末の場合には、操作入力は、音声を入力することにより行われても
よい。
れに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲー
ム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と
同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。
0によって、図15に示した各機能を実現する構成としたが、この構成に限られない。こ
れらのすべての手段を通信端末10によって実現する構成としてもよいし、少なくとも一
部の手段を通信端末10によって実現する構成としてもよい。通信端末10とゲームサー
バ20とでは実質的に同一のハードウエア構成を採るため、上記実施形態に記載したよう
にして通信端末10によっても各機能を実現できる。図19(a),(b)には、本実施
形態のゲーム制御装置の各機能(図15に示す各機能)について、通信端末10と、ゲー
ムサーバ20及びデータベースサーバ30との間の分担例を示す。
11…CPU
12…ROM
13…RAM
14…画像処理部
15…指示入力部
16…表示部
17…通信インタフェース部
18…バス
20…ゲームサーバ
21…CPU
22…ROM
23…RAM
24…データベースアクセス部
25…通信インタフェース部
26…バス
30…データベースサーバ
31…ユーザデータベース
32…ゲームデータベース
51…登録手段
52…ゲーム実行手段
53…対応付け手段
54…取得手段
55…特典付与手段
56…通信手段
57…提示手段
Claims (3)
- 複数のユーザが協力して共通の対戦相手に対するバトルを行うように構成されたゲームを進行させるサーバであって、
複数のユーザの各々の通信端末から指示を受信する通信手段と、
複数のユーザのうち前記対戦相手と最初にバトルを行う第1ユーザと、第1ユーザによる前記対戦相手とのバトルが終了した後に前記対戦相手とバトルを行う1又は複数の第2ユーザのいずれかの第2ユーザの通信端末から攻撃処理の実行指示を受信したときに前記攻撃処理を実行すると共に、第1ユーザと1又は複数の第2ユーザのいずれかの第2ユーザとが異なるときに、第1ユーザによる前記対戦相手とのバトルの開始から終了までの期間である第1期間内においては、攻撃処理の実行指示を受信する度に所定の値のポイントを加算し、1又は複数の第2ユーザのいずれかの第2ユーザによる前記対戦相手とのバトルの開始から終了までの期間である第2期間内においては、攻撃処理の実行指示を受信する度に前記所定の値よりも大きい値のポイントを加算するゲーム実行手段と、
前記ポイントの累積値がしきい値を超えた場合に、複数のユーザのうち第1ユーザと1又は複数の第2ユーザの各々に特典を付与する特典付与手段と、
を備えることを特徴とするサーバ。 - 前記特典は、前記ゲーム上のアイテムに交換可能である、請求項1に記載のサーバ。
- 複数のユーザが協力して共通の対戦相手に対するバトルを行うように構成されたゲームを進行させるサーバの制御プログラムであって、前記サーバに、
複数のユーザの各々の通信端末から指示を受信し、
複数のユーザのうち前記対戦相手と最初にバトルを行う第1ユーザと、第1ユーザによる前記対戦相手とのバトルが終了した後に前記対戦相手とバトルを行う1又は複数の第2ユーザのいずれかの第2ユーザの通信端末から攻撃処理の実行指示を受信したときに前記攻撃処理を実行すると共に、第1ユーザと1又は複数の第2ユーザのいずれかの第2ユーザとが異なるときに、第1ユーザによる前記対戦相手とのバトルの開始から終了までの期間である第1期間内においては、攻撃処理の実行指示を受信する度に所定の値のポイントを加算し、1又は複数の第2ユーザのいずれかの第2ユーザによる前記対戦相手とのバトルの開始から終了までの期間である第2期間内においては、攻撃処理の実行指示を受信する度に前記所定の値よりも大きい値のポイントを加算し、
前記ポイントの累積値がしきい値を超えた場合に、複数のユーザのうち第1ユーザと1又は複数の第2ユーザの各々に特典を付与することを実行させることを特徴とする制御プログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015193862A JP6678867B2 (ja) | 2015-09-30 | 2015-09-30 | サーバ、制御プログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015193862A JP6678867B2 (ja) | 2015-09-30 | 2015-09-30 | サーバ、制御プログラム |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012170529A Division JP5847037B2 (ja) | 2012-07-31 | 2012-07-31 | ゲーム制御装置、ゲーム制御方法、ゲームシステム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2016034511A JP2016034511A (ja) | 2016-03-17 |
JP6678867B2 true JP6678867B2 (ja) | 2020-04-08 |
Family
ID=55522770
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015193862A Active JP6678867B2 (ja) | 2015-09-30 | 2015-09-30 | サーバ、制御プログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6678867B2 (ja) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2018156190A (ja) * | 2017-03-15 | 2018-10-04 | 株式会社コナミデジタルエンタテインメント | ゲームシステム及びプログラム |
JP2020103985A (ja) * | 2020-04-07 | 2020-07-09 | グリー株式会社 | ゲームプログラム、ゲームシステム、端末装置、及びゲームプログラムの実行方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011206442A (ja) * | 2010-03-30 | 2011-10-20 | Namco Bandai Games Inc | ゲームシステム、プログラム及び情報記憶媒体 |
-
2015
- 2015-09-30 JP JP2015193862A patent/JP6678867B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2016034511A (ja) | 2016-03-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5882188B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP5436612B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP5265789B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲーム制御システム | |
KR101570688B1 (ko) | 게임 제어 장치, 게임 제어 방법, 기록 매체, 게임 시스템 | |
JP5832982B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP6195093B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
WO2013157396A1 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム | |
JP5838149B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP5535272B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
WO2013154020A1 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲーム制御システム | |
JP5395210B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、コミュニケーション装置 | |
JP6678867B2 (ja) | サーバ、制御プログラム | |
JP5847302B2 (ja) | コミュニケーション装置、プログラム、コミュニケーションシステム | |
JP5562400B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP5847037B2 (ja) | ゲーム制御装置、ゲーム制御方法、ゲームシステム | |
JP5526295B1 (ja) | ゲームプログラム、及び、情報処理装置 | |
WO2013124932A1 (ja) | ゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステム | |
JP6206764B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP6206772B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP5845208B2 (ja) | ゲーム制御装置、プログラム、ゲーム制御システム | |
JP2014147832A (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP2014208168A (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20151009 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20151009 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20161220 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20170613 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20180130 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190206 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190801 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20200124 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6678867 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |