JP2022125202A - ゲームプログラム、方法、および情報処理装置 - Google Patents

Abstract

【課題】ゲームの興趣性を向上させる。
【解決手段】ゲームプログラム（１３１）は、プロセッサ（１０）に、権利アイテムをユーザに関連付けるステップ（Ｓ３０２）と、第１のキャラクタと第２のキャラクタとを戦闘させるステップと、戦闘内容に基づいて、権利アイテムを消費可能とするための第１の条件が満たされたか否かを判定するステップ（Ｓ３０５、Ｓ４０１）と、第１の条件が満たされた場合に、ユーザに関連付けられた１以上の権利アイテムのうち、抽選により、少なくとも何れかを特定するステップ（Ｓ４０２）と、特定された権利アイテムについて、当該権利アイテムを消費して、当該権利アイテムに応じたオブジェクトをユーザに付与するステップ（Ｓ４０６）と、を実行させる。
【選択図】図１０

Description

本開示はゲームプログラム、ゲームプログラムを実行する方法および情報処理装置に関する。

ゲーム空間内に、オブジェクトを表示させて、ユーザに該オブジェクトを操作させることによりゲームを進行させるゲームプログラムが、様々な事業者により提供されている。このようなゲームにおいて、ゲームをプレイした場合（一例として、所定の課題をクリアした場合など）に応じて、報酬をユーザに獲得させることが広く行われている。報酬は、多くの場合、ゲームを有利に進めるための、上述のオブジェクト、アイテムまたはポイントなどであったりする。

Pokemon GO公式サイト、[online］、２０１７年、Niantic, Inc.、株式会社ポケモン、任天堂株式会社、株式会社クリーチャーズ、株式会社ゲームフリーク、[２０１７年３月１３日検索]、インターネット（ＵＲＬ：http://www.pokemongo.jp/）

しかしながら、上述のような従来技術は、報酬を獲得したとしても、ゲームの進行が単調になると、ユーザがゲームをプレイすることに対するインセンティブを維持することが徐々に難しくなる。

本発明の一態様は、ユーザの操作に応じてゲームを進行させつつ、ゲームの展開を多様化させることで、ゲームの興趣性をいっそう向上させることを目的とする。

本開示に係るゲームプログラムは、プロセッサ、メモリ、及び操作部を備えるコンピュータにより実行される。ゲームプログラムは、プロセッサに、権利アイテムをユーザに関連付けるステップと、ユーザの入力操作に応じて、ユーザが操作対象とする第１のキャラクタと、第１のキャラクタと戦闘する対象となる第２のキャラクタとを戦闘させるステップと、戦闘させるステップにおける戦闘内容に基づいて、権利アイテムを消費可能とするための第１の条件が満たされたか否かを判定するステップと、第１の条件が満たされた場合に、ユーザに関連付けられた１以上の権利アイテムのうち、抽選により、少なくとも何れかを特定するステップと、特定された権利アイテムについて、当該権利アイテムを消費して、当該権利アイテムに応じたオブジェクトをユーザに付与するステップと、を実行させる。

本開示に係る方法は、プロセッサ、メモリ、及び操作部を備えるコンピュータがゲームプログラムを実行する方法である。該方法は、プロセッサが、請求項１に記載の各ステップを実行することを含む。

本開示に係る情報処理装置は、上述のゲームプログラムを記憶する記憶部と、該ゲームプログラムを実行することにより、情報処理装置の動作を制御する制御部と、を備えている。

本開示の一態様によれば、ゲームの興趣性を向上させるという効果を奏する。

本発明の実施形態に係るゲームシステムのハードウェア構成を示す図である。 本発明の実施形態に係るユーザ端末およびサーバの機能的構成を示すブロック図である。 （Ａ）及び（Ｂ）は、本発明の実施形態におけるゲーム画面の具体例を示す図である。 （Ａ）～（Ｄ）は、本発明の実施形態において消費アイテムとの引き換えに第１の抽選を行う画面の具体例を示す図である。 （Ａ）～（Ｃ）は、本発明の実施形態において第１の条件が満たされた場合に第１の抽選を行う画面の具体例を示す図である。 （Ａ）及び（Ｂ）は、本発明の実施形態における操作列の編集画面の具体例を示す図である。 本発明の実施形態において操作列の編集を行う処理の流れを説明するフローチャートである。 本発明の実施形態において連続する操作の順序に応じてキャラクタにアクションを実行させる処理の流れを説明するフローチャートである。 本発明の実施形態において第１の条件が満たされたか否かを判断する処理の流れを説明するフローチャートである。 本発明の実施形態において第１の条件が満たされたことに応じて第１の抽選を行う処理の流れを説明するフローチャートである。 本発明の実施形態において消費アイテムとの引き換えに第１の抽選を行う処理の流れを説明するフローチャートである。 本発明の実施形態において権利アイテムを一括して消費する処理の流れを説明するフローチャートである。

〔実施形態〕
本開示に係るゲームシステムは、複数のユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。

＜ゲームシステム１のハードウェア構成＞
図１は、ゲームシステム１のハードウェア構成を示す図である。ゲームシステム１は図示の通り、複数のユーザ端末１００と、サーバ２００とを含む。各ユーザ端末１００は、サーバ２００とネットワーク２を介して接続する。ネットワーク２は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂３Ｇ、４Ｇ移動通信システム、ＬＴＥ（Long Term Evolution）、および所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク（例えばWi-Fi（登録商標））等が挙げられる。

サーバ２００（コンピュータ、情報処理装置）は、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってよい。サーバ２００は、プロセッサ２０と、メモリ２１と、ストレージ２２と、通信ＩＦ２３と、入出力ＩＦ２４とを備える。サーバ２００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。

ユーザ端末１００（コンピュータ、情報処理装置）は、スマートフォン、フィーチャーフォン、ＰＤＡ（Personal Digital Assistant）、またはタブレット型コンピュータ等の携帯端末であってよい。ユーザ端末１００は、ゲームプレイに適したゲーム装置であってもよい。ユーザ端末１００は図示の通り、プロセッサ１０と、メモリ１１と、ストレージ１２と、通信インターフェース（ＩＦ）１３と、入出力ＩＦ１４と、タッチスクリーン１５（表示部）と、カメラ１７と、測距センサ１８とを備える。ユーザ端末１００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末１００は、タッチスクリーン１５に代えて、または、加えて、ユーザ端末１００本体とは別に構成されたディスプレイ（表示部）を接続可能な入出力ＩＦ１４を備えていてもよい。

また、図１に示すように、ユーザ端末１００は、１以上のコントローラ１０２０と通信可能に構成されることとしてもよい。コントローラ１０２０は、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信規格に従って、ユーザ端末１００と通信を確立する。コントローラ１０２０は、１以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末１００へ送信する。また、コントローラ１０２０は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末１００へ送信する。

なお、ユーザ端末１００がカメラ１７および測距センサ１８を備えることに代えて、または、加えて、コントローラ１０２０がカメラ１７および測距センサ１８を有していてもよい。

ユーザ端末１００は、例えばゲーム開始時に、コントローラ１０２０を使用するユーザに、該ユーザの名前またはログインＩＤ等のユーザ識別情報を、該コントローラ１０２０を介して入力させることが望ましい。これにより、ユーザ端末１００は、コントローラ１０２０とユーザとを紐付けることが可能となり、受信した出力値の送信元（コントローラ１０２０）に基づいて、該出力値がどのユーザのものであるかを特定することができる。

ユーザ端末１００が複数のコントローラ１０２０と通信する場合、各コントローラ１０２０を各ユーザが把持することで、ネットワーク２を介してサーバ２００などの他の装置と通信せずに、該１台のユーザ端末１００でマルチプレイを実現することができる。また、各ユーザ端末１００が無線ＬＡＮ（Local Area Network）規格等の無線規格により互いに通信接続する（サーバ２００を介さずに通信接続する）ことで、複数台のユーザ端末１００によりローカルでマルチプレイを実現することもできる。１台のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、ユーザ端末１００は、さらに、サーバ２００が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末１００は、サーバ２００が備える後述する種々の機能を分散して備えていてもよい。

なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末１００はサーバ２００と通信を行ってもよい。例えば、あるゲームにおける成績または勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ２００に送信してもよい。

また、コントローラ１０２０は、ユーザ端末１００に着脱可能な構成であるとしてもよい。この場合、ユーザ端末１００の筐体における少なくともいずれかの面に、コントローラ１０２０との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末１００とコントローラ１０２０とが結合している場合は、ユーザ端末１００とコントローラ１０２０とは、有線を介して信号を送受信する。

図１に示すように、ユーザ端末１００は、外部のメモリカード等の記憶媒体１０３０の装着を、入出力ＩＦ１４を介して受け付けてもよい。これにより、ユーザ端末１００は、記憶媒体１０３０に記録されるプログラム及びデータを読み込むことができる。記憶媒体１０３０に記録されるプログラムは、例えばゲームプログラムである。

ユーザ端末１００は、サーバ２００等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末１００のメモリ１１に記憶してもよいし、記憶媒体１０３０から読み込むことにより取得したゲームプログラムをメモリ１１に記憶してもよい。

以上で説明したとおり、ユーザ端末１００は、該ユーザ端末１００に対して情報を入力する機構の一例として、通信ＩＦ１３、入出力ＩＦ１４、タッチスクリーン１５、カメラ１７、および、測距センサ１８を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。

例えば、操作部が、カメラ１７および測距センサ１８の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末１００の近傍の物体１０１０を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体１０１０としてのユーザの手、予め定められた形状のマーカーなどが検出され、検出結果として得られた物体１０１０の色、形状、動き、または、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末１００は、カメラ１７の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ（ユーザの手の一連の動き）を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。

あるいは、操作部がタッチスクリーン１５で構成される場合、ユーザ端末１００は、タッチスクリーン１５の入力部１５１に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信ＩＦ１３で構成される場合、ユーザ端末１００は、コントローラ１０２０から送信される信号（例えば、出力値）をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力ＩＦ１４で構成される場合、該入出力ＩＦ１４と接続されるコントローラ１０２０とは異なる入力装置（図示せず）から出力される信号をユーザの入力操作として特定し、受け付ける。

＜各装置のハードウェア構成要素＞
プロセッサ１０は、ユーザ端末１００全体の動作を制御する。プロセッサ２０は、サーバ２００全体の動作を制御する。プロセッサ１０および２０は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、およびＧＰＵ（Graphics Processing Unit）を含む。

プロセッサ１０は後述するストレージ１２からプログラムを読み出し、後述するメモリ１１に展開する。プロセッサ２０は後述するストレージ２２からプログラムを読み出し、後述するメモリ２１に展開する。プロセッサ１０およびプロセッサ２０は展開したプログラムを実行する。

メモリ１１および２１は主記憶装置である。メモリ１１および２１は、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）等の記憶装置で構成される。メモリ１１は、プロセッサ１０が後述するストレージ１２から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ１０に作業領域を提供する。メモリ１１は、プロセッサ１０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ２１は、プロセッサ２０が後述するストレージ２２から読み出した各種プログラムおよびデータを一時的に記憶することにより、プロセッサ２０に作業領域を提供する。メモリ２１は、プロセッサ２０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。

本実施形態においてプログラムとは、ゲームをユーザ端末１００により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームをユーザ端末１００とサーバ２００との協働により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームを複数のユーザ端末１００の協働により実現するためのゲームプログラムであってもよい。また、各種データとは、ユーザ情報およびゲーム情報などのゲームに関するデータ、ならびに、ユーザ端末１００とサーバ２００との間または複数のユーザ端末１００間で送受信する指示または通知を含んでいる。

ストレージ１２および２２は補助記憶装置である。ストレージ１２および２２は、フラッシュメモリまたはＨＤＤ（Hard Disk Drive）等の記憶装置で構成される。ストレージ１２およびストレージ２２には、ゲームに関する各種データが格納される。

通信ＩＦ１３は、ユーザ端末１００における各種データの送受信を制御する。通信ＩＦ２３は、サーバ２００における各種データの送受信を制御する。通信ＩＦ１３および２３は例えば、無線ＬＡＮ（Local Area Network）を介する通信、有線ＬＡＮ、無線ＬＡＮ、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。

入出力ＩＦ１４は、ユーザ端末１００がデータの入力を受け付けるためのインターフェースであり、またユーザ端末１００がデータを出力するためのインターフェースである。入出力ＩＦ１４は、ＵＳＢ（Universal Serial Bus）等を介してデータの入出力を行ってもよい。入出力ＩＦ１４は、例えば、ユーザ端末１００の物理ボタン、カメラ、マイク、または、スピーカ等を含み得る。サーバ２００の入出力ＩＦ２４は、サーバ２００がデータの入力を受け付けるためのインターフェースであり、またサーバ２００がデータを出力するためのインターフェースである。入出力ＩＦ２４は、例えば、マウスまたはキーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。

ユーザ端末１００のタッチスクリーン１５は、入力部１５１と表示部１５２とを組み合わせた電子部品である。入力部１５１は、例えばタッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部１５２は、例えば液晶ディスプレイ、または有機ＥＬ（Electro-Luminescence）ディスプレイ等によって構成される。

入力部１５１は、入力面に対しユーザの操作（主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作）が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部１５１は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。

図示していないが、ユーザ端末１００は、該ユーザ端末１００の保持姿勢を特定するための１以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。ユーザ端末１００がセンサを備えている場合、プロセッサ１０は、センサの出力からユーザ端末１００の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ１０は、ユーザ端末１００が縦向きに保持されているときには、縦長の画像を表示部１５２に表示させる縦画面表示としてもよい。一方、ユーザ端末１００が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ１０は、ユーザ端末１００の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。

カメラ１７は、イメージセンサ等を含み、レンズから入射する入射光を電気信号に変換することで撮影画像を生成する。

測距センサ１８は、測定対象物までの距離を測定するセンサである。測距センサ１８は、例えば、パルス変換した光を発する光源と、光を受ける受光素子とを含む。測距センサ１８は、光源からの発光タイミングと、該光源から発せられた光が測定対象物にあたって反射されて生じる反射光の受光タイミングとにより、測定対象物までの距離を測定する。測距センサ１８は、指向性を有する光を発する光源を有することとしてもよい。

ここで、ユーザ端末１００が、カメラ１７と測距センサ１８とを用いて、ユーザ端末１００の近傍の物体１０１０を検出した検出結果を、ユーザの入力操作として受け付ける例をさらに説明する。カメラ１７および測距センサ１８は、例えば、ユーザ端末１００の筐体の側面に設けられてもよい。カメラ１７の近傍に測距センサ１８が設けられてもよい。カメラ１７としては、例えば赤外線カメラを用いることができる。この場合、赤外線を照射する照明装置および可視光を遮断するフィルタ等が、カメラ１７に設けられてもよい。これにより、屋外か屋内かにかかわらず、カメラ１７の撮影画像に基づく物体の検出精度をいっそう向上させることができる。

プロセッサ１０は、カメラ１７の撮影画像に対して、例えば以下の（１）～（５）に示す処理のうち１以上の処理を行ってもよい。（１）プロセッサ１０は、カメラ１７の撮影画像に対し画像認識処理を行うことで、該撮影画像にユーザの手が含まれているか否かを特定する。プロセッサ１０は、上述の画像認識処理において採用する解析技術として、例えばパターンマッチング等の技術を用いてよい。（２）また、プロセッサ１０は、ユーザの手の形状から、ユーザのジェスチャを検出する。プロセッサ１０は、例えば、撮影画像から検出されるユーザの手の形状から、ユーザの指の本数（伸びている指の本数）を特定する。プロセッサ１０はさらに、特定した指の本数から、ユーザが行ったジェスチャを特定する。例えば、プロセッサ１０は、指の本数が５本である場合、ユーザが「パー」のジェスチャを行ったと判定する。また、プロセッサ１０は、指の本数が０本である（指が検出されなかった）場合、ユーザが「グー」のジェスチャを行ったと判定する。また、プロセッサ１０は、指の本数が２本である場合、ユーザが「チョキ」のジェスチャを行ったと判定する。（３）プロセッサ１０は、カメラ１７の撮影画像に対し、画像認識処理を行うことにより、ユーザの指が人差し指のみ立てた状態であるか、ユーザの指がはじくような動きをしたかを検出する。（４）プロセッサ１０は、カメラ１７の撮影画像の画像認識結果、および、測距センサ１８の出力値等の少なくともいずれか１つに基づいて、ユーザ端末１００の近傍の物体１０１０（ユーザの手など）とユーザ端末１００との距離を検出する。例えば、プロセッサ１０は、カメラ１７の撮影画像から特定されるユーザの手の形状の大小により、ユーザの手がユーザ端末１００の近傍（例えば所定値未満の距離）にあるのか、遠く（例えば所定値以上の距離）にあるのかを検出する。なお、撮影画像が動画の場合、プロセッサ１０は、ユーザの手がユーザ端末１００に接近しているのか遠ざかっているのかを検出してもよい。（５）カメラ１７の撮影画像の画像認識結果等に基づいて、ユーザの手が検出されている状態で、ユーザ端末１００とユーザの手との距離が変化していることが判明した場合、プロセッサ１０は、ユーザが手をカメラ１７の撮影方向において振っていると認識する。カメラ１７の撮影範囲よりも指向性が強い測距センサ１８において、物体が検出されたりされなかったりする場合に、プロセッサ１０は、ユーザが手をカメラの撮影方向に直交する方向に振っていると認識する。

このように、プロセッサ１０は、カメラ１７の撮影画像に対する画像認識により、ユーザが手を握りこんでいるか否か（「グー」のジェスチャであるか、それ以外のジェスチャ（例えば「パー」）であるか）を検出する。また、プロセッサ１０は、ユーザの手の形状とともに、ユーザがこの手をどのように移動させているかを検出する。また、プロセッサ１０は、ユーザがこの手をユーザ端末１００に対して接近させているのか遠ざけているのかを検出する。このような操作は、例えば、マウスまたはタッチパネルなどのポインティングデバイスを用いた操作に対応させることができる。ユーザ端末１００は、例えば、ユーザの手の移動に応じて、タッチスクリーン１５においてポインタを移動させ、ユーザのジェスチャ「グー」を検出する。この場合、ユーザ端末１００は、ユーザが選択操作を継続中であると認識する。選択操作の継続とは、例えば、マウスがクリックされて押し込まれた状態が維持されること、または、タッチパネルに対してタッチダウン操作がなされた後タッチされた状態が維持されることに対応する。また、ユーザ端末１００は、ユーザのジェスチャ「グー」が検出されている状態で、さらにユーザが手を移動させると、このような一連のジェスチャを、スワイプ操作（またはドラッグ操作）に対応する操作として認識することもできる。また、ユーザ端末１００は、カメラ１７の撮影画像によるユーザの手の検出結果に基づいて、ユーザが指をはじくようなジェスチャを検出した場合に、当該ジェスチャを、マウスのクリックまたはタッチパネルへのタップ操作に対応する操作として認識してもよい。

＜ゲームシステム１の概要＞
ゲームシステム１に基づくゲームは、ユーザが操作対象とする第１のキャラクタと、第１のキャラクタと戦闘する対象となる第２のキャラクタとを戦闘させるゲームである。以降、第１のキャラクタを、操作キャラクタと記載する。また、第２のキャラクタを、敵キャラクタと記載する。

また、ゲームシステム１に基づくゲームは、ユーザのタッチスクリーン１５に対する連続した操作に応じて、操作キャラクタに連続したアクションを実行させることが可能なゲームである。そのようなゲームの一例としては、操作キャラクタが敵キャラクタと戦闘する際にコンボアクションを実行するアクションゲームが挙げられる。また、そのようなアクションゲームを含むＲＰＧ（Role-Playing Game）が挙げられる。また、そのようなＲＰＧは、一例として、複数のユーザが各自のユーザ端末を介して同時に１つのゲーム空間に参加するＭＭＯＲＰＧ（Massively Multiplayer Online Role-Playing Game）であってもよい。また、そのようなＭＭＯＲＰＧは、一例として、操作キャラクタが仮想的なゲーム空間内を自由に移動可能なオープンワールドのゲームであってもよい。ただし、ゲームシステム１に基づくゲームは、これらの例示したタイプのゲームに限定されない。

また、ゲームシステム１によって実行されるゲームでは、権利アイテムが、ユーザに関連付けられる。以降、権利アイテムがユーザに関連付けられることを、付与される、とも記載する。本実施形態では、権利アイテムは、当該ゲームにおいて利用可能なオブジェクト群のうち１以上のオブジェクトを取得する権利を表す。オブジェクト群は、操作キャラクタになり得るキャラクタを含む。また、オブジェクト群は、サブキャラクタを含む。サブキャラクタとは、操作キャラクタと共に敵キャラクタと戦うキャラクタである。

また、ゲームシステム１によって実行されるゲームでは、ユーザは、権利アイテムを、１以上保有することができる。保有される権利アイテムのうち何れかの権利アイテムが消費されることにより、当該権利アイテムに応じた１以上のオブジェクトが、ユーザに付与される。保有される権利アイテムのうち消費される権利アイテムは、後述する第１の抽選により決定される。また、権利アイテムの消費により付与される１以上のオブジェクトは、後述する第２の抽選により、上述したオブジェクト群の中から決定される。

また、ゲームシステム１によって実行されるゲームでは、操作キャラクタと敵キャラクタとの戦闘内容に基づいて、権利アイテムを消費可能とするための第１の条件が満たされたか否かが判定される。第１の条件が満たされた場合に、ユーザによって保有される１以上の権利アイテムのうち、第１の抽選により、少なくとも何れかが特定される。そして、特定された権利アイテムが消費されると、当該権利アイテムに応じたオブジェクトが第２の抽選により決定され、決定されたオブジェクトがユーザに付与される。

ここで、第１の条件は、ユーザに付与されるポイントの合計が、所定値に達することであってもよい。ポイントは、敵キャラクタとの戦闘内容に応じてユーザに付与される。以降、敵キャラクタとの戦闘内容に応じてユーザに付与されるポイントを、戦闘ポイントとも記載する。本実施形態では、ユーザに付与された戦闘ポイントの合計が所定値に到達すると、第１の抽選が行われる。

なお、上述した第１の抽選は、第１の条件が満たされた場合に加えて、ユーザに関連付けられた消費アイテムの所定量と引き換えに、行われてもよい。この場合、ゲームシステム１によって実行されるゲームでは、消費アイテムがユーザに関連付けられる。消費アイテムとは、例えば、ゲームにおける仮想通貨であるが、これに限られない。

また、ゲームシステム１によって実行されるゲームでは、権利アイテムは、操作キャラクタと敵キャラクタとの戦闘の実行に応じて付与される。例えば、権利アイテムは、敵キャラクタに勝利したか否かに応じて付与されてもよい。この場合、権利アイテムは、敵キャラクタに勝利する度に付与されてもよいし、複数の敵キャラクタに勝利した場合に付与されてもよい。また、例えば、権利アイテムは、敵キャラクタに勝利するまでの過程で所定の条件が満たされたか否かに応じて付与されてもよい。本実施形態では、権利アイテムは、操作キャラクタが敵キャラクタとの戦闘に勝利した場合に付与されるものとする。なお、権利アイテムは、戦闘の実行に応じて付与されることに加えて、ゲームにおいて設定された他の達成条件が達成された場合に付与されてもよい。

また、ゲームシステム１によって実行されるゲームでは、ユーザに付与される権利アイテムは、操作キャラクタと戦闘した敵キャラクタに応じたものであってもよい。敵キャラクタに応じた権利アイテムとは、当該権利アイテムの消費に応じて、当該敵キャラクタに応じたキャラクタが確率的に付与される権利アイテムである。すなわち、敵キャラクタに応じたキャラクタを含むオブジェクト群の中から、第２の抽選により、消費する権利アイテムに応じたオブジェクトが決定される。ここで、敵キャラクタに応じたキャラクタとは、当該敵キャラクタと同グループのキャラクタであってもよい。キャラクタのグループについては後述する。

また、ゲームシステム１によって実行されるゲームでは、消費する権利データに応じたオブジェクトとして、上述した操作キャラクタになり得るキャラクタが、ユーザに確率的に付与される。また、消費する権利データに応じたオブジェクトとして、上述したサブキャラクタになり得るキャラクタが、ユーザに確率的に付与される。また、消費する権利データに応じたオブジェクトとして、キャラクタ以外のゲームにおいて利用可能なアイテムが、ユーザに確率的に付与される。すなわち、操作キャラクタになり得るキャラクタ、サブキャラクタになり得るキャラクタ、及び、キャラクタ以外のゲームにおいて利用可能なアイテムを含むオブジェクト群の中から、第２の抽選により、消費する権利データに応じたオブジェクトが決定される。

また、ゲームシステム１によって実行されるゲームでは、権利アイテムには、その希少度が関連付けられる。権利アイテムの希少度は、当該権利アイテムに応じて取得できる可能性があるキャラクタの希少度に基づくものである。ここで、キャラクタの希少度とは、ゲームを有利に進める上でキャラクタの価値の高さを表すものである。換言すると、希少度が高いキャラクタを利用するほど、ゲームをより有利に進めることができる。例えば、本実施形態では、キャラクタの希少度を、価値の高い順にＡ、Ｂ、Ｃで表すものとし、権利アイテムの希少度を、Ｓ、Ａ、Ｂ、Ｃで表すものとする。希少度Ａの権利アイテムは、当該権利アイテムに応じて希少度Ａのキャラクタが取得できる可能性が、他の希少度の権利アイテムより高く設定されたものである。同様に、希少度Ｂの権利アイテムは、当該権利アイテムに応じて希少度Ｂのキャラクタが取得できる可能性が、他の希少度の権利アイテムより高く設定されたものである。同様に、希少度Ｃの権利アイテムは、当該権利アイテムに応じて希少度Ｃのキャラクタが取得できる可能性が、他の希少度の権利アイテムより高く設定されたものである。また、希少度Ｘの権利アイテムは、何れかの希少度のキャラクタが必ず取得でき、キャラクタ以外のアイテムが取得される可能性がないよう設定されたものである。ただし、権利アイテムの希少度は、当該権利アイテムに応じて取得できる可能性があるキャラクタの希少度に基づいていればよく、上述した希少度に限られない。

また、ゲームシステム１によって実行されるゲームでは、権利アイテムには、当該権利アイテムによって取得できる可能性があるキャラクタのグループが関連付けられる。ここで、ゲームにおいて利用可能なキャラクタは、グループに分類できるものとする。一例として、ドラゴンＸ１、ドラゴンＸ２、ドラゴンＸ３との名称でそれぞれ識別されるキャラクタは、グループＸに分類される。また、ドラゴンＹ１、ドラゴンＹ２との名称でそれぞれ識別されるキャラクタは、グループＹに分類される。ただし、キャラクタの名称及びグループは、上述した例に限られない。

また、同一グループに分類されるキャラクタには、希少度が異なるものが含まれていてもよい。例えば、上述した例では、グループＸにおいて、ドラゴンＸ１は希少度Ａであり、ドラゴンＸ２は希少度Ｂであり、ドラゴンＸ３は希少度Ｃであってもよい。また、上述したグループＹにおいて、ドラゴンＹ１は希少度Ｂであり、ドラゴンＹ２は希少度Ｃであってもよい。ただし、同一グループに分類されるキャラクタには、必ずしも希少度が異なるものが含まれていなくてもよい。

このように、権利アイテムには、希少度及びグループが関連付けられる。以降、権利アイテムに関連付けられた希少度及びグループの組み合わせを、権利アイテムの種類とも記載する。上述した例では、権利アイテムの種類には、「グループＸで希少度Ｓ」という種類、「グループＹで希少度Ｃ」という種類、等がある。

また、ゲームシステム１によって実行されるゲームでは、ユーザに付与された権利アイテムは、当該権利アイテムに応じて取得可能なキャラクタのグループを認識可能な態様で表示部１５２に表示される。本実施形態では、ユーザに付与された権利アイテムは、当該権利アイテムの種類（グループ及び希少度）を認識可能な態様で表示される。

また、ゲームシステム１によって実行されるゲームでは、操作キャラクタは、当該操作キャラクタによって使用可能なアクション、又は、ユーザによって保有されるキャラクタのうち、当該操作キャラクタと同グループの他のキャラクタによって使用可能なアクションを実行することができる。換言すると、同グループのキャラクタ間で、使用可能なアクションが共有される。

また、ゲームシステム１によって実行されるゲームでは、操作キャラクタになり得るキャラクタ毎に、コンボアクションの編集画面が提供される。編集画面は、操作部に対する連続する操作よりなる操作列に含まれる各操作に対して、当該操作の操作列における順序に応じたアクションを関連付ける機能を有する。操作キャラクタは、敵キャラクタとの戦闘の際に、連続する操作に応じて、当該操作に対してその順序に応じて編集画面で関連付けられたアクションを実行する。なお、操作列に含まれる編集可能な操作の数は、同グループのキャラクタ間では、希少度がより低いキャラクタほど多くてもよい。

＜ゲームシステム１の機能的構成＞
図２は、ゲームシステム１に含まれるサーバ２００およびユーザ端末１００の機能的構成を示すブロック図である。サーバ２００およびユーザ端末１００のそれぞれは、図示しない、一般的なコンピュータとして機能する場合に必要な機能的構成、および、ゲームにおける公知の機能を実現するために必要な機能的構成を含み得る。

ユーザ端末１００は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末１００は、プロセッサ１０、メモリ１１、ストレージ１２、通信ＩＦ１３、および入出力ＩＦ１４等の協働によって、制御部１１０および記憶部１３０として機能する。

サーバ２００は、各ユーザ端末１００と通信して、ユーザ端末１００がゲームを進行させるのを支援する機能を有する。例えば、有価データの販売、サービスの提供などを実行する。ゲームがマルチプレイゲームである場合には、サーバ２００は、ゲームに参加する各ユーザ端末１００と通信して、ユーザ端末１００同士のやりとりを仲介する機能を有していてもよい。サーバ２００は、プロセッサ２０、メモリ２１、ストレージ２２、通信ＩＦ２３、および入出力ＩＦ２４等の協働によって、制御部２１０および記憶部２３０として機能する。

記憶部１３０および記憶部２３０は、ゲームプログラム１３１、ゲーム情報１３２およびユーザ情報１３３を格納する。ゲームプログラム１３１は、ユーザ端末１００およびサーバ２００で実行するゲームプログラムである。ゲーム情報１３２は、制御部１１０および制御部２１０がゲームプログラム１３１を実行する際に参照するデータである。ユーザ情報１３３は、ユーザのアカウントに関するデータである。記憶部２３０において、ゲーム情報１３２およびユーザ情報１３３は、ユーザ端末１００ごとに格納されている。

（サーバ２００の機能的構成）
制御部２１０は、記憶部２３０に格納されたゲームプログラム１３１を実行することにより、サーバ２００を統括的に制御する。例えば、制御部２１０は、ユーザ端末１００に各種データおよびプログラム等を送信する。制御部２１０は、ゲーム情報もしくはユーザ情報の一部または全部をユーザ端末１００から受信する。ゲームがマルチプレイゲームである場合には、制御部２１０は、ユーザ端末１００からマルチプレイの同期の要求を受信して、同期のためのデータをユーザ端末１００に送信してもよい。

制御部２１０は、ゲームプログラム１３１の記述に応じて、オブジェクト提供部２１１として機能する。制御部２１０は、実行するゲームの性質に応じて、ユーザ端末１００におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。

オブジェクト提供部２１１は、消費すべき権利アイテムを表す情報がユーザ端末１００から通知されると、ユーザに付与するオブジェクトを第２の抽選により決定する。第２の抽選は、当該権利アイテムの種類に基づいて実行される。

第２の抽選について説明する。記憶部２３０に記憶されるゲーム情報１３２は、権利アイテムの種類に関連付けて、出現確率を表す情報を含んでいる。

出現確率は、オブジェクト群を構成するオブジェクト各々が抽選される確率によって構成される。例えば、上述した例では、「グループＸで希少度Ａ」の種類に関連付けて、グループＸで希少度Ａの各キャラクタが抽選される確率の合計が、他の種類より高くなるよう出現確率が記憶される。また、「グループＹで種類Ｓ」の種類に関連付けて、グループＹで各希少度のキャラクタが抽選される確率の合計が１００％となるよう出現確率が記憶される。なお、権利アイテムの種類に対して関連付けられた出現確率において、各オブジェクトが抽選される確率の合計は、１００％となるよう設定される。また、このような出現確率は、更新され得る。例えば、出現確率は、特定の期間において、当該期間限定で取得可能となるオブジェクトが抽選される確率を含むよう更新されてもよい。

また、オブジェクト提供部２１１は、ゲーム情報１３２を参照することにより、ユーザ端末１００から通知された権利アイテムの種類に関連付けられた出現確率を取得する。そして、オブジェクト提供部２１１は、当該出現確率に基づいて、オブジェクト群の中から第２の抽選を行い、ユーザに付与するオブジェクトを決定する。本実施形態では、第２の抽選によって決定されるオブジェクトの個数は、１つであるものとする。ただし、第２の抽選によって決定されるオブジェクトの個数は、複数であってもよい。また、第２の抽選によって決定されるオブジェクトの個数は、個数を決定するための抽選により決定されてもよい。

（ユーザ端末１００の機能的構成）
制御部１１０は、記憶部１３０に格納されたゲームプログラム１３１を実行することにより、ユーザ端末１００を統括的に制御する。例えば、制御部１１０は、ゲームプログラム１３１およびユーザの操作にしたがって、ゲームを進行させる。また、制御部１１０は、ゲームを進行させている間、必要に応じて、サーバ２００と通信して、情報の送受信を行う。

制御部１１０は、ゲームプログラム１３１の記述に応じて、操作受付部１１１、表示制御部１１２、ユーザインターフェース（以下、ＵＩ）制御部１１３、アニメーション生成部１１４、ゲーム実行部１１５、カメラ配置制御部１１６、報酬決定部１１７、取得準備部１１８、取得実行部１１９、編集画面生成部１２０及び連続操作判定部１２１として機能する。制御部１１０は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。

操作受付部１１１は、入力部１５１に対するユーザの入力操作を検知し受け付ける。操作受付部１１１は、タッチスクリーン１５およびその他の入出力ＩＦ１４を介したコンソールに対してユーザが及ぼした作用から、いかなる入力操作がなされたかを判別し、その結果を制御部１１０の各要素に出力する。

例えば、操作受付部１１１は、入力部１５１に対する入力操作を受け付け、該入力操作の入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部１１１は、入力操作の種類として、例えばタッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。また、操作受付部１１１は、連続して検知されていた入力が途切れると、タッチスクリーン１５から接触入力が解除されたことを検知する。

ＵＩ制御部１１３は、ＵＩを構築するために表示部１５２に表示させるＵＩオブジェクトを制御する。ＵＩオブジェクトは、ユーザが、ゲームの進行上必要な入力をユーザ端末１００に対して行うためのツール、または、ゲームの進行中に出力される情報をユーザ端末１００から得るためのツールである。ＵＩオブジェクトは、これには限定されないが、例えば、アイコン、ボタン、リスト、メニュー画面などである。

アニメーション生成部１１４は、各種オブジェクトの制御態様に基づいて、各種オブジェクトのモーションを示すアニメーションを生成する。例えば、アニメーション生成部１１４は、操作キャラクタがアクションを実行する様子を表現したアニメーションを生成する。もし、アクションが敵キャラクタに対する攻撃であれば、アニメーション生成部１１４は、操作キャラクタの攻撃前の準備モーションを表すアニメーションと、攻撃モーションを表すアニメーションと、攻撃後の戻りモーションを表すアニメーションとを生成する。また、例えば、アニメーション生成部１１４は、操作キャラクタのアクションにより敵キャラクタが作用を受けた様子（やられモーション）を表すアニメーションを生成する。

また、例えば、アニメーション生成部１１４は、第１の抽選、第２の抽選が実行されている様子を表現したアニメーション等を生成してもよい。

表示制御部１１２は、タッチスクリーン１５の表示部１５２に対して、各機能ブロックによって実行された処理結果が反映されたゲーム画面を出力する。例えば、表示制御部１１２は、ゲーム空間のうち、カメラ配置制御部１１６が規定する仮想カメラの視野の領域と、当該領域に存在するオブジェクトとを描画したゲーム画面を生成する。また、表示制御部１１２は、アニメーション生成部１１４によって生成されたアニメーションを含むゲーム画面を出力する。また、表示制御部１１２は、上述のＵＩオブジェクトを、該ゲーム画面に重畳して描画してもよい。

なお、以降、操作受付部１１１によって入力部１５１に対する入力操作が検知され受け付けられることを、単に、入力操作が受け付けられる、とも記載する。また、他の機能ブロックが、各種のゲーム画面を表示制御部１１２によって表示部１５２に出力することを、単に、表示する、とも記載する。

ゲーム実行部１１５は、操作キャラクタに、ユーザの入力操作に基づいて、操作キャラクタが使用可能なアクション、又は、ユーザによって保有されるキャラクタのうち、操作キャラクタと同グループの他のキャラクタによって使用可能なアクションを実行させる。

また、ゲーム実行部１１５は、ユーザの操作に基づくアクションを、ゲーム空間に存在する操作キャラクタに実行させることにより、ゲームを進行させる。本実施形態では、ゲームは、操作キャラクタが敵キャラクタと戦闘することにより進行する。操作キャラクタは、敵キャラクタとの戦闘においてアクションを実行して敵キャラクタの体力を減らし、敵キャラクタの体力が無くなると戦闘に勝利するものとする。操作キャラクタに実行させるアクションの内容は、後述の連続操作判定部１２１によって決定される。アクションの種類としては、例えば、敵キャラクタに対して作用を与えるアクション、操作キャラクタ自身の移動、サブキャラクタのゲーム空間への召喚等があるが、これらに限られない。また、敵キャラクタに対して作用を与えるアクションとしては、敵キャラクタに対する攻撃、敵キャラクタの属性を変化させるアクション等があるが、これらに限られない。敵キャラクタに対する攻撃としては、敵キャラクタを所定距離ふきとばす技、よろけさせて所定期間行動不能にさせる技等があるが、これに限られない。また、変化させる敵キャラクタの属性としては、例えば、攻撃力、防御力、命中率、移動速度等が挙げられるが、これらに限られない。

また、ゲーム実行部１１５は、決定したアクションを、アニメーション生成部１１４に通知する。また、ゲーム実行部１１５は、操作キャラクタの移動に伴い、ゲーム空間における操作キャラクタの位置または向いている方向に変化があると、当該位置または方向を、後述のカメラ配置制御部１１６に通知する。

また、ゲーム実行部１１５は、上述したアクションによって敵キャラクタが攻撃されたと判定した場合、攻撃結果を決定する。攻撃結果は、例えば、敵キャラクタに与えるダメージ値、ダメージ値を与えたあとの敵キャラクタの体力値、敵キャラクタを倒したか否か（敵キャラクタの体力値が０以下になったか否か）、敵キャラクタを倒した場合に付与される権利アイテムがあるか否か、敵キャラクタとの戦闘内容に応じたポイントの付与があるか否か等を含む。

戦闘ポイントは、例えば、操作キャラクタのレベル及び敵キャラクタのレベルに応じて付与される。具体的には、ゲーム実行部１１５は、操作キャラクタが敵キャラクタとの戦闘に勝利したとき、操作キャラクタのレベルと敵キャラクタのレベルとの大小関係、および、これらのレベルの差を特定する。そして、特定したレベルの大小関係および差に基づいて、戦闘ポイントの量を決定する。このとき、ゲーム実行部１１５は、操作キャラクタが戦闘に勝利した敵キャラクタのレベルが高ければ、戦闘ポイントの値が大きくなり、反対に敵キャラクタのレベルが低ければ、戦闘ポイントの値が小さくなるように、戦闘ポイントの値を決定してもよい。これにより、権利アイテムに応じたオブジェクトを取得するためには、ある程度の強さの敵キャラクタとの戦闘に勝利する必要がある。よって、強い敵キャラクタとの戦闘に勝利することによる獲得報酬によってゲームを有利に進めることができるという、ゲーム本来の魅力を損なうことなく、ゲームを進行させることができる。

ゲーム実行部１１５は例えば、操作キャラクタのレベルと敵キャラクタのレベルとが同じ場合、戦闘ポイントとして５戦闘ポイントをユーザに付与し、敵キャラクタのレベルが１上がるごとに、戦闘ポイントを１増やしてもよい。また、敵キャラクタのレベルが１下がるごとに、戦闘ポイントを１減らしてもよい。この例の場合、操作キャラクタのレベルより敵キャラクタのレベルが５以上低いと、付与される戦闘ポイントが０となる。換言すれば、この場合、ゲーム実行部１１５は戦闘ポイントをユーザに付与しない。なお、獲得される戦闘ポイントの値には上限が設定されていてもよい。これにより、少ない戦闘回数で権利アイテムが消費されてしまうという状況を防ぐことができる。

なお、戦闘によって獲得される戦闘ポイントの量は、操作キャラクタのレベルに関係なく、敵キャラクタのレベルのみに応じて決定されてもよい。また、操作キャラクタのレベルと敵キャラクタのレベルとに関係なく、一定の値であってもよい。また例えば、戦闘ポイントの値はランダムに決定されてもよい。

また、ゲーム実行部１１５は、操作キャラクタが敵キャラクタとの戦闘に勝利した場合、戦闘ポイントとは別のポイント（例えば、経験値）を操作キャラクタに付与してもよい。この経験値の合計が、操作キャラクタのレベルに応じて設定される所定値に到達したとき、操作キャラクタのレベルを１上げてもよい。また、ゲーム実行部１１５は、操作キャラクタと敵キャラクタとの戦闘時に、該操作キャラクタにアビリティを付与してもよい。例えば、操作キャラクタのアクションによって敵キャラクタに攻撃をヒットさせることに基づいて、操作キャラクタにアビリティを付与してもよい。また、例えば、操作キャラクタのアクションによって敵キャラクタに攻撃をヒットさせた回数が所定回数に達すること、敵キャラクタに与えたダメージ量が一定量を超えること、敵キャラクタとの戦闘に所定回数勝利することにより、操作キャラクタにアビリティを付与することとしてもよい。これにより、敵キャラクタとの戦闘で操作キャラクタを強化するという、ゲーム本来の魅力を損なうことなく、ゲームを進行させることができる。

ここで、ユーザに付与された戦闘ポイントの合計は、ユーザに関連付けられて記憶部１３０に記憶され、ユーザに戦闘ポイントが付与されると加算される。また、戦闘ポイントの合計が所定値に達した（第１の条件が満たされた）ことに応じて、ユーザによって消費可能な権利アイテム数が増加する。消費可能な権利アイテム数は、ユーザに関連付けられて記憶部１３０に記憶され、第１の条件が満たされると加算される。また、第１の条件を満たしたことに応じて権利アイテムが消費されると、消費可能な権利アイテム数は、減算される。

また、ゲーム実行部１１５は、ゲームを進行させるための各種の処理を、必要に応じてサーバ２００との通信を行いながら実行する。

カメラ配置制御部１１６は、ゲーム空間のうちユーザに提示する領域を指定するための仮想カメラを規定する。カメラ配置制御部１１６は、仮想カメラのゲーム空間内での位置および向きを規定することにより、仮想カメラをゲーム空間に仮想的に配置する。さらに、カメラ配置制御部１１６は、仮想カメラで規定される視野領域および当該視野領域に配置されているオブジェクトを描画した画像を作成するよう、後述の表示制御部１１２に指示する。

具体的には、例えば、カメラ配置制御部１１６は、ゲーム実行部１１５から通知される操作キャラクタの位置に基づいて、仮想カメラを操作キャラクタの後方に配置してもよい。この場合、カメラ配置制御部１１６は、仮想カメラの向きが、ゲーム実行部１１５から通知される操作キャラクタの向いている方向となるようにする。このように仮想カメラを制御することにより、ユーザは、操作キャラクタを移動させながら、操作キャラクタの視点でゲーム空間に臨むことができる。ただし、仮想カメラの配置及び向きの制御は、必ずしも上述した制御でなくてもよい。

報酬決定部１１７は、ユーザに付与する権利アイテムの個数、及び、各権利アイテムの種類を決定する。例えば、報酬決定部１１７は、操作キャラクタと敵キャラクタとの戦闘が終了した場合に、ユーザに付与する権利アイテムの個数、及び、各権利アイテムの種類を決定してもよい。なお、報酬決定部１１７がユーザに付与する権利アイテムを決定する処理は、戦闘が終了した場合に加えて、ゲームにおいて設定されたその他の達成条件が満たされた場合に行われてもよい。

例えば、報酬決定部１１７は、ゲーム実行部１１５から通知される戦闘内容に基づいて、付与する権利アイテムの個数を決定してもよい。また、報酬決定部１１７は、付与する各権利アイテムに対して、予め設定された設定確率に基づいて、その種類を設定する。例えば、権利アイテムの希少度がより高い種類ほど、設定確率が低くなるよう定められている。また、報酬決定部１１７は、付与する各権利アイテムに対して、有効期間を設定する。有効期間は、権利アイテムの種類に対して、予め関連付けられていてもよい。その場合、有効期間は、権利アイテムの希少度がより高い種類ほど、短くなるよう定められる。付与時からの経過時間が有効期間を超えた権利アイテムは、ユーザに付与された権利アイテムの群から削除される。以降、ユーザに付与された権利アイテムの群を、保有権利アイテム群とも記載する。

また、ユーザが保有し得る権利アイテムの個数には上限が設定されている。保有権利アイテム群を構成する権利アイテムの個数が上限に達している場合、報酬決定部１１７は、戦闘が終了した場合でも、権利アイテムの付与を行わないようにしてもよい。あるいは、権利アイテムの個数が上限に達している場合、報酬決定部１１７は、上述のようにして付与する権利アイテムを決定した上で、付与予定の権利アイテムとして保存してもよい。なお、付与予定の権利アイテムは、保有権利アイテム群を構成する権利アイテムの個数が変化して上限より少なくなれば、任意の時点で保有権利アイテム群に加えられてもよい。ただし、その場合でも、権利アイテムに設定される有効期間は、付与予定となった時点からカウントされるようにしてもよい。

取得準備部１１８は、操作キャラクタと敵キャラクタとの戦闘内容に基づいて、権利アイテムを消費可能とするための第１の条件が満たされたか否かを判定する。本実施形態では、第１の条件は、前述した戦闘ポイントの合計が所定値に達することである。ただし、第１の条件は、戦闘内容に基づく条件であれば、これらの例に限られない。

また、取得準備部１１８は、第１の条件が満たされた場合に、第１の抽選により、保有権利アイテム群のうち少なくとも何れかを特定する。第１の抽選は、保有権利アイテム群の何れかがランダムに特定される抽選であってもよい。換言すると、第１の抽選において、保有権利アイテム群を構成する各々が特定される確率は、同一であってもよい。ただし、各権利アイテムが特定される確率は、必ずしも同一でなくてもよく、重み付けがなされていてもよい。なお、各権利アイテムが特定される確率に重み付けがなされている場合であっても、そのような重み付けは、権利アイテムがユーザに付与された時期に基づく重み付けではないことが望ましい。

このように、本実施形態では、保有権利アイテム群のうち付与された時期が古い順に、消費対象として特定されていくわけではなく、ランダムな順で特定されていく。したがって、ユーザは、所望の権利アイテムを消費したい場合に、当該権利アイテムより古い権利アイテムを消費する必要が無く、ゲームの興趣性が向上する。

また、取得準備部１１８は、消費アイテムと引き換えに、第１の抽選を行う場合もある。この場合、取得準備部１１８は、保有権利アイテム群における各種類の権利アイテムが占める割合をユーザに提示した上で、消費アイテムと引き換えに第１の抽選を指示する操作を受け付けることが望ましい。以下では、保有権利アイテム群における各種類の権利アイテムが占める割合を、「保有権利アイテム群における各種類の割合」とも記載する。これにより、ユーザは、保有権利アイテム群における各種類の割合を考慮して、任意の時点で抽選を指示することができる。例えば、ユーザは、保有権利アイテム群において、所望の種類の権利アイテムが占める割合が多いと考えた時点で、抽選を指示することができる。このように、ユーザは、所望する種類の権利アイテムが消費される可能性を高めることに介入することができる。

また、取得準備部１１８は、消費アイテムと引き換えに、保有権利アイテム群の全て又は一部分を一括して消費してもよい。この場合、一括して消費するために要する消費アイテムの量は、一括して消費する対象となる権利アイテム群における各種類の割合に応じて設定されてもよい。また、一括して消費するために要する消費アイテムの量は、一括して消費する対象となる権利アイテムの数に応じて設定されてもよい。なお、一括して消費するために要する消費アイテムの量は、一括して消費する対象となる個数の権利アイテムの各々に対して、個別に第１の抽選を行うのに必要な消費アイテムの量の合計より少なくてもよい。

また、取得準備部１１８は、第１の抽選を実行すると、第１の抽選により決定した権利アイテムに関する情報を、取得実行部１１９に通知する。

また、取得準備部１１８は、消費アイテムと引き換えに一括して消費する操作を受け付けた場合に、保有権利アイテム群を構成する各権利アイテムの種類を、一括して取得実行部１１９に通知する。

取得実行部１１９は、取得準備部１１８によって決定された権利アイテムに応じたオブジェクトの決定を、サーバ２００に要求する。具体的には、取得実行部１１９は、決定された権利アイテムの種類をサーバ２００に通知する。前述したように、サーバ２００において、オブジェクト提供部２１１は、通知された種類に応じた第２の抽選を実行することによりオブジェクトを決定し、取得実行部１１９に通知する。

また、取得実行部１１９は、抽選された権利アイテムに応じたオブジェクトを通知されると、当該権利アイテムを、消費されたものとして保有権利アイテム群から削除する。

編集画面生成部１２０は、連続する操作よりなる操作列に含まれる各操作に対して、該操作の操作列における順序に応じたアクションを関連付ける編集画面を生成する。なお、本実施形態では、１つの操作列は、連続する同種類の操作の列であるものとする。以降、操作列に含まれる各操作に対して順序に応じたアクションが関連付けられた情報を、操作列情報とも記載する。また、各操作に対して順序に応じたアクションを関連付けることを、操作列情報を編集する、とも記載する。編集画面生成部１２０の詳細については後述する。

連続操作判定部１２１は、タッチスクリーン１５に対する操作が前回の操作に続いているか否かを判定する。また、連続操作判定部１２１は、前回の操作に今回の操作が続いていると判定した場合には、操作列情報を参照することにより、今回の操作に応じて操作キャラクタに実行させるアクションを決定する。連続操作判定部１２１の詳細については後述する。

（操作の種類）
操作受付部１１１により特定される操作の種類の詳細について説明する。本実施形態では、操作の種類として、タップ操作、上フリック操作、下フリック操作、左右フリック操作及び回転操作があるものとする。タップ操作の検出手法については、公知の手法を適用可能である。

ここでは、まず、上フリック操作、下フリック操作及び左右フリック操作の検出手法について説明する。これらの操作は、それぞれ、フリック操作の方向に基づき検出される。フリック操作自体の検出手法については、公知の手法を適用可能である。ここで、上、下、左右の各方向は、表示部１５２において任意に定めることが可能である。例えば、表示部１５２に表示されたゲーム空間においてキャラクタが向いている方向（すなわち、仮想カメラが向いている方向）を、上方向としてもよい。この場合、上方向を定めることにより、上方向の反対方向を、下方向と定めることができる。また、上方向を９０度左（または右）回転させた方向を、左（または右）方向と定めることができる。

この場合、操作受付部１１１は、フリック操作の方向が、上方向を基準として所定角度の範囲に含まれる場合に、上フリック操作として検出する。これにより、操作キャラクタが向いている方向へのフリック操作が、上フリック操作として検出される。また、操作受付部１１１は、フリック操作の方向が、下方向を基準として所定角度の範囲に含まれる場合に、下フリック操作として検出する。これにより、操作キャラクタの後ろに向かう方向へのフリック操作が、下フリック操作として検出される。また、操作受付部１１１は、フリック操作の方向が、左（または右）方向を基準として所定角度の範囲に含まれる場合に、左右フリック操作として検出する。これにより、操作キャラクタの横方向に向かうフリック操作が、左右フリック操作として検出される。

次に、回転操作の検出手法について説明する。回転操作とは、ドラッグ操作における物体１０１０の接触位置（すなわち、タッチ位置）の軌跡がリング状またはほぼリング状となる操作をいうものとする。なお、回転操作の軌跡が描くリングは閉じていなくてもよい。また、回転操作におけるドラッグ操作の開始位置と終了位置とは、一致していなくてもよい。例えば、回転操作は、所定期間におけるドラッグ操作のベクトル成分の変化を検知することにより特定可能である。ただし、回転操作の特定手法は、これに限られない。

（連続操作判定部１２１の詳細）
連続操作判定部１２１の詳細について説明する。連続操作判定部１２１は、前述したように、ある操作が、前回の操作に連続しているか否かを判定する。前回の操作に続いているとは、今回の操作が、前回の操作に基づく操作キャラクタの一連のモーションが開始してから一定期間内に行われたことをいう。ここで、前回の操作に基づく操作キャラクタの一連のモーションが開始してからの一定期間内として、例えば、前回の操作に基づいて操作キャラクタが攻撃のための準備モーションを行っている期間としてもよいし、戻りモーションを終えるまでの間としてもよいし、戻りモーションを終えてからも所定の時間内において操作を受け付けることとしてもよい。例えば、ある操作が、前回の操作に基づく操作キャラクタの一連のモーションが終わる前に行われたこととしてもよい。

すなわち、連続操作判定部１２１は、今回の操作が、前回の操作に基づく操作キャラクタの一連のモーションが開始してから一定期間内に行われたか否かを判断すればよい。例えば、ある操作が、前回の操作に基づく操作キャラクタの攻撃前の準備モーションを表すアニメーションが行われている間に行われた場合に、連続操作判定部１２１は、ある操作が、前回の操作に連続していると判定してもよい。また、ある操作が、前回の操作に基づく操作キャラクタの戻りモーションが終わってから一定期間が経過するまでの間に行われた場合に、連続操作判定部１２１は、ある操作が、前回の操作に連続していると判定してもよい。

また、連続操作判定部１２１は、連続していると判定したときに、前回及び今回の操作の種類に応じた操作列情報を参照して、実行すべきアクションを決定する。連続操作判定部１２１は、決定したアクションを、ゲーム実行部１１５に通知する。

具体的に、まず、前回及び今回の操作の種類が同一であった場合について説明する。この場合、連続操作判定部１２１は、今回の操作が、当該種類の操作の何番目であるか（すなわち、順序ｉ）をカウントする。順序ｉのカウントは、連続していると判定する度に、操作の種類を履歴として記憶しておくことで算出可能である。なお、連続操作判定部１２１は、操作の種類の履歴を、連続していないと判定した時点でクリアしてもよい。そして、連続操作判定部１２１は、今回の操作の種類に関する操作列情報を参照し、今回の順序ｉの操作に関連付けられたアクションを、次に実行すべきアクションとして決定する。なお、今回の順序ｉが、操作列情報における編集可能数Ｍを超えている場合について説明する。この場合、本実施形態では、連続操作判定部１２１は、これ以上連続した操作は不可能であるとして、次に実行すべきアクションを決定しないものとする。すなわち、同じ種類の操作は、連続数が編集可能数Ｍを超えた時点以降、当該操作が前回の操作に連続していないと判定されるまで、無効となる。これにより、本実施形態は、ユーザに対して、できるだけ複数の種類の操作列をつなげた操作を行うよう促すことができる。

ただし、連続数が編集可能数Ｍを超えている場合の処理は、上述したような操作を無効とする処理に限られない。例えば、この場合、連続操作判定部１２１は、順序を１にリセットして、操作列情報の１段目のアクションを、次に実行すべきアクションとして決定してもよい。この場合、ユーザは、同種類の操作を連続して行うと、連続数に上限なく、連続数の分だけ、次々と連続してアクションを繰り出すことが可能となる。

次に、前回及び今回の操作の種類が同一でなかった場合について説明する。この場合、連続操作判定部１２１は、今回の操作の種類の関する操作列情報を参照し、順序ｉの操作に関連付けられた１段目のアクションを、次に実行すべきアクションとして決定する。

ゲーム実行部１１５は、連続操作判定部１２１によって決定されたアクションが通知されると、前回の操作に基づくアクションに続いて今回の操作に基づくアクションを操作キャラクタに実行させるよう、他の各部に通知する。

例えば、前回の操作に基づくアクション及び今回の操作に基づくアクションが共に敵キャラクタに作用を与えるアクションである場合について例示的に説明する。敵キャラクタに作用を与えるアクションが、前述のように、準備モーションと、攻撃モーションと、戻りモーションとを含んでいたとする。このとき、今回の操作が、前回の操作に基づく技モーションの表示期間中であるとする。この場合、今回の操作に基づくアクションを操作キャラクタに開始させるタイミングとして、次の２つのパターンが考えられる。

１つ目のパターンでは、ゲーム実行部１１５は、操作キャラクタに、前回の操作による技モーションを終了させた後、続く戻りモーションをキャンセルして、今回の操作による準備モーションを開始させる。２つ目のパターンでは、ゲーム実行部１１５は、操作キャラクタに、前回の操作による技モーションをキャンセルさせ、直ちに今回の操作による準備モーションを開始させる。いずれの場合であっても、ゲーム実行部１１５は、操作キャラクタに、連続した操作に応じて、操作列情報に基づき決定したアクションを連続して実行させることができる。

＜ゲームシステム１の画面例＞
（ゲーム画面の具体例）
ゲーム実行部１１５によって生成されるゲーム画面の具体例について、図３（Ａ）及び（Ｂ）を参照して説明する。図３（Ａ）は、操作キャラクタと敵キャラクタとが戦闘中の画面を表し、戦闘ポイントオブジェクト３０１と、操作キャラクタ３０２と、敵キャラクタ３０３と、プレイヤキャラクタ３０４と、武器３０５とを含んでいる。なお、この例では、戦闘中の画面は、１つの敵キャラクタ３０３を含んでいるが、複数の敵キャラクタ３０３を含んでいてもよい。図３（Ｂ）は、敵キャラクタ３０３に勝利した後の画面を表し、戦闘ポイントオブジェクト３０１と、操作キャラクタ３０２と、プレイヤキャラクタ３０４と、武器３０５とを含んでいる。これらは、図３（Ａ）及び（Ｂ）において、それぞれ、ゲーム空間を表す背景の上に重畳して表示されている。また、図３（Ａ）及び（Ｂ）の画面は、さらに、サブキャラクタ（図示せず）を含む場合もある。

図３（Ａ）及び（Ｂ）のゲーム画面では、プレイヤキャラクタ３０４は、操作キャラクタ３０２に搭乗し、武器３０５を装備している。なお、これらのゲーム画面には、図示しないメニューやボタン等のＵＩオブジェクトがさらに含まれていてもよい。例えば、そのようなＵＩオブジェクトに対する操作に応じて、プレイヤキャラクタ３０４が搭乗する操作キャラクタ３０２は、ユーザによって保有される他のキャラクタに変更され得る。ただし、変更可能な他のキャラクタは、操作キャラクタになり得るキャラクタである。また、そのようなＵＩオブジェクトに対する操作に応じて、プレイヤキャラクタ３０４が使用する武器３０５は、ユーザによって保有される他の武器に変更され得る。また、そのようなＵＩオブジェクトに対する操作に応じて、サブキャラクタが召喚され得る。また、そのようなＵＩオブジェクトに対する操作に応じて、操作キャラクタ３０２と敵キャラクタ３０３との戦闘における各種設定が変更され得る。

また、図３（Ａ）及び（Ｂ）の例では、戦闘ポイントオブジェクト３０１は、ゲージ３０１ａを含む。また、戦闘ポイントオブジェクト３０１は、図３（Ｂ）に示すように、バッジ３０１ｂを含む場合もある。ゲージ３０１ａは、ユーザに関連付けられた戦闘ポイントの合計を表している。ゲージ３０１ａは、円環で表され、円環の一周分の長さが、戦闘ポイントが到達すべき所定値を表している。また、円環のうち所定の色で塗りつぶされた部分円環の長さが、ユーザに関連付けられた戦闘ポイントの合計を表している。部分円環の長さは、ユーザに戦闘ポイントが付与される度に更新される。バッジ３０１ｂは、消費可能な権利アイテム数を表している。ここでは、戦闘ポイントの合計が所定値に達すると、バッジ３０１ｂに表示される数値に１が加算されるとともに、戦闘ポイントの合計が０にリセットされるものとする。なお、戦闘ポイントの合計が０にリセットされると、ゲージ３０１ａの円環は、全周に渡って塗りつぶされていない状態となる。

また、バッジ３０１ｂが表示されていない状態（すなわち、消費可能な権利アイテム数が０である状態）で、戦闘ポイントオブジェクト３０１に対する入力操作が受け付けられると、ユーザによって保有される権利アイテムの一覧画面が表示される。権利アイテムの一覧画面については後述する。

また、バッジ３０１ｂに１以上の数値が表示されている状態で、戦闘ポイントオブジェクト３０１に対する入力操作が受け付けられると、第１の抽選を実行するか否かを指示する抽選指示画面が表示される。抽選指示画面については、後述する。抽選指示画面を経て権利データの何れかが消費されると、バッジ３０１ｂに表示される数値から１が減算される。

（消費アイテムと引き換えに実行される第１の抽選に関わる画面の具体例）
図４（Ａ）は、ユーザによって保有される権利アイテムの一覧画面である。この例では
、権利アイテムを、「クリスタル」と表現している。また、この例では、権利アイテムを消費することを、「クリスタルをふかする」と表現している。以降、権利アイテムの一覧画面を、クリスタル一覧画面とも記載する。図４（Ａ）に示すクリスタル一覧画面は、クリスタルの所持数を表示する表示領域４０１と、クリスタル表示枠４０２＿１～４０２＿１２と、ふかボタン４０５と、すてるボタン４０６とを含む。

以下、クリスタル表示枠４０２＿１～４０２＿１２の各々を、クリスタル表示枠４０２＿ｉ（ｉは１以上１２以下の自然数）とも記載する。この例では、ユーザによって保有可能な権利アイテムの数の上限は１２であるため、１２個のクリスタル表示枠４０２＿ｉが表示されている。

クリスタル表示枠４０２＿ｉは、クリスタルオブジェクト４０３と、クリスタルの有効期間を表示する表示領域４０４とを含み得る。ここで、クリスタルオブジェクト４０３は、当該クリスタルの種類（グループ及び希少度）を認識可能な態様で表示される。この例では、例えば、クリスタル表示枠４０２＿１に含まれるクリスタルオブジェクト４０３は、グループＸで希少度Ｓの種類であることが認識可能に表示されている。換言すると、このクリスタルオブジェクト４０３からは、グループＸで希少度Ｓのキャラクタを取得できる可能性が高いことが認識可能に表示されている。また、クリスタル表示枠４０２＿１に含まれる表示領域４０４は、当該クリスタルの有効期間が、残り１５分であることを表している。

この例では、クリスタルオブジェクト４０３及び表示領域４０４は、クリスタル表示枠４０２＿１～４０２＿４に含まれ、クリスタル表示枠４０２＿５～４０２＿１２に含まれていない。つまり、ユーザによって保有されるクリスタルの所持数は４である。したがって、表示領域４０１は、上限１２個のうち４個のクリスタルを保持していることを表す「４／１２」との表示を含んでいる。

ふかボタン４０５は、消費アイテムと引き換えに、保有されるクリスタルの１つを第１の抽選により特定して消費することを指示するＵＩオブジェクトである。

すてるボタン４０６は、消費アイテムと引き換えに、保有されるクリスタルの全てを破棄することを指示するＵＩオブジェクトである。

図４（Ｂ）に示す消費個数選択画面は、図４（Ａ）におけるふかボタン４０５に対する入力操作が受け付けられると、表示される。この消費個数選択画面は、ランダムに１つふかボタン４０７と、ぜんぶふかボタン４０８とを含む。ランダムに１つふかボタン４０７は、消費アイテムとの引き換えに、第１の抽選によりクリスタルを１つふかすることを指示するためのＵＩオブジェクトである。この例では、ランダムに１つふかボタン４０７には、ふかを実行するために必要となる消費アイテムの設定量として、「通貨１０」が記載されている。

ぜんぶふかボタン４０８は、消費アイテムとの引き換えに、ユーザによって保有されるクリスタルを一括してふかすることを指示するためのＵＩオブジェクトである。この例では、ぜんぶふかボタン４０８には、ふかを実行するために必要となる消費アイテムの設定量として、「通貨３５」が記載されている。このように、権利アイテムを一括して消費するために必要な消費アイテムの設定量は、個別に消費するために必要な消費アイテムの設定量の合計より少なく設定されていてもよい。

図４（Ｃ）に示すオブジェクト付与画面は、図４（Ｂ）においてランダムに１つふかボタン４０７に対する入力操作が受け付けられると、表示される。このオブジェクト付与画面は、第１の抽選により特定されたクリスタルに応じて、第２の抽選により決定されたオブジェクトを表している。また、このオブジェクト付与画面は、表示領域４０９と、表示領域４１０とを含む。表示領域４０９は、付与されたオブジェクト名が表示される領域である。表示領域４１０は、付与されたオブジェクトがキャラクタである場合に、その希少度が表示される領域である。図４（Ｃ）の例では、図４（Ａ）のクリスタル表示枠４０２＿１に表示されたグループＸで希少度Ｓのクリスタルオブジェクト４０３が示すクリスタルから、ドラゴンＸ１という名称で希少度Ａのキャラクタがふかし、付与されている。

図４（Ｄ）に示すクリスタル一覧画面は、図４（Ｃ）に続いて表示される。このクリスタル一覧画面からは、図４（Ｃ）で消費されたグループＸで希少度Ｓのクリスタルオブジェクト４０３が、図４（Ａ）で表示されていたクリスタル表示枠４０２＿１から削除されている。また、図４（Ａ）でクリスタル表示枠４０２＿２以降に表示されていた各クリスタルオブジェクト４０３は、クリスタル表示枠４０２＿１以降に順次繰り上げられて表示されている。また、表示領域４０１では、クリスタルの所持数が、図４（Ａ）に表示されていた「４／１２」に対して１減算され、「３／１２」になっている。

図５（Ａ）に示す抽選指示画面は、図３（Ｂ）のようにバッジ３０１ｂに１以上の数値が表示されている状態で、戦闘ポイントオブジェクト３０１に対する入力操作が受け付けられた場合に表示される。抽選指示画面は、戻るボタン５０１と、ふかするボタン５０２とを含む。戻るボタン５０１は、前画面（例えば、図３（Ｂ））に戻ることを指示するためのＵＩオブジェクトである。ふかするボタン５０２は、戦闘ポイントが所定値に到達したことに応じてクリスタルをふかすることを指示するためのＵＩオブジェクトである。

図５（Ｂ）に示すオブジェクト付与画面は、図５（Ａ）においてふかするボタン５０２に対する入力操作が受け付けられると、表示される。このオブジェクト付与画面は、図４（Ｃ）に示したオブジェクト付与画面と同様に、表示領域４０９と、表示領域４１０とを含む。これらの領域の詳細については、詳細な説明を繰り返さない。図５（Ｂ）の例では、図４（Ｃ）のクリスタル表示枠４０２＿２に表示されたグループＸで希少度Ｂのクリスタルオブジェクト４０３が示すクリスタルから、ドラゴンＸ２という名称で希少度Ｂのキャラクタがふかし、付与されている。

図５（Ｃ）に示すクリスタル一覧画面は、図５（Ｂ）に続いて表示される。このクリスタル一覧画面からは、図５（Ｂ）で消費されたグループＸで希少度Ｂのクリスタルオブジェクト４０３が、図４（Ｄ）で表示されていたクリスタル表示枠４０２＿２から削除されている。また、図４（Ｃ）でクリスタル表示枠４０２＿３に表示されていたクリスタルオブジェクト４０３は、クリスタル表示枠４０２＿２に繰り上げられて表示されている。また、表示領域４０１では、クリスタルの所持数が、図４（Ｃ）に表示されていた「３／１２」から１減算され、「２／１２」となっている。

（編集画面の具体例）
編集画面生成部１２０が生成する編集画面の具体例について説明する。編集画面は、操作列情報を編集するための画面である。なお、以下において、同種類の操作よりなる操作列の先頭からｉ（ｉ＝１，２，・・・・）番目の操作を、順序ｉの操作とも記載する。また、順序ｉの操作に関連付けられたアクションを、ｉ段目のアクションとも記載する。操作列情報は、詳細を後述する連続操作判定部１２１によって操作が連続していると判定されたときに参照される。ここで、ある種類の操作に続いて他の種類の操作がある場合には、ある種類の操作列情報に続いて他の種類の操作列情報が参照される。このため、ユーザは、各種類の操作列情報の組み合わせを考慮して編集を行うことで、連続する操作により連続して繰り出されるアクションを、より変化に富んだものとすることができる。

編集画面生成部１２０は、ユーザが保有するキャラクタ毎に、編集画面を生成する。なお、編集画面は、ユーザが保有するキャラクタのうち、操作キャラクタになり得るキャラクタ毎に生成され、サブキャラクタになり得るキャラクタについては、生成されないものとする。換言すると、キャラクタに対する連続する操作により連続して繰り出されるアクションは、操作キャラクタになり得るキャラクタについては編集できるが、サブキャラクタになり得るキャラクタについては編集できないものとする。以降、操作キャラクタになり得るキャラクタを、編集可能キャラクタとも記載する。

編集可能キャラクタとしては、ゲームの開始時に予めユーザに付与されているキャラクタがある。また、編集可能キャラクタとしては、ゲームの進行に伴い追加して付与されるキャラクタがある。例えば、編集可能キャラクタは、前述したように、ユーザに付与された権利アイテムが消費されることにより、当該権利アイテムに応じて第２の抽選により付与される場合がある。

編集画面の一例を図６（Ａ）及び（Ｂ）に示す。図６（Ａ）は、グループＸで希少度ＡのドラゴンＸ１に関する編集画面の一例である。図６（Ｂ）は、グループＸで希少度ＣのドラゴンＸ３に関する編集画面の一例である。

図６（Ａ）及び（Ｂ）において、編集画面は、操作の種類毎の操作列コンポーネント６０１と、アクションアイコン６１２の一覧とを含む。この例では、５種類の操作（タップ操作、上フリック操作、下フリック操作、左右フリック操作及び回転操作）のそれぞれの操作列コンポーネント６０１が含まれている。ただし、編集画面に含まれる操作列コンポーネント６０１の個数は、図示した個数に限定されない。また、表示し得るアクションアイコン６１２の個数が、同時に表示可能な個数（図６（Ａ）及び（Ｂ）では６つ）を超える場合には、スクロールバー６１１が表示されるようになっている。スクロールバー６１１に対する操作により、表示し得るアクションアイコン６１２のうち、隠れていたアクションアイコン６１２が表示される。

まず、操作列コンポーネント６０１について説明する。操作列コンポーネント６０１は、該当する種類の連続した操作のうち、順序ｉの操作に関連付けられたアクションを表すスロット６０２＿ｉ（ｉは１以上Ｎ以下の自然数）を、１段目からＮ段目まで順に配列したコンポーネントである。

なお、Ｎは、１以上の整数であり、当該種類の操作列に含まれ得る操作の最大数を表す。最大数Ｎは、当該種類の連続する操作により連続してアクションを繰り出すことが可能な連続数の上限値となる。以降、最大数Ｎを、最大連続数Ｎとも記載する。最大連続数Ｎは、該当する編集可能キャラクタの希少度に応じて異なる場合がある。例えば、最大連続数Ｎは、希少度が低い編集可能キャラクタほど、多くなっていてもよい。また、最大連続数Ｎは、例えば、該当する編集可能キャラクタの特性に応じて異なっていてもよい。また、最大連続数Ｎは、該当する操作の種類の特性に応じて異なっていてもよい。また、最大連続数Ｎは、所定の条件が満たされた場合に増加可能である。最大連続数Ｎを増加させる条件としては、例えば、仮想通貨等の消費アイテムとの引き換えが挙げられる。また、最大連続数Ｎを増加させる条件としては、例えば、その編集可能キャラクタがレベルアップすることが挙げられる。ただし、最大連続数Ｎを増加させる条件は、これらに限られない。

例えば、図６（Ａ）に示すように、希少度ＡのドラゴンＸ１の編集画面において、タップ操作の操作列コンポーネント６０１の最大連続数Ｎは、３である。また、図６（Ｂ）に示すように、希少度ＣのドラゴンＸ３の編集画面において、タップ操作の操作列コンポーネント６０１の最大連続数Ｎは、５である。このように、同グループのキャラクタであるドラゴンＸ１及びＸ２間では、希少度がより低いドラゴンＸ３ほど、タップ操作の操作列コンポーネント６０１の最大連続数Ｎは多くなっている。

また、操作列コンポーネント６０１に含まれるＮ個のスロット６０２＿ｉのうち、編集可能数Ｍまでのスロット６０２＿ｉに対して、アクションの関連付けが可能（すなわち、編集可能）である。編集可能数Ｍを超えるスロット６０２＿ｉは、編集不可能であり、アクションの関連付けができない。編集不可能なスロット６０２＿ｉは、編集不可能であることを表すよう表示される。図６（Ａ）及び（Ｂ）の例では、カギマークが表示されたスロット６０２＿ｉは、編集不可能であることを表している。また、当該種類の連続する操作により連続してアクションを繰り出すことが可能な連続数は、編集可能数Ｍまでとなる。ただし、編集可能数Ｍは、編集可能キャラクタが満たす条件に応じて最大連続数Ｎまで増加可能である。なお、編集可能数Ｍは、編集可能キャラクタにより異なっていてもよい。編集可能数Ｍを増加させる条件としては、例えば、仮想通貨等の消費アイテムとの引き換えが挙げられる。また、編集可能数Ｍを増加させる条件としては、例えば、その編集可能キャラクタがレベルアップすることが挙げられる。ただし、編集可能数Ｍを増加させる条件は、これらに限られない。

次に、アクションアイコン６１２について説明する。アクションアイコン６１２は、操作列情報の各操作に対して関連付け得るアクションを表している。関連付け得るアクションの種類としては、前述のように、敵キャラクタに作用を与えるもの、操作キャラクタを移動するもの、サブキャラクタを召喚するもの等がある。

また、アクションアイコン６１２が表すアクションには、例えば、アクションの名称、アクションの特性、アクションのパラメータ等の各種の情報が定められている。アクションアイコン６１２の近傍には、このような各アクションに関する情報が併せて表示されていてもよい。図６（Ａ）の例では、例えば、「Ｘ１＿ａ」という名称のアクションの特性は「ｘｘａ１」であり、コストは「ｙ１」である。また、アクションのパラメータの一例として、コストがある。コストの詳細については後述する。なお、アクションアイコン６１２が表すアクションに定められる情報は、上述した情報に限定されない。また、アクションアイコン６１２の近傍に表示される情報は、これらの情報に限定されない。なお、図６（Ａ）の例では、アクションアイコン６１２は、対応するアクションの名称を含むアイコンとして表示されているが、アクションアイコン６１２の表示形態は、これに限られない。例えば、アクションアイコン６１２は、対応するアクションを表すデザインのアイコンとして表示されていてもよい。

次に、アクションアイコン６１２の一覧について説明する。アクションアイコン６１２の一覧は、スロット６０２＿ｉに対応する操作に関連付けが可能なアクションの一覧を表す。関連付けが可能なアクションは、該当する編集可能キャラクタによって取得済みのアクションを含む。さらに、関連付けが可能なアクションは、該当する編集可能キャラクタと同グループの他の編集可能キャラクタによって取得済みのアクションを含んでいてもよい。以降、あるキャラクタによって取得済みのアクションのことを、当該キャラクタによって使用可能なアクション、と記載することもある。

なお、編集可能キャラクタは、条件を満たすことにより新たなアクションを取得するようになっていてもよい。新たなアクションを取得する条件とは、例えば、該当する編集可能キャラクタの操作キャラクタとしてのプレイ期間が閾値を超えることであってもよい。これは、ゲームの進行に伴い操作キャラクタが新たな技を閃いたことを表現している。また、アクションを取得する条件とは、例えば、操作キャラクタが所定のアイテムを取得することであってもよい。これは、操作キャラクタが所定のアイテムを用いて新たな技を覚えることを表現している。

また、アクションアイコン６１２の一覧は、編集対象のスロット６０２＿ｉに対応する操作の種類に応じた特性を有するアクションの一覧を表す。例えば、タップ操作に応じた特性とは、ホーミング性能が高いことであってもよい。また、例えば、上フリック操作または下フリック操作に応じた特性とは、攻撃力が高いことであってもよい。また、例えば、左右フリックに応じた特性とは、攻撃範囲が広いことであってもよい。また、関連付け得るアクションの特性を、操作の種類に応じて変化させてもよい。例えば、上、下または左右フリック操作に比べて、タップ操作に関連付け得るアクションのホーミング性能を高くし、回転操作に関連付け得るアクションのホーミング性能を低くしてもよい。また、例えば、上または下フリック操作に比べて、左右フリック操作に関連付け得るアクションのホーミング性能を高くしてもよい。

例えば、図６（Ａ）では、タップ操作の操作列コンポーネント６０１に含まれる何れかのスロット６０２＿ｉがタップされたことにより、アクションアイコン６１２の一覧が表示される。これらのアクションアイコン６１２が表すアクションは、タップ操作に応じた特性を有するアクションであって、当該ドラゴンＸ１又はグループＸの他のキャラクタにより使用可能なアクションである。例えば、アクションＸ１＿ａ、Ｘ１＿ｂ、Ｘ１＿ｃは、ドラゴンＸ１によって使用可能なアクションを表す。また、例えば、アクションＸ２＿ａ、Ｘ２＿ｂは、グループＸの他のキャラクタであるドラゴンＸ２によって使用可能なアクションを表す。また、例えば、アクションＸ３＿ａは、グループＸの他のキャラクタであるドラゴンＸ３によって使用可能なアクションを表す。なお、実線のアクションアイコン６１２は、該当するキャラクタによって取得済みのアクションを表し、破線のアクションアイコン６１２は、未取得のアクションを表している。

また、図６（Ｂ）では、タップ操作の操作列コンポーネント６０１に含まれる何れかのスロット６０２＿ｉがタップされたことにより、アクションアイコン６１２の一覧が表示される。これらのアクションアイコン６１２が表すアクションは、タップ操作に応じた特性を有するアクションであって、当該ドラゴンＸ３又はグループＸの他のキャラクタにより使用可能なアクションである。この例では、図６（Ａ）及び（Ｂ）は、どちらもグループＸのキャラクタの編集画面を例示しているため、それぞれのタップ操作に応じたアクションアイコン６１２の一覧は、同等となっている。

このように、希少度ＣのドラゴンＸ３のタップ操作のスロット６０２＿ｉに、当該ドラゴンＸ３によって使用可能なアクションＸ３＿ａだけでなく、より高い希少度のドラゴンＸ１、Ｘ２によって使用可能なアクションＸ１＿ａ、Ｘ１＿ｂ、Ｘ１＿ｃ、Ｘ２＿ａ、Ｘ２＿ｂの何れかを関連付けることができる。このとき、希少度がより低いドラゴンＸ３のタップ操作の最大連続数５が、希少度がより高いドラゴンＸ１のタップ操作の最大連続数３より多いことにより、希少度が低くてもドラゴンＸ３を使用することの戦略性が増す。したがって、ユーザにとって、既に希少度ＡのドラゴンＸ１を保有していたとしても、新たに希少度ＣのドラゴンＸ３を取得することに対する動機付けが向上する。

次に、編集画面における操作列情報の編集方法の一例について説明する。編集可能なスロット６０２＿ｉには、アクションアイコン６１２を嵌め込むことが可能となっている。嵌め込まれたアクションアイコン６１２が表すアクションは、スロット６０２＿ｉの順序の操作に関連付けられる。スロット６０２＿ｉにアクションアイコン６１２を嵌め込むための操作は、例えば、ドラッグ操作であってもよい。また、嵌め込むための操作は、スロット６０２＿ｉ及びアクションアイコン６１２をこの順または逆順にタップ操作することであってもよい。ただし、嵌め込むための操作は、これらの操作に限定されない。

また、スロット６０２＿ｉに嵌め込まれたアクションアイコン６１２は、所定の操作によりクリアされ、空きスロットとなることが可能である。クリアのための操作は、例えば、既に嵌め込まれたアクションアイコン６１２が、スロット６０２＿ｉの枠外にドラッグ操作されることであってもよい。ただし、クリアのための操作は、このような操作に限定されない。また、編集画面において、各種類の操作列コンポーネント６０１における各スロット６０２＿ｉを空きスロットとする「オールクリア」の機能が提供されていてもよい。この場合、編集画面は、オールクリアを指示する操作ボタン（図示せず）を含む。

なお、スロット６０２＿ｉは、該当する順序のアクションが関連付けられていない場合には、空きスロットであることを表すよう表示される。図６（Ａ）及び（Ｂ）の例では、斜線で塗りつぶされたスロット６０２＿ｉは、空きスロットである。

例えば、図６（Ａ）において、タップ操作に関する操作列コンポーネント６０１を参照すると、３つのスロット６０２＿ｉが配列されている。すなわち、最大連続数Ｎは３である。また、スロット６０２＿１～６０２＿２までが編集可能であり、そのうち、スロット６０２＿２は空きスロットである。また、スロット６０２＿３は、編集不可能となっている。すなわち、編集可能数Ｍは２である。換言すると、この例では、この編集可能キャラクタについては、タップ操作の最大連続数３のうち編集可能数の２段目まで、連続したアクションを実行させることが可能となっている。

また、各操作列情報において各操作に対して関連付けられたアクションのコストの総和は、コストの上限値を超えないよう定められている。例えば、各種類の操作列コンポーネント６０１における各スロット６０２＿ｉに嵌め込まれたアクションアイコン６１２のコストの総和が上限値を超えているか否かは、操作列情報の編集を終了する際に判断される。例えば、編集画面生成部１２０は、編集終了を指示する操作が行われた際に、コストの総和が上限値を超えていなければ、編集内容を反映した操作列情報を、ユーザ情報１３３として記憶部１３０に保存する。もし、コストの総和が上限値を超えていれば、編集画面生成部１２０は、操作列情報を保存しない。この場合、編集画面生成部１２０は、コストの総和が上限値を超えていることを表示した上で、編集画面の表示を継続してもよい。また、スロットによっては、キャラクタに固有のアクションが割り当てられており、当該スロットについて編集を不可としてもよい。すなわち、キャラクタに固有のアクションが割り当てられているスロットについて、アクションをクリアすることも、他のアクションを割り当てることも不可能であることとしてもよい。

＜ゲームシステム１の処理フロー＞
図７～図１２は、ユーザ端末１００が、ゲームプログラム１３１に基づいて実行する処理の流れを示すフローチャートである。

（操作列情報の編集処理の流れ）
まず、操作列情報の編集処理について、図７を参照して説明する。図７は、操作列情報の編集処理の流れを示すフローチャートである。なお、以下の動作の開始時に、表示部１５２には、既にゲーム画面が表示されているものとする。また、表示されているゲーム画面には、操作列情報の編集開始を指示するためのＵＩオブジェクトが含まれているものとする。また、図７に示す一連の処理ステップは、ユーザ端末１００によって実行されるものとして記載しているが、これらの処理ステップの少なくとも一部は、サーバ２００によって実行されてもよい。

ステップＳ１０１において、操作受付部１１１は、ある編集可能キャラクタについて、操作列情報の編集開始を指示する操作を受け付けたか否かを判断する。対象となる編集可能キャラクタは、この時点で選択されている操作キャラクタであってもよいし、その他の編集可能キャラクタであってもよい。編集開始を指示する操作が受け付けられた場合、次のステップＳ１０２が実行される。

ステップＳ１０２において、編集画面生成部１２０は、その編集可能キャラクタに関する操作列情報を記憶部１３０から読み込む。このとき読み込まれる操作列情報は、既に編集されて保存されている操作列情報、または、初期状態の操作列情報である。初期状態の操作列情報では、各操作に対して予め定められたアクションが関連付けられているものとする。

ステップＳ１０３において、編集画面生成部１２０は、この編集可能キャラクタの操作列情報に基づいて、編集画面を表示する。

ステップＳ１０４において、操作受付部１１１は、スロット６０２＿ｉの１つに対する操作を受け付ける。例えば、スロット６０２＿ｉに対するタップ操作、または、ドラッグ操作が受け付けられてもよい。以下、操作が受け付けられたスロット６０２＿ｉを、操作対象のスロット６０２＿ｉとも記載する。

ステップＳ１０５において、編集画面生成部１２０は、操作が受け付けられたスロット６０２＿ｉの状態によって、処理を分岐する。

具体的には、ステップＳ１０５において、操作対象のスロット６０２＿ｉが編集不可能であった場合について説明する。この場合、ステップＳ１０６において、編集画面生成部１２０は、該当するスロット６０２＿ｉは編集不可能であるという通知を表示する。

また、ステップＳ１０５において、操作対象のスロット６０２＿ｉに既にアクションアイコン６１２が嵌め込まれていた場合について説明する。この場合、ステップＳ１０４で受け付けられた操作が、当該スロット６０２＿ｉに対するクリアを指示する操作であったとする（ステップＳ１０７でＹｅｓ）。この場合、ステップＳ１０８において、編集画面生成部１２０は、該当するスロット６０２＿ｉからアクションアイコン６１２をクリアし、空きスロットとして表示する。

また、ステップＳ１０５において、操作対象のスロット６０２＿ｉが空きスロットであった場合について説明する。この場合、ステップＳ１０９において、編集画面生成部１２０は、当該スロット６０２＿ｉに応じたアクションアイコン６１２の一覧を表示する。一覧に含まれるアクションアイコン６１２は、対応する編集可能キャラクタ及び同グループの他の編集可能キャラクタが取得済みのアクションのうち、当該スロット６０２＿ｉに対応する操作の種類に応じた特性を有するアクションを表す。

ステップＳ１１０において、操作受付部１１１は、アクションアイコン６１２の一覧の何れか１つを、スロット６０２＿ｉまでドラッグする操作を受け付ける。ドラッグ先として有効なスロット６０２＿ｉは、ステップＳ１０４で操作された操作対象のスロット６０２＿ｉと同一の操作列コンポーネント６０１に含まれる何れかのスロット６０２＿ｉであるものとする。

ステップＳ１１１において、編集画面生成部１２０は、ドラッグ操作されたアクションアイコン６１２を、ドラッグ先のスロット６０２＿ｉに嵌め込んだ画像を表示する。

ステップＳ１１２において、編集終了を指示する操作が受け付けられていなければ、編集画面生成部１２０は、ステップＳ１０４からの動作を繰り返す。

ステップＳ１１２において、編集終了を指示する操作が受け付けられた場合について説
明する。この場合、ステップＳ１１３において、編集画面生成部１２０は、コストの総和が上限値を超えるか否かを判断する。具体的には、編集画面生成部１２０は、各種類の操作列コンポーネント６０１に含まれる各スロット６０２＿ｉに嵌め込まれたアクションアイコン６１２のコストの合計を算出し、算出した値が上限値を超えるか否かを判断すればよい。

ステップＳ１１３において、コストの総和が上限値を超える場合、編集画面生成部１２０は、その旨を表す通知を表示する。そして、編集画面生成部１２０は、ステップＳ１０４からの動作を繰り返す。

ステップＳ１１３において、コストの総和が上限値以下である場合について説明する。この場合、ステップＳ１１４において、編集画面生成部１２０は、各操作列コンポーネント６０１における編集内容を反映させた操作列情報を、記憶部１３０に保存する。

ステップＳ１１５において、表示制御部１１２は、編集画面を閉じてゲーム画面を表示する。

（連続する操作に応じた処理）
次に、タッチスクリーン１５に対して連続する操作に応じた処理について、図８を参照して説明する。図８は、連続する操作に応じた処理の流れを示すフローチャートである。なお、図８に示す一連の処理ステップは、ユーザ端末１００によって実行されるものとして記載しているが、これらの処理ステップの少なくとも一部は、サーバ２００によって実行されてもよい。

ステップＳ２０１において、操作受付部１１１がゲームを開始する操作を受け付けると、ゲーム実行部１１５は、ゲームを開始する。

ステップＳ２０２において、ゲーム実行部１１５は、サーバ２００から取得した各種ゲーム情報に基づいて、操作キャラクタが存在するゲーム空間を表すゲーム画面を生成し、タッチスクリーン１５に表示する。

ステップＳ２０３において、操作受付部１１１は、操作キャラクタについての操作列情報を記憶部１３０から読み込む。

ステップＳ２０４において、操作受付部１１１が、タッチスクリーン１５に対する操作を受け付けると、ステップＳ２０５において、連続操作判定部１２１は、受け付けられた今回の操作が、前回の操作に連続しているか否かを判断する。

具体的には、連続操作判定部１２１は、今回の操作が、前回の操作に基づく操作キャラクタのアクションを表すモーションの終了前に受け付けられていた場合に、連続していると判断する。それ以外の場合、連続操作判定部１２１は、連続していないと判断する。なお、連続しているか否かの判断基準としては、これに限らず、他の基準も採用可能である。

ステップＳ２０５において、今回の操作が前回の操作に連続していないと判断した場合について説明する。この場合、ステップＳ２０６において、連続操作判定部１２１は、この操作キャラクタの操作列情報のうち、今回の操作の種類に関する操作列情報を参照する。そして、連続操作判定部１２１は、操作列情報の先頭の操作に関連付けられたアクションを、実行すべきアクションとして決定する。

一方、ステップＳ２０５において、今回の操作が前回の操作に連続していると判断した場合について説明する。この場合、ステップＳ２０７において、連続操作判定部１２１は、今回の操作の種類と、前回の操作の種類とが、同一であるか否かを判断する。

ステップＳ２０７において、同一の種類でないと判断した場合、ステップＳ２０６が実行される。これにより、今回の種類の操作列情報において先頭の操作に関連付けられたアクションが、実行すべきアクションとして決定される。

ステップＳ２０７において、同一の種類であると判断した場合、ステップＳ２０８が実行される。

ステップＳ２０８において、連続操作判定部１２１は、今回の操作が、この種類の操作の何段目であるか（すなわち、順序）を特定する。

ステップＳ２０９において、連続操作判定部１２１は、ステップＳ２０８で特定した順序が、この種類の操作の編集可能数Ｍ以下であるか否かを判断する。

ステップＳ２０９において、操作の順序が編集可能数Ｍを超えている場合、実行すべきアクションが決定されることなく、ステップＳ２０４からの操作が繰り返される。すなわち、編集可能数Ｍを超えて連続する同種の操作は、前回の操作に連続していないと判定されるまで、無効となる。

ステップＳ２０９において、操作の順序が編集可能数Ｍ以下である場合について説明する。この場合、ステップＳ２１０において、連続操作判定部１２１は、今回の種類の操作列情報において、ステップＳ２０８で特定した順序の操作に関連付けられたアクションを、実行すべきアクションとして決定する。

ステップＳ２１１において、ゲーム実行部１１５は、操作キャラクタに、決定されたアクションを実行させるよう、各部に通知する。具体的には、アニメーション生成部１１４は、操作キャラクタが、決定されたアクションのモーションを行うアニメーションを生成する。また、表示制御部１１２は、生成されたアニメーションを表示する。なお、ゲーム実行部１１５は、操作キャラクタが実行中の前回のアクションに基づく表示を途中で取りやめて、今回決定されたアクションに基づく表示を行うよう各部を制御する。このとき、この時点で表示されているモーションが前回のアクションの戻りモーションであれば、ゲーム実行部１１５は、戻りモーションの表示を直ちにキャンセルして今回のアクションのモーションを表示するよう制御する。また、この時点で表示されているモーションが前回のアクションの攻撃モーションであれば、ゲーム実行部１１５は、攻撃モーションの表示が終了するまで待機してから戻りモーションの表示をキャンセルして今回のアクションのモーションを表示するよう制御してもよい。あるいは、この場合、ゲーム実行部１１５は、攻撃モーションの表示をキャンセルして今回のアクションのモーションを表示するよう制御してもよい。

そして、制御部１１０は、ステップＳ２０４からの動作を繰り返す。

（権利アイテム及び戦闘ポイントを付与する処理）
次に、操作キャラクタの敵キャラクタとの戦闘内容に応じて、戦闘ポイントをユーザに付与する処理について、図９を参照して説明する。図９は、戦闘ポイントを付与する処理の流れを示すフローチャートである。なお、図９に示す一連の処理ステップは、ユーザ端末１００によって実行されるものとして記載しているが、これらの処理ステップの少なくとも一部は、サーバ２００によって実行されてもよい。

ステップＳ３０１において、ゲーム実行部１１５は、操作キャラクタと敵キャラクタとの戦闘に勝利したか否かを判断する。ステップＳ３０１でＮｏの場合、ステップＳ３０１が繰り返される。ステップＳ３０１でＹＥＳの場合、次のステップＳ３０２が実行される。

ステップＳ３０２において、報酬決定部１１７は、戦闘内容に基づいて、付与する権利アイテムの個数及び種類を決定する。そして、報酬決定部１１７は、決定した権利アイテムをユーザに付与する。なお、戦闘に勝利したときに権利アイテムが付与される確率が、例えば、操作キャラクタ、操作キャラクタと戦闘する敵キャラクタ、または権利アイテムごとに設定されているものとするが、これに限られない。報酬決定部１１７は、戦闘に勝利したときに、当該確率に基づいて権利アイテムを付与する。

ステップＳ３０３において、ゲーム実行部１１５は、戦闘内容に基づいて、付与する戦闘ポイントを決定する。例えば、付与する戦闘ポイントは、操作キャラクタのレベルと敵キャラクタのレベルとに応じて決定されてもよい。

ステップＳ３０４において、ゲーム実行部１１５は、決定された戦闘ポイントを、ユーザに関連付けられた戦闘ポイントの合計に加算する。また、ゲーム実行部１１５は、ゲーム画面における戦闘ポイントオブジェクト３０１について、加算された戦闘ポイントの合計を反映させて表示を更新する。

ステップＳ３０５において、取得準備部１１８は、戦闘内容に基づいて、第１の条件が満たされたか否かを判断する。具体的には、取得準備部１１８は、ユーザに関連付けられた戦闘ポイントの合計が、所定値に到達したか否かを判断する。ステップＳ３０５でＮｏの場合、ステップＳ３０１からの動作が繰り返される。ステップＳ３０５でＹｅｓの場合、次のステップＳ３０６が実行される。

ステップＳ３０６において、取得準備部１１８は、ユーザに関連付けられた、消費可能な権利アイテム数に、１を加算する。また、取得準備部１１８は、ゲーム画面における戦闘ポイントオブジェクト３０１について、消費可能な権利アイテム数を表すバッジ３０１ｂの表示を更新する。そして、ステップＳ３０１からの動作が繰り返される。

（第１の条件が満たされたことに応じて第１の抽選を行う処理フロー）
次に、第１の条件が満たされたことに応じて第１の抽選を行う処理の流れを、図１０に示す。

ステップＳ４０１で、ユーザ端末１００において、取得準備部１１８は、第１の条件が満たされたことに応じて第１の抽選を行うための操作を受け付けたか否かを判断する。具体的には、取得準備部１１８は、図３（Ｂ）において戦闘ポイントオブジェクト３０１に対する入力操作が受け付けられ、続いて、図５（Ａ）においてふかするボタン５０２に対する入力操作が受け付けられたか否かを判断すればよい。ステップＳ４０１でＮｏの場合、ステップＳ４０１が繰り返される。ステップＳ４０１でＹｅｓの場合、次のステップＳ４０２が実行される。

ステップＳ４０２で、取得準備部１１８は、保有権利アイテム群の中から、消費する対象となる権利アイテムを、第１の抽選により特定する。具体的には、取得準備部１１８は、ユーザによって保有されるクリスタル群の中から、ランダムに１つを特定すればよい。

ステップＳ４０３で、取得準備部１１８は、特定された権利アイテムの消費を、サーバ２００に対して要求する。具体的には、取得準備部１１８は、特定された権利アイテムの種類を、サーバ２００に送信する。

ステップＳ４０４で、サーバ２００におけるオブジェクト提供部２１１は、通知された権利アイテムの種類に応じたオブジェクトを決定する。決定されるオブジェクトは、当該種類に関連付けられた１つ以上のオブジェクトの中から、出現確率に基づいて決定される。決定されるオブジェクトは、操作キャラクタになり得るキャラクタ、サブキャラクタになり得るキャラクタ、及び、ゲームにおいて利用可能なその他のオブジェクトの少なくとも何れかを含む。

ステップＳ４０５で、オブジェクト提供部２１１は、決定したオブジェクトを、ユーザ端末１００に通知する。

ステップＳ４０６で、取得準備部１１８は、通知されたオブジェクトを、第１の抽選により特定された権利アイテムに応じたオブジェクトとして、ユーザに付与する。このとき、取得準備部１１８は、図５（Ｂ）に示したオブジェクト付与画面を表示してもよい。

（消費アイテムと引き換えに第１の抽選を行う処理フロー）
次に、消費アイテムと引き換えに第１の抽選を行う処理の流れを、図１１に示す。なお、図１１に示す処理の開始時には、ユーザ端末１００の表示部１５２に、図４（Ａ）に示したような保有権利アイテム群の一覧画面が表示されているものとする。

ステップＳ５０１で、ユーザ端末１００において、取得準備部１１８は、消費アイテムとの引き換えに１つの権利アイテムを消費する操作を受け付けたか否かを判断する。具体的には、取得準備部１１８は、図４（Ａ）においてふかボタン４０５に対する入力操作が受け付けられ、続いて、図４（Ｂ）においてランダムに１つふかボタン４０７に対する入力操作が受け付けられたか否かを判断すればよい。ステップＳ５０１でＮｏの場合、ステップＳ５０１が繰り返される。ステップＳ５０１でＹｅｓの場合、次のステップＳ５０２が実行される。

ステップＳ５０２で、取得準備部１１８は、消費アイテムの所定量を消費する。所定量は、権利アイテムを１つ消費するために設定された量である。

ステップＳ５０３～Ｓ５０７の処理は、第１の条件が満たされたことに応じて第１の抽選を行う処理における図１０のステップＳ４０２～Ｓ４０６と同様であるため、詳細な説明を繰り返さない。これにより、第１の抽選により権利アイテムが特定され、特定された権利アイテムの種類に応じて決定されたオブジェクトが、ユーザに付与される。また、オブジェクト付与画面が表示される。

（権利アイテムを一括して消費する処理フロー）
次に、権利アイテムを一括して消費する処理の流れを、図１２に示す。なお、図１２に示す処理の開始時には、ユーザ端末１００の表示部１５２に、図４（Ａ）に示したような保有権利アイテム群の一覧画面が表示されているものとする。

ステップＳ６０１で、ユーザ端末１００において、取得準備部１１８は、消費アイテムとの引き換えに権利アイテムを一括して消費する操作を受け付けたか否かを判断する。具体的には、取得準備部１１８は、図４（Ａ）においてふかボタン４０５に対する入力操作が受け付けられ、続いて、図４（Ｂ）においてぜんぶふかボタン４０８に対する入力操作が受け付けられたか否かを判断すればよい。ステップＳ６０１でＮｏの場合、ステップＳ５０１が繰り返される。ステップＳ６０１でＹｅｓの場合、次のステップＳ６０２が実行される。

ステップＳ６０２で、取得準備部１１８は、消費アイテムの所定量を消費する。所定量は、権利アイテムを一括して消費するために設定された量であり、一括して消費する対象となる権利アイテム数に応じて異なっていてもよい。

ステップＳ６０３で、取得準備部１１８は、各権利アイテムの消費を、サーバ２００に対して一括して要求する。具体的には、取得準備部１１８は、各権利アイテムの種類を、サーバ２００に送信する。

ステップＳ６０４～Ｓ６０６では、各権利アイテムについて、第１の条件が満たされたことに応じて第１の抽選を行う処理における図１０のステップＳ４０４～Ｓ４０６と同様の処理が実行される。これにより、権利アイテムが一括して消費され、各権利アイテムの種類に応じて決定されたオブジェクトが、ユーザに付与される。また、付与される各オブジェクトについて、オブジェクト付与画面が表示される。

＜本実施形態の効果＞
以上説明したように、本実施形態では、第１の条件が満たされた際にどの権利アイテムが消費されるかが抽選により特定されるため、ユーザの意思により権利アイテムを指定する場合と比べると、ユーザによるゲーム進行がランダムになる要素が増える。その結果、ゲームの展開が多様化し、ゲームの興趣性が向上する、という効果を奏する。

また、本実施形態では、ユーザは、権利アイテムを消費してオブジェクトを取得するために、第１の条件を満たすことが必要になる。第１の条件が満たされたか否かは、操作キャラクタと敵キャラクタとの戦闘内容に応じて判断されるため、操作キャラクタと敵キャラクタを戦闘させるプレイを繰り返すことに対するユーザの動機付けが向上する、という効果を奏する。

また、本実施形態では、操作キャラクタと敵キャラクタとの戦闘により、当該敵キャラクタに応じた種類（グループ及び希少度）の権利アイテムが付与される。また、そのような権利アイテムを消費すれば、そのグループ及び希少度のキャラクタが付与される期待値が大きい。その結果、操作キャラクタと敵キャラクタとを戦闘させるプレイを繰り返すことに対するユーザの動機付けが向上する、という効果を奏する。

また、本実施形態では、ユーザに付与された権利アイテムは、その種類（グループ及び希少度）が認識可能に表示される。その結果、権利アイテムを消費して様々なグループ・様々な希少度のキャラクタを取得することに対するユーザの動機付けが向上する、という効果を奏する。

なお、図２に示すサーバ２００およびユーザ端末１００の機能は一例にすぎない。サーバ２００は、ユーザ端末１００が備える機能の少なくとも一部を備えていてもよい。また、ユーザ端末１００は、サーバ２００が備える機能の少なくとも一部を備えていてもよい。さらに、ユーザ端末１００およびサーバ２００以外の他の装置をゲームシステム１の構成要素とし、該他の装置にゲームシステム１における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末１００、サーバ２００、および他の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。

〔ソフトウェアによる実現例〕
制御部２１０の制御ブロック（特に、オブジェクト提供部２１１）、ならびに、制御部
１１０の制御ブロック（特に、操作受付部１１１、表示制御部１１２、ユーザインターフェース（以下、ＵＩ）制御部１１３、アニメーション生成部１１４、ゲーム実行部１１５、カメラ配置制御部１１６、報酬決定部１１７、取得準備部１１８、取得実行部１１９、編集画面生成部１２０及び連続操作判定部１２１）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。

後者の場合、制御部２１０または制御部１１０、もしくはその両方を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するＣＰＵ、上記プログラムおよび各種データがコンピュータ（またはＣＰＵ）で読み取り可能に記録されたＲＯＭ（Read Only Memory）または記憶装置（これらを「記録媒体」と称する）、上記プログラムを展開するＲＡＭ（Random Access Memory）などを備えている。そして、コンピュータ（またはＣＰＵ）が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

〔付記事項〕
本発明の一側面に係る内容を列記すると以下のとおりである。

（項目１） ゲームプログラム（１３１）について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ（１０、２０）、メモリ（１１、２１）、及び操作部を備えるコンピュータ（ユーザ端末１００、サーバ２００）により実行される。ゲームプログラムは、プロセッサに、権利アイテムをユーザに関連付けるステップと、ユーザの入力操作に応じて、ユーザが操作対象とする第１のキャラクタと、第１のキャラクタと戦闘する対象となる第２のキャラクタとを戦闘させるステップと、戦闘させるステップにおける戦闘内容に基づいて、権利アイテムを消費可能とするための第１の条件が満たされたか否かを判定するステップと、第１の条件が満たされた場合に、ユーザに関連付けられた１以上の権利アイテムのうち、抽選により、少なくとも何れかを特定するステップと、特定された権利アイテムについて、当該権利アイテムを消費して、当該権利アイテムに応じたオブジェクトをユーザに付与するステップと、を実行させる。

上記構成によれば、権利アイテムを消費してオブジェクトを取得するために第１の条件を満たすよう、第１のキャラクタと第２のキャラクタとを戦闘させるプレイを繰り返すことに対するユーザの動機付けが向上する。そして、第１の条件が満たされた際にどの権利アイテムが消費されるかが抽選により特定されるため、ユーザの意思により権利アイテムを指定する場合と比べると、ユーザによるゲーム進行がランダムになる要素が増える。その結果、ゲームの展開が多様化し、ゲームの興趣性が向上する。

（項目２） （項目１）において、権利アイテムを関連付けるステップは、戦闘させるステップの実行に応じて、権利アイテムをユーザに付与してもよい。これにより、権利アイテムを取得するために、第１のキャラクタと第２のキャラクタとを戦闘させるプレイに対するユーザの動機付けが向上する。

（項目３） （項目１）又は（項目２）において、権利アイテムを関連付けるステップは、戦闘させるステップにおける第２のキャラクタに応じた権利アイテムを、ユーザに付与してもよい。このように、第２のキャラクタに応じた権利アイテムが付与されることにより、付与された権利アイテムを消費することに対するユーザの動機付けが向上する。

（項目４） （項目３）において、オブジェクトを付与するステップにおいて、消費する権利アイテムに応じたオブジェクトとして、当該権利アイテムに関連する第２のキャラクタに応じたオブジェクトを、ユーザに確率的に付与してもよい。これにより、第２のキャラクタに応じたオブジェクトを取得するために、付与された権利アイテムを消費することに対するユーザの動機付けがさらに向上する。

（項目５） （項目１）から（項目４）の何れか１項目において、オブジェクトを付与するステップにおいて、消費する権利アイテムに応じたオブジェクトとして、第１のキャラクタになり得るキャラクタを、ユーザに確率的に付与してもよい。これにより、第１のキャラクタになり得るキャラクタを取得するために、付与された権利アイテムを消費することに対するユーザの動機付けが向上する。

（項目６） （項目１）から（項目５）の何れか１項目において、オブジェクトを付与するステップにおいて、消費する権利アイテムに応じたオブジェクトとして、第１のキャラクタと共に第２のキャラクタと戦闘し得るキャラクタを、ユーザに確率的に付与してもよい。これにより、第１のキャラクタと共に戦闘し得るキャラクタを取得するために、付与された権利アイテムを消費することに対するユーザの動機付けが向上する。

（項目７） （項目１）から（項目６）の何れか１項目において、ゲームプログラムは、プロセッサに、ユーザに関連付けられた権利アイテムを、当該権利アイテムに応じて取得可能なキャラクタのグループを認識可能な態様で表示部に表示するステップをさらに実行させてもよい。これにより、ユーザは、保有する権利データの表示態様から、抽選により取得できる可能性があるキャラクタのグループがわかる。その結果、より多くのグループのキャラクタを取得することに対するユーザの動機付けが向上する。

（項目８） （項目７）において、戦闘させるステップは、第１のキャラクタに、当該第１のキャラクタによって使用可能なアクション、又は、ユーザによって保有されるキャラクタのうち、当該第１のキャラクタと同グループの他のキャラクタによって使用可能なアクションを実行させてもよい。このように、同グループのキャラクタ間で、使用可能なアクションを共有できるようにすることで、既に保有しているキャラクタと同グループの他のキャラクタを取得することに対するユーザの動機付けが向上する。

（項目９） （項目１）から（項目８）の何れか１項目において、プロセッサは、ゲームプログラムに基づくゲームにおいて利用可能な各キャラクタについて、ゲームを有利に進める上での価値を表す希少度の設定を示す情報を前記メモリに記憶させてもよい。この場合、ゲームプログラムは、プロセッサに、ユーザによって保有される、第１のキャラクタになり得るキャラクタ毎に、操作部に対する連続する操作よりなる操作列に含まれる各操作に対して、当該操作の操作列における順序に応じたアクションを関連付ける編集画面を表示部に表示するステップをさらに実行させてもよい。また、編集画面を表示部に表示するステップにおいて、各操作に対して関連付け可能なアクションは、当該キャラクタによって使用可能なアクション群、及び、ユーザによって保有されるキャラクタのうち当該キャラクタと同グループの他のキャラクタによって使用可能なアクション群であってもよい。また、編集画面を表示部に表示するステップにおいて、操作列に含まれる編集可能な操作の数は、同グループのキャラクタ間では、希少度がより低いキャラクタほど多くてもよい。また、戦闘させるステップは、操作部に対する操作を受け付けると、第１のキャラクタについて当該操作に対して順序に応じて関連付けられたアクションを、当該第１のキャラクタに実行させてもよい。

これにより、ユーザは、既に保有している当該グループのキャラクタによって使用可能なアクションを、新たに取得する希少度が低いキャラクタの操作列に含めることができる可能性が高い。そのため、希少度が低いキャラクタを用いることの戦略性が増し、ゲームの興趣性が向上する。

（項目１０） （項目１）から（項目９）の何れか１項目において、ゲームプログラムは、プロセッサに、戦闘させるステップにおける戦闘内容に応じたポイントを、ユーザに付与するステップをさらに実行させてもよい。この場合、判定するステップは、付与されたポイントの合計が所定値に到達することにより、第１の条件が満たされたと判定することを含む。これにより、権利データを消費するためのポイントを貯めるため、第１のキャラクタと第２のキャラクタとを戦闘させるプレイを繰り返すことに対するユーザの動機付けが向上する。

（項目１１） （項目１）から（項目１０）の何れか１項目において、特定するステップは、ユーザに関連付けられた消費アイテムの所定量と引き換えに、１以上の権利アイテムの少なくとも何れかを抽選により特定してもよい。これにより、ユーザは、ポイントが貯まっていなくても、所望の時点で消費対象の権利データを抽選することができる。その結果、第１の条件が満たされない期間が長くなっても、ゲームのプレイを継続することに対するユーザの動機付けが維持される。

（項目１２） ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ、メモリ、及び操作部を備えるコンピュータにより実行される。該方法は、プロセッサが（項目１）に記載の各ステップを実行する方法である。（項目１２）に係る方法は、（項目１）に係るゲームプログラムと同様の作用効果を奏する。

（項目１３） 情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、（項目１）に係るゲームプログラムを記憶する記憶部（１２０）と、該ゲームプログラムを実行することにより、情報処理装置（ユーザ端末１００）の動作を制御する制御部（１１０）と、を備える。（項目１３）に係る情報処理装置は、（項目１）に係るゲームプログラムと同様の作用効果を奏する。

１ ゲームシステム、 ２ ネットワーク、 １０，２０ プロセッサ、 １１，２１ メモリ、 １２，２２ ストレージ、 １３，２３ 通信ＩＦ（操作部）、 １４，２４ 入出力ＩＦ（操作部）、 １５ タッチスクリーン（表示部、操作部）、 １７ カメラ（操作部）、 １８ 測距センサ（操作部）、 １００ ユーザ端末（情報処理装置）、 １１０，２１０ 制御部、 １１１ 操作受付部、 １１２ 表示制御部、 １１３ ＵＩ制御部、 １１４ アニメーション生成部、 １１５ ゲーム実行部、 １１６ カメラ配置制御部、 １１７ 報酬決定部、 １１８ 取得準備部、 １１９ 取得実行部、 １２０ 編集画面生成部、 １２１ 連続操作判定部、 １３０，２３０ 記憶部、 １３１ ゲームプログラム、 １３２ ゲーム情報、 １３３ ユーザ情報、 １５１ 入力部（操作部）、 １５２ 表示部、 ２００ サーバ、 ２１１ オブジェクト提供部、 １０１０ 物体、 １０２０ コントローラ（操作部）、 １０３０ 記憶媒体

Claims (3)

1. コンピュータを
   権利アイテムをユーザに関連付ける関連付け手段と、
   前記権利アイテムを消費可能とするための第１の条件が満たされたか否かを判定する判断手段と、
   前記第１の条件が満たされた場合に、前記ユーザに関連付けられた１以上の前記権利アイテムのうち、抽選により、少なくとも何れかを特定する特定手段と、
   特定された前記権利アイテムについて、当該権利アイテムを消費して、当該権利アイテムに応じたオブジェクトを前記ユーザに付与する付与手段と、
   して機能させるプログラム。
2. コンピュータを、
   前記権利アイテムには、希少度及びグループが関連付けられており、前記ユーザに付与された前記権利アイテムは、当該権利アイテムのグループ及び希少度を認識可能な態様で表示する表示手段と、
   して、さらに機能させる請求項１に記載のプログラム
3. 権利アイテムをユーザに関連付ける関連付け手段と、
   前記権利アイテムを消費可能とするための第１の条件が満たされたか否かを判定する判断手段と、
   前記第１の条件が満たされた場合に、前記ユーザに関連付けられた１以上の前記権利アイテムのうち、抽選により、少なくとも何れかを特定する特定手段と、
   特定された前記権利アイテムについて、当該権利アイテムを消費して、当該権利アイテムに応じたオブジェクトを前記ユーザに付与する付与手段と、
   を有する情報処理システム。
   
   

Images