2003-10-01
ちょっと前の話になるのだけれど，"Joel on Software" の Joel Spolsky 氏が，自らデザインを行った新社屋がやっと完成したことを，自身の blog において伝えている。
http://www.joelonsoftware.com/items/2003/09/19.html
ここで氏は，１つの「こぼれ話」として，建築産業とソフトウェア産業の類似性について触れている。
氏は Tom Poppendieck 氏のコラム "Lean Construction" を引き合いに出している。
http://www.poppendieck.com/construction.htm
"Lean Construction" というのは，建築プロジェクトのマネジメント手法として一般に知られているものであるらしい。このコラムは，ソフトウェア開発の専門家である Poppendieck 氏が，マネジメントの「修行」として Lean Construction Institute に研修を受けに行ったときの体験談が元になっている。
Poppendieck 氏によれば，建築産業におけるプロジェクト管理も，やはり多くの不安定要素を抱えつつ動いているものであるそうだ。顧客の要求は曖昧だし，設計はいつまでたっても固まらない。人員の運用は困難を極めるし，スケジュールは往々にして遅延する。資材の調達に不足があれば，工程は大きな遅延を生じてしまうし，仕事に手を付けられず「遊び」状態になってしまった人員は，膨大な人件費を無駄に浪費してしまう。
特に建築プロジェクトにおいては，細かな工程を基本単位として人員の割り振りを行っていることが，遅延を生じる大きな原因となっているようだ。全体の作業を個々の工程へと細分化し，その工程の間で仕事を「受け渡す」(handoff) ことによってプロジェクトを進行させるのだけれど，この「受け渡し」が変動要素を含んでいるために，工程が増えれば増えるほどスケジュールの歪みも大きくなってくる。例えば，普通の家を建てるにも，その過程には百数十もの「受け渡し」が存在しているというのだから，よほど上手く運用できなければ，とたんに大きな歪みを抱えてしまうというわけだ。
2003-10-02
先程まで目を通していた資料の中に "Open-Closed Principle" (OCP) という用語が出てきたので，これについて軽く調べてみることにした。
簡単な google リサーチによって真っ先に見つけたのは，C++ Report の Robert C. Martin 氏の記事 "The Open-Closed Principle" だ。
http://www.objectmentor.com/resources/articles/ocp.pdf
また，石井勝氏の記事「デザインパターンと Open-Closed Principle」では，OCP のコンセプトとその必要性，また，各種のデザインパターンとの関連性などについて簡単な解説を行っている。
http://member.nifty.ne.jp/masarl/article/dp-ocp.html
どちらも非常に分かりやすい記事であり，参考資料としては十分なものではないかと思う。
OCP の提唱者である Bertrand Meyer 氏によれば，その定義とは次のようなものになっている。
Martin 氏の補足によれば，「拡張に対して開かれている」状態とは，アプリケーションの要求に応じてモジュールの振る舞いを拡張することが可能である状態を指す。また，「変更に対して閉じられている」状態とは，ソースコード自体を変更することが不可能（不要）である状態を指す。これらを総合すると，OCP とは，「モジュールのソースコートに変更を加えることなく，付け足しのみによって拡張が可能である状態」を表すものであると言うことができる。
例えば Template Method パターンなどは，モジュールの挙動に関して OCP を実現するための基本的な戦略の一つだ。ベタなＣでは，モジュールのコード自体に変更を加えることによって拡張を実現していたようなシチュエーションも，Ｃ＋＋の仮想関数による動的なディスパッチを用いれば，元のソースには一切触れることなく拡張を行うことが可能となる。
しかも，Ｃ的な実装では抽象階層から具象階層への依存が発生していた点についても，Template Method による実装ならば，これを具象階層から抽象階層へ向かう依存へと転じ，抽象階層を「閉じた」モジュールとして「絶縁」 (insulation) することが可能となる。この「具象へ向かう依存の解消」は，理論的な設計面において単純性をもたらすだけでなく，不要なコンパイル時結合性を解消するという，実装面での依存性の低下にも大きく貢献する（つまり，「ちょっと変更したら全コンパイル」の危険性を回避できるということだ！）。
これらの OCP の解説に共通して見られるのが，OCP こそがオブジェクト指向設計 (Object Oriented Design - OOD) の根幹をなすコンセプトであるという主張だ。OOD から OCP が導き出されるのではなく，むしろ，OCP を実現するための一手法として OOD が存在するのだという，実にダイナミックな発想だ。
Matrin 氏はこれに加えて，OOD において一般的な慣習として扱われている基本ルールの数々は OCP によって理由付けすることが可能であることを示している。例えば，「すべてのメンバ変数は private にすべきである」なんていう，誰もが叩き込まれている基本ルールのひとつを引き合いに出して，これを OCP 的な観点から見た場合の必要性について述べている。
これは逆に，OCP さえ守られていれば，このような慣習をかたくなに守る必要性が無いことを示しているのかもしれない。例として Martin 氏は，次のような Time クラスの実装を挙げている。
この Time クラスは，時刻の情報を保持する構造に簡単な比較演算子を加えたものなのだけれど，このクラスのメンバ変数の仕様が将来に渡って変更される可能性は非常に低いため，これを「閉じる」必要性も低いと言うことができる。また，誰かがこの変数の値を勝手に書き換えたとしても，このクラス自体の動作には何ら支障が無い（それは，このクラスの外で完結する問題だ）ため，アクセスを保護する目的でのアクセスメソッドを用意する必要性も低いということができる。
実際問題的なことを言うならば，屁理屈をこねる前にアクセスメソッドを用意して，メンバ変数は private へと隠すべきだ。何故なら，アクセスメソッドを実装する手間は非常に安いものであり，「実装しないことによるリスク」と比較すれば十分に見合う作業であるからだ。純粋に理論的設計の観点から見れば，このデザインはそれほど「悪いデザイン」であるとは限らない。むしろ，これはスタイルの問題なのであり，危ぶむべきは「悪いスタイル」なのであるのだと， Martin 氏は指摘している。
2003-10-03
今年のゲームショウにおいて，個人的に注目した要素が２つある。１つは，任天堂の「無線ネットワーク対応ポケモン」であり，もう１つは，SCEJ の "EyeToy" だ。
http://www.playstation.jp/scej/title/eyetoy/
"EyeToy" に関しては，ハードウェア同梱ゆえの供給の弱さという点に一抹の不安を感じている。「一週間もあれば１００万枚刷れる」という円盤メディアとは違い，ハードウェアの生産スケジュールを考慮しなければならないからだ（しかもハードウェアの生産は Logitech 社に依存している）。現時点での欧米での加熱ぶりを見るに，国内での年内発売は難しいかもしれないと予測していたのだけれど，どうやら国内でもクリスマス商戦に向けて大々的に売り込む目論みのようだ。さて，どうなることやら……。
先日のこと，ゲームデザイナ兼コンサルタントの Greg Costikyan が，自身の blog "Games * Design * Art * Culture" において "EyeToy" のヒットについて軽く触れていた。
http://costik.com/weblog/2003_09_01_blogchive.html#106365113...
今夏に SCEE から発売された "EyeToy" は，欧州圏において驚異的な売り上げを記録しており，その正確な数量は定かでないものの，ホリデーシーズンには北米と日本でも発売されるとあって，まもなくミリオンを突破することは間違い無いだろうと思われる。
しかしなぜ，このようにシンプルな仕組みを持つゲームが登場し，これほどまでに好評を博しているのだろうか。実際にゲームを見てみれば分かることだけれど，"EyeToy" に収録されているゲームはどれも他愛の無い内容のものばかりだ。それがどうして，ここまでユーザに受けているのだろうか。カメラデバイスとは，そこまで高い可能性を持つデバイスなのだろうか。
CNN/Money の Chris Morris 氏は，同誌のゲーム産業解説記事 "Game Over" において "EyeToy" の話題を取り上げている。その中には次のような記述が見られる。
http://money.cnn.com/2003/09/12/commentary/game_over/column_...
このような間口の広さを持つと共に，実際にプレイを始めて数分で「面白い」と納得させる力があるからこそ，この商品は売れている。しかし，そこで得られる「面白さ」の正体とは，一体何なのだろうか。それを単に「直感性ゆえの分かりやすさ」と混ぜてしまうのは，少しせっかちなものの見方のように思える。
EyeToy の持つ「面白さ」の要素を理解するには，このゲームを独りでプレイしてみるのがいいかもしれない。きっと全然面白くないだろうからだ。このゲームがもたらす「面白さ」の要素の多くの部分は，このゲームの中に存在するわけではなく，ゲームの画面を見つめている人達を取り巻く環境の中に存在している。
それは，最初の要素である「ゲームの画面に映る自分の姿が面白い」から，「ゲームの画面に映る友達の姿が面白い」，あるいは，「間抜けな動きをする友人の姿が面白い」から「家族みんなで参加するのが面白い」等々……画面の中に作り出される世界よりも，ずっと「こちら側の世界」にもたらされる「体験」の要素が「面白さ」の主軸として取り入れられている。そこが，他の多くのゲームとは異なると感じている点だ。
2003-10-04
このような話に関連して，以前から考えていることの１つに，ユーザがゲームを通じて得ることのできるエクスペリエンス……つまり「体験」の要素を，ゲームのバリューを評価する基準として用いることができないだろうか，ということがある。
アプリケーション・ソフトウェアのインタフェース設計の分野においては，度々「ユーザ・エクスペリエンス」という用語が用いられることがある。これは，９０年代中盤から始められた「ユーザ指向デザイン」 (User-Centered Design) の研究において生み出された概念だ。
http://www.peterme.com/index112498.html
つまり，従来から用いられていた「ユーザ・インタフェース」という用語が，ユーザとテクノロジの接点を論じるにはあまりにも狭すぎると考えられたために，もっと広く包括的な意味を持つ語彙を導入する必要があったということだ。
認知心理学とユーザ・インタフェース設計の専門家として有名な Don Norman 氏は，次のように述べている。
この考えは，「ゲーム」を取り巻く現状にも適用することができるかもしれない。つまり，「ゲーム性」とか「ゲームシステム」，あるいは，特徴的なアートデザインとか，（誰かにとって）革新的なテクノロジとか，そういった狭い観点に着目するのではなく，そのゲーム……延いてはその「商品」を通じてユーザが得ることになるであろう「体験」の要素に着目することが，ユーザの欲求を正確に分析する「鍵」となるのではないだろうか，ということだ。
既存の一般的な考え方では，あるゲームを評価するための視点が，パッケージの中の要素へと入り込み過ぎていたように思える。ユーザの「体験」の部分は，ゲーム機とゲームソフトという個々のエレメントの中に主体を置いていては見えにくい部分だ。ユーザがどうしてそのゲームによって楽しくなるのだろうか，あるいは，「楽しくなるに違いない」と確信してくれるだろうか。その勝負の場を，ゲーム機の中に「閉じ込める」のではなく，ゲーム機の外へと「開放する」のは，ある意味では大きな可能性の獲得であり，ある意味では大きな問題への挑戦でもある。
ゲームを通しての「体験」という要素に着目する場合に，まず思い出されるソフトの１つが "EyeToy" であり，もう１つのソフトが 「ボクらの太陽」だ。
http://www.konamijpn.com/products/boktai/japanese/comic_ppw0...
「ボクタイ」のゲームシステムには，多くの人間にとって重要な存在である「太陽」の要素が取り込まれている。プレイヤはゲームを進めるために，常に「太陽」の存在を意識しなければならない。天候の悪い日は上手くゲームが進められないかもしれないし，あるいは，夏の暑い日差しが少しは有難く感じられるようになるかもしれない。日常生活において日光の良く当たる場所を探し求めてみたり，時間の推移と共に日の強さが変化することを知るかもしれない。あるいは，ふと見上げた夕日の美しさに目を奪われ，今まで特に意識することの無かった太陽の存在を，少し考えてみるきっかけとなるかもしれない。
そうした「体験」のひとつひとつが，このゲームを通して得た思い出として，ユーザの記憶の中に刻まれるわけだ。
これらのゲームから得られる「体験」の要素は，ゲーム機よりも外の世界へと大きく開かれている。この「広がり」から新たな「体験」を創出することが，テクノロジの十分に発達した今となって許される新たな挑戦なのではないか，と，僕は考えている。
2003-10-05
それでは，この「体験」の要素に着目した場合，次に創出されるべき「新たな体験」とは，どのようなものになるのだろうか。そこで僕が可能性の１つとして見出していたのが，「無線ネットワーク」の要素だった。
これは，携帯端末とアドホックな無線ネットワークの組み合わせによって生み出される「局所性」と「可搬性」の要素が，来たるべき「偏在するコンピュータ」の時代に向けて新たな「体験」をもたらすことになるに違いないと確信しているからだ。これについては，ユビキタス・コンピューティングとインタフェース・デザインの分野において既に研究が進められており，そこから多くのヒントを見出すことができる。
そしてもう１つ，無線ネットワークに拘る理由がある。これは個人的な主義思想によるものなのだけれど，「子供向けのゲームというものは『ひとり遊び』を助長するものであってはいけない」という考えが，僕の頭の中に常に存在している。ゲームは，ゲームの世界へと子供を引き込むものであるよりも，むしろ，人間同士のコミュニケーションにおける「接点」の上に存在するべきだという考え方だ。
そのような思想からすれば，GameBoy の「ポケモン」は非常に良いゲームの例だったのだけれど，これには大きな制約が１つ存在した。それは，ゲーム機同士の接続が有線に限られていたという点だ。この場合の「無線」と「有線」の違いというものは，決して単なる扱い易さの問題だけではない。「有線」では接続を行うのに物理的な干渉を行う必要がある。接続する相手に対して極端に接近し，接続するという行為によって相手のデバイスを占有しなければならない。このような行為は，日常生活においてかなり特異なコミュニケーションとして分類されてしまうはずだ。
これに対して「無線」は，「声によるコミュニケーション」に近い性質を持っている。接続する相手に対して物理的な干渉を行う必要は無い。ただ「声」を投げかければ，それは何も無い空間を通じて，たちまち多くの人へと伝わることになる。そのような自由度を持ちながらも，空間的には制限を伴っており（例のデバイスの通信範囲は数メートル程度に制限されているようだ），その局所性が「直接のコミュニケーション」をサポートする役割として活躍することになる。
そのような考えを持っていた僕にとって，「無線対応ポケモン」は，まさに理想のデバイスであるように思える。子供達は，もはや「ゲーム」をするためにポケモンを持つのでは無い……ポケモンという「接点」から生み出されるコミュニケーションのすべてが，ポケモンからもたらされる「体験」のすべてであり，子供達のカルチャーを構成する１つの要素として存在することになるのだ。
ゲームをプレイするのに部屋に篭っていたのでは，そこから得られる「体験」は部屋の中での出来事に限られてしまうだろうし，デバイス同士をケーブルで接続していたのでは，そこから得られる「体験」は物理的な制約を伴うものへと限られてしまう。しかし，このデバイスはそれらの制限をすべて取り除くことに成功している。子供達の生活空間すべてと，子供達が過ごす膨大な時間のすべてが，その相手となり得るわけだ。
願わくば，そういったゲームからもたらされる「体験」の数々が，子供達にとって掛け替えの無いものであって欲しいと思う。ゲーム機を持って公園を駆け回ることがとても楽しいかもしれないし（電波の弱さが重要なファクタとなるかもしれないし，専用の小型発信機などを用意すれば，また面白い遊びを独創することが可能になるかもしれない），ゲームを通して得た友人が少年期において重要な役割を果たすかもしれない。ホットスポットを求めて街を探検することが新たな体験に繋がるかもしれないし，共通の目的を持つことが人付き合いの幅を広げることとなるかもしれない。
人生において最も重要な時期であるはずの幼年時代が，ゲームによって制限されることがあって欲しくは無い。それはむしろ，子供達の経験を豊かなものとし，大切な記憶の数々を作り出すひとつのきっかけであって欲しい……そんな独りよがりのおせっかいが，この考えを支えている。
しかも最高に悔しいのが，この無線デバイスの最初のコンテンツとして「ポケモン」を持ってきたということだ。もうこの製品が，最悪の場合でもある程度の成功を収めるだろうことは，誰の目にも明らかな事実だ。これは言ってみれば，開戦直後に原爆を投下するような行為だ。僕はその爆心地にかなり近い場所に立っているし，もしかしたら，爆心地の真ん中に立って絶望に呻いている人が，この日本のどこかに居るのかもしれないと考えている。
2003-10-06
先日，Herb Sutter 氏の "Non-Virtual Interface Idiom" について調べた際に，それとはあまり関連の無い文書を１つ読んだ（単にサーチに引っかかっただけの話なのだけれど）。Bosko Zivaljevic 氏の "Templatized Primitive Method Idiom" だ。
http://jerry.cs.uiuc.edu/~plop/plop2002/final/ttpattern.pdf
これは，簡潔にまとめるならば，Template Method パターンにおいて各プリミティブメソッド（仮想関数として実装を委譲される部分）を実装する際に，テンプレート関数を活用すると良いケースが存在するというものだ。
Template Method におけるプリミティブメソッドの定義は，大きく括り過ぎれば，各実装において重複する部分が発生してしまうし，小さく括り過ぎれば，インタフェースの抽象性が枷（かせ）となる危険性を生み出してしまう。各プリミティブの定義は基底クラスにおいて抽象的に行われるために，派生側から具象的な実体への参照を得ることが難しくなるという特性を持っているわけだ。
Zivaljevic 氏は，このような問題を多態性によって解決することは困難であると指摘している。これに多態性を適用しようとすると，抽象クラスと派生クラスにおいて行われるべき「インタフェースと実装の役割分担」が曖昧なものとなってしまい，本来は一方通行であるはずの「抽象←具象」の依存関係を崩してしまうためだ。その結果として，動的キャスト等の「あまり好ましく無い」テクニックが必要とされてしまうことになる。
このような状況においてテンプレート関数は「特効薬」となりうる可能性を秘めている。プリミティブメソッドの中身をテンプレート関数として別途に実装することで，各実装の共通化を行いつつも，動的な型情報に全く依存しないコードを実装することが可能となるわけだ。
では，なぜテンプレート関数を用いると上手く行くのだろうか。それは，ええと……今日はもう眠いので明日考える……。
2003-10-07
"Templatized Primitive Method Idiom" の中で Zivaljevic 氏が挙げている設計の例を整理すると，次のようなものになる − 抽象基底クラスと，そこから派生される具象クラスが複数存在し，それぞれの具象クラスは似たような実装を持っており，しかもその実装が自分自身の型に依存するような関係を持っている。
ここで，当然の流れとして「似たような実装」の共有化を考えることになる。それぞれの実装が分離されたままでは，処理に拡張を行うことが難しくなってしまうし，下位構造の依存関係も複雑化してしまうからだ。これは典型的な「堅い設計」 (rigid design) の例として指摘することができるかもしれない。ほんの少しの変更が多くの箇所へ影響を与えてしまうために，拡張が困難なものとなってしまっているという状態だ。
実装の共有を図るにあたって，まず考えられる手段がクラスの階層化だ。該当する処理を分離し，もう１つの Template Method クラスを構築してしまえば良い。しかし，この方法はちょっとした弱点を抱えている。それぞれの実装が具象クラスの型に依存するような構造を持っているため，それを抽象化した時点でダウンキャストの必要性が生じてしまうというものだ。最終的にはダウンキャストを使うことも考えられるものの，これはできる限り利用を控えるべきだと思う。
他には，共通する処理を基底クラスのメソッドとして実装してしまうという方法が考えられるものの，これも上と同様の理由によって実現が難しくなっている。異なる継承ツリーに属する具象クラス同士が依存関係を持つ場合，これを抽象化してしまうと，どうしてもダウンキャストの必要性が生じてしまう。どうやら，このような場合にポリモルフィズムは思ったような効果を上げてくれないようだ。
C++ のテンプレートは，抽象化の手段として非常に強力な機能を持っている。具体的には，下位層の実装を抽象化するという機能を実現するのだけれど，OOP ではこれと同じことをポリモルフィズムによって実現する。ただ，OOP における継承はクラスの間に強力な結合をもたらすものなので，あまり自由に扱うことができないというのが実情だ。この点において，テンプレートはかなりのアドバンテージを持っている。ポリモルフィズムよりも優れた適用可能性を持っているわけだ。
テンプレートがポリモルフィズムと比較して劣っている点は，"IS-A" 関係（「ＸはＹの一種である」という関係）を扱うことができないという点だ。テンプレートは与えられた型情報を元に静的なコードを生み出すだけのものであるから，動的に変動する情報を扱うことはできない。逆に言えば，ポリモルフィズムを利用する最大の動機とは "IS-A" 関係を扱うことにあると指摘することができる。
上のような例は，まさにテンプレートを用いるべきパターンかもしれない。この場合の抽象化を行う動機は，単に「実装を共有したい」というものであり，いわゆる "is implemented in terms of" 関係（「ＸはＹの実装を用いる」という関係）で表されるものだ。テンプレートを用いれば実装を一箇所へ集約することができるし，下位構造においても柔軟な構成を行うことが可能となる。
Generic Programming の方面に距離を置くようになってからというもの，敢えてテンプレートの利用を避けるように心がけていたのだけれど，純粋に実装を共有するという目的においては，やはりテンプレートが魅力的な手段として目に映ることがある。あの記述の難しさと，コンパイル時依存性の問題には十分に気をつける必要があるものの，限定された場面で適切な運用を心がけるようにすれば，それほど害悪のあるものでも無いはずだと考えている。
2003-10-08
以前，海外のゲーム系ブログを探してみようと試みたことがあった。その時に得られた数個のサイトからリンクを辿るうちに，そこそこの数の巡回対象が得られるようになった。たいていはざっと目を通すだけなんだけれど，たまに興味を惹かれる記事があると，印刷して移動中に読んでみたりしている。
それらのサイトの中でも際立ってユニークな存在が，Jane Pinckard 氏のブログサイト "game girl advance" だ。
http://www.gamegirladvance.com/
このサイトは，Jane 氏とその共同執筆者である Justin Hall 氏が，ゲームとそれを取り巻くカルチャーについて，様々な意見を述べているサイトだ。開発者の立場からは一歩引いた視点での論評が，いわゆる「個人ジャーナリズムとしてのブログ」ってやつっぽくって，個人的にはいい感じだと思っている。
"GGA" の最近の記事から張られていたリンクの中で興味を惹かれたのが，Salon.com にあった Dani Bunten 氏の回顧記事だ。
http://www.salon.com/tech/feature/2003/03/18/bunten/
Dani Bunten 氏は，かの有名な多人数トレーディングゲーム "M.U.L.E." の作者として知られる人物だ。コンピュータゲームの黎明期に活躍したゲームデザイナの１人であると共に，数少ない女性ゲームデザイナとしても有名な存在であったそうだ。
重度のヘビースモーカーだった氏は，１９９８年に肺ガンによって他界してしまった。氏の持つユニークなゲームデザイン哲学は "M.U.L.E." という初期の名作を生み出したものの，８０年代から９０年代にかけて流行ったコンテント重厚化の流れに乗ることができず，ついには大衆にもパブリッシャにも受け入れられることの無いまま，その短い人生を閉じることになってしまった。
このようにゲーム産業にも「過去の人」が徐々に現れてくると，それに伴って「物語」の類が形成されていくのだろうなと思う。この場合の Bunten 氏の話などは，ある種の才能を発揮しながらも成功を収めることができなかった人の物語だ。氏は，ビジネス的には成功を収めることができなかったものの，デザインの思想という点において Will Wright 氏や Sid Meier 氏などをはじめとする著名なゲームデザイナ達に影響を与えている。そのような貢献を残しているからこそ，この記事のように人々に惜しまれる存在となっているのだろうと思う。
上の記事と同時にリンクを張られていたのが，"TheFeature" の記事 "Multiplayer - the Only Mobile Game" だ。これは，"GGA" の共同執筆者である Justin Hall 氏が，モバイルネットワーク情報サイトである "TheFeature" に寄稿した記事となっている。
http://www.thefeature.com/article?articleid=26917
記事の内容を簡潔にまとめると，「せっかくの携帯電話なのに，スタンドアロンのゲームばかりなのはもったいないよね」とか，そんな感じの内容だ。
Hall 氏は，携帯電話のゲームコンテンツとして，スタンドアロン形式のゲームや，限定されたコミュニケーション機能しか持たないゲームが氾濫していることを指摘した上で，今後登場してくるであろうコミュニケーション指向のゲームの可能性について触れている。
そこで挙げている例の１つとして面白かったのが，フランスは newt games 社が制作している携帯ゲーム "Kigen" の話だ。
このゲームに関しては公開されている情報がほとんど存在しないものの，Hall 氏の記述によれば，携帯電話デバイスから得られる位置情報を利用したサイバーＳＦ風マルチプレイヤーゲーム，というもののようだ。人々の住む都市そのものを舞台としたゲームであり，映画「マトリックス」のような世界観をテーマとしたものだと想像すれば良いだろうと思う。
この newt games 社についてもう少し詳しく調べてみると，既に「モギィ・アイテムハント」という，位置依存型の携帯ゲームを販売していることが分かる。
http://www.mogimogi.com/mogi.php?language=jp
基地局の情報を利用して現在の位置情報を得るという機能は，最近の携帯には当然のように搭載されている機能なのだけれど，これを利用した「位置依存型」のゲームというものは，この「モギィ」が初めてではないかと思う。これがゲームとして面白いものであるかどうかは微妙なところだけれど……やはり，単なる「宝探しゲーム」に終わってしまうと，辛いものがあるだろうと思う。どこかに「都市独特のカルチャー」とリンクする部分が無いと，ね……。
2003-10-09
オフィスが今の場所へと移転してからというもの，個人的に生活スタイルの改善を試みようとしている。仕事中に音楽をまったく聴かなくなったというのも，その改善のうちの１つだ。特定の作業に没頭するよりも，思考や会話に多くのタスクが割り振られるようになったことが，その動機として挙げられる。
そのせいもあって，日常において音楽を聴くという行為の頻度はかなり下がってしまったものの，マイナーでユニークな曲を探すという変な趣味は相変わらず続けている。最近の僕の中でのヒット曲は，Magdalen Hsu-Li 氏の "Redefinition of Identity" だ。
http://www.magdalenhsuli.net/realaudio/redefinition.ra
Magdalen 氏は，中華系アメリカ人の女性シンガー・ソングライターだ。力強い歌声と高い歌唱力，それにポップな音楽性を兼ね備えた，ユニークで魅力的なアーティストだ。
同ページの "HEAR MAGDALEN'S MUSIC" のセクションでは，氏の楽曲の多くを RealAudio で聴くことができる。
http://www.magdalenhsuli.com/music.htm
これらの楽曲群は，全体的に聴きやすい曲調を持っており，意外と大衆性のあるもののようにも思えるのだけれど，その雰囲気に反して歌詞の内容はかなり攻撃的だ。バックグラウンドにあるのは，人種差別への反感や，バイセクシュアルの解放，現代社会に対しての批判など……そういった社会的に重みのあるテーマを，鋭い歌声によって描いている。
そのような「アクの強さ」も，言うなれば Magdalen 氏の持つ魅力の１つなのだろうと思う。
以前から Grasshopper Manufacture の "Killer7" が気になってしょうがない。
http://www.capcom.co.jp/killer7/
先日のゲームショーでは，残念ながらプレイアブルなデモは出展されなかったものの，カプコンブースのメインスクリーン上で予告編の上映を行っていた。
http://mediaviewer.ign.com/ignMediaPage.jsp?channel_id=74&ob...
"Killer7" の用いているビジュアル表現は非常にユニークなものだ。独特な調整のセルシェーダによって，全体的にシャープでソリッドな雰囲気を持つビジュアルを実現している。そこから抜き出されたスクリーンショットの１コマは，まるでスタイリッシュなイラスト作品のような格調の高さを持っている。
http://www.gamespot.com/gamecube/action/killer7/screens.html...
部分的にシャドウ処理も導入しているようで，効果的な影の演出も実現されている。
http://www.gamespot.com/gamecube/action/killer7/screens.html...
「３Ｄのイラスト的な表現」というテーマは，前作「花と太陽と雨と」においても部分的に試みられていたことだ。
http://www.grasshopper.co.jp/flower/
あの時点では技術的にも表現的にも未成熟なレベルで終わってしまっていたものが，今回は完全に「モノになっている」という印象が感じられる。プログラム面での技術力が向上していることはもちろん，それを使いこなすことによって望み通りのビジュアルを実現しているというのが，この場合の「技術力の高さ」として指摘できる所だ。
ゲーム内容については不明な点が多いものの，須田氏の書くスクリプトの面白さは既に折り紙付きだから，内容について心配することは無いだろうと考えている。僕は，普段はあまり GameCube のゲームをプレイしていないのだけれど，この作品が出たときには，真っ先に購入しようと考えている。
2003-10-10
急転直下の一日。仕事場が赤坂に移って以来，初めての徹夜作業となった。本当に災難は忘れた頃に降りかかってくるものだと思う。久々に肝を冷やされる思いをした。
今回のトラブルを通して痛感させられたことの１つに，コンソール機におけるメモリ管理の問題がある。このような地味な問題は，いつも喉元を過ぎると思わず忘れてしまうのだけれど，本来ならば常に留意しなければならない問題だろうと思う。
PC 向けのソフトウェアとゲームコンソール向けのソフトウェアの間には，様々なスタイルの違いが存在する。プロセッサの演算能力の違いや，根本的なアーキテクチャの違いなどはともかくとして（そもそも，その差は大したものでは無くなってきているように感じる），メモリの周辺に生じる制限などは，いまだに大きな差異を感じさせられる点の１つではないかと思う。一方では意識すらしなくなってきていることが，もう一方では深刻な問題を引き起こす原因となっているからだ。
PC 上でのソフトウェア開発においては，そのバックボーンに仮想メモリの機構が存在することを前提におくことができる。パフォーマンス上の問題から物理メモリの容量を考慮することはあるものの，その他の多くの瑣末な問題については仮想メモリの存在によってカバーすることが可能だ。例えば，短期的なメモリ不足はスワッピングによって補うことができるし，ヒープ領域の断片化が深刻な問題を引き起こすことはほとんど無い。メモリリークに関しても小規模なものであれば無視することができてしまう。
専用サーバのような長期生存プロセスにおいては，これらの問題 − ヒープ領域の断片化や小規模なメモリリーク等に関して，真面目な対処を行う必要があるものの，クライアントプログラムにおいては，それらはほとんど無視することのできる問題となるはずだ。例えば１ステージ毎に 4kB リークしたとして，それが深刻な問題となるのは何時間プレイを続けた後だろうか？
しかし，これらの問題は，コンソール機においては致命的なクラッシュを引き起こす原因となる。QA テスト中に一度でもクラッシュが発生すれば，それは「クラスＡのバグ」 − すなわち，品質管理上の重大な欠陥を意味する。クラスＡのバグが存在する場合，担当者が土下座でもしない限りは，その製品を発売することはできない（担当者が土下座すれば……という話は置いておくとして）。
オペレーティングシステムが提供する各種のメモリ管理の機構については，Windows NT を例にとってみると調べが付けやすい。例えば MSDN サイトの "Technical Articles" を覗いてみれば，これに関連する情報を見つけることができる。
http://msdn.microsoft.com/library/en-us/dngenlib/html/msdn_v...
http://msdn.microsoft.com/library/en-us/dngenlib/html/msdn_n...
http://msdn.microsoft.com/library/en-us/dngenlib/html/msdn_h...
http://msdn.microsoft.com/library/en-us/dngenlib/html/heap3....
http://msdn.microsoft.com/library/en-us/dngenlib/html/msdn_m...
また，東京大学の「戦略ソフトウェア特論II」に登場する David Probert 氏の講義資料も，適度に詳しい情報が載っていて分かりやすい。概論を追うだけであれば，この程度の情報があれば十分だろうと思う。
http://www.i.u-tokyo.ac.jp/ss/lecture/new-documents/Lectures...
ついでだから，演習問題に取り組んでみるのも面白いかもしれない。
http://www.i.u-tokyo.ac.jp/ss/lecture/new-documents/Projects...
これらのメモリにまつわる問題は，そもそも高度なオペレーティングシステムが存在すれば済む問題なのかもしれない。しかし，コンソールゲーム機のオペレーティングシステムに関して言えば，この先もしばらくの間は現状のような「パフォーマンス重視」の設計が続くことになるだろうと思うし，携帯機や「組み込み型ゲーム」の存在を考慮するならば，やはりメモリの制限は取り組まなければならない項目の１つとして存在し続けることだろうと思う。
2003-10-11
とりあえずバグの原因は特定できたので，修正したコードをコミットして作業は終了した。もう朝も近い時刻だったのだけれど，電車は動いていなかったので，週末ということもあって適当な飲み屋で朝まで過ごすことになった。本当の修羅場だったらこんなことやってられないんだよなあ，とか，ちょっと懐かしい感覚を思い出しながら帰宅した。
メモリリークや根本的なメモリ不足に関してはともかくとして，それらよりも表面化しにくい問題として分類されるのが，ヒープメモリの断片化の問題ではないかと思う。合計容量で言えば十分な空きが存在するはずなのに，連続したメモリブロックが確保できないが故にクラッシュが発生するというパターンだ。
ヒープの断片化が発生するそもそもの原因は，確保される領域の間に生存期間の違いが存在するためだ。生存期間の短いブロックと長いブロックが交互に配置されてしまうと，前者のブロックが解放された後も後者のブロックが「くさび」となってしまうために，連続したメモリブロックが確保できなくなってしまう。これが，いわゆる「断片化」の状態だ。
更にこの問題を深刻にしているのが，断片化がクラッシュを引き起こすケースというものが非常に限られているという事実だ。多くの場合において断片化の問題は「明らかにクラッシュを引き起こす」か，「いつの間にか解消される」かのどちらかに落ち着く傾向がある。時間の経過と共に問題を蓄積しながらも，あるタイミングにおいては回復しているわけだ。しかしそれが，何かの拍子によって臨界点を突破すると，深刻なクラッシュを引き起こしてしまうことになる。
このような現象は，簡単な手順によって再現することもあれば，非常に複雑な手順でしか再現しないこともある。特定の手順で特定の行動を繰り返した場合に，たまたま断片化が蓄積されてクラッシュしてしまう……論理的に推定される空きメモリ容量に着目しただけでは気付くことのできない問題だ。もし対処を行ったとしても，別の箇所に同じような問題が残っているのではないかという猜疑心が開発者の精神を蝕むことになる。
断片化の問題を解消するために考えられる方法のうち，最もシンプルなものは，生存期間の違いに合わせてインタフェースを分離するという方法だ。「常駐されるデータ」，「大規模かつ生存期間の長いデータ」，「小規模なデータ」などのような分類を用意し，これを厳密に適用する。簡単なチェック機構を用意することによって，運用状態の検証を行うことも可能だ。
例えば id software の "Quake" のソースコードでは，大規模なメモリブロックを "Hunk", 小規模なメモリブロックを "Zone", レベルデータの格納に利用されるメモリブロックを "Cache" と名付けて管理している。
http://www.quakeforge.net/doxygen/zone_8h-source.html
"Hunk" は上位・下位のそれぞれからメモリを確保する関数を持っている。これは，ブロックの生存期間に合わせて確保を行う位置を切り替えられるように設計されたものだと思われる（例えばフレームバッファのような常駐メモリに関しては上位から確保を行っている）。レベルデータが "Cache" に格納されるのは，特定のレベルを行き来する場合に "Cache" 上にデータが残っていることを期待しているのだろうと思う。
Quake は PC ゲームなので，これが適切な例となるかどうかは分からないけれど……まあ，おおかたこんな感じだろうと思う。あとは，データ先読み（プリフェッチ）のような機構を，空きメモリの状態に合わせて柔軟に組み込めるようになっていると良いだろうと考えている。
こうなってくると，以前購入を見送った「省メモリプログラミング」 (Charles Weir, James Noble) に興味が出てくる。
http://www.pearsoned.co.jp/washo/software/wa_soft10-j.html
以前，本屋で立ち読みをしたときは，ちょっとゲームとは用途が違うなと感じたのだけれど，開発時において柔軟性の高いメモリ管理ポリシーを提示するには，このようなファッションを取り入れる必要が出てくるのかもしれないと思う。バグを減らすということはもちろんとして，柔軟性の高いシステムを提供することが，デザイナやアーティストの「わがまま」を受け入れる上で必須な項目になると考えている。
2003-10-12
普通の休日。一昨日からの余韻でずっと寝続けていた。平日に無茶をしている分，休日にこれでもかというくらい寝ている。思わず寝過ぎてしまうものだから，今度は逆に平日に寝れなくなるという，どうしようもない悪循環が続いている……。
いまだに Battlefield 1942 と縁が切れていないのも，休日が無駄に費やされている１つの要因だ。惰性でネットゲーをプレイし続けるのは情け無いので，何とかして足を洗いたいと考えているのだけれど……何か次の「波」が来ないことには，とても辞められなさそうだ。
いつかの話に戻るのだけれど，"Joel on Software" の Joel Spolsky 氏が，自ら設計に加わったオリジナルのオフィスが完成したことを，自身のブログにおいて伝えていた。
http://www.joelonsoftware.com/articles/BionicOffice.html
氏が "Bionic Office" と呼ぶこのオフィスは，完全に密閉が可能なキュービクルに，部屋同士の相関性に配慮された独創的なレイアウト，それから，無停電電源 (UPS) を備えたコンセントや，特殊な配線用の溝を内蔵した仕事机，それに，目を休めるために壁の横に取り付けられた小窓や，休憩室の２５インチ壁掛けプラズマディスプレイなど……とにかく，IT 技術者に対して，およそ考えられる限りの配慮を尽くした超快適オフィスとなっている。
"Joel on Software" にある数々のコラムを読んでみれば分かるように，Joel 氏は基本的なスタンスとして，「優れた人材」と「適切な環境」の組み合わせが高い品質のソフトウェアを生み出す上で必須の条件になると考えている。氏は，それに適した環境を作り出し，それに見合った人材を呼び込むためにも，そのオフィスは一般的なプログラマの自宅よりも快適な環境であるべきだと述べている。例えば，仕事の後に友人とディナーに行く約束をしたならば，待ち合わせの場所としてオフィスを選びたくなる……そんな状況をイメージしているそうだ。
氏の主張は，特定の職種においては適当なものなのだろうと思うのだけれど，ゲーム制作のような「オフィス＝共同作業のスタジオ」という構図が成り立つ環境においては，必ずしも適切なものとは言えないだろうと思う。
例えば，マイクロソフトなどは職員全員に対して個室が割り当てられている上に，ビルの間はバスで移動なんていうような豪快な話をよく聞く。そのように各個人が隔離された状態において，どのように横方向への連携を保つことができているのだろうかと，少し不思議に感じることがある。
http://pc.watch.impress.co.jp/docs/2003/0910/ms.htm
まあでも，世界最高のソフトウェアメーカがそういうスタイルをとっていると言うんだから，決して間違っているわけではないんだろうな……。
2003-10-13
相変わらずの引きこもり休日。一日で平均１１時間以上寝ている。それが平日は４時間程度になってしまうというのだから，何とも極端な話だと思う。最近は何も運動をしていないし……いつかきっと何かを病んでしまう……。
今日は amazon からの荷を受け取るために，最寄の郵便集配局へと赴いた。荷の中身は Iris の最新アルバム "Awakening" と，コンピレーション・アルバム "Reconnect", それに Low Technicians の "Remembrance" だ。
http://www.cdbaby.com/cd/iris?cdbaby=9d195899f488b8ca236eec9...
http://www.amazon.com/exec/obidos/tg/detail/-/B0000AOGMR
http://www.cdbaby.com/cd/lowtechnicians?cdbaby=9d195899f488b...
先日，久しぶりに Iris のサイトを覗いてみたところ，新アルバム発売の告知が載せられていたので，さっそく購入してみたというわけだ。ついでに発売元レーベルである Diffusion Records のページを覗いてみると，Low Technicians のアルバムもいつの間にか発売されていたので，同時に発注することにした。どちらも，去年から出ると言われ続けていてなかなか出なかったアルバムだ。まあ，みんな基本的にインディーズだから，延びたり消滅したりはよくある話で……。
http://www.diffusionrecords.com/main.html
Iris の方は，初期の曲作りを担当していた Matt Morris が抜けて，ボーカルの Reagan Jones と，作曲担当の Andrew Sega （昔 "Necros" と名乗っていた Scener だ）の二人構成になっている。Reagan 氏の歌唱力には更に磨きがかかっているし，Andrew 氏のポップで厚みのある曲調は，以前の Iris に見られた「薄っぺらさ」をすっかり払拭している。ジャンル的にはいわゆる「シンセポップ」なんだけれど，９０年代の安っぽさやギラつきを再燃させるのではなく，アクを感じさせないスマートなスタイルを作り出すことに成功しているのではないかと思う。
Low Technicians の方のアルバムは，もうちょっと落ち着いた雰囲気のアルバムだ。アナクロな感じのギターサウンドと，正確で味気ないリズムマシンのビートが，奇妙に組み合わさって独特な味わいを作り出している。全体的に陰鬱な表情の曲ばかりなのも面白い。渋めの曲でダルい感覚に浸るのにはうってつけのアルバムだ……。
2003-10-14
少し前の話になるのだけれど，西田亙氏の日記において「GPS と相対論」の話が取り上げられていた。
http://www.wnishida.com/~wmemo/?date=20031009
これは，コロラド大学の Neil Ashby 教授の記事 "General relativity in the global positioning system" について触れたものだ。恐らく同じものとみられる記事を LSU のウェブ上で読むことができる。
http://www.phys.lsu.edu/mog/mog9/node9.html
しかし，もともとネタが難解なものである上に，聞いたこともない単語ばかりが並んでいるものだから，内容などはさっぱり理解することができない……。ほぼ同等の内容が九州大学の野村清英氏の記事「GPS と物理」の中で扱われているので，こちらを参照するのが良いだろうと思う。
http://maya.phys.kyushu-u.ac.jp/~knomura/museum/GPS.pdf
GPS - "Global Positioning System" は，地表を覆うように配置されている２４個の人工衛星から電波信号を受信し，そこから受信者の現在位置を割り出すという装置だ。衛星から送信される電波信号には，送信の行われた正確な時刻が情報として埋め込まれている。そこで，発信時刻と受信時刻の差を求め，得られた値を光速度で割ると，衛星と受信者の間にある距離を求めることができる。あとは，同様にして複数の衛星との距離を求めれば，それらの関係から受信者の座標を割り出すことができるという仕組みだ。
ここで重要な鍵となるのが，衛星側における正確な時刻を保つ機構だ。当たり前のことだけれど，光の速度は非常に速いため，その被除数となる時間差の値には，相当な精度が求められることになる。具体的には，数ナノセカンド（１０億分の１秒）の誤差がメートル単位の誤差に繋がるという，とてもシビアな世界だ。
ところが，この「正確な時間の保持」というものが，宇宙航空のスケールともなると，非常に難しいものとなる。衛星軌道における重力ポテンシャルの違いが生み出す赤方偏移現象や，２次ドップラー効果によって生み出される時間の膨張から，衛星上の時間と地表上の時間というものは異なった進み方を見せることになる。ゆえに，どんなに正確な原子時計を積んだところで，ただ軌道上を回っているだけで徐々に時計は狂ってしまうわけだ。
このような相対論的効果を考慮して，衛星上の原子時計は 446.47/10^12 だけ周波数を下げるという処置がなされている。しかし，これはあくまでも平均的な補正処理であり，実際には，衛星が偏心軌道をとっていることや，地球が楕円形をなしていることなどを考慮し，更に細かい補正を行う必要がある。これらの補正については，初期の衛星に搭載されていたハードウェアが貧弱だったことから，受信機側において補正を行うことが求められている。
このように，普段なら宇宙科学や素粒子物理の世界でしか登場してこないような相対性の理論が，GPS という非常にポピュラーなメカニズムの中で重要な役割を果たしている。あまりにもスケールが大き過ぎるがゆえに，具体的なイメージをつかむことすらできないその理論が，実はこのように日常の中に組み込まれていたというのが，何とも不思議な感覚だ。
更に面白いのは，実際に相対論による効果が測定されるまで，その理論が完全には信じられていなかったという事実だ。Ashby 教授によれば，１９７７年の６月に最初の GPS (NTS-2) 衛星が軌道に載せられたとき，その衛星に内蔵されたセシウム原子時計の補正装置はオフにされていたそうだ。つまり，実際に相対論による時間のずれを確認してから，改めて補正装置を接続しようという段取りだ。
測定期間には２０日が費やされ，その間に衛星と地上の原子時計の周波数を比較したところ，衛星の方が 442.5/10^12 だけ高い値を示していることが判明した。この差異は１日あたり 38,000 ナノセカンドの誤差を生み出す。これは GPS の用途としては決して無視できない量だ。そのようにして，相対論に基づいた理論の正しさが実証され，補正装置の接続が行われることになったということだ。
2003-10-15
いつものように帰宅すると，家のポストに小包が放り込まれていた。中身は Charles Weir, James Noble の「省メモリプログラミング」。一昨日 amazon で注文した商品だ。
http://www.pearsoned.co.jp/washo/software/wa_soft10-j.html
ううむ，さすがに早いなあ……。休日を待って本屋やレコード屋に行くよりも，amazon に注文した方が，よほど早く商品を手に入れることができる。ここ数年というもの，かなりの頻度で amazon を利用しているような気がする。ただ，今の家のポストは防犯設備が皆無なので，もし将来的に家を移すことがあれば，荷物受け取り用の設備を持った所を選びたいものだと考えている。
件の本，「省メモリプログラミング」の内容に関しては……ええと，何と言うか……個人的には，「目から鱗が落ちる」というような類の本ではなかった。これまでの経験の中で何となく得ていたような知識が，誰にでも分かるような文体で丁寧に解説されている。そのようなものだから，ここから新たに得られる知識というものは，実はさほど多くない。ただ，今まで漠然としたイメージとして頭の中に蓄積されていたものが，新たにはっきりとした認識として蘇ってくるという感覚は，何となく存在した。
基本的な内容は，いわゆる「デザインパターンカタログ」と呼ばれる類のものだ。ソフトウェアの動作に必要とされるメモリ容量を節約するための「パターン」が多数収録されている。それらのパターン一つ一つに対して，具体的な長所や欠点，適用範囲や実装手順などが細かく提示されており，読者の正確な理解を助けるとともに，設計時の強力な「レシピ」として使えるものともなっている。
結局の所，単一のヒープを使い回している限り，どうしても断片化の危険性は生まれてしまう。この問題に対する最も簡単な回避方法は，生存期間やブロックの大きさの違いによって複数のヒープを使い分けることだろうと思う。例えば Windows API では，HeapCreate 関数を使うことによってユーザが新たにヒープを作成することができるようになっている。
http://msdn.microsoft.com/library/en-us/memory/base/heapcrea...
細かなメモリブロックを不規則かつ大量に生成する場合は，このような関数を使って専用のヒープを用意した方が良い。そうすれば，メインのヒープを汚すことなく，気ままに確保と破棄を繰り返すことができる。
また，WindowsXP 以降には "Low-fragmentation Heap" と呼ばれる機能が用意されている。これは，任意のヒープに対して断片化への耐性を付加するというオプション機能だ。
http://msdn.microsoft.com/library/en-us/memory/base/low_frag...
具体的には，いわゆる "Segregated Storage" と呼ばれるデータ構造を利用したものであるようだ。小規模なメモリブロックを効率良く，かつ高速に扱うことができるようになっている。ただし，16kB 以下のメモリブロックしか扱うことができないため，それ以上の大きさを持つブロックに対しては何ら寄与するものがない。
しかし，メインメモリ 1GB 超が当たり前の時代になっているというのに，今更こんな機能を追加しているってのも，なんだか妙な話なのだけれど……。
調べ物をしている最中に見つけたサイトがある。Ravenbrook 社の運営する情報サイト "The Memory Management Reference" だ。
http://www.memorymanagement.org/
どういった動機でこのようなサイトを運営しているのかは定かでないんだけれど，とにかく，メモリ管理に関連する情報が驚異的な密度で集められている。特に用語集 ("The Memory Management Glossary") などは，一見の価値があるのでないかと思う。
http://www.memorymanagement.org/glossary/
2003-10-16
最近，様々な事情から，過去のプロジェクトのソースコードに修正を加えたり，データを解析したりというような作業があったのだけれど，その作業の難しさに驚きを覚えることがあった。それが他所のプロジェクトならともかくとしても，自分が書いたコードなども含まれているのだからショッキングだ。そんなに昔の話でもないのに，記憶は実にあやふやなものとなっており，相当な時間をかけなければ解析することができなかった。完全に思い出すことは既に不可能だったから，まともに解析するしかなかったわけだ……。
今の会社では，単一のプラットフォームをターゲットとして扱っている都合上，他のプラットフォームへの移植に関してはまったく考えることなく済まされている。しかし，たとえ単一のプラットフォームを相手にしていたとしても，将来的なアセットの再利用を考慮すると，決して「作りっ放し」の体勢では済まされないという事情が存在する。
アセットの再利用という話で例を挙げると，去年末に発売された「ゼルダの伝説 風のタクト」には，過去に N64 向けに発売された「時のオカリナ」の GC バージョンが収録されていた。
http://www.famitsu.com/game/news/2002/11/14/103,1037239689,8...
初回の出荷枚数を稼ぐ目的で組まれたキャンペーンなのだけれど，この手のキャンペーンとしては実に太っ腹なものだったと思う。「リメイク」してしまえば単体でも売れるタイトルであるのに，その「ネタ」をここで使ってしまおうというのが，個人的には大胆な決断であると感じた。
この GC 版「時のオカリナ」は，ゲーム内容に関してはほぼ変更が無く，セーブ・ロード等の一部システムが入れ替えてあるのみという作りになっている。実装方法については，エミュレータの線も考えられなくはないけれど……まあ普通に考えれば，データは旧製品のものをそのまま利用し，プログラムは必要な箇所のみ書き換えて対応したのだろうと思う。
コードやデータを「生きたアセット」として保つことは，存外に難しい作業であると感じることがある。そのバイト列を完全に保存することは可能であったとしても，周囲の環境はすぐに風化してしまう。時代が移り変われば，コンパイラの仕様も変化してしまうし，周辺ツールのバージョンも切り替わってしまう。アプリケーションで扱うことのできなくなったデータはコンテントとしての意味を失い始め，本当に単なるバイト列へと近づいてしまう。もっとも，だからこそ「単なるバイト列」をも活かすエミュレーション技術が持てはやされるのかもしれないけれど……。
N64 の例で言えば，ソースと同時に SGI の WS も保持しておかなければ不都合が生じるかもしれないし，それが Playstation ならば，DOS や Windows 95, あるいは NEWS ワークステーションの環境を保持しておかなければならないかもしれない（それが Windows XP で動くとは限らない！）。そもそも，開発機材なんかはメーカーに返却してしまうものだから，もう一度動かしてみようとしても，もはやどうにもならないという事情がある。
モデルデータやモーションデータに関しても，過去のツールのデータが最新のバージョンで支障無く読み込めるとは限らないし，独自形式を利用していた場合は，そのコンバータやプラグインが最新の環境で動かせるようにしなくてはならない。もしかしたら，ソースレベルから修正を行わなくてはならないかもしれないし，そもそも，ツールのバイナリやソースがまともに残されているとは限らないから用心が必要だ。ゲーム本体を構成するアセットの管理については十分な気を遣っていても，担当が個人の枠に収まってしまっているような作業に関してはあやふやになってしまっている場合が多いと思う。
ともかく，「アセットは会社の財産として管理する必要がある」という認識を常に持ち続けることが肝心なのだろうと思う。この辺りの管理はできていて当然と考えられる節があるから，各々が自己責任の意識を持って行動することが求められるのかもしれない。
2003-10-17
また別の例を挙げると，PC 版 "Metal Gear Solid" の話がある。これは移植の話になるのだけれど，オリジナルがプラットフォームに深く依存した形であった上に，内容的にはほぼそのままの移植となっていたという点で，面白い事例となっている。
移植作業を担当した Digital Dialect 社の元社員 "malkia" 氏は，この移植作業の顛末を gamedevleagure の記事に対するコメントの中で語っている。
http://www.enetation.co.uk/comments.php?user=jdfristrom&comm...
この PC 版 MGS は体験版のみプレイしたことがあるのだけれど，図らずして「完全移植」になってしまっているな，というのが率直な感想だった。モデルやモーション，テクスチャ等の素材は PS 版のものがそのまま流用されており，当時の PC ゲームの基準からすれば，かなりプアなものとなってしまっていた。また，短期間の移植作業ではシステムの大規模な改造にも着手することも不可能だったようで，固定小数点エラーから発生するガクつきや，「Ｚソート法」でペリペリめくれるポリゴンなど（Ｚバッファは用いられていない），ハードウェア面での制約も PS 版のものをそのまま引き継ぐ形となってしまっている。
コンシューマ機の世界では既に DC や PS2 が登場しており，PC のグラフィクスハードウェアも加速度的に成長を遂げている時期にあって，このような PS レベルのクオリティが維持されてしまっているという状況は，見た目のアピールの面で大きく不利な要素となっていた。ユーザとしては，PC 版なんだから PS よりも綺麗になっているに違いないと考える心理があると思うのだけれど……。
実際の移植作業は，３人のプログラマと９ヶ月の期間で行ったということだ。いずれのプログラマも PS での開発経験が無く（しかも malkia 氏の場合，最初にプレイしたソフトがこの "MGS" だった），PS 用の開発機材も与えられていない状態で移植作業を開始したというのだから驚きだ。まず最初にソースの解析を行い，データの再構成を行い，GTE + GPU 用に書かれたコードを x86 + DirectX 用に変換し，パース補正処理や独自のゲームセーブ機能などを付加し，土壇場で VR ミッションの入れ込みを行い，その上で十分なデバッグを行い……と，必要なタスクを積み上げていくと，かなりヘビーな仕事が多いように感じる。３人×９ヶ月でギリギリの線（少し鼻血が出る程度）だろうと思う。
余談だけれど，移植に伴う「改良」の一環として，主人公の顔テクスチャにちゃんとした目の形を描き込んだところ，これを却下されてしまったというエピソードが紹介されている。ウェブに載せられているスクリーンショットを覗いてみると，そのときの名残りを見つけることができる。
http://www.microsoft.com/games/mgspc/img/screens/ss_b_1.jpg
元は，下のような「ぼかされた」テクスチャが利用されている。
http://www.microsoft.com/games/mgspc/img/screens/ss_b_13.jpg
敢えてぼやけた表現を用いることでユーザの想像による補間を狙っているのに，これを不用意に描き換えてしまっては，かえって「改悪」になってしまう……という判断なのだろうと思う。
この PS 版 MGS は，現在，GameCube 版 "The Twin Snake" としてリメイクが行われている。こちらの方は，PC 移植版の質素さとは打って変わって，素材からプログラムまで全て作り直しとなっているようだ。
http://www.konamijpn.com/products/mgs_tts/japanese/
スクリーンショットが公開された頃から，モデルやテクスチャはすべて作り直しだということが分かっていたのだけれど，アニメーションやカメラの動きぐらい，少なからず使い回している箇所があるのではないかと見ていた。しかし，TGS で公開された予告編を観た後では，もはやそれさえも無く全て作り直しだろうと確信するに至った。
そもそも，今と昔ではモデルやアニメーションの作り方も違っているだろうし，かなりの量のカットが追加されているともあって，オリジナルのデータは参考程度でしかないというのが実際のところだろうと思う。
2003-10-18
プロダクトの移植の話に関しては，もう１つ面白い事例が Gamasutra の Postmortem 記事において紹介されていた。PS2 版 "Splinter Cell" の移植作業を Ubi Soft の上海スタジオが担当したという話だ。
http://www.gamasutra.com/resource_guide/20030714/hao_01.shtm...
Ubi Soft は海外の主要パブリッシャの中でも特に国際色の強い企業だ。フランスとカナダに本拠地を置くほか，全世界 22 ヶ所の事業所に約 1,900 人の従業員を抱えている。中国では上海と北京の２ヶ所の事業所に 200 人近くのスタッフを配置しており，アジア地区における本格的な制作拠点の１つとしてその存在を位置付けているようだ。
上の記事は，Ubi のモントリオールスタジオで制作されたヒットタイトル "Splinter Cell" の PS2 への移植を上海スタジオが担当したという話について，プロダクトマネージャの Wu Dong Hao 氏がその顛末を記したものだ。僕は Ubi が上海に制作スタジオを持っているということさえ知らなかったし，ましてやそこが "Splinter Cell" の移植を担当したということなど知る由もなかった。しかし最も驚くべきことは，このプロジェクトには総勢 80 人ものスタッフが動員されており，そのマンパワーによってたったの４ヶ月で移植作業を完了させてしまったという事実だ。
"Splinter Cell" は，Xbox の機能をフルに活用したタイトルであるため，その内容を完全に維持したまま PS2 へ移植することは不可能だ。モデルやテクスチャの類は適切なダウングレードを行わなくてはならないし，場合によっては一部の仕様を削らなくてはならないかもしれない。しかも，ただ闇雲に PS2 のスペックへ落とせば良いというものでもなくて，全体として統一されたクオリティを保ちつつ加工を行わなくてはならない。たとえ人数を大量に投入できたところで，逆に難しくなってしまうのがこの点だ。
プログラム側の作業もかなり大掛かりなものとなっている。Splinter Cell はエンジン部分に Unreal Engine のカスタムバージョンを利用しているのだけれど，ゲームプログラム側に提供されるリソースの量は，この Unreal Engine のスペックに制限されることになる。よって，まずはエンジンの仕様と挙動を完全に把握し，ゲームプログラムやデータの方でどの程度のリソースを扱うことができるのかという点を見極める作業から始めなくてはならない。
また，このゲームの重要なアピールポイントの１つともなっている各種視覚エフェクトの類は，すべて PS2 専用に作り直す必要があったとのことだ。Xbox 版のコードが再利用不可能であることは早々に判明しており，すべてスクラッチで書き直すという作業が行われている。この作業については，本格的な移植作業に先立って設けられた半年程の研究期間において実装が行われており，そこで十分な結果が得られたために，その後の作業を円滑に行うことができたということだ。
余談だけど，Unreal Engine 自体の移植は Secret Level 社が担当したようだ。
http://www.secretlevel.com/main.php?page_type=product_pages&...
これらの移植作業だけでも随分大変そうなのだけれど，それに加えて，全体的なゲームバランスの調整や，新たなレベルの追加まで行ったというのだから，実に気合が入っているものだと思う。最終的には上海スタジオの人員だけでなく，カナダのオリジナルスタッフや，フランス・イタリアのスタッフまでかき集めての大騒動となったようだ。
上の記事の中で Wu 氏は，「悪かった点」の１つとして，データの受け渡しの際に発生した問題を挙げている。
Splinter Cell (Unreal Engine) では，各種のデータを独自アーカイブ形式へとパックし，ゲーム側ではそのアーカイブデータのみを扱うという手法をとっている。従って，レベルデザイナは各レベルのアーカイブデータを提出するところまでが仕事として定められており，そのアーカイブの元となる素材データに関しては，各自の責任において管理することが求められている。
このように，「最終データさえ存在すれば正常にゲームをビルドすることができる」という状態になっていると，各個の素材の管理についてはどうしてもずさんになってしまう傾向があるようだ。使われているはずの素材が迷子になってしまったり，単純な勘違いから名前がイカれてしまったり，最終データよりも古いバージョンの素材が残されてしまったり……日常的に様々な問題が発生し，しかも，誰もそれに気づかないまま放置されてしまう。
Splinter Cell の移植作業においても，このような問題は実際に発生してしまっていたようだ。「データが欠落している」と指摘する移植チームに対して，オリジナルチームは「データは渡した」と返答を返す。「（ちゃんとデータをよこせよ！）」……「（ちゃんと探してないんじゃないの？）」……そんな感じのやりとりが何度か続けられ，両者の間に不穏な雰囲気が生み出されてしまうまでに発展してしまったと Wu 氏は記している。
最終的にこの問題は，アーカイブから元素材と同等のものを抽出するツールを作成するという，言わば移植チーム側の自力的手法によって，何とか解決することができたようだ。
このような素材の管理に関する問題は，どのような方式にも必ず一長一短が存在しており，誰もが逃れられない苦しみを味わうことを運命付けられている。それを多くの人が痛感しているだけに，プロダクト管理手法の話題や，Alienbrain のようなアセット管理ツールに注目が集められるのだろうと思う。
2003-10-19
Ubi 上海スタジオにおける "Splinter Cell" の移植の話には，色々と興味深い情報が含まれている。僕は中国のゲーム事情にはあまり詳しくないので，このように本格的な制作組織が存在するということ自体が初めて得られる情報だった。
http://www.gamasutra.com/resource_guide/20030714/hao_01.shtm...
大規模制作チームを投入しての短期間移植プロジェクトという事例自体がかなり珍しいものであるだけに，そのプロダクションの管理手法もかなりユニークなものとなっている。
データの移植作業は，レベルデザイナとアーティストから構成される２・３人の小チームによって行われる。そのような小チームが全体では十数組存在しており，それらが並列に作業を行うことによって移植が進められる。いわゆるマトリクス方式のマネジメント手法だ。ここでの作業の工程は研究段階において定型化することに成功しており，実際の作業はかなりスムーズに進めることができていたようだ。
それぞれの作業の評価は完全な結果主義に基づいて行われる。それも，約２週間という非常に短い期間で評価を繰り返し行ったそうだ。そこで良い評価を受けたスタッフは月給に賞与が加えられ，逆に悪い評価を受けたスタッフは厳重な注意を受けることになる。あまりにも悪い評価が続くようだと，途中で解雇に踏み切ることもあったと述べている。そのように厳密かつ積極的な制作管理を行うことによって，チーム内における高い士気の維持を可能とし，スケジュールの厳守を実現することができたということだ。
もう１つ興味深かったのは，「悪かった点」として「文化の壁」を挙げていることだ。
"Splinter Cell" の移植作業には上海のメインスタッフのほか，カナダやフランス・イタリアのスタッフが参加している。しかも，これらのスタッフは遠隔で分担作業を行ったわけではなく，全員が上海オフィスに集まってのコラボレーションを試みたということだ。
当初は，既存のチーム内に国外からの人材を混ぜ合わせることによって，完全なコラボレーションの実現を目指していたようだ。しかし作業が進むにつれ，言語や文化の壁を乗り越えることが予想以上に困難であることが判明し，結局，「現地チーム」と「外地チーム」の２つに分かれて運営を行うという方針に落ち着いたようだ。
ここで問題になってくるのが，リーダーが２人存在することによって生まれる指揮系統の乱れだ。「現地チーム」と「外地チーム」にはそれぞれ独自のリーダーが存在するのだけれど，このリーダーは基本的に全チームに対して影響を与える権限を持っている。そうなれば困った問題が発生してしまうのは想像に難くないことだ。例えば，１つのチームに２人のメインプログラマが居て，それぞれがまったく異なった意見を振りかざしていたとしたら，どうだろう？ しかも，その２人がまったく異なった文化やバックグラウンドを持つ人物だとしたら……。
また，国籍ごとにチームが分離されたことによってセクショナリズムの問題も発生してくる。特に，上司との協調を重視するという現地スタッフの性格と，個人での問題の解決を好むという国外スタッフの性格は，あまり組み合わせの良いものではなかったようだ。結果的にお互いが余計な競争心を持ってしまい，協力的な態度が失われてしまうことが度々あったと Wu 氏は述べている。
2003-10-20
国際的な連携によるゲーム制作の難しさについては，前述の記事と同じ頃に掲載された Gamastura の Postmortem 記事 "Managing An International Remote Development Team" の中にも語られている。
http://www.gamasutra.com/resource_guide/20030714/meltzer_01....
著者の Max Meltzer 氏は，この記事の中で，Ubi の最新タイトル "XIII" と，その前のタイトル "The Ire Sequence" （未発売）において，複数の国籍の企業を連携させて制作を行ったことを述べており，そこで発生した問題とその対処方法について簡単な解説を行っている。
今冬発売の Ubi の主力タイトルでもある "XIII" では，ネットワーク対戦の部分の開発を，スウェーデンの制作会社である Southend Interactive 社に依頼している。
http://www.southend-interactive.com/
もう１つのタイトル "The Ire Sequence" の方は，インディアナポリスに存在する小さな内部制作チームが中心となって，そこから世界中の制作会社に対して仕事を発注するというスタイルをとっている。その発注先の企業には，イギリスや南アフリカ，ウクライナ，ロシア，インド，等々の多彩な国々が含まれている。このように多くの国外の企業を利用する動機は，主に人件費の削減という目的にあるようだ。
Meltzer 氏は上の記事の中で，国外の制作会社と連携を行うためのノウハウを提示しつつ，いくつかの「落とし穴」の存在について述べている。国際連携において最もコアな問題となるのは，言語の違いや文化の違い，それから生活時間帯の違い（日付のずれ）などのように，国境を越える際に必然的に存在する「壁」の問題だ。それ以外の問題に関しては，国内外を問わず外部の制作会社を利用する際に挙げられる注意点が多いように思える。
例えば，"The Ire Sequence" がプロジェクト半ばにして終了してしまった理由の中でも最も大きなものは，「制作会社の性質が変わってしまったから」という，実にシンプルなものだ。これはもはや，国際連携がどうこうという話とは別問題なのではないかと感じた。
この記事の中でも，アセット管理の問題に関していくつかの反省点が挙げられている。前の "Splinter Cell" のような単純な移植作業であれば，必要なデータを確実に送り届けるだけで事が済むのだけれど，開発の過程において連携を行うには，もっと多くのデータを頻繁にやりとりする必要がある。そこで貧弱なインフラしか存在しないとなると，どうしても作業が煩雑化してしまい，作業場の手違いが頻繁に発生することはもはや避けられなくなる。
Meltzer 氏は "The Ire Sequence" において，郵送（！）や電子メール，FTP 等のインフラを利用してデータの交換を行ったと記している。郵送などのような方法でデータの交換を行っていれば，いずれ問題が発生することは容易に想像できるのだけれど，メールや FTP によるデータの交換も，結局は五十歩百歩なレベルだ。各ロケーションに存在するアセットを統合し，常に最新の状態に同期させるという目的においては，これらのインフラ単体では無力に等しい。
このような問題に対し，例えば Electronic Arts 社では，各制作スタジオとヘッドクオーターに Alienbrain を導入することによって，厳密なアセットの管理を実現しているようだ。
http://www.nxn-software.com/comp_prro_prre_pu_020129.php
http://www.nxn-software.com/prod_exte.php#rcs
Alienbrain の Remote Collaboration Server (RCS) を使えば，遠隔地に分散するアセットをどこからでも透過的に扱うことができるようになる。データの交換には SSL 暗号化によるセキュアな通信路が用いられるから，機密漏洩対策も十分だ。また，Alienbrain にはプロジェクト管理を行うための各種ツールも搭載されているため，アセットの制作状況とスケジュールを照らし合わせつつ，統合的に制作進行を管理することもできるようになる。
このように考えると，Alienbrain のようにアセットとプロジェクトの管理を統合的に行うツールなどは，遠隔での連携を実現するにあたって必須のインフラとして求められるように思える。その用途に対して Alienbrain が十分な機能を本当に提供できているかどうかという点に関しては，判断を留保しておくとしても……。
2003-10-21
最近は仕事の上でも C++ のコードを扱う機会が多くなってきた。今まではベタな C ばかりだったので，テキストエディタなどは vi で十分と考えていたのだけれど，それが C++ ともなると VisualStudio の IntelliSense 機能などが羨ましくなってくる。
http://www.atmarkit.co.jp/fdotnet/special/vs2003/vs2003_02.h...
今のままでも特に苦労はしていないのだけれど，ちょっと試しに他のエディタを使ってみようかと考えている。
とりあえず手を付けてみたのは，コーディング専用エディタとして有名な製品 "SlickEdit" だ。
以前は日本語での編集にうまく対応できていないことから却下していたのだけれど，最新バージョンの "v8" ではその問題も解決されているようだ。とりあえず Unicode に対応しているほか，各地域の標準的なエンコーディング（例えば SJIS や EUC-JP など）にも対応している。
http://www.slickedit.com/products/pr_languages.php
"Tools -> Configurations -> File Options -> Load" にある "Encoding" の項目を適切な値に設定し，あとはフォントの設定さえ行えば，問題無く日本語が扱えるようになるはずだ。
体験版は日本の代理店からダウンロードすることができた。ライセンスコードの請求には，まあ，Mailinator なり何なりを利用すればいいだろう……。
http://www.solitonwave.co.jp/product/vse/download3.htm
早速使い始めているのだけれど，至れり尽くせりのコーディング補助機能に驚きさえ覚えている。VisualStudio のコーディング補助機能も相当にパワーアップしているようだけれど，SlickEdit の方もそれに負けず劣らずといった感じだ。特に，ヒント機能で表示されるコメントが JavaDoc の書式に対応しているので，Doxygen 向けにコメントを書いてあるソースの場合，上の図のように詳細なコメントが表示される。ううむ，これは結構いけてるかも……。
しかし，"Visual C++ .NET Standard 2003" が 17,800 円で買えるとあっては，SlickEdit の $300 という価格は微妙なものだと思う。それならば，エディタ的な機能については少し我慢するとしても Visual C++ を買っておいた方が良くはないだろうか……。
今は物珍しさもあって面白がっている状態なのだけれど，しばらく経てばその興奮も醒めて，冷静に評価することができるようになるだろうと思う。試用期間は３０日もあるのだから，期限一杯まで使い切って，それから判断を下そうと考えている。
2003-10-22
SlickEdit をインストールして以来，エディタ上のフォントの設定に凝ってみている。Windows XP では標準で Font Link の機能が設定されていることから，欧文フォントでも問題無く日本語を表示することができるようだ。
http://blue.ribbon.to/~akene/fontlink.htm
SlickEdit はプロポーショナルフォントでの編集にも対応していることから，他のエディタと比較してより多くのフォントを利用することができる。例えば僕は，Windows に標準で入れられている "Verdana" フォントが好きなので，Verdana の 10 ポイントを "Unicode Source Windows" フォントとして設定している。
更に，Windows XP から標準で搭載されている "ClearType" の機能を有効にして，フォントの表示にアンチエイリアシングを付けてみた。職場のディスプレイは CRT なので ClearType の本来の機能からは外れているような気もするのだけれど，ClearType を有効にしないことにはアンチエイリアシングの機能が働かないようなのでそうしている。それに，CRT だからと言って ClearType の効果がまったく無いというわけではなさそうだ。
http://www.atmarkit.co.jp/fpc/xp_feature/cleartype/cleartype...
昔はプロポーショナルフォントでコードを書くなんてことは考えもしなかったけど，こうして実際にやってみると，さほど違和感も無い。それに，アンチエイリアシングが効いているおかげで，小さなフォントの視認性も向上したように思える。ううむ……。
2003-10-23
コーディング環境として VisualStudio を導入する際に，唯一の障害として存在していたのは，同ソフトにおいて EUC 漢字コードを扱うことが難しいという問題だった。Windows 環境では日本語コードとしてもっぱら SJIS を使うことになるのだけれど，UNIX 環境においては SJIS 漢字コードの存在は好まれない。そうした事情から，双方の思惑が衝突してしまうという事情があった。
この際だから，ソースコードの記述にも UTF-8 を導入することによって，この辺りのややこしい問題を取り払うことができないだろうかと考えている。UTF-8 コードは，ものすごく簡潔に表せば「８ビット目が立っている場合，コードが次のバイトまで伸びる」という規則性を持ったエンコーディング方式だから，SJIS にあるような「２バイト目が ASCII での特殊コードに相当するために発生する障害」なども避けることができるはずだ。
とにかく，ユニコードと UTF-8 の存在のおかげで，多言語テキストを扱う際に発生しうる様々な問題をスマートに解決することができている。特に，マイクロソフト製品がこの辺りの問題を率先して解決してくれているのが有難い。ゲーム中に利用するテキストデータなども，とりあえず Excel 上で管理するようにしておけば，ローカライズを行うときにも戸惑うことなく済ませることができるかもしれない。
マイクロソフトは，ソフトウェア産業において，最も国際化対応のノウハウを蓄積している企業であることは間違い無いだろうと思う。同社の "Global Development and Computing Portal" サイトでは，Windows ソフトウェアを国際化対応させる際に必要となる情報の数々が，非常に充実した形で公開されている。
http://www.microsoft.com/globaldev/default.mspx
特に "Ask Dr. International" のコーナーなどは面白いかもしれない。マイクロソフトって，何気にこういう仮想人格キャラクタを作るのが好きだと思う……。
http://www.microsoft.com/globaldev/DrIntl/columns/default.ms...
特に，新しい中国語コードである "GB-18030" を扱った記事 "Ask Dr. International, #15" など必読だ。
http://www.microsoft.com/globaldev/DrIntl/columns/015/defaul...
まったく，ＣＪＫコードは言語の魔境というか……当事者の一員である日本人でさえも嫌気を覚えるほど複雑な世界であるのに，ましてや欧米圏に住む技術者などにとっては，できる限り関わりを持ちたくない世界であることは間違いないだろうと思う。
2003-10-24
そういえば，先日の "Joel on Software" の記事では，Joel 氏が Unicode について語っていた。その名も "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)" だ。
http://www.joelonsoftware.com/articles/Unicode.html
内容は，英語圏に在住するソフトウェア技術者も Unicode に関する知識を備えなければいけないという忠告とともに，その簡単な導入を行うというものだ。過去に存在したエンコーディング方式の問題から，国際標準規格としての Unicode の発生までを，本当にざっくりと解説している。また，UCS コードや UTF-8 等の各種エンコーディング方式に関する説明も行っている。
たしかに，このようなレベルでもいいから，世界中の技術者が Unicode に対して理解を持つようになれば，いろんなソフトウェアがもうちょっと使いやすくなるのかもしれないと思う。
日本語の資料としては，Wikipedia の「文字コード」の項が参考になるかもしれない。
http://ja.wikipedia.org/wiki/%E6%96%87%E5%AD%97%E3%82%B3%E3%...
この Wikipedia 自身も Unicode の恩恵を受けて存在することができているという事実は，ちょっと面白いことだと思う。それにしても，最近の Wikipedia は恐ろしく内容が充実してきている。ベースとなる英語コンテンツだけでなく，日本語で書かれた項目も増え続けているのが驚きだ。献身的なコントリビュータの活躍があってのものなのだろうと思う。その貢献に感謝しつつ，有難く使わせていただいている。
2003-10-25
Unicode やマイクロソフト製品云々で思い出したのだけれど，マイクロソフトの秘密兵器（？） "Microsoft Office InfoPath 2003" の発売日が今日だったようだ。
http://www.microsoft.com/japan/office/infopath/prodinfo/defa...
http://www.atmarkit.co.jp/fdotnet/special/infopath/infopath_...
遂に XML との完全な統合を果たした Office 製品の登場ということで，データ管理を行う際の強力なツールとなってくれるのではないかと，少し期待している。
ただ，なにぶん触ったことが無いだけに，どういう位置付けのソフトになっているのか把握しかねている部分がある。一見したところ，XML データベース的な色の濃い（要するに XML 版 Access とか，そんな雰囲気の）製品のように感じられるのだけれど，時には「要するに XML エディタ」などという不穏な記述が見られることもあるし，逆にドキュメンテーションの機能が強調されていることもある。
公式サイトの解説も，なんだかいまいち的を得ていないように見えるし……とにかく，実物を触ってみないことには何も始まらなさそうだ。
最も興味があるのは，「フォーム」の形式に関する部分だ。InfoPath では XML Schema で記述されたスキーマから自動的にフォームを生成することが可能であると謳われているのだけれど，単純な表構造として表されるもの以上の構造を持つスキーマを，どう「フォーム」で扱うのだろうかと考えると，自分ではなかなか想像のつかないところがある。
とにかく試しに触ってみたいのだけれど……会社の方でサイトライセンスを取る予定は無いのかな……むむ。
2003-10-26
Microsoft と国際化ときて，個人的に連想するのは，Raymond Chen 氏のブログ "The Old New Thing" だ。
http://blogs.gotdotnet.com/raymondc/
この Chen 氏のブログでは，Microsoft が Windows という本格的な GUI 環境を創り上げて行く上で体験することになった出来事の数々が，惜しげもなく公開されている。つい先日も，「本にしたら売れるのでは？」なんてコメントを寄せられていたのだけれど，Chen 氏曰く，ちゃんとした本を書こうと思うとどうしても筆に詰まってしまうそうで，このブログのように思いつくままに書き記すスタイルの方が性に合っているということだった。まあ，そのおかげで，毎日面白いコラムを読むことができているのだけれど……。
Chen 氏が語るエピソードの中には，国際化に関する話題も沢山含まれている。それは，Microsoft が国際化に対して細心の注意を払い続けていることが分かるものであるし，時には，その気遣いが逆に奇妙な仕様を生み出してしまっていることもある。
例えば "Why you can't rotate text" の項では，テキストを縦方向に表示することがいかに難しい問題であるのかということを，多言語対応の観点から述べている。横書きテキストでさえ様々な例外に対処しなければならないのに，ましてや縦書きともなれば，その諸問題は一層複雑さを増してくるわけだ。
http://blogs.gotdotnet.com/raymondc/commentview.aspx/751e593...
この話の発端となった記事 "When I dock my taskbar vertically, why does the word "Start" disappear?" も面白い。これは，「タスクバーを縦にするとスタートメニューの『スタート』の文字が消される」という奇妙な仕様について解説した記事だ。
http://blogs.gotdotnet.com/raymondc/commentview.aspx/f5676cc...
その理由は，単に「スタート」の文字を途中で切って（クリップして）しまうと見た目が格好悪くなるから，というものなのだけれど（ちなみに十分な幅が与えられれば文字は復活する），それ以外にももう１つ，怪しげな「逸話」について触れられている。
もう１つ，"Why doesn't the clock in the taskbar display seconds?" という記事がある。記事の内容は，「なぜタスクバーの時計には『秒』が表示されないのか」という疑問に対して解説を行ったものだ。そしてその理由は，「Windows 95 が発売された当時，秒数の表示はマシンパワーを余計に消費する原因となりうるものであったから」と述べられている。
http://blogs.gotdotnet.com/raymondc/commentview.aspx/ae6637d...
面白いのは，そのコメントの中のやりとりだ。「秒数表示はいいから，アナログ時計が欲しい」という意見に対して Chen 氏は，国際化の観点からの判断によってアナログ時計の搭載は見送られていたという，驚きの事実を述べている。
なんでも，マイクロソフトが行った調査によれば，ある地域（国）において「不安になるほど高い割合の人々」がアナログ時計を読むことができなかったという結果が出たそうだ。その地域がどこであるかは明らかにされていないものの，無視できない数の人々にとって意味の無い機能を率先して搭載するわけには行かないという事情があったようだ。
「デジタル時計は可でも，アナログ時計は不可」なんて，ちょっとにわかには信じ難いことだけれど，そうやって狭い範囲での常識を潰し続け，より多くの範囲で通じる共通項を探し出していく作業が「国際化」と呼ばれる過程の実態なのだろうと思う。
2003-10-27
まあ，そんなわけで，Raymond Chen 氏のブログは毎日チェックしている。ソフトウェアに関係ない日常的な話も面白いから不思議だ。
最近は趣味でスウェーデン語を習っているようだ。ヨーロッパの文化に関する話題がよく出てくる。
http://blogs.gotdotnet.com/raymondc/commentview.aspx/a36a8bd...
北欧情勢とか全然分からないから，その，ノルウェーとかフィンランドはＯＫでも，デンマークはダメっていう，基準の付け方が分からなくて可笑しい。そもそも，この４国の位置関係がまったく把握できていない……島根と鳥取の区別もつかないのに，ましてやスウェーデンとフィンランドの区別などできるはずがないのだけれど。
http://www.mofa.go.jp/mofaj/area/europe.html
北欧の近代史はとてもシリアスだ。厳しい環境の中で苦労を味わいながらも，最終的には復活を遂げるというところが面白くて，興味を誘われる。
http://www.google.co.jp/search?hl=ja&ie=Shift_JIS&q=%83t%83B...
腐ったニシンについては……適当に google をかけてみれば見つけることができる。
http://www.google.com/search?lr=lang_ja&q=surstromming
まあ，とりたてて面白いものでも無いんだけれど……そういうネタが出てくるぐらい，本当にヒマなものなんだろうと思う。
2003-10-28
ちょっと野暮用があって，基数ソート法 (radix sort) について調べていた。