〔実施形態1〕
本開示に係るゲームシステムは、複数のユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。
<ゲームシステム1のハードウェア構成>
図1は、ゲームシステム1のハードウェア構成を示す図である。ゲームシステム1は図示の通り、複数のユーザ端末100と、サーバ200とを含む。各ユーザ端末100は、サーバ200とネットワーク2を介して接続する。ネットワーク2は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂3G、4G移動通信システム、LTE(Long Term Evolution)、および所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク(例えばWi-Fi(登録商標))等が挙げられる。
サーバ200(コンピュータ、情報処理装置)は、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってよい。サーバ200は、プロセッサ20と、メモリ21と、ストレージ22と、通信IF23と、入出力IF24とを備える。サーバ200が備えるこれらの構成は、通信バスによって互いに電気的に接続される。
ユーザ端末100(コンピュータ、情報処理装置)は、スマートフォン、フィーチャーフォン、PDA(Personal Digital Assistant)、またはタブレット型コンピュータ等の携帯端末であってよい。ユーザ端末100は、ゲームプレイに適したゲーム装置であってもよい。ユーザ端末100は図示の通り、プロセッサ10と、メモリ11と、ストレージ12と、通信インターフェース(IF)13と、入出力IF14と、タッチスクリーン15(表示部)と、カメラ17と、測距センサ18とを備える。ユーザ端末100が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末100は、タッチスクリーン15に代えて、または、加えて、ユーザ端末100本体とは別に構成されたディスプレイ(表示部)を接続可能な入出力IF14を備えていてもよい。
また、図1に示すように、ユーザ端末100は、1つ以上のコントローラ1020と通信可能に構成されることとしてもよい。コントローラ1020は、例えば、Bluetooth(登録商標)等の通信規格に従って、ユーザ端末100と通信を確立する。コントローラ1020は、1つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末100へ送信する。また、コントローラ1020は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末100へ送信する。
なお、ユーザ端末100がカメラ17および測距センサ18を備えることに代えて、または、加えて、コントローラ1020がカメラ17および測距センサ18を有していてもよい。
ユーザ端末100は、例えばゲーム開始時に、コントローラ1020を使用するユーザに、該ユーザの名前またはログインID等のユーザ識別情報を、該コントローラ1020を介して入力させることが望ましい。これにより、ユーザ端末100は、コントローラ1020とユーザとを紐付けることが可能となり、受信した出力値の送信元(コントローラ1020)に基づいて、該出力値がどのユーザのものであるかを特定することができる。
ユーザ端末100が複数のコントローラ1020と通信する場合、各コントローラ1020を各ユーザが把持することで、ネットワーク2を介してサーバ200などの他の装置と通信せずに、該1台のユーザ端末100でマルチプレイを実現することができる。また、各ユーザ端末100が無線LAN(Local Area Network)規格等の無線規格により互いに通信接続する(サーバ200を介さずに通信接続する)ことで、複数台のユーザ端末100によりローカルでマルチプレイを実現することもできる。1台のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、ユーザ端末100は、さらに、サーバ200が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末100によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末100は、サーバ200が備える後述する種々の機能を分散して備えていてもよい。
なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末100はサーバ200と通信を行ってもよい。例えば、あるゲームにおける成績または勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ200に送信してもよい。
また、コントローラ1020は、ユーザ端末100に着脱可能な構成であるとしてもよい。この場合、ユーザ端末100の筐体における少なくともいずれかの面に、コントローラ1020との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末100とコントローラ1020とが結合している場合は、ユーザ端末100とコントローラ1020とは、有線を介して信号を送受信する。
図1に示すように、ユーザ端末100は、外部のメモリカード等の記憶媒体1030の装着を、入出力IF14を介して受け付けてもよい。これにより、ユーザ端末100は、記憶媒体1030に記録されるプログラム及びデータを読み込むことができる。記憶媒体1030に記録されるプログラムは、例えばゲームプログラムである。
ユーザ端末100は、サーバ200等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末100のメモリ11に記憶してもよいし、記憶媒体1030から読み込むことにより取得したゲームプログラムをメモリ11に記憶してもよい。
以上で説明したとおり、ユーザ端末100は、該ユーザ端末100に対して情報を入力する機構の一例として、通信IF13、入出力IF14、タッチスクリーン15、カメラ17、および、測距センサ18を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。
例えば、操作部が、カメラ17および測距センサ18の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末100の近傍の物体1010を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体1010としてのユーザの手、予め定められた形状のマーカなどが検出され、検出結果として得られた物体1010の色、形状、動き、または、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末100は、カメラ17の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ(ユーザの手の一連の動き)を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。
あるいは、操作部がタッチスクリーン15で構成される場合、ユーザ端末100は、タッチスクリーン15の入力部151に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信IF13で構成される場合、ユーザ端末100は、コントローラ1020から送信される信号(例えば、出力値)をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力IF14で構成される場合、該入出力IF14と接続されるコントローラ1020とは異なる入力装置(図示せず)から出力される信号をユーザの入力操作として特定し、受け付ける。
<各装置のハードウェア構成要素>
プロセッサ10は、ユーザ端末100全体の動作を制御する。プロセッサ20は、サーバ200全体の動作を制御する。プロセッサ10および20は、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、およびGPU(Graphics Processing Unit)を含む。
プロセッサ10は後述するストレージ12からプログラムを読み出し、後述するメモリ11に展開する。プロセッサ20は後述するストレージ22からプログラムを読み出し、後述するメモリ21に展開する。プロセッサ10およびプロセッサ20は展開したプログラムを実行する。
メモリ11および21は主記憶装置である。メモリ11および21は、ROM(Read Only Memory)およびRAM(Random Access Memory)等の記憶装置で構成される。メモリ11は、プロセッサ10が後述するストレージ12から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ10に作業領域を提供する。メモリ11は、プロセッサ10がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ21は、プロセッサ20が後述するストレージ22から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ20に作業領域を提供する。メモリ21は、プロセッサ20がプログラムに従って動作している間に生成した各種データも一時的に記憶する。
本実施形態においてプログラムとは、ゲームをユーザ端末100により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームをユーザ端末100とサーバ200との協働により実現するためのゲームプログラムであってもよい。なお、ユーザ端末100とサーバ200との協働により実現されるゲームは、一例として、ユーザ端末100において起動されたブラウザ上で実行されるゲームであってもよい。あるいは、該プログラムは、該ゲームを複数のユーザ端末100の協働により実現するためのゲームプログラムであってもよい。また、各種データとは、ユーザ情報およびゲーム情報などのゲームに関するデータ、ならびに、ユーザ端末100とサーバ200との間または複数のユーザ端末100間で送受信する指示または通知を含んでいる。
ストレージ12および22は補助記憶装置である。ストレージ12および22は、フラッシュメモリまたはHDD(Hard Disk Drive)等の記憶装置で構成される。ストレージ12およびストレージ22には、ゲームに関する各種データが格納される。
通信IF13は、ユーザ端末100における各種データの送受信を制御する。通信IF23は、サーバ200における各種データの送受信を制御する。通信IF13および23は例えば、無線LAN(Local Area Network)を介する通信、有線LAN、無線LAN、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。
入出力IF14は、ユーザ端末100がデータの入力を受け付けるためのインターフェースであり、またユーザ端末100がデータを出力するためのインターフェースである。入出力IF14は、USB(Universal Serial Bus)等を介してデータの入出力を行ってもよい。入出力IF14は、例えば、ユーザ端末100の物理ボタン、カメラ、マイク、または、スピーカ等を含み得る。サーバ200の入出力IF24は、サーバ200がデータの入力を受け付けるためのインターフェースであり、またサーバ200がデータを出力するためのインターフェースである。入出力IF24は、例えば、マウスまたはキーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。
ユーザ端末100のタッチスクリーン15は、入力部151と表示部152とを組み合わせた電子部品である。入力部151は、例えばタッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部152は、例えば液晶ディスプレイ、または有機EL(Electro-Luminescence)ディスプレイ等によって構成される。
入力部151は、入力面に対しユーザの操作(主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作)が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部151は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。なお、タッチスクリーン15に対し入力操作を行うための指示体は特に限定されない。例えば、指示体はユーザの手指であっても、スタイラスペン等であってもよい。
図示していないが、ユーザ端末100は、該ユーザ端末100の保持姿勢を特定するための1以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。ユーザ端末100がセンサを備えている場合、プロセッサ10は、センサの出力からユーザ端末100の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ10は、ユーザ端末100が縦向きに保持されているときには、縦長の画像を表示部152に表示させる縦画面表示としてもよい。一方、ユーザ端末100が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ10は、ユーザ端末100の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。
カメラ17は、イメージセンサ等を含み、レンズから入射する入射光を電気信号に変換することで撮影画像を生成する。
測距センサ18は、測定対象物までの距離を測定するセンサである。測距センサ18は、例えば、パルス変換した光を発する光源と、光を受ける受光素子とを含む。測距センサ18は、光源からの発光タイミングと、該光源から発せられた光が測定対象物にあたって反射されて生じる反射光の受光タイミングとにより、測定対象物までの距離を測定する。測距センサ18は、指向性を有する光を発する光源を有することとしてもよい。
ここで、ユーザ端末100が、カメラ17と測距センサ18とを用いて、ユーザ端末100の近傍の物体1010を検出した検出結果を、ユーザの入力操作として受け付ける例をさらに説明する。カメラ17および測距センサ18は、例えば、ユーザ端末100の筐体の側面に設けられてもよい。カメラ17の近傍に測距センサ18が設けられてもよい。カメラ17としては、例えば赤外線カメラを用いることができる。この場合、赤外線を照射する照明装置および可視光を遮断するフィルタ等が、カメラ17に設けられてもよい。これにより、屋外か屋内かにかかわらず、カメラ17の撮影画像に基づく物体の検出精度をいっそう向上させることができる。
プロセッサ10は、カメラ17の撮影画像に対して、例えば以下の(1)〜(5)に示す処理のうち1つ以上の処理を行ってもよい。(1)プロセッサ10は、カメラ17の撮影画像に対し画像認識処理を行うことで、該撮影画像にユーザの手が含まれているか否かを特定する。プロセッサ10は、上述の画像認識処理において採用する解析技術として、例えばパターンマッチング等の技術を用いてよい。(2)また、プロセッサ10は、ユーザの手の形状から、ユーザのジェスチャを検出する。プロセッサ10は、例えば、撮影画像から検出されるユーザの手の形状から、ユーザの指の本数(伸びている指の本数)を特定する。プロセッサ10はさらに、特定した指の本数から、ユーザが行ったジェスチャを特定する。例えば、プロセッサ10は、指の本数が5本である場合、ユーザが「パー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が0本である(指が検出されなかった)場合、ユーザが「グー」のジェスチャを行ったと判定する。また、プロセッサ10は、指の本数が2本である場合、ユーザが「チョキ」のジェスチャを行ったと判定する。(3)プロセッサ10は、カメラ17の撮影画像に対し、画像認識処理を行うことにより、ユーザの指が人差し指のみ立てた状態であるか、ユーザの指がはじくような動きをしたかを検出する。(4)プロセッサ10は、カメラ17の撮影画像の画像認識結果、および、測距センサ18の出力値等の少なくともいずれか1つに基づいて、ユーザ端末100の近傍の物体1010(ユーザの手など)とユーザ端末100との距離を検出する。例えば、プロセッサ10は、カメラ17の撮影画像から特定されるユーザの手の形状の大小により、ユーザの手がユーザ端末100の近傍(例えば所定値未満の距離)にあるのか、遠く(例えば所定値以上の距離)にあるのかを検出する。なお、撮影画像が動画の場合、プロセッサ10は、ユーザの手がユーザ端末100に接近しているのか遠ざかっているのかを検出してもよい。(5)カメラ17の撮影画像の画像認識結果等に基づいて、ユーザの手が検出されている状態で、ユーザ端末100とユーザの手との距離が変化していることが判明した場合、プロセッサ10は、ユーザが手をカメラ17の撮影方向において振っていると認識する。カメラ17の撮影範囲よりも指向性が強い測距センサ18において、物体が検出されたりされなかったりする場合に、プロセッサ10は、ユーザが手をカメラの撮影方向に直交する方向に振っていると認識する。
このように、プロセッサ10は、カメラ17の撮影画像に対する画像認識により、ユーザが手を握りこんでいるか否か(「グー」のジェスチャであるか、それ以外のジェスチャ(例えば「パー」)であるか)を検出する。また、プロセッサ10は、ユーザの手の形状とともに、ユーザがこの手をどのように移動させているかを検出する。また、プロセッサ10は、ユーザがこの手をユーザ端末100に対して接近させているのか遠ざけているのかを検出する。このような操作は、例えば、マウスまたはタッチパネルなどのポインティングデバイスを用いた操作に対応させることができる。ユーザ端末100は、例えば、ユーザの手の移動に応じて、タッチスクリーン15においてポインタを移動させ、ユーザのジェスチャ「グー」を検出する。この場合、ユーザ端末100は、ユーザが選択操作を継続中であると認識する。選択操作の継続とは、例えば、マウスがクリックされて押し込まれた状態が維持されること、または、タッチパネルに対してタッチダウン操作がなされた後タッチされた状態が維持されることに対応する。また、ユーザ端末100は、ユーザのジェスチャ「グー」が検出されている状態で、さらにユーザが手を移動させると、このような一連のジェスチャを、スワイプ操作(またはドラッグ操作)に対応する操作として認識することもできる。また、ユーザ端末100は、カメラ17の撮影画像によるユーザの手の検出結果に基づいて、ユーザが指をはじくようなジェスチャを検出した場合に、当該ジェスチャを、マウスのクリックまたはタッチパネルへのタップ操作に対応する操作として認識してもよい。
<ゲーム概要>
ゲームシステム1が実現するゲームは、ゲーム空間にキャラクタオブジェクト(以降、単にキャラクタと称する)を配置し、該ゲーム空間内で、該キャラクタをユーザの入力操作に応じて動作させるゲームである。ゲームシステム1に基づくゲームは、3次元のゲーム空間および3次元のオブジェクトで表現される3Dゲームであってもよいし、2次元のゲーム空間および2次元のオブジェクトで表現される2Dゲームであってもよい。なお、以降、ユーザの入力操作に応じて動作するキャラクタを「操作キャラクタ」と称する。
詳しくは後述するが、ゲームシステム1が実現するゲームでは、ユーザは、操作キャラクタを操作して、該キャラクタを、同じゲーム空間に配置される敵キャラクタと戦闘させることにより、ゲームを進行させる。また、ゲームシステム1が実現するゲームでは、ユーザは、キャラクタを獲得するための抽選を行うことができる。
ゲームシステム1が実現するゲームの一例としては、仮想的なゲーム空間内に配置されたキャラクタを、ユーザが自由に操作して移動および戦闘させることができる、オープンワールドのゲームであってもよい。本実施形態では一例として、ゲームシステム1がオープンワールドのRPG(Role-Playing Game)を実現する場合について説明する。
なお、ゲームシステム1が実現するゲームは、マルチプレイが可能であってもよい。例えば、該ゲームは、複数のユーザが、各自のユーザ端末100を介して同時に同じゲーム空間内で各自の操作キャラクタを動作させてゲームを進行させる、MMORPG(Massively Multiplayer Online Role-Playing Game)であってもよい。ただし、ゲームシステム1が実現するゲームのジャンルおよびゲーム内容は、上述したタイプのものに限定されない。
<ゲームシステム1の機能的構成>
図2は、ゲームシステム1に含まれるサーバ200およびユーザ端末100の機能的構成を示すブロック図である。サーバ200およびユーザ端末100のそれぞれは、図示しない、一般的なコンピュータとして機能する場合に必要な機能的構成、および、ゲームにおける公知の機能を実現するために必要な機能的構成を含み得る。
ユーザ端末100は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末100は、プロセッサ10、メモリ11、ストレージ12、通信IF13、および入出力IF14等の協働によって、制御部110および記憶部120として機能する。
サーバ200は、各ユーザ端末100と通信して、ユーザ端末100がゲームを進行させるのを支援する機能を有する。例えば、有価データの販売、サービスの提供などを実行する。ゲームがマルチプレイゲームである場合には、サーバ200は、ゲームに参加する各ユーザ端末100と通信して、ユーザ端末100同士のやりとりを仲介する機能を有していてもよい。サーバ200は、プロセッサ20、メモリ21、ストレージ22、通信IF23、および入出力IF24等の協働によって、制御部210および記憶部220として機能する。
記憶部120および記憶部220は、ゲームプログラム231、ゲーム情報232、およびユーザ情報233を格納する。ゲームプログラム231は、ユーザ端末100およびサーバ200が実行するゲームプログラムである。
ゲーム情報232は、制御部110および制御部210がゲームプログラム231を実行する際に参照するデータである。
ユーザ情報233は、ユーザのアカウント毎に記憶される情報である。ある1アカウントについてのユーザ情報233は、少なくとも1台のユーザ端末100と対応付けられている。本実施形態では、1台のユーザ端末100に、1つのアカウントが対応付けられている例について説明する。記憶部120は、ユーザ端末100に対応するアカウントのユーザ情報233を記憶する。一方、記憶部220は、各ユーザ端末100から収集したユーザ情報233をまとめて記憶している。ユーザ情報233は、キャラクタデータ233Aを含む。キャラクタデータ233Aは、ユーザが所持しているキャラクタについてのデータである。キャラクタデータ233Aの詳細については後述する。
(サーバ200の機能的構成)
制御部210は、記憶部220に格納されたゲームプログラム231を実行することにより、サーバ200を統括的に制御する。例えば、制御部210は、ユーザ端末100に各種データおよびプログラム等を送信する。ゲームがマルチプレイゲームである場合には、制御部210は、ユーザ端末100からマルチプレイの同期の要求を受信して、同期のためのデータをユーザ端末100に送信してもよい。
制御部210は、ゲームプログラム231の記述に応じて、送受信部211、サーバ処理部212、およびデータ管理部213として機能する。制御部210は、実行するゲームの性質に応じて、ユーザ端末100におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。
送受信部211は、ユーザ端末100から各種データおよびリクエストを受信する。例えば、送受信部211は、ゲーム情報232もしくはユーザ情報233の一部または全部を、ユーザ端末100から受信する。また、送受信部211は、ユーザ情報233の一部として、ユーザ端末100からキャラクタデータ233Aを受信してもよい。また、送受信部211は、ユーザ端末100から抽選の実行リクエストを受信してもよい。
送受信部211は、ユーザ端末100に対し各種データおよびリクエストを送信する。例えば、送受信部211は、抽選の実行リクエストの送信元であるユーザ端末100に対して、抽選結果を送信してもよい。また例えば、送受信部211は、抽選の実行リクエストの送信元であるユーザ端末100に対して、更新後のキャラクタデータ233Aを送信してもよい。
サーバ処理部212は、ゲームを提供するために必要な演算処理を行う。サーバ処理部212は送受信部211に対し、各種データの送信を指示する。サーバ処理部212は、データ管理部213に対し、ゲーム情報232、およびユーザ情報233に含まれる各種情報の追加、更新、または削除を指示する。サーバ処理部212は、抽選に係る処理を実行してもよい。
データ管理部213は、記憶部220に格納されているデータを管理する。データ管理部213は、サーバ処理部212からの指示に応じてゲーム情報232およびユーザ情報233に含まれる各種情報の、追加、更新、または削除を実行する。データ管理部213は、サーバ処理部212の指示に従って、記憶部220からゲーム情報232およびユーザ情報233のうち少なくとも一方の情報を読み出してもよい。データ管理部213は、サーバ処理部212の指示に従って、ゲームプログラム231のうち、あるユーザ端末100で実行する分のプログラムを記憶部220から読み出して、送受信部211を介し該ユーザ端末100に送信してもよい。
(ユーザ端末100の機能的構成)
制御部110は、記憶部120に格納されたゲームプログラム231を実行することにより、ユーザ端末100を統括的に制御する。例えば、制御部110は、ゲームプログラム231およびユーザの操作にしたがって、ゲームを進行させる。また、制御部110は、ゲームを進行させている間、必要に応じて、サーバ200と通信して、情報の送受信を行う。
制御部110は、ゲームプログラム231の記述に応じて、操作受付部111、ゲーム進行部112、カメラ配置制御部113、オブジェクト制御部114、表示制御部115、および通信部116として機能する。制御部110は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。
操作受付部111は、入力部151に対するユーザの入力操作を検知し受け付ける。操作受付部111は、タッチスクリーン15およびその他の入出力IF14を介したコンソールに対してユーザが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部110の各要素に出力する。
例えば、操作受付部111は、入力部151に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部111は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部111は、連続して検知されていた入力が途切れると、タッチスクリーン15から接触入力が解除されたことを検知する。
通信部116は、サーバ200に対し各種データおよびリクエストを送信する。例えば、通信部116はサーバ200に対し、ゲーム情報232もしくはユーザ情報233の一部または全部を送信する。例えば、通信部116は抽選の実行リクエストをサーバ200に送信する。また、通信部116はサーバ200に対して、ユーザ情報233の一部としてキャラクタデータ233Aを送信してもよい。
通信部116は、サーバ200から各種データおよびリクエストを受信する。例えば、通信部116はサーバ200から、ゲーム情報232もしくはユーザ情報233の一部または全部を受信する。また、通信部116は、サーバ200から抽選結果を示す情報を受信してもよい。また、通信部116は、サーバ200から更新後のキャラクタデータ233Aを受信してもよい。
ゲーム進行部112は、ゲームの進行に係る各種処理を行う。例えば、ゲーム進行部112は、操作受付部111が受け付けた入力操作の位置の座標と、操作の種類と、ゲームの進行状況とに基づいて、ユーザの指示内容を特定する。また、ゲーム進行部112は、ゲームの進行に係る各種判定処理を行う。また、ゲーム進行部112は、記憶部120に記憶された、ゲーム情報232およびユーザ情報233に含まれる各種情報の追加、更新、または削除を行う。ゲーム進行部112は、戦闘処理部112A、抽選部112B、およびキャラクタ付与部112Cを含む。
戦闘処理部112Aは、操作キャラクタおよび自動戦闘キャラクタと、敵キャラクタとの戦闘に係る処理を実行する。また、戦闘処理部112Aは、戦闘の結果、所定の条件が満たされた場合、ユーザに付与するキャラクタを決定する。戦闘処理部112Aは付与するキャラクタを決定すると、該キャラクタをキャラクタ付与部112Cに通知する。
抽選部112Bは、キャラクタを獲得するための抽選に係る処理を実行する。抽選の方法は特に限定されない。例えば、抽選部112Bは、ユーザの所定の入力操作に応じてゲーム情報232に含まれている筐体(抽選のデータテーブル)を参照し、該テーブルに基づいて抽選結果を定めてよい。抽選部112Bは、抽選の結果、すなわち、ユーザに付与するキャラクタをキャラクタ付与部112Cに通知する。
キャラクタ付与部112Cは、戦闘処理部112Aの処理の結果、または抽選部112Bの抽選の結果、付与すると決定されたキャラクタを、ユーザに付与する。キャラクタ付与部112Cは、戦闘処理部112Aまたは抽選部112Bが付与するキャラクタを決定すると、該キャラクタに対応するキャラクタの初期データをゲーム情報232から読み出して、該データをユーザ情報233のキャラクタデータ233Aに追加する。
カメラ配置制御部113は、ゲーム空間のうちユーザに提示する領域を指定するための仮想カメラを規定する。カメラ配置制御部113は、仮想カメラのゲーム空間内での位置および向きを規定することにより、仮想カメラをゲーム空間に仮想的に配置する。カメラ配置制御部113は、仮想カメラで規定される視野領域および当該視野領域に配置されているオブジェクトを描画した画像を作成するよう、表示制御部115に指示する。なお、カメラ配置制御部113は、仮想カメラの位置および向きを、随時変更してよい。
オブジェクト制御部114は、ゲーム情報232に含まれる、オブジェクトの設定情報に基づきゲーム空間にオブジェクトを配置する。また、オブジェクト制御部114は、ゲーム空間に配置したオブジェクトを制御する。例えば、オブジェクト制御部114は、オブジェクトのゲーム空間内での位置、向き、形状、色等を変更したり、オブジェクトに所定の一連の動作を行わせたりする。例えば、オブジェクト制御部114は、操作キャラクタをゲーム進行部112が決定した移動方向、移動速度、および移動距離で移動させる。
表示制御部115は、表示部152に画像を表示させる。例えば、表示制御部115は、ゲーム空間のうち、カメラ配置制御部113が規定する仮想カメラの視野の領域と、当該領域に存在するオブジェクトとを含む画像を生成し、表示部152に表示させる。
オブジェクト制御部114は、UI(user interface)を構築するためのオブジェクト(UIオブジェクト)をゲーム空間に配置して、該UIオブジェクトを制御してもよい。また、表示制御部115は、画像にアイコン、ボタン、リスト、メニュー画面等、ゲームの種々の操作に必要なUIに係る画像(UI画像)を重畳して表示させてもよい。UI画像およびUIオブジェクトとは、ユーザが、ゲームの進行上必要な入力をユーザ端末100に対して行うためのツールである。また、UI画像およびUIオブジェクトとは、ユーザが、ゲームの進行中に出力される情報をユーザ端末100から得るためのツールである。
なお、図2に示すサーバ200およびユーザ端末100の機能は一例にすぎない。サーバ200は、ユーザ端末100が備える機能の少なくとも一部を備えていてもよい。また、ユーザ端末100は、サーバ200が備える機能の少なくとも一部を備えていてもよい。さらに、ユーザ端末100およびサーバ200以外の他の装置をゲームシステム1の構成要素とし、該他の装置にゲームシステム1における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末100、サーバ200、および他の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。
(ゲーム空間とオブジェクトの配置)
ユーザ端末100のゲーム進行部112は、ゲームプログラム231に基づくゲームを開始させる。ゲームが開始すると、オブジェクト制御部114は、ゲーム進行部112の指示に従って、所定のゲーム空間を構築し、該ゲーム空間に、予め定められた操作キャラクタを配置する。また、オブジェクト制御部114は該ゲーム空間に、木、岩、建物等、ゲーム空間の背景となる背景オブジェクトを配置してもよい。また、オブジェクト制御部114は該ゲーム空間に、操作キャラクタの戦闘相手である敵キャラクタ(他のキャラクタ)を配置してもよい。
なお、本実施形態では、ゲームシステム1が実現するゲームの一例として、ユーザが、自分の所持しているキャラクタのうち、操作可能なキャラクタの中から1体のキャラクタを選んで、該キャラクタを操作する例について説明する。しかしながら、ゲームシステム1が実現するゲームでは、ユーザに、一度に複数のキャラクタ(例えば、後述する人間キャラクタと騎乗モンスター、または複数の人間キャラクタ等)を操作可能とさせてもよい。また、各キャラクタの全ての動きをユーザの入力操作に応じて行うのではなく、攻撃のタイミング、移動の方向等、一部の動きのみをユーザに操作させてもよい(所謂、セミオート操作)。
本実施形態では、一例として、ゲームの開始時に草原等、屋外の空間に相当するゲーム空間(フィールド空間と称する)がオブジェクト制御部114によって構築され、該フィールド空間に操作キャラクタ等が配置される場合について説明する。
なお、オブジェクト制御部114が構築するゲーム空間は、上述したフィールド空間に限られない。例えば、オブジェクト制御部114は、ゲーム進行部112の指示に応じて、洞窟または建物の中など、屋内(所謂、ダンジョン)の空間に相当するゲーム空間(ダンジョン空間と称する)を構築し、該空間に操作キャラクタ等を配置してもよい。例えば操作受付部111がダンジョンに入ることを指示する入力操作を受け付けた場合、ゲーム進行部112は、オブジェクト制御部114にダンジョン空間の構築および該空間への操作キャラクタ等の配置を指示してもよい。
図3は、ゲーム空間の一種である、フィールド空間を描画した画面の一例を示す図である。フィールド空間には、少なくとも操作キャラクタが1体配置される。図3の状態(A)は、フィールド空間において、人間キャラクタ301が、該キャラクタの武器302を背に持った状態で配置された状態を示す図である。
ここで、「人間キャラクタ」とは、操作可能なキャラクタの一種である。なお、「人間キャラクタ」はあくまで名称の一例であり、人間キャラクタ301は必ずしも人間または人型のキャラクタでなくてもよい。また、武器302は必須ではない。
(騎乗モンスターと自動戦闘モンスター)
図3の状態(B)は、フィールド空間において、人間キャラクタ301が騎乗モンスター303に騎乗した状態を示す図である。騎乗モンスター303とは、操作可能なキャラクタの一種であり、人間キャラクタ301の仲間(すなわち、戦闘における味方)となるキャラクタの一種である。また、騎乗モンスター303は、人間キャラクタ301の代わりに戦闘に参加可能であってよい。
人間キャラクタ301は、騎乗モンスター303に騎乗することができる。換言すると、騎乗モンスター303は、人間キャラクタ301の乗り物となるキャラクタである。なお、「戦闘に参加するキャラクタ」とは、ある敵キャラクタ(後述)との戦闘中に、該ゲーム空間内に配置されているキャラクタであって、該戦闘中にユーザの操作キャラクタの味方となるキャラクタである。なお、戦闘に参加するキャラクタは、敵キャラクタに対し必ずしも攻撃等のアクションを実行しなくてもよい。また、戦闘に参加するキャラクタは、敵キャラクタからのアクションを受けなくてもよい。例えば、人間キャラクタ301が騎乗モンスター303に騎乗しているが、入力操作に基づく攻撃等の各種アクションは騎乗モンスター303のみが行う場合でも、人間キャラクタ301は戦闘に参加していることとする。
ユーザが騎乗モンスター303を指定する操作、および騎乗を指示する入力操作を行うと、操作受付部111はこれらの操作を受け付け、ゲーム進行部112は人間キャラクタ301を、指定された騎乗モンスター303と関連付ける。さらに、ゲーム進行部112は人間キャラクタ301と騎乗モンスター303を関連付けたことをオブジェクト制御部114に通知する。オブジェクト制御部114は該通知を受けて、人間キャラクタ301を騎乗モンスター303に騎乗させた体制および位置に配置する。これにより、ユーザは、ある人間キャラクタ301に対し、乗り物としての騎乗モンスター303の関連付けを変えてゲームを楽しむことができる。したがって、ゲームの興趣性が向上する。
ゲーム進行部112の戦闘処理部112Aは、人間キャラクタ301を騎乗モンスター303に騎乗させた場合、騎乗している人間キャラクタ301を以降の戦闘で攻撃、防御等のアクションをさせないようにしてもよい。換言すると、戦闘処理部112Aは、騎乗モンスター303および人間キャラクタ301の両方を戦闘に参加させるが、いずれか片方しか戦闘での種々のアクションに係る入力操作は行えないようにしてもよい。
なお、ゲーム進行部112はユーザの所定の入力操作に応じて、人間キャラクタ301の騎乗状態を解除してもよい。この場合、騎乗モンスター303はフィールド空間から削除され、人間キャラクタ301のみが該空間に残る。
本発明に係る人間キャラクタ301と騎乗モンスター303との見かけの関係性は「騎乗」に限定されず、騎乗モンスター303の外観に応じて適宜定められてよい。例えば、人間キャラクタ301と鳥型の騎乗モンスター303とが関連付けられた場合、騎乗モンスター303は人間キャラクタ301を掴んで飛び上がってもよい。
なお、操作受付部111がユーザの自動戦闘モンスター304を操作キャラクタと関連付ける(自動戦闘モンスター304を召喚する)入力操作を受け付けた場合、ゲーム進行部112は、自動戦闘モンスター304を操作キャラクタ(人間キャラクタ301または騎乗モンスター303)に関連付けてもよい。そして、ゲーム進行部112は、フィールド空間に自動戦闘モンスター304を配置するよう、オブジェクト制御部114に指示してもよい。そして、オブジェクト制御部114は自動戦闘モンスター304をフィールド空間に配置してもよい。
自動戦闘モンスター304とは、ユーザが操作不可能なキャラクタの一種である。また、自動戦闘モンスター304は騎乗モンスター303と異なり、人間キャラクタ301が騎乗することができないキャラクタである。後述する戦闘において、ゲーム進行部112およびオブジェクト制御部114が所定の行動パターンで自動戦闘モンスター304を動かすことにより、自動戦闘モンスター304は、自動的に戦闘に参加する。なお、以降の説明では、騎乗モンスター303と自動戦闘モンスター304をまとめて「モンスター」とも称する。
なお、フィールド空間における仮想カメラの位置は、ユーザの操作キャラクタ(人間キャラクタ301または騎乗モンスター303)がユーザ端末100の略中央に表示されるような位置であることが望ましい。これにより、表示部152の表示画面上で、ユーザがタッチスクリーン15をタッチ操作する領域(例えば、図3の状態(A)および(B)の領域A)を確保することができる。
(戦闘)
図4は、戦闘時のフィールド空間を描画した画面の一例を示す図である。ユーザは、フィールド空間内を、人間キャラクタ301または騎乗モンスター303を操作して移動する。一方、フィールド空間内には、所定のタイミングで配置され、所定の行動パターンで移動等の行動を行う、敵キャラクタが配置されている。人間キャラクタ301(および騎乗モンスター303)と、敵キャラクタとの位置関係(例えば距離および各キャラクタの向き)が第1条件を満たした場合、戦闘処理部112Aは、人間キャラクタ301(および騎乗モンスター303)が敵キャラクタ305と遭遇して戦闘が開始したと判定し、戦闘に係る各種処理を開始する。一方、敵キャラクタが倒された(フィールド空間から削除された)、または人間キャラクタ301(および騎乗モンスター303)と敵キャラクタとの位置関係が第2条件を満たした場合、戦闘処理部112Aは、戦闘が終了したと判定し、該戦闘に係る各種処理を終了してもよい。
なお、戦闘処理部112Aは、戦闘の開始および終了を定めず、フィールド空間での移動からシームレスに戦闘が開始されるようにしてもよい。この場合、戦闘処理部112Aは、操作受付部111が人間キャラクタ301または騎乗モンスター303の所定の動作(例えば、攻撃)を指示する入力操作を受け付けた場合に、戦闘に係る各種処理を開始してよい。
図4の状態(A)は、人間キャラクタ301と敵キャラクタ305との戦闘が開始した状態を示す図である。戦闘処理部112Aにより戦闘が開始したと判定された場合、オブジェクト制御部114は、図示の通り人間キャラクタ301が武器302を構えた状態となるように、人間キャラクタ301および武器302の配置を調整してもよい。
敵キャラクタ305は、所定の行動パターンに従って戦闘処理部112Aにより行動が制御されているNPC(non player character)である。敵キャラクタ305は、騎乗モンスター303または自動戦闘モンスター304の一種と同様の外見および能力(移動および攻撃方法等)を有していてもよい。
戦闘処理部112Aは、操作受付部111の受け付ける、戦闘時の攻撃、防御、回避、移動等の入力操作に応じて、人間キャラクタ301と敵キャラクタ305との戦闘を進める。例えば、攻撃を指示する入力操作を操作受付部111が受け付けた場合、戦闘処理部112Aは、人間キャラクタ301の攻撃力の値と、敵キャラクタ305の防御力の値とに応じて敵キャラクタ305に与えられるダメージを計算する。オブジェクト制御部114は、戦闘処理部112Aの進める各種処理に応じて、人間キャラクタ301、武器302、および敵キャラクタ305の配置、移動、ポーズ等を制御する。
図4の状態(B)は、人間キャラクタ301が騎乗モンスター303に騎乗した状態で敵キャラクタ305と戦闘している状態を示す図である。上述の通り、人間キャラクタ301は騎乗モンスター303に騎乗すると、攻撃等の諸動作が出来なくなり、人間キャラクタ301に代わり騎乗モンスター303が該諸動作を実行する。
例えば、ユーザの入力操作に応じて、騎乗モンスター303は図示のように、その外見および能力に応じた攻撃方法で、敵キャラクタ305に攻撃する。これにより、騎乗モンスター303に応じたアクションを実行させることができるため、戦闘における戦略性を高めることができる。したがって、ゲームの興趣性を向上させることができる。
戦闘処理部112Aは、騎乗モンスター303の能力に応じて騎乗モンスター303と敵キャラクタ305との戦闘を進める。なお、自動戦闘モンスター304が配置されている場合、戦闘処理部112Aは、自動戦闘モンスター304と敵キャラクタ305との戦闘に係る処理も実行する。
図4の状態(C)は、戦闘に勝利した状態を示す図である。例えば図示のように、人間キャラクタ301が1人で戦闘し、敵キャラクタ305に勝利したとする。この場合、戦闘処理部112Aは、戦闘の内容または結果に応じた報酬アイテムを、ユーザに付与する。具体的には、戦闘処理部112Aは、ユーザ情報233に含まれている該報酬アイテムの個数を示す値を増加させる。なお、戦闘処理部112Aは、付与される報酬アイテムの種類および数を、敵キャラクタ305の種類およびレベル等に応じて変化させてもよい。また、オブジェクト制御部114または表示制御部115は、ユーザが入手した(ユーザに付与された)報酬アイテムの種類および数を示すUIオブジェクト306またはUI画像306を、配置して表示してもよい。
詳しくは後述するが、戦闘処理部112Aは、該報酬アイテムを付与することで、報酬アイテムの所持数が所定数以上になった場合、ユーザに付与するキャラクタを決定してもよい。なお、付与するキャラクタは、人間キャラクタ301、騎乗モンスター303、および自動戦闘モンスター304のいずれであってもよいが、騎乗モンスター303または自動戦闘モンスター304であることが望ましい。
人間キャラクタ301、騎乗モンスター303、および自動戦闘モンスター304はそれぞれの個体に応じた能力が予め設定されている。該能力の設定は、キャラクタデータ233Aとして、記憶部120に格納されている。
(キャラクタデータ)
図5は、キャラクタデータ233Aのデータ構造を示す図である。キャラクタデータ233Aは、図示の通り、キャラクタ1個体を一意に示す識別コードに対して、該キャラクタの種類を示す情報と、名称と、希少度を示す情報と、戦闘に係る種々のパラメータ(戦闘パラメータ)の値と、該キャラクタが装備している(該キャラクタに対応付けられている)装備品を示す情報と、が対応付けられたデータである。キャラクタデータ233Aの1レコードは、キャラクタ1個体を示している。なお、キャラクタデータ233Aには同一名称のモンスターが含まれていてもよい。換言すると、ユーザが、同じ外見のモンスターを複数所持することが可能であってもよい。
キャラクタの種類とは、キャラクタが人間キャラクタ、騎乗モンスター、および自動戦闘モンスターのいずれであるかを示す情報である。キャラクタの名称は、該キャラクタの名称を示す。本実施形態では、同じ名称のキャラクタは、同じ外見である。希少度は、該キャラクタの入手難易度(所謂、レアリティ)を示す。図示の例では、Dが最も希少度が低く、Aが最も希少度が高い。戦闘パラメータは、戦闘処理部112Aが戦闘の際に参照して戦闘に係る処理を実行するためのパラメータである。
装備品を示す情報は、該キャラクタに対応付けられている(すなわち、該キャラクタが装備している)装備品を示している。なお、図示の例では人間キャラクタのみが装備品を装備しているが、騎乗モンスターおよび自動戦闘モンスターも装備品を装備可能であってよい。キャラクタに装備品が対応付けられている場合、戦闘処理部112Aは、該装備品の攻撃力または防御力等のパラメータも参照して、戦闘に係る処理を行う。例えば、戦闘処理部112Aは、キャラクタの攻撃力に、装備品の攻撃力を足し合わせた値を、該キャラクタの攻撃に係るダメージ計算の際に用いる。なお、ユーザが所持している装備品および該装備品のパラメータを示す情報は、ユーザ情報233に含まれている。
(戦闘によるキャラクタ付与)
ゲームシステム1が実現するゲームでは、以下で説明する、戦闘付与処理または抽選付与処理のうちいずれか一方が実行された場合に、ユーザにモンスターを付与する。
戦闘付与処理とは、操作キャラクタと敵キャラクタとを戦闘させた結果に応じて、ユーザにモンスターを付与する処理である。図6は、ゲームシステム1における戦闘付与処理の流れの一例を示すフローチャートである。
ユーザ端末100のゲーム進行部112がゲームを開始させると、オブジェクト制御部114は所定のゲーム空間(例えば、フィールド空間)に操作キャラクタを配置し、ゲーム進行部112およびオブジェクト制御部114は、ユーザの入力操作に応じて該操作キャラクタを動作させる(S100)。以降、ゲーム進行部112は、ユーザの入力操作に応じて、操作キャラクタの移動、騎乗、自動戦闘モンスター304の召喚等を実行する。また、オブジェクト制御部114は、ゲーム進行部112からの指示に従って、操作キャラクタが配置されたゲーム空間に配置されると定められている敵キャラクタとを動作させる。
戦闘処理部112Aが、操作キャラクタが敵キャラクタと遭遇したと判定するまで、ゲーム進行部112およびオブジェクト制御部114は上述した制御を実行する(S102でNO)。操作キャラクタと敵キャラクタとの位置関係が第1条件を満たした場合、戦闘処理部112Aは、操作キャラクタがある敵キャラクタと遭遇したと判定する(S102でYES)。この場合、戦闘処理部112Aは、戦闘に係る各種処理を進め、操作キャラクタ(および自動戦闘モンスター)と、該ある敵キャラクタとを戦闘させる(S104)。戦闘において、所定の条件(第2条件)が満たされるまで、戦闘は継続される(S106でNO)。第2条件が満たされた場合(S106でYES)、戦闘処理部112Aは、該ある敵キャラクタとの戦闘が終了したと判定する。なお、敵キャラクタが複数存在する場合、戦闘処理部112Aは、操作キャラクタと他の敵キャラクタとの戦闘は継続させる。
戦闘が終了したと判定すると、戦闘処理部112Aは、該戦闘の内容に応じて、ユーザに報酬アイテムを付与する(S108)。さらに、戦闘処理部112Aは、報酬アイテムが所定数貯まったか否かを判定する(S110)。報酬アイテムが所定数貯まっていない場合(S110でNO)、戦闘処理部112Aは、以降の処理を行わない。一方、報酬アイテムが所定数貯まっている場合(S110でYES)、戦闘処理部112Aは、ユーザの所持する報酬アイテムを該所定数だけ消費し(S112)、該報酬アイテムに応じて、ユーザに付与するモンスターを決定する(S114)。例えば、戦闘処理部112Aは、報酬アイテムの種類に応じてユーザに付与するモンスターを決定する。キャラクタ付与部112Cは、決定したモンスターをユーザに付与する(S116)。
このように、戦闘により獲得したキャラクタをユーザに付与する仕様とすることで、ユーザに、戦闘を行う動機を与えることができる。さらに、戦闘でユーザに付与され得る(ユーザが獲得できる)キャラクタは、戦闘に参加可能である。したがって、ユーザに、獲得したキャラクタを戦闘に参加させようとする、すなわち、さらに戦闘を行う動機を与えることができる。そして、該戦闘の結果に応じて、さらにキャラクタがユーザに付与される。このように、このように、モンスターの獲得と、戦闘という2つの目的を循環的にユーザに提示することができるため、ユーザにゲームを飽きずに継続させることができる。
また、報酬アイテムが所定数貯まった場合にモンスターを付与することとすることで、ユーザに戦闘を繰り返し、報酬アイテムを収集するという目的を持たせることができる。
なお、報酬アイテムの種類は、敵キャラクタの種類(例えば、敵キャラクタの名称)と1対1で対応していることが望ましい。例えば、ある騎乗モンスターが敵キャラクタとして出現した場合、戦闘処理部112Aは、該騎乗モンスターに対応する報酬アイテムを付与することが望ましい。そして、該報酬アイテムが所定数以上貯まった場合、戦闘処理部112Aは、前記敵キャラクタとしての騎乗モンスターを、ユーザに付与する対象のモンスターとして決定してもよい。
これにより、ユーザは戦闘に勝利したとき、戦った敵キャラクタを獲得することができる。したがって、戦闘により、獲得できるキャラクタが容易に判別できる。
(抽選によるキャラクタ付与)
一方、抽選付与処理とは、抽選結果に応じてユーザにモンスターを付与する処理である。図7は、ゲームシステム1における抽選付与処理の流れの一例を示すフローチャートである。図7に示す抽選付与処理は、ゲームにおいて、ユーザが任意のタイミングで、抽選を指示する入力操作を行うことにより、開始される。
ユーザ端末100の操作受付部111は、抽選を指示する入力操作を受け付ける(S200)。操作受付部111が該入力操作を受け付けると、抽選部112Bは、ユーザに付与するモンスターを、抽選により決定する(S202)。キャラクタ付与部112Cは、抽選部112Bが決定したモンスターを、ユーザに付与する(S204)。すなわち、キャラクタ付与部112Cは、ユーザ端末100のユーザ情報233に含まれている、キャラクタデータ233Aに、抽選部112Bが決定したモンスターのデータ(図3における1レコード)を追加する。最後に、ゲーム進行部112はS202における抽選結果を表示制御部115に通知し、表示制御部115は該抽選結果を示す画像を作成して、表示部152に表示させる(S206)。
なお、ユーザが抽選を実行するためには、何らかの対価が必要であってもよい。例えば、ゲーム進行部112は、ユーザが所定の抽選アイテムを所定数以上所持している場合は、S202以降の処理を実行し、ユーザが所定の抽選アイテムを所定数以上所持していない場合は、S202以降の処理を実行しないこととしてもよい。さらに、ゲーム進行部112は、S202以降の処理を行う場合は、記憶部120のユーザ情報233に記憶されている該抽選アイテムの数を、該所定数分だけ減少させてもよい。すなわち、ゲーム進行部112は、S202以降の処理を行う場合、抽選アイテムを所定数分だけ消費させてもよい。
このように、抽選により決定したキャラクタをユーザに付与することで、ユーザに、抽選を行う動機を与えることができる。さらに、抽選でユーザに付与され得る(ユーザが獲得できる)キャラクタは、操作キャラクタと関連付けることで戦闘に参加可能である。したがって、ユーザに、獲得したキャラクタを戦闘に参加させようとする、すなわち、さらに戦闘を行う動機を与えることができる。そして、該戦闘の結果に応じて、図6に示したようにキャラクタがユーザに付与される。このように、ユーザに抽選でモンスターを獲得させることで、該ユーザに操作キャラクタを操作して戦闘を行う動機も与えることができる。したがって、ユーザに継続的な目標を与え、ゲームを飽きずに継続させることができる。
〔実施形態2〕
<モンスターの成長>
ユーザ端末100のゲーム進行部112は、あるモンスターを戦闘に参加させた場合、または、あるモンスターに所定の成長アイテムが使用された場合に、該モンスターを成長させてもよい。以下、本発明の実施形態2について説明する。なお、上記実施形態にて説明した内容と同じ内容については、その説明を繰り返さない。これは、以降の実施形態でも同様である。
本実施形態に係るゲーム進行部112は、あるモンスターを戦闘に参加させた場合、該モンスターを成長させる。「モンスターを成長させる」とは、該モンスターの能力を変化させることを意味する。なお、ゲーム進行部112は、単に戦闘に参加しただけでなく、戦闘中、または戦闘終了時に所定の成長条件を満たしていた場合に、該モンスターを成長させてもよい。また、ゲーム進行部112は、モンスターだけでなく、人間キャラクタを成長させてもよい。
また、ゲーム進行部112は、あるモンスターに所定の成長アイテムが使用された場合に、該モンスターを成長させてもよい。「所定の成長アイテム」とは、ゲームにおいて所定の条件が満たされた場合に、ユーザに、または該ユーザが所有する人間キャラクタに対して付与されるアイテムである。
操作受付部111は、成長対象のモンスターを選択する入力操作を受けつける。操作受付部111が該入力操作を受け付けると、ゲーム進行部112は選択されたモンスターを成長対象のモンスターと決定する。続いて、操作受付部111は、成長アイテムの使用を指示する入力操作を受け付ける。操作受付部111が該入力操作を受け付けると、ゲーム進行部112は、キャラクタデータ233Aに含まれている、成長対象のモンスターのキャラクタデータを更新することで、該モンスターの能力を変化させる。
(モンスターの能力の例)
モンスターの能力は、例えば、モンスターの体力、攻撃力、攻撃速度、および防御力等、モンスターに設定された各種パラメータの値、または該値の限界値で示される。ゲーム進行部112は、これらのパラメータの値および限界値の少なくとも1つを増加または減少させることで、モンスターの能力を変化させてもよい。
また、モンスターの能力は、例えば、モンスターに付与されている属性、ならびに該属性の影響の強さを示すパラメータの値で示される。ゲーム進行部112は、モンスターに属性を付与する、もしくはモンスターに付与されている属性を削除することにより、該モンスターの能力を変化させてもよい。また、ゲーム進行部112は、属性に係るパラメータの値を増加または減少させることで、該モンスターの能力を変化させてもよい。
また、モンスターの能力は、例えば、該モンスターが実行可能なスキルの数、種類、および各スキルの性能で示される。スキルとは、例えばモンスターの何らかのアクションに関するアクションスキル、ならびに、常時効果を発揮するパッシブスキル等である。ゲーム進行部112は、実行可能なスキルの数および種類を増加させること、ならびに、各スキルの性能を向上させるまたは低下させることにより、該モンスターの能力を変化させてもよい。
また、モンスターが騎乗モンスターである場合、「モンスターの能力」とは、例えば、人間キャラクタが該モンスターに騎乗した場合の、モンスターの移動速度または移動可能な地形の種類等であってもよい。ゲーム進行部112は、モンスターの移動速度を速くする、または遅くすること、ならびに、移動可能な地形の種類を増加または減少させることにより、該モンスターの能力を変化させてもよい。
成長させることが可能なモンスターを戦闘または抽選によって獲得できるようにすることで、モンスターを獲得したユーザに、該モンスターを成長させるという目的および楽しみを与えることができる。したがって、ゲームシステム1は、ゲームの興趣性を向上させることができる。
また、獲得したモンスターを成長させて、成長させたモンスターを使用して、更に別のモンスターと戦闘することで、該別のモンスターの獲得を狙うことができる。このように、モンスターの獲得と、モンスターの成長という2つの目的を循環的にユーザに提示することができるため、ユーザにゲームを飽きずに継続させることができる。
<モンスターの限界突破>
戦闘処理部112Aまたは抽選部112Bにおいて、ユーザに付与済のモンスターと同じモンスターを前記ユーザに付与するモンスターとして決定した場合、キャラクタ付与部112Cは、前記モンスターを前記ユーザに付与する代わりに、該付与済のモンスターを限界突破させてもよい。「限界突破」は、成長と同様に、モンスターの能力を変化させることを意味する。
(限界突破に係る処理の流れ)
図8は、ゲームシステム1における、限界突破に係る処理の流れの一例を示すフローチャートである。図8に示す各処理は、ゲーム進行部112がモンスターをユーザに付与する処理の代わりに実行される。すなわち、図8に示す各処理は、図6に示すフローチャートのS116、または、図7に示すフローチャートのS204の処理の代わりに実行される。
戦闘処理部112Aまたは抽選部112Bが付与するモンスターを決定すると(図6のS114または図8のS202)、キャラクタ付与部112Cは、該モンスターがユーザに付与済みのモンスターであるか否かを判定する(S300)。例えば、キャラクタ付与部112Cは、は、決定されたモンスターを特定する情報(例えば、ゲーム情報232に記憶されている、該モンスターの識別コード)をキーとして用いて、キャラクタデータ233Aを検索する。キャラクタデータ233Aに、キャラクタ特定情報が示すモンスターについてのデータが含まれていた場合、キャラクタ付与部112Cは、該モンスターがユーザに付与済みのモンスターであると判定する(S300でYES)。一方、キャラクタデータ233Aに、キャラクタ特定情報が示すモンスターについてのデータが含まれていない場合、キャラクタ付与部112Cは、該モンスターがユーザに付与していない(すなわち、未付与の)モンスターであると判定する(S300でNO)。
戦闘処理部112Aまたは抽選部112Bが決定したモンスターが、ユーザに未付与のモンスターであった場合(S300でNO)、キャラクタ付与部112Cは、S114およびS204と同様に、該モンスターをユーザに付与する(S302)。
一方、戦闘処理部112Aまたは抽選部112Bが決定したモンスターが、ユーザに付与済みのモンスターであった場合(S300でYES)、キャラクタ付与部112Cは該モンスター(すなわち、付与する予定であったモンスター)をユーザに付与しない。そして、ゲーム進行部112は、該モンスターを限界突破対象のモンスターと決定する。ゲーム進行部112は、限界突破対象のモンスターを限界突破させる(S304)。具体的には、ゲーム進行部112は例えば、キャラクタデータ233Aに含まれている、限界突破対象のモンスターのキャラクタデータを更新することで、該モンスターの能力を変化させる。
以上の処理によれば、戦闘または抽選によって、ユーザに付与済みのモンスターが再度付与される状況になった場合に、同じモンスターを重複して付与する代わりに、付与済みのモンスターの能力を変化させる。
これにより、例え同じモンスターが付与される状況になった場合でも、所持しているモンスターが強化されるという利点をユーザに与えることができる。これにより、ユーザに一度獲得したモンスターを再度戦闘または抽選で獲得する動機を与えることができる。
なお、キャラクタ付与部112Cは、人間キャラクタもモンスターと同様に限界突破させてもよい。人間キャラクタを限界突破させる場合の処理も、以上で説明した、モンスターの限界突破に係る処理と同様である。
図8のS304の処理は、S116、または、S204のタイミング以外のタイミングで実行されてもよい。例えば、ゲーム進行部112は、戦闘処理部112Aまたは抽選部112Bが決定したモンスターが付与済みか否かに関わらず、一旦ユーザに付与してもよい(S302)。この場合、S300の判定処理は行われなくてよい。そして、ゲーム進行部112は、操作受付部111がユーザの、限界突破を指示する一連の入力操作を受け付けたときに、ユーザが重複して所持しているモンスターの限界突破を実行してもよい。
限界突破を指示する一連の入力操作には、限界突破対象のモンスターを指定する入力操作と、該モンスターの限界突破のために消費される消費対象のモンスターを指定する入力操作が含まれている。なお、限界突破対象のモンスターと消費対象のモンスターとは、同じまたは同種のモンスターであることが望ましい。
ゲーム進行部112は、該複数のレコードのうち、ユーザが消費対象に指定したモンスターを示すレコードを削除し、ユーザが限界突破対象に指定したモンスターを示すレコードを更新することで、該限界突破対象のモンスターの能力を変化させる。
モンスターを成長または限界突破させた場合、該モンスターの外見を変化させてもよい。成長または限界突破に合わせてモンスターの外見を変更することで、モンスターの成長段階、または限界突破の段階を一見して判別できるようにすることができる。また、モンスターの成長または限界突破させたときに外見がどのように変化するか、ユーザに期待感を持たせることができる。
例えば、モンスターを成長または限界突破させたときに、より強そうな、またはより華やかな外見に変更することが望ましい。これにより、ユーザに、モンスターを成長または限界突破させた事に対する満足感をより多く感じさせることができる。また、ユーザに、モンスターを成長または限界突破させるための動機をより強く与えることができる。
なお、人間キャラクタについても、モンスターと同様に、成長および限界突破の少なくとも一方が可能であってもよい。人間キャラクタの成長および限界突破に係る処理の流れは、本実施形態で説明した、モンスターの成長および限界突破の処理の流れと同様である。
〔実施形態3〕
本発明に係るゲームシステムは、操作キャラクタの装備品に、戦闘に参加可能な仲間キャラクタを関連付けてもよい。そして、装備品に仲間キャラクタが関連付けられた場合、仲間キャラクタを以降の戦闘に参加不可能とするとともに、前記装備品に該仲間キャラクタに応じた効果を付与してもよい。
ユーザは、人間キャラクタまたは騎乗モンスターを操作キャラクタとして操作することができる。したがって、操作キャラクタの装備品とは、例えば人間キャラクタ301の武器302、防具、およびアクセサリ、ならびに、騎乗モンスター303の武器、防具、アクセサリ等である。
ユーザは、人間キャラクタとともに、該人間キャラクタが騎乗する騎乗モンスターを戦闘に参加させることができる。また、ユーザは人間キャラクタまたは騎乗モンスターとともに、自動戦闘モンスターを戦闘に参加させることができる。したがって、仲間キャラクタとは、騎乗モンスターまたは自動戦闘モンスターである。なお、人間キャラクタをNPCとして戦闘に参加させることが可能である場合、人間キャラクタも仲間キャラクタに含まれる。
図9は、本実施形態に係るゲームシステム1に含まれる、ユーザ端末100Aおよびサーバ200の機能的構成を示すブロック図である。本実施形態に係るゲームシステム1は、実施形態1に係るゲームシステム1に対して、ユーザ端末100の代わりにユーザ端末100Aを備える点が異なる。ユーザ端末100Aは、ユーザ端末100と同様の構成に加えて、ゲーム進行部112に武器強化部112Dを含む。
武器強化部112Dは、ユーザ情報233に含まれている、装備品のパラメータを示す情報を更新することで、装備品を強化する。ここで、「装備品を強化する」とは、装備品に何らかの効果(本来、装備品には備わっていない、付加的効果)を付与することを示す。
ここで言う「効果」とは、例えば、装備品の能力の向上効果、および装備品を装備することにより使用可能なスキルの増加効果等であってよい。また、上記効果とは、装備品の外見および属性等を変化させることであってもよい。
また、武器強化部112Dは、装備品の強化に使用する仲間キャラクタの、所持する能力およびスキルの少なくとも一方に応じた効果を装備品に付与することが望ましい。これにより、使用する仲間キャラクタに応じて、装備品に多彩な効果を付与することができる。したがって、ゲームの興趣性がいっそう向上する。
(装備品強化処理の流れ)
図10は、装備品を強化する処理(装備品強化処理)の流れの一例を示すフローチャートである。なお、以下の例では、仲間キャラクタとして、モンスターが装備品強化に使用可能であることとするが、人間キャラクタを装備品の強化に用いる場合も処理の流れは同様である。
操作受付部111は、装備品の強化に使うモンスターを選択する入力操作を受け付ける(S400)。また、操作受付部111は、強化対象の装備品を選択する入力操作を受け付ける(S402)。その後、操作受付部111は、装備品の強化を指示する入力操作を受け付ける(S404)。ゲーム進行部112は、操作受付部111がS404の入力操作を受け付けた場合、S402で選択された装備品と、S400で選択されたモンスターとを関連付ける(S406)。なお、この関連付けは、モンスターに装備品を装備させるための関連付けとは区別されて管理される。ゲーム進行部112はさらに、上記関連付けたモンスター、すなわち装備品の強化に使ったモンスターを、使用不可能とする(S408)。なお、該モンスターは戦闘時のみ使用不可能(すなわち、戦闘に参加不可能)であってもよいし、常時使用不可能であってもよい。
最後に、ゲーム進行部112は、S406で関連付けられた装備品、すなわち強化対象の装備品に、強化に使うモンスターに応じた効果を付与する(S410)。例えば、ゲーム進行部112は、強化に使うモンスターの能力またはスキルに応じた効果を装備品に付与する。
なお、装備品に関連付けられる(すなわち、装備品の強化に使用される)仲間キャラクタは、実施形態2で説明したように、戦闘または所定の成長アイテムを使用することによって能力を変化させることが可能なキャラクタであることが望ましい。このようなキャラクタを装備品の強化に使用することにより、該キャラクタの成長状態に応じた効果を装備品に付与することができる。したがって、どこまでキャラクタを成長させてから、装備品の強化に用いるかをユーザに考えさせることができる。このようにユーザに戦略性をもって装備品強化を行わせることで、ゲームの興趣性をいっそう向上させることができる。
装備品に関連付けられる仲間キャラクタは、人間キャラクタまたは騎乗モンスター(副キャラクタ)等、ユーザが操作可能なキャラクタであることが望ましい。本実施形態に係るゲームでは、ユーザが一度に操作可能なキャラクタは1体(例えば、図3の状態(B)における人間キャラクタ301または騎乗モンスター303)である。また、この例に限らず、ユーザが一度に操作可能なキャラクタの数は、自ずと限られる。一度に操作可能なキャラクタが多いほど、ユーザの判断速度および判断能力が求められるからである。
したがって、ユーザの所持する人間キャラクタおよび騎乗モンスターの数が増えてきた場合、あまり使用しないキャラクタが発生する。また、すでに戦闘に強い人間キャラクタまたは騎乗モンスター等、欲しいキャラクタをユーザが所持している場合など、ユーザの、キャラクタを獲得および収集しようという動機が薄れてしまう。
上記の処理によれば、あまり使用しない人間キャラクタまたは騎乗モンスターでも、装備品の強化に使用するという役割を持たせることができる。したがって、ユーザのキャラクタ収集意欲を高めることができる。これにより、ゲームの興趣性がいっそう向上する。
さらに言えば、装備品に関連付けられる仲間キャラクタは、騎乗モンスターであることが望ましい。人間キャラクタは、例えばゲームのストーリーの進行に関わるキャラクタであったり、該ストーリーの進行に応じて獲得できる(すなわち、「仲間に加わる」)キャラクタであったりする場合がある。一方、騎乗モンスターは、操作可能なキャラクタと関連付けられることで、初めて戦闘に参加可能である。換言すると、騎乗モンスターは、それ自体で戦闘に参加することはできない。したがって、主たるキャラクタが装備品に関連付けられて戦闘に参加不可能となってしまうことを防止できる。また、人間キャラクタの装備品強化への使用を避け、騎乗モンスターを使用することとすることで、ストーリーの進行、およびユーザのストーリーの理解に支障が出ないようにすることができる。
〔実施形態4〕
本実施形態に係るゲームシステム1は、ユーザのタッチスクリーン15に対する連続した操作に応じて、操作キャラクタに連続したアクション(コンボアクションと称する)を実行させることが可能なゲームを実現してもよい。
<ユーザ端末の機能的構成>
図11は、本実施形態に係るゲームシステム1に含まれる、ユーザ端末100Bおよびサーバ200の機能的構成を示すブロック図である。本実施形態に係るゲームシステム1は、実施形態3に係るゲームシステム1に対して、ユーザ端末100Aの代わりにユーザ端末100Bを備える点が異なる。ユーザ端末100Bは、ユーザ端末100Aと同様の構成に加えて、ゲーム進行部112に編集画面生成部112E及び連続操作判定部112Fを含む。
編集画面生成部112Eは、連続する操作よりなる操作列に含まれる各操作に対して、該操作の操作列における順序に応じたアクションを関連付ける編集画面を生成する。なお、本実施形態では、1つの操作列は、連続する同種類の操作の列であるものとする。以降、操作列に含まれる各操作に対して順序に応じたアクションが関連付けられた情報を、操作列情報とも記載する。また、各操作に対して順序に応じたアクションを関連付けることを、操作列情報を編集する、とも記載する。編集画面生成部112Eの詳細については後述する。
連続操作判定部112Fは、タッチスクリーン15に対する操作が前回の操作に続いているか否かを判定する。また、連続操作判定部112Fは、前回の操作に今回の操作が続いていると判定した場合には、操作列情報を参照することにより、今回の操作に応じて操作キャラクタに実行させるアクションを決定する。連続操作判定部112Fの詳細については後述する。
(操作の種類)
操作受付部111により特定される操作の種類の詳細について説明する。本実施形態では、操作の種類として、タップ操作、上フリック操作、下フリック操作、左右フリック操作及び回転操作があるものとする。タップ操作の検出手法については、公知の手法を適用可能である。
ここでは、まず、上フリック操作、下フリック操作及び左右フリック操作の検出手法について説明する。これらの操作は、それぞれ、フリック操作の方向に基づき検出される。フリック操作自体の検出手法については、公知の手法を適用可能である。ここで、上、下、左右の各方向は、表示部152において任意に定めることが可能である。例えば、表示部152に表示されたゲーム空間においてキャラクタが向いている方向(すなわち、仮想カメラが向いている方向)を、上方向としてもよい。この場合、上方向を定めることにより、上方向の反対方向を、下方向と定めることができる。また、上方向を90度左(または右)回転させた方向を、左(または右)方向と定めることができる。
この場合、操作受付部111は、フリック操作の方向が、上方向を基準として所定角度の範囲に含まれる場合に、上フリック操作として検出する。これにより、操作キャラクタが向いている方向へのフリック操作が、上フリック操作として検出される。また、操作受付部111は、フリック操作の方向が、下方向を基準として所定角度の範囲に含まれる場合に、下フリック操作として検出する。これにより、操作キャラクタの後ろに向かう方向へのフリック操作が、下フリック操作として検出される。また、操作受付部111は、フリック操作の方向が、左(または右)方向を基準として所定角度の範囲に含まれる場合に、左右フリック操作として検出する。これにより、操作キャラクタの横方向に向かうフリック操作が、左右フリック操作として検出される。
次に、回転操作の検出手法について説明する。回転操作とは、ドラッグ操作における物体1010の接触位置(すなわち、タッチ位置)の軌跡がリング状またはほぼリング状となる操作をいうものとする。なお、回転操作の軌跡が描くリングは閉じていなくてもよい。また、回転操作におけるドラッグ操作の開始位置と終了位置とは、一致していなくてもよい。
回転操作の検出手法の一例について説明する。例えば、回転操作は、所定期間におけるドラッグ操作のベクトル成分の変化を検知することにより特定可能である。具体的には、操作受付部111は、入力部151に対する物体1010の接触を検出してから所定期間ドラッグ操作が継続していれば、その操作方向のベクトル成分の変化を検出する。操作方向のベクトル成分の変化について、図12を用いて説明する。図12は、回転操作における操作方向のベクトル成分の変化を表す模式図である。なお、ここでは、操作方向を、タッチスクリーン15の平面上に任意の直交座標系を定めたときのx軸に沿うx成分及びy軸に沿うy成分の組で表すとする。また、正のx成分を、「x軸正方向」と記載する。また、負のx成分を、「x軸負方向」と記載する。また、正のy成分を、「y軸正方向」と記載する。また、負のy成分を、「y軸負方向」と記載する。
例えば、図12(A)に示すように、所定期間中に、操作方向のベクトル成分が、(1)(x軸負方向、y軸正方向)、(2)(x軸正方向、y軸正方向)、(3)(x軸正方向、y軸負方向)、(4)(x軸負方向、y軸負方向)の順で変化したとする。この場合、操作受付部111は、回転操作を検出したと判断する。この場合の回転操作は、時計回りの操作である。また、例えば、図12(B)に示すように、所定期間中に、操作方向のベクトル成分が、(1)(x軸正方向、y軸正方向)、(2)(x軸負方向、y軸正方向)、(3)(x軸負方向、y軸負方向)、(4)(x軸正方向、y軸負方向)の順で変化したとする。この場合、操作受付部111は、回転操作を検出したと判断する。なお、この場合の回転操作は、半時計回りの操作である。このように、操作受付部111は、回転操作を表すベクトル成分の変化のパターンをあらかじめ記憶しておき、該当するパターンを検出した場合に、回転操作を検出したと判断すればよい。なお、該当する変化のパターンは、上述した例に限定されない。また、回転操作の検出手法は、上述した手法に限られず、他の手法を適用することも可能である。
(編集画面生成部112Eの詳細)
編集画面生成部112Eが生成する編集画面について説明する。編集画面は、操作列情報を編集するための画面である。なお、以下において、同種類の操作よりなる操作列の先頭からi(i=1,2,・・・・)番目の操作を、順序iの操作とも記載する。また、順序iの操作に関連付けられたアクションを、i段目のアクションとも記載する。操作列情報は、詳細を後述する連続操作判定部112Fによって操作が連続していると判定されたときに参照される。ここで、ある種類の操作に続いて他の種類の操作がある場合には、ある種類の操作列情報に続いて他の種類の操作列情報が参照される。このため、ユーザは、各種類の操作列情報の組み合わせを考慮して編集を行うことで、連続する操作により連続して繰り出されるアクションを、より変化に富んだものとすることができる。
編集画面生成部112Eは、ユーザが保有する保有キャラクタ毎に、編集画面を生成する。保有キャラクタは、ユーザによって選択されることにより操作キャラクタとなり得るキャラクタである。保有キャラクタとしては、ゲームの開始時に予めユーザに付与されているキャラクタがある。また、保有キャラクタとしては、ゲームの進行に伴い追加して付与されるキャラクタがある。例えば、保有キャラクタは、操作キャラクタが敵キャラクタとの戦闘に勝利することにより付与されてもよい。また、追加して付与される保有キャラクタは、1つ以上のキャラクタの中から抽選により決定されてもよい。また、追加して付与される保有キャラクタは、ゲームの進行に伴いユーザに付与される未開封物が開封されることにより、その内包物として出現してもよい。この場合、未開封物は、所定の条件を満たすことにより開封されてもよい。例えば、未開封物が、操作キャラクタが戦闘に勝利することにより付与されるタマゴとして表現されるとする。この場合、このようなタマゴが、仮想的なふ化装置にセットされ、所定条件が満たされるとふ化してキャラクタが出現するものとしてもよい。なお、未開封物を開封するための所定条件が満たされるまでの期間は、仮想通貨等の消費アイテムとの引き換えに短縮されるようになっていてもよい。また、所定条件を満たす代わりに、消費アイテムとの引き換えに未開封物が開封されてもよい。
編集画面の一例を図13(A)及び(B)に示す。図13(A)及び(B)において、編集画面は、操作の種類毎の操作列コンポーネント115aと、アクションアイコン115bの一覧とを含む。この例では、5種類の操作(タップ操作、上フリック操作、下フリック操作、左右フリック操作及び回転操作)のそれぞれの操作列コンポーネント115aが含まれている。ただし、編集画面に含まれる操作列コンポーネント115aの個数は、図示した個数に限定されない。また、表示し得るアクションアイコン115bの個数が、同時に表示可能な個数(図13(A)及び(B)では6つ)を超える場合には、スクロールバー115cが表示されるようになっている。スクロールバー115cに対する操作により、表示し得るアクションアイコン115bのうち、隠れていたアクションアイコン115bが表示される。
まず、操作列コンポーネント115aについて説明する。操作列コンポーネント115aは、該当する種類の連続した操作のうち、順序iの操作に関連付けられたアクションを表すスロット115ai(iは1以上N以下の自然数)を、1段目からN段目まで順に配列したコンポーネントである。なお、Nは、1以上の整数であり、当該種類の操作列に含まれ得る操作の最大数を表す。最大数Nは、当該種類の連続する操作により連続してアクションを繰り出すことが可能な連続数の上限値となる。以降、最大数Nを、最大連続数Nとも記載する。最大連続数Nは、例えば、該当する保有キャラクタの特性に応じて異なっていてもよい。また、最大連続数Nは、該当する操作の種類の特性に応じて異なっていてもよい。また、最大連続数Nは、所定の条件が満たされた場合に増加可能である。最大連続数Nを増加させる条件としては、例えば、仮想通貨等の消費アイテムとの引き換えが挙げられる。また、最大連続数Nを増加させる条件としては、例えば、その保有キャラクタがレベルアップすることが挙げられる。ただし、最大連続数Nを増加させる条件は、これらに限られない。
また、操作列コンポーネント115aに含まれるN個のスロット115aiのうち、編集可能数Mまでのスロット115aiに対して、アクションの関連付けが可能(すなわち、編集可能)である。編集可能数Mを超えるスロット115aiは、編集不可能であり、アクションの関連付けができない。編集不可能なスロット115aiは、編集不可能であることを表すよう表示される。図13(A)及び(B)の例では、カギマークが表示されたスロット115aiは、編集不可能であることを表している。また、当該種類の連続する操作により連続してアクションを繰り出すことが可能な連続数は、編集可能数Mまでとなる。ただし、編集可能数Mは、保有キャラクタが満たす条件に応じて最大連続数Nまで増加可能である。なお、編集可能数Mは、保有キャラクタにより異なっていてもよい。編集可能数Mを増加させる条件としては、例えば、仮想通貨等の消費アイテムとの引き換えが挙げられる。また、編集可能数Mを増加させる条件としては、例えば、その保有キャラクタがレベルアップすることが挙げられる。ただし、編集可能数Mを増加させる条件は、これらに限られない。
次に、アクションアイコン115bについて説明する。アクションアイコン115bは、操作列情報の各操作に対して関連付け得るアクションを表している。関連付け得るアクションの種類としては、前述のように、敵キャラクタに作用を与えるもの、操作キャラクタを移動するもの、他の保有キャラクタを召喚するもの等がある。
また、アクションアイコン115bが表すアクションには、例えば、アクションの名称、アクションの特性、アクションのパラメータ等の各種の情報が定められている。アクションアイコン115bの近傍には、このような各アクションに関する情報が併せて表示されていてもよい。図13(A)の例では、例えば、「A1」という名称のアクションの特性は「xx」であり、コストは「yy」である。また、アクションのパラメータの一例として、コストがある。コストの詳細については後述する。なお、アクションアイコン115bが表すアクションに定められる情報は、上述した情報に限定されない。また、アクションアイコン115bの近傍に表示される情報は、これらの情報に限定されない。なお、図13(A)の例では、アクションアイコン115bは、対応するアクションの名称を含むアイコンとして表示されているが、アクションアイコン115bの表示形態は、これに限られない。例えば、アクションアイコン115bは、対応するアクションを表すデザインのアイコンとして表示されていてもよい。
次に、アクションアイコン115bの一覧について説明する。アクションアイコン115bの一覧は、スロット115aiに対応する操作に関連付けが可能なアクションの一覧を表す。関連付けが可能なアクションは、該当する保有キャラクタによって取得済みのアクションを含む。さらに、関連付けが可能なアクションは、該当する保有キャラクタと同種別の他の保有キャラクタによって取得済みのアクションを含んでいてもよい。
なお、保有キャラクタは、条件を満たすことにより新たなアクションを取得するようになっていてもよい。新たなアクションを取得する条件とは、例えば、該当する保有キャラクタの操作キャラクタとしてのプレイ期間が閾値を超えることであってもよい。これは、ゲームの進行に伴い操作キャラクタが新たな技を閃いたことを表現している。また、アクションを取得する条件とは、例えば、操作キャラクタが所定のアイテムを取得することであってもよい。これは、操作キャラクタが所定のアイテムを用いて新たな技を覚えることを表現している。
また、アクションアイコン115bの一覧は、編集対象のスロット115aiに対応する操作の種類に応じた特性を有するアクションの一覧を表す。例えば、タップ操作に応じた特性とは、ホーミング性能が高いことであってもよい。また、例えば、上フリック操作または下フリック操作に応じた特性とは、攻撃力が高いことであってもよい。また、例えば、左右フリックに応じた特性とは、攻撃範囲が広いことであってもよい。また、関連付け得るアクションの特性を、操作の種類に応じて変化させてもよい。例えば、上、下または左右フリック操作に比べて、タップ操作に関連付け得るアクションのホーミング性能を高くし、回転操作に関連付け得るアクションのホーミング性能を低くしてもよい。また、例えば、上または下フリック操作に比べて、左右フリック操作に関連付け得るアクションのホーミング性能を高くしてもよい。
例えば、図13(A)では、タップ操作の操作列コンポーネント115aに含まれる何れかのスロット115aiがタップされたことにより、タップ操作に応じた特性を有するアクションA1〜A6を表すアクションアイコン115bの一覧が表示されている。また、図13(B)では、上フリック操作の操作列コンポーネント115aに含まれる何れかのスロット115aiがタップされたことにより、上フリック操作に応じた特性を有するアクションB1〜B6を表すアクションアイコン115bの一覧が表示されている。
次に、編集画面における操作列情報の編集方法の一例について説明する。編集可能なスロット115aiには、アクションアイコン115bを嵌め込むことが可能となっている。嵌め込まれたアクションアイコン115bが表すアクションは、スロット115aiの順序の操作に関連付けられる。スロット115aiにアクションアイコン115bを嵌め込むための操作は、例えば、ドラッグ操作であってもよい。また、嵌め込むための操作は、スロット115ai及びアクションアイコン115bをこの順または逆順にタップ操作することであってもよい。ただし、嵌め込むための操作は、これらの操作に限定されない。
また、スロット115aiに嵌め込まれたアクションアイコン115bは、所定の操作によりクリアされ、空きスロットとなることが可能である。クリアのための操作は、例えば、既に嵌め込まれたアクションアイコン115bが、スロット115aiの枠外にドラッグ操作されることであってもよい。ただし、クリアのための操作は、このような操作に限定されない。また、編集画面において、各種類の操作列コンポーネント115aにおける各スロット115aiを空きスロットとする「オールクリア」の機能が提供されていてもよい。この場合、編集画面は、オールクリアを指示する操作ボタン(図示せず)を含む。
なお、スロット115aiは、該当する順序のアクションが関連付けられていない場合には、空きスロットであることを表すよう表示される。図13(A)及び(B)の例では、斜線で塗りつぶされたスロット115aiは、空きスロットである。
例えば、図13(A)において、タップ操作に関する操作列コンポーネント115aを参照すると、5つのスロット115aiが配列されている。すなわち、最大連続数Nは5である。また、スロット115a1〜115a4までが編集可能であり、そのうち、スロット115a2〜115a4は空きスロットである。また、スロット115a5は、編集不可能となっている。すなわち、編集可能数Mは4である。換言すると、この例では、この保有キャラクタについては、タップ操作の最大連続数5のうち編集可能数の4段目まで、連続したアクションを実行させることが可能となっている。
また、各操作列情報において各操作に対して関連付けられたアクションのコストの総和は、コストの上限値を超えないよう定められている。例えば、各種類の操作列コンポーネント115aにおける各スロット115aiに嵌め込まれたアクションアイコン115bのコストの総和が上限値を超えているか否かは、操作列情報の編集を終了する際に判断される。例えば、編集画面生成部112Eは、編集終了を指示する操作が行われた際に、コストの総和が上限値を超えていなければ、編集内容を反映した操作列情報を、ユーザ情報133として記憶部120に保存する。もし、コストの総和が上限値を超えていれば、編集画面生成部112Eは、操作列情報を保存しない。この場合、編集画面生成部112Eは、コストの総和が上限値を超えていることを表示した上で、編集画面の表示を継続してもよい。
(連続操作判定部112Fの詳細)
連続操作判定部112Fの詳細について説明する。連続操作判定部112Fは、前述したように、ある操作が、前回の操作に連続しているか否かを判定する。前回の操作に続いているとは、今回の操作が、前回の操作に基づく操作キャラクタの一連のモーションが開始してから一定期間内に行われたことをいう。ここで、前回の操作に基づく操作キャラクタの一連のモーションが開始してからの一定期間内として、例えば、前回の操作に基づいて操作キャラクタが攻撃のための準備モーションを行っている期間としてもよいし、戻りモーションを終えるまでの間としてもよいし、戻りモーションを終えてからも所定の時間内において操作を受け付けることとしてもよい。例えば、ある操作が、前回の操作に基づく操作キャラクタの一連のモーションが終わる前に行われたこととしてもよい。
すなわち、連続操作判定部112Fは、今回の操作が、前回の操作に基づく操作キャラクタの一連のモーションが開始してから一定期間内に行われたか否かを判断すればよい。例えば、ある操作が、前回の操作に基づく操作キャラクタの攻撃前の準備モーションを表すアニメーションが行われている間に行われた場合に、連続操作判定部112Fは、ある操作が、前回の操作に連続していると判定してもよい。また、ある操作が、前回の操作に基づく操作キャラクタの戻りモーションが終わってから一定期間が経過するまでの間に行われた場合に、連続操作判定部112Fは、ある操作が、前回の操作に連続していると判定してもよい。
また、連続操作判定部112Fは、連続していると判定したときに、前回及び今回の操作の種類に応じた操作列情報を参照して、実行すべきアクションを決定する。連続操作判定部112Fは、決定したアクションを、ゲーム進行部112に通知する。
具体的に、まず、前回及び今回の操作の種類が同一であった場合について説明する。この場合、連続操作判定部112Fは、今回の操作が、当該種類の操作の何番目であるか(すなわち、順序i)をカウントする。順序iのカウントは、連続していると判定する度に、操作の種類を履歴として記憶しておくことで算出可能である。なお、連続操作判定部112Fは、操作の種類の履歴を、連続していないと判定した時点でクリアしてもよい。そして、連続操作判定部112Fは、今回の操作の種類に関する操作列情報を参照し、今回の順序iの操作に関連付けられたアクションを、次に実行すべきアクションとして決定する。なお、今回の順序iが、操作列情報における編集可能数Mを超えている場合について説明する。この場合、本実施形態では、連続操作判定部112Fは、これ以上連続した操作は不可能であるとして、次に実行すべきアクションを決定しないものとする。すなわち、同じ種類の操作は、連続数が編集可能数Mを超えた時点以降、当該操作が前回の操作に連続していないと判定されるまで、無効となる。これにより、本実施形態は、ユーザに対して、できるだけ複数の種類の操作列をつなげた操作を行うよう促すことができる。
ただし、連続数が編集可能数Mを超えている場合の処理は、上述したような操作を無効とする処理に限られない。例えば、この場合、連続操作判定部112Fは、順序を1にリセットして、操作列情報の1段目のアクションを、次に実行すべきアクションとして決定してもよい。この場合、ユーザは、同種類の操作を連続して行うと、連続数に上限なく、連続数の分だけ、次々と連続してアクションを繰り出すことが可能となる。
次に、前回及び今回の操作の種類が同一でなかった場合について説明する。この場合、連続操作判定部112Fは、今回の操作の種類の関する操作列情報を参照し、順序iの操作に関連付けられた1段目のアクションを、次に実行すべきアクションとして決定する。
ゲーム進行部112は、連続操作判定部112Fによって決定されたアクションが通知されると、前回の操作に基づくアクションに続いて今回の操作に基づくアクションを操作キャラクタに実行させるよう、他の各部に通知する。
例えば、前回の操作に基づくアクション及び今回の操作に基づくアクションが共に敵キャラクタに作用を与えるアクションである場合について例示的に説明する。敵キャラクタに作用を与えるアクションが、前述のように、準備モーションと、攻撃モーションと、戻りモーションとを含んでいたとする。このとき、今回の操作が、前回の操作に基づく技モーションの表示期間中であるとする。この場合、今回の操作に基づくアクションを操作キャラクタに開始させるタイミングとして、次の2つのパターンが考えられる。
1つ目のパターンでは、ゲーム進行部112は、操作キャラクタに、前回の操作による技モーションを終了させた後、続く戻りモーションをキャンセルして、今回の操作による準備モーションを開始させる。2つ目のパターンでは、ゲーム進行部112は、操作キャラクタに、前回の操作による技モーションをキャンセルさせ、直ちに今回の操作による準備モーションを開始させる。いずれの場合であっても、ゲーム進行部112は、操作キャラクタに、連続した操作に応じて、操作列情報に基づき決定したアクションを連続して実行させることができる。
<ゲームシステム1の処理の態様例>
次に、ゲームシステム1の処理の態様例として、操作列情報の編集処理と、連続する操作に応じた処理とについて、図面を参照して説明する。
(操作列情報の編集処理の流れ)
まず、操作列情報の編集処理について、図14を参照して説明する。図14は、操作列情報の編集処理の流れを示すフローチャートである。なお、以下の動作の開始時に、表示部152には、既にゲーム画面が表示されているものとする。また、表示されているゲーム画面には、操作列情報の編集開始を指示するためのメニューまたは操作ボタン等が含まれているものとする。また、以下の説明において、編集画面生成部112Eの処理結果を表示制御部115によって表示することを、単に、編集画面生成部112Eによって表示する、とも記載する。
ステップS501において、操作受付部111は、ある保有キャラクタについて、操作列情報の編集開始を指示する操作を受け付けたか否かを判断する。対象となる保有キャラクタは、この時点で選択されている操作キャラクタであってもよいし、その他の保有キャラクタであってもよい。編集開始を指示する操作が受け付けられた場合、次のステップS502が実行される。
ステップS502において、編集画面生成部112Eは、その保有キャラクタに関する操作列情報を記憶部120から読み込む。このとき読み込まれる操作列情報は、既に編集されて保存されている操作列情報、または、初期状態の操作列情報である。初期状態の操作列情報では、各操作に対して予め定められたアクションが関連付けられているものとする。
ステップS503において、編集画面生成部112Eは、この保有キャラクタの操作列情報に基づいて、編集画面を表示する。
ステップS504において、操作受付部111は、スロット115aiの1つに対する操作を受け付ける。例えば、スロット115aiに対するタップ操作、または、ドラッグ操作が受け付けられてもよい。以下、操作が受け付けられたスロット115aiを、操作対象のスロット115aiとも記載する。
ステップS505において、編集画面生成部112Eは、操作が受け付けられたスロット115aiの状態によって、処理を分岐する。
具体的には、ステップS505において、操作対象のスロット115aiが編集不可能であった場合について説明する。この場合、ステップS506において、編集画面生成部112Eは、該当するスロット115aiは編集不可能であるという通知を表示する。
また、ステップS505において、操作対象のスロット115aiに既にアクションアイコン115bが嵌め込まれていた場合について説明する。この場合、ステップS504で受け付けられた操作が、当該スロット115aiに対するクリアを指示する操作であったとする(ステップS507でYes)。この場合、ステップS508において、編集画面生成部112Eは、該当するスロット115aiからアクションアイコン115bをクリアし、空きスロットとして表示する。
また、ステップS505において、操作対象のスロット115aiが空きスロットであった場合について説明する。この場合、ステップS509において、編集画面生成部112Eは、当該スロット115aiに応じたアクションアイコン115bの一覧を表示する。一覧に含まれるアクションアイコン115bは、対応する保有キャラクタ及び同種別の他の保有キャラクタが取得済みのアクションのうち、当該スロット115aiに対応する操作の種類に応じた特性を有するアクションを表す。
ステップS510において、操作受付部111は、アクションアイコン115bの一覧の何れか1つを、スロット115aiまでドラッグする操作を受け付ける。ドラッグ先として有効なスロット115aiは、ステップS504で操作された操作対象のスロット115aiと同一の操作列コンポーネント115aに含まれる何れかのスロット115aiであるものとする。
ステップS511において、編集画面生成部112Eは、ドラッグ操作されたアクションアイコン115bを、ドラッグ先のスロット115aiに嵌め込んだ画像を表示する。
ステップS512において、編集終了を指示する操作が受け付けられていなければ、編集画面生成部112Eは、ステップS504からの動作を繰り返す。
ステップS512において、編集終了を指示する操作が受け付けられた場合について説明する。この場合、ステップS513において、編集画面生成部112Eは、コストの総和が上限値を超えるか否かを判断する。具体的には、編集画面生成部112Eは、各種類の操作列コンポーネント115aに含まれる各スロット115aiに嵌め込まれたアクションアイコン115bのコストの合計を算出し、算出した値が上限値を超えるか否かを判断すればよい。
ステップS513において、コストの総和が上限値を超える場合、編集画面生成部112Eは、その旨を表す通知を表示する。そして、編集画面生成部112Eは、ステップS504からの動作を繰り返す。
ステップS513において、コストの総和が上限値以下である場合について説明する。この場合、ステップS514において、編集画面生成部112Eは、各操作列コンポーネント115aにおける編集内容を反映させた操作列情報を、記憶部120に保存する。
ステップS515において、表示制御部115は、編集画面を閉じてゲーム画面を表示する。
(編集画面例)
次に、編集画面の一例について説明する。図15(A)(B)(C)は、編集画面の一例を表す図である。
図15(A)に示す編集画面は、ある保有キャラクタについて、操作列情報の編集開始が指示されたときに表示される(ステップS503)。この編集画面は、操作の各種類の操作列コンポーネント115aを含む。例えば、タップ操作の操作列コンポーネント115aにおいて、スロット115a1〜115a4には、アクションA3、A6、A1、A5を表すアクションアイコン115bが嵌め込まれている。また、スロット115a5は、編集不可能であることを表すよう、カギマークが表示されている。
図15(B)に示す編集画面は、図15(A)の編集画面において、タップ操作の操作列コンポーネント115aに含まれるスロット115a2が枠外にドラッグ操作されたときに表示されたものである(ステップS504、S505で「アクション有り」、S507でYes、S508)。すなわち、この操作により、タップ操作のスロット115a2は、空きスロットとなる。また、空きスロットとなったスロット115a2が選択されているため、タップ操作に応じたアクションアイコン115bの一覧が追加して表示されている(ステップS505で「空きスロット」、S509)。
図15(C)に示す編集画面は、図15(B)に示す編集画面において、アクションA4を表すアクションアイコン115bが、タップ操作のスロット115a2までドラッグされた場合に表示される。すなわち、このドラッグ操作により、アクションA4を表すアクションアイコン115bが、タップ操作のスロット115a2に嵌め込まれている(ステップS510、S511)。
この状態で編集終了すると、各種類の操作列情報は、次のように保存される。すなわち、タップ操作の操作列情報において、1段目〜4段目の操作に対して、アクションA3、A4、A1、A5が関連付けられる。左右フリックの操作列情報において、1段目の操作に対して、アクションC3が関連付けられる。下フリックの操作列情報においては、アクションが関連付けられない。回転操作の操作列情報において、1段目の操作に対してアクションE3が関連付けられる。
(連続する操作に応じた処理)
次に、タッチスクリーン15に対して連続する操作に応じた処理について、図16を参照して説明する。図16は、連続する操作に応じた処理の流れを示すフローチャートである。
ステップS601において、操作受付部111がゲームを開始する操作を受け付けると、ゲーム進行部112は、ゲームを開始する。
ステップS602において、ゲーム進行部112は、サーバ200から取得した各種ゲーム情報に基づいて、操作キャラクタが存在するゲーム空間を表すゲーム画面を生成する。そして、表示制御部115は、生成されたゲーム画面をタッチスクリーン15に表示する。
ステップS603において、操作受付部111は、操作キャラクタについての操作列情報を記憶部120から読み込む。
ステップS604において、操作受付部111が、タッチスクリーン15に対する操作を受け付けると、ステップS605において、連続操作判定部112Fは、受け付けられた今回の操作が、前回の操作に連続しているか否かを判断する。
具体的には、連続操作判定部112Fは、今回の操作が、前回の操作に基づく操作キャラクタのアクションを表すモーションの終了前に受け付けられていた場合に、連続していると判断する。それ以外の場合、連続操作判定部112Fは、連続していないと判断する。なお、連続しているか否かの判断基準としては、これに限らず、他の基準も採用可能である。
ステップS605において、今回の操作が前回の操作に連続していないと判断した場合について説明する。この場合、ステップS606において、連続操作判定部112Fは、この操作キャラクタの操作列情報のうち、今回の操作の種類に関する操作列情報を参照する。そして、連続操作判定部112Fは、操作列情報の先頭の操作に関連付けられたアクションを、実行すべきアクションとして決定する。
一方、ステップS605において、今回の操作が前回の操作に連続していると判断した場合について説明する。この場合、ステップS607において、連続操作判定部112Fは、今回の操作の種類と、前回の操作の種類とが、同一であるか否かを判断する。
ステップS607において、同一の種類でないと判断した場合、ステップS606が実行される。これにより、今回の種類の操作列情報において先頭の操作に関連付けられたアクションが、実行すべきアクションとして決定される。
ステップS607において、同一の種類であると判断した場合、ステップS608が実行される。
ステップS608において、連続操作判定部112Fは、今回の操作が、この種類の操作の何段目であるか(すなわち、順序)を特定する。
ステップS609において、連続操作判定部112Fは、ステップS608で特定した順序が、この種類の操作の編集可能数M以下であるか否かを判断する。
ステップS609において、操作の順序が編集可能数Mを超えている場合、実行すべきアクションが決定されることなく、ステップS604からの操作が繰り返される。すなわち、編集可能数Mを超えて連続する同種の操作は、前回の操作に連続していないと判定されるまで、無効となる。
ステップS609において、操作の順序が編集可能数M以下である場合について説明する。この場合、ステップS610において、連続操作判定部112Fは、今回の種類の操作列情報において、ステップS608で特定した順序の操作に関連付けられたアクションを、実行すべきアクションとして決定する。
ステップS611において、ゲーム進行部112は、操作キャラクタに、決定されたアクションを実行させるよう、各部に通知する。具体的には、オブジェクト制御部114は、操作キャラクタが、決定されたアクションのモーションを行うアニメーションを生成する。また、表示制御部115は、生成されたアニメーションを表示する。なお、ゲーム進行部112は、操作キャラクタが実行中の前回のアクションに基づく表示を途中で取りやめて、今回決定されたアクションに基づく表示を行うよう各部を制御する。このとき、この時点で表示されているモーションが前回のアクションの戻りモーションであれば、ゲーム進行部112は、戻りモーションの表示を直ちにキャンセルして今回のアクションのモーションを表示するよう制御する。また、この時点で表示されているモーションが前回のアクションの攻撃モーションであれば、ゲーム進行部112は、攻撃モーションの表示が終了するまで待機してから戻りモーションの表示をキャンセルして今回のアクションのモーションを表示するよう制御してもよい。あるいは、この場合、ゲーム進行部112は、攻撃モーションの表示をキャンセルして今回のアクションのモーションを表示するよう制御してもよい。
そして、制御部110は、ステップS604からの動作を繰り返す。
以上で、連続する操作に応じた処理の説明を終了する。
例えば、図15(C)に例示した編集画面により操作列情報が保存されているとする。この場合に、例えば、タップ操作、タップ操作、左右フリック操作の順に連続して操作が受け付けられたとする。すると、1段目のタップ操作に関連付けられたアクションA3、2段目のタップ操作に関連付けられたアクションA4、1段目の左右フリック操作に関連付けられたアクションC3、の順にアクションが繰り出されることになる。また、タップ操作が連続して5回以上受け付けられたとする。この場合、タップ操作の操作列情報において、4段目までしかアクションが関連付けられていない。すなわち、編集可能数M=4である。したがって、この場合、アクションA3、A4、A1、A5の順に4段目までアクションが繰り出される。その後、4段目のアクションA5が敵キャラクタを攻撃するアクションであるとすると、5回目以降の連続するタップ操作は、アクションA5の戻りモーションが終了するまで、無効となる。
<本実施形態の効果>
このように、本実施形態では、操作の種類毎に操作列情報を編集可能とし、連続した操作を受け付けた場合には、編集された操作列情報にしたがって決定したアクションを操作キャラクタに実行させる。このため、本実施形態は、連続する操作に応じたゲーム展開を、ユーザが試行錯誤しながら変化させることができる。これにより、ユーザは、連続した操作に応じて多様なゲーム展開を楽しむことができ、興趣性がより高まる。
また、本実施形態では、保有キャラクタ毎の編集画面において、操作列に含まれる各操作に対して関連付け可能なアクションは、当該保有キャラクタによって取得済みのアクションまたは同種別の他の保有キャラクタによって取得済みのアクションである。このため、本実施形態は、その保有キャラクタの世界観またはその種別の世界観にあったアクションを、当該保有キャラクタに行わせることができる。
また、本実施形態では、保有キャラクタ毎の編集画面において、操作列に含まれる各操作に対して関連付け可能なアクションは、保有キャラクタが満たす条件に応じて追加される。また、操作列において編集可能な操作数は、保有キャラクタが満たす条件に応じて増加する。このため、本実施形態は、ゲームプレイをすればするほど、保有キャラクタに関する操作列情報をより有利に編集して、保有キャラクタを強くすることができる。
〔変形例1:お勧め操作列情報の自動設定〕
本実施形態では、編集画面生成部112Eが生成する編集画面は、操作列情報を編集する機能を含むものとして説明した。さらに、編集画面は、お勧め操作列情報を自動設定する機能を含んでいてもよい。お勧め操作列情報とは、操作列に含まれる各操作に対して、予め推奨されるアクションを関連付けた操作列情報である。例えば、編集画面は、お勧め操作列情報の自動設定を指示する操作に応じて、お勧め操作列情報に基づいて、操作列に含まれる各操作に対して推奨されるアクションを一括して関連付ける。具体的には、操作列コンポーネント115aのスロット115aiに、お勧め操作列情報にしたがったアクションアイコン115bが一括して自動で嵌め込まれてもよい。
また、編集画面は、複数のお勧め操作列情報の何れかを選択させて自動設定を行う機能を含んでいてもよい。具体的には、複数のお勧め操作列情報は、それぞれ異なる特性を有するよう構成されていてもよい。この場合、ユーザは、特性を考慮してお勧め操作列情報を選択可能である。
図17は、オススメ操作列情報の自動設定を行う編集画面の一例である。図17(A)の編集画面は、「オススメ」ボタン115dを含む。「オススメ」ボタン115dは、お勧め操作列情報の自動設定を指示する操作を受け付けるボタンである。
図17(B)は、図17(A)の編集画面において、「オススメ」ボタン115dが操作されると表示されるお勧め操作列情報の選択画面の一例である。この例では、「オススメ1」のお勧め操作列情報は、最後の決め技の威力を重視した構成となっている。また、「オススメ2」のお勧め操作列情報は、連続して繰り出されるアクションの間に隙が生じないことに重点を置いた構成となっている。
図17(C)は、図17(B)の編集画面において、「オススメ1」が選択されて自動設定が行われた編集画面の一例である。この例では、「オススメ1」における各種類の操作列情報にしたがって、該当するアクションアイコン115bが、該当するスロット115aiに、自動的に嵌め込まれている。
また、編集画面は、自動設定されるお勧め操作列情報に応じて、推奨される連続操作のお勧めパターンを提示する機能をさらに含んでいてもよい。連続操作のお勧めパターン
とは、例えば、「タップ、タップ、タップ、上フリック」等といったように、連続する操作として推奨される操作の種類及び順序を表す情報である。ユーザは、お勧め操作列情報を自動設定した上で、お勧めパターンの連続操作を行うことにより、例えば、最後の決め技まで連続して繰り出すアクションを効果的につなげることができ、より興趣性が向上する。
また、編集画面は、お勧め操作列情報の構成をさらに強化可能な未取得のアクションがあれば、当該アクションを保有キャラクタに取得させる条件を提示する機能をさらに含んでいてもよい。取得する条件とは、例えば、ゲーム空間内で所定のイベントに参加して所定のミッションをクリアすることであってもよいが、これに限られない。また、編集画面は、ユーザが新たに獲得したアクションがある場合に、当該アクションを含めるように、連続操作のお勧めパターンを提示する機能を有してもよい。例えば、ユーザが新たに獲得したアクションがあり、当該アクションが操作列情報に関連付けられたことがないことを想定する。この場合に、編集画面において、当該アクションを含む連続操作のお勧めパターンが提示されてもよい。
本変形例では、ユーザは、お勧め操作列情報を利用することにより、お勧めの操作列情報に基づくゲーム展開を手軽に楽しむことができる。また、ユーザは、そのようなお勧め操作列情報を設定した場合に有効な連続する操作のパターンを、容易に習得することができる。また、そのようなお勧め操作列情報の設定に必要なアクションを取得するために、ゲームをプレイすることに対するユーザの動機付けが強化される。
〔変形例2:操作列情報の共有〕
本実施形態では、操作列情報は、ユーザ毎に編集されるものとして説明した。さらに、編集画面生成部112Eが生成する編集画面は、他のユーザによって編集された操作列情報に基づいて自動設定を行う機能を含むよう変形可能である。例えば、編集画面は、当該ユーザが編集した任意の保有キャラクタの操作列情報を、他のユーザに対して公開する機能を有していてもよい。また、例えば、編集画面は、当該ユーザが編集する任意の保有キャラクタの編集画面において、他のユーザによって公開されている操作列情報を取得して自動設定する機能を有していてもよい。このとき、例えば、操作列情報を公開する機能は、操作列情報とともにユーザのコメントを公開する機能を含んでいてもよい。また、この場合、他のユーザの操作列情報を自動設定する機能は、1つ以上の他のユーザの操作列情報とともに公開されたコメントをユーザに提示した上で、自動設定する操作列情報を選択させる機能を含んでいてもよい。
図18は、このように変形した場合の編集画面の一例である。図18(A)に示す編集画面は、公開ボタン115eと、取得ボタン115fを含む。公開ボタン115eが操作されると、編集画面生成部112Eは、編集された操作列情報を、公開対象として、サーバ200に送信する。
図18(B)は、図18(A)の編集画面において、取得ボタン115fが操作された場合に表示される選択画面の一例である。編集画面生成部112Eは、取得ボタン115fに対する操作に応じて、サーバ200から、公開された操作列情報の一覧を取得して、選択可能に表示する。この例では、ユーザ1によって公開された操作列情報1と、ユーザ2によって公開された操作列情報2とが、選択可能に表示されている。この場合、一覧から何れかの操作列情報が選択されると、編集画面生成部112Eは、公開された操作列情報の一覧から選択された操作列情報に基づいて、該当するアクションアイコン115bを該当するスロット115aiに自動設定すればよい。
本変形例では、ユーザは、他のユーザとの間で操作列情報を共有することにより、他のユーザにより設定された操作列情報に基づくゲーム展開を楽しむことができる。
〔変形例3〕
本実施形態では、操作列は、同種の操作よりなるものとして説明した。これに限らず、本実施形態は、操作列が、1つ以上の種類の操作からなるよう変形することが可能である。図19は、本変形例における編集画面の一例である。図19に示すように、編集画面は、1つ以上の操作列コンポーネント315aを含む。各操作列コンポーネント315aは、スロット315aiを含む。また、編集画面の下部には、アクションアイコン315bの一覧が表示される。アクションアイコン315bは、上述したアクションアイコン115bに対して、アクションの名称に加えて、関連付け可能な操作の種類(例えば、タップ)が表示されている点が異なる。その他の点については、アクションアイコン115bと同様に構成されるため、詳細な説明を繰り返さない。また、操作列コンポーネント315aは、上述した操作列コンポーネント115aに対して、含まれる各スロット315aiに嵌め込み可能なアクションアイコン315bが異なる操作の種類に対応するものであってもよい点が異なる。その他の点については、操作列コンポーネント115a同様に構成されるため、詳細な説明を繰り返さない。
この場合、操作列コンポーネント315aの編集内容を反映して保存される操作列情報は、1〜N段目までの操作について、操作の種類及びアクションの組を関連付けた情報となる。このような操作列情報を用いる場合、連続操作判定部112Fは、図16に示した処理において、ステップS607の処理をスキップする。また、ステップS610において、今回の操作の種類に関する操作列情報を参照する代わりに、それまでに受け付けられた操作の種類の順序に対応する操作列情報を参照すればよい。
〔実施形態5〕
上述した各実施形態では、ゲームシステム1が実現するゲームの一例として、ユーザが、自分の所持しているキャラクタのうち、操作可能なキャラクタの中から1体のキャラクタを選んで、該キャラクタを操作する例について説明した。本実施形態では、複数のキャラクタによってデッキが編成され、デッキに含まれる各キャラクタがユーザによって操作され得る例について説明する。
本実施形態に係るゲームシステム1に係るゲームには、デッキを用いて進行するプレイパートが含まれる。プレイパートでは、デッキに含まれる各キャラクタが、仮想的なゲーム空間においてユーザ操作に応じて動作する。また、プレイパートでは、デッキに含まれる各キャラクタが、ゲーム空間において遭遇する敵キャラクタとの戦闘を行う。
<ユーザ端末の機能的構成>
図20は、本実施形態に係るゲームシステム1に含まれる、ユーザ端末100Cおよびサーバ200の機能的構成を示すブロック図である。本実施形態に係るゲームシステム1は、実施形態4に係るゲームシステム1に対して、ユーザ端末100Bの代わりにユーザ端末100Cを備える点が異なる。ユーザ端末100Cは、ユーザ端末100Bと同様の構成に加えて、ゲーム進行部112にデッキ編成部112Gを含む。
(デッキ編成部の詳細)
デッキ編成部112Gは、ゲームにおいて利用可能なキャラクタのうち、第1キャラクタ、第2キャラクタ及び第3キャラクタをそれぞれ含む複数のデッキを編成する。
ここでは、第1キャラクタの一例として、人間キャラクタを適用する。
また、第2キャラクタとは、第1キャラクタの乗り物となるキャラクタである。第1キャラクタの乗り物とは、仮想的なゲーム空間において第1キャラクタを乗せて移動するものをいう。例えば、第2キャラクタは、動物、電車、汽車、自動車、自転車、バイク、絨毯、箒等を表す各種のキャラクタであってもよいが、これらに限られない。ここでは、第2キャラクタの一例として、騎乗モンスターを適用する。
また、第3キャラクタとは、第1キャラクタを支援するキャラクタである。第1キャラクタの支援とは、第1キャラクタを用いたプレイパートの進行をより有利にすることをいう。例えば、第3キャラクタは、第1キャラクタと共に敵キャラクタとの戦闘を行うキャラクタであってもよいが、これに限られない。ここでは、第3キャラクタとして、自動戦闘モンスターを適用する。
なお、1つのデッキに含まれる人間キャラクタ、騎乗モンスター、及び、自動戦闘モンスターの数は、それぞれ、1つであってもよいし、複数であってもよい。本実施形態では、1つのデッキには、1つずつの人間キャラクタ及び騎乗モンスターと、複数の自動戦闘モンスターとが含まれるものとする。
また、デッキを編成するとは、ゲームにおいて利用可能な人間キャラクタ、騎乗モンスター及び自動戦闘モンスターの中から、デッキに含めるものを選択することをいう。デッキ編成部112Gは、複数のデッキの各々に含めるキャラクタの選択を、ユーザの操作に基づいて行う。ユーザの操作は、デッキに含めるキャラクタを指定する操作であってもよいし、自動での選択を指示する操作であってもよい。自動での選択は、ゲームにおいて利用可能なキャラクタの中からランダムに実行されてもよいし、所定の規則に基づいて実行されてもよい。
また、デッキ編成部112Gは、複数のデッキの各々に含める人間キャラクタ、騎乗モンスター及び自動戦闘モンスターの少なくとも何れかとして、ユーザに付与されたキャラクタの何れかを適用する。
ここでは、実施形態1に記載した通り、キャラクタ付与部112Cによって、戦闘処理部112Aの処理の結果、または抽選部112Bの抽選の結果、付与すると決定されたキャラクタが、ユーザに付与される。また、ゲームにおける各種の条件が満たされた場合に、キャラクタ付与部112Cによって、キャラクタがユーザに付与されてもよい。各種の条件は、戦闘処理部112Aの処理の結果によらない条件、抽選部112Bの抽選の結果によらない条件を含んでいてもよい。例えば、所定の日時に、新たなキャラクタがユーザに付与されてもよい。また、ゲームの進行状況が所定条件を満たした場合に、新たなキャラクタがユーザに付与されてもよい。また、あらかじめ付与されているキャラクタがあってもよい。
本実施形態では、騎乗モンスター及び自動戦闘モンスターは、戦闘処理部112Aの処理の結果、または抽選部112Bの抽選の結果によって少なくとも付与されるものとする。また、人間キャラクタは、戦闘処理部112Aの処理の結果によらず、抽選部112Bの抽選の結果によらずに(例えば、プレイパートの進行に伴い)、付与されるものとする。
また、デッキ編成部112Gは、複数のデッキの各々に含める人間キャラクタ、騎乗モンスター及び自動戦闘モンスターとして、装備品に関連付けられていないキャラクタをそれぞれ適用する。つまり、デッキに含めることができるキャラクタは、ユーザに付与されたキャラクタのうち、実施形態3で説明した装備品強化に使用されていないキャラクタである。
このように、装備品に関連付けたキャラクタをデッキに含めることができないことにより、装備品に関連付けるキャラクタの選択をユーザに考えさせることができ、ゲームの戦略性を向上させる。
(ゲーム進行部の詳細)
ゲーム進行部112は、実施形態1〜4に記載した構成に加えて、次のように構成される。
ゲーム進行部112は、複数のデッキのうち何れかを使用して、ユーザの操作に応じて、当該デッキに含まれる、人間キャラクタを乗せた騎乗モンスターと、自動戦闘モンスターとの少なくとも何れかを動作させることによりプレイパートを進行させる。
具体的には、ゲーム進行部112は、ユーザの操作に応じて、人間キャラクタを乗せた騎乗モンスターを、ゲーム空間内で動作させる。騎乗モンスターが、人間キャラクタの代わりに騎乗モンスターを戦闘に参加させることが可能であること、入力操作に基づくアクションは騎乗モンスターが行うこと等については、実施形態1で説明した通りである。
また、ゲーム進行部112は、ユーザの操作によらずに、自動戦闘モンスターを敵キャラクタと戦闘させる。なお、前述の各実施形態では、自動戦闘モンスターは、ユーザが操作不可能なキャラクタの一種であるものとして説明した。本実施形態では、自動戦闘モンスターは、ユーザによる操作も可能である。本実施形態における自動戦闘モンスターは、ユーザの操作によらずに自動的に戦闘に参加して各種のアクションを行うことに加えて、ユーザの操作に応じた動作を行う場合もある。
例えば、ゲーム進行部112は、タッチスクリーン15に対するユーザの操作を受け付けると、当該操作に関連付けられた騎乗モンスター又は自動戦闘モンスターに、当該操作に関連付けられたアクションを実行させる。例えば、タップ、上フリック、左右フリック、下フリック、一回転等の操作には、騎乗モンスターが関連付けられていてもよい。また、ロングタップの操作には、自動戦闘モンスターが関連付けられていてもよい。
これにより、ユーザは、キャラクタにアクションをさせるための操作の種類に応じて、操作対象となるキャラクタを切り替えられる。換言すると、ユーザは、操作対象を切り替えるための特別な操作を行う必要がない。つまり、ユーザは、少ないタッチ操作だけで、操作対象を切り替えながら、キャラクタにアクションを実行させてゲームを楽しむことができる。その結果、ユーザは、片手の操作で、プレイパートを進行させてゲームを楽しむことも可能である。
なお、ゲーム進行部112は、ユーザの操作に応じて、騎乗モンスターが人間キャラクタを乗せている状態と乗せていない状態を切り替えてもよい。この場合、騎乗モンスターが人間キャラクタを乗せていない状態では、ユーザの操作に応じて人間キャラクタを動作させることによりプレイパートを進行させてもよい。その場合、操作に関連付けられた人間キャラクタ、騎乗モンスター又は自動戦闘モンスターの何れかに、当該操作に関連付けられたアクションを実行させてもよい。また、騎乗モンスターが人間キャラクタを乗せている状態では騎乗モンスターに関連付けられた種類の操作が、乗せていない状態では人間キャラクタに関連付けられてもよい。つまり、騎乗モンスターが人間キャラクタを乗せているか否かに応じて、操作に関連付けられた対象が騎乗モンスター及び人間キャラクタの間で切り替わってもよい。
ここで、ユーザの操作に応じて騎乗モンスターに実行させるアクションは、当該騎乗モンスターについて、編集画面において関連付けられたアクションであってもよい。換言すると、編集画面生成部112Eは、騎乗モンスターについて、タッチスクリーンに対する連続する操作よりなる操作列に含まれる各操作に、該操作の操作列における順序に応じたアクションを関連付ける編集画面を表示する。編集画面については、実施形態4で述べた通りである。
また、ユーザの操作に応じて自動戦闘モンスターに実行させるアクションは、自動戦闘モンスター毎にあらかじめ定められたアクションであってもよい。また、自動戦闘モンスターについても、騎乗モンスターと同様の編集画面が提供されてもよい。この場合、ユーザの操作に応じて自動戦闘モンスターに実行させるアクションは、編集画面において関連付けられたアクションであってもよい。
また、ゲーム進行部112は、プレイパートの進行中に、ユーザの操作に応じて、使用中のデッキを複数のデッキのうち他のデッキに変更する。また、ゲーム進行部112は、ユーザの操作に応じて、変更後のデッキに含まれる、第1キャラクタを乗せた第2キャラクタと、第3キャラクタとの少なくとも何れかを動作させることによりプレイパートを進行させる。
これにより、ユーザは、例えば、異なる特性となるよう複数のデッキを編成しておけば、プレイパートの進行状況に応じて、当該進行状況に適した特性のデッキに変更してプレイパートを進行させることができる。その結果、複数のデッキを編成することによるゲームの興趣性が向上する。なお、デッキの特性は、デッキに含まれる各キャラクタのパラメータの組み合わせによって表される。
<ゲーム処理>
図21は、本実施形態に係るゲームプログラム131に基づいてゲームシステム1が実行するデッキ変更処理の流れを説明するフローチャートである。
ステップS701において、ユーザ端末100Cのデッキ編成部112Gは、人間キャラクタと、騎乗モンスターと、自動戦闘モンスターとをそれぞれが含む複数のデッキを編成する。
ステップS702において、ゲーム進行部112は、複数のデッキの何れかを選択して、プレイパートを開始する。選択されるデッキは、ユーザの操作に基づき指定されたデッキであってもよいし、自動的に選択されたデッキであってもよい。
ステップS703において、ゲーム進行部112は、プレイパートを進行する。本ステップにおける処理の詳細は、実施形態1において図6を参照して述べた通りである。
ステップS704において、ゲーム進行部112は、プレイパートを終了するか否かを判断する。例えば、ゲーム進行部112は、ユーザによる終了を指示する操作が受け付けられた場合には、プレイパートを終了すると判断してもよい。また、ゲーム進行部112は、プレイパートにおいて所定条件が満たされた場合に、プレイパートを終了すると判断してもよい。所定条件とは、例えば、制限時間が到来すること、デッキに含まれるキャラクタの一部または全部の体力がなくなること、ミッションが達成されること等であってもよいが、これらに限られない。ステップS704でYesの場合、デッキ変更処理が終了する。ステップS704でNoの場合、次のステップS705の処理が実行される。
ステップS705において、ゲーム進行部112は、デッキの変更を指示する操作が受け付けられたか否かを判断する。なお、本ステップは、敵キャラクタとの戦闘中(図6におけるステップS104の実行中)に実行されてもよい。ステップS705でNoの場合、ステップS703からの処理が繰り返される。また、ステップS705でYesの場合、次のステップS706の処理が実行される。
ステップS706において、ゲーム進行部112は、使用するデッキを変更する。具体的には、ゲーム進行部112は、オブジェクト制御部114を用いて、仮想的なゲーム空間から、変更前のデッキに含まれる各キャラクタを削除し、変更後のデッキに含まれる各キャラクタを配置する。詳細には、オブジェクト制御部114は、変更後のデッキに含まれる騎乗モンスターに人間キャラクタを乗せて、自動戦闘モンスターと共にゲーム空間に配置する。なお、ゲーム画面における各キャラクタの配置の詳細については後述する。デッキを変更すると、ゲーム進行部112は、ステップS703からの処理を繰り返す。
以上で、ゲームシステム1は、処理を終了する。
<ゲーム画面例>
図22〜図26を用いて、本実施形態においてユーザ端末100Cの表示部152に表示されるゲーム画面の具体例について説明する。
(デッキ編成画面の具体例)
図22は、ステップS701で表示されるデッキ編成画面の一例を示す図である。図22において、デッキ編成画面G1は、デッキタブG101a〜G101cと、編成エリアG102と、選択エリアG105、G106及びG107とを含む。
デッキタブG101a及びG101bは、編成中又は編成済みのデッキを表す情報を編成エリアG102に表示するためのUIオブジェクトの一例である。デッキタブG101cは、新しく作成したデッキを表す情報を編成エリアG102に表示するためのUIオブジェクトの一例である。編成エリアG102は、デッキタブG101a〜G101cの何れかに対応するデッキを表す情報を、切り替えて表示する。
図22では、デッキタブG101aに対応するデッキ1を表す情報が、編成エリアG102に表示されている。デッキ1は編成中であり、当該デッキ編成画面の表示が終了した時点で編成内容が確定されてもよい。
編成エリアG102は、デッキ1を表す情報として、人間キャラクタH1と、騎乗モンスターM1と、自動戦闘モンスターOP1及びOP5とをそれぞれ表すイラストと、キャラクタ情報G103a〜G103dと、装備ボタンG104a及びG104bとを含む。つまり、この具体例では、1つのデッキは、1つの人間キャラクタと、1つの騎乗モンスターと、2つの自動戦闘モンスターとを含むものとする。
キャラクタ情報G103a〜G103dは、それぞれ、その近傍に表示されたキャラクタに関する情報を表している。例えば、キャラクタ情報G103aは、人間キャラクタH1のパラメータが体力10、攻撃力20、防御力45であることを表している。
装備ボタンG104a及びG104bは、キャラクタに装備品を装備させるためのUIオブジェクトの一例である。この例では、人間キャラクタ及び騎乗モンスターに装備品を装備させることが可能である。ただし、装備品を装備可能なキャラクタは、デッキに含まれるキャラクタの少なくとも何れかであればよく、例えば、自動戦闘モンスターも装備品を装備可能であってもよい。また、人間キャラクタ及び騎乗モンスターの少なくとも何れかは、装備品を装備できなくてもよい。また、装備品の装備により、キャラクタのパラメータが、装備された装備品に応じてより有利に変化してもよい。
例えば、デッキ1に含まれる人間キャラクタH1は、武器H−K1を装備している。装備ボタンG104aに対する操作が受け付けられると、人間キャラクタH1が装備可能な装備品の何れかが、ユーザの操作により選択されて、当該キャラクタに装備される。装備品が装備された後に装備ボタンG104aに対する操作が受け付けられた場合には、装備品の変更が可能である。
なお、装備可能な装備品には、実施形態3において説明したような、キャラクタが関連付けられることにより強化された装備品も含まれる。もし、武器H−K1が、強化された装備品である場合、人間キャラクタH1のパラメータは、強化されていない武器H−K1が装備されたときよりも、より有利に変化する。
選択エリアG105は、デッキに含める人間キャラクタを選択するための領域の一例であり、人間キャラクタを表すキャラクタアイコンG108a〜G108bを含む。選択エリアG105に含まれる「人間キャラクタ(2)」の表示は、ユーザに付与されている人間キャラクタが、2つであることを表している。この具体例では、付与されている2つの人間キャラクタ全てが選択エリアG105に表示されている。
選択エリアG106は、デッキに含める騎乗モンスターを選択するための領域の一例であり、騎乗モンスターを表すキャラクタアイコンG108c〜G108gを含む。選択エリアG106の詳細は、選択エリアG105と同様に説明される。ただし、選択エリアG106には、ユーザに付与された騎乗モンスター8つのうち一部に対応するキャラクタアイコンが表示され、全てが表示されていない点が、選択エリアG105の詳細とは異なる。スクロールバーG109は、表示されていない騎乗モンスターに対応するキャラクタアイコンを表示させるためのUIオブジェクトの一例である。
選択エリアG107は、デッキに含める自動戦闘モンスターを選択するための領域の一例であり、自動戦闘モンスターを表すキャラクタアイコンG108h〜G108lを含む。選択エリアG107の詳細は、選択エリアG106と同様に説明される。
キャラクタアイコンG108a〜G108lの何れかに対する操作が受け付けられると、編成エリアG102における対応する種類のキャラクタのイラストが更新され、当該キャラクタがデッキに組み入れられる。例えば、図22において、キャラクタアイコンG108dに対する操作が受け付けられると、編成エリアG102に表示された騎乗モンスターM1のイラストが、騎乗モンスターM2のイラストに更新される。また、デッキ1に組み入れられていた騎乗モンスターM1が、騎乗モンスターM2に変更される。
(デッキを表す情報の具体例)
図23は、ステップS701において編成されたデッキを表す情報の一例を説明する図である。デッキを表す情報は、ステップS701において、ユーザ端末100Cの記憶部120及びサーバ200の記憶部220の少なくとも何れかに記憶される。この例では、デッキ編成画面に対するユーザの操作によって、デッキ1〜デッキ3が編成されたものする。
図23において、各デッキを表す情報は、デッキ番号と、人間キャラクタと、その装備品と、騎乗モンスターと、その装備品と、2つの自動戦闘モンスターとをそれぞれ表す情報を含む。例えば、デッキ番号が1のデッキ(以降、デッキ1と称する)は、人間キャラクタH1と、その装備品として武器H−K1と、騎乗モンスターM1と、その装備品としてアクセサリM−K1と、自動戦闘モンスターOP1と、自動戦闘モンスターOP5とを含んでいる。
(プレイパート画面におけるキャラクタの配置の具体例)
図24〜図25は、プレイパート画面におけるキャラクタの配置を説明するための図である。
ここで、ゲーム進行部112は、プレイパート画面を、横長画像及び縦長画像の何れかに切り替え可能である。例えば、ユーザ端末100Cの表示部152が長方形状である場合、表示制御部115は、長辺を横方向として横長画像のプレイパート画面を表示するか、短辺を横方向として縦長画像のプレイパート画面を表示するかを切り替える。
ここで、横長画像及び縦長画像間の切り替えは、ユーザ端末100Cに搭載されたジャイロセンサ又は加速度センサ等(何れも図示せず)によりユーザ端末100Cの動きが検知されたタイミングで行われてもよい。その場合、表示制御部115は、表示部152の長辺が水平方向に沿うと判定した場合に横長画像に切り替え、短辺が水平方向に沿うと判定した場合に縦長画像に切り替えてもよい。また、横長画像及び縦長画像間の切り替えは、ユーザ端末100Cの動きに関わらず、ユーザ操作に応じて行われてもよい。この場合、初期設定では、プレイパート画面は横長画像で表示されてもよい。ただし、初期設定は、必ずしも横長画像でなくてもよい。
オブジェクト制御部114は、人間キャラクタを乗せた騎乗モンスターと、自動戦闘モンスターとを、横長画像の横方向に沿って配置して表示部152に表示する。なお、横方向に沿う配置とは、各キャラクタの縦方向の座標が同一であることに限定されない。例えば、横方向に沿う配置とは、複数のキャラクタのうち縦方向において最も離れている2つのキャラクタ間の縦方向における距離が許容範囲内であり、且つ、横方向において隣り合うキャラクタ間の横方向における距離が閾値以上であることであってもよい。
また、オブジェクト制御部114は、使用中のデッキに複数の自動戦闘モンスターが含まれる場合に、複数の自動戦闘モンスターを、騎乗モンスターの両脇に分けて配置する。例えば、騎乗モンスターは、横方向における中央近傍に表示されてもよい。これにより、ユーザは、人間キャラクタを乗せた騎乗モンスターに注目することができる。また、オブジェクト制御部114は、横長画像において、人間キャラクタを乗せた騎乗モンスター及び自動戦闘モンスターより上方の領域に、敵キャラクタを配置する。ここで、横長画像における上方とは、当該画像が矩形である場合には、上端と定められた長辺に向かう方向である。
図24は、横長画像のプレイパート画面の一例を示す図である。図24に示すプレイパート画面G2は、例えば、ステップS702においてデッキ1が選択された場合に、ステップS703におけるプレイパートにおいて表示される。
横長画像のプレイパート画面G2では、デッキ1に含まれる人間キャラクタH1を乗せた騎乗モンスターM1と、自動戦闘モンスターOP1及びOP5とが、横方向に沿って配置されている。また、人間キャラクタH1は、武器H−K1を装備し、騎乗モンスターM1は、アクセサリM−K1を装備している。また、自動戦闘モンスターOP1と、OP5とは、騎乗モンスターM1の両脇に分けて配置されている。また、人間キャラクタH1を乗せた騎乗モンスターM1と、自動戦闘モンスターOP1及びOP5より上方の領域に、敵キャラクタe1が配置されている。
図25は、縦長画像のプレイパート画面の一例を示す図である。図25に示すプレイパート画面G3は、例えば、横長画像のプレイパート画面G2が表示されている状態で、縦長画像への切り替えが行われた場合に表示される。縦長画像のプレイパート画面G3では、デッキ1に含まれる人間キャラクタH1を乗せた騎乗モンスターM1の斜め上方の領域に、自動戦闘モンスターOP1及びOP5が配置されている。ここで、縦長画像における上方とは、当該画像が矩形である場合には、上端と定められた短辺に向かう方向である。なお、横長画像から縦長画像への切り替えの際には、自動戦闘モンスターOP1及びOP5が、上述した配置となるよう移動するアニメーションが表示されてもよい。また、縦長画像から横長画像への切り替えの際も同様である。なお、自動戦闘モンスターOP1及びOP5の配置は、騎乗モンスターM1の斜め上方の領域に限らず、斜め下方の領域であってもよい。
図24及び図25からわかるように、横長画像のプレイパート画面は、縦長画像のプレイパート画面に比べて、デッキに含まれる複数のキャラクタを、横方向の幅を有効に使って配置できるというメリットがある。その結果、隣り合うキャラクタ間に充分なスペースが確保され、圧迫感のないゲーム空間が表現される。また、横長画像のプレイパート画面は、縦長画像のプレイパート画面に比べて、配置された複数のキャラクタよりも上方の領域の幅が広くなり、敵キャラクタを配置する領域の幅を充分に確保することができる。その結果、複数の敵キャラクタが出現する場合に、当該複数の敵キャラクタを横方向に沿って配置することができる。これにより、敵キャラクタと味方キャラクタとが対峙して攻撃し合う状況を、ユーザにわかりやすく提示することができる。
また、横長画像で表示されたプレイパート画面に対する操作を行うユーザは、ユーザ端末100Cを横長の向きで保持する。ユーザ端末100Cを横長の向きで保持する場合、縦長の向きで保持する場合と比べて、操作する手によってプレイパート画面が隠れてしまう面積が小さくなるというメリットがある。
(プレイパート画面におけるデッキ変更の具体例)
図24及び図26を用いて、プレイパート画面におけるデッキ変更の具体例について説明する。
図24に示すプレイパート画面G2は、デッキ変更ボタンG201a〜G201cと、降りるボタンG202とを含む。デッキ変更ボタンG201〜G201cは、使用中のデッキの変更を指示する操作を受け付けるUIオブジェクトの一例である。デッキ変更ボタンG201a〜G201cは、それぞれ、編成済みのデッキ1〜3に対応付けられており、当該ボタンに対する操作が受け付けられると、使用中のデッキを、対応付けられたデッキに変更する処理が実行される。
プレイパート画面G2では、デッキ1が使用中であるため、当該デッキ1に対応付けられたデッキ変更ボタンG201aに対する操作は受け付け不可能となっている。また、デッキ変更ボタンG201aは、操作が受け付け不可能であることを表す態様で表示されてもよい。この例では、デッキ変更ボタンG201aは、デッキ1が使用中であることを表す情報を含むことにより、操作が受け付け不可能であることを表している。ただし、使用中のデッキに対応付けられたデッキ変更ボタンの表示態様は、これに限られない。
また、デッキ1とデッキ2とでは、人間キャラクタが同一であり、騎乗モンスター及び自動戦闘モンスターが異なっている。そのため、使用中のデッキ1からデッキ2への変更を行っても人間キャラクタは変更されず、騎乗モンスター及び自動戦闘モンスターが変更される。そこで、デッキ2に対応付けられたデッキ変更ボタンG201bは、変更により配置されるキャラクタの1つである騎乗モンスターM1のイラストを含んでいる。
また、デッキ1とデッキ3とでは、人間キャラクタが異なっているため、使用中のデッキ1からデッキ3への変更を行うと人間キャラクタが変更される。そこで、デッキ3に対応付けられたデッキ変更ボタンG201cは、変更により配置される人間キャラクタH2のイラストを含んでいる。
このように、デッキ変更ボタンは、当該ボタンに対する操作により人間キャラクタが変更される場合は、変更により配置される人間キャラクタのイラストを含んでいてもよい。また、デッキ変更ボタンは、当該ボタンに対する操作により人間キャラクタが変更されない場合は、変更により配置されるモンスターの少なくとも1つのイラストを含んでいてもよい。これにより、ユーザは、デッキ変更ボタンに対する操作によって配置されるキャラクタの概要を、容易に認識することができる。
降りるボタンG202に対する操作が受け付けられると、騎乗モンスターM1が人間キャラクタH1を乗せた状態から、乗せていない状態に変更する処理が行われる。変更する処理の際には、人間キャラクタH1が騎乗モンスターから降りるアニメーションが表示されてもよい。騎乗モンスターM1が人間キャラクタH1を乗せていない状態では、ユーザの操作に応じて、人間キャラクタH1が操作可能となる。
図26は、ステップS706において、デッキの変更を指示する操作が受け付けられた場合に、その後のステップS703において表示されるプレイパート画面の一例である。ここでは、図24において、デッキ3に対応付けられたデッキ変更ボタンG201cに対する操作が受け付けられたものとして説明する。図26に示すプレイパート画面G4は、プレイパート画面G3と同様に横長画像である。プレイパート画面G4は、プレイパート画面G3に対して、デッキ1に含まれる各キャラクタに替えて、デッキ3に含まれる各キャラクタを含む点が異なる。また、デッキ変更ボタンG201a〜G201cに替えて、デッキ変更ボタンG301a〜G301cを含む点も異なる。デッキ3に含まれる各キャラクタの配置については、図24で説明した各キャラクタの配置と同様に説明されるため、詳細な説明を繰り返さない。
プレイパート画面G4では、デッキ3が使用中であるため、当該デッキ3に対応付けられたデッキ変更ボタンG301cに対する操作は受け付け不可能となっている。また、デッキ3とデッキ1とでは、人間キャラクタが異なっているため、デッキ1に対応付けられたデッキ変更ボタンG301aは、変更により配置される人間キャラクタH1のイラストを含んでいる。デッキ変更ボタンG301bも、デッキ変更ボタンG301aと同様に、人間キャラクタH1のイラストを含んでいる。
このように、役割の異なる複数のキャラクタ(人間キャラクタ、騎乗モンスター、自動戦闘モンスター)をそれぞれ含む複数のデッキを編成し、使用するデッキを変更しながらプレイパートを進行させることで、プレイパートの進行が多様化して興趣性が向上する。また、複数のデッキを編成しておくことの楽しみを、ユーザに提供することができる。また、複数のデッキを編成するために必要となるキャラクタを獲得することに対するユーザの動機付けが向上する。
〔実施形態5の変形例〕
本実施形態において、プレイパートでは、騎乗モンスターが人間キャラクタを乗せているか否かに応じて、操作の対象が騎乗モンスター及び人間キャラクタの間で切り替わる例について説明した。これに限らず、騎乗モンスターが人間キャラクタを乗せているか否かに関わらず、騎乗モンスター及び人間キャラクタの双方が操作の対象であってもよい。また、騎乗モンスターが人間キャラクタを乗せている場合には、人間キャラクタは操作の対象でなく騎乗モンスターが操作の対象であり、乗せていない場合には、騎乗モンスター及び人間キャラクタの双方が操作の対象であってもよい。
また、本実施形態では、プレイパートの進行中に、デッキに含まれる全てのキャラクタがゲーム空間に配置されるものとして説明した。これに限らず、ゲーム空間には、プレイパートの進行状況に応じて、デッキに含まれる一部のキャラクタが配置され、他の一部のキャラクタは配置されなくてもよい。
例えば、騎乗モンスターが人間キャラクタを乗せていない場合には、騎乗モンスターをゲーム空間に配置しないようにしてもよい。一例として、ゲーム空間において敵キャラクタが出現していない場合には、人間キャラクタを降ろした騎乗モンスターがゲーム空間から消えるように構成してもよい。このような構成は、例えば、ゲーム空間における経路に応じて、当該経路の移動に適したキャラクタが異なる場合に有効である。例えば、騎乗モンスターでの移動が適した経路では、人間キャラクタを乗せた騎乗モンスターを移動させればよく、人間キャラクタでの移動が適した経路では、騎乗モンスターから降りた人間キャラクタを用いて移動させればよい。その場合、人間キャラクタを降ろした騎乗モンスターは、仮想空間から消えていることが望ましい。
また、例えば、ゲーム空間において敵キャラクタが出現していない場合には、デッキに含まれる人間キャラクタを乗せた騎乗モンスターをゲーム空間に配置し、敵キャラクタが出現したタイミングで、同デッキに含まれる自動戦闘モンスターをゲーム空間に配置してもよい。あるいは、ユーザの操作に応じて、同デッキに含まれる自動戦闘モンスターをゲーム空間に配置してもよい。
また、図24及び図26に示したプレイパート画面では、プレイパートにおける戦闘の進行中に、デッキを変更可能である例について説明した。これに限らず、プレイパートにおいて戦闘が進行していない間、すなわち、敵キャラクタが出現していない間にも、デッキを変更可能であってもよい。
また、図24〜図26では、騎乗モンスターが人間キャラクタを乗せた状態から乗せていない状態に切り替えるための降りるボタンG202が表示される例について説明した。さらに、騎乗モンスターが人間キャラクタを乗せていない状態のプレイパート画面では、乗せていない状態から乗せた状態に切り替えるためのUIオブジェクトが表示されてもよい。また、乗せている状態と乗せていない状態とを切り替えるためのユーザ操作は、ボタン等のUIオブジェクトに対する操作に限らない。例えば、タッチ操作の種類に応じて、乗せている状態と乗せていない状態とを切り替える処理が実行されてもよい。
〔その他の変形例〕
上述した実施形態5において、デッキ編成部112Gは、ゲームにおいて利用可能なキャラクタのうち、第1キャラクタ、第2キャラクタ及び第3キャラクタをそれぞれ含む複数のデッキを編成するものとして説明した。第2キャラクタとは、第1キャラクタの乗り物となるキャラクタであるとして説明し、図24および図26等では、第1キャラクタである人間キャラクタが第2キャラクタである騎乗モンスターに乗り、人間キャラクタに代わって騎乗モンスターが戦闘を行う例、および、人間キャラクタが騎乗モンスターに乗っておらず人間キャラクタが戦闘を行う例を説明した。
この他に、デッキの編成において、第1キャラクタである人間キャラクタに、第2キャラクタであるモンスターキャラクタを関連付けることにより、人間キャラクタまたはモンスターキャラクタのいずれかを表示して、ユーザの操作に応じて動作することとしてもよい。すなわち、第2キャラクタであるモンスターが戦闘する場合、人間キャラクタは描画されないこととしてもよい。例えば、人間キャラクタがモンスターキャラクタを召喚して、モンスターキャラクタとして戦闘をする場合などがある。この場合、モンスターキャラクタに戦闘をさせるために、アイテムを集めることや人間キャラクタで戦闘を行うことなどの所定の条件を必要とすることとしてもよい。例えば、図24および図26の例ではボタンG202により人間キャラクタをユーザの操作対象とするか騎乗モンスターをユーザの操作対象とするかを切り替えることとしているが、上記の所定の条件を満たさない限りボタンG202への入力操作を無効化し、上記の所定の条件を満たすことにより、ボタンG202への入力操作を有効にすることとしてもよい。
以上のように、本開示のある局面によると、ゲームプログラムは、プロセッサに、ゲームプログラムに基づくゲームにおいて利用可能なキャラクタのうち、人間キャラクタである第1キャラクタと、第1キャラクタに代わって戦闘のための入力操作をユーザから受け付ける第2キャラクタと、を関連付けた組み合わせを含むデッキを編成するステップと、デッキに含まれる第1キャラクタと第2キャラクタとの組み合わせのうち何れかを使用して、ユーザの操作に応じて、第1キャラクタと、第2キャラクタと、の少なくとも何れかを動作させることによりゲームを進行させるステップと、ゲームの進行中に、ユーザの操作に応じて、使用中の組み合わせを他の組み合わせに変更するステップと、を実行させる。
上述した各実施形態において、各キャラクタに実行させることが可能なアクションは、タッチ操作の方向と当該キャラクタが向いている向きとに応じたアクションであってもよい。例えば、ゲーム進行部112は、タッチスクリーン15に対するタッチ位置を第1の位置から第2の位置へ移動させることにより入力される第1の入力操作を受け付けた場合に、第1の位置と第2の位置とにより定まるタッチ操作の方向を特定する。第1の入力操作とは、例えば、フリック操作であるが、これに限られない。また、ゲーム進行部112は、タッチスクリーン15に表示される画面においてキャラクタが向いている方向を特定する。また、ゲーム進行部112は、タッチ操作の方向とキャラクタが向いている方向とを比較し、比較結果に応じたアクションを、キャラクタに実行させる。
比較結果に応じてキャラクタに実行させるアクションとしては、例えば、対象オブジェクトに作用を及ぼすためのアクション、移動するためのアクション等が挙げられる。作用としては、例えば、攻撃が挙げられる。対象オブジェクトに作用を及ぼすためのアクションとしては、例えば、攻撃動作が挙げられる。また、対象オブジェクトの種類としては、例えば、キャラクタに対して攻撃動作等を行なう敵キャラクタ、障害物のオブジェクトが挙げられる。また、移動とは、ゲーム空間におけるキャラクタの位置を変更するためのアクションである。移動するためのアクションとしては、例えば、歩行、走行、他のオブジェクトまたは他のオブジェクトによる攻撃動作を避けるための回避動作が挙げられる。
例えば、ゲーム進行部112は、第1の入力操作を受け付けた場合に、タッチ操作の方向が、キャラクタが向いている方向により定まる一定範囲の方向に含まれていれば、他のオブジェクトに作用を及ぼすためのアクションを、当該キャラクタに実行させてもよい。
〔ソフトウェアによる実現例〕
制御部210の制御ブロック(特に、送受信部211、サーバ処理部212及びデータ管理部213)、ならびに、制御部110の制御ブロック(特に、操作受付部111、ゲーム進行部112、カメラ配置制御部113、オブジェクト制御部114、表示制御部115及び通信部116)は、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェアによって実現してもよい。
後者の場合、制御部210または制御部110、もしくはその両方を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するCPU、上記プログラムおよび各種データがコンピュータ(またはCPU)で読み取り可能に記録されたROM(Read Only Memory)または記憶装置(これらを「記録媒体」と称する)、上記プログラムを展開するRAM(Random Access Memory)などを備えている。そして、コンピュータ(またはCPU)が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
〔付記事項〕
本発明の一側面に係る内容を列記すると以下のとおりである。
(項目1) プロセッサ(10、20)と、メモリ(11、21)とを備えるコンピュータ(ユーザ端末100およびサーバ200の少なくとも一方)により実行されるゲームプログラム(131、231)について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサに、ゲームプログラムに基づくゲームにおいて利用可能なキャラクタのうち、第1キャラクタと、第1キャラクタの乗り物となる第2キャラクタと、第1キャラクタをゲームの進行において支援する第3キャラクタと、をそれぞれ含む複数のデッキを編成するステップと、複数のデッキのうち何れかを使用して、ユーザの操作に応じて、当該デッキに含まれる、第1キャラクタを乗せた第2キャラクタと、第3キャラクタとの少なくとも何れかを動作させることによりゲームを進行させるステップと、ゲームの進行中に、ユーザの操作に応じて、使用中のデッキを複数のデッキのうち他のデッキに変更するステップと、を実行させる。上記の構成によれば、役割の異なる複数のキャラクタをそれぞれ含む複数のデッキの何れかを使用してゲームを進行させることができ、ゲーム進行中にデッキを変更することもできる。その結果、ゲームの進行が多様化してゲームの興趣性が向上する。
(項目2) (項目1)において、ゲームを進行させるステップは、第1キャラクタを乗せた第2キャラクタと第3キャラクタとを、横長画像の横方向に沿って配置して表示部に表示してもよい。これにより、横長画面の横方向には充分なスペースがあるので、隣り合うキャラクタ間に充分なスペースを確保できる。その結果、キャラクタが重なり合って表示されることがなく、圧迫感のないゲーム空間をユーザに提示することができる。
(項目3) (項目2)において、ゲームを進行させるステップは、使用中のデッキに複数の第3キャラクタが含まれる場合に、複数の第3キャラクタを、第2キャラクタの両脇に分けて配置してもよい。これにより、デッキに第3キャラクタが2体以上含まれる場合に、ユーザに対して、第1キャラクタを乗せた第2キャラクタに注目させることができる。
(項目4) (項目2)又は(項目3)において、ゲームを進行させるステップは、第1キャラクタ、第2キャラクタ及び第3キャラクタと、敵キャラクタとを戦闘させることによりゲームを進行させ、横長画像において、第2キャラクタ及び第3キャラクタよりも上方の領域に敵キャラクタを配置するように表示部に表示してもよい。これにより、敵キャラクタに対して、第1キャラクタを乗せた第2キャラクタ及び第3キャラクタを横並びで対峙させることにより、ユーザに敵キャラクタを注目させることができる。
(項目5) (項目2)から(項目4)の何れか1項目において、ゲームを進行させるステップは、表示部に表示させる画像を横長画像及び縦長画像の何れかに切り替え可能であり、縦長画像において、第3キャラクタを、第2キャラクタよりも斜め上方又は斜め下方の領域に配置するように表示部に表示してもよい。これにより、ユーザは、縦長画面においても、縦長画像用の配置でゲームのプレイを楽しむことができる。
(項目6) (項目1)から(項目5)の何れか1項目において、ゲームを進行させるステップは、表示部としてのタッチスクリーンに対するユーザの操作を受け付けると、当該操作に関連付けられた第2キャラクタ又は第3キャラクタに、当該操作に関連付けられたアクションを実行させてもよい。これにより、ユーザは、キャラクタにアクションをさせるための操作に応じて、操作対象となるキャラクタを切り替えられる。換言すると、ユーザは、操作対象を切り替えるための特別な操作を行う必要がない。その結果、少ないタッチ操作だけで、操作対象を切り替えながらキャラクタにアクションを実行させてゲームを楽しむことができる。
(項目7) (項目6)において、ゲームプログラムは、プロセッサに、タッチスクリーンに対する連続する操作よりなる操作列に含まれる各操作に、該操作の操作列における順序に応じたアクションを関連付ける編集画面を表示するステップをさらに実行させてもよい。これにより、ユーザは、連続するタッチ入力に応じたゲーム展開を、編集により変化させることができる。その結果、ユーザは、連続する操作に応じて多様なゲーム展開を楽しむことができ、ゲームの興趣性がより高まる。
(項目8) (項目1)から(項目7)の何れか1項目において、ゲームを進行させるステップは、第1キャラクタ、第2キャラクタ及び第3キャラクタを、敵キャラクタと戦闘させることによりゲームを進行させ、ゲームプログラムは、プロセッサに、ユーザの操作に応じて、ゲームにおいて利用可能なキャラクタのうち何れかを選択し、選択したキャラクタを、ユーザに付与されたものとしてユーザに関連付けてメモリに記憶させるステップと、ゲームを進行させるステップにおける戦闘結果に応じて、ゲームにおいて利用可能なキャラクタのうち何れかを選択し、選択したキャラクタを、ユーザに付与されたものとしてユーザに関連付けてメモリに記憶させるステップと、をさらに実行させ、複数のデッキを編成するステップは、複数のデッキのそれぞれに含める第1キャラクタ、第2キャラクタ及び第3キャラクタの少なくとも何れかとして、ユーザに付与されたキャラクタの何れかを適用してもよい。これにより、戦闘結果に応じてキャラクタをユーザに付与することで、ゲームをプレイすることに対するユーザの動機付けを向上させる。また、ユーザの操作に応じて選択したキャラクタをユーザに付与することで、選択を実行させることに対するユーザの動機付けを向上させる。さらに、付与されたキャラクタを、デッキに含めて戦闘に参加させることができるので、ゲームをプレイすることに対するユーザの動機付けをさらに向上させる。このように、キャラクタの獲得と、ゲームのプレイという2つの目的を循環的にユーザに提示することができるため、ユーザにゲームを飽きずに継続させることができる。したがって、ユーザにゲームをプレイする動機を継続的に与え、これによりゲームの興趣性を向上させることができる。
(項目9) (項目1)から(項目8)の何れか1項目において、ゲームプログラムは、プロセッサに、ゲームにおいて利用可能な装備品に、ゲームプログラムに基づくゲームにおいてデッキに含めることが可能なキャラクタの何れかを関連付けることにより、関連付けたキャラクタに応じた効果を、当該装備品に付与するステップをさらに実行させ、複数のデッキを編成するステップは、複数のデッキのそれぞれに含める第1キャラクタ、第2キャラクタ及び第3キャラクタとして、装備品に関連付けられていないキャラクタをそれぞれ適用し、ゲームを進行させるステップは、使用中のデッキに含まれる第1キャラクタ、第2キャラクタ及び第3キャラクタの少なくとも何れかに、効果が付与された装備品を装備させることにより、当該効果を反映させてゲームを進行させてもよい。これにより、ユーザは、デッキに含めない不要なキャラクタを装備品に関連付けることで、当該装備品に当該キャラクタに応じた効果を付与することができ、不要なキャラクタを有効に活用することができる。また、装備品に関連付けたキャラクタはデッキに含めることができないので、装備品に関連付けるキャラクタの選択をユーザに考えさせることができ、ゲームの戦略性を向上させる。
(項目10) (項目1)から(項目9)の何れか1項目において、ゲームを進行させるステップは、ユーザの操作に応じて第2キャラクタが第1キャラクタを乗せた状態及び乗せていない状態を切り替え、第2キャラクタが第1キャラクタを乗せていない状態では、ユーザの操作に応じて第1キャラクタを動作させることによりゲームを進行させてもよい。これにより、ユーザは、第1キャラクタが第2キャラクタに乗っているか否かに応じて、操作の対象を切り替えることができ、ゲームの進行がさらに多様化してゲームの興趣性が向上する。
(項目11) (項目1)から(項目10)の何れか1項目において、ゲームを進行させるステップは、第1キャラクタ、第2キャラクタ及び第3キャラクタと、敵キャラクタとを戦闘させることによりゲームを進行させ、ユーザの操作によらずに第3キャラクタを敵キャラクタと戦闘させてもよい。これにより、第3キャラクタが操作によらずに敵キャラクタと戦闘するので、ユーザは、第1キャラクタを乗せた第2キャラクタを敵キャラクタと戦闘させるための操作に注力できる。
(項目12) ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。該方法は、プロセッサが(項目1)に記載のゲームプログラムの各ステップを実行する方法である。(項目12)に係る方法は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。
(項目13) 情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、(項目1)に係るゲームプログラム(131、231)を記憶するメモリ(11、21)と、該ゲームプログラムを実行することにより、情報処理装置(ユーザ端末100およびサーバ200の少なくとも一方)の動作を制御するプロセッサ(10、20)とを備える。(項目13)に係る情報処理装置は、(項目1)に係るゲームプログラムと同様の作用効果を奏する。