JP7413479B2 - プログラム - Google Patents

Description

本発明は、プログラムに関する。

ロールプレイングゲーム、アクションロールプレイングゲームなど、ゲームキャラクタを操作してゲームを進行させるものがある。これらゲームでは、例えば、ユーザの入力操作に応じてゲームキャラクタに行動させ、敵キャラクタと戦闘をさせること等により経験値をゲームキャラクタに付与する。ゲームキャラクタが成長すると、より強力な敵キャラクタと戦闘をして勝利をし、ゲームを進行させられるようになる。

キャラクタを操作するための技術として、例えば、特開２０１６－０５１２６６号公報（特許文献１）がある。特許文献１には、スマートフォンによって実行されるビデオゲームにおいて、スマートフォンのタッチパネルに表示されるキャラクタオブジェクトをユーザがタッチ操作することで、タッチパネルに対するスライド操作方向とキャラクタオブジェクトの移動やジャンプなどの各アクションとを対応付けてキャラクタオブジェクトを制御するゲーム操作方法が開示されている。

特開２０１６－０５１２６６号公報

ゲームキャラクタが成長すると、より多様な行動ができるようになり、その結果、ユーザはますますプレイを楽しむことができる。

例えば、ゲームキャラクタが成長することにより、回復呪文を覚えたり特殊な攻撃を覚えたりといったスキルを獲得することがある。典型的には、ゲームキャラクタが経験値を獲得すると、ゲームキャラクタのレベルが上がり、一定レベルに達する都度、攻撃呪文などのスキルを獲得するといったことが行われている。しかし、ゲームキャラクタの成長方法が単調であると、プレイの展開の幅が狭まることとなり、ゲームの興趣性をよりいっそう向上させることが必要となる。

ゲームによっては、ゲーム中においてキャラクタの成長のさせ方に多様な選択肢を用意しつつ、ユーザがキャラクタの成長のさせ方に自発的に介入させることで、多様なゲーム展開を実現しているものもある。例えば、ロールプレイングゲームにおいて、プレイヤーキャラクタが予め戦士、魔法使い、僧侶、格闘家などの職業を付与されており、この職業を、転職という形式でゲーム中で変更可能とするものがある。例えば、職業に応じて獲得するスキルが異なるようにすることで、ユーザは、自ら考えたキャラクタの成長のさせ方に沿ってゲームを進行させることができる。

しかしながら、このような転職システムを採用したゲームは、典型的には、ユーザが自らの意思で転職先の職業を指定するものの、転職後の職業では低いレベルのキャラクタとなるものが多い。そのためユーザはキャラクタをある職業にした後に、じっくりとキャラクタを成長させることとなる。そうすると、ユーザは、そもそもどの職業に就かせるかという選択をじっくりと検討することが必要となり、キャラクタの職業を変更することに慎重となる。結果的に、多様なゲーム展開が促されないことになりかねない、という課題がある。

本開示は、キャラクタのパラメータの更新方法を多様化させることで、より展開を多様化することを支援し、これによりプレイの興趣性をいっそう向上させることが可能な技術を提供することを目的とする。

本開示に示す一実施形態によれば、プログラムが提供される。プログラムは、コンピュータを、操作対象となる１以上のキャラクタについて、キャラクタに関連付けることが可能な属性を供出対象とする抽選処理を行う抽選手段と、抽選処理の結果に応じて供出された属性を示す情報を記憶させる記憶手段と、既に行われた抽選処理の結果に応じて供出されたことにより既にキャラクタに関連付けることが可能となっている属性が、新たに行われた抽選処理の結果に応じて再び供出されることにより、属性がいずれのキャラクタの属性であるかにかかわらず、共通の第１のオブジェクトをユーザに付与する付与手段と、第１のオブジェクトを消費することにより、属性に関連するパラメータを成長させるように更新するための処理を行う更新手段と、して機能させる。

本開示に示す一実施形態によれば、プロセッサと、メモリとを備える情報処理装置が提供される。前記メモリに格納されるゲームプログラムを前記プロセッサが読み込むことにより、前記プロセッサが、操作対象となる１以上のキャラクタについて、前記キャラクタに関連付けることが可能な属性を示す情報を前記メモリに記憶させる。前記プロセッサは、前記キャラクタの属性を供出対象とする抽選処理を行う。前記プロセッサは、抽選処理の結果、既に前記キャラクタに関連付けることが可能な前記属性が供出されることにより、前記属性に関連するパラメータを更新するための処理を行う。

本開示に示す一実施形態によれば、プロセッサと、メモリとを備えるコンピュータにおいて実行される方法が提供される。この方法は、前記プロセッサが、操作対象となる１以上のキャラクタについて、前記キャラクタに関連付けることが可能な属性を示す情報を前記メモリに記憶させる第１のステップと、前記キャラクタの属性を供出対象とする抽選処理を行う第２のステップと、抽選処理の結果、既に前記キャラクタに関連付けることが可能な前記属性が供出されることにより、前記属性に関連するパラメータを更新するための処理を行う第３のステップとを実行することを含む。

本開示によれば、キャラクタのパラメータの更新方法を多様化させることで、より展開を多様化することを支援し、これによりプレイの興趣性をいっそう向上させることができる。

本実施形態に係るユーザ端末を示す図である。 本実施形態に係るユーザ端末のハードウェア構成を示す図である。 本実施形態に係るユーザ端末の機能ブロック図である。 本実施形態に係るユーザ端末のタッチスクリーン上に表示されるゲームのゲーム画面の一例を示す図である。 操作検出部が、ユーザの入力操作に応じてプレイヤキャラクタを移動させる方向を検出する処理を示す図である。 プレイヤキャラクタ（ここでは、自キャラクタ）の動作テーブルを示す図である。 （Ａ）は、タッチスクリーン上に表示される操作オブジェクトの一例を示す図であり、（Ｂ）は操作オブジェクトが弾性変形した状態を示す図である。 本実施形態に係るゲームプログラムで実装される主要な機能モジュールを示す模式図である。 本実施形態において操作オブジェクト内にプレイヤキャラクタの状態に関する情報を表示させるための処理を示すフローチャートである。 （Ａ）および（Ｂ）は、図９のフローチャートにおけるゲーム画面の例を示す図である。 ユーザがプレイヤキャラクタに所定のアクションを実行させたい場合の画面例であり、（Ａ）はプレイヤキャラクタがジャンプしている状態の画面例を示す図であり、（Ｂ）は、所定のアクションの入力操作が成功した場合の画面例を示す図であり、（Ｃ）は当該アクションの入力操作が失敗した場合の画面例を示す図である。 ユーザがプレイヤキャラクタに所定のアクションを実行させたい場合の画面例であり、（Ａ）はプレイヤキャラクタがジャンプしている状態の画面例を示す図であり、（Ｂ）は、所定のアクションの入力操作が成功した場合の画面例を示す図であり、（Ｃ）は当該アクションの入力操作が失敗した場合の画面例を示す図である。 変形例に係るゲーム画面を示す図である。 別の変形例に係る操作オブジェクトを示す図である。 自キャラクタ１００などユーザが操作することが可能なゲームキャラクタのパラメータのデータ構造、および、ユーザの入力操作に応じてゲームキャラクタに各種行動を行わせた履歴とゲームキャラクタが獲得したスキルとの対応関係を含むデータ構造を示す図である。 ユーザの入力操作に応じて自キャラクタ１００が行動を行うことに起因して、自キャラクタ１００がスキルを獲得したことを通知する局面を示す。 自キャラクタ１００が獲得可能なスキルと、自キャラクタ１００が習得しているスキルとをユーザが確認することができるスキル一覧の画面例を示す。 ユーザ端末１が、自キャラクタ１００の動作内容に応じて、スキル習得のための各スキルの経験値を更新し、スキルを獲得したこと、スキルを成長させたことをユーザに通知する処理を示すフローチャートである。 ユーザ端末１が、ユーザの入力操作に応じて、自キャラクタ１００が習得しているスキル一覧の画面をタッチスクリーン２に提示する処理を示すフローチャートである。 第２の実施形態においてプレイヤキャラクタをユーザが変更するためのユーザインターフェース画像の表示処理を示すフローチャートである。 図２０に示すフローチャートにおけるゲーム画面の例を示す図である。図２２は、図２１に示すゲーム画面に連続するゲーム画面の例を示す図である。 図２１に示すゲーム画面に連続するゲーム画面の例を示す図である。 プレイヤキャラクタをユーザが変更した後でのユーザインターフェース画像の例を示す図である。 プレイヤキャラクタ変更用のユーザインターフェース画像を表示させたままスライド操作が入力された場合のゲーム画面の例を示す図である。 ゲームプログラムにおいてユーザが操作対象とし得るキャラクタと、ユーザが操作対象とすることができるキャラクタとを管理するためのキャラクタ管理情報のデータ構造を示す図である。 ユーザがキャラクタを変更する入力操作によらず、敵キャラクタとの戦闘中に自動的にキャラクタを変更する第１のモードと、第１のモードを停止させる第２のモードとを切り替えるためのユーザインターフェース画像と、オートチェンジによりキャラクタが変更されるゲーム画面とを示す図である。 オートチェンジ適用モードにおいて、パーティ編成されるキャラクタのうち、敵キャラクタと戦闘するキャラクタを特定し、特定した結果に応じてキャラクタをタッチスクリーン２に表示させる処理を示すフローチャートである。 抽選処理により供出されるゲーム媒体を示すテーブルである。 抽選処理において、ユーザの端末のディスプレイ２に表示される画面例を示す。 キャラクタのジョブに関連付けられたスキルを表示するための画面例である。 本実施形態に示すフローチャートである。

以下の説明では、ゲームキャラクタのパラメータの更新を多様化することでゲーム展開をも多様化することを支援する技術について説明する。
まず、（ア）ユーザがゲームキャラクタの入力操作を行ってゲームキャラクタを動作させることを支援するため、タッチスクリーンに所定の情報を表示する態様について説明しているが、ゲームキャラクタの動作内容を示す情報をタッチスクリーンに表示する構成に限られない。また、ユーザの入力操作を受け付ける構成として、タッチスクリーンに対する入力操作を受け付ける例を示しているが、これに限らず、ゲームコントローラ等への入力によりゲームキャラクタを動作させる場合にも、以下の実施形態に示す開示内容を適用することとしてもよい。（イ）続いて、ユーザの入力操作等に応じてキャラクタがアクションを行った結果、キャラクタの各種パラメータを強化することができるゲームプログラムについて説明する。（ウ）これら構成において、さらに、各キャラクタが、ジョブ（職業）という属性と関連付けられる態様について説明する。本実施形態では、各キャラクタの属性が、抽選処理によってユーザに付与される。さらに、キャラクタのジョブを変更した場合に、キャラクタの体力、スキルポイントなどのパラメータはジョブの変更前から引き継ぎつつ、ジョブの変更後は、そのジョブならではの装備アイテムが装備できたり、そのジョブならではのスキルを発動できたりするようになる。ゲームプログラムは、ジョブならではのスキルなど、ジョブと関連付けられたパラメータについては、以下のようにして更新する。例えば、ゲームプログラムは、既にユーザに供出済みのジョブが、抽選により再び供出される場合に、ジョブに関連するパラメータを成長させるための素材アイテムをユーザに付与する、または、再びジョブが供出されたことをもってジョブに関連するパラメータを成長させる。
本開示では、上記（ウ）の構成により、ユーザがキャラクタのジョブを変更することを促しつつ、ジョブ自体に関連するキャラクタのパラメータについては、抽選処理の結果に応じて成長させられる構成としている。これにより、ユーザに対し、次々と新たなジョブを抽選により獲得するように促すことで、さらにゲーム展開の多様化を支援することができる。このように、ゲームプログラムは、キャラクタの性能を表す第１のパラメータについては、ユーザの入力操作に応じてキャラクタに攻撃、回避、ジャンプなどの動作を行わせることで成長させる。ゲームプログラムは、キャラクタの属性であるキャラクタのジョブを、抽選によりユーザに付与する。ゲームプログラムは、キャラクタのジョブに応じた第２のパラメータ（ジョブに特有のスキルなど）を、第１のパラメータの成長方法とは異なる方法で更新する。具体的には、ゲームプログラムは、キャラクタのジョブを付与するための抽選処理を行ったとき、既にユーザが獲得しているジョブを、抽選により供出すると決定した場合（すなわち、ジョブが重複した場合）、ジョブに関連する第２のパラメータを更新するためのアイテムをユーザに付与するか、ジョブに関連する第２のパラメータを更新する。
従来、キャラクタごとに転職を更新することができるものにおいて、転職のたびにパラメータが初期化されるものがある（例えば、レベル１に戻るもの）。また、従来、ユーザの任意の職業の選択によりキャラクタを転職させるものがある。この従来例と比べると、本開示に示すゲームプログラムは、抽選処理によりキャラクタのジョブをユーザに付与するものであるため、ユーザがどの職業を選択するかを迷うことがない。また、本開示に示すゲームプログラムは、基本的なパラメータの成長に加え、ジョブによるキャラクタの成長を楽しむことができる。さらに、ジョブを獲得するための抽選処理によりジョブが重複することでジョブを成長させることができるため、次々と抽選によりジョブを獲得しようとユーザに促すことができる。これにより、キャラクタの成長方法を多様化しつつ、多様化させるようなゲームプレイをユーザに促すことができ、ゲームの興趣性をいっそう向上させることができる。

まず、ゲームキャラクタを動作させるための入力操作に応じて、ゲームキャラクタが行っている動作の内容をタッチスクリーンに表示する構成について概要を説明すると、以下の通りである。

（１）本開示の一実施形態に係るゲーム方法は、ユーザの入力操作に従って、タッチスクリーンに表示されるキャラクタオブジェクトを制御するゲーム方法であって、
当該ゲーム方法は、
（ａ）前記入力操作の開始点から前記入力操作の終了点に向けて、前記タッチスクリーン上に操作オブジェクトを表示させるステップと、
（ｂ）前記入力操作に基づいて、前記キャラクタオブジェクトに所定の動作を実行させるステップと、
（ｃ）前記ステップ（ｂ）における前記キャラクタオブジェクトの状態を検出するステップと、
（ｄ）検出された前記キャラクタオブジェクトの前記状態に関連付けられた所定の情報を、前記操作オブジェクトに付随して前記タッチスクリーン上に表示させるステップと、
を含む。

上記方法によれば、入力操作に対するフィードバックをユーザへ直感的に与えることができる。

（２） 前記操作オブジェクトは、前記開始点と前記終了点との間に表示されるオブジェクトであり、
前記ステップ（ａ）において、前記操作オブジェクトは、前記基準点側の部分および前記終了点側の部分のいずれか一方が、他方の部分よりも大きい拡大部となるように表示され、
前記ステップ（ｄ）において、前記所定の情報は、前記拡大部の内側に表示されても良い。

上記方法によれば、タッチスクリーン上のデッドスペースである操作オブジェクトの拡径部に状態表示情報を表示させることで、スマートフォンのような狭い画面を有効利用することができる。

（３）前記ステップ（ｄ）において、前記開始点と前記終了点との位置関係に関わらず、前記タッチスクリーン上における前記所定の情報の表示角度は固定されていても良い。

上記方法によれば、操作オブジェクト内に表示された情報の視認性を確保することができる。

（４）前記ステップ（ｂ）において、第一の入力操作を行うことで前記キャラクタオブジェクトを第一の状態とし、前記第一の状態において第二の入力操作を行うことで前記所定の動作が実行されても良い。

（５）前記ステップ（ｂ）において、第一の入力操作を行うことで前記キャラクタオブジェクトを第一の状態とした後に第二の状態とし、前記第一の状態または前記第二の状態において第二の入力操作を行うことで前記所定の動作が実行されても良い。

これらの方法によれば、複数の入力操作が必要な動作（アクション）についても、当該入力操作の成否をユーザに対して分かりやすくフィードバックすることができる。

（６）本開示の一実施形態に係るプログラムは、上記（１）から（５）のいずれかに記載のゲーム方法をコンピュータに実行させるためのプログラムである。

この構成によれば、入力操作に対するフィードバックをユーザへ直感的に与えることが可能なプログラムを提供することができる。

［本開示が示す第１の実施形態の詳細］
以下、本開示が示す実施形態について図面を参照しながら説明する。なお、本実施形態の説明において既に説明された部材と同一の参照番号を有する部材については、説明の便宜上、その説明は繰り返さない。

本開示の実施の形態によるゲームプログラムは、図１に示されるように、タッチスクリーン２を備えたユーザ端末１において実行されるものである。ユーザ端末１は、ゲームプログラムを実行することにより、ゲームプログラムに応じたゲームをプレイする環境をユーザに対して提供する。ユーザ端末１は、例えば、アプリ等を配信するプラットフォームを介してゲームプログラムをインストールする。ユーザ端末１は、ユーザ端末１にインストールされたゲームプログラム、または、予めプリインストールされているゲームプログラムを実行することで、ユーザによるゲームのプレイを可能とする。ユーザは、タッチスクリーン２を介してゲーム内のプレイヤキャラクタ（キャラクタオブジェクトの一例）を操作することができる。ユーザ端末１は、例えば、スマートフォン、ＰＤＡ（Personal Digital Assistant）、タブレット型コンピュータ等の携帯可能な端末であってもよいし、パーソナルコンピュータ、ビデオゲーム機器等であってもよい。

なお、ユーザ端末１はネットワークを介してゲーム・サーバと通信を行ってもよい。この場合は、以下の実施形態におけるユーザ端末１に関する様々な機能の全部または一部はゲーム・サーバが担い、例えば、ゲーム・サーバで生成されるゲーム画像をブラウザ等のアプリケーションによりユーザ端末１で表示できるように構成してもよい。さらに、ゲーム・サーバを介して、別のユーザ端末と通信可能な構成とすることもできる。

図２に示されるように、ユーザ端末１は、ハードウェア構成として、互いにバス接続されたＣＰＵ（Central Processing Unit）３、主記憶４、補助記憶５、送受信部６、表示部７および入力部８を備えている。このうち主記憶４は例えばＤＲＡＭ（Dynamic Random Access Memory）などで構成されており、補助記憶５は例えばＨＤＤ（Hard Disk Drive）などで構成されている。補助記憶５には、本実施の形態によるゲームプログラムが格納されている。ゲームプログラムは、主記憶４上に展開されＣＰＵ３によって実行される。なお、主記憶４上には、ＣＰＵ３がゲームプログラムに従って動作している間に生成したデータやＣＰＵ３によって利用されるデータも一時的に格納される。送受信部６はＣＰＵ３の制御によりユーザ端末１とネットワークとの接続を確立する。入力部８は、タッチスクリーン２である表示部７に対するユーザの操作を検知して、ユーザ端末１に対して何らかの操作があったことを検知する。

図３は、本実施形態に係るユーザ端末１の機能ブロック図の一例を示す。
本実施の形態における表示部７および入力部８は上述したタッチスクリーン２に相当する。タッチスクリーン２は、図３に示されるように、入力部８に相当するタッチセンシング部１０と、表示部７に相当するディスプレイ２０とを有している。タッチスクリーン２は、ユーザのタッチ操作（タッチスクリーン２における物理的接触操作等）を受け付ける。具体的には、タッチセンシング部１０はユーザによるタッチ操作に応じた操作信号を制御部３０へ出力する。タッチ操作は、ユーザの指によりなされてもよいし、スタイラス等でもよい。ディスプレイ２０は、制御部３０から出力される表示信号に基づいてユーザ操作に対応する画像を表示する。ディスプレイ２０は、例えばＬＣＤ（Liquid Crystal Display）、有機ＥＬ（electroluminescence）その他の表示装置によって実現される。

制御部３０は、タッチセンシング部１０が受け付けたユーザからの指示に基づいてゲームプログラムを実行し、ゲーム世界においてプレイヤとして機能するプレイヤキャラクタの動作を制御しつつ、ゲームを進行させる。制御部３０は、ゲームプログラムを実行することにより、入力操作受付部３２と、キャラクタ操作検出部３４と、オブジェクト制御部３６と、表示制御部３８と、の各機能を発揮する。

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

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

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

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

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

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

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

キャラクタ操作検出部３４は、タッチスクリーン２に対するユーザの入力操作に基づいて、ゲームに登場するプレイヤキャラクタ（以下、「自キャラクタ」と称することもある）に所定の動作を実行させる入力操作の操作内容を検出する。キャラクタ操作検出部３４は、ユーザの入力操作に基づいて、例えば、プレイヤキャラクタを移動させる方向を検出する。すなわち、キャラクタ操作検出部３４は、ユーザがプレイヤキャラクタの移動方向を指定する入力操作を受け付ける。

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

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

表示制御部３８は、キャラクタ操作検出部３４およびオブジェクト制御部３６での制御に応じて、ディスプレイ２０の表示内容を決定し、決定した表示内容に従った画像、テキスト等の各種の情報をディスプレイ２０に出力する。例えば、表示制御部３８は、プレイヤキャラクタをディスプレイ２０の一定領域に表示させた状態で、入力操作受付部３２によって受け付けた入力操作に応じて操作オブジェクト４０を表示させつつプレイヤキャラクタに所定の動作（例えば、移動やジャンプ動作）を行わせる画面表示を行う。

図４は、本実施形態に係るユーザ端末１のタッチスクリーン２に表示されるゲーム画面の一例を示す。図４の画面例は、ユーザが操作する自キャラクタ１００（キャラクタオブジェクト、プレイヤキャラクタの一例）に、所定の動作を行わせるための入力操作を受け付ける画面である。制御部３０は、タッチスクリーン２に、ユーザが操作するプレイヤキャラクタである自キャラクタ１００と、対戦相手（敵）となるキャラクタである相手キャラクタ２００とを表示させて、ユーザに対し、自キャラクタ１００に所定の動作を行わせるための入力操作を受け付ける。自キャラクタ１００および相手キャラクタ２００は、ユーザ端末１を縦型となるように置いたときに、その上下方向においてタッチスクリーン２の中央付近（例えば、タッチスクリーン２をその上下方向に三分割したときの中央の領域内）に、例えば、左右方向において進行方向に視野がやや広くなるように表示される。タッチスクリーン２の下方には、例えば地面の断面（図４のドット模様の部分）が表示されている。タッチスクリーン２の下半部、すなわち地面の断面が表示された部分は、後述の操作オブジェクト４０を操作するためのスペースとして利用可能である。ユーザは、タッチスクリーン２の任意位置への操作によって、自キャラクタ１００を操作することができる。ユーザが、例えば、ディスプレイ２０の左右方向に沿った方向（図４の矢印Ａの方向）のドラッグ操作を入力した場合、制御部３０は、そのドラッグ操作を受け付けて、自キャラクタ１００をドラッグ操作の方向に対応する方向（例えば、矢印Ｂの方向）に移動させるよう制御する。

なお、タッチスクリーン２の左右方向の端部には、各種のユーザインターフェース画像（ＵＩ画像）３００が表示される。ＵＩ画像３００には、例えば、マップを表示するためのＵＩ画像３００Ａやスキル（ゲーム内で自キャラクタ１００により行われる攻撃アクションの一つ）を発動させるためのＵＩ画像３００Ｂが含まれる。

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

図５の状態（Ａ）は、タッチスクリーン２からユーザの指が離れた状態から、ユーザが指をタッチスクリーン２に接近させた状態を示す。入力操作受付部３２は、ユーザの指がタッチスクリーン２に接近したことを検出し、検出した座標を初期タッチ位置としてメモリ（例えば、主記憶４または補助記憶５）に保持する。

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

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

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

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

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

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

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

２．自キャラクタの動作例
図６に、自キャラクタ１００の動作テーブル６０（アクション例）を示す。動作テーブル６０は、例えば、制御部３０（表示制御部３８）に記憶されている。図６に示すように、動作テーブル６０には、ユーザの入力操作と、入力操作時の自キャラクタ１００の状態とに基づいて自キャラクタ１００に実行させる所定のアクションが設定されている。動作テーブル６０に例示された例１～８について、以下に詳述する。

例１：ユーザがタップ操作した場合には、自キャラクタ１００がどのような状態であっても（すなわち、地面に着地していても着地していなくても）、制御部３０は、自キャラクタ１００に攻撃動作（例えば、持っている剣を振る）を実行させる。
例２：ユーザが横スライド操作（ここで、タッチスクリーン２の左右方向（水平方向）に沿った向きを０度とし、水平方向よりも上側を正とし、下側を負とした場合に、例えば、－４５度から＋３０度の範囲内のドラッグ操作を、横スライド操作と称する。）を行い、かつ、自キャラクタ１００が地面に着地している場合には、制御部３０は、自キャラクタ１００をドラッグ操作の方向に移動させる。なお、ドラッグ操作の開始点と終了点の距離（スライド量）が所定の閾値以下の場合は、自キャラクタ１００を歩かせるようにし、スライド量が所定の閾値よりも大きい場合には、自キャラクタ１００を走らせるようにしてもよい。
例３：ユーザが上スライド操作（例えば、＋６０度から＋１２０度の範囲内のドラッグ操作を、上スライド操作と称する。）を行い、かつ、自キャラクタ１００が地面に着地している場合には、制御部３０は、自キャラクタ１００にジャンプ動作を実行させる。
例４：ユーザが例３と同様の上スライド操作を行い、かつ、自キャラクタ１００が地面に着地していない場合には、制御部３０は、自キャラクタ１００が地面に着地した後にジャンプ動作を実行させる。すなわち、この場合は、自キャラクタ１００のジャンプ動作が繰り返される。
例５：ユーザが下スライド操作（例えば、－４５度から－１３５度の範囲内のドラッグ操作を、下スライド操作と称する。）を行い、かつ、自キャラクタ１００が地面に着地している場合には、制御部３０は、自キャラクタ１００をしゃがみ込ませる。
例６：ユーザが例５と同様の下スライド操作を行い、かつ、自キャラクタ１００が地面に着地していない場合には、制御部３０は、自キャラクタ１００に下方攻撃動作（いわゆる、兜割り）を実行させる。
例７：ユーザが斜め上スライド操作（例えば、＋３０度から＋６０度の範囲内のドラッグ操作を、斜め上スライド操作と称する。）を行い、かつ、自キャラクタ１００が地面に着地している場合には、制御部３０は、自キャラクタ１００を斜めにジャンプさせ、着地後に地面上を移動させる。
例８：ユーザが例７と同様の斜め上スライド操作を行い、かつ、自キャラクタ１００が壁などの障害物に接している場合には、制御部３０は、自キャラクタ１００に壁を蹴って上方へジャンプする動作（いわゆる、三角飛び）を実行させる。

制御部３０は、例えば、ユーザの上スライド操作（第一の入力操作の一例）を受け付けると、動作テーブル６０を参照して自キャラクタ１００をジャンプさせた状態（第一の状態の一例）とし、ジャンプさせた状態においてユーザの下スライド操作（第二の入力操作の一例）を受け付けると、動作テーブル６０を参照して自キャラクタ１００に兜割りを実行させる。また、斜めスライド操作を受け付けた場合には、制御部３０は、斜め上スライド操作に基づいて動作テーブル６０を参照して自キャラクタ１００をジャンプ状態（第一の状態）とした後に地面上を移動させる状態（第二の状態の一例）とする。そして、制御部３０は、自キャラクタ１００をジャンプさせた状態または地面を移動させた状態において所定の入力操作（例えば、下スライド動作）を受け付けると、動作テーブル６０を参照して自キャラクタ１００に所定の動作（ジャンプ状態の場合には兜割り、移動状態の場合にはしゃがみ込み）を実行させる。

３．操作オブジェクトの基本構成
本実施形態に係る操作オブジェクト４０（図４参照）は、ユーザのタッチスクリーン２に対する接近操作が検知されるとタッチスクリーン２に表示される。操作オブジェクト４０は、ユーザが自キャラクタ１００を移動させる方向を示す弾性状のオブジェクトである。操作オブジェクト４０は、図７の（Ａ）に示すように、指接触時の初期形状として、タッチスクリーン２に接触した位置（例えば、図５の初期タッチ位置座標５１Ａ）である接触開始点に関連付けられた基準位置の周囲に、円形状の基部４２を有するように形成される。なお、基準位置は、最初に指がタッチスクリーン２に触れた座標でなくても良く、例えば、最初に指が触れたフレームの数フレーム後のフレームにおいて指が触れていた座標であっても良い。ユーザがタッチスクリーン２上で接触開始点から接触終了点（ここで、接触終了点とは、ユーザの指などがタッチスクリーン２に接触した状態での最終地点を意味する）までドラッグ操作を行うと、図７の（Ｂ）に示すように操作オブジェクト４０は、ユーザの指に引っ張られるような弾性変形を伴う。このとき、操作オブジェクト４０は、ドラッグ操作の接触開始点に対応して表示される基部（拡大部）４２に加えて、ドラッグ操作の接触終了点（注：指はタッチスクリーン２に接触したままの状態である。）付近に位置する先端部４４と、基部４２と先端部４４との間を接続する接続部４６とを含むように構成される。このように操作オブジェクト４０は、接触開始点から接触終了点に向けて入力されたドラッグ操作の方向に弾性的に延ばされるように形成される。また、ユーザが接触終了点を接触状態に維持しつつタッチスクリーン２上において更に指などを移動させた場合、先端部４４もそれに追従して更に移動し操作オブジェクト４０の延びる向きも変化する。ユーザによるドラッグ操作が終了した際に（すなわち、タッチスクリーン２上において接触終了点からユーザの指が離れた際に）、弾性変形した操作オブジェクト４０が、その復元力に従って、接触開始点に向けて段階的に萎縮して、図７の（Ａ）に示した初期形状に復元するように表示され、一定時間経過後に非表示となる。なお、図７の（Ａ）では、接触開始点を中心に円形状の基部４２を形成しているが、必ずしもこれに限定されない。例えば、基部４２を接触開始点から一定距離だけ上部または下部にずらして形成しても良い。すなわち、操作オブジェクト４０の基部４２は、接触開始点に関連付けられた所定の位置（基準位置）に対応して表示されていても良い。また、接触開始点に形成した操作オブジェクト４０（基部４２）をドラッグ操作に応じて変形させずに、接触開始点から接触終了点に向けて、操作オブジェクトの一部を構成する別のオブジェクトを表示させるようにしても良い。

４．主要な機能モジュールの説明
図８～図１０を参照して、本実施形態に係るゲームプログラムで実装される主要な機能モジュールとその動作処理について説明する。当該機能モジュールを通じて、操作信号としての入力を処理して、表示信号としての出力を生成することになる。
図８に示す操作オブジェクト制御プログラムモジュール（操作オブジェクト制御ＰＭ）８０は、タッチスクリーン２（タッチセンシング部１０）を通じたユーザの入力操作に基づいて操作オブジェクト４０を制御するためのモジュールである。キャラクタ制御プログラムモジュール（キャラクタ制御ＰＭ）９０は、タッチスクリーン２を通じたユーザの入力操作に応じて仮想空間内の自キャラクタ１００の動作を制御して自キャラクタ１００を操作するためのモジュールである。操作オブジェクト制御プログラムモジュール８０は、入力操作受付プログラムモジュール（入力操作受付ＰＭ）８２と、操作オブジェクト描画プログラムモジュール（操作オブジェクト描画ＰＭ）８４とを含む。入力操作受付ＰＭ８２は、図３に示す入力操作受付部３２としての機能を有し、操作オブジェクト描画ＰＭ８４は、オブジェクト制御部３６および表示制御部３８としての機能を有する。キャラクタ制御ＰＭ９０は、キャラクタ操作検出部３４としての機能を有する。

タッチスクリーン２上でユーザの指などによる入力操作（例えば、接近操作）が実行されると、入力操作受付ＰＭ８２は、入力操作を受け付け、受け付けた入力操作に関する情報（入力操作情報）をキャッシュメモリ（例えば、図５のバッファメモリ５３）に格納する（図９のステップＳ１）。次に、キャラクタ制御ＰＭ９０は、入力操作受付ＰＭ８２から入力操作情報を取得する（ステップＳ２）。そして、キャラクタ制御ＰＭ９０は、ゲーム内状況に基づいて、例えば、自キャラクタ１００の状態（地面に着地しているか否か、壁などの障害物に接しているか否か、など）に関する情報を取得する（ステップＳ３）。なお、ここでの「自キャラクタ１００の状態」とは、キャラクタの動作に関連する状態（例えば、着地状態か否か）を示し、キャラクタのステータスの異常状態（例えば、毒や石化）などは含まない。

次いで、キャラクタ制御ＰＭ９０は、ステップＳ２で取得した入力操作情報とステップＳ３で取得した自キャラクタ１００の状態に関する情報（以下、キャラクタ状態情報と称する）に基づいて、図６の動作テーブル６０を参照して自キャラクタ１００を制御する（ステップＳ４）。例えば、ユーザが横スライド操作を行い、かつ、自キャラクタ１００が地面に着地している場合には、キャラクタ制御ＰＭ９０は、横スライド操作情報、および自キャラクタ１００が地面に着地状態であるという情報を取得し、これらの情報から動作テーブル６０の例２に基づいて、図１０の（Ａ）に示すように自キャラクタ１００をドラッグ操作の方向（矢印Ｃの方向）に移動させる。なお、キャラクタ制御ＰＭ９０は、自キャラクタ１００の制御結果に基づいて、相手キャラクタ２００を制御することもできる。例えば、キャラクタ制御ＰＭ９０は、自キャラクタ１００が相手キャラクタ２００を攻撃した場合、その攻撃を受けたことを表すアクションを相手キャラクタ２００に行わせることができる。

次に、操作オブジェクト制御ＰＭ８０内の操作オブジェクト描画ＰＭ８４は、入力操作受付ＰＭ８２から入力操作情報を取得するとともに、キャラクタ制御ＰＭ９０からキャラクタ状態情報を取得する（ステップＳ５）。そして、操作オブジェクト描画ＰＭ８４は、ステップＳ５で取得した入力操作情報およびキャラクタ状態情報に基づいて、操作オブジェクト４０を描画し、タッチスクリーン２に表示する（ステップＳ６）。例えば、図６の例２のように横スライド操作が行われた場合には、操作オブジェクト描画ＰＭ８４は、入力操作受付ＰＭ８２から横スライド操作情報を取得し、図１０の（Ａ）に示すように、初期タッチ位置座標（接触開始点）から現在のタッチ位置座標（接触終了点）に向けて、すなわち矢印Ｃ´方向に操作オブジェクト４０を引き延ばすように表示する。それと同時に、操作オブジェクト描画ＰＭ８４は、キャラクタ制御ＰＭ９０から取得したキャラクタ状態情報に基づいて、図１０の（Ａ）に示すように、操作オブジェクト４０の基部４２の内側に自キャラクタ１００の状態に対応した情報（例えば、文字情報）を表示する。例えば、自キャラクタ１００が地面に着地した状態でユーザが矢印Ｃの方向に横スライド操作を実行した場合には、操作オブジェクト４０の基部４２内には「Ｒｕｎ」と表示される（図１０の（Ａ）参照）。なお、横スライド操作のスライド量が所定値以下の場合は、基部４２内に「Ｒｕｎ」の代わりに「Ｗａｌｋ」と表示しても良い。また、自キャラクタ１００が地面に着地した状態でユーザが上スライド操作あるいは斜め上スライド操作を実行した場合には、図１０の（Ｂ）に示すように、自キャラクタ１００がドラッグ操作の方向である矢印Ｄ方向に応じてジャンプするとともに、操作オブジェクト４０が矢印Ｄ´方向に引き伸ばされ、操作オブジェクト４０の基部４２内に「Ｊｕｍｐ」と表示される。ステップＳ６の処理が完了すると、ステップＳ１へ戻り、処理を繰り返す。

タッチスクリーン２上において、基部４２内に表示される文字情報（「Ｒｕｎ」や「Ｊｕｍｐ」）の表示角度は固定されていることが好ましい。すなわち、図１０の（Ａ），（Ｂ）に示すように、操作オブジェクト４０の基部４２に対する先端部４４の角度に関わらず、文字情報が横書きである場合には、文字情報は表示部の下辺と略平行となる向きで表示される。例えば、接触開始点から下向き側にドラッグ操作が入力された場合や、接触開始点を中心にして接触終了点が回転するような入力操作が入力された場合にも、タッチスクリーン２上における文字情報の表示角度はユーザが見易い向きで表示されるため、良好な視認性を確保することができる。

図１１は、ユーザが自キャラクタ１００に兜割りのアクションを実行させようとする場合のゲーム画面例であり、（Ａ）は自キャラクタ１００がジャンプしている状態の画面例を示し、（Ｂ）は、兜割りの入力操作が成功した場合の画面例を示し、（Ｃ）は兜割りの入力操作が失敗した場合の画面例を示している。
兜割り（下方攻撃）は、図６の動作テーブル６０の例５に示すように、自キャラクタ１００が地面に着地していない状態（図１１の（Ａ）に示す状態）において下スライド操作がなされた時に実行可能となる。すなわち、制御部３０は、ユーザの上スライド操作あるいは斜め上スライド操作に基づいて自キャラクタ１００を地面に着地していないジャンプ状態とし、このジャンプ状態においてユーザの下スライド操作の入力を受け付けた場合に、自キャラクタ１００に兜割りを実行させる。

兜割りの入力操作が成功した場合、すなわちジャンプ状態において下スライド操作が入力された場合には、図１１の（Ｂ）に示すように、制御部３０は、自キャラクタ１００に兜割りを実行させるとともに、操作オブジェクト４０の基部４２内に兜割りに関する情報（例えば、「Ａｔｔａｃｋ」）を表示する。一方、兜割りの入力操作が失敗した場合、例えばドラッグ操作の下方向への角度が足りなかった場合には、図１１の（Ｃ）に示すように、制御部３０は、自キャラクタ１００に兜割りを実行させず、また、操作オブジェクト４０の基部４２内にはその時点での自キャラクタ１００の状態に関する情報（例えば、「Ｊｕｍｐ」）を表示する。この場合、ユーザは、表示「Ｊｕｍｐ」を見ることで、ドラッグ操作の下方向への角度が足りなかったことを容易に認識することができる。このように、基部４２内に文字情報を表示することで、兜割りのような複数の入力操作が必要な動作についても当該入力操作の成否をユーザに対して分かりやすくフィードバックすることができる。

図１２は、図１１と同様に、ユーザが自キャラクタ１００に兜割りのアクションを実行させようとする場合のゲーム画面例であり、（Ａ）は自キャラクタ１００がジャンプしている状態の画面例を示し、（Ｂ）は、兜割りの入力操作が成功した場合の画面例を示し、（Ｃ）は兜割りの入力操作が失敗した場合の画面例を示している。
図１１の場合と同様に、兜割りの入力操作が成功した場合には、図１２の（Ｂ）に示すように、制御部３０は、自キャラクタ１００に兜割りを実行させるとともに、操作オブジェクト４０の基部４２内に兜割りに関する情報（例えば、「Ａｔｔａｃｋ」）を表示する。一方、兜割りの入力操作が失敗した場合、例えば上スライド操作や斜め上スライド操作に基づいてジャンプした自キャラクタ１００が地面に着地してから下スライド操作が入力された場合には、図１２の（Ｃ）に示すように、制御部３０は、自キャラクタ１００に兜割りを実行させず、また、基部４２内にはその時点での自キャラクタ１００の状態に関する情報（例えば、「Ｒｕｎ」）を表示する。この場合、ユーザは、表示「Ｒｕｎ」を見ることで、自キャラクタ１００が地面に着地してから下スライド操作を行ったために入力操作に失敗したことを容易に認識することができる。

以上説明したように、本実施形態によれば、制御部３０は、ユーザの入力操作に基づいて、接触開始点から接触終了点に向けてタッチスクリーン２上に操作オブジェクト４０を表示させつつ、自キャラクタ１００に所定の動作を実行させる。そして、制御部３０は、自キャラクタ１００の状態を検出し、検出された自キャラクタ１００の状態に関連付けられた所定の情報（例えば、上記説明した文字情報）を、タッチスクリーン２上の操作オブジェクト４０の基部４２内に表示させる。これにより、入力操作に対するフィードバックをユーザへ直感的に与えることが可能となる。

自キャラクタ１００の状態に関連付けられた文字情報は、操作オブジェクト４０の拡大部である基部４２内に表示されている。このように、タッチスクリーン２上のデッドスペースである操作オブジェクト４０の拡大部に文字情報を表示させることで、スマートフォンのような狭い画面を有効利用することができる。

上記の実施形態においては、図１０～１２に示すように、操作オブジェクト４０の拡大部である基部４２の内側に自キャラクタ１００の状態に関する文字情報を表示しているが、これに限定されない。図１３に示すように、操作オブジェクト４０から吹き出し４８のような形で、自キャラクタ１００の状態に関する情報（例えば、「Ｒｕｎ」）を表示するようにしても良い。すなわち、自キャラクタ１００に関する情報は操作オブジェクト４０に付随するように表示されていれば良い。

また、上記の実施形態においては、図７等に示すように、基部４２を先端部４４よりも大きくするように操作オブジェクト４０を形成しているが、これに限定されない。図１４の操作オブジェクト１４０に示すように、先端部１４４を基部１４２よりも大きく形成してもよい。この場合、自キャラクタ１００の状態に関する情報（例えば、「Ｒｕｎ」）は、拡大部である先端部１４４内に表示される。

また、操作オブジェクト４０に付随して表示されるキャラクタ状態情報は、文字情報に限られず、図形等のその他の記号であっても良い。

５．キャラクタに行動を行わせれば行わせるほど、キャラクタのパラメータが向上していく構成の説明

以下、図１５～図１９を参照して、ユーザの入力操作等に応じてキャラクタがアクションを行った結果、キャラクタの各種パラメータを強化することができるゲームプログラムについて説明する。

図１５は、自キャラクタ１００などユーザが操作することが可能なゲームキャラクタのパラメータのデータ構造、および、ユーザの入力操作に応じてゲームキャラクタに各種行動を行わせた履歴とゲームキャラクタが獲得したスキルとの対応関係を含むデータ構造を示す図である。ユーザ端末１は、主記憶４等に、図１５に示すデータ構造のデータを保持し、適宜、データを参照しつつゲームを進行させる。

図１５の図示例（Ａ）は、自キャラクタ１００などユーザが操作することが可能なゲームキャラクタのパラメータのデータ構造を示す。図示例（Ａ）に示すように、自キャラクタ１００（例えば、キャラクタ名「Ｈ」のパラメータの例とする）の各種パラメータのデータ構造は、項目「グレード」と、項目「項目名」と、項目「基本値」と、項目「装備による補正値」と、項目「スキルによる補正値」と、項目「称号による補正値」とを含む。

項目「グレード」は、自キャラクタが獲得可能なスキルの範囲を示す。本実施形態では、グレード「２」の例を示しており、ユーザがゲームプレイに伴って所定のゲーム媒体を入手するなどの所定の条件を満たすことにより、項目「グレード」が更新される。

項目「項目名」は、パラメータの名称を示しており、本実施形態では、自キャラクタ１００のパラメータの名称として、「体力値（ＨＰ：ヒットポイント）」、「スキルポイント（ＳＰ）」、「攻撃値」、「防御値」を含む。「体力値（ＨＰ：ヒットポイント）」は、自キャラクタ１００の体力の値を示す。例えば、「体力値」が尽きた場合は、ゲームオーバーとしてゲームプレイを終了させることがある。「スキルポイント（ＳＰ）」は、自キャラクタ１００が所定の入力操作（長押し操作等）等に応じて、特殊なモーション（攻撃動作を行うためのモーション、体力を回復させる回復動作を行うためのモーションなどを含む）を発動させる際に消費されるパラメータである。「攻撃値」は、自キャラクタ１００が他のキャラクタにダメージを与える量に影響する。「防御値」は、自キャラクタ１００が他のキャラクタ等から受けるダメージ量に影響する。

項目「基本値」は、装備アイテム等の補正によらない自キャラクタ１００自身のパラメータの値を示す。項目「装備による補正値」は、装備アイテム等の、自キャラクタ１００と所定のアイテムを関連付けることによるパラメータの補正量を示す。項目「スキルによる補正値」は、自キャラクタ１００が獲得しているスキル（スキルの詳細は後述する）によるパラメータの補正量を示す。項目「称号による補正値」は、ゲームプレイに伴ってユーザが獲得する称号オブジェクト（例えば、ゲームプログラムの運営者によって、所定の名称を含む称号がユーザに与えられ、称号を有すること等により、「体力値の上限を増やす」などのゲーム中の効果が発生する。）に従った補正量を示す。

図１５の図示例（Ｂ）は、ユーザの入力操作に応じてゲームキャラクタに各種行動を行わせた履歴とゲームキャラクタが獲得したスキルとの対応関係を示す。

図示例（Ｂ）に示すように、キャラクタが各種行動を行った行動内容の履歴は、自キャラクタ１００のグレードを示す項目「グレード」と、項目「スキル名」と、項目「パラメータ補正の内容」と、項目「経験値」と、項目「レベル」と、項目「経験値獲得条件」とを含む。

項目「スキル名」は、自キャラクタ１００が獲得可能なスキルの名称を示す。

項目「パラメータ補正の内容」は、項目「スキル名」に示されるスキルが、項目「レベル」に達することにより自キャラクタ１００に及ぼすパラメータ補正の内容を示す。

項目「パラメータ補正の内容」としては、例えば、（ｉ）自キャラクタ１００の体力値を補正するもの、（ｉｉ）タップ等の入力操作等に応じて自キャラクタ１００が攻撃動作を行う場合に、攻撃動作の攻撃力を増加させるもの、（ｉｉｉ）攻撃動作を連続して繰り出せる回数の上限を増加させる（コンボ数を増やす）もの、（ｉｖ）自キャラクタ１００がゲームフィールドにおいて所定の入力操作に応じてゲームアイテムの採集動作（例えば、ゲームフィールド中の鉱山から石を取得する動作、草花を採集する動作、釣りをする動作など）のアニメーションを行う時間を短縮化するもの、（ｖ）自キャラクタ１００のスキルポイントの最大値を増加させるもの、（ｖｉ）フリック等の入力操作に応じて自キャラクタ１００が回避動作を行う場合に、自キャラクタ１００の回避動作の距離、速度等を増加させるもの、（ｖｉｉ）下スライド等の入力操作に応じて自キャラクタ１００にしゃがみ動作を行わせつつガードを行わせる場合に、ガード時に敵キャラクタの攻撃から受けるダメージ量を低減させるもの、（ｖｉｉｉ）上スライド等の入力操作に応じて自キャラクタ１００がジャンプ動作を行う場合にジャンプの距離、速度等を増加させるもの、（ｉｘ）上スライド等の入力操作に応じて自キャラクタ１００がジャンプしている最中にタップ操作、下スライド操作等を受け付けて空中での攻撃動作を行う場合に、その攻撃力や空中での攻撃可能な回数を増加させるもの、（ｘ）自キャラクタ１００が、素材アイテムをもとに武器・防具などを合成し、強化させるクラフト動作を行う場合に、そのクラフトにより得られるアイテムの種類、アイテム生成の成功度などを高めるもの、などがある。

項目「経験値」は、項目「スキル名」に示されるスキルについて、項目「経験値獲得条件」に示される条件が満たされることにより増加する値と、レベルアップに必要な経験値の値とを示す。

項目「レベル」は、項目「スキル名」に示されるスキルについて、ユーザが成長させた度合いを示す。例えば、スキル「体力値アップ」について、レベルが低い場合よりも、レベルが高い場合の方が、パラメータ補正内容が良好となるようにすることができる。これにより、ユーザに対し、スキルのレベルアップをさせるため、項目「経験値獲得条件」に示される動作を自キャラクタ１００に行わせるよう動機づけることができる。この結果、ユーザは、自キャラクタ１００に対し、図６等に示すアクションを行わせれば行わせるほど、自キャラクタ１００のパラメータを更新することができるので、ゲームプレイを継続して行い、自キャラクタ１００の操作に習熟するよう動機づけることができる。また、これらスキルの中には、あるスキルのレベルが一定程度に達することで、スキルの習得が可能になるものが含まれる。すなわち、第１のスキルについてレベルが一定程度に達する（例えば、レベルが最大に達する）ことにより、第２のスキルを獲得可能になる。

項目「経験値獲得条件」は、項目「スキル名」に示されるスキルについて経験値を獲得し、レベルを向上させるための条件を示す。このような条件として、例えば、図６等に示すアクションを自キャラクタ１００に行わせるための入力操作を行うことがある。換言すれば、自キャラクタ１００にアクションを行わせるための入力操作を行い、このことに起因して自キャラクタ１００がアクションを行うことで、各スキルについて経験値を獲得することができる。したがって、ユーザは、図６等に示す様々なアクションを次々と試そうと動機づけられる。また、スキルによっては、スキル名「体力値アップ」のように、自キャラクタ１００がダメージを受けることでパラメータを成長させられるものもある。これにより、移動のためのアクションとともに、敵キャラクタと戦闘を行うためのアクション（回避動作、攻撃動作、ガード動作など）実行のための入力操作をいっそうユーザに促すよう動機づけることができる。

図１６は、ユーザの入力操作に応じて自キャラクタ１００が行動を行うことに起因して、自キャラクタ１００がスキルを獲得したことを通知する局面を示す。

図１６の図示例（Ａ）は、一例として、横スクロールアクションゲーム（ＭＭＯＲＰＧであってもよい）を示している。図示例（Ａ）において、ユーザが横スライド操作（ドラッグ操作）を継続することにより、自キャラクタ１００が移動している局面を示す。ユーザ端末１は、タッチスクリーン２に、ＵＩ部品９００を表示している。ＵＩ部品９００は、ユーザのタッチ操作等の入力操作を受け付けて、自キャラクタ１００が習得しているスキルの一覧をユーザが確認するための画面へと遷移させるためのアイコンである。

図示例（Ｂ）は、ユーザが自キャラクタ１００を斜めにジャンプさせるための入力操作として、斜め上スライド操作（または、フリック操作でもよい）を行い、自キャラクタ１００がジャンプしたことに起因して、自キャラクタ１００が新たにスキルを獲得したこと、スキルを成長させたことをユーザに通知する局面を示す。

ユーザ端末１は、タッチスクリーン２に、自キャラクタ１００が新たにスキルを獲得したことを通知するためのＵＩ部品９０２を、自キャラクタ１００の近傍に一定時間（例えば、数秒）表示させる。これにより、ユーザは、ゲームプレイ中に自キャラクタ１００を注視しつつ、ユーザの入力操作により自キャラクタ１００にアクションを行わせた結果、新たに自キャラクタ１００がスキルを獲得したこと、スキルを成長させたことを容易に認識することができる。ユーザ端末１は、ＵＩ部品９０２が表示されてから一定時間が経過すると、ＵＩ部品９０２の表示を終了する。これにより、ユーザは、スキルを獲得したこと、スキルを成長させたことを認識したうえで、再び自キャラクタ１００に注目して自キャラクタ１００にアクションを行わせることに集中できる。

ユーザ端末１は、タッチスクリーン２に表示されるＵＩ部品９００の近傍に、ＵＩ部品９０１を表示させる。ＵＩ部品９０１は、自キャラクタ１００が獲得しているスキルにおいてユーザが未確認のものがあること、スキルを成長させた結果をユーザが未確認のものがあることを示すアイコンである。図示例（Ｂ）では、ユーザが未確認のスキルの数をＵＩ部品９０１において示している。ユーザ端末１は、ＵＩ部品９０１を、ユーザが未確認のスキルがなくなるまで表示し続けることとしてもよい。これにより、ユーザは、自キャラクタ１００に注目してアクション操作を行い、敵キャラクタとの戦闘を行ったあとで、落ち着いてスキル一覧を確認するといったように、ユーザが自キャラクタ１００に行わせたいアクションに集中させつつ、ＵＩ部品９０１を表示することで、ユーザが自キャラクタ１００の成長を確認する機会を逸するのを抑止することができる。

図１７は、自キャラクタ１００が獲得可能なスキルと、自キャラクタ１００が習得しているスキルとをユーザが確認することができるスキル一覧の画面例を示す。ユーザ端末１は、例えば、ＵＩ部品９００に対するユーザのタッチ操作を受け付けることにより、図１７に示す画面をタッチスクリーン２に表示させる。

図１７の図示例（Ａ）は、自キャラクタ１００が未だ獲得していないスキルと、自キャラクタ１００が既に習得しているスキルとをタッチスクリーン２に表示している局面を示す。図示例（Ａ）に示すように、ユーザ端末１は、タッチスクリーン２において、スタンダードスキルボタン９１０と、スペシャルスキルボタン９１１と、第１のスキル群９１２と、第２のスキル群９１３とを表示している。スタンダードスキルボタン９１０とスペシャルスキルボタン９１１とは、ユーザの入力操作に応じて、タッチスクリーン２に表示するスキルの種別を切り替えるためのアイコンである。図示例（Ａ）では、スタンダードスキルボタン９１０が有効になっていることをユーザが認識できるよう、スペシャルスキルボタン９１１と比べてスタンダードスキルボタン９１０を強調表示している。

ユーザがスペシャルスキルボタン９１１にタッチ操作を行うと、ユーザ端末１は、タッチスクリーン２に表示するスキルの種別を切り替えて、スペシャルスキルボタン９１１が有効になっていることをユーザが認識できるよう、スタンダードスキルボタン９１０と比べてスペシャルスキルボタン９１１を強調表示する。

スペシャルスキルボタン９１１により表示されるスキルの種別としては、例えば、（ｉ）自キャラクタ１００が入力操作に応じたアクションによらず習得し成長させることができるもの、（ｉｉ）自キャラクタ１００についてのエピソードの閲覧を可能とするもの、（ｉｉｉ）過去のゲーム中での自キャラクタ１００の会話内容のログの表示を可能とするもの、（ｉｖ）戦闘中の画面で、タップ操作等の攻撃動作とは別に、スキルポイントを消費して発動可能な攻撃動作または回復動作などをキャラクタに行わせるもの、などが含まれる。

ここで、（ｉ）自キャラクタ１００が入力操作に応じたアクションによらず習得し成長させることができるスキルとしては、例えば、ユーザがゲームプレイに伴ってゲーム媒体を獲得することにより、自キャラクタ１００が使用可能となるものを含む。例えば、ユーザのゲームプレイに伴って、様々なアイテム、スキル、キャラクタ、ゲーム中の仮想通貨などを供出するゲーム媒体をゲーム中でユーザが入手したとする。ユーザ端末１は、このゲーム媒体からユーザに付与する対象を抽選により決定する。ユーザ端末１は、ゲーム媒体からユーザに付与する対象がスキルであれば、どのスキルを付与するかを抽選で決定する。ゲームプレイ時に、ゲーム媒体からアイテム等を供出するための所定の条件を満たすことで、ユーザに対し、抽選結果に従った付与対象（アイテム、スキル、キャラクタ、ゲーム中の仮想通貨など）を付与する。ここで、ユーザ端末１は、ユーザが自キャラクタ１００に攻撃動作を行わせて敵キャラクタを攻撃し、敵キャラクタを撃破した等により、ユーザにゲーム媒体を付与することとしてもよい。

第１のスキル群９１２は、自キャラクタ１００が習得可能なスキルのうちグレード「１」に分類されるスキルを含む。第２のスキル群９１３は、自キャラクタ１００が習得可能なスキルのうちグレード２に分類されるスキルを含む。

ユーザ端末１は、ユーザのゲームプレイに伴い所定の条件を満たすことにより、自キャラクタ１００のグレードを更新する。例えば、所定の条件とは、ユーザが入力操作を行うことで自キャラクタ１００にアクションを行わせることで満たすことができるものとしてもよい。例えば、ユーザ端末１は、ユーザの入力操作に応じて自キャラクタ１００にアクションを行わせて、敵キャラクタを撃破する等により、アイテム等を供出するゲーム媒体をユーザに付与する。ユーザ端末１は、このゲーム媒体からユーザに付与される対象がキャラクタである場合に、複数のキャラクタのうちいずれのキャラクタをユーザに供出するかを抽選する。抽選の結果、ユーザが獲得していないキャラクタがゲーム媒体から供出される場合は、ユーザが当該キャラクタを操作可能とし、ユーザが既に獲得しているキャラクタがゲーム媒体から供出される場合は、当該キャラクタのグレードを更新する。例えば、ユーザが既にグレード「１」のキャラクタを操作可能な状態で、当該キャラクタがゲーム媒体から供出されると、ユーザ端末１は、当該キャラクタのグレードをグレード「１」からグレード「２」に更新し、当該キャラクタが獲得可能なスキルの範囲を拡大する。

このように、当該キャラクタのグレードが更新されるまでは、当該キャラクタのグレードの範囲内でスキルを獲得し、成長させることができるようにすることで、ユーザに対し、キャラクタのグレードを更新するためのゲームプレイを促すことができる。また、ゲームプレイに伴ってユーザが獲得するゲーム媒体からキャラクタ等が供出されることでキャラクタのグレードが更新されることにより、ユーザにとっては、ゲームプレイをすればするほどキャラクタの成長を実感させることができる。例えば、自キャラクタ１００が攻撃動作時に連続して繰り出せる技の上限数（コンボ数）が、スキルの成長とともに更新されると、いっそうキャラクタの成長をユーザが実感することができ、ゲームプレイの継続を促すことができる。

図示例（Ａ）において、第１のスキル群９１２と比べて、第２のスキル群９１３では、ユーザが未だ獲得していないスキルがあることを、ユーザが獲得済みのスキルと区別できるよう表示している。ユーザ端末１は、ユーザが獲得済みのスキルについては、各スキルのアイコンの近傍に、スキルのレベルを示す表示を行っている。一方、ユーザが未だ獲得していないスキルについては、アイコンをグレーアウトさせる、スキルの中身をアイコンから判別できないようにするといった表示態様にすることで、ユーザがこれらスキルを獲得しようと動機づけることができる。

図示例（Ｂ）は、ユーザが獲得し、または成長させたスキルについて、ユーザが未確認のものがあることを示している。図示例（Ｂ）において、ユーザ端末１は、ユーザが未確認のスキルがあることをユーザに通知するためのＵＩ部品９１５を、スキルのアイコンに重ねてタッチスクリーン２に表示しているが、ＵＩ部品９１５の表示態様はこれに限られない。これにより、ユーザに対し、ＵＩ部品９１５に対する操作を促して、よりいっそう自キャラクタ１００の成長をユーザが実感する機会を増やすことができる。

図１８は、ユーザ端末１が、自キャラクタ１００の動作内容に応じて、スキル習得のための各スキルの経験値を更新し、スキルを獲得したこと、スキルを成長させたことをユーザに通知する処理を示すフローチャートである。ユーザ端末１は、プログラムに従って動作することにより、以下の各ステップを実行する。

ステップＳ１８０１において、ユーザ端末１のＣＰＵ３は、自キャラクタ１００についてイベントが発生したことを検出する。イベントの内容としては、図１５の図示例（Ｂ）の項目「経験値獲得条件」に示されるものを含む。

例えば、ユーザが自キャラクタ１００にアクションを行わせるための入力操作がタッチスクリーン２に行われたことに応答して、自キャラクタ１００に行わせるアクションの内容が決定され、その決定内容に従って自キャラクタ１００を動作させる指示をＣＰＵ２が行ったことによるイベントを含む。また、イベントの内容としては、自キャラクタ１００が、敵キャラクタが行う攻撃モーションの範囲に位置することまたは障害物に衝突すること等の、体力値を減少させるイベントを含む。また、イベントの内容としては、自キャラクタ１００がアクションを行った結果、敵キャラクタに攻撃をヒットさせたこと、敵キャラクタにダメージを与えたこと、自キャラクタ１００を回復させたこと、自キャラクタ１００以外の他のキャラクタを回復させたことなどを含む。

ステップＳ１８０３において、ＣＰＵ３は、ステップＳ１８０１で発生を検出したイベントの内容を判別する。例えば、イベントの内容が、入力操作に応じて自キャラクタ１００を動作させるものであれば、その入力操作に応じて自キャラクタ１００が行うアクションの内容（例えば、攻撃動作、採集動作など）を判別する。

ステップＳ１８０５において、ＣＰＵ３は、ステップＳ１８０３で判別した内容に応じて、各スキルの経験値を更新する。

ステップＳ１８０７において、ＣＰＵ３は、ステップＳ１８０５の処理により、各スキルについて経験値がレベルアップに必要な水準に達したものがある場合に、当該スキルを獲得したこと、成長させたことについてユーザが未確認であることを示すフラグを設定するとともに、図１６の図示例（Ｂ）に示すような態様で、その旨を示す通知をタッチスクリーン２に表示させる。ＣＰＵ３は、ユーザが未確認であることを示すフラグが設定されたスキルの数をカウントすることで、図１６の図示例（Ｂ）のＵＩ部品９０１において、ユーザが未確認のスキルの数を表示することができる。

図１９は、ユーザ端末１が、ユーザの入力操作に応じて、自キャラクタ１００が習得しているスキル一覧の画面をタッチスクリーン２に提示する処理を示すフローチャートである。ユーザ端末１は、プログラムに従って動作することにより、以下の各ステップを実行する。

ステップＳ１９０１において、ユーザ端末１のＣＰＵ３は、スキル一覧を表示させるためのユーザの入力操作を検出する。例えば、図１６に示すＵＩ部品９００へのタッチ操作を検出することで、ＣＰＵ３は、以下の各ステップを実行する。

ステップＳ１９０３において、ＣＰＵ３は、ユーザが新たに獲得したスキル、成長させたスキルにおいて、ユーザが未確認のスキルを、ステップＳ１８０７で各スキルに設定されるフラグにより特定する。

ステップＳ１９０５において、ＣＰＵ３は、ユーザが未確認のスキルに、ユーザの確認を促すための通知用のアイコンを配置して、タッチスクリーン２に表示する画像を生成する。

ステップＳ１９０７において、ＣＰＵ３は、ステップＳ１９０５で生成した画像をタッチスクリーン２に表示する。例えば、図１７の図示例（Ｂ）のＵＩ部品９１５が表示されるスキルは、スキルを新たに獲得したこと、スキルを成長させたことについてユーザが未確認のスキルを示している。

［本開示が示す第２の実施形態の説明］
以下、本開示が示す第２の実施形態について図面を参照しながら説明する。なお、本実施形態の説明において既に説明された部材と同一の参照番号を有する部材については、説明の便宜上、その説明は繰り返さない。第２の実施形態では、ユーザが複数のキャラクタを編成して、ゲームプレイ中に、操作対象のキャラクタをユーザが切り替えつつ進行させるゲームにおいて、キャラクタを切り替えるための操作について主に説明する。

６．ＵＩ画像（操作キー）の表示処理の説明
図２０～図２４を参照して、本実施形態に係るゲームプログラムにおける操作キーの表示処理について説明する。

図２０は、第２の実施形態においてプレイヤキャラクタをユーザが変更するためのユーザインターフェース画像の表示処理を示すフローチャートである。

図２０のステップＳ１１において、制御部３０は、ユーザの指などがタッチスクリーン２へ接近したか（接近操作が入力された）否かを、タッチセンシング部１０から入力操作受付部３２へ出力された信号により判定する。接近操作が入力されたと判定された場合には（ステップＳ１１のＹｅｓ）、ステップＳ１２において、制御部３０は、接触終了点の位置を検出する。そして、ステップＳ１３において、制御部３０は、接触終了点が、接近操作が検出された位置（接触開始点）を含む一定領域内に含まれるか否かを判定する。接触終了点が接近開始点を含む一定領域内に含まれていない、すなわち、接触開始点と接触終了点とが一定距離以上離れていると判定された場合には（ステップＳ１３のＮｏ）、ステップＳ１４において、制御部３０は、ユーザが自キャラクタ１００の操作を要求していると判断し、接触開始点と接触終了点とによって規定されるベクトル（図５の（Ｄ）参照）に基づいて、自キャラクタ１００に所定の動作を実行させる。このとき、制御部３０は、接触開始点の周囲に図７に示す操作オブジェクト４０の基部４２を表示し、接触終了点に基づいて操作オブジェクト４０を弾性変形させても良い。その後、ステップＳ１１へと戻り、処理が繰り返される。

一方、接触終了点が接近開始点を含む一定領域内に含まれると判定された場合には（ステップＳ１３のＹｅｓ）、ステップＳ１６において、制御部３０は、接近操作が継続している時間が一定時間を超えたか否かを判定する。すなわち、ここでは、制御部３０は、ユーザの入力操作が「長押し操作」であるか否かを判定する。ユーザの入力操作が「長押し操作」であると判定された場合には（ステップＳ１６のＹｅｓ）、ステップＳ１７において、制御部３０は、タッチスクリーン２上に所定のＵＩ画像６０（図２１参照）を表示する。

図２１は、図２０に示すフローチャートにおけるゲーム画面の例を示す図である。図２２は、図２１に示すゲーム画面に連続するゲーム画面の例を示す図である。

図２１に示すように、ＵＩ画像６０は、ベース部６２と、第一の操作キー６４（第一の操作オブジェクトの一例）と、第二の操作キー６６（第二の操作オブジェクトの一例）とから構成されている。ベース部６２の部分には、例えば、略円形状の画像を表示しても良く、特に画像を表示しなくても良い。すなわち、ベース部６２は、第一の操作キー６４および第二の操作キー６６の配置関係を決定するための基準として構成されていれば良い。第一の操作キー６４は、第一から第三のアイコン６４Ａ～６４Ｃから構成されている。第一のアイコン６４Ａは、タッチスクリーン２上に現在表示されている（すなわち、ユーザにより選択されている）自キャラクタ１００に対応している。第二のアイコン６４Ｂは、ユーザ選択により自キャラクタ１００と変更可能なキャラクタ１２０に対応している。第三のアイコン６４Ｃは、ユーザ選択により自キャラクタ１００と変更可能であってキャラクタ１２０とは異なるキャラクタ１３０に対応している。第二の操作キー６６は、現在選択中のキャラクタのスキルを発動させるための操作キーである。第二の操作キー６６への入力操作により発動するスキルは、例えば、図１５の例で説明したスキルポイントを一定量消費して発動する攻撃動作または回復動作などである。このように、スキルポイントを消費して発動する動作であるため、タップ操作等によりキャラクタが行う攻撃動作等と比較して、強力な効果を持つものとしてもよい。

第一のアイコン６４Ａには、現在使用中のキャラクタ（自キャラクタ１００）を示す情報（例えば「使用中」）が表示されている。第一のアイコン６４Ａは、タッチスクリーン２上に現在表示されている自キャラクタ１００に対応するアイコンであるため、選択不能な状態で表示されていることが好ましい。すなわち、ユーザが第一のアイコン６４Ａ上でリリース操作を行ったとしても、何らのアクションも実行されない。第二のアイコン６４Ｂおよび第三のアイコン６４Ｃには、自キャラクタ１００と変更可能なキャラクタ１２０，１３０の情報（例えば、キャラクタ１２０，１３０の顔）がそれぞれ表示されている。第二の操作キー６６には、例えば「スキル」と表示されている。

これらの操作キー６４，５６は、長押し操作がされた接触開始点（すなわち、ベース部６２）から左側に所定距離だけ離れてベース部６２に対して放射状となるように配列されている。第一の操作キー６４（各アイコン６４Ａ～６４Ｃ）および第二の操作キー６６は、操作入力が入力された位置であるベース部６２に対して、それぞれの配置関係が固定されている。例えば、ベース部６２の左側領域において、上から、第二の操作キー６６、第一のアイコン６４Ａ、第二のアイコン６４Ｂ、第三のアイコン６４Ｃの順に、タッチスクリーン２の左右方向に対して非対称となるように配置されている。

なお、図２１に示す例においては、ユーザが右手の指でタッチスクリーン２を操作するものと仮定して、右手指で操作しやすいように、ベース部６２の左側領域に第一の操作キー６４および第二の操作キー６６を配置しているが、この例に限られない。例えば、左手指で操作する場合には、ユーザの選択操作によりベース部６２の右側領域にこれらの操作キーを配置しても良い。この場合も、各操作キー６４，６６の配置関係は固定されている。すなわち、ユーザの右手による入力操作の場合とユーザの左手による入力操作の場合とで第一の操作キー６４（各アイコン６４Ａ～６４Ｃ）および第二の操作キー６６の配置が左右対称に切り替え可能であっても良い。このように、ユーザが右手と左手のどちらでタッチスクリーン２を操作するかに応じてベース部６２に対して操作キー６４，６６の配置を左右対称に切り替えることで、操作性をさらに向上させることができる。

続いて、ステップＳ１８において、制御部３０は、リリース操作が入力されたか否かを判定する。リリース操作が入力されたと判定された場合には（ステップＳ１８のＹｅｓ）、ステップＳ１９において、制御部３０は、リリース操作が入力された位置（タッチオフ位置）が各操作キー６４，５６の領域に含まれるか否かを判定する。タッチオフ位置が各操作キー６４，５６の領域に含まれないと判定された場合には（ステップＳ１９のＮｏ）、ステップＳ２０において、制御部３０は、ユーザが各操作キー６４，５６に対応する操作を要求していないと判断し、何らのアクションも実行せずにＵＩ画像６０を非表示とする。その後、ステップＳ１１へと戻り、処理が繰り返される。

一方、タッチオフ位置が各操作キー６４，５６の領域に含まれていると判定された場合には（ステップＳ１９のＹｅｓ）、ステップＳ２１において、制御部３０は、選択された操作キーに対応する操作を実行する。例えば、図２２の（Ａ）に示すように、第三のアイコン６４Ｃ上でリリース操作が入力されたと判定された場合には、図２２の（Ｂ）に示すように制御部３０は、自キャラクタ１００の代わりに第二のアイコン６４Ｃに対応するキャラクタ１３０をタッチスクリーン２上に表示させるとともに、ＵＩ画像６０を非表示とする。その後、ステップＳ１１へと戻り、処理が繰り返される。

図２３は、プレイヤキャラクタをユーザが変更した後でのユーザインターフェース画像の例を示す図である。

図２３は、タッチスクリーン２上に表示されるキャラクタが、自キャラクタ１００から別のキャラクタ１３０に変更された後で、長押し操作が入力された場合のＵＩ画像６０を示している。
この場合、タッチスクリーン２上に現在表示されているキャラクタ１３０に対応する第三のアイコン６４Ｃには「使用中」と表示され、当該第三のアイコン６４Ｃは選択不能な状態となっている。また、第一のアイコン６４Ａおよび第二のアイコン６４Ｂには、キャラクタ１３０と変更可能なキャラクタ１００，１２０の顔がそれぞれ表示されている。このように、キャラクタ変更用のアイコンとして、現在選択されているキャラクタに対応するアイコンも選択不能な状態で表示させることで、各アイコン６４Ａ～６４Ｃの配置関係を固定して表示することができる。

図２４は、プレイヤキャラクタ変更用のユーザインターフェース画像を表示させたままスライド操作が入力された場合のゲーム画面の例を示す図である。

図２４の（Ａ）および（Ｂ）は、長押し操作が入力された状態（ＵＩ画像６０が表示された状態）から所定方向にスライド（ドラッグ）操作が入力された場合の画面例を示している。
ステップＳ１７において、長押し操作によりＵＩ画像６０が表示された状態でドラッグ操作が入力されると、制御部３０は、接触開始点から接触終了点までのドラッグ操作が一定速度以下であるか否かを判定する。ドラッグ操作の速度は、例えば、ドラッグ操作の接触開始点から接触終了点までのスライド量とフレーム数に基づいて検出することができる。ドラッグ操作の検出速度が所定の閾値以下の場合には、制御部３０は、ＵＩ画像６０をドラッグ操作に追随させて移動させつつ、キャラクタ１００をドラッグ操作に応じて操作する（移動や、ジャンプなど）。例えば、図２４の（Ａ）に示すように、長押し操作によりＵＩ画像６０が表示された状態からユーザが矢印Ａの方向にドラッグ操作を行うと、制御部３０は、ＵＩ画像６０を表示させたまま、そのドラッグ操作の方向に基づいて、自キャラクタ１００に所定の動作を実行させるとともにＵＩ画像６０を移動させる。例えば、ドラッグ方向が斜め上方向である場合には、図２４の（Ｂ）に示すように、当該ドラッグ方向に基づいて、操作オブジェクト４０を弾性変形させながら表示させつつ、キャラクタ１００をジャンプさせる。それと同時に、制御部３０は、ＵＩ画像６０を、第一の操作キー６４（アイコン６４Ａ～６４Ｃ）および第二の操作キー６６の配置関係を維持しながら、ドラッグ方向に応じて移動させる。これにより、キャラクタ１００を別のキャラクタに変更できる状態を維持しつつ、現在表示されているキャラクタを操作することができる。このとき、ドラッグ操作の接触終了点には常にＵＩ画像６０のベース部６２が配置されるため、各操作キー６４，６６は選択することができない。

一方、ドラッグ操作が一定速度よりも速い場合には、制御部３０は、ＵＩ画像６０をドラッグ操作に追随して移動させないようにし、各操作キー６４，６６を選択可能とする。すなわち、この場合、ユーザは、各操作キー６４、６６上でリリース操作を行って、各操作キー６４，６６を選択することができる。このように、ドラッグ操作の速度に応じて、自キャラクタ１００の操作と各操作キー６４，６６の操作とを切り替えることで、操作性の自由度を向上させることができる。

以上説明したように、本実施形態によれば、制御部３０は、タッチスクリーン２上の任意位置に対するユーザの長押し操作に基づいて、タッチスクリーン２に自キャラクタ１００を変更するための第一の操作キー６４（ＵＩ画像６０）を表示させ、ユーザが第一の操作キー６４を選択操作することで、タッチスクリーン２に表示されている自キャラクタ１００を異なるキャラクタ（例えば、キャラクタ１３０）へと変更する。これにより、通常時にはタッチスクリーン２に表示された空間内の操作領域や視認可能範囲に影響を与えることなく、ユーザによる長押し操作時のみに自キャラクタ１００を変更するためのＵＩ画像６０を提供することができる。

また、ＵＩ画像６０は、各アイコン６４Ａ～６４Ｃや第二の操作キー６６の配置関係が固定されて表示されるため、各操作キー６４，６６の位置をユーザが記憶することができる。これにより、各キャラクタ１００，１２０，１３０に対応するアイコン６４Ａ～６４Ｃやスキル発動用の操作キー６６の位置をユーザが記憶することができるため、ユーザはＵＩ画像６０の表示を視認することなくキャラクタの変更やスキル発動を実行することができる。

７．ゲームフィールドに登場させる、ユーザの操作対象のキャラクタを、ユーザの切替操作によらず自動で切り替える処理

以上のように、ユーザは、各操作キー６４、６６へ入力操作を行うことにより、操作対象とするキャラクタを変更することができる。ユーザ端末１は、ユーザがゲーム中に変更可能なキャラクタをパーティとして編成してゲーム進行させている場合に、パーティに含まれる各キャラクタを変更するための入力操作に応じて、タッチスクリーン２に表示させるキャラクタを変更する。

ここで、第２の実施形態では、ユーザ端末１は、ユーザが操作対象とするキャラクタを変更するための入力操作（各操作キー６４等への操作）によらず、ゲーム進行に応じて自動的に切り替える処理を行うことができる。具体的には、ユーザがキャラクタを変更する入力操作によらず、敵キャラクタとの戦闘中に自動的にキャラクタを変更（オートチェンジ）する第１のモード（オートチェンジ適用モード）と、第１のモードを停止させる第２のモード（オートチェンジ停止モード）とを、ユーザが選択することができる。

第１のモードにおいて、例えば、ユーザが操作対象とする各キャラクタのパラメータと、敵キャラクタのパラメータとを比較して、パーティ編成に含まれる各キャラクタのうちいずれかのキャラクタを特定し、特定したキャラクタをタッチスクリーン２に表示させることで、ユーザが操作対象とするキャラクタを変更する。ここで、タッチスクリーン２には、多数の敵キャラクタが表示され得るが、ユーザ端末１は、各キャラクタのパラメータと比較する対象となる敵キャラクタを、ユーザが操作対象とするキャラクタが攻撃動作を行うためにロックオンしているキャラクタであるとしてもよい。ロックオンしている状態であると、キャラクタ１００が敵キャラクタ２００を向いているかいなかにかかわらず、ユーザがタップ操作等によりキャラクタ１００に攻撃動作を行わせる場合に、敵キャラクタ２００に向けて攻撃動作のためのアクションを行う。ユーザ端末１は、例えば、キャラクタ１００に最も近い距離にいる敵キャラクタ２００を、キャラクタ１００が攻撃対象としてロックオンしたキャラクタとする。

第１のモードにおいて、ユーザ端末１は、タッチスクリーン２に表示させるキャラクタを特定するため、例えば、（ｉ）ユーザが操作対象とするキャラクタが攻撃対象とする敵キャラクタに対し、パーティに含まれる各キャラクタの攻撃に関するパラメータに基づいて、変更対象のキャラクタを特定する。ユーザ端末１は、例えば、敵キャラクタに対し、最もダメージ効率がよいキャラクタを、タッチスクリーン２に表示させるキャラクタとして特定する。

第１の実施形態で説明したように、ユーザが操作対象とするキャラクタは、ユーザの入力操作に応じて様々な動作を行うことにより、そのパラメータを成長させることができる。ユーザ端末１は、攻撃に関するパラメータに基づいて、敵キャラクタと戦闘するキャラクタを特定する場合、ユーザがパーティ編成したキャラクタの各パラメータの補正内容を参照して、攻撃力の高さ、コンボ数などに基づいて、単位時間あたりに敵キャラクタに与えうるダメージ量が最も高いキャラクタを、タッチスクリーン２に表示させるキャラクタとして特定することもできる。

また、ユーザ端末１は、（ｉｉ）ユーザが操作対象とするキャラクタが攻撃対象とする敵キャラクタから攻撃を受けたとした場合に、キャラクタが生存する可能性の高低に応じて、タッチスクリーン２に表示させるキャラクタを特定してもよい。ユーザ端末１は、例えば、パーティ編成に含まれるキャラクタのうち、敵キャラクタから攻撃を受けたとしてもキャラクタが受けるダメージが最も小さくなるキャラクタを特定する。

また、ユーザ端末１は、（ｉｉｉ）攻撃対象とするキャラクタの移動速度のパラメータと、ユーザがパーティ編成した各キャラクタの移動に関するパラメータ（移動速度、回避動作の速さ、回避動作の距離、ジャンプの速さ、ジャンプの距離など）とに基づいて、攻撃対象とするキャラクタに攻撃を成功させやすそうなキャラクタを、タッチスクリーン２に表示させるキャラクタとして特定してもよい。例えば、敵キャラクタの移動速度が速い場合は、ユーザが操作するキャラクタが片手剣や拳、斧等の攻撃手段であれば、敵キャラクタの移動に追従しやすいキャラクタのほうが攻撃をヒットさせやすい場合があると想定される。ユーザ端末１は、敵キャラクタの移動に関するパラメータと、パーティ編成した各キャラクタの移動に関するパラメータとを比較して、例えば、敵キャラクタの移動速度と同等か、より速いキャラクタを、タッチスクリーン２に表示させるキャラクタとして特定する。

図２５は、ゲームプログラムにおいてユーザが操作対象とし得るキャラクタと、ユーザが操作対象とすることができるキャラクタとを管理するためのキャラクタ管理情報のデータ構造を示す図である。ユーザ端末１は、主記憶４等に、図２５に示すデータ構造のデータを保持し、適宜、データを参照しつつゲームを進行させる。

図２５に示すように、キャラクタ管理情報は、項目「キャラクタ識別情報」と、項目「キャラクタ名称」と、項目「キャラクタ属性」と、項目「ユーザの使用可否」と、項目「パーティ編成」と、項目「グレード」とを含む。

項目「キャラクタ識別情報」は、ゲームプログラムにおいてユーザが操作対象として獲得し得るキャラクタそれぞれを識別するための情報である。

項目「キャラクタ名称」は、各キャラクタの名称を示す。

項目「キャラクタ属性」は、各キャラクタに設定される属性を示す。ここで、キャラクタに設定される属性とは、キャラクタが装備可能な装備アイテムの種別を含む。装備アイテムとしては、キャラクタと関連付けることができる武器の種類、防具の種類、アクセサリの種類などがある。各キャラクタに設定される属性として、武器種とは別に設定されるものとして、攻撃や防御の際に参照される別のパラメータを含む。例えば、三すくみのようにタイプごとの相性が設定されているものがある。図２５の例では、例えば、タイプ「水」はタイプ「火」に強く、タイプ「火」はタイプ「土」に強く、タイプ「土」はタイプ「水」に強い、といったような相性が設定されており、これら相性に基づいて、キャラクタとキャラクタとの戦闘におけるダメージ量が補正されることがある。また、例えば、キャラクタによっては、弱点となる属性、攻撃を無効化できる属性が設定されていることもある。例えば、空を飛ぶキャラクタについて、タイプ「土」の攻撃を無効化する（ダメージを受けない）一方、タイプ「風」の攻撃が弱点であるとして、攻撃を受けた時のダメージ量が増加する。

ユーザ端末１は、第１のモードにおいて、ユーザが操作対象とするキャラクタが攻撃対象とする敵キャラクタに対し、パーティに含まれる各キャラクタの攻撃に関するパラメータに基づいて、変更対象のキャラクタを特定する場合に、これらキャラクタに設定される属性と、敵キャラクタについて設定される属性とに基づいて、変更対象のキャラクタを特定することとしてもよい。ユーザ端末１は、例えば、パーティに編成される各キャラクタのうち、各キャラクタの基本値、装備による補正値、スキルによる補正値により定まる攻撃値と、各キャラクタが攻撃をする際の最大コンボ数と、各キャラクタの属性と、敵キャラクタの属性とに基づいて、単位時間あたりに敵キャラクタに与えるダメージが最も高いキャラクタを特定することができる。

項目「ユーザの使用可否」は、ユーザがゲームプレイにおいて使用可能となったキャラクタか、ユーザが未獲得のキャラクタかを示す。

項目「パーティ編成」は、ユーザがゲームプレイ時にパーティとして編成するキャラクタとして組み込まれているか否かを示す。ユーザ端末１は、例えば、３人一組でゲームを進行させることができる場合に、ユーザが使用することができるキャラクタの中から、パーティとして少なくとも一人、最大３名の指定をユーザから受け付けて、受け付けたパーティ編成（デッキと呼ぶこともある）を保存する。

項目「グレード」は、第１の実施形態で説明したように、キャラクタが獲得可能なスキルの範囲を示す。

図２６は、ユーザがキャラクタを変更する入力操作によらず、敵キャラクタとの戦闘中に自動的にキャラクタを変更する第１のモードと、第１のモードを停止させる第２のモードとを切り替えるためのユーザインターフェース画像と、オートチェンジによりキャラクタが変更されるゲーム画面とを示す図である。

図２６の図示例（Ａ）に示すように、ユーザ端末１は、タッチスクリーン２において、ユーザインターフェース画像において、オートチェンジ可能な第１のモードとするか、第１のモードを切り替えて第２のモードとするかの変更操作をユーザから受け付けるためのＵＩ画像６４Ｅを表示する。図２３で説明したように、ユーザ端末１は、ユーザから長押し操作を受け付けた場合に、ＵＩ画像６４Ｅを含むＵＩ画像６０をタッチスクリーン２に表示させる。図示例（Ａ）では、ユーザが第１のモードを有効にしていることを、ＵＩ画像６４Ｅにおいて「オートキャラチェンジ：ＯＮ」として表示しているとともに、ＵＩ画像６４Ｅに対するドラッグ操作等により、第１のモードから第２のモードへと切替可能であることを表示している。図示例（Ａ）に示すように、オートチェンジを有効にするか否かのＵＩ画像６４Ｅを、ユーザが操作対象のキャラクタを切り替えるためのＵＩ画像６４、操作対象のキャラクタにスキルを発動させるＵＩ画像とは異なる位置に表示することで、ユーザの誤入力を抑止することが望ましい。図示例（Ａ）に示すように、操作対象のキャラクタにスキルを発動させるＵＩ画像、および、操作対象のキャラクタを切り替えるためのＵＩ画像６４と、ＵＩ画像６４Ｅとが、ユーザが長押し操作を行った箇所に基づき表示されるベース部６２に対向するように配置してもよい。

図示例（Ｂ）と図示例（Ｃ）は、オートキャラチェンジが有効な状態で、ユーザが操作対象とする各キャラクタと、敵キャラクタ２００とのパラメータを比較して、キャラクタ１３０からキャラクタ１００へと、ユーザの操作対象のキャラクタが変更される局面を示す。図示例（Ｂ）において、キャラクタ１３０と、敵キャラクタ２００とが一定距離以内にあるために、キャラクタ１３０が敵キャラクタ２００をロックオンしている状態にあるとする。この状態で、ユーザ端末１は、タッチスクリーンに対するタップ操作を受け付けて、タップ操作が行われたことを示すＵＩ部品２６０を表示している。このとき、ユーザ端末１は、タップ操作が行われたことにより、キャラクタ１３０に攻撃動作を行わせるためのイベントが発生したことに応答して、パーティに編成される各キャラクタのパラメータと、敵キャラクタ２００のパラメータとを比較して、タッチスクリーン２に表示させてユーザの操作対象とするキャラクタを特定する。図示例（Ｂ）の例では、キャラクタ１３０に代えて、キャラクタ１００を、敵キャラクタ２００と戦闘させるためのキャラクタとして特定したとする。これにより、ユーザ端末１は、図示例（Ｂ）の状態から図示例（Ｃ）の状態に画面を遷移させる。

図示例（Ｃ）に示すように、キャラクタ１３０からキャラクタ１００へとユーザの操作対象のキャラクタが切り替えられる。ユーザ端末１は、例えばキャラクタ１３０を画面外へと移動させるように表示するとともに、キャラクタ１００が画面外から攻撃判定を伴って画面内へと移動させるように表示する。これにより、キャラクタの交代によりタッチスクリーン２に登場するキャラクタ１００が、キャラクタ１３０と交代しつつ敵キャラクタ２００に攻撃する。ユーザ端末１は、ユーザが操作対象とするキャラクタが切り替わったことをユーザに知覚させるためのＵＩ画像２６２を、キャラクタの交代とともに一定時間タッチスクリーン２に表示させる。これにより、ユーザは、ユーザがキャラクタを変更させるための操作を行ったことによらずオートチェンジでキャラクタが変更されたことを認識することが容易となり、変更後のキャラクタの動作に集中することが容易になる。

なお、ユーザがＵＩ画像６４Ａ、６４Ｂに対して操作をすることにより、ユーザの操作に基づいてキャラクタを変更した場合は、ユーザは既にキャラクタが変わることを認識しているため、キャラクタ変更時にＵＩ画像２６２を表示しないこととする一方、オートチェンジによりキャラクタが変更された場合にＵＩ画像２６２を表示することとしてもよい。

図２７は、オートチェンジ適用モードにおいて、パーティ編成されるキャラクタのうち、敵キャラクタと戦闘するキャラクタを特定し、特定した結果に応じてキャラクタをタッチスクリーン２に表示させる処理を示すフローチャートである。ユーザ端末１は、プログラムに従って動作することにより、以下の各ステップを実行する。

ステップＳ２７０１において、ユーザ端末１のＣＰＵ３は、キャラクタ１００について発生したイベントが、攻撃動作を発生させるものであることを検出する。例えば、タッチスクリーン２に対してユーザがタップ操作を行った際に、ユーザ端末１が、ユーザの入力操作がタップ操作であると判別し、タップ操作に対応するアクションが攻撃動作（図６の例）であることにより、攻撃動作を発生させるためのイベントをキャラクタ１００について発生させる。

ステップＳ２７０３において、ＣＰＵ３は、キャラクタ１００が攻撃対象としてロックオンしている敵キャラクタのパラメータと、パーティ編成中の各キャラクタの攻撃力、属性などダメージ量に影響を与えるパラメータとを比較して、所定時間あたりのダメージ量が最大となるキャラクタを特定する。

ステップＳ２７０５において、ＣＰＵ３は、ステップＳ２７０３で特定されるキャラクタが、ゲームフィールドにおいて戦闘中のキャラクタ（現にユーザが操作対象として入力操作に応じた動作を行わせているキャラクタ）である場合は当該キャラクタに攻撃動作を行わせる。一方、ＣＰＵ３は、ステップＳ２７０３で特定されるキャラクタが、ゲームフィールドで戦闘中のキャラクタではなくパーティで待機中のキャラクタであれば、戦闘中のキャラクタに代えて、ステップＳ２７０３で特定されるキャラクタをタッチスクリーン２に登場させる演出を行って、ユーザが操作対象とするキャラクタを、ステップＳ２７０３で特定されたキャラクタに切り替える。

以上のように第１の実施形態と第２の実施形態について説明した。第１の実施形態と第２の実施形態とを組み合わせてもよい。

ここで、第１の実施形態の説明において、「ここで、（ｉ）自キャラクタ１００が入力操作に応じたアクションによらず習得し成長させることができるスキルとしては、例えば、ユーザがゲームプレイに伴ってゲーム媒体を獲得することにより、自キャラクタ１００が使用可能となるものを含む。例えば、ユーザのゲームプレイに伴って、様々なアイテム、スキル、キャラクタ、ゲーム中の仮想通貨などを供出するゲーム媒体をゲーム中でユーザが入手したとする。ユーザ端末１は、このゲーム媒体からユーザに付与する対象を抽選により決定する。ユーザ端末１は、ゲーム媒体からユーザに付与する対象がスキルであれば、どのスキルを付与するかを抽選で決定する。ゲームプレイ時に、ゲーム媒体からアイテム等を供出するための所定の条件を満たすことで、ユーザに対し、抽選結果に従った付与対象（アイテム、スキル、キャラクタ、ゲーム中の仮想通貨など）を付与する。ここで、ユーザ端末１は、ユーザが自キャラクタ１００に攻撃動作を行わせて敵キャラクタを攻撃し、敵キャラクタを撃破した等により、ユーザにゲーム媒体を付与することとしてもよい。」と記載した。

第２の実施形態で説明したように、ユーザが操作対象とするキャラクタが複数であり、各キャラについて固有のスキルを有することがある。上記の例において、ユーザのゲームプレイに伴って、新たにキャラクタのスキル、装備アイテム、装備アイテムを生成するための素材アイテムをユーザに付与する場合に、付与する対象範囲を、パーティ編成中のキャラクタに関連するものとしてもよい。

具体的には、ゲーム端末１は、ユーザがパーティ編成をしたうえでゲームフィールドにおいて敵キャラクタと戦闘することによりゲーム媒体を獲得する場合、ゲーム媒体から抽選で付与される対象を、パーティ編成に含まれるキャラクタに関するものに限定したり、パーティ編成に含まれるキャラクタに関連するものが供出される割合を、パーティ編成に含まれないキャラクタに関連するものが供出される割合よりも高めることとしてもよい。ユーザにとっては、パーティ編成に含まれないキャラクタを強化するアイテム、スキル等を獲得しても、現にパーティ編成に含まれるキャラクタの強化にはつながらないが、上記のように構成することにより、ユーザがキャラクタの強化によりゲーム進行が有利になる機会、キャラクタの成長を実感する機会から遠ざけてしまい興趣性を低下させる事態の発生を低減させることができる。例えば、ゲーム媒体から装備アイテム、装備アイテムの素材となる素材アイテムが供出される場合に、パーティ編成に含まれるキャラクタが装備可能なものを優先して供出することとしてもよい。

また、ゲーム媒体からキャラクタを供出する場合は、第１の実施形態で説明したように、既にユーザが獲得しているキャラクタが供出される場合は、当該キャラクタのグレードが更新され、ユーザが獲得していないキャラクタが供出されると、ユーザが新たに操作対象のキャラクタとすることができるため、いずれにとってもユーザにとってはゲームの興趣性を高めることとも考えられる。したがって、ゲーム媒体からキャラクタを供出する場合等においては、パーティ編成にどのキャラクタが含まれているかにかかわらず、予め定められた供出割合に従って、キャラクタを供出することとしてもよい。

（変形例）
上記の第２の実施形態の例の他に、以下のように構成してもよい。すなわち、オートキャラチェンジが有効であったとしても、一定条件のもとでは、ユーザがキャラクタを変更するための入力操作によらないキャラクタ変更を実行しないこととしてもよい。例えば、図２７のステップＳ２７０３において特定されるキャラクタが、敵キャラクタに対してダメージ量を最大化するには適したキャラクタであるとしても、当該キャラクタの体力値が少ない状態である場合などにおいては、当該キャラクタが攻撃を受けて戦闘の続行ができなくなりやすい局面がある。また、スキルポイントが尽きかけているキャラクタであると、スキル発動による強力な攻撃を実行する回数も限られる。

したがって、ステップＳ２７０３において、パーティに編成されるキャラクタの体力値の残存量、スキルポイントの残存量に基づいて、敵キャラクタと戦闘するキャラクタを特定することとしてもよい。例えば、パーティ編成において、敵キャラクタに与えられる所定時間当たりのダメージ量に基づいて、パーティ編成に含まれる各キャラクタを順位付けし、上位のキャラクタから順に、残存体力が一定以上ない場合は次の順位のキャラクタを優先し、残存体力が一定以上ある場合について、当該キャラクタを、ユーザの操作対象のキャラクタとして特定する。

（付記事項１） 以上の実施形態で説明した事項を以下に付記する。
（付記１） 本実施形態によると、ゲームプログラムが提供される。ゲームプログラムは、プロセッサ（３）と、メモリ（４）と、表示部（７）と、ユーザの入力操作を受け付けるための操作部（２）とを備えるコンピュータ（１）において実行されるものである。ゲームプログラムは、プロセッサに、ユーザが操作対象とするゲームキャラクタのキャラクタパラメータを補正する補正内容（図１５の図示例（Ｂ）の項目「パラメータの補正内容」）をゲームキャラクタに適用するための条件（図１５の図示例（Ｂ）の項目「経験値」の、レベルアップに必要な経験値の値）と、当該条件の達成状況を示す比較用パラメータ（図１５の図示例（Ｂ）の項目「経験値」の、項目「経験値獲得条件」に示される条件が満たされることにより増加する値）とを、複数の補正内容それぞれについてメモリに記憶させるステップと、ゲームキャラクタを動作させるために操作部に対してユーザが入力操作を行った結果、ゲームキャラクタについて発生したイベントの内容を特定するステップ（図６、ステップＳ１８０３）と、イベントが発生したことに応答して、当該イベントの内容に関連する補正内容についての比較用パラメータを更新するステップ（ステップＳ１８０５）と、各補正内容について比較用パラメータが条件を達成した場合に、当該条件に対応する補正内容をゲームキャラクタに適用することにより、ゲームプレイが有利になるようにゲームキャラクタのキャラクタパラメータを補正するステップ（ステップＳ１８０７）とを実行させる。

（付記２） （付記１）において、複数の補正内容のうち、ゲームキャラクタに適合させられる補正内容の範囲が設定されており（図１７の図示例（Ａ）に示す第１のスキル群９１２、第２のスキル群９１３）、プロセッサに、さらに、ユーザのゲームプレイに伴い、予め定められた拡張条件を満たすことにより（例えば、グレード「１」のキャラクタを操作可能な状態で、当該キャラクタがゲーム媒体から供出されると、ユーザ端末１は、当該キャラクタのグレードをグレード「１」からグレード「２」に更新し、当該キャラクタが獲得可能なスキルの範囲を拡大する）、ゲームキャラクタに適合させられる補正内容の範囲を拡張するよう再設定するステップを実行させる。

（付記３） （付記２）において、プロセッサに、さらに、ユーザのゲームプレイに伴い、ユーザに、ゲームプレイ時に使用可能なオブジェクトをユーザが獲得する権利を表すゲーム媒体を付与するステップを実行させ、拡張条件には、ゲーム媒体からオブジェクトを獲得するための入力操作をユーザから受け付けることにより、ゲーム媒体から所定のオブジェクトがユーザに付与されることを含む（例えば、グレード「１」のキャラクタを操作可能な状態で、当該キャラクタがゲーム媒体から供出されると、ユーザ端末１は、当該キャラクタのグレードをグレード「１」からグレード「２」に更新し、当該キャラクタが獲得可能なスキルの範囲を拡大する）。

（付記４） （付記１）から（付記３）のいずれかにおいて、複数の補正内容の少なくともいずれかは、ゲームキャラクタが他のゲームキャラクタに作用を及ぼすためのキャラクタパラメータを補正するものを含む（図１５の図示例（Ｂ）において、項目「スキル名」の「クリティカル率アップ」、「武器種習熟」に対応する項目「パラメータ補正の内容」など）。

（付記５） （付記４）において、複数の補正内容の少なくともいずれかは、ゲームキャラクタが他のゲームキャラクタに作用を及ぼすための入力操作に応じて、ゲームキャラクタに連続して攻撃動作をすることができる回数を増加させるものを含む（図１５の図示例（Ｂ）において、項目「スキル名」の「武器種習熟」に対応する項目「パラメータの補正内容」における「最大コンボ数＋２」など）。

（付記６） （付記１）から（付記５）のいずれかにおいて、複数の補正内容の少なくともいずれかは、ゲームキャラクタが他のゲームキャラクタから作用を及ぼされた場合に減少するキャラクタパラメータに関するものを含む（図１５の図示例（Ｂ）において、項目「スキル名」の「ガード時ダメージ低減」に対応する項目「パラメータ補正の内容」など）。

（付記７） （付記１）から（付記６）のいずれかにおいて、特定するステップにおいて、発生するイベントは、ユーザの入力操作によりゲームキャラクタにアクションを行わせることを含み、イベントの内容を特定することは、ゲームキャラクタに行わせるアクションの内容を特定することを含む（ステップＳ１８０３、図６、図１５の図示例（Ｂ）の項目「経験値獲得条件」における「攻撃により他のキャラクタにダメージを与える」など）。

（付記８） （付記１）から（付記７）のいずれかにおいて、特定するステップにおいて、発生するイベントは、ゲームキャラクタが他のオブジェクトから作用を受けることによりゲームキャラクタに発生するものを含む（ステップＳ１８０３、図６、図１５の図示例（Ｂ）の項目「経験値獲得条件」における「キャラクタがダメージを受ける」など）。

（付記９） （付記１）から（付記８）のいずれかにおいて、各補正内容について比較用パラメータが条件を達成した場合に、条件を達成した補正内容があることを示す通知を表示部により行うステップをさらに実行させる（図１６のＵＩ部品９０１）。

（付記１０） （付記９）において、表示部に、ゲームキャラクタに適用可能な補正内容の一覧と、ゲームキャラクタに適用されている補正内容の一覧とを含む一覧画面（図１７）に遷移させるインターフェース画像（図１６のＵＩ部品９００）を表示させるステップと、インターフェース画像に対するユーザの入力操作に応答して、一覧画面を表示部に表示させるステップとをさらに実行させ、一覧画面を表示させるステップにおいて、条件を達成したことをユーザが未確認の補正内容と（ＵＩ部品９１５）、確認済みの補正内容とをユーザが区別可能な態様で、一覧画面を表示部に表示させる。

［実施の形態３］
次に、上記の実施形態の構成において、各キャラクタが、ジョブ（職業）という属性と関連付けられる態様について説明する。本実施形態では、抽選処理により、各キャラクタのジョブが供出される。キャラクタにジョブを設定すると（例えば、キャラクタ「ＸＸＸ」を、属性「なし」（特にジョブの設定なし）から、属性「魔法剣士」などとすることができる。このとき、キャラクタ「ＸＸＸ」がもともと装備できなかった装備品についても、ジョブに関連する装備品については装備可能となる。例えば、キャラクタ「ＸＸＸ」が、もともと武器「槍」を装備可能であるがその他の種類の武器が装備できないときであっても、ジョブ「魔法剣士」になった場合に、武器「剣」を装備できるようになる。これにより、ジョブのスキルのみならず、装備可能な武器についても多様化することができる。

図２８は、抽選処理により供出されるゲーム媒体を示すテーブルである。図２８に示すように、テーブルには、供出対象物となるゲーム媒体の名称と、ゲーム媒体の種類名と、ゲーム媒体のレアリティと、ゲーム媒体の供出確率とが対応付けられている。図２８の例で示すように、ゲームプログラムは、供出対象物として、各キャラクタの属性である「ジョブ」と、各キャラクタが装備可能な「装備アイテム」（武器および防具など）とを供出する。例えば、キャラ「ＸＸＸ」についてのジョブ「魔法剣士」が供出され、当該ゲーム媒体の希少度は「４」と設定される。ユーザの端末またはサーバにおいて、図２８に示すテーブルを保持する。

図２９は、抽選処理において、ユーザの端末のディスプレイ２に表示される画面例を示す。図２９の例（Ａ）は、抽選を開始するための入力操作をユーザから受け付けるための画面例である。図２９の例（Ｂ）は、抽選処理を実行した結果を表示する画面例である。

例（Ａ）に示すように、ユーザの端末のタッチスクリーン２に、抽選処理を開始するためのアイコン（アイコン２９０３、２９０４、２９０５、２９０６）と、抽選処理により供出されるゲーム媒体の一例をユーザに提示するための画像表示部２９０１および２９０２とを表示させる。ゲームプログラムは、画像表示部２９０１において、例えば、抽選によりキャラクタのジョブを供出する場合に、ジョブに関連するキャラクタの名称、画像等を表示する。ゲームプログラムは、画像表示部２９０２において、抽選によりキャラクタのジョブを供出する場合に、例えば、（ｉ）ジョブの名称、（ｉｉ）そのジョブで使用できる装備の種類、（ｉｉｉ）そのジョブで使用することができる特殊なキャラクタ動作（スペシャルスキル）を表示する。

アイコン２９０３は、仮想通貨を使用して、抽選処理を１回実行するための操作を受け付けるためのものである。アイコン２９０５は、仮想通貨とは異なるアイテムを消費することで、抽選処理を１回実行するための操作を受け付けるためのものである。

アイコン２９０４は、仮想通貨を使用して、抽選処理を複数回実行するための操作を受け付けるためのものである。例えば、仮想通貨を使用して１回の抽選を実行する場合と比べて、一定倍数（例えば、１０回）の抽選処理を実行することができる。

アイコン２９０５は、仮想通貨とは異なるアイテムを消費することで、抽選処理を複数回実行するための操作を受け付けるためのものである。

例（Ｂ）に示すように、ゲームプログラムは、ユーザの端末のタッチスクリーン２に、抽選処理の結果（供出されたゲーム媒体２９１０－１～２９１０－１１）を表示する。例（Ｂ）では、アイコン２９０４への操作に応答して、１１階の抽選処理を実行した結果が表示されている。

例（Ｂ）では、キャラクタ「ＸＸＸ」のジョブが、抽選処理によりユーザに付与されている（ゲーム媒体２９１０－１）。また、過去にユーザが獲得したキャラクタのジョブが、今回の抽選処理によってユーザに付与される場合に、当該ジョブに代えて、どのキャラクタのジョブを強化するのにも使用可能なアイテムであるジョブ強化アイテムがユーザに付与されたことを、ゲーム媒体２９１０－６により示している。アイコン２９０７への操作を受け付けた場合、ゲームプログラムは、抽選処理を実行する。

図３０は、キャラクタのジョブに関連付けられたスキルを表示するための画面例である。

図３０に示すように、各キャラクタには、ユーザに付与された各キャラクタのジョブを設定することができる。タッチスクリーン２は、あるキャラクタのジョブ「魔法剣士」が発動可能なスキルの一覧を表示している。タッチスクリーン２において、ジョブ「魔法剣士」についてのグレード１のスペシャルスキルを、スキル表示領域３０１２に示す。タッチスクリーン２において、ジョブ「魔法剣士」についてのグレード２のスペシャルスキルを、スキル表示領域３０１３に示す。

上記の実施形態では、各キャラクタのスタンダードスキル、スペシャルスキルは、各キャラクタにアクションを行わせることで習得されると説明した。ここで、各キャラクタにジョブを設定している場合に、ジョブに特有のスペシャルスキル（アクションを行わせるもの）を習得可能としているが、このジョブに特有のスペシャルスキルを獲得するには、抽選処理によりキャラクタのジョブが重複した場合にユーザに供出されるジョブ強化アイテムを使用する。どのキャラクタのジョブが重複しようとも、共通のジョブ強化アイテムをユーザに付与する。ユーザの端末は、ユーザから、ジョブ強化アイテムを消費するための操作を受け付けて、ユーザが獲得済みのキャラクタのジョブについてのグレードを成長させることができる（例えば、ジョブ強化アイテムを消費して、ジョブ「魔法剣士」のグレードを、グレード「１」からグレード「２」に成長させることができる）

図３１は、本実施形態に示すフローチャートである。図３１に示す処理は、例えば、ユーザの端末またはサーバのいずれかで実行されるか、または、ユーザの端末において抽選を実行する処理を受けてサーバで抽選処理を実行し、サーバでの抽選処理の結果をユーザの端末で表示する。

ステップＳ３１０１において、ユーザの端末は、タッチスクリーン２により、ユーザから、抽選開始の操作を受け付ける。

ステップＳ３１０３において、ユーザの端末は、図２８に示すテーブルを参照して、抽選により供出するゲーム媒体を特定する。ユーザの端末は、供出対象物としてキャラクタの属性を供出すると特定した場合に、既にユーザが獲得しているキャラクタのジョブと重複する場合は、ジョブを強化するためのアイテムをユーザに付与すると決定する。

ステップＳ３１０５において、ユーザの端末は、抽選処理の結果、ユーザに付与されるゲーム媒体を表示する。

以上のように説明したが、本実施形態のゲームプログラムによると、コンピュータに、ユーザが操作対象となる１以上のキャラクタについて、キャラクタに関連付けることが可能な属性（ジョブ）を示す情報をメモリに記憶させる。ゲームプログラムは、コンピュータに、キャラクタの属性（ジョブ）を供出対象とする抽選処理を行わせる。ゲームプログラムは、コンピュータに、抽選処理の結果、既にキャラクタに関連付けることが可能な属性（ジョブ）が供出されることにより（ジョブが重複することにより）、属性（ジョブ）に関連するパラメータを更新するための処理を行う（例えば、ジョブ強化アイテムをユーザに付与する）。

ゲームプログラムは、コンピュータのプロセッサに、さらに、操作部（タッチスクリーン２）に対するユーザの入力操作に応答して、キャラクタを動作させるステップと、キャラクタを動作させたことに基づいて、キャラクタの性能を示す第１のパラメータ（上記実施形態のＨＰ、ＳＰなど）を更新するステップとを実行させる。ゲームプログラムは、キャラクタを動作させたことにより第１のパラメータが更新される（ＨＰが増加する、スキルが発現する）一方、キャラクタを動作させた履歴によらず属性（ジョブ）に関連するパラメータを更新するための処理を行う（例えば、ジョブ強化アイテムをユーザに付与する）。

ゲームプログラムは、コンピュータのプロセッサに、さらに、キャラクタに関連付けることが可能な属性（ジョブ）のうちからいずれかを指定するためのユーザの入力操作に応答して（キャラクタに設定するジョブをいずれにするかのユーザの操作を受け付けて）、当該キャラクタを、ユーザにより指定された属性（ジョブ）に変更するステップを実行させる。ゲームプログラムは、属性（ジョブ）の指定によりキャラクタの属性（ジョブ）が変更される場合に、いずれの属性（ジョブ）においても第１のパラメータ（ＨＰ、ＳＰなど）を適用する。

ゲームプログラムは、既にキャラクタに関連付けることが可能な属性（ジョブ）が抽選処理により供出されたことに応答して、第１のアイテム（ジョブ強化アイテム）をユーザに付与するステップと、第１のアイテム（ジョブ強化アイテム）を消費することにより、１以上のキャラクタについて関連付けることが可能な属性（ジョブ）に関連するパラメータを更新する（ジョブのグレードを成長させ、ジョブに応じて獲得できるスペシャルスキルの幅を広げる）ステップとを含む。

ゲームプログラムは、既にキャラクタに関連付けることが可能な属性（ジョブ）が抽選処理により供出されたことに応答して、キャラクタの属性（ジョブ）に関連するパラメータを更新する（ジョブのグレードを成長させるなど）。
このように構成すると、よりユーザのゲームプレイの展開が多様になる。

上記の実施形態は、本発明の理解を容易にするための例示に過ぎず、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良することができると共に、本発明にはその均等物が含まれることは言うまでもない。

１：ユーザ端末、２：タッチスクリーン、３：ＣＰＵ、４：主記憶、５：補助記憶、６：送受信部、７：表示部、８：入力部、１０：タッチセンシング部、２０：表示部、３０：制御部、３２：入力操作受付部、３４：キャラクタ操作検出部、３６：オブジェクト制御部、３８：表示制御部、４０：操作オブジェクト、４２：基部、４４：先端部、４６：接続部、５３：バッファメモリ、５５：初期タッチ位置座標、６０：動作テーブル、８０：せ操作オブジェクト制御プログラムモジュール、８２：入力操作受付プログラムモジュール、８４：操作オブジェクト描画プログラムモジュール、９０：キャラクタ制御プログラムモジュール、１００：自キャラクタ（プレイヤキャラクタ、キャラクタオブジェクトの一例）、２００：相手キャラクタ

Claims (6)

1. コンピュータを、
   操作対象となる１以上のキャラクタについて、前記キャラクタに関連付けることが可能な属性を供出対象とする抽選処理を行う抽選手段と、
   前記抽選処理の結果に応じて供出された属性を示す情報を記憶させる記憶手段と、
   既に行われた前記抽選処理の結果に応じて供出されたことにより既に前記キャラクタに関連付けることが可能となっている属性が、新たに行われた前記抽選処理の結果に応じて再び供出されることにより、当該属性がいずれのキャラクタの属性であるかにかかわらず、共通の第１のオブジェクトをユーザに付与する付与手段と、
   前記第１のオブジェクトを消費することにより、前記属性自体に関連するパラメータを成長させるように更新するための処理を行う更新手段と、して機能させる、プログラム。
2. 既に行われた前記抽選処理の結果に応じて供出されたことにより既に前記キャラクタに関連付けることが可能となっている属性が、新たに行われた前記抽選処理の結果に応じて再び供出された際、前記属性を付与せず、前記付与手段が前記第１のオブジェクトをユーザに付与する、請求項１に記載のプログラム。
3. コンピュータを、
   操作部に対するユーザの入力操作に応答して、前記キャラクタを動作させる動作手段と、
   前記キャラクタを動作させたことに基づいて、前記キャラクタの性能を示す第１のパラメータを更新する性能更新手段と、して機能させ、
   前記キャラクタを動作させたことにより蓄積される履歴に応じて前記第１のパラメータが更新される一方、前記属性自体に関連するパラメータについては前記キャラクタを動作させたことにより蓄積される履歴によるものではなく前記第１のオブジェクトを消費することにより更新するための処理を前記更新手段が行う、請求項１または請求項２に記載のプログラム。
4. コンピュータを、
   前記キャラクタに関連付けることが可能な属性のうちからいずれかを指定するための前記ユーザの入力操作に応答して、当該キャラクタを、前記指定された属性に変更する変更手段と、して機能させ、
   前記性能更新手段において、前記属性の指定により前記キャラクタの前記属性が変更される際に、いずれの前記属性に変更されたときであっても、当該キャラクタを動作させたことに基づいて更新させた当該キャラクタの性能を示す前記第１のパラメータは更新されない、請求項３に記載のプログラム。
5. 前記属性自体に関連するパラメータは、前記キャラクタの性能を示す第１のパラメータについて上昇可能な範囲を特定するための情報であり、
   前記成長させるように更新するための処理は、当該処理を実行するときの前記上昇可能な範囲よりも広い範囲を特定する情報となるように、前記属性自体に関連するパラメータを更新する処理である、請求項１から４のいずれか１項に記載のプログラム。
6. 前記第１のオブジェクトは、消費することにより、いずれのキャラクタの属性自体に関連するパラメータであっても、成長させるように更新可能なオブジェクトである、請求項１から５のいずれか１項に記載のプログラム。

Images