図1は、本発明の一実施形態に係るシステム1の構成を概略的に示す構成図である。一実施形態におけるシステム1は、図示するように、サーバ10と、このサーバ10とインターネット等の通信網20を介して接続された複数の端末装置30と、を備え、端末装置30のユーザに対してキャラクタを用いたゲームを提供する。また、一実施形態におけるシステム1は、電子書籍、動画コンテンツ、及び音楽コンテンツ等のゲーム以外の様々なデジタルコンテンツの提供サービス、テキストチャット(ミニメール)、サークル、アバター、日記、伝言板、及び挨拶等の様々なユーザ間のコミュニケーション機能を実現するコミュニケーションプラットフォーム(SNSプラットフォーム)サービス、並びに電子商取引サービス等の様々なインターネットサービスを、端末装置30のユーザに対して提供し得る。
一実施形態におけるサーバ10は、一般的なコンピュータとして構成されており、図示のとおり、CPU(コンピュータプロセッサ)11と、メインメモリ12と、ユーザI/F13と、通信I/F14と、ストレージ(記憶装置)15と、を含み、これらの各構成要素がバス17を介して互いに電気的に接続されている。CPU11は、ストレージ15からオペレーティングシステムやその他様々なプログラムをメインメモリ12にロードし、このロードしたプログラムに含まれる命令を実行する。メインメモリ12は、CPU11が実行するプログラムを格納するために用いられ、例えば、DRAM等によって構成される。なお、一実施形態におけるサーバ10は、それぞれ上述したようなハードウェア構成を有する複数のコンピュータを用いて構成され得る。
ユーザI/F13は、例えば、オペレータの入力を受け付けるキーボードやマウス等の情報入力装置と、CPU11の演算結果を出力する液晶ディスプレイ等の情報出力装置とを含む。通信I/F14は、ハードウェア、ファームウェア、又はTCP/IPドライバやPPPドライバ等の通信用ソフトウェア又はこれらの組み合わせとして実装され、通信網20を介して端末装置30と通信可能に構成される。
ストレージ15は、例えば磁気ディスクドライブで構成され、各種サービスを提供するための制御用プログラム等の様々なプログラムが記憶される。また、ストレージ15には、各種サービスを提供するための各種データも記憶され得る。ストレージ15に記憶され得る各種データは、サーバ10と通信可能に接続されるサーバ10とは物理的に別体のデータベースサーバ等に格納されてもよい。
一実施形態において、サーバ10は、階層構造の複数のウェブページから成るウェブサイトを管理するウェブサーバとしても機能し、こうしたウェブサイトを介して各種サービスを端末装置30のユーザに対して提供し得る。ストレージ15には、このウェブページに対応するHTMLデータも記憶され得る。HTMLデータは、様々な画像データが関連付けられ、又、JavaScript(登録商標)等のスクリプト言語等で記述された様々なプログラムが埋め込まれ得る。
また、一実施形態において、サーバ10は、端末装置30においてウェブブラウザ以外の実行環境上で実行されるアプリケーション(プログラム)を介して各種サービスを提供し得る。ストレージ15には、こうしたアプリケーションも記憶され得る。このアプリケーションは、例えば、Objective−CやJava(登録商標)等のプログラミング言語を用いて作成される。ストレージ15に記憶されたアプリケーションは、配信要求に応じて端末装置30に配信される。なお、端末装置30は、こうしたアプリケーションを、サーバ10以外の他のサーバ(アプリマーケットを提供するサーバ)等からダウンロードすることもできる。
このように、サーバ10は、各種サービスを提供するためのウェブサイトを管理し、当該ウェブサイトを構成するウェブページ(HTMLデータ)を端末装置30からの要求に応答して配信することができる。また、上述したように、サーバ10は、このようなウェブページ(ウェブブラウザ)を用いた各種サービスの提供とは代替的に、又は、これに加えて、端末装置30において実行されるアプリケーションとの通信に基づいて各種サービスを提供することができる。いずれの態様で当該サービスを提供するにしても、サーバ10は、各種サービスの提供に必要な各種データ(画面表示に必要なデータを含む)を端末装置30との間で送受信することができる。また、サーバ10は、各ユーザを識別する識別情報(例えば、ユーザID)毎に各種データを記憶し、ユーザ毎に各種サービスの提供状況を管理することができる。詳細な説明は省略するが、サーバ10は、ユーザの認証処理や課金処理等を行う機能を有することもできる。
一実施形態における端末装置30は、サーバ10が提供するウェブサイトのウェブページをウェブブラウザ上で表示すると共にアプリケーションを実行するための実行環境を実装した任意の情報処理装置であり、スマートフォン、タブレット端末、ウェアラブルデバイス、パーソナルコンピュータ、及びゲーム専用端末等が含まれ得るが、これらに限定されるものではない。
端末装置30は、一般的なコンピュータとして構成され、図1に示すとおり、CPU(コンピュータプロセッサ)31と、メインメモリ32と、ユーザI/F33と、通信I/F34と、ストレージ(記憶装置)35と、を含み、これらの各構成要素がバス37を介して互いに電気的に接続されている。
CPU31は、ストレージ35からオペレーティングシステムやその他様々なプログラムをメインメモリ32にロードし、このロードしたプログラムに含まれる命令を実行する。メインメモリ32は、CPU31が実行するプログラムを格納するために用いられ、例えば、DRAM等によって構成される。
ユーザI/F33は、例えば、ユーザの入力を受け付けるタッチパネル、キーボード、ボタン及びマウス等の情報入力装置と、CPU31の演算結果を出力する液晶ディスプレイ等の情報表示装置とを含む。通信I/F34は、ハードウェア、ファームウェア、又は、TCP/IPドライバやPPPドライバ等の通信用ソフトウェア又はこれらの組み合わせとして実装され、通信網20を介してサーバ10と通信可能に構成される。
ストレージ35は、例えば磁気ディスクドライブやフラッシュメモリ等により構成され、オペレーティングシステム等の様々なプログラムが記憶される。また、ストレージ35は、サーバ10から受信した様々なアプリケーションが記憶され得る。
端末装置30は、例えば、HTML形式のファイル(HTMLデータ)を解釈して画面表示するためのウェブブラウザを備えており、このウェブブラウザの機能によりサーバ10から取得したHTMLデータを解釈して、受信したHTMLデータに対応するウェブページを表示することができる。また、端末装置30のウェブブラウザには、HTMLデータに関連付けられた様々な形式のファイルを実行可能なプラグインソフトが組み込まれ得る。
端末装置30のユーザがサーバ10によって提供されるサービスを利用する際には、例えば、HTMLデータやアプリケーションによって指示されたアニメーションや操作用アイコン等が端末装置30に画面表示される。ユーザは、端末装置30のタッチパネル等を用いて各種指示を入力することができる。ユーザから入力された指示は、端末装置30のウェブブラウザやNgCore(商標)等のアプリケーション実行環境の機能を介してサーバ10に伝達される。
次に、このように構成された一実施形態におけるシステム1が有する機能について説明する。上述したように、一実施形態におけるシステム1は、ユーザに対して様々なインターネットサービスを提供し得るが、オンラインゲームにおいては、電子的なカード、アイテム、ゲーム内で利用可能な仮想通貨等の様々なゲームアイテムが用いられる。ゲームアイテムは、ゲームにおいてユーザによって用いられる仮想的なアイテムの総称であり、例えば、カード、キャラクタ、武器や防具等のキャラクタが装着ないし保有するアイテム、及びアバタを含む(これ以降単に「アイテム」と表現する)。本発明の一態様において、アイテムは、ゲームの進行に応じ、ユーザによって、ゲーム内で、取得、保有、使用、管理、交換、合成、強化、売却、廃棄、及び/又は贈与等され得るが、アイテムの利用態様は本明細書で明示されるものには限られない。アイテムには、例えば、ゲームの進行において適宜参照される属性情報(例えば、「レアリティ(rarity)」「レベル」、「攻撃力」、「防御力」、「ゲームアイテムの名称」等)が設定される。これらの属性情報の少なくとも一部はゲームの進行に伴って更新され得る。例えば、カードゲームにおいては、ユーザは、ゲーム内で一又は複数のカードを保有し、その保有するカードを用いてミッションを攻略したり、当該カードを用いて他のユーザやノンユーザキャラクタと対戦することによりゲームを進行させることができる。
本発明の一実施形態において、ユーザが保有するアイテムには、所定値以上のレアリティ値を有するアイテムを少なくとも1つ含むように構成してもよい。この所定値以上のレアリティ値を有するアイテムを、本明細書において、「レアアイテム」と称することがある。
以降、一実施形態におけるシステム1の機能について、複数のプレイヤキャラクタ(以下、単に「キャラクタ」と言うことがある。)によって構成されるパーティを設定してゲームを進行させる一実施形態におけるロールプレイングゲーム(RPG)を提供する機能を例として説明する。
図2は、システム1(サーバ10及び端末装置30)が有する機能を概略的に示すブロック図である。まず、一実施形態におけるサーバ10が有する機能について説明する。サーバ10は、図示するように、様々な情報を記憶する情報記憶部41と、一実施形態におけるRPGの進行を制御するゲーム進行制御部42と、を備える。これらの機能は、CPU11及びメインメモリ12等のハードウェア、並びに、ストレージ15に記憶されている各種プログラムやテーブル等が協働して動作することによって実現され、例えば、ロードしたプログラムに含まれる命令をCPU11が実行することによって実現される。また、図2に例示したサーバ10が有する機能の一部又は全部は、端末装置30によって実現され、又は、サーバ10と端末装置30とが協働することによって実現され得る。
一実施形態における情報記憶部41は、ストレージ15等によって実現され、図2に示すように、ユーザが保有するキャラクタに関する情報を管理する保有キャラクタ情報管理テーブル41aと、ユーザが保有するアイテムに関する情報を管理する保有アイテム情報管理テーブル41bと、アイテム交換条件管理テーブル41cと、アイテム交換グループ管理テーブル41dとを有する。
図3は、一実施形態における保有キャラクタ情報管理テーブル41aにおいて管理される情報の一例を示す。保有キャラクタ情報管理テーブル41aは、図示するように、ユーザを識別する「ユーザID」と、このユーザが保有するキャラクタを識別する「キャラクタID」との組合せに対応付けて、このユーザがこのキャラクタを取得した日時を示す「取得日時」、このキャラクタの「キャラクタ名」、「職業」、対戦相手との対戦に勝利すること等によって獲得する「経験値」、経験値の増加に応じて増加する「レベル(現在値/最大値)」、「HP(現在値/最大値)」、このキャラクタに対応する「シリーズ」、このキャラクタが装備している武器を識別する「設定アイテム(武器)」、このキャラクタが装備している防具を識別する「設定アイテム(防具)」、このキャラクタが装備しているアクセサリを識別する「設定アイテム(アクセサリ)」、このキャラクタが装備している1つ目のアビリティを識別する「設定アイテム(アビリティ1)」、このキャラクタが装備している2つ目のアビリティを識別する「設定アイテム(アビリティ2)」、このキャラクタの「攻撃力」、「防御力」、攻撃を重視する前衛又は防御を重視する後衛等のキャラクタの隊列を示す「隊列(前衛/後衛)」、このキャラクタがパーティに含まれている場合の設定情報である「パーティ設定情報」等の情報も管理する。なお、保有キャラクタ情報管理テーブル41aは、さらに、図示しないが、このキャラクタが保有している1つ又は複数のキャラクタを強化するアイテムを識別する「保有アイテム(強化素材)」、このキャラクタが保有している1つ又は複数のHPを回復するアイテムを識別する「保有アイテム(回復剤)」等の情報を管理するよう構成してもよい。
一実施形態において、職業には、例えば、戦士、魔法使い等の値が設定され、この職業の値に応じて、HP、攻撃力、防御力等の他のパラメータの値が変化し、又、装備できる装備品(武器、防具及びアクセサリ)及びアビリティ等のアイテムが変化する。また、HP、攻撃力、防御力等のパラメータは、例えば、レベル、及び、装備するアイテムに応じて変化する。一実施形態のRPGにおいて、キャラクタが有するパラメータは、装備するアイテムに応じて値が変化する、HP、攻撃力、防御力等のパラメータと、装備するアイテムに応じて値が変化しない、経験値、レベル等のパラメータと、が含まれる。
一実施形態において、強化素材には、レベル強化素材、限界突破素材、装備強化素材及びスキル強化素材の4種類が存在し得る。レベル強化素材は、例えば、レベルを上昇させたり、又は、経験値を上昇させるための素材である。このレベル強化素材は、例えば、希少度により、これらの上昇値を変化させてもよい。装備強化素材は、キャラクタの攻撃力、防御力を上昇させたり、又は、装備レベルの経験値を上昇させるための素材としてもよい。スキル強化素材は、プレイヤのスキルを1段階上げるための素材である。このスキル強化素材は、例えば、希少度により、成功確率を変化させてもよい。強化素材には、その他にも種々のもが考えられ、これらに限定されるものでないことはいうまでもない。
一実施形態において、回復剤は、ユーザが保有するキャラクタの残存HPを所定数だけ回復させるためのものであり得る。なお、回復剤の種類は複数あってもよく、ユーザが保有するキャラクタの残存HPを最大値へ回復させるためのものであってもよい。回復剤には、その他にも種々のもが考えられ、これらに限定されるものでないことはいうまでもない。
一実施形態におけるRPGは、シリーズ化しているゲームの複数のシリーズ(例えば、シリーズI−XIIの12シリーズ)の各々において登場するキャラクタを使用可能なゲームとして構成されており、保有キャラクタ情報管理テーブル41aのシリーズには、そのキャラクタに対応する(キャラクタが登場する)シリーズを特定する値が設定される。また、パーティ設定情報は、このキャラクタがパーティに含まれている場合の設定情報が登録され、例えば、パーティ内における並び順等が登録される。ここで、パーティ設定情報は、キャラクタがパーティに含まれていない場合には登録されないため、このパーティ設定情報の有無によって、このキャラクタがパーティに含まれているか否かを識別することができる。
一実施形態において、キャラクタは、1つの武器、1つの防具、1つのアクセサリ、及び2つのアビリティを同時に装備できるように構成されており、保有キャラクタ情報管理テーブル41aの「設定アイテム(武器)」、「設定アイテム(防具)」、「設定アイテム(アクセサリ)」、「設定アイテム(アビリティ1)」、「設定アイテム(アビリティ2)」には、それぞれに対応する個別のアイテムを識別する情報(後述するように、一実施形態においては、アイテムIDと取得日時との組合せ)が設定される。このように、一実施形態におけるRPGにおいて、キャラクタは、設定可能なアイテムの枠として、5つのアイテム枠を有し、このアイテム枠は、アイテムの種別(武器、防具、アクセサリ、アビリティ)に関連付けられている。その他の実施形態において、さらに設定可能なアイテム枠として、1つ又は複数のアイテム枠を有し、このアイテム枠には、アイテム種別(強化素材、回復剤)に関連付けられるよう構成されていてもよい。
例えば、ユーザは、一実施形態におけるRPGを初めてプレイする時には所定数のキャラクタを保有しており、その後、ゲームの進行に応じて新たなキャラクタを取得して保有する。例えば、ユーザは、ステージをクリアすることによって、現実の又は仮想的な貨幣を用いて購入することによって、又は、抽選によって、新たなキャラクタを取得し得る。
図4は、一実施形態における保有アイテム情報管理テーブル41bにおいて管理される情報の一例を示す。保有アイテム情報管理テーブル41bは、図示するように、ユーザを識別する「ユーザID」と、このユーザが保有するアイテムを識別する「アイテムID」と、このユーザがこのアイテムを取得した日時を示す「取得日時」との組合せに対応付けて、「アイテム名」、このアイテムの種別を示す「アイテム種別」、このアイテムの「経験値」、「レベル」、このアイテムに対応する「シリーズ」、「攻撃力」、「防御力」等の情報を管理する。
一実施形態のRPGにおいて、アイテムの少なくとも一部は、キャラクタと同様に、シリーズ化しているゲームの複数のシリーズの各々において登場するアイテムとして設定されており(シリーズに関連付けられており)、保有アイテム情報管理テーブル41bのシリーズには、そのアイテムに対応するシリーズを特定する値が設定される。
一実施形態において、アイテム種別には、武器、防具、アクセサリ、アビリティ、強化素材及び回復剤等を特定する値が設定される。なお、アイテム種別には、ユーザが保有しているゲームカードを特定する値が設定されてもよい。また、アイテムIDによって識別されるアイテムは、例えば、剣A(武器)、剣B(武器)、鎧B(防具)、鎧C(防具)、腕輪B(アクセサリ)、魔法A(アビリティ)及び必殺技B(アビリティ)等が対応し、このアイテム毎に、アイテムの名称、並びに、レベル毎の攻撃力及び防御力等のパラメータ等が設定されている。また、アイテムIDによって識別されるアイテムは、例えば、強化素材C(強化素材)、回復剤B(回復剤)等が対応するよう構成することもできるし、強化素材、回復剤の種類を区別しない態様であってもよい。ユーザは、同じアイテムを複数保有することができ、例えば、複数の剣Aを保有することができる。そして、経験値、レベル等のパラメータは、アイテムIDと取得日時との組合せによって識別される個別のアイテム毎に管理され、同じアイテムであっても、例えば、レベルが異なれば、攻撃力、防御力等が異なることになる。なお、アイテムIDと取得日時との組合せに代えて、例えば、アイテムIDと枝番号との組合せによって、個別のアイテムを識別するようにしても良い。
例えば、ユーザは、一実施形態におけるRPGを初めてプレイする時には所定数のアイテムを保有しており、その後、ゲームの進行に応じて新たなアイテムを取得して保有する。例えば、ユーザは、ステージをクリアすることによって、現実の又は仮想的な貨幣を用いて購入することによって、又は、抽選によって、新たなアイテムを取得し得る。特に、レアアイテムには有利なパラメータ(例えば、高い攻撃力)が設定されているので、ユーザは、レアアイテムを用いることによりゲームを有利に進行させることができる。したがって、ユーザは、保有するアイテム、所有しているポイントや仮想通貨等を使用してレアアイテムの取得を目指すようになる。
一実施形態におけるゲーム進行制御部42は、一実施形態におけるRPGの進行に関する様々な処理の実行を制御する。例えば、ゲーム進行制御部42は、ゲームの進行の制御に関する様々な画面のHTMLデータ又は制御データを端末装置30に送信し、端末装置30上で表示される当該画面を介したユーザによる操作入力に応答して様々な処理を実行し、当該処理の結果に応じたHTMLデータ又は制御データを端末装置30に送信する。ここで、RPGの進行の制御には、例えば、パーティと対戦相手との対戦処理の実行の制御、パーティの管理(パーティを構成するキャラクタの管理、及び、キャラクタが装備するアイテムの管理等が含まれる)等が含まれる。
一実施形態において、ゲーム進行制御部42は、さらに、例えば、強化素材のレアアイテムへの交換を促すため、1又は複数の交換条件に関する情報を端末装置30へ送信する。端末30上で表示されるアイテム交換選択画面を介したユーザによる操作入力に応答して、ユーザが選択したアイテム交換要求の処理を実行し、当該処理結果に応じたHTMLデータ又は制御データを端末装置30に送信する。詳細は後述する。なお、1又は複数の交換条件に関する情報の端末装置30へ送信は、ゲームの進行処理内に限られず、その開始前や終了後など任意のタイミングで行い得る。また、ゲーム内でのアイテム流通の管理は、強化素材に限られず、任意のアイテムについて行われ得る。また、交換できるレアアイテムとして、種々のものが考えられ、特定のレアアイテムに限られない。上記では、強化素材のレアアイテムへの交換を例に挙げたが、強化素材の通常のアイテムへの交換であっても構わない。以下の説明では、アイテムの交換はレアアイテムを例に説明する。
以上、サーバ10が有する機能について説明した。次に、一実施形態における端末装置30が有する機能について説明する。端末装置30は、図2に示すように、様々な情報を記憶する情報記憶部51と、一実施形態におけるRPGの進行に関する端末側の制御を実行する端末側制御部52と、を有する。これらの機能は、CPU31及びメインメモリ32等のハードウェア、並びに、ストレージ35に記憶されている各種プログラムやテーブル等が協働して動作することによって実現され、例えば、ロードしたプログラムに含まれる命令をCPU31が実行することによって実現される。また、図2に例示した端末装置30が有する機能の一部又は全部は、サーバ10と端末装置30とが協働することによって実現され、又は、サーバ10によって実現され得る。
一実施形態において、端末側制御部52は、サーバ10からのアイテム交換条件関する情報の受領及び端末30上での表示、並びに端末30上で表示されるアイテム交換選択画面を介したユーザによる選択操作の入力を受けて、ユーザが選択したアイテム交換要求をサーバ10へ送信する処理を実行する。端末側制御部52は、サーバ10側での処理結果に応じたHTMLデータ又は制御データを受領した場合、若しくは当該受領後にユーザがアイテムの確認要求を行った場合に、交換条件に即して取得したアイテムを端末30上で表示させるよう処理を実行する。
一実施形態における情報記憶部51は、メインメモリ32又はストレージ35等によって実現され、図2に示すように、アイテム情報格納領域51aを有する。このアイテム情報格納領域51aは、キャラクタから装備を解除されたアイテムに関する情報を一時的に保存するための領域である。一実施形態における端末側制御部52は、一実施形態におけるRPGの進行に関する様々な端末側の処理の実行を制御する。例えば、端末側制御部52は、ゲームの進行の制御に関する様々な画面のHTMLデータ又は制御データをサーバ10から受信して当該画面を端末装置30上で表示し、ユーザによる当該画面を介した操作入力を受け付けて、当該操作入力に対応する制御データ等をサーバ10に送信する。
一実施形態において、端末側制御部52は、さらに、ゲームの進行処理中やその前後に、例えば、強化素材の他のレアアイテム等への複数の交換条件に関する画面のHTMLデータ又は制御データをサーバ10から受信して当該画面を端末装置30上で表示し、ユーザによる当該画面を介した操作入力を受け付けて、当該操作入に対応する制御データ等をサーバ10に送信する。
次に、一実施形態におけるシステム1の動作について説明する。図5は、一実施形態におけるサーバ10によって実行されるゲーム進行処理の一例を示すフロー図である。ゲーム進行処理では、まず、図示するように、特定のアイテムの存在量に偏りがあるか判断される(ステップ80)。特定のアイテムの存在量が過剰になっている等の状況がみられた場合、当該アイテムと交換可能なアイテムとの交換条件を1つ若しくは複数個ユーザに提示する(ステップ85)。ユーザは提示されたアイテム交換条件の中から希望するアイテム交換条件を選択し、サーバ10はユーザによるアイテム交換の選択を受け付ける(ステップ90)。なお、上記ステップ80は省略されてもよい。アイテムの存在量に偏りが生ずることが予め予想されるなどの場合は、これらのアイテムの交換条件の提示を行うこととなる(ステップ85)。また、ユーザ全体でのアイテム所有量など交換対象とするアイテムを特定する判断基準に限定はなく、上記ステップ80における判断基準としては上記以外に様々なものが考えられる。例えば、レアアイテムやレアキャラクタの流通である場合、1日あたりのアクティブユーザ数(その日実際にアプリケーションを起動してゲームをプレイしたユーザ数)のうち、そのゲームアイテムを保有するユーザの割合を流通率とし、システム側で意図した流通率との乖離をみることにより判断されてもよい。また、ゲーム掲示板などでのアイテムやキャラクタの話題性により判断されてもよい。他方、回復剤などの流通である場合、1日あたりのアクティブなユーザ数と、それらのユーザが保有するゲームアイテムの個数との比率を求め、システム側が意図した比率との乖離を見るように構成してもよい。このように、ゲーム内全体のアイテム個数ではなく、アクティブユーザが保有するアイテム個数とすることで、休眠ユーザが保有するアイテム個数が除かれ、より実態と近い流通量を基準とすることができる。一実施形態において、ユーザによるアイテム交換要求は、端末装置30に表示されるアイテム交換選択画面75を介して行われる。図6は、一実施形態におけるアイテム交換選択画面75の一例を示す。アイテム交換選択画面75は、図示するように、中央にアイテム交換条件表示領域77が配置されると共に下端に基本メニュ領域100が配置されている。アイテム交換条件表示領域77には、ユーザによって選択可能な1又は複数のアイテム交換条件(図6の例では、アイテム交換条件1−3の3つの交換条件)が表示され、ユーザは、アイテム交換条件表示領域77に表示されているアイテム交換条件の中から所望の交換条件を選択することができる。ユーザによる選択可能な交換条件は、例えば、すでに交換条件を選択したことや一定の時間が経過したこと等に応じて変更され得る。なお、アイテム交換条件表示領域77には、図示しないが、ユーザがいずれのアイテム交換も希望しない場合に選択可能な「アイテム交換しない」という表示がなされ得る。なお、図6の下端の基本メニュ領域100の詳細は、後述する。
一実施形態におけるサーバ10によって実行されるゲーム進行処理では、サーバ10のゲーム進行制御部42は、例えば、強化素材が、ゲーム内で過剰に流通していると判断した場合、当該強化素材のレアアイテムへの交換を促すため、ステップ90において、当該強化素材のレアアイテムへの交換条件を1又は複数個提示するよう、当該1又は複数の交換条件に関する情報を端末装置30へ送信する。ここで、ゲーム内でのアイテム流通の管理は、強化素材に限られず、任意のアイテムについて行われ得る。また、レアアイテムとして、ユーザが保有するキャラクタの任意のパラメータ(攻撃力、防御力、HPなど)を所定量上昇させるブースト素材などが考えられるが、これに限られない。レアアイテムとして、クエストで敵を倒しても容易に入手できないアイテム、ガチャを使用しても入手が困難なアイテム、アイテム交換以外で入手不可能なアイテムなども考えられる。また、レアアイテムとして、パラメータの高い装備品(武器、防具)、アビリティなどであってもよい。ユーザには、当該情報を受領した端末30上で1又は複数の交換条件が提示されたアイテム交換選択画面75が表示される。アイテム交換選択画面75上でのユーザによる操作入力に応答して、ユーザが選択したアイテム交換条件に従いアイテム交換の処理を実行し、当該処理結果に応じたHTMLデータ又は制御データを端末装置30に送信する。
より具体的には、一実施形態におけるサーバ10のゲーム進行制御部42は、強化素材のゲーム内での流通を低減するため、下記のような方法で、当該強化素材のレアアイテムへの交換を促す。図10は、ユーザへ提示するアイテム交換条件をより詳細に示したものである。図10は、アイテム交換条件管理テーブル41cを示し、交換条件として1からN個の条件がテーブルで管理され、各交換条件には、固有のグループIDが付与されている。交換条件には、例えば、交換条件1として、「強化素材10個をブースト素材Aと交換」、交換条件2として、「強化素材50個をブースト素材Bと交換」、交換条件3として、「強化素材100個をブースト素材Cと交換」があり、強化素材の交換個数が大きくなるにつれ、より強力なブースト素材と交換することができるような交換条件とすることができる。また、別の交換条件には、例えば、交換条件4として、「回復剤10個をブースト素材Dと交換」、交換条件5として、「回復剤20個をブースト素材Eと交換」、交換条件6として、「回復剤30個をブースト素材Fと交換」があり、回復剤の交換個数が大きくなるにつれ、より強力なブースト素材と交換することができるような交換条件を設定することができる。いずれの場合においても、交換条件は、ユーザのゲーム内ランクやゲームの進捗などユーザ固有のステータスに応じて適宜変更され得る。ユーザのランクが上昇したり、ゲームの進捗が進展するに従い、よりレートのよい交換条件が設定され得る。また、交換条件は、ゲーム内の各種アイテムの流通量に応じて、適宜設定・変更され得る。さらに、交換条件は、一定の時間の経過に伴い変更されてもよい。
一実施形態において、サーバ10のゲーム進行制御部42は、強化素材のゲーム内での流通を低減させるため、当該強化素材のレアアイテムへの交換を促す。ステップ90において、図10のアイテム交換条件管理テーブル41cの中から、別個のグループIDが付与された交換条件1、2及び3の内の1つ又は複数の交換条件を端末装置30へ送信する(交換条件として3つの例を挙げたが、1つ、2つ若しくは4つ以上の交換条件が設定されても構わない)。一方、サーバ10のゲーム進行制御部42は、回復剤が、ゲーム内で過剰に流通していると判断した場合、当該回復剤のレアアイテムへの交換を促すため、ステップ90において、図10のアイテム交換条件管理テーブル41cの中から、別個のグループIDが付与された交換条件4、5及び6の内の1つ又は複数の交換条件を端末装置30へ送信する(交換条件として3つの例を挙げたが、1つ、2つ若しくは4つ以上の交換条件が設定されても構わない)。サーバ10のゲーム進行制御部42は、強化素材及び回復剤のいずれについての流通量を抑制するため、ステップ90において、例えば、図10のアイテム交換条件管理テーブル41cの中から、交換条件1、2及び3の内の1つ又は複数の交換条件と、交換条件4、5及び6の内の1つ又は複数の交換条件とを端末装置30へ送信するようにしてもよい。いずれの場合においても、交換条件の設定、追加及び選択はランダムに行われ、これらのいずれがユーザに提示されるかは、抽選などにより決定することができる。ユーザに提示される交換条件の個数は、ユーザのゲーム内ランクやゲームの進捗などユーザ固有のステータスに応じて適宜変更され得る。ユーザのランクが上昇したり、ゲームの進捗が進展するに従い、ユーザに提示される交換条件の個数を増やすよう構成してもよい。
図11は、アイテム交換グループ管理テーブル41dを示し、図10の交換条件にそれぞれ付与されたグループID毎に、1つ又は複数の交換条件が設定され、これらがテーブルで管理されている。図11では、グループID1、ID2として、強化素材とレアアイテムとの交換条件がそれぞれ3つ設定されているが、図10の各種アイテムの設定に応じて、回復剤その他のアイテムとレアアイテムとの交換条件が適宜設定される。一実施形態において、サーバ10のゲーム進行制御部42は、強化素材の流通量をさらに抑制するため、当該強化素材のレアアイテムへの交換を促す。ステップ90において、図10のアイテム交換条件管理テーブル41cの中から、例えば、交換条件1、2及び3の交換条件を端末装置30へ送信する。ユーザは、交換条件の提示を受け、端末装置30上のアイテム交換選択画面75で交換条件1を選択すると、サーバ側では、選択した交換条件に基づきアイテム交換の処理を実行するとともに、必要と判断した場合(未だに強化素材の流通量を抑制する場合など)には当該ユーザへの更なる交換条件の提示のため、アイテム交換グループ管理テーブル41dを参照する。その際、同じグループIDのグループ内の別の交換条件が提示される。当該グループ内の別の交換条件は、すでに提示されたがユーザにより選択されなかった交換条件でもよいし、今迄に提示されたことがない交換条件であってもよい。また、新たな交換条件の提示が複数回に亘って行われる場合、当該グループ内の別の交換条件がなくなるまで行われ、当該グループ内に交換条件がない場合は、別のグループIDが付与されたグループの中から交換条件を選択し提示するよう構成してもよい。
具体的には、図10における当該交換条件1に付与されたグループID1中の1つまたは複数の交換条件(図11では、グループID1、2ともにそれぞれ3つの交換条件を有する)の中から、1つ又は複数の交換条件を新たにユーザに提示する。どのようなレアアイテムを同一グループに設定するかは、ゲームバランスやユーザのランク、ユーザのアイテム交換回数・履歴、経過時間等様々な観点により適宜決定することができ、特定のレアアイテムのみを対象とするものではない。上記新たな提示及び交換の後において、サーバ側で依然として必要と判断した場合(未だに強化素材の流通量を抑制する場合など)には、上述の方法で更に交換条件を提示するようにしてもよい。このような場合、ユーザのアイテム交換を促すため、交換の回数や時間経過などにより、よりいいレートの交換条件を提示するようにしてもよい。このように、交換条件の提示を複数回に亘って行う(かつ段階的により魅力のあるレートを提示する)ことで、ユーザのアイテム交換(上記例では、強化素材の交換)を促し、ゲーム内でのアイテムの存在量(上記例では、強化素材の存在量)を調整することが可能となる。
一実施形態において、ボックスガチャのような方式で提示されてもよい。具体的には、1つのグループIDのグループの中のどの交換条件を選択するかを抽選により決定してもよいし、どのグループIDを選択するかについても抽選により決定するようにしてもよい。また、複数の交換条件が含まれるデッキ(ボックス)を各ユーザ毎に割り当て、各ユーザ毎の交換条件の提示状況を管理してもよい。例えば、グループID1の中から交換条件1−1が抽選で選ばれたとすると、当該交換条件をユーザに提示するとともに、当該交換条件が提示されたことを示す情報をアイテム交換条件管理テーブル41cに適宜格納してもよい。さらに、新たな交換条件を提示する場合は、同じグループID1のグループの中から別の交換条件が抽選により選択されるように構成されてもよい。新たな交換条件の提示を1又は複数回実施した結果、デッキ(ボックス)に含まれる全ての交換条件が提示・交換されると、別のデッキ(ボックス)が割り当てられ、その中から交換条件が抽選されるように構成されてもよい。例えば、グループID1のグループ内の交換条件が全て提示・交換された場合、グループID2のグループの中から交換条件が抽選により決定されてもよいし、どのグループIDのグループを選択するかについても抽選により決定するように構成されてもよい。
強化素材がゲーム内で過剰に流通している場合、通常のステージ(クエスト)をプレイすることなく、ユーザが新たに入手したキャラクタ(のパラメータ)を強くしたりすることが可能となり、このようなユーザが多くなると、ゲーム全体が一時的若しくは慢性的に不活性な状態になりかねない。また、回復剤がゲーム内で過剰に流通している場合も、無料配布される回復剤を貯めるなどし、これを通常のステージ(クエスト)以外の特別なイベントでのみ使用したりするユーザが増え、当該イベントでのユーザ間の不公平につながるばかりか、ゲーム全体が一時的若しくは慢性的に不活性な状態になりかねない。これに対して、上述した方法によれば、ユーザが保有するアイテムを魅力のあるレアアイテム等と交換する機会を1回ないしは複数回提供することで、ゲーム全体における各種アイテムの存在比率が、特定のアイテムに偏ることを回避ないし低減し、ゲームバランスを適正な水準に保つことを可能とし、引いては、ユーザのゲームへの関心度の維持・向上につながる。
ゲーム進行処理では、次に、図示するように、ユーザによるステージの選択を受け付ける(ステップS100)。一実施形態において、ユーザによるステージの選択は、端末装置30に表示されるステージ選択画面55を介して行われる。図7は、一実施形態におけるステージ選択画面55の一例を示す。ステージ選択画面55は、図示するように、中央にステージ選択領域57が配置されると共に下端に基本メニュ領域100が配置されている。ステージ選択領域57には、ユーザによって選択可能な1又は複数のステージ(図7の例では、ステージ1−3の3つのステージ)が表示され、ユーザは、ステージ選択領域57に表示されているステージの中から所望のステージをプレイするステージとして選択することができる。ユーザによって選択可能なステージは、例えば、ステージをクリアすること等に応じて追加され得る。
ここで、一実施形態のRPGにおいて、各ステージは、シリーズ化しているゲームの複数のシリーズのうちの1つのシリーズに関連付けられており、例えば、関連付けられているシリーズにおいて登場する敵キャラクタが出現するステージとして構成されている。図7に示すように、ステージ選択領域57には、各ステージに関連付けられているシリーズに関する情報が表示されている(例えば、図7の例では、「ステージ1」には「シリーズVII」が関連付けられており、「ステージ2」には「シリーズIV」が関連付けられている)。
一実施形態のRPGにおいては、ステージに加え、上述したように、キャラクタ及び一部のアイテムが同じくシリーズに関連付けられている。そして、プレイするステージに対応するシリーズ(ステージの種類)と同じシリーズに対応するキャラクタ及びアイテムに対して、特定のパラメータの値が向上する特別効果が適用される。他の実施形態のRPGにおいては、これに代えて、又は、これに加えて、ステージに登場する敵キャラクタとシリーズとが関連付けられ得る(この場合、敵キャラクタと、これに対応するシリーズとが情報記憶部41等において記憶され得る)。そして、この他の実施形態においては、対戦する敵キャラクタに対応するシリーズと同じシリーズに対応するキャラクタ及びアイテムに対して、上記特別効果が適用される。
基本メニュ領域100は、「交換」と表示されたアイテム交換条件選択メニュ101と、「ステージ」と表示されたステージ選択メニュ102と、「パーティ」と表示されたパーティ管理メニュ104と、「合成」と表示された合成メニュ106と、「ヘルプ」と表示されたヘルプメニュ108とによって構成されている。「交換」と表示されたアイテム交換条件選択メニュ101を選択すると、アイテム交換選択画面75を表示させることができる。このときの交換条件の表示態様は上述したが、交換条件が提示されない場合には、「交換条件の提示はない」等の表示を行ってもよい。この基本メニュ領域100は、一実施形態におけるRPGをプレイするときの基本となるメニュによって構成されており、ステージ選択画面55以外の主要な画面においても同様に配置されている。
アイテム交換条件選択メニュ101は、ユーザがアイテム交換条件選択画面75を介してアイテム交換条件を選択するためのメニュである。このアイテム交換条件選択は、図5に示すフローの順序に限定されず、当該メニュを選択することにより適宜所望の交換条件を選択するよう構成可能である。また、図5に示すゲーム進行処理の開始前又はゲーム進行処理の終了後においても行い得るよう構成することも可能である。ステージ選択メニュ102は、ユーザがステージ選択画面55を介してステージを選択するためのメニュである。パーティ管理メニュ104は、ユーザがパーティの設定に関する操作を行うためのメニュであり、詳細は後述する。ヘルプメニュ108は、ユーザがゲームの進め方や操作方法等を調べるためのメニュである。
基本メニュ領域100の合成メニュ106は、ユーザが保有する複数のアイテムに含まれる複数のアイテムを合成して1のアイテムのパラメータを強化する合成アクションを実行するためのメニュである。一実施形態において、合成アクションは、保有するアイテムの中から強化する対象となる1のアイテムをユーザが選択し、更に、この1のアイテムの強化のために消費する1又は複数のアイテムをユーザが選択することによって行われる。合成アクションが行われると、強化する対象とされたアイテムのパラメータ(例えば、経験値、レベルの最大値等)が増加すると共に、消費されたアイテムは消滅する。こうした合成アクションに関する処理は、カードゲーム等の技術分野において一般的な処理であるから、これ以上の詳細な説明は省略する。
ユーザは、まず、アイテム交換条件選択画面75を介してアイテム交換条件を選択すると、ユーザによるアイテム交換条件の選択をサーバ10が受け付けし、受領したアイテム交換条件にしたがって、必要な処理実行し、サーバ10の保有アイテム情報管理テーブル41bにおいて、アイテム交換を選択したユーザを識別する「ユーザID」、このユーザが保有するアイテムを識別する「アイテムID」、及びこのユーザがこのアイテムを取得した日時を示す「取得日時」との組合せに対応付けて、交換条件に基づき新規に取得することとなるアイテムの「アイテム名」、「アイテム種別」等の情報が追加されるとともに、交換に供したアイテムの「アイテム名」、「アイテム種別」等の情報が削除される。なお、新規に取得するアイテムの種類により、このアイテムの「経験値」、「レベル」、このアイテムに対応する「シリーズ」、「攻撃力」、「防御力」等の情報が保有アイテム情報管理テーブル41bに適宜追加される。
次に、ユーザがステージ選択画面55を介してステージを選択すると、ユーザによるステージの選択をサーバ10が受け付け、さらに、ユーザによるパーティの設定を受け付ける(ステップS110)。一実施形態において、ユーザによるパーティの設定は、端末装置30に表示されるパーティ管理画面60を介して行われる。図8は、一実施形態におけるパーティ管理画面60の一例を示す。このパーティ管理画面60は、ステージ選択画面55を介してユーザがステージを選択することに応じて表示され、又は、基本メニュ領域100のパーティ管理メニュ104をユーザが選択することに応じて表示される。
パーティ管理画面60は、図示するように、現在のパーティに含まれる複数のキャラクタを表示するパーティ表示領域62と、「編成」と表示された編成ボタン64と、「最強」と表示された最強ボタン66と、「進む」と表示された継続ボタン68と、を有し、更に、下端に上述した基本メニュ領域100が配置されている。
パーティ表示領域62は、現在のパーティに含まれる複数のキャラクタに関する情報を一覧表示し、各々が1つのキャラクタに関する情報を表示する複数(図8の例では5つ)の単位領域62aが縦方向に並べて配置されている。この単位領域62aは、図9に示すように、キャラクタ画像を表示するキャラクタ画像表示領域102を左端に有し、その右側上方にキャラクタの基本情報を表示する基本情報表示領域104、及び、同じく右側下方にキャラクタが装備しているアイテムに関する情報を表示するアイテム情報表示領域105を有する。
キャラクタ画像表示領域102は、図示するように、キャラクタの隊列(前衛/後衛)に応じて、キャラクタ画像が、左側又は右側の何れかにスライドした位置に表示されるように構成されており、例えば、キャラクタの隊列が「前衛」である場合にはキャラクタ画像が左側にスライドした位置に表示され、キャラクタの隊列が「後衛」である場合にはキャラクタ画像が右側にスライドした位置に表示される。基本情報表示領域104は、例えば、キャラクタに対応するシリーズ、キャラクタ名、レベル(現在値/最大値)、HP(最大値)等の情報を表示するように構成されている。これらの情報は、保有キャラクタ情報管理テーブル41aにおいて管理されている。
一実施形態にけるアイテム情報表示領域105は、キャラクタが有する複数のアイテム枠(一実施形態においては5つのアイテム枠)にそれぞれ対応するアイテムオブジェクト106が横方向に一列に配置されており、具体的には、左から順に、武器のアイテム枠に対応する武器オブジェクト106aと、防具のアイテム枠に対応する防具オブジェクト106bと、アクセサリのアイテム枠に対応するアクセサリオブジェクト106cと、アビリティのアイテム枠に対応する2つのアイテムオブジェクトである第1アビリティオブジェクト106d及び第2アビリティオブジェクト106eと、が配置されている。一実施形態において、各アイテムオブジェクト106には、このキャラクタの対応するアイテム枠に設定されているアイテムの画像が表示され、対応するアイテム枠に何れのアイテムも設定されていない場合には、アイテムが設定されていないことを示す画像等が表示される。また、図示するように、アクセサリオブジェクト106cと第1アビリティオブジェクト106dとの間には所定の間隔が設けられている。
ここで、一実施形態のパーティ表示領域62における単位領域62aは、ユーザから、キャラクタの隊列(前衛/後衛)の設定指示、及び、アイテムの設定指示を受け付けるように構成されている。具体的には、ユーザは、キャラクタ画像表示領域102を選択することによって、キャラクタの隊列(前衛/後衛)の変更指示を行うことができ、例えば、前衛から後衛、又は、後衛から前衛へと、キャラクタの隊列が切り替わる。
図8において、ユーザが、パーティ管理画面60の編成ボタン64を選択すると、パーティの編成を行うための図13に例示するパーティ編成画面80が端末装置30上に表示される。一実施形態におけるパーティ編成画面80は、図示するように、現在のパーティに含まれるキャラクタを表示するパーティ表示領域82と、ユーザが保有する残りの(現在のパーティに含まれない待機中の)キャラクタを表示する保有キャラクタ表示領域84と、「確定」と表示された確定ボタン86と、を有する。
パーティ表示領域82、及び、保有キャラクタ表示領域84は、それぞれ、パーティ管理画面60における単位領域62aと同様に構成された複数の単位領域62aが縦方向に並べて配置されている。即ち、パーティ編成画面80における単位領域62aは、キャラクタ画像表示領域102、基本情報表示領域104、及び、アイテム情報表示領域105を有し、キャラクタ画像表示領域102を介してキャラクタの隊列(前衛/後衛)の設定指示を受け付けると共に、アイテム情報表示領域105を介してキャラクタが装備するアイテムの設定指示を受け付けるように構成されている。従って、一実施形態におけるパーティ編成画面80は、現在のパーティに含まれるキャラクタに加えて、現在のパーティに含まれない待機中のキャラクタを対象として、アイテム情報表示領域105のタップ操作及びスワイプ操作に応じたアイテムの設定指示を受け付けるように構成されており、更に、現在のパーティに含まれない待機中のキャラクタを含む複数のキャラクタ間で装備するアイテムを変更できるように構成されている。
ユーザが、パーティ編成画面80のパーティ表示領域82に表示されているキャラクタ、及び、保有キャラクタ表示領域84に表示されているキャラクタの中からそれぞれ1つのキャラクタを選択すると、パーティ表示領域82において選択されたキャラクタがパーティから除外されると共に、保有キャラクタ表示領域84において選択されたキャラクタがパーティに追加される。また、パーティ表示領域82に表示されているキャラクタの中から2つのキャラクタをユーザが選択すると、選択された2つのキャラクタのパーティ内における並び順が入れ替わる。そして、確定ボタン86が選択されて、パーティに含まれるキャラクタ、及び、パーティ設定情報等が変更されると、保有キャラクタ情報管理テーブル41aの対応するキャラクタのパーティ設定情報が更新される。
図9において、ユーザがパーティ管理画面60の最強ボタン66を選択すると、ユーザが保有するキャラクタ、及び、アイテムの中から、パーティ全体のパラメータが最大となるキャラクタ及びアイテムの組合せが自動的に選択されて、現在設定されているパーティに含まれるキャラクタが、自動的に選択されたキャラクタに変更されると共に、変更後のキャラクタ(自動的に選択されたキャラクタ)が装備しているアイテムが、自動的に選択されたアイテムに変更される。パーティに含まれるキャラクタ、及び、変更後のキャラクタが装備しているアイテムが変更されると、保有キャラクタ情報管理テーブル41aの対応する情報が更新される。
ユーザがパーティ管理画面60の続行ボタン68を選択すると、現在設定されているパーティが確定する。なお、ユーザは、ステージ選択画面55を介してステージを選択してパーティ管理画面60が表示された後、パーティの変更をすることなく直ちに続行ボタン68を選択してパーティを確定させることもできる。
図5のフロー図に戻り、こうしてパーティが確定すると、サーバ10は、選択されているステージを進行させて(ステップS120)、このゲーム進行処理を終了する。一実施形態のRPGでは、各ステージは、複数のサブステージによって構成されており、各サブステージにおいて、設定されているパーティと、予め定められている1又は複数の対戦相手キャラクタとの対戦処理が行われる。対戦処理においては、ユーザによるコマンド入力(武器でたたかう、防御する、アイテムを利用する、アビリティを利用する等)に従ってパーティに含まれるプレイヤキャラクタがアクションを実行する。そして、攻撃力及び防御力等のパラメータに応じたダメージを相互に与え、パーティに含まれる全てのキャラクタのHPがゼロとなる前に全ての対戦相手キャラクタを倒すと、次のサブステージに進み、全てのサブステージをクリアするとステージのクリアとなる。
上述した実施形態では、ステージ及びサブステージによって構成されるRPGを例示したが、本発明の実施形態は、様々な態様のゲームに適用することができる。例えば、ユーザによる操作に従ってパーティを仮想空間内で移動させ、遭遇した対戦相手キャラクタとの対戦処理を行う態様のRPGに適用することもできる。更に、本発明の実施形態は、RPGに限られず、複数のアイテムが設定されるキャラクタを用いた様々な態様のゲームに適用され得る。
本明細書で説明された処理及び手順は、実施形態中で明示的に説明されたもの以外にも、ソフトウェア、ハードウェアまたはこれらの任意の組み合わせによって実現される。より具体的には、本明細書で説明される処理及び手順は、集積回路、揮発性メモリ、不揮発性メモリ、磁気ディスク、光ストレージ等の媒体に、当該処理に相当するロジックを実装することによって実現される。また、本明細書で説明される処理及び手順は、それらの処理・手順をコンピュータプログラムとして実装し、各種のコンピュータに実行させることが可能である。
本明細書中で説明される処理及び手順が単一の装置、ソフトウェア、コンポーネント、モジュールによって実行される旨が説明されたとしても、そのような処理または手順は複数の装置、複数のソフトウェア、複数のコンポーネント、及び/又は複数のモジュールによって実行され得る。また、本明細書中で説明されるデータ、テーブル、又はデータベースが単一のメモリに格納される旨説明されたとしても、そのようなデータ、テーブル、又はデータベースは、単一の装置に備えられた複数のメモリまたは複数の装置に分散して配置された複数のメモリに分散して格納され得る。さらに、本明細書において説明されるソフトウェアおよびハードウェアの要素は、それらをより少ない構成要素に統合して、またはより多い構成要素に分解することによって実現することも可能である。
本明細書において、発明の構成要素が単数もしくは複数のいずれか一方として説明された場合、又は、単数もしくは複数のいずれとも限定せずに説明された場合であっても、文脈上別に解すべき場合を除き、当該構成要素は単数又は複数のいずれであってもよい。