JP4754243B2 - プログラム、情報記憶媒体及びゲーム装置 - Google Patents

Description

本発明は、クライアント機であるコンピュータに、他のクライアント機との間で行うネットワークゲームを進行させるためのプログラム等に関する。

複数の独立したゲーム装置が互いにデータ授受可能に接続され、マルチプレーヤゲームが行えるように形成されたゲームシステムが知られているが、このようなゲームシステムの技術の一つとして、各ゲーム装置での表示体の動きが不揃いになることを防止するために同期表示制御を行うものがある。具体的には、各ゲーム装置において、自装置のカウント信号と受信した他のゲーム装置のカウント信号とに基づいて、受信した他のゲーム装置からの受信データを自装置の同期に合わせたデータに補正し、補正後のデータに基づいてゲーム画面を生成している（例えば、特許文献１参照）。
特許第２８０７６２５号公報

しかしながら、特許文献１の技術をネットワークゲームシステムに適用する場合、次のような問題が生じる。即ち、特許文献１は業務用ゲームシステムへの適用を前提としているため、各ゲーム装置の処理能力は等しく、また、全体として略一体の筐体で成るため、各ゲーム装置はシステム内に設けられた専用線であるデータ伝送ラインによって接続されている。一方、ネットワークゲームシステムでは、ゲーム装置として各家庭に設置されているパソコンや家庭用ゲーム装置等を用い、インターネット等の通信ネットワークを介して各ゲーム装置が接続される。この場合、各ゲーム装置での処理能力の違いや、ゲーム装置間を接続する通信ネットワークによる通信ラグ等により、各ゲーム装置において他のゲーム装置からのデータの受信遅れや受信漏れが頻繁に発生し得る。その結果、ゲーム進行が一時停止したりして、プレーヤに違和感・不満感を与えるゲーム画面となってしまう。

上記事情に鑑み、本発明は、ネットワークゲームを実行するゲームシステムにおいて、各ゲーム装置の処理能力の違いやゲーム装置間の通信ネットワークによる通信ラグ等によりゲーム画面が一時停止するといった違和感・不満感を抑制したゲーム進行制御を実現することを目的としている。

上記課題を解決するための第１の発明は、
クライアント機であるコンピュータに、各クライアント機から送信されてくるクライアント機別の入力コマンドをそれぞれのクライアント機に配信するホスト機と通信させ、自機に操作入力された入力コマンドを前記ホスト機に送信させるとともに、前記ホスト機から配信されてきた自機の入力コマンドを含む全クライアント機の入力コマンドに基づき、可変のフレーム時間間隔でフレーム画像を表示制御させていくことで、他のクライアント機との間で行うネットワークゲームの進行を制御させるためのプログラム（例えば、図１７のゲームプログラム４１０）であって、
前記ホスト機から配信されてくる入力コマンドの受信タイミングと、当該受信した入力コマンドに基づくフレーム画像の表示制御のタイミングとに基づいて、前記フレーム時間の長さを調整するフレーム時間調整手段（例えば、図１７のフレーム時間補正部２３２；図２４のステップＣ７）、
として前記コンピュータを機能させるためのプログラムである。

また、第１２の発明は、
各クライアント機から送信されてくるクライアント機別の入力コマンドをそれぞれのクライアント機に配信するホスト機と通信させ、自機に操作入力された入力コマンドを前記ホスト機に送信させるとともに、前記ホスト機から配信されてきた自機の入力コマンドを含む全クライアント機の入力コマンドに基づき、可変のフレーム時間間隔でフレーム画像を表示制御させていくことで、他のクライアント機との間で行うネットワークゲームの進行を制御させるクライアント機であるゲーム装置（例えば、図１，１７のゲーム端末１０）であって、
前記ホスト機から配信されてくる入力コマンドの受信タイミングと、当該受信した入力コマンドに基づくフレーム画像の表示制御のタイミングとに基づいて、前記フレーム時間の長さを調整するフレーム時間調整手段（例えば、図１７のフレーム時間補正部２３２；図２４のステップＣ７）、
を備えたゲーム装置である。

この第１又は第１２の発明によれば、他のクライアント機との間でネットワークゲームを行うクライアント機において、ホスト機から配信されてくる入力コマンドの受信タイミングと、この受信した入力コマンドに基づくフレーム画像の表示制御のタイミングとに基づいて、フレーム時間の長さが調整される。従って、例えば入力コマンドの受信タイミングが遅れ、これに伴ってフレーム画像の表示制御のタイミングが遅れたといった場合に、フレーム時間を長くしてフレーム画像の表示更新速度を遅くすることで、以降のフレーム画像の表示制御のタイミング遅れを抑制し、ゲーム画面の表示が一時停止するといった不都合を防止できる。尚、各クライアント機からホスト機に送信された入力コマンドはホスト機からそれぞれのクライアント機に配信されるので、各クライアント機において、フレーム画像の表示更新速度や表示更新時刻は異なるけれども、同一のフレーム画像が生成・表示される。

また、第２の発明として、第１の発明のプログラムを、
前記フレーム時間調整手段が、予め設定された連続するｎ枚（ｎは１以上の整数）のフレーム画像を生成して表示制御する期間であるサイクル期間毎に、当該サイクル期間以降の少なくとも１サイクル期間におけるフレーム時間の長さを調整する、
ように前記コンピュータを機能させるためのプログラムとしても良い。

この第２の発明によれば、サイクル期間毎に、このサイクル期間以降の少なくとも１サイクル期間におけるフレーム時間の長さが調整される。即ち、フレーム時間の長さの調整は、サイクル期間を単位として行われる。

また、第３の発明として、第１又は第２の発明のプログラムを、
予め設定された連続するｎ枚（ｎは１以上の整数）のフレーム画像を生成して表示制御する期間であるサイクル期間毎に、該サイクル期間の区切りを示す同期データを前記ホスト機に送信する同期データ送信手段（例えば、図１７のクライアント部２３０；図２４のステップＣ２９）として前記コンピュータを機能させるためのプログラムであって、
前記ホスト機は、各クライアント機から送信されてくるクライアント機別の同期データをそれぞれのクライアント機に配信し、
前記ホスト機から配信されてくるクライアント機別の同期データの受信タイミングに基づいて、前記ホスト機から配信されてきたクライアント機別の入力コマンドが当該クライアント機で操作入力されたサイクル期間を判断する入力サイクル期間判断手段（例えば、図１７のクライアント部２３０；図２４のステップＣ１５）、
前記入力サイクル期間判断手段により判断された同一のサイクル期間内での全クライアント機の入力コマンドに基づいて、当該サイクル期間の各フレーム画像の表示制御を行うフレーム画像表示制御手段（例えば、図１７のクライアント部２３０；図２４のステップＣ１９）、
として前記コンピュータを機能させるためのプログラムとしても良い。

この第３の発明によれば、サイクル期間毎に同期データがホスト機に送信されるとともに、ホスト機から配信されてくるクライアント機別の同期データの受信タイミングに基づいて、受信した入力コマンドが操作入力されたサイクル期間が判断され、同一のサイクル期間内での全クライアント機の入力コマンドに基づいて、このサイクル期間内でのフレーム画像の表示制御が行われる。

また、第４の発明として、第１〜第３の何れかの発明のプログラムを、
前記ホスト機からの入力コマンドの配信待ちによるフレーム画像の表示制御の一時停止状態である待ち状態の発生を検出する待ち状態検出手段（例えば、図１７のクライアント部２３０；図２４のステップＣ２５：ＮＯ〜Ｃ２７）、
として前記コンピュータを機能させ、
前記フレーム時間調整手段が、前記待ち状態検出手段による検出に応じて、前記フレーム時間を長くさせるフレーム時間長期化手段（例えば、図１７のフレーム時間補正部２３２；図２６のステップＥ３）を有する、
ように前記コンピュータを機能させるためのプログラムとしても良い。

この第４の発明によれば、入力コマンドの受信待ちによるフレーム画像の表示制御の一時停止状態である待ち状態の発生が検出され、この検出に応じてフレーム時間の長さが長くされる。従って、待ち状態の発生の検出に応じてフレーム時間が長くされることで、以降に発生する待ち状態の継続時間（待ち時間）が短くなり、待ち状態の発生が抑制されてゲーム画面の表示が一時停止するといった不都合を抑制できる。またこのとき、例えば検出された待ち時間が長い程、フレーム時間をより長くすることで、発生する待ち状態を効率良く抑制することが可能となる。

また、第５の発明として、第４の発明のプログラムを、
前記待ち状態検出手段が、前記待ち状態の継続時間である待ち時間を検出する待ち時間検出手段（例えば、図１７のクライアント部２３０；図２４のステップＣ２５：ＮＯ〜Ｃ２７）を有し、
前記フレーム時間長期化手段が、前記待ち時間検手段により検出された待ち時間を基に、前記フレーム時間を長くさせる程度を決定する、
ように前記コンピュータを機能させるためのプログラムとしても良い。

この第５の発明によれば、待ち時間が検出され、この検出された待ち時間に基づいた程度でフレーム時間が長くされる。

また、第６の発明として、第４又は第５の発明のプログラムを、
前記フレーム時間長期化手段が、前記フレーム時間を漸次長くさせるように前記コンピュータを機能させるためのプログラムとしても良い。

この第６の発明によれば、フレーム時間が漸次長くされる。従って、フレーム時間を徐々に長くさせることで、フレーム画像の表示更新速度が急激に変化してプレーヤに違和感を与えるゲーム画面となってしまうことを防止できる。

また、第７の発明として、第１〜第６の何れかの発明のプログラムを、
前記ホスト機からの入力コマンドの配信待ちによるフレーム画像の表示制御の一時停止状態である待ち状態の発生を検出する待ち状態検出手段（例えば、図１７のクライアント部２３０；図２４のステップＣ２５：ＮＯ〜Ｃ２７）、
前記待ち状態検出手段により検出された待ち状態の発生状況を待ち状況情報として前記ホスト機に送信する待ち状況送信手段（例えば、図１７のクライアント部２３０；図２４のステップＣ２９）、
として前記コンピュータを機能させ、
前記ホスト機は、各クライアント機から受信したクライアント機別の待ち状況情報をそれぞれのクライアント機に配信し、
前記フレーム時間調整手段が、前記ホスト機から配信されてきた待ち状況情報に基づいて、前記フレーム時間を短くさせるフレーム時間短縮化手段（例えば、図１７のフレーム時間補正部２３２；図２６のステップＥ５〜Ｅ９）を有する、
ように前記コンピュータを機能させるためのプログラムとしても良い。

この第７の発明によれば、待ち状態の発生が検出され、この検出された待ち状態の発生状況が待ち状況情報としてホスト機に送信されるとともに、ホスト機から配信されてきたクライアント機別の待ち状況情報に基づいた程度でフレーム時間が短くされる。これにより、長くされたフレーム時間を、例えばクライアント機に応じて予め設定されている標準のフレーム時間に戻すことが可能となる。またこのとき、待ち状況情報に基づいてフレーム時間が短くされるので、例えば自機のフレーム時間が長くなったことで他機に待ち状態が発生しているといった場合に、フレーム時間をより短くすることにより、他機に発生している待ち状態を抑制させつつ、自機のフレーム時間を短くさせるといったことが可能となる。

また、第８の発明として、第７の発明のプログラムを、
予め設定された連続するｎ枚（ｎは１以上の整数）のフレーム画像を生成して表示制御する期間であるサイクル期間毎に、前記待ち状態検出手段が待ち状態の発生を検出し、前記待ち状況送信手段が待ち状況情報を前記ホスト機に送信する、
ように前記コンピュータを機能させるためのプログラムとしても良い。

この第８の発明によれば、サイクル期間毎に、待ち状態の発生が検出され、この待ち状態の待ち状況情報がホスト機に送信される。

また、第９の発明として、第７又は第８の発明のプログラムを、
前記待ち状態検出手段が、発生した待ち状態の継続時間である待ち時間を検出する待ち時間検出手段（例えば、図１７のクライアント部２３０；図２４のステップＣ２５：ＮＯ〜Ｃ２７）を有し、
前記待ち状況送信手段が、前記待ち時間検出手段により検出された待ち時間を待ち状況情報に含めて送信し、
前記フレーム時間短縮化手段が、前記ホスト機から配信されてきたクライアント機別の待ち状況情報に含まれる待ち時間の内、最大の待ち時間と自機の待ち時間との差分を基に、前記フレーム時間を短くさせる程度を決定する、
ように前記コンピュータを機能させるためのプログラムとしても良い。

この第９の発明によれば、待ち時間が検出され、この検出された待ち時間が待ち状況情報に含めてホスト機に送信されるとともに、ホスト機から配信されてきたクライアント機別の待ち時間の内、最大の待ち時間と自機の待ち時間との差分に基づいた程度でフレーム時間が短くされる。従って、例えば待ち時間の差分が大きい程、フレーム時間を短くする程度を大きくすることで、より効率良く、他機に発生している待ち状態を抑制させることが可能となる。

また、第１０の発明として、第７〜第９の何れかの発明のプログラムを、
前記フレーム時間短縮手段が、前記フレーム時間を漸次短くさせるように前記コンピュータを機能させるためのプログラムとしても良い。

この第１０の発明によれば、フレーム時間が漸次短くされる。従って、フレーム時間を徐々に短くさせることで、フレーム画像の表示更新速度が急激に変化してプレーヤに違和感を与えるゲーム画面となってしまうことを防止できる。

また、第１１の発明は、第１〜第１０の何れかの発明のプログラムを記憶したコンピュータ読み取り可能な情報記憶媒体（例えば、図１７の記憶部４００）である。

ここでいう「情報記憶媒体」とは、記憶されている情報をコンピュータが読み取り可能な、例えばハードディスクやＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、メモリカード、ＩＣメモリ等の記憶媒体である。従って、この第１１の発明によれば、該情報記憶媒体に記憶されている情報をコンピュータに読み取らせて演算処理を実行させることで、第１〜第１０の何れかの発明と同様の効果を奏することができる。

本発明によれば、他のクライアント機との間でネットワークゲームを行うクライアント機において、ホスト機から配信されてくる入力コマンドの受信タイミングと、この受信した入力コマンドに基づくフレーム画像の表示制御のタイミングとに基づいて、フレーム時間の長さが調整される。従って、例えば入力コマンドの受信タイミングが遅れ、これに伴ってフレーム画像の表示制御のタイミングが遅れたといった場合に、フレーム時間を長くしてフレーム画像の表示更新速度を遅くすることで、以降のフレーム画像の表示制御のタイミング遅れを抑制し、ゲーム画面の表示が一時停止するといった不都合を防止できる。

また、入力コマンドの受信待ちによるフレーム画像の表示制御の一時停止状態である待ち状態の発生が検出され、この検出に応じてフレーム時間の長さが長くされる。従って、待ち状態の発生の検出に応じてフレーム時間が長くされることで、以降に発生する待ち状態の継続時間（待ち時間）が短くなり、待ち状態の発生が抑制されてゲーム画面の表示が一時停止するといった不都合を抑制できる。またこのとき、例えば検出された待ち時間が長い程、フレーム時間をより長くすることで、発生する待ち状態を効率良く抑制することが可能となる。

更に、待ち状態の発生が検出され、この検出された待ち状態の発生状況が待ち状況情報としてホスト機に送信されるとともに、ホスト機から配信されてきたクライアント機別の待ち状況情報に基づいた程度でフレーム時間が短くされる。これにより、長くされたフレーム時間を、例えばクライアント機に応じて予め設定されている標準のフレーム時間に戻すことが可能となる。またこのとき、待ち状況情報に基づいてフレーム時間が短くされるので、例えば自機のフレーム時間が長くなったことで他機に待ち状態が発生しているといった場合に、フレーム時間をより短くすることにより、他機に発生している待ち状態を抑制させつつ、自機のフレーム時間を短くさせるといったことが可能となる。

以下、図面を参照して本発明に好適な実施形態を説明する。尚、以下では、複数のゲーム端末が通信ネットワークを介して接続されたネットワークゲームシステムで、いわゆるリアルタイムストラテジーゲームを実行する場合を説明するが、本発明の適用可能な実施形態がこれに限定されるものではない。

［ゲームシステム］
図１は、本実施形態におけるネットワークゲームを実現するゲームシステム１の構成例を示す図である。同図によれば、ゲームシステム１は、複数のゲーム端末１０とロビーサーバ６０とを備え、各装置が通信ネットワークＮに接続されている。

ゲーム端末１０は、プレーヤが操作してゲームを楽しむものであり、プレーヤの操作入力を受け付ける入力装置やゲーム演算等を行う演算処理装置、ゲーム画面等を表示する表示装置、通信ネットワークＮに接続するための通信装置等を有している。このゲーム端末１０は、例えば家庭に設置されているパソコンや家庭用ゲーム装置等で実現される。

ロビーサーバ６０は、ゲームに参加するプレーヤの決定や各プレーヤのゲーム端末１０間の接続管理といったマッチング処理を行うものであり、演算処理装置や通信ネットワークＮに接続するための通信装置等を有している。このロビーサーバ６０は、例えば汎用サーバ装置やサーバシステムによって実現される。

通信ネットワークＮは、データ授受が可能な通信路である。即ち、通信ネットワークＮは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網により実現される。また、通信方法については有線／無線を問わない。但し、通信ネットワークＮは、ゲームシステム１を構築するためだけの専用線で成るものではなく、ゲームシステム１で用いるデータ以外のデータも伝送され得る。例えば、インターネットがその代表例であるが、ＬＡＮ等であっても良い。即ち、通信ネットワークＮは、ゲームシステム１以外の要因により通信トラフィックが変化し得るネットワークである。

そして、このようなゲームシステム１において複数プレーヤが参加するマルチプレイが行われる場合、先ず、ゲーム端末１０がロビーサーバ６０にログインし、ロビーサーバ６０のマッチング処理によってゲームに参加するプレーヤが決定され、各プレーヤのゲーム端末１０間の接続が確保された後、ゲームが開始される。ゲーム中は、参加する各プレーヤのゲーム端末１０同士が直接接続してゲームが実行される。

［ゲーム概要］
本実施形態において、ゲームシステム１では、宇宙を舞台としたリアルタイムストラテジーゲームが実行される。プレーヤは国家指導者となり、ゲーム開始時点に所有している母星（惑星のひとつ）を拠点として艦船を生産し、他の惑星を占領し、他のプレーヤと交戦して宇宙の覇権を争うゲームを楽しむ。

図２は、本実施形態のゲーム概要図であり、ゲームマップの一例を示している。同図（ａ）に示すように、宇宙空間を模したゲームマップには、各プレーヤの母星を含む多数の惑星ＰＬや、各プレーヤが所有する艦船ＳＨ等が配置されている。具体的には、同図（ａ）は、２人のプレーヤＡ，Ｂが参加している場合を示しており、惑星ＰＬには、プレーヤＡが所有する惑星ＰＬａ（図中、濃く網掛け表示されている）、及び、プレーヤＢが所有する惑星ＰＬｂ（図中、薄く網掛け表示されている）が含まれているとともに、艦船ＳＨとして、プレーヤＡの艦船ＳＨａ（図中、濃く網掛け表示されている）、及び、プレーヤＢの艦船ＳＨｂ（図中、薄く網掛け表示されている）が配置されている。

ゲームマップは、ゲームに参加している各プレーヤのゲーム端末１０において同一である。また、使用するゲームマップはゲーム毎に生成されるランダムマップ、或いは、予め用意されている固定マップの中から選択される。そして、ゲーム中は、ゲームマップ中の各ゲーム端末１０に応じた一部分が、それぞれのゲーム端末１０においてゲーム画面として表示される。

プレーヤは、ゲーム端末１０において表示されるゲーム画面を見ながら、所有する艦船や惑星上の施設等のユニットに対する各種の指示コマンドを入力してこれらを操作する。尚、プレーヤのコマンド入力は、ターン制ではなくリアルタイムに行われる。

図３に、プレーヤがゲーム端末１０に入力できるコマンドの一例を示す。同図では、コマンド毎に、そのコマンド名と、指示対象と、指示内容とが対応付けられている。同図によれば、コマンドには、例えば、所有する惑星上に造船所等の施設を建設させる“建設”コマンド、造船所に探査船や移住船、戦艦等の艦船を生産させる“造船”コマンド、探査船をゲームマップ上の未知のエリア（位置）に向かわせ、そのエリアを探査させる“探査”コマンド、移民船を空き惑星（どのプレーヤにも所有されていない惑星）に向かわせ、その惑星に移民を送り込む“移民”コマンド、戦艦に敵（他プレーヤ）の惑星を攻撃させ、それを占領させる“占領”コマンド、戦艦を敵の艦船と交戦可能な位置まで移動させ、その艦船と交戦させる“交戦”コマンド等がある。尚、各コマンドによる指示内容の実行には、それに応じた資産（資源や人、資金等）や時間を消費する。

プレーヤは、ゲーム画面を見ながら、自身の戦力（艦船や資産等）を効率良く利用するよう、ゲーム画面外の敵の位置やその戦力を推測しつつ適当なコマンドを入力して、マップ上の未知のエリアを開拓し、戦力を増強して勝利を目指す。

具体的には、例えば“建設”コマンドを入力して、所有する惑星上に造船所等の施設を建設させ、“造船”コマンドを入力して、建設させた造船所で探査船や移民船、戦艦といった艦船を生産させる。そして、“探査”コマンドを入力して、探査船にゲームマップ上の未知のエリアを探査させる。ゲーム画面において、未知のエリアは黒く塗り潰されて表示されており、探査船が到達することでそのエリアの様子が見えるようになる。探査によって空き惑星を発見すると、“移民”コマンドを入力してその空き惑星に移民船を向かわせ、移民を送り込む。移民を送り込むことで、その空き惑星を占領することができる。また、“交戦”コマンドを入力して敵の艦船と交戦したり、或いは、“占領”コマンドを入力して敵の惑星を攻撃してそれを占領したりする。

また、図２（ｂ）に示すように、所有する惑星同士が一定距離内にある場合、それらはスターラインＬＮで連結される。スターラインＬＮで連結された惑星では、資産が共有化される。複数の惑星で資産を共有することで、多くの資産を要する艦船や施設等の生産が可能となる。尚、スターラインＬＮで連結された惑星が敵に占領されると、この惑星を連結しているスターラインＬＮは解除される。具体的には、同図（ｂ）では、プレーヤＡが所有する惑星ＰＬａの内、図中右下部の４つの惑星ＰＬａが互いにスターラインＬＮａで連結されているとともに、図中中央下部の４つの惑星ＰＬａが互いにスターラインＬＮａで連結されている。また、プレーヤＢが所有する惑星ＰＬｂの内、図中左部の３つの惑星ＰＬｂが互いにスターラインＬＮｂで連結されている。

そして、所定の終了条件が満たされるとゲーム終了となる。終了条件としては、例えば所定時間（例えば、１時間）の経過や、母星が敵に占領若しくは破壊されたといった条件がある。またここで、勝敗条件としては、例えば所定時間の経過時点で所有している惑星が最も多いプレーヤが勝者となる、或いは、母星が占領若しくは破壊されたプレーヤが敗者となるといった条件がある。

［通信構成］
図４は、ゲーム中におけるゲーム端末１０間の論理的な接続構成を示す図であり、４台のゲーム端末Ａ，Ｂ，Ｃ，Ｄがゲームに参加している場合を示している。同図に示すように、本実施形態では、ゲームに参加しているゲーム端末１０の内、１台のゲーム端末１０が通信ホストとされる。そして、この通信ホストであるゲーム端末１０（以下、単に「通信ホスト」という）と、他のゲーム端末１０それぞれとが通信接続される。即ち、参加するゲーム端末１０同士の接続は、２台のゲーム端末１０間のピア・ツー・ピア型の直接接続によって実現される。

同図では、ゲーム端末Ａが通信ホストであり、このゲーム端末Ａとゲーム端末Ｂ，Ｃ，Ｄそれぞれとが通信接続されている。尚ここで、通信ホストは、各ゲーム端末１０の内、例えば処理能力が最も高い、或いは、他のゲーム端末１０との応答時間が最も短いといった所定の条件を満足するゲーム端末１０が選択される。

各ゲーム端末１０は、自機での入力コマンドを即時に通信ホストに送信する。通信ホストは、各ゲーム端末１０から送信されてくる入力コマンドを即時にゲーム端末１０それぞれに配信する。そして、各ゲーム端末１０は、通信ホストから配信されてくる入力コマンドを基にゲーム進行を制御する。

ゲーム端末１０間のデータ通信は、詳細には次のように実現される。即ち、ゲーム端末１０は、図５に示すように、ホスト機能１２及びクライアント機能１４を有している。これらの機能は、互いに独立した機能として動作する。

ホスト機能１２は、該ゲーム端末１０をホスト機として機能させ、各ゲーム端末１０間でのデータ通信を制御する。具体的には、各ゲーム端末１０から受信した入力コマンド等のデータのゲーム端末１０それぞれへの配信を行う。

クライアント機能１４は、該ゲーム端末１０をクライアント機として機能させ、該ゲーム端末１０でのゲーム進行を制御する。具体的には、プレーヤによるコマンドの入力受け付け、入力コマンドの通信ホストへの送信、ホスト機能１２により配信されてきた各ゲーム端末１０での入力コマンドに基づくゲームの進行制御、ゲーム画像やゲーム音の生成等を行う。

これらの機能は、図６に示すように、通信ホストにおいては、ホスト機能１２及びクライアント機能１４の双方が有効となり、通信ホスト以外のゲーム端末１０においては、クライアント機能１４のみが有効となる。即ち、通信ホストは、ゲームを実行するクライアント機であるとともに、ゲームシステム１でのデータ通信を制御するホスト機でもある。また、通信ホスト以外のゲーム端末１０は、クライアント機である。そして、各ゲーム端末１０におけるクライアント機能１４が通信ホストのホスト機能１２と通信することで、ゲームシステム１におけるネットワークゲームが実現される。

同図では、ゲーム端末Ａが通信ホストであり、このゲーム端末Ａにおいて、ホスト機能１２及びクライアント機能１４が有効となっている。即ち、ゲーム端末Ａは、ホスト機であるとともにクライアント機である。また、他のゲーム端末Ｂ，Ｃ，Ｄにおいては、ホスト機能１２が無効であり、クライアント機能１４のみが有効となっている。即ち、ゲーム端末Ｂ，Ｃ，Ｄはクライアント機である。

そして、ゲーム端末Ａのホスト機能１２（以下、「ホストＡ」という）に、ゲーム端末Ａ，Ｂ，Ｃ・・・それぞれのクライアント機能１４（以下、「クライアントＡ，Ｂ，Ｃ・・・」という）が接続されている。このとき、ホストＡとクライアントＢ，Ｃ・・・それぞれとの間のデータ通信は通信ネットワークＮを介して実現され、ホストＡとクライアントＡとの間のデータ通信はゲーム端末Ａ内でのデータ転送によって実現される。

図７，８は、ホスト・クライアント間の通信手順を示す図であり、両図とも、ホストＡ及びクライアントＡ，Ｂに注目した場合を例として示している。また、図８のタイムチャートにおいては、通信ラグが全く無いものとしている。本実施形態において、各ゲーム端末１０におけるゲームの進行制御はサイクルを単位として行われる。サイクルとは、予め定められた連続する所定数Ｉのフレームから成る期間であり、例えば１フレームが０．０４［秒］程度であり、１サイクルが１０フレームである場合には、１サイクルは０．４［秒］程度となる。

図７（ａ）に示すように、ゲーム端末１０においてプレーヤによりコマンドＣが入力されると、該ゲーム端末１０のクライアントが、この入力コマンドＣをホストに送信する。すると、ホストは、受信した入力コマンドＣを各クライアントに配信（送信）する。同図（ａ）では、サイクルＳＣ_ｎにおいて、ゲーム端末Ａでの入力コマンドＣ_ａがクライアントＡからホストＡに送信され、この入力コマンドＣ_ａが、ホストＡからクライアントＡ，Ｂそれぞれに配信されている（図８の（１））。

また、図７（ｂ）に示すように、各クライアントは、サイクルの終了毎に、他のクライアントとの処理同期を取るためのサイクルの終了（区切り）を示す同期データＤをホストに送信する。すると、ホストは、受信した同期データＤを各クライアントに配信する。同図（ｂ）では、サイクルＳＣ_ｎの終了時に、クライアントＡから同期データＤ_ａが、クライアントＢから同期データＤ_ｂが、それぞれホストＡに送信され、ホストＡから、この同期データＤ_ａ，Ｄ_ｂがクライアントＡ，Ｂそれぞれに配信されている（図８（２））。尚、図７，８では、ホストＡから、同期データＤ_ａ，Ｄ_ｂが１つのデータとして配信されているように示されているが、実際には別々のデータとして配信される。

各クライアントは、ホストから配信されてくる同期データＤの受信により、ホストから受信した各クライアントでの入力コマンドＣが何れのサイクルで入力されたものであるかを判断する。具体的には、例えばゲーム端末Ａについての配信データ（入力コマンドＣ_ａや同期データＤ_ａ）の内、サイクルＳＣ_ｎ−１の終了を示す同期データＤ_ａｎ−１の受信から、サイクルＳＣ_ｎの終了を示す同期データＤ_ａｎの受信までの間に受信した入力コマンドＣ_ａを、サイクルＳＣ_ｎでの入力コマンドＣ_ａと判断する。

そして、各クライアントは、各サイクルのゲーム進行処理（各ユニットの制御やフレーム画像の生成・表示等）を、その２サイクルおいて前のサイクル（即ち、３サイクル前）での入力コマンドＣに基づいて行う。即ち、例えばゲーム端末Ａ，Ｂそれぞれにおいて、サイクルＳＣ_ｎでのゲーム端末Ａ，Ｂでの入力コマンドＣ_ａｎ，Ｃ_ｂｎに従って、サイクルＳＣ_ｎ＋３でのゲーム進行が制御される（図８の（３））。

このように、ゲームシステム１では、各ゲーム端末１０での入力コマンドＣは、該ゲーム端末１０のクライアントからホストに送信され、ホストから各クライアントに配信される。また、各クライアントから、サイクル毎に該サイクルの終了を示す同期データＤがホストに送信され、ホストから各クライアントに配信される。各クライアントでは、この同期データＤの受信により各入力コマンドの入力サイクルが判断され、各入力コマンドは、該コマンドが入力されたサイクルの２サイクルおいた後のサイクル（即ち、３サイクル後）のゲーム進行に反映される。

［待ちの発生］
ホスト・各クライアント間のデータ通信は、理想的には上述した通りであるが、実際には、種々の要因により、クライアントにおいて、入力コマンドが未受信であるために次サイクルの処理を開始できず、ゲーム進行が一時停止している状態、即ち“待ち”が発生する。これは、主に、（Ａ）通信ネットワークＮによる通信ラグ（通信遅れ）、（Ｂ）各ゲーム端末１０の処理能力（マシンパワー）の違い、といった理由により発生する。

（Ａ）通信ネットワークＮによる通信ラグ
ゲーム端末１０間は、例えばインターネット等の公衆通信網といったゲームシステム１に係る通信以外の通信にも利用される通信網により実現される通信ネットワークＮを介して接続されるため、この通信ネットワークＮに起因する通信ラグが生じる。通信ラグは、ゲーム端末１０間の物理的な距離や、通信ネットワークＮの通信速度といった通信品質に応じたものであるとともに、通信負荷（トラフィック）の変動によっても左右される。このため、同一データについて、ホストからの配信とクライアントでの受信とに時間差が生じるとともに、クライアント毎にも受信時刻が異なる。尚、ホストと同一のゲーム端末１０（通信ホスト）内のクライアントについては、ホストとのデータ通信に通信ネットワークＮを介さないため、他のクライアントと比較して、ホストとの間に生じる通信ラグが極めて小さい。

（Ｂ）ゲーム端末１０の処理能力の違い
また、ゲーム端末１０は家庭に設置されているパソコン等で実現されるため、端末毎にその処理能力が異なる。即ち、ゲーム端末１０毎に、クライアントが１フレームの処理に要する時間（フレーム時間）Ｔが異なり、その結果、１サイクルの処理に要する時間（サイクル時間）が異なる。クライアント毎のフレーム時間Ｔの差は、ゲーム画面の表示速度（具体的には、フレーム画像の更新速度）の差として表れる。

クライアント毎にサイクル時間が異なると、同一サイクルについての同期データＤの送信時刻がクライアント毎に異なる。具体的には、処理能力が高いクライアントである程、サイクル時間が短く、同一サイクルについての同期データＤの送信時刻が他のクライアントより早い。その結果、各クライアントにおいて、同一サイクルについての同期データＤの受信に時間差が生じる。そして、この時間差は、サイクルの進行に従って大きくなる。尚、実際のサイクル時間Ｔは、ゲーム演算量等によって多少変動し得る。

図９は、上述した２つの要因による待ちの発生を説明するための図である。同図は、ホストＡ及びクライアントＡ，Ｂに注目した場合のタイムチャートを示している。通信ホストであるゲーム端末Ａの方がゲーム端末Ｂよりも処理能力が高いので、クライアントＡのフレーム時間Ｔ_ａは、クライアントＢのフレーム時間Ｔ_ｂよりも短い。また、ともに通信ホスト内の機能であるクライアントＡ・ホストＡ間に生じる通信ラグは、クライアントＢ・ホストＡ間に生じる通信ラグよりも小さい。

クライアントにおいて、各サイクルの処理は、該サイクルから２サイクルおいて前（３サイクル前）のサイクルでの入力コマンドを基に行われる。また、サイクルの区切りは、同期データＤの受信により判断される。即ち、各クライアントは、各サイクルの終了時点において、該サイクルから２サイクル前の、全クライアントについての同期データＤの受信を完了している必要がある。従って、各クライアントでは、同期データＤの受信が２サイクル以上遅れると、次のサイクルが開始できない状態である“待ち”が発生する。

同図に示すように、クライアントＡ，ＢそれぞれがサイクルＳＣ_ｎから同時に処理を開始した場合、例えばクライアントＡからサイクルＳＣ_ｎ＋１の終了時に送信された同期データＤ_ａｎ＋１は、ホストＡで受信され、ホストＡからクライアントＡ，Ｂに配信される。そして、この同期データＤ_ａｎ＋１は、クライアントＡにおいて、サイクルＳＣ_ｎ＋２途中の時刻ｔ_ａ１に受信される。また、クライアントＢからサイクルＳＣ_ｎ＋１の終了時に送信された同期データＤ_ｂｎ＋１は、ホストＡで受信され、ホストＡからクライアントＡ，Ｂに配信される。そして、この同期データＤ_ｂｎ＋１は、クライアントＡにおいて、時刻ｔ_ａ１より遅い時刻ｔ_ａ３に受信される。

クライアントＡにおいて、サイクルＳＣ_ｎ＋３の処理は時刻ｔ_ａ２に終了するが、続いて次サイクルＳＣ_ｎ＋４の処理を開始するためには、この時刻ｔ_ａ２の時点で、その２サイクル前のサイクルＳＣ_ｎ＋１に係る全クライアントの同期データＤ_ａｎ＋１，Ｄ_ｂｎ＋１の受信を完了している必要がある。しかし、同期データＤ_ａｎ＋１の受信時刻ｔ_ａ１は時刻ｔ_ａ２よりも早いが、同期データＤ_ｂｎ＋１の受信時刻ｔ_ａ３は時刻ｔ_ａ２よりも遅い。つまり、サイクルＳＣ_ｎ＋３の終了時点では同期データＤ_ｂｎ＋１を受信していないため、次サイクルＳＣ_ｎ＋４の処理を開始できない。従って、サイクルＳＣ_ｎ＋３の処理の終了時刻ｔ_ａ２から、同期データＤ_ｂｎ＋１を受信して次サイクルＳＣ_ｎ＋４の処理が開始可能となる時刻ｔ_ａ３までの間、待ちフレーム数Ｗ_ａの待ちが発生する。但し、Ｗ＝１，２，３，・・・、である。

ここで、発生した待ちはその直前のサイクルに含まれるものとする。即ち、各サイクルは、１サイクル当たりのフレーム数Ｉのフレーム画像が生成・表示制御される期間と、その直後に発生した待ちフレーム数Ｗの待ちの期間とから成る。そして、同期データＤは、各サイクルの終了後にクライアントからホストに送信されることとする。またこのとき、該サイクルで発生した待ちの情報（詳細には、発生した待ちフレーム数Ｗ）が同期データＤに含めて送信される。

このように、ゲームシステム１では、上述した２つの理由により、クライアントにおいて待ちが発生する。待ちが発生すると、その間はゲームの進行処理が一時停止するが、待ちが頻繁に発生すると、表示更新／停止を繰り返す不自然なゲーム画面となり、プレーヤに対して違和感や不満感といったストレスを与えることになる。

［平滑化処理］
そこで、本実施形態では、待ちが発生したクライアントにおいてフレーム時間Ｔを長くするように調整する平滑化処理を行うことで、以降の待ちの発生を抑制している。

図１０は、平滑化処理を説明するための図であり、平滑化処理によるフレーム時間Ｔの変化を示している。また、同図では、クライアントＡの場合を例として示しており、サイクルＳＣ_ｎの終わりに、待ちフレーム数Ｗ_ａの待ちが発生している。同図に示すように、サイクルＳＣ_ｎの終わりに待ちが発生すると、その次のサイクルＳＣ_ｎ＋１から平滑化処理が開始される。平滑化処理では、発生した待ちフレーム数Ｗ_ａに応じて、各フレームＦＬのフレーム時間Ｔが徐々に長くされる。平滑化処理を開始後の各フレーム時間Ｔ_ｉは、次式（１）で与えられる。
Ｔ_ｉ＝Ｔ_ｉ−１＋ΔＴ_ｉ ・・（１）

式（１）において、ｉは平滑化処理の開始からの経過フレーム数であり、ｉ＝１，２，・・・である。また、ΔＴ_ｉは前フレーム時間Ｔ_ｉ−１に対する伸延時間であり、ΔＴ_ｉ＞０、である。即ち、フレーム時間Ｔ_ｉは、伸延時間ΔＴ_ｉづつ徐々に長くなる。

伸延時間ΔＴ_ｉは経過フレーム数ｉ毎に異なる値としても良いが、ここでは同一の値ΔＴとし、次式（２）で与えられることとする。
ΔＴ＝（Ｔ_０×Ｗ_ａ）／Ｅ ・・（２）

式（２）において、Ｔ_０は平滑化処理の開始直前のフレーム時間Ｔ（同図では、サイクルＳＣ_ｎの最終フレームＦＬ_Ｉのフレーム時間Ｔ）である。また、Ｅは定数であり、例えば１サイクル当たりのフレーム数Ｉを整数倍した値で与えられる。即ち、伸延時間ΔＴは、発生した待ちフレーム数Ｗ_ａに比例した値となる。従って、平滑化処理が行われている間のフレーム時間Ｔ_ｉは、図１１に示すように、一次関数のグラフとなる。

本実施形態において、この平滑化処理はサイクルを単位として実現される。即ち、図１２に示すように、サイクルＳＣ_ｎ＋１から開始された平滑化処理は、そのサイクルＳＣ_ｎ＋１の終了時点、より詳細にはそのサイクルＳＣ_ｎ＋１の最終フレームＦＬ_Ｉの終了時点で終了される。そして、同図（ａ）に示すように、サイクルＳＣ_ｎ＋１の終わりに待ちが発生すると、発生した待ちフレーム数Ｗ_ａに応じて再度伸延時間ΔＴが算出され、この新たな伸延時間ΔＴを基に、次のサイクルＳＣ_ｎ＋２の平滑化処理が開始される。一方、同図（ｂ）に示すように、サイクルＳＣ_ｎ＋１の終わりに待ちが発生しない場合には、次のサイクルＳＣ_ｎ＋２において平滑化処理は行われない。

このように、平滑化処理では、フレーム時間Ｔが徐々に長くされる。フレーム時間Ｔを徐々に長くさせるのは、ゲーム画面が動画であるためであり、フレーム時間Ｔを大きく変化させると、表示速度が急激に変化して不自然なゲーム画面となることを防止するためである

また、発生した待ちフレーム数Ｗに応じた（比例した）伸延時間ΔＴとすることで、例えばゲーム端末１０毎の処理能力が異なる場合に、他のクライアントのフレーム時間Ｔとの差を縮め、以降の待ちの発生を抑制することが可能となる。

［最適化処理］
上述の平滑化処理では、クライアントにおいて待ちが発生すると、該クライアントでのフレーム時間Ｔを長くさせる調整を行うことで以降発生する待ちを抑制している。ところで、待ちは、上述した主に２つの理由（通信ネットワークＮによる通信ラグ、及び、各ゲーム端末１０の処理能力の違い）によって発生する。通信ラグは、ゲームシステム１の構成上発生が避けられないものであるとともに、通信ネットワークＮの通信負荷によってその大きさが変動し得るものである。また、実際のフレーム時間（実フレーム時間）Ｔは、ゲーム処理負荷が大きい場合には一時的に長くなるといったように変動し得るものである。これらの理由の組み合わせにより、各クライアントでの待ちは頻繁に発生し得る。

そして、平滑化処理により、クライアントそれぞれが待ちの発生毎に自身のフレーム時間Ｔを長くすると、結果的に、各クライアントのフレーム時間Ｔは長くされるのみであり、更に、場合によっては各クライアントで発生する待ちが増大する可能性がある。そこで、各クライアントにおいて、平滑化処理を行っていないサイクルでは、平滑化処理によって長くされたフレーム時間Ｔを短くさせるように調整する最適化処理を行う。

図１３は、最適化処理を説明するための図であり、フレーム時間Ｔの変化を示している。また、同図では、ゲーム端末Ａ，Ｂ，Ｃ，Ｄが参加しており、クライアントＡの場合を例として示している。同図に示すように、サイクルＳＣ_ｎの終わりに待ちが発生しない場合、その次のサイクルＳＣ_ｎ＋１から最適化処理が開始される。最適化処理では、２サイクルおいて前（３サイクル前）のサイクルＳＣ_ｎ−２で発生した各クライアントでの待ちフレーム数Ｗ_ｎ−１に基づいて、各フレーム時間Ｔが短くされる。

具体的には、図１４に示すように、サイクルＳＣ_ｎ−２で発生したクライアントＡ，Ｂ，Ｃ，Ｄそれぞれの待ちフレーム数Ｗ_ａｎ−２，Ｗ_ｂｎ−２，Ｗ_ｃｎ−２，Ｗ_ｄｎ−２の内、最大数が最大待ちフレーム数Ｗ_ｍａｘとされる。そして、この最大待ちフレーム数Ｗ_ｍａｘと、自機の待ちフレーム数Ｗとの差分である差分フレーム数ｄが算出される。この差分フレーム数ｄは、相対的に他機を待たせているフレーム数を表す。具体的には、例えば、Ｗ_ａｎ−２＝１、Ｗ_ｂｎ−２＝５、Ｗ_ｃｎ−２＝２、Ｗ_ｄｎ−２＝２、であるとすると、最大待ちフレーム数Ｗ_ｍａｘは、Ｗ_ｍａｘ＝５、となる。そして、クライアントＡの場合、差分フレーム数ｄは、ｄ＝４（＝５−１）、となる。自機の待ちフレーム数Ｗが最大である場合には、ｄ＝０、となり、他機を待たせていない、即ち自機以上に待っている他機がいないことになる。

次いで、差分フレーム数ｄの値に応じて、短くさせる目標となるフレーム時間である目標時間Ｎが設定される。具体的には、ｄ＝１、の場合には、式（３ａ）に示す算出式に従って算出され、ｄ＝２、の場合には、式（３ｂ）に示す算出式に従って算出され、ｄ＝３、の場合には、式（３ｃ）に示す算出式に従って算出され、ｄ＝４、の場合には、式（３ｄ）に示す算出式に従って算出され、ｄ＝５、の場合には、式（３ｅ）に示す算出式に従って算出され、ｄ＝６、の場合には、式（３ｆ）に示す算出式に従って算出され、ｄ＝７、の場合には、式（３ｇ）に示す算出式に従って算出され、ｄ＞７、の場合には、式（３ｈ）に示す算出式に従って算出される。
Ｎ＝Ｓ×１１／１２（ｄ＝１） ・・（３ａ）
Ｎ＝Ｓ×１０／１１（ｄ＝２） ・・（３ｂ）
Ｎ＝Ｓ×９／１０（ｄ＝３） ・・（３ｃ）
Ｎ＝Ｓ×８／９（ｄ＝４） ・・（３ｄ）
Ｎ＝Ｓ×７／８（ｄ＝５） ・・（３ｅ）
Ｎ＝Ｓ×６／７（ｄ＝６） ・・（３ｆ）
Ｎ＝Ｓ×５／６（ｄ＝７） ・・（３ｇ）
Ｎ＝Ｓ×４／５（ｄ＞７） ・・（３ｈ）

式（３ａ）〜（３ｈ）において、Ｓは標準フレーム時間である。標準フレーム時間Ｓとは、ゲーム端末１０毎に、例えばその処理能力等を考慮して決定される標準となるフレーム時間である。式（３ａ）〜（３ｈ）により算出される目標時間Ｎは、差分フレーム数ｄが大きい程、小さい。また、目標時間Ｎが標準時間Ｓより短く設定されるのは、実フレーム時間が通信ラグ等により若干長くなることが多いためである。

そして、各フレームＦＬのフレーム時間Ｔが、この目標時間Ｎに収束するように徐々に短くされる。即ち、図１３に示すように、クライアントＡにおいて、サイクルＳＣ_ｎ＋１から最適化処理（フレーム短縮）が開始される場合、最適化処理の開始後の各フレームＦＬ_ｉのフレーム時間Ｔ_ｉは、次式（４）で与えられる。
Ｔ_ｉ＝（Ｔ_ｉ−１＋Ｎ）／２ ・・（４）

式（４）において、ｉは最適化処理の開始からの経過サイクル数であり、ｉ＝１，２，・・・である。従って、サイクル時間Ｔ_ｉは、図１５のグラフに示すように、時間経過とともに目標時間Ｎに向かって収束するように変化する。

また、差分フレーム数ｄが、ｄ＝０、の場合には、目標時間Ｎは算出されず、各フレーム時間Ｔ_ｉは、Ｔ_ｉ＝Ｓ、とされる。即ち、フレーム時間Ｔ_ｉは、強制的に標準時間Ｓに戻される。

本実施形態において、最適化処理は、上述した平滑化処理と同様にサイクルを単位として実現される。即ち、図１６に示すように、サイクルＳＣ_ｎ＋１から開始された最適化処理は、そのサイクルＳＣ_ｎ＋１の終了時点、より詳細にはそのサイクルＳＣ_ｎ＋１の最終フレームＦＬ_Ｉの終了時点で終了される。そして、同図（ａ）に示すように、サイクルＳＣ_ｎ＋１の終わりに待ちが発生していないならば、２サイクル前のサイクルＳＣ_ｎ−１での各クライアントで発生した待ち時間Ｗ_ｎ−１に応じて再度目標時間Ｎが算出され、この新たな目標時間Ｎを基に、次のサイクルＳＣ_ｎ＋２における最適化処理が開始される。一方、同図（ｂ）に示すように、サイクルＳＣ_ｎ＋１の終わりに待ちが発生した場合には、次のサイクルＳＣ_ｎ＋２からは平滑化処理が開始され、最適化処理は行われない。

つまり、本実施形態では、各クライアントにおいて、サイクル毎に、その前サイクルで発生した待ちの有無により平滑化処理或いは最適化処理のどちらかが選択され、選択された処理が行われる。即ち、待ちが発生した場合には平滑化処理が行われ、待ちが発生していない場合には最適化処理が行われる。

［機能構成］
図１７は、ゲーム端末１０の機能構成を示すブロック図である。同図によれば、ゲーム端末１０は、機能的には、操作入力部１００と、処理部２００と、画像表示部３４０と、音出力部３５０と、記憶部４００と、通信部５００とを備えて構成される、

操作入力部１００は、プレーヤによる操作指示を受け付け、操作に応じた操作信号を処理部２００に出力する。特に、本実施形態では、プレーヤによるコマンドの入力を検出し、検出したコマンドを処理部２００に出力する。この機能は、例えばキーボードやマウス、ボタンスイッチ、レバー、各種センサ等によって実現される。

処理部２００は、ゲーム端末１０の全体制御やゲームの進行制御、画像生成等の各種演算処理を行う。この機能は、例えばＣＰＵ（ＣＩＳＣ型、ＲＩＳＣ型）、ＡＳＩＣ（ゲートアレイ等）等の演算処理装置やその制御プログラムにより実現される。

また、処理部２００は、主にゲームの実行に係る演算処理を行うゲーム演算部２１０と、ゲーム演算部２１０の処理によって求められた各種のデータに基づき、ゲーム画像を生成する画像生成部２４０と、効果音やＢＧＭ等のゲーム音を生成する音生成部２５０とを含んでいる。

ゲーム演算部２１０は、記憶部４００から読み出したゲーム情報（プログラム及びデータ）や、操作入力部１００から入力される操作信号等に基づいて種々のゲーム処理を実行する。また、本実施形態では、ゲーム演算部２１０は、ホスト機能を実現するホスト部２２０と、クライアント機能を実現するクライアント部２３０とを含んでいる。

ゲーム演算部２１０は、ゲーム実行開始に先立ち、所定のゲーム前処理を行う。具体的には、先ず、ロビーサーバ６０にログインしてゲームの参加申請を行う。そして、ロビーサーバ６０から、ゲームに参加する他のプレーヤやそのゲーム端末１０、通信ホスト等を通知されると、自端末が通信ホストであれば、クライアント機能及びホスト機能の双方を有効にし、他のゲーム端末１０からの接続を待機する。また、自端末が通信ホストでないならば、クライアント機能を有効にし、通信ホストに接続する。尚、ゲームに参加する他のプレーヤやそのゲーム端末１０、通信ホスト等の情報は、参加ゲーム端末情報４２２に格納される

その後、ロビーサーバ６０からゲーム開始が通知されると、所定のゲーム中処理の実行を開始する。即ち、自端末が通信ホストである場合には、クライアント部２３０が所定のクライアント処理を実行するとともに、ホスト部２２０が所定のホスト処理を実行する。また、自端末が通信ホストでない場合には、クライアント部２３０が所定のクライアント処理を実行する。

ホスト部２２０は、所定のホスト処理を実行して、各ゲーム端末１０間のデータ通信を制御する。具体的には、クライアントから入力コマンドや同期データＤ等のデータを受信すると、この受信データを各クライアントに配信する。ここで、クライアントとのデータの送受信は、該ゲーム端末１０内のクライアント部２３０とのデータ転送、及び、他のゲーム端末１０とのデータ通信を意味する。

クライアント部２３０は、フレーム時間補正部２３２を含み、所定のクライアント処理を実行して該ゲーム端末１０におけるゲーム進行を制御する。具体的には、操作入力部１００から、プレーヤの操作入力によって入力されたコマンドが入力されると、この入力コマンドをホストに送信する。ここで、ホストとのデータの送受信は、該ゲーム端末１０が通信ホストである場合には、該端末内のホスト部２２０との間のデータ転送を意味し、通信ホストでない場合には、通信ホストとの間のデータ通信を意味する。

また、クライアント部２３０は、サイクルの終了毎に、該サイクルの終わりに発生した待ちフレーム数Ｗを検出し、検出した待ちフレーム数Ｗを含めた同期データＤをホストに送信する。尚、待ちが発生していない場合には、待ちフレーム数Ｗを「０」とする。

また、クライアント部２３０は、ホストから配信されてくる入力コマンドを受信すると、この受信した入力コマンドを、該入力コマンドの送信元であるゲーム端末１０に対応付けて受信コマンド情報４２４に格納する。

受信コマンド情報４２４とは、ホストから受信した各クライアントでの入力コマンドの情報である。図１８に、受信コマンド情報４２４のデータ構成の一例を示す。同図によれば、受信コマンド情報４２４は、ゲーム端末１０毎の複数の受信コマンドデータ４２５から構成される。受信コマンドデータ４２５は、該当するゲーム端末１０の名称（ゲーム端末名）４２５ａとともに、サイクル番号４２５ｂと、入力コマンド４２５ｃと、完了フラグ４２５ｄとを対応付けて格納している。完了フラグ４２５ｄとは、対応するサイクルの入力コマンドの受信を完了したか否かを示すフラグである。この完了フラグ４２５ｄは、初期値として「０」が設定されており、対応するサイクルの同期データＤが受信されると「１」に更新される。

クライアント部２３０は、ホストから受信した入力コマンドを、該入力コマンドの送信元であるゲーム端末１０に該当する受信コマンドデータ４２５において、完了フラグ４２５ｄが「０」であり、且つサイクル番号４２５ｂが最前である入力コマンド４２５ｃとして追加する。例えば同図の場合、受信されたゲーム端末Ａでの入力コマンドは、サイクル番号４２５ｂが「２３」の入力コマンド４２５ｃとして追加格納される。

また、クライアント部２３０は、ホストから配信されてくる同期データＤを受信すると、この受信した同期データＤを基に、受信コマンド情報４２４及び待ち情報４２６を更新する。即ち、受信した同期データＤの送信元のゲーム端末１０に該当する受信コマンドデータ４２５において、該当するサイクル番号４２５ｂの完了フラグ４２５ｄを「１」に更新する。

また、受信した同期データＤに含まれる待ちフレーム数Ｗを、該同期データＤの受信元であるゲーム端末１０に対応付けて待ち情報４２６に格納する。待ち情報４２６とは、各クライアントでの待ちに関する情報である。図１９に、待ち情報４２６のデータ構成の一例を示す。同図によれば、待ち情報４２６は、ゲーム端末１０毎の複数の待ちデータ４２７から構成される。待ちデータ４２７は、該当するゲーム端末名４２７ａとともに、サイクル番号４２７ｂと、待ちフレーム数４２７ｃとを対応付けて格納している。尚、同図中、「−」はデータを未格納であることを示している。

クライアント部２３０は、ホストから受信した同期データＤに含まれる待ちフレーム数Ｗを、該同期データＤの送信元であるゲーム端末１０に該当する待ちデータ４２７において、該当するサイクル番号４２７ｂの待ちフレーム数４２７ｃとして格納する。例えば同図の場合、受信されたゲーム端末Ａの同期データＤに含まれる待ちフレーム数Ｗは、サイクル番号４２７ｂが「２３」の待ちフレーム数４２７ｃとして格納される。

フレーム時間補正部２３２は、フレーム毎に該フレームのフレーム時間Ｔを補正する。具体的には、サイクルの終了毎に、該終了したサイクルの終わりに待ちが発生したか否かを判断し、待ちが発生したならば、次サイクルにおいて、上述した平滑化処理に基づく処理を行って各フレーム時間Ｔを長くさせる。即ち、該終了したサイクルの終わりに発生した待ちフレーム数Ｗを基に、式（２）に示した算出式に従って伸延時間ΔＴを算出する。そして、次サイクルにおいて、フレーム毎に、算出した伸延時間ΔＴを前フレームの実フレーム時間Ｔに加算して補正フレーム時間Ｕを算出する。

ここで、平滑化処理にかかるデータは平滑化情報４２８に格納されている。図２０に、平滑化情報４２８のデータ構成の一例を示す。同図によれば、平滑化情報４２８は、伸延時間算出式４２８ａと、伸延時間４２８ｂと、平滑化フラグ４２８ｃとを含んでいる。伸延時間算出式４２８ａは、式（２）で示した、伸延時間ΔＴの算出式を格納する。伸延時間４２８ｂは、伸延時間算出式４２８ａに従って算出された伸延時間ΔＴの値を格納する。この値は、サイクル毎に更新される。平滑化フラグ４２８ｃは、平滑化処理に基づくフレーム時間Ｔの伸延を実行中であるか否かを示すフラグである。実行中であれば「１」が格納され、そうでなければ「０」が格納される。

また、フレーム時間補正部２３２は、終了したサイクルの終わりに待ちが発生していないならば、次サイクルにおいて、上述した最適化処理に基づく処理を行って各フレーム時間Ｔを短くさせる。即ち、待ち情報４２６を参照して、該終了したサイクルの２サイクル前のサイクルで発生した各クライアントの待ちフレーム数Ｗ_−２の内から最大数を選択し、これを最大待ちフレーム数Ｗ_ｍａｘとする。次いで、この最大待ちフレーム数Ｗ_ｍａｘから、自機の２サイクル前の待ちフレーム数Ｗ_−２を減算して、差分フレーム数ｄを算出する。

続いて、この差分フレーム数ｄが「０」より大きいならば、式（３ａ）〜（３ｈ）に示した、この差分フレーム数ｄの値に応じた算出式に従って目標時間Ｎを算出する。そして、次サイクルにおいて、フレーム毎に、算出した目標時間Ｎとその前フレームの実フレーム時間Ｔとを加算平均して補正フレーム時間Ｕを算出する。また、差分フレーム数ｄが「０」ならば、次サイクルにおいて、標準フレーム時間Ｓを各フレームの補正フレーム時間Ｕとする。

ここで、最適化処理にかかるデータは最適化情報４３２に格納されている。図２１に、最適化情報４３２のデータ構成の一例を示す。同図によれば、最適化情報４３２は、目標時間算出式４３２ａと、差分フレーム数４３２ｂと、目標時間４３２ｃとを格納している。目標時間算出式４３２ａは、式（３ａ）〜（３ｈ）で示した、差分フレーム数ｄ毎の目標時間Ｎの算出式を格納する。差分フレーム数４３２ｂは、２サイクル前の各クライアントでの待ちフレーム数Ｗ_−２から算出された差分フレーム数ｄの値を格納する。この値は、サイクル毎に更新される。目標時間４３２ｃは、差分フレーム数４３２ｂに応じた目標時間算出式４３２ａに従って算出された目標時間Ｎの値を格納する。この値は、サイクル毎に更新される。

更に、フレーム時間補正部２３２は、上述した平滑化処理或いは最適化処理によって算出した補正フレーム時間Ｕの値を、Ｓ／２≦Ｕ≦２×Ｓ、の範囲に収めるクリッピング処理を行う。ここで、Ｓは標準フレーム時間である。尚、フレーム時間補正部２３２により算出された補正フレーム時間Ｕは、あくまでも処理の目標とする値であり、この値での実行が保証されるものではない。例えばハードウェアの処理能力に対してゲーム演算量が多いフレームの場合、実フレーム時間はこれより長くなり得る。

そして、クライアント部２３０は、フレーム時間補正部２３２によって算出された補正フレーム時間Ｕで、各サイクルのゲームの進行処理を行う。即ち、受信コマンド情報４２４を参照し、該サイクルの２サイクルおいて前（３サイクル前）の各ゲーム端末１０での入力コマンドを基に、補正フレーム時間Ｕの時間間隔で、各プレーヤのユニット等を制御し、画造生成部２４０にフレーム画像を生成させ、画像表示部３４０に表示させる処理を、１サイクルに相当するフレーム数Ｉだけ繰り返し行う。

ここで、クライアント部２３０により制御されるサイクルの進行に関する情報は、サイクル進行情報４３４に格納されている。図２２に、サイクル進行情報４３４のデータ構成の一例を示す。同図によれば、サイクル進行情報４３４は、現サイクル４３４ａと、実フレーム時間４３４ｂと、補正フレーム時間４３４ｃと、標準フレーム時間４３４ｄと、待ちフレーム数４３４ｅとを格納している。

現サイクル４３４ａは、現在クライアント部２３０により進行制御の対象となっているサイクルのサイクル番号を格納する。この値は、サイクル毎に更新される。実フレーム時間４３４ｂは、直前のフレームの実際のフレーム時間Ｔの値を格納する。この値は、フレーム毎に更新される。補正フレーム時間４３４ｃは、フレーム時間補正部２３２により算出された補正フレーム時間Ｕの値を格納する。この値は、フレーム毎に更新される。標準フレーム時間４３４ｄは、ゲーム開始に先立ち、ロビーサーバ６０から通知される標準フレーム時間Ｓの値を格納する。待ちフレーム数４３４ｅは、直前に発生した待ちフレーム数Ｗの値を格納する。

画像生成部２４０は、ゲーム演算部２１０による演算結果に基づき、ゲーム画面を表示するためのゲーム画像を生成し、生成した画像の画像信号を画像表示部３４０に出力する。画像表示部３４０は、処理部２００からの画像信号に基づくゲーム画像を表示する。この機能は、例えばＣＲＴ、ＬＣＤ、ＥＬＤ等のハードウェアによって実現される。

音生成部２５０は、ゲーム中に使用される効果音やＢＧＭ等のゲーム音声を生成し、生成したゲーム音声の音信号を音出力部３５０に出力する。音出力部３５０は、音生成部２５０からの音信号に基づいて、ＢＧＭや効果音等のゲーム音声を出力する。この機能は、例えばスピーカ等によって実現される。

記憶部４００は、処理部２００にゲーム端末１０を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームを実行させるために必要なプログラムやデータ等を記憶するとともに、処理部２００の作業領域として用いられ、処理部２００が各種プログラムに従って実行した演算結果や操作入力部１００から入力される入力データ等を一時的に記憶する。この機能は、例えば各種ＩＣメモリやハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ、ＲＡＭ、ＶＲＡＭ等によって実現される。

また、記憶部４００は、処理部２００をゲーム演算部２１０として機能させるためのゲームプログラム４１０及びゲームデータを記憶する。ゲームプログラム４１０には、ホスト部２２０として機能させるためのホストプログラム４１２と、クライアント部２３０として機能させるためのクライアントプログラム４１４とが含まれる。また、ゲームデータには、参加ゲーム端末情報４２２と、受信コマンド情報４２４と、待ち情報４２６と、平滑化情報４２８と、最適化情報４３２と、サイクル進行情報４３４とが含まれる。

通信部５００は、所定の通信回線に接続して他のゲーム端末１０等の外部装置とのデータ通信を行う。この機能は、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＩｒＤＡ等の無線通信モジュール、モデム、ＴＡ、有線用の通信ケーブルのジャックや制御回路などによって実現される。

［処理の流れ］
図２３は、ゲームシステム１におけるゲーム処理の流れを説明するためのフローチャートである。同図によれば、先ず、ゲーム端末１０がロビーサーバ６０に接続してログインし、ゲームの参加申請を行う（ステップＡ１）。

すると、ロビーサーバ６０が、このゲーム端末１０からの参加申請を受け付け（ステップＢ１）、他のゲーム端末１０からの参加申請を基にゲームの参加プレーヤを決定する（ステップＢ３）。次いで、これら各参加プレーヤのゲーム端末１０の内から、その処理能力等を考慮して通信ホストとなるゲーム端末１０を決定し（ステップＢ５）、また、各ゲーム端末１０の処理能力等を考慮して標準フレーム時間Ｓを決定する（ステップＢ７）。そして、参加プレーヤの各ゲーム端末１０に対して、他の参加プレーヤのゲーム端末１０や通信ホスト、標準フレーム時間Ｓ等を通知する（ステップＢ９）。

各ゲーム端末１０は、ロビーサーバ６０からのこの通知を受信すると（ステップＡ３）、自端末が通信ホストであるならば（ステップＡ５：ＹＥＳ）、ホスト機能及びクライアント機能を有効にし（ステップＡ７）、他のゲーム端末１０からの接続を待つ（ステップＡ９）。自端末が通信ホストでないならば（ステップＡ５：ＮＯ）、クライアント機能を有効にし（ステップＡ１５）、通信ホストに接続する（ステップＡ１７）。

その後、ロビーサーバ６０は、適当なタイミングで各ゲーム端末１０にゲーム開始指示を通知する（ステップＢ１１）。そして、ゲーム端末１０は、このゲーム開始指示を受信すると（ステップＡ１１，Ａ１９）、ゲーム中処理を開始する。即ち、自端末が通信ホストである場合には、ホスト部２２０がホスト処理の実行を開始するとともに、クライアント部２３０がクライアント処理の実行を開始する（ステップＡ１３）。また、自端末が通信ホストでない場合には、クライアント部２３０がクライアント処理の実行を開始する（ステップＡ２１）。

図２４は、クライアント処理の流れを説明するためのフローチャートである。この処理は、クライアント部２３０がクライアントプログラム４１４に従った処理を行うことで実現される。同図によれば、先ず、フレーム時間補正部２３２が補正準備処理を実行する（ステップＣ１）。

図２５は、補正準備処理の流れを説明するためのフローチャートである。同図によれば、フレーム時間補正部２３２は、待ちフレーム数Ｗの値を判定し、この値が「０」より大きいならば（ステップＤ１：ＹＥＳ）、現サイクルにおいてフレーム時間Ｔを長くさせる平滑化処理を行うことを示すよう、平滑化フラグを「１」に設定する（ステップＤ３）。そして、待ちフレーム数Ｗを基に、式（２）に示した算出式に従って伸延時間ΔＴを算出する（ステップＤ５）。

一方、待ちフレーム数Ｗが「０」より小さい、即ち「０」であるならば（ステップＤ１：ＮＯ）、フレーム時間補正部２３２は、待ち情報４２６を参照して、現サイクルから２サイクル前の各クライアントでの待ちフレーム数Ｗ_−２の内から、最大数を最大待ちフレーム数Ｗ_ｍａｘとして選択する（ステップＤ７）。次いで、この最大待ちフレーム数Ｗ_ｍａｘから、自機の現サイクルから２サイクル前の待ちフレーム数Ｗ_−２を減算して、差分フレーム数ｄを算出する（ステップＤ９）。

そして、算出した差分フレーム数ｄが「０」より大きいならば（ステップＤ１１：ＹＥＳ）、フレーム時間補正部２３２は、式（３ａ）〜（３ｈ）に示した、差分フレーム数ｄに応じた算出式に従って目標時間Ｎを算出する（ステップＤ１３）。
以上の処理を行うと、フレーム時間補正部２３２は、補正準備処理を終了する。

補正準備処理が終了すると、続いて、クライアント部２３０は、待ちフレーム数Ｗを「０」に、各サイクルの先頭からの経過サイクル数を表す変数ｉを「１」に更新する（ステップＣ３）。その後、ループＡの処理を、補正フレーム時間Ｕの時間間隔で繰り返し実行する。

ループＡでは、先ず、待ちフレーム数Ｗの値を判断し、その値が「０」に等しいならば（ステップＣ５：ＹＥＳ）、フレーム時間補正部２３２が、フレーム時間補正処理を実行して補正フレーム時間Ｕを算出する（ステップＣ７）。このステップＣ５での判定により、現状が待ち状態であるか否かが判断され、待ち状態である場合にはフレーム時間Ｔの補正（調整）が行われない。

図２６は、フレーム時間補正処理の流れを説明するためのフローチャートである。同図によれば、フレーム時間補正部２３２は、平滑化フラグの設定値を判定し、「１」に設定されているならば（ステップＥ１：ＹＥＳ）、フレーム時間Ｔを長くさせる調整を行うと判断して、前フレームの実フレーム時間Ｔに伸延時間ΔＴを加算して補正フレーム時間Ｕを算出する（ステップＥ３）。

一方、平滑化フラグが「０」に設定されているならば（ステップＥ１：ＮＯ）、フレーム時間補正部２３２は、フレーム時間Ｔを短くさせる調整を行なうと判断して、差分フレーム数ｄの値を判定し、この値が「０」より大きいならば（ステップＥ５：ＮＯ）、前フレーム時間Ｔと目標時間Ｎとを加算平均して補正フレーム時間Ｕを算出する（ステップＥ７）。また、差分フレーム数ｄが「０」より小さい、即ち「０」に等しいならば（ステップＥ５：ＮＯ）、補正フレーム時間Ｕを標準フレーム時間Ｓとする（ステップＥ９）。

その後、フレーム時間補正部２３２は、算出した補正フレーム時間Ｕに対するクリッピング処理を行う。即ち、補正フレーム時間Ｕが「Ｓ／２」より小さいならば（ステップＥ１１：ＹＥＳ）、この補正フレーム時間Ｕを「Ｓ／２」に変更する（ステップＥ１３）。また、補正フレーム時間Ｕが「２×Ｓ」より大きいならば（ステップＥ１５：ＹＥＳ）、この補正フレーム時間Ｕを「２×Ｓ」に更新する（ステップＥ１７）。
以上の処理を行うと、フレーム時間補正部２３２は、フレーム時間補正処理を終了する。

フレーム時間補正処理が終了すると、クライアント部２３０は、操作入力部１００からコマンドが入力されたか否かを判断し、入力されたならば（ステップＣ９：ＹＥＳ）、その入力されたコマンドをホストに送信する（ステップＣ１１）。

また、クライアント部２３０は、ホストから配信されてくるデータを受信したか否かを判断し、受信したならば（ステップＣ１３：ＹＥＳ）、その受信したデータを記憶する（ステップＣ１５）。即ち、入力コマンドを受信したならば、該入力コマンドを、その送信元のゲーム端末１０に該当する受信コマンドデータ４２５において、該当するサイクルの入力コマンドとして格納する。また、同期データＤを受信したならば、該同期データＤの送信元のゲーム端末１０に該当する受信コマンドデータ４２５において、該当するサイクルの完了フラグを「１」にするとともに、該同期データＤに含まれている待ちフレーム数Ｗを、該ゲーム端末１０に該当する待ちデータ４２７に、該当するサイクルの待ちフレーム数として追加する。

続いて、クライアント部２３０は、変数ｉの値を判断し、その値が１サイクル当たりのフレーム数Ｉ以下ならば（ステップＣ１７：ＹＥＳ）、受信コマンド情報４２４を参照し、現サイクルから２サイクルおいて前（３サイクル前）のサイクルでの各ゲーム端末１０での入力コマンドを基に各プレーヤのユニットの制御等を行い、画像生成部２４０にフレーム画像を生成させ、画像表示部３４０に表示させる（ステップＣ１９）。

その後、クライアント部２３０は、変数ｉを「１」加算した値に更新する（ステップＥ２１）。そして、更新後の変数ｉが１サイクル当たりのフレーム数Ｉより小さいならば（ステップＥ２３：ＮＯ）、ステップＣ５に戻り、次フレームについてのループＡの処理を開始する。このステップＣ２３の判定により、１サイクル相当分のゲーム進行処理（Ｉ枚のフレーム画像の生成・表示等）が行われたか否かが判断される。

一方、変数ｉの値がＩより大きいならば（ステップＣ２３：ＹＥＳ）、クライアント部２３０は、受信コマンド情報４２４を参照して、現サイクルから２サイクル前の同期データＤを全クライアントについて受信済みであるか否かを判断する。受信済みでないならば（ステップＣ２５：ＮＯ）、待ちフレーム数Ｗを「１」加算した値に更新した後（ステップＣ２７）、ステップＣ５に戻り、次フレームについてのループＡの処理を開始する。一方、受信済みであるならば（ステップＣ２５：ＹＥＳ）、ループＡを終了する。

ループＡを終了すると、クライアント部２３０は、現サイクルが終了したことを示す同期データＤを待ちフレーム数Ｗとともにホストに送信する（ステップＣ２９）。その後、ゲーム終了であるか否かを判断し、終了しないならば（ステップＣ３１：ＮＯ）、次サイクルを新たな現サイクルとし（ステップＣ３３）、ステップＣ１に戻る。ゲームを終了するならば（ステップＣ３１：ＹＥＳ）、本クライアント処理を終了する。

［作用・効果］
以上のように、本実施形態によれば、ゲームシステム１を構成するクライアントにおいて待ちが発生すると、該クライアントでは、その次サイクルにおいて、フレーム時間Ｔを徐々に長くする平滑化処理が行われる。具体的には、発生した待ちフレーム数Ｗに応じた伸延時間ΔＴが算出され、フレーム毎に、その前フレームの実フレーム時間Ｔにこの伸延時間ΔＴが加算されて補正フレーム時間Ｕが算出される。この平滑化処理によれば、待ちが発生したクライアントにおいて、発生した待ちフレーム数Ｗに応じてフレーム時間Ｔが徐々に長くされることで、該クライアントにおいて以降発生するであろう待ちが抑制され、その結果、待ちの発生によるゲーム画面の一時停止といった事態の防止が実現される。

また、平滑化処理が行われていないサイクルにおいては、フレーム時間Ｔを徐々に短くする最適化処理が行われる。具体的には、該サイクルの２サイクルおいて前（３サイクル前）の各クライアントで発生した待ちフレーム数Ｗに応じて目標時間Ｎが算出される。そして、フレーム毎に、その前フレームの実フレーム時間と目標時間Ｎとを加算平均して補正フレーム時間Ｕが算出される。この最適化処理によれば、上記平滑化処理により長くされた各クライアントのフレーム時間Ｔを短くさせ、標準フレーム時間Ｓに近い値に戻すことが可能となる。

［変形例］
尚、本発明の適用は、上述した実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で適宜変更可能である。

本実施形態のゲームシステムの構成例。 ゲームマップの一例。 コマンドの一例。 ゲーム中におけるゲーム端末の論理的な接続構成例。 ゲーム端末が有する機能図。 ゲーム中におけるゲーム端末間の通信構成例。 ホスト・クライアント間の通信手順の説明図。 ホスト・クライアント間の通信手順の説明図。 クライアントにおける待ちの発生の説明図。 平滑化処理の説明図。 平滑化処理によるフレーム時間Ｔ_ｉの一例。 平滑化処理の実現例。 最適化処理の説明図。 最適化処理の説明図。 最適化処理によるフレーム時間Ｔ_ｉの一例。 最適化処理の実現例。 ゲーム端末の機能構成例。 受信コマンド情報のデータ構成例。 待ち情報のデータ構成例。 平滑化情報のデータ構成例。 最適化情報のデータ構成例。 サイクル進行情報のデータ構成例。 ゲーム処理全体の流れ図。 ゲーム処理中に実行されるクライアント処理の流れ図。 クライアント処理中に実行される補正準備処理の流れ図。 クライアント処理中に実行されるフレーム時間補正処理の流れ図。

符号の説明

１ ゲームシステム
１０ ゲーム端末
１００ 操作入力部
２００ 処理部
２１０ ゲーム演算部
２２０ ホスト部
２３０ クライアント部
２３２ フレーム時間補正部
２４０ 画像生成部
２５０ 音生成部
３４０ 画像表示部
３５０ 音出力部
４００ 記憶部
４１０ ゲームプログラム
４１２ ホストプログラム
４１４ クライアントプログラム
４２２ 参加ゲーム端末情報
４２４ 受信コマンド情報
４２６ 待ち情報
４２８ 平滑化情報
４３２ 最適化情報
４３４ サイクル進行情報
５００ 通信部
６０ ロビーサーバ
Ｎ 通信ネットワーク

Claims (7)

1. クライアント機であるコンピュータに、自機に操作入力された入力コマンド及び自機における待ち状態の状況を示す待ち状況情報をホスト機に送信させるとともに、前記ホスト機から配信されてきた全クライアント機の入力コマンド及び待ち状況情報に基づき、可変のフレーム時間間隔でフレーム画像を表示制御させていくことで、他のクライアント機との間で行うネットワークゲームの進行を制御させるためのプログラムであって、
   前記ホスト機からの入力コマンドの配信待ちによるフレーム画像の表示制御の待ち状態の発生を検出し、発生した待ち状態の継続時間である待ち時間を検出する待ち状態検出手段、
   前記待ち状態検出手段により検出された待ち時間を前記待ち状況情報に含めて前記ホスト機に送信する待ち状況送信手段、
   前記ホスト機から配信されてきた待ち状況情報を基に相対的に他のクライアント機を待たせている時間を判定し、この判定時間に基づいて前記フレーム時間を短くさせる程度を決定して前記フレーム時間を短くさせるフレーム時間短縮化手段、
   として前記コンピュータを機能させるためのプログラム。
2. 前記フレーム時間短縮化手段が、前記ホスト機から配信されてきた他のクライアント機の待ち状況情報に含まれる待ち時間の内、最大の待ち時間と自機の待ち時間との差分を、相対的に他のクライアント機を待たせている時間と判定する、ように前記コンピュータを機能させるための請求項１に記載のプログラム。
3. 前記待ち状態検出手段による検出に応じて、前記フレーム時間を長くさせるフレーム時間長期化手段として前記コンピュータを更に機能させるための請求項１又は２に記載のプログラム。
4. 予め設定された連続するｎ枚（ｎは１以上の整数）のフレーム画像を生成して表示制御する期間であるサイクル期間毎に、前記待ち状態検出手段が待ち状態の発生を検出し、前記待ち状況送信手段が待ち状況情報を前記ホスト機に送信する、
   ように前記コンピュータを機能させるための請求項１〜３の何れか一項に記載のプログラム。
5. 前記フレーム時間短縮化手段が、前記フレーム時間を漸次短くさせるように前記コンピュータを機能させるための請求項１〜４の何れか一項に記載のプログラム。
6. 請求項１〜５の何れか一項に記載のプログラムを記憶したコンピュータ読み取り可能な情報記憶媒体。
7. 自機に操作入力された入力コマンド及び自機における待ち状態の状況を示す待ち状況情報をホスト機に送信するとともに、前記ホスト機から配信されてきた全クライアント機の入力コマンド及び待ち状況情報に基づき、可変のフレーム時間間隔でフレーム画像を表示制御させていくことで、他のクライアント機との間で行うネットワークゲームの進行を制御させるクライアント機であるゲーム装置であって、
   前記ホスト機からの入力コマンドの配信待ちによるフレーム画像の表示制御の待ち状態の発生を検出し、発生した待ち状態の継続時間である待ち時間を検出する待ち状態検出手段と、
   前記待ち状態検出手段により検出された待ち時間を前記待ち状況情報に含めて前記ホスト機に送信する待ち状況送信手段と、
   前記ホスト機から配信されてきた待ち状況情報を基に相対的に他のクライアント機を待たせている時間を判定し、この判定時間に基づいて前記フレーム時間を短くさせる程度を決定して前記フレーム時間を短くさせるフレーム時間短縮化手段と、
   を備えたゲーム装置。

Images