JP5608929B1 - ゲームサーバ、ゲーム制御方法、ゲームプログラム、記録媒体及びゲームシステム - Google Patents

Abstract

【課題】実ユーザが、端末に搭載された電池の電池残量を気にすることなくゲームプレイに集中することが可能なゲームサーバを提供する。【解決手段】通信ネットワークを介して接続された端末３から、端末３に提供されるゲームに対する操作データを受信する受信部１１ａと、端末３に提供されるゲーム画像が遷移する遷移形式を、静止画遷移形式又はアニメーション遷移形式に決定する遷移形式決定部１０５と、決定した遷移形式でゲーム画像を表示するデータを、端末３に送信する表示用データ送信部４３と、を備え、受信部１１ａは、端末３に電力供給する電池３４に関するデータを受信し、遷移形式決定部１０５は、端末３から受信した電池に関するデータに基づき電池３４の電池残量が所定値未満である場合には、ゲーム画像の遷移形式を静止画遷移形式に決定することを特徴とする。【選択図】図５

Description

本発明は、通信ネットワークを介して接続された各端末からの操作データに応じて、ゲーム上に存在する仮想ユーザの行動を制御するゲームサーバ、当該ゲームサーバで提供するゲーム上に存在する仮想ユーザの行動を制御するゲーム制御方法、当該ゲーム制御方法をコンピュータに実行させるためのゲームプログラム、当該ゲームプログラムを記録した記録媒体、及び、当該ゲームサーバと端末から構成されるゲームシステムに関する。

近年、スマートフォンに代表される高機能な携帯端末の普及に伴い、ソーシャルネットワーキングサービス（ＳＮＳ）を利用して提供されるゲームとして、ソーシャルネットワークゲーム（以下、ソーシャルゲームという。）が普及している。ソーシャルゲームは、実ユーザが端末を操作してゲームサーバにアクセスし、ゲームサーバによって構築された仮想空間に存在する仮想ユーザを操作することによって、同一の仮想空間に存在する他の仮想ユーザと交流しながらオンラインでプレイするゲームである。

このようなソーシャルゲームの一態様として、仮想ユーザの行動やストーリーなどに基づき、例えばクエストパート、バトルパート、強化パート、ガチャパートなどの複数のゲームパートを組み合わせることで、一つのゲームとして構成されるものがある。ゲームパートを組み合わせたソーシャルゲームの一例として、特許文献１には、ガチャパートに相当するゲームパートでサッカー選手を示す選手カードを集め、強化パートに相当するゲームパートで集めた選手カードで示されるサッカー選手を育成し、バトルパートに相当するゲームパートで他のユーザやコンピュータと対戦するゲームが記載されている。

ソーシャルゲームの進行を表すゲーム画像は、具体的には次のようにして端末に表示される。すなわち、端末は、クリック操作またはタップ操作に応じて、その都度ゲームサーバから、ＧＩＦ画像などのラスタ形式の静止画像を取得して、取得した静止画像をゲーム画像として表示している。このような静止画像の切替表示では、クリック操作又はタップ操作に応じて予め決まった順番で端末に表示される静止画像が切り替わることとなる。

また、上記の静止画像の切替表示以外にも、ソーシャルゲームでは、ゲームの進行に臨場感を持たせるためアニメーション画像をゲーム画像として用いるものがある。例えばJavaScript（登録商標）などでラスタ形式の静止画像を連続表示することでゲーム進行をアニメーショで表示することができる。他にも、アドビシステムズ社が開発したAdobe Flash（登録商標）を利用したベクタ画像を用いて、ゲーム進行をアニメーションで表示することもできる。このようなアニメーション表示では、クリック操作やタップ操作に応じて表示画像の一部を選択し、スライド操作やフリック操作に応じて表示画像の一部を付加、削除、変形させるなどの複雑な描画処理が可能で、ゲーム画面をより複雑に遷移することができる。

特開２０１３−０５９５６４号公報

しかしながら、上述したアニメーション表示では、静止画像の切替表示に比べて、端末側でゲーム画面を表示するのに必要な処理量が多く、端末に搭載された電力供給用電池の電池残量の減りが速い傾向にある。このような電池残量の減り方の違いは、アニメーション表示でゲーム画面が表現されるゲームが、静止画像の切替表示でゲーム画面が表現されるゲームに比べて、実ユーザにとって敬遠される原因となっていた。

本発明は、上述した課題に鑑みてなされたものであり、実ユーザが、端末に搭載された電池の電池残量を気にすることなくゲームプレイに集中することが可能なゲームサーバ、ゲームサーバで提供するゲームの進行を制御するゲーム制御方法、ゲームプログラム、ゲームプログラムを記録した記録媒体及びゲームシステムを提供することを目的とする。

上述した従来の課題を解決するため、本発明は、以下の手段を有する。

（１）通信ネットワークを介して接続された端末から、端末にゲームを提供するゲームサーバにおいて、ゲームに対して実ユーザが操作した操作データを、端末から受信する受信部と、前記端末の表示部に前記ゲームの進行内容及び操作内容を表示するゲーム画像の遷移形式を、実ユーザの操作に応じて静止画を所定の順番で切り替えて表示することによりゲーム画像が遷移する静止画遷移形式、又は、実ユーザの操作に応じて図面情報からアニメーションを作図して表示することによりゲーム画像が遷移するアニメーション遷移形式に決定する遷移形式決定部と、決定した遷移形式でゲーム画像を表示するデータを、端末に送信する表示用データ送信部と、を備え、受信部は、端末に電力供給する電池に関するデータをさらに受信し、遷移形式決定部は、受信した電池に関するデータに基づき電池残量が所定値未満である場合には、ゲーム画像の遷移形式を静止画遷移形式に決定することを特徴とする。

端末から受信した操作データには、例えばクエスト、バトルなどの各種動作の実行要求に関する情報が含まれる。さらに、端末から受信したデータには、端末に電力供給する電池の電池残量、電圧レベル及び定格容量などの電池に関する情報が含まれる。

静止画遷移形式とは、端末が、クリック操作又はタップ操作に応じて、その都度ゲームサーバから取得した静止画を切り替えて表示することにより、ゲーム画像が遷移する形式である。つまり、静止画遷移形式では、クリック操作又はタップ操作に応じて他の静止画に表示が切り替わることとなる。

例えば、仮想ユーザが敵とバトルするゲーム進行を表現する場合、表示を切り替える前の第１の静止画が、バトル実行を受け付ける操作受付画像であり、表示を切り替えた後の第２の静止画が、バトル実行後の敵に与えたダメージなどを示すバトル結果画像である。このように、第１の静止画と第２の静止画との間にアニメーションが表示されることなく、第１の静止画から第２の静止画に直接切り替わることで、バトルの進行を表現することができる。

上記の通り、静止画遷移形式では、操作に応じて１枚１枚切り替わりながら決まった順番で表示されるだけなので実ユーザに作業的な印象を与えかねないという欠点がある。このような欠点がある反面、静止画遷移形式では、第１の静止画から第２の静止画に切り替わる間にアニメーションが表示されないので、後述するアニメーション遷移形式と比べて、描画処理が軽く電池残量が減りにくいため、電池残量が少ない状況でゲーム操作を行うのに適している。

一方、アニメーション遷移形式とは、アニメーションの表示によりゲーム画像が遷移する形式である。例えば、仮想ユーザが敵とバトルするゲーム進行を表現する場合、アニメーション遷移形式では、上述した静止画遷移形式のように静止画を切り替えることはなく、アニメーションの表示によりゲーム画像が遷移するので、バトル実行の受付からバトル結果の間に、敵に攻撃する様子、例えば敵が変形したり倒れたりする様子をアニメーションにより表現することができる。

すなわち、アニメーション遷移形式は、タップ操作及びフリック操作に応じてゲーム画像の一部を選択して選択箇所を変形及び移動させるなど、静止画遷移形式に比べて複雑な描画処理が可能であるため、実ユーザに比較的複雑な操作や画像演出を提供できるという利点がある。このような利点がある反面、アニメーション遷移形式で表現されるゲーム画像は、静止画遷移形式に比べて、端末側でゲーム画面を表示するのに必要な処理量が多く、端末に搭載された電力供給用電池の電池残量の減りが速いため、電池残量に余裕がある状況下でゲーム操作を行うのに適している。

このような静止画遷移形式及びアニメーション遷移形式の特徴を利用して、遷移形式決定部は、受信した電池に関するデータに基づいて、電池残量を取得するか、もしくは当該データから電池残量情報を算出し、取得若しくは算出した電池残量が所定値未満である場合には、ゲーム画像を遷移する遷移形式を静止画遷移形式に決定する。例えば、遷移形式決定部は、電池残量が３０％未満など、電池残量が少なくなった場合には、直前まで遷移形式がアニメーション遷移形式であっても、静止画遷移形式に変更する。

上記の通り、本態様によれば、電池残量が所定値未満になると電池残量の減りが比較的少ない静止画遷移形式のゲーム画面を端末に表示することにより、実ユーザに対して、端末に搭載された電池の電池残量を気にさせることなく、ゲームプレイに集中させることが可能となる。すなわち、本態様によれば、端末に搭載された電力供給用電池の電池残量の減りが早いといった理由で敬遠されることなく、アニメーション遷移形式のゲーム画面で表現されるゲーム進行を多くの利用者に楽しんでもらうことが可能となる。

（２）遷移形式決定部は、電池残量が所定値以上の場合には、電池残量の増加に伴って段階的に静止画遷移形式からアニメーション遷移形式に切り換えることを特徴とする。

本態様によれば、電池残量の増加に伴って段階的に静止画遷移形式からアニメーション遷移形式に切り換える。具体例として、ゲームがクエスト、バトル、カード合成など、複数のゲームパートから構成されている場合、電池残量の増加に伴って、操作頻度が最も低いゲームパートの順番、例えばカード合成、バトル、クエストの順番でゲーム画面を静止画遷移形式からアニメーション遷移形式に切り換える。また、電池残量の減少に伴って段階的に遷移形式を切り換えるのであれば、上記のような操作頻度によらず、例えば各ゲームパートを構成するゲーム画像全体に対するアニメーション遷移形式のゲーム画像が占める割合に基づいて切り替えてもよい。具体的には、ゲームの世界観、ゲーム設計者の意図などによって、クエスト、バトル、カード合成の順番でアニメーション遷移形式のゲーム画像が占める割合が少ない場合、クエスト、バトル、カード合成の順番で、段階的にゲーム画面を静止画遷移形式からアニメーション遷移形式に切り換えてもよい。

本態様によれば、上記具体例で示したとおり、電池残量の増加に伴って段階的に静止画遷移形式からアニメーション遷移形式に切り換えることにより、全てのゲームパートのゲーム画像を静止画遷移形式からアニメーション遷移形式に同時に切り換えるのに比べて、端末の電池を低充電状態から通常の充電状態に早く復帰することができる。つまり、本態様によれば、充電動作により電池残量が所定値以上に復帰した後も、実ユーザに対して、端末に搭載された電池の電池残量を気にさせることなくゲームプレイに集中させることが可能となる。

（３）端末に提供されるゲームは、複数のゲームパートから構成されており、受信部は、端末から、一のゲームパートを進行するための操作データを受信し、遷移形式決定部は、電池残量が所定値以上の場合には、電池残量の増加に伴って、操作頻度が最も低いゲームパートから順番に、各ゲームパートに対応した遷移形式を静止画遷移形式からアニメーション遷移形式に切り換えることを特徴とする。

本態様によれば、ゲームパートの操作頻度を考慮して、操作頻度が最も低いゲームパートから順番に、静止画遷移形式からアニメーション遷移形式に切り替えることにより、例えば、操作頻度を考慮せずに、任意のゲームパートに関するゲーム画像について静止画遷移形式からアニメーション遷移に切り替える場合に比べて、電池残量が所定値を上下することで頻繁に遷移形式が切り替わる事態を確実に回避できる。換言すると、電池残量の変動に応じて遷移形式が頻繁に切り替わると、実ユーザにとってゲームをプレイしにくいような事態が生じる。本態様では、このような事態を確実に回避できる。

（４）遷移形式決定部は、電池残量が所定値未満の場合には、電池残量の減少に伴って段階的にアニメーション遷移形式から静止画遷移形式に切り換えることを特徴とする。

本態様によれば、具体例として、ゲームがクエスト、バトル、カード合成など、複数のゲームパートから構成されている場合、電池残量の減少に伴って、操作頻度が最も高いゲームパートの順番、例えばクエスト、バトル、カード合成の順番で、段階的にゲーム画面をアニメーション遷移形式から静止画遷移形式に切り換える。また、電池残量の減少に伴って段階的に遷移形式を切り換えるのであれば、上記のような操作頻度に限らず、例えば個々のゲームパートを構成するゲーム画像全体に対するアニメーション遷移形式のゲーム画像が占める割合に基づいて切り替えてもよい。具体的に、ゲームの世界観、ゲーム設計者の意図などによって、カード合成、バトル、クエストの順番でアニメーション遷移形式のゲーム画像が占める割合が多い場合、カード合成、バトル、クエストの順番で、段階的にゲーム画面をアニメーション遷移形式から静止画遷移形式に切り換えてもよい。

ここで、全てのゲームパートのゲーム画像をアニメーション遷移形式から静止画遷移形式に同時（同時期）に切り換えると、今まで複雑な画面演出が単調な画面演出に大きく切り替わるため、実ユーザのゲームを進行する意欲を大きく失ってしまう。一方、本態様によれば、上記具体例で示したとおり、電池残量の減少に伴って段階的にアニメーション遷移形式から静止画遷移形式に切り換えることにより、全てのゲームパートのゲーム画像をアニメーション遷移形式から静止画遷移形式に同時に切り換えるのに比べて遷移形式の切り替えにより与える違和感を軽減でき、電池残量が少なくなってもゲームを楽しんでもらう環境を提供できる。

（５）端末に提供されるゲームは、複数のゲームパートから構成されており、受信部は、端末から、一のゲームパートを進行するための操作データを受信し、遷移形式決定部は、電池残量が所定値未満の場合には、電池残量の減少に伴って、操作頻度が高いゲームパートから順番に、各ゲームパートに対応した遷移形式をアニメーション遷移形式から静止画遷移形式に切り換えることを特徴とする。

本態様によれば、ゲームパートの操作頻度を考慮して、操作頻度が最も高いゲームパートから順番に、アニメーション遷移形式から静止画遷移形式に切り替えることにより、例えば操作頻度を考慮せずに、任意のゲームパートに関するゲーム画像についてアニメーション遷移から静止画遷移形式に切り替える場合に比べて、実ユーザに電池残量を気にさせることなく、ゲームに集中させることができる。換言すると、電池残量が所定値未満となった後も、操作頻度が高いゲームパートに関する遷移形式がなかなか静止画遷移形式に切り替わらないと、比較的短時間で電池残量がなくなる事態が生じる。一方、本態様によれば、操作頻度の高いゲームパートから、電力消費量が少ない静止画遷移形式に切り替えるので、比較的短時間で電池残量がなくなる事態を回避し、実ユーザに対してゲームに集中させることができる。

（６）遷移形式が前記静止画遷移形式に決定された後に、現在のゲームの進行内容から特定の進行内容に到達するまでの電力消費量を推測する電力消費量推測部と、推測した電力消費量に基づいて、特定の進行内容に進行できないように制限する進行内容制限部と、を備えることを特徴とする。

本態様によれば、現在の進行内容から、例えばクエストパートでゴール地点に辿り着いたり、ゲーム上でボスと呼ばれる特定の敵とバトルしたりするなど、ゲーム進行上特に盛り上がる「見せ場」に当たる進行内容に到達するまでの電力消費量を推測する。上記のような「見せ場」に当たる進行内容については、電池残量に余裕がある状況下で、アニメーション遷移形式を用いて高揚感や躍動感を与える画面演出を実ユーザに提供することが望ましい。

そこで、本態様によれば、例えば、ボスとバトルするまでに、残り２体の他の敵とバトルする必要がある場合には、当該２体の他の敵とバトルに要する消費電力を推定する。そして、本態様によれば、上記具体例のように推測した電力消費量に基づき、例えば電池残量に余裕がなければ、ボスと対戦させなかったりするようにゲーム進行を制限する。以上のようにして、本態様によれば、電池残量に余裕がある適切な状況下において、高揚感や躍動感を与える画面演出を実ユーザに提供することができる。

（７）電池残量が所定値未満である場合に、静止画遷移形式又はアニメーション遷移形式の選択を求める選択操作情報を端末に送信する遷移形式選択情報送信部を更に備え、受信部は、選択操作情報に従って静止画遷移形式又はアニメーション遷移形式を選択したことを示す選択情報を含む操作データを更に受信し、遷移形式決定部は、電池残量が所定値未満であって、選択情報が静止画遷移形式を選択したことを示す場合に、ゲーム画像の遷移形式を静止画遷移形式に決定することを特徴とする。

本態様によれば、電池残量が所定値未満である場合、実ユーザに対して遷移形式の選択を求めてから、表示用データを静止画遷移形式で送信することで、端末に搭載された電池の電池残量の減り具合を実ユーザに喚起しながら、電池の消費が比較的少ない静止画遷移形式のゲーム画面でゲームを継続させることができる。

（８）ゲーム画像の遷移形式をアニメーション遷移形式に決定した場合、電池残量の減少に伴って、ゲーム画像により操作可能な操作内容を段階的に制限する操作内容設定部を更に備えることを特徴とする。

本態様によれば、例えばフリック操作に応じてフリック方向に敵の部位を分離させ、タップ操作に応じてタップ箇所を破壊箇所として選択するなどの操作内容が設定されていた場合には、電池残量の減少に伴って、フリック操作を無効にしたり、タップ操作が可能な時間間隔を長くしたりするなど、操作内容を段階的に制限する。このようにして電池残量の減少に伴って操作内容を段階的に制限することにより、描画処理をできるだけ軽くて電池残量の消耗を抑えながら、実ユーザの希望により選択されたアニメーション遷移形式のゲーム画像を表示することができる。

（９）前記静止画遷移形式のゲーム画像はラスタ画像から構成され、前記アニメーション遷移形式のゲーム画像はベクタ画像から構成されることを特徴とする。

ラスタ画像は、ビットマップ画像など、画素が線上に並んだもの（ラスタ線）の集合体によって表現される画像である。一方、ベクタ画像は、点の位置、点と点とを結ぶ線、線の太さ及び色、曲線であれば曲率など、幾何学的な図面情報によって表現される画像である。

ラスタ画像とベクタ画像とを比較すると、ラスタ画像は、ベクタ画像と異なりメモリに展開したデータを出力するだけでゲーム画像を出力できるため、電池残量が少ない場合に適している。これに対して、ベクタ画像は、ラスタ画像に比べてより複雑な描画処理が可能なため、電池残量に余裕があり複雑な操作や画像演出を実ユーザに提供できる状況に適している。

本態様によれば、ラスタ画像とベクタ画像との利点を考慮し、それぞれ静止画遷移形式とアニメーション遷移形式とに適用することで、電池残量に適したゲーム進行を実現することができる。

（１０）以上のような本発明は、いずれの態様においても、上記ゲームサーバの発明を、そのゲームサーバで提供するゲームの進行を制御するゲーム制御方法、ゲームプログラム、ゲームプログラムを記録した記録媒体及びゲームシステムとして捉えることも可能である。

本発明によれば、実ユーザが、端末に搭載された電池の電池残量を気にさせることなく、ゲームプレイに集中することが可能なゲームサーバ、ゲームサーバで提供するゲームの進行を制御するゲーム制御方法、ゲームプログラム、ゲームプログラムを記録した記録媒体及びゲームシステムを提供することができる。

本発明が適用されたゲームシステムのシステム構成を示す図である。 本発明が適用されたゲームサーバが提供するソーシャルゲームの構成について説明するための図である。 本発明が適用されたゲームサーバのハードウェア構成を示す図である。 第１の実施形態に係るゲームサーバにより実現される構成を示す図である。 バトルパート処理部の具体的な構成を説明するための図である。 ゲームデータ記憶部が記憶するデータについて説明するための図である。 仮想ユーザが敵との対戦の開始時に表示されるゲーム画像の一例を示す図である。 静止画遷移形式のゲーム画像により実現される対戦処理の進行内容を示す図である。 アニメーション遷移形式のゲーム画像により実現される対戦処理の進行内容を示す図である。 操作内容データテーブルの具体例について説明するための図である。 第１の実施形態に係るゲームサーバにより実行される処理を説明するためのフローチャートである。 第１の実施形態におけるゲームパート処理を説明するためのフローチャートである。 第１の実施形態に係るゲームサーバにより実行される処理の第１の変形例を説明するためのフローチャートである。 第１の実施形態に係るゲームサーバにより実行される処理の第２の変形例を説明するためのフローチャートである。 第２の実施形態に係るゲームサーバにより実現される構成を示す図である。 第２の実施形態に係るゲームサーバにより実行される処理を説明するためのフローチャートである。 第３の実施形態に係るゲームサーバにより実現される構成を示す図である。 静止画遷移形式又はアニメーション遷移形式の選択を求めるゲーム画像の具体例を示す図である。 第３の実施形態に係るゲームサーバにより実行される処理を説明するためのフローチャートである。 第３の実施形態に係るゲームパート処理の変形例を説明するためのフローチャートである。

本発明を実施するための形態（以下、本実施形態という。）について具体例を示して説明する。本実施形態は、ゲームサーバと通信ネットワークを介して接続された端末にゲームを提供するゲームシステムに関する。具体的には、図１に示すように、本実施形態のゲームシステムＧは、実ユーザにゲームを提供するゲームサーバ１と、ゲームサーバ１と通信ネットワークであるインターネット２を介して接続された端末３ａ、３ｂ、３ｃ、・・・（以下、総称して端末３ともいう。）と、を備える。

以下では、まず、実施形態の説明に先立って、本実施形態において用いる用語の定義を明確にし、さらに本実施形態において扱うソーシャルゲームの概要について説明した後、ゲームシステムＧの構成及び処理内容について具体的に説明する。

（１）用語の定義
本実施形態において用いる用語の定義は以下の通りである。

「実ユーザ」とは、端末を操作する実体、すなわち人に当たるものをいう。一方、「仮想ユーザ」は、「実ユーザ」の端末におけるボタンやタッチ操作によって、実ユーザに成り代わって仮想空間を行動可能な仮想実体をいう。この「仮想ユーザ」には、例えば、旧来の将棋ゲームや麻雀ゲームのプレイヤのように、その仮想実体がゲーム上視認できないが、「実ユーザ」に成り代わった存在として仮想空間内で操作される駒や牌も含まれる。「仮想ユーザ」には、また、ロールプレイングゲームや対戦ゲームにおいてゲーム上で表示され、移動やアクションを起こす視認可能な特定のキャラクタも含まれる。さらに「仮想ユーザ」には、ＳＮＳにおけるアバターとして表示される仮想実体も含まれる。

「仮想空間」とは、ゲーム上で仮想ユーザが行動可能な、コンピュータによって構築される空間を示す。仮想空間は、例えば、仮想ユーザが移動可能な仮想の道が張り巡らされた構造が採用され、仮想の道を介して仮想ユーザが移動可能に接続されたスタート地点及びゴール地点が設定される。また、仮想空間には、仮想の道に、仮想ユーザが対戦可能な敵を配置するといった構造を採用することができる。

（２）ソーシャルゲームの概要
続いて、ゲームサーバ１からインターネット２を介して接続された端末３に提供されるソーシャルゲームの概要について、図２を参照して説明する。

一般にソーシャルゲームは、実ユーザによる端末３の操作に応じた動作を行う仮想ユーザを介して、仮想空間内において、例えば、数百種類など多種類のキャラクタが付された仮想的なカード（以下、単にカードという。）の中から、所定枚数からなるカードのアイテムリスト（以下、デッキともいう。）を作成するゲームである。より具体的には、デッキに搭載したカードのレベルアップやグループの選択を行いつつ、仮想空間上で出現する敵とカード同士で対戦したり、他の仮想ユーザとカードのトレードを行ったりするなど、カードを強化、収集していくものである。カード同士の対戦では、デッキを構成する各カードの攻撃力や防御力、所定のカードの組合せにより一定の効力を得るスキル（カードゲームや麻雀でいうところの「役」に当たる。）などに基づいて、敵に与えるダメージや勝敗が決する。

ソーシャルゲームは、複数のゲームパート（以下、単に「パート」ともいう）が有機的に組み合わさることにより、一つのストーリーやキャラクタが完成し、全体として一つのゲームとして成立する。例えば、ソーシャルゲーム２０は、図２に示すように、クエストパート２１と、バトルパート２２と、ガチャパート２３と、強化パート２４と、を備える。

クエストパート２１は、「探索、探求、冒険」などの意義を有する「クエスト」という言葉が表す通り、仮想ユーザが仮想空間を探索して、探索中に出現する敵と対戦したり、新たなカードを獲得したり、仮想ユーザのレベル向上を行うことにより、進捗するゲームを構成する一部分である。クエストパート２１では、仮想ユーザに所定のクエスト用ポイントが与えられ、仮想ユーザの移動、アイテムの獲得やレベルの向上などは、このクエスト用ポイントを消費することで行われる。また、クエストパート２１では、バトル用ポイントを消費して仮想ユーザが所有するカードを用いることで、出現した敵と対戦が行われる。

バトルパート２２は、仮想ユーザが所有するカードが組み込まれたデッキを用いて、他の仮想ユーザを敵として対戦するパートであり、上述したデッキを構成する各カードの攻撃力及び防御力に基づいて勝敗が決する。

ガチャパート２３は、硬貨を自動販売機に投入してカプセルに包装されたおもちゃであるカプセルトイが出てくる様子を表した「ガチャガチャ」（登録商標）に由来するものであり、例えば、仮想ユーザが、硬貨の代わりに仮想的に与えられるガチャ用ポイントやガチャ用の権限を用いて、カードごとの出現率に基づいてランダムにカードを取得するパートである。

強化パート２４は、仮想ユーザが所有しているカードを合成してカードの強さを表すレベルを上げることで、デッキに組み込まれた時に、敵に与える攻撃力や、敵からの攻撃を防御する防御力などを強化するパートである。

以上のような複数のパートから構成されるソーシャルゲーム２０は、各パート単体が他のゲームパートから独立したものではなく、上述したように、各パートが互いに関係し合い、組み合わさることで、ゲーム全体としての意義を有するものとなっている。したがって、ソーシャルゲーム２０では、仮想ユーザが各ゲームパートを有効に進捗させることで、全体として一つのゲームを進行させることができる。

（３）基本的なハードウェア構成
（３−１）端末の構成
以上のようなソーシャルゲーム２０の定義に基づき、以下、本実施形態のゲームシステムＧを実現するためのハードウェア構成について説明する。

図１に示すように、端末３は、例えば、無線通信部３１と、表示部３２と、操作部３３と、これら各部に電力供給する電池３４とを備える携帯型無線通信端末により構成される。無線通信部３１は、携帯電話回線や無線ＬＡＮ回線を用いてインターネット２に接続し、ウェブブラウザ上でゲームサーバ１とデータ通信を行う。表示部３２は、ゲームサーバ１から受信したウェブブラウザの画面を表示する。操作部３３は、例えば、表示部３２の画面上の表示に従って実ユーザからの操作入力を受け付けるタッチパネルから構成される。このように実ユーザから受け付けられた操作入力は、無線通信部３１によりゲームサーバ１に送信される。また、電池３４は、例えば繰り返し充放電可能な二次電池であって、上述した無線通信部３１と、表示部３２と、操作部３３に電力供給する。また、電池３４は、例えば電池残量を検出可能な検出機能を有している。なお、電池残量の検出機能は、電池３４が有する場合に限らない。つまり、端末３が、電池３４以外に、電池３４の電池残量を検出する検出用の処理回路を備えてもよい。また、端末３側で電池残量を検出する代わりに、ゲームサーバ１が、電池３４の電圧レベル及び定格容量などの情報を受信して、当該情報を用いて電池残量を算出してもよい。以下の説明では、端末３が、電池残量を示す電池残量情報を検出し、検出した電池残量情報をゲームサーバ１に送信するものとして説明する。

以上のハードウェア構成を有する端末３では、例えば、予め登録したユーザＩＤと所定のパスワードとの組合せにより、端末の個体認証処理を行う。そして、端末３は、ゲームサーバ１との間での認証が完了すると、ゲームサーバ１からゲームを進行するのに必要なデータを受信するとともに、操作部３３における操作データをゲームサーバ１に送信する。また、端末３は、上述の通り、当該端末３が有する電池３４の電池残量を示す電池残量情報を逐次ゲームサーバ１に送信する。

なお、端末３は、通信ネットワークであるインターネット２を介してゲームサーバ１と通信可能な通信装置であれば、携帯電話機、ＰＤＡ、パーソナルコンピュータなどであってもよい。また、操作部３３の例としてタッチパネルを挙げたが、もちろん物理的なキー操作によってカーソルなどを移動させて選択操作を行い、情報の入力を行うような構成を採用してもよい。

（３−２）ゲームサーバの概略構成
端末３と通信可能に接続されるゲームサーバ１は、例えば図３に示すような汎用的なハードウェア構成を有するコンピュータにより実現される。すなわち、ゲームサーバ１は、図３に示すように、インターネット２を介して端末３と通信を行う通信インタフェース部１１と、キーボードやマウスなどのユーザからの操作入力を受ける操作入力部１２とを備える。また、ゲームサーバ１は、各種演算処理を行うＣＰＵなどの演算処理部１３と、演算処理データを一時的に記憶するＳＲＡＭやＤＲＡＭなどのメインメモリ１４と、アプリケーションプログラム及び各種データが記憶されたハードディスクなどの記憶装置１５と、演算処理結果を表示するディスプレイ１６とを備える。

（４）第１の実施形態
（４−１）ゲームサーバ
第１の実施形態に係るゲームサーバ１（本実施形態では、他の実施形態と区別するためゲームサーバ１ａという。）は、ソーシャルゲーム２０を実ユーザに提供するためのゲームプログラムを記憶装置１５にインストールすることで、図４に示すような機能ブロックが実現される。

すなわち、ゲームサーバ１ａでは、例えば図４に示すような、受信部１１ａと、送信部１１ｂと、ゲームデータ処理部１００ａと、ゲームデータを管理するゲームデータ記憶部２００とからなる機能が実現される。

受信部１１ａは、通信ネットワーク２を通じて、端末３から送られてくる操作データを受信する手段である。具体的に、受信部１１が受信する操作データを示すデータは、仮想ユーザに対して要求する行動の内容を示すデータであって、例えば、仮想空間に設定された仮想の道に沿って仮想ユーザが移動すること、当該仮想の道を移動中に仮想ユーザが遭遇した敵を攻撃することを示すデータである。また、受信部１１ａは、ゲーム進行に関するデータ以外にも、端末３の電池の電池残量を示すデータも受信する。

送信部１１ｂは、ゲームの進行内容を示すゲーム画面を表示させるための表示用データを、端末３に送信する手段である。送信部１１ｂが送信するデータは、例えば、仮想ユーザが、仮想の道に沿って移動したり敵に攻撃したりするゲームの進行内容を示すゲーム画像の画像データである。より具体的に、送信部１１ｂは、静止画遷移形式又はアニメーション遷移形式で表現されたゲーム画像を表示するデータを端末３に送信する。

なお、表示用データは画像データに限らない。つまり端末３がログイン時などに予めゲーム画像を示す画像データをダウンロードしているような場合には、送信部１１ｂは、当該ゲーム画面を端末に表示させる表示制御データを、表示用データとして端末３に送信することが可能であるが、以下ではゲーム画像の画像データを表示用データとして説明する。

ゲームデータ処理部１００ａは、クエストパート処理部１０１とバトルパート処理部１０２とガチャパート処理部１０３と強化パート処理部１０４と遷移形式決定部１０５とを有する。

ここで、クエストパート処理部１０１は、クエストパート２１のデータ処理を行う。また、バトルパート処理部１０２は、バトルパート２２のデータ処理を行う。ガチャパート処理部１０３は、ガチャパート２３のデータ処理を行う。強化パート処理部１０４は、強化パート２４のデータ処理を行う。

また、遷移形式決定部１０５は、端末３の電池残量を示す情報に基づいて、ゲーム画像の遷移形式を決定する処理を行う。具体的に、遷移形式決定部１０５は、端末３の電池残量が３０パーセント以上の場合は、端末３に表示されるゲーム画像の遷移形式をアニメーション遷移形式に決定する。また、遷移形式決定部１０５は、端末３の電池残量が３０パーセント未満の場合は、端末３に表示されるゲーム画像の遷移形式を静止画遷移形式に決定する。静止画遷移形式とアニメーション遷移形式との特徴及び違いについては後述する。また、電池残量に余裕があればより複雑な画像演出を実ユーザに提供するため、初期設定の遷移形式は、アニメーション遷移形式とする。

ゲームデータ記憶部２００は、ゲームデータ処理部１００ａによってアクセスされ、ゲームデータ処理部１００ａが処理する各種ゲームデータを管理する。

上記の構成からなるゲームサーバ１ａにおいて、以下では、バトルパート処理部１０２の具体的な処理に注目して、ゲーム画像の遷移形式を決定する具体的な構成及び処理について説明する。

（４−２）バトルパート処理部
図５は、バトルパート処理部１０２の具体的な構成を示す図である。

（４−２−１）ゲームデータ記憶部の構成
まず、バトルパート処理部１０２で用いるデータとして、ゲームデータ記憶部２００は、図５に示すように、敵データテーブル２１０と、仮想ユーザデータテーブル２２０と、ゲーム画像データテーブル２３０と、操作内容データテーブル２４０と、を記憶している。

（敵データテーブル２１０）
敵データテーブル２１０は、例えば図６（Ａ）に示すような、仮想ユーザが対戦可能な敵に関する各種パラメータを管理するデータテーブルである。すなわち、敵データテーブル２１０は、一意に識別可能な固有番号を示す敵ＩＤ６１１が割り当てられた敵ごとに、体力６１２と攻撃力６１３と防御力６１４とを管理する。

体力６１２は、仮想ユーザからの攻撃に対する耐久能力を数値化した値（以下、体力値ともいう。）であり、攻撃力６１３は仮想ユーザを攻撃する能力を数値化した値であり、防御力６１４は仮想ユーザからの攻撃を防御する能力を数値化した値である。図６（Ａ）では、例えば、敵ＩＤ６１１が「００００１」で管理される敵について、体力６１２が「１２５」であり、攻撃力６１３が「２０」であり、防御力６１４が「１３」であることを示している。

（仮想ユーザデータテーブル２２０）
仮想ユーザデータテーブル２２０は、例えば、図６（Ｂ）に示すように、仮想ユーザに関する各種パラメータを管理するデータテーブルである。すなわち、仮想ユーザデータテーブル２２０は、一意に識別可能な固有番号を示すユーザＩＤ６２１が割り振られた仮想ユーザ毎に、ユーザレベル６２２と体力６２３と攻撃力６２４と防御力６２５と、過去１週間の操作回数６２６と、を管理する。

ユーザレベル６２２は、ゲーム開始段階から累積される累積能力値、換言すればゲーム内での仮想ユーザの強さを定量的に表現した数値である。また、体力６２３は敵からの攻撃に対する耐久能力を数値化した体力値であり、攻撃力６２４は敵を攻撃する能力を数値化した値であり、防御力６２５は敵の攻撃を防御する能力を数値化した値である。過去１週間の操作回数６２５は、４つのゲームパートについて操作された回数である。図６（Ｂ）では、例えば、ユーザＩＤ６２１が「１０００１」で管理される仮想ユーザについて、ユーザレベル６２２が「３５」であり、体力６２３が「２８５」であり、攻撃力６２４が「５６」であり、防御力６２５が「４５」であることを示している。また、過去１週間の操作回数６２５として、クエストパート２１が「２５２回」、バトルパート２２が「１２１回」、ガチャパート２３が「８７回」、強化パート２４が「３４回」操作されたことを示している。

（ゲーム画像データテーブル２３０）
ゲーム画像データテーブル２３０は、例えば図７、図８及び図９に示すようなゲーム画像を表示するデータを管理する。

図７に示すゲーム画像７０は、仮想ユーザが対戦可能な敵を表示する画像であり、各種ゲームパートのプレイを選択するメニュー選択画像７１１〜７１４と、敵を視覚的に表現した敵画像７２と、敵画像７２に表現された敵との対戦を要求するための操作用画像７３とから構成される。操作用画像７３の表示箇所がクリック操作又はタップ操作されると、後述するように遷移形式決定部１０５によって遷移形式が決定され、静止画遷移形式に決定した場合には図８（Ａ）に示すゲーム画像８１に遷移し、アニメーション遷移形式に決定した場合には図９（Ａ）に示すゲーム画像９１に遷移する。

図８に示すゲーム画像は、静止画遷移形式のゲーム画像により実現される対戦処理の進行内容及び操作内容を示す図である。ここで、静止画遷移形式とは、端末３が、クリック操作又はタップ操作に応じて、その都度ゲームサーバ１から取得した静止画像に直接遷移する形式である。

具体的に、図８（Ａ）に示すゲーム画像８１は、仮想ユーザがバトルを開始する操作を受け付けるための静止画であり、操作用画像８１１がタップ操作されることでゲーム画像８２に遷移可能なハイパーリンクが設定されている。また、図８（Ｂ）に示すゲーム画像８２は、仮想ユーザの攻撃により敵の右腕と左足が破壊されたバトル結果と、バトルを再開する操作用画像８２１とが示された静止画であって、操作用画像８２１がタップ操作されることで他のゲーム画像に遷移可能なハイパーリンクが設定されている。

ゲーム画像８１、８２から明らかなように、静止画遷移形式では、操作に応じて１枚１枚切り替わりながら決まった順番で表示されるだけなので実ユーザに作業的な印象を与えかねないという欠点がある。このような欠点がある反面、静止画遷移形式では、静止画（ゲーム画像８１）から静止画（ゲーム画像８２）に切り替わる間にアニメーションが表示されないので、具体的には後述するアニメーション遷移形式と比べて、描画処理が軽く電池残量が減りにくいため、電池残量が少ない状況でゲーム操作を行うのに適している。

図９に示すゲーム画像は、アニメーション遷移形式のゲーム画像により実現される対戦処理の進行内容及び操作内容を示す図である。ここで、アニメーション遷移形式とは、アニメーションの表示によりゲーム画像が遷移する形式である。すなわち、アニメーション遷移形式は、静止画遷移形式のように静止画を切り替えることはなく、アニメーションの表示によりゲーム画像が遷移するので、タップ操作及びフリック操作に応じてゲーム画像の一部を変形及び移動させるなど、静止画遷移形式に比べて複雑な描画処理を実現することができる。

具体的に、図９（Ａ）に示すゲーム画像９１は、仮想ユーザがバトルを開始する操作を受け付けるための画像であり、操作用画像９１１がタップ操作されることで、図９（Ｂ）から図９（Ｅ）までのゲーム画像のような、アニメーションの表示が開始されることになる。

すなわち、図９（Ｂ）に示すゲーム画像９２は、表示箇所９２１のフリック操作に従って端末３により形成される画像であって、画面右上に移動する敵の右腕を変形及び分離させながら破壊する様子を示している。図９（Ｃ）に示すゲーム画像９３は、ゲーム画像９１の操作用画像９１１のタップ操作から５秒後に、敵がランダムな方向、例えば画面左下に移動する様子を示している。図９（Ｄ）に示すゲーム画像９４は、ゲーム画像９３の表示から４秒後に、敵が表示箇所９４１のフリック操作に従って端末３により形成される画像であって、敵の左足を変形及び分離させながら破壊する様子を示している。図９（Ｅ）に示すゲーム画像９５は、仮想ユーザの攻撃により敵の右腕と左足が破壊されたバトル結果と、バトルを再開する操作用画像９５１とが示された画像であって、操作用画像９５１がタップ操作されることで他のゲーム画像に遷移可能なハイパーリンクが設定されている。

ゲーム画像９１〜９５から明らかなように、アニメーション遷移形式のゲーム画像は、タップ操作及びフリック操作に応じてゲーム画像の一部を変形及び移動させるなど、静止画遷移形式に比べて複雑な描画処理が可能であるため、実ユーザに比較的複雑な操作や画像演出を提供できるという利点がある。このような利点がある反面、アニメーション遷移形式で表現されるゲーム画像は、静止画遷移形式に比べて、端末側でゲーム画面を表示するのに必要な処理量が多く、端末に搭載された電力供給用電池の電池残量の減りが速いため、電池残量に余裕がある状況下でゲーム操作を行うのに適している。

なお、静止画遷移形式のゲーム画像およびアニメーション遷移形式のゲーム画像は、両方とも、ラスタ画像を用いて表現することができる。ここで、ラスタ画像とは、ビットマップ画像など、画素が線上に並んだもの（ラスタ線）の集合体によって表現される画像である。ラスタ画像を切り替えて表示すれば静止画遷移形式のゲーム画像を実現でき、JavaScript（登録商標）を用いてラスタ画像を連続表示すればアニメーション遷移形式のゲーム画像を実現することができる。

上記の通りラスタ画像を用いることで、静止画遷移形式およびアニメーション遷移形式の両方を実現することができるが、次に説明するように、アニメーション遷移形式のゲーム画像は、ラスタ画像に代えてベクタ画像から構成されることが特に好ましい。ここで、ベクタ画像とは、点の位置、点と点とを結ぶ線、線の太さ及び色、曲線であれば曲率など、幾何学的な図面情報によって表現される画像であって、端末側で図形情報に基づいてラスタ画像を作図する処理を要する。

ラスタ画像とベクタ画像とを比較すると、ラスタ画像は、ベクタ画像と異なり端末３の内部メモリに展開したデータをディスプレイに出力するだけでゲーム画像を出力できるため、電池残量が少ない場合に適している。これに対して、ベクタ画像は、ラスタ画像に比べてより複雑な描画処理が可能なため、電池残量に余裕があり複雑な操作や画像演出を実ユーザに提供できる状況に適している。

以上のようなラスタ画像とベクタ画像との利点を考慮し、それぞれ静止画遷移形式のゲーム画像とアニメーション遷移形式のゲーム画像とに適用することで、電池残量に適したゲーム進行を実現することができる。

（操作内容データテーブル２４０）
操作内容データテーブル２４０は、図１０に示すように、静止画遷移形式及びアニメーション遷移形式でそれぞれ表現されるゲーム画像により操作可能な操作内容を管理するテーブルである。

例えば、図１０では、遷移形式２４１に対応する各種操作内容、すなわち、タップ操作２４２の操作内容と、フリック操作２４３の操作内容とを一覧で管理している。図１０の例において、静止画遷移形式では、タップ操作を「後続画像に直接遷移する」操作内容に設定し、フリック操作には何ら操作内容を設定しないことを示している。また、アニメーション遷移形式では、タップ操作を「タップ箇所を破壊箇所として選択する」操作内容に設定し、フリック操作を「フリック方向に敵の部位を分離させる」操作内容に設定することを示している。後述する操作内容設定部４２は、上記の情報を管理する操作内容データテーブル２４０を参照して、遷移形式に対応する操作内容を設定する。

（４−２−２）バトルパート処理部１０２の構成
バトルパート処理部１０２は、図５に示すように、仮想ユーザが仮想空間で遭遇した敵との対戦を実行する対戦実行部４１と、ゲーム画像で操作可能な操作内容を設定する操作内容設定部４２と、対戦の進行内容が表示されたゲーム画像の表示データを端末３に送信する表示用データ送信部４３と、を備える。

対戦実行部４１は、仮想ユーザと敵との対戦を実行する。具体的に、対戦実行部４１は、仮想ユーザの攻撃によって敵に与えるダメージを、仮想ユーザの攻撃力及び敵の防御力から算出して、敵の体力値から差し引く。また、対戦実行部４１は、仮想ユーザが敵から受けるダメージを、仮想ユーザの防御力及び敵の攻撃力から算出して、仮想ユーザの体力値から差し引く。さらに、対戦実行部４１は、仮想ユーザよりも先に敵の体力の値が「０」になった場合には仮想ユーザが勝利したものと判断して勝利結果に応じた報酬を仮想ユーザに設定し、敵よりも先に仮想ユーザの体力の値が「０」になった場合には仮想ユーザが敗北したものと判断する。

操作内容設定部４２は、遷移形式決定部１０５により決定されたゲーム画像により操作可能な操作内容を決定する。つまり、操作内容決定部４２は、操作内容データテーブル２４０を参照して、同一の敵と対戦するようなゲーム進行状態であっても、アニメーション遷移形式が決定された場合には静止画遷移形式に比べて操作の自由度を高めたり、より複雑な操作を可能にしたりするなど、決定された遷移形式に適した操作内容を設定する。

具体的に、操作内容決定部４２は、遷移形式が静止画遷移形式に設定された場合、タップ操作によりゲーム画像８１からゲーム画像８２に直接遷移するという操作内容を設定する。一方、操作内容決定部４２は、遷移形式がアニメーション遷移形式に設定された場合、ゲーム画像９１〜９５のようにタップ操作及びフリック操作により敵を段階的に破壊したり変形したりする操作内容を設定する。このようにして、操作形式決定部４２は、アニメーション遷移形式が決定された場合には静止画遷移形式に比べて操作の自由度を高めたり、より複雑な操作を可能にしたりするなど、決定された遷移形式に適した操作内容を設定する。

表示用データ送信部４３は、遷移形式決定部１０５により決定した遷移形式であって、操作内容決定部４３により設定された操作内容を操作可能に表現したゲーム画像を表示するための表示用データを、端末３に送信する。具体的に、表示用データ送信部４３は、同一の敵と対戦するようなゲーム進行状態であっても、決定された遷移形式に応じて、ゲーム画像データテーブル２３０から、図８に示すゲーム画像８１、８２、若しくは、図９に示すゲーム画像９１〜９５を表示するためのデータを端末３に送信する。

（４−３）ゲームサーバが実行する処理
第１の実施形態に係るゲームサーバ１ａにより実行される処理について図１１を参照して説明する。すなわち、ゲームデータ処理部１００ａは、図１１に示すステップＳ１１０１〜Ｓ１１０６に従い、電池残量情報に基づいて遷移形式を決定してバトルパート２２を含む各種ゲームパートを実行する。また、上述したように、初期設定された遷移形式はアニメーション遷移形式とする。

ステップＳ１１０１において、受信部１１ａは、端末３から、当該端末３が備える電池３４の電池残量情報を受信して、ステップＳ１１０２に進む。ステップＳ１１０２において、遷移形式決定部１０５は、当該電池残量情報が示す電池残量が所定値、例えば満充電状態に対して３０％未満であるか否かを判断する。ここで、電池残量が３０％未満の場合（Ｓ１１０２：Ｙｅｓ）にはステップＳ１１０３に進み、電池残量が３０％未満ではない場合（Ｓ１１０２：Ｎｏ）、つまり電池残量が３０％以上の場合にはステップＳ１１０４に進む。

ステップＳ１１０３において、遷移形式決定部１０５は、ゲーム画像の遷移形式を静止画遷移形式に決定する。ステップＳ１１０４において、遷移形式決定部１０５は、ゲーム画像の遷移形式を変更せず、アニメーション遷移形式に決定する。ステップＳ１１０３及びステップＳ１１０４の後はステップＳ１１０５に進む。

ステップＳ１１０５において、ゲームデータ処理部１００ａは、各種のゲームパート処理を実行する。例えば対象となるゲームパートがバトルパート２２の場合、バトルパート処理部１０２は、図１２に示すステップＳ１２０１〜Ｓ１２０５に従った処理を実行する。

まず、表示用データ送信部４３は、対戦実行用ゲーム画像として、図７に示すようなゲーム画像の表示用データを端末３に送信する（ステップＳ１２０１）。次に、操作内容設定部４２は、遷移形式決定部１０５により決定した遷移形式が静止画遷移形式であるか否かを判断する（ステップＳ１２０２）。遷移形式が静止画遷移形式である場合（Ｓ１２０２：Ｙｅｓ）にはステップＳ１２０３に進み、操作内容設定部４２は、タップ操作によりゲーム画像８１からゲーム画像８２に直接遷移するという操作内容を設定する。また、遷移形式が静止画遷移形式ではない場合（Ｓ１２０２：Ｎｏ）、すなわち遷移形式がアニメーション遷移形式である場合にはステップＳ１２０４に進み、操作内容設定部４２は、ゲーム画像９１〜９５のようにタップ操作及びフリック操作により敵を段階的に破壊したり変形したりする操作内容を設定する。

ステップＳ１２０３又はステップＳ１２０４が終了すると、表示用データ送信部４３は、操作内容決定部４２により設定された操作内容を操作可能に表現したゲーム画像を表示するデータを、端末３に送信する（ステップＳ１２０５）。すなわち、表示用データ送信部４３は、遷移形式が静止画遷移形式である場合には図８に示すゲームデータ８１、８２を表示するデータを端末３に送信し、遷移形式がアニメーション遷移形式である場合には図９に示すゲームデータ９１〜９５を表示するデータを端末３に送信して、図１２に示すステップＳ１１０５を終了し、ステップＳ１１０６に進む。

ステップＳ１１０６において、ゲームデータ処理部１００ａは、実ユーザがゲームを継続しているか否かを判断する。具体的には、最後に操作データを受信した時刻から所定時間が経過していない場合（Ｓ１１０６：Ｙｅｓ）にはゲームを継続していると判断してステップＳ１１０１に戻り、最後に操作データを受信した時刻から所定時間が経過している場合（Ｓ１１０６：Ｎｏ）にはゲームを継続していないと判断して図１１に示す処理を終了する。

上記の図１１及び図１２に示す処理により、ゲームデータ処理部１００ａは、電池残量が所定値未満になると電池残量の減りが比較的少ない静止画遷移形式のゲーム画面を端末３に表示することにより、実ユーザに対して、端末３が備える電池３４の電池残量を気にさせることなく、ゲームプレイに集中させることが可能となる。すなわち、ゲームデータ処理部１００ａは、端末３が備える電池３４の電池残量の減りが早いといった理由で敬遠されることなく、アニメーション遷移形式のゲーム画面で表現されるゲーム進行を多くの利用者に楽しんでもらうことが可能となる。

（４−４）第１の変形例
ゲームサーバ１は、上記の図１１に示すステップＳ１１０４において、一律に遷移形式をアニメーション遷移形式に決定する代わりに、図１３に示すフローチャートに従い、電池残量の増加に伴って段階的に静止画遷移形式からアニメーション遷移形式に切り換えてもよい。すなわち、電池残量が３０％未満ではない場合（Ｓ１１０２：Ｎｏ）には、以下に示すように、ステップＳ１３０１〜Ｓ１３０７を行い、その後ステップ１１０５に進んでもよい。

ステップＳ１３０１において、遷移形式決定部１０５は、端末３の電池残量が、満充電状態に対して４０％未満であるか否かを判断する。ここで、電池残量が４０％未満の場合（Ｓ１３０１：Ｙｅｓ）、つまり電池残量が３０％以上乃至４０％未満にはステップＳ１３０２に進む。また、電池残量が４０％未満ではない場合（Ｓ１３０１：Ｎｏ）、つまり電池残量が４０％以上の場合にはステップＳ１３０４に進む。

ステップＳ１３０２において、遷移形式決定部１０５は、下記の例に示すように、仮想ユーザデータテーブル２２０の過去１週間の操作回数６２５を参照して、操作頻度が最も低い方から１番目のゲームパートの遷移形式をアニメーション遷移形式に決定して、ステップ１３０３に進む。例えば、ユーザＩＤデータ６２１が「１０００１」で管理される仮想ユーザについては、過去１週間の操作回数６２５が最も少ない強化パート２４の遷移形式をアニメーション遷移形式に決定する。

ステップＳ１３０３において、遷移形式決定部１０５は、操作頻度が最も低い方から２〜４番目のゲームパートの遷移形式を静止画遷移形式に決定して、ステップＳ１００４を終了する。例えば、ユーザＩＤデータ６２１が「１０００１」で管理される仮想ユーザについては、過去１週間の操作回数６２５が２〜４番目に少ないゲームパート、つまり、ガチャパート２３、バトルパート２２、クエストパート２１の遷移形式を静止画遷移形式に決定する。

ステップＳ１３０４において、遷移形式決定部１０５は、端末３の電池残量が、満充電状態に対して５０％未満であるか否かを判断する。ここで、電池残量が５０％未満の場合（Ｓ１３０４：Ｙｅｓ）、つまり電池残量が４０％以上乃至５０％未満にはステップＳ１３０５に進む。また、電池残量が５０％未満ではない場合（Ｓ１３０４：Ｎｏ）、つまり電池残量が５０％以上の場合にはステップＳ１３０７に進む。

ステップ１３０５において、遷移形式決定部１０５は、操作頻度が最も低い方から１、２番目のゲームパートの遷移形式をアニメーション遷移形式に決定して、ステップ１３０６に進む。例えば、ユーザＩＤデータ６２１が「１０００１」で管理される仮想ユーザについては、過去１週間の操作回数６２５が１、２番目に少ない強化パート２４、ガチャパート２３の遷移形式をアニメーション遷移形式に決定する。

ステップＳ１３０６において、遷移形式決定部１０５は、操作頻度が最も低い方から３、４番目のゲームパートの遷移形式を静止画遷移形式に決定して、ステップＳ１００４を終了する。例えば、ユーザＩＤデータ６２１が「１０００１」で管理される仮想ユーザについては、過去１週間の操作回数６２５が３、４番目に少ないバトルパート２２、クエストパート２１の遷移形式を静止画遷移形式に決定する。

ステップ１３０７において、遷移形式決定部１０５は、全てのゲームパートのゲーム画像の遷移形式を、アニメーション遷移形式に決定してステップＳ１００４を終了する。

上記の図１３に示す処理を行うことで、ゲームデータ処理部１００ａは、電池残量の増加に伴って、例えば強化パート２４、ガチャパート２３、バトルパート２２・クエストパート２１の順番で、遷移形式を静止画遷移形式からアニメーション遷移形式に切り換える。このようにして電池残量の増加に伴って段階的に静止画遷移形式からアニメーション遷移形式に切り換えることにより、全てのゲームパートのゲーム画像を静止画遷移形式からアニメーション遷移形式に同時に切り換えるのに比べて、端末３の電池３４を低充電状態から通常の充電状態に早く復帰することができる。

つまり、上記の図１３に示す処理を行うことで、充電動作により電池残量が所定値以上に復帰した後も、実ユーザに対して、端末に搭載された電池３４の電池残量を気にすることなくゲームプレイに集中させることが可能となる。

特に、上記の図１３に示す処理では、ゲームパートの操作頻度を考慮して、静止画遷移形式からアニメーション遷移形式に切り替えることにより、例えば操作頻度を考慮せず任意のゲームパートに関するゲーム画像について静止画遷移形式からアニメーション遷移に切り替える場合に比べて、電池残量が所定値以上に復帰した直後に、再び電池残量が所定値を下回ることで静止画遷移形式に切り替わるような事態を確実に回避できる。電池残量の変動に応じて遷移形式が頻繁に切り替わると、実ユーザにとってゲームをプレイしにくくなるが、このような事態を上記の図１３に示す処理により確実に回避することができる。

なお、電池残量の増加に伴って段階的に静止画遷移形式からアニメーション遷移形式に切り換えるのであれば、図１３に示す処理に限らず、例えば、ランダムに選択したゲームパートの遷移形式から静止画遷移形式からアニメーション遷移形式に切り替えてもよい。例えば、ゲームの世界観、ゲーム設計者の意図などによって、クエストパート２１、バトルパート２２、ガチャパート２３、強化パート２４の順番で、ゲーム画像全体に対してアニメーション遷移形式のゲーム画像が占める割合が少ない場合、クエストパート２１、バトルパート２２、ガチャパート２３、強化パート２４の順番で、段階的にゲーム画面を静止画遷移形式からアニメーション遷移形式に切り換えてもよい。

（４−５）第２の変形例
ゲームサーバ１は、上記の図１１に示すステップＳ１１０３において、一律に遷移形式を静止画遷移形式に決定する代わりに、図１４に示すフローチャートに従い、電池残量の減少に伴って段階的にアニメーション遷移形式から静止画遷移形式に切り換えてもよい。すなわち、電池残量が３０％未満である場合（Ｓ１１０２：Ｙｅｓ）には、以下に示すように、ステップＳ１４０１〜Ｓ１４０７を行い、その後ステップＳ１１０５進んでもよい。

ステップＳ１４０１において、遷移形式決定部１０５は、端末３の電池残量が、満充電状態に対して２５％以上で３０％未満の範囲であるか否かを判断する。ここで、電池残量が当該範囲である場合（Ｓ１４０１：Ｙｅｓ）にはステップＳ１４０２に進む。また、電池残量が当該範囲ではない場合（Ｓ１４０１：Ｎｏ）、つまり電池残量が２５％未満の場合にはステップＳ１４０４に進む。

ステップＳ１４０２において、遷移形式決定部１０５は、以下の例に示すように、操作頻度が最も高い方から１番目のゲームパートの遷移形式を静止画遷移形式に決定して、ステップ１４０３に進む。例えば、ユーザＩＤデータ６２１が「１０００１」で管理される仮想ユーザについては、過去１週間の操作回数６２５が最も多いクエストパート２１の遷移形式を静止画遷移形式に決定する。

ステップＳ１４０３において、遷移形式決定部１０５は、操作頻度が最も高い方から２〜４番目のゲームパートの遷移形式をアニメーション遷移形式に決定して、ステップＳ１００３を終了する。例えば、ユーザＩＤデータ６２１が「１０００１」で管理される仮想ユーザについては、過去１週間の操作回数６２５が２〜４番目に多いゲームパート、つまりバトルパート２２、ガチャパート２３、強化パート２４の遷移形式をアニメーション遷移形式に決定して、ステップＳ１１０３を終了する。

ステップＳ１４０４において、遷移形式決定部１０５は、端末３の電池残量が、満充電状態に対して２０％以上で２５％未満の範囲であるか否かを判断する。ここで、電池残量が当該範囲の場合（Ｓ１４０４：Ｙｅｓ）にはステップＳ１４０５に進む。また、電池残量が当該範囲ではない場合（Ｓ１４０４：Ｎｏ）、つまり電池残量が２０％未満の場合にはステップＳ１４０７に進む。

ステップ１４０５において、遷移形式決定部１０５は、操作頻度が最も高い方から１、２番目のゲームパートの遷移形式を静止画遷移形式に決定して、ステップ１４０６に進む。例えば、ユーザＩＤデータ６２１が「１０００１」で管理される仮想ユーザについては、過去１週間の操作回数６２５が１、２番目に多いクエストパート２１、バトルパート２２の遷移形式を静止画遷移形式に決定する。

ステップＳ１４０６において、遷移形式決定部１０５は、操作頻度が最も高い方から３、４番目のゲームパートの遷移形式をアニメーション遷移形式に決定して、ステップＳ１１０３を終了する。例えば、ユーザＩＤデータ６２１が「１０００１」で管理される仮想ユーザについては、過去１週間の操作回数６２５が３、４番目に多いガチャパート２３、強化パート２４の遷移形式をアニメーション遷移形式に決定する。

ステップ１４０７において、遷移形式決定部１０５は、全てのゲームパートのゲーム画像の遷移形式を、静止画遷移形式に決定してステップＳ１１０３を終了する。

上記の図１４に示す処理を行うことで、ゲームデータ処理部１００ａは、電池残量の減少に伴って、例えばクエストパート２１、バトルパート２２、ガチャパート２３・強化パート２４の順番で、遷移形式をアニメーション遷移形式から静止画遷移形式に切り換える。ここで、全てのゲームパートのゲーム画像をアニメーション遷移形式から静止画遷移形式に同時に切り換えると、今まで複雑な画面演出が単調な画面演出に大きく切り替わるため、実ユーザのゲームを進行する意欲を大きく失ってしまう。

一方、上記の図１４に示す処理では、電池残量の増加に伴って段階的にアニメーション遷移形式から静止画遷移形式に切り換えることにより、全てのゲームパートのゲーム画像をアニメーション遷移形式から静止画遷移形式に同時に切り換えるのに比べて遷移形式の切り替えにより与える違和感を軽減でき、電池残量が少なくなっても、ゲームを楽しんでもらう環境を提供できる。

特に、上記の図１４に示す処理では、ゲームパートの操作頻度を考慮して、アニメーション遷移形式から静止画遷移形式に切り替えることにより、例えば操作頻度を考慮せず任意のゲームパートに関するゲーム画像についてアニメーション遷移から静止画遷移形式に切り替える場合に比べて、実ユーザに電池残量を気にさせることなく、ゲームに集中させることができる。例えば、電池残量が所定値未満となった後も、操作頻度が高いゲームパートに関する遷移形式がなかなか静止画遷移形式に切り替わらないと、比較的短時間で電池残量がなくなる事態が生じる。一方、上記の図１４に示す処理では、操作頻度の高いゲームパートから、電力消費量が少ない静止画遷移形式に切り替えるので、比較的短時間で電池残量がなくなる事態を回避し、実ユーザに対してゲームに集中させることができる。

なお、電池残量の減少に伴って段階的にアニメーション遷移形式から静止画遷移形式に切り換えるのであれば、図１４に示す処理に限らず、例えば、ランダムに選択したゲームパートから順番にアニメーション遷移形式から静止画遷移形式に切り替えてもよい。例えば、強化パート２４、ガチャパート２３、バトルパート２２、クエストパート２１の順番で、ゲーム画像全体に対してアニメーション遷移形式のゲーム画像が占める割合が多い場合、強化パート２４、ガチャパート２３、バトルパート２２、クエストパート２１の順番で、段階的にゲーム画面をアニメーション遷移形式から静止画遷移形式に切り換えてもよい。

（５）第２の実施形態
次に、第２の実施形態に係るゲームサーバ１（本実施形態では、他の実施形態と区別するためゲームサーバ１ｂという。）について、図１５などを用いて説明する。図１５に示すように、ゲームサーバ１ｂについては、受信部１１ａと、送信部１１ｂと、ゲームデータ記憶部２００が第１の実施形態と同様の構成であり、ゲームデータ処理部１００ｂの構成の一部が第１の実施形態と異なる。よって、第１の実施形態に係るゲームサーバ１ａと同様の構成については省略する。

（５−１）ゲームデータ処理部
ゲームデータ処理部１００ｂは、図１５に示すように、第１の実施形態に係るゲームデータ処理部１００ａと同様の構成を備え、更に電池残量推測部１０６と進行内容制限部１０７と、を備える。ここで、第１の実施形態に係るゲームデータ処理部１００ａと同様の構成については省略する。

電池残量推測部１０６は、遷移形式決定部１０５によって遷移形式が静止画遷移形式に決定された後に、現在のゲームの進行内容から特定の進行内容に到達するまでの電力消費量を推測する。ここで、所定の進行内容とは、クエストパート２１の進行中にゴール地点に辿り着いたり、ゲームを進行中に特定の敵（以下、ボスともいう）と対戦したりするなど、ゲーム進行上特に盛り上がる「見せ場」に当たる。「見せ場」に当たる進行内容については、電池残量に余裕がある状況下で、アニメーション遷移形式を用いて高揚感や躍動感を与える画面演出を実ユーザに提供することが望ましい。このため、電池残量推測部１０６は、現在のゲーム進行内容に基づいて所定の進行内容に到達するまでの消費電力を推測する。例えば、ボスとバトルするまでに、残り４体の他の敵とバトルする必要がある場合には、当該４体の他の敵とバトルに要する消費電力を推定する。

進行内容制限部１０７は、推測した電力消費量に基づき、例えば電池残量に余裕がなければ、ボスと対戦させなかったりするようにゲーム進行を制限する。具体的には、推測した電力消費量が、電池容量に換算して２０％以上である場合には、ボスとの対戦を実行しないように、バトルパート処理部１０２の処理に制限をかける。

（５−２）ゲームサーバが実行する処理
第２の実施形態に係るゲームサーバ１ｂにより実行される処理について図１６を参照して説明する。すなわち、ゲームデータ処理部１００ｂは、図１６に示すステップＳ１６０１〜Ｓ１６０９に従い、電池残量情報に基づいて遷移形式を決定してバトルパート２２を含む各種ゲームパートを実行する。

ステップＳ１６０１において、受信部１１ａは、端末３から、当該端末３が備える電池３４の電池残量情報を受信して、ステップＳ１６０２に進む。

ステップＳ１６０２において、遷移形式決定部１０５は、当該電池残量情報が示す電池残量が所定値、例えば満充電状態に対して３０％未満であるか否かを判断する。ここで、電池残量が３０％未満の場合（Ｓ１６０２：Ｙｅｓ）にはステップＳ１６０３に進み、電池残量が３０％未満ではない場合（Ｓ１６０２：Ｎｏ）、つまり電池残量が３０％以上の場合にはステップＳ１６０４に進む。

ステップＳ１６０３において、遷移形式決定部１０５は、ゲーム画像の遷移形式を静止画遷移形式に決定し、ステップＳ１６０５に進む。ステップＳ１６０４において、遷移形式決定部１０５は、ゲーム画像の遷移形式をアニメーション遷移形式に決定してステップＳ１６０８に進む。

ステップＳ１６０５において、消費電力推定部１０６は、バトルパート処理部１０２による進行内容に基づいて、ボスとのバトルに到達するまでの消費電力を推定して、ステップＳ１６０６に進む。上記の例の通り、ボスとバトルするまでに、残り４体の他の敵とバトルする必要がある場合には、当該４体の他の敵とバトルに要する消費電力を推定する。

ステップＳ１６０６において、進行内容制限部１０７は、ステップＳ１６０５により推測した消費電力が、電池容量で換算して２０％以上であるという条件を満たすか否かを判断する。当該条件を満たす場合（Ｓ１６０６：Ｙｅｓ）には電池残量に余裕が無いためステップＳ１６０７に進み、当該条件を満たさない場合（Ｓ１６０６：Ｎｏ）には、電池残量に余裕があるためステップＳ１６０７に進まずステップＳ１６０８に進む。

ステップＳ１６０７において、進行内容制限部１０７は、推測した電力消費量に基づき、ボスとの対戦を進行するのに電池残量に余裕がないため、ボスと対戦させないように、バトルパート処理部１０２の処理を制限して、ステップＳ１６０８に進む。なお、電池残量に余裕がある場合には当該制限をせずに、ステップＳ１６０８に進む。

ステップＳ１６０８において、ゲームデータ処理部１００ｂは、各種のゲームパート処理を実行して、ステップＳ１６０９に進む。例えば対象となるゲームパートがバトルパート２２の場合、バトルパート処理部１０２は、図１２に示すステップＳ１２０１〜Ｓ１２０５に従った処理を実行する。

ステップＳ１６０９において、ゲームデータ処理部１００ｂは、実ユーザがゲームを継続しているか否かを判断する。具体的には、最後に操作データを受信した時刻から所定時間が経過していない場合（Ｓ１６０９：Ｙｅｓ）にはゲームを継続していると判断してステップＳ１６０１に戻り、最後に操作データを受信した時刻から所定時間が経過している場合（Ｓ１６０９：Ｎｏ）にはゲームを継続していないと判断して図１６に示す処理を終了する。

上記の図１６に示す処理により、ゲーム上の「見せ場」となる特定の進行内容に到達するまでに消費する消費電力を推定して、推定した電力消費量に基づき電池残量に余裕がなければ、特定の進行内容を進行不可に設定してゲーム進行を制限する。このような処理により、電池残量に余裕がある適切な状況下において、高揚感や躍動感を与える画面演出を実ユーザに提供することができる。

（６）第３の実施形態
次に、第３の実施形態に係るゲームサーバ１（本実施形態では、他の実施形態と区別するためゲームサーバ１ｃという。）について、図１７などを用いて説明する。図１７に示すように、ゲームサーバ１ｃについては、受信部１１ａと、送信部１１ｂと、ゲームデータ記憶部２００が第１の実施形態と同様の構成であり、ゲームデータ処理部１００ｃの構成の一部が第１の実施形態と異なる。よって、第１の実施形態に係るゲームサーバ１ａと同様の構成については省略する。

（６−１）ゲームデータ処理部
ゲームデータ処理部１００ｃは、図１７に示すように、第１の実施形態に係るゲームデータ処理部１００ａと同様の構成を備え、更に遷移形式選択情報送信部１０８を備える。ここで、第１の実施形態に係るゲームデータ処理部１００ａと同様の構成については省略する。

遷移形式選択情報送信部１０８は、電池残量が所定値未満である場合に、例えば、図１８に示すような、静止画遷移形式又はアニメーション遷移形式の選択を求めるゲーム画像１８０の表示用データを端末３に送信する。ここで、ゲーム画像１８０は、各種ゲームパートのプレイを選択するメニュー選択画像１８１１〜１８１４と、静止画遷移形式を選択する選択画像１８２１と、アニメーション遷移形式を選択する選択画像１８２２とから構成される。また、ゲーム画像１８０の表示用データは、ゲームデータ記憶部２００に記憶され、遷移形式選択操作用情報送信部１０８により読み出されて端末３に送信される。

ゲーム画像１８０の表示用データが端末３に送信されると、その後、受信部１１ａは、ゲーム画像１３０に従って、選択用操作情報に従って静止画遷移形式又はアニメーション遷移形式を選択したことを示す遷移形式選択情報を受信する。

また、遷移形式決定部１０５は、電池残量が例えば３０％未満であって、受信部１１ａが受信した遷移形式選択情報が静止画遷移形式を選択したことを示す場合に、ゲーム画像の遷移形式を静止画遷移形式に決定する。

（６−２）ゲームサーバが実行する処理
次に、第２の実施形態に係るゲームサーバ１ｃにより実行される処理について図１９を参照して説明する。すなわち、ゲームデータ処理部１００ｃは、図１９に示すステップＳ１９０１〜Ｓ１９０８に従い、電池残量情報に基づいて遷移形式を決定してバトルパート２２を含む各種ゲームパートを実行する。

ステップＳ１９０１において、受信部１１ａは、端末３から、当該端末３の電池残量情報を受信して、ステップＳ１９０２に進む。ステップＳ１９０２において、遷移形式決定部１０５は、当該電池残量情報が示す電池残量が所定値、例えば満充電状態に対して３０％未満であるか否かを判断する。ここで、電池残量が３０％未満の場合（Ｓ１９０２：Ｙｅｓ）にはステップＳ１９０３に進み、電池残量が３０％未満ではない場合（Ｓ１９０２：Ｎｏ）つまり電池残量が３０％以上の場合にはステップＳ１９０６に進む。

ステップＳ１９０３において、遷移形式選択情報送信部１０８は、静止画遷移形式又はアニメーション遷移形式の選択を求める情報、つまり図１８に示すゲーム画像１８０の表示用データを端末３に送信して、ステップＳ１９０４に進む。

ステップＳ１９０４において、遷移形式決定部１０５は、遷移形式についてアニメーション遷移形式に初期設定しているが、ゲーム画像１８０が表示された端末３から受信部１１ａが受信した遷移形式選択情報が、静止画遷移形式を選択したことを示しているか否かを判断する。ここで、遷移形式選択情報が静止画遷移形式を選択したことを示す場合（Ｓ１９０４：Ｙｅｓ）にはステップＳ１９０５に進み、遷移形式選択情報が静止画遷移形式を選択したことを示さない場合（Ｓ１９０４：Ｎｏ）つまりアニメーション遷移形式を選択したことを示す場合にはステップＳ１９０６に進む。

ステップＳ１９０５において、遷移形式決定部１０５は、ゲーム画像の遷移形式を静止画遷移形式に決定（変更）する。また、ステップＳ１９０６において、遷移形式決定部１０５は、ゲーム画像の遷移形式を変更せず、アニメーション形式に決定する。ステップＳ１９０５及びステップＳ１９０６の後はステップＳ１９０７に進む。

ステップＳ１９０７において、ゲームデータ処理部１００ｃは、各種のゲームパート処理を実行する。例えば対象となるゲームパートがバトルパート２２の場合には、上述した第１の実施形態と同様に、図１２に示すステップＳ１２０１〜Ｓ１２０５に従い、バトルパート処理部１０２の表示用データ送信部４３が、バトルパート２２の表示用データを送信して、ステップＳ１９０８に進む。

ステップＳ１９０８において、ゲームデータ処理部１００ｃは、実ユーザがゲームを継続しているか否かを判断する。具体的には、最後に操作データを受信した時刻から所定時間が経過していない場合（Ｓ１９０８：Ｙｅｓ）にはゲームを継続していると判断してステップＳ１９０１に戻り、最後に操作データを受信した時刻から所定時間が経過している場合（Ｓ１９０８：Ｎｏ）にはゲームを継続していないと判断して図１９に示す処理を終了する。

上記図１９に示す処理を実行することで、電池残量が所定値未満である場合、実ユーザに対して遷移形式の選択を求めてから、表示用データを静止画遷移形式で送信することで、端末３が備える電池３４の電池残量の減り具合を実ユーザに喚起しながら、電池３４の消費が比較的少ない静止画遷移形式のゲーム画面でゲームを継続させることができる。

（６−３）変形例
ゲームサーバ１ｃは、上記の図１９に示すステップのうちステップＳ１９０７において図１２に示す処理を実行する代わりに、図２０に示すフローチャートに従って、ゲーム画像の遷移形式を静止画遷移形式に決定した場合には、電池残量の減少に伴って操作可能な操作内容を段階的に制限してもよい。

まず、表示用データ送信部４３は、対戦実行用ゲーム画像として、図７に示すようなゲーム画像の表示用データを端末３に送信する（ステップＳ２００１）。次に、操作内容設定部４２は、遷移形式決定部１０５により決定した遷移形式が静止画遷移形式であるか否かを判断する（ステップＳ２００２）。遷移形式が静止画遷移形式である場合（Ｓ２００２：Ｙｅｓ）にはステップＳ２００３に進み、操作内容設定部４２は、タップ操作によりゲーム画像８１からゲーム画像８２に直接遷移するという操作内容を設定してステップＳ２００９に進む。また、遷移形式が静止画遷移形式ではない場合（Ｓ２００２：Ｎｏ）、すなわち遷移形式がアニメーション遷移形式である場合にはステップＳ２００４に進み、操作内容設定部４２は、ゲーム画像９１〜９５のようにタップ操作及びフリック操作により敵を段階的に破壊したり変形したりする操作内容を設定してステップＳ２００５に進む。

ステップＳ２００５において、操作内容設定部４２は、電池残量が２０％以上３０％未満であるか否かを判断し、電池残量が２０％以上３０％未満である場合（Ｓ２００５：Ｙｅｓ）には、電池残量に余裕があるものとして操作内容を制限せずにステップＳ２００９に進む。また、電池残量が２０％以上３０％未満ではない場合（Ｓ２００５：Ｎｏ）には電池残量に余裕がないものとして、フリック操作に応じた操作内容を無効にし（Ｓ２００６）、ステップＳ２００７に進む。

ステップＳ２００７において、操作内容設定部４２は、電池残量が１０％以上２０％未満であるか否かを判断し、電池残量が１０％以上２０％未満である場合（Ｓ２００５：Ｙｅｓ）には、更なる操作内容の制限を行わずにステップＳ２００９に進む。また、電池残量が１０％以上２０％未満ではない場合（Ｓ２００５：Ｎｏ）には更なる操作内容の制限として、タップ操作可能な時間間隔を例えば１秒間から５秒間など長くなるように操作内容を設定変更し（ステップＳ２００８）、ステップＳ２００９に進む。

ステップＳ２００９において、表示用データ送信部４３は、操作内容決定部４２により設定された操作内容を操作可能に表現したゲーム画像を表示するデータを、端末３に送信する。すなわち、表示用データ送信部４３は、遷移形式が静止画遷移形式である場合には図８に示すゲームデータ８１、８２を表示するデータを端末３に送信し、遷移形式がアニメーション遷移形式である場合には図９に示すゲームデータ９１〜９５を表示するデータを端末３に送信して、図１９に示すステップＳ１９０７を終了し、ステップＳ１９０８に進む。

上記の図２０に示す処理により、電池残量の減少に伴って、フリック操作を無効にしたり、タップ操作が可能な時間間隔を長くしたりするなど、操作内容を段階的に制限する。このようにして電池残量の減少に伴って操作内容を段階的に制限することにより、描画処理をできるだけ軽くて電池残量の消耗を抑えながら、実ユーザの希望により選択されたアニメーション遷移形式のゲーム画像を表示することができる。

（７）他の実施形態
以上、本実施形態に係るゲームサーバ、ゲーム制御方法、ゲームプログラム及びゲームシステムについて述べたが、本発明は記述の実施形態に限定されるものではなく、本発明の技術思想に基づいて各種の変形および変更が可能である。

例えば、図１６に示す処理のうち、ステップＳ１６０４を行う代わりに、図１３に示すフローチャートに従った処理（ステップＳ１３０１〜Ｓ１１０７）を行ってもよい。また、ステップＳ１６０３を行う代わりに、図１４に示すフローチャートに従った処理（ステップＳ１４０１〜Ｓ１４０７）を行ってもよい。

また、図１９に示す処理のうち、ステップＳ１９０６を行う代わりに、図１３に示すフローチャートに従った処理（ステップＳ１３０１〜Ｓ１１０７）を行ってもよい。また、ステップＳ１９０５を行う代わりに、図１４に示すフローチャートに従った処理（ステップＳ１４０１〜Ｓ１４０７）を行ってもよい。

また、本発明は、上記の実施形態の機能を実現するソフトウェアのプログラムが記録された非一時的な記録媒体をシステム又は装置に提供し、当該システム又は装置のコンピュータ、すなわちＣＰＵ又はＭＰＵに、当該非一時的な記録媒体に記録されたプログラムを読み出して実行させることによって実現してもよい。

この場合、当該非一時的な記録媒体から読み出されたプログラムは、上述の実施形態の機能を実現する。したがって、当該プログラム及び当該プログラムが記録された非一時的な記録媒体も、本発明の一態様である。

当該プログラムを提供する非一時的な記録媒体は、例えばフレキシブルディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷなどの光ディスク、磁気テープ、不揮発性メモリカード、及びＲＯＭを含む。或いは、当該プログラムは、通信ネットワークを介してダウンロード可能であってもよい。

さらに、上記の実施形態の機能は、コンピュータが当該プログラムを読み出して実行するだけではなく、コンピュータ上で動作するＯＳ（operating system）等に、当該プログラムの指示に基づき実際の操作の一部又はすべてを実行させることによって実現してもよい。

さらに、上記の実施形態の機能は、非一時的な記録媒体から読み出されたプログラムを、コンピュータに挿入された拡張ボードに設けられたメモリ、又は、コンピュータに接続された拡張装置に設けられたメモリに書き込み、拡張ボード又は拡張装置に設けられたＣＰＵ等に、プログラムの指示に基づき実際の処理のすべて又は一部を実行させることによって実現されてもよい。

典型的な実施形態を参照して本発明を説明したが、本発明は、ここに開示する典型的な態様に限定されないことはもちろんである。特許請求の範囲は、このような変更と、同等の構造及び機能とをすべてを含むように最も広く解釈することが可能である。

１ ゲームサーバ
２ インターネット
３ 端末
１１ａ 受信部
１１ｂ 送信部
１０２ バトルパート処理部
１０５ 遷移形式決定部
４１ 対戦実行部
４２ 操作内容設定部
４３ 表示用データ送信部

Claims (13)

1. 通信ネットワークを介して接続された端末にゲームを提供するゲームサーバにおいて、
   前記ゲームに対して実ユーザが操作した操作データを、前記端末から受信する受信部と、
   前記端末の表示部に前記ゲームの進行内容及び操作内容を表示するゲーム画像の遷移形式を、実ユーザの操作に応じて静止画を所定の順番で切り替えて表示することによりゲーム画像が遷移する静止画遷移形式、又は、実ユーザの操作に応じて図面情報からアニメーションを作図して表示することによりゲーム画像が遷移するアニメーション遷移形式に決定する遷移形式決定部と、
   前記決定した遷移形式でゲーム画像を表示するデータを、前記端末に送信する表示用データ送信部と、を備え、
   前記受信部は、前記端末に電力供給する電池に関するデータをさらに受信し、
   前記遷移形式決定部は、前記受信した電池に関するデータに基づき電池残量が所定値未満である場合には、ゲーム画像の遷移形式を前記静止画遷移形式に決定することを特徴とするゲームサーバ。
2. 前記遷移形式決定部は、前記電池残量が所定値以上の場合には、該電池残量の増加に伴って段階的に前記静止画遷移形式から前記アニメーション遷移形式に切り換えることを特徴とする請求項１記載のゲームサーバ。
3. 前記端末に提供されるゲームは、複数のゲームパートから構成されており、
   前記受信部は、前記端末から、一のゲームパートを進行するための操作データを受信し、
   前記遷移形式決定部は、前記電池残量が所定値以上の場合には、該電池残量の増加に伴って、操作頻度が最も低いゲームパートから順番に、各ゲームパートに対応した遷移形式を前記静止画遷移形式から前記アニメーション遷移形式に切り換えることを特徴とする請求項２記載のゲームサーバ。
4. 前記遷移形式決定部は、前記電池残量が所定値未満の場合には、該電池残量の減少に伴って段階的に前記アニメーション遷移形式から前記静止画遷移形式に切り換えることを特徴とする請求項１記載のゲームサーバ。
5. 前記端末に提供されるゲームは、複数のゲームパートから構成されており、
   前記受信部は、前記端末から、一のゲームパートを進行するための操作データを受信し、
   前記遷移形式決定部は、前記電池残量が所定値未満の場合には、該電池残量の減少に伴って、操作頻度が最も高いゲームパートから順番に、各ゲームパートに対応した遷移形式を前記アニメーション遷移形式から前記静止画遷移形式に切り換えることを特徴とする請求項４記載のゲームサーバ。
6. 遷移形式が前記静止画遷移形式に決定した場合に、現在のゲームの進行内容から特定の進行内容に到達するまでの電力消費量を推測する電力消費量推測部と、
   前記推測した電力消費量に基づいて、前記特定の進行内容に進行できないように制限する進行内容制限部と、を備えることを特徴とする請求項１〜５のいずれか１項に記載のゲームサーバ。
7. 前記電池残量が所定値未満である場合に、前記静止画遷移形式又は前記アニメーション遷移形式の選択を求める選択操作情報を前記端末に送信する遷移形式選択情報送信部を更に備え、
   前記受信部は、前記選択操作情報に従って前記静止画遷移形式又は前記アニメーション遷移形式を選択したことを示す選択情報を含む操作データを更に受信し、
   前記遷移形式決定部は、前記電池残量が前記所定値未満であって、前記選択情報が前記静止画遷移形式を選択したことを示す場合に、ゲーム画像の遷移形式を前記静止画遷移形式に決定することを特徴とする請求項１又は５記載のゲームサーバ。
8. ゲーム画像の遷移形式を前記アニメーション遷移形式に決定した場合、前記電池残量の減少に伴って、該ゲーム画像により操作可能な操作内容を段階的に制限する操作内容設定部を更に備えることを特徴とする請求項７記載のゲームサーバ。
9. 前記静止画遷移形式のゲーム画像はラスタ画像から構成され、
   前記アニメーション遷移形式のゲーム画像はベクタ画像から構成されることを特徴とする請求項１〜８のいずれか１項に記載のゲームサーバ。
10. 通信ネットワークを介して接続された端末にゲームを提供する処理を、前記通信ネットワークに接続されたコンピュータが実行するゲーム制御方法において、
    前記ゲームに対して実ユーザが操作した操作データを、前記端末から受信する操作データ受信処理と、
    前記端末の表示部に前記ゲームの進行内容及び操作内容を表示するゲーム画像の遷移形式を、実ユーザの操作に応じて静止画を所定の順番で切り替えて表示することによりゲーム画像が遷移する静止画遷移形式、又は、実ユーザの操作に応じて図面情報からアニメーションを作図して表示することによりゲーム画像が遷移するアニメーション遷移形式に決定する遷移形式決定処理と、
    前記決定した遷移形式でゲーム画像を表示するデータを、前記端末に送信する表示用データ送信処理と、を前記通信ネットワークに接続されたコンピュータが実行し、
    前記操作データ受信処理では、前記端末に電力供給する電池に関するデータをさらに受信し、
    前記遷移形式決定処理では、前記受信した電池に関するデータに基づき電池残量が所定値未満である場合には、ゲーム画像の遷移形式を前記静止画遷移形式に決定することを特徴とするゲーム制御方法。
11. 通信ネットワークを介して接続された端末にゲームを提供する処理を、前記通信ネットワークに接続されたコンピュータに実行させるためのプログラムにおいて、
    前記ゲームに対して実ユーザが操作した操作データを、前記端末から受信する操作データ受信処理と、
    前記端末の表示部に前記ゲームの進行内容及び操作内容を表示するゲーム画像の遷移形式を、実ユーザの操作に応じて静止画を所定の順番で切り替えて表示することによりゲーム画像が遷移する静止画遷移形式、又は、実ユーザの操作に応じて図面情報からアニメーションを作図して表示することによりゲーム画像が遷移するアニメーション遷移形式に決定する遷移形式決定処理と、
    前記決定した遷移形式でゲーム画像を表示するデータを、前記端末に送信する表示用データ送信処理と、を前記通信ネットワークに接続されたコンピュータに実行させ、
    前記操作データ受信処理では、前記端末に電力供給する電池に関するデータをさらに受信し、
    前記遷移形式決定処理では、前記受信した電池に関するデータに基づき電池残量が所定値未満である場合には、ゲーム画像の遷移形式を前記静止画遷移形式に決定することを特徴とするプログラム。
12. 通信ネットワークを介して接続された端末にゲームを提供する処理を、前記通信ネットワークに接続されたコンピュータに実行させるプログラムをコンピュータ読み取り可能に記録した記録媒体において、
    前記ゲームに対して実ユーザが操作した操作データを、前記端末から受信する操作データ受信処理と、
    前記端末の表示部に前記ゲームの進行内容及び操作内容を表示するゲーム画像の遷移形式を、実ユーザの操作に応じて静止画を所定の順番で切り替えて表示することによりゲーム画像が遷移する静止画遷移形式、又は、実ユーザの操作に応じて図面情報からアニメーションを作図して表示することによりゲーム画像が遷移するアニメーション遷移形式に決定する遷移形式決定処理と、
    前記決定した遷移形式でゲーム画像を表示するデータを、前記端末に送信する表示用データ送信処理と、を前記通信ネットワークに接続されたコンピュータに実行させ、
    前記操作データ受信処理では、前記端末に電力供給する電池に関するデータをさらに受信し、
    前記遷移形式決定処理では、前記受信した電池に関するデータに基づき電池残量が所定値未満である場合には、ゲーム画像の遷移形式を前記静止画遷移形式に決定することを特徴とする記録媒体。
13. ゲームサーバと、
    前記ゲームサーバと通信ネットワークを介して接続された１以上の端末とから構成され、
    前記ゲームサーバは、
    通信ネットワークを介して接続された端末から、該端末に提供されるゲームに対して実ユーザが操作した操作データを、前記端末から受信する受信部と、
    前記端末の表示部に前記ゲームの進行内容及び操作内容を表示するゲーム画像の遷移形式を、実ユーザの操作に応じて静止画を所定の順番で切り替えて表示することによりゲーム画像が遷移する静止画遷移形式、又は、実ユーザの操作に応じて図面情報からアニメーションを作図して表示することによりゲーム画像が遷移するアニメーション遷移形式に決定する遷移形式決定部と、
    前記決定した遷移形式でゲーム画像を表示するデータを、前記端末に送信する表示用データ送信部と、を有し、
    前記受信部は、前記端末に電力供給する電池に関するデータをさらに受信し、
    前記遷移形式決定部は、前記受信した電池に関するデータに基づき電池残量が所定値未満である場合には、ゲーム画像の遷移形式を前記静止画遷移形式に決定し、
    前記端末は、
    前記電池と、
    実ユーザの操作入力を受け付ける操作入力部と、
    前記受け付けた操作入力を示す操作データと、前記電池に関するデータと、を前記ゲームサーバに送信する送信部と、
    前記ゲームサーバからゲーム画像を表示するデータを受信する受信部と、
    前記ゲーム画像を表示する表示部を有することを特徴とするゲームシステム。