JP6318279B1 - 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム - Google Patents

情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム Download PDF

Info

Publication number
JP6318279B1
JP6318279B1 JP2017053400A JP2017053400A JP6318279B1 JP 6318279 B1 JP6318279 B1 JP 6318279B1 JP 2017053400 A JP2017053400 A JP 2017053400A JP 2017053400 A JP2017053400 A JP 2017053400A JP 6318279 B1 JP6318279 B1 JP 6318279B1
Authority
JP
Japan
Prior art keywords
game
combo
input operation
control unit
display
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017053400A
Other languages
English (en)
Other versions
JP2018153470A (ja
Inventor
裕史 渡邉
裕史 渡邉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Colopl Inc
Original Assignee
Colopl Inc
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 Colopl Inc filed Critical Colopl Inc
Priority to JP2017053400A priority Critical patent/JP6318279B1/ja
Application granted granted Critical
Publication of JP6318279B1 publication Critical patent/JP6318279B1/ja
Publication of JP2018153470A publication Critical patent/JP2018153470A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • User Interface Of Digital Computer (AREA)

Abstract

【課題】ゲーム性を高めることができる情報処理方法を提供する。【解決手段】情報処理方法は、ゲームを表示するスクリーンにユーザによる入力操作に関する操作情報を表示させるために、コンピュータによって実行される。該方法は、入力操作に基づいた表示形態で操作情報をスクリーンに表示させる第一表示ステップと、所定の表示条件が満たされている間は、入力操作に基づいた表示形態で操作情報をスクリーンに表示させず、入力操作に基づかない表示形態で操作情報をスクリーンに表示させる第二表示ステップと、を備える。【選択図】図23

Description

本開示は、情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラムに関する。
特許文献1は、操作により特定される入力手順が、所定の基準手順に一致するか否かを判定し、入力操作の一致又は不一致を示す表示を行う方法を開示する。
特許5864810号公報
特許文献1記載の方法は、多彩な操作をユーザに入力させることでゲーム性を向上させることについて、改善の余地がある。
本開示に係る方法は、ゲームを表示するスクリーンにユーザによる入力操作に関する操作情報を表示させるために、コンピュータによって実行される情報処理方法であって、入力操作に基づいた表示形態で操作情報をスクリーンに表示させる第一表示ステップと、所定の表示条件が満たされている間は、入力操作に基づいた表示形態で操作情報をスクリーンに表示させず、入力操作に基づかない表示形態で操作情報をスクリーンに表示させる第二表示ステップと、を備える。
本開示によれば、ゲーム性を高めることができる方法、装置及びプログラムが提供される。
一実施形態のゲーム提供システムの構成を示す図である。 携帯端末の構成を示すブロック図である。 サーバの機能的な構成を示すブロック図である。 入力操作受付部が入力操作の種類を検知する処理を説明する図である。 移動方向検出部がユーザの入力操作に応じてゲームキャラクタを移動させる方向を検出する処理を説明する図である。 ドラッグ操作時に表示されるオブジェクトの一例である。 ドラッグ操作時に表示されるオブジェクトの一例である。 ドラッグ操作時に表示されるオブジェクトの変形を説明する図である。 オブジェクトの変形時おけるポリゴン方向調整処理を説明する図である。 オブジェクトの変形後にタッチ位置が更新された場合について示す模式図である。 カメラ配置制御部が仮想カメラを制御する処理を説明する図である。カメラ配置制御部が仮想カメラを制御する処理を説明する図である。 ユーザによる入力操作に応じて変化するカメラワーク及び操作オブジェクトを説明する図である。 移動操作時の処理を説明するフローチャートである。 交戦時における仮想カメラの撮影方向を説明するための画面例である。 攻撃操作時の処理を説明するフローチャートである。 オブジェクト制御部がコンボデータに基づいてゲームキャラクタに攻撃動作を実行させたときのアクションの一例を示す図である。 フリック操作時の処理を説明するフローチャートである。 フリック操作に基づく動作処理を説明するフローチャートである。 コンボ列を定義するテーブル群の一例である。 コンボ列の分岐を説明する図である。 ドラッグ操作の案内表示となるアニメーション画像の一例である。 アニメーションを利用した案内表示の一例を説明する図である。 アニメーションを利用した案内表示の他の例を説明する図である。 先行入力を説明する図である。 後発入力を説明する図である。 案内表示時間について説明する図である。 コンボ処理を説明するフローチャートである。 コンボ列の分岐時におけるコンボ処理のフローチャートである。 案内表示処理のフローチャートである。
以下、図面を参照しつつ、本開示の一実施形態について説明する。以下の説明では、同一の部品又は構成要素には同一の符号が付される。それらの名称及び機能は同一である。したがって、それらについての詳細な説明は繰り返さない。
[技術思想]
ゲームの一例として、ユーザによる入力操作に応じて、キャラクタがゲームの仮想空間を移動したり、ゲームの仮想空間に配置された敵キャラクタと交戦したりするゲームがある。このようなゲームにおいて、ユーザによる攻撃操作の手順が所定手順に一致する場合には、通常の攻撃操作によるダメージよりも大きなダメージを敵キャラクタに与えることができるゲームシステム(いわゆるコンボシステム)が存在する。コンボシステムを採用することにより、ゲームキャラクタに多彩な攻撃動作を行わせることができるため、ゲーム性が向上する。しかしながら、ユーザは、数多くの操作手順を理解しなければならない。したがって、多彩な操作をユーザに入力させる工夫が必要になる。このような工夫の一つとしては、ユーザに対して次の操作を案内するシステムを提供することが考えられる。このシステムを採用するにあたっては、適切なタイミングでユーザに案内する仕組みが必要になる。
ところで、スマートフォンなどのタッチスクリーンを備える情報処理装置がゲームプログラムを実行する場合、タッチスクリーンにはゲームの画面が表示される。情報処理装置は、ゲームの画面上でユーザによる入力操作を受け付ける。ユーザは、タッチスクリーンに対して指などを近接させて操作する。このため、ユーザは、操作ボタンなどを備えた一般的なコントローラと比べると、感触で入力操作の状況を理解することができない。このような背景に鑑み、入力操作の操作状況をタッチスクリーンに表示することで、ユーザに操作状況を報知するシステムが存在する。上述したコンボシステムをタッチスクリーンで提供するゲームに採用した場合には、入力操作の報知とコンボ操作の案内とを適切に行う仕組みが必要になる。
本実施形態は、ユーザによる入力操作に応じてゲームのキャラクタを動作させるためにコンピュータによって実行される情報処理方法、情報処理装置、及び、情報処理プログラムに関連し、上述した課題の少なくとも1つを解決する。
[ゲーム提供システム]
本実施形態において、ユーザは、例えばスマートフォンなどの、タッチスクリーンを搭載した情報処理装置を操作する。ユーザは、ゲームサーバとスマートフォンとの間でゲームに関するデータを送受信させながらゲームを進行させる。
図1は、一実施形態のゲーム提供システムの構成を示す図である。図1に示されるように、ゲーム提供システム1は、ユーザにより使用される情報処理装置と、サーバ20とを含み、これらの装置がネットワーク80によって互いに通信可能に接続されている。
図1の例では、ユーザにより使用される情報処理装置として、携帯端末10A、携帯端末10B及び携帯端末10Cなど複数の携帯端末を示している。以下、携帯端末10A、10B、10Cなどの携帯端末を「携帯端末10」と総称することもある。携帯端末10A及び携帯端末10Bは、無線基地局81と通信することにより、ネットワーク80と接続する。携帯端末10Cは、家屋などの施設に設置される無線ルータ82と通信することにより、ネットワーク80と接続する。携帯端末10は、例えばタッチスクリーンを備える端末であり、一例として、スマートフォン、ファブレット、タブレットなどのコンピュータである。
携帯端末10は、ゲームプログラムを実行することにより、ゲームプログラムに応じたゲームをプレイする環境をユーザに対して提供する。携帯端末10には、例えば、アプリなどを配信するプラットフォームを介してゲームプログラムがインストールされる。携帯端末10は、携帯端末10にインストールされたゲームプログラム、又は、予めプリインストールされているゲームプログラムを実行することで、ユーザによるゲームのプレイを可能とする。携帯端末10は、ゲームプログラムを読み込んで実行することにより、サーバ20と通信接続し、ゲームの進行に応じてゲームに関連するデータをサーバ20と送受信する。
サーバ20は、ゲームのプレイに必要なデータを、適宜のタイミングで携帯端末10へ送信することで、携帯端末10でのゲームのプレイを進行させる。サーバ20は、ゲームをプレイする各ユーザの、ゲームに関連する各種データを管理する。サーバ20は、携帯端末10と通信し、各ユーザのゲームの進行に応じて、画像、音声、テキストデータ、その他のデータなどを携帯端末10へ送信する。
例えば、サーバ20は、各ユーザがゲームのストーリーを進行させた進行状況、ゲーム内に登場するキャラクタ(以下、「ゲームキャラクタ」ともいう。)のうち各ユーザが使用可能なゲームキャラクタの情報、ゲームキャラクタの能力を示すパラメータ、ゲームキャラクタが使用する道具の性能を示すパラメータ、その他の各種データなどを管理する。また、サーバ20は、ゲームの運営者によりユーザに対して行われるキャンペーン、ゲームの進行における不具合の発生、不具合の解消、その他のゲームの運営に関連する情報などをユーザに通知する処理を行う。
ゲームプログラムは、ユーザがゲームをプレイするモードとして、一人のユーザがプレイするシングルプレイと、複数人のユーザが協同してプレイするマルチプレイとに対応している。例えば、ゲーム提供システム1において、サーバ20は、マルチプレイに参加するユーザを特定して各ユーザの各携帯端末10と通信することなどにより、マルチプレイでゲームをプレイする環境を各ユーザに提供する。
ゲーム提供システム1は、マルチプレイに対応することにより、例えば、アクションゲームであれば、各ユーザでチームを結成して、クエストモードなど比較的強力なキャラクタと対戦するゲームモードを複数のユーザがプレイすることを可能とする。また、ゲーム提供システム1は、サッカーゲームであれば、各ユーザが同一のサッカーチームのメンバーとなって試合を行うことを可能とする。また、ゲーム提供システム1は、テニスゲームであれば、各ユーザでチームを結成してダブルスの試合を行うことを可能とする。
[構成]
サーバ20のハードウェアの構成を説明する。サーバ20は、通信IF(Interface)22と、入出力IF23と、メモリ25と、ストレージ26と、プロセッサ29とを備え、これらが通信バスを介して互いに接続する。
通信IF22は、通信機器であり、例えばLAN(Local Area Network)規格など各種の通信規格に対応しており、携帯端末10などの外部の通信機器との間でデータを送受信するためのインタフェースとして機能する。
入出力IF23は、インタフェース機器であり、サーバ20への情報の入力を受け付けるとともに、サーバ20の外部へ情報を出力するためのインタフェースとして機能する。入出力IF23は、マウス、キーボードなどの情報入力機器の接続を受け付ける入力受付部と、画像などを表示するためのディスプレイなどの情報出力機器の接続を受け付ける出力部とを含む。
メモリ25は、記憶装置であり、例えば、処理に使用されるデータなどを記憶するために用いられる。メモリ25は、例えば、プロセッサ29が処理を行う際に一時的に使用するための作業領域をプロセッサ29に提供する。メモリ25は、ROM(Read Only Memory)、RAM(Random Access Memory)などを含んで構成される。
ストレージ26は、記憶装置であり、例えば、プロセッサ29が読み込んで実行するための各種プログラム及びデータを記憶するために用いられる。ストレージ26が記憶する情報は、ゲームプログラム、ゲームプログラムに関連する情報、ゲームプログラムをプレイするユーザの情報、その他の情報を含む。ストレージ26は、例えば、HDD(Hard Disk Drive)、フラッシュメモリなどを含んで構成される。
プロセッサ29は、演算装置であり、ストレージ26に記憶されるプログラムなどを読み込んで実行することにより、サーバ20の動作を制御する。プロセッサ29は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、GPU(Graphics Processing Unit)などを含んで構成される。
図2は、携帯端末10の構成を示すブロック図である。図2に示されるように、携帯端末10は、アンテナ110と、無線通信IF120と、タッチスクリーン130と、入出力IF140と、記憶部150と、音声処理部160と、マイク170と、スピーカ180と、制御部190とを含む。
アンテナ110は、携帯端末10が発する信号を電波として空間へ放射する。また、アンテナ110は、空間から電波を受信して受信信号を無線通信IF120へ与える。
無線通信IF120は、携帯端末10が他の通信機器と通信するため、アンテナ110などを介して信号を送受信するための変復調処理などを行う。無線通信IF120は、チューナー、高周波回路などを含む無線通信用の通信モジュールであり、携帯端末10が送受信する無線信号の変復調や周波数変換を行い、受信信号を制御部190へ与える。
タッチスクリーン130は、ユーザからの入力操作を受け付けて、ユーザに対し情報をディスプレイ132に出力する。タッチスクリーン130は、ユーザの入力操作を受け付けるための部材であるタッチパネル131を含む。また、タッチスクリーン130は、メニュー画面や、ゲームの進行を画面に表示するための部材であるディスプレイ132を含む。タッチパネル131は、例えば、静電容量方式のものを用いることによって、ユーザの指などが接近したことを検出する。ディスプレイ132は、例えば、LCD(Liquid Crystal Display)、有機EL(electroluminescence)、その他の表示装置によって実現される。
入出力IF140は、インタフェース機器であり、携帯端末10への情報の入力を受け付けるとともに、携帯端末10の外部へ情報を出力するためのインタフェースとして機能する。
記憶部150は、記憶装置であり、フラッシュメモリ、RAM(Random Access Memory)などにより構成され、携帯端末10が使用するプログラム、携帯端末10がサーバ20から受信する各種データ、その他の各種データを記憶する。
音声処理部160は、演算装置であり、音声信号の変復調を行う。音声処理部160は、マイク170から与えられる信号を変調して、変調後の信号を制御部190へ与える。また、音声処理部160は、音声信号をスピーカ180へ与える。音声処理部160は、例えば、音声処理用のプロセッサによって実現される。マイク170は、音声信号の入力を受け付けて制御部190へ出力するための音声入力部として機能する。スピーカ180は、音声信号を、携帯端末10の外部へ出力するための音声出力部として機能する。
制御部190は、演算装置であり、記憶部150に記憶されるプログラムを読み込んで実行することにより、携帯端末10の動作を制御する。制御部190は、例えば、アプリケーションプロセッサによって実現される。
携帯端末10がゲームプログラム151を実行する処理について、より詳細に説明する。ある局面において、記憶部150は、ゲームプログラム151と、ゲーム情報152と、ユーザ情報153とを記憶する。携帯端末10は、例えば、サーバ20からゲームプログラムをダウンロードして記憶部150に記憶させる。また、携帯端末10は、ゲームの進行に伴いサーバ20と通信することで、ゲーム情報152及びユーザ情報153などの各種のデータをサーバ20と送受信する。
ゲームプログラム151は、携帯端末10においてゲームを進行させるためのプログラムである。ゲーム情報152は、ゲームプログラム151が参照する各種のデータを含む。ゲーム情報152は、例えば、ゲームにおいて仮想空間に配置されるオブジェクトの情報、オブジェクトに対応付けられた効果の情報(ゲームキャラクタに設定されるスキルの情報などを含む)基準モーションデータ、コンボデータなどを含む。基準モーションデータは、各ゲームキャラクタの動作を定義する。動作は、入力操作に対応付けて定義されてもよい。コンボデータは、所定の条件で発生するコンボによってゲームキャラクタに実行させる動作の内容(例えば、攻撃動作の種類、攻撃力、動きなど)を定義する。ユーザ情報153は、ゲームをプレイするユーザについての情報を含む。ユーザ情報153は、例えば、ゲームをプレイする携帯端末10のユーザを識別する情報、マルチプレイ時に協働してゲームをプレイする他のユーザを識別する情報、その他の情報を含む。その他の情報は、例えば、タッチパネル131の履歴データなどを含む。履歴データは、タッチパネル131の操作履歴である。
制御部190は、ゲームプログラム151を読み込んで実行することにより、入力操作受付部191と、ゲーム進行処理部192と、移動方向検出部193と、カメラ配置制御部194と、オブジェクト制御部195と、表示制御部196と、の各機能を発揮する。
入力操作受付部191は、タッチスクリーン130の出力に基づいて、ユーザの入力操作を受け付ける。具体的には、入力操作受付部191は、ユーザの指などがタッチパネル131に接近したことを、タッチスクリーン130を構成する面の横軸及び縦軸からなる座標系の座標として検出する。
入力操作受付部191は、タッチスクリーン130に対するユーザの操作を判別する。入力操作受付部191は、例えば、(1)「接近操作」、(2)「リリース操作」、(3)「タップ操作」、(4)「ダブルタップ操作」、(5)「長押し操作(ロングタッチ操作)」、(6)「ドラッグ操作(スワイプ操作)」、(7)「ムーブ操作」、(8)「フリック操作」、その他のユーザの操作を判別する。入力操作受付部191が判別するユーザの操作は、上記に限られない。例えば、タッチパネル131が、ユーザがタッチパネル131に対して押下する圧力の大きさを検出可能な機構を有する場合、入力操作受付部191は、ユーザにより押下された圧力の大きさを判別する。
(1)「接近操作」とは、ユーザが指などをタッチスクリーン130に接近させる操作である。タッチスクリーン130は、ユーザの指などが接近したこと(ユーザの指などがタッチスクリーン130に接触したことを含む)をタッチパネル131により検出し、検出したタッチスクリーン130の座標に応じた信号を制御部190へ出力する。制御部190は、タッチスクリーン130へのユーザの指などの接近を検出しない状態から、接近を検出したときに、状態が「タッチオン状態」になったと判別する。
(2)「リリース操作」とは、ユーザがタッチスクリーン130を接近操作している状態を止める操作である。入力操作受付部191は、例えば、ユーザが指などをタッチスクリーン130に接触させている状態から、指を離す操作をしたときに、ユーザの操作を「リリース操作」と判別する。制御部190は、タッチスクリーン130へのユーザの指などの接近を検出している状態から、接近を検出しない状態になったときに、状態が「タッチオン状態」から「タッチオフ状態」になったと判別する。
(3)「タップ操作」とは、ユーザがタッチスクリーン130に対して指などを接近させる接近操作をした後に、接近操作をした位置でリリース操作を行うことである。入力操作受付部191は、接近操作が検出されない状態(ユーザの指などがタッチパネル131から離れており、タッチパネル131がユーザの指などの接近を検出していない状態)から、タッチスクリーン130の出力に基づいて、ユーザの指などが接近したことを検出した場合に、その検出した座標を「初期タッチ位置」として保持する。入力操作受付部191は、初期タッチ位置の座標と、リリース操作をした座標とがほぼ同一である場合(接近操作が検出された座標から一定範囲内の座標においてリリース操作の座標が検出された場合)に、ユーザの操作を「タップ操作」と判別する。
(4)「ダブルタップ操作」とは、ユーザがタップ操作を一定時間内に2回行う操作である。入力操作受付部191は、例えば、ユーザの操作をタップ操作と判別してから一定時間内に、タップ操作にかかる座標で再びタップ操作を判別した場合に、ユーザの操作を「ダブルタップ操作」と判別する。
(5)「長押し操作」とは、ユーザがタッチスクリーン130を押し続ける操作である。タッチスクリーン130は、ユーザの操作を検出して接近操作を判別してから、接近操作が検出された座標において接近操作が継続している時間が一定時間を超えた場合に、ユーザの操作を「長押し操作」(「長押し操作」を、「ロングタッチ操作」と称することもある)と判別する。
(6)「ドラッグ操作」とは、ユーザがタッチスクリーン130に指などを接近させた接近状態を維持したまま、指をスライドさせる操作である。
(7)「ムーブ操作」とは、ユーザがタッチスクリーン130において、接近操作を維持しつつ、タッチスクリーン130に指などを接近させている位置を移動させてリリース操作を行う一連の操作をいう。
(8)「フリック操作」は、ユーザがムーブ操作を予め定められた時間よりも短い時間で行う操作をいう。フリック操作は、ユーザがタッチスクリーン130で指を弾くような操作である。
入力操作受付部191は、所定期間のユーザの入力操作の判別結果を記憶部150に操作履歴として記憶する。入力操作受付部191により行われる入力操作の種類を検知する詳細な処理は、後述する。
ゲーム進行処理部192は、ユーザの操作に応じて、各種のプログラムを呼び出すなどによりゲームを進行させる処理を行う。例えば、ゲーム進行処理部192は、サーバ20と通信し、ゲームの進行に応じてサーバ20へデータを送信する処理、サーバ20からゲームに関連するデータを受信する処理、ゲームの進行に応じてユーザに報酬を付与する処理、時間の経過を計測する処理、その他の処理を行う。
移動方向検出部193は、タッチスクリーン130に対するユーザの入力操作が移動操作である場合、ゲームに登場するキャラクタであるゲームキャラクタを移動させる入力操作の操作内容を検出する。移動操作とは、ゲームキャラクタの移動方向を指示する入力操作であり、方向性のある操作である。移動操作の一例としては、所定条件下のドラッグ操作又はフリック操作である。例えばゲームプログラム151がアクションゲームである場合、移動方向検出部193は、ユーザのドラッグ操作又はフリック操作に基づいて、ゲームキャラクタを移動させる方向を検出する。
具体的には、移動方向検出部193は、タッチスクリーン130からユーザの指が離れた状態から、ユーザが指をタッチスクリーン130に接近させて、入力操作受付部191がタッチパネル131にユーザの指が接近したことを検出した座標を初期タッチ位置として、ユーザがドラッグ操作を行った場合に、初期タッチ位置の座標とタッチスクリーン130の検出結果とに基づいて、ゲームキャラクタの移動方向を検出する。移動方向検出部193の詳細な処理は、後述する。
カメラ配置制御部194は、仮想空間に配置される各オブジェクトを、どのようにユーザに見せるかを決定する。具体的には、カメラ配置制御部194は、制御部190がゲームプログラム151を読み込んで実行することで生成される仮想空間において、仮想カメラの配置及び撮影方向(カメラワーク)を制御する。仮想カメラの配置及び撮影方向は、仮想空間の座標及び方向によって定義される。制御部190は、仮想空間における仮想カメラの撮影画像をディスプレイ132に表示することで、ユーザに対しゲームのプレイ環境を提供する。
オブジェクト制御部195は、携帯端末10がゲームプログラム151を実行することにより進行されるゲームに登場する各種オブジェクト、及び、入力操作受付部191が受け付けたユーザの操作内容に基づいて生成される各種オブジェクト(例えば、GUI(Graphical User Interface)画面など)の生成、変形、移動などの処理を制御する。オブジェクト制御部195は、例えば、タッチスクリーン130に対する入力操作に基づいて、ユーザの操作を示す操作オブジェクトを生成する。操作オブジェクトの詳細については後述する。
表示制御部196は、ディスプレイ132の表示を制御する。表示制御部196は、例えば、仮想カメラのカメラワークに従った画像をディスプレイ132に出力する。表示制御部196は、仮想空間内における仮想カメラの配置及び撮影方向に応じて、ディスプレイ132の表示内容を決定し、決定した表示内容に従う画像、テキストなどの各種の情報をディスプレイ132に出力する。
図3は、サーバ20の機能的な構成を示すブロック図である。図3を参照して、サーバ20の詳細な構成を説明する。サーバ20は、一般的なコンピュータとして構成され、プログラムに従って動作することにより、通信部220と、記憶部250と、制御部290としての機能を発揮する。
通信部220は、通信機器であり、サーバ20が携帯端末10などの外部の通信機器と通信するためのインタフェースとして機能する。
記憶部250は、記憶装置であり、携帯端末10においてユーザがゲームを進行させるための各種プログラム及びデータを記憶する。ある局面において、記憶部250は、ゲームプログラム251と、ゲーム情報252と、ユーザ情報253とを記憶する。
ゲームプログラム251は、サーバ20が携帯端末10と通信して、携帯端末10においてゲームを進行させるためのプログラムである。ゲームプログラム251は、ゲームを進行させるための各種データであるゲーム情報252及びユーザ情報253などを参照して、ユーザの入力操作に応じてゲームを進行させる。ゲームプログラム251は、制御部290に実行されることにより、携帯端末10とデータを送受信する処理、携帯端末10のユーザが行った操作内容に応じてゲームを進行させる処理、ゲームをプレイするユーザの情報を更新する処理、その他の処理をサーバ20に行わせる。
ゲーム情報252は、ゲームプログラム251が参照する各種のデータを含む。ゲーム情報252は、オブジェクト管理テーブル252Aと、パッシブスキル管理テーブル252Bと、アクティブスキル管理テーブル252Cとを含む。
オブジェクト管理テーブル252Aは、ゲームの仮想空間内に配置されるオブジェクトの設定を示す。携帯端末10は、ゲームプログラム151を実行することにより、仮想空間内に配置されるオブジェクトを、仮想空間内に配置される仮想カメラによって撮影された画像をディスプレイ132に表示させることでゲームを進行させる。
ここで、オブジェクトとしては、例えば、ユーザが操作するゲームキャラクタを示すオブジェクト、ゲームキャラクタが装着する対象物を示すオブジェクトなど様々なものがある。これらオブジェクトは、ユーザがタッチスクリーン130に対して予め定められた入力操作を行うこと、ゲームの進行に伴い一定の条件を満たすこと、その他の様々な事象の発生を契機として、オブジェクトに対応付けられた処理が行われる。
例えば、あるオブジェクトに対してユーザがタッチスクリーン130に対して接近操作を行うことで、オブジェクトがユーザに選択された状態となる。また、例えば、ユーザがタップ操作を行うことで、ユーザに選択されているオブジェクトがユーザの入力操作に応じて攻撃するなどの処理が行われる。また、例えば、ユーザがドラッグ操作を行うことで、ユーザに選択されているオブジェクトがユーザの入力操作に応じて移動するなどの処理が行われる。また、例えば、ユーザがオブジェクトに対してロングタッチ操作をすることで、ユーザに対し、ゲームを有利に進めるための報酬が付与されるなどの処理が行われる。
パッシブスキル管理テーブル252Bは、オブジェクトを識別する情報と、オブジェクトに対応付けられたパッシブスキルの情報とが対応付けられている。ここで、パッシブスキルとは、例えば、ゲームにおいて予め定められた条件が満たされたときに発動され、ユーザがゲームを有利に進行させることができるものである。例えば、パッシブスキルが発動した場合に、ゲームキャラクタの移動速度が向上するなどの、ゲームを有利に進行させられる効果を発揮させる。
アクティブスキル管理テーブル252Cは、オブジェクトを識別する情報と、オブジェクトに対応付けられたアクティブスキルの情報とが対応付けられている。ここで、アクティブスキルとは、例えば、ゲームにおいて予め定められた条件が満たされたときに発動可能な状態となり、ユーザから、スキルを発動させるための入力操作を受け付けることにより、ユーザがゲームを有利に進行させることができるものである。
ユーザ情報253は、ゲームをプレイするユーザについての情報である。ユーザ情報253は、ユーザ管理テーブル253Aを含む。ユーザ管理テーブル253Aは、各ユーザを識別する情報と、ユーザがゲームを進行させた度合いを示す情報と、ユーザがゲーム内で保有するアイテム、ゲームキャラクタ、ゲームキャラクタが使用する装着物などの情報その他の情報を含む。
制御部290は、記憶部250に記憶されるゲームプログラム251を実行することにより、送受信部291、サーバ処理部292、データ管理部293、マッチング部294、計測部295としての機能を発揮する。
送受信部291は、ゲームプログラム151を実行する携帯端末10から、各種情報を受信し、携帯端末10に対し、各種情報を送信する。携帯端末10とサーバ20とは、ユーザに関連付けられるオブジェクトを仮想空間に配置する要求、オブジェクトを削除する要求、オブジェクトを移動させる要求、ユーザが獲得する報酬に応じて各種パラメータを更新する要求、ゲームを進行させるための画像、音声その他のデータ、サーバ20から携帯端末10へ送信される通知などの情報を送受信する。
サーバ処理部292は、サーバ20全体の動作を制御し、各種のプログラムを呼び出すなどによりゲームの進行に必要な処理を行う。サーバ処理部292は、例えば、携帯端末10から受信した情報に基づいて、ゲーム情報252、ユーザ情報253などのデータを更新し、携帯端末10に各種データを送信することでゲームを進行させる。
データ管理部293は、サーバ処理部292の処理結果に従って、記憶部250に記憶される各種データを更新する処理、データベースにレコードを追加/更新/削除する処理などを行う。
マッチング部294は、複数のユーザを関連付けるための一連の処理を行う。マッチング部294は、例えば、ユーザがマルチプレイを行うための入力操作を行った場合に、ゲームを協同してプレイさせるユーザを関連付ける処理などを行う。
計測部295は、時間を計測する処理を行う。計測部295は、例えば、仮想空間に配置される各オブジェクトについて時間の経過を計測する。また、計測部295は、ゲームが進行している時間を計測する。サーバ20は、携帯端末10から、携帯端末10においてゲームプログラム151を実行して計測される各種の計測結果の情報を受信し、受信した情報と、計測部295の計測結果とを照合することで、携帯端末10とサーバ20とで、各種の時間に関する情報を同期させる。
[実施形態の構成のまとめ]
以上のように、実施形態のゲーム提供システム1の構成を説明してきた。本実施形態において、ゲームプログラム151は、例えばアクションゲームであり、仮想空間内の仮想カメラの配置及び撮影方向に応じた画像をタッチスクリーン130に表示させることでゲームを進行させる。
例えば、ゲームプログラム151がアクションゲームである場合、ゲーム進行処理部192は、ユーザの操作に応じてストーリーを進行させ、画像、テキストなどディスプレイ132に表示するデータを決定する処理、交戦相手又は仲間の選択をユーザから受け付ける処理、ユーザの操作に応じてアクションゲームを進める処理などの基本的な処理を行う。
例えば、ゲームプログラム151がアクションゲームである場合、カメラ配置制御部194は、アクションゲームを行うための仮想空間における仮想カメラの配置位置及び撮影方向を、アクションゲームの進展に応じて、逐次、決定する。カメラ配置制御部194は、仮想カメラのカメラワークを制御する。カメラ配置制御部194の詳細な処理は、後述する。
例えば、表示制御部196は、ゲームキャラクタを一定領域に表示させるよう仮想カメラを配置した状態で、ゲームキャラクタに第1の動作(例えば、移動動作)を行わせるための入力操作を受け付けて、受け付けた入力操作に応じてゲームキャラクタに第1の動作を行わせる画面表示をする。
[動作]
図面を参照して、実施形態のゲーム提供システム1を構成する各装置の動作を説明する。
(入力操作の検知)
図4は、入力操作受付部191が入力操作の種類を検知する処理を説明する図である。
図4の例では、ユーザ情報153を記憶する記憶部150の配列fp[0]〜配列fp[10]までの11個の配列のそれぞれに、タッチパネル131により検知されたタッチスクリーン130上の位置を示す履歴情報が格納されている。履歴情報は、所定の期間毎(例えば、フレームレート毎)に履歴情報テーブルに格納される。履歴情報が格納される配列の個数は限定されず、任意の個数であってよい。また、履歴情報テーブルでは、タッチオフからタッチオンになった場合に検知された履歴情報を、初期位置座標として記憶部150に記憶してもよい。
図4に示されるように、例えば、配列fp[0]〜配列fp[9]に、履歴情報(x0、y0)が格納されており、配列fp[10]にnull値が格納された場合、入力操作受付部191は、入力操作はタップ操作であると判別する。また、例えば、タッチナウ状態において履歴情報が変化した後に、null値が格納された場合、入力操作受付部191はnull値が格納された配列fp[5]の直前の配列fp[3]および配列fp[4]に格納されている履歴情報を参照する。そして、入力操作受付部191は、配列fp[3]および配列fp[4]の履歴情報がそれぞれ示す位置の間の距離が予め設定された閾値以上である場合、入力操作はフリック操作であると判別する。また、入力操作受付部191は、タッチナウ状態において履歴情報が変化した後に、例えば配列fp[4]〜fp[10]に履歴情報(x15、y15)が格納された場合、入力操作はドラッグ操作であると判別する。
(移動方向の検知)
図5は、移動方向検出部193がユーザの入力操作に応じてゲームキャラクタを移動させる方向を検出する処理を説明する図である。移動方向検出部193は、ユーザがタッチスクリーン130を押していない状態から、指などをタッチパネル131に接近させてタッチスクリーン130を押した位置(初期タッチ位置)を起点と設定する。入力操作受付部191は、ユーザの操作をドラッグ操作と判別している場合に、起点となる座標と、タッチスクリーン130がユーザの指などの接近を検出している座標とに基づいて、ゲームキャラクタを移動させる方向を検出する。
図5の状態(A)は、タッチスクリーン130からユーザの指が離れた状態から、ユーザが指をタッチスクリーン130に接近させた状態を示す。入力操作受付部191は、ユーザの指がタッチパネル131に接近したことを検出し、検出した座標を初期タッチ位置として記憶部150にユーザ情報153として保持する。
図5の例では、記憶部150が保持する初期タッチ位置の座標を、初期タッチ位置座標155として示す。入力操作受付部191は、タッチスクリーン130の検出結果(ユーザの指がタッチスクリーン130に接近している座標、及び、ユーザの指がタッチスクリーン130に接近していることを検出していないこと(検出結果「null」))を、一定フレーム分、ユーザ情報153としてバッファメモリに格納する。バッファメモリは、タッチスクリーン130における検出結果を、各フレームについて一定フレーム分(図5の例では、配列fp〔0〕〜配列fp〔10〕までの11フレーム分)、格納することができる。バッファメモリは、例えばリングバッファとして実現することができる。
図5の状態(A)の例では、ユーザがタッチスクリーン130を押した位置を、押下位置30A(タッチスクリーン130の座標(x0,y0))として示す。
図5の状態(B)は、ユーザがタッチスクリーン130に対してドラッグ操作を行って、タッチスクリーン130に対する押下位置を、押下位置30Aから押下位置30B(タッチスクリーン130の座標(x9,y9))まで10フレーム(配列fp〔0〕〜配列fp〔9〕までの10フレーム分)で移動させたことを示す。入力操作受付部191は、タッチスクリーン130の検出結果をユーザ情報153としてバッファメモリに格納し、バッファメモリに保持される値を参照して、タッチスクリーン130に対するユーザの操作をドラッグ操作と判別する。
図5の状態(C)は、ユーザがタッチスクリーン130を押している位置を、押下位置30Bから押下位置30C(タッチスクリーン130の座標(x14,y14))まで、5フレーム(配列fp〔10〕、fp〔0〕、fp〔1〕、fp〔2〕、fp〔3〕の5フレーム分)で移動させたことを示す。
図5の状態(D)は、移動方向検出部193が、状態(B)及び状態(C)のそれぞれにおいて、ユーザがゲームキャラクタを移動させる方向を指定する入力操作の検出結果を示す。移動方向検出部193は、バッファメモリにおいて、タッチスクリーン130が検出する押下位置の座標を書き込む対象となるメモリ領域がいずれであるかを示す情報(バッファメモリの書き込み位置)を管理している。
図5の状態(B)において、移動方向検出部193は、入力操作受付部191の判別結果に基づいて、初期タッチ位置を示す座標31A(座標(x0,y0))から座標31B(座標(x9,y9))までユーザがドラッグ操作を行ったことを検出する。移動方向検出部193は、初期タッチ位置の座標31Aを起点として、座標31Aと座標31Bとによって規定されるベクトル32B((y9−y0)/(x9−x0))を、ゲームキャラクタを移動させる方向として検出する。
図5の状態(C)において、移動方向検出部193は、入力操作受付部191の判別結果に基づいて、座標31B(座標(x9,y9))から座標31C(座標(x14,y14))までユーザがドラッグ操作を行ったことを検出する。移動方向検出部193は、初期タッチ位置の座標31Aを起点として、座標31Aと座標31Cとによって規定されるベクトル32C((y14−y0)/(x14−x0))を、ゲームキャラクタを移動させる方向として検出する。
このように、移動方向検出部193は、ユーザの指が接近していない状態からタッチスクリーン130に接近したことを検出した第1のタッチ位置から、接近していることを検出したまま第2のタッチ位置へ検出位置が移動した場合に、接近していることを検出している間、第1のタッチ位置を起点とし第2のタッチ位置へ向かう方向である操作方向を、ゲームキャラクタCA1の仮想空間における移動方向として決定する。
(操作オブジェクト)
図6はドラッグ操作時に表示されるオブジェクトの一例である。ユーザの入力済みの入力操作を示すオブジェクトを操作オブジェクトという。図6の状態(A)は、ドラッグ操作の初期タッチ位置に表示されるオブジェクトの一例である。図6の状態(A)に示されるように、操作オブジェクト400は、固定円410、および当該固定円410の内部に位置する弾性表示オブジェクト420を備えている。操作オブジェクト400は、ユーザの指がタッチスクリーン130に接近したことが検知されるとタッチスクリーン130に表示される。弾性表示オブジェクト420は、指接触時の初期形状として、タッチ位置の周囲に円形を有するように形成される。なお、図6では、弾性表示オブジェクト420は、タッチ位置を中心に円形を形成しているが、必ずしもこれに限定されない。例えば、弾性表示オブジェクト420は、初期タッチ位置から一定距離だけ上部または下部にずらして表示してもよい。表示位置を一定距離だけずらすことにより、円形の弾性表示オブジェクト420を表示する際に、ユーザの指で隠れてしまうのを防止することができる。
図6の状態(B)は、初期タッチ位置からドラッグ操作したときに表示されるオブジェクトの一例である。図6の状態(B)に示されるように、ユーザがタッチスクリーン130上でドラッグ操作(タッチスクリーン130上において指を第1のタッチ位置から第2のタッチ位置に移動させる操作)を行うと、ユーザの指に引っ張られるような弾性変形をした弾性表示オブジェクト420が表示される。弾性表示オブジェクト420は、ドラッグ操作の第1のタッチ位置に位置しその位置が固定されている基部430と、ドラッグ操作の第2のタッチ位置付近に位置する先端部450と、基部430と先端部450との間を接続する接続部440とを含むように構成される。このように、弾性表示オブジェクト420は、ドラッグ操作がされた方向に弾性的に延ばすように表示される。なお、図6の状態(B)では、基部430が先端部450よりも大きくなるように弾性表示オブジェクト420を表示しているが、これに限定されない。例えば、先端部450を基部430よりも大きくした弾性表示オブジェクト420を表示してもよい。また、ユーザが指を接触状態に維持しつつタッチスクリーン130上を更に移動させた場合、先端部450もそれに追従して更に移動し、弾性表示オブジェクト420の延びる向きも変化する。
図6の状態(C)は、ユーザの指がタッチスクリーン130から離れたときに表示されるオブジェクトの一例である。図6の状態(C)に示されるように、ユーザによるドラッグ操作が終了した際に(即ち、タッチスクリーン130からユーザの指が離れた際に)、弾性変形した弾性表示オブジェクト420が、その復元力に従って、接触開始点に向けて段階的に萎縮することにより、図6の状態(A)に示される初期形状に復元するように表示される。この際、図示されるように、復元力の反動により弾性表示オブジェクト420の伸張方向とは逆の萎縮方向において固定円410からはみ出すように表示され、その後に初期形状に復元する。なお、図示された弾性表示オブジェクト420は復元に伴って変形しているが、これに限定されない。例えば、このような変形を行わずに弾性表示オブジェクト420を初期形状に復元させ、弾性表示オブジェクト420の位置を伸張方向とは逆の萎縮方向に震わせるようにずらすこととしてもよい。
図7はドラッグ操作時に表示されるオブジェクトの一例である。図7の状態(A)は、弾性表示オブジェクトの画像例である。図7の状態(A)に示めされるように、弾性表示オブジェクトは略正方形状の画像750として生成され、ゲーム画像の一部として重畳される。画像750は、半透明領域760および透明領域770を含む。半透明領域760は弾性表示オブジェクトの基本表示領域である。
図7の状態(A)は、状態(B)に示されるように、略正方形のメッシュ領域に収容され、複数のメッシュ710に分割されたポリゴンとして形成される。一例として、画像750は、4×4=16メッシュに分割され、弾性オブジェクトを収容している。メッシュに分割する数は限定的でないことが当業者に理解される。そして、弾性表示オブジェクトの変形は、画像750をゴムシートの如く伸張する処理、特に、メッシュ毎に伸張する物理演算処理を仮想的に実施することにより実現される。
図8は、ドラッグ操作時に表示されるオブジェクトの変形を説明する図である。図8の状態(A)及び状態(B)に示されるように、弾性表示オブジェクトは、複数のメッシュ710に分割された板状のポリゴン700の各頂点720の座標を動かすことによって弾性変形を表現する。各頂点720はメッシュ状に配置されており、任意の頂点720Aの座標がドラッグ操作によって移動された場合、その他の頂点720も頂点720Aに関する移動ベクトル(例えば、移動方向および移動距離)に応じて座標が変更される。例えば、頂点720A以外の頂点720の移動距離は、頂点720Aからの距離によって重み付けをしてもよい。即ち、図8の状態(B)に示されるように、頂点720Aからの距離が大きくなるにつれて(頂点720Aから離れるにつれて)座標の変化量が小さくなるようにしてもよい。なお、図8の状態(B)における白丸は、変形前の(即ち、図8の状態(A)の)頂点の位置を表している。
これにより、図7の状態(C)に示されるように、ドラッグ操作の方向に沿ってタッチの開始点からタッチの終了点に向けて伸張させることにより、変形した弾性オブジェクト420a’を形成する。図7の状態(C)の例では、分割された複数のメッシュの各頂点の座標が移動した際に、当該複数のメッシュの各々は、列(#1〜#4)ごとに同一の長方形状を維持したまま(例えばメッシュ#1A〜#1Dは全て同一の長方形状を有している。)、タッチの終了点に近い列(#1)のメッシュほど、遠い列(#4)のメッシュと比べて累進的に長く伸張される。一例として、ドラッグ操作による移動距離Lに応じて、各列の伸張率を加重配分するように構成されてもよい。
図7の状態(C)の例では、各列について、#4が10%、#3が15%、#2が30%、#1が45%となるように配分されている(合計で100%)。更に例えば移動距離を2Lとした場合には、#4が1%、#3が4%、#2が35%、#1が60%といった具合に#1を更に大きくするように加重配分されてもよい。
図9は、オブジェクトの変形時おけるポリゴン方向調整処理を説明する図である。図9の状態(A)及び状態(B)に示されるように、ポリゴンの方向が操作方向となるように、ポリゴンの回転による調整処理(ポリゴン方向調整処理)が実施される。当該ポリゴン方向調整処理が実施されることにより、変形されたオブジェクトは、ドラッグ操作時の指の移動距離に拘わらず、ドラッグ操作方向に対して常に一定の幅を有して変形可能となる。オブジェクトは、常に一定の幅を有するように構成可能な点、および初期タッチ位置から継続するタッチ位置に向けて伸張してオブジェクトを変形することにより、非常に滑らかな曲線形状を有することが可能となる点において、従来技術と異なる表示とすることができる。
図10は、オブジェクトの変形後にタッチ位置が更新された場合について示す模式図である。図10の状態(A)及び状態(B)に示されるように、ユーザが接触終了点1(状態(A))から指を離すことなく、更に他の接触終了点2(状態(B))まで指をタッチスクリーン130に接触させながら移動させた場合には、継続してオブジェクトを変形させる。即ち、ドラッグ操作における接触開始点に対する、接触終了点1と接触終了点2の間の角度だけポリゴンの方向を回転させて、変形した弾性オブジェクト420a’を回転し、次いで、当該回転した弾性オブジェクトの形状を引き続き接触終了点2まで伸張して、更に変形した弾性オブジェクト420a’’を形成する。
(仮想カメラの制御)
図11は、カメラ配置制御部194が仮想カメラVCを制御する処理を説明する図である。図11では、仮想カメラVCがゲームキャラクタCA1を背後から追尾するカメラワークを説明する。図11の状態(A)では、ゲームキャラクタCA1が方向D1(移動方向)に向かって移動する様子が示されている。例えば、入力操作受付部191がユーザによる入力操作をドラッグ操作と判定し、移動方向検出部193がゲームキャラクタCA1の移動方向を方向D1と検出したとき、オブジェクト制御部195は、ゲームキャラクタCA1の正面を方向D1に向け、ゲームキャラクタCA1を方向D1へ移動させる。カメラ配置制御部194は、ゲームキャラクタCA1の背後から追尾するように、仮想カメラVCの配置位置及び撮影方向を制御する。ゲームキャラクタCA1の背後から追尾する場合、カメラ配置制御部194は、撮影方向DVとゲームキャラクタCA1の向き(方向D1)とがなす角度θ1(対応関係)は0°となる。カメラ配置制御部194は、カメラ視界の中央付近にゲームキャラクタCA1が表示されるように、仮想カメラVCを配置する。
図11の状態(B)では、ユーザによるドラッグ操作により移動方向が方向D1から方向D2へ変更された様子を示す。この場合、オブジェクト制御部195は、ゲームキャラクタCA1の正面を方向D2に向け、ゲームキャラクタCA1を方向D2へ移動させる。このとき、カメラ配置制御部194は、撮影方向DVとゲームキャラクタCA1の向き(方向D1)とがなす角度θ1(対応関係)が0°となるように、仮想カメラVCの配置位置及び撮影方向DVを変更する。なお、カメラ配置制御部194は、変化前後の移動方向の変化角度θ2を検出し、検出された変化角度θ2を仮想カメラVCの変化角度θ3としてもよい。
このように、カメラ配置制御部194は、ユーザによる入力操作に応じて移動方向が変化するゲームキャラクタCA1を背後から追尾するようなカメラワークを提供する。
(移動操作時の画面例)
図12は、ユーザによる入力操作に応じて変化するカメラワーク及び操作オブジェクトを説明する図である。画面例(A)〜画面例(C)は、タッチスクリーン130に表示された画像である。画面例(A)〜画面例(C)では、表示制御部196が、カメラ配置制御部194によりゲームキャラクタCA1の背後から撮影された画像を、タッチスクリーン130に表示させている。入力操作受付部191によりユーザによる入力操作が受け付けられたとき、オブジェクト制御部195は、ユーザの入力操作に応じて操作オブジェクトを生成する。表示制御部196は、仮想カメラVCにより撮影された画像上に操作オブジェクトを重畳させて、タッチスクリーン130に表示させる。
図12の画面例(A)は、ユーザがタッチスクリーン130に指などを接近させた操作をしたときの画面の一例である。入力操作受付部191によりユーザがタッチスクリーン130の第1位置300Aに指などを接近させた操作をしたと判定されたとき、オブジェクト制御部195は、入力操作に応答して円形の操作オブジェクト300を生成する。表示制御部196は、生成された円形の操作オブジェクト300をタッチ位置である第1位置300Aに表示させる。図12の画面例(A)では、撮影方向を方向VD1、ゲームキャラクタCA1の向きを方向CD1で示している。撮影方向である方向VD1とゲームキャラクタCA1の向きである方向CD1の対応関係(なす角度)は0°である。
図12の画面例(B)は、図12の画面例(A)の第1位置300Aを起点としてユーザがドラッグ操作をしたときの画面の一例である。入力操作受付部191は、起点である第1位置300Aから終点である第2位置300Bまでのドラッグ操作を受け付ける。入力操作受付部191によりドラッグ操作が受け付けられた場合、オブジェクト制御部195は、ドラッグ操作の操作結果を示す操作オブジェクト300を生成する。ドラッグ操作の操作結果を示す操作オブジェクト300は、ドラッグ操作の起点となる位置と終点となる位置とを関連付けることで、操作結果(例えば操作方向)を表現する。図12の画面例(B)の例では、オブジェクト制御部195は、起点及び終点に対応する位置に操作オブジェクト300の端部がそれぞれ位置するように、第1位置300Aから第2位置300Bに至るまで引き延ばされた操作オブジェクト300を生成している。表示制御部196は、引き延ばされた操作オブジェクト300をタッチスクリーン130に表示させる。この状態における操作方向及び撮影方向が図示されている。操作方向は方向SD1(図中右上方向)であり、撮影方向は方向VD1(図中上方向)である。方向SD1と方向VD1とのなす角はθ4である。
さらに、移動方向検出部193は、ドラッグ操作が受け付けられた場合、ゲームキャラクタCA1の移動方向を、操作方向である方向SD1と同一の方向に決定する。オブジェクト制御部195は、ゲームキャラクタCA1を移動方向に向け、移動を開始させる。
図12の画面例(B)においてゲームキャラクタCA1の向きが変更されると、カメラ配置制御部194は、ゲームキャラクタCA1の背後を追尾するように仮想カメラVCの配置位置及び撮影方向を制御する。具体的には、方向SD1と方向VD1とのなす角であるθ4分だけ、撮影方向が注視点(ゲームキャラクタCA1)を中心として右回転する。さらに、仮想カメラVCの配置位置は、ゲームキャラクタCA1又は移動目的地が画面の中央にくるように制御される。これにより、タッチスクリーン130に表示される画像は、画面例(B)から画面例(C)へ遷移する。
このように、ユーザによる入力操作に応じてゲームキャラクタを背後から追尾するカメラワークが実行されるため、臨場感のあるゲームが提供される。また、操作方向が画面上に示されることにより、ユーザにとって理解し易いゲームが提供される。
(移動操作時のフローチャート)
図13は、移動操作時の処理を説明するフローチャートである。図13のフローチャートは、制御部190がゲームプログラム151を実行することによりアクションゲームを進行させる処理を示すフローチャートである。
ステップS10において、制御部190は、入力操作が受け付けられたか否かを判定する。
入力操作が受け付けられたと判定されると(ステップS10:YES)、ステップS12において、制御部190は、初期タッチ位置に操作オブジェクトを表示させる(図12の画面例(A)に対応する)。オブジェクト制御部195は、入力操作に応答して円形の操作オブジェクト300を生成する。表示制御部196は、生成された円形の操作オブジェクト300をタッチ位置である第1位置300Aに表示させる。初期タッチ位置は、操作方向を決定する起点(操作オブジェクトの端部位置)の初期値となる。
ステップS14において、制御部190は、入力操作がドラッグ操作であるか否かを判定する。制御部190は、タッチスクリーン130の履歴情報を用いて、ドラッグ操作であるか否かを判定する(図4参照)。
入力操作がドラッグ操作であると判定されると(ステップS14:YES)、ステップS16において、制御部190は、起点(第1位置300A)からドラッグ方向(方向SD1)へ伸びる操作オブジェクト300を表示させる(図12の画面例(B)に対応する)。制御部190は、タッチスクリーン130の履歴情報を用いて、操作オブジェクト300を生成して、タッチスクリーン130に表示させる。
ステップS18において、制御部190は、タッチスクリーン130の履歴情報を用いて、ドラッグ操作のドラッグ方向(方向SD1)を検出する(図5参照)。そして、制御部190は、ドラッグ方向(方向SD1)に基づいてゲームキャラクタCA1の移動方向及びゲームキャラクタCA1の向きを決定する。そして、制御部190は、移動方向に従ってゲームキャラクタCA1をドラッグ方向(方向SD1)へ移動させる(図12の画面例(B)に対応する)。さらに、制御部190は、仮想カメラVCの撮影方向をゲームキャラクタCA1の向きと一致させる(図12の画面例(C)に対応する)。
ステップS20において、制御部190は、ドラッグ操作が完了したか否かを判定する。ドラッグ操作が完了していないと判定されると(ステップS20:NO)、制御部190は、上述したステップS16及びステップS18を再実行する。これにより、ユーザの指が接近していることをタッチスクリーン130が検出している間、つまり、ドラグ操作が継続されている間、操作オブジェクトが表示され、ゲームキャラクタCA1が移動することになる。
ドラッグ操作が完了したと判定されると(ステップS20:YES)、ステップS22として、制御部190は、ゲームキャラクタCA1の移動を終了する。そして、ステップS24として、制御部190は、操作オブジェクト300の表示を終了する。
一方、入力操作がドラッグ操作でないと判定されると(ステップS14:NO)、ステップS26において、制御部190は、入力操作に応じた動作をゲームキャラクタCA1に実行させる。例えば、タップ操作であれば、攻撃対象を決定し、ゲームキャラクタCA1に攻撃動作を実行させる。そして、ステップS24として、制御部190は、操作オブジェクト300の表示を終了する。
入力操作が受け付けられていないと判定された場合(ステップS10:NO)、又は、操作オブジェクト300の表示を終了すると、図13に示されるフローチャートは終了する。そして、制御部190は、所定の条件が満たされるまで図13に示されるフローチャートを最初から実行する。以上で、移動操作時の一連の処理が終了する。
(交戦時のカメラワークの概要)
一般的なアクションゲームにおいては、ゲームキャラクタCA1が仮想空間のフィールドを移動するシーンだけでなく、仮想空間に配置された敵キャラクタ(対象キャラクタの一例)と交戦するシーンが存在する。
ユーザは、シーンに応じて、仮想空間においてキャラクタを移動させる移動操作だけでなく、ゲームキャラクタCA1に攻撃動作を行わせる攻撃動作を入力する。移動操作は、上述のとおり、ゲームキャラクタの移動方向を指示する入力操作であり、方向性のある操作である。移動操作の一例としては、所定条件下のドラッグ操作又はフリック操作である。一方、攻撃操作は、ゲームキャラクタCA1に攻撃動作を行わせる入力操作である。基本的な攻撃操作の一例としては、タップ操作である。なお、攻撃操作には、タップ操作と組み合わされたフリック操作を含む。詳細については後述する。
カメラ配置制御部194は、ユーザによる入力操作に応じて移動方向が変化するゲームキャラクタCA1を背後から追尾するようなカメラワークを提供する。つまり、カメラ配置制御部194が仮想カメラVCの撮影方向を変更する契機(トリガ)は、ユーザによる移動操作である。ここで、カメラ配置制御部194は、仮想カメラVCの撮影方向を変更する契機(トリガ)として攻撃操作をさらに含む。これにより、敵キャラクタとの交戦時において、臨場感、迫力、キャラクタとの一体感などを演出するためのカメラワークを瞬時に提供することができる。
(交戦時の画面例)
図14は、交戦時における仮想カメラVCの撮影方向を説明するための画面例である。図14の画面例(A)〜画面例(D)は、タッチスクリーン130に表示された画像である。画面例(A)〜画面例(D)では、表示制御部196が、カメラ配置制御部194により、ゲームキャラクタCA1を撮影した画像を、タッチスクリーン130に表示させている。入力操作受付部191によりユーザによる入力操作が受け付けられたとき、オブジェクト制御部195は、ユーザの入力操作に応じて操作オブジェクトを生成する。表示制御部196は、仮想カメラVCにより撮影された画像上に操作オブジェクトを重畳させて、タッチスクリーン130に表示させる。
図14の画面例(A)は、移動操作時において敵キャラクタCA2が視界に入ったときの画面の一例である。図14の画面例(A)では、撮影方向を方向VD1、ゲームキャラクタCA1の向きを方向D3で示している。
図14の画面例(B)は、図14の画面例(A)の状況において、攻撃操作であるタップ操作が行われたときの画面の一例である。オブジェクト制御部195は、タップ操作に応答して円形の操作オブジェクト300を生成する。表示制御部196は、生成された円形の操作オブジェクト300をタッチ位置に表示させる。このとき、敵キャラクタCA2とゲームキャラクタCA1との距離が予め定められた距離内にある場合、敵キャラクタCA2を攻撃対象として決定する(ロックオン)。ゲームキャラクタCA1は、ロックオンされた敵キャラクタCA2の方向D4へ向けられる。カメラ配置制御部194は、仮想カメラVCがゲームキャラクタCA1を背後から撮影するように、仮想カメラVCを制御する。仮想カメラVCの撮影方向は、ゲームキャラクタCA1の向きである方向D4と同一方向である方向VD2へ変更される。これにより、タッチスクリーン130に表示される画像は、図14の画面例(B)は図14の画面例(C)へ遷移する。
図14の画面例(C)は、攻撃操作に応じて仮想カメラVCの撮影方向が変更されたときの画面の一例である。そして、図14の画面例(D)は、敵キャラクタに対して攻撃操作を実行しているときの画面の一例である。このように、タップ操作という方向性の無い操作がなされた場合であっても、仮想カメラVCの撮影方向が変更され、臨場感のある交戦画面が提供される。
(攻撃操作時のフローチャート)
図15は、攻撃操作時の処理を説明するフローチャートである。図15のフローチャートは、制御部190がゲームプログラム151を実行することによりアクションゲームを進行させる処理を示すフローチャートである。
ステップS30において、制御部190は、入力操作が受け付けられたか否かを判定する。制御部190は、入力操作として、仮想空間においてゲームキャラクタCA1を移動させる移動操作及びゲームキャラクタCA1に攻撃動作を行わせる攻撃操作を受け付けることができる。
入力操作が受け付けられたと判定されると(ステップS30:YES)、ステップS32において、制御部190は、初期タッチ位置に操作オブジェクトを表示させる(図14の画面例(B)に対応する)。オブジェクト制御部195は、入力操作に応答して円形の操作オブジェクト300を生成する。表示制御部196は、生成された円形の操作オブジェクト300をタッチ位置に表示させる。
ステップS34において、制御部190は、入力操作がタップ操作であるか否かを判定する。制御部190は、タッチスクリーン130の履歴情報を用いて、タップ操作であるか否かを判定する(図4参照)。
入力操作がタップ操作であると判定されると(ステップS34:YES)、ステップS36において、制御部190は、攻撃範囲内に敵キャラクタが存在するか否かを判定する。攻撃範囲は、ゲームキャラクタCA1を基準として予め設定される。
攻撃範囲内に敵キャラクタが存在すると判定されると(ステップS36:YES)、ステップS38において、制御部190は、攻撃対象となる敵キャラクタを特定する。制御部190は、攻撃範囲内に複数の敵キャラクタが存在する場合には、例えばゲームキャラクタCA1に最も近接した敵キャラクタを攻撃対象にする。
ステップS40として、制御部190は、ゲームキャラクタCA1を攻撃動作の対象となる敵キャラクタCA2の位置と、ゲームキャラクタCA1の位置とに基づいて、ゲームキャラクタCA1を敵キャラクタCA2に向けさせる(図14の画面例(B)に対応する)。
ステップS42として、制御部190は、仮想カメラVCの撮影方向をゲームキャラクタCA1の向きに基づいて決定する。制御部190は、ゲームキャラクタCA1の向きに対して予め定められた方向からキャラクタを撮影するように制御する。ゲームキャラクタCA1の向きに対して予め定められた方向とは、例えば、ゲームキャラクタCA1の背後から撮影する方向、ゲームキャラクタCA1の横から撮影する方向、ゲームキャラクタCA1の上から撮影する方向などである。具体的な一例として、制御部190は、仮想カメラVCの撮影方向をゲームキャラクタCA1の向きと一致させ、ゲームキャラクタCA1の背後から撮影するように、仮想カメラVCを制御する(図14の画面例(C)に対応する)。
ステップS44として、制御部190は、ゲームキャラクタCA1に攻撃動作を実行させる(図14の画面例(D)に対応する)。ステップS46として、制御部190は、操作オブジェクト300の表示を終了する。
一方、入力操作がタップ操作でないと判定されると(ステップS34:NO)、ステップS48において、制御部190は、入力操作に応じた動作をゲームキャラクタCA1に実行させる。このとき、入力操作がドラッグ操作などの移動操作であれば、制御部190は、図13で説明したとおり、ゲームキャラクタCA1を移動させるとともに、仮想空間を移動するゲームキャラクタCA1を追尾するように仮想カメラVCを制御する。そして、ステップS46として、制御部190は、操作オブジェクト300の表示を終了する。
また、攻撃範囲内に敵キャラクタが存在しないと判定されると(ステップS36:NO)、ステップS46として、制御部190は、操作オブジェクト300の表示を終了する。
入力操作が受け付けられていないと判定された場合(ステップS30:NO)、又は、操作オブジェクト300の表示を終了すると、図15に示されるフローチャートは終了する。そして、制御部190は、所定の条件が満たされるまで図15に示されるフローチャートを最初から実行する。以上で、攻撃操作時の一連の処理が終了する。
(交戦時における連撃攻撃)
アクションゲームにおいては、予め定められた期間内に攻撃操作を連続して受け付けた場合、連撃攻撃(いわゆるコンボ攻撃)を発生させることがある。このようなコンボ攻撃の内容は、ゲーム情報152又はゲーム情報252にコンボデータとして定義されている。コンボ攻撃に多様性を持たせるために、コンボ攻撃中の攻撃操作に方向性のある入力操作を採用することがある。例えば、タップ操作、タップ操作、フリック操作という一連の入力操作に基づくコンボ攻撃である。
図16は、オブジェクト制御部195がコンボデータに基づいてゲームキャラクタCA1に攻撃動作を実行させたときのアクション(モーションともいう)の一例を示す図である。図16の状態(A)は、アクションa1を示す。図16の状態(B)は、アクションa2を示す。図16の状態(C)は、アクションa3を示す。入力操作受付部191がタップ操作を受け付けると、オブジェクト制御部195は、図16の状態(A)に示されるように、ゲームキャラクタCA1にアクションa1を実行させる。続いて、入力操作受付部191が予め定められた期間内に再びタップ操作を受け付けると、オブジェクト制御部195は、図16の状態(B)に示すアクションa2をゲームキャラクタCA1に実行させる。続いて、入力操作受付部191が予め定められた期間内にフリック操作を受け付けると、オブジェクト制御部195は、図16の状態(C)に示すアクションa3をゲームキャラクタCA1に実行させる。アクションa3は、アクションa1、a2より演出を派手にしたり、攻撃力を大きくしたりするように設定してもよい。また、アクションa3のためのフリック操作の代わりに、タップ操作が3回続けられることによって、オブジェクト制御部195は、他の演出が派手であったり攻撃力が大きかったりするアクションをゲームキャラクタCA1に実行させてもよい。一実施形態によれば、タッチスクリーン130によるタッチ操作でコンボ攻撃をゲームキャラクタCA1に実行させるゲームであっても、コンボの流れを分岐させることができる。このように、コンボ攻撃中の攻撃操作に方向性のある入力操作を採用することで、ユーザは多様な操作によって次々と流れるようにゲームキャラクタCA1に攻撃させることができる。よって、ゲームの趣向性が向上する。
(連撃攻撃時のカメラワーク)
連撃攻撃時においても、制御部190は、図15に示された攻撃操作時のフローチャートに沿って処理を実行する。入力操作が連撃攻撃の最初の攻撃操作であるか否かは、2回目の攻撃操作が入力されることによって初めて確定する。したがって、タップ操作が通常のタップ操作であるか連撃操作となるかに関わらず、制御部190は、図15に示された攻撃操作時のフローチャートに沿って処理を実行する。つまり、制御部190は、事後的に連撃操作となる最初のタップ操作に応じて、図15に示された攻撃操作時のフローチャートに沿って処理を実行する。
このため、ステップS40として、制御部190は、所定期間内に連続する攻撃操作が受け付けられた場合、所定期間内に連続する攻撃操作のうち最初の攻撃動作の対象となる敵キャラクタCA2にゲームキャラクタCA1を向かせることになる。そして、ステップS42として、制御部190は、予め定められた方向からゲームキャラクタCA1を撮影するように仮想カメラVCを制御する。
そして、制御部190は、2回目以降のタップ操作が行われた場合、所定期間前にタップ操作が行われていたか否かを判定する。制御部190は、所定期間前にタップ操作が行われていない場合、2回目のタップ操作については、図15に示された攻撃操作時のフローチャートに沿って処理を実行する。この場合、制御部190は、2回目のタップ操作によって攻撃対象となる敵キャラクタCA2にゲームキャラクタCA1を向かせることになる。そして、ステップS42として、制御部190は、予め定められた方向からゲームキャラクタCA1を撮影するように仮想カメラVCを制御する。
一方、制御部190は、所定期間前にタップ操作が行われていた場合、当該タップ操作については、図15に示された攻撃操作時のフローチャートのうち、ステップS42については実行しない。つまり、制御部190は、予め定められた期間内に2回目以降の攻撃操作が行われた場合には、最初の攻撃操作に基づいて決定された仮想カメラVCの撮影方向を、所定期間内に連続する攻撃操作を受け付けている間は変更しない。これにより、ゲームキャラクタCA1の攻撃によって敵キャラクタCA2の位置が変化し、それに伴ってゲームキャラクタCA1の向きが変更された場合であっても、仮想カメラVCの撮影方向は変更されないことになる。制御部190は、ユーザにキャラクタの向きを一度理解させた後は、固定されたアングルで連撃の様子を提供することにより、ユーザがキャラクタの向きを見失うことが無い状態で、連撃中のキャラクタや対象キャラクタを種々の角度から確認させることができる。
同様に、制御部190は、コンボ攻撃中の攻撃操作に方向性のある入力操作が含まれていた場合であっても、最初の攻撃操作に基づいて決定された仮想カメラVCの撮影方向を、所定期間内に連続する攻撃操作を受け付けている間は変更しない。以下では、フリック操作がコンボ攻撃中の攻撃操作に含まれる場合の例を詳細に説明する。
図17は、フリック操作時の処理を説明するフローチャートである。図17のフローチャートは、制御部190がゲームプログラム151を実行することによりアクションゲームを進行させる処理を示すフローチャートである。
ステップS50において、制御部190は、入力操作が受け付けられたか否かを判定する。制御部190は、入力操作として、仮想空間においてゲームキャラクタCA1を移動させる移動操作及びゲームキャラクタCA1に攻撃動作を行わせる攻撃操作を受け付けることができる。
入力操作が受け付けられたと判定されると(ステップS50:YES)、ステップS32において、制御部190は、初期タッチ位置に操作オブジェクトを表示させる(図14の画面例(B)に対応する)。オブジェクト制御部195は、入力操作に応答して円形の操作オブジェクト300を生成する。表示制御部196は、生成された円形の操作オブジェクト300をタッチ位置に表示させる。
ステップS54において、制御部190は、入力操作がフリック操作であるか否かを判定する。制御部190は、タッチスクリーン130の履歴情報を用いて、フリック操作であるか否かを判定する(図4参照)。
入力操作がフリック操作であると判定されると(ステップS54:YES)、ステップS56において、制御部190は、初期タッチ位置からフリック方向へ延びる操作オブジェクトを表示させる。
ステップS58において、制御部190は、ゲームキャラクタCA1が向いている方向を特定する。例えば記憶部150には、ゲームキャラクタCA1の顔が向いている方向または直前の移動操作の進行方向等を示す情報が記憶されている。制御部190は、ゲームキャラクタCA1に実行させたアクション、他のオブジェクトからの作用などに基づいて、記憶部150に記憶された情報が示す方向の中からゲームキャラクタCA1が向いている方向を選択する。次に、制御部190は、選択した結果に基づき、記憶部150を参照してゲームキャラクタCA1の向いている方向を特定する。
ステップS60において、制御部190は、フリック操作の方向とタッチスクリーン130に表示される画面においてゲームキャラクタCA1が向いている方向とを比較する。
ステップS62において、制御部190は、ステップS60における比較結果に応じたアクションを、ゲームキャラクタCA1に実行させる。この処理の詳細は、図18に示されたフローチャートを用いて後述する。
ステップS46として、制御部190は、操作オブジェクト300の表示を終了する。
一方、入力操作がフリック操作でないと判定されると(ステップS54:NO)、ステップS66において、制御部190は、入力操作に応じた動作をゲームキャラクタCA1に実行させる。そして、ステップS46として、制御部190は、操作オブジェクト300の表示を終了する。
入力操作が受け付けられていないと判定された場合(ステップS50:NO)、又は、操作オブジェクト300の表示を終了すると、図17に示されるフローチャートは終了する。そして、制御部190は、所定の条件が満たされるまで図17に示されるフローチャートを最初から実行する。以上で、攻撃操作時の一連の処理が終了する。
図18は、図17に示されたフリック操作に基づく動作処理を説明するフローチャートである。制御部190は、図18に示されるフローチャートに従い、比較結果に応じたアクションをゲームキャラクタCA1に実行させる。
ステップS70において、制御部190は、図18に示されたステップS50においてフリック操作を受け付ける前の所定期間内に、攻撃動作を行なうためのタップ操作を受け付けたか否かを判定する。
フリック操作の所定期間前に攻撃動作を行なうためのタップ操作を受け付けたと判定されると(ステップS70:YES)、ステップS72において、制御部190は、フリック操作の方向はゲームキャラクタCA1が向いている方向と所定関係にあるか否かを判定する。所定関係は、例えばゲームキャラクタCA1が向いている方向を軸として、フリック操作の方向が当該軸から左右一定の範囲(例えば、左右それぞれに30度以内、45度以内等)となることとしてもよい。
フリック操作の方向はゲームキャラクタCA1が向いている方向により定まる一定範囲の方向に含まれていると判定されると(ステップS72:YES)、ステップS74として、制御部190は、前回の攻撃動作に対応する操作がタップ操作であり、且つ、今回の操作がフリック操作であることに基づく攻撃動作を、ゲームキャラクタCA1に実行させる。このように、連続してゲームキャラクタCA1に攻撃動作を実行させる場合、毎回同じ攻撃動作をゲームキャラクタCA1に実行させるのではなく、異なる攻撃動作をゲームキャラクタCA1に実行させることができる。従って、攻撃動作が多様になる。ステップS72が終了すると、図18に示されるフローチャートが終了する。
一方、フリック操作の方向はゲームキャラクタCA1が向いている方向と所定関係にないと判定されると(ステップS72:NO)、ステップS76として、制御部190は、ゲームキャラクタCA1に、攻撃動作を実行することなくフリック操作の方向に移動するための回避動作を実行させる。それに続けて、ステップS78として、制御部190は、ゲームキャラクタCA1に攻撃動作を実行させる。ステップS78において制御部190がゲームキャラクタCA1に実行させる攻撃動作は、タップ操作に基づく攻撃動作とは異なってもよい。この場合、ゲームキャラクタCA1による攻撃動作がより多様となり、ゲームの趣向性が向上する。ステップS78が終了すると、図18に示されるフローチャートが終了する。
一方、フリック操作の所定期間前に攻撃動作を行なうためのタップ操作を受け付けていないと判定されると(ステップS70:NO)、ステップS80において、制御部190は、ゲームキャラクタCA1に回避動作を実行させ、攻撃動作を実行させない。そして、ステップS82において、制御部190は、仮想カメラVCの向きをゲームキャラクタCA1の向きに基づいて決定する。ステップS82が終了すると、図18に示されるフローチャートが終了する。
このように、制御部190は、ゲームキャラクタCA1が向いている方向とフリック操作の方向とに応じて、ゲームキャラクタCA1に攻撃動作を実行させたり回避動作を実行させたりするなど、アクションを分けることができるので、ゲームの趣向性が向上する。特に、攻撃対象に対する入力操作に多様性を持たせることができる。
また、制御部190は、コンボ攻撃の最初の攻撃操作に基づいて仮想カメラVCの撮影方向を決定し、コンボ攻撃中においては撮影方向を変更しない。このため、ユーザにゲームキャラクタCA1の向きを一度理解させた後は、固定されたアングルで連撃の様子を提供することにより、フリック操作が入力し易くなる。
また、フリック操作は、ゲーム中の素早い操作が必要とされる場面において、ユーザが直感的に素早く入力する操作である。本実施形態では、フリック操作の方向に応じて攻撃動作または回避動作を選択できるため、直感的に攻撃と回避とを選択することができる。よって、ゲームの趣向性が向上する。
(コンボ攻撃のパターン)
コンボ攻撃は、上述した操作手順に限定されることはなく、種々の操作手順が採用され得る。コンボ攻撃の種類が増えるほどゲームキャラクタCA1に多彩な攻撃をさせることができるので、ゲーム性が向上する。
図19は、コンボ列を定義するテーブル群の一例である。このようなテーブル群は、ゲーム情報152又はゲーム情報252にコンボデータとして含まれる。図19のテーブル例(A)は、コンボの手順を定義するコンボテーブルTB1である。図19のテーブル例(A)に示されるように、コンボテーブルTB1は、コンボ列ごとに、操作内容の順番を定義する。コンボ列は、コンボが成立する手順通りに入力操作を並べた列である。一例として、「第一コンボ列」は、タップ操作が二回続けて入力されたときにコンボが成立することが定義されている。また、「第二コンボ列」は、タップ操作が三回続けて入力されたときにコンボが成立することが定義されている。また、「第三コンボ列」は、タップ操作が三回続けて入力されたときにコンボが成立することが定義されている。また、「第四コンボ列」は、タップ操作が二回続けて入力され、その後フリック操作が入力されたときにコンボが成立することが定義されている。また、「第五コンボ列」は、タップ操作が二回続けて入力され、その後フリック操作及びタップ操作が続けて入力されたときにコンボが成立することが定義されている。また、図示を省略するが、それぞれの入力操作には、入力操作を受け付け可能な時間が設定されている。つまり、コンボは、それぞれの受付時間内において上述した手順が実行されたときに成立する。なお、全ての入力操作に対して共通する受付時間が設定されていてもよい。以下では、このような時間的要素を含めたコンボの手順をコンボ条件ともいう。受付時間の詳細については後述する。
コンボ条件が満たされた場合、ゲーム上の効果が奏される。ゲーム上の効果は、コンボ列ごとに予め定められている。ゲーム上の効果の一例は、ゲームパラメータの増減である。ゲームパラメータは、例えば、攻撃ダメージ値、攻撃軽減値、ゲームキャラクタCA1又は敵キャラクタの攻撃力、防御力、HP、属性などである。ゲーム上の効果の他の例は、ゲームキャラクタの攻撃モーションの変更である。ゲーム上の効果の一例として、ゲームキャラクタの攻撃モーションは、コンボ条件が満たされた場合と満たされていない場合とで変更されてもよい。なお、第一コンボ列〜第三コンボ列は、同じ入力操作が繰り返されることがある。この場合に、当該入力にゲーム上の効果を付加しない場合には、コンボの成立が判定されなくてもよい。
図19のテーブル例(B)は、コンボ列と当該コンボ列のコンボ条件が満たされたときに奏されるゲーム上の効果とを関連付けたコンボテーブルTB2である。図19のテーブル例(B)に示されるように、コンボ列それぞれにゲーム上の効果が関連付けられている。一例として、「第一コンボ列」には、攻撃ダメージ値が10%増加すること、及び、第二モーションで動作することがゲーム上の効果として関連付けられている。第一コンボ列のコンボ条件は、第一コンボ列の最後の手順である「タップ操作」時において満たされるため、このタップ操作時において、攻撃ダメージ値が10%増加し、かつ、第二モーションとなることが定義されている。同様に、「第二コンボ列」には、攻撃ダメージ値が15%増加すること、及び、第一モーションで動作することがゲーム上の効果として関連付けられている。「第三コンボ列」には、攻撃ダメージ値が20%増加すること、及び、第二モーションで動作することがゲーム上の効果として関連付けられている。「第四コンボ列」には、攻撃ダメージ値が25%増加すること、また、第三モーションで動作することがゲーム上の効果として関連付けられている。「第五コンボ列」には、攻撃ダメージ値が30%増加すること、また、第三モーションで動作することがゲーム上の効果として関連付けられている。
(コンボ列の分岐)
図20は、コンボ列の分岐を説明する図である。図20の画面例(A)〜画面例(F)は、タッチスクリーン130に表示された画像の一部である。画面例(A)は、所定時間前に攻撃操作がない状態でタップ操作が行われた場合のゲームキャラクタCA1のモーションを示している。
画面例(B)は、画面例(A)で示すモーション中の受付時間内にタップ操作が行われた場合のゲームキャラクタCA1のモーションを示している。つまり、画面例(B)は、図19のコンボテーブルTB2において定義された「第一コンボ列」のコンボ条件が満たされたときの画面の一部である。画面例(B)は、第二モーションで攻撃するゲームキャラクタCA1が表示されている。
図19のコンボテーブルTB2の例では、タップ操作が2回連続した場合、受付時間内に次に入力される攻撃操作の種別に応じて、満たされるコンボ条件が異なる。例えば、受付時間内に次の攻撃操作としてタップ操作が入力される場合には、図19のコンボテーブルTB2において定義された「第二コンボ列」のコンボ条件を満たす。この場合、画面例(C)に示されるように、第一モーションで攻撃するゲームキャラクタCA1が表示される。一方、受付時間内に次の攻撃操作としてフリック操作が入力される場合には、図19のコンボテーブルTB2において定義された「第四コンボ列」のコンボ条件を満たす。この場合、画面例(E)に示されるように、第三モーションで攻撃するゲームキャラクタCA1が表示されている。このように、画面例(B)においては、次の攻撃操作の種別に応じて画面例(C)へ遷移するのか、画面例(E)へ遷移するのかが決定される。このような状況を「コンボ列の分岐」という。
なお、画面例(D)は、画面例(C)で示すモーション中の受付時間内にタップ操作が行われた場合のゲームキャラクタCA1のモーションを示している(図19のコンボテーブルTB2の第三コンボ列)。画面例(F)は、画面例(E)で示すモーション中の受付時間内にタップ操作が行われた場合のゲームキャラクタCA1のモーションを示している(図19のコンボテーブルTB2の第五コンボ列)。
(コンボ列の分岐時の案内表示)
図20の画面例(B)の状況(コンボ列の分岐時)において、ユーザに対して、コンボ条件が満たされる次の入力操作の案内が表示される。以下では、コンボ条件が満たされる次の入力操作を案内する画面上の表示を案内表示という。また、コンボ列が分岐するタイミングを分岐タイミングという。案内表示は、分岐タイミングにおいて所定の案内表示時間の間、表示される。案内表示時間(表示時間の一例)の詳細については後述する。分岐タイミングにおける案内表示は、ユーザに対して、コンボを成立させるために次に入力すべき入力操作を提示する。よって、コンボ列の種類を増加させたことによる操作の複雑さが緩和され得る。
案内表示を提示する手法は、以下の四つの手法が存在する。第一の手法は、案内表示を吹き出し形式で表示する手法である。例えば、案内表示時間において、タッチスクリーン130にゲームキャラクタCA1の吹き出しとして次の入力操作を示す案内表示が表示される。案内すべき次の入力操作は、複数の候補が存在する。案内する入力操作は、取り得る全ての候補であってもよいし、選択された候補であってもよい。選択基準としては、例えば、取り得るコンボ列のうちゲーム上の効果が最も高いコンボ列となる入力操作が選択されてもよい。あるいは、複数の候補のうち直前の入力操作とは異なる入力操作が選択されてもよい。第一の手法は、案内表示がタッチスクリーン130上に案内表示時間だけに出現することから、ゲームの他のオブジェクトやキャラクタとの重なりを抑えることができる。このため、第一の手法は、スマートフォンのように表示領域が狭いデバイスにも採用することができる。また、第一の手法では、操作対象の近傍に案内表示が出現するため、操作対象に着目しているユーザは気付きやすい。
第二の手法は、コンボ列をノードとエッジとを用いたグラフとして画面に予め表示する手法である。ノードは入力操作を示し、エッジはコンボ順番を示す。第二の手法では、案内表示時間において、次の入力操作を示すノードが強調表示される。第二の手法では、案内表示に必要な表示領域が第一の手法よりも大きくなる反面、ユーザはコンボ列の入力操作の初期段階から、コンボ列の全体を理解することができる。
第三の手法は、第一の手法を改良した手法である。第一の手法では、吹き出しを用いて次の入力操作を案内するため、画面表示領域の有効利用はできるものの、吹き出しは、操作状況を表示する操作オブジェクトと比べて、外観が大きく異なる。操作オブジェクトは、操作履歴という操作情報を用いて、入力操作に基づいた表示形態でオブジェクトを表示する。操作情報を、ゲームを表示するスクリーンにユーザによる入力操作に関する情報であると定義すると、次に案内すべき入力操作も操作情報の一種である。このため、案内表示と操作オブジェクトとは、共に操作情報を表示するために画面上に出現するものである。このため、案内表示と操作オブジェクトとの両者を同一又は類似する外観にした方がユーザに受け入れやすい。
第三の手法の一例としては、操作オブジェクトの変形を利用して、操作オブジェクトを案内表示に利用する手法である。案内表示に利用された操作オブジェクトは、ユーザの入力状況を表示するものではなくなるため、案内オブジェクトとなる。案内オブジェクトは、一例として、ユーザによる前回のタッチ位置を表示位置とし、入力操作を促すように変形する。例えば、ドラッグ操作を案内する案内オブジェクトは、ドラッグ操作方向に沿って所定周期で伸縮する。このような案内オブジェクトは、操作オブジェクトを利用するユーザによって理解しやすく、受け入れやすい。
第四の手法は、第三の手法を改良した手法である。第三の手法の一例を実現するためには、操作オブジェクトの表示及び変形に係るプログラムを大幅に変更する必要がある。第四の手法は、操作オブジェクトのプログラムの改変を極力抑えるために採用され得る。第四の手法において、案内表示時間では、操作オブジェクトの表示を中断し、アニメーションの表示に切り替える。つまり、案内表示時間よりも前の期間においては、入力操作に応じて変形する操作オブジェクト(入力操作に基づいた表示形態の一例)でタッチスクリーン130に操作履歴(操作情報の一例)を表示させておき、案内表示時間においては、操作オブジェクトを表示させず、アニメーション(入力操作に基づかない表示形態の一例)で案内表示(操作情報の一例)を表示させる。なお、「入力操作に基づく表示形態」とは、入力操作に応じてオブジェクトの形状パラメータ又は色パラメータが制御される形態のことである。ユーザの入力操作によってアニメーションの再生開始、終了が行われた結果、タッチスクリーン130上の図形の形状・色が変更されることがあるが、このような操作は、形状パラメータ又は色パラメータを制御するものではないため、「入力操作に基づかない表示形態」の一例である。
(アニメーションの一例)
図21は、ドラッグ操作の案内表示となるアニメーション画像の一例である。図21の画像例(A)〜画像例(C)は、タッチスクリーン130に表示された画像の一部である。画像例(A)は、操作オブジェクトの形状に類似する図形500Aを含む。画像例(B)は、図形500Aよりも横幅のある図形500Bを含む。画像例(C)は、図形500Bよりも横幅のある図形500Cを含む。画像例(A)、画像例(B)及び画像例(C)の順に切り替えられることで、横方向に延びる図形が案内表示として表現される。また、画像例(C)、画像例(B)及び画像例(A)の順に切り替えられることで、横方向に縮む図形が案内表示として表現される。このように、画像例(A)〜画像例(C)が切り替えられることで、図形が左右方向に伸縮するアニメーションとなり、案内表示時間においてドラッグ操作を案内する。
(案内表示が行われる画面の遷移例)
図22は、アニメーションを利用した案内表示の一例を説明する図である。図22の画面例(A)〜画面例(F)は、タッチスクリーン130に表示された画像の一部である。画面例(A)〜画面例(F)は、順に時系列で遷移する。
図22の画面例(A)は、ユーザによるタップ操作が行われたタイミングの画像である。タップ操作によって、操作オブジェクト300が表示されるとともに、ゲームキャラクタCA1は、タップ操作に応じて予め定められた攻撃モーション(例えば、第一モーション)を開始する。一例として、タップ操作の入力前の所定期間に入力操作を受け付けていない場合、ゲームキャラクタCA1は、タップ操作に応じて第一モーションで動作する。
図22の画面例(B)は、図22の画面例(A)にて入力されたタップ操作に応じた攻撃モーション中のゲームキャラクタCA1を表示する画像である。図22の画面例(B)では、攻撃モーション中(第一モーション中)のゲームキャラクタCA1にタップ操作が入力され、操作オブジェクト300が表示される。二連続のタップ操作は、図19のテーブル例(A)の「第一コンボ列」に係るコンボ条件を満たす。なお、コンボ条件は、時間的要素を含むが、図22の説明においては、時間的要素に関するコンボ条件は省略し、詳細は後述する。「第一コンボ列」に係るコンボ条件が満たされた場合、図19のテーブル例(B)の「第一コンボ列」に係るゲーム上の効果として、次の攻撃モーションが「第二モーション」となる。ゲームキャラクタCA1は、第二モーションを開始する。
図22の画面例(C)は、図22の画面例(B)にて入力されたタップ操作に応じた攻撃モーション中(第二モーション中)のゲームキャラクタCA1を表示する画像である。「第一コンボ列」のコンボ条件が満たされたとき、次の入力操作がタップ操作であれば、「第二コンボ列」のコンボ条件を満たし、次の入力操作がフリック操作であれば「第四コンボ列」のコンボ条件を満たす。つまり、図22の画面例(C)は、分岐タイミングにおける画面例である。このとき、設定された所定期間に、図21のアニメーションによる案内表示500が表示される。以下では、上記所定期間を案内表示時間ともいう。案内表示500は、図21の図形500A〜500Cを所定の順番で再生した結果である。
図22の画面例(D)は、図22の画面例(C)に対して、タップ操作が入力されたタイミングの画像である。案内表示500は、アニメーションであるため、タップ操作に応じて変形しない。また、操作オブジェクトの表示も禁止されているため、タップ操作に応じた操作状況の表示も行われない。しかしながら、タップ操作が入力されているため、第二コンボ列のコンボ条件は満たされる。このため、図19のテーブル例(B)の「第二コンボ列」に係るゲーム上の効果として、次の攻撃モーションが「第一モーション」となる。ゲームキャラクタCA1は、第一モーションを開始する。
図22の画面例(E)は、図22の画面例(D)にて入力されたタップ操作に応じた攻撃モーション中(第一モーション中)のゲームキャラクタCA1を表示する画像である。図22の画面例(E)では、案内表示時間が経過し、案内表示500を示すアニメーションは終了している。そして、攻撃モーション中(第一モーション中)のゲームキャラクタCA1にタップ操作が入力され、操作オブジェクト300が表示される。四連続のタップ操作は、図19のテーブル例(A)の「第三コンボ列」に係るコンボ条件を満たす。「第三コンボ列」に係るコンボ条件が満たされた場合、図19のテーブル例(B)の「第三コンボ列」に係るゲーム上の効果として、次の攻撃モーションが「第二モーション」となる。ゲームキャラクタCA1は、第二モーションを開始する。
図22の画面例(F)は、図22の画面例(E)にて入力されたタップ操作に応じた攻撃モーション中(第二モーション中)のゲームキャラクタCA1を表示する画像である。
以上、連続するタップ操作に応じて、ゲーム上の効果が変更され、かつ、案内表示時間ではアニメーションの案内表示500が表示される。
図23は、アニメーションを利用した案内表示の他の例を説明する図である。図23の画面例(A)〜画面例(F)は、タッチスクリーン130に表示された画像の一部である。画面例(A)〜画面例(F)は、順に時系列で遷移する。
図23の画面例(A)〜画面例(C)は、図22の画面例(A)〜画面例(C)と同一である。
図23の画面例(D)は、図23の画面例(C)に対して、フリック操作が入力されたタイミングの画像である。案内表示500は、アニメーションであるため、フリック操作に応じて変形しない。また、操作オブジェクトの表示も禁止されているため、フリック操作に応じた操作状況の表示も行われない。しかしながら、フリック操作が入力されているため、第四コンボ列のコンボ条件は満たされる。このため、図19のテーブル例(B)の「第四コンボ列」に係るゲーム上の効果として、次の攻撃モーションが「第三モーション」となる。ゲームキャラクタCA1は、第三モーションを開始する。
図23の画面例(E)は、図23の画面例(D)にて入力されたフリック操作に応じた攻撃モーション中(第三モーション中)のゲームキャラクタCA1を表示する画像である。図23の画面例(E)では、案内表示時間が経過し、案内表示500を示すアニメーションは終了している。そして、攻撃モーション中(第三モーション中)のゲームキャラクタCA1にタップ操作が入力され、操作オブジェクト300が表示される。二連続のタップ操作とフリック操作とに続いて、さらにタップ操作された場合には、図19のテーブル例(A)の「第五コンボ列」に係るコンボ条件を満たす。「第五コンボ列」に係るコンボ条件が満たされた場合、図19のテーブル例(B)の「第五コンボ列」に係るゲーム上の効果として、次の攻撃モーションが「第三モーション」となる。ゲームキャラクタCA1は、第三モーションを開始する。
図23の画面例(F)は、図23の画面例(E)にて入力されたタップ操作に応じた攻撃モーション中(第三モーション中)のゲームキャラクタCA1を表示する画像である。
以上、タップ操作及びフリック操作に応じて、ゲーム上の効果が変更され、かつ、案内表示時間ではアニメーションの案内表示500が表示される。
(コンボ条件の時間的要素、先行入力及び後発入力)
図24は、先行入力を説明する図である。図24は、図23の画面例(B)から画面例(E)に至るまでのゲームキャラクタCA1の動作を詳細に説明する図である。
図24に示されるように、タップ操作に応じて第二モーションが開始される。第二モーションの再生は、開始時刻t1から開始され、終了時刻t2で終了する。第二モーションの再生中に、次の入力操作を受け付けるための受付時間が設定される。受付時間は、第二モーションの再生時間(第一コンボ動作で動作するキャラクタを表示させる期間の一例)である開始時刻t1から終了時刻t2までの間に設定される。図中では、受付時間は、開始時刻t3から開始され、終了時刻t4で終了する。
受付時間内にコンボ攻撃に係る入力操作が受け付けられた場合に、コンボ条件が満たされたと判定される。このため、受付時間外にコンボ攻撃に係る入力操作が受け付けられた場合であっても、当該入力操作はコンボ条件を満たすか否かの判定には考慮されない。つまり、コンボ条件は時間的要素を含む。図22及び図23の説明では、時間的要素は省略したが、全ての操作について受付時間が設定され、コンボ条件として時間的要素の条件を満たすか否かが判定される。
また、受付時間内にコンボ攻撃に係る入力操作が受け付けられた場合、先行入力か後発入力かに応じて、次のモーションの再生時間の開始時刻が変更される。受付時間には、分岐可能タイミングTA(第一タイミングの一例)が予め設定されている。分岐可能タイミングTAは、分岐されたコンボに係るモーションの再生が可能となるタイミングである。受付時間内に受け付けられたコンボ攻撃に係る入力操作が、受付時間の開始時刻t3から分岐可能タイミングTAまでに受け付けられた場合には、当該入力操作は先行入力として判定される。図24の例では、フリック操作が先行入力となる。コンボ攻撃に係る入力操作が先行入力である場合、次のモーション再生は、分岐可能タイミングTAから開始される。図24の例では、第三モーション再生の開始時刻t5が分岐可能タイミングTAと同一の時刻になる。
図25は、後発入力を説明する図である。入力操作に関して図24と比較すると、フリック操作が分岐可能タイミングTAの後に受け付けられる点を除き、同一である。図25に示されるように、受付時間内に受け付けられたコンボ攻撃に係る入力操作が、分岐可能タイミングTAから受付時間の終了時刻t4までに受け付けられた場合には、当該入力操作は後発入力として判定される。図25の例では、フリック操作が後発入力となる。コンボ攻撃に係る入力操作が後発入力である場合、次のモーション再生は、後発入力のあったタイミングから開始される。図25の例では、第三モーション再生の開始時刻t5がフリック操作のあったタイミングと同一の時刻になる。
(案内表示時間)
図26は、案内表示時間について説明する図である。案内表示時間は、受付時間に基づいて設定される。図26に示されるように、受付時間の開始時刻t3に、案内表示時間の開始時刻t7が設定される。また、案内表示時間の終了時刻t8は、コンボ攻撃に係る入力操作が先行入力の場合には分岐可能タイミングTAを基準に設定される。例えば、案内表示時間の終了時刻t8は、分岐可能タイミングTAより第一期間M1前に終了するように設定される。第一期間M1は0を含む。このため、案内表示時間の終了時刻t8は、分岐可能タイミングTAと同時であってもよい。このように、コンボ攻撃に係る入力操作が先行入力の場合には、分岐可能タイミングTAにおいてモーション再生がスタートするため、少なくとも分岐可能タイミングTAまでに案内表示を終了させることで、映像と案内表示が同期するため、ユーザにとって理解しやすい案内表示が提供される。
また、案内表示時間の終了時刻t8は、コンボ攻撃に係る入力操作が後発入力の場合には受付時間の終了時刻t4を基準に設定される。例えば、案内表示時間の終了時刻t8は、受付時間の終了時刻t4より第二期間M2前に終了するように設定される。第二期間M2は0を含む。このため、案内表示時間の終了時刻t8は、受付時間の終了時刻t4と同時であってもよい。このように、コンボ攻撃に係る入力操作が後発入力の場合には、受付時間の終了時刻t4を基準として案内表示時間を設定することにより、受付時間の終了タイミングをユーザが学習することができる。
なお、案内表示時間の終了時刻t8は、後発入力が受け付けられたタイミングで終了するようにしてもよい。この場合、映像と案内表示が同期するため、ユーザにとって理解しやすい案内表示が提供される。
(コンボ処理のフローチャート)
図27は、コンボ処理を説明するフローチャートである。図27のフローチャートは、制御部190がゲームプログラム151を実行することによりアクションゲームを進行させる処理を示すフローチャートである。図27に示されるフローチャートは、後述する分岐フラグが「0」のときに開始される。分岐フラグは、コンボ列に分岐があるときに「1」に設定され、コンボ列に分岐がないときに「0」に設定されるフラグである。
ステップS90において、制御部190は、入力操作が受け付けられたか否かを判定する。
入力操作が受け付けられたと判定されると(ステップS90:YES)、ステップS92において、制御部190は、操作オブジェクト300を表示するとともに、入力操作と前回入力操作との関係がコンボ条件を満たすか否かを判定する。前回入力操作とは、直前に入力された入力操作であってもよいし、所定回数前までに入力された入力操作であってもよい。制御部190は、例えば、図19に示されるテーブル例(A)のコンボテーブルTB1を参照し、ステップS90にて受け付けられた入力操作と、操作履歴に格納されている前回入力操作との関係が、何れかのコンボ列の手順と一致しているか否かを判定する。さらに、制御部190は、ステップS90にて受け付けられた入力操作が前回入力操作時に設定された受付時間内に受け付けられたものであるか否かを判定する。制御部190は、上記二つの判定が肯定的な場合、入力操作と前回入力操作との関係がコンボ条件を満たすと判定する。
一例として、ステップS90にて受け付けられた入力操作がタップ操作であり、操作履歴に格納されている前回入力操作がタップ操作であり、前回入力操作に設定された受付時間内に入力されたものであるとする。この場合、制御部190は、「第一コンボ列」に係るコンボ条件が満たされたと判定する(図19のコンボテーブルTB1)。また、一例として、ステップS90にて受け付けられた入力操作がタップ操作であり、操作履歴に格納されている前回入力操作がタップ操作であるものの、前回入力操作に設定された受付時間外に入力されたものであるとする。この場合、制御部190は、コンボ条件が満たされていないと判定する。
コンボ条件が満たされていないと判定されると(ステップS92:NO)、ステップS96において、制御部190は、入力操作に応じて動作するキャラクタの表示を開始する。制御部190は、例えば、図20の画面例(A)に示されるように、第一モーションで動作するゲームキャラクタCA1の表示を開始する。
コンボ条件が満たされたと判定されると(ステップS92:YES)、ステップS94において、制御部190は、コンボ動作で動作するキャラクタの表示を開始する。制御部190は、例えば、図20の画面例(B)に示されるように、第二モーションで動作するゲームキャラクタCA1の表示を開始する(図19のコンボテーブルTB2)。
ゲームキャラクタCA1の動作の表示が開始されると(ステップS94又はステップS96)、ステップS97において、制御部97は、次の入力操作のための受付時間を設定する(図24,図25)。
続いて、ステップS98において、制御部190は、コンボ列の分岐が存在するか否かを判定する。制御部190は、一例として、図19に示されるテーブル例(A)のコンボテーブルTB1及び操作履歴を参照し、ステップS90にて受け付けられた入力操作と、次回の入力操作との関係が複数のコンボ条件を満たす状況であるか否かを判定する。一例として、前回のタップ操作が1回、ステップS90にて受け付けられた入力操作がタップ操作である場合を説明する。このような二連続のタップ操作が受け付けられたとき、図19のコンボテーブルTB1に示されるように、次の入力操作がタップ操作であれば「第二コンボ列」を満たし、次の入力操作がフリック操作であれば「第四コンボ列」を満たす。このような場合、制御部190は、コンボ列の分岐があると判定する。
コンボ列の分岐があると判定されると(S98:YES)、ステップS100において、制御部190は、分岐フラグを「1」に設定する。一方、コンボ列の分岐がないと判定されると(S98:YES)、ステップS102において、制御部190は、分岐フラグを「0」に設定する。
入力操作が受け付けられていないと判定された場合(ステップS90:NO)、又は、分岐フラグの設定が終了した場合(ステップS100又はステップS102)には、図27に示されるフローチャートは、終了する。そして、制御部190は、分岐フラグが「0」である場合、図27に示されるフローチャートを最初から実行する。
(コンボ列の分岐時におけるコンボ処理のフローチャート)
図28は、コンボ列の分岐時におけるコンボ処理のフローチャートである。図28のフローチャートは、制御部190がゲームプログラム151を実行することによりアクションゲームを進行させる処理を示すフローチャートである。図28に示されるフローチャートは、分岐フラグが「1」のときに開始される。なお、以下ではコンボ列の分岐先が二つである場合、例えば、図20の画面例(B)における状況を一例として説明する。
ステップS110において、制御部190は、入力操作が受け付けられたか否かを判定する。
入力操作が受け付けられたと判定されると(ステップS110:YES)、ステップS112において、制御部190は、入力操作と前回入力操作との関係が第一コンボ条件を満たすか否かを判定する。第一コンボ条件は、分岐する二つのコンボ列のうち、一方のコンボ列に係るコンボ条件である。制御部190は、例えば、図19に示されるテーブル例(A)のコンボテーブルTB1を参照し、ステップS110にて受け付けられた入力操作と、操作履歴に格納されている前回入力操作との関係が、「第二コンボ列」の手順と一致しているか否かを判定する(第一コンボ条件の一例)。さらに、制御部190は、ステップS110にて受け付けられた入力操作が前回入力操作時に設定された受付時間内に受け付けられたものであるか否かを判定する(第一コンボ条件の一例)。制御部190は、上記二つの判定が肯定的な場合、入力操作と前回入力操作との関係が第一コンボ条件を満たすと判定する。
第一コンボ条件が満たされたと判定されると(ステップS112:YES)、ステップS114において、制御部190は、第一コンボ動作で動作するキャラクタの表示を開始する。一例として、「第二コンボ列」に係るコンボ条件が満たされたとすると、制御部190は、例えば、図20の画面例(C)に示されるように、第一モーション(第一コンボ動作の一例)で動作するゲームキャラクタCA1の表示を開始する。
第一コンボ条件が満たされていないと判定されると(ステップS112:NO)、ステップS116において、制御部190は、入力操作と前回入力操作との関係が第二コンボ条件を満たすか否かを判定する。第二コンボ条件は、分岐する二つのコンボ列のうち、他方のコンボ列に係るコンボ条件である。制御部190は、例えば、図19に示されるテーブル例(A)のコンボテーブルTB1を参照し、ステップS110にて受け付けられた入力操作と、操作履歴に格納されている前回入力操作との関係が、「第四コンボ列」の手順と一致しているか否かを判定する(第二コンボ条件の一例)。さらに、制御部190は、ステップS110にて受け付けられた入力操作が前回入力操作時に設定された受付時間内に受け付けられたものであるか否かを判定する(第二コンボ条件の一例)。制御部190は、上記二つの判定が肯定的な場合、入力操作と前回入力操作との関係が第二コンボ条件を満たすと判定する。
第二コンボ条件が満たされたと判定されると(ステップS116:YES)、ステップS118において、制御部190は、第二コンボ動作で動作するキャラクタの表示を開始する。一例として、「第四コンボ列」に係るコンボ条件が満たされたとすると、制御部190は、例えば、図20の画面例(E)に示されるように、第三モーション(第二コンボ動作の一例)で動作するゲームキャラクタCA1の表示を開始する。
第二コンボ条件が満たされていないと判定されると(ステップS116:NO)、ステップS120において、制御部190は、入力操作に応じて動作するキャラクタの表示を開始する。制御部190は、例えば、図20の画面例(A)に示されるように、第一モーションで動作するゲームキャラクタCA1の表示を開始する。
ゲームキャラクタCA1の動作の表示が開始されると(ステップS114、ステップS118又はステップS120)、ステップS122において、制御部97は、次の入力操作のための受付時間を設定する(図24,図25)。
続いて、ステップS124において、制御部190は、分岐フラグ処理を行う。分岐フラグ処理は、図27のステップS98、ステップS100及びステップS102と同一である。
入力操作が受け付けられていないと判定された場合(ステップS110:NO)、又は、分岐フラグの設定が終了した場合(ステップS124)には、図28に示されるフローチャートは、終了する。そして、制御部190は、分岐フラグが「1」である場合、図28に示されるフローチャートを最初から実行する。
(案内表示処理のフローチャート)
図29は、案内表示処理のフローチャートである。図29のフローチャートは、制御部190がゲームプログラム151を実行することによりアクションゲームを進行させる処理を示すフローチャートである。図29に示されるフローチャートは、分岐フラグが「1」のときに開始される。このため、図28に示されるフローチャートと並行して行われる。また、以下では、図20の画面例(B)における状況を一例として説明する。そして、案内表示は、ゲーム上の効果が大きい第四コンボ列に係る操作を案内するものとする。
ステップS132において、制御部190は、分岐可能タイミングTAを設定する(図24,図25)。制御部190は、直前に入力された入力操作に設定された受付時間に対して、分岐可能タイミングTAを設定する。一例として、制御部190は、受付時間の開始から所定時間の間隔を空けて分岐可能タイミングTAを設定する。
続いて、ステップS134において、制御部190は、案内表示を開始する。制御部190は、一例として、直前に入力された入力操作に設定された受付時間の開始とともに、図21に示されたアニメーションの再生を行う。この場合、受付時間の開始とともに次の入力操作(第四コンボ列のフリック操作)の入力を促すアニメーションが表示される。なお、案内表示時間の開始を、受付時間の開始よりも所定時間遅らせてもよい。
続いて、ステップS136において、制御部190は、入力操作と前回入力操作との関係が第二コンボ条件を満たすか否かを判定する。この処理は、図28のステップS116と同一である。
第二コンボ条件が満たされたと判定されると(ステップS136:YES)、ステップS138において、制御部190は、次の入力操作(第四コンボ列のフリック操作)が先行入力であるか後発入力であるかを判定する(図24,図25)。次の入力操作が先行入力である場合、制御部190は、分岐可能タイミングTAを基準に案内表示時間の終了タイミングを設定する。例えば、制御部190は、分岐可能タイミングTAより第一期間M1前に案内表示時間の終了時刻t8を設定する(図26)。次の入力操作が後発入力である場合、制御部190は、受付時間の終了時刻を基準に案内表示時間の終了タイミングを設定する。例えば、制御部190は、受付時間の終了時刻t4より第二期間M2前に案内表示時間の終了時刻t8を設定する(図26)。あるいは、制御部190は、後発入力を基準に案内表示時間の終了タイミングを設定してもよい。例えば、制御部190は、後発入力と同一又は所定時間経過後のタイミングに案内表示時間の終了時刻t8を設定する。
一方、第二コンボ条件が満たされていないと判定されると(ステップS136:NO)、ステップS140において、制御部190は、受付時間の終了時刻を基準に案内表示時間の終了タイミングを設定する。例えば、制御部190は、受付時間の終了時刻t4より第二期間M2前に案内表示時間の終了時刻t8を設定する。
終了タイミングの設定が終了すると、ステップS142として、制御部190は、設定されたタイミングで案内表示を終了する。以上で図29に示されるフローチャートは、終了する。そして、制御部190は、分岐フラグが「1」である場合、図29に示されるフローチャートを最初から実行する。
(案内表示のまとめ)
案内表示は、コンボ列が分岐するタイミングで表示される。案内表示は、一例として、操作オブジェクトに類似したアニメーションが再生される。また、アニメーション再生時においては、操作オブジェクトは表示させない。
(変形例1)
制御部190は、コンボの手順を定義するコンボテーブルTB1を参照してコンボ列の分岐を判定していたが、これに限定されるものではない。例えば、制御部190は、操作内容と分岐フラグとが関連付けられた分岐タイミングテーブルを参照してもよい。分岐タイミングテーブルは、コンボテーブルTB1から予め作成することができる。
(変形例2)
さらに、実施形態では、カメラ配置制御部194は、コンボ攻撃中においてはコンボ攻撃の最初の攻撃操作に基づいて仮想カメラVCの撮影方向を決定し、以降のコンボ攻撃中の撮影方向を固定する例を説明したが、これに限定されない。例えば、カメラ配置制御部194は、攻撃操作(コンボ攻撃操作を含む)を受け付けた場合には、常にゲームキャラクタCA1をその背後から撮影するように仮想カメラVCを制御してもよい。つまり、コンボ攻撃中においては、最初の攻撃操作に基づいて決定された仮想カメラVCの撮影方向(ゲームキャラクタCA1をその背後から撮影する方向)を維持するように、仮想カメラの撮影方向を変更し続ける。この場合、制御部190は、図18のステップS74、ステップS78の攻撃時において、攻撃対象となる敵キャラクタCA2にゲームキャラクタCA1を向かせ、ゲームキャラクタCA1の向きに応じて仮想カメラVCの撮影方向を制御する(図15のステップS40及びS42に相当する処理が行われる)。これにより、戦闘シーンにおいては、ゲームキャラクタCA1は常に敵キャラクタCA2に正面から対峙し、常にゲームキャラクタCA1の背後から観察するゲーム画面が提供される。このようなカメラワークとすることにより、ユーザがキャラクタの向きを見失うことが無いため、攻撃操作に方向性のある入力操作が含まれる場合であっても、操作性を向上させることができる。
(変形例3)
ドラッグ操作の操作結果を示す操作オブジェクト300は、複数のオブジェクトを用いて操作結果が表現されもよい。
(変形例4)
連撃操作中に含まれている操作は、フリック操作である例を説明したが、ドラッグ操作であってもよい。
(変形例5)
タッチスクリーン130は、モーションセンサ及びディスプレイ装置からなるデバイスに置き換えてもよい。
(変形例6)
上述したゲーム処理の全てを携帯端末10又はサーバ20が単体で実行してもよい。
以上、本開示の実施形態について説明したが、本開示の技術的範囲は、本実施形態の説明によって限定的に解釈されるべきではない。本実施形態は一例であって、特許請求の範囲の記載事項に基づいて、様々な実施形態の変更が可能であることが当業者によって理解されるところである。本開示の技術的範囲は、特許請求の範囲の記載事項及びその均等の範囲に基づいて定められるべきである。
本開示の主題は、例えば以下のような項目として示される。
(項目1)
ゲームを表示するスクリーン(例えばタッチスクリーン130)にユーザによる入力操作に関する操作情報を表示させるために、コンピュータによって実行される情報処理方法であって、
前記入力操作に基づいた表示形態(例えば操作オブジェクト300,400)で操作情報(例えば操作履歴)を前記スクリーンに表示させる第一表示ステップ(例えばステップS92)と、
所定の表示条件が満たされている間は(例えばコンボ列の分岐が発生し、設定された案内表示時間内であるとき)、前記入力操作に基づいた表示形態で操作情報を前記スクリーンに表示させず、前記入力操作に基づかない表示形態(例えば案内表示500)で操作情報(次に入力すべき入力操作)を前記スクリーンに表示させる第二表示ステップ(例えばステップS134)と、
を備える情報処理方法。
この情報処理方法によれば、入力操作に基づいた表示形態を、所定の表示条件が満たされている間は、入力操作に基づかない表示形態へ切り替えることができる。入力操作に基づいた表示形態と比べて、入力操作に基づかない表示形態は、表示変化の自由度が高い。このため、多彩な操作を制限なく表現することができるので、多彩な操作をユーザに入力させることができ、結果として、ゲーム性を向上させることができる。
(項目2)
前記第一表示ステップでは、前記入力操作に基づいた表示形態の操作情報として、前記入力操作に応じて形状が変化するオブジェクト(例えば操作オブジェクト300,400)を前記スクリーンに表示させ、
前記第二表示ステップでは、前記入力操作に基づかない表示形態の操作情報として、前記操作情報に関する予め記憶したアニメーション(例えば案内表示500)を前記スクリーンに表示させる、項目1に記載の情報処理方法。
この情報処理方法によれば、変形するオブジェクトとアニメーションとを切り替えることで、操作オブジェクトのプログラムの改変を極力抑えることができる。
(項目3)
前記アニメーションは、所定の前記入力操作を促す案内表示である項目2に記載の情報処理方法。
この情報処理方法によれば、案内表示をアニメーションで行うことで、操作オブジェクトのプログラムの改変を極力抑えることができる。
(項目4)
前記第二表示ステップでは、前記入力操作と次回の第一入力操作(例えばタップ操作)との関係が、キャラクタを第一コンボ動作で動作させるための第一コンボ条件(例えば第二コンボ列に係るコンボ条件)を満たす状況であり、かつ、前記入力操作と次回の第二入力操作(例えばフリック操作)との関係が、前記キャラクタを第二コンボ動作で動作させるための第二コンボ条件(例えば第四コンボ列に係るコンボ条件)を満たす状況である場合に、前記表示条件が満たされたと判定する、項目2又は3に記載の情報処理方法。
この情報処理方法によれば、コンボ列の分岐タイミングにおいて、変形するオブジェクトとアニメーションとを切り替えることができる。
(項目5)
前記第二表示ステップでは、所定のコンボ動作で動作する前記キャラクタを前記スクリーンに表示させる期間(例えば、第二モーション再生期間:開始時刻t1〜終了時刻t2)に設定された前記第二入力操作の受付期間(例えば、開始時刻t3〜終了時刻t4)に前記アニメーションを前記スクリーンに表示する、項目4に記載の情報処理方法。
この情報処理方法によれば、コンボに関する受付期間において、変形するオブジェクトとアニメーションとを切り替えることができる。
(項目6)
項目1〜5の何れか一項に記載の方法をコンピュータに実行させる、プログラム。
(項目7)
メモリと、
前記メモリに結合されたプロセッサとを備え、
前記プロセッサの制御により項目1〜5の何れか一項に記載の方法を実行する、装置。
1…ゲーム提供システム、10…携帯端末、20…サーバ、25…メモリ、26…ストレージ、29…プロセッサ、130…タッチスクリーン、150…記憶部、151…ゲームプログラム、190…制御部、191…入力操作受付部、192…ゲーム進行処理部、193…移動方向検出部、194…カメラ配置制御部、195…オブジェクト制御部、196…表示制御部、220…通信部、250…記憶部、251…ゲームプログラム、290…制御部、291…送受信部、292…サーバ処理部、293…データ管理部、294…マッチング部、295…計測部、300,400…操作オブジェクト、500…案内表示、CA1…ゲームキャラクタ(キャラクタの一例)。

Claims (6)

  1. ゲームを表示するスクリーンにユーザによる入力操作に関する操作情報を表示させるために、コンピュータによって実行される情報処理方法であって、
    前記入力操作に基づいた表示形態で操作情報を前記スクリーンに表示させる第一表示ステップと、
    所定の表示条件が満たされている間は、前記入力操作に基づいた表示形態で操作情報を前記スクリーンに表示させず、前記入力操作に基づかない表示形態で操作情報を前記スクリーンに表示させる第二表示ステップと、
    を備え
    前記第一表示ステップでは、前記入力操作に基づいた表示形態の操作情報として、前記入力操作に応じて形状が変化するオブジェクトを前記スクリーンに表示させ、
    前記第二表示ステップでは、前記入力操作に基づかない表示形態の操作情報として、前記操作情報に関する予め記憶したアニメーションを前記スクリーンに表示させる、情報処理方法。
  2. 前記アニメーションは、所定の前記入力操作を促す案内表示である請求項に記載の情報処理方法。
  3. 前記第二表示ステップでは、前記入力操作と次回の第一入力操作との関係が、キャラクタを第一コンボ動作で動作させるための第一コンボ条件を満たす状況であり、かつ、前記入力操作と次回の第二入力操作との関係が、前記キャラクタを第二コンボ動作で動作させるための第二コンボ条件を満たす状況である場合に、前記表示条件が満たされたと判定する、請求項2に記載の情報処理方法。
  4. 前記第二表示ステップでは、所定のコンボ動作で動作する前記キャラクタを前記スクリーンに表示させる期間に設定された前記第二入力操作の受付期間に前記アニメーションを前記スクリーンに表示する、請求項に記載の情報処理方法。
  5. 請求項1〜の何れか一項に記載の方法をコンピュータに実行させる、プログラム。
  6. メモリと、
    前記メモリに結合されたプロセッサとを備え、
    前記プロセッサの制御により請求項1〜の何れか一項に記載の方法を実行する、装置。
JP2017053400A 2017-03-17 2017-03-17 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム Active JP6318279B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017053400A JP6318279B1 (ja) 2017-03-17 2017-03-17 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017053400A JP6318279B1 (ja) 2017-03-17 2017-03-17 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018070682A Division JP2018153639A (ja) 2018-04-02 2018-04-02 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム

Publications (2)

Publication Number Publication Date
JP6318279B1 true JP6318279B1 (ja) 2018-04-25
JP2018153470A JP2018153470A (ja) 2018-10-04

Family

ID=62069463

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017053400A Active JP6318279B1 (ja) 2017-03-17 2017-03-17 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム

Country Status (1)

Country Link
JP (1) JP6318279B1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020021182A (ja) * 2018-07-30 2020-02-06 株式会社リコー 操作情報提供装置、操作情報提供システム、およびプログラム
JP2020018690A (ja) * 2018-08-02 2020-02-06 株式会社コロプラ ゲームプログラム、ゲーム方法、および情報処理装置
JP2020028652A (ja) * 2018-08-24 2020-02-27 株式会社コロプラ ゲームプログラム、方法、および情報処理装置
JP2020044140A (ja) * 2018-09-19 2020-03-26 株式会社コロプラ ゲームプログラム、ゲーム方法、および情報処理装置
JP2020110603A (ja) * 2020-02-26 2020-07-27 株式会社コロプラ ゲームプログラム、方法、および情報処理装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015225397A (ja) * 2014-05-26 2015-12-14 株式会社コロプラ ユーザインターフェースプログラム
JP2016146900A (ja) * 2015-02-10 2016-08-18 株式会社バンダイナムコエンターテインメント プログラムおよびゲーム装置
JP6034945B1 (ja) * 2015-12-10 2016-11-30 株式会社コロプラ ゲームプログラム
JP2017023581A (ja) * 2015-07-27 2017-02-02 株式会社バンダイナムコエンターテインメント プログラム及びゲームシステム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015225397A (ja) * 2014-05-26 2015-12-14 株式会社コロプラ ユーザインターフェースプログラム
JP2016146900A (ja) * 2015-02-10 2016-08-18 株式会社バンダイナムコエンターテインメント プログラムおよびゲーム装置
JP2017023581A (ja) * 2015-07-27 2017-02-02 株式会社バンダイナムコエンターテインメント プログラム及びゲームシステム
JP6034945B1 (ja) * 2015-12-10 2016-11-30 株式会社コロプラ ゲームプログラム

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020021182A (ja) * 2018-07-30 2020-02-06 株式会社リコー 操作情報提供装置、操作情報提供システム、およびプログラム
JP7183613B2 (ja) 2018-07-30 2022-12-06 株式会社リコー 操作情報提供装置、操作情報提供システム、およびプログラム
JP2020018690A (ja) * 2018-08-02 2020-02-06 株式会社コロプラ ゲームプログラム、ゲーム方法、および情報処理装置
JP2020028652A (ja) * 2018-08-24 2020-02-27 株式会社コロプラ ゲームプログラム、方法、および情報処理装置
JP2020044140A (ja) * 2018-09-19 2020-03-26 株式会社コロプラ ゲームプログラム、ゲーム方法、および情報処理装置
JP7266982B2 (ja) 2018-09-19 2023-05-01 株式会社コロプラ プログラム
JP2020110603A (ja) * 2020-02-26 2020-07-27 株式会社コロプラ ゲームプログラム、方法、および情報処理装置
JP7252915B2 (ja) 2020-02-26 2023-04-05 株式会社コロプラ ゲームプログラム、方法、および情報処理装置

Also Published As

Publication number Publication date
JP2018153470A (ja) 2018-10-04

Similar Documents

Publication Publication Date Title
JP6318279B1 (ja) 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム
US10695661B2 (en) Game control device, game system, and information storage medium
JP6318228B1 (ja) 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム
JP2018110786A (ja) ゲーム方法およびゲームプログラム
JP6263293B1 (ja) 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム
JP6244445B1 (ja) 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム
JP6902461B2 (ja) 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム
JP6002345B1 (ja) ゲームプログラム、方法及びタッチスクリーンを備える情報処理装置
JP6907148B2 (ja) 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム
JP6336168B1 (ja) 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム
JP2017192538A (ja) ゲームプログラム、方法及びタッチスクリーンを備える情報処理装置
JP2018153639A (ja) 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム
JP6554506B2 (ja) 情報処理方法、情報処理装置及び情報処理プログラム
JP2017185190A (ja) ゲームプログラム、方法及びタッチスクリーンを備える情報処理装置
KR102205901B1 (ko) 증강 현실을 제공하는 방법 및 컴퓨팅 디바이스
JP6174202B1 (ja) ゲームプログラム、方法及びタッチスクリーンを備える情報処理装置
JP6306771B1 (ja) 情報処理方法、情報処理装置及び情報処理プログラム
JP2021178183A (ja) 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム
JP6554125B2 (ja) ゲーム方法およびゲームプログラム
JP2018102909A (ja) 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム
JP6002344B1 (ja) ゲームプログラム、方法及びタッチスクリーンを備える情報処理装置
JP2017221676A (ja) ゲームプログラム、方法及びタッチスクリーンを備える情報処理装置
JP6948283B2 (ja) 情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラム
JP7086899B2 (ja) 情報処理方法、情報処理装置及び情報処理プログラム
JP3768223B1 (ja) ゲームシステム、プログラム及び情報記憶媒体

Legal Events

Date Code Title Description
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: 20180307

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180402

R150 Certificate of patent or registration of utility model

Ref document number: 6318279

Country of ref document: JP

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