以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。
1.ゲームシステム
まず、図1を用いて本実施形態のゲームシステム1の概要及び概要構成について説明する。なお、図1は、本実施形態のゲームシステム1の構成を示すシステム構成の一例を示す図である。
本実施形態のゲームシステム1は、図1に示すように、ゲームサービスを提供するサーバ装置10と、端末装置20(例えば、端末装置20A、20B、20C)とが、インターネット(ネットワークの一例)に接続可能に構成されている。
ユーザは、端末装置20からインターネットを介してサーバ装置10にアクセスし、インターネットを介してサーバ装置10から送信されてくるゲームをプレーすることができる。さらに、ユーザは、端末装置20からサーバ装置10にアクセスし、他のユーザとの間でコミュニケーションを図ることができる。
サーバ装置10は、インターネットを介して通信接続された端末装置20を用いて、ユーザにゲームをプレーさせるサービスを提供することが可能な情報処理装置である。また、サーバ装置10は、コミュニケーション型のサービスを提供するSNSサーバとして機能してもよい。ここで、SNSサーバとは、複数のユーザ間でコミュニケーションを提供することが可能なサービスを提供する情報処理装置であってもよい。
また、サーバ装置10は、例えば、SNSサーバとして機能する場合には、提供するSNSの動作環境(API(アプリケーションプログラミングインタフェース)、プラットフォーム等)を利用して実行されるソーシャルゲーム(Social Game)をと呼ばれるゲームを提供することができるようになっている。
特に、サーバ装置10は、端末装置20のWebブラウザ上で提供されるゲーム、例えばHTML、FLASH、CGI、PHP、shockwave、Java(登録商標)アプレット、JavaScript(登録商標)など様々な言語で作られたブラウザゲーム(Webブラウザで設置サイトを開くだけで起動するゲーム)を提供することができるようになっている。
なお、ソーシャルゲームとは、既存のオンラインゲームとは違い、専用のクライアントソフトウェアを必要とせず、WebブラウザとSNSのアカウントのみで利用可能なゲームが含まれる。また、サーバ装置10は、ネットワークを介して他のユーザの端末(スマートフォン、パソコン、ゲーム機など)と接続し、オンラインで同時に同じゲーム進行を共有することができるオンラインゲームを提供することが可能な構成を有している。
一方、サーバ装置10は、1つの(装置、プロセッサ)で構成されていてもよいし、複数の(装置、プロセッサ)で構成されていてもよい。
そして、サーバ装置10の記憶領域(後述する記憶部140)に記憶される課金情報、ゲーム情報等の情報を、ネットワーク(イントラネット又はインターネット)を介して接続されたデータベース(広義には記憶装置、メモリ)に記憶するようにしてもよいし、SNSサーバとして機能する場合には、記憶領域に記憶されるユーザ情報146等の情報を、ネットワーク(イントラネット又はインターネット)を介して接続されたデータベース(広義には記憶装置、メモリ)に記憶するようにしてもよい。
具体的には、本実施形態のサーバ装置10は、端末装置20のユーザ(すなわち、ゲームを実行するプレーヤ)の操作に基づく入力情報を受信し、受信した入力情報に基づいてゲーム処理を行うようになっている。そして、サーバ装置10は、ゲーム処理結果を端末装置20に送信し、端末装置20は、サーバ装置10から受信したゲーム処理結果を端末装置20にユーザに閲覧可能に提供する各種の処理を行うようになっている。
端末装置20は、スマートフォン、携帯電話、PHS、コンピュータ、ゲーム装置、PDA、携帯型ゲーム機等、画像生成装置などの情報処理装置であり、インターネット(WAN)、LANなどのネットワークを介してサーバ装置10に接続可能な装置である。なお、端末装置20とサーバ装置10との通信回線は、有線でもよいし無線でもよい。
また、端末装置20は、Webページ(HTML形式のデータ)を閲覧可能なWebブラウザを備えている。すなわち、端末装置20は、サーバ装置10との通信を行うための通信制御機能、及びサーバ装置10から受信したデータ(Webデータ、HTML形式で作成されたデータなど)を用いて表示制御を行うとともに、ユーザ操作のデータをサーバ装置10に送信するWebブラウザ機能などを備え、ゲーム画面をユーザに提供する各種の処理を実行し、ユーザによってゲームを実行させるようになっている。ただし、端末装置20は、サーバ装置10から提供されたゲーム制御情報を取得して所定のゲーム処理を実行し、ゲーム処理に基づくゲームを実行してもよい。
具体的には、端末装置20は、所定ゲームを行う旨の要求をサーバ装置10に対して行うと、サーバ装置10のゲームサイトに接続され、ゲームが開始される。特に、端末装置20は、必要に応じてAPIを用いることにより、SNSサーバとして機能するサーバ装置10に所定の処理を行わせ、又は、SNSサーバとして機能するサーバ装置10が管理するユーザ情報146を取得させてゲームを実行する構成を有している。
2.サーバ装置
次に、図2を用いて本実施形態のサーバ装置10について説明する。なお、図2は、本実施形態のサーバ装置10の機能ブロックを示す図である。また、本実施形態のサーバ装置10は図2の構成要素(各部)の一部を省略した構成としてもよい。
サーバ装置10は、管理者やその他の入力に用いるための入力部120、所定の表示を行う表示部130、所定の情報が記憶された情報記憶媒体180、端末装置20やその他と通信を行う通信部196、主に提供するゲームに関する処理を実行する処理部100、及び、主にゲームに用いる各種のデータを記憶する記憶部140を含む。
入力部120は、システム管理者等がゲームに関する設定やその他の必要な設定、データの入力に用いるものである。例えば、本実施形態の入力部120は、マウスやキーボード等によって構成される。
表示部130は、システム管理者用の操作画面を表示するものである。例えば、本実施形態の表示部130は、液晶ディスプレイ等によって構成される。
情報記憶媒体180(コンピュータにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク(CD、DVD)、光磁気ディスク(MO)、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ(ROM)などによって構成される。
通信部196は、外部(例えば、端末、他のサーバや他のネットワークシステム)との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ASICなどのハードウェアや、プログラムなどによって構成される。
記憶部140は、処理部100や通信部196などのワーク領域となるもので、その機能は、RAM(VRAM)などによって構成される。なお、記憶部140に記憶される情報は、データベースで管理してもよい。
また、本実施形態においては、記憶部140には、提供するゲームに関する情報を示すゲーム情報144、提供するゲームに関しプレーヤとしてのユーザに関する情報を示すユーザ情報146、及び、その他ゲーム演算に必要な各種の情報が記憶される。
処理部100は、記憶部140内の主記憶部142をワーク領域として各種処理を行う
。処理部100の機能は各種プロセッサ(CPU、DSP等)、ASIC(ゲートアレイ等)などのハードウェアや、プログラムにより実現できる。
処理部100は、情報記憶媒体180に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体180には、本実施形態の各部としてコンピュータを機能させるためのプログラム(各部の処理をコンピュータに実行させるためのプログラム)が記憶される。
例えば、処理部100(プロセッサ)は、情報記憶媒体に記憶されているプログラムに基づいて、サーバ装置10全体の制御を行うとともに、各部間におけるデータ等の受け渡しの制御などの各種の処理を行う。さらに、端末装置20からの要求に応じた各種サービスを提供する処理を行う。
具体的には、本実施形態の処理部100は、通信制御部101、Web処理部102及びゲーム管理部104を少なくとも有している。
通信制御部101は、端末装置20とネットワークを介してデータを送受信する処理を行う。すなわち、サーバ装置10は、通信制御部101によって端末装置20等から受信した情報に基づいて各種処理を行う。
特に、本実施形態の通信制御部101は、ユーザの端末装置20からの要求に基づいて、当該ユーザの端末装置20にゲーム画面を送信する処理を行う。
Web処理部102は、Webサーバとして機能する。例えば、Web処理部102は、HTTP(Hypertext Transfer Protocol)等の通信プロトコルを通じて、端末装置20にインストールされているWebブラウザの要求に応じてデータを送信する処理、及び、端末装置20のWebブラウザによって送信されるデータを受信する処理を行う。
なお、本実施形態では、サーバ装置10がSNSサーバとしての機能も備えていている場合を例にとり説明するが、サーバ装置10を、ゲーム用のサーバと、SNS用のサーバと別々に形成してもよい。また、本実施形態のゲームの処理は、サーバ装置10が一部又は全部を行ってもよいし、端末装置20が一部を行ってもよい。
ゲーム管理部104は、端末装置20と連動し、当該端末装置20を介して入力されたプレーヤの操作に基づいて、各プレーヤにおいてロールプレーイングゲーム(RPG)や対戦ゲームに関するゲーム処理を実行するとともに、各ユーザのゲームの進行状況やアイテム管理などの各ユーザにおいて使用するキャラクタ及び各種のアイテムを含むユーザ情報146を管理する。
なお、ゲーム管理部104は、ユーザの操作に基づかず、ユーザが設定した各種のデータに基づいて自動的にゲームを実行するための自動演算処理を実行し、端末装置20で再生するためのデータを生成し、生成したデータを端末装置20に提供してもよい。
3.端末装置
次に、図3及び図4を用いて本実施形態の端末装置20について説明する。なお、図3は、本実施形態における端末装置の構成を示す機能ブロック図の一例であり、図4は、本実施形態における端末装置の外観構成を示す図の一例である。また、本実施形態の端末装置20は図3の構成要素(各部)の一部を省略した構成としてもよい。
入力部260は、プレーヤが操作データを入力するためのものである。入力部260には、表示画面に設けられたタッチパネル(図4の符号12)などの検出部262も含まれ、タッチパネル12は、表示画面におけるタッチ位置(指示位置)の2次元座標(x,y)を検出する。
なお、表示画面におけるタッチ操作には、直接的な手指によるタッチ操作と、ポインティングデバイスによる間接的なタッチ操作と、擬似的なタッチ操作とが含まれる。また、表示画面におけるスライド操作には、直接的な手指によるスライド操作と、ポインティングデバイスによる間接的なスライド操作と、擬似的なスライド操作とが含まれる。
例えば、擬似的なタッチ操作又はスライド操作とは、
(1)赤外線などの光ビームをタッチパネル面と平行に当該タッチパネル面に近接した位置で照射し、当該タッチパネルの一端部に縦横方向に一定間隔に形成される複数の照射部と、各照射部と対を構成し、当該各照射部に対向するタッチパネルの他端部に設けられ、各照射された光ビームをそれぞれ受信する複数のセンサとによって、タッチパネル12に接触又は近接した際に光ビームが遮断された縦横の座標を検出し、当該検出した座標に基づいて認識するタッチ操作又はスライド操作、及び、
(2)タッチパネル12の表示面を撮像するカメラを設け、当該カメラによってユーザがタッチパネル12に接触又は近接した位置座標を検出し、当該検出した位置座標に基づいて認識するタッチ操作又はスライド操作、
などタッチパネル12に実際に接触することによって又は近接させて検出することによって認識するタッチ操作又はスライド操作を含む。
また、タッチパネルに同時に複数のタッチ位置が検出される場合には、いずれか1つのタッチ位置(先に検出されたタッチ位置)を用いるようにしてもよいし、複数のタッチ位置を同時に処理してもよい。
なお、タッチパネルに複数の判定領域が存在する場合には、各判定領域において、1つのタッチ位置(先に検出されたタッチ位置)を用いるようにしてもよい。また、判定領域とは、取得したタッチ位置のうち、移動制御など処理部200で処理するためのタッチ位置を予め特定するタッチパネル上の範囲である。
図4(A)及び(B)に示すとおり、端末装置20の表示画面は、例えば液晶ディスプレイとタッチパネル12とを積層したタッチパネル型ディスプレイである。このうち液晶ディスプレイは、表示部290として機能し、タッチパネル12は、検出部262として機能する。以下、端末装置20の表示画面を、適宜、「タッチパネル」と称す。
また、入力部260は、タッチパネル12の他、各種の操作情報(操作信号)を入力可能なボタンやレバー、キーボード、ステアリング、マイク、加速度センサなどを備えていてもよい。
記憶部270は、処理部200や通信部296などのワーク領域となるもので、その機能はRAM(VRAM)などにより実現できる。そして、本実施形態の記憶部270は、ワーク領域として使用される主記憶部271と、最終的な表示画像等が記憶される画像バッファ272と、提供するゲームに関しプレーヤとしてのユーザに関する情報を示すユーザ情報273と、テーブルデータなどのゲームを実行する上で必要な各種のデータを記憶するゲームデータ記憶部274と、を含む。なお、これらの一部を省略する構成としてもよいし、サーバ装置10の記憶部140がその一部を構成してもよい。
特に、本実施形態の主記憶部271は、タッチ検出処理部211において取得された基
準位置及び指示位置、及び、各種のマーカの画像及び各種の判定処理において用いる条件を示す条件情報などを記憶することができる。
情報記憶媒体280(コンピュータにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク(CD、DVD)、光磁気ディスク(MO)、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ(ROM)などにより実現できる。
また、情報記憶媒体280には、本実施形態の各部としてコンピュータを機能させるためのプログラム(各部の処理をコンピュータに実行させるためのプログラム)を記憶することができる。なお、処理部200は、後述するように、情報記憶媒体280に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。
表示部290は、本実施形態により生成された画像を出力するものであり、その機能は、CRT、LCD、タッチパネル型ディスプレイ、或いはHMD(ヘッドマウントディスプレイ)などにより実現できる。
特に、本実施形態では表示部290は、タッチパネルディスプレイを用いることによりプレーヤがゲーム操作を行う入力部260としても機能する。ここでタッチパネルとして、例えば抵抗膜方式(4線式、5線式)、静電容量方式、電磁誘導方式、超音波表面弾性波方式、赤外線走査方式などのタッチパネルを用いることができる。
音出力部292は、本実施形態により生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。
通信部296は、外部(例えばホスト装置や他の端末装置)との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ASICなどのハードウェアや、プログラムなどにより実現できる。
なお、端末装置20は、サーバ装置10が有する情報記憶媒体や記憶部270に記憶されている本実施形態の各部としてコンピュータを機能させるためのプログラムやデータを、ネットワークを介して受信し、受信したプログラムやデータを情報記憶媒体280や記憶部270に記憶してもよい。このようにプログラムやデータを受信して端末装置20を機能させる場合も本発明の範囲内に含めることができる。
処理部200(プロセッサ)は、入力部260からの入力データやプログラムなどに基づいて、サーバ装置10と連動して、ゲーム処理、画像生成処理、或いは音生成処理などの処理を行う。
特に、本実施形態においては、ゲーム処理としては、ゲーム開始条件が満たされた場合にゲームを開始する処理、ゲームを進行させる処理、プレーヤオブジェクト、敵オブジェクトなどのオブジェクトを配置する処理、オブジェクトを表示する処理、ゲーム結果を演算する処理、或いはゲーム終了条件が満たされた場合にゲームを終了する処理などが含まれる。
また、処理部200は、記憶部270をワーク領域として各種処理を行う。処理部200の機能は各種プロセッサ(CPU、DSP等)、ASIC(ゲートアレイ等)などのハードウェアや、プログラムにより実現できる。
特に、本実施形態の処理部200は、オブジェクト空間設定部210と、タッチ検出処
理部211と、表示制御部212と、入力受付処理部213と、ゲーム制御部214と、ゲーム演算部215と、仮想カメラ制御部216と、ゲーム管理部217と、描画部220と、音処理部230とを含む。また、これらの一部を省略する構成としてもよい。
オブジェクト空間設定部210は、オブジェクト(プレーヤオブジェクト、移動体、敵オブジェクト(敵キャラクタ含む)など)、移動経路、建物、樹木、柱、壁、マップ(地形)などの表示物を表す各種オブジェクト(スプライト、ビルボード、ポリゴン、自由曲面又はサブディビジョンサーフェスなどのプリミティブ面で構成されるオブジェクト)をオブジェクト空間に配置設定する処理を行う。
具体的にはオブジェクト空間設定部210は、オブジェクト(モデルオブジェクト)の位置や回転角度(向き、方向と同義)を決定し、その位置(X、Y)或いは(X、Y、Z)にその回転角度(X、Y軸回りでの回転角度)或いは(X、Y、Z軸回りでの回転角度)でオブジェクトを配置する。
ここで、オブジェクト空間とは、いわゆる仮想2次元空間、仮想3次元空間の両方を含む。2次元空間とは、例えば2次元座標(X,Y)においてオブジェクトが配置される空間であり、3次元空間とは、例えば3次元座標(X,Y,Z)においてオブジェクトが配置される空間である。
そしてオブジェクト空間を2次元空間とした場合には、複数のオブジェクトそれぞれについて設定された優先順位に基づいてオブジェクトを配置する。例えば、奥側にあるように見せたいオブジェクト(スプライト)から順にオブジェクトを配置し、手前側にあるように見せたいオブジェクトを重ねて配置する処理を行うことができる。
また、描画サイズが大きなオブジェクトを画像の下方に配置し、描画サイズが小さなオブジェクトを画像の上方に配置すれば、画面の上方に対応するオブジェクト空間が奥側にあるように見せることができ、画面の下方に対応するオブジェクト空間が手前側にあるように見せることができる。
また、オブジェクト空間を3次元空間とした場合には、ワールド座標系にオブジェクトを配置する。
タッチ検出処理部211は、プレーヤが入力部260から入力した入力情報の認識処理を行う。具体的には、本実施形態のタッチ検出処理部211は、入力部260によって入力された指示位置を取得する。
例えば、タッチ検出処理部211は、タッチパネル12におけるタッチ位置(2次元の位置座標)を指示位置として取得する。また、タッチ検出処理部211は、スライド操作中(タッチ操作の開始からタッチ操作の解除までの期間)における各時点のタッチ位置(指示位置)を取得する。例えば、タッチ検出処理部211は、タッチ位置の取得を行う周期を、表示画面のフレーム周期と同じ(1/60秒〜1/120秒程度)とすることができる。
表示制御部212は、タッチパネル12上に、プレーヤのゲームに関する操作入力を受け付けるための入力受付領域を表示する。「入力受付領域」とは、タッチパネル12上のゲーム空間を表示する領域内又はゲーム空間の表示領域とは別に形成された領域に対してプレーヤによってタッチ操作入力又はスライド操作入力が実行されて接触された場合に、当該領域に対応付けられた入力指示を検出するための領域である。
入力受付領域は、タッチパネル12上の所定の領域に固定表示されていてもよいし、画面上移動可能に表示されていてもよく、例えば、プレーヤの操作対象となるキャラクタに対する特定制御を行うための特定コマンドを入力するための領域、又は、例えば、キャラクタが表示されている領域そのものなどゲーム空間内に固定又は移動しているプレーヤキャラクタを特定するための領域である。
入力受付処理部213は、入力受付領域へのプレーヤの操作入力に基づく入力指示を受け付けるとともに、受け付けた入力指示をゲーム制御部214に出力する。
特に、入力受付処理部213は、入力受付領域への入力指示として、プレーヤの操作対象となるキャラクタに対する特定制御を行う特定コマンドを実行するための指示、及び、プレーヤの操作対象となる複数のキャラクタの中から1のキャラクタを特定するための指示を受け付ける。
ゲーム制御部214は、入力受付処理部213によって受け付けたコマンドと、当該コマンドを受け付けた際のタッチ操作入力に継続して入力されたスライド操作入力と、コマンドに基づくゲーム処理を実行する。
特に、ゲーム制御部214は、入力受付処理部213によって受け付けたコマンド(すなわち、入力指示)の操作対象となるキャラクタ(すなわち、プレーヤキャラクタ)に対する制御、又は、敵キャラクタやその他の付随するキャラクタに対する制御を実行する。
例えば、ゲーム制御部214は、対戦ゲームやシューティングゲームの場合には、敵キャラクタに対する攻撃、味方キャラクタに対する能力回復などのサポートなどの所定の処理を実行する。また、ゲーム制御部214は、シミュレーションゲームの場合には、作物の作成や建物建築などの所定の作業を実行する。
また、例えば、本実施形態のゲーム制御部214は、入力受付処理部213と連動してスライド操作入力を受け付け、敵キャラクタを攻撃対象に設定(ロックオン)する処理を実行する。
一方、ゲーム制御部214は、オブジェクト空間内における移動体オブジェクト(特に、プレーヤキャラクタや敵キャラクタなどのキャラクタオブジェクト)等の操作対象のキャラクタオブジェクトの移動演算を行う。
すなわち、ゲーム制御部214は、入力部260によりプレーヤが入力した入力データ又はプログラム(移動アルゴリズム)や各種データ(モーションデータ)などに基づいて、移動体オブジェクトをオブジェクト空間内で移動させ、又は、移動体オブジェクトの動作(モーション、アニメーション)を制御するための処理を行う。
具体的には、ゲーム制御部214は、オブジェクトの移動情報(移動方向、移動量、移動速度、位置、回転角度、或いは加速度)や動作情報(各パーツオブジェクトの位置、或いは回転角度)を、1フレーム毎に順次求めるシミュレーション処理を行う。ここでフレームとは、オブジェクトの移動処理、動作処理(シミュレーション処理)や画像生成処理を行う時間の単位である。そして、本実施形態では、フレームレートは、固定としてもよいし、処理負荷に応じて可変としてもよい。
なお、ゲーム制御部214は、3次元のオブジェクト空間において入力方向に基づいてオブジェクトを移動させる処理を行ってもよい。例えば、予め、入力方向毎に移動方向を対応づけ、入力方向に対応する移動方向にオブジェクトを移動させる。
また、ゲーム制御部214は、サーバ装置10と連動して実行してもよいし、その一部又は全部がサーバ装置10に形成されていてもよい。
ゲーム演算部215は、種々のゲーム演算処理を行う。特に、ゲーム演算部215は、プレーヤの指示に基づいてゲームに使用される複数のプレーヤキャラクタをデッキとして設定する場合には、当該デッキに設定された各プレーヤキャラクタを用いてゲームを進行させるための各処理を実行する。
また、ゲーム演算部215は、シューティングゲームの予め定められたオブジェクト空間の形成、マップに基づくオブジェクト空間の形成、ユーザの操作に応じて予め設定されたシナリオに基づくゲームの進行、プレーヤオブジェクト(操作対象オブジェクト)と敵オブジェクトやその他のオブジェクト(操作非対象オブジェクト)との対戦、及び、当該対戦時のパラメータ管理などのゲームを実行する上で必要な演算処理を行う。
ゲーム演算部215は、スライド操作入力に応じて変動パラメータを管理するとともに、その結果を表示制御部212と連動してタッチパネル12上にゲージとして表示させる。
なお、ゲーム演算部215は、サーバ装置10と連動して実行するが、その一部又は全部の機能はサーバ装置10に搭載されていてもよい。
仮想カメラ制御部216は、所与の視点から見える画像であって、奥行きがあるように見える画像を生成する。この場合に、仮想カメラ制御部216が、オブジェクト空間内の所与(任意)の視点から見える画像を生成するための仮想カメラ(視点)の制御処理を行う。具体的には、仮想カメラの位置(X、Y、Z)又は回転角度(X、Y、Z軸回りでの回転角度)を制御する処理(視点位置や視線方向を制御する処理)を行う。
例えば、仮想カメラによりオブジェクト(例えば、キャラクタ、ボール、車)を後方から撮影する場合には、オブジェクトの位置又は回転の変化に仮想カメラが追従するように、仮想カメラの位置又は回転角度(仮想カメラの向き)を制御する。
この場合には、ゲーム制御部214で得られたオブジェクトの位置、回転角度又は速度などの情報に基づいて、仮想カメラを制御できる。或いは、仮想カメラを、予め決められた回転角度で回転させたり、予め決められた移動経路で移動させる制御を行ってもよい。また、この場合には、仮想カメラの位置(移動経路)又は回転角度を特定するための仮想カメラデータに基づいて仮想カメラを制御する。
なお、仮想カメラ(視点)が複数存在する場合には、それぞれの仮想カメラについて上記の制御処理が行われる。
ゲーム管理部217は、入力部260を介して入力されたプレーヤの操作に基づいて、各プレーヤにおいて対戦ゲーム等のゲームに使用するプレーヤキャラクタ及び各種のアイテムを設定し、ユーザ情報273に登録する。
特に、ゲーム管理部217は、デッキを用いてゲームを実行する場合には、設定されたプレーヤキャラクタ及び各種のアイテムをデッキデータとしてユーザ情報273に登録する。
描画部220は、処理部200で行われる種々の処理(ゲーム処理)の結果に基づいて
描画処理を行い、これにより画像を生成し、表示部290に出力する。描画部220が生成する画像は、いわゆる2次元画像であってもよいし、いわゆる3次元画像であってもよい。特に、描画部220は、オブジェクト空間における仮想カメラから見える画像であって、画面上に表示する画像を生成する。
ここで2次元画像を生成する場合には、描画部220は、設定された優先度が低いオブジェクトから順に描画して、オブジェクト同士が重なる場合には、優先度の高いオブジェクトを上書きして描画する。
また、3次元画像を生成する場合には、本実施形態の描画部220は、まずオブジェクト(モデル)の各頂点の頂点データ(頂点の位置座標、テクスチャ座標、色データ、法線ベクトル或いはα値等)を含むオブジェクトデータ(モデルデータ)が入力され、入力されたオブジェクトデータに含まれる頂点データに基づいて、頂点処理が行われる。なお、頂点処理を行うに際して、必要に応じてポリゴンを再分割するための頂点生成処理(テッセレーション、曲面分割、ポリゴン分割)を行うようにしてもよい。
また、頂点処理では、頂点の移動処理や、座標変換(ワールド座標変換、カメラ座標変換)、クリッピング処理、透視変換、あるいは光源処理等のジオメトリ処理が行われ、その処理結果に基づいて、オブジェクトを構成する頂点群について与えられた頂点データを変更(更新、調整)する。そして、頂点処理後の頂点データに基づいてラスタライズ(走査変換)が行われ、ポリゴン(プリミティブ)の面とピクセルとが対応づけられる。そしてラスタライズに続いて、画像を構成するピクセル(表示画面を構成するフラグメント)を描画するピクセル処理(フラグメント処理)が行われる。
ピクセル処理では、テクスチャの読出し(テクスチャマッピング)、色データの設定/変更、半透明合成、アンチエイリアス等の各種処理を行って、画像を構成するピクセルの最終的な描画色を決定し、透視変換されたオブジェクトの描画色を画像バッファ272(フレームバッファ、ピクセル単位で画像情報を記憶できるバッファ。VRAM、レンダリングターゲット)に出力(描画)する。すなわち、ピクセル処理では、画像情報(色、法線、輝度、α値等)をピクセル単位で設定あるいは変更するパーピクセル処理を行う。
これにより、オブジェクト空間内に設定された仮想カメラ(所与の視点)から見える画像が生成される。なお、仮想カメラ(視点)が複数存在する場合には、それぞれの仮想カメラから見える画像を分割画像として1画面に表示できるように画像を生成することができる。
なお、描画部220が行う頂点処理やピクセル処理は、シェーディング言語によって記述されたシェーダプログラムによって、ポリゴン(プリミティブ)の描画処理をプログラム可能にするハードウェア、いわゆるプログラマブルシェーダ(頂点シェーダやピクセルシェーダ)により実現されてもよい。プログラマブルシェーダでは、頂点単位の処理やピクセル単位の処理がプログラム可能になることで描画処理内容の自由度が高く、ハードウェアによる固定的な描画処理に比べて表現力を大幅に向上させることができる。
そして、描画部220は、オブジェクトを描画する際に、ジオメトリ処理、テクスチャマッピング、隠面消去処理、αブレンディング等を行う。
ジオメトリ処理では、オブジェクトに対して、座標変換、クリッピング処理、透視投影変換、或いは光源計算等の処理を行う。そして、ジオメトリ処理後(透視投影変換後)のオブジェクトデータ(オブジェクトの頂点の位置座標、テクスチャ座標、色データ(輝度データ)、法線ベクトル、或いはα値等)を記憶部270に記憶する。
テクスチャマッピングでは、記憶部270のテクスチャ記憶部に記憶されるテクスチャ(テクセル値)をオブジェクトにマッピングする処理を行う。具体的には、オブジェクトの頂点に設定(付与)されるテクスチャ座標等を用いて記憶部270のテクスチャ記憶部からテクスチャ(色(RGB)、α値などの表面プロパティ)を読み出し、2次元の画像であるテクスチャをオブジェクトにマッピングする。この場合に、ピクセルとテクセルとを対応づける処理や、テクセルの補間としてバイリニア補間などを行う。
なお、本実施形態では、オブジェクトを描画する際に、所与のテクスチャをマッピングする処理を行うようにしてもよい。この場合には、マッピングされるテクスチャの色分布(テクセルパターン)を動的に変化させることができる。
また、この場合において、色分布(ピクセルパターン)が異なるテクスチャを動的に生成してもよいし、複数の色分布が異なるテクスチャを予め用意しておき、使用するテクスチャを動的に切り替えるようにしてもよい。またオブジェクト単位でテクスチャの色分布を変化させてもよい。
隠面消去処理では、描画ピクセルのZ値(奥行き情報)が格納されるZバッファ(奥行きバッファ)を用いたZバッファ法(奥行き比較法、Zテスト)による隠面消去処理を行う。すなわち、オブジェクトのプリミティブに対応する描画ピクセルを描画する際に、Zバッファに格納されるZ値を参照するとともに、当該参照されたZバッファのZ値と、プリミティブの描画ピクセルでのZ値とを比較し、描画ピクセルでのZ値が、仮想カメラから見て手前側となるZ値(例えば小さなZ値)である場合には、その描画ピクセルの描画処理を行うとともにZバッファのZ値を新たなZ値に更新する。
αブレンディング(α合成)では、描画部220は、α値(A値)に基づく半透明合成処理(通常αブレンディング、加算αブレンディング又は減算αブレンディング等)を行う。なお、α値は、各ピクセル(テクセル、ドット)に関連づけて記憶できる情報であり、例えば色情報以外のプラスアルファの情報である。α値は、マスク情報、半透明度(透明度、不透明度と等価)、バンプ情報などとして使用できる。
音処理部230は、処理部200で行われる種々の処理の結果に基づいて音処理を行い、BGM、効果音、又は音声などのゲーム音を生成し、音出力部292に出力する。
なお、本実施形態の端末装置は、1人のプレーヤのみがプレーできるシングルプレーヤモード専用のシステムにしてもよいし、複数のプレーヤがプレーできるマルチプレーヤモードも備えるシステムにしてもよい。
また、複数のプレーヤがプレーする場合に、これらの複数のプレーヤに提供するゲーム画像やゲーム音を、1つの端末装置20を用いて生成してもよいし、ネットワーク(伝送ライン、通信回線)などで接続された複数の端末装置20又はサーバ装置10を用いて分散処理により生成してもよい。
4.本実施形態の手法
4−1.ゲームの概要
本実施形態の端末装置20は、ゲーム用の画面(以下、「ゲーム画面」と称す。所与の画面の一例)に現れる敵キャラクタ(オブジェクトの一例)へ攻撃を与えるゲーム処理を実行する。このゲーム処理は、シューティングゲーム、RPGにおける対戦パート、シミュレーションゲームなどへの適用が可能である。なお、ここでは、当該ゲーム処理をシングルプレーモードのシューティングゲームへ適用した例を説明する。
ユーザは、ゲーム画面へのスライド操作入力によって複数の敵キャラクタを連続して攻撃対象(処理対象の一例)に設定(以下、「ロックオン」という。)し、その後、所定のアクションをすることにより、ロックオンされた敵キャラクタを攻撃する。
ここで、本実施形態の端末装置20は、敵キャラクタがロックされてからの経過時間(後述する時間のカウント値)が制限時間(後述する制限値)に達するまでの時間をカウントダウンし、制限時間に達するとロックオンを解除し始める。したがって、ユーザは、多くの敵を攻撃してハイスコアを得るために、スライド操作を如何にして効率的に行うかが重要となる。
4−2.ゲーム画面の例
図5は、ゲーム画面の一例である。ここでは、ユーザの指によるタッチパネル12への直接的なスライド操作を想定する。
図5に示すとおり、ゲーム画面には、例えば上端側から順に、ゲームスコア900の表示領域と、ユーザの攻撃力を示すゲージ1000の表示領域と、オブジェクト空間1500の表示領域と、ロックが解除され始めるまでの残り時間を示すゲージ2000の表示領域とが配置される。
オブジェクト空間1500には、表示制御部212によって複数種類の敵キャラクタが表示される(なお、表示制御部212の処理は、主にゲーム制御部214によって制御される。以下も同様。)。ここでは、図5に示すとおり属性の異なる3種類の敵キャラクタCAA、CAB、CACがゲーム画面に複数ずつ同時に出現する場合を想定する。これらの敵キャラクタCAA、CAB、CACの各々の見た目のサイズは、例えば一般的な指先の幅より大きく設定される。
このとき、表示制御部212は、例えば、ゲーム画面に出現中の敵キャラクタCAA、CAB、CACの一部又は全部を揺動させることにより、ユーザが敵キャラクタにタッチしにくい状況、すなわち、敵キャラクタをロックオンしにくい状況を作り出すことができる。敵キャラクタの「揺動」とは、例えば、ゲーム画面上の或る位置座標を中心として敵キャラクタの位置座標が1方向又は複数方向にかけて振動する状態のことを言う。
因みに、図5では、防御力の最も高い敵キャラクタCACが揺動する状態を、二重の部分円弧によって表わした。また、ここでは図9に示すとおり敵キャラクタCAAの属性「A」の防御力を「低」とし、敵キャラクタCABの属性「B」の防御力を「中」、敵キャラクタCACの「属性C」の防御力を「高」と仮定した(以下、同様。)。
なお、ゲーム画面に出現する敵キャラクタCAA、CAB、CACの位置の制御方法については、ここで説明したものに限定されることはなく、各種の方法を適用することができる。敵キャラクタの位置の制御方法として適用可能な幾つかの例については後述する。
4−3.ロックオン
ユーザは、ロックオンしたい複数の敵キャラクタを、例えば図6に太い曲線で示すとおりゲーム画面から指先を離さずに連続してタッチ操作する。ここでは、ユーザがゲーム画面から指先を離さずに複数の敵キャラクタを連続してタッチ操作をすることを、適宜、「敵キャラクタのスライド操作」、「敵キャラクタをスライド操作する」などと表現し、ゲーム画面におけるスライド操作中のタッチ位置の軌跡を適宜、「スライド軌跡」又は「軌跡」と称す。
ここで、ゲーム画面におけるタッチ位置は、タッチ検出処理部211によって定期的に検出される。ここでは、タッチ検出処理部211によるタッチ位置の検出周期を、フレーム周期と同じと仮定する。この場合、ユーザがスライド操作を行うと、ゲーム画面の連続するフレームから連続してタッチ位置が検出され、ユーザがスライド操作を終了(スライド操作後にタッチ操作を解除)すると、ゲーム画面のフレームからタッチ位置が検出されない。
さて、ユーザがゲーム画面上の複数の敵キャラクタをスライド操作すると、当該複数の敵キャラクタのうち、当該スライド操作の軌跡に対して所定の関係を満たした1又は複数の敵キャラクタがロックオンされる。ここでは、特に、軌跡上に存在する敵キャラクタと、軌跡からの距離が所定範囲内に収まっている敵キャラクタとがロックオンされることとする。
例えば、入力受付処理部213は、敵キャラクタの位置座標を中心とした所定サイズのエリア(以下、「ロック可能エリア」と称す。)をゲーム画面上に設定し、ロック可能エリアの輪郭にスライド軌跡の少なくとも一部が交差(所与の条件の一例)した場合に、当該敵キャラクタのロックオン指示を受け付け、そうでない場合に、当該敵キャラクタのロックオン指示を受け付けない(なお、入力受付処理部213の処理は、主にゲーム制御部214によって制御される。以下も同様。)。
そして、入力受付処理部213が敵キャラクタのロックオン指示を受け付けると、ゲーム演算部215(設定部の一例、解除部の一例、設定部の一例)は、後述するロックオンテーブル(図11)へ当該敵キャラクタを登録することにより、当該キャラクタを攻撃処理(処理の一例)の対象に設定(ロックオン)する(なお、ゲーム演算部215の処理は、主にゲーム制御部214によって制御される。以下も同様。)。
図7(A)に示す例では、敵キャラクタCAAのロック可能エリアAAの輪郭はスライド軌跡Qに交差しているので、当該敵キャラクタCAAはロックオンされる。また、敵キャラクタCABのロック可能エリアABの輪郭もスライド軌跡Qに交差しているので、当該敵キャラクタCABはロックオンされる。一方、敵キャラクタCACのロック可能エリアACの輪郭はスライド軌跡Qに交差していないので、当該敵キャラクタCACはロックオンされない。なお、ロック可能エリアAA、AB、ACは、ロックオン指示を受付けるか否かの基準として用いられるものであるので、ゲーム画面への表示は必須ではない。
また、入力受付処理部213は、以上のようなスライド操作入力(ロックオン指示)を受け付けるか否かの判定に当たり、スライド軌跡Qを算出する処理を行う。スライド軌跡Qの算出は、例えば以下の算出処理(1),(2)の何れかをゲーム画面の各フレームについて実行することにより行われる。
(1)入力受付処理部213は、先行フレームからタッチ検出処理部211が検出したタッチ位置の座標である第1の座標と、現フレームからタッチ検出処理部211が検出したタッチ位置の座標である第2の座標とを参照し、第1の座標と第2の座標とを結ぶ線分を、先行フレームから現フレームまでの期間に行われたスライド操作の軌跡として算出する。ここで「現フレーム」とは、ゲーム画面の最新フレームのことであり、「先行フレーム」とは、現フレームより1つ前のフレームのことである。
(2)入力受付処理部213は、最新の3以上のフレームの各々からタッチ検出処理部211が検出したタッチ位置の座標を参照する。そして、入力受付処理部213は、これら3以上のタッチ位置の座標を検出順に通る曲線を所定の補間処理によって算出し、当該曲線のうち、先行フレームから現フレームまでの区間に相当する部分曲線を、先行フレー
ムから現フレームまでの期間に行われたスライド操作の軌跡とする。なお、所定の補間処理としては、位置のサンプルから軌跡を算出する各種の補間処理(例えばスプライン補間など)を適用することが可能である。
また、入力受付処理部213は、図7(A)に示すとおり、敵キャラクタCAAのロック可能エリアAAのサイズと、敵キャラクタCABのロック可能エリアABのサイズと、敵キャラクタCACのロック可能エリアACのサイズとの間に差を設けることもできる。
例えば、入力受付処理部213は、ロック可能エリアのサイズに防御力を反映させる。具体的には、入力受付処理部213は、特性テーブル(図9)において防御力が高く設定されている敵キャラクタほど、ロック可能エリアを狭く設定する。これによって、防御力の高い敵キャラクタほどロックオンし難いという状況が作り出される。なお、図7(A)では、ロック可能エリアのサイズを敵キャラクタのサイズと同等以上としたが、敵キャラクタのサイズより小さく設定することも可能である。
そして、表示制御部212は、図7(B)に示すとおり、ロックオンされた敵キャラクタCAA、CABをゲーム画面上で強調表示する。図7(B)に示す例では、ロックオンされた敵キャラクタCAA、CABの各々にロックオンカーソルLOC(マークの一例)が付与された例を示している。因みに、図7(B)に示す例では、概略輪帯状のロックオンカーソルLOCが敵キャラクタCAA、CABの各々に付与されている(敵キャラクタに対するロックオンカーソルの付与は、設定中のオブジェクトを強調表示する態様の一例である)。なお、ロックオンされた敵キャラクタの強調方法は、これに限定されることはなく、他の強調方法(後述)を適用することもできる。
4−4.ロック解除
上記のロックオンが維持される時間には、制限が設けられる。よって、ユーザは、多くの敵キャラクタを攻撃するために、なるべく短い時間内になるべく多くの敵キャラクタをスライド操作する必要がある。この状況を作り出すために、ゲーム演算部215は、例えば以下の処理を実行する。
先ず、ゲーム演算部215は、敵キャラクタをロックオンテーブル(図11)に登録する度に、当該敵キャラクタが登録された時点を起点としたスライド操作の時間の計測を開始する。この時間の長さ(時間のカウント値)は、計測値の一例であって、敵キャラクタごとに算出され、また、定期的に(例えばフレーム周期で)更新される。時間のカウント値の詳細は、後述する。
そして、ゲーム演算部215は、ロックオンテーブル(図11)に登録されている1又は複数の敵キャラクタ(ロックオンされている1又は複数の敵キャラクタ)のうち、時間のカウント値が制限値(ここでは10秒とする。)に達した敵キャラクタを、ロックオンテーブル(図11)から削除することで、当該敵キャラクタのロックを解除(ロックオフ)する。敵キャラクタのロックが解除されると、表示制御部212は、当該敵キャラクタに付与されていたロックオンカーソルLOCをゲーム画面から消去する。
また、ゲーム演算部215は、制限値(ここでは10秒)から時間のカウント値を減算することにより、ロックが解除されるまでの残り時間(以下、「残りカウント値」と称す。残り計測値の一例。)を算出する。また、ゲーム演算部215は、この残りカウント値の算出を、ロックオンテーブル(図11)に登録された敵キャラクタごとに行う。そして、表示制御部212は、個々の敵キャラクタの残りカウント値に応じて、個々の敵キャラクタのロックオンカーソルの表示態様(例えば、表示サイズ、表示色、表示輝度、時間変化パターンの組み合わせ)を変化させる。
図7(C)に示す例では、残りカウント値に応じてロックオンカーソルLOCの表示態様(例えば、表示サイズ、表示色、表示輝度、時間変化パターンの組み合わせ)が変化する状態(調整されている状態)を示している。特に、図7(C)の例では、敵キャラクタCAAの残りカウント値が小さくなり、敵キャラクタCAAに付与されたロックオンカーソルLOCの表示サイズが小さくなり、かつ、ロックオンカーソルLOCが点滅し始めた状態を示している。したがって、ユーザは、個々の敵キャラクタに付与されたロックオンカーソルの表示態様により、個々の敵キャラクタのロックが解除されるまでのおおよその残り時間を把握することができる。
なお、表示制御部212は、ロックオンテーブル(図11)に登録されている敵キャラクタのうち、登録順序(ロックオン番号)が最上位である敵キャラクタ(最も早期にロックオンされた敵キャラクタ)の残りカウント値を、ゲーム画面上のゲージ2000へ反映することもできる。この場合、ユーザは、敵キャラクタのロックが解除され始めるまでの残り時間を、ゲージ2000によって把握することができる。
4−5.攻撃トリガーの例
ユーザが所定のアクションをすると、そのタイミングでロックオンされている全ての敵キャラクタに対して攻撃が加えられる。この攻撃のトリガーとなる所定のアクションは、「スライド操作後にタッチ操作を解除してから、更に所定の攻撃ボタン(不図示)をタッチ操作すること」などとすることができる。但し、ここでは、最もシンプルなアクションである「スライド操作後にタッチ操作を解除すること」を攻撃のトリガーとして用いることとする。
なお、ユーザがスライド操作後にタッチ操作を解除すると、連続するフレームからタッチ検出処理部211が連続してタッチ位置を検出する状態から、タッチ検出処理部211がタッチ位置を検出しない状態へと移行する。そこで、ゲーム演算部215は、連続するフレームから連続してタッチ位置が検出される状態からタッチ位置が検出されない状態へと移行したタイミングで、ロックオンテーブル(図11)に登録されている敵キャラクタを対象とした以下の攻撃処理(処理の一例)を実行する。
4−6.攻撃処理
攻撃処理は、ゲーム演算部215によって例えば次のとおり実行される。すなわち、ゲーム演算部215は、ロックオンテーブル(図11)に登録されている1又は複数の敵キャラクタ(ロックオンされている1又は複数の敵キャラクタ)の各々の体力値(HP)を、ステータステーブル(図10)に基づき認識し、当該敵キャラクタの体力値(HP)から、所定の攻撃力パラメータ(処理のパラメータの一例)に応じた値を減算し、ステータステーブル(図10)における体力値(HP)を、減算後の値に更新する。なお、所定の攻撃力パラメータは、例えば、攻撃処理に先立ち予め設定される。
4−6−1.ロングスライド攻撃
本実施形態のユーザは、図8に示すとおり、最後にロックオンした敵キャラクタの位置座標P1からタッチ操作を解除する位置座標P2まで余剰なスライド操作(敵キャラクタの存在しない領域におけるスライド操作)を行うことで、敵キャラクタへダメージを与えることができ、しかも、余剰なスライド操作の軌跡の長さ(余剰距離)を大きくするほどダメージが大きくなるものとする。
この場合、余剰距離が大きいほど敵キャラクタをロックできるチャンスは減ってロックが解除されるリスクも高まるので、ユーザには、いかなるタイミングで余剰なスライド操作を始め、いかなるタイミングで余剰なスライド操作を終えるべきかの判断が求められる
。そのために、ゲーム演算部215は、例えば以下の処理を実行する。
先ず、ゲーム演算部215は、敵キャラクタをロックオンテーブル(図11)に登録する度に、その時点における当該敵キャラクタの位置を起点としたスライド操作の距離(軌跡の長さ)の計測を開始する。この距離の長さ(距離のカウント値)は、計測値の一例であって、敵キャラクタごとにロックオンテーブル(図11)に書き込まれ、また、定期的に(例えばフレーム周期で)更新される。距離のカウント値の詳細は、後述する。
そして、ゲーム演算部215は、ロックオンテーブル(図11)を適宜に参照し、ロックオンテーブル(図11)に登録されている1又は複数の敵キャラクタ(ロックオンされている1又は複数の敵キャラクタ)のうち、ロックオン番号が最下位である敵キャラクタ(最後にロックオンされた敵キャラクタ)の距離のカウント値が大きいときほど、攻撃力パラメータを大きな値に設定する。
なお、ゲーム演算部215によって設定された攻撃力パラメータの値は、表示制御部212によってゲーム画面のゲージ1000へ逐次に反映される。また、攻撃力パラメータの決定方法は、ここで説明したものに限定されることはない。決定方法の他の例については、後述する。
4−6−2.コンボ攻撃
また、本実施形態のユーザは、スライド操作を行い、属性の共通する敵キャラクタが連続してロックオンされるようなスライド軌跡を描くことで、敵キャラクタへ与えるダメージ(ゲーム処理の効果の一例)を大きくすることができる。そのために、ゲーム演算部215は、例えば以下の処理を実行する。
先ず、ゲーム演算部215は、敵キャラクタをロックオンテーブル(図11)に登録する度に、当該敵キャラクタの属性が直前に登録された敵キャラクタの属性と共通するか否かを判別し、共通する場合には当該敵キャラクタの連続フラグ(図11)をオンする。
そして、ゲーム演算部215は、ロックオンテーブル(図11)を適宜に参照し、ロックオンテーブル(図11)においてオンされている連続フラグ(図11)の個数が大きいときほど、攻撃力パラメータを大きな値に設定する。
なお、ゲーム演算部215によって設定された攻撃力パラメータの値は、表示制御部212によってゲーム画面のゲージ1000へ逐次に反映される。また、攻撃力パラメータの決定方法は、ここで説明したものに限定されることはない。決定方法の他の例については、後述する。
4−7.攻撃後処理の概要
攻撃処理の後、ゲーム演算部215及び表示制御部212は、例えば以下の処理を実行する。
ゲーム演算部215は、体力値(HP)がゼロとなった敵キャラクタをステータステーブル(図10)から削除することにより、ステータステーブル(図10)を更新する。また、ゲーム演算部215は、ロックオンテーブル(図11)から全ての敵キャラクタを削除(登録抹消)することにより、ロックオンテーブル(図11)をリセットする。また、ゲーム演算部215は、体力値(HP)がゼロとなった敵キャラクタの属性及び個数に応じた点数を、ユーザ情報273に保管されているスコアへ加算する。なお、ゲーム演算部215は、体力値(HP)がゼロとなった敵キャラクタのレア度(出現頻度の低さ)が高いほど、スコアに加算すべき点数を大きく設定してもよい。
表示制御部212は、敵キャラクタのうち体力値(HP)がゼロとなったものをゲーム画面から消去し、攻撃対象となった全ての敵キャラクタのロックオンカーソルをゲーム画面から消去し、また、上記の点数をゲーム画面上のスコア900へ加算することにより、ゲーム画面を新規のゲーム画面に更新する。新規のゲーム画面は、ユーザによる新規のスライド操作入力が可能なゲーム画面である。また、表示制御部212は、攻撃の状態等を表す画面(攻撃画面)を所定期間に亘って表示し、攻撃画面の内容を、攻撃対象となった敵キャラクタの個数と、攻撃力パラメータとの組み合わせなどに応じて変化させることもできる。
4−8.ロックオン数による時間ボーナス
本実施形態では、ゲーム性を高めるため、同時にロックオンされている敵キャラクタの個数が目標数(ここでは30個とする。)に達した場合に、ユーザへ特典(ボーナス)が付与される(目標数に達することは、所与の条件の一例である。)。
例えば、ゲーム演算部215は、ロックオンテーブル(図11)を適宜に参照し、ロックオンテーブル(図11)に登録されている敵キャラクタのロックオン番号の最大値が目標数(ここでは30個)に達した場合に、ロックオンテーブル(図11)のボーナスフラグをオンする。
そして、ゲーム演算部215は、ロックオンテーブル(図11)を適宜に参照し、ロックオンテーブル(図11)のボーナスフラグがオンされていた場合には、敵キャラクタのロックが解除されるまでの残り時間を延長するというボーナスをユーザへ付与する。
したがって、ユーザがなるべく多くの敵キャラクタをスライド操作してロックオンすればボーナスを獲得できる可能性が高まるが、スライド操作の時間が長くなって敵キャラクタのロックが解除される可能性も高まる、というトレードオフの関係が作り出される。
因みに、残り時間を延長するための処理としては、例えば以下の処理(1)〜(5)の何れかを採用することができる。
(1)ゲーム演算部215は、ロックオンテーブル(図11)に登録されている1又は複数の敵キャラクタの全ての時間のカウント値から一律に所定値(例えば10秒)を減算する。この処理(1)によると、ロックされている全ての敵キャラクタの残り時間をそれぞれ同じ時間ずつ延長することができる。
(2)ゲーム演算部215は、ロックオンテーブル(図11)に登録されている1又は複数の敵キャラクタの全ての時間のカウント値をゼロにリセットする。この処理(2)によると、ロックされている全ての敵キャラクタの残り時間を、最後にロックされた敵キャラクタの残り時間(最も長い残り時間)に近づけることができる。
(3)ゲーム演算部215は、ロックオンテーブル(図11)に登録されている1又は複数の敵キャラクタの全ての時間のカウント値をマイナスの所定値にリセットする。この処理(3)によると、処理(2)よりも更に延長時間を長くすることができる。
(4)ゲーム演算部215は、ロックオンテーブル(図11)に登録されている1又は複数の敵キャラクタの全ての時間のカウント値へ1未満の所定値を乗算する。この処理(4)によると、ロックされている全ての敵キャラクタの残り時間をそれぞれ同じ割合で延長することができる。
(5)ゲーム演算部215は、時間のカウント値の上限を規定するための制限値を(10秒以上の値に)増大させる。この処理(5)によると、当該制限値を元の値(10秒)に戻さない限りは、残り時間の延長というユーザへのボーナスを継続させることができる。
なお、ゲーム演算部215は、以上の処理(1)〜(5)を使い分けてもよい。例えば、ゲーム演算部215は、ユーザの設定、ゲームの進捗度などに応じて以上の処理(1)〜(5)使い分けてもよいし、以上の処理(1)〜(5)をランダムに使い分けてもよい。また、ここでは、ゲーム演算部215は、残り時間の延長対象となる敵キャラクタを、ロックオンテーブル(図11)に登録されている全ての敵キャラクタとするが、一部の敵キャラクタ(特定の敵キャラクタ)とすることも可能である。
4−9.特殊キャラクタロックによる時間ボーナス
また、本実施形態では、ゲーム性を高めるため、特殊なキャラクタ(ここでは、防御力最高の敵キャラクタとする。)がロックオンされた場合に、ユーザへ特典(ボーナス)が付与される(特殊なキャラクタは、特定のオブジェクトの一例である。)。
例えば、ゲーム演算部215は、ロックオンテーブル(図11)へ敵キャラクタを登録する際に、当該敵キャラクタの属性が特殊な属性(ここでは防御力が最高の属性)であるか否かを判定し、特殊な属性であった場合に、ロックオンテーブル(図11)のボーナスフラグをオンする。
そして、ゲーム演算部215は、ロックオンテーブル(図11)を適宜に参照し、ロックオンテーブル(図11)のボーナスフラグがオンされていた場合には、敵キャラクタのロックが解除されるまでの残り時間を延長するというボーナスをユーザへ付与する。
したがって、ユーザが特殊な敵キャラクタをスライド操作で追いかけてロックオンすればボーナスを獲得できる可能性が高まるが、スライド操作に時間が長くなって敵キャラクタのロックが解除される可能性も高まる、というトレードオフの関係が作り出される。
因みに、残り時間を延長するための処理としては、例えば上記の処理(1)〜(5)の何れかを採用することができる。
なお、ゲーム演算部215は、以上の処理(1)〜(5)を使い分けてもよい。例えば、ゲーム演算部215は、ユーザの設定、ゲームの進捗度などに応じて以上の処理(1)〜(5)使い分けてもよいし、以上の処理(1)〜(5)をランダムに使い分けてもよい。また、ここでは、ゲーム演算部215は、残り時間の延長対象となる敵キャラクタを、ロックオンテーブル(図11)に登録されている全ての敵キャラクタとするが、一部の敵キャラクタ(特定の敵キャラクタ)とすることも可能である。
5.実施形態の動作
5−1.テーブル
以上の各処理を実行するために、端末装置20のゲームデータ記憶部274は、特性テーブル(図9)、ステータステーブル(図10)、ロックオンテーブル(図11)を記憶する。特性テーブル(図9)、ステータステーブル(図10)、ロックオンテーブル(図11)は、基本的にゲーム演算部215によって管理される。
図9に示す特性テーブルは、ゲーム画面に出現する複数種類(ここでは3種類とする。)の敵キャラクタCAA、CAB、CACの各々の特性を表す。ここでは、敵キャラクタの特性として「防御力」を想定し、防御力の高さを「低」、「中」、「高」の三段階で表
し、敵キャラクタCAAの属性を「A」、敵キャラクタCABの属性を「B」、敵キャラクタCACの属性を「C」で表す。図9に示すとおり、特性テーブルは、属性「A」に防御力「低」を対応付け、属性「B」に防御力「中」を対応付け、属性「C」に防御力「高」を対応付けて記憶している。
図10に示すステータステーブルは、ゲーム画面に出現中の個々の敵キャラクタのステータスを表す。図10に示すとおり、ステータステーブルは、出現中の敵キャラクタの各々の属性、位置座標、体力値(HP)を、当該敵キャラクタのキャラクタIDに対応付けて記憶している。なお、ステータステーブルは、ゲーム演算部215によって例えばフレーム周期で更新される。
図11に示すロックオンテーブルには、スライド操作入力によりロックオンされた1又は複数の敵キャラクタが登録される。図11に示すとおり、登録された個々の敵キャラクタの情報には、登録順序(ロックオン番号)、キャラクタID、属性、時間のカウント値、距離のカウント値、及び連続フラグが含まれる。但し、ロックオン番号の情報、属性の情報がロックオンテーブルに記録されることは必須ではない。なぜなら、カウント値の小さい敵キャラクタほどロックオン番号が小さいという関係が常に成り立ち、また、キャラクタIDと属性との対応関係は、特性テーブルにも記録されているからである。なお、時間のカウント値、距離のカウント値の説明は後述する。
ロックオンテーブルにおける或る敵キャラクタの連続フラグは、当該敵キャラクタの属性と、当該敵キャラクタよりロックオン番号が1だけ小さい敵キャラクタ(直前にロックオンされた敵キャラクタ)の属性とが共通であった場合に、ゲーム演算部215によってオンされる。この連続フラグの設定は、例えば当該敵キャラクタが登録されたタイミングで行われる。
また、図11の最右列に示すとおり、ロックオンテーブルは、ボーナスフラグを保持している。ボーナスフラグは、ユーザへ特典(ボーナス)を付与するタイミングが到来したか否かを示すフラグであって、ロックオンテーブル(図11)に登録されている敵キャラクタのロックオン番号の最大値が目標数(ここでは30個)に達した場合、又は、ロックオンテーブル(図11)へ新規に登録された敵キャラクタの属性が特殊(ここでは防御力が最高の属性)であった場合に、ゲーム演算部215によってオンされる。
5−1−1.ロックオンテーブルにおける時間のカウント値
ロックオンテーブルにおける各敵キャラクタの時間のカウント値は、当該敵キャラクタがロックオンされた時点を起点としたスライド操作の時間を示す。この時間のカウント値は、ゲーム演算部215によって定期的に更新される。以下、時間のカウント値の更新周期を、ゲーム画面のフレーム周期と同じと仮定する。
例えば、ゲーム演算部215は、ロックオンテーブル(図11)に敵キャラクタを登録すると、登録したタイミングで、当該敵キャラクタの時間のカウント値の更新(計時)を開始する。そして、ゲーム演算部215は、フレームが更新される度に、1フレーム周期に相当する値を、ロックオンテーブル(図11)に登録された個々の敵キャラクタの時間のカウント値へ加算する。
5−1−2.ロックオンテーブルにおける距離のカウント値
ロックオンテーブルにおける或る敵キャラクタの距離のカウント値は、当該敵キャラクタがロックオンされた位置を起点としたスライド操作の距離(軌跡の長さ)を示す。この距離のカウント値は、ゲーム演算部215によって定期的に更新される。以下、距離のカウント値の更新周期を、ゲーム画面のフレーム周期と同じと仮定する。
例えば、ゲーム演算部215は、ロックオンテーブル(図11)に敵キャラクタを登録すると、登録したタイミングで、当該敵キャラクタの距離のカウント値の更新(測距)を開始する。そして、ゲーム演算部215は、フレームが更新される度に、先行フレームから現フレームまでに行われたスライド操作の軌跡の長さを算出し、当該長さを示す値を、ロックオンテーブル(図11)に登録された個々の敵キャラクタの距離のカウント値へ加算する。
なお、先行フレームから現フレームまでに行われたスライド操作の軌跡は、例えば入力受付処理部213による以下の処理(1)又は処理(2)によって算出される。
(1)入力受付処理部213は、先行フレームからタッチ検出処理部211が検出したタッチ位置の座標である第1の座標と、現フレームからタッチ検出処理部211が検出したタッチ位置の座標である第2の座標とを参照し、第1の座標と第2の座標とを結ぶ線分を、先行フレームから現フレームまでの期間に行われたスライド操作の軌跡として算出する。
(2)入力受付処理部213は、最新の3以上のフレームの各々からタッチ検出処理部211が検出したタッチ位置の座標を参照する。そして、入力受付処理部213は、これら3以上のタッチ位置の座標を検出順に通る曲線を所定の補間処理によって算出し、当該曲線のうち、先行フレームから現フレームまでの区間に相当する部分曲線を、先行フレームから現フレームまでの期間に行われたスライド操作の軌跡とする。なお、所定の補間処理としては、位置のサンプルから軌跡を算出する各種の補間処理(例えばスプライン補間など)を適用することが可能である。
6.実施形態のフロー
6−1.全体フロー
6−1−1.全体フローの概要
図12は、ゲーム中における端末装置20の処理の流れを示すフローチャートである。
本動作は、原則的には端末装置20において実行される処理である。ただし、一部の処理においては、サーバ装置10と連動することによって実行されることも可能である。
ゲーム開始当初、端末装置20は、初期のゲーム画面(初期画面)の表示処理を実行し、その後、所定のフレーム周期(例えば1/60秒)でゲーム画面のフレーム更新処理を繰り返し実行する(S11)。また、端末装置20は、フレーム更新処理(S11)を実行する度に、タッチ位置の検出処理(S12)を実行する。
ここで、ゲーム開始後、ユーザがスライド操作を開始する前の時点では、タッチ位置の検出処理(S12)においてタッチ位置が検出されることはないので(S13N)、ロックオンテーブルに敵キャラクタが登録されることもない(S29N)。
このため、ゲーム開始後、ユーザがスライド操作を開始する前の時点では、ゲーム終了条件が満たされない限り(S33N)、図12のS11、S12、S13N、S29N、S33Nを経てS11へ戻るというループがフレーム周期で繰り返される。
その後、ユーザがゲーム画面に対するスライド操作を開始すると、タッチ位置の検出処理(S12)においてタッチ位置が検出されるので(S13Y)、ロックオン判定処理(S15)、ボーナスフラグの判定処理(S17、S19、S21)、ロック解除判定処理(S23)、ゲージ更新処理(S25)という一連の処理がフレーム周期で繰り返される
。
ロックオン判定処理(S15)では、後述するとおり、ユーザが先行フレームから現フレームまでに行ったスライド操作の軌跡に対して所定の関係を満たす1又は複数の敵キャラクタが存在する場合に、当該1又は複数の敵キャラクタの全てがロックオンテーブルへ登録(ロックオン)される。
また、ボーナスフラグの判定処理(S17、S19、S21)では、後述するとおり、ロックオンテーブルのボーナスフラグに基づきユーザへボーナスを付与すべきタイミングが到来したか否が判定され、到来していた場合にユーザへボーナスを付与する処理(S19)が実行される。
また、ロック解除判定処理(S23)では、後述するとおり、ロックオンテーブルに登録されている敵キャラクタの中に、時間のカウント値が制限値(例えば10秒)に達したものが存在するか否かが判定され、存在した場合に当該敵キャラクタがロックオンテーブルから削除(ロックが解除)される。但し、初回のロック解除判定処理(S23)では、ロックオンテーブルに登録された敵キャラクタの時間のカウント値は全てゼロとなっているはずなので、ロックオンテーブルから敵キャラクタが削除(ロックが解除)されることはない。
また、ゲージ更新処理(S25)では、後述するとおり、後続フレームのゲージへ反映させるべきパラメータの計算処理が実行される。「後続フレーム」とは、現フレームの次のフレームのことであり、フレーム更新処理後のフレームのことである。
以上の一連の処理(S15〜S25)は、ユーザがスライド操作を継続している限り、繰り返され、その後、ユーザがタッチ操作を解除すると、タッチ位置の検出処理(S12)にてタッチ位置が検出されないので(S13N)、端末装置20は、攻撃の準備を開始する(S29)。
すなわち、端末装置20は、タッチ操作が解除された時点(S13N)でロックオンテーブルに登録されている敵キャラクタ(ロックオンされている敵キャラクタ)が存在するか否かの判定処理(S29)を実行し、存在する場合には(S29Y)、攻撃処理(S31)を実行する。
攻撃処理(S31)では、後述するとおり、ロックオンテーブルに登録されている敵キャラクタ(ロックオンされている敵キャラクタ)の体力値を減算する処理等が実行される。
したがって、ユーザがスライド操作後にタッチ操作を解除すると(S13N)、その時点でロックオンされている敵キャラクタが存在していたならば(S29Y)、ロックオンされている敵キャラクタへ攻撃処理が施され(S31)、ロックオンされている敵キャラクタが存在していなかったならば(S29N)、攻撃処理(S31)は実行されることはなく、ユーザが次にスライド操作を開始(S13Y)するまで一連の処理(S15〜S25)が休止される。
したがって、ユーザは、スライド操作により複数の敵キャラクタを連続的にロックオンし、スライド操作後にタッチ操作を解除するだけで、ロックオンした複数の敵キャラクタへ一斉に攻撃を与えることができる。
なお、図12のフローによると、仮に、ユーザが単一の敵キャラクタをタッチ操作した
後に何らスライド操作をせずタッチ操作を解除した場合であっても、タッチ操作の開始からタッチ操作の解除までの時間が少なくとも1フレーム周期だけ確保されていれば一連の処理(S15〜S25)が実行されるので、当該単一の敵キャラクタをロックオン(S15)かつ攻撃(S31)することが可能である。
したがって、ユーザは、スライド操作による連続ロックオン後の一斉攻撃と、タッチ操作による単独ロックオン後の単独攻撃との双方を行うことが可能である。
6−1−2.図12の各ステップ
以下、図12の各ステップを順に説明する。
ステップS11:ゲーム制御部214(設定部の一例)は、表示制御部212を介してゲーム画面を表示する。初回のステップS11では、ゲーム画面は初期画面に設定され、2回目以降のステップS11では、ゲーム画面の更新が行われる。
ステップS12:ゲーム制御部214は、タッチ検出処理部211を介して現フレームに対するタッチ操作の検出処理を行う。
ステップS13:ゲーム制御部214は、現フレームに対するタッチ操作が検出されたか否かを判定し、検出された場合にはロックオン判定処理(S15)へ移行し、そうでない場合には攻撃準備処理(S29)へ移行する。
ステップS15:ゲーム制御部214は、ロックオン判定処理を実行することにより所定の条件を満たした敵キャラクタをロックオンテーブルへ登録して次の処理(S17)へ移行する。なお、ロックオン判定処理のフローは、後述する。
ステップS17:ゲーム制御部214は、ゲーム演算部215を介してロックオンテーブル(図11)のボーナスフラグがオンされているか否かを判定し、オンされている場合はボーナス付与処理(S19)へ移行し、そうでない場合はロック解除判定処理(S23)へ移行する。
ステップS19:ゲーム制御部214は、ゲーム演算部215を介してボーナス付与処理を実行する。具体的には、ゲーム演算部215は、ロックオンテーブル(図11)に登録されている1又は複数の敵キャラクタの全てについて、ロックが解除されるまでの残り時間の延長処理を行う。この処理の例は、前述したとおりである。
ステップS21:ゲーム制御部214は、ゲーム演算部215を介してロックオンテーブル(図11)のボーナスフラグをオフしてからロック解除判定処理(S23)へ移行する。
ステップS23:ゲーム制御部214は、ロック解除判定処理を実行して時間のカウント値が制限値(ここでは10秒)に達した敵キャラクタをロックオンテーブルから削除してゲージ更新処理(S25)へ移行する。なお、ロック解除判定処理のフローは、後述する。
ステップS25:ゲーム制御部214は、ゲージ更新処理を実行してからフレーム更新処理(S11)へ移行する。なお、ゲージ更新処理のフローは、後述する。
ステップS29:ゲーム制御部214は、ロックオンテーブル(図11)に登録されている敵キャラクタの個数がゼロであるか否かを判定し、ゼロである場合に終了判定処理(
S33)へ移行し、そうでない場合に攻撃処理(S31)へ移行する。
ステップS31:ゲーム制御部214は、攻撃処理を実行してから終了判定処理(S33)へ移行する。なお、攻撃処理のフローは、後述する。
ステップS33:ゲーム制御部214は、ゲーム終了条件が満たされたか否かを判定し、満たされた場合に図12のフローを終了し、そうでない場合にフレーム更新処理(S11)へ移行する。なお、ゲーム終了条件が満たされた場合とは、不図示の終了ボタンがタッチ操作された場合(終了指示の入力)や、オブジェクト空間から全ての敵キャラクタが消去された場合(ゲームクリア)や、不図示の電源ボタンが押下された場合(終了指示の入力)などである。
なお、以上のフローにおけるステップの実行順序は、可能な範囲で入れ替えてもよい。
6−2.ロックオン判定処理のフロー
図13は、ロックオン判定処理のフローチャート(図12におけるサブルーチン)である。
本動作は、原則的には端末装置20において実行される処理である。ただし、一部の処理においては、サーバ装置10と連動することによって実行されることも可能である。
先ず、入力受付処理部213は、先行フレームから現フレームまでのスライド軌跡を算出する(S151)。先行フレームから現フレームまでのスライド軌跡を算出する方法は、前述したとおりである。
次に、入力受付処理部213は、現フレームに出現している敵キャラクタの各々のロック可能エリアを特性テーブル(図9)に基づき設定する(S155)。なお、本ステップでは、現フレームに出現している敵キャラクタの代わりに、先行フレームに出現していた敵キャラクタを用いることも可能である。
次に、入力受付処理部213は、設定したロック可能エリアの少なくとも1つの輪郭にスライド軌跡が交差するか否かを判定し(S157)、交差する場合(S157Y)は、当該ロック可能エリアに対応する敵キャラクタをロックオンするための処理(S159)へ移行し、そうでない場合(S157N)は、ロックオン判定処理のフロー(図13)をその時点で終了する。
次に、スライド軌跡にロック可能エリアが交差した1又は複数の敵キャラクタのロックオン指示を入力受付処理部213が受け付けると(S159)、ゲーム演算部215は、当該1又は複数の敵キャラクタをロックオンテーブル(図11)へ登録する(S159)。これによって、ロックオンテーブル(図11)に登録された敵キャラクタの個数が増えることになる。なお、ステップS159において入力受付処理部213が受け付けた敵キャラクタの個数が2以上である場合には、ゲーム演算部215は、先行フレームのタッチ位置に近い敵キャラクタほど先の順序で登録を行う。
次に、ゲーム演算部215は、現時点でロックオンテーブル(図11)に登録されている敵キャラクタの個数(すなわちロックオンされている敵キャラクタの個数)が目標数(30個)に達したか否かを判定し(S1511)、達した場合(S1511Y)には、ボーナスフラグをオンし(ステップS1515)、そうでない場合(S1511N)には、次の判定処理(S1513)へ移行する。
次に、ゲーム演算部215は、ロックオンテーブル(図11)へ新規に登録された1又は複数の敵キャラクタの中に特殊な敵キャラク(ここでは防御力が最高の敵キャラクタ)があるか否かを判定し(S1513)、特殊な敵キャラクタがある場合(S1513Y)には、ボーナスフラグをオンし(S1515)、そうでない場合(S1513N)には、更に別の判定処理(S1517)へ移行する。
次に、ゲーム演算部215は、ロックオンテーブル(図11)へ新規に登録された1又は複数の敵キャラクタの各々の属性が、当該敵キャラクタよりロックオン番号が「1」だけ小さい敵キャラクタの属性と同じであるか否かを判定し(S1517)、同じである場合には、ロックオンテーブル(図11)における当該敵キャラクタの連続フラグをオンし(S1519)、そうでない場合には次の処理(S1521)へ移行する。
次に、表示制御部212は、ステップS159でロックオンテーブル(図11)に登録された1又は複数の敵キャラクタに対するロックオンカーソルのゲーム画面への表示を開始する準備(例えば画像バッファ272の更新)を行う(S1521)。なお、実際に表示が開始されるのは、次に図12のステップS11が実行されたときである。
次に、ゲーム演算部215は、ロックオンテーブル(図11)へ新規に登録された1又は複数の敵キャラクタの距離のカウント及び時間のカウント(時間のカウント値及び距離のカウント値の定期的な更新)を開始し(S1523)、ロックオン判定処理のフローを終了する。
なお、以上のフローにおけるステップの実行順序は、可能な範囲で入れ替えてもよい。
6−3.ロック解除判定処理のフロー
図14は、ロック解除判定処理のフローチャート(図12におけるサブルーチン)である。
本動作は、原則的には端末装置20において実行される処理である。ただし、一部の処理においては、サーバ装置10と連動することによって実行されることも可能である。
先ず、ゲーム演算部215は、ロックオンテーブル(図11)を参照し(S231)、ロックオンテーブル(図11)に登録されている敵キャラクタの中に時間のカウント値が制限値(ここでは10秒)に達したものが存在するか否かを判定し(S233)、存在する場合には次の処理(S235)へ移行し、そうでない場合にはロック解除判定処理のフローを終了する。
次に、ゲーム演算部215は、時間のカウント値が制限値(ここでは10秒)に達した1又は複数の敵キャラクタをロックオンテーブル(図11)から削除することによりロックオンテーブル(図11)を更新する(S235)。ロックオンテーブルから削除された1又は複数の敵キャラクタは、攻撃処理の対象から外されることになり(すなわちロックが解除され)、ロックオンテーブル(図11)から削除されなかった1又は複数の敵キャラクタのロックオン番号は、削除された敵キャラクタの数だけ繰り上がる。
次に、表示制御部212は、ゲーム画面における当該1又は複数の敵キャラクタのロックオンカーソルを消去する準備(例えば画像バッファ272の更新)を行う(S237)。なお、実際にカーソルが消去されるのは、次に図12のステップS11が実行されたときである。これによって、ロック判定処理のフローが終了する。
なお、以上のフローにおけるステップの実行順序は、可能な範囲で入れ替えてもよい。
6−4.ゲージ更新処理のフロー
図15は、ゲージ更新処理のフローチャート(図12におけるサブルーチン)である。
本動作は、原則的には端末装置20において実行される処理である。ただし、一部の処理においては、サーバ装置10と連動することによって実行されることも可能である。以下、各ステップを順に説明する。
先ず、ゲーム演算部215は、ロックオンテーブル(図11)を参照し、ロックオン番号が最大の敵キャラクタ(最後にロックオンされた敵キャラクタ)の距離のカウント値と、ロックオンテーブル(図11)においてオンされている連続フラグの個数とを認識する(S251)。
次に、ゲーム演算部215は、距離のカウント値と、連続フラグの個数とに応じて攻撃力パラメータを設定する(S253)。
次に、表示制御部212は、ゲーム演算部215が設定した攻撃力パラメータを、ゲーム画面上のゲージ1000へ反映させる準備(例えば画像バッファ272の更新)を行う(S255)。なお、実際に反映されるのは、次に図12のステップS11が実行されたときである。
次に、ゲーム演算部215は、ロックオンテーブル(図11)においてロックオン番号が「1」である敵キャラクタ(最も早期にロックオンされた敵キャラクタ)の時間のカウント値を参照し、カウント値から制限値(ここでは10秒)までの残りカウント値を算出する。表示制御部212は、算出されたカウント値をゲーム画面上のゲージ2000へ反映させる準備(例えば画像バッファ272の更新)を行う(S257)。なお、実際に反映されるのは、次に図12のステップS11が実行されたときである。これによって、ゲージ更新処理のフローが終了する。
なお、以上のフローにおけるステップの実行順序は、可能な範囲で入れ替えてもよい。
6−5.攻撃処理のフロー
図16は、攻撃処理のフローチャート(図12におけるサブルーチン)である。
本動作は、原則的には端末装置20において実行される処理である。ただし、一部の処理においては、サーバ装置10と連動することによって実行されることも可能である。以下、各ステップを順に説明する。
先ず、ゲーム演算部215は、ロックオンテーブル(図11)に登録されている1又は複数の敵キャラクタの各々の体力値(HP)を、ステータステーブル(図10)に基づき認識する(S311)。
次に、ゲーム演算部215は、当該1又は複数の敵キャラクタの各々の体力値(HP)から、ステップS253で設定した攻撃力パラメータに応じた値を、減算する。そして、ゲーム演算部215は、ステータステーブル(図10)における体力値(HP)を、減算後の値に更新する(S313)。これによって、ロックオンテーブル(図11)に登録されている1又は複数の敵キャラクタが攻撃されたことになる。
次に、ゲーム演算部215は、ステップS313にて体力値(HP)がゼロになった敵キャラクタの属性及び個数に応じて、ユーザ情報273に保管されているスコアを更新す
る(S317)。
次に、ゲーム演算部215は、ロックオンテーブル(図11)における全ての敵キャラクタを削除する(S319)。これによって、ロックオンテーブル(図11)がリセットされる。
次に、表示制御部212は、前述した攻撃画像をゲーム画面へ表示すると共に、次のステップS11で表示すべきゲーム画面(更新後のゲーム画面)の準備(例えば画像バッファ272の更新)を行う(S3110)。これによって、攻撃処理のフローが終了する。なお、実際にゲーム画面が更新されるのは、次に図12のステップS11が実行されたときである。因みに、更新後のゲーム画面では、全てのロックオンカーソルは消去され、体力値(HP)がゼロになった敵キャラクタは消去され、スコア900には更新後のスコアが反映される。
なお、以上のフローにおけるステップの実行順序は、可能な範囲で入れ替えてもよい。
7.実施形態の作用効果
以上説明したとおり、上記実施形態の端末装置20は、ゲーム画面へのスライド操作入力を受け付け、当該受け付けたスライド操作入力に応じてゲームを実行するものであって、攻撃処理の対象となり得る複数の敵キャラクタトをゲーム画面に表示する処理(S11)と、複数の敵キャラクタのうち、ゲーム画面に対するスライド操作の軌跡に対して所与の条件(例えば軌跡からの距離が所定値未満という条件)を充足するものを、攻撃処理の対象にロックオンする処理(S159)と、ロックオン後におけるスライド操作の時間を敵キャラクタごとにカウントする処理(主にS1523)と、ロックオン中の敵キャラクタのうちカウント値が制限値に達した敵キャラクタについてのロックを解除する処理(S235)と、ユーザによるタッチ操作の解除が行われた場合(S13のN)には、行われた時点でロック中の敵キャラクタへ、攻撃処理(S31)を実行し、ロック中の敵キャラクタが所与の条件(例えばキャラクタ数が目標数に達するという条件)を充足した場合(S1551Y)には、当該敵キャラクのロックが解除されるまでの残りカウント値を延長する(S19)。
よって、ユーザは、ゲーム画面へのスライド操作によって複数の敵キャラクタをロックオンしてからタッチ操作の解除をするだけで、ロックオンされた複数の敵キャラクタへ攻撃処理を施すことができる。但し、上記実施形態の端末装置20は、カウント値が制限値に達した敵キャラクタのロックを解除する一方で、ロック中の敵キャラクタが所与の条件を充足した場合には1回のスライド操作で設定できるオブジェクトの個数を増大できるという可能性(ボーナス)をユーザへ付与する。このため、ユーザがスライド操作の時間を長くとるほどボーナス付与の確率すなわちロックオン数が増大される確率が高まるものの、スライド操作の時間が長くなるほどロックオンが解除される可能性も高まる、というトレードオフの関係が作り出される。したがって、上記実施形態の端末装置20によれば、スライド操作を利用したシンプルかつ面白みのある攻撃型のゲームが実現する。
8.変形例
8−1.敵キャラクタの動きによるロック困難度制御
上記実施形態の表示制御部212は、ゲーム画面上で敵キャラクタを揺動させたが、揺動させることに加えて、又は揺動させることに代えて、敵キャラクタを移動させてもよい。例えば、表示制御部212は、タッチ位置又はスライド軌跡からの距離が所定値未満である敵キャラクタに対して、タッチ位置又はスライド軌跡から所定速度で離れる(逃げる)動作をさせてもよい。この場合、ユーザが敵キャラクタをロックオンするためには、敵キャラクタの速度よりも早い速度でスライド操作をする必要が生じるので、ロックオンの
難易度が高まる。
また、表示制御部212は、敵キャラクタの移動速度、揺動の振幅、揺動の周波数の少なくとも1つに敵キャラクタの防御力を反映させてもよい。例えば、表示制御部212は、特性テーブル(図9)において防御力が高く設定されている敵キャラクタほど敵キャラクタの移動速度(揺動の振幅、揺動の周波数なども含む)を大きく設定してもよい。
また、上記実施形態の表示制御部212は、敵キャラクタの移動速度、揺動の振幅、揺動の周波数の少なくとも1つにスライド操作の速度を反映させてもよい。ここで、スライド操作の速度とは、タッチ位置の変化速度のことであり、例えば、最新のスライド速度は、現フレームにおけるタッチ位置と先行フレームにおけるタッチ位置との距離が大きいほど高いとみなすことができる。
8−2.タッチ時間によるロック困難度制御
また、上記実施形態の入力受付処理部213は、防御力の高い敵キャラクタほどロック可能エリアのサイズを狭く設定したが、ロック可能エリアのサイズを狭く設定するのに加えて、又は、ロック可能エリアのサイズを狭く設定する代わりに、ロックオンに必要なタッチ時間(ロックオン指示の入力を受け付けたとみなすまでのタッチ時間)を長く設定してもよい。
例えば、入力受付処理部213は、例えばゲームデータ記憶部274に判定履歴を残しつつ、各フレームについて以下の判定処理(1),(2),(3)を実行すればよい。
(1)入力受付処理部213は、防御力が「低」の敵キャラクタCAAのロック可能エリアに軌跡が交差したと判定した場合には、当該敵キャラクタに対するロックオン指示の入力を受け付け、そうでない場合には受け付けない。
(2)入力受付処理部213は、防御力が「中」である敵キャラクタCABのロック可能エリアに軌跡が交差したと判定した場合には判定履歴を参照し、先行するフレームの判定でも同一の敵キャラクタCABについて同じ判定結果が得られていた場合には、当該敵キャラクタに対するロックオン指示の入力を受け付け、そうでない場合には受け付けない。
(3)入力受付処理部213は、防御力が「高」である敵キャラクタCACのロック可能エリアに軌跡が交差したと判定した場合には判定履歴を参照し、先行2つのフレームの判定の各々において同一の敵キャラクタCACについて同じ判定結果が得られていた場合には、当該敵キャラクタに対するロックオン指示の入力を受け付け、そうでない場合には受け付けない。
したがって、ユーザは、防御力の高い敵キャラクタCACをロックオンするために、スライド操作の途中で敵キャラクタCACを所定時間(ここでは3フレーム周期分)に亘って連続してタッチ操作する必要がある。したがって、ユーザには、時間の残りカウント値に余裕があるときには、防御力の高い敵キャラクタCACを追うことができるが、時間の残りカウント値に余裕の無いときには、当該敵キャラクタCACを追うことをあきらめる、といった柔軟な判断が迫られる。
8−3.一斉ロック解除
上記の実施形態のゲーム演算部215は、ロックを解除するか否かの判定を敵キャラクタごとに行ったが、ロックを解除するか否かの判定を、ロックされている全ての敵キャラクタについて一括して行ってもよい。例えば、ゲーム演算部215は、ロックオンテーブ
ルに登録されている敵キャラクタ(ロックオンされている敵キャラクタ)のうち、ロックオン番号が最も上位である敵キャラクタ(最も早期にロックオンされた敵キャラクタ)の時間の残りカウント値がゼロとなった場合に、ロックオンテーブルに登録されている全ての敵キャラクタのロックを一斉に解除してもよい。この場合、ユーザには、最も早期にロックオンした敵キャラクタの残りカウント値がゼロになる直前に一斉攻撃できれば高得点が得られるが、残りカウント値がゼロになった途端に全てのロックが解除されてしまう、というハイリスクハイリターンな状況が作り出される。
なお、ロックされている全ての敵キャラクタのロックを一斉に解除する場合、上記の実施形態のゲーム演算部215は、時間のカウントを開始するタイミングを、ロックされたタイミングではなくスライド操作が開始されたタイミング(スライド操作の開始時におけるタッチ操作のタイミング)としてもよい。
8−4.距離カウントダウン
上記の実施形態のゲーム演算部215は、ロックを解除する否かの判定に、スライド操作の時間(時間のカウント値)を用いたが、スライド操作の距離(距離のカウント値)を用いてもよい。この場合、ユーザは、高得点を狙うために、なるべく短い距離で多くの敵キャラクタをスライド操作してロックオンすることを目指すことになる。
また、上記の実施形態のゲーム演算部215は、ロックを解除するか否かの判定に、スライド操作の時間(時間のカウント値)を用い、かつ、ユーザへのボーナスとして「ロック解除までの残り時間の延長(時間の残りカウント値の延長)」を付与したが、ロックを解除するか否かの判定に、スライド操作の距離(距離のカウント値)を用い、かつ、ユーザへのボーナスとして「ロック解除までの残り距離の延長(距離の残りカウント値の延長)」を付与してもよい。
8−5.ロングタッチ攻撃
上記の実施形態のゲーム演算部215は、余剰距離(最後にロックされた敵キャラクタの距離のカウント値)を攻撃力パラメータに反映させたが、余剰時間(最後にロックされた敵キャラクタの時間のカウント値)を攻撃力パラメータに反映させてもよい。その場合、ユーザは、敵キャラクタを最後にロックオンしてからタッチ操作を解除するまで余剰なタッチ操作(長押し操作)又は余剰なスライド操作を行うことで、敵キャラクタへのダメージを増大させることができ、しかも、余剰なタッチ操作又は余剰なスライド操作の時間(余剰時間)を大きくするほど大きなダメージを敵キャラクタへ与えることができる。但し、余剰時間が長いほど敵キャラクタをロックできるチャンスは減ってロックが解除されるリスクも高まるので、ユーザには、いかなるタイミングで余剰なタッチ操作又は余剰なスライド操作をし始め、いかなるタイミングで余剰なタッチ操作又は余剰なスライド操作を終えるべきかの判断が求められる。
8−6.ボーナス条件
上記の実施形態のゲーム演算部215は、ユーザへボーナスが与えられる条件(ボーナス条件)を、ロックオンテーブルに登録された敵キャラクタの個数が目標数(30個)に達した場合、又は、ロックオンテーブルに特殊な敵キャラクタが登録された場合としたが、「ロックオンテーブルに登録された複数の敵キャラクタの中に特殊な配列パターンを有する一連の敵キャラクタが含まれていた場合」としてもよい。例えば、ロックオンテーブルに登録された複数の敵キャラクタの中に、属性の配列パターンが「ABABABABABABABABABABABABABABAB」、「ACACACACACACACACACACACACACACAC」、「BCBCBCBCBCBCBCBCBCBCBCBCBCBCBC」の何れかに合致する一連の敵キャラクタが含まれている場合などである。
8−7.ボーナス内容
上記の実施形態のゲーム演算部215は、ロックオンテーブルに登録された敵キャラクタが所与の条件を充足した場合にユーザへ与えられるボーナスを、ロックが解除されるまでの残り時間の延長又は残り距離の延長としたが、他のボーナス、例えば、必殺技の発動、アイテムの付与、ゲーム時間の延長、ユーザの攻撃力アップ、ユーザの体力値アップ、攻撃力パラメータのアップなどとしてもよい。
8−8.攻撃パラメータ
上記の実施形態のゲーム演算部215は、登録番号が最大である敵キャラクタ(最後にロックされた敵キャラクタ)の距離のカウント値又は時間のカウント値を、攻撃力パラメータに反映させたが、攻撃力パラメータ以外の攻撃パラメータへ反映させてもよい。例えば、例えば、攻撃タイプ(マシンガン、手榴弾、光線兵器などの武器タイプ)、攻撃回数(発射回数など)、攻撃時間などに反映させてもよい。
8−9.パズルゲームの変形例
8−9−1.パズルゲームの概要
上記の実施形態は、オブジェクト空間に出現する敵キャラクタを攻撃する攻撃ゲームへ本発明を適用したものであるが、オブジェクト空間に出現するブロック(以下、「パズルピース」という。)を消去するパズルゲームにも本発明は適用が可能である。パズルピースはオブジェクトの一例であり、ゲーム画像からパズルピースを消去する処理は所与の処理の一例である。本変形例では、このパズルゲームについて説明する。ここでは、上記実施形態の攻撃ゲームと共通する部分の説明は省略し、上記実施形態の攻撃ゲームとの相違点を主に説明する。
本変形例において、ゲーム画面の表示当初、例えばゲーム画面内には複数のパズルピースが密に配列されたオブジェクト空間が表示される。当該複数のパズルピースには、属性の異なる複数種類のパズルピースが含まれている。「属性の異なる複数種類のパズルピース」とは、例えば、色、柄、マーク、形状、仮想質量の組み合わせの異なる複数種類のパズルピースのことである。
ゲーム画面に表示された当該複数のパズルピースのうち、ユーザのスライド操作によって一部のパズルピースが消去されるとゲーム画面に間隙が生じる。次いで、オブジェクト空間の仮想重力を受けた新規のパズルピースがゲーム画面内に自由落下し、当該間隙が埋まる。なお、このとき、新規のパズルピースの落下経路に他のパズルピースがあれば、当該パズルピースが新規のパズルピースに押されて移動してもよい。また、新規のパズルピースの属性は、ランダムに決定されてもよいし、予め決められた法則に従って決定されてもよい。また、パズルピースの落下方法には、公知の何れかの方法を採用することができる。例えば、パズルピースが消去されるペースと同じペースで新規のパズルピースが落下してもよいし、パズルピースが消去されるペースと関係なく、予め決められたペースで新規のパズルピースが落下してもよい。
ユーザがゲーム画面をスライド操作すると、スライド操作の当初のタッチ位置に配置されていたパズルピースと同じ属性のパズルピースは、当該スライド操作中にタッチ操作されたタイミング(すなわちパズルピースの輪郭がスライド軌跡と交差したタイミング)でロックオンされる。一方、当初のタッチ位置に配置されていたパズルピースとは属性の相違するパズルピースは、当該スライド操作中にタッチ操作されたとしても(すなわちパズルピースの輪郭がスライド軌跡と交差したとしても)ロックオンされない。
つまり、本変形例のパズルゲームでは、1回のスライド操作によりロックオン可能なオ
ブジェクトが、当該スライド操作の当初にタッチ操作されたオブジェクトと同じ属性のオブジェクトのみに制限される。そして、ロックされたパズルピースのうち、時間のカウント値が制限値に達した(残り時間がゼロとなった)パズルピースのロックは、その時点で解除される。
そして、ユーザが当該スライド操作後にタッチ操作を解除すると、タッチ操作が解除された時点でロックされていたパズルピースが全て消去される。
ここで、パズルピースの消去される順序は、その後のゲーム進行に大きな影響を与える。なぜなら、オブジェクト空間内におけるパズルピースの配列(属性の配列)は、パズルピースが消去される順序に依存するからである。
そこで、本変形例のパズルゲームでは、原則的に、タッチ操作の解除後に複数のパズルピースが消去される順序を、当該複数のパズルピースの残り時間(時間の残りカウント値)に応じた順序に設定し、また、当該複数のパズルピースが消去されるタイミングの差を、タッチ操作の解除時点における残りカウント値の差と同じに設定する。したがって、本実施例のパズルゲームは、自分がロックオンした順序次第でその後のゲーム展開が変化するという実感を、ユーザに与えることができる。以下、これを実現するための具体的な動作を説明する。
8−9−2.ピース消去のタイミング制御
本変形例のゲーム演算部215は、上記実施形態のゲーム演算部215と同様、タッチ操作が解除された時点でロックオンテーブル(図11)の登録を全て削除(オールリセット)するが、その際に、ロックオンテーブル(図11)に登録されていたパズルピースの情報を不図示の処理テーブルへ移行させる(すなわちパズルピースを処理テーブルへ登録する)。この処理テーブルは、ゲーム画面からパズルピースを消去するタイミングを制御するためのテーブルである。
処理テーブルには、少なくとも個々のパズルピースが消去されるまでの残り時間(時間の残りカウント値)の情報が書き込まれる。処理テーブルにおける残りカウント値は、ロックオンテーブル(図11)におけるロックオン番号が上位であったパズルピースほど小さな値に設定される(例えば最上位の残りカウント値はゼロに設定される。)。この場合、ユーザがタッチ操作を解除した直後にパズルピースが消去され始めることになる。また、処理テーブルにおけるパズルピース間の残りカウント値の差は、ロックオンテーブル(図11)における時間のカウント値の差と同じに設定される。この場合、パズルピース間における消去タイミングのずれは、原則的に、パズルピース間におけるロックタイミングのずれと同じに設定される。
そして、ゲーム演算部215は、処理テーブルにおける残りカウント値のカウントダウンを開始することで、パズルピースをゲーム画面から消去する準備を開始する。このカウントダウンは、定期的に(例えばフレーム周期で)行われる。
その後、ゲーム演算部215は、定期的に(例えばフレーム周期で)処理テーブルを参照し、残りカウント値がゼロとなったパズルピースが処理テーブルに存在していた場合には、表示制御部212を介してゲーム画面から当該パズルピースを消去し、当該パズルピースを処理テーブルから削除(登録抹消)する。
また、ゲーム演算部215は、同時に消去すべきパズルピースの個数が多いときほど、処理の効果(例えばユーザの得点)を高く設定する。
8−9−3.時間ボーナス後のコンボ攻撃
本変形例のゲーム演算部215は、例えば上記の実施形態と同様、例えばロックオンされているパズルピースの個数が「7」に達した場合に、時間ボーナスをユーザへ付与する。但し、本変形例のゲーム演算部215は、時間ボーナスをユーザへ付与する際に、ロックオンテーブル(図11)に登録されている全ての時間のカウント値を一斉に同じ値にリセットする。この場合、時間ボーナスが付与された時点でロックされていた複数のパズルピースの間では、時間の残りカウント値が共通となる。よって、時間ボーナスが付与された時点でロックされていた複数のパズルピースの間では、ロックの解除されるタイミングもゲーム画面から消去されるタイミングも共通となる。
よって、本変形例のユーザは、時間ボーナスが付与された後であって付与の時点でロックされていた全てのパズルピースのロックが解除される前にタッチ操作を解除したならば、当該全てのパズルピースを一斉消去して高得点を得ることができる(コンボ攻撃の発動)。
その反対に、本変形例のユーザは、時間ボーナスが付与された後にタッチ操作を解除せずにスライド操作を継続したならば、同時にロックできるパズルピースの個数、ひいては同時に消去されるパズルピースの個数を、更に増大させることができる。但し、その場合は、当該全てのパズルピースのロックが一斉に解除される(すなわち時間ボーナスが無駄になる)かもしれないというリスクをユーザが負うことになる。
したがって、本変形例のパズルゲームは、時間ボーナスの付与後、リスクを回避して早期にコンボ攻撃を発動させるか、それともリスクを負ってパズルピースの消去数増大にチャレンジするかという決断を、ユーザに迫ることができる。
8−9−4.パズルゲームの補足
なお、上記パズルゲームについても攻撃ゲームと同様の変形が可能である。
また、パズルゲームに適用されたゲーム演算部215の動作の一部又は全部は、攻撃ゲームにも適用が可能である。
例えば、属性によるロック制限(最初にタッチ操作したオブジェクトと同じ属性のオブジェクトしかロックできないという制限)は、攻撃ゲームに適用することも可能である。
また、パズルゲーム又は攻撃ゲームにおいては、オブジェクトの個数による処理制限を課してもよい。「個数による処理制限」とは、タッチ操作を解除した時点でロックされていたオブジェクトの個数が例えば所定数以下(例えば2以下)である場合には、当該オブジェクトへ処理(攻撃又は消去)を施さない、という制限である。
また、タイミング制御(複数のオブジェクトに処理が施される順序を、時間の残りカウント値に応じた順序とする制御)は、攻撃ゲームに適用することも可能である。
また、ボーナス付与後のコンボ攻撃(複数のオブジェクトへ同時に処理を施す)は、パズルゲームだけでなく攻撃ゲームにも適用することが可能である。
8−10.ポインティングデバイス
上記の実施形態では、端末装置20のユーザインタフェースとしてタッチパネルを利用したが、ゲーム画面上のカーソル(ポインタ)を移動させるマウスなどのポインティングデバイスをタッチパネルの代わりに利用することもできる。
その場合、ユーザは、ポインティングデバイス(マウス)の確定ボタン(左ボタン)を押下しながらゲーム画面内のカーソル(ポインタ)をスライドさせることで、「スライド操作」を行うことができる。また、スライド操作後にポインティングデバイス(マウス)の確定ボタン(左ボタン)を解除することで、「スライド操作後のタッチ操作の解除」を行うことができる。
一方、タッチ検出処理部211は、各フレームについてのタッチ位置の検出処理を例えば次のとおり行えばよい。すなわち、タッチ検出処理部211は、ポインティングデバイス(マウス)の確定ボタンが押下されているか否かを判定し、押下されている場合には、ゲーム画面内のカーソル(マウスポインタ)の位置を「タッチ位置」として検出し、確定ボタンが押下されていない場合には「タッチ位置」を検出しない。この場合、ユーザがポインティングデバイス(マウス)でスライド操作を行うと、ゲーム画面の連続するフレームから連続して「タッチ位置」が検出され、ユーザがスライド操作後に確定ボタン(左ボタン)を解除した場合には、フレームから「タッチ位置」が検出されない。
8−11.画面切り替え(スクロールなど)
上記の実施形態の表示制御部212は、ゲーム画面の切り替え方については、様々な手法を適用することができる。例えば、端末装置20は、仮想カメラの位置、仮想カメラの向き、仮想カメラの画角のうち少なくとも1つをオブジェクト空間内で時間変化させることで、オブジェクト空間においてユーザがスライド操作可能なエリアを時間変化させてもよい(因みに、オブジェクト空間における仮想カメラの位置をユーザから見て上下又は左右に時間変化させると、ゲーム画面がスクロールする。)。なお、仮想カメラの位置又は向きを時間変化させる方向は、ユーザから見て上下方向でもよいし左右方向でもよい。また、仮想カメラの画角を変化させる方向は、ユーザから見て画角が拡大する方向であってよいし画角が縮小する方向であってもよい。また、仮想カメラの位置、仮想カメラの向き、仮想カメラの画角のうち少なくとも1つの時間変化パターンは、スライド操作の時間、スライド操作の距離、スライド操作を行った回数、ゲーム開始からの経過時間、ユーザのランクなどに応じて設定されてもよい。
8−12.ロックオン通知
上記の実施形態の表示制御部212は、ロックオンされた敵キャラクタを他の敵キャラクタとゲーム画面上で区別するために、敵キャラクタへマーク(ロックオンカーソル)を付与したが、マークを付与する代わり又はマークを付与することに加えて、敵キャラクタ自体の表示態様(表示サイズ、表示色、表示輝度、時間変化パターンの組み合わせ)を変化させてもよい。
また、上記の実施形態の表示制御部212は、ロックが解除されるまでの残りカウント値に応じてマーク(ロックオンカーソル)の表示態様(表示サイズ、表示色、表示輝度、時間変化パターンの組み合わせ)を変化させたが、敵キャラクタの表示態様(表示サイズ、表示色、表示輝度、時間変化パターンの組み合わせ)を変化させてもよい。
また、敵キャラクタがロックオンされた旨のユーザへの通知は、表示制御部212による画像表示に加えて、又は、表示制御部212による画像表示の代わりに、音処理部230による音出力によって行われてもよい。
また、敵キャラクタがロックオンされた旨をユーザへ通知するほか、敵キャラクタのロックが解除された旨をユーザへ通知してもよい。
8−13.敵の体当たり攻撃
上記の実施形態では、敵キャラクタへユーザが攻撃を与えるゲームについて説明したが
、当該ゲームにおいては、敵キャラクタからユーザへ攻撃(以下、「体当たり攻撃」という。)が与えられてもよい。敵キャラクタからユーザへ体当たり攻撃が与えられるタイミングは、所与の条件(以下、「体当たり条件」という。)が満たされたタイミングである。
例えば、本実施形態のゲーム演算部215は、ゲーム開始からの経過時間が閾値以上である場合や、敵キャラクタの体力値の合計が閾値以上である場合などに、体当たり条件が満たされたと判定し、敵キャラクタがユーザへ体当たり攻撃を与える処理を実行してもよい。この処理は、例えば、ユーザのスコア及び体力値の少なくとも一方を減算する処理である。
また、本実施形態のゲーム演算部215は、体当たり攻撃の時点でロックオンテーブルに登録されている敵キャラクタの一部又は全部をロックオンテーブルから消去してもよい。これによって、ロックオンされていた敵キャラクタの一部又は全部のロックが体当たり攻撃によって強制的に解除されるので、ロックオンに費やした過去の労力が無駄になるというユーザにとって不利な状況を作り出すことができる。
また、以上の体当たり攻撃が実施される場合、表示制御部212は、体当たり攻撃が開始されるまでの残り時間をゲージなどでゲーム画面へ表示させてもよい。
8−14.攻撃トリガー
上記の実施形態のゲーム制御部214は、攻撃のトリガーを「スライド操作後にタッチ操作を解除すること」としたが、他の所定のアクションとしてもよい。例えば、「スライド操作後にタッチ操作を解除してから更に所定のボタンをタッチすること」などのアクションとしてもよいし、「スライド軌跡で所定の文字又は図形を描くこと」などのアクションとしてもよい。
8−15.オブジェクト空間
上記の実施形態の端末装置20は、オブジェクト空間の次元を2次元としたが、3次元としてもよい。その場合は、攻撃パラメータの数も増えるので、例えば最後にロックオンされた敵キャラクタのカウント値を、他の攻撃パラメータである攻撃距離(射程距離)などへ反映させてもよい。
8−16.アイテム獲得ゲーム
上記の実施形態のゲームは、ロックオンした敵キャラクタへ攻撃を加えるシューティングゲーム又はロックオンしたパズルピースをゲーム画面から消去するパズルゲームに本発明を適用したものであるが、ロックオンしたオブジェクト(アイテム、キャラクタ)をユーザに獲得させる獲得ゲームなどの他種ゲームにも本発明は適用が可能である。
また、上記の実施形態の端末装置20は、同一のオブジェクト空間内に、攻撃対象となる敵キャラクタと、獲得対象となるオブジェクト(以下、「アイテム等」という。)との双方を同時に出現させ、かつ、敵キャラクタとアイテム等とをユーザが1回のスライド操作でロックオンできるようにしてもよい。
その場合、ゲーム演算部215は、ユーザがスライド操作後にタッチ操作を解除したタイミングで、ロックオンされている敵キャラクタへの攻撃処理とロックオンされているアイテム等の獲得処理との双方を実行してもよい。
また、その際に、ゲーム演算部215は、ロックオンされているアイテムの属性等に応じてロックオンされている敵キャラクタに対する攻撃パラメータを設定してもよい。例え
ば、ゲーム演算部215は、ロックオンされていたアイテム等の属性がユーザにとって有利なものであるほど攻撃力パラメータを大きく設定してもよい。このようにすれば、攻撃したい敵キャラクタと有利なアイテムとを1回のスライド操作でロックオンしようというモチベーションをユーザに与えることができる。
8−17.その他の変形例
本発明は、上記実施形態で説明したものに限らず、種々の変形実施が可能である。例えば、明細書又は図面中の記載において広義や同義な用語として引用された用語は、明細書又は図面中の他の記載においても広義や同義な用語に置き換えることができる。
例えば、本実施形態は、一のサーバ装置10によって各ゲームを端末装置20に提供してもよいし、複数のサーバ装置10を連動させてサーバシステムを構築し、各ゲームを端末装置に提供してもよい。
さらに、本実施形態においては、サーバ装置10によって提供されたゲームを端末装置20によって実行されているが、タッチ検出処理部211を除き、上記の端末装置20の処理部200の各機能及びゲームプログラムの実行をサーバ装置10で実行し、当該端末装置20は、操作入力とストリーミングによる画像表示を実行することによって、上記のゲームを実現してもよい。
また、本実施形態においては、ゲーム装置に本発明の端末装置を適用しているが、ゲーム装置に限らず、スマートフォン、タブレット型情報端末装置、パーソナルコンピュータ、モニター又はテレビなどのタッチパネルを用いて操作入力を実行可能な端末装置であれば、本発明の端末装置を提供することができる。
本発明は、実施形態で説明した構成と実質的に同一の構成(例えば、機能、方法及び結果が同一の構成、あるいは目的及び効果が同一の構成)を含む。また、本発明は、実施形態で説明した構成の本質的でない部分を置き換えた構成を含む。また、本発明は、実施形態で説明した構成と同一の作用効果を奏する構成又は同一の目的を達成することができる構成を含む。また、本発明は、実施形態で説明した構成に公知技術を付加した構成を含む。
上記のように、本発明の実施形態について詳細に説明したが、本発明の新規事項及び効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。したがって、このような変形例はすべて本発明の範囲に含まれるものとする。