IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社コロプラの特許一覧

特開2022-180021プログラム、情報処理方法および情報処理装置
<>
  • 特開-プログラム、情報処理方法および情報処理装置 図1
  • 特開-プログラム、情報処理方法および情報処理装置 図2
  • 特開-プログラム、情報処理方法および情報処理装置 図3
  • 特開-プログラム、情報処理方法および情報処理装置 図4
  • 特開-プログラム、情報処理方法および情報処理装置 図5
  • 特開-プログラム、情報処理方法および情報処理装置 図6
  • 特開-プログラム、情報処理方法および情報処理装置 図7
  • 特開-プログラム、情報処理方法および情報処理装置 図8
  • 特開-プログラム、情報処理方法および情報処理装置 図9
  • 特開-プログラム、情報処理方法および情報処理装置 図10
  • 特開-プログラム、情報処理方法および情報処理装置 図11
  • 特開-プログラム、情報処理方法および情報処理装置 図12
  • 特開-プログラム、情報処理方法および情報処理装置 図13
  • 特開-プログラム、情報処理方法および情報処理装置 図14
  • 特開-プログラム、情報処理方法および情報処理装置 図15
  • 特開-プログラム、情報処理方法および情報処理装置 図16
  • 特開-プログラム、情報処理方法および情報処理装置 図17
  • 特開-プログラム、情報処理方法および情報処理装置 図18
  • 特開-プログラム、情報処理方法および情報処理装置 図19
  • 特開-プログラム、情報処理方法および情報処理装置 図20
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022180021
(43)【公開日】2022-12-06
(54)【発明の名称】プログラム、情報処理方法および情報処理装置
(51)【国際特許分類】
   A63F 13/5375 20140101AFI20221129BHJP
   A63F 13/80 20140101ALI20221129BHJP
   A63F 13/533 20140101ALI20221129BHJP
【FI】
A63F13/5375
A63F13/80 B
A63F13/533
【審査請求】未請求
【請求項の数】7
【出願形態】OL
(21)【出願番号】P 2021086900
(22)【出願日】2021-05-24
(71)【出願人】
【識別番号】509070463
【氏名又は名称】株式会社コロプラ
(74)【代理人】
【識別番号】100108855
【弁理士】
【氏名又は名称】蔵田 昌俊
(74)【代理人】
【識別番号】100103034
【弁理士】
【氏名又は名称】野河 信久
(74)【代理人】
【識別番号】100179062
【弁理士】
【氏名又は名称】井上 正
(74)【代理人】
【識別番号】100153051
【弁理士】
【氏名又は名称】河野 直樹
(74)【代理人】
【識別番号】100199565
【弁理士】
【氏名又は名称】飯野 茂
(74)【代理人】
【識別番号】100162570
【弁理士】
【氏名又は名称】金子 早苗
(72)【発明者】
【氏名】山崎 徹
(72)【発明者】
【氏名】森 耕平
(57)【要約】
【課題】 ゲームで使用されるデッキの編成を容易にする技術を提供する。
【解決手段】 実施形態によれば、コンピュータによって実行されるプログラムにおいて、ゲームで使用される複数のカードを含むように編成されたメインデッキをゲーム画像の第1範囲に表示させることと、ユーザの第1操作に応答して、メインデッキとは異なるサブデッキをゲーム画像の第2範囲に表示させることと、をコンピュータに実行させるようにした。
【選択図】図5
【特許請求の範囲】
【請求項1】
ゲームで使用される複数のカードを含むように編成されたメインデッキを、ゲーム画像の第1範囲に表示させることと、
ユーザの第1操作に応答して、前記メインデッキとは異なるサブデッキを、前記ゲーム画像の第2範囲に表示させることと、
をコンピュータに実行させるプログラム。
【請求項2】
前記サブデッキを表示させることは、前記ゲーム画像における前記第1範囲の位置を変更することによって前記サブデッキを表示させることを含む、請求項1に記載のプログラム。
【請求項3】
前記メインデッキを表示させることと、前記サブデッキを表示させることと、が、前記メインデッキを編成するゲームパートとは異なるゲームパートで実行される、
請求項1または請求項2に記載のプログラム。
【請求項4】
前記ユーザの第2操作に応答して、前記メインデッキに含まれるカードと、前記サブデッキに含まれるカードと、を入れ替えること
をコンピュータにさらに実行させる、請求項1乃至3のいずれか一項に記載のプログラム。
【請求項5】
前記メインデッキを表示させることが、複数のユーザの各々のデッキから選択されたカードを、前記第1範囲のうち前記複数のユーザの各々のための表示範囲に表示させることを含み、
前記サブデッキを表示させることが、前記複数のユーザのうち第1ユーザからの前記第1操作に応答して、当該第1ユーザのデッキに含まれるカードのうち、前記第1ユーザのための前記表示範囲に表示されていないカードを、前記第2範囲に表示させることを含む、
請求項1乃至4のいずれか一項に記載のプログラム。
【請求項6】
コンピュータが実行する情報処理方法であって、
ゲームで使用される複数のカードを含むように編成されたメインデッキを、ゲーム画像の第1範囲に表示させることと、
ユーザの操作に応答して、前記メインデッキとは異なるサブデッキを、前記ゲーム画像の第2範囲に表示させることと、
を含む情報処理方法。
【請求項7】
ゲームで使用される複数のカードを含むように編成されたメインデッキを、ゲーム画像の第1範囲に表示させる表示制御部と、
ユーザの操作に応答して、前記メインデッキとは異なるサブデッキを、前記ゲーム画像の第2範囲に表示させる表示切替部と、
を備える情報処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、プログラム、情報処理方法および情報処理装置に関する。
【背景技術】
【0002】
1または複数のカードを含むカードセットを使用するゲームが知られている。カードセットは「デッキ」とも呼ばれる。このようなゲームでは、例えば、敵キャラクタとの戦闘において、デッキに含まれるカードの効果を発動させることによって敵キャラクタにダメージを与える。ゲームのプレイヤー(以下、「ユーザ」とも言う。)は、各カードに設定された効果の属性またはパラメータ等を考慮して、1または複数のカードを組み合わせ、デッキを編成する。
【0003】
プレイヤーが保有するキャラクタから1以上のキャラクタを選択してグループを編成するゲームにおいて、敵キャラクタに勝てる可能性の高い、おすすめ編成を提示する装置が提案されている(例えば、特許文献1参照)。また、ユーザのタッチ操作に応じて表示を変化させる技術も知られている(例えば、特許文献2参照)。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2018-171181号公報
【特許文献2】特表2012-520521号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
デッキ編成は、ゲームを有利に進められるかどうかに関わる戦略的な要素である。しかし、敵キャラクタまたはクエスト等に応じてデッキを編成するのは依然として手間がかかる。
【0006】
この発明の一態様は、デッキ編成を容易にする技術を提供する。
【課題を解決するための手段】
【0007】
上記課題を解決するためにこの発明の一態様は、コンピュータによって実行されるプログラムにおいて、ゲームで使用される複数のカードを含むように編成されたメインデッキをゲーム画像の第1範囲に表示させることと、ユーザの第1操作に応答して、メインデッキとは異なるサブデッキをゲーム画像の第2範囲に表示させることと、をコンピュータに実行させるようにした。
【発明の効果】
【0008】
一態様に係るプログラムによれば、ゲームで使用されるメインデッキがゲーム画像の第1範囲に表示され、ユーザの第1操作を受け付けた場合には、さらにメインデッキとは異なるサブデッキがゲーム画像の第2範囲に表示される。これにより、ゲームで使用されるメインデッキだけでなく、メインデッキとは異なるサブデッキを併せて表示させ、ユーザが容易にデッキ編成を行えるようにすることができる。
【0009】
この発明の一態様によれば、デッキ編成を容易にする技術が提供される。
【図面の簡単な説明】
【0010】
図1図1は、第1実施形態に係るゲームプログラムに関連するゲームシステムの全体構成の一例を示す図である。
図2図2は、第1実施形態に係るサーバの機能構成の一例を示す図である。
図3図3は、第1実施形態に係るユーザ端末の機能構成の一例を示す図である。
図4図4は、第1実施形態に係るゲームプログラムによって実現されるゲームの構成を示す略図である。
図5図5は、第1実施形態に係るユーザ端末の情報処理動作の第1実施例を示すフローチャートである。
図6図6は、図5に示した情報処理動作のうちメインデッキ表示処理の詳細を示すフローチャートである。
図7図7は、図5に示した情報処理動作のうちサブデッキ表示処理の詳細を示すフローチャートである。
図8図8は、第1実施形態に係るデッキ管理テーブルの一例を示す図である。
図9図9は、第1実施形態に係る所持カード管理テーブルの一例を示す図である。
図10図10は、第1実施形態に係るクエスト管理テーブルの一例を示す図である。
図11図11は、第1実施形態のデッキ表示に係るゲーム画像の第1の例を示す図である。
図12図12は、第1実施形態に係るユーザ端末の情報処理動作の第2実施例を示すフローチャートである。
図13図13は、第1実施形態に係るカード入替え処理を説明するゲーム画像の一例を示す図である。
図14図14は、第1実施形態のデッキ表示に係るゲーム画像の第2の例を示す図である。
図15図15は、第1実施形態のデッキ表示に係るゲーム画像の第3の例を示す図である。
図16図16は、第2実施形態に係るユーザ端末の機能構成の一例を示す図である。
図17図17は、第2実施形態に係るゲームプログラムによって実現されるゲームの構成を示す略図である。
図18図18は、第2実施形態に係るユーザ端末の情報処理動作の一例を示すフローチャートである。
図19図19は、第2実施形態に係る協力プレイ用デッキ管理テーブルの一例を示す図である。
図20図20は、第2実施形態のデッキ表示に係るゲーム画像の一例を示す図である。
【発明を実施するための形態】
【0011】
以下、図面を参照してこの発明に係わる実施形態を説明する。なお、以降、説明済みの要素と同一または類似の要素には同一または類似の符号を付し、重複する説明については基本的に省略する。例えば、複数の同一または類似の要素が存在する場合に、各要素を区別せずに説明するために共通の符号を用いることがあるし、各要素を区別して説明するために当該共通の符号に加えて枝番号を用いることもある。
【0012】
[第1実施形態]
第1実施形態に係るプログラムは、ユーザによって使用される端末装置(以下、「ユーザ端末」と言う。)上でゲームを実現させるためのプログラムである。以下では、第1実施形態に係るプログラムを、一般的なコンピュータの機能を実現させるためのプログラムと区別して、ゲームプログラムと呼ぶ。
【0013】
ゲームプログラムは、1台のユーザ端末でローカルにゲームを実現させるゲームプログラム、ユーザ端末とサーバに協働してゲームを実現させるゲームプログラム、(サーバ経由でまたはサーバを介さずに)複数のユーザ端末に協働してゲームを実現させるゲームプログラム等であり得る。第1実施形態では、一例として、サーバがゲームプログラムを包括的に管理し、ユーザ端末からの要求に応答してゲームプログラムおよび関連データ等を送信し、実際のゲーム進行は主にユーザ端末において実現されるゲームシステムについて説明する。
【0014】
(1)構成
(1-1)ゲームシステム
図1は、ゲームプログラムに関連するゲームシステム1の全体構成の一例を示す。
ゲームシステム1は、複数のユーザ端末100A,100B,100C・・・(以下、個々の区別をせず総称的に「ユーザ端末100」とも呼ぶ)と、サーバ200と、を含む。各ユーザ端末100は、サーバ200との間でネットワークNWを介して通信可能である。サーバ200には、任意の数のユーザ端末100が接続可能であるが、簡単のために1つのユーザ端末100についてのみ詳細な構成を図示し説明する。
【0015】
ネットワークNWは、例えばインターネットであり、LAN(Local Area Network)、WAN(Wide Area Network)、移動通信網、有線電話網、FTTH(Fiber To The Home)、CATV(Cable Television)網等のアクセス網を含み得る。
【0016】
ユーザ端末100は、第1実施形態に係る情報処理装置の一例であり、ゲームプレイをするユーザによって使用される端末である。ユーザ端末100は、ゲームプログラムを実行することによりゲームを実現し、ゲーム進行に応じたゲーム画像を表示することによりゲーム画面を実現する。ゲーム画像は、ゲーム空間を描画した画像を含み得る。ゲーム空間を描画した画像は、ゲーム空間に配置された複数のオブジェクトの画像を含み得る。ゲーム画像は、静止画像または動画像を含む。ゲーム画像はまたUI(User Interface)オブジェクトの画像を含み得る。ユーザ端末100は、例えば、スマートフォン、タブレット端末、ノート型パーソナルコンピュータ等の携帯端末である。ユーザ端末100は、デスクトップ型パーソナルコンピュータのような据置型コンピュータであってもよい。ユーザ端末100はまた、ゲームプレイに適した専用のゲーム端末であってもよい。以下では、一例として、ユーザ端末100が、タッチスクリーンを備えるスマートフォンであるものとして説明する。
【0017】
サーバ200は、例えばゲーム開発者等によって運営および管理される装置である。サーバ200は、ゲームプログラムおよびユーザ情報を包括的に管理し、ユーザ端末100におけるゲームの進行を支援する。サーバ200は、ワークステーションやパーソナルコンピュータ等の汎用コンピュータであってよい。例えばサーバ200は、ネットワークNWを介してユーザ端末100からユーザ情報または種々の要求を受け付け、要求に応答してネットワークNWを介してユーザ端末100にゲームプログラムや関連データを送信する。サーバ200は、同時に複数のユーザ端末100との間で情報の送受信が可能であり、複数のユーザ端末100におけるゲームの進行を並行して支援し得る。
【0018】
(1-2)ハードウェア構成
(1-2-1)サーバ
図1に示すように、サーバ200は、ハードウェアとして、プロセッサ2001と、メモリ2002と、ストレージ2003と、通信インタフェース(通信I/F)2004と、入出力インタフェース(入出力I/F)2005と、を備え、これらがバス2006を介して互いに電気的に接続される。
【0019】
プロセッサ2001は、サーバ200全体の動作を制御する。プロセッサ2001は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、GPU(Graphics Processing Unit)等の汎用プロセッサを含む。プロセッサ2001は、汎用プロセッサに限らず、ASIC(Application Specific Integrated Circuit)またはFPGA(Field-Programmable Gate Array)等の専用プロセッサであってもよい。
メモリ2002は、主記憶装置であり、ROM(Read Only Memory)およびRAM(Random Access Memory)等を含む。
ストレージ2003は、補助記憶装置であり、ハードディスクドライブ(HDD)やソリッドステートドライブ(SSD:Solid State Drive)等の不揮発性記憶装置を含む。ストレージ2003は、プロセッサ2001により実行されるプログラムや、プログラムの実行に必要な設定データ等を記憶する。プログラムの一部はROMに記憶されてもよい。
【0020】
プロセッサ2001は、ストレージ2003からプログラムを読み出してメモリ2002に展開し、展開したプログラムを解釈および実行することによって、後述する処理機能を実現し得る。
【0021】
通信インタフェース(通信I/F)2004は、ネットワークNWを介してユーザ端末100等の外部装置と通信するためのモジュールであり、送受信のための信号処理回路、光コネクタ等を含む。通信インタフェース2004は、例えば光通信モジュールを含んでもよい。
【0022】
入出力インタフェース(入出力I/F)2005は、キーボードやマウス等の入力装置を通じてオペレータが入力した操作データを取り込むとともに、出力データを液晶または有機EL(Electro Luminescence)ディスプレイやスピーカ等の出力装置に出力する。
【0023】
(1-2-2)ユーザ端末
図1に示すように、ユーザ端末100は、ハードウェアとして、プロセッサ1001と、メモリ1002と、ストレージ1003と、センサ1004と、通信インタフェース(通信I/F)1005と、入出力インタフェース(入出力I/F)1006と、タッチスクリーン1007と、を備え、これらがバス1008を介して互いに電気的に接続される。
【0024】
プロセッサ1001は、ユーザ端末100の全体の動作を制御する。プロセッサ1001は、例えば、CPU、MPU、GPU等の汎用プロセッサを含む。プロセッサ1001もまた、汎用プロセッサに限らず、ASICまたはFPGA等の専用プロセッサであってもよい。
メモリ1002は、主記憶装置であり、ROMおよびRAM等を含む。
ストレージ1003は、補助記憶装置であり、内蔵または外付けの半導体メモリ(例えばフラッシュメモリ)等を含む。ストレージ1003は、プロセッサ1001により実行されるプログラムや、プログラムの実行に必要な設定データ等を記憶する。プログラムの一部は、ROMに記憶されてもよい。
プロセッサ1001は、ストレージ1003からプログラムを読み出してメモリ1002に展開し、展開したプログラムを解釈および実行することによって、後述する処理機能を実現し得る。
【0025】
センサ1004は、例えば、イメージセンサ、サウンドセンサ、加速度センサ、角速度センサ、地磁気センサ、GPSセンサ、近接センサ、環境光センサ等である。センサ1004は、感知された種々の情報を電気信号に変換し、出力する。
【0026】
通信インタフェース(通信I/F)1005は、ネットワークNWを介してサーバ200等の外部装置と通信するためのモジュールであり、送受信のための信号処理回路、アンテナ、LAN端子等を含む。通信インタフェース1005は、移動通信用のモジュール、無線/有線LAN用のモジュール、近距離無線通信用のモジュール等を含み得る。
【0027】
入出力インタフェース(入出力I/F)1006は、外部装置から入力データを取り込むとともに、出力データを外部装置に出力する。入出力インタフェース1006は、例えば、ユーザ端末100の物理ボタンや、ユーザ端末100に内蔵されたスピーカ、USB(Universal Serial Bus)ポート等を含み得る。
【0028】
タッチスクリーン1007は、入力部1071と表示部1072とを備え、ユーザの入力操作を受け付けるとともに、ユーザに種々の画像を表示する機能を有する。
【0029】
入力部1071は、例えば静電容量式や抵抗膜式のタッチパネルである。入力部1071は、ユーザが指やタッチペン(スタイラスペン)で触れた接触位置を検知し、接触位置の座標情報を生成する。
【0030】
表示部1072は、例えば液晶ディスプレイや有機ELディスプレイであり、表示データに基づく種々の画像を表示する。表示部1072は、ゲーム画像を表示することによってゲーム画面を実現する。
【0031】
ユーザ端末100は、入出力インタフェース1006を介して接続されるキーボード、マウス、コントローラ等の外部入力装置からユーザの操作を受け付けることもできる。ユーザ端末100は、入出力インタフェース1006を介して接続されるメモリカード等の外部記憶装置からゲームプログラムおよび関連データを取得してもよい。ユーザ端末100は、入出力インタフェース1006を介して接続されるディスプレイやスピーカ等の外部出力装置に表示情報を出力することもできる。ユーザ端末100は、入出力インタフェース1006を介して接続されるメモリカード等の外部記憶装置をストレージ1003として使用してもよい。ユーザ端末100はまた、センサ1004からの信号をユーザの入力操作として受け付けてもよい。
【0032】
(1-3)機能構成
(1-3-1)サーバ
図2は、第1実施形態に係るサーバ200の機能構成の一例を示す。なお、一般的なコンピュータの機能構成およびゲームの実現に必要な公知の構成については、図示および説明を省略する。
【0033】
サーバ200は、各ユーザ端末100と通信し、ユーザ端末100におけるゲームの進行を支援する機能を有する。例えば、サーバ200は、各ユーザ端末100からの要求に応答して、各ユーザ端末100にゲームプログラムや、ゲームプログラムの実行に必要な関連データ等を送信する機能を有する。サーバ200は、制御部210と、記憶部220と、を備える。
【0034】
記憶部220は、主にストレージ2003により実現される。記憶部220は、ゲームプログラム記憶部221と、ゲーム情報記憶部222と、ユーザ情報記憶部223と、を備える。
【0035】
ゲームプログラム記憶部221は、ゲームプログラムを記憶する。
ゲーム情報記憶部222は、ゲームプログラムを実行する際に参照される種々のゲーム情報を記憶する。
ユーザ情報記憶部223は、各ユーザ端末100に関連付けられるユーザに関する情報を記憶する。ユーザ情報記憶部223は、例えば、ユーザのアカウント情報、ユーザのニックネーム、ユーザの所持カード、またはユーザのゲーム進行状況等の情報を記憶する。
【0036】
制御部210は、主にプロセッサ2001およびメモリ2002により実現される。制御部210は、サーバ200全体の機能を制御する。制御部210は、ゲームプログラム記憶部221に記憶されたゲームプログラムを実行することにより、受信制御部211、送信制御部212、およびゲーム進行部213として機能し得る。
【0037】
受信制御部211は、各ユーザ端末100から、ユーザ情報、各ユーザ端末100におけるゲームの進行状況に関する情報、およびプログラムまたは関連データの送信要求等を受け付ける。
【0038】
送信制御部212は、各ユーザ端末100に、要求されたプログラムまたは関連データ、あるいは更新されたプログラム等を送信する。送信制御部212はまた、各ユーザ端末100にゲームの進行状況に関する情報の送信を要求し得る。
【0039】
ゲーム進行部213は、ゲームプログラムに記述されたコードに従ってゲーム情報記憶部222およびユーザ情報記憶部223に記憶された情報を参照し、各ユーザ端末100におけるゲームの進行状況を管理する。ゲーム進行部213はまた、各ユーザ端末100からの情報収集の要否や各ユーザ端末100へのデータ送信の要否を判定し得る。
【0040】
例えば、制御部210は、受信制御部211により、ユーザ端末100からゲームプログラムの送信要求を受け付け、ゲーム進行部213により、当該ユーザ端末100に送信すべきゲームプログラムと関連データを決定し、送信制御部212により、決定されたゲームプログラムおよび関連データをユーザ端末100に送信する。
【0041】
(1-3-2)ユーザ端末
図3は、第1実施形態に係るユーザ端末100の機能構成の一例を示す。なお、一般的なコンピュータの機能構成およびゲームの実現に必要な公知の構成については、図示および説明を省略する。
【0042】
ユーザ端末100は、制御部110と、記憶部120と、を備える。
記憶部120は、主にストレージ1003により実現される。記憶部120は、ゲームプログラム記憶部121と、ゲーム情報記憶部122と、デッキ情報記憶部123と、を備える。
【0043】
ゲームプログラム記憶部121は、ゲームプログラムを記憶する。
【0044】
ゲーム情報記憶部122は、ゲームプログラムを実行する際に参照される種々のゲーム情報を記憶する。ゲーム情報記憶部122はまた、ゲーム画像を表示させるための表示データを生成する際に参照される画像、音声、および音楽等の表示情報を記憶する。
【0045】
デッキ情報記憶部123は、デッキ管理テーブル1231、所持カード管理テーブル1232、およびクエスト管理テーブル1233を記憶する。デッキ管理テーブル1231は、デッキの内容を表す情報を記憶する。所持カード管理テーブル1232は、ユーザ端末100のユーザが所持するカードの情報を記憶する。クエスト管理テーブル1233は、デッキを使用してプレイ可能なクエストの情報を記憶する。
【0046】
制御部110は、主にプロセッサ1001およびメモリ1002により実現される。制御部110は、ユーザ端末100全体の機能を制御する。制御部110は、ゲームプログラム記憶部121に記憶されたゲームプログラムを実行することにより、ゲーム進行部111、オブジェクト制御部112、操作受付部113、表示制御部114、およびデッキ管理部115として機能し得る。
【0047】
ゲーム進行部111は、ゲームプログラムに記述されたコードに従って、ゲーム情報記憶部122に記憶されたゲーム情報を参照し、ゲーム空間にオブジェクトを配置してゲームを進行させる機能を有する。
【0048】
オブジェクト制御部112は、ゲーム空間に配置された種々のオブジェクトの動作またはステータスを制御する機能を有する。
【0049】
操作受付部113は、入力部1071を介して入力されたユーザの操作を受け付ける機能を有する。以下、「ユーザの操作」は、入力部1071を介して入力されたユーザの操作を指すものとする。ユーザの操作は、タップ操作、ドラッグアンドドロップ操作、スワイプ操作、ピンチイン操作、およびピンチアウト操作など、入力部1071を介した種々の種類の操作を含む。操作受付部113は、入力部1071による接触位置の検知に基づいて、ユーザの操作の開始を検知し得る。操作受付部113は、入力部1071による接触位置の検知から非検知への遷移に基づいて、ユーザの操作の終了を検知し得る。操作受付部113は、ユーザの操作の開始に対応する接触位置からユーザの操作の終了に対応する接触位置までの座標情報を入力部1071から連続的に取得する。操作受付部113によるユーザの操作の判別は、知られている方法で行われてよい。
【0050】
表示制御部114は、表示部1072にゲーム画像を表示させるための表示データを生成する機能を有する。表示制御部114は、ゲーム画像の第1範囲にメインデッキを表示させる表示制御部として機能する。表示制御部114はまた、ユーザの操作に応答して、ゲーム画像の第2範囲にサブデッキを表示させる表示切替部として機能する。
【0051】
デッキ管理部115は、デッキの情報を管理し、デッキの編成および保存を支援する機能を有する。デッキ管理部115はまた、表示制御部114と連携して、ゲーム画像におけるメインデッキおよびサブデッキの表示を生成する。
【0052】
(1-4)ゲームの構成
第1実施形態に係るゲームプログラムによって実現されるゲームは、1以上のカードを組み合わせて編成されたデッキを使用可能なゲームを含む。以下では、第1実施形態について、デッキを使用するクイズRPG(RPG:ロールプレイングゲーム)における適用例を用いて説明する。ただし、第1実施形態はクイズRPGに限定されず、デッキを使用可能な他の分類のゲームにも適用可能である。
【0053】
図4は、第1実施形態に係るゲームプログラムによって実現されるゲームの構成を示す略図である。ゲームは、複数のゲームパートで構成される。一例として、ゲームは、ホームパートと、デッキ編成パートと、クエストパートと、を含む。ホームパートは、ゲームの拠点となるゲームパートである。デッキ編成パートは、ゲーム開始前にユーザが所持するカードの中から1または複数のカードを組み合わせてデッキを編成可能なゲームパートである。クエストパートは、ユーザがデッキを用いてゲームプレイを行うことのできるゲームパートである。クエストパートは、それぞれに目標が設定された複数のクエスト(「ゲームステージ」等、類似の用語に読み替えられ得る)を含む。例えば、あるクエストの目標は、当該クエストに設定された敵キャラクタの討伐である。各クエストではクイズが出題され、ユーザはユーザ端末100を介して解答を入力する。クイズに正解すると、デッキに含まれるカードの効果として、敵キャラクタに対して攻撃等のアクションが発動される。各カードには、効果の属性またはパラメータが設定されており、ユーザは、戦闘を有利に進められるよう属性またはパラメータを考慮してデッキを編成する。
【0054】
ゲーム画像6は、ホームパートに係るゲーム画像の一例(略図)である。例えばゲーム画像6は、デッキ編成ボタン61と、クエストボタン62と、を含む。デッキ編成ボタン61は、デッキ編成パートへの遷移を要求する操作ボタンである。クエストボタン62は、クエストパートへの遷移を要求する操作ボタンである。操作ボタンは、ユーザによって選択されると所定の機能を発揮するように構成されたUIオブジェクトである。操作ボタンに代えて他のコマンドが使用されてもよい。
【0055】
例えば、デッキ編成ボタン61が選択されると、ホームパートからデッキ編成パートに遷移し、デッキ編成パートに係るゲーム画像7が表示される(P1)。ゲーム画像7は、デッキ編成パートに係るゲーム画像の一例である。ユーザは、デッキ編成パートにおいて、所持するカードの中から任意に選択したカードを組み合わせて1または複数のデッキを編成することができる。例えばゲーム画像7は、デッキ名71、デッキカード欄72、デッキ切替ボタン73、所持カード欄74、決定ボタン75、およびもどるボタン76を含む。デッキ名71は、編成中のデッキの識別情報(図示の例では「デッキ2」)を含む。デッキカード欄72は、編成中のデッキに含まれるカードを示す。デッキカード欄72には最大枠数が設定される。ユーザは、最大枠数以下の数のカードを各デッキに組み込むことができる。デッキ切替ボタン73は、編成対象のデッキを切り替え可能とする。例えば、左側のボタン73が選択されると、編成対象のデッキが「デッキ2」から「デッキ1」に切り替わり、右側のボタン73が選択されると、編成対象のデッキが「デッキ2」から「デッキ3」に切り替わる。所持カード欄74は、ユーザが所持するカードの一覧を示す。矢印DDは、デッキ編成操作の一例として、ユーザによるドラッグアンドドロップ操作を示す。ユーザは、ドラッグアンドドロップ操作DDにより、所持カード欄74のカードをデッキカード欄72に組み込む、または所持カード欄74のカードとデッキカード欄72のカードとを入れ替えることができる。決定ボタン75はデッキ編成を保存するためのボタンである。決定ボタン75が選択されると、デッキの内容がデッキ情報記憶部123に保存される。もどるボタン76は、前のゲーム画面にもどるためのボタンである。例えば、もどるボタン76が選択されると、デッキ編成の変更を保存せずに、デッキ編成パートからホームパートに遷移する(P2)。
【0056】
ゲーム画像6においてクエストボタン62が選択されると、ホームパートからクエストパートに遷移し、クエストパートに係るゲーム画像8が表示される(P3)。ゲーム画像8は、クエストパートの入口に対応するゲーム画像の一例である。クエストパートをプレイするために、ユーザは、まず、ゲームプレイしようとするクエストを選択し、クエストに設定された目標および使用されるデッキの内容を確認してから、実際のクエストプレイに進む。ここでは、「デッキの内容」は、デッキに含まれるカードの情報を含む。「デッキの内容」はまた、デッキにおけるカードの並び順の情報を含み得る。例えばゲーム画像8は、クエスト選択ボタン81と、もどるボタン82とを含む。クエスト選択ボタン81は、クエストの識別情報(図では、クエスト1、クエスト2、・・・)を含む。ユーザは、クエスト選択ボタン81のいずれかを選択することによって、ゲームプレイをするクエストを選択することができる。もどるボタン82は、前のゲーム画面に戻るためのボタンである。例えば、もどるボタン82が選択されると、クエストパートからホームパートに遷移する(P4)。
【0057】
ゲーム画像8においていずれかのクエスト選択ボタン81が選択された場合、例えばゲーム画像11のような確認画面が表示される(P5)。例えばゲーム画像11は、敵キャラ画像50、敵キャラ情報51、メインデッキフィールド20、もどるボタン43、および挑戦するボタン44を含む。敵キャラ画像50および敵キャラ情報51は、クエストに設定された敵キャラクタの画像および情報を示す。メインデッキフィールド20は、ゲームで使用されるデッキの内容を示す。挑戦するボタン44が選択されると、表示中のデッキを用いる選択したクエストでのゲームプレイが開始される。もどるボタン43が選択されると、ゲーム画像8に遷移する(P6)。ユーザは、ゲーム画像11のような確認画面において、これからプレイするクエストおよび使用されるデッキの最終確認を行うことができる。
【0058】
ゲーム画像11のようなゲームプレイ前の確認画面において、デッキの内容を変更したいと考える場合、ユーザは、この例では、ゲーム画像11から何らかの操作を経てゲーム画像7のようなデッキ編成用画面を表示させるか(P7)、またはゲーム画像11から、もどるボタン43、もどるボタン82、およびデッキ編成ボタン61という順に選択して、ゲーム画像7に切り替える必要がある。第1実施形態は、このようなゲームプレイ前の確認画面におけるデッキ編成を可能とする。
【0059】
(2)動作
次に、図3に示したユーザ端末100による情報処理動作例について説明する。第1実施形態では、主にユーザ端末100のユーザによるシングルプレイの状況を想定して説明する。なお、以降の動作の前提として、ユーザ端末100の制御部110および記憶部120の連携により、ゲームプログラムに記述されたコードに従ってゲームがいくらか進行されているものとする。
【0060】
(第1実施例)
第1実施例では、デッキを使用するゲームプレイの前に、ユーザの操作に応答して、ゲームで使用されるデッキ(後述する「メインデッキ」)に含まれるカードの入替え候補として「サブデッキ」を表示させる、デッキ表示動作について説明する。
【0061】
図5は、第1実施形態に係るユーザ端末100の情報処理動作の第1実施例を示すフローチャートである。
まずステップS1において、ユーザ端末100は、制御部110の制御の下、メインデッキ表示処理を実行する。この処理は、例えば、ユーザが所定のゲーム画面を介してゲームプレイしようとするクエストを選択したことをトリガとして実行される。ユーザ端末100の表示部1072は、選択されたクエストに関する情報および当該クエストで使用されるデッキに関する情報を表示する確認画面を提示する。第1実施形態では、あらかじめ保存されたデッキのうち、選択されたクエストで使用されるデッキ(または使用される予定のデッキ)を「メインデッキ」と呼ぶ。メインデッキは1または複数のカードを含む。ステップS1については図6を参照してさらに後述する。
【0062】
次いでステップS2において、ユーザ端末100は、操作受付部113により、サブデッキ表示を要求するユーザ操作(ユーザの第1操作)を受け付けたかどうかを監視し、当該ユーザ操作を受け付けた場合(YES)、ステップS3に進む。サブデッキ表示を要求するユーザ操作を受け付けなければ(NO)、処理を終了するか監視を継続する。サブデッキ表示を要求するユーザ操作は、例えば、所定のUIオブジェクトにより実現される操作ボタンをタップする操作である。なお、ここでは「操作ボタンをタップする」と言うとき、操作ボタンに関連付けられた機能の発動を要求する操作全般を意味する。「操作ボタンをタップする」は、操作ボタンにタッチする、操作ボタンを選択する、または操作ボタンを押す、等と読み替えられてよい。また、サブデッキ表示を要求するユーザ操作は、UIオブジェクトとしての操作ボタンに対する操作に限られず、同様の機能を要求するタッチ操作、物理ボタンの操作、またはその他のコマンドに置き換えられてもよい。
【0063】
ステップS3において、ユーザ端末100は、制御部110の制御の下、サブデッキ表示を要求するユーザ操作に応答してサブデッキ表示処理を実行する。「サブデッキ」は、メインデッキに含まれるカードの入替え候補である1または複数のカードを含む、メインデッキとは異なるデッキである。なお、本明細書で単に「デッキ」と言うとき、メインデッキおよびサブデッキの両方を含み得る。ステップS3については図7を参照してさらに後述する。
【0064】
図6は、図5のステップS1に示したメインデッキ表示処理の詳細を示す。
ステップS11において、デッキ管理部115は、メインデッキ情報を取得する。メインデッキ情報は、メインデッキに含まれるカードに関する情報を含む。例えばデッキ管理部115は、デッキ情報記憶部123に記憶されたデッキ管理テーブル1231および所持カード管理テーブル1232から必要な情報を読み出すことにより、メインデッキ情報を取得する。
【0065】
図8は、デッキ管理テーブル1231の一例を示す。デッキ管理テーブル1231は、デッキの内容を表す情報を記憶し、例えば、デッキID、メインデッキフラグ、サブデッキフラグ、および編成情報を含む。デッキIDは、保存されているデッキを識別可能な情報(図示の例では、「デッキ1」、「デッキ2」、・・・「デッキ21」・・・)を含む。メインデッキフラグは、メインデッキであるか否かを識別する。「1」はメインデッキであることを表し、「0」はメインデッキでないことを表す。サブデッキフラグは、サブデッキであるか否かを識別する。「1」はサブデッキであることを表し、「0」はサブデッキでないことを表す。サブデッキフラグは省略されてもよい。ここでは、デッキ1~デッキ20がメインデッキとして設定され、デッキ21~デッキX(Xは任意に設定されてよい)がサブデッキとして設定されている。メインデッキとして保存するかサブデッキとして保存するかはユーザが設定可能であってもよい。
【0066】
編成情報は、各デッキを編成するカードの情報を含む。カードの情報は、例えばカードを識別可能な情報(図示の例では、「カード1」、「カード2」・・・)を含む。各デッキには、最大枠数(カードの上限数)(図示の例では6)が設定される。カードの並び順は、枠情報(図示の例では、「第1枠」、「第2枠」・・・「第6枠」)により管理される。図示の例では、「デッキ1」は、第1枠に「カード1」、第2枠に「カード2」、第3枠に「カード3」、第4枠に「カード4」、第5枠に「カード5」、第6枠に「カード6」を含む。「デッキ2」は、第1枠に「カード11」、第2枠に「カード1」・・・を含む。デッキ1の第1枠「カード1」とデッキ2の第2枠「カード1」とは、同一のカードが重複して編成されたものであってよい。このような重複を許容しない設定であってもよい。さらに図示の例では、「デッキ21」は、第1枠に「カード21」、第2枠に「カード22」、第3枠に「カード23」・・・を含む。デッキ管理テーブル1231に保存されるデッキ(メインデッキまたはサブデッキ)は、ユーザによって編成されたデッキのみならず、サーバ200から配信されたデッキおよびゲームプログラムによって自動生成されたデッキを含んでよい。第1実施形態では、メインデッキは言わば「スターティングメンバー」、サブデッキは言わば「控え」または「補欠」の役割を有する。したがって、第1実施形態では、メインデッキに含まれるカードとサブデッキに含まれるカードとの重複を許容しない設定が採用される。ただし、そのような重複を許容する適用例を除外しようとするものではない。
【0067】
図9は、所持カード管理テーブル1232の一例を示す。ユーザは、ゲーム内で1以上のカードを所持する。ユーザが所持するカードは、ゲームの進行に伴って、発動可能な効果が変化し得る。またユーザが所持するカードの枚数は、ゲームの進行に伴って、増加または減少し得る。所持カード管理テーブル1232は、ユーザ端末100のユーザが所持するカードの情報を管理するもので、例えば、カードID、HP、画像ID、および攻撃力を含む。カードIDは、各カードを識別可能な情報(図示の例では、「カード1」、「カード2」、「カード3」・・・)を含む。HPは、各カードに設定されたHP(ヒットポイント)の値を示す。HPは、敵キャラクタからのダメージに耐えられる体力を数値化したものである。図示の例では、カード1は「1000」、カード2は「850」、カード3は「1200」のHP値を有する。画像IDは、表示データを生成する際に例えばゲーム情報記憶部122から読み出される、各カードに設定された画像の識別情報を含む。図示の例では、カード1は「画像1」、カード2は「画像2」、カード3は「画像3」により表示される。攻撃力は、発動可能な効果を数値化したもので、例えば攻撃力の値が大きいほど敵に与えることのできるダメージが大きくなる。図示の例では、カード1は「15」、カード2は「6」、カード3は「21」を有する。HP、画像ID、および攻撃力は、ゲームの進行に伴って変化し得る。各カードにはさらに他の情報が設定されてよい。
【0068】
上記ステップS11において、デッキ管理部115は、デッキ管理テーブル1231から、メインデッキとして保存されたデッキのうちいずれかのデッキのレコードを読み出す。はじめに読み出されるメインデッキを、便宜上アクティブなメインデッキと呼ぶ。アクティブなメインデッキは、例えば、番号が最も小さいデッキ、ユーザによって直近に編成され保存されたデッキ、またははじめに表示すべきデッキとしてユーザにより指定されたデッキ等である。例えば、デッキ2がアクティブなメインデッキである場合、デッキ管理部115は、デッキ管理テーブル1231から、デッキ2に含まれるカードの情報(第1枠=カード11、第2枠=カード1・・・)を読み出す。さらにデッキ管理部115は、デッキ2に含まれる各カードの情報を、所持カード管理テーブル1232から取得する。
【0069】
次いでステップS12において、表示制御部114は、ステップS11で取得した情報に基づいて、ゲーム画像にメインデッキを表示させるための表示データを生成し出力する。ゲーム画像は、選択されたクエスト(ユーザが挑戦しようとしているクエスト)の情報と、メインデッキの情報と、を含む。メインデッキの情報は、メインデッキを表示する領域であるメインデッキフィールドに表示される。メインデッキフィールドは、ゲーム画像の第1範囲の一例である。メインデッキフィールドの表示は、専用のUIオブジェクトを用いて実現される。第1実施形態では、メインデッキフィールドは、ゲーム画像内の所定の位置に表示される。
【0070】
ステップS13において、デッキ管理部115は、ユーザが挑戦しようとしているクエストがサブデッキの設定対象であるか否かを判定する。デッキ管理部115は、例えばデッキ情報記憶部123に格納されたクエスト管理テーブル1233の情報に基づいて判定を行う。クエストがサブデッキの対象である場合(YES)、ステップS14に進み、クエストがサブデッキの対象でない場合(NO)、処理を終了する。
【0071】
図10は、クエスト管理テーブル1233の一例を示す。クエスト管理テーブル1233は、デッキを使用してプレイ可能なゲームとしてのクエストの情報を記憶する。例えばクエスト管理テーブル1233は、クエストID、敵キャラ、画像ID、およびサブデッキ設定を含む。クエストIDは、クエストを識別可能な情報(図示の例では、「クエスト1」、「クエスト2」・・・、「クエスト101」・・・)を含む。敵キャラは、各クエストに設定された敵キャラクタに関する情報を含む。図示の例では、クエスト1には「敵1」、クエスト2には「敵2」、クエスト101には「ドラゴン」が設定されている。画像IDは、表示データを生成する際に例えばゲーム情報記憶部122から読み出される、各敵キャラクタに設定された画像の識別情報を含む。図示の例では、クエスト1の敵1は「画像101」、クエスト2の敵2は「画像102」、クエスト101のドラゴンは「画像501」により表示される。サブデッキ設定は、各クエストのサブデッキ設定に関する情報を含む。値「NA」は、当該クエストがサブデッキ設定の対象でないことを示す。図示の例では、クエスト1およびクエスト2はサブデッキ設定の対象ではない。一方、クエスト101には、「サブデッキ設定」として「デッキ21」が設定されている。このように、第1実施形態では、特定のクエストまたは特定の敵キャラクタに対して、メインデッキのカードの入替え候補としてのカードを含むサブデッキを設定できるものとする。サブデッキの情報は上述のデッキ管理テーブル1231で管理される。デッキ管理テーブル1231において、「デッキ21」は、「クエスト101用サブデッキ」または「対ドラゴン用サブデッキ」等として管理されてもよい。サブデッキ設定の情報は、デッキ管理テーブル1231内で重複してもよい。例えば、ドラゴンに類似する敵キャラクタが出現する複数のクエストに同一の「デッキ21」がサブデッキとして設定されてよい。また、すべてのクエストにサブデッキ設定が可能であってもよい。
【0072】
上記ステップS13において、ユーザが挑戦しようとしているクエストがクエスト101の場合、YESの分岐によりステップS14に進む。他方、ユーザが挑戦しようとしているクエストがクエスト1またはクエスト2の場合、NOの分岐により処理を終了する。
【0073】
ステップS14において、表示制御部114は、展開ボタンの機能を有するUIオブジェクトをゲーム画像にさらに表示させる。展開ボタンは、サブデッキ表示を要求する操作ボタンの一例である。展開ボタンは、サブデッキを表示する領域であるサブデッキフィールドを展開するための操作ボタンと言うこともできる。サブデッキフィールドは、ゲーム画像の第2範囲の一例である。
【0074】
図11は、第1実施形態のデッキ表示に係るゲーム画像の第1の例を示す。
図11の左側のゲーム画像11は、ユーザが所定のゲーム画面を介して挑戦しようとするクエストを選択したことに応答して、確認画面として表示部1072により提示される。ゲーム画像11は、特に、クエスト管理テーブル1233の「クエスト101」がユーザにより選択された場合に表示されるゲーム画像の一例である。例えばゲーム画像11は、敵キャラ画像50、敵キャラ情報51、メインデッキフィールド20、総HP情報41、メインデッキ切替ボタン42、もどるボタン43、挑戦するボタン44、および展開ボタン45を含む。
【0075】
敵キャラ画像50は、クエストに設定された敵キャラクタの画像を含む。図示の例では、クエスト管理テーブル1233の「クエスト101」に設定された「画像501」が表示される。
【0076】
敵キャラ情報51は、選択されたクエストに設定された敵キャラクタの情報を含む。図示の例では、クエスト管理テーブル1233の「クエスト101」に設定された「ドラゴン」という文字情報を含む。ゲーム画像に表示される敵キャラ情報51は、敵キャラクタの属性、攻撃力、HP値、特殊技など、さらに多くの情報を含んでよい。これらの情報もまたクエスト管理テーブル1233に記憶され得る。
【0077】
メインデッキフィールド20は、メインデッキを表示する領域であり、メインデッキに含まれるカードを表示するための枠20A~20Fを含む。枠の数は一例である。メインデッキフィールド20は、ゲーム画像11内の所定の位置、例えばゲーム画像11の中心位置から所定の距離のところに表示される。メインデッキフィールド20は、ステップS11で読み出されたアクティブなメインデッキの情報を表示する。例えば、デッキ2に含まれる第1枠~第6枠のカードの画像が、順に、枠20A,20B,20C,20D,20E,20F内に表示される。
【0078】
総HP情報41は、メインデッキフィールド20内の枠20A~20Fに表示された6枚のカードのHPの合計値を表示する。デッキ管理部115は、所持カード管理テーブル1232から該当カードのHP値を読み出し、合計値を算出する。
【0079】
メインデッキ切替ボタン42は、表示するメインデッキの切替えを可能にする操作ボタンである。メインデッキ切替ボタン42がユーザによってタップされると、デッキ管理テーブル1231に記憶された上または下の行のメインデッキの情報が読み出され、表示が切り替えられる。例えば、左側のボタン42がユーザによってタップされると、表示中の「デッキ2」に代えて「デッキ1」に関する表示に切り替えられる。同様に、右側のボタン42がタップされると、表示中の「デッキ2」に代えて「デッキ3」に関する表示に切り替えられる。
【0080】
もどるボタン43は、前のゲーム画面に戻るためのボタンである。もどるボタン43がユーザによってタップされると、選択中のクエスト(図示の例では「ドラゴン」のクエスト(クエスト101))に挑戦せず、直前に表示されていたゲーム画像の表示に戻る。ユーザは、例えば、挑戦するクエストを変更したいとき、またはクエストプレイ自体をキャンセルしたいときなどに、もどるボタン43を選択する。
【0081】
挑戦するボタン44は、選択中のクエストでのゲームプレイを開始するボタンである。挑戦するボタン44がユーザによってタップされると、メインデッキフィールド20に表示されているメインデッキのカードを用いて、表示中のクエストでのゲームプレイが開始される。
【0082】
展開ボタン45は、サブデッキフィールドの展開を要求する操作ボタンである。選択中のクエストがサブデッキ設定対象ではない場合(図6のステップS13でNOの場合)、展開ボタン45は表示されない。展開ボタン45がユーザによってタップされると、操作受付部113、表示制御部114、およびデッキ管理部115の連携により、図5のステップS3のサブデッキ表示処理が実行される。ユーザが展開ボタン45をタップする操作は、第1操作の一例である。
【0083】
図7は、図5のステップS3に示したサブデッキ表示処理の詳細を示す。
ステップS31において、デッキ管理部115は、選択中のクエストに設定されたサブデッキ情報を取得する。サブデッキ情報は、サブデッキに含まれるカードに関する情報を含む。例えばデッキ管理部115は、まずクエスト管理テーブル1233から「クエスト101」に設定されたサブデッキ設定「デッキ21」を読み出し、次いでデッキ管理テーブル1231から「デッキ21」の編成情報「カード21」、「カード22」、「カード23」・・・を読み出すことにより、サブデッキ情報を取得する。
【0084】
ステップS32において、デッキ管理部115は、表示制御部114と連携して、サブデッキ表示用のゲーム画像に変更する処理を実行する。この処理は、ゲーム画像におけるメインデッキフィールドの位置を変更することによってサブデッキフィールドを表示させる処理を含む。この処理はまた、ゲーム画像におけるメインデッキフィールドの位置を変更して、変更前のメインデッキフィールドの位置にサブデッキフィールドを表示させる処理を含み得る。
【0085】
ステップS33において、デッキ管理部115は、サブデッキフィールドおよびサブデッキを表示させる。サブデッキフィールドの表示は、専用のUIオブジェクトを用いて実現される。サブデッキフィールドは、読み出したサブデッキのカードの情報を表示する。
【0086】
図11の右側のゲーム画像12は、ゲーム画像11において展開ボタン45がタップされた場合に表示されるゲーム画像の一例である。例えばゲーム画像12は、ゲーム画像11に含まれていたのと同じ表示(敵キャラ画像50、敵キャラ情報51、メインデッキフィールド20、総HP情報41、メインデッキ切替ボタン42、もどるボタン43、および挑戦するボタン44)に加えて、サブデッキフィールド30、および折畳みボタン46をさらに含む。
【0087】
サブデッキフィールド30は、サブデッキを表示する領域であり、サブデッキに含まれるカードを表示するための枠30A~30Fを含む。枠の数は一例である。図示の例では、サブデッキフィールド30は、吹出しの外観を有するUIオブジェクトとして表示される。例えば、デッキ21に含まれる第1枠~第6枠のカードの画像が順に、枠30A,30B,30C,30D,30E,30F内に表示される。これにより、ユーザは、クエストプレイを開始する前の確認画面において、クエストの情報とともに、クエストで使用される予定のメインデッキと、メインデッキの入替え候補のカードを含むサブデッキと、を確認することができ、メインデッキのカードの入替えの要否を判断することができる。
【0088】
折畳みボタン46は、サブデッキフィールド30の表示を消す機能を有する。例えばゲーム画像12において折畳みボタン46がタップされると、ゲーム画像12からゲーム画像11へと遷移する。
【0089】
図11の例では、サブデッキフィールド30が展開される際、サブデッキフィールド30の表示スペースの分、メインデッキフィールド20の表示スペースが上方に移動するように設定されている。この例では、破線で示したように、ゲーム画像11においてメインデッキフィールド20が表示されていた位置付近に、ゲーム画像12においてサブデッキフィールド30が表示される。この例ではまた、敵キャラ情報51および総HP情報41も同様に上方に移動して表示される。敵キャラ画像50は、図示したように表示を維持されてもよいし、表示を変更されてもよい。サブデッキフィールド30の展開時には、ゲーム画像を簡潔にするため、敵キャラ画像50、敵キャラ情報51または総HP情報41の表示が消されてもよい。あるいは、メインデッキフィールド20の位置はそのままで、メインデッキフィールド20の下方に(例えば、もどるボタン43および挑戦するボタン44に重畳して)サブデッキフィールド30が表示されてもよい。サブデッキまたはサブデッキフィールド30の表示態様は、これらに限定されない。折畳みボタン46がタップされると、メインデッキフィールド20の位置が変更され(元に戻され)てよい。
【0090】
図11に例示したように、サブデッキフィールド30の展開時にメインデッキフィールド20の位置を変更することで、ゲーム画面において、展開ボタン45を押すとメインデッキがせり上がり、隠れていたサブデッキが展開表示され、折畳みボタン46を押すとサブデッキが折り畳まれる(隠れる)、という視覚効果がもたらされる。
【0091】
(第2実施例)
第2実施例では、第1実施例の動作に加えて、ユーザの操作に応答してメインデッキに含まれるカードとサブデッキに含まれるカードとを入れ替える、デッキ表示動作について説明する。
【0092】
図12は、第1実施形態に係るユーザ端末の情報処理動作の第2実施例を示すフローチャートである。
まずステップS1において、ユーザ端末100は、制御部110の制御の下、メインデッキ表示処理を実行する。この処理は、第1実施例において図5および図6に関して説明したステップS1と同様の処理であるので、詳細な説明は省略する。
【0093】
次いでステップS2において、ユーザ端末100は、操作受付部113により、サブデッキ表示を要求するユーザ操作(ユーザの第1操作)を受け付けたかどうかを監視し、当該ユーザ操作を受け付けた場合(YES)、ステップS3に進む。この処理もまた第1実施例で説明したステップS2と同様の処理であるので、詳細な説明は省略する。サブデッキ表示を要求するユーザ操作を受け付けることなく例えば一定時間が経過した場合(NO)、ステップS8に進む。
【0094】
ステップS3において、ユーザ端末100は、制御部110の制御の下、サブデッキ表示を要求するユーザ操作に応答してサブデッキ表示処理を実行する。この処理もまた第1実施例で説明したステップS3と同様の処理であるので、詳細な説明は省略する。
【0095】
ステップS4において、ユーザ端末100は、操作受付部113により、入替え操作(ユーザの第2操作)を受け付けたか否かを判定する。入替え操作は、表示されているデッキのカードの入替えを要求する操作であり、例えばドラッグアンドドロップ操作である。入替え操作についてはさらに後述する。入替え操作を受け付けたと判定される場合(YES)、ステップS5に進み、入替え操作を受け付けることなく例えば一定時間が経過した場合(NO)、ステップS6に進む。
【0096】
ステップS5において、表示制御部114は、操作受付部113が受け付けた入替え操作にしたがって、入替え処理を行い、入替え後のゲーム画像を表示させる処理を行う。
【0097】
図13は、第1実施形態に係るカード入替え処理を説明するゲーム画像の一例を示す。カード入替え処理は、メインデッキのカードとサブデッキのカードとを入れ替える処理を含む。図13の左側のゲーム画像13は、メインデッキフィールド20およびサブデッキフィールド30を含み、サブデッキフィールド30が展開された図11の右側のゲーム画像12の一部分に対応する。矢印DDは、ユーザによるドラッグアンドドロップ操作を示す。矢印DDは、ゲーム画像13に実際に視覚的演出として表示されてもよいし、ゲーム画像13には表示されなくてもよい。矢印DDは、ドラッグアンドドロップ操作の開始位置がサブデッキフィールド30内の第2枠30B内にあり、ドラッグアンドドロップ操作の終了位置がメインデッキフィールド20内の第2枠20B内にあることを示す。これは、枠30Bのカードと枠20Bのカードとを入れ替える操作に対応する。
【0098】
操作受付部113は、例えば、サブデッキフィールド30内のいずれかの枠からメインデッキフィールド20内のいずれかの枠へのドラッグアンドドロップ操作が検知されたことを、入替え操作を受け付けたと判定する。操作受付部113は、メインデッキフィールド20内のいずれかの枠からサブデッキフィールド30内のいずれかの枠へのドラッグアンドドロップ操作が検知されたことを、入替え操作を受け付けたと判定してもよい。入替え操作は、メインデッキフィールド20内の枠同士またはサブデッキフィールド30内の枠同士の入替えを要求するものでもよい。この場合、入替え操作は、メインデッキのカードの並び順の変更またはサブデッキのカードの並び順の変更を要求する操作に対応する。例えば、ドラッグアンドドロップ操作の開始位置がメインデッキフィールド20内の第1枠で検知され、終了位置がメインデッキフィールド20内の第3枠で検知される場合、操作受付部113は、この操作をメインデッキフィールド20内の第1枠と第3枠のカードを入れ替える操作として受け付ける。メインデッキフィールド20内の枠同士またはサブデッキフィールド30内の枠同士の入替え操作は受け付けないように設定されてもよい。ドラッグアンドドロップ操作はスワイプ操作と読み替えられてもよい。あるいは、ドラッグアンドドロップ操作の代わりに、メインデッキフィールド20またはサブデッキフィールド30のいずれかの枠がタップされ、その後一定時間内にメインデッキフィールド20またはサブデッキフィールド30のいずれかの枠がタップされるタップ操作が検知されたことを入替え操作として受け付けてもよい。第2操作としての入替え操作は、他の同様のタッチ操作に置き換えられてもよい。入替え操作はまた、他の物理ボタンまたは他のコマンドによる操作に置き換えられてもよい。操作受付部113は、受け付けた入替え操作の情報をデッキ管理部115に渡す。デッキ管理部115は、受け取った情報に応じて、デッキ管理テーブル1231を書き換える処理を行う。
【0099】
図13の右側のゲーム画像14は、ゲーム画像13に対するドラッグアンドドロップ操作DDに応答してカードの入替え処理が行われた後のゲーム画像を示す。ゲーム画像14は、ステップS5で表示されるゲーム画像の一例である。ゲーム画像13に対し、ゲーム画像14では、メインデッキフィールド20の第2枠20Bのカードと、サブデッキフィールド30の第2枠30Bのカードと、が入れ替わっている。
【0100】
次いでステップS6において、操作受付部113は、サブデッキ表示終了を要求する操作、例えば、折畳みボタン46をタップする操作等を受け付けたか否かを判定する。サブデッキ表示終了を要求する操作が検知された場合(YES)、ステップS7に進み、一定時間検知されなければ(NO)、ステップS4に戻り、引き続き入替え操作の有無を判定する。
【0101】
ステップS7において、表示制御部114は、サブデッキ表示を消す(サブデッキフィールド30を折り畳む)処理を行う。この処理はメインデッキフィールド20の位置を変更する(元に戻す)処理を含んでよい。
【0102】
ステップS8において、操作受付部113は、デッキ表示終了を要求する操作、例えば、もどるボタン43または挑戦するボタン44をタップする操作を受け付けたか否かを判定する。デッキ表示終了を要求する操作が検知された場合(YES)、制御部110は、処理を終了し、検知された操作に応じたゲーム画像表示を実行する。例えば、もどるボタン43がタップされた場合には、クエスト選択前のゲーム画像表示に戻る。挑戦するボタン44がタップされた場合には、メインデッキフィールド20に表示されているメインデッキのカードを用いるクエストプレイのゲーム画像に遷移する。サブデッキフィールド30が展開された状態でもどるボタン43または挑戦するボタン44の操作を受け付けてもよく、その場合、ステップS6およびS7の処理は省略されてもよい。
【0103】
(他の実施例)
サブデッキフィールドの展開例(サブデッキ表示例)は、図11に関して説明した例に限られない。
図14は、第1実施形態のデッキ表示に係るゲーム画像の第2の例を示す。ゲーム画像15は、サブデッキ表示を要求するユーザ操作(ユーザの第1操作)を受け付けた場合に表示されるゲーム画像の一部分に対応する。ゲーム画像15は、メインデッキフィールド20と、サブデッキフィールド32と、を含む。メインデッキフィールド20は、図11のゲーム画像12のメインデッキフィールド20と同じである。サブデッキフィールド32は、スクロールバー33を含む。ゲーム画像15は、サブデッキフィールド32の表示スペースが限られているか、またはサブデッキに含まれるカードの数が多いため、サブデッキフィールド32内に一度にすべてのカードを表示できない場合の表示例である。ゲーム画像15では、サブデッキフィールド32には、サブデッキに含まれる6枚(またはそれ以上)のカードのうち5枚しか表示されていない。スクロールバー33は、サブデッキフィールド32の表示対象の切替えを可能にする。ユーザがスクロールバー33のカーソルを上下にスライド操作すると、操作受付部113および表示制御部114は、スライド操作に応答して表示対象を変更する。サブデッキフィールド32が展開されるとき、メインデッキフィールド20は、ゲーム画像12と同様に、位置を移動して表示されてよい。
【0104】
図15は、第1実施形態のデッキ表示に係るゲーム画像の第3の例を示す。ゲーム画像16もまた、サブデッキ表示を要求するユーザ操作(ユーザの第1操作)を受け付けた場合に表示されるゲーム画像の一部分に対応する。ゲーム画像16は、メインデッキフィールド20と、サブデッキフィールド34と、を含む。メインデッキフィールド20は、図11のゲーム画像12のメインデッキフィールド20と同じである。サブデッキフィールド34は、ゲーム画像12のサブデッキフィールド30に比べて表示スペースが拡大されている。ゲーム画像16は、サブデッキに含まれるカードの数に応じてサブデッキフィールド34を拡大して表示する表示例である。図15の例では、サブデッキが10枚のカードを含んでおり、サブデッキフィールド34は、10枚のカードが一度に表示されるように拡大される。サブデッキフィールド34は、例えば、カード枚数に応じてあらかじめ用意された大きさの異なるUIオブジェクト、またはカード枚数に応じて大きさが可変に構成されたUIオブジェクトを用いて実現される。サブデッキフィールド34が展開されるとき、メインデッキフィールド20は、ゲーム画像12と同様に、位置を移動して表示されてよい。
【0105】
(3)効果
上述したように、第1実施形態では、デッキを使用するゲームプレイの前に、ゲームで使用されるメインデッキと、メインデッキに含まれるカードの入替え候補のカードを含むサブデッキと、をユーザが容易に確認できるようにした。ユーザは、ゲームプレイ前に、入替え候補のカードを確認し、入替えの要否を判断することができる。またユーザは、カードの入替えを望む場合、わざわざデッキ編成パートに戻ることなく、簡易な操作でカードの入替えを行うことができる。ユーザから受け付ける操作が少ないのでユーザ端末100の制御部110による処理を高速化することができる。同様に、ゲームパート遷移の必要がないので、制御部110の処理負荷を軽減することができる。サブデッキフィールド30をメインデッキフィールド20の近くに表示させることで、ユーザは、デッキ編成を容易に確認することができる。さらに、メインデッキフィールド20の位置を変更して、メインデッキフィールド20が表示されていた位置にサブデッキフィールド30を表示すれば、ユーザは視線移動せずにサブデッキを確認することができる。
【0106】
第1実施形態では、あらかじめ特定のクエストまたは特定の敵用に、ゲームで使用されるメインデッキとは異なる、入替え候補のカードを含むサブデッキを編成可能とするゲーム設定を例に挙げて説明した。このようなゲーム設定は、特定のクエストまたは特定の敵に特に有利なカード、またはメインデッキの編成時に組み込むかどうか迷ったカードなどを、ユーザがサブデッキとして編成することを可能にし、ゲームの興趣性を高める。
【0107】
ただし、第1実施形態はこのようなゲーム設定に限定されない。例えば、展開ボタン45をタップするなどのユーザ操作を受け付けるたびに、デッキ管理部115が、所持カード管理テーブル1232からカードを抽出し、サブデッキの代わりに、レコメンドデッキとして表示するようにしてもよい。レコメンドの一例としては、デッキ管理部115がサーバ200から他のユーザの情報を取得することにより、同じクエストに挑戦したユーザのデッキ情報に基づいて行われることが考えられる。例えば、当該クエストにおいて最も多く選択されたデッキ編成の情報がレコメンドデッキとして紹介されたり、または注目度の高いユーザのデッキ編成の情報が提示されてもよい。このとき、所持カード管理テーブル1232に含まれるカードのみが表示されるように制御されてよい。各ユーザ端末100は、実際にクエストプレイで使用したメインデッキの情報をクエストの識別情報とともに任意のタイミングでサーバ200に送信することができ、サーバ200は、複数のユーザ端末100のメインデッキの情報をクエストごとに統合し、蓄積することができる。また例えば、デッキ管理部115は、ユーザの所持カードのうち、表示中のメインデッキのカードを除いたカードの中から、HPまたは攻撃力の値の高い順にカードを所定枚数抽出して、レコメンドデッキを生成し、表示させることができる。防御力の高いカード、特殊技を発動可能なカード、または敵キャラクタの属性に対して有利な属性を有するカードなど、他の抽出条件が設定されてもよい。あるいは、使用可能なカード枚数に制限がある場合に、上記技術が適用されてもよい。例えば、デッキ管理テーブル1231に記憶されたデッキに含まれるカードのうち、第1枠から制限枚数の枠までのカードをメインデッキとし、残りのカードをサブデッキとしてもよい。
【0108】
[第2実施形態]
第1実施形態がシングルプレイの状況を想定したデッキ表示例に関するのに対し、第2実施形態は、協力プレイの状況を想定したデッキ表示例に関する。協力プレイは、複数のユーザ端末がゲームデータの一部を共有することにより協働してゲームを進行させるゲームプレイである。協力プレイは、マルチプレイ、協力バトル、またはマルチバトル、等と言い換えられてもよい。
【0109】
以下では、第2実施形態について、主に第1実施形態との相違点について説明する。特に言及のない場合、第1実施形態に関して説明した構成または動作は、そのまままたは適宜変更して、第2実施形態に適用されてよい。
【0110】
(1)構成
(1-1)ゲームシステム
第2実施形態に係るゲームシステムは、第1実施形態で図1を参照して説明したのと同じ構成を備えることができる。第1実施形態と同様、ユーザ端末100は、第2実施形態に係る情報処理装置の一例である。
【0111】
協力プレイは、例えば、複数のユーザ端末100がサーバ200との間で通信することによって、サーバ200を介したオンライン協力プレイとして実現される。協力プレイは、サーバ200を介さないLANプレイとして実現されてもよい。または協力プレイは、複数のユーザ端末100がBluetooth(登録商標)等の近距離無線通信を介して直接通信することによってローカル協力プレイとして実現されてもよい。あるいは協力プレイは、ユーザ端末100とサーバ200との間の通信と、ユーザ端末100間の直接通信と、を組み合わせて実現されてもよい。
【0112】
以下では一例として、複数のユーザ端末100がサーバ200を介したオンライン協力プレイを実行する状況を想定して説明する。例えば、あるユーザ端末(ホスト端末)100Aが、協力プレイへの参加を募集するための「ルーム」の開設要求をサーバ200に送信する。開設要求は、例えば、ユーザ端末100Aを使用するユーザ(ホスト)のID、ニックネーム、デッキ情報、および協力プレイの対象クエストの情報を含む。協力プレイはルーム単位で行われる。ここではルーム単位の協力プレイに参加するユーザを協力プレイヤーとも呼ぶ。協力プレイヤーは、ルームを開設するホストおよび開設済みのルームに参加するゲストを含む。
【0113】
サーバ200は、ユーザ端末100Aから受信した開設要求に応答してルームを開設し、ルームの情報を公開する。公開される情報は、例えば、ルームの識別情報、ホストのニックネーム、デッキの一部、および協力プレイの対象クエストの情報である。他のユーザ端末(ゲスト端末)100Bは、公開された情報をもとにルームへの参加要求をサーバ200に送信する。参加要求は、例えば、ユーザ端末100Bを使用するユーザ(ゲスト)のID、ニックネーム、およびデッキ情報を含む。サーバ200は、受信した参加要求に応答して、公開するルームの情報にゲストの情報を追加する。ホスト端末100Aおよび参加要求を送信したゲスト端末100Bは、ルーム成立後、ゲームプレイ前の協力プレイ確認画面において、第2実施形態に係るデッキ表示を実現することができる。ルーム成立の条件は、例えば、ルームの参加人数が上限値に達したこと、または参加募集の制限時間に達したことなど、任意に設定されてよい。第2実施形態に係るデッキ表示を含む協力プレイ確認画面は、ルーム成立前に、ルームへの参加募集が継続されている状況で実現されてもよい。
【0114】
(1-2)ハードウェア構成
第2実施形態に係るサーバ200およびユーザ端末100は、図1を参照して第1実施形態に関して説明したのと同じハードウェア構成を備えることができる。
【0115】
(1-3)機能構成
(1-3-1)サーバ
第2実施形態に係るサーバ200は、図2を参照して第1実施形態に関して説明したのと同様の機能構成を備えることができる。
第2実施形態では、ゲーム進行部213は、さらに、ユーザ端末100から受信したルーム開設要求に応答してルームを開設し、公開情報を生成する。ゲーム進行部213はまた、各ルームに係る共有データを生成し、協力プレイを支援する。
【0116】
(1-3-2)ユーザ端末
図16は、第2実施形態に係るユーザ端末100の機能構成の一例を示す。ユーザ端末100は、第1実施形態と同様に、制御部110と、記憶部120と、を備える。
【0117】
記憶部120は、ゲームプログラム記憶部121と、ゲーム情報記憶部122と、デッキ情報記憶部123と、を備える。ゲームプログラム記憶部121およびゲーム情報記憶部122は、第1実施形態と同様であるので、詳細な説明は省略する。
【0118】
デッキ情報記憶部123は、デッキ管理テーブル1231、所持カード管理テーブル1232、クエスト管理テーブル1233、および協力プレイ用デッキ管理テーブル1234を記憶する。デッキ管理テーブル1231、所持カード管理テーブル1232、およびクエスト管理テーブル1233は、第1実施形態と同様である。
協力プレイ用デッキ管理テーブル1234は、協力プレイ用に編成されたデッキの内容を表す情報を記憶する。
【0119】
制御部110は、ゲームプログラム記憶部121に記憶されたゲームプログラムを実行することにより、ゲーム進行部111、オブジェクト制御部112、操作受付部113、表示制御部114、デッキ管理部115、および協力プレイ管理部116として機能し得る。ゲーム進行部111、オブジェクト制御部112、操作受付部113、表示制御部114、およびデッキ管理部115は、第1実施形態と同様の機能を有するので、詳細な説明は省略する。
【0120】
協力プレイ管理部116は、協力プレイに関連する種々の機能を有する。例えば、協力プレイ管理部116は、ユーザの操作に応答して協力プレイのためのルームの開設要求またはルームへの参加要求を出力する。協力プレイ管理部116はまた、デッキ管理部115と連携して、開設要求または参加要求とともに送信すべきデッキ情報を取得する。協力プレイ管理部116はまた、表示制御部114と連携して、協力プレイ確認画面用のゲーム画像におけるメインデッキおよびサブデッキの表示を生成する。
【0121】
(1-4)ゲームの構成
第2実施形態に係るゲームプログラムによって実現されるゲームは、第1実施形態と同様、1以上のカードを組み合わせて編成されたデッキを使用可能なゲームを含む。第2実施形態についても、第1実施形態と同様のクイズRPGにおける適用例を用いて説明するが、これに限定されるものではなく、第2実施形態もまた、デッキを使用可能な他の分類のゲームに適用可能である。
【0122】
図17は、第2実施形態に係るゲームプログラムによって実現されるゲームの構成を示す略図である。ゲームは、複数のゲームパートで構成される。一例として、ゲームは、ホームパートと、デッキ編成パートと、クエストパートと、協力プレイパートと、を含む。ホームパートおよびデッキ編成パートは、第1実施形態で説明したのと同様のゲームパートである。クエストパートは、第1実施形態と同様、ユーザがデッキを用いてシングルプレイ用のクエストでゲームプレイを行うことのできるゲームパートである。協力プレイパートは、複数のユーザ(協力プレイヤー)による協力プレイを可能とするゲームパートである。協力プレイヤーは、カードを出し合って1つのデッキ(「ルームデッキ」と称する)を編成する。ルームデッキは、協力プレイ用のクエストでゲームプレイを行うために使用される。協力プレイ用のクエストは、シングルプレイ用のクエストと同様、敵キャラクタの討伐のような目標がそれぞれに設定された複数のクエストを含む。第1実施形態で説明したのと同様に、各協力プレイヤーは、出題されるクイズに正解してルームデッキに含まれるカードの効果を発動させることにより、ルーム(またはチーム)として協力して目標達成をめざす。例えば、ルーム内の協力プレイヤーには同じクイズが出題され、各協力プレイヤーは、各々のユーザ端末100を介して解答を入力する。入力された解答は、例えばサーバ200において多数決が取られ、ルームとしての解答が決定され、正否が判定される。多数決が取れない場合には例えばホストの解答が優先される。あるいは、協力プレイヤーごとに解答の成否が判定され、ルームデッキのカードのうち、クイズに正解したプレイヤーが所有するカードからアクションが発動されてもよい。協力プレイパートの場合にも、各協力プレイヤーは、ルーム(またはチーム)として挑戦しようとするクエストおよびルームデッキの内容を確認してから、実際の協力プレイに進む。協力プレイ用クエストの情報は、第1実施形態で説明したクエスト管理テーブル1233と同様のテーブル(図示せず)により、サーバ200の記憶部220およびユーザ端末100の記憶部120に保存され得る。協力プレイ用のクエストは、シングルプレイ用のクエストと区別される必要はない。協力プレイパートとクエストパートとは一体化されてもよい。
【0123】
ゲーム画像60は、ホームパートに係るゲーム画像の一例(略図)である。例えばゲーム画像60は、デッキ編成ボタン61と、クエストボタン62と、協力プレイボタン63と、を含む。デッキ編成ボタン61は、第1実施形態で説明したのと同様、デッキ編成パートへの遷移を要求する操作ボタンである。クエストボタン62は、第1実施形態で説明したのと同様、シングルプレイ用のクエストパートへの遷移を要求する操作ボタンである。協力プレイボタン63は、協力プレイパートへの遷移を要求する操作ボタンである。操作ボタンは、ユーザによって選択されると所定の機能を発揮するように構成されたUIオブジェクトである。操作ボタンに代えて他のコマンドが使用されてもよい。
【0124】
第1実施形態に関して説明したのと同様に、デッキ編成ボタン61が選択されると、ホームパートからデッキ編成パートに遷移し、デッキ編成パートに係るゲーム画像7が表示される(Q1)。ゲーム画像7は、第1実施形態で説明したゲーム画像7と同様であるので説明を省略する。ゲーム画像7においてもどるボタン76が選択されると、デッキ編成パートからホームパートに遷移する(Q2)。
【0125】
第1実施形態に関して説明したのと同様に、クエストボタン62が選択されると、ホームパートからシングルプレイ用のクエストパートに遷移する。クエストパートは、第1実施形態で説明したのと同様であるので、図示および説明を省略する。
【0126】
ゲーム画像60において協力プレイボタン63が選択されると、ホームパートから協力プレイパートに遷移し、協力プレイパートに係るゲーム画像90が表示される(Q3)。ゲーム画像90は、協力プレイパートの入口に対応するゲーム画像の一例である。ゲーム画像90は、例えば、ルーム選択ボタン91と、もどるボタン92とを含む。ルーム選択ボタン91は、新しいルームの開設要求に係るボタン(「新ルーム開設」)、または開設済みルームへの参加要求に係るボタン(「ルームR1」、「ルームR2」・・・)等を含む。もどるボタン92は、前のゲーム画面に戻るためのボタンである。例えば、もどるボタン92が選択されると、協力プレイパートからホームパートに遷移する(Q4)。
【0127】
ゲーム画像90においていずれかのルーム選択ボタン91が選択された場合、所定の操作を行うゲーム画面(図示省略)を経て、ゲーム画像17のような確認画面が表示される(Q5)。例えばゲーム画像17は、図4のゲーム画像11と同様、敵キャラクタの画像50、敵キャラクタの情報51、ルームデッキフィールド25、もどるボタン43、および挑戦するボタン44を含む。敵キャラクタの画像50および敵キャラクタの情報51は、第1実施形態と同様、クエストに設定された敵キャラクタの情報を示す。ルームデッキフィールド25は、ゲームで使用されるルームデッキの内容を示す。ルームデッキは、後述するように、各協力プレイヤーが所持するカードを含む。ルームデッキフィールド25は、各協力プレイヤーのカードを表示するためのデッキフィールドを含む。図示の例では、協力プレイヤーは3人(1P、2P、3P)である。挑戦するボタン44が選択されると、表示中のルームデッキを用いる選択したクエストでのゲームプレイが開始される。もどるボタン43が選択されると、ゲーム画像90に遷移する(Q6)。ユーザは、ゲーム画像17のような確認画面において、これから協力プレイで挑戦するクエストおよび使用されるデッキの最終確認を行うことができる。
【0128】
協力プレイは、友人同士など固定メンバーでプレイされることもあれば、不特定多数のプレイヤーに募集をかけて毎回異なるメンバーでプレイされることもある。特に後者の場合、プレイヤーごとに所持カードは異なるから、協力プレイヤーが所持カードからカードを出し合うことによって構成されるルームデッキの内容も毎回大きく異なることになる。協力プレイにおいても、ルームデッキの内容は、ゲームを有利に進められるかどうかに大きく影響する。そのため、各協力プレイヤーは、協力プレイ開始前に、他の協力プレイヤーのカードを確認し、ルームデッキ全体のバランスを考慮して自身のカードを変更する、いわゆる「すり合わせ」作業を望む。このような戦略的なすり合わせ作業は、ゲームの興趣性を高める。
【0129】
ゲーム画像17のような協力プレイ前の確認画面において、各ユーザがルームデッキのカードのうち自身のデッキの内容を変更したいと考える場合、ユーザは、この例では、ゲーム画像17から何らかの操作を経てゲーム画像7のようなデッキ編成用画面を表示させるか(Q7)、またはゲーム画像17から、もどるボタン43、もどるボタン92、およびデッキ編成ボタン61という順に選択して、ゲーム画像7に切り替える必要がある。第2実施形態は、このような協力プレイ前の確認画面におけるデッキ編成を可能とする。
【0130】
(2)動作
次に、図16に示したユーザ端末100による情報処理動作例について説明する。以降の動作の前提として、少なくとも1のユーザ端末100とサーバ200との間の通信が確立され、当該ユーザ端末100の制御部110および記憶部120の連携により、ゲームプログラムに記述されたコードに従ってゲームがいくらか進行されているものとする。
【0131】
なお、ローカル協力プレイの場合など、以下で説明するサーバ200の動作は、適宜、1または複数のユーザ端末100の動作に読み替えられる。
【0132】
図18は、第2実施形態に係るユーザ端末100の情報処理動作の一例を示すフローチャートである。ここでは、ユーザ端末100が、サーバ200にルーム開設要求を送信するホスト端末であるものとして説明する。例えばユーザ端末100は、ルーム開設を要求するユーザ操作を受け付けたことをトリガとして、以降の処理を実行する。ルーム開設を要求するユーザ操作は、協力プレイの対象クエストを選択する操作を含む。
【0133】
まずステップS101において、ユーザ端末100は、デッキ管理部115および協力プレイ管理部116の連携により、協力プレイ用デッキ管理テーブル1234から協力プレイ用デッキの情報を取得し、対象クエストを指定する情報とともにルーム開設要求としてサーバ200に送信する。
【0134】
協力プレイ用デッキは、第1実施形態で説明したデッキと同様、1または複数のカードを含む。協力プレイ用デッキの内容は、協力プレイ用デッキ管理テーブル1234に記憶される。
【0135】
図19は、協力プレイ用デッキ管理テーブル1234の一例を示す。協力プレイ用デッキ管理テーブル1234は、協力プレイ用デッキの内容を表す情報を記憶し、例えば、デッキID、コメント、および編成情報を含む。デッキIDは、保存されているデッキを識別可能な情報(図示の例では、「デッキ101」、「デッキ102」・・・)を含む。コメントは、各デッキの説明を含み、例えばユーザの理解を助けるためデッキ編成時にゲーム画面上に表示される。図示の例では、デッキ101は「対ドラゴン用デッキ」であり、デッキ102は「対XXモンスター用デッキ」である。コメントはオプションであり省略されてもよい。編成情報は、各デッキを編成するカードの情報を含む。カードの情報は、例えばカードを識別可能な情報(図示の例では、「カード101」、「カード102」、「カード103」・・・「カード111」・・・)を含む。各デッキには、最大枠数(カードの上限数)(図示の例では6)が設定される。カードの並び順は、枠情報(図示の例では、「第1枠」、「第2枠」・・・「第6枠」)により管理される。図示の例では、「デッキ101(対ドラゴン用デッキ)」は、第1枠に「カード101」、第2枠に「カード102」、第3枠に「カード103」・・・を含む。「デッキ102(対XXモンスター用デッキ)」は、第1枠に「カード111」・・・を含む。協力プレイ用デッキ管理テーブル1234において、異なるデッキに同一のカードが重複して編成されてよい。例えば、デッキ102が、デッキ101に組み込まれている「カード101」を含んでもよい。このような重複を許容しない設定であってもよい。図示のように、協力プレイ用のデッキは、クエストまたは敵ごとに編成され保存されてよい。協力プレイ用のデッキは単一のデッキであってもよい。協力プレイ用デッキ管理テーブル1234に保存されるデッキは、ユーザによって編成されたデッキのみならず、サーバ200から配信されたデッキおよびゲームプログラムによって自動生成されたデッキを含んでよい。第1実施形態と同様に、協力プレイ用のデッキに含まれるカードの情報は、所持カード管理テーブル1232において管理される。
【0136】
上記ステップS101において、ユーザ端末100は、ユーザによって選択された対象クエストに応じて、協力プレイ用デッキ管理テーブル1234から該当するデッキのレコードを読み出す。協力プレイ用のクエストには、第1実施形態でクエスト管理テーブル1233について説明したのと同様に、敵キャラクタが設定されているものとする。例えば、対象クエストに設定された敵キャラクタが「ドラゴン」の場合、「デッキ101」に含まれる第1枠~第6枠のカード情報が読み出される。あるいは、第1実施形態で説明したのと同様に、クエストまたは敵キャラクタにかかわらずアクティブなデッキが読み出されてもよいし、ユーザがデッキを選択可能なようにしてもよい。あるいは、協力プレイ用デッキは、シングルプレイ用デッキと共用であってもよい。この場合、協力プレイ用デッキ管理テーブル1234は、デッキ管理テーブル1231で代用される。
【0137】
各ユーザ端末100は、ルームの開設要求とともに、読み出した協力プレイ用デッキ(例えば、「デッキ101」)に含まれるカードの情報をサーバ200に送信する。ユーザ端末100が開設済みルームへの参加要求を送信するゲスト端末である場合も同様に、参加要求とともに協力プレイ用デッキに含まれるカードの情報をサーバ200に送信する。サーバ200は、例えば、各ユーザ端末100から受信した協力プレイ用デッキの第1枠から順に所定数のカードを抽出し、ルームデッキを生成する。サーバ200は、生成したルームデッキの情報を、ルームの共有データとしてユーザ端末100に送信する。第2実施形態では、各ユーザの協力プレイ用デッキのうち、ルームデッキとして抽出(選択)される部分を「メインデッキ」と呼び、残りの部分を「サブデッキ」と呼ぶ。メインデッキは、協力プレイで使用される予定のカードを含むデッキであり、サブデッキは、メインデッキのカードの入替え候補のカードを含む、メインデッキとは異なるデッキである。
【0138】
次いでステップS102において、ユーザ端末100は、協力プレイ管理部116により、サーバ200から受信された共有データをもとに、ルーム情報を取得する。ルーム情報は、ルームデッキに含まれるカードの情報を含む。
【0139】
ステップS103において、ユーザ端末100は、表示制御部114により、受信したルーム情報をもとに、協力プレイ確認画面においてルームデッキの内容を表示する。表示制御部114は、ゲーム画像にルームデッキを表示させるための表示データを生成し出力する。ゲーム画像は、対象クエストの情報と、ルームデッキの情報と、を含む。ルームデッキの情報は、ルームデッキを表示する領域であるルームデッキフィールドに表示される。ルームデッキの情報は、各協力プレイヤーのメインデッキの情報と言い換えることができる。ルームデッキフィールドは、メインデッキを表示する領域であるメインデッキフィールドを含む。ルームデッキフィールドは、第2実施形態においてゲーム画像の第1範囲の一例である。メインデッキフィールドは、複数の協力プレイヤー(複数のユーザ)の各々のデッキから選択されたカードを表示する領域である。メインデッキフィールドは、第2実施形態において、ゲーム画像の第1範囲のうち複数の協力プレイヤーの各々のための表示範囲の一例である。ルームデッキフィールドおよびメインデッキフィールドの表示は、専用のUIオブジェクトを用いて実現される。第2実施形態では、ルームデッキフィールドおよびメインデッキフィールドは、ゲーム画像内の所定の位置に表示される。
【0140】
図20は、第2実施形態のデッキ表示に係るゲーム画像の一例を示す。
図20の左側のゲーム画像17は、例えばルームの成立後、協力プレイ確認画面として表示部1072により提示される。ゲーム画像17は、図11に示したゲーム画像11と同様に、敵キャラ画像50、敵キャラ情報51、総HP情報41、もどるボタン43、挑戦するボタン44、および展開ボタン45を含む。敵キャラ画像50および敵キャラ情報51は、協力プレイの対象クエストに設定された敵キャラクタの情報を示す。ゲーム画像17はさらに、ルーム情報52およびルームデッキフィールド25を含む。
【0141】
ルーム情報52は、参加しているルームを識別可能な情報(図示の例では「ルームR3」)を含む。ルームを識別可能な情報は、サーバ200において付与され、管理される。
【0142】
ルームデッキフィールド25は、ルームデッキを表示する領域である。ルームデッキフィールド25は、ゲーム画像17内の所定の位置、例えばゲーム画像17の中心位置から所定の距離のところに表示される。ルームデッキフィールド25は、ステップS102で取得されたルームデッキに含まれるカードの情報を表示する。図示の例では、ルームR3は、協力プレイヤーを3人(プレイヤー1(1P),プレイヤー2(2P),プレイヤー3(3P))含む。例えば、1Pはホストを表し、2Pおよび3Pはゲストを表す。2Pおよび3Pは例えば参加要求がサーバ200において受信された順序に対応する。ルームデッキフィールド25は、各協力プレイヤーのメインデッキを表示する、メインデッキフィールド26,27,28を含む。図示の例では、ルームデッキフィールド25を略3分割した各々にメインデッキフィールド26,27,28が表示される。図示の例では、メインデッキフィールド26,27,28は各々2枠を有し、ルームデッキの合計枠数は6枠である。枠数は一例にすぎない。メインデッキフィールド26は、1Pのユーザ端末100がルーム開設要求とともに送信した協力プレイ用デッキのうち、抽出された先頭の2枠(第1枠および第2枠)のカードを表示する。メインデッキフィールド27は、2Pのユーザ端末100が参加要求とともに送信した協力プレイ用デッキのうち、抽出された先頭の2枠(第1枠および第2枠)のカードを表示する。メインデッキフィールド28は、3Pのユーザ端末100が参加要求とともに送信した協力プレイ用デッキのうち、抽出された先頭の2枠(第1枠および第2枠)のカードを表示する。
【0143】
ゲーム画像17は、1P(ホスト)のユーザ端末100に表示される例であるので、1P用のメインデッキフィールド26が強調表示されている。2P用のユーザ端末100においては、例えばルームデッキフィールド25の表示順はそのままでメインデッキフィールド27が強調表示され、3Pのユーザ端末100においては、例えばルームデッキフィールド25の表示順はそのままで3P用のメインデッキフィールド28が強調表示される。展開ボタン45の位置は、例えば2Pのユーザ端末100ではメインデッキフィールド27の下方、3Pのユーザ端末100ではメインデッキフィールド28の下方、など、ゲーム画像17とは異なる位置に配置されてよい。各協力プレイヤーがユーザ端末100を介して挑戦するボタン44を押すと、準備完了の意思表示がサーバ200に送信される。例えば、1P(ホスト)のユーザ端末100のゲーム画面では、当初、挑戦するボタン44はグレイアウト表示され、全ゲストが準備完了した後で挑戦するボタン44を選択可となるように設定される。ホストがルームの最終意思表示として挑戦するボタン44を押すと、表示されているルームデッキを用いて、表示中のクエストでの協力プレイが開始される。
【0144】
総HP情報41は、ルームデッキフィールド25に表示されている6枚のカードのHPの合計値を示す。総HP情報41の値は、サーバ200において計算されてもよいし、各ユーザ端末100において計算されてもよい。
【0145】
上記の例では、サーバ200は、各協力プレイヤーの協力プレイ用デッキから所定数として2枠ずつカードを抽出し、ルームデッキを生成した。抽出されるカード数は、ゲーム開発者等によって任意に設定されてよい。抽出されるカード数は、対象クエストごとまたは敵キャラクタごとにあらかじめ設定されてもよい。あるいは、サーバ200は、抽出するカード数を協力プレイヤー数に応じて変更してもよい。例えば、ルームデッキの枠数が6と設定され、協力プレイヤー数に応じて各協力プレイヤーのメインデッキの枠数が決定されるという設定が可能である。この場合、サーバ200は、協力プレイヤーが2人(ホスト1人とゲスト1人)であれば、各々のメインデッキの枠数を3(=6/2)と決定する。同様に、協力プレイヤーが3人(ホスト1人とゲスト2人)であれば、各々のメインデッキの枠数を2(=6/3)と決定する。割り切れない場合は、ホストの枠数を多くする、またはホストの枠数を少なくするなど調整される。対象クエストごとまたは敵キャラクタごとに、各協力プレイヤーのメインデッキ枠数を固定とするか協力プレイヤー数に応じて変化させるかが設定されてもよい。同様に、対象クエストごとまたは敵キャラクタごとに、ルームデッキの枠数、協力プレイヤーの上限数、または各協力プレイヤーのメインデッキ枠数等が設定されてもよい。
【0146】
ステップS104において、ユーザ端末100は、操作受付部113により、サブデッキ表示を要求するユーザ操作(ユーザ端末100を使用する第1ユーザの第1操作)を受け付けたかどうかを監視し、当該ユーザ操作を受け付けた場合(YES)、ステップS105に進む。サブデッキ表示を要求するユーザ操作を受け付けることなく例えば一定時間が経過した場合(NO)、ステップS111に進む。サブデッキ表示を要求するユーザ操作は、例えば、ゲーム画像17において展開ボタン45を押す操作であるが、第1実施形態と同様、他の操作または他のコマンド等に置き換え可能である。
【0147】
ステップS105において、ユーザ端末100は、表示制御部114、デッキ管理部115、および協力プレイ管理部116の連携により、サブデッキ表示処理を実行する。サブデッキ表示処理は、ユーザ端末100を使用するユーザ(第1ユーザ)の協力プレイ用デッキに含まれるカードのうち、当該ユーザのメインデッキフィールドに表示されていないカードをサブデッキフィールドに表示させることを含む。第2実施形態において、サブデッキフィールドは、ゲーム画像の第2範囲の一例である。なお、ここでは、ユーザ端末100を使用するユーザのサブデッキのみを表示し、他のプレイヤーのサブデッキは表示しない態様を想定している。ただしこれは一例にすぎず、全協力プレイヤーのサブデッキを表示するようにしてもよい。
【0148】
ステップS105の処理は、図7に示したサブデッキ表示処理のフローにしたがって実行され得る。
まずステップS31において、デッキ管理部115は、協力プレイ管理部116と連携して、サブデッキの情報を取得する。サブデッキの情報は、例えば、サーバ200から受信された共有データに含まれる。あるいは、デッキ管理部115は、ルーム開設要求とともに送信した「デッキ101」の編成情報を協力プレイ用デッキ管理テーブル1234から読み出し、自身のメインデッキフィールド26に含まれるカードを除いた残りのカードをサブデッキとして特定してもよい。図示の例では、「デッキ101」のうち第3枠~第6枠がサブデッキのカードに対応する。
【0149】
ステップS32において、デッキ管理部115は、表示制御部114と連携して、サブデッキ表示用のゲーム画像に変更する処理を実行する。この処理は、ゲーム画像におけるメインデッキフィールドの位置を変更することによってサブデッキフィールドを表示させる処理を含む。この処理はまた、ゲーム画像におけるメインデッキフィールドの位置を変更して、変更前のメインデッキフィールドの位置にサブデッキフィールドを表示させる処理を含み得る。メインデッキフィールドの位置は、ルームデッキフィールドの位置と読み替えられてもよい。
【0150】
ステップS33において、デッキ管理部115は、サブデッキフィールドおよびサブデッキを表示させる。サブデッキフィールドの表示は、専用のUIオブジェクトを用いて実現される。サブデッキフィールドは、読み出したサブデッキのカードの情報を表示する。
【0151】
図20の右側のゲーム画像18は、ゲーム画像17において展開ボタン45がタップされた場合に表示されるゲーム画像の一例である。例えばゲーム画像18は、ゲーム画像17に含まれていたのと同じ表示(敵キャラ画像50、敵キャラ情報51、メインデッキフィールド20、総HP情報41、もどるボタン43、挑戦するボタン44、およびルーム情報52)に加えて、サブデッキフィールド35および折畳みボタン46をさらに含む。
【0152】
サブデッキフィールド35は、サブデッキを表示する領域であり、サブデッキに含まれるカードを表示するための枠(図示の例では4枠)を含む。例えば、「デッキ101」の第3枠~第6枠のカードの画像が順にサブデッキフィールド35の枠内に表示される。サブデッキフィールド35に表示される枠の数は、カードの数に応じて変更されてもよいし、固定であってもよい。第1実施形態と同様に、サブデッキフィールド35は、吹出しの外観を有するUIオブジェクトとして表示される。これにより、ユーザは、協力プレイを開始する前の確認画面において、クエストの情報とともに、協力プレイで使用される予定のルームデッキ全体と、自身が所持するカードを含むメインデッキと、メインデッキの入替え候補のカードを含むサブデッキと、を確認することができ、自身のメインデッキのカードの入替えの要否を判断することができる。
【0153】
折畳みボタン46は、サブデッキフィールド35の表示を消す機能を有する。例えばゲーム画像12において折畳みボタン46がタップされると、ゲーム画像18からゲーム画像17へと遷移する。
【0154】
図20の例では、第1実施形態と同様に、サブデッキフィールド35が展開される際、サブデッキフィールド35の表示スペースの分、メインデッキフィールド26を含むルームデッキフィールド25全体の表示スペースが上方に移動するように設定されている。この例では、破線で示したように、ゲーム画像17においてルームデッキフィールド25が表示されていた位置付近に、ゲーム画像18においてサブデッキフィールド35が表示される。この例ではまた、敵キャラ情報51、総HP情報41、およびルーム情報52も同様に上方に移動して表示される。敵キャラ画像50は、図示したように表示を維持されてもよいし、表示を変更されてもよい。サブデッキフィールド35の展開時には、ゲーム画像を簡潔にするため、敵キャラ画像50、敵キャラ情報51、総HP情報41、またはルーム情報52の表示が消されてもよい。あるいは、ルームデッキフィールド25の位置はそのままで、ルームデッキフィールド25の下方に(例えば、もどるボタン43および挑戦するボタン44に重畳して)サブデッキフィールド35が表示されてもよい。サブデッキまたはサブデッキフィールド35の表示態様は、これらに限定されない。折畳みボタン46がタップされると、ルームデッキフィールド25の位置が変更され(元に戻され)てよい。
【0155】
次いでステップS106において、ユーザ端末100は、操作受付部113により、入替え操作(ユーザの第2操作)を受け付けたか否かを判定する。入替え操作は、第1実施形態と同様、表示されているデッキのカードの入替えを要求する操作であり、例えばドラッグアンドドロップ操作である。ここでは入替え操作は、ユーザ端末100のユーザのメインデッキとサブデッキとの間でのみ許容されるよう設定される。例えば、操作受付部113は、サブデッキフィールド35のいずれかの枠からメインデッキフィールド26のいずれかの枠へのドラッグアンドドロップ操作が検知されたこと、またはメインデッキフィールド26のいずれかの枠からサブデッキフィールド35のいずれかの枠へのドラッグアンドドロップ操作が検知されたことを、入替え操作を受け付けたと判定する。第1実施形態と同様に、サブデッキフィールド35のいずれかの枠がタップされ、その後一定時間内にメインデッキフィールド26のいずれかの枠がタップされるタップ操作が検知されたこと、またはその逆の順序でタップ操作が検知されたことを、入替え操作を受け付けたと判定してもよい。入替え操作は他のコマンドで入力されてもよい。入替え操作を受け付けたと判定される場合(YES)、ステップS107に進み、入替え操作を受け付けることなく例えば一定時間が経過した場合(NO)、ステップS109に進む。
【0156】
ステップS107において、表示制御部114は、操作受付部113が受け付けた入替え操作にしたがって、第1実施形態と同様に、入替え後のゲーム画像を表示させる処理を行う。
【0157】
ステップS108において、ユーザ端末100は、入替え後のメインデッキ情報をサーバ200に送信する。サーバ200は、例えばホスト(1P)のメインデッキの内容を変更したルームデッキ情報を含む共有データを生成し、他の協力プレイヤー(2Pおよび3P)のユーザ端末100に送信する。共有データを受信したユーザ端末100は、共有データに基づいてルームデッキフィールド25の表示を変更する。共有データは、ホストのユーザ端末100にも送信されてよい。ステップS107の表示処理は、サーバ200から共有データを受信した後で実行されてもよい。共有データは、更新後のルームデッキに係る再計算された総HP値を含んでよい。総HP値は各ユーザ端末100において再計算されてもよい。各ユーザ端末100は、ルームデッキフィールド25の表示とともに総HP情報41の表示も変更する。
【0158】
ここでは、各ユーザ端末100には他の協力プレイヤーのサブデッキは表示されず、他の協力プレイヤーのメインデッキの入替えが行われた場合に、当該他の協力プレイヤーのメインデッキフィールド(27または28)の表示が更新される設定を例に挙げて説明した。この場合、例えば、ある協力プレイヤー(1P)のユーザ端末100Aにおいてサブデッキフィールド35が展開されている場合、他の協力プレイヤー(2Pおよび3P)のユーザ端末100Bおよび100Cにおいて、1P用のメインデッキフィールド26内に「編成中」等のインジケータが表示されるようにしてもよい。また、2Pまたは3Pのユーザ端末(100Bまたは100C)において編成が終了しデッキが確定された場合(各端末において挑戦するボタン44が押された場合)、1Pのユーザ端末100Aにおける2Pまたは3Pのメインデッキフィールド(27または28)の表示態様を変更することとしてもよい。例えば、メインデッキフィールド27または28に重畳させて「確定」等のインジケータを表示させてもよいし、メインデッキフィールド27または28をグレーアウトの表示としてもよい。
【0159】
ステップS109において、操作受付部113は、サブデッキ表示終了を要求する操作、例えば折畳みボタン46をタップする操作等を受け付けたか否かを判定する。サブデッキ表示終了を要求する操作が検知された場合(YES)、ステップS110に進み、一定時間検知されなければ(NO)、ステップS106に戻り、引き続き入替え操作の有無を判定する。
【0160】
ステップS110において、表示制御部114は、サブデッキ表示を消す(サブデッキフィールド35を折り畳む)処理を行う。この処理は、メインデッキフィールド26またはルームデッキフィールド25の位置を変更する(元に戻す)処理を含んでよい。
【0161】
ステップS111において、操作受付部113は、デッキ表示終了を要求する操作、例えば、もどるボタン43または挑戦するボタン44をタップする操作を受け付けたか否かを判定する。デッキ表示終了を要求する操作が検知された場合(YES)、制御部110は、処理を終了し、検知された操作に応じたゲーム画像表示を実行する。例えば、もどるボタン43がタップされた場合には、ルーム参加をキャンセルまたは保留し、直前のゲーム画像表示に戻る。挑戦するボタン44がタップされた場合には、全協力プレイヤーの同意後、ルームデッキフィールド25に表示されているルームデッキのカードを用いる協力プレイのゲーム画像に遷移する。ある協力プレイヤー(例えば3P)のユーザ端末100Cにおいて挑戦するボタン44がタップされた場合、他の協力プレイヤー(1Pおよび2P)のユーザ端末100Aおよび100Bにおいて、3P用のメインデッキフィールド28内に「準備完了」等のインジケータが表示されるようにしてもよい。なお、デッキ表示に制限時間を設定し、制限時間の経過後にデッキ編成を確定させることとしてもよい。
【0162】
第2実施形態に係るユーザ端末100の情報処理動作は、第1実施形態の第1実施例に関して説明したのと同様に、サブデッキフィールドの展開まで(図18のステップS105まで)で終了されてもよい。
なお、以上で説明した情報処理動作は、ユーザ端末100がサーバ200に参加要求を送信するゲスト端末である場合にも同様に適用可能である。
【0163】
(3)効果
上述したように、第2実施形態では、デッキを使用する協力プレイとしてのゲームプレイの前に、ゲームで使用されるメインデッキと、メインデッキに含まれるカードの入替え候補のカードを含むサブデッキと、をユーザが容易に確認できるようにした。ユーザは、ゲームプレイ前に、入替え候補のカードを確認し、入替えの要否を判断することができる。またユーザは、カードの入替えを望む場合、わざわざデッキ編成パートに戻ることなく、簡易な操作でカードの入替えを行うことができる。
【0164】
特に第2実施形態では、複数の協力プレイヤーがカードを出し合って1つのデッキを構築するゲームにおいて、ユーザが他の協力プレイヤーのカードを確認しながら、自身のメインデッキおよびサブデッキを容易に確認可能とした。ユーザは、協力プレイ確認画面のまま、ルームを離れることなくカードの入替えを行うことができる。これは、ユーザの利便性を大きく向上させる。またユーザから受け付ける操作が少ないのでユーザ端末100の制御部110による処理を高速化することができる。同様に、ゲームパート遷移の必要がないので、ユーザ端末100およびサーバ200の処理負荷を軽減することができる。デッキ編成のためにルームへの入退室を繰り返す必要がないことから、ユーザ端末100とサーバ200との間、またはユーザ端末100と他のユーザ端末100との間の通信量を抑制することができる。第1実施形態と同様、サブデッキフィールド35をメインデッキフィールド26(またはルームデッキフィールド25)の近くに表示させることで、ユーザがデッキ編成を容易に確認することができ、メインデッキフィールド26(またはルームデッキフィールド25)の位置を変更してサブデッキフィールド35を表示させることで、ユーザは視線移動せずにサブデッキを確認することができる。
【0165】
第2実施形態では、協力プレイ用デッキとして保存されたデッキの中から、協力プレイの人数やカード数等の制約に応じて、実際に協力プレイで使用されるカードが各ユーザのメインデッキとして抽出されるというゲーム設定を例に挙げて説明した。このようなゲーム設定例は、協力プレイ用のカード候補をある程度絞ったうえでのデッキ編成を容易にし、ゲームの興趣性を高める。カードの入替えを行うとただちに他の協力プレイヤーにも通知されるようにすれば、各プレイヤーは、他の協力プレイヤーの変更後のデッキを見てただちに戦略を練ることができる。
【0166】
ただし、第2実施形態はこのようなゲーム設定に限定されない。例えば、第1実施形態と同様に、ユーザが協力プレイ用のメインデッキと、協力プレイ用のサブデッキと、をあらかじめ保存できるようにしてもよい。協力プレイ用のメインデッキおよびサブデッキは、例えば、1枠、2枠、または3枠など、少数のカードを含むように設定されてよい。あるいは、第1実施形態でも述べたように、展開ボタン45がタップされるたびに、デッキ管理部115が所持カード管理テーブル1232からカードを抽出し、レコメンドデッキとして表示するようにしてもよい。
【0167】
第1実施形態および第2実施形態によれば、ゲームで使用されるデッキ編成を容易にする技術が提供される。
【0168】
[他の実施形態]
なお、この発明は上記実施形態に限定されるものではない。
例えば、クエストプレイまたは協力プレイに使用されるデッキには、変更不可の固定カードまたは固定枠が含まれてよい。このような制約を設けることでゲームの戦略性を高めることができる。またメインデッキフィールドおよびサブデッキフィールドは、カードを含まない空白表示の枠を含んでもよい。
【0169】
サブデッキの表示は、上述したような展開ボタンのタップに限られない。例えば、ゲーム画像に対するタップ操作、ダブルタップ操作、スワイプ操作、フリック操作、またはピンチアウト操作、等によって、サブデッキフィールドが展開されてもよい。同様に、サブデッキの表示を消すのは、折畳みボタンのタップに限られず、ゲーム画像に対するタップ操作、ダブルタップ操作、スワイプ操作、フリック操作、またはピンチイン操作、等によって、サブデッキフィールドが折り畳まれてもよい。
【0170】
デッキ編成は、パーティ編成と読み替えられてもよい。カードは、キャラクタと読み替えられてもよい。クイズに正解した場合にデッキに含まれるカードから発動されるアクションは、攻撃に限られず、ダメージを受けて減少したHP値の回復や、敵からのダメージを回避するバリア効果等の特殊技など、ゲーム内キャラクタが取り得るあらゆるアクションを含んでよい。カードには、デッキ内の他のカードと相互作用して、当該カードが単独で使用されるときとは異なる効果を発動できる設定がなされてもよい。
【0171】
第1実施形態で説明したサブデッキの設定が可能なクエスト、または第2実施形態で説明した協力プレイ用のクエストは、いつでもプレイ可能な常駐クエストおよび期間限定でプレイ可能なイベントクエストを含んでよい。例えば、敵キャラクタとしてドラゴンが設定されたクエストは、半年に1回だけ、毎月1日だけ、または毎週日曜日の21時~22時など、期間限定で繰返し出現するようなイベントクエストであってよい。このような場合、ユーザは、対ドラゴン用に戦略を練った特別なデッキを編成し、常駐クエスト用のデッキとは別のサブデッキまたは協力プレイ用デッキとして保存し、プレイ可能なときに読み出させることができる。
【0172】
サーバ200およびユーザ端末100の構成は、実施形態に係るゲームプログラムを実現可能な他の構成に置き換えられてもよい。サーバ200の構成およびユーザ端末100の構成は、省略され、複数の装置に分散配置され、類似の構成に置き換えられてもよい。サーバ200およびユーザ端末100の各機能部は、回路を用いることで実現されてもよい。回路は、特定の機能を実現する専用回路であってもよいし、プロセッサのような汎用回路であってもよい。
【0173】
さらに、フローチャートを用いて説明した処理の流れは、説明した手順に限定されるものではなく、いくつかのステップの順序が入れ替えられてもよいし、いくつかのステップが同時並行で実施されてもよい。また、以上で説明した一連の処理は、時間的に連続して実行される必要はなく、各ステップは任意のタイミングで実行されてもよい。
【0174】
上記各実施形態の処理の少なくとも一部は、例えば汎用のコンピュータに搭載されたプロセッサを基本ハードウェアとして用いることでも実現可能である。上記処理を実現するプログラムは、コンピュータで読み取り可能な記録媒体に格納して提供されてもよい。プログラムは、インストール可能な形式のファイルまたは実行可能な形式のファイルとして記録媒体に記憶される。記録媒体としては、磁気ディスク、光ディスク(CD-ROM、CD-R、DVD等)、光磁気ディスク(MO等)、半導体メモリ等である。記録媒体は、プログラムを記憶でき、かつ、コンピュータが読み取り可能であれば、何れであってもよい。また、上記処理を実現するプログラムを、インターネット等のネットワークに接続されたコンピュータ(サーバ)上に格納し、ネットワーク経由でコンピュータ(クライアント)にダウンロードさせてもよい。
【0175】
なお、この発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の発明が含まれており、開示される複数の構成要件から選択された組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、課題が解決でき、効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【符号の説明】
【0176】
1…ゲームシステム、100…ユーザ端末、110…制御部、111…ゲーム進行部、112…オブジェクト制御部、113…操作受付部、114…表示制御部、115…デッキ管理部、116…協力プレイ管理部、120…記憶部、121…ゲームプログラム記憶部、122…ゲーム情報記憶部、123…デッキ情報記憶部、1231…デッキ管理テーブル、1232…所持カード管理テーブル、1233…クエスト管理テーブル、1234…協力プレイ用デッキ管理テーブル、200…サーバ、211…受信制御部、212…送信制御部、213…ゲーム進行部、220…記憶部、221…ゲームプログラム記憶部、222…ゲーム情報記憶部、223…ユーザ情報記憶部、1001…プロセッサ、1002…メモリ、1003…ストレージ、1004…センサ、1005…通信インタフェース、1006…入出力インタフェース、1007…タッチスクリーン、1008…バス、1071…入力部、1072…表示部、2001…プロセッサ、2002…メモリ、2003…ストレージ、2004…通信インタフェース、2005…入出力インタフェース、2006…バス。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20