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

Description

本開示は、情報処理方法、装置、及び当該情報処理方法をコンピュータに実行させるためのプログラムに関する。

特許文献１は、操作により特定される入力手順が、所定の基準手順に一致するか否かを判定し、入力操作の一致又は不一致を示す表示を行う方法を開示する。

特許５８６４８１０号公報

特許文献１記載の方法は、多彩な操作をユーザに入力させることでゲーム性を向上させることについて、改善の余地がある。

本開示に係る方法は、スクリーンに表示されるゲームのキャラクタをユーザによる入力操作に応じて動作させるために、コンピュータによって実行される情報処理方法であって、入力操作を受け付けた場合であって、入力操作と前回入力操作との関係が所定のコンボ条件を満たしているときには、所定のコンボ動作で動作するキャラクタをスクリーンに表示させる第一表示ステップと、入力操作と次回の第一入力操作との関係が、キャラクタを第一コンボ動作で動作させるための第一コンボ条件を満たす状況であり、かつ、入力操作と次回の第二入力操作との関係が、キャラクタを第二コンボ動作で動作させるための第二コンボ条件を満たす状況である場合には、所定のコンボ動作で動作するキャラクタの表示中において、第二入力操作の入力を促す案内表示をスクリーンに表示させる案内表示ステップと、第二入力操作を受け付けた場合には、第二コンボ動作で動作するキャラクタをスクリーンに表示させる第二表示ステップと、を備える。

本開示によれば、ゲーム性を高めることができる方法、装置及びプログラムが提供される。

一実施形態のゲーム提供システムの構成を示す図である。 携帯端末の構成を示すブロック図である。 サーバの機能的な構成を示すブロック図である。 入力操作受付部が入力操作の種類を検知する処理を説明する図である。 移動方向検出部がユーザの入力操作に応じてゲームキャラクタを移動させる 方向を検出する処理を説明する図である。 ドラッグ操作時に表示されるオブジェクトの一例である。 ドラッグ操作時に表示されるオブジェクトの一例である。 ドラッグ操作時に表示されるオブジェクトの変形を説明する図である。 オブジェクトの変形時おけるポリゴン方向調整処理を説明する図である。 オブジェクトの変形後にタッチ位置が更新された場合について示す模式図 である。 カメラ配置制御部が仮想カメラを制御する処理を説明する図である。カメ ラ配置制御部が仮想カメラを制御する処理を説明する図である。 ユーザによる入力操作に応じて変化するカメラワーク及び操作オブジェク トを説明する図である。 移動操作時の処理を説明するフローチャートである。 交戦時における仮想カメラの撮影方向を説明するための画面例である。 攻撃操作時の処理を説明するフローチャートである。 オブジェクト制御部がコンボデータに基づいてゲームキャラクタに攻撃動 作を実行させたときのアクションの一例を示す図である。 フリック操作時の処理を説明するフローチャートである。 フリック操作に基づく動作処理を説明するフローチャートである。 コンボ列を定義するテーブル群の一例である。 コンボ列の分岐を説明する図である。 ドラッグ操作の案内表示となるアニメーション画像の一例である。 アニメーションを利用した案内表示の一例を説明する図である。 アニメーションを利用した案内表示の他の例を説明する図である。 先行入力を説明する図である。 後発入力を説明する図である。 案内表示時間について説明する図である。 コンボ処理を説明するフローチャートである。 コンボ列の分岐時におけるコンボ処理のフローチャートである。 案内表示処理のフローチャートである。

以下、図面を参照しつつ、本開示の一実施形態について説明する。以下の説明では、同一の部品又は構成要素には同一の符号が付される。それらの名称及び機能は同一である。したがって、それらについての詳細な説明は繰り返さない。

［技術思想］
ゲームの一例として、ユーザによる入力操作に応じて、キャラクタがゲームの仮想空間を移動したり、ゲームの仮想空間に配置された敵キャラクタと交戦したりするゲームがある。このようなゲームにおいて、ユーザによる攻撃操作の手順が所定手順に一致する場合には、通常の攻撃操作によるダメージよりも大きなダメージを敵キャラクタに与えることができるゲームシステム（いわゆるコンボシステム）が存在する。コンボシステムを採用することにより、ゲームキャラクタに多彩な攻撃動作を行わせることができるため、ゲーム性が向上する。しかしながら、ユーザは、数多くの操作手順を理解しなければならない。したがって、多彩な操作をユーザに入力させる工夫が必要になる。このような工夫の一つとしては、ユーザに対して次の操作を案内するシステムを提供することが考えられる。このシステムを採用するにあたっては、適切なタイミングでユーザに案内する仕組みが必要になる。

ところで、スマートフォンなどのタッチスクリーンを備える情報処理装置がゲームプログラムを実行する場合、タッチスクリーンにはゲームの画面が表示される。情報処理装置は、ゲームの画面上でユーザによる入力操作を受け付ける。ユーザは、タッチスクリーンに対して指などを近接させて操作する。このため、ユーザは、操作ボタンなどを備えた一般的なコントローラと比べると、感触で入力操作の状況を理解することができない。このような背景に鑑み、入力操作の操作状況をタッチスクリーンに表示することで、ユーザに操作状況を報知するシステムが存在する。上述したコンボシステムをタッチスクリーンで提供するゲームに採用した場合には、入力操作の報知とコンボ操作の案内とを適切に行う仕組みが必要になる。

本実施形態は、ユーザによる入力操作に応じてゲームのキャラクタを動作させるためにコンピュータによって実行される情報処理方法、情報処理装置、及び、情報処理プログラムに関連し、上述した課題の少なくとも１つを解決する。

［ゲーム提供システム］
本実施形態において、ユーザは、例えばスマートフォンなどの、タッチスクリーンを搭載した情報処理装置を操作する。ユーザは、ゲームサーバとスマートフォンとの間でゲームに関するデータを送受信させながらゲームを進行させる。

図１は、一実施形態のゲーム提供システムの構成を示す図である。図１に示されるように、ゲーム提供システム１は、ユーザにより使用される情報処理装置と、サーバ２０とを含み、これらの装置がネットワーク８０によって互いに通信可能に接続されている。

図１の例では、ユーザにより使用される情報処理装置として、携帯端末１０Ａ、携帯端末１０Ｂ及び携帯端末１０Ｃなど複数の携帯端末を示している。以下、携帯端末１０Ａ、１０Ｂ、１０Ｃなどの携帯端末を「携帯端末１０」と総称することもある。携帯端末１０Ａ及び携帯端末１０Ｂは、無線基地局８１と通信することにより、ネットワーク８０と接続する。携帯端末１０Ｃは、家屋などの施設に設置される無線ルータ８２と通信することにより、ネットワーク８０と接続する。携帯端末１０は、例えばタッチスクリーンを備える端末であり、一例として、スマートフォン、ファブレット、タブレットなどのコンピュータである。

携帯端末１０は、ゲームプログラムを実行することにより、ゲームプログラムに応じたゲームをプレイする環境をユーザに対して提供する。携帯端末１０には、例えば、アプリなどを配信するプラットフォームを介してゲームプログラムがインストールされる。携帯端末１０は、携帯端末１０にインストールされたゲームプログラム、又は、予めプリインストールされているゲームプログラムを実行することで、ユーザによるゲームのプレイを可能とする。携帯端末１０は、ゲームプログラムを読み込んで実行することにより、サーバ２０と通信接続し、ゲームの進行に応じてゲームに関連するデータをサーバ２０と送受信する。

サーバ２０は、ゲームのプレイに必要なデータを、適宜のタイミングで携帯端末１０へ送信することで、携帯端末１０でのゲームのプレイを進行させる。サーバ２０は、ゲームをプレイする各ユーザの、ゲームに関連する各種データを管理する。サーバ２０は、携帯端末１０と通信し、各ユーザのゲームの進行に応じて、画像、音声、テキストデータ、その他のデータなどを携帯端末１０へ送信する。

例えば、サーバ２０は、各ユーザがゲームのストーリーを進行させた進行状況、ゲーム内に登場するキャラクタ（以下、「ゲームキャラクタ」ともいう。）のうち各ユーザが使用可能なゲームキャラクタの情報、ゲームキャラクタの能力を示すパラメータ、ゲームキャラクタが使用する道具の性能を示すパラメータ、その他の各種データなどを管理する。また、サーバ２０は、ゲームの運営者によりユーザに対して行われるキャンペーン、ゲームの進行における不具合の発生、不具合の解消、その他のゲームの運営に関連する情報などをユーザに通知する処理を行う。

ゲームプログラムは、ユーザがゲームをプレイするモードとして、一人のユーザがプレイするシングルプレイと、複数人のユーザが協同してプレイするマルチプレイとに対応している。例えば、ゲーム提供システム１において、サーバ２０は、マルチプレイに参加するユーザを特定して各ユーザの各携帯端末１０と通信することなどにより、マルチプレイでゲームをプレイする環境を各ユーザに提供する。

ゲーム提供システム１は、マルチプレイに対応することにより、例えば、アクションゲームであれば、各ユーザでチームを結成して、クエストモードなど比較的強力なキャラクタと対戦するゲームモードを複数のユーザがプレイすることを可能とする。また、ゲーム提供システム１は、サッカーゲームであれば、各ユーザが同一のサッカーチームのメンバーとなって試合を行うことを可能とする。また、ゲーム提供システム１は、テニスゲームであれば、各ユーザでチームを結成してダブルスの試合を行うことを可能とする。

［構成］
サーバ２０のハードウェアの構成を説明する。サーバ２０は、通信ＩＦ（Interface）２２と、入出力ＩＦ２３と、メモリ２５と、ストレージ２６と、プロセッサ２９とを備え、これらが通信バスを介して互いに接続する。

通信ＩＦ２２は、通信機器であり、例えばＬＡＮ（Local Area Network）規格など各種の通信規格に対応しており、携帯端末１０などの外部の通信機器との間でデータを送受信するためのインタフェースとして機能する。

入出力ＩＦ２３は、インタフェース機器であり、サーバ２０への情報の入力を受け付けるとともに、サーバ２０の外部へ情報を出力するためのインタフェースとして機能する。入出力ＩＦ２３は、マウス、キーボードなどの情報入力機器の接続を受け付ける入力受付部と、画像などを表示するためのディスプレイなどの情報出力機器の接続を受け付ける出力部とを含む。

メモリ２５は、記憶装置であり、例えば、処理に使用されるデータなどを記憶するために用いられる。メモリ２５は、例えば、プロセッサ２９が処理を行う際に一時的に使用するための作業領域をプロセッサ２９に提供する。メモリ２５は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）などを含んで構成される。

ストレージ２６は、記憶装置であり、例えば、プロセッサ２９が読み込んで実行するための各種プログラム及びデータを記憶するために用いられる。ストレージ２６が記憶する情報は、ゲームプログラム、ゲームプログラムに関連する情報、ゲームプログラムをプレイするユーザの情報、その他の情報を含む。ストレージ２６は、例えば、ＨＤＤ（Hard Disk Drive）、フラッシュメモリなどを含んで構成される。

プロセッサ２９は、演算装置であり、ストレージ２６に記憶されるプログラムなどを読み込んで実行することにより、サーバ２０の動作を制御する。プロセッサ２９は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）などを含んで構成される。

図２は、携帯端末１０の構成を示すブロック図である。図２に示されるように、携帯端末１０は、アンテナ１１０と、無線通信ＩＦ１２０と、タッチスクリーン１３０と、入出力ＩＦ１４０と、記憶部１５０と、音声処理部１６０と、マイク１７０と、スピーカ１８０と、制御部１９０とを含む。

アンテナ１１０は、携帯端末１０が発する信号を電波として空間へ放射する。また、アンテナ１１０は、空間から電波を受信して受信信号を無線通信ＩＦ１２０へ与える。

無線通信ＩＦ１２０は、携帯端末１０が他の通信機器と通信するため、アンテナ１１０などを介して信号を送受信するための変復調処理などを行う。無線通信ＩＦ１２０は、チューナー、高周波回路などを含む無線通信用の通信モジュールであり、携帯端末１０が送受信する無線信号の変復調や周波数変換を行い、受信信号を制御部１９０へ与える。

タッチスクリーン１３０は、ユーザからの入力操作を受け付けて、ユーザに対し情報をディスプレイ１３２に出力する。タッチスクリーン１３０は、ユーザの入力操作を受け付けるための部材であるタッチパネル１３１を含む。また、タッチスクリーン１３０は、メニュー画面や、ゲームの進行を画面に表示するための部材であるディスプレイ１３２を含む。タッチパネル１３１は、例えば、静電容量方式のものを用いることによって、ユーザの指などが接近したことを検出する。ディスプレイ１３２は、例えば、ＬＣＤ（Liquid Crystal Display）、有機ＥＬ（electroluminescence）、その他の表示装置によって実現される。

入出力ＩＦ１４０は、インタフェース機器であり、携帯端末１０への情報の入力を受け付けるとともに、携帯端末１０の外部へ情報を出力するためのインタフェースとして機能する。

記憶部１５０は、記憶装置であり、フラッシュメモリ、ＲＡＭ（Random Access Memory）などにより構成され、携帯端末１０が使用するプログラム、携帯端末１０がサーバ２０から受信する各種データ、その他の各種データを記憶する。

音声処理部１６０は、演算装置であり、音声信号の変復調を行う。音声処理部１６０は、マイク１７０から与えられる信号を変調して、変調後の信号を制御部１９０へ与える。また、音声処理部１６０は、音声信号をスピーカ１８０へ与える。音声処理部１６０は、例えば、音声処理用のプロセッサによって実現される。マイク１７０は、音声信号の入力を受け付けて制御部１９０へ出力するための音声入力部として機能する。スピーカ１８０は、音声信号を、携帯端末１０の外部へ出力するための音声出力部として機能する。

制御部１９０は、演算装置であり、記憶部１５０に記憶されるプログラムを読み込んで実行することにより、携帯端末１０の動作を制御する。制御部１９０は、例えば、アプリケーションプロセッサによって実現される。

携帯端末１０がゲームプログラム１５１を実行する処理について、より詳細に説明する。ある局面において、記憶部１５０は、ゲームプログラム１５１と、ゲーム情報１５２と、ユーザ情報１５３とを記憶する。携帯端末１０は、例えば、サーバ２０からゲームプログラムをダウンロードして記憶部１５０に記憶させる。また、携帯端末１０は、ゲームの進行に伴いサーバ２０と通信することで、ゲーム情報１５２及びユーザ情報１５３などの各種のデータをサーバ２０と送受信する。

ゲームプログラム１５１は、携帯端末１０においてゲームを進行させるためのプログラムである。ゲーム情報１５２は、ゲームプログラム１５１が参照する各種のデータを含む。ゲーム情報１５２は、例えば、ゲームにおいて仮想空間に配置されるオブジェクトの情報、オブジェクトに対応付けられた効果の情報（ゲームキャラクタに設定されるスキルの情報などを含む）基準モーションデータ、コンボデータなどを含む。基準モーションデータは、各ゲームキャラクタの動作を定義する。動作は、入力操作に対応付けて定義されてもよい。コンボデータは、所定の条件で発生するコンボによってゲームキャラクタに実行させる動作の内容（例えば、攻撃動作の種類、攻撃力、動きなど）を定義する。ユーザ情報１５３は、ゲームをプレイするユーザについての情報を含む。ユーザ情報１５３は、例えば、ゲームをプレイする携帯端末１０のユーザを識別する情報、マルチプレイ時に協働してゲームをプレイする他のユーザを識別する情報、その他の情報を含む。その他の情報は、例えば、タッチパネル１３１の履歴データなどを含む。履歴データは、タッチパネル１３１の操作履歴である。

制御部１９０は、ゲームプログラム１５１を読み込んで実行することにより、入力操作受付部１９１と、ゲーム進行処理部１９２と、移動方向検出部１９３と、カメラ配置制御部１９４と、オブジェクト制御部１９５と、表示制御部１９６と、の各機能を発揮する。

入力操作受付部１９１は、タッチスクリーン１３０の出力に基づいて、ユーザの入力操作を受け付ける。具体的には、入力操作受付部１９１は、ユーザの指などがタッチパネル１３１に接近したことを、タッチスクリーン１３０を構成する面の横軸及び縦軸からなる座標系の座標として検出する。

入力操作受付部１９１は、タッチスクリーン１３０に対するユーザの操作を判別する。入力操作受付部１９１は、例えば、（１）「接近操作」、（２）「リリース操作」、（３）「タップ操作」、（４）「ダブルタップ操作」、（５）「長押し操作（ロングタッチ操作）」、（６）「ドラッグ操作（スワイプ操作）」、（７）「ムーブ操作」、（８）「フリック操作」、その他のユーザの操作を判別する。入力操作受付部１９１が判別するユーザの操作は、上記に限られない。例えば、タッチパネル１３１が、ユーザがタッチパネル１３１に対して押下する圧力の大きさを検出可能な機構を有する場合、入力操作受付部１９１は、ユーザにより押下された圧力の大きさを判別する。

（１）「接近操作」とは、ユーザが指などをタッチスクリーン１３０に接近させる操作である。タッチスクリーン１３０は、ユーザの指などが接近したこと（ユーザの指などがタッチスクリーン１３０に接触したことを含む）をタッチパネル１３１により検出し、検出したタッチスクリーン１３０の座標に応じた信号を制御部１９０へ出力する。制御部１９０は、タッチスクリーン１３０へのユーザの指などの接近を検出しない状態から、接近を検出したときに、状態が「タッチオン状態」になったと判別する。

（２）「リリース操作」とは、ユーザがタッチスクリーン１３０を接近操作している状態を止める操作である。入力操作受付部１９１は、例えば、ユーザが指などをタッチスクリーン１３０に接触させている状態から、指を離す操作をしたときに、ユーザの操作を「リリース操作」と判別する。制御部１９０は、タッチスクリーン１３０へのユーザの指などの接近を検出している状態から、接近を検出しない状態になったときに、状態が「タッチオン状態」から「タッチオフ状態」になったと判別する。

（３）「タップ操作」とは、ユーザがタッチスクリーン１３０に対して指などを接近させる接近操作をした後に、接近操作をした位置でリリース操作を行うことである。入力操作受付部１９１は、接近操作が検出されない状態（ユーザの指などがタッチパネル１３１から離れており、タッチパネル１３１がユーザの指などの接近を検出していない状態）から、タッチスクリーン１３０の出力に基づいて、ユーザの指などが接近したことを検出した場合に、その検出した座標を「初期タッチ位置」として保持する。入力操作受付部１９１は、初期タッチ位置の座標と、リリース操作をした座標とがほぼ同一である場合（接近操作が検出された座標から一定範囲内の座標においてリリース操作の座標が検出された場合）に、ユーザの操作を「タップ操作」と判別する。

（４）「ダブルタップ操作」とは、ユーザがタップ操作を一定時間内に２回行う操作である。入力操作受付部１９１は、例えば、ユーザの操作をタップ操作と判別してから一定時間内に、タップ操作にかかる座標で再びタップ操作を判別した場合に、ユーザの操作を「ダブルタップ操作」と判別する。

（５）「長押し操作」とは、ユーザがタッチスクリーン１３０を押し続ける操作である。タッチスクリーン１３０は、ユーザの操作を検出して接近操作を判別してから、接近操作が検出された座標において接近操作が継続している時間が一定時間を超えた場合に、ユーザの操作を「長押し操作」（「長押し操作」を、「ロングタッチ操作」と称することもある）と判別する。

（６）「ドラッグ操作」とは、ユーザがタッチスクリーン１３０に指などを接近させた接近状態を維持したまま、指をスライドさせる操作である。

（７）「ムーブ操作」とは、ユーザがタッチスクリーン１３０において、接近操作を維持しつつ、タッチスクリーン１３０に指などを接近させている位置を移動させてリリース操作を行う一連の操作をいう。

（８）「フリック操作」は、ユーザがムーブ操作を予め定められた時間よりも短い時間で行う操作をいう。フリック操作は、ユーザがタッチスクリーン１３０で指を弾くような操作である。

入力操作受付部１９１は、所定期間のユーザの入力操作の判別結果を記憶部１５０に操作履歴として記憶する。入力操作受付部１９１により行われる入力操作の種類を検知する詳細な処理は、後述する。

ゲーム進行処理部１９２は、ユーザの操作に応じて、各種のプログラムを呼び出すなどによりゲームを進行させる処理を行う。例えば、ゲーム進行処理部１９２は、サーバ２０と通信し、ゲームの進行に応じてサーバ２０へデータを送信する処理、サーバ２０からゲームに関連するデータを受信する処理、ゲームの進行に応じてユーザに報酬を付与する処理、時間の経過を計測する処理、その他の処理を行う。

移動方向検出部１９３は、タッチスクリーン１３０に対するユーザの入力操作が移動操作である場合、ゲームに登場するキャラクタであるゲームキャラクタを移動させる入力操作の操作内容を検出する。移動操作とは、ゲームキャラクタの移動方向を指示する入力操作であり、方向性のある操作である。移動操作の一例としては、所定条件下のドラッグ操作又はフリック操作である。例えばゲームプログラム１５１がアクションゲームである場合、移動方向検出部１９３は、ユーザのドラッグ操作又はフリック操作に基づいて、ゲームキャラクタを移動させる方向を検出する。

具体的には、移動方向検出部１９３は、タッチスクリーン１３０からユーザの指が離れた状態から、ユーザが指をタッチスクリーン１３０に接近させて、入力操作受付部１９１がタッチパネル１３１にユーザの指が接近したことを検出した座標を初期タッチ位置として、ユーザがドラッグ操作を行った場合に、初期タッチ位置の座標とタッチスクリーン１３０の検出結果とに基づいて、ゲームキャラクタの移動方向を検出する。移動方向検出部１９３の詳細な処理は、後述する。

カメラ配置制御部１９４は、仮想空間に配置される各オブジェクトを、どのようにユーザに見せるかを決定する。具体的には、カメラ配置制御部１９４は、制御部１９０がゲームプログラム１５１を読み込んで実行することで生成される仮想空間において、仮想カメラの配置及び撮影方向（カメラワーク）を制御する。仮想カメラの配置及び撮影方向は、仮想空間の座標及び方向によって定義される。制御部１９０は、仮想空間における仮想カメラの撮影画像をディスプレイ１３２に表示することで、ユーザに対しゲームのプレイ環境を提供する。

オブジェクト制御部１９５は、携帯端末１０がゲームプログラム１５１を実行することにより進行されるゲームに登場する各種オブジェクト、及び、入力操作受付部１９１が受け付けたユーザの操作内容に基づいて生成される各種オブジェクト（例えば、ＧＵＩ（Graphical User Interface）画面など）の生成、変形、移動などの処理を制御する。オブジェクト制御部１９５は、例えば、タッチスクリーン１３０に対する入力操作に基づいて、ユーザの操作を示す操作オブジェクトを生成する。操作オブジェクトの詳細については後述する。

表示制御部１９６は、ディスプレイ１３２の表示を制御する。表示制御部１９６は、例えば、仮想カメラのカメラワークに従った画像をディスプレイ１３２に出力する。表示制御部１９６は、仮想空間内における仮想カメラの配置及び撮影方向に応じて、ディスプレイ１３２の表示内容を決定し、決定した表示内容に従う画像、テキストなどの各種の情報をディスプレイ１３２に出力する。

図３は、サーバ２０の機能的な構成を示すブロック図である。図３を参照して、サーバ２０の詳細な構成を説明する。サーバ２０は、一般的なコンピュータとして構成され、プログラムに従って動作することにより、通信部２２０と、記憶部２５０と、制御部２９０としての機能を発揮する。

通信部２２０は、通信機器であり、サーバ２０が携帯端末１０などの外部の通信機器と通信するためのインタフェースとして機能する。

記憶部２５０は、記憶装置であり、携帯端末１０においてユーザがゲームを進行させるための各種プログラム及びデータを記憶する。ある局面において、記憶部２５０は、ゲームプログラム２５１と、ゲーム情報２５２と、ユーザ情報２５３とを記憶する。

ゲームプログラム２５１は、サーバ２０が携帯端末１０と通信して、携帯端末１０においてゲームを進行させるためのプログラムである。ゲームプログラム２５１は、ゲームを進行させるための各種データであるゲーム情報２５２及びユーザ情報２５３などを参照して、ユーザの入力操作に応じてゲームを進行させる。ゲームプログラム２５１は、制御部２９０に実行されることにより、携帯端末１０とデータを送受信する処理、携帯端末１０のユーザが行った操作内容に応じてゲームを進行させる処理、ゲームをプレイするユーザの情報を更新する処理、その他の処理をサーバ２０に行わせる。

ゲーム情報２５２は、ゲームプログラム２５１が参照する各種のデータを含む。ゲーム情報２５２は、オブジェクト管理テーブル２５２Ａと、パッシブスキル管理テーブル２５２Ｂと、アクティブスキル管理テーブル２５２Ｃとを含む。

オブジェクト管理テーブル２５２Ａは、ゲームの仮想空間内に配置されるオブジェクトの設定を示す。携帯端末１０は、ゲームプログラム１５１を実行することにより、仮想空間内に配置されるオブジェクトを、仮想空間内に配置される仮想カメラによって撮影された画像をディスプレイ１３２に表示させることでゲームを進行させる。

ここで、オブジェクトとしては、例えば、ユーザが操作するゲームキャラクタを示すオブジェクト、ゲームキャラクタが装着する対象物を示すオブジェクトなど様々なものがある。これらオブジェクトは、ユーザがタッチスクリーン１３０に対して予め定められた入力操作を行うこと、ゲームの進行に伴い一定の条件を満たすこと、その他の様々な事象の発生を契機として、オブジェクトに対応付けられた処理が行われる。

例えば、あるオブジェクトに対してユーザがタッチスクリーン１３０に対して接近操作を行うことで、オブジェクトがユーザに選択された状態となる。また、例えば、ユーザがタップ操作を行うことで、ユーザに選択されているオブジェクトがユーザの入力操作に応じて攻撃するなどの処理が行われる。また、例えば、ユーザがドラッグ操作を行うことで、ユーザに選択されているオブジェクトがユーザの入力操作に応じて移動するなどの処理が行われる。また、例えば、ユーザがオブジェクトに対してロングタッチ操作をすることで、ユーザに対し、ゲームを有利に進めるための報酬が付与されるなどの処理が行われる。

パッシブスキル管理テーブル２５２Ｂは、オブジェクトを識別する情報と、オブジェクトに対応付けられたパッシブスキルの情報とが対応付けられている。ここで、パッシブスキルとは、例えば、ゲームにおいて予め定められた条件が満たされたときに発動され、ユーザがゲームを有利に進行させることができるものである。例えば、パッシブスキルが発動した場合に、ゲームキャラクタの移動速度が向上するなどの、ゲームを有利に進行させられる効果を発揮させる。

アクティブスキル管理テーブル２５２Ｃは、オブジェクトを識別する情報と、オブジェクトに対応付けられたアクティブスキルの情報とが対応付けられている。ここで、アクティブスキルとは、例えば、ゲームにおいて予め定められた条件が満たされたときに発動可能な状態となり、ユーザから、スキルを発動させるための入力操作を受け付けることにより、ユーザがゲームを有利に進行させることができるものである。

ユーザ情報２５３は、ゲームをプレイするユーザについての情報である。ユーザ情報２５３は、ユーザ管理テーブル２５３Ａを含む。ユーザ管理テーブル２５３Ａは、各ユーザを識別する情報と、ユーザがゲームを進行させた度合いを示す情報と、ユーザがゲーム内で保有するアイテム、ゲームキャラクタ、ゲームキャラクタが使用する装着物などの情報その他の情報を含む。

制御部２９０は、記憶部２５０に記憶されるゲームプログラム２５１を実行することにより、送受信部２９１、サーバ処理部２９２、データ管理部２９３、マッチング部２９４、計測部２９５としての機能を発揮する。

送受信部２９１は、ゲームプログラム１５１を実行する携帯端末１０から、各種情報を受信し、携帯端末１０に対し、各種情報を送信する。携帯端末１０とサーバ２０とは、ユーザに関連付けられるオブジェクトを仮想空間に配置する要求、オブジェクトを削除する要求、オブジェクトを移動させる要求、ユーザが獲得する報酬に応じて各種パラメータを更新する要求、ゲームを進行させるための画像、音声その他のデータ、サーバ２０から携帯端末１０へ送信される通知などの情報を送受信する。

サーバ処理部２９２は、サーバ２０全体の動作を制御し、各種のプログラムを呼び出すなどによりゲームの進行に必要な処理を行う。サーバ処理部２９２は、例えば、携帯端末１０から受信した情報に基づいて、ゲーム情報２５２、ユーザ情報２５３などのデータを更新し、携帯端末１０に各種データを送信することでゲームを進行させる。

データ管理部２９３は、サーバ処理部２９２の処理結果に従って、記憶部２５０に記憶される各種データを更新する処理、データベースにレコードを追加／更新／削除する処理などを行う。

マッチング部２９４は、複数のユーザを関連付けるための一連の処理を行う。マッチング部２９４は、例えば、ユーザがマルチプレイを行うための入力操作を行った場合に、ゲームを協同してプレイさせるユーザを関連付ける処理などを行う。

計測部２９５は、時間を計測する処理を行う。計測部２９５は、例えば、仮想空間に配置される各オブジェクトについて時間の経過を計測する。また、計測部２９５は、ゲームが進行している時間を計測する。サーバ２０は、携帯端末１０から、携帯端末１０においてゲームプログラム１５１を実行して計測される各種の計測結果の情報を受信し、受信した情報と、計測部２９５の計測結果とを照合することで、携帯端末１０とサーバ２０とで、各種の時間に関する情報を同期させる。

［実施形態の構成のまとめ］
以上のように、実施形態のゲーム提供システム１の構成を説明してきた。本実施形態において、ゲームプログラム１５１は、例えばアクションゲームであり、仮想空間内の仮想カメラの配置及び撮影方向に応じた画像をタッチスクリーン１３０に表示させることでゲームを進行させる。

例えば、ゲームプログラム１５１がアクションゲームである場合、ゲーム進行処理部１９２は、ユーザの操作に応じてストーリーを進行させ、画像、テキストなどディスプレイ１３２に表示するデータを決定する処理、交戦相手又は仲間の選択をユーザから受け付ける処理、ユーザの操作に応じてアクションゲームを進める処理などの基本的な処理を行う。

例えば、ゲームプログラム１５１がアクションゲームである場合、カメラ配置制御部１９４は、アクションゲームを行うための仮想空間における仮想カメラの配置位置及び撮影方向を、アクションゲームの進展に応じて、逐次、決定する。カメラ配置制御部１９４は、仮想カメラのカメラワークを制御する。カメラ配置制御部１９４の詳細な処理は、後述する。

例えば、表示制御部１９６は、ゲームキャラクタを一定領域に表示させるよう仮想カメラを配置した状態で、ゲームキャラクタに第１の動作（例えば、移動動作）を行わせるための入力操作を受け付けて、受け付けた入力操作に応じてゲームキャラクタに第１の動作を行わせる画面表示をする。

［動作］
図面を参照して、実施形態のゲーム提供システム１を構成する各装置の動作を説明する。

（入力操作の検知）
図４は、入力操作受付部１９１が入力操作の種類を検知する処理を説明する図である。図４の例では、ユーザ情報１５３を記憶する記憶部１５０の配列ｆｐ［０］〜配列ｆｐ［１０］までの１１個の配列のそれぞれに、タッチパネル１３１により検知されたタッチスクリーン１３０上の位置を示す履歴情報が格納されている。履歴情報は、所定の期間毎（例えば、フレームレート毎）に履歴情報テーブルに格納される。履歴情報が格納される配列の個数は限定されず、任意の個数であってよい。また、履歴情報テーブルでは、タッチオフからタッチオンになった場合に検知された履歴情報を、初期位置座標として記憶部１５０に記憶してもよい。

図４に示されるように、例えば、配列ｆｐ［０］〜配列ｆｐ［９］に、履歴情報（ｘ０、ｙ０）が格納されており、配列ｆｐ［１０］にｎｕｌｌ値が格納された場合、入力操作受付部１９１は、入力操作はタップ操作であると判別する。また、例えば、タッチナウ状態において履歴情報が変化した後に、ｎｕｌｌ値が格納された場合、入力操作受付部１９１はｎｕｌｌ値が格納された配列ｆｐ［５］の直前の配列ｆｐ［３］および配列ｆｐ［４］に格納されている履歴情報を参照する。そして、入力操作受付部１９１は、配列ｆｐ［３］および配列ｆｐ［４］の履歴情報がそれぞれ示す位置の間の距離が予め設定された閾値以上である場合、入力操作はフリック操作であると判別する。また、入力操作受付部１９１は、タッチナウ状態において履歴情報が変化した後に、例えば配列ｆｐ［４］〜ｆｐ［１０］に履歴情報（ｘ１５、ｙ１５）が格納された場合、入力操作はドラッグ操作であると判別する。

（移動方向の検知）
図５は、移動方向検出部１９３がユーザの入力操作に応じてゲームキャラクタを移動させる方向を検出する処理を説明する図である。移動方向検出部１９３は、ユーザがタッチスクリーン１３０を押していない状態から、指などをタッチパネル１３１に接近させてタッチスクリーン１３０を押した位置（初期タッチ位置）を起点と設定する。入力操作受付部１９１は、ユーザの操作をドラッグ操作と判別している場合に、起点となる座標と、タッチスクリーン１３０がユーザの指などの接近を検出している座標とに基づいて、ゲームキャラクタを移動させる方向を検出する。

図５の状態（Ａ）は、タッチスクリーン１３０からユーザの指が離れた状態から、ユーザが指をタッチスクリーン１３０に接近させた状態を示す。入力操作受付部１９１は、ユーザの指がタッチパネル１３１に接近したことを検出し、検出した座標を初期タッチ位置として記憶部１５０にユーザ情報１５３として保持する。

図５の例では、記憶部１５０が保持する初期タッチ位置の座標を、初期タッチ位置座標１５５として示す。入力操作受付部１９１は、タッチスクリーン１３０の検出結果（ユーザの指がタッチスクリーン１３０に接近している座標、及び、ユーザの指がタッチスクリーン１３０に接近していることを検出していないこと（検出結果「ｎｕｌｌ」））を、一定フレーム分、ユーザ情報１５３としてバッファメモリに格納する。バッファメモリは、タッチスクリーン１３０における検出結果を、各フレームについて一定フレーム分（図５の例では、配列ｆｐ〔０〕〜配列ｆｐ〔１０〕までの１１フレーム分）、格納することができる。バッファメモリは、例えばリングバッファとして実現することができる。

図５の状態（Ａ）の例では、ユーザがタッチスクリーン１３０を押した位置を、押下位置３０Ａ（タッチスクリーン１３０の座標（ｘ０，ｙ０））として示す。

図５の状態（Ｂ）は、ユーザがタッチスクリーン１３０に対してドラッグ操作を行って、タッチスクリーン１３０に対する押下位置を、押下位置３０Ａから押下位置３０Ｂ（タッチスクリーン１３０の座標（ｘ９，ｙ９））まで１０フレーム（配列ｆｐ〔０〕〜配列ｆｐ〔９〕までの１０フレーム分）で移動させたことを示す。入力操作受付部１９１は、タッチスクリーン１３０の検出結果をユーザ情報１５３としてバッファメモリに格納し、バッファメモリに保持される値を参照して、タッチスクリーン１３０に対するユーザの操作をドラッグ操作と判別する。

図５の状態（Ｃ）は、ユーザがタッチスクリーン１３０を押している位置を、押下位置３０Ｂから押下位置３０Ｃ（タッチスクリーン１３０の座標（ｘ１４，ｙ１４））まで、５フレーム（配列ｆｐ〔１０〕、ｆｐ〔０〕、ｆｐ〔１〕、ｆｐ〔２〕、ｆｐ〔３〕の５フレーム分）で移動させたことを示す。

図５の状態（Ｄ）は、移動方向検出部１９３が、状態（Ｂ）及び状態（Ｃ）のそれぞれにおいて、ユーザがゲームキャラクタを移動させる方向を指定する入力操作の検出結果を示す。移動方向検出部１９３は、バッファメモリにおいて、タッチスクリーン１３０が検出する押下位置の座標を書き込む対象となるメモリ領域がいずれであるかを示す情報（バッファメモリの書き込み位置）を管理している。

図５の状態（Ｂ）において、移動方向検出部１９３は、入力操作受付部１９１の判別結果に基づいて、初期タッチ位置を示す座標３１Ａ（座標（ｘ０，ｙ０））から座標３１Ｂ（座標（ｘ９，ｙ９））までユーザがドラッグ操作を行ったことを検出する。移動方向検出部１９３は、初期タッチ位置の座標３１Ａを起点として、座標３１Ａと座標３１Ｂとによって規定されるベクトル３２Ｂ（（ｙ９−ｙ０）／（ｘ９−ｘ０））を、ゲームキャラクタを移動させる方向として検出する。

図５の状態（Ｃ）において、移動方向検出部１９３は、入力操作受付部１９１の判別結果に基づいて、座標３１Ｂ（座標（ｘ９，ｙ９））から座標３１Ｃ（座標（ｘ１４，ｙ１４））までユーザがドラッグ操作を行ったことを検出する。移動方向検出部１９３は、初期タッチ位置の座標３１Ａを起点として、座標３１Ａと座標３１Ｃとによって規定されるベクトル３２Ｃ（（ｙ１４−ｙ０）／（ｘ１４−ｘ０））を、ゲームキャラクタを移動させる方向として検出する。

このように、移動方向検出部１９３は、ユーザの指が接近していない状態からタッチスクリーン１３０に接近したことを検出した第１のタッチ位置から、接近していることを検出したまま第２のタッチ位置へ検出位置が移動した場合に、接近していることを検出している間、第１のタッチ位置を起点とし第２のタッチ位置へ向かう方向である操作方向を、ゲームキャラクタＣＡ１の仮想空間における移動方向として決定する。

（操作オブジェクト）
図６はドラッグ操作時に表示されるオブジェクトの一例である。ユーザの入力済みの入力操作を示すオブジェクトを操作オブジェクトという。図６の状態（Ａ）は、ドラッグ操作の初期タッチ位置に表示されるオブジェクトの一例である。図６の状態（Ａ）に示されるように、操作オブジェクト４００は、固定円４１０、および当該固定円４１０の内部に位置する弾性表示オブジェクト４２０を備えている。操作オブジェクト４００は、ユーザの指がタッチスクリーン１３０に接近したことが検知されるとタッチスクリーン１３０に表示される。弾性表示オブジェクト４２０は、指接触時の初期形状として、タッチ位置の周囲に円形を有するように形成される。なお、図６では、弾性表示オブジェクト４２０は、タッチ位置を中心に円形を形成しているが、必ずしもこれに限定されない。例えば、弾性表示オブジェクト４２０は、初期タッチ位置から一定距離だけ上部または下部にずらして表示してもよい。表示位置を一定距離だけずらすことにより、円形の弾性表示オブジェクト４２０を表示する際に、ユーザの指で隠れてしまうのを防止することができる。

図６の状態（Ｂ）は、初期タッチ位置からドラッグ操作したときに表示されるオブジェクトの一例である。図６の状態（Ｂ）に示されるように、ユーザがタッチスクリーン１３０上でドラッグ操作（タッチスクリーン１３０上において指を第1のタッチ位置から第２のタッチ位置に移動させる操作）を行うと、ユーザの指に引っ張られるような弾性変形をした弾性表示オブジェクト４２０が表示される。弾性表示オブジェクト４２０は、ドラッグ操作の第1のタッチ位置に位置しその位置が固定されている基部４３０と、ドラッグ操作の第２のタッチ位置付近に位置する先端部４５０と、基部４３０と先端部４５０との間を接続する接続部４４０とを含むように構成される。このように、弾性表示オブジェクト４２０は、ドラッグ操作がされた方向に弾性的に延ばすように表示される。なお、図６の状態（Ｂ）では、基部４３０が先端部４５０よりも大きくなるように弾性表示オブジェクト４２０を表示しているが、これに限定されない。例えば、先端部４５０を基部４３０よりも大きくした弾性表示オブジェクト４２０を表示してもよい。また、ユーザが指を接触状態に維持しつつタッチスクリーン１３０上を更に移動させた場合、先端部４５０もそれに追従して更に移動し、弾性表示オブジェクト４２０の延びる向きも変化する。

図６の状態（Ｃ）は、ユーザの指がタッチスクリーン１３０から離れたときに表示されるオブジェクトの一例である。図６の状態（Ｃ）に示されるように、ユーザによるドラッグ操作が終了した際に（即ち、タッチスクリーン１３０からユーザの指が離れた際に）、弾性変形した弾性表示オブジェクト４２０が、その復元力に従って、接触開始点に向けて段階的に萎縮することにより、図６の状態（Ａ）に示される初期形状に復元するように表示される。この際、図示されるように、復元力の反動により弾性表示オブジェクト４２０の伸張方向とは逆の萎縮方向において固定円４１０からはみ出すように表示され、その後に初期形状に復元する。なお、図示された弾性表示オブジェクト４２０は復元に伴って変形しているが、これに限定されない。例えば、このような変形を行わずに弾性表示オブジェクト４２０を初期形状に復元させ、弾性表示オブジェクト４２０の位置を伸張方向とは逆の萎縮方向に震わせるようにずらすこととしてもよい。

図７はドラッグ操作時に表示されるオブジェクトの一例である。図７の状態（Ａ）は、弾性表示オブジェクトの画像例である。図７の状態（Ａ）に示めされるように、弾性表示オブジェクトは略正方形状の画像７５０として生成され、ゲーム画像の一部として重畳される。画像７５０は、半透明領域７６０および透明領域７７０を含む。半透明領域７６０は弾性表示オブジェクトの基本表示領域である。

図７の状態（Ａ）は、状態（Ｂ）に示されるように、略正方形のメッシュ領域に収容され、複数のメッシュ７１０に分割されたポリゴンとして形成される。一例として、画像７５０は、４×４＝１６メッシュに分割され、弾性オブジェクトを収容している。メッシュに分割する数は限定的でないことが当業者に理解される。そして、弾性表示オブジェクトの変形は、画像７５０をゴムシートの如く伸張する処理、特に、メッシュ毎に伸張する物理演算処理を仮想的に実施することにより実現される。

図８は、ドラッグ操作時に表示されるオブジェクトの変形を説明する図である。図８の状態（Ａ）及び状態（Ｂ）に示されるように、弾性表示オブジェクトは、複数のメッシュ７１０に分割された板状のポリゴン７００の各頂点７２０の座標を動かすことによって弾性変形を表現する。各頂点７２０はメッシュ状に配置されており、任意の頂点７２０Ａの座標がドラッグ操作によって移動された場合、その他の頂点７２０も頂点７２０Ａに関する移動ベクトル（例えば、移動方向および移動距離）に応じて座標が変更される。例えば、頂点７２０Ａ以外の頂点７２０の移動距離は、頂点７２０Ａからの距離によって重み付けをしてもよい。即ち、図８の状態（Ｂ）に示されるように、頂点７２０Ａからの距離が大きくなるにつれて（頂点７２０Ａから離れるにつれて）座標の変化量が小さくなるようにしてもよい。なお、図８の状態（Ｂ）における白丸は、変形前の（即ち、図８の状態（Ａ）の）頂点の位置を表している。

これにより、図７の状態（Ｃ）に示されるように、ドラッグ操作の方向に沿ってタッチの開始点からタッチの終了点に向けて伸張させることにより、変形した弾性オブジェクト４２０ａ’を形成する。図７の状態（Ｃ）の例では、分割された複数のメッシュの各頂点の座標が移動した際に、当該複数のメッシュの各々は、列（＃１〜＃４）ごとに同一の長方形状を維持したまま（例えばメッシュ＃１Ａ〜＃１Ｄは全て同一の長方形状を有している。）、タッチの終了点に近い列（＃１）のメッシュほど、遠い列（＃４）のメッシュと比べて累進的に長く伸張される。一例として、ドラッグ操作による移動距離Ｌに応じて、各列の伸張率を加重配分するように構成されてもよい。

図７の状態（Ｃ）の例では、各列について、＃４が１０％、＃３が１５％、＃２が３０％、＃１が４５％となるように配分されている（合計で１００％）。更に例えば移動距離を２Ｌとした場合には、＃４が１％、＃３が４％、＃２が３５％、＃１が６０％といった具合に＃１を更に大きくするように加重配分されてもよい。

図９は、オブジェクトの変形時おけるポリゴン方向調整処理を説明する図である。図９の状態（Ａ）及び状態（Ｂ）に示されるように、ポリゴンの方向が操作方向となるように、ポリゴンの回転による調整処理（ポリゴン方向調整処理）が実施される。当該ポリゴン方向調整処理が実施されることにより、変形されたオブジェクトは、ドラッグ操作時の指の移動距離に拘わらず、ドラッグ操作方向に対して常に一定の幅を有して変形可能となる。オブジェクトは、常に一定の幅を有するように構成可能な点、および初期タッチ位置から継続するタッチ位置に向けて伸張してオブジェクトを変形することにより、非常に滑らかな曲線形状を有することが可能となる点において、従来技術と異なる表示とすることができる。

図１０は、オブジェクトの変形後にタッチ位置が更新された場合について示す模式図である。図１０の状態（Ａ）及び状態（Ｂ）に示されるように、ユーザが接触終了点１（状態（Ａ））から指を離すことなく、更に他の接触終了点２（状態（Ｂ））まで指をタッチスクリーン１３０に接触させながら移動させた場合には、継続してオブジェクトを変形させる。即ち、ドラッグ操作における接触開始点に対する、接触終了点１と接触終了点２の間の角度だけポリゴンの方向を回転させて、変形した弾性オブジェクト４２０ａ’を回転し、次いで、当該回転した弾性オブジェクトの形状を引き続き接触終了点２まで伸張して、更に変形した弾性オブジェクト４２０ａ’’を形成する。

（仮想カメラの制御）
図１１は、カメラ配置制御部１９４が仮想カメラＶＣを制御する処理を説明する図である。図１１では、仮想カメラＶＣがゲームキャラクタＣＡ１を背後から追尾するカメラワークを説明する。図１１の状態（Ａ）では、ゲームキャラクタＣＡ１が方向Ｄ１（移動方向）に向かって移動する様子が示されている。例えば、入力操作受付部１９１がユーザによる入力操作をドラッグ操作と判定し、移動方向検出部１９３がゲームキャラクタＣＡ１の移動方向を方向Ｄ１と検出したとき、オブジェクト制御部１９５は、ゲームキャラクタＣＡ１の正面を方向Ｄ１に向け、ゲームキャラクタＣＡ１を方向Ｄ１へ移動させる。カメラ配置制御部１９４は、ゲームキャラクタＣＡ１の背後から追尾するように、仮想カメラＶＣの配置位置及び撮影方向を制御する。ゲームキャラクタＣＡ１の背後から追尾する場合、カメラ配置制御部１９４は、撮影方向ＤＶとゲームキャラクタＣＡ１の向き（方向Ｄ１）とがなす角度θ１（対応関係）は０°となる。カメラ配置制御部１９４は、カメラ視界の中央付近にゲームキャラクタＣＡ１が表示されるように、仮想カメラＶＣを配置する。

図１１の状態（Ｂ）では、ユーザによるドラッグ操作により移動方向が方向Ｄ１から方向Ｄ２へ変更された様子を示す。この場合、オブジェクト制御部１９５は、ゲームキャラクタＣＡ１の正面を方向Ｄ２に向け、ゲームキャラクタＣＡ１を方向Ｄ２へ移動させる。このとき、カメラ配置制御部１９４は、撮影方向ＤＶとゲームキャラクタＣＡ１の向き（方向Ｄ１）とがなす角度θ１（対応関係）が０°となるように、仮想カメラＶＣの配置位置及び撮影方向ＤＶを変更する。なお、カメラ配置制御部１９４は、変化前後の移動方向の変化角度θ２を検出し、検出された変化角度θ２を仮想カメラＶＣの変化角度θ３としてもよい。

このように、カメラ配置制御部１９４は、ユーザによる入力操作に応じて移動方向が変化するゲームキャラクタＣＡ１を背後から追尾するようなカメラワークを提供する。

（移動操作時の画面例）
図１２は、ユーザによる入力操作に応じて変化するカメラワーク及び操作オブジェクトを説明する図である。画面例（Ａ）〜画面例（Ｃ）は、タッチスクリーン１３０に表示された画像である。画面例（Ａ）〜画面例（Ｃ）では、表示制御部１９６が、カメラ配置制御部１９４によりゲームキャラクタＣＡ１の背後から撮影された画像を、タッチスクリーン１３０に表示させている。入力操作受付部１９１によりユーザによる入力操作が受け付けられたとき、オブジェクト制御部１９５は、ユーザの入力操作に応じて操作オブジェクトを生成する。表示制御部１９６は、仮想カメラＶＣにより撮影された画像上に操作オブジェクトを重畳させて、タッチスクリーン１３０に表示させる。

図１２の画面例（Ａ）は、ユーザがタッチスクリーン１３０に指などを接近させた操作をしたときの画面の一例である。入力操作受付部１９１によりユーザがタッチスクリーン１３０の第１位置３００Ａに指などを接近させた操作をしたと判定されたとき、オブジェクト制御部１９５は、入力操作に応答して円形の操作オブジェクト３００を生成する。表示制御部１９６は、生成された円形の操作オブジェクト３００をタッチ位置である第１位置３００Ａに表示させる。図１２の画面例（Ａ）では、撮影方向を方向ＶＤ１、ゲームキャラクタＣＡ１の向きを方向ＣＤ１で示している。撮影方向である方向ＶＤ１とゲームキャラクタＣＡ１の向きである方向ＣＤ１の対応関係（なす角度）は０°である。

図１２の画面例（Ｂ）は、図１２の画面例（Ａ）の第１位置３００Ａを起点としてユーザがドラッグ操作をしたときの画面の一例である。入力操作受付部１９１は、起点である第１位置３００Ａから終点である第２位置３００Ｂまでのドラッグ操作を受け付ける。入力操作受付部１９１によりドラッグ操作が受け付けられた場合、オブジェクト制御部１９５は、ドラッグ操作の操作結果を示す操作オブジェクト３００を生成する。ドラッグ操作の操作結果を示す操作オブジェクト３００は、ドラッグ操作の起点となる位置と終点となる位置とを関連付けることで、操作結果（例えば操作方向）を表現する。図１２の画面例（Ｂ）の例では、オブジェクト制御部１９５は、起点及び終点に対応する位置に操作オブジェクト３００の端部がそれぞれ位置するように、第１位置３００Ａから第２位置３００Ｂに至るまで引き延ばされた操作オブジェクト３００を生成している。表示制御部１９６は、引き延ばされた操作オブジェクト３００をタッチスクリーン１３０に表示させる。この状態における操作方向及び撮影方向が図示されている。操作方向は方向ＳＤ１（図中右上方向）であり、撮影方向は方向ＶＤ１（図中上方向）である。方向ＳＤ１と方向ＶＤ１とのなす角はθ４である。

さらに、移動方向検出部１９３は、ドラッグ操作が受け付けられた場合、ゲームキャラクタＣＡ１の移動方向を、操作方向である方向ＳＤ１と同一の方向に決定する。オブジェクト制御部１９５は、ゲームキャラクタＣＡ１を移動方向に向け、移動を開始させる。

図１２の画面例（Ｂ）においてゲームキャラクタＣＡ１の向きが変更されると、カメラ配置制御部１９４は、ゲームキャラクタＣＡ１の背後を追尾するように仮想カメラＶＣの配置位置及び撮影方向を制御する。具体的には、方向ＳＤ１と方向ＶＤ１とのなす角であるθ４分だけ、撮影方向が注視点（ゲームキャラクタＣＡ１）を中心として右回転する。さらに、仮想カメラＶＣの配置位置は、ゲームキャラクタＣＡ１又は移動目的地が画面の中央にくるように制御される。これにより、タッチスクリーン１３０に表示される画像は、画面例（Ｂ）から画面例（Ｃ）へ遷移する。

このように、ユーザによる入力操作に応じてゲームキャラクタを背後から追尾するカメラワークが実行されるため、臨場感のあるゲームが提供される。また、操作方向が画面上に示されることにより、ユーザにとって理解し易いゲームが提供される。

（移動操作時のフローチャート）
図１３は、移動操作時の処理を説明するフローチャートである。図１３のフローチャートは、制御部１９０がゲームプログラム１５１を実行することによりアクションゲームを進行させる処理を示すフローチャートである。

ステップＳ１０において、制御部１９０は、入力操作が受け付けられたか否かを判定する。

入力操作が受け付けられたと判定されると（ステップＳ１０：ＹＥＳ）、ステップＳ１２において、制御部１９０は、初期タッチ位置に操作オブジェクトを表示させる（図１２の画面例（Ａ）に対応する）。オブジェクト制御部１９５は、入力操作に応答して円形の操作オブジェクト３００を生成する。表示制御部１９６は、生成された円形の操作オブジェクト３００をタッチ位置である第１位置３００Ａに表示させる。初期タッチ位置は、操作方向を決定する起点（操作オブジェクトの端部位置）の初期値となる。

ステップＳ１４において、制御部１９０は、入力操作がドラッグ操作であるか否かを判定する。制御部１９０は、タッチスクリーン１３０の履歴情報を用いて、ドラッグ操作であるか否かを判定する（図４参照）。

入力操作がドラッグ操作であると判定されると（ステップＳ１４：ＹＥＳ）、ステップＳ１６において、制御部１９０は、起点（第１位置３００Ａ）からドラッグ方向（方向ＳＤ１）へ伸びる操作オブジェクト３００を表示させる（図１２の画面例（Ｂ）に対応する）。制御部１９０は、タッチスクリーン１３０の履歴情報を用いて、操作オブジェクト３００を生成して、タッチスクリーン１３０に表示させる。

ステップＳ１８において、制御部１９０は、タッチスクリーン１３０の履歴情報を用いて、ドラッグ操作のドラッグ方向（方向ＳＤ１）を検出する（図５参照）。そして、制御部１９０は、ドラッグ方向（方向ＳＤ１）に基づいてゲームキャラクタＣＡ１の移動方向及びゲームキャラクタＣＡ１の向きを決定する。そして、制御部１９０は、移動方向に従ってゲームキャラクタＣＡ１をドラッグ方向（方向ＳＤ１）へ移動させる（図１２の画面例（Ｂ）に対応する）。さらに、制御部１９０は、仮想カメラＶＣの撮影方向をゲームキャラクタＣＡ１の向きと一致させる（図１２の画面例（Ｃ）に対応する）。

ステップＳ２０において、制御部１９０は、ドラッグ操作が完了したか否かを判定する。ドラッグ操作が完了していないと判定されると（ステップＳ２０：ＮＯ）、制御部１９０は、上述したステップＳ１６及びステップＳ１８を再実行する。これにより、ユーザの指が接近していることをタッチスクリーン１３０が検出している間、つまり、ドラグ操作が継続されている間、操作オブジェクトが表示され、ゲームキャラクタＣＡ１が移動することになる。

ドラッグ操作が完了したと判定されると（ステップＳ２０：ＹＥＳ）、ステップＳ２２として、制御部１９０は、ゲームキャラクタＣＡ１の移動を終了する。そして、ステップＳ２４として、制御部１９０は、操作オブジェクト３００の表示を終了する。

一方、入力操作がドラッグ操作でないと判定されると（ステップＳ１４：ＮＯ）、ステップＳ２６において、制御部１９０は、入力操作に応じた動作をゲームキャラクタＣＡ１に実行させる。例えば、タップ操作であれば、攻撃対象を決定し、ゲームキャラクタＣＡ１に攻撃動作を実行させる。そして、ステップＳ２４として、制御部１９０は、操作オブジェクト３００の表示を終了する。

入力操作が受け付けられていないと判定された場合（ステップＳ１０：ＮＯ）、又は、操作オブジェクト３００の表示を終了すると、図１３に示されるフローチャートは終了する。そして、制御部１９０は、所定の条件が満たされるまで図１３に示されるフローチャートを最初から実行する。以上で、移動操作時の一連の処理が終了する。

（交戦時のカメラワークの概要）
一般的なアクションゲームにおいては、ゲームキャラクタＣＡ１が仮想空間のフィールドを移動するシーンだけでなく、仮想空間に配置された敵キャラクタ（対象キャラクタの一例）と交戦するシーンが存在する。

ユーザは、シーンに応じて、仮想空間においてキャラクタを移動させる移動操作だけでなく、ゲームキャラクタＣＡ１に攻撃動作を行わせる攻撃動作を入力する。移動操作は、上述のとおり、ゲームキャラクタの移動方向を指示する入力操作であり、方向性のある操作である。移動操作の一例としては、所定条件下のドラッグ操作又はフリック操作である。一方、攻撃操作は、ゲームキャラクタＣＡ１に攻撃動作を行わせる入力操作である。基本的な攻撃操作の一例としては、タップ操作である。なお、攻撃操作には、タップ操作と組み合わされたフリック操作を含む。詳細については後述する。

カメラ配置制御部１９４は、ユーザによる入力操作に応じて移動方向が変化するゲームキャラクタＣＡ１を背後から追尾するようなカメラワークを提供する。つまり、カメラ配置制御部１９４が仮想カメラＶＣの撮影方向を変更する契機（トリガ）は、ユーザによる移動操作である。ここで、カメラ配置制御部１９４は、仮想カメラＶＣの撮影方向を変更する契機（トリガ）として攻撃操作をさらに含む。これにより、敵キャラクタとの交戦時において、臨場感、迫力、キャラクタとの一体感などを演出するためのカメラワークを瞬時に提供することができる。

（交戦時の画面例）
図１４は、交戦時における仮想カメラＶＣの撮影方向を説明するための画面例である。図１４の画面例（Ａ）〜画面例（Ｄ）は、タッチスクリーン１３０に表示された画像である。画面例（Ａ）〜画面例（Ｄ）では、表示制御部１９６が、カメラ配置制御部１９４により、ゲームキャラクタＣＡ１を撮影した画像を、タッチスクリーン１３０に表示させている。入力操作受付部１９１によりユーザによる入力操作が受け付けられたとき、オブジェクト制御部１９５は、ユーザの入力操作に応じて操作オブジェクトを生成する。表示制御部１９６は、仮想カメラＶＣにより撮影された画像上に操作オブジェクトを重畳させて、タッチスクリーン１３０に表示させる。

図１４の画面例（Ａ）は、移動操作時において敵キャラクタＣＡ２が視界に入ったときの画面の一例である。図１４の画面例（Ａ）では、撮影方向を方向ＶＤ１、ゲームキャラクタＣＡ１の向きを方向Ｄ３で示している。

図１４の画面例（Ｂ）は、図１４の画面例（Ａ）の状況において、攻撃操作であるタップ操作が行われたときの画面の一例である。オブジェクト制御部１９５は、タップ操作に応答して円形の操作オブジェクト３００を生成する。表示制御部１９６は、生成された円形の操作オブジェクト３００をタッチ位置に表示させる。このとき、敵キャラクタＣＡ２とゲームキャラクタＣＡ１との距離が予め定められた距離内にある場合、敵キャラクタＣＡ２を攻撃対象として決定する（ロックオン）。ゲームキャラクタＣＡ１は、ロックオンされた敵キャラクタＣＡ２の方向Ｄ４へ向けられる。カメラ配置制御部１９４は、仮想カメラＶＣがゲームキャラクタＣＡ１を背後から撮影するように、仮想カメラＶＣを制御する。仮想カメラＶＣの撮影方向は、ゲームキャラクタＣＡ１の向きである方向Ｄ４と同一方向である方向ＶＤ２へ変更される。これにより、タッチスクリーン１３０に表示される画像は、図１４の画面例（Ｂ）は図１４の画面例（Ｃ）へ遷移する。

図１４の画面例（Ｃ）は、攻撃操作に応じて仮想カメラＶＣの撮影方向が変更されたときの画面の一例である。そして、図１４の画面例（Ｄ）は、敵キャラクタに対して攻撃操作を実行しているときの画面の一例である。このように、タップ操作という方向性の無い操作がなされた場合であっても、仮想カメラＶＣの撮影方向が変更され、臨場感のある交戦画面が提供される。

（攻撃操作時のフローチャート）
図１５は、攻撃操作時の処理を説明するフローチャートである。図１５のフローチャートは、制御部１９０がゲームプログラム１５１を実行することによりアクションゲームを進行させる処理を示すフローチャートである。

ステップＳ３０において、制御部１９０は、入力操作が受け付けられたか否かを判定する。制御部１９０は、入力操作として、仮想空間においてゲームキャラクタＣＡ１を移動させる移動操作及びゲームキャラクタＣＡ１に攻撃動作を行わせる攻撃操作を受け付けることができる。

入力操作が受け付けられたと判定されると（ステップＳ３０：ＹＥＳ）、ステップＳ３２において、制御部１９０は、初期タッチ位置に操作オブジェクトを表示させる（図１４の画面例（Ｂ）に対応する）。オブジェクト制御部１９５は、入力操作に応答して円形の操作オブジェクト３００を生成する。表示制御部１９６は、生成された円形の操作オブジェクト３００をタッチ位置に表示させる。

ステップＳ３４において、制御部１９０は、入力操作がタップ操作であるか否かを判定する。制御部１９０は、タッチスクリーン１３０の履歴情報を用いて、タップ操作であるか否かを判定する（図４参照）。

入力操作がタップ操作であると判定されると（ステップＳ３４：ＹＥＳ）、ステップＳ３６において、制御部１９０は、攻撃範囲内に敵キャラクタが存在するか否かを判定する。攻撃範囲は、ゲームキャラクタＣＡ１を基準として予め設定される。

攻撃範囲内に敵キャラクタが存在すると判定されると（ステップＳ３６：ＹＥＳ）、ステップＳ３８において、制御部１９０は、攻撃対象となる敵キャラクタを特定する。制御部１９０は、攻撃範囲内に複数の敵キャラクタが存在する場合には、例えばゲームキャラクタＣＡ１に最も近接した敵キャラクタを攻撃対象にする。

ステップＳ４０として、制御部１９０は、ゲームキャラクタＣＡ１を攻撃動作の対象となる敵キャラクタＣＡ２の位置と、ゲームキャラクタＣＡ１の位置とに基づいて、ゲームキャラクタＣＡ１を敵キャラクタＣＡ２に向けさせる（図１４の画面例（Ｂ）に対応する）。

ステップＳ４２として、制御部１９０は、仮想カメラＶＣの撮影方向をゲームキャラクタＣＡ１の向きに基づいて決定する。制御部１９０は、ゲームキャラクタＣＡ１の向きに対して予め定められた方向からキャラクタを撮影するように制御する。ゲームキャラクタＣＡ１の向きに対して予め定められた方向とは、例えば、ゲームキャラクタＣＡ１の背後から撮影する方向、ゲームキャラクタＣＡ１の横から撮影する方向、ゲームキャラクタＣＡ１の上から撮影する方向などである。具体的な一例として、制御部１９０は、仮想カメラＶＣの撮影方向をゲームキャラクタＣＡ１の向きと一致させ、ゲームキャラクタＣＡ１の背後から撮影するように、仮想カメラＶＣを制御する（図１４の画面例（Ｃ）に対応する）。

ステップＳ４４として、制御部１９０は、ゲームキャラクタＣＡ１に攻撃動作を実行させる（図１４の画面例（Ｄ）に対応する）。ステップＳ４６として、制御部１９０は、操作オブジェクト３００の表示を終了する。

一方、入力操作がタップ操作でないと判定されると（ステップＳ３４：ＮＯ）、ステップＳ４８において、制御部１９０は、入力操作に応じた動作をゲームキャラクタＣＡ１に実行させる。このとき、入力操作がドラッグ操作などの移動操作であれば、制御部１９０は、図１３で説明したとおり、ゲームキャラクタＣＡ１を移動させるとともに、仮想空間を移動するゲームキャラクタＣＡ１を追尾するように仮想カメラＶＣを制御する。そして、ステップＳ４６として、制御部１９０は、操作オブジェクト３００の表示を終了する。

また、攻撃範囲内に敵キャラクタが存在しないと判定されると（ステップＳ３６：ＮＯ）、ステップＳ４６として、制御部１９０は、操作オブジェクト３００の表示を終了する。

入力操作が受け付けられていないと判定された場合（ステップＳ３０：ＮＯ）、又は、操作オブジェクト３００の表示を終了すると、図１５に示されるフローチャートは終了する。そして、制御部１９０は、所定の条件が満たされるまで図１５に示されるフローチャートを最初から実行する。以上で、攻撃操作時の一連の処理が終了する。

（交戦時における連撃攻撃）
アクションゲームにおいては、予め定められた期間内に攻撃操作を連続して受け付けた場合、連撃攻撃（いわゆるコンボ攻撃）を発生させることがある。このようなコンボ攻撃の内容は、ゲーム情報１５２又はゲーム情報２５２にコンボデータとして定義されている。コンボ攻撃に多様性を持たせるために、コンボ攻撃中の攻撃操作に方向性のある入力操作を採用することがある。例えば、タップ操作、タップ操作、フリック操作という一連の入力操作に基づくコンボ攻撃である。

図１６は、オブジェクト制御部１９５がコンボデータに基づいてゲームキャラクタＣＡ１に攻撃動作を実行させたときのアクション（モーションともいう）の一例を示す図である。図１６の状態（Ａ）は、アクションａ１を示す。図１６の状態（Ｂ）は、アクションａ２を示す。図１６の状態（Ｃ）は、アクションａ３を示す。入力操作受付部１９１がタップ操作を受け付けると、オブジェクト制御部１９５は、図１６の状態（Ａ）に示されるように、ゲームキャラクタＣＡ１にアクションａ１を実行させる。続いて、入力操作受付部１９１が予め定められた期間内に再びタップ操作を受け付けると、オブジェクト制御部１９５は、図１６の状態（Ｂ）に示すアクションａ２をゲームキャラクタＣＡ１に実行させる。続いて、入力操作受付部１９１が予め定められた期間内にフリック操作を受け付けると、オブジェクト制御部１９５は、図１６の状態（Ｃ）に示すアクションａ３をゲームキャラクタＣＡ１に実行させる。アクションａ３は、アクションａ１、ａ２より演出を派手にしたり、攻撃力を大きくしたりするように設定してもよい。また、アクションａ３のためのフリック操作の代わりに、タップ操作が３回続けられることによって、オブジェクト制御部１９５は、他の演出が派手であったり攻撃力が大きかったりするアクションをゲームキャラクタＣＡ１に実行させてもよい。一実施形態によれば、タッチスクリーン１３０によるタッチ操作でコンボ攻撃をゲームキャラクタＣＡ１に実行させるゲームであっても、コンボの流れを分岐させることができる。このように、コンボ攻撃中の攻撃操作に方向性のある入力操作を採用することで、ユーザは多様な操作によって次々と流れるようにゲームキャラクタＣＡ１に攻撃させることができる。よって、ゲームの趣向性が向上する。

（連撃攻撃時のカメラワーク）
連撃攻撃時においても、制御部１９０は、図１５に示された攻撃操作時のフローチャートに沿って処理を実行する。入力操作が連撃攻撃の最初の攻撃操作であるか否かは、２回目の攻撃操作が入力されることによって初めて確定する。したがって、タップ操作が通常のタップ操作であるか連撃操作となるかに関わらず、制御部１９０は、図１５に示された攻撃操作時のフローチャートに沿って処理を実行する。つまり、制御部１９０は、事後的に連撃操作となる最初のタップ操作に応じて、図１５に示された攻撃操作時のフローチャートに沿って処理を実行する。

このため、ステップＳ４０として、制御部１９０は、所定期間内に連続する攻撃操作が受け付けられた場合、所定期間内に連続する攻撃操作のうち最初の攻撃動作の対象となる敵キャラクタＣＡ２にゲームキャラクタＣＡ１を向かせることになる。そして、ステップＳ４２として、制御部１９０は、予め定められた方向からゲームキャラクタＣＡ１を撮影するように仮想カメラＶＣを制御する。

そして、制御部１９０は、２回目以降のタップ操作が行われた場合、所定期間前にタップ操作が行われていたか否かを判定する。制御部１９０は、所定期間前にタップ操作が行われていない場合、２回目のタップ操作については、図１５に示された攻撃操作時のフローチャートに沿って処理を実行する。この場合、制御部１９０は、２回目のタップ操作によって攻撃対象となる敵キャラクタＣＡ２にゲームキャラクタＣＡ１を向かせることになる。そして、ステップＳ４２として、制御部１９０は、予め定められた方向からゲームキャラクタＣＡ１を撮影するように仮想カメラＶＣを制御する。

一方、制御部１９０は、所定期間前にタップ操作が行われていた場合、当該タップ操作については、図１５に示された攻撃操作時のフローチャートのうち、ステップＳ４２については実行しない。つまり、制御部１９０は、予め定められた期間内に２回目以降の攻撃操作が行われた場合には、最初の攻撃操作に基づいて決定された仮想カメラＶＣの撮影方向を、所定期間内に連続する攻撃操作を受け付けている間は変更しない。これにより、ゲームキャラクタＣＡ１の攻撃によって敵キャラクタＣＡ２の位置が変化し、それに伴ってゲームキャラクタＣＡ１の向きが変更された場合であっても、仮想カメラＶＣの撮影方向は変更されないことになる。制御部１９０は、ユーザにキャラクタの向きを一度理解させた後は、固定されたアングルで連撃の様子を提供することにより、ユーザがキャラクタの向きを見失うことが無い状態で、連撃中のキャラクタや対象キャラクタを種々の角度から確認させることができる。

同様に、制御部１９０は、コンボ攻撃中の攻撃操作に方向性のある入力操作が含まれていた場合であっても、最初の攻撃操作に基づいて決定された仮想カメラＶＣの撮影方向を、所定期間内に連続する攻撃操作を受け付けている間は変更しない。以下では、フリック操作がコンボ攻撃中の攻撃操作に含まれる場合の例を詳細に説明する。

図１７は、フリック操作時の処理を説明するフローチャートである。図１７のフローチャートは、制御部１９０がゲームプログラム１５１を実行することによりアクションゲームを進行させる処理を示すフローチャートである。

ステップＳ５０において、制御部１９０は、入力操作が受け付けられたか否かを判定する。制御部１９０は、入力操作として、仮想空間においてゲームキャラクタＣＡ１を移動させる移動操作及びゲームキャラクタＣＡ１に攻撃動作を行わせる攻撃操作を受け付けることができる。

入力操作が受け付けられたと判定されると（ステップＳ５０：ＹＥＳ）、ステップＳ３２において、制御部１９０は、初期タッチ位置に操作オブジェクトを表示させる（図１４の画面例（Ｂ）に対応する）。オブジェクト制御部１９５は、入力操作に応答して円形の操作オブジェクト３００を生成する。表示制御部１９６は、生成された円形の操作オブジェクト３００をタッチ位置に表示させる。

ステップＳ５４において、制御部１９０は、入力操作がフリック操作であるか否かを判定する。制御部１９０は、タッチスクリーン１３０の履歴情報を用いて、フリック操作であるか否かを判定する（図４参照）。

入力操作がフリック操作であると判定されると（ステップＳ５４：ＹＥＳ）、ステップＳ５６において、制御部１９０は、初期タッチ位置からフリック方向へ延びる操作オブジェクトを表示させる。

ステップＳ５８において、制御部１９０は、ゲームキャラクタＣＡ１が向いている方向を特定する。例えば記憶部１５０には、ゲームキャラクタＣＡ１の顔が向いている方向または直前の移動操作の進行方向等を示す情報が記憶されている。制御部１９０は、ゲームキャラクタＣＡ１に実行させたアクション、他のオブジェクトからの作用などに基づいて、記憶部１５０に記憶された情報が示す方向の中からゲームキャラクタＣＡ１が向いている方向を選択する。次に、制御部１９０は、選択した結果に基づき、記憶部１５０を参照してゲームキャラクタＣＡ１の向いている方向を特定する。

ステップＳ６０において、制御部１９０は、フリック操作の方向とタッチスクリーン１３０に表示される画面においてゲームキャラクタＣＡ１が向いている方向とを比較する。

ステップＳ６２において、制御部１９０は、ステップＳ６０における比較結果に応じたアクションを、ゲームキャラクタＣＡ１に実行させる。この処理の詳細は、図１８に示されたフローチャートを用いて後述する。

ステップＳ４６として、制御部１９０は、操作オブジェクト３００の表示を終了する。

一方、入力操作がフリック操作でないと判定されると（ステップＳ５４：ＮＯ）、ステップＳ６６において、制御部１９０は、入力操作に応じた動作をゲームキャラクタＣＡ１に実行させる。そして、ステップＳ４６として、制御部１９０は、操作オブジェクト３００の表示を終了する。

入力操作が受け付けられていないと判定された場合（ステップＳ５０：ＮＯ）、又は、操作オブジェクト３００の表示を終了すると、図１７に示されるフローチャートは終了する。そして、制御部１９０は、所定の条件が満たされるまで図１７に示されるフローチャートを最初から実行する。以上で、攻撃操作時の一連の処理が終了する。

図１８は、図１７に示されたフリック操作に基づく動作処理を説明するフローチャートである。制御部１９０は、図１８に示されるフローチャートに従い、比較結果に応じたアクションをゲームキャラクタＣＡ１に実行させる。

ステップＳ７０において、制御部１９０は、図１８に示されたステップＳ５０においてフリック操作を受け付ける前の所定期間内に、攻撃動作を行なうためのタップ操作を受け付けたか否かを判定する。

フリック操作の所定期間前に攻撃動作を行なうためのタップ操作を受け付けたと判定されると（ステップＳ７０：ＹＥＳ）、ステップＳ７２において、制御部１９０は、フリック操作の方向はゲームキャラクタＣＡ１が向いている方向と所定関係にあるか否かを判定する。所定関係は、例えばゲームキャラクタＣＡ１が向いている方向を軸として、フリック操作の方向が当該軸から左右一定の範囲（例えば、左右それぞれに３０度以内、４５度以内等）となることとしてもよい。

フリック操作の方向はゲームキャラクタＣＡ１が向いている方向により定まる一定範囲の方向に含まれていると判定されると（ステップＳ７２：ＹＥＳ）、ステップＳ７４として、制御部１９０は、前回の攻撃動作に対応する操作がタップ操作であり、且つ、今回の操作がフリック操作であることに基づく攻撃動作を、ゲームキャラクタＣＡ１に実行させる。このように、連続してゲームキャラクタＣＡ１に攻撃動作を実行させる場合、毎回同じ攻撃動作をゲームキャラクタＣＡ１に実行させるのではなく、異なる攻撃動作をゲームキャラクタＣＡ１に実行させることができる。従って、攻撃動作が多様になる。ステップＳ７２が終了すると、図１８に示されるフローチャートが終了する。

一方、フリック操作の方向はゲームキャラクタＣＡ１が向いている方向と所定関係にないと判定されると（ステップＳ７２：ＮＯ）、ステップＳ７６として、制御部１９０は、ゲームキャラクタＣＡ１に、攻撃動作を実行することなくフリック操作の方向に移動するための回避動作を実行させる。それに続けて、ステップＳ７８として、制御部１９０は、ゲームキャラクタＣＡ１に攻撃動作を実行させる。ステップＳ７８において制御部１９０がゲームキャラクタＣＡ１に実行させる攻撃動作は、タップ操作に基づく攻撃動作とは異なってもよい。この場合、ゲームキャラクタＣＡ１による攻撃動作がより多様となり、ゲームの趣向性が向上する。ステップＳ７８が終了すると、図１８に示されるフローチャートが終了する。

一方、フリック操作の所定期間前に攻撃動作を行なうためのタップ操作を受け付けていないと判定されると（ステップＳ７０：ＮＯ）、ステップＳ８０において、制御部１９０は、ゲームキャラクタＣＡ１に回避動作を実行させ、攻撃動作を実行させない。そして、ステップＳ８２において、制御部１９０は、仮想カメラＶＣの向きをゲームキャラクタＣＡ１の向きに基づいて決定する。ステップＳ８２が終了すると、図１８に示されるフローチャートが終了する。

このように、制御部１９０は、ゲームキャラクタＣＡ１が向いている方向とフリック操作の方向とに応じて、ゲームキャラクタＣＡ１に攻撃動作を実行させたり回避動作を実行させたりするなど、アクションを分けることができるので、ゲームの趣向性が向上する。特に、攻撃対象に対する入力操作に多様性を持たせることができる。

また、制御部１９０は、コンボ攻撃の最初の攻撃操作に基づいて仮想カメラＶＣの撮影方向を決定し、コンボ攻撃中においては撮影方向を変更しない。このため、ユーザにゲームキャラクタＣＡ１の向きを一度理解させた後は、固定されたアングルで連撃の様子を提供することにより、フリック操作が入力し易くなる。

また、フリック操作は、ゲーム中の素早い操作が必要とされる場面において、ユーザが直感的に素早く入力する操作である。本実施形態では、フリック操作の方向に応じて攻撃動作または回避動作を選択できるため、直感的に攻撃と回避とを選択することができる。よって、ゲームの趣向性が向上する。

（コンボ攻撃のパターン）
コンボ攻撃は、上述した操作手順に限定されることはなく、種々の操作手順が採用され得る。コンボ攻撃の種類が増えるほどゲームキャラクタＣＡ１に多彩な攻撃をさせることができるので、ゲーム性が向上する。

図１９は、コンボ列を定義するテーブル群の一例である。このようなテーブル群は、ゲーム情報１５２又はゲーム情報２５２にコンボデータとして含まれる。図１９のテーブル例（Ａ）は、コンボの手順を定義するコンボテーブルＴＢ１である。図１９のテーブル例（Ａ）に示されるように、コンボテーブルＴＢ１は、コンボ列ごとに、操作内容の順番を定義する。コンボ列は、コンボが成立する手順通りに入力操作を並べた列である。一例として、「第一コンボ列」は、タップ操作が二回続けて入力されたときにコンボが成立することが定義されている。また、「第二コンボ列」は、タップ操作が三回続けて入力されたときにコンボが成立することが定義されている。また、「第三コンボ列」は、タップ操作が三回続けて入力されたときにコンボが成立することが定義されている。また、「第四コンボ列」は、タップ操作が二回続けて入力され、その後フリック操作が入力されたときにコンボが成立することが定義されている。また、「第五コンボ列」は、タップ操作が二回続けて入力され、その後フリック操作及びタップ操作が続けて入力されたときにコンボが成立することが定義されている。また、図示を省略するが、それぞれの入力操作には、入力操作を受け付け可能な時間が設定されている。つまり、コンボは、それぞれの受付時間内において上述した手順が実行されたときに成立する。なお、全ての入力操作に対して共通する受付時間が設定されていてもよい。以下では、このような時間的要素を含めたコンボの手順をコンボ条件ともいう。受付時間の詳細については後述する。

コンボ条件が満たされた場合、ゲーム上の効果が奏される。ゲーム上の効果は、コンボ列ごとに予め定められている。ゲーム上の効果の一例は、ゲームパラメータの増減である。ゲームパラメータは、例えば、攻撃ダメージ値、攻撃軽減値、ゲームキャラクタＣＡ１又は敵キャラクタの攻撃力、防御力、ＨＰ、属性などである。ゲーム上の効果の他の例は、ゲームキャラクタの攻撃モーションの変更である。ゲーム上の効果の一例として、ゲームキャラクタの攻撃モーションは、コンボ条件が満たされた場合と満たされていない場合とで変更されてもよい。なお、第一コンボ列〜第三コンボ列は、同じ入力操作が繰り返されることがある。この場合に、当該入力にゲーム上の効果を付加しない場合には、コンボの成立が判定されなくてもよい。

図１９のテーブル例（Ｂ）は、コンボ列と当該コンボ列のコンボ条件が満たされたときに奏されるゲーム上の効果とを関連付けたコンボテーブルＴＢ２である。図１９のテーブル例（Ｂ）に示されるように、コンボ列それぞれにゲーム上の効果が関連付けられている。一例として、「第一コンボ列」には、攻撃ダメージ値が１０％増加すること、及び、第二モーションで動作することがゲーム上の効果として関連付けられている。第一コンボ列のコンボ条件は、第一コンボ列の最後の手順である「タップ操作」時において満たされるため、このタップ操作時において、攻撃ダメージ値が１０％増加し、かつ、第二モーションとなることが定義されている。同様に、「第二コンボ列」には、攻撃ダメージ値が１５％増加すること、及び、第一モーションで動作することがゲーム上の効果として関連付けられている。「第三コンボ列」には、攻撃ダメージ値が２０％増加すること、及び、第二モーションで動作することがゲーム上の効果として関連付けられている。「第四コンボ列」には、攻撃ダメージ値が２５％増加すること、また、第三モーションで動作することがゲーム上の効果として関連付けられている。「第五コンボ列」には、攻撃ダメージ値が３０％増加すること、また、第三モーションで動作することがゲーム上の効果として関連付けられている。

（コンボ列の分岐）
図２０は、コンボ列の分岐を説明する図である。図２０の画面例（Ａ）〜画面例（Ｆ）は、タッチスクリーン１３０に表示された画像の一部である。画面例（Ａ）は、所定時間前に攻撃操作がない状態でタップ操作が行われた場合のゲームキャラクタＣＡ１のモーションを示している。

画面例（Ｂ）は、画面例（Ａ）で示すモーション中の受付時間内にタップ操作が行われた場合のゲームキャラクタＣＡ１のモーションを示している。つまり、画面例（Ｂ）は、図１９のコンボテーブルＴＢ２において定義された「第一コンボ列」のコンボ条件が満たされたときの画面の一部である。画面例（Ｂ）は、第二モーションで攻撃するゲームキャラクタＣＡ１が表示されている。

図１９のコンボテーブルＴＢ２の例では、タップ操作が２回連続した場合、受付時間内に次に入力される攻撃操作の種別に応じて、満たされるコンボ条件が異なる。例えば、受付時間内に次の攻撃操作としてタップ操作が入力される場合には、図１９のコンボテーブルＴＢ２において定義された「第二コンボ列」のコンボ条件を満たす。この場合、画面例（Ｃ）に示されるように、第一モーションで攻撃するゲームキャラクタＣＡ１が表示される。一方、受付時間内に次の攻撃操作としてフリック操作が入力される場合には、図１９のコンボテーブルＴＢ２において定義された「第四コンボ列」のコンボ条件を満たす。この場合、画面例（Ｅ）に示されるように、第三モーションで攻撃するゲームキャラクタＣＡ１が表示されている。このように、画面例（Ｂ）においては、次の攻撃操作の種別に応じて画面例（Ｃ）へ遷移するのか、画面例（Ｅ）へ遷移するのかが決定される。このような状況を「コンボ列の分岐」という。

なお、画面例（Ｄ）は、画面例（Ｃ）で示すモーション中の受付時間内にタップ操作が行われた場合のゲームキャラクタＣＡ１のモーションを示している（図１９のコンボテーブルＴＢ２の第三コンボ列）。画面例（Ｆ）は、画面例（Ｅ）で示すモーション中の受付時間内にタップ操作が行われた場合のゲームキャラクタＣＡ１のモーションを示している（図１９のコンボテーブルＴＢ２の第五コンボ列）。

（コンボ列の分岐時の案内表示）
図２０の画面例（Ｂ）の状況（コンボ列の分岐時）において、ユーザに対して、コンボ条件が満たされる次の入力操作の案内が表示される。以下では、コンボ条件が満たされる次の入力操作を案内する画面上の表示を案内表示という。また、コンボ列が分岐するタイミングを分岐タイミングという。案内表示は、分岐タイミングにおいて所定の案内表示時間の間、表示される。案内表示時間（表示時間の一例）の詳細については後述する。分岐タイミングにおける案内表示は、ユーザに対して、コンボを成立させるために次に入力すべき入力操作を提示する。よって、コンボ列の種類を増加させたことによる操作の複雑さが緩和され得る。

案内表示を提示する手法は、以下の四つの手法が存在する。第一の手法は、案内表示を吹き出し形式で表示する手法である。例えば、案内表示時間において、タッチスクリーン１３０にゲームキャラクタＣＡ１の吹き出しとして次の入力操作を示す案内表示が表示される。案内すべき次の入力操作は、複数の候補が存在する。案内する入力操作は、取り得る全ての候補であってもよいし、選択された候補であってもよい。選択基準としては、例えば、取り得るコンボ列のうちゲーム上の効果が最も高いコンボ列となる入力操作が選択されてもよい。あるいは、複数の候補のうち直前の入力操作とは異なる入力操作が選択されてもよい。第一の手法は、案内表示がタッチスクリーン１３０上に案内表示時間だけに出現することから、ゲームの他のオブジェクトやキャラクタとの重なりを抑えることができる。このため、第一の手法は、スマートフォンのように表示領域が狭いデバイスにも採用することができる。また、第一の手法では、操作対象の近傍に操作対象に関連付けて案内表示が出現するため、操作対象に着目しているユーザは気付きやすい。

第二の手法は、コンボ列をノードとエッジとを用いたグラフとして画面に予め表示する手法である。ノードは入力操作を示し、エッジはコンボ順番を示す。第二の手法では、案内表示時間において、次の入力操作を示すノードが強調表示される。第二の手法では、案内表示に必要な表示領域が第一の手法よりも大きくなる反面、ユーザはコンボ列の入力操作の初期段階から、コンボ列の全体を理解することができる。

第三の手法は、第一の手法を改良した手法である。第一の手法では、吹き出しを用いて次の入力操作を案内するため、画面表示領域の有効利用はできるものの、吹き出しは、操作状況を表示する操作オブジェクトと比べて、外観が大きく異なる。操作オブジェクトは、操作履歴という操作情報を用いて、入力操作に基づいた表示形態でオブジェクトを表示する。操作情報を、ゲームを表示するスクリーンにユーザによる入力操作に関する情報であると定義すると、次に案内すべき入力操作も操作情報の一種である。このため、案内表示と操作オブジェクトとは、共に操作情報を表示するために画面上に出現するものである。このため、案内表示と操作オブジェクトとの両者を同一又は類似する外観にした方がユーザに受け入れやすい。

第三の手法の一例としては、操作オブジェクトの変形を利用して、操作オブジェクトを案内表示に利用する手法である。案内表示に利用された操作オブジェクトは、ユーザの入力状況を表示するものではなくなるため、案内オブジェクトとなる。案内オブジェクトは、一例として、ユーザによる前回のタッチ位置を表示位置とし、入力操作を促すように変形する。例えば、ドラッグ操作を案内する案内オブジェクトは、ドラッグ操作方向に沿って所定周期で伸縮する。このような案内オブジェクトは、操作オブジェクトを利用するユーザによって理解しやすく、受け入れやすい。

第四の手法は、第三の手法を改良した手法である。第三の手法の一例を実現するためには、操作オブジェクトの表示及び変形に係るプログラムを大幅に変更する必要がある。第四の手法は、操作オブジェクトのプログラムの改変を極力抑えるために採用され得る。第四の手法において、案内表示時間では、操作オブジェクトの表示を中断し、アニメーションの表示に切り替える。つまり、案内表示時間よりも前の期間においては、入力操作に応じて変形する操作オブジェクト（入力操作に基づいた表示形態の一例）でタッチスクリーン１３０に操作履歴（操作情報の一例）を表示させておき、案内表示時間においては、操作オブジェクトを表示させず、アニメーション（入力操作に基づかない表示形態の一例）で案内表示（操作情報の一例）を表示させる。なお、「入力操作に基づく表示形態」とは、入力操作に応じてオブジェクトの形状パラメータ又は色パラメータが制御される形態のことである。ユーザの入力操作によってアニメーションの再生開始、終了が行われた結果、タッチスクリーン１３０上の図形の形状・色が変更されることがあるが、このような操作は、形状パラメータ又は色パラメータを制御するものではないため、「入力操作に基づかない表示形態」の一例である。

（アニメーションの一例）
図２１は、ドラッグ操作の案内表示となるアニメーション画像の一例である。図２１の画像例（Ａ）〜画像例（Ｃ）は、タッチスクリーン１３０に表示された画像の一部である。画像例（Ａ）は、操作オブジェクトの形状に類似する図形５００Ａを含む。画像例（Ｂ）は、図形５００Ａよりも横幅のある図形５００Ｂを含む。画像例（Ｃ）は、図形５００Ｂよりも横幅のある図形５００Ｃを含む。画像例（Ａ）、画像例（Ｂ）及び画像例（Ｃ）の順に切り替えられることで、横方向に延びる図形が案内表示として表現される。また、画像例（Ｃ）、画像例（Ｂ）及び画像例（Ａ）の順に切り替えられることで、横方向に縮む図形が案内表示として表現される。このように、画像例（Ａ）〜画像例（Ｃ）が切り替えられることで、図形が左右方向に伸縮するアニメーションとなり、案内表示時間においてドラッグ操作を案内する。

（案内表示が行われる画面の遷移例）
図２２は、アニメーションを利用した案内表示の一例を説明する図である。図２２の画面例（Ａ）〜画面例（Ｆ）は、タッチスクリーン１３０に表示された画像の一部である。画面例（Ａ）〜画面例（Ｆ）は、順に時系列で遷移する。

図２２の画面例（Ａ）は、ユーザによるタップ操作が行われたタイミングの画像である。タップ操作によって、操作オブジェクト３００が表示されるとともに、ゲームキャラクタＣＡ１は、タップ操作に応じて予め定められた攻撃モーション（例えば、第一モーション）を開始する。一例として、タップ操作の入力前の所定期間に入力操作を受け付けていない場合、ゲームキャラクタＣＡ１は、タップ操作に応じて第一モーションで動作する。

図２２の画面例（Ｂ）は、図２２の画面例（Ａ）にて入力されたタップ操作に応じた攻撃モーション中のゲームキャラクタＣＡ１を表示する画像である。図２２の画面例（Ｂ）では、攻撃モーション中（第一モーション中）のゲームキャラクタＣＡ１にタップ操作が入力され、操作オブジェクト３００が表示される。二連続のタップ操作は、図１９のテーブル例（Ａ）の「第一コンボ列」に係るコンボ条件を満たす。なお、コンボ条件は、時間的要素を含むが、図２２の説明においては、時間的要素に関するコンボ条件は省略し、詳細は後述する。「第一コンボ列」に係るコンボ条件が満たされた場合、図１９のテーブル例（Ｂ）の「第一コンボ列」に係るゲーム上の効果として、次の攻撃モーションが「第二モーション」となる。ゲームキャラクタＣＡ１は、第二モーションを開始する。

図２２の画面例（Ｃ）は、図２２の画面例（Ｂ）にて入力されたタップ操作に応じた攻撃モーション中（第二モーション中）のゲームキャラクタＣＡ１を表示する画像である。「第一コンボ列」のコンボ条件が満たされたとき、次の入力操作がタップ操作であれば、「第二コンボ列」のコンボ条件を満たし、次の入力操作がフリック操作であれば「第四コンボ列」のコンボ条件を満たす。つまり、図２２の画面例（Ｃ）は、分岐タイミングにおける画面例である。このとき、設定された所定期間に、図２１のアニメーションによる案内表示５００が表示される。以下では、上記所定期間を案内表示時間ともいう。案内表示５００は、図２１の図形５００Ａ〜５００Ｃを所定の順番で再生した結果である。

図２２の画面例（Ｄ）は、図２２の画面例（Ｃ）に対して、タップ操作が入力されたタイミングの画像である。案内表示５００は、アニメーションであるため、タップ操作に応じて変形しない。また、操作オブジェクトの表示も禁止されているため、タップ操作に応じた操作状況の表示も行われない。しかしながら、タップ操作が入力されているため、第二コンボ列のコンボ条件は満たされる。このため、図１９のテーブル例（Ｂ）の「第二コンボ列」に係るゲーム上の効果として、次の攻撃モーションが「第一モーション」となる。ゲームキャラクタＣＡ１は、第一モーションを開始する。

図２２の画面例（Ｅ）は、図２２の画面例（Ｄ）にて入力されたタップ操作に応じた攻撃モーション中（第一モーション中）のゲームキャラクタＣＡ１を表示する画像である。図２２の画面例（Ｅ）では、案内表示時間が経過し、案内表示５００を示すアニメーションは終了している。そして、攻撃モーション中（第一モーション中）のゲームキャラクタＣＡ１にタップ操作が入力され、操作オブジェクト３００が表示される。四連続のタップ操作は、図１９のテーブル例（Ａ）の「第三コンボ列」に係るコンボ条件を満たす。「第三コンボ列」に係るコンボ条件が満たされた場合、図１９のテーブル例（Ｂ）の「第三コンボ列」に係るゲーム上の効果として、次の攻撃モーションが「第二モーション」となる。ゲームキャラクタＣＡ１は、第二モーションを開始する。

図２２の画面例（Ｆ）は、図２２の画面例（Ｅ）にて入力されたタップ操作に応じた攻撃モーション中（第二モーション中）のゲームキャラクタＣＡ１を表示する画像である。

以上、連続するタップ操作に応じて、ゲーム上の効果が変更され、かつ、案内表示時間ではアニメーションの案内表示５００が表示される。

図２３は、アニメーションを利用した案内表示の他の例を説明する図である。図２３の画面例（Ａ）〜画面例（Ｆ）は、タッチスクリーン１３０に表示された画像の一部である。画面例（Ａ）〜画面例（Ｆ）は、順に時系列で遷移する。

図２３の画面例（Ａ）〜画面例（Ｃ）は、図２２の画面例（Ａ）〜画面例（Ｃ）と同一である。

図２３の画面例（Ｄ）は、図２３の画面例（Ｃ）に対して、フリック操作が入力されたタイミングの画像である。案内表示５００は、アニメーションであるため、フリック操作に応じて変形しない。また、操作オブジェクトの表示も禁止されているため、フリック操作に応じた操作状況の表示も行われない。しかしながら、フリック操作が入力されているため、第四コンボ列のコンボ条件は満たされる。このため、図１９のテーブル例（Ｂ）の「第四コンボ列」に係るゲーム上の効果として、次の攻撃モーションが「第三モーション」となる。ゲームキャラクタＣＡ１は、第三モーションを開始する。

図２３の画面例（Ｅ）は、図２３の画面例（Ｄ）にて入力されたフリック操作に応じた攻撃モーション中（第三モーション中）のゲームキャラクタＣＡ１を表示する画像である。図２３の画面例（Ｅ）では、案内表示時間が経過し、案内表示５００を示すアニメーションは終了している。そして、攻撃モーション中（第三モーション中）のゲームキャラクタＣＡ１にタップ操作が入力され、操作オブジェクト３００が表示される。二連続のタップ操作とフリック操作とに続いて、さらにタップ操作された場合には、図１９のテーブル例（Ａ）の「第五コンボ列」に係るコンボ条件を満たす。「第五コンボ列」に係るコンボ条件が満たされた場合、図１９のテーブル例（Ｂ）の「第五コンボ列」に係るゲーム上の効果として、次の攻撃モーションが「第三モーション」となる。ゲームキャラクタＣＡ１は、第三モーションを開始する。

図２３の画面例（Ｆ）は、図２３の画面例（Ｅ）にて入力されたタップ操作に応じた攻撃モーション中（第三モーション中）のゲームキャラクタＣＡ１を表示する画像である。

以上、タップ操作及びフリック操作に応じて、ゲーム上の効果が変更され、かつ、案内表示時間ではアニメーションの案内表示５００が表示される。

（コンボ条件の時間的要素、先行入力及び後発入力）
図２４は、先行入力を説明する図である。図２４は、図２３の画面例（Ｂ）から画面例（Ｅ）に至るまでのゲームキャラクタＣＡ１の動作を詳細に説明する図である。

図２４に示されるように、タップ操作に応じて第二モーションが開始される。第二モーションの再生は、開始時刻ｔ１から開始され、終了時刻ｔ２で終了する。第二モーションの再生中に、次の入力操作を受け付けるための受付時間が設定される。受付時間は、第二モーションの再生時間（第一コンボ動作で動作するキャラクタを表示させる期間の一例）である開始時刻ｔ１から終了時刻ｔ２までの間に設定される。図中では、受付時間は、開始時刻ｔ３から開始され、終了時刻ｔ４で終了する。

受付時間内にコンボ攻撃に係る入力操作が受け付けられた場合に、コンボ条件が満たされたと判定される。このため、受付時間外にコンボ攻撃に係る入力操作が受け付けられた場合であっても、当該入力操作はコンボ条件を満たすか否かの判定には考慮されない。つまり、コンボ条件は時間的要素を含む。図２２及び図２３の説明では、時間的要素は省略したが、全ての操作について受付時間が設定され、コンボ条件として時間的要素の条件を満たすか否かが判定される。

また、受付時間内にコンボ攻撃に係る入力操作が受け付けられた場合、先行入力か後発入力かに応じて、次のモーションの再生時間の開始時刻が変更される。受付時間には、分岐可能タイミングＴＡ（第一タイミングの一例）が予め設定されている。分岐可能タイミングＴＡは、分岐されたコンボに係るモーションの再生が可能となるタイミングである。受付時間内に受け付けられたコンボ攻撃に係る入力操作が、受付時間の開始時刻ｔ３から分岐可能タイミングＴＡまでに受け付けられた場合には、当該入力操作は先行入力として判定される。図２４の例では、フリック操作が先行入力となる。コンボ攻撃に係る入力操作が先行入力である場合、次のモーション再生は、分岐可能タイミングＴＡから開始される。図２４の例では、第三モーション再生の開始時刻ｔ５が分岐可能タイミングＴＡと同一の時刻になる。

図２５は、後発入力を説明する図である。入力操作に関して図２４と比較すると、フリック操作が分岐可能タイミングＴＡの後に受け付けられる点を除き、同一である。図２５に示されるように、受付時間内に受け付けられたコンボ攻撃に係る入力操作が、分岐可能タイミングＴＡから受付時間の終了時刻ｔ４までに受け付けられた場合には、当該入力操作は後発入力として判定される。図２５の例では、フリック操作が後発入力となる。コンボ攻撃に係る入力操作が後発入力である場合、次のモーション再生は、後発入力のあったタイミングから開始される。図２５の例では、第三モーション再生の開始時刻ｔ５がフリック操作のあったタイミングと同一の時刻になる。

（案内表示時間）
図２６は、案内表示時間について説明する図である。案内表示時間は、受付時間に基づいて設定される。図２６に示されるように、受付時間の開始時刻ｔ３に、案内表示時間の開始時刻ｔ７が設定される。また、案内表示時間の終了時刻ｔ８は、コンボ攻撃に係る入力操作が先行入力の場合には分岐可能タイミングＴＡを基準に設定される。例えば、案内表示時間の終了時刻ｔ８は、分岐可能タイミングＴＡより第一期間Ｍ１前に終了するように設定される。第一期間Ｍ１は０を含む。このため、案内表示時間の終了時刻ｔ８は、分岐可能タイミングＴＡと同時であってもよい。このように、コンボ攻撃に係る入力操作が先行入力の場合には、分岐可能タイミングＴＡにおいてモーション再生がスタートするため、少なくとも分岐可能タイミングＴＡまでに案内表示を終了させることで、映像と案内表示が同期するため、ユーザにとって理解しやすい案内表示が提供される。

また、案内表示時間の終了時刻ｔ８は、コンボ攻撃に係る入力操作が後発入力の場合には受付時間の終了時刻ｔ４を基準に設定される。例えば、案内表示時間の終了時刻ｔ８は、受付時間の終了時刻ｔ４より第二期間Ｍ２前に終了するように設定される。第二期間Ｍ２は０を含む。このため、案内表示時間の終了時刻ｔ８は、受付時間の終了時刻ｔ４と同時であってもよい。このように、コンボ攻撃に係る入力操作が後発入力の場合には、受付時間の終了時刻ｔ４を基準として案内表示時間を設定することにより、受付時間の終了タイミングをユーザが学習することができる。

なお、案内表示時間の終了時刻ｔ８は、後発入力が受け付けられたタイミングで終了するようにしてもよい。この場合、映像と案内表示が同期するため、ユーザにとって理解しやすい案内表示が提供される。

（コンボ処理のフローチャート）
図２７は、コンボ処理を説明するフローチャートである。図２７のフローチャートは、制御部１９０がゲームプログラム１５１を実行することによりアクションゲームを進行させる処理を示すフローチャートである。図２７に示されるフローチャートは、後述する分岐フラグが「０」のときに開始される。分岐フラグは、コンボ列に分岐があるときに「１」に設定され、コンボ列に分岐がないときに「０」に設定されるフラグである。

ステップＳ９０において、制御部１９０は、入力操作が受け付けられたか否かを判定する。

入力操作が受け付けられたと判定されると（ステップＳ９０：ＹＥＳ）、ステップＳ９２において、制御部１９０は、操作オブジェクト３００を表示するとともに、入力操作と前回入力操作との関係がコンボ条件を満たすか否かを判定する。前回入力操作とは、直前に入力された入力操作であってもよいし、所定回数前までに入力された入力操作であってもよい。制御部１９０は、例えば、図１９に示されるテーブル例（Ａ）のコンボテーブルＴＢ１を参照し、ステップＳ９０にて受け付けられた入力操作と、操作履歴に格納されている前回入力操作との関係が、何れかのコンボ列の手順と一致しているか否かを判定する。さらに、制御部１９０は、ステップＳ９０にて受け付けられた入力操作が前回入力操作時に設定された受付時間内に受け付けられたものであるか否かを判定する。制御部１９０は、上記二つの判定が肯定的な場合、入力操作と前回入力操作との関係がコンボ条件を満たすと判定する。

一例として、ステップＳ９０にて受け付けられた入力操作がタップ操作であり、操作履歴に格納されている前回入力操作がタップ操作であり、前回入力操作に設定された受付時間内に入力されたものであるとする。この場合、制御部１９０は、「第一コンボ列」に係るコンボ条件が満たされたと判定する（図１９のコンボテーブルＴＢ１）。また、一例として、ステップＳ９０にて受け付けられた入力操作がタップ操作であり、操作履歴に格納されている前回入力操作がタップ操作であるものの、前回入力操作に設定された受付時間外に入力されたものであるとする。この場合、制御部１９０は、コンボ条件が満たされていないと判定する。

コンボ条件が満たされていないと判定されると（ステップＳ９２：ＮＯ）、ステップＳ９６において、制御部１９０は、入力操作に応じて動作するキャラクタの表示を開始する。制御部１９０は、例えば、図２０の画面例（Ａ）に示されるように、第一モーションで動作するゲームキャラクタＣＡ１の表示を開始する。

コンボ条件が満たされたと判定されると（ステップＳ９２：ＹＥＳ）、ステップＳ９４において、制御部１９０は、コンボ動作で動作するキャラクタの表示を開始する。制御部１９０は、例えば、図２０の画面例（Ｂ）に示されるように、第二モーションで動作するゲームキャラクタＣＡ１の表示を開始する（図１９のコンボテーブルＴＢ２）。

ゲームキャラクタＣＡ１の動作の表示が開始されると（ステップＳ９４又はステップＳ９６）、ステップＳ９７において、制御部９７は、次の入力操作のための受付時間を設定する（図２４，図２５）。

続いて、ステップＳ９８において、制御部１９０は、コンボ列の分岐が存在するか否かを判定する。制御部１９０は、一例として、図１９に示されるテーブル例（Ａ）のコンボテーブルＴＢ１及び操作履歴を参照し、ステップＳ９０にて受け付けられた入力操作と、次回の入力操作との関係が複数のコンボ条件を満たす状況であるか否かを判定する。一例として、前回のタップ操作が１回、ステップＳ９０にて受け付けられた入力操作がタップ操作である場合を説明する。このような二連続のタップ操作が受け付けられたとき、図１９のコンボテーブルＴＢ１に示されるように、次の入力操作がタップ操作であれば「第二コンボ列」を満たし、次の入力操作がフリック操作であれば「第四コンボ列」を満たす。このような場合、制御部１９０は、コンボ列の分岐があると判定する。

コンボ列の分岐があると判定されると（Ｓ９８：ＹＥＳ）、ステップＳ１００において、制御部１９０は、分岐フラグを「１」に設定する。一方、コンボ列の分岐がないと判定されると（Ｓ９８：ＹＥＳ）、ステップＳ１０２において、制御部１９０は、分岐フラグを「０」に設定する。

入力操作が受け付けられていないと判定された場合（ステップＳ９０：ＮＯ）、又は、分岐フラグの設定が終了した場合（ステップＳ１００又はステップＳ１０２）には、図２７に示されるフローチャートは、終了する。そして、制御部１９０は、分岐フラグが「０」である場合、図２７に示されるフローチャートを最初から実行する。

（コンボ列の分岐時におけるコンボ処理のフローチャート）
図２８は、コンボ列の分岐時におけるコンボ処理のフローチャートである。図２８のフローチャートは、制御部１９０がゲームプログラム１５１を実行することによりアクションゲームを進行させる処理を示すフローチャートである。図２８に示されるフローチャートは、分岐フラグが「１」のときに開始される。なお、以下ではコンボ列の分岐先が二つである場合、例えば、図２０の画面例（Ｂ）における状況を一例として説明する。

ステップＳ１１０において、制御部１９０は、入力操作が受け付けられたか否かを判定する。

入力操作が受け付けられたと判定されると（ステップＳ１１０：ＹＥＳ）、ステップＳ１１２において、制御部１９０は、入力操作と前回入力操作との関係が第一コンボ条件を満たすか否かを判定する。第一コンボ条件は、分岐する二つのコンボ列のうち、一方のコンボ列に係るコンボ条件である。制御部１９０は、例えば、図１９に示されるテーブル例（Ａ）のコンボテーブルＴＢ１を参照し、ステップＳ１１０にて受け付けられた入力操作と、操作履歴に格納されている前回入力操作との関係が、「第二コンボ列」の手順と一致しているか否かを判定する（第一コンボ条件の一例）。さらに、制御部１９０は、ステップＳ１１０にて受け付けられた入力操作が前回入力操作時に設定された受付時間内に受け付けられたものであるか否かを判定する（第一コンボ条件の一例）。制御部１９０は、上記二つの判定が肯定的な場合、入力操作と前回入力操作との関係が第一コンボ条件を満たすと判定する。

第一コンボ条件が満たされたと判定されると（ステップＳ１１２：ＹＥＳ）、ステップＳ１１４において、制御部１９０は、第一コンボ動作で動作するキャラクタの表示を開始する。一例として、「第二コンボ列」に係るコンボ条件が満たされたとすると、制御部１９０は、例えば、図２０の画面例（Ｃ）に示されるように、第一モーション（第一コンボ動作の一例）で動作するゲームキャラクタＣＡ１の表示を開始する。

第一コンボ条件が満たされていないと判定されると（ステップＳ１１２：ＮＯ）、ステップＳ１１６において、制御部１９０は、入力操作と前回入力操作との関係が第二コンボ条件を満たすか否かを判定する。第二コンボ条件は、分岐する二つのコンボ列のうち、他方のコンボ列に係るコンボ条件である。制御部１９０は、例えば、図１９に示されるテーブル例（Ａ）のコンボテーブルＴＢ１を参照し、ステップＳ１１０にて受け付けられた入力操作と、操作履歴に格納されている前回入力操作との関係が、「第四コンボ列」の手順と一致しているか否かを判定する（第二コンボ条件の一例）。さらに、制御部１９０は、ステップＳ１１０にて受け付けられた入力操作が前回入力操作時に設定された受付時間内に受け付けられたものであるか否かを判定する（第二コンボ条件の一例）。制御部１９０は、上記二つの判定が肯定的な場合、入力操作と前回入力操作との関係が第二コンボ条件を満たすと判定する。

第二コンボ条件が満たされたと判定されると（ステップＳ１１６：ＹＥＳ）、ステップＳ１１８において、制御部１９０は、第二コンボ動作で動作するキャラクタの表示を開始する。一例として、「第四コンボ列」に係るコンボ条件が満たされたとすると、制御部１９０は、例えば、図２０の画面例（Ｅ）に示されるように、第三モーション（第二コンボ動作の一例）で動作するゲームキャラクタＣＡ１の表示を開始する。

第二コンボ条件が満たされていないと判定されると（ステップＳ１１６：ＮＯ）、ステップＳ１２０において、制御部１９０は、入力操作に応じて動作するキャラクタの表示を開始する。制御部１９０は、例えば、図２０の画面例（Ａ）に示されるように、第一モーションで動作するゲームキャラクタＣＡ１の表示を開始する。

ゲームキャラクタＣＡ１の動作の表示が開始されると（ステップＳ１１４、ステップＳ１１８又はステップＳ１２０）、ステップＳ１２２において、制御部９７は、次の入力操作のための受付時間を設定する（図２４，図２５）。

続いて、ステップＳ１２４において、制御部１９０は、分岐フラグ処理を行う。分岐フラグ処理は、図２７のステップＳ９８、ステップＳ１００及びステップＳ１０２と同一である。

入力操作が受け付けられていないと判定された場合（ステップＳ１１０：ＮＯ）、又は、分岐フラグの設定が終了した場合（ステップＳ１２４）には、図２８に示されるフローチャートは、終了する。そして、制御部１９０は、分岐フラグが「１」である場合、図２８に示されるフローチャートを最初から実行する。

（案内表示処理のフローチャート）
図２９は、案内表示処理のフローチャートである。図２９のフローチャートは、制御部１９０がゲームプログラム１５１を実行することによりアクションゲームを進行させる処理を示すフローチャートである。図２９に示されるフローチャートは、分岐フラグが「１」のときに開始される。このため、図２８に示されるフローチャートと並行して行われる。また、以下では、図２０の画面例（Ｂ）における状況を一例として説明する。そして、案内表示は、ゲーム上の効果が大きい第四コンボ列に係る操作を案内するものとする。

ステップＳ１３２において、制御部１９０は、分岐可能タイミングＴＡを設定する（図２４，図２５）。制御部１９０は、直前に入力された入力操作に設定された受付時間に対して、分岐可能タイミングＴＡを設定する。一例として、制御部１９０は、受付時間の開始から所定時間の間隔を空けて分岐可能タイミングＴＡを設定する。

続いて、ステップＳ１３４において、制御部１９０は、案内表示を開始する。制御部１９０は、一例として、直前に入力された入力操作に設定された受付時間の開始とともに、図２１に示されたアニメーションの再生を行う。この場合、受付時間の開始とともに次の入力操作（第四コンボ列のフリック操作）の入力を促すアニメーションが表示される。なお、案内表示時間の開始を、受付時間の開始よりも所定時間遅らせてもよい。

続いて、ステップＳ１３６において、制御部１９０は、入力操作と前回入力操作との関係が第二コンボ条件を満たすか否かを判定する。この処理は、図２８のステップＳ１１６と同一である。

第二コンボ条件が満たされたと判定されると（ステップＳ１３６：ＹＥＳ）、ステップＳ１３８において、制御部１９０は、次の入力操作（第四コンボ列のフリック操作）が先行入力であるか後発入力であるかを判定する（図２４，図２５）。次の入力操作が先行入力である場合、制御部１９０は、分岐可能タイミングＴＡを基準に案内表示時間の終了タイミングを設定する。例えば、制御部１９０は、分岐可能タイミングＴＡより第一期間Ｍ１前に案内表示時間の終了時刻ｔ８を設定する（図２６）。次の入力操作が後発入力である場合、制御部１９０は、受付時間の終了時刻を基準に案内表示時間の終了タイミングを設定する。例えば、制御部１９０は、受付時間の終了時刻ｔ４より第二期間Ｍ２前に案内表示時間の終了時刻ｔ８を設定する（図２６）。あるいは、制御部１９０は、後発入力を基準に案内表示時間の終了タイミングを設定してもよい。例えば、制御部１９０は、後発入力と同一又は所定時間経過後のタイミングに案内表示時間の終了時刻ｔ８を設定する。

一方、第二コンボ条件が満たされていないと判定されると（ステップＳ１３６：ＮＯ）、ステップＳ１４０において、制御部１９０は、受付時間の終了時刻を基準に案内表示時間の終了タイミングを設定する。例えば、制御部１９０は、受付時間の終了時刻ｔ４より第二期間Ｍ２前に案内表示時間の終了時刻ｔ８を設定する。

終了タイミングの設定が終了すると、ステップＳ１４２として、制御部１９０は、設定されたタイミングで案内表示を終了する。以上で図２９に示されるフローチャートは、終了する。そして、制御部１９０は、分岐フラグが「１」である場合、図２９に示されるフローチャートを最初から実行する。

（案内表示のまとめ）
案内表示は、コンボ列が分岐するタイミングで表示される。案内表示は、一例として、操作オブジェクトに類似したアニメーションが再生される。また、アニメーション再生時においては、操作オブジェクトは表示させない。

（変形例１）
制御部１９０は、コンボの手順を定義するコンボテーブルＴＢ１を参照してコンボ列の分岐を判定していたが、これに限定されるものではない。例えば、制御部１９０は、操作内容と分岐フラグとが関連付けられた分岐タイミングテーブルを参照してもよい。分岐タイミングテーブルは、コンボテーブルＴＢ１から予め作成することができる。

（変形例２）
さらに、実施形態では、カメラ配置制御部１９４は、コンボ攻撃中においてはコンボ攻撃の最初の攻撃操作に基づいて仮想カメラＶＣの撮影方向を決定し、以降のコンボ攻撃中の撮影方向を固定する例を説明したが、これに限定されない。例えば、カメラ配置制御部１９４は、攻撃操作（コンボ攻撃操作を含む）を受け付けた場合には、常にゲームキャラクタＣＡ１をその背後から撮影するように仮想カメラＶＣを制御してもよい。つまり、コンボ攻撃中においては、最初の攻撃操作に基づいて決定された仮想カメラＶＣの撮影方向（ゲームキャラクタＣＡ１をその背後から撮影する方向）を維持するように、仮想カメラの撮影方向を変更し続ける。この場合、制御部１９０は、図１８のステップＳ７４、ステップＳ７８の攻撃時において、攻撃対象となる敵キャラクタＣＡ２にゲームキャラクタＣＡ１を向かせ、ゲームキャラクタＣＡ１の向きに応じて仮想カメラＶＣの撮影方向を制御する（図１５のステップＳ４０及びＳ４２に相当する処理が行われる）。これにより、戦闘シーンにおいては、ゲームキャラクタＣＡ１は常に敵キャラクタＣＡ２に正面から対峙し、常にゲームキャラクタＣＡ１の背後から観察するゲーム画面が提供される。このようなカメラワークとすることにより、ユーザがキャラクタの向きを見失うことが無いため、攻撃操作に方向性のある入力操作が含まれる場合であっても、操作性を向上させることができる。

（変形例３）
ドラッグ操作の操作結果を示す操作オブジェクト３００は、複数のオブジェクトを用いて操作結果が表現されもよい。

（変形例４）
連撃操作中に含まれている操作は、フリック操作である例を説明したが、ドラッグ操作であってもよい。

（変形例５）
タッチスクリーン１３０は、モーションセンサ及びディスプレイ装置からなるデバイスに置き換えてもよい。

（変形例６）
上述したゲーム処理の全てを携帯端末１０又はサーバ２０が単体で実行してもよい。

以上、本開示の実施形態について説明したが、本開示の技術的範囲は、本実施形態の説明によって限定的に解釈されるべきではない。本実施形態は一例であって、特許請求の範囲の記載事項に基づいて、様々な実施形態の変更が可能であることが当業者によって理解されるところである。本開示の技術的範囲は、特許請求の範囲の記載事項及びその均等の範囲に基づいて定められるべきである。

本開示の主題は、例えば以下のような項目として示される。

（項目１）
スクリーン（例えばタッチスクリーン１３０）に表示されるゲームのキャラクタ（例えばゲームキャラクタ）をユーザによる入力操作に応じて動作させるために、コンピュータによって実行される情報処理方法であって、
前記入力操作を受け付けた場合であって、前記入力操作と前回入力操作との関係が所定のコンボ条件（例えば第一コンボ列に係るコンボ条件）を満たしているときには、所定のコンボ動作（例えば第二モーション）で動作する前記キャラクタを前記スクリーンに表示させる第一表示ステップ（例えばステップＳ９２、ステップＳ９４）と、
前記入力操作と次回の第一入力操作（例えばタップ操作）との関係が、前記所定のコンボ動作で動作する前記キャラクタを表示させる第一コンボ条件（例えば第二コンボ列に係るコンボ条件）を満たす状況であり、かつ、前記入力操作と次回の第二入力操作（例えばフリック操作）との関係が、前記キャラクタを第二コンボ動作で動作させるための第二コンボ条件（例えば第四コンボ列に係るコンボ条件）を満たす状況である場合には、前記所定のコンボ動作で動作する前記キャラクタの表示中において、前記第二入力操作の入力を促す案内表示を前記スクリーンに表示させる案内表示ステップ（例えばステップＳ１３４）と、
前記第二入力操作を受け付けた場合には、第二コンボ動作（例えば第三モーション）で動作する前記キャラクタを前記スクリーンに表示させる第二表示ステップ（例えばステップＳ１１８）と、
を備える情報処理方法。

この情報処理方法によれば、コンボ列の分岐タイミングにおいて案内表示をスクリーンに表示させることができるので、適切なタイミングでユーザに次の入力操作を案内することができる。

（項目２）
前記案内表示ステップでは、前記所定のコンボ動作で動作する前記キャラクタを表示させる期間（例えば、第二モーション再生期間：時刻ｔ１〜時刻ｔ２）に前記第二入力操作の受付時間（例えば、時刻ｔ３〜時刻ｔ４）が設定され、前記受付時間に基づいて前記案内表示の表示時間（例えば、時刻ｔ７〜時刻ｔ８）が設定される、項目１に記載の情報処理方法。

この情報処理方法によれば、受付時間外の入力操作を、コンボ判定から除外することができる。

（項目３）
前記受付時間には第一タイミング（例えば分岐可能タイミングＴＡ）が設定され、
前記第二表示ステップでは、前記受付時間の開始から前記第一タイミングまでに前記第二入力操作が受け付けられた場合（例えば先行入力）には、第二コンボ動作で動作する前記キャラクタを前記第一タイミングから前記スクリーンに表示させ、前記第一タイミングから前記受付時間の終了までに前記第二入力操作が受け付けられた場合（例えば後発入力）には、第二コンボ動作で動作する前記キャラクタを前記第二入力操作が受け付けられたタイミングから前記スクリーンに表示させる、項目２に記載の情報処理方法。

この情報処理方法によれば、コンボ動作をするキャラクタの動きの開始タイミングを、先行入力と後発入力とで変更することができる。

（項目４）
前記案内表示ステップでは、前記表示時間の終了は、前記受付時間の終了時、又は、前記受付時間の終了よりも所定時間前に設定される、項目２又は３に記載の情報処理方法。

この情報処理方法によれば、受付終了した操作を案内表示によって案内することを回避することができる。

（項目５）
前記案内表示ステップでは、前記受付時間の開始から前記第一タイミングまでに前記第二入力操作が受け付けられた場合には、前記表示時間の終了は、前記第一タイミング、又は、前記第一タイミングよりも所定時間前（例えば第一期間Ｍ１）に設定され、前記第一タイミングから前記受付時間の終了までに前記第二入力操作が受け付けられた場合には、前記表示時間の終了は、前記第二入力操作が受け付けられたタイミング、前記受付時間の終了、又は、前記受付時間の終了よりも所定時間前（例えば第二期間Ｍ２）に設定される、項目２〜４の何れか一項に記載の情報処理方法。

この情報処理方法によれば、少なくとも第一タイミングまでに案内表示を終了させることで、映像と案内表示が同期するため、ユーザにとって理解しやすい案内表示が提供される。また、この情報処理方法によれば、受付時間の終了時刻を基準として案内表示時間を設定することにより、受付時間の終了タイミングをユーザに学習させることができる。

（項目６）
前記案内表示は、前記キャラクタの近傍に前記キャラクタと関連付けて表示される、項目１〜５の何れか一項に記載の情報処理方法。

この情報処理方法によれば、操作対象に着目しているユーザに対しても案内することができる。

（項目７）
前記案内表示は、前記スクリーンの所定位置に、ノードとエッジとを用いたグラフとして表示される、項目１〜５の何れか一項に記載の情報処理方法。

この情報処理方法によれば、ユーザはコンボ列の入力操作の初期段階から、コンボ列の全体を理解することができる。

（項目８）
前記案内表示は、前記スクリーンがタッチスクリーンである場合に、操作オブジェクトを変形させることによって生成される、項目１〜５の何れか一項に記載の情報処理方法。

この情報処理方法によれば、操作オブジェクトを利用するユーザによって理解しやすく、受け入れやすい。

（項目９）
項目１〜８の何れか一項に記載の方法をコンピュータに実行させる、プログラム。

（項目１０）
メモリと、
前記メモリに結合されたプロセッサとを備え、
前記プロセッサの制御により項目１〜８の何れか一項に記載の方法を実行する、装置。

１…ゲーム提供システム、１０…携帯端末、２０…サーバ、２５…メモリ、２６…スト
レージ、２９…プロセッサ、１３０…タッチスクリーン、１５０…記憶部、１５１…ゲー
ムプログラム、１９０…制御部、１９１…入力操作受付部、１９２…ゲーム進行処理部、
１９３…移動方向検出部、１９４…カメラ配置制御部、１９５…オブジェクト制御部、１
９６…表示制御部、２２０…通信部、２５０…記憶部、２５１…ゲームプログラム、２９
０…制御部、２９１…送受信部、２９２…サーバ処理部、２９３…データ管理部、２９４
…マッチング部、２９５…計測部、３００，４００…操作オブジェクト、５００…案内表
示、ＣＡ１…ゲームキャラクタ（キャラクタの一例）。

Claims (10)

1. スクリーンに表示されるゲームのキャラクタをユーザによる入力操作に応じて動作させるために、コンピュータによって実行される情報処理方法であって、
   前記入力操作を受け付けた場合であって、前記入力操作と前回入力操作との関係が所定のコンボ条件を満たしているときには、所定のコンボ動作で動作する前記キャラクタを前記スクリーンに表示させる第一表示ステップと、
   前記入力操作と次回の第一入力操作との関係が、前記キャラクタを第一コンボ動作で動作させるための第一コンボ条件を満たす状況であり、かつ、前記入力操作と次回の第二入力操作との関係が、前記キャラクタを第二コンボ動作で動作させるための第二コンボ条件を満たす状況であるときに、前記第一入力操作を受け付けた場合には、前記第一コンボ動作で動作する前記キャラクタを前記スクリーンに表示させ、前記第二入力操作を受け付けた場合には、前記第二コンボ動作で動作する前記キャラクタを前記スクリーンに表示させる、第二表示ステップと、
   を備え、
   前記第一入力操作又は前記第二入力操作の受付時間が設定され、且つ、前記受付時間には第一タイミングが設定され、
   前記第二表示ステップでは、前記受付時間の開始から前記第一タイミングまでに前記第一入力操作又は前記第二入力操作が受け付けられた場合には、前記第一コンボ動作又は前記第二コンボ動作で動作する前記キャラクタを前記第一タイミングから前記スクリーンに表示させ、前記第一タイミングから前記受付時間の終了までに前記第一入力操作又は前記第二入力操作が受け付けられた場合には、前記第一コンボ動作又は前記第二コンボ動作で動作する前記キャラクタを前記第一入力操作又は前記第二入力操作が受け付けられたタイミングから前記スクリーンに表示させる、
   情報処理方法。
2. 前記所定のコンボ動作で動作する前記キャラクタの表示中において、前記第一入力操作又は前記第二入力操作の入力を促す案内表示を前記スクリーンに表示させる案内表示ステップを更に備える、請求項１に記載の情報処理方法。
3. 前記案内表示ステップでは、前記受付時間に基づいて前記案内表示の表示時間が設定される、請求項２に記載の情報処理方法。
4. 前記案内表示ステップでは、前記表示時間の終了は、前記受付時間の終了時、又は、前記受付時間の終了よりも所定時間前に設定される、請求項３に記載の情報処理方法。
5. 前記案内表示ステップでは、前記受付時間の開始から前記第一タイミングまでに前記第一入力操作又は前記第二入力操作が受け付けられた場合には、前記表示時間の終了は、前記第一タイミング、又は、前記第一タイミングよりも所定時間前に設定され、前記第一タイミングから前記受付時間の終了までに前記第一入力操作又は前記第二入力操作が受け付けられた場合には、前記表示時間の終了は、前記第一入力操作又は前記第二入力操作が受け付けられたタイミング、前記受付時間の終了、又は、前記受付時間の終了よりも所定時間前に設定される、請求項３に記載の情報処理方法。
6. 前記案内表示は、前記キャラクタの近傍に前記キャラクタと関連付けて表示される、請求項２〜５の何れか一項に記載の情報処理方法。
7. 前記案内表示は、前記スクリーンの所定位置に、ノードとエッジとを用いたグラフとして表示される、請求項２〜５の何れか一項に記載の情報処理方法。
8. 前記案内表示は、前記スクリーンがタッチスクリーンである場合に、操作オブジェクトを変形させることによって生成される、請求項２〜５の何れか一項に記載の情報処理方法。
9. 請求項１〜８の何れか一項に記載の方法をコンピュータに実行させる、プログラム。
10. メモリと、
    前記メモリに結合されたプロセッサとを備え、
    前記プロセッサの制御により請求項１〜８の何れか一項に記載の方法を実行する、装置。

Images