JP7149251B2

JP7149251B2 - 情報処理プログラム、情報処理装置、情報処理システム、および情報処理方法

Info

Publication number: JP7149251B2
Application number: JP2019207018A
Authority: JP
Inventors: 一慶泉水; 真樹安原
Original assignee: Nintendo Co Ltd
Current assignee: Nintendo Co Ltd
Priority date: 2019-11-15
Filing date: 2019-11-15
Publication date: 2022-10-06
Anticipated expiration: 2039-11-15
Also published as: US11529561B2; US20210146257A1; JP2021078589A

Description

本発明は、所定のゲーム課題をプレイヤに提示するゲーム処理が実行される情報処理システムに関する。

従来から、ゲーム内のＮＰＣにプレイヤキャラクタが話しかけることで、「依頼」や「クエスト」等とも呼ばれるゲーム課題が出され、プレイヤキャラクタを操作して、当該ゲーム課題を達成して報酬を獲得するゲームが知られている。また、このようなゲーム課題として、ＮＰＣから「アイテムＡが持ってきて欲しい」というように、所定のアイテムをＮＰＣに渡すことで達成できるようなゲーム課題も知られている。このようなゲーム課題を達成するために、プレイヤはプレイヤキャラクタを操作して、当該プレイヤキャラクタに仮想ゲーム世界において所定のアイテムを入手あるいは取得し、依頼主となるＮＰＣの場所までプレイヤキャラクタを移動し（ＮＰＣに会い）、当該ＮＰＣに当該アイテムを渡す、という操作を行う必要がある。

ここで、上記のようにプレイヤキャラクタがＮＰＣに直接会って所定のアイテムを渡す代わりに、特定のＮＰＣに指示することで、当該所定のアイテムをプレイヤキャラクタの代わりに依頼主のＮＰＣに届けてもらうというゲームシステムも知られている（例えば、非特許文献１）。

ファミ通．ｃｏｍ、"どうぶつの森ポケットキャンプがアップデートを実施。"フータの探検スゴロク"や"ぺりおの宅配便"など多数の新要素が追加！"、［online］、［令和１年１０月２９日検索］、インターネット（ＵＲＬ：https://www.famitsu.com/news/201901/30171221.html）

上記のゲームシステムは、上記ゲーム課題の達成に関するプレイヤの利便性を更に高めるという点で、更なる改良の余地があった。

それ故に、本発明の目的は、ゲーム課題を達成する際のプレイヤの利便性をより高めることができる情報処理プログラム等を提供することである。

上記目的を達成するために、例えば以下のような構成例が挙げられる。

構成例の一例は、情報処理装置のコンピュータにおいて実行される情報処理プログラムであって、コンピュータを、パラメータ管理手段と、課題管理手段と、モード切替手段と、第１達成手段と、第２達成手段として機能させる。パラメータ管理手段は、ゲームのプレイヤまたは当該ゲームのプレイヤキャラクタに関連付けられたプレイヤ関連パラメータを管理する。課題管理手段は、ゲームにおいて設定されたゲーム課題の状態を管理する。モード切替手段は、プレイヤによる切替入力に基づいて、ゲームの状態を第１モードと第２モードとで切り替える。第１達成手段は、ゲームの状態が第１モードの場合、プレイヤによりゲームがプレイされている間に、未達成のゲーム課題を達成するために行われる当該プレイヤによる操作入力に基づいて、プレイヤ関連パラメータを第１変化量だけ変化させることを条件として、ゲーム課題が達成されたと判定する。第２達成手段は、ゲームの状態が第２モードの場合、プレイヤによりゲームがプレイされていなくても、プレイヤ関連パラメータを変化させずに、または当該プレイヤ関連パラメータを第１変化量よりも小さい第２変化量だけ変化させることを条件として、ゲーム課題が達成されたと判定する。

上記構成例によれば、第１モードのときは、プレイヤは、自らの操作に基づきゲーム課題を達成でき、第２モードの時は、プレイヤがゲームをプレイしていない、すなわち、プレイヤが操作していないときでも、ゲーム課題の達成が可能となる。この際、第１モードでは、プレイヤ関連パラメータを第１変化量だけ変化させることを達成条件とするが、第２モードの場合は、当該変化を発生させない、あるいは、発生するとしても第１モードの場合より小さな変化量とする。そのため、プレイヤの操作無しでゲーム課題ができるとともに、第２モードにおけるゲーム課題達成の際にプレイヤが意図しないプレイヤ関連パラメータの減少が起こることを防ぐ、あるいは、軽減することができる。これにより、ゲーム課題を達成しようとする際のプレイヤの利便性を向上させることができる。

他の構成例として、第２達成手段は、第１達成手段または第２達成手段により達成されたと判定され得るゲーム課題のうち、当該第１達成手段によって達成されたと判定されていない当該ゲーム課題について、達成されたと判定してもよい。

上記構成例によれば、プレイヤが自らの操作で達成済みのゲーム課題は第２達成手段による処理対象から除外できる。これにより、第１達成手段で達成済みのゲーム課題が第２達成手段により達成されてしまうことで違和感をプレイヤに与えることを防ぐことができる。

更に他の構成例として、第２達成手段は、第１達成手段または第２達成手段により達成されたと判定され得るゲーム課題のうち、当該第１達成手段により達成されたと判定されていない当該ゲーム課題の全てについて、達成されたと判定してもよい。

上記構成例によれば、プレイヤが自らの操作で達成していないゲーム課題の全てを第２達成手段によって達成扱いとすることができ、プレイヤの利便性を向上できる。

更に他の構成例として、課題管理手段は、ゲーム内時間の経過または現実の時間の経過に応じてゲーム課題を更新してもよい。

上記構成例によれば、所定の時間毎に定期的にゲーム課題の内容を更新することができる、これにより、様々なゲーム課題をプレイヤに提供して、ゲームをより長く楽しませることが可能となる。

更に他の構成例として、第２達成手段は、課題管理手段によりゲーム課題の更新が行われたことに応じて、当該更新される前のゲーム課題が達成されたと判定してもよい。

上記構成例によれば、ゲーム課題を定期的に達成扱いとすることができる。

更に他の構成例として、第２達成手段は、ゲームが起動されたときに、当該ゲームを前回プレイし終えたとき以降の現実の時間経過に応じた数量のゲーム課題が達成されたものとして判定してもよい。

上記構成例によれば、ゲーム課題を達成する処理をゲーム起動時にまとめて行うため、定期的に当該処理を行う場合よりも効率的な処理が可能となる。

更に他の構成例として、課題管理手段は、プレイヤまたはプレイヤキャラクタが所有するアイテムをゲーム内のノンプレイヤキャラクタに譲渡することが達成条件であるゲーム課題を、当該ノンプレイヤキャラクタ毎に関連付けて設定してもよい。

上記構成例によれば、ノンプレイヤキャラクタ毎にゲーム課題の内容を変化させることができ、ゲーム内で様々なノンプレイヤキャラクタと会うことへの動機付けを提供できる。

更に他の構成例として、情報処理プログラムは、複数のノンプレイヤキャラクタから少なくとも１つのノンプレイヤキャラクタを指定するキャラクタ指定手段と、指定されたノンプレイヤキャラクタが、プレイヤまたはプレイヤキャラクタの代わりにゲーム課題を達成するゲーム演出を実行する演出手段としてコンピュータを更に機能させてもよい。そして、課題管理手段は、指定されたノンプレイヤキャラクタを除くノンプレイヤキャラクタ毎にゲーム課題を関連付けて設定してもよい。

上記構成例によれば、指定したノンプレイヤキャラクタがプレイヤの代わりにゲーム課題を達成するという演出を提示できる。また、指定されたノンプレイヤキャラクタからはゲーム課題が提示されないようにすることができる。これにより、プレイヤにとって違和感のない演出が可能となる。

更に他の構成例として、第２達成手段は、初めて、キャラクタ指定手段によるノンプレイヤキャラクタの指定が行われたとき、当該指定に応じて少なくとも１つのゲーム課題が達成されたと判定し、演出手段は、初めての指定に応じて達成されたゲーム課題に係るゲーム演出を実行するようにしてもよい。

上記構成例によれば、ノンプレイヤキャラクタがプレイヤの代わりにゲーム課題を達成してくれる様子を実演してプレイヤに見せることができる。これにより、第２達成手段による処理の有用性をプレイヤにわかりやすく示すことができる。

更に他の構成例として、キャラクタ指定手段は、プレイヤまたはプレイヤキャラクタが特定のアイテムを所持していることを条件として、当該特定のアイテムに対応するノンプレイヤキャラクタを指定可能としてもよい。

上記構成例によれば、指定できるノンプレイヤキャラクタの数を増やすため、様々なアイテムをゲーム内で入手させることへの動機付けをプレイヤに提供でき、ゲームの興趣性を向上させることができる。

更に他の構成例として、情報処理プログラムは、ゲーム課題が達成されたことに基づき、プレイヤまたはプレイヤキャラクタに報酬を付与する報酬付与手段としてコンピュータを更に機能させてもよい。

上記構成例によれば、積極的にゲーム課題を達成させることへの動機付けをプレイヤに提供できる。

更に他の構成例として、報酬付与手段は、第２達成手段によりゲーム課題が達成されたことによる報酬を付与する時点においてプレイヤまたはプレイヤキャラクタがゲーム内で取得し得るアイテムを、当該プレイヤまたは当該プレイヤキャラクタに更に付与するようにしてもよい。

上記構成例によれば、プレイヤが自身の操作でゲーム内においてアイテムを入手する手間を省くことができ、第２達成手段による機能をプレイヤに利用してもらうことへの動機付けを提供することもできる。

更に他の構成例として、第２達成手段は、ゲームの状態が第２モードである場合であって、プレイヤによりゲームがプレイされている間に課題管理手段によりゲーム課題の更新が行われた場合、当該更新の後でゲームの画面の遷移が行われたときに、ゲーム課題が達成されたと判定するようにしてもよい。

上記構成例によれば、課題管理手段による更新と同時に未達成のゲーム課題が達成されることによってプレイヤに違和感を与えてしまう可能性を軽減することができる。例えば、第２達成手段による処理の実現を、プレイヤキャラクタの側にいるノンプレイヤキャラクタが未達成のゲーム課題を代わりに達成するような制御で行う場合、ノンプレイヤキャラクタが側にいるにもかかわらず、未達成のゲーム課題が達成されているという違和感をプレイヤに与えることを防ぐことができる。すなわち、ゲーム内でのシーン遷移等、ノンプレイヤキャラクタが画面上に表示されなくなるような何らか節目となるタイミングで、ノンプレイヤキャラクタが未達成のゲーム課題を達成してきたように見せることができる。

更に他の構成例として、情報処理プログラムは、プレイヤの確認操作入力に基づいて、前回の当該確認操作入力以降に達成されたゲーム課題を確認できる画像を生成する確認画面生成手段としてコンピュータを更に機能させてもよい。

上記構成例によれば、プレイヤが知らない間に達成されたゲーム課題について把握させることができ、プレイヤの利便性を向上できる。

更に他の構成例として、課題管理手段は、ゲーム内時間の経過または現実の時間の経過に応じてゲーム課題を更新し、第２達成手段は、達成されたゲーム課題を確認するための確認操作入力が行われていない状態で課題管理手段によりゲーム課題が更新された場合、更新後の当該ゲーム課題についても、プレイヤ関連パラメータを変化させず、または当該プレイヤ関連パラメータを第１変化量よりも小さい第２変化量だけ変化させることを条件として、ゲーム課題が達成されたと判定してもよい。

上記構成例によれば、プレイヤがゲームをプレイしていない間（例えばログアウト期間中）に複数回ゲーム課題が更新された場合でも、これらのゲーム課題も第２達成手段による処理対象とすることができる。これにより、プレイヤの利便性を向上することができる。

更に他の構成例として、第２達成手段は、確認操作入力が行われていない状態でゲーム課題が更新された場合に当該更新後のゲーム課題が達成されたと判定する処理を、所定の回数を上限回数として繰り返し実行し、確認操作入力が行われたことに応じて、当該判定の実行回数のカウントをリセットしてもよい。

上記構成例によれば、確認操作が行われるまでに第２達成手段によって達成されたゲーム課題の情報を記憶するための記憶容量を削減することができる。

更に他の構成例として、情報処理プログラムは、第１達成手段によりゲーム課題が達成されたと判定した場合は、当該ゲーム課題に関連付けられたノンプレイヤキャラクタに対応するノンプレイヤ関連パラメータを第３変化量だけ変化させ、第２達成手段によりゲーム課題が達成されたと判定した場合は、当該ノンプレイヤ関連パラメータを変化させない、または、当該第３変化量よりも小さい第４変化量だけ当該ノンプレイヤ関連パラメータを変化させるパラメータ管理手段としてコンピュータをさらに機能させてもよい。

上記構成例によれば、例えばノンプレイヤキャラクタに親密度というパラメータを設定する場合に、第１達成手段によるゲーム課題達成の場合は、当該ゲーム課題に関連するノンプレイヤキャラクタとの親密度を高めることができる。その一方で、第２達成手段によるゲーム課題達成の場合は、第１達成手段の場合よりも親密度の上昇を鈍くすることができる。これにより、第１達成手段によるゲーム課題の達成を行わせることの動機付けをプレイヤに提供でき、第１達成手段と第２達成手段の使い分けの余地をプレイヤに提供して、ゲームの興趣性を高めることができる。

更に他の構成例として、複数のノンプレイヤキャラクタから少なくとも１つのノンプレイヤキャラクタを指定するキャラクタ指定手段と、
前記指定されたノンプレイヤキャラクタが、前記プレイヤまたは前記プレイヤキャラクタの代わりにゲーム課題を達成するゲーム演出を実行する演出手段として前記コンピュータをさらに機能させ、
前記第２達成手段により前記ゲーム課題が達成されたと判定した場合に、前記キャラクタ指定手段により指定された前記ノンプレイヤキャラクタに関連付けられた前記ノンプレイヤ関連パラメータを変化させる

上記構成例によれば、例えばノンプレイヤキャラクタに親密度というパラメータを設定する場合であって、第２達成手段によりゲーム課題を達成した場合は、上記指定したノンプレイヤキャラクタとの親密度は高めることができる。

更に他の構成例として、モード切替手段は、第１モードの状態をゲームの状態の基準とし、プレイヤまたはプレイヤキャラクタが対価を払うことを条件として、第１モードを第２モードへと切り替えるようにしてもよい。

更に他の構成例として、モード切替手段は、プレイヤまたはプレイヤキャラクタが対価を払うことで有効となった権利が存続していることを条件として、第１モードを第２モードへと切り替えるようにしてもよい。

本実施形態によれば、プレイヤがゲーム課題を達成しようとする際の利便性を高めることができる。

本実施形態の一例である情報処理システムの全体像を示す模式図スマートデバイス１０２の構成の一例を示すブロック図サーバ１０１の構成の一例を示すブロック図本実施形態のゲームの画面例本実施形態のゲームの画面例本実施形態のゲームの画面例サーバ１０１のメモリ１２３に格納されるプログラムおよびデータの一例セーブデータ２１５の構成の一例発生中課題データ２２４の構成の一例自動代行結果データ２２５のデータ構成の一例スマートデバイス１０２のメモリ１１３に格納されるプログラムおよびデータの一例本実施形態にかかるゲーム処理の詳細を示すフローチャート起動時処理の詳細を示すフローチャート自動代行処理の詳細を示すフローチャートレポート表示処理の詳細を示すフローチャート

以下、本発明の一実施形態について説明する。図１は、本実施形態に係る情報処理システムの全体像を示す模式図である。本実施形態の情報処理システム１００は、サーバ１０１と、複数の端末１０２とを含んでいる。本実施形態では、端末１０２の一例として、スマートデバイスを想定する。本実施形態では、スマートデバイス１０２の一例としては、スマートフォンやタブレット機等の携帯型の情報処理端末を想定するが、据え置き型のスマートデバイスの場合でも本実施形態の処理は適用できる。サーバ１０１と、スマートデバイス１０２とは、インターネット１０３を介して通信可能に構成されている。

本実施形態では、このような構成で、情報処理が実行されるが、以下では、当該情報処理の一例として、ゲーム処理を例として説明する。具体的には、スマートデバイス上にゲームプログラムがインストールされ、サーバ１０１と適宜通信を行いながら実行されるゲーム処理である。なお、本実施形態にかかるゲーム処理では、プレイヤのプレイ状況を示すデータ自体はサーバ１０１に保存される形態を採っている。このプレイ状況を示すデータは、例えばそのプレイヤが操作するプレイヤキャラクタの情報や、後述するゲーム課題の進行状況や、所持アイテム等を示すデータであり、一例として、後述するプレイヤデータ２１３である。例えば、ゲーム開始時に、サーバ１０１へのログイン処理が行われ、プレイヤのプレイ状況を示すデータがサーバ１０１からスマートデバイス１０２上に取得され、これを用いてゲーム処理が実行される。

［サーバのハードウェア構成］
次に、上記サーバ１０１のハードウェア構成について説明する。図３は、サーバ１０１の機能ブロック図である。サーバ１０１は、プロセッサ１２１と、メモリ１２３と、通信部１２４とを少なくとも備えている。プロセッサ１２１は、サーバ１０１を制御するための各種プログラムを実行する。メモリ１２３には、プロセッサ１２１によって実行される各種プログラムおよび利用される各種データが格納される。通信部１２４は、有線、または無線通信によってネットワークと接続し、上記スマートデバイス１０２または他のサーバ（図示せず）との間で所定のデータを送受信する。

［スマートデバイスのハードウェア構成］
次に、上記システムにおける各ハードウェアの構成について説明する。図２は、スマートデバイス１０２の機能ブロック図である。図２において、スマートデバイス１０２は、プロセッサ１１１と、メモリ１１３と、通信部１１４と、操作部１１５と、表示部１１６とを備えている。プロセッサ１１１は、後述する情報処理を実行したり、スマートデバイス１０２の全体的な動作を制御したりするためのシステムプログラム（図示せず）を実行することで、スマートデバイス１０２の動作を制御する。なお、プロセッサ１１１は、単一のプロセッサを搭載してもよいし、複数のプロセッサを搭載するようにしてもよい。メモリ１１３は、プロセッサ１１１によって実行される各種プログラムおよび当該プログラムで利用される各種データが格納される。メモリ１１３は、例えば、フラッシュＥＥＰＲＯＭやハードディスク装置である。通信部１１４は、有線、または無線通信によってネットワークと接続し、上記サーバ１０１との間で所定のデータを送受信する。操作部１１５は、例えば、ユーザからの操作を受け付けるための入力装置である。表示部１１６は、典型的には液晶表示装置である。なお、本実施形態に係る処理では、操作部１１５及び表示部１１６として、液晶画面と一体化したタッチパネルを想定する。他の実施形態では、操作部１１５として、タッチパネル以外の所定のポインティングデバイスを用いてもよい。

［本実施形態のゲーム処理の概要］
次に、本実施形態で実行される情報処理の概要について説明する。本実施形態では、情報処理の一例としてゲーム処理を例に説明する。特に、本実施形態は、ゲーム内で提示されるゲーム課題を受注して、このゲーム課題を達成し、所定の報酬を獲得する処理に関するものである。

まず、本実施形態で想定するゲームは、様々な仮想キャラクタが生活している仮想ゲーム世界内で、プレイヤキャラクタとして仮想的に生活するゲームである。例えば、様々な素材アイテムを集めて自分の家を建てたり、庭を整備したりできる。そして、本ゲームでは、所定の上記仮想キャラクタ（以下、ＮＰＣ（ノンプレイヤキャラクタ）と呼ぶ）と会話することで、当該ＮＰＣからゲーム課題が提示される。このゲーム課題を達成することで、所定の報酬を獲得することが可能である。また、本ゲームでは、各ＮＰＣについてプレイヤキャラクタとの親密度を示すパラメータ（以下、単に親密度と呼ぶ）が設定されており、このようなゲーム課題を達成することで、ゲーム課題を提示したＮＰＣとの親密度を高めることも可能となっている。なお、親密度を高めることで、特別なアイテム等をＮＰＣからもらうことも可能となっている。

上記ゲーム課題は、いわゆるクエストや依頼、ミッション等と呼ばれるものである。本例では、当該ゲーム課題として、ＮＰＣが所定のアイテムを要求するというゲーム課題を想定する。例えば、プレイヤが、プレイヤキャラクタを所定のＮＰＣに話しかけさせると、当該ＮＰＣから、ゲーム課題として、所定のアイテムを持ってきて欲しい旨が示される。プレイヤはこのゲーム課題を引き受けるか否かを選択できる（以下では、ゲーム課題の引き受けのことを「受注」と呼ぶ）。ゲーム課題を受注した場合、その後、プレイヤはプレイヤキャラクタを操作して仮想ゲーム世界において当該要求されたアイテムを入手し、ＮＰＣに渡すことができる。これにより、ゲーム課題が達成され、達成報酬を獲得することができる。換言すれば、プレイヤキャラクタが所有する所定のアイテムを消費することが達成条件として設定されているようなゲーム課題を例として説明する。なお、本例では、ゲーム課題はＮＰＣ毎に違う内容が設定されている。

より具体的な例を示すと、本ゲームでは、動物を擬人化した上記仮想キャラクタがＮＰＣとして複数設定されている。プレイヤキャラクタ（これは人間のキャラクタである）が所定のＮＰＣに話しかけると、例えば、「りんごを１個、ももを３個持ってきて欲しい」という「おねがい」メッセージが表示される。これが、当該ＮＰＣに関連付けられているゲーム課題の提示となる。すなわち、ゲーム課題の達成のために必要なアイテム（以下、その必要数も含める概念で、要求アイテムと呼ぶ）が提示されることになる。この際、プレイヤにこのゲーム課題を受注するか否かを問い合わせる選択肢が表示される。プレイヤがこのゲーム課題を受注することを選択する操作を行うことで、当該ゲーム課題を受注した状態となる。この後、プレイヤはプレイヤキャラクタを操作して、りんごやももが入手可能なゲーム内の所定の場所（一例として、果物がなっている木のある森）に移動する。そこで、りんごやももを入手するための操作（例えば、木を揺する操作）を行うことで、りんごやももを所定数入手することができる。換言すれば、プレイヤキャラクタの所持アイテムが増加することになる。その後、当該ＮＰＣのいる場所に移動し、当該ＮＰＣに話しかけることで、上記要求アイテムをＮＰＣに渡すことができる。すなわち、プレイヤキャラクタが所有しているアイテムから、りんごが１個、ももが３個が消費されることになる。これにより、ゲーム課題が達成され、達成報酬として、所定のゲーム内アイテムがプレイヤ（あるいはプレイヤキャラクタ）に付与される。また、当該ＮＰＣに関する親密度も増加する。

なお、ゲーム課題を受注する時点で既に上記要求アイテムをプレイヤキャラクタが所有している場合は、ゲーム課題の受注と同時にゲーム課題が達成され得る。

ここで、本ゲームにおける上記ゲーム課題の発生タイミングに関して補足説明する。本ゲームでは、上記ＮＰＣ毎にそれぞれゲーム課題が設定されており、各ＮＰＣから受注可能となっている。これらＮＰＣは、予め定められているタイミングでゲーム世界内の所定の場所に出現し、その後、所定のタイミングでいなくなる。そのため、この所定のタイミングは、受注可能なゲーム課題が更新されるタイミング（以下、課題更新タイミングと呼ぶ）でもある。具体的な例で説明すると、ゲーム課題を提示するＮＰＣが出現するゲーム内の場所として、予め５カ所の場所が定義されているとする。そして、３時間毎に、出現するＮＰＣが入れ替わるものとする。例えば、ＮＰＣ出現場所として、「場所Ａ」～「場所Ｅ」の５つの場所が定義されているとする。また、ゲーム課題を提示可能なＮＰＣとして、「ＮＰＣ－Ａ」～「ＮＰＣ－Ｊ」の１０体のＮＰＣが用意されているとする（これら具体的な数値は、あくまで一例である）。そして、例えば３：００に場所ＡにＮＰＣ－Ａが出現すると、当該ＮＰＣ－Ａから「ゲーム課題Ａ」が受注可能な状態となる。その後、６：００になれば、場所ＡからはＮＰＣ－Ａはいなくなり、ＮＰＣ－Ｆが出現する。このＮＰＣ－Ｆからは、「ゲーム課題Ｆ」が受注可能となっている。つまり、６：００のタイミングで、場所Ａで受注可能なゲーム課題が「ゲーム課題Ａ」から「ゲーム課題Ｆ」に更新されることになる。

なお、受注はしたが、達成する前に課題更新タイミングが到来したゲーム課題について、本例では、後述する自動代行が行われていなければ、達成できなかったものとして扱うものとする。

なお、本例では、説明をわかりやすくするため、１人のＮＰＣにつき、１つのゲーム課題が設定されているものとする。但し、他の実施形態では１人のＮＰＣから複数のゲーム課題が受注可能なようにしてもよい。例えば、ＮＰＣ－Ａについて、「ゲーム課題Ａ１」「ゲーム課題Ａ２」「ゲーム課題Ａ３」の３つを設定してもよい。この場合、「ゲーム課題Ａ１」が達成されることで「ゲーム課題Ａ２」が受注可能とすればよい。同様に、「ゲーム課題Ａ２」が達成されることで、「ゲーム課題Ａ３」が受注可能とすればよい。

上記から、本ゲームでは、３時間毎に５つのゲーム課題（５人のＮＰＣ）が入れ替わることになり、プレイヤは、最大で５つまでゲーム課題が受注可能である（なお、掛け持ちも可能である）。また、１日に８回のゲーム課題の更新が行われるため、プレイヤは、１日で最大４０のゲーム課題を受注可能となっている。

上記のように、本ゲームでは、ゲーム課題を達成するためには、基本的には次のような流れでのゲームの操作が必要となる。
（１）ＮＰＣからゲーム課題を受注するための操作（以下、受注操作と呼ぶ）→（２）要求アイテムを集めるための各種の操作→（３）要求アイテムをＮＰＣに渡すための操作（以下、要求アイテム譲渡操作と呼ぶ）

１つのゲーム課題を達成するためには、上記のような一連の操作が必要となる（これは、ある種のルーチンワーク的な性質を有するともいえる）。ここで、上記のように３時間毎に更新されるゲーム課題の全て達成しようとすると、プレイヤの操作の労力もある程度要求され得る可能性がある。また、全てとはいわずとも、ある程度のゲーム課題は達成しておきたいと考える場合でも、プレイヤの時間の都合等で、十分にプレイ時間が確保できず、思うようにゲーム課題が達成できない場合もあり得る。そこで、本実施形態では、上記のようなゲーム課題を自動で達成する機能を提供する。具体的には、本ゲームでは、「パートナーキャラ」というものを利用してこの機能を実現している。

より具体的に説明すると、プレイヤは、上記仮想キャラクタのうちのいずれか一体を「パートナーキャラクタ（以下、単にパートナーと呼ぶ）」として設定（指定）することができる。なお、設定されたパートナーは、パートナー設定されている間は、ゲーム内において、プレイヤキャラクタの後ろをついてくるように制御される。そして、パートナーが設定されると、当該パートナーが、プレイヤの代わりにゲーム課題を自動で代行する（ゲーム内では、パートナーがプレイヤを「お手伝い」する、という扱いになる）。これにより、上述のような一連の操作をプレイヤが行わずとも、パートナーが代わりにゲーム課題を達成してくれることになる。なお、パートナーが設定されている間は、プレイヤがゲームをプレイしていない時（ログインしていない時等）であっても、当該パートナーがゲーム課題を自動代行するような処理が行われる。そのため、パートナーを設定しておけば、プレイヤがゲームにログインしていない時間帯に発生し得るゲーム課題についてもパートナーが達成し、その達成報酬を獲得することも可能である。

また、本実施形態では、パートナーとして設定されている仮想キャラクタは、その設定中はゲーム課題を提示しないものとする。そのため、パートナー設定中は、パートナー以外の仮想キャラクタがゲーム課題を提示することになる。

また、パートナーによる自動代行の対象となるゲーム課題は、上記課題更新タイミングにおいて、そのときに発生しているゲーム課題のうち、未達成のもの全てが対象となる。例えば、６：００の課題更新タイミングで合計５つのゲーム課題が受注可能になった後、次の課題更新タイミングである９：００までに２つしかゲーム課題を達成していなかった場合を想定する。この場合は、９：００のタイミングで、残っている３つのゲーム課題がパートナーによって自動代行されて、ゲーム課題が更新されるような処理が行われる。換言すれば、プレイヤが自分で達成したゲーム課題については、自動代行の対象にはならない。なお、受注はしたが課題更新タイミングにおいて達成されていないゲーム課題についても、本例では自動代行の対象とする。他の実施形態では、受注したが達成しないままゲーム課題更新タイミングが到来したゲーム課題については、自動代行対象とはせずに未達成として扱うようにしてもよい。また、更に他の実施形態では、達成されていないゲーム課題の全てを自動代行の対象とはせず、このうちの一部だけを自動代行の対象としてもよい。

ここで、本実施形態では、上記パートナーによるゲーム課題達成の場合、上述したような要求アイテムの消費は行われない。例えば、ゲーム課題Ａの要求アイテムが「りんごが１個、ももが３個」である場合、パートナーの自動代行によらずにプレイヤ自身が上記のような一連の操作でこのゲーム課題Ａを達成する場合は、所持アイテムから「りんごが１個、ももが３個」消費されることになる。しかし、当該ゲーム課題Ａがパートナーによる自動代行で達成された場合は、このような所持アイテムからの消費は行われない。これは、自動代行であればプレイヤの操作無しでゲーム課題が達成され得るところ、プレイヤの知らないところで勝手に要求アイテムがＮＰＣに渡されてしまうことを防ぐためである。すなわち、プレイヤが意図していないアイテム消費や所持数の減少が発生してしまうことを防ぐためである。

次に、パートナーによる自動代行が行われるタイミングおよび達成報酬付与に関して説明する。ここでは、ゲームが起動されている場合と、ゲームが起動されていない場合（プレイヤがゲームをプレイしていない場合）とに分けて説明する。まず、ゲームが起動されている場合（プレイヤがゲームをプレイ中の場合）は、上記課題更新タイミングで、そのときに未達成のゲーム課題について、自動代行を行い、達成したものとする処理が行われる。但し、達成報酬の実際の付与については、課題更新タイミングと同時ではなく、後述するレポート画面がプレイヤに確認されたタイミングで、達成報酬が付与される。

一方、ゲームが起動されていない場合の自動代行に関して、ゲーム上の表現としては、ゲームを起動していない間もパートナーがゲーム課題を達成していたというものとなるが、これは、次のような処理で実現される。本例では、ゲームが再開されたタイミングで、セーブデータを前回セーブした時刻以降に経過した時間分の課題更新タイミングの回数だけ、自動代行を行ったものとして扱う。具体的には、ゲームが再開されたタイミングで、ゲームが起動されていない間に自動代行が行われた回数だけを算出し、記憶しておく。その後、後述するレポート画面をプレイヤに提示する処理において、この回数分のゲーム課題を生成し、パートナーによる自動代行を行う。そして、自動代行分の達成報酬の抽選も行い、プレイヤに付与する。

上記のように、プレイヤがゲームを起動していない間も、自動代行が行われたものとする処理が行われるが、報酬受け取りは、レポート画面が確認されたタイミングとなる。そのため、レポート画面の確認操作が行われない限り、達成報酬はプレイヤに付与されず、溜め込むような状態となる。本例では、記憶容量削減等の観点から、溜め込んでおける報酬の数（換言すれば、自動代行できる回数）に上限を設けている。そして、付与されていない達成報酬がこの上限値に達した場合は、レポート画面の確認による報酬受け取りが行われるまでは、新たな自動代行は行われないような制御が行われる。なお、本例では、この上限値を１日分とする。これにより、達成報酬の受け取りを少なくとも１日に一度は行わないと、それ以上の自動代行が行われないため、プレイヤが毎日ゲームを起動することへの動機付けも提供できる。

次に、上述のレポート画面に関して説明する。まず、パートナーが自動代行でゲーム課題を達成すると、自動代行による報酬が受け取り可能であることを示す通知等が提示される。そして、プレイヤがこの通知の内容を確認するための操作を行うと、「レポート画面」という形で、自動代行の結果と獲得した報酬が表示され、このタイミングで達成報酬がプレイヤに付与される。

以下、画面例を用いて、当該レポート画面に係るゲームの流れと画面遷移の例を説明する。図４～図６は、当該レポート画面に関するゲーム画面の一例である。まず図４は、マップ画面を示している。この画面では、仮想ゲーム世界を俯瞰した地図が表示されており、プレイヤキャラクタが移動できる場所が複数示されている。プレイヤは、所定の場所を指定することで（例えばタップ操作）、プレイヤキャラクタをその場所に移動させることが可能である。また、この画面において、画面の右下に、パートナー画像２０１が表示されている。更に、自動代行による達成報酬が受け取り可能である旨のメッセージも、当該パートナーが話している体裁で表示されている。プレイヤは、当該パートナー画像２０１をタップ操作することで、自動代行の結果を確認することができる。なお、受け取れる報酬がないときに当該パートナー画像２０１をタップした場合は、「パートナーの管理メニュー」（図示は省略）が表示される。プレイヤは、この管理メニューから、例えばパートナーの解任や変更を行うことができる。

上記パートナー画像２０１をプレイヤがタップ操作すると、図５に示すようなレポート画面（ＮＰＣ一覧）が表示される。この画面では、前回に結果を確認したときから現在までの間にパートナーが自動代行（図５では「お手伝い」として扱われている）したゲーム課題の依頼主となるＮＰＣの画像２０２（例えば顔画像）が一覧表示される。つまり、どのＮＰＣのゲーム課題を自動代行してきたのかが示される。

図５の画面で更にプレイヤが画面（どの位置でもよい）をタップ操作すると、上記ＮＰＣの画像２０２が裏返るような演出が行われ、図６のようなレポート画面（報酬一覧）が表示される。図６では、各ゲーム課題の達成報酬を示す画像２０３が一覧表示されている。これにより、プレイヤは達成報酬としてどのようなアイテムを獲得したのかを確認できる。また、このようなレポート画面を確認したタイミングで、当該達成報酬の抽選処理が行われ、抽選された達成報酬をプレイヤに付与する処理も実行される。

［本実施形態のゲーム処理の詳細］
次に、図７～図１７を参照して本実施形態のゲーム処理をより詳細に説明する。

［使用データについて］
まず、本ゲーム処理にて用いられる各種データに関して説明する。図７は、サーバ１０１のメモリ１２３に格納されるプログラムおよびデータの一例を示している。メモリ１２３には、サーバ側プログラム２１１、プレイヤデータベース２１２、ゲーム課題マスタデータ２１６等が格納される。

サーバ側プログラム２１１は、本実施形態に係るゲーム処理においてサーバ側が担当する各種機能をサーバ１０１に実行させるためのプログラムである。

プレイヤデータベース２１２は、本実施形態にかかるゲームの各プレイヤについての情報を記憶したデータベースであり、複数のプレイヤデータ２１３で構成されている。各プレイヤデータ２１３には、アカウントデータ２１４、セーブデータ２１５等が含まれている。

アカウントデータ２１４は、各プレイヤのアカウントに関する情報であり、各プレイヤを識別するための情報でもある。サーバ１０１へのログイン処理等にも用いられる。

セーブデータ２１５は、各プレイヤのゲームのプレイ状況、進行状況等をセーブした情報である。図８に、セーブデータ２１５の構成の一例を示す。セーブデータ２１５には、所持アイテムデータ２２１、パートナーモード情報２２２、現在のパートナー情報２２３、発生中課題データ２２４、自動代行結果データ２２５、最終更新日時２２６等が含まれている。

所持アイテムデータ２２１は、そのプレイヤが所有しているゲーム内アイテムを示す情報である。上記要求アイテムなどをゲーム内で入手した場合は、一旦当該所持アイテムデータ２２１に記憶される。また、ゲーム課題の依頼主に要求アイテムを渡す場合は、当該所持アイテムデータ２２１から要求アイテムが消費あるいはその所持数が減算されることになる。

パートナーモード情報２２２は、上述したパートナーが設定されている状態か設定されていない状態かを示すための情報である。以下の説明では、パートナーが設定されている状態のことを「パートナーモード」、設定されていない状態のことを「ノンパートナーモード」と呼ぶ。

現在のパートナー情報２２３は、パートナーモードである場合に、現在設定されているパートナーを特定するための情報である。つまり、その仮想キャラクタがパートナーとして現在設定されているかを示す情報である。

発生中課題データ２２４は、プレイヤがゲームをプレイ中において、現在発生しているゲーム課題の内容を示す情報である。換言すれば、発生中のゲーム課題を管理するために用いられる情報である。上記のように、課題更新タイミングを経ることで定期的に（本例では３時間毎）ゲーム課題の内容は入れ替わる。この課題更新のタイミングで、更新されたゲーム課題の内容を示す情報として発生中課題データ２２４が更新されることになる。なお、本例では、当該データの更新が行われるのは、プレイヤがゲーム起動中（ゲームにログイン中）の間であり、プレイヤがゲームを起動していない間（ログアウトしている間）は更新されないものとする。後述する処理の関係で、ゲーム再開時に、前回ゲームからログアウトしたときに発生していたゲーム課題を把握する必要があるためである。

図９に、当該発生中課題データ２２４のデータ構成の一例を示す。発生中課題データ２２４は、作成日時２５１、ＮＰＣ情報２５２、進行状況２５３、達成報酬情報２５４、および、課題内容情報２５５を少なくとも含む、テーブル形式のデータである。図９では、発生中課題データ２２４における１レコード（横１行分のデータ）が１つ分のゲーム課題に対応する。本例では、１回分の上記課題更新タイミングで、５つのゲーム課題が発生する例で説明しているため、当該発生中課題データ２２４の件数も５件となっている。作成日時２５１は、そのゲーム課題が生成された（発生した）日時を示す情報である。ＮＰＣ情報２５２は、そのレコードに係るゲーム課題の依頼主となるＮＰＣを特定するための情報である。進行状況２５３は、そのゲーム課題の進行状況を示す情報である。当該情報には、受注していない状態を示す「未受注」か、受注したがまだ達成していない状態の「進行中」か、既に達成した状態の「達成済み」かを示す情報が適宜設定される。達成報酬情報２５４は、そのゲーム課題の達成報酬を示すための情報である。ここで、本実施形態では、達成報酬は抽選によって選ばれるものとする。そのため、当該達成報酬情報２５４には、当該抽選に用いる抽選テーブルを示す情報が定義されている。なお、本例では、達成報酬の受け取り操作が行われたタイミングで、当該抽選テーブルを用いた抽選処理が行われ、報酬内容が決定される。課題内容情報２５５は、そのゲーム課題の内容を示す情報である。例えば、上記要求アイテムの内容を定義する情報等が含まれる。

図８に戻り、次に、自動代行結果データ２２５は、ゲーム起動中において実行された上記自動代行の結果を示すためのデータである。より正確には、自動代行によってゲーム課題自体は達成済みの扱いであるが、まだ達成報酬がプレイヤに受け取られていないゲーム課題を示す情報である。換言すれば、未受け取り状態の達成報酬とそのゲーム課題を示す情報である。また、本実施形態では、当該自動代行結果データ２２５の件数には上限が設けられている。本例では、上記のように、１日分、すなわち、４０件である場合を例に説明する（３時間毎の課題更新が８回分）。すなわち、達成報酬の受け取りが行われない限りは、自動代行に係る処理は４０回が上限回数となり、当該自動代行による達成報酬は最大で１日分しか溜め込むことができないことになる。このように上限を設けることで、過去にどのようなＮＰＣと出会って、どのようなゲーム課題を受注したのかという情報を記憶するための記憶容量を削減することが可能となる。

図１０に、当該自動代行結果データ２２５のデータ構成の一例を示す。自動代行結果データ２２５は、ＮＰＣ情報２６１、使用報酬テーブル情報２６２、自動代行日時２６３を少なくとも含む、テーブル形式のデータである。また、自動代行結果データ２２５における１レコードが１つ分のゲーム課題に対応する。上記のように、本例では１日分を上限とするため、４０件分のレコードが自動代行結果データ２２５に含まれることになる。ＮＰＣ情報２６１は、そのレコードに係るゲーム課題の依頼主であるＮＰＣを特定するための情報である。使用報酬テーブル情報２６２は、そのゲーム課題の達成報酬を抽選する際に用いる上記抽選テーブルを示す情報である。自動代行日時２６３は、自動代行が行われた日時を示す情報である。本例の場合、基本的には、ゲーム再開時、あるいは、ゲーム課題更新タイミングとなる。

図８に戻り、次に、未起動時の自動代行回数データ２２６は、上記のようにゲーム未起動時において実行され得たであろう自動代行の回数を示すデータである。当該データは、ゲームの再開時に算出されて記憶される。その後、上述したレポート画面が確認されたタイミングで、当該回数分のゲーム課題の生成処理と報酬抽選処理が行われ、報酬の付与が行われる。なお、上記のように上限値が設定されている関係上、実際に処理されるゲーム未起動時における自動代行の回数は、ゲームの再開時に算出された自動代行回数よりも少なくなることもあり得る。

次に、最終更新日時２２７は、当該セーブデータ２１５が最後に更新された日時を示す情報である。なお、本例では、当該セーブデータ２１５は、ゲームが起動された後は、所定のタイミングで自動的に更新されるものとする。具体的には、後述するゲーム起動時処理（ステップＳ１）が行われた後は、ゲームプレイが終了するまで（プレイヤがログアウトするまで）の間、例えばゲーム内のシーン遷移が発生したタイミングや、アイテムの増減が発生したタイミング等で、上述した所持アイテムデータ２２１等の各データを含む、そのときのゲーム状態を示す情報がスマートデバイス１０２からサーバに送信され、その内容でセーブデータ２１５が更新されるものとする。

その他、図示は省略するが、セーブデータ２１５には、プレイヤキャラクタの外観を示す画像データや名前、ゲーム世界内でのプレイヤキャラクタの現在位置、フレンド情報等の各種データも格納されている。

図７に戻り、次に、ゲーム課題マスタデータ２１６は、上記のゲーム課題を生成する際の元になるデータである。本例では、各ＮＰＣに複数のゲーム課題が定義されているものとする。そして、課題更新タイミングの際に、どのＮＰＣを出現させるかを例えばランダムに決定して、更に、各ＮＰＣに設定されている複数のゲーム課題からどのゲーム課題を用いるのかを決定する処理が、当該ゲーム課題マスタデータ２１６に基づいて行われる。

次に、スマートデバイス側のデータに関して説明する。図１１は、スマートデバイス１０２のメモリ１１３に格納されるプログラムおよびデータの一例を示している。メモリ１１３には、クライアント側プログラム２８１、操作データ２８２、オブジェクトデータ２８３等が格納される。

クライアント側プログラム２８１は、本実施形態に係るゲーム処理においてスマートデバイス側が担当する各種機能をスマートデバイス１０２に実行させるためのプログラムである。

操作データ２８２は、操作部１１５に対して行われた各種操作内容を示すデータである。本実施形態では、操作部１１５としてのタッチパネルへの入力の有無、タッチ座標等を示すデータや、図示しない各種ボタンの押下状態等を示すデータが含まれている。当該操作データ２８２の内容は、操作部１１５からの信号に基づき、所定の周期で更新されるものとする。

オブジェクトデータ２８３は、ゲーム世界を構成する各種オブジェクトやステージの画像や形状等を定義したデータである。上記仮想キャラクタの外観を示す画像データ等も当該データに含まれる。

その他、メモリ１２３には、ゲーム処理に必要な各種データも適宜格納される。

［ゲーム処理例の詳細］
次に、図１２のフローチャートを参照して、本実施形態にかかるゲーム処理の詳細を説明する。なお、ここでは、主に上記ボーナスステージに関する処理について説明し、その他のゲーム処理の説明については割愛する。また、以下の処理は、基本的には、スマートデバイス１０２のプロセッサ１１１が主体である場合を例に説明する。他の実施形態では、以下の処理の一部をサーバ１０１において実行し、その結果をスマートデバイス１０２における処理に反映するようにしてもよい。例えば、スマートデバイス１０２では、操作データの取得とサーバへの送信、各種画像音声処理を中心に行えばよい。そして、サーバ１０１では、当該操作データに基づいたゲーム処理、例えば仮想ゲーム空間内でのプレイヤオブジェクトの移動または各種の判定処理等を行い、その実行結果をスマートデバイス１０２に送るようにしてもよい。

なお、サーバ１０１における処理については、図示は省略するが、プレイヤの操作（スマートデバイス１０２からの要求）に応じて、ログイン処理や、必要なデータの送受信処理等が適宜行われている。

スマートデバイス１０２において、プレイヤによってゲーム起動操作、例えば、メニュー画面から当該ゲームのアイコンをタップする操作等、が行われることで、本実施形態に係るゲーム処理が開始され得る。ゲーム処理が開始されると、まず、ステップＳ１で、ゲーム起動時処理が実行される。この処理では、主に、ログイン処理と、ゲーム未起動時（ログアウト中）において実行され得た自動代行回数（の最大値）を算出する処理が実行される。図１３は、当該ゲーム起動時処理の詳細を示すフローチャートである。図１３において、まず、ステップＳ２１で、プロセッサ１１１は、サーバ１０１と通信を行い、所定のログイン処理を行う。ログイン処理が成功すれば、プロセッサ１１１は、セーブデータ２１５を含む、ゲーム処理に必要となる各種のデータをサーバ１０１から取得する。

次に、ステップＳ２２で、プロセッサ１１１は、取得したセーブデータ２１５を参照して、現在のゲーム状態がパートナーモードであるか否かを判定する。当該判定の結果、パートナーモードではない場合（ノンパートナーモードである場合）は（ステップＳ２２でＮＯ）、後述するステップＳ２５に処理が進められる。

一方、パートナーモードである場合は（ステップＳ２２でＹＥＳ）、次に、ステップＳ２３で、プロセッサ１１１は、ゲームが起動されていない間（ログアウト期間中）に行われ得た自動代行の回数を算出する。具体的には、最終更新日時２２７（この時点では、前回ログアウトの日時を示すものとなっている）から現在時刻までの間に、課題更新タイミングが何回あったかを算出する。すなわち、ログアウト期間中における自動代行回数を算出する。本例では、３時間毎の課題更新タイミングで５つのゲーム課題が発生する例であるため、例えばログアウトしていた期間が６時間である場合は、１０回の自動代行が行われ得る（１０のゲーム課題を自動代行され得る）と算出されることになる。

次に、ステップＳ２４で、プロセッサ１１１は、上記算出した自動代行回数に基づき、未起動時の自動代行回数データ２２６を更新する。具体的は、未起動時の自動代行回数データ２２６で示される値に上記算出した回数を加算する処理が実行される。報酬を受け取らないままで、ログイン～ログアウト（つまり、ゲームの再開）が複数回行われた場合、ゲーム未起動時における自動代行回数も蓄積されていくことになる。なお、ここでは、未起動時の自動代行回数データ２２６自体には特に上限はなく、単純に自動代行が行われ得た回数としてカウントされていく。実際に自動代行として扱われる回数は、後述のレポート表示処理において、上記のような上限との関係で決定されることになる。例えば、未起動時の自動代行回数として５０回と算出されたとしても、実際に自動代行したものとして扱われる回数は、本例の場合は最大でも４０件分までとなる。

次に、ステップＳ２５で、プロセッサ１１１は、発生中課題データ２２４を設定する処理を行う。具体的には、次のような処理が行われる。まず、プロセッサ１１１は、前回ログアウトした後、課題更新タイミングが到来していたか否かを判定する。到来していなければ、プロセッサ１１１は、発生中課題データ２２４の更新は行わない。つまり、前回ログアウト時に記録されている発生中課題データ２２４をそのまま用いることになる。一方、課題更新タイミングが到来していれば、プロセッサ１１１は、サーバ１０１から取得したゲーム課題マスタデータ２１６に基づいて、出現するＮＰＣとこれに関連付けられるゲーム課題とを決定する。そして、決定した結果で発生中課題データ２２４を更新する。これにより、今回のプレイ中にプレイヤが認識可能なゲーム課題（現在発生中のゲーム課題）が設定されることになる。

次に、ステップＳ２６で、プロセッサ１１１は、上記の処理を反映したゲーム画面を生成して表示する。その後、プレイヤからの操作の受付を開始する。以上で、ゲーム起動時処理は終了する。

図１２に戻り、次に、ステップＳ２で、プロセッサ１１１は、上記課題更新タイミングが到来したか否かを判定する。その結果、到来していなければ（ステップＳ２でＮＯ）、後述のステップＳ５に処理が進められる。到来している場合は（ステップＳ２でＹＥＳ）、ステップＳ３で、プロセッサ１１１は、自動代行処理を実行する。この処理は、ゲームプレイ中におけるパートナーの自動代行を実行するための処理である。

図１４は、上記自動代行処理の詳細を示すフローチャートである。まず、ステップＳ３１で、プロセッサ１１１は、パートナーモード情報２２２を参照して、現在のゲーム状態がパートナーモードであるか否かを判定する。パートナーモードではない場合は（ステップＳ３１でＮＯ）、当該自動代行処理は終了する。一方、パートナーモードである場合は（ステップＳ３１でＹＥＳ）、ステップＳ３２で、プロセッサ１１１は、自動代行結果データ２２５の件数が上限に達しているか否かを判定する。達している場合は（ステップＳ３２でＹＥＳ）、これ以上の自動代行を行わないようにするため、自動代行処理は終了する。まだ達していない場合は（ステップＳ３２でＮＯ）、ステップＳ３３で、発生中課題データ２２４を参照して、進行状況が「達成済み」となっていない（すなわち、未達成の）ゲーム課題を抽出する。

次に、ステップＳ３４で、プロセッサ１１１は、抽出したゲーム課題に係るＮＰＣ情報２５２および達成報酬情報２５４に基づいて、自動代行結果データ２２５を更新する処理を実行する。具体的には、プロセッサ１１１は、抽出したゲーム課題に対応するＮＰＣ情報２６１、使用報酬テーブル情報２６２を設定し、現在の日時を自動代行日時２６３に設定する。これにより、課題更新タイミングの時点で未達成のゲーム課題を達成扱いとし、その達成報酬は未受け取りである、という状態とすることができる。以上で、自動代行処理は終了する。

図１２に戻り、次に、ステップＳ４で、プロセッサ１１１は、ゲーム課題更新処理を実行する。すなわち、プロセッサ１１１は、サーバ１０１から取得したゲーム課題マスタデータ２１６に基づいて、出現するＮＰＣとこれに関連付けられるゲーム課題とを決定し、決定した内容で発生中課題データ２２４を更新する。これにより、プレイヤが受注可能なゲーム課題が入れ替わることになる。

次に、ステップＳ５で、プロセッサ１１１は、操作データ２８２を取得する。次に、ステップＳ６で、操作データ２８２で示される操作内容が、未受注のゲーム課題を受注する操作（以下、課題受注操作）であるか否かを判定する。その結果、課題受注操作である場合は（ステップＳ６でＹＥＳ）、ステップＳ７で、課題受注処理を実行する。具体的には、プロセッサ１１１は、発生中課題データ２２４を参照し、受注した課題に対応する進行状況２５３を「進行中」に設定する。更に、プロセッサ１１１は、ゲーム課題を受注する演出等を表示する処理も実行する。その他、ゲーム課題の受注に伴う各種の処理も適宜実行される。その後、ステップＳ２に戻り、処理が繰り返される。

一方、ステップＳ６の判定の結果、操作内容が課題受注操作ではない場合は（ステップＳ６でＮＯ）、ステップＳ８で、プロセッサ１１１は、上記要求アイテム譲渡操作が行われたか否かを判定する。この操作は、例えば、進行中のゲーム課題であって、要求アイテムを全てその依頼主のＮＰＣに渡す操作である。要求アイテム譲渡操作が行われた場合は（ステップＳ８でＹＥＳ）、ステップＳ９で、プロセッサ１１１は、課題達成処理を実行する。具体的には、プロセッサは、以下のような処理を実行する。まず、プロセッサ１１１は、今回の報告に係るゲーム課題の要求アイテムを所持アイテムデータ２２１から消費あるいは減算する処理を行う。更に、プロセッサ１１１は、達成報酬情報２５４で示される報酬テーブルに基づいて、達成報酬を抽選する処理を実行する。そして、プロセッサ１１１は、抽選された達成報酬を所持アイテムデータ２２１に追加することで、達成報酬をプレイヤに付与する。更に、発生中課題データ２２４の該当するゲーム課題の進行状況２５３を「達成済み」に設定する。更に、プロセッサ１１１は、ゲーム課題を達成したことを示す所定の演出を表示する処理も行う。また、プロセッサ１１１は、今回達成したゲーム課題の依頼主であるＮＰＣの親密度を所定値だけ高める処理を行う。その後、上記ステップＳ２に戻り、処理が繰り返される。

一方、ステップＳ８の判定の結果、操作内容が要求アイテム譲渡操作ではない場合は（ステップＳ８でＮＯ）、ステップＳ１０で、プロセッサ１１１は、レポート確認操作が行われたか否かを判定する。この操作は、例えば、受け取り可能な達成報酬がある状態において、上記図４で示したマップ画面でプレイヤがパートナー画像２０１をタップする操作である。当該判定の結果、レポート確認操作が行われた場合は（ステップＳ１０でＹＥＳ）、ステップＳ１１で、プロセッサ１１１は、レポート表示処理を実行する。この処理では、主に、上述したレポート画面を用いて自動代行の結果を示し、また、達成報酬を抽選してプレイヤに付与する処理が行われる。

図１５は、当該レポート表示処理の詳細を示すフローチャートである。まず、ステップＳ４１で、プロセッサ１１１は、未起動時の自動代行回数データ２２６を参照して、その回数が１以上であるか否かを判定する。つまり、ログアウト期間中に自動代行が１回でも発生し得た状況であるか否かを判定する。当該判定の結果、１以上では無い（つまり、０回）場合は（ステップＳ４１でＮＯ）、後述のステップＳ４３に処理が進められる。

一方、未起動時の自動代行回数データ２２６が１以上の場合は（ステップＳ４１でＹＥＳ）、ステップＳ４２で、プロセッサ１１１は、ゲーム未起動時における自動代行に関する情報を自動代行結果データ２２５に追加する処理を実行する。具体的には、まず、プロセッサ１１１は、その時点での自動代行結果データ２２５の件数が上限に達しているか否かを判定する。達していれば、これ以上の自動代行はできない状態であるため、プロセッサ１１１は、自動代行結果データ２２５への情報の追加は行わずに、処理を次に進める。一方、まだ上限まで達していない場合は、プロセッサ１１１は、当該上限に達するまでの回数分、ゲーム課題を生成する処理を実行する。具体的には、プロセッサ１１１は、ゲーム課題マスタデータ２１６に基づいて、ランダムにゲーム課題を生成する。そして、当該生成したゲーム課題を示す情報を自動代行結果データ２２５に追加する。すなわち、当該生成したゲーム課題にかかるＮＰＣ情報２６１および使用報酬テーブル情報２６２を自動代行結果データ２２５に追加する。また、自動代行日時２６３には、現在の処理日時が設定される。これにより、ゲーム未起動時においてもパートナーによる自動代行が実行されたという結果にすることができる。

次に、ステップＳ４３で、プロセッサ１１１は、自動代行結果データ２２５を読み出す処理を実行する。上記のような処理の結果、自動代行結果データ２２５には、プレイヤがゲームプレイ中において行われた自動代行の結果と、ゲーム未起動時（ログアウト期間中）における自動代行の結果とが含まれ得るものとなっている。

次に、ステップＳ４４で、プロセッサ１１１は、自動代行分の達成報酬を抽選し、プレイヤに付与する処理を実行する。具体的には、プロセッサ１１１は、自動代行結果データ２２５の使用報酬テーブル情報２６２を用いて各ゲーム課題の達成報酬を抽選する。そして、プロセッサ１１１は、抽選された達成報酬を所持アイテムデータ２２１に追加する。

次に、ステップＳ４５で、プロセッサ１１１は、自動代行結果データ２２５に基づき、上記図５で示したようなレポート画面（ＮＰＣ一覧）を生成して表示する処理を実行する。具体的には、自動代行結果データ２２５のＮＰＣ情報２６１に基づいて、自動代行したＮＰＣを特定し、その顔画像等を含むレポート画面（ＮＰＣ一覧）を生成して表示する。また、この際に、プロセッサ１１１は、パートナーがゲーム課題を達成した様子を示すゲーム演出を表示するようにしてもよい。その後、プレイヤからの操作を待ち受ける。

次に、ステップＳ４６で、プロセッサ１１１は、操作データ２８２を取得し、続くステップＳ４７で、何らかの入力操作が行われたか、例えば、画面内の任意の位置がタップ操作されたか否かを判定する。当該判定の結果、まだ入力が行われていない場合は（ステップＳ４７でＮＯ）、上記ステップＳ４５に戻り、処理が繰り返される。何らかの入力が行われていた場合は（ステップＳ４７でＹＥＳ）、次に、ステップＳ４８で、プロセッサ１１１は、上記図６で示したようなレポート画面（報酬一覧）を生成して表示する処理を実行する。具体的には上記ステップＳ４４で抽選された達成報酬に対応する画像を生成し、更に、これを用いたレポート画面（報酬一覧）を生成して表示する。その後、プレイヤからの操作を待ち受ける。

次に、ステップＳ４９で、プロセッサ１１１は、操作データ２８２を取得し、続くステップＳ５０で、何らかの入力操作が行われたか、例えば、画面内の任意の位置がタップ操作されたか否かを判定する。当該判定の結果、まだ入力が行われていない場合は（ステップＳ５０でＮＯ）、上記ステップＳ４８に戻り、処理が繰り返される。何らかの入力が行われていた場合は（ステップＳ５０でＹＥＳ）、次に、ステップＳ５１で、プロセッサ１１１は、自動代行結果データ２２５をクリアする処理を実行する。つまり、達成報酬が受け取り済みの状態となる。その結果、自動代行結果データ２２５には、これ以降（今回のレポート確認操作が行われた以降）に達成されたゲーム課題に関する情報が改めて貯まっていくことになる。

次に、ステップＳ５２で、プロセッサ１１１は、レポート画面（報酬一覧）を消去して、レポート画面の提示を終了し、元の画面（例えばマップ画面）に遷移する処理を実行する。以上で、レポート表示処理は終了する。

図１２に戻り、次に、上記ステップＳ１０の判定の結果、レポート確認操作も行われていない場合は（ステップＳ１０でＮＯ）、ステップＳ１２で、その他のゲーム処理が実行される。ここでは、例えば、以下のような処理が実行される。まず、操作データ２８２で示される内容に基づいて、プレイヤキャラクタをゲーム内世界で移動させたり、所定のアクションを行わせたりする処理が実行される。このような処理の結果、上記要求アイテムを含む各種アイテムが入手できた場合は、所持アイテムデータ２２１の内容も適宜更新される。また、パートナーの指定操作や解任操作が行われていた場合は、その操作内容に基づき、パートナーモード情報２２２および現在のパートナー情報２２３が更新される。すなわち、パートナーモード／ノンパートナーモードの切り替え処理が行われる。また、パートナーモードである場合にパートナーの変更操作が行われていれば、操作内容に基づいてパートナーを変更し、更に、現在のパートナー情報２２３を適宜更新する処理も実行される。また、受け取り可能な達成報酬の有無を判定し、それに応じて上記図４で示したパートナー画像２０１の表示内容を変化させる処理（受け取り可能報酬があることを示す表示のオンオフ等）も行われる。特に、本実施形態では、課題更新タイミングが到来しても、すぐには受け取り可能報酬があることを示す表示は行わずに、何らかのゲーム内シーンの遷移が発生したタイミングで、受け取り可能報酬があることを示す表示の設定が行われる。これは、上記のようにパートナーはゲーム内においてプレイヤキャラクタの後ろをついてくるという体裁であるところ、プレイヤが知らない間にパートナーがゲーム課題を自動代行してきているように見えることを防ぐためである。つまり、シーン遷移の間にパートナーが自動代行を行ったような体裁として、プレイヤに違和感を与えることを防ぐものである。そして、上記のような各種のゲーム処理を反映したゲーム画面を生成して表示する処理も実行される。

ステップＳ１２の処理が終われば、上記ステップＳ２に戻り、所定のゲーム終了指示（ログアウト操作等）が行われるまで、処理が繰り返される。以上で、本実施形態のゲーム処理の詳細説明を終了する。

このように、本実施形態では、アイテムなどの消費を条件に達成されるゲーム課題があり、これをパートナーによる自動代行で達成扱いとする場合は、本来は達成条件とされているアイテム等の消費を行わないようにしている。つまり、プレイヤの操作無しでゲーム課題が達成できるところ、この達成に伴ってプレイヤが意図していないアイテムの消費が発生してしまうことを防ぐことができる。これにより、ゲーム課題の達成についての利便性を高めることができる。

［変形例］
なお、上記実施形態では、パートナーがゲーム課題を自動代行する場合は、一切のアイテム消費が発生しない場合を例に挙げた。これに限らず、本来消費される分よりは少ない数でアイテム消費が発生するようにしてもよい。例えば、本来の要求アイテムが「りんごを１個、ももを３個」である場合、パートナーによる自動代行で達成される際には、「りんごが１個、ももが１個」というように、本来の要求数より小さい数だけ消費されるようにしてもよい。

また、自動代行の対象とするゲーム課題に関して、プレイヤの操作によって達成されていない、すなわち、未達成のゲーム課題のうちの一部だけを対象としてもよいし、（上記の例のように）未達成のゲーム課題の全てを対象としてもよい。

また、上記の例では、３時間毎にゲーム課題を更新する例を挙げた。この時間の判定については、現実の時間を用いてもよいし、現実の時間の進み方とは異なり得るゲーム内時間を基準に判定してもよい。

また、他の実施形態では、例えば３時間毎にゲーム課題を更新する場合、３時間毎に、その時点で未達成のゲーム課題を自動代行するような制御を行ってもよい。この場合は、例えばサーバ側の処理として、３時間毎に未達成のゲーム課題を自動代行して、上記自動代行結果データ２２５を更新するような処理を行うようにすればよい。

また、上記レポート画面の表示に関して、上記の例ではパートナー画像２０１をタップ操作することで表示される場合を例示した。この他、他の実施形態では、ゲームが起動（再開）されたタイミングで、その時点で達成報酬が未受け取りのゲーム課題についての上記レポート画面を表示するようにしてもよい。上記のように、例えば３時間毎に未達成のゲーム課題を自動代行するような場合、ゲームを起動するだけで自動代行分の達成報酬をプレイヤに受け取らせることもでき、プレイヤの利便性を更に向上させることができる。

また、上記の例では、１体のＮＰＣにつき１つのゲーム課題が対応づけられている例で説明したが、他の実施形態では、１体のＮＰＣが複数のゲーム課題をプレイヤに提示できるようにしてもよい。例えば、１体のＮＰＣにつき５件のゲーム課題を設定するようにしてもよい。この場合、各ＮＰＣは、所定の順番で１つずつゲーム課題をプレイヤに提示できるようにすればよい。例えば、１つめのゲーム課題を提示し、これが達成されれば、２つめのゲーム課題をプレイヤに提示可能なようにすればよい。

また、上記の例では、ゲーム課題を出すＮＰＣが５体である場合を例示したが、この数は一例であり、これより多くても少なくてもよく、１体だけであってもよいことは言うまでも無い。

また、上記の例では、ゲーム課題を開始する場合、「受注」する操作を行う場合を例に挙げた。他の実施形態では、この受注のための操作は不要としてもよい。例えば、上記のような受注のための操作を行うことなく、要求アイテムが既に揃っている状態で上記ＮＰＣに話しかけるだけで、ゲーム課題が達成されるようにしてもよい。この場合は、ゲーム課題が更新されたタイミングで、各ゲーム課題自体が開始されたものとして扱うような処理を行えばよい。

また、他の実施形態では、ゲームを最初に開始してから、初めてパートナーを設定した場合に限り、所定のゲーム課題を即時に自動代行させ、報酬をプレイヤに付与するようにしてもよい。パートナーによる自動代行の機能のデモンストレーション的な意味合いで、自動代行の効果をプレイヤにすぐにわかりやすく伝えることができる。

また、他の実施形態では、パートナーに、上記のような自動代行に加えて、ゲーム内で入手可能なアイテムも収集させるようにしてもよい。そして、例えば上記レポート画面で達成報酬をプレイヤに付与するタイミングに併せて、収集したアイテムをプレイヤに付与するようにしてもよい。例えば、上述の「りんご」や「もも」等のアイテムを所定数、プレイヤに付与してもよい。

また、上記実施形態では、ゲーム課題を達成した際に、当該ゲーム課題の依頼主のＮＰＣとの親密度が変化する例を示した。この親密度に関して、他の実施形態では、次のような制御を行ってもよい。まず、あるゲーム課題に対して、プレイヤの操作に基づいて（つまり、自動代行を使わずに）ゲーム課題を達成した場合は、依頼主のＮＰＣの親密度が第１変化量だけ上がる。一方、パートナーによる自動代行で当該ゲーム課題が達成された場合は、当該ＮＰＣの親密度は変化させないようにしてもよい。あるいは、上記第１変化量よりも小さい量である第２変化量だけ上げるようにしてもよい。これは、課題の受注や要求アイテムのＮＰＣへの譲渡において、プレイヤキャラクタと依頼主のＮＰＣとが直接会って話をするという体裁で処理するところ、プレイヤキャラクタと会ってもいないのに親密度が変化することには違和感があると考えられるためである。

また、上記自動代行によるゲーム課題の達成に伴い、パートナーとして指定している仮想キャラクタとの親密度を上げるようにしてもよい。例えば、上記レポート画面の表示処理において、パートナーがゲーム課題を達成したことを示す演出を表示するタイミングで、当該パートナーの親密度を上げる処理を行ってもよい。これにより、特に親密度を上げたい仮想キャラクタをパートナーに設定することで、親密度をより高めやすくすることが可能となる。

また、他の実施形態では、パートナーの指定のために条件を設けてもよい。例えば、仮想キャラクタ毎に設定されている所定のアイテムをプレイヤ（キャラクタ）が所持していることを条件として、所定の仮想キャラクタをパートナーとして設定可能なようにしてもよい。換言すれば、条件となる所定アイテムを揃えるまではパートナーとしての指名ができないようにしてもよい。

また、所定の対価をプレイヤまたはプレイヤキャラクタが払うことを条件として、パートナーを設定できるようにしてもよい。例えば、所定のサブスクリプションサービスに加入し、所定の月額料金を支払うことでパートナー設定権を有効にすることが可能なようにしてもよい。つまり、月額料金を支払ったプレイヤのみが、パートナーを設定することが可能となるような構成としてもよい。

また、上記実施形態では、課題更新タイミングが到来しても、すぐには受け取り可能報酬があることを示す表示は行わずに、何らかのゲーム内シーンの遷移が発生したタイミングで、受け取り可能報酬があることを示す表示の設定を行っていた。すなわち、未達成の課題を達成済みとする処理自体は課題更新タイミングで行っていた。この点に関して、他の実施形態では、課題更新タイミングが到来した後、何らかのゲーム内シーンの遷移が発生したタイミングで、更新前に未達成であった課題をパートナーが代行する処理（達成済みとする処理）を行うようにしてもよい。

また、上記の例では、達成報酬（自動代行結果データ２２５）が上限まで貯まっている場合は、それ以上の自動代行はできないような構成を例に挙げた。他の実施形態では、このような場合でも、古いものから順に消去していき、自動代行が可能なようにしてもよい。この場合は、常に最新のデータが（上限の件数分まで）格納されることになる。

また、上記の例では、パートナーとして１体のＮＰＣを設定する例を挙げたが、他の実施形態では、複数体のＮＰＣを同時にパートナーとして設定できるようにしてもよい。そして、この複数のパートナーが手分けして未達成のゲーム課題を自動代行するような制御を行ってもよい。

また、上記実施形態では、サーバ１０１とスマートデバイス１０２とが協働してゲーム処理を行う例を挙げたが、他の実施形態では、スマートデバイス１０２のみで上記のようなゲーム処理が行われるようにしてもよい。すなわち、上述のサーバ１０１に記憶される各種データをスマートデバイス１０２に記憶するように構成し、スマートデバイス１０２だけで上述したような処理が完結する、いわゆるスタンドアローンの形式でゲーム処理を行ってもよい。

１０１サーバ
１０２スマートデバイス
１１１プロセッサ
１１３メモリ
１１４通信部
１１５操作部
１１６表示部
１２１プロセッサ
１２３メモリ
１２４通信部

Claims

情報処理装置のコンピュータにおいて実行される情報処理プログラムであって、
前記コンピュータを、
ゲームのプレイヤまたは当該ゲームのプレイヤキャラクタに関連付けられ、ゲーム課題の達成に関連するプレイヤ関連パラメータを管理するパラメータ管理手段と、
前記ゲームにおいて設定された前記ゲーム課題の状態を管理する課題管理手段と、
前記プレイヤによる切替入力に基づいて、前記ゲームの状態を第１モードと第２モードとで切り替えるモード切替手段と、
前記ゲームの状態が前記第１モードの場合、前記プレイヤにより前記ゲームがプレイされている間に、前記プレイヤ関連パラメータが、少なくとも、前記ゲーム課題の達成に必要となる第１変化量だけ変化させることが可能な状態か否かを当該プレイヤ関連パラメータに基づいて判定し、未達成の前記ゲーム課題を達成するために行われる当該プレイヤによる操作入力に基づいて、前記プレイヤ関連パラメータを前記第１変化量だけ変化させることが可能な状態であることを条件として、当該プレイヤ関連パラメータを当該第１変化量だけ変化させるとともに前記ゲーム課題が達成されたと判定する第１達成手段と、
前記ゲームの状態が前記第２モードの場合、前記プレイヤにより前記ゲームがプレイされていなくても、前記プレイヤ関連パラメータを変化させずに前記ゲーム課題が達成されたと判定する、または、前記プレイヤ関連パラメータが前記第１変化量よりも小さい第２変化量だけ変化させることが可能な状態か否かを当該プレイヤ関連パラメータに基づいて判定し、当該プレイヤ関連パラメータを前記第２変化量だけ変化させることが可能な状態であることを条件として、当該プレイヤ関連パラメータを当該第２変化量だけ変化させるとともに前記ゲーム課題が達成されたと判定する、第２達成手段として機能させる、情報処理プログラム。
前記第２達成手段は、前記第１達成手段または前記第２達成手段により達成されたと判定され得る前記ゲーム課題のうち、当該第１達成手段によって達成されたと判定されていない当該ゲーム課題について、達成されたと判定する、請求項１に記載の情報処理プログラム。
前記第２達成手段は、前記第１達成手段または前記第２達成手段により達成されたと判定され得る前記ゲーム課題のうち、当該第１達成手段により達成されたと判定されていない当該ゲーム課題の全てについて、達成されたと判定する、請求項１に記載の情報処理プログラム。
前記課題管理手段は、ゲーム内時間の経過または現実の時間の経過に応じて前記ゲーム課題を更新する、請求項１乃至３のいずれかに記載の情報処理プログラム。
前記第２達成手段は、前記課題管理手段により前記ゲーム課題の更新が行われたことに応じて、当該更新される前の前記ゲーム課題が達成されたと判定する、請求項４に記載の情報処理プログラム。
前記第２達成手段は、前記ゲームが起動されたときに、当該ゲームを前回プレイし終えたとき以降の現実の時間経過に応じた数量の前記ゲーム課題が達成されたものとして判定する、請求項１乃至５のいずれかに記載の情報処理プログラム。
前記課題管理手段は、前記プレイヤまたは前記プレイヤキャラクタが所有するアイテムを前記ゲーム内のノンプレイヤキャラクタに譲渡することが達成条件である前記ゲーム課題を、当該ノンプレイヤキャラクタ毎に関連付けて設定する、請求項１乃至６のいずれかに記載の情報処理プログラム。
前記情報処理プログラムは、
複数の前記ノンプレイヤキャラクタから少なくとも１つのノンプレイヤキャラクタを指定するキャラクタ指定手段と、
前記指定されたノンプレイヤキャラクタが、前記プレイヤまたは前記プレイヤキャラクタの代わりに前記ゲーム課題を達成するゲーム演出を実行する演出手段として前記コンピュータを更に機能させ、
前記課題管理手段は、前記指定されたノンプレイヤキャラクタを除くノンプレイヤキャラクタ毎に前記ゲーム課題を関連付けて設定する、請求項７に記載の情報処理プログラム。
前記第２達成手段は、初めて、前記キャラクタ指定手段による前記ノンプレイヤキャラクタの指定が行われたとき、当該指定に応じて少なくとも１つの前記ゲーム課題が達成されたと判定し、
前記演出手段は、前記初めての指定に応じて達成された前記ゲーム課題に係る前記ゲーム演出を実行する、請求項８に記載の情報処理プログラム。
前記キャラクタ指定手段は、前記プレイヤまたは前記プレイヤキャラクタが特定のアイテムを所持していることを条件として、当該特定のアイテムに対応する前記ノンプレイヤキャラクタを指定可能とする、請求項８または９に記載の情報処理プログラム。
前記情報処理プログラムは、前記ゲーム課題が達成されたことに基づき、前記プレイヤまたは前記プレイヤキャラクタに報酬を付与する報酬付与手段として前記コンピュータを更に機能させる、請求項１乃至１０のいずれかに記載の情報処理プログラム。
前記報酬付与手段は、前記第２達成手段により前記ゲーム課題が達成されたことによる報酬を付与する時点において前記プレイヤまたは前記プレイヤキャラクタが前記ゲーム内で取得し得るアイテムを、当該プレイヤまたは当該プレイヤキャラクタに更に付与する、請求項１１に記載の情報処理プログラム。
前記第２達成手段は、前記ゲームの状態が前記第２モードである場合であって、前記プレイヤにより前記ゲームがプレイされている間に前記課題管理手段により前記ゲーム課題の更新が行われた場合、当該更新の後で前記ゲームの画面の遷移が行われたときに、前記ゲーム課題が達成されたと判定する、請求項５に記載の情報処理プログラム。
前記情報処理プログラムは、前記プレイヤの確認操作入力に基づいて、前回の当該確認操作入力以降に達成された前記ゲーム課題を確認できる画像を生成する確認画面生成手段として前記コンピュータを更に機能させる、請求項１乃至１３のいずれかに記載の情報処理プログラム。
前記課題管理手段は、ゲーム内時間の経過または現実の時間の経過に応じて前記ゲーム課題を更新し、
前記第２達成手段は、達成された前記ゲーム課題を確認するための前記確認操作入力が行われていない状態で前記課題管理手段により前記ゲーム課題が更新された場合、更新後の当該ゲーム課題についても、前記プレイヤ関連パラメータを変化させずに前記ゲーム課題が達成されたと判定する、または当該プレイヤ関連パラメータを前記第２変化量だけ変化させることが可能な状態であることを条件として、当該プレイヤ関連パラメータを当該第２変化量だけ変化させるとともに前記ゲーム課題が達成されたと判定する、請求項１４に記載の情報処理プログラム。
前記第２達成手段は、
前記確認操作入力が行われていない状態で前記ゲーム課題が更新された場合に当該更新後の前記ゲーム課題が達成されたと判定する処理を、所定の回数を上限回数として繰り返し実行し、
前記確認操作入力が行われたことに応じて、当該判定の実行回数のカウントをリセットする、請求項１５に記載の情報処理プログラム。
前記情報処理プログラムは、前記第１達成手段により前記ゲーム課題が達成されたと判定した場合は、当該ゲーム課題に関連付けられた前記ノンプレイヤキャラクタに対応するノンプレイヤ関連パラメータを第３変化量だけ変化させ、前記第２達成手段により前記ゲーム課題が達成されたと判定した場合は、当該ノンプレイヤ関連パラメータを変化させない、または、当該第３変化量よりも小さい第４変化量だけ当該ノンプレイヤ関連パラメータを変化させるパラメータ管理手段として前記コンピュータをさらに機能させる、請求項７に記載の情報処理プログラム。
複数の前記ノンプレイヤキャラクタから少なくとも１つのノンプレイヤキャラクタを指定するキャラクタ指定手段と、
前記指定されたノンプレイヤキャラクタが、前記プレイヤまたは前記プレイヤキャラクタの代わりにゲーム課題を達成するゲーム演出を実行する演出手段として前記コンピュータをさらに機能させ、
前記第２達成手段により前記ゲーム課題が達成されたと判定した場合に、前記キャラクタ指定手段により指定された前記ノンプレイヤキャラクタに関連付けられた前記ノンプレイヤ関連パラメータを変化させる、請求項１７に記載の情報処理プログラム。
前記モード切替手段は、前記第１モードの状態を前記ゲームの状態の基準とし、前記プレイヤまたは前記プレイヤキャラクタが対価を払うことを条件として、前記第１モードを前記第２モードへと切り替える、請求項１乃至１８のいずれかに記載の情報処理プログラム。
前記モード切替手段は、前記プレイヤまたは前記プレイヤキャラクタが対価を払うことで有効となった権利が存続していることを条件として、前記第１モードを前記第２モードへと切り替える、請求項１９に記載の情報処理プログラム。
前記第２達成手段は、前記ゲームの状態が前記第２モードの場合、前記ゲームが起動または操作されていなくても、前記プレイヤ関連パラメータを変化させずに前記ゲーム課題が達成されたと判定する、または当該プレイヤ関連パラメータを前記第２変化量だけ変化させることが可能な状態であることを条件として、当該プレイヤ関連パラメータを当該第２変化量だけ変化させるとともに前記ゲーム課題が達成されたと判定する、請求項１乃至２０のいずれかに記載の情報処理プログラム。
ゲームのプレイヤまたは当該ゲームのプレイヤキャラクタに関連付けられ、ゲーム課題の達成に関連するプレイヤ関連パラメータを管理するパラメータ管理手段と、
前記ゲームにおいて設定された前記ゲーム課題の状態を管理する課題管理手段と、
前記プレイヤによる切替入力に基づいて、前記ゲームの状態を第１モードと第２モードとで切り替えるモード切替手段と、
前記ゲームの状態が前記第１モードの場合、前記プレイヤにより前記ゲームがプレイされている間に、前記プレイヤ関連パラメータが、少なくとも、前記ゲーム課題の達成に必要となる第１変化量だけ変化させることが可能な状態か否かを当該プレイヤ関連パラメータに基づいて判定し、未達成の前記ゲーム課題を達成するために行われる当該プレイヤによる操作入力に基づいて、前記プレイヤ関連パラメータを前記第１変化量だけ変化させることが可能な状態であることを条件として、当該プレイヤ関連パラメータを当該第１変化量だけ変化させるとともに前記ゲーム課題が達成されたと判定する第１達成手段と、
前記ゲームの状態が前記第２モードの場合、前記プレイヤにより前記ゲームがプレイされていなくても、前記プレイヤ関連パラメータを変化させずに前記ゲーム課題が達成されたと判定する、または、前記プレイヤ関連パラメータが前記第１変化量よりも小さい第２変化量だけ変化させることが可能な状態か否かを当該プレイヤ関連パラメータに基づいて判定し、当該プレイヤ関連パラメータを前記第２変化量だけ変化させることが可能な状態であることを条件として、当該プレイヤ関連パラメータを当該第２変化量だけ変化させるとともに前記ゲーム課題が達成されたと判定する、第２達成手段とを備える、情報処理装置。
ゲーム処理を行うプロセッサを備える情報処理システムであって、
ゲームのプレイヤまたは当該ゲームのプレイヤキャラクタに関連付けられ、ゲーム課題の達成に関連するプレイヤ関連パラメータを管理するパラメータ管理手段と、
前記ゲームにおいて設定された前記ゲーム課題の状態を管理する課題管理手段と、
前記プレイヤによる切替入力に基づいて、前記ゲームの状態を第１モードと第２モードとで切り替えるモード切替手段と、
前記ゲームの状態が前記第１モードの場合、前記プレイヤにより前記ゲームがプレイされている間に、前記プレイヤ関連パラメータが、少なくとも、前記ゲーム課題の達成に必要となる第１変化量だけ変化させることが可能な状態か否かを当該プレイヤ関連パラメータに基づいて判定し、未達成の前記ゲーム課題を達成するために行われる当該プレイヤによる操作入力に基づいて、前記プレイヤ関連パラメータを前記第１変化量だけ変化させることが可能な状態であることを条件として、当該プレイヤ関連パラメータを当該第１変化量だけ変化させるとともに前記ゲーム課題が達成されたと判定する第１達成手段と、
前記ゲームの状態が前記第２モードの場合、前記プレイヤにより前記ゲームがプレイされていなくても、前記プレイヤ関連パラメータを変化させずに前記ゲーム課題が達成されたと判定する、または、前記プレイヤ関連パラメータが前記第１変化量よりも小さい第２変化量だけ変化させることが可能な状態か否かを当該プレイヤ関連パラメータに基づいて判定し、当該プレイヤ関連パラメータを前記第２変化量だけ変化させることが可能な状態であることを条件として、当該プレイヤ関連パラメータを当該第２変化量だけ変化させるとともに前記ゲーム課題が達成されたと判定する、第２達成手段とを備える、情報処理システム。
情報処理装置を制御するコンピュータが実行する情報処理方法であって、
前記コンピュータに、
ゲームのプレイヤまたは当該ゲームのプレイヤキャラクタに関連付けられ、ゲーム課題の達成に関連するプレイヤ関連パラメータを管理させ、
前記ゲームにおいて設定された前記ゲーム課題の状態を管理させ、
前記プレイヤによる切替入力に基づいて、前記ゲームの状態を第１モードと第２モードとで切り替えさせ、
前記ゲームの状態が前記第１モードの場合、前記プレイヤにより前記ゲームがプレイされている間に、前記プレイヤ関連パラメータが、少なくとも、前記ゲーム課題の達成に必要となる第１変化量だけ変化させることが可能な状態か否かを当該プレイヤ関連パラメータに基づいて判定し、未達成の前記ゲーム課題を達成するために行われる当該プレイヤによる操作入力に基づいて、前記プレイヤ関連パラメータを前記第１変化量だけ変化させることが可能な状態であることを条件として、当該プレイヤ関連パラメータを当該第１変化量だけ変化させるとともに前記ゲーム課題が達成されたと判定させ、
前記ゲームの状態が前記第２モードの場合、前記プレイヤにより前記ゲームがプレイされていなくても、前記プレイヤ関連パラメータを変化させずに前記ゲーム課題が達成されたと判定する、または、前記プレイヤ関連パラメータが前記第１変化量よりも小さい第２変化量だけ変化させることが可能な状態か否かを当該プレイヤ関連パラメータに基づいて判定し、当該プレイヤ関連パラメータを前記第２変化量だけ変化させることが可能な状態であることを条件として、当該プレイヤ関連パラメータを当該第２変化量だけ変化させるとともに前記ゲーム課題が達成されたと判定させる、情報処理方法。