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

Abstract

【課題】ゲームの興趣性およびユーザの課金を行なうことに対する満足度を向上させることが可能なゲームプログラムを提供する。【解決手段】ゲームプログラムは、プロセッサに、ゲームプレイにおいてユーザが利用可能なオブジェクトをユーザに付与するステップと、ユーザに付与されるオブジェクトの第１のパラメータを、当該オブジェクトの重複保有をさせないか、または当該オブジェクトの重複保有を解消することにより、ゲームプレイが有利に進められるように更新させるステップと、重複保有をさせないこと又は重複保有を解消することによらず、課金処理により又は課金処理によりユーザに付与されるゲーム内価値を消費することにより第１のパラメータを更新させるステップとを実行させる。【選択図】図４

Description

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

ユーザが、当該ユーザに付与されたオブジェクトを用いてプレイするゲームが、様々な事業者により提供されている。このようなゲームにおいて、ユーザによって既に保有されるオブジェクトと同種類のオブジェクトが、当該ユーザに新たに付与されることがある。

特許文献１には、同種類のオブジェクトを組み合わせることによって一方のオブジェクトに設定されたパラメータの上限値を上昇させる技術が記載されている。

また、ユーザにオブジェクトを付与する方法には、ユーザの操作に応じて、所定の規則に基づいてユーザに付与すべきオブジェクトを選択する方法（「抽選」あるいは「ガチャ」とも言われる）が知られている（例えば、特許文献２参照）。当該選択する方法は、ユーザのゲームプレイに伴って無償で行われる場合もあるが、ユーザが購入したゲーム内価値を消費することによって（有償で）行われる場合もある。

特開２０１４−１３１７５８号公報（２０１４年７月１７日公開） 特開２０１３−２０２３２２号公報（２０１３年１０月７日公開）

上記の先行技術によれば、ユーザにとって、付与されたオブジェクトが保有するオブジェクトと重複しても、保有するオブジェクトのパラメータを高めることができ、オブジェクトが重複した結果が有効に活用される。よって、ゲームの興趣性が高められる。

一方で、ユーザがガチャを有償で実行させる場合では、ユーザは、一般に、課金額に見合ったメリットを期待し、当該メリットが課金額に見合わないとユーザが判断すると、ユーザがガチャを行う意欲が低減しやすい。

このように、上記のパラメータを高めることについては、ゲームの興趣性をさらに高める観点およびユーザが課金を行なうことに対する満足度をより高める観点から、さらなる活用法が求められている。

本開示の一態様は、ゲームの興趣性およびユーザの課金を行なうことに対する満足度を向上させることを目的とする。

本開示に係るゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。ゲームプログラムは、プロセッサに、ゲームプレイにおいてユーザが利用可能なオブジェクトをユーザに付与されるものとしてメモリに記憶させるステップと、ユーザに保有されるオブジェクトに対応付けられている第１のパラメータを、当該オブジェクトの重複保有をさせないこと、または当該オブジェクトの重複保有を解消することによりゲームプレイが有利に進められるように更新し、更新後の第１のパラメータをメモリに記憶させるステップと、当該重複保有をさせないこと又は当該重複保有を解消することによらず、課金処理により又は課金処理によりユーザに付与されるゲーム内価値を消費することにより、第１のパラメータを更新させるステップと、を実行させる。

また、本開示に係るコンピュータがゲームプログラムを実行する方法は、前記コンピュータは、プロセッサおよびメモリを備え、前記プロセッサが上記の各ステップを実行する。

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

本開示の一態様によれば、ゲームの興趣性およびユーザの課金を行なうことに対する満足度をより向上させる効果を奏する。

ゲームシステムのハードウェア構成を示す図である。 ユーザ端末およびサーバの機能的構成を示すブロック図である。 本実施形態に係るゲームプログラムに基づいて、ゲームシステムにおいて実行される処理の流れの一例を示すフローチャートである。 本実施形態における第１のパラメータを更新する処理の一例を示すフローチャートである。 本実施形態におけるゲーム内価値の取得処理の一例を示すフローチャートである。 本実施形態におけるゲーム内価値の消費可能条件を判定する処理の一例を示すフローチャートである。 本実施形態における、異なる割合に応じて第１のパラメータの値の増加分を決定する処理の例を示すフローチャートである。 本実施形態における限界突破数と第１のパラメータ（スコア）と関係の一例を示す図である。 （Ａ）は、本実施形態におけるオブジェクト「ベア」のステータスを示す画面であり、（Ｂ）は、ゲーム内価値の有償分を消費して第１のパラメータを更新するためのユーザインターフェース（ＵＩ）へのタッチ操作により移行した画面の一例を示す図である。 ゲーム内価値の有償分を消費して第１のパラメータを更新した結果を表示する画面の一例を示す図である。 （Ａ）は、本実施形態における特定のアイテムの有償分を消費して第１のパラメータを更新するためのＵＩへのタッチ操作により移行した画面の一例を示す図であり、（Ｂ）は、特定のアイテムの有償分を消費して第１のパラメータを更新した結果を表示する画面の一例を示す図である。 （Ａ）は、本実施形態における所定の規則に基づくオブジェクトの選択によって「ベア」が選択された状態を表示する画面の一例を示す図であり、（Ｂ）は、当該選択されたオブジェクトをユーザに重複保有させることに代えて、ユーザ保有のオブジェクトの第１のパラメータを更新した結果を表示する画面の一例を示す図である。

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

＜ゲームシステム１のハードウェア構成＞
図１は、ゲームシステム１のハードウェア構成を示す図である。ゲームシステム１は図示の通り、複数のユーザ端末１００と、サーバ２００とを含む。各ユーザ端末１００は、サーバ２００とネットワーク２を介して接続する。ネットワーク２は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂３Ｇ、４Ｇ移動通信システム、ＬＴＥ（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）ディスプレイ等によって構成される。

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

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

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

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

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

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

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

＜ゲーム概要＞
ゲームシステム１によって実行されるゲーム（以下、本ゲーム）は、特定のジャンルに限らず、あらゆるジャンルのゲームであってよい。例えば、テニス、卓球、ドッジボール、野球、サッカーおよびホッケーなどのスポーツを題材としたゲーム、パズルゲーム、クイズゲーム、ＲＰＧ、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、アクションゲーム、ならびに、アクションロールプレイングゲームなどであってもよい。

また、本ゲームは、特定のプレイ形態に限らず、あらゆるプレイ形態のゲームであってもよい。例えば、単一のユーザによるシングルプレイゲーム、および、複数のユーザによるマルチプレイゲーム、また、マルチプレイゲームの中でも、複数のユーザが対戦する対戦ゲーム、および、複数のユーザが協力する協力プレイゲームなどであってもよい。

ゲームシステム１は、一例として、パズル要素を配置する領域を含む盤面に複数種類の該パズル要素を配置し、該盤面を、ユーザ端末１００の表示部に表示し、該盤面におけるパズル要素の配置が変更されることよって同種のパズル要素が所定数以上連続して配置された場合に、該連続して配置されたパズル要素の少なくとも１つを盤面から除去し、除去されたパズル要素に応じて成績を決定することによって進行するパズルゲームを実行するためのシステムである。本実施形態では、単一のユーザ端末１００において実行されるパズルゲーム（シングルプレイ型パズルゲーム）が想定されている。この場合、シングルプレイ型パズルゲームをユーザ端末１００において実行するために必要な情報のやりとりがユーザ端末１００とサーバ２００との間で行われる。

別の実施形態では、ゲームシステム１は、例えば、マルチプレイ型ゲームを実行するためのシステムであってもよい。マルチプレイ型ゲームとしてのパズルゲーム（マルチプレイ型パズルゲーム）は、ユーザが操作するユーザ端末１００（クライアントのコンピュータ）と、１以上の他のユーザが操作する１以上の他のユーザ端末１００（他のクライアントのコンピュータ）との間で、該ゲームに係るデータの少なくとも一部を共有することにより、複数のユーザが１のパズルゲームに参加して協力してプレイすることが可能なパズルゲームである。

ゲームシステム１がマルチプレイ型パズルゲームである場合、サーバ２００を介して通信する第１のユーザ端末１００、第２のユーザ端末１００、および、第３のユーザ端末１００・・・のそれぞれにおいて、盤面が生成され、それぞれの表示部に表示される。別の実施形態では、パズルゲームに係るデータとして、例えば、盤面に配置されるパズル要素の種類、クリア条件、フィーバーゲージ、プレイ結果などが、サーバ２００を介して、複数のユーザ端末１００間で共有される。サーバ２００は、各ユーザ端末１００から収集した情報、および、自装置において生成した情報を、１のパズルゲームに協力して参加する各ユーザ端末１００に配布して共有させる。具体的には、盤面に配置されるパズル要素の種類を示すパズル要素データＤ１、クリア条件を示すクリア条件データＤ２、フィーバーゲージの情報を示すフィーバーゲージデータＤ３、および、プレイ結果を示す成績データＤ４などが、各ユーザ端末１００に配布され、共有される。

さらに別の実施形態では、ゲームシステム１において実行されるパズルゲームは、複数のステージを含んでいてもよい。ユーザは、ユーザ端末１００を操作して、複数のステージの中からプレイしたいステージを選択し、選択したステージをプレイする。

ゲームシステム１がゲームプログラム１３１に基づいて実現するゲームは、ゲーム空間にキャラクタオブジェクトを配置し、該ゲーム空間内で、該キャラクタをユーザの入力操作に応じて動作させるゲームであってもよい。ゲームプログラム１３１に基づくゲームは、３次元のゲーム空間および３次元のオブジェクトで表現される３Ｄゲームであってもよいし、２次元のオブジェクトで表現される２Ｄゲームであってもよい。なお、以降、ユーザの入力操作に応じて動作するキャラクタを「操作キャラクタ」もしくは「プレイヤキャラクタ（以下、ＰＣ）」と称する。

また、ゲームシステム１は、ゲームプレイにおいてユーザが利用可能なキャラクタをユーザに付与してメモリ１１に記憶させる。たとえば、ゲームプログラム１３１は、プロセッサ１０に、特定のキャラクタを含む複数のキャラクタのうち何れか１つを選択するステップを実行させる。ゲームプログラム１３１は、選択されたキャラクタがユーザによって既に保有されているオブジェクトと異なる場合では、当該選択されたキャラクタを、ユーザに保有されるキャラクタとしてメモリ１１に記憶させる。

たとえば、本実施形態で説明するパズルゲームでは、パズルゲームの１プレイの終了時、パズルゲームの実行について設定されている各種条件をクリアした場合、チケットなどの特定のアイテムの使用（消費）時に、新たにユーザに付与され得るキャラクタは、カプセルが画面に表示され、当該カプセルが割れてカプセル内からキャラクタが出現するように表示される。キャラクタが出現した画面１２００は、図１２（Ａ）に示すように、キャラクタの画像９０１と、当該キャラクタのステータス表示１２０１と、当該キャラクタの希少度の表示１２０２とを含んでいる。

ここで「希少度」とは、キャラクタ（カード）の希少価値を等級で表したものである。本ゲームでは、一例として、メインプレイパート（対戦パート、実践パート、実戦パート）においてユーザに有利な効果をもたらすキャラクタ、すなわち、能力の高いキャラクタほど、上級の希少度が設定されている。本実施形態では、希少価値の高い等級から順に、「Ｓ」、「Ａ」、「Ｂ」、および、「Ｃ」のアルファベットで示された希少度が設定される。なお、希少度は、例えば、キャラクタ（カード）の入手困難性、より具体的には、キャラクタ（カード）が当たる抽選における当選確率、クエストまたはミッションのクリア報酬として入手される場合のクエストまたはミッションの難易度、または、有償で入手する場合の価格などと相関があってもよい。一般に、高価な、または、入手困難性が高いキャラクタ（カード）ほど、上級の希少度が設定されている。

＜ゲーム詳細＞
以下、実施形態のパズルゲームを具体的に説明する。図３（Ａ）は、後述する第３プレイパート進行部１１３によって表示されるパズル画面の一例である。このパズル画面は、複数のパズル要素３０１と、射出台３０２とを含む盤面によって構成される。複数のパズル要素３０１は、盤面内に配置される。各パズル要素３０１には、複数種類のキャラクタの何れかが表示されている。射出台３０２上には、キャラクタ要素３０３の何れかがセットされ得る。

なお、パズルゲームのプレイに際して、ユーザは、プレイに使用するキャラクタを選択する。制御部１１０は、ユーザが保有するキャラクタのうち、ゲームのプレイに使用するキャラクタを指定するためのユーザの第１の入力操作を受け付ける。たとえば、第３プレイパート進行部１１３は、保有しているキャラクタの一覧３０４から、射出台３０２にセットするキャラクタ要素３０３を選択可能な選択画面を表示部１５２に表示させる。ユーザがいずれかの当該キャラクタをタップすることにより、ゲームのプレイに使用するキャラクタが指定される。当該パズル画面では、ユーザのプレイに使用するキャラクタとして「ティア」が選択されていることが表示されている。そして、当該パズル画面には、選択しているキャラクタ「ティア」を囲む環状のゲージ３０７が表示されている。

図３（Ｂ）は、選択画面の一例である。選択画面は、保有しているキャラクタの一覧３０４を含む。この例では、一覧３０４は、「ティア」、「ハート」、「ルナ」の３つのキャラクタを含んでいる。なお、一覧３０４の中で「ティア」を示す図形の輪郭が太線となっているのは、当該キャラクタが選択されていることを示している。また、選択画面は、選択されたキャラクタに関するパラメータ表示３０５を含んでいる。また、選択画面は、選択されたキャラクタのキャラクタ要素３０３を射出台３０２にセットすることを指示する「セット」ボタン３０６を含んでいる。

第３プレイパート進行部１１３は、ユーザにより指定されたキャラクタおよび当該キャラクタに対応付けられている前記第１のパラメータに基づきゲームを進行させる。第３プレイパート進行部１１３は、このようなゲームプレイにおいて指定されたキャラクタを操作するための前記ユーザの第２の入力操作に応答してキャラクタを動作させる。第３プレイパート進行部１１３は、射出台３０２上のキャラクタ要素３０３が操作されると、当該キャラクタ要素３０３を射出させる。なお、制御部１１０は、当該オブジェクトを、当該第２の入力操作によらず自動的に動作させてもよい。

そして、第３プレイパート進行部１１３は、第１の条件が満たされることにより、ゲームプレイで使用される第２のパラメータを、第１のパラメータに基づき更新する。ゲームのプレイによりユーザが得点するパズルゲームであれば、第１の条件とは、ユーザが得点できる条件であり、当該第２のパラメータとは、そのパズルゲームにおけるユーザの得点である。ユーザの得点は、キャラクタが有するスコアに基づいて決まる。

たとえば、射出したキャラクタ要素３０３が複数のパズル要素３０１の少なくとも一部に衝突すると、衝突に応じて、複数のパズル要素３０１の配置を変更する。このとき、複数のパズル要素３０１のうち、射出されたキャラクタ要素３０３と同種のキャラクタが表示されたパズル要素３０１が、所定数以上連続して配置されれば、第３プレイパート進行部１１３は、それらのパズル要素３０１を盤面から除去する。第３プレイパート進行部１１３は、除去されたパズル要素３０１に応じてプレイ結果を算出する。プレイ結果は、例えば、連続して除去された同種のパズル要素３０１の個数（連鎖数）によって表される。

そして、第３プレイパート進行部１１３は、当該パズルゲームにおいて、ユーザの得点が第２の条件を満たすことにより、ゲームプレイをクリアしたか否かを判定する。たとえば、第３プレイパート進行部１１３は、ユーザの得点が所定の値まで達したら、そのパズルゲーム（ステージ）がクリアされたと判定する。この場合、第２の条件は、そのパズルゲームにおけるユーザの総得点が当該所定の値を超えること、である。

なお、射出台３０２上にセット可能なキャラクタ要素３０３は、ユーザが保有しているキャラクタの何れかであってもよいし、ユーザが選んだキャラクタを含む複数のキャラクタの群から第３プレイパート進行部１１３が選択する任意のキャラクタであってもよい。

図３（Ｂ）に示される例では、パラメータ表示３０５には、「ティア」に関するパラメータとして、レベルが２３であることと、得点単価（以下、「スコア」とも言う）が４５４であることと、スキルレベルが３であることとが表示されている。レベルが高くなるとスコアが高くなる。スキルレベル、スコアは本発明における第１のパラメータの一態様であり、レベルは第１のパラメータとは異なる第３のパラメータとしてキャラクタに関連付けられている。このように、第１のパラメータは、キャラクタに関連付けられた第３のパラメータの更新に伴って更新されるものがあってもよく、なくてもよい。本実施形態では、第３のパラメータの更新によらずに第１のパラメータを更新することが可能であるが、この処理については後述する。

レベルは、当該キャラクタが最初にユーザに付与されたときには、初期値（例えば、１）が設定される。また、レベルは、例えば、当該キャラクタによるプレイ中の累計得点に応じてアップする。また、レベルは、例えば、当該キャラクタと同一のキャラクタがユーザに付与されたときにアップする。さらに、レベルは、「１０」を上限値とする。レベル１０に達したキャラクタのパラメータ表示３０５では、レベルは「ＭＡＸ」と表示される。

得点単価は、パズル要素３０１がプレイにおいて盤面から除去されたときの得点の単価である。得点単価は、レベルアップに伴い増加する。当該パズルゲームでは、ユーザの得点として、盤面から除去されたパズル要素３０１のスコアの積算値が計上される。よって、キャラクタのスコアは、高いほどパズルゲームの得点を高くすることができるので、ゲームを有利に進行させることが可能である。当該スコアは、キャラクタのパラメータに該当する。

一方、当該パズルゲームの得点には、スキルレベルに関する得点も含まれる。前述のゲージ３０７は、スキルに関するものであり、ユーザが選択した特定のパズル要素３０１（ティア）を盤面から除去したときに増加する。ゲージ３０７が満たされると、「ティア」のスキルが発動可能となる。

「スキル」は、パズル要素３０１に特有の技であり、一般に、盤面からパズル要素３０１を効果的に除去するための特殊効果を伴う。そして、「スキル」の効果は、スキルレベルが高いほど高くなる。よって、キャラクタのスキルレベルは、高いほどゲームを有利に進行させることが可能である。当該スキルレベルは、キャラクタのパラメータに該当する。スキルを発動すると、ゲージ３０７は空の状態に戻る。

ユーザがキャラクタを獲得すると、このような選択画面の一覧３０４に、新たなキャラクタが追加される。

なお、ゲームのプレイにおいて、使用されるパラメータおよび設定される条件は、ゲームの種類およびゲームのプレイに応じて適宜に設定され得る。たとえば、アクションゲームなどの、敵キャラクタとの格闘または他のユーザとの対戦を含むゲームでは、ゲームのプレイで使用される第２のパラメータは、ゲーム内における敵キャラクタの体力値であり得る。この場合、第１の条件を、ユーザが指定した、あるいは操作するキャラクタによる攻撃が成功すること、とし、第１のパラメータをユーザが指定、操作するキャラクタの攻撃力とすると、第２のパラメータとしての敵キャラクタの体力値は、ユーザのキャラクタによる攻撃が成功することにより、当該ユーザのキャラクタの攻撃力に応じて減じるように更新される。そして、敵キャラクタの体力値がゼロまで減じることを第２の条件とすると、ユーザのキャラクタの攻撃によって敵キャラクタの体力値がゼロまで減じたことにより、第３プレイパート進行部１１３は、ゲームのプレイ（敵キャラクタとの格闘）をクリアしたと判定する。

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

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

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

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

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

制御部２１０は、ゲームプログラム１３１の記述に応じて、進行支援部２１１、同期制御部２１２、および、パラメータ算出部２１３として機能する。制御部２１０は、実行するゲームの性質に応じて、ユーザ端末１００におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。たとえば、サーバ２００は、所定の条件に基づいて、ユーザに関連付けられるオブジェクトを選択することを、ユーザ端末１００からの要求に応じて実行するブロックとして機能することが可能である。所定の条件に基づくオブジェクトを選択する方法としては、例えば、抽選、所定の優先度に基づく選択等が挙げられる。本実施形態では当該方法として抽選をする形態について説明する。

進行支援部２１１は、ユーザ端末１００と通信し、ユーザ端末１００が、本ゲームに含まれる各種のプレイパートを進行させるための支援を行う。例えば、上述の各プレイパートのいずれが実行されているのかに応じて、そのときにユーザ端末１００が参照すべき情報を適宜提供する。

同期制御部２１２は、ＰｖＰ戦において、対戦する各ユーザ端末１００と通信して、ユーザ端末１００同士のやりとりを仲介する。さらに、同期制御部２１２は、対戦相手のマッチング、対戦の進行状況の同期をとるための同期制御などを実行する。

パラメータ算出部２１３は、ユーザ端末１００からの要求に応じて、またキャラクタが有している第１のパラメータに応じて、キャラクタの第１のパラメータの更新すべき値を算出する。以下、更新すべき値を「更新量」といい、更新が増加であるときは「増加量」ともいう。本実施形態ではキャラクタのレベルの増加に伴わずに第１のパラメータの一態様であるスキルレベルおよびスコアを増加させることができる。パラメータ算出部２１３は、必要に応じて、第１のパラメータの更新回数、第１のパラメータの上限、および、更新回数に対する第１のパラメータの増分の割合などの種々の設定条件を参照し、第１のパラメータの更新量を算出する。

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

制御部１１０は、ゲームプログラム１３１の記述に応じて、第１プレイパート進行部１１１、第２プレイパート進行部１１２、第３プレイパート進行部１１３、第４プレイパート進行部１１４、および、第５プレイパート進行部１１５として機能する。

なお、制御部１１０は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。例えば、制御部１１０は、第６プレイパート進行部、および、第７プレイパート進行部として機能してもよい。

さらに、制御部１１０は、図示しない操作受付部、および、表示制御部などとしても機能する。操作受付部は、入力部１５１に対するユーザの入力操作を検知し受け付ける。例えば、操作受付部は、上述の入力操作の、入力部１５１における入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部は、例えば、タッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。表示制御部は、タッチスクリーン１５の表示部１５２に対して、制御部１１０の各部によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部は、制御部１１０の各部によって生成された映像を含むゲーム画面を表示部１５２に表示してもよい。また、表示制御部は、グラフィカルユーザインターフェース（以下、ＧＵＩ）を、該ゲーム画面に重畳して描画してもよい。

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

第２プレイパート進行部１１２は、各種オブジェクトの制御態様に基づいて、各種オブジェクトのモーションを示すアニメーションを生成する。例えば、抽選が実行されている様子を表現したアニメーション等を生成してもよい。

第３プレイパート進行部１１３は、ゲームをプレイするプレイ画面を生成する。また、第３プレイパート進行部１１３は、プレイ画面に対する操作に応じて、ゲームを進行する。また、第３プレイパート進行部１１３は、ゲームの１プレイが終了すると、そのプレイにおける成績等を表すプレイ結果を算出する。なお、ここで言うゲームの１プレイとは、そのゲームにおいて定められたプレイの単位の１回分を指すものとする。たとえば、当該ゲームの１プレイとは、ユーザの操作に応じて、所定の条件をクリアするまでのゲームの進行であり、パズルゲームであれば、ユーザの操作に応じて所定の値の得点を獲得するまで、であってよく、アクションゲームであれば、所定の敵キャラクタの体力値がゼロになるまで、であってよい。

第４プレイパート進行部１１４は、ユーザの操作に応じて、または、ゲームのプレイに伴って、オブジェクトのパラメータに関する種々の処理を実行する。また、第４プレイパート進行部１１４は、サーバ２００のパラメータ算出部２１３に当該パラメータの算出を要求する。

第５プレイパート進行部１１５は、ユーザの入力に応じてサーバ２００へ抽選の実行を要求し、サーバ２００からの抽選結果を受け付けるとともにその判定および確定を実行する。

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

＜処理概要＞
本実施形態において、ゲームプログラム１３１は、ユーザに保有されるオブジェクトに対応付けられている第１のパラメータを、ゲームプレイが有利に進められるように更新する。本実施形態ではオブジェクトがキャラクタである形態について説明する。また、第１のパラメータとして、本実施形態では、スコア、スキルレベルである形態について説明するが、本発明における第１のパラメータはこれに限定されず、例えば、敵と戦闘するゲームであれば攻撃力、防御力、レースゲームであればスピード等、ユーザが使用するオブジェクトに対応付けられる各種のパラメータを採用できる。

ゲームシステム１において、第１のパラメータを更新する処理には２通りある。説明の便宜上、「処理Ａ」及び「処理Ｂ」という。処理Ａは、当該オブジェクトの重複保有をさせないこと、または、重複保有を解消することにより、ユーザに関連づけられた消費アイテムの消費に基づいてゲームプレイが有利に進められるように更新する処理である。消費アイテムは、ゲーム内価値に該当し、後に説明する。「重複保有をさせない」とは、例えば、既に保有するオブジェクトと同じオブジェクトを保有するための条件を満たしたときに、当該同じオブジェクトを保有させないという形態が挙げられる。たとえば、制御部１１０は、ユーザが既に保有しているキャラクタと同じキャラクタが新たに選択されることに応じた設定値の分だけ、当該同じキャラクタを重複して保有させる代わりとして、当該同じキャラクタを保有させずに、既に保有しているキャラクタのスコアおよびスキルレベルを増加させる。

また、「重複保有を解消する」とは、例えば、予め同一のオブジェクトを重複して保有するときに、重複しているオブジェクトのうちの一部の保有を解消する形態が挙げられる。なお、本実施形態は、特定のキャラクタを含む複数のキャラクタのうち何れか１つを抽選するステップをさらに含む。そして、選択するステップで選択されたキャラクタが、ユーザが保有するキャラクタと重複する場合に、当該選択されたキャラクタを保有させずに、プレイが有利に進められるようにパラメータを更新する。

処理Ｂは、第１のパラメータを、前述した重複保有をさせないこと又は重複保有を解消することによらず、第１の課金処理によって、または、第１の課金処理とは異なる第２の課金処理に基づいてユーザに付与される消費アイテムを消費することによって、更新させる処理である。当該消費アイテムは、ユーザの操作に基づく第２の課金処理に基づいてユーザによって付与されるものである。ユーザは、課金によってオブジェクトの第１のパラメータを迅速に高めることができ、それにより、より一層有利なプレイを期待することができる。よって、ゲームの興趣性を高めることができる。また、ユーザの課金に対する満足度をより向上させることができる。本実施形態において、処理Ｂは、課金処理によって第１のパラメータを更新させる前者であってよいが、以下の説明では、第２の課金処理によってユーザに付与された消費アイテムを消費して第１のパラメータを更新させる後者として説明する。

本実施形態では、処理Ａ及び処理Ｂにおいて、第１のパラメータの更新を行なうことを、「限界突破」ともいい、最小単位の第１のパラメータの更新の回数を「限界突破数」という。

＜処理フロー＞
図４は、本実施形態における、ユーザに関連づけられた消費アイテムの消費に基づいて第１のパラメータを更新する処理の一例を示すフローチャートである。本実施形態において、「パラメータを更新する」とは、パラメータを増加させることである。ゲームプログラム１３１は、スコアおよびスキルレベルを、課金処理によりユーザに付与される消費アイテムを消費することにより更新させる処理を実行させる。

まず、ステップＳ４０１において制御部１１０は、消費アイテムの取得処理として、ユーザの操作に基づく課金処理に基づいて、消費アイテムをユーザによって保有されるものとしてユーザに関連付けてメモリ１１に記憶させる。この処理により、消費アイテムは、ユーザに付与される。

消費アイテムは、例えばコインや宝石を模したオブジェクトであり得る。本実施形態では、消費アイテムは宝石を模したオブジェクトとする。消費アイテムは、ゲームのプレイに伴ってユーザが無償で入手することが可能であるものとする。当該消費アイテムの取得処理は、より詳細には、例えば図５に示すフローにしたがって実行される。図５は、本実施形態における消費アイテムの取得処理の一例を示すフローチャートであり、ユーザの課金により消費アイテムを有償分として取得する。

ステップＳ５０１において、制御部１１０は、消費アイテム取得を指示するユーザからの操作を受け付けたか否かを判定する。当該操作を受け付けた場合では、ステップＳ５０２において、制御部１１０は、消費アイテム取得のための課金処理を指示する操作を受け付けたか否かを判定する。

ステップＳ５０２において課金処理を指示する操作を受け付けた場合には、ステップＳ５０３において、制御部１１０は、ユーザが有償によって消費アイテムを取得したものとして、取得した消費アイテムを消費アイテムの有償分としてメモリに記憶させる。次に、制御部１１０は、図４に示すフローに復帰する。

一方で、ステップＳ５０１またはステップＳ５０２においてユーザからの操作を受け付けなかった場合も、制御部１１０は、図４に示すフローに復帰する。

ステップＳ４０２において、制御部１１０は、第１のパラメータの更新を可能とするために必要な消費アイテムの消費に関する条件（消費可能条件）を満たしたか否かを判定する。ここで、消費可能条件とは、例えば、一回の限界突破に必要な数以上の消費アイテムをユーザが保有していること、が挙げられる。

ステップＳ４０２において消費可能条件を満たすと判定した場合では、ステップＳ４０３において、制御部１１０は、消費可能条件を満たす消費アイテムの消費によってスコアおよびスキルレベルを増加する指示の操作を受け付けたか否かを判定する。

ここで、制御部１１０は、ユーザが保有するキャラクタのスコアおよびスキルレベルを含むステータスとともに、課金処理に基づいてユーザに付与された消費アイテムの消費によってスコアおよびスキルレベルを更新させること、を指示するためのＵＩを表示するステップをさらに実行してもよい。

図９（Ａ）は、キャラクタ「ベア」のステータスを示す画面である。この画面９００は、キャラクタであるベアの画像９０１と、そのステータスを表示するステータス表示９０２と、三つのＵＩ９０３〜９０５とを含んでいる。ＵＩ９０３〜９０５は、いずれも、消費アイテムの消費によるパラメータ増加を指示するためのＵＩである。ユーザは、消費アイテム有償分の消費によるパラメータ増加を指示するべく、ＵＩ９０３をタッチする。

ＵＩ９０３のタッチ操作を受け付けると、制御部１１０は、画面９００にウインドウ９１１を重ねて表示する。ウインドウ９１１は、「消費アイテム有償分１０個を消費」して「ベア」の限界突破値を「１０」高める旨のメッセージと、パラメータ更新操作を指示するためのＵＩ９１２と、当該操作を止めることを指示するためのＵＩ９１３とを含む。ユーザがＵＩ９１２をタッチすると、制御部１１０は、パラメータ更新のための処理を引き続き実行する。

すなわち、ユーザがＵＩ９１２をタッチすると、ステップＳ４０４において、制御部１１０は対象のキャラクタについて、スコアおよびスキルレベルの増加分をサーバ２００に要求する。ステップＳ４０５において、パラメータ算出部２１３は、対象キャラクタについて、スコアおよびスキルレベルの増加分を決定する処理を実行する。

ステップＳ４０５において、パラメータ算出部２１３は、消費アイテムの消費量に応じて対象キャラクタのスコアおよびスキルレベルを増加させればよい。これらのパラメータごとに更新方法が定められている場合は、パラメータ算出部２１３は、定められた更新方法に基づいてパラメータの増加分を決定する。

たとえば、本実施形態において、スキルレベルには、スキルレベルの更新可能な値に上限値「１０」が設定されている。よって、ステップＳ４０５において、パラメータ算出部２１３は、対象キャラクタの更新前におけるスキルレベルが１０未満か否かを判定する。そして、パラメータ算出部２１３は、更新前のスキルレベルが１０未満であれば、ステップＳ４０６において、スキルレベルの決定すべき増加量を前述した設定値の分と決定し、更新前または更新後のスキルレベルが１０以上となる場合には、スキルレベルの算出値をその上限値である「１０」に決定する。

上記のようなスキルレベルの更新は、当該上限値までは課金によって高めることができ、それ以上は、課金によって高めることができなくなる。よって、スキルレベルが上限値に至らないうちはユーザの課金に対する満足度を高めることができる。しかしながら、課金によってスキルレベルが増加し続けられると、課金をするユーザのゲームの進行が有利になりすぎ、かえってゲームの興趣性が損なわれる。よって、スキルレベルを課金によって増加できる範囲に上限値が設定されることで、結果的にゲームの興趣性が適切に保たれる。

本実施形態では、第１のパラメータの更新可能な値に上限値が設定されている形態について説明したが、更新可能な値の制限はさまざまに設定し得る。例えば、処理Ｂによる更新の上限値と、処理Ａによる更新の上限値とが異なる形態でもよい。このような形態の具体例としては、例えば、上限値が＋１００であり処理Ｂでは＋１０まで第１のパラメータを更新できるものとしてもよい。

本実施形態では、スコアの更新には、更新前のスコアの数値に応じて異なるスコア増加の割合が設定されている。より具体的には、本実施形態では、前述の処理Ｂにおいて、第１のパラメータの値が所定値以下の場合に、所定量の消費アイテムを消費することにより第１のパラメータを第１の量だけ更新し、第１のパラメータの値が当該所定値を超えている場合に、当該所定量の消費アイテムを消費することにより、第１のパラメータを第１の量よりも小さい第２の量だけ更新する。このようなスコアの更新により、有償分の消費アイテムの単位消費量当たりのスコアの更新量は、スコアの更新量の合計値が所定値以下のときよりも、合計値が所定値を超したときの方が小さくなる。以下、このようなスコアの更新のフローについて説明する。図７は、本実施形態における、異なる割合に応じて第１のパラメータ値の増加分を決定する処理の例を示すフローチャートである。

当該処理例において、スコアの増加は、図８に示す成長線Ｌ１にしたがって決められる。図８は、横軸を限界突破数とし、縦軸をスコアとしており、関係の一例を示す図である。図示されている線Ｌ１は、キャラクタの成長線とも言う。成長線Ｌ１は、限界突破数が１００までの部分である線分Ｌ１１と、限界突破数が１００以上の部分である線分Ｌ１２とを含む。線分Ｌ１１の増分は、線分Ｌ１２のそれに比べて明らかに大きい。成長線Ｌ１は、限界突破数１００までの間では、スコアはより大きく増加し、限界突破数が１００よりも大きくなると、スコアはより小さく増加することを表している。なお、図８中の限界突破数は、消費アイテムの消費数の絶対値と一対一で対応している。すなわち、限界突破数は、消費アイテムを１０個消費すると１０増加する。また、図８中、Ｓ_０は、キャラクタが有するスコアの初期値である。さらに、成長線Ｌ１は、二つの直線の連結で構成されているが、これに限定されず、例えば、一直線であってもよいし、連続する曲線であってもよいし、直線部とそれを連結する曲線部とから構成されてもよい。

ステップＳ７０１において、パラメータ算出部２１３は、算出前における限界突破数（前述の「ベア」であれば１８）と、消費アイテムの有償分を消費した量に応じて増加後の限界突破値を算出する。前述したように、消費アイテムを一つ消費したら限界突破数を一つ増やし、１０個消費したら１０増やす。

次いで、ステップＳ７０２において、パラメータ算出部２１３は、算出前の限界突破数が１００未満か否かを判定する。算出前の限界突破数が１００未満であれば、ステップＳ７０３において、パラメータ算出部２１３は、線分Ｌ１１における変化の割合に基づいて増加後のスコア値を算出する。

一方、算出前の限界突破数が１００以上であると、ステップＳ７０４において、パラメータ算出部２１３は、線分Ｌ１２における変化の割合に基づいて増加後のスコア値を算出する。線分Ｌ１２における変化の割合は、図８から明らかなように、線分Ｌ１１における変化の割合に比べて十分に小さい。よって、スコアについては、線分Ｌ１１に対応する限界突破数のうちは、課金によるスコアの増加量が十分に大きい。しかしながら、線分Ｌ１２に対応する限界突破数に至ると、課金によるスコアの増加量は線分Ｌ１１ほどに大きくはなくなる。よって、線分Ｌ１１に対応する限界突破数ではユーザの課金に対する満足度をより高められる一方で、線分Ｌ１２に対応する限界突破数では、課金処理によるスコアの増加が抑制される。よって、課金をするユーザのゲームの進行が有利になりすぎ、かえってゲームの興趣性が損なわれることが抑制されるので、ゲームの興趣性が適切に保たれる。

増加後のスコア値を算出すると、制御部２１０は、図４に示すフローに復帰する。ステップＳ４０６において、進行支援部２１１は、算出したスコア値をユーザ端末の制御部１１０に通知する。

次いで、第４プレイパート進行部１１４は、スコアおよびスキルレベルを、課金処理によりユーザに付与される消費アイテムを消費することにより更新させる処理を実行する。本実施形態では、ステップＳ４０６において決定したスキルレベルおよびスコアの増加分がサーバ２００から通知されると、ステップＳ４０７において、第４プレイパート進行部１１４は、通知結果を表示部１５２に表示させる。

ここで制御部１１０は、図９（Ｂ）の画面９００から図１０に示す画面１０００を表示部１５２に表示させる。画面１０００は、「ベア」の画像９０１以外に、更新前後のパラメータの表示１００２と、パラメータ更新後における消費アイテム有償分の個数の表示１００３とを含んでいる。表示１００２は、ベアの限界突破数が１８から２８に増加したこと、ベアのスコアが１８００から２８００に増加したこと、および、ベアのスキルレベルが６から９に増加したこと、を表示している。表示１００３は、ユーザが保有する消費アイテムの有償分を１０個消費したこと、および、当該有償分の数が８に減少したこと、を表示している。

本実施形態において、抽選で重複するキャラクタが選択された場合では、ユーザにそのキャラクタを重複保有させずに、新たに選択されたキャラクタを、ユーザが保有する同種のキャラクタのパラメータの更新に自動的に使用する。たとえば、ユーザがキャラクタ「ベア」をすでに保有していて、その限界突破数は１８、スコアは１８００、スキルレベルは６、とする。そして、例えば抽選によって、図１２（Ｂ）に示す「ベア」が新たにユーザに選択されたとする。新たに選択されたベアは、画面１２００に表示されるがユーザには付与されず、ユーザが既に保有している「ベア」のパラメータの更新に供される。具体的には、図１２（Ｂ）に示されるように、画面１２１０の表示１２１１において、ユーザが既に保有している「ベア」の限界突破数が１つ増えて１９となり、スコアが１００増えて１９００となる。ただし、「ベア」のスキルレベルは、スコアが約３００増加することにより一つ上がる程度の割合で増加する。このため、この場合でのスキルレベルは、６のまま変わらない。

次いで、ステップＳ４０８において、制御部１１０は、メモリ１１に記憶させている消費アイテムを減算してメモリ１１に記憶させ、また、パラメータ値の通知された増加分をメモリに記憶させる。

前述した図４に示される処理例によれば、ユーザは、課金によってキャラクタのパラメータ（スコアおよびスキルレべル）を迅速に高めることができる。それにより、より一層有利なプレイが期待され、その結果、ゲームの興趣性が高められ、またユーザの課金に対する満足度も高められる。

また、制御部１１０は、キャラクタのステータス表示画面にパラメータの更新のためのＵＩをさらに表示部１５２に表示させることで、ユーザは、自身が保有するキャラクタのスコアおよびスキルレベルの増加の必要性を容易に確認することが可能である。そして、課金によって容易にこれらのパラメータを高めることが可能となる。よって、課金によって上記のパラメータを高めることの利便性がより高められる。

［有償分のアイテムの間で第１のパラメータの更新量を区別する処理例］
本実施形態は、第１のパラメータの更新に利用可能な消費アイテム以外の特定のアイテムをさらに含んでいてもよい。たとえば、制御部１１０は、第１のパラメータの更新に利用可能な特定のアイテムを、消費アイテムを消費することによってユーザに付与するステップを実行させてもよい。この場合、前述した更新させるステップにおいて、制御部１１０は、特定のアイテムを消費するためのユーザの入力操作に応答して第１のパラメータを更新させる。以下、このような特定のアイテムに係る処理を「処理Ｃ」とも言う。このような構成によれば、第１のパラメータを増加させる方法をより多様化することが可能である。

上記の場合、消費アイテムによる第１のパラメータの更新と、特定のアイテムによる第１のパラメータの更新とに差を設けてもよい。すなわち、本実施形態では、処理Ｂにおいて、所定量の消費アイテムを消費することにより、第１のパラメータを第１の量だけ更新し、当該所定量の消費アイテムを消費することに基づいてユーザに付与される量の前述の特定のアイテムを消費して、第１のパラメータを、当該第１の量よりも小さい第３の量だけ更新してもよい。このような処理によれば、消費アイテムを消費してキャラクタのパラメータを更新させる処理と、特定アイテムを消費してキャラクタのパラメータを更新させる処理とを比べたときに、パラメータを同量増加させるために必要な課金額は、前者の方がより小さくなる。

たとえば、第４プレイパート進行部１１４は、上記の二つの処理のそれぞれについて、限界突破数に対する消費アイテムの消費数との比率（前述では１／１）に比べて、限界突破数に対する特定アイテムの消費数との比率を実質的に小さく設定する。たとえば、前者の処理では、前述したように、消費アイテムを一単位（１０個）消費すると限界突破数が１０高まると設定されている。一方、後者の処理では、特定アイテムを一単位（１枚）消費すると限界突破数が８しか高まらない、と設定されてもよい。なお、消費アイテムの一単位と特定アイテムの一単位との購入額は同じとする。

消費アイテムをパラメータの更新（前者）の処理例に使用すると、図１１に示されるように、限界突破数は１８から２８へ１０増加し、スコアは１８００から２８００へ１０００増加し、スキルレベルは６から９へ３増加する。

一方で、特定アイテムをパラメータの更新（後者）の処理例に使用する場合では、例えば、ユーザは、図９（Ａ）に示す画面９００におけるＵＩ９０５をタッチして、スペシャルチケットを１枚消費してパラメータを更新する操作を指示する。制御部１１０は、ＵＩ１００５に対するユーザのタッチ操作を受け付ける。次に、制御部１１０は、図１１（Ａ）に示す画面１１００を表示部１５２に表示させる。画面１１００は、ウインドウ１１０１が画面９００に重なって表示されるように構成されており、ウインドウ１１０１は、スペシャルチケットを消費する旨を示し、ＵＩ１１０２、１１０３を含む。それら以外は、画面１１００は、前述した図９（Ｂ）の画面と同様である。

次に、ユーザによる当該操作を指示するためのＵＩ１１０２に対するタッチ操作を制御部１１０が受け付けると、制御部１１０は、図１１（Ｂ）に示す画面１１１０を表示させる。画面１１１０は、更新前後のパラメータの数値の表示１１１１と、スペシャルチケットを消費した旨の表示１１１２とを含んでいる。表示１１１１では、限界突破数は１８から２６へ８増加し、スコアは１８００から２６００へ８００増加し、スキルレベルは６から８へ２増加している。このように、いずれのパラメータも、前者の処理例の増加量（更新量）の方が後者の処理例のそれよりも大きい。よって、パラメータの単位更新量における課金額は、消費アイテムのそれの方が特定アイテムのそれよりも安価である。

上記の処理例によれば、ユーザにとって、所定値までパラメータを高める場合に、課金により入手した特定アイテムによってパラメータを増加させるのに比べて、課金（消費アイテムの有償分）によりパラメータを増加させる方が安価となる。よって、ユーザは課金処理によってパラメータを高めやすい。

［消費アイテムの由来によってパラメータの更新量を区別する処理例］
本実施形態では、制御部１１０は、ゲームのプレイに伴い、課金処理によらず消費アイテムをユーザに関連付けてメモリに記憶させる処理をさらに実行させもよい。この場合、第４プレイパート進行部１１４は、前述の更新させるステップにおいて、課金処理によりユーザに付与される消費アイテムを所定量消費することにより、第１のパラメータを第４の量だけ更新し、課金処理によらずユーザに付与される消費アイテムを所定量消費することにより、第１のパラメータを、当該第４の量とは異なる第５の量だけ更新してもよい。このような処理によれば、課金処理に基づいて付与された消費アイテムを消費した場合のパラメータ更新量は、ゲームのプレイに基づいて付与された消費アイテムを消費した場合の更新量に対して異なる量となる。

この場合では、消費アイテムの消費可能条件を満たすか否かの判定する処理は、図４のフローにおけるステップＳ４０２に代えて、図６に示すフローにしたがって実行される。図６は、本実施形態における消費アイテムの消費可能条件を判定する処理の一例を示すフローチャートである。

図６に示されるように、ステップＳ６０１において、制御部１１０は、消費アイテムの有償分がパラメータを高めるための消費可能条件を満たすか否かを判定する。ステップＳ６０２において、制御部１１０は、消費アイテムの無償分がパラメータを高めるための消費可能条件を満たすか否かを判定する。

消費アイテムの有償分または無償分の消費可能条件が満たされている場合には、ステップＳ６０３において、制御部１１０は、当該消費可能条件を満たすと判定し、図４に示すフローに復帰する。消費アイテムの有償分または無償分の消費可能条件が満たされていない場合には、ステップＳ６０４において、制御部１１０は、当該消費可能条件を満たさないと判定し、図４に示すフローに復帰する。

消費アイテムの有償分の消費とそれによるパラメータの更新は、前述した形態のように実施可能である。一方、消費アイテムの無償分の消費とそれによるパラメータ（スコア）の更新では、例えば、前述の図８における成長線Ｌ１より傾きの大きな成長線が適用されてもよい。このようにパラメータの更新の設定を異ならせることにより、ユーザは、無償分の消費アイテムを入手することにも意欲的となり、ゲームをプレイする動機づけがより強まる。

このように、上記の処理例では、ゲームのプレイに伴って入手した消費アイテムをパラメータの増加に使用することが可能となる。また、ユーザが入手した消費アイテムの由来を合わせてパラメータの更新量を適宜に設定することが可能となる。

また、前述の説明とは逆に、課金による消費アイテムの使用をより有利にしてもよい。この場合は、ユーザの課金に対する満足度がより一層高められる。このように、ユーザの課金に対する満足度と、ゲームの興趣性との適正化を図ることが可能となる。

〔変形例〕
本発明では、前述した実施形態における所定量の消費アイテムを消費することにより第１のパラメータを更新することに代えて、所定額の課金による課金処理によって第１のパラメータを更新してもよい。当該課金処理は、消費アイテムをユーザが保有するための課金処理とは異なる。この場合、消費アイテムの消費を介さずに直接課金処理によって第１のパラメータを更新することが可能となる。よって、処理Ｂのためのユーザの課金処理が不要となり、ユーザの課金処理がより簡素化される。

なお、特定のアイテムは、課金処理または消費アイテムの消費以外にも、ゲームのプレイに伴ってユーザに付与されてもよい。そして、前述した本発明の実施形態と同様に、課金処理によらない特定のアイテムと、課金処理による特定アイテムとの間で、それを消費したときの第１のパラメータの更新量に差を付けてもよい。

また、前述の本発明の実施形態は、前述したパズルゲームを例に、キャラクタをユーザに重複して保有させずに当該キャラクタのパラメータを更新させる形態を説明した。たとえば、第５プレイパート進行部１１５は、特定のキャラクタを含む複数のキャラクタのうち何れか１つを選択するステップをさらに実行する。そして、第４プレイパート進行部１１４は、新たに選択されたキャラクタが、ユーザが保有するキャラクタと重複する場合に、当該選択されたキャラクタを保有させずに、パラメータを更新する。このように、前述の実施形態では、ユーザに対して新たに選択されたキャラクタが、ユーザによって既に保有されているキャラクタと同じである場合に、当該キャラクタをユーザに付与せず、パラメータを自動的に更新している。しかしながら、本発明におけるキャラクタの重複に係るパラメータの更新は、前述の実施形態に限定されない。

たとえば、本発明におけるキャラクタと当該キャラクタの重複によるパラメータの更新では、ユーザが保有するキャラクタの重複を解消する形態にも適用可能である。たとえば、制御部１１０は、ユーザが保有する重複する複数のキャラクタから一のキャラクタを残して残りのキャラクタを消費することで、当該キャラクタの重複保有を解消してもよく、このようにして重複保有を解消させることにより、第４プレイパート進行部１１４は、保有するキャラクタのパラメータを更新してもよい。この場合、パラメータを更新する方法が多様になり、より多種のゲームに適用することが可能となることから、ゲームの興趣性を高める観点からより好ましい。

また、本発明におけるキャラクタと当該キャラクタの重複によるパラメータの更新では、ユーザに新たに選択される重複保有されるオブジェクトに代えてパラメータの更新に使用されるアイテムをユーザに付与することでオブジェクトを重複保有させない形態にも適用可能である。たとえば、第５プレイパート進行部１１５は、特定のキャラクタを含む複数のキャラクタのうち何れか１つを選択するステップをさらに実行する。そして、制御部１１０は、ユーザに新たに選択されたキャラクタが、ユーザが既に保有するキャラクタと重複する場合に、当該選択されたオブジェクトの代わりにパラメータを更新させるアイテムをユーザに付与してメモリ１１に記憶してよい。そして、制御部１１０がユーザの操作に応じて当該アイテムを消費し、第４プレイパート進行部１１４が、ユーザが保有するキャラクタのパラメータの更新を実行する。この場合も、パラメータを更新する方法が多様になり、より多種のゲームに適用することが可能となることから、ゲームの興趣性を高める観点からより好ましい。

〔ソフトウェアによる実現例〕
制御部２１０の制御ブロック（特に、パラメータ算出部２１３）、ならびに、制御部１１０の制御ブロック（特に、第４プレイパート進行部１１４）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。

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

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

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

（項目１） ゲームプログラム（１３１）について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ（１０、２０）およびメモリ（１１、２１）を備えるコンピュータ（ユーザ端末１００およびサーバ２００の少なくとも一方）により実行される。ゲームプログラムは、プロセッサに、ゲームプレイにおいてユーザが利用可能なオブジェクトをユーザに付与されるものとしてメモリに記憶させるステップと、ユーザに保有されるオブジェクトに対応付けられている第１のパラメータを、当該オブジェクトの重複保有をさせないこと、または当該オブジェクトの重複保有を解消することによりゲームプレイが有利に進められるように更新し、更新後の第１のパラメータをメモリに記憶させるステップと、当該重複保有をさせないことまたは当該重複保有を解消することによらず、課金処理によりまたは課金処理によりユーザに付与されるゲーム内価値を消費することにより、第１のパラメータを更新させるステップと、を実行させる。これにより、ユーザは、課金によってオブジェクトの第１のパラメータを迅速に高めることができ、それにより、より一層有利なプレイを期待することができる。よって、ゲームの興趣性を高めることができる。また、ユーザの課金を行なうことに対する満足度を高めることができる。

（項目２） （項目１）において、ゲームプログラムは、プロセッサに、ユーザが保有するオブジェクトのうち、ゲームプレイに使用するオブジェクトを指定するためのユーザの第１の入力操作を受け付けるステップと、ユーザにより指定されたオブジェクトおよび当該オブジェクトに対応付けられている第１のパラメータに基づきゲームを進行させるステップと、をさらに実行させ、進行させるステップは、ゲームプレイにおいて指定されたオブジェクトを操作するためのユーザの第２の入力操作に応答して、または、第２の入力操作によらず自動的にオブジェクトを動作させるステップと、第１の条件が満たされることにより、ゲームプレイで使用される第２のパラメータを、第１のパラメータに基づき更新するステップと、第２のパラメータが第２の条件を満たすことにより、ゲームプレイをクリアしたか否かを判定するステップとを含んでもよい。この構成によれば、ユーザがゲームプレイで操作するオブジェクトのパラメータが課金によって高められる。よって、ユーザは、自身が操作するオブジェクトの強化を課金により迅速に高めることができ、ユーザの課金を行なうことに対する満足度がより一層高まる。

（項目３） （項目１）または（項目２）において、前述の更新させるステップでは、第１のパラメータが第１の値以下の場合に、ゲーム内価値の消費に基づく更新を可能とし、第１のパラメータが第１の値を超えている場合に、ゲーム内価値の消費に基づく更新を実行しない構成としてもよい。この構成によれば、ユーザは、当該第１の値までは課金によって第１のパラメータを高めることができ、それ以上は課金によって高めることができなくなる。よって、ユーザの課金を行なうことに対する満足度を高めつつ、ゲームの興趣性を適切に保つことができる。

（項目４） （項目１）または（項目２）において、前述の更新させるステップでは、第１のパラメータの値が所定値以下の場合に、所定額の課金処理により、または所定量のゲーム内価値を消費することにより、第１のパラメータを第１の量だけ更新し、第１のパラメータの値が当該所定値を超えている場合に、当該所定額の課金処理により、または当該所定量のゲーム内価値を消費することにより、第１のパラメータを第１の量よりも小さい第２の量だけ更新してもよい。この構成によれば、ユーザは、第１のパラメータの値が当該所定値までは課金によって第１のパラメータをより多く高めることができ、当該所定値を超える場合は課金によってさほどに大きくは第１のパラメータを高めることができなくなる。よって、ユーザの課金を行なうことに対する満足度を高めつつ、ゲームの興趣性を適切に保つことができる。

（項目５） （項目１）から（項目４）までのいずれか１項目において、ゲームプログラムは、プロセッサに、さらに、第１のパラメータの更新に利用することが可能な特定のアイテムを、課金処理により、またはゲーム内価値を消費することによってユーザに付与するステップを実行させ、前述の更新させるステップにおいて、特定のアイテムを消費するためのユーザの入力操作に応答して、第１のパラメータを更新させてもよい。この構成によれば、ユーザは、ゲームプレイに伴って獲得した特定のアイテムの使用によっても第１のパラメータを高めることが可能となる。よって、第１のパラメータを増加させる方法が多様になるので、ゲームの興趣性が向上する。

（項目６） （項目５）において、前述の更新させるステップでは、所定額の課金処理により、または所定量のゲーム内価値を消費することにより、第１のパラメータを第１の量だけ更新し、当該所定額の課金処理または当該所定量のゲーム内価値を消費することに基づいてユーザに付与される量の特定のアイテムを消費して、第１のパラメータを、第１の量よりも小さい第３の量だけ更新してもよい。この構成によれば、ユーザにとって、所定値まで第１のパラメータを高める場合に、課金により入手したオブジェクトによって第１のパラメータを高めるのに比べて、課金により第１のパラメータを高める方が安価となる。よって、ユーザは課金処理によって第１のパラメータを高めやすい。

（項目７） （項目１）から（項目６）までのいずれか１項目において、ゲームプログラムは、プロセッサに、ゲームプレイに伴い、課金処理によらずゲーム内価値をユーザに関連付けてメモリに記憶させるステップをさらに実行させ、前述の更新させるステップにおいて、課金処理によりユーザに付与されるゲーム内価値を所定量消費することにより、第１のパラメータを第４の量だけ更新し、課金処理によらずユーザに付与されるゲーム内価値を当該所定量消費することにより、第１のパラメータを、第４の量とは異なる第５の量だけ更新してもよい。この構成によれば、ユーザは、ゲームプレイに伴って入手したゲーム内価値を第１のパラメータの更新（増加）に使用することが可能となる。また、ユーザが入手したゲーム内価値の由来を合わせて第１のパラメータの更新量を適宜に設定することが可能となる。したがって、課金によるゲーム内価値の使用をより有利にすればユーザの課金を行なうことに対する満足度を高めることが可能となる。また、課金を伴わないゲーム内価値の使用をより有利にすれば、課金による安易な第１のパラメータの増加を抑制することが可能となる。このように、ユーザの課金による有利な効果と、ゲームの興趣性との関係の適正化を図ることが可能となる。

（項目８） （項目１）から（項目７）までのいずれか１項目において、ゲームプログラムは、プロセッサに、ユーザが保有するオブジェクトの、第１のパラメータを含むステータスとともに、課金処理により、または、課金処理に基づいてユーザに付与されたゲーム内価値の消費によって第１のパラメータを更新させることを指示するためのユーザーインターフェースを表示するステップをさらに実行させてもよい。この構成によれば、ユーザは、自身が保有するオブジェクトの第１のパラメータを確認した際に、第１のパラメータに不足を感じた場合に直ちに、課金によって容易に第１のパラメータを高めることが可能となる。よって、課金によって第１のパラメータを高めることの利便性をより一層向上させることができる。

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

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

１ ゲームシステム、２ ネットワーク、１０，２０ プロセッサ、１１，２１ メモリ、１２，２２ ストレージ、１３，２３ 通信ＩＦ（操作部）、１４，２４ 入出力ＩＦ（操作部）、１５ タッチスクリーン（表示部、操作部）、１７ カメラ（操作部）、１８ 測距センサ（操作部）、１００ ユーザ端末（情報処理装置）、１１０，２１０ 制御部、１１１ 第１プレイパート進行部、１１２ 第２プレイパート進行部、１１３ 第３プレイパート進行部、１１４ 第４プレイパート進行部、１１５ 第５プレイパート進行部、１２０，２２０ 記憶部、１３１ ゲームプログラム、１３２ ゲーム情報、１３３ ユーザ情報、１５１ 入力部（操作部）、１５２ 表示部、２００ サーバ、２１１ 進行支援部、２１２ 同期制御部、２１３ パラメータ算出部、３０１ パズル要素、３０２ 射出台、３０３ キャラクタ要素、３０４ 一覧、３０５ パラメータ表示、３０６ ボタン、３０７ ゲージ、９００，１０００，１１００，１１１０，１２００，１２１０ 画面、９０１ 画像、９０２，１２０１ ステータス表示、９０３，９０５，９１２，９１３，１１０２，１１０３ ＵＩ、１０１０ 物体、９１１，１１０１ ウインドウ、１０２０ コントローラ（操作部）、１０３０ 記憶媒体、１００２，１００３，１１１１，１１１２，１２０２，１２１１ 表示

Claims (10)

1. ゲームプログラムであって、
   前記ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行され、
   前記ゲームプログラムは、前記プロセッサに、
   ゲームプレイにおいてユーザが利用可能なオブジェクトを前記ユーザに付与されるものとして前記メモリに記憶させるステップと、
   前記ユーザに保有されるオブジェクトに対応付けられている第１のパラメータを、当該オブジェクトの重複保有をさせないこと、または当該オブジェクトの重複保有を解消することにより前記ゲームプレイが有利に進められるように更新し、更新後の前記第１のパラメータを前記メモリに記憶させるステップと、
   前記重複保有をさせないことまたは前記重複保有を解消することによらず、課金処理によりまたは課金処理により前記ユーザに付与されるゲーム内価値を消費することにより、前記第１のパラメータを更新させるステップと、
   を実行させるゲームプログラム。
2. 前記ゲームプログラムは、前記プロセッサに、
   前記ユーザが保有する前記オブジェクトのうち、前記ゲームプレイに使用するオブジェクトを指定するための前記ユーザの第１の入力操作を受け付けるステップと、
   前記ユーザの前記第１の入力操作により指定されたオブジェクトおよび当該オブジェクトに対応付けられている前記第１のパラメータに基づきゲームを進行させるステップと、をさらに実行させ、
   前記進行させるステップは、
   前記ゲームプレイにおいて前記指定された前記オブジェクトを操作するための前記ユーザの第２の入力操作に応答して、または、前記第２の入力操作によらず自動的に前記オブジェクトを動作させるステップと、
   第１の条件が満たされることにより、前記ゲームプレイで使用される第２のパラメータを、前記第１のパラメータに基づき更新するステップと、
   前記第２のパラメータが第２の条件を満たすことにより、前記ゲームプレイをクリアしたか否かを判定するステップとを含む、請求項１に記載のゲームプログラム。
3. 前記更新させるステップにおいて、前記第１のパラメータが第１の値以下の場合に、前記ゲーム内価値の消費に基づく前記更新を可能とし、前記第１のパラメータが前記第１の値を超えている場合に、前記ゲーム内価値の消費に基づく前記更新を実行しない、請求項１または２に記載のゲームプログラム。
4. 前記更新させるステップにおいて、
   前記第１のパラメータの値が所定値以下の場合に、所定額の課金処理により、または所定量の前記ゲーム内価値を消費することにより、前記第１のパラメータを第１の量だけ更新し、
   前記第１のパラメータの値が前記所定値を超えている場合に、前記所定額の課金処理により、または前記所定量の前記ゲーム内価値を消費することにより、前記第１のパラメータを前記第１の量よりも小さい第２の量だけ更新する、請求項１または２に記載のゲームプログラム。
5. 前記ゲームプログラムは、前記プロセッサに、さらに、
   前記第１のパラメータの更新に利用することが可能な特定のアイテムを、課金処理により、または前記ゲーム内価値を消費することによって前記ユーザに付与するステップを実行させ、
   前記更新させるステップにおいて、前記特定のアイテムを消費するための前記ユーザの入力操作に応答して、前記第１のパラメータを更新させる、請求項１〜４のいずれか一項に記載のゲームプログラム。
6. 前記更新させるステップにおいて、所定額の課金処理により、または所定量の前記ゲーム内価値を消費することにより、前記第１のパラメータを第１の量だけ更新し、
   前記所定額の課金処理または前記所定量のゲーム内価値を消費することに基づいて前記ユーザに付与される量の前記特定のアイテムを消費して、前記第１のパラメータを、前記第１の量よりも小さい第３の量だけ更新する、請求項５に記載のゲームプログラム。
7. 前記ゲームプログラムは、前記プロセッサに、
   前記ゲームプレイに伴い、課金処理によらず前記ゲーム内価値を前記ユーザに関連付けて前記メモリに記憶させるステップ、をさらに実行させ、
   前記更新させるステップにおいて、前記課金処理により前記ユーザに付与される前記ゲーム内価値を所定量消費することにより、前記第１のパラメータを第４の量だけ更新し、
   前記課金処理によらず前記ユーザに付与される前記ゲーム内価値を前記所定量消費することにより、前記第１のパラメータを、前記第４の量とは異なる第５の量だけ更新する、請求項１〜６のいずれか一項に記載のゲームプログラム。
8. 前記ゲームプログラムは、前記プロセッサに、
   前記ユーザが保有する前記オブジェクトの、前記第１のパラメータを含むステータスとともに、前記課金処理により、または、前記課金処理に基づいて前記ユーザに付与された前記ゲーム内価値の消費によって前記第１のパラメータを更新させることを指示するためのユーザーインターフェースを表示するステップをさらに実行させる、請求項１〜７のいずれか一項に記載のゲームプログラム。
9. コンピュータがゲームプログラムを実行する方法であって、
   前記コンピュータは、プロセッサおよびメモリを備え、
   前記プロセッサが請求項１に記載の各ステップを実行する方法。
10. 情報処理装置であって、
    前記情報処理装置は、
    請求項１に記載のゲームプログラムを記憶するメモリと、
    該ゲームプログラムを実行することにより、情報処理装置の動作を制御するプロセッサとを備えている、情報処理装置。

Images