特許 5740541 ゲーム制御方法、ゲーム提供装置及びゲーム制御プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5740541

(24)【登録日】2015年5月1日

(45)【発行日】2015年6月24日

(54)【発明の名称】ゲーム制御方法、ゲーム提供装置及びゲーム制御プログラム

(51)【国際特許分類】

   A63F 13/358 20140101AFI20150604BHJP

   A63F 13/47 20140101ALI20150604BHJP

   A63F 13/537 20140101ALI20150604BHJP

   A63F 13/69 20140101ALI20150604BHJP

【ＦＩ】

   A63F13/358

   A63F13/47

   A63F13/537

   A63F13/69 500

【請求項の数】7

【全頁数】31

(21)【出願番号】特願2015-14645(P2015-14645)

(22)【出願日】2015年1月28日

(62)【分割の表示】特願2014-140638(P2014-140638)の分割

【原出願日】2013年5月29日

(65)【公開番号】特開2015-97812(P2015-97812A)

(43)【公開日】2015年5月28日

【審査請求日】2015年1月28日

【早期審査対象出願】

(73)【特許権者】

【識別番号】504437801

【氏名又は名称】グリー株式会社

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100153051

【弁理士】

【氏名又は名称】河野 直樹

(74)【代理人】

【識別番号】100140176

【弁理士】

【氏名又は名称】砂川 克

(74)【代理人】

【識別番号】100179062

【弁理士】

【氏名又は名称】井上 正

(74)【代理人】

【識別番号】100124394

【弁理士】

【氏名又は名称】佐藤 立志

(74)【代理人】

【識別番号】100112807

【弁理士】

【氏名又は名称】岡田 貴志

(74)【代理人】

【識別番号】100111073

【弁理士】

【氏名又は名称】堀内 美保子

(72)【発明者】

【氏名】佐野 孝行

【審査官】 谷山 稔男

(56)【参考文献】

【文献】 特許第５１３２８２５（ＪＰ，Ｂ１）

【文献】 特許第５６８９５５４（ＪＰ，Ｂ２）

【文献】 特開平０６−３２７８３５（ＪＰ，Ａ）

【文献】 特開２０１２−１４３５０９（ＪＰ，Ａ）

【文献】 特開２０１０−０４２０９０（ＪＰ，Ａ）

【文献】 特開２００７−２１５７９５（ＪＰ，Ａ）

【文献】 特開２００４−２６６５７５（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ａ６３Ｆ １３／００−１３／９８

Ａ６３Ｆ ９／２４

(57)【特許請求の範囲】

【請求項1】

ゲームに用いる背景画面を含む行程再生時と行程変更時に用いる画像データ及び行程データを記憶した記憶手段及び前記記憶手段にアクセス可能な処理装置を備え、携帯端末に前記ゲームを提供可能なゲーム提供装置に用いられるゲーム制御方法であって、
前記処理装置が、前記ゲームを開始前に前記携帯端末から送信リクエストを受信した場合、前記画像データと、前記ゲーム内の第一の行程を示し前記背景画面上でゲーム媒体をユーザの操作なしに動かして前記ゲームを進行するための第一の行程データとを含む第一のレスポンスを前記携帯端末に送信する第一の送信工程と、
前記第一の行程データを再生中に、前記第一の行程データを変更するための変更リクエストを当該携帯端末から受信した場合、前記ゲーム内の第二の行程を示し前記背景画面上で前記ゲーム媒体を前記ユーザの操作なしに動かして前記ゲームを進行するための第二の行程データを含む第二のレスポンスを前記携帯端末に送信する第二の送信工程と、
を備え、
前記記憶手段は、ゲーム媒体ＩＤ毎に、前記ゲーム内の各々の行程の間隔の実行速度を示すスピード属性を関連付けて記述した管理情報を記憶しており、
前記第一の行程データ及び前記第二の行程データは、前記背景画面を遷移するための画面遷移情報を含まないデータであり、前記管理情報に基づいて、前記各々の行程の間隔の実行速度が規定されていることを特徴とするゲーム制御方法。

【請求項2】

請求項１に記載のゲーム制御方法において、
前記第一の行程データ及び前記第二の行程データは、前記ゲーム内の行程を示すステップ番号毎に順次、前記ゲーム内の行程を再生することにより、前記ゲームを進行するためのデータであることを特徴とするゲーム制御方法。

【請求項3】

請求項１又は請求項２に記載のゲーム制御方法において、
前記ゲーム内の行程のうち、最終の行程である最終ステップは、開始時のステップ又は途中のステップに戻るステップであることを特徴とするゲーム制御方法。

【請求項4】

請求項１乃至請求項３のいずれか１項に記載のゲーム制御方法において、
前記第一の行程データ内のパラメータは少なくともダメージの値を含むことを特徴とするゲーム制御方法。

【請求項5】

ゲームを携帯端末に提供可能なゲーム提供装置であって、
前記ゲームに用いる背景画面を含む行程再生時と行程変更時に用いる画像データ及び行程データを記憶した記憶手段と、
前記ゲームを開始前に前記携帯端末から送信リクエストを受信した場合、前記画像データと、前記ゲーム内の第一の行程を示し前記背景画面上でゲーム媒体をユーザの操作なしに動かして前記ゲームを進行するための第一の行程データとを含む第一のレスポンスを前記携帯端末に送信する第一の送信手段と、
前記第一の行程データを再生中に、前記第一の行程データを変更するための変更リクエストを当該携帯端末から受信した場合、前記ゲーム内の第二の行程を示し前記背景画面上で前記ゲーム媒体を前記ユーザの操作なしに動かして前記ゲームを進行するための第二の行程データを含む第二のレスポンスを前記携帯端末に送信する第二の送信手段と、
を備え、
前記記憶手段は、ゲーム媒体ＩＤ毎に、前記ゲーム内の各々の行程の間隔の実行速度を示すスピード属性を関連付けて記述した管理情報を記憶しており、
前記第一の行程データ及び前記第二の行程データは、前記背景画面を遷移するための画面遷移情報を含まないデータであり、前記管理情報に基づいて、前記各々の行程の間隔の実行速度が規定されていることを特徴とするゲーム提供装置。

【請求項6】

ゲームに用いる背景画面を含む行程再生時と行程変更時に用いる画像データ及び行程データを記憶した記憶手段を備え、携帯端末に前記ゲームを提供可能なゲーム提供装置に用いられるゲーム制御プログラムであって、
前記ゲーム提供装置を、
前記ゲームを開始前に前記携帯端末から送信リクエストを受信した場合、前記画像データと、前記ゲーム内の第一の行程を示し前記背景画面上でゲーム媒体をユーザの操作なしに動かして前記ゲームを進行するための第一の行程データとを含む第一のレスポンスを前記携帯端末に送信する第一の送信手段、
前記第一の行程データを再生中に、前記第一の行程データを変更するための変更リクエストを当該携帯端末から受信した場合、前記ゲーム内の第二の行程を示し前記背景画面上で前記ゲーム媒体を前記ユーザの操作なしに動かして前記ゲームを進行するための第二の行程データを含む第二のレスポンスを前記携帯端末に送信する第二の送信手段、
として機能させ、
前記記憶手段は、ゲーム媒体ＩＤ毎に、前記ゲーム内の各々の行程の間隔の実行速度を示すスピード属性を関連付けて記述した管理情報を記憶しており、
前記第一の行程データ及び前記第二の行程データは、前記背景画面を遷移するための画面遷移情報を含まないデータであり、前記管理情報に基づいて、前記各々の行程の間隔の実行速度が規定されているゲーム制御プログラム。

【請求項7】

ゲームに用いる背景画面を含む行程再生時と行程変更時に用いる画像データ及び行程データを記憶した記憶手段及び前記記憶手段にアクセス可能な処理装置を備える携帯端末に用いられるゲーム制御方法であって、
前記処理装置が、前記画像データと、前記ゲーム内の第一の行程を示し前記背景画面上でゲーム媒体をユーザの操作なしに動かして前記ゲームを進行するための第一の行程データとを再生する第一の再生工程と、
前記第一の行程データを再生中に、ユーザの操作により、前記第一の行程データを変更するための変更リクエストの入力を受け付けると、前記ゲーム内の第二の行程を示し前記背景画面上で前記ゲーム媒体を前記ユーザの操作なしに動かして前記ゲームを進行するための第二の行程データを再生する第二の再生工程と、
を備え、
前記記憶手段は、ゲーム媒体ＩＤ毎に、前記ゲーム内の各々の行程の間隔の実行速度を示すスピード属性を関連付けて記述した管理情報を記憶しており、
前記第一の行程データ及び前記第二の行程データは、前記背景画面を遷移するための画面遷移情報を含まないデータであり、前記管理情報に基づいて、前記各々の行程の間隔の実行速度が規定されていることを特徴とするゲーム制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ゲーム制御方法、ゲーム提供装置及びゲーム制御プログラムに関する。

【背景技術】

【0002】

従来の通信方式であるリクエスト・レスポンス方式では、例えば、キャラクタの動作を含むゲームを行う場合、クライアント側がキャラクタの１歩（又は数歩）毎にサーバ側からデータをロードする。このような従来の通信方式では、通信トラフィック（通信量）を圧迫するため、例えば、キャラクタを動かすためのゲームオブジェクト画像のような高画質の画像データをクライアント側に提供することができない。

【0003】

これに対し、従来の通信方式を採用して高画質の画像データを提供するためには、例えば、サーバ側での処理の一部をクライアント側に分担させる必要がある。すなわち、現状のソーシャルゲームでは、サーバ・クライアント間の通信回数を極力減らすために、バトルの開始からバトル終了までの低画質の画像データを一度にクライアント側に送信している。クライアント側では、送信された画像データを処理して高画質の画像データを作成している。

【0004】

なお、この出願の発明に関連する先行技術文献情報としては特許文献１がある。特許文献１記載の技術では、クライアント側（端末装置側）で生成していた画面遷移情報を、クライアント側からのリクエストの都度にサーバ側で生成して端末装置に送信している。これにより、特許文献１記載の技術では、通信量の少ないアプリタイプを基本としつつ、ブラウザタイプに近いダイナミックな画面情報の生成処理を行わせることができる。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特許第５１３２８２５号公報（第０００８−０００９段落及び第００１２段落）

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかしながら、現状のソーシャルゲーム及び特許文献１記載の技術は、通常は特に問題ないが、本発明者の検討によれば、以下の点で改善の余地がある。

【0007】

すなわち、現状のソーシャルゲームは、クライアント側に高画質の画像データを作成する負荷がかかる点で改善の余地がある。

【0008】

また、特許文献１記載の技術は、より一層、通信量を低減させる観点から、改善の余地がある。

【0009】

本発明は上記実情を考慮してなされたもので、リクエスト・レスポンス方式を用いて高画質の画像データをクライアント側に提供でき、クライアント側で高画質の画像データを作成する負荷が無く、より一層、通信量を低減し得るゲーム制御方法、ゲーム提供装置及びゲーム制御プログラムを提供することを目的とする。

【課題を解決するための手段】

【0010】

本発明の一つの局面は、ゲームに用いる画像データを記憶した記憶手段及び前記記憶手段にアクセス可能な処理装置を備え、携帯端末にゲームを提供可能なゲーム提供装置に用いられるゲーム制御方法であって、前記処理装置が、前記携帯端末から送信リクエストを受信した場合、前記画像データと、前記ゲーム内の行程を示す第一の行程データとを前記携帯端末に送信する第一の送信工程と、前記画像データ及び前記行程データに基づいて各々の行程を再生中に、前記行程データを変更するための変更リクエストを当該携帯端末から受信した場合、第二の行程データを含む変更レスポンスを前記携帯端末に送信する第二の送信工程と、を備えたゲーム制御方法である。

【発明の効果】

【0011】

以上説明したように本発明によれば、リクエスト・レスポンス方式を用いて高画質の画像データをクライアント側に提供でき、クライアント側で高画質の画像データを作成する負荷が無く、より一層、通信量を低減させることができる。

【図面の簡単な説明】

【0012】

【図1】本発明の概要を説明するための模式図である。

【図2】本発明の概要におけるフレンドユーザ情報の一例を示す模式図である。

【図3】本発明の概要における最終カード情報の一例を示す模式図である。

【図4】本発明の概要におけるゲーム画面の一例を示す模式図である。

【図5】本発明の概要における種族カードの情報の一例を示す模式図である。

【図6】本発明の概要における味方キャラクタの情報の一例を示す模式図である。

【図7】本発明の概要における敵キャラクタの情報の一例を示す模式図である。

【図8】本発明の概要における行程データの作成に用いる条件の一例を示す模式図である。

【図9】本発明の概要における行程データの一例を示す模式図である。

【図10】本発明の第１の実施形態に係るゲーム制御方法が適用されたゲームシステム及びその周辺構成の一例を示す模式図である。

【図11】同実施形態におけるゲーム提供装置の機能ブロック構成の一例を示す模式図である。

【図12】同実施形態における携帯端末の機能ブロック構成の一例を示す模式図である。

【図13】同実施形態における準備段階の動作を説明するためのフローチャートである。

【図14】同実施形態におけるゲーム段階の動作を説明するためのシーケンス図である。

【図15】本発明の第２の実施形態における種族カードの情報の一例を示す模式図である。

【図16】本発明の第３の実施形態における味方キャラクタの情報の一例を示す模式図である。

【発明を実施するための形態】

【0013】

以下、本発明の各実施形態について図面を用いて説明するが、その前に、本発明の概要について図１を用いて述べる。なお、以下に述べる概要は、「スキル」や「行程」等といった具体的な用語を用いているが、本発明は概要の説明に限定されない。例えば、「スキル」は「必殺技」を意味し、「スキル発動」は「必殺技の使用（による行程変更）」を意味しているが、「必殺技の使用」の意味に限らず、「行程変更」をもたらすのであれば、ゲーム内容に適した他の用語に読み替えてもよい（「必殺技」は対戦ゲーム以外のゲームでは不適切になる。）。また、「行程」は、「シナリオ」、「ストーリー」又は「ゲームフロー」などに読み替えてもよい。

【0014】

本発明の概要は、クライアント側が所定の各々の行程を示す行程データ（シナリオデータ）に基づいて各々の行程を再生するゲームであって、ユーザの操作により、サーバ側と通信して当該行程データを他の行程データに変更可能となっている。ここで、ユーザの操作としては、タッチパネルの操作を想定しているが、これに限定されない。ゲームとしては、行程データに基づいて行程が再生されるゲームであれば、対戦ゲームに限らず、任意のゲームに適用可能である。ゲーム内のキャラクタ、アイテム又はカードの有無は、それぞれ任意である。但し、以下では、理解を助けるために、各キャラクタによる対戦ゲームを例に挙げて述べる。

【0015】

このゲームでは、従来のリクエスト・レスポンス方式により、行程再生時と行程変更時に用いる全ての画像データと、味方キャラクタと敵キャラクタとが対戦する各々の行程を示す行程データとを含むゲームプログラムの送信リクエストを予めクライアント側からサーバ側に送信する。サーバ側では、当該ゲームプログラムを含むレスポンスをクライアント側に送信する。クライアント側は、従来のリクエスト・レスポンス方式により、ゲーム開始前に全ての画像データ（高画質の画像データ）を取得するので、従来の低画質の画像データを処理して高画質の画像データを作成するといった負荷がかからない。

【0016】

クライアント側では、ゲームプログラムを実行し、行程データに基づいて、各画像データを用いて行程を再生するので、対戦を遅延なく描画できる。また、行程データは、所定の背景画面上で各キャラクタを動かしてゲームを進行するためのデータであり、従来とは異なり、他の背景画面を描画するための画像データなどを含む画面遷移情報を含まなくてもよい。すなわち、このゲームは、行程再生時に画面遷移をしない場合、背景画面のデータ量が小さくて済むため、より一層、通信量を低減させることができる。但し、画面遷移を完全に無くす必要はない。例えば、背景画面のデータ量を小さくしたい度合に応じて、低い確率で画面遷移を行うようにしてもよい。

【0017】

各キャラクタは、ユーザの操作なしに動くものであり、行程データに基づいて、対戦相手を攻撃してダメージを与え、また、対戦相手から攻撃されてダメージを受ける。ゲームは、ユーザ操作による行程データの変更がなければ再生している行程データに基づいて対戦を描写し続け、クエスト終了時に止まる。このゲームは、行程データの変更以外ではユーザ操作が不要なので、高速な操作に不慣れなユーザや、頻繁な操作が面倒なユーザでもプレイし易い利点がある。また、このゲームは、ユーザ操作毎にサーバ側と通信する従来のゲームに比べ、通信量が少ないため、通信によるゲーム進行の遅延を招くおそれが少なくなり、ユーザのストレスを軽減させることができる。また、このゲームは、サーバ側で行程データを作成するため、クライアント側による行程データの改ざんを阻止することができる。

【0018】

以上のようなゲームでは、例えば図１に示すように、クエスト開始当初の行程データにより行程を再生した場合、スキルの発動（による行程データの変更）が無ければ、クエスト終了時に当初の結果（例、敵の得点、味方の得点）が得られる。なお、行程データは、１回の再生によりクエスト終了までの全行程を示すデータ（長いデータ）でもよいが、繰り返し再生によりクエスト終了までの全行程を示すデータ（短いデータ）とした方が、レスポンス時の通信量を低減する観点から好ましい。また、図１に示す準備段階のうち、「デッキを構築」及び「クエストを選択」の処理は、任意の付加的事項であり、省略可能となっている。

【0019】

また、クライアント側では、再生している行程データでは対戦に負けるとユーザが判断した場合に、任意のタイミングでユーザ操作によりスキルを発動させ、スキル演出画面の表示中に、新たな行程データの送信リクエストをサーバ側に送信する。

【0020】

サーバ側では、新たな行程データの送信リクエストを受けると、新たな行程データを含むレスポンスをクライアント側に送信する。

【0021】

クライアント側では、レスポンスを受けると、スキル演出画面の表示に代えて、新たな行程データにより新しい行程を再生するので、クエスト終了時に新しい結果（例、敵の得点、味方の得点）を得ることができる。新しい結果の例として、敵・味方の得点を示したが、これに限らず、例えば、生存したキャラクタの数、各キャラクタのＨＰ（体力値）を用いてもよい。すなわち、新たな行程データによる新しい結果とは、勝敗に関連する状況を意味するが、勝敗そのものを意味しない（新しい結果が勝敗そのものを意味する場合には、対戦で負けると判断した場合に１回だけ行程データを変更すれば、必ず勝つことになり、興趣性に乏しいため。）。

【0022】

このゲームは、単調な攻撃指示等を行うことなく、ゲームのシナリオを変更する操作のみを行うため、限られた操作でゲーム進行をコントロールする興趣性をユーザに感じさせることができる。

【0023】

上述したゲームは、以下の例のような任意の付加的要素（ａ）〜（ｉ）により、興趣性を向上させてもよい。但し、任意の付加的要素は、以下に列挙したものに限定されない。

【0024】

（ａ）ゲーム開始前にダウンロードされた行程データとは別の行程データを選択可能にするため、クエストの途中で分岐点（例：スキルを発動可能な分岐点）を設ける。但し、分岐点を設けずに、他の行程データを選択可能な条件（例、攻撃した回数、経過時間）、他の行程データの選択指示を入力するためのゲーム媒体又は選択ボタンなどを明示するようにしてもよい。

【0025】

（ｂ）キャラクタを動かすための行程データをサーバ側から受信し、クライアント側で描画する。但し、行程データとしては、キャラクタに限らず、所望のゲーム媒体を動かすように変形可能である。

【0026】

（ｃ）スキル発動時に、スキル演出画面を表示する。但し、スキル発動時には、必殺技を演出して示すスキル演出画面に限らず、ユーザを待たせないための任意のローディング画面を表示して構わない。スキル演出画面としては、選択したカードの種族名又は属性名に応じて、異なる画像データを用いてもよい。

【0027】

（ｄ）複数のカードでデッキ（攻撃をするためのグループ）を構成するとしてもよい。この場合、予め味方キャラクタを種族ごとに分類しておき、当該デッキに投入されている各種族カードの枚数に応じて、味方キャラクタの攻撃内容が変化するようにしてもよい。また、カードのデッキは、ユーザが全てのカードを選択して作成してもよい。あるいは、カードのデッキは、ユーザが１以上の数枚のカードを選択し、１以上の残り枚数のカードをユーザのフレンドの情報に基いて選択し、各々の選択したカードに基づいて作成してもよい。当該フレンドの情報としては、例えば、ユーザＩＤ及びフレンドのユーザＩＤを互いに関連付けたフレンドユーザ情報（図２参照）と、ユーザＩＤ及び最終プレイ時のリーダカードＩＤを互いに関連付けた最終カード情報（図３参照）とが使用可能となっている。フレンドユーザ情報は、ＳＮＳ（Social Networking Service）の情報を用いてもよい。最終カード情報は、ゲームの履歴情報から抽出してもよい。リーダカードＩＤは、デッキ内の先頭カードを示す情報である。なお、最終カード情報は、リーダカードＩＤに限らず、デッキ内のカードを示す情報であれば、適宜、使用可能となっている。但し、カードを用いなくてもよい。カードを用いる場合、味方キャラクタを分類せずに、例えば、味方キャラクタにカードをランダムに配ってもよい。味方キャラクタを分類する場合、種族ごとに限らず、任意の属性ごと（例、職業ごと、職位ごと、所有アイテムごと、行動の特徴ごと等）に分類可能である。

【0028】

（ｅ） 種族カードの枚数に応じて、味方キャラクタの攻撃を変化させてもよい。

【0029】

（ｆ） カードは、スピード属性を持たせてもよい。この場合、デッキに投入されたカードのスピード属性に応じて、攻撃間隔の短い行程データがサーバ側から提供される。

【0030】

（ｇ） 攻撃チャージが味方キャラクタの攻撃毎に減っていき、攻撃チャージが０になると敵からの攻撃を受けるようにしてもよく、敵からの攻撃を受けると、攻撃チャージが所定値にリセットされるようにしてもよい。但し、攻撃チャージを用いる場合、攻撃チャージの数値は表示してもしなくてもよい。

【0031】

（ｈ）味方キャラクタ毎に行動の特徴を定義してもよい。この場合、行程データは、味方キャラクタ毎の特徴に基づいて作成される。例えば、第１の味方キャラクタが攻撃重視、第２の味方キャラクタが防御重視、第３の味方キャラクタが魔法重視、といった特徴に基づいて行程データを作成してもよい。なお、攻撃重視の場合、例えば、敵に与えるダメージを大きい値にしてステップを作成すればよい。防御重視の場合、例えば、敵から受けるダメージを小さい値にしてステップを作成すればよい。魔法重視の場合、例えば、通常の攻撃にはない変化をＨＰに与えるようにステップを作成すればよい。通常の攻撃パターンにはない変化としては、例えば、１つ以上の味方キャラクタのＨＰを回復させる等がある。ここでいう「特徴」の用語は、キャラクタ毎の行動を区別する項目を表す用語であればよいので、例えば、「役割」、「パターン」、「方針」、「原則」又は「規則」等といった用語に適宜、読み替えてもよい。また、これらの用語は、適宜、「行動」又は「行動の」等といった修飾語を付加してもよい（例、行動パターン、行動の方針など。）。

【0032】

（ｉ）スキルチャージが味方キャラクタの攻撃毎に減っていき、スキルチャージが０になるとカードが明滅し、スキル発動可能状態になるようにしてもよい。但し、攻撃チャージの数値の表示／非表示は任意である。スキル発動可能状態か否かの表示／非表示も任意であるが、プレイし易さの観点から、スキル発動可能状態か否かは表示する方が好ましい。但し、スキル発動可能状態を明示せずに、別の指標（例、味方キャラクタの個数やＨＰ、ゲームの経過時間など）により、スキル発動可能状態か否かが分かるようにしてもよい。

【0033】

次に、以上のような任意の付加的要素（ａ）〜（ｉ）のうち、（ｂ）キャラクタを動かす行程データ、（ｄ）カードのデッキ、（ｅ）カード枚数に応じた攻撃、（ｇ）攻撃チャージ、及び（ｉ）スキルチャージ、を用いたゲームの一例について説明する。例えば、図４に示すように、味方キャラクタＰ１〜Ｐ３と、敵キャラクタＥｎ１〜Ｅｎ５とが草原で対戦している場面を表す対戦画面Ｇ１と、各種族カードＣ１〜Ｃ６を明示したデッキを表すデッキ画面Ｇ２とを含むゲーム画面が表示されていたとする。各キャラクタＰ１〜Ｐ３、Ｅｎ１〜Ｅｎ５下方の太い横棒は、斜線領域によりＨＰを表わしている。種族カードＣ１〜Ｃ６は、図５（ａ）に示すように、カードＩＤ、種族名、属性名及びスキルチャージ（初期値）が互いに関連付けられたカード情報により表示される。カード情報は、図５（ｂ）に示すカード管理情報から選択された情報であり、デッキ情報ともいう。味方キャラクタＰ１〜Ｐ３は、図６（ａ）に示すように、味方キャラクタＩＤ、ＨＰ、種族名及びカード枚数が互いに関連付けられた味方キャラクタ情報により表示される。味方キャラクタ情報は、図５（ａ）に示すカード情報内の種族名の個数に応じたカード枚数を、図６（ｂ）に示す味方キャラクタ管理情報に関連付けた情報である。敵キャラクタＥｎ１〜Ｅｎ５は、図７に示すように、敵キャラクタＩＤ、ＨＰ及び攻撃チャージ（初期値）が互いに関連付けられた敵キャラクタ情報により表示される。カード管理情報、味方キャラクタ管理情報及び敵キャラクタ情報は、予めゲーム制御プログラムに記述されている。

【0034】

ここで、デッキに投入されている各種族カードに応じて、攻撃する味方キャラクタが変化する例に付いて述べる。種族と味方キャラクタＰ１〜Ｐ３との組合せは、例えば、図６（ａ）及び次の通りとする。
種族組合せ：Ｐ１…獣族、Ｐ２…精霊族、Ｐ３…人間族。

【0035】

このとき、味方キャラクタＰ１〜Ｐ３は、種族カードの枚数に応じた攻撃を行う（段階攻撃）。具体的には例えば、次に示すように段階攻撃を行うようにすればよい。
０枚…画面の隅で怯えている動作（モーション）で、順番が来ても攻撃しない。
１〜２枚…順番が来たら、弱い攻撃を行う動作。
３〜４枚…順番が来たら、普通の攻撃を行う動作。
５〜６枚…順番が来たら、強い攻撃を行う動作。

【0036】

図４に示す例では、第１の味方キャラクタＰ１が、種族カード“獣”の枚数“３枚”に応じて、順番が来たら普通の攻撃を行うように動作する。

【0037】

第２の味方キャラクタＰ２は、種族カード“精霊”の枚数“１枚”に応じて、順番が来たら弱い攻撃を行うように動作する。

【0038】

第３の味方キャラクタＰ３は、種族カード“人間”の枚数“２枚”に応じて、順番が来たら弱い攻撃を行うように動作する。

【0039】

なお、攻撃の順番と、攻撃により敵に与えるダメージとは、行程データに示される。攻撃の順番は、例えば第１、第２及び第３の味方キャラクタＰ１、Ｐ２、Ｐ３の昇順で巡回する順番（Ｐ１→Ｐ２→Ｐ３を繰り返す順番）において、攻撃チャージに基づく間隔で敵キャラクタＥｎ１、Ｅｎ２、Ｅｎ３の攻撃を挿入して得られる。すなわち、敵キャラクタＥｎ１〜Ｅｎ５の各々は、味方キャラクタＰ１、Ｐ２、Ｐ３の攻撃毎にカウントダウンされる値の攻撃チャージが０になった時点で攻撃の順番が来る。各々の攻撃チャージは、対応する敵キャラクタの攻撃後に初期値にリセットされる。なお、味方キャラクタや敵キャラクタの攻撃の順序は、例えば、スキル発動可能状態から選択された種族カードの属性名に応じて、変更してもよい。例えば、スキル発動可能状態でカードＣ１（火属性）を選択した場合には、Ｐ１→Ｐ２→Ｐ３を繰り返す攻撃順序であるのに対し、スキル発動可能状態でカードＣ２（水属性）を選択した場合には、Ｐ３→Ｐ２→Ｐ１を繰り返す攻撃順序であるようにしてもよい。敵キャラクタの攻撃順序も同様に、カードの属性に応じて変更してもよい。

【0040】

行程データの作成に用いる条件は、図８に示すように、例えば、敵キャラクタＥｎ１，Ｅｎ２，…を示す敵キャラクタＩＤ、敵キャラクタのＨＰ、及び攻撃チャージの初期値（攻撃チャージが０になるまでの攻撃回数）、といった敵キャラクタに関する条件と、カードＣ１，Ｃ２，…を示すカードＩＤ、及びスキルチャージの初期値（スキルチャージが０になるまでの攻撃回数）、といったカードに関する条件と、を含んでいる。攻撃チャージの初期値と、スキルチャージの初期値との関係は任意であるが、少なくともいずれかの攻撃チャージの初期値が、全てのスキルチャージの初期値よりも小さいという関係をもつ方が、（いずれかの敵の反撃後にスキル発動可能となるため、）一方的な攻撃による興趣性の低下を防ぐ観点から好ましい。行程データの作成に用いる条件としては、さらに、味方キャラクタの攻撃力及び防御力と、敵キャラクタの攻撃力及び防御力とを含めてもよい。なお、攻撃チャージの初期値は、行程データのうち、攻撃の順番の決定に用いられる。敵キャラクタのＨＰは、行程データのうち、攻撃により受けるダメージの決定に用いられる。攻撃により受けるダメージは、前述した各キャラクタの攻撃力及び防御力に基づいて決定（算出）してもよく、ランダムに決定してもよく、あるいは、所定のアルゴリズムで算出した値にランダムな値を加算して得られた値に決定してもよい。

【0041】

行程データは、図９に示すように、各々の行程を示すステップ番号毎に、攻撃元のキャラクタＩＤ、攻撃先のキャラクタＩＤ、攻撃先のキャラクタＩＤに付与されるダメージ（ＨＰの減少分）を含んでいる。各々の行程は、ステップ番号毎に順次、再生される。なお、行程データのうち、最終ステップは、開始時のステップ（又は途中のステップ）に戻ることを記述していてもよい。あるいは、最終ステップから開始時又は途中のステップに戻ることは、行程データに含めず、ゲームプログラムに規定してもよい。

【0042】

図９に示す行程データの場合、１１ステップ目で、味方キャラクタＰ１，Ｐ２，Ｐ３の攻撃回数が合計８回目になり、カードＣ１，Ｃ６のスキルチャージが０になる。このため、１１ステップ終了後に、カードＣ１，Ｃ６がスキル発動可能状態になり、カードＣ１，Ｃ６が明滅する。カードＣ１，Ｃ６の明滅状態（スキル発動可能状態）は、スキル発動されるまで継続する。

【0043】

１１ステップより後にユーザがカードＣ１又はカードＣ６をタッチ操作してスキル発動を行った場合、発動したタイミング以降の行程を示す新たな行程データがサーバから取得される。これは、図１中、上の行程から下の行程に移行することに対応する。

【0044】

ここで、新たな行程データは、新たに作成してもよく、前回の行程データ内の各パラメータを任意に変更して作成してもよい。新たな行程データは、例えば、前回の行程データのうち、各キャラクタＩＤを変えずに、ダメージの値を変えて作成してもよい。あるいは、新たな行程データは、前回の行程データに対し、各キャラクタＩＤを変えると共に、ダメージの値を変えて作成してもよい。すなわち、ダメージの値は、変更後の行程データが新たな結果をもたらすために、前回の行程データから変更する必要がある。但し、各キャラクタＩＤは、前回の行程データから変えても変えなくてもよい。また、攻撃チャージ及びスキルチャージは、それぞれ前回の行程データから変えても変えなくてもよい。

【0045】

以上が本発明の概要である。続いて、本発明の各実施形態について具体的に説明する。

【0046】

＜第１の実施形態＞
図１０は本発明の第１の実施形態に係るゲーム制御方法が適用されたゲームシステムの構成例を示す模式図である。インターネットなどを含むネットワーク１に対し、ゲーム提供装置２が接続されると共に、本システムでユーザが使用するクライアント装置となる、複数、例えば３台の携帯端末４Ａ〜４Ｃが、無線ＬＡＮのアクセスポイント（ＡＰ）５、あるいは基地局６を介して接続される。これらの各装置は、それぞれハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は記憶媒体から各装置のコンピュータにインストールされ、対応する装置の機能を実現させるためのプログラムが用いられる。

【0047】

ゲーム提供装置２は、ゲームを実現するためのゲームプログラム、当該ゲームプログラムに付随した画像データ及び行程データを携帯端末４Ａ〜４Ｃに提供するコンピュータである。このゲーム提供装置２は、例えばＳＮＳを運営する企業が、サービスの一環としてオンラインゲームのサービスを提供するべく設置するものであり、ネットワーク１に接続される。

【0048】

一方、クライアント側の携帯端末４Ａ〜４Ｃは、それぞれスマートフォン、フィーチャー・フォンなどを含み、例えば、Android（登録商標）又はiOS（登録商標）などのＯＳ（Operating System）上で動作する携帯電話であっても良いし、さらにはノートブック型のパーソナルコンピュータ、モバイルコンピュータなどであっても良い。以下の実施形態では、説明を簡略化するために、携帯端末４Ａ〜４Ｃはいずれもタッチパネルを有するスマートフォンであるものとして説明する。

【0049】

携帯端末４Ａ〜４Ｃは、上記基地局６を介してのネットワーク１との接続に加えて、例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ規格の無線ＬＡＮ（Local Area Network）であるＷｉ−Ｆｉ（登録商標）を優先的に選択可能として、上記アクセスポイント５と相互接続が可能であるものとする。

【0050】

また、携帯端末４Ａ〜４Ｃは、例えば、近距離無線通信規格であるBluetooth（登録商標）技術により相互に無線接続が可能となっている。

【0051】

携帯端末４Ａ〜４Ｃとしては、その機種固有のハードウェア構成、採用しているＯＳ、インストールされているアプリケーション等が多岐にわたるものとし、ゲーム提供装置２はそれら多様な携帯端末４Ａ〜４Ｃに対応した各種アプリケーションプログラムをそれぞれに配信可能であるものとする。

【0052】

上記ゲーム提供装置２と携帯端末４Ａ〜４Ｃそれぞれの機能ブロック構成について図１１乃至図１２を参照して述べる。

【0053】

ゲーム提供装置２は、携帯端末４Ａ〜４Ｃにゲームを提供可能な装置であり、図１１に示すように、記憶装置２１、メモリ２２、プロセッサ２３及び通信部２４を備えている。記憶装置２１及びメモリ２２は記憶手段を構成している。プロセッサ２３は、記憶手段にアクセス可能な処理装置を構成している。

【0054】

記憶装置２１は、ゲームを実現するためのゲーム制御プログラムｐ_ｓ３等を記憶するものであり、例えば、ハードディスクドライブ（ＨＤＤ）、光ディスクドライブ、ＤＶＤ、ＭＯなどの大容量記憶装置である。この記憶装置２１には、ＯＳ（オペレーティングシステム）ｐ_ｓ０、サーバ側ＪＳ実行環境プログラムｐ_ｓ１、Ａ社フレームワークプログラムｐ_ｓ２及びゲーム制御プログラムｐ_ｓ３等が記憶されている。ゲーム制御プログラムｐ_ｓ３は、ゲームに用いる画像データを含んでいる。

【0055】

ＯＳ ｐ_ｓ０は、ゲーム提供装置２の基本的な機能を実現するためのプログラムである。

【0056】

サーバ側ＪＳ実行環境プログラムｐ_ｓ１は、プロセッサ２３により実行され、後述するサーバ側ＪＳ実行環境Ｓ１を実現するためのプログラムである。

【0057】

Ａ社フレームワークプログラムｐ_ｓ２は、プロセッサ２３により実行され、後述するＡ社フレームワークＳ２を実現するためのプログラムである。

【0058】

各ゲーム制御プログラムｐ_ｓ３は、ゲーム提供装置２に用いられるプログラムである。詳しくは各ゲーム制御プログラムｐ_ｓ３は、プロセッサ２３により実行され、本実施形態に係るゲームを個別に実現するためのプログラムである。例えば、ゲーム制御プログラムｐ_ｓ３は、携帯端末４Ａのユーザの操作により、ゲームを携帯端末４Ａに実行させるためのプログラムである。なお、この説明及び他の箇所における携帯端末４Ａの説明は、他の携帯端末４Ｂ、４Ｃについても同様である。

【0059】

また、ゲーム制御プログラムｐ_ｓ３は、任意のプレイ内容に関するゲーム機能の他に、以下の機能（ｆ１）〜（ｆ２）をプロセッサ２３に実現させるためのプログラムを含んでいる。

【0060】

（ｆ１） 携帯端末４Ａから送信リクエストを受信した場合、画像データと、当該ゲーム内の行程を示す第一の行程データとを携帯端末４Ａに送信する第一の送信機能。

【0061】

画像データとしては、例えば、ゲームの背景画面に用いる画像データ（例、草原、海岸、山、海、空、宇宙、宮殿など）、各キャラクタの画像データ、各キャラクタの攻撃を示す画像データ（例、炎、水、雷、光線、煙など）、各カードの画像データ、及びスキル演出画面（例、必殺技、舞踊など）の画像データなどがある。

【0062】

（ｆ２） 携帯端末４Ａが当該画像データ及び行程データに基づいて各々の行程を再生中に、当該行程データを変更するための変更リクエストを当該携帯端末４Ａから受信した場合、第二の行程データを含む変更レスポンスを携帯端末４Ａに送信する第二の送信機能。

【0063】

当該変更レスポンスが、ゲームの背景画面を遷移するための画面遷移情報を含まず、当該ゲームが、行程データの変更の前後で、同一の画像データを背景画面に用いることが、背景画面のデータ量を低減し、より一層、通信量を低減させる観点から好ましい。但し、これらの事項は必須ではない。仮に、変更レスポンスが画面遷移情報を含み、行程データの変更の前後で背景画面の画像データが変更されたとしても、例えば、変更レスポンスが画面遷移情報を含む確率が１／２よりも低い場合には、背景画面のデータ量を著しく低減させることが可能である。

【0064】

当該ゲームは、ユーザの側の味方キャラクタと、ゲーム提供装置２の側の敵キャラクタとが対戦する対戦ゲームであってもよい。行程データが示す各々の行程は、味方キャラクタが敵キャラクタを攻撃する行程、又は敵キャラクタが味方キャラクタを攻撃する行程であってもよい。

【0065】

各々の行程は、味方キャラクタが敵キャラクタを攻撃する複数回の行程と、敵キャラクタが味方キャラクタを攻撃する１回の行程とを交互に含んでもよい。すなわち、各々の行程は、前述した攻撃チャージに基づいて攻撃の順序が定められていてもよい。

【0066】

各々の行程のうち、味方キャラクタが敵キャラクタを攻撃する行程が所定回数だけ実行されたときの行程は、第二の送信機能が実行可能であることをユーザに提示する行程を含んでいてもよい。すなわち、各々の行程のうちのいずれかの行程は、前述したスキルチャージに基づいてスキル発動可能状態を提示する行程を含んでもよい。

【0067】

メモリ２２は、ゲーム制御プログラムｐ_ｓ３等を実行する際に必要とされるワークエリアなどとして使用される。

【0068】

プロセッサ２３は、記憶装置２１及びメモリ２２にアクセス可能となっており、記憶装置２１に記憶されたゲーム制御プログラムｐ_ｓ３等と協働して、本発明の実施形態に係るゲームを行う他、ゲーム提供装置２全体の制御を司るものである。

【0069】

通信部２４は、ネットワーク１を介した携帯端末４Ａ〜４Ｃなどの外部装置との通信の制御を司る。

【0070】

各携帯端末４Ａ〜４Ｃの機能ブロック構成は、互いに同一のため、ここでは携帯端末４Ａの機能ブロック構成を代表例に挙げて述べる。

【0071】

携帯端末４Ａは、図１２に示すように、記憶装置４１Ａ、メモリ４２Ａ、プロセッサ４３Ａ、通信部４４Ａ、電子コンパス４５Ａ、カメラ４６Ａ、表示部４７Ａ及びタッチパネル４８Ａを備えている。各部４１Ａ〜４８Ａの説明は、符号の末尾ＡをＢ又はＣに読み替えることにより、他の携帯端末４Ｂの各部４１Ｂ〜４８Ｂの説明又は他の携帯端末４Ｃの各部４１Ｃ〜４８Ｃの説明として読み替え可能となっている。

【0072】

記憶装置４１Ａは、ゲームを実現するためのクライアントサイドのゲーム制御プログラムｐ_ｃ４等を記憶するものであり、例えば、ハードディスクドライブ（ＨＤＤ）などの大容量記憶装置である。この記憶装置４１Ａには、ＯＳ（オペレーティングシステム）ｐ_ｃ０、アプリケーション実行環境プログラムｐ_ｃ１、Ａ社ＤＢ接続キットプログラムｐ_ｃ２、Ａ社フレームワークプログラムｐ_ｃ３及びゲーム制御プログラムｐ_ｃ４が記憶されている。

【0073】

ＯＳ ｐ_ｃ０は、携帯端末４Ａの基本的な機能を実現するためのプログラムである。

【0074】

アプリケーション実行環境プログラムｐ_ｃ１は、プロセッサ４３Ａにより実行され、後述するアプリケーション実行環境Ｃ１を実現するためのプログラムである。

【0075】

Ａ社ＤＢ接続キットプログラムｐ_ｃ２は、プロセッサ４３Ａにより実行され、後述するＡ社ＤＢ接続キットＣ２を実現するためのプログラムである。

【0076】

Ａ社フレームワークプログラムｐ_Ｃ３は、プロセッサ４３Ａにより実行され、後述するＡ社フレームワークＣ３を実現するためのプログラムである。

【0077】

ゲーム制御プログラムｐ_ｃ４は、プロセッサ４３Ａにより実行され、本発明の実施形態に係るゲームのクライアント側の処理を制御するプログラムである。

【0078】

メモリ４２Ａは、クライアントサイドのゲーム制御プログラムｐ_ｃ４を実行する際に必要とされるワークエリアなどとして使用される。

【0079】

プロセッサ４３Ａは、記憶装置４１Ａに記憶されたゲーム制御プログラムｐ_ｃ４と協働して、本発明の実施形態に係るゲームを行う他、携帯端末４Ａ全体の制御を司るものである。

【0080】

通信部４４Ａは、ネットワーク１を介したゲーム提供装置２などの外部装置との通信の制御を司る。また、通信部４３は、無線ＬＡＮ、ブルートゥース（登録商標）、ＷｉＦｉなどの無線通信機能をも有する。

【0081】

電子コンパス４５Ａは、地磁気センサを有し、方位を測定する。

【0082】

カメラ４６Ａは、撮像機能を有し、撮像した画像を記憶装置４１Ａに格納する。

【0083】

表示部４７Ａは、タッチパネル４８Ａが取り付けられたディスプレイ装置である。

【0084】

タッチパネル４８Ａは、ユーザの操作に応じて、操作データを入力する機能をもっている。

【0085】

上記ゲーム提供装置２と携帯端末４Ａ〜４Ｃそれぞれの機能ブロック構成に対応する電子回路のハードウェア構成自体は、きわめて一般的で周知であるものとして、その記載及び説明を省略する。

【0086】

続いて、ゲーム提供装置２と携帯端末４Ａ〜４Ｃ間の接続アーキテクチャの概念について説明する。Ａ社が提供するオンラインのゲームプログラム又はアプリケーションプログラムを実行するに当たり、携帯端末４Ａ〜４Ｃには、例えばＡＩＲ（登録商標）などで記述された、当該ゲームプログラム又はアプリケーションプログラムのためのアプリケーション実行環境（プログラムｐ_ｃ１）が実装されると共に、当該Ａ社のデータベースに接続して課金処理等を行うためのＡ社データベース接続キット（プログラムｐ_ｃ２）が組込まれる。

【0087】

これと共に、携帯端末４Ａ〜４Ｃがゲーム提供装置２との通信を行う部分に関しては、Ａ社が開発した（ソフトウェア）クライアントサイドのＡ社フレームワーク（プログラムｐ_ｃ３）がインストールされる。

【0088】

一方のゲーム提供装置２では、オンラインゲーム及びアプリケーションを実行するための、例えばNode.js（登録商標）やjQueryで記述されたサーバ側JavaScript（登録商標）実行環境（プログラムｐ_ｓ１）が実装されると共に、携帯端末４Ａ〜４Ｃとの通信を行う部分には、上記Ａ社フレームワーク（プログラムｐ_ｃ３）と対応するＡ社（ソフトウェア）サーバサイドのＡ社フレームワーク（プログラムｐ_ｓ２）が実装される。

【0089】

上記各フレームワーク（プログラムｐ_ｃ３、ｐ_ｓ２）は、ＯＳに依存しないスクリプト言語として、例えばJavaScriptを用いて記述されている。そのため、携帯端末４Ａ〜４ＣのＯＳがAndroid及びiOSなどのいずれのＯＳであっても同一接続環境を構築できる。また、変形例として、ゲームプログラム（Nativeアプリ）の一部に、ＡＰＩ（application programming interface）としてウェブソケット（Websocket）機能を組み込む場合には、Nativeアプリでもウェブソケットを利用することが可能となる。

【0090】

次に、以上のように構成されたゲームシステムの動作について図１３のフローチャート及び図１４のシーケンス図を用いて説明する。なお、以下の説明では、ゲーム提供装置２には、予め図３に示した各プログラムｐ_ｓ１〜ｐ_ｓ３がインストールされているものとする。同様に、各携帯端末４Ａ〜４Ｃには、最初にＡ社からサービス提供を受けた際に、図１２に示した各プログラムｐ_ｃ１〜ｐ_ｃ４がインストールされたものとする。また、以下の説明では、記載を簡潔にする観点から、送受信に通信部２４、４４Ａを介在させている旨の記載を省略する。また、以下の説明は、図４に示す対戦ゲームを実行する場合を例に挙げて述べる。

【0091】

＜準備段階＞
始めに、携帯端末４Ａでは、図１３に示すように、ユーザの操作により、デッキ構築を開始するためのデッキ構築開始リクエストをゲーム提供装置２に送信する（ＳＴ１）。

【0092】

ゲーム提供装置２では、プロセッサ２３が、このデッキ構築開始リクエストに応じて、図５（ｂ）に示すカード管理情報に基いて、カードＩＤ、種族名及び属性名を含む種族カードのリスト情報を含むレスポンスを携帯端末４Ａに送信する。

【0093】

携帯端末４Ａでは、このリスト情報を表示し、ユーザの操作により、リスト情報から５枚の種族カードを選択し、選択結果を示すリクエストをゲーム提供装置２に送信する（ＳＴ２）。

【0094】

ゲーム提供装置２では、プロセッサ２３が、このリクエストを受けると、図２に示すフレンドユーザ情報に基いて、携帯端末４ＡのユーザのユーザＩＤに関連付けられたフレンドのユーザＩＤを含むレスポンスを携帯端末４Ａに送信する。

【0095】

携帯端末４Ａでは、このフレンドのユーザＩＤを表示し、ユーザの操作により、一人のフレンドのユーザＩＤを選択し（ＳＴ３）、選択結果を示すリクエストをゲーム提供装置２に送信する。

【0096】

ゲーム提供装置２では、プロセッサ２３が、このリクエストを受けると、図３に示す最終カード情報に基いて、フレンドのユーザＩＤに関連付けられたリーダカードＩＤを読出すと共に、このリーダカードＩＤに対応する１枚の種族カードをリスト情報から選択する。この選択は、フレンドユーザの最終プレイ時のリーダカードを６枚目のカードとする処理に相当する（ＳＴ４）。

【0097】

しかる後、ゲーム提供装置２では、プロセッサ２３が、選択された合計６枚の種族カードの情報からなるデッキ情報を構築し（ＳＴ５）、当該デッキ情報を含むレスポンスを携帯端末４Ａに送信する。

【0098】

続いて、携帯端末４Ａでは、ユーザの操作により、クエスト（行先）を選択するためのクエスト選択リクエストをゲーム提供装置２に送信する。なお、「クエスト」は、「ゲーム」と読み替えてもよい。

【0099】

ゲーム提供装置２では、プロセッサ２３が、このクエスト選択リクエストに応じて、各クエストの案内情報を含むレスポンスを携帯端末４Ａに送信する。

【0100】

携帯端末４Ａでは、この各クエストの案内情報を表示し、ユーザの操作により、１つのクエストを選択し（ＳＴ６）、選択結果を含む送信リクエストをゲーム提供装置２に送信する。

【0101】

ゲーム提供装置２では、プロセッサ２３が、この送信リクエストに応じたレスポンスとして、選択されたクエストに用いる画像データと、当該クエスト内の行程を示す第一の行程データとを含むレスポンスを携帯端末４Ａに送信する。画像データのうち、各キャラクタの画像データは、味方キャラクタ情報及び敵キャラクタ情報を付随情報として含んでいる。なお、各キャラクタの画像データと、味方キャラクタ情報及び敵キャラクタ情報とは別々の情報としてもよい。この場合、レスポンスは、図６（ａ）に示す味方キャラクタ情報及び図７に示す敵キャラクタ情報を含んでいる。また、画像データと、第一の行程データとは、１回のレスポンスに含めてもよく、別々のレスポンスに含めてもよい。

【0102】

いずれにしても、携帯端末４Ａでは、ゲーム開始前に、クエストの全データを取得し（ＳＴ７）、準備段階の処理を終了する。

【0103】

＜ゲーム段階＞
携帯端末４Ａでは、図１４に示すように、当該画像データ及び行程データに基づいて各々の行程を再生するクエストを実行する（ＳＴ１１）。当該クエストは、図４に示すように、ユーザの側の味方キャラクタＰ１〜Ｐ３と、ゲーム提供装置２の側の敵キャラクタＥｎ１〜Ｅｎ５とが対戦する対戦ゲームである。行程データが示す各々の行程は、味方キャラクタＰ１〜Ｐ３が敵キャラクタＥｎ１〜Ｅｎ５を攻撃する行程、又は敵キャラクタＥｎ１〜Ｅｎ５が味方キャラクタＰ１〜Ｐ３を攻撃する行程となっている。

【0104】

すなわち、当該クエストは、例えば図４に示す画面Ｇ１，Ｇ２の表示中、図９に示す行程データに基づいて、画面Ｇ１内の各キャラクタＰ１〜Ｐ３、Ｅｎ１〜Ｅｎ５の攻撃及びダメージを制御することにより、実行されている。図９に示す行程データは、味方キャラクタＰ１〜Ｐ３が敵キャラクタＥｎ１〜Ｅｎ５を攻撃する複数回の行程と、敵キャラクタＥｎ１〜Ｅｎ５が味方キャラクタＰ１〜Ｐ３を攻撃する１回の行程とを交互に含んでいる。また、携帯端末４Ａは、この行程データに基づいて、例えば、味方キャラクタＰ１〜Ｐ３が敵キャラクタＥｎ１〜Ｅｎ５を攻撃する行程が１１回だけ実行されたとき、スキル発動可能状態をカードＣ１，Ｃ６の明滅によりユーザに提示する。

【0105】

携帯端末４Ａでは、クエストの実行中、ユーザの操作により、当該行程データを変更するための変更リクエストをゲーム提供装置２に送信する（ＳＴ１２）。ステップＳＴ１２の操作としては、例えば、明滅中のカードをタッチする操作である。

【0106】

ゲーム提供装置２では、プロセッサ２３が、当該行程データを変更するための変更リクエストを当該携帯端末４Ａから受信する（ＳＴ１３）。

【0107】

ゲーム提供装置２では、プロセッサ２３が、当該変更リクエストに応じて、携帯端末４Ａが用いている行程データとは異なる第二の行程データを含む変更レスポンスを携帯端末４Ａに送信する（ＳＴ１４）。この例では、当該変更レスポンスは、クエストの背景画面を遷移するための画面遷移情報を含まない。当該クエストは、行程データの変更の前後で、同一の画像データを当該背景画面に用いている。図４に示すゲーム画面Ｇ１の場合、変更前の行程データの背景画面に用いる草原の画像データと、変更後の行程データの背景画面に用いる草原の画像データとが同一の画像データである。

【0108】

携帯端末４Ａでは、当該第二の行程データに基づいて各々の行程を再生するクエストを実行する（ＳＴ１５）。

【0109】

以下、携帯端末４Ａでは、クエスト終了まで、適宜、ステップＳＴ１２〜ＳＴ１５の処理を繰り返し実行する。補足すると、ユーザは、携帯端末４Ａに再生されるクエストの推移を見守り、勝ちそうであれば、そのままステップＳＴ１５を継続し、負けそうであれば、再度、ステップＳＴ１２の操作を実行し、行程データを変更させる。

【0110】

上述したように本実施形態によれば、ゲーム提供装置２が、携帯端末４Ａから送信リクエストを受信した場合、画像データと、ゲーム内の行程を示す第一の行程データとを携帯端末４Ａに送信する。

【0111】

これにより、リクエスト・レスポンス方式を用いて高画質の画像データをクライアント側に提供でき、クライアント側で高画質の画像データを作成する負荷が無い。

【0112】

また、本実施形態によれば、画像データ及び行程データに基づいて各々の行程を携帯端末４Ａが再生中に、ゲーム提供装置２が、行程データを変更するための変更リクエストを当該携帯端末４Ａから受信した場合、第二の行程データを含む変更レスポンスを携帯端末４Ａに送信する。

【0113】

ここで、変更レスポンスがゲームの背景画面を遷移するための画面遷移情報を含まず、ゲームが、行程データの変更の前後で、同一の画像データを背景画面に用いる場合、背景画面のデータ量を低減でき、より一層、通信量を低減させることができる。また、変更レスポンスが画面遷移情報を含むとしても、画面遷移情報を含む確率が低い場合には、同様に、背景画面のデータ量を低減でき、より一層、通信量を低減させることができる。

【0114】

また、本実施形態によれば、ユーザの側の味方キャラクタと、ゲーム提供装置２の側の敵キャラクタとが対戦する対戦ゲームを実現することができる。

【0115】

また、本実施形態によれば、味方キャラクタＰ１〜Ｐ３が敵キャラクタＥｎ１〜Ｅｎ５を攻撃する複数回の行程と、敵キャラクタＥｎ１〜Ｅｎ５が味方キャラクタＰ１〜Ｐ３を攻撃する１回の行程とを交互に含むので、規則的に行程データを作成でき、もって、行程データを作成する負荷を軽減させることができる。

【0116】

また、本実施形態によれば、味方キャラクタＰ１〜Ｐ３が敵キャラクタＥｎ１〜Ｅｎ５を攻撃する行程が所定回数だけ実行されたときの行程が、スキル発動可能状態をユーザに提示する行程を含んでいるので、規則的に行程データを作成でき、もって、行程データを作成する負荷を軽減させることができる。

【0117】

＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。

【0118】

本実施形態は、第１の実施形態の変形例であり、図１５（ａ）及び図１５（ｂ）に示すように、カードＩＤ毎に、行程データが示す各々の行程の間隔の実行速度ｖ〜３ｖを示すスピード属性を関連付けた構成である。なお、図１５（ｂ）はカード管理情報を示し、図１５（ａ）はカード管理情報から選択されたカード情報（デッキ情報ともいう）を示す。

【0119】

ここで、第１の実行速度ｖは、第２の実行速度２ｖの半分の実行速度であることを示す。ｖの絶対値は任意に設定可能である。なお、実行速度としては、ｖ〜３ｖの値に限らず、任意の値が使用可能である。また、各実行速度ｖ〜３ｖは任意であるが、カードの他の属性（種族名又は属性名）のパターンとは一致しないように設定することが望ましい。

【0120】

このような実行速度としては、例えば、フレームレートが使用可能となっている。フレームレートとは、動画において、単位時間当たりいくつフレーム（映像・コマのこと）が処理されるかを示す値である。フレームレートは、通常、１秒当たりの数値で表し、ｆｐｓ（frames per second）という単位で表す。

【0121】

以上のような構成によれば、ゲーム提供装置２が、図１５（ａ）に示す情報に基いて、各々の行程の間隔の実行速度を規定した行程データを作成し、スキル発動時に選択されたカードのスピード属性が示す実行速度ｖ〜３ｖで各々の行程の間隔が進行する（異なる）行程データを携帯端末４Ａに提供できるので、第１の実施形態の効果に加え、興趣性を向上させることができる。

【0122】

＜第３の実施形態＞
次に、本発明の第３の実施形態について説明する。

【0123】

本実施形態は、第１又は第２の実施形態の変形例であり、図１６（ａ）及び図１６（ｂ）に示すように、味方キャラクタＩＤ毎に、攻撃重視、防御重視又は魔法重視を示す行動の特徴属性を関連付けた構成である。なお、図１６（ｂ）は味方キャラクタ管理情報を示す。図１６（ａ）は、図５（ａ）又は図１５（ａ）に示すカード情報内の種族名の個数に応じたカード枚数を味方キャラクタ管理情報に関連付けた味方キャラクタ情報を示す。

【0124】

ここで、攻撃重視の場合、行程データを作成する際に、例えば、敵に与えるダメージを大きい値にして行程（ステップ）を作成すればよい。防御重視の場合、行程データを作成する際に、例えば、敵から受けるダメージを小さい値にして行程を作成すればよい。魔法重視の場合、行程データを作成する際に、例えば、通常の攻撃にはない変化をＨＰに与えるように行程を作成すればよい。通常の攻撃パターンにはない変化としては、例えば、１つ以上の味方キャラクタのＨＰを回復させる等がある。回復対象の味方キャラクタは、自分（当該魔法重視の味方キャラクタ）でもよく、自分以外の味方キャラクタでもよい。

【0125】

以上のような構成によれば、ゲーム提供装置２が、図１６（ａ）に示す情報に基いて、味方キャラクタ毎に行動の特徴を変えた行程データを作成し、味方キャラクタＩＤ毎に、特徴が異なる行程データを携帯端末４Ａに提供できるので、第１又は第２の実施形態の効果に加え、興趣性を向上させることができる。

【0126】

なお、上記実施の形態では、ゲーム制御プログラムｐ_ｓ３に、第一の送信機能および第二の送信機能が設けられる場合で説明したが、これに限定されるものではない。例えば、ゲーム制御プログラムｐ_ｃ４が、画像データと、当該ゲーム内の行程を示す第一の行程データとを携帯端末４Ａで再生し、携帯端末４Ａが当該画像データ及び第一の行程データに基づいてゲーム内の行程を再生中に、ユーザの操作により、当該第一の行程データを変更するための変更リクエストの入力を受け付けると、第二の行程データを携帯端末４Ａで再生するとしても良い。

【0127】

なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどのコンピュータ読み取り可能な記憶媒体に格納して頒布することもできる。

【0128】

なお、本願発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。

【0129】

以下に、本願の原出願の当初の特許請求の範囲に記載された発明を付記する。

【0130】

［１］ ゲームに用いる画像データを記憶した記憶手段及び前記記憶手段にアクセス可能な処理装置を備え、携帯端末にゲームを提供可能なゲーム提供装置に用いられるゲーム制御方法であって、前記処理装置が、前記携帯端末から送信リクエストを受信した場合、前記画像データと、前記ゲーム内の行程を示す第一の行程データとを前記携帯端末に送信する第一の送信工程と、前記画像データ及び前記行程データに基づいて各々の行程を再生中に、前記行程データを変更するための変更リクエストを当該携帯端末から受信した場合、第二の行程データを含む変更レスポンスを前記携帯端末に送信する第二の送信工程と、を備えたことを特徴とするゲーム制御方法。

【0131】

［２］ 上記［１］に記載のゲーム制御方法において、前記変更レスポンスは、前記ゲームの背景画面を遷移するための画面遷移情報を含まず、前記ゲームは、前記行程データの変更の前後で、同一の画像データを前記背景画面に用いることを特徴とするゲーム制御方法。

【0132】

［３］ 上記［１］又は［２］に記載のゲーム制御方法において、前記ゲームは、前記ユーザの側の味方キャラクタと、前記ゲーム提供装置の側の敵キャラクタとが対戦する対戦ゲームであり、前記各々の行程は、前記味方キャラクタが前記敵キャラクタを攻撃する行程、又は前記敵キャラクタが前記味方キャラクタを攻撃する行程であることを特徴とするゲーム制御方法。

【0133】

［４］ 上記［３］に記載のゲーム制御方法において、前記各々の行程は、前記味方キャラクタが前記敵キャラクタを攻撃する複数回の行程と、前記敵キャラクタが前記味方キャラクタを攻撃する１回の行程とを交互に含むことを特徴とするゲーム制御方法。

【0134】

［５］ 上記［３］又は［４］に記載のゲーム制御方法において、前記各々の行程のうち、前記味方キャラクタが前記敵キャラクタを攻撃する行程が所定回数だけ実行されたときの行程は、前記第二の送信工程が実行可能であることを前記ユーザに提示する行程を含んでいることを特徴とするゲーム制御方法。

【0135】

［６］ 携帯端末にゲームを提供可能なゲーム提供装置であって、前記ゲームに用いる画像データを記憶した記憶手段と、前記携帯端末から送信リクエストを受信した場合、前記画像データと、前記ゲーム内の行程を示す第一の行程データとを前記携帯端末に送信する第一の送信手段と、前記画像データ及び前記行程データに基づいて各々の行程を再生中に、前記行程データを変更するための変更リクエストを当該携帯端末から受信した場合、第二の行程データを含む変更レスポンスを前記携帯端末に送信する第二の送信手段と、を備えたことを特徴とするゲーム提供装置。

【0136】

［７］ ゲームに用いる画像データを記憶した記憶手段を備え、携帯端末にゲームを提供可能なゲーム提供装置に用いられるゲーム制御プログラムであって、前記ゲーム提供装置を、前記携帯端末から送信リクエストを受信した場合、前記画像データと、前記ゲーム内の行程を示す第一の行程データとを前記携帯端末に送信する第一の送信手段、前記画像データ及び前記行程データに基づいて各々の行程を再生中に、前記行程データを変更するための変更リクエストを当該携帯端末から受信した場合、第二の行程データを含む変更レスポンスを前記携帯端末に送信する第二の送信手段、として機能させるためのゲーム制御プログラム。

【符号の説明】

【0137】

１…ネットワーク、２…ゲーム提供装置、４Ａ〜４Ｃ…携帯端末、５…アクセスポイント（ＡＰ）、６…基地局、２１，４１Ａ…記憶装置、２２，４２Ａ…メモリ、２３，４３Ａ…プロセッサ、２４，４４Ａ…通信部、４５Ａ…電子コンパス、４６Ａ…カメラ、４７Ａ…表示部、４８Ａ…タッチパネル。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】