コンピュータゲームを題材として活用する情報教育の教材・実践事例をまとめたサイトです．

情報論

FrontPage

情報論

学習トピック

  • データ圧縮
    • 可逆圧縮/非可逆圧縮
  • 誤り検出/訂正技術
    • パリティ,CRC

授業の流れ

  • 情報論とは？
    • 厳密な定義を議論するのは目的ではないので，イメージとして理解できるようにする
    • ビットの話はしてるので．「情報をビット列に変え，またビット列から情報を復元する仕組みを学ぶ」とする
    • 後の説明に備え，「符号化」「復号」という単語もこの時点で出しておく
  • そもそも「情報」とは？
    • "定義"の重要性と曖昧性は何度も出しておく
  • データ圧縮
    • 符号化の例として扱う
    • 圧縮の２つの考え方：可逆＆非可逆
    • 可逆圧縮
      • ここでは「ゲームにおけるデータ節約の様々な手法」から入る
      • マリオとドラクエ（前の回で使ったゲームを流用．他のゲームでも同様の事例は確認可能）
    • 非可逆圧縮
      • 「品質を下げる」と表現．「人間が気づかない範囲の情報を削ってしまう」「演出上必要なところ以外は簡素に」
      • まず画像で例を示す
      • 可逆圧縮と非可逆圧縮の例を，ビット列の例を示して（単純な例で）説明
      • 音声圧縮の例（PCエンジン CD-ROM^2のゲーム）
  • データ冗長化
    • ビット反転の可能性についてまず説明
    • ゲームの「パスワード」例
      • パスワードが間違ってゲームが再開できない例も示す
      • パスワードの長さから推定される「表現可能なビット数」は，実際にプレイデータとして復旧できるデータを比べると明らかに多い．なぜか？
      • 合わせて，バッテリーバックアップ方式で「データが消えた」メッセージを表示するゲームも紹介
    • 「なぜ消えたのがわかるの？」「パスワードが間違ってるとわかるなら，なんで直してくれないの？」
  • 誤り検出/訂正符号
    • 例として，パリティビットを使った誤り検出と訂正の説明
      • CSアンプラグドの「カード交換の手品」（参考: Error Detection | Computer Science Unplugged）を題材にミニテストを実施
      • 復元可能，復元不可能，検出のみ可能，などいろんなパターンを提示
    • 100%間違いなく訂正できるわけではない
      • ゲームデータで誤り「検出」だけで「訂正」しないのは，ゲームの進行に支障を来す形で「訂正」してしまう可能性があるため．
      • あてずっぽうでパスワードを探り当てないように，という意図もあると思われる．

使用題材

スーパーマリオブラザース (1985, 任天堂)

  • ファミコンのグラフィック表示の原理
    • 8x8ドット単位のタイルを敷き詰めてグラフィックを表示
      • 背景もキャラクターも，この基本に依存
    • 文字
    • 使うタイルの種類が少ないほど，データサイズが小さくて済む
  • グラフィックにおけるデータ節約の工夫
    • レンガブロック：縦横にどんどん並べても違和感がないようなドットデザイン
    • 地上の草と空の雲：あるパレットの色が「白」か「緑」かの違いだけで，他は全く同じグラフィック．

ドラゴンクエスト （エニックス）

  • キャラクター使い回し
    • データ量節約
    • キャラクターの特性値（体力，攻撃力など）だけで特徴づけ
    • パターン
  • ファミコンの文字グラフィック表示の原理
    • 標準で持ってるのは「数字」と「英大文字」のみ（未確認）
      • それ以外の文字を使う場合は自前で用意する必要あり
    • 文字コードなんてものは当然非対応．「画像」として用意する必要あり
      • つまり「8x8ドットのタイル敷き詰め」の制限を受ける
      • なので，ファミコンの文字の多くは8x8ドット
  • 使用文字の節約
    • 参考情報： http://game.watch.impress.co.jp/docs/news/20090904_312961.html
    • カタカナ：20文字しかない
      • ドラクエなのに「ク」も「エ」もない
    • 濁点：別の8x8タイルとして表示し，清音と組み合わせて濁音文字を表現
      • しかし「ド」だけは独立した文字として用意（「ドラゴン」が出てくるから？でもゴは「コ」+「゛」．町の名前にも「メルキド」「ドムドーラ」とドが多用されていて，会話の文章にも多数登場し使用頻度が高いからかもしれない．）
    • 漢字：「力」は「カ」（カタカナ）で代用
      • 基本的にはひらがなのみ．漢字に相当する使用文字は「力」のみ
  • ふっかつのじゅもん
    • ゲームの続きをプレイするために必要な文字列
      • 当時，ゲームのプレイデータをセーブする機構はほとんどなかった（カセットテープ，ディスクシステムなど磁気保存の方式は一部にあったが，いずれも高価もしくは対応ソフトが少なかった）
      • 主流だったのが，ゲームを中断する時に王様が教えてくれる，一見意味不明な文字列＝"ふっかつのじゅもん"．これをメモしておいて，次にプレイを再開する時に文字列を入力すると，ふっかつのじゅもんをメモした時点のパラメータで再開できた
    • 使用可能な文字：64種類 (=6bit)
    • 長さ：20文字
      • つまり全体で120bitのプレイデータ
    • 実際にプレイデータに相当するのは，109bitだけ
      • 所持アイテム，各種フラグなど
      • 順番に並んでるのではなく，一つのデータを表すビット列をあちこちの文字（に対応するビット列）に分散させている（推測防止）
      • ゲーム進行に大きく影響しないパラメータは入ってない（現在の体力など．再開時には満タンになっている）
      • 算出可能なパラメータも入ってない（体力の最大値や攻撃力など．"経験値"と"プレイヤーの名前（4文字）"から，対応する値が算出できる）
      • 参考：「復活の呪文」資料室(SATOH_Yoshiyuki) http://www.imasy.or.jp/~yotti/dq-passwd.html
    • 残る11bit:誤り検出符号
      • CRC(Cyclic Redundancy Check, 巡回冗長符号)を利用

イースI・II（1989, 日本ファルコム)

  • PCエンジン CD-ROM^2で発売
    • 特徴は「生録音の音声をそのまま再生できる（CDなので）」
    • 当時の音声は無圧縮．
  • 音楽・ボイスの部分だけで60分くらいあったらしい
    • 無圧縮だと，大体540MB相当
  • しかしWiiのバーチャルコンソール版として配信されたものは，約30MB強しかない
    • ゲーム自体のボリューム当時のまま
    • むしろ，PCエンジン本体のエミュレーション部分のプログラムが追加されてる分，本来なら容量が増えているはず
    • 当時はムービー再生も不可能（主記憶装置が72kBしかない）
    • となるとデータ節約のカギになるのは・・・音声しかない

バベルの塔 (1987, ナムコ)

  • パスワード
    • 4種類の絵（ゲーム中に登場する16x16のグラフィック4つ） (=2bit)
    • 長さ：4個
      • 8bitで表現可能
    • 「認証用パスワード」に近い扱い
      • 再開したいフロア（ステージ）の番号をまず自分で選んでから，対応するパスワードを入力
      • フロア番号とパスワードの対応関係の法則は未調査（決めうちの可能性もある．が，容量節約のために算出できる可能性もあり？）

ロックマン2 (1988, カプコン)

  • パスワード
    • 5x5のマスに9個の点を置く
      • パスワードを図形的表現で採用した面白い例
    • 25マスx点の有無 = 25bit？
      • 「9個の点を置く」という条件から，実際可能な組み合わせは2^25よりははるかに少ない

タッチ　ミステリーオブトライアングル (1987, 東宝)

  • パスワード
    • 使用文字：68文字 (=7bit?)
      • なぜこんな中途半端な長さに・・・
    • 長さ：60文字
      • 7x60 = 420bit．ただし，ゲーム内容からして明らかにこんなにいらない．
  • 「すっごい長いパスワード」の例として，手元にあったものをネタ的に使用
    • そもそもこのゲーム，同名の原作漫画のキャラクターを使ってるのだが，ゲーム内容は原作の内容と全く関係ない．
      • ちなみに，10匹の迷子の子犬を見つけるために，立ちふさがる敵を野球のボールでなぎ倒していくというゲームです．
      • 今の大学生でも知ってる人が多いくらい有名なマンガなので，ある種お笑いネタとして利用．学習目的で言えば，これを使う必然性は全くないです．

ドラゴンクエストIII (1988, エニックス)

  • 「おきのどくですが　ぼうけんのしょ１ばんは　きえてしまいました。」
    • 本当はデータは消えてない．だが何らかの理由でビット反転が起こり，正常でないデータになっている
      • 誤り検出技術が使われている
    • ゲーム進行に悪影響が出る可能性もあるので，「きえた」ということにしてデータを削除してしまう
      • 削除するのはメッセージが出た後らしく，リセットを連打するとさらにビット反転が起こって，たまにゲーム開始可能な状態になることがあるらしい

パリティビット

  • ゲーム会社の名前 (パリティビット公式Webサイト
    • パリティビットの説明の際に，余談として同名の会社紹介．
    • 代表作は「ダービースタリオン」．パラメータが多用されるゲームなので，もしかすると授業ネタが眠ってるかも？

その他素材

映像・音声圧縮用ミドルウェア群

ファミコンの音源

概論としては内容がマニアックになってしまいそうなので，授業では触れず．ただ，デジタル音源から情報科学をひもとく授業も面白そう．

  • 矩形波2音，三角波1音，ノイズ音＋拡張音源(DPCM)
    • 基本は3音+ノイズ音．
    • 音数を多く使えば当然データサイズも増える
      • DPCMで音を鳴らすとかなりデータを食うので，初期ではほとんど使われず．
    • 音程と長さをビット列で直接指定
      • 非可逆圧縮という概念はない．元となるデータあっての非可逆圧縮なので当然
  • 先人達の知恵
    • ドラクエ1：タイトルとエンディング以外のBGMは全て2音．ノイズは効果音として適宜使用．
    • アルペジオ
      • 和音を構成する音を，1音ずつ連続的に鳴らす演奏手法（音楽用語）
      • 同時に何音も鳴らせない昔のゲーム機の環境では，和音を表現する手法として最適
      • ドラクエのBGMでも多用されている
    • ノイズ音源を打楽器に見立てて利用
    • 音源の間引き
      • BGM演奏中に別の効果音を鳴らすとき，音源の一部を一瞬だけ効果音用に使用
      • 当然その間，BGMのその音源の担当部分は途切れる
      • 入れ替えの際によく犠牲になるのはメロディーライン．ベースラインを消すと急にBGMが薄い感じになるから？（経験則．未検証）

その他

E3 (Electronic Entertainment Expo)

  • 業界向けゲーム展示会＠アメリカ
    • 毎年1回開催（大体6月頃に開催）なので，この回あたりで紹介

文字コード

  • 実際利用されている文字コードにも，ドラクエのような「清音」＋「濁点」の表現方法がある(Unicod)
    • こちらはデータサイズの節約ではなく，文字の意味づけと文字コードの対応関係というポリシーの問題だが

可逆圧縮と非可逆圧縮

  • Powerpointでは，可逆圧縮の画像を載せても，勝手に圧縮処理が行われてしまう
    • 色の境界線の差異を見せたいのに，境界線にブロックノイズがのっかったような画像になってしまう．

ゲームの世界での「パスワード」

  • 認証用パスワード以外に，「ゲームの続きをプレイする」ためのパスワードも存在
    • パスワードがプレイデータそのもの
      • 1文字ごとに対応するビット列を定義
      • 特定の文字の並び→ビット列→本来のプレイデータに対応付け

QRコード

オーディオオカルト

  • 音楽録音再生専用USBメモリー （紹介ページ）
    • スペック
      • 容量:4GB， 19,950円（税込）
      • ケース：木製（ヴァイオリンの音響効果を応用）
      • ケーブル：100%ウール外皮（音質に悪影響を与えるノイズを極力排除）
    • 時間が余ったときに，これを紹介した上で「さて，これをみんなはどう思う？」と問いかけ
      • コンピュータの「情報」の概念を理解してないと，ツッコミどころがわからない

powered by Quick Homepage Maker 4.73
based on PukiWiki 1.4.7 License is GPL. QHM

最新の更新 RSS  Valid XHTML 1.0 Transitional