JP2022180021A - プログラム、情報処理方法および情報処理装置 - Google Patents

Abstract

【課題】 ゲームで使用されるデッキの編成を容易にする技術を提供する。【解決手段】 実施形態によれば、コンピュータによって実行されるプログラムにおいて、ゲームで使用される複数のカードを含むように編成されたメインデッキをゲーム画像の第１範囲に表示させることと、ユーザの第１操作に応答して、メインデッキとは異なるサブデッキをゲーム画像の第２範囲に表示させることと、をコンピュータに実行させるようにした。【選択図】図５

Description

本発明の実施形態は、プログラム、情報処理方法および情報処理装置に関する。

１または複数のカードを含むカードセットを使用するゲームが知られている。カードセットは「デッキ」とも呼ばれる。このようなゲームでは、例えば、敵キャラクタとの戦闘において、デッキに含まれるカードの効果を発動させることによって敵キャラクタにダメージを与える。ゲームのプレイヤー（以下、「ユーザ」とも言う。）は、各カードに設定された効果の属性またはパラメータ等を考慮して、１または複数のカードを組み合わせ、デッキを編成する。

プレイヤーが保有するキャラクタから１以上のキャラクタを選択してグループを編成するゲームにおいて、敵キャラクタに勝てる可能性の高い、おすすめ編成を提示する装置が提案されている（例えば、特許文献１参照）。また、ユーザのタッチ操作に応じて表示を変化させる技術も知られている（例えば、特許文献２参照）。

特開２０１８－１７１１８１号公報 特表２０１２－５２０５２１号公報

デッキ編成は、ゲームを有利に進められるかどうかに関わる戦略的な要素である。しかし、敵キャラクタまたはクエスト等に応じてデッキを編成するのは依然として手間がかかる。

この発明の一態様は、デッキ編成を容易にする技術を提供する。

上記課題を解決するためにこの発明の一態様は、コンピュータによって実行されるプログラムにおいて、ゲームで使用される複数のカードを含むように編成されたメインデッキをゲーム画像の第１範囲に表示させることと、ユーザの第１操作に応答して、メインデッキとは異なるサブデッキをゲーム画像の第２範囲に表示させることと、をコンピュータに実行させるようにした。

一態様に係るプログラムによれば、ゲームで使用されるメインデッキがゲーム画像の第１範囲に表示され、ユーザの第１操作を受け付けた場合には、さらにメインデッキとは異なるサブデッキがゲーム画像の第２範囲に表示される。これにより、ゲームで使用されるメインデッキだけでなく、メインデッキとは異なるサブデッキを併せて表示させ、ユーザが容易にデッキ編成を行えるようにすることができる。

この発明の一態様によれば、デッキ編成を容易にする技術が提供される。

図１は、第１実施形態に係るゲームプログラムに関連するゲームシステムの全体構成の一例を示す図である。 図２は、第１実施形態に係るサーバの機能構成の一例を示す図である。 図３は、第１実施形態に係るユーザ端末の機能構成の一例を示す図である。 図４は、第１実施形態に係るゲームプログラムによって実現されるゲームの構成を示す略図である。 図５は、第１実施形態に係るユーザ端末の情報処理動作の第１実施例を示すフローチャートである。 図６は、図５に示した情報処理動作のうちメインデッキ表示処理の詳細を示すフローチャートである。 図７は、図５に示した情報処理動作のうちサブデッキ表示処理の詳細を示すフローチャートである。 図８は、第１実施形態に係るデッキ管理テーブルの一例を示す図である。 図９は、第１実施形態に係る所持カード管理テーブルの一例を示す図である。 図１０は、第１実施形態に係るクエスト管理テーブルの一例を示す図である。 図１１は、第１実施形態のデッキ表示に係るゲーム画像の第１の例を示す図である。 図１２は、第１実施形態に係るユーザ端末の情報処理動作の第２実施例を示すフローチャートである。 図１３は、第１実施形態に係るカード入替え処理を説明するゲーム画像の一例を示す図である。 図１４は、第１実施形態のデッキ表示に係るゲーム画像の第２の例を示す図である。 図１５は、第１実施形態のデッキ表示に係るゲーム画像の第３の例を示す図である。 図１６は、第２実施形態に係るユーザ端末の機能構成の一例を示す図である。 図１７は、第２実施形態に係るゲームプログラムによって実現されるゲームの構成を示す略図である。 図１８は、第２実施形態に係るユーザ端末の情報処理動作の一例を示すフローチャートである。 図１９は、第２実施形態に係る協力プレイ用デッキ管理テーブルの一例を示す図である。 図２０は、第２実施形態のデッキ表示に係るゲーム画像の一例を示す図である。

以下、図面を参照してこの発明に係わる実施形態を説明する。なお、以降、説明済みの要素と同一または類似の要素には同一または類似の符号を付し、重複する説明については基本的に省略する。例えば、複数の同一または類似の要素が存在する場合に、各要素を区別せずに説明するために共通の符号を用いることがあるし、各要素を区別して説明するために当該共通の符号に加えて枝番号を用いることもある。

［第１実施形態］
第１実施形態に係るプログラムは、ユーザによって使用される端末装置（以下、「ユーザ端末」と言う。）上でゲームを実現させるためのプログラムである。以下では、第１実施形態に係るプログラムを、一般的なコンピュータの機能を実現させるためのプログラムと区別して、ゲームプログラムと呼ぶ。

ゲームプログラムは、１台のユーザ端末でローカルにゲームを実現させるゲームプログラム、ユーザ端末とサーバに協働してゲームを実現させるゲームプログラム、（サーバ経由でまたはサーバを介さずに）複数のユーザ端末に協働してゲームを実現させるゲームプログラム等であり得る。第１実施形態では、一例として、サーバがゲームプログラムを包括的に管理し、ユーザ端末からの要求に応答してゲームプログラムおよび関連データ等を送信し、実際のゲーム進行は主にユーザ端末において実現されるゲームシステムについて説明する。

（１）構成
（１－１）ゲームシステム
図１は、ゲームプログラムに関連するゲームシステム１の全体構成の一例を示す。
ゲームシステム１は、複数のユーザ端末１００Ａ，１００Ｂ，１００Ｃ・・・（以下、個々の区別をせず総称的に「ユーザ端末１００」とも呼ぶ）と、サーバ２００と、を含む。各ユーザ端末１００は、サーバ２００との間でネットワークＮＷを介して通信可能である。サーバ２００には、任意の数のユーザ端末１００が接続可能であるが、簡単のために１つのユーザ端末１００についてのみ詳細な構成を図示し説明する。

ネットワークＮＷは、例えばインターネットであり、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、移動通信網、有線電話網、ＦＴＴＨ（Fiber To The Home）、ＣＡＴＶ（Cable Television）網等のアクセス網を含み得る。

ユーザ端末１００は、第１実施形態に係る情報処理装置の一例であり、ゲームプレイをするユーザによって使用される端末である。ユーザ端末１００は、ゲームプログラムを実行することによりゲームを実現し、ゲーム進行に応じたゲーム画像を表示することによりゲーム画面を実現する。ゲーム画像は、ゲーム空間を描画した画像を含み得る。ゲーム空間を描画した画像は、ゲーム空間に配置された複数のオブジェクトの画像を含み得る。ゲーム画像は、静止画像または動画像を含む。ゲーム画像はまたＵＩ（User Interface）オブジェクトの画像を含み得る。ユーザ端末１００は、例えば、スマートフォン、タブレット端末、ノート型パーソナルコンピュータ等の携帯端末である。ユーザ端末１００は、デスクトップ型パーソナルコンピュータのような据置型コンピュータであってもよい。ユーザ端末１００はまた、ゲームプレイに適した専用のゲーム端末であってもよい。以下では、一例として、ユーザ端末１００が、タッチスクリーンを備えるスマートフォンであるものとして説明する。

サーバ２００は、例えばゲーム開発者等によって運営および管理される装置である。サーバ２００は、ゲームプログラムおよびユーザ情報を包括的に管理し、ユーザ端末１００におけるゲームの進行を支援する。サーバ２００は、ワークステーションやパーソナルコンピュータ等の汎用コンピュータであってよい。例えばサーバ２００は、ネットワークＮＷを介してユーザ端末１００からユーザ情報または種々の要求を受け付け、要求に応答してネットワークＮＷを介してユーザ端末１００にゲームプログラムや関連データを送信する。サーバ２００は、同時に複数のユーザ端末１００との間で情報の送受信が可能であり、複数のユーザ端末１００におけるゲームの進行を並行して支援し得る。

（１－２）ハードウェア構成
（１－２－１）サーバ
図１に示すように、サーバ２００は、ハードウェアとして、プロセッサ２００１と、メモリ２００２と、ストレージ２００３と、通信インタフェース（通信Ｉ／Ｆ）２００４と、入出力インタフェース（入出力Ｉ／Ｆ）２００５と、を備え、これらがバス２００６を介して互いに電気的に接続される。

プロセッサ２００１は、サーバ２００全体の動作を制御する。プロセッサ２００１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の汎用プロセッサを含む。プロセッサ２００１は、汎用プロセッサに限らず、ＡＳＩＣ（Application Specific Integrated Circuit）またはＦＰＧＡ（Field-Programmable Gate Array）等の専用プロセッサであってもよい。
メモリ２００２は、主記憶装置であり、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）等を含む。
ストレージ２００３は、補助記憶装置であり、ハードディスクドライブ（ＨＤＤ）やソリッドステートドライブ（ＳＳＤ：Solid State Drive）等の不揮発性記憶装置を含む。ストレージ２００３は、プロセッサ２００１により実行されるプログラムや、プログラムの実行に必要な設定データ等を記憶する。プログラムの一部はＲＯＭに記憶されてもよい。

プロセッサ２００１は、ストレージ２００３からプログラムを読み出してメモリ２００２に展開し、展開したプログラムを解釈および実行することによって、後述する処理機能を実現し得る。

通信インタフェース（通信Ｉ／Ｆ）２００４は、ネットワークＮＷを介してユーザ端末１００等の外部装置と通信するためのモジュールであり、送受信のための信号処理回路、光コネクタ等を含む。通信インタフェース２００４は、例えば光通信モジュールを含んでもよい。

入出力インタフェース（入出力Ｉ／Ｆ）２００５は、キーボードやマウス等の入力装置を通じてオペレータが入力した操作データを取り込むとともに、出力データを液晶または有機ＥＬ（Electro Luminescence）ディスプレイやスピーカ等の出力装置に出力する。

（１－２－２）ユーザ端末
図１に示すように、ユーザ端末１００は、ハードウェアとして、プロセッサ１００１と、メモリ１００２と、ストレージ１００３と、センサ１００４と、通信インタフェース（通信Ｉ／Ｆ）１００５と、入出力インタフェース（入出力Ｉ／Ｆ）１００６と、タッチスクリーン１００７と、を備え、これらがバス１００８を介して互いに電気的に接続される。

プロセッサ１００１は、ユーザ端末１００の全体の動作を制御する。プロセッサ１００１は、例えば、ＣＰＵ、ＭＰＵ、ＧＰＵ等の汎用プロセッサを含む。プロセッサ１００１もまた、汎用プロセッサに限らず、ＡＳＩＣまたはＦＰＧＡ等の専用プロセッサであってもよい。
メモリ１００２は、主記憶装置であり、ＲＯＭおよびＲＡＭ等を含む。
ストレージ１００３は、補助記憶装置であり、内蔵または外付けの半導体メモリ（例えばフラッシュメモリ）等を含む。ストレージ１００３は、プロセッサ１００１により実行されるプログラムや、プログラムの実行に必要な設定データ等を記憶する。プログラムの一部は、ＲＯＭに記憶されてもよい。
プロセッサ１００１は、ストレージ１００３からプログラムを読み出してメモリ１００２に展開し、展開したプログラムを解釈および実行することによって、後述する処理機能を実現し得る。

センサ１００４は、例えば、イメージセンサ、サウンドセンサ、加速度センサ、角速度センサ、地磁気センサ、ＧＰＳセンサ、近接センサ、環境光センサ等である。センサ１００４は、感知された種々の情報を電気信号に変換し、出力する。

通信インタフェース（通信Ｉ／Ｆ）１００５は、ネットワークＮＷを介してサーバ２００等の外部装置と通信するためのモジュールであり、送受信のための信号処理回路、アンテナ、ＬＡＮ端子等を含む。通信インタフェース１００５は、移動通信用のモジュール、無線／有線ＬＡＮ用のモジュール、近距離無線通信用のモジュール等を含み得る。

入出力インタフェース（入出力Ｉ／Ｆ）１００６は、外部装置から入力データを取り込むとともに、出力データを外部装置に出力する。入出力インタフェース１００６は、例えば、ユーザ端末１００の物理ボタンや、ユーザ端末１００に内蔵されたスピーカ、ＵＳＢ（Universal Serial Bus）ポート等を含み得る。

タッチスクリーン１００７は、入力部１０７１と表示部１０７２とを備え、ユーザの入力操作を受け付けるとともに、ユーザに種々の画像を表示する機能を有する。

入力部１０７１は、例えば静電容量式や抵抗膜式のタッチパネルである。入力部１０７１は、ユーザが指やタッチペン（スタイラスペン）で触れた接触位置を検知し、接触位置の座標情報を生成する。

表示部１０７２は、例えば液晶ディスプレイや有機ＥＬディスプレイであり、表示データに基づく種々の画像を表示する。表示部１０７２は、ゲーム画像を表示することによってゲーム画面を実現する。

ユーザ端末１００は、入出力インタフェース１００６を介して接続されるキーボード、マウス、コントローラ等の外部入力装置からユーザの操作を受け付けることもできる。ユーザ端末１００は、入出力インタフェース１００６を介して接続されるメモリカード等の外部記憶装置からゲームプログラムおよび関連データを取得してもよい。ユーザ端末１００は、入出力インタフェース１００６を介して接続されるディスプレイやスピーカ等の外部出力装置に表示情報を出力することもできる。ユーザ端末１００は、入出力インタフェース１００６を介して接続されるメモリカード等の外部記憶装置をストレージ１００３として使用してもよい。ユーザ端末１００はまた、センサ１００４からの信号をユーザの入力操作として受け付けてもよい。

（１－３）機能構成
（１－３－１）サーバ
図２は、第１実施形態に係るサーバ２００の機能構成の一例を示す。なお、一般的なコンピュータの機能構成およびゲームの実現に必要な公知の構成については、図示および説明を省略する。

サーバ２００は、各ユーザ端末１００と通信し、ユーザ端末１００におけるゲームの進行を支援する機能を有する。例えば、サーバ２００は、各ユーザ端末１００からの要求に応答して、各ユーザ端末１００にゲームプログラムや、ゲームプログラムの実行に必要な関連データ等を送信する機能を有する。サーバ２００は、制御部２１０と、記憶部２２０と、を備える。

記憶部２２０は、主にストレージ２００３により実現される。記憶部２２０は、ゲームプログラム記憶部２２１と、ゲーム情報記憶部２２２と、ユーザ情報記憶部２２３と、を備える。

ゲームプログラム記憶部２２１は、ゲームプログラムを記憶する。
ゲーム情報記憶部２２２は、ゲームプログラムを実行する際に参照される種々のゲーム情報を記憶する。
ユーザ情報記憶部２２３は、各ユーザ端末１００に関連付けられるユーザに関する情報を記憶する。ユーザ情報記憶部２２３は、例えば、ユーザのアカウント情報、ユーザのニックネーム、ユーザの所持カード、またはユーザのゲーム進行状況等の情報を記憶する。

制御部２１０は、主にプロセッサ２００１およびメモリ２００２により実現される。制御部２１０は、サーバ２００全体の機能を制御する。制御部２１０は、ゲームプログラム記憶部２２１に記憶されたゲームプログラムを実行することにより、受信制御部２１１、送信制御部２１２、およびゲーム進行部２１３として機能し得る。

受信制御部２１１は、各ユーザ端末１００から、ユーザ情報、各ユーザ端末１００におけるゲームの進行状況に関する情報、およびプログラムまたは関連データの送信要求等を受け付ける。

送信制御部２１２は、各ユーザ端末１００に、要求されたプログラムまたは関連データ、あるいは更新されたプログラム等を送信する。送信制御部２１２はまた、各ユーザ端末１００にゲームの進行状況に関する情報の送信を要求し得る。

ゲーム進行部２１３は、ゲームプログラムに記述されたコードに従ってゲーム情報記憶部２２２およびユーザ情報記憶部２２３に記憶された情報を参照し、各ユーザ端末１００におけるゲームの進行状況を管理する。ゲーム進行部２１３はまた、各ユーザ端末１００からの情報収集の要否や各ユーザ端末１００へのデータ送信の要否を判定し得る。

例えば、制御部２１０は、受信制御部２１１により、ユーザ端末１００からゲームプログラムの送信要求を受け付け、ゲーム進行部２１３により、当該ユーザ端末１００に送信すべきゲームプログラムと関連データを決定し、送信制御部２１２により、決定されたゲームプログラムおよび関連データをユーザ端末１００に送信する。

（１－３－２）ユーザ端末
図３は、第１実施形態に係るユーザ端末１００の機能構成の一例を示す。なお、一般的なコンピュータの機能構成およびゲームの実現に必要な公知の構成については、図示および説明を省略する。

ユーザ端末１００は、制御部１１０と、記憶部１２０と、を備える。
記憶部１２０は、主にストレージ１００３により実現される。記憶部１２０は、ゲームプログラム記憶部１２１と、ゲーム情報記憶部１２２と、デッキ情報記憶部１２３と、を備える。

ゲームプログラム記憶部１２１は、ゲームプログラムを記憶する。

ゲーム情報記憶部１２２は、ゲームプログラムを実行する際に参照される種々のゲーム情報を記憶する。ゲーム情報記憶部１２２はまた、ゲーム画像を表示させるための表示データを生成する際に参照される画像、音声、および音楽等の表示情報を記憶する。

デッキ情報記憶部１２３は、デッキ管理テーブル１２３１、所持カード管理テーブル１２３２、およびクエスト管理テーブル１２３３を記憶する。デッキ管理テーブル１２３１は、デッキの内容を表す情報を記憶する。所持カード管理テーブル１２３２は、ユーザ端末１００のユーザが所持するカードの情報を記憶する。クエスト管理テーブル１２３３は、デッキを使用してプレイ可能なクエストの情報を記憶する。

制御部１１０は、主にプロセッサ１００１およびメモリ１００２により実現される。制御部１１０は、ユーザ端末１００全体の機能を制御する。制御部１１０は、ゲームプログラム記憶部１２１に記憶されたゲームプログラムを実行することにより、ゲーム進行部１１１、オブジェクト制御部１１２、操作受付部１１３、表示制御部１１４、およびデッキ管理部１１５として機能し得る。

ゲーム進行部１１１は、ゲームプログラムに記述されたコードに従って、ゲーム情報記憶部１２２に記憶されたゲーム情報を参照し、ゲーム空間にオブジェクトを配置してゲームを進行させる機能を有する。

オブジェクト制御部１１２は、ゲーム空間に配置された種々のオブジェクトの動作またはステータスを制御する機能を有する。

操作受付部１１３は、入力部１０７１を介して入力されたユーザの操作を受け付ける機能を有する。以下、「ユーザの操作」は、入力部１０７１を介して入力されたユーザの操作を指すものとする。ユーザの操作は、タップ操作、ドラッグアンドドロップ操作、スワイプ操作、ピンチイン操作、およびピンチアウト操作など、入力部１０７１を介した種々の種類の操作を含む。操作受付部１１３は、入力部１０７１による接触位置の検知に基づいて、ユーザの操作の開始を検知し得る。操作受付部１１３は、入力部１０７１による接触位置の検知から非検知への遷移に基づいて、ユーザの操作の終了を検知し得る。操作受付部１１３は、ユーザの操作の開始に対応する接触位置からユーザの操作の終了に対応する接触位置までの座標情報を入力部１０７１から連続的に取得する。操作受付部１１３によるユーザの操作の判別は、知られている方法で行われてよい。

表示制御部１１４は、表示部１０７２にゲーム画像を表示させるための表示データを生成する機能を有する。表示制御部１１４は、ゲーム画像の第１範囲にメインデッキを表示させる表示制御部として機能する。表示制御部１１４はまた、ユーザの操作に応答して、ゲーム画像の第２範囲にサブデッキを表示させる表示切替部として機能する。

デッキ管理部１１５は、デッキの情報を管理し、デッキの編成および保存を支援する機能を有する。デッキ管理部１１５はまた、表示制御部１１４と連携して、ゲーム画像におけるメインデッキおよびサブデッキの表示を生成する。

（１－４）ゲームの構成
第１実施形態に係るゲームプログラムによって実現されるゲームは、１以上のカードを組み合わせて編成されたデッキを使用可能なゲームを含む。以下では、第１実施形態について、デッキを使用するクイズＲＰＧ（ＲＰＧ：ロールプレイングゲーム）における適用例を用いて説明する。ただし、第１実施形態はクイズＲＰＧに限定されず、デッキを使用可能な他の分類のゲームにも適用可能である。

図４は、第１実施形態に係るゲームプログラムによって実現されるゲームの構成を示す略図である。ゲームは、複数のゲームパートで構成される。一例として、ゲームは、ホームパートと、デッキ編成パートと、クエストパートと、を含む。ホームパートは、ゲームの拠点となるゲームパートである。デッキ編成パートは、ゲーム開始前にユーザが所持するカードの中から１または複数のカードを組み合わせてデッキを編成可能なゲームパートである。クエストパートは、ユーザがデッキを用いてゲームプレイを行うことのできるゲームパートである。クエストパートは、それぞれに目標が設定された複数のクエスト（「ゲームステージ」等、類似の用語に読み替えられ得る）を含む。例えば、あるクエストの目標は、当該クエストに設定された敵キャラクタの討伐である。各クエストではクイズが出題され、ユーザはユーザ端末１００を介して解答を入力する。クイズに正解すると、デッキに含まれるカードの効果として、敵キャラクタに対して攻撃等のアクションが発動される。各カードには、効果の属性またはパラメータが設定されており、ユーザは、戦闘を有利に進められるよう属性またはパラメータを考慮してデッキを編成する。

ゲーム画像６は、ホームパートに係るゲーム画像の一例（略図）である。例えばゲーム画像６は、デッキ編成ボタン６１と、クエストボタン６２と、を含む。デッキ編成ボタン６１は、デッキ編成パートへの遷移を要求する操作ボタンである。クエストボタン６２は、クエストパートへの遷移を要求する操作ボタンである。操作ボタンは、ユーザによって選択されると所定の機能を発揮するように構成されたＵＩオブジェクトである。操作ボタンに代えて他のコマンドが使用されてもよい。

例えば、デッキ編成ボタン６１が選択されると、ホームパートからデッキ編成パートに遷移し、デッキ編成パートに係るゲーム画像７が表示される（Ｐ１）。ゲーム画像７は、デッキ編成パートに係るゲーム画像の一例である。ユーザは、デッキ編成パートにおいて、所持するカードの中から任意に選択したカードを組み合わせて１または複数のデッキを編成することができる。例えばゲーム画像７は、デッキ名７１、デッキカード欄７２、デッキ切替ボタン７３、所持カード欄７４、決定ボタン７５、およびもどるボタン７６を含む。デッキ名７１は、編成中のデッキの識別情報（図示の例では「デッキ２」）を含む。デッキカード欄７２は、編成中のデッキに含まれるカードを示す。デッキカード欄７２には最大枠数が設定される。ユーザは、最大枠数以下の数のカードを各デッキに組み込むことができる。デッキ切替ボタン７３は、編成対象のデッキを切り替え可能とする。例えば、左側のボタン７３が選択されると、編成対象のデッキが「デッキ２」から「デッキ１」に切り替わり、右側のボタン７３が選択されると、編成対象のデッキが「デッキ２」から「デッキ３」に切り替わる。所持カード欄７４は、ユーザが所持するカードの一覧を示す。矢印ＤＤは、デッキ編成操作の一例として、ユーザによるドラッグアンドドロップ操作を示す。ユーザは、ドラッグアンドドロップ操作ＤＤにより、所持カード欄７４のカードをデッキカード欄７２に組み込む、または所持カード欄７４のカードとデッキカード欄７２のカードとを入れ替えることができる。決定ボタン７５はデッキ編成を保存するためのボタンである。決定ボタン７５が選択されると、デッキの内容がデッキ情報記憶部１２３に保存される。もどるボタン７６は、前のゲーム画面にもどるためのボタンである。例えば、もどるボタン７６が選択されると、デッキ編成の変更を保存せずに、デッキ編成パートからホームパートに遷移する（Ｐ２）。

ゲーム画像６においてクエストボタン６２が選択されると、ホームパートからクエストパートに遷移し、クエストパートに係るゲーム画像８が表示される（Ｐ３）。ゲーム画像８は、クエストパートの入口に対応するゲーム画像の一例である。クエストパートをプレイするために、ユーザは、まず、ゲームプレイしようとするクエストを選択し、クエストに設定された目標および使用されるデッキの内容を確認してから、実際のクエストプレイに進む。ここでは、「デッキの内容」は、デッキに含まれるカードの情報を含む。「デッキの内容」はまた、デッキにおけるカードの並び順の情報を含み得る。例えばゲーム画像８は、クエスト選択ボタン８１と、もどるボタン８２とを含む。クエスト選択ボタン８１は、クエストの識別情報（図では、クエスト１、クエスト２、・・・）を含む。ユーザは、クエスト選択ボタン８１のいずれかを選択することによって、ゲームプレイをするクエストを選択することができる。もどるボタン８２は、前のゲーム画面に戻るためのボタンである。例えば、もどるボタン８２が選択されると、クエストパートからホームパートに遷移する（Ｐ４）。

ゲーム画像８においていずれかのクエスト選択ボタン８１が選択された場合、例えばゲーム画像１１のような確認画面が表示される（Ｐ５）。例えばゲーム画像１１は、敵キャラ画像５０、敵キャラ情報５１、メインデッキフィールド２０、もどるボタン４３、および挑戦するボタン４４を含む。敵キャラ画像５０および敵キャラ情報５１は、クエストに設定された敵キャラクタの画像および情報を示す。メインデッキフィールド２０は、ゲームで使用されるデッキの内容を示す。挑戦するボタン４４が選択されると、表示中のデッキを用いる選択したクエストでのゲームプレイが開始される。もどるボタン４３が選択されると、ゲーム画像８に遷移する（Ｐ６）。ユーザは、ゲーム画像１１のような確認画面において、これからプレイするクエストおよび使用されるデッキの最終確認を行うことができる。

ゲーム画像１１のようなゲームプレイ前の確認画面において、デッキの内容を変更したいと考える場合、ユーザは、この例では、ゲーム画像１１から何らかの操作を経てゲーム画像７のようなデッキ編成用画面を表示させるか（Ｐ７）、またはゲーム画像１１から、もどるボタン４３、もどるボタン８２、およびデッキ編成ボタン６１という順に選択して、ゲーム画像７に切り替える必要がある。第１実施形態は、このようなゲームプレイ前の確認画面におけるデッキ編成を可能とする。

（２）動作
次に、図３に示したユーザ端末１００による情報処理動作例について説明する。第１実施形態では、主にユーザ端末１００のユーザによるシングルプレイの状況を想定して説明する。なお、以降の動作の前提として、ユーザ端末１００の制御部１１０および記憶部１２０の連携により、ゲームプログラムに記述されたコードに従ってゲームがいくらか進行されているものとする。

（第１実施例）
第１実施例では、デッキを使用するゲームプレイの前に、ユーザの操作に応答して、ゲームで使用されるデッキ（後述する「メインデッキ」）に含まれるカードの入替え候補として「サブデッキ」を表示させる、デッキ表示動作について説明する。

図５は、第１実施形態に係るユーザ端末１００の情報処理動作の第１実施例を示すフローチャートである。
まずステップＳ１において、ユーザ端末１００は、制御部１１０の制御の下、メインデッキ表示処理を実行する。この処理は、例えば、ユーザが所定のゲーム画面を介してゲームプレイしようとするクエストを選択したことをトリガとして実行される。ユーザ端末１００の表示部１０７２は、選択されたクエストに関する情報および当該クエストで使用されるデッキに関する情報を表示する確認画面を提示する。第１実施形態では、あらかじめ保存されたデッキのうち、選択されたクエストで使用されるデッキ（または使用される予定のデッキ）を「メインデッキ」と呼ぶ。メインデッキは１または複数のカードを含む。ステップＳ１については図６を参照してさらに後述する。

次いでステップＳ２において、ユーザ端末１００は、操作受付部１１３により、サブデッキ表示を要求するユーザ操作（ユーザの第１操作）を受け付けたかどうかを監視し、当該ユーザ操作を受け付けた場合（ＹＥＳ）、ステップＳ３に進む。サブデッキ表示を要求するユーザ操作を受け付けなければ（ＮＯ）、処理を終了するか監視を継続する。サブデッキ表示を要求するユーザ操作は、例えば、所定のＵＩオブジェクトにより実現される操作ボタンをタップする操作である。なお、ここでは「操作ボタンをタップする」と言うとき、操作ボタンに関連付けられた機能の発動を要求する操作全般を意味する。「操作ボタンをタップする」は、操作ボタンにタッチする、操作ボタンを選択する、または操作ボタンを押す、等と読み替えられてよい。また、サブデッキ表示を要求するユーザ操作は、ＵＩオブジェクトとしての操作ボタンに対する操作に限られず、同様の機能を要求するタッチ操作、物理ボタンの操作、またはその他のコマンドに置き換えられてもよい。

ステップＳ３において、ユーザ端末１００は、制御部１１０の制御の下、サブデッキ表示を要求するユーザ操作に応答してサブデッキ表示処理を実行する。「サブデッキ」は、メインデッキに含まれるカードの入替え候補である１または複数のカードを含む、メインデッキとは異なるデッキである。なお、本明細書で単に「デッキ」と言うとき、メインデッキおよびサブデッキの両方を含み得る。ステップＳ３については図７を参照してさらに後述する。

図６は、図５のステップＳ１に示したメインデッキ表示処理の詳細を示す。
ステップＳ１１において、デッキ管理部１１５は、メインデッキ情報を取得する。メインデッキ情報は、メインデッキに含まれるカードに関する情報を含む。例えばデッキ管理部１１５は、デッキ情報記憶部１２３に記憶されたデッキ管理テーブル１２３１および所持カード管理テーブル１２３２から必要な情報を読み出すことにより、メインデッキ情報を取得する。

図８は、デッキ管理テーブル１２３１の一例を示す。デッキ管理テーブル１２３１は、デッキの内容を表す情報を記憶し、例えば、デッキＩＤ、メインデッキフラグ、サブデッキフラグ、および編成情報を含む。デッキＩＤは、保存されているデッキを識別可能な情報（図示の例では、「デッキ１」、「デッキ２」、・・・「デッキ２１」・・・）を含む。メインデッキフラグは、メインデッキであるか否かを識別する。「１」はメインデッキであることを表し、「０」はメインデッキでないことを表す。サブデッキフラグは、サブデッキであるか否かを識別する。「１」はサブデッキであることを表し、「０」はサブデッキでないことを表す。サブデッキフラグは省略されてもよい。ここでは、デッキ１～デッキ２０がメインデッキとして設定され、デッキ２１～デッキＸ（Ｘは任意に設定されてよい）がサブデッキとして設定されている。メインデッキとして保存するかサブデッキとして保存するかはユーザが設定可能であってもよい。

編成情報は、各デッキを編成するカードの情報を含む。カードの情報は、例えばカードを識別可能な情報（図示の例では、「カード１」、「カード２」・・・）を含む。各デッキには、最大枠数（カードの上限数）（図示の例では６）が設定される。カードの並び順は、枠情報（図示の例では、「第１枠」、「第２枠」・・・「第６枠」）により管理される。図示の例では、「デッキ１」は、第１枠に「カード１」、第２枠に「カード２」、第３枠に「カード３」、第４枠に「カード４」、第５枠に「カード５」、第６枠に「カード６」を含む。「デッキ２」は、第１枠に「カード１１」、第２枠に「カード１」・・・を含む。デッキ１の第１枠「カード１」とデッキ２の第２枠「カード１」とは、同一のカードが重複して編成されたものであってよい。このような重複を許容しない設定であってもよい。さらに図示の例では、「デッキ２１」は、第１枠に「カード２１」、第２枠に「カード２２」、第３枠に「カード２３」・・・を含む。デッキ管理テーブル１２３１に保存されるデッキ（メインデッキまたはサブデッキ）は、ユーザによって編成されたデッキのみならず、サーバ２００から配信されたデッキおよびゲームプログラムによって自動生成されたデッキを含んでよい。第１実施形態では、メインデッキは言わば「スターティングメンバー」、サブデッキは言わば「控え」または「補欠」の役割を有する。したがって、第１実施形態では、メインデッキに含まれるカードとサブデッキに含まれるカードとの重複を許容しない設定が採用される。ただし、そのような重複を許容する適用例を除外しようとするものではない。

図９は、所持カード管理テーブル１２３２の一例を示す。ユーザは、ゲーム内で１以上のカードを所持する。ユーザが所持するカードは、ゲームの進行に伴って、発動可能な効果が変化し得る。またユーザが所持するカードの枚数は、ゲームの進行に伴って、増加または減少し得る。所持カード管理テーブル１２３２は、ユーザ端末１００のユーザが所持するカードの情報を管理するもので、例えば、カードＩＤ、ＨＰ、画像ＩＤ、および攻撃力を含む。カードＩＤは、各カードを識別可能な情報（図示の例では、「カード１」、「カード２」、「カード３」・・・）を含む。ＨＰは、各カードに設定されたＨＰ（ヒットポイント）の値を示す。ＨＰは、敵キャラクタからのダメージに耐えられる体力を数値化したものである。図示の例では、カード１は「１０００」、カード２は「８５０」、カード３は「１２００」のＨＰ値を有する。画像ＩＤは、表示データを生成する際に例えばゲーム情報記憶部１２２から読み出される、各カードに設定された画像の識別情報を含む。図示の例では、カード１は「画像１」、カード２は「画像２」、カード３は「画像３」により表示される。攻撃力は、発動可能な効果を数値化したもので、例えば攻撃力の値が大きいほど敵に与えることのできるダメージが大きくなる。図示の例では、カード１は「１５」、カード２は「６」、カード３は「２１」を有する。ＨＰ、画像ＩＤ、および攻撃力は、ゲームの進行に伴って変化し得る。各カードにはさらに他の情報が設定されてよい。

上記ステップＳ１１において、デッキ管理部１１５は、デッキ管理テーブル１２３１から、メインデッキとして保存されたデッキのうちいずれかのデッキのレコードを読み出す。はじめに読み出されるメインデッキを、便宜上アクティブなメインデッキと呼ぶ。アクティブなメインデッキは、例えば、番号が最も小さいデッキ、ユーザによって直近に編成され保存されたデッキ、またははじめに表示すべきデッキとしてユーザにより指定されたデッキ等である。例えば、デッキ２がアクティブなメインデッキである場合、デッキ管理部１１５は、デッキ管理テーブル１２３１から、デッキ２に含まれるカードの情報（第１枠＝カード１１、第２枠＝カード１・・・）を読み出す。さらにデッキ管理部１１５は、デッキ２に含まれる各カードの情報を、所持カード管理テーブル１２３２から取得する。

次いでステップＳ１２において、表示制御部１１４は、ステップＳ１１で取得した情報に基づいて、ゲーム画像にメインデッキを表示させるための表示データを生成し出力する。ゲーム画像は、選択されたクエスト（ユーザが挑戦しようとしているクエスト）の情報と、メインデッキの情報と、を含む。メインデッキの情報は、メインデッキを表示する領域であるメインデッキフィールドに表示される。メインデッキフィールドは、ゲーム画像の第１範囲の一例である。メインデッキフィールドの表示は、専用のＵＩオブジェクトを用いて実現される。第１実施形態では、メインデッキフィールドは、ゲーム画像内の所定の位置に表示される。

ステップＳ１３において、デッキ管理部１１５は、ユーザが挑戦しようとしているクエストがサブデッキの設定対象であるか否かを判定する。デッキ管理部１１５は、例えばデッキ情報記憶部１２３に格納されたクエスト管理テーブル１２３３の情報に基づいて判定を行う。クエストがサブデッキの対象である場合（ＹＥＳ）、ステップＳ１４に進み、クエストがサブデッキの対象でない場合（ＮＯ）、処理を終了する。

図１０は、クエスト管理テーブル１２３３の一例を示す。クエスト管理テーブル１２３３は、デッキを使用してプレイ可能なゲームとしてのクエストの情報を記憶する。例えばクエスト管理テーブル１２３３は、クエストＩＤ、敵キャラ、画像ＩＤ、およびサブデッキ設定を含む。クエストＩＤは、クエストを識別可能な情報（図示の例では、「クエスト１」、「クエスト２」・・・、「クエスト１０１」・・・）を含む。敵キャラは、各クエストに設定された敵キャラクタに関する情報を含む。図示の例では、クエスト１には「敵１」、クエスト２には「敵２」、クエスト１０１には「ドラゴン」が設定されている。画像ＩＤは、表示データを生成する際に例えばゲーム情報記憶部１２２から読み出される、各敵キャラクタに設定された画像の識別情報を含む。図示の例では、クエスト１の敵１は「画像１０１」、クエスト２の敵２は「画像１０２」、クエスト１０１のドラゴンは「画像５０１」により表示される。サブデッキ設定は、各クエストのサブデッキ設定に関する情報を含む。値「ＮＡ」は、当該クエストがサブデッキ設定の対象でないことを示す。図示の例では、クエスト１およびクエスト２はサブデッキ設定の対象ではない。一方、クエスト１０１には、「サブデッキ設定」として「デッキ２１」が設定されている。このように、第１実施形態では、特定のクエストまたは特定の敵キャラクタに対して、メインデッキのカードの入替え候補としてのカードを含むサブデッキを設定できるものとする。サブデッキの情報は上述のデッキ管理テーブル１２３１で管理される。デッキ管理テーブル１２３１において、「デッキ２１」は、「クエスト１０１用サブデッキ」または「対ドラゴン用サブデッキ」等として管理されてもよい。サブデッキ設定の情報は、デッキ管理テーブル１２３１内で重複してもよい。例えば、ドラゴンに類似する敵キャラクタが出現する複数のクエストに同一の「デッキ２１」がサブデッキとして設定されてよい。また、すべてのクエストにサブデッキ設定が可能であってもよい。

上記ステップＳ１３において、ユーザが挑戦しようとしているクエストがクエスト１０１の場合、ＹＥＳの分岐によりステップＳ１４に進む。他方、ユーザが挑戦しようとしているクエストがクエスト１またはクエスト２の場合、ＮＯの分岐により処理を終了する。

ステップＳ１４において、表示制御部１１４は、展開ボタンの機能を有するＵＩオブジェクトをゲーム画像にさらに表示させる。展開ボタンは、サブデッキ表示を要求する操作ボタンの一例である。展開ボタンは、サブデッキを表示する領域であるサブデッキフィールドを展開するための操作ボタンと言うこともできる。サブデッキフィールドは、ゲーム画像の第２範囲の一例である。

図１１は、第１実施形態のデッキ表示に係るゲーム画像の第１の例を示す。
図１１の左側のゲーム画像１１は、ユーザが所定のゲーム画面を介して挑戦しようとするクエストを選択したことに応答して、確認画面として表示部１０７２により提示される。ゲーム画像１１は、特に、クエスト管理テーブル１２３３の「クエスト１０１」がユーザにより選択された場合に表示されるゲーム画像の一例である。例えばゲーム画像１１は、敵キャラ画像５０、敵キャラ情報５１、メインデッキフィールド２０、総ＨＰ情報４１、メインデッキ切替ボタン４２、もどるボタン４３、挑戦するボタン４４、および展開ボタン４５を含む。

敵キャラ画像５０は、クエストに設定された敵キャラクタの画像を含む。図示の例では、クエスト管理テーブル１２３３の「クエスト１０１」に設定された「画像５０１」が表示される。

敵キャラ情報５１は、選択されたクエストに設定された敵キャラクタの情報を含む。図示の例では、クエスト管理テーブル１２３３の「クエスト１０１」に設定された「ドラゴン」という文字情報を含む。ゲーム画像に表示される敵キャラ情報５１は、敵キャラクタの属性、攻撃力、ＨＰ値、特殊技など、さらに多くの情報を含んでよい。これらの情報もまたクエスト管理テーブル１２３３に記憶され得る。

メインデッキフィールド２０は、メインデッキを表示する領域であり、メインデッキに含まれるカードを表示するための枠２０Ａ～２０Ｆを含む。枠の数は一例である。メインデッキフィールド２０は、ゲーム画像１１内の所定の位置、例えばゲーム画像１１の中心位置から所定の距離のところに表示される。メインデッキフィールド２０は、ステップＳ１１で読み出されたアクティブなメインデッキの情報を表示する。例えば、デッキ２に含まれる第１枠～第６枠のカードの画像が、順に、枠２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，２０Ｅ，２０Ｆ内に表示される。

総ＨＰ情報４１は、メインデッキフィールド２０内の枠２０Ａ～２０Ｆに表示された６枚のカードのＨＰの合計値を表示する。デッキ管理部１１５は、所持カード管理テーブル１２３２から該当カードのＨＰ値を読み出し、合計値を算出する。

メインデッキ切替ボタン４２は、表示するメインデッキの切替えを可能にする操作ボタンである。メインデッキ切替ボタン４２がユーザによってタップされると、デッキ管理テーブル１２３１に記憶された上または下の行のメインデッキの情報が読み出され、表示が切り替えられる。例えば、左側のボタン４２がユーザによってタップされると、表示中の「デッキ２」に代えて「デッキ１」に関する表示に切り替えられる。同様に、右側のボタン４２がタップされると、表示中の「デッキ２」に代えて「デッキ３」に関する表示に切り替えられる。

もどるボタン４３は、前のゲーム画面に戻るためのボタンである。もどるボタン４３がユーザによってタップされると、選択中のクエスト（図示の例では「ドラゴン」のクエスト（クエスト１０１））に挑戦せず、直前に表示されていたゲーム画像の表示に戻る。ユーザは、例えば、挑戦するクエストを変更したいとき、またはクエストプレイ自体をキャンセルしたいときなどに、もどるボタン４３を選択する。

挑戦するボタン４４は、選択中のクエストでのゲームプレイを開始するボタンである。挑戦するボタン４４がユーザによってタップされると、メインデッキフィールド２０に表示されているメインデッキのカードを用いて、表示中のクエストでのゲームプレイが開始される。

展開ボタン４５は、サブデッキフィールドの展開を要求する操作ボタンである。選択中のクエストがサブデッキ設定対象ではない場合（図６のステップＳ１３でＮＯの場合）、展開ボタン４５は表示されない。展開ボタン４５がユーザによってタップされると、操作受付部１１３、表示制御部１１４、およびデッキ管理部１１５の連携により、図５のステップＳ３のサブデッキ表示処理が実行される。ユーザが展開ボタン４５をタップする操作は、第１操作の一例である。

図７は、図５のステップＳ３に示したサブデッキ表示処理の詳細を示す。
ステップＳ３１において、デッキ管理部１１５は、選択中のクエストに設定されたサブデッキ情報を取得する。サブデッキ情報は、サブデッキに含まれるカードに関する情報を含む。例えばデッキ管理部１１５は、まずクエスト管理テーブル１２３３から「クエスト１０１」に設定されたサブデッキ設定「デッキ２１」を読み出し、次いでデッキ管理テーブル１２３１から「デッキ２１」の編成情報「カード２１」、「カード２２」、「カード２３」・・・を読み出すことにより、サブデッキ情報を取得する。

ステップＳ３２において、デッキ管理部１１５は、表示制御部１１４と連携して、サブデッキ表示用のゲーム画像に変更する処理を実行する。この処理は、ゲーム画像におけるメインデッキフィールドの位置を変更することによってサブデッキフィールドを表示させる処理を含む。この処理はまた、ゲーム画像におけるメインデッキフィールドの位置を変更して、変更前のメインデッキフィールドの位置にサブデッキフィールドを表示させる処理を含み得る。

ステップＳ３３において、デッキ管理部１１５は、サブデッキフィールドおよびサブデッキを表示させる。サブデッキフィールドの表示は、専用のＵＩオブジェクトを用いて実現される。サブデッキフィールドは、読み出したサブデッキのカードの情報を表示する。

図１１の右側のゲーム画像１２は、ゲーム画像１１において展開ボタン４５がタップされた場合に表示されるゲーム画像の一例である。例えばゲーム画像１２は、ゲーム画像１１に含まれていたのと同じ表示（敵キャラ画像５０、敵キャラ情報５１、メインデッキフィールド２０、総ＨＰ情報４１、メインデッキ切替ボタン４２、もどるボタン４３、および挑戦するボタン４４）に加えて、サブデッキフィールド３０、および折畳みボタン４６をさらに含む。

サブデッキフィールド３０は、サブデッキを表示する領域であり、サブデッキに含まれるカードを表示するための枠３０Ａ～３０Ｆを含む。枠の数は一例である。図示の例では、サブデッキフィールド３０は、吹出しの外観を有するＵＩオブジェクトとして表示される。例えば、デッキ２１に含まれる第１枠～第６枠のカードの画像が順に、枠３０Ａ，３０Ｂ，３０Ｃ，３０Ｄ，３０Ｅ，３０Ｆ内に表示される。これにより、ユーザは、クエストプレイを開始する前の確認画面において、クエストの情報とともに、クエストで使用される予定のメインデッキと、メインデッキの入替え候補のカードを含むサブデッキと、を確認することができ、メインデッキのカードの入替えの要否を判断することができる。

折畳みボタン４６は、サブデッキフィールド３０の表示を消す機能を有する。例えばゲーム画像１２において折畳みボタン４６がタップされると、ゲーム画像１２からゲーム画像１１へと遷移する。

図１１の例では、サブデッキフィールド３０が展開される際、サブデッキフィールド３０の表示スペースの分、メインデッキフィールド２０の表示スペースが上方に移動するように設定されている。この例では、破線で示したように、ゲーム画像１１においてメインデッキフィールド２０が表示されていた位置付近に、ゲーム画像１２においてサブデッキフィールド３０が表示される。この例ではまた、敵キャラ情報５１および総ＨＰ情報４１も同様に上方に移動して表示される。敵キャラ画像５０は、図示したように表示を維持されてもよいし、表示を変更されてもよい。サブデッキフィールド３０の展開時には、ゲーム画像を簡潔にするため、敵キャラ画像５０、敵キャラ情報５１または総ＨＰ情報４１の表示が消されてもよい。あるいは、メインデッキフィールド２０の位置はそのままで、メインデッキフィールド２０の下方に（例えば、もどるボタン４３および挑戦するボタン４４に重畳して）サブデッキフィールド３０が表示されてもよい。サブデッキまたはサブデッキフィールド３０の表示態様は、これらに限定されない。折畳みボタン４６がタップされると、メインデッキフィールド２０の位置が変更され（元に戻され）てよい。

図１１に例示したように、サブデッキフィールド３０の展開時にメインデッキフィールド２０の位置を変更することで、ゲーム画面において、展開ボタン４５を押すとメインデッキがせり上がり、隠れていたサブデッキが展開表示され、折畳みボタン４６を押すとサブデッキが折り畳まれる（隠れる）、という視覚効果がもたらされる。

（第２実施例）
第２実施例では、第１実施例の動作に加えて、ユーザの操作に応答してメインデッキに含まれるカードとサブデッキに含まれるカードとを入れ替える、デッキ表示動作について説明する。

図１２は、第１実施形態に係るユーザ端末の情報処理動作の第２実施例を示すフローチャートである。
まずステップＳ１において、ユーザ端末１００は、制御部１１０の制御の下、メインデッキ表示処理を実行する。この処理は、第１実施例において図５および図６に関して説明したステップＳ１と同様の処理であるので、詳細な説明は省略する。

次いでステップＳ２において、ユーザ端末１００は、操作受付部１１３により、サブデッキ表示を要求するユーザ操作（ユーザの第１操作）を受け付けたかどうかを監視し、当該ユーザ操作を受け付けた場合（ＹＥＳ）、ステップＳ３に進む。この処理もまた第１実施例で説明したステップＳ２と同様の処理であるので、詳細な説明は省略する。サブデッキ表示を要求するユーザ操作を受け付けることなく例えば一定時間が経過した場合（ＮＯ）、ステップＳ８に進む。

ステップＳ３において、ユーザ端末１００は、制御部１１０の制御の下、サブデッキ表示を要求するユーザ操作に応答してサブデッキ表示処理を実行する。この処理もまた第１実施例で説明したステップＳ３と同様の処理であるので、詳細な説明は省略する。

ステップＳ４において、ユーザ端末１００は、操作受付部１１３により、入替え操作（ユーザの第２操作）を受け付けたか否かを判定する。入替え操作は、表示されているデッキのカードの入替えを要求する操作であり、例えばドラッグアンドドロップ操作である。入替え操作についてはさらに後述する。入替え操作を受け付けたと判定される場合（ＹＥＳ）、ステップＳ５に進み、入替え操作を受け付けることなく例えば一定時間が経過した場合（ＮＯ）、ステップＳ６に進む。

ステップＳ５において、表示制御部１１４は、操作受付部１１３が受け付けた入替え操作にしたがって、入替え処理を行い、入替え後のゲーム画像を表示させる処理を行う。

図１３は、第１実施形態に係るカード入替え処理を説明するゲーム画像の一例を示す。カード入替え処理は、メインデッキのカードとサブデッキのカードとを入れ替える処理を含む。図１３の左側のゲーム画像１３は、メインデッキフィールド２０およびサブデッキフィールド３０を含み、サブデッキフィールド３０が展開された図１１の右側のゲーム画像１２の一部分に対応する。矢印ＤＤは、ユーザによるドラッグアンドドロップ操作を示す。矢印ＤＤは、ゲーム画像１３に実際に視覚的演出として表示されてもよいし、ゲーム画像１３には表示されなくてもよい。矢印ＤＤは、ドラッグアンドドロップ操作の開始位置がサブデッキフィールド３０内の第２枠３０Ｂ内にあり、ドラッグアンドドロップ操作の終了位置がメインデッキフィールド２０内の第２枠２０Ｂ内にあることを示す。これは、枠３０Ｂのカードと枠２０Ｂのカードとを入れ替える操作に対応する。

操作受付部１１３は、例えば、サブデッキフィールド３０内のいずれかの枠からメインデッキフィールド２０内のいずれかの枠へのドラッグアンドドロップ操作が検知されたことを、入替え操作を受け付けたと判定する。操作受付部１１３は、メインデッキフィールド２０内のいずれかの枠からサブデッキフィールド３０内のいずれかの枠へのドラッグアンドドロップ操作が検知されたことを、入替え操作を受け付けたと判定してもよい。入替え操作は、メインデッキフィールド２０内の枠同士またはサブデッキフィールド３０内の枠同士の入替えを要求するものでもよい。この場合、入替え操作は、メインデッキのカードの並び順の変更またはサブデッキのカードの並び順の変更を要求する操作に対応する。例えば、ドラッグアンドドロップ操作の開始位置がメインデッキフィールド２０内の第１枠で検知され、終了位置がメインデッキフィールド２０内の第３枠で検知される場合、操作受付部１１３は、この操作をメインデッキフィールド２０内の第１枠と第３枠のカードを入れ替える操作として受け付ける。メインデッキフィールド２０内の枠同士またはサブデッキフィールド３０内の枠同士の入替え操作は受け付けないように設定されてもよい。ドラッグアンドドロップ操作はスワイプ操作と読み替えられてもよい。あるいは、ドラッグアンドドロップ操作の代わりに、メインデッキフィールド２０またはサブデッキフィールド３０のいずれかの枠がタップされ、その後一定時間内にメインデッキフィールド２０またはサブデッキフィールド３０のいずれかの枠がタップされるタップ操作が検知されたことを入替え操作として受け付けてもよい。第２操作としての入替え操作は、他の同様のタッチ操作に置き換えられてもよい。入替え操作はまた、他の物理ボタンまたは他のコマンドによる操作に置き換えられてもよい。操作受付部１１３は、受け付けた入替え操作の情報をデッキ管理部１１５に渡す。デッキ管理部１１５は、受け取った情報に応じて、デッキ管理テーブル１２３１を書き換える処理を行う。

図１３の右側のゲーム画像１４は、ゲーム画像１３に対するドラッグアンドドロップ操作ＤＤに応答してカードの入替え処理が行われた後のゲーム画像を示す。ゲーム画像１４は、ステップＳ５で表示されるゲーム画像の一例である。ゲーム画像１３に対し、ゲーム画像１４では、メインデッキフィールド２０の第２枠２０Ｂのカードと、サブデッキフィールド３０の第２枠３０Ｂのカードと、が入れ替わっている。

次いでステップＳ６において、操作受付部１１３は、サブデッキ表示終了を要求する操作、例えば、折畳みボタン４６をタップする操作等を受け付けたか否かを判定する。サブデッキ表示終了を要求する操作が検知された場合（ＹＥＳ）、ステップＳ７に進み、一定時間検知されなければ（ＮＯ）、ステップＳ４に戻り、引き続き入替え操作の有無を判定する。

ステップＳ７において、表示制御部１１４は、サブデッキ表示を消す（サブデッキフィールド３０を折り畳む）処理を行う。この処理はメインデッキフィールド２０の位置を変更する（元に戻す）処理を含んでよい。

ステップＳ８において、操作受付部１１３は、デッキ表示終了を要求する操作、例えば、もどるボタン４３または挑戦するボタン４４をタップする操作を受け付けたか否かを判定する。デッキ表示終了を要求する操作が検知された場合（ＹＥＳ）、制御部１１０は、処理を終了し、検知された操作に応じたゲーム画像表示を実行する。例えば、もどるボタン４３がタップされた場合には、クエスト選択前のゲーム画像表示に戻る。挑戦するボタン４４がタップされた場合には、メインデッキフィールド２０に表示されているメインデッキのカードを用いるクエストプレイのゲーム画像に遷移する。サブデッキフィールド３０が展開された状態でもどるボタン４３または挑戦するボタン４４の操作を受け付けてもよく、その場合、ステップＳ６およびＳ７の処理は省略されてもよい。

（他の実施例）
サブデッキフィールドの展開例（サブデッキ表示例）は、図１１に関して説明した例に限られない。
図１４は、第１実施形態のデッキ表示に係るゲーム画像の第２の例を示す。ゲーム画像１５は、サブデッキ表示を要求するユーザ操作（ユーザの第１操作）を受け付けた場合に表示されるゲーム画像の一部分に対応する。ゲーム画像１５は、メインデッキフィールド２０と、サブデッキフィールド３２と、を含む。メインデッキフィールド２０は、図１１のゲーム画像１２のメインデッキフィールド２０と同じである。サブデッキフィールド３２は、スクロールバー３３を含む。ゲーム画像１５は、サブデッキフィールド３２の表示スペースが限られているか、またはサブデッキに含まれるカードの数が多いため、サブデッキフィールド３２内に一度にすべてのカードを表示できない場合の表示例である。ゲーム画像１５では、サブデッキフィールド３２には、サブデッキに含まれる６枚（またはそれ以上）のカードのうち５枚しか表示されていない。スクロールバー３３は、サブデッキフィールド３２の表示対象の切替えを可能にする。ユーザがスクロールバー３３のカーソルを上下にスライド操作すると、操作受付部１１３および表示制御部１１４は、スライド操作に応答して表示対象を変更する。サブデッキフィールド３２が展開されるとき、メインデッキフィールド２０は、ゲーム画像１２と同様に、位置を移動して表示されてよい。

図１５は、第１実施形態のデッキ表示に係るゲーム画像の第３の例を示す。ゲーム画像１６もまた、サブデッキ表示を要求するユーザ操作（ユーザの第１操作）を受け付けた場合に表示されるゲーム画像の一部分に対応する。ゲーム画像１６は、メインデッキフィールド２０と、サブデッキフィールド３４と、を含む。メインデッキフィールド２０は、図１１のゲーム画像１２のメインデッキフィールド２０と同じである。サブデッキフィールド３４は、ゲーム画像１２のサブデッキフィールド３０に比べて表示スペースが拡大されている。ゲーム画像１６は、サブデッキに含まれるカードの数に応じてサブデッキフィールド３４を拡大して表示する表示例である。図１５の例では、サブデッキが１０枚のカードを含んでおり、サブデッキフィールド３４は、１０枚のカードが一度に表示されるように拡大される。サブデッキフィールド３４は、例えば、カード枚数に応じてあらかじめ用意された大きさの異なるＵＩオブジェクト、またはカード枚数に応じて大きさが可変に構成されたＵＩオブジェクトを用いて実現される。サブデッキフィールド３４が展開されるとき、メインデッキフィールド２０は、ゲーム画像１２と同様に、位置を移動して表示されてよい。

（３）効果
上述したように、第１実施形態では、デッキを使用するゲームプレイの前に、ゲームで使用されるメインデッキと、メインデッキに含まれるカードの入替え候補のカードを含むサブデッキと、をユーザが容易に確認できるようにした。ユーザは、ゲームプレイ前に、入替え候補のカードを確認し、入替えの要否を判断することができる。またユーザは、カードの入替えを望む場合、わざわざデッキ編成パートに戻ることなく、簡易な操作でカードの入替えを行うことができる。ユーザから受け付ける操作が少ないのでユーザ端末１００の制御部１１０による処理を高速化することができる。同様に、ゲームパート遷移の必要がないので、制御部１１０の処理負荷を軽減することができる。サブデッキフィールド３０をメインデッキフィールド２０の近くに表示させることで、ユーザは、デッキ編成を容易に確認することができる。さらに、メインデッキフィールド２０の位置を変更して、メインデッキフィールド２０が表示されていた位置にサブデッキフィールド３０を表示すれば、ユーザは視線移動せずにサブデッキを確認することができる。

第１実施形態では、あらかじめ特定のクエストまたは特定の敵用に、ゲームで使用されるメインデッキとは異なる、入替え候補のカードを含むサブデッキを編成可能とするゲーム設定を例に挙げて説明した。このようなゲーム設定は、特定のクエストまたは特定の敵に特に有利なカード、またはメインデッキの編成時に組み込むかどうか迷ったカードなどを、ユーザがサブデッキとして編成することを可能にし、ゲームの興趣性を高める。

ただし、第１実施形態はこのようなゲーム設定に限定されない。例えば、展開ボタン４５をタップするなどのユーザ操作を受け付けるたびに、デッキ管理部１１５が、所持カード管理テーブル１２３２からカードを抽出し、サブデッキの代わりに、レコメンドデッキとして表示するようにしてもよい。レコメンドの一例としては、デッキ管理部１１５がサーバ２００から他のユーザの情報を取得することにより、同じクエストに挑戦したユーザのデッキ情報に基づいて行われることが考えられる。例えば、当該クエストにおいて最も多く選択されたデッキ編成の情報がレコメンドデッキとして紹介されたり、または注目度の高いユーザのデッキ編成の情報が提示されてもよい。このとき、所持カード管理テーブル１２３２に含まれるカードのみが表示されるように制御されてよい。各ユーザ端末１００は、実際にクエストプレイで使用したメインデッキの情報をクエストの識別情報とともに任意のタイミングでサーバ２００に送信することができ、サーバ２００は、複数のユーザ端末１００のメインデッキの情報をクエストごとに統合し、蓄積することができる。また例えば、デッキ管理部１１５は、ユーザの所持カードのうち、表示中のメインデッキのカードを除いたカードの中から、ＨＰまたは攻撃力の値の高い順にカードを所定枚数抽出して、レコメンドデッキを生成し、表示させることができる。防御力の高いカード、特殊技を発動可能なカード、または敵キャラクタの属性に対して有利な属性を有するカードなど、他の抽出条件が設定されてもよい。あるいは、使用可能なカード枚数に制限がある場合に、上記技術が適用されてもよい。例えば、デッキ管理テーブル１２３１に記憶されたデッキに含まれるカードのうち、第１枠から制限枚数の枠までのカードをメインデッキとし、残りのカードをサブデッキとしてもよい。

［第２実施形態］
第１実施形態がシングルプレイの状況を想定したデッキ表示例に関するのに対し、第２実施形態は、協力プレイの状況を想定したデッキ表示例に関する。協力プレイは、複数のユーザ端末がゲームデータの一部を共有することにより協働してゲームを進行させるゲームプレイである。協力プレイは、マルチプレイ、協力バトル、またはマルチバトル、等と言い換えられてもよい。

以下では、第２実施形態について、主に第１実施形態との相違点について説明する。特に言及のない場合、第１実施形態に関して説明した構成または動作は、そのまままたは適宜変更して、第２実施形態に適用されてよい。

（１）構成
（１－１）ゲームシステム
第２実施形態に係るゲームシステムは、第１実施形態で図１を参照して説明したのと同じ構成を備えることができる。第１実施形態と同様、ユーザ端末１００は、第２実施形態に係る情報処理装置の一例である。

協力プレイは、例えば、複数のユーザ端末１００がサーバ２００との間で通信することによって、サーバ２００を介したオンライン協力プレイとして実現される。協力プレイは、サーバ２００を介さないＬＡＮプレイとして実現されてもよい。または協力プレイは、複数のユーザ端末１００がＢｌｕｅｔｏｏｔｈ（登録商標）等の近距離無線通信を介して直接通信することによってローカル協力プレイとして実現されてもよい。あるいは協力プレイは、ユーザ端末１００とサーバ２００との間の通信と、ユーザ端末１００間の直接通信と、を組み合わせて実現されてもよい。

以下では一例として、複数のユーザ端末１００がサーバ２００を介したオンライン協力プレイを実行する状況を想定して説明する。例えば、あるユーザ端末（ホスト端末）１００Ａが、協力プレイへの参加を募集するための「ルーム」の開設要求をサーバ２００に送信する。開設要求は、例えば、ユーザ端末１００Ａを使用するユーザ（ホスト）のＩＤ、ニックネーム、デッキ情報、および協力プレイの対象クエストの情報を含む。協力プレイはルーム単位で行われる。ここではルーム単位の協力プレイに参加するユーザを協力プレイヤーとも呼ぶ。協力プレイヤーは、ルームを開設するホストおよび開設済みのルームに参加するゲストを含む。

サーバ２００は、ユーザ端末１００Ａから受信した開設要求に応答してルームを開設し、ルームの情報を公開する。公開される情報は、例えば、ルームの識別情報、ホストのニックネーム、デッキの一部、および協力プレイの対象クエストの情報である。他のユーザ端末（ゲスト端末）１００Ｂは、公開された情報をもとにルームへの参加要求をサーバ２００に送信する。参加要求は、例えば、ユーザ端末１００Ｂを使用するユーザ（ゲスト）のＩＤ、ニックネーム、およびデッキ情報を含む。サーバ２００は、受信した参加要求に応答して、公開するルームの情報にゲストの情報を追加する。ホスト端末１００Ａおよび参加要求を送信したゲスト端末１００Ｂは、ルーム成立後、ゲームプレイ前の協力プレイ確認画面において、第２実施形態に係るデッキ表示を実現することができる。ルーム成立の条件は、例えば、ルームの参加人数が上限値に達したこと、または参加募集の制限時間に達したことなど、任意に設定されてよい。第２実施形態に係るデッキ表示を含む協力プレイ確認画面は、ルーム成立前に、ルームへの参加募集が継続されている状況で実現されてもよい。

（１－２）ハードウェア構成
第２実施形態に係るサーバ２００およびユーザ端末１００は、図１を参照して第１実施形態に関して説明したのと同じハードウェア構成を備えることができる。

（１－３）機能構成
（１－３－１）サーバ
第２実施形態に係るサーバ２００は、図２を参照して第１実施形態に関して説明したのと同様の機能構成を備えることができる。
第２実施形態では、ゲーム進行部２１３は、さらに、ユーザ端末１００から受信したルーム開設要求に応答してルームを開設し、公開情報を生成する。ゲーム進行部２１３はまた、各ルームに係る共有データを生成し、協力プレイを支援する。

（１－３－２）ユーザ端末
図１６は、第２実施形態に係るユーザ端末１００の機能構成の一例を示す。ユーザ端末１００は、第１実施形態と同様に、制御部１１０と、記憶部１２０と、を備える。

記憶部１２０は、ゲームプログラム記憶部１２１と、ゲーム情報記憶部１２２と、デッキ情報記憶部１２３と、を備える。ゲームプログラム記憶部１２１およびゲーム情報記憶部１２２は、第１実施形態と同様であるので、詳細な説明は省略する。

デッキ情報記憶部１２３は、デッキ管理テーブル１２３１、所持カード管理テーブル１２３２、クエスト管理テーブル１２３３、および協力プレイ用デッキ管理テーブル１２３４を記憶する。デッキ管理テーブル１２３１、所持カード管理テーブル１２３２、およびクエスト管理テーブル１２３３は、第１実施形態と同様である。
協力プレイ用デッキ管理テーブル１２３４は、協力プレイ用に編成されたデッキの内容を表す情報を記憶する。

制御部１１０は、ゲームプログラム記憶部１２１に記憶されたゲームプログラムを実行することにより、ゲーム進行部１１１、オブジェクト制御部１１２、操作受付部１１３、表示制御部１１４、デッキ管理部１１５、および協力プレイ管理部１１６として機能し得る。ゲーム進行部１１１、オブジェクト制御部１１２、操作受付部１１３、表示制御部１１４、およびデッキ管理部１１５は、第１実施形態と同様の機能を有するので、詳細な説明は省略する。

協力プレイ管理部１１６は、協力プレイに関連する種々の機能を有する。例えば、協力プレイ管理部１１６は、ユーザの操作に応答して協力プレイのためのルームの開設要求またはルームへの参加要求を出力する。協力プレイ管理部１１６はまた、デッキ管理部１１５と連携して、開設要求または参加要求とともに送信すべきデッキ情報を取得する。協力プレイ管理部１１６はまた、表示制御部１１４と連携して、協力プレイ確認画面用のゲーム画像におけるメインデッキおよびサブデッキの表示を生成する。

（１－４）ゲームの構成
第２実施形態に係るゲームプログラムによって実現されるゲームは、第１実施形態と同様、１以上のカードを組み合わせて編成されたデッキを使用可能なゲームを含む。第２実施形態についても、第１実施形態と同様のクイズＲＰＧにおける適用例を用いて説明するが、これに限定されるものではなく、第２実施形態もまた、デッキを使用可能な他の分類のゲームに適用可能である。

図１７は、第２実施形態に係るゲームプログラムによって実現されるゲームの構成を示す略図である。ゲームは、複数のゲームパートで構成される。一例として、ゲームは、ホームパートと、デッキ編成パートと、クエストパートと、協力プレイパートと、を含む。ホームパートおよびデッキ編成パートは、第１実施形態で説明したのと同様のゲームパートである。クエストパートは、第１実施形態と同様、ユーザがデッキを用いてシングルプレイ用のクエストでゲームプレイを行うことのできるゲームパートである。協力プレイパートは、複数のユーザ（協力プレイヤー）による協力プレイを可能とするゲームパートである。協力プレイヤーは、カードを出し合って１つのデッキ（「ルームデッキ」と称する）を編成する。ルームデッキは、協力プレイ用のクエストでゲームプレイを行うために使用される。協力プレイ用のクエストは、シングルプレイ用のクエストと同様、敵キャラクタの討伐のような目標がそれぞれに設定された複数のクエストを含む。第１実施形態で説明したのと同様に、各協力プレイヤーは、出題されるクイズに正解してルームデッキに含まれるカードの効果を発動させることにより、ルーム（またはチーム）として協力して目標達成をめざす。例えば、ルーム内の協力プレイヤーには同じクイズが出題され、各協力プレイヤーは、各々のユーザ端末１００を介して解答を入力する。入力された解答は、例えばサーバ２００において多数決が取られ、ルームとしての解答が決定され、正否が判定される。多数決が取れない場合には例えばホストの解答が優先される。あるいは、協力プレイヤーごとに解答の成否が判定され、ルームデッキのカードのうち、クイズに正解したプレイヤーが所有するカードからアクションが発動されてもよい。協力プレイパートの場合にも、各協力プレイヤーは、ルーム（またはチーム）として挑戦しようとするクエストおよびルームデッキの内容を確認してから、実際の協力プレイに進む。協力プレイ用クエストの情報は、第１実施形態で説明したクエスト管理テーブル１２３３と同様のテーブル（図示せず）により、サーバ２００の記憶部２２０およびユーザ端末１００の記憶部１２０に保存され得る。協力プレイ用のクエストは、シングルプレイ用のクエストと区別される必要はない。協力プレイパートとクエストパートとは一体化されてもよい。

ゲーム画像６０は、ホームパートに係るゲーム画像の一例（略図）である。例えばゲーム画像６０は、デッキ編成ボタン６１と、クエストボタン６２と、協力プレイボタン６３と、を含む。デッキ編成ボタン６１は、第１実施形態で説明したのと同様、デッキ編成パートへの遷移を要求する操作ボタンである。クエストボタン６２は、第１実施形態で説明したのと同様、シングルプレイ用のクエストパートへの遷移を要求する操作ボタンである。協力プレイボタン６３は、協力プレイパートへの遷移を要求する操作ボタンである。操作ボタンは、ユーザによって選択されると所定の機能を発揮するように構成されたＵＩオブジェクトである。操作ボタンに代えて他のコマンドが使用されてもよい。

第１実施形態に関して説明したのと同様に、デッキ編成ボタン６１が選択されると、ホームパートからデッキ編成パートに遷移し、デッキ編成パートに係るゲーム画像７が表示される（Ｑ１）。ゲーム画像７は、第１実施形態で説明したゲーム画像７と同様であるので説明を省略する。ゲーム画像７においてもどるボタン７６が選択されると、デッキ編成パートからホームパートに遷移する（Ｑ２）。

第１実施形態に関して説明したのと同様に、クエストボタン６２が選択されると、ホームパートからシングルプレイ用のクエストパートに遷移する。クエストパートは、第１実施形態で説明したのと同様であるので、図示および説明を省略する。

ゲーム画像６０において協力プレイボタン６３が選択されると、ホームパートから協力プレイパートに遷移し、協力プレイパートに係るゲーム画像９０が表示される（Ｑ３）。ゲーム画像９０は、協力プレイパートの入口に対応するゲーム画像の一例である。ゲーム画像９０は、例えば、ルーム選択ボタン９１と、もどるボタン９２とを含む。ルーム選択ボタン９１は、新しいルームの開設要求に係るボタン（「新ルーム開設」）、または開設済みルームへの参加要求に係るボタン（「ルームＲ１」、「ルームＲ２」・・・）等を含む。もどるボタン９２は、前のゲーム画面に戻るためのボタンである。例えば、もどるボタン９２が選択されると、協力プレイパートからホームパートに遷移する（Ｑ４）。

ゲーム画像９０においていずれかのルーム選択ボタン９１が選択された場合、所定の操作を行うゲーム画面（図示省略）を経て、ゲーム画像１７のような確認画面が表示される（Ｑ５）。例えばゲーム画像１７は、図４のゲーム画像１１と同様、敵キャラクタの画像５０、敵キャラクタの情報５１、ルームデッキフィールド２５、もどるボタン４３、および挑戦するボタン４４を含む。敵キャラクタの画像５０および敵キャラクタの情報５１は、第１実施形態と同様、クエストに設定された敵キャラクタの情報を示す。ルームデッキフィールド２５は、ゲームで使用されるルームデッキの内容を示す。ルームデッキは、後述するように、各協力プレイヤーが所持するカードを含む。ルームデッキフィールド２５は、各協力プレイヤーのカードを表示するためのデッキフィールドを含む。図示の例では、協力プレイヤーは３人（１Ｐ、２Ｐ、３Ｐ）である。挑戦するボタン４４が選択されると、表示中のルームデッキを用いる選択したクエストでのゲームプレイが開始される。もどるボタン４３が選択されると、ゲーム画像９０に遷移する（Ｑ６）。ユーザは、ゲーム画像１７のような確認画面において、これから協力プレイで挑戦するクエストおよび使用されるデッキの最終確認を行うことができる。

協力プレイは、友人同士など固定メンバーでプレイされることもあれば、不特定多数のプレイヤーに募集をかけて毎回異なるメンバーでプレイされることもある。特に後者の場合、プレイヤーごとに所持カードは異なるから、協力プレイヤーが所持カードからカードを出し合うことによって構成されるルームデッキの内容も毎回大きく異なることになる。協力プレイにおいても、ルームデッキの内容は、ゲームを有利に進められるかどうかに大きく影響する。そのため、各協力プレイヤーは、協力プレイ開始前に、他の協力プレイヤーのカードを確認し、ルームデッキ全体のバランスを考慮して自身のカードを変更する、いわゆる「すり合わせ」作業を望む。このような戦略的なすり合わせ作業は、ゲームの興趣性を高める。

ゲーム画像１７のような協力プレイ前の確認画面において、各ユーザがルームデッキのカードのうち自身のデッキの内容を変更したいと考える場合、ユーザは、この例では、ゲーム画像１７から何らかの操作を経てゲーム画像７のようなデッキ編成用画面を表示させるか（Ｑ７）、またはゲーム画像１７から、もどるボタン４３、もどるボタン９２、およびデッキ編成ボタン６１という順に選択して、ゲーム画像７に切り替える必要がある。第２実施形態は、このような協力プレイ前の確認画面におけるデッキ編成を可能とする。

（２）動作
次に、図１６に示したユーザ端末１００による情報処理動作例について説明する。以降の動作の前提として、少なくとも１のユーザ端末１００とサーバ２００との間の通信が確立され、当該ユーザ端末１００の制御部１１０および記憶部１２０の連携により、ゲームプログラムに記述されたコードに従ってゲームがいくらか進行されているものとする。

なお、ローカル協力プレイの場合など、以下で説明するサーバ２００の動作は、適宜、１または複数のユーザ端末１００の動作に読み替えられる。

図１８は、第２実施形態に係るユーザ端末１００の情報処理動作の一例を示すフローチャートである。ここでは、ユーザ端末１００が、サーバ２００にルーム開設要求を送信するホスト端末であるものとして説明する。例えばユーザ端末１００は、ルーム開設を要求するユーザ操作を受け付けたことをトリガとして、以降の処理を実行する。ルーム開設を要求するユーザ操作は、協力プレイの対象クエストを選択する操作を含む。

まずステップＳ１０１において、ユーザ端末１００は、デッキ管理部１１５および協力プレイ管理部１１６の連携により、協力プレイ用デッキ管理テーブル１２３４から協力プレイ用デッキの情報を取得し、対象クエストを指定する情報とともにルーム開設要求としてサーバ２００に送信する。

協力プレイ用デッキは、第１実施形態で説明したデッキと同様、１または複数のカードを含む。協力プレイ用デッキの内容は、協力プレイ用デッキ管理テーブル１２３４に記憶される。

図１９は、協力プレイ用デッキ管理テーブル１２３４の一例を示す。協力プレイ用デッキ管理テーブル１２３４は、協力プレイ用デッキの内容を表す情報を記憶し、例えば、デッキＩＤ、コメント、および編成情報を含む。デッキＩＤは、保存されているデッキを識別可能な情報（図示の例では、「デッキ１０１」、「デッキ１０２」・・・）を含む。コメントは、各デッキの説明を含み、例えばユーザの理解を助けるためデッキ編成時にゲーム画面上に表示される。図示の例では、デッキ１０１は「対ドラゴン用デッキ」であり、デッキ１０２は「対ＸＸモンスター用デッキ」である。コメントはオプションであり省略されてもよい。編成情報は、各デッキを編成するカードの情報を含む。カードの情報は、例えばカードを識別可能な情報（図示の例では、「カード１０１」、「カード１０２」、「カード１０３」・・・「カード１１１」・・・）を含む。各デッキには、最大枠数（カードの上限数）（図示の例では６）が設定される。カードの並び順は、枠情報（図示の例では、「第１枠」、「第２枠」・・・「第６枠」）により管理される。図示の例では、「デッキ１０１（対ドラゴン用デッキ）」は、第１枠に「カード１０１」、第２枠に「カード１０２」、第３枠に「カード１０３」・・・を含む。「デッキ１０２（対ＸＸモンスター用デッキ）」は、第１枠に「カード１１１」・・・を含む。協力プレイ用デッキ管理テーブル１２３４において、異なるデッキに同一のカードが重複して編成されてよい。例えば、デッキ１０２が、デッキ１０１に組み込まれている「カード１０１」を含んでもよい。このような重複を許容しない設定であってもよい。図示のように、協力プレイ用のデッキは、クエストまたは敵ごとに編成され保存されてよい。協力プレイ用のデッキは単一のデッキであってもよい。協力プレイ用デッキ管理テーブル１２３４に保存されるデッキは、ユーザによって編成されたデッキのみならず、サーバ２００から配信されたデッキおよびゲームプログラムによって自動生成されたデッキを含んでよい。第１実施形態と同様に、協力プレイ用のデッキに含まれるカードの情報は、所持カード管理テーブル１２３２において管理される。

上記ステップＳ１０１において、ユーザ端末１００は、ユーザによって選択された対象クエストに応じて、協力プレイ用デッキ管理テーブル１２３４から該当するデッキのレコードを読み出す。協力プレイ用のクエストには、第１実施形態でクエスト管理テーブル１２３３について説明したのと同様に、敵キャラクタが設定されているものとする。例えば、対象クエストに設定された敵キャラクタが「ドラゴン」の場合、「デッキ１０１」に含まれる第１枠～第６枠のカード情報が読み出される。あるいは、第１実施形態で説明したのと同様に、クエストまたは敵キャラクタにかかわらずアクティブなデッキが読み出されてもよいし、ユーザがデッキを選択可能なようにしてもよい。あるいは、協力プレイ用デッキは、シングルプレイ用デッキと共用であってもよい。この場合、協力プレイ用デッキ管理テーブル１２３４は、デッキ管理テーブル１２３１で代用される。

各ユーザ端末１００は、ルームの開設要求とともに、読み出した協力プレイ用デッキ（例えば、「デッキ１０１」）に含まれるカードの情報をサーバ２００に送信する。ユーザ端末１００が開設済みルームへの参加要求を送信するゲスト端末である場合も同様に、参加要求とともに協力プレイ用デッキに含まれるカードの情報をサーバ２００に送信する。サーバ２００は、例えば、各ユーザ端末１００から受信した協力プレイ用デッキの第１枠から順に所定数のカードを抽出し、ルームデッキを生成する。サーバ２００は、生成したルームデッキの情報を、ルームの共有データとしてユーザ端末１００に送信する。第２実施形態では、各ユーザの協力プレイ用デッキのうち、ルームデッキとして抽出（選択）される部分を「メインデッキ」と呼び、残りの部分を「サブデッキ」と呼ぶ。メインデッキは、協力プレイで使用される予定のカードを含むデッキであり、サブデッキは、メインデッキのカードの入替え候補のカードを含む、メインデッキとは異なるデッキである。

次いでステップＳ１０２において、ユーザ端末１００は、協力プレイ管理部１１６により、サーバ２００から受信された共有データをもとに、ルーム情報を取得する。ルーム情報は、ルームデッキに含まれるカードの情報を含む。

ステップＳ１０３において、ユーザ端末１００は、表示制御部１１４により、受信したルーム情報をもとに、協力プレイ確認画面においてルームデッキの内容を表示する。表示制御部１１４は、ゲーム画像にルームデッキを表示させるための表示データを生成し出力する。ゲーム画像は、対象クエストの情報と、ルームデッキの情報と、を含む。ルームデッキの情報は、ルームデッキを表示する領域であるルームデッキフィールドに表示される。ルームデッキの情報は、各協力プレイヤーのメインデッキの情報と言い換えることができる。ルームデッキフィールドは、メインデッキを表示する領域であるメインデッキフィールドを含む。ルームデッキフィールドは、第２実施形態においてゲーム画像の第１範囲の一例である。メインデッキフィールドは、複数の協力プレイヤー（複数のユーザ）の各々のデッキから選択されたカードを表示する領域である。メインデッキフィールドは、第２実施形態において、ゲーム画像の第１範囲のうち複数の協力プレイヤーの各々のための表示範囲の一例である。ルームデッキフィールドおよびメインデッキフィールドの表示は、専用のＵＩオブジェクトを用いて実現される。第２実施形態では、ルームデッキフィールドおよびメインデッキフィールドは、ゲーム画像内の所定の位置に表示される。

図２０は、第２実施形態のデッキ表示に係るゲーム画像の一例を示す。
図２０の左側のゲーム画像１７は、例えばルームの成立後、協力プレイ確認画面として表示部１０７２により提示される。ゲーム画像１７は、図１１に示したゲーム画像１１と同様に、敵キャラ画像５０、敵キャラ情報５１、総ＨＰ情報４１、もどるボタン４３、挑戦するボタン４４、および展開ボタン４５を含む。敵キャラ画像５０および敵キャラ情報５１は、協力プレイの対象クエストに設定された敵キャラクタの情報を示す。ゲーム画像１７はさらに、ルーム情報５２およびルームデッキフィールド２５を含む。

ルーム情報５２は、参加しているルームを識別可能な情報（図示の例では「ルームＲ３」）を含む。ルームを識別可能な情報は、サーバ２００において付与され、管理される。

ルームデッキフィールド２５は、ルームデッキを表示する領域である。ルームデッキフィールド２５は、ゲーム画像１７内の所定の位置、例えばゲーム画像１７の中心位置から所定の距離のところに表示される。ルームデッキフィールド２５は、ステップＳ１０２で取得されたルームデッキに含まれるカードの情報を表示する。図示の例では、ルームＲ３は、協力プレイヤーを３人（プレイヤー１（１Ｐ），プレイヤー２（２Ｐ），プレイヤー３（３Ｐ））含む。例えば、１Ｐはホストを表し、２Ｐおよび３Ｐはゲストを表す。２Ｐおよび３Ｐは例えば参加要求がサーバ２００において受信された順序に対応する。ルームデッキフィールド２５は、各協力プレイヤーのメインデッキを表示する、メインデッキフィールド２６，２７，２８を含む。図示の例では、ルームデッキフィールド２５を略３分割した各々にメインデッキフィールド２６，２７，２８が表示される。図示の例では、メインデッキフィールド２６，２７，２８は各々２枠を有し、ルームデッキの合計枠数は６枠である。枠数は一例にすぎない。メインデッキフィールド２６は、１Ｐのユーザ端末１００がルーム開設要求とともに送信した協力プレイ用デッキのうち、抽出された先頭の２枠（第１枠および第２枠）のカードを表示する。メインデッキフィールド２７は、２Ｐのユーザ端末１００が参加要求とともに送信した協力プレイ用デッキのうち、抽出された先頭の２枠（第１枠および第２枠）のカードを表示する。メインデッキフィールド２８は、３Ｐのユーザ端末１００が参加要求とともに送信した協力プレイ用デッキのうち、抽出された先頭の２枠（第１枠および第２枠）のカードを表示する。

ゲーム画像１７は、１Ｐ（ホスト）のユーザ端末１００に表示される例であるので、１Ｐ用のメインデッキフィールド２６が強調表示されている。２Ｐ用のユーザ端末１００においては、例えばルームデッキフィールド２５の表示順はそのままでメインデッキフィールド２７が強調表示され、３Ｐのユーザ端末１００においては、例えばルームデッキフィールド２５の表示順はそのままで３Ｐ用のメインデッキフィールド２８が強調表示される。展開ボタン４５の位置は、例えば２Ｐのユーザ端末１００ではメインデッキフィールド２７の下方、３Ｐのユーザ端末１００ではメインデッキフィールド２８の下方、など、ゲーム画像１７とは異なる位置に配置されてよい。各協力プレイヤーがユーザ端末１００を介して挑戦するボタン４４を押すと、準備完了の意思表示がサーバ２００に送信される。例えば、１Ｐ（ホスト）のユーザ端末１００のゲーム画面では、当初、挑戦するボタン４４はグレイアウト表示され、全ゲストが準備完了した後で挑戦するボタン４４を選択可となるように設定される。ホストがルームの最終意思表示として挑戦するボタン４４を押すと、表示されているルームデッキを用いて、表示中のクエストでの協力プレイが開始される。

総ＨＰ情報４１は、ルームデッキフィールド２５に表示されている６枚のカードのＨＰの合計値を示す。総ＨＰ情報４１の値は、サーバ２００において計算されてもよいし、各ユーザ端末１００において計算されてもよい。

上記の例では、サーバ２００は、各協力プレイヤーの協力プレイ用デッキから所定数として２枠ずつカードを抽出し、ルームデッキを生成した。抽出されるカード数は、ゲーム開発者等によって任意に設定されてよい。抽出されるカード数は、対象クエストごとまたは敵キャラクタごとにあらかじめ設定されてもよい。あるいは、サーバ２００は、抽出するカード数を協力プレイヤー数に応じて変更してもよい。例えば、ルームデッキの枠数が６と設定され、協力プレイヤー数に応じて各協力プレイヤーのメインデッキの枠数が決定されるという設定が可能である。この場合、サーバ２００は、協力プレイヤーが２人（ホスト１人とゲスト１人）であれば、各々のメインデッキの枠数を３（＝６／２）と決定する。同様に、協力プレイヤーが３人（ホスト１人とゲスト２人）であれば、各々のメインデッキの枠数を２（＝６／３）と決定する。割り切れない場合は、ホストの枠数を多くする、またはホストの枠数を少なくするなど調整される。対象クエストごとまたは敵キャラクタごとに、各協力プレイヤーのメインデッキ枠数を固定とするか協力プレイヤー数に応じて変化させるかが設定されてもよい。同様に、対象クエストごとまたは敵キャラクタごとに、ルームデッキの枠数、協力プレイヤーの上限数、または各協力プレイヤーのメインデッキ枠数等が設定されてもよい。

ステップＳ１０４において、ユーザ端末１００は、操作受付部１１３により、サブデッキ表示を要求するユーザ操作（ユーザ端末１００を使用する第１ユーザの第１操作）を受け付けたかどうかを監視し、当該ユーザ操作を受け付けた場合（ＹＥＳ）、ステップＳ１０５に進む。サブデッキ表示を要求するユーザ操作を受け付けることなく例えば一定時間が経過した場合（ＮＯ）、ステップＳ１１１に進む。サブデッキ表示を要求するユーザ操作は、例えば、ゲーム画像１７において展開ボタン４５を押す操作であるが、第１実施形態と同様、他の操作または他のコマンド等に置き換え可能である。

ステップＳ１０５において、ユーザ端末１００は、表示制御部１１４、デッキ管理部１１５、および協力プレイ管理部１１６の連携により、サブデッキ表示処理を実行する。サブデッキ表示処理は、ユーザ端末１００を使用するユーザ（第１ユーザ）の協力プレイ用デッキに含まれるカードのうち、当該ユーザのメインデッキフィールドに表示されていないカードをサブデッキフィールドに表示させることを含む。第２実施形態において、サブデッキフィールドは、ゲーム画像の第２範囲の一例である。なお、ここでは、ユーザ端末１００を使用するユーザのサブデッキのみを表示し、他のプレイヤーのサブデッキは表示しない態様を想定している。ただしこれは一例にすぎず、全協力プレイヤーのサブデッキを表示するようにしてもよい。

ステップＳ１０５の処理は、図７に示したサブデッキ表示処理のフローにしたがって実行され得る。
まずステップＳ３１において、デッキ管理部１１５は、協力プレイ管理部１１６と連携して、サブデッキの情報を取得する。サブデッキの情報は、例えば、サーバ２００から受信された共有データに含まれる。あるいは、デッキ管理部１１５は、ルーム開設要求とともに送信した「デッキ１０１」の編成情報を協力プレイ用デッキ管理テーブル１２３４から読み出し、自身のメインデッキフィールド２６に含まれるカードを除いた残りのカードをサブデッキとして特定してもよい。図示の例では、「デッキ１０１」のうち第３枠～第６枠がサブデッキのカードに対応する。

ステップＳ３２において、デッキ管理部１１５は、表示制御部１１４と連携して、サブデッキ表示用のゲーム画像に変更する処理を実行する。この処理は、ゲーム画像におけるメインデッキフィールドの位置を変更することによってサブデッキフィールドを表示させる処理を含む。この処理はまた、ゲーム画像におけるメインデッキフィールドの位置を変更して、変更前のメインデッキフィールドの位置にサブデッキフィールドを表示させる処理を含み得る。メインデッキフィールドの位置は、ルームデッキフィールドの位置と読み替えられてもよい。

ステップＳ３３において、デッキ管理部１１５は、サブデッキフィールドおよびサブデッキを表示させる。サブデッキフィールドの表示は、専用のＵＩオブジェクトを用いて実現される。サブデッキフィールドは、読み出したサブデッキのカードの情報を表示する。

図２０の右側のゲーム画像１８は、ゲーム画像１７において展開ボタン４５がタップされた場合に表示されるゲーム画像の一例である。例えばゲーム画像１８は、ゲーム画像１７に含まれていたのと同じ表示（敵キャラ画像５０、敵キャラ情報５１、メインデッキフィールド２０、総ＨＰ情報４１、もどるボタン４３、挑戦するボタン４４、およびルーム情報５２）に加えて、サブデッキフィールド３５および折畳みボタン４６をさらに含む。

サブデッキフィールド３５は、サブデッキを表示する領域であり、サブデッキに含まれるカードを表示するための枠（図示の例では４枠）を含む。例えば、「デッキ１０１」の第３枠～第６枠のカードの画像が順にサブデッキフィールド３５の枠内に表示される。サブデッキフィールド３５に表示される枠の数は、カードの数に応じて変更されてもよいし、固定であってもよい。第１実施形態と同様に、サブデッキフィールド３５は、吹出しの外観を有するＵＩオブジェクトとして表示される。これにより、ユーザは、協力プレイを開始する前の確認画面において、クエストの情報とともに、協力プレイで使用される予定のルームデッキ全体と、自身が所持するカードを含むメインデッキと、メインデッキの入替え候補のカードを含むサブデッキと、を確認することができ、自身のメインデッキのカードの入替えの要否を判断することができる。

折畳みボタン４６は、サブデッキフィールド３５の表示を消す機能を有する。例えばゲーム画像１２において折畳みボタン４６がタップされると、ゲーム画像１８からゲーム画像１７へと遷移する。

図２０の例では、第１実施形態と同様に、サブデッキフィールド３５が展開される際、サブデッキフィールド３５の表示スペースの分、メインデッキフィールド２６を含むルームデッキフィールド２５全体の表示スペースが上方に移動するように設定されている。この例では、破線で示したように、ゲーム画像１７においてルームデッキフィールド２５が表示されていた位置付近に、ゲーム画像１８においてサブデッキフィールド３５が表示される。この例ではまた、敵キャラ情報５１、総ＨＰ情報４１、およびルーム情報５２も同様に上方に移動して表示される。敵キャラ画像５０は、図示したように表示を維持されてもよいし、表示を変更されてもよい。サブデッキフィールド３５の展開時には、ゲーム画像を簡潔にするため、敵キャラ画像５０、敵キャラ情報５１、総ＨＰ情報４１、またはルーム情報５２の表示が消されてもよい。あるいは、ルームデッキフィールド２５の位置はそのままで、ルームデッキフィールド２５の下方に（例えば、もどるボタン４３および挑戦するボタン４４に重畳して）サブデッキフィールド３５が表示されてもよい。サブデッキまたはサブデッキフィールド３５の表示態様は、これらに限定されない。折畳みボタン４６がタップされると、ルームデッキフィールド２５の位置が変更され（元に戻され）てよい。

次いでステップＳ１０６において、ユーザ端末１００は、操作受付部１１３により、入替え操作（ユーザの第２操作）を受け付けたか否かを判定する。入替え操作は、第１実施形態と同様、表示されているデッキのカードの入替えを要求する操作であり、例えばドラッグアンドドロップ操作である。ここでは入替え操作は、ユーザ端末１００のユーザのメインデッキとサブデッキとの間でのみ許容されるよう設定される。例えば、操作受付部１１３は、サブデッキフィールド３５のいずれかの枠からメインデッキフィールド２６のいずれかの枠へのドラッグアンドドロップ操作が検知されたこと、またはメインデッキフィールド２６のいずれかの枠からサブデッキフィールド３５のいずれかの枠へのドラッグアンドドロップ操作が検知されたことを、入替え操作を受け付けたと判定する。第１実施形態と同様に、サブデッキフィールド３５のいずれかの枠がタップされ、その後一定時間内にメインデッキフィールド２６のいずれかの枠がタップされるタップ操作が検知されたこと、またはその逆の順序でタップ操作が検知されたことを、入替え操作を受け付けたと判定してもよい。入替え操作は他のコマンドで入力されてもよい。入替え操作を受け付けたと判定される場合（ＹＥＳ）、ステップＳ１０７に進み、入替え操作を受け付けることなく例えば一定時間が経過した場合（ＮＯ）、ステップＳ１０９に進む。

ステップＳ１０７において、表示制御部１１４は、操作受付部１１３が受け付けた入替え操作にしたがって、第１実施形態と同様に、入替え後のゲーム画像を表示させる処理を行う。

ステップＳ１０８において、ユーザ端末１００は、入替え後のメインデッキ情報をサーバ２００に送信する。サーバ２００は、例えばホスト（１Ｐ）のメインデッキの内容を変更したルームデッキ情報を含む共有データを生成し、他の協力プレイヤー（２Ｐおよび３Ｐ）のユーザ端末１００に送信する。共有データを受信したユーザ端末１００は、共有データに基づいてルームデッキフィールド２５の表示を変更する。共有データは、ホストのユーザ端末１００にも送信されてよい。ステップＳ１０７の表示処理は、サーバ２００から共有データを受信した後で実行されてもよい。共有データは、更新後のルームデッキに係る再計算された総ＨＰ値を含んでよい。総ＨＰ値は各ユーザ端末１００において再計算されてもよい。各ユーザ端末１００は、ルームデッキフィールド２５の表示とともに総ＨＰ情報４１の表示も変更する。

ここでは、各ユーザ端末１００には他の協力プレイヤーのサブデッキは表示されず、他の協力プレイヤーのメインデッキの入替えが行われた場合に、当該他の協力プレイヤーのメインデッキフィールド（２７または２８）の表示が更新される設定を例に挙げて説明した。この場合、例えば、ある協力プレイヤー（１Ｐ）のユーザ端末１００Ａにおいてサブデッキフィールド３５が展開されている場合、他の協力プレイヤー（２Ｐおよび３Ｐ）のユーザ端末１００Ｂおよび１００Ｃにおいて、１Ｐ用のメインデッキフィールド２６内に「編成中」等のインジケータが表示されるようにしてもよい。また、２Ｐまたは３Ｐのユーザ端末（１００Ｂまたは１００Ｃ）において編成が終了しデッキが確定された場合（各端末において挑戦するボタン４４が押された場合）、１Ｐのユーザ端末１００Ａにおける２Ｐまたは３Ｐのメインデッキフィールド（２７または２８）の表示態様を変更することとしてもよい。例えば、メインデッキフィールド２７または２８に重畳させて「確定」等のインジケータを表示させてもよいし、メインデッキフィールド２７または２８をグレーアウトの表示としてもよい。

ステップＳ１０９において、操作受付部１１３は、サブデッキ表示終了を要求する操作、例えば折畳みボタン４６をタップする操作等を受け付けたか否かを判定する。サブデッキ表示終了を要求する操作が検知された場合（ＹＥＳ）、ステップＳ１１０に進み、一定時間検知されなければ（ＮＯ）、ステップＳ１０６に戻り、引き続き入替え操作の有無を判定する。

ステップＳ１１０において、表示制御部１１４は、サブデッキ表示を消す（サブデッキフィールド３５を折り畳む）処理を行う。この処理は、メインデッキフィールド２６またはルームデッキフィールド２５の位置を変更する（元に戻す）処理を含んでよい。

ステップＳ１１１において、操作受付部１１３は、デッキ表示終了を要求する操作、例えば、もどるボタン４３または挑戦するボタン４４をタップする操作を受け付けたか否かを判定する。デッキ表示終了を要求する操作が検知された場合（ＹＥＳ）、制御部１１０は、処理を終了し、検知された操作に応じたゲーム画像表示を実行する。例えば、もどるボタン４３がタップされた場合には、ルーム参加をキャンセルまたは保留し、直前のゲーム画像表示に戻る。挑戦するボタン４４がタップされた場合には、全協力プレイヤーの同意後、ルームデッキフィールド２５に表示されているルームデッキのカードを用いる協力プレイのゲーム画像に遷移する。ある協力プレイヤー（例えば３Ｐ）のユーザ端末１００Ｃにおいて挑戦するボタン４４がタップされた場合、他の協力プレイヤー（１Ｐおよび２Ｐ）のユーザ端末１００Ａおよび１００Ｂにおいて、３Ｐ用のメインデッキフィールド２８内に「準備完了」等のインジケータが表示されるようにしてもよい。なお、デッキ表示に制限時間を設定し、制限時間の経過後にデッキ編成を確定させることとしてもよい。

第２実施形態に係るユーザ端末１００の情報処理動作は、第１実施形態の第１実施例に関して説明したのと同様に、サブデッキフィールドの展開まで（図１８のステップＳ１０５まで）で終了されてもよい。
なお、以上で説明した情報処理動作は、ユーザ端末１００がサーバ２００に参加要求を送信するゲスト端末である場合にも同様に適用可能である。

（３）効果
上述したように、第２実施形態では、デッキを使用する協力プレイとしてのゲームプレイの前に、ゲームで使用されるメインデッキと、メインデッキに含まれるカードの入替え候補のカードを含むサブデッキと、をユーザが容易に確認できるようにした。ユーザは、ゲームプレイ前に、入替え候補のカードを確認し、入替えの要否を判断することができる。またユーザは、カードの入替えを望む場合、わざわざデッキ編成パートに戻ることなく、簡易な操作でカードの入替えを行うことができる。

特に第２実施形態では、複数の協力プレイヤーがカードを出し合って１つのデッキを構築するゲームにおいて、ユーザが他の協力プレイヤーのカードを確認しながら、自身のメインデッキおよびサブデッキを容易に確認可能とした。ユーザは、協力プレイ確認画面のまま、ルームを離れることなくカードの入替えを行うことができる。これは、ユーザの利便性を大きく向上させる。またユーザから受け付ける操作が少ないのでユーザ端末１００の制御部１１０による処理を高速化することができる。同様に、ゲームパート遷移の必要がないので、ユーザ端末１００およびサーバ２００の処理負荷を軽減することができる。デッキ編成のためにルームへの入退室を繰り返す必要がないことから、ユーザ端末１００とサーバ２００との間、またはユーザ端末１００と他のユーザ端末１００との間の通信量を抑制することができる。第１実施形態と同様、サブデッキフィールド３５をメインデッキフィールド２６（またはルームデッキフィールド２５）の近くに表示させることで、ユーザがデッキ編成を容易に確認することができ、メインデッキフィールド２６（またはルームデッキフィールド２５）の位置を変更してサブデッキフィールド３５を表示させることで、ユーザは視線移動せずにサブデッキを確認することができる。

第２実施形態では、協力プレイ用デッキとして保存されたデッキの中から、協力プレイの人数やカード数等の制約に応じて、実際に協力プレイで使用されるカードが各ユーザのメインデッキとして抽出されるというゲーム設定を例に挙げて説明した。このようなゲーム設定例は、協力プレイ用のカード候補をある程度絞ったうえでのデッキ編成を容易にし、ゲームの興趣性を高める。カードの入替えを行うとただちに他の協力プレイヤーにも通知されるようにすれば、各プレイヤーは、他の協力プレイヤーの変更後のデッキを見てただちに戦略を練ることができる。

ただし、第２実施形態はこのようなゲーム設定に限定されない。例えば、第１実施形態と同様に、ユーザが協力プレイ用のメインデッキと、協力プレイ用のサブデッキと、をあらかじめ保存できるようにしてもよい。協力プレイ用のメインデッキおよびサブデッキは、例えば、１枠、２枠、または３枠など、少数のカードを含むように設定されてよい。あるいは、第１実施形態でも述べたように、展開ボタン４５がタップされるたびに、デッキ管理部１１５が所持カード管理テーブル１２３２からカードを抽出し、レコメンドデッキとして表示するようにしてもよい。

第１実施形態および第２実施形態によれば、ゲームで使用されるデッキ編成を容易にする技術が提供される。

［他の実施形態］
なお、この発明は上記実施形態に限定されるものではない。
例えば、クエストプレイまたは協力プレイに使用されるデッキには、変更不可の固定カードまたは固定枠が含まれてよい。このような制約を設けることでゲームの戦略性を高めることができる。またメインデッキフィールドおよびサブデッキフィールドは、カードを含まない空白表示の枠を含んでもよい。

サブデッキの表示は、上述したような展開ボタンのタップに限られない。例えば、ゲーム画像に対するタップ操作、ダブルタップ操作、スワイプ操作、フリック操作、またはピンチアウト操作、等によって、サブデッキフィールドが展開されてもよい。同様に、サブデッキの表示を消すのは、折畳みボタンのタップに限られず、ゲーム画像に対するタップ操作、ダブルタップ操作、スワイプ操作、フリック操作、またはピンチイン操作、等によって、サブデッキフィールドが折り畳まれてもよい。

デッキ編成は、パーティ編成と読み替えられてもよい。カードは、キャラクタと読み替えられてもよい。クイズに正解した場合にデッキに含まれるカードから発動されるアクションは、攻撃に限られず、ダメージを受けて減少したＨＰ値の回復や、敵からのダメージを回避するバリア効果等の特殊技など、ゲーム内キャラクタが取り得るあらゆるアクションを含んでよい。カードには、デッキ内の他のカードと相互作用して、当該カードが単独で使用されるときとは異なる効果を発動できる設定がなされてもよい。

第１実施形態で説明したサブデッキの設定が可能なクエスト、または第２実施形態で説明した協力プレイ用のクエストは、いつでもプレイ可能な常駐クエストおよび期間限定でプレイ可能なイベントクエストを含んでよい。例えば、敵キャラクタとしてドラゴンが設定されたクエストは、半年に１回だけ、毎月１日だけ、または毎週日曜日の２１時～２２時など、期間限定で繰返し出現するようなイベントクエストであってよい。このような場合、ユーザは、対ドラゴン用に戦略を練った特別なデッキを編成し、常駐クエスト用のデッキとは別のサブデッキまたは協力プレイ用デッキとして保存し、プレイ可能なときに読み出させることができる。

サーバ２００およびユーザ端末１００の構成は、実施形態に係るゲームプログラムを実現可能な他の構成に置き換えられてもよい。サーバ２００の構成およびユーザ端末１００の構成は、省略され、複数の装置に分散配置され、類似の構成に置き換えられてもよい。サーバ２００およびユーザ端末１００の各機能部は、回路を用いることで実現されてもよい。回路は、特定の機能を実現する専用回路であってもよいし、プロセッサのような汎用回路であってもよい。

さらに、フローチャートを用いて説明した処理の流れは、説明した手順に限定されるものではなく、いくつかのステップの順序が入れ替えられてもよいし、いくつかのステップが同時並行で実施されてもよい。また、以上で説明した一連の処理は、時間的に連続して実行される必要はなく、各ステップは任意のタイミングで実行されてもよい。

上記各実施形態の処理の少なくとも一部は、例えば汎用のコンピュータに搭載されたプロセッサを基本ハードウェアとして用いることでも実現可能である。上記処理を実現するプログラムは、コンピュータで読み取り可能な記録媒体に格納して提供されてもよい。プログラムは、インストール可能な形式のファイルまたは実行可能な形式のファイルとして記録媒体に記憶される。記録媒体としては、磁気ディスク、光ディスク（ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＤＶＤ等）、光磁気ディスク（ＭＯ等）、半導体メモリ等である。記録媒体は、プログラムを記憶でき、かつ、コンピュータが読み取り可能であれば、何れであってもよい。また、上記処理を実現するプログラムを、インターネット等のネットワークに接続されたコンピュータ（サーバ）上に格納し、ネットワーク経由でコンピュータ（クライアント）にダウンロードさせてもよい。

なお、この発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の発明が含まれており、開示される複数の構成要件から選択された組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、課題が解決でき、効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。

１…ゲームシステム、１００…ユーザ端末、１１０…制御部、１１１…ゲーム進行部、１１２…オブジェクト制御部、１１３…操作受付部、１１４…表示制御部、１１５…デッキ管理部、１１６…協力プレイ管理部、１２０…記憶部、１２１…ゲームプログラム記憶部、１２２…ゲーム情報記憶部、１２３…デッキ情報記憶部、１２３１…デッキ管理テーブル、１２３２…所持カード管理テーブル、１２３３…クエスト管理テーブル、１２３４…協力プレイ用デッキ管理テーブル、２００…サーバ、２１１…受信制御部、２１２…送信制御部、２１３…ゲーム進行部、２２０…記憶部、２２１…ゲームプログラム記憶部、２２２…ゲーム情報記憶部、２２３…ユーザ情報記憶部、１００１…プロセッサ、１００２…メモリ、１００３…ストレージ、１００４…センサ、１００５…通信インタフェース、１００６…入出力インタフェース、１００７…タッチスクリーン、１００８…バス、１０７１…入力部、１０７２…表示部、２００１…プロセッサ、２００２…メモリ、２００３…ストレージ、２００４…通信インタフェース、２００５…入出力インタフェース、２００６…バス。

Claims (7)

1. ゲームで使用される複数のカードを含むように編成されたメインデッキを、ゲーム画像の第１範囲に表示させることと、
   ユーザの第１操作に応答して、前記メインデッキとは異なるサブデッキを、前記ゲーム画像の第２範囲に表示させることと、
   をコンピュータに実行させるプログラム。
2. 前記サブデッキを表示させることは、前記ゲーム画像における前記第１範囲の位置を変更することによって前記サブデッキを表示させることを含む、請求項１に記載のプログラム。
3. 前記メインデッキを表示させることと、前記サブデッキを表示させることと、が、前記メインデッキを編成するゲームパートとは異なるゲームパートで実行される、
   請求項１または請求項２に記載のプログラム。
4. 前記ユーザの第２操作に応答して、前記メインデッキに含まれるカードと、前記サブデッキに含まれるカードと、を入れ替えること
   をコンピュータにさらに実行させる、請求項１乃至３のいずれか一項に記載のプログラム。
5. 前記メインデッキを表示させることが、複数のユーザの各々のデッキから選択されたカードを、前記第１範囲のうち前記複数のユーザの各々のための表示範囲に表示させることを含み、
   前記サブデッキを表示させることが、前記複数のユーザのうち第１ユーザからの前記第１操作に応答して、当該第１ユーザのデッキに含まれるカードのうち、前記第１ユーザのための前記表示範囲に表示されていないカードを、前記第２範囲に表示させることを含む、
   請求項１乃至４のいずれか一項に記載のプログラム。
6. コンピュータが実行する情報処理方法であって、
   ゲームで使用される複数のカードを含むように編成されたメインデッキを、ゲーム画像の第１範囲に表示させることと、
   ユーザの操作に応答して、前記メインデッキとは異なるサブデッキを、前記ゲーム画像の第２範囲に表示させることと、
   を含む情報処理方法。
7. ゲームで使用される複数のカードを含むように編成されたメインデッキを、ゲーム画像の第１範囲に表示させる表示制御部と、
   ユーザの操作に応答して、前記メインデッキとは異なるサブデッキを、前記ゲーム画像の第２範囲に表示させる表示切替部と、
   を備える情報処理装置。
   

Images