JP5901828B1 - 情報処理システム及びプログラム、並びにサーバ - Google Patents

Abstract

【課題】高い表現能力を有すると共に、ゲームの状況に適合したスタンプ等の選択操作による入力を高速に行うこと。【解決手段】プレイヤー端末１−Ｐは、候補スタンプを複数個羅列して表示し、それらの中からプレイヤーにより選択されたものを、他のプレイヤー端末１−Ｑに送信する。サーバ２のスタンプ・メタデータ管理部１８１は、複数の候補スタンプの夫々を、ゲームの所定状況を示すメタデータと対応付けて管理する。スタンプ表示順番決定部１５３は、複数の候補スタンプ毎に夫々対応付けられた複数のメタデータと、ゲームの実行中における現在の状況を示す状況データとの夫々の相関度に基づいて、当該複数のスタンプがプレイヤー端末１−Ｐに表示される際の羅列の順番を制御する。メタデータ更新部１５４は、複数の候補スタンプ毎のメタデータの内容を、プレイヤーの送信対象の選択結果に基づいて更新する。【選択図】図４

Description

本発明は、情報処理システム及びプログラム、並びにサーバに関する。

従来から、スマートフォン等の端末で実行可能なゲームとして、マルチバトル等複数のプレイヤーが参加可能なゲームが存在する。
このようなゲームの実行中に、複数のプレイヤー間でコミュニケーションを図る機能が設けられている場合が多い（例えば特許文献１乃至３参照）。

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

しかしながら、従来のゲームの多くでは、複数のプレイヤー間でコミュニケーションを図る機能として、フリーテキストのチャット機能が採用されているが、スマートフォンのソフトウェアキーボードを用いた文字列の入力は、マルチバトル等のゲームの進行速度との比較において低速であり、複数のプレイヤー間でコミュニケーションの円滑化が妨げられてしまう。

そこで、入力速度を高めるべく、フリーテキストの代わりに、タップ操作等ごく短時間で容易な操作のみで入力可能となる、固定的なスタンプや定型文を送受信する手法も考えられる。
しかしながら、従来においては、ゲームで用意されているスタンプ等の種類数は非常に少なく、かつ、大量のスタンプを制御するための仕組みを有さないため、固定的なスタンプや定型文を送受信する手法では、プレイヤー間において伝達可能なメッセージの種類は極めて限定されるため、複数のプレイヤー間でコミュニケーションを図るという観点では不適である。

そこで、高い表現能力を得るためには、スタンプ等の種類数を増加させる必要がある。
しかしながら、スタンプ等の種類数が増加した場合、プレイヤーにとって、多数種類のスタンプ等の中から、ゲームの現状況に適したスタンプ等を見付けだすことは困難であり、見付けだす迄に長時間を要する場合がある。
即ち、プレイヤーが送信対象のスタンプ等を見付けだした後は、スタンプの送信までは、タップ操作等ごく短時間で容易な操作をするだけで、当該スタンプ等は送信されることになるが、当該スタンプ等を見付け出すまでに時間を要することになるため、トータルの入力速度は高速であるとは言い難い。この程度の入力速度では、未だマルチバトル等のゲームの速いテンポに付いていけず、複数のプレイヤー間でコミュニケーションの円滑化が妨げられてしまう。

従って、スタンプ等の種類数を増加させる場合には、ゲームの状況に適合したスタンプ等の選択操作による入力が高速になるための仕組みが必要になる。
このような仕組み自体は、上述の特許文献１乃至３等を含め従来においても存在するが、何れも、予め決定された所定のパターンに従って動作する静的なものである。
しかしながら、マルチバトル等のゲームは時々刻々と状況が変化していくため、このような静的な従来の仕組みを採用しても、ゲームの状況に適合したスタンプ等の選択操作による入力を高速に行うことは困難である。

このように、ゲームの実行中に複数のプレイヤー間でコミュニケーションを図る機能として、スタンプ等を送受信する機能であって、高い表現能力を有すると共に、ゲームの状況に適合したスタンプ等の選択操作による入力を高速に行うことが可能な機能の確立が要求されている。
しかしながら、従来においては、特許文献１乃至３を含め、このような機能を確立することは非常に困難である。

本発明は、ゲームの実行中に複数のプレイヤー間でコミュニケーションを図る機能として、スタンプ等を送受信する機能であって、高い表現能力を有すると共に、ゲームの状況に適合したスタンプ等の選択操作による入力を高速に行うことが可能な機能を確立することを目的とする。

上記目的を達成するため、本発明の一態様の情報処理システムは、
複数のプレイヤーの夫々の操作を受付けてゲームを実行し得る複数の端末と、サーバとを含む情報処理システムにおいて、
前記複数の端末の夫々は、
所定のコードに対応付けられた、文字、図形、記号、又はこれらの結合からなるシンボルを、他の端末に送信し得る候補シンボルとして複数個羅列して表示する制御を実行する表示制御手段と、
複数の前記候補シンボルの中から前記プレイヤーにより選択されたものを送信対象として、当該送信対象に対応付けられた前記コードを他の端末に送信する制御を実行する送信制御手段と、
を備え、
前記端末又は前記サーバは、
複数の前記候補シンボルの夫々を、前記ゲームの所定状況を示すメタデータと対応付けて管理する管理手段と、
前記管理手段により管理されている前記複数の候補シンボル毎に夫々対応付けられた複数の前記メタデータと、前記ゲームの実行中における現在の状況を示す状況データとの夫々の相関度に基づいて、当該複数の候補シンボルが前記表示制御手段の制御により表示される際の羅列の順番を制御する羅列順番制御手段と、
前記管理手段により管理されている前記複数の候補シンボル毎の前記メタデータの内容を、前記プレイヤーの送信対象の選択結果に基づいて更新する更新手段と、
を備える。

本発明によれば、ゲームの実行中に複数のプレイヤー間でコミュニケーションを図る機能として、スタンプ等を送受信する機能であって、従来技術との比較において膨大な数のスタンプを用意することによる高い表現能力を有すると共に、ゲームの状況に適合したスタンプ等の選択操作による入力を高速に行うことが可能な機能を確立することができる。

本発明の一実施形態に係る情報システムの構成を示すブロック図である。 図１の情報処理システムのうち、本発明の一実施形態のプレイヤー端末のハードウェア構成を示すブロック図である。 図１の情報処理システムのうち、本発明の一実施形態のハードウェア構成を示すブロック図である。 図２のプレイヤー端末及び図３のサーバの機能的構成例を示す機能ブロック図である。 ゲームの実行中にプレイヤー端末に表示される画面の例を示している。 ゲームの実行中にプレイヤー端末に表示されるスタンプ画面の一例であって、図５の例とは異なる例を示している。 多次元ベクトル空間モデルを用いた、スタンプのメタデータとゲームの状況データとの相関度の演算手法を説明する図である。 個人化されたメタデータの生成手法の一例を説明する図である。 図３のサーバが実行するスタンプ処理の流れを説明するフローチャートである。

以下、本発明の実施形態について、図面を用いて説明する。

なお、以下において、単に「画像」と呼ぶ場合には、「動画像」と「静止画像」との両方を含むものとする。
また、「動画像」には、次の第１処理乃至第３処理の夫々により表示される画像を含むものとする。
第１処理とは、平面画像（２Ｄ画像）におけるオブジェクト（例えばゲームキャラクタ）の夫々の動作に対して、複数枚からなる一連の静止画像を時間経過と共に連続的に切り替えて表示させる処理をいう。具体的には例えば、２次元アニメーション、いわゆるパラパラ漫画的な処理が第１処理に該当する。
第２処理とは、立体画像（３Ｄモデルの画像）におけるオブジェクト（例えばゲームキャラクタ）の夫々の動作に対応するモーションを設定しておき、時間経過と共に当該モーションを変化させて表示させる処理をいう。具体的には例えば、３次元アニメーションが第２処理に該当する。
第３処理とは、オブジェクト（例えばゲームキャラクタ）の夫々の動作に対応した映像（即ち動画）を準備しておき、時間経過と共に当該映像を流していく処理をいう。

図１は、本発明の一実施形態に係る情報処理システムの構成を示している。
図１に示す情報処理システムは、ｍ人（ｍは１以上の任意の整数値）のプレイヤーの夫々により使用されるプレイヤー端末１−１乃至１−ｍと、サーバ２とを含むシステムである。プレイヤー端末１−１乃至１−ｍの夫々と、サーバ２とは、インターネット等の所定のネットワークＮを介して相互に接続されている。

サーバ２は、プレイヤー端末１−１乃至１−ｍの夫々に対してゲームの実行環境を提供し、プレイヤー端末１−１乃至１−ｍの夫々において実行されるゲームに関する各種各様のサービスを提供する。

このようなサービスの１つとして、本実施形態では、ゲームの実行中に、プレイヤー端末１−１乃至１−ｍの夫々の間で、換言すると各プレイヤー間で各種情報の授受を可能とする。ここで、授受の対象となる情報は、プレイヤーが手動入力したテキストでもよいが、ゲームの実行中にテキストを入力することがゲームのスムーズな進行を妨げたり、プレイヤーのゲーム操作の邪魔になる場合が多い。
そこで、本実施形態では、授受の対象となる情報として、１回のタップ等簡単な操作で送信が可能になるスタンプが採用されている。

なお、以下、プレイヤー端末１−１乃至１−ｍの夫々を個々に区別する必要がない場合、これらをまとめて「プレイヤー端末１」と呼ぶ。

図２は、図１の情報処理システムのうち、本発明の一実施形態に係るプレイヤー端末１のハードウェア構成を示すブロック図である。

プレイヤー端末１は、スマートフォン等で構成される。
プレイヤー端末１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２３と、バス２４と、入出力インターフェース２５と、タッチ操作入力部２６と、表示部２７と、入力部２８と、記憶部２９と、通信部３０と、ドライブ３１と、を備えている。

ＣＰＵ２１は、ＲＯＭ２２に記録されているプログラム、又は、記憶部２９からＲＡＭ２３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ２３には、ＣＰＵ２１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ２１、ＲＯＭ２２及びＲＡＭ２３は、バス２４を介して相互に接続されている。このバス２４にはまた、入出力インターフェース２５も接続されている。入出力インターフェース２５には、タッチ操作入力部２６、表示部２７、入力部２８、記憶部２９、通信部３０及びドライブ３１が接続されている。

タッチ操作入力部２６は、例えば表示部２７の表示面に積層される静電容量式又は抵抗膜式（感圧式）の位置入力センサにより構成され、タッチ操作がなされた位置の座標を検出する。
ここで、タッチ操作とは、タッチ操作入力部２６に対する物体の接触又は近接の操作をいう。タッチ操作入力部２６に対して接触又は近接する物体は、例えばプレイヤーの指やタッチペン等である。なお、以下、タッチ操作がなされた位置を「タッチ位置」と呼び、タッチ位置の座標を「タッチ座標」と呼ぶ。
表示部２７は、液晶等のディスプレイにより構成され、ゲームに関する画像等、各種画像を表示する。
このように、本実施形態では、タッチ操作入力部２６と表示部２７とにより、タッチパネルが構成されている。

入力部２８は、各種ハードウェア釦等で構成され、プレイヤーの指示操作に応じて各種情報を入力する。
記憶部２９は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部３０は、インターネットを含むネットワークＮを介して他の装置（図１の例ではサーバ２や他のプレイヤー端末１）との間で行う通信を制御する。

ドライブ３１は、必要に応じて設けられる。ドライブ３１には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア４１が適宜装着される。ドライブ３１によってリムーバブルメディア４１から読み出されたプログラムは、必要に応じて記憶部２９にインストールされる。また、リムーバブルメディア４１は、記憶部２９に記憶されている各種データも、記憶部２９と同様に記憶することができる。

図３は、図１の情報処理システムのうち、本発明の一実施形態に係るサーバ２のハードウェア構成を示すブロック図である。

サーバ２は、ＣＰＵ５１と、ＲＯＭ５２と、ＲＡＭ５３と、バス５４と、入出力インターフェース５５と、出力部５６と、入力部５７と、記憶部５８と、通信部５９と、ドライブ６０とを備えている。
サーバ２の構成は、プレイヤー端末１のタッチパネルを除いた構成と基本的に同様であるので、ここではその説明は省略する。

このような図２のプレイヤー端末１及び図３のサーバ２の各種ハードウェアと各種ソフトウェアとの協働により、プレイヤー端末１でゲームの実行が可能になる。ここで、本実施形態では、マルチバトル等の複数のプレイヤーが参加するゲームが対象である。このため、プレイヤー端末１及び図３のサーバ２の各種ハードウェアと各種ソフトウェアとの協働により、さらに、当該ゲームに参加している複数のプレイヤー間でスタンプの授受が可能になる。

つまり、マルチバトル等の複数のプレイヤーが参加するゲームにおいては、複数のプレイヤーが協力して所定のタスク（例えば敵を倒す等）を実行するとき等に、当該複数のプレイヤー間でコミュニケーションを図ることができると好適である。
このようなコミュニケーションを図る従来の手法として、フリーテキストのチャット機能を利用する手法が広く知られている。
しかしながら、マルチバトルは、リアルタイムに状況が逐次変化し、非常にテンポ（ゲームの進行速度）が速い。従って、複数のプレイヤー間でコミュニケーションを図る手法としては、このような速いテンポにあわせて、現状況で求められている情報を他のプレイヤーに伝達可能とすることが要求される。従来のフリーテキストのチャット機能を利用する手法では、テキスト入力の操作に長時間を要するため、このような要求に応えることは非常に困難である。
この点、スタンプの送信機能を利用する手法は、例えば１回のタップ操作でスタンプの送信が可能になる手法であるため、従来のフリーテキストのチャット機能を利用した場合と比較するならば、リアルタイムに状況が変化するマルチバトルに対して適合可能な手法であるといえる。

ただし、スタンプの送信機能を利用する手法を単に採用しただけで、マルチバトルに常に適合するかというと、そうとは言い切れない。
例えば、プレイヤーが送信対象のスタンプを見付け出すまでに長時間を要すると、リアルタイムに状況が変化するマルチバトルの速いテンポについていけないことになる。
ここで、送信候補のスタンプの種類数が少なければ、プレイヤーが所望のスタンプを見付け出すまでの時間は自ずと短時間になるため、マルチバトルの速いテンポに十分についていくことができる。
しかしながら、フリーテキストを使わずにスタンプのみでコミュニケーションを図ることを考慮すると、各種状況に適合可能となるように多数の種類のスタンプを用意しておく必要がある。
多数のスタンプを予め決められた固定的な順序で羅列して端末に表示してしまうと、プレイヤーは、所望のスタンプをその都度目視で見付け出さなければならない。従って、所望のスタンプを見付け出して送信を指示する操作（１回のタップ操作）の実行までに長時間を要する可能性が高く、マルチバトルの速いテンポに付いていくことが非常に困難になる。

このような点を解消する従来の手法として、スタンプを選択するリストを手動で並び替える手法や、予め用意されたプレースホルダに対して所望のスタンプを挿入する操作をプレイヤーが行う手法を採用することもできる。
しかしながら、これらの従来の手法では、マルチバトルの状況の変化に応じてリアルタイムに、各状況に適切なスタンプを提示することは困難である。特に、ＲＰＧのジャンルでは、その困難性は顕著なものとなる。ＲＰＧのジャンルでは、登場する敵の特徴に応じて様々な戦術を採る必要があるところ、とある時点に採られた戦術に対して適合するスタンプを、当該時点よりも時間的に前に予め予測して用意しておくことは非常に困難だからである。

以上まとめると、このようにリアルタイムに状況が変化するマルチバトルに対して好適な複数のプレイヤー間のコミュニケーションを図る手法として、スタンプの送信機能を利用する手法を採用する場合、プレイヤーが多様な状況に応じてスタンプを高速に選択できる必要がある。
具体的には、プレイヤーが多様な状況に応じてスタンプを高速に選択できるようにするためには、次の３つの課題を解決する必要がある。

第１の課題は、マルチバトルの多様な状況に対応するのに必要十分な種類数のスタンプを提供可能とすることである。
近年のマルチバトルでは、プレイヤーの自由度は極めて高く、様々なキャラクタの組み合わせで戦闘に臨み、かつ、それらのキャラクタ達の行動の組み合わせによってマルチバトルの状況が大きく変化する。
なお、ここで、マルチバトルの状況とは、例えばＲＰＧのジャンルでは、敵キャラクタのＨＰや強化又は弱体化等のステータスや、味方キャラクタのＨＰや強化又は弱体化等のステータスのことをいう。
このように、マルチバトルは、極めて多様な状況が存在し、その状況もリアルタイムに変化していく。従って、スタンプは、このような多様な各状況の夫々に対応する、必要十分な数の種類が必要になる。

このような第１の課題が解決できたとしても、即ち、マルチバトルの多様な状況に対応するのに必要十分な種類数のスタンプを提供できたとしても、現状況に適合するスタンプをプレイヤーが素早く選択できなければ、マルチバトルの多様な状況に対応できているとは言い難い。
現状況に適合するスタンプをプレイヤーが素早く選択できるようにするためには、現状況に適合するスタンプをシステム側からプレイヤーに推薦等できると好適である。
そこで、第２の課題として、マルチバトルにおいて刻々と変化する状況と、スタンプとの関連性を動的に計算できることが挙げられる。
マルチバトルでは、ゲームの状況は刻々と変化する上、状況を構成する要素の組み合わせは膨大であり、それらの状況を予測して定義しておくことは非常に困難である。
また、このようなゲームでは、日々拡張と改善のためのアップデートが行われており、マルチバトルにおいて発生する状況は、常に変化している。このアップデートに追随して、スタンプとバトル状況との関係を、静的に人手で定義することは現実的ではない。

このような第２の課題が解決できて、現状況に適合するスタンプをシステム側からプレイヤーに推薦等ができたとしても、「現状況に適合する」と判断した主体はあくまでもサーバ２側であって、プレイヤーが判断したわけではない。従って、推薦等されたスタンプがプレイヤーの全てにとって適合する（所望のスタンプとして受け入れられる）とは限らない。
そこで、第３の課題として、個人化（パーソナライズ）できることが挙げられる。
即ち、スタンプの選択は、プレイヤー個人の嗜好が強く反映されるものであるため、マルチバトルの状況とスタンプとの関連性の演算において、各プレイヤーの夫々の個人差を反映することが必要である。

本実施形態の情報処理システムは、このような第１乃至第３の課題を解決可能なユーザインタフェースを実現可能なシステムである。即ち、本実施形態の情報処理システムは、マルチバトルの多様な状況に対応可能となる膨大な数のスタンプ（第１の課題を解決した状況）の中から、プレイヤーが直観的かつ容易にスタンプを選択できるユーザインターフェイスを実現する。
具体的には、本実施形態の情報処理システムは、マルチバトルにおけるゲームの状況変化に応じて、使用される可能性が高い順にスタンプをリアルタイムに並び替え続ける機能と、プレイヤーが実際に選択したスタンプの情報をフィードバックすることにより、ゲーム内の状況とスタンプとの関連性を自律的に学習する機能と、を実現する。
これらの機能は、スタンプに紐付けられたメタデータと、ゲーム内において刻々と変化する状況を示すメタデータ（以下、「状況データ」と呼ぶ）との関連性を、プレイヤー毎の個人差を反映し動的に演算する仕組み（第２の課題及び第３の課題を解決する仕組み）により実現される。
本実施形態の情報処理システムがこのような機能を発揮させる処理を、以下、「スタンプ処理」と呼ぶ。
図４は、プレイヤー端末１とサーバ２の機能的構成のうち、スタンプ処理の実行時の機能的構成を示す機能ブロック図である。

図４において、プレイヤー端末１−Ｐは、プレイヤー端末１−１乃至１−ｍのうち、スタンプを送信する側の端末を示している。プレイヤー端末１−Ｑは、プレイヤー端末１−１乃至１−ｍのうち、スタンプを受信する側の端末を示している。即ち、プレイヤー端末１−１乃至１−ｍの夫々は、スタンプの送受信機能を有しているため、プレイヤー端末１−Ｐにもなるし、プレイヤー端末１−Ｑにもなる。

プレイヤー端末１−ＰのＣＰＵ２１においては、コマンド発行部１０１と、表示制御部１０２と、送信スタンプ受付部１０３と、スタンプ送信制御部１０４と、更新有無決定部１０５と、が機能する。
サーバ２のＣＰＵ５１においては、ゲーム状況管理部１５１と、状況データ取得部１５２と、スタンプ表示順番決定部１５３と、メタデータ更新部１５４と、初期メタデータ作成部１５５と、が機能する。
サーバ２の記憶部５８の一領域には、スタンプＤＢ１７１と、プレイヤー毎ＤＢ１７２と、初期値ＤＢ１７３と、ゲーム状況ＤＢ１７４とが設けられる。なお、プレイヤー毎ＤＢ１７２と、初期値ＤＢ１７３とにより、スタンプ・メタデータ管理部１８１が構成される。

プレイヤー端末１−Ｐのコマンド発行部１０１は、プレイヤーによるタッチ操作入力部２６へのタッチ操作に基づいて、ゲームで用いられる各種コマンドを発行する。
当該コマンド発行部１０１は、図示はしないが、プレイヤー端末１−Ｑ側（プレイヤー端末１−１乃至１−ｍの全て）においても機能する。
サーバ２のゲーム状況管理部１５１は、プレイヤー端末１−Ｐ，１−Ｑ（プレイヤー端末１−１乃至１−ｍの全て）の夫々から発行されたコマンド等に基づいて、ゲームの状況の変化を逐次管理し、リアルタイムに変化するゲームの状況データをゲーム状況ＤＢ１７４に格納する。

なお、ゲーム状況ＤＢ１７４は、本実施形態ではサーバ２の一構成要素とされたが特にこれに限定されない。
例えばゲーム状況ＤＢ１７４は、既存のソーシャルゲームが有するデータベースサーバ内に設けられてもよい。また例えば、負荷分散のために、ゲーム用のサーバ２から直接アクセスされるマスターデータベースを用いずに、マスターデータベースから定期的にコピーされるレプリケーションサーバ内に、ゲーム状況ＤＢ１７４が設けられてもよい。

プレイヤー端末１−Ｐの表示制御部１０２は、スタンプ表示制御部１１１と、ゲーム画面表示制御部１１２とを含む。
スタンプ表示制御部１１１は、プレイヤー端末１−Ｑに送信し得るスタンプ（以下、「候補スタンプ」と呼ぶ）を複数個羅列して表示部２７に表示させる制御を実行する。
ゲーム画面表示制御部１１２は、ゲーム画面を表示部２７に表示させる制御を実行する。

図５は、ゲームの実行中にプレイヤー端末１−Ｐに表示される画面の例を示している。
図５（Ａ）は、ゲーム画面３０１の例を示している。
図５（Ｂ）は、ゲーム画面３０１に重畳される、スタンプ選択画面３０２の例を示している。
スタンプ選択画面３０２には、プレイヤーが選択可能な候補スタンプ３１０が複数個（図５（Ｂ）の例では６個）羅列されて表示される。

ここで、図５（Ｂ）のスタンプ選択画面３０２において表示される候補スタンプ３１０の種類や羅列の順番は、従来のように予め固定されたものではなく、図５（Ａ）のゲーム画面３０１に表示されるゲームの状況に応じて動的に変化する。

具体的には例えば、図５（Ａ）のゲーム画面３０１に示す様に、マルチバトルにおいて強大な敵Ｅｎと、複数人のプレイヤーが戦闘を行っているものとする。
なお、図５（Ａ）の例では、１人のプレイヤーは、プレイヤー端末１−Ｐを操作して、４人の味方キャラクタＣ１乃至Ｃ４を操作しており、プレイヤー端末１−Ｑ等を操作する他のプレイヤーのキャラクタはゲーム画面３０１上には表示されていない。
この戦闘において、例えば、敵Ｅｎからの攻撃により、プレイヤー端末１−Ｐのプレイヤーの味方キャラクターＣ１が大ダメージを受けたものとする。

この場合のゲームの状況は、味方キャラクターＣ１のＨＰが低い状況（瀕死の状況）である。このような状況は、図４のサーバ２のゲーム状況管理部１５１により管理され、ゲーム状況ＤＢ１７４に格納される。ここで、ゲームの状況は逐次変化するので、ゲーム状況ＤＢ１７４の格納内容はリアルタイムに更新される。
状況データ取得部１５２は、ゲーム状況ＤＢ１７４の格納内容を、状況データの形態で取得して、スタンプ表示順番決定部１５３に提供する。
具体的には例えば、図５の例では、ゲーム状況ＤＢ１７４の格納内容は、味方のＨＰが低いというゲームの状況である。この場合、状況データ取得部１５２は、味方のＨＰが低いというゲームの状況を多次元ベクトル空間へ写像したデータを、状況データとして生成して、スタンプ表示順番決定部１５３に提供する。

一方、サーバ２が提供可能な各スタンプには、当該スタンプに適合する状況を多次元ベクトル空間へ予め写像したデータが、メタデータとして付与されている。
このような各スタンプとメタデータとの対応付けの管理は、スタンプ・メタデータ管理部１８１によってなされている。例えば、回復を求めるスタンプや自分がダメージを受けたことを仲間に伝えるスタンプに対しては、味方のＨＰが低いというゲームの状況と同一又は類似の状況が多次元ベクトル空間へ予め写像したデータがメタデータとして付与されている。

このとき、スタンプ表示順番決定部１５３は、スタンプ・メタデータ管理部１８１により管理されている複数のスタンプ毎に夫々対応付けられた複数のメタデータと、ゲームの現在の状況を示す状況データとの夫々の相関度に基づいて、当該複数のスタンプがプレイヤー端末１−Ｐにおいて夫々表示される際の羅列の順番を決定する。
図５の例では、ゲームの現在の状況を示す状況データとは、上述した様に味方のＨＰが低い状況を示す状況データである。
従って、当該状況データは、味方のＨＰが低い状況と同一又は類似の状況を示すメタデータと相関度が高くなる。このような高い相関度を有するメタデータに紐付けられたスタンプ、即ち回復を求めるスタンプや自分がダメージを受けたことを仲間に伝えるスタンプが、羅列の順番の上位となるように決定される。その結果、プレイヤー端末１−Ｐにおいては、図５（Ｂ）のスタンプ選択画面３０２が表示される。

図６は、ゲームの実行中にプレイヤー端末１−Ｐに表示されるスタンプ画面の一例であって、図５の例とは異なる例を示している。
図６（Ａ）は、スタンプ３１０Ｄの羅列の順番が固定となっている従来のスタンプ画面３０２Ｄ、即ち静的なスタンプリストからなる従来のスタンプ画面３０２Ｄの一例を示している。
図６（Ｂ）は、ゲームの状況に応じて候補スタンプ３１０Ｓの羅列の順番が変化するスタンプ画面３０２Ｓ、即ち本発明が適用される動的なスタンプリストからなるスタンプ画面３０２Ｓの一例を示している。
ここで、図６（Ａ）の従来のスタンプ画面３０２Ｄと、図６（Ｂ）の本発明が適用されるスタンプ画面３０２Ｓとは別個独立したものではなく、共存させることができる。即ち、プレイヤーが所定のタッチ操作をすることで、図６（Ａ）の従来のスタンプ画面３０２Ｄと、図６（Ｂ）の本発明が適用されるスタンプ画面３０２Ｓとのうち一方から他方へのページ切替が行われる。
図６（Ｃ）は、スタンプ３１０Ｄの羅列の順番が固定となっている従来のスタンプリストと、ゲームの状況に応じて候補スタンプ３１０Ｓの羅列の順番が変化する、本発明が適用されるスタンプリストとを区分けして同時に表示するスタンプ画面３０２Ｔを示している。
このように、従来の静的なスタンプリストと、本発明が適用される動的なスタンプリストは共存が可能であり、その共存の手法は特に限定されず、図６（Ａ）と図６（Ｂ）に示す様にページ切替により共存させる手法を採用してもよいし、図６（Ｃ）に示す様に同一画面に共存させる手法を採用してもよい。

ここで、このような本発明が適用される動的なスタンプリストにおいて、候補スタンプの羅列の順番を動的に変化させる処理は、サーバ２側のスタンプ表示順番決定部１５３（図４）により実行される。
そこで以下、スタンプ表示順番決定部１５３のさらなる機能の詳細について、図７を参照して説明する。
図７は、多次元ベクトル空間モデルを用いた、スタンプのメタデータとゲームの状況データとの相関度の演算手法を説明する図である。
本実施形態では、ゲームの状況を示す状況データ４０１と、スタンプＤＢ１７１に格納されている所定のスタンプ４０２に対応付けられたメタデータ４０３との相関度は、図７に示す様に、多次元ベクトル空間上に夫々射影されたベクトルＡとベクトルＢとの間の距離として表される。当該距離の計量手法は特に限定されないが、例えばベクトル間の内積やコサイン尺度を用いる手法を採用することができる。

このような多次元ベクトル空間上に射影されたベクトルを、以下、「メタデータベクトルＭ」と呼ぶ。
ゲームの状況を示す状況データと、スタンプに紐づけられたメタデータとの両方を、同一構造のメタデータベクトルＭとして表現することにより、両者の多次元ベクトル空間上での比較が可能になる。これにより、絶え間ないマルチバトルの状況変化に対してリアルタイムに反応して、相関度の高いスタンプを推薦すること（羅列の順番として上位にすること）が可能になる。
メタデータベクトルＭを構成する各要素は、プレイヤーや敵のレベルやＨＰ／ＭＰ等の各種パラメタ、所有アイテム、所有スキル等のゲーム内の各属性情報の値である。

具体的には、メタデータベクトルＭは、次の式（１）に示す様に定義される。

・・・（１）
ここで、ｆｉは、プレイヤーのゲーム内の属性情報のうち、ｉ番目の属性に対応する０乃至１の実数を示す。これらのｆｉの値は、無限大ノルム正規化が行われていることが好ましい。例えば、最大レベルが１００のゲームでは、レベルの値を最大値で正規化することにより、レベル１を０．０１とし、レベル１００を１とするようにｆｉを表現することができる。
また、アイテムの所有数をｆｉの値で表現するときは、所有可能な最大値で正規化することができる。
属性の数ｎは、ゲーム内容に応じて、数百乃至数千になる場合がある。例えば、ゲーム内に５００種類のアイテムがあり、スキルが５００種類あるとき、属性の数ｎは少なくとも１０００以上となる。

つまり、ゲームの状況を示す状況データ４０１は、メタデータベクトルＭの構造を有するベクトルＡとして表されると共に、スタンプ４０２に対応付けられたメタデータ４０３は、メタデータベクトルＭの同一構造を有するベクトルＢとして表される。
ここで、ゲームの状況を示す状況データ４０１を示すベクトルＡを「ａ」と記述し、スタンプ４０２に対応付けられたメタデータ４０３を示すベクトルＢを「ｂ」と記述するとき、ａとｂの相関量を示すスコアｓｃｏｒｅ（ａ，ｂ）は、次の式（２）に示す様に定義することができる。

・・・（２）
ここで、ａｉは、ゲームの状況を示すｎ次元のベクトル空間上のｉ番目の属性の重み（０乃至１の実数）である。ｂｉは、スタンプの特徴（適合するゲームの所定状況）を示すｎ次元のベクトル空間上のｉ番目の属性の重み（０乃至１の実数）である。

図４のスタンプ表示順番決定部１５３のうちスコア算出部１６１は、所定のゲームの状況を示すベクトルａと、スタンプＤＢ１７１に格納されている各スタンプの特徴を示す各ベクトルｂとの夫々について、スコアｓｃｏｒｅ（ａ，ｂ）を夫々算出する。
スコアｓｃｏｒｅ（ａ，ｂ）が高い値を持つスタンプほど、ゲームの現状況に適合することとなる。そこで、スタンプ表示順番決定部１５３のうち順番決定部１６２は、各スタンプの夫々のスコアｓｃｏｒｅ（ａ，ｂ）に従って、プレイヤー端末１−Ｐにおいて表示する際の各スタンプの羅列の順番を夫々決定する。

このようにして、プレイヤー端末１−Ｐにおいては、ゲームの現状況に適合する順に、各候補スタンプが羅列されて表示される。従って、プレイヤーは、羅列の順番が上位の候補スタンプを選択する操作（例えば、当該候補スタンプに対して１回タップする操作）をするだけで、ゲームの現状況に適合するスタンプがプレイヤー端末１−Ｐからプレイヤー端末１−Ｑに送信される。
つまり、図４の送信スタンプ受付部１０３は、タッチ操作入力部２６に対するタッチ操作により選択された候補スタンプを、送信対象のスタンプ（以下、「送信スタンプ」と呼ぶ）として受け付ける。
スタンプ送信制御部１０４は、送信スタンプをプレイヤー端末１−Ｑに送信する制御を実行する。

ここで、送信スタンプを送信するとは、送信スタンプの画像データを送信するのではなく、送信スタンプに予め対応付けられたコードの情報を送信するという意である。
これにより、例えばゲームのグローバル展開の支援に繋げることができる。
即ち、１つのゲームタイトルに対して、異なる言語を話すプレイヤーが混在して参加する状況が考えられる。
スタンプは、潜在的には多言語化に非常に適したコミュニケーションツールである。例えば、「Ｈｅａｌ ｍｅ ｐｌｅａｓｅ」という意味のスタンプに対してグローバルに共通のコード（例えば、ＳＴＡＭＰ００００１）を割り当てることで、日本語版のプレイヤー端末１では「ヒール、プリーズ」という日本語を含むスタンプを表示させ、中国語版のプレイヤー端末１では「請医治我」という日本語を含むスタンプを表示させることができる。
このように、スタンプに対してコードを予め対応付けることで、多言語化に対応させたスタンプを実現化することができる。これにより、メッセージを受け取るクライアント（プレイヤー端末１）の言語環境に応じてローカライズされたスタンプを表示させることが可能になる。つまり、実質的に多言語でのコミュニケーションをリアルタイムに行うことが可能となる。
なお、このような多言語コミュニケーションを実現するためには、必然的に、多数種類のスタンプを用意する必要が生じる。従って、多数種類のスタンプの中から、プレイヤーが直感的かつ高速に目的のスタンプを選択するためには、従来のように固定された静的なスタンプの配置では対応できず、本実施形態のようにゲームの状況に応じて動的にスタンプの配置を変化させる必要がある。

次に、スタンプに紐付けられるメタデータの個人化の必要性について詳しく説明する。

本実施形態では、上述した様に、ゲームの現状況に適合したスタンプがプレイヤーに推薦される（羅列の順番が上位として表示される）。しかしながら、プレイヤーの中には、推薦されたスタンプ（以下、「推薦スタンプ」と呼ぶ）を選択せずに、別のスタンプを選択するものも存在する。
これは、当該プレイヤーにとっては、推薦スタンプよりも、自身で選択した別のスタンプの方が、ゲームの現状況に適合すると判断したことを意味する。
即ち、ゲームの現状況に適合するスタンプとは、全てのプレイヤーにとって一律ではなく、各プレイヤー毎に異なる場合が多い。

ここで、推薦スタンプとは、ゲームの現状況を示す状況データと同一又は類似のメタデータと紐付けられたスタンプである。
つまり、推薦スタンプのメタデータとは、当該推薦スタンプに対してゲームの所定状況が適合すると「とある主体」が判断して生成された、当該所定状況を示すメタデータである。そして、当該所定状況がゲームの現状況と同一又は類似であったことから、当該所定状況を示す当該メタデータが紐付けられたスタンプが、推薦スタンプとしてプレイヤーに提示されたのである。
この場合の「とある主体」は、推薦の当初は、ゲームの運営者やサーバ２であることが多い。つまり、サーバ２側が、推薦スタンプと当該所定状況（ゲームの現状況と同一又は類似の状況）とが「適合する」と判断したものである。

しかしながら、同一のスタンプであっても、それから受け取る印象は各プレイヤーにとってまちまちである。従って、サーバ２側で「ゲームの現状況に適合する」と判断された推薦スタンプであっても、とあるプレイヤーにとっては「ゲームの現状況に適合する」と受け取られない場合がある。
つまり、プレイヤーの中には、「ゲームの現状況に適合する」とサーバ２側で判断された推薦スタンプを選択せずに、自身が「ゲームの現状況に適合する」と判断した別のスタンプを選択する者もいる。この場合、当該プレイヤーは、推薦スタンプは「ゲームの現状況に適合する」ものではなく、自己が選択した違うスタンプの方が「ゲームの現状況に適合する」と判断した、と把握することができる。

そこで、メタデータ更新部１５４は、スタンプＤＢ１７１に格納されている各スタンプ毎のメタデータの内容を、送信対象となるメタデータをプレイヤー選択した結果に基づいて更新することで、メタデータの個人化（当該プレイヤー専用のメタデータの生成）を行う。
更新の有無は、プレイヤー端末１−Ｐ側の更新有無決定部１０５において決定される。

例えば、更新有無決定部１０５は、候補スタンプが羅列されたリストの中で上位に羅列されたスタンプ（サーバ２側で推薦されたスタンプ）をプレイヤーが選択した場合、メタデータを更新しないと決定する。
これに対して、更新有無決定部１０５は、候補スタンプが羅列されたリストの中で中位乃至下位のスタンプが選択された場合、メタデータの更新をすると決定する。
この場合、サーバ２側のメタデータ更新部１５４は、例えば、ゲームの現状況を示すメタデータ（サーバ２側で推薦したもののプレイヤーに選択されなかった第１スタンプのメタデータ）と、プレイヤーにより選択された第２スタンプのメタデータとを合成することで、新たなメタデータをを創造する。そして、更新有無決定部１０５は、当該新たなメタデータを当該第２スタンプのメタデータとして置換することで、当該第２スタンプのメタデータを更新する。これにより、次に類似する状況が起きたときには、当該第２スタンプが、より上位に表示されるようになる。

なお、更新有無決定部１０５が更新有無を決定するための閾値、即ち、上位と、中位乃至下位とを切り分ける順位は、特に限定されず、ゲームタイトルの特性やメタデータの品質に応じて設定すると好適である。

このようにして、メタデータ更新部１５４により更新されたメタデータは、それ以降、当該プレイヤー専用のメタデータ（個人化されたメタデータ）として管理される。即ち、１つのスタンプに対して、サーバ２側（ゲームの運営者側）で当初紐付けられた初期値のメタデータと、各プレイヤー毎の個人化されたメタデータとが別々に存在することになる。
そこで、所定のスタンプと、サーバ２側で当初紐付けられた初期値のメタデータとの対応関係を示す情報は、初期値ＤＢ１７３に格納される。一方、所定のスタンプと、個人化されたメタデータとの対応関係を示す情報は、各プレイヤー毎に区分されてプレイヤー毎ＤＢ１７２に格納される。

図８は、個人化されたメタデータの生成手法の一例を説明する図である。
図７の例と同様に、ゲームの状況を示す状況データに対応するメタデータベクトルＭを「ａ」とし、プレイヤーが選択したスタンプに紐付けられたメタデータベクトルＭを「ｂ」とするとき、ｂをａに近づける処理をすることで、プレイヤーが選択したスタンプのメタデータの個人化を行うことができる。
例えば、この個人化されたメタデータを示す個人化関数ｐｅｒｓｏｎａｌｉｚｅ（ａ，ｂ）の単純な実装として、次の式（３）に示す様に、ベクトルａとベクトルｂの和として定義できる。

・・・（３）
個人化関数ｐｅｒｓｏｎａｌｉｚｅ（ａ，ｂ）が示すベクトルの和の成分は、ベクトルａとベクトルｂの夫々の成分を加えたものであり、それ故、個人化関数ｐｅｒｓｏｎａｌｉｚｅ（ａ，ｂ）は（ａ１＋ｂ１，ａ２＋ｂ２，・・・，ａｎ＋ｂｎ）となる。つまり、プレイヤーが選択したスタンプの元々の特徴量と、プレイヤーが選択した時点のゲームの状況を示す特徴量の両方を考慮したメタデータとして、個人化関数ｐｅｒｓｏｎａｌｉｚｅ（ａ，ｂ）として示される新たなメタデータベクトルＭが定義される。
つまり、図８に示す様に、ベクトルの加算処理により、ベクトルｂ（スタンプのメタデータベクトルＭ）は、ベクトルａ（ゲームの状況のメタデータベクトルＭ）に近付くことになる。その結果、次に同様の状況が発生した時、個人化されたベクトルＭ（個人化関数ｐｅｒｓｏｎａｌｉｚｅ（ａ，ｂ）が示すベクトルＭ）と対応付けられたスタンプは、より上位に羅列されるように表示される。
なお、図８の例は例示に過ぎない。即ち、メタデータの個人化の手法は、単純なベクトルの合成手法に限定されず、重みをつけて合成する手法や、最小の移動量でベクトルを近似させる手法など、ベクトルｂがベクトルａへ近づく手法であれば、任意の手法を採用することができる。

図４に戻り、初期メタデータ作成部１５５は、蓄積されたプレイヤー毎ＤＢ１７２のデータを対象として統計処理を行い、統計処理の結果に基づいて汎用的なメタデータを抽出し、当該汎用的なメタデータを初期値のメタデータとして生成し、初期値ＤＢ１７３に新たに記憶させる。
なお、統計処理の手法は、特に限定されず、例えば各属性の平均を算出する手法等任意の手法を採用することができる。

以上、サーバ２及びプレイヤー端末１の機能的構成について説明した。
次に、図９を参照して、このような機能的構成を有するサーバ２が実行する処理のうち、スタンプ処理について説明する。
図９は、サーバ２が実行するスタンプ処理の流れを説明するフローチャートである。

ステップＳ１において、図４のサーバ２のゲーム状況管理部１５１は、ゲーム状況を監視する。
ステップＳ２において、ゲーム状況管理部１５１は、スタンプ表示条件を満たしたか否かを判定する。
スタンプ表示条件とは、プレイヤー端末１側に推薦するスタンプを表示させる条件をいう。スタンプ表示条件は、特に限定されないが、例えば、次のような第１条件と第２条件のＯＲ条件を採用することができる。第１条件とは、一定の時間が経過したという条件である。第２条件とは、ゲーム状況を示す状況データ（メタデータベクトルＭ）に所定の閾値を超える変化があったことという条件である。

スタンプ表示条件を満たしていない場合、ステップＳ２においてＮＯであると判定されて、処理はステップＳ９に進む。
ステップＳ９において、ゲーム状況管理部１５１は、処理の終了の指示があったか否かを監視する。
処理の終了の指示は、特に限定されず、例えばゲームの終了を示す指示を採用することができる。
即ち、ゲームが終了してその旨が指示されると、ステップＳ９においてＹＥＳであると判定されて、スタンプ処理は終了となる。
これに対して、ゲームが継続している限り、ステップＳ９においてＮＯであると判定されて、処理はステップＳ１に戻される。

即ち、ゲームが継続している間、スタンプ表示条件が満たされないと、ステップＳ１、ステップＳ２ＮＯ、及びステップＳ９ＮＯのループ処理が繰り返し実行されて、スタンプ処理は待機状態になる。
スタンプ表示条件が満たされると、ステップＳ２においてＹＥＳであると判定されて、処理はステップＳ３に進む。

ステップＳ３において、スタンプ表示順番決定部１５３のスコア算出部１６１は、ゲーム状況の状況データと、各スタンプのメタデータとの相関量に基づき、各スタンプのスコアを演算する。
ステップＳ４において、スタンプ表示順番決定部１５３の順番決定部１６２は、各スコアに基づいて、各スタンプの羅列順番を決定する。
ステップＳ５において、スタンプ表示順番決定部１５３は、決定された羅列順番で、各スタンプをプレイヤー端末１（図４の例ではプレイヤー端末１−Ｐ）に表示させる。

ステップＳ６において、ゲーム状況管理部１５１は、プレイヤー端末１（図４の例ではプレイヤー端末１−Ｐ）から他のプレイヤー端末１（図４の例ではプレイヤー端末１−Ｑ）に、スタンプが送信されたか否かを判定する。
スタンプが送信されていない場合、ステップＳ６においてＮＯであると判定されて、処理は上述したステップＳ９に進む。
これに対して、スタンプが送信された場合、ステップＳ６においてＹＥＳであると判定されて、処理はステップＳ７に進む。

ステップＳ７において、メタデータ更新部１５４は、送信された当該スタンプのメタデータの更新が必要か否かを判定する。
上述した様に、メタデータの更新有無は、プレイヤー端末１（図４の例ではプレイヤー端末１−Ｐ）側の更新有無決定部１０５により決定された。従って、更新有無決定部１０５により更新は不要と判定された場合、ステップＳ７ににおいてＮＯであると判定されて、処理は上述したステップＳ９に進む。
これに対して、更新有無決定部１０５により更新は必要と判定された場合、ステップＳ７においてＹＥＳであると判定されて、処理はステップＳ８に進む。

ステップＳ８において、メタデータ更新部１５４は、当該スタンプのメタデータを更新する。即ち、当該スタンプを送信したプレイヤー端末１（図４の例ではプレイヤー端末１−Ｐ）のプレイヤーにとって好適なメタデータに更新され、プレイヤー毎ＤＢ１７２に格納される。
このようにして、メタデータの個人化が行われると、処理は上述したステップＳ９に進む。

以上本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

例えば、複数のプレイヤー端末１の間でコミュニケーションを図るために送受信される情報は、上述の実施形態ではスタンプとされたが、特にこれに限定されず、所定のコードに対応付けられた、文字、図形、記号、又はこれらの結合からなるシンボルであれば足りる。
従って、例えば本発明は、所定のコードに対応付けられた定型文を送受信する際にも適用可能である。

また例えば、図４の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図４の例に限定されない。また、機能ブロックの存在場所も、図４に特に限定されず、任意でよい。例えば、サーバ２の機能ブロックをプレイヤー端末１等に移譲させてもよい。逆にプレイヤー端末１の機能ブロックをサーバ２等に移譲させてもよい。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、プレイヤーにプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でプレイヤーに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

換言すると、本発明が適用される情報処理システムは、上述の図１や図４の実施形態としての情報処理システムを含め、次のような構成を有する各種各様の実施形態を取ることができる。
即ち、本発明が適用される複数の情報処理システムは、
複数のプレイヤーの夫々の操作を受付けてゲームを実行し得る複数の端末（例えば図１のプレイヤー端末１−１乃至１−ｍ）と、サーバ（例えば図１のサーバ２）とを含む情報処理システムにおいて、
前記複数の端末の夫々は、
所定のコードに対応付けられた、文字、図形、記号、又はこれらの結合からなるシンボルを、他の端末に送信し得る候補シンボルとして複数個羅列して表示する制御を実行する表示制御手段（例えば図４の表示制御部１０２）と、
複数の前記候補シンボルの中から前記プレイヤーにより選択されたものを送信対象として、当該送信対象に対応付けられた前記コードを、他の端末に送信する制御を実行する送信制御手段（例えば図４のスタンプ送信制御部１０４）と、
を備え、
前記端末又は前記サーバは、
複数の前記候補シンボルの夫々を、前記ゲームの所定状況を示すメタデータと対応付けて管理する管理手段（例えば図４のスタンプ・メタデータ管理部１８１）と、
前記管理手段により管理されている前記複数の候補シンボル毎に夫々対応付けられた複数の前記メタデータと、前記ゲームの実行中における現在の状況を示す状況データとの夫々の相関度に基づいて、当該複数の候補シンボルが前記表示制御手段の制御により表示される際の羅列の順番を制御する羅列順番制御手段（例えば図４のスタンプ表示順番決定部１５３）と、
前記管理手段により管理されている前記複数の候補シンボル毎の前記メタデータの内容を、前記プレイヤーの送信対象の選択結果に基づいて更新する更新手段（例えば図４のメタデータ更新部１５４）と、
を備える。

これにより、ゲームの実行中に複数のプレイヤー間でコミュニケーションを図る機能として、スタンプ等を送受信する機能であって、高い表現能力を有すると共に、ゲームの状況に適合したスタンプ等の選択操作による入力を高速に行うことが可能な機能を確立することができる。
具体的には、ゲームの状況、例えばマルチバトルの状況を予め固定的に定義せずに、動的な演算により、リアルタイムに変化するゲームの現状況に応じて、使用可能性が高い順に候補シンボル（スタンプ等）を並び替え続ける機能を実現することが可能になる。
これにより、次の４つの効果を奏することが可能になる。

第１の効果は、スタンプの種類数のスケーラビリティを確保できる効果である。
即ち、本発明が適用される情報処理システムによれば、多数種類の候補シンボル（スタンプ等）が存在する場合においても、ゲームの現状況に適合する候補シンボルをリストの上位に優先的に表示させることができる。
従って、端末のプレイヤーにとっては、スタンプの種類数の増加が、送信対象を選択する際の困難性に直結しなくなる。その結果、ゲームの運営側としては、スタンプの種類数を容易に増加させることができる。
さらに、このようなスタンプの種類数のスケーラビリティの確保により、シンボル（スタンプ等）を販売するビジネスモデルや、シンボル（スタンプ等）をゲーム内の報酬として配布するサービス等を支援することが容易に可能になる。

第２の効果は、コミュニケーションの多様性に容易に対応可能になるという効果である。
第１の効果により、ゲーム内でのプレイヤー間のコミュニケーションに必要十分な数のスタンプを用意することができるようになる。その結果、従来、フリー入力のテキスト（文章）の補助として用いられたシンボル（スタンプ等）が、主たるコミュニケーションツールとして利用可能になる。

第３の効果は、マルチバトルに要求される速いテンポに適合可能という効果である。
即ち、従来のフリーテキストのチャット機能では、入力に時間を要するため、マルチバトル中に用いることは現実的に不可能であった。
これに対して、本発明が適用される情報処理システムでは、１回のタップ操作等の簡単で即座にできる操作のみで、シンボル（スタンプ等）を選択することができる。
さらに、ゲームの現状況との相関が高いメタデータと紐付いたシンボル、即ちゲームの現状況に適合するシンボル（スタンプ等）がプレイヤーにとってわかり易い状態で提示されるように、シンボルの羅列の順番を決定することが容易にできる。
その結果、プレイヤーは、他のプレイヤーに送信する対象のシンボル（スタンプ等）を高速に選択できるようになるため、マルチバトルの速いテンポに適合することが容易に可能になる。

第４の効果は、個人化対応が容易に可能になるという効果である。
即ち、本発明が適用される情報処理システムは、動的な計算を基盤としており、シンボルに紐付けられるメタデータを各プレイヤー毎に更新することができるため、個人化を容易に行うことができる。
従って、プレイヤー毎の嗜好の違いや所有キャラクタの偏りに応じて、異なるシンボル（スタンプ等）を推薦することができる。

また、
前記羅列順番制御手段は、
前記ゲームの実行中において、現在の状況を示す前記状況データを取得する取得手段と、
前記管理手段により管理されている前記複数の候補シンボルの夫々について、対応付けられた前記メタデータに対する前記状況データとの相関度に基づいて、夫々のスコアを算出する算出手段（例えば図４のスコア算出部１６１）と、
前記管理手段により管理されている前記複数の候補シンボルの夫々の前記スコアに従って、当該複数の候補シンボルの羅列の各順番を決定する順番決定手段（例えば図４の順番決定部１６２）と、
を備えることができる。

このようにして、相関度に基づいてスコアが算出され、当該スコアというより明確な基準に基づいて候補シンボルの羅列の各順番が決定されるので、ゲームの現状況により適合した順番で各候補シンボルがプレイヤーに提示されるようになる。

また、前記メタデータ及び前記状況データは、多次元ベクトル空間上のベクトルで表され、
羅列順番制御手段は、前記メタデータのベクトルと前記状況データのベクトルとの前記多次元ベクトル空間上の距離を、前記相関度として算出する
ことができる。

これにより、ゲームの状況に関連する各種属性を、ベクトルを構成する各要素とすることが容易に可能になる。即ち、ゲームタイトル等に応じて適切なベクトルを容易に生成することができる。
従って、ゲームタイトル等に適切な演算により、適切な相関度が演算されるようになるので、ゲームの現状況により適合した順番で各候補シンボルがプレイヤーに提示されるようになる。

また、前記表示制御手段の制御による表示対象として、羅列の順番が可変する１以上の前記候補シンボルが属する第１シンボル群に加え、さらに、羅列の順番が固定の１以上の前記候補シンボルが属する第２シンボル群が存在し、
羅列順番制御手段は、前記第１シンボル群に属する前記１以上の候補シンボル毎に夫々対応付けられた複数の前記メタデータと、前記ゲームの実行中における現在の状況を示す前記状況データとの夫々の相関度に基づいて、前記第１シンボル群に属する前記１以上の候補シンボルの羅列の順番を制御する
ことができる。

これにより、従来の静的な第２シンボル群の羅列表示と、本発明が適用される動的な第１シンボル群の羅列表示とを共存させることが容易に可能になるので、プレイヤーにとって便宜である。

前記管理手段は、所定の前記候補シンボルに対して、予め対応付けられていた初期値の前記メタデータ（例えば図４の初期値ＤＢ１７３に格納されるメタデータ）と、前記更新手段により内容が更新された前記メタデータ（例えば図４のプレイヤー毎ＤＢ１７２に格納されたメタデータ）の夫々を対応付けて管理し、
前記羅列順番制御手段は、前記所定の候補シンボルの羅列の順番を制御するに際し、初期値の前記メタデータと、内容が更新された前記メタデータとを選択的に用いる、
ことができる。

これにより、１つのシンボル（スタンプ等）に対して、初期値のメタデータと、プレイヤー毎に個人化されたメタデータとを選択的に切り替えて使い分けすることが可能になる。従って、各種各様な観点で羅列の順番を変更したシンボル群をプレイヤーに提示することができる。

１、１−１乃至１−ｍ、１−Ｐ，１−Ｑ・・・プレイヤー端末、２・・・サーバ、２１，５１・・・ＣＰＵ、１０１・・コマンド発行部、１０２・・・表示制御部、１０３・・・送信スタンプ受付部、１０４・・・スタンプ送信制御部、１０５・・・更新有無決定部、１１１・・・スタンプ表示制御部、１１２・・・ゲーム画面表示制御部、１５１・・・ゲーム状況管理部、１５２・・・状況データ取得部、１５３・・・スタンプ表示順番決定部、１５４・・・メタデータ更新部、１５５・・・初期メタデータ作成部、１６１・・・スコア算出部、１６２・・・順番決定部、１７１・・・スタンプＤＢ、１７２・・・プレイヤー毎ＤＢ、１７３・・・初期値ＤＢ、１７４・・・ゲーム状況ＤＢ、１８１・・・スタンプ・メタデータ管理部

Claims (7)

1. 複数のプレイヤーの夫々の操作を受付けてゲームを実行し得る複数の端末と、サーバとを含む情報処理システムにおいて、
   前記複数の端末の夫々は、
   所定のコードに対応付けられた、文字、図形、記号、又はこれらの結合からなるシンボルを、他の端末に送信し得る候補シンボルとして複数個羅列して表示する制御を実行する表示制御手段と、
   複数の前記候補シンボルの中から前記プレイヤーにより選択されたものを送信対象として、当該送信対象に対応付けられた前記コードを他の端末に送信する制御を実行する送信制御手段と、
   を備え、
   前記端末又は前記サーバは、
   複数の前記候補シンボルの夫々を、前記ゲームの所定状況を示すメタデータと対応付けて管理する管理手段と、
   前記管理手段により管理されている前記複数の候補シンボル毎に夫々対応付けられた複数の前記メタデータと、前記ゲームの実行中における現在の状況を示す状況データとの夫々の相関度に基づいて、当該複数の候補シンボルが前記表示制御手段の制御により表示される際の羅列の順番を制御する羅列順番制御手段と、
   前記管理手段により管理されている前記複数の候補シンボル毎の前記メタデータの内容を、前記プレイヤーの送信対象の選択結果に基づいて更新する更新手段と、
   を備える情報処理システム。
2. 前記羅列順番制御手段は、
   前記ゲームの実行中において、現在の状況を示す前記状況データを取得する取得手段と、
   前記管理手段により管理されている前記複数の候補シンボルの夫々について、対応付けられた前記メタデータに対する前記状況データとの相関度に基づいて、夫々のスコアを算出する算出手段と、
   前記管理手段により管理されている前記複数の候補シンボルの夫々の前記スコアに従って、当該複数の候補シンボルの羅列の各順番を決定する順番決定手段と、
   を備える請求項１に記載の情報処理システム。
3. 前記メタデータ及び前記状況データは、多次元ベクトル空間上のベクトルで表され、
   羅列順番制御手段は、前記メタデータのベクトルと前記状況データのベクトルとの前記多次元ベクトル空間上の距離を、前記相関度として算出する
   請求項２に記載の情報処理システム。
4. 前記表示制御手段の制御による表示対象として、羅列の順番が可変する１以上の前記候補シンボルが属する第１シンボル群に加え、さらに、羅列の順番が固定の１以上の前記候補シンボルが属する第２シンボル群が存在し、
   羅列順番制御手段は、前記第１シンボル群に属する前記１以上の候補シンボル毎に夫々対応付けられた複数の前記メタデータと、前記ゲームの実行中における現在の状況を示す前記状況データとの夫々の相関度に基づいて、前記第１シンボル群に属する前記１以上の候補シンボルの羅列の順番を制御する
   請求項１乃至３のうち何れか１項に記載の情報処理システム。
5. 前記管理手段は、所定の前記候補シンボルに対して、予め対応付けられていた初期値の前記メタデータと、前記更新手段により内容が更新された前記メタデータの夫々を対応付けて管理し、
   前記羅列順番制御手段は、前記所定の候補シンボルの羅列の順番を制御するに際し、初期値の前記メタデータと、内容が更新された前記メタデータとを選択的に用いる、
   請求項１乃至４のうち何れか１項に記載の情報処理システム。
6. 複数のプレイヤーの夫々の操作を受付けてゲームを実行し得る複数の端末と、サーバとを含む情報処理システムであって、
   前記複数の端末の夫々は、
   所定のコードに対応付けられた、文字、図形、記号、又はこれらの結合からなるシンボルを、他の端末に送信し得る候補シンボルとして複数個羅列して表示する制御を実行する表示制御手段と、
   複数の前記候補シンボルの中から前記プレイヤーにより選択されたものを送信対象として、当該送信対象に対応付けられた前記コードを他の端末に送信する制御を実行する送信制御手段と、
   を備える前記情報処理システムのうち、
   前記端末又は前記サーバに、
   複数の前記候補シンボルの夫々を、前記ゲームの所定状況を示すメタデータと対応付けて管理する管理ステップと、
   前記管理ステップの処理により管理されている前記複数の候補シンボル毎に夫々対応付けられた複数の前記メタデータと、前記ゲームの実行中における現在の状況を示す状況データとの夫々の相関度に基づいて、当該複数の候補シンボルが前記表示制御手段の制御により表示される際の羅列の順番を制御する羅列順番制御ステップと、
   前記管理ステップの処理により管理されている前記複数の候補シンボル毎の前記メタデータの内容を、前記プレイヤーの送信対象の選択結果に基づいて更新する更新ステップと、
   を含む制御処理を実行させるプログラム。
7. 複数のプレイヤーの夫々の操作を受付けてゲームを実行し得る複数の端末と通信をするサーバであって、
   前記複数の端末の夫々は、所定のコードに対応付けられた、文字、図形、記号、又はこれらの結合からなるシンボルを、他の端末に送信し得る候補シンボルとして複数個羅列して表示し、複数の前記候補シンボルの中から前記プレイヤーにより選択されたものを送信対象として、当該送信対象に対応付けられた前記コードを他の端末に送信する制御を実行する場合、前記サーバは、
   複数の前記候補シンボルの夫々を、前記ゲームの所定状況を示すメタデータと対応付けて管理する管理手段と、
   前記管理手段により管理されている前記複数の候補シンボル毎に夫々対応付けられた複数の前記メタデータと、前記ゲームの実行中における現在の状況を示す状況データとの夫々の相関度に基づいて、当該複数の候補シンボルが前記端末において表示される際の羅列の順番を制御する羅列順番制御手段と、
   前記管理手段により管理されている前記複数の候補シンボル毎の前記メタデータの内容を、前記プレイヤーの送信対象の選択結果に基づいて更新する更新手段と、
   を備えるサーバ。

Images