図面 (/)

技術 ゲーム制御方法、ゲーム提供装置及びゲーム制御プログラム

出願人 グリー株式会社
発明者 佐野孝行
出願日 2015年1月28日 (4年5ヶ月経過) 出願番号 2015-014645
公開日 2015年5月28日 (4年1ヶ月経過) 公開番号 2015-097812
状態 特許登録済
技術分野 電子ゲーム機
主要キーワード 明滅状態 行程データ 同一接続 フレームワークプログラム 回復対象 特徴属性 付加的要素 変更リクエスト
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2015年5月28日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (17)

課題

リクエストレスポンス方式を用いて高画質の画像データをクライアント側に提供でき、クライアント側で高画質の画像データを作成する負荷が無く、より一層、通信量を低減させる。

解決手段

ゲーム提供装置2は、画像データと、第一の行程データとを携帯端末4Aに送信する。携帯端末4Aは、画像データ及び行程データに基づいて各々の行程再生するゲームを実行する。ゲーム提供装置2は、携帯端末4Aから受信した変更リクエストに応じて、第二の行程データを含む変更レスポンスを携帯端末4Aに送信し、第二の行程データに基づくゲームを携帯端末4Aに実行させる。

概要

背景

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

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

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

概要

リクエスト・レスポンス方式を用いて高画質の画像データをクライアント側に提供でき、クライアント側で高画質の画像データを作成する負荷が無く、より一層、通信量を低減させる。ゲーム提供装置2は、画像データと、第一の行程データとを携帯端末4Aに送信する。携帯端末4Aは、画像データ及び行程データに基づいて各々の行程再生するゲームを実行する。ゲーム提供装置2は、携帯端末4Aから受信した変更リクエストに応じて、第二の行程データを含む変更レスポンスを携帯端末4Aに送信し、第二の行程データに基づくゲームを携帯端末4Aに実行させる。

目的

このような従来の通信方式では、通信トラフィック(通信量)を圧迫するため、例えば、キャラクタを動かすためのゲームオブジェクト画像のような高画質の画像データをクライアント側に提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

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

請求項3

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

請求項4

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

請求項5

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

請求項6

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

請求項7

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

技術分野

背景技術

0002

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

0003

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

0004

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

先行技術

0005

特許第5132825号公報(第0008−0009段落及び第0012段落)

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

0006

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

0007

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

0008

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

0009

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

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

0010

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

発明の効果

0011

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

図面の簡単な説明

0012

本発明の概要を説明するための模式図である。
本発明の概要におけるフレンドユーザ情報の一例を示す模式図である。
本発明の概要における最終カード情報の一例を示す模式図である。
本発明の概要におけるゲーム画面の一例を示す模式図である。
本発明の概要における種族カードの情報の一例を示す模式図である。
本発明の概要における味方キャラクタの情報の一例を示す模式図である。
本発明の概要における敵キャラクタの情報の一例を示す模式図である。
本発明の概要における行程データの作成に用いる条件の一例を示す模式図である。
本発明の概要における行程データの一例を示す模式図である。
本発明の第1の実施形態に係るゲーム制御方法が適用されたゲームシステム及びその周辺構成の一例を示す模式図である。
同実施形態におけるゲーム提供装置の機能ブロック構成の一例を示す模式図である。
同実施形態における携帯端末の機能ブロック構成の一例を示す模式図である。
同実施形態における準備段階の動作を説明するためのフローチャートである。
同実施形態におけるゲーム段階の動作を説明するためのシーケンス図である。
本発明の第2の実施形態における種族カードの情報の一例を示す模式図である。
本発明の第3の実施形態における味方キャラクタの情報の一例を示す模式図である。

実施例

0013

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

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

次に、以上のような任意の付加的要素(a)〜(i)のうち、(b)キャラクタを動かす行程データ、(d)カードのデッキ、(e)カード枚数に応じた攻撃、(g)攻撃チャージ、及び(i)スキルチャージ、を用いたゲームの一例について説明する。例えば、図4に示すように、味方キャラクタP1〜P3と、敵キャラクタEn1〜En5とが草原で対戦している場面を表す対戦画面G1と、各種族カードC1〜C6を明示したデッキを表すデッキ画面G2とを含むゲーム画面が表示されていたとする。各キャラクタP1〜P3、En1〜En5下方の太い横棒は、斜線領域によりHPを表わしている。種族カードC1〜C6は、図5(a)に示すように、カードID、種族名、属性名及びスキルチャージ(初期値)が互いに関連付けられたカード情報により表示される。カード情報は、図5(b)に示すカード管理情報から選択された情報であり、デッキ情報ともいう。味方キャラクタP1〜P3は、図6(a)に示すように、味方キャラクタID、HP、種族名及びカード枚数が互いに関連付けられた味方キャラクタ情報により表示される。味方キャラクタ情報は、図5(a)に示すカード情報内の種族名の個数に応じたカード枚数を、図6(b)に示す味方キャラクタ管理情報に関連付けた情報である。敵キャラクタEn1〜En5は、図7に示すように、敵キャラクタID、HP及び攻撃チャージ(初期値)が互いに関連付けられた敵キャラクタ情報により表示される。カード管理情報、味方キャラクタ管理情報及び敵キャラクタ情報は、予めゲーム制御プログラムに記述されている。

0034

ここで、デッキに投入されている各種族カードに応じて、攻撃する味方キャラクタが変化する例に付いて述べる。種族と味方キャラクタP1〜P3との組合せは、例えば、図6(a)及び次の通りとする。
種族組合せ:P1…獣族、P2…精霊族、P3…人間族。

0035

このとき、味方キャラクタP1〜P3は、種族カードの枚数に応じた攻撃を行う(段階攻撃)。具体的には例えば、次に示すように段階攻撃を行うようにすればよい。
0枚…画面の隅で怯えている動作(モーション)で、順番が来ても攻撃しない。
1〜2枚…順番が来たら、弱い攻撃を行う動作。
3〜4枚…順番が来たら、普通の攻撃を行う動作。
5〜6枚…順番が来たら、強い攻撃を行う動作。

0036

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

0037

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

0038

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

0039

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

0040

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

0041

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

0042

図9に示す行程データの場合、11ステップ目で、味方キャラクタP1,P2,P3の攻撃回数が合計8回目になり、カードC1,C6のスキルチャージが0になる。このため、11ステップ終了後に、カードC1,C6がスキル発動可能状態になり、カードC1,C6が明滅する。カードC1,C6の明滅状態(スキル発動可能状態)は、スキル発動されるまで継続する。

0043

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

0044

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

0045

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

0046

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

0047

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

0048

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

0049

携帯端末4A〜4Cは、上記基地局6を介してのネットワーク1との接続に加えて、例えばIEEE802.11a/b/g/n規格の無線LAN(Local Area Network)であるWi−Fi(登録商標)を優先的に選択可能として、上記アクセスポイント5と相互接続が可能であるものとする。

0050

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

0051

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

0052

上記ゲーム提供装置2と携帯端末4A〜4Cそれぞれの機能ブロック構成について図11乃至図12を参照して述べる。

0053

ゲーム提供装置2は、携帯端末4A〜4Cにゲームを提供可能な装置であり、図11に示すように、記憶装置21、メモリ22、プロセッサ23及び通信部24を備えている。記憶装置21及びメモリ22は記憶手段を構成している。プロセッサ23は、記憶手段にアクセス可能な処理装置を構成している。

0054

記憶装置21は、ゲームを実現するためのゲーム制御プログラムp_s3等を記憶するものであり、例えば、ハードディスクドライブ(HDD)、光ディスクドライブ、DVD、MOなどの大容量記憶装置である。この記憶装置21には、OS(オペレーティングシステム)p_s0、サーバ側JS実行環境プログラムp_s1、A社フレームワークプログラムp_s2及びゲーム制御プログラムp_s3等が記憶されている。ゲーム制御プログラムp_s3は、ゲームに用いる画像データを含んでいる。

0055

OS p_s0は、ゲーム提供装置2の基本的な機能を実現するためのプログラムである。

0056

サーバ側JS実行環境プログラムp_s1は、プロセッサ23により実行され、後述するサーバ側JS実行環境S1を実現するためのプログラムである。

0057

A社フレームワークプログラムp_s2は、プロセッサ23により実行され、後述するA社フレームワークS2を実現するためのプログラムである。

0058

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

0059

また、ゲーム制御プログラムp_s3は、任意のプレイ内容に関するゲーム機能の他に、以下の機能(f1)〜(f2)をプロセッサ23に実現させるためのプログラムを含んでいる。

0060

(f1)携帯端末4Aから送信リクエストを受信した場合、画像データと、当該ゲーム内の行程を示す第一の行程データとを携帯端末4Aに送信する第一の送信機能

0061

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

0062

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

0063

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

0064

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

0065

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

0066

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

0067

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

0068

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

0069

通信部24は、ネットワーク1を介した携帯端末4A〜4Cなどの外部装置との通信の制御を司る。

0070

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

0071

携帯端末4Aは、図12に示すように、記憶装置41A、メモリ42A、プロセッサ43A、通信部44A、電子コンパス45A、カメラ46A、表示部47A及びタッチパネル48Aを備えている。各部41A〜48Aの説明は、符号の末尾AをB又はCに読み替えることにより、他の携帯端末4Bの各部41B〜48Bの説明又は他の携帯端末4Cの各部41C〜48Cの説明として読み替え可能となっている。

0072

記憶装置41Aは、ゲームを実現するためのクライアントサイドのゲーム制御プログラムp_c4等を記憶するものであり、例えば、ハードディスクドライブ(HDD)などの大容量記憶装置である。この記憶装置41Aには、OS(オペレーティングシステム)p_c0、アプリケーション実行環境プログラムp_c1、A社DB接続キットプログラムp_c2、A社フレームワークプログラムp_c3及びゲーム制御プログラムp_c4が記憶されている。

0073

OS p_c0は、携帯端末4Aの基本的な機能を実現するためのプログラムである。

0074

アプリケーション実行環境プログラムp_c1は、プロセッサ43Aにより実行され、後述するアプリケーション実行環境C1を実現するためのプログラムである。

0075

A社DB接続キットプログラムp_c2は、プロセッサ43Aにより実行され、後述するA社DB接続キットC2を実現するためのプログラムである。

0076

A社フレームワークプログラムp_C3は、プロセッサ43Aにより実行され、後述するA社フレームワークC3を実現するためのプログラムである。

0077

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

0078

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

0079

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

0080

通信部44Aは、ネットワーク1を介したゲーム提供装置2などの外部装置との通信の制御を司る。また、通信部43は、無線LAN、ブルートゥース(登録商標)、WiFiなどの無線通信機能をも有する。

0081

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

0082

カメラ46Aは、撮像機能を有し、撮像した画像を記憶装置41Aに格納する。

0083

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

0084

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

0085

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

0086

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

0087

これと共に、携帯端末4A〜4Cがゲーム提供装置2との通信を行う部分に関しては、A社が開発した(ソフトウェア)クライアントサイドのA社フレームワーク(プログラムp_c3)がインストールされる。

0088

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

0089

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

0090

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

0091

<準備段階>
始めに、携帯端末4Aでは、図13に示すように、ユーザの操作により、デッキ構築を開始するためのデッキ構築開始リクエストをゲーム提供装置2に送信する(ST1)。

0092

ゲーム提供装置2では、プロセッサ23が、このデッキ構築開始リクエストに応じて、図5(b)に示すカード管理情報に基いて、カードID、種族名及び属性名を含む種族カードのリスト情報を含むレスポンスを携帯端末4Aに送信する。

0093

携帯端末4Aでは、このリスト情報を表示し、ユーザの操作により、リスト情報から5枚の種族カードを選択し、選択結果を示すリクエストをゲーム提供装置2に送信する(ST2)。

0094

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

0095

携帯端末4Aでは、このフレンドのユーザIDを表示し、ユーザの操作により、一人のフレンドのユーザIDを選択し(ST3)、選択結果を示すリクエストをゲーム提供装置2に送信する。

0096

ゲーム提供装置2では、プロセッサ23が、このリクエストを受けると、図3に示す最終カード情報に基いて、フレンドのユーザIDに関連付けられたリーダカードIDを読出すと共に、このリーダカードIDに対応する1枚の種族カードをリスト情報から選択する。この選択は、フレンドユーザの最終プレイ時のリーダカードを6枚目のカードとする処理に相当する(ST4)。

0097

しかる後、ゲーム提供装置2では、プロセッサ23が、選択された合計6枚の種族カードの情報からなるデッキ情報を構築し(ST5)、当該デッキ情報を含むレスポンスを携帯端末4Aに送信する。

0098

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

0099

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

0100

携帯端末4Aでは、この各クエストの案内情報を表示し、ユーザの操作により、1つのクエストを選択し(ST6)、選択結果を含む送信リクエストをゲーム提供装置2に送信する。

0101

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

0102

いずれにしても、携帯端末4Aでは、ゲーム開始前に、クエストの全データを取得し(ST7)、準備段階の処理を終了する。

0103

<ゲーム段階>
携帯端末4Aでは、図14に示すように、当該画像データ及び行程データに基づいて各々の行程を再生するクエストを実行する(ST11)。当該クエストは、図4に示すように、ユーザの側の味方キャラクタP1〜P3と、ゲーム提供装置2の側の敵キャラクタEn1〜En5とが対戦する対戦ゲームである。行程データが示す各々の行程は、味方キャラクタP1〜P3が敵キャラクタEn1〜En5を攻撃する行程、又は敵キャラクタEn1〜En5が味方キャラクタP1〜P3を攻撃する行程となっている。

0104

すなわち、当該クエストは、例えば図4に示す画面G1,G2の表示中、図9に示す行程データに基づいて、画面G1内の各キャラクタP1〜P3、En1〜En5の攻撃及びダメージを制御することにより、実行されている。図9に示す行程データは、味方キャラクタP1〜P3が敵キャラクタEn1〜En5を攻撃する複数回の行程と、敵キャラクタEn1〜En5が味方キャラクタP1〜P3を攻撃する1回の行程とを交互に含んでいる。また、携帯端末4Aは、この行程データに基づいて、例えば、味方キャラクタP1〜P3が敵キャラクタEn1〜En5を攻撃する行程が11回だけ実行されたとき、スキル発動可能状態をカードC1,C6の明滅によりユーザに提示する。

0105

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

0106

ゲーム提供装置2では、プロセッサ23が、当該行程データを変更するための変更リクエストを当該携帯端末4Aから受信する(ST13)。

0107

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

0108

携帯端末4Aでは、当該第二の行程データに基づいて各々の行程を再生するクエストを実行する(ST15)。

0109

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

0110

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

0111

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

0112

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

0113

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

0114

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

0115

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

0116

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

0117

<第2の実施形態>
次に、本発明の第2の実施形態について説明する。

0118

本実施形態は、第1の実施形態の変形例であり、図15(a)及び図15(b)に示すように、カードID毎に、行程データが示す各々の行程の間隔の実行速度v〜3vを示すスピード属性を関連付けた構成である。なお、図15(b)はカード管理情報を示し、図15(a)はカード管理情報から選択されたカード情報(デッキ情報ともいう)を示す。

0119

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

0120

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

0121

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

0122

<第3の実施形態>
次に、本発明の第3の実施形態について説明する。

0123

本実施形態は、第1又は第2の実施形態の変形例であり、図16(a)及び図16(b)に示すように、味方キャラクタID毎に、攻撃重視、防御重視又は魔法重視を示す行動の特徴属性を関連付けた構成である。なお、図16(b)は味方キャラクタ管理情報を示す。図16(a)は、図5(a)又は図15(a)に示すカード情報内の種族名の個数に応じたカード枚数を味方キャラクタ管理情報に関連付けた味方キャラクタ情報を示す。

0124

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

0125

以上のような構成によれば、ゲーム提供装置2が、図16(a)に示す情報に基いて、味方キャラクタ毎に行動の特徴を変えた行程データを作成し、味方キャラクタID毎に、特徴が異なる行程データを携帯端末4Aに提供できるので、第1又は第2の実施形態の効果に加え、興趣性を向上させることができる。

0126

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

0127

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

0128

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

0129

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

0130

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

0131

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

0132

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

0133

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

0134

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

0135

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

0136

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

0137

1…ネットワーク、2…ゲーム提供装置、4A〜4C…携帯端末、5…アクセスポイント(AP)、6…基地局、21,41A…記憶装置、22,42A…メモリ、23,43A…プロセッサ、24,44A…通信部、45A…電子コンパス、46A…カメラ、47A…表示部、48A…タッチパネル。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 株式会社セガゲームスの「 情報処理装置及びプログラム」が 公開されました。( 2019/05/16)

    【課題】自動回復後でも時間回復分のポイントを手間なく得られるようにする。【解決手段】本発明は、ユーザーの所持ポイントを記憶するユーザー情報記憶部と、ユーザーの所持ポイントを消費することによってゲームプ... 詳細

  • 株式会社セガゲームスの「 情報処理装置及びプログラム」が 公開されました。( 2019/05/16)

    【課題】保留されたコンテンツを適切なタイミングで利用できるようにする情報処理装置を提供する。【解決手段】ユーザー毎に交換元となるコンテンツと交換先となるコンテンツが関連付けて設定されたトレード情報を記... 詳細

  • 株式会社ドリコムの「 ゲームシステム、データ削除方法、ならびに、プログラム」が 公開されました。( 2019/05/16)

    【課題】ユーザに応じて適切な要素データを残しつつ、ゲームデータが増大するのを抑制できるゲームシステム等を提供する。【解決手段】制御部340は、未使用のキャラクタデータがゲームにおいて使用されると、使用... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ