JP2013226223A - ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム - Google Patents

ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム Download PDF

Info

Publication number
JP2013226223A
JP2013226223A JP2012099549A JP2012099549A JP2013226223A JP 2013226223 A JP2013226223 A JP 2013226223A JP 2012099549 A JP2012099549 A JP 2012099549A JP 2012099549 A JP2012099549 A JP 2012099549A JP 2013226223 A JP2013226223 A JP 2013226223A
Authority
JP
Japan
Prior art keywords
user
battle
game
support
request
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.)
Granted
Application number
JP2012099549A
Other languages
English (en)
Other versions
JP5436612B2 (ja
Inventor
Kota Wakasa
晃太 若狭
Original Assignee
Konami Digital Entertainment Co Ltd
株式会社コナミデジタルエンタテインメント
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Konami Digital Entertainment Co Ltd, 株式会社コナミデジタルエンタテインメント filed Critical Konami Digital Entertainment Co Ltd
Priority to JP2012099549A priority Critical patent/JP5436612B2/ja
Publication of JP2013226223A publication Critical patent/JP2013226223A/ja
Application granted granted Critical
Publication of JP5436612B2 publication Critical patent/JP5436612B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45Controlling the progress of the video game
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35Details of game servers
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45Controlling the progress of the video game
    • A63F13/48Starting a game, e.g. activating a game device or waiting for other players to join a multiplayer session
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/55Controlling game characters or game objects based on the game progress
    • A63F13/58Controlling game characters or game objects based on the game progress by computing conditions of game characters, e.g. stamina, strength, motivation or energy level
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70Game security or game management aspects
    • A63F13/79Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/795Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for finding other players; for building a team; for providing a buddy list
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/80Special adaptations for executing a specific game genre or game mode
    • A63F13/847Cooperative playing, e.g. requiring coordinated actions from several players to achieve a common goal
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45Controlling the progress of the video game
    • A63F13/46Computing the game score
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/90Constructional details or arrangements of video game devices not provided for in groups A63F13/20 or A63F13/25, e.g. housing, wiring, connections or cabinets
    • A63F13/92Video game devices specially adapted to be hand-held while playing
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/406Transmission via wireless network, e.g. pager or GSM
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55Details of game data or player data management
    • A63F2300/5546Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • A63F2300/5566Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history by matching opponents or finding partners to build a team, e.g. by skill level, geographical area, background, play style

Abstract

【課題】ユーザのゲームの進行度が低い場合にゲームの進行を補助することができるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供すること。
【解決手段】本発明のゲーム制御装置は、ユーザによるゲーム上の対戦を実行する対戦実行手段と、第1のユーザから第1の対戦における支援要請を受け付ける受付手段と、第1のユーザ以外のユーザに対して、第1のユーザとのゲームの進行度の差に応じて、前記第1の対戦における支援要請を行うか否かを判定する判定手段と、前記判定手段の判定結果に応じて、第1のユーザ以外のユーザのうち支援要請先の第2のユーザを特定し、第2のユーザに対して前記支援要請を行う要請手段と、を備える。
【選択図】図15

Description

本発明は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御する技術に関する。
近年、特定のサービス提供者によるソーシャルネットワーキングサービス(SNS)においてウェブブラウザ上で動作するAPI(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム(Social Game)が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であって、かつウェブブラウザが搭載された通信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。
上述したソーシャルゲームでは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の1つとなっている。ソーシャルゲームでは、例えば、関係付けられたユーザ(仲間)間で協力したゲームの実行のほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。このようなソーシャルゲームの一例として、下記の非特許文献1に記載されたデジタルカードゲーム(ドラゴンコレクション(登録商標))が知られている。
アプリSTYLE Vol.5(株式会社イースト・プレス)、7-8頁
従来のソーシャルゲームにおいて、各ユーザが例えばゲーム上のキャラクタとバトル(対戦)を行いながらゲームを進行させていくときに、ユーザ毎のゲーム上の能力の差などから、ゲームの進行度合いに差が生ずる。このとき、例えばゲームのゲーム上の能力が低いユーザにとっては、バトルに勝利してゲームを早く先に進めることができず(つまり、ゲームの進行度が低く)、ゲームのシナリオに応じたゲームの面白味を感じられない場合があった。
本発明は上述した観点に鑑みてなされたもので、ユーザのゲームの進行度が低い場合にゲームの進行を補助することができるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。
本発明の第1の観点は、
ユーザによるゲーム上の対戦を実行する対戦実行手段と、
第1のユーザから第1の対戦における支援要請を受け付ける受付手段と、
第1のユーザ以外のユーザに対して、第1のユーザとのゲームの進行度の差に応じて、前記第1の対戦における支援要請を行うか否かを判定する判定手段と、
前記判定手段の判定結果に応じて、第1のユーザ以外のユーザのうち支援要請先の第2のユーザを特定し、第2のユーザに対して前記支援要請を行う要請手段と、
を備える。
このゲーム制御装置では、ゲームを実行中の第1のユーザよりも、例えばゲームの進行度が高い第2のユーザに支援要請が行われる。ゲームの進行度が高い第2のユーザはゲーム上の能力(例えば、バトルの能力等)が高いと考えられるため、第2のユーザに対して支援要請が行われることで、第1のユーザに対する支援は実効性が高いものとなる。その結果、ゲームの進行度が低いユーザであっても、ゲームのシナリオに応じたゲームの面白味を感じられるようになる。また、ゲームの進行度が高いユーザが、ゲームの進行度が低いユーザのゲームの進行を補助する構成となるため、ユーザ全体でゲームの活性化が図れるようになる。
なお、「ゲームの進行度」は、ゲームの性質によって任意に設定可能であり、例えば、ゲーム内でクリアしたステージの数や、ゲーム内で取得したアイテムの数、あるいはゲーム内で与えられた特定のミッションを達成した回数等、ミッションを所定回数達成する毎に上昇するレベル等のパラメータ、ゲーム画面上の特定のメニューの選択回数に応じて決定してもよい。
上記ゲーム制御装置において、前記判定手段は、第1のユーザ以外のユーザのうち、第1のユーザとのゲームの進行度の差が所定値以上であるユーザに対して支援要請を行うと判定してもよい。これにより、支援要請を行う第2のユーザの数を適切に制限することができる。また、第1のユーザと比べて第2のユーザの進行度を十分に高く設定できるため、第1のユーザよりもゲーム上の能力が十分に高いユーザによる支援を受けることが期待でき、支援の実効性をより高めることができる。
上記ゲーム制御装置において、前記要請手段によって行われた前記支援要請に応じた、前記第2のユーザによる所定の操作入力の情報に基づいて、前記第1の対戦における前記第1のユーザの対戦能力、又は前記第1の対戦の対戦相手の対戦能力を、前記第1のユーザが有利となるように調整する第1の支援を実行する支援手段、を備えてもよい。
「所定の操作入力」は、ユーザの通信端末に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末に対する表示画面上のタッチ操作の入力のほか、加速度センサを備えた通信端末を振ることによる操作入力、あるいはジェスチャによる操作入力(ジェスチャ入力)であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末に対する所定のジェスチャを行うことで通信端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。
第2のユーザによって行われる第1の支援は、第1の対戦の対戦相手と直接的に対戦することではなく、第1の対戦における前記第1のユーザの対戦能力、又は第1の対戦の対戦相手の対戦能力を、前記第1のユーザが有利となるように調整することである。言わば、第1の支援は、第1のユーザによる第1の対戦を間接的に支援するものである。つまり、第1のユーザが例えば自らの操作によって第1の対戦に勝利するように補助されるため、第1のユーザにとっては自ら対戦に勝利したという達成感を得ることができる。
第1の支援を実行する場合、前記支援手段は、前記第1のユーザと前記第2のユーザのゲームの進行度の差が大きいほど、第1のユーザがより有利になるように調整してもよい。これにより、第2のユーザのゲームの進行度が第1のユーザよりも高いほど、第2のユーザによる支援によって第1のユーザのゲームの進行がしやすくなる。その結果、支援を行う第2のユーザ次第で、第1のユーザのゲームの進行率が調整されることになり、ゲーム性の幅を広げることができる。
上記ゲーム制御装置において、前記支援要請は、前記第2のユーザによる前記第1の対戦の対戦相手との対戦を実行してもよい。このように、第2のユーザによって行われる支援は、第1の対戦の対戦相手と直接的に対戦することであってもよい。このような支援方法であっても、第1のユーザのゲームの進行を第2のユーザが補助することができる。
上記ゲーム制御装置において、前記要請手段は、判定手段の判定結果に応じて、前記第1の対戦において前記第1のユーザが有利になるように調整する第1の支援、又は、前記第2のユーザによる前記第1の対戦の対戦相手との対戦を実行する第2の支援のいずれかを、前記第2のユーザが選択可能に提示してもよい。ここで、第1の支援は、第2のユーザが第1の対戦の対戦相手と直接的に対戦する、言わば直接的な支援である。第2の支援は、前述したように、第1のユーザによる第1の対戦に対する、言わば間接的な支援である。第2のユーザは、第1のユーザに対する支援方法として、第1の支援又は第2の支援のいずれかを選択できる。そのため、第2のユーザが自らのゲームの進行状況に応じた柔軟な選択を可能とするゲーム設定とすることができる。
上記ゲーム制御装置において、前記対戦実行手段は、ユーザによる前記ゲーム上の対戦の実行に伴って当該ユーザのゲーム上のパラメータを消費してもよい。この場合、第2のユーザが、第1の支援又は第2の支援のいずれかの支援方法を選択するに当たって、第2の支援(第1の対戦の対戦相手との対戦を実行すること)による自らのパラメータの消費量を考慮しながら選択を行うことになるため、深いゲーム性を実現できる。例えば、対戦で勝利することで、あるいは対戦で勝利した数に応じて特典を得られる設定とした場合には、第2のユーザが、パラメータの消費量と、得られる特典とを比較考量する構成とすることができる。
上記ゲーム制御装置において、ユーザ間を関係付ける関係付け手段、を備え、前記要請手段は、前記第2のユーザを、前記第1のユーザと関係付けられたユーザの中から選択してもよい。
支援要請を行う第2のユーザを支援要請元の第1のユーザと関係付けられたユーザ(仲間)の中から選択することで、第1のユーザにとっては、仲間によって支援を受けているという実感が得られるため、仲間との関係性を高めることができる。そのため、ゲームのソーシャル性を高めることができる。
本発明の第2の観点は、
ユーザによるゲーム上の対戦を実行するステップと、
第1のユーザから第1の対戦における支援要請を受け付けるステップと、
第1のユーザ以外のユーザに対して、第1のユーザとのゲームの進行度の差に応じて、前記第1の対戦における支援要請を行うか否かを判定するステップと、
前記判定するステップの判定結果に応じて、第1のユーザ以外のユーザのうち支援要請先の第2のユーザを特定し、第2のユーザに対して前記支援要請を行うステップと、
を備えた、ゲーム制御方法である。
本発明の第3の観点は、コンピュータに、
ユーザによるゲーム上の対戦を実行する機能、
第1のユーザから第1の対戦における支援要請を受け付ける機能、
第1のユーザ以外のユーザに対して、第1のユーザとのゲームの進行度の差に応じて、前記第1の対戦における支援要請を行うか否かを判定する機能、及び、
前記判定する機能の判定結果に応じて、第1のユーザ以外のユーザのうち支援要請先の第2のユーザを特定し、第2のユーザに対して前記支援要請を行う機能、
を実現させるためのプログラムである。
コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、DVD−ROMやCD−ROM等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。
本発明の第4の観点は、通信端末と、当該通信端末からアクセス可能に構成され、前記通信端末によるゲームの実行を制御するサーバと、を含むゲームシステムであって、
ユーザによるゲーム上の対戦を実行する対戦実行手段、
第1のユーザから第1の対戦における支援要請を受け付ける受付手段、
第1のユーザ以外のユーザに対して、第1のユーザとのゲームの進行度の差に応じて、前記第1の対戦における支援要請を行うか否かを判定する判定手段、及び、
前記判定手段の判定結果に応じて、第1のユーザ以外のユーザのうち支援要請先の第2のユーザを特定し、第2のユーザに対して前記支援要請を行う要請手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
を備えた、ゲームシステムである。
本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、ユーザのゲームの進行度が低い場合にゲームの進行を補助することができる。
実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるユーザデータベースの構成例を示す図。 モンスターキャラクタデータの内容を例示する図。 バトル管理データのデータ構成例を例示する図。 支援要請リストのデータ構成例を例示する図。 ゲームのトップページの表示例を示す図。 ゲーム内のバトルのトップページの表示例を示す図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態の通信端末とゲームサーバの間の主要な処理(他のユーザが参戦する場合)を示すシーケンスチャート。 実施形態の通信端末とゲームサーバの間の主要な処理(他のユーザが応援する場合)を示すシーケンスチャート。 変形例に係るゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 変形例に係るゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。
以下、本発明の実施形態について説明する。
(1)ゲームシステムの構成
図1は、実施形態のゲームシステムのシステム構成例を示している。図1に示すように、このゲームシステムは、例えばインターネットなどの通信網NW(ネットワーク)に接続可能な通信端末10a,10b,10c,…と、通信網NWに接続されているゲームサーバ20と、データベースサーバ30とによって構成されている。各通信端末10a,10b,10c,…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、PDA(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機(いわゆる多機能型のスマートテレビも含む。)などの通信端末である。なお、以下の説明において、各通信端末10a,10b,10c,…に共通して言及するときには、通信端末10と表記する。
このゲームシステムにおいて、ゲームサーバ20は、クライアントである通信端末10と通信可能に構成されており、通信端末10に対してゲーミングサービスを提供する。ゲームサーバ20には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ30は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ20と例えば有線で接続される。
通信端末10は、ゲームサーバ20によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末10でウェブページに対する操作をしてゲームを実行する。
また、図1には図示していないが、ゲームサーバ20とは別に各通信端末10のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末10からのアクセスを受け入れるために複数のゲームサーバ20を設ける場合は、その複数のゲームサーバ20間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ20は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。
(2)通信端末の構成
図2及び図3を参照して通信端末10について説明する。
図2は、通信端末10の外観の例を示す図であって、(a)は、例えば折り畳み式の携帯端末(携帯電話機)などの釦入力方式の通信端末を例示したものであり、(b)は、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図3は、通信端末10の内部構成を示すブロック図である。
図3に示すように、通信端末10は、CPU(Central Processing Unit)11、ROM(Read Only Memory)12、RAM(Random Access Memory)13、画像処理部14、指示入力部15、表示部16、及び、信号送受信部としての通信インタフェース部17を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス18が設けられている。
CPU11は、ROM12内のウェブブラウザをRAM13にロードして実行する。そして、CPU11は、指示入力部15等によってユーザに入力されるURL(Uniform Resource Locator)の適切な指定に基づき、通信インタフェース部17を介して、ゲームサーバ20からウェブページを表示するためのデータ、すなわち、HTML(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ(以下、総称して適宜「HTMLデータ」と表記する。)を通信インタフェース部17を介して取得し、そのHTMLデータを解釈する。なお、通信端末10には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。
なお、HTMLデータの取得に当たって、CPU11は、予め登録されたユーザID(ユーザ識別情報)、あるいは指示入力部15を介して入力されるユーザIDを含むアクセス要求メッセージを、通信インタフェース部17を介してゲームサーバ20へ通知する。
ウェブブラウザは、画像処理部14を介して、取得したHTMLデータに基づき、ゲームサーバ20から提供されるウェブページを表示部16に表示する。また、ウェブブラウザは、ユーザが指示入力部15の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新たなHTMLデータの送信(つまり、ウェブページの更新)をゲームサーバ20へ要求する。
画像処理部14は、HTMLデータの解析結果としてCPU11から与えられる表示用画像データに基づいて、表示部16にウェブページを表示する。表示部16は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むLCD(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面16aに表示する。
通信端末10が釦入力方式の通信端末(図2(a))である場合、指示入力部15は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群15a、及び、テンキーなどの複数の指示入力釦を含む釦群15bを備え、各釦の押下(操作)入力を認識してCPU11へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部16に表示されているウェブページをスクロールして表示することをCPU11へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示(例えば強調表示)されている1つのハイパーリンクまたはメニューをユーザが選択することをCPU11へ指示するために設けられる。なお、通信端末10を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末10を片手で保持したままその親指で操作(クリック)しやすいように、通信端末10の前面に配置されていることが好ましい。図2(a)に示す例では、釦群15bは、釦群15aの下方に配置され、「0」〜「9」、「*」、「#」(テンキー)が表記された複数の指示入力釦を含む。
通信端末10がタッチパネル入力方式の通信端末(図2(b))である場合、指示入力部15は、主として表示画面16aに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図2(b)に示すように、通信端末10がタッチパネル入力方式の場合であっても釦群15aが設けられる場合もある。
通信端末10に表示されるウェブページ上のメニューの選択操作は、例えば通信端末10が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末10がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面16a上のメニューの位置を指あるいはペンで指示(タッチ操作)することによって行われる。
(3)ゲームサーバの構成
図4を参照してゲームサーバ20の構成について説明する。
ゲームサーバ20は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末10に対してゲームのウェブサービスを提供する。図3に示すように、ゲームサーバ20は、CPU21、ROM22、RAM23、データベース(DB)アクセス部24、及び、通信インタフェース部25を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス26が設けられている。なお、ゲームサーバ20は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。
ROM22には、クライアントである通信端末10のウェブブラウザに対してHTML文書や画像などのオブジェクトの表示(ウェブページの表示)のサービスを提供するアプリケーションプログラムが格納されている。ROM22には、アプリケーションプログラム以外にもCPU21によって参照される各種データが格納されている。
CPU21は、ROM22内のゲームプログラムをRAM23にロードして実行し、通信インタフェース部25を介して、各種の処理を行う。
例えば、CPU21は、通信インタフェース部25を介して、HTMLデータを通信端末10宛に送信する。なお、ゲームサーバ20が通信端末10のユーザの認証処理を行う場合には、CPU21はその認証処理を行う。
CPU21は、通信インタフェース部を介して、通信端末10で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなHTMLデータの送信、または、ゲームサーバ20内の演算処理あるいはデータ処理などを含む。
データベースアクセス部24は、CPU21がデータベースサーバ30に対してデータの読み書きを行うときのインタフェースである。
(4)データベースサーバの構成
データベースサーバ30(記憶装置)は、大容量のハードディスク装置やRAID(Redundant Arrays of Inexpensive Disks)等の形態の装置等、汎用ストレージで実現できる。データベースサーバ30内の各データベースは、ゲームサーバ20のデータベースアクセス部24を介してCPU21からのデータの読み書きが可能となるように構成されている。
図5に、データベースサーバ30の構成の一例を示す。図5に示すように、データベースサーバ30は、ユーザデータベース31と、ゲームデータベース32とを備える。
本実施形態のゲームシステムによって実現されるゲームのタイプは特に限定されるものではないが、以下では、本実施形態のゲームの一例として、ユーザの通信端末10に対する操作に応じて、ユーザがゲーム上で仮想的に保有する戦士カードを使い、ゲーム上のモンスターであるモンスターキャラクタとバトルを行う対戦型デジタルカードゲーム(以下、適宜「本実施形態のゲーム」という。)を採り上げる。後述するように、本実施形態のゲームでは、ユーザがモンスターキャラクタとのバトルで敗北すると支援要請を行うことができ、支援要請を受諾した他のユーザは、支援要請元のユーザのバトルを支援することができるように構成されている。
図6に、本実施形態のゲームにおいて適用されるユーザデータベース31の一例を示す。この例では、ユーザデータベース31は、ユーザID(ユーザ識別情報)ごとに、ユーザ名、技能レベル、攻撃ポイント、友情ポイント、モンスター撃破数、仲間のユーザID、保有カードのデータの各項目についての情報を含む。ユーザデータベース31に含まれる情報は、ゲームサーバ20によって逐次更新されうる。
以下の説明では、ユーザデータベース31に含まれるユーザID、あるいはユーザを特定するユーザ名(後述する)ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名
ゲームの実行時に通信端末10にユーザを特定するために表示されるユーザ名である。ユーザ名はユーザによって予め指定される所定長以下のテキストである。ユーザ名は、ゲームサーバ20によって提供されるネットワーク環境(あるいはゲームコミュニティ)上でユーザを特定する名称である。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばLv1(レベル1)からLv100(レベル100)までの範囲のレベル値である。
・攻撃ポイント
本実施形態のゲームにおいて、戦士カードを使用したモンスターキャラクタとのバトルを行う上で必要となるポイントである。攻撃ポイントが所定値よりも少なくなるとバトルを実行することができない。攻撃ポイントは、モンスターキャラクタと1回のバトルを行うことで低減し、所定の時間が経過する毎に回復(増加)する値である。
・友情ポイント
本実施形態のゲームにおいて、仲間へ応援メッセージを送信することでユーザが取得するポイントである。また、他のユーザから支援要請に対して、他のユーザを応援することによって支援したときにも友情ポイントが得られる。
・モンスター撃破数
本実施形態のゲームにおいて、ユーザがバトルによって撃破したモンスターキャラクタの数である。モンスターキャラクタの撃破数は、ゲームの進行度の一例である。
・仲間のユーザID
対象となるユーザIDと関係付けられた他のユーザIDのデータである。なお、仲間のユーザIDは、後述する変形例2に関連する。
・保有カードのデータ
保有カードのデータは、ユーザが保有している戦士カードのデータであり、例えば、図6に示すように、戦士カード毎の画像、攻撃力などのパラメータを含む。戦士カードがモンスターキャラクタとバトルを行うときに、モンスターキャラクタに対して攻撃力の値に応じたダメージを与えることができる。
図5に戻り、ゲームデータベース32は、ゲームサーバ20からのアクセスに基づき、ゲームサーバ20によって実行されたゲームの進行に関する情報、モンスターキャラクタのデータ(モンスターキャラクタデータ)、バトル管理データ、支援要請リストを記憶する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、各ユーザのモンスターキャラクタとのバトルの詳細結果などを含んでもよい。
モンスターキャラクタデータの一例を図7に示す。モンスターキャラクタデータは、バトルの相手となるモンスターキャラクタのデータを含む。モンスターキャラクタデータは、バトル処理の実行とともにゲームデータベース32から例えばRAM23にロードされ、記憶されるデータである。図7では、バトルに出現するモンスターキャラクタMC1,MC2,MC3,…の各々について、ウェブページに表示される画像と、モンスターキャラクタの体力を示すHP(Hit Point)の値とが対応付けられている。例えば、図7に示す例では、各モンスターキャラクタのHPは1500〜2000の範囲内であるが、この範囲の中からバトルを行うときにランダムにHPの値が設定されてもよい。
バトル管理データは、ユーザごとにバトルの状態を管理するためのデータである。図8にバトル管理データのデータ構成例を示す。図8に示すバトル管理データでは、ユーザ(ユーザ名又はユーザID)ごとに、出現中のモンスターキャラクタ(出現中のモンスター)とそのHP、及びバトルの終了時刻が書き込まれている。なお、バトルの終了時刻は必ずしも必須のデータではないが、モンスターキャラクタを倒すまでの時間が限定されている場合には、バトルの終了時刻が書き込まれる。なお、ユーザごとにバトル相手としてモンスターキャラクタが出現した場合、そのモンスターキャラクタを倒す(つまり、そのモンスターキャラクタとのバトルに勝利する)までは、出現中のモンスターとしてバトル管理データに書き込まれたままとなる。また、バトル管理データ中のHPは、対応するモンスターキャラクタの最新の値を示している。例えば、1又は複数回のバトルにおいてHPが低減した場合に、低減後のHPがバトル管理データに書き込まれる。
バトル管理データ内のデータは、ユーザがバトルを行うときに読み出され、バトルが終了したときに上書き(更新)される。
前述したように、本実施形態のゲームでは、例えばユーザがモンスターキャラクタとのバトルにおいて敗北した場合に、他のユーザに対してそのバトルに対する支援要請を行うことができる。なお、バトルの支援要請を行う条件は、ユーザがモンスターキャラクタとのバトルにおいて敗北したという条件に限られない。バトル開始時に無条件で支援要請できることとしてもよいし、バトルにおける所定の条件が満たされた場合にのみ支援要請ができることとしてもよい。「バトルにおける所定の条件」とは、例えば、ユーザがバトルで使用する戦士カード、及びバトル相手のモンスターキャラクタの攻撃力などのパラメータ(又は能力レベル)についての所定の条件でよく、より具体的には、例えば、戦士カードとモンスターキャラクタの攻撃力の差が一定値あることという条件としてもよい。
支援要請リストは、ユーザから行われた支援要請が順に書き込まれたリストである。支援要請リスト内の支援要請のうち支援が実行されたものについては、リストから削除される。図9に、支援要請リストのデータ構成例を示す図である。図9に例示する支援要請リストでは、ユーザ(ユーザ名又はユーザID)ごとに、支援要請が行われたときのバトルのバトル相手(モンスターキャラクタ)と、バトルの終了時刻とが書き込まれる。なお、バトルの終了時刻は必ずしも必須のデータではないが、モンスターキャラクタを倒すまでの時間が限定されている場合には、バトルの終了時刻が書き込まれる。この場合には、バトルの終了時刻までにモンスターキャラクタのHPをゼロにしなければ(つまり、モンスターキャラクタを撃破できなければ)、そのモンスターキャラクタは倒せなかったと判断される。
(5)本実施形態のゲーム
以下、本実施形態のゲームのモンスターキャラクタとのバトル処理について、図10〜14を参照しながら説明する。図10は、本実施形態のゲームにおいて通信端末10上に表示されるトップページの一例を示す図である。図11〜14は、バトル処理が実行されるときの通信端末10上に表示されるウェブページの例を示す図である。
図10に例示する本実施形態のゲームのトップページは、個々のユーザIDに応じたウェブページで構成される。図10の例では、ユーザデータ表示領域、戦士画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザIDのユーザデータに含まれる、技能レベル、友情ポイント、攻撃ポイント、モンスター撃破数の各項目のデータ(図6参照)が表示される領域である。
戦士画像表示領域は、対象となるユーザIDのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
メニュー表示領域は、本実施形態のゲームにおいてバトル処理の実行を開始するためのメニューm1を含む複数のメニュー(メニューm1以外は図示せず)が表示される領域である。
図10のゲームのトップページ上でメニューm1が選択操作されると、図11のP0に示すようにウェブページが更新される。ウェブページP0は、バトルのトップページである。ウェブページP0では、バトル可能なモンスターキャラクタとして、出現中のモンスターキャラクタの一覧を表示するモンスター表示領域101と、バトルに関するユーザ宛のテキストメッセージが表示されるメッセージ表示領域102とが含まれる。モンスター表示領域101には、モンスターキャラクタ毎に「バトルする」と表記されたメニューm11,m12が含まれる。各メニューは、対応するモンスターキャラクタ毎に設けられている。メッセージ表示領域102に含まれるテキストメッセージには、例えば、ユーザ(この場合、ユーザKNM)の仲間のバトルの進行度合いを示す情報や、他のユーザにバトルの支援要請を行った場合には他のユーザによる支援結果の情報等が含まれる。
図11のウェブページP0において例えばメニューm11が選択操作されると、図12のP1に示すようにウェブページが更新される。ユーザが手持ちの戦士カードを使用してモンスターキャラクタを倒すためのプレイを実行するためのバトル画面に切り替わる。ウェブページP1は、メニューm11に対応するモンスターキャラクタMC1とのバトルのためのウェブページである。なお、1回のバトルを行う度にユーザの攻撃ポイントが一定値、あるいは使用する戦士カードに応じた値だけ消費される。
ウェブページP1は、ユーザがバトルで使用する戦士カードの画像と、バトル相手のモンスターキャラクタMC1の画像と、モンスターキャラクタMC1のHP(Hit Point)を示すHPゲージと、「攻撃する」と表記されたメニューm20とを含む。HPは、モンスターキャラクタの体力を示す値である。ユーザが使用する戦士カードが倒される前にモンスターキャラクタのHPをゼロにできれば、ユーザがバトルに勝利したことを意味し、ユーザが使用する戦士カードが倒された時点でモンスターキャラクタのHPがゼロになっていなければ、ユーザがバトルに敗北したことを意味する。
ウェブページP1においてメニューm20が選択操作されると、P2に示すようにウェブページが更新される。ウェブページP2では、ウェブページP1と比べて、ユーザがバトルに使用する戦士カードによってモンスターキャラクタMC1に対する攻撃が行われ、その結果、モンスターキャラクタのHPが低下した場合が示されている。なお、メニューm20が選択操作される度にバトル相手のモンスターキャラクタから戦士カードに対して攻撃が加えられる。
ウェブページP3に示すように、モンスターキャラクタMC1のHPがゼロに達すると、ユーザがバトルに勝利し、モンスターキャラクタMC1が撃破されたことになる。他方、ウェブページP4に示すように、モンスターキャラクタMC1のHPがゼロに達する前に戦士カードが倒されると、ユーザがバトルに敗北したことになる。バトルに敗北した場合、モンスターキャラクタMC1は消失せずに、バトル後に残存するHPが維持された状態でバトルについてのユーザのトップページP0に表示される。
なお、ウェブページP4に示したように、バトルで敗北した場合には、再度モンスターキャラクタMC1とバトルを単独で行うための、「1人で挑む」と表記されたメニューm21と、他のユーザに支援要請を行うためのメニューm22とが表示される。
図13及び図14は、いずれもユーザKNMが支援要請を行ったとき(つまり、メニューm22を選択操作したとき)の、ユーザKNM向けのウェブページの遷移と、その支援要請を受諾したユーザABC向けのウェブページの遷移とを示している。図13と図14とでは、ユーザKNMからの支援要請に対するユーザABCの支援方法が異なる。
図13は、ユーザKNMからの支援要請に対するユーザABCの支援方法として、ユーザKNMのバトル相手のモンスターキャラクタとバトルを行う(つまり、参戦する)支援方法(後述する第2の支援)が選択された場合である。
図13を参照すると、ウェブページP4(図12のウェブページP4と同じ)においてメニューm22が選択操作されると、P5に示すようにウェブページが更新され、支援要請が受け付けられたことがユーザKNMに通知される。ユーザKNMによる支援要請が受け付けられると、所定条件を満たすユーザに対して支援要請を受けるか否かを確認するためのメッセージが表示される。ここでは、所定条件を満たすユーザABC向けのウェブページの一例をP6に示す。ウェブページP6には、支援方法の選択を促すために、「参戦する」と表記されたメニューm31と、「応援する」と表記されたメニューm32とが表示される。ウェブページP6においてメニューm31(「参戦する」)が選択操作されると、P7に示すようにウェブページが更新されて、ユーザABCが、戦士カードを使用してユーザKNMのバトル相手であるモンスターキャラクタMC1とバトルを行う画面に遷移する。ウェブページP7は、例えば図12のウェブページP1,P2と同形式であるが、モンスターキャラクタMC1のHPの値は、ユーザKNMが敗北した時点のHP(つまり、ウェブページP4のモンスターキャラクタMC1のHP)の値となっている。ウェブページP8に示すように、このバトルでユーザABCが、ユーザKNMのバトル相手であるモンスターキャラクタMC1を撃破すると、ユーザABCがモンスターキャラクタMC1を倒してくれたことを示すメッセージがユーザKNMに通知される。ウェブページP9に、そのメッセージを含むウェブページの表示例を示す。なお、ユーザKNMへの通知方法は、ウェブページP9に例示したテキスト形式の視覚的情報に限られず、音声などの聴覚的情報であってもよい。
図14は、ユーザKNMからの支援要請に対するユーザABCの支援方法として、ユーザKNMによるバトルを応援するという支援方法(後述する第1の支援)が選択された場合である。バトルを応援する場合、支援要請を受諾したユーザABCがユーザKNMのバトル相手とバトルを行うことはないが、支援要請元であるユーザKNMが使用する戦士カードの攻撃力を向上させる仕組みとなっている。
図14を参照すると、ウェブページP4(図12のウェブページP4と同じ)においてメニューm22が選択操作されると、P5に示すようにウェブページが更新され、支援要請が受け付けられたことがユーザKNMに通知される。ユーザKNMによる支援要請が受け付けられると、所定条件を満たすユーザに対して支援要請を受けるか否かを確認するためのメッセージが表示される。ここでは、所定条件を満たすユーザABC向けのウェブページの一例をP6に示す。ウェブページP6には、支援方法の選択を促すために、「参戦する」と表記されたメニューm31と、「応援する」と表記されたメニューm32とが表示される。ウェブページP6においてメニューm32(「応援する」)が選択操作されると、P10に示すようにウェブページが更新されて、ユーザABCが、ユーザKNMによるバトルを応援したことを確認する画面に遷移する。ユーザABCによってバトルの応援することによる支援が行われると、例えばユーザKNMがバトルで使用する戦士カードの攻撃力が増加する。つまり、その後にユーザKNMがモンスターキャラクタMC1と再びバトルを行うときには、自ら使用する戦士カードの攻撃力がユーザABCの応援によって増加した状態でバトルが行われる。このとき、ユーザKNMには、戦士カードの攻撃力が増加したことを示すメッセージが通知される。ウェブページP11に、そのメッセージを含むウェブページの表示例を示す。なお、ユーザKNMへの通知方法は、ウェブページP11に例示したテキスト形式の視覚的情報に限られず、音声などの聴覚的情報であってもよい。
(6)ゲーム制御装置における各処理の概要
次に、上述した本実施形態のゲームを実現するためゲーム制御装置における各処理について説明する。
本実施形態では、ゲームサーバ20及びデータベースサーバ30によってゲーム制御装置が構成されている。以下では、上述した対戦型デジタルカードゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図15を参照して説明する。図15は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。なお、図15の機能ブロック図中、登録手段51、第1の支援手段56、及び第2の支援手段57は、必ずしも必須の構成要素ではない。
なお、以下の説明において、通信端末10に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末10で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネル操作によるウェブページのスクロール操作によって変化しうる。
登録手段51は、例えば通信端末10に提供するウェブページ上での通信端末10への適切な操作入力に基づいてユーザの登録要求を認識し、登録処理を行う機能を備える。この登録処理は、ユーザが本実施形態のゲームにユーザ登録を行うときに実行される。
登録手段51の機能は、例えば以下のように実現される。ゲームサーバ20のCPU21は、通信インタフェース部25を介して通信端末10から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ20から提供されるウェブページ上での通信端末10に対する所定の操作(例えば、所定のメニューの選択操作やユーザが指定するユーザIDやパスワード等のテキスト入力等)によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末10を特定するための情報(例えばUID(Unique Identifier)などの端末の個体識別情報、メールアドレス等)が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザIDが含まれていてもよい。
CPU21は、登録要求メッセージを受信し、登録要求メッセージにユーザIDが含まれていない場合には、ユーザIDを新規に発行してそのユーザIDの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末10へ送信する。CPU21は、登録要求メッセージを受信し、登録要求メッセージにユーザIDが含まれている場合には、そのユーザIDの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末10へ送信する。
登録が完了すると、CPU21は、ユーザIDに対応するユーザデータを生成し、ユーザデータベース31に格納する。登録が完了すると、ユーザは、本実施形態のゲームを実行することが可能となる。
バトル実行手段52(対戦実行手段)は、ユーザによるゲーム上のバトル(対戦)を実行する機能を備える。
バトル実行手段52の機能は、例えば、通信端末10に表示するウェブページを、通信端末10からの要求に応じて逐次更新させることによって、ゲーム上のバトルを実行するようにしてもよい。この場合、バトル実行手段52の機能を実現するために、ゲームサーバ20のCPU21は、通信端末10からHTTPリクエストを受信し、そのHTTPリクエストに応じてゲーム上の所定の処理を行い、ゲームの実行結果としてのHTMLデータを含むHTTPレスポンスを通信端末10宛に返信する。
例えば、図10に示すゲームのトップページ上でメニューm1が選択操作されたことによってHTTPリクエストが通信端末10からゲームサーバ20宛に送信されると、ゲームサーバ20のCPU21は、そのHTTPリクエストに応じて、図11に示すバトルのトップページを表示するためのHTMLデータを含むHTTPレスポンスを通信端末10宛に送信する。このとき、HTMLデータを作成するに当たって、CPU21は、バトル管理データからゲームを実行中のユーザのバトル相手となるモンスターキャラクタとそのHPを読み出してRAM23に記憶させるとともに、読み出したデータに基づいてHTMLデータを生成する。
モンスターキャラクタとのバトル処理では、ゲームサーバ20のCPU21は、ユーザによる適切な操作に応じて、ユーザが保有する戦士カードのうちバトルで使用される所定数の戦士カードの選択結果を取得する。なお、以下では、理解の容易のために、バトルに参加する戦士カードの数を1枚とする。CPU21は、各ユーザについて、モンスターキャラクタを倒したタイミングで、あるいはランダムなタイミングで、ゲームデータベース32が記憶するモンスターキャラクタデータのうちいずれかのモンスターキャラクタをバトルのために出現させる。具体的には、CPU21は、ユーザのバトル相手となるモンスターキャラクタのデータを読み出し、バトル管理データに新たに書き込む。このとき、モンスターキャラクタのデータのHPの初期値がランダムに決定される。例えば、モンスターキャラクタデータにおいてモンスターキャラクタMC1のHPが1500〜2000の範囲として設定されているが、実際のバトル処理を行うときに使用されるHPの初期値として、1500〜2000の範囲の中からランダムに1つの値が決定される。
CPU21は、出現中のモンスターキャラクタのデータをバトル管理データから読み出し、バトルで使用される戦士カードのデータをユーザデータから読み出して、RAM23に記憶させ、以下のバトル処理を実行する。
具体的には、例えばメニューm11,m12(「バトルする」)のいずれかのメニューが選択操作され、モンスターキャラクタとのバトルが開始されると、ユーザが戦士カードを使ってモンスターキャラクタを攻撃するとき(例えば図12のウェブページP1でメニューm20(「攻撃する」)が選択操作されたとき)には、CPU21は、使用される戦士カードの攻撃力の値に応じてモンスターキャラクタのHPを低減させる処理を行う。以下、メニューm20(「攻撃する」)に対する操作を「攻撃操作」という。
例えば、戦士カードの攻撃力をPaとし、ランダムに決定される係数をkとすると、1回の攻撃操作によって、モンスターキャラクタのHPに対して行われる演算は、例えば以下の式(1)に従って行われるようにしてもよい。更新されたHPの値は、バトル実行中に逐次RAM23に上書きされる。

HP=HP−Pa×k …(1)
また、攻撃操作に応じてバトル相手のモンスターキャラクタから戦士カードに対して、一定の、あるいはランダムな値の攻撃力にて攻撃が加えられる。モンスターキャラクタの攻撃力は、HPに概ね比例した値としてもよいし、一定の、あるいはランダムな値であってもよい。モンスターキャラクタから加えられる攻撃力、あるいはその攻撃力の積算値(複数回の攻撃操作に伴う攻撃力の積算値)が戦士カードの防御力を上回った場合に、その戦士カードが倒されたことになる。ユーザがバトルで使用される戦士カードが1枚のみの場合、その戦士カードが倒されたときにはユーザの敗北となる。なお、戦士カードが複数枚バトルに参加する場合、モンスターキャラクタから加えられる攻撃の対象となる戦士カードは一定の順に、あるいはランダムに決定されてよい。
攻撃操作によるモンスターキャラクタのHPの更新は、上述した式(1)に限られない。例えば、上記式(1)におけるPaは戦士カードの攻撃力ではなく、所定の範囲の中から攻撃操作に応じてランダムに決定される数値としても良い。
また、バトルの勝敗の決定方法は適宜設定することができる。例えば、所定回数の攻撃操作によって、あるいは所定時刻までにモンスターキャラクタのHPをゼロにすることができなければ、そのモンスターキャラクタは倒せなかったと判断される。
CPU21は、更新後のモンスターキャラクタのHPの値がゼロになっていない場合には、更新後のモンスターキャラクタのHP(RAM23上の値)をバトル管理データに書き込む。CPU21は、更新後のモンスターキャラクタのHPの値がゼロになった場合には、モンスターキャラクタを撃破したと判断して、バトル管理データから、対象となるユーザについてのモンスターキャラクタのデータを消去するとともに、ゲームの進行度としてのユーザデータのモンスター撃破数を1だけ増加させる。
CPU21は、ユーザによる1回のバトルが行われると、ユーザのユーザデータにアクセスして、攻撃ポイントの値を所定量、あるいはバトルで使用した戦士カードに応じた量だけ低下させる処理を行う。
受付手段53は、支援要請元のユーザ(第1のユーザ)からバトル(第1の対戦)における支援要請を受け付ける機能を備える。
受付手段53の機能は、以下のようにして実現することができる。ゲームサーバ20のCPU21は、例えば、ゲームを実行中のユーザによってメニューm22(「支援要請する」)の選択操作が行われたことを認識すると、ゲームデータベース32内の支援要請リストに所要のデータを書き込むことによって、支援要請を受け付ける。支援要請リストに書き込まれるデータは、図9に示したように、例えばユーザID、バトル相手(バトルでユーザが敗北したときのモンスターキャラクタ)、バトルの終了時刻等である。
判定手段54は、支援要請元のユーザ(第1のユーザ)以外のユーザに対して、第1のユーザとのゲームの進行度の差に応じて、第1のユーザのバトル(第1の対戦)における支援要請を行うか否かを判定する機能を備える。
判定手段54の機能は、例えば以下のようにして実現することができる。ゲームサーバ20のCPU21は、ユーザの通信端末10から、ゲームのトップページあるいはバトルのトップページに対するHTTPリクエストが送信された場合には、そのユーザよりもモンスター撃破数が少ない(つまり、進行度が低い)ユーザからの支援要請があるか否か、支援要請リストを検索する。より好ましくは、CPU21は、上記HTTPリクエストを送信したユーザよりもモンスター撃破数が所定数以上少ないユーザからの支援要請があるか否か、支援要請リストを検索する。モンスター撃破数の比較は、HTTPリクエストを送信したユーザと、支援要請リストに記述されたユーザとの間のユーザデータのモンスター撃破数を読み出して、比較することにより行われる。
要請手段55は、判定手段54の判定結果に応じて、支援要請元のユーザ(第1のユーザ)以外のユーザのうち支援要請先の第2のユーザを特定し、第2のユーザに対して支援要請を行う機能を備える。
要請手段55の機能は、以下のようにして実現できる。ゲームサーバ20のCPU21は、上述したように、HTTPリクエストを送信したユーザと、支援要請リストに記述されたユーザとの間のユーザデータのモンスター撃破数を比較する。そして、CPU21は、支援要請リストに記述されたユーザのうち、HTTPリクエストを送信したユーザよりもモンスター撃破数が少ないユーザの支援要請を、HTTPリクエストを送信したユーザの通信端末10宛に送信する。つまり、ゲームのトップページあるいはバトルのトップページに対するHTTPリクエストがユーザから送信される度に、そのユーザを支援要請先とするか否かについて、モンスター撃破数に基づいて判定することにより、第2のユーザが特定される。この場合、CPU21は、既に支援要請を送信したいずれかのユーザから支援要請を受諾する返信があるまで、ゲームのトップページあるいはバトルのトップページに対するHTTPリクエストを送信するユーザについて上記処理を行う。
なお、第2のユーザを特定するタイミングは上述した例に限られない。その他の例として、CPU21は、ユーザによるメニューm22(「支援要請する」)の選択操作を認識し、支援要請を受け付けたタイミングでユーザデータを参照し、その時点におけるモンスター撃破数の差から1又は複数の第2のユーザを予め特定してもよい。そして、特定された第2のユーザのいずれかのユーザからアクセスが行われた(つまり、ゲームのトップページあるいはバトルのトップページに対するHTTPリクエストが送信された)ときに、そのアクセスしたユーザに対して支援要請を送信してもよい。
要請手段55は、好ましくは、例えば図13のウェブページP6に示したように、支援要請元のユーザ(第1のユーザ)からの支援要請に対して、第1の支援(後述する第1の支援手段56による第1の支援)、又は第2の支援(後述する第2の支援手段57による第2の支援)のいずれかを、上記第2のユーザが選択可能に提示する機能を備えてもよい。第1の支援は、支援要請を受諾した他のユーザが支援要請元のユーザのバトルに直接関与することなく、間接的に支援する(応援する)支援方法である。第2の支援は、支援要請を受諾した他のユーザが支援要請元のユーザのバトル相手とバトルを行う(参戦する)支援方法である。
この要請手段55の機能を実現するために、CPU21は、HTTPリクエストの送信元ユーザに対して、仲間からの支援要請があることを通知するメッセージと支援方法の選択メニューを含むようにして、ゲームのトップページあるいはバトルのトップページを表示するためのHTMLデータを送信する(例えば、図13のウェブページP6参照)。
第1の支援手段56(支援手段)は、支援要請元のユーザ(第1のユーザ)からの支援要請に応じた、第1のユーザ以外のユーザ(第2のユーザ)による所定の操作入力の情報に基づいて、バトルにおける第1のユーザのバトル能力、又はバトルのバトル相手のバトル能力を、第1のユーザが有利となるように調整する第1の支援を実行する機能を備える。ここで、第2のユーザは、支援要請先のユーザのうち支援要請を受諾したユーザを意味する。第2のユーザは、1人のユーザとは限らず複数存在してもよい。
第1の支援手段56の機能は、以下のようにして実現することができる。ゲームサーバ20のCPU21は、いずれかのユーザ(支援要請先の第2のユーザ)からのメニューm32(「応援する」)の選択操作(所定の操作入力)を認識すると、支援要請元のユーザ(第1のユーザ)の支援対象となるバトルにおいて、第1のユーザが使用する戦士カードの攻撃力を増加させる、あるいはバトル相手のモンスターキャラクタの攻撃力を低下させる処理を行う。なお、戦士カードの攻撃力の増加、あるいはモンスターキャラクタの攻撃力の低下は、所定比率の増加あるいは低下でもよいし、所定量の増加あるいは低下でもよい。
第2の支援手段57は、支援要請元のユーザ(第1のユーザ)からの支援要請に応じて、第1のユーザ以外のユーザ(第2のユーザ)によって第1のユーザのバトル相手のモンスターキャラクタとのバトルを行う第2の支援を実行する機能を備える。
第2の支援手段57の機能は、以下のようにして実現することができる。ゲームサーバ20のCPU21は、いずれかのユーザ(支援要請先の第2のユーザ)からのメニューm31(「参戦する」)の選択操作(所定の操作入力)を認識すると、そのユーザと、支援対象のバトルにおけるモンスターキャラクタとの間で、バトルの処理を実行する。具体的には、CPU21は、第2のユーザが支援対象のバトルにおけるモンスターキャラクタに対して攻撃操作が可能となるようにHTMLデータを生成して、第2のユーザの通信端末10宛に送信する(例えば、図13のウェブページP7参照)。このとき、バトル相手となるモンスターキャラクタのHPは、支援要請リストに書き込まれているHPの値を元にバトルが開始される。
(7)本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図16及び図17のシーケンスチャートを参照して説明する。図16及び図17は、本実施形態のゲーム制御装置によって行われる、本実施形態のゲームのバトル処理を示しており、図16は支援要請を受諾した他のユーザが参戦する場合であり、図17は、支援要請を受諾した他のユーザが応援する場合である。なお、図16及び図17には、図13及び図14に記載された各ウェブページが表示されるタイミングを符号により示している。
また、図16及び図17では、ユーザKNMが第1のユーザの例であり、ユーザABCが第2のユーザの例である。
(7−1)支援要請を受諾したユーザが参戦することで支援する場合
先ず、ゲームを実行中のユーザKNM(第1のユーザ)が例えばモンスターキャラクタMC1にバトルに敗北すると、例えば図13のウェブページP4が表示される。ここで、メニューm22(「支援要請する」)が選択操作され、支援要請を含むHTTPリクエストを受信すると(ステップS100)、ゲームサーバ20のCPU21は、ゲームデータベース32内の支援要請リストに所要のデータを書き込む(ステップS110)。書き込まれるデータは、図9に示したように、例えば、ユーザID、バトル相手(バトルでユーザが敗北したときのモンスターキャラクタ)、バトルの終了時刻等である。支援要請リストへの書き込み後、CPU21は、支援要請が受け付けられたことを通知するためのHTMLデータをユーザKNMの通信端末10宛に送信する(ステップS120)。これにより、例えば図13のウェブページP5がユーザKNMの通信端末10に表示される。ユーザKNMの支援要請が支援要請リストに書き込まれた後、CPU21は、ゲームのトップページあるいはバトルのトップページを表示するためのHTMLデータを送信するユーザを認識する度に、そのユーザがユーザKNMよりもモンスター撃破数が多いか否かを判定し、多い場合には、そのユーザに対してユーザKNMの支援要請を送信する(ステップS140)。つまり、支援要請元のユーザよりもモンスター撃破数が多い(つまり、ゲームの進行度が高い)ユーザを対象として支援要請が行われる。ここでは、ユーザABCの通信端末10宛にユーザKNMの支援要請が送信された場合を想定する。支援要請を受信したユーザABCの通信端末10には、例えば図13のウェブページP6が表示される。
ウェブページP6上でメニューm31(「参戦する」)が選択操作され、支援要請が受諾されたことを認識すると(ステップS150)、CPU21は、ユーザABCと、ユーザKNMがバトルで敗北したモンスターキャラクタMC1との間のバトル画面用のHTMLデータを生成して送信する(ステップS160)。その結果、例えば図13のウェブページP7がユーザABCの通信端末10に表示される。このとき、ユーザABCのバトルにおけるモンスターキャラクタMC1のHPは、バトル管理データのユーザKNMのデータが読み出されて表示される。そして、ユーザABCの1又は複数回の攻撃操作に基づいて、CPU21は、バトル処理を行う(ステップS170)。ここで、ユーザABCがモンスターキャラクタMC1を撃破した場合には、CPU21からのHTMLデータの送信に応じて、例えば図13のウェブページP8がユーザABCの通信端末10に表示される。
CPU21は、ユーザABCとモンスターキャラクタMC1のバトルの後、支援要請リスト、バトル管理データ、及びユーザデータを更新する(ステップS180)。例えば、ユーザABCがモンスターキャラクタMC1を撃破した場合、支援要請リストから、該当データ(ユーザKNMの対戦相手としてのモンスターキャラクタMC1)を削除するとともに、バトル管理データ中、ユーザKNMの出現中のモンスターの欄からモンスターキャラクタMC1を削除する。また、CPU21は、ユーザKNMとユーザABCのユーザデータにアクセスして、それぞれモンスター撃破数を1だけ増加させる。
その後、例えば、ユーザKNMの通信端末10からのゲームまたはバトルのトップページのHTTPリクエストの受信に応じて、ユーザABCによる支援結果を通知するためのHTMLデータをユーザKNMの通信端末10宛に送信する(ステップS190)。これにより、例えば図13のウェブページP9がユーザKNMの通信端末10に表示される。
(7−2)支援要請を受諾したユーザが応援することで支援する場合
ステップS100〜S140については、(7−1)の場合と同じであるため、重複説明を省略する。
ウェブページP6上でメニューm32(「応援する」)が選択操作され、支援要請が受諾されたことを認識すると(ステップS200)、CPU21は、応援により所定の特典が得られたことを通知するためのHTMLデータを生成して送信する(ステップS210)。その後に、ユーザKNMが支援対象のモンスターキャラクタMC1と再度バトルを行うときにHTMLデータが送信されると、ユーザKNMの通信端末10には、図14のウェブページP11に例示したように、応援によって攻撃力が上昇したことを通知するためのメッセージが表示される。その後、バトル処理において攻撃操作が行われたことを認識する度に、CPU21は、ユーザKNMが使用する戦士カードの攻撃力を、例えば一定量あるいは一定比率上昇させるように調整する(ステップS240)。CPU21は、攻撃操作に応じて、調整された攻撃力に基づいてモンスターキャラクタMC1のHPの低下量を決定してHPを更新する(ステップS250)。CPU21は、モンスターキャラクタMC1のHPを更新すると、更新後のHPを含むHTMLデータを生成して(ステップS260)、ユーザKNMの通信端末10宛に送信する(ステップS270)。なお、図17では、ステップS230〜S270は、1回の攻撃操作に応じた一連の処理を示しているが、複数回の攻撃操作が行われる場合には、ステップS230〜S270の処理が繰り返し行われる。
上述したように、支援要請を受諾したユーザABCが応援することによる支援を選択する場合、その支援方法は、ユーザABCが支援要請元のユーザKNMのバトル相手と直接的にバトルすることではなく、例えば、支援要請元のユーザKNMのバトル能力をユーザKNMが有利となるように調整することである。言わば、第2の支援は、ユーザKNMによるモンスターキャラクタMC1とのバトルを間接的に支援するものである。つまり、ユーザKNMが例えば自らの操作によってモンスターキャラクタMC1とのバトルに勝利するように補助されるため、ユーザKNMにとっては、バトルに勝利すれば自らバトルに勝利したという達成感を得ることができる。
以上説明したように、本実施形態のゲーム制御装置では、支援要請元のユーザ(第1のユーザ)の支援要請先が、ゲームの進行度の差に応じて決定される。例えば、第1のユーザよりもモンスター撃破数の多い(つまり、ゲームの進行度が高い)ユーザ(第2のユーザ)に対して支援要請が行われる。ゲームの進行度が高い第2のユーザはゲーム上の能力(例えば、バトルで使用する戦士カードの能力等)が高いと考えられるため、第2のユーザに対して支援要請が行われることで、第1のユーザに対する支援は実効性が高いものとなる。その結果、ゲームの進行度が低いユーザであっても、ゲームのシナリオに応じたゲームの面白味を感じられるようになる。また、ゲームの進行度が高いユーザが、ゲームの進行度が低いユーザのゲームの進行を補助する構成となるため、ユーザ全体でゲームの活性化が図れるようになる。
上記実施形態では、モンスター撃破数の差に応じて支援要請を行うか否か判定し、モンスター撃破数の差は適宜設定できる。また、上記実施形態の説明においても述べたが、判定手段54は、支援要請元のユーザ(第1のユーザ)以外のユーザのうち、第1のユーザとのモンスター撃破数(ゲームの進行度)の差が所定値以上であるユーザに対して支援要請を行うと判定してもよい。
この構成では、支援要請先のユーザ(第2のユーザ)の数を適切に制限することができる。また、第1のユーザと比べて第2のユーザの進行度を十分に高く設定できるため、第1のユーザよりもゲーム上の能力が十分に高いユーザによる支援を受けることが期待でき、支援の実効性をより高めることができる。
上記実施形態において、第1の支援手段56を設けることは必須ではなく、支援要請先のユーザ(第2のユーザ)を特定した後、その支援方法は適宜設定してもよいが、第1の支援手段56によって実現される第1の支援は、以下の点で好ましい。
第2のユーザによって行われる第1の支援は、支援要請元のユーザ(第1のユーザ)のバトル相手と直接的にバトルすることではなく、第1のユーザがバトルで使用する戦士カードの攻撃力(第1のユーザの対戦能力)、又は第1のユーザのバトル相手の攻撃力を、第1のユーザが有利となるように調整することである。言わば、第1の支援は、第1のユーザによる第1の対戦を間接的に支援するものである。つまり、第1のユーザが例えば自らの操作によって第1の対戦に勝利するように補助されるため、第1のユーザにとっては自ら対戦に勝利したという達成感を得ることができる。
上記実施形態において、第2の支援手段57を設けることは必須ではなく、支援要請先のユーザ(第2のユーザ)を特定した後、その支援方法は適宜設定してもよいが、支援要請元のユーザ(第1のユーザ)のバトル相手と直接的にバトルを行う第2の支援によっても、第1のユーザのゲームの進行を第2のユーザが補助することができる。また、第2の支援では、ゲームの進行度が高い第2のユーザによって、言わば直接的な支援が受けられるため、支援の実効性がより高くなる。
上記実施形態では、要請手段55は、好ましくは、例えば図13のウェブページP6に示したように、支援要請元のユーザ(第1のユーザ)からの支援要請に対して、第1の支援(メニューm32)、及び第2の支援(メニューm31)の方法を双方提示し、第2のユーザがいずれかの支援を選択可能にする例を示したが、その双方を提示せずにいずれか一方を提示するようにしてもよい。なお、第1の支援、及び第2の支援の方法を双方提示し、第2のユーザがいずれかの支援を選択可能にする構成とした場合には、第2のユーザが自らのゲームの進行状況に応じた柔軟な選択を可能とするゲーム設定とすることができる。
上記実施形態では、バトル実行手段52は、ユーザによるバトルの実行に伴って当該ユーザの攻撃ポイント(ゲーム上のパラメータ)を消費するように構成したが、これに限られない。なお、ユーザがバトルを実行するに当たって攻撃ポイントを消費するように構成した場合には、支援要請を受けたユーザ(第2のユーザ)が、第1の支援又は第2の支援のいずれかの支援方法を選択するに当たって、第2の支援(支援要請元のユーザのバトル相手とのバトルを実行すること)による自らの攻撃ポイントの消費量を考慮しながら選択することになるため、深いゲーム性を実現できる。
例えば、モンスターキャラクタを倒すことで、あるいはモンスター撃破数に応じて特典を得られるゲーム設定とした場合には、第2のユーザが、自らの攻撃ポイントの消費量と、得られる特典とを比較考量する構成とすることができる。より具体的には、第1の支援(言わば間接的な支援)を行った場合には、自らバトルを行わないため攻撃ポイントを減少させずに済むが、比較的少量の特典しか付与されず、モンスター撃破数を増加させることはできない。他方、第2の支援(言わば直接的な支援)を行った場合には、自らバトルを行うことで比較的な大きな特典を得るためにモンスター撃破数を増加させることができるが、攻撃ポイントが減少してしまうため別の新たなバトルを直ちに実行することができなくなる。よって、第2のユーザにとっては、このような損得の事情を勘案しながら支援方法の選択を行うようになる。
(8)変形例
以下、上述した実施形態の変形例について説明する。
(8−1)変形例1
上述した実施形態において、第1の支援手段56は、支援要請元のユーザ(第1のユーザ)と支援要請先のユーザ(第2のユーザ)の間のモンスター撃破数(ゲームの進行度)の差が大きいほど、第1のユーザがより有利になるように調整してもよい。これにより、第2のユーザのゲームの進行度が第1のユーザよりも高いほど、第2のユーザによる支援によって第1のユーザのゲームの進行がしやすくなる。その結果、支援を行う第2のユーザ次第で、第1のユーザのゲームの進行率が調整されることになり、ゲーム性の幅を広げることができる。
本変形例の第1の支援手段56を実現するために、ゲームサーバ20のCPU21は、第2のユーザから支援要請の受諾の返信があったときに、第1のユーザと第2のユーザのモンスター撃破数の差を、ユーザデータを参照してもとめる。モンスター撃破数の差と、ユーザがバトルで使用する戦士カードの攻撃力の上昇率との関係を示すデータを例えばROM22に記憶させておく。CPU21は、モンスター撃破数の差をもとめると、ROM22内のデータを参照して、第1のユーザがバトルで使用する戦士カードの攻撃力の上昇率を決定する。
(8−2)変形例2
図18は、本変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。図18の機能ブロック図は、図15と比較すると、関係付け手段58が追加された点で異なる。関係付け手段58は、ユーザ間を関係付ける機能を備える。例えば、関係付け手段58は、ユーザIDに基づく申請を契機として、当該ユーザIDと他のユーザIDとを仲間として関係付ける機能を備える。
関係付け手段58の機能は例えば、以下のとおり実現される。ゲームサーバ20のCPU21は、通信インタフェース部25を介して、あるユーザIDに対応するユーザの通信端末10から、仲間になりたいユーザID(あるいは、対応するユーザ名)を指定した申請メッセージ(申請)を受け付ける。この申請メッセージの送信は、ユーザの通信端末10に提供されるウェブページの機能として予め設定されている。CPU21は、申請メッセージを受け付けると、申請メッセージに含まれるユーザIDに基づくアクセスがあったタイミングで、そのユーザIDに対応する通信端末10宛に、他のユーザIDに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるHTMLデータを送信する。その申請を承認することが返信されれば、CPU21は、両者を仲間として登録する。具体的には、CPU21は、ユーザデータベース31内の対応する2つのユーザIDのユーザデータの「仲間のユーザID」の箇所(図6参照)にデータを書き込む。
なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限らず、同一のゲーム上のステージを実行するユーザ同士を仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間でバトルを行うゲーム上のモードが存在する場合には、所定回数以上バトルを行ったユーザ同士を自動的に仲間として登録してもよい。
本変形例では、要請手段55は、支援要請先のユーザ(第2のユーザ)を、支援要請元のユーザ(第1のユーザ)と仲間として関係付けられたユーザの中から選択してもよい。このように選択することで、第1のユーザにとっては、仲間によって支援を受けているという実感が得られるため、仲間との関係性を高めることができる。そのため、ゲームのソーシャル性を高めることができる。
本変形例における要請手段55の機能は、以下のようにして実現することができる。
ゲームサーバ20のCPU21は、ユーザからゲームのトップページあるいはバトルのトップページに対するHTTPリクエストが送信されると、支援要請リストに記述されたユーザのうち、HTTPリクエストを送信したユーザよりもモンスター撃破数が少なく、かつ仲間のユーザからの支援要請を、HTTPリクエストを送信したユーザの通信端末10宛に送信する。つまり、ゲームのトップページあるいはバトルのトップページに対するHTTPリクエストがユーザから送信される度に、そのユーザを支援要請先とするか否かについて、モンスター撃破数と仲間であるか否かに基づいて判定することにより、第2のユーザが特定される。この場合についても、CPU21は、既に支援要請を送信したいずれかのユーザから支援要請を受諾する返信があるまで、ゲームのトップページあるいはバトルのトップページに対するHTTPリクエストを送信するユーザについて上記処理を行う。
なお、支援要請先のユーザを支援要請元のユーザの仲間に限定してしまうと、第2のユーザ(支援要請先のユーザ)が決定することができない可能性がある。つまり、支援要請を行った後、仲間からのログイン又はアクセスがなく、支援を適時に受けられず、支援の実効性が失われる可能性がある。そこで、以下のように処理を行ってもよい。
CPU21は、支援要請リストに書き込まれてから所定期間の間、ユーザからゲームのトップページあるいはバトルのトップページに対するHTTPリクエストが送信される度に、支援要請リストに記述されたユーザのうち、HTTPリクエストを送信したユーザよりもモンスター撃破数が少なく、かつ仲間のユーザからの支援要請を、HTTPリクエストを送信したユーザの通信端末10宛に送信する。上記所定期間の間に、支援要請先のユーザから支援要請を受諾する返信がない場合には、支援要請先のユーザを支援要請元のユーザの仲間に限定しないようにする。つまり、CPU21は、支援要請リストに記述されたユーザのうち、HTTPリクエストを送信したユーザよりもモンスター撃破数が少ないユーザからの支援要請を、HTTPリクエストを送信したユーザの通信端末10宛に送信する。
なお、バトルに終了時刻が設定されている場合には、その終了時刻の所定時間前までに仲間からの支援要請の受諾の返信がなければ、支援要請先のユーザを支援要請元のユーザの仲間に限定しないようにしてもよい。
(8−2)変形例3
上述した実施形態において、第1の支援手段56によって実行される第1の支援(バトルにおける支援要請元の第1のユーザのバトル能力、又は第1のユーザのバトルのバトル相手のバトル能力を、第1のユーザが有利となるように調整すること)の支援要請を複数のユーザから受諾することを許容してもよい。その場合には、支援要請を受諾したユーザの数が増加するにつれて、第1のユーザがより有利となるように調整されるようにしてもよい。
本変形例を実現するために、例えば、CPU21は、支援要請リストに書き込まれてから所定期間の間、ユーザからゲームのトップページあるいはバトルのトップページに対するHTTPリクエストが送信される度に、支援要請リストに記述されたユーザのうち、HTTPリクエストを送信したユーザよりもモンスター撃破数が少ないユーザからの支援要請を、HTTPリクエストを送信したユーザの通信端末10宛に送信する。そして、CPU21は、上記所定期間の間に支援要請を受諾した(つまり、メニューm32(「応援する」)の選択操作をした)ユーザの数をカウントする。CPU21は、そのカウント値に応じて、例えば第1のユーザがバトルで使用する戦士カードの攻撃力の上昇率を決定する。
なお、本変形例では、図14のウェブページP11において、例えば5人のユーザからの応援による支援を受けている場合には、「5人の応援により攻撃力UP中!」などと表示させることが好ましい。
以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。例えば、上記実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。
上述した実施形態及び変形例では、カードを用いたバトルを行う場合を例として説明したが、これに限られない。カードでなく、例えば、ユーザのアバタ画像等の他のオブジェクトであってもよい。あるいは、カード等のオブジェクトを使用せずにバトル処理を行ってもよい。
上述した実施形態では、本発明の実行対象のゲームがカードを用いたバトルゲームである場合の例について説明したが、本発明のゲームのこれに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲームやレースゲームのようにゲーム内のステージを進行させていくゲームでは、支援要請先のユーザのステージの進行度に応じて、支援要請元のユーザのステージの進行率を上昇させる(例えば、キャラクタやレースカー等の進行速度を早くする等)ようにすることができ、好適に本発明を適用することができる。また、本発明をFPS(First Person shooter)、TPS(Third Person shooter)等のシューティングゲームに適用する場合には、支援要請先のユーザの敵オブジェクトの撃破数が多いほど(つまり、支援要請先のユーザの進行度が高いほど)、支援要請元のユーザに与えられる支援として、そのユーザのシューティングにおいて表示される照準の径が拡大するようにしてもよい。
上述した実施形態では、本発明のゲームの進行度の一例としてモンスター撃破数を挙げたが、ゲームの進行度は、ゲームの性質によって任意に設定可能である。例えば、ゲーム内でクリアしたステージの数や、ゲーム内で取得したアイテムの数、あるいはゲーム内で与えられた特定のミッションを達成した回数等、ミッションを所定回数達成する毎に上昇するレベル等のパラメータ、ゲーム画面上の特定のメニューの選択回数に応じて決定してもよい。
上述した実施形態では、ユーザによる通信端末に対する所定の操作入力は、ユーザの通信端末に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えた通信端末を振ることによる操作入力、あるいはジェスチャによる操作入力(ジェスチャ入力)であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末に対する所定のジェスチャを行うことで通信端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能な通信端末の場合には、操作入力は、音声を入力することにより行われてもよい。
上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。
上述した実施形態では、ネットワーク上のゲームサーバ20及びデータベースサーバ30によって、バトル実行手段52、受付手段53、判定手段54、要請手段55、第1の支援手段56、及び第2の支援手段57の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末10によって実現する構成としてもよいし、少なくとも一部の手段を通信端末10によって実現する構成としてもよい。通信端末10とゲームサーバ20とでは実質的に同一のハードウエア構成を採るため、上記実施形態に記載したようにして通信端末10によっても各機能を実現できる。図19(a),(b)には、本実施形態のゲーム制御装置の各機能(図15に示す各機能)について、通信端末10と、ゲームサーバ20及びデータベースサーバ30との間の分担例を示す。
10…通信端末
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…第1の支援手段
57…第2の支援手段
(3)ゲームサーバの構成
図4を参照してゲームサーバ20の構成について説明する。
ゲームサーバ20は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末10に対してゲームのウェブサービスを提供する。図に示すように、ゲームサーバ20は、CPU21、ROM22、RAM23、データベース(DB)アクセス部24、及び、通信インタフェース部25を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス26が設けられている。なお、ゲームサーバ20は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。
(3)ゲームサーバの構成
図4を参照してゲームサーバ20の構成について説明する。
ゲームサーバ20は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末10に対してゲームのウェブサービスを提供する。図に示すように、ゲームサーバ20は、CPU21、ROM22、RAM23、データベース(DB)アクセス部24、及び、通信インタフェース部25を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス26が設けられている。なお、ゲームサーバ20は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

Claims (11)

  1. ユーザによるゲーム上の対戦を実行する対戦実行手段と、
    第1のユーザから第1の対戦における支援要請を受け付ける受付手段と、
    第1のユーザ以外のユーザに対して、第1のユーザとのゲームの進行度の差に応じて、前記第1の対戦における支援要請を行うか否かを判定する判定手段と、
    前記判定手段の判定結果に応じて、第1のユーザ以外のユーザのうち支援要請先の第2のユーザを特定し、第2のユーザに対して前記支援要請を行う要請手段と、
    を備えた、ゲーム制御装置。
  2. 前記判定手段は、第1のユーザ以外のユーザのうち、第1のユーザとのゲームの進行度の差が所定値以上であるユーザに対して支援要請を行うと判定することを特徴とする、
    請求項1に記載されたゲーム制御装置。
  3. 前記要請手段によって行われた前記支援要請に応じた、前記第2のユーザによる所定の操作入力の情報に基づいて、前記第1の対戦における前記第1のユーザの対戦能力、又は前記第1の対戦の対戦相手の対戦能力を、前記第1のユーザが有利となるように調整する第1の支援を実行する支援手段、を備えたことを特徴とする、
    請求項1又は2に記載されたゲーム制御装置。
  4. 前記支援手段は、前記第1のユーザと前記第2のユーザのゲームの進行度の差が大きいほど、第1のユーザがより有利になるように調整することを特徴とする、
    請求項3に記載されたゲーム制御装置。
  5. 前記支援要請は、前記第2のユーザによる前記第1の対戦の対戦相手との対戦を実行することであることを特徴とする、
    請求項1に記載されたゲーム制御装置。
  6. 前記要請手段は、判定手段の判定結果に応じて、前記第1の対戦において前記第1のユーザが有利になるように調整する第1の支援、又は、前記第2のユーザによる前記第1の対戦の対戦相手との対戦を実行する第2の支援のいずれかを、前記第2のユーザが選択可能に提示することを特徴とする、
    請求項1又は2に記載されたゲーム制御装置。
  7. 前記対戦実行手段は、ユーザによる前記ゲーム上の対戦の実行に伴って当該ユーザのゲーム上のパラメータを消費することを特徴とする、
    請求項6に記載されたゲーム制御装置。
  8. ユーザ間を関係付ける関係付け手段、を備え、
    前記要請手段は、前記第2のユーザを、前記第1のユーザと関係付けられたユーザの中から選択することを特徴とする、
    請求項1〜7のいずれかに記載されたゲーム制御装置。
  9. ユーザによるゲーム上の対戦を実行するステップと、
    第1のユーザから第1の対戦における支援要請を受け付けるステップと、
    第1のユーザ以外のユーザに対して、第1のユーザとのゲームの進行度の差に応じて、前記第1の対戦における支援要請を行うか否かを判定するステップと、
    前記判定するステップの判定結果に応じて、第1のユーザ以外のユーザのうち支援要請先の第2のユーザを特定し、第2のユーザに対して前記支援要請を行うステップと、
    を備えた、ゲーム制御方法。
  10. コンピュータに、
    ユーザによるゲーム上の対戦を実行する機能、
    第1のユーザから第1の対戦における支援要請を受け付ける機能、
    第1のユーザ以外のユーザに対して、第1のユーザとのゲームの進行度の差に応じて、前記第1の対戦における支援要請を行うか否かを判定する機能、及び、
    前記判定する機能の判定結果に応じて、第1のユーザ以外のユーザのうち支援要請先の第2のユーザを特定し、第2のユーザに対して前記支援要請を行う機能、
    を実現させるためのプログラム。
  11. 通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
    ユーザによるゲーム上の対戦を実行する対戦実行手段、
    第1のユーザから第1の対戦における支援要請を受け付ける受付手段、
    第1のユーザ以外のユーザに対して、第1のユーザとのゲームの進行度の差に応じて、前記第1の対戦における支援要請を行うか否かを判定する判定手段、及び、
    前記判定手段の判定結果に応じて、第1のユーザ以外のユーザのうち支援要請先の第2のユーザを特定し、第2のユーザに対して前記支援要請を行う要請手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    ゲームシステム。
JP2012099549A 2012-04-25 2012-04-25 ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム Active JP5436612B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012099549A JP5436612B2 (ja) 2012-04-25 2012-04-25 ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012099549A JP5436612B2 (ja) 2012-04-25 2012-04-25 ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
PCT/JP2013/061723 WO2013161731A1 (ja) 2012-04-25 2013-04-22 ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2013253198A Division JP6206764B2 (ja) 2013-12-06 2013-12-06 ゲーム制御装置、プログラム、ゲームシステム

Publications (2)

Publication Number Publication Date
JP2013226223A true JP2013226223A (ja) 2013-11-07
JP5436612B2 JP5436612B2 (ja) 2014-03-05

Family

ID=49483048

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012099549A Active JP5436612B2 (ja) 2012-04-25 2012-04-25 ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム

Country Status (2)

Country Link
JP (1) JP5436612B2 (ja)
WO (1) WO2013161731A1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014090972A (ja) * 2012-11-06 2014-05-19 Dna:Kk サーバー装置、及び、ゲームプログラム
JP2014090973A (ja) * 2012-11-06 2014-05-19 Dna:Kk サーバー装置、及び、ゲームプログラム
JP2015131036A (ja) * 2014-01-15 2015-07-23 株式会社コナミデジタルエンタテインメント ゲームシステム、ゲームサーバ、端末、及びプログラム
KR20150116473A (ko) * 2014-04-04 2015-10-16 엔에이치엔엔터테인먼트 주식회사 카드 게임 진행 방법 및 이를 이용한 카드 게임 서비스 시스템
JP5819559B1 (ja) * 2015-05-08 2015-11-24 グリー株式会社 ゲームプログラム、ゲーム制御方法、およびコンピュータ
JP2015221208A (ja) * 2014-05-21 2015-12-10 株式会社 ディー・エヌ・エー オンラインゲームにおけるプレイヤの協力の容易化
US10898808B2 (en) 2014-11-28 2021-01-26 Gree, Inc. Game program, game control method, and computer

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6206764B2 (ja) * 2013-12-06 2017-10-04 株式会社コナミデジタルエンタテインメント ゲーム制御装置、プログラム、ゲームシステム
CN105413175A (zh) * 2015-10-28 2016-03-23 华为技术有限公司 实现游戏求助的方法、装置和服务器

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008245987A (ja) * 2007-03-30 2008-10-16 Namco Bandai Games Inc プログラム、情報記憶媒体、ゲーム機、サーバ、及びゲームシステム
JP2011188887A (ja) * 2010-03-11 2011-09-29 Konami Digital Entertainment Co Ltd ゲームシステム、ゲームシステムの制御方法及びプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008245987A (ja) * 2007-03-30 2008-10-16 Namco Bandai Games Inc プログラム、情報記憶媒体、ゲーム機、サーバ、及びゲームシステム
JP2011188887A (ja) * 2010-03-11 2011-09-29 Konami Digital Entertainment Co Ltd ゲームシステム、ゲームシステムの制御方法及びプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"「ngCoreはイケてる」「武器より防具が売れる」、「忍者ロワイヤル」を企画・開発双方の視点から語る", [ONLINE], JPN6013024936, 9 September 2011 (2011-09-09), ISSN: 0002537982 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014090972A (ja) * 2012-11-06 2014-05-19 Dna:Kk サーバー装置、及び、ゲームプログラム
JP2014090973A (ja) * 2012-11-06 2014-05-19 Dna:Kk サーバー装置、及び、ゲームプログラム
JP2015131036A (ja) * 2014-01-15 2015-07-23 株式会社コナミデジタルエンタテインメント ゲームシステム、ゲームサーバ、端末、及びプログラム
KR20150116473A (ko) * 2014-04-04 2015-10-16 엔에이치엔엔터테인먼트 주식회사 카드 게임 진행 방법 및 이를 이용한 카드 게임 서비스 시스템
KR102200446B1 (ko) * 2014-04-04 2021-01-11 엔에이치엔 주식회사 카드 게임 진행 방법 및 이를 이용한 카드 게임 서비스 시스템
JP2015221208A (ja) * 2014-05-21 2015-12-10 株式会社 ディー・エヌ・エー オンラインゲームにおけるプレイヤの協力の容易化
US10898808B2 (en) 2014-11-28 2021-01-26 Gree, Inc. Game program, game control method, and computer
JP5819559B1 (ja) * 2015-05-08 2015-11-24 グリー株式会社 ゲームプログラム、ゲーム制御方法、およびコンピュータ

Also Published As

Publication number Publication date
WO2013161731A1 (ja) 2013-10-31
JP5436612B2 (ja) 2014-03-05

Similar Documents

Publication Publication Date Title
JP5436612B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5646537B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5265789B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲーム制御システム
JP5442810B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5551210B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP2014068758A (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5889777B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
WO2013176002A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
JPWO2013157396A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
JP5529923B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、情報処理装置
WO2013140481A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
WO2013154020A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲーム制御システム
JP6206764B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5731710B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5290460B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP6678867B2 (ja) サーバ、制御プログラム
JP5395210B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、コミュニケーション装置
JP5827271B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5845208B2 (ja) ゲーム制御装置、プログラム、ゲーム制御システム
JP5529924B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、情報処理装置
WO2013124932A1 (ja) ゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、記録媒体、ゲームシステム
JP2014208168A (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5839711B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP2014147832A (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP2014028079A (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130903

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131024

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20131119

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131210

R150 Certificate of patent or registration of utility model

Ref document number: 5436612

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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