JP2017018530A - ゲーム装置、ゲームサーバ、及びプログラム - Google Patents

Abstract

【課題】多数の画像の表示が必要なゲームであっても、ファイルサイズの制限内に抑えつつ表示品位の悪化を抑制すること。【解決手段】ゲーム装置は、複数のキャラクタをそれぞれ含む所定数のグループを用いて進行するゲームにおいて、グループにそれぞれ含まれる複数のキャラクタのうち、特定のキャラクタに対応するオブジェクトの画像を第１の画像サイズで取得し、他のキャラクタに対応するオブジェクトの画像を第１の画像サイズとは異なる第２の画像サイズで取得する画像取得部と、画像取得部が取得した前記グループごとの画像を、ゲームの進行に応じて表示部に表示する表示制御部と、を備える。【選択図】図４

Description

本発明は、ゲーム装置、ゲームサーバ、及びプログラムに関する。

ゲームサーバから端末装置に提供されるブラウザ型のゲームでは、Ｆｌａｓｈ（登録商標）に準拠したＳＷＦ形式のデータファイルをゲームサーバから端末装置に送信することにより端末装置にゲーム画面が表示されるものがある（例えば、特許文献１）。例えば、Ｆｌａｓｈ（登録商標）を用いたバトルゲームの演出において、１チームについて最大１０枚のキャラクタカードが登場する場合、１チーム（１ユーザのデッキ）対１チームのバトルでは、２チーム分の最大２０枚のキャラクタカードが登場する。従来、最大２０枚でのバトルを実現している場合には、データファイルのファイルサイズの上限（例えば、１００ＫＢ）について問題は生じなかった。

特開２０１３-４１３３７号公報

しかしながら、例えば、３チーム対３チームのバトルを実現する場合には、最大６０枚のキャラクタカードが登場することになるため、キャラクタカードの画像の容量が増大し、ファイルサイズの上限を超えてしまうという問題が生じる。そこで、一つの解決方法として、キャラクタカードの画像の容量を減らす方法が考えられるが、単純に容量を減らすだけでは画像が劣化してしまいゲーム画面の表示品位が悪化してしまう懸念がある。

本発明のいくつかの態様は、多数の画像の表示が必要なゲームであっても、ファイルサイズの制限内に抑えつつ表示品位の悪化を抑制するゲーム装置、ゲームサーバ、制御方法、及びプログラムを提供することを目的の一つとする。

また、本発明の他の態様は、後述する実施形態に記載した作用効果を奏することを可能にするゲーム装置、ゲームサーバ、及びプログラムを提供することを目的の一つとする。

上述した課題を解決するために、本発明の一態様は、複数のキャラクタをそれぞれ含む所定数のグループを用いて進行するゲームにおいて、前記グループにそれぞれ含まれる複数のキャラクタのうち、特定のキャラクタに対応するオブジェクトの画像を第１の画像サイズで取得し、他のキャラクタに対応するオブジェクトの画像を前記第１の画像サイズとは異なる第２の画像サイズで取得する画像取得部と、前記画像取得部が取得した前記グループごとの画像を、ゲームの進行に応じて表示部に表示する表示制御部と、を備えるゲーム装置である。

また、本発明の一態様は、複数のキャラクタをそれぞれ含む所定数のグループを用いて進行するゲームにおいて、前記グループにそれぞれ含まれる複数のキャラクタのうち、特定のキャラクタに対応するオブジェクトの画像を第１の画像サイズで出力し、他のキャラクタに対応するオブジェクトの画像を前記第１の画像サイズとは異なる第２の画像サイズで出力するとともに、出力先の端末装置の表示部において、前記第１の画像サイズで出力する画像と、前記第２の画像サイズで出力する画像とを、前記ゲームの進行に応じて表示させるための制御情報を出力する出力部、を備えるゲームサーバである。

また、本発明の一態様は、コンピュータを、上記記載のゲーム装置として機能させるためのプログラムである。

ゲームシステムの構成の一例を示すブロック図。 画像ファイルに基づくゲーム画面の一例を示す図。 キャラクタ画像を縮小する方法の一例を説明する説明図。 ユーザ端末及びゲームサーバの構成の一例を示すブロック図。 画像ファイル生成処理の一例を示すフローチャート。 画像データ結合処理の一例を示すフローチャート。 画像ファイルの表示処理の一例を示すフローチャート。

以下、本発明の一実施形態について、図面を参照して説明する。
まず、ゲームシステム１の全体構成の概要を説明する。図１は、本実施形態に係るゲームシステム１の構成の一例を示すブロック図である。ゲームシステム１は、ユーザ端末１０−１と、ユーザ端末１０−２と、ユーザ端末１０−３、・・・と、ゲームサーバ３０とのコンピュータ装置を備えており、これらのコンピュータ装置はネットワークＮＷを介して接続される。ユーザ端末１０−１と、ユーザ端末１０−２と、ユーザ端末１０−３とは同様の構成であるため、特に区別しない場合には、「−１」、「−２」等の記載を省略してユーザ端末１０として説明する。ここでは３台のユーザ端末１０を図示しているが、任意の台数のユーザ端末１０がゲームサーバ３０に接続されてもよい。

例えば、ユーザ端末１０は、ユーザが利用するコンピュータ装置であり、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、タブレットＰＣ、スマートフォンやフィーチャーフォン等の携帯電話機、携帯情報端末（ＰＤＡ：Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）等が適用できる。

ゲームサーバ３０は、ユーザ端末１０にゲームを提供するサーバ装置である。例えば、ゲームサーバ３０は、ユーザ端末１０にブラウザゲームを提供するウェブサーバである。ブラウザゲームは、ゲームを実行するための専用のプログラムをダウンロードすることが不要なゲームであって、ユーザ端末１０においてウェブブラウザを実行することによりウェブブラウザ上に表示されるゲーム画面でプレイすることが可能なゲームである。例えば、ゲームサーバ３０は、ユーザ端末１０に対するユーザの操作入力に基づいてゲームの各種の処理を実行し、ゲームの進行に応じてゲーム画面をユーザ端末１０に表示させる。

本実施形態では、ユーザが所持する複数のキャラクタカードの中から対戦（以下、「バトル」ともいう）に用いるカードをデッキにセットし、デッキにセットされたカードのキャラクタと、対戦相手のユーザのデッキにセットされたカードのキャラクタとがバトルを行うバトルゲームを例に説明する。キャラクタとは、ゲーム内に登場する人物、動物、物体（例えば、乗り物）などである。ゲームサーバ３０は、バトルを行う際のゲーム画面として表示する画像を示す画像ファイルＸをユーザ端末１０に送信することでユーザ端末１０に画像を表示させる。例えば、画像ファイルＸは、Ｆｌａｓｈ（登録商標）に準拠したＳＷＦ形式のデータファイルである。ユーザ端末１０は、ＳＷＦ形式のデータファイルを再生するソフトウェア（Ｆｌａｓｈプレイヤ）を実行することで、ゲームサーバ３０から受信した画像ファイルＸが示す画像を表示する。

本実施形態に係るバトルゲームの例は、デッキにセットされた複数のキャラクタをそれぞれ含む所定数のチームを用いて進行するゲームである。ここで、チームとは、複数のキャラクタを含むグループの一例であって、例えば、１人のユーザの１つのデッキにセットされているカードのキャラクタで構成される単位が１つのチームに相当する。１つのデッキ（即ち、１つのチーム）には、チームのリーダーとなるキャラクタのカード（以下、「リーダーカード」ともいう）を１枚と、リーダー以外のキャラクタのカード（即ち、リーダーカード以外のキャラクタカード）を最大で９枚（合計で最大１０枚のキャラクタカード）と、をセットすることができる。例えば、バトルゲームのゲーム画面には、対戦するチームごとのデッキにセットされたキャラクタカードに対応するキャラクタ画像が表示される。

また、本実施形態のバトルゲームでは、プレイ可能な期間や条件に制限が無い通常のバトル（以下、「通常バトル」ともいう）と、特定の期間や特定の条件を満たしたときのみプレイ可能なバトル（以下、「イベントバトル」ともいう）とをプレイできる。例えば、通常バトルでは、１チーム対１チームのバトルが行われる。一方、イベントバトルでは、３チーム対３チームのバトルが行われる。

図２は、画像ファイルＸに基づいてユーザ端末１０に表示されるゲーム画面の一例を示す図である。図示するバトル画面Ｇ１０は、バトルの際に表示されるゲーム画面の一例であり、チームＡ、Ｂ、Ｃの３チームと、チームＤ、Ｅ、Ｆの３チームとによる３チーム対３チームのイベントバトルの画面の一例を示している。バトル画面Ｇ１０の下半分には、ユーザのチームを含むチームＡ、Ｂ、Ｃのそれぞれのチーム編成を示すキャラクタ画像が表示される。具体的には、各チームのチーム編成として、デッキにセットされているリーダーカードに対応するキャラクタ画像ＣＬの１枚と、リーダーカード以外にデッキにセットされているキャラクタカードに対応するキャラクタ画像Ｃ１〜Ｃ９の最大で９枚とが表示されている。一方、バトル画面Ｇ１０の上半分には、チームＡ、Ｂ、Ｃと対戦する対戦相手のチームＤ、Ｅ、Ｆのそれぞれのチーム編成を示すキャラクタ画像が、同様に表示される。例えば、バトル画面Ｇ１０において、リーダーカードのキャラクタ画像ＣＬは、バトルにおいて中心となるキャラクタを示す画像であるため、他のキャラクタ画像Ｃ１〜Ｃ９よりも大きく表示される。

なお、この図に示すバトル画面Ｇ１０は、イベントバトルのバトル画面であるため、６チーム分のキャラクタ画像が表示されているが、通常バトルの場合には２チーム分のキャラクタ画像が表示されることになる。

ところで、３チーム対３チームのイベントバトルの場合には、図２に示すように、６チーム分の最大６０枚のキャラクタカードに対応するキャラクタ画像が必要になる。例えば、キャラクタ画像の１枚当たりのデータサイズを２ＫＢ（キロバイト）とすると、バトル画面Ｇ１０を表示させる画像ファイルＸのファイルサイズは、キャラクタ画像のデータサイズのみでも１２０ＫＢ（２ＫＢ×１０枚×６チーム）となり、その他に付随情報（ヘッダ、データサイズ等の情報）やキャラクタ画像が示すキャラクタの動作を定義する動作規定データ（例えば、スクリプト）等もさらに加わる。

これに対して、携帯端末ごとに通信できるファイルサイズには制限があり、その制限を超えると必要なキャラクタ画像による画面の演出ができなくなる。携帯端末によって制限の値は異なるが、制限の厳しいものは例えば１００ＫＢに制限されるものがある。そのため、上述したように３チーム対３チームのイベントバトルの場合には、ファイルサイズの制限（例えば、１００ＫＢ）を越えてしまう場合がある。

そこで、本実施形態では、ゲームサーバ３０は、デッキにセットされている最大１０枚のキャラクタカードのうち、リーダーカード以外の他のキャラクタカードに対応するキャラクタ画像の画像サイズを縮小することにより、バトル画面Ｇ１０を表示するための画像ファイルＸのファイルサイズを制限内に収まるよう縮減してゲームサーバ３０からユーザ端末１０へ送信する。

図３は、キャラクタ画像を縮小する方法の一例を説明する説明図である。ゲームサーバ３０は、各チームのリーダーカードのキャラクタ画像ＣＬ（６チーム分で６枚）の画像サイズはそのままにして表示品位を保ちつつ、他のカードのキャラクタ画像Ｃ１〜Ｃ９（６チーム分で５４枚）の画像サイズを縮小する。

ゲームサーバ３０は、リーダーカード以外の他のカードのキャラクタ画像Ｃ１〜Ｃ９の９枚の画像を１枚の画像に結合した結合画像を生成する。例えば、ゲームサーバ３０は、符号Ｓ１に示すように、キャラクタ画像Ｃ１〜Ｃ９の９枚を「縦３枚×横３枚」に並べてシート状に配置した結合画像（以下、「シート画像」ともいう）を生成する。例えば、ゲームサーバ３０は、チームごとに９枚のキャラクタ画像Ｃ１〜Ｃ９を１枚のシート画像Ｓ１とすることで、６チーム分のシート画像Ｓ１を生成する。

シート画像Ｓ１におけるキャラクタ画像Ｃ１〜Ｃ９の並び順は、任意の並び順とすることができるが、図示する例では、左から右へ且つ上から下への並び順としている。このように、９枚のキャラクタ画像Ｃ１〜Ｃ９を１枚のシート画像Ｓ１とすることのみでも、ファイルの数が９つから１つに減り、ファイルごとに必要なヘッダ情報等の容量を削減することができる。また、ファイルの数を１つにすることで、単位画像あたりの容量を減らすことが容易となる。

また、ゲームサーバ３０は、符号ＳＳ１に示すように、シート画像Ｓ１の画像サイズを縮小したシート画像（以下、「縮小シート画像」ともいう）を生成する。縮小シート画像ＳＳ１の画像サイズは、例えば、縮小シート画像ＳＳ１と、６枚のリーダーカードのキャラクタ画像ＣＬと、その他の付随情報や動作規定データ等を合計したファイルサイズがファイルサイズの制限（例えば、１００ＫＢ）内に収まるような画像サイズである。

なお、ゲームサーバ３０は、縮小シート画像ＳＳ１及びリーダーカードのキャラクタ画像ＣＬに対して画像圧縮処理を行ってもよい。即ち、縮小シート画像ＳＳ１の画像サイズは、圧縮後の縮小シート画像ＳＳ１と、６枚のリーダーカードの圧縮後のキャラクタ画像ＣＬと、その他の付随情報や動作規定データ等を合計したファイルサイズがファイルサイズの制限内に収まるような画像サイズであってもよい。なお、縮小シート画像ＳＳ１に対する圧縮率は、リーダーカードのキャラクタ画像ＣＬに対する圧縮率と同じとしてもよいし、キャラクタ画像ＣＬに対する圧縮率よりも高くしてもよい。

このように、イベントバトルの場合には、通常バトルの際に表示するキャラクタ画像の画像サイズのままではファイルサイズの制限（例えば、１００ＫＢ）を越えてしまうため、ユーザ端末１０は、ファイルサイズの制限内に縮減された画像ファイルＸを取得する。この場合、ユーザ端末１０は、リーダーカードのキャラクタ画像ＣＬの画像サイズを変更しないで、リーダーカード以外の他のキャラクタ画像Ｃ１〜Ｃ９の画像サイズを縮小することでファイルサイズが縮減された（例えば、約９５ＫＢに減縮された）画像ファイルＸを取得する。これにより、ユーザ端末１０は、ファイルサイズの制限内でゲーム画面に表示するキャラクタ画像を取得できるとともに、ゲーム画面の表示品位の悪化を抑制することができる。

なお、キャラクタカードの種類ごとに背景色が異なる場合には、キャラクタ画像Ｃ１〜Ｃ９を並べたときに隣り合う画像の背景色が、赤と黄色、赤と緑等のように異なる場合がある。仮に、間隔を空けずにキャラクタ画像Ｃ１〜Ｃ９を並べた場合には、縮小したときや圧縮したときに、隣接する画像の境界が１ピクセル以上にまたがり、その結果色が混じって滲みが生じ、隣接する画像の境界の判別が困難になる場合がある。
そこで、本実施形態では、ゲームサーバ３０は、キャラクタ画像Ｃ１〜Ｃ９を並べて配置したシート画像Ｓ１を生成する際に、隣り合う画像どうしの間に所定の間隔（例えば、４ピクセル）を空けて配置する。これにより、本実施形態では、シート画像Ｓ１を生成する際に、隣り合う画像どうしの間に余白が設けられるため、隣り合う画像の境界で滲みが発生せず、画像の表示品位を保つことができる。

〔ゲームシステムの構成〕
次に、図４を参照して、ゲームシステム１が備えるユーザ端末１０及びゲームサーバ３０の機能構成について説明する。図４は、ゲームシステム１が備えるユーザ端末１０及びゲームサーバ３０の構成の一例を示すブロック図である。

〔ユーザ端末１０の構成〕
まず、ユーザ端末１０の構成について説明する。ユーザ端末１０は、例えば、通信部１２と、入力部１３と、表示部１４と、記憶部１５と、制御部１１０とを備え、ネットワークＮＷを介して接続されたゲームサーバ３０や他の装置等と通信部１２を介して通信を行う。通信部１２は、例えば、複数のイーサネット（登録商標）ポートや複数のＵＳＢ等のデジタル入出力ポート等を含んで構成される。

入力部１３は、例えば、タッチパネルとしてディスプレイ（表示部１４）と一体に構成されており、ユーザの操作により各種の指示が入力される。また、入力部１３は、キーボードやマウス、タッチパッドや、音声により各種の指示が入力されるマイクロホンなど、その他の入力装置であってもよい。
表示部１４は、画像やテキスト等の情報を表示するディスプレイであり、例えば、液晶ディスプレイパネル、有機ＥＬ（ＥｌｅｃｔｒｏＬｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイパネルなどを含んで構成される。

記憶部１５は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ-Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ-Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などを含み、ユーザ端末１０が処理する各種情報や画像、各種アプリケーションのプログラム等を記憶する。なお、記憶部１５は、ユーザ端末１０に内蔵されるものに限らず、ＵＳＢ等のデジタル入出力ポート等によって接続された外付け型の記憶装置でもよい。また、ユーザ端末１０は、不図示のスピーカ、音声出力端子、カメラ、ジャイロセンサ、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信モジュールなどのハードウェア構成を含んで構成されてもよい。

制御部１１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を含んで構成され、記憶部１５に記憶されているＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やソフトウェアのプログラムを実行してユーザ端末１０の各部を制御する。例えば、制御部１１０は、画像取得部１１１と、表示制御部１１２とを備え、ゲームサーバ３０から画像ファイルＸを取得して、ゲーム画面を表示部１４に表示させる。

画像取得部１１１は、ゲームサーバ３０から通信部１２を介して画像ファイルＸを取得する。この画像ファイルＸは、ＳＷＦ形式のデータファイルであって、バトルゲームでバトルするチームにそれぞれ含まれる複数のキャラクタのキャラクタ画像が含まれる。例えば、通常バトル（１チーム対１チームのバトル）の場合には、画像取得部１１１は、各チームのそれぞれに含まれる複数のキャラクタに対応するキャラクタ画像を、それぞれ同じ画像サイズで取得する。一方、イベントバトル（３チーム対３チームのバトル）の場合には、画像取得部１１１は、各チームにそれぞれ含まれる複数のキャラクタのうち、リーダーカードに対応するキャラクタ画像ＣＬを第１の画像サイズで取得し、他のキャラクタカードに対応するキャラクタ画像Ｃ１〜Ｃ９を第１の画像サイズとは異なる第２の画像サイズで取得する。

例えば、第１の画像サイズは、通常バトルで取得するキャラクタ画像の画像サイズと同じサイズであり、例えば、ゲームサーバ３０に記憶されているキャラクタ画像の標準の画像サイズである。第２の画像サイズは、例えば、第１の画像サイズより小さい画像サイズであって、図３に示す縮小シート画像ＳＳ１に配置されている各キャラクタ画像の画像サイズである。

表示制御部１１２は、ＳＷＦ形式のデータファイルを再生するソフトウェア（Ｆｌａｓｈプレイヤ）を実行することで実現する機能の一つとして、画像取得部１１１が取得した画像ファイルＸを再生して表示部１４に表示する。例えば、表示制御部１１２は、画像取得部１１１が取得した画像ファイルＸに基づいて、各チームに含まれるキャラクタ画像を、バトルゲームの進行に応じて表示部１４に表示する（図２のバトル画面Ｇ１０参照）。また、画像取得部１１１が縮小シート画像ＳＳ１を取得した場合には、表示制御部１１２は、他のキャラクタカードに対応するキャラクタ画像Ｃ１〜Ｃ９のそれぞれを表示する際に、縮小シート画像ＳＳ１に対してそれぞれ表示するキャラクタ画像以外をマスクする。

〔ゲームサーバ３０の構成〕
次に、ゲームサーバ３０の構成について説明する。ゲームサーバ３０は、サーバ通信部３４と、サーバ記憶部３５と、サーバ制御部３１０と、を備えている。サーバ通信部３４は、例えば、複数のイーサネット（登録商標）ポートや複数のＵＳＢ等のデジタル入出力ポート等を含んで構成され、ネットワークＮＷを介して接続されたユーザ端末１０や他の装置等と通信を行う。

サーバ記憶部３５は、例えば、ＨＤＤやＳＳＤ、ＥＥＰＲＯＭ、ＲＯＭ、ＲＡＭなどを含み、ゲームサーバ３０が処理する各種情報や画像、プログラム等や、ユーザ端末１０から取得したユーザ情報などを記憶する。なお、サーバ記憶部３５は、ゲームサーバ３０に内蔵されるものに限らず、ＵＳＢ等のデジタル入出力ポート等によって接続された外付け型の記憶装置でもよい。

例えば、サーバ記憶部３５は、デッキ情報記憶部３５１と、表示画像記憶部３５２と、シート画像記憶部３５３と、テンプレート記憶部３５４とを備えている。
デッキ情報記憶部３５１は、ユーザごとのデッキにセットされたキャラクタカードを示すデッキ情報を記憶する。例えば、デッキ情報には、ユーザの識別情報（例えば、ユーザＩＤ）と、デッキの識別情報（例えば、デッキＩＤ）と、デッキにセットされたキャラクタカードの識別情報（例えば、カードのシリアルＩＤ）とが関連付けられている。また、デッキ情報において、デッキにセットされたキャラクタカードの識別情報は、リーダーカードと他のキャラクタカードとで区別可能に関連付けられている。このデッキ情報を参照することで、バトルゲームで対戦する各チームのチーム編成（各チームに含まれるキャラクタ）がわかる。

表示画像記憶部３５２は、バトルゲームで使用するキャラクタカードのキャラクタ画像、及びゲーム画面（例えば、図３のバトル画面Ｇ１０）に表示される背景画像、アイコン、文字等のデータを記憶する。ここで、表示画像記憶部３５２に記憶されているキャラクタ画像の画像サイズは、例えば、通常バトルの際に送信されるキャラクタ画像として予め設定された標準の画像サイズ（第１の画像サイズ）である。

シート画像記憶部３５３は、イベントバトルの際に生成される縮小シート画像ＳＳ１のデータを記憶する。例えば、イベントバトルが実行されたときに生成された縮小シート画像ＳＳ１は、シート画像記憶部３５３に記憶され、その後のイベントバトルで同じチームが再びイベントバトルに参加する際に利用される。

テンプレート記憶部３５４は、画像ファイルＸを生成する際にテンプレートとして利用するテンプレートデータを記憶する。例えば、テンプレートデータは、ゲーム画面の種類ごとに用意されており、それぞれのテンプレートデータごとに特有なヘッダ情報と、動作規定データと、画像データ群とが含まれる。画像データ群には、ゲーム画面の背景画像と、ゲーム画面に表示するキャラクタ画像に対応するダミー画像とが含まれる。このテンプレートデータのダミー画像を、ゲーム画面に表示したいキャラクタ画像に置換してユーザ端末１０に送信することで、ゲーム画面に所望のキャラクタ画像を表示することができる。

例えば、イベントバトルの際に表示されるバトル画面Ｇ１０（図２参照）を表示するための画像ファイルＸの画像データ群には、バトル画面Ｇ１０の背景画像と、バトルする６チーム分のキャラクタ画像に対応するダミー画像が含まれる。具体的には、各チーム１枚のリーダーカードのキャラクタ画像ＣＬの６枚（６チーム分）と、各チーム９枚の他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９が並んで配置された縮小シート画像ＳＳ１の６枚（６チーム分）とに対応するダミー画像が含まれる。一方、通常バトルの場合には、各チーム１枚のリーダーカードのキャラクタ画像ＣＬの２枚（２チーム分）と、各チーム９枚の他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９の１８枚（２チーム分）とに対応するダミー画像が含まれる。

サーバ制御部３１０は、サーバ記憶部３５に記憶されている各種情報に基づいて、画像ファイルＸを生成して、サーバ通信部３１を介してユーザ端末１０に送信する。例えば、サーバ制御部３１０は、データ処理部３１１と、データ出力部３１２とを備えている。

データ処理部３１１は、表示するゲーム画面に応じて、テンプレート記憶部３５４に記憶されているテンプレートデータの中から画像ファイルＸの生成に使用するテンプレートデータを特定する。また、データ処理部３１１は、バトルで対戦するチームのデッキ情報に基づいて特定した各チームのキャラクタ画像を表示画像記憶部３５２から取得する。そして、データ処理部３１１は、特定したテンプレートデータ内の変更対象となるダミー画像を、取得した各チームのキャラクタ画像に置換して画像ファイルＸを生成する。

また、データ処理部３１１は、イベントバトルの場合には、リーダーカード以外の他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９が並んで配置されたシート画像Ｓ１を生成する。さらに、データ処理部３１１は、生成したシート画像Ｓ１の画像サイズを縮小した縮小シート画像ＳＳ１を生成する。そして、データ処理部３１１は、特定したテンプレートデータのダミー画像を、リーダーカードのキャラクタ画像ＣＬと他のキャラクタカードの縮小シート画像ＳＳ１とに置換して画像ファイルＸを生成する。なお、データ処理部３１１は、シート画像Ｓ１から縮小シート画像ＳＳ１を生成する際に、画質（明るさ、色相等）の調整を行ってもよい。

データ出力部３１２は、データ処理部３１１が生成した画像ファイルＸを、サーバ通信部３４を介してユーザ端末１０に送信する。例えば、イベントバトルの場合には、データ出力部３１２は、リーダーカードのキャラクタ画像ＣＬを第１の画像サイズで送信し、他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９を第１の画像サイズより縮小した第２の画像サイズで送信する。また、データ出力部３１２は、第１の画像サイズで送信したキャラクタ画像ＣＬと、第２の画像サイズで送信したキャラクタ画像Ｃ１〜Ｃ９とをゲームの進行に応じて表示させるための制御情報として、画像ファイルＸに含まれる動作規定データを送信する。

なお、通常バトルの場合には、データ出力部３１２は、リーダーカードのキャラクタ画像ＣＬ及び他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９を第１の画像サイズで送信するとともに、第１の画像サイズで送信した各キャラクタ画像をゲームの進行に応じて表示させるための制御情報として、画像ファイルＸに含まれる動作規定データを送信する。

〔画像ファイル生成処理〕
次に、本実施形態に係るゲームサーバ３０が画像ファイルＸを生成する画像ファイル生成処理の動作を説明する。図５は、本実施形態に係る画像ファイル生成処理の一例を示すフローチャートである。この図に示す画像ファイル生成処理は、イベントバトルが選択された場合に画像ファイルＸを生成する処理の一例を示している。

なお、通常バトルとイベントバトルとのいずれが選択されるかは、例えば、バトルゲームにおいてバトルを開始する前に表示されるゲーム画面（例えば、マイページ画面、トップ画面、ホーム画面等）に対するユーザの操作により選択される。例えば、バトルを開始する前に表示されるゲーム画面の「通常バトルの開始ボタン」と「イベントバトルの開始ボタン」とのいずれがユーザにより押下されてからゲームが実行されたかによって選択される。

「通常バトルの開始ボタン」が押下された後に、対戦相手が選択され、デッキ選択によりチーム（バトルに参加する参加キャラクタ）が選択されると、「ゲーム実行ボタン」が表示される。そして、表示された「ゲーム実行ボタン」が押下されると通常バトルが開始され、通常バトルが選択されたことになる。一方、「イベントバトルの開始ボタン」が押下された後に、対戦相手が選択され、デッキ選択によりチーム（参加キャラクタ）が選択されると、「ゲーム実行ボタン」が表示される。そして、表示された「ゲーム実行ボタン」が押下されるとイベントバトルが開始され、イベントバトルが選択されたことになる。
以下の処理は、「イベントバトルの開始ボタン」が押下されたものとして、説明する。

ユーザ端末１０において、ユーザの操作に応じて、対戦相手が選択される（ステップＳ３００）。また、ユーザによりバトルに用いるデッキが選択さることにより、バトルするチーム（参加キャラクタ）が選択される（ステップＳ３０２）。なお、ユーザのチーム以外は、サーバ制御部３１０の制御により自動でバトルするチーム（参加キャラクタ）が選択されてもよい。

対戦相手及びチーム（参加キャラクタ）が選択されると、サーバ制御部３１０は、シート画像記憶部３５３を参照して、チームごとに縮小シート画像ＳＳ１（図３参照）が生成済みであるか否かを判定する（ステップＳ３０４）。縮小シート画像ＳＳ１が生成済みであると判定された場合には（ステップＳ３０４：ＹＥＳ）、サーバ制御部３１０は、ステップＳ３０８に処理を進める。一方、縮小シート画像ＳＳ１が生成済みでないと判定された場合には（ステップＳ３０４：ＮＯ）、サーバ制御部３１０は、画像データ結合処理（ステップＳ３０６）を実行して縮小シート画像ＳＳ１を生成してから、ステップＳ３０８に処理を進める。

〔画像データ結合処理〕
ここで、図６を参照して、図４に示すステップＳ３０６の画像データ結合処理について詳しく説明する。図６は、本実施形態に係る画像データ結合処理の一例を示すフローチャートである。

サーバ制御部３１０は、キャラクタ画像９枚（縦３枚×横３枚）分のサイズと、余白分のサイズとを含む描画領域を用意する（ステップＳ３２０）。
次に、サーバ制御部３１０は、チームごとに、リーダーカード以外の他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９の９枚の画像を描画領域に並べて配置したシート画像Ｓ１（図３参照）を生成する（ステップＳ３２２）。

また、サーバ制御部３１０は、生成したシート画像Ｓ１に対して画像サイズの縮小と、画質の調整を行い、ファイルサイズを縮減した縮小シート画像ＳＳ１を生成する（ステップＳ３２４）。

そして、サーバ制御部３１０は、生成した縮小シート画像ＳＳ１をシート画像記憶部３５３に記憶させる（ステップＳ３２６）。このとき、サーバ制御部３１０は、いずれのチームの縮小シート画像ＳＳ１であるかを特定できるように、ユーザＩＤ及びデッキＩＤ、またはユーザＩＤ及びデッキＩＤに対応する識別情報（例えば、ユーザＩＤ及びデッキＩＤに基づいて新たに生成するチームを一意に識別する識別情報）と関連付けて縮小シート画像ＳＳ１をシート画像記憶部３５３に記憶させる。

上記ステップＳ３２０〜Ｓ３２６の処理により、サーバ制御部３１０は、チームごとの縮小シート画像ＳＳ１を生成して、画像データ結合処理を終了する。

次に、図５に戻り、サーバ制御部３１０は、バトルするチームの数分（例えば６チーム分）の縮小シート画像ＳＳ１を生成済みであるか否かを判定する（ステップＳ３０８）。バトルするチームの数分の縮小シート画像ＳＳ１を生成済みでないと判定された場合には（ステップＳ３０８：ＮＯ）、サーバ制御部３１０は、バトルするチームの数分の縮小シート画像ＳＳ１が生成済みになるまで、ステップＳ３０４に処理を戻す。一方、バトルするチームの数分の縮小シート画像ＳＳ１を生成済みであると判定された場合には（ステップＳ３０８：ＹＥＳ）、サーバ制御部３１０は、テンプレート記憶部３５４を参照して、表示するゲーム画面（例えば、図２のバトル画面Ｇ１０）に応じたテンプレートデータを特定する。また、サーバ制御部３１０は、チームごとにテンプレートデータ内の変更対象となるダミー画像を特定する（ステップＳ３１０）。

そして、サーバ制御部３１０は、チームごとに特定したダミー画像を、チームごとの参加キャラクタのキャラクタ画像に置換する。具体的には、サーバ制御部３１０は、チームごとに、リーダーカードに対応するダミー画像と他のキャラクタに対応するダミー画像とのそれぞれを、リーダーカードのキャラクタ画像ＣＬと他のキャラクタの縮小シート画像ＳＳ１とに置換する（ステップＳ３１２）。

次に、サーバ制御部３１０は、バトルするチームの数分（例えば６チーム分）のテンプレートデータ内の変更対象となるダミー画像を置換済みであるか否かを判定する（ステップＳ３１４）。バトルするチームの数分のダミー画像を置換済みでないと判定された場合には（ステップＳ３１４：ＮＯ）、サーバ制御部３１０は、バトルするチームの数分のダミー画像が置換済みになるまで、ステップＳ３１０に処理を戻す。一方、バトルするチームの数分のダミー画像を置換済みであると判定された場合には（ステップＳ３１４：ＹＥＳ）、サーバ制御部３１０は、置換済みのテンプレートデータを画像ファイルＸとして、サーバ通信部３４を介してユーザ端末１０に送信する（ステップＳ３１６）。

〔画像ファイル表示処理〕
次に、ユーザ端末１０が画像ファイルＸを表示する表示処理の動作について説明する。
図７は、本実施形態に係る画像ファイルＸの表示処理の一例を示すフローチャートである。

ユーザ端末１０において、通常バトルとイベントバトルとのいずれかが選択されると（ステップＳ１００）、制御部１１０は、通常バトルとイベントバトルとのいずれが選択されたかを示す情報を、通信部１２を介してゲームサーバ３０へ送信する。通常バトルが選択された場合には、ゲームサーバ３０は、通常バトル用の画像ファイルＸをユーザ端末１０に送信する。一方、イベントバトルが選択された場合には、ゲームサーバ３０は、イベントバトル用の画像ファイルＸをユーザ端末１０に送信する。

これにより、制御部１１０は、ゲームサーバ３０から通信部１２を介して、画像ファイルＸを取得する。例えば、通常バトルが選択された場合（ステップＳ１０２：通常バトル）、制御部１１０は、画像ファイルＸを取得することにより、リーダーカードのキャラクタ画像ＣＬ及び他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９を、それぞれ同じ画像サイズ（例えば、第１の画像サイズ）で取得する（ステップＳ１０４）。

そして、制御部１１０は、取得した画像ファイルＸに基づいて、各チームに含まれるキャラクタ画像を、バトルゲームの進行に応じてゲーム画面（例えば、通常バトルの１チーム対１チームのバトル画面）に表示する（ステップＳ１０６）。例えば、通常バトルのバトル画面には、各チームの参加キャラクタとして、同じ画像サイズ（例えば、第１の画像サイズ）で取得したリーダーカードのキャラクタ画像ＣＬと他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９とが表示される。また、各キャラクタ画像は、画像ファイルＸに含まれる動作規定データに基づいて表示される。

一方、イベントバトルがユーザにより選択された場合（ステップＳ１０２：イベントバトル）、制御部１１０は、画像ファイルＸを取得することにより、リーダーカードのキャラクタ画像ＣＬを第１の画像サイズで取得し、他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９を第２の画像サイズで取得する（ステップＳ１０８）。例えば、制御部１１０は、他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９が並んで配置された縮小シート画像ＳＳ１を取得することにより、他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９を、第１の画像サイズより小さい第２の画像サイズで取得する。

そして、制御部１１０は、取得した画像ファイルＸに基づいて、各チームに含まれるキャラクタ画像を、バトルゲームの進行に応じてゲーム画面（例えば、イベントバトルの３チーム対３チームのバトル画面Ｇ１０、図２参照）に表示する（ステップＳ１１０）。ここで、制御部１１０は、他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９のそれぞれを表示する際には、縮小シート画像ＳＳ１に含まれるキャラクタ画像Ｃ１〜Ｃ９のうちそれぞれ表示するキャラクタ画像以外をマスクするマスク処理を行う。これにより、ユーザ端末１０は、取得した縮小シート画像ＳＳ１から所望のキャラクタ画像をゲーム画面に表示することができる。

〔実施形態のまとめ〕
（１）以上説明してきたように、本実施形態に係るユーザ端末１０（ゲーム装置の一例）は、画像取得部１１１と、表示制御部１１２とを備えている。画像取得部１１１は、複数のキャラクタをそれぞれ含む所定数のチーム（グループの一例）を用いて進行するゲームにおいて、チームにそれぞれ含まれる複数のキャラクタのうち、特定のキャラクタに対応するキャラクタカード（オブジェクトの一例）の画像を第１の画像サイズで取得する。また、画像取得部１１１は、他のキャラクタに対応するキャラクタカードの画像を第１の画像サイズとは異なる第２の画像サイズで取得する。そして、表示制御部１１２は、画像取得部１１１が取得したチームごとの画像を、ゲームの進行に応じて表示部１４に表示する。

これにより、ユーザ端末１０は、キャラクタに応じて異なる画像サイズのキャラクタ画像を取得するので、特定のキャラクタのキャラクタ画像の表示品位を保ちつつ、他のキャラクタの画像サイズを縮小することでファイルサイズを縮減することができる。よって、本実施形態によれば、ユーザ端末１０は、多数の画像の表示が必要なゲームであっても、ファイルサイズの制限内に抑えつつ表示品位の悪化を抑制することができる。

なお、オブジェクトは、ゲームに登場する実体であって、かつ、画像（テキスト、静止画像、または、動画像）によってユーザに認識されるものである。例えば、キャラクタに対応するオブジェクトは、キャラクタの姿を表したものであってもよいし、キャラクタに対応付けられたカード、メダル、スロット、アイテムなどであってもよい。

（２）特定のキャラクタは、例えば、チーム（グループの一例）に対応するそれぞれのユーザにより予め設定されたキャラクタである。一例として、特定のキャラクタは、ユーザにより予めデッキにセットされたリーダーカードに対応するキャラクタである。また、この場合、他のキャラクタカードのキャラクタ画像の第２の画像サイズは、リーダーカードのキャラクタ画像の第１の画像サイズより小さい画像サイズである。

これにより、ユーザ端末１０は、例えば、バトルで主要なリーダーカードのキャラクタ画像の画像サイズは変えずに、あまり重要ではないリーダーカード以外のキャラクタ画像の画像サイズを縮小して取得することができる。よって、ユーザ端末１０は、主要なリーダーカードのキャラクタ画像の表示品位を保ちつつ、画像ファイルＸのファイルサイズを縮減して、ファイルサイズの制限内で画像を取得することができる。また、例えば、図２に示すバトル画面Ｇ１０では、リーダーカード以外のキャラクタ画像が、リーダーカードのキャラクタ画像より小さく表示されるため、リーダーカード以外のキャラクタ画像の画像サイズを縮小しても、表示品位への影響が少なく、表示品位の悪化を抑制することができる。

なお、上記実施形態では、特定のキャラクタがリーダーカードのキャラクタである例を説明したが、これに限られるものではなく、反対に、特定のキャラクタをリーダーカード以外のキャラクタカードのキャラクタとしてもよい。この場合、他のキャラクタカードがリーダーカードであり、第１の画像サイズを第２の画像サイズより小さい画像サイズとしてもよい。リーダーカードは、主要なキャラクタのカードを示す一例であって、他の呼称であってもよい。例えば、リーダーカードに代えて、ボスカード、キャプテンカード、メインカード等としてもよい。

（３）また、画像取得部１１１は、複数の他のキャラクタに対応するキャラクタカード（オブジェクトの一例）の画像が並んで配置された縮小シート画像ＳＳ１（結合画像の一例）を取得する。表示制御部１１２は、複数の他のキャラクタに対応するキャラクタカードの画像のそれぞれを表示する際に、画像取得部１１１が取得した縮小シート画像ＳＳ１に対してそれぞれ表示する画像以外をマスクする。

これにより、ユーザ端末１０は、縮小シート画像ＳＳ１に含まれる複数のキャラクタ画像のそれぞれの中から、表示したい所望の画像を表示することができる。即ち、ユーザ端末１０は、縮小シート画像ＳＳ１から任意のキャラクタ画像を表示することができる。

（４）また、シート画像Ｓ１（結合画像の一例）において、複数の他のキャラクタに対応するキャラクタカード（オブジェクトの一例）の画像は、所定の間隔を空けて配置されている。これにより、ユーザ端末１０は、シート画像Ｓ１を生成する際に、隣り合う画像どうしの間に余白が設けられるため、隣り合う画像の境界で滲みが発生せず、画像の表示品位を保つことができる。

（５）また、画像取得部１１１は、チーム（グループの一例）のそれぞれに含まれる複数のキャラクタに対応するキャラクタカード（オブジェクトの一例）の画像を、それぞれ同じ画像サイズで取得してもよい。これにより、ユーザ端末１０は、通常バトルのように元々ファイルサイズの制限に問題が無い場合には、各キャラクタ画像を同じ画像サイズで取得することで、処理を簡略化できる。

（６）また、本実施形態に係るゲームは、例えば、対戦型のバトルゲームである。
画像取得部１１１は、プレイ可能な期間に限定のあるバトルゲーム（例えば、イベントバトル）がユーザにより選択された場合、特定のキャラクタに対応するキャラクタカード（オブジェクトの一例）の画像を第１の画像サイズで取得するとともに、他のキャラクタに対応するキャラクタカードの画像を第２の画像サイズで取得する。一方、プレイ可能な期間に限定のないバトルゲーム（例えば、通常バトル）が選択された場合、特定のキャラクタに対応するキャラクタカードの画像、及び他のキャラクタに対応するキャラクタカードの画像を同じ画像サイズで取得する。

これにより、ユーザ端末１０は、バトルゲームの種類（例えば、通常バトルであるかイベントバトルであるか）に応じて、キャラクタによって異なる画像サイズでキャラクタ画像を取得するか、キャラクタによらず同じ画像サイズでキャラクタ画像を取得するかを制御することができる。よって、ユーザ端末１０は、例えば通常バトルとイベントバトルのいずれであっても、ファイルサイズの制限内で画像を取得できるとともに、表示品位の悪化を抑制することができる。

（７）また、本実施形態に係るゲームサーバ３０は、データ出力部３１２（出力部の一例）を備えている。データ出力部３１２は、複数のキャラクタをそれぞれ含む所定数のチーム（グループの一例）を用いて進行するゲームにおいて、チームにそれぞれ含まれる複数のキャラクタのうち、特定のキャラクタに対応するキャラクタカード（オブジェクトの一例）の画像を第１の画像サイズで出力する。また、データ出力部３１２は、他のキャラクタに対応するキャラクタカードの画像を第１の画像サイズとは異なる第２の画像サイズで出力する。さらに、データ出力部３１２は、出力先のユーザ端末１０（端末装置の一例）の表示部１４において、第１の画像サイズで出力する画像と、第２の画像サイズで出力する画像とを、ゲームの進行に応じて表示させるための動作規定データ（制御情報の一例）を出力する。

これにより、ゲームサーバ３０は、ゲーム画面を表示するための画像ファイルＸを出力する際に、キャラクタによって異なる画像サイズでキャラクタ画像を出力するので、特定のキャラクタのキャラクタ画像の表示品位を保ちつつ、他のキャラクタの画像サイズを縮小することでファイルサイズを縮減することができる。よって、本実施形態によれば、ゲームサーバ３０は、多数の画像の表示が必要なゲームであっても、ファイルサイズの制限内で画像を出力することができるとともに、ユーザ端末１０で表示させる画像の表示品位の悪化を抑制することができる。

［変形例］
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成は上述の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

なお、上記実施形態では、３チーム対３チームのイベントバトルの場合に、リーダーカード以外の他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９を縮小する例を説明したが、対戦するチームの数は一例であって、さらに多いチーム数でのイベントバトルであってもよいし、２チーム対２チームのイベントバトルであってもよい。

また、上記実施形態では、１チーム、即ちデッキにセットされるキャラクタカードが最大１０枚である例を説明したが、デッキにセット可能なキャラクタカードの最大数は、任意に決めることができる。また、デッキにセット可能なキャラクタカードの最大数が多く、１チーム対１チームの通常バトルであってもファイルサイズの上限を超えてしまう場合には、通常バトルにおいても、リーダーカード以外の他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９を縮小する構成としてもよい。

なお、上記実施形態では、リーダーカード以外の他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９を結合したシート画像Ｓ１を縮小して縮小シート画像ＳＳ１にしてからゲームサーバ３０からユーザ端末１０に送信する例を説明したが、キャラクタ画像の縮小の方法はこれにかぎられるものではない。例えば、リーダーカード以外の他のキャラクタカードのキャラクタ画像Ｃ１〜Ｃ９を結合しないで、キャラクタ画像Ｃ１〜Ｃ９のそれぞれを縮小してからゲームサーバ３０からユーザ端末１０に送信する構成としてもよい。

また、上述の制御部１１０またはサーバ制御部３１０の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより制御部１１０またはサーバ制御部３１０としての処理を行ってもよい。ここで、「記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行する」とは、コンピュータシステムにプログラムをインストールすることを含む。ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、インターネットやＷＡＮ、ＬＡＮ、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。このように、プログラムを記憶した記録媒体は、ＣＤ−ＲＯＭ等の非一過性の記録媒体であってもよい。また、記録媒体には、当該プログラムを配信するために配信サーバからアクセス可能な内部または外部に設けられた記録媒体も含まれる。配信サーバの記録媒体に記憶されるプログラムのコードは、端末装置で実行可能な形式のプログラムのコードと異なるものでもよい。すなわち、配信サーバからダウンロードされて端末装置で実行可能な形でインストールができるものであれば、配信サーバで記憶される形式は問わない。なお、プログラムを複数に分割し、それぞれ異なるタイミングでダウンロードした後に端末装置で合体される構成や、分割されたプログラムのそれぞれを配信する配信サーバが異なっていてもよい。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

［付記］
以上の記載から本発明は例えば以下のように把握される。なお、本発明の理解を容易にするために添付図面の参照符号を便宜的に括弧書きにて付記するが、それにより本発明が図示の態様に限定されるものではない。

（付記１）本発明の一態様に係るゲーム装置（１０）は、複数のキャラクタをそれぞれ含む所定数のグループを用いて進行するゲームにおいて、前記グループにそれぞれ含まれる複数のキャラクタのうち、特定のキャラクタに対応するオブジェクトの画像を第１の画像サイズで取得し、他のキャラクタに対応するオブジェクトの画像を前記第１の画像サイズとは異なる第２の画像サイズで取得する画像取得部（１１１、Ｓ１０８）と、前記画像取得部が取得した前記グループごとの画像を、ゲームの進行に応じて表示部（１４）に表示する表示制御部（１１２、Ｓ１１０）と、を備える。

付記１の構成によれば、ゲーム装置は、キャラクタに応じて異なる画像サイズのキャラクタ画像を取得することにより、多数の画像の表示が必要なゲームであっても、ファイルサイズの制限内に抑えつつ表示品位の悪化を抑制することができる。

（付記２）また、本発明の一態様は、付記１に記載のゲーム装置であって、前記特定のキャラクタは、前記グループに対応するそれぞれのユーザにより予め設定されたキャラクタであり、前記第２の画像サイズは、前記第１の画像サイズより小さい画像サイズである。

付記２の構成によれば、ゲーム装置は、特定のキャラクタ画像の画像サイズは変えずに、他のキャラクタ画像の画像サイズを縮小して取得するので、特定のキャラクタ画像の表示品位を保ちつつファイルサイズを縮減して、ファイルサイズの制限内で画像を取得することができる。特定のキャラクタは、それぞれのグループの主要なキャラクタであることからバトル時にユーザが注視する可能性が高いキャラクタである。そのため、特定のキャラクタ画像の表示品質を保つことで、他のキャラクタ画像の表示品質が多少低下しても、ユーザに対して自然なバトルの演出を実現することができる。

（付記３）また、本発明の一態様は、付記１または付記２に記載のゲーム装置であって、前記画像取得部は、複数の前記他のキャラクタに対応するオブジェクトの画像が並んで配置された結合画像（ＳＳ１）を取得し、前記表示制御部は、複数の前記他のキャラクタに対応するオブジェクトの画像のそれぞれを表示する際に、前記画像取得部が取得した前記結合画像に対してそれぞれ表示する画像以外をマスクする。

付記３の構成によれば、ゲーム装置は、結合画像（例えば、縮小シート画像ＳＳ１）に含まれる複数のキャラクタ画像のそれぞれの中から、表示したい所望の画像を表示することができる。

（付記４）また、本発明の一態様は、付記３に記載のゲーム装置であって、前記結合画像（Ｓ１、ＳＳ１）において、複数の前記他のキャラクタに対応するオブジェクトの画像は、所定の間隔を空けて配置されている。

付記４の構成によれば、ゲーム装置は、結合画像（例えば、シート画像Ｓ１）を生成する際に、隣り合う画像どうしの間に余白が設けられるため、隣り合う画像の境界で滲みが発生せず、画像の表示品位を保つことができる。

（付記５）また、本発明の一態様は、付記１から付記４のいずれか一に記載のゲーム装置であって、前記画像取得部は、前記グループのそれぞれに含まれる複数のキャラクタに対応するオブジェクトの画像を、それぞれ同じ画像サイズで取得する。

付記５の構成によれば、ゲーム装置は、通常バトルのように元々ファイルサイズの制限に問題が無い場合には、各キャラクタ画像を同じ画像サイズで取得することで、処理を簡略化できる。

（付記６）また、本発明の一態様は、付記５に記載のゲーム装置であって、前記ゲームは、対戦型のバトルゲームであり、前記画像取得部は、プレイ可能な期間に限定のあるバトルゲームがユーザにより選択された場合、前記特定のキャラクタに対応するオブジェクトの画像を第１の画像サイズで取得するとともに、他のキャラクタに対応するオブジェクトの画像を前記第２の画像サイズで取得し、プレイ可能な期間に限定のないバトルゲームが選択された場合、前記特定のキャラクタに対応するオブジェクトの画像、及び前記他のキャラクタに対応するオブジェクトの画像を同じ画像サイズで取得する。

付記６の構成によれば、ゲーム装置は、バトルゲームの種類に応じて、キャラクタによって異なる画像サイズでキャラクタ画像を取得するか、キャラクタによらず同じ画像サイズでキャラクタ画像を取得するかを制御することができるので、例えば通常バトルとイベントバトルのいずれであっても、ファイルサイズの制限内で画像を取得できるとともに、表示品位の悪化を抑制することができる。

（付記７）また、本発明の一態様に係るゲームサーバ（３０）は、複数のキャラクタをそれぞれ含む所定数のグループを用いて進行するゲームにおいて、前記グループにそれぞれ含まれる複数のキャラクタのうち、特定のキャラクタに対応するオブジェクト（例えば、キャラクタカード）の画像を第１の画像サイズで出力し、他のキャラクタに対応するオブジェクトの画像を前記第１の画像サイズとは異なる第２の画像サイズで出力するとともに、出力先の端末装置（１０）の表示部（１４）において、前記第１の画像サイズで出力する画像と、前記第２の画像サイズで出力する画像とを、前記ゲームの進行に応じて表示させるための制御情報を出力する出力部（３１２）、を備える。

付記７の構成によれば、ゲームサーバは、キャラクタによって異なる画像サイズでキャラクタ画像を出力するので、特定のキャラクタのキャラクタ画像の表示品位を保ちつつ、他のキャラクタの画像サイズを縮小することでファイルサイズを縮減することができる。よって、ゲームサーバは、多数の画像の表示が必要なゲームであっても、ファイルサイズの制限内で画像を出力することができるとともに、端末装置（例えば、ゲーム装置）で表示させる画像の表示品位の悪化を抑制することができる。

（付記８）また、本発明の一態様に係るコンピュータを、付記１から付記５のいずれか一に記載のゲーム装置として機能させるためのプログラム。

（付記９）また、本発明の一態様に係るゲームの制御方法は、複数のキャラクタをそれぞれ含む所定数のグループを用いて進行するゲームにおいて、前記グループにそれぞれ含まれる複数のキャラクタのうち、特定のキャラクタに対応するオブジェクトの画像を第１の画像サイズで取得し、他のキャラクタに対応するオブジェクトの画像を前記第１の画像サイズとは異なる第２の画像サイズで取得するステップと、取得した前記グループごとの画像を、ゲームの進行に応じて表示部に表示するステップと、を含む。

１ ゲームシステム、１０ ユーザ端末、１２ 通信部、１３ 入力部、１４ 表示部、１５ 記憶部、３０ ゲームサーバ、３４ サーバ通信部、３５ サーバ記憶部、１１０ 制御部、１１１ 画像取得部、１１２ 表示制御部、３１０ サーバ制御部、３１１ データ処理部、３１２ データ出力部、３５１ デッキ情報記憶部、３５２ 表示画像記憶部、３５３ シート画像記憶部、３５４ テンプレート記憶部

Claims (8)

1. 複数のキャラクタをそれぞれ含む所定数のグループを用いて進行するゲームにおいて、前記グループにそれぞれ含まれる複数のキャラクタのうち、特定のキャラクタに対応するオブジェクトの画像を第１の画像サイズで取得し、他のキャラクタに対応するオブジェクトの画像を前記第１の画像サイズとは異なる第２の画像サイズで取得する画像取得部と、
   前記画像取得部が取得した前記グループごとの画像を、ゲームの進行に応じて表示部に表示する表示制御部と、
   を備えるゲーム装置。
2. 前記特定のキャラクタは、前記グループに対応するそれぞれのユーザにより予め設定されたキャラクタであり、
   前記第２の画像サイズは、前記第１の画像サイズより小さい画像サイズである、
   請求項１に記載のゲーム装置。
3. 前記画像取得部は、
   複数の前記他のキャラクタに対応するオブジェクトの画像が並んで配置された結合画像を取得し、
   前記表示制御部は、
   複数の前記他のキャラクタに対応するオブジェクトの画像のそれぞれを表示する際に、前記画像取得部が取得した前記結合画像に対してそれぞれ表示する画像以外をマスクする、
   請求項１または請求項２に記載のゲーム装置。
4. 前記結合画像において、複数の前記他のキャラクタに対応するオブジェクトの画像は、所定の間隔を空けて配置されている、
   請求項３に記載のゲーム装置。
5. 前記画像取得部は、
   前記グループのそれぞれに含まれる複数のキャラクタに対応するオブジェクトの画像を、それぞれ同じ画像サイズで取得する、
   請求項１から請求項４のいずれか一項に記載のゲーム装置。
6. 前記ゲームは、対戦型のバトルゲームであり、
   前記画像取得部は、
   プレイ可能な期間に限定のあるバトルゲームがユーザにより選択された場合、前記特定のキャラクタに対応するオブジェクトの画像を第１の画像サイズで取得するとともに、他のキャラクタに対応するオブジェクトの画像を前記第２の画像サイズで取得し、プレイ可能な期間に限定のないバトルゲームが選択された場合、前記特定のキャラクタに対応するオブジェクトの画像、及び前記他のキャラクタに対応するオブジェクトの画像を同じ画像サイズで取得する、
   請求項５に記載のゲーム装置。
7. 複数のキャラクタをそれぞれ含む所定数のグループを用いて進行するゲームにおいて、前記グループにそれぞれ含まれる複数のキャラクタのうち、特定のキャラクタに対応するオブジェクトの画像を第１の画像サイズで出力し、他のキャラクタに対応するオブジェクトの画像を前記第１の画像サイズとは異なる第２の画像サイズで出力するとともに、出力先の端末装置の表示部において、前記第１の画像サイズで出力する画像と、前記第２の画像サイズで出力する画像とを、前記ゲームの進行に応じて表示させるための制御情報を出力する出力部、
   を備えるゲームサーバ。
8. コンピュータを、請求項１から請求項５のいずれか一項に記載のゲーム装置として機能させるためのプログラム。

Images