JP2004520903A - Integration of real-time data into gaming applications - Google Patents

Abstract

Real world data is integrated into the gaming experience affecting the player's games and actions. The game module creates game elements from real world data associated with the location. Weather conditions are simulated based on weather information (104) from different observing locations in the world, and traffic conditions (100) are similarly simulated. In a flight simulator game, the game integrates real aircraft and real weather conditions as the player's aircraft navigates the world.
[Selection] Figure 2

Description

（天候の傾向の伝達）
ゲーム天候が実際の天候に整合するように変化する１０分間の期間の後、次いでゲームマイクロプロセスは、知覚された傾向の方向で残りの時間の間に天候を変更させるように作用する。このプロセスは、現在の天候観測と以前に報告された観測と比較し、その変更の範囲内のランダム変化を計算し、次いでこの変化に整合するための残りの時間にわたって天候を変更させる。
【００２５】
例えば、時刻ｔ−１におけるある場所の報告された観測は、方向２００、速度５、突風１０であり得、時刻ｔにおける同じ場所の報告された観測は、方向１５０、速度１０、突風１５であり得る。次いで、ウインドマイクロプロセスは、方向−５０（１５０−２００）、速度＋５（１０−５）、および突風＋５（１５−１０）として２つの観察間の差を計算する。次いで風マイクロプロセスは、変化の範囲（例えば−２０、３、２）内のランダム値を選択し、この値を、以下の伝えられた天候、方向１２０、速度１３、突風１７を生じる現在の天候値に追加する。この天候マネージャ３００は、次の１時間の更新まで、好ましくは各１０分の伝えられた変更の２０％（最も近い整数に丸められる）をインプリメントする。この変更は、以下のように示され得る。
【００２６】

従って、本発明は、ゲーム経験を制御するための現実世界の条件に基づいて天候効果をアクティブに作成するための風マイクロプロセスを使用する。
【００２７】
（マクロ処理）
冒頭で説明したように、マイクロプロセスは、データがない場合、時間内にデータを満たすかまたは伝えるように作用する。マイクロプロセスは、データ更新の間の時間内に作用する。一方でマクロプロセスは、天候データに情報を追加するようにより大きなスケールにわたって作用する。天候データには情報があるが、シミュレーションに対して望ましい情報よりも詳細ではない。
【００２８】
（雷雨マクロプロセスの頻度）
一実施形態では、マクロプロセスは、領域内の雷雨頻度を評価するために使用される。特定の領域の天候観察は、雷雨が存在すること、およびその相対的な厳しさ（厳しいか否かとして報告した）を列挙するだけである。本実施形態では、本発明は、典型的にはより多くの雷雲または所与の領域内のセルが存在する単純な規則を使用することによってこのデータを増強し、このデータが秋または冬月ではなく、夏月の雷雨を有するように伝えられた。例えば、雷雨を有するように報告されてきた領域のための雲情報を生成する場合に、プログラムは、１年のほとんどの間に選択されたセクタ当たり基本レベル３の雷雲を平均化する。北半球の夏月の間（６月〜８月）に、さらなる温暖化はより頻繁にそしてさらなる雷雲を引き起こし得る。
【００２９】
雷雲をセクタに割り当てる場合、マクロプロセスは、プレイヤーが現在ゲーム１１２をプレイしている月をその内部で決定する。この情報は、プレイヤーのコンピュータを含む任意の数のソースまたは外部データベースから容易に利用可能にされる。６月〜８月の間に、プロセスは、所与の領域当たりの雷雲の量の２倍を生じ得るランダム数をベース平均値に追加する。このように、ゲーム１１２は、現在の天候データおよび１年の期間に応答して天候変化を引き起こすことにより、現実のプロセスに基づく異なる経験をプレイヤーに提供する。
【００３０】
図３を再度参照すると、航空機マネージャ３０８は、プレイヤーの航空機および内部システムに関する情報を処理し、保守する。航空機マネージャ３０８は、プレイヤーの制御プロセス３２８（航空機の移動およびシステムの制御）から制御入力を取る。次いで、航空機マネージャ３０８は、リアルタイム天候情報のための天候マネージャ３０４とインターフェースを取る。このリアルタイム天候情報（例えば、降水量、風、温度）は、航空機の動作、コックピットディスプレイ内のリアルタイムトラフィックのディスプレイを提供するトラフィックマネージャ３００、および世界に関する操作および物理的情報のための世界マネージャ３１２に影響を与える。航空機マネージャ３０８は、レンダリングエンジン３１６に航空機に関する航空機専用の情報を提供する。当業者に公知の航空機の音およびリアルタイム感覚をシミュレートする必要がある場合、航空機マネージャ３０８はまた、ディレクティブをオーディオエンジン３２０およびフォースフィードバックエンジン３２４に出力する。
【００３１】
世界マネージャ３１２は、当業者に公知である場合、世界の物理的状態に関する情報を保守する。これは、地形、土地利用（ｇｒｏｕｎｄ ｃｏｖｅｒ）、水文学、建物、道、およびナビゲーション特徴に関する情報を含む。世界マネージャ３１２は、地形の外観（温度、降水量）に影響を与え得る天候マネージャ３０４からのリアルタイム入力を取る。世界マネージャ３１２は、ナビゲーションおよび地形情報をトラフィックマネージャ３００および航空機マネージャ３０４に提供する。世界マネージャ３１２はまた、情報をレンダリングエンジン３１６に提供する。
【００３２】
レンダリングエンジン３１６は、従来技術を用いてディスプレイ３３２を介してゲームの内部状態（コックピット）および外部状態（地形、天候、他の航空機）をユーザに提示する。オーディオエンジン３２０は、現実の航空機、通信、および世界の音をユーザに提供する。航空機マネージャ３０８およびトラフィックマネージャ３００からの入力に基づいて、オーディオエンジン３２０は、オーディオシステム３３６を介してイベントベースの音および音声通信に基づくイベントをユーザに出力する。イベントベースの音（エンジン騒音、コックピットスイッチ運動、または航空機クラッシュ）は、航空機マネージャ３０８によってオーディオエンジン３２０に送信されたイベントに応答してオーディオエンジン３２０によって生成される。これらの音声は、スイッチ運動の場合に一回出力するか、または変更されるまで継続的に変更される（エンジンのうなり（ｄｒｏｎｅ）の場合）かのいずれかである。
【００３３】
オーディオシステムはまた、空のトラフィックコントローラ（ＡＴＣ）およびユーザによって聞き取られ得る他の航空機からの、トラフィックマネージャ３００によって生成された音声オーディオメッセージを生成する。ゲーム内のこの可能な通信句（ｐｈｒａｓｅ）は、（例えば、「機首方位３５０に向かって左に曲がれ」、または「ラジャー、機首方位３５０に向かって左に曲がります」）は、全ての位置（ＡＴＣ、擬似航空機、およびプレイヤー）に対して前もって進められる。コマンドによって参照され得るデータベースに配置される。音声アクターは、その位置で行われた全ての句に含まれた全てのワードおよび数（例えば、ワード（曲がる、左、右、に、へ、から、機首方位）、０、１、２、３、４、５等は、ＡＴＣコントローラを示す人によって記録ステップされる）を記録するために使用され得る。位置およびワードによって参照され得るデータベースに配置される。
【００３４】
通信コマンドは、オーディオエンジン３２０によって受け取られ、通信コマンドは、句を特定し、かつこれを満たすために必要とされた情報の全てを含む。すなわち、位置（ＡＴＣ、プレイヤー、擬似航空機）、コマンド（例えば、ＴＵＲＮ＿ＴＯ＿ＨＥＡＤＩＮＧ）、およびその句（方向：左、指定３５０）を書き込むことが必要な任意の特定のデータの全てを含む。次いで、オーディオエンジン３２０は、その位置に対する句を参照し、その位置に対して記録されたワードデータのためのボイスデータを参照し、次いでそのボイスデータを、句によって示された順序で「スティッチング（ｓｔｉｔｃｈｉｎｇ）」と呼ばれた従来のプロセスを用いてオーディオスピーカにそのボイスデータを出力する。
【００３５】
フォースフィードバックエンジン３２４は、当業者に公知のジョイスティックに含まれた皮膚ハードウエアを介してフォースフィードバック情報をユーザに提供する。このフィードバック情報は、航空機マネージャ３０８からの入力に応答して生成される。このフィードバックの例は、制御圧力、ホイールスピン、振動、着陸バンパー、または航空機のエンジン問題による振動を含む。
【００３６】
プレイヤーの制御／ゲームプロセス３２８は、ユーザからの選択および制御情報を介してゲームの軌道および実行を制御し、他のエンジンにプレイヤーによって制御されたゲームユニットに関する現在の情報を提供する。プレイヤーの制御／ゲームプロセス３２８はまた、ゲームおよび世界の状態についてのデータを保守する。
【００３７】
ジョイスティック３４０はまた、ユーザがプレイヤー制御／ゲーム状態プロセス３２８を介してゲームへの入力を提供することを可能にする。これらの入力は、制御情報（揺れ、振動、および回転）、スロットル位置、および機能選択（例えば、ギアを低下またはフラップ制御）を含み得る。ユーザはまた、フォースフィードバックエンジン３２４を介してゲームからの情報の適切なフォースフィードバック情報を受け取る。キーボード３４４は、標準的なコンピュータキーボードである。プレイヤーは、ゲームおよび航空機の構成を制御するための符号化されたキープレス（ｋｅｙｐｒｅｓｓ）およびマクロを使用する。
【００３８】
従って、本発明は、現実世界のデータをゲームに統合するためのシステムを提供して、リアルおよびランダムな態様でプレイヤーのゲームの経験に影響を与え、これにより現実世界の天候およびトラフィックデータがゲームの結果に影響を与えそして影響を及ぼす。
【００３９】
以下の説明は、本発明の実施形態によるフライトシミュレータにおける２つの重要な要素を説明する。すなわち天候エンジンおよびトラフィックマネージャである。
【００４０】
（Ｉ．天候エンジン）
図４は、天候エンジン４００と天候マネージャ３０４との間の関係を表す。天候エンジン４００は、天候マネージャ３０４から天候入力データ（観測）を受け取り、データに対する天候マネージャ３０４のリクエスト上で現在の天候状態の計算を実行する。上述のように、天候マネージャ３０４は、ゲームにおいて必要とされた航空機の周りの天候または任意の他の表示位置を説明するために使用される天候データを保守する。好適な実施形態では、天候エンジン４００は、天候シミュレーションのための改変を実行する独立モジュールである。実際の現実世界のデータは、各場所および時間に対して利用可能であるため、プレイヤーは、ゲーム１１２をプレイし得る。ゲーム１１２は、ゲームプレイを制御するための現実世界のデータに基づいてデータを改変する。
【００４１】
天候エンジン４００のための入力は、専用の場所および時間値を有する天候観察のセットである。天候エンジン４００の出力は、任意の専用の位置および時間値のための改変された天候状態である。次いで天候エンジン４００は、プレイヤーの航空機がある位置から別の位置に移動するにつれて、またはプレイヤーの航空機が時間内に移動して、現実のリアルタイム天候経験をプレイヤー１２０に提供するにつれて、ゲームにおいてスムーズにレンダリングされた天候を変更する。さらに、天候エンジン４００は、ほとんどの天候要素に対する「ポイント」天候状態およびいくつかの雲のタイプのための「環境」状態の両方を生成する。天候エンジン４００は、改変された天候を生成するために使用されるべき種々の天候要素に関する属性情報を格納する天候要素に４０４に接続される。
【００４２】
（天候要素）
以下は、天候要素データベース４０４において保守された天候要素の例示的なリストである。
・雲。雲は、雲タイプおよび雲の層によって分類される。雲は以下の属性を用いて特定される。すなわち、雲のタイプ、層ベースの高度、層の上部の高度、密度（範囲）である。
・風。風は層によって分類される。さらに風は、層間を直線的に変化する。風は以下の属性を用いて特定される。すなわち、高さ、方向および速度である。あるいは、突風およびスコールが特定され得る。
・視界。視界は水平に見られ得るマイルの数を用いて特化される。制限された視界は、煙霧および霧によって実現される。
・温度。温度は摂氏温度で特定される。
・圧力。圧力はミリバールで特定される。
・降水量。支援された降水量は雨、雪、およびであり、これらは共存し得る。降水量は、密度で特定される。
・雷雨。雷雨は、パワーで特定される。
・氷結。氷結の可能な存在は、他の天候要素に従って予測され、以下に説明される。
・乱気流。乱気流の可能な存在は、他の天候要素に従って予測される。
【００４３】
（天候要素依存性）
観測点は、天候データプロバイダ１０４によって準備された天候データベースにおいて収集され報告された天候データのセットである。天候要素のいくつかは、観測点に対して定義される一方で、他の要素は、他の天候要素に従って合成される。例えば、「氷結」および「乱気流」は、観測点に対して特化されず、従って、他の天候要素の存在および程度に従って計算される。図５は、異なる要素、その出力、および他の要素（もしあれば）を示すブロック図である。異なる天候要素は、異なる出力を必要とする。例えば、降水量は、レンダリングおよびオーディオを必要とし、雲および温度情報に基づいて合成される。氷結は、温度および視界要素に基づいて合成される。しかし、雲自体がレンダリングされ、所与の観測点のための実際のデータに基づくか、またはゲームユニットの現在の場所が観測場所間にある場合に改変される。
【００４４】
（Ａ．天候要素改変）
天候改変の主要な目的は、天候をスムーズに変更させることである。１つの場所から別の場所に移動しながら、またはこれらの観測場所の天候要素の改変に基づいて、プレイヤーのゲームユニットの現在の位置および時間に対する時間および場所付近のこれらの観測場所に対する天候要素の改変に基づいて遅れずに移動する。以下のアルゴリズムは、実際の天候データを有する観測点を用いて、時間および位置の両方によって天候改変を実現する一実施形態である。
【００４５】
（ステップ１−場所によるフィルタ天候観測）
天候改変に対する第１のステップは、改変のために使用された相対的な観測場所を選択することである。図６は、観測場所を選択するように反復的な選択ブロックのプロセスを示す。全ての観測がブロックとして格納され、ブロックは緯度および経度の値によって特定される。このタスクは、空間的かつ時間的にプレイヤーの航空機の現在の場所に近い観測場所を選択することである。第１に、天候エンジン４００は、ブロックが観測場所を含むかどうかを決定するために、航空機の場所を含むブロックを処理する。次いで、ブロックは観測点を含まない場合、天候エンジン４００は、図６に示されるように航空機の場所を含むブロック周囲のブロックを処理する。しかし、航空機の場所内の観測点がない場合、検索の範囲値は、現在の位置に対して最も近いブロックを含むように増強される。次いで天候エンジン４００は、図６に示されるように次の経路における次に最も近いブロックを処理する。任意の観測点が経路内で見出される場合、天候エンジン４００は、任意のパス上で停止する。これらの観測点は、改変のために使用される。
【００４６】
（ステップ２．時間による改変）
天候改変に対する第２のステップは、現在の時間値に従って関連する観測を選択することである。第１のステップでピックアップされた観測場所のそれぞれに対して、現在の時間値の最も近い観測場所（最も近い最小および最大時間値）が選択される。
【００４７】
以下の場合が発生し得る
・ステップ１で見出された観測領域の全ては過去に配置される。この状況では、天候エンジン４００は、改変のために最新の観測場所を選択する。
・観測の全ては将来にある。この例では、最も古い観測が選択される。
・将来の観測および過去の観測の両方が存在する。この場合、天候エンジン４００は、過去において最新の観測および未来において最も近い観測を選択し、各観測場所のための天候要素に基づいて改変された観測が生成される。一実施形態では、改変された観測場所は、現在の時間値および選択された観測時間値に従って直線的に選択される。
【００４８】
（ステップ３−場所による改変）
次に、カメラ場所に対する改変された観測は、以前のステップに選択され改変された観測場所の全てに従って作成される。図７は、本改変機構の一実施形態を示す。Ｄｉは、カメラの場所と観測＃ｉ場所との間の距離の平方であり、観測＃ｉに対する正規化されていない重みが１／Ｄｉとして計算され、正規化に対する合計の重みが正規化されていない重みの合計として計算され（｛Ｓ＝１／Ｄ１＋１／Ｄ２＋１／Ｄ３．．．｝）、そして、観測＃ｉの対する正規化された重みは、合計の重みによって除算された正規化されていない重み１／（Ｄｉ＊Ｓ）として計算される。
【００４９】
１つ以上の非常に近い観測が存在する場合に、特別な場合が存在する。この場合、時間による最も近い（Ｄｉが約０である）観測は、カメラ場所のための観測点として選択される。
【００５０】
（ステップ４−定義されていない要素の計算）
いくつかの天候要素は、選択された観測場所に対して存在し得ない。この場合、特定の天候要素規則に従って現在の天候要素の改変の後に計算されなければならない。例えば、標準圧力逓減率テーブルを介して計算される。氷結は、その場所における考慮、降水量、雲のタイプ、および温度を説明するように計算される。
【００５１】
（ステップ５−高さによる改変）
いくつかの天候要素は層（例えば風）として定義されるが、特定のカメラ高さ場所（風、次いで温度、氷結および乱気流）に対して計算される。これらの要素に対して、天候要素値は、最も近い層の値間で直線的に改変されなければならない。さらに、特定の高さにおける計算は、好ましくは風の計算は、風速および風の方向をランダムに変更し得る突風を説明する。
【００５２】
（Ｂ．雲の改変）
雲の範囲（フライトシミュレーションゲームでは重要である）はまた、好適には本発明に従って改変される。一実施形態では、雲オブジェクトは、プレイヤーの航空機が移動する場合に移動するグリッドを用いてインプリメントされる。雲パラメータは、グリッドの各頂点に対して改変される現実世界の観測データに従って計算される。図８は、約２／８の雲の範囲のための雲オブジェクトを示す。グリッドの各セルは、１つの雲オブジェクトを含む。雲オブジェクトの場所は、各セルに対してランダムであるが、より大きな雲（より大きい雲範囲）は、より低い場所の「自由度」を有する。従って、全範囲に対して、各雲オブジェクトは、グリッドの頂点に正確に配置される。雲オブジェクトのサイズは、観測データから得られた現在の雲の範囲値に従って計算される。一実施形態では、ランダム値がより現実のシミュレーションを提供するために追加される（正および負のサイズの両方）。各雲オブジェクトは、雲の形態を生成するために対応するシード値を有する。このシード値は、好ましくは、雲の形態の現実の変化をエミュレートする時間と共に滑らかに変化される。さらに、各雲オブジェクトは、時間とともに変化しない揺れランダム値を有する。この揺れ値は、雲が波打つ垂直軸（ｖｅｒｔｉｃａｌ）からの角度を特定する。
【００５３】
（雲グリッド生成）
雲グリッドは、新しい航空機および雲層の各々に対して生成される。各グリッド頂点（雲オブジェクト）に対して、以下の値がグリッド作成において生成される。
・サイズ変更係数。最小雲サイズ変更から最大サイズ変更の範囲におけるＳｉｚｅＶａｒｉａｔｉｏｎ。
・０〜１の範囲のオフセット変更係数（ｏｆｆｓｅｔＶａｒｉａｔｉｏｎ）。
・０．０〜２５５．０の範囲の初期シード値。
【００５４】
（移動している航空機のための雲グリッド処理）
雲グリッドは、雲グリッドステップ値（ｃｌｏｕｄ ｇｒｉｄ ｓｔｅｐ）に常に位置合わせされる。従って、航空機が新しい場所に移動する場合、いくつかのグリッドのロウおよび／またはカラムが検出され、新しいグリッドのロウおよび／またはカラムが追加される（その移動が十分に大きい場合）。この場合、メモリブロック（さらに存在しているが、頂点に移動する）が移動され、新しい頂点（雲オブジェクト）値が生成される。
【００５５】
（頂点値の計算）
各頂点のための値はまた、一実施形態では各天候サイクルのために再計算される。一実施形態では、以下の値が再計算される。
【００５６】
（大きさ）
雲のサイズは、その場所において、ＣｌｏｕｄＤｅｎｓｉｔｙ＊ｃｌｏｕｄ ｇｒｉｄ ｓｔｅｐ＊ＳｉｚｅＶａｒｉａｔｉｏｎとして、雲の範囲（Ｃｌｏｕｄ Ｄｅｎｓｉｔｙ，０〜１の範囲）に従って計算される。この計算されたｃｌｏｕｄ ｓｉｚｅは、０〜ｃｌｏｕｄ ｇｒｉｄ ｓｔｅｐの範囲内にあるべきである。この値は、オーバーフローの場合に調整されるべきである。
【００５７】
（雲の高さ）
雲の高さは、その場所において雲の層の現在の高さである。
【００５８】
（オフセット）
グリッドの頂点からの雲のオフセットは、（ｃｌｏｕｄ ｇｒｉｄ ｓｔｅｐ−ＣｌｏｕｄＳｉｚｅ）＊ＯｆｆｓｅｔＶａｒｉａｔｉｏｎとして計算される。
【００５９】
（シード値）
このシード値は、ＣｕｒｒｅｎｔＳｅｅｄ＋ＴｉｍｅＥｌａｐｓｅｄ＊ＣＬＯＵＤ＿ＳＥＥＤ＿ＣＨＡＮＧＥ（ＣＬＯＵＤ＿ＳＥＥＤ＿ＣＨＡＮＧＥは、精密調整のための対象物（ｓｕｂｊｅｃｔ）であり、０．２の値が始めに想定され得る）経過した時間値（ｔｉｍｅ＿ｔ、（秒））に従って計算される。
【００６０】
（ｃ．氷結モジュール）
好適な実施形態では、本発明は、飛行機上の氷結条件をシミュレートするリアルタイムデータを使用する。この氷結条件は、リアルタイムデータによって提供されない天候効果であるが、リアルタイムデータによって生成され引き起こされる。この氷結条件はまた、厳しい氷結条件は飛行機を故障させ、クラッシュさえもし得るため、プレイヤーのゲーム経験に関して直接的な効果を有する天候効果である。一実施形態では、氷結モジュールは、天候エンジン４００内に含まれたモジュールである。この氷結モジュールは、天候に関する入力情報を獲得し、この情報は、氷結の存在および厳しさを決定する。この氷結モジュールはまた、航空機上の脱氷結システムの状態を含む、航空機に関する構成情報を受け取る。氷結モジュールは、天候、航空機構成、航空機の位置、およびパイロットの航空機およびアクションの位置に基づいて航空機上の氷結の存在およびレベルを計算かつ維持する。氷結のタイプおよび厳しさにおける差および異なる航空機構成への影響を反映するために為され得る。氷結モジュールの出力は、氷結によって逆の影響が与えられる航空機のいくつかの重要な部分（ウインドシールド、横窓、翼、機体、およびエンジン吸気口）の氷結レベルの最大パーセント（０．０〜１．０）である。データは、航空機の性能および操作に現実の変化に影響を与える航空機システムモデル（動力学、エンジン）内部の他のモジュールによって使用される。このデータは、ユーザに氷結の現実の効果（機体上の氷結、窓の氷結によって低減された視界）を表示するためにレンダラー（ｒｅｎｄｅｒｅｒ）によって使用される。
【００６１】
（Ｉ．氷結のハイレベルなプロセス）
一実施形態では、最高レベルにおいて、氷結モジュールは、以下からなるループによって提示される。
【００６２】
１．世界および航空機の現在の状態を入力する
２．氷結蓄積を計算する
３．氷結離脱（ｄｅａｃｃｕｍｕｌａｔｉｏｎ）（融解）を計算する
４．航空機の更新された氷結状態を出力する
５．繰り返す
このモデルは、ユーザによって影響されるいくつかの変数を入力として獲得するために、モジュールは、好ましくは、ユーザへの氷結の変化を示す速度で実行する用にスケジューリングされる。しかし、氷は任意の高速状態で凍結または融解せず、典型的には、５秒ごとに１回の頻度でモジュールを実行させることで十分である。
【００６３】
（２．氷結の一般的な変数）
ゲーム状態制御から
・航空機位置（緯度および経度）
・航空機高度（フィート）
・Ｗｉｎｄｓｈｉｅｌｄ＿ｄｅｉｃｅ＿ｏｎ（ウインドシールド脱氷結システムが現在動作しているかどうかを示すブール（Ｂｏｏｌｅａｎ））
・Ｗｉｎｇ＿ｄｅｉｃｅ＿ｏｎ（翼脱氷結システムが現在動作しているかどうかを示すブール）
・これらの変数は、これらのシステムを含まない航空機において偽である。一実施形態では、システムは、故障するように為され得ることにより、ユーザがオン（真）に制御するように移動させても、システムはオフ（偽）であり得る。
【００６４】
天候マネージャ３０４から
・現在の位置におけるＧｒｏｕｎｄ＿ｔｅｍｐｅｒａｔｕｒｅ
・ＯＡＴ（外部空気温度）。これは、ｇｒｏｕｎｄ＿ｔｅｍｐｅｒａｔｕｒｅから１０００フィート当たり３度の標準逓減率計算を用いて計算される（７０°Ｆ ｇｒｏｕｎｄ＿ｔｅｍｐｅｒａｔｕｒｅとすると、これは、１０，０００フィートにおいて４０°ＦのＯＡＴ推定を生じる）。
【００６５】
・Ｃｌｏｕｄ＿ｃｏｖｅｒａｇｅ（この位置および高度における雲の範囲）。これは、この位置を含む天候座標（ｗｅａｔｈｅｒ ｒｅｃｔａｎｇｌｅ）内の高度において０（無雲）〜１（全天雲）の数である。
【００６６】
（３．氷結特有の変数）
以下の変数は、氷結モジュールによって維持され、他のモデルに対して利用可能にされる。この変数は、０．０（無氷結）〜１（全氷結）の値を有し得る。
【００６７】
Ｗｉｎｄｓｈｉｅｌｄ＿ｉｃｉｎｇ（航空機の前面の視界ウインドシールドの氷結レベル）
・Ｓｉｄｅ＿ｗｉｎｄｏｗｓ＿ｉｃｉｎｇ（側面ウインドウ上の氷結レベル）
・Ｗｉｎｇ＿ｉｃｉｎｇ（翼上の氷結レベル）
・Ｆｕｓｅｌａｇｅ＿ｉｃｉｎｇ（機体上の氷結レベル）
・Ｅｎｇｉｎｅ＿ｉｎｔａｋｅ＿ｉｃｉｎｇ（エンジン吸気口の氷結レベル）
これらの変数のそれぞれは、プラットフォームおよび航空機の構成に基づいてそのレベルを他のレベルに変更させ得る。
【００６８】
（４．氷結処理）
現実世界における航空機上の氷結の効果の概算は、氷結効果を計算するために本発明によって使用される。
【００６９】
（ｉ）入力状態データ）
ゲーム状態および天候データは氷結モジュールにアクセスされ、読み出される。
【００７０】
（ｉｉ）氷結蓄積の計算）
航空機が可視水蒸気（雲）範囲内にあり、外部空気温度（ＯＡＴ）（また、この水蒸気が接触部分で凍結する（１０〜３０°Ｆ））が温度範囲内にある場合に、航空機上の氷結が種々の表面上に蓄積される。より暖かい温度は氷を融解する。より冷たい温度では、水蒸気は接触部分で融解しない。
【００７１】
例えば、より高い速度の蓄積は、７０％雲量よりも高い雲の雲量（流れる雲）に割り当てられ得る。この速度はまた、航空機の構成および氷のタイプ、あるいは高度により異なることが示される。
【００７２】
ある実施形態において、以下のアルゴリズムを用いて氷結蓄積を計算する。
【００７３】
【数１】

（ｉｉｉ）氷結離脱（大気または除氷設備による融解）および大気の効果による融解の計算）
現実世界において氷結と戦う２つの方法がある。１つは、温度が氷を溶融するために十分に暖かい。領域または高度で飛行することである。これは、３２°Ｆよりも高いＯＡＴである。しかし、パイロットは氷結条件以外で飛行し得るが、ＯＡＴは、氷を誘拐するのに十分暖かくない。
【００７４】
より暖かい領域への飛行に基づく除氷を計算するための１つのアルゴリズムは、
【００７５】
【数２】

（ｉｖ）航空機設備の使用による除氷）
氷結と戦うための他の方法は、除氷設備を使用することである。氷結設備は、しばしば信頼できず、一貫しておよび効率的に適用するのに信頼性がなく、困難である。パイロットが頻繁にそして定期的に設備を適用しない場合、氷結設備は氷を融解することが不可能になるように、氷が蓄積し得る。例えば、設備が十分な除氷設備と共に使用されない場合、除氷値は、全体の量の半分に設定され得る。
【００７６】
除氷設備が効率的に動作し得るが除氷設備は航空機の全てをカバーできない。最終的に、除氷設備は、氷結条件の間により高いレベルの蓄積頻度で可能になり、除氷設備は、脱氷結条件を維持することが可能でなくてもよい。
【００７７】
除氷設備を用いて除氷を計算するための１つのアルゴリズムは、
【００７８】
【数３】

第１のアルゴリズムは、十分暖かい温度および航空機が雲内に存在しないことに起因して航空機による氷融解（除氷）をエミュレートする。第２のアルゴリズムは、ウインドシールド上で除氷するか、または翼上で除氷するかのいずれかに起因して氷を取り除くことをエミュレートする。
【００７９】
従って、各ループ（ゲームにおけるサイクル）に対して、除氷設備は、翼およびウインドシールドから氷を除去するように試みる。しかし、上述のように、パイロットが氷の条件から遠ざかって飛行しない場合、本発明の除氷条件は、氷結が設備および／または航空機を圧迫し得る可能性をリアルに提供する。
【００８０】
（ｖ）氷結変数の出力状態
氷結変数の入力状態は、蓄積および離脱モデルによって変更される。この結果生じた値は、他のモジュールおよび外部モジュールに対して利用可能にされる。これらの変数がどのようにして使用されるかについてのいくつかの例が以下に示される。
【００８１】
（ａ）航空機システムモデル
航空機システムモデルは、航空機の飛行をシミュレートする従来のモデルである。
【００８２】
（１．リフトの計算）
翼上の氷蓄積は、最大半分だけ翼によって生成されたリフトを低減する。従って、氷結モデルは、航空機システムモデルを以下のように調整する。Ｌｉｆｔ＝Ｌｉｆｔ＊（Ｗｉｎｇ＿ｉｃｉｎｇ＊０．５）である。
【００８３】
（２．抗力の計算）
翼および機体上の氷蓄積は、航空機の性能に対して最大２５％またはそれ以上の抵抗を追加する。従って、本例では、航空機システムモデルは、以下のように調整される。
【００８４】
Ｄｒａｇ＝Ｄｒａｇ＊（１＋（０．１２５＊（ｗｉｎｇ＿ｉｃｉｎｇ＋ｆｕｓｅｌａｇｅ＿ｉｃｉｎｇ）））
（３．重量計算）
翼および機体上の氷蓄積は、著しい重量を航空機に追加し得る（この例に対して、最大２５％またはそれ以上）。この調整は、以下のようであり得る。
【００８５】
Ａｉｒｃｒａｆｔ＿ｗｅｉｇｈｔ＝Ａｉｒｃｒａｆｔ＿ｗｅｉｇｈｔ＊（１＋（０．１２５＊（ｗｉｎｇ＿ｉｃｉｎｇ＋ｆｕｓｅｌａｇｅ＿ｉｃｉｎｇ）））
（４．エンジン性能の計算）
エンジン吸気氷結は、利用可能である空気量を制限することによってエンジン性能に影響を与え得る。この調整は以下のようであり得る。
【００８６】
Ｔｈｒｕｓｔ＝Ｔｈｒｕｓｔ−（Ｔｈｒｕｓｔ＊Ｅｎｇｉｎｅ＿ｉｎｔａｋｅ＿ｉｃｉｎｇ）
（５．機体氷結による航空機設備への影響の計算）
氷結はまた、航空機のギア、フラップ、および機器（氷結が上にある）の動作に影響を与え得る。
【００８７】
【数４】

（ｂ）氷結レンダーモデル）
これらは、氷結モデルの結果によって影響されるレンダー決定の例である。このレンダーは、外部の世界および航空機のビューをユーザに表示する。これは、一般的にウインドシールド、側面の窓、および航空機を含み得る。
【００８８】
（１．ウインドシールドからのビュー）
ウインドシールドからのビューは、一般的に透明である。氷結条件では、視界の量は、ｗｉｎｄｓｈｉｅｌｄ＿ｉｃｉｎｇの量だけ低減される。ここで、氷結されたウインドシールドディスプレイのアレイは、ｗｉｎｄｓｈｉｅｌｄ＿ｉｃｉｎｇ値に基づいて予めレンダリングされ、表示される。例えば、
ｗｉｎｄｓｈｉｅｌｄ＿ｐａｎｅｌ＝ｗｉｎｄｓｈｉｅｌｄ＿ｉｃｉｎｇ＿ｐａｎｅｌｓ［ｗｉｎｄｓｈｉｅｌｄ＿ｉｃｉｎｇ］
（２．側面窓からのビュー）
側面窓からのビューは、その変数によって示されたｗｉｎｄｏｗ＿ｉｃｉｎｇのパーセントによって不明瞭にされる。ここで、氷結されたウインドウディスプレイのアレイは、予めレンダリングされ、ｗｉｎｄｏｗ＿ｉｃｉｎｇ値に基づいて表示される。
【００８９】
ｗｉｎｄｏｗ＿ｐａｎｅｌ＝ｗｉｎｄｏｗ＿ｉｃｉｎｇ＿ｐａｎｅｌ［ｗｉｎｄｏｗ＿ｉｃｉｎｇ］
（ｃ）航空機レンダリング）
ユーザによって示された航空機自体は、ｗｉｎｄｓｈｉｅｌｄ＿ｉｃｉｎｇ、ｗｉｎｄｏｗ＿ｉｃｉｎｇ、ｗｉｎｇ＿ｉｃｉｎｇ、およびｆｕｓｅｌａｇｅ＿ｉｃｉｎｇ荷関連付けられた値に依存して変更される。種々の現実の蓄積レベルにおける氷結影響の予めレンダリングされた表現は、これらの変数の値に応じて航空機モデルに追加される。窓の外を見る場合、および外部のビューが選択された場合、ユーザはこの蓄積を見る。これは、上記で示されたような複数のアレイおよび計算を含む。
【００９０】
従って、氷結モジュールは、プレイヤーの航空機および本発明に従う航空機のレンダリングと双方向通信する氷結影響を生成するための基礎として現実世界のデータを使用して、現在および実際の天候条件に基づく興奮するゲーム経験を提供する。
【００９１】
（ＩＩ．トラフィックマネージャ）
図９を参照すると、トラフィックマネージャ３００は、その機能性をインプリメントするいくつかの独立的なプロセスから構成される。トラフィックエンジン９００は、プレイヤーのゲーム１１２における航空機の全てを作成、管理、かつ更新する。トラフィックエンジン９００は、まずプレイヤー制御／ゲーム状態エンジン３２８からプレイヤーの航空機データ（位置、高度、機首方位、速度、および構成）をリクエストする。トラフィックエンジン９００は、このデータを使用して、上述のようにプレイヤーの航空機の周囲の航空機トラフィックのためのゲームデータサーバ１０８へのリクエストをフォーミュレートする。このトラフィックエンジン９００は、ゲーム１１２内に航空機を作成するために戻ってきたデータを使用する。トラフィックエンジン９００は、トラフィックデータベース９０４の使用を介してこのデータを管理し、トラフィックデータベース９０４は、プレイヤーの航空機を含むプレイヤーの航空機付近の全てのアクティブな航空機のリストを含む。各データベースエントリに対して格納された情報は、一般的に、航空機識別番号（例えば、ＴＷＡ７１４）およびこのプロセスにおいて以後のトラフィックエンジン９００によって作成された擬似およびプレイヤーの航空機オブジェクトへの固有のポインタを含む。このトラフィックデータベース９０４はまた、ゲーム１１２内の他のプロセスによって使用され、このトラフィックオブジェクトを識別し、これにアクセスする。
【００９２】
航空機エントリをトラフィックデータベース９０４に加えることによって、トラフィックエンジン９００はまた、プレイヤーの領域外部にあるデータベース９０４からのエントリを除去することによってデータベース９０４を管理する。一実施形態では、トラフィックエンジン９００はまた、３更新サイクルに対するレポートを受信しなかった任意の航空機のためのトラフィックデータベース９０４からのエントリを除去する。上述のように、データベース９０４への更新は、プレイヤーの航空機の所定の地理的領域内の航空機のために受信される。従って、レポートの欠如は、着陸した航空機を示すか、またはその位置は、航空機が、現在ではプレイヤーのゲーム１１６にもはや関連しないプレイヤーの航空機からはるかに十分離れていることを示す。
【００９３】
まずトラフィックエンジン９００は、単一のＡＴＣプロセス９０８を生成する。このＡＴＣプロセス９０８は、擬似航空機プロセッサ９１６およびプレイヤー航空機プロセス９３２と制御および通信し、その結果ＡＴＣプロセス９０８は、現実のＡＴＣコントローラとしてプレイヤーに現れる。ＡＴＣプロセス９０８は、トラフィックデータベース９０４へのリンクを含むことにより、ＡＴＣプロセス９０８は、関連する航空機のすべてのデータ（例えば、現在の速度、機首方位、および高度）へのアクセスを有する。
【００９４】
次いで、トラフィックエンジン９００は、新しい非プレイヤーの航空機に関する情報がトラフィックデータベース９０４に入力される場合、各非プレイヤーの航空機のための固有の擬似航空機プロセス９１６を作成する。このトラフィックエンジン９００は、そのデータが利用可能になる場合、擬似航空機プロセス９１６に、現実の航空機に関するデータレポート更新を送信する。このデータは、その航空機の位置および構成を現実の航空機のデータに一致させるように、擬似航空機プロセス９１６によって使用される。各擬似航空機プロセス９１６は、世界の現実の航空機としてプレイヤー１２０に対して現れ、挙動する。この擬似航空機データは、世界における位置（ｘ、ｙ位置、機首方位、速度、および高度）、航空機識別、および状態（ギア位置、フラップ位置等）等のデータを含む。このデータは、内部的に保守され、ＡＴＣプロセス９０８およびレンダリングエンジン３１６等の他のゲームプロセスからのデータリクエストに応答して発行され得る。ＡＴＣプロセス９０８を用いる通信／制御リンクはまた、作成の間に確立される。このリンクは、擬似航空機プロセス９１６が通信コマンドを作成し、ＡＴＣプロセス９０８に応答することを可能にする。擬似航空機プロセス９１６によって生成されたオーディオ通信は、オーディオエンジン３２０に通信コマンドを送信することによって達成される。
【００９５】
トラフィックエンジン９００はまた、プレイヤー制御／ゲーム状態エンジン３２８に外部的にリンクされ、ＡＴＣプロセス９０８に内部的にリンクされるプレイヤー航空機プロセス９１２を作成する。これは、ＡＴＣプロセス９０８がプレイヤーをモニタリングし、プレイヤーと双方向通信することを可能にする。プレイヤーの航空機および意図に関する情報は、プレイヤー制御／ゲーム状態エンジン３２８からプレイヤー航空機プロセス９１２へのデータをモニタリングするプロセスを介して、ＡＴＣプロセス９０８にアクセス可能である。ＡＴＣプロセス９０８はまた、好ましくは、オーディオエンジン３２０（プレイヤーがほぼ聞く）に送信された音声通信コマンドを介してプレイヤーと双方向通信する。
このプレイヤーは、プレイヤー制御／ゲーム状態エンジン３２８によって提供された、インターフェース（制御、メニュー、およびキーボードコマンド）を介してコントローラを用いて応答かつ双方向通信する。
【００９６】
（Ａ．擬似航空機プロセスアルゴリズム）
各擬似航空機プロセス９１６は、好ましくシミュレーション実行、共通のデータベース、および通信、ナビゲーション、制御を処理する個々のモジュール、規則に基づく意思決定を含む。このシミュレーション実行は、個々のモジュールの実行の順序をスケジューリングする。一実施形態では、初期化の後、プロセス実行の順序は、
１．通信モジュール（新しいデータおよびコマンドの入力）
２．規則ベースの論理モジュール（更新データへの反応）
３．ナビゲーションおよび制御モジュール（現在の航空機の目的地に従うように航空機を移動させる）
４．通信モジュール（出力データおよびコマンド）
５．繰り返し
（１．共通のデータベース）
共通のデータベースは、トラフィックエンジン９００から受信されたレポート、論理およびナビゲーションモジュールによって制御された場合の航空機の現在の状態、ならびに擬似航空機自体の内部目標および状態に関するデータ（例えば、ナビゲーションおよび制御モジュールの現在の目的地）を格納するために使用される。この共通のデータベースはまた、プロセスモジュールのための共通の通信アーキテクチャを提供するために使用される。データベースへの変更は、モジュールによって入力され動作される。
【００９７】
（２．通信モジュール）
通信モジュールは、擬似航空機プロセス９１６と他の外部プロセスとの間の全体の通信を管理する。通信モジュールは、新しいデータおよびメッセージを格納するか、またはデータを外部プロセスを送信するための領域として共通データベースを使用する。通信モジュールによるデータ入力は、トラフィックエンジン９００からの更新レポート、ＡＴＣプロセス９０８からのコマンド、他のプロセスによるデータリクエストを含む。通信モジュールは、他のモジュールによって命令されたメッセージに基づく外部プロセッサにデータを出力する。通信モジュールによるデータ出力は、ＡＴＣプロセス９０８およびオーディオエンジン３２８へのメッセージ、他のモジュールへのデータリクエスト、ならびにレンダリングエンジン３１６および他のプロセッサへの位置更新を含む。
【００９８】
（３．規則ベースの論理モジュール）
規則ベースの論理モジュールは、擬似航空機の状態の変化およびその周りの世界の変化に応答して擬似航空機の動作を制御する。擬似航空機によって受信されたリアルタイムデータが、日、位置、および天候によって変動する場合、リアルタイムデータは、ゲーム内部のプレイヤーの経験に関するリアルタイムデータの影響を提供する、これらの規則と相互作用する。これらの予めプログラムされ、そしてフレキシブルな動作規則の例は、航空機の位置の変更、ＡＴＣ通信および制御、ならびにプレイヤー航空機の位置（プレイヤーによって制御された場合）に応答する規則を含む。例えば、航空機の位置に応答する１つの規則は、擬似航空機が空港の５０マイル内にあり、着陸しようとしているトラフィック制御プロセス９０８に通知する必要性を含む。これはまた、プレイヤーによって聞かれるオーディオメッセージを生じる。
【００９９】
これを説明する規則の例は、
【０１００】
【数５】

擬似航空機はまた、トラフィックコントローラによるコマンドに反応する。航空機は、空港に十分近くなる場合、ＡＴＣコントローラは、（擬似）航空機が現実の航空機の経路に従うことをやめ、着陸する命令に従うように伝える。この擬似航空機は、ＡＴＣコマンドに従うようにそのナビゲーションモジュールを変更させることによって反応し、そのコマンドに続いて、そのモジュールがコマンドを受信し、オーディオを介して同じコマンドを通知したＡＴＣプロセス９０８に応答する。
【０１０１】
この挙動を達成するための１つのアルゴリズムは、
【０１０２】
【数６】

である。
【０１０３】
擬似航空機９１６はまた、プレイヤーの航空機の動きに反応し得る。この擬似航空機９１６は、擬似航空機に近づくようになる任意の航空機（例えば、プレイヤーの航空機は擬似航空機にぶつけようと試みる）をモニタリングし、その航空機から離れるように移動しようとする規則に基づいた論理を含み得る。これが発生する場合、擬似航空機の規則に基づく論理は、通常のナビゲーションを中断し、プレイヤーの航空機から離れるように飛行し、ＡＴＣに抗議のメッセージを送信するように航空機に命令し得る。この挙動を達成するためのアルゴリズムの１つの例は、
【０１０４】
【数７】

である。
【０１０５】
いったんプレイヤーが擬似航空機から離れて移動した場合、以下の規則は、擬似航空機が通常に動作するように戻る。
【０１０６】
【数８】

（Ｂ．ナビゲーションおよび制御）
ナビゲーションおよび制御モジュールは、従来の自動操縦の機能性を含む。従来の技術を用いる共通のデータベースに格納されたレポート更新に従うことによって擬似航空機をナビゲートおよび制御することを可能にする。しかし、本発明によると、ナビゲーションおよび制御モジュールはまた、その内部規則に基づく論理モジュールまたは外部ＡＴＣプロセス９０８のいずれかによってこれらのモジュールに発行されたナビゲーションコマンドに従うことを可能にする。
【０１０７】
ナビゲーションおよび制御モジュールは、擬似航空機の航空機位置、高度、速度、および機首方位を現実の航空機のそれらに一致させるようにレポート更新を使用する。レポートデータ（位置、機首方位速度および高度）は、一実施形態では、上述したように、約３分ごとにトラフィックエンジン９００によって更新される場合、一実施形態では、ナビゲーションおよび制御モジュールは、これらの更新間の航空機の動きを概算するそれ自体のデータを補間そして生成し、これは以下により詳細に説明される。擬似航空機の現在の位置、機首方位、高度、および擬似航空機の速度は、レンダリングエンジンに送信され、ゲーム内部の他のプロセスに対して利用可能にされる。
【０１０８】
実際の航空機の動きに整合させることに加えて、ナビゲーションおよび制御モジュールはまた、特定のナビゲーションコマンドに応答することを可能にする。これらのコマンドは、内部規則ベースの論理モジュールまたはＡＴＣプロセス９０８によってこのモジュールに発行され得る。これらのコマンドの例は、
・特定の機首方位に向ける（左または右）
・高度（下降、上昇、または維持）
・ある値の速度の（増加または減少）
・点（ｘ、ｙ位置および高度）への直接飛行
・点（特定のｘ、ｙ位置および高度の旋回）における保持
・空港へのアプローチおよび着陸の実行
・（あるｘ、ｙ位置）から離れる運動
・レポート更新に従う通常のナビゲーション（停止、再開）
・アプローチのためのクリア
・着陸のためのクリア
これらのコマンドは、プロセス間に容易に伝達される簡単なフォーマットで存在する（例えば、「機首方位３５０に左に曲がる」コマンドは、ｔｕｒｎ＿ｌｅｆｔ＿ｔｏ＿ｈｅａｄｉｎｇ３５０として表現され得る）。
【０１０９】
（Ｃ．航空機観測間のナビゲートおよび平均化）
擬似航空機が信頼可能な態様で動作するために、擬似航空機は、位置レポート間で滑らかに移行しなければならない。これらの報告は、レポートされた機首方位、速度、高度、およびＸ、Ｙ（緯度、経度）位置を含む。この擬似航空機は、それが表す現実の航空機のための最新のレポートの位置（Ｘ、Ｙ緯度および経度）において最初に作成される。擬似航空機はまた、現実の航空機の高度において、およびその航空機の機首方位および大気速度を用いて作成される。次いで擬似航空機は、機首方位、速度、および高度を用いてその位置から前方に「動かされる」。擬似航空機の位置の変化は、航空機エージェントによって内部で計算され、レンダリングエンジン３２８に出力される。これは、現実の航空機からの次のレポート（経度、緯度、高度、機首方位、および速度）が受け取られるまで継続する。次いで、擬似航空機プロセス９１６は、ゲーム１１６内の擬似航空機の位置と現実の航空機の位置との間の差を比較する。まず、プロセス９１６は、その位置により直接向かうように擬似航空機を移動させる機首方位、速度、および高度の変化を含むベクトルを計算する（それにより、航空機は、航空機の実際の位置まで捉えることができる）。次いで、プロセス９１６は、そのベクトルを現実の航空機からの報告の機首方位、高度、および速度ベクトルにそのベクトル（ベクトル加算を用いて）を加える（現実の航空機のベクトルは、その航空機が向かおうとしている場所を反映する）。次いで擬似航空機プロセス９１６は、そのベクトルに整合させるためにコース、機首方位、および速度を変更するように擬似航空機に命令する。従って、生じたベクトルは、現実の航空機位置をより良好に反映するために必要とされた変化および実際のコースに沿う動きの両方を反映する。
【０１１０】
最後に、本発明に従って、自動操縦は、機首方位および高度の移動を行うようにプログラムされる。ベクトルの変化に対する速やかな動きを命令するよりも、自動操縦は、約３０秒にわたる変化を管理する。擬似航空機がそのベクトルで安定化した後に、擬似航空機は、プロセスが繰り返される次の更新までそのベクトルに沿って移動し続ける。
【０１１１】
（Ｄ．プレイヤーの航空機の回避）
リアルタイムデータとゲームとの統合における別の発行は、プレイヤーの航空機と擬似航空機との間の相互作用を制御することである。一実施形態では、規則は擬似航空機をプレイヤー制御回路を設置させるように使用される。第１に、擬似航空機は、プレイヤーの航空機が擬似航空機の範囲内に存在し、その範囲に向かって速やかに移動する場合に飛び去る。第２に、擬似航空機は、プレイヤーがより低い速度で接近する場合、プレイヤーの航空機から離れて移動するのをやめる。第３に、擬似航空機は、プレイヤーの航空機が、プレイヤーが十分低い速度において最初に接近するのと同じ距離で擬似航空機（最大範囲内）に近づいて飛行することを可能にする。第４に、擬似周回は、プレイヤーの航空機が唯一の（ｓｏｌｅ）最大範囲内で移動する場合、プレイヤーの航空機から離れて飛行することを試みる。これらの規則は、プレイヤーの航空機が衝突を引き起こすことなく、リアルタイム擬似トラフィックと相互作用することを可能にする。次いでこのプレイヤーは、擬似航空機にゆっくりと接近するように移動することによって、編隊で飛行する技術を発展させ得る。プレイヤーはまた、擬似航空機に意図的な飛行を試みるか、あるいはそのコースから飛び出すかまたは地面の物体または山に飛んでいくように擬似航空機を強制する。一実施形態では、擬似航空機、あるいは擬似およびプレイヤーの航空機が別の物体に衝突する場合、その衝突した物体が爆発し、ゲームセッションは終了する。
【０１１２】
以下は、上記の規則を達成するためのアルゴリズムの一実施形態である。
【０１１３】
（ｐｓ〜ｐ２の距離の計算、ｐｓ〜ｐ２の接近速度、およびｐｓ〜ｐ２の回避ベクトル）
擬似航空機からプレイヤーの航空機までの距離は、Ｘ、Ｙおよび高度差の平方和の３乗根として計算される。それぞれに対して、ＸおよびＹは、緯度から変換され、経度、緯度から０緯度点および０経度点からのフィートに変換される。高度（Ａ）はフィートである。距離_ｐｓ〜ｐ＝（（Ｘ_ｐｓ−Ｘ_ｐ）^２＋（Ｙ_ｐｓ−Ｙ_ｐ）^２＋（Ｚ_ｐｓ−Ｚ_ｐ）^２）^１／３であり、Ｐは、プレイヤーの航空機からの値を表し、ＰＳは擬似航空機を表す。
【０１１４】
接近_ｐｓ〜ｐの速度は、１つの計算サイクルから別の計算サイクルの距離_ｐｓ〜ｐの値を比較することによって計算される。距離_ｐｓ〜ｐが各秒で計算される場合、その期間のための１秒当たりの接近速度は、距離_{ｐｓ〜ｐ（ｔ−１）}の以前の値−距離_{ｐｓ〜ｐ（ｔ）}の現在の値である。例えば、以前の値のｆが１４００フィートであり、現在の値が１２００であり、接近速度は２００ｆｔ／フィートである。
【０１１５】
（回避ベクトル）
擬似航空機は、各ゲームサイクル（１秒当たり約１回）においてその中心点に対する距離_ｐｓ〜ｐおよびプレイヤーの航空機の接近_ｐｓ〜ｐの速度をモニタリングする。
【０１１６】
距離_ｐｓ〜ｐ＜１５００ｆｔが接近_ｐｓ〜ｐ＞＝２５ｆｔ／分を論理積演算する場合、擬似航空機は、
ａ．自動操縦を切る（例えば位置レポートに従うことをやめる）
ｂ．分ごとに、「私にあまりにも接近している航空機がある」という効果に対してランダムからされオーディオメッセージを送信する。
【０１１７】
ｃ．接近速度の２倍の速度（１５００ｆｔ／分）で、または航空機性能が許容する最大値で回避ベクトル_ｐｓ〜ｐの方向においてプレイヤーから離れて移動する。
【０１１８】
このアルゴリズムは、プレイヤーが高速で擬似航空機に向かって航空機を移動させ始める状況にアドレスする。接近_ｐｓ〜ｐ＜２５ｆｔ／分の速度は、距離_ｐｓ〜ｐ＞５０Ｆｔを論理積演算し、擬似航空機自動操縦を論理積演算する場合、擬似航空機プロセス９１６は、
ａ．自動操縦を切る
ｂ．通常のナビゲーションを再開する
ｃ．その元のコースに戻るように、擬似航空機を移動する
ｄ．一実施形態では、「誰かが私たちと共に編隊で飛行する」効果に対するオーディオメッセージを出力する。
【０１１９】
このアルゴリズムは、プレイヤーが速やかに航空機に向かって移動する場合の状況にアドレスするが、合理的な接近速度に速度を下げる。
【０１２０】
距離_ｐｓ〜ｐが＜５０ｆｔである場合、擬似航空機プロセス９１６は、
ａ．自動操縦を切る（例えば位置レポートに従うことをやめる）
ｂ．１５秒ごとに「あなたはあまりにも接近している」という効果に対するメッセージを送信する。
【０１２１】
ｃ．接近速度の２倍の速度（１５００ｆｔ／分）で、または航空機性能が許容する最大値で回避ベクトル_ｐｓ〜ｐの方向においてプレイヤーの航空機から離れて移動する。
【０１２２】
このアルゴリズムは、プレイヤーが擬似航空機に向かって編隊で飛行し、次いで意図的にまたは誤操作によって擬似航空機に向かって移動を始める状況にアドレスする。
【０１２３】
擬似航空機が地面またはプレイヤーの航空機以外の任意の物体と衝突する場合、
ａ．擬似航空機は、ランダムオーディオメッセージを出力する
ｂ．擬似航空機が爆発する
ｃ．ゲームセッションが終了する。
【０１２４】
距離_ｐｓ〜ｐが＜１０フィートである（航空機が恐らく衝突することを示す）場合、
ａ．擬似航空機は、「これはダム（ｄｕｍｂ）である」効果に対するランダムオーディオメッセージを出力する
ｂ．擬似航空機が爆発する
ｃ．プレイヤーの航空機も爆発する
ｄ．ゲームセッションが終了する。
【０１２５】
（Ｄ．ＡＴＣプロセスアルゴリズム）
ＡＴＣプロセス９０８は、擬似航空機プロセス９１６と類似しているアーキテクチャを有する。ＡＴＣプロセスは、実行シミュレーション、共通のデータベース、および通信、および規則ベースの決定作成を処理するここのモジュールを含む。
【０１２６】
実行シミュレーションは、ここのモジュールの命令をスケジューリングする。初期化の後、プロセス実行の命令は、
１．通信モジュール（新しいデータおよびコマンドの入力）
２．規則ベースの論理モジュール（更新された内部および外部データへの反応）
３．通信モジュール（データおよびコマンドを出力する）
４．繰り返す
（１．ＡＴＣ共通データベース）
ＡＴＣ共通データベースは、制御下の航空機に関するデータおよび内部目標に関するデータ、ならびにＡＴＣプロセス９０８の状態を格納するために使用される。この共通のデータベースはまた、他のプロセスモジュールのための共通の通信アーキテクチャを提供するために使用される。データベースへの変更が入力され、モジュールによって動作される。
【０１２７】
（２．ＡＴＣ通信モジュール）
通信モジュールの基本動作は、擬似航空機モジュールで使用される動作と同様である。ＡＴＣ通信モジュールは、ＡＴＣプロセス９０８と他の外部プロセスとの間の全ての通信を管理する。ＡＴＣ通損モジュールは、新しいデータおよびメッセージを格納する領域として共通のデータベースを使用するか、またはデータを外部プロセスに送信する。ＡＴＣ通信モジュールによるデータ入力は、擬似航空機およびプレイヤープロセス９１２、９１６からの位置レポート、擬似航空機およびプレイヤーの航空機プロセス９１２、９１６からのリクエストおよび応答を含む。ＡＴＣ通信モジュールは、データを他のモジュールによって命令されたメッセージに基づいて外部プロセスを出力する。ＡＴＣ通信モジュールによるデータ入力は、擬似航空機プロセス９１６、プレイヤー航空機プロセス１１２、およびオーディオエンジン３２８へのメッセージ、ならびにプレイヤーおよび擬似航空機プロセス９１２、９１６へのデータリクエストを含む。
【０１２８】
（３．ＡＴＣ規則に基づいた論理モジュール）
ＡＴＣ規則に基づいた論理モジュールは、世界内の航空機の状態の変更に応答してＡＴＣプロセス９０８の動作を制御する。ＡＴＣプロセス９０８は、ゲームがプレイされる日、位置、および天候による航空機のフローの変化に応答することにより、リアルタイムトラフィックおよび天候条件に対して現実のリアルタイム応答を提供する。このモジュール内のルールセットは、プレイヤーが到達するように選択し得る空域内で主要な空港のアクティブコントロールをシミュレートするように作用する。ＡＴＣプロセス９０８は、空港への着陸または空港からの離陸のいずれかである航空機と相互作用する。
【０１２９】
（Ｅ．帰航航空機の制御）
その空港に着陸することになっている航空機（擬似またはプレイヤー）は、ＡＴＣプロセス９０８と接触し、その空港の５０マイル内でこの意図を説明しなければならない。この擬似航空機は、これを自動的に行うが、プレイヤーは、この通信を手動で行わなければならない。航空機がこの通信を行う場合、着陸キューに追加される。ＡＴＣプロセス９０８は、航空機との通信を管理し、さらに、着陸のためにプレイヤーの航空機を順番付ける必要がある場合、リアルタイムトラフィックを調整するようにこのキューを使用する。この着陸キューは、着陸のためのＡＴＣプロセスに接触した航空機のＦＩＦＯ（先入れ先出し）キューからなる。各航空機に対してこのキューに含まれたデータは、順序命令、その航空機のための識別ＩＤ、データが制御下で持っていかれ、最初のアプローチポイント（そのポイントは現在データがクリアされている）に送信した場合、データが最初に割り当てられた高度を含む。
【０１３０】
このキューは、航空機が接近し、空港に着陸している制御をシミュレートする規則に基づいた論理によって使用される。これは、制御およびオーディオコマンドが航空機に発行されるアプローチにおけるいくつかの点を通過することを含む。この点（空港の滑走路からの場所）およびコマンドは、以下のように発行される。
【０１３１】
【表１】

航空機が制御下にある場合、航空機はＡＴＣ規則のコマンドに従い、航空機が存在する場所およびこの航空機を次のポイント上に進める場合に検知する。キュー内でこのデータを使用する規則の例は、以下に示される。
【０１３２】
【数９】

航空機が着陸する場合、航空機は、帰航航空機キューから除去される。その航空機からのデータが消失され得るとすぐに、この航空機は、トラフィックエンジン９００によって除去される。
【０１３３】
（１．最初のアプローチポイント（ＩＡＰ）ポイントにおける航空機の保持）
航空行きのトラフィックが混雑している場合、適用され得るアプローチおよび着陸を望むより多くの航空機が存在する。１つのみの航空機が最終アプローチ固定（ＦＡＦ）に一度にクリアされ、これは、航空機を滑らかに順序付ける。このＡＴＣプロセス９０８は、最終アプローチ固定にクリアされる前に、ＩＡＰにおいて保持するように航空機に要求することによってこれに適用する。
【０１３４】
航空機がＩＡＰに最初にクリアされる場合、維持するために高度が与えられる。
この高度は、基本コードからのオフセットを決定するためのキューにおける順序命令を用いて生成される。この高度分離は、航空機が衝突することを妨げる。例えば
航空機アプローチがキュー内の４番目の航空機である場合、ＩＡＰの基本高度は１０，０００フィートであり、その航空機は、ＩＡＰまでの１００００＋（４＊１０００）＝１４，０００フィートにクリアされる。順序番号が１０を超える場合、キュー内の航空機の全体の数は１０未満であり（いくつかの航空機がクリアされたことを示す）、航空機シーケンス数が１にリセットされる。これは、１１，０００ｆｔ（１０，０００＋１＊１０００ｆｔ）にクリアされるべき次の航空機を生じる。ＦＡＦとして保持する航空機出口はクリアになり、ＩＡＰにおいて保持されている次の航空機はＦＡＦにクリアされる。
【０１３５】
（２．帰航航空機）
空港を出発する（離陸する）航空機は、航空機が離陸する態勢が整っていることを示すＡＴＣプロセス９０８に通信メッセージを送信する場合、離陸キューに追加される。このメッセージは、擬似航空機がその空港にあるべきである空港エンジン９００によって生成され、その飛行プランは、擬似航空機がまだ離陸して以内ことを示す場合、擬似航空機によって自動的に発行される。このメッセージはまた、擬似航空機が空港に存在し、離陸を望んでいる場合にプレイヤーの航空機によって生成される。この離陸キューは、順序番号、航空機に対するＩＤ番号、航空機が離陸するためにクリアされるポイントをデータとして維持する。離陸論理が関係される３ポイントが存在する。
【０１３６】
【表２】

航空機が離陸するように要求する場合、航空機は離陸キューに追加される。ＡＴＣプロセス９０８が、航空機が離陸する（任意の以前の航空機が到着または滑走路順序ポイントを超えて到達または移動した）ことを可能にすることが安全である場合、航空機は離陸するためにクリアされる。他の場合では、航空機は保持するように尋ねられ、そのポイントがクリアになる場合、離陸することが可能になる。一旦航空機が順序ポイントに到達する場合、ＡＴＣプロセス９０８は、通常のナビゲーションを再開するが、キューから航空機を除去しない。次いでこの航空機は、そのレポートデータに従い、実際のルートに整合するように開始され得る。航空機が５０マイルポイントを超えて移動する場合、データがキューから除去され、可聴センドオフメッセージである。
【０１３７】
（３．地面上の航空機の保持）
着陸キューに関して、適応され得る離陸を望むより多くの航空機がある状況があり得る。これは、しばしば、プレイヤーの航空機が空港が混雑している場合に離陸することを尋ねる時に発生し得る。この場合、航空機が離陸メッセージに対する準備を送信する場合、航空機が保持するように命令される。キューにおいて前もって航空機が出発する場合、この航空機は、最終的には離陸するようにクリアされる。不幸にも実際の寿命（ｒｅａｌ ｌｉｆｅ）を反映する離陸キューを保持し得る航空機の数に制限されない。
【０１３８】
（４．制御不能な（ｒｏｇｕｅ）航空機の処理）
着陸および離陸キューはまた、ＡＴＣプロセス９０８が航空機の制御（特にプレイヤーの航空機）下では存在しない航空機のための空域をモニタリングすることを可能にする２次的な目的に役立つ。プレイヤーの航空機が空港の５０マイル内にあり、ＡＴＣプロセス９０８に接触せず、着陸キュー上に配置されたＡＴＣプロセッサ９０８が決定する場合、ＡＴＣプロセス９０８は、それ自体を識別するためにその決定を尋ね、そして航空機が着陸するまでその意図または同様なメッセージが何であるかを尋ねることにより、未知の航空機にオーディオメッセージを送信するように応答する。同じプロセスは、そのプロセスが滑走路に進み、間隔を尋ねることなく離陸する場合に、プレイヤーに対して使用される。ＡＴＣプロセス９０８は、航空機が離陸（離陸キューに関してではない）に対する間隔をリクエストすることなく滑走路上に存在することを検知し、航空機が５０マイルを超えてしまうまでオーディオメッセージの適切なストリングことを検知する。
【０１３９】
（５．リアルタイム天候データの使用）
ＡＴＣプロセス９０８はまた、天候データ（例えば、風の方向はどこか）に対してのパイロットリクエストに応答するように制御している空港に関して上述したようなリアルタイム天候データを使用し得る。このデータはまた、ＡＴＣプロセス９０８が、航空機に着陸するように命令する最適な滑走路を選択することを可能にし、リアルタイム条件に基づいてＣＮ部分自体の現実のレンダリングを生成する。
【０１４０】
従って、システム、方法、および装置は、リアルタイムデータの使用がゲーム経験に影響を与え、これを駆動することを可能にするために説明される。好適な実施形態がいくつかの細部（すなわちフライトシミュレーションアプリケーション）において説明されてきたが、本発明の教示は、同様に他のゲーム（カーレーシングゲームおよび船レーシングゲーム、あるいは他のスポーツイベント等）に拡張され得る。多くのさらなる改変が本発明の真の趣旨から逸脱することなく上述の装置に為され得る。さらに、特定の機能性が上述の回路用ソフトウエアの上述の方法およびモジュールの異なるステップに起因されてきたが、これらの機能性は、当業者に公知のような異なる順序でおよび異なるモジュールにおいて実行され得る。
【図面の簡単な説明】
【０１４１】
【図１】図１は、本発明の実施形態によるリアルタイムデータを組み込むためのシステムのブロック図である。
【図２】図２は、本発明の実施形態によるゲームデータサーバのより詳細なブロック図である。
【図３】図３は、本発明の実施形態によるゲームシステムのブロック図である。
【図４】図４は、本発明の実施形態による天候マネージャのブロック図である。
【図５】図５は、本発明の実施形態による天候要素依存性のブロック図である。
【図６】図６は、本発明の実施形態によるカメラパスの図である。
【図７】図７は、本発明の実施形態による場所による改変を示す図である。
【図８】図８は、本発明の実施形態による雲物体グリッドの図である。
【図９】図９は、本発明の実施形態によるトラフィックマネージャシステムのブロック図である。【Technical field】
[0001]
The present application relates to electronic games, and more particularly, to games that use real world data to simulate game play.
[Background Art]
[0002]
In the traditional computer gaming experience, players are immersed in a closed environment operated by application developers. Even in games that simulate real-world locations, environmental conditions, actors, and objects are only predefined and changed according to predetermined parameters or algorithms, or at most incorporate pseudo-random changes. The player experience is limited to the boundaries of the creation of the application developer and the player's own choice. Conventional game architectures are only designed to take advantage of the known conditions under which the game operates, and are not designed to account for new or random changes in real-world elements.
[0003]
Conventional games deprive players of the excitement and diversity provided by real-world conditions. For example, in a flight simulator game, a player typically selects different weather conditions, traffic conditions, and other characteristics of the game environment. The application then creates a simulated environment that matches these parameters. Thus, conventional flight simulators may "simulate" external data, but this data does not reflect actual current weather or traffic conditions. Conventional flight simulator add-ons may also be run prior to the start of the game to update the cloud data file for the flight simulator and provide a range of clouds that reflect real-world conditions at the time of the update. However, the in-game environment is updated only at this time prior to execution, and therefore does not change during the game and does not have the ability to allow real-time data to affect game play. In contrast, in the real world, weather can change suddenly and unpredictably, empty traffic can become unpredictably heavy, mechanical failures can occur, airports shut down And sometimes planes can crash, and real pilots have to adapt to these situations. However, none of these events were modeled in a typical game, and if these events were modeled, they could be generated in some non-random pattern, or depending on the user's choice appear. Even if this condition occurs in a pseudo-random pattern, the player can quickly learn the range of possible conditions and provide a significant difference in the level of enjoyment for the player, the conditions under which the player flies. The excitement of knowing that is "real" is further deprived.
[0004]
Thus, with the new game architecture, real-world events, environments, actors, and objects can be incorporated into the gaming experience, giving players a true simulation of the real-world experience, and moreover, real-world events. If it does, it provides additional excitement to participate in the event.
DISCLOSURE OF THE INVENTION
[Means for Solving the Problems]
[0005]
(Summary of the Invention)
According to the present invention, real world information is incorporated into the virtual environment provided to the game. In a software product embodiment, the application module receives a location selection from a player. This location selection selects a geographic location (eg, San Francisco) where the game is played. The application module then retrieves real world information. Real-world information can vary depending on the nature of the game. For flight simulators, real world information includes weather information such as cloud cover, precipitation, wind, fog, and sky traffic data. This real-world information includes the location of other airplanes near the player, the changed route of other airplanes, and airport conditions for the selected location during a period near the time the information was requested. After receiving the real-world information, the application module generates a simulated real-world configuration responsive to the real-world information. For example, in a flight simulator game, the configuration may include cloud, wind, rain, and sky traffic. For example, clouds are created in a virtual environment that responds to the location and nature of the cloud as identified in a real world database. Sky traffic (ie, other aircraft flying near the player's plane) is generated in response to the actual location of the real-world aircraft. In a car racing embodiment, simulated street car traffic is generated in response to real world car traffic on a corresponding real world street. Thus, according to embodiments of the present invention, the real world is simulated for the player to provide the player with the excitement of the real, unpredictable nature of the real world.
[0006]
In one embodiment, the application module determines whether information about the location has changed since the information was last retrieved or when the player was moved to a new location. If either changes, the simulated configuration is regenerated in response to the information, or the simulated configuration is generated in response to an interpolation procedure. This allows real world information to be used in the gaming environment if this information is not continuously available. For example, currently empty traffic information is only available every few minutes so that new information is received in real-world information based on prior heading and flight plan information. Then, the traffic displayed to the player is modified. Since weather data is not available at each location, weather data is simulated for those locations where real world data is not associated. Further, the presence of these weather elements must be inferred from the available data, since all weather elements that can be shown are not represented in the weather database. Thus, the present invention allows real-world data to interact with the player. Thus, in response to all of the actual weather or traffic currently occurring in the world at the selected location, if traffic is congested on a particular day, the player must fly through traffic congestion. Rather, in bad weather, players must use techniques to fight against weather conditions. Accordingly, systems, methods, and applications are provided for integrating real world data into a database that affects a player's ongoing gaming experience.
[0007]
(Detailed description of preferred embodiments)
Although the description herein uses a flight simulation game as an exemplary embodiment for teaching the present invention, the present invention is not limited to this specification and is not limited to car racing, ship racing, motorcycle racing, skiing. Or easily extended to any other type of competitive outdoor gaming activity. In a flight simulator embodiment, the two real-world conditions available to be integrated into the game are weather and sky traffic. Weather and sky traffic data are both collected by third parties and made available in publicly accessible databases. The database stores information regarding predetermined weather conditions for predetermined locations throughout the world (referred to as “observation locations”) and stores traffic information including location, location, heading, and aircraft type. The present invention uses this information to create an exciting, real, and unpredictable gaming experience according to the present invention.
[0008]
Referring to FIG. 1, the game data server 108 continuously collects “real-time” data and weather 104 data provider systems from traffic 100. In response to the request, game data server 108 validates the data available to games 112, 116 and players 120, 124. Data providers 100, 104 are located remotely and are typically accessed via the Internet or other communication means (such as satellite or leased lines). Data providers 100, 104 are conventional, collecting and encoding observations about the world (weather, aircraft traffic, etc.) and making these observations available in real time in a known format or structure. The game data server 108 of the present invention accesses the data and transfers the data to the database storage area. Transferring the "snapshot" of data from the providers 100, 104 to the game data server means that the main load of data access from the games 112, 116 is processed between the game and the game data server 108, and the game and the provider Between being processed.
[0009]
Examples of provided weather data include temperature, wind direction and speed, cloud cover and cloud types at some altitudes, and precipitation types. Examples of empty traffic data are position (latitude and longitude), speed, heading, identification, and flight plan for each aircraft in a geographic area (eg, across the United States). The real-time nature of the data is related to the rate of change of the monitored process, the frequency of which real-time nature of the data is available for updating. Weather data is typically updated by physical (by human) or electronic means (e.g., in a METAR database) and made available once an hour, and these means capture the normal rate of change in weather conditions. Is enough. In special cases (hurricane winds, or extreme bad weather), weather data may be updated more frequently. For this discussion, real-time is considered once an hour or whenever necessary to reflect the predictable rate of change in the real world. The national empty traffic control system updates the traffic data once every three minutes and typically captures position, heading, and aircraft speed changes. This is fast enough to allow the position of the aircraft to be modified in accordance with the present invention to provide a realistic simulation of the flight path of the aircraft.
[0010]
When the player 120 controls a game unit in a game 112 (eg, an aircraft, a car, etc.), the game 112 may be required to provide a real environment for the game. Need. The data required by game 112 includes data such as weather forecasts or empty traffic in the direction that player 120 is guiding vehicles in game 112. Accordingly, the game 112 requests data based on the current location and time of the player gaming unit. This time information may be provided explicitly or implicitly. The frequency of data requests for this game preferably matches the frequency of updating data in the database maintained by the providers 100,104. This allows the game 112 to provide a real-time representation of the world and vehicles of the world to the player at the highest possible speed. Alternatively, the request may be asynchronous, requesting large amounts of data to be used over an extended period of time. Game data server 108 processes game 112 data requests and provides requested data to game 112 for rendering and simulation in game 112. Multiple players 124 may play different copies of game 116 and may access game data server 108 for data responsive to some other area of the world or an area of the same world as player 120. Further, the second player 124 may play a game 116 (eg, a car racing game or a football game) that is completely different from the game 112 being played by the first player 120. However, different games 116 may request the same type of data as the first game 112 (eg, weather). The architecture of the present invention can be extended to meet the data requirements of other games. For example, in addition to weather forecasts, car road racing games may use a database to generate and store real-time data on vehicle traffic. A maritime game may collect and store real-time data on maritime conditions that may be used in the game and thereafter.
[0011]
Referring to FIG. 2, the game data server 108 maintains its sky traffic and weather databases 200, 204 with external sky traffic 100 and data requested from the weather data provider 104 as described above. To control the type and frequency of requests for data generated from external data systems 100, 104, game server 108 uses timer processors 208, 212 to initiate data requests. In a start-up embodiment or any full reset, the timer processor 108, 212 instructs the data requesters 216, 220 to request all current data available for weather and traffic. A snapshot of the data is used by the data update processors 216, 220 to initially populate the databases 200, 204. After the databases 200, 204 are sufficiently congested, the timers 208, 212 then request data at the maximum update frequency and time for personal data and update each database 200, 204. As described above, in the example of weather data, this is once an hour when about 10 minutes have elapsed from that time. In the case of empty traffic data, this is about every 3 minutes. This update time and frequency used by the timers 208, 212 are selected and optimized to match the data provider 100, 104 update time and after-market.
[0012]
When the player 120 plays the computer game 112, it makes a request corresponding to sky traffic and weather data corresponding to changes in the location and time of the player's game unit. Requests for data are preferably made via a separate empty traffic 224 and weather request process 228. Game 112 requests the data in a form that specifies the required data. For example, the game 112 may identify a current position (latitude, longitude, and altitude) in the flight simulator, a state heading. Requests for data by the game 112 are made in response to selection and control inputs by the player 120 (eg, where and how the player 120 is flying the plane in the flight simulation game). This game data request is used by the empty traffic request process 224 and the weather request process 228 to generate data queries to each traffic and weather database 200,204.
[0013]
For example, in one embodiment, to determine most pertinent data, the request processes 224, 228 may include the aircraft performance (747 vs. Piper cub), status (cruise, landing, takeoff, taxiing), current aircraft data ( Consider the previous request (position, heading, speed and direction), position, heading, speed and direction. Aircraft status may include the location of aircraft controls (eg, speed less than 120 kts, gear down, landing conditions for 747 style aircraft such as flaps> 15) and aircraft location (less than 4000 feet and within 10 miles of airport). Means.
[0014]
Request processes 224 and 228 gather data on the direction of travel of the aircraft and the frequency and distance in and around the aircraft appropriate to the aircraft and condition. In the previous 747 landing example, the request process 224, 228 requests data within 30 miles in a circular fashion around the aircraft at low speed (once every 10 minutes). Because the location of the airplane changes less frequently than if the airplane location was a full flight. In cruise conditions, the 747 typically flies at 35,000 feet at 400 miles per hour. In this case, the request process 224, 228 generates data every five minutes within an ellipse that was 200 miles wide and 400 miles long with most of the indicated length towards the current heading of the aircraft. Request. Of course, other parameters for the data request may be used in accordance with the present invention. Thus, the game 112 processes a subset of the larger database 200, 204 that describes the data (weather or aircraft) that the gaming aircraft encounters, but is filtered to relate to the location or route of the aircraft. One advantage of the process described above is that it saves time and bandwidth by minimizing the data needed to be resent to the game.
[0015]
In the case of aircraft data, it may consist of a list of determined aircraft data (eg, identification, flight path, heading, altitude, and speed) within the area where the request process is determined. In the case of weather, the return data consists of weather forecasts (temperature, wind direction, dew point (freezing level), precipitation, etc.) in the area where the weather request process algorithm was determined. The traffic and weather request processes 224, 228 may vary depending on the particular needs (eg, traffic is only needed within 50 miles of the traffic process 224 to work well, but the weather process 228 May need up to 100 miles of data to work well.)
[0016]
Referring to FIG. 3, the game system 107 is shown implemented using an object-oriented design. Preferably, a particular object stores its own data, requests data from other objects when needed, and provides data to other objects when requested. FIG. 3 shows the connections among the traffic manager 300, weather manager 304, aircraft manager 308, world manager 312, rendering engine 316, and player controls 328. After all of these processing requests and processing requests for data from each other, these requests may be visualized as being on a bus architecture. Other game processes, the audio engine 320, and the force feedback engine 324 are hardly connected, and take input only from the aircraft manager 308 and traffic manager 300.
[0017]
Traffic manager 300 maintains an internal database of real-time traffic in the world experienced by users. The traffic manager 300 also simulates the movement of traffic and its control by a traffic controller. Based on the type, state, and location of the player's aircraft received from the player control / game state process 328, the traffic manager 300 sends a message from the game data server 108 within a predefined geographic area around the player's aircraft. Request traffic data. This data is maintained in an internal database located on the player's computer, and this data is continuously updated by these requests and by simulating traffic by the traffic manager's internal processes.
[0018]
This traffic manager 300 processes requests for empty traffic data locations (location, heading, altitude, speed, and identification) from render engine 316 on a continuous basis. This render engine 316 can be any conventional rendering process. This data is used to display aircraft inside the world on the game display. The traffic manager 300 also simulates the communication of empty traffic in the game world based on real-time data. This external realization is performed by a communication command transmitted to the audio engine 336. The audio engine 336 uses these commands to output real audio communication messages (eg, traffic control (ATC) and voice communication from the aircraft) to the user based on the player's state in the game and other aircraft. These messages include messages between the ATC and other aircraft and between the ATC and the player 120. This sound is simulated using conventional techniques as known to those skilled in the art.
[0019]
The weather manager 304 maintains an internal database of real-time weather in the world experienced by the user. Based on the player's aircraft state data (location, heading, altitude, speed, and identification) received from the player control / game state process 228, the weather manager 304 Request weather data. This data is maintained in an internal database that is continuously updated by these requests (based on weather data and the rate of change of aircraft movement) and weather simulations based on weather manager rules. The weather manager 304 processes requests for weather conditions (thermal wind, precipitation, visibility) from the render engine 316 on a continuous basis through a general area. This data is used to display real-time weather changes in the world on the game display.
[0020]
The weather manager 304 also simulates real, changing climate based on real-time weather supply and a process based on rules within the weather manager 304 itself, and uses available real-world data (eg, wind gust, Provides weather effects not provided by thunderstorms, cloud drift rates, any precipitation intensity, etc. A rule-based process that reacts to weather changes and trends near distance and time, such as gusts, is called micro-level processing. Macro processes account for trends that can occur due to daily or calendar trends. Examples of macro processes are by date and time (trend of thunderstorms occurring during the last afternoon), or by the time of year (many stratus clouds (but not thunderclouds) tend to develop in the United States during winter). Includes processes that are triggered. The changing weather reveals the changing weather itself to the user by the rendering engine 316. Thus, the use of micro and macro processes extends real-world data information to create new game conditions that are random. Because the experience depends on real world weather. In addition, since thunderstorms or gusts can significantly affect a pilot's ability to fly an airplane in a flight simulation game or drive a car in a car racing game, these processes interact with the player's game play and interact. Create weather effects.
[0021]
(Micro process)
If the weather data is updated only once an hour, one embodiment of the present invention uses micro-process rules that communicate movement between these updates once an hour and change to world data. These results look at how the data typically changes over time and convey if the acquired real-world data can change over a later time before receiving the next update Use simple rules developed for:
[0022]
(Wind macro processing)
Wind is reported and expressed as direction, speed, and gust (if there is a gust up to 10kts, 20kts from 360). Typically, this data is updated each hour by each reporting station. The weather manager 304 maintains weather observation data for locations reported at current and previous times, respectively. The wind macro process compares the wind direction, wind speed, and gust values of these observations, and actively changes the wind conditions experienced by the player over the next time period.
[0023]
(Transition of game weather to current weather observation)
When a new weather observation comes in, the weather manager 304 slowly changes the wind that the player sees at that location over the next 10 minutes. Although the wind can change quickly, changing the values over a reasonable short period of time makes the environment more believable. In one embodiment, game 116 changes direction, speed, and gust values by about 10 percent each minute. For example, the current game weather at a location is direction 180, velocity 5, and gust 10, and a new observation at the same location at time t is direction 150, velocity 10, and gust 15. In one embodiment, the wind microprocess calculates the difference between the current and new observations as follows.
[0024]
Direction: -30 (150-180), speed +5 (10-5), and gust +5 (15-10)
The wind microprocess then changes by this amount over the next 10 minutes so that the wind at this location matches the observed value. The weather manager 304 implements 1/10 (preferably rounded to the nearest integer) of this communicated change to each value for each minute over the next 10 minutes. This value that the player sees will almost change as follows

(Communication of weather trends)
After a 10 minute period in which the game weather changes to match the actual weather, the game microprocess then acts to change the weather for the remainder of the time in the direction of the perceived tendency. This process compares the current weather observation with previously reported observations, calculates a random change within the change, and then causes the weather to change over the remaining time to match this change.
[0025]
For example, a reported observation at a location at time t-1 may be direction 200, velocity 5, gust 10, and a reported observation at the same location at time t is direction 150, velocity 10, gust 15. obtain. The wind microprocess then calculates the difference between the two observations as direction -50 (150-200), velocity +5 (10-5), and gust +5 (15-10). The wind microprocess then selects a random value within the range of the change (e.g., -20, 3, 2) and assigns this value to the following reported weather, direction 120, speed 13, current weather resulting in gust 17: Append to value. This weather manager 300 implements 20% (rounded to the nearest integer) of the reported change, preferably for each 10 minutes, until the next hourly update. This change can be shown as follows.
[0026]

Thus, the present invention uses a wind micro-process to actively create weather effects based on real-world conditions for controlling the gaming experience.
[0027]
(Macro processing)
As explained at the outset, microprocesses act to fill or communicate data in time when there is no data. The microprocess works in time between data updates. Macro processes, on the other hand, work over a larger scale to add information to weather data. The weather data has information but is less detailed than the information desired for the simulation.
[0028]
(Frequency of thunderstorm macro process)
In one embodiment, a macro process is used to assess the frequency of thunderstorms in a region. Weather observations of a particular area only list the presence of a thunderstorm and its relative severity (reported as severe or not). In this embodiment, the present invention augments this data by using simple rules that typically have more thunderclouds or cells in a given area, and this data may fall in the fall or winter months. But was told to have a thunderstorm in the summer months. For example, when generating cloud information for an area that has been reported to have a thunderstorm, the program averages selected elementary level 3 thunderclouds per sector during most of the year. During the Northern Hemisphere summer months (June-August), more warming can cause more frequent and more thunderclouds.
[0029]
When assigning a thundercloud to a sector, the macro process determines within which month the player is currently playing the game 112. This information is readily made available from any number of sources or external databases, including the player's computer. Between June and August, the process adds a random number to the base average that can produce twice the amount of thunderclouds per given area. In this manner, the game 112 provides players with a different experience based on real-world processes by inducing weather changes in response to current weather data and one year periods.
[0030]
Referring again to FIG. 3, the aircraft manager 308 processes and maintains information about the player's aircraft and internal systems. The aircraft manager 308 takes control inputs from the player's control process 328 (moving the aircraft and controlling the system). The aircraft manager 308 then interfaces with the weather manager 304 for real-time weather information. This real-time weather information (eg, precipitation, wind, temperature) is sent to the aircraft manager, the traffic manager 300 providing a display of real-time traffic in the cockpit display, and the world manager 312 for operational and physical information about the world. Affect. Aircraft manager 308 provides rendering engine 316 with aircraft-specific information about the aircraft. Aircraft manager 308 also outputs directives to audio engine 320 and force feedback engine 324 when it is necessary to simulate aircraft sounds and real-time sensations known to those skilled in the art.
[0031]
The world manager 312 maintains information about the physical state of the world, as known to those skilled in the art. This includes information on terrain, ground cover, hydrology, buildings, roads, and navigation features. The world manager 312 takes real-time inputs from the weather manager 304 that can affect the appearance of the terrain (temperature, precipitation). World manager 312 provides navigation and terrain information to traffic manager 300 and aircraft manager 304. World manager 312 also provides information to rendering engine 316.
[0032]
The rendering engine 316 presents the user with the internal state (cockpit) and the external state (terrain, weather, other aircraft) of the game via the display 332 using conventional techniques. The audio engine 320 provides real-world aircraft, communications, and world sounds to the user. Based on inputs from aircraft manager 308 and traffic manager 300, audio engine 320 outputs events based on event-based sound and voice communication to user via audio system 336. Event-based sounds (engine noise, cockpit switch movements, or aircraft crashes) are generated by audio engine 320 in response to events sent to audio engine 320 by aircraft manager 308. These sounds are either output once in the case of a switch movement, or are continuously changed until changed (in the case of an engine drone).
[0033]
The audio system also generates audio audio messages generated by the traffic manager 300 from the empty traffic controller (ATC) and other aircraft that can be heard by the user. This possible phrase in the game (e.g., "turn left toward heading 350" or "ranger, turn left toward heading 350") Proceeded ahead for position (ATC, pseudo-aircraft, and player). It is located in a database that can be referenced by commands. The voice actor may include all words and numbers (eg, words (turn, left, right, to, from, heading), 0, 1, 2,...) In all phrases made at that location. 3, 4, 5, etc. can be used to record (recorded by the person indicating the ATC controller). Placed in a database that can be referenced by location and word.
[0034]
The communication command is received by the audio engine 320, and the communication command includes all of the information needed to identify and satisfy the phrase. That is, it includes all of the location (ATC, player, pseudo-aircraft), command (e.g., TURN_TO_HEADING), and any specific data for which the phrase (direction: left, designation 350) needs to be written. The audio engine 320 then references the phrase for that location, refers to the voice data for the word data recorded for that location, and then “stitches” the voice data in the order indicated by the phrase. The voice data is output to an audio speaker using a conventional process called "stitching".
[0035]
Force feedback engine 324 provides the user with force feedback information via skin hardware included in a joystick known to those skilled in the art. This feedback information is generated in response to input from aircraft manager 308. Examples of this feedback include control pressure, wheel spin, vibration, landing bumper, or vibration due to aircraft engine problems.
[0036]
The player control / game process 328 controls the trajectory and execution of the game via selection and control information from the user, and provides other engines with current information about the game units controlled by the player. The player control / game process 328 also maintains data about the game and the state of the world.
[0037]
Joystick 340 also allows the user to provide input to the game via player control / game state process 328. These inputs may include control information (sway, vibration, and rotation), throttle position, and function selection (eg, gear down or flap control). The user also receives the appropriate force feedback information of the information from the game via the force feedback engine 324. Keyboard 344 is a standard computer keyboard. Players use encoded keypresses and macros to control game and aircraft configurations.
[0038]
Accordingly, the present invention provides a system for integrating real-world data into a game to affect a player's gaming experience in a real and random manner so that real-world weather and traffic data is Affect and affect the results of
[0039]
The following description describes two important elements in a flight simulator according to an embodiment of the present invention. The weather engine and the traffic manager.
[0040]
(I. Weather engine)
FIG. 4 illustrates the relationship between the weather engine 400 and the weather manager 304. The weather engine 400 receives weather input data (observations) from the weather manager 304 and performs calculations of the current weather condition on the weather manager 304 request for the data. As described above, the weather manager 304 maintains weather data used to describe the weather or any other display location around the aircraft needed in the game. In a preferred embodiment, weather engine 400 is a stand-alone module that performs modifications for weather simulation. Players may play the game 112 because actual real world data is available for each location and time. The game 112 modifies data based on real world data for controlling game play.
[0041]
The input for the weather engine 400 is a set of weather observations with dedicated location and time values. The output of the weather engine 400 is a modified weather condition for any dedicated position and time values. The weather engine 400 may then smoothly transition through the game as the player's aircraft moves from one location to another, or as the player's aircraft moves in time to provide a real-time, real-time weather experience to the player 120. Change the rendered weather. In addition, the weather engine 400 generates both "point" weather conditions for most weather elements and "environment" conditions for some cloud types. The weather engine 400 is connected to 404 a weather element that stores attribute information about various weather elements to be used to generate the modified weather.
[0042]
(Weather element)
The following is an exemplary list of weather elements maintained in the weather element database 404.
·cloud. Clouds are classified by cloud type and cloud layer. Clouds are identified using the following attributes: Cloud type, layer-based altitude, altitude above the layer, density (range).
·Wind. Winds are classified by stratum. Further, the wind varies linearly between the layers. Wind is specified using the following attributes: That is, height, direction and speed. Alternatively, gusts and squalls may be identified.
・ Visibility. The field of view is specialized using the number of miles that can be seen horizontally. Limited visibility is provided by fumes and fog.
·temperature. Temperatures are specified in degrees Celsius.
·pressure. The pressure is specified in millibar.
·Precipitation amount. The supported precipitation is rain, snow, and these can coexist. Precipitation is specified by density.
・ Thunderstorm. Thunderstorms are identified by power.
・ Freezing. The possible presence of icing is predicted according to other weather factors and is described below.
-Turbulence. The possible presence of turbulence is predicted according to other weather factors.
[0043]
(Weather element dependency)
An observation point is a set of weather data collected and reported in a weather database prepared by a weather data provider 104. Some of the weather elements are defined for observation points, while other elements are composited according to other weather elements. For example, "ice" and "turbulence" are not specific to the observation point and are therefore calculated according to the presence and degree of other weather elements. FIG. 5 is a block diagram illustrating the different elements, their outputs, and other elements (if any). Different weather elements require different outputs. For example, precipitation requires rendering and audio and is synthesized based on cloud and temperature information. Freezing is synthesized based on temperature and visibility factors. However, the clouds themselves are rendered and based on the actual data for a given observer, or modified if the current location of the game unit is between observers.
[0044]
(A. Weather element modification)
The main purpose of weather modification is to make the weather change smoothly. While moving from one location to another, or based on a modification of the weather element of these observation locations, the weather elements for these observation locations near the time and location relative to the current location and time of the player's game unit. Move on time based on the modification. The following algorithm is an embodiment that implements weather modification by both time and location using observation points with actual weather data.
[0045]
(Step 1-Filter weather observation by location)
The first step for weather modification is to select the relative observation location used for the modification. FIG. 6 shows the process of an iterative selection block to select an observation location. All observations are stored as blocks, and the blocks are specified by latitude and longitude values. The task is to select an observation location that is spatially and temporally close to the current location of the player's aircraft. First, the weather engine 400 processes the block containing the location of the aircraft to determine whether the block contains an observation location. Then, if the block does not include an observation point, the weather engine 400 processes blocks around the block including the location of the aircraft, as shown in FIG. However, if there are no observers in the location of the aircraft, the range value of the search is augmented to include the block closest to the current location. The weather engine 400 then processes the next closest block in the next path, as shown in FIG. If any observation point is found in the path, the weather engine 400 stops on any path. These observation points are used for modification.
[0046]
(Step 2. Modification by time)
The second step for weather modification is to select the relevant observation according to the current time value. For each observation location picked up in the first step, the observation location closest to the current time value (closest minimum and maximum time value) is selected.
[0047]
The following cases can occur
All of the observation areas found in step 1 are located in the past. In this situation, the weather engine 400 selects the latest observation location for modification.
-All observations are in the future. In this example, the oldest observation is selected.
・ There are both future and past observations. In this case, the weather engine 400 selects the latest observation in the past and the closest observation in the future, and generates a modified observation based on weather factors for each observation location. In one embodiment, the modified observation location is selected linearly according to the current time value and the selected observation time value.
[0048]
(Step 3-Modify by location)
Next, a modified observation for the camera location is created according to all of the modified observation locations selected in the previous step. FIG. 7 shows an embodiment of the present modification mechanism. Di is the square of the distance between the location of the camera and the location of observation #i, the unnormalized weight for observation #i is calculated as 1 / Di, and the total weight for normalization is normalized. Is calculated as the sum of the missing weights ({S = 1 / D1 + 1 / D2 + 1 / D3 ...) and the normalized weight for observation #i is unnormalized divided by the sum weight It is calculated as weight 1 / (Di * S).
[0049]
A special case exists when there is more than one very close observation. In this case, the closest observation with time (Di is about 0) is selected as the observation point for the camera location.
[0050]
(Step 4-Calculation of Undefined Elements)
Some weather factors may not be present for the selected observation location. In this case, it must be calculated after modification of the current weather element according to the specific weather element rules. For example, it is calculated via a standard pressure reduction rate table. Freezing is calculated to account for the considerations, precipitation, cloud type, and temperature at that location.
[0051]
(Step 5-Modification by height)
Some weather elements are defined as layers (eg, wind) but are calculated for a particular camera height location (wind, then temperature, freezing and turbulence). For these factors, the weather factor values must be linearly modified between the values of the closest layers. Furthermore, the calculation at a particular height, preferably the wind calculation, accounts for gusts that can randomly change the wind speed and direction.
[0052]
(B. Cloud modification)
The extent of the clouds (important in flight simulation games) is also preferably modified according to the invention. In one embodiment, the cloud object is implemented with a grid that moves as the player's aircraft moves. Cloud parameters are calculated according to real-world observation data modified for each vertex of the grid. FIG. 8 shows a cloud object for a cloud coverage of about 2/8. Each cell of the grid contains one cloud object. The location of the cloud object is random for each cell, but larger clouds (larger cloud ranges) have lower location "degrees of freedom". Thus, for the entire range, each cloud object is accurately located at the top of the grid. The size of the cloud object is calculated according to the current cloud range value obtained from the observation data. In one embodiment, random values are added (both positive and negative sizes) to provide a more realistic simulation. Each cloud object has a corresponding seed value to generate a cloud morphology. This seed value is preferably changed smoothly over time to emulate a real change in cloud morphology. Further, each cloud object has a swing random value that does not change with time. This swing value specifies the angle from the vertical axis at which the cloud undulates.
[0053]
(Cloud grid generation)
A cloud grid is created for each new aircraft and cloud layer. For each grid vertex (cloud object), the following values are generated in grid creation:
-Size change factor. SizeVariation in the range from minimum cloud size change to maximum size change.
An offset change factor (offsetVariation) in the range of 0-1.
An initial seed value in the range 0.0 to 255.0.
[0054]
(Cloud grid processing for moving aircraft)
The cloud grid is always aligned to the cloud grid step. Thus, when the aircraft moves to a new location, some grid rows and / or columns are detected and new grid rows and / or columns are added (if the movement is large enough). In this case, the memory block (which still exists but moves to the vertex) is moved and a new vertex (cloud object) value is generated.
[0055]
(Calculation of vertex values)
The value for each vertex is also recalculated in one embodiment for each weather cycle. In one embodiment, the following values are recalculated.
[0056]
(size)
The size of the cloud is calculated at that location as CloudDensity * cloud grid step * SizeVariation according to the range of the cloud (Cloud Density, 0-1). This calculated cloud size should be in the range of 0 to cloud grid steps. This value should be adjusted in case of overflow.
[0057]
(Cloud height)
The cloud height is the current height of the cloud layer at that location.
[0058]
(offset)
The cloud offset from the grid vertex is calculated as (cloud grid step-CloudSize) * OffsetVariation.
[0059]
(Seed value)
This seed value is calculated according to the elapsed time value (time_t, (seconds)) where CurrentSeed + TimeElapsed * CLOUD_SEED_CHANGE (CLOUD_SEED_CHANGE is the object (subject) for fine adjustment, and a value of 0.2 can be assumed first). Is done.
[0060]
(C. Freezing module)
In a preferred embodiment, the present invention uses real-time data that simulates icing conditions on an airplane. This icing condition is a weather effect that is not provided by real-time data, but is generated and caused by real-time data. This icing condition is also a weather effect that has a direct effect on the player's gaming experience, as severe icing conditions can break down an airplane and even crash. In one embodiment, the freeze module is a module included within weather engine 400. The freeze module obtains input information about the weather, which determines the presence and severity of the freeze. The icing module also receives configuration information about the aircraft, including the status of the deicing system on the aircraft. The freeze module calculates and maintains the presence and level of freeze on the aircraft based on weather, aircraft configuration, aircraft location, and pilot aircraft and action locations. It can be done to reflect differences in the type and severity of icing and the impact on different aircraft configurations. The output of the freeze module is the maximum percentage (0.0 to 1) of the freeze level of some important parts of the aircraft (windshield, side windows, wings, fuselage, and engine inlet) that are adversely affected by the freeze. .0). The data is used by other modules within the aircraft system model (dynamics, engine) that affect real-world changes in aircraft performance and operation. This data is used by the renderer to display to the user the actual effect of the freeze (freeze on the airframe, reduced view due to window freeze).
[0061]
(I. High level process of freezing)
In one embodiment, at the highest level, the freeze module is presented by a loop consisting of:
[0062]
1. Enter the current state of the world and aircraft
2. Calculate ice accumulation
3. Calculate deaccumulation (melting)
4. Output updated icing status of aircraft
5. repeat
In order for this model to take as input some variables that are affected by the user, the module is preferably scheduled to run at a rate that indicates a change in freezing to the user. However, ice does not freeze or thaw at any high speed, and it is typically sufficient to have the module run once every 5 seconds.
[0063]
(2. General variables of freezing)
From game state control
・ Aircraft location (latitude and longitude)
・ Aircraft altitude (feet)
Windshield_deice_on (Boolean indicating whether the windshield deicing system is currently operating)
Wing_deice_on (Boolean indicating whether the wing deicing system is currently operating)
-These variables are false on aircraft that do not include these systems. In one embodiment, the system may be made to fail, so that even if the user moves to control on (true), the system may be off (false).
[0064]
From the weather manager 304
-Ground_temperature at the current position
OAT (external air temperature). This is calculated from the ground_temperature using a standard decay rate calculation of 3 degrees per 1000 feet (assuming 70 ° F ground_temperature which results in an OAT estimate of 40 ° F at 10,000 feet).
[0065]
Cloud_coverage (extent of the cloud at this position and altitude). This is a number between 0 (no cloud) and 1 (all sky clouds) at an altitude within the weather coordinates that include this location.
[0066]
(3. Variables specific to freezing)
The following variables are maintained by the freeze module and made available to other models. This variable may have a value between 0.0 (no freezing) and 1 (full freezing).
[0067]
Windshield_icing (freezing level of the visibility windshield in front of the aircraft)
-Side_windows_icing (freezing level on the side window)
・ Wing_icing (freezing level on the wing)
・ Fusage_icing (freezing level on the aircraft)
・ Engine_intake_icing (freezing level of engine intake)
Each of these variables may cause that level to change to another level based on platform and aircraft configuration.
[0068]
(4. Freezing treatment)
An estimate of the effect of freezing on an aircraft in the real world is used by the present invention to calculate the freezing effect.
[0069]
(I) Input state data)
Game state and weather data are accessed and read from the freeze module.
[0070]
(Ii) Calculation of icing accumulation)
If the aircraft is in the visible water vapor (cloud) range and the outside air temperature (OAT) (and this water vapor freezes in contact (10-30 ° F.)) but is within the temperature range, freezing on the aircraft will occur. Accumulate on various surfaces. Warmer temperatures melt the ice. At cooler temperatures, the water vapor does not melt at the interface.
[0071]
For example, higher velocity accumulations may be assigned to cloud cover (flowing clouds) of clouds higher than 70% cloud cover. This speed is also shown to vary with aircraft configuration and ice type, or altitude.
[0072]
In one embodiment, the following algorithm is used to calculate icing accumulation.
[0073]
(Equation 1)

(Iii) Ice detachment (melting by air or deicing equipment) and calculation of melting due to atmospheric effects)
There are two ways to fight freezing in the real world. For one, the temperature is warm enough to melt the ice. Flying in an area or altitude. This is an OAT higher than 32 ° F. However, while pilots can fly outside of freezing conditions, OAT is not warm enough to abduct ice.
[0074]
One algorithm for calculating deicing based on flying to warmer areas is:
[0075]
(Equation 2)

(Iv) Deicing by using aircraft equipment)
Another way to combat freezing is to use deicing equipment. Freezing installations are often unreliable, unreliable and difficult to apply consistently and efficiently. If the pilot does not apply the equipment frequently and regularly, ice may accumulate so that the ice equipment cannot melt the ice. For example, if the equipment is not used with sufficient deicing equipment, the deicing value may be set to half of the total amount.
[0076]
Deicing equipment can operate efficiently, but deicing equipment cannot cover all of the aircraft. Ultimately, deicing equipment is enabled at higher levels of accumulation frequency during icing conditions, and the deicing equipment may not be able to maintain deicing conditions.
[0077]
One algorithm for calculating deicing using deicing equipment is:
[0078]
[Equation 3]

The first algorithm emulates ice melting (de-icing) by an aircraft due to sufficiently warm temperatures and the absence of the aircraft in the clouds. The second algorithm emulates removing ice due to either deicing on a windshield or deicing on a wing.
[0079]
Thus, for each loop (cycle in the game), the deicing facility will attempt to remove ice from the wings and windshield. However, as noted above, if the pilot does not fly away from the ice conditions, the deicing conditions of the present invention offer the potential that icing can squeeze equipment and / or aircraft.
[0080]
(V) Output state of freeze variables
The input state of the freezing variable is changed by the accumulation and departure model. The resulting value is made available to other modules and external modules. Some examples of how these variables are used are shown below.
[0081]
(A) Aircraft system model
Aircraft system models are conventional models that simulate the flight of an aircraft.
[0082]
(1. Calculation of lift)
Ice accumulation on the wing reduces the lift generated by the wing by up to half. Thus, the freeze model adjusts the aircraft system model as follows. Lift = Lift * (Wing_icing * 0.5).
[0083]
(2. Calculation of drag)
Ice accumulation on the wings and fuselage adds up to 25% or more resistance to aircraft performance. Thus, in this example, the aircraft system model is adjusted as follows.
[0084]
Drag = Drag * (1+ (0.125 * (wing_icing + fuselage_icing)))
(3. Weight calculation)
Ice accumulation on the wings and fuselage can add significant weight to the aircraft (up to 25% or more for this example). This adjustment may be as follows.
[0085]
Aircraft_weight = Aircraft_weight * (1+ (0.125 * (wing_icing + fuselage_icing)))
(4. Calculation of engine performance)
Engine intake icing can affect engine performance by limiting the amount of air available. This adjustment may be as follows.
[0086]
Thrust = Thrust- (Thrust * Engine_intake_icing)
(5. Calculation of the effect of aircraft freeze on aircraft equipment)
Freezing can also affect the operation of aircraft gears, flaps, and equipment (with freezing on).
[0087]
(Equation 4)

(B) Freezing render model)
These are examples of render decisions that are affected by the results of the freeze model. This render displays a view of the outside world and aircraft to the user. This may generally include windshields, side windows, and aircraft.
[0088]
(1. View from the windshield)
The view from the windshield is generally transparent. Under icing conditions, the amount of visibility is reduced by the amount of windshield_icing. Here, the frozen windshield display array is pre-rendered and displayed based on the windshield_icing value. For example,
windshield_panel = windshield_icing_panels [windshield_icing]
(2. View from the side window)
The view from the side window is obscured by the window_icing percentage indicated by that variable. Here, the frozen window display array is pre-rendered and displayed based on the window_icing value.
[0089]
window_panel = window_icing_panel [window_icing]
(C) Aircraft rendering)
The aircraft itself indicated by the user is changed depending on the windshield_icing, window_icing, wing_icing, and fuselage_icing load associated values. Pre-rendered representations of the icing effects at various real accumulation levels are added to the aircraft model depending on the values of these variables. The user sees this accumulation when looking out of the window and when an external view is selected. This includes multiple arrays and calculations as shown above.
[0090]
Thus, the freeze module uses real-world data as the basis for generating freeze effects that interact with the player's aircraft and the rendering of the aircraft according to the present invention, and based on current and actual weather conditions, an exciting game. Provide experience.
[0091]
(II. Traffic Manager)
Referring to FIG. 9, the traffic manager 300 is comprised of several independent processes that implement its functionality. The traffic engine 900 creates, manages, and updates all of the aircraft in the player's game 112. The traffic engine 900 first requests player aircraft data (position, altitude, heading, speed, and configuration) from the player control / game state engine 328. The traffic engine 900 uses this data to formulate requests to the game data server 108 for aircraft traffic around the player's aircraft as described above. The traffic engine 900 uses the data returned to create an aircraft in the game 112. The traffic engine 900 manages this data through use of the traffic database 904, which includes a list of all active aircraft near the player's aircraft, including the player's aircraft. The information stored for each database entry typically includes an aircraft identification number (eg, TWA 714) and a unique pointer to pseudo and player aircraft objects created by the traffic engine 900 later in this process. . This traffic database 904 is also used by other processes in the game 112 to identify and access this traffic object.
[0092]
By adding aircraft entries to the traffic database 904, the traffic engine 900 also manages the database 904 by removing entries from the database 904 that are outside the player's territory. In one embodiment, traffic engine 900 also removes entries from traffic database 904 for any aircraft that did not receive a report for three update cycles. As described above, updates to the database 904 are received for aircraft within a predetermined geographic area of the player's aircraft. Thus, the lack of a report indicates the aircraft that has landed, or indicates that its location is far enough away from the player's aircraft that is no longer relevant to the player's game 116.
[0093]
First, the traffic engine 900 creates a single ATC process 908. The ATC process 908 controls and communicates with the simulated aircraft processor 916 and the player aircraft process 932 so that the ATC process 908 appears to the player as a real ATC controller. By including a link to the traffic database 904, the ATC process 908 has access to all data of the associated aircraft (eg, current speed, heading, and altitude).
[0094]
The traffic engine 900 then creates a unique pseudo-aircraft process 916 for each non-player aircraft when information about the new non-player aircraft is entered into the traffic database 904. The traffic engine 900 sends data report updates for the real aircraft to the simulated aircraft process 916 as the data becomes available. This data is used by the simulated aircraft process 916 to match the location and configuration of the aircraft with the data of a real aircraft. Each simulated aircraft process 916 appears and behaves to player 120 as a real aircraft in the world. This simulated aircraft data includes data such as position in the world (x, y position, heading, speed, and altitude), aircraft identification, and status (gear position, flap position, etc.). This data is maintained internally and may be issued in response to data requests from other game processes, such as ATC process 908 and rendering engine 316. A communication / control link using the ATC process 908 is also established during creation. This link allows the simulated aircraft process 916 to create a communication command and respond to the ATC process 908. Audio communication generated by the simulated aircraft process 916 is accomplished by sending communication commands to the audio engine 320.
[0095]
The traffic engine 900 also creates a player aircraft process 912 that is externally linked to the player control / game state engine 328 and internally linked to the ATC process 908. This allows the ATC process 908 to monitor and interact with the player. Information about the player's aircraft and intent is accessible to the ATC process 908 via a process that monitors data from the player control / game state engine 328 to the player aircraft process 912. The ATC process 908 also preferably interacts with the player via voice communication commands sent to the audio engine 320 (nearly heard by the player).
The player responds and interacts with the controller via the interface (controls, menus, and keyboard commands) provided by the player control / game state engine 328.
[0096]
(A. Simulated aircraft process algorithm)
Each pseudo-aircraft process 916 preferably includes simulation execution, a common database, and individual modules that handle communication, navigation, and control, rule-based decision making. This simulation execution schedules the order of execution of the individual modules. In one embodiment, after initialization, the order of process execution is:
1. Communication module (enter new data and commands)
2. Rule-based logic module (react to updated data)
3. Navigation and control module (moves aircraft to follow current aircraft destination)
4. Communication module (output data and command)
5. repetition
(1. Common database)
The common database includes reports received from the traffic engine 900, data on the current state of the aircraft as controlled by the logic and navigation modules, and data on internal targets and states of the simulated aircraft itself (eg, the current state of the navigation and control modules). Used to store the destination). This common database is also used to provide a common communication architecture for process modules. Changes to the database are entered and acted upon by the module.
[0097]
(2. Communication module)
The communication module manages overall communication between the simulated aircraft process 916 and other external processes. The communication module uses a common database as an area to store new data and messages or to send data to external processes. Data input by the communication module includes update reports from the traffic engine 900, commands from the ATC process 908, and data requests from other processes. The communication module outputs data to an external processor based on messages dictated by other modules. Data output by the communication module includes messages to the ATC process 908 and audio engine 328, data requests to other modules, and location updates to the rendering engine 316 and other processors.
[0098]
(3. Rule-based logic module)
The rule-based logic module controls the operation of the pseudo-aircraft in response to changes in the state of the pseudo-aircraft and changes in the world around it. If the real-time data received by the simulated aircraft fluctuates by day, location, and weather, the real-time data interacts with these rules, which provide the effect of the real-time data on the player's experience within the game. Examples of these pre-programmed and flexible operating rules include changes in aircraft position, ATC communication and control, and rules that respond to player aircraft position (if controlled by the player). For example, one rule for responding to the location of an aircraft includes the need to notify the traffic control process 908 that the simulated aircraft is within 50 miles of the airport and is about to land. This also results in audio messages being heard by the player.
[0099]
An example rule that illustrates this is:
[0100]
(Equation 5)

The simulated aircraft also responds to commands by the traffic controller. If the aircraft is close enough to the airport, the ATC controller tells the (pseudo) aircraft to stop following the path of the real aircraft and to follow the command to land. The simulated aircraft responds by changing its navigation module to follow the ATC command, and following the command, the module responds to the ATC process 908 that received the command and signaled the same command via audio. .
[0101]
One algorithm to achieve this behavior is
[0102]
(Equation 6)

It is.
[0103]
Simulated aircraft 916 may also respond to player aircraft movement. The simulated aircraft 916 monitors any aircraft that are approaching the simulated aircraft (e.g., the player's aircraft attempts to hit the simulated aircraft) and is based on rules based on rules that attempt to move away from the aircraft. May be included. When this occurs, the rules-based logic of the simulated aircraft may instruct the aircraft to interrupt normal navigation, fly away from the player's aircraft, and send a protest message to the ATC. One example of an algorithm for achieving this behavior is:
[0104]
(Equation 7)

It is.
[0105]
Once the player has moved away from the simulated aircraft, the following rules return the simulated aircraft to operate normally.
[0106]
(Equation 8)

(B. Navigation and control)
The navigation and control module includes conventional autopilot functionality. It enables navigating and controlling the simulated aircraft by following report updates stored in a common database using conventional techniques. However, according to the invention, the navigation and control module also allows to follow the navigation commands issued to these modules by either the logic module based on its internal rules or the external ATC process 908.
[0107]
The navigation and control module uses the report updates to match the aircraft position, altitude, speed, and heading of the simulated aircraft to those of the real aircraft. If the report data (position, heading speed and altitude) is updated by the traffic engine 900 about every three minutes, in one embodiment, as described above, in one embodiment, the navigation and control module Interpolate and generate its own data that approximates aircraft movements during the update of the system, which is described in more detail below. The current position, heading, altitude, and speed of the simulated aircraft are transmitted to the rendering engine and made available to other processes within the game.
[0108]
In addition to matching the actual aircraft movement, the navigation and control module also allows for responding to certain navigation commands. These commands may be issued to this module by an internal rule-based logic module or ATC process 908. Examples of these commands are
・ Aim at a specific heading (left or right)
・ Altitude (descent, ascent, or maintenance)
.Of a certain speed (increase or decrease)
Direct flight to a point (x, y position and altitude)
Holding at a point (turn at a specific x, y position and altitude)
・ Approaching and landing at the airport
・ Exercise away from (a certain x, y position)
-Normal navigation according to report update (stop, restart)
・ Clear for approach
・ Clear for landing
These commands exist in a simple format that is easily communicated during the process (eg, a “turn left to heading 350” command may be expressed as a turn_left_to_heading 350).
[0109]
(C. Navigating and averaging between aircraft observations)
In order for the simulated aircraft to operate in a reliable manner, the simulated aircraft must transition smoothly between position reports. These reports include the reported heading, speed, altitude, and X, Y (latitude, longitude) location. This simulated aircraft is first created at the location (X, Y latitude and longitude) of the latest report for the real aircraft it represents. Simulated aircraft are also created at the altitude of a real aircraft and with the heading and atmospheric speed of the aircraft. The simulated aircraft is then "moved" forward from its position using heading, speed, and altitude. Changes in the position of the simulated aircraft are calculated internally by the aircraft agent and output to the rendering engine 328. This continues until the next report (longitude, latitude, altitude, heading, and speed) from the real aircraft is received. The simulated aircraft process 916 then compares the difference between the simulated aircraft position in the game 116 and the actual aircraft position. First, the process 916 calculates a vector that includes changes in heading, speed, and altitude that cause the pseudo-aircraft to move more directly to its location (so that the aircraft can capture to the actual location of the aircraft). it can). Process 916 then adds the vector (using vector addition) to the heading, altitude, and velocity vector of the report from the real aircraft (the vector of the real aircraft will be headed by the aircraft). To reflect where you are). The simulated aircraft process 916 then instructs the simulated aircraft to change course, heading, and speed to match the vector. Thus, the resulting vector reflects both the changes needed to better reflect the actual aircraft position and the movement along the actual course.
[0110]
Finally, in accordance with the present invention, the autopilot is programmed to perform heading and altitude movement. Rather than commanding a quick move to a vector change, autopilot manages the change over about 30 seconds. After the simulated aircraft has stabilized on that vector, the simulated aircraft continues to move along that vector until the next update where the process is repeated.
[0111]
(D. Avoidance of player's aircraft)
Another issue in integrating real-time data with games is to control the interaction between player aircraft and pseudo-aircraft. In one embodiment, the rules are used to cause the simulated aircraft to install player control circuitry. First, the simulated aircraft flies off if the player's aircraft is within range of the simulated aircraft and moves quickly toward that range. Second, the simulated aircraft stops moving away from the player's aircraft if the player approaches at a lower speed. Third, the simulated aircraft allows the player's aircraft to fly close to the simulated aircraft (within the maximum range) at a sufficiently low speed and at the same distance as the first approach. Fourth, the pseudo-lap attempts to fly away from the player's aircraft if the player's aircraft moves within a sole maximum range. These rules allow the player's aircraft to interact with real-time pseudo traffic without causing a collision. The player may then develop the technology of flying in formation by moving closer to the simulated aircraft. The player also attempts to intentionally fly the pseudo-aircraft, or forces the pseudo-aircraft to jump out of its course or to fly to ground objects or mountains. In one embodiment, if the simulated aircraft, or the simulated and player's aircraft, collides with another object, the colliding object explodes and the game session ends.
[0112]
The following is one embodiment of an algorithm for achieving the above rules.
[0113]
(Calculation of distance from ps to p2, approach speed from ps to p2, and avoidance vector from ps to p2)
The distance from the simulated aircraft to the player's aircraft is calculated as the cube root of the sum of the squares of X, Y and the altitude difference. For each, X and Y are converted from latitude and longitude and latitude into feet from zero latitude point and zero longitude point. Altitude (A) is feet. distance _{ps to p} = ((X _ps -X _p ) ² + (Y _ps -Y _p ) ² + (Z _ps -Z _p ) ² ) ^1/3 Where P represents a value from the player's aircraft and PS represents a pseudo-aircraft.
[0114]
Approach _{ps to p} Speed is the distance from one calculation cycle to another _{ps to p} Calculated by comparing the values of distance _{ps to p} Is calculated in each second, the approach speed per second for that period is the distance _{ps to p (t-1)} Previous value of-distance _{ps to p (t)} Is the current value of. For example, the previous value of f is 1400 feet, the current value is 1200, and the approach speed is 200 ft / ft.
[0115]
(Evasion vector)
The simulated aircraft is the distance to its center point in each game cycle (about once per second) _{ps to p} And approaching player aircraft _{ps to p} Monitor speed.
[0116]
distance _{ps to p} <1500 ft approaching _{ps to p} When ANDing> = 25 ft / min, the pseudo-aircraft
a. Turn off autopilot (eg stop following position report)
b. Every minute, it sends a randomized audio message for the effect of "There is an aircraft too close to me."
[0117]
c. Avoidance vector at twice the approach speed (1500 ft / min) or at the maximum allowed by aircraft performance _{ps to p} Move away from the player in the direction of.
[0118]
This algorithm addresses situations where the player begins moving the aircraft at high speed towards the pseudo-aircraft. Approach _{ps to p} <25 ft / min speed is distance _{ps to p} If ANDing> 50 Ft and ANDing the pseudo-aircraft autopilot, the pseudo-aircraft process 916 includes:
a. Turn off autopilot
b. Resume normal navigation
c. Move the simulated aircraft back to its original course
d. In one embodiment, an audio message is output for the "Someone flies with us" effect.
[0119]
This algorithm addresses situations where the player moves quickly toward the aircraft, but slows down to a reasonable approach speed.
[0120]
distance _{ps to p} If is <50 ft, the simulated aircraft process 916 includes:
a. Turn off autopilot (eg stop following position report)
b. Sends a message every 15 seconds to the effect "You are too close".
[0121]
c. Avoidance vector at twice the approach speed (1500 ft / min) or at the maximum allowed by aircraft performance _{ps to p} Move away from the player's aircraft in the direction of.
[0122]
This algorithm addresses situations in which a player flies in formation toward a simulated aircraft and then begins to move toward the simulated aircraft intentionally or by misoperation.
[0123]
If the simulated aircraft collides with any object other than the ground or the player's aircraft,
a. Simulated aircraft outputs random audio messages
b. Simulated aircraft explodes
c. The game session ends.
[0124]
distance _{ps to p} Is <10 feet (indicating that the aircraft is likely to collide)
a. The simulated aircraft outputs a random audio message for the "this is a dumb" effect
b. Simulated aircraft explodes
c. Player's aircraft also explodes
d. The game session ends.
[0125]
(D. ATC process algorithm)
The ATC process 908 has an architecture similar to the simulated aircraft process 916. The ATC process includes this module that handles execution simulation, common database and communication, and rule-based decision making.
[0126]
The execution simulation schedules the instructions of the module here. After initialization, the process execution instructions are:
1. Communication module (enter new data and commands)
2. Rule-based logic module (reacting to updated internal and external data)
3. Communication module (outputs data and commands)
4. repeat
(1. ATC common database)
The ATC common database is used to store data about controlled aircraft and data about internal targets, as well as the state of the ATC process 908. This common database is also used to provide a common communication architecture for other process modules. Changes to the database are entered and run by the module.
[0127]
(2. ATC communication module)
The basic operation of the communication module is similar to the operation used in the simulated aircraft module. The ATC communication module manages all communication between the ATC process 908 and other external processes. The ATC pass-through module uses a common database as an area to store new data and messages, or sends the data to an external process. Data input by the ATC communication module includes location reports from the simulated aircraft and player processes 912, 916, requests and responses from the simulated aircraft and player aircraft processes 912, 916. The ATC communication module outputs data to external processes based on messages commanded by other modules. Data input by the ATC communication module includes messages to the simulated aircraft process 916, the player aircraft process 112, and the audio engine 328, and data requests to the player and simulated aircraft processes 912, 916.
[0128]
(3. Logic module based on ATC rules)
Logic modules based on ATC rules control the operation of ATC process 908 in response to changes in the state of the aircraft in the world. The ATC process 908 provides a real-time real-time response to real-time traffic and weather conditions by responding to changes in aircraft flow with the day, location, and weather when the game is played. The rulesets in this module serve to simulate major airport active controls in the airspace that players may choose to reach. The ATC process 908 interacts with an aircraft that is either landing at an airport or taking off from an airport.
[0129]
(E. Control of return aircraft)
The aircraft (pseudo or player) that is to land at the airport must contact ATC process 908 and account for this intent within 50 miles of the airport. The simulated aircraft does this automatically, but the player must make this communication manually. If the aircraft makes this communication, it is added to the landing queue. The ATC process 908 manages communication with the aircraft and uses this queue to coordinate real-time traffic when the player's aircraft needs to be sequenced for landing. This landing queue comprises a FIFO (first in first out) queue of the aircraft that has contacted the ATC process for landing. The data contained in this queue for each aircraft includes the ordering instructions, the identification ID for that aircraft, the data taken under control, and the first approach point (the point at which the data is currently cleared). , The data contains the altitude initially assigned.
[0130]
This cue is used by rule-based logic to simulate control of an aircraft approaching and landing at an airport. This involves passing control and audio commands through several points in the approach issued to the aircraft. This point (location from the airport runway) and commands are issued as follows.
[0131]
[Table 1]

If the aircraft is under control, the aircraft follows the commands of the ATC rules to detect where the aircraft is and when to advance the aircraft to the next point. An example of a rule that uses this data in a queue is shown below.
[0132]
(Equation 9)

When the aircraft lands, the aircraft is removed from the return aircraft queue. As soon as data from the aircraft can be lost, the aircraft is removed by the traffic engine 900.
[0133]
(1. Retention of aircraft at initial approach point (IAP) point)
If airbound traffic is congested, there are more aircraft that want an approach and landing that can be applied. Only one aircraft is cleared at a time in the Final Approach Fix (FAF), which smoothly orders the aircraft. This ATC process 908 applies to this by requiring the aircraft to hold at the IAP before being cleared to the final approach fix.
[0134]
If the aircraft is cleared to the IAP for the first time, an altitude is provided to maintain.
This altitude is generated using a sequence instruction in a queue to determine an offset from the base code. This altitude separation prevents aircraft from colliding. For example
If the aircraft approach is the fourth aircraft in the queue, the base altitude of the IAP is 10,000 feet and the aircraft will be cleared 10,000+ (4 * 1000) = 14,000 feet to the IAP. If the sequence number is greater than 10, the total number of aircraft in the queue is less than 10 (indicating that some aircraft have been cleared) and the aircraft sequence number is reset to one. This results in the next aircraft to be cleared at 11,000 ft (10,000 + 1 * 1000 ft). The aircraft exit held as FAF is cleared and the next aircraft held in the IAP is cleared in FAF.
[0135]
(2. Return aircraft)
An aircraft departing from the airport (taking off) is added to the take-off queue if it sends a communication message to the ATC process 908 indicating that the aircraft is ready to take off. This message is generated by the airport engine 900 where the simulated aircraft should be at the airport, and its flight plan is automatically issued by the simulated aircraft if it indicates that the simulated aircraft is still within takeoff. This message is also generated by the player's aircraft if a simulated aircraft is present at the airport and wants to take off. The takeoff queue maintains as an order number, an ID number for the aircraft, and a point that is cleared for the aircraft to take off. There are three points where takeoff logic is concerned.
[0136]
[Table 2]

If the aircraft requests to take off, the aircraft is added to the takeoff queue. If it is safe for the ATC process 908 to allow the aircraft to take off (any previous aircraft has reached or moved beyond the arrival or runway order point), the aircraft is cleared to take off You. In other cases, the aircraft is asked to hold and if that point clears, it can take off. Once the aircraft reaches the order point, the ATC process 908 resumes normal navigation but does not remove the aircraft from the queue. The aircraft can then be started to match the actual route according to the report data. If the aircraft travels beyond 50 miles, the data is removed from the queue and an audible send-off message.
[0137]
(3. Holding aircraft on the ground)
With respect to landing cues, there may be situations where there are more aircraft that want to take off that can be adapted. This can often occur when a player's aircraft asks to take off if the airport is congested. In this case, if the aircraft sends a readiness for a takeoff message, the aircraft is instructed to hold. If the aircraft departs earlier in the queue, it will eventually be cleared to take off. Unfortunately, you are not limited to the number of aircraft that can have a take-off cue that reflects the real life.
[0138]
(4. Handling of uncontrolled aircraft)
The landing and take-off cues also serve a secondary purpose that allows the ATC process 908 to monitor airspace for aircraft that are not under control of the aircraft (especially the player's aircraft). If the player's aircraft is within 50 miles of the airport, does not contact the ATC process 908, and the ATC processor 908 located on the landing queue determines, the ATC process 908 will make that determination to identify itself. Respond to send audio messages to unknown aircraft by asking and asking what the intention or similar message is until the aircraft lands. The same process is used for players when the process goes to the runway and takes off without asking for the interval. The ATC process 908 detects that the aircraft is on the runway without requesting an interval for takeoff (not with respect to the takeoff queue) and detects the proper string of audio messages until the aircraft has exceeded 50 miles I do.
[0139]
(5. Use of real-time weather data)
ATC process 908 may also use real-time weather data as described above for airports that are controlling to respond to pilot requests for weather data (eg, where the wind direction is). This data also allows the ATC process 908 to select the optimal runway to instruct to land on the aircraft, generating a real rendering of the CN portion itself based on real-time conditions.
[0140]
Accordingly, systems, methods, and apparatus are described to enable the use of real-time data to influence and drive the gaming experience. Although the preferred embodiment has been described in some detail (i.e., a flight simulation application), the teachings of the present invention may be applied to other games as well (such as car and ship racing games, or other sporting events). Can be extended. Many further modifications can be made to the above-described devices without departing from the true spirit of the invention. Further, while certain functionality has been attributed to the different steps of the above-described methods and modules of the circuit software described above, these functionality may be performed in different orders and in different modules as known to those skilled in the art. Can be done.
[Brief description of the drawings]
[0141]
FIG. 1 is a block diagram of a system for incorporating real-time data according to an embodiment of the present invention.
FIG. 2 is a more detailed block diagram of a game data server according to an embodiment of the present invention.
FIG. 3 is a block diagram of a game system according to the embodiment of the present invention.
FIG. 4 is a block diagram of a weather manager according to an embodiment of the present invention.
FIG. 5 is a block diagram of weather element dependency according to an embodiment of the present invention.
FIG. 6 is a diagram of a camera path according to an embodiment of the present invention.
FIG. 7 illustrates location modification according to an embodiment of the present invention.
FIG. 8 is a diagram of a cloud object grid according to an embodiment of the present invention.
FIG. 9 is a block diagram of a traffic manager system according to an embodiment of the present invention.

Claims (33)

Receiving a location selection from the player at an identifiable time;
Inserting simulated environmental conditions for the selected location into the virtual world in response to real world information associated with the selected location from a time other than the identified time;
Generating a simulated environmental condition for a game in response to the inserted and simulated environmental conditions. The method for simulating a real world environment in a virtual world represented in a game. Receiving a location selection from a player;
Inserting simulated environmental conditions for the selected location into the virtual world in response to real world information associated with the location other than the selected location;
Generating a simulated environmental condition for the game in response to the inserted and simulated environmental condition. Receiving a location selection from the player at an identifiable time;
Responsive to the real world information associated with the selected location and the location other than the identified time, inserting a simulated environmental condition for the selected location into a virtual world;
Generating a simulated environmental condition for the game in response to the inserted and simulated environmental condition. Receiving a location selection from a player;
Determining whether real world environmental condition information is associated with the selected location;
Responsive to determining whether real-world environmental condition information is associated with the selected location, the real-world environment to generate simulated environmental conditions in the virtual world for the selected location. Applying environmental condition information. The method for simulating a real world environment in a virtual world represented in a game. Responsive to the step of determining whether real world environment condition information is not present at the selected location, analyzing the location enclosed by the selected location to determine if the enclosed location is a real world environment condition; 5. The method of claim 4, further comprising determining whether it is associated with the information. Determining the geographical location of the gaming unit controlled by the player;
Responsive to current real-world data available to the location of the gaming unit, applying the current real-world data to simulate a portion of a gaming experience;
In response to current real-world data not available for the location of the gaming unit, a current location associated with a location near the location of the gaming unit to simulate a portion of the gaming experience. Inserting real-world data based on the real-world data. 7. The method of claim 6, wherein the gaming experience is a flight simulation game, the gaming unit is an aircraft simulation, and the real world data includes weather data or traffic data. The game experience is a flight simulation game, the game unit is an aircraft simulation, the real world data includes weather data, the method includes:
7. The method of claim 6, further comprising generating a simulated weather condition for the location based on real world data regarding other weather conditions for the location. 9. The method of claim 8, wherein the simulated weather condition is a freezing condition and the generation of the freezing condition is determined based on real-world data on temperature and precipitation. The game experience is a flight simulation game, the game unit is an aircraft simulation, the real world data includes surrounding aircraft data, and the method comprises:
7. The method of claim 6, further comprising generating a representation of the real world aircraft for display as part of a gaming experience based on real world data identifying the real world aircraft. The method of claim 10, further comprising selecting to display a real-world aircraft located within a predetermined radius of the location of the aircraft simulation. Receiving from the player a location selection for a gaming unit controlled by the player at an identifiable time;
Responsive to a real-world unit associated with a location near the selected location of the gaming unit controlled by the player at the identified time, generating a representation of the gaming unit for display in the game. A method for simulating a real world environment in a virtual world represented in a game, including. The game is a flight simulation game, wherein the game unit is an aircraft, and generating a representation is associated with a location near the selected location of the aircraft controlled by the player at the identified time. The method of claim 12, comprising generating a representation of the aircraft to be displayed in the game in response to the real aircraft. 14. The method of claim 13, wherein the representation of an aircraft corresponding to the real aircraft is displayed at a location corresponding to where the real aircraft is located in the real world. 15. The method of claim 14, wherein the location of the representation is updated to account for the change in position of the real aircraft. Determining whether there is new data about the location of the real aircraft whose representation is displayed in the game;
Updating the representation location in response to the presence of new data regarding the location of the aircraft in response to the new data. 17. The method of claim 16, further comprising, in response to determining that there is no new data regarding the location of the aircraft, inserting a new location for a representation of the aircraft based on current data regarding the aircraft. The described method. 19. The method of claim 18, wherein the current data includes speed and heading information of the real aircraft. A game unit corresponding to a real world unit moves away from a game unit controlled by the player in response to the player's game unit moving within a predetermined radius of the game unit corresponding to the real world unit. 15. The method of claim 14, wherein the method is moving. 14. The method of claim 13, wherein the empty traffic controller process maintains information about a player's aircraft and the location of the real-world aircraft and alerts the player about movement of the real-world aircraft. 21. The method of claim 20, wherein the empty traffic controller sends an audio message to the player about real world movements to emulate wireless traffic experienced by a real world pilot. A system for integrating real world data into games,
A real world data manager for requesting a selected group of real world data from a comprehensive real world database for use in the game;
A database of real world data connected to a real world data manager to store a selected grouping of data related to the real world event;
Receiving a request for inserted data from the real world data data manager, retrieving selected data from the real world data database, and generating inserted game data to be used in the execution of the game; A system for integrating real world data into a game, the real world data manager and a real world data insertion engine connected to the real world data database. The game is a flight simulation game, the real world data is weather data, and the insertion engine is a weather engine for inserting weather data to be displayed during execution of the game. An apparatus according to claim 1. 23. The apparatus of claim 22, wherein the weather engine simulates weather conditions based on an analysis of other real world weather conditions. 25. The apparatus of claim 24, wherein the weather engine simulates icing conditions based on analysis of temperature and precipitation data. 26. The apparatus of claim 25, wherein the weather engine updates icing conditions in response to a player using a deicing application within the game. 23. The game is a flight simulation game, the real world data is traffic data, and the insertion engine inserts traffic data to display other aircraft during execution of the game. An apparatus according to claim 1. A computer readable medium for integrating real world data into a game, the computer readable medium comprising:
Displaying the game unit corresponding to the player's input at an identifiable time,
Causing real-world data relating to the location of the real-world unit to be retrieved at a time near the time to the identified time at which the player's input is received;
A computer readable medium for integrating real world data into a game, storing instructions for displaying a representation of a real world unit in response to the retrieved data in the game. The computer-readable medium includes a processor,
Determine whether real-world data is present in the currently displayed real-world unit during the selected time period,
Responsive to determining that real world data is not present at the selected time, causing the real world unit to be inserted at the location of the real world unit;
29. The computer readable medium of claim 28, further comprising instructions for displaying the real world unit at the inserted location. 30. The computer readout of claim 29, wherein the game is a flight simulation game, the gaming unit is an aircraft, and the instructions cause the processor to insert into a real-world aircraft location based on heading and speed information. Possible medium. A computer readable medium for integrating real world data into a game, the computer readable medium causing a processor to display a game unit corresponding to a player input at an identifiable time,
Causing real-world data relating to environmental conditions to be retrieved at a time near the time to the identified time at which the player's input is received;
A computer readable medium for integrating real world data into a game, storing instructions for displaying a representation of an in-game environmental condition in response to data retrieved within the game. Instructions for causing the processor to retrieve real world data relating to environmental conditions include:
Causing weather data relating to a location corresponding to the location of the game unit to be extracted,
The computer-readable medium of claim 31, further comprising: displaying an expression of an environmental condition based on the retrieved data. The instructions are:
Determining whether weather data is present at the location of the gaming unit;
In response to determining that no weather data is present, have surrounding locations analyzed until real-world weather data is found,
33. The computer readable medium of claim 32, wherein the computer readable medium causes an expression of environmental conditions for the location of the gaming unit in the game to be inserted from the found weather data of the real world.

Images