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

Abstract

【課題】ゲームの興趣性を向上させる。【解決手段】ゲームプログラム（１３１）は、プロセッサ（１０）に、ゲームに登場する複数のキャラクタのうちの少なくとも１つの第１キャラクタに対する、ユーザの第１入力操作に応じて、該第１キャラクタを第１状態から第２状態へ遷移させるステップ（Ｓ１０７）と、第１キャラクタが第２状態に遷移してから、所定の時間が経過したことに応じて、第１キャラクタを第１状態に復帰させるステップ（Ｓ１１９）と、第１キャラクタが第１状態に復帰したことに応じて、第２状態であった第１キャラクタに基づくコンテンツをユーザに付与するステップ（Ｓ１２０）と、ユーザの第２入力操作に応じて、指定されたコンテンツを表示部に表示するステップ（Ｓ２０４）と、を実行させる。【選択図】図１２

Description

特許法第３０条第２項適用申請有り ・ウェブサイトのアドレス （Ａ）ｈｔｔｐｓ：／／ｔｗｉｔｔｅｒ．ｃｏｍ／ｃｏｌｏｐｌ＿ｄｒｅａｍｉｎｇ 掲載日 ２０１８年３月８日～ （Ｂ）ｈｔｔｐｓ：／／ｃｏｌｏｐｌ．ｃｏ．ｊｐ／ｄｒｅａｍｉｎｇ／ 掲載日 ２０１８年３月８日～ （Ｃ）ｈｔｔｐｓ：／／ｃｏｌｏｐｌ．ｃｏ．ｊｐ／ｎｅｗｓ／ｐｒｅｓｓｒｅｌｅａｓｅ／２０１８０５１１０１．ｐｈｐ 掲載日 ２０１８年５月１１日 （Ｄ）ｈｔｔｐｓ：／／ｃｏｌｏｐｌ．ｃｏ．ｊｐ／ｎｅｗｓ／ｐｒｅｓｓｒｅｌｅａｓｅ／２０１８年６月２５０１．ｐｈｐ 掲載日 ２０１８年６月２５日 （Ｅ）ｈｔｔｐｓ：／／ｃｏｌｏｐｌ．ｃｏ．ｊｐ／ｎｅｗｓ／ｐｒｅｓｓｒｅｌｅａｓｅ／２０１８年８月９０１．ｐｈｐ 掲載日 ２０１８年８月９日 （Ｆ）ｈｔｔｐｓ：／／ｃｏｌｏｐｌ．ｃｏ．ｊｐ／ｎｅｗｓ／ｐｒｅｓｓｒｅｌｅａｓｅ／２０１８年１１月１２０１．ｐｈｐ 掲載日 ２０１８年１１月１２日 （Ｇ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｃＪｔｈ８ｗｐ５Ｚ１Ｅ 掲載日 ２０１８年６月２１日 （Ｈ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｗＦｋＣＨ－＿ＪＬＬＵ 掲載日 ２０１８年６月２４日 （Ｉ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｆＴｗ０７０ｋＧＧＣ０ 掲載日 ２０１８年６月２４日 （Ｊ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＳＡｐ７ＣＦＺＩＩＫｗ 掲載日 ２０１８年６月２４日 （Ｋ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝Ｉ３ＯＢＬｋ１ｒＬｋｇ 掲載日 ２０１８年６月２４日 （Ｌ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｗｒＦｉＬｑｚｊｒｔ４ 掲載日 ２０１８年６月２６日 （Ｍ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＲｃＪｕ－Ｕ７Ｂ１Ｓｓ 掲載日 ２０１８年６月２７日 （Ｎ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＢＡＡＤＤ５ｐＱｖＺｋ 掲載日 ２０１８年７月１日 （Ｏ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｊＭ２ｐＰＺＤ４ｂａＩ 掲載日 ２０１８年７月２日

特許法第３０条第２項適用申請有り （Ｐ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｌＨｎＪＪＦｚＦｙｘ０ 掲載日 ２０１８年７月３日 （Ｑ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝９９ＸＵＫ３３ｉｘＦｗ 掲載日 ２０１８年７月４日 （Ｒ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝Ｘ４８ＵＤｉＷＭｋＺ８ 掲載日 ２０１８年７月５日 （Ｓ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＲｎＬＳＯｄ＿Ｂｓ５Ｉ 掲載日 ２０１８年７月６日 （Ｔ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｔ４ＨａｆＳ４ＢＰＨｃ 掲載日 ２０１８年７月７日 （Ｕ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｒｕｃ２ＦＣＮｇｘＮＩ 掲載日 ２０１８年７月１２日 （Ｖ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝５Ｑ０ｘＥｐｎ２Ｎ００ 掲載日 ２０１８年７月２４日 （Ｗ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｃＷｇＱＱ４Ｊｉ２ｑｋ 掲載日 ２０１８年７月２４日 （Ｘ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｕ＿ｑｅＪＸ９ｖＦ９４ 掲載日 ２０１８年８月１０日 （Ｙ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｕｓｚＪ５Ｚ４Ｈ６Ｏｇ 掲載日 ２０１８年１０月１０日 （Ｚ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＫＸＬｋｄ－ｅＥ９－ｓ 掲載日 ２０１８年１０月１７日 （ＡＡ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ＣＩ６ＡＬ１ｕｔｅ０ｇ 掲載日 ２０１８年１０月２６日 （ＡＢ）ｈｔｔｐｓ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｉｔ６ｒ８ＱｊＢＳＶＭ 掲載日 ２０１８年１１月１１日 （ＡＣ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｗａｔｃｈ／ｌｖ３１３９３９７６５ 掲載日 ２０１８年７月１日

特許法第３０条第２項適用申請有り （ＡＤ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｗａｔｃｈ／ｌｖ４２１９６５３ 掲載日 ２０１８年７月２４日 （ＡＥ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｗａｔｃｈ／ｌｖ３１４９２３６０８ 掲載日 ２０１８年８月２２日 （ＡＦ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｇａｔｅ／ｌｖ３１５３７７０３５ 掲載日 ２０１８年９月１９日 （ＡＧ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｇａｔｅ／ｌｖ３１５９９４９２９ 掲載日 ２０１８年１０月１９日 （ＡＨ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｇａｔｅ／ｌｖ３１６６３７３５２ 掲載日 ２０１８年１１月２８日 （ＡＩ）ｈｔｔｐｓ：／／ｌｉｖｅ．ｎｉｃｏｖｉｄｅｏ．ｊｐ／ｇａｔｅ／ｌｖ３１８０２２２４４ 掲載日 ２０１９年１月２９日 ・アプリケーション名：「ＤＲＥＡＭ！ｉｎｇ」 アプリケーションバージョンおよびリリース・アップデート日：Ｖｅｒ．１．０．０ ２０１８年８月８日 Ｖｅｒ．１．０．１ ２０１８年８月１３日 Ｖｅｒ．１．０．２ ２０１８年８月１７日 Ｖｅｒ．１．０．３ ２０１８年８月２２日 Ｖｅｒ．１．０．４ ２０１８年８月３１日 Ｖｅｒ．１．０．５ ２０１８年９月７日 Ｖｅｒ．１．０．６ ２０１８年９月１４日 Ｖｅｒ．１．０．７ ２０１８年９月２８日 Ｖｅｒ．１．０．８ ２０１８年１０月１１日 Ｖｅｒ．１．０．９ ２０１８年１０月３０日 Ｖｅｒ．１．０．１０ ２０１８年１１月１５日 Ｖｅｒ．１．０．１１ ２０１８年１１月１６日 Ｖｅｒ．１．０．１２ ２０１８年１１月２９日 Ｖｅｒ．１．０．１３ ２０１８年１１月３０日 Ｖｅｒ．１．０．１４ ２０１８年１２月１２日 Ｖｅｒ．１．０．１５ ２０１８年１２月１８日 Ｖｅｒ．１．０．１６ ２０１９年１月１８日 Ｖｅｒ．１．０．１７ ２０１９年１月２８日 Ｖｅｒ．１．０．１８ ２０１９年２月８日 Ｖｅｒ．１．０．１９ ２０１９年２月２２日 Ｖｅｒ．１．０．２０ ２０１９年３月８日

本開示はゲームプログラム、ゲームプログラムを実行する方法および情報処理装置に関する。

例えば、特許文献１に開示されているとおり、ユーザがゲーム実行を指示した後、自動的にゲームが進行し、所定期間が経過すると、その自動進行の結果がユーザに知らされるという、いわゆる放置ゲームが、従来ユーザに広く提供されている。

特開２０１３－１２６４６２号公報 （２０１３年６月２７日公開）

ところで、キャラクタが登場するゲームにおいて、キャラクタに対する愛着を向上させる観点から放置ゲームの興趣性をさらに向上させる余地がある。

本開示の一態様は、ゲームの興趣性を向上させることを目的とする。

本開示に係るゲームプログラムは、プロセッサ、メモリおよび表示部を備えるコンピュータにより実行される。ゲームプログラムは、プロセッサに、ゲームプログラムに基づくゲームに登場する複数のキャラクタのうちの少なくとも１つの第１キャラクタに対する、ユーザの第１入力操作に応じて、該第１キャラクタを第１状態から第２状態へ遷移させるステップと、第１キャラクタが第２状態に遷移してから、所定の時間が経過したことに応じて、第１キャラクタを第１状態に復帰させるステップと、第１キャラクタが第１状態に復帰したことに応じて、第２状態であった第１キャラクタに基づくコンテンツをユーザに付与するステップと、ユーザの第２入力操作に応じて、指定されたコンテンツを表示部に表示するステップと、を実行させる。

本開示の一態様によれば、ゲームの興趣性を向上させる効果を奏する。

ゲームシステムのハードウェア構成を示す図である。 ゲームシステムで実行されるゲームのゲームサイクルの一例を説明する図である。 ユーザ端末およびサーバの機能的構成を示すブロック図である。 カードのデータ構造の一例を示す図である。 キャラクタを定義するキャラクタデータのデータ構造の一例を示す図である。 （Ａ）は、ペアパラメータテーブルのデータ構造の一例を示す図であり、（Ｂ）は、ペアパラメータＤＢのデータ構造の一例を示す図である。 ストーリーリストのデータ構造の一例を示す図である。 練習パート進行部によって実行される練習パートにおける処理の流れを示すフローチャートである。 練習パートで参照されるデッキ情報のデータ構造の一例を示す図である。 （Ａ）は、前回のセットにおいて、ユーザによって選択され、場に出されたカードの一例を示す図であり、（Ｂ）は、前回のセット終了直後の２次デッキのデッキ情報を示す図であり、（Ｃ）は、空いたポジションに補充されるカードの候補を示す図である。 （Ａ）および（Ｂ）は、ユーザ端末の表示部に表示されるステージ進行画面の一例を示す図である。 放置パート進行部が実行する放置パートのうち、実行パートの処理の流れを示すフローチャートである。 放置パート進行部が実行する放置パートのうち、実行パートの処理の流れを示すフローチャートである。 放置キャラクタ情報のデータ構造の一例を示す図である。 （Ａ）は、日記データのデータ構造の一例を示す図であり、（Ｂ）は、希少度が高い日記データのデータ構造の一例を示す図である。 表示部に表示されるキャラクタ選択画面の一例を示す図である。 （Ａ）は、表示部に表示される導入画面の一例を示す図であり、（Ｂ）は、表示部に表示される実行画面の一例を示す図である。 放置パート進行部が実行する放置パートのうち、閲覧パートの処理の流れを示すフローチャートである。 日記データベースのデータ構造の一例を示す図である。 （Ａ）は、表示部に表示される一覧画面の一例を示す図であり、（Ｂ）は、表示部に表示される日記画面の一例を示す図である。

〔実施形態１〕
本開示に係るゲームシステムは、複数のユーザにゲームを提供するためのシステムである。以下、ゲームシステムについて図面を参照しつつ説明する。なお、本発明はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が本発明に含まれることが意図される。以下の説明では、図面の説明において同一の要素には同一の符号を付し、重複する説明を繰り返さない。

＜ゲームシステム１のハードウェア構成＞
図１は、ゲームシステム１のハードウェア構成を示す図である。ゲームシステム１は図示の通り、複数のユーザ端末１００と、サーバ２００とを含む。各ユーザ端末１００は、サーバ２００とネットワーク２を介して接続する。ネットワーク２は、インターネットおよび図示しない無線基地局によって構築される各種移動通信システム等で構成される。この移動通信システムとしては、例えば、所謂３Ｇ、４Ｇ移動通信システム、ＬＴＥ（Long Term Evolution）、および所定のアクセスポイントによってインターネットに接続可能な無線ネットワーク（例えばWi-Fi（登録商標））等が挙げられる。

サーバ２００（コンピュータ、情報処理装置）は、ワークステーションまたはパーソナルコンピュータ等の汎用コンピュータであってよい。サーバ２００は、プロセッサ２０と、メモリ２１と、ストレージ２２と、通信ＩＦ２３と、入出力ＩＦ２４とを備える。サーバ２００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。

ユーザ端末１００（コンピュータ、情報処理装置）は、スマートフォン、フィーチャーフォン、ＰＤＡ（Personal Digital Assistant）、またはタブレット型コンピュータ等の携帯端末であってよい。ユーザ端末１００は、ゲームプレイに適したゲーム装置であってもよい。ユーザ端末１００は図示の通り、プロセッサ１０と、メモリ１１と、ストレージ１２と、通信インターフェース（ＩＦ）１３と、入出力ＩＦ１４と、タッチスクリーン１５（表示部）と、カメラ１７と、測距センサ１８とを備える。ユーザ端末１００が備えるこれらの構成は、通信バスによって互いに電気的に接続される。なお、ユーザ端末１００は、タッチスクリーン１５に代えて、または、加えて、ユーザ端末１００本体とは別に構成されたディスプレイ（表示部）を接続可能な入出力ＩＦ１４を備えていてもよい。

また、図１に示すように、ユーザ端末１００は、１つ以上のコントローラ１０２０と通信可能に構成されることとしてもよい。コントローラ１０２０は、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信規格に従って、ユーザ端末１００と通信を確立する。コントローラ１０２０は、１つ以上のボタン等を有していてもよく、該ボタン等に対するユーザの入力操作に基づく出力値をユーザ端末１００へ送信する。また、コントローラ１０２０は、加速度センサ、および、角速度センサ等の各種センサを有していてもよく、該各種センサの出力値をユーザ端末１００へ送信する。

なお、ユーザ端末１００がカメラ１７および測距センサ１８を備えることに代えて、または、加えて、コントローラ１０２０がカメラ１７および測距センサ１８を有していてもよい。

ユーザ端末１００は、例えばゲーム開始時に、コントローラ１０２０を使用するユーザに、該ユーザの名前またはログインＩＤ等のユーザ識別情報を、該コントローラ１０２０を介して入力させることが望ましい。これにより、ユーザ端末１００は、コントローラ１０２０とユーザとを紐付けることが可能となり、受信した出力値の送信元（コントローラ１０２０）に基づいて、該出力値がどのユーザのものであるかを特定することができる。

ユーザ端末１００が複数のコントローラ１０２０と通信する場合、各コントローラ１０２０を各ユーザが把持することで、ネットワーク２を介してサーバ２００などの他の装置と通信せずに、該１台のユーザ端末１００でマルチプレイを実現することができる。また、各ユーザ端末１００が無線ＬＡＮ（Local Area Network）規格等の無線規格により互いに通信接続する（サーバ２００を介さずに通信接続する）ことで、複数台のユーザ端末１００によりローカルでマルチプレイを実現することもできる。１台のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、ユーザ端末１００は、さらに、サーバ２００が備える後述する種々の機能の少なくとも一部を備えていてもよい。また、複数のユーザ端末１００によりローカルで上述のマルチプレイを実現する場合、複数のユーザ端末１００は、サーバ２００が備える後述する種々の機能を分散して備えていてもよい。

なお、ローカルで上述のマルチプレイを実現する場合であっても、ユーザ端末１００はサーバ２００と通信を行ってもよい。例えば、あるゲームにおける成績または勝敗等のプレイ結果を示す情報と、ユーザ識別情報とを対応付けてサーバ２００に送信してもよい。

また、コントローラ１０２０は、ユーザ端末１００に着脱可能な構成であるとしてもよい。この場合、ユーザ端末１００の筐体における少なくともいずれかの面に、コントローラ１０２０との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末１００とコントローラ１０２０とが結合している場合は、ユーザ端末１００とコントローラ１０２０とは、有線を介して信号を送受信する。

図１に示すように、ユーザ端末１００は、外部のメモリカード等の記憶媒体１０３０の装着を、入出力ＩＦ１４を介して受け付けてもよい。これにより、ユーザ端末１００は、記憶媒体１０３０に記録されるプログラム及びデータを読み込むことができる。記憶媒体１０３０に記録されるプログラムは、例えばゲームプログラムである。

ユーザ端末１００は、サーバ２００等の外部の装置と通信することにより取得したゲームプログラムをユーザ端末１００のメモリ１１に記憶してもよいし、記憶媒体１０３０から読み込むことにより取得したゲームプログラムをメモリ１１に記憶してもよい。

以上で説明したとおり、ユーザ端末１００は、該ユーザ端末１００に対して情報を入力する機構の一例として、通信ＩＦ１３、入出力ＩＦ１４、タッチスクリーン１５、カメラ１７、および、測距センサ１８を備える。入力する機構としての上述の各部は、ユーザの入力操作を受け付けるように構成された操作部と捉えることができる。

例えば、操作部が、カメラ１７および測距センサ１８の少なくともいずれか一方で構成される場合、該操作部が、ユーザ端末１００の近傍の物体１０１０を検出し、当該物体の検出結果から入力操作を特定する。一例として、物体１０１０としてのユーザの手、予め定められた形状のマーカーなどが検出され、検出結果として得られた物体１０１０の色、形状、動き、または、種類などに基づいて入力操作が特定される。より具体的には、ユーザ端末１００は、カメラ１７の撮影画像からユーザの手が検出された場合、該撮影画像に基づき検出されるジェスチャ（ユーザの手の一連の動き）を、ユーザの入力操作として特定し、受け付ける。なお、撮影画像は静止画であっても動画であってもよい。

あるいは、操作部がタッチスクリーン１５で構成される場合、ユーザ端末１００は、タッチスクリーン１５の入力部１５１に対して実施されたユーザの操作をユーザの入力操作として特定し、受け付ける。あるいは、操作部が通信ＩＦ１３で構成される場合、ユーザ端末１００は、コントローラ１０２０から送信される信号（例えば、出力値）をユーザの入力操作として特定し、受け付ける。あるいは、操作部が入出力ＩＦ１４で構成される場合、該入出力ＩＦ１４と接続されるコントローラ１０２０とは異なる入力装置（図示せず）から出力される信号をユーザの入力操作として特定し、受け付ける。

＜各装置のハードウェア構成要素＞
プロセッサ１０は、ユーザ端末１００全体の動作を制御する。プロセッサ２０は、サーバ２００全体の動作を制御する。プロセッサ１０および２０は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、およびＧＰＵ（Graphics Processing Unit）を含む。

プロセッサ１０は後述するストレージ１２からプログラムを読み出し、後述するメモリ１１に展開する。プロセッサ２０は後述するストレージ２２からプログラムを読み出し、後述するメモリ２１に展開する。プロセッサ１０およびプロセッサ２０は展開したプログラムを実行する。

メモリ１１および２１は主記憶装置である。メモリ１１および２１は、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）等の記憶装置で構成される。メモリ１１は、プロセッサ１０が後述するストレージ１２から読み出したプログラムおよび各種データを一時的に記憶することにより、プロセッサ１０に作業領域を提供する。メモリ１１は、プロセッサ１０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。メモリ２１は、プロセッサ２０が後述するストレージ２２から読み出した
各種プログラムおよびデータを一時的に記憶することにより、プロセッサ２０に作業領域を提供する。メモリ２１は、プロセッサ２０がプログラムに従って動作している間に生成した各種データも一時的に記憶する。

本実施形態においてプログラムとは、ゲームをユーザ端末１００により実現するためのゲームプログラムであってもよい。あるいは、該プログラムは、該ゲームをユーザ端末１００とサーバ２００との協働により実現するためのゲームプログラムであってもよい。なお、ユーザ端末１００とサーバ２００との協働により実現されるゲームは、一例として、ユーザ端末１００において起動されたブラウザ上で実行されるゲームであってもよい。あるいは、該プログラムは、該ゲームを複数のユーザ端末１００の協働により実現するためのゲームプログラムであってもよい。また、各種データとは、ユーザ情報およびゲーム情報などのゲームに関するデータ、ならびに、ユーザ端末１００とサーバ２００との間または複数のユーザ端末１００間で送受信する指示または通知を含んでいる。

ストレージ１２および２２は補助記憶装置である。ストレージ１２および２２は、フラッシュメモリまたはＨＤＤ（Hard Disk Drive）等の記憶装置で構成される。ストレージ１２およびストレージ２２には、ゲームに関する各種データが格納される。

通信ＩＦ１３は、ユーザ端末１００における各種データの送受信を制御する。通信ＩＦ２３は、サーバ２００における各種データの送受信を制御する。通信ＩＦ１３および２３は例えば、無線ＬＡＮ（Local Area Network）を介する通信、有線ＬＡＮ、無線ＬＡＮ、または携帯電話回線網を介したインターネット通信、ならびに近距離無線通信等を用いた通信を制御する。

入出力ＩＦ１４は、ユーザ端末１００がデータの入力を受け付けるためのインターフェースであり、またユーザ端末１００がデータを出力するためのインターフェースである。入出力ＩＦ１４は、ＵＳＢ（Universal Serial Bus）等を介してデータの入出力を行ってもよい。入出力ＩＦ１４は、例えば、ユーザ端末１００の物理ボタン、カメラ、マイク、または、スピーカ等を含み得る。サーバ２００の入出力ＩＦ２４は、サーバ２００がデータの入力を受け付けるためのインターフェースであり、またサーバ２００がデータを出力するためのインターフェースである。入出力ＩＦ２４は、例えば、マウスまたはキーボード等の情報入力機器である入力部と、画像を表示出力する機器である表示部とを含み得る。

ユーザ端末１００のタッチスクリーン１５は、入力部１５１と表示部１５２とを組み合わせた電子部品である。入力部１５１は、例えばタッチセンシティブなデバイスであり、例えばタッチパッドによって構成される。表示部１５２は、例えば液晶ディスプレイ、または有機ＥＬ（Electro-Luminescence）ディスプレイ等によって構成される。

入力部１５１は、入力面に対しユーザの操作（主にタッチ操作、スライド操作、スワイプ操作、およびタップ操作等の物理的接触操作）が入力された位置を検知して、位置を示す情報を入力信号として送信する機能を備える。入力部１５１は、図示しないタッチセンシング部を備えていればよい。タッチセンシング部は、静電容量方式または抵抗膜方式等のどのような方式を採用したものであってもよい。

図示していないが、ユーザ端末１００は、該ユーザ端末１００の保持姿勢を特定するための１以上のセンサを備えていてもよい。このセンサは、例えば、加速度センサ、または、角速度センサ等であってもよい。ユーザ端末１００がセンサを備えている場合、プロセッサ１０は、センサの出力からユーザ端末１００の保持姿勢を特定して、保持姿勢に応じた処理を行うことも可能になる。例えば、プロセッサ１０は、ユーザ端末１００が縦向きに保持されているときには、縦長の画像を表示部１５２に表示させる縦画面表示としてもよい。一方、ユーザ端末１００が横向きに保持されているときには、横長の画像を表示部に表示させる横画面表示としてもよい。このように、プロセッサ１０は、ユーザ端末１００の保持姿勢に応じて縦画面表示と横画面表示とを切り替え可能であってもよい。

カメラ１７は、イメージセンサ等を含み、レンズから入射する入射光を電気信号に変換することで撮影画像を生成する。

測距センサ１８は、測定対象物までの距離を測定するセンサである。測距センサ１８は、例えば、パルス変換した光を発する光源と、光を受ける受光素子とを含む。測距センサ１８は、光源からの発光タイミングと、該光源から発せられた光が測定対象物にあたって反射されて生じる反射光の受光タイミングとにより、測定対象物までの距離を測定する。測距センサ１８は、指向性を有する光を発する光源を有することとしてもよい。

ここで、ユーザ端末１００が、カメラ１７と測距センサ１８とを用いて、ユーザ端末１００の近傍の物体１０１０を検出した検出結果を、ユーザの入力操作として受け付ける例をさらに説明する。カメラ１７および測距センサ１８は、例えば、ユーザ端末１００の筐体の側面に設けられてもよい。カメラ１７の近傍に測距センサ１８が設けられてもよい。カメラ１７としては、例えば赤外線カメラを用いることができる。この場合、赤外線を照射する照明装置および可視光を遮断するフィルタ等が、カメラ１７に設けられてもよい。これにより、屋外か屋内かにかかわらず、カメラ１７の撮影画像に基づく物体の検出精度をいっそう向上させることができる。

プロセッサ１０は、カメラ１７の撮影画像に対して、例えば以下の（１）～（５）に示す処理のうち１つ以上の処理を行ってもよい。（１）プロセッサ１０は、カメラ１７の撮影画像に対し画像認識処理を行うことで、該撮影画像にユーザの手が含まれているか否かを特定する。プロセッサ１０は、上述の画像認識処理において採用する解析技術として、例えばパターンマッチング等の技術を用いてよい。（２）また、プロセッサ１０は、ユーザの手の形状から、ユーザのジェスチャを検出する。プロセッサ１０は、例えば、撮影画像から検出されるユーザの手の形状から、ユーザの指の本数（伸びている指の本数）を特定する。プロセッサ１０はさらに、特定した指の本数から、ユーザが行ったジェスチャを特定する。例えば、プロセッサ１０は、指の本数が５本である場合、ユーザが「パー」のジェスチャを行ったと判定する。また、プロセッサ１０は、指の本数が０本である（指が検出されなかった）場合、ユーザが「グー」のジェスチャを行ったと判定する。また、プロセッサ１０は、指の本数が２本である場合、ユーザが「チョキ」のジェスチャを行ったと判定する。（３）プロセッサ１０は、カメラ１７の撮影画像に対し、画像認識処理を行うことにより、ユーザの指が人差し指のみ立てた状態であるか、ユーザの指がはじくような動きをしたかを検出する。（４）プロセッサ１０は、カメラ１７の撮影画像の画像認識結果、および、測距センサ１８の出力値等の少なくともいずれか１つに基づいて、ユーザ端末１００の近傍の物体１０１０（ユーザの手など）とユーザ端末１００との距離を検出する。例えば、プロセッサ１０は、カメラ１７の撮影画像から特定されるユーザの手の形状の大小により、ユーザの手がユーザ端末１００の近傍（例えば所定値未満の距離）にあるのか、遠く（例えば所定値以上の距離）にあるのかを検出する。なお、撮影画像が動画の場合、プロセッサ１０は、ユーザの手がユーザ端末１００に接近しているのか遠ざかっているのかを検出してもよい。（５）カメラ１７の撮影画像の画像認識結果等に基づいて、ユーザの手が検出されている状態で、ユーザ端末１００とユーザの手との距離が変化していることが判明した場合、プロセッサ１０は、ユーザが手をカメラ１７の撮影方向において振っていると認識する。カメラ１７の撮影範囲よりも指向性が強い測距センサ１８において、物体が検出されたりされなかったりする場合に、プロセッサ１０は、ユーザが手をカメラの撮影方向に直交する方向に振っていると認識する。

このように、プロセッサ１０は、カメラ１７の撮影画像に対する画像認識により、ユーザが手を握りこんでいるか否か（「グー」のジェスチャであるか、それ以外のジェスチャ（例えば「パー」）であるか）を検出する。また、プロセッサ１０は、ユーザの手の形状とともに、ユーザがこの手をどのように移動させているかを検出する。また、プロセッサ１０は、ユーザがこの手をユーザ端末１００に対して接近させているのか遠ざけているのかを検出する。このような操作は、例えば、マウスまたはタッチパネルなどのポインティングデバイスを用いた操作に対応させることができる。ユーザ端末１００は、例えば、ユーザの手の移動に応じて、タッチスクリーン１５においてポインタを移動させ、ユーザのジェスチャ「グー」を検出する。この場合、ユーザ端末１００は、ユーザが選択操作を継続中であると認識する。選択操作の継続とは、例えば、マウスがクリックされて押し込まれた状態が維持されること、または、タッチパネルに対してタッチダウン操作がなされた後タッチされた状態が維持されることに対応する。また、ユーザ端末１００は、ユーザのジェスチャ「グー」が検出されている状態で、さらにユーザが手を移動させると、このような一連のジェスチャを、スワイプ操作（またはドラッグ操作）に対応する操作として認識することもできる。また、ユーザ端末１００は、カメラ１７の撮影画像によるユーザの手の検出結果に基づいて、ユーザが指をはじくようなジェスチャを検出した場合に、当該ジェスチャを、マウスのクリックまたはタッチパネルへのタップ操作に対応する操作として認識してもよい。

＜ゲーム概要＞
実施形態１に係るゲームシステム１がゲームプログラムに基づいて実行するゲーム（以下、本ゲーム）は、一例として、育成シミュレーションゲームである。該育成シミュレーションゲームは、一例として、アイドルを目指しているキャラクタを育成するアイドル育成シミュレーションゲームである。本ゲームでは、上述のキャラクタは、例えば、架空の世界でアイドルを目指して学校生活を送る男子高校生である。

ゲームシステム１は、特定のジャンルに限らず、あらゆるジャンルのゲームを実行するためのシステムであってもよい。例えば、テニス、卓球、ドッジボール、野球、サッカーおよびホッケーなどのスポーツを題材としたゲーム、パズルゲーム、クイズゲーム、ＲＰＧ、アドベンチャーゲーム、シューティングゲーム、シミュレーションゲーム、育成ゲーム、ならびに、アクションゲームなどであってもよい。

また、ゲームシステム１は、特定のプレイ形態に限らず、あらゆるプレイ形態のゲームを実行するためのシステムであってもよい。例えば、単一のユーザによるシングルプレイゲーム、および、複数のユーザによるマルチプレイゲーム、また、マルチプレイゲームの中でも、複数のユーザが対戦する対戦ゲーム、および、複数のユーザが協力する協力プレイゲームなどであってもよい。

本ゲームは一例として、デッキ編成要素を含んでいてもよい。すなわち、ゲームシステム１は、ゲーム上で利用可能な、デジタルデータとしてのゲーム媒体をユーザに保有させ、これらのゲーム媒体の集合（以下、デッキ）を構成し、該デッキに基づいてゲームを進行させる。

本ゲームでは、ゲーム媒体は、ゲームにおいて、ユーザの操作にしたがって何らかの動作を主体的に行うことにより、ゲームの進行内容に影響を与える。ゲーム媒体は、一例として、デッキを構成する最小単位としてのカードという表現形態でユーザに提供される。

本ゲームでは、一例として、それぞれのカードには、該カードを分類するグループ識別子として、本ゲームに登場する複数のキャラクタのうちの１つが紐付けられている。キャラクタは、本ゲームを構成する少なくともいずれかのプレイパートにおいて、上述の動作を行う主体として表現される。本ゲームでは、カードおよびキャラクタには各種のパラメータが設定されている。ユーザは、ゲームをプレイすることを経てこれらのパラメータを強化することができる。すなわち、本ゲームは、カードまたはキャラクタを育成する育成要素を含むゲームであってもよい。

本ゲームを実行するためのゲームプログラムは、サーバ２００からユーザ端末１００へ基本的に無料で提供される。本ゲーム内のサービスの一部は、有料で提供される。一例として、本ゲームは、いわゆる、アイテム課金制のゲームである。

本実施形態では、一例として、本ゲーム内で利用可能なゲーム媒体の一部が、有料で提供される。本実施形態では、一例として、有料で提供されるゲーム媒体を、有償アイテムと称する。有償アイテムは、例えば、本ゲーム内でダイヤを模して表現される。本ゲームにおいて、ダイヤは、一例として、ユーザに所有させるゲーム媒体としてのカードを所定の規則に基づいて選択する処理、いわゆる「抽選」をゲームシステム１に実行させるために消費されるものである。

本実施形態では、ダイヤは、ユーザがダイヤを購入するための支払いを実施したことに伴って該ユーザに付与される。また、ダイヤは、ユーザが支払いを実施する代わりに、本ゲームをプレイして、本ゲームの進行状況を予め定められた条件に合致するように進めた場合に、プレイ報酬として該ユーザに配布されてもよい。

ゲームシステム１において、ユーザの購入行動に伴って付与されたダイヤと、ユーザの購入行動に代えて、ユーザのプレイ内容に応じて配布されたダイヤとは、区別して管理されてもよいし、区別せずにトータル個数のみが管理されてもよい。以下では、前者のダイヤを、購入ダイヤ（第１の有償アイテム）と称し、後者のダイヤを、配布ダイヤ（第２の有償アイテム）と称して必要に応じて区別する。本実施形態では、一例として、ゲームシステム１は、購入行動に伴って付与された購入ダイヤと、購入行動に代えて、プレイ報酬として配布された配布ダイヤとを区別してそれぞれ個数を管理するものとする。

＜ゲームサイクル＞
図２は、本ゲームのゲームサイクルの一例を説明する図である。本ゲームは、複数のプレイパートで構成される。本ゲームは、育成シミュレーションゲームであって、一例として、ストーリーパート（第２パート）、練習パート（第２パート）、実践パート（第２パート）、抽選パート、能力管理パート、および、放置パート（第１パート）の６つのプレイパートを含む。

ストーリーパートは、ユーザが、キャラクタにまつわる物語を読み進めて、ゲームを進行させるパートであり、本ゲームにおけるユーザの主たる目的となるパートである。物語は、ユーザ端末１００において、静止画および動画を含む映像、音声、および、テキストなどの少なくともいずれかを含むストーリーデータとしてユーザに対して提供される。

本実施形態では、一例として、ストーリーデータは、共通ストーリーまたは個別ストーリーのいずれかの内容を含むストーリーデータとして提供される。共通ストーリーは、本ゲームの主軸の物語として展開され、本ゲームで用意されたさまざまなキャラクタが登場する、本ゲームのメインストーリーともいうべきものである。共通ストーリーは、分岐もなくすべてのユーザが***で読み進めるものとする。個別ストーリーは、共通ストーリーに登場する個々のキャラクタにまつわるサイドストーリー、例えば、外伝またはスピンオフ作品として展開されるものである。個別ストーリーは、ユーザのプレイ状況に応じて、分岐があったり、読み進める順番が異なったりしてもよい。

こうして、ユーザは、映像、音声および、テキストを介して、共通ストーリーを読み進めるとともに、お気に入りのキャラクタについての個別ストーリーを楽しむことができる。個別ストーリーは、１人のキャラクタに焦点を当てた物語であってもよいし、特定の複数人のキャラクタおよびそれらのキャラクタの関係性に焦点を当てた物語であってもよい。

本実施形態では、物語を読むための条件が設定されており、ユーザは、ロックされた物語を解放すべく、その条件を満たすように、以下のプレイパートをプレイする。本ゲームのゲームとしての遊戯性は、例えば、ユーザが、物語を解放するために、以下のプレイパートをいかに有利にプレイするかという点に見出される。一方、ユーザが特段のプレイ条件を満たさずとも、時間が来たら、あるいは、サーバ２００から供給されたら、自動的に解放される物語があってもよい。

ユーザがストーリーパートをプレイすると、ユーザは、該パートをプレイしたことに基づいて、以後のゲーム進行、とりわけ、練習パートおよび実践パートを有利に進めるための何らかの成果を得る。成果は、一例として、練習パートおよび実践パートでプレイできるクエストの解放である。以下では、クエストを、本育成シミュレーションゲームの文脈に即して、キャラクタ達がアイドルとしてのパフォーマンスを披露する「ステージ」と称する。他の成果として、配布ダイヤ、抽選ポイント、または、抽選チケットがユーザに付与されてもよい。例えば、ユーザが、１つの物語に対応する１つのストーリーデータを読了すると、読了報酬として、所定個の配布ダイヤが該ユーザに付与されてもよい。これにより、ユーザは、解放したストーリーデータを次々に読了し、配布ダイヤを貯めて、後述する抽選パートに興じることができる。

練習パートは、カードおよびそのカードに対応するキャラクタを育成するパートである。一例として、練習パートでは、カードが編成されたデッキを用いてステージを進行させる。ユーザがプレイしたいステージを選択して該ステージを最後まで進行させると、ユーザは、該ステージをクリアしたと判定される。ユーザは、ステージをクリアしたことに基づいて、以後のゲーム進行、とりわけ、実践パートを有利に進めるための何らかの成果を得る。成果は、一例として、報酬獲得、カードまたはキャラクタのパラメータ強化、ユーザのステータス向上、および、キャラクタの個別ストーリーの解放などである。報酬は、例えば、各パートで利用可能なカード、および、カードまたはキャラクタを強化するための強化アイテムなどである。練習パートを繰り返しプレイすることにより育成されたカードおよびキャラクタは、例えば、以下の実践パートにおいて、より有利に動作する。

実践パートは、育成したカードが編成されたデッキを用いて、ステージにおいて課された課題をクリアするパートである。ユーザがプレイしたいステージを選択して該ステージをクリアすると、ユーザは、該ステージをクリアしたことに伴う成果を得ることができる。成果は、例えば、クリア報酬、および、共通ストーリーの解放である。クリア報酬は、例えば、カード、および、強化アイテムなどである。他の成果として、例えば、カードまたはキャラクタのパラメータ強化、および、ユーザのステータス向上などの成果がユーザに与えられてもよい。

本実施形態では、実践パートは、一例として、ユーザによって保有される１以上のカード（ゲーム媒体）を、対戦相手のカードと対戦させるパートであってもよい。対戦相手は、他のユーザであってもよいし、ゲームプログラムにしたがって動作するコンピュータ（ＣＯＭ）であってもよい。また、対戦で使用する１以上のカードは、デッキに組み入れることによって対戦で使用可能であってもよい。デッキは、練習パートで編成されるデッキと異なる構成を有していてもよいし、同じ構成を有していてもよい。本実施形態では、一例として、実践パートは、ユーザが編成したデッキの各キャラクタと、ゲームプログラム１３１に基づいてコンピュータが編成したデッキの各キャラクタとが、アイドルとしてのパフォーマンスの高さを競う対戦（ＣＯＭ戦）を含む。本実施形態では、ＣＯＭ戦の結果が、勝利、引き分け、または、敗北のいずれであるのかに応じてクリア判定がなされ、ユーザに与えられる成果が決定される。一例として、対戦は、該対戦で使用されるユーザのカードのパラメータが、例えば先の練習パートなどにおいて強化されていればいるほど、ユーザ側が勝利しやすいように進行してもよい。

抽選パートは、本ゲームで利用できるデジタルデータとしてのゲーム媒体を、ゲーム内価値と引き換えに、ユーザに獲得させるパートである。本実施形態では、一例として、抽選パートの進行中に、ゲームシステム１において抽選が実行される。具体的には、サーバ２００は、ユーザに所有させるゲーム媒体を、複数のゲーム媒体で構成される母集団の中から所定の規則に基づいて選択することにより抽選を実行する。抽選の実行と引き換えられるゲーム内価値は、例えば、ユーザが課金により入手した仮想通貨などの有価媒体であってもよいし、プレイ報酬として無償で提供されるポイントまたは消費アイテムなどであってもよい。本実施形態では、一例として、抽選パートにおいて抽選が実行されると、当選したカードがユーザによって保有される。当選したカードは、練習パートおよび実践パートなどで利用することが可能となる。

抽選を実行するために消費される有価媒体とは、本実施形態において上述の有償アイテムのことであり、より具体的には、上述のダイヤのことを指す。また、本実施形態では、抽選を実行するために消費される消費アイテムは、一例として、抽選チケットの形態で表現される。本ゲームでは一例として、ユーザは、所定個のダイヤと引き換えるか、または、抽選チケットを所定枚数消費することにより、抽選をゲームシステム１において実行させることができる。

なお、本実施形態では、一例として、抽選に関して、購入ダイヤと配布ダイヤとは等価なものとして取り扱われる。したがって、購入ダイヤであっても配布ダイヤであっても抽選に必要な個数は同じであり、いずれのダイヤが消費されても、抽選は同様に実行される。すなわち、同じ母集団から同じ規則にしたがって、ユーザに付与するカードの選択が行われる。

また、本実施形態では、一例として、抽選チケット１枚で、１枚のカードが当選する抽選が１回実行される。さらに、本実施形態では、抽選チケットと交換可能な抽選ポイントがユーザに付与され得る。例えば、本ゲームにおいて、ユーザに付与される抽選ポイント１００ｐｔにつき、１枚の抽選チケットと交換が可能であるとする。抽選ポイントは、ログインボーナス、および、プレイ報酬などとして、ユーザに配布される。

以上のとおり、本ゲームにおいて、ユーザは、ゲームシステム１に抽選を実行させるための手段として以下の３つを有する。（１）ダイヤを購入し、入手した購入ダイヤと引き換えに抽選を実施する。（２）所定条件が満たされるようにゲームをプレイし、入手した配布ダイヤと引き換えに抽選を実施する。（３）所定条件が満たされるようにゲームをプレイして抽選ポイントを貯め、抽選ポイントと交換で手に入れた抽選チケットを消費して抽選を実施する。

ここで、「（ゲーム媒体などを）ユーザに獲得させる／保有させる／付与する」とは、一例として、ユーザに対応付けて管理されているゲーム媒体などのデジタルデータの状態を、使用不可から使用可能に遷移させることであってもよい。あるいは、デジタルデータを、ユーザ識別情報またはユーザ端末ＩＤなどに対応付けて、ゲームシステム１に含まれるメモリ１１およびメモリ２１のうちの少なくともいずれかのメモリに記憶させることであってもよい。

能力管理パートは、上述の各パートで獲得された強化アイテムを消費して、カードまたはキャラクタの能力を解放したり、強化したりするパートである。ユーザは、本パートにおいてカードまたはキャラクタの能力を解放したり、強化したりすることにより、練習パートおよび実践パートをより有利に進めることが可能となる。

放置パートは、いわゆる、放置ゲームの要素を含むパートである。具体的には、ユーザが放置パートの実行を指示した後、自動的にゲームが進行し、所定期間が経過すると、その自動進行の結果がユーザに知らされる。本実施形態では、一例として、ユーザ端末１００は、放置パートにおいて、実行パートと称するサブパートと、閲覧パートと称するサブパートとを実行する。実行パートにおいて、ユーザ端末１００は、本ゲームに登場する複数のキャラクタのうちの少なくとも１つのキャラクタを、ユーザの第１入力操作に応じて、第１状態から第２状態へ遷移させ、該キャラクタが第２状態に遷移してから、所定の時間が経過したことに応じて、該キャラクタを第１状態に復帰させ、該キャラクタが第１状態に復帰したことに応じて、第２状態であったキャラクタに基づくコンテンツを報酬としてユーザに付与する。閲覧パートにおいて、ユーザ端末１００は、ユーザに付与されたコンテンツのうち表示すべきコンテンツを指定するための第２入力操作を、ユーザから受け付け、第２入力操作を受け付けたことに応答して、指定されたコンテンツを表示部１５２に表示する。これにより、ユーザは、ストーリーパートで読了する物語とは別に、放置パートをプレイすることにより入手した、キャラクタに基づくコンテンツを閲覧して、キャラクタへの愛着をより一層高めながら、本ゲームを楽しむことができる。

さらに、ユーザ端末１００は、実行パートにおいて、コンテンツの他にも、強化アイテム、または、抽選チケットなどを、報酬としてユーザに付与してもよい。これにより、放置パートのプレイをユーザに一層動機付けることができる。

なお、本ゲームは、ミニスケープゲーム、いわゆる、箱庭ゲームの要素を含んでいてもよい。例えば、本ゲームは、上述の５つのプレイパートの他にも、箱庭パートを含んでいてもよい。箱庭パートでは、ユーザは、上述の各パートをプレイすることにより入手したアイテム、および、カードなどの各種ゲーム媒体をマップに配置し、該マップの世界を俯瞰して楽しむことができる。また、箱庭パートのプレイ成果が、上述の他のパートにおいて有利に作用するように、該成果が設定されてもよい。

＜ゲームシステム１の機能的構成＞
図３は、ゲームシステム１に含まれるサーバ２００およびユーザ端末１００の機能的構成を示すブロック図である。サーバ２００およびユーザ端末１００のそれぞれは、図示しない、一般的なコンピュータとして機能する場合に必要な機能的構成、および、ゲームにおける公知の機能を実現するために必要な機能的構成を含み得る。

ユーザ端末１００は、ユーザの入力操作を受け付ける入力装置としての機能と、ゲームの画像や音声を出力する出力装置としての機能を有する。ユーザ端末１００は、プロセッサ１０、メモリ１１、ストレージ１２、通信ＩＦ１３、および入出力ＩＦ１４等の協働によって、制御部１１０および記憶部１２０として機能する。

サーバ２００は、各ユーザ端末１００と通信して、ユーザ端末１００がゲームを進行させるのを支援する機能を有する。ゲームがマルチプレイゲームである場合には、サーバ２００は、ゲームに参加する各ユーザ端末１００と通信して、ユーザ端末１００同士のやりとりを仲介する機能を有していてもよい。サーバ２００は、プロセッサ２０、メモリ２１、ストレージ２２、通信ＩＦ２３、および入出力ＩＦ２４等の協働によって、制御部２１０および記憶部２２０として機能する。

記憶部１２０および記憶部２２０は、ゲームプログラム、ゲーム情報１３２およびユーザ情報１３３を格納する。ゲームプログラム１３１は、ユーザ端末１００が実行するゲームプログラムである。ゲームプログラム２３１は、サーバ２００が実行するゲームプログラムである。ゲーム情報１３２は、制御部１１０および制御部２１０がゲームプログラムを実行する際に参照するデータである。ユーザ情報１３３は、ユーザのアカウントに関するデータである。記憶部２２０において、ゲーム情報１３２およびユーザ情報１３３は、ユーザ端末１００ごとに格納されている。

（サーバ２００の機能的構成）
制御部２１０は、記憶部２２０に格納されたゲームプログラム２３１を実行することにより、サーバ２００を統括的に制御する。例えば、制御部２１０は、ユーザ端末１００に各種データおよびプログラム等を送信する。制御部２１０は、ゲーム情報もしくはユーザ情報の一部または全部をユーザ端末１００から受信する。ゲームがマルチプレイゲームである場合には、制御部２１０は、ユーザ端末１００からマルチプレイの同期の要求を受信して、同期のためのデータをユーザ端末１００に送信してもよい。

制御部２１０は、ゲームプログラム２３１の記述に応じて、進行支援部２１１として機能する。制御部２１０は、実行するゲームの性質に応じて、ユーザ端末１００におけるゲームの進行を支援するために、図示しないその他の機能ブロックとしても機能することができる。

進行支援部２１１は、ユーザ端末１００と通信し、ユーザ端末１００が、本ゲームに含まれる各種のプレイパートを進行させるための支援を行う。例えば、上述の各プレイパートのいずれが実行されているのかに応じて、そのときにユーザ端末１００が参照すべき情報を適宜提供する。

（ユーザ端末１００の機能的構成）
制御部１１０は、記憶部１２０に格納されたゲームプログラム１３１を実行することにより、ユーザ端末１００を統括的に制御する。例えば、制御部１１０は、ゲームプログラム１３１およびユーザの操作にしたがって、ゲームを進行させる。また、制御部１１０は、ゲームを進行させている間、必要に応じて、サーバ２００と通信して、情報の送受信を行う。

制御部１１０は、ゲームプログラム１３１の記述に応じて、ストーリーパート進行部１１１、練習パート進行部１１２、実践パート進行部１１３、抽選パート進行部１１４、および、放置パート進行部１１５として機能する。

なお、制御部１１０は、実行するゲームの性質に応じて、ゲームを進行させるために、図示しないその他の機能ブロックとしても機能することができる。例えば、制御部１１０は、上述の能力管理パートを進行させる能力管理部、および、上述の箱庭パートを進行させる箱庭パート進行部として機能してもよい。

さらに、制御部１１０は、図示しない操作受付部、および、表示制御部などとしても機能する。操作受付部は、入力部１５１に対するユーザの入力操作を検知し受け付ける。例えば、操作受付部は、上述の入力操作の、入力部１５１における入力位置の座標を検出し、該入力操作の種類を特定する。操作受付部は、例えば、タッチ操作、スライド操作、スワイプ操作、およびタップ操作等を特定する。表示制御部は、タッチスクリーン１５の表示部１５２に対して、制御部１１０の各部によって実行された処理結果が反映されたゲーム画面を出力する。表示制御部は、制御部１１０の各部によって生成された映像を含むゲーム画面を表示部１５２に表示してもよい。また、表示制御部は、グラフィカルユーザインターフェース（以下、ＧＵＩ）を、該ゲーム画面に重畳して描画してもよい。

ストーリーパート進行部１１１は、上述のストーリーパートを進行させる。ストーリーパート進行部１１１は、物語に対応するストーリーデータを再生する。ストーリーデータは、ユーザに物語を提示するために、動画、静止画、テキスト、および、音声などの各種のデータを少なくとも１以上含むデータである。ストーリーパート進行部１１１は、各物語の状態、例えば、解放済みか、未解放であるかを管理する。

練習パート進行部１１２は、上述の練習パートを進行させる。練習パート進行部１１２は、クエスト、本実施形態ではステージ、の進行に用いるデッキを編成し、ステージを進行させる。ユーザが、ステージを最後までプレイした場合には、練習パート進行部１１２は、ステージ完遂に伴う成果を決定し、該成果をゲーム情報１３２に反映させる。

実践パート進行部１１３は、上述の実践パートを進行させる。実践パート進行部１１３は、ステージ、本実施形態ではＣＯＭ戦、に用いるデッキを編成し、ＣＯＭ戦を進行させる。実践パート進行部１１３は、ＣＯＭ戦の結果に応じて成果を決定し、該成果をゲーム情報１３２に反映させる。

抽選パート進行部１１４は、上述の抽選パートを進行させる。抽選パート進行部１１４は、抽選の実行を指示するユーザの入力操作にしたがって、抽選実行要求をサーバ２００に送信する。サーバ２００によって、当選したカードが決定されると、抽選パート進行部１１４は、当選したカードについての通知をサーバ２００から受信し、当選した該カードをユーザに保有させる。

放置パート進行部１１５は、上述の放置パートを進行させる。具体的には、放置パート進行部１１５は、ユーザによって選択されたキャラクタを第１状態から第２状態へ遷移させ、第２状態に遷移してから所定の時間が経過した後、該キャラクタに基づくコンテンツを、放置パートのプレイ報酬としてユーザに付与する。

ユーザの操作によらずに実行パートが進行している間にキャラクタが陥っている第２状態は、ユーザに対しては、例えば、キャラクタが寝ている睡眠状態という体裁で表現されてもよい。この場合、実行パートが進行していない間のキャラクタの第１状態は、例えば、覚醒状態という体裁で表現されてもよい。

本実施形態では、一例として、放置パート進行部１１５は、キャラクタが第２状態へ遷移してから、ユーザにコンテンツが付与されるまでの間の任意のタイミングで、該キャラクタに基づくコンテンツを生成する。

本実施形態では、コンテンツは、第２状態に遷移したキャラクタが、該第２状態であった間に体験した出来事という体裁で、該出来事を表現したデジタルデータである。具体的には、睡眠状態に遷移したキャラクタが、寝ている間に見た夢の内容を日記形式で報告するという体裁で、該夢の内容を表現したデジタルデータである。

コンテンツは、例えば、動画データ、静止画データ、音声データ、テキストデータの少なくとも１つを含むように構成されたものである。放置パート進行部１１５は、閲覧パートにおいて、ユーザに付与されたコンテンツを再生し、表示部１５２および図示しないスピーカに出力することにより、コンテンツをユーザに閲覧させる。

本実施形態では、一例として、コンテンツは、睡眠状態に遷移したキャラクタが、睡眠中に見た夢の内容について日記形式で記したという体裁で生成される「日記データ」である。日記データの生成方法およびそのデータ構造については後に詳述する。

なお、図２に示すサーバ２００およびユーザ端末１００の機能は一例にすぎない。サーバ２００は、ユーザ端末１００が備える機能の少なくとも一部を備えていてもよい。また、ユーザ端末１００は、サーバ２００が備える機能の少なくとも一部を備えていてもよい。さらに、ユーザ端末１００およびサーバ２００以外の他の装置をゲームシステム１の構成要素とし、該他の装置にゲームシステム１における処理の一部を実行させてもよい。すなわち、本実施形態においてゲームプログラムを実行するコンピュータは、ユーザ端末１００、サーバ２００、および他の装置の何れであってもよいし、これらの複数の装置の組み合わせにより実現されてもよい。

＜発明概要＞
本実施形態では、ユーザ端末１００は、ゲームプログラム１３１を記憶するメモリ１１と、ゲームプログラム１３１を実行することにより、ユーザ端末１００の動作を制御するプロセッサ１０と、表示部１５２とを備えている。ユーザ端末１００のプロセッサ１０は、ゲームの興趣性を向上させるために、ゲームプログラム１３１に基づいて、以下のステップを実行するように構成されている。すなわち、プロセッサ１０は、ゲームプログラム１３１に基づくゲームに登場する複数のキャラクタのうちの少なくとも１つの第１キャラクタに対する、ユーザの第１入力操作に応じて、該第１キャラクタを第１状態から第２状態へ遷移させるステップ（Ｓ１０７）と、第１キャラクタが第２状態に遷移してから、所定の時間が経過したことに応じて、第１キャラクタを第１状態に復帰させるステップ（Ｓ１１９）と、第１キャラクタが第１状態に復帰したことに応じて、上述の第２状態であった第１キャラクタに基づくコンテンツ（日記データ）をユーザに付与するステップ（Ｓ１２０）と、ユーザの第２入力操作に応じて、指定されたコンテンツを表示部に表示するステップ（Ｓ２０４）と、を実行する。

プロセッサ１０は、ゲームプログラム１３１に基づいて、付与するステップＳ１２０の後、表示するステップＳ２０４の前に、ユーザに付与された１または複数のコンテンツのうち表示すべきコンテンツを指定するための第２入力操作を、ユーザから受け付けるステップ（Ｓ２０３）を実行してもよい。

＜データ構造＞
（カード）
図４は、カードのデータ構造の一例を示す図である。図４は、カード１枚に相当するデータのデータ構造を示す。図４に示すデータ構造を有するカードは、ゲーム情報１３２として、ユーザが保有するカードの枚数分、記憶部１２０に記憶されている。このカードの集合体によりカードデータベース（ＤＢ）が構築される。カードＤＢは、ユーザが保有するカードを一元管理するためのデータベースである。カードＤＢでは、図４に示すデータ構造を有するカードは、１つのレコードとして取り扱われる。

カードは、一例として、カードＩＤ、キャラクタ名、希少度、属性、カードレベル、魅力、練習スキル、メインスキル、サブスキル、および、セリフ管理情報の各項目を含む。

カードＩＤの項目には、カードＩＤが格納されている。カードＩＤは、ユーザが保有するカードをゲームシステム１上で一意に管理するために、カードに固有に割り当てられた識別情報のことである。本実施形態では、同じ内容のカードが複数枚重複して獲得されることがある。したがって、同じ内容のカードが複数枚ある場合には、それぞれのカードを識別するために、それぞれのカードに異なるカードＩＤが付与される。

キャラクタ名の項目には、該カードを分類するグループ識別子として該カードに紐付けられているキャラクタの名前が格納されている。本実施形態では、カードに紐付けられるキャラクタは、本ゲームに登場する複数のキャラクタのうちの１つである。キャラクタは、練習パートおよび実践パートなどにおいて、所定の行為を実施する動作主体であり、例えば、練習パートで使用されるデッキに編成されたカードに紐付けられているキャラクタは、該練習パートにおいて、動作主体として機能する。本ゲームにおいて動作主体として登場する各キャラクタには、他のキャラクタと重複しない固有の名前が設定されている。すなわち、キャラクタ名によって、該カードに紐付けられているキャラクタを一意に識別することができる。キャラクタＩＤも、キャラクタを一意に識別するためにキャラクタ固有に割り当てられている。そのため、該項目には、キャラクタ名に代えてキャラクタＩＤが格納されてもよい。

また、本実施形態では、異なるカードに、同じキャラクタが紐付けられていてもよい。したがって、ユーザが、同じキャラクタが紐付けられているカードを複数枚保有することが起こり得、この場合、その複数枚のそれぞれのカードは、別のカードとして取り扱われる。

希少度の項目には、カードに設定された希少度が格納される。希少度は、カードの本ゲーム内での希少価値を等級で表したものである。一般に、ゲーム上、特に、練習パートおよび実践パートにおいて良好な成果をもたらすカードには、上級の希少度が設定されている。本実施形態では、希少度は、等級が高いものから順に、ＳＳＲ、ＳＲ、Ｒ、Ｎの４段階で表される。なお、希少度は、例えば、カードの入手困難性、より具体的には、カードが当たる抽選における当選確率、ステージのクリア報酬として入手される場合のステージの難易度、または、有償入手の場合の価格などと相関があってもよい。カードの入手困難性が高いほど、カードの希少度は高く設定される。

属性の項目には、カードを属性で分類する場合に、該カードがどの属性に分類されるのかを示す情報が格納されている。本ゲームでは、一例として、赤、青、および、黄の３種類の属性が設けられている。カードは、赤、青、および、黄のいずれかの属性に分類される。なお、属性の名称は、ゲームの文脈に応じて適宜設定されるものである。例えば、アイドルが登場するゲームであれば、情熱、知性、優雅の３属性であってもよいし、魔法使いが登場するゲームであれば、火、水、雷の３属性であってもよい。

属性は、練習パートにおいて、カードを用いてゲームが進行する場にも設定されていてもよい。本ゲームにおいて場とは、デッキに編成されたカードのうち、ゲームを進行させるために使用するカードとして選択されたカードを配置する場所を指す。ユーザは、ゲームで使用したいカードを場に出すことによって、該カードを使用してゲームを進めることができる。場に設定されている属性を場属性と称する。デッキに組み入れられたカードの属性（以下、カード属性）および場属性は、例えば、ステージクリア時の成果を決定するために、練習パートの進行中において練習パート進行部１１２によって参照される。

また、属性は、カードのパラメータを強化するための強化アイテムにも設定されていてもよい。強化対象カードのカード属性および強化アイテムの属性は、例えば、能力管理パートの進行中において、図示しない能力管理部によって参照される。例えば、カードと同じ属性の強化アイテムを該カードの強化に用いることで、強化効率が向上する。

カードレベルの項目には、カード自体のレベルを示す値が格納される。本実施形態では、カードレベルが高いほど、実践パートにおいて良好な結果をもたらす性能が高いことを意味する。カードレベルは、例えば、練習パートのステージをクリアしたことの成果として上昇させることができる。

魅力の項目には、カードの性能の１つとしての魅力のパラメータ値が格納される。魅力のパラメータ値が高いほど、実践パートにおけるＣＯＭ戦において該カードが有利に作用する。例えば、観客動員数を競うＣＯＭ戦において、魅力が高いほど、多くの観客を動員することができ、ＣＯＭ戦に勝利しやすくなる。魅力は、カードレベルと相関があり、カードレベルが上がるほど、魅力のパラメータ値も高くなる。

練習スキルの項目には、練習スキルの詳細情報が格納される。練習スキルは、カードに紐付けられており、該カードが、練習パートにおけるデッキに組み入れられた場合に、練習パートにおけるステージの進行中に発動可能となるものである。

メインスキルの項目には、メインスキルの詳細情報が格納される。メインスキルは、カードに紐付けられており、該カードが、実践パートにおけるメインデッキに組み入れられた場合に、実践パートにおけるステージの進行中に発動可能となるものである。

サブスキルの項目には、サブスキルの詳細情報が格納される。サブスキルは、カードに紐付けられており、該カードが、実践パートにおけるサブデッキに組み入れられた場合に、実践パートにおけるステージの進行中に発動可能となるものである。

カードに紐付けられている上述の各スキルは、ステージの進行中、該カードに表現されているキャラクタが発動したものとして演出されてもよい。スキルが発動されると、各パートの進行に有利な効果がもたらされる。各スキルの詳細情報としては、例えば、スキルの名称、効果の内容、効果値、発動条件などが含まれる。

セリフ管理情報の項目には、セリフ管理情報が格納される。セリフ管理情報は、キャラクタに発話させるセリフを管理するための情報であり、サーバ２００から供給される。なお、練習パート等において、キャラクタ同士の対話をイベントとして発生させない場合は、カードにおいて、セリフ管理情報の項目は省略されてもよい。

（キャラクタ）
図５は、キャラクタを定義するキャラクタデータのデータ構造の一例を示す図である。図５に示すデータ構造を有するキャラクタデータは、本ゲームの各ゲームパートにおいてキャラクタごとに作成され、ゲーム情報１３２として記憶部１２０に記憶される。ユーザが保有するカードに紐付けられているキャラクタの分だけキャラクタデータが記憶部１２０に記憶されていてもよいし、ユーザがカードを入手する前から、本ゲームに登場するすべてのキャラクタの分のキャラクタデータが記憶部１２０に記憶されていてもよい。

キャラクタデータは、一例として、キャラクタＩＤ、キャラクタ名、所属（カテゴリ）、ペアパラメータテーブル、ストーリーリスト、セリフデータベース（以下、ＤＢ）、および、カードＩＤリストの各項目を含む。

キャラクタＩＤの項目には、キャラクタＩＤが格納されている。キャラクタＩＤは、各ゲームパートにおいて動作主体として機能するキャラクタをゲームシステム１上で一意に管理するために、キャラクタに固有に割り当てられた識別情報のことである。キャラクタＩＤは、体系的にユニークなテキスト列（記号、英数字など）で構成されていることが好ましい。

キャラクタ名の項目には、キャラクタ名が格納されている。キャラクタ名は、ユーザがキャラクタを識別するために、キャラクタに固有に割り当てられた識別情報のことである。キャラクタが男子高校生アイドルである場合は、ユーザが識別しやすいように、人名またはニックネームなどと分かるような文字列で構成されていることが好ましい。

所属の項目には、キャラクタがどの集合に属するのかを示すパラメータが格納されている。ストーリーパートにおいて展開される物語の中で各キャラクタには、該キャラクタの性質または所属などのように、キャラクタのカテゴリを示すさまざまな設定がなされている。所属の項目は、複数設けられてもよい。所属の項目は、ゲームの文脈および世界観などに応じて、より具体的に定義されてもよい。例えば、キャラクタが、男子高校生である場合、所属の項目として、該キャラクタの「学年」、「部活」、「所属寮」、「派閥」、「血液型」などの、キャラクタのカテゴリを表す項目が設けられてもよい。

ペアパラメータテーブルの項目には、ペアパラメータテーブルまたは該ペアパラメータテーブルが格納されている場所を示すアクセス情報が格納されている。ペアパラメータとは、該キャラクタと、その他のキャラクタとの間の関係性を表す数値化したものである。本実施形態では、本ゲームにおいて登場するすべてのキャラクタの組み合わせごとにペアパラメータが設定されている。ペアパラメータテーブルは、図５に示すキャラクタデータによって定義されているキャラクタを基準として、その他のキャラクタとの間に設定されたペアパラメータを、その他のキャラクタごとに一覧にしたものである。

なお、ゲームシステム１は、キャラクタごとにペアパラメータテーブルを管理する代わりに、本ゲームに登場するすべてのキャラクタの組み合わせごとに設定されたペアパラメータを一元管理するためのペアパラメータデータベース（以下、ＤＢ）を記憶部（記憶部１２０または記憶部２２０）において保持していてもよい。この場合、ペアパラメータテーブルの項目には、ペアパラメータＤＢから、該キャラクタにおける他のキャラクタとのペアパラメータを抽出するためのクエリが格納されていてもよい。ペアパラメータテーブルおよびペアパラメータＤＢについては、データ構造図に基づいて後に詳述する。

ストーリーリストの項目には、ストーリーリストまたはストーリーリストにアクセスするためのアクセス情報が格納されている。ストーリーリストは、該キャラクタにまつわる個別ストーリーをまとめたリストである。本実施形態では、一例として、キャラクタにまつわる個別ストーリーは、該キャラクタとその他のキャラクタとのペアに焦点を当てた物語である。ストーリーリストについては、データ構造図に基づいて後に詳述する。

セリフデータベースの項目には、セリフＤＢまたはセリフＤＢにアクセスするためのアクセス情報が格納されている。セリフＤＢは、該キャラクタに紐付けられたセリフパックを一元管理するデータベースである。セリフパックは、練習パートにおいてイベントを進行させるために必要なイベントデータおよびそのメタデータなどがひとまとまりにパッケージ化された情報である。具体的には、セリフパックは、該キャラクタまたは該キャラクタとペアリングされた相手キャラクタに発話させる１以上のセリフからなるセリフ群を少なくとも含む。なお、練習パートまたは実践パート等において、対話するイベントが発生しない場合は、該セリフデータベースの項目は、キャラクタデータから省略されてもよい。

カードＩＤリストの項目には、カードＩＤリストまたはカードＩＤリストにアクセスするためのアクセス情報が格納されている。カードＩＤリストは、ユーザが保有するカードのうち、該キャラクタが紐付いているカードのカードＩＤをまとめたリストである。ユーザ端末１００は、カードＩＤリストを参照することにより、ユーザが保有しているカードの中から、該キャラクタが紐付いているカードをすぐに抽出することができる。

本実施形態では、キャラクタとカードとは１対多の関係である。すなわち、１つのカードにおいて紐付けられるキャラクタは１体であるが、異なる複数のカードに対して同じキャラクタが紐付けられ得る。また、同じキャラクタでも、紐付けられているカードが異なれば、カードごとに異なる属性が設定され得る。

また、本実施形態では、キャラクタごとにも、図５に示すとおり、上述の各種項目が紐付けられており、これらのキャラクタごとの情報は、同じキャラクタが紐付けられている各カードで共有される。

換言すれば、カードは、キャラクタごとにグルーピングすることが可能であり、キャラクタは、カードを分類するためのグループ、キャラクタＩＤおよびキャラクタ名は、カードをグルーピングするためのグループ識別子と捉えることができる。そして、同じグループに属する各カードが利用されるとき、該グループに紐付けられた情報が、各カードに共通で参照される。具体的には、ユーザ端末１００は、同じキャラクタが紐付いている各カードをデッキに組み入れて利用する際、該カードに紐付けられているキャラクタを動作させるときに、該キャラクタを定義する上述の各項目を参照する。

なお、カードは、キャラクタ以外にも、上述したとおり、希少度または属性などに基づいて分類することも可能である。さらに、カードは、キャラクタに設定されている所属などに基づいて分類することも可能である。

（ペアパラメータテーブル）
図６の（Ａ）は、ペアパラメータテーブルのデータ構造の一例を示す図である。本ゲームでは、一例として、５人のキャラクタが物語に登場する。５人のキャラクタのキャラクタ名は、一例として、Ａ太、Ｂ介、Ｃ彦、Ｄ男、および、Ｆ郎である。同図には、一例として、キャラクタ「Ａ太」に紐付けられているペアパラメータテーブルを示している。同様のペアパラメータテーブルが、Ｂ介、Ｃ彦、Ｄ男、および、Ｆ郎のキャラクタごとに作成される。

ペアパラメータテーブルは、相手キャラクタ、および、ペアパラメータの各項目を含む。ペアパラメータは、上述のとおり、ペアを構成する２人のキャラクタ間の関係性を数値化したものであり、本実施形態では、一例として、友好度と調和度との２種類のペアパラメータが設定されている。

相手キャラクタの項目には、基準となるキャラクタとペアリングされた相手キャラクタのキャラクタ名が格納されている。例えば、図６に示す第１のレコードは、基準となるキャラクタ「Ａ太」と、その相手キャラクタである「Ｂ介」との間のペアパラメータを格納するためのレコードである。

友好度の項目には、キャラクタ間の友好度を示す数値が格納される。友好度とは、ペアとなっているキャラクタ間の友好の度合いを評価する指標である。本実施形態では、数値が高いほど、ペアの友好の度合いが高い、すなわち、２人は仲が良いということを意味する。図６に示す例では、例えば、「Ａ太」と「Ｂ介」との友好度は「２５」である。友好度は、ペアごとの個別ストーリーを解放する条件として参照される。

調和度の項目には、キャラクタ間の調和度を示す数値が格納される。調和度とは、ペアとなっているキャラクタ間の連携の良さを評価する指標である。本実施形態では、１００％を、ペアがとり得る最大の調和度とし、数値が高いほど、ペアの連携が良くとれている、すなわち、該ペアによってよりよいパフォーマンスが出力されるということを意味する。

例えば、実践パートのステージをプレイする際、該ステージで使用するカードのうち、特定の２枚のカードがそれぞれ示すキャラクタ間の調和度の数値に応じて、実践パートのステージにおける、該２体のキャラクタに係る、画像、動画、および音声等での演出が変化してもよい。具体的には、該２体のキャラクタ間の調和度の数値が所定値以上の場合、該２体のキャラクタが親密であることを示す画像、動画、および音声の少なくともいずれかを出力することとしてもよい。また、該２体のキャラクタ間の調和度の数値が高いほど、該演出がより豪華な演出になるようにしてもよい。また、該２体のキャラクタ間の調和度の数値が高いほど、該演出の回数、すなわち演出頻度が増加してもよい。

また例えば、該２体のキャラクタ間の調和度の数値が高いほど、実践パートのステージ進行が有利になってもよい。具体的には、該２体のキャラクタ間の調和度の数値が高いほど、実践パートのステージにおいて発動可能なスキルの効果値または効果内容の継続時間が増加してもよい。また、該２体のキャラクタ間の調和度の数値が高いほど、実践パートのステージにおいて、該２体のキャラクタの少なくとも一方のスキルの、発動可能回数および発動機会の少なくとも一方が増加してもよい。

また例えば、上述の２体のキャラクタ間の調和度の数値が高いほど、これらのキャラクタ、または該キャラクタに対応するカードに設定されている各種パラメータの値を、ゲームが有利になるように変更してもよい。具体的には、該２体のキャラクタ間の調和度の数値が高いほど、これらのキャラクタに対応するカードの魅力のパラメータ値が上昇してもよい。また、実践パートのステージが、ユーザの自陣営と、敵陣営とが対戦する対戦形式のステージである場合、自陣営の特定の２枚のカードが示すキャラクタ間の調和度と、敵陣営の特定の２枚のカードが示すキャラクタ間の調和度とを比較してもよい。そして、該比較の結果、調和度が高い方の陣営の、該特定の２枚のカードのパラメータを増加させてもよい。もしくは、該比較の結果、調和度が低い方の陣営の、該特定の２枚のカードのパラメータを低下させてもよい。

また例えば、実践パートのステージが、自陣営のターンと敵陣営のターンとを実行することで進行するゲームの場合、前述の比較の結果、調和度が高い方の陣営のターンを先に行うようにしてもよい。一例として、調和度が高い方の陣営が対戦で有利な先手を取る確率を高めるなどが想定される。または、前述の比較の結果、調和度が高い方の陣営のターンを実行する頻度を上昇させてもよい。

本実施形態では、一例として、調和度は、練習パートにおいて、ペアが練習を積むことにより高めることができ、実践パートにおいて、ペアが特定のパフォーマンスを出力するために消費される。すなわち、調和度は、ユーザが、練習パートと実践パートとを繰り返しプレイすることにより増減する数値である。

図６の（Ｂ）は、ペアパラメータＤＢのデータ構造の一例を示す図である。本実施形態では、ペアパラメータＤＢにおいて、本ゲームに登場するキャラクタの組み合わせ、すなわち、ペアを主キーとし、該ペアごとにレコードが作成される。そして、該レコードにペアパラメータが格納されている。具体的には、友好度と調和度とが格納されている。

本実施形態では、上述したとおり、５人のキャラクタが登場する。この場合、５人のキャラクタのすべての組み合わせは、１０通りあるので、ペアパラメータＤＢは、１０個のレコードを有する。ユーザ端末１００の制御部１１０は、ペアパラメータＤＢから、１人のキャラクタをキーにして、ペアパラメータのレコードを抽出してもよい。例えば、「主キーにＡ太が含まれているレコードを抽出する」というクエリに基づいてペアパラメータＤＢを操作すれば、図６の（Ａ）に示すとおり、Ａ太についてのペアパラメータテーブルが得られる。

（ストーリーリスト）
図７は、ストーリーリストのデータ構造の一例を示す図である。同図には、一例として、キャラクタ「Ａ太」に紐付けられているストーリーリストを示している。同様のストーリーリストが、Ｂ介、Ｃ彦、Ｄ男、および、Ｆ郎のキャラクタごとに作成される。

ストーリーリストは、相手キャラクタ、ストーリーＩＤおよび状態の各項目を含む。

相手キャラクタの項目には、基準となるキャラクタ（ここでは「Ａ太」）とペアリングされた相手キャラクタのキャラクタ名が格納されている。

ストーリーＩＤの項目には、該ペアに紐付けられた個別ストーリーのストーリーＩＤが格納されている。ストーリーＩＤは、個別ストーリーに対応するストーリーデータをゲームシステム１において一意に識別するための識別情報である。個別ストーリーを一意に識別できる情報であれば何でもよく、例えば、該項目には、ストーリーＩＤに代えて、個別ストーリーごとに設定された物語のタイトル、章番号などが格納されていてもよい。あるいは、該項目には、ストーリーＩＤに代えて、個別ストーリーに対応するストーリーデータが格納されている場所を示すアドレス情報が格納されていてもよい。

個別ストーリーは、１つのペアにつき、複数個ユーザに提供されてもよい。同図に示す例では、例えば、Ａ太とＢ介とのペアにまつわる個別ストーリーは、ストーリーＩＤ「ＡＢ００１」から「ＡＢ００３」までの３話分ユーザに提供されている。

状態の項目には、該個別ストーリーの状態を示すパラメータが格納されている。個別ストーリーの状態を示すパラメータは、一例として、個別ストーリーが解放済みであるか、未解放であるのかを示すフラグであってもよい。本実施形態では、個別ストーリーが「解放済みである」とは、ユーザが、該個別ストーリーのストーリーデータにユーザ端末１００を介してアクセスすることが可能であって、該個別ストーリーをユーザが読むことができる状態であることを意味する。

さらに、上述の状態の項目または別に設けられた項目には、個別ストーリーの状態を示すパラメータとして、解放進捗が格納されていてもよい。解放進捗は、個別ストーリーが未解放である場合に、解放の条件をユーザがどれだけ満たしているのかを示した情報である。本実施形態では、解放進捗は、一例として、分数であり、解放に必要な友好度を示す分母と、ユーザがゲームをプレイすることによって蓄積した該ペアの現在の友好度を示す分子とで構成される。

なお、個別ストーリーは、図６の（Ｂ）に示したペアパラメータＤＢと同様に、ペアを主キーとするデータベースにて、ペアごとに一元管理されてもよい。

（ストーリーリスト）
図７は、ストーリーリストのデータ構造の一例を示す図である。同図には、一例として、キャラクタ「Ａ太」に紐付けられているストーリーリストを示している。同様のストーリーリストが、Ｂ介、Ｃ彦、Ｄ男、および、Ｆ郎のキャラクタごとに作成される。

ストーリーリストは、相手キャラクタ、ストーリーＩＤおよび状態の各項目を含む。

相手キャラクタの項目には、基準となるキャラクタ（ここでは「Ａ太」）とペアリングされた相手キャラクタのキャラクタ名が格納されている。

ストーリーＩＤの項目には、該ペアに紐付けられた個別ストーリーのストーリーＩＤが格納されている。ストーリーＩＤは、個別ストーリーに対応するストーリーデータをゲームシステム１において一意に識別するための識別情報である。個別ストーリーを一意に識別できる情報であれば何でもよく、例えば、該項目には、ストーリーＩＤに代えて、個別ストーリーごとに設定された物語のタイトル、章番号などが格納されていてもよい。あるいは、該項目には、ストーリーＩＤに代えて、個別ストーリーに対応するストーリーデータが格納されている場所を示すアドレス情報が格納されていてもよい。

個別ストーリーは、１つのペアにつき、複数個ユーザに提供されてもよい。同図に示す例では、例えば、Ａ太とＢ介とのペアにまつわる個別ストーリーは、ストーリーＩＤ「ＡＢ００１」から「ＡＢ００３」までの３話分ユーザに提供されている。

状態の項目には、該個別ストーリーの状態を示すパラメータが格納されている。個別ストーリーの状態を示すパラメータは、一例として、個別ストーリーが解放済みであるか、未解放であるのかを示すフラグであってもよい。本実施形態では、個別ストーリーが「解放済みである」とは、ユーザが、該個別ストーリーのストーリーデータを所有していること、または、該ストーリーデータにユーザ端末１００を介してアクセスする権限を有していることであって、該個別ストーリーをユーザが読むことができる状態であることを意味する。

さらに、上述の状態の項目または別に設けられた項目には、個別ストーリーの状態を示すパラメータとして、解放進捗が格納されていてもよい。解放進捗は、個別ストーリーが未解放である場合に、解放の条件をユーザがどれだけ満たしているのかを示した情報である。本実施形態では、解放進捗は、一例として、分数であり、解放に必要な友好度を示す分母と、ユーザがゲームをプレイすることによって蓄積した該ペアの現在の友好度を示す分子とで構成される。

なお、個別ストーリーは、図６の（Ｂ）に示したペアパラメータＤＢと同様に、ペアを主キーとするデータベースにて、ペアごとに一元管理されてもよい。

＜練習パート＞
（処理フロー）
図８は、練習パート進行部１１２によって実行される練習パートにおける処理の流れを示すフローチャートである。

ステップＳ３０１では、練習パート進行部１１２は、不図示のデッキ編成画面を表示部１５２に表示させる。デッキ編成画面は、選択されたステージで使用される１次デッキに組み入れるカードをユーザが所有するカードの中から選択する入力操作を受け付けるための画面である。

ステップＳ３０２では、練習パート進行部１１２は、デッキ編成画面に対して実施される上述の入力操作が操作受付部を介して受け付けられたか否か判定する。練習パート進行部１１２は、該入力操作を受け付けた場合、ステップＳ３０２のＹＥＳからステップＳ３０３に進み、該入力操作を受け付けていない場合は、ステップＳ３０２のＮＯからステップＳ３０４に進む。

ステップＳ３０３では、練習パート進行部１１２は、ユーザによって選択されたカードを１次デッキに組み入れて１次デッキを編成する。

さらに、本実施形態では、練習パート進行部１１２は、ユーザが選択したカードとは別
に、所定の規則にしたがって特定したカードを１次デッキに組み入れてもよい。練習パート進行部１１２は、ユーザが保有するカードのうち、ユーザによって指定されなかったカードを所定の規則にしたがって特定してもよい。例えば、練習パート進行部１１２は、ユーザが保有するカードの中からランダムで特定してもよい。あるいは、練習パート進行部１１２は、ユーザが保有していないカードを所定の規則にしたがって特定してもよい。例えば、練習パート進行部１１２は、ユーザによって選択されたステージに予め関連付けられたカードを１次デッキに組み入れるカードとして特定してもよい。本実施形態では、練習パート進行部１１２は、ユーザによって選択された、ユーザが保有するカード例えば１０枚と、ステージに関連付けられているカード例えば１枚とを１次デッキに編成する。

ステップＳ３０４では、練習パート進行部１１２は、練習パートにおけるステージの開始を指示する入力操作を受け付けてもよい。ステージの開始を指示する入力操作は、例えば、デッキ編成画面内に配置されている「開始ボタン」などのＵＩ部品をユーザがタッチすることにより、入力されてもよい。開始ボタンがタッチされると、練習パート進行部１１２は、ステップＳ３０４のＹＥＳからステップＳ３０５へ進み、ステージの進行を開始する。

次に、練習パート進行部１１２は、ステージを進行させる。本実施形態では、一例として、１つのステージは、所定回のセットで構成される。練習パート進行部１１２は、１回のセットに相当するステップＳ３０５からステップＳ３０９までの各処理を所定回、例えば、１０セット繰り返し進行させることにより、ステージを進行させる。本実施形態では、場はセットごとに設けられる。すなわち、練習パート進行部１１２は、場に出すカードとしてユーザに選択されたカードを使用して、１つのセットを進行させるという処理を１０セット分繰り返すことにより、１つのステージを進行させる。ステップＳ３０５からステップＳ３０９までのループを抜ける条件は、したがって、「ステージを構成するすべてのセットが処理済みであること」である。

ステップＳ３０５では、練習パート進行部１１２は、１次デッキに基づいて２次デッキを編成する。より詳細には、練習パート進行部１１２は、１次デッキに組み入れられたカードの中から、所定の規則に基づいてカードを抽出し、抽出したカードからなる２次デッキを編成する。一例として、練習パート進行部１１２は、２次デッキに組み入れるカード５枚を、１次デッキの１１枚のカードの中からランダムで抽出する。

ステップＳ３０６では、練習パート進行部１１２は、進行中の各セットの基本情報をユーザに対して開示するためのステージ進行画面を表示部１５２に表示する。ステージ進行画面は、ステップＳ３０５にて編成された２次デッキを含む。具体的には、練習パート進行部１１２は、例えば、上述のステージ進行画面に、２次デッキのカード一覧を表示させ、カード一覧の中から、ユーザが、進行中のセットで使用するカードを選択できるようにＵＩを提供する。すなわち、ステージ進行画面は、２次デッキの中から、進行中のセットで使用するカードを選択する入力操作をユーザから受け付けるための画面としても機能する。ステージ進行画面の具体例については、図１１の（Ａ）を参照して後に詳述する。

ステップＳ３０７では、練習パート進行部１１２は、ステージ進行画面に対して実施される入力操作が操作受付部を介して受け付けられたか否か判定する。練習パート進行部１１２は、該入力操作を受け付けた場合、ステップＳ３０７のＹＥＳからステップＳ３０８に進み、該入力操作を受け付けていない場合は、ステップＳ３０７のＮＯからステップＳ３０６に戻り、該入力操作が受け付けられるまで待機する。

ステップＳ３０８では、練習パート進行部１１２は、１つのセットに対するユーザのプレイ、つまりペアの選択、に基づいて、ユーザに付与する報酬を決定する。報酬は、一例として、カードに設定されているパラメータを強化できる強化アイテムである。

ステップＳ３０９では、練習パート進行部１１２は、ユーザの入力操作にしたがってユーザが２次デッキから選択したカードを場に出して、進行中のセットを終了まで進行させる。本実施形態では、練習パート進行部１１２は、ユーザが選択した２枚のカードを場に出す。そして、練習パート進行部１１２は、場に出したカードに基づいて、該セットを進行させる。本実施形態では、一例として、「セットにおいてカードを使用する」とは、進行中のセットに関連付けられている場にカードを出して、場と、該場に出されたカードとの組み合わせに応じて発生させたイベントを進行させることを指す。より具体的には、練習パート進行部１１２は、場に出したそれぞれのカードに紐付けられているキャラクタのペアを特定する。そして、練習パート進行部１１２は、場に出された２枚のカードのそれぞれに紐付いているキャラクタの２人に所定の行為を実施させる。具体的には、練習パート進行部１１２は、発生させたイベントを再生するためのイベントデータを処理し、キャラクタ達が上述の所定の行為を実施している演出が付いたアニメーションを表示部１５２に出力したり、キャラクタのセリフに対応する音声データを図示しないスピーカに出力したりする。さらに、練習パート進行部１１２は、ステップＳ３０８において決定された量の報酬がドロップしてユーザが獲得できる様を表すアニメーションを、併せて、表示部１５２に出力してもよい。

練習パート進行部１１２は、１つのセットにつき、ステップＳ３０５からステップＳ３０９までの各処理を実行し、これをセットごとに繰り返す。練習パート進行部１１２は、ステージを構成するすべてのセットについてステップＳ３０５からステップＳ３０９までの処理を実行すると、例えば、１０セット進行させると、ループを抜け、ステップＳ３１０に進む。

ステップＳ３１０では、練習パート進行部１１２は、ステージがプレイされた成果を示す結果画面を表示部１５２に表示する。結果画面は、少なくとも、例えば、１０セットを通じて合計で強化アイテムが何個付与されたのかを示す情報を含んでいる。

ステップＳ３１１では、練習パート進行部１１２は、各セットで獲得された報酬を、ユーザに付与する。具体的には、ユーザに関連付けて記憶されている強化アイテムの所持数を、上述の合計が示す個数分増分する。

（デッキ編成）
図９は、練習パートで参照されるデッキ情報のデータ構造の一例を示す図である。図９の（Ａ）は、１次デッキのデッキ情報を示し、図９の（Ｂ）は、２次デッキのデッキ情報を示す。

図９に示すとおり、各デッキのデッキ情報は、ポジション番号、および、カードＩＤの各項目を含む。

ポジション番号の項目には、各デッキにおけるカードの配置場所を識別するための識別情報が格納されている。例えば、ポジション番号「１－１」は、１次デッキにおける１番目の配置場所を示しており、ここに配置されたカードは、１次デッキの１番目のカードというように識別される。なお、デッキ上の配列または配置順が、デッキを用いたゲームパートにおける進行に影響を与えない実施形態においては、ポジション番号の項目は省略されてもよい。

カードＩＤの項目には、各デッキに組み入れられたカードのカードＩＤが格納されている。同図では、説明を簡略化するために１ケタの数字が格納されているが、カードＩＤは、全てのカードを一意に識別するために割り振られる識別情報であるので、実際には、これよりも複雑な文字および記号の羅列であると想定される。

なお、同図には、発明の理解を助けるために、キャラクタ名の項目を設けている。これは、説明のために図示したのであって、実際のデッキ情報には項目として設けられていなくてもよい。キャラクタ名の項目には、該ポジションに配置されたカードに紐付けられているキャラクタのキャラクタ名が格納されている。

図９の（Ａ）に示すとおり、１次デッキのデッキ情報は、少なくとも、ユーザによって選択されたカードを配置するためのポジションを有する。図示の例では、該ポジションは「１－１」から「１－１０」まで１０個設けられている。

練習パート進行部１１２が、１次デッキに入れるカードとして、ユーザによって選択されたカードとは別のカードを所定の規則に基づいて特定する場合が想定される。この場合、１次デッキのデッキ情報は、そのようにして特定されたカードを配置するためのポジションを有していてもよい。図示の例では、該ポジションは、「１－１１」として１個設けられている。以下では、ユーザが選択したカードとは別に、練習パート進行部１１２が選択したカードを、特に区別が必要な場合には、ゲストカードと称する。一例として、１次デッキは、ユーザによって選択されたカードを配置するための１０個のポジションと、練習パート進行部１１２が決定したゲストカードを配置するための１個のポジションとで構成される。本実施形態では、ゲストカードは、例えば、ステージごとに予め定められている。

練習パート進行部１１２は、ステップＳ１０３において、デッキ編成画面を介して、１０枚のカードを選択する第１入力操作を受け付けると、該１０枚のカードと、選択されたステージに関連付けられた１枚のゲストカードとに基づいて、図９の（Ａ）に示すデッキ情報を生成する。

練習パート進行部１１２は、カードを分類するためのグループ識別子、例えば、キャラクタ名またはキャラクタＩＤに基づいて、カードが属するグループ、例えば、カードに紐付いているキャラクタを特定し、同じグループに属するゲーム媒体を、予め定められた上限数を超えないように、１次デッキに組み込んでもよい。例えば、図９の（Ａ）に示すとおり、練習パート進行部１１２は、ゲストカードを除いて、同じキャラクタのカードが２枚を超えて組み入れられないように１次デッキを制御してもよい。これにより、様々なキャラクタのカードを１次デッキに組み入れて、どのキャラクタも万遍なく育成するようにユーザを促すことができる。結果として、ユーザは、ゲームに飽きることなく長く育成ゲームを楽しむことが可能となる。

図９の（Ｂ）に示すとおり、２次デッキのデッキ情報は、練習パート進行部１１２によって、１次デッキに組み入れられたカードの中から抽出されたカードを配置するためのポジションを有する。図示の例では、該ポジションは「２－１」から「２－５」まで５個設けられている。

練習パート進行部１１２は、セットが開始される度に、１次デッキに組み入れられた１１枚のカードの中から、所定の規則に基づいて５枚（第１の所定数）のカードを抽出し、図９の（Ｂ）に示すデッキ情報を生成する。

例えば、練習パート進行部１１２は、ランダムに５枚のカードを抽出してもよい。練習パート進行部１１２は、前回のセットでどのカードが場に出されたのかに応じて５枚のカードを抽出してもよい。練習パート進行部１１２は、一例として、以下の規則に基づいて５枚のカードを抽出し２次デッキを編成する。

図１０の（Ａ）～（Ｃ）は、前回のセットが進行した後、次に、練習パート進行部１１２が、今回のセットを進行させるために用いる２次デッキを再編するまでの工程を詳細に説明する図である。

図１０の（Ａ）は、前回のセットのステップＳ１０９において、ユーザによって選択され、場に出されたカードの一例を示す図である。上段は選択されたカードのカードＩＤ、下段は該カードに紐付けられているキャラクタのキャラクタ名を示す。図示のとおり、ユーザは、図９の（Ｂ）に示す２次デッキのカードの中から、カードＩＤ「５」および「７」の各カードを選択したとする。以下では、カードＩＤ「５」および「７」の各カードを、５番のカード、７番のカードと称する。

図１０の（Ｂ）は、前回のセット終了直後の２次デッキのデッキ情報を示す図である。同図に示す例では、ポジション番号の項目の記載を省略した。上段は、２次デッキに組み入れられているカードのカードＩＤ、下段は、該カードに紐付けられているキャラクタのキャラクタ名を示す。

練習パート進行部１１２は、前回のセットが終了すると、一旦、前回のセットでユーザに選択され、場に出されたカードを、２次デッキから外す。図示の例では、練習パート進行部１１２は、５番のカードと７番のカードとを２次デッキから外す。一方、練習パート進行部１１２は、前回のセットでユーザに選択されなかったカードを、今回のセットにおける２次デッキに組み入れたまま維持する。

次に、練習パート進行部１１２は、今回のセットための２次デッキを再編成する。一例として、練習パート進行部１１２は、上述のカードを外したことにより空いたポジションに補充するカードを選択する。別の例では、練習パート進行部１１２は、前回のセットで編成された２次デッキをリセットし、２次デッキのすべてのポジションを新しく選びなおしてもよい。

一例として、練習パート進行部１１２は、空いたポジションに補充するカードの候補を、以下のように特定し、該カードの候補の中から、補充するカードをランダムに抽出する。

図１０の（Ｃ）は、空いたポジションに補充されるカードの候補を示す図である。例えば、練習パート進行部１１２は、前回のセットで２次デッキに組み入れられなかったカードを候補に入れる。これにより、前回のセットで練習パート進行部１１２によって抽出されずに１次デッキに残留した各カードが２次デッキに組み込まれる可能性が出る。

すなわち、練習パート進行部１１２は、前回のセットで場に出すカードとして選択されなかったカードを２次デッキに残留させる構成、および、１次デッキにおいて２次デッキ用に抽出されなかったカードを候補に入れる構成を有する。これらの構成により、結果として、ユーザに多様なカードを使って、各種キャラクタを幅広く育成してほしいとするゲームマスター側、例えば、本ゲームのゲームプログラムを各ユーザに供給する運営団体の意図を反映させることができる。

本実施形態では、加えて、練習パート進行部１１２は、前回のセットでユーザに選択されたカードも候補に入れる。これにより、前回のセットでユーザが選択したカードが今回のセットにおいても連続で２次デッキに組み込まれる可能性が出る。また、カードが２次デッキに組み込まれれば、ユーザは、そのカードを自分の意思で最終的に場に出すカードとして選択することができる。ユーザは、お気に入りのカードを、該カードに関連するパラメータを育成するために何度でも選択したいと思っていると考えられる。

すなわち、練習パート進行部１１２は、前回のセットで場に出すカードとして選択されたカードを候補に入れる構成、および、２次デッキの中から場に出したいカードについてユーザの選択を受け付ける構成を有する。これらの構成により、お気に入りのカードを集中的に強化したいとするユーザの要望にも応えることが可能となる。

（ステージ進行画面）
図１１の（Ａ）および（Ｂ）は、ユーザ端末１００の表示部１５２に表示されるステージ進行画面の一例を示す図である。

練習パート進行部１１２は、ステップＳ１０６を実行するときに、例えば、図１１の（Ａ）に示すステージ進行画面９００を表示部１５２に表示する。練習パート進行部１１２は、ステップＳ１０９を実行するときに、例えば、図１１の（Ｂ）示すステージ進行画面９００を表示部１５２に表示する。

ステージ進行画面９００は、ステージおよび各セットの基本情報を開示する第１の機能と、セットで使用するカードをユーザが選択するためのＵＩ部品を提供する第２の機能と、イベントの進行状況および結果をユーザに対して提示する第３の機能とを備えるように構成される。

図１１の（Ａ）に示すとおり、第１の機能を実現するために、ステージ進行画面９００は、一例として、セット情報９０１と、集中度ゲージ９０２と、成果情報９０３とを含む。

セット情報９０１は、ステージの進行状況を示す情報を含む。進行状況を示す情報は、進行中のセット（以下、現行セット）を含めて、進行が完了していないセットが残りいくつあるのかを示す情報である。「あと３セット」などとセット情報９０１が表示されることにより、ユーザは、未完了のセットが３セットあることを理解する。

セット情報９０１は、さらに、現行セット、次回セット、および、次々回セットの場属性を示す情報を含んでいてもよい。各セットにおいて「場」とは、ユーザによって選択された２枚のカードを配置するための場所のことであり、本ゲームの文脈で言えば、上述の２枚のカードのそれぞれに紐付けられた二人のキャラクタ（ペア）が、練習としてパフォーマンスを行うための練習舞台９０５である。

場属性を示す情報は、例えば、図示のとおり、色分けされたアイコンとして提示されてもよい。詳細には、セット情報９０１のうち、左の最も大きいアイコンが、現行セットの場属性を示し、中央のアイコンが、次回セットの場属性を示し、右のアイコンが次々回セットの場属性を示す。

本実施形態では、練習パート進行部１１２は、該セットにおける場属性と、場に配置されたカードの属性との関係性に応じて、該セットを完遂した時にユーザが得られる成果を決定してもよい。例えば、練習パート進行部１１２は、場属性と一致するカードが場に配置されたセットでは、一致しない場合よりもユーザにとって有利な成果が得られるように、該セットの成果の内容を補正してもよい。具体的には、練習パート進行部１１２は、属性が一致したセットを完遂したことの報酬である強化アイテムをより多くユーザに獲得させてもよいし、該セットに登場したペアのペアパラメータの上昇値をより多くしてもよい。また、本実施形態では、練習パート進行部１１２は、場属性と一致するカードが場に配置されたセットでは、一致しない場合よりもより多くのメダルをユーザに獲得させる。さらに、本実施形態では、練習パート進行部１１２は、場属性と一致するカードであって、推奨ペアとキャラクタが一致するカードが場に出されたセットでは、属性のみを一致させた場合よりもさらにより多くのメダルをユーザに獲得させる。

ユーザは、よりよい成果を効率よく得るために、セット情報９０１に示された場属性を確認し、手持ちのカードの属性と比較して最適なペアを選択することができる。結果として、練習パートの遊戯性が高まる。

集中度ゲージ９０２は、セットごとにイベントが進行する度に、イベントが進行したことの成果として蓄積されるパラメータの蓄積度合いを示すＵＩ部品である。本ゲームの文脈では、該パラメータは、一例として、場に出た各キャラクタが練習に集中している度合いを示す集中度として表現される。本実施形態では、練習パート進行部１１２は、セットごとに場にカードを配置し、各カードのキャラクタ対に関するイベントを進行させる度に集中度を更新する。集中度が予め定められた閾値に達すると、練習パート進行部１１２は、次回以降の数セットを、ユーザにとって特に有利にステージを進行させるモード（いわゆるフィーバーモード）で進行させる。例えば、練習パート進行部１１２は、セット完遂後に得られる強化アイテムなどの報酬の量を大幅に増加させてもよい。練習パート進行部１１２は、フィーバーモードを終了させると、集中度のゲージをリセットし、またゼロから蓄積を再開する。なお、練習パート進行部１１２は、場属性と場に出されたカードの属性とが一致している場合に、より多くの集中度を蓄積してもよい。本実施形態では、練習パート進行部１１２は、集中度を、ステージを跨いで持ち越してもよい。練習パート進行部１１２は、ステージが終了した時点の集中度を、ゲーム情報１３２として記憶部１２０に記憶しておき、別のステージが開始されたときに、記憶しておいた集中度を読み出す。

成果情報９０３は、進行中のステージにおいて、進行済みの各セットでこれまでに獲得された報酬の数または量をユーザに提示するためのＵＩ部品である。図示の例では、報酬は、属性が設定された強化アイテムおよびメダルであり、強化アイテムについては、設定された属性ごとに、報酬として獲得された強化アイテムの数が開示される。また、メダルについては、属性問わず、獲得されたメダルの全種類の合計が開示される。これにより、ユーザは、ステージの進行中であっても、ステージ完遂後に得られる報酬の量を事前に把握することが可能となる。

第２の機能を実現するために、ステージ進行画面９００は、一例として、２次デッキ９１２を含む。

２次デッキ９１２は、１次デッキに組み入れられたカードの中から、練習パート進行部１１２が所定の規則に基づいて抽出したカードをユーザに提示するためのＵＩ部品である。また、２次デッキ９１２は、場に出す２枚のカードをユーザが選択するためのＵＩ部品である。２次デッキ９１２には、練習パート進行部１１２によって２次デッキとして抽出された、例えば５枚のカードが配置される。

２次デッキ９１２において、カードには、属性アイコン９１４が付与されてもよい。属性アイコン９１４は、カード属性を示す。ユーザは、カードに付与されている属性アイコン９１４を見て、そのカードのカード属性を確認することができる。

２次デッキ９１２において、カードには、調子アイコン９１５が付与されてもよい。調子アイコン９１５は、そのカードの調子の良さを示す。本実施形態では、「カードの調子」とは、カードの状態の良し悪しを示すパラメータである。カードの調子は、ステージで固定されていてもよいし、セットごとに変更されてもよいし、そのカードが場で使用されるまでの間同じ調子で維持されるものであってもよい。カードの調子が良いことは、カードの調子が通常の場合よりも、該カードが場に出されたときに、該カードが、ユーザにとって有利な結果または良好な成果をもたらすことができるということを意味している。

本実施形態では、練習パート進行部１１２は、２次デッキに組み入れられた各カードの調子を所定の規則に基づいて決定し、各カードが選択されずに２次デッキに残留している間、その調子を維持させる。練習パート進行部１１２は、カードが使用された後、次に、該カードを２次デッキに編成するときに、該カードの調子を所定の規則に基づいて再設定する。一例として、練習パート進行部１１２は、「通常」、「好調」、「絶好調」の３段階で、各カードの調子をランダムに決定する。

調子が所定の段階より上の段階にあるカード、例えば、調子が好調以上であるカード同士がペアとして選択された場合には、通常のカードを場に出した場合と比較して、より有利な結果またはより良好な成果が得られる。一例として、練習パート進行部１１２は、該ペアについて進行するイベントにつき、希少度の高いセリフを発現させる可能性を高めたり、ボーナス対話としてセリフをより多く発現させたりして、ペアに希少度の高い行為を実施させたりして、ユーザがよりイベントを楽しめるようにする。あるいは、練習パート進行部１１２は、セット完遂後に得られる各種パラメータの上昇率を高めたり、より多くのまたはより価値の高い報酬をユーザに獲得させたりして、より良好な成果をもたらしてもよい。

２次デッキ９１２において、ゲストカードのカードには、ゲストアイコン９１７が付与されてもよい。これにより、ユーザは、自分の手持ちのカード以外でデッキに組み入れられているゲストカードを判別しやすくなる。

以上のとおり、ユーザは、ステージ進行画面９００に開示されたさまざまな情報、特に、セット情報９０１、および、２次デッキ９１２を確認して、現行セットの場に最適な２枚のカードを選択することができる。

２枚のカードを選択するための入力操作は、例えば、２次デッキ９１２に配置されている所望のカードをタップ操作することで実現される。

練習パート進行部１１２は、２次デッキ９１２に配置されている５枚のカードのうち、２枚のカードに対するタップ操作を受け付けると、選択された２枚のカードを場に出して、現行セットを進行させる。具体的には、練習パート進行部１１２は、選択された２枚のカードのそれぞれに紐付けられているキャラクタのペアを、練習舞台９０５に表示して、該ペアに関するイベントを進行させる。

続いて、練習パート進行部１１２は、現行セットにつきユーザに付与される報酬を視覚的に見せる演出を出力してもよい。以下では、練習パート進行部１１２が、内部的にユーザに獲得させる報酬を所定の規則に基づいて確定させること、また、確定したことをユーザに対して視覚的に見せることを「報酬をドロップさせる」と表現し、報酬が確定すること、また、報酬がそのように視覚的に提示されることを、「報酬がドロップする」と表現する。また、そのように取り扱われる報酬そのものを「ドロップ報酬」と表現する。

一例として、図１１の（Ｂ）に示すとおり、練習パート進行部１１２は、イベント進行の終盤に、ステージ進行画面９００において、ドロップ報酬としての強化アイテム９１８が、所定の行為を実施中のキャラクタ９０６およびキャラクタ９０７からドロップする様を表現したアニメーションを出力する。練習パート進行部１１２は、練習舞台９０５において演出としてドロップさせる強化アイテム９１８の個数を、ステップＳ１０８にて決定した個数と合わせることが好ましい。本実施形態では、さらに、練習パート進行部１１２は、ドロップした強化アイテム９１８が、成果情報９０３において強化アイテムの個数を表すアイコン９１９のところまで移動するアニメーションを付加してもよい。

これにより、ユーザは、セットで獲得できた強化アイテム数を直感的に把握することが可能となり、さらに、ドロップした強化アイテムの数多い場合には、とりわけ、多くの強化アイテム９１８が獲得できたことを視覚的に認知することができるので、セットを成功させたことについて、達成感、満足感をより一層得ることができる。

（画像の素材データベース）
サーバ２００の記憶部２２０には、画像の素材データベース（以下、素材ＤＢ）が格納されている。素材ＤＢにおいて管理されている素材データは、ストーリーパート、練習パートまたは実践パートの進行時にゲーム画面に配置される画像である。素材データとしては、例えば、キャラクタが居る所定の場所を表す背景画像（第１の素材データ）と、該所定の場所で、所定の行為を実施するキャラクタを表す前景画像（第２の素材データ）とがある。

背景画像は、例えば静止画である。背景画像の素材ＤＢは、例えば、ＩＤ、場所名、静止画の各項目を含むデータ構造を有する。ＩＤの項目には、背景画像を一意に識別する情報が格納されており、該情報は、静止画のファイル名などであってもよい。場所名の項目には、背景画像が表す場所の名前が格納されている。該名前は、例えば、「校舎の廊下」、「理事長室」、「寮のキッチン」、「カフェテラス」、「夕暮れの野原」など、ストーリーパートで進行する物語に登場する場所、もしくは、練習パートのステージ進行画面９００（図１１）または実践パートのステージ進行画面（不図示）において背景として採用される場所を指す文字列であってもよい。静止画の項目には、背景画像のデータ本体または該データ本体が格納されている場所を示すアドレスが格納されている。

前景画像は、例えばキャラクタの静止画（フレーム）の集合体、つまり、所定の行為を実施する動きを伴うキャラクタの動画である。前景画像の素材ＤＢは、例えば、ＩＤ、キャラクタ名、行為、動画の各項目を含むデータ構造を有する。ＩＤの項目には、前景画像を一意に識別する情報が格納されており、該情報は、動画のファイル名などであってもよい。キャラクタ名の項目には、前景画像が表すキャラクタの名前が格納されている。キャラクタ名に代えて、キャラクタＩＤが格納されていてもよい。行為の項目には、前景画像が表す、上述のキャラクタが実施している行為を説明する文字列が格納されている。該文字列は、例えば、「お菓子を食べる」、「びっくりする」、「飛び跳ねる」、「おしゃべりする」、「腕組みする」などであり、実践パートのステージ進行画面、または、練習パートのステージ進行画面９００（図１１の（Ｂ））において練習舞台９０５に出されたキャラクタに実施させる行為を指す言葉が格納されている。行為の項目には、言葉に代えて、ゲームシステム１が行為を一意に識別できるような識別情報が格納されていてもよい。動画の項目には、前景画像のデータ本体または該データ本体が格納されている場所を示すアドレスが格納されている。

以上のとおり、背景画像の素材ＤＢには、ストーリーパート、練習パートおよび実践パートで使用されるすべての背景画像が格納されている。前景画像の素材ＤＢには、すべてのキャラクタごとに、すべての行為ごとの動画が格納されている。進行支援部２１１は、ユーザ端末１００のゲームの進行状況に応じて、適時に、背景画像の素材ＤＢに基づいて必要な場所に対応する背景画像を読み出し、また、前景画像の素材ＤＢに基づいて、必要なキャラクタの必要な行為に対応する前景画像を読み出し、背景画像と前景画像とをユーザ端末１００に供給する。

本実施形態では、図１１の（Ｂ）に示すとおり、練習パートの練習舞台９０５において、２人のキャラクタが左右に配置される。配置された位置が左か右かでキャラクタの向きが変わる。そこで、前景画像の素材ＤＢにおいて、右配置用の前景画像を登録しておき、練習舞台９０５の左に配置するときには、練習パート進行部１１２が、該前景画像を左右反転させてもよい。あるいは、前景画像の素材ＤＢにおいて、１つのキャラクタの１つの行為につき、右配置用の前景画像と左配置用の前景画像とが登録されていてもよい。

ストーリーパート、練習パートおよび実践パートの進行のために管理されている、上述の素材データは、以下で説明する放置パートにおいて報酬である日記データを生成するために流用されることが好ましい。これにより、放置パートのために態々新規に素材を生成せずとも、既存の資源を活用し、労力を抑えつつ、本ゲームに放置パートを導入することができる。

＜放置パート＞
（実行パートの処理フロー）
図１２および図１３は、放置パート進行部１１５が実行する放置パートのうち、実行パートの処理の流れを示すフローチャートである。

例えば、ユーザが、放置パートのトップ画面（不図示）が表示されている状態で、寝かしつけるキャラクタを選択するためのキャラクタ選択画面を呼び出す入力操作を行う。該入力操作に応答して、放置パート進行部１１５は、キャラクタ選択画面を表示部１５２に表示して、ステップＳ１０１からの一連の処理を開始する。

ステップＳ１０１では、放置パート進行部１１５は、キャラクタ選択画面を介して、第２状態に遷移させるキャラクタ、具体的には、寝かしつけるキャラクタ（以下、第１キャラクタ）を選択する入力操作（第３入力操作）を受け付ける。該入力操作に応答して、放置パート進行部１１５は、ステップＳ１０１のＹＥＳからステップＳ１０２に進む。

ステップＳ１０２では、放置パート進行部１１５は、上述の入力操作によって選択された、第１キャラクタを特定する。続いて、放置パート進行部１１５は、必要に応じて、ステップＳ１０３およびＳ１０４を実行してもよい。ステップＳ１０３およびＳ１０４は省略されてもよい。

ステップＳ１０３では、放置パート進行部１１５は、放置パートで利用可能な消費アイテムの一覧を表示し、利用する消費アイテムを指定する入力操作（第４入力操作）を受け付ける。

ステップＳ１０４では、放置パート進行部１１５は、上述の入力操作に応答して、指定された消費アイテムを消費する。消費アイテムは、例えば、アロマなど、キャラクタの快眠を助ける快眠グッズを模して表現されてもよい。消費された消費アイテムに応じて、第１キャラクタの起床後に付与される日記データの内容、すなわち、第１キャラクタが見る夢の内容が変化してもよい。例えば、第１キャラクタが好きな香りのアロマを使用すると、楽しい夢などポジティブな内容の夢を見る確率が上がってもよいし、特定のキャラクタの好きな香りのアロマを使用すると、該特定のキャラクタが夢に登場する確率が上がってもよい。

ステップＳ１０５では、放置パート進行部１１５は、ステップＳ１０２で特定された第１キャラクタの睡眠導入時の様子を表す導入画面を表示部１５２に表示する。

ステップＳ１０６では、放置パート進行部１１５は、導入画面に表示されている第１キャラクタに対するユーザの入力操作（第１入力操作）を受け付ける。この入力操作としては、例えば、第１キャラクタが表示されている入力部１５１の領域を、ユーザが指などでなでるようなスライド操作の繰り返しとすることが想定される。放置パート進行部１１５は、上述のスライド操作を所定回数検知すると、ステップＳ１０６のＹＥＳからステップＳ１０７に進む。

ステップＳ１０７では、放置パート進行部１１５は、検知したスライド操作に応答して、第１キャラクタを覚醒状態から睡眠状態に遷移させる。

ステップＳ１０８では、放置パート進行部１１５は、睡眠状態遷移時からの経過時間の計測を開始する。こうして、放置パート進行部１１５は、放置ゲームを、所定の時間が経過するまで、ユーザの入力操作を必要とせずに自動で進行させる。所定の時間は、例えば、８時間などが想定される。

ステップＳ１０９では、放置パート進行部１１５は、寝かされた第１キャラクタと消費された消費アイテムとを加味してコンテンツを生成する。なお、放置パート進行部１１５は、コンテンツを生成するステップＳ１０９を、ステップＳ１０７からステップＳ１２０までの任意のタイミングで実行してもよい。

ステップＳ１１０では、放置パート進行部１１５は、第１キャラクタが睡眠状態にあることを示す画面、すなわち、放置ゲームが進行中であることを示す実行画面（第２画面）を表示部１５２に表示する。放置パート進行部１１５は、実行画面に、所定の時間が経過するまでの残り時間を配置して、ユーザに知らせてもよい。

ステップＳ１１１では、放置パート進行部１１５は、ここで一旦放置パートを終了する指示を受け付けてもよい。放置パートを終了する指示をユーザから受け付けると、放置パート進行部１１５は、図１３に示すステップＳ１１２において、再び放置パートを開始する指示を受け付けるまで、放置パートを終了する。放置パート進行部１１５は、ここで、放置パートを終了させても、経過時間の計測を継続し、バックグラウンドで放置ゲームを進行させる。ユーザは、所定の時間が経過するまで、別のパートをプレイしたり、本ゲーム自体を終了させて別のことをしていてもよい。放置パートを終了する指示が入力されないうちは、放置パート進行部１１５は、ステップＳ１１１のＮＯから、図１３に示すステップＳ１１３に進み、所定の時間が経過するまで待機する。

ステップＳ１１２では、放置パート進行部１１５は、放置パートを開始する指示をユーザから受け付ける。放置パートを開始する指示をユーザから受け付けると、放置パート進行部１１５は、放置パートを開始し、ステップＳ１１２のＹＥＳからステップＳ１１３に進む。

ステップＳ１１３では、放置パート進行部１１５は、第１キャラクタが睡眠状態に遷移したときから計測していた経過時間が、所定の時間、例えば８時間、に到達したか否かを判定する。所定の時間が経過しないうちは、放置パート進行部１１５は、ステップＳ１１４に進み、所定の時間が経過すると、ステップＳ１１７に進む。

ステップＳ１１４では、放置パート進行部１１５は、実行画面を表示する。放置パート進行部１１５は、実行画面を介して、放置ゲームの進行を途中でキャンセルする指示を受け付けてもよい。

ステップＳ１１５では、実行画面中のキャンセルボタンが押下されるなどして、放置パート進行部１１５が、寝かしつけをキャンセルする入力操作（第５入力操作）をユーザから受け付けてもよい。該入力操作を受け付けると、放置パート進行部１１５は、ステップＳ１１５のＹＥＳからステップＳ１１６に進む。該入力操作を受け付けないうちは、放置パート進行部１１５は、ステップＳ１１１に戻り、放置パートの終了指示を待つか、あるいは、ステップＳ１１３に戻り、所定の時間の経過を待つ。

ステップＳ１１６では、放置パート進行部１１５は、所定の時間の満了を待たずに、第１キャラクタを睡眠状態から覚醒状態に復帰させる。この場合、放置パート進行部１１５は、日記データまたは強化アイテムなどの報酬をユーザに付与することを省略してもよいし、所定の時間の満了を待って覚醒状態に復帰させたときにもらえる報酬よりもゲーム内価値が低い報酬をユーザに付与してもよい。

ステップＳ１１７では、放置パート進行部１１５は、所定の時間が満了し、第１キャラクタを、睡眠状態から覚醒状態に復帰させることが可能であることを示す復帰直前画面を表示部１５２に表示する。復帰直前画面には、覚醒状態に復帰可能な第１キャラクタが配置されていてもよい。

ステップＳ１１８では、放置パート進行部１１５は、復帰直前画面を介して、第１キャラクタに対する入力操作を受け付ける。この入力操作としては、例えば、第１キャラクタが表示されている入力部１５１の領域を、ユーザが指などで軽くたたくようなタップ操作、または、ダブルタップ操作とすることが想定される。放置パート進行部１１５は、上述のタップ操作を所定回数検知すると、ステップＳ１１８のＹＥＳからステップＳ１１９に進む。

ステップＳ１１９では、放置パート進行部１１５は、検知したタップ操作に応答して、第１キャラクタを睡眠状態から覚醒状態へと復帰させる。

ステップＳ１２０では、放置パート進行部１１５は、第１キャラクタが、所定の時間を満了した上で覚醒状態に復帰したことに基づいて、ユーザに報酬を付与する。具体的には、放置パート進行部１１５は、日記データをユーザに付与する。放置パート進行部１１５は、ステップＳ１０９で生成した日記データを、ユーザ端末１００の記憶部１２０に、任意のタイミングで閲覧可能に保存してもよい。このとき、該日記データに、付与された日時を関連付けておくことが好ましい。さらに、放置パート進行部１１５は、強化アイテムをユーザに付与してもよい。放置パート進行部１１５は、付与したばかりの日記データを、表示部１５２に表示してもよい。

別の実施形態では、ステップＳ１２１が実行されてもよい。ステップＳ１２１では、放置パート進行部１１５は、寝かしつけメータにおけるパラメータ値を所定の増分だけ加算する。寝かしつけメータに係る処理については、実施形態２で詳述する。

（放置キャラクタ情報）
図１４は、放置キャラクタ情報のデータ構造の一例を示す図である。放置キャラクタ情報は、放置パートで使用されるキャラクタに関する情報である。例えば、放置キャラクタ情報は、放置パートにおいて、寝かしつけの対象となる各キャラクタの情報を含むテーブルである。放置キャラクタ情報は、本ゲームに登場するキャラクタのうち、放置パートで寝かしつけの対象となる各キャラクタの情報を含む。本ゲームに登場するすべてのキャラクタが、寝かしつけの対象であってもよい。

放置キャラクタ情報は、キャラクタＩＤ、キャラクタ名、状態の各項目を含んでいてもよい。キャラクタＩＤの項目には、キャラクタに一意に割り当てられているキャラクタＩＤが格納されている。キャラクタ名の項目には、キャラクタの名前が格納されている。キャラクタＩＤおよびキャラクタ名のいずれか一方は省略されてもよい。

状態の項目には、キャラクタの状態を示す状態情報（第１情報）が格納されている。キャラクタの状態は、放置パートの進行に影響を与える。状態情報は、「報酬」のサブ項目を含む。「報酬」のサブ項目には、キャラクタを寝かしつけた後、該キャラクタの覚醒時にドロップする報酬の属性を示す情報が格納されている。図示の例では、Ａ太には、「赤」の状態情報が紐付けられている。該状態情報は、Ａ太を寝かしつけると、覚醒時に、赤属性の強化アイテムがドロップすることを意味している。状態情報の「ランダム」は、赤・青・黄いずれかの属性の強化アイテムがランダムでドロップすることを意味している。

状態情報は、「調子」のサブ項目を含んでもよい。「調子」のサブ項目には、第１状態から第２状態への遷移のし易さ、または、第２状態にあるときの調子の良さを示す情報が格納されている。第２状態は、睡眠状態であってもよい。この場合、「調子」のサブ項目には、寝つき易さ、または、睡眠の質などを示す情報が格納されてもよい。図示の例では、状態情報の「よく眠れそう」は、キャラクタが良好な睡眠状態を保つことにより、良い夢を見る確率が高いことを示す。キャラクタが良い夢を見ると、ユーザにとって希少価値が高い内容を含む日記データが生成される。すなわち、「調子」の状態情報に基づいて、キャラクタを寝かしつけた場合に、希少価値が高い日記データが生成される確率が決定される。

放置パート進行部１１５は、キャラクタごとの「報酬」および「調子」のサブ項目を、定期的に、または、所定のトリガに基づいて、適時に変動させてもよい。

放置パート進行部１１５は、同図に示す放置キャラクタ情報を参照して、寝かしつけの対象となるキャラクタ一覧を生成し、該一覧を、ステップＳ１０１の前に、表示部１５２に表示する。

（日記データ）
図１５の（Ａ）は、日記データのデータ構造の一例を示す図である。日記データは、ステップＳ１０８とステップＳ１２０との間の任意のタイミングで、放置パート進行部１１５によって、生成される。日記データは、執筆者、日時、本文、コメント、背景画像、前景画像の各項目を含んでいてもよい。

執筆者の項目には、日記を記したキャラクタという体裁で、放置パートで睡眠状態に遷移させられたキャラクタの名前が格納される。

日時の項目には、執筆者が夢を見た日時という体裁で、該執筆者であるキャラクタが、放置パートにおいて睡眠状態から覚醒状態に復帰した日時が格納される。時間は、時分を正確に示す情報でなくとも、朝、昼、夜などのおおよその時間帯を示す情報であってもよい。

本文の項目には、執筆者が見た夢の内容を記した文章という体裁で、執筆者であるキャラクタに基づいて放置パート進行部１１５が生成した文章が格納される。コメントの項目には、執筆者が見た夢に対して述べた感想という体裁で、執筆者であるキャラクタに基づいて放置パート進行部１１５が生成した文章が格納される。これらの文章は、キャラクタに設定されているパーソナリティに応じて、該キャラクタが、ストーリーパートの物語の中で普段話すときの語り口調になるように放置パート進行部１１５が生成してもよい。

背景画像の項目には、執筆者が見た夢を表すイラストのうち、背景画像として採用される静止画の識別情報が格納される。例えば、ＩＤ、ファイル名または格納先を示すアドレスなどが格納される。

前景画像の項目には、執筆者が見た夢を表すイラストのうち、前景画像として採用される動画内のフレームを特定する情報が格納される。フレームは、例えば、キャラクタ名と、行為名または行為を識別する情報と、動画内の何番目のフレームかを特定する情報と、右配置用か左配置用かを特定する情報とによって一意に特定される。

図１５の（Ｂ）は、希少度が高い日記データのデータ構造の一例を示す図である。放置パート進行部１１５は、執筆者とゆめの登場人物との特定の組み合わせ、ゆめの登場人物と行為との特定の組み合わせなどに応じて、執筆者が「レアな夢」を見たという体裁で、通常の日記データよりも内容が充実した希少度が高い日記データを生成してもよい。例えば、希少度が高い日記データにおいては、通常の日記データと比較して、コメントの内容が充実していてもよいし、イラストに使われる背景画像または前景画像として、再生回数が少なく、絵柄が豪華な画像が採用されてもよい。

（本文の素材データベース）
サーバ２００の記憶部２２０には、さらに、日記データにおける本文を生成するためのテキストの素材ＤＢが格納されている。素材ＤＢとして、例えば、夢に登場するキャラクタの呼称を集積するキャラクタ呼称ＤＢと、夢に出てくる場所の呼称を集積する場所呼称ＤＢと、夢に登場するキャラクタが実施する行為の呼称を集積する行為呼称ＤＢとの３つが記憶部２２０に格納されている。

キャラクタ呼称ＤＢは、あるキャラクタが他のキャラクタを指し示す場合に用いる呼称を集積する。ストーリーパートでは、キャラクタとキャラクタとの間には様々関係性が設定されており、１人のキャラクタは、他のキャラクタから、呼び捨て、愛称、敬称など、様々な呼称で呼ばれている。ストーリーパートの物語で構築されたゲームの世界観を壊さないように、日記データの本文においてキャラクタを指し示す文字列として、ストーリーパートにおいて設定されている呼称が採用されることが好ましい。

キャラクタ呼称ＤＢにおいて、呼称は、呼ぶ側のキャラクタのＩＤと、呼ばれる側のキャラクタのＩＤとに関連付けて格納されている。本実施形態では、執筆者が自身が登場する夢を見ることもあり得るとする。そこで、呼ぶ側のキャラクタのＩＤと、呼ばれる側のキャラクタのＩＤとが同じレコードには、該キャラクタが自分のことを指すときの一人称を格納すればよい。

場所呼称ＤＢには、夢が展開されると想定されている場所の呼称が複数格納されている。場所の呼称は、背景画像と１対１で対応付けられて格納されてもよい。

行為呼称ＤＢには、夢でキャラクタに実施させる行為として想定されている行為の呼称が複数格納されている。便宜上「呼称」としているが、行為を指す文字列は、本文における後述の定型部分「ていた。」が、文法上正しく後に続くように構成される。例えば、行為呼称ＤＢには、「つまみ食いし」、「踊っ」、「トイレを探し」、「昨日の夜ごはんを聞い」などの文字列が格納されている。行為の呼称には、キャラクタごとに、当該キャラクタが当該行為を実施しているように見えるフレームを特定する情報が紐付けられている。例えば、行為の呼称「つまみ食いし」には、すべてのキャラクタ分の、動画「お菓子を食べる」の中の１フレームが紐付けられている。夢の中の行為がつまみ食いに決定された場合、放置パート進行部１１５は、登場キャラクタの動画「お菓子を食べる」の中の１フレームをイラストの前景画像をとして用いることができる。

図１５に示した日記データの本文は、一例として、定型部分と非定型部分とで構成され
る。定型部分は、例えば、「ＡとＢが、ＣでＤていた。」のうちの、アルファベットの部分以外の部分を指す。定型部分は、すべての日記データの本文において、共通するである。非定型部分は、上述の各アルファベットの部分である。項目Ａは、夢に登場する１人目のキャラクタに対応し、項目Ｂは、夢に登場する２人目のキャラクタに対応し、項目Ｃは、夢が展開されている場所に対応し、項目Ｄは、夢に登場する２人のキャラクタが実施している行為に対応している。

放置パート進行部１１５は、夢に登場する２人のキャラクタを、本ゲームに登場するキャラクタの中からランダムで決定してもよい。放置パート進行部１１５は、睡眠状態にあるキャラクタ（執筆者）に基づいて、夢に登場する２人のキャラクタのそれぞれの呼称をキャラクタ呼称ＤＢから取得する。放置パート進行部１１５は、呼ぶ側である執筆者のキャラクタＩＤと、呼ばれる側となる夢に登場するキャラクタのキャラクタＩＤとに関連付けられた呼称をキャラクタ呼称ＤＢから取得すればよい。放置パート進行部１１５は、取得した２つの呼称を、本文の項目Ａおよび項目Ｂに埋める。

放置パート進行部１１５は、夢が展開される場所の呼称を場所呼称ＤＢからランダムで取得し、項目Ｃを埋める。放置パート進行部１１５は、夢に登場する２人のキャラクタに実施させる行為の呼称を行為呼称ＤＢからランダムで取得し、項目Ｄを埋める。これにより、放置パート進行部１１５は、睡眠状態にあるキャラクタに基づいて、本文を自動で生成することができる。

（コメントの素材データベース）
サーバ２００の記憶部２２０には、さらに、日記データにおけるコメントを生成するためのテキストの素材ＤＢ（コメントＤＢ）が格納されている。

コメントＤＢは、夢を見たキャラクタ本人（執筆者）が見た夢の内容に対して述べた感想という体裁の文章を集積している。コメントＤＢにおいて、該文章は、執筆者と該執筆者が見た夢の中で実施されていた行為との組み合わせごとに用意されていてもよい。

放置パート進行部１１５は、上述のようにして、本文の項目Ｄを埋める行為を決定したあと、寝かしつけられたキャラクタ（執筆者）と、決定した行為との組み合わせに対応付けられている文章をコメントＤＢから取得する。

（日記データの生成手順）
放置パート進行部１１５は、上述のように、執筆者に基づいて、本文における項目Ａ～Ｄを決定し、各素材ＤＢから取得した各文字列を埋めて本文を完成させる。放置パート進行部１１５は、さらに、執筆者が選択されたときに関連付けられていた状態情報を加味して、項目Ａ～Ｄを決定してもよい。放置パート進行部１１５は、項目Ｃに基づいて特定される背景画像と、項目ＡおよびＤに基づいて特定される左側に配置されるキャラクタの前景画像と、項目ＢおよびＤに基づいて特定される右側に配置されるキャラクタの前景画像とを合成して、見た夢の内容を表すイラストを生成する。放置パート進行部１１５は、執筆者と項目Ｄとに基づいて特定されるコメントの文章をコメントＤＢから取得する。放置パート進行部１１５は、執筆者と、上述のように生成した本文と、上述のように取得したコメントと、上述のように合成したイラストとを含む日記データを生成する。放置パート進行部１１５は、執筆者が睡眠状態から覚醒状態に復帰したとき、上述の日記データに、さらに、該執筆者が覚醒状態に復帰した日時を紐付けて、日記データを完成させる。

（キャラクタ選択画面）
図１６は、表示部１５２に表示されるキャラクタ選択画面の一例を示す図である。放置パート進行部１１５は、例えば、図示のキャラクタ選択画面４００を、放置パートのトップ画面を表示した後、ステップＳ１０１を実行するまでの間に表示する。

キャラクタ選択画面４００は、キャラクタリスト４０１をＵＩ部品として含む。キャラクタリスト４０１は、放置パートで寝かしつけが可能なキャラクタを一覧でユーザに提示するとともに、寝かしつけるキャラクタを選択するための入力操作を受け付けるためのＵＩ部品である。

キャラクタリスト４０１は、キャラクタと、該キャラクタの状態情報を示すアイコンとを含む。アイコン４０２は、図１４に示す状態情報のうち、「報酬」のサブ項目に対応する。放置パート進行部１１５は、「報酬」のサブ項目において、赤、青、黄のいずれかの属性が設定されているキャラクタには、赤、青、黄のいずれかの属性を示すアイコン４０２を付す。アイコン４０３は、「調子」のサブ項目に対応する。放置パート進行部１１５は、「調子」のサブ項目において、「よく眠れそう」の調子が設定されているキャラクタには、良い夢を見る確率が高いことを示すアイコン４０３を付す。

放置パート進行部１１５は、例えば、キャラクタリスト４０１内のキャラクタに対するタップ操作を、寝かしつけるキャラクタを選択する入力操作（第３入力操作）として受け付ける。これにより、ユーザは、アイコン４０２およびアイコン４０３などに基づいて各キャラクタの状態を確認しながら、寝かしつけるキャラクタを選択することができる。

（導入画面）
図１７の（Ａ）は、表示部１５２に表示される導入画面の一例を示す図である。導入画面は、放置パートを開始するための指示をユーザが入力するための画面である。放置パート進行部１１５は、例えば、図示の導入画面５００を、ステップＳ１０２を実行してからステップＳ１０６を実行するまでの間に表示する。

導入画面５００は、キャラクタ５０１と、手アイコン５０２とをＵＩ部品として含む。キャラクタ５０１は、ユーザによって選択されたキャラクタを示すＵＩ部品である。手アイコン５０２は、キャラクタ５０１に対して作用を及ぼすオブジェクトを可視化したものであって、ユーザに対して、入力操作を促すためのＵＩ部品である。ここでの入力操作とは、寝かしつけの対象として選択された上述のキャラクタを睡眠状態に遷移させるための入力操作（第１入力操作）である。放置パート進行部１１５は、例えば、手アイコン５０２をタッチした状態で、任意の方向に往復でスライド操作を繰り返す操作を第１入力操作として受け付ける。これにより、ユーザは、手アイコン５０２を操作してキャラクタ５０１に対して作用を及ぼし、キャラクタ５０１を睡眠状態に遷移させて放置パートの実行開始を指示することができる。

（実行画面）
図１７の（Ｂ）は、表示部１５２に表示される実行画面の一例を示す図である。実行画面は、放置パートが実行され、ユーザの操作を必要とすることなく進行している間に、その進行状況をユーザに提示するための画面である。放置パート進行部１１５は、例えば、図の実行画面６００を、ステップＳ１１０、および、ステップＳ１１４を実行するときに表示する。

実行画面６００は、キャラクタ６０１と、進行状況６０２と、閲覧ボタン６０３と、キャンセルボタン６０４とをＵＩ部品として含む。キャラクタ６０１は、第２状態に遷移中のキャラクタを示すＵＩ部品である。キャラクタ６０１は、第１状態にあるキャラクタ５０１から第２状態に遷移したことが分かるように、キャラクタ５０１とは異なる表示態様で表示される。進行状況６０２は、第２状態から再び第１状態に復帰するまでの残り時間をユーザに提示するためのＵＩ部品である。閲覧ボタン６０３は、ユーザが所有する日記を閲覧するための画面を呼び出すＵＩ部品である。キャンセルボタン６０４は、所定の時間が満了するのを待たずに、放置パートの実行を取り止めるためのＵＩ部品である。放置パート進行部１１５は、ステップＳ１１５において、キャンセルボタン６０４に対するタップ操作を、寝かしつけをキャンセルする入力操作（第５入力操作）として受け付ける。

所定の時間が満了した後、放置パート進行部１１５は、ステップＳ１１７にて、実行画面６００を不図示の復帰直前画面に切り替えてもよい。復帰直前画面は、例えば、進行状況６０２が、残り時間の代わりに、キャラクタ６０１がいつでも覚醒状態に復帰できることを表した通知を提示することにより構成される。放置パート進行部１１５は、ステップＳ１１８にて、復帰直前画面を介してキャラクタ６０１に対する所定の入力操作を受け付けたことに応答して、キャラクタ６０１を睡眠状態から覚醒状態に復帰させる。

（閲覧パートの処理フロー）
図１８は、放置パート進行部１１５が実行する放置パートのうち、閲覧パートの処理の流れを示すフローチャートである。

ステップＳ２０１では、放置パート進行部１１５は、コンテンツの一覧表示を指示する入力操作を受け付ける。例えば、図１７の（Ｂ）に示す実行画面６００の閲覧ボタン６０３に対するタップ操作を、該入力操作として受け付ける。

ステップＳ２０２では、放置パート進行部１１５は、コンテンツを一覧表示する一覧画面（第１画面）を表示部１５２に表示する。

ステップＳ２０３では、放置パート進行部１１５は、一覧画面を介して、閲覧するコンテンツを指定する入力操作（第２入力操作）を受け付ける。放置パート進行部１１５は、該入力操作を受け付けると、ステップＳ２０３のＹＥＳからステップＳ２０４に進む。

ステップＳ２０４では、放置パート進行部１１５は、第２入力操作によって指定されたコンテンツ、具体的は、日記データを表示部１５２に表示する。

ステップＳ２０５では、放置パート進行部１１５は、日記データと併せて、該日記データを他のアプリケーションで共有できるようにするための共有ボタンを同じ画面に表示してもよい。

ステップＳ２０６では、放置パート進行部１１５は、共有ボタンに対するユーザの入力操作を受け付ける。放置パート進行部１１５は、該入力操作を受け付けると、ステップＳ２０６のＹＥＳからステップＳ２０７に進む。

ステップＳ２０７では、放置パート進行部１１５は、ステップＳ２０４で表示部１５２に表示している日記データを、他のアプリケーションに共有させる。他のアプリケーションとしては、例えば、ＳＮＳ（Social Networking Service）アプリケーション、電子メールアプリケーション、メモ帳アプリケーション、画像保管アプリケーションなどが想定される。ＳＮＳアプリケーションとしては、例えば、ＬＩＮＥ（登録商標）などのメッセージ交換アプリケーション、Ｔｗｉｔｔｅｒ（登録商標）などの短文投稿アプリケーション、および、Ｆａｃｅｂｏｏｋ（登録商標）などの情報共有アプリケーションなどが想定されている。これらのＳＮＳアプリケーションに日記データを共有させることにより、ユーザは、ＳＮＳアプリケーションを活用して、自身が獲得した日記データを他のユーザに広く公開することができる。さらに、他のアプリケーションとしては、ＷｉＦｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ(登録商標)または赤外線などを使用した無線通信アプリケーションが想定される。これにより、ユーザは、近距離通信が可能な間柄の他のユーザと、日記データを共有することができる。

（日記データベース）
図１９は、日記データベース（以下、日記ＤＢ）のデータ構造の一例を示す図である。日記ＤＢは、ユーザが所有する日記データを管理するためのものであり、ユーザがごとに生成される。日記ＤＢは、ユーザ端末１００の記憶部１２０およびサーバ２００の記憶部２２０に記憶されており、ユーザ端末１００とサーバ２００との間で共有されている。

日記ＤＢは、日時、執筆者、お気に入り、今月、先月、日記データの各項目を含んでいてもよい。日時の項目では、図１５に示す日記データに関連付けられている日時が参照される。執筆者の項目では、図１５に示す日記データに関連付けられている執筆者が参照される。

お気に入りの項目には、該日記データがユーザによってお気に入りに指定されているか否かを示すフラグが格納されている。本実施形態では、日記データは、該日記データが付与された月の翌々月の末日まで保存され、この閲覧期限を過ぎると該日記ＤＢから抹消されるものとする。しかし、ユーザがお気に入りに指定した日記データは、例えば、最大３０個まで、閲覧期限を無視して日記ＤＢに保存できるものとする。該項目の「１」は、ユーザが、該日記データをお気に入りに指定していることを指し、「０」は、ユーザが、該日記をお気に入りに指定していないことを指す。放置パート進行部１１５は、閲覧期限を過ぎると、該項目が「０」の日記データを日記ＤＢから抹消する。

今月の項目には、該日記データが今月に付与されたものであるか否かを示すフラグが格納されている。先月の項目には、該日記データが先月に付与されたものであるか否かを示すフラグが格納されている。

例えば、今月が「２０１９年３月」である場合、２０１９年３月にユーザに付与された日記データの該項目には、「１」が格納され、それ以外の年月に付与された日記データの該項目には「０」が格納される。放置パート進行部１１５は、現在時刻が次月、例えば、「４月」に移行すると、２０１９年３月にユーザに付与された日記データの今月の項目を、「１」から「０」に更新し、先月の項目を「０」から「１」に更新する。放置パート進行部１１５は、現在時刻が次々月、例えば、「５月」に移行すると、２０１９年３月にユーザに付与された日記データを、閲覧期限が到来したことに伴い、お気に入りに指定された日記データを除き、日記ＤＢから抹消する。

日記データの項目には、日記データのデータ本体（図１５）または該データ本体が格納されている場所を示すアドレスが格納されている。

放置パート進行部１１５は、日記ＤＢを以上のようにして管理し、一覧画面が呼び出された場合には、常に最新の日記ＤＢに基づいて、一覧画面を生成する。一覧画面から日記データが指定された場合には、指定された日記データを、上述のアドレスから読み出して、表示部１５２に表示する。

（一覧画面）
図２０の（Ａ）は、表示部１５２に表示される一覧画面の一例を示す図である。放置パート進行部１１５は、例えば、図示の一覧画面７００を、ステップＳ２０２を実行するときに表示する。

一覧画面７００は、タブ７０１～７０３と、日記リスト７０４とをＵＩ部品として含む。日記データは、例えば、「お気に入り」、「先月」および「今月」の３つのグループに分類される。タブ７０１は、お気に入りに分類されている日記データの日記リスト７０４を呼び出すためのＵＩ部品である。タブ７０２は、先月のグループに分類されている日記データの日記リスト７０４を呼び出すためのＵＩ部品である。タブ７０３は、今月のグループに分類されている日記データの日記リスト７０４を呼び出すためのＵＩ部品である。図示の例では、今月の日記データの一覧が表示されているが、ユーザは、お気に入りに登録した日記データの日記リストに切り替えたい場合は、タブ７０１を、先月の日記データの日記リストに切り替えたい場合は、タブ７０２を、それぞれ、タップすればよい。

日記リスト７０４は、日記アイコン７０５と閲覧期限７０６とをＵＩ部品として含んでいてもよい。日記アイコン７０５は、１つの日記データに対応するアイコンである。日記アイコン７０５は、執筆者、日時、および、お気に入りに登録されている日記データか否かを示すお気に入りアイコン７０７を含んでいてもよい。閲覧期限７０６は、グループ内の各日記データの閲覧期限をユーザに通知するためのＵＩ部品である。ユーザは、日記アイコン７０５に含まれている情報を確認して、閲覧したい日記データを探し、所望の日記データの日記アイコン７０５に対して閲覧を指示する入力操作（第２入力操作）を行うことができる。放置パート進行部１１５は、第２入力操作を受け付けて、操作された日記アイコン７０５に対応する日記データを、後述する図２０の（Ｂ）のように表示部１５２に表示する。

（日記画面）
図２０の（Ｂ）は、表示部１５２に表示される日記画面の一例を示す図である。放置パート進行部１１５は、例えば、図示の日記画面８００を、ステップＳ２０４を実行するときに表示する。

日記画面８００は、日記データ８０１と、共有ボタン８０２と、管理ボタン８０３とをＵＩ部品として含む。日記データ８０１は、１つの日記データをユーザに提示するためのものであり、ＵＩ部品として、日付８０４、執筆者８０５、本文８０６、コメント８０７、および、イラスト８０８を含む。これらのＵＩ部品は、図１５に示す日記データを構成する各項目に基づいて生成される。

共有ボタン８０２は、日記データを他のアプリケーションに共有させることを指示するためのＵＩ部品である。ユーザは、共有ボタン８０２をタップすることにより、例えば、ＳＮＳアプリケーションに、日記画面８００に表示されている日記データ８０１の静止画データを共有させることができる。

管理ボタン８０３は、日記データのお気に入りの登録と解除とを指示するためのＵＩ部品である。ユーザは、お気に入りに登録されている日記データ８０１が表示されている間に、管理ボタン８０３をタップすることにより、該日記データ８０１のお気に入りの設定を解除することができる。反対に、ユーザは、お気に入りに登録されている日記データ８０１が表示されている間に管理ボタン８０３をタップして、該日記データ８０１をお気に入りに登録することができる。

以上のように、ユーザは、付与された日記データを、一覧画面７００および日記画面８００を介して、いつでも閲覧し、楽しむことができる。

〔実施形態２〕
本実施形態では、ゲームシステム１において、ユーザごとに、寝かしつけメータが管理されていてもよい。寝かしつけメータは、ユーザが、放置パートをどれだけプレイしたかを管理するためのパラメータであり、ユーザがキャラクタを所定の時間寝かしつけて日記データを取得する度に、パラメータ値が加算されるものである。放置パート進行部１１５は、キャラクタが所定の時間寝かしつけられる度に、ステップＳ１２１にて、寝かしつけメータのパラメータ値を加算する。蓄積されたパラメータ値は、ゲーム内価値を有する他のゲーム媒体、例えば、抽選チケットと交換が可能である。

パラメータ値と交換できる抽選チケットには、グレードに応じていくつかの種類があってもよい。交換するパラメータ値が大きいほど、グレードの高い抽選チケットと交換できるものとする。グレードが高い抽選チケットほど、希少価値がより高いカードがより当選しやすい母集団が紐付けられている。グレードが高い抽選チケットに基づいて抽選が実行された場合、グレードが低い抽選チケットと比較して希少価値が高いカードが当選しやすく、したがって、グレードが高い抽選チケットほどゲーム内価値が高い。

抽選チケットは、例えば、７段階のグレードに対応して７種類ある。希少度Ｎのカードからなる母集団が紐付けられた第１抽選チケット、希少度Ｎおよび希少度Ｒのカードからなる母集団が紐付けられた第２抽選チケット、希少度Ｒのカードからなる母集団が紐付けられた第３抽選チケット、希少度Ｒおよび希少度ＳＲのカードからなる母集団が紐付けられた第４抽選チケット、希少度ＳＲのカードからなる母集団が紐付けられた第５抽選チケット、希少度ＳＲおよび希少度ＳＳＲのカードからなる母集団が紐付けられた第６抽選チケット、希少度ＳＳＲのカードからなる母集団が紐付けられた第７抽選チケットの７種類である。つまり、第７抽選チケットが使用されると、希少度ＳＳＲのカードが１００％当選するので、第７抽選チケットは、ユーザにとって最もゲーム内価値が高い抽選チケットとなる。

例えば、寝かしつけメータは、０～７００点の値を蓄積できるものとし、１００点で第１抽選チケット、２００点で第２抽選チケット、以降、交換する値が１００点増えるごとに１段階上のグレードの抽選チケットと交換が可能であり、７００点満点で、最もグレードが高い第７抽選チケットとの効果が可能となる。値との交換により、抽選チケットが付与されると、寝かしつけメータのパラメータ値はリセットされて、０からカウントが再開される。ユーザは、希少度が高いカードが当選しにくいが、早く手に入るグレードが低めの抽選チケットを使ってたくさんの回数の抽選に興じてもよいし、希少度が高いカードが当選しやすいが、手に入りにくいグレードが高めの抽選チケットを使って、少ないチャンスで、希少度が高いカードを狙う抽選に興じてもよい。

さらに、寝かしつけメータのパラメータ値の上昇量が異なる複数のコースを設定し、ユーザに所望のコースを選択させてから、放置パートをプレイさせてもよい。複数のコースとしては、例えば、２か月程度で寝かしつけメータを７００点満点にできる２か月コースと、３か月程度で寝かしつけメータを７００点満点にできる３か月コースと、半年程度で寝かしつけメータを７００点満点にできる半年コースとが想定されてもよい。

放置パート進行部１１５は、ユーザによって予め選択されたコースに応じて、寝かしつけ１回につき加算するパラメータ値を決定する。期間が長いコースほど、ゲーム内価値が高い報酬と交換できるようにすることが好ましい。例えば、３か月コースで貯められた７００点と交換される報酬よりも、半年コースで貯められた７００点と交換される報酬の方がゲーム内価値が高くなるように報酬を定めればよい。

〔変形例〕
放置パート進行部１１５は、ステップＳ１１４において、第２状態にある第１キャラクタと、該第１キャラクタが復帰したことに応じて付与される予定のコンテンツの一部とを示す第２画面を表示してもよい。具体的には、放置パート進行部１１５は、実行画面６００において、キャラクタ６０１が見ている夢の内容の一部を表示してもよい。例えば、放置パート進行部１１５は、キャラクタ６０１が見ている夢に登場する２人のキャラクタのアイコンを実行画面６００に表示してもよい。ユーザは、２人のキャラクタが目当てのキャラクタでない場合には、キャンセルボタン６０４を操作して、寝かしつけを中止し、放置パートを最初からやり直すことができる。

ステップＳ１０４で使用できる消費アイテムとして、睡眠状態を維持する所定の期間を短縮できる、いわゆる、時短アイテムがあってもよい。例えば、ステップＳ１０４で、時短アイテムが使用された場合には、通常、覚醒状態に復帰するまで８時間を要するところ、３時間に短縮されてもよい。

放置パート進行部１１５は、キャラクタを睡眠状態に維持する所定の時間を、複数の中からユーザに選ばせてもよい。例えば、１時間、３時間、８時間の中からユーザに選ばせる。放置パート進行部１１５は、選ばれた所定の時間が長いほど、ユーザに付与する報酬のゲーム内価値を高くしたり、ゲーム内価値が高い報酬がドロップする確率を上げたりしてもよい。

放置パート進行部１１５は、所定の時間を満了せずにキャラクタを覚醒状態に復帰させたとき、つまり、ユーザが、キャンセルボタン６０４を押下して放置パートを中止したとき、報酬を全く付与しなくてもよいし、中止されるまでの進捗に応じて報酬を部分的に付与してもよい。例えば、途中でキャンセルされた場合には、放置パート進行部１１５は、日記データは付与せず、強化アイテムだけをユーザに付与してもよいし、ユーザに付与する強化アイテムの数量を減らしてもよい。

〔ソフトウェアによる実現例〕
制御部２１０の制御ブロック（特に、進行支援部２１１）、ならびに、制御部１１０の制御ブロック（特に、ストーリーパート進行部１１１、練習パート進行部１１２、実践パート進行部１１３、抽選パート進行部１１４、および、放置パート進行部１１５）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。

後者の場合、制御部２１０または制御部１１０、もしくはその両方の機能を備えた情報処理装置は、各機能を実現するソフトウェアであるプログラムの命令を実行するＣＰＵ、上記プログラムおよび各種データがコンピュータ（またはＣＰＵ）で読み取り可能に記録されたＲＯＭ（Read Only Memory）または記憶装置（これらを「記録媒体」と称する）、上記プログラムを展開するＲＡＭ（Random Access Memory）などを備えている。そして、コンピュータ（またはＣＰＵ）が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記コンピュータに供給されてもよい。なお、本発明の一態様は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

〔付記事項〕
本発明の一側面に係る内容を列記すると以下のとおりである。

（項目１） ゲームプログラム（１３１、２３１）について説明した。本開示のある局面によると、ゲームプログラムは、プロセッサ（１０、２０）およびメモリ（１１、２１）を備えるコンピュータ（ユーザ端末１００およびサーバ２００の少なくとも一方）により実行される。ゲームプログラムは、プロセッサに、ゲームプログラムに基づくゲームに登場する複数のキャラクタのうちの少なくとも１つの第１キャラクタに対する、ユーザの第１入力操作に応じて、該第１キャラクタを第１状態から第２状態へ遷移させるステップ（Ｓ１０７）と、第１キャラクタが第２状態に遷移してから、所定の時間が経過したことに応じて、第１キャラクタを第１状態に復帰させるステップ（Ｓ１１９）と、第１キャラクタが第１状態に復帰したことに応じて、第２状態であった第１キャラクタに基づくコンテンツ（日記データ）をユーザに付与するステップ（Ｓ１２０）と、ユーザの第２入力操作に応じて、指定されたコンテンツを表示部に表示するステップ（Ｓ２０４）と、を実行させる。

（項目２） （項目１）において、遷移させるステップでは、第１入力操作に応じて、第１キャラクタを、ユーザの操作によらずに進行する、ゲーム内の第１パート（放置パート）が進行していない第１状態（覚醒状態）から、第１パートが進行している第２状態（睡眠状態）へと遷移させ、復帰させるステップでは、第１パートが進行してから、所定の時間が経過したことに応じて、該第１パートを終了させてもよい。

（項目３） （項目１）または（項目２）において、コンテンツを付与するステップでは、第１キャラクタが、第２状態であった間に体験した出来事という体裁で、該出来事を表現したコンテンツをユーザに付与してもよい。

（項目４） （項目１）から（項目３）までのいずれか１項目において、複数のキャラクタのそれぞれには該キャラクタの状態を示す第１情報（状態情報）が関連付けられており、ゲームプログラムは、プロセッサに、ユーザの第３入力操作に応じて、複数のキャラクタの中から、第２状態へ遷移させる第１キャラクタを特定するステップと、第３入力操作に応じて特定された第１キャラクタと、第１キャラクタに関連付けられている第１情報とに基づいて、ユーザに付与するコンテンツを生成するステップとを実行させてもよい。

（項目５） （項目４）において、メモリにおいて、キャラクタが居る所定の場所を表す複数の第１の素材データと、所定の行為を実施するキャラクタを表す複数の第２の素材データとが記憶されており、ゲームプログラムは、プロセッサに、第１の素材データ、および、第２の素材データの少なくともいずれか一方を用いて、第２パート（ストーリーパート、練習パート、実践パート）を進行させるステップを実行させ、コンテンツを生成するステップでは、第１キャラクタと第１情報とに基づいて選択されたメモリに記憶されている１以上の素材データを用いて、コンテンツを生成してもよい。

（項目６） （項目４）または（項目５）において、ゲームプログラムは、プロセッサに、ＳＮＳアプリケーションを介してコンテンツを公開することを指示するためのＵＩ部品（共有ボタン）を表示するステップ（Ｓ２０５）を実行させてもよい。

（項目７） （項目１）から（項目６）までのいずれか１項目において、ゲームプログラムは、プロセッサに、第１キャラクタが所定の時間が満了したことに伴って第２状態から第１状態に復帰した場合に、ユーザに関連付けられたパラメータにおけるパラメータ値を加算するステップ（Ｓ１２１）と、パラメータが示すパラメータ値と引き換えに、引き換えるパラメータ値が大きいほど、ゲームにおいて価値が高い報酬を付与するステップとを実行させてもよい。

（項目８） （項目７）において、報酬を付与するステップは、報酬として、キャラクタが紐付けられたカードを選択する抽選処理を実施するために必要な抽選アイテム（抽選チケット）をユーザに付与するステップであって、該報酬を付与するステップでは、引き換えるパラメータ値が大きいほど、希少価値がより高いカードがより当選しやすい母集団が紐付けられた抽選アイテムを付与し、ゲームプログラムは、プロセッサに、ユーザが所有する抽選アイテムと引き換えに、該抽選アイテムに紐付けられた母集団から選択されたカードを、該ユーザに付与するステップを実行させてもよい。

（項目９） （項目７）または（項目８）において、パラメータは、パラメータ値の上昇量に応じて複数種類あり、複数種類の中の１つのパラメータがユーザに関連付けられており、加算するステップでは、ユーザに関連付けられたパラメータのパラメータ値を、該パラメータに設定されている上昇量に基づいて加算し、報酬を付与するステップでは、ユーザに関連付けられているパラメータの上昇量が小さいほど、該パラメータが示すパラメータ値と引き換えにユーザに付与する報酬の価値を高くしてもよい。

（項目１０） （項目１）から（項目９）までのいずれか１項目において、コンテンツを付与するステップでは、コンテンツに、該コンテンツをユーザに付与した日付を関連付けてメモリに保存し、ゲームプログラムは、プロセッサに、メモリに保存された複数のコンテンツを、日付ごとに一覧表示する第１画面（一覧画面７００）を表示するステップ（Ｓ２０２）と、第１画面に一覧表示されたコンテンツに対するユーザの入力操作を、該コンテンツを指定する第２入力操作として受け付けるステップ（Ｓ２０３）と、を実行させてもよい。

（項目１１） （項目４）において、ゲームプログラムは、プロセッサに、ユーザの第４入力操作に応じて、該ユーザが所有する消費アイテムのうち、該第４入力操作によって指定された消費アイテム（快眠グッズ）を消費するステップ（Ｓ１０４）を実行させ、コンテンツを生成するステップでは、第１キャラクタと、該第１キャラクタに関連付けられている第１情報と、消費された消費アイテムとに基づいて、ユーザに付与するコンテンツを生成してもよい。

（項目１２） （項目１）から（項目１１）までのいずれか１項目において、ゲームプログラムは、プロセッサに、第２状態にある第１キャラクタと、該第１キャラクタが復帰したことに応じて付与される予定のコンテンツの一部とを示す第２画面（実行画面６００）を表示するステップ（Ｓ１１４）と、第２画面に対する、ユーザの第５入力操作に応じて、該第１キャラクタを、所定の時間が経過する前に第１状態に復帰させるステップと、を実行させてもよい。

（項目１３） ゲームプログラムを実行する方法を説明した。本開示のある局面によると、ゲームプログラムは、プロセッサおよびメモリを備えるコンピュータにより実行される。該方法は、プロセッサが（項目１）に記載の各ステップを実行する方法である。（項目１３）に係る方法は、（項目１）に係るゲームプログラムと同様の作用効果を奏する。

（項目１４） 情報処理装置を説明した。本開示のある局面によると、該情報処理装置は、（項目１）に係るゲームプログラムを記憶するメモリ（メモリ１１、記憶部１２０）と、該ゲームプログラムを実行することにより、情報処理装置（ユーザ端末１００）の動作を制御するプロセッサ（プロセッサ１０、制御部１１０）とを備える。（項目１４）に係る情報処理装置は、（項目１）に係るゲームプログラムと同様の作用効果を奏する。

１ ゲームシステム、２ ネットワーク、１０，２０ プロセッサ、１１，２１ メモリ、１２，２２ ストレージ、１３，２３ 通信ＩＦ（操作部）、１４，２４ 入出力ＩＦ（操作部）、１５ タッチスクリーン（表示部、操作部）、１７ カメラ（操作部）、１８ 測距センサ（操作部）、１００ ユーザ端末（情報処理装置）、１１０，２１０ 制御部、１１１ ストーリーパート進行部、１１２ 練習パート進行部、１１３ 実践パート進行部、１１４ 抽選パート進行部、１１５ 放置パート進行部、１２０，２２０ 記憶部、１３１，２３１ ゲームプログラム、１３２ ゲーム情報、１３３ ユーザ情報、１５１ 入力部（操作部）、１５２ 表示部、２００ サーバ、２１１ 進行支援部、１０１０ 物体、１０２０ コントローラ（操作部）、１０３０ 記憶媒体

Claims (14)

1. ゲームプログラムであって、
   前記ゲームプログラムは、プロセッサ、メモリおよび表示部を備えるコンピュータにより実行されるものであり、
   前記ゲームプログラムは、前記プロセッサに、
   前記ゲームプログラムに基づくゲームに登場する複数のキャラクタのうちの少なくとも１つの第１キャラクタに対する、ユーザの第１入力操作に応じて、該第１キャラクタを第１状態から第２状態へ遷移させるステップと、
   前記第１キャラクタが前記第２状態に遷移してから、所定の時間が経過したことに応じて、前記第１キャラクタを前記第１状態に復帰させるステップと、
   前記第１キャラクタが前記第１状態に復帰したことに応じて、前記第２状態であった前記第１キャラクタに基づくコンテンツを前記ユーザに付与するステップと、
   前記ユーザの第２入力操作に応じて、指定された前記コンテンツを前記表示部に表示するステップと、を実行させる、ゲームプログラム。
2. 前記遷移させるステップでは、前記第１入力操作に応じて、前記第１キャラクタを、前記ユーザの操作によらずに進行する、前記ゲーム内の第１パートが進行していない前記第１状態から、前記第１パートが進行している前記第２状態へと遷移させ、
   前記復帰させるステップでは、前記第１パートが進行してから、前記所定の時間が経過したことに応じて、該第１パートを終了させる、請求項１に記載のゲームプログラム。
3. 前記コンテンツを付与するステップでは、前記第１キャラクタが、前記第２状態であった間に体験した出来事という体裁で、該出来事を表現したコンテンツを前記ユーザに付与する、請求項１または２に記載のゲームプログラム。
4. 前記複数のキャラクタのそれぞれには該キャラクタの状態を示す第１情報が関連付けられており、
   前記ゲームプログラムは、前記プロセッサに、
   前記ユーザの第３入力操作に応じて、前記複数のキャラクタの中から、前記第２状態へ遷移させる前記第１キャラクタを特定するステップと、
   前記第３入力操作に応じて特定された前記第１キャラクタと、該第１キャラクタに関連付けられている前記第１情報とに基づいて、前記ユーザに付与する前記コンテンツを生成するステップとを実行させる、請求項１から３のいずれか１項に記載のゲームプログラム。
5. 前記メモリにおいて、前記キャラクタが居る所定の場所を表す複数の第１の素材データと、所定の行為を実施する前記キャラクタを表す複数の第２の素材データとが記憶されており、
   前記ゲームプログラムは、前記プロセッサに、
   前記第１の素材データ、および、前記第２の素材データの少なくともいずれか一方を用いて、第２パートを進行させるステップを実行させ、
   前記コンテンツを生成するステップでは、前記第１キャラクタと前記第１情報とに基づいて選択された前記メモリに記憶されている１以上の前記素材データを用いて、前記コンテンツを生成する、請求項４に記載のゲームプログラム。
6. 前記ゲームプログラムは、前記プロセッサに、
   ＳＮＳアプリケーションを介して前記コンテンツを公開することを指示するためのＵＩ部品を表示するステップを実行させる、請求項４または５に記載のゲームプログラム。
7. 前記ゲームプログラムは、前記プロセッサに、
   前記第１キャラクタが前記所定の時間が満了したことに伴って前記第２状態から前記第１状態に復帰した場合に、前記ユーザに関連付けられたパラメータにおけるパラメータ値を加算するステップと、
   前記パラメータが示す前記パラメータ値と引き換えに、引き換える前記パラメータ値が大きいほど、前記ゲームにおいて価値が高い報酬を付与するステップとを実行させる、請求項１から６までのいずれか１項に記載のゲームプログラム。
8. 前記報酬を付与するステップは、前記報酬として、前記キャラクタが紐付けられたカードを選択する抽選処理を実施するために必要な抽選アイテムを前記ユーザに付与するステップであって、該報酬を付与するステップでは、引き換える前記パラメータ値が大きいほど、希少価値がより高いカードがより当選しやすい母集団が紐付けられた抽選アイテムを付与し、
   前記ゲームプログラムは、前記プロセッサに、
   前記ユーザが所有する前記抽選アイテムと引き換えに、該抽選アイテムに紐付けられた前記母集団から選択されたカードを、該ユーザに付与するステップを実行させる、請求項７に記載のゲームプログラム。
9. 前記パラメータは、前記パラメータ値の上昇量に応じて複数種類あり、前記複数種類の中の１つのパラメータが前記ユーザに関連付けられており、
   前記加算するステップでは、前記ユーザに関連付けられた前記パラメータの前記パラメータ値を、該パラメータに設定されている上昇量に基づいて加算し、
   前記報酬を付与するステップでは、前記ユーザに関連付けられているパラメータの上昇量が小さいほど、該パラメータが示す前記パラメータ値と引き換えに前記ユーザに付与する報酬の価値を高くする、請求項７または８に記載のゲームプログラム。
10. 前記コンテンツを付与するステップでは、前記コンテンツに、該コンテンツをユーザに付与した日付を関連付けて前記メモリに保存し、
    前記ゲームプログラムは、前記プロセッサに、
    前記メモリに保存された複数の前記コンテンツを、前記日付ごとに一覧表示する第１画面を表示するステップと、
    前記第１画面に一覧表示された前記コンテンツに対する前記ユーザの入力操作を、該コンテンツを指定する前記第２入力操作として受け付けるステップと、を実行させる、請求項１から９のいずれか１項に記載のゲームプログラム。
11. 前記ゲームプログラムは、前記プロセッサに、
    前記ユーザの第４入力操作に応じて、該ユーザが所有する消費アイテムのうち、該第４入力操作によって指定された消費アイテムを消費するステップを実行させ、
    前記コンテンツを生成するステップでは、前記第１キャラクタと、該第１キャラクタに関連付けられている前記第１情報と、消費された前記消費アイテムとに基づいて、前記ユーザに付与する前記コンテンツを生成する、請求項４に記載のゲームプログラム。
12. 前記ゲームプログラムは、前記プロセッサに、
    前記第２状態にある前記第１キャラクタと、該第１キャラクタが復帰したことに応じて付与される予定の前記コンテンツの一部とを示す第２画面を表示するステップと、
    前記第２画面に対する、前記ユーザの第５入力操作に応じて、該第１キャラクタを、前記所定の時間が経過する前に前記第１状態に復帰させるステップと、を実行させる、請求項１から１１のいずれか１項に記載のゲームプログラム。
13. コンピュータがゲームプログラムを実行する方法であって、
    前記コンピュータは、プロセッサ、メモリおよび表示部を備え、
    前記プロセッサが請求項１に記載の各ステップを実行する方法。
14. 情報処理装置であって、
    前記情報処理装置は、
    請求項１に記載のゲームプログラムを記憶するメモリと、
    該ゲームプログラムを実行することにより、情報処理装置の動作を制御するプロセッサと、
    表示部と、を備えている、情報処理装置。
    

Images