JP3888629B2 - データ書き込みプログラム、ゲームシステムおよびデータ書き込み方法 - Google Patents
データ書き込みプログラム、ゲームシステムおよびデータ書き込み方法 Download PDFInfo
- Publication number
- JP3888629B2 JP3888629B2 JP2002334113A JP2002334113A JP3888629B2 JP 3888629 B2 JP3888629 B2 JP 3888629B2 JP 2002334113 A JP2002334113 A JP 2002334113A JP 2002334113 A JP2002334113 A JP 2002334113A JP 3888629 B2 JP3888629 B2 JP 3888629B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- game
- writing
- game machine
- updated
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
- A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
- A63F2300/55—Details of game data or player data management
- A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
- A63F2300/558—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history by assessing the players' skills or ranking
Description
【０００１】
【発明の属する技術分野】
本発明は、データ書き込みプログラム、ゲームシステムおよびデータ書き込み方法に関し、より特定的には、ゲーム機間のデータ通信によってやりとりされたデータに基づいて更新されたゲームデータを、電気的に書き換え可能な不揮発性メモリに書き込むためのデータ書き込みプログラム、ゲームシステムおよびデータ書き込み方法に関する。
【０００２】
【従来の技術】
従来、ゲーム機間のデータ通信によってやりとりされたデータに基づいて、各ゲーム機で個別に保持しているゲームデータを更新するゲームシステムがある（例えば、特許文献１参照。）。このようなゲームシステムによれば、例えば、あるゲーム機において、ゲーム中に特定のキャラクタが出現したときに、通信によってこのキャラクタに関する情報を他のゲーム機に送信することにより、そのキャラクタを他のゲーム機にも登場させることができる。
【０００３】
さらに、このようなゲームシステムを利用すれば、あるゲーム機で出現したキャラクタやアイテムを、他のゲーム機に移動させたり、他のゲーム機で出現したキャラクタやアイテムと交換したりすることも可能となる。以下、従来のゲームシステムにおいて、第１ゲーム機から第２ゲーム機へキャラクタＡを移動させるときの処理の流れを図１４に示すフローチャートを参照して説明する。
【０００４】
第１ゲーム機および第２ゲーム機において、キャラクタＡの移動を開始する前に、まず、更新前のゲームデータがバックアップメモリにセーブされる（Ｓ９１１、Ｓ９２１）。これは、キャラクタＡの移動処理が何らかの原因によって失敗に終わったときに、ゲームデータが完全に消滅してしまうことを防ぐためである。第１ゲーム機の更新前のゲームデータには、キャラクタＡが存在し、第２ゲーム機の更新前のゲームデータには、キャラクタＡは存在しない。続いて、第１ゲーム機から第２ゲーム機へキャラクタＡに関するキャラクタ情報が送信される（Ｓ９１２、Ｓ９２２）。そして、各ゲーム機では、通信によってやり取りされたキャラクタＡのデータに基づいて、ワークＲＡＭ上でゲームデータが更新される（Ｓ９１３、Ｓ９２３）。すなわち、第１ゲーム機では、キャラクタＡを消去するようにゲームデータが更新され、第２ゲーム機では、キャラクタＡを追加するようにゲームデータが更新される。ゲームデータの更新が完了すると、続いて各ゲーム機において、更新後のゲームデータがバックアップメモリにセーブされる（Ｓ９１４、Ｓ９２４）。このとき、各ゲーム機では、図１５に示すように、ステップＳ９１１およびステップＳ９２１でセーブした更新前のゲームデータを上書きしないような領域に、更新後のゲームデータが書き込まれる。この結果、第１ゲーム機のバックアップメモリには、キャラクタＡが存在しないゲームデータが記憶され、第２ゲーム機のバックアップメモリには、キャラクタＡが存在するゲームデータが記憶される。以上のようにして第１ゲーム機から第２ゲーム機へキャラクタＡが移動される。キャラクタの交換についても同様である。
【０００５】
【特許文献１】
特開２００２-２０４８９３号公報
【０００６】
【発明が解決しようとする課題】
ところが、前述のキャラクタＡの移動処理の例では、ステップＳ９１２およびステップＳ９２２でゲームデータのやりとりが完了後、いずれかのゲーム機において、何らかの原因によって（例えば、セーブ中にプレイヤによって電源が切られることによって）更新後のゲームデータが正常にセーブできなかった場合、キャラクタＡが完全に消滅してしまったり、キャラクタＡの複製が生成されてしまったりといった問題が発生することが判明した。
【０００７】
例えば、図１６の（ａ）に示すように、ゲームデータの更新処理が開始されてから（時刻ｔ０）各ゲーム機において更新後のセーブデータがバックアップメモリに書き込まれるまで（時刻ｔ１）の期間において、電源が切られるなどによって第２ゲーム機の処理が異常終了してしまった場合、第１ゲーム機ではセーブが成功し、第２ゲーム機ではセーブが失敗する。第１ゲーム機では、セーブが正常に完了したため、次回のゲーム処理では更新後のゲームデータがバックアップメモリより読み出される。一方、第２ゲーム機では、セーブの失敗によって更新後のゲームデータは消失してしまったので、次回のゲーム処理ではステップＳ９２１でセーブしておいた更新前のゲームデータがバックアップメモリより読み出される。その結果、図１６の（ｂ）に示すように、第１ゲーム機にも第２ゲーム機にもキャラクタＡが存在せず、キャラクタＡが完全に消滅してしまうことになる。
【０００８】
また例えば、図１７の（ａ）に示すように、時刻ｔ０〜時刻ｔ１の期間において、第１ゲーム機の処理が異常終了してしまった場合には、第１ゲーム機ではセーブが失敗し、第２ゲーム機ではセーブが成功する。第１ゲーム機では、セーブの失敗によって更新後のゲームデータは消失してしまったので、次回のゲーム処理ではステップＳ９１１でセーブしておいた更新前のゲームデータがバックアップメモリより読み出される。一方、第２ゲーム機では、セーブが正常に完了したため、次回のゲーム処理では更新後のゲームデータがバックアップメモリより読み出される。その結果、図１７の（ｂ）に示すように、第１ゲーム機にも第２ゲーム機にもキャラクタＡが存在し、キャラクタＡの複製が生成されてしまうことになる。特に、キャラクタＡがゲーム中でめったに出現しないような貴重なキャラクタである場合には、プレイヤが故意に第１ゲーム機の電源を切ってキャラクタＡの複製を生成することもあり得る。そうなれば、ゲームの面白みが失われてしまうことになる。
【０００９】
このように、一方のゲーム機でセーブが失敗し、他方のゲーム機でセーブが成功した場合には、データが消滅したりデータの複製が生成されたりといった問題が生じる。なお、第１ゲーム機および第２ゲーム機の双方でセーブに失敗した場合には、いずれのゲーム機においても、次回のゲーム処理では更新前のゲームデータがバックアップメモリより読み出されるため、データが消滅したりデータの複製が生成されたりといった問題は生じない。
【００１０】
それゆえに本発明は、各ゲーム機において、データ通信によってやりとりされたデータに基づいて更新されたゲームデータを、電気的に書き換え可能な不揮発性メモリに書き込むときに、あるゲーム機ではセーブに失敗し、他のゲーム機ではセーブに成功するといった状況が発生する可能性を低減することのできるデータ書き込みプログラム、ゲームシステムおよびデータ書き込み方法を提供することを目的とする。
【００１１】
【課題を解決するための手段および発明の効果】
本発明は、上記の課題を解決するために以下のような構成を採用した。なお、括弧内の参照符号等は、本発明の理解を助けるために後述する実施形態との対応関係を示したものであり、本発明の範囲を何ら限定するものではない。
【００１２】
本発明のデータ書き込みプログラムは、第１ゲーム機（１００ａ）に通信可能に接続された第２ゲーム機（１００ｂ）との間のデータ通信によってやりとりされたデータ（キャラクタ情報）に基づいて更新されたゲームデータを、この第１ゲーム機に接続された電気的に書き換え可能な不揮発性メモリ（２２）に書き込むためのプログラムである。このデータ書き込みプログラムは、第１ゲーム機のコンピュータ（ＣＰＵ１１）に、第１書き込みステップ（Ｓ１５、Ｓ２５）と、第１書き込み完了通知送信ステップ（Ｓ１６、Ｓ２６）と、第１書き込み完了通知受信ステップ（Ｓ１６、Ｓ２６）と、第２書き込みステップ（Ｓ１７、Ｓ２７）とを実行させる。第１書き込みステップでは、更新後のゲームデータが、所定の部分（５３）を除いて不揮発性メモリに書き込まれる。第１書き込み完了通知送信ステップでは、上記の第１書き込みステップの書き込みが完了したときに、第２ゲーム機に第１書き込み完了通知が送信される。第１書き込み完了通知受信ステップでは、第２ゲーム機から第１書き込み完了通知が受信される。第２書き込みステップでは、第２ゲーム機に第１書き込み完了通知が送信され、かつ第２ゲーム機から第１書き込み完了通知が受信された後に、上記の所定部分のゲームデータが不揮発性メモリに書き込まれる。これにより、各ゲーム機は、更新されたゲームデータの一部の書き込みが完了したことを互いに確認してから残りの部分を書き込むので、何ら確認することなく更新後のゲームデータの全てが書き込まれる場合と比較して、一方のゲーム機ではセーブに失敗し、かつ他方のゲーム機ではセーブに成功するといった状況が発生する可能性をより低減することができる。
【００１３】
なお、上記の所定部分のデータサイズが、不揮発性メモリに対して書き込み可能な最小単位のデータサイズであってもよい。これにより、第２書き込みステップで書き込むべきデータのサイズが最小限となるので、ゲームデータの一部の書き込みが完了したことを互いに確認してから全てのゲームデータの書き込みが完了するまでの期間を最小限の期間とすることができる。その結果、一方のゲーム機ではセーブに失敗し、かつ他方のゲーム機ではセーブに成功するといった状況が発生する可能性を最小限に抑えることができる。
【００１４】
また、上記の所定部分のデータが、更新後のゲームデータの書き込みが正常に完了したことを示す書き込み完了データ（５３）であってもよい。これにより、不揮発性メモリに書き込まれたゲームデータを読み出す際に、書き込み完了データを参照することで、そのゲームデータが最後まで正常に書き込まれたものであるか否かを確実に識別することができる。また、第２書き込みステップで書き込むべきデータが書き込み完了データのみとなるので、ゲームデータの一部の書き込みが完了したことを互いに確認してから全てのゲームデータの書き込みが完了するまでの期間が短くなる。その結果、一方のゲーム機ではセーブに失敗し、かつ他方のゲーム機ではセーブに成功するといった状況が発生する可能性を低減することができる。なお、書き込み完了データの例としては、パリティチェックやチェックサムやＣＲＣのデータが挙げられる。
【００１５】
また、更新後のゲームデータが、不揮発性メモリにおいて、最近に書き込まれたゲームデータが上書きされないような領域に書き込まれてもよい。これにより、更新後のゲームデータの書き込みが書き込み途中で失敗してしまった場合であっても、不揮発性メモリに最近に書き込まれたゲームデータは残るので、ゲームデータが完全に消失してしまうことがない。しかも、一方のゲーム機では書き込みに成功し、かつ他方のゲーム機では書き込みに失敗するといった状況が発生する可能性を低減することができる。したがって、書き込みに失敗したゲーム機が、次回のゲーム処理において更新以前のゲームデータを利用することに起因した問題（特定のゲームデータが消滅してしまう問題や、特定のゲームデータの複製が生成されてしまう問題）が発生する可能性を低減することができる。
【００１６】
また、上記のデータ書き込みプログラムが、コンピュータ読取可能な記録媒体（２００ａ）に格納された状態でコンピュータに供給されてもよい。
【００１７】
本発明のゲームシステムは、通信可能に接続された少なくとも２台のゲーム機（１００ａ、１００ｂ）が個別に保持しているゲームデータを、これらゲーム機間のデータ通信によってやりとりされたデータ（キャラクタ情報）に基づいてそれぞれ更新し、更新後のゲームデータを各ゲーム機に接続された電気的に書き換え可能な不揮発性メモリ（２２）にそれぞれ書き込むシステムである。このゲームシステムでは、各ゲーム機が、揮発性メモリ（１２）と、データ更新手段（ステップＳ１３を実行するＣＰＵ１１；以下、単にステップ番号のみを示す）と、第１書き込み手段（Ｓ１５）と、第１書き込み完了通知送信手段（Ｓ１６）と、第１書き込み完了通知受信手段（Ｓ１６）と、第２書き込み手段（Ｓ１７）とをそれぞれ備える。揮発性メモリは、ゲーム処理の過程で生成されたゲームデータを一時的に記憶する。データ更新手段は、データ通信によってやり取りされたデータに基づいて揮発性メモリに記憶されているゲームデータを更新する。第１書き込み手段は、更新後のゲームデータを、所定部分（５３）を除いて不揮発性メモリに書き込む。第１書き込み完了通知送信手段は、第１書き込み手段による書き込みが完了したときに、他のゲーム機に第１書き込み完了通知を送信する。第１書き込み完了通知受信手段は、他のゲーム機から第１書き込み完了通知を受信する。第２書き込み手段は、他のゲーム機に第１書き込み完了通知が送信され、かつ他のゲーム機から第１書き込み完了通知が受信された後に、上記の所定部分のゲームデータを不揮発性メモリに書き込む。これにより、一方のゲーム機ではセーブに失敗し、かつ他方のゲーム機ではセーブに成功するといった状況が発生する可能性をより低減することができる。
【００１８】
本発明のデータ書き込み方法は、通信可能に接続された少なくとも２台のゲーム機（１００ａ、１００ｂ）において、これらゲーム機間のデータ通信によってやりとりされたデータ（キャラクタ情報）に基づいて更新されたゲームデータを、各ゲーム機に接続された電気的に書き換え可能な不揮発性メモリ（２２）にそれぞれ書き込むためのデータ書き込み方法である。このデータ書き込み方法は、各ゲーム機において、更新後のゲームデータを不揮発性メモリに書き込むときに、この更新後のゲームデータを、第１書き込み処理と第２書き込み処理の２回に分けて書き込み、第１書き込み処理が完了したときに、その旨を他のゲーム機に通知し、他のゲーム機からの第１書き込み処理の完了の通知に基づいて各ゲーム機において第１書き込み処理が完了したことが確認された後、第２書き込み処理を開始する。これにより、一方のゲーム機ではセーブに失敗し、かつ他方のゲーム機ではセーブに成功するといった状況が発生する可能性をより低減することができる。
【００１９】
【発明の実施の形態】
以下、本発明の一実施形態について図面を参照して説明する。
図１に、本発明の一実施形態に係るゲームシステムの外観を示す。図１において、第１ゲーム機１００ａと、第２ゲーム機１００ｂとが通信ケーブル３００を介して通信可能に接続される。また、第１ゲーム機１００ａおよび第２ゲーム機１００ｂには、ゲームカートリッジ２００ａ、２００ｂが必要に応じてそれぞれ接続される。
【００２０】
図２に、第１ゲーム機１００ａおよびゲームカートリッジ２００ａの内部構成を示す。なお、第２ゲーム機１００ｂおよびゲームカートリッジ２００ｂについては、第１ゲーム機１００ａおよびゲームカートリッジ２００ａと同じ構成を有しているため、説明を省略する。第１ゲーム機１００ａには、各種のプログラムを実行するＣＰＵ１１や、ＣＰＵ１１が扱うデータを一時的に記憶するワークメモリ１２や、画像データを一時的に記憶するＶＲＡＭ１３や、ゲームカートリッジ２００ａとの間でデータのやり取りを可能にする外部メモリＩ／Ｆ１４や、プレイヤによって操作される操作ボタン（十字キー、Ａボタン、Ｂボタンなど）１６や、操作ボタンの状態をデータとして入力するためのコントローラＩ／Ｆ１５や、画像を表示するための液晶モニタ１８や、画像データに基づいて液晶モニタ１８を駆動するための液晶ドライバ１７や、他のゲーム機と通信を行うための通信ポート１９が設けられている。外部メモリＩ／Ｆ１４は、ゲームカートリッジ２００ａに接続され、通信ポート１９は、通信ケーブル３００を通じて第２ゲーム機１００ｂの通信ポートに接続される。ゲームカートリッジ２００ａには、各種プログラム等が予め格納されたプログラムＲＯＭ２１と、ゲーム処理の過程で生成されたゲームデータを必要に応じて記憶するためのバックアップメモリ２２が一体的に設けられている。バックアップメモリ２２は、例えばフラッシュメモリやＥＥＰＲＯＭやＦｅＲＡＭといった、電気的に書き換え可能な不揮発性メモリである。
【００２１】
ゲームカートリッジ２００ａのプログラムＲＯＭ２１には、図３に示すように、ゲームプログラムや、ゲーム画像を生成するときに用いられる画像データや、後述するバックアップ処理を行うためのバックアップ制御プログラムや、後述する更新制御処理を行うための更新制御プログラムなどが格納されている。
【００２２】
ゲームカートリッジ２００ａのバックアップメモリ２２には、図４に示すように、ゲームデータを記憶するための２つのバックアップ領域（第１バックアップ領域、第２バックアップ領域）が確保されている。そして、各領域に対して、第１ゲーム機１００ａのワークメモリ１２に記憶されているゲームデータが交互に書き込まれる。各バックアップ領域に書き込まれるゲームデータには、履歴データ４１〜４３と、書き込み完了バイト５１〜５３が含まれている。履歴データ４１〜４３は、そのゲームデータが過去に更新された回数を示すものである。ワークメモリ１２に記憶されている最新のゲームデータをバックアップする際には、履歴データ４１と履歴データ４２を比較して、バックアップメモリ２２にすでに記憶されている２つのゲームデータのうち、古い方のゲームデータが記憶されている側のバックアップ領域に、最新のゲームデータが書き込まれる（つまり、古いほうのゲームデータが最新のゲームデータによって上書きされる。）。また、書き込み完了バイト５１〜５３は、ゲームデータがバックアップメモリ２２に書き込まれるときに、一番最後に書き込まれる１バイト分のデータである。バックアップメモリ２２からゲームデータを読み出すときに、書き込み完了バイトがセットされているかどうかを確認することによって、そのゲームデータがバックアップメモリ２２に正常に書き込まれたものであるか否かを判別することができる。ワークメモリ１２には、最新のゲームデータを記憶するための領域と、更新制御処理において利用されるフラグデータ６０を記憶するための領域が確保されている。なお、書き込み完了バイトとしては、例えばチェックサムやＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）の値が好ましい。また、本実施例では、書き込み完了バイトとしてＣＲＣチェックサムの値を例にあげて説明するが、例えば交換したキャラクタに関するデータやゲームデータの任意部分のデータであってもよい。
【００２３】
図５に、ゲームデータに含まれるキャラクタ情報を示す。キャラクタ情報とは、ゲーム中に登場しうるキャラクタ（またはアイテム）に関する情報である。キャラクタ情報には、図５に示すように、キャラクタごと、キャラクタの種類を識別するためのキャラクタ識別情報と、キャラクタがゲーム中に登場しているか否か（存在しているか否か）を示す登場フラグと、キャラクタのステータスを示すステータス情報とが含まれる。プレイヤが、新たなキャラクタやアイテムをゲーム中で入手したり、データ通信によって他のプレイヤから入手した場合には、登場フラグがセットされ（例えば１となる）、一方、プレイヤが、すでに入手していたキャラクタやアイテムをゲーム中で手放したり、データ通信によって他のプレイヤに譲った場合には、登場フラグがクリアされる（例えば０となる）。ゲーム機間でキャラクタの交換が行われる際には、まずデータ通信によってキャラクタ識別情報とステータス情報がやりとりされた後、各ゲーム機において、相手側に譲ったキャラクタの登場フラグがクリアされ、相手側から入手したキャラクタの登場フラグがセットされ、その入手したキャラクタのステータス情報が更新される。
【００２４】
図６に、第１ゲーム機１００ａと第２ゲーム機１００ｂとの間でキャラクタを交換するときの、液晶モニタ１８に表示されるゲーム画面例を示す。まず、図６の（ａ）に示すように、キャラクタの交換を行うか否かをプレイヤに確認するための表示がなされる。そして、プレイヤから交換の指示を受けると、図６（ｂ）に示すように、キャラクタを交換する準備のために第１ゲーム機１００ａと第２ゲーム機１００ｂとが通信していることを示す表示がなされる。各ゲーム機における準備が完了すると、図６（ｃ）に示すように、交換するキャラクタ（相手側に譲るキャラクタ）を選択させるための表示がなされる。各ゲーム機において、交換するキャラクタが決定されると、キャラクタ情報をやりとりするためのデータ通信が開始され、図６（ｄ）に示すように、キャラクタを交換中であることを示す表示がなされる。そしてキャラクタの交換が完了すると、図６（ｅ）に示すように、キャラクタの交換が無事完了したことを示す表示がなされる。図６（ｅ）のゲーム画面では、図６（ｃ）のゲーム画面に示されていたキャラクタＡが、キャラクタＢに置き換わっている。
【００２５】
以下、本実施形態における、キャラクタ交換時の処理について説明する。詳細なフローの説明を行う前に、図７〜図１０を参照して、まず本実施形態の処理の概要について説明する。
【００２６】
図７は、第１ゲーム機１００ａから第２ゲーム機１００ｂにキャラクタＡを移動させるときの処理の流れを示している。キャラクタＡの移動処理が開始されると、まず、第１ゲーム機１００ａおよび第２ゲーム機１００ｂは、各ゲーム機のワークメモリに記憶されているゲームデータをバックアップメモリ２２にセーブする（Ｓ１１、Ｓ２１）。その後、キャラクタＡのキャラクタ情報を第１ゲーム機１００ａから第２ゲーム機１００ｂに送信する（Ｓ１２、Ｓ２２）。続いて、各ゲーム機は、ワークメモリに記憶されているゲームデータを更新する（Ｓ１３、Ｓ２３）。具体的には、第１ゲーム機１００ａでは、キャラクタＡの登場フラグがクリアされ、第２ゲーム機１００ｂでは、キャラクタＡの登場フラグがセットされると同時にキャラクタＡのステータス情報が更新される。なお、ここまでの処理については、図１４に示した従来のゲームシステムと同様である。
【００２７】
ワークメモリ上でのゲームデータの更新が完了すると、各ゲーム機は、更新後のゲームデータをバックアップメモリ２２に書き込むのであるが、本実施形態では、更新後のゲームデータが、第１段階の書き込み処理（以下、第１書き込み処理と称す）（Ｓ１５、Ｓ２５）と第２段階の書き込み処理（以下、第２書き込み処理と称す）（Ｓ１７、Ｓ２７）の２回に分けてバックアップメモリ２２に書き込まれる。そして、第２書き込み処理は、ステップＳ１６およびステップＳ２６において、両方のゲーム機において第１書き込み処理が完了したことが通信によって確認されてから開始される。
【００２８】
図８に、更新後のゲームデータがバックアップメモリ２２に書き込まれるときの各ゲーム機の処理の流れを示す。図８の（ａ）に示すように、本実施形態では、時刻ｔ１において、両方のゲーム機において第１書き込み処理が完了したことを通信によって確認した後に、第２書き込み処理が開始される。ここで、第１書き込みの途中で第１ゲーム機の電源が切られることによって第１ゲーム機の処理が異常終了してしまった場合、第１ゲーム機ではデータの書き込みに失敗してしまう。一方、第２ゲーム機は、両方のゲーム機において第１書き込み処理が完了したことを確認することができないので、第２書き込みを実行することができず、第２ゲーム機でもデータの書き込みに失敗してしまう。その結果、いずれのゲーム機においても、次回のゲーム処理では更新前のゲームデータがバックアップメモリより読み出されるため、従来のゲームシステムのようにデータが消滅したりデータの複製が生成されたりといった問題は生じない。ただし、異常終了が第２書き込み処理の途中で発生した場合には、従来と同様の問題が発生してしまう。そこで、その可能性をできる限り低減するために、第２書き込み処理の期間をできる限り短くする（つまり、第２書き込み処理において書き込まれるデータサイズをできる限り小さくする）のが好ましい。なお、バックアップメモリ２２に書き込むことができる最小のデータサイズは、例えば１ビットであったり、１バイトであったりと、デバイス毎に異なっているので、第２書き込み処理において書き込まれるデータサイズは、バックアップメモリ２２に書き込むことができる最小のデータサイズとするのが好ましい。
【００２９】
ところで、各ゲーム機において、第１書き込みが同時に完了するとは限らない。データの書き込み速度はバックアップメモリ２２の種類（フラッシュメモリ、ＥＥＰＲＯＭ、ＦｅＲＡＭなど）によって異なり、また、特にフラッシュメモリは、何度もデータを書き換えることによって性能が劣化してデータの書き込み速度が低減するからである。また、各ゲーム機でゲームデータのサイズが異なる場合もある。そこで、図９に示すように、各ゲーム機が第１書き込みを完了した時点で相手のゲーム機に第１書き込み完了通知を送信するようにし、両方のゲーム機が第１書き込み完了通知を送信した時点で第２書き込みを開始するようにすればよい。図９に示す例の場合、第１ゲーム機１００ａは、第１書き込みの途中で第２ゲーム機１００ｂから第１書き込み完了通知を受信し、その後、第１書き込みが完了した時点で第２書き込みを開始する。一方、第２ゲーム機１００ｂは、第１書き込みの完了後、第１ゲーム機１００ａが第１書き込みを完了するまで待機し、第１ゲーム機１００ａからの第１書き込み完了通知を受信後、第２書き込みを開始する。ここで、各ゲーム機は、第１書き込み完了通知の送受信結果に基づいて、図４に示すワークメモリ１２のフラグデータ６０を更新し、このフラグデータを参照して第２書き込みの開始タイミングが決定される。図１０の（ａ）は、第１ゲーム機１００ａが先に第１書き込みを完了したときの、各ゲーム機のフラグデータ６０の変化の様子を示している。フラグデータ６０は、第１ゲーム機の状態を示すフラグと、第２ゲーム機の状態を示すフラグとからなり、図１０の（ａ）に示すように、第１ゲーム機１００ａが第１書き込みを完了したときには、第１ゲーム機１００ａおよび第２ゲーム機ａの双方において、第１ゲーム機の状態を示すフラグを“１”にセットする。その後、第２ゲーム機が第１書き込みを完了したときに、第２ゲーム機の状態を示すフラグが“１”にセットされる。各ゲーム機では、フラグデータ６０において、第１ゲーム機の状態を示すフラグと第２ゲーム機の状態を示すフラグがいずれも“１”になったときに、第２書き込みを開始する。なお、図１０の（ｂ）は、第２ゲーム機１００ｂが先に第１書き込みを完了したときの、フラグデータ６０の変化の様子を示している。
【００３０】
以下、図１１〜図１３に示すフローチャートを参照して、ゲーム機間でキャラクタを交換する際の各ゲーム機の動作をより詳細に説明する。
【００３１】
図１１は、ゲーム処理を実行するときの第１ゲーム機１００ａのＣＰＵ１１の処理の流れを示している。図１１において、ゲーム処理が開始すると、ＣＰＵ１１は、ワークメモリ１２にゲームデータを記憶する（Ｓ１０１）。このゲームデータは、ゲームの進行に応じて適宜更新される。続いて、プレイヤからバックアップの指示があったかどうか判断する（Ｓ１０２）。プレイヤによるバックアップの指示は、操作ボタン１６を通じて行われる。バックアップの指示があった場合は、後述するバックアップ処理を実行後、ステップＳ１０４に進む。一方、バックアップの指示がなかった場合にはステップＳ１０４に進む。ステップＳ１０４では、プレイヤからキャラクタを交換するように指示があったかどうか判断する。交換指示があった場合にはステップＳ１０５に進み、交換指示がなかった場合にはステップＳ１０１に戻る。
【００３２】
キャラクタの交換指示があった場合には、まず後述するバックアップ処理が行われ（Ｓ１０５）、その後、他のゲーム機と接続されているかどうか判断する（Ｓ１０６）。他のゲーム機と接続されていない場合には、接続されるまで待機する。ステップＳ１０６において、他のゲーム機と接続されていることが確認されると、ステップＳ１０７に進む。そして、他のゲーム機において、キャラクタ情報を送受信する準備が完了したかどうか判断し（Ｓ１０７）、他のゲーム機において準備が完了していない場合には、完了するまで待機する。ステップＳ１０７において、他のゲーム機の準備が完了したことが確認されると、プレイヤに、交換するキャラクタ（第２ゲーム機に移動させるキャラクタ）を選択させる（Ｓ１０８）。そして、交換されるキャラクタに関するキャラクタ情報を第２ゲーム機との間で送受信する（Ｓ１０９）。その後、後述する更新制御処理によって、キャラクタ交換後のゲームデータをバックアップメモリ２２に書き込んで（Ｓ１１０）、ステップＳ１０１に戻る。
【００３３】
図１２を参照して、図１１のステップＳ１０３およびステップＳ１０５のバックアップ処理について説明する。バックアップ処理が開始すると、ＣＰＵ１１は、ワークメモリ１２上のゲームデータを書き込むべきバックアップ領域を、図４に示した２つのバックアップ領域のうちから選択する（Ｓ２０１）。このとき、ＣＰＵ１１は、履歴データ４１と履歴データ４２を比較して、より古いゲームデータが格納されているバックアップ領域を選択する。続いて、ワークメモリ１２に記憶されているゲームデータのうち、バックアップメモリ２２の１セクタ分に対応するサイズのデータをバックアップ領域に書き込む（Ｓ２０２）。このとき、図４に示した書き込み完了バイトは最初にクリアされるのが好ましい。そして、その１セクタ分のゲームデータが正常に書き込めたかどうか判断し（Ｓ２０３）、正常に書き込めた場合には、ステップＳ２０５に進む。一方、正常に書き込めなかった場合には、書き込みを繰り返し、その結果、所定の回数以内で正常に書き込めた場合には（ステップＳ２０４でＹＥＳ）、ステップＳ２０５に進む。一方、書き込みを所定の回数繰り返したにも関わらず正常に書き込めなかった場合には（ステップＳ２０４でＮＯ）、エラーがあった旨を液晶モニタ１８に表示して処理を停止する。ステップＳ２０５では、バックアップ領域を構成する全セクタ（例えば１５セクタ）に対するゲームデータの書き込みが終了したかどうか判断し、終了していなかった場合には、ステップＳ２０２に戻って次のセクタ分のゲームデータを書き込む。こうして全て（１５セクタ分）のゲームデータの書き込みが完了すると、バックアップ処理は終了する。
【００３４】
図１３を参照して、図１１のステップＳ１１０の更新制御処理について説明する。更新制御処理が開始すると、まずＣＰＵ１１は、図１１のステップＳ１０９で送受信したキャラクタ情報に基づいて、ワークメモリ１２内のゲームデータを更新する（Ｓ３０１）。具体的には、第２ゲーム機１００ｂに譲ったキャラクタの登場フラグをクリアするとともに、第２ゲーム機１００ｂから受け取ったキャラクタ情報に基づいて、第２ゲーム機１００ｂから入手したキャラクタの登場フラグをセットし、そのキャラクタのステータス情報を更新する。ゲームデータの更新が完了すると、続いて、その更新後のゲームデータを書き込むべきバックアップ領域を、図４に示した２つのバックアップ領域のうちから選択する（Ｓ３０２）。このとき、ＣＰＵ１１は、履歴データ４１と履歴データ４２を比較して、より古いゲームデータが格納されているバックアップ領域を選択する。
【００３５】
続いて、ワークメモリ１２に記憶されている更新後のゲームデータのうち、バックアップメモリ２２の１セクタ分に対応するサイズのデータをバックアップ領域に書き込む（Ｓ３０２）。このとき、図４に示した書き込み完了バイトは最初にクリアされるのが好ましい。そして、次に書き込むべきデータが最後のセクタに対応するデータであるかどうか判断する（Ｓ３０４）。例えばゲームデータが１５セクタ分のデータであって、すでに１４セクタ分のゲームデータが書き込まれている場合、次に書き込むべきデータは最後のセクタに対応するデータとなる。ステップＳ３０４において、次に書き込むべきデータが最後のセクタに対応するデータではなかった場合には、ステップＳ３０３に戻り、次のセクタに対応するデータを書き込む。
【００３６】
ステップＳ３０４において、次に書き込むべきデータが最後のセクタに対応するデータであった場合には、その最後のセクタに対応するデータのうち、１バイト分のデータをバックアップ領域に書き込む（Ｓ３０５）。そして、次に書き込むべきデータが最後の１バイト分のデータ（図４に示した書き込み完了バイト）であるかどうか判断する（Ｓ３０６）。ステップＳ３０６において、次に書き込むべきデータが最後の１バイト分のデータではなかった場合には、ステップＳ３０５に戻り、次の１バイト分のデータを書き込む。ステップＳ３０６において、次に書き込むべきデータが最後の１バイト分のデータであった場合には、第２ゲーム機１００ｂに第１書き込み完了通知を送信し、フラグデータ６０を更新する（Ｓ３０７）。なお、図示は省略するが、各ゲーム機は、更新制御処理の開始後、他のゲーム機から第１書き込み完了通知を受信したかどうかを監視し、他のゲーム機から第１書き込み完了通知を受信したときには、例えば割り込み処理等によってフラグデータ６０を更新する。
【００３７】
第１書き込み完了通知の送信が完了すると、次に、フラグデータ６０を参照して、全てのゲーム機（ここでは第１ゲーム機および第２ゲーム機）において、第１書き込みが完了したかどうか判断し、まだ完了していないゲーム機が存在していた場合には、そのゲーム機が第１書き込みを完了するまで待機する（Ｓ３０８）。一方、全てのゲーム機において第１書き込みが完了していた場合には、最後の１バイト分のデータ（書き込み完了バイト）であるＣＲＣチェックサムの値をバックアップ領域に書き込む。そして、ゲームデータのＣＲＣチェックサムが計算され、その計算値とＣＲＣチェックサムの値とが一致したとき、更新後のゲームデータの全ての書き込みを完了する（Ｓ３０９）。続いて、キャラクタの交換が完了した旨が液晶モニタ１８に表示され（Ｓ３１０）、更新制御処理は終了する。
【００３８】
以上のように、本実施形態によれば、各ゲーム機において第１書き込みが完了したことを確認してから第２書き込みを開始するので、書き込み完了のタイミングをほぼ同時期に終了させることができる。したがって、第１書き込み完了したことの確認がなされる前にいずれかのゲーム機が異常終了した場合には、全てのゲーム機において書き込み処理が失敗に終わる。したがって、あるゲーム機では書き込みに失敗し、かつ他のゲーム機では書き込みに成功するといった状況が発生する可能性が低減されるので、データが消滅したりデータの複製が生成されたりといった問題が発生する可能性が低減される。
【００３９】
なお、本実施形態では、バックアップメモリ２２に書き込まれるゲームデータには、ゲームデータの書き込みが正常に終了したことを示す１バイト分のデータ（書き込み完了バイト）が含まれるとしたが、このデータのサイズは１バイトに限らない。さらに、ゲームデータに、このような“書き込みが正常に終了したことを示すデータ”が含まれていなくてもよい。ただし、このようなデータを利用することにより、ゲームデータを読み出すときに、そのゲームデータが正常に書き込まれたものか否かを容易に判断できる利点がある。
【００４０】
また、本実施形態では、第２書き込み処理において書き込まれるデータのサイズが１バイトであるとしたが、本発明はこれに限らず、第２書き込み処理において書き込まれるデータのサイズが１バイトよりも小さくてもよいし、１バイトよりも大きくてもよい。
【００４１】
また、本実施形態では、２台のゲーム機間でキャラクタ等の交換を行うとしたが、本発明はこれに限らず、３台以上のゲーム機間でキャラクタ等を交換する場合にも容易に適用することが可能であり、その結果、本実施形態と同様の効果を達成することができる。例えば、第１ゲーム機から第２ゲーム機にキャラクタＡを移動させると同時に、第２ゲーム機から第３ゲーム機にキャラクタＢを移動し、さらに同時に第３ゲーム機から第１ゲーム機にキャラクタＣを移動させるような場合であっても、いずれかのキャラクタが消滅したり、その複製が生成されてしまう可能性が低減される。
【００４２】
また、本実施形態では、２台のゲーム機間でキャラクタ等を交換または移動させるとしたが、本発明はこれに限らず、一般に、複数のゲーム機間で、データ通信を通じてデータの一部をやりとりし、そのやり取りされたデータに基づいて各自のゲームデータを更新して不揮発性メモリに書き込む場合に好適に適用される。例えば、各ゲーム機で、プレイヤがゲームをプレイしたときの結果（得点）が得点ランキング表として保存されている場合に、ゲーム機間でこの得点ランキング表のデータをやり取りすることによって、各ゲーム機の得点ランキング表を統合した新たな得点ランキング表を生成し（その結果、複数のプレイヤが同一の得点ランキング表にランクアップされるようになる。）、今まで保存していた得点ランキング表を上書きするような場合にも、本発明は有効である。すなわち、あるゲーム機では更新後の得点ランキング表の書き込みに失敗し、かつ他のゲーム機では更新後の得点ランキング表の書き込みに成功し、各ゲーム機が保持する得点ランキング表の整合性が失われてしまうのを効果的に防止することができる。
【００４３】
また、本実施形態では、２台のゲーム機が通信ケーブル３００を介して通信するとしたが、本発明はこれに限らず、２台のゲーム機がネットワークを介して通信する場合にも本発明を適用することができる。
【００４４】
また、本実施形態では、各種プログラムがゲームカートリッジ２００ａを通じて第１ゲーム機１００ａに供給されるとしたが、本発明はこれに限らず、ＣＤ−ＲＯＭや、ＤＶＤなど、他の任意のコンピュータ読取可能な記録媒体を通じてゲーム機に供給されてもよい。さらには、ネットワークなどの通信回線を通じてゲーム機に供給されてもよい。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るゲームシステムの外観を示す図である。
【図２】第１ゲーム機１００ａおよびゲームカートリッジ２００ａの構成を示すブロック図である。
【図３】プログラムＲＯＭ２１のメモリイメージである。
【図４】バックアップメモリ２２およびワークメモリ１２のメモリイメージである。
【図５】ゲームデータに含まれるキャラクタ情報を示す図である。
【図６】キャラクタ交換時のゲーム画面例を示す図である。
【図７】本発明の一実施形態に係るゲームシステムにおいて、第１ゲーム機１００ａから第２ゲーム機１００ｂにキャラクタＡを移動させるときの処理の流れを示すフローチャートである。
【図８】更新後のゲームデータをバックアップメモリ２２に書き込むときの各ゲーム機における処理の流れを示す図である。
【図９】更新後のゲームデータをバックアップメモリ２２に書き込むときの各ゲーム機における処理の流れを示す図である。
【図１０】フラグデータ６０の変化の様子を示す図である。
【図１１】ＣＰＵ１１によって実行されるゲーム処理の流れを示すフローチャートである。
【図１２】バックアップ処理の流れを示すフローチャートである。
【図１３】更新制御処理の流れを示すフローチャートである。
【図１４】従来のゲームシステムにおいて、第１ゲーム機から第２ゲーム機にキャラクタＡを移動させるときの処理を示すフローチャートである。
【図１５】バックアップメモリにおいて、更新前のゲームデータが格納される領域と、更新後のゲームデータが格納される領域とが異なることを示す図である。
【図１６】従来のゲームシステムにおいて、キャラクタＡが完全に消滅してしまう原理を説明するための図である。
【図１７】従来のゲームシステムにおいて、キャラクタＡの複製が生成されてしまう原理を説明するための図である。
【符号の説明】
１１ ＣＰＵ
１２ ワークメモリ
１３ ＶＲＡＭ
１４ 外部メモリＩ／Ｆ
１５ コントローラＩ／Ｆ
１６ 操作ボタン
１７ 液晶ドライバ
１８ 液晶モニタ
１９ 通信ポート
２１ プログラムＲＯＭ
２２ バックアップメモリ
４１〜４３ 履歴データ
５１〜５３ 書き込み完了バイト
６０ フラグデータ
１００ａ 第１ゲーム機
１００ｂ 第２ゲーム機
２００ａ、２００ｂ ゲームカートリッジ
３００ 通信ケーブル
【発明の属する技術分野】
本発明は、データ書き込みプログラム、ゲームシステムおよびデータ書き込み方法に関し、より特定的には、ゲーム機間のデータ通信によってやりとりされたデータに基づいて更新されたゲームデータを、電気的に書き換え可能な不揮発性メモリに書き込むためのデータ書き込みプログラム、ゲームシステムおよびデータ書き込み方法に関する。
【０００２】
【従来の技術】
従来、ゲーム機間のデータ通信によってやりとりされたデータに基づいて、各ゲーム機で個別に保持しているゲームデータを更新するゲームシステムがある（例えば、特許文献１参照。）。このようなゲームシステムによれば、例えば、あるゲーム機において、ゲーム中に特定のキャラクタが出現したときに、通信によってこのキャラクタに関する情報を他のゲーム機に送信することにより、そのキャラクタを他のゲーム機にも登場させることができる。
【０００３】
さらに、このようなゲームシステムを利用すれば、あるゲーム機で出現したキャラクタやアイテムを、他のゲーム機に移動させたり、他のゲーム機で出現したキャラクタやアイテムと交換したりすることも可能となる。以下、従来のゲームシステムにおいて、第１ゲーム機から第２ゲーム機へキャラクタＡを移動させるときの処理の流れを図１４に示すフローチャートを参照して説明する。
【０００４】
第１ゲーム機および第２ゲーム機において、キャラクタＡの移動を開始する前に、まず、更新前のゲームデータがバックアップメモリにセーブされる（Ｓ９１１、Ｓ９２１）。これは、キャラクタＡの移動処理が何らかの原因によって失敗に終わったときに、ゲームデータが完全に消滅してしまうことを防ぐためである。第１ゲーム機の更新前のゲームデータには、キャラクタＡが存在し、第２ゲーム機の更新前のゲームデータには、キャラクタＡは存在しない。続いて、第１ゲーム機から第２ゲーム機へキャラクタＡに関するキャラクタ情報が送信される（Ｓ９１２、Ｓ９２２）。そして、各ゲーム機では、通信によってやり取りされたキャラクタＡのデータに基づいて、ワークＲＡＭ上でゲームデータが更新される（Ｓ９１３、Ｓ９２３）。すなわち、第１ゲーム機では、キャラクタＡを消去するようにゲームデータが更新され、第２ゲーム機では、キャラクタＡを追加するようにゲームデータが更新される。ゲームデータの更新が完了すると、続いて各ゲーム機において、更新後のゲームデータがバックアップメモリにセーブされる（Ｓ９１４、Ｓ９２４）。このとき、各ゲーム機では、図１５に示すように、ステップＳ９１１およびステップＳ９２１でセーブした更新前のゲームデータを上書きしないような領域に、更新後のゲームデータが書き込まれる。この結果、第１ゲーム機のバックアップメモリには、キャラクタＡが存在しないゲームデータが記憶され、第２ゲーム機のバックアップメモリには、キャラクタＡが存在するゲームデータが記憶される。以上のようにして第１ゲーム機から第２ゲーム機へキャラクタＡが移動される。キャラクタの交換についても同様である。
【０００５】
【特許文献１】
特開２００２-２０４８９３号公報
【０００６】
【発明が解決しようとする課題】
ところが、前述のキャラクタＡの移動処理の例では、ステップＳ９１２およびステップＳ９２２でゲームデータのやりとりが完了後、いずれかのゲーム機において、何らかの原因によって（例えば、セーブ中にプレイヤによって電源が切られることによって）更新後のゲームデータが正常にセーブできなかった場合、キャラクタＡが完全に消滅してしまったり、キャラクタＡの複製が生成されてしまったりといった問題が発生することが判明した。
【０００７】
例えば、図１６の（ａ）に示すように、ゲームデータの更新処理が開始されてから（時刻ｔ０）各ゲーム機において更新後のセーブデータがバックアップメモリに書き込まれるまで（時刻ｔ１）の期間において、電源が切られるなどによって第２ゲーム機の処理が異常終了してしまった場合、第１ゲーム機ではセーブが成功し、第２ゲーム機ではセーブが失敗する。第１ゲーム機では、セーブが正常に完了したため、次回のゲーム処理では更新後のゲームデータがバックアップメモリより読み出される。一方、第２ゲーム機では、セーブの失敗によって更新後のゲームデータは消失してしまったので、次回のゲーム処理ではステップＳ９２１でセーブしておいた更新前のゲームデータがバックアップメモリより読み出される。その結果、図１６の（ｂ）に示すように、第１ゲーム機にも第２ゲーム機にもキャラクタＡが存在せず、キャラクタＡが完全に消滅してしまうことになる。
【０００８】
また例えば、図１７の（ａ）に示すように、時刻ｔ０〜時刻ｔ１の期間において、第１ゲーム機の処理が異常終了してしまった場合には、第１ゲーム機ではセーブが失敗し、第２ゲーム機ではセーブが成功する。第１ゲーム機では、セーブの失敗によって更新後のゲームデータは消失してしまったので、次回のゲーム処理ではステップＳ９１１でセーブしておいた更新前のゲームデータがバックアップメモリより読み出される。一方、第２ゲーム機では、セーブが正常に完了したため、次回のゲーム処理では更新後のゲームデータがバックアップメモリより読み出される。その結果、図１７の（ｂ）に示すように、第１ゲーム機にも第２ゲーム機にもキャラクタＡが存在し、キャラクタＡの複製が生成されてしまうことになる。特に、キャラクタＡがゲーム中でめったに出現しないような貴重なキャラクタである場合には、プレイヤが故意に第１ゲーム機の電源を切ってキャラクタＡの複製を生成することもあり得る。そうなれば、ゲームの面白みが失われてしまうことになる。
【０００９】
このように、一方のゲーム機でセーブが失敗し、他方のゲーム機でセーブが成功した場合には、データが消滅したりデータの複製が生成されたりといった問題が生じる。なお、第１ゲーム機および第２ゲーム機の双方でセーブに失敗した場合には、いずれのゲーム機においても、次回のゲーム処理では更新前のゲームデータがバックアップメモリより読み出されるため、データが消滅したりデータの複製が生成されたりといった問題は生じない。
【００１０】
それゆえに本発明は、各ゲーム機において、データ通信によってやりとりされたデータに基づいて更新されたゲームデータを、電気的に書き換え可能な不揮発性メモリに書き込むときに、あるゲーム機ではセーブに失敗し、他のゲーム機ではセーブに成功するといった状況が発生する可能性を低減することのできるデータ書き込みプログラム、ゲームシステムおよびデータ書き込み方法を提供することを目的とする。
【００１１】
【課題を解決するための手段および発明の効果】
本発明は、上記の課題を解決するために以下のような構成を採用した。なお、括弧内の参照符号等は、本発明の理解を助けるために後述する実施形態との対応関係を示したものであり、本発明の範囲を何ら限定するものではない。
【００１２】
本発明のデータ書き込みプログラムは、第１ゲーム機（１００ａ）に通信可能に接続された第２ゲーム機（１００ｂ）との間のデータ通信によってやりとりされたデータ（キャラクタ情報）に基づいて更新されたゲームデータを、この第１ゲーム機に接続された電気的に書き換え可能な不揮発性メモリ（２２）に書き込むためのプログラムである。このデータ書き込みプログラムは、第１ゲーム機のコンピュータ（ＣＰＵ１１）に、第１書き込みステップ（Ｓ１５、Ｓ２５）と、第１書き込み完了通知送信ステップ（Ｓ１６、Ｓ２６）と、第１書き込み完了通知受信ステップ（Ｓ１６、Ｓ２６）と、第２書き込みステップ（Ｓ１７、Ｓ２７）とを実行させる。第１書き込みステップでは、更新後のゲームデータが、所定の部分（５３）を除いて不揮発性メモリに書き込まれる。第１書き込み完了通知送信ステップでは、上記の第１書き込みステップの書き込みが完了したときに、第２ゲーム機に第１書き込み完了通知が送信される。第１書き込み完了通知受信ステップでは、第２ゲーム機から第１書き込み完了通知が受信される。第２書き込みステップでは、第２ゲーム機に第１書き込み完了通知が送信され、かつ第２ゲーム機から第１書き込み完了通知が受信された後に、上記の所定部分のゲームデータが不揮発性メモリに書き込まれる。これにより、各ゲーム機は、更新されたゲームデータの一部の書き込みが完了したことを互いに確認してから残りの部分を書き込むので、何ら確認することなく更新後のゲームデータの全てが書き込まれる場合と比較して、一方のゲーム機ではセーブに失敗し、かつ他方のゲーム機ではセーブに成功するといった状況が発生する可能性をより低減することができる。
【００１３】
なお、上記の所定部分のデータサイズが、不揮発性メモリに対して書き込み可能な最小単位のデータサイズであってもよい。これにより、第２書き込みステップで書き込むべきデータのサイズが最小限となるので、ゲームデータの一部の書き込みが完了したことを互いに確認してから全てのゲームデータの書き込みが完了するまでの期間を最小限の期間とすることができる。その結果、一方のゲーム機ではセーブに失敗し、かつ他方のゲーム機ではセーブに成功するといった状況が発生する可能性を最小限に抑えることができる。
【００１４】
また、上記の所定部分のデータが、更新後のゲームデータの書き込みが正常に完了したことを示す書き込み完了データ（５３）であってもよい。これにより、不揮発性メモリに書き込まれたゲームデータを読み出す際に、書き込み完了データを参照することで、そのゲームデータが最後まで正常に書き込まれたものであるか否かを確実に識別することができる。また、第２書き込みステップで書き込むべきデータが書き込み完了データのみとなるので、ゲームデータの一部の書き込みが完了したことを互いに確認してから全てのゲームデータの書き込みが完了するまでの期間が短くなる。その結果、一方のゲーム機ではセーブに失敗し、かつ他方のゲーム機ではセーブに成功するといった状況が発生する可能性を低減することができる。なお、書き込み完了データの例としては、パリティチェックやチェックサムやＣＲＣのデータが挙げられる。
【００１５】
また、更新後のゲームデータが、不揮発性メモリにおいて、最近に書き込まれたゲームデータが上書きされないような領域に書き込まれてもよい。これにより、更新後のゲームデータの書き込みが書き込み途中で失敗してしまった場合であっても、不揮発性メモリに最近に書き込まれたゲームデータは残るので、ゲームデータが完全に消失してしまうことがない。しかも、一方のゲーム機では書き込みに成功し、かつ他方のゲーム機では書き込みに失敗するといった状況が発生する可能性を低減することができる。したがって、書き込みに失敗したゲーム機が、次回のゲーム処理において更新以前のゲームデータを利用することに起因した問題（特定のゲームデータが消滅してしまう問題や、特定のゲームデータの複製が生成されてしまう問題）が発生する可能性を低減することができる。
【００１６】
また、上記のデータ書き込みプログラムが、コンピュータ読取可能な記録媒体（２００ａ）に格納された状態でコンピュータに供給されてもよい。
【００１７】
本発明のゲームシステムは、通信可能に接続された少なくとも２台のゲーム機（１００ａ、１００ｂ）が個別に保持しているゲームデータを、これらゲーム機間のデータ通信によってやりとりされたデータ（キャラクタ情報）に基づいてそれぞれ更新し、更新後のゲームデータを各ゲーム機に接続された電気的に書き換え可能な不揮発性メモリ（２２）にそれぞれ書き込むシステムである。このゲームシステムでは、各ゲーム機が、揮発性メモリ（１２）と、データ更新手段（ステップＳ１３を実行するＣＰＵ１１；以下、単にステップ番号のみを示す）と、第１書き込み手段（Ｓ１５）と、第１書き込み完了通知送信手段（Ｓ１６）と、第１書き込み完了通知受信手段（Ｓ１６）と、第２書き込み手段（Ｓ１７）とをそれぞれ備える。揮発性メモリは、ゲーム処理の過程で生成されたゲームデータを一時的に記憶する。データ更新手段は、データ通信によってやり取りされたデータに基づいて揮発性メモリに記憶されているゲームデータを更新する。第１書き込み手段は、更新後のゲームデータを、所定部分（５３）を除いて不揮発性メモリに書き込む。第１書き込み完了通知送信手段は、第１書き込み手段による書き込みが完了したときに、他のゲーム機に第１書き込み完了通知を送信する。第１書き込み完了通知受信手段は、他のゲーム機から第１書き込み完了通知を受信する。第２書き込み手段は、他のゲーム機に第１書き込み完了通知が送信され、かつ他のゲーム機から第１書き込み完了通知が受信された後に、上記の所定部分のゲームデータを不揮発性メモリに書き込む。これにより、一方のゲーム機ではセーブに失敗し、かつ他方のゲーム機ではセーブに成功するといった状況が発生する可能性をより低減することができる。
【００１８】
本発明のデータ書き込み方法は、通信可能に接続された少なくとも２台のゲーム機（１００ａ、１００ｂ）において、これらゲーム機間のデータ通信によってやりとりされたデータ（キャラクタ情報）に基づいて更新されたゲームデータを、各ゲーム機に接続された電気的に書き換え可能な不揮発性メモリ（２２）にそれぞれ書き込むためのデータ書き込み方法である。このデータ書き込み方法は、各ゲーム機において、更新後のゲームデータを不揮発性メモリに書き込むときに、この更新後のゲームデータを、第１書き込み処理と第２書き込み処理の２回に分けて書き込み、第１書き込み処理が完了したときに、その旨を他のゲーム機に通知し、他のゲーム機からの第１書き込み処理の完了の通知に基づいて各ゲーム機において第１書き込み処理が完了したことが確認された後、第２書き込み処理を開始する。これにより、一方のゲーム機ではセーブに失敗し、かつ他方のゲーム機ではセーブに成功するといった状況が発生する可能性をより低減することができる。
【００１９】
【発明の実施の形態】
以下、本発明の一実施形態について図面を参照して説明する。
図１に、本発明の一実施形態に係るゲームシステムの外観を示す。図１において、第１ゲーム機１００ａと、第２ゲーム機１００ｂとが通信ケーブル３００を介して通信可能に接続される。また、第１ゲーム機１００ａおよび第２ゲーム機１００ｂには、ゲームカートリッジ２００ａ、２００ｂが必要に応じてそれぞれ接続される。
【００２０】
図２に、第１ゲーム機１００ａおよびゲームカートリッジ２００ａの内部構成を示す。なお、第２ゲーム機１００ｂおよびゲームカートリッジ２００ｂについては、第１ゲーム機１００ａおよびゲームカートリッジ２００ａと同じ構成を有しているため、説明を省略する。第１ゲーム機１００ａには、各種のプログラムを実行するＣＰＵ１１や、ＣＰＵ１１が扱うデータを一時的に記憶するワークメモリ１２や、画像データを一時的に記憶するＶＲＡＭ１３や、ゲームカートリッジ２００ａとの間でデータのやり取りを可能にする外部メモリＩ／Ｆ１４や、プレイヤによって操作される操作ボタン（十字キー、Ａボタン、Ｂボタンなど）１６や、操作ボタンの状態をデータとして入力するためのコントローラＩ／Ｆ１５や、画像を表示するための液晶モニタ１８や、画像データに基づいて液晶モニタ１８を駆動するための液晶ドライバ１７や、他のゲーム機と通信を行うための通信ポート１９が設けられている。外部メモリＩ／Ｆ１４は、ゲームカートリッジ２００ａに接続され、通信ポート１９は、通信ケーブル３００を通じて第２ゲーム機１００ｂの通信ポートに接続される。ゲームカートリッジ２００ａには、各種プログラム等が予め格納されたプログラムＲＯＭ２１と、ゲーム処理の過程で生成されたゲームデータを必要に応じて記憶するためのバックアップメモリ２２が一体的に設けられている。バックアップメモリ２２は、例えばフラッシュメモリやＥＥＰＲＯＭやＦｅＲＡＭといった、電気的に書き換え可能な不揮発性メモリである。
【００２１】
ゲームカートリッジ２００ａのプログラムＲＯＭ２１には、図３に示すように、ゲームプログラムや、ゲーム画像を生成するときに用いられる画像データや、後述するバックアップ処理を行うためのバックアップ制御プログラムや、後述する更新制御処理を行うための更新制御プログラムなどが格納されている。
【００２２】
ゲームカートリッジ２００ａのバックアップメモリ２２には、図４に示すように、ゲームデータを記憶するための２つのバックアップ領域（第１バックアップ領域、第２バックアップ領域）が確保されている。そして、各領域に対して、第１ゲーム機１００ａのワークメモリ１２に記憶されているゲームデータが交互に書き込まれる。各バックアップ領域に書き込まれるゲームデータには、履歴データ４１〜４３と、書き込み完了バイト５１〜５３が含まれている。履歴データ４１〜４３は、そのゲームデータが過去に更新された回数を示すものである。ワークメモリ１２に記憶されている最新のゲームデータをバックアップする際には、履歴データ４１と履歴データ４２を比較して、バックアップメモリ２２にすでに記憶されている２つのゲームデータのうち、古い方のゲームデータが記憶されている側のバックアップ領域に、最新のゲームデータが書き込まれる（つまり、古いほうのゲームデータが最新のゲームデータによって上書きされる。）。また、書き込み完了バイト５１〜５３は、ゲームデータがバックアップメモリ２２に書き込まれるときに、一番最後に書き込まれる１バイト分のデータである。バックアップメモリ２２からゲームデータを読み出すときに、書き込み完了バイトがセットされているかどうかを確認することによって、そのゲームデータがバックアップメモリ２２に正常に書き込まれたものであるか否かを判別することができる。ワークメモリ１２には、最新のゲームデータを記憶するための領域と、更新制御処理において利用されるフラグデータ６０を記憶するための領域が確保されている。なお、書き込み完了バイトとしては、例えばチェックサムやＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）の値が好ましい。また、本実施例では、書き込み完了バイトとしてＣＲＣチェックサムの値を例にあげて説明するが、例えば交換したキャラクタに関するデータやゲームデータの任意部分のデータであってもよい。
【００２３】
図５に、ゲームデータに含まれるキャラクタ情報を示す。キャラクタ情報とは、ゲーム中に登場しうるキャラクタ（またはアイテム）に関する情報である。キャラクタ情報には、図５に示すように、キャラクタごと、キャラクタの種類を識別するためのキャラクタ識別情報と、キャラクタがゲーム中に登場しているか否か（存在しているか否か）を示す登場フラグと、キャラクタのステータスを示すステータス情報とが含まれる。プレイヤが、新たなキャラクタやアイテムをゲーム中で入手したり、データ通信によって他のプレイヤから入手した場合には、登場フラグがセットされ（例えば１となる）、一方、プレイヤが、すでに入手していたキャラクタやアイテムをゲーム中で手放したり、データ通信によって他のプレイヤに譲った場合には、登場フラグがクリアされる（例えば０となる）。ゲーム機間でキャラクタの交換が行われる際には、まずデータ通信によってキャラクタ識別情報とステータス情報がやりとりされた後、各ゲーム機において、相手側に譲ったキャラクタの登場フラグがクリアされ、相手側から入手したキャラクタの登場フラグがセットされ、その入手したキャラクタのステータス情報が更新される。
【００２４】
図６に、第１ゲーム機１００ａと第２ゲーム機１００ｂとの間でキャラクタを交換するときの、液晶モニタ１８に表示されるゲーム画面例を示す。まず、図６の（ａ）に示すように、キャラクタの交換を行うか否かをプレイヤに確認するための表示がなされる。そして、プレイヤから交換の指示を受けると、図６（ｂ）に示すように、キャラクタを交換する準備のために第１ゲーム機１００ａと第２ゲーム機１００ｂとが通信していることを示す表示がなされる。各ゲーム機における準備が完了すると、図６（ｃ）に示すように、交換するキャラクタ（相手側に譲るキャラクタ）を選択させるための表示がなされる。各ゲーム機において、交換するキャラクタが決定されると、キャラクタ情報をやりとりするためのデータ通信が開始され、図６（ｄ）に示すように、キャラクタを交換中であることを示す表示がなされる。そしてキャラクタの交換が完了すると、図６（ｅ）に示すように、キャラクタの交換が無事完了したことを示す表示がなされる。図６（ｅ）のゲーム画面では、図６（ｃ）のゲーム画面に示されていたキャラクタＡが、キャラクタＢに置き換わっている。
【００２５】
以下、本実施形態における、キャラクタ交換時の処理について説明する。詳細なフローの説明を行う前に、図７〜図１０を参照して、まず本実施形態の処理の概要について説明する。
【００２６】
図７は、第１ゲーム機１００ａから第２ゲーム機１００ｂにキャラクタＡを移動させるときの処理の流れを示している。キャラクタＡの移動処理が開始されると、まず、第１ゲーム機１００ａおよび第２ゲーム機１００ｂは、各ゲーム機のワークメモリに記憶されているゲームデータをバックアップメモリ２２にセーブする（Ｓ１１、Ｓ２１）。その後、キャラクタＡのキャラクタ情報を第１ゲーム機１００ａから第２ゲーム機１００ｂに送信する（Ｓ１２、Ｓ２２）。続いて、各ゲーム機は、ワークメモリに記憶されているゲームデータを更新する（Ｓ１３、Ｓ２３）。具体的には、第１ゲーム機１００ａでは、キャラクタＡの登場フラグがクリアされ、第２ゲーム機１００ｂでは、キャラクタＡの登場フラグがセットされると同時にキャラクタＡのステータス情報が更新される。なお、ここまでの処理については、図１４に示した従来のゲームシステムと同様である。
【００２７】
ワークメモリ上でのゲームデータの更新が完了すると、各ゲーム機は、更新後のゲームデータをバックアップメモリ２２に書き込むのであるが、本実施形態では、更新後のゲームデータが、第１段階の書き込み処理（以下、第１書き込み処理と称す）（Ｓ１５、Ｓ２５）と第２段階の書き込み処理（以下、第２書き込み処理と称す）（Ｓ１７、Ｓ２７）の２回に分けてバックアップメモリ２２に書き込まれる。そして、第２書き込み処理は、ステップＳ１６およびステップＳ２６において、両方のゲーム機において第１書き込み処理が完了したことが通信によって確認されてから開始される。
【００２８】
図８に、更新後のゲームデータがバックアップメモリ２２に書き込まれるときの各ゲーム機の処理の流れを示す。図８の（ａ）に示すように、本実施形態では、時刻ｔ１において、両方のゲーム機において第１書き込み処理が完了したことを通信によって確認した後に、第２書き込み処理が開始される。ここで、第１書き込みの途中で第１ゲーム機の電源が切られることによって第１ゲーム機の処理が異常終了してしまった場合、第１ゲーム機ではデータの書き込みに失敗してしまう。一方、第２ゲーム機は、両方のゲーム機において第１書き込み処理が完了したことを確認することができないので、第２書き込みを実行することができず、第２ゲーム機でもデータの書き込みに失敗してしまう。その結果、いずれのゲーム機においても、次回のゲーム処理では更新前のゲームデータがバックアップメモリより読み出されるため、従来のゲームシステムのようにデータが消滅したりデータの複製が生成されたりといった問題は生じない。ただし、異常終了が第２書き込み処理の途中で発生した場合には、従来と同様の問題が発生してしまう。そこで、その可能性をできる限り低減するために、第２書き込み処理の期間をできる限り短くする（つまり、第２書き込み処理において書き込まれるデータサイズをできる限り小さくする）のが好ましい。なお、バックアップメモリ２２に書き込むことができる最小のデータサイズは、例えば１ビットであったり、１バイトであったりと、デバイス毎に異なっているので、第２書き込み処理において書き込まれるデータサイズは、バックアップメモリ２２に書き込むことができる最小のデータサイズとするのが好ましい。
【００２９】
ところで、各ゲーム機において、第１書き込みが同時に完了するとは限らない。データの書き込み速度はバックアップメモリ２２の種類（フラッシュメモリ、ＥＥＰＲＯＭ、ＦｅＲＡＭなど）によって異なり、また、特にフラッシュメモリは、何度もデータを書き換えることによって性能が劣化してデータの書き込み速度が低減するからである。また、各ゲーム機でゲームデータのサイズが異なる場合もある。そこで、図９に示すように、各ゲーム機が第１書き込みを完了した時点で相手のゲーム機に第１書き込み完了通知を送信するようにし、両方のゲーム機が第１書き込み完了通知を送信した時点で第２書き込みを開始するようにすればよい。図９に示す例の場合、第１ゲーム機１００ａは、第１書き込みの途中で第２ゲーム機１００ｂから第１書き込み完了通知を受信し、その後、第１書き込みが完了した時点で第２書き込みを開始する。一方、第２ゲーム機１００ｂは、第１書き込みの完了後、第１ゲーム機１００ａが第１書き込みを完了するまで待機し、第１ゲーム機１００ａからの第１書き込み完了通知を受信後、第２書き込みを開始する。ここで、各ゲーム機は、第１書き込み完了通知の送受信結果に基づいて、図４に示すワークメモリ１２のフラグデータ６０を更新し、このフラグデータを参照して第２書き込みの開始タイミングが決定される。図１０の（ａ）は、第１ゲーム機１００ａが先に第１書き込みを完了したときの、各ゲーム機のフラグデータ６０の変化の様子を示している。フラグデータ６０は、第１ゲーム機の状態を示すフラグと、第２ゲーム機の状態を示すフラグとからなり、図１０の（ａ）に示すように、第１ゲーム機１００ａが第１書き込みを完了したときには、第１ゲーム機１００ａおよび第２ゲーム機ａの双方において、第１ゲーム機の状態を示すフラグを“１”にセットする。その後、第２ゲーム機が第１書き込みを完了したときに、第２ゲーム機の状態を示すフラグが“１”にセットされる。各ゲーム機では、フラグデータ６０において、第１ゲーム機の状態を示すフラグと第２ゲーム機の状態を示すフラグがいずれも“１”になったときに、第２書き込みを開始する。なお、図１０の（ｂ）は、第２ゲーム機１００ｂが先に第１書き込みを完了したときの、フラグデータ６０の変化の様子を示している。
【００３０】
以下、図１１〜図１３に示すフローチャートを参照して、ゲーム機間でキャラクタを交換する際の各ゲーム機の動作をより詳細に説明する。
【００３１】
図１１は、ゲーム処理を実行するときの第１ゲーム機１００ａのＣＰＵ１１の処理の流れを示している。図１１において、ゲーム処理が開始すると、ＣＰＵ１１は、ワークメモリ１２にゲームデータを記憶する（Ｓ１０１）。このゲームデータは、ゲームの進行に応じて適宜更新される。続いて、プレイヤからバックアップの指示があったかどうか判断する（Ｓ１０２）。プレイヤによるバックアップの指示は、操作ボタン１６を通じて行われる。バックアップの指示があった場合は、後述するバックアップ処理を実行後、ステップＳ１０４に進む。一方、バックアップの指示がなかった場合にはステップＳ１０４に進む。ステップＳ１０４では、プレイヤからキャラクタを交換するように指示があったかどうか判断する。交換指示があった場合にはステップＳ１０５に進み、交換指示がなかった場合にはステップＳ１０１に戻る。
【００３２】
キャラクタの交換指示があった場合には、まず後述するバックアップ処理が行われ（Ｓ１０５）、その後、他のゲーム機と接続されているかどうか判断する（Ｓ１０６）。他のゲーム機と接続されていない場合には、接続されるまで待機する。ステップＳ１０６において、他のゲーム機と接続されていることが確認されると、ステップＳ１０７に進む。そして、他のゲーム機において、キャラクタ情報を送受信する準備が完了したかどうか判断し（Ｓ１０７）、他のゲーム機において準備が完了していない場合には、完了するまで待機する。ステップＳ１０７において、他のゲーム機の準備が完了したことが確認されると、プレイヤに、交換するキャラクタ（第２ゲーム機に移動させるキャラクタ）を選択させる（Ｓ１０８）。そして、交換されるキャラクタに関するキャラクタ情報を第２ゲーム機との間で送受信する（Ｓ１０９）。その後、後述する更新制御処理によって、キャラクタ交換後のゲームデータをバックアップメモリ２２に書き込んで（Ｓ１１０）、ステップＳ１０１に戻る。
【００３３】
図１２を参照して、図１１のステップＳ１０３およびステップＳ１０５のバックアップ処理について説明する。バックアップ処理が開始すると、ＣＰＵ１１は、ワークメモリ１２上のゲームデータを書き込むべきバックアップ領域を、図４に示した２つのバックアップ領域のうちから選択する（Ｓ２０１）。このとき、ＣＰＵ１１は、履歴データ４１と履歴データ４２を比較して、より古いゲームデータが格納されているバックアップ領域を選択する。続いて、ワークメモリ１２に記憶されているゲームデータのうち、バックアップメモリ２２の１セクタ分に対応するサイズのデータをバックアップ領域に書き込む（Ｓ２０２）。このとき、図４に示した書き込み完了バイトは最初にクリアされるのが好ましい。そして、その１セクタ分のゲームデータが正常に書き込めたかどうか判断し（Ｓ２０３）、正常に書き込めた場合には、ステップＳ２０５に進む。一方、正常に書き込めなかった場合には、書き込みを繰り返し、その結果、所定の回数以内で正常に書き込めた場合には（ステップＳ２０４でＹＥＳ）、ステップＳ２０５に進む。一方、書き込みを所定の回数繰り返したにも関わらず正常に書き込めなかった場合には（ステップＳ２０４でＮＯ）、エラーがあった旨を液晶モニタ１８に表示して処理を停止する。ステップＳ２０５では、バックアップ領域を構成する全セクタ（例えば１５セクタ）に対するゲームデータの書き込みが終了したかどうか判断し、終了していなかった場合には、ステップＳ２０２に戻って次のセクタ分のゲームデータを書き込む。こうして全て（１５セクタ分）のゲームデータの書き込みが完了すると、バックアップ処理は終了する。
【００３４】
図１３を参照して、図１１のステップＳ１１０の更新制御処理について説明する。更新制御処理が開始すると、まずＣＰＵ１１は、図１１のステップＳ１０９で送受信したキャラクタ情報に基づいて、ワークメモリ１２内のゲームデータを更新する（Ｓ３０１）。具体的には、第２ゲーム機１００ｂに譲ったキャラクタの登場フラグをクリアするとともに、第２ゲーム機１００ｂから受け取ったキャラクタ情報に基づいて、第２ゲーム機１００ｂから入手したキャラクタの登場フラグをセットし、そのキャラクタのステータス情報を更新する。ゲームデータの更新が完了すると、続いて、その更新後のゲームデータを書き込むべきバックアップ領域を、図４に示した２つのバックアップ領域のうちから選択する（Ｓ３０２）。このとき、ＣＰＵ１１は、履歴データ４１と履歴データ４２を比較して、より古いゲームデータが格納されているバックアップ領域を選択する。
【００３５】
続いて、ワークメモリ１２に記憶されている更新後のゲームデータのうち、バックアップメモリ２２の１セクタ分に対応するサイズのデータをバックアップ領域に書き込む（Ｓ３０２）。このとき、図４に示した書き込み完了バイトは最初にクリアされるのが好ましい。そして、次に書き込むべきデータが最後のセクタに対応するデータであるかどうか判断する（Ｓ３０４）。例えばゲームデータが１５セクタ分のデータであって、すでに１４セクタ分のゲームデータが書き込まれている場合、次に書き込むべきデータは最後のセクタに対応するデータとなる。ステップＳ３０４において、次に書き込むべきデータが最後のセクタに対応するデータではなかった場合には、ステップＳ３０３に戻り、次のセクタに対応するデータを書き込む。
【００３６】
ステップＳ３０４において、次に書き込むべきデータが最後のセクタに対応するデータであった場合には、その最後のセクタに対応するデータのうち、１バイト分のデータをバックアップ領域に書き込む（Ｓ３０５）。そして、次に書き込むべきデータが最後の１バイト分のデータ（図４に示した書き込み完了バイト）であるかどうか判断する（Ｓ３０６）。ステップＳ３０６において、次に書き込むべきデータが最後の１バイト分のデータではなかった場合には、ステップＳ３０５に戻り、次の１バイト分のデータを書き込む。ステップＳ３０６において、次に書き込むべきデータが最後の１バイト分のデータであった場合には、第２ゲーム機１００ｂに第１書き込み完了通知を送信し、フラグデータ６０を更新する（Ｓ３０７）。なお、図示は省略するが、各ゲーム機は、更新制御処理の開始後、他のゲーム機から第１書き込み完了通知を受信したかどうかを監視し、他のゲーム機から第１書き込み完了通知を受信したときには、例えば割り込み処理等によってフラグデータ６０を更新する。
【００３７】
第１書き込み完了通知の送信が完了すると、次に、フラグデータ６０を参照して、全てのゲーム機（ここでは第１ゲーム機および第２ゲーム機）において、第１書き込みが完了したかどうか判断し、まだ完了していないゲーム機が存在していた場合には、そのゲーム機が第１書き込みを完了するまで待機する（Ｓ３０８）。一方、全てのゲーム機において第１書き込みが完了していた場合には、最後の１バイト分のデータ（書き込み完了バイト）であるＣＲＣチェックサムの値をバックアップ領域に書き込む。そして、ゲームデータのＣＲＣチェックサムが計算され、その計算値とＣＲＣチェックサムの値とが一致したとき、更新後のゲームデータの全ての書き込みを完了する（Ｓ３０９）。続いて、キャラクタの交換が完了した旨が液晶モニタ１８に表示され（Ｓ３１０）、更新制御処理は終了する。
【００３８】
以上のように、本実施形態によれば、各ゲーム機において第１書き込みが完了したことを確認してから第２書き込みを開始するので、書き込み完了のタイミングをほぼ同時期に終了させることができる。したがって、第１書き込み完了したことの確認がなされる前にいずれかのゲーム機が異常終了した場合には、全てのゲーム機において書き込み処理が失敗に終わる。したがって、あるゲーム機では書き込みに失敗し、かつ他のゲーム機では書き込みに成功するといった状況が発生する可能性が低減されるので、データが消滅したりデータの複製が生成されたりといった問題が発生する可能性が低減される。
【００３９】
なお、本実施形態では、バックアップメモリ２２に書き込まれるゲームデータには、ゲームデータの書き込みが正常に終了したことを示す１バイト分のデータ（書き込み完了バイト）が含まれるとしたが、このデータのサイズは１バイトに限らない。さらに、ゲームデータに、このような“書き込みが正常に終了したことを示すデータ”が含まれていなくてもよい。ただし、このようなデータを利用することにより、ゲームデータを読み出すときに、そのゲームデータが正常に書き込まれたものか否かを容易に判断できる利点がある。
【００４０】
また、本実施形態では、第２書き込み処理において書き込まれるデータのサイズが１バイトであるとしたが、本発明はこれに限らず、第２書き込み処理において書き込まれるデータのサイズが１バイトよりも小さくてもよいし、１バイトよりも大きくてもよい。
【００４１】
また、本実施形態では、２台のゲーム機間でキャラクタ等の交換を行うとしたが、本発明はこれに限らず、３台以上のゲーム機間でキャラクタ等を交換する場合にも容易に適用することが可能であり、その結果、本実施形態と同様の効果を達成することができる。例えば、第１ゲーム機から第２ゲーム機にキャラクタＡを移動させると同時に、第２ゲーム機から第３ゲーム機にキャラクタＢを移動し、さらに同時に第３ゲーム機から第１ゲーム機にキャラクタＣを移動させるような場合であっても、いずれかのキャラクタが消滅したり、その複製が生成されてしまう可能性が低減される。
【００４２】
また、本実施形態では、２台のゲーム機間でキャラクタ等を交換または移動させるとしたが、本発明はこれに限らず、一般に、複数のゲーム機間で、データ通信を通じてデータの一部をやりとりし、そのやり取りされたデータに基づいて各自のゲームデータを更新して不揮発性メモリに書き込む場合に好適に適用される。例えば、各ゲーム機で、プレイヤがゲームをプレイしたときの結果（得点）が得点ランキング表として保存されている場合に、ゲーム機間でこの得点ランキング表のデータをやり取りすることによって、各ゲーム機の得点ランキング表を統合した新たな得点ランキング表を生成し（その結果、複数のプレイヤが同一の得点ランキング表にランクアップされるようになる。）、今まで保存していた得点ランキング表を上書きするような場合にも、本発明は有効である。すなわち、あるゲーム機では更新後の得点ランキング表の書き込みに失敗し、かつ他のゲーム機では更新後の得点ランキング表の書き込みに成功し、各ゲーム機が保持する得点ランキング表の整合性が失われてしまうのを効果的に防止することができる。
【００４３】
また、本実施形態では、２台のゲーム機が通信ケーブル３００を介して通信するとしたが、本発明はこれに限らず、２台のゲーム機がネットワークを介して通信する場合にも本発明を適用することができる。
【００４４】
また、本実施形態では、各種プログラムがゲームカートリッジ２００ａを通じて第１ゲーム機１００ａに供給されるとしたが、本発明はこれに限らず、ＣＤ−ＲＯＭや、ＤＶＤなど、他の任意のコンピュータ読取可能な記録媒体を通じてゲーム機に供給されてもよい。さらには、ネットワークなどの通信回線を通じてゲーム機に供給されてもよい。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るゲームシステムの外観を示す図である。
【図２】第１ゲーム機１００ａおよびゲームカートリッジ２００ａの構成を示すブロック図である。
【図３】プログラムＲＯＭ２１のメモリイメージである。
【図４】バックアップメモリ２２およびワークメモリ１２のメモリイメージである。
【図５】ゲームデータに含まれるキャラクタ情報を示す図である。
【図６】キャラクタ交換時のゲーム画面例を示す図である。
【図７】本発明の一実施形態に係るゲームシステムにおいて、第１ゲーム機１００ａから第２ゲーム機１００ｂにキャラクタＡを移動させるときの処理の流れを示すフローチャートである。
【図８】更新後のゲームデータをバックアップメモリ２２に書き込むときの各ゲーム機における処理の流れを示す図である。
【図９】更新後のゲームデータをバックアップメモリ２２に書き込むときの各ゲーム機における処理の流れを示す図である。
【図１０】フラグデータ６０の変化の様子を示す図である。
【図１１】ＣＰＵ１１によって実行されるゲーム処理の流れを示すフローチャートである。
【図１２】バックアップ処理の流れを示すフローチャートである。
【図１３】更新制御処理の流れを示すフローチャートである。
【図１４】従来のゲームシステムにおいて、第１ゲーム機から第２ゲーム機にキャラクタＡを移動させるときの処理を示すフローチャートである。
【図１５】バックアップメモリにおいて、更新前のゲームデータが格納される領域と、更新後のゲームデータが格納される領域とが異なることを示す図である。
【図１６】従来のゲームシステムにおいて、キャラクタＡが完全に消滅してしまう原理を説明するための図である。
【図１７】従来のゲームシステムにおいて、キャラクタＡの複製が生成されてしまう原理を説明するための図である。
【符号の説明】
１１ ＣＰＵ
１２ ワークメモリ
１３ ＶＲＡＭ
１４ 外部メモリＩ／Ｆ
１５ コントローラＩ／Ｆ
１６ 操作ボタン
１７ 液晶ドライバ
１８ 液晶モニタ
１９ 通信ポート
２１ プログラムＲＯＭ
２２ バックアップメモリ
４１〜４３ 履歴データ
５１〜５３ 書き込み完了バイト
６０ フラグデータ
１００ａ 第１ゲーム機
１００ｂ 第２ゲーム機
２００ａ、２００ｂ ゲームカートリッジ
３００ 通信ケーブル
Claims (8)
- 第１ゲーム機に通信可能に接続された第２ゲーム機との間のデータ通信によってやりとりされたデータに基づいて更新されたゲームデータを、当該第１ゲーム機に接続された電気的に書き換え可能な不揮発性メモリに書き込むためのデータ書き込みプログラムであって、当該第１ゲーム機のコンピュータに、
更新後のゲームデータを、所定部分を除いて前記不揮発性メモリに書き込む第１書き込みステップと、
前記第１書き込みステップの書き込みが完了したときに、前記第２ゲーム機に第１書き込み完了通知を送信する第１書き込み完了通知送信ステップと、
前記第２ゲーム機から第１書き込み完了通知を受信する第１書き込み完了通知受信ステップと、
前記第２ゲーム機に第１書き込み完了通知が送信され、かつ前記第２ゲーム機から第１書き込み完了通知が受信された後に、前記所定部分のゲームデータを前記不揮発性メモリに書き込む第２書き込みステップとを実行させることを特徴とする、データ書き込みプログラム。 - 前記所定部分のデータサイズが、前記不揮発性メモリに対して書き込み可能な最小単位のデータサイズであることを特徴とする、請求項１に記載のデータ書き込みプログラム。
- 前記所定部分のデータが、更新後のゲームデータが正常に書き込まれたことを示すデータであることを特徴とする、請求項１に記載のデータ書き込みプログラム。
- 前記更新後のゲームデータが、前記不揮発性メモリにおいて、最近に書き込まれたゲームデータが上書きされないような領域に書き込まれることを特徴とする、請求項１に記載のデータ書き込みプログラム。
- 請求項１〜４のいずれかに記載のデータ書き込みプログラムを格納した、コンピュータ読取可能な記録媒体。
- 通信可能に接続された少なくとも２台のゲーム機が個別に保持しているゲームデータを、当該ゲーム機間のデータ通信によってやりとりされたデータに基づいてそれぞれ更新し、更新後のゲームデータを各ゲーム機に接続された電気的に書き換え可能な不揮発性メモリにそれぞれ書き込むゲームシステムであって、
各ゲーム機が、
ゲーム処理の過程で生成されたゲームデータを一時的に記憶する揮発性メモリと、
前記データ通信によってやり取りされたデータに基づいて前記揮発性メモリに記憶されているゲームデータを更新するデータ更新手段と、
更新後のゲームデータを、所定部分を除いて前記不揮発性メモリに書き込む第１書き込み手段と、
前記第１書き込み手段による書き込みが完了したときに、他のゲーム機に第１書き込み完了通知を送信する第１書き込み完了通知送信手段と、
他のゲーム機から第１書き込み完了通知を受信する第１書き込み完了通知受信手段と、
他のゲーム機に第１書き込み完了通知が送信され、かつ他のゲーム機から第１書き込み完了通知が受信された後に、前記所定部分のゲームデータを前記不揮発性メモリに書き込む第２書き込み手段とをそれぞれ備えることを特徴とする、ゲームシステム。 - 前記更新後のゲームデータが、前記不揮発性メモリにおいて、最近に書き込まれたゲームデータが上書きされないような領域に書き込まれることを特徴とする、請求項６に記載のゲームシステム。
- 通信可能に接続された少なくとも２台のゲーム機において、当該ゲーム機間のデータ通信によってやりとりされたデータに基づいて更新されたゲームデータを、各ゲーム機に接続された電気的に書き換え可能な不揮発性メモリにそれぞれ書き込むためのデータ書き込み方法であって、
各ゲーム機において、
更新後のゲームデータを前記不揮発性メモリに書き込むときに、当該更新後のゲームデータを、第１書き込み処理と第２書き込み処理の２回に分けて書き込み、
前記第１書き込み処理が完了したときに、当該旨を他のゲーム機に通知し、
他のゲーム機からの第１書き込み処理の完了の通知に基づいて各ゲーム機において第１書き込み処理が完了したことが確認された後、第２書き込み処理を開始することを特徴とする、データ書き込み方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002334113A JP3888629B2 (ja) | 2002-11-18 | 2002-11-18 | データ書き込みプログラム、ゲームシステムおよびデータ書き込み方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002334113A JP3888629B2 (ja) | 2002-11-18 | 2002-11-18 | データ書き込みプログラム、ゲームシステムおよびデータ書き込み方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004166819A JP2004166819A (ja) | 2004-06-17 |
| JP3888629B2 true JP3888629B2 (ja) | 2007-03-07 |
Family
ID=32698650
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002334113A Expired - Lifetime JP3888629B2 (ja) | 2002-11-18 | 2002-11-18 | データ書き込みプログラム、ゲームシステムおよびデータ書き込み方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3888629B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4652190B2 (ja) * | 2005-09-22 | 2011-03-16 | 株式会社バンダイナムコゲームス | プログラム、情報記憶媒体及び電子機器 |
| JP2007111355A (ja) * | 2005-10-21 | 2007-05-10 | Bandai Co Ltd | 携帯型ゲーム装置およびゲームシステム |
| JP6194221B2 (ja) * | 2013-10-08 | 2017-09-06 | 任天堂株式会社 | 情報処理システム、情報処理装置、情報処理プログラム、およびセーブデータの記憶方法 |
| JP6647855B2 (ja) | 2015-12-22 | 2020-02-14 | 任天堂株式会社 | データ交換システム、情報処理装置、データ交換プログラムおよびデータ交換方法 |
-
2002
- 2002-11-18 JP JP2002334113A patent/JP3888629B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004166819A (ja) | 2004-06-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105912356B (zh) | 一种支持版本回退的光模块固件程序在线升级方法 | |
| JP4768237B2 (ja) | 携帯可能電子装置及び携帯可能電子装置の制御方法 | |
| US20100151947A1 (en) | Game system, server and terminal | |
| JP2010195111A (ja) | 車載コンピュータシステム | |
| US6483746B2 (en) | Electronic apparatus | |
| JP3888629B2 (ja) | データ書き込みプログラム、ゲームシステムおよびデータ書き込み方法 | |
| US20070038918A1 (en) | Data backup method and memory device | |
| US7654904B2 (en) | Game machine, backup control program of game data and backup control method | |
| JP3093541B2 (ja) | プログラムおよびデータの版数管理を行う端末装置およびオンラインシステム | |
| JP6259601B2 (ja) | 情報処理装置、情報処理システム、情報処理方法及びコンピュータプログラム | |
| JP2008015783A (ja) | 電子バリュー交換システム、端末装置、復旧装置及びそれらに用いる電子バリュー交換方法 | |
| JP2014099097A (ja) | 情報処理装置、情報処理方法、およびコンピュータプログラム | |
| JP5045115B2 (ja) | プログラマブルデバイス制御装置およびその方法 | |
| JP2003228490A (ja) | ネットワークに接続される端末装置およびこれを用いたネットワークシステム | |
| JP4028480B2 (ja) | Ｆｐｇａコンフィギュレーション制御方法及び制御装置 | |
| JP2008217202A (ja) | ディスクアレイ装置及びファームウェア更新方法 | |
| JP2007042038A (ja) | 端末機器の制御装置及び制御方法 | |
| JPH0855068A (ja) | 通信端末装置 | |
| JPH08161160A (ja) | 光ディスク再生装置のファームウエア更新方法 | |
| JP2003108445A (ja) | 携帯可能電子装置及びそのチェック方法 | |
| JP3514173B2 (ja) | 制御装置 | |
| CN113467842B (zh) | 适用于工业级应用场景的嵌入式设备的启动方法、嵌入式设备和计算机可读存储介质 | |
| JP7572298B2 (ja) | 通信装置、およびファームウェア更新システム | |
| JP7568572B2 (ja) | 監視装置 | |
| JP6092673B2 (ja) | メモリ制御装置、メモリ制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050930 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060726 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060920 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20061124 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061124 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3888629 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091208 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091208 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101208 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101208 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111208 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111208 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121208 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121208 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121208 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131208 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |