JPH09284357A

JPH09284357A - リアルタイム通信システム

Info

Publication number: JPH09284357A
Application number: JP8089095A
Authority: JP
Inventors: Masaki Kawahori; 昌樹川堀
Original assignee: Sega Enterprises Ltd
Current assignee: Sega Corp
Priority date: 1996-04-11
Filing date: 1996-04-11
Publication date: 1997-10-31

Abstract

(57)【要約】【課題】データ量が大きくなることによるデータの交換
速度の遅れる問題を解決したリアルタイム通信システム
を提供する。【解決手段】第一の装置と第二の装置を通信回線でつな
ぎ、該第一、第二の装置において入力データに対し、同
じ処理を行うリアルタイム通信システムにおいて、該第
一の装置と第二の装置は、互いに相手側装置からのデー
タを未受信である時、該相手側装置に対するデータの送
信を行わないことを特徴とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、リアルタイム通信
システムに関する。同一の画像または音声を表示し、入
力に応じてその表示を変化させる複数の表示装置を離隔
して配置し、それぞれの装置への入力信号を相手装置側
に通信回線を通して送るシステムに関する。

【０００２】

【従来の技術】近年、ビデオゲーム装置等の分野におい
て、複数の遊戯者がそれぞれ対応するプレーヤ（例え
ば、ビデオゲームにおける登場人物）の動きを入力パッ
ドにより入力操作して対戦する対戦型のビデオゲームが
人気となっている。

【０００３】更に、このビデオゲーム装置を遠隔地間に
配置し、通信ケーブル及びモデムを利用してそれぞれの
地からの入力信号を送受し、対戦ゲームを実行すること
が研究開発されつつある。

【０００４】かかるシステムをリアルタイム通信ゲーム
システムと呼ぶ。これまで提案されてきたかかるリアル
タイム通信ゲームシステムでは、操作入力データに基づ
き、対応するゲーム装置でプレーヤの状態（ステータ
ス）変化を演算し、その演算結果であるステータス情報
データまたは、当該ステータス情報データの変化を差分
データとしてパケット化して相手側に通信するものであ
った。

【０００５】かかる場合、ステータスの情報量がアプリ
ケーションの内容により不確定であり、通信情報量も必
然に大きいものとなる。したがって、対戦ゲームの如き
アプリケーションへの適用において、特に低速の通信回
線を通しては実現が困難である。

【０００６】即ち、データの交換速度が遅くなり、ゲー
ム内容におけるプレーヤに俊敏な動きを与えることが困
難である。特に低速な通信レートでは最低現必要なデー
タ量を必要な時間内に送ることが難しい。更に、通信途
中にエラーが生じてもプログラムの実行における回復が
困難である。

【０００７】

【発明が解決しようとする課題】したがって、本発明の
目的は、データ量が大きくなることによるデータの交換
速度の遅れる問題を解決したリアルタイム通信システム
を提供することにある。

【０００８】更に、本発明の目的は、通信途中のエラー
によりプログラムの実行が困難となることを回避できる
リアルタイム通信システムを提供することにある。

【０００９】また、本発明の目的は、ビデオゲーム装置
に適用する場合、通信回線を通して対戦ゲームを可能と
するリアルタイム通信システムを提供することにある。

【００１０】

【課題を解決するための手段】上記本発明の課題を達成
するための請求項１に記載のリアルタイム通信システム
は、第一の装置と第二の装置を通信回線でつなぎ、該第
一、第二の装置において入力データに対し、同じ処理を
行うリアルタイム通信システムにおいて、該第一の装置
と第二の装置は、互いに相手側装置からのデータを未受
信である時、該相手側装置に対するデータの送信を行わ
ないことを特徴とする。

【００１１】更に、本発明の課題を達成するための請求
項２前記受信データを１／２Ｔ＋１（但し、Ｔはタイム
スロット）の期間バッファリングすることを特徴とす
る。

【００１２】また、請求項３に記載のリアルタイム通信
システムは、請求項１に記載のリアルタイム通信システ
ムにおいて、呼びかけを行いマスタ側となった前記第一
の装置または第二の装置は、スレーブ側となった相手側
装置からのパディングデータを待って、伝送速度測定用
シグナルを送り、該相手側装置から伝送速度測定用シグ
ナルの返送がある時、該伝送速度測定用シグナルを送っ
た時間の半分の時間だけパディングデータを送り、スレ
ーブ側と同期を合わせることを特徴とする。

【００１３】また、請求項４に記載されるリアルタイム
通信システムは、請求項３において、前記スレーブ側と
なった相手側装置は、パディングデータを前記マスタ側
の前記第一の装置または第二の装置に送り、該マスタ側
からの伝送速度測定用シグナルを待ち、伝送速度測定用
シグナルを返送し、パディングデータを再び待って該マ
スタ側との同期をあわせることを特徴とする。

【００１４】更に又、請求項５に記載のリアルタイム通
信システムは、請求項１において、前記第一の装置及び
第二の装置は、同じゲームプログラムを実行するゲーム
機であり、前記入力に対し、同じ計算を行い同じ画像を
表示し、リアルタイムでゲームを行うことを特徴とす
る。

【００１５】

【発明の実施の形態】以下本発明の実施の形態を図面を
参照しながら説明する。尚、図に於いて同一または、類
似のものには同一の参照番号または参照記号を付して説
明する。

【００１６】図１は、２人の遊戯者、したがって２台の
ビデオゲーム装置間で通信回線を通して、ビデオゲーム
を実行する場合を例として、本発明にしたがうリアルタ
イム通信システムの構成例を説明する図である。

【００１７】尚、以下実施例としてビデオゲーム装置間
で通信を行う場合を例として説明するが、本発明はかか
るゲーム装置を用いたリアルタイム通信ゲームシステム
に限定されるものではない。

【００１８】図１において、１、２はそれぞれ通信回線
３を通して遠隔地に配置されるビデオゲーム機Ａ、Ｂで
ある。

【００１９】ビデオゲーム機１、２はそれぞれゲーム機
本体１０と、本発明に従う通信プロトコルの対象となる
通信装置１１を有して構成される。ゲーム機本体１０
は、既存のビデオゲーム装置本体と共通の構成を有す
る。

【００２０】かかるシステムの全体構成において、二人
の遊戯者がそれぞれビデオゲーム機１、２に付属する入
力パッド等の入力装置１２を操作してデータを入力す
る。入力されたデータは、後に説明する本発明にしたが
うプロトコルにしたがって、相手のゲーム機側に通信回
線３を通して送られる。

【００２１】そして、それぞれのゲーム機１、２におい
て、自側のゲーム機に付属する入力装置１２から入力さ
れたデータと相手側のゲーム機に付属する入力装置１２
から入力されたデータとを、あたかもそれぞれのゲーム
機に二つの入力装置１２が付属し、対戦する遊戯者から
データが入力された如くに、ゲームプログラムが実行さ
れる。

【００２２】図２は、かかる図１に例示する本発明のリ
アルタイム通信システムにおける位置づけをシステム階
層により示している。即ち、最下位層Ｌ１にゲーム機の
ハードウェアがあり、シリアルポートを通して、相手側
入力装置１２からのデータが通信回線を通して入力され
る。

【００２３】シリアルポートを通して入力されるデータ
は、レイヤＬ２のシリアルＩ／Ｏコントロールを経て、
レイヤＬ３の本発明による特徴を有する通信プロトコル
に従いレイヤＬ４のアプリケーションＩ／Ｆに送られ
る。そして、アプリケーション層である最上層Ｌ５にお
いて、ゲームプログラム等のアプリケーションで処理さ
れる。

【００２４】本発明による特徴を有する通信プロトコル
には、タイミングアジャスト、データエクスチェンジ、
エラーエンド及びノーマルエンドを有する。後にそれら
の内容を順に詳細に実施例とともに説明する。

【００２５】図３は、本発明を適用したゲーム機等の装
置の構成例である。図１のゲーム機１、２に対応させる
と、ゲーム機本体１０は、バッファ部２１とアプリケー
ション実行部３１を含んでいる。バッファ部２１は、通
信装置１１と接続される送信バッファ２１０と受信バッ
ファ２１１によりそれぞれ送信信号及び受信信号のタイ
ミングを調整する。

【００２６】また、バッファ部２１は、更にＰ1 バッフ
ァ２１２、Ｐ2 バッファ２１３を有する。Ｐ1 バッファ
２１２は、自装置に接続される入力装置１２から入力デ
ータバッファ１２０を通して入力される信号のタイミン
グを調整してアプリケーション実行部３１側に送る。Ｐ
2 バッファ２１３は、通信回線３を通して送られる相手
側装置に接続される入力装置１２から入力される信号を
入力し、そのタイミングを調整してアプリケーション実
行部３１側に送る。

【００２７】更に、バッファ部２１は、エラー情報検出
部２１４を有し、エラーを検出してアプリケーション実
行部３１側に送る。上記のような本発明を適用した装置
の構成において、通信装置１１とバッファ部２１との間
は、シリアルＩ／Ｏ（ＳＩＯ）コントロール２１６によ
りインタフェースされる。

【００２８】またバッファ部２１とアプリケーション実
行部３１との間は、アプリケーションインタフェース
（ＡＰＩ）ライブラリ２１５によりインタフェースされ
る。

【００２９】これらのＳＩＯコントロール２１６及びＡ
ＰＩライブラリ２１５は、既存のインタフェース機能が
適用可能である。更に、送信、受信バッファ２１０、２
１１とＰ1 バッファ、Ｐ2 バッファ２１２、２１３の間
が、後に説明するように本発明により特徴付けられるプ
ロトコルによりインタフェースされる（図３、２１７参
照）。

【００３０】実施例において、上記ＳＩＯコントロール
２１６は、次の機能を有する。

【００３１】送信バッファ２１０の内容を１バイトづつ
送信し、受信した１バイトを受信バッファに入れる。送
信バッファが空き（送信が完了）かどうかを知らせる。
更に受信しているか（受信済のチェック）を知らせる。

【００３２】一方、アプリケーションインタフェース
（ＡＰＩ）ライブラリ２１５は、この部分を変えること
によりワークデータの交換やベリファイ、表示の同期を
ずらし応答を速める等の処理が出来る。

【００３３】図４は、上記本発明を適用したリアルタイ
ム通信システムの動作フローであり特に、装置をビデオ
ゲーム機とし、二人の遊戯者間で対戦ゲームを実行する
例である。

【００３４】先ずゲームスタートに当たって、二人の遊
戯者の一方から相手側に通信回線３を通してゲームの呼
びかけを行う。これに対し、相手側からの応答を受信
し、両者間でデータリンクコネクションが確立される
（ステップＳ１）。

【００３５】データリンクコネクションが確立される
と、双方のゲーム機１、２において、ゲーム開始のため
に通常のイニシャル処理が行われる（ステップＳ２）。
ここで、ゲーム機１、２には、同一のゲームを行う対戦
ゲームのためのゲームプログラムがインストールされて
いることが必要である。

【００３６】したがって、それぞれの遊戯者により、自
装置においてゲームスタートを入力することにより、イ
ンストールされているゲームプログラムにしたがって、
通常のゲーム機での初期化動作と同様に、ゲーム開始の
ための初期化が可能である。

【００３７】次に本発明にしたがい、先に説明した図３
のプロトコルコントロール２１４に対応する通信プロト
コルが実行される。

【００３８】本発明にしたがう通信プロトコルは、タイ
ミングアジャストフェーズ（ステップＳ３）、データエ
クスチェンジフェーズ（ステップＳ４）、エラーエンド
フェーズ（ステップＳ５、６）及びノーマルエンドフェ
ーズ（ステップＳ７）の４つのフェーズ処理が含まれ
る。

【００３９】データエクスチェンジフェーズ（ステップ
Ｓ４）の前には必ずタイミングアジャストフェーズ（ス
テップＳ３）で同期をとることが必要である。データの
交換は、エラーエンドフェーズ（ステップＳ５）かノー
マルエンドフェーズ（ステップＳ７）の何方かにフェー
ズを切り換えてから終了する。

【００４０】フェーズチェンジは、自動的に行われ、し
たがってアプリケーション実行部３１側で切り換える必
要がない。

【００４１】図５〜図９は、本発明の基本となる通信プ
ロトコルを実行するためのタイミングチェックの方法を
説明する図である。

【００４２】送信チェックも受信チェックもゲームサイ
クル（例えば１／６０sec 毎）の先頭で行われる。した
がって重要であるのは、ゲームサイクルの先頭でデータ
の受信が完了しているか否かである。

【００４３】図５は、本発明の説明において、このタイ
ミングの検証を行う方法を説明する図である。図におい
て縦の列は、サイクルを表す。また数字は、フレーム
（画面）番号を表している。

【００４４】サイクル表示において、ＴX は自側装置に
おいて入力されたデータを送信するタイミングであり、
ＲX は相手側装置に入力されたデータを必要な時に受信
完了していることを示す。Ｄisp はフレームの処理が完
了し、表示可能の状態を表している。

【００４５】また図８、図９に表示されるｒx は、実際
に相手のデータを受信するタイミングを表している。

【００４６】上記図５の表示の意味にしたがって、先ず
自側装置と相手側装置に於けるクロックが異なる場合に
ついて検討する。図において、Ａはゲーム機１側、Ｂは
ゲーム機２側である。今、ゲーム機２側のクロック周波
数が、ゲーム機１側のクロック周波数の半分である場合
を考える。

【００４７】この場合、クロック周波数の大きいゲーム
機１側でゲーム機２側からのデータの受信を待つことで
タイミングを合わせるようにしている。今、ゲーム機１
側からデータ２を送信するタイミングを見ると、ゲーム
機２側からのデータ１の受信が行われていない状態であ
る（ｘで表示）。この場合、ゲーム機１側からは、次の
データ３の送出が行われない（ｘで表示）。

【００４８】ついで、ゲーム機２側からのデータ１の受
信が完了した時点で、ゲーム機１側から次のデータ３が
ゲーム機２側に送信が行われる。以下同様にしてゲーム
機１側とゲーム機２側のデータの送信が行われる。

【００４９】ここで、上記のように、相手側からのデー
タが未受信の時は、新たな送信が行われない。かかる
「未受信の時、送信を行わない」ようにすることが、本
発明の基本プロトコルである。

【００５０】かかる本発明の基本プロトコルに基づき、
更にフレームアウトした時の処理を図７により説明す
る。即ち、図７において、ゲーム機１側から送信すべき
データ５のタイミングＦＯでフレームアウトを生じてい
る。したがって、ゲーム機２側は、データ５の受信が出
来ず、本発明の基本プロトコルにしたがいゲーム機２側
からはデータ７の送信が行われない。同時に、画面処理
のサイクルも遅れる。

【００５１】次にゲームを中断する場合、ポーズ指示を
与えてレジューム状態とすることがある。図８は、かか
るポーズをかけた場合の通信について説明する図であ
る。

【００５２】図８において、ゲーム機１側から送信すべ
きデータ４のタイミングＰＰでポーズ指示を行い、した
がってデータ４の送出は行われず、データ４をゲーム機
２側で受信出来ない。これに対し、ゲーム機２側は「デ
ータが未受信の時、送信を行わないようにする」という
本発明の基本プロトコルにしたがって、ゲーム機１側か
らポーズ指示がある間データの送信を行わない。

【００５３】ゲーム機１側からポーズを解除して再びデ
ータ４の送信を開始すると、ゲーム機２側でこれを受信
してデータの送信を再開する。

【００５４】したがって、この図８におけるポーズ処理
では、送信しないといういことが相手側にポーズをかけ
ていることを通知していることを意味している。

【００５５】上記における「データが未受信の時、送信
を行わないようにする」という本発明の基本プロトコル
は、図３のプロトコルコントロール２１７によって、受
信バッファ２１１を監視し、入力データバッファ１２０
のデータの送信バッファ２１０への転送を制御すること
により行われる。

【００５６】ここで、受信データのバッファリングにつ
いて説明する。受信データをバッファリングなしで表示
処理を行う場合、１サイクル内のタイミングのずれの影
響で受信が間に合わず交互に振動が起きる現象に発展す
る可能性がある。

【００５７】図９（１）は、かかる現象を説明するため
の図であり、バッファリングなしの場合である。今ゲー
ム機１側からのタイミングＰで何らかの原因によりデー
タ３の送信が行われない場合、では先のフレームのデー
タ２を受信するので、データ３の送信が行われる。しか
し、次のフレームで受信データ２の表示が行われるが、
ゲーム機１側からデータの送信行われていないので、ゲ
ーム機２側からの送信は、行われない。

【００５８】一方、ゲーム機１側では、ゲーム機２側か
らのデータ３を受信するので、データ２の送信を行う。
この時、先のフレームでゲーム機２側からのデータを受
信していないので表示は、行われない。

【００５９】このようにゲーム機１側、ゲーム機２側で
交互にデータの送信、未送信状態を繰り返し、対応して
表示、非表示が交互に繰り返される発振状態となる。

【００６０】一方、図９（２）は、受信データをバッフ
ァリングして表示する場合である。このバッファリング
は、プロトコルコントロール２１４により受信バッファ
２１１に所定期間受信データを保留するように制御する
ことにより行われる。

【００６１】図９（２）に示すように、ｒx は、物理的
にデータが到来した時点であり、Ｒｘとｒx の差がバッ
ファリング時間となる。図９（２）の例は、１／２Ｔ＋
１の期間中、受信データを待つようにしている。

【００６２】したがって、何らかの原因で１バイト遅れ
ても（図中Ｐ点）、更に１バイト以上の遅れが生じる前
に復帰すれば、振動は起こらない。２バイトの遅れが生
じた時は、ウェイト状態とするが、相手側のバッファに
吸収されて振動は生じない。

【００６３】ここで、本発明は更に同期ずれを１垂直同
期期間（Ｖ−sync)内に収めるために、データ交換の開
始タイミングを測定するようにしている。データを送信
し、回線上を伝わって相手装置で処理され、再び回線上
を伝わって帰って来たデータを受信する時間（Ｖ−sync
単位）を測定する。

【００６４】マスタ側（先にゲームの実行を呼びかけた
ゲーム機側）は、スレーブ側にデータ転送の合図を送っ
た後、計測時間の半分の時間を待ってデータを送出す
る。

【００６５】かかる手順を図１０の例に基づき説明す
る。図において、ゲーム機１がマスタ側、ゲーム機２が
スレーブ側であると想定する。マスタ側のゲーム機１
は、ゲーム開始の準備が出来た時、パディングデータ
（ＰＡＤ）が送られるのを待つ。

【００６６】スレーブ側のゲーム機２からのＰＡＤの受
信が始まると、マスタ側は伝送速度測定用信号ＳＩＧＮ
１のスレーブ側への送信を開始し、スレーブ側からの応
答として伝送速度測定用信号ＳＩＧＮ２が返送されるの
を待つ。

【００６７】伝送速度測定用信号ＳＩＧＮ２が受信され
た時、先に送った伝送速度測定用信号ＳＩＧＮ１の送信
時間（Ｔインタラプト）の半分の時間１／２ＴだけＰＡ
Ｄを送る。ついで区切りＭＡＲＫを送り、データ交換の
手順を開始する。

【００６８】一方、スレーブ側においては、準備が出来
たら時点で、ＰＡＤを送信し、マスタ側からの伝送速度
測定用信号ＳＩＧＮ１が送られるのを待つ。ＳＩＧＮ１
を受信したら、ＳＩＧＮ２を送り、ＰＡＤが送られるの
を待つ。

【００６９】マスタ側から，ＰＡＤが送られると、区切
りＭＡＲＫをスレーブ側に送り、データ交換を開始す
る。

【００７０】上記のようにして、データ交換の開始タイ
ミングの同期が取られる。尚、上記伝送速度測定用信号
ＳＩＧＮ１、２、区切りＭＡＲＫ及びＰＡＤは、１バイ
トのデータであり、具体的数値は、システム、バージョ
ン、オープション等により異なり、実施例として次のよ
うに定義される。

【００７１】ＰＡＤの値は、システム番号を表し、ゲー
ム機間で異なる場合は通信が出来ない。例えば、ＰＡＤ
番号として＄００である。伝送速度測定用信号ＳＩＧＮ
の値は、バージョン、オープションを表し、通信プロト
コルを制御する。例えば、ＳＩＧＮの各ビットは、次の
ように表される。

【００７２】ＳＩＧＮビット７１：ＰＡＤと区別するための１と定義される）ビット６−４０００：バージョン）ビット３０：未使用ビット２０：ハミング符号なし１：ありビット１０：チェックサムなし１：ありビット００：ＣＲＣなし１：ありタイミングアジャスト処理により同期が取られ、データ
エクスチェンジ（データ交換）が開始する。

【００７３】伝送されるデータは、８ビットのデータと
４ビットの冗長チェック（ＲＣ：Redundancy Check) ビ
ットの計１２ビットで１個のデータとして、８個のデー
タと１６ビットのブロック検査文字（ＢＣＣ：Block Ch
eck Character)で１ブロックとする。

【００７４】送信順序は、図１１に示されるごとくであ
る。

【００７５】冗長チェック（ＲＣ）ビット及びブロック
検査文字（ＢＣＣ）は、それぞれハミング符号及びチェ
ックサムを用いることが出来るが、オプションでこれら
を省略することも出来る。

【００７６】各ブロックの二つの連続する領域は、１Ｖ
−syncで送信することが出来る２バイトのデータを表
す。ただし１２００bpsの場合、２バイトの送信には約
１８ｍｓｅｃかかるので、少しずつ遅れ、送信が間に合
わなくなるが、２バイト分の空欄で調整ができるので８
Ｖ−syncで１４バイトを送信することが出来る。

【００７７】上記ＲＣビットは、ハミング符号によるチ
ェックビットであり、ＲＣ００の下位ニブルはＤＡＴＡ
００、上位ニブルはＤＡＴＡ０１のＲＣビット（８−１
１）となる。

【００７８】ＢＬＯＣＫ＃１のＢＣＣ００とＢＣＣ０１
は、ＢＬＯＣＫ＃０の８個のデータ（１２バイト）に対
するものである。

【００７９】ＲＣビットとＤＡＴＡをチェックして、１
ビット誤りがあれば自動的に訂正される。したがって、
アプリケーション実行部３１側ではデータの誤りをチェ
ックする必要はない。

【００８０】２ビット以上の誤りは、リアルタイムには
検出出来ないが、ＢＣＣによって検出出来る。ＢＣＣに
よる誤りの検出時には、どのブロックに誤りがあったか
をアプリケーション実行部３１側に知らせ、エラー終了
となる。この後の処理はアプリケーション実行部３１で
行われる。

【００８１】尚、上記図１１において、各ブロックの番
号は送信されない。これは、装置１、２において、お互
いにブロック数をカウントすることにより容易にブロッ
クの数を認識することが出来るからである。

【００８２】上記の如くしてデータ交換が行われる（ス
テップＳ４：図４）ここで、トランスペアレント（透過）なデータ転送を行
うために脱出記号（ＤＬＥ：Data Link Escape) を用意
する。制御記号は、図１２に示すうように、ＤＬＥをつ
けて２バイトデータとして表す。

【００８３】データとしてＤＬＥを送る時は、図１２
（１）に示すように、ＤＬＥ・ＤＬＥとして２バイトで
送る。

【００８４】エラー検出コードフォーマット（エラー確
認コードも同じ）は図１２（２）に示すようにＤＬＥと
ＢＬＯＣＫ＃の２バイトで送る。

【００８５】更に、エンドコードフォーマット（エンド
確認コードも同じ）は、図１２（３）に示す如くであ
り、＄００の数は、ＥＮＤの位置によって異なる。

【００８６】次に輸送エラーが発見されると（ステップ
Ｓ５：ｙｅｓ）、エラーエンド処理フェーズになり（ス
テップＳ６）、上記図１２（２）のエラー検出コードを
送信して、相手側からのエラー確認コードが受信される
のを待つ。

【００８７】エラー検出コードとエラー確認コードは、
上記の通り同じフォーマットとすることにより、相手側
と同時にエラーが発見された場合にも対応している。つ
いでアプリケーション実行部３１から終了を指示される
と、ノーマルエンドモード（ステップＳ７）になる。

【００８８】ノーマルエンドモード（ステップＳ７）で
は、エンドコードを送信してエンド確認コードが受信さ
れるのを待つ。エンド確認コードを受信すると正常に終
了する。上記のようにエンド確認コードを受信する前に
エラーを発見するとエラーエンドモードになる（ステッ
プＳ５）。

【００８９】ここで、エンドコードとエンド確認コード
は図１２（３）に示すように、同じフォーマットにする
ことで、相手側も同時に終了された場合に対応してい
る。

【００９０】正常終了されていない間はゲームのメイン
処理が行われて（ステップＳ８）、データエクスチェン
ジ（ステップＳ４）が継続する。正常終了の場合は、ゲ
ーム終了処理が行われ（ステップＳ９）、１ステージを
終了する（ステップＳ１０）。全ステージが終了されな
ければ、再びゲームイニシャル処理が行われる。

【００９１】上記の本発明にしたがうリアルタイム通信
システムにおいて、更に双方のゲーム機において行われ
るゲームが異なる場合は、データの送受信が出来ないよ
うにキーワードを導入する。

【００９２】キーワードは、タイミングアジャスト（図
１０、図１１参照）の直後の８バイトデータを指す。ゲ
ーム名等を必ず送信することとし、これを必ずチェック
する。始めの４バイトが一致していない時、送受信が出
来ないようにする。後の４バイトはバージョンの違いを
表する。

【００９３】一方、アプリケーション実行部３１におい
て、上記誤り情報をブロック番号を付してエラー情報検
出部２１３から通知される場合、タイミングアジャスト
処理（ステップＳ３）をやり直し、誤りのあったブロッ
クから再開する（ステップＳ６）。

【００９４】

【発明の効果】以上実施例にしたがって、説明したよう
に本発明によって、次のような効果を有する。

【００９５】遠隔地のゲーム機で全く同じ計算を行わせ
ることを実現するために、入力データを交換することで
最小の通信量で対戦ゲームを可能とする。

【００９６】通信回線の物理的な遅延を計測し、タイミ
ングを計ることでリアルタイムのデータ交換を可能に
し、対戦ゲームを可能にする。

【００９７】また、これにより最小限のバッファ量を自
動的に算出できるために最小の遅延でデータ交換される
ので対戦ゲームを可能とする。

【００９８】エーラー訂正、検出機構を導入すること
で、遠隔地でのゲーム機で同じ計算をし、対戦ゲームの
結果が同じであることの保証を得ることができる。した
がって、商用利用が可能になる。

【００９９】更に、上記実施例では、ゲーム機における
対戦ゲームを例として説明したが、本発明はこれに限定
されるものではない。応用として遠隔地でのコンピュー
タを結び、同じ画面を見ながらコミュニケーションでき
る技術にも適用可能である。

【図面の簡単な説明】

【図１】本発明の適用例を説明する図である。

【図２】本発明の位置づけを説明する図である。

【図３】本発明の適用装置の構成例を示す図である。

【図４】本発明の動作フローである。

【図５】本発明のタイミングチェックの方法説明図であ
る。

【図６】クロックが異なる場合の一例を説明する図であ
る。

【図７】フレームアウトした場合の一例を説明する図で
ある。

【図８】ポーズをかけた場合の一例を説明する図であ
る。

【図９】バッファリングの効果を説明する図である。

【図１０】タイミングアジャストの説明図である。

【図１１】ブロックの構成例を説明する図である。

【図１２】脱出記号の説明図である。

【符号の説明】

１、２ゲーム機３通信回線１０ゲーム機本体１１通信装置１２入力装置３１アプリケーション実行部２１０、２１１、２１２、２１３バッファ部２１４エラー情報検出部２１５ＡＰＩライブラリインタフェース２１６ＳＩＯコントロールインタフェース

Claims

【特許請求の範囲】

【請求項１】第一の装置と第二の装置を通信回線でつな
ぎ、該第一、第二の装置において入力データに対し、同
じ処理を行うリアルタイム通信システムにおいて、該第一の装置と第二の装置は、互いに相手側装置からの
データを未受信である時、該相手側装置に対するデータ
の送信を行わないことを特徴とするリアルタイム通信シ
ステム。
【請求項２】請求項１において、前記受信データを１／２Ｔ＋１（但し、Ｔはタイムスロ
ット）の期間バッファリングすることを特徴とするリア
ルタイム通信システム。
【請求項３】請求項１において、呼びかけを行いマスタ側となった前記第一の装置または
第二の装置は、スレーブ側となった相手側装置からのパ
ディングデータを待って、伝送速度測定用シグナルを送
り、該相手側装置から伝送速度測定用シグナルの返送が
ある時、該伝送速度測定用シグナルを送った時間の半分
の時間だけパディングデータを送り、スレーブ側と同期
を合わせることを特徴とするリアルタイム通信システ
ム。
【請求項４】請求項３において、前記スレーブ側となった相手側装置は、パディングデー
タを前記マスタ側の前記第一の装置または第二の装置に
送り、該マスタ側からの伝送速度測定用シグナルを待
ち、伝送速度測定用シグナルを返送し、パディングデー
タを再び待って該マスタ側との同期をあわせることを特
徴とするリアルタイム通信システム。
【請求項５】請求項１において、前記第一の装置及び第二の装置は、同じゲームプログラ
ムを実行するゲーム機であり、前記入力に対し、同じ計
算を行い同じ画像を表示し、リアルタイムでゲームを行
うことを特徴とするリアルタイム通信システム。