JP2018068888A - イベント制御方法及びイベント制御プログラム - Google Patents

Abstract

【課題】ゲーム中に実行されるイベントを作成する際、作成したイベントを他の端末装置と共有することを目的とする。【解決手段】ゲーム中に実行されるイベントを作成する際の制御処理をコンピュータが実行するイベント制御方法であって、イベント条件及びイベント結果の少なくともいずれかの設定条件を受け付け、受け付けた前記設定条件に応じて前記イベントを実行するために補完すべき条件を抽出し、前記補完すべき条件を含むイベント条件が設定されたイベントのデータを、イベントを作成した端末装置と異なる他の端末装置から利用可能な状態にする、イベント制御方法が提供される。【選択図】図１６

Description

本発明は、イベント制御方法及びイベント制御プログラムに関する。

ユーザが望む展開の仮想空間のイベントをユーザが独自に作成し、他のユーザの端末装置にそのイベントを実行させる技術が知られている（例えば、特許文献１参照）。特許文献１では、イベントを作成したユーザの端末装置は、他のユーザの端末装置で行われたプレイの内容をフィードバックし、イベント内容をブラッシュアップする。イベントの一例としては、歴史上の人物の架空の会話等が挙げられる。

特開２０１０−１７２６５６号公報 特開２００１−３１１６２６号公報

しかしながら、特許文献１では、作成したイベントは単独で実行されるものであり、イベントに関連するゲーム中に実行されるものではない。この場合、作成したイベントの内容が、ゲームのストーリや進行度合いと矛盾しないようにしたり、逆にゲームのストーリをイベント結果に応じて変化させたりする必要はない。

一方、ユーザが作成したイベントが、ゲーム中に実行され、ゲームに影響を与える場合、ゲームの内容とイベントを実行した結果とが矛盾しないように制御する必要がある。このため、イベント作成時にイベントを実行するための条件（以下、「イベント条件」ともいう。）を設定し、ゲーム中にイベント条件を満足したときにイベントが実行されるようにする。

ところが、ユーザが、ゲームのストーリと矛盾しないために必要なすべてのイベント条件を抽出し、設定することは煩雑であり、時間がかかる。また、ユーザが手動でイベント条件を設定する場合、設定したイベント条件に誤りや不足が生じる場合がある。その結果、ゲーム中にイベントが実行できないことがある。

他方、ゲームのストーリと矛盾しないために必要なすべてのイベント条件が設定されたイベントを他の端末装置においても利用できれば、他の端末装置のプレイヤは、イベントの作成の際のイベント条件の設定の手間が省ける。また、設定したイベント条件に誤りや不足がなく、ゲームをより楽しむことができる。

そこで、一側面では、本発明は、ゲーム中に実行されるイベントを作成する際、作成したイベントを他の端末装置と共有することを目的とする。

一つの案では、ゲーム中に実行されるイベントを作成する際の制御処理をコンピュータが実行するイベント制御方法であって、イベント条件及びイベント結果の少なくともいずれかの設定条件を受け付け、受け付けた前記設定条件に応じて前記イベントを実行するために補完すべき条件を抽出し、前記補完すべき条件を含むイベント条件が設定されたイベントのデータを、イベントを作成した端末装置と異なる他の端末装置から利用可能な状態にする、イベント制御方法が提供される。

一側面によれば、ゲーム中に実行されるイベントを作成する際、作成したイベントを他の端末装置と共有することができる。

一実施形態に係る端末装置のハードウェア構成の一例を示す図。 一実施形態に係る端末装置の機能構成の一例を示す図。 一実施形態に係るイベント結果ＤＢの一例を示す図。 一実施形態に係るイベント条件ＤＢの一例を示す図。 一実施形態に係るテーブルの一例を示す図。 一実施形態に係るゲーム実行処理の一例を示すフローチャート。 一実施形態に係るイベント制御処理の一例を示すフローチャート。 一実施形態に係るイベント作成画面の一例を示す図。 一実施形態に係るイベント概要作成画面の一例を示す図。 一実施形態に係るイベント結果編集画面の一例を示す図。 一実施形態に係るイベント条件編集画面の一例を示す図。 一実施形態に係るイベント内容編集画面の一例を示す図。 一実施形態に係るイベントセット編集画面の一例を示す図。 一実施形態に係るイベントの実行結果の表示例を示す図。 一実施形態に係るイベントの実行結果の表示例を示す図。 一実施形態に係るイベントの共有システムの一例を示す図。 一実施形態に係るイベント共有処理の一例を示すフローチャート。

以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。

［歴史イベント］
ゲーム中に実行されるイベントがある。ゲームのプレイヤ（ユーザ）は、自分が希望する展開のイベントを独自に作成することができる。その際、プレイヤは、ゲームに登場するキャラクタやその他のキャラクタを使用して、プレイヤが望む展開のイベントを作成したり、ストーリでは語られていない出来事を想像してイベントを作成したりすることができる。作成したイベントは、ゲーム中にイベント条件が満たされたタイミングに実行される。

イベントには、複数種類のイベントがあり、歴史イベント及び依頼イベントを含む。例えば、歴史上のシナリオに基づき実行されるゲームにおいて、プレイヤは、歴史イベント及び依頼イベントの２種類のイベントを作成でき、各イベントにおいて自分が望む歴史上の人物の会話等を設定できる。プレイヤは、武将同士の会話内容や、その歴史イベントが発生する条件、発生後の出来事等、さまざまな設定を行うことができ、武将の婚姻や君主の交代、勢力の同盟や家宝の授与等、自分だけの歴史イベントを作成することができる。

歴史イベントは、武将の所属、武将の状態変更、武将の所属都市、武将の所属変更等に関するイベント条件が、ゲーム進行中に満たされた際に単発で発生するイベントである。依頼イベントは、絆成立や金を獲得できるイベント等、リクエスト（お使い）形式のイベントであり、歴史イベントと異なり、単発で発生するわけではなく、リクエストに対してゲーム内でリクエストを満足できるようにゲームが展開されているか等の一連の流れで発生する。依頼イベントの一例としては、特定の条件を満たしたときに武将が訪ねてくるイベント等が挙げられる。

以下では、主に歴史イベントの作成及び作成した歴史イベントの共有の機能を有する端末装置１０の一実施形態について説明する。本実施形態に係る端末装置１０は、ゲーム機器（携帯用ゲーム機器を含む）であってもよいし、パーソナルコンピュータ（ＰＣ）であってもよい。ただし、本実施形態に係る端末装置はこれに限らず、スマートフォン、携帯端末、ＰＤＡ（Personal Digital Assistants）、携帯電話、携帯用ゲーム機器、ＨＭＤ（Head Mount Display）、ＦＭＤ（Face Mount Display）等のウェアラブル表示デバイスであってもよい。

［端末装置のハードウェア構成］
まず、本実施形態に係る端末装置１０のハードウェア構成の一例について、図１を参照しながら説明する。本実施形態に係る端末装置１０は、ＣＰＵ（Central Processing Unit）２１、ＲＯＭ（Read Only Memory）２２、ＲＡＭ２３及びＨＤＤ（Hard Disk Drive）２４を有している。また、端末装置１０は、グラフィックカード２５、外部Ｉ／Ｆ２６、通信Ｉ／Ｆ２７、入力Ｉ／Ｆ２８、ディスプレイ２９及びスピーカ３０を有している。各部はバスで相互に接続されている。

ＲＯＭ２２は、電源を切っても内部データを保持することができる不揮発性の半導体メモリである。ＲＡＭ２３は、プログラムやデータを一時保持する揮発性の半導体メモリである。ＲＯＭ２２及びＲＡＭ２３には、プログラム及びデータが格納されている。

ＨＤＤ２４は、プログラムやデータを格納している不揮発性の記憶装置である。ＨＤＤ２４には、端末装置１０の全体を制御する基本ソフトウェア及びアプリケーションソフトウェアのプログラムが格納されてもよい。ＨＤＤ２４には、各種のデータベースが格納されてもよい。本実施形態では、ＨＤＤ２４には、基本処理プログラム、ゲーム実行処理プログラム、イベント制御処理プログラム等の各種のプログラム及び各種のデータが格納されている。

ＣＰＵ２１は、例えばＨＤＤ２４から各種プログラム及び各種データをＲＡＭ２３上に読み出し、各種の処理を実行することで、端末装置１０の全体の制御や端末装置１０に搭載された機能を実現する。

外部Ｉ／Ｆ２６は、端末装置１０を外部装置に接続するインターフェースである。外部装置には、記録媒体２６ａなどがある。これにより、端末装置１０は、外部Ｉ／Ｆ２６を介して記録媒体２６ａの読み取り及び書き込みを行うことができる。記録媒体２６ａの一例としては、ＣＤ（Compact Disk）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（SD Memory card）又はＵＳＢメモリ（Universal Serial Bus memory）等が挙げられる。

例えば、端末装置１０には、ゲーム実行処理プログラム及びイベント制御処理プログラム等が格納された記録媒体２６ａを装着することが可能である。これらのプログラムは、外部Ｉ／Ｆ２６により読み出されて、ＲＡＭ２３に読み込まれる。

ＣＰＵ２１は、ＲＡＭ２３に読み込まれたゲーム実行プログラム及びイベント制御処理プログラムを実行し、グラフィックカード２５にゲーム及び歴史イベントの進行に応じた画像の出力を指示する。グラフィックカード２５は、指示に従い画面に表示するゲームの画像処理や歴史イベントの画像処理を行い、ゲーム画像及びイベント画像をディスプレイ２９に描画させる。グラフィックカード２５から出力される画像の一フレーム時間は、例えば１／３０〜１／６０秒である。グラフィックカード２５は、フレーム単位で１枚の画像の描画を実行する。すなわち、一秒間に３０回〜６０回のフレームの画像が描画される。

また、ＣＰＵ２１は、ＲＡＭ２３に読み込まれた上記の各種プログラムを処理し、ゲームや歴史イベントの進行に応じてスピーカ３０から所定の音を出力させる。

通信Ｉ／Ｆ２７は、端末装置１０をネットワークに接続するインターフェースである。通信Ｉ／Ｆ２７は、アンテナを有する通信ユニットを介して他プレイヤの端末装置やサーバと通信を行う。

入力Ｉ／Ｆ２８は、コントローラ４０等の入力機器に接続するインターフェースである。コントローラ４０は、操作ボタン及び方向キーを有する。プレイヤは、コントローラ４０を用いてゲーム操作を行う。例えば、プレイヤは、操作ボタンを操作することでプレイヤキャラクタに所定の動作を行わせることができる。また、プレイヤは、方向キーを操作することでプレイヤキャラクタを所定の方向に移動させることができる。入力Ｉ／Ｆ２８は、プレイヤがコントローラ４０を用いて行った入力操作に基づく入力情報をＲＡＭ２３に格納させる。また、プレイヤが、コントローラ４０を操作してゲームの開始を指示したとき、入力Ｉ／Ｆ２８が、その指示情報を入力することによりゲーム処理が開始される。

ＣＰＵ２１がＲＡＭ２３に格納された入力情報に基づきプレイヤキャラクタの動作等の各種の演算処理を実行すると、入力Ｉ／Ｆ２８はＣＰＵ２１からの指示に従いＲＡＭ２３に記憶されているゲームのデータをメモリカード２８ａに保存させる。また、入力Ｉ／Ｆ２８は、メモリカード２８ａに保存されている中断時のゲームのデータを読み出してＲＡＭ２３に転送し、ＲＡＭ２３に保持させる処理を行う。

［携帯用ゲーム機器の機能構成］
次に、本実施形態に係る端末装置１０の機能構成の一例について、図２を参照しながら説明する。端末装置１０は、受付部１１、ゲーム実行部１２、記憶部１３、イベント制御部１４、グラフィック処理部１６、サウンド処理部１７、表示部１８、音出力部１９及び通信部２０を有する。

受付部１１は、プレイヤのゲーム操作を受け付ける。例えば、受付部１１は、コントローラ４０の操作キーや方向キーの操作を受け付ける。歴史イベント作成時、受付部１１は、イベント内容、イベント条件及びイベント結果の少なくともいずれかの設定条件を受け付ける。受付部１１の機能は、例えば入力Ｉ／Ｆ２８又は外部Ｉ／Ｆ２６により実現される。

ゲーム実行部１２は、ゲーム実行処理プログラムに従いゲーム処理を実行する。本実施形態にて実行されるゲームは、単独でプレイするゲームであってもよいし、ネットワークを介して接続される他プレイヤと共同でプレイする通信ゲームであってもよい。

記憶部１３は、イベント結果ＤＢ１３１、イベント条件ＤＢ１３２、イベント登録ＤＢ１３４を記憶する。図３に、一実施形態に係るイベント結果ＤＢ１３１の一例を示す。イベント結果ＤＢ１３１には、イベント作成時にプレイヤが設定可能な「イベント結果」の項目が記憶されている。

図３が示すイベント結果名毎に、その結果名が示す設定内容の詳細が保存されている。例えば、イベント結果が「１．君主の交代」の場合、設定内容の詳細の一例として「[指定君主]が隠居して同勢力の[指定君主]が君主になること」が記憶されている。［］内は、イベント条件毎に、プレイヤが任意の指定君主を動的に設定できる。

また、例えば、イベント結果が「２．太守の設定」の場合、設定内容の詳細の一例として「[指定都市]の太守を[指定武将]に変更すること」が記憶されている。また、例えば、イベント結果が「３．武将の死亡」の場合、設定内容の詳細の一例として「[指定武将]が死亡すること」が記憶されている。［］内は、イベント条件毎に、プレイヤが任意の指定武将、指定都市、指定勢力等を指定し、この指定に応じて動的に変更される。

図４に、一実施形態に係るイベント条件ＤＢ１３２の一例を示す。イベント条件ＤＢ１３２には、歴史イベント作成時にプレイヤが設定可能な「イベント条件」の項目が記憶されている。図４が示す条件名毎に、その条件が示す設定内容の詳細が保存されている。

例えば、イベント条件が「１．発生月日」の場合、設定内容の詳細の一例として「［指定］年［指定］月［以前／以降／一致］であること」が記憶されている。［指定］には、プレイヤが指定した年数や月が入力される。［以前／以降／一致］のように選択肢が表示されている場合には、プレイヤが以前、以降又は一致のいずれかを選択する。

また、例えば、イベント条件が「２．武将の身分」の場合、設定内容の詳細の一例として「[指定武将]が[指定身分]であること」が記憶されている。また、例えば、イベント条件が「３．武将の所属勢力」の場合、設定内容の詳細の一例として「［指定武将］が[指定勢力]に所属していること」が記憶されている。

イベント結果ＤＢ１３１とイベント条件ＤＢ１３２とに基づき、所定のイベント結果を得るために必要なイベント条件が所定の計算式により求められる。図５にイベント結果とイベント条件とを紐付けたテーブル１３３の一例を示す。テーブル１３３には、イベント結果名１３３ａ、イベント条件名１３３ｂ及び詳細条件１３３ｃの各項目が記憶されている。テーブル１３３では、イベント結果名１３３ａ毎に、その結果名が示す設定内容のイベント結果を得るために必須の条件を示すイベント条件名１３３ｂが対応付けられている。

例えば、図５では、イベント結果に「３．武将の死亡」が設定された場合、このイベント結果を得るためのイベント条件として、イベント結果名１３３ａ「３．武将の死亡」に対応するイベント条件名１３３ｂ「１４．武将の状態」、「２．武将の身分」、「１５．プレイヤ武将」の各条件が設定される。そして、これらの３つのイベント条件が、指定された武将の死亡のイベント結果を得るために補完すべき必須の条件となる。

イベント条件名１３３ｂが「１４．武将の状態」の場合、設定内容の詳細の一例として「［指定武将］が出陣していないこと」が条件となる。イベント条件名１３３ｂが「２．武将の身分」の場合、設定内容の詳細の一例として「［指定武将］が君主でないこと」が条件となる。イベント条件名１３３ｂが「２０．プレイヤ武将」の場合、設定内容の詳細の一例として「プレイヤ武将が［指定武将］でないこと」が条件となる。なお、テーブル１３３は、必ずしも作成する必要はなく、イベント結果及びイベント条件の少なくともいずれかをプレイヤが設定したことに応じて、設定に対応した補完すべきイベント条件を随時計算により自動算出すればよい。ただし、以下では、便宜上、テーブル１３３を用いて説明する。

図２に戻り、イベント登録ＤＢ１３４は、プレイヤが作成した歴史イベントを登録する。記憶部１３は、作成した歴史イベントを、イベントセットに登録する。イベントセットは、発生させたい歴史イベントをグループ化したものであり、作成した歴史イベントは、いずれかのイベントセットに属する。イベント登録ＤＢ１３４には、複数のイベントセットが登録されてもよい。イベントセットに登録された歴史イベントは、指定された順番に実行される。なお、イベント登録ＤＢ１３４は、プレイヤが作成した依頼イベントを登録してもよい。

また、記憶部１３は、ゲーム実行処理プログラム１３５及びイベント制御処理プログラム１３６をインストールし、保存する。ゲーム実行処理プログラム１３５は、ＣＰＵ２１にゲーム実行処理を実行させるためのプログラムである。イベント制御処理プログラム１３６は、ＣＰＵ２１にイベント制御処理を実行させるためのプログラムである。記憶部１３の機能は、例えば図１に示すＲＯＭ２２、ＲＡＭ２３、ＨＤＤ２４又はネットワークを介して端末装置１０に接続されるクラウド上のサーバ等により実現される。

イベント制御部１４は、歴史イベントの編集を行うイベント編集部４、歴史イベントの登録を行うイベント登録部５及びゲーム中に歴史イベントの実行を制御するイベント実行部６を有する。

イベント編集部４は、プレイヤの指示に従い、イベント条件、イベント内容及びイベント結果を編集する。イベント編集部４は、イベント条件、イベント内容及びイベント結果の少なくともいずれかを編集してもよい。イベント編集部４は、設定したイベント結果に応じて、そのイベント結果を得るために補完すべきイベント条件を抽出する。例えば、イベント編集部４は、プレイヤがイベント結果を設定すると、記憶部１３のテーブル１３３を参照して、設定したイベント結果を得るために必須のイベント条件を自動抽出し、自動で設定する。

イベント編集部４は、自動抽出したイベント条件及びプレイヤが設定したイベント条件の中で任意に指定可能な条件（指定武将など）の引数に、プレイヤが指定した条件を動的に設定する。例えば、イベント編集部４は、プレイヤが設定したイベント条件にて任意に指定可能な「指定武将」の条件の引数に、プレイヤが指定した「武将」の名前を設定してイベント条件の一部を動的に変更することができる。イベント編集部４は、自動抽出したイベント条件及びプレイヤが設定したイベント条件を表示部１８に表示する。これにより、プレイヤは、自身が設定したイベント条件だけでなく、自動抽出したイベント条件を確認することができる。

イベント登録部５は、作成した歴史イベントをイベント登録ＤＢ１３４に登録する。イベント実行部６は、ゲーム中に設定したイベント条件が満たされたとき、イベント登録ＤＢ１３４に登録した歴史イベントのうち、有効に設定されているイベントセットに属する歴史イベントを順に実行する。

イベント制御部１４は、作成した歴史イベントのデータを、歴史イベントを作成した端末装置と異なる他の端末装置から利用可能な状態にする。

かかる機能構成により、イベント実行部６が歴史イベントの内容に従い歴史イベントを実行した結果、プレイヤは、設定した内容の歴史イベントを視聴でき、設定したイベント結果を得ることができる。なお、ゲーム実行部１２及びイベント制御部１４の機能は、例えば、ゲーム実行処理プログラム１３５及びイベント制御処理プログラム１３６がＣＰＵ２１に実行させる処理により実現される。

グラフィック処理部１６は、表示部１８に接続され、ゲーム実行部１２及びイベント実行部６から描画命令が出力されると、表示部１８にビデオ信号を出力する。これにより、表示部１８は、ゲームの進行に合わせてゲームの画像及び歴史イベントの画像を表示する。グラフィック処理部１６の機能は、例えばグラフィックカード２５により実現される。表示部１８の機能は、例えばディスプレイ２９により実現される。

サウンド処理部１７は、音出力部１９に接続され、ゲーム実行部１２及びイベント実行部６からサウンド出力の指示命令が出力されると、音出力部１９にサウンド信号を出力する。これにより、音出力部１９は、ゲームの進行及び歴史イベントの実行に応じた音声及びサウンドを出力する。音出力部１９の機能は、例えばスピーカ３０により実現される。

通信部２０は、サーバや他プレイヤの端末装置と通信を行う。通信部２０の機能は、例えば通信Ｉ／Ｆ２７により実現される。例えば、イベント結果ＤＢ１３１、イベント条件ＤＢ１３２、テーブル１３３及びイベント登録ＤＢ１３４がクラウド上の記憶装置に記憶されている場合、通信部２０は、クラウド上の記憶装置から必要な情報を受信する。

なお、図２は機能に着目したブロック図を描いており、これらの機能ブロックで示した各部のソフトウエアを実行するプロセッサはハードウェアである。

［ゲーム実行処理］
次に、本実施形態に係るゲーム実行処理の一例について図６を参照して説明する。図６は、一実施形態に係るゲーム実行処理の一例を示したフローチャートである。本処理は、主にゲーム実行部１２及びイベント実行部６により実行される。ここでは、ゲーム実行部１２は所定のゲームを実行し、イベント実行部６は所定の歴史イベントを実行する。なお、以下では歴史イベントを例に挙げて説明するが、本実施形態に係るイベント制御処理が制御するイベントは、歴史イベントに限らず、依頼イベントであってもよい。

本処理が開始されると、ゲーム実行部１２は、指定されたゲームを実行する（ステップＳ１０）。次に、イベント実行部６は、歴史イベントを反映するか否かを判定する（ステップＳ１２）。イベント実行部６は、有効に設定されているイベントセットであって、ゲーム中にイベント条件が満たされた場合、ステップＳ１４に進む。イベント実行部６は、設定されたイベント条件が満たされていないと判定すると、ステップＳ１８に進み、設定されたイベント条件が満たされていると判定すると、ステップＳ１４に進む。つまり、ゲーム実行部１２は、図６のステップＳ１２において、歴史イベントを反映させる際、イベント結果を設定したことにより自動抽出したイベント条件及び手動で設定されたイベント条件がゲーム中で満たされていない場合、歴史イベントを実行しない。

ステップＳ１４において、イベント実行部６は、イベント登録ＤＢ１３４に登録されているイベントセットのうち、有効に設定されているイベントセットに含まれる歴史イベントを順番に実行する。次に、ゲーム実行部１２は、歴史イベントの実行結果に応じてゲームのストーリを変更する（ステップＳ１６）。例えば、ゲーム実行部１２は、歴史イベントにてプレイヤが指定した武将が死亡した場合、ゲームを、その武将が生きて登場する場面を無くしたストーリに変更する。

ステップＳ１８では、ゲーム実行部１２は、ゲームを終了するか否かを判定する。ゲーム実行部１２は、ゲームが終了すると判定すると、本処理を終了する。一方、ゲーム実行部１２は、ゲームを終了しないと判定すると、ステップＳ１０に戻り、ゲームを再開する。ゲーム実行部１２がステップＳ１８にてゲームを終了するまで、ステップＳ１０〜Ｓ１８の処理が繰り返される。

［イベント制御処理］
次に、本実施形態に係るイベント制御処理の一例について図７〜図１２を参照して説明する。図７は、一実施形態に係るイベント制御処理の一例を示したフローチャートである。図８〜図１３は、イベント作成画面又はイベント登録画面の一例である。本処理は、主にイベント制御部１４により実行される。

本処理が開始されると、イベント制御部１４は、歴史イベントの作成要求があるか否かを判定する（ステップＳ２０）。図８（ａ）の画面は、スタートメニューにおいてプレイヤにより「歴史イベント作成」が選択された状態を示す。「歴史イベント作成」が選択されると、表示部１８は、図８（ｂ）の「歴史イベント作成」画面に遷移する。

図８（ｂ）の「歴史イベント作成」画面では、プレイヤにより「（歴史イベントの）作成・変更」が選択されている。「作成・変更」が選択されると、表示部１８は図８（ｃ）の「作成・変更」画面に遷移する。

図８（ｃ）の「作成・変更」画面では、プレイヤにより「新規作成」が選択されている。「新規作成」が選択されると、図７のステップＳ２０において、イベント制御部１４は、歴史イベントの新規作成要求があったと判定し、歴史イベント編集画面を表示する（ステップＳ２２）。図９（ａ）の画面は、ステップＳ２２において表示された「歴史イベント編集」画面の一例を示す。

図７に戻り、次に、イベント制御部１４は、歴史イベントの概要を設定するか否かを判定する（ステップＳ２４）。図９（ａ）の画面に示すように、プレイヤが「概要」ボタンを選択すると、図７のステップＳ２４において、イベント制御部１４は、歴史イベントの概要を設定すると判定し、表示部１８は、図９（ｂ）の「イベント概要」画面に遷移する。そして、イベント制御部１４は、図９（ｂ）の「イベント概要」画面にてプレイヤが入力した歴史イベントの概要を設定する（ステップＳ２６）。図９（ｂ）の「イベント概要」画面では、歴史イベントの名前や概要等、作成する歴史イベントの基本的な情報を入力することができる。イベント形式には、「歴史イベント」と「依頼イベント」とがあり、本実施形態では、歴史イベントが選択される。

一方、プレイヤが「概要」ボタンを選択しない場合、図７のステップＳ２４において、イベント制御部１４は、歴史イベントの概要を設定しないと判定し、ステップＳ２８に進む。なお、本実施形態では、ステップＳ２４とステップＳ２８との処理を段階的に判定しているが、これに限らず、図９（ａ）の概要、結果、条件、内容の４つのボタンの押下に従い、これらのステップのいずれかを行うことができる。

次に、ステップＳ２８において、イベント制御部１４は、歴史イベントの結果（イベント結果）、条件（イベント条件）、内容（イベント内容）のいずれを設定するかを判定する。図１０（ａ）の「歴史イベント編集」画面は、プレイヤにより「結果」ボタンが選択された状態を示す。この場合、表示部１８は、図１０（ｂ）の「結果編集」画面に遷移する。

図７に戻り、次に、ステップＳ３０において、イベント制御部１４は、図１０（ｂ）の「結果編集」画面にてプレイヤが望むイベント結果を設定させる。イベント結果の設定は、イベント結果ＤＢ１３１に記憶されているイベント結果のリストからプレイヤが選択することにより行われる。

図１０（ｃ）は、図１０（ｂ）の「結果編集」画面にて結果を設定した結果の一例を示す画面である。この例では、設定したイベント結果は「３．武将の死亡」であり、その結果の詳細は「［指定武将］が死亡すること」である。なお、指定武将は、歴史上の人物に限らず、仮想の人物を指定できる。イベント制御部１４は、「結果」の補足説明を予め定義し、プレイヤに表示してもよい。これにより、プレイヤの歴史イベントの作成を容易にすることができる。

図７に戻り、次に、ステップＳ３２において、イベント制御部１４は、設定されたイベント結果を得るために補完すべきイベント条件を抽出する。イベント制御部１４は、テーブル１３３を参照し、設定したイベント結果に対応するイベント条件を抽出する。

イベント制御部１４は、図５のテーブル１３３を参照し、イベント結果名１３３ａ「３．武将の死亡」に対応する、イベント条件名１３３ｂ「１４．武将の状態」、「２．武将の身分」及び「１５．プレイヤ武将」のイベント条件を抽出する。その結果、次の３つのイベント条件が自動抽出される。
（条件１）[指定武将]が出陣していない。

このとき、表示部１８は、条件１の詳細な説明を表示可能である。例えば、表示部１８は、「条件１は、「死亡していれば」出陣や合戦を行うことはできないため、本イベント条件が自動でセットされる。」と表示してもよい。
（条件２）[指定武将]が君主でない。

例えば、表示部１８は、「条件２の「君主」は勢力の長であり、死亡していれば君主とはなり得ないので、本イベント条件が自動でセットされる。」と表示してもよい。
（条件３）プレイヤ武将が[指定武将]でない。

例えば、表示部１８は、「条件３では、プレイヤ武将が自らの死亡をイベント結果とすることはゲームのルールとして許されていないので、本イベント条件が自動でセットされる。」と表示してもよい。なお、プレイヤ武将には、プレイヤがゲームにおいて使用している武将名が表示される。

図７に戻り、次に、ステップＳ３４において、表示部１８は、イベント制御部１４が抽出したイベント条件を画面に表示する。自動抽出したイベント条件を画面に表示した例を図１１（ｂ）に示す。これにより、プレイヤは、自動設定された歴史イベントのイベント条件を把握することができる。

図７に戻り、次に、イベント制御部１４は、歴史イベントの作成を終了するか否かを判定する（ステップＳ３６）。イベント制御部１４は、プレイヤの指示に従い歴史イベントの作成を終了すると判定した場合、ステップＳ４２に進む。一方、イベント制御部１４は、歴史イベントの作成を終了しないと判定した場合、ステップＳ２８に戻る。

ステップＳ２８にて、プレイヤが図１１（ａ）に示す「条件」ボタンを選択した場合について説明する。この場合、表示部１８は、図１１（ｂ）の「条件編集」画面に遷移する。図１１（ｂ）の画面には、先程のイベント結果の設定に応じて自動抽出された歴史イベントのイベント条件が設定されている。この時点で設定されているイベント条件は、設定されたイベント結果を得るために自動抽出された最低限必要な条件である。

イベント制御部１４は、「条件編集」画面にてプレイヤにイベント条件を設定させる（ステップＳ３８）。イベント条件の設定は、イベント条件ＤＢ１３２に記憶されているイベント条件のリストからプレイヤが選択することにより行われる。

図１１（ｃ）に、イベント条件を設定した画面例を示す。図１１（ｃ）の「条件編集」画面の１〜３の条件は、「結果編集」画面にて設定したイベント結果に応じて自動抽出されたイベント条件であり、４，５の条件は、プレイヤが設定したイベント条件である。

本実施形態では、プレイヤが任意の４，５の条件を設定しているが、プレイヤは必ずしもイベント条件を手動で設定する必要はない。つまり、設定されるイベント条件には、「結果編集」画面にて設定したイベント結果に応じて抽出されたイベント条件のみが自動で設定されてもよい。なお、イベント条件よりもイベント結果を先に設定することで、イベント結果を得るために必要なイベント条件が自動設定されるため、プレイヤがイベント条件を設定する煩雑さを軽減でき、歴史イベントの作成時間を短縮できる。また、設定したイベント条件に誤りや不足が生じることを防止できる。

図７に戻り、次に、イベント制御部１４は、歴史イベントの作成を終了するか否かを判定する（ステップＳ３６）。イベント制御部１４は、歴史イベントの作成を終了すると判定した場合、ステップＳ４２に進む。一方、イベント制御部１４は、歴史イベントの作成を終了しないと判定した場合、ステップＳ２８に戻る。

ステップＳ２８において、プレイヤが図１２（ａ）に示すように「内容」ボタンを選択した場合について説明する。この場合、表示部１８は、図１２（ｂ）の画面に遷移する。プレイヤが「追加」ボタンを選択すると、表示部１８は、図１２（ｃ）の画面に移行し、イベント制御部１４は、歴史イベントの内容を編集することができる。歴史イベントの内容では、指定武将の会話の設定、背景表示の設定、ＢＧＭの設定、ナレーションの設定、イベントで表示する画像の設定等を行うことができる。

図７に戻り、ステップＳ２８〜Ｓ４０の処理が繰り返された後、ステップＳ３６において、イベント制御部１４がプレイヤの指示に従い歴史イベントの作成を終了すると判定した場合、ステップＳ４２に進む。ステップＳ４２において、記憶部１３は、歴史イベントをイベント登録ＤＢ１３４に登録し、イベントセットの有効又は無効を設定する。つまり、イベント制御部１４は、登録する歴史イベントをいずれかのイベントセットに登録することでグループ化し、図１３に示す「イベントセット編集」画面にて、イベントセット毎に「有効」又は「無効」を設定する。有効に設定されているイベントセットのみがゲーム中で利用可能な状態となる。

図７に戻り、次に、イベント制御部１４は、「ゲーム中に反映」ボタンが押されたか否かを判定する（ステップＳ４４）。プレイヤにより「ゲーム中に反映」ボタンが押された場合、イベント制御部１４は、有効に設定されたイベントセットに属する歴史イベントをゲーム中に反映させ（ステップＳ４６）、本処理を終了する。一方、プレイヤにより「ゲーム中に反映」ボタンが押されなかった場合、本処理はそのまま終了する。これにより、有効化した歴史イベントが、ゲーム中であってイベント条件を満足するタイミングに実行される。

例えば、ゲーム中に図１１（ｃ）に示す５つのイベント条件が満たされたとき、作成した特定の歴史イベントが開始される。このとき、ゲーム中の通常画面から図１４に一例を示す歴史イベントの画面が突如発生し、歴史イベントの内容に設定した通りの会話が始まる。さらに、図１５に示す歴史イベント中の画面では、図１５（ａ）に示すように、どのような歴史イベントが発生したのかのナレーションが表示される。次に、図１５（ｂ）において歴史イベント終了時の画像とナレーションを示した画面が表示され、最後に、図１５（ｃ）に示すように、設定されたイベント結果の画面が表示される。イベント画面を閉じると、ゲームの画面に切り替わり、ゲームが再開される。以上、歴史イベントの作成、歴史イベントの登録、歴史イベントの実行について説明した。

プレイヤが歴史イベントの作成時にゲームのストーリと矛盾を生じさせないすべてのイベント条件を手動で抽出し、設定することは困難である場合が多い。また、イベント条件の設定自体が煩雑であり、また、プレイヤが手動でイベント条件を設定すると、設定した条件に誤りや不足が生じる場合がある。

これに対して、本実施形態に係るイベント制御方法によれば、イベント結果に応じたイベント条件を自動で抽出し、設定することができる。これにより、プレイヤは、必須のイベント条件のすべてを手動で設定する必要がなくなり、歴史イベントの作成時の煩雑さを低減できる。また、ユーザが手動でイベント条件を設定する場合に、設定したイベント条件に誤りや不足が発生することを抑制できる。これにより、歴史イベントの作成の処理が簡素化され、プレイヤはより手軽に歴史イベントの作成を行うことができる。

また、作成した歴史イベントをゲーム中に実行させることにより、プレイヤは、自分が希望する歴史イベントの内容を鑑賞できる。また、実行したイベント結果により、歴史イベント中に得られる所定の値（レベルや友好度等）を、歴史イベント終了後にゲームのストーリに戻る際に引き継ぐことが可能となる。

例えば、ゲーム中のストーリの分岐点（所定の値により複数ある分岐ストーリのどれを進めるかが決定されるポイント）で望んでいないストーリへ進みそうな場合に、希望する所定の値を付与することができるような歴史イベントを作成してもよい。これにより、作成した歴史イベントを再生してからゲームのストーリへ戻ることで、複数ある分岐ストーリのうちの「希望するストーリ」へ進める、という事も可能となる。

このようにして、歴史イベント終了後にゲームのストーリに戻る際に、歴史イベントの内容及び結果を反映してゲームのストーリを変化又は終了させたり、キャラクタの能力値を変化させたり、家宝を与える等アイテムを増減させたりすることができる。

なお、本実施形態では、イベント条件の自動抽出はイベント結果が設定されたときに実行されたが、これに限らない。例えば、イベント結果及びイベント条件の少なくともいずれかの条件が設定された場合、イベント条件の自動抽出を実行する。これにより、必須のイベント条件を補完することができる。つまり、（１）プレイヤがイベント結果を設定したとき、設定したイベント結果に対応するイベント条件が自動抽出され得る。また、（２）プレイヤがイベント結果及びイベント条件を設定したとき、設定したイベント結果及びイベント条件に対応するイベント条件が自動抽出され得る。さらに、（３）プレイヤがイベント条件を設定したとき、設定したイベント条件に対応するイベント条件が自動抽出され得る。

また、イベント制御部１４が、イベント結果を複数設定している場合、ゲーム実行部１２は、先にゲーム中に反映したイベント結果によって後のイベント結果をゲーム中に反映しなくなる場合が生じ得る。例えば、ゲーム実行部１２は、「武将の死亡」により武将を死亡させた後、「武将の追放」で同じ武将を追放しようとした場合、すでにその武将は死亡しているため、「武将の追放」というイベント結果はゲーム中には反映されない。

また、歴史イベントでは、デファインによる条件指定が可能である。例えば、指定武将には、武将名を設定する方法以外に、知力が一番高い武将等、名前が決定していない武将名をメッセージ中に自動で呼び出すことができる。この場合、ゲーム進行状態によって、呼び出される武将が変わることになり、ゲーム中の意外性を高めることができる。

また、依頼イベント中に歴史イベントが発生し、その結果、依頼イベントのミッションが達成できなくなる場合、依頼イベントは消滅する。例えば、依頼イベント中に歴史イベントが実行され、その結果、依頼イベントの対象武将が死亡した場合、依頼イベントを継続して実行できないようになった場合には、その依頼イベントは消滅する。

［歴史イベント及び依頼イベントの共有］
次に、歴史イベント及び依頼イベント(以下、単に「イベント」ともいう。)の共有について説明する。作成および登録したイベントのデータは、他プレイヤと共有することができる。これにより、自作の歴史イベント又は依頼イベントを他プレイヤの端末装置にて他プレイヤにプレイしてもらうことや、他プレイヤが作成した歴史イベント又は依頼イベントを自プレイヤの端末装置にてプレイすることができる。

イベントを共有する場合、イベント制御部１４は、プレイヤの指示に応じて共有するイベントを選択する。図１６に示すように、複数の端末装置１０ａ〜１０ｃがネットワーク６０を介してサーバ５０と接続されており、端末装置１０ａ〜１０ｃ間でイベントを共有する。本実施形態では、イベントを共有する端末装置の一例として、３つの端末装置１０ａ〜１０ｃを示しているが、イベントを共有する端末装置の台数はこれに限られない。

サーバ５０は、通信部５１、制御部５２及び記憶部５３を有する。端末装置１０ａ〜１０ｃの少なくともいずれかは、共有してもよいと判断した自作のイベントをサーバ５０にアップロードし、通信部５１は、アップロードされたイベントのデータを受信する。

制御部５２は、受信したイベントのデータを記憶部５３に記憶する。共有可能なイベントは、共有リスト５４としてサーバ５０の記憶部５３に記憶される。共有リスト５４は、各イベントセットに属する各イベントの概要やイベント条件、ダウンロード数（ＤＬ数）の各項目が表示されている。各イベントの概要やイベント条件は、イベント作成時にイベント作成者により設定されているデータである。ダウンロード数は、イベントを作成したプレイヤの端末装置とは異なる他プレイヤの端末装置にそのイベントをダウンロードされた数である。

共有リスト５４の各項目は、端末装置１０ａ〜１０ｃに表示され、各プレイヤにより閲覧可能である。各プレイヤは、イベント作成時に設定された各イベントの概要やイベント条件を確認し、実行したいイベントを選択すると、選択されたイベントがサーバ５０から他プレイヤの端末装置にダウンロードされる。

なお、他プレイヤの端末装置にダウンロードされた数をカウントアップして、所定数のダウンロードが行われた場合、サーバ５０からそのイベントを作成したプレイヤの端末装置にトロフィーやクーポン等を提供するサービスを行ってもよい。

他プレイヤの端末装置にダウンロードされた数により、他プレイヤは、共有リスト５４に表示されている共有可能なイベントに対する他の端末装置による利用度を知ることができる。これにより、他プレイヤは、イベントの選択の際にイベントの人気度を考慮することができる。

各プレイヤの端末装置１０ａ〜１０ｃは、オリジナルの武将を作成し、その武将を登録した場合、イベントと同様に、自作の登録武将をサーバ５０にアップロードして、他プレイヤと共有することができる。

オリジナルの登録武将は、一プレイヤの端末装置にて作成されたオリジナルのオブジェクトの一例であり、オリジナルのオブジェクトはこれに限らない。各端末装置は、オリジナルのオブジェクトとして、オリジナルのキャラクタ、オリジナルのアイテム等を作成してもよい。作成したオリジナルのオブジェクトのデータを共有フォルダへ登録することで、イベントの登録と同様に、他の端末装置から利用可能な状態にすることができる。

その場合、他プレイヤの端末装置にて実行されるイベントに登場する指定武将に、共有されたオリジナルの登録武将を設定することで、他プレイヤの端末装置にて共有リスト５４に挙げられたイベントのいずれかを実行する際に、そのイベントに登場する武将をいずれかの端末装置で作成されたオリジナルの登録武将に動的に変更することができる。このようにして、一プレイヤの端末装置にて作成されたイベントとオリジナルのオブジェクトとを組み合わせて又は単体で他プレイヤの端末装置にて共有することができる。

［イベント共有処理］
最後に、イベント共有処理について、図１７を参照して説明する。図１７は、本実施形態に係るイベント共有処理の一例を示すフローチャートである。本処理は、サーバ５０により実行される。

本処理が開始されると、サーバ５０の通信部５１は、いずれかの端末装置からイベントのアップロードの要求があったか否かを判定する（ステップＳ５０）。イベントのアップロードの要求がなかった場合、ステップＳ５６に進む。

一方、イベントのアップロードの要求があった場合、通信部５１は、要求されたイベントのアップロードを受け付ける（ステップＳ５２）。制御部５２は、アップロードされたイベントを共有リスト５４に追加し、その一覧を表示する（ステップＳ５４）。

ステップＳ５６において、通信部５１は、いずれかの端末装置からイベントのダウンロードの要求があったか否かを判定する。イベントのダウンロードの要求がなかった場合、本処理を終了する。一方、イベントのダウンロードの要求があった場合、通信部５１は、要求されたイベントのダウンロードを行い（ステップＳ５８）、制御部５２は、ダウンロードを要求されたイベントのダウンロード数をカウントアップし、本処理を終了する。

以上に説明したように、本実施形態に係るイベント制御方法によれば、イベントの作成、イベントの登録、イベントの実行、及びイベントのデータを他プレイヤと共有することができる。これにより、一のプレイヤの端末装置にて作成したイベントを、他プレイヤの端末装置にて実行でき、イベント実行の結果を他プレイヤの端末装置において実行されているゲームに反映することができる。また、他プレイヤの端末装置にて作成したイベントを、自プレイヤの端末装置にて実行でき、イベント実行の結果を自プレイヤの端末装置において実行されているゲームに反映することができる。

なお、各端末装置は、イベントを他の端末装置にて共有する場合の共有条件を設定することができる。これによれば、共有条件を満たす場合のみ他の端末装置にて共有リスト５４に挙げられたイベントをダウンロードすることができる。これにより、イベントの共有に所定の制限（フィルタリング）を設けることができる。

以上、イベント制御方法及びイベント制御プログラムを上記実施形態により説明したが、本発明に係るイベント制御方法及びイベント制御プログラムは上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。

例えば、上記実施形態に係るイベント制御方法では、歴史シミュレーションゲームに適用される歴史イベントを例に挙げたが、本発明に係るイベント制御方法が適用されるゲームはこれに限らない。例えば、マス目タイプのシミュレーションＲＰＧゲームにも適用可能である。この場合、隣接マスにＡキャラクタとＢキャラクタとがいるときに、そこで発生する会話イベントやその他のイベントをプレイヤが設定する場合にも、本発明に係るイベント制御方法を用いて、イベントの作成、イベントの登録、イベントの実行、及びイベントのデータを他プレイヤと共有することができる。

４ イベント編集部
５ イベント登録部
６ イベント実行部
１０ 端末装置
１１ 受付部
１２ ゲーム実行部
１３ 記憶部
１４ イベント制御部
１６ グラフィック処理部
１７ サウンド処理部
１８ 表示部
１９ 音出力部
２０ 通信部
２１ ＣＰＵ
２２ ＲＯＭ
２３ ＲＡＭ
２４ ＨＤＤ
２５ グラフィックカード
２６ 外部Ｉ／Ｆ
２６ａ 記録媒体
２７ 通信Ｉ／Ｆ
２８ 入力Ｉ／Ｆ
２８ａ メモリカード
２９ ディスプレイ
３０ スピーカ
４０ コントローラ
５０ サーバ
５１ 通信部
５２ 制御部
５３ 記憶部
５４ 共有リスト
１３１ イベント結果ＤＢ
１３２ イベント条件ＤＢ
１３３ テーブル
１３４ イベント登録ＤＢ
１３５ ゲーム実行処理プログラム
１３６ イベント制御処理プログラム

Claims (6)

1. ゲーム中に実行されるイベントを作成する際の制御処理をコンピュータが実行するイベント制御方法であって、
   イベント条件及びイベント結果の少なくともいずれかの設定条件を受け付け、
   受け付けた前記設定条件に応じて前記イベントを実行するために補完すべき条件を抽出し、
   前記補完すべき条件を含むイベント条件が設定されたイベントのデータを、イベントを作成した端末装置と異なる他の端末装置から利用可能な状態にする、
   イベント制御方法。
2. 他の端末装置から利用可能な状態にした前記イベントの一覧を前記他の端末装置から閲覧可能なように表示する、
   請求項１に記載のイベント制御方法。
3. 前記イベントを作成する際に設定した前記イベントの概要を前記イベントの一覧に表示する、
   請求項１又は２に記載のイベント制御方法。
4. 利用可能な状態にした前記イベントに対する前記他の端末装置による利用度を前記イベントの一覧に表示する、
   請求項１〜３のいずれか一項に記載のイベント制御方法。
5. オリジナルのオブジェクトを作成した際、作成した前記オリジナルのオブジェクトのデータを、他の端末装置から利用可能な状態にし、
   前記オリジナルのオブジェクトのデータを使用して前記他の端末装置にて前記イベントを実行させる、
   請求項１〜４のいずれか一項に記載のイベント制御方法。
6. ゲーム中に実行されるイベントを作成する際の制御処理をコンピュータに実行させるためのイベント制御プログラムであって、
   イベント条件及びイベント結果の少なくともいずれかの設定条件を受け付け、
   受け付けた前記設定条件に応じて前記イベントを実行するために補完すべき条件を抽出し、
   前記補完すべき条件を含むイベント条件が設定されたイベントのデータを、イベントを作成した端末装置と異なる他の端末装置から利用可能な状態にする、
   イベント制御プログラム。

Images