check-sum（検査合計）。もともとは情報処理用語。
簡単に説明すれば、その復活の呪文が正しいものかどうか判定すること。
この判定に引っかかってしまうと「じゅもんが ちがいます」となるｗ
ここに、簡単な例を示そう。
Ａ＝１、Ｂ＝２、Ｃ＝３…という形でアルファベットと数字を対応させた場合
「アイテムαを４個、アイテムβを３個持っている」をパスワード化すると「ＤＣ」となる。
ここに「アイテムαとβの合計は７個」という情報を加えると、パスワードは「ＤＣＧ」となる。
この「Ｇ」の部分がチェックサムだ。
この例では、左２文字の数の和と右１文字の数が合わなければ、不正なパスワードとなる。
「アイテムαを３個、アイテムβを４個持っている」パスワード「ＣＤＧ」。
「アイテムαを２個、アイテムβを５個持っている」パスワード「ＢＥＧ」。
これらは通っても、「ＢＣＧ」や「ＤＥＧ」ではチェックサムが違うので通らないわけだ。
そして、チェックサム記号がひとつとは限らない。
例えばＡＦＧＺとして（Ｚ＝数字を「最後から逆」にあらわした仮の記号）
Ｆ＝Ｇ－ＺとなりＡ＋Ｆ＝Ｇと合わせてチェックスルーにするとか。
実際の復活の呪文では、もっと複雑な仕組みではあるが
復活の呪文内には、主人公の名前や持ち物などのデータとともに、このような判定用データが埋め込まれている。
では、実際の仕組みとは。
DQ1の場合、復活の呪文は1字あたり64種類の文字で、１か0かの情報は6個分含まれている。
１か0かの情報はビット(bit : binary digitの略)という単位で表される。
復活の呪文は20字あるので、120ビットの情報量となる。
一方、格納されているゲームのデータは、勇者名24ビット、経験値16ビット、お金16ビット、
武器3ビット、鎧3ビット、盾2ビット、薬草4ビット、鍵4ビット、アイテム32ビット、フラグ5ビット。
計、109ビットの情報量となる。
120－109＝11 この、残りの11ビットが判定用データとして割り当てられている。
そして判定用データとしてCRCを求めている。
ここではCRCの求め方の詳細な説明は省かせてもらう。
興味のある方は各自調べてみると良いだろう。
CRCはデータが壊れているかどうかを判別する目的でデータ通信に使われる事が多い。
※CRC : Cyclic Redundancy Check (巡回冗長検査)
CRCを求めているだけ、としてデータ通信に長けた方の中には逆に簡単だと言う方もいるようだ。
最終更新：2011年02月14日 11:26
