米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> スポ−ツ;娯楽 -> マイクロソフト コーポレーション

発明の名称 プレーヤが口頭でコミュニケーションできるようにする方法及び口頭のコミュニケーションを可能にするシステム
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2007−244901(P2007−244901A)
公開日 平成19年9月27日(2007.9.27)
出願番号 特願2007−146887(P2007−146887)
出願日 平成19年6月1日(2007.6.1)
代理人 【識別番号】100089705
【弁理士】
【氏名又は名称】社本 一夫
発明者 デーモン ブイ.ダニエリ / ロクサーナ ガブリエラ アラマ
要約 課題
ゲームデバイス上の複数プレーヤのリアルタイムな音声コミュニケーションの使用を実現する。

解決手段
他のゲームコンソールと通信できるゲームコンソール102が、各プレーヤのためのヘッドホン109a〜109d及びマイクロホン202a〜202dを備える。1名または複数名のプレーヤに向けられた口頭のコミュニケーションが、PCMデジタルデータに変換され、リアルタイムで符号化され圧縮されて、別のゲームコンソール210、212、214に伝送されるデータパケットが生成される。圧縮されたデータパケットは、圧縮解除され復号化されて、宛先の受け手のヘッドホンを駆動するアナログ信号に変換されるPCMデータが生成される。事前定義されたレベルの計算リソースが、音声コミュニケーションのために使用されてゲームプレーの品質に悪影響が及ぶことが回避される。
特許請求の範囲
【請求項1】
少なくとも1つのマルチプレーヤゲームコンソール上で行われる電子ゲームで使用するための、前記ゲームを行いながらリアルタイムにプレーヤが口頭でコミュニケーションできるようにする方法であって、
(a)前記マルチプレーヤゲームコンソールを使用している少なくとも1人のプレーヤにオーディオセンサを提供するステップであって、前記オーディオセンサが、前記少なくとも1人のプレーヤによって生成されたサウンドに応答して前記ゲームコンソールへの入力信号を生成する、ステップと、
(b)出力信号に応答して前記ゲームの別のプレーヤに可聴なサウンドを生成するように構成された少なくとも1つのサウンドトランスデューサを提供するステップと、
(c)符号化されたデジタル信号を生成するために、前記オーディオセンサからの前記入力信号を符号化するステップと、
(d)前記別のプレーヤに関連する音声チャネルを介して前記符号化されたデジタル信号を伝達するステップと、
(e)前記出力信号を生成するために、前記別のプレーヤの前記チャネルにおける前記符号化された信号を復号化するステップと、
(f)前記1人のプレーヤによって生成された前記サウンドに対応する可聴サウンドを生成するために、前記サウンドトランスデューサに前記出力信号を提供するステップであって、前記1人のプレーヤによる口頭のコミュニケーションが、前記ゲームの前記別のプレーヤによって聞かれるようにする、ステップと、
を備え、
更に、前記電子ゲームの前記プレーヤ間で口頭のコミュニケーションを可能にするために前記電子ゲームコンソール上で割り振られる処理リソースに対する限度を事前定義するステップを備えた方法。
【請求項2】
(a)前記別のプレーヤによって生成されたサウンドを検出する別のオーディオセンサを提供するステップであって、前記別のプレーヤによって生成された前記サウンドに応答して別の入力信号を生成する、ステップと、
(b)別の出力信号に応答して前記ゲームの前記1人のプレーヤによって可聴なサウンドを生成するように構成された、前記1人のプレーヤのためのサウンドトランスデューサを提供するステップと、
(c)前記別のオーディオセンサからの前記別の入力信号を符号化するステップであって、別の符号化されたデジタル信号を生成する、ステップと、
(d)前記1人のプレーヤに関連するチャネルを介して前記別の符号化されたデジタル信号を伝達するステップと、
(e)前記1人のプレーヤに関連する前記チャネルにおける前記別の符号化された信号を復号化するステップであって、前記別の出力信号を生成する、ステップと、
(f)前記別のプレーヤによって生成された前記サウンドに対応する可聴サウンドを生成するために、前記別の出力信号を前記別のサウンドトランスデューサに提供するステップであって、前記別のプレーヤによる口頭のコミュニケーションが、前記ゲームの前記1人のプレーヤによって聞かれるようにする、ステップと、
をさらに備えた、請求項1に記載の方法。
【請求項3】
前記1人のプレーヤ及び前記別のプレーヤは、コミュニケーションするように結合された異なるマルチプレーヤゲームコンソール上で前記電子ゲームを行い、前記符号化された信号が、前記1人のプレーヤの前記マルチプレーヤゲームコンソールと前記別のプレーヤの前記マルチプレーヤゲームコンソールとの間で伝達されるようになっている、請求項1に記載の方法。
【請求項4】
前記1人のプレーヤを、前記1人のプレーヤが口頭でコミュニケーションをとる前記別のプレーヤを選択できるようにするステップをさらに備えた、請求項1に記載の方法。
【請求項5】
前記1人のプレーヤ及び前記別のプレーヤは、チームのメンバであり、
別のチームのプレーヤに関してステップ(a)〜(f)を繰り返すステップをさらに備え、これにより前記別のチームの前記プレーヤが、互いに口頭でコミュニケーションできるようにした、
請求項1に記載の方法。
【請求項6】
前記マルチプレーヤゲームコンソールを使用して前記電子ゲームを行うさらなるプレーヤに関してステップ(a)〜(f)を繰り返すステップをさらに備え、これにより前記さらなるプレーヤが、前記ゲームにおけるその他の選択されたプレーヤと口頭でコミュニケーションできるようにした、
請求項1に記載の方法。
【請求項7】
前記符号化された信号に可聴効果を適用するステップをさらに備え、前記可聴効果は、前記サウンドトランスデューサによって生成された前記可聴サウンドの特性を実質的に変化させて、前記可聴サウンドが、前記1人のプレーヤによって生成される前記サウンドとは異なるようにした、請求項1に記載の方法。
【請求項8】
前記可聴効果を適用する前記ステップは、前記1人のプレーヤによって生成された前記サウンドの個人を特定する特性を実質的に除去して、前記1人のプレーヤの音声が、別のプレーヤの音声と実質的に区別不可能であるようにする、請求項7に記載の方法。
【請求項9】
前記可聴効果は、前記1人のプレーヤによって生成された前記サウンドの音調範囲から前記可聴サウンドの音調範囲を変化させる、請求項7に記載の方法。
【請求項10】
前記可聴効果は、前記1人のプレーヤによって生成された前記サウンドに関連する性別の変化に対応する、請求項7に記載の方法。
【請求項11】
前記出力信号に可聴効果を適用するステップをさらに備え、これにより前記可聴サウンドが、前記1人のプレーヤによって生成された前記サウンドとは異なるようにした、請求項1に記載の方法。
【請求項12】
前記可聴効果は、周波数帯域の均等化、残響、及び反響のうちの1つである、請求項11に記載の方法。
【請求項13】
請求項1に記載のステップを実行するための複数のマシン語命令を有する、記憶媒体。
【請求項14】
ゲームのプレー中にゲームコンソールを介して、前記ゲームコンソール上の複数のプレーヤが口頭でコミュニケーションできるようにする方法であって、
(a)前記ゲームに参加している前記複数のプレーヤの各人に関して、前記プレーヤが使用するため前記ゲームコンソールに結合されたオーディオセンサ及びオーディオトランスデューサを提供するステップであって、前記オーディオセンサが、前記プレーヤによって生成された口頭の発言に応答して前記ゲームコンソールへの入力信号を生成し、前記オーディオトランスデューサが、前記ゲームコンソールからの出力信号に応答して前記プレーヤに可聴なサウンドを生成する、ステップと、
(b)前記複数のプレーヤのなかから少なくとも1人の意図した受け手に転送するため、前記ゲームコンソールによって使用される形式に各オーディオセンサからの前記入力信号を符号化するステップと、
(c)各意図した受け手に関して、前記意図した受け手のための前記出力信号を生成するために、前記ゲームコンソールによって使用される前記形式から復号化するステップと、
(d)各意図した受け手に関して、前記意図した受け手の前記オーディオトランスデューサを使用して、前記出力信号に対応する可聴信号を生成するステップであって、前記意図した受け手が、前記ゲームの別のプレーヤからの口頭のコミュニケーションを聞くようにする、ステップと
を備え、
事前定義された数の符号化インスタンスが、各オーディオ時間フレーム中に前記ゲームコンソール上で動作し、かつ前記事前定義された数は、口頭の発言を生成している前記ゲームコンソール上のプレーヤの総数より少ない、方法。
【請求項15】
前記ゲームコンソール上の口頭のコミュニケーションを処理することに割り振られる計算リソースのレベルを事前定義するステップをさらに備え、前記レベルは、固定であり、前記ゲームを行っている際中に音声コミュニケーションを使用するプレーヤの数の変化とは独立である、請求項14に記載の方法。
【請求項16】
直接リンク及びネットワークのうちの1つを介して前記少なくとも1人の意図した受け手に前記形式でデータを通信するステップをさらに備え、前記少なくとも1人の意図した受け手は、別のゲームコンソールを使用して前記ゲームを行い前記形式の前記データを処理している、請求項14に記載の方法。
【請求項17】
各プレーヤが、前記プレーヤの口頭のコミュニケーションの前記意図した受け手を選択できるようにするステップをさらに備え、前記意図した受け手は、前記ゲームによって課される制約に従って前記ゲームの前記複数のプレーヤのなかから選択される、請求項14に記載の方法。
【請求項18】
符号化する前記ステップは、
(a)前記入力信号をアナログ信号からデジタル信号に変換するステップと、
(b)前記形式を有する圧縮されたデジタル信号を生成するために、前記デジタル信号を圧縮するステップと
を備えた、請求項14に記載の方法。
【請求項19】
復号化する前記ステップは、
(a)圧縮解除されたデジタル信号を生成するため、前記形式を有する前記圧縮されたデジタル信号を圧縮解除するステップと、
(b)前記圧縮解除されたデジタル信号を、前記オーディオトランスデューサを駆動する前記出力信号に変換するステップと、
を備えた、請求項18に記載の方法。
【請求項20】
前記形式は、少なくとも1つのオーディオ時間フレーム全体にそれぞれが広がる複数のデータパケットを含む、請求項14に記載の方法。
【請求項21】
符号化する前記ステップは、オーディオ時間フレーム中に前記ゲームコンソール上の単一の符号化インスタンス上で並列に複数のプレーヤに関する入力信号を符号化するステップを含む、請求項20に記載の方法。
【請求項22】
前記ゲームコンソール上で、符号化インスタンスの前記事前定義された数より多くのプレーヤが連続するオーディオ時間フレームの中で話している場合、前記連続するオーディオ時間フレームの中で符号化される前記口頭の発言を選択する際にラウンドロビン選択が適用されるように、前記ゲームコンソール上のプレーヤの前記口頭の発言を符号化する、請求項14に記載の方法。
【請求項23】
ゲームが、一時にアクティブである符号化インスタンスの前記事前定義された数を判定することができるようにするステップをさらに備えた、請求項14に記載の方法。
【請求項24】
(a)復号化する前記ステップの前に異なるマルチプレーヤゲームコンソールからのデータパケットのストリームをミキシングするステップと、
(b)それぞれの異なる意図した受け手のための前記出力信号を生成するために、異なるマルチプレーヤゲームコンソールからのデータパケットのストリームを復号化し、次に、復号化されたデジタル信号をミキシングするステップと、
のうちの1つをさらに備えた、請求項20に記載の方法。
【請求項25】
ストリームを復号化する前記ステップは、前記ストリームを並列で復号化するステップを含む、請求項24に記載の方法。
【請求項26】
(a)選択されたプレーヤをチャネルに割り当てるステップと、
(b)共通のチャネルに割り当てられたプレーヤが、互いに選択的に口頭でコミュニケーションできるようにするステップと、
をさらに備えた、請求項14に記載の方法。
【請求項27】
(a)各プレーヤに、前記プレーヤが、少なくとも1人の他のプレーヤから口頭のコミュニケーションを受信することができる聴取者チャネルを割り当てるステップと、
(b)口頭の発言を行う各プレーヤを前記口頭の発言が別のプレーヤに伝達される話者チャネルに割り当てるステップと、
(c)特定のプレーヤの前記聴取者チャネルを口頭の発言を行う前記プレーヤの前記話者チャネルと論理的に結合することにより、前記口頭の発言が前記特定のプレーヤによって聞かれるかどうかを判定するステップと、
(d)前記特定のプレーヤが、論理的に結合する前記ステップの結果に応じて前記口頭の発言を聞くことができるようにするステップと
をさらに備えた、請求項14に記載の方法。
【請求項28】
(a)口頭の発言を生成しているプレーヤによって制御される前記ゲームにおけるアニメーションのグラフィックキャラクタの口唇部分を制御するための口唇同期データを生成するステップと、
(b)前記アニメーションのグラフィックキャラクタの前記口唇部分を制御して、前記アニメーションのグラフィックキャラクタに対応する前記プレーヤの前記口頭の発言と同期して動くようにするために、前記口唇同期データを使用するステップと
をさらに備えた、請求項14に記載の方法。
【請求項29】
請求項14に記載のステップ(b)〜(d)を実行するためのマシン実行可能命令を有する、記憶媒体。
【請求項30】
ゲームを行うプレーヤ間で口頭のコミュニケーションを可能にするシステムであって、
(a)プロセッサと、複数の機能を前記プロセッサに実行させるためのマシン語命令が記憶されたメモリと、を含むマルチプレーヤゲームコンソールであって、前記機能がゲームのインスタンスを実行することを含み、前記機能が更に、前記電子ゲームの前記プレーヤ間で口頭のコミュニケーションを可能にするために前記ゲームコンソール上で割り振られる処理リソースに対する限度を事前定義することを含む、マルチプレーヤゲームコンソールと、
(b)ゲーム中に口頭でコミュニケーションをとる各プレーヤのための口頭コミュニケーション入出力デバイスであって、それぞれの口頭コミュニケーション入出力デバイスが、
(i)入射するサウンドを示す入力信号を生成するサウンドセンサと、
(ii)印加された出力信号に応答して可聴サウンドを生成するサウンドトランスデューサと、を含む、口頭コミュニケーション入出力デバイスと、 (c)サウンドセンサから印加される前記入力信号を符号化して符号化された信号を生成するエンコーダと、
(d)前記符号化された信号を復号化して、少なくとも1つのサウンドトランスデューサに印加される前記出力信号を生成するデコーダと、
を備えたシステム。
【請求項31】
少なくとも1つの他のマルチプレーヤゲームコンソールと通信するように前記マルチプレーヤゲームコンソールを結合するように構成され、かつ前記マルチプレーヤゲームコンソールと前記他のマルチプレーヤゲームコンソールとの間で符号化されたデータのストリームを伝達して、前記マルチプレーヤゲームコンソール上で前記ゲームを行っている少なくとも1人のプレーヤと前記他のマルチプレーヤゲームコンソール上で前記ゲームを行っている少なくとも1人の他のプレーヤとの間で口頭のコミュニケーションを可能にするように構成されたインタフェースをさらに備えた、請求項30に記載のシステム。
【請求項32】
前記プロセッサ及び前記インタフェースは協働して、直接リンク及びネットワークのうちの1つを介して符号化されたデータの前記ストリームを含むパケットを生成し受信する、請求項31に記載のシステム。
【請求項33】
前記マシン語命令は、前記プロセッサに、前記エンコーダの前記機能、及び前記デコーダの前記機能を実施させる、請求項30に記載のシステム。
【請求項34】
前記マシン語命令は、前記プロセッサに、前記デコーダへのシリアル入力のために、受信した符号化されたデータのキューを維持させる、請求項30に記載のシステム。
【請求項35】
前記マシン語命令は、前記プロセッサに、プレーヤがサウンドを変化させる効果を選択し適用して、前記入力信号を実質的に変化させることができるようにさせ、それにより、口頭のコミュニケーションの受け手である別のプレーヤの前記サウンドトランスデューサによって生成される前記可聴サウンドが、前記プレーヤの前記サウンドセンサに入射した前記サウンドからある規定された仕方で変更される、請求項30に記載のシステム。
【請求項36】
前記符号化された信号は複数の時間フレームを含み、各エンコーダは、前記マルチプレーヤゲームコンソール上で符号化されるべきサウンドを生成するプレーヤより少ない数のエンコーダが存在する場合、ラウンドロビン技術を使用して、連続する時間フレームに関する入力信号を処理する、請求項30に記載のシステム。
【請求項37】
前記符号化されたデータは圧縮されたデータを含み、各デコーダは、各データストリームが異なるプレーヤから受信される場合、前記符号化されたデータを含むデータストリームを並列に処理する、請求項30に記載のシステム。
【請求項38】
前記エンコーダは、複数のサウンドトランスデューサから前記エンコーダに並列に印加される入力信号を符号化する、請求項30に記載のシステム。
【請求項39】
(a)データストリームをミキシングして、前記デコーダに供給されるミキシングされたデータストリームを生成するミクサと、
(b)前記デコーダから受け取られた復号化されたデータをミキシングするミクサと、
のうちの1つをさらに備えた、請求項38に記載のシステム。
【請求項40】
前記マシン語命令は、前記プロセッサに、プレーヤを様々な音声チャネルに関連付けさせ、かつ、プレーヤが、前記様々な音声チャネルの中からある音声チャネルを選択できるようにし、選択された前記音声チャネルに関連するプレーヤと口頭でコミュニケーションできるようにする、請求項30に記載のシステム。
【請求項41】
前記マシン語命令は、前記プロセッサに、
(a)話者チャネルを、各プレーヤと、前記プレーヤが口頭のコミュニケーションを受信できる聴取者チャネルとに関連付けることと、
(b)任意の話者チャネルを介して口頭のコミュニケーションが受信されたとき、前記口頭のコミュニケーションが前記プレーヤによって聞かれるかどうかを判定するためプレーヤの前記聴取者チャネルを前記話者チャネルと論理的に結合することと、
を行わせる、請求項30に記載のシステム。
発明の詳細な説明
【発明の属する技術分野】
【0001】
本発明は、一般に、電子ゲームのプレーヤの間におけるコミュニケーションに係る、プレーヤが口頭でコミュニケーションできるようにする方法及び口頭のコミュニケーションを可能にするシステムに関する。
【0002】
より具体的には、プレーヤがゲームに参加するのを可能にするように一緒に結合されたマルチプレーヤ電子ゲームデバイス間でデータを伝送するネットワークを介する音声コミュニケーションを含め、1つまたは複数のマルチプレーヤ電子ゲームデバイスを使用するプレーヤ間の音声コミュニケーションを円滑にするマルチプレーヤ電子ゲームシステムに関連した、プレーヤが口頭でコミュニケーションできるようにする方法、口頭のコミュニケーションを可能にするシステム、オーディオチャネルを符号化する方法、オーディオチャネルを符号化するためのシステム、オーディオチャネルを復号化する方法、圧縮されたデータを復号化するシステム、及び記録媒体に関する。
【従来の技術】
【0003】
1名または複数名の他の人々で非電子ゲーム、例えば、ブリッジなどのカードゲームを行っているとき、ゲーム中にプレーヤ間の口頭のコミュニケーションを介して生じる社交的対話は、通常、ゲームの楽しみをずっと大きくする。また、口頭のコミュニケーションは、ゲームプレーの要素でもある。というのは、ゲーム中に相手に対してプレーヤによって行われるコメントにより、相手が集中力を失い、手際が悪くなることが引き起こされる効果があり、他方、チームメンバに対して行われたコメントが励ましを与え、チームメンバのプレーの質を増進させることが可能であるからである。したがって、ゲームをする個人間のコミュニケーションは、明らかにゲームをする体験の重要な要素である。
【0004】
ゲームプレーにそれほど重要なプレーヤ間の口頭の言葉のやり取りは、プレーヤが、インターネット及びその他のネットワークリンクを介して電子ゲームを行い始めた当初、初めは欠如していた。異なるサイトにいるプレーヤは、一般に、互いにコミュニケーションをとることができなかった。というのは、プレーヤのパーソナルコンピュータ(PC)は、ゲームのプレーに関連するデータだけをネットワークを介して伝えたからである。このように、同じ場所で人々によってプレーされるゲームの大変重要な面である、口頭のコミュニケーション及び関連した社交的対話が失われることにより、インターネットを介して行われるゲームをそれほど面白くないものとしていた。この問題に対処するため、ゲームプレー中にインターネット又は他のネットワークを介するPC間の音声コミュニケーションをサポートするハードウェア及びソフトウェアが開発された。ほぼ同じ頃に、インターネットまたはその他のネットワークを介して音声を伝送して(すなわち、VoIP(voice over IP))、従来の電話機の長距離電話の費用を被ることなく、ネットワークで接続されたパーティ間のコミュニケーションを可能にする技術が開発された。この研究は、H.323規格、SIP(Session Initiation Protocol)、及びMGCP/MEGACO(メディアゲートウェイ制御プロトコル/メディアゲートウェイコントローラ)仕様を含め、VoIP通信をサポートする様々なプロトコルの作成をもたらした。VoIP用に開発された技術は、ネットワーク上のPC電子ゲームのプレーヤ間の口頭のコミュニケーションを可能にするスキームに一般に適用可能であり、またそのようなスキームにおいて使用されてきた。ゲームプレー中に接続されたPC間の音声コミュニケーションを提供するシステムの例には、マイクロソフトコーポレーションのSIDE WINDER GAME VOICE(商標)、マインドメーカ(Mindmaker)インコーポレーテッドのGAMECOMMANDER 2(商標)のデバイス及びソフトウェア、TEAMSOUND(商標)ソフトウェア、ゲームスパイインダストリーズ(GameSpyIndustries)のROGER WILCOソフトウェア、及びエイリアンウェア テクノロジー(Alienware Technology)のFIRST CONACTソフトウェアが含まれる。以上の製品によって提供される音声コミュニケーションにより、インターネットまたはその他のネットワークを介して接続されたPC上でゲームを行うことの楽しみが大幅に増す。以上のシステムの一部は、音声データがネットワークを介してPC間で直接に転送されるピアツーピアモードで動作する一方、他の一部は、1つのゲームプレーヤのPCから音声データを受信し、その音声データをネットワークを介して、ゲームを行うためにそのネットワークに接続されている1つまたは複数の他のPCに転送する。
【0005】
以上のシステムは、1つのPC当り1名のプレーヤだけにコミュニケーションを提供するので、各PCが、独自のネットワークストリームの音声データを生成し、このネットワークストリームが、互いのプレーヤの他のPCに送信される(または音声サーバに送信され、次に、このサーバが、その音声データを互いのプレーヤのPCに送信する)。したがって、この手法は、相当なネットワークデータオーバーヘッドをもたらす。
【0006】
現在、PCゲーム音声コミュニケーションのための従来技術のシステムで、インターネットまたは他のネットワークを介して行われるゲームにおいて1つのPC当り複数名のプレーヤを可能にするものは存在せず、したがって、従来の技術は、1つのPC当りマルチプレーヤの(multiplayer-per-PC)音声コミュニケーション機能をサポートしていない。また、そのようなマルチプレーヤPCシステムは、あるPC上の数名のプレーヤに関して既存の音声コミュニケーションプロトコルを使用して開発されたとすると、過大な量の計算リソースを必要とする可能性が高い。PC上のゲームのすべてのプレーヤに音声コミュニケーションに必要なリソースを割り振ることは、PCが、非常に高速のプロセッサ、大量のメモリ、及び高速のビデオドライバカードを有しているのでない限り、ゲームプレーの質に悪影響を与えるであろう。
【0007】
PCとは対照的に、専用のゲームコンソールは、しばしば、高性能のPCの処理能力及び可用メモリを有さず、したがって、以上の問題は、各ゲームコンソール上で複数のプレーヤによる音声コミュニケーションをサポートするスキームを開発する際に、いっそう大きな問題である。音声処理に必要とされるリソースが、音声コミュニケーションに参加するプレーヤの数が変化するにつれて規定の限度を超えて増大することが許されないよう、ゲーム機能及びゲーム設計に適切なように、ゲームコンソール上で音声コミュニケーションが可能なプレーヤの数とは独立に、音声コミュニケーションに必要なメモリ及びその他のコンピュータリソースの要件に固定されたレベルを割り振ることが望ましい。また、サイトにおけるゲームの各インスタンスに関して複数のプレーヤ間の音声コミュニケーションを可能にし、各プレーヤが、自身が誰と口頭でコミュニケーションをとるか(話すことと聞くことの両方)を制御できるようにし、またマルチプレーヤゲームコンソール間の音声コミュニケーションに必要なネットワーク帯域幅を小さくするためにゲームのそのインスタンスからの音声データのすべてを結合して単一のネットワークデータストリームにすることも有利である。さらに、サイトにおける単一のゲームインスタンスに関して複数のプレーヤ間で、音声データのエンコーダまたはデコーダなどのあるリソースを共用することが望ましい。
【0008】
ゲームグラフィックスの品質が向上するにつれ、現実感に関係する他の機能を維持することがより重要になる。1つのそのような機能は、ゲームプレー中にリップ同期(lip-sync)情報または他のビシーム(viseme)(リップ位置)情報に音声データを提供して、ゲームにおいて表示されるグラフィックキャラクタのリップが、ゲーム表示におけるグラフィックキャラクタによって表されグラフィックキャラクタを制御するプレーヤの、語と同期して動くようにする機能である。ただし、既存の音声コミュニケーションシステムは、通常、リップ同期を可能にするデータを伝送せず、この結果、音声コミュニケーションを受け取るプレーヤには、話しているプレーヤに対応するゲームにおけるキャラクタのリップが、話し手の語に同期して動くのが見られない。
【0009】
音声コミュニケーションは、一般に、望ましい機能であるが、特定のプレーヤによって乱用された場合、煩わしいものとなり、他のプレーヤが享受するゲームの楽しみを減じる可能性がある。また、従来の技術は、プレーヤが、迷惑なプレーヤによって使用されるゲームコンソールに関わらず、その迷惑なプレーヤが参加者であるあらゆるゲーム中にプレーヤに話しかける、またはプレーヤの声を聞くのをブロックすることも可能にしない。様々な人々が、他者の迷惑な挙動に対して様々な程度の許容度を有する。しかし、何らかの理由で特定の他のプレーヤの声を聞かない、または話しかけないことを選択したあらゆるプレーヤは、ゲームにおける他のプレーヤとコミュニケーションをとる能力を手放すことなく、その特定の他のプレーヤとのコミュニケーションを防止する能力を有さなければならない。プレーヤは、特定の他のプレーヤが過度の冒涜的な言葉または性的に露骨な言葉を使用する、または中傷である、または社会的に容認できないと自身が感じる言葉を使用する、またはそのようなコメントをすると感じるため、憤慨する可能性がある。
【0010】
親はまた、子供が、ゲームプレー中に音声コミュニケーションに参加するのをブロックして、その子供が冒涜的な言葉にさらされるのを回避することを、または有害な目的でゲームプレーの範囲外で子供に接触しようと試みる可能性がある誰かとの口頭のコミュニケーションを除外することを、望む可能性がある。子供の音声コミュニケーションのこの親によるブロック処理は、オンラインゲームサービス上で記憶されなければならず、それでその子供が異なるゲームコンソールからそのオンラインサービスに接続した場合でも、有効なままでなければならない。従来技術のゲーム音声コミュニケーションシステムでは、マルチプレーヤゲームコンソールを使用してゲームに参加している、子供などの選択されたプレーヤによる口頭のコミュニケーションをブロックすることが可能ではない。
【0011】
インターネットまたはその他のネットワークを介してゲームを行っている際中に、プレーヤの口頭の振舞いが(他のプレーヤから受け取られた苦情の数に基づき)あまりにもひどくなり、正当化される場合、オンラインゲームサービスは、そのプレーヤが、そのオンラインゲームサービスを介してゲームを行っている際中に音声のコミュニケーションに参加するのをある期間にわって防止することができなければならず、また、そのプレーヤの口頭の振舞いに関する苦情を引き続き受けることでさらに正当化される場合、そのプレーヤが音声コミュニケーションを使用するのを永久的に禁止処分にすることができなければならない。現行の音声コミュニケーションシステムでは、このレベルの制御を各オンラインゲームサービスにおいて適用して、使用されるエイリアス、またはプレーヤがオンラインゲームサービスを通じてゲームに参加するのに使用するゲームコンソールに関わらず、プレーヤを禁止処分にすることができない。
【0012】
音声コミュニケーションシステムは、ゲームを行うPC上の用途で周知であるが、ゲームコンソールは、異なるアーキテクチャを有し、可用システムリソースに対する明確な限界を伴う。ほとんどのゲームコンソールは、ゲームの単一のインスタンス上、すなわち、同一のコンソール上で複数のプレーヤを可能にする。ゲームコンソールは、インターネット、またはその他のネットワークを介して相互接続されたとき、好ましくは、ゲームコンソール上の複数のプレーヤの各人に音声コミュニケーションを提供することができなければならない。PC上のゲームプレー中の音声コミュニケーションを可能にするように開発された従来の技術の使用は、計算リソースがより限られており、かつ複数のプレーヤに関する音声コミュニケーションに対応する必要性があるため、ゲームコンソール上では受け入れることができない。したがって、前述した問題に対処する1つまたは複数のマルチプレーヤゲームコンソール上で行われるゲームに関して音声コミュニケーションを可能にする方法及びシステムの必要性が、明らかに存在する。
【0013】
いくつかの文献に上述のような従来の技術に関連した技術内容が開示されている(例えば、非特許文献1参照)。
【0014】
【非特許文献1】Mindmaker, Inc.、”Game Commander 2: Experience The Most Powerful and Flexible Voice Solution for Games.”、5pp.、インターネット<URL:http://www.gamecommander.com/products/gc2.html>
【発明の開示】
【発明が解決しようとする課題】
【0015】
従来のシステムには上述したような種々の問題があり、さらなる改善が望まれている。
【0016】
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、ゲームデバイス上の複数プレーヤのリアルタイムな音声コミュニケーションの使用を実現する、プレーヤが口頭でコミュニケーションできるようにする方法及び口頭のコミュニケーションを可能にするシステムを提供することにある。
【課題を解決するための手段】
【0017】
前述したとおり、ネットワークを介して接続されたPC上でゲームを行う1名の個人と、別個のPCを各人が使用する1名または複数名のゲームの他のプレーヤとの間の音声コミュニケーションは、周知である。これに対して、本発明により、ゲームコンソール上でゲームを行う複数のプレーヤが、そのゲームを行う1名または複数名の他のプレーヤとローカルで、かつ/またはネットワークを介して口頭でコミュニケーションをとることができるようになる。より多くの人々がゲームに加わるにつれ、口頭のコミュニケーションをサポートするのに余りにも大きな計算リソースが要求されることになるのを回避するため、本発明は、ゲームの設計者が、ゲームのプレーヤ間の口頭のコミュニケーションをサポートするのに使用される計算リソースに対して事前定義された限度を確立することができるようにする。
【0018】
ゲームのプレーヤ間の口頭のコミュニケーションをサポートするのに各マルチプレーヤゲームコンソールで使用するための特定のハードウェアが提供される。口頭でコミュニケーションをとる各プレーヤは、マイクロホン(より一般的には、オーディオセンサ)及びヘッドホン(より一般的には、オーディオトランスデューサ)を含むヘッドセットを備える。ヘッドセットは、音声コミュニケーションモジュールに結合され、このモジュールは、一実施形態においてゲームコントローラに接続されるか、または別の実施形態においてゲームコントローラの一部として内部に含まれる。マイクロホンからの入力信号が、マルチプレーヤゲームコンソール内部のエンコーダによって圧縮され、デジタル化される。次に、デジタル化され、圧縮された信号は、音声コミュニケーションチャネルを介して、宛先の受け手である別のプレーヤに伝送される。デコーダが、その圧縮された信号を圧縮解除して、その別のプレーヤのヘッドホンに印加される出力信号を生成して、元々生成された、音声コミュニケーションの伝送元であるプレーヤのマイクロホンに入射したサウンドに対応する可聴サウンドが生成される。本明細書で、また特許請求の範囲で使用する「音声コミュニケーション」という用語は、「口頭のコミュニケーション」という用語と同義であり、区別なく使用されるものとする。また、「口頭のコミュニケーション」または「音声コミュニケーション」は、ゲームに参加するプレーヤによって生成される話された語及び句、ならびにぶつぶつ言う声、叫び声などの他のサウンドまたは発声の伝達を包含するものとする。
【0019】
マルチプレーヤゲームコンソール上で口頭のコミュニケーションを処理することに割り振られる計算リソースのレベルは、好ましくは、ゲームを行いながら音声コミュニケーションを使用するプレーヤの数とは独立であるように事前定義されており、固定されている。この特徴により、ゲーム中に口頭でコミュニケーションをとるプレーヤの数の増加が、ゲームプレーのその他の態様の品質に悪影響を与えないことが保証される。
【0020】
デジタル圧縮信号を含むデータは、1つまたは複数のゲームコンソール上でゲームを行う1名または複数名の宛先の受け手に伝送されるとき、特定の形式になっている。デジタル圧縮信号は、直接リンク、またはインターネットなどのネットワークを介して伝送される。ゲームに依存して、各プレーヤが、ゲームのその他のプレーヤのなかから口頭のコミュニケーションの宛先の受け手を選択できるようにすることが可能である。例えば、チームのメンバが、互いに、またチームリーダと1つの音声チャネルを介して口頭でコミュニケーションをとることができるが、チームリーダは、それと同じ音声チャネルを介してチームメンバとコミュニケーションをとるか、または異なる音声チャネルを介して別のチームリーダとコミュニケーションをとるかを選択的に行うことができる。
【0021】
好ましくは、符号化するステップは、アナログ信号をデジタル信号に変換し、そのデジタル信号を圧縮して適切な形式で圧縮されたデジタル信号を生成するステップを含む。同様に、復号化するステップは、好ましくは、圧縮された信号を圧縮解除して圧縮解除されたデジタル信号を生成し、その圧縮解除されたデジタル信号を、オーディオトランスデューサを駆動するのに使用される出力信号に変換するステップを含む。
【0022】
圧縮された信号のために使用される形式は、複数のオーディオデータパケットを含む。各オーディオデータパケットは、オーディオ時間フレーム全体に広がる。好ましくは、事前定義された数の符号化インスタンスが、各オーディオ時間フレーム中にゲームコンソール上で動作している。事前定義された数は、好ましくは、ゲームコンソールを使用し、他のプレーヤと口頭でコミュニケーションをとるのに口頭の発言を生成しているプレーヤの総数より少ない。ゲームコンソール上のプレーヤの口頭の発言は、ゲームコンソール上で、事前定義された数の符号化インスタンスより多くのプレーヤが、連続するオーディオ時間フレームの中で話している場合、連続するオーディオ時間フレームの中で符号化される口頭の発言を選択する際にラウンドロビン選択が適用されるような仕方で符号化される。行われているゲームが、一度にアクティブである符号化インスタンスの事前定義された数を判定する。
【0023】
他のマルチプレーヤゲームコンソールから受信された符号化されたデータストリームの並列復号化を1つまたは複数のミクサと連携して使用して、プレーヤのヘッドホンを駆動する出力信号を生成することができる。
【0024】
選択されたプレーヤを1つまたは複数のチャネルに割り当てることが可能であり、また共通チャネルに割り当てられたプレーヤが、互いに選択的に口頭でコミュニケーションをとることができるようにされる。一実施形態では、各プレーヤは、そのプレーヤが他のプレーヤから口頭のコミュニケーションを受信することができる1つまたは複数の聴取者チャネルに割り当てられる。さらに、各プレーヤは、口頭の発言が他のプレーヤに伝送される1つまたは複数の話者チャネルに割り当てられる。マルチプレーヤゲームコンソール上の特定のプレーヤによって聞かれる口頭の発言は、その特定のプレーヤの聴取者チャネルを口頭の発言を行うプレーヤの話者チャネルと論理的に結合(すなわち、ANDにする)ことによって判定される。
【0025】
また、この方法は、ゲームにおけるアニメーションのグラフィックキャラクタの口唇部分(oral portion)(例えば、口)を制御するための口唇同期データを提供するステップも含む。口唇同期データは、ゲーム中に表示されるアニメーションのグラフィックキャラクタの口唇部分を制御して、口唇部分が、アニメーションのグラフィックキャラクタを制御するプレーヤの口頭の発言と同期して動くようにするのに使用される。
【0026】
プレーヤは、選択された他のプレーヤとの口頭のコミュニケーションを防止することができるようにされる。選択されたプレーヤとの口頭のコミュニケーションは、行われている現行のゲームだけにおいて、またはプレーヤと選択された他のプレーヤがともに参加するあらゆるゲームにおいて防止することが可能である。
【0027】
本発明のさらなる態様は、ゲームを行っているプレーヤ間の口頭のコミュニケーションを可能にするシステムを対象とする。このシステムは、プロセッサ及びメモリを有するマルチプレーヤゲームコンソールを含む。メモリの中には、プロセッサが、ゲームのインスタンスを実行することを含め、複数の機能を実行するようにさせるためのマシン語命令が記憶される。口頭コミュニケーション入出力デバイスが、ゲーム中に口頭でコミュニケーションをとる各プレーヤに関して含まれ、各口頭コミュニケーション入出力デバイスは、サウンドセンサに入射するサウンドを示す入力信号を生成するサウンドセンサ、及び印加される出力信号に応答して可聴サウンドを生成するサウンドトランスデューサを有する。メモリの中のマシン語命令は、プロセッサに、口頭のコミュニケーションを可能にする前述した方法のステップと一般的に整合する機能を実行させる。
【0028】
本発明の以上の態様及び付随する利点の多くは、添付の図面と併せて考慮されるとき、以下の詳細な説明を参照することによってよりよく理解されるにつれ、より明白となるであろう。
【発明の実施の形態】
【0029】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【0030】
本発明を実施するための例としてのゲームシステム
図1に示すように、例としての電子ゲームシステム100は、ゲームコンソール102、及びコントローラ104a及び104bなどの最高で4つのユーザ入力デバイスをサポートする。ゲームコンソール102は、内部ハードディスクドライブ(この図では示さず)、及び光記憶ディスク108によって代表される様々な形態のポータブル光記憶媒体をサポートする。適切なポータブル記憶媒体の例には、DVD(digital versatile disk)ディスク、及びCD(compact disc[disk])−ROM(read only memory)ディスクが含まれる。このゲームシステムでは、ゲームプログラムが、好ましくは、ゲームコンソールで使用されるためにDVDディスク上で配布されるが、他の記憶媒体が代わりに使用可能であること、または他のプログラムをインターネットまたはその他のネットワークを介してダウンロードするのが可能であることが企図される。
【0031】
ゲームコンソール102の前面上には、コントローラに電気的に接続するために4つのコネクタ110a、110b、110c、110dが提供されている。他のタイプのコネクタまたは無線接続を代わりに使用することが可能なことも企図されている。また、電源ボタン112及びディスクトレイイジェクト(disc tray eject)ボタン114も、ゲームコンソール102の前面上に配置されている。電源ボタン112は、ゲームコンソールへの電力の印加を制御し、またイジェクトボタン114は、ポータブル媒体ドライブ106のトレイ(図示せず)の開閉を交互に行って記憶ディスク108の挿入及び取出しを可能にし、そのディスク上のデジタルデータを読み取ってメモリにロードすること、またはゲームコンソールが使用するためにハードドライブ上に記憶することを可能にする。
【0032】
ゲームコンソール102は、テレビジョン、またはその他の表示モニタ、またはスクリーン(図示せず)に、A/V(audio/visual)インタフェースケーブル120を介して接続する。電力ケーブルプラグ122が、従来の交流ラインソース(図示せず)に接続されたとき、ゲームコンソールに電力を伝える。ゲームコンソール102は、イーサネット(登録商標)接続を介してネットワーク及び/またはインターネットに、またはブロードバンド接続を介して、データを転送するデータコネクタ124をさらに備えていることが可能である。あるいは、モデム(図示せず)を使用してデータをネットワーク及び/またはインターネットに転送することが可能であることが企図される。さらなる代案として、ゲームコンソールをイーサネット(登録商標)クロスオーバー(cross-over)ケーブル(図示せず)を介して別のゲームコンソールに直接にリンクすることが可能である。
【0033】
各コントローラ104a及び104bは、リード線を介して(または、別の企図される実施形態では、別法として、無線インタフェースを介して)ゲームコンソール102に結合される。図示した実施形態では、コントローラは、ユニバーサルシリアルバス(USB)対応であり、USBケーブル130を介してゲームコンソール102に接続される。ゲームコンソール102は、ゲームソフトウェアと対話し、ゲームソフトウェアを制御するための多種多様なユーザデバイスのいずれかを備えていることが可能である。図1に示したとおり、各コントローラ104a及び104bは、親指スティック132a、132b、132c、Dパッド134、ボタン136、及び2つのトリガ138を備えている。以上のコントローラは、単に代表的なものであり、ゲームコンソール102を制御するために、他のゲーム入力機構及びゲーム出力機構を図1で示したものの代わりに用いること、あるいは図1で示したものに加えて使用することが可能である。
【0034】
取外し可能な機能ユニットまたは機能モジュールをオプションとしてコントローラ104a、104bの中に挿入して追加の機能を提供することが可能である。例えば、ポータブルメモリユニット(図示せず)により、ユーザは、ゲームパラメータを記憶し、そのポータブルメモリユニットを他のコンソール上のコントローラの中に挿入することによって別のゲームコンソール上でゲームをするためにそのパラメータを搬送することができるようになる。コントローラで使用するために、他の取外し可能な機能ユニットが利用可能である。本発明に関連して、音声コミュニケーションモジュール140を備えた取外し可能な機能ユニットが使用されて、ユーザが、ローカルに、及び/またはネットワークを介して他のユーザと口頭でコミュニケーションをとることができるようになる。音声コミュニケーションモジュール140には、ヘッドセット142が接続され、ヘッドセット142は、好ましくは、入射するサウンドに応答して入力信号を生成するブーム(boom)マイクロホン144または他のタイプのオーディオセンサ、及びゲームコンソールからの出力信号に応答して可聴サウンドを生成するためのヘッドホン146または他のタイプのオーディオトランスデューサを含む。企図されている別の実施形態(図示せず)では、音声コミュニケーション能力は、他の点でコントローラ104a及び104bと全般的に同様であるコントローラ(図示せず)の欠くことのできない部分として含まれる。図1に示したコントローラは、2つの取外し可能な機能ユニットまたは機能モジュールを収容するように構成されている。ただし、2つより多い、または少ないモジュールを代わりに使用することも可能である。
【0035】
ゲームシステム100は、もちろん、ゲームを行うことができるが、CD及びDVD上の音楽及びビデオを再生することも可能である。ハードディスクドライブ上に記憶された、またはドライブ106において光記憶ディスク108から読み取られる、またはオンラインソースからの、または機能ユニットまたは機能モジュールからのデジタルデータを使用して、ゲームコントローラによって他の機能を実施するのが可能であることが企図されている。
【0036】
本発明を実施するための機能構成要素
次に、図2を参照すると、機能ブロック図が、例として、どのように構成要素が提供されて、マルチプレーヤゲームコンソール上の電子ゲームのプレー中にプレーヤ間の音声コミュニケーションまたは口頭のコミュニケーションが容易になるかを示している。前述したとおり、ゲームコンソール100のこの実施形態は、各コンソール上に最大で4名のプレーヤを有することが可能であり、また各プレーヤが、コントローラ及び音声コミュニケータを備えていることが可能である。音声コミュニケーションモジュール140aの詳細を関連のコントローラ104aに関連して示している。コントローラ104b、104c、及び104d(ゲームコンソール100に結合されている場合)が、オプションとして、それぞれ、コントローラ104aに結合されているもののような対応する音声コミュニケーションモジュールを含むことが可能であることを理解されたい。現行の好適実施形態では、音声コミュニケーションモジュール140aは、デジタル信号プロセッサ(DSP)156、アナログ−デジタル変換器(ADC)158、デジタル−アナログ変換器(DAC)161、及びユニバーサルシリアルバス(USB)インタフェース163を含む。入射する環境におけるサウンドに応答して、マイクロホン144は、ADC158に入力されるアナログ出力信号を生成し、ADC158は、そのアナログ信号を対応するデジタル信号に変換する。ADC158からのデジタル信号は、さらなる処理のためにDSP156に入力され、DSPの出力が、コントローラ104aに接続するためにUSBインタフェース163に印加される。この実施形態では、音声コミュニケーションモジュール140aは、USB接続(別個に図示せず)を介してコントローラ104a上の機能ユニットポートまたは機能モジュールポートに接続する。同様に、ゲームコンソール100から来るデジタルサウンドデータが、コントローラ104aを介して伝送されて、USBインタフェース163に印加され、インタフェース163が、そのデジタル信号をDSP156に伝送し、DSP156がDAC161に伝送する。DAC161は、そのデジタル信号をヘッドホン146を駆動するのに使用される対応するアナログ信号に変換する。
【0037】
マルチプレーヤゲームコンソール100を参照すると、いくつかの重要な機能構成要素が示されている。ただし、本発明に妥当な他の機能構成要素も含まれるが、図示していないことを理解されたい。具体的には、ゲームコンソール100は、CPU(central processing unit)150、ならびにROMとRAM(random access memory)をともに含むメモリ152を含む。また、DSP154も提供されている。マイクロホン144からのアナログ信号に応答してADC158によって生成されるデジタル信号が、コントローラ104aを介してCPU150に伝送され、CPU150は、ゲームコンソール上のイーサネット(登録商標)ポート(図2に示さず)を通じ、ブロードバンド接続を介して他のローカルな音声コミュニケーションモジュール及び他のゲームコンソールに伝送するため、その音声ストリーム信号の符号化を取り扱う。
【0038】
代替の実施形態は、音声コミュニケーションモジュール140a内部のDSP156を使用して、マイクロホン144からのアナログ信号に応答してADC158によって生成されたデジタル信号を符号化する。次に、符号化されたデータは、コントローラ104aを介してCPU150に伝送され、CPU150は、この場合も、ゲームコンソール上のブロードバンド接続を介する他のローカルな音声コミュニケーションモジュール及び他のゲームコンソールへの符号化されたデータの伝送を取り扱う。
【0039】
マルチプレーヤゲームコンソール100は、クロスオーバーイーサネット(登録商標)ケーブルを使用して別のゲームコンソールに直接に接続するか、あるいはハブ、スイッチ、またはその他の同様のデバイスを使用して、より従来どおりのネットワークを介して1つまたは複数の他のマルチプレーヤゲームコンソールに接続することが可能であり、かつ/または適切なケーブルモデム、デジタル加入者回線(DSL)接続、またはその他の適切なインタフェースのブロードバンド接続を介してインターネットまたはその他のネットワークに接続することが可能である。マルチプレーヤゲームコンソール100が、モデム(図示せず)を介してインターネットまたはその他のネットワークに接続される代替の実施形態も企図されている。直接接続またはネットワーク接続を介してパケットとして伝送されるデジタル信号が、ゲームコンソール100上のイーサネット(登録商標)ポートを介して(または同じゲームコンソールに接続された他の音声コミュニケーションモジュール及びコントローラから)CPU150に入力され、CPUによって処理されてデータパケットが復号化され、出力ミキシングのためにDSP154に印加されるデジタルサウンドデータが回復される。DSP154からの信号は、USBインタフェース163を介して入力するために、その音声コミュニケーションの受け手であるプレーヤのための宛先の音声コミュニケーションモジュールに伝送される。
【0040】
代替の実施形態は、CPUを使用してコントローラ104aを介して宛先の音声コミュニケーションモジュール140aに符号化されたデータパケットを伝送する。次に、符号化されたデータパケットは、音声コミュニケーションモジュール140a内部のDSP156によって復号化され、結果の復号化された信号がDAC161に伝送され、DAC161が、ヘッドホン146を駆動する対応するアナログ信号を生成する。
【0041】
さらに別の企図される代替形態では、各プレーヤに関するヘッドホン及びマイクロホンが、ゲームコンソールに直接に結合され、音声コミュニケーションモジュールの機能が、ゲームコンソール内部のCPU、またはDSPなどの他のプロセッサ、及び適切なDACモジュール及びADCモジュールによって行われることが可能である。したがって、サウンド信号を処理してプレーヤ間で伝送されるサウンドデータを生成する構成要素、及び各プレーヤのヘッドホンを駆動するアナログ信号を生成する構成要素の位置は、本発明に重要ではない。
【0042】
また、CPU150は、マイクロホン144に向かって話すプレーヤのサウンドの特性を変更する音声効果も適用し、また様々な効果の選択を使用してサウンドの性質を変更することができる。例えば、女性のプレーヤは、自分の音声が、男性の太い声のように聞こえるようにする音声効果、または音声に茶目っけ(elfin quality)があるようにする音声効果、または音声が、いくつかの他の所望の異なる音調(tonal)特性及びピッチ特性を有するようにする音声効果を選択することができる。プレーヤが選択することができる利用可能な音声効果は、ゲームに依存する。そのような音声効果は、実質的にプレーヤの音声のサウンドを変更して、プレーヤを実質的に認識不可能であるようにすることが可能であり、またゲームの中であるキャラクタが別のキャラクタに話しかけるように見えるとき、プレーヤによって制御されているそのキャラクタにドラマチックな性質またはよりすぐれた現実感を加えることが可能である。したがって、音声効果により、ロールプレーイング(role playing)が容易になり、プレーヤの真の身元が隠される。同一のゲームコンソール100に接続されているプレーヤが、ゲームコンソールが配置されている部屋の中で数フィート(1フィートは、30.48cm)しか離れていないため、互いの声が直接に聞こえるときでさえ、適用される音声効果に起因するプレーヤの音声の変更により、ヘッドホンを介して口頭のコミュニケーションを受け取る他のプレーヤによって聞き取られるサウンドが大きく変更されて、室内でプレーヤたちに伝播するプレーヤの音声の局所的サウンドを容易に無視することが可能になる。
【0043】
実際に、本発明における限定ではないが、ゲームコンソール100の好適実施形態は、ネットワークを介して、またはオンラインゲームサービスを通してインターネットを介して行われるゲーム中の口頭のコミュニケーションに、最高で16名のプレーヤが参加するのが可能であることを予期して設計されている。明らかに、プレーヤが一度に参加するのを予期することが可能な他のプレーヤからの口頭のコミュニケーションの数には、実際的な限界が存在する。したがって、プレーヤは、同時に話す4名を超える他のプレーヤからの口頭のコミュニケーションを理解することができないものと想定した。
【0044】
ゲームプレーのシナリオ
ゲームのタイプ、及び音声コミュニケーション信号を符号化する要件及び復号化する要件に影響を与える所与のゲームに参加しているプレーヤの数に依存して、異なる適切なシナリオが存在する。例えば、音声コミュニケーションに関する要件に影響を与える3つの主要なシナリオが存在する。第1のシナリオは、「ポイントツーポイント」と呼ばれ、2つの相互接続されたゲームコンソールのそれぞれにおいて1名のプレーヤを含み、各プレーヤは、他のプレーヤとの音声コミュニケーションに参加している。「マルチポイント」と呼ばれる第2のシナリオでは、やはり、各ゲームコンソール上で音声コミュニケーションに参加している1名だけのプレーヤが存在するが、最高で16名のプレーヤが参加するゲームを行うため、最高で16のゲームコンソールが、ネットワークを介して相互接続される。第3のシナリオは、「ゲームコンソール上のマルチプレーヤ」と呼ばれる。というのは、1つのゲームコンソール当り最高で4名のプレーヤが、また最高で4つのゲームコンソールがネットワークを介して相互接続されて、最高で16名のプレーヤが同時にゲームを行い、口頭でコミュニケーションをとることが可能になるからである。この最後のシナリオに関して、単一のゲームコンソール上の2名またはそれより多くのプレーヤが、同じ室内に物理的にいるものの、前述したとおり、音声効果オプションの使用によってもたらされる音声の変化により、各プレーヤによるゲーム及びロールプレーイングの楽しみが増すことが可能であるため、ゲーム中に音声コミュニケーションを使用することも可能である。さらに、以上3つのシナリオのそれぞれにおいて述べたゲームコンソール/プレーヤの総数の限度は、ソフトな限度と考えることができる。というのは、さらなるプレーヤまたはゲームコンソールが参加することを除外する固有のハードウェアの限界は存在しないからである。
【0045】
以上の3つのシナリオの1つまたは複数に従ってゲームを設計することにより、ソフトウェア設計者が、音声コミュニケーションに割り振られる計算リソースに対して最大の事前定義された限度を設定して、音声コミュニケーションが、ゲームプレーの品質に悪影響を与えるのを回避することが可能である。また、マルチプレーヤゲームコンソール上で行われる特定のゲームが、ある人数のプレーヤだけによって行われるのが適切であるように独自の要件を有することも可能である。この場合、ゲームの性質により、必要とされる口頭コミュニケーションチャネルの数の限度が決まる。例えば、チェスなどのゲームは、通常、ポイントツーポイントシナリオを使用して行われる。というのは、チェスには、通常、2名のプレーヤだけが関与するからである。音声コミュニケーション機能により、その2名のプレーヤが、チェスゲームを行いながら互いに話すことが可能になる。このポイントツーポイントシナリオの場合、各ゲームコンソールは、1つのエンコーダ及び1つのデコーダを実装するだけでよい。というのは、複数のエンコーダ及びデコーダは必要ないからである。各音声フレーム更新中、ゲームコンソール上のCPUが、必要に応じて符号化及び復号化を更新する。このポイントツーポイントシナリオにおいて1.5パーセントの事前定義された符号化CPU使用率限度及び0.5パーセントの復号化CPU使用率限度を使用すると、必要とされるCPU使用率の合計は、およそ2.0パーセントだけである。
【0046】
図4の機能ブロック図に示すとおり、ゲームコンソール102は、ゲームコンソール172と音声コミュニケーションするように結合されている。マイクロホン144が、コンソール102を使用するプレーヤの音声に反応し、このマイクロホンに接続されている音声コミュニケーションモジュールが、シングルストリームエンコーダ160に入力されるPCM(pulse code modulated)データを生成する。PCMデータに応答して、エンコーダは、圧縮されたデータパケットを生成し、次に、このデータパケットが、ゲームコンソール172が接続されているネットワーク170を介して伝送される。
【0047】
あるいは、シングルストリーム符号化が、音声コミュニケーションモジュールのDSPによって行われることが可能である。この実施形態では、マイクロホン144が、ゲームコンソール102を使用するプレーヤの音声に反応し、DSP156が、ADC158に接続され、圧縮されたデータパケットを生成し、次に、このデータパケットが、ネットワーク170を介してゲームコンソール172に伝送するためにゲームコンソール102に送られる。
【0048】
ゲームコンソール102からの圧縮されたデータは、ゲームコンソール172においてネットワークキュー174に入力される。コンソール102からのサウンドパケット圧縮データを受信するのにネットワークキューを使用する目的は、データがネットワーク170を介して送信される際に生じるジッタ及び他のタイミング異常を除去することである。シングルストリームデコーダの出力は、PCMデータであり、次に、このデータが、ゲームコンソール172を使用するプレーヤの音声コミュニケーションモジュール内部のDACに印加されて、ヘッドホン178を駆動するアナログ出力が生成される。
【0049】
代替の実施形態では、圧縮されたデータは、ゲームコンソール102から音声コミュニケーションモジュール内部のDSP156に伝送される。DSPは、圧縮されたデータを復号化して、対応するPCM信号に変換し、このPCM信号が、ゲームコンソール172を使用するプレーヤの音声コミュニケーションモジュール内部のDAC161に印加されて、ヘッドホン178を駆動するのに使用される対応するアナログ出力信号が生成される。
【0050】
同様に、コンソール172を使用するプレーヤからの口頭のコミュニケーションに関して、マイクロホン180が、入射するサウンドを、マイクロホン180が接続されているコミュニケーションモジュール内部のADCを使用してPCMデータに変換し、このPCMデータが、シングルストリームエンコーダ182に入力され、エンコーダ182が、ゲームコンソール102内部のネットワークキュー162にネットワーク170を介して伝送される圧縮されたデータを生成する。ネットワークキュー162からの圧縮されたデータは、シングルストリームデコーダ168に入力され、デコーダ168は、ヘッドホン146が接続されている音声コミュニケーションモジュール内部のDAC変換器に入力されるPCMデータを生成する。DACは、対応するアナログサウンド信号を生成する。したがって、ヘッドホン146が、コンソール172に接続されたプレーヤのサウンドに対応するアナログサウンド信号を(加えられた音声効果があれば、その効果を伴って)受け取る。
【0051】
各コンソールに1名のプレーヤが存在するが、複数のゲームコンソールがゲームセッションに参加しているマルチポイントシナリオでは、ゲーム設計者は、すべてのプレーヤが、ゲームを行っている他のプレーヤのすべてと口頭でコミュニケーションをとることができるべきか、またはプレーヤのサブセットから成るチームが存在する場合、同一のチームにいるプレーヤだけが互いに話すことが可能であるようにするかを決定することが可能である。例えば、マルチポイントシナリオで行われているゲームが、カードゲームである場合、1つのゲームコンソール当り1名づつの4名の個人プレーヤが存在することが可能であるか、または各2名のプレーヤの2つのチームが存在することが可能である。4名の別々のプレーヤが存在する場合、各ゲームコンソールは、1つのエンコーダ及び1つの4対1デコーダ(以下に述べる)を実装する。音声フレーム更新中、各コンソールが、ゲームコンソールを使用する単一のプレーヤによる発話を伝送するために必要な符号化を更新し、またゲームに参加する他のゲームコンソール上の(最高で)3名の他のプレーヤのなかの任意のプレーヤからの発話データの復号化を更新する。このシナリオの場合、1.5パーセントのCPU使用率に関する事前定義された符号化限度、及び1.3パーセントのCPU使用率に関する4対1デコーダ限度を使用すると、カードゲームを行うのに使用されている4つのゲームコンソールのいずれにおいても、合計は、およそ2.8パーセントのCPU使用率である。
【0052】
図3は、どのようにマルチポイントシナリオが、各ゲームコンソール上で機能的に実施されるかを示しているが、他のゲームコンソールを示していない。ただし、ネットワーク170は、図示したゲームコンソールと通信する他のゲームコンソールに結合するものと理解する。前述したとおり、ゲームコンソールは、プレーヤの音声コミュニケーションモジュール(図3に示さず)内部のADCによって生成されたPCMデータを受け取るシングルストリームエンコーダ160を含む。PCMデータは、シングルストリームエンコーダ160に入力され、ネットワーク170を介して他のゲームコンソールに伝送するためにパケットの形態の圧縮されたデータの音声フレームが生成される。同様に、圧縮されたデータのパケットは、ネットワーク170を介して他のゲームコンソールから図示したゲームコンソールに伝送される。ゲーム(またはチャネル)に参加する各プレーヤは、データパケットが一時的に記憶されるゲームコンソール上のネットワークキューを有し、ミクサ166aによるミキシングのため、またデコーダ168aによる復号化のために選択エンジン164aによって圧縮されたデータのパケットが選択されたとき、ジッタ及び他のタイミング問題が最小限に抑えられることを保証する。デコーダ168aは、DACに供給されるPCMデータを生成し、DACは、ヘッドホン146を駆動するアナログ信号を生成する。
【0053】
代替の実施形態では、選択エンジン164aが、ミキシング及び圧縮解除のために音声コミュニケーションモジュール(図2に示す)のDSP156に2つの選択された圧縮されたデータストリームを伝送する。DSP156は、音声コミュニケーションモジュール内部のDACに供給される対応するPCM信号を生成し、DACは、ヘッドホン146を駆動する対応するアナログ信号を生成する。
【0054】
図3に示すとおり、ネットワークキュー162a、162b、及び162cがそれぞれ、他のプレーヤの、すなわち、最高でN名のプレーヤの各人に提供される。
【0055】
前述したマルチポイントシナリオでは、カードゲームに参加している3名だけの残りのプレーヤが存在するので、3つだけのネットワークキューが存在する。ミクサ166aは、一度に2つの入力だけを結合するので、デコーダ168aは、ヘッドホン146を装着しているプレーヤに、一度に2名のプレーヤに関する同時のPCMデータだけしか提供することができない。これに対して、デコーダ168bが、選択エンジン164bからの4つのデータパケットを一度に結合してヘッドホン146に提供される出力を生成するミクサ166bを含む代替の実施形態も示している。この代替の実施形態では、プレーヤには、最高で4つの他の音声データパケットが同時に提供される。
【0056】
あるいは、選択エンジン164aを使用して、宛先の受け手の音声コミュニケーションモジュール内部のDSP156に4つの選択された圧縮されたデータストリームを伝送することが可能である。DSP156は、この場合も、音声コミュニケーションモジュール内部のDACに供給される対応するPCM信号を生成し、ヘッドホン146を駆動する対応するアナログ信号が生成される。
【0057】
「ゲームコンソール上のマルチプレーヤ」シナリオに関する機能上の詳細を図5に示す。図5では、ゲームコンソール102が、ネットワーク層206を介してネットワーク170に接続され、これにより、プレーヤ216a及び216bを有するゲームコンソール210、単一のプレーヤ218を有するゲームコンソール212、及び4名のプレーヤ220a、220b、220c、及び220dを有するゲームコンソール214に接続されている。ゲームコンソール102には、プレーヤ200a、200b、200c、及び200dが接続されており、各プレーヤは、音声コミュニケーションモジュールを有するゲームコントローラを備えている。このシナリオの場合、コンソール210、212、及び214のそれぞれにおけるプレーヤの全員が、圧縮されたデータパケットのシングルストリームを生成するように符号化される音声コミュニケーションを有する。ゲームコンソール102内部のネットワーク層206が、残り3つのゲームコンソールのそれぞれからのデータパケットを、第2のゲームコンソール210に関するネットワークキュー162、第3のゲームコンソール212に関するネットワークキュー184、及び第4のゲームコンソール214に関するネットワークキュー186を含む3つの別々のネットワークキューに入れる。ゲームコンソール102内部のこの3つのネットワークキューからの出力が、デコーダ168に入力され、デコーダ168の出力が、音声コミュニケーション190aないし190dを受け取る特定のヘッドホンを決定する出力ルータ188に印加される。
【0058】
代替の実施形態は、出力ルータ188を使用してデコーダ168を迂回し、ネットワークキュー162、184、及び186から直接にデータパケットを引き出す。出力ルータ188は、宛先の受け手の音声コミュニケーションモジュール内部のDSPに圧縮されたデータを伝送して、そのプレーヤのヘッドホンが、音声コミュニケーション190aないし190dを受け取るようにする。
【0059】
したがって、プレーヤ200aないし200dの各人は、そのプレーヤを宛先とする音声コミュニケーションだけを受け取る。同様に、ゲームコンソール102上の4名のプレーヤの各人の対応するマイクロホン202a、202b、202c、及び202dからのサウンド入力が、入力ルータ204に供給され、ルータ204は、PCMデータストリームをエンコーダ160に選択的に印加して、エンコーダ160の出力が、ネットワーク層206に結合される。ネットワーク層は、サウンドデータを搬送する圧縮されたデータパケットが、ネットワーク170を介してゲームコンソール210、212、及び214のなかの適切なものにトランスポートされることを保証する。複数名のプレーヤを有する各ゲームコンソール内部の出力ルータは、ゲームコンソール102を使用するプレーヤからの音声コミュニケーションを受け取るプレーヤを決定する。
【0060】
別の実施形態は、話しているプレーヤの音声コミュニケーションモジュール内部のDSPを使用して圧縮されたデータを符号化することにより、入力ルータ204及びエンコーダ160を迂回する。
【0061】
符号化のための、優先順位付け/ラウンドロビン技術
図6は、ゲームを行うためにゲームコンソールを使用している最高で4名のプレーヤによる音声コミュニケーションを扱うゲームコンソール上の優先順位付けに関する機能上の態様を示している。各音声間隔中、4つのエンコーダインスタンスのうち2つだけがアクティブであり、したがって、ゲームコンソール上で、音声コミュニケーション能力を有するプレーヤの数よりも少ない数のエンコーダが存在する。したがって、4つのマイクロホン211a、211b、211c、及び211dが存在するが、このマイクロホンにそれぞれ接続される音声コミュニケーションモジュール内部のADCからのデジタルPCMデータが、すべて同時に符号化されるわけではない。PCMデータの各ストリームは、ブロック213a、213b、213c、及び213dに示すとおり、音声活動化検出アルゴリズムに印加される。このアルゴリズムは、いつプレーヤがマイクロホンに向かって話し、ゲームにおける1名または複数名の他のプレーヤに伝送するために符号化されなければならないPCMデータを生成しているかを判別する。最悪ケースのシナリオで、4名すべてのプレーヤが、同時に話しており、音声活動化検出アルゴリズムが、ゲームコンソールに接続されている4つすべてのマイクロホンからのPCMデータが符号化される必要のあることを示す可能性がある。しかし、この好適実施形態では、2つ音声ストリームだけを一度に符号化することが可能であるので、ブロック215における優先順位付けアルゴリズムが、2つの並列エンコーダ160aに入力されるPCMデータのストリームを決定するか、または選択する。これらのエンコーダは、ネットワークを介して伝送されるパケット化されたフレームの中で圧縮されたデータを生成する(ゲームコンソールが、リンクまたはネットワークを介して1つまたは複数の他のゲームコンソールに接続されていると想定して)。図6に示した例では、優先順位付けアルゴリズムは、ネットワークを介して出力するために現行のフレームの中に符号化することに関して、最高の優先順位を有するものとして、PCMデータ217c及び217dを含む2つのストリームのPCMデータを選択している。これに対して、ストリーム217a及び217bの中のPCMデータには、音声入力を有していないが、圧縮されたデータの次のフレームの中で、音声データを含む場合、符号化することに関して最高の優先順位を有するものとしてマークが付けられる。
【0062】
ラウンドロビン符号化方法を使用して、2つの並列エンコーダが4名のプレーヤからの音声コミュニケーションを符号化することができるようにし、任意の所与の音声データフレームの間に話していることが可能なプレーヤの総数よりも少ない数のエンコーダが、ゲームコンソール上で必要とされるようにする。図12は、開始ブロック380から始めて、音声フレームのラウンドロビン符号化を可能にするように実施される論理ステップに関する詳細を提供している。ステップ382で、4つのPCMパケット(各プレーヤに1つ)のアレイが組み立てられる。プレーヤが音声コミュニケーションをとらない場合、PCM無音パケットがそのアレイに挿入される。判定ステップ384が、ロジックが現行の音声フレームに関して第1のループを実行しているかどうかを判定する。実行している場合、ステップ386が、iが値0、1、2、または3を有することが可能な変数priority(i)を使用してアレイにおける優先順位を準備することを提供する。その後、ロジックは、ステップ390に進む。
【0063】
ロジックは、現行の音声フレームに関して第1のループを行っていない場合、ステップ388に進み、現行の音声フレームに関する前のループにおいて生成された優先順位アレイを使用する。その後、ロジックは、やはりステップ390に進む。ステップ390で、音声活動化の検出が行われて、PCMパケットに、そのパケットが音声内容を有するかどうかを示すマークが付けられるようになる。アルゴリズムは、現行のサウンドレベルが、平均(背景)レベルより相当に高いかどうかを検出し、相当に高いことは、マイクロホンを有するプレーヤが、多分、現在、マイクロホンに向かって話していることを示している。あるいは、PCMパケットを分析して、背景雑音の特性とは相当に異なる音声特性を検出することが可能である。次に、ステップ392が、変数priorities indexをゼロに等しいものとして設定し、また変数encodeopsをゼロに等しいものとして初期設定する。
【0064】
判定ステップ394が、priorities index変数が4より小さいかどうか、かつencodeops変数が2より小さいかどうかを判定する。判定ステップ394には、以上2つの変数がゼロに初期設定されたステップ392の直後に最初に到達するので、両方の基準が満たされ、ステップ402に進む。ステップ402で、変数PCM stream indexが、変数prioritiesに等しく設定され、値iは、priorities index変数に等しい。音声フレームに関する最初のパス(pass)で、PCM stream index変数がpriorities[0]に等しく設定される。
【0065】
次に、判定ステップ404が、PCM stream indexに等しいindexでPCMパケットに関して音声が検出されたかどうかを判定する。この場合も、音声フレームの間のこのロジックの最初のパスとともに、判定ステップが、PCM packet[PCM stream index]に関して音声が検出されたかどうかを判定する。検出された場合、ステップ406が、優先順位アレイの終りにある変数priorities[priorities index]を動かし、この変数の後のすべての他の要素の順位を1つ先に移動する。次に、ステップ408が、変数encodeopsを前の値に1を足したものに等しく設定し、これにより、この変数を増分する。判定ステップ404で音声が検出されなかった場合、ステップ410が、priorities indexをpriorities indexに1を足したものに等しく設定し、これにより、この変数を増分する。ステップ408またはステップ410の後、ロジックは、判定ステップ394に進む。
【0066】
priorities index変数が4に等しくなる、またはencodeops変数が2に等しくなると、ロジックは、ステップ396に進む。このステップで、ロジックは、PCM Packet[priorities[0]]及びPCM Packet[priorities[1]]に関する音声検出プロパティを偽に設定する。次に、ステップ398が、PCM Packet[priorities[2]]及びPCM Packet[priorities[3]]の並列符号化を提供する。最後に、ステップ400で、ロジックが、現行の音声フレームに関してネットワークを介して伝送するために4つの圧縮されたデータパケットのアレイを組み立てる。このロジックに基づき、4名すべてのプレーヤが実際に話している場合、音声コンソール上のプレーヤのすべてが、ゲームにおける他のプレーヤとコミュニケーションをとることができるように、PCMパケットが、このラウンドロビンアルゴリズムを使用して圧縮されたパケットを形成するように符号化されることが明白であろう。
【0067】
プレーヤ1、2、3、及び4が全員、同時に話していると想定される例を辿ることが役立つかもしれない。符号化された最新の2つの音声または2名のプレーヤの履歴が保持されている。ロジックは、プレーヤ1に関する現行のマイクロホンパケットを調べることから開始する。音声がアルゴリズムによって検出された場合、その音声が符号化される。次に、同じ判定が、プレーヤ2に関して行われる。すなわち、音声が、プレーヤ2のマイクロホンにおいて存在する場合、その音声が、現行の音声フレームの中で符号化される。初期の履歴は、プレーヤに[1,2,3,4]という順序が付けられて開始するが、この時点で、順序がプレーヤ[3,4,1,2]であるように更新される。ロジックは、事前定義されたマイクロホン符号化間隔の後、ループバックして、前回、処理されなかった2名のプレーヤに関するオーディオデータを処理する。現在、履歴リストは、[3,4,1,2]であり、したがって、プレーヤ3の音声が、現在、プレーヤ3のマイクロホンに入力されているかどうかを判定する検査が行われ、入力されている場合、その音声が符号化される。しかし、プレーヤ3が、この時点でもはや話していない場合、ロジックは、代わりに、話しているものと想定されるプレーヤ4に進む。したがって、プレーヤ4に関するデジタルPCM音声パケットが符号化され、履歴が更新されて[3,1,2,4]になる。次に、ロジックは、プレーヤ1に進み、そのプレーヤの音声を符号化し、新しい履歴[3,2,4,1]を生成する。次に、ロジックは、プレーヤ3及び2で開始する。プレーヤ3がまだ話しておらず、したがって、そのプレーヤのマイクロホンにおいて音声が存在しないものと想定すると、ロジックは、プレーヤ2及び4に関するデジタルPCMパケットを符号化し、履歴リスト[3,1,2,4]をもたらす。
【0068】
一実施形態では、スキップされ、符号化されないプレーヤの各PCMパケットに関して、そのプレーヤの前のパケットが音声フレームに関して減衰させられ、再生される。起こりうる最悪の状態で、全プレーヤが話しており、実際に、異なるチームにいる4名の異なるプレーヤがゲームコンソール上に存在するとき、各プレーヤの1つおきのPCMパケットがスキップされる。この手法は、各プレーヤの音声の品質に対してわずかな悪影響を与えるが、これは、最悪ケースのシナリオであり、このシナリオは、通常、ゲームプレー中に稀にしか生じない。
【0069】
スキップされ、したがって、前のパケットを繰り返すことによって埋められなければならないプレーヤのPCMパケットは、ネットワークを介して伝送されないことに留意されたい。代わりに、繰り返されるPCMパケットは、そのパケットの宛先の受け手によって使用される受信側ゲームコンソールによって扱われる。したがって、任意の1つの音声フレーム中、最大で4つではなく、せいぜい2つのパケットが、ゲームコンソールから送信される。キューが、前のパケットをバッファに入れ、スキップされたパケットに取って代わるようにその前のパケットを提供する。あるいは、スキップされたパケットは、受信側ゲームコンソールによってキューに入れられず、代わりに、そのパケットが、伝送を行ったゲームコンソールによってスキップされたことを示す通知が、そのチャネルに関して受信側ゲームコンソールのネットワークキューの中に挿入される。
【0070】
ラウンドロビン符号化技術は、一度に2つの音声フレームに対してしか動作せず、現在、符号化されていないストリームのその他のフレームを繰り返す。前述したとおり、これにより、あるゲームコンソール上の4名すべてのプレーヤが話しているとき、サウンドの劣化がもたらされる可能性があるが、この技術により、追加のCPUリソースを使用して4名すべてのプレーヤの音声を別々に符号化することが回避される。追加のCPUリソースを使用して4名すべてのプレーヤの音声を別々に符号化することは、ゲームプレーに悪影響を与える可能性がある。
【0071】
代替の実施形態では、1名のプレーヤ当り1つのエンコーダが、発話を符号化するために割り振られる。ただし、この実施形態は、それほど望ましくない。というのは、前述した実施形態の2倍の計算リソースが必要とされるからである。
【0072】
リンク/ネットワークを介する音声コミュニケーション
図10は、リンクまたはネットワークを介する音声コミュニケーションを可能にするために適用される一般的なステップを示している。最初、ステップ330でゲームが開始される。次に、判定ステップ332が、プレーヤが他のプレーヤと音声でコミュニケーションをとることが止められたかどうかを判定する。この状態は、そのプレーヤが、行動規範または他のサービスポリシーの違反により、オンラインゲームサービスによって音声コミュニケーションをとることの禁止または停止処分を受けたためもたらされる可能性がある。音声がブロックされることが可能な別の理由は、親などの権限の付与された個人によって、未成年の子供がゲーム中に他のプレーヤとの音声コミュニケーションに関与することが許されるべきでないと決定したことによる。このオプションは、特定のプレーヤアカウントに関してゲームコンソール上で提供されるオプションを使用して利用可能であり、また設定することが可能である。設定されると、そのデータは、オンラインゲームサービス上に記憶され、そのプレーヤがサービスに接続するたびに音声コミュニケーションをブロックすることが実施される。現行のプレーヤの音声コミュニケーションがブロックされた場合、ステップ334が、ゲームコンソールが音声コミュニケーションを処理しなくてもよいことを判定し、ステップ336で、代わりに次の話し手に進む。次の話し手が、ゲームコンソール上の設定によって音声コミュニケーションをとることから除外されていないと想定すると、ロジックは、そのプレーヤのために音声コミュニケーションモジュール内部のADCからPCMデータを取得するステップ338に進む。次に、ロジックは、ステップ340でそのPCM音声データを圧縮して圧縮されたデータにする。ステップ342が、現行のプレーヤのPCM音声データを圧縮する際、何らかの割り当てられた音声効果を適用して、そのプレーヤの音声の特性を変化させる。ステップ344で、圧縮されたデータが、ネットワーク346を介して宛先の受信側ゲームコンソールに伝送されて、音声コミュニケーションモジュールを有する宛先の受け手に届く。ステップ348が、圧縮されたデータを伝送しているゲームコンソール上の次の話し手を処理することを準備し、これにより、判定ステップ332に戻る。
【0073】
ネットワーク346を介して音声コミュニケーションを受信したゲームコンソール上で、ステップ352が、圧縮されたデータをそのようなデータのネットワークキューに追加することを提供する。次に、ステップ354で、ゲームコンソールが、キューから引き出された圧縮されたデータを圧縮解除し、対応するPCMデータを生成する。ステップ356が、オプションの環境効果があれば、それを追加することを提供する。そのような効果は、一般に、ゲームコンソール上で行われているゲームにおいて提供されるオプションによって決定される。例えば、環境効果には、反響を追加すること、またはゲームの環境が洞穴内部である場合、残響を導入することが含まれることが可能であり、あるいは環境効果は、例えば、小さいスピーカ上のオーディオデータの再生に関して低音ブースト(bass boost)を追加することによって周波数帯域の均等化を提供することに関わることが可能である。次に、ステップ358が、複数の異なるプレーヤから受信された音声ストリームをミキシングして、宛先の受け手のプレーヤに提供される1つの出力音声ストリームにする。この出力音声ストリームが、ステップ360で、PCMデータとして宛先の受け手のプレーヤのヘッドホンに関連するDACに伝送され、DACが、ヘッドホンを駆動する対応するアナログ信号を生成する。したがって、プレーヤは、復号化され、ミキシングされて出力音声ストリームになったプレーヤの各人からの音声コミュニケーションを聞く。
【0074】
プレーヤ間のミュートにされた音声コミュニケーション
特定のプレーヤが別のプレーヤによって音声コミュニケーションからミュートにされたときはいつでも、別の状況が生じる。このようにあるプレーヤがミュートにされると、その特定のミュートにされたプレーヤは、ミュート処理側のプレーヤの声を聞く、またはそのプレーヤに話すことができない。ミュート処理側のプレーヤは、音声コミュニケーションを元に戻すのに明示的にミュートにされたプレーヤをミュート解除しなければならない。
【0075】
ネットワークデータパケットの扱い
図11は、ネットワーク346を介して音声コミュニケーションデータをパケットとして受信することに関するさらなる詳細を示している。ブロック350a及び350bに示されるとおり、圧縮されたデータが、N個の他のゲームコンソールからネットワークを介して受信される。圧縮されたデータの各チャネルは、最初、N個のキュー351a〜351bの1つに入力され、接続されたゲームコンソール上の各プレーヤ(各ゲームコンソール上に1名または複数名のプレーヤ)に関して個別のキューが提供される。次に、ブロック364が、圧縮されたデータを受け取るように形成されているN個のキューを同期する。このステップで、現行の音声フレームに関してキューのすべてから、符号化された圧縮されたパケットが獲得される。次に、選択エンジン366が、ブロック368において復号化エンジンに入力するために組み立てられるべき圧縮されたパケットを決定する。復号化エンジンは、圧縮されたデータを圧縮解除して復号化し、そのデータをPCMデータに変換して、次に、このPCMデータが、接続された音声周辺コミュニケーションモジュール370ないし372のそれぞれに適用されて、その音声コミュニケーションモジュールをそれぞれ使用するプレーヤが、ネットワークを介して自身に伝送されたサウンドを聞くことができるようになる。
【0076】
各キューから受け取られた符号化されたパケットの処理に関連する詳細を図7に示している。ブロック221で、CPUが、各キューをチェックして符号化された圧縮されたパケットを獲得するか、またはキューが、あるプレーヤからのパケットを有していないが、そのプレーヤに関するパケットがそのキューの中に存在すべきであったことをクライアントのCPUに通知する。この場合、CPUは、そのキューからそのプレーヤに関して獲得された前のパケットが、実際に有効な符号化されたパケットであったかどうかを判定し、有効な符号化されたパケットであった場合、CPUは、そのプレーヤに関する前のパケットをコピーして、次のブロックにおけるさらなる処理のために提供することができるようにする。しかし、そのプレーヤに関する前のパケットも欠落していた場合、CPUは、そのプレーヤに関する前のパケットに減衰を行う。このステップの目的は、ラウンドロビン符号化中にパケットをスキップすること、及びネットワーク条件のためにドロップされたパケットからもたらされる欠落したパケットによって生じる無音の知覚を最小限に抑えることである。
【0077】
次に、ブロック222で、ブロック221で獲得されたパケットが配列され、その配列の中のすべての無音パケットが除去される。その結果が、キューの中で元に提供されたパケットのサブセットである。前述した処理により、サブセットの中のすべてのパケットが有効な音声データを含む。
【0078】
次に、ブロック224が、チャネルマスクを音声データに適用することを提供する。各プレーヤにチャネルが関連し、特定のチャネル上のすべてのプレーヤが、互いに音声でコミュニケーションをとることができる。例えば、1つのチャネルが、チームリーダとして指名されたプレーヤとチームメンバの間の音声コミュニケーションのために使用され、そのプレーヤが、チームのすべてのメンバとコミュニケーションをとることができるようにすることが可能である。さらに、チームリーダは、複数のチームリーダとコミュニケーションをとることができる指令者として指名された別のプレーヤと口頭でコミュニケーションをとるために別のチャネルを選択する、あるいはチームリーダが、他のチームリーダとだけコミュニケーションをとることができるようにするさらに別のチャネルを選択することも可能である。この実施形態では、話している各プレーヤに、そのプレーヤに関する「話者(talker)チャネル」を定義する16ビットワードが与えられる。ゲームは、話者チャネルに関するワードの個々のビットが何を意味するかを判定し、例えば、話者チャネルが、チーム用、チームリーダ用、指令者用等であることを示す。さらに、各プレーヤに、発話を受け取ることができる「聴取者(listener)チャネル」を割り当てることが可能である。音声コミュニケーションが、ネットワークを介して入ってきたとき、話者チャネルは、所与のプレーヤに関する聴取者チャネルと論理「AND」にされており、結果がゼロでない場合は、そのプレーヤが、音声コミュニケーションを聞くことができる。このようにして、行われているゲームが(またはゲームの制約の範囲内で各プレーヤが)、他のプレーヤと音声コミュニケーションするように結合されるプレーヤを判定する任意の順列(permutation)を選択することができる。
【0079】
図7を再び参照すると、ブロック224により、各プレーヤが、一部のチャネルだけを聴取し、チャネルマスクを使用することを選択できるようになる。ゲームコンソール上の各プレーヤに関してチャネルマスクが適用され、最大で4つのサブセットの音声ストリーム、すなわち、聴取する各プレーヤに関して1つのサブセットが、プレーヤの個々の聴取者マスクに基づいてもたらされる。聴取している各個人は、異なる音声ストリームに含まれる候補パケットのリストを有する。
【0080】
ブロック226で、ミュート処理マスク及びユーザによって定義された優先順位が提供される。好適実施形態により、プレーヤが、選択されたプレーヤとのさらなる音声コミュニケーションを選択的に除外することができるようになるが、プレーヤが、現行のゲームセッション中に特定のプレーヤとの音声コミュニケーションをミュートにすることだけを選択的に行うのが可能であることも企図される。この代替の実施形態では、ゲームコンソール上の各プレーヤが、聴取チャネル上である人々をミュートにするのを選択することが可能である。次に、そのプレーヤによってミュートにされたプレーヤからの音声ストリームが、ゲームコンソール上のそのプレーヤ向けの候補音声ストリームのリストから除去される。各プレーヤ向けのあらゆる残りの音声ストリームが、ユーザによって定義された優先順位でソートされる。このステップで、1つの音声ストリームが、常時、最高の優先順位を有することが可能である。例えば、ゲームが(またはゲームがそのオプションを許す場合、プレーヤが)、チームメンバがチームリーダと音声コミュニケーションをとるように結合するチャネルを選択的に設定して、そのチャネルが、チームメンバの各人に対して最高の優先順位を有するようにすることが可能である。また、着信する音声ストリームの音量も、所与のプレーヤ向けのチャネルの優先順位を判定する基準となり、そのプレーヤが、常時、最大音量の音声ストリームを聞くようにすることも可能である。あるいは、またはさらには、ある音声ストリームのレンダリングが開始された場合、ゲームは、後に開始した他の音声ストリームの音量に関わらず、その音声ストリームが終了するのを待ち、その音声ストリームが終了する前に文が「ストリーム途中(mid-stream)」で中断されないようにする。さらなる別法として、または追加として、各音声チャネルに関して他の優先順位を定義することも可能である。例えば、ゲーム固有の役割に関連する優先順位を適用することが可能である。
【0081】
ブロック226の後、ブロック228に示す復号化エンジンタイプ1、またはブロック230に示す復号化エンジンタイプ2を使用して、ミュート処理マスクとユーザ/ゲームによって定義された優先順位とを適用することからもたらされた音声ストリームに復号化を適用する。ブロック228で、復号化エンジンタイプ1が、デコーダを割り振り、各プレーヤのメソッドに関してミキシング及び復号化を行う。このアルゴリズムでは、各プレーヤに関して、配列されたパケットのリストの中の最初のN個のパケットが選択される。リストがN個より少ない要素を含む場合、存在しないパケットの代わりに無音の圧縮されたデータパケットを使用して、音声パケットのCPU処理においてスパイク(spike)が生じるのを回避する。
【0082】
ブロック230で、エンジンタイプ2を使用して復号化を適用する際、DSPのメソッドで復号化及びミキシングを行うためにデコーダが割り振られる。このアルゴリズムに従って、最大数の復号化されたパケットに達するまで、または候補パケットの終りに達するまで、または候補パケットリストの終りに達するまで、パケットの配列されたリストから、リストが空でない場合、現行のプレーヤが獲得される。配列されたパケットのリストの先頭が、前に選択されていない場合は、リストの先頭が復号化されるように選択され、復号化されたパケットに関してカウンタが増分される。その後、リストの先頭は、配列されたリストから除去される。次に、アルゴリズムは、次のプレーヤに進み、そのプレーヤが現行のプレーヤとなる。例えば、プレーヤ4の後、プレーヤ1は次いで再び現行のプレーヤになる。さらなる音声パケットを復号化するために復号化スロットが残っている場合、無音パケットを並列デコーダに適用して音声パケットのCPU処理におけるスパイクを回避する。
【0083】
復号化エンジン、タイプ1及び2
図8に、復号化エンジンタイプ1の機能上の態様に関する詳細を示している。図8に示すとおり、符号240、242、及び244で示される符号化されたストリーム1ないしNが、各プレーヤのヘッドホンに関して復号化するための2つの符号化されたストリームを選択する選択エンジン257に圧縮されたデータを提供する。このケースでは、符号化されたストリーム1.1及び符号化されたストリーム1.2が、デコーダ168aに入力するために選択され、デコーダ168aにおいて、ストリームは、復号化に先立ってミクサ252によってミキシングされる。デコーダの出力は、ヘッドセット248に関して音声コミュニケーションモジュール内部のDACに供給されるPCMデータである。同様に、他のプレーヤのヘッドホンのそれぞれに関して、別のデコーダ168bが、圧縮されたデータとして符号化された音声ストリームを受け取り、このストリームが、ミキシングされて復号化される。図示するとおり、第4のプレーヤに関するデコーダは、符号化された音声ストリーム4.1及び4.2をミキシングするミクサ254を含み、デコーダが、音声コンソール上の第4のプレーヤ用のヘッドホン250を駆動するアナログ信号を提供するDACに供給されるPCMデータを生成するようになっている。もちろん、4名より少ないプレーヤがゲームコンソールを使用している場合が存在し、その場合、アクティブである必要があるデコーダは、4つより少ない。
【0084】
復号化エンジンタイプ1と復号化エンジンタイプ2の両方に対する代替の実施形態は、(ブロック226における)優先順位の付けられた音声ストリームを、宛先の受け手の音声コミュニケーションモジュール内部のDSPに直接に伝送する。
【0085】
タイプ2復号化エンジンの機能上の態様を図9Aに示している。この場合も、符号240、242、及び244で表される符号化されたストリーム1ないしNが、選択エンジン260に入力され、エンジン260は、聴取を行っており自分に向けられた音声ストリームを有する各プレーヤに関して、最大で4つ、最小で1つのデコーダストリームを選択する。このケースでは、4つの並列デコーダ262が、4つの選択された符号化された音声ストリームの圧縮されたデータを受け取る。次に、デコーダは、その圧縮されたデータを復号化し、結果のPCMデータを、音声ストリームが向けられた各プレーヤに関するミクサに供給する。このケースでは、第1のプレーヤが、符号264で識別されるミクサ内部のミクサ270によってミキシングされる他のプレーヤからの2つの音声ストリームを受け取る。図示していないが、ゲームにおいて他のプレーヤから音声コミュニケーションを受け取る他のプレーヤのそれぞれも、4つの並列デコーダの出力がミキシングのために印加される別個のミキシングビン(bin)を備えている。例えば、第4のプレーヤが、符号266で識別されるミクサ内部のミクサ272によってミキシングされる3つの音声ストリームを受け取る。次に、結果のPCMデータが、第4のプレーヤ用のヘッドセット250に印加される。したがって、各プレーヤは、そのプレーヤに割り当てられた4つ1組(four-in-one)ミキシングビンによってミキシングされた1つないし4つの音声ストリームを受け取ることができる。
【0086】
(ブロック260における)別の実施形態は、デコーダ262、ならびにミクサ264及び266を迂回し、圧縮されたデータをヘッドホン248及び250にそれぞれ結合された音声コミュニケーションモジュールのDSPに伝送する。
【0087】
タイプ2の復号化エンジンで使用するための代替の手法を図9Bに示している。この実施形態では、デコーダとミクサの相対的配置が、図9Aで示したものとは逆になっている。具体的には、各プレーヤが、ネットワークを介して着信する圧縮されたデータを受け取り、ミキシングするように結合された2ストリームミクサを備えている。2ストリームミクサ280がプレーヤ1に提供され、2ストリームミクサ282がプレーヤ2に提供され、2ストリームミクサ284がプレーヤ3に提供され、また2ストリームミクサ286がプレーヤ4に提供されている。したがって、最大で2つの音声ストリームの圧縮されたデータが、プレーヤごとの以上のミクサのそれぞれに入力され、ミキシングされて、4ストリーム並列デコーダ288に入力するために各ミクサから単一のミキシングされたストリームが提供される。次に、このデコーダは、圧縮されたデータを復号化して、別のプレーヤからの音声コミュニケーションの宛先の受け手である各プレーヤのヘッドホン248、252、253、及び250に供給されるPCMデータを生成する。
【0088】
さらに別の実施形態は、2ストリームミクサ280、282、284、及び286に伝送された圧縮されたデータが、ヘッドホン248、252、253、及び250にそれぞれ結合された音声コミュニケーションモジュールのDSPによって復号化されるようにする。
【0089】
他のプレーヤとの音声コミュニケーションの制御
前述したとおり、プレーヤは、挙動の問題を理由に、またはその他の理由で特定のプレーヤとのさらなる音声コミュニケーションを除外するオプションを有する。例えば、ある特定の別のプレーヤが、過度の冒涜的な言葉を使用する傾向にある場合、プレーヤは、その別のプレーヤとさらなるコミュニケーションをとらないことを選択することが可能である。各ゲームは、一般に、プレーヤが、現行のゲームセッション及び将来のゲームセッションに関して別のプレーヤとの音声コミュニケーションをミュートにするオプションを提供し、また、プレーヤが、現行のゲームセッションに限って別のプレーヤとの音声コミュニケーションをミュートにできるようにすることが可能であることも企図されている。図13、13A、及び13Bは、音声コミュニケーションのこの制御を、「マイゲーム(MY GAME)」と呼ばれるゲームにおいて実施できるようにする例としてのダイアログボックス430を示している。この架空のゲームは、プレーヤリストボックス432に示すとおり、プレーヤの各人をリストする。プレーヤリストボックス432は、選択バー434で示されるとおり、先頭にリストされるプレーヤが選択されている6名のプレーヤを含んでいる。「アベンジャ(Avenger)」というエイリアスを使用してゲームを行うこのプレーヤは、そのエイリアスと同じ行で、ダイアログの1つの列に示される話者記号436で示されるとおり、音声コミュニケーション能力を有する。「アイスマン(Iceman)」及び「レースオックス(Raceox)」というエイリアスをそれぞれ使用するプレーヤは、以上のエイリアスのどちらの同じ行にも、その列で話者記号436を欠いていることから明らかなとおり、音声コミュニケーション能力を有さない。プレーヤリストボックス432を見ている現行のプレーヤとの音声コミュニケーションから、リストされているプレーヤの任意のプレーヤをミュートにすることができるようにするラジオボタン438が提供されている。このケースでは、ラジオボタン438で示されるとおり、アベンジャが、プレーヤによって選択されている。プレーヤが選択されたとき、選択されたプレーヤを特定し、このプレーヤが、現在、ゲームの参加者の1人であり、音声コミュニケーションモジュールを有することを示すウインドウ440が開く。プレーヤリストボックス432を見ているプレーヤが、選択ボタン442をクリックした場合、異なる状態に切り替えることができるオプションバー452を含む音声コミュニケーションステータスセレクト450が開く。図13Aに示すとおり、オプションバー452は、選択されたプレーヤが、このオプションを選択しているプレーヤとの口頭のコミュニケーションをとることができるようになっていることを示す。図13Bでは、オプションバーが、状態454に切り替えられており、このことは、その状態を見ているプレーヤが、選択されたプレーヤを現行のゲームセッションに関してミュートにするのを望むことを示す。プレーヤが行う選択に応じて、話者記号436が変化する。図13に示したものの代わりに、プレーヤが、選択された特定のプレーヤをミュートにするオプションを選択した場合、図示した話者記号の周りにダッシュボックス(dash box)が現れる。このタイプのミュート処理は、現行のゲームセッション後、終了する。他方、特定のプレーヤが選択的にロックアウトされた場合、ダッシュヘビーバーボックス(dash heavy-bar box)がスピーカ記号436の周りに追加される。その場合、あるプレーヤをミュートにする決定は、ゲームセッション内からその決定を行ったプレーヤによって、またはゲームコンソールのシステムコントロールを使用することによってだけオフにすることができる。さらに別の記号(図示せず)が、ヘッドホンを介してではなく、受け手のプレーヤのゲームコンソールに接続されたラウドスピーカ(例えば、テレビジョンスピーカまたはモニタスピーカ)を介して対応するプレーヤに関する音声コミュニケーションが再生されることを示すのに使用される。このオプションは、ヘッドセットを着用しないことを好むプレーヤによって選択されることが可能であるが、それほど望ましくない。というのは、プレーヤが、他のプレーヤと口頭でコミュニケーションをとるのにマイクロホンを使用していないからである。
【0090】
数名のプレーヤが、ある特定のプレーヤに関する否定的なフィードバックを、冒涜的な言葉の過度の使用、または性的に露骨な言葉の使用などの容認できないと見なされるそのプレーヤの口頭の挙動に基づいて提供した場合、オンラインゲームサービスが、受け取られた苦情の数がしきい値を超えたことを自動的に判定し、その特定のプレーヤが、さらなる音声コミュニケーションを禁止されるようにする。この禁止は、最初、1週間などの限られた期間にわたり、後に、しきい値を超えてさらなる苦情が受け取られた場合、その特定のプレーヤを永久に音声コミュニケーションから締め出すことが可能である。このように禁止処分を受けた特定のプレーヤには、最初、音声コミュニケーション能力の一時的な停止処分が通知され、次に、そのプレーヤの挙動が永久的な停止処分をもたらした場合、その結果が通知される。プレーヤが、ゲームコンソール上でオンラインゲームサービスにログインするたびに、サインインプロセスの一環として許可フラグがゲームコンソールにダウンロードされる。このフラグは、システムの様々な態様に関する情報を含む。フラグの1つが、特定のプレーヤが音声チャネルに参加する許可を有するかどうかを判定する。したがって、ある特定のプレーヤが、サービスの規定または行動規範に違反した場合、プレーヤが音声でコミュニケーションをとる能力を制御するビットが、そのような音声コミュニケーションを除外するように変更されることが可能である。
【0091】
プレーヤが、ある特定のプレーヤを音声コミュニケーションから除外することを選択すると、その特定のプレーヤの身元が、好ましくは、オンラインゲームサービスに伝送され、その選択を行ったプレーヤの身元に関連して記憶され、あらゆるゲームの将来のセッションにおいて、そのような決定を行ったプレーヤが、その特定の他のプレーヤからの音声コミュニケーションを全く受け取らず、またその特定の他のプレーヤに対して音声コミュニケーションを全く伝送しないようにする。この決定は、その特定の他のプレーヤに明らかではない。というのは、ゲームにおけるプレーヤのステータスを示すダイアログボックスは、単に、その決定を行ったプレーヤが音声コミュニケーション能力を欠いていることの指示をその特定の他のプレーヤのビュー上で表示し、その決定を行ったプレーヤに表示されるダイアログにおいて、その特定の他のプレーヤのミュートにされたステータスが示されるからである。したがって、その特定のプレーヤが、使用するエイリアスを変更した、または異なるゲームコンソールを使用してサインオンしたとしても、プレーヤによって行われたその特定のプレーヤに関する音声コミュニケーションの禁止は、有効であり続ける。
【0092】
また、PCMデータが、発話の各セグメントに関連するリップ位置情報も含むことも企図されている。リップ同期情報は、生成されて、PCMデータとともにエンコーダに伝送され、圧縮されたデータに変換され、受け手のプレーヤに伝送されて、あるプレーヤが話しているとき、ゲームにおいてそのプレーヤによって代表され、制御されるキャラクタが、そのプレーヤによって話されている語と同期して話しているように見えるようになる。話しているプレーヤを表すグラフィックキャラクタの性質に応じて、「口」の性質は、人間の体の通常の口唇部分のものとは異なる可能性がある。例えば、ゲームにおけるキャラクタは、そのキャラクタが話すときに動く大顎(mandibles)を有するエイリアンである可能性がある。それでも、キャラクタの口唇部分を話される語と同期することにより、ゲームプレーの現実感が高まる。グラフィックキャラクタ及び話される語を使用してリップ同期を実現することの詳細が、本出願と同じ譲受人に譲渡された米国特許第6067095号明細書で開示されており、この特許の開示及び図面は、参照により明確に本明細書に組み込まれている。あるいは、リップ同期情報は、復号化中、圧縮されたデータから抽出することが可能である。
【0093】
以下、米国特許第6067095号明細書で開示されている内容を説明する。
【0094】
本実施形態は、話をするアニメーションのキャラクタの口唇の位置及び口の開きを決定するためのシステムを対象とする。より詳細には、本実施形態は、アニメーションのキャラクタまたは機械的キャラクタの口唇の位置及び口唇間の開きを、キャラクタが話している語と同期させるための方法及びシステムに関する。一実施形態では、本実施形態は、ワシントン州レッドモンドのマイクロソフトコーポレーションによって市販されるリアルメーション(Realmation)システム(商標)に組み込まれる。
【0095】
次に、いくつかの図のすべてで同様の符号が同様の要素を表す図面を参照し、本実施形態の態様、及び例としての動作環境を説明する。
【0096】
例としての動作環境
本実施形態の態様を、無線周波数(RF)通信チャネルを介して1つまたは複数のスレーブデバイスと通信し、かつ制御するマスタデバイスを含むシステムの状況で説明する。より具体的には、本実施形態の態様は、「リアルメーション」システム内部で特に適用可能である。「リアルな(realistic)」という語と「アニメーション」という語を組み合わせることから由来する「リアルメーション」は、ワシントン州レッドモンドのマイクロソフトコーポレーションによって開発された技術を表すものである。リアルメーションシステムの例には、機械的キャラクタなどの1つまたは複数のスレーブデバイスと通信し、かつ制御する、ディスプレイを備えたコンピュータシステムなどのマスタデバイスが含まれる。マスタデバイスは、ディスプレイ上でアニメーションのオーディオ/ビデオプレゼンテーションのシーンを提供し、他方、それと同時に、1つまたは複数の機械的キャラクタに制御情報及び音声データを伝送する。機械的キャラクタは、制御情報及び音声データを受け取ることに応答して、アニメーションのオーディオ/ビデオプレゼンテーションの状況に沿って動き、話をする。
【0097】
マイクロソフトコーポレーションの技術者が、次の2つの主な構成要素を含むリアルメーション製品を開発している。すなわち、マスタデバイスとして動作するリアルメーション制御システム、及びスレーブデバイスとして動作する1つまたは複数のリアルメーションパフォーマである。リアルメーションパフォーマには、産業目的、教育目的、研究目的、エンターテイメント目的、またはその他の同様な目的で有用な様々なデバイスが含まれる可能性がある。各リアルメーションパフォーマは、リアルメーション制御システムを送信元とする信号を受信し、復調し、復号化するためのRFトランシーバシステムを含む。リアルメーション制御システムを送信元とする信号は、制御情報及び音声データを含む。また、各リアルメーションパフォーマ内部のRFトランシーバは、信号を符号化し、変調し、リアルメーション制御システムに伝送することもできる。この伝送信号は、リアルメーションパフォーマに関するステータス情報をリアルメーション制御システムに搬送する。
【0098】
リアルメーション制御システムは、アニメーションのオーディオ/ビデオプレゼンテーションを表示しながら、1つまたは複数のリアルメーションパフォーマの動作を統制する。リアルメーション制御システムは、リアルメーションデータソース、リアルメーションリンクマスタ、及び表示システムを含む。リアルメーションデータソースは、リアルメーションリンクマスタを制御し、リアルメーションデータの入力を提供するコンピュータシステムなどの能動的なデバイスであることが可能である。あるいは、リアルメーションデータソースは、リアルメーションリンクマスタにリアルメーションデータを送り込むコンピュータ、VCR、またはTVチューナなどの受動的なデバイスであることが可能である。別の代替案には、リアルメーションデータソースをリアルメーションリンクマスタと結合して、「スマート」リアルメーションリンクマスタを形成することが含まれる。構成に関わらず、リアルメーションデータソースは、リアルメーションデータの入力を提供し、リアルメーションリンクマスタが、そのリアルメーションデータを1つまたは複数のリアルメーションパフォーマに伝送する。
【0099】
リアルメーションリンクマスタの主な機能は、リアルメーションデータソースからリアルメーションデータを受け取り、そのリアルメーションデータを符号化し、符号化されたリアルメーションデータを1つまたは複数のリアルメーションパフォーマに伝送することである。さらに、リアルメーションリンクマスタは、リアルメーションパフォーマから応答信号を受け取り、その応答信号を復号化してリアルメーションデータを回復することができる。
【0100】
リアルメーション製品の2つの例としての実施形態には、シンプレックス実施形態及びデュープレックス実施形態が含まれる。リアルメーション制御システム、リアルメーションリンクマスタ、及びリアルメーションパフォーマの例としての実施形態を、マイクロプロセッサベースのシステム上で実行されるプログラムの状況で一般的に説明する。本実施形態の実施態様は、様々なタイプのプログラムを含み、様々なプログラミング言語を使用し、また様々なタイプの計算機器で動作することが可能であることが、当業者には認められよう。さらに、例としての実施形態の説明では、リアルメーション制御システムは、RF通信チャネルを介してリアルメーションパフォーマを制御するものとして説明するが、RF通信チャネルに代用されるものには、光ファイバリンク、銅線、赤外線信号などの他の通信媒体が含まれる可能性があることが、当業者には理解されよう。
【0101】
一般に、本明細書で定義するプログラムには、特定のタスクを行う、または特定の抽象データ型を実装するルーチン、サブルーチン、プログラムモジュール、構成要素、データ構造等が含まれる。さらに、本実施形態の態様は、他のコンピュータシステム構成にも適用可能であることが、当業者には理解されよう。他のコンピュータシステム構成には、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの家庭用電化製品またはプログラマブル家庭用電化製品、ミニコンピュータ、メインフレームコンピュータ等が含まれるが、以上には限定されない。また、本実施形態の態様は、通信網を介してリンクされたリモート処理デバイスによってタスクが行われることを含む分散コンピューティング環境の状況においても適用可能である。分散コンピューティング環境では、プログラムモジュールは、ローカルのメモリ記憶デバイスとリモートのメモリ記憶デバイスの両方の中に配置されていることが可能である。
【0102】
シンプレックス実施形態とデュープレックス実施形態の両方において、リアルメーションパフォーマは、子供たちに対話式の学習及びエンターテイメントの環境を提供することを目的とする費用の低いアニメーションの機械的キャラクタである。最低限、各リアルメーションパフォーマは、受信機システム、音声合成器、スピーカ、処理ユニット、及び1つまたは複数のサーボモータを含む。受信機システムがリアルメーションデータを受信したことに応答して、処理ユニットが、そのリアルメーションデータの内容によって決まる仕方で復号化、解釈、及び応答を行う。処理ユニットの応答には、1つまたは複数のサーボモータを作動させること、及び/または音声合成器に入力を提供することが含まれることが可能である。
【0103】
デュープレックス実施形態では、各リアルメーションパフォーマは、1つまたは複数のセンサデバイス、及び送信機システムをさらに含む。センサデバイスは、子供が手を握り締めたこと、目を覆ったこと、またはリアルメーションパフォーマの位置を変えたことなどのアクションを検出することができる。センサからの出力信号を監視することにより、処理ユニットは、ステータス情報を収集することができる。リアルメーション制御システムから要求を受け取ったとき、または自律的な判断を行うことにより、処理ユニットは、センサステータス情報をリアルメーション制御システムに伝送することができる。センサステータス情報を受信したことに応答して、リアルメーション制御システムは、その情報に相応する仕方でアニメーションのオーディオ/ビデオプレゼンテーションを変更することができる。例えば、子供がリアルメーションパフォーマの目を覆ったアクションに応答して、アニメーションのオーディオ/ビデオプレゼンテーションを「いないいないばあ」の遊びに切り替えることができる。
【0104】
したがって、デュープレックス実施形態では、リアルメーション制御システムは、1つまたは複数のリアルメーションパフォーマと双方向通信を行う。リアルメーション制御システムのこの例としての実施形態の説明では、パーソナルコンピュータ上で実行され、マイクロプロセッサベースの通信デバイス上で実行される別のプログラムと協働するプログラムを説明するが、独立型プラットフォーム上で実行される単一のプログラム、または無線通信機器を備えた分散コンピューティングデバイスなどの他の実施態様でも十分である可能性があることが、当業者には認められよう。
【0105】
シンプレックス実施形態では、リアルメーション制御システムは、1つまたは複数のリアルメーションパフォーマと単一方向通信を行う。リアルメーション制御システムのシンプレックス実施形態の説明では、マイクロプロセッサベースの通信デバイス上で実行されるプログラムとインターフェースを取るビデオカセットレコーダ(VCR)、またはケーブルTVボックスを説明するが、直接放送信号、レーザディスクプレーヤ、ビデオテーププレーヤ、CD−ROMにアクセスする計算デバイスなどの他の実施態様でも十分である可能性があることが、当業者には認められよう。さらに、この実施形態には、独立型構成で動作させるためにVCR、または同様のデバイスをマイクロプロセッサベースの通信デバイスに統合することが含まれることが可能である。
【0106】
マスタデバイスとスレーブデバイスの間の通信を振幅変調(「AM」)技術に従って形成されるRF信号伝送の状況で説明する。RF信号は、あるデバイスから別のデバイスにデジタル情報の記号表現を転送するのに使用される。RF信号は、デジタルデータの記号表現の値に基づき、搬送波信号の振幅を所定の仕方で変調することによって生成される。以上のデバイス間で情報を伝送するための様々な通信技術を利用することができ、AM技術の使用を説明することにより、本実施形態の何らかの態様の原理が制限されるわけではないことを理解されたい。
【0107】
次に、いくつかの図面のすべてで同様の符号が同様の要素を表している図面を参照すると、本実施形態の態様、及び例としての動作環境が記載されている。図14〜20は、以下の考察と併せて、本実施形態を実装することができる適切な環境の簡単な一般的説明を提供することを目的としている。
【0108】
デュープレックス実施形態:パーソナルコンピュータベースのシステム
図14は、本実施形態のデュープレックス実施形態のための例としての環境を示している。この環境は、リアルメーションパフォーマ20060を制御し、リアルメーションパフォーマ20060と対話を行うリアルメーション制御システム20010を含む対話式学習状況を子供に提供する。リアルメーション制御システム20010は、従来のパーソナルコンピュータ20020、リアルメーションリンクマスタ20080、アンテナ20088、スピーカ20043、及び表示デバイス20047を含む。パーソナルコンピュータ20020は、ハードディスクドライブ20027、磁気ディスクドライブ20028、及び/または光ディスクドライブ20030を含むことが可能である。
【0109】
動作中、リアルメーション制御システム20010は、表示デバイス20047上、及びスピーカ20043上でオーディオ/ビデオプレゼンテーションを制御する。さらに、リアルメーション制御システム20010は、リアルメーションデータをリアルメーションパフォーマ20060に伝送する。リアルメーションデータは、リアルメーションパフォーマ20060の動作を制御するための制御データ及び音声データを含む。リアルメーションデータを伝送するプロセスは、リアルメーションデータを符号化すること、符号化されたリアルメーションデータで搬送波を変調すること、及び変調された搬送波をRF信号としてアンテナ20088からRF通信チャネル20015を介して送信することを含む。
【0110】
リアルメーションパフォーマ20060は、アンテナ20068でリアルメーション制御システムからのRF信号を受信する。受信機システム20061〜20067が、受信されたRF信号を処理してリアルメーションデータを回復する。リアルメーションパフォーマ20060は、受信されたリアルメーションデータを解釈し、リアルメーションパフォーマ20060内部に実現された、少なくとも1つの口サーボモータ20069aを含む1つまたは複数のサーボモータ20069a〜20069fの動作を制御することにより、かつ/またはスピーカ20071で聞こえるように出力されるように音声データを提供することにより、そのリアルメーションデータに応答する。したがって、適切なリアルメーションデータをリアルメーションパフォーマ20060に伝送することにより、リアルメーションパフォーマ20060が動き、オーディオ/ビデオプレゼンテーションの延長であるかのように話すことを生じさせる。
【0111】
また、リアルメーションパフォーマ20060は、光センサ及びタッチセンサ20070a〜20070fも含む。子供が適切な仕方でリアルメーションパフォーマ20060に触れた、リアルメーションパフォーマ20060を握り締めた、または動かしたことに応答して、リアルメーションパフォーマ20060内部の光センサ及び/またはタッチセンサ20070が、ステータス情報を生成することができる。リアルメーション制御システム20010からのコマンドに応答して、リアルメーションパフォーマ20060は、ステータス情報をリアルメーション制御システム20010による処理のために、RF通信チャネル20015を介してリアルメーションリンクマスタ20080に伝送することができる。ステータス情報を受信し、それを解釈することにより、リアルメーション制御システム20010は、そのステータス情報に相応する仕方でオーディオ/ビデオプレゼンテーションの進行を変更することができる。
【0112】
図15は、デュープレックス実施形態のリアルメーション制御システム20010を実装するための例としてのシステムを示す図である。この例としてのシステムは、処理ユニット20021、システムメモリ20022、及びシステムメモリを処理ユニット20021に結合するシステムバス20023を含む従来のパーソナルコンピュータ20020を含む。システムメモリ20022は、読取り専用メモリ(ROM)20024及びランダムアクセスメモリ(RAM)20025を含む。ROM20024は、始動中などにパーソナルコンピュータ20020内部の要素間で情報を転送するのを助ける基本ルーチンを含む基本入力/出力システム20026(BIOS)のためのストレージを提供する。パーソナルコンピュータ20020は、ハードディスクドライブ20027、取外し可能なディスク20029に対して読取り及び書込みを行う目的の磁気ディスクドライブ28、及びCD−ROMディスク20031を読み取る、またはその他の光媒体に対して読取り及び書込みを行う目的の光ディスクドライブ20030をさらに含む。ハードディスクドライブ20027、磁気ディスクドライブ20028、及び光ディスクドライブ20030は、それぞれ、ハードディスクドライブインターフェース20032、磁気ディスクドライブインターフェース20033、及び光ドライブインターフェース20034を介してシステムバス20023とインターフェースを取る。以上のドライブ、及び関連するコンピュータ可読媒体により、パーソナルコンピュータ20020のための不揮発性ストレージが提供される。コンピュータ可読媒体の上記の説明は、ハードディスク、取外し可能な磁気ディスク、及びCD−ROMディスクについて述べているが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ等の、コンピュータによって読取り可能な他のタイプの媒体も例としての動作環境において使用できることが、当業者には理解されよう。
【0113】
オペレーティングシステム20035a、20035b、1つまたは複数のアプリケーションプログラム20036a、20036b、その他のプログラムモジュール20037a、20037b、及びプログラムデータ20038a、20038bを含むいくつかのプログラムモジュールが、ドライブ20027〜20030、及びRAM20025の中に記憶されることが可能である。ユーザは、キーボード20040、及びマウス20042などのポインティングデバイスを介してパーソナルコンピュータ20020にコマンド及び情報を入力することができる。他の入力デバイス(図示せず)には、マイクロホン、ジョイスティック、トラックボール、ライトペン、ゲームパッド、スキャナ、カメラ等が含まれることが可能である。以上の入力デバイス、及びその他の入力デバイスは、しばしば、システムバスに結合されたシリアルポートインターフェース20046を介して処理ユニット20021に接続されるが、ゲームポートまたはユニバーサルシリアルバス(universal serial bus)(USB)などの他のインターフェースで接続してもよい。また、コンピュータモニタ20047、または他のタイプの表示デバイスも、ビデオアダプタ20048などのインターフェースを介してシステムバス20023に接続される。1つまたは複数のスピーカ20043が、オーディオアダプタ20044などのインターフェースを介してシステムバスに接続される。モニタ及びスピーカに加えて、パーソナルコンピュータは、通常、プリンタやプロッタ(plotter)などの他の周辺出力デバイス(図示せず)も含む。
【0114】
パーソナルコンピュータ20020は、リモートコンピュータ20049のような1つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境において動作することが可能である。リモートコンピュータ20049は、サーバ、ルータ、ピアデバイス、またはその他の一般的なネットワークノードであることが可能であり、通常、パーソナルコンピュータ20020に関連して説明した要素の多く、またはすべてを含むが、図15では、メモリ記憶デバイス20050だけを示している。図15に描いた論理接続は、ローカルエリアネットワーク(LAN)20051、及びワイドエリアネットワーク(WAN)20052を含む。以上のタイプのネットワーキング環境は、オフィス、企業全体のコンピュータ網、イントラネット、及びインターネットにおいて一般的である。
【0115】
LANネットワーキング環境で使用されるとき、パーソナルコンピュータ20020は、ネットワークインターフェース20053を介してLAN20051に接続される。WANネットワーキング環境で使用されるとき、パーソナルコンピュータ20020は、通常、インターネットなどのWAN20052を介して通信を確立するためのモデム20054、または他の手段を含む。内部にあることも、外部にあることも可能なモデム20054は、シリアルポートインターフェース20046を介してシステムバス20023に接続される。ネットワーク化された環境では、パーソナルコンピュータ20020に関連して描いたプログラムモジュール、またはプログラムモジュールの部分が、リモートのメモリ記憶デバイスの中に記憶されることが可能である。図示したネットワーク接続は、例としてのものであり、コンピュータ間で通信リンクを確立する他の手段も使用できることが理解されよう。
【0116】
パーソナルコンピュータ20020は、処理ユニット20021が、様々なMIDI対応デバイス(すなわち、電子キーボード、シンセサイザ等)を制御する手段を提供するミュージカルインスツルメンテーションデジタルインターフェース(musical instrumentation digital interface)(「MIDI」)アダプタ20039を含む。また、MIDIアダプタにより、処理ユニット20021がリアルメーションリンクマスタ20080を制御できるようになることが可能である。MIDIアダプタは、システムバス23を介してデータを受け取り、そのデータをMIDIプロトコルに従って形式設定し、そのデータをMIDIバス20045を介して伝送することで動作する。MIDIバスに接続された機器が、MIDI形式のデータの伝送を検出し、そのデータを無視すべきか、または受け入れて処理すべきかを判定する。したがって、リアルメーションリンクマスタ20080が、MIDIバス上のデータを検査し、リアルメーションリンクマスタ20080を宛先の受取り側として明示的に特定するデータを処理する。データを受け取ったことに応答して、リアルメーションリンクマスタ20080は、そのデータをRF通信チャネル20015を介して伝送することができる。
【0117】
図16は、リアルメーションリンクマスタ20080を定義する様々な構成要素及び/またはプロセスを示すブロック図である。最初、コンピュータ20020上で実行されているプログラムが、データを生成することにより、またはコンピュータ20020がアクセスすることのできる記憶媒体からデータを取得することによってリアルメーションデータを獲得する。さらに、プログラムは、リアルメーション特有のプロトコルに従ってそのリアルメーションデータを形式設定することができ、あるいは、プログラムは、事前に形式設定されたリアルメーションデータを記憶媒体から取得することができる。プログラムは、MIDIアダプタ20039及び20081、ならびにMIDIバス20045を含むMIDIインターフェースを介して、そのリアルメーションデータをリアルメーションリンクマスタ20080に転送する。このプロセスは、リアルメーションデータをMIDI形式にパッケージ化しなおすこと含む。MIDIインターフェースは、コンピュータ20020とリアルメーションリンクマスタ20080の間でリアルメーションデータを転送するのに使用することができるいくつかの可能なインターフェースの1つに過ぎないことが、当業者には理解されよう。代替のインターフェースには、RS232、セントロニクス(Centronix)、及びSCSIなどのインターフェースが含まれるが、以上には限定されない。
【0118】
プロトコルハンドラ(handler)20083が、MIDIアダプタ20081からMIDI形式のデータを受け取り、MIDIの形式設定を除去してリアルメーションデータを回復する。このプロセス中、プロトコルハンドラ20083は、リアルメーションデータ、及び/またはMIDI形式のデータをデータバッファ20082の中に一時的に記憶することができる。また、プロトコルハンドラ20083は、データを伝送する準備としてリアルメーションデータに対して他の操作も行うことができる。リアルメーションデータを伝送する前に、データエンコーダプロセス20084が、リアルメーションデータを符号化して、符号化されたリアルメーションデータをRF送信機20086に提供する。RF送信機は、符号化されたリアルメーションデータを使用して搬送波を変調した後、変調された搬送波をアンテナ20088からリアルメーションパフォーマ20060(図17)にRF通信チャネル20015を介して伝送する。
【0119】
また、リアルメーションリンクマスタ20080は、1つまたは複数のリアルメーションパフォーマ20060、または他のデバイスからのリアルメーションデータを搬送する信号も受信することができる。リアルメーションリンクマスタ20080は、その信号をアンテナ20088で検出し、その信号をRF受信機87に提供する。RF受信機20087は、受信された信号を復調し、符号化されたリアルメーションデータを回復し、その符号化されたリアルメーションデータをデータデコーダプロセス20085に提供する。データデコーダプロセス20085は、符号化されたリアルメーションデータを復号化し、復号化されたリアルメーションデータをプロトコルハンドラ20083に提供する。プロトコルハンドラ20083は、復号化されたリアルメーションデータをMIDI形式にパッケージ化し、MIDIインターフェース20081を介してそのMIDI形式のデータをコンピュータ20020に転送する。プロトコルハンドラ20083、及び/またはMIDIインターフェース20081は、処理中、リアルメーションデータをデータバッファ20082の中に一時的に記憶することができる。
【0120】
MIDIインターフェース20039で情報を受け取ると、コンピュータ20020は、そのMIDI形式のデータからリアルメーションデータを回復し、次に、そのリアルメーションデータを処理する。
【0121】
シンプレックス実施形態:ビデオ信号ベースのシステム
図17は、本実施形態のシンプレックス実施形態のための例としての環境を示している。この環境は、リアルメーションパフォーマ20060を制御するリアルメーション制御システム20011を含む学習状況を子供に提供する。リアルメーション制御システム20011は、オーディオ/ビデオ信号ソース20056、リアルメーションリンクマスタ20090、アンテナ20098、ならびにスピーカ20059を含む表示デバイス20057を含む。リアルメーション制御システム20011は、アンテナ20098、及びRF通信チャネル20015を使用してリアルメーションデータをリアルメーションパフォーマ20060に伝送する。このタスクを達するため、リアルメーションリンクマスタ20090は、標準のビデオ接続を介してオーディオ/ビデオ信号ソース20056、及び表示デバイス20057とインターフェースを取る。この標準のビデオインターフェースを介して、リアルメーションリンクマスタ20090は、リアルメーションデータで符号化されたビデオ信号(「符号化されたビデオ」)をオーディオ/ビデオ信号ソース20056から受け取る。リアルメーションリンクマスタ20090は、ビデオ信号からリアルメーションデータを取り出し、次に、RF通信チャネル20015を介してそのリアルメーションデータをリアルメーションパフォーマ20060に転送する。さらに、リアルメーションリンクマスタ20090は、取出しの済んだビデオ信号(「ビデオ」)を表示デバイス20057に送る。オーディオ/ビデオ信号ソース20056は、表示デバイス20057におけるスピーカ20059ともインターフェースを取る。このインターフェースを介して、オーディオ/ビデオ信号ソース20056は、オーディオ/ビデオプレゼンテーションのためのオーディオ信号を提供する。したがって、子供は、リアルメーションリンクマスタ20090が、リアルメーションデータを1つまたは複数のリアルメーションパフォーマ20060に伝送している最中に、表示デバイス20056上、及びスピーカ20059上でオーディオ/ビデオプレゼンテーションを見る/聞くことができる。リアルメーションデータの受信により、リアルメーションパフォーマ20060が、オーディオ/ビデオプレゼンテーションの延長であるかのように動き、話すことが生じさせられる。
【0122】
ビデオカセットレコーダまたはビデオカセットプレーヤ、ケーブル受信ボックス、TVチューナ、レーザディスクプレーヤ、サテライトブロードキャスト、マイクロ波ブロードキャスト、またはビデオ出力を備えたコンピュータを含むが、以上には限定されない様々なソースにより、符号化されたビデオが提供されることが可能である。図18は、リアルメーションデータで符号化されたビデオ信号を生成するパラダイムシステムを示すブロック図である。図18で、コンピュータシステム20020は、ビデオデータエンコーダ20076及びオーディオ/ビデオ信号ソース20056とインターフェースを取る。オーディオ/ビデオ信号ソース20056は、次の2つの出力信号を提供する。すなわち、ビデオ及びオーディオである。これらの出力信号は、ライブカメラフィード(live camera feed)、事前録音の再生、ブロードキャスト受信等を含むことが可能である。コンピュータシステム20020は、制御信号(「制御」)を使用してオーディオ/ビデオソース20056の動作を制御する。制御信号は、オーディオ/ビデオ信号ソース20056からのビデオ信号及びオーディオ信号の出力をゲート制御する。
【0123】
また、コンピュータシステム20020は、ビデオ信号の上に符号化するためのリアルメーションデータも提供する。コンピュータシステム20020は、ビデオデータエンコーダ20076に対してリアルメーションデータを転送し、ビデオ信号のゲート制御を行う。ビデオデータエンコーダは、リアルメーションデータをビデオ信号の上に符号化し、リアルメーションの符号化されたビデオ信号(「符号化されたビデオ」)を生成することによってビデオ信号とリアルメーションデータを結合する。この符号化技術は、ビデオ信号の水平オーバースキャン(overscan)領域の輝度をラインごとに変調することを含む。この技術により、各ラインに単一のリアルメーションデータビットが符号化されることがもたらされる。さらに、ビデオ信号のフィールド境界により、各フレームが固定数のデータ語を含む、リアルメーションデータに関するフレーム構造が提供される。
【0124】
より具体的には、ビデオ信号の各フィールドが、4ビットから構成されるパターン識別語を含む。それぞれの隣接するフィールドの中の4ビットパターン識別語の値は、定義された1組の値を巡回する。各フィールドの中のパターン識別語により、符号化されたビデオ信号が通常のビデオ信号と区別される。通常のビデオ信号では、ランダムな「雑音」がパターン識別語の代わりに現れる。符号化されたビデオ信号からリアルメーションデータを回復しようと試みるデコーダは、このパターンの存在を検出しなければならない。したがって、パターン識別語により、簡単なチェックサム誤り検出の完全性を上回るさらなる層の完全性が回復されたリアルメーションデータに提供される。
【0125】
オーディオ/ビデオ信号ソース20056から符号化されたビデオ信号を受け取るリアルメーションリンクマスタ20090は、その符号化されたビデオ信号からリアルメーションデータを回復し、次に、そのリアルメーションデータをリアルメーションパフォーマ20060(図17に示す)に伝送することができる。あるいは、ビデオブロードキャスト機器20079が、符号化されたビデオ信号をオーディオ信号とともに受け取り、次に、その信号を1つまたは複数の遠隔に配置されたリアルメーションリンクマスタにブロードキャストすることができる。別の代替案では、ビデオ記憶機器20078が、符号化されたビデオ信号をオーディオ信号とともに受け取った後、その信号を将来の取出しのために記憶媒体上に記憶することが可能である。
【0126】
図19は、リアルメーションリンクマスタ20090を定義する様々な構成要素及び/またはプロセスを示すブロック図である。リアルメーションリンクマスタ20090の構成要素のそれぞれは、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実装することができる。リアルメーションリンクマスタ20090のビデオデータ検出器20091が、オーディオ/ビデオ信号ソース20056を起点とするビデオ信号を受け取り、そのビデオ信号が、符号化されたビデオ信号であるかどうかを識別する。ビデオデータ検出器20091が、受信されたビデオ信号の中でパターン識別語の存在を検出した場合、そのビデオ信号は、符号化されたビデオ信号である。ビデオデータ検出器20091は、符号化されたビデオ信号からリアルメーションデータを取り除くことに取りかかり、そのリアルメーションデータをデータ誤りプロセッサ20099に提供する一方で、符号化されていないビデオ信号を表示デバイス20057に提供する。
【0127】
データ誤りプロセッサ20099は、リアルメーションデータを分析して、リアルメーションデータの中に誤りが存在すれば、その誤りを検出して訂正する。リアルメーションデータの中の誤りが訂正された後、プロトコルハンドラ20093が、回復され、確認されたリアルメーションデータを受け取り、1つまたは複数のリアルメーションパフォーマ20060に伝送するためにメッセージパケットを組み立てる。メッセージパケットを組み立てると、プロトコルハンドラ20093は、そのメッセージパケットをデータエンコーダ20094に提供する。データエンコーダ20094は、そのデータを符号化し、符号化されたデータをRF送信機20096に提供する。RF送信機20096は、符号化されたデータを受け取り、その符号化されたデータで搬送波信号を変調する。さらに、RF送信機は、その変調された搬送波をアンテナ20098を介して伝送する。リアルメーションデータの処理中、様々な構成要素が、リアルメーションデータをデータバッファ20092の中に一時的に記憶することができる。
【0128】
表示デバイス20057が、ビデオデータ検出器20091から符号化されていないビデオ信号を受け取り、またオーディオ/ビデオ信号ソース20056からオーディオ信号を受け取る。これらの信号を受け取ることにより、表示デバイス20057上、及びスピーカ20059上のオーディオ/ビデオプレゼンテーションがもたらされる。
【0129】
表示デバイス20057上のオーディオ/ビデオプレゼンテーションと、アンテナ20098から伝送されたリアルメーションデータの間に関係が存在することを理解されたい。リアルメーションデータを検出するプロセス、誤りを訂正するプロセス、リアルメーションデータを符号化するプロセス、及び搬送波を変調するプロセスにより、わずかな遅延が導入される可能性があるが、表示デバイス20057によって受け取られたビデオ信号、及びアンテナ20098から伝送されたリアルメーションデータは、元の符号化されたビデオ信号の同一の領域から獲得されている。この特性により、コンテキストに依存した(context-sensitive)リアルメーションデータをビデオ信号の上に符号化することが可能になる。コンテキストに依存したリアルメーションデータを1つまたは複数のリアルメーションパフォーマに伝送することにより、リアルメーションパフォーマが、オーディオ/ビデオプレゼンテーションに関連する仕方で動き、かつ/または話すことが可能になる。
【0130】
リアルメーションパフォーマ
図20は、リアルメーションパフォーマ20060を定義する様々な構成要素及び/またはプロセスを示す機能ブロック図である。構成要素のそれぞれは、ハードウェアで、ソフトウェアで、またはハードウェアとソフトウェアの組合せで実装することができる。一般に、リアルメーションパフォーマは、ROM、または何らかの他の不揮発性ストレージ媒体からプログラムを取り出し、そのプログラムの命令を実行するためのマイクロプロセッサまたは他の処理ユニットを含む。さらに、リアルメーションパフォーマ20060は、RF無線受信機20067などのハードウェア構成要素、ならびに、場合により、送信機20066、アンテナ20068、読取り可能で書込み可能な記憶メモリ20062、センサ20070、サーボモータ20069、音声合成器20061、及びスピーカ20071を含む。
【0131】
RF受信機20067は、アンテナ68から検出された信号を受け取る。RF受信機は、搬送波を復調し、符号化されたリアルメーションデータを回復することで、受け取られた信号に対して作用する。次に、データデコーダ20065が、符号化されたリアルメーションデータを受け取り、復号化する。プロトコルハンドラ20063が、デコーダ20065から出力される復号化されたリアルメーションデータを受け取り、そのリアルメーションデータを解釈する。リアルメーションデータの内容に基づき、このプログラムは、制御信号及び/または音声データを適切なデバイスに送る。したがって、リアルメーションデータが制御情報を含む場合、モーションサーボモータ20069の1つまたは複数が制御信号を受け取り、作動させられる。さらに、リアルメーションデータが音声データを含む場合、音声合成器20061が、その音声データを受け取り、その音声データをオーディオ信号に変換した後、そのオーディオ信号をスピーカ20071に提供する。リアルメーションデータは、様々なプロセスが行われている最中に、データバッファ20062の中に一時的に記憶することが可能である。
【0132】
また、リアルメーションパフォーマ20060は、光センサ及びタッチセンサ20070を含むことが可能である。センサ70は、圧力、光、温度、またはその他のパラメータの変動に応答してステータス情報を生成することが可能である。リアルメーションパフォーマ20060は、このステータス情報をリアルメーション制御システム20010(図14に示す)に伝送することができる。このプロセスは、プロトコルハンドラ20063においてステータス情報を形式設定すること、データエンコーダプロセス20064においてそのステータス情報を符号化すること、RF送信機20066においてその符号化されたステータス情報で搬送波を変調すること、及び次に、変調された搬送波をアンテナ20068を通じてRF通信パス20015を介して伝送することを含む。
【0133】
人間音声生成
本実施形態の説明に取りかかる前に、人間音声生成に関する簡単な背景を提供することが役立つことが分かるであろう。音声の発声機構(phonatorymechanism)及び分節機構(articulatory mechanism)は、様々な横断面の寸法の管に類似の特性の音響システムと見なすことができる。管の下端、つまり声道には、声門としても知られる声帯間に開口がある。声道の上端は、口唇で終わる。声道は、咽頭(食道から口までのつながり)、及び口、つまり口腔から成る。
【0134】
音声生成プロセスを研究する際、現実感があるが、扱いやすい数学モデルをもたらすやり方で物理システムの重要な特徴を取り出すことが役立つ。声門下のシステムは、肺、気管支、及び気管を含む。この声門下のシステムが、音声の生成のためのエネルギー源の役割をする。音声は、単に、肺から空気が排出され、もたらされる空気の流れが声道のどこかの収縮によって乱されるときにこのシステムから放射される音波である。
【0135】
音声サウンドは、励振の様式に従って3つの別個のクラスに分類することができる。本実施形態は、そのクラスのうち2つ、有声クラス及び無声クラスをその他のパラメータとともに使用して、アニメーションのキャラクタ、または機械的キャラクタの適切な口唇の位置、及び口の開きを決定する。有声サウンドは、緩和振動で声帯が震えるように声帯の緊張が調整された状態で声門を通るように空気を強制し、これにより、声道を励振させる空気の準周期的なパルスを生成することによって生成される。英語の母音のほとんどすべて、及び子音の一部が有声である。
【0136】
無声サウンドは、声道の何らかの地点で、通常、口側の終端の方で収縮を形成し、乱流を生成するのに十分なだけ高い速度でその収縮を通るように空気を強制することによって生成される。無声サウンドの例は、単語、hat、cap、及びsashにおける子音である。ささやいている最中、生成されるすべてのサウンドが、無声である。
【0137】
口唇の位置及び口の開きを決定すること
簡単に説明すると、本実施形態は、話をするアニメーションのキャラクタ、または機械的キャラクタの口の特徴、すなわち、口唇の位置、及び口の開きを決定するためのシステムを提供する。口唇の位置は、アニメーションのキャラクタ、または機械的キャラクタの口唇の形状及び位置を指すものとして使用する。例えば、様々な母音及び子音などの様々なサウンドを人間が発音するには、話者の口唇が、様々な形状または位置に置かれなければならない。本実施形態は、アニメーションのキャラクタ、または機械的キャラクタが話しているサウンドを発音するのに必要な口唇の位置、または口唇の形状を決定することができる。
【0138】
口の開きは、アニメーションのキャラクタ、または機械的キャラクタの口唇間の開きの量を指すものとして使用する。例えば、大声で話している人間は、一般に、ささやいている人間よりも大きい口唇間の開きを有する。口の開きの決定の基礎にあるのは、この理解である。したがって、本実施形態は、アニメーションのキャラクタ、または機械的キャラクタが話しているサウンドを生成するのに必要な口唇間の開きの量を決定するための方法も提供する。口唇の位置と口の開きを組み合わせることにより、本実施形態は、話しているアニメーションのキャラクタ、または機械的キャラクタと、そのキャラクタが話している音声の間で現実感のある同期を提供するのに必要な口の特徴を決定する。
【0139】
本実施形態は、プログラムモジュールによって提供される命令に応答してコンピュータによって行われるコンピュータによって実装されるプロセスであることが、当業者には理解されよう。一実施形態では、プロセスを実行するプログラムモジュールは、コンピュータ20020(図14)上に実装される。ただし、図17に関連して前述したシンプレックス実施形態などの他の実施形態では、プロセスを実行するプログラムモジュールは、リアルメーションリンクマスタ20090(図17)、またはリアルメーションパフォーマ20060(図17)において実装されることが可能である。この実施形態では、リアルメーションリンクマスタ20090、またはリアルメーションパフォーマ20060が、プログラムモジュールによって提供される命令を実行する適切なコンピュータ(図示せず)を含む。
【0140】
次に、図21を参照すると、本実施形態の例としての実施形態によるアニメーションのキャラクタ、または機械的キャラクタに関する口唇の位置及び口の開きを決定するための方法20800を例示する流れ図が示されている。方法20800は、ステップ20805で開始し、ステップ20810に進んで、時間領域音声信号が、デジタル式にサンプリングされるか、またはデジタル式に記録される。好ましくは、音声信号は、16ビットのサンプリング精度を有する44.1kHzのCD品質サンプリングレートでサンプリングされる。44.1kHzが、好ましいサンプリングレートであり、また16ビットが、好ましいサンプリング精度であるが、他のサンプリングレート及びサンプリング精度を使用してもよいことを理解されたい。
【0141】
一実施形態では、時間領域音声信号は、リアルメーションパフォーマ20060(図14及び17)によって話される、歌われる、または別の仕方で生成される語またはサウンドに対応する。さらに別の実施形態では、時間領域信号は、表示デバイス20047(図14)上に表示されるアニメーションのキャラクタによって話される、歌われる、または別の仕方で生成される語またはサウンドに対応する。代替の実施形態では、時間領域信号は、前に説明した図で示されていない他のアニメーションのキャラクタ、または機械的キャラクタによって話される、歌われる、または別の仕方で生成される語またはサウンドに対応することが可能であることも、当業者には認められよう。
【0142】
次に、図22A及び22Bを参照すると、時間領域音声信号をデジタル式にサンプリングすることの概略が提供されている。図22Aは、通常の時間領域音声信号20900を示す図である。x軸が、時間を表し、y軸が、音圧(acoustic pressure)の変動を表している。図22Aに見られるとおり、サウンドが生成されると、話者の口における音圧が、時間とともに変化し、音響的な波、つまり音波がもたらされる。図22Bは、一部分20905を拡大し、拡大部分20910として示した通常の時間領域音声信号20900を示す図である。拡大部分20910は、時間領域音声信号20900がデジタル式にサンプリングされる仕方を示している。各デジタルサンプルは、拡大部分20910において黒のドットで終わる垂直線で表されている。したがって、図22Bから外挿することができるとおり、サンプリングレートが増加するにつれ、時間領域音声信号に関するサンプル数が増加し、これにより、元の時間領域音声信号のより正確なデジタル表現がもたらされる。
【0143】
ステップ20820で、ステップ20810からのサンプリングされた音声信号が、フレームに分けられる、つまり分割される。各フレームは、特定の期間中のデジタルサンプルを含む。好ましくは、各フレームの長さは、20ミリ秒である。したがって、例えば、再サンプリングされた音声信号の長さが2秒であり、かつ各フレームの長さが20ミリ秒である場合、フレームの数は、2秒を20ミリ秒で割ったもの、すなわち、100フレームに等しい。当業者には周知のとおり、ほとんどの音声処理スキームにおける基礎にある想定は、音声信号のプロパティが、時間とともに比較的ゆっくりと変化するということである。この想定は、短いセグメント、つまりフレームが、あたかも固定のプロパティを有する一様のサウンド(sustained sound)からの短いセグメントであるかのように分離され、処理される様々な処理方法をもたらす。したがって、ステップ20820で、再サンプリングされた音声信号をフレームに分割して、以下により詳細に説明するとおり、口唇の位置及び口の開きのより正確な表現を提供するように信号をさらに処理することができる。
【0144】
次に、図22Cを参照すると、フレームに分割された時間領域信号900の図が示されている。フレーム20915、20920、20925、20930、及び20935は、ステップ20820で時間領域信号20900をフレームに分割したときに生成されることが可能なフレームの一部を例示するものである。図22Cは、アナログ音声信号を示しているが、ステップ20820でフレームに分けられる、つまり分割される再サンプリングされた音声信号は、実際には、図22Bの拡大部分20910において示すようなデジタルサンプルから構成されることを認識されたい。
【0145】
図21を再び参照すると、ステップ20825で、再サンプリングされた音声信号の各フレームにウィンドウ(windowing)関数が適用される。ウィンドウ関数は、当業者には周知のデジタル音声処理技術である。ステップ20825で、各フレームにウィンドウ関数が適用されて、各フレームの境界条件の効果が強調されなくなる。好ましくは、フレームの中央のデジタルサンプルは、ウィンドウ関数による影響を受けず、他方、フレームの端に近いサンプルが減衰されて、そのサンプルが強調されなくなる。ハミングウインドウ(Hamming window)が、好ましくは、ステップ825で適用されるウィンドウ関数である。ただし、ハニング(Hanning)ウィンドウ関数、または三角ウィンドウ関数などの、ただし、それらには限定されないその他のタイプのデジタル音声処理ウィンドウ関数もステップ20825で適用することが可能であることを理解されたい。
【0146】
ステップ20825で、フレームのそれぞれにウィンドウ関数が適用された後、ステップ20830で、線形予測符号化(LPC)技術が、フレームのそれぞれに適用される。LPC技術は、人間の声帯、及び人間がサウンドを生成する仕方をモデル化する圧縮された形態の人間の音声をもたらす。ステップ20830でフレームにLPC技術を適用することの一環として、各フレームに関していくつかの属性が判定される。この属性には、音声信号フレームの利得、つまりパワーが含まれる。また、この属性には、いくつかのk係数、つまり反射係数も含まれる。k係数には、ピッチ係数、及び有声/無声係数が含まれる。LPC技術、ならびにLPC技術を介して判定される属性は、音声認識の分野の技術者には周知である。
【0147】
パワー、つまり利得が、各フレームに関して判定される。このパワーは、語または音節が話される際に分散される空気の量を示すものである。パワーは、一般に、増加するにつれて口唇間の開きの量が増大するため、口の開きをよく近似するものである。平方自乗平均(RMS)法、及び予測誤差法(prediction error method)を含むが、それらには限定されない、利得を判定する多くのやり方が存在することが当業者には理解されよう。
【0148】
ピッチ係数は、いくつかの異なる相関法の1つを使用して判定することができる。この方法の中で最も一般的なのは、平均振幅差関数(AMDF)であるが、当業者は、その他の関数を選択することもできる。この相関結果を使用して、あるセグメントの音声が有声であるか、または無声であるかを判定することができる。信号の高い自己相関は、そのセグメントが有声であることを意味する。より低い自己相関は、そのセグメントが無声であることを意味する。
【0149】
ステップ20835で、各フレームに関してステップ20830で判定されたk係数が、ケプストラム(Cepstral)領域にマップされて、各フレームに関していくつかのケプストラム係数がもたらされる。LPC領域からケプストラム領域へのマッピングは、音声認識の分野の技術者には周知である。k係数は、観察者によって聴き取られるものにはうまくマップされないため、ケプストラム領域にマップされる。k係数は、人間の声道の横断面積をモデル化する。したがって、k係数は、音声認識において有効である、すなわち、音声を再現するのに有効であるが、口唇の位置及び口の開きを決定するためにはそれほど有効でない。他方、ケプストラム係数は、どのように人間の音声が投射され、どのように人間の声が他者によって聴き取られるかに関するモデルを提供する。したがって、ケプストラム係数は、話者の口唇の位置に関するよりよいモデルを提供する。ステップ20830で判定された各フレームに関する利得は、変更されないままである。
【0150】
ステップ82040で、各フレームに関してステップ20835で決定されたケプストラム係数がベクトル量子化されて、各フレームに関するベクトル量子化結果が達せられる。ベクトル量子化結果は、各フレームに関するキャラクタの口唇の位置に対応する。ベクトル量子化技術は、当業者には周知である。ステップ840におけるベクトル量子化は、ニューラルネットワーク(neural network)、最小距離マッピング、または当業者に周知の他の技術を使用して達することができる。
【0151】
図23を参照して、ステップ20840で達せられるようなベクトル量子化の代表的な例について述べる。図23は、有声/無声係数及びピッチ係数を表すケプストラム係数を利用したベクトル量子化技術を示す図である。図23のx軸は、ピッチ係数を表し、y軸は、有声/無声係数を表している。図23に示すとおり、ベクトル21005、21010、及び21015は、そのフレームに関するピッチ係数及び有声/無声係数に基づいてマップされている。したがって、ベクトル21005は、あるフレームに関する有声/無声係数及びピッチ係数に対応する。同様に、ベクトル21010及び21015もそれぞれ、あるフレームに関する有声/無声係数及びピッチ係数に対応する。ベクトル量子化を介して、マップされたベクトルを、ベクトルのマッピングに基づく対応するベクトル量子化結果に量子化する、つまり変換することができる。図23では、有声/無声係数及びピッチ係数を使用するマッピング及びベクトル量子化を示しているが、任意の数の様々な係数をマップし、ベクトル量子化することができることが、当業者には認められよう。さらに、ベクトル量子化を使用して、口唇の位置以外のパラメータも決定することができる。例えば、ベクトル量子化を使用して、生成されているサウンドを判定することができ、これは、音声認識アプリケーションにおいて役立つ。ただし、本実施形態の場合、ベクトル量子化結果は、各フレームに関するアニメーションのキャラクタ、または機械的キャラクタの口唇の位置に対応する。
【0152】
ベクトル量子化は、最小距離マッピングにより、ニューラルネットワークを使用することにより(以上のどちらも周知の技術である)、または別の周知のベクトル量子化技術を使用することによって達することができる。図23に示したとおり、ベクトル量子化を介して、ベクトル21005、21010、及び21015が、文字「a」を話しているときに生成されるサウンドに対応することが判定される。というのは、この例では、以上のベクトルは、文字「a」を話しているときに生成されるベクトルの範囲に最も近いからである。したがって、ベクトル21005、21010、及び21015に対応するフレームに関して、アニメーションのキャラクタ、または機械的キャラクタの口唇は、文字「a」のサウンドを生成する位置に置かれなければならないことが判定された。前述したのと同様の仕方で、ベクトル21020、21025、及び21030は、「k」、「t」、または「d」などの硬い子音のどれかを話しているときに生成されるサウンドに対応することが判定される。同様に、ベクトル21035、21040、及び21045は、「sh」のサウンドを話しているときに生成されるサウンドに対応することが判定される。したがって、ベクトル量子化を介して、ステップ20840で、アニメーションのキャラクタ、または機械的キャラクタの口唇の位置を決定できることを見て取ることができる。ただし、キャラクタの口唇の位置は、口の特徴の一部に過ぎない。キャラクタの口の特徴には、LPC技術を適用したことの結果としてステップ20830で判定された利得に対応する口の開きも含まれる。ただし、ステップ20830で判定された利得は、さらに説明するとおり、アニメーションのキャラクタ、または機械的キャラクタに関して滑らかな音声パターンを生成するようにさらに処理する必要がある。
【0153】
利得係数は、例としての句21299のフレームから計算され、図25Aで時間に対してプロットされている。図21を再び参照すると、ステップ20845で、利得の極大及び極小が、所定の数のフレーム内に見出される。次に、図25Bを参照すると、極大21201、21203、21205、21207、21209、21211、21213、21215、及び21217が見出される。極小21200、21202、21204、21206、21208、21210、21212、21214、21216、及び21218が見出される。最小の時間量を下回る利得の極大及び極小を含むすべてのフレームは、ステップ20845で棄却される。例えば、図25Cを参照すると、極大21201及び21215が棄却され、また極小21202及び21216が棄却されている。
【0154】
ステップ20850で、極小を含むフレームに関する利得、及び極大を含むフレームに関する利得が調整される。極小を含むフレームに関する利得は、調整された利得により、極小においてキャラクタの口が完全に閉じていることが生じるように調整される。調整された利得が、極大を含むフレームに関しても決定され、その調整された利得により、極大を含むフレームに関してキャラクタの口が完全に開いていることが生じるようになる。残りのすべてのフレームに関して、すなわち、利得の極小または極大を含まないフレームに関して、利得は、ステップ20830で計算された値からの最小利得レベルと最大利得レベルの間で基準化される。例えば、図25Cを参照すると、極大21203、21205、21207、21209、21211、及び21217が、最大利得レベル21250に調整されている。極小21200、21204、21206、21208、21210、21212、21214、及び21218が、最小利得レベル21260に調整されている。
【0155】
前述し、図25Cに示したとおり、キャラクタの口が各極小で完全に閉じ、各極大で完全に開くように、ステップ20850で調整された利得が計算されて、キャラクタにより自然な口の動きが与えられる。そうでなければ、キャラクタの口唇は、キャラクタの口が明確に開くこと、及び閉じることがないため、唇を震わせてぶつぶつ言っているように見えることになる。ユーザは、キャラクタの口が、所定の時間内に完全に開き、完全に閉じることを予期している。口が完全に開閉しない場合、キャラクタの口唇が決して触れ合わないため、唇を震わせているように見える。口が十分に開かない場合、キャラクタは、ぶつぶつ言っているように見える。利得に関する極小及び極大は、4フレームより少ない間隔で、または4フレームより多い間隔で決定することが可能であることを理解されたい。ただし、60〜80ミリ秒の範囲内で口を完全に開かせ、完全に閉じさせることにより、アニメーションのキャラクタ、または機械的キャラクタに滑らかな口の動きが提供されることが確認されている。
【0156】
したがって、例えば、図25B及び25Cを参照して、フレーム21200〜21204が、第1の語に関する極大及び極小であるものと想定する。第1の極小1200を見出した後、利得分析は、口の最大の開きに設定する次の極大を探す。極大21201は、最後の極小21200に近すぎるため、棄却される。利得分析は、次の極大21203を探索し、極大21203を口の最大の開きとして割り当てる。利得分析は、極大及び極小を探索するこのプロセスを続ける。21205と21207のように、第1の極大が極小に近すぎ、かつ次の極大がその極小から離れすぎている場合、利得分析は、閉じの極小21204と21208の間の距離、つまり期間を極大の数で割り、極大をその割った距離の中央に移動し、また極小をその割った距離の両端に移動する。また、これは、極小及び極大21208〜21214に関しても行われる。極小間の距離が、21214〜21218のように、強い語または音節の区切りとしては小さすぎる場合、利得分析は、極大のなかの最大のものを最大の開きとして選択する。次に、そのセグメント全体が、完全に閉じていることから完全に開いていることまでの範囲の間で基準化される。
【0157】
図21を参照すると、各フレームに関して、ステップ20830からの利得、またはステップ20850からの利得(フレームが、極大または極小を含む場合)、及びステップ20840からのベクトル量子化結果が、ステップ20855で、経験的に導出されたマッピング関数に適用される。前述したとおり、利得は、キャラクタの口唇間の空間の量、すなわち、どれだけ広く口が開いているかを表す。ベクトル量子化結果は、キャラクタが発しているサウンドに関する口唇の位置を表す。一実施形態では、経験的に導出されたマッピング関数に利得、及びベクトル量子化結果を適用することにより、リアルメーションパフォーマ20060の口を駆動するサーボモータ20069によって提示することができる最も似通った口の形状がもたらされる。
【0158】
次に、図24を参照すると、口の形状を決定するのにステップ20855で使用することが可能な経験的に導出されたマッピング関数21100の代表的な例が示されている。図24に示すとおり、各行21105〜21130が、異なる口唇の位置を表し、また各列21135〜21160が、異なる利得値を表している。利得値は、列21135で最低であり、列21160で最高である。各フレームに関する口の特徴を決定するため、口唇の位置、すなわち、行が、口の開き、すなわち、列と組み合わされ、もたらされる口の特徴のセルが決まる。例えば、口唇の位置が、行21110に対応し、かつ利得、つまり口の開きが、列21155に対応するものと想定する。この仮定の場合、もたらされる口の特徴は、セル21165に含まれる。
【0159】
機械的キャラクタの場合、経験的に導出されたマッピング関数は、口のサーボモータを駆動して適切な口の特徴にするようにコマンドが、機械的キャラクタに送られることをもたらすルックアップテーブルとして実装することが可能である。例えば、一実施形態では、このルックアップテーブルは、コンピュータ20020(図15)のシステムメモリ20022の中に記憶することが可能である。ルックアップテーブルから判定された口の特徴がリアルメーションリンクマスタ20080によって制御データとしてリアルメーションパフォーマ20060に送られて、リアルメーションパフォーマの口の特徴を制御するサーボモータ20069aを設定することが可能である。別の例として、アニメーションのキャラクタに関して、経験的に導出されたマッピング関数により、表示デバイス上で口の形状の表示がもたらされることが可能である。次に、セルアニメ製作者が、キャラクタの口の形状を描く際、その表示された口の形状をアニメーションセルに直接に組み込むこと、またはその表示された口の形状を基準として使用することが可能である。
【0160】
ステップ20855で、利得、及びベクトル量子化結果が、経験的に導出されたマッピング関数に適用された後、ステップ20860で、方法は終了する。
【0161】
以上の説明から、本実施形態が、機械的キャラクタとアニメーションのキャラクタの両方に関して口唇の位置及び口の開きを決定するための迅速で、効率的であり、かつ正確な方法を提供することが、当業者には明白であろう。さらに、本実施形態が、微細な細分性を有する口唇の位置及び口の開きを決定するための方法を提供する、すなわち、口唇の位置及び口の開きの正確な表現を提供することも明白であろう。また、本実施形態が、デジタル環境に適合する口唇の位置及び口の開きを決定するための方法を提供することも明白であろう。
【0162】
さらに、リアルメーションパフォーマ20060を含む実施形態においては、音声信号がリアルメーションパフォーマによって話されるには、まず、口の特徴のデータが、リアルメーションパフォーマに送られなければならないことが、当業者には理解されよう。これは、リアルメーションパフォーマ20060の口唇の位置及び口の開きを制御するサーボ69が設定されるのに時間を要するからである。
【0163】
以上、米国特許第6067095号明細書で開示されている内容を説明した。
【0164】
本発明の利点の1つは、ゲームコンソール上のプレーヤの全員に関する音声ストリームを結合して単一の圧縮されたデータストリームにして、限られた帯域幅の範囲内でネットワークを介してデータをより効率的に伝送することである。したがって、同一のゲームコンソール上の複数のプレーヤが、ゲームに参加する他のプレーヤの全員に話しているとき、その複数のプレーヤに関する音声データが結合されて1つのネットワークストリームになる。そのゲームコンソールから複数の音声データストリームを送信する必要がない。
【0165】
本発明の別の利点は、ゲームコンソール上でゲームを行っている可能性があるプレーヤの数の半分である最大数のエンコーダを割り振ることができることである。したがって、ゲーム設計者は、音声コミュニケーションに割り振られるべきリソースの量を決定することができ、また例えば、2つのエンコーダだけを提供し、そのエンコーダが、前述したとおり、ラウンドロビン式に動作することを要求することにより、そのリソースを制限することができる。ラウンドロビン手法を実行する際、前に伝送されたパケットを使用することでわずかに悪影響が存在するが、音声コミュニケーションの質に対する悪影響より、音声コミュニケーションのための計算リソースの使用の制限の方がはるかに重要であり、ゲームプレーの質に対する悪影響が最小限に抑えられる。
【0166】
インターネットまたは他のネットワークを介してゲームに参加しているとき、プレーヤは、オプションとして、行われているゲームに応じて、音声コミュニケーションをとる際の特定の言葉遣いに合意したプレーヤとだけゲームを行うのを選択することが可能である。また、プレーヤは、オプションとしてゲームが唯一、音声コミュニケーション能力を有するプレーヤと行われることを選択することが可能である。同様に、音声コミュニケーション能力のないプレーヤは、やはり音声コミュニケーション能力を有さない他のプレーヤとだけ選択的にゲームに加わることが可能である。
【0167】
本発明をその好適実施形態に関連して説明してきたが、特許請求の範囲の内で本発明に多くの変更を加えるのが可能であることが、当業者には理解されよう。したがって、本発明の範囲は、以上の説明によって全く限定されるものではなく、すべて特許請求の範囲に関連して定められるものとする。
[発明の効果]
【0168】
以上説明したように本発明によれば、ゲームデバイス上の複数プレーヤのリアルタイムな音声コミュニケーションの使用を実現することができる。
【図面の簡単な説明】
【0169】
【図1】本発明の実施形態のマルチプレーヤゲームコンソール及び音声コミュニケーションシステムの概略を示す図である。
【図2】本発明の実施形態の図1のマルチプレーヤゲームコンソール及び音声コミュニケーションモジュールを示すブロック図である。
【図3】本発明の実施形態の音声コミュニケーション能力を有するマルチプレーヤゲームコンソールを示す機能ブロック図である。
【図4】本発明の実施形態のネットワークを介するポイントツーポイント通信で結合された2つのマルチプレーヤゲームコンソールを示す機能ブロック図である。
【図5】本発明の実施形態のネットワークを介して3つの他のマルチプレーヤゲームコンソールと通信するように結合された第1のマルチプレーヤゲームコンソールを示すブロック図である。
【図6】本発明の実施形態の2つの並列エンコーダを有するゲームコンソール上の複数のプレーヤに関する優先順位付け符号化を示す機能ブロック図である。
【図7】本発明の実施形態のマルチプレーヤゲームコンソール上で復号化するパケットをキューから選択する際に本発明によって使用されるステップを示す論理図である。
【図8】本発明の実施形態のマルチプレーヤゲームコンソールにおいて使用されるタイプ1の復号化エンジンを示す機能ブロック図である。
【図9A】本発明の実施形態のマルチプレーヤゲームコンソールにおいて使用されるタイプ2の復号化エンジンを示す機能ブロック図である。
【図9B】本発明の実施形態の図9Aのミクサ及び4ストリーム並列デコーダの詳細を示すブロック図である。
【図10】本発明の実施形態のネットワークを介してサウンドデータの符号化されたパケットを送受信するためのステップのさらなる詳細を示す論理図である。
【図11】本発明の実施形態のマルチプレーヤゲームコンソール上の各プレーヤに関してどのように音声ストリームが受信され、キューに入れられ、復号化されるかを示す機能ブロック図である。
【図12】本発明の実施形態のサウンドパケットのラウンドロビン符号化を実行するステップを示す流れ図である。
【図13】本発明の実施形態のプレーヤ間の音声コミュニケーションを使用するゲームにおいて音声オプションを選択するための例としてのユーザインタフェースを示す図である。
【図13A】本発明の実施形態のマルチプレーヤゲームにおいて別のプレーヤとの音声コミュニケーションを制御する、または除外するのにプレーヤが選択することができる1つのオプションを示す図である。
【図13B】本発明の実施形態のマルチプレーヤゲームにおいて別のプレーヤとの音声コミュニケーションを制御する、または除外するのにプレーヤが選択することができる別のオプションを示す図である。
【図14】デュープレックス実施形態のための例としての環境を示す図である。
【図15】図14に示したデュープレックス実施形態のリアルメーション制御システム(Realmation Control System)を実装するための例としてのシステムを示す図である。
【図16】図14に示したデュープレックス実施形態のリアルメーションリンクマスタを定義する様々な構成要素及び/またはプロセスを示すブロック図である。
【図17】シンプレックス実施形態のための例としての環境を示す図である。
【図18】リアルメーションデータで符号化されたビデオ信号を生成するパラダイムシステム(paradigmatic system)を示すブロック図である。
【図19】図17に示したシンプレックス実施形態のリアルメーションリンクマスタを定義する様々な構成要素及び/またはプロセスを示すブロック図である。
【図20】例としての実施形態によるリアルメーションパフォーマ(Realmation Performer)を定義する様々な構成要素及び/またはプロセスを示すブロック図である。
【図21】例としての実施形態による口の特徴(mouth feature)を決定するための方法を示す流れ図である。
【図22A】通常の時間領域音声信号を示す図である。
【図22B】デジタル式にサンプリングされた拡大部分を含む通常の時間領域音声信号を示す図である。
【図22C】フレームに分割された時間領域信号を示す図である。
【図23】有声/無声(voiced/nonvoiced)係数及びピッチ係数を表すケプストラム係数(Cepstral coefficient)を利用するベクトル量子化技術を示す図である。
【図24】アニメーションのキャラクタまたは機械的キャラクタの口の特徴を決定するのに使用することができる経験的に導出されたマッピング関数の代表的な例を示す図である。
【図25A】時間に対してプロットされた例としての句の利得係数を示す図である。
【図25B】極小及び極大が示された時間に対してプロットされた例としての句の利得係数を示す図である。
【図25C】極小及び極大が基準化された時間に対してプロットされた例としての句の利得係数を示す図である。
【符号の説明】
【0170】
100 電子ゲームシステム
102 ゲームコンソール
104a、104b、104c、104d コントローラ
140、140a、140b、140c、140d 音声コミュニケーションモジュール
144 マイクロホン
146 ヘッドホン
150 CPU
152 メモリ
154、156 デジタル信号プロセッサ
158 アナログ−デジタル変換器
160 シングルストリームエンコーダ
160a 2つの並列エンコーダ
161 デジタル−アナログ変換器
162 ネットワークキュー
162a、162b、162c ネットワークキュー
163 USBインタフェース
164a、164b 選択エンジン
166a、166b ミクサ
168 デコーダ
168a、168b デコーダ
170 ネットワーク
172 ゲームコンソール
174 ネットワークキュー
176 シングルストリームデコーダ
178 ヘッドホン
180 マイクロホン
182 エンコーダ
184、186 ネットワークキュー
188 出力ルータ
190a、190b、190c、190d 音声コミュニケーション
200a、200b、200c、200d プレーヤ
202a、202b、202c マイクロホン
204 ルータ
206 ネットワーク層
210 ゲームコンソール
211a、211b、211c、211d マイクロホン
212 ゲームコンソール
213a、213b、213c、213d
214 ゲームコンソール
215 優先順位付けアルゴリズム
216a、216b プレーヤ
217a、217b、217c、217d
218 プレーヤ
220a、220b、220c、220d
240、242、244 ストリーム
248 ヘッドセット
250 ヘッドホン
252 ミクサ
253 ヘッドホン
254 ミクサ
257、260 選択エンジン
262 4つの並列デコーダ
264、266、270、272 ミクサ
280、282、284、286 2ストリームミクサ
288 4ストリーム並列デコーダ




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013