特許 7195465 プログラム、方法、およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2022-12-15

(45)【発行日】2022-12-23

(54)【発明の名称】プログラム、方法、およびシステム

(51)【国際特許分類】

   A63F 13/533 20140101AFI20221216BHJP

   A63F 13/69 20140101ALI20221216BHJP

   A63F 13/80 20140101ALI20221216BHJP

【ＦＩ】

A63F13/533

A63F13/69 520

A63F13/80 B

【請求項の数】 8

(21)【出願番号】P 2022020503

(22)【出願日】2022-02-14

【審査請求日】2022-05-13

【早期審査対象出願】

(73)【特許権者】

【識別番号】511249637

【氏名又は名称】株式会社Ｃｙｇａｍｅｓ

(74)【代理人】

【識別番号】100094569

【弁理士】

【氏名又は名称】田中 伸一郎

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100086771

【弁理士】

【氏名又は名称】西島 孝喜

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤 直樹

(74)【代理人】

【識別番号】100139712

【弁理士】

【氏名又は名称】那須 威夫

(74)【代理人】

【識別番号】100170209

【弁理士】

【氏名又は名称】林 陽和

(72)【発明者】

【氏名】佐藤 有一郎

(72)【発明者】

【氏名】後藤 崇文

(72)【発明者】

【氏名】岡部 優紀

(72)【発明者】

【氏名】熊田 純也

(72)【発明者】

【氏名】劉 英楠

(72)【発明者】

【氏名】上野 高史

(72)【発明者】

【氏名】柴田 有輝

(72)【発明者】

【氏名】森 信虎

(72)【発明者】

【氏名】藤田 嵩

【審査官】早川 貴之

(56)【参考文献】

【文献】特開２０１８－２０２１８３（ＪＰ，Ａ）

【文献】特開２０１７－１８５３６９（ＪＰ，Ａ）

【文献】レジェンド・オブ・ルーンテラ，GameWith [online]，2020年05月15日，https://gamewith.jp/gamedb/article/game/show/5511/8479?from=ios，[検索日：2022年7月15日]

【文献】『レジェンド・オブ・ルーンテラ』LoLの対戦カードゲーム - 面白いゲーム情報，YouTube [online][video]，2020年05月01日，https://www.youtube.com/watch?v=eBRSQATH5KM，[検索日：2022年7月15日]

【文献】Prismatic，MTG WIKI [online]，2021年04月29日，https://web.archive.org/web/20210429134116/https://mtg.fandom.com/wiki/Prismatic?oldid=359437，[検索日：2022/07/15]

【文献】シャドウバース 公式タクティクスガイド ，第2版，株式会社ＫＡＤＯＫＡＷＡ，2016年12月13日，20頁

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ａ６３Ｆ ９／２４，１３／００－１３／９８

(57)【特許請求の範囲】

【請求項1】

各々に属性が対応付けられた複数のゲーム媒体から選択された所定数のゲーム媒体を含むデッキを使用した対戦ゲームをユーザに提供することをコンピュータに実行させるためのプログラムであって、
前記対戦ゲームの開始前に、当該対戦ゲームに使用される前記デッキに含ませるゲーム媒体の複数の属性の前記ユーザによる選択を受け付けることと、
前記デッキにおいて、前記ユーザにより選択された複数の属性の各属性のゲーム媒体の個数が属性ごとに予め決められた最低数以上になるように前記デッキを管理することであって、前記複数の属性がメイン属性とサブ属性とを含み、前記メイン属性の前記最低数が前記サブ属性の前記最低数よりも大きい、前記デッキを管理することと、
前記ユーザにより選択された前記複数の属性と、前記ユーザの対戦相手により使用される前記デッキに含まれる前記所定数のゲーム媒体の前記複数の属性と、を表示することと、
を前記コンピュータに実行させるための、プログラム。

【請求項2】

前記表示することは、前記対戦ゲームの開始時に表示される対戦開始画面上に、前記ユーザにより選択された前記複数の属性と、前記対戦相手により使用される前記デッキに含まれる前記所定数のゲーム媒体が有する前記複数の属性と、を示す文字または画像を表示することを含む、
請求項１に記載のプログラム。

【請求項3】

前記表示することは、前記対戦ゲームの開始後に表示される対戦画面上に、前記ユーザにより選択された前記複数の属性にそれぞれ関連付けられた複数の補足情報を表示することを含む、
請求項１または２に記載のプログラム。

【請求項4】

前記表示することは、前記対戦ゲームの開始後に表示される対戦画面上に、前記対戦相手により使用される前記デッキに含まれる前記所定数のゲーム媒体の前記複数の属性の全て、または当該所定数のゲーム媒体のうち最も個数が多いゲーム媒体の１つの属性、を示す文字または画像を表示することを含む、
請求項１～３のうちいずれか１項に記載のプログラム。

【請求項5】

前記表示することは、前記対戦ゲームの開始後の一時中断時に表示される中断画面上に、前記ユーザにより選択された前記複数の属性と、前記対戦相手により使用される前記デッキに含まれる前記所定数のゲーム媒体の前記複数の属性と、を示す文字または画像を表示することを含む、
請求項１～４のうちいずれか１項に記載のプログラム。

【請求項6】

前記表示することは、前記ユーザにより選択された前記複数の属性を、属性ごとのゲーム媒体の個数の大小関係を識別可能な態様で表示することと、前記対戦相手により使用される前記デッキに含まれる前記所定数のゲーム媒体の前記複数の属性を、属性ごとのゲーム媒体の個数の大小関係を識別可能な態様で表示することを含む、
請求項１～５のうちいずれか１項に記載のプログラム。

【請求項7】

各々に属性が対応付けられた複数のゲーム媒体から選択された所定数のゲーム媒体を含むデッキを使用した対戦ゲームをユーザに提供するための方法であって、
コンピュータにより、前記対戦ゲームの開始前に、当該対戦ゲームに使用される前記デッキに含ませるゲーム媒体の複数の属性の前記ユーザによる選択を受け付けることと、
前記コンピュータにより、前記デッキにおいて、前記ユーザにより選択された複数の属性の各属性のゲーム媒体の個数が属性ごとに予め決められた最低数以上になるように前記デッキを管理することであって、前記複数の属性がメイン属性とサブ属性とを含み、前記メイン属性の前記最低数が前記サブ属性の前記最低数よりも大きい、前記デッキを管理することと、
前記コンピュータにより、前記ユーザにより選択された前記複数の属性と、前記ユーザの対戦相手により使用される前記デッキに含まれる前記所定数のゲーム媒体の前記複数の属性と、を表示することと、
を含む、方法。

【請求項8】

各々に属性が対応付けられた複数のゲーム媒体から選択された所定数のゲーム媒体を含むデッキを使用した対戦ゲームをユーザに提供するためのシステムであって、
前記対戦ゲームの開始前に、当該対戦ゲームに使用される前記デッキに含ませるゲーム媒体の複数の属性の前記ユーザによる選択を受け付ける受付処理部と、
前記デッキにおいて、前記ユーザにより選択された複数の属性の各属性のゲーム媒体の個数が属性ごとに予め決められた最低数以上になるように前記デッキを管理する管理処理部であって、前記複数の属性がメイン属性とサブ属性とを含み、前記メイン属性の前記最低数が前記サブ属性の前記最低数よりも大きい、管理処理部と、
前記ユーザにより選択された前記複数の属性と、前記ユーザの対戦相手により使用される前記デッキに含まれる前記所定数のゲーム媒体の前記複数の属性と、を表示する表示処理部と、
を備える、システム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、プログラム、方法、およびシステムに関する。

【背景技術】

【0002】

従来、各々に属性が対応付けられた複数のゲーム媒体（たとえばデジタルカード）から選択された所定数のゲーム媒体を含むデッキを使用した対戦ゲームをユーザに提供する技術が知られている。

【先行技術文献】

【特許文献】

【0003】

【文献】特許第６８０４６７５号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

上記のような従来の対戦ゲームにおいては、単一の属性のゲーム媒体を使用してデッキを編成する必要があるという制限が設けられることがある。このため、属性に関する戦略性をより向上させる余地がある。

【0005】

そこで、本開示が解決しようとする課題の一つは、属性に関する戦略性がより向上した対戦ゲームを提供することが可能なプログラム、方法、およびシステムを提供することである。

【課題を解決するための手段】

【0006】

本開示の一例としての認証システムは、各々に属性が対応付けられた複数のゲーム媒体から選択された所定数のゲーム媒体を含むデッキを使用した対戦ゲームをユーザに提供することをコンピュータに実行させるためのプログラムであって、対戦ゲームの開始前に、当該対戦ゲームに使用されるデッキに含ませるゲーム媒体の複数の属性のユーザによる選択を受け付けることと、デッキにおいて、ユーザにより選択された複数の属性の各属性のゲーム媒体の個数が属性ごとに予め決められた最低数以上になるようにデッキを管理することと、ユーザにより選択された複数の属性と、ユーザの対戦相手により使用されるデッキに含まれる所定数のゲーム媒体の複数の属性と、を表示することと、をコンピュータに実行させるための、プログラムである。

【0007】

また、本開示の他の一例としての方法は、各々に属性が対応付けられた複数のゲーム媒体から選択された所定数のゲーム媒体を含むデッキを使用した対戦ゲームをユーザに提供するための方法であって、対戦ゲームの開始前に、当該対戦ゲームに使用されるデッキに含ませるゲーム媒体の複数の属性のユーザによる選択を受け付けることと、デッキにおいて、ユーザにより選択された複数の属性の各属性のゲーム媒体の個数が属性ごとに予め決められた最低数以上になるようにデッキを管理することと、ユーザにより選択された複数の属性と、ユーザの対戦相手により使用されるデッキに含まれる所定数のゲーム媒体の複数の属性と、を表示することと、を含む。

【0008】

また、本開示のさらに他の一例としてのシステムは、各々に属性が対応付けられた複数のゲーム媒体から選択された所定数のゲーム媒体を含むデッキを使用した対戦ゲームをユーザに提供するためのシステムであって、対戦ゲームの開始前に、当該対戦ゲームに使用されるデッキに含ませるゲーム媒体の複数の属性のユーザによる選択を受け付ける受付処理部と、デッキにおいて、ユーザにより選択された複数の属性の各属性のゲーム媒体の個数が属性ごとに予め決められた最低数以上になるようにデッキを管理する管理処理部と、ユーザにより選択された複数の属性と、ユーザの対戦相手により使用されるデッキに含まれる所定数のゲーム媒体の複数の属性と、を表示する表示処理部と、を備える。

【図面の簡単な説明】

【0009】

【図1】図１は、実施形態にかかるシステムの構成を示した例示的かつ模式的な図である。

【図2】図２は、実施形態にかかる端末装置の機能的構成を示した例示的かつ模式的なブロック図である。

【図3】図３は、実施形態にかかる端末装置およびサーバ装置により実行される処理の流れを示した例示的かつ模式的なシーケンス図である。

【図4】図４は、実施形態にかかる端末装置により実行されるデッキ編成処理の流れを示した例示的かつ模式的なフローチャートである。

【図5】図５は、実施形態にかかるクラス選択画面の一例を示した例示的かつ模式的な図である。

【図6】図６は、実施形態にかかるデッキ編成画面の一例を示した例示的かつ模式的な図である。

【図7】図７は、実施形態にかかる入替確認画像の一例を示した例示的かつ模式的な図である。

【図8】図８は、実施形態にかかる、図６に示される例に対してメインクラスおよびサブクラスの入れ替えが施されたデッキ編成画面を示した例示的かつ模式的な図である。

【図9】図９は、実施形態にかかる保存確認画像の一例を示した例示的かつ模式的な図である。

【図10】図１０は、実施形態にかかる保存アラート画像の一例を示した例示的かつ模式的な図である。

【図11】図１１は、実施形態にかかる保存アラート画像の図１０とは異なる一例を示した例示的かつ模式的な図である。

【図12】図１２は、実施形態にかかる保存アラート画像の図１０および図１１とは異なる一例を示した例示的かつ模式的な図である。

【図13】図１３は、実施形態にかかる保存アラート画像の図１０～図１２とは異なる一例を示した例示的かつ模式的な図である。

【図14】図１４は、実施形態にかかる保存アラート画像の図１０～図１３とは異なる一例を示した例示的かつ模式的な図である。

【図15】図１５は、実施形態にかかる対戦開始画面の一例を示した例示的かつ模式的な図である。

【図16】図１６は、実施形態にかかる対戦開始画面の図１５とは異なる一例を示した例示的かつ模式的な図である。

【図17】図１７は、実施形態にかかる対戦開始画面の図１５および図１６とは異なる一例を示した例示的かつ模式的な図である。

【図18】図１８は、実施形態にかかる対戦画面の一例を示した例示的かつ模式的な図である。

【図19】図１９は、実施形態にかかる対戦画面の図１８とは異なる一例を示した例示的かつ模式的な図である。

【図20】図２０は、実施形態にかかる対戦画面の図１８および図１９とは異なる一例を示した例示的かつ模式的な図である。

【図21】図２１は、実施形態にかかる中断画面の一例を示した例示的かつ模式的な図である。

【図22】図２２は、実施形態にかかる端末装置およびサーバ装置を構成する情報処理装置のハードウェア構成の一例を示した例示的かつ模式的なブロック図である。

【発明を実施するための形態】

【0010】

以下、本開示にかかるプログラム、方法、およびシステムの実施形態を図面に基づいて説明する。以下に記載する実施形態の構成、ならびに当該構成によってもたらされる作用および効果は、あくまで一例であって、以下の記載内容に制限されるものではない。

【0011】

また、以下では、「第１」、「第２」などの序数が必要に応じて使用されるが、これらの序数は、識別の便宜のために使用されるものであり、特定の優先順位を示すものではない。

【0012】

図１は、実施形態にかかるシステムの構成を示した例示的かつ模式的な図である。

【0013】

図１に示されるように、実施形態にかかるシステムは、タッチパネルを有するディスプレイ１１０Ａを含む複数の端末装置１１０と、サーバ装置１２０と、を備える。端末装置１１０とサーバ装置１２０とは、たとえばインターネットのようなネットワーク１５０を介して互いに通信可能に接続されている。

【0014】

なお、図１に示される構成は、あくまで一例であり、本開示の技術的思想を制限するものではない。たとえば、図１には、ディスプレイ１１０Ａを含む端末装置１１０の例として、ディスプレイ１１１Ａおよび１１２Ａを含むタブレットコンピュータとして構成された端末装置１１１および１１２が例示されている。しかしながら、端末装置１１０の個数は、３個以上であってもよいし、端末装置１１０は、一般的なコンピュータと同等の構成（具体例は図２２を参照しながら後述する）を有していれば、タブレットコンピュータ以外の電子機器として構成されていてもよい。

【0015】

上記のような構成により、実施形態では、端末装置１１０のユーザ間でのネットワーク１５０を介した対戦ゲームが実現される。たとえば、実施形態において、対戦ゲームは、各々に属性（以下、クラスと表現する）が対応付けられた複数のゲーム媒体としてのたとえばデジタルカード（以下、単にカードと表現する）から選択された所定数のカードを含むデッキを使用した対戦ゲームである。

【0016】

たとえば、実施形態において、各端末装置１１０のユーザは、対戦ゲームの運営者から提供されるカードを抽選などによりデジタル的に取得することで所有し、所有しているカードからクラスを考慮した上で所定数のカードを選択することでデッキを編成し、編成したデッキを使用して他のユーザとサーバ装置１２０を介して対戦ゲームをプレイする。

【0017】

また、実施形態において、サーバ装置１２０は、たとえば、対戦ゲームをプレイするユーザ（プレイヤ）に関するプレイヤ情報を当該対戦ゲームに参加するユーザごとに記録する。プレイヤ情報とは、たとえば、プレイヤが所有しているカードに関する情報、およびプレイヤが過去に編成したデッキに関する情報などである。そして、サーバ装置１２０は、ユーザの操作に応じて端末装置１１０から出力される情報に基づいて、記録されたプレイヤ情報を更新したり、対戦ゲームの進行を制御したりする。

【0018】

ところで、各々にクラスが対応付けられた複数のカードから選択された所定数のカードを含むデッキを使用した対戦ゲームをユーザに提供する上記のような技術について、従来から様々に検討されている。このような従来の対戦ゲームにおいては、単一のクラスのゲーム媒体を使用してデッキを編成する必要があるという制限が設けられることがある。このため、クラスに関する戦略性をより向上させる余地がある。

【0019】

そこで、実施形態は、以下で詳細に説明する技術により、デッキに最低限含ませる必要があるカードの枚数（最低数）がクラスごとに予め決められているという条件下で複数のクラスのカードを含むように編成されたデッキを使用した対戦ゲームを可能にすることで、クラスに関する戦略性がより向上した対戦ゲームを提供することを実現する。

【0020】

図２は、実施形態にかかる端末装置１１０の機能的構成を示した例示的かつ模式的なブロック図である。

【0021】

図２に示されるように、端末装置１１０は、受付処理部２０１と、管理処理部２０２と、ゲーム制御処理部２０３と、表示処理部２０４と、を含んでいる。

【0022】

受付処理部２０１は、端末装置１１０を使用したユーザの各種の操作の入力を受け付ける。たとえば、受付処理部２０１は、対戦ゲームの開始前に、当該対戦ゲームに使用されるデッキに含ませるカードのクラスの選択を受け付けたり、クラスの選択後に、デッキに含ませるカードの選択を受け付けたりする。

【0023】

管理処理部２０２は、ユーザの操作に応じて編成されたデッキの管理を行う。管理処理部２０２が行う管理の具体的内容については後で詳細に説明するため、ここではこれ以上の説明を省略する。

【0024】

ゲーム制御処理部２０３は、通信によりサーバ装置１２０と連携しながら、対戦ゲームの進行を制御する。また、表示処理部２０４は、対戦ゲームに関する画像のディスプレイ１１０Ａへの出力を制御する。

【0025】

上記のような機能的構成に基づき、実施形態にかかる端末装置１１０は、ユーザに対戦ゲームを提供する際に、次の図３に示されるような流れで、サーバ装置１２０と連携しながら、各種の処理を実行する。

【0026】

図３は、実施形態にかかる端末装置１１０およびサーバ装置１２０により実行される処理の流れを示した例示的かつ模式的なシーケンス図である。

【0027】

図３に示されるように、実施形態において、端末装置１１０（たとえばゲーム制御処理部２０３）は、まず、Ｓ３１１において、当該端末装置１１０のユーザのプレイヤ情報をサーバ装置１２０から取得するためのログイン要求処理を実行し、当該ユーザの識別情報などを含むログイン情報をサーバ装置１２０に送信する。このＳ３１１の処理は、たとえば対戦ゲームを提供するために端末装置１１０にインストールされたアプリケーションの開始時に実行される。

【0028】

そして、サーバ装置１２０は、Ｓ３２１において、端末装置１１０から受信されたログイン情報に基づいてログイン処理を実行し、自身が記録しているプレイヤ情報の中から対応するプレイヤ情報を抽出し、抽出したプレイヤ情報を端末装置１１０に送信する。

【0029】

そして、端末装置１１０（たとえば受付処理部２０１、管理処理部２０２、および表示処理部２０４）は、Ｓ３１３において、対戦ゲームに使用するデッキをユーザの操作に応じて編成するデッキ編成処理を実行し、編成されたデッキに関するデッキ情報をサーバ装置１２０に送信する。詳細は後述するが、デッキ編成処理とは、受付処理部２０１によりユーザの操作を受け付けるとともに必要に応じて表示処理部２０４により各種の画像（画面）をディスプレイ１１０Ａに表示しながら管理処理部２０２によりデッキを管理する処理である。

【0030】

そして、サーバ装置１２０は、Ｓ３２２において、端末装置１１０から受信されたデッキ情報を保存して自身が記録しているプレイヤ情報を更新するデッキ情報保存処理を実行する。

【0031】

そして、端末装置１１０（たとえば受付処理部２０１、ゲーム制御処理部２０３、および表示処理部２０４）およびサーバ装置１２０は、それぞれ、Ｓ３１３およびＳ３２３において、通信により互いに連携しながら対戦ゲームを実行するゲーム実行処理を実行する。ゲーム実行処理とは、受付処理部２０１によりユーザの操作を受け付けるとともに表示処理部２０４により各種の画像（画面）をディスプレイ１１０Ａに表示しながら、ゲーム制御処理部２０３によりゲームの進行を制御する処理である。

【0032】

ここで、実施形態において、上記のＳ３１２のデッキ編成処理は、以下に説明するように、対戦ゲームに使用するデッキに含ませるカードのクラスをユーザに選択させる処理、デッキを編成するカードをユーザに選択させる処理、編成されたデッキを保存する処理、および、これらの処理に供する各種の画像をディスプレイ１１０Ａに表示する処理などを含む。

【0033】

図４は、実施形態にかかる端末装置１１０により実行されるデッキ編成処理の流れを示した例示的かつ模式的なフローチャートである。

【0034】

図４に示されるように、デッキ編成処理では、まず、Ｓ４０１において、表示処理部２０４は、対戦ゲームに使用するデッキに含ませるカードのクラスをユーザに選択させる処理に供されるたとえば次の図５に示されるようなクラス選択画面をディスプレイ１１０Ａに表示する。そして、受付処理部２０１は、クラス選択画面を介したユーザの操作の入力を受け付ける。

【0035】

図５は、実施形態にかかるクラス選択画面の一例を示した例示的かつ模式的な図である。

【0036】

図５に示される画像５００は、クラス選択画面の一例である。この画像５００は、対戦ゲームに使用されるデッキに含ませるクラスの選択を受け付ける領域５１０と、当該選択を確定させるための決定ボタン５２０と、を含む。

【0037】

複数のクラスのカードを含むデッキを対戦ゲームに使用するという条件下において、ユーザは、領域５１０に対する操作、たとえばディスプレイ１１０Ａのタッチパネルを介したタッチ操作、を実行することで、デッキに含ませるカードの複数のクラスを選択することが可能である。これら複数のクラスの選択は、決定ボタン５２０に対するタッチ操作としての選択完了操作が実行された場合に確定する。

【0038】

なお、以下では、簡単化のため、クラス選択画面を介して選択されるクラスの個数が２つである場合についてのみについて説明するが、本開示の技術は、クラス選択画面を介して選択されるクラスの個数が３つ以上である場合についても同様に適用可能である。

【0039】

たとえば、図５に示される例において、領域５１０には、「エルフ」というクラスの選択を受け付ける選択ボタン５１１と、「ロイヤル」というクラスの選択を受け付ける選択ボタン５１２と、「ウィッチ」というクラスの選択を受け付ける選択ボタン５１３と、「ドラゴン」というクラスの選択を受け付ける選択ボタン５１４と、が表示されている。さらに、領域５１０には、「ネクロマンサー」というクラスの選択を受け付ける選択ボタン５１５と、「ヴァンパイア」というクラスの選択を受け付ける選択ボタン５１６と、「ビショップ」というクラスの選択を受け付ける選択ボタン５１７と、「ネメシス」というクラスの選択を受け付ける選択ボタン５１８と、も表示されている。

【0040】

２つのクラスのカードを含むデッキを対戦ゲームに使用するという条件下において、ユーザは、上記の８つの選択ボタン５１１～５１８のうち所望の２つを操作することで、デッキに含ませるカードの２つのクラスを選択することが可能である。これら２つのクラスの選択は、決定ボタン５２０を使用した選択完了操作が実行された場合に確定する。なお、１つ目に選択されたクラスは、たとえばデッキの主力となるメイン属性としてのメインクラスとなり、２つ目に選択されたクラスは、たとえば主力を補佐するサブ属性としてのサブクラスとなる。実施形態では、メインクラスに対して予め決められた上記の最低数がサブクラスに対して予め決められた上記の最低数よりも大きい必要があるという制限が設けられる。

【0041】

図４に戻り、Ｓ４０２において、受付処理部２０１は、選択完了操作、たとえば上記の決定ボタン５２０に対するタッチ操作が実行されたか否かを判定する。Ｓ４０２において、選択完了操作が実行されていないと判定された場合、Ｓ４０１に処理が戻り、受付処理部２０１は、クラス選択画面を介したユーザの操作の入力を引き続き受け付ける。

【0042】

一方、Ｓ４０２において、選択完了操作が実行されたと判定された場合、Ｓ４０３に処理が進む。そして、Ｓ４０３において、表示処理部２０４は、デッキに含ませるカードをユーザに選択させる処理に供されるたとえば次の図６に示されるようなデッキ編成画面をディスプレイ１１０Ａに表示する。そして、受付処理部２０１は、デッキ編成画面を介したユーザの操作の入力を受け付ける。

【0043】

図６は、実施形態にかかるデッキ編成画面の一例を示した例示的かつ模式的な図である。

【0044】

図６に示される画像６００は、デッキ編成画面の一例である。この画像６００は、第１領域６１０と、第２領域６２０と、保存ボタン６３０と、第３領域６４０と、クラス入替ボタン６５０と、自動編成ボタン６６０と、を含む。

【0045】

第１領域６１０には、たとえば、ユーザがデジタル的に所有しているカードのうち、上記のクラス選択画面によって選択されたクラスのカードと、クラスが無い（または全てのクラスに対応する）ものとしてデータ上扱われる「ニュートラル」と呼ばれる特性を持つカードと、の一覧が表示される。また、第２領域６２０には、デッキ内のカードの一覧が表示される。ユーザは、第１領域６１０に表示されたカードを選択する操作（たとえばタッチ操作）を実行し、選択したカードを第２領域６２０内へと移動させる操作（たとえばスワイプ操作）を実行することで、デッキを編成する。編成されたデッキは、保存ボタン６３０の操作（たとえばタッチ操作）が実行された場合に、デッキ内のカードの枚数が予め決められた条件を満たすか否かを判定するための後述する所定の判定処理を経て保存される。

【0046】

なお、メインクラス、サブクラス、および「ニュートラル」のカードの一覧が第１領域６１０に表示されるという上記の表示態様は、あくまで一例である。実施形態では、ユーザが所有している全てのカードの一覧が第１領域６１０にデフォルトで表示されうる。この場合、ユーザは、デッキ編成画面から呼び出すことが可能なカードフィルタ機能を利用して、全てのカードの中から所望のカードのみを抽出（検索）することで、所望のカードのみを第１領域６１０に表示させうる。

【0047】

第３領域６４０には、現在編成中のデッキの名称が表示される。デッキの名称は、ユーザが任意に変更することが可能である。デフォルトのデッキの名称としては、たとえば、メインクラスおよびサブクラスが左からこの順番でスラッシュ記号を挟んで並んだ名称（図６に示される例では「エルフ／ロイヤル」）が使用される。デフォルトのデッキの名称におけるメインクラスおよびサブクラスの並び順を固定しておけば、カード枚数が相対的に多いメインクラスがどちらでカード枚数が相対的に少ないサブクラスがどちらであるかをデフォルトのデッキの名称から容易に識別することが可能となる。

【0048】

クラス入替ボタン６５０は、メインクラスおよびサブクラスを入れ替える操作のためにクラス選択画面に戻る手間を軽減するために、デッキ編成画面上でメインクラスおよびサブクラスを入れ替える操作を受け付ける。クラス入替ボタン６５０に対する操作（たとえばタッチ操作）が実行されると、次の図７に示されるような入替確認画像がデッキ編成画面上にポップアップ的に表示される。

【0049】

図７は、実施形態にかかるメインクラスおよびサブクラスの入れ替え時に表示される入替確認画像の一例を示した例示的かつ模式的な図である。

【0050】

図７に示される画像７００は、入替確認画像の一例である。この画像７００には、メインクラスおよびサブクラスの入れ替えを実行して問題ないかの確認をユーザに促すメッセージが表示される。

【0051】

また、画像７００は、実行ボタン７１０と、キャンセルボタン７２０と、を含んでいる。キャンセルボタン７２０に対する操作（たとえばタッチ操作）が実行された場合、図６に示されるようなデッキ編成画面が再び表示される。一方、実行ボタン７１０に対する操作（たとえばタッチ操作）が実行された場合、図６に示される例に対してメインクラスおよびサブクラスの入れ替えが施された、次の図８に示されるようなデッキ編成画面が表示される。

【0052】

図８は、実施形態にかかる、図６に示される例に対してメインクラスおよびサブクラスの入れ替えが施されたデッキ編成画面を示した例示的かつ模式的な図である。

【0053】

図８に示される画像８００は、図６に示される例に対してメインクラスおよびサブクラスの入れ替えが施されたデッキ編成画面である。この画像８００は、図６に示される画像６００と同様の画面構成を有している。ただし、この画像８００においては、メインクラスおよびサブクラスの入れ替えに応じて、第３領域６４０に表示されたデッキの名称（「ロイヤル／エルフ」）が、図６に示される画像６００の第３領域６４０に表示されたデッキの名称（「エルフ／ロイヤル」）に対して、メインクラスおよびサブクラスの配置順が逆になっている。

【0054】

図４に戻り、Ｓ４０４において、受付処理部２０１は、デッキ編成画面を介したデッキの保存操作、たとえば上記の保存ボタン６３０に対するタッチ操作が実行されたか否かを判定する。Ｓ４０４において、保存操作が実行されていないと判定された場合、Ｓ４０３に処理が戻り、受付処理部２０１は、デッキ編成画面を介したユーザの操作の入力を引き続き受け付ける。

【0055】

一方、Ｓ４０４において、保存操作が実行されたと判定された場合、Ｓ４０５に処理が進む。そして、Ｓ４０５以降において、デッキ内のカードの枚数が予め決められた条件を満たすか否かを判定するための所定の判定処理が実行される。

【0056】

より具体的に、Ｓ４０５において、管理処理部２０２は、デッキに含まれる全体のカードの枚数が４０枚以上であるか否かを判定する。なお、４０という数字は、デッキを編成するカードの必要十分な枚数として予め決められた上記の所定数に対応する。いうまでもなく、４０という数字は一例であり、実施形態では、所定数として４０以外の数字が使用されてもよい。また、実施形態では、所定数が、たとえば３９～４１などのような、上限値と下限値とを有する任意の幅を持った数の範囲として設定されてもよい。

【0057】

Ｓ４０５において、デッキに含まれる全体のカードの枚数が４１枚未満であると判定された場合、Ｓ４０６に処理が進む。そして、Ｓ４０６において、管理処理部２０２は、デッキに含まれる全体のカードの枚数が４１枚未満であるか否か、つまりデッキが所定数ちょうどのカードを含んでいるか否かを判定する。

【0058】

Ｓ４０６において、デッキに含まれる全体のカードの枚数が４１枚未満であると判定された場合、デッキに含まれる全体のカードの枚数に関する条件は満たされている。この場合、Ｓ４０７以降の処理により、クラスごとに予め決められた上記の最低数に関する条件が満たされているか否かを判定するための処理が実行される。

【0059】

より具体的に、Ｓ４０７において、管理処理部２０２は、デッキに含まれるメインクラスのカードの枚数が２４枚以上であるか否かを判定する。なお、２４という数字は、デッキ内に最低限含まれる必要があるメインクラスのカードの枚数として予め決められた上記の最低数に対応する。いうまでもなく、２４という数字は一例であり、実施形態では、メインクラスのカードの最低数として２４以外の数字が使用されてもよい。

【0060】

Ｓ４０７において、メインクラスのカードの枚数が２４枚以上であると判定された場合、Ｓ４０８に処理が進む。そして、Ｓ４０８において、管理処理部２０２は、デッキに含まれるサブクラスのカードの枚数が９枚以上であるか否かを判定する。なお、９という数字は、デッキ内に最低限含まれる必要があるサブクラスのカードの枚数として予め決められた上記の最低数に対応する。いうまでもなく、９という数字は一例であり、実施形態では、メインクラスのカードの最低数よりも小さい数字であれば、サブクラスのカードの最低数として９以外の数字が使用されてもよい。

【0061】

ここで、上記の例では、メインクラスのカードの最低数が２４であり、サブクラスのカードの最低数が９であり、両者の和（２４＋９）としての３３という数字は、所定数としての４０という数字よりも小さい。このため、実施形態では、最大で７枚分、メインクラスにもサブクラスにも該当しない上記の「ニュートラル」と呼ばれる特性を持つカードをデッキに含めることも可能である。これにより、ゲーム性がさらに向上する。

【0062】

ところで、実施形態は、デッキを編成する際に、インターネットなどで公開されている他者が編成したデッキを流用することが可能なように構成されている。しかしながら、他者が編成したデッキには、自分が所有していないカードが含まれている可能性があり、自分が所有していないカードを含むデッキは、対戦ゲームに使用することができない。このため、自分が所有しているカードのみによってデッキが編成されているか否かをチェックすることが望まれる。

【0063】

そこで、Ｓ４０８において、メインクラスのカードの枚数が２４枚以上であると判定された場合、Ｓ４０９に処理が進む。そして、Ｓ４０９において、管理処理部２０２は、保存しようとしているデッキが所有しているカードのみによって編成されているか否かを判定する。

【0064】

Ｓ４０９において、デッキが所有しているカードのみによって編成されていると判定された場合、対戦ゲームに使用可能なデッキが編成されていると判定できる。この場合、Ｓ４１０に処理が進む。そして、Ｓ４１０において、管理処理部２０２は、編成されたデッキに関するデッキ情報を保存し、保存されたデッキ情報をサーバ装置１２０と共有する。

【0065】

なお、Ｓ４１０においてデッキ情報の保存が実行される場合、それに先立って、デッキ情報の保存を確定して問題ないかの確認をユーザに促すことができれば望ましい。したがって、実施形態において、表示処理部２０４は、デッキ情報の保存に先立って、次の図９に示されるような保存確認画像を表示する。そして、受付処理部２０１は、保存確認画像を介したユーザの操作の入力を受け付ける。

【0066】

図９は、実施形態にかかる保存確認画像の一例を示した例示的かつ模式的な図である。

【0067】

図９に示される画像９００は、保存確認画像の一例である。この画像９００には、デッキの名称の入力を促すメッセージが表示される。

【0068】

また、画像９００は、入力されたデッキの名称が表示される領域９１０と、決定ボタン９２０と、キャンセルボタン７２０と、を含んでいる。これにより、ユーザは、領域９１０を確認しながらデッキの名称を入力した上で、決定ボタン９２０の操作（たとえばタッチ操作）を実行することで、デッキ情報の保存を確定させることが可能である。

【0069】

ここで、図４に戻り、上記のＳ４０５～Ｓ４０９において各条件が満たされない場合、その旨をユーザに通知することが望まれる。

【0070】

そこで、実施形態では、上記のＳ４０５～Ｓ４０９において各条件が満たされない場合、Ｓ４１１に処理が進む。そして、Ｓ４１１において、表示処理部２０４は、下記の図１０～図１４に示されるような保存アラート画像を表示することで、条件を満たさないデッキが保存されようとしている旨をユーザに通知する。そして、受付処理部２０１は、保存アラート画像を介したユーザの操作の入力を受け付ける。

【0071】

図１０は、実施形態にかかる保存アラート画像の一例を示した例示的かつ模式的な図である。

【0072】

図１０に示される画像１０００は、上記のＳ４０５の条件が満たされない場合に表示される保存アラート画像の一例である。この画像１０００には、上記のＳ４０５の条件を満たさないデッキが保存されようとしている旨をユーザに通知するメッセージと、条件を満たさないことを承知の上でデッキを保存するか否かをユーザに確認するメッセージと、が表示される。

【0073】

また、画像１０００は、保存ボタン１０１０と、キャンセルボタン１０２０と、を含んでいる。これにより、ユーザは、保存ボタン１０１０の操作（たとえばタッチ操作）を実行することで、上記のＳ４０５の条件を満たさないことを承知の上でデッキの保存を確定させることが可能である。なお、キャンセルボタン１０２０の操作（たとえばタッチ操作）を実行された場合は、図６に示されるようなデッキ編成画面が再び表示される。

【0074】

また、図１１は、実施形態にかかる保存アラート画像の図１０とは異なる一例を示した例示的かつ模式的な図である。

【0075】

図１１に示される画像１１００は、上記のＳ４０６の条件が満たされない場合に表示される保存アラート画像の一例である。この画像１１００には、上記のＳ４０６の条件を満たさないデッキが保存されようとしている旨をユーザに通知するメッセージと、条件を満たさないことを承知の上でデッキを保存するか否かをユーザに確認するメッセージと、が表示される。

【0076】

また、画像１１００は、保存ボタン１１１０と、キャンセルボタン１１２０と、を含んでいる。これにより、ユーザは、保存ボタン１１１０の操作（たとえばタッチ操作）を実行することで、上記のＳ４０６の条件を満たさないことを承知の上でデッキの保存を確定させることが可能である。なお、キャンセルボタン１１２０の操作（たとえばタッチ操作）を実行された場合は、図６に示されるようなデッキ編成画面が再び表示される。

【0077】

また、図１２は、実施形態にかかる保存アラート画像の図１０および図１１とは異なる一例を示した例示的かつ模式的な図である。

【0078】

図１２に示される画像１２００は、上記のＳ４０７の条件が満たされない場合に表示される保存アラート画像の一例である。この画像１２００には、上記のＳ４０７の条件を満たさないデッキが保存されようとしている旨をユーザに通知するメッセージと、条件を満たさないことを承知の上でデッキを保存するか否かをユーザに確認するメッセージと、が表示される。

【0079】

また、画像１２００は、保存ボタン１２１０と、キャンセルボタン１２２０と、を含んでいる。これにより、ユーザは、保存ボタン１２１０の操作（たとえばタッチ操作）を実行することで、上記のＳ４０７の条件を満たさないことを承知の上でデッキの保存を確定させることが可能である。なお、キャンセルボタン１２２０の操作（たとえばタッチ操作）を実行された場合は、図６に示されるようなデッキ編成画面が再び表示される。

【0080】

また、図１３は、実施形態にかかる保存アラート画像の図１０～図１２とは異なる一例を示した例示的かつ模式的な図である。

【0081】

図１３に示される画像１３００は、上記のＳ４０８の条件が満たされない場合に表示される保存アラート画像の一例である。この画像１３００には、上記のＳ４０８の条件を満たさないデッキが保存されようとしている旨をユーザに通知するメッセージと、条件を満たさないことを承知の上でデッキを保存するか否かをユーザに確認するメッセージと、が表示される。

【0082】

また、画像１３００は、保存ボタン１３１０と、キャンセルボタン１３２０と、を含んでいる。これにより、ユーザは、保存ボタン１３１０の操作（たとえばタッチ操作）を実行することで、上記のＳ４０８の条件を満たさないことを承知の上でデッキの保存を確定させることが可能である。なお、キャンセルボタン１３２０の操作（たとえばタッチ操作）を実行された場合は、図６に示されるようなデッキ編成画面が再び表示される。

【0083】

また、図１４は、実施形態にかかる保存アラート画像の図１０～図１３とは異なる一例を示した例示的かつ模式的な図である。

【0084】

図１４に示される画像１４００は、上記のＳ４０９の条件が満たされない場合に表示される保存アラート画像の一例である。この画像１４００には、上記のＳ４０９の条件を満たさないデッキが保存されようとしている旨をユーザに通知するメッセージと、条件を満たさないことを承知の上でデッキを保存するか否かをユーザに確認するメッセージと、が表示される。

【0085】

また、画像１４００は、保存ボタン１４１０と、キャンセルボタン１４２０と、を含んでいる。これにより、ユーザは、保存ボタン１４１０の操作（たとえばタッチ操作）を実行することで、上記のＳ４０９の条件を満たさないことを承知の上でデッキの保存を確定させることが可能である。なお、キャンセルボタン１４２０の操作（たとえばタッチ操作）を実行された場合は、図６に示されるようなデッキ編成画面が再び表示される。

【0086】

図４に戻り、Ｓ４１１の処理が実行されると、Ｓ４１２に処理が進む。そして、Ｓ４１２において、受付処理部２０１は、保存操作、たとえば上記の保存ボタン１０１０、１１１０、１２１０、１３１０、または１４１０の操作（たとえばタッチ操作）、が実行されたか否かを判定する。

【0087】

Ｓ４１１において、保存操作が実行されていない、つまり上記のキャンセルボタン１０２０、１１２０、１２２０、１３２０、または１４２０の操作（たとえばタッチ操作）が実行されたと判定された場合、上記のＳ４０３に処理が戻る。一方、Ｓ４１１において、保存操作が実行されたと判定された場合、上記のＳ４１０に処理が進む。

【0088】

Ｓ４１０の処理が完了すると、図４に示される一連の処理、つまり図３に示されるＳ３１２の処理が終了する。

【0089】

ところで、上記のＳ４０５～Ｓ４０９の条件は、図６または図８に示されるデッキ編成画面における自動編成ボタン６６０の操作（たとえばタッチ操作）に応じてデッキが自動で編成される場合にも考慮されうる。つまり、実施形態では、自動編成ボタン６６０の操作が実行されると、上記のＳ４０５～Ｓ４０９の条件が全て満たされるように、所有している複数のカードから所定数のカードを自動で選択し、デッキを編成する。どのカードが選択されるかは、対戦ゲームにおいてカードをプレイするために必要となるプレイポイントとしてカードごとに予め決められたコスト、および対戦ゲームの運営者が全カードの使用率などに基づいて各カードに対して任意で設定した優先度なども考慮されうる。

【0090】

なお、デッキに有効期限のあるカードが含まれている場合、デッキが編成されてから当該デッキを使用して実際に対戦ゲームがプレイされるまでの期間が長期間にわたると、有効期限切れにより、実際に対戦ゲームがプレイされる際にデッキが使用不可能になる可能性もある。

【0091】

そこで、実施形態において、上記のＳ４０５～Ｓ４０９の条件の判定は、対戦ゲームの開始時、つまり図３に示されるＳ３１３およびＳ３２３に先立って、サーバ装置１２０側でも実行されうる。そして、サーバ装置１２０は、デッキが使用不可能な場合、その旨を端末装置１１０に通知する。このようにすれば、使用不可能なデッキで対戦ゲームがプレイされるのを回避することが可能である。

【0092】

なお、実施形態において、デッキに含まれるカードのクラスは、デッキの編成時のみならず、対戦ゲームの開始時（開始前も含みうる）および開始後においてもユーザが確認可能であることが望ましい。このとき、自分のデッキに含まれるカードのクラスのみならず、対戦相手のデッキに含まれるカードのクラスをも確認可能であることが望ましい。そこで、実施形態において、表示処理部２０４は、下記の図１５～図２１に示されるような画像（画面）により、デッキに含まれるカードのクラスを表示しうる。

【0093】

たとえば、実施形態において、表示処理部２０４は、対戦ゲームの開始時に、次の図１５に示されるような対戦開始画面を表示し、当該対戦開始画面上に、自分のデッキに含まれるカードのクラスと、対戦相手のデッキに含まれるカードのクラスと、を表示しうる。

【0094】

まず、図１５は、実施形態にかかる対戦開始画面の一例を示した例示的かつ模式的な図である。

【0095】

図１５に示される画像１５００は、対戦開始画面の一例である。この画像１５００は、自分のデッキに含まれるカードのクラスが表示される第１領域１５１０と、対戦相手のデッキに含まれるカードのクラスが表示される第２領域１５２０と、を含む。

【0096】

図１５に示される例では、デッキに含まれるカードのクラスが、メインクラスを示す文字およびサブクラスを示す文字が左からこの順番でスラッシュ記号を挟んで並んだ形（「エルフ／ビショップ」、「エルフ／ネメシス」）で表示されている。しかしながら、実施形態において、デッキに含まれるカードのクラスは、次の図１６に示される例のように、必ずしも文字として表示されていなくてもよい。

【0097】

図１６は、実施形態にかかる対戦開始画面の図１５とは異なる一例を示した例示的かつ模式的な図である。

【0098】

図１６に示される画像１６００は、デッキに含まれるカードのクラスが文字以外の情報として表示された対戦開始画面の一例である。この画像１６００は、自分のデッキに含まれるカードのクラスが表示される第１領域１６１０と、対戦相手のデッキに含まれるカードのクラスが表示される第２領域１６２０と、を含む。

【0099】

第１領域１６１０には、自分のデッキに含まれるカードのメインクラスとしての「エルフ」を示す画像１６１１と、自分のデッキに含まれるカードのサブクラスとしての「ビショップ」を示す画像１６１２と、が左からこの順番で並んで表示されている。また、第２領域１６２０には、対戦相手のデッキに含まれるカードのメインクラスとしての「エルフ」を示す画像１６２１と、対戦相手のデッキに含まれるカードのサブクラスとしての「ネメシス」を示す画像１６２２と、が左からこの順番で並んで表示されている。

【0100】

図１６に示される例では、デッキに含まれるカードのクラスが画像的に表示されている。しかしながら、実施形態において、デッキに含まれるカードのクラスは、次の図１７に示される例のように、文字と画像との組み合わせとして表示されてもよい。

【0101】

図１７は、実施形態にかかる対戦開始画面の図１５および図１６とは異なる一例を示した例示的かつ模式的な図である。

【0102】

図１７に示される画像１７００は、デッキに含まれるカードのクラスが文字および図形の組み合わせの情報として表示された対戦開始画面の一例である。この画像１７００は、自分のデッキに含まれるカードのクラスが表示される第１領域１７１０と、対戦相手のデッキに含まれるカードのクラスが表示される第２領域１７２０と、を含む。

【0103】

第１領域１７１０には、自分のデッキに含まれるカードのメインクラスとしての「エルフ」を示す文字と、自分のデッキに含まれるカードのメインクラスとしての「エルフ」を示す画像１７１１と、自分のデッキに含まれるカードのサブクラスとしての「ビショップ」を示す画像１７１２と、が左からこの順番で並んで表示されている。また、第２領域１７２０には、対戦相手のデッキに含まれるカードのメインクラスとしての「エルフ」を示す文字と、対戦相手のデッキに含まれるカードのメインクラスとしての「エルフ」を示す画像１７２１と、対戦相手のデッキに含まれるカードのサブクラスとしての「ネメシス」を示す画像１７２２と、が左からこの順番で並んで表示されている。

【0104】

図１７に示される例では、メインクラスのみが文字として表示され、サブクラスは文字として表示されていないが、実施形態では、メインクラスとサブクラスとの両方が文字として表示されてもよい。

【0105】

また、実施形態において、表示処理部２０４は、対戦ゲームの開始後に、下記の図１８に示されるような対戦画面を表示し、当該対戦画面上に、デッキに含まれるカードのクラスに関連付けられた補足情報を表示することで、デッキに含まれるカードのクラスをユーザが確認することを可能としうる。補足情報とは、クラスごとに予め決められた能力などを示す情報である。

【0106】

図１８は、実施形態にかかる対戦画面の一例を示した例示的かつ模式的な図である。

【0107】

図１８に示される画像１８００は、対戦画面の一例である。この画像１６００は、自分のデッキに含まれるカードのメインクラスとしての「ネクロマンサー」に関連付けられた補足情報としての第１情報１８１１と、自分のデッキに含まれるカードのサブクラスとしての「エルフ」に関連付けられた補足情報としての第２情報１８１２と、を含む。これにより、ユーザは、自分のデッキに含まれるカードのメインクラスおよびサブクラスと、当該メインクラスおよびサブクラスの能力と、を対戦ゲームのプレイ中に容易に確認することが可能である。

【0108】

なお、図１８に示される例では、対戦相手のデッキに含まれるカードのクラス（メインクラスおよびサブクラス）の補足情報が対戦画面上に表示されていない。しかしながら、実施形態では、対戦相手のデッキに含まれるカードのクラスの補足情報も対戦画面上に表示されうる。この場合、ユーザは、対戦相手側の補足情報を確認することで、対戦相手のデッキに含まれるクラスを（間接的に）把握することが可能である。

【0109】

また、実施形態は、対戦相手のデッキに含まれるカードのクラスを、たとえば次の図１９に示されるような態様で対戦画面上に表示することも可能である。

【0110】

図１９は、実施形態にかかる対戦画面の図１８とは異なる一例を示した例示的かつ模式的な図である。

【0111】

図１９に示される画像１９００は、対戦相手のデッキに含まれるカードのクラスのうちメインクラスのみが表示された対戦画面の一例である。この画像１９００は、対戦相手のデッキに含まれるカードのメインクラスとしての「エルフ」を示す文字が表示された領域１９１０を含む。これにより、ユーザは、対戦相手のデッキに含まれるカードのメインクラスを対戦ゲームのプレイ中に容易に確認することが可能である。

【0112】

なお、図１９に示される例では、対戦相手のデッキに含まれるカードのサブクラスが対戦画面上に表示されていない。しかしながら、実施形態では、次の図２０に示されるように、対戦相手のデッキに含まれるカードのメインクラスおよびサブクラスの両方を対戦画面上に表示することも可能である。

【0113】

図２０は、実施形態にかかる対戦画面の図１８および図１９とは異なる一例を示した例示的かつ模式的な図である。

【0114】

図２０に示される画像２０００は、対戦相手のデッキに含まれるカードのメインクラスおよびサブクラスの両方が表示された対戦画面の一例である。この画像２０００は、対戦相手のデッキに含まれるカードのメインクラスとしての「エルフ」を示す文字と、対戦相手のデッキに含まれるカードのサブクラスとしての「ネメシス」を示す文字と、が左からこの順番でスラッシュ記号を挟んで表示された領域１９１０を含む。これにより、ユーザは、対戦相手のデッキに含まれるカードのメインクラスおよびサブクラスの両方を対戦ゲームのプレイ中に容易に確認することが可能である。

【0115】

さらに、実施形態では、次の図２１に示されるように、デッキに含まれるカードのクラスを、対戦ゲームの開始後の一時中断時に表示される中断画面上に表示することも可能である。なお、中断画面は、対戦画面上に設けられる中断ボタン（不図示）の操作（たとえばタッチ操作）に応じて表示されうる。

【0116】

図２１は、実施形態にかかる中断画面の一例を示した例示的かつ模式的な図である。

【0117】

図２１に示される画像２１００は、中断画面の一例である。この画像２１００は、第１領域２１１０と、第２領域２１２０と、を含む。第１領域２１１０には、自分のデッキに含まれるカードのメインクラスとしての「エルフ」を示す文字と、自分のデッキに含まれるカードのサブクラスとしての「ビショップ」を示す文字と、が左からこの順番でスラッシュ記号を挟んで並んで表示されている。また、第２領域２１２０には、対戦相手のデッキに含まれるカードのメインクラスとしての「エルフ」を示す文字と、対戦相手のデッキに含まれるカードのサブクラスとしての「ネメシス」を示す文字と、が左からこの順番でスラッシュ記号を挟んで並んで表示されている。これにより、ユーザは、自分のデッキに含まれるカードのメインクラスおよびサブクラスと、対戦相手のデッキに含まれるカードのメインクラスおよびサブクラスと、の全てを対戦ゲームの中断中に容易に確認することが可能である。

【0118】

以上説明したように、実施形態にかかる端末装置１１０は、各々にクラスが対応付けられた複数のカードから選択された所定数のカードを含むデッキを使用した対戦ゲームをユーザに提供するように構成される。端末装置１１０は、受付処理部２０１と、管理処理部２０２と、表示処理部２０４と、を備える。受付処理部２０１は、対戦ゲームの開始前に、当該対戦ゲームに使用されるデッキに含ませるカードの複数のクラスのユーザによる選択を受け付けるように構成される。管理処理部２０２は、デッキにおいて、ユーザにより選択された複数のクラスの各クラスのカードの個数がクラスごとに予め決められた最低数以上になるようにデッキを管理する。表示処理部２０４は、ユーザにより選択された複数のクラスと、ユーザの対戦相手により使用されるデッキに含まれる所定数のカードの複数のクラスと、を表示するように構成される。

【0119】

上記の構成によれば、ユーザは、ユーザにより選択された複数のクラスと、ユーザの対戦相手により使用されるデッキに含まれる所定数のカードの複数のクラスと、を考慮しながら対戦ゲームをプレイすることになる。したがって、たとえば単一のクラスのカードを使用してデッキを編成する必要があるという制限が設けられている場合と異なり、クラスに関する戦略性がより向上した対戦ゲームを提供することができる。

【0120】

たとえば、実施形態において、複数のクラスは、メインクラスとサブクラスとを含み、メインクラスの最低数は、サブクラスの最低数よりも大きい。このような構成によれば、ユーザは、メインクラスおよびサブクラスの各々の最低数を考慮して戦略的にデッキを編成する必要があるため、対戦ゲームの戦略性をより向上させることができる。

【0121】

また、実施形態において、表示処理部２０４は、対戦ゲームの開始時に表示される対戦開始画面上に、ユーザにより選択された複数のクラスと、対戦相手により使用されるデッキに含まれる所定数のカードが有する複数のクラスと、を示す文字または画像を表示しうる（たとえば図１５～図１７参照）。このような構成によれば、どのようなデッキ間で対戦ゲームがプレイされるかを対戦ゲームの開始時に容易に確認することができる。

【0122】

また、実施形態において、表示処理部２０４は、対戦ゲームの開始後に表示される対戦画面上に、ユーザにより選択された複数のクラスにそれぞれ関連付けられた複数の補足情報を表示しうる（たとえば図１８参照）。このような構成によれば、自分のデッキに関する補足情報を対戦ゲームのプレイ中に容易に確認することができる。

【0123】

また、実施形態において、表示処理部２０４は、対戦ゲームの開始後に表示される対戦画面上に、対戦相手により使用されるデッキに含まれる所定数のカードの複数のクラスの全て、または当該所定数のカードのうち最も個数が多いカードの１つのクラス、を示す文字または画像を表示しうる（たとえば図１９および図２０参照）。このような構成によれば、対戦相手が使用するクラスの少なくとも一部を対戦ゲームのプレイ中に容易に確認することができる。

【0124】

また、実施形態において、表示処理部２０４は、対戦ゲームの開始後の一時中断時に表示される中断画面上に、ユーザにより選択された複数のクラスと、対戦相手により使用されるデッキに含まれる所定数のカードの複数のクラスと、を示す文字または画像を表示しうる（たとえば図２１参照）。このような構成によれば、どのようなデッキ間で対戦ゲームがプレイされているかを対戦ゲームの中断時に容易に確認することができる。

【0125】

また、実施形態において、表示処理部２０４は、ユーザにより選択された複数のクラスを、クラスごとのカードの個数の大小関係を識別可能な態様で表示しうるとともに、対戦相手により使用されるデッキに含まれる所定数のカードの複数のクラスを、クラスごとのカードの個数の大小関係を識別可能な態様で表示しうる。このような構成によれば、自分のデッキに含まれるカードのクラスごとの枚数を確認するとともに、対戦相手のデッキに含まれるカードのクラスごとの枚数をある程度予測しながら、対戦ゲームをプレイすることができる。したがって、対戦ゲームの戦略性をより向上させることができる。

【0126】

最後に、上述した実施形態にかかる端末装置１１０およびサーバ装置１２０のハードウェア構成について説明する。実施形態にかかる認証モジュールは、たとえば次の図２２に示されるような、一般的なコンピュータと同等のハードウェア構成を有する情報処理装置２２００として構成される。

【0127】

実施形態にかかる端末装置１１０およびサーバ装置１２０を構成する情報処理装置２２００のハードウェア構成を示した例示的かつ模式的なブロック図である。

【0128】

図２２に示されるように、情報処理装置２２００は、プロセッサ２２１０と、メモリ＠２２０と、ストレージ２２３０と、入出力インターフェース（Ｉ／Ｆ）２２４０と、通信インターフェース（Ｉ／Ｆ）２２５０と、を備えている。これらのハードウェアは、バス２２６０に接続されている。

【0129】

プロセッサ２２１０は、たとえばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）として構成され、情報処理装置２２００の各部の動作を統括的に制御する。

【0130】

メモリ２２２０は、たとえばＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）およびＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を含み、プロセッサ２２１０により実行されるプログラムなどの各種のデータの揮発的または不揮発的な記憶、およびプロセッサ２２１０がプログラムを実行するための作業領域の提供などを実現する。

【0131】

ストレージ２２３０は、たとえばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）またはＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）を含み、各種のデータを不揮発的に記憶する。

【0132】

入出力インターフェース２２４０は、たとえばタッチパネル、キーボード、およびマウスなどのような入力装置から情報処理装置２２００へのデータの入力と、たとえば情報処理装置２２００からディスプレイおよびスピーカなどのような出力装置へのデータの出力と、を制御する。

【0133】

通信インターフェース２２５０は、情報処理装置２２００が他の装置と通信を実行することを可能にする。

【0134】

実施形態にかかる端末装置１１０が有する機能的構成（図２参照）は、プロセッサ２２１０がメモリ２２２０またはストレージ２２３０に予め記憶されたプログラムを実行した結果として、ハードウェアとソフトウェアとの協働による機能モジュール群として実現される。ただし、実施形態では、図２に示される機能モジュール群のうち一部または全部が、専用に設計された回路（ｃｉｒｃｕｉｔｒｙ）のようなハードウェアのみによって実現されてもよい。さらに、実施形態では、図２に示される機能モジュール群のうち少なくとも一部がサーバ装置１２０側に実現されてもよい。

【0135】

なお、上述したプログラムは、必ずしもメモリ２２２０またはストレージ２２３０に予め記憶されている必要はない。たとえば、上述したプログラムは、フレキシブルディスク（ＦＤ）のような各種の磁気ディスク、またはＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）のような各種の光ディスクなどといった、コンピュータで読み取り可能な媒体にインストール可能な形式または実行可能な形式で記録されたコンピュータプログラムプロダクトとして提供されてもよい。

【0136】

また、上述したプログラムは、インターネットなどのネットワーク経由で提供または配布されてもよい。すなわち、上述したプログラムは、インターネットなどのネットワークに接続されたコンピュータ上に格納された状態で、ネットワーク経由でのダウンロードを受け付ける、といった形で提供されてもよい。

【0137】

以上、本開示のいくつかの実施形態およびその変形を説明したが、これらの実施形態およびその変形は、例として提示したものであり、発明の範囲を限定することは意図していない。これらの新規な実施形態およびその変形は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これらの実施形態およびその変形は、発明の範囲または要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲とに含まれる。

【符号の説明】

【0138】

１１０ 端末装置
２０１ 受付処理部
２０２ 管理処理部
２０４ 表示処理部

【要約】

【課題】属性に関する戦略性がより向上した対戦ゲームを提供する。
【解決手段】本開示の一例としての認証システムは、各々に属性が対応付けられた複数のゲーム媒体から選択された所定数のゲーム媒体を含むデッキを使用した対戦ゲームをユーザに提供することをコンピュータに実行させるためのプログラムであって、対戦ゲームの開始前に、当該対戦ゲームに使用されるデッキに含ませるゲーム媒体の複数の属性のユーザによる選択を受け付けることと、デッキにおいて、ユーザにより選択された複数の属性の各属性のゲーム媒体の個数が属性ごとに予め決められた最低数以上になるようにデッキを管理することと、ユーザにより選択された複数の属性と、ユーザの対戦相手により使用されるデッキに含まれる所定数のゲーム媒体の複数の属性と、を表示することと、をコンピュータに実行させるための、プログラムである。
【選択図】図２

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】