JP7161786B2 - ゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラム - Google Patents

Description

本発明は、ゲームを管理するゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムに関するものである。

従来から、ゲームの進行中に、予め定められている様々なイベントが発生するゲームが提案されている（例えば、特許文献１）。ユーザは、ゲーム中に発生するイベントを楽しみながら、ゲームを進行させる。

特開２００４－３３４８８号公報

通常、ゲーム中に発生するイベントとしては、複数の様々なイベントが予め用意されている。しかしながら、ゲーム中に発生するイベントは固定化されているため、ユーザが何度もゲームを遊戯するうちに、同じイベントの発生が繰り替えされ、ゲームに飽きてしまうこともある。

本発明は、上記の事情に鑑みてなされたものであり、その目的は、ユーザが飽きずに繰り返し遊戯できる興趣性の高いゲームを提供することである。

１）本発明の一局面によるゲーム管理装置（3,201,203）は、ユーザが所有する複数のキャラクタの中からユーザによって選択された少なくとも１つのキャラクタを、イベント発生用の第１キャラクタとして設定する設定手段（71）と、前記第１キャラクタまたは複数の前記第１キャラクタの組み合わせに応じて、ゲーム中に前記第１キャラクタに関連するイベントを発生させるイベント管理手段（72）と、を備えている。

この構成のゲーム管理装置は、例えばゲーム装置としてのコンピュータ（ゲーム専用機、パーソナルコンピュータ、スマートフォン等）により構成することができる。あるいは、本ゲーム管理装置は、各ユーザのゲーム端末と通信を行うことができるサーバなどのコンピュータにより構成することができる。あるいは、本ゲーム管理装置は、相互に通信する複数のコンピュータ（サーバ、ゲーム端末）により構成することもできる。

本ゲーム管理装置が管理するゲームでは、ユーザは、複数のキャラクタを所有することができる。ここでキャラクタには、例えば人物、動物、植物、架空の生物（モンスター等）、非生物（材料、道具等）など、ゲームの内容によって様々なものを適用できる。また、キャラクタは、ゲーム内で、２
次元または３次元の画像、カード形式の画像など、様々な表示形態のものを適用できる。

また、本ゲーム管理装置が管理するゲームでは、ユーザは、自分が所有する複数のキャラクタの中から少なくとも１つのキャラクタを選択して、イベント発生用のキャラクタとして設定することができる。ユーザによって選択された少なくとも１つのキャラクタは、設定手段によって「イベント発生用の第１キャラクタ」として設定される。

そして、イベント発生用として設定された第１キャラクタまたは複数の第１キャラクタの組み合わせに応じて、イベント管理手段が、ゲーム中に第１キャラクタに関連するイベントを発生させる。ここで、第１キャラクタに関連するイベントとしては、例えばスポーツを題材にしたゲームでは、第１キャラクタが練習したり、ライバルと対決したりするイベントが考えられる。その他にも、第１キャラクタがユーザの分身的なキャラクタ（マイキャラクタ）と一緒に行動する（例えば、練習する、食事する、旅行する）等であってもよい。なお、第１キャラクタに関連するイベントは、第１キャラクタが画面に登場するイベントに限定されない。例えば、第１キャラクタに関連するクイズが出題されるイベントであってもよい。その他にも、第１キャラクタと関係のある他のキャラクタ（友達、先輩、後輩、コーチ、ライバル等）が第１キャラクタのことを語るイベントであったり、第１キャラクタのライバルが第１キャラクタに勝つために練習するイベントであったりしてもよい。

なお、第１キャラクタまたは複数の第１キャラクタがイベント発生用として設定された場合、必ずイベントが発生するようにしてもよいし、所定の確率でイベントが発生するようにしてもよいし、所定の条件を満たした場合にイベントが発生するようにしてもよい。

また、第１キャラクタに関連するイベントは、第１キャラクタのパラメータ（特徴的パラメータ）に関連するイベントとすることができる。例えば、第１キャラクタが、特定の能力の優れた（特定の能力のパラメータが所定の基準よりも高い）キャラクタであった場合には、当該第１キャラクタに関連するイベントは、その特定の能力に関連する（特定の能力を活用した）イベントとする。具体例としては、第１キャラクタが打撃能力の優れた（打撃能力のパラメータが所定の基準よりも高い）選手であった場合に、当該第１キャラクタに関連するイベントは、打撃に関するイベント、例えば打撃特訓、ホームラン競争等のイベントとすることができる。

また、第１キャラクタに関連するイベントは、第１キャラクタと後述する第２キャラクタ（ユーザのマイキャラクタ等）との関係に関連するイベントとすることができる。例えば、第１キャラクタと第２キャラクタとが、ゲーム上、ライバル関係であった場合には、当該第１キャラクタに関連するイベントは、両キャラクタの対決シーンのイベントとする。

特に、複数の第１キャラクタを組み合わせることで、その組み合わせに応じたイベントが発生するので、イベントのバリエーションが非常に多くなる。すなわち、ユーザが所有するｎ個のキャラクタからｒ個のキャラクタを選択して組み合わせる場合、組み合わせの数は、ｎ！／｛（ｎ－ｒ）！ｒ！｝で表される。例えば、ユーザが所有する１０個のキャラクタから３個のキャラクタを選択して第１キャラクタとして設定する場合、１２０通りの組み合わせがあり、ユーザは、第１キャラクタとして設定するキャラクタの組み合わせを変えれば、組合せに応じた様々なイベントの発生が期待できる。

また、複数の第１キャラクタを組合せる場合は、複数の第１キャラクタ間の関係に応じたイベントが発生し得るようにしてもよい。あるいは、複数の第１キャラクタに第２キャラクタを含めた複数のキャラクタ間の関係に応じたイベントが発生し得るようにしてもよい。以下にその一例を示す。

例１：キャラクタＡおよびＢが、ゲーム上、ライバル同士の関係である場合に、両キャラクタＡおよびＢをイベント発生用の第１キャラクタとして設定することで、対決シーンのイベントが発生する（かもしれない）ことを期待できる（あるいは、ユーザが発生し得るイベントを想像する）。

例２：キャラクタＰ、Ｑ、Ｒが、ゲーム上、同じ学校の同級生の関係である場合には、これら３体のキャラクタＰ、Ｑ、Ｒをイベント発生用の第１キャラクタとして設定することで、３人で旅行に行くというイベントが発生する（かもしれない）ことを期待できる。さらに、キャラクタＰ、Ｑ、Ｒと第２キャラクタとが同じ学校の同級生の関係である場合には、これら３体のキャラクタＰ、Ｑ、Ｒをイベント発生用の第１キャラクタとして設定することで、第２キャラクタを含めた４人で旅行に行くというイベントが発生する（かもしれない）ことを期待できる。

イベントは必ず発生するとは限らないが、ユーザが各第１キャラクタについてのパラメータ、特徴、他の第１キャラクタとの関係、第２キャラクタとの関係等を知っていれば、イベント発生用として設定した第１キャラクタまたは複数の第１キャラクタの組み合わせによって、発生し得るイベントを想像する、あるいは期待するという楽しみも生まれる。

また、イベント発生の効果についても任意に定めることができる。例えば、イベントが発生した場合、そのイベントの進行または結果に応じて、ユーザのマイキャラクタのパラメータが変動するようにしてもよいし、ユーザにアイテム等が付与されるようにしてもよい。あるいは、パラメータの変動等の効果を生じることなく、単にユーザが発生したイベントを楽しむだけにしてもよい。

以上のように、本構成では、ユーザはイベント発生用のキャラクタを集め、集めたキャラクタを任意に選択してイベント発生用の第１キャラクタとして設定することにより、第１キャラクタまたは複数の第１キャラクタの組み合わせに応じた様々なイベントが、ゲーム中に発生し得る。よって、ユーザは、イベント発生用として設定する第１キャラクタまたはその組合せによるイベントのバリエーションを楽しむことができる。例えば、ゲームに飽きてきたユーザは、イベント発生用として設定する第１キャラクタを変えることにより、ゲーム中に発生するイベントも変化するので、飽きの来ないゲームプレイが可能となる。すなわち、本ゲーム管理装置では、ユーザが任意に設定できる第１キャラクタまたは複数の第１キャラクタの組み合わせによって、ゲーム中に発生するイベントのバリエーションが豊富になる。これにより、遊戯の幅が広がり、ユーザが継続的に繰り返し飽きずに遊戯できる興趣性の高いゲームを実現できる。

２）上記の構成において、前記イベント管理手段（72）は、前記第１キャラクタまたは複数の前記第１キャラクタの組み合わせに応じた前記イベントを、前記ゲーム中に所定の確率で発生させることが好ましい。

ここで、イベントを発生させる確率は、全てのイベントについて同一の確率としてもよいし、イベントの内容、種類、効果等に応じて、例えば１０％、３０％、５０％、７０％等、異ならせてもよい。また、後述する４）の構成のように、ユーザのゲーム操作によって、ゲーム中にイベントの発生確率が変動するようにしてもよい。

本構成では、イベント発生用の第１キャラクタが設定されたからといって、当該第１キャラクタに関連するイベントが、必ずしも１００％発生するとは限らず、イベントが発生するか否かは確率に基づいている。よって、イベントがどのタイミングで発生するかも分からない。従って、イベント発生用として第１キャラクタが設定された後、ユーザは、第１キャラクタに関連するイベントが発生することを期待しながら、緊張感を持ってゲームを遊戯することになる。本構成により、ゲーム性の向上が図られる。

３）上記の２）の構成において、前記ゲーム中にユーザによって操作される第２キャラクタと前記第１キャラクタとの関係度を管理する関係度管理手段（73）と、前記関係度に応じて、前記確率を変動させる確率変動手段（74）と、をさらに備えていることが好ましい。

ここで、ゲーム中にユーザによって操作される第２キャラクタとは、いわゆるプレイヤキャラクタであり、例えば、ユーザの分身的なマイキャラクタとすることができる。また、第１キャラクタと第２キャラクタとの関係については、例えばチームメイト、選手と監督、選手とマネージャ、先輩と後輩、ライバル同士、恋人同士、上司と部下、親子、兄弟等、様々な関係が適用できる。そして、第１キャラクタと第２キャラクタとの関係度としては、例えば、両者の親密度としてもよいし、一方が他方を評価する評価値としてもよい。

また、第１キャラクタと第２キャラクタとの関係度は、予め初期値が定められているものとしてもよい。一例を挙げると、第１キャラクタＡと第２キャラクタとはゲーム内で親友という設定であり、両者の関係度を「１００」とする。一方、第１キャラクタＢと第２キャラクタとはゲーム内で知り合い程度の設定であり、両者の関係度を「１０」とする。また、その関係度は、後述する５）の構成のように、ユーザによって操作される第２キャラクタの行動によって、ゲーム中に変動するものとしてもよい。

この構成によれば、第１キャラクタと第２キャラクタとの関係度によって、当該第１キャラクタに関連するイベントの発生確率（または、当該第１キャラクタを組み合わせに含む場合における、その組み合わせに応じたイベントの発生確率）が変動する。例えば、関係度（前記親密度、前記評価値等）が大きいほど、イベントの発生確率が向上する。

一例を挙げると、第１キャラクタと第２キャラクタとの関係度が「３９以下」、「４０～７９」、「８０～１１９」、「１２０～１５９」、「１６０～１９９」、「２００（最大）」の場合、イベントの発生確率がそれぞれ「１０％」、「２０％」、「３０％」、「５０％」、「７０％」、「１００％」と変動する。第１キャラクタが単独の場合、上記の例のイベント発生確率をそのまま適用できる。一方、イベント発生用として設定された第１キャラクタが複数の場合、複数の第１キャラクタの組合せに応じたイベントの発生確率の決定には様々な態様が考えられる。以下にその一例を示す。

複数の第１キャラクタ（Ａ、Ｂ…）の組み合わせに応じたイベントの発生確率については、全ての第１キャラクタ（Ａ、Ｂ…）と第２キャラクタとの関係度が、所定の基準（条件）を満足した場合に、満足した関係度の基準に応じた確率が適用される。例えば、設定された複数の第１キャラクタの全てが、所定の関係度の基準（例えば「４０以上」）を満足するまではイベントの発生確率が「１０％」であり、当該基準を満足したときに、イベントの発生確率が「２０％」となる。また、複数の第１キャラクタの全てが、さらにその上の関係度の基準（例えば「８０以上」）を満足したときに、イベントの発生確率が「３０％」となる。以下同様に、複数の第１キャラクタの全てが、さらに上の関係度の基準を満足する毎に、イベントの発生確率が向上する。

あるいは、複数の第１キャラクタの組合せに応じたイベントの発生確率については、当該複数の第１キャラクタの中で最も高い関係度のものを採用して、決定してもよい。あるいは、逆に、最も低い関係度のものを採用してもよく、この場合は、ユーザは関係度の底上げを図ることを動機付けられる。

あるいは、複数の第１キャラクタの組合せに応じたイベントの発生確率については、当該複数の第１キャラクタの関係度の平均を算出し、関係度の平均に基づいて決定してもよい。

ところで、各々の第１キャラクタと第２キャラクタとの関係度は、ユーザが画面上で視認可能とすることが好ましい。これにより、ユーザは、イベント発生用として第１キャラクタを設定する場合、あるいはゲーム進行の途中で、第１キャラクタの第２キャラクタとの関係度を画面上で確認し、関係度を認識しながら遊戯を楽しむことができる。例えば、ユーザが、ある第１キャラクタについての関係度が高いことを画面上で確認した場合、その第１キャラクタに関するイベントが高い確率で発生するという期待感が高まる。

本構成により、イベント発生用として設定する第１キャラクタと第２キャラクタとの関係度により、あるいは第１キャラクタが設定された後の第２キャラクタとの関係度により、イベントの発生のし易さが変わる。よって、ユーザは、イベントを早く発生させたいと考える場合には、自分が設定した第１キャラクタと自分の操作キャラクタである第２キャラクタとの関係度が大きくなるように遊戯すればよいので、よりゲーム性を高めることができる。

４）上記の３）の構成において、前記第１キャラクタを前記ゲーム内に登場させる登場キャラクタ管理手段（75）をさらに備え、前記関係度管理手段（73）は、ユーザの操作によって前記第２キャラクタが前記第１キャラクタと所定の行動を行う毎に、当該第１キャラクタと当該第２キャラクタとの前記関係度を変動させることが好ましい。

ここで、「所定の行動」とは、例えば、第２キャラクタが第１キャラクタと一緒に練習する、対決する、食事する、遊ぶ、あるいは同じ場所に共に一緒にいる等、様々なゲーム内の行動を言う。本構成では、ユーザがイベント発生用として設定した第１キャラクタがゲーム内に登場する。そして、ユーザが操作する第２キャラクタが、第１キャラクタとゲーム内で練習等の所定の行動を行えば、両者の関係度（前記親密度、前記評価値等）が向上し、当該第１キャラクタに関連するイベント（または、当該第１キャラクタを組み合わせに含む場合におけるその組み合わせに応じたイベント）の発生確率が高くなる。

なお、イベント発生用として第１キャラクタが設定されたことにより、第２キャラクタが第１キャラクタと所定の行動を行わなくとも、前述のように所定の確率で、第１キャラクタに関連するイベントが発生する可能性はある。その上で、本構成では、ユーザの操作によって、第２キャラクタが第１キャラクタと所定の行動を行うようにすることで、意図的にイベント発生の確率を向上できるのである。

よって、ユーザは、特定の第１キャラクタに関連するイベントを高い確率で発生させたい場合、第２キャラクタが第１キャラクタと所定の行動を行うように、ゲーム操作（ゲーム内の第２キャラクタの行動を選択する操作等）を行えばよい。本構成により、ユーザは、自分の操作によって、特定の第１キャラクタに関連するイベントの発生確率を変動させることができるので、ゲーム性がより向上する。

５）上記の１）の構成において、前記第１キャラクタを前記ゲーム内に登場させる登場キャラクタ管理手段（75）と、ユーザの操作によって前記第２キャラクタが前記第１キャラクタと所定の行動を行う毎に、当該第１キャラクタと当該第２キャラクタとの関係度を変動させる関係度管理手段（73）と、をさらに備え、前記イベント管理手段（72）は、前記第１キャラクタと前記第２キャラクタとの前記関係度が所定の基準に達した場合に、当該第１キャラクタに関連する前記イベントを発生させることが好ましい。

本構成では、ユーザがイベント発生用として設定した第１キャラクタがゲーム内に登場する。そして、ユーザが操作する第２キャラクタが、第１キャラクタとゲーム内で所定の行動（一緒に練習する等）を行えば、両者の関係度（前記親密度、前記評価値等）が変動する。そして、ある第１キャラクタとの関係度が所定の基準に達した後に、その第１キャラクタに関連するイベントが発生（１００％発生）する。ここで、イベント発生のタイミングについては、関係度が所定の基準に達した直後にイベントが発生するものとしてもよいし、関係度が所定の基準に達した後、ある程度の時間をおいてから（例えばゲーム上のイベント発生タイミングの調整が入ってから）イベントが発生するものとしてもよい。ゲーム上のイベント発生タイミングの調整が入る一例としては、次のような場合が考えられる。すなわち、複数のターンで仕切られてゲームが進行するゲームにおいて、あるターンのコマンド実行中に、第１キャラクタと第２キャラクタとの関係度が所定の基準に達した場合、次のターンの開始時まで待って、当該第１キャラクタに関するイベントが発生するようにする。

なお、関係度が所定の基準に達していない場合については、任意に定めることができる。例えば、第１キャラクタと第２キャラクタとの関係度が所定の基準に達していない場合、関係度に応じた確率で（あるいは関係度に依らず所定の確率で）、当該第１キャラクタに関連するイベントが発生するようにしてもよい。あるいは、第１キャラクタと第２キャラクタとの関係度が所定の基準に達していない場合、当該第１キャラクタに関連するイベントが発生しないようにしてもよい。

ここで、イベント発生用として設定された第１キャラクタが１つの場合、当然ながら当該第１キャラクタと第２キャラクタとの関係度が所定の基準に達した場合に（それを契機として）、イベントが発生する。

一方、イベント発生用として設定された第１キャラクタが複数の場合、様々な態様が考えられる。複数の第１キャラクタ（Ａ、Ｂ…）の組み合わせに応じたイベントは、全ての第１キャラクタ（Ａ、Ｂ…）と第２キャラクタとの関係度が所定の基準に達した場合に、当該イベントが発生するようにすることができる。あるいは、複数の第１キャラクタ（Ａ、Ｂ…）の組み合わせに応じたイベントは、その中の何れか１つの第１キャラクタと第２キャラクタとの関係度が所定の基準に達した場合に、当該イベントが発生するようにしてもよい。あるいは、複数の第１キャラクタ（Ａ、Ｂ…）の組み合わせに応じたイベントは、その中の所定割合以上（例えば５０％以上）の第１キャラクタと第２キャラクタとの関係度が所定の基準に達した場合に、当該イベントが発生するようにしてもよい。

本構成では、ユーザは、特定の第１キャラクタに関連するイベントを確実に発生させたい場合、当該第１キャラクタとの関係度が所定の基準に達するように、ゲーム操作（ゲーム内の第２キャラクタの行動を選択する操作等）を行えばよい。本構成により、ユーザは、自分の操作によって、特定の第１キャラクタに関連するイベントを１００％発生させることができるので、ゲーム性がより向上する。

６）上記の１）ないし５）の何れかの構成において、前記第１キャラクタの設定可能数に上限を設けると共に、所定の条件を満足することによって、前記設定可能数の上限を変動させる設定可能数管理手段（76）をさらに備えていることが好ましい。

この構成によれば、イベント発生用として設定できる第１キャラクタの設定可能数には上限が設けられる。例えば、ゲーム開始時には、設定可能数の上限は「２」である。但し、設定可能数の上限は、所定の条件を満足することによって変動する。ここで、所定の条件の例としては、以下のようなものがある。

（ａ）後述する７）の構成のように、ゲームの進行度に関係するゲームパラメータが予め設定された条件を満足することを所定の条件とする。

（ｂ）設定可能数の上限を大きくするために、ユーザが所定量のゲーム内ポイント、ゲーム内通貨、課金アイテム等を消費することを所定の条件とする。

（ｃ）他のユーザと所定の関係、例えば仲間の関係を構築できるゲームでは、仲間数が所定人数に達することを所定の条件とする。

（ｄ）ゲームの実行結果が所定の基準に達しない場合を所定の条件とする。例えば、キャラクタを育成することができるゲームにおいて、ユーザがキャラクタの育成を途中で止めてしまった場合に、設定可能数の上限を低下させるようにする。

なお、上記の（ａ）～（ｄ）は所定の条件一例であって、これらに限定されるものではなく、ゲームの内容に応じて様々な条件を定めることができる。

本構成では、第１キャラクタの設定可能数に上限を設ける一方で、ユーザが所定の条件を満たすことによりその上限を大きくすることができるようにしている。第１キャラクタの設定可能数の上限が大きくなるほど、ゲーム中に発生可能となるイベントのバリエーションも多くなる。よって、ユーザは、設定可能数の上限を向上させるべく（または上限の低下を回避すべく）、所定の条件を満足するようにゲームを積極的に遊戯するように動機付けられる。

７）上記の６）の構成において、前記所定の条件を満足するとは、前記ゲームの進行度に関係するゲームパラメータが予め設定された条件を満足することであることが好ましい。

ここで、ゲームの進行度に関係するゲームパラメータの一例としては、複数のキャラクタを育成することができるゲームでは、育成を完了したキャラクタ数が挙げられる。この場合、育成を完了したキャラクタ数が所定値（例えば１、５、１０等）に達することで所定の条件を満たすものとする。ゲームの進行度に関係するゲームパラメータの他の例としては、ステージ、ポイント、レベル等、ゲーム内容に応じた様々なゲームパラメータを適用できる。例えば、所定ステージに到達したこと、獲得ポイントが所定値に到達したこと、ユーザのゲームレベルが所定レベルに到達したこと、ユーザのマイキャラクタのレベルが所定レベルに達したこと等が、「ゲームの進行度に関係するゲームパラメータが予め設定された条件を満足すること」に該当する。

本構成では、ユーザは、ゲームの進行度に関係するゲームパラメータが予め設定された条件を満足するように、ゲームを積極的に遊戯するように動機付けられる。

８）上記の１）ないし７）の何れかの構成において、前記イベントと、当該イベントを発生させるための前記第１キャラクタまたは複数の前記第１キャラクタの組み合わせと、の関係を示す情報を、ユーザに報知する報知手段（80）をさらに備えていることが好ましい。ここで、報知手段による報知例を以下に示す。

（Ａ）イベントにより生じるパラメータ向上等の効果と、当該イベントを発生させるための第１キャラクタまたは複数の前記第１キャラクタの組み合わせと、の関係を示す情報を、ユーザに事前に報知（提示）する。例えば、イベントの効果としてユーザのマイキャラクタのパラメータが変動する場合、パラメータの向上を図るために必要な第１キャラクタまたは第１キャラクタの組合せに関する情報を、ユーザに事前に報知する。野球ゲームを例示すると、「打撃力を強化するイベントを発生させるためには、（打撃力の高い）キャラクタＰ、Ｑ、Ｒ・・・のいずれかのキャラクタを設定すればよい」旨を、ユーザに報知する。

（Ｂ）イベントの種類または内容と、当該イベントを発生させるための第１キャラクタまたは複数の前記第１キャラクタの組み合わせと、の関係を示す情報を、ユーザに事前に報知する。ここでイベントの種類または内容の例としては、合同練習イベント、対決イベント、旅行イベント、食事イベント等がある。これらは一例であり、イベントの種類または内容は、ゲーム内容によって様々である。例えば、「対決イベントを発生させるためには、（ユーザのマイキャラクタとライバルである）キャラクタＸを設定すればよい」旨を、ユーザに報知する。

上記の（Ａ）および（Ｂ）の何れの場合も、ユーザに対して全ての関係を示す詳細なテーブル情報等を提示してもよいし、その一部のみをランダムに提示してユーザの興味を引くようにしてもよい。この情報の提示がある場合、ユーザは所望のイベントを発生させよう（それによって、所望の効果を発生させよう）として、それに必要なキャラクタを入手しようと動機づけられる。

また、上記の（Ａ）および（Ｂ）の何れの場合も、前記関係を示す情報として、ユーザの所有するキャラクタに関する情報のみを抽出してユーザに提示してもよい。この場合、ユーザ（特に、自分が所有するキャラクタをイベント発生用として設定すればどのようなイベントが発生するのかをあまり知らない初心者ユーザ）に、ゲームを積極的に楽しむ動機付けを与えることができる。

９）上記の１）ないし８）の何れかの構成において、前記ゲーム中に発生した前記イベントの進行または結果に応じて、前記第２キャラクタのパラメータを変動させるパラメータ変動手段（79）をさらに備えていることが好ましい。

この構成によれば、ゲーム中に発生したイベントの進行または結果に応じて、第２キャラクタのパラメータが変動するという効果が生じる。例えば、野球ゲームの場合、第２キャラクタの打力、走力、守備力等の特定のパラメータが向上したり、特殊能力のパラメータを獲得したりする。一例を挙げると、第１キャラクタＡに関連するイベントの結果により、第２キャラクタの打力が所定量（または所定割合）向上する。また、第１キャラクタＢに関連するイベントの結果により、第２キャラクタの走力が所定量（または所定割合）向上する。なお、発生したイベントを最後まで完了させない場合、あるいはイベントをクリアしない場合であっても、イベントの進行度に応じてパラメータを変動させることも可能である。

本構成では、各イベントの効果として、第２キャラクタ（ユーザのマイキャラクタ等）のパラメータが変動する。そして、発生するイベントに応じて、パラメータの変動効果も変わる。よって、ユーザは設定する第１キャラクタの組合せを工夫することにより、様々なイベントを発生させて、第２キャラクタの能力等パラメータの強化を図ることができる。本構成によりゲーム性をより向上させることができる。

１０）上記の９）の構成において、前記第２キャラクタのパラメータの変動の内容は、前記第１キャラクタのパラメータに関連するものであることが好ましい。

例えば、第１キャラクタが打撃能力の優れた（打撃能力のパラメータが所定の基準よりも高い）選手であった場合に、当該第１キャラクタに関連するイベントが進行または完了すると、第２キャラクタは、その第１キャラクタの特定のパラメータ（この場合、打撃能力）の影響を受けて、それと同じ打撃能力が向上する。本構成により、ユーザは、イベント発生用として設定する第１キャラクタのパラメータを考慮しながら組合せを工夫することにより、様々なイベントを発生させて、第２キャラクタのパラメータを万遍なく向上させたり、特定のパラメータの強化を図ったりすることができる。本構成によりゲーム性をより向上させることができる。

１１）上記の９）または１０）の構成において、ユーザが所有する前記複数のキャラクタのそれぞれには希少度が設定されており、前記パラメータ変動手段（79）は、イベント発生用として設定された前記第１キャラクタの前記希少度が高いほど、当該第１キャラクタに応じて発生した前記イベントの進行または結果に応じて、前記第２キャラクタのパラメータを大きく変動させることが好ましい。

この構成によれば、各キャラクタには予め希少度が設定されている。希少度は、「１、２…」、「Ａ、Ｂ…」、「金、銀…」、「ノーマル、レア…」等、様々な態様で表すことができる。例えば、複数段階の希少度「ノーマル」、「レア」、「Ｓレア」のうちの何れか１つの希少度が、各キャラクタ設定されている。この例の場合、同じキャラクタＡでも、ノーマル、レア、Ｓレアの３種類の希少度のものが存在する。

そして、イベント発生用として設定された第１キャラクタの希少度が高いほど、第１キャラクタに応じて発生したイベントの効果が高くなる。すなわち、イベント発生用として第１キャラクタが設定されたことによって、第１キャラクタに応じたイベントが発生した場合、第１キャラクタの希少度が高いほど、そのイベントの進行または結果に応じて、第２キャラクタのパラメータが大きく変動する。例えば、第１キャラクタの希少度が高いほど、第２キャラクタの能力パラメータがより大きくなる。

本構成により、イベント発生用として設定される第１キャラクタの希少度が高いほど、ゲームを有利に進めることができるようになり、ゲーム性が高まる。そして、ユーザに対して、より希少度の高いキャラクタを入手しようとする動機付けを与えることができる。

１２）上記の１）ないし１１）の何れかの構成において、複数の前記第１キャラクタの組み合わせに応じて発生する前記イベントは、当該複数の前記第１キャラクタ間の関係に基づいたイベントであることが好ましい。

ここで、複数の第１キャラクタ間の関係とは、例えば、ライバル、親友、親子、恋人等、ゲームの内容に応じた様々な関係が適用できる。例えば、キャラクタＡとキャラクタＢとはライバルの関係であったとする。そして、イベント発生用としてキャラクタＡおよびキャラクタＢが設定された場合、両キャラクタの組み合わせに応じたイベントとして、両キャラクタの関係（ライバル）に基づいて、対決イベントが発生する。この場合、前記第２キャラクタ（ユーザのマイキャラクタ等）が対決イベントを見届けたり、応援したりする等により、イベントに参加するようにしてもよい。

このように、本構成では、イベント発生用として設定された複数の第１キャラクタ間の関係に基づいた内容のイベントが発生する。よって、ユーザは、対決イベント等の特定の内容のイベントを発生させたい場合、キャラクタ間の関係を考えながら、イベント発生用の複数のキャラクタを選択すればよい。本構成により、ゲーム性のさらなる向上が図られる。

１３）上記の１）ないし１２）の何れかの構成において、ユーザに関係付けられた第２ユーザを管理する関係管理手段（77）と、前記第２ユーザが所有する特定のキャラクタを、ユーザ自身のイベント発生用の前記第１キャラクタとして設定することを許可する許可手段（78）と、をさらに備えていることが好ましい。

本ゲーム管理装置は、ユーザに関係付けられた仲間などの第２ユーザを管理する関係管理手段を備えている。ここで、仲間とは、ゲーム内で構築されるユーザ同士の仮想的な関係の総称であり、知人、友人、友達、クラスメイト、相棒、親類、家族、兄弟、姉妹、会社や組織の同僚などの様々なゲーム内の関係を含む。なお、ユーザと関連付けがなされている他のユーザ（第２ユーザ）であれば、仲間という関係でなくてもよい。ただし、以下の説明では、第２ユーザを、便宜上、仲間と称して説明する。

本構成では、ユーザの仲間（第２ユーザ）が所有する特定のキャラクタを、ユーザ自身のイベント発生用の第１キャラクタとして設定することができる。すなわち、イベント発生用のキャラクタの設定枠として、仲間のキャラクタを設定できる枠があり、ユーザは、自分の仲間のキャラクタを借りて、イベント発生用のキャラクタとして設定できるのである。ここで、「仲間が所有する特定のキャラクタ」の例としては、仲間がイベント発生用として設定しているキャラクタの１つとしたり、仲間が貸し出し可能なキャラクタとして予め選択しているキャラクタとしたりできる。あるいは、仲間が所有しているキャラクタの中で最も能力の高いキャラクタが、特定のキャラクタとしてゲーム管理装置によって自動的に選択されるようにしてもよい。

ユーザにとって、仲間のキャラクタを設定できる枠は、１つだけとしてもよいし、複数であってもよい。例えば、仲間の数に応じて、仲間のキャラクタを設定できる枠の上限を変動させてもよい。すなわち、仲間が多いほど前記枠の上限を大きくしてもよい。

以上のように、本構成では、ユーザは、自らが所有していないキャラクタであっても、仲間が所有する特定のキャラクタを借りて、ユーザ自身のイベント発生用のキャラクタとして設定できる。この場合、ユーザにとっては、仲間が多いほど、選択可能なキャラクタの幅が広がるので、様々なイベントの発生が可能となる。本構成により、各ユーザは、積極的に多くの仲間を作ろうとする動機付けを与えられることになる。そして、各ユーザの仲間が増えることにより、ユーザ間のコミュニティが活性化し、延いてはゲーム全体の活性化が図られる。

１４）上記の１）ないし１３）の何れかの構成において、ユーザが所有する前記複数のキャラクタのそれぞれには希少度が設定されており、イベント発生用として設定された前記第１キャラクタの前記希少度が高いほど、前記ゲーム中に発生する可能性のある前記イベントの数を多くすることが好ましい。

この構成によれば、各キャラクタには予め希少度が設定されている。例えば、「ノーマル」、「レア」、「Ｓレア（最高）」のうちの何れか１つの希少度が、各キャラクタ設定されている。そして、イベント発生用として設定された第１キャラクタの希少度に応じて、ゲーム中に発生する可能性のあるイベントの数が異なる。

ここでは、イベント発生用として設定された第１キャラクタが１つの場合を例に挙げて説明する。第１キャラクタの希少度が「ノーマル（最低）」の場合、発生する可能性のあるイベントの数を、例えば「１」とする。また、第１キャラクタの希少度が「レア」の場合、発生する可能性のあるイベントの数を、例えば「２」とする。また、第１キャラクタの希少度が「Ｓレア（最高）」の場合、発生する可能性のあるイベントの数を、例えば「３」とする。この例のように、第１キャラクタの希少度が高いほど、ゲーム中に発生する可能性のあるイベントの数を多くする。

また、イベント発生用として設定された第１キャラクタが複数の場合も同様に、複数の第１キャラクタの一部または全部の希少度が高いほど、それらの組合せに応じて発生する可能性のあるイベントの数を多くしてもよい。

本構成により、イベント発生用として設定される第１キャラクタの希少度が高いほど、ゲーム中に発生するイベントのバリエーションが広がり、ゲーム性が高まる。そして、ユーザに対して、より希少度の高いキャラクタを入手しようとする動機付けを与えることができる。

１５）上記の１）ないし１４）の何れかの構成において、前記ゲームは、ユーザにより操作される第２キャラクタによる所定のシナリオに基づいたゲームであり、前記イベントは、前記シナリオの中で追加的に発生するものであることが好ましい。

ここで、ゲームにおける「所定のシナリオ」とは、ゲームの進行に合わせて展開させるゲームストーリであり、ゲームに登場するキャラクタの役割、ゲーム中の演出効果、ゲーム内の選択肢等のゲームストーリに関連する様々な要素を含めることができる。野球ゲームを例に挙げると、ユーザにより操作される第２キャラクタを主人公として、高校２年生の夏からプロ野球選手になるまでのストーリを、所定のシナリオとすることができる。このようなシナリオの中で、イベント発生用として設定された第１キャラクタまたは複数の前記第１キャラクタの組み合わせに応じたイベントが、追加的に発生する。換言すれば、所定のシナリオがゲームのメインシナリオであり、前記イベントは、メインシナリオ自体を変更させるものではなく、メインシナリオの中で追加的に発生するゲーム要素である。

１６）本発明の他の一局面によるゲームシステムは、ゲームサーバ（201）と、当該ゲームサーバ（201）との間で通信を行う端末装置（203）と、を含むゲームシステムであって、ユーザが所有する複数のキャラクタの中からユーザによって選択された少なくとも１つのキャラクタを、イベント発生用の第１キャラクタとして設定する設定手段（71）、前記第１キャラクタまたは複数の前記第１キャラクタの組み合わせに応じて、ゲーム中に前記第１キャラクタに関連するイベントを発生させるイベント管理手段（72）、を前記ゲームサーバ（201）又は前記端末装置（203）のいずれか一方が備えている。

１７）本発明の他の一局面によるゲーム管理方法は、ゲームの管理を行うコンピュータにおけるゲーム管理方法であって、前記コンピュータが、ユーザが所有する複数のキャラクタの中からユーザによって選択された少なくとも１つのキャラクタを、イベント発生用の第１キャラクタとして設定する設定ステップと、前記コンピュータが、前記第１キャラクタまたは複数の前記第１キャラクタの組み合わせに応じて、ゲーム中に発生するイベントを変動させるイベント管理ステップと、を含む。

１８）本発明の他の一局面によるプログラムは、コンピュータを前記の１）ないし１５）の何れかに記載のゲーム管理装置（3,201,203）として動作させるためのプログラムであって、前記コンピュータを前記ゲーム管理装置（3,201,203）が備えている各手段として機能させるためのプログラムである。

本発明によれば、ユーザが任意に設定できる第１キャラクタまたは複数の第１キャラクタの組み合わせによって、ゲーム中に発生するイベントのバリエーションが豊富になる。これにより、遊戯の幅が広がり、ユーザが継続的に繰り返し飽きずに遊戯できる興趣性の高いゲームを実現できる。

本発明の一実施の形態に係るゲームシステムの構成例を示す説明図である。 ゲーム装置のハード構成の一例を示すブロック図である。 ゲームサーバのード構成の一例を示すブロック図である。 シナリオの開始から終了までの間に、様々なイベントが発生することを示す概念図である。 イベントデッキ設定画面の一例を示す説明図である。 イベント発生用のキャラクタ選択画面の一例を示す説明図である。 イベントデッキに組み込まれたキャラクタと、発生し得るイベントとの関係の一例を示す概念図である。 ゲーム装置の基本的な機能的構成の一例を示す機能ブロック図である。 ユーザ情報の一例を示す説明図である。 ゲーム管理装置の主要な構成の一例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 イベントデッキ設定情報の一例を示す説明図である。 第１キャラクタの組み合わせとイベントとの関係を示す関係情報の一例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 キャラクタ間の関係度とイベント発生確率との関係の一例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 イベントデッキ設定画面の他の例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 第１キャラクタとイベントとの対応関係の一例を示す説明図である。 ゲーム装置の動作の一例を示すフローチャートである。 ゲームシステムの他の構成例を示すブロック図である。 ゲームサーバの主要な構成の一例を示す機能ブロック図である。 ゲームシステムの他の構成例を示すブロック図である。

以下、本発明の一実施の形態に係るゲームシステム、ゲーム管理装置、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。
〔ゲームシステムの概要〕

本発明の一実施の形態に係るゲームシステムの構成例を、図１に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク４上に設置されたゲームサーバ１と、ネットワーク４を介してゲームサーバ１と通信可能に接続できる各ユーザのゲーム装置３とによって構成される。

本実施の形態のネットワーク４は、インターネットに限定されるものではなく、ゲームサーバ１と各ユーザのゲーム装置３との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線（電話回線、移動体通信回線等）、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。

このゲームシステムの例において、本発明の一実施の形態に係るゲーム管理装置は、ゲーム装置３として構成することができる。あるいは、本発明の一実施の形態に係るゲーム管理装置は、ゲームサーバ１として構成したり、相互に通信するゲームサーバ１およびゲーム装置３として構成したりすることもできる。以下には、ゲーム管理装置をゲーム装置３として構成する例について先ず説明し、その他の構成については後述するものとする。

ゲーム装置３は、ゲームプログラムを実行可能な情報処理装置であれば様々なものを適用できる。例えば、ゲーム装置３としては、据置型または携帯型のゲーム専用機、パーソナルコンピュータ（以下「ＰＣ」と呼称する）、タブレット型コンピュータ、スマートフォン、携帯電話端末、ＰＨＳ（Personal Handy-phone System）端末、携帯情報端末（ＰＤＡ：Personal Digital Assistant）、情報処理機能を備えた多機能型テレビジョン受像機（いわゆるスマートテレビ）等が適用できる。

ゲームサーバ１は、ゲームサービスを受ける各ユーザのゲーム装置３からのネットワーク４を介したアクセスを受け付けて、各ユーザのゲーム情報をデータベース等の記憶装置に蓄積して管理し、各ユーザにネットワーク４を介したゲームサービスを提供する。例えば、ゲームサーバ１は、各ユーザのゲーム装置３に対して、ゲームのシナリオの情報を追加的に配信するサービスを提供する。また、ゲームサーバ１は、ユーザ間のゲーム内交流（例えば、メッセージの送信等）のサービスをユーザに提供する。また、ゲームサーバ１は、各ユーザがオンラインモードのゲーム（例えば、ネットワーク対戦ゲーム等）を遊戯する場合に、ユーザ間のマッチング等のサービスも提供する。

なお、ゲーム装置３は、オンラインモードおよびオフラインモードの何れでもゲームを実行することが可能である。

本発明の一実施の形態に係るゲーム管理装置としてのゲーム装置３は、ゲーム中に発生するイベントのバリエーションを増やすことができる機能を備えている。ユーザはイベント発生用のキャラクタを集め、集めたキャラクタを任意に選択してイベントデッキを構築することができる。そして、イベントデッキに組み込まれた単独のキャラクタまたは複数のキャラクタの組み合わせに応じて、当該キャラクタに関連するイベントが、ゲーム中に発生可能となる。イベントデッキに組み込むキャラクタを変えれば、異なるイベントが発生する機会が得られるので、イベントのバリエーションが豊富になり、ユーザがゲームに飽きることなく繰り返し遊戯できるようになる。以下に、これを実現する本実施の形態に係るゲーム管理装置としてのゲーム装置３等の構成の詳細を説明する。
〔ゲーム装置の構成〕

ユーザが操作するゲーム装置３としては、上述のようにゲーム専用機、ＰＣ、スマートフォン、携帯電話端末等、様々なものを適用できるが、ゲーム画面を表示したり、ゲームを実行するための入力操作を行ったりといった、ゲームを遊戯する上で必要となる基本的な構成は、何れも同様である。

図２に、ゲーム装置３の構成例を示している。同図に示すように、ゲーム装置３は、主に、ＣＰＵ（Central Processing Unit）３１と、主記憶装置としてのＲＯＭ（Read Only Memory）３２及びＲＡＭ（Random Access Memory）３３と、画像処理部３４と、表示部３５と、サウンド処理部３６と、音声入力部３７と、音声出力部３８と、補助記憶装置３９と、操作入力部４０と、通信制御部４１と、デコーダ４２と、記録媒体ドライブ４３とを備えており、構成要素３１～３４、３６および３９～４２はバスライン４４を介して相互に接続されている。なお、バスライン４４と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ３１は、ゲームプログラムやウェブブラウザ等の各種プログラムの命令を解釈して実行し、ゲーム装置３全体の制御を行う。ＲＯＭ３２には、ゲーム装置３の基本的な動作制御に必要なプログラム等が記憶されている。また、ＲＡＭ３３には、ＲＯＭ３２、補助記憶装置３９または記録媒体ドライブ４３からロードされた各種プログラムやデータが記憶され、ＣＰＵ３１に対する作業領域を確保する。ゲームプログラム、ウェブブラウザ等の各種プログラムは、ＲＯＭ３２または補助記憶装置３９に記憶されており、ＲＡＭ３３にロードされてＣＰＵ３１によって実行される。また、ウェブブラウザを使用して画面を表示させる場合、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインソフトウェアを、ウェブブラウザと共にＲＯＭ３２または補助記憶装置３９に記憶していてもよい。

画像処理部３４は、ＣＰＵ３１からの画像表示命令に基づいて表示部３５を駆動し、当該表示部３５の画面に画像を表示させる。表示部３５には、液晶ディスプレイまたは有機ＥＬ（Electro-Luminescence）ディスプレイ等の既知の種々の表示装置が適用できる。なお、表示部３５は、ゲーム装置３と一体である必要はなく、例えば、ゲーム装置３に対して外部接続されるテレビジョンモニタ等であってもよい。

サウンド処理部３６は、音声入力部３７から音声が入力されたときにアナログ音声信号をデジタル音声信号に変換するとともに、ＣＰＵ３１からの発音指示に基づいてアナログ音声信号を生成して音声出力部３８に出力する。音声入力部３７は、ゲーム装置３に内蔵または外付けされたマイクロフォンからなる。音声出力部３８は、ゲーム実行時の効果音などを出力するものであり、ゲーム装置３に内蔵または外付けされたスピーカからなる。

補助記憶装置３９は、前述の各種プログラムやデータ等を格納する記憶装置である。補助記憶装置３９としては、例えばハードディスクドライブ、フラッシュメモリドライブ、メモリカードリーダライタ等を用いることができる。

操作入力部４０は、ユーザの操作入力を受け入れて当該操作入力に対応した入力信号を、バスライン４４を介してＣＰＵ３１に出力するものである。操作入力部４０の例としては、ゲーム装置３の本体に設けられた方向指示ボタン、決定ボタン、英数文字等入力ボタンなどの物理的ボタンがある。あるいは、操作入力部４０は、ゲーム装置３の本体に外部接続されたコントローラであってもよい。また、表示部３５の画面にタッチパネル（接触入力式のインタフェース）を搭載することによって表示部３５をいわゆるタッチスクリーンとして構成しているゲーム装置３の場合、当該タッチパネルも操作入力部４０となる。

また、一般的な音声認識技術を利用して、音声入力部３７から入力された音声をＣＰＵ３１が解析し、各種入力を、音声により行うことができる構成としてもよい。

通信制御部４１は、通信インタフェース４１ａを備え、ゲーム操作時等にデータ通信するための通信制御機能を有している。ここで、データ通信用の通信制御機能には、例えば、無線ＬＡＮ接続機能、無線ＬＡＮや携帯電話回線網を介したインターネット接続機能、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信機能などが含まれる。通信制御部４１は、ＣＰＵ３１からの命令に基づいてゲーム装置３を無線ＬＡＮやインターネット等に接続するための接続信号を発信するとともに、通信相手側から送信されてきた情報を受信してＣＰＵ３１へ供給する。

記録媒体ドライブ４３としては、例えば、ＤＶＤ－ＲＯＭドライブ、ＣＤ－ＲＯＭドライブ、ハードディスクドライブ、光ディスクドライブ、フレキシブルディスクドライブ、シリコンディスクドライブ、カセット媒体読み取り機等が用いられる。この場合、記録媒体４５としては、ＤＶＤ－ＲＯＭ、ＣＤ－ＲＯＭ、ハードディスク、光ディスク、フレキシブルディスク、半導体メモリ等が用いられる。

記録媒体ドライブ４３は、記録媒体４５から画像データ、音声データ及びプログラムデータを読み出し、読み出したデータをデコーダ４２に供給する。デコーダ４２は記録媒体ドライブ４３からの再生したデータに対してＥＣＣ(Error Correction Code)によるエラー訂正処理を施し、エラー訂正処理を施したデータをＲＡＭ３３等に供給する。

なお、ゲーム装置３には、その他にもＧＰＳ（Global Positioning System）信号受信回路、ＣＣＤ（Charge Coupled Device）イメージセンサ等の撮像装置（カメラ）、３軸加速度センサなどが備えられていてもよい。
〔ゲームサーバの構成〕

図３にゲームサーバ１のハード構成の一例を示している。同図に示すように、ゲームサーバ１は、主に、ＣＰＵ１１と、主記憶装置としてのＲＯＭ１２及びＲＡＭ１３と、補助記憶装置１４と、通信制御部１５と、入出力制御部１６とを備えており、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン１７を介して相互に接続されている。なお、バスライン１７と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ１１は、システムソフトウェアやゲームプログラム等のアプリケーションソフトウェアの命令を解釈して実行し、ゲームサーバ１全体の制御を行う。ＲＯＭ１２は、ゲームサーバ１の基本的な動作制御に必要なプログラム等を記憶している。ＲＡＭ１３は、各種プログラム及びデータを記憶し、ＣＰＵ１１に対する作業領域を確保する。

補助記憶装置１４は、ゲームプログラムや各種データ等を格納する記憶装置である。補助記憶装置１４としては、例えばハードディスクドライブなどを用いることができる。後述するように、ゲームサーバ１をゲーム管理装置とすることもできる。この場合、ゲームサーバ１（コンピュータ）をゲーム管理装置として動作させるためのプログラムは、例えば補助記憶装置１４に記憶されており、当該プログラムはゲームサーバ１の起動時に補助記憶装置１４からバスライン１７を介してＲＡＭ１３へとロードされ、当該ＣＰＵ１１によって実行される。

通信制御部１５は、ネットワーク４と接続される通信インタフェース１５ａを備え、ネットワーク４を介した各ユーザのゲーム装置３との間の通信を制御する。

入出力制御部１６は、例えばデータベースサーバ２と通信可能に接続され、ＣＰＵ１１がデータベースサーバ２に対してデータ（レコード）の読み書きを実行するときの入出力制御を行う。

データベースサーバ２は、ゲームサーバ１が管理する各ユーザのゲーム情報を記憶する領域を有する記憶装置として、例えばＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成の大容量ハードディスク装置を具備する。このデータベースサーバ２は、例えば、各ユーザを一意に識別する識別情報（ユーザＩＤ）と対応付けて、各ユーザの各種ゲーム情報（ユーザ名、レベル、ゲーム内ポイント、所持アイテムなど）を記憶するリレーショナルデータベース、オブジェクトデータベース又はオブジェクト関係データベース等として構築することができる。

なお、ゲームサーバ１にデータベースサーバ２の機能を持たせて、データベースをゲームサーバ１の内部で構成してもよい。また、ゲームサーバ１の有する各機能を複数のサーバに分散して持たせて、ゲームサーバ１を複数台のサーバとして構成することもできる。例えば、ユーザがゲーム装置３を操作してゲームサーバ１へアクセスした場合に、当該ユーザが正規のユーザかどうかを判別する認証機能を有する認証サーバを、ゲームサーバ１のメインサーバとは別に設け、メインサーバと認証サーバとでゲームサーバ１を構成してもよい。他の構成例としては、ユーザが課金対象のアイテムをゲーム内で購入した場合に課金管理を行う課金管理サーバを、ゲームサーバ１のメインサーバ等とは別に設け、メインサーバ、認証サーバおよび課金管理サーバによりゲームサーバ１を構成してもよい。

また、ゲームサービスを利用するユーザ数が数十万人、数百万人、あるいはそれ以上となると、多数のユーザのゲーム装置３からの巨大なアクセスにも耐え得るサーバシステムの構築が求められるため、ネットワーク４上に複数のゲームサーバ１を設けて冗長化（多重化）を図ることにより、負荷分散型のシステム構成としてもよい。この場合、複数のゲームサーバ１間の負荷を調整するためのロードバランサを設けることが望ましい。
〔ゲームの概要〕

ゲーム管理装置の一例としての本実施形態のゲーム装置３によって実行されるゲームの例としては、野球、サッカー、テニス、アメリカンフットボール、バスケットボール、バレーボールなどを題材としたスポーツゲーム、アドベンチャーゲーム、シミュレーションゲーム、育成ゲーム、ロールプレイングゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、主に、ゲーム装置３が、野球ゲームを実行する場合について、以下に説明する。

本実施の形態の野球ゲームは、所定のシナリオを進めながら主人公キャラクタに練習等を行わせ、主人公キャラクタ（ユーザにより操作されるマイキャラクタ）を育成して、自分だけのオリジナルキャラクタを完成させるゲームモードを備えている。ゲームにおける「所定のシナリオ」とは、ゲームの進行に合わせて展開させるゲームストーリであり、ゲームに登場するキャラクタの役割、ゲーム中の演出効果、ゲーム内の選択肢等のゲームストーリに関連する様々な要素を含めることができる。

本野球ゲームにおけるシナリオの一例としては、ユーザにより操作される主人公キャラクタが、高校２年生の夏からプロ野球選手になるまでの、次のような概略のゲームストーリとすることができる。例えば、主人公キャラクタは、スポーツの名門高校の野球部に所属しているが、チームメイトのレベルの高さに圧倒されて、最初はレギュラーにもなれない。主人公キャラクタは、この高校でチームメイトと練習を積みながらレギュラーを勝ち取り、野球の試合（全国大会等）に出場する。主人公キャラクタの練習および試合を視察するプロ野球球団のスカウトの評価が一定以上であれば、プロ野球選手としてスカウトされる。ユーザにより操作される主人公キャラクタは、第２キャラクタの一例である。

本ゲームでは、１つのシナリオの終了により主人公キャラクタの育成が完了する。育成が完了した主人公キャラクタは、オリジナルキャラクタとして、別のゲームモードで使用することができる。シナリオの終了後は、再度、最初からシナリオを開始することにより、繰り返し、主人公キャラクタを育成できる。

また、予め複数のシナリオが用意されており、ユーザが任意のシナリオを選択できるようにしてもよい。また、シナリオのバリエーションを増加させるため、ゲーム装置３は、ゲームサーバ１から、追加のシナリオをダウンロードできるようにしてもよい。例えば、ゲームサーバ１からは、定期的に（１か月に１回等）新しいシナリオが提供される。

上記のようなシナリオの進行の一例を次に示す。シナリオの開始から終了までのゲーム上の期間を、例えば５０週間（ゲーム内の仮想的な期間）とする。ゲーム内には、主人公キャラクタのゲーム内の行動を選択するための複数のコマンドが用意されている。コマンドの例としては、「練習」、「休む」、「お出かけ」等がある。練習コマンドを実行すれば、主人公キャラクタの能力パラメータを向上させることができる。その一方で、練習コマンドを実行すれば、体力パラメータは低下する。休むコマンドを実行すれば、例えば、主人公キャラクタの体力パラメータは向上する。お出かけコマンドを実行すれば、例えば、主人公キャラクタのやる気パラメータを向上させることができる。ユーザが何れかのコマンドを実行する毎に、例えばゲーム内の仮想的な時間が１週間ずつ経過する。すなわち、本ゲームの例では、シナリオの開始から終了まで合計５０ターンあり、１ターン毎にゲーム内の仮想的な時間が１週間ずつ経過してシナリオが進行する。

図４に示すように、シナリオの開始から終了までの間には、様々なイベントが発生する。イベントが発生する可能性のあるタイミングは、任意に定めることができる。例えば、シナリオの開始から終了までの各ターンにおいて、ユーザがコマンドを選択したタイミング、当該コマンドの実行中の任意のタイミング、当該コマンドが終了したタイミング等に、イベントの発生機会を設ける。例えば、前述の各タイミングで、イベントを発生させるか否かの抽選が所定の確率で行われるようにすることができる。あるいは、抽選に依らず、ゲームの進行度が基準に達したタイミングで必ず発生するイベントを設けてもよい。例えば、シナリオが１０ターン、２０ターン、３０ターンまで進行すれば、それらのタイミングで予定されていた所定のイベント（試合イベント等）が１００％発生するようにしてもよい。

ただし、本ゲームでは、発生するイベントは固定的ではなく、ユーザがイベントデッキに組み込んだ単独のキャラクタまたは複数のキャラクタの組み合わせに応じて、様々なイベントが追加的に発生可能となる。

図５にイベントデッキ設定画面の一例を示す。この画面には、イベントデッキ設定領域１０１が設けられている。図５の画面では、イベントデッキ設定領域１０１にはキャラクタの設定枠（いわゆるスロット）１０２が３つあり、そのうちの２つの設定枠１０２に、選手Ａのキャラクタおよび選手Ｂのキャラクタがそれぞれ設定されている例を示している。この例では、選手Ａのキャラクタおよび選手Ｂのキャラクタによって、イベントデッキが編成される。イベントデッキ設定領域１０１に設定された選手Ａのキャラクタおよび選手Ｂのキャラクタは、イベント発生用の第１キャラクタの一例である。以下、イベントデッキに組み込まれたキャラクタのことを、必要に応じて「第１キャラクタ」と称する。

イベントデッキ設定領域１０１に設定できるキャラクタは、基本的には、ユーザが所有しているキャラクタである。ユーザは、自分が所有している複数のキャラクタの中から、ユーザが任意に選択することができる。ここで、ユーザが所有しているキャラクタは、ゲーム内で、２
次元または３次元の画像、カード形式の画像など、様々な表示形態のものを適用できる。本実施の形態では、一例としてユーザが所有しているキャラクタをカード形式とする。すなわち、ユーザが所有しているキャラクタは、デジタルカードとしてゲーム装置３で管理されるとともに、ゲーム画面に表示される。

ユーザによってイベントデッキ設定領域１０１にキャラクタが設定された場合、その後、当該キャラクタは、ゲーム内に登場するようになる。ゲーム内に登場したキャラクタは、ゲーム内での練習、試合、各種イベント等において、２次元または３次元コンピュータグラフィックスにより描写してもよい。本ゲームの例では、ユーザが所有できるキャラクタは、チームメイトの選手、野球部のマネージャ、一般の人（例えば街の住人）等である。このように、キャラクタを「選手」、「マネージャ」、「一般」等の複数のカテゴリに分けて管理してもよい。また、ユーザが所有しているキャラクタが人物の場合、そのキャラクタをイベントデッキに組み込めば、そのキャラクタはゲームの登場人物となるので、ユーザが所有している（または所有可能な）キャラクタを「登場人物キャラクタ」、「登場人物ユニット」、「登場人物カード」等と称しても良い。

なお、シナリオに最初から用意されている登場人物のキャラクタ（例えば、監督１人、スカウト１人、マネージャ１人、チームメイトの選手４人～８人）は、イベントデッキ設定領域１０１にキャラクタをセットしなくともゲームに登場する。イベントデッキ設定領域１０１にキャラクタを設定すれば、そのキャラクタが登場人物として追加される。

イベントデッキ設定画面において、設定枠１０２にキャラクタを設定する操作の一例を次に示す。キャラクタがセットされていない設定枠１０２（いわゆる空きスロット）に対応する設定ボタン１０３を選択する（または設定枠１０２を直接選択する）ことにより、図６に例示するイベント発生用のキャラクタ選択画面が表示される。このキャラクタ選択画面には、ユーザが現在所有している複数のキャラクタの一覧が表示される。ユーザは、キャラクタの一覧から、イベントデッキに組み込みたいキャラクタを選択する。

また、イベントデッキに組み込まれたキャラクタを変更する場合は、変更ボタン１０４を選択する（またはキャラクタがセットされた設定枠１０２を直接選択する）。これにより、図６に例示するイベント発生用のキャラクタ選択画面が表示されるので、改めてキャラクタを選択し直すことができる。また、キャラクタをイベントデッキから外す場合は、外したいキャラクタの設定枠を選択して、所定の設定解除操作を行えばよい。

イベントデッキの設定枠にセット可能なキャラクタには、それぞれ固有のイベントが用意されている。そして、ユーザがイベントデッキに組み込んだ単独のキャラクタまたは複数のキャラクタの組合せに応じて、ゲーム中に、固有のイベントが発生し得る。ここで発生し得るイベントは、イベントデッキに組み込まれた第１キャラクタに関するイベントである。

イベントデッキに組み込まれた第１キャラクタに関するイベントには、例えば、当該キャラクタが単独で行動するイベント（例えば、練習する、食事する、おみくじを引く等）がある。第１キャラクタに関するイベントの他の例としては、当該第１キャラクタが他のキャラクタと一緒に行動するイベント（例えば、練習する、食事する、旅行する等）がある。特に、第１キャラクタが主人公キャラクタと一緒に行動するイベントが好ましい。

なお、第１キャラクタに関連するイベントは、当該第１キャラクタが画面に登場するイベントに限定されない。例えば、第１キャラクタに関連するクイズが出題されるイベントであってもよい。その他にも、第１キャラクタと関係のある他のキャラクタ（友達、先輩、後輩、コーチ、ライバル等）が第１キャラクタのことを語るイベントであったり、第１キャラクタのライバルが第１キャラクタに勝つために練習するイベントであったりしてもよい。

イベントデッキに組み込まれた第１キャラクタと、発生し得るイベントとの関係の一例を、図７の概念図に示す。図７において、「＝（イコール）」記号の左側がイベントデッキに組み込まれた第１キャラクタであり、その右側が発生し得るイベントである。

例えば、ユーザが「選手Ａ」のキャラクタをイベントデッキに組み込んだ場合、「選手Ａ」のキャラクタに関連する「イベントＡ」が発生し得る。イベントＡの一例としては、選手Ａのキャラクタが特別な練習をするイベントとすることができる。イベントＡの他の例としては、主人公と選手Ａとが仲の良いチームメイトであるキャラクタ設定の場合、主人公キャラクタと選手Ａのキャラクタとが一緒に特別な練習をしたり、一緒に食事したりするイベントとすることができる。

また、ユーザが「選手Ｂ」のキャラクタをイベントデッキに組み込んだ場合、「選手Ｂ」に対応する「イベントＢ」が発生し得る。イベントＢの一例としては、主人公と選手Ｂとがライバル関係であるキャラクタ設定の場合、主人公キャラクタと選手Ｂのキャラクタとが対決するイベントとすることができる。

また、例えばユーザが「選手Ａ」および「選手Ｂ」の両キャラクタをイベントデッキに組み込んだ場合、「選手Ａ」および「選手Ｂ」の組合せに対応する「イベントＣ」が発生し得る。イベントＣの一例としては、選手Ａと選手Ｂとがライバル関係であるキャラクタ設定の場合、選手Ａのキャラクタと選手Ｂのキャラクタとが対決するイベントとすることができる。例えば、この対決イベントにおいて、第２キャラクタとしての主人公キャラクタが対決イベントを見届けたり、応援したりする等により、イベントに参加するようにしてもよい。なお、この場合、「イベントＣ」だけではなく、前述の「イベントＡ」および「イベントＢ」も発生し得るようにしてもよい。すなわち、「選手Ａ」および「選手Ｂ」の両キャラクタがイベントデッキに組み込まれた場合には、「選手Ａ」、「選手Ｂ」、「選手Ａ」＋「選手Ｂ」の３通りのパターンが何れも有効であり、「イベントＡ」、「イベントＢ」、「イベントＣ」の何れも発生し得るようにするのである。

また、例えばユーザが「選手Ｃ」、「選手Ｄ」および「一般Ｅ」の３つのキャラクタをイベントデッキに組み込んだ場合、これら３つのキャラクタの組合せに対応する「イベントＤ」が発生し得る。イベントＣの一例としては、「選手Ｃ」および「選手Ｄ」にとって「一般Ｅ」が恋人候補であるキャラクタ設定の場合、「選手Ｃ」および「選手Ｄ」のキャラクタが「一般Ｅ」のキャラクタに告白するイベントとすることができる。例えば、このイベントにおいて、主人公キャラクタも「一般Ｅ」のキャラクタに告白することにより、イベントに参加するようにしてもよい。

また、例えば、ユーザが「選手Ａ」、「選手Ｂ」および「選手Ｄ」の３つのキャラクタをイベントデッキに組み込んだ場合、これら３つのキャラクタの組合せに対応する「イベントＥ」が発生し得る。イベントＤの一例としては、「選手Ａ」、「選手Ｂ」および「選手Ｄ」のキャラクタが合宿を行うイベントとすることができる。例えば、この合宿イベントにおいて、主人公キャラクタも合宿に参加するようにしてもよい。

上述した各イベントは、ほんの一例であり、イベントデッキに組み込むキャラクタまたは複数のキャラクタの組み合わせに応じた様々なイベントが発生するようにできる。

なお、ユーザによってキャラクタがイベントデッキに組み込まれた場合、必ずイベントが発生するようにしてもよいし、所定の確率でイベントが発生するようにしてもよいし、所定の条件を満たした場合にイベントが発生するようにしてもよい。

好ましくは、イベントデッキに組み込まれた第１キャラクタまたは複数の前記第１キャラクタの組み合わせに応じたイベントを、ゲーム中に所定の確率で発生させるようにする。この場合、イベントが発生するか否かは確率に基づき、イベントがどのタイミングで発生するかも分からない。従って、第１キャラクタがイベントデッキに組み込まれた後、ユーザは、当該第１キャラクタに関連するイベントの発生を期待しながら、緊張感を持ってゲームを遊戯する。

また、ユーザによって操作される第２キャラクタとしての主人公キャラクタと、イベントデッキに組み込まれた第１キャラクタとの関係度に応じて、前記イベントが発生する確率を変動させることが好ましい。主人公キャラクタと第１キャラクタとの関係度としては、例えば、両者の親密度としてもよいし、一方が他方を評価する評価値としてもよい。この関係度は、予め決められているものとしてもよいし、ユーザによって操作される主人公キャラクタの行動によって、ゲーム中に変動するものとしてもよい。好ましくは、ユーザの操作によって主人公キャラクタが第１キャラクタと所定の行動を行う毎に、両者の関係度を変動させる。例えば、主人公キャラクタが第１キャラクタと一緒に練習したり、遊んだりすることによって、両者の関係度が向上する。これにより、ユーザは、自分の操作によって、特定の第１キャラクタに関連するイベントの発生確率を向上させることができる。

また、主人公キャラクタと、イベントデッキに組み込まれたある第１キャラクタとの関係度が所定の基準に達した場合に、その第１キャラクタに関連するイベントが１００％発生するようにしてもよい。ここで、イベント発生のタイミングについては、関係度が所定の基準に達した直後にイベントが発生するものとしてもよいし、関係度が所定の基準に達した後、ある程度の時間をおいてから（例えばゲーム上のイベント発生タイミングの調整が入ってから）イベントが発生するものとしてもよい。一例としては、シナリオのあるターンのコマンド実行中に、主人公キャラクタと選手Ａのキャラクタとの関係度が所定の基準に達した場合、当該ターンの終了時、または次のターンの開始時に、選手Ａのキャラクタに関するイベントが発生するようにする。

なお、前記関係度が所定の基準に達していない場合については、任意に定めることができる。例えば、主人公キャラクタと第１キャラクタとの関係度が所定の基準に達していない場合、関係度に応じた確率で（あるいは関係度に依らず所定の確率で）、当該第１キャラクタに関連するイベントが発生するようにしてもよい。あるいは、主人公キャラクタと第１キャラクタとの関係度が所定の基準に達していない場合、当該第１キャラクタに関連するイベントが１００％発生しないようにしてもよい。

ところで、イベントデッキを編成する第１キャラクタの設定可能数に上限を設けないことも可能であるが、上限を設けることが好ましい。また、所定の条件を満足することによって、前記設定可能数の上限を変動させることが好ましい。所定の条件を満足する一例としては、ゲームの進行度に関係するゲームパラメータが予め設定された条件を満足することである。本ゲームでは、１つのシナリオの終了により主人公キャラクタの育成が完成するので、育成を完了したキャラクタ数を前記ゲームパラメータの一例とすることができる。すなわち、育成を完了したキャラクタ数が所定値（例えば１、５、１０等）に達することで所定の条件を満たすものとし、設定可能数の上限を向上させる。

また、課金により（例えば、課金アイテムを消費することにより）、イベントデッキ設定画面の設定枠１０２が所定数（例えば１つ）増加するようにしてもよい。あるいは、ユーザが所定量のゲーム内ポイントやゲーム内通貨等を消費することを前記所定の条件として、設定枠１０２の数が増加するようにしてもよい。

あるいは、ユーザがキャラクタの育成を途中で止めてしまった場合には、第１キャラクタの設定可能数の上限を低下させる（設定枠１０２の数が減少する）ようにしてもよい。また、キャラクタの育成を完成させても、そのキャラクタのパラメータが所定値に達しない場合には、設定可能数の上限を低下させるようにしてもよい。

その他にも、様々な条件を満たすことにより、第１キャラクタの設定可能数の上限を変動させてもよい。

また、本ゲームでは、ユーザが他のユーザと仲間関係を構築することができる。ここで、仲間とは、ゲーム内で構築されるユーザ同士の仮想的な関係の総称であり、知人、友人、友達、クラスメイト、相棒、親類、家族、兄弟、姉妹、会社や組織の同僚などの様々なゲーム内の関係を含む。なお、ユーザと関連付けがなされている他のユーザ（第２ユーザ）であれば、仲間という関係でなくてもよい。

そして、ユーザに仲間がいる場合、イベントデッキ設定画面には、仲間のキャラクタを設定できる設定枠（フレンド枠、助っ人枠等と称してもよい）が追加されるようにしてもよい。その詳細については後述する。

また、ゲーム中にイベントが発生した場合、そのイベントの進行または結果に応じて、様々な効果が発生するようにすることができる。その効果の一例としては、主人公キャラクタのパラメータが変動するようにしてもよいし、ユーザにアイテム等が付与されるようにしてもよい。あるいは、パラメータの変動等の効果を生じることなく、単にユーザが発生したイベントを楽しむだけにしてもよい。

ユーザがイベントデッキにキャラクタを組み込むためには、キャラクタを入手する必要がある。キャラクタの入手方法には幾つかの方法がある。例えば、ユーザは、抽選モードを実行することにより、抽選でキャラクタを入手できる。この抽選モードでは、ゲーム内の全てのキャラクタの中からユーザに付与するキャラクタが抽選される。ユーザが抽選モードを実行するためには、例えば、所定量のゲーム内ポイント、課金アイテム等を必要としてもよい。また、ユーザは他のユーザ（仲間等）からキャラクタをプレゼントとして受け取ることもできる。また、ユーザは、ゲーム内のプレイの報酬として、キャラクタを入手できる。例えば、ユーザは、自分が育成した複数のキャラクタを使用して他のユーザと対戦を行い、ゲーム内でランキングを競うことができる。ここでランキングの上位に入ったユーザには、報酬としてキャラクタが付与される。なお、ゲームの開始時に、所定数（例えば５つ）のキャラクタが、ユーザに付与されるようにしてもよい。

また、ユーザが所有できる各キャラクタには予め希少度が設定されている。本ゲームでは、「ノーマル」、「レア」、「Ｓレア」のうちの何れか１つの希少度が、各キャラクタ設定されている。ここで、「ノーマル」が最低の希少度であり、「Ｓレア」が最高の希少度である。よって、例えば選手Ａのキャラクタについては、「ノーマル」、「レア」、「Ｓレア」の３種類の希少度のものが存在する。例えば、ユーザは、抽選モードで「ノーマル」のキャラクタを入手することもあるし、「レア」または「Ｓレア」のキャラクタを入手することもある。図６に例示するように、本実施の形態では、キャラクタの希少度を星印の数によって示しており、「ノーマル」は星１つ、「レア」は星２つ、「Ｓレア」は星３つである。

ユーザが既に所有しているキャラクタと同一のキャラクタ（キャラクタ名も希少度も同一）を入手したとき、ゲーム装置３は、自動的に両キャラクタを合体させる合体処理を実行する。この合体処理の実行時には、画面に合体演出が表示される。この合体処理により、合体後のキャラクタのレベルが「Ｌｖ１」から「Ｌｖ２」に向上する。同一のキャラクタに対する合体が繰り返され、当該キャラクタのレベルが所定レベル（例えばＬｖ１００）に達すれば、当該キャラクタの希少度が１つ向上し、そのレベルが「Ｌｖ１」にリセットされる。例えば、選手Ａ（ノーマル、Ｌｖ９９）のキャラクタを所有しているユーザが、選手Ａ（ノーマル、Ｌｖ１）のキャラクタ入手した場合、合体処理により、ユーザは選手Ａ（レア、Ｌｖ１）のキャラクタを所有することになる。

なお、本ゲームでは、キャラクタ名が同じであっても、希少度が異なれば、合体処理が行われることはない。なお、上述の合体処理は、一例であり、これに限定されない。例えば、自動的に実行されるのではなく、ユーザによる操作に基づいて合体処理が実行されるようにしてもよい。また、異なる希少度のキャラクタ同士の合体を可能としてもよい。また、異なるキャラクタ同士の合体を可能としてもよい。

ユーザは、「ノーマル」、「レア」、「Ｓレア」の何れの希少度のキャラクタについても、イベントデッキに組み込むことができる。そして、イベントデッキに組み込まれた第１キャラクタの希少度が高いほど、当該第１キャラクタに関連するイベントの効果を高くすることが好ましい。例えば、第１キャラクタの希少度が高いほど、そのイベントの進行または結果に応じて、主人公キャラクタのパラメータが大きく変動するようにする。その詳細については後述する。

また、イベントデッキに組み込まれた第１キャラクタの希少度が高いほど、ゲーム中に発生する可能性のあるイベント（当該第１キャラクタに関連するイベント）の数を多くすることが好ましい。その詳細についても後述する。

ユーザがイベントデッキを設定または変更できるタイミングについては、任意に定めることができる。例えば、シナリオの開始前にだけ、イベントデッキの設定を許可してもよい。あるいは、シナリオの開始前にイベントデッキの設定を許可し、シナリオの開始後もイベントデッキの変更を許可してもよい。

シナリオの開始後にイベントデッキの変更を許可する場合、ユーザが任意のタイミングで何回でも変更できるようにしてもよいし、変更のタイミングまたは回数を制限してもよい。一例を挙げると、シナリオの進行中に３回（例えば、１０ターン目、２０ターン目、３０ターン目）のみ、イベントデッキの変更を許可する。この場合、ゲーム装置３のＣＰＵ３１は、イベントデッキの変更を許可するタイミングで、「ここでイベントデッキを変更しませんか？」等のメッセージを画面に表示し、ユーザにイベントデッキが変更可能である旨を報知することが好ましい。また、シナリオの開始後にイベントデッキの変更を許可する場合、所定の条件（例えば、ユーザが抽選モードを実行して新たなキャラクタを入手すること）を満たす必要があるものとしてもよい。
〔ゲーム装置の機能的構成および動作〕

次に、上記のゲームを実現するゲーム管理装置としてのゲーム装置３の機能的構成の一例について説明する。

図８は、ゲーム装置３の基本的な構成の一例を示す機能ブロック図である。

本実施の形態に係るゲーム装置３は、入力管理手段５１、実行手段５２、出力管理手段５３、キャラクタ管理手段５４、ユーザ情報管理手段５５、通信管理手段５６、交流管理手段５７等を備えている。これらの各手段は、ゲーム装置３のＣＰＵ３１が本実施の形態に係るプログラムを実行することにより実現されるものである。

入力管理手段５１は、ユーザによって操作される操作入力部４０からの入力信号を理解して、実行手段５２に出力する。実行手段５２は、ユーザの操作入力等に基づいて、演算やデータ処理を実行する。本ゲームでは、シナリオの進行、コマンドの実行、イベントの実行等の処理が行われる。実行手段５２によって実行された処理結果の情報は、記憶装置（ＲＡＭ３３、補助記憶装置３９等）の所定の領域に記憶される。出力管理手段５３は、実行手段５２による実行結果の画像情報（静止画または動画）を、画像処理部３４を介して表示部３５に出力すると共に、実行結果の音声情報を、サウンド処理部３６を介して音声出力部３８に出力する。

キャラクタ管理手段５４は、ゲーム内の全てのキャラクタを管理する機能を有する。各キャラクタにはそれらを一意に識別するキャラクタＩＤが設けられており、各キャラクタは、キャラクタＩＤにより管理される。各キャラクタには、能力パラメータおよび希少度が予め定められている。打者キャラクタの能力パラメータの一例としては、ミート、パワー、弾道、走力、肩力、守備力等がある。また、投手キャラクタの能力パラメータの一例としては、球速、コントロール、スタミナ、変化球、守備力等がある。各キャラクタの情報（キャラクタデータベース）は、補助記憶装置３９または記録媒体４５から読み出されてＲＡＭ３３に記憶される。

ユーザ情報管理手段５５は、ユーザのゲームに関する情報を、記憶装置（ＲＡＭ３３、補助記憶装置３９等）に記憶して管理する。ユーザ情報管理手段５５が管理しているユーザのゲームに関する情報の一例（この例ではユーザＩＤ＝０００００１の１人分の情報）を、図９に示す。ユーザ情報管理手段５５は、ユーザの基本情報、キャラクタ情報、アイテム情報、ポイント情報、仲間情報、交流履歴等を、記憶装置に記憶する。

ユーザの基本情報としては、ユーザＩＤ、パスワード、ユーザ名等がある。ユーザＩＤおよびパスワードは、オンラインモードにおいて、ゲームサーバ１にアクセスする場合に使用される。

キャラクタ情報には、ユーザが現在所有しているキャラクタ（イベントデッキに組み込むことが可能なキャラクタ）の情報、育成中の主人公キャラクタの情報、育成を完了したオリジナルキャラクタの情報等が含まれる。ユーザが現在所有しているキャラクタの情報としては、キャラクタＩＤが記憶される。このキャラクタＩＤに対応するキャラクタの情報は、前記キャラクタ管理手段５４によって管理されている。育成中の主人公キャラクタの情報としては、例えば、ミート、パワー、弾道、走力、肩力、守備力、体力、やる気等のパラメータの情報が記憶される。ゲーム中にコマンドまたはイベントが実行された結果として、主人公キャラクタのパラメータの一部または全部が変更された場合、当該パラメータの情報は、変更後の情報に更新される。育成を完了したオリジナルキャラクタの情報としては、キャラクタＩＤおよび育成完了時のパラメータの情報が記憶される。

アイテム情報およびポイント情報は、現在、ユーザが所有しているアイテムおよびポイントの情報である。

仲間情報とは、ユーザに関係付けられた仲間の情報であり、ユーザＩＤと対応付けられて仲間のユーザＩＤが記憶される。また、交流履歴とは、ユーザが他のユーザ（仲間等）にゲーム内で交流を行った履歴の情報である。この交流履歴には、交流の種類、相手、時間の情報が含まれる。交流の種類としては、挨拶、メッセージ送信、プレゼント、チャットなどがある。交流の相手の情報として、相手のユーザＩＤが記憶される。

通信管理手段５６は、オンラインモードまたは通信対戦モードにおいて、通信制御部４１を介して、ユーザのゲーム装置３とゲームサーバ１との間、またはユーザのゲーム装置３と他のユーザのゲーム装置３との間の情報通信を管理する機能を有する。

交流管理手段５７は、ゲーム内で行われるユーザ同士の交流やコミュニケーションを実現するものである。ユーザのゲーム装置３の交流管理手段５７は、ゲームサーバ１を介して（またはゲームサーバ１を介さずに直接）、他のユーザのゲーム装置３と、交流情報の送受信を行う。交流情報には、ユーザが相手宛に作成したメッセージや、相手にプレゼントするキャラクタまたはアイテムの情報等が含まれる。

次に、図１０機能ブロック図等を参照して、ゲーム装置３の主要な機能的構成について説明する。図１０に示すように、ゲーム管理装置としてのゲーム装置３は、主に、設定手段７１およびイベント管理手段７２を備えている。これらの各手段は、ゲーム装置３のＣＰＵ３１が、本実施の形態に係るプログラムを実行することにより実現されるものである。

設定手段７１は、ユーザが所有する複数のキャラクタの中からユーザによって選択された少なくとも１つのキャラクタを、イベント発生用の第１キャラクタとして設定する機能を有する。本実施の形態では、前述のように、図５に例示するイベントデッキ設定画面において、ユーザは自分が所有する複数のキャラクタの中から任意のキャラクタを選択して設定枠１０２にセットする操作を行う。この操作によりキャラクタ選択情報が入力された場合、設定手段７１は、選択されたキャラクタのキャラクタＩＤを、イベント発生用の第１キャラクタの設定情報として記憶装置（ＲＡＭ３３または補助記憶装置３９等）に記憶する。以下、この設定情報を「イベントデッキ設定情報」と称する。

図１２に、イベントデッキ設定情報の一例を示す。図１２では、イベントデッキの３つの設定枠１０２が有効であり、そのうちの２つの設定枠１０２に、キャラクタＩＤ＝２００１の選手Ａ（Ｓレア）およびキャラクタＩＤ＝１００２の選手Ｂ（レア）という２つの第１キャラクタが設定されている例を示している。なお、図１２では、キャラクタＩＤに対応するキャラクタの名前および希少度の各情報フィールドが設けられているが、これらの情報フィールドは省くことができる。これは、キャラクタの名前および希少度は、キャラクタＩＤによって特定されるからである。また、図１２では、関係度の情報フィールドも設けられているが、これについては後述する。

イベント管理手段７２は、イベントデッキに組み込まれた前記第１キャラクタまたは複数の前記第１キャラクタの組み合わせに応じて、ゲーム中に前記第１キャラクタに関連するイベントを発生させる機能を有する。例えば、図１３に示すように、第１キャラクタの組み合わせとイベントとの関係を示す関係情報が、予め記憶装置（ＲＡＭ３３等）に記憶されている。この関係情報は、例えば記録媒体４５または補助記憶装置３９に保存されており、ゲーム中にロードされて、ＲＡＭ３３に記憶される。そして、イベント管理手段７２は、前記関係情報に基づいて、ゲーム中に発生させるイベントを管理する。

各イベントには、それらを一意に識別するイベントＩＤが付されている。ゲーム中にあるイベントＩＤのイベントを発生させる場合、当該イベントＩＤに対応するイベント実行プログラムがＣＰＵ３１によって実行される。

図１３の関係情報において、イベントデッキに組み込まれた第１キャラクタがキャラクタＩＤ＝０００１の場合、それに対応するイベントは、イベントＩＤ＝０００１の「打撃特訓」というイベントである。また、第１キャラクタがキャラクタＩＤ＝０００２の場合、それに対応するイベントは、イベントＩＤ＝０００２の「守備特訓」というイベントである。また、第１キャラクタがキャラクタＩＤ＝０００３の場合、それに対応するイベントは、イベントＩＤ＝０００３の「走塁特訓」というイベントである。

また、イベントデッキに組み込まれた第１キャラクタがキャラクタＩＤ＝０００１および０００２の場合、この組み合わせに対応するイベントは、イベントＩＤ＝０１０１の「対決」イベントである。また、第１キャラクタがキャラクタＩＤ＝０００１および０００３の場合、この組み合わせに対応するイベントは、イベントＩＤ＝０１０２の「クイズ」イベントである。

また、第１キャラクタがキャラクタＩＤ＝０００１、０００２および０００３の場合、この組み合わせに対応するイベントは、イベントＩＤ＝０５０１の「バッティングセンター」というイベントである。また、第１キャラクタがキャラクタＩＤ＝０００１、０００２および０００４の場合、この組み合わせに対応するイベントは、イベントＩＤ＝０５０２の「みんなで遊ぶ」というイベントである。その他、イベントデッキを構成する単独の第１キャラクタまたは複数の第１キャラクタの組合せに応じた様々なイベントが用意されている。

前述のように、イベントデッキとして設定された第１キャラクタが、例えばキャラクタＩＤ＝０００１および０００２の場合、第１キャラクタの組合せとしては、「０００１」、「０００２」、「０００１＋０００２」の３パターンを有効とすることができる。よって、この場合、イベントＩＤ＝０００１の「打撃特訓」、イベントＩＤ＝０００２の「守備特訓」、イベントＩＤ＝０１０１の「対決」のイベントが発生し得る。

同様に、イベントデッキとして設定された第１キャラクタが、例えばキャラクタＩＤ＝０００１、０００２および０００３の場合、第１キャラクタの組合せとしては、「０００１」、「０００２」、「０００３」「０００１＋０００２」、「０００１＋０００３」、「０００２＋０００３」、「０００１＋０００２＋０００３」の７パターンを有効とすることができる。

イベント管理手段７２がゲーム中に発生させるイベントは、前述のように第１キャラクタに関連するイベントである。例えば、イベントＩＤ＝０００１の「打撃特訓」とは、イベントデッキに組み込まれたキャラクタＩＤ＝０００１のキャラクタが単独で、または主人公キャラクタと一緒に打撃特訓を行うイベントである。なお、前述のように、第１キャラクタに関連するイベントは、第１キャラクタが画面に登場するイベントに限定されない。

また、イベント管理手段７２は、第１キャラクタまたは複数の第１キャラクタがイベント発生用として設定された場合、必ずイベントが発生するようにしてもよいし、所定の確率でイベントが発生するようにしてもよいし、所定の条件を満たした場合にイベントが発生するようにしてもよい。

また、第１キャラクタに関連するイベントは、第１キャラクタのパラメータ（特徴的パラメータ）に関連するイベントとすることができる。例えば、第１キャラクタが、特定の能力の優れた（特定の能力のパラメータが所定の基準よりも高い）キャラクタであった場合には、当該第１キャラクタに関連するイベントは、その特定の能力に関連する（特定の能力を活用した）イベントとする。具体例としては、第１キャラクタが打撃能力の優れた（打撃能力のパラメータが所定の基準よりも高い）選手であった場合に、当該第１キャラクタに関連するイベントは、打撃に関するイベント、例えば打撃特訓、ホームラン競争等のイベントとすることができる。

また、第１キャラクタに関連するイベントは、第１キャラクタと主人公キャラクタとの関係に関連するイベントとすることができる。例えば、第１キャラクタと主人公キャラクタとが、ゲーム上、ライバル関係であった場合には、当該第１キャラクタに関連するイベントは、両キャラクタの対決シーンのイベントとする。

特に、複数の第１キャラクタを組合せることで、その組み合わせに応じたイベントが発生するので、イベントのバリエーションが非常に多くなる。すなわち、ユーザが所有するｎ個のキャラクタからｒ個のキャラクタを選択して組み合わせる場合、組み合わせの数は、ｎ！／｛（ｎ－ｒ）！ｒ！｝で表される。例えば、ユーザが所有する１０個のキャラクタから３個のキャラクタを選択して第１キャラクタとして設定する場合、１２０通りの組み合わせがあり、ユーザは、イベントデッキに組み込む第１キャラクタの組み合わせを変えれば、組合せに応じた様々なイベントの発生が期待できる。

また、複数の第１キャラクタを組み合わせる場合は、複数の第１キャラクタ間の関係に応じたイベントが発生し得るようにしてもよい。あるいは、複数の第１キャラクタに主人公キャラクタを含めた複数のキャラクタ間の関係に応じたイベントが発生し得るようにしてもよい。以下にその一例を示す。

例１：キャラクタＡおよびＢが、ゲーム上、ライバル同士の関係である場合に、両キャラクタＡおよびＢをイベントデッキに組み込むことで、対決シーンのイベントが発生する（かもしれない）ことを期待できる（あるいは、ユーザが発生し得るイベントを想像する）。

例２：キャラクタＰ、Ｑ、Ｒが、ゲーム上、同じ学校の同級生の関係である場合には、これら３体のキャラクタＰ、Ｑ、Ｒをイベントデッキに組み込むことで、３人で旅行に行くというイベントが発生する（かもしれない）ことを期待できる。さらに、キャラクタＰ、Ｑ、Ｒと第２キャラクタとが同じ学校の同級生の関係である場合には、これら３体のキャラクタＰ、Ｑ、Ｒをイベント発生用の第１キャラクタとして設定することで、第２キャラクタを含めた４人で旅行に行くというイベントが発生する（かもしれない）ことを期待できる。

イベントは必ず発生するとは限らないが、ユーザが各第１キャラクタについてのパラメータ、特徴、他の第１キャラクタとの関係、主人公キャラクタとの関係等を知っていれば、イベントデッキに組み込んだ第１キャラクタまたは複数の第１キャラクタの組み合わせによって、発生し得るイベントを想像する、あるいは期待するという楽しみも生まれる。

また、イベント発生の効果についても任意に定めることができる。例えば、イベントが発生した場合、そのイベントの進行または結果に応じて、ユーザのマイキャラクタのパラメータが変動するようにしてもよいし、ユーザにアイテム等が付与されるようにしてもよい。あるいは、パラメータの変動等の効果を生じることなく、単にユーザが発生したイベントを楽しむだけにしてもよい。

以上のように、本実施形態の構成では、ユーザはイベント発生用のキャラクタを集め、集めたキャラクタを任意に選択してイベント発生用の第１キャラクタとして設定することにより、第１キャラクタまたは複数の第１キャラクタの組み合わせに応じた様々なイベントが、ゲーム中に発生し得る。よって、ユーザは、イベントデッキ構築を試行錯誤しながら、イベント発生用として設定する第１キャラクタまたはその組合せによるイベントのバリエーションを楽しむことができる。例えば、ゲームに飽きてきたユーザは、イベント発生用として設定する第１キャラクタを変更することにより、ゲーム中に発生するイベントも変化するので、飽きの来ないゲームプレイが可能となる。

本実施の形態のゲームは、ユーザにより操作される第２キャラクタとしての主人公キャラクタによる所定のシナリオに基づいたゲームである。よって、図１１に示すように、ゲーム装置３は、シナリオ進行手段７０を備えている。このシナリオ進行手段７０は、ユーザによるゲーム進行の操作（本ゲームではコマンド選択操作）に基づいて、主人公キャラクタによる所定のシナリオを進行させる機能を有する。そして、イベント管理手段７２がイベントデッキに応じて発生させる前記イベントは、前記シナリオの中で追加的に発生する。換言すれば、前記所定のシナリオがゲームのメインシナリオであり、イベントデッキに応じたイベントは、メインシナリオ自体を変更させるものではなく、メインシナリオの中で追加的に発生するゲーム要素である（図４参照）。

ゲームのメインシナリオには、イベントデッキに関係なく、予め用意された基本イベント（試合イベント等）が周期的に、あるいはランダムに発生するようにしてもよい。この場合、イベントデッキとしてキャラクタがセットされていなくとも、シナリオの進行中に、前記基本イベントが発生することがある。この場合において、ユーザがイベントデッキとして少なくとも１つの第１キャラクタをセットしておけば、基本イベントにはない特別なイベントとして、イベントデッキに対応するイベントが追加的に発生する可能性が生じる。

但し、適用対象のゲームは、シナリオに沿って進行するゲームに限定されるものではない。例えば、ユーザがプレイヤキャラクタを操作して打撃や守備を行う野球ゲームの場合、予め決められたシナリオがあるわけではない。このようなゲームにおいて、ユーザがイベントデッキに少なくとも１つのコーチキャラクタを設定しておけば、イベントデッキに応じたイベントとして、ゲーム中にコーチが打撃のコツを教えてくれるイベント等が追加的に発生するようにしてもよい。

次に、イベントデッキに応じたイベントを所定の確率で発生させる好ましい例について説明する。本実施の形態のイベント管理手段７２は、イベントデッキに組み込まれた第１キャラクタまたは複数の前記第１キャラクタの組み合わせに応じた前記イベントを、ゲーム中に所定の確率で発生させる機能を有する。ここで、イベントを発生させる確率は、全てのイベントについて同一の確率（例えば２０％）としてもよい。あるいは、イベントの内容、種類、効果等に応じて、例えば１０％、３０％、５０％、７０％等、発生確率を異ならせてもよい。あるいは、ユーザのゲーム操作によって、主人公キャラクタと第１キャラクタとの関係度が変化し、ゲーム中にイベントの発生確率が変動するようにしてもよい（詳細は後述する）。

あるいは、シナリオの進行度によって、イベントの発生確率が変動するようにしてもよい。例えば、シナリオの進行度が所定値（５０％）に達するまでと、それ以降とで、イベントの発生確率を異ならせる。一例を挙げると、シナリオの進行度が５０％に達するまではイベントの発生確率を１０％とし、それ以降は２０％とする。これは、シナリオの前半に発生しなかったイベントを、シナリオの後半に発生し易くした例である。逆に、シナリオの前半にイベント発生し易くし、シナリオの後半にイベントを発生し難くしてもよい。

この構成では、イベント発生用の第１キャラクタが設定されたからといって、当該第１キャラクタに関連するイベントが、必ずしも１００％発生するとは限らず、イベントが発生するか否かは確率に基づいている。よって、イベントがどのタイミングで発生するかも分からない。従って、イベント発生用として第１キャラクタが設定された後、ユーザは、第１キャラクタに関連するイベントが発生することを期待しながら、緊張感を持ってゲームを遊戯することになる。本構成により、ゲーム性の向上が図られる。

次に、主人公キャラクタと第１キャラクタとの関係度に応じて、イベントの発生確率を変動させる好ましい構成について説明する。図１４に示すように、ゲーム装置３は、設定手段７１およびイベント管理手段７２に加えて、関係度管理手段７３および確率変動手段７４をさらに備えていることが好ましい。

前記関係度管理手段７３は、ゲーム中にユーザによって操作される第２キャラクタの一例としての主人公キャラクタと、イベントデッキに組み込まれた第１キャラクタとの関係度を管理する機能を有する。主人公キャラクタと第１キャラクタとの関係については、例えばチームメイト、選手と監督、選手とマネージャ、先輩と後輩、ライバル同士、恋人同士、上司と部下、親子、兄弟等、様々な関係が適用できる。そして、主人公キャラクタと第１キャラクタとの関係度としては、例えば、両者の親密度としてもよいし、一方が他方を評価する評価値としてもよい。

本実施の形態では、前記関係度は、例えば「０～２００」の何れかの数値をとるものとして説明する。なお、関係度を数値ではなく、「Ａ、Ｂ…」等のレベルで表してもよい。

主人公キャラクタと第１キャラクタとの関係度は、予め初期値が定められているものとしてもよい。一例を挙げると、主人公キャラクタと選手Ａ（第１キャラクタの一例）とは、ゲーム内で親友という設定であり、両者の関係度を「１００」とする。一方、主人公キャラクタと選手Ｂ（第１キャラクタの一例）とは、ゲーム内で知り合い程度の設定であり、両者の関係度を「１０」とする。また、主人公キャラクタとマネージャＣ（第１キャラクタの一例）との関係度を「５０」とする。

また、前記関係度は、ユーザによって操作される主人公キャラクタの行動によって、ゲーム中に変動する構成とすることが好ましい。すなわち、ゲーム装置３は、イベントデッキに組み込まれた第１キャラクタをゲーム内に登場させる登場キャラクタ管理手段７５をさらに備える。そして、関係度管理手段７３は、ユーザの操作によって主人公キャラクタが前記第１キャラクタと所定の行動を行う毎に、当該第１キャラクタと主人公キャラクタとの前記関係度を変動させる。ここで、「所定の行動」とは、例えば、主人公キャラクタが第１キャラクタと一緒に練習する、対決する、食事する、遊ぶ、あるいは同じ場所に共に一緒にいる等、様々なゲーム内の行動を言う。このように、ゲーム内で主人公キャラクタが第１キャラクタと所定の関係を有する行動を行えば、両者の関係度が変動する。

例えば、主人公キャラクタがチームメイト等の第１キャラクタと一緒に練習すれば、関係度が「１０」向上する。また、例えば、主人公キャラクタが第１キャラクタと一緒に食事すれば、関係度が「５」向上する。また、例えば、主人公キャラクタが第１キャラクタと対決し、勝利した場合は、関係度（評価値）が「１０」向上する一方、負けた場合は関係度が「５」低下する。これらは一例であり、主人公キャラクタの行動と前記関係度との対応関係は、任意に定めることができる。

関係度管理手段７３による関係度管理の一例を次に示す。図１２に例示するように、イベントデッキ設定情報の中に、関係度の情報フィールドが設けられている。そして、関係度管理手段７３は、イベントデッキとして設定されている第１キャラクタと主人公キャラクタとの関係度が変動する毎に、関係度の情報フィールドの値を更新し、現在の関係度を管理する。

そして、前記確率変動手段７４は、主人公キャラクタと第１キャラクタとの関係度に応じて、第１キャラクタに関連するイベントが発生する確率（または、当該第１キャラクタを組み合わせに含む場合における、その組み合わせに応じたイベントが発生する確率）を変動させる機能を有する。図１５に、前記関係度とイベント発生確率との関係の一例を示す。この例では、関係度が「３９以下」、「４０～７９」、「８０～１１９」、「１２０～１５９」、「１６０～１９９」、「２００（最大）」の場合、イベントの発生確率がそれぞれ「１０％」、「２０％」、「３０％」、「５０％」、「７０％」、「１００％」と変動する。この例では、関係度の数値が大きいほど（またはレベルが高いほど）、段階的にイベントの発生確率を向上させている。

イベントデッキとして設定された第１キャラクタが１つの場合、図１５のイベント発生確率をそのまま適用できる。一方、イベントデッキとして設定された第１キャラクタが複数の場合、複数の第１キャラクタの組合せに応じたイベントの発生確率は、例えば次のようにして求めることができる。ここでは、選手Ａと選手Ｂの各キャラクタがイベントデッキに組み込まれている場合を例示する。例えば、主人公キャラクタと選手Ａとの関係度が「１００」であり、主人公キャラクタと選手Ｂとの関係度が「５０」であるとする。この場合、図１５の関係に基づけば、選手Ａの関係度からは３０％、選手Ｂの関係度からは２０％のイベント発生確率が取得できる。そこで、選手Ａ＋選手Ｂの組合せに応じたイベントの発生確率は、平均をとって、（３０％＋２０％）／２＝２５％とすることができる。

複数の第１キャラクタの組合せに応じたイベントの発生確率の決定には、その他にも様々な態様が考えられる。以下にその一例を示す。

複数の第１キャラクタ（Ａ、Ｂ…）の組み合わせに応じたイベントの発生確率については、全ての第１キャラクタ（Ａ、Ｂ…）と第２キャラクタとの関係度が、所定の基準（条件）を満足した場合に、満足した関係度の基準に応じた確率が適用される。例えば、設定された複数の第１キャラクタの全てが、所定の関係度の基準（例えば「４０以上」）を満足するまではイベントの発生確率が「１０％」であり、当該基準を満足したときに、イベントの発生確率が「２０％」となる。また、複数の第１キャラクタの全てが、さらにその上の関係度の基準（例えば「８０以上」）を満足したときに、イベントの発生確率が「３０％」となる。以下同様に、複数の第１キャラクタの全てが、さらに上の関係度の基準を満足する毎に、イベントの発生確率が向上する。

あるいは、複数の第１キャラクタの組合せに応じたイベントの発生確率については、当該複数の第１キャラクタの中で最も高い関係度のものを採用し、図１５に例示する関係度とイベント発生確率との関係に基づいて決定してもよい。あるいは、逆に、最も低い関係度のものを採用してもよく、この場合は、ユーザは関係度の底上げを図ることを動機付けられる。

あるいは、複数の第１キャラクタの組合せに応じたイベントの発生確率については、当該複数の第１キャラクタの関係度の平均値を適用し、図１５に例示する関係度とイベント発生確率との関係に基づいて決定してもよい。

ところで、各々のキャラクタと主人公キャラクタとの関係度は、ユーザが画面上で視認可能とすることが好ましい。これにより、ユーザは、イベント発生用として第１キャラクタを設定する場合、あるいはゲーム進行の途中で、第１キャラクタの主人公キャラクタとの関係度を画面上で確認し、関係度を認識しながら遊戯を楽しむことができる。例えば、ユーザが、ある第１キャラクタについての関係度が高いことを画面上で確認した場合、その第１キャラクタに関するイベントが高い確率で発生するという期待感が高まる。

前記関係度をユーザが視認可能とする、ゲーム装置３における画面表示制御の一例を次に示す。ゲームには、主人公キャラクタの現在のゲーム状況（シナリオの進行度等）やパラメータを表示する画面が用意されている。この画面に、あるいはこの画面から遷移した別の画面に、ユーザが所有しているキャラクタの一覧（イベントデッキとして設定しているキャラクタを含む全ての所有キャラクタ）が表示される。そして、この一覧に含まれる各々のキャラクタには、主人公キャラクタとの関係度が視認可能に表示されている。例えば、関係度の高さを６段階にレベル分けし（図１５参照）、星印の数（１個～最大６個）等で関係度のレベルを表記する。あるいは、関係度の値そのもの（図１５の例では０～２００の範囲の値）を表記してもよい。そして、一覧に含まれるキャラクタの内、イベントデッキとして設定されているキャラクタには、その旨を確認できる情報（マーク、文字、色、濃淡等）が付されている。従って、ユーザは画面を見れば、どのキャラクタをイベントデッキとして設定しており、またそのキャラクタの主人公キャラクタとの関係度はどの程度なのかを確認することができる。

あるいは、図５または図１８に例示するイベントデッキ設定画面において、現在設定されている個々のキャラクタに、主人公キャラクタとの関係度が視認可能に表示されるようにしてもよい。

本構成により、イベント発生用として設定する第１キャラクタと主人公キャラクタとの関係度により、あるいは第１キャラクタが設定された後の主人公キャラクタとの関係度により、イベントの発生のし易さが変わる。よって、ユーザは、イベントを早く発生させたいと考える場合には、自分が設定した第１キャラクタと自分の操作キャラクタである第２キャラクタとの関係度が大きくなるように遊戯すればよいので、よりゲーム性を高めることができる。

なお、イベント発生用として第１キャラクタが設定されたことにより、主人公キャラクタが第１キャラクタと所定の行動を行わなくとも、前述のように所定の確率で、第１キャラクタに関連するイベントが発生する可能性はある。その上で、本構成では、ユーザの操作によって、主人公キャラクタが第１キャラクタと所定の行動を行うようにすることで、意図的にイベント発生の確率を向上できるのである。

よって、ユーザは、特定の第１キャラクタに関連するイベントを高い確率で発生させたい場合、主人公キャラクタが第１キャラクタと所定の行動を行うように、ゲーム操作（ゲーム内の主人公キャラクタの行動を選択する操作等）を行えばよい。本構成により、ユーザは、自分の操作によって、特定の第１キャラクタに関連するイベントの発生確率を変動させることができるので、ゲーム性がより向上する。

また、前記イベント管理手段７２は、イベントデッキとして設定された第１キャラクタと主人公キャラクタとの関係度が所定の基準に達した場合に、当該第１キャラクタに関連するイベントを１００％発生させることが好ましい。例えば、図１５に示すように、関係度が「２００」に達した場合に、イベントの発生確率を１００％にする。

ここで、イベント発生のタイミングについては、関係度が所定の基準（例えば２００）に達した直後にイベントが発生するものとしてもよいし、関係度が所定の基準に達した後、ある程度の時間をおいてから（例えばゲーム上のイベント発生タイミングの調整が入ってから）イベントが発生するものとしてもよい。

なお、関係度が所定の基準に達していない場合については、任意に定めることができる。例えば、主人公キャラクタと第１キャラクタとの関係度が所定の基準である「２００」に達していない場合、図１５に例示するように、関係度に応じた確率で当該第１キャラクタに関連するイベントが発生するようにしてもよい。あるいは、関係度が所定の基準に達していない場合には、関係度に依らず所定の確率でイベントが発生するようにしてもよい。あるいは、主人公キャラクタと第１キャラクタと関係度が所定の基準に達していない場合、当該第１キャラクタに関連するイベントが発生しないようにしてもよい。

ここで、イベント発生用として設定された第１キャラクタが１つの場合、当然ながら当該第１キャラクタと主人公キャラクタとの関係度が所定の基準に達した場合に（それを契機として）、イベントが１００％発生する。

一方、イベント発生用として設定された第１キャラクタが複数の場合、以下に示すような、様々な態様が考えられる。

複数の第１キャラクタ（Ａ、Ｂ…）の組み合わせに応じたイベントは、その組合せに含まれる全ての第１キャラクタと主人公キャラクタとの関係度が所定の基準に達した場合に、当該イベントが１００％発生するようにすることができる。

あるいは、複数の第１キャラクタ（Ａ、Ｂ…）の組み合わせに応じたイベントは、その中の何れか１つの第１キャラクタと第２キャラクタとの関係度が所定の基準に達した場合に、当該イベントが１００％発生するようにしてもよい。

あるいは、複数の第１キャラクタ（Ａ、Ｂ…）の組み合わせに応じたイベントは、その中の所定割合以上（例えば５０％以上）の第１キャラクタと第２キャラクタとの関係度が所定の基準に達した場合に、当該イベントが１００％発生するようにしてもよい。

本構成では、ユーザは、特定の第１キャラクタに関連するイベントを確実に発生させたい場合、当該第１キャラクタとの関係度が所定の基準に達するように、ゲーム操作（ゲーム内の主人公キャラクタの行動を選択する操作等）を行えばよい。本構成により、ユーザは、自分の操作によって、特定の第１キャラクタに関連するイベントを１００％発生させることができるので、ゲーム性がより向上する。

次に、イベントデッキとして設定可能な第１キャラクタの数の上限を、種々の条件によって変動させる構成について説明する。図１６に示すように、本実施の形態のゲーム装置３は、設定手段７１およびイベント管理手段７２に加えて、設定可能数管理手段７６を備えている。この設定可能数管理手段７６は、第１キャラクタの設定可能数に上限を設けると共に、所定の条件を満足することによって、前記設定可能数の上限を変動させる機能を有する。

例えば、ゲーム開始時には、第１キャラクタの設定可能数の上限は「２」である。但し、設定可能数の上限は、所定の条件を満足することによって変動する。ここで、所定の条件の例としては、以下のようなものがある。

（ａ）ゲームの進行度に関係するゲームパラメータが予め設定された条件を満足することを所定の条件とする。その詳細については後述する。

（ｂ）設定可能数の上限を大きくするために、ユーザが所定量のゲーム内ポイント、ゲーム内通貨、課金アイテム等を消費することを所定の条件とする。

（ｃ）本実施の形態のゲームのように、他のユーザと仲間関係を構築できるゲームでは、仲間数が所定人数に達することを所定の条件とする。例えば仲間数が３０人に達すると設定可能数の上限が１つ増加し、その後、４０人でさらに１つ増加し、５０人以上になるとさらに１つ増加する。

（ｄ）ゲームの実行結果が所定の基準に達しない場合を所定の条件とする。例えば、キャラクタを育成することができるゲームにおいて、ユーザがキャラクタの育成を途中で止めてしまった場合に、設定可能数の上限を低下させるようにする。また、キャラクタの育成を完成させても、そのキャラクタのパラメータが所定値に達しない場合には、設定可能数の上限を低下させるようにする。

なお、上記の（ａ）～（ｄ）は所定の条件一例であって、これらに限定されるものではなく、ゲームの内容に応じて様々な条件を定めることができる。

設定可能数管理手段７６は、例えば、図１２に示すイベントデッキ設定情報の中に設けられているフラグの有効／無効を切り換えることにより、第１キャラクタの設定可能数の増減を管理する。

本構成では、第１キャラクタの設定可能数に上限を設ける一方で、ユーザが所定の条件を満たすことによりその上限を大きくすることができるようにしている。第１キャラクタの設定可能数の上限が大きくなるほど、ゲーム中に発生可能となるイベントのバリエーションも多くなる。よって、ユーザは、設定可能数の上限を向上させるべく（または上限の低下を回避すべく）、所定の条件を満足するようにゲームを積極的に遊戯するように動機付けられる。

次に、ゲームの進行度に関係するゲームパラメータが予め設定された条件を満足することを、第１キャラクタの設定可能数の上限を変動させるための「所定の条件」とする、好ましい形態について説明する。ここで、ゲームの進行度に関係するゲームパラメータの一例としては、本実施の形態のゲームのように、複数のキャラクタを育成することができるゲームでは、育成を完了したキャラクタ数が挙げられる。この場合、育成を完了したキャラクタ数が所定値（例えば１、５、１０等）に達することで所定の条件を満たすものとする。

例えば、一度もシナリオを開始していないゲーム開始時には、第１キャラクタの設定可能数の上限は「２」である。この場合、図５のイベントデッキ設定画面の設定枠１０２は２つだけである。その後、シナリオの終了により育成を完了したキャラクタ数が「１」になれば、第１キャラクタの設定可能数の上限は「３」に変更される。これにより、図５のイベントデッキ設定画面の設定枠１０２は３つになる。さらにその後、シナリオの終了により育成を完了したキャラクタ数が「２」になれば、第１キャラクタの設定可能数の上限は「４」に変更され、設定枠１０２は４つになる。その後も育成を完了したキャラクタ数が増える毎に、第１キャラクタの設定可能数の上限を大きくしてもよいし、設定可能数の上限が所定の値（例えば５）になれば、それ以上は上限が大きくならない（設定枠１０２の数が増えない）ようにしてもよい。

ゲームの進行度に関係するゲームパラメータの他の例としては、ステージ、ポイント、レベル等、ゲーム内容に応じた様々なゲームパラメータを適用できる。例えば、所定ステージに到達したこと、獲得ポイントが所定値に到達したこと、ユーザのゲームレベルが所定レベルに到達したこと、ユーザのマイキャラクタのレベルが所定レベルに達したこと等が、「ゲームの進行度に関係するゲームパラメータが予め設定された条件を満足すること」に該当する。

本実施の形態の構成により、ユーザは、ゲームの進行度に関係するゲームパラメータが予め設定された条件を満足するように、ゲームを積極的に遊戯するように動機付けられる。

次に、ユーザに仲間がいる場合、ユーザのイベントデッキに、仲間のキャラクタを組み込むことを可能とする好ましい構成について説明する。この構成のゲーム装置３は、図１７に示すように、設定手段７１およびイベント管理手段７２に加えて、関係管理手段の一例としての仲間管理手段７７および許可手段７８を備えている。

前記仲間管理手段７７は、ユーザに関係付けられた第２ユーザの一例としての仲間を管理する機能を有する。あるユーザが他のユーザと仲間関係を構築するための一形態としては、２人のユーザの何れか一方が、他方のユーザに対してゲームサーバ１を介して仲間申請を行い、当該仲間申請を受けたユーザがゲームサーバ１を介して仲間になることを承認するという、両ユーザ間においてなされる仲間申請とその承認の操作が挙げられる。仲間管理手段７７は、図９に例示するように、ユーザと仲間関係にある他のユーザのユーザＩＤを仲間情報として記憶し、仲間管理を行う。

前記許可手段７８は、仲間が所有する特定のキャラクタを、ユーザ自身のイベント発生用の第１キャラクタとして設定することを許可する機能を有する。ここで、「仲間が所有する特定のキャラクタ」の例としては、仲間がイベントデッキとして設定しているキャラクタの１つとすることができる。例えば、図５のイベントデッキ設定画面において、仲間が、左端の設定枠１０２に設定しているキャラクタ（図１２の設定枠ＩＤ＝１に対応するキャラクタ）を、「仲間が所有する特定のキャラクタ」とすることができる。

あるいは、仲間が貸し出し可能なキャラクタとして予め選択しているキャラクタを、「仲間が所有する特定のキャラクタ」としてもよい。あるいは、仲間が所有しているキャラクタの中で最も能力の高いキャラクタをゲーム装置３が自動的に抽出し、当該キャラクタを「仲間が所有する特定のキャラクタ」としてもよい。

例えば、ユーザが仲間を所定人数（例えば１人）以上つくった場合、許可手段７８は、仲間のキャラクタをイベントデッキとして設定することを許可する。これにより、イベントデッキ設定画面には、仲間のキャラクタを設定できる助っ人枠１０５が設けられる。

図１８に、助っ人枠１０５が設けられたイベントデッキ設定画面の一例を示す。図１８では、通常の設定枠１０２が５つと、助っ人枠１０５が１つの合計６つの枠が設けられている例を示している。助っ人枠１０５に仲間のキャラクタを設定する場合、例えば、ユーザが助っ人枠１０５を選択すれば、図示しない助っ人選択画面に遷移する。この助っ人選択画面には、仲間のキャラクタの一覧が表示され、その中から任意のキャラクタを選択すれば、選択したキャラクタを助っ人枠１０５に設定することができる。

ユーザにとって、仲間のキャラクタをイベントデッキとして設定できる助っ人枠１０５は、１つだけとしてもよいし、複数であってもよい。例えば、ユーザと関係付けられている仲間の数に応じて、助っ人枠１０５の数を変動させてもよい。すなわち、仲間の数が大きいほど、仲間のキャラクタを設定できる助っ人枠１０５の数を増やしてもよい。

本実施の形態の構成では、ユーザは、自らが所有していないキャラクタであっても、仲間が所有する特定のキャラクタを借りて、ユーザ自身のイベント発生用のキャラクタとして設定できる。この場合、ユーザにとっては、仲間が多いほど、選択可能なキャラクタの幅が広がるので、様々なイベントの発生が可能となる。本構成により、各ユーザは、積極的に多くの仲間を作ろうとする動機付けを与えられることになる。そして、各ユーザの仲間が増えることにより、ユーザ間のコミュニティが活性化し、延いてはゲーム全体の活性化が図られる。

次に、イベントデッキに応じたイベントが発生した場合の効果等について説明する。イベントが発生した場合、単にユーザが発生したイベントを楽しむだけにしてもよいが、発生したイベントの進行または結果に応じて、主人公キャラクタのパラメータを変動させる構成が好ましい。この構成を実現するゲーム装置３は、図１９に示すように、設定手段７１およびイベント管理手段７２に加えて、パラメータ変動手段７９を備えている。

イベントデッキに応じたイベントは、ユーザにより操作される第２キャラクタの一例としての主人公キャラクタに関連するイベントとすることが好ましい。ここで主人公キャラクタに関するイベントとは、例えば、主人公キャラクタが第１キャラクタと練習する、対決する、食事する、旅行する等、がある。なお、主人公キャラクタに関連するイベントは、主人公キャラクタが画面に登場するイベントに限定されない。例えば、第１キャラクタが主人公キャラクタのことを語る、思う、想像するようなイベントであったり、主人公キャラクタのライバルである第１キャラクタが、主人公キャラクタに勝つために練習するイベントであったりしてもよい。

そして、前記パラメータ変動手段７９は、ゲーム中に発生した、イベントデッキに応じたイベントの進行または結果に応じて、主人公キャラクタのパラメータを変動させる機能を有する。

例えば、野球ゲームの場合、イベントの進行または結果に応じて、主人公キャラクタの打力、走力、守備力等の特定のパラメータが向上したり、特殊能力のパラメータを獲得したりする。一例を挙げると、図１３に例示するように、キャラクタＩＤ＝０００１の選手Ａのキャラクタをイベントデッキとして設定した場合、打撃特訓イベントが発生する。このイベントでは、例えば、主人公キャラクタと選手Ａとが一緒に打撃特訓を行なう。このイベントの結果により、主人公キャラクタの打力（ミート、パワー）のパラメータが所定量（または所定割合）向上する。

また、図１３に例示するように、キャラクタＩＤ＝０００２の選手Ｂのキャラクタをイベントデッキとして設定した場合、走力特訓イベントが発生する。このイベントでは、例えば、主人公キャラクタと選手Ｂとが一緒に走力特訓を行なう。このイベントの結果により、主人公キャラクタの走力のパラメータが所定量（または所定割合）向上する。

なお、主人公キャラクタのパラメータを変動させるイベントの条件としては、必ずしも、主人公キャラクタに関連するイベントである必要はない。例えば、第１キャラクタが打撃能力の優れた選手であった場合に、当該第１キャラクタに関連するイベントが進行または完了すると、仮に主人公キャラクタ自身がそのイベントに登場していなくても、主人公キャラクタの打撃能力のパラメータが向上するようにしてもよい。

もっとも、第２キャラクタとしての主人公キャラクタに関連するイベントが発生した場合にのみ、当該イベントの進行または結果に応じて主人公キャラクタのパラメータ（能力等）が変動するようにしてもよい。

また、所定の能力（打力、走力、守備力等）の高い第１キャラクタをイベントデッキとして設定することにより、主人公キャラクタの当該能力を向上させるイベントが発生するようにすることが好ましい。例えば、打力のパラメータが所定の基準よりも高い第１キャラクタＰ，Ｑ，Ｒ・・・の何れかをイベントデッキとして設定することにより、主人公キャラクタの打力を強化できるイベントが発生する。また、打力のパラメータが所定の基準よりも高い第１キャラクタＰ，Ｑ，Ｒ・・・を１つより２つ、２つより３つと、より多くイベントデッキとして設定することにより、打力強化の効果がより高いイベントが発生する（イベントの内容も各々異なる）。同様に、走力のパラメータが所定の基準よりも高いキャラクタをイベントデッキとして設定することにより、主人公キャラクタの走力を強化できるイベントが発生する。

このように、主人公キャラクタのパラメータの変動の内容は、前記第１キャラクタのパラメータに関連するものであることが好ましい。例えば、第１キャラクタが打撃能力の優れた（打撃能力のパラメータが所定の基準よりも高い）選手であった場合に、当該第１キャラクタに関連するイベントが進行または完了すると、主人公キャラクタは、その第１キャラクタの特定のパラメータ（この場合、打撃能力）の影響を受けて、それと同じ打撃能力が向上する。

なお、ユーザが、発生したイベントを最後まで完了させない場合、あるいはイベントをクリアしない場合であっても、イベントの進行度に応じてパラメータを変動させることも可能である。

本実施の形態の構成では、イベントデッキに応じたイベントの効果として、主人公キャラクタのパラメータが変動する。そして、発生するイベントに応じて、パラメータの変動効果も変わる。よって、ユーザはイベントデッキとして設定する第１キャラクタのパラメータを考慮しながら組合せを工夫することにより、様々なイベントを発生させて、主人公キャラクタのパラメータを万遍なく向上させたり、特定のパラメータの強化を図ったりすることができる。本構成によりゲーム性をより向上させることができる。

次に、イベントデッキとして設定された第１キャラクタの希少度に応じて、イベントの効果を異ならせる好ましい構成について説明する。前述のように、本実施の形態のゲームでは、「ノーマル」、「レア」、「Ｓレア」のうちの何れか１つの希少度が、各キャラクタに予め設定されている。なお、希少度は、３段階の設定に限定されない。例えば、希少度は、「ノーマル」、「ノーマル＋」、「レア」、「レア＋」、「Ｓレア」の５段階であってもよい。また、希少度は、「１、２…」、「Ａ、Ｂ…」、「金、銀…」等、様々な態様で表すことができる。

そして、前記パラメータ変動手段７９は、イベントデッキとして設定された第１キャラクタの希少度が高いほど、当該第１キャラクタに応じて発生したイベントの進行または結果に応じて、主人公キャラクタのパラメータを大きく変動させる機能を有する。例えば、選手Ａ（ノーマル）の第１キャラクタに応じて発生したイベントの結果、主人公キャラクタの打力は「＋１０」となる。また、同じ名前でも、選手Ａ（レア）の第１キャラクタに応じて発生したイベントの結果、主人公キャラクタの打力は「＋２０」となる。また、選手Ａ（Ｓレア）の第１キャラクタに応じて発生したイベントの結果、主人公キャラクタの打力は「＋３０」となる。このように、同じ名前の選手Ａのキャラクタでも、希少度が異なれば、内容の異なるイベントが発生し（または同一内容のイベントが発生してもよい）、上述のようにイベントの効果が異なる。

本実施の形態の構成により、イベントデッキとして設定される第１キャラクタの希少度が高いほど、ゲームを有利に進めることができるようになり、ゲーム性が高まる。そして、ユーザに対して、より希少度の高いキャラクタを入手しようとする動機付けを与えることができる。

次に、イベントデッキとして設定された第１キャラクタの希少度が高いほど、ゲーム中に発生する可能性のあるイベント（当該第１キャラクタに関連するイベント）の数を多くする好ましい構成について説明する。

ここでは、イベントデッキとして設定された第１キャラクタが１つの場合を例に挙げて説明する。図２１に、イベントデッキとして設定された第１キャラクタと、発生する可能性のあるイベントとの対応関係の一例を示す。図２１の例では、イベントデッキとして選手Ａ（ノーマル）のキャラクタが設定された場合、発生する可能性のあるイベントは、「打撃特訓０１」の１つである。また、イベントデッキとして選手Ａ（レア）のキャラクタが設定された場合、発生する可能性のあるイベントは、「打撃特訓０２」および「打撃特訓０３」の２つである。また、イベントデッキとして選手Ａ（Ｓレア）のキャラクタが設定された場合、発生する可能性のあるイベントは、「打撃特訓０４」、「打撃特訓０５」および「打撃特訓０６」の３つである。なお、これは一例であり、第１キャラクタの希少度が高いほど、ゲーム中に発生する可能性のあるイベントの数が多いという関係が成立すれば、イベントの数は任意に定めることができる。

なお、図２１の例では、選手Ａ（ノーマル）、選手Ａ（レア）、選手Ａ（Ｓレア）の３つのキャラクタをイベントデッキに組み込んだ場合、「打撃特訓０１」～「打撃特訓０６」の何れのイベントも発生する可能性がある。

また、イベントデッキとして設定された第１キャラクタが複数の場合も同様に、複数の第１キャラクタの一部または全部の希少度が高いほど、それらの組合せに応じて発生する可能性のあるイベントの数を多くしてもよい。

本実施の形態の構成により、イベント発生用として設定される第１キャラクタの希少度が高いほど、ゲーム中に発生するイベントのバリエーションが広がり、ゲーム性が高まる。そして、ユーザに対して、より希少度の高いキャラクタを入手しようとする動機付けを与えることができる。

ところで、複数の第１キャラクタの組み合わせに応じて発生するイベントは、当該複数の第１キャラクタ間の関係に基づいたイベントであることが好ましい。ここで、複数の第１キャラクタ間の関係とは、例えば、ライバル、親友、親子、恋人等、ゲームの内容に応じた様々な関係が適用できる。例えば、キャラクタＡとキャラクタＢとはライバルの関係であったとする。そして、イベントデッキとしてキャラクタＡおよびキャラクタＢが設定された場合、両キャラクタの組み合わせに応じたイベントとして、両キャラクタの関係（ライバル）に基づいて、対決イベントが発生する。この場合、主人公キャラクタが対決イベントを見届けたり、応援したりする等により、イベントに参加するようにしてもよい。

このように、イベント発生用として設定された複数の第１キャラクタ間の関係に基づいた内容のイベントが発生するので、ユーザは、対決イベント等の特定の内容のイベントを発生させたい場合、キャラクタ間の関係を考えながら、イベントデッキに組み込む複数のキャラクタを選択すればよい。本構成により、ゲーム性のさらなる向上が図られる。

次に、予め、イベントと、当該イベントを発生させるためのキャラクタとの関係を示す情報をユーザに報知する構成について説明する。ゲーム装置３は、図２０に示すように、設定手段７１およびイベント管理手段７２に加えて、報知手段８０を備えている。

前記報知手段８０は、イベントと、当該イベントを発生させるための第１キャラクタまたは複数の第１キャラクタの組み合わせと、の関係を示す情報を、ユーザに報知する機能を有する。以下に、報知手段８０による報知例を示す。

（Ａ）イベントにより生じるパラメータ向上等の効果と、当該イベントを発生させるための第１キャラクタまたは複数の前記第１キャラクタの組み合わせと、の関係を示す情報を、ユーザに事前に報知（提示）する。例えば、イベントの効果として主人公キャラクタのパラメータが変動する場合、パラメータの向上を図るために必要な第１キャラクタまたは第１キャラクタの組合せに関する情報を、ユーザに事前に報知する。野球ゲームを例示すると、「打力を強化するイベントを発生させるためには、（打力の高い）キャラクタＰ、Ｑ、Ｒ・・・のいずれかのキャラクタを設定すればよい」旨の情報を画面に表示して、ユーザに報知する。報知する情報は、前記関係を示す情報の手がかりとなるようなヒント的な情報でもよい。例えば、「キャラクタＰを設定すれば、イベントで打力が強化できるかもしれない」旨の報知でもよい。

（Ｂ）イベントの種類または内容と、当該イベントを発生させるための第１キャラクタまたは複数の前記第１キャラクタの組み合わせと、の関係を示す情報（上記ヒント的な情報を含む）を、ユーザに事前に報知する。ここでイベントの種類または内容の例としては、特訓イベント、対決イベント、旅行イベント、食事イベント等がある。これらは一例であり、イベントの種類または内容は、ゲーム内容によって様々である。例えば、「対決イベントを発生させるためには、（主人公キャラクタとライバルである）キャラクタＸを設定すればよい」旨の情報を画面に表示して、ユーザに報知する。対決イベントの後には、前述のように、所定の効果（主人公キャラクタのパラメータが向上すたり特殊能力が身に付く等）が発生するようにしてもよい。また、その効果も併せて報知してもよい。

上記の（Ａ）および（Ｂ）の何れの場合も、ユーザは、ゲーム装置３で所定の操作を行えば、いつでも、報知手段８０から提示される上記の情報を画面で確認できる。

また、上記の（Ａ）および（Ｂ）の何れの場合も、ユーザに対して全ての関係を示す詳細なテーブル情報等を提示してもよいし、その一部のみをランダムに提示してユーザの興味を引くようにしてもよい。この情報の提示がある場合、ユーザは所望のイベントを発生させよう（それによって、所望の効果を発生させよう）として、それに必要なキャラクタを入手しようと動機づけられる。

また、上記の（Ａ）および（Ｂ）の何れの場合も、前記関係を示す情報として、ユーザの所有するキャラクタに関する情報のみを抽出してユーザに提示してもよい。この場合、ユーザ（特に、自分が所有するキャラクタをイベント発生用として設定すればどのようなイベントが発生するのかをあまり知らない初心者ユーザ）に、ゲームを積極的に楽しむ動機付けを与えることができる。

ここで、本実施の形態のゲーム装置３の動作の一例を、図２２のフローチャートを参照しながら、以下に説明する。

ユーザがゲーム装置３の操作入力部４０を操作して、複数のシナリオの中から任意のシナリオを選択すれば、ゲーム装置３のＣＰＵ３１は、実行対象のシナリオを決定する（Ｓ１）。なお、シナリオが１つのみであれば、ステップＳ１を省くことができる。

その後、ゲーム装置３は、イベントデッキの設定処理を実行する（Ｓ２）。このステップＳ２において、ゲーム装置３は、図５に例示するイベントデッキ設定画面を表示部３５に表示させる。このイベントデッキ設定画面で、ユーザは、自分が所有しているキャラクタの中から任意のキャラクタを選択し、イベントデッキを編成することができる。ゲーム装置３は、ユーザによって選択された少なくとも１つのキャラクタを、イベント発生用の第１キャラクタとして設定する。これにより、例えば、図１２に示すイベントデッキ設定情報が記憶装置（ＲＡＭ３３、補助記憶装置３９等）に記憶される。

なお、ステップＳ２のイベントデッキの設定処理は、ステップＳ１のシナリオ選択の前に行われてもよい。

また、上記のようにしてイベントデッキが設定された後は、イベントデッキ設定情報が不揮発性の記憶装置（補助記憶装置３９等）に記憶され、その後、ユーザがイベントデッキのキャラクタ編成を変更するまで、イベントデッキ設定情報が保持されるようにしてもよい。この場合、ユーザは、シナリオを開始する毎に、一からイベントデッキの設定操作を行う必要がなく、前回のイベントデッキ設定が引き継がれる。

また、イベントデッキに組み込むことが可能なキャラクタは、ステップＳ１で選択されたシナリオに応じて、限定されるようにしてもよい。一例を挙げると、女子高校を舞台にしたシナリオの場合、イベントデッキに組み込むことが可能なキャラクタは、女性のキャラクタに限定される。また、例えば、外国の学校を舞台にしたシナリオの場合、イベントデッキに組み込むことが可能なキャラクタは、外国人のキャラクタに限定される。この場合、ユーザは、シナリオを開始する前に、当該シナリオに応じたキャラクタを入手することを動機付けられる。

なお、ユーザは、イベントデッキ設定画面の設定枠１０２に全くキャラクタを設定しない（イベントデッキのキャラクタがゼロの状態）で、シナリオを開始することもできる。しかしながら、その場合は、イベントデッキに応じたイベントが発生することはない。但し、イベントデッキとは関係のない基本イベントが発生するようにしてもよい。

シナリオの開始後（Ｓ３）、ユーザは、例えば、「練習」、「休む」、「お出かけ」の何れかのコマンドを選択し（Ｓ４）、シナリオを進行させる。例えば、「練習」のコマンドには、打撃練習、走塁練習、守備練習、筋力トレーニング等の様々な選択可能なサブコマンドが用意されている。例えば、打撃練習のコマンドを選択すれば、イベントデッキの選手Ａと一緒に練習し、走塁練習のコマンドを選択すれば、イベントデッキの選手Ｂと一緒に練習する等、選択するコマンドによって、一緒に練習する相手が異なる。

ユーザによるコマンドの選択後に、ゲーム装置３は、イベントの抽選処理を実行する（Ｓ５）。イベントデッキに組み込まれた第１キャラクタに関連するイベントの発生確率は、例えば、図１５に示すように、主人公キャラクタと第１キャラクタとの関係度に応じて変動するようにしてもよい。ここで当選したイベントがあれば（Ｓ６でＹＥＳ）、ゲーム装置３は、そのイベントを発生させる（Ｓ７）。イベントデッキに少なくとも１つの第１キャラクタが組み込まれていれば、当該第１キャラクタに関連するイベントが発生する可能性がある。イベントデッキに複数の第１キャラクタが組み込まれていれば、複数の第１キャラクタの組合せのバリエーションも多くなり、イベントが発生する可能性も高くなる。

ゲーム装置３は、発生したイベントの進行または結果に応じて、主人公キャラクタのパラメータを変動させる。例えば、ゲーム装置３は、主人公キャラクタの打力、走力、守備力等のパラメータを向上させる。このとき、ゲーム装置３は、図９に例示する育成中のキャラクタのパラメータを、変動後の値に更新する（Ｓ８）。その後、ステップＳ９に移行する。

一方、ステップＳ６において、当選したイベントがなければ（Ｓ６でＮＯ）、ステップＳ７およびＳ８が実行されることなく、ステップＳ９に移行する。このステップＳ９では、前記ステップＳ４で選択されたコマンドが実行される。ゲーム装置３は、コマンドの実行により主人公キャラクタのパラメータが変動すれば、変動後の値に更新する（Ｓ１０）。また、コマンドの実行により、主人公キャラクタがイベントデッキに組み込まれている第１キャラクタと所定の行動（練習等）を行った場合、ゲーム装置３は、両者の関係度も更新する（Ｓ１１）。これにより、例えば、図１２のイベントデッキ設定情報における関係度の値が更新される。

その後、シナリオが終了したか否かが判断される（Ｓ１２）。ここで、シナリオが終了していない場合は（Ｓ１２でＮＯ）、ステップＳ４に戻り、シナリオが終了するまでステップＳ４～Ｓ１２が繰り返される。シナリオの終了により、主人公キャラクタの育成が完了する。

以上のように、本実施の形態のゲーム装置３では、ユーザが任意に設定できる第１キャラクタまたは複数の第１キャラクタの組み合わせによって、ゲーム中に発生するイベントのバリエーションが豊富になる。これにより、遊戯の幅が広がり、ユーザが継続的に繰り返し飽きずに遊戯できる興趣性の高いゲームを実現できる。
〔ゲーム管理装置の他の構成例〕

前述の実施の形態では、ゲーム管理装置をゲーム装置３として構成した例を示したが、以下には、ゲーム管理装置をゲームサーバ２０１として構成する例について説明する。また、ゲーム管理装置を、相互に通信する複数のコンピュータ（サーバ、端末装置）により構成する例について説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。

本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図２３に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク４上に設置されたゲームサーバ２０１と、ネットワーク４を介してゲームサーバ２０１と通信可能に接続できる各ユーザの端末装置２０３とによって構成される。

ゲームサーバ２０１のハード構成は、図３のゲームサーバ１と同様である。また、端末装置２０３のハード構成も、図２のゲーム装置３と同様である。

ゲームサーバ２０１は、ゲームサービスを受ける各ユーザの端末装置２０３からのネットワーク４を介したアクセスを受け付けて、各ユーザのゲーム情報をデータベース（記憶装置）に蓄積して管理し、各ユーザにネットワーク４を介したゲームサービスを提供する。

ゲームサーバ２０１によるゲームサービスの提供の形態としては、ゲーム用のプログラム（アプリケーションソフトウェア）がゲームサーバ２０１に実装されており、端末装置２０３でゲームを実行するのではなく、端末装置２０３でのゲーム操作入力に応じてゲームサーバ２０１でゲームを実行し、その実行結果を各ユーザの端末装置２０３に送信する形態がある。例えば、各ユーザの端末装置２０３に搭載されたウェブブラウザによってゲームがプレイできる、いわゆるブラウザゲームをゲームサーバ２０１が提供する。あるいは、ゲームサーバ２０１でゲームを実行した結果のゲーム映像を、例えばストリーミング形式で端末装置２０３に送信する、いわゆるクラウドゲーミングのサービスをゲームサーバ２０１が提供する。

あるいは、ゲーム実行プログラムの一部または全部をユーザの端末装置２０３側にインストールし、端末装置２０３においてもゲーム実行処理が行われるようなゲームシステムとすることもできる。

例えば、ブラウザゲームを提供するサービス形態では、ユーザの端末装置２０３にゲーム専用のソフトウェアをダウンロード又はインストールする必要がなく、端末装置２０３をネットワーク４に接続できる環境であれば、ユーザはどこでも気軽にゲームサーバ２０１から提供されるゲームサービスを楽しむことができる。

このゲームシステムでは、ゲームサーバ２０１が、各ユーザの端末装置２０３における入力操作に応じてゲーム進行のための演算処理やデータ処理を実行する。そして、ゲームサーバ２０１は、演算処理等の実行結果に基づいてデータベース内の各ユーザのゲーム情報を更新するとともに、当該実行結果をユーザの端末装置２０３の画面に表示させるためのウェブページ情報（ゲーム画面データ）を各ユーザの端末装置２０３に送信する。

各ユーザの端末装置２０３には、ユーザーエージェントとしてウェブサイト閲覧機能を有するウェブブラウザが搭載されており、ゲームサーバ２０１から送信されたウェブページ情報を端末装置２０３の画面に表示することができるようになっている。この端末装置２０３としては、例えば、携帯電話端末、ＰＨＳ端末、携帯情報端末（ＰＤＡ）、スマートフォン、ＰＣ、タブレット型コンピュータ、通信機能を有するゲーム装置（据置型または携帯型のゲーム装置）または双方向の通信機能を備えた多機能型テレビジョン受像機（いわゆるスマートテレビ）など、ネットワーク４経由でゲームサーバ２０１に接続してゲームサービスの提供を受けることができる様々な端末が適用できる。

そして、ゲームサーバ２０１と端末装置２０３とは互いに通信して各種データの送受が可能であり、共にＣＰＵ、ＲＯＭ、ＲＡＭ、補助記憶装置、通信制御部等を備えた情報処理装置（コンピュータ）であって、同様のハード構成を有する。よって、ゲームサーバ２０１と端末装置２０３とを含むゲームシステムにおいて、上述の各実施の形態で説明したゲーム装置３が具備する各手段７１～８０は、ゲームサーバ２０１または端末装置２０３の何れか一方が備えていればよい。すなわち、ゲーム装置３が具備する各手段７１～８０を、ゲームサーバ２０１に設けることが可能である。あるいは、ゲーム装置３が具備する各手段７１～８０を、ゲームサーバ２０１と端末装置２０３とに分散して設けることも可能である。これらの構成でも、前述の実施の形態と同様の作用効果を奏する。

例えば、図１０ではゲーム装置３が、設定手段７１およびイベント管理手段７２を備えていたが、図２４に例示するように、ゲームサーバ２０１が設定手段７１およびイベント管理手段７２の機能を備えているものとすることができる。

あるいは、図２５に例示するように、設定手段７１およびイベント管理手段７２の機能を、ゲームサーバ２０１と端末装置２０３とに分散して設けてもよい。なお、図２５では、ゲームサーバ２０１に設定手段７１を設けると共に、端末装置２０３にイベント管理手段７２を設ける構成例を示しているが、これに限定されない。ゲームサーバ２０１にイベント管理手段７２を設けると共に、端末装置２０３に設定手段７１を設けてもよい。
〔その他の実施の形態〕

前述の各実施の形態では、野球ゲームを例示したが、本発明は複数のキャラクタが登場するゲーム、例えばサッカーゲーム、対戦ゲーム等にも適用可能である。また、イベントデッキに組み込むことができるキャラクタを選手等の人物とする例について説明したが、これに限定されるものではない。前記キャラクタとしては、動物（競走馬等）、植物、架空の生物（モンスター等）、非生物（材料、道具等）など、ゲームの内容によって様々なものを適用できる。

例えば、料理ゲームの場合、イベントデッキに組み込むことができるキャラクタを、料理の材料となる野菜、果物、調味料等とすることができる。このようなキャラクタをイベントデッキに組み込むことで、その調理方法にまつわるイベントが発生し、そのイベントが進行または完了することで、主人公キャラクタがレシピ（調理方法）を一つマスターする、コックとしての能力パラメータが向上するといったゲームにも適用できる。

また、各種情報を記憶装置に記憶する記憶制御機能を有する構成に関し、記憶装置そのものについては当該構成に含まれないので、ゲーム装置、端末装置、ゲームサーバまたはゲームシステムの内外を問わず、どこに設置されていてもよい。例えば、記憶装置は、ゲームサーバ１が有するＲＡＭ１３や補助記憶装置１４、ゲーム装置３が有するＲＡＭ３３や補助記憶装置３９、あるいはゲームサーバ１やゲーム装置３とは別構成のファイルサーバ（オンラインストレージ）等であってもよい。

また、前述の各実施の形態で説明した各構成は、適宜組み合わせて適用することができる。

また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲーム装置、端末装置、ゲームサーバのＣＰＵにより実行される。また、プログラムをサーバ等に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。

１ ゲームサーバ
３ ゲーム装置（ゲーム管理装置）
３１ ＣＰＵ
３２ ＲＯＭ
３３ ＲＡＭ
３９ 補助記憶装置
７０ シナリオ進行手段
７１ 設定手段
７２ イベント管理手段
７３ 関係度管理手段
７４ 確率変動手段
７５ 登場キャラクタ管理手段
７６ 設定可能数管理手段
７７ 仲間管理手段（関係管理手段）
７８ 許可手段
７９ パラメータ変動手段
８０ 報知手段
２０１ ゲームサーバ（ゲーム管理装置）
２０３ 端末装置（ゲーム管理装置）

Claims (3)

1. 育成対象キャラクタを育成する第１ゲームと、前記第１ゲームでの育成が完了した前記育成対象キャラクタを使用可能な第２ゲームとを含むゲームを管理する機能を実現するゲームプログラムであって、
   コンピュータに、
   第１キャラクタとユーザ識別情報とを関連付けて記憶装置に記憶させる記憶制御機能と、
   ユーザの要求に基づいて、複数の抽選対象キャラクタの中から、抽選により少なくとも１つのキャラクタを決定するキャラクタ決定機能と、
   前記抽選で決定されたキャラクタが、前記ユーザ識別情報に関連付けられた前記第１キャラクタと同一のキャラクタであった場合、当該第１キャラクタと、前記抽選で決定されたキャラクタとを合体させ、当該第１キャラクタのパラメータを変動させる合体処理実行機能と、
   ユーザの操作に基づいて、前記ユーザ識別情報に関連付けられた前記第１キャラクタの中から少なくとも１つのイベント発生用キャラクタを設定する設定機能と、
   前記第１ゲームにおいて、前記設定機能によって設定された前記イベント発生用キャラクタに応じたイベントが発生した場合、当該イベント発生用キャラクタのパラメータに基づいて前記育成対象キャラクタのパラメータを変動させるパラメータ変動機能と、を実行させ、
   前記合体処理実行機能は、前記ユーザ識別情報に関連付けられた前記第１キャラクタのパラメータを変動させるときに、前記イベントが発生した場合に前記育成対象キャラクタのパラメータの変動量が大きくなるように、当該第１キャラクタのパラメータを変動させることを特徴とする、ゲームプログラム。
2. 育成対象キャラクタを育成する第１ゲームと、前記第１ゲームでの育成が完了した前記育成対象キャラクタを使用可能な第２ゲームとを含むゲームを実行するゲーム端末装置と、当該ゲーム端末装置と通信ネットワークにより接続されるサーバ装置とを備えたゲームシステムであって、
   第１キャラクタとユーザ識別情報とを関連付けて記憶装置に記憶させる記憶制御手段と、
   ユーザの要求に基づいて、複数の抽選対象キャラクタの中から、抽選により少なくとも１つのキャラクタを決定するキャラクタ決定手段と、
   前記抽選で決定されたキャラクタが、前記ユーザ識別情報に関連付けられた前記第１キャラクタと同一のキャラクタであった場合、当該第１キャラクタと、前記抽選で決定されたキャラクタとを合体させ、当該第１キャラクタのパラメータを変動させる合体処理実行手段と、
   ユーザの操作に基づいて、前記ユーザ識別情報に関連付けられた前記第１キャラクタの中から少なくとも１つのイベント発生用キャラクタを設定する設定手段と、
   前記第１ゲームにおいて、前記設定手段によって設定された前記イベント発生用キャラクタに応じたイベントが発生した場合、当該イベント発生用キャラクタのパラメータに基づいて前記育成対象キャラクタのパラメータを変動させるパラメータ変動手段と、を備え、
   前記合体処理実行手段は、前記ユーザ識別情報に関連付けられた前記第１キャラクタのパラメータを変動させるときに、前記イベントが発生した場合に前記育成対象キャラクタのパラメータの変動量が大きくなるように、当該第１キャラクタのパラメータを変動させることを特徴とする、ゲームシステム。
3. 育成対象キャラクタを育成する第１ゲームと、前記第１ゲームでの育成が完了した前記育成対象キャラクタを使用可能な第２ゲームとを含むゲームを管理するゲーム管理装置であって、
   第１キャラクタの情報を記憶装置に記憶させる記憶制御手段と、
   ユーザの要求に基づいて、複数の抽選対象キャラクタの中から抽選により決定された少なくとも１つのキャラクタの情報を取得するキャラクタ情報取得手段と、
   前記抽選で決定されたキャラクタが、前記記憶装置に記憶された前記第１キャラクタと同一のキャラクタであった場合、当該第１キャラクタと、前記抽選で決定されたキャラクタとを合体させ、当該第１キャラクタのパラメータを変動させる合体処理実行手段と、
   ユーザの操作に基づいて、前記記憶装置に記憶された前記第１キャラクタの中から少なくとも１つのイベント発生用キャラクタを設定する設定手段と、
   前記第１ゲームにおいて、前記設定手段によって設定された前記イベント発生用キャラクタに応じたイベントが発生した場合、当該イベント発生用キャラクタのパラメータに基づいて前記育成対象キャラクタのパラメータを変動させるパラメータ変動手段と、を備え、
   前記合体処理実行手段は、前記記憶装置に記憶された前記第１キャラクタのパラメータを変動させるときに、前記イベントが発生した場合に前記育成対象キャラクタのパラメータの変動量が大きくなるように、当該第１キャラクタのパラメータを変動させることを特徴とする、ゲーム管理装置。

Images