(58)【調査した分野】(Int.Cl.,DB名)
前記表示制御ステップは、第2形式の第2種類のエフェクトの再生頻度が前記一定以上のときに再生要求された場合、前記エフェクトのデータを削減する処理を実行し、当該処理後の当該エフェクトのデータを用いて、前記制御を実行するステップを含む、
請求項1又は2に記載のプログラム。
前記表示制御ステップは、再生要求された前記形式及び前記種類のエフェクトのデータが前記GPUのキャッシュに存在する場合、当該キャッシュに存在する当該エフェクトのデータを用いて、前記制御を実行するステップを含む、
請求項1乃至3のうち何れか1項に記載のプログラム。
再生要求された前記形式及び前記種類のエフェクトについて、前記再生頻度が一定以上であれば、前記再生頻度に応じて削減するデータ量を決定する削減量決定量ステップを、
さらに含み、
前記表示制御ステップは、前記再生頻度が一定以上であれば、前記削減量決定量ステップの処理で決定された前記データ量分だけ削減された前記エフェクトのデータを用いて、前記制御を実行する、
請求項1乃至4のうち何れか1項に記載のプログラム。
【発明を実施するための形態】
【0010】
以下、本発明の実施形態について、図面を用いて説明する。
【0011】
図1は、本発明の一実施形態に係るプレイヤー端末1のハードウェア構成を示すブロック図である。
【0012】
なお、以下において、単に「画像」と呼ぶ場合には、「動画像」と「静止画像」との両方を含むものとする。
【0013】
プレイヤー端末1は、スマートフォンで構成される。
プレイヤー端末1は、SoC(System on a chip)11と、バス25と、入出力インターフェース26と、タッチ操作入力部27と、表示部28と、入力部29と、記憶部30と、通信部31と、ドライブ32と、を備えている。
プレイヤー端末1のSoC11は、CPU(Central Processing Unit)21と、ROM(Read Only Memory)22と、RAM(Random Access Memory)23と、GPU(Graphics Processing Unit)24と、を備えている。
【0014】
CPU21は、ROM22に記録されているプログラム、又は、記憶部30からRAM23にロードされたプログラムに従って各種の処理を実行する。
RAM23には、CPU21が各種の処理を実行する上において必要なデータ等も適宜記憶される。
GPU24は、ROM22に記録されているプログラム、又は、記憶部30からRAM23にロードされたプログラムに従って、表示部28に表示させる画像データに対して所定の画像処理を施す。ここで、表示部28に表示させる画像データには、後述のエフェクトのデータも含まれている場合がある。また、所定の画像処理としては、例えば、最終的なレンダリング処理の他、3D座標から2D座標への座標変換処理等のレンダリングの前処理等が存在する。
【0015】
SoC(System on a chip)11が接続されるバス25には、入出力インターフェース26も接続されている。入出力インターフェース26には、タッチ操作入力部27、表示部28、入力部29、記憶部30、通信部31及びドライブ32が接続されている。
【0016】
タッチ操作入力部27は、例えば表示部28に積層される静電容量式又は抵抗膜式(感圧式)の位置入力センサにより構成され、タッチ操作がなされた位置の座標を検出する。
ここで、タッチ操作とは、タッチ操作入力部27に対する物体の接触又は近接の操作をいう。タッチ操作入力部27に対して接触又は近接する物体は、例えばプレイヤーの指やタッチペン等である。なお、以下、タッチ操作がなされた位置を「タッチ位置」と呼び、タッチ位置の座標を「タッチ座標」と呼ぶ。
表示部28は、液晶等のディスプレイにより構成され、ゲームに関する画像等、各種画像を表示する。
このように、本実施形態では、タッチ操作入力部27と表示部28とにより、タッチパネルが構成されている。
なお、本明細書で「表示媒体」と呼ぶ場合、単に表示部28を意味せず、タッチ操作入力部27と表示部28とから構成される「タッチパネル」を意味する。
【0017】
入力部29は、各種ハードウェア釦等で構成され、プレイヤーの指示操作に応じて各種情報を入力する。
記憶部30は、DRAM(Dynamic Random Access Memory)等で構成され、各種データを記憶する。
通信部31は、図示せぬインターネットを含むネットワークを介して他の装置(図示せぬサーバや図示せぬ他のプレイヤー端末)との間で行う通信を制御する。
【0018】
ドライブ32は、必要に応じて設けられる。ドライブ32には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア41が適宜装着される。ドライブ32によってリムーバブルメディア41から読み出されたプログラムは、必要に応じて記憶部30にインストールされる。また、リムーバブルメディア41は、記憶部30に記憶されている各種データも、記憶部30と同様に記憶することができる。
【0019】
このような
図1のプレイヤー端末1の各種ハードウェアと各種ソフトウェアとの協働により、プレイヤー端末1でゲームの実行が可能になる。
ここで、プレイヤー端末1は、上述の如くスマートフォンで構成されており、ゲームの実行中には、継続的にタスクを実行するため、有効的な省電力技術の適用が求められる。このためには、スマートフォンの主要な電力消費源を対象とする省電力化を図るとよい。
そこで、本発明者は、先ず次のようにして、スマートフォンの主要な電力消費源がGPU24であり、特にGPU24によるメモリのアクセス時の負荷が電力消費が著しい、という知見を得た。
【0020】
即ち、本発明者は、プレイヤー端末1として適用可能なスマートフォンの実機を用いて、各構成要素の負荷を実測したところ、スマートフォンの主要な電力消費源がGPU24であるという結果を得た。
【0021】
さらに、本発明者は、ゲーム実行中のGPU24の負荷と消費電力との関係を明らかにするために、既存のゲームタイトルにおけるGPU24の負荷による電力消費量を計測した。前提として、発明者は、既存のゲームタイトルの設定で高画質モードと低画質モードを設定し、それぞれの電力消費量の対比を行った。
結果として、高画質モードでは、GPUの負荷が上昇する頻度が高く、かつ、バッテリー残量の低下速度が速くなることが判明した。一方、低画質モードでは、GPUの負荷が上昇する頻度が低く、かつ、バッテリー残量の低下速度が遅くなることが判明した。
このように、プレイヤー端末1のようなスマートフォンでの電力消費が大きい要素は、GPU24であることが検証された。
【0022】
ここで、GPU24の内部の電力消費の内訳として最大のものは、GPU24からRAM23等のメモリへのアクセスであることが知られている。
この理由は、プレイヤー端末1のようなスマートフォンのGPU24は、
図1に示すように、CPU21やメモリと結合されたSoC11として実装されているからである。即ち、SoC11では、メモリダイはCPU21やGPU24といったロジックダイの上部にスタックされて実装されている。RAM23等のメモリへのアクセスは、オフチップアクセスとなるため著しく電力の消費量が大きくなるのである。
【0023】
以上のことから、ゲーム実行時に、GPU24からメモリへのアクセス量を低減させることで、プレイヤー端末1のようなスマートフォンの効果的な省電力化を図ることができる。
ここで、ゲーム実行時にGPU24からメモリへのアクセス量が多いものは、グラフィックのエフェクト(シェダープログラムやテクスチャー)であり、ゲーム内で頻繁に再生されている。
従って、ゲーム内で頻繁に再生されるエフェクトを対象としてデータの削減を行い、GPU24からメモリへのアクセス回数を減少させることで、プレイヤー端末1のようなスマートフォンの効果的な省電力化を図ることができる。
【0024】
しかしながら、ゲームのエフェクトは、ゲームの面白さや魅力に直結するものであり、プレイヤーに対して効果的に提示する必要があるため、むやみやたらにデータを削減することは好ましくない。
ここで、プレイヤーは、ゲームのエフェクトよりも省電力を図ることを所望する場合には、ゲームの設定メニューを操作して、ゲームのエフェクトをOFFに手動で切り替えることはできる。しかしながら、プレイヤー(特にゲームの初心者)は、ゲームの設定メニューを操作することに慣れていないことが多く、省電力のためだけにゲームのエフェクトのON/OFFを切り替えることは困難であるし煩わしい。
つまり、魅力的なグラフィックのエフェクトのプレイヤーへの提示と、省電力とを自動的に両立させる機能が必要になる。
【0025】
ここで、プレイヤーがゲームのプレイ中にグラフィックのエフェクトに注目している度合いを「注目度」と呼ぶならば、
図2に示すように、注目度が高いときには、グラフィックのエフェクトを、データ量を削減せずに効果的にプレイヤーに提示する一方、注目度が低いときには、グラフィックのエフェクトのデータ量を削減して、省電力化を図ると好適である。
図2は、プレイヤーのエフェクトへの注目度と省電力効果の関係を表す図である。
図2において、縦軸はプレイヤーのエフェクトへの注目度を示し、横軸はエフェクトの再生頻度を示している。
ゲーム内のエフェクトの再生頻度が高ければ高いほど、プレイヤーはエフェクトを何度も見るためエフェクトに飽き、注意を払わなくなる傾向にあるため、
図2に示すように注目度も低くなる。
一方、エフェクトの再生頻度が高ければ、そのエフェクトによって消費される電力の総量が多いということであり、再生頻度が高ければ高いほど、
図2に示すようにエフェクトを省電力化した時の効果は大きくなる。
【0026】
そこで、本発明が適用されるプレイヤー端末1は、プレイヤーが十分に飽きる程度に再生頻度が高くなったエフェクトを対象としてデータを削減して、GPU24からメモリへのアクセス回数を減少させることで、省電力化を図る。
一方、プレイヤー端末1は、再生頻度が低いエフェクトについては、データを削減せずに高画質のまま再生する。
即ち、プレイヤー端末1は、ゲームのエフェクトの再生頻度に応じて、頻度が高いものほど、より多くのデータを削減する処理を自動的に実行する。
これにより、魅力的なグラフィックのエフェクトのプレイヤーへの提示と、省電力とを自動的に両立できるという効果を奏する。この効果は、繰り返し同一のエフェクトが再生されるゲームに適用すると、より顕著になる。
また、プレイヤー端末1は、プレイヤーからの明示的な操作を必要とせずに自動的に省電力化を実現できる。従って、カジュアルなプレイヤーが数多くプレイするソーシャルゲームに適用すると、効果がより顕著になる。
【0027】
ここで、ゲームのエフェクトのデータの削減手法は、特に限定されず任意でよい。例えば
図3に示す削減手法を適用することができる。
図3は、エフェクトのデータの削減手法の具体例を示す図である。
図3の左方の画像は、エフェクトのデータ削減がされていないオリジナルのゲーム画面である。
図3の右方の画像は、エフェクトのデータ削減がなされた後のゲーム画面である。
【0028】
図3の上段に示すように、例えば、エフェクトの形式がGPU24への命令であるCSS Shader Effect/OpenGL Shader Effectである場合は、Shaderプログラムから30%程度の操作を削減することにより、GPU24への負荷そのものを減らすことができる。
即ち、
図3の上段に示すデータの削減手法を適用することで、ゲームのエフェクトのグラフィックの陰影量(
図3の例では剣から発する光の量)が減少するが、その分だけ、GPU24からメモリへのアクセス回数が減少して、省電力を図ることができる。
【0029】
また、
図3の中段に示すように、例えば、エフェクトがビデオの形式で実装されている場合は、ビットレートを30%程度落としたビデオを予め用意し、低ビットレートのビデオを使用することにより、GPU24とメモリ間のデータ転送量を削減することができる。
即ち、
図3の中段に示すデータ削減手法を適用することで、ゲームのエフェクトのグラフィックの画質は落ちるが、その分だけ、GPU24からメモリへのアクセス回数が減少して、省電力を図ることができる。
【0030】
さらに、
図3の下段に示すように、例えば、エフェクトの形式が3Dのポリゴンデータを用いる形式の場合は、頂点数を30%程度削減したモデルを使用することにより、GPU24とメモリ間のデータ転送量を削減することができる。
即ち、
図3の下段に示すデータ削減方法を適用することで、ゲームのエフェクトのグラフィックの頂点数は減ることになるが、その分だけ、GPU24からメモリへのアクセス回数が減少して、省電力を図ることができる。
【0031】
このように、エフェクトのデータの削減手法として複数種類の手法を用意して、ゲームのエフェクトの形式毎に適切な種類手法を適用することができる。また、データの削減手法は、アルゴリズムを用いた動的な削減手法でも良いし、予めデータを削減したエフェクトのデータ(アセット)を用意する手法でも良い。
【0032】
このようにして、本願発明が適用されるプレイヤー端末1は、GPU24からメモリへのアクセス回数を効果的に減少させることで、省電力化を図ることができる。
このような本発明が適用される省電力化の手法は、ほぼ全てのスマートフォン用GPU24に適用可能である。
また、本手法は、特定のハードウェアに依存しない汎用的な省電力化の手法であるため、多数のスマートフォンのプラットフォームに適用することができる。
さらに、本手法は、エフェクトの再生のみを制御するものであり、スマートフォンのハードウェア毎に人手でプロファイルを用意する従来の省電力化の手法や、GPUへの供給電圧や動作周波数を制御するファームウェアを用いる従来の省電力化の手法に比べて、実装コストを低く抑えることができる。
【0033】
以上説明した一連の処理は、プレイヤー端末1におけるハードウェアとソフトウェアの協働により実現される。この場合、プレイヤー端末1は、例えば
図4に示す機能的構成を有している。
図4は、プレイヤーによって操作され、エフェクトが繰り返し再生されるゲームを実行するための
図1のプレイヤー端末の機能的構成の一例を示す機能ブロック図である。
【0034】
図4に示すように、プレイヤー端末1のCPU21においては、ゲーム実行部51と、表示制御部52と、エフェクト再生頻度管理部53とが機能する。表示制御部52は、エフェクトデータ選択部71と、エフェクトデータ削減量決定部72とを備える。
また、記憶部30の一領域として、エフェクト再生頻度管理DB54と、エフェクトデータ格納DB81とが設けられている。エフェクトデータ格納DB81は、データ量大削減DB91と、データ量中削減DB92と、データ量小削減DB93と、データ量無削減DB94とを備える。
さらに、GPU24は、キャッシュ61を備える。
【0035】
ゲーム実行部51は、ゲームの実行を制御し、当該ゲームの実行中、複数の形式及び複数の種類のエフェクトのうち、所定形式及び所定種類のエフェクトの再生要求を、CPU21の表示制御部52に対して行う。
【0036】
表示制御部52は、再生要求された所定形式及び所定種類のエフェクトについて、その再生頻度に応じてデータ量が削減されたデータを用いて、当該エフェクトを含むゲームの画像をGPU24を介して表示部28に表示させる制御を実行する。
【0037】
具体的には、表示制御部52は、再生要求された所定形式及び所定種類のエフェクトのデータがGPU21のキャッシュ61に格納されている場合は、キャッシュ61に存在するエフェクトのデータを用いて、当該エフェクトを含むゲームの画像を表示部28に表示させる制御を実行する。
即ち、GPU24は、キャッシュ61に格納されているエフェクトのデータを用いて、レンダリングを開始する。この場合、GPU24からメモリへのアクセスは発生しないので、大きな省電力効果を奏することができる。
【0038】
これに対して、表示制御部52は、再生要求された所定形式及び所定種類のエフェクトのデータがGPU21のキャッシュ61に格納されていない場合は、データ量が削減されたエフェクトのデータ(アセット)をエフェクトデータ格納DB81から読み込み、GPU24に提供する。なお、データの削減量については、データ量を削減しない「0」を含むものとする。つまり、表示制御部52は、省電力を必要としない場合、データ量が削減されていないエフェクトのデータ(アセット)をエフェクトデータ格納DB81から読み込み、GPU24に提供することもある。
即ち、GPU24は、エフェクトデータ格納DB81から読み出されたエフェクトのデータを用いて、レンダリングを開始する。この場合、GPU24からメモリへのアクセスは発生しているが、データ量が削減されているので、その分だけアクセス回数が減少して、省電力の効果を奏することができる。
【0039】
ここで本実施形態では、表示制御部52が受け付ける再生要求として、レンダリング要求renderが採用されている。render(type,user_id,effect_id)として、定義することができる。
typeは、エフェクトの形式を示す。エフェクトの形式としては、例えば、シェーダプログラムや、ビデオストリーム、ビットマップ画像等が考えられる。
user_idは、レンダリング要求の発生元となるプレイヤーを一意に識別する識別子である。なお、user_idは、単純にプレイヤーを識別する方式だけでなく、プレイヤー端末1を識別することにより、プレイヤー端末1毎の再生頻度を考慮する方式としても良い。
effect_idは、レンダリング対象となるエフェクトの種類の識別子を示す。
【0040】
上記のレンダリング要求に応じて、表示制御部52は、エフェクトデータ選択部71やエフェクトデータ削減量決定部72に対して、アセット検索要求findを発行する。アセット検索要求findは、find(effect_id,frequency)として定義することができる。
effect_idは、上述のレンダリング要求renderで用いられたものと同一のエフェクトの種類の識別子である。
また、frequencyは、当該種類のエフェクトの再生頻度である。
【0041】
エフェクト再生頻度管理部53は、複数の形式毎及び複数の種類毎に、エフェクトの再生頻度を計測し、それらの計測結果を管理する。
具体的には、エフェクト再生頻度管理部53は、各エフェクトの再生頻度をプレイヤー毎に区分して、エフェクト再生頻度管理DB54に記録することで、エフェクトの再生頻度を管理する。即ち、エフェクト再生頻度管理DB54は、プレイヤー毎の各エフェクトの再生頻度のデータを格納する。
なお、エフェクト再生頻度管理部53は、エフェクト再生頻度管理DB54に記憶された全ユーザのエフェクトの再生頻度を集計することにより、各エフェクトについて、データ削減量の初期値を決定することもできる。
【0042】
ここで、エフェクト再生頻度管理部53の最も重要な特徴は、プレイヤー端末1の充電間隔に応じてエフェクトの再生頻度を計測できる点にある。
本実施形態では、エフェクト再生頻度管理部53は、所定形式のレコードを取得して、ユーザ毎に取得したレコードの集合を当該ユーザの再生頻度の情報recordとして、エフェクト再生頻度管理DB54に記憶している。
レコードの集合たるエフェクト頻度の情報recordは、record:={user_id,effect_id,frequency}のように表すことができる。
ここで、user_idは、上記のレンダリング要求renderで用いられたものと同一のプレイヤーを一意に識別する識別子である。
effect_idは、上述のレンダリング要求renderで用いられたものと同一のエフェクトの種類の識別子である。
frequencyは、当該種類のエフェクトの再生頻度である。
このようにして、本実施形態では、プレイヤー毎にエフェクトの再生頻度を計測するため、特定のプレイヤー個人に特化した省電力化を実現することができる。
これにより、プレイヤー個人の生活スタイル、及び、パーティ構成等のゲームプレイスタイルに合わせた省電力化を自動的に実現することが可能となる。
【0043】
本実施形態の実装において重要な点は、エフェクト頻度の情報recordの初期化のタイミングの決定である。
エフェクト頻度の情報recordの初期化の好適なタイミングの一つとして、
図5に示すように、1日の終わりや始まり等がある。
【0044】
図5は、1日単位でのプレイヤーのゲームプレイによるエフェクトの再生頻度を表す図である。
図5においては、縦軸はエフェクトの再生頻度を示し、横軸は1日の24時間帯を示す時間軸である。
図5の例では、多くのプレイヤーは1日の終わりにスマートフォンを充電すると仮定されている。そして、エフェクトの画質は、4段階に分かれており、低画質になるほど、エフェクトのデータ量が削減されて、省電力の効果が顕著になるものとされている。具体的には、エフェクトの画質は、高画質から低画質になる順に、最高画質、標準画質、省電力画質、及び超省電力画質に分かれるものとされている。
【0045】
図5の左側の図は、1日の4つのタイミングで再生されるエフェクトの再生頻度と、その際のエフェクトの画質の変化を示している。
まず、朝の通勤や通学時間帯にゲームをプレイすることにより、エフェクトの再生頻度が上昇する。この時間帯では、エフェクトの再生頻度が蓄積されていないため、最高画質でエフェクトが再生される。
次に、昼休みのゲームプレイや夕方の帰宅時のゲームプレイの中で当該エフェクトが再生されることにより、エフェクトが標準画質や省電力画質へと自動的に切り替わる。
最後に、深夜のゲームプレイでは、再生頻度が最も高い状況であり、超省電力画質でエフェクトが再生される。
【0046】
図5の右側の図は、めったに再生されない希少性の高いエフェクト再生頻度と、その際のエフェクトの画質の変化を示している。
1日を通じて希少性の高いエフェクトの再生頻度は低いままに保たれるため、常に最高画質で再生することができる。
【0047】
以上
図5を用いて説明したように、エフェクト頻度の情報recordの初期化を1日の終わりや始まりに実行して、1日単位でエフェクトの再生頻度を計測することにより、バッテリーの残量が不足しがちな夕方以降に適切な省電力化を図ることが自動的にできる。また、めったに再生されないエフェクトは最高画質で再生することができるため、プレイヤーは魅力的なグラフィックのエフェクトを体感することができる。
【0048】
なお、エフェクト頻度の情報recordの初期化の好適なタイミングは、上記の1日の終わりや始まり以外として、例えば90%以上の充電状況になった時を採用することができる。つまり、
図5の実施例では、スマートフォンを90%以上に充電することにより、エフェクトの画質を元の最高画質に直ちに戻すことができる。
ここで、エフェクト頻度の情報recordの初期化とは、エフェクトの再生頻度frequencyを0にすることのみならず、所定の値に減少させることも含む広義な概念である。
即ち、プレイヤー端末1の充電間隔に応じてエフェクトの再生頻度を計測し、その再生頻度に応じて、エフェクトのデータ量をより多く削減するという操作を自動的に適用することにより、エフェクトの再生時におけるGPU24からメモリへのアクセスの回数を減少させることができる。これにより、プレイヤーがあまり注意を払わないエフェクトのみを選択的に省電力化し、その省電力の効果を大きいものにすることができる。
【0049】
図4に戻り、表示制御部52の機能的構成について、さらに詳しく説明する。
表示制御部52は、ゲーム実行部51からエフェクトの再生要求がなされると、呼び出されて、エフェクトデータ選択部71と、エフェクトデータ削減量決定部72とを機能させる。
ここで、表示制御部52が呼び出される場合には、前述のアセット検索要求findが用いられる。
【0050】
エフェクトデータ選択部71は、再生要求された形式及び種類のエフェクトについて、その再生頻度に応じてデータ量が削減されたデータを、エフェクトデータ格納DB81から選択して抽出し、GPU24に提供する。
エフェクトデータ削減量決定部72は、再生要求された形式及び種類のエフェクトについて、その再生頻度に応じて削減するデータ量を決定する。
【0051】
再生要求される形式としては、予めデータ量を削減できるアセットの形式(例えば、ビットマップデータ、ビデオデータ)と、データ量を動的に削減できるアセットの形式(例えば、シェーダプログラム、ゲームエンジン側で再生フレームを制御するアニメーション)とが存在する。
【0052】
先ず、再生要求されたアセットの形式が、予めデータ量を削減できるアセットの形式(例えば、ビットマップデータ、ビデオデータ)の場合を考える。
この場合、エフェクトデータ削減量決定部72は、予め実装者により設定された
図6に示すような対応表、即ちエフェクトの再生頻度とエフェクトデータ格納DB81との対応表を用いることで、適切な省電力性能を有するDBを選択することで、結果として削減するデータ量を決定している。
図6は、エフェクト再生頻度とエフェクトデータ格納DB81との対応関係を示す図である。
図6に示すように、エフェクトデータ削減量決定部72は、エフェクトの再生頻度frequencyが0回乃至10回の場合には、データ量無削減DB94を選択することで、データの削減量は「0(削減しない)」と決定している。
エフェクトデータ削減量決定部72は、エフェクトの再生頻度frequencyが11回乃至30回の場合には、データ量小削減DB93を選択することで、データの削減量は「小」であると決定している。
エフェクトデータ削減量決定部72は、エフェクトの再生頻度frequencyが31回乃至70回の場合には、データ量中削減DB92を選択することで、データの削減量は「中」であると決定している。
エフェクトデータ削減量決定部72は、エフェクトの再生頻度frequencyが71回以上の場合には、データ量大削減DB91を選択することで、データの削減量は「大」であると決定している。
【0053】
ここで、エフェクトデータ格納DB81は、複数形式の複数種類のエフェクトの各データを格納するデータベースである。
具体的には
図6の対応表が採用される場合、エフェクトデータ格納DB81は、データ量大削減DB91、データ量中削減DB92、データ量小削減DB93、及びデータ量無削減DB94といった4段階のデータベースから構築することができる。
ここで、
図4におけるデータ量大削減DB91、データ量中削減DB92、データ量小削減DB93、及びデータ量無削減DB94の右方にある矢印は、消費電力を表している。データ削減量が大きければGPU24からメモリへのアクセスの総量は小さくなるため、消費電力は小さくなる。これに対して、データ削減量が小さければGPU24からメモリへのアクセスの総量は大きくなるため、消費電力は大きくなる。
データ量大削減DB91は、「大」の削減量(例えば40%程度の削減量)で予め削減されたアセットを格納するデータベースである。データ量大削減DB91が選択された場合、エフェクトの画質は超省電力画質になる。
データ量中削減DB92は、「中」の削減量(例えば20%程度の削減量)で予め削減されたアセットを格納するデータベースである。データ量中削減DB92が選択された場合、エフェクトの画質は省電力画質になる。
データ量小削減DB93は、「小」の削減量で予め削減されたアセット、例えば標準的なデータ量削減手法(減色の手法等)を行った、標準アセットを格納するデータベースである。データ量小削減DB93が選択された場合、エフェクトの画質は標準画質になる。
データ量無削減DB94は、「0」の削減量(即ちデータ量を削減していない)のアセットを格納するデータベースである。データ量無削減DB94が選択された場合、エフェクトの画質は最高画質になる。
これらのデータベースは、
図4の例では記憶部30といった、フラッシュストレージ等の二次記憶上に格納されているが、すべてがSoc11のメモリ上にあっても良い。データの格納場所に関わらず、データ読み込みの総量を減少させることができるため、高い省電力効果を期待することができるからである。
【0054】
以上説明したように、再生要求されたアセットの形式が、予めデータ量を削減できるアセットの形式(例えば、ビットマップデータ、ビデオデータ)の場合、エフェクトデータ削減量決定部72は、再生要求された形式及び種類のエフェクトについて、その再生頻度にとって適切な省電力性能を有するDBを、エフェクトデータ格納DB81の中から選択することで、結果としてデータの削減量を決定する。
エフェクトデータ選択部71は、このようにしてエフェクトデータ削減量決定部72により選択されたDBから、再生要求された形式及び種類のエフェクトのアセットを抽出して、GPU24に提供する。
【0055】
次に、再生要求されたエフェクトの形式がデータ量を動的に削減できるアセットの形式(例えば、シェーダプログラム、ゲームエンジン側で再生フレームを制御するアニメーション)の場合を考える。
【0056】
エフェクトデータ削減量決定部72は、再生要求された形式及び種類のエフェクトについて、エフェクトの再生頻度に応じて、削減するデータ量を決定する。
エフェクトデータ選択部71は、エフェクトデータ格納DB81のうち例えばデータ量無削減DB94から、エフェクトのデータをスキップしながら(間引きしながら)読み込み、データ読み込みの総量を削減する。間引きの間隔等については、エフェクトデータ削減量決定部72により決定されたデータの削減量に基づいて決定される。
間引きして読み込まれたエフェクトのデータ、即ち、エフェクトデータ削減量決定部72により決定された削減量の分だけ削減されたデータが、GPU24に提供される。
【0057】
なお、上述の例では、エフェクトデータ削減量決定部72の読み込み対象のデータベースは、エフェクトデータ格納DB81のデータ量無削減DB94とされたが、特にこれに限定されず、例えば好適な例として、エフェクトデータのスキップ読み込みに対応するための特別なフォーマットで格納されたデータベースを採用してもよい。
【0058】
次に
図7を参照して、
図1のプレイヤー端末1が実行する処理のうち、ゲームのエフェクトを再生するための一連の処理(以下、「エフェクト再生処理」と呼ぶ)について説明する。
即ち、
図7は、エフェクト再生処理の流れの一例を説明するフローチャートである。
エフェクト再生処理は、ゲーム実行開始を契機として開始される。
【0059】
ステップS1において、
図4の表示制御部52は、ゲームのエフェクト再生要求を受け付ける。
【0060】
ステップS2において、エフェクト再生頻度管理部53は、再生要求されたエフェクトについての過去のエフェクトの再生頻度を取得する。なお、過去のエフェクトの再生頻度は、エフェクト再生頻度管理DB54に格納されている。
【0061】
ステップS3において、表示制御部52は、再生要求されたエフェクトの各データがキャッシュ61に格納されているか否かを判断する。
再生要求されたエフェクトの各データがキャッシュ61に格納されている場合には、ステップS3においてYESであると判断されて、処理はステップS9に進む。ステップS9については後述する。
これに対して、再生要求されたエフェクトの各データがキャッシュ61に格納されていない場合には、ステップS3においてNOであると判断されて、処理はステップS4に進む。
【0062】
ステップS4において、表示制御部52は、予めデータ量を削減できる各データがあるか否かを判断する。
再生要求されたエフェクトの形式が、予めデータ量を削減できるアセットの形式(例えば、ビットマップデータ、ビデオデータ)の場合、予めデータ量を削減できる各データがあるとして、ステップS4においてYESであると判断されて、処理はステップS5に進む。
【0063】
ステップS5において、表示制御部52は、ステップS2の処理で取得されたエフェクトの再生頻度にとって適切な省電力性能を有するエフェクトデータ格納DB81を選択する。
即ち、表示制御部52は、データ量大削減DB91、データ量中削減DB92、データ量小削減DB93、及びデータ量無削減DB94の中から、適切な省電力性能を有するものを選択する。
【0064】
ステップS6において、表示制御部52は、適切な省電力性能を有するエフェクトデータ格納DB81から、再生要求されたエフェクトの各データを読み込む。
その後、処理はステップS9に進む。ステップS9については後述する。
【0065】
これに対して、再生要求されたエフェクトの形式がデータ量を動的に削減できるアセットの形式(例えば、シェーダプログラム、ゲームエンジン側で再生フレームを制御するアニメーション)の場合、予めデータ量を削減できる各データがないとして、ステップS4においてNOであると判断されて、処理はステップS7に進む。
【0066】
ステップS7において、表示制御部52は、読み込み対象のエフェクトデータ格納DB81を選択する。例えば、エフェクトデータ削減量決定部72は、データ量無削減DB94を選択する。
【0067】
ステップS8において、表示制御部52は、選択したエフェクトデータ格納DB81から、再生要求されたエフェクトの各データをスキップしながら読み込む。その後、処理は、ステップS9に進む。
【0068】
ステップS9において、GPU24は、CPU21の表示制御部52により読み込まれた又はキャッシュ61に格納されていた、エフェクトの各データを用いて、レンダリングを開始する。
ステップS10において、GPU24は、エフェクトを再生する。
【0069】
ステップS11において、エフェクト再生頻度管理部53は、ステップS10の処理で再生されたエフェクトの再生頻度を更新する。なお、更新されたエフェクト再生も頻度は、エフェクト再生頻度管理DBに上書きされる。
これにより、エフェクト再生処理は終了となる。
【0070】
以上本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。
【0071】
また、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
換言すると、
図3の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に
図3の例に限定されない。また、機能ブロックの存在場所も、
図3に特に限定されず、任意でよい。
具体的には例えば、
図3に示す各機能ブロックは、上述の実施形態ではネイティブアプリケーションとしてプレイヤー端末1に備えられていたが、HTMLとJavaScript(登録商標)を用いてWebアプリケーションとして実装することで、図示せぬサーバ等に備えることもできる。
また、1つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。
【0072】
一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えば
図1のプレイヤー端末1や図示せぬサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。
【0073】
このようなプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。
【0074】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。
【0075】
換言すると、本発明が適用される情報処理プログラムは、上述の実施形態としてのプレイヤー端末1に適用されるものを含め、次のような構成を有する各種各様の実施形態を取ることができる。
即ち、本発明が適用される情報処理プログラムは、
プレイヤーによって操作され、エフェクトが繰り返し再生されるゲームを実行するための端末に、
複数形式の複数種類のエフェクトの各データを格納するメモリ(例えば
図4のエフェクトデータ格納DB81を有するメモリ)と、
前記複数形式の複数種類のエフェクトのうち、再生要求された形式及び種類のエフェクトのデータを含む画像のデータに対して、所定の画像処理を施すGPU(例えば
図1のGPU24)と、
前記GPUの画像処理の結果に基づいて、再生要求された前記形式及び前記種類のエフェクトを含む画像を表示させる表示媒体(例えば
図1のタッチ操作入力部27及び表示部28からなるタッチパネル)と、
を備える端末(例えば
図1のプレイヤー端末1)、又は当該端末を制御する情報処理装置に、
前記複数形式毎及び前記複数種類毎に、エフェクトの再生頻度を計測し、それらの計測結果を管理する頻度管理ステップ(例えば
図4のエフェクト再生頻度管理部53が実行するステップ)と、
再生要求された前記形式及び前記種類について、前記再生頻度に応じてデータ量が削減されたエフェクトのデータを用いて、当該エフェクトを含む前記画像を前記GPUを介して前記表示媒体に表示させる制御を実行する表示制御ステップ(例えば
図4の表示制御部52が実行するステップ)と、
を含む制御処理を実行させるプログラムである。
このように、プログラムを実行させるコンピュータは、上述した様に、
図1のプレイヤー端末1等の端末のみならず、当該端末を制御する情報処理装置、即ち、図示せぬサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。
【0076】
このようにして、継続的にタスクが実行されるゲームに対して有効な、端末の省電力化が可能になる。
【0077】
即ち、ゲームのグラフィックのエフェクトは、GPU24からメモリへのアクセス量が多いため、ゲーム実行中のプレイヤー端末1にとっての大電力消費要因の一つである。一方、ゲームのグラフィックのエフェクトは、ゲームの面白さや魅力に直結するものであるが、当該ゲーム内で頻繁に再生されるとプレイヤーがあまり注意を払わなくなってしまう。
そこで、本発明が適用されるプログラムは、エフェクトの再生頻度に応じて、当該エフェクトのデータを自動で削減して、GPU24からメモリへのアクセス回数を減少させることで、省電力化を図ることができる。このとき、データ量が大きく削減されるエフェクトは、プレイヤーがあまり注意を払わなくなったものである。換言すると、プレイヤーが注意を払っているエフェクトについては、データ量は削減されず高画質で提示される。
このようにして、本発明が適用されるプログラムは、魅力的なグラフィックのエフェクトのプレイヤーへの提示と、省電力とを自動的に両立できるという効果を奏する。
【0078】
また、従来の省電力化技術としては、動的電圧・周波数制御(DVFS:Dynamic Voltage and Frequency Scaling)が良く知られている。DVFSは、GPUへの供給電圧及び動作周波数を、OSから得られるシステム情報を用いて動的に制御することにより、消費電力を削減する。DVFSは有効な省電力化手法であり、スマートフォン用GPUに幅広く採用されている。
しかしながら、ゲームはGPUを使い続けるソフトウェアであるため、DVFSのみでは十分な省電力化を達成することはできず、プレイヤーが、バッテリー残量を気にせずゲームをプレイできる環境は実現されていない。
以上のことから、ゲームは一定時間継続して実行されるアプリケーションであるため、スマートフォン上で動作するゲームで適用可能な省電力化の技術は重要な要素である。本発明が適用される上述のプログラムにより、このような技術が実現可能になる。
【0079】
前記プログラムは、
第1形式の第1種類のエフェクトについては、データ量が削減されていないデータと、データ量が予め削減されたデータとが予め前記メモリに記憶されており、
前記表示制御ステップは、前記第1形式の前記第1種類のエフェクトの再生頻度が一定量を超えたときに再生要求された場合、前記データ量が予め削減されたエフェクトのデータを用いて、前記制御を実行するステップを含む、
ようにすることができる。
第1形式が、予めデータ量を削減できるアセットの形式(例えば、ビットマップデータ、ビデオデータ)である場合に、より適切な省電力の制御を実行することができる。
【0080】
前記表示制御ステップは、第2形式の第2種類のエフェクトの再生頻度が一定量を超えたときに再生要求された場合、前記エフェクトのデータを削減する処理を実行し、当該処理後の当該エフェクトのデータを用いて、前記制御を実行するステップを含む、
ようにすることができる。
第2形式が、データ量を動的に削減できるアセットの形式(例えば、シェーダプログラム、ゲームエンジン側で再生フレームを制御するアニメーション)の場合に、より適切な省電力の制御を実行することができる。
【0081】
前記表示制御ステップは、再生要求された前記形式及び前記種類のエフェクトのデータが前記GPUのキャッシュに存在する場合、当該キャッシュに存在する当該エフェクトのデータを用いて、前記制御を実行するステップを含む、
ようにすることができる。
この場合、GPUからメモリへのアクセスが原則発生しないため、省電力の効果が非常に大きなものとなる。
【0082】
また、前記プログラムは、
再生要求された前記形式及び前記種類のエフェクトについて、前記再生頻度に応じて削減するデータ量を決定する削減量決定量ステップ(例えば
図4のエフェクトデータ削減量決定部72のステップ)を、
さらに含み、
前記表示制御ステップは、前記削減量決定量ステップの処理で決定され前記データ量分だけ削減された前記エフェクトのデータを用いて、前記制御を実行する(例えば
図4の表示制御部52が実行するステップ)、
ことができる。
【0083】
これにより、より適切なデータの削減量が決定されるので、省電力が効率的なものとなる。
なお、ここでいう「データの削減量」は、これから削減される量のみならず、予め削減されている量も含む広義な概念である。
即ち、上述した様に、再生要求される形式としては、予めデータ量を削減できるアセットの形式(例えば、ビットマップデータ、ビデオデータであり、上述の第1の形式)と、データ量を動的に削減できるアセットの形式(例えば、シェーダプログラム、ゲームエンジン側で再生フレームを制御するアニメーションであり、上述の第2の形式)とが存在する。
第1の形式のエフェクトが再生要求された場合、削減量決定ステップとして、複数のDBの中から、所定の削減量で予め削減されたデータ(アセット)が格納されたDBを決定するステップを採用することで、当該所定の削減量をデータの削減量として決定するのと等価な処理が実現可能になる。
第2の形式のエフェクトが再生要求された場合、削減量決定ステップとして、データの削減量を動的に決定するステップを採用することができる。
【0084】
さらに、前記端末は、充電式の電力供給部をさらに備え、
前記頻度管理ステップは、前記電力供給部の充電度合に基づいて、前記エフェクトの再生頻度の計測の開始及び終了のタイミングを制御するステップをさらに含むようにすることができる。
例えば、エフェクトの再生頻度の計測の開始及び終了のタイミングとして、一日の終了や始まりを採用した例が、上述の
図5の例である。
図5の例で上述した様に、特定の個人に特化した省電力化を図ることが容易にできる。これにより、プレイヤー個人の生活スタイル、及び、パーティ構成等のゲームプレイスタイルに合わせた省電力化を自動的に実現することが可能となる。
【解決手段】表示制御部52は、再生要求された複数形式及び複数種類について、エフェクトの再生頻度に応じてデータ量が削減されたエフェクトのデータを用いて、エフェクトを含む再生要求された画像をGPU24を介して表示媒体に表示させる制御を実行する。即ち、表示制御部52は、再生要求された形式及び種類のエフェクトについて、エフェクトの再生頻度に応じて削減するデータ量を決定し、そのデータ量分だけデータが削減されたエフェクトのデータを、エフェクトデータ格納DB81から抽出して、GPU24に提供する。