以下は私ことRyuKの個人的感想の叙述です。ご連絡は まで。
Monologue
2009-04-15
Whisky-Tango-Foxtrot
更新を再開しようかと思ったのだが、まだネタがないので仕方なくblog風に先日撮った写真(芝公園にて、2009年4月3日)で茶を濁す。
昨年も書いているように、本当はサイト自体を何かのCMSかblogツールにいい加減移行したいと思っていて、そのくせ時間がないので踏み切れないでいる。
VS2008はやっと自分のPCにインストールしたところで、昨年書いた課題に取りかかる以前の段階で1年以上足踏みしてしまっている。ただその間に色々な事柄が起き、以前描いていた計画も、実装に取りかかる遙か以前の段階で既に再検討を余儀なくされている。具体的には、DICEに関して、ある部分のみC++/CLIを用いて.NET化することを考えていた。それというのも、C++もそろそろ潮時かと考えて、C++を利用する部分を徐々に縮小させることを意図していたからであった。現在もその方針自体は誤った物ではなかったと考えているが、今それを為すべきか、そのための時間があるかということを熟慮すると、同じ時間を使うにしても他に為すべきことがあるのではないかという結論に至った。
また、去年計画だけして頓挫したものとして、どのみち日の目を見ないのであろうから忘れないうちに書いてしまうと、RTMPをDICEに実装することを考えていた。それというのも、DICEのプロトコル実装の試金石として商業的に意味のありそうなプロトコルを是非実装しておきたかったのと、Flashとの親和性を高めておきたかったという事情がある。サーバー用のソフトウェアスタック(と.NETで作った簡易クライアント)しかコントロールできない私にとって、Flash + JavaScriptはクライアントアプリ作成のためのRAD環境たり得た。ところが状況は変わり、C++の非常に有望なクライアント用ソフトウェアスタックが自由なライセンスの元で利用できることになり、今はそれをどう活かすかについて思案している。勘の良い諸兄ならそれが何かもうお分かりだろう。
2008-01-15
Denial ain't just a river in Egypt
久々にDICEの新バージョンをリリースすることが出来た。今回は互換性を破る変更もあったので、インクリメンタルに新バージョンをリリースするという以前の目標はひとまず置いて、必要な部品が全て入るまで待たざるを得なかった。ついでというわけではないが、自分のハンドルもKLからRyuKに変更した。KLでは短すぎるというのが主な理由だが、元のサイト名(KLassphere)をとある理由で変更したいという動機が先に存在したかも知れない。そちらはryukwareへ変わっている。サイトのデザインもDICEのWeb UIで採用しているテンプレートを再利用して改装した。webサイト自体も去年秋から新アドレスへ移転している。
実はこのページもいよいよblogツールで生成するように変更しようかと思っていて、去年初めに各種ツールを検討してみた。が、一番最初に触ってみたMovable Typeがあまりにダメダメだったのでこの案はそこで一旦棚上げになってしまった。ここのサーバはMySQLが使えるので環境は問題ない。ただ自分としてはデータのXCOPY deploymentができるSQLiteを使いたい。SSHも使えるのでSQLiteのビルドも出来、そこまでは問題なかった。問題だったのは、肝腎のMTの管理者ツールが非常に使いにくいということだ。カスタマイズの際の独自マークアップも汚く、そんな下らない物を学習する気など毛頭無い。使える既成テーマもろくにない。何故MTが最初の候補に挙がったかというと、このページの古い記事をインポートしたときに、記事の日付をオリジナルの物に変更したいという事があって、さしあたりそれが可能なのがMTであったというわけだ。いつか機会が有れば今度はWordPressを試してみようと思ってはいるけれどSQLiteを用いるのにこちらはこちらで手間がかかるようで痛し痒しである。
他人の作ったツールを使う場合の居心地の悪さというものはソフトウェアを書く際に利用するミドルウェアについてもしばしば感じることになる。オープンソースでソースコードとシンボルが手に入るならともかくそうでない場合は、いや手に入る場合であったとしても、分厚いミドルウェアの利用者はハッカーたることを強制されてしまう。そういう意味ではWindowsというものも巨大なミドルウェアであって、最近はMSDNのMS社員blogで様々な情報公開が行われていて助かることしきりである。しかし実態として見れば、不十分なAPIドキュメントあるいはAPIそのものについての補遺を非公式の場で行うことは現状を追認するエクスキューズでしかない。ミドルウェアによってもたらされる利益がある一方で、ミドルウェアを原因とするフラストレーションは相手がはっきりしているだけに顕在化しやすい。Windowsのような、選択の余地がないケースでは尚更である。
DICEについて言うと、今回からSSPIを使うのをやめてOpenSSLに切り替えた。もう1つの変更は逆方向で、これまで8年間STLportを使い続けてきたのをやめて今回からVC++のC++ライブラリを使うように変更した。VS2005からSxSになってインストールが面倒になったにも関わらず、である。C++標準ライブラリの変更自体は、これまでデバッグの関係で両対応にしていたので何ら問題はない。STLportの利点は、かつてVC6時代にあったiostreamやロケールのバグが修正されていたり、SGI STL譲りのhash_map、ropeといったコンテナ、それからmalloc呼び出しを抑えるノードアロケータ、さらに名称の由来である移植性などである。加えて、後年メインテナーが変更になって以来、iostreamのさらなる修正やbig fileサポート、組み込みプラットフォームサポート、ユニットテスト追加、basic_stringのスタティックバッファ、+=ではなく+でbasic_stringを繋げる場合の最適化、ノードアロケータのロックフリー化、など様々な改良が施されてきた。VC++添付のライブラリはDinkumwareという会社のOEMで、そこのP.J. Plauger氏(以前Cマガジンで連載があった)が去年だったかニュースグループでSTLportをかなり口汚く論難して反論に遭っていたのを見たことがある。
STLportを捨てることを決めたのは、VS2008の機能リスト中にSTLとマネージド型のマーシャリングが自動的になされるといった.NET絡みの親和性を見つけて、これはもう避けられないなと感じた事による。STLportを使っていると他のC++ライブラリと問題が起こることが多くその度に苦しめられた一方で、長年使ってきたという既成事実のおかげで慣れてきていたのも事実である。それでも、マルチコア環境でSTLportノードアロケータが実際はmallocに劣るというテスト結果(OSのヒープアロケータの薄いラッパーであるmallocの方がスレッドやスレッドローカルデータについてよく知っているのだから当たり前だ)や、VC++がC++例外のソースコードを提供していないせいでSTLportを使う場合もVC++のdllが丸ごと必要になるという問題は以前から不愉快に思っていた。ノードアロケータはユーザランドでのメモリリークになるのでそれと引き替えにパフォーマンスが得られるならと思い許容していたが実はそうではないというのは特にショックであった。また、DICEではそもそもiostreamを使っていないのでその部分でのSTLportの恩恵は全くない。STLportをやめてみてまず最初に判明したのは、これまでIntellisenseが正常に機能しなかった原因はSTLportにあったということだ。てっきりLokiが問題なのだと思い込んでいたが、そうではなかった。当然、MSVCのC++ライブラリだとSTLコンテナやbasic_stringの中身もデバッガで易々と見ることが出来る。唯一勿体ないと感じるのはbasic_stringの最適化くらいで、これもどうしても無ければならないという類の物でもない。むしろ、デバッガでbasic_stringの中身を見るときに一々スタティックバッファとダイナミックバッファの両方を見たりせずに済むようになってせいせいした。unordered associative container (hash_map)も今後TR1絡みで動いていくだろうから変更にはいい機会だったと思う。
他方、VS2008には困ったこともあった。ATL属性が廃止になっていて、実はDICEのサービスはこれを使っている。しかし、実際に汚い物なので、廃止されるのもむべなるかなといったところである。今回のDICEは、こういったWindows世界での波風からできるだけ逃れるというのも一つのテーマになっていて、上記のMSVCのC++ライブラリへの回帰は残念ながらそれに逆行するが、このページの2006年11月30日の項で述べたweb UIへの移行はついに達成した。web UIでカバーしきれない部分は、これもMicrosoftの束縛の象徴であるMFCを使っていたDICEAdminShellを廃止し、DICE Managerという、機能を最低限に絞ったヘルパーアプリケーションをC#/Windows Formsで作って新たに入れた。2006年11月30日の項でも書いたようにMFCは本当に無茶苦茶で、DICEAdminShellを廃止したのもMFCに起因している。VS2003からVS2005に移行したときにコンパイルし直したところ、XPでは動くのにWindows Server 2003では動かないようになってしまったのだ。VS2008では驚くべき事にMFCがまだ残っていて機能拡張までされているそうだが、この辺で引導を渡してやっていた方が結果的に各方面が幸せだったのではないか。DICEの.NET webアプリケーションコンテナもVS2005移行に伴って.NET Framework 1.1から2.0に移行し、マネージドコード部分に多少書き換えを要した。.NET Framework 3.5が2.0ベースであるのは賢明な方針である。
Web UIは、それなりに道具が揃うとかなり楽に作れる。prototype.jsに代表される外部のAJAXライブラリは一切使わず、自前でフレームワークを作った。どのみちIDEが無いのだから大して手間は変わらない。無意味にファットなライブラリに興味はなく、また標準ライブラリを書き換えてあったり、一旦導入すると以降はそのライブラリのスタイルを強要されたりするのも煩わしい。道具の一つとして、PHPのSmartyのようなテンプレートエンジンをJavaScriptでXHTMLのカスタムタグとDOMを利用して作ろうと思ったところ、XML名前空間やxhtmlについてIEはIE7でもサポートがろくになされていないのがわかり、Firefoxにせよapplication/xml+xhtmlが必要になるため、仕方なくspanタグを使って作った。もう一つテンプレートエンジン絡みで参ったのは、<p>などのブロックタグが実行時にJavaScriptによって他のブロックタグの内側に挿入されると、IEが「未知の実行時エラー」を出すことだ。勿論正しい動作だが普段はエラーに寛容なIEらしからぬ振る舞いで、VSのデバッガでもよくわからない部分へ行くので原因を探すのに苦労した。今のところweb UIは通常のwebページの外見で、web IRCクライアントでせいぜいタブインターフェイスをサポートするくらいだが、将来的にはwebデスクトップに必要なMDIをサポートできるようにきちんとウィジェットクラスの階層を定義できたらと思っている。今回は、デモとして、管理者用にリモートファイルダウンロードマネージャを入れた。GetRightやIrvineに似た機能をwebから利用できる。サポート機能はまだプリミティブでベーシック認証やリザルトコード302などはサポートしていないが、HTTP/1.1のchunked encodingは完全にサポートしているのでPerl/Rubyで以前書いたツールのスーパーセットになっている。
Web UIについて書いていて今気付いたが、DICEに新しいライブラリをもう一つ導入している。メンバー登録時に表示されるCAPTCHAを、GDI+を使って実装した。今回Vistaを正式サポートした際に、諸々の理由でWindows 2000を動作環境から外したので、これが可能になった。とはいえGDIを使えば済む話でパフォーマンスもそちらの方が犠牲にならないものの、GDI+は何かと楽である。オープンソースの画像ライブラリだと、最近はFirefoxなどで使われているハードウェアアクセラレーションが入ったCairoが一番有名だろうか。ただ、これも他のオープンソースライブラリの例に漏れずlibpngなどに依存しているので、環境を作るのに労力が要る。昔FreeBSDのサーバで使うC++の掲示板用にCAPTCHAを入れた時にはpaintlibというクロスプラットフォームライブラリを使っていて、これは2年前に開発中止になってしまっている。
さて、今後は、DICEについてもう一段さらにジャンプを予定している。それが済んだらようやっと頻繁にリリースを出来る環境が出来るのではないかと思う。ゲームの方は、かなりの長期間離れていた後に、最近UT3が出たので下手ながらたまにオンライン対戦をやっている。UT2004は時間の無駄遣いが恐ろしくなりアンインストールするほどにプレイしたので今回も期待していたが、若干物足りない。売り上げは残念な結果に終わっているのでいよいよPCゲームも(MMOとSteamで買えるゲーム以外は)終焉に至ったかと感慨深い。
2006-12-12
Minuano
2006年は更新1回などと前回書きながらまたこのページを更新する。今回はつまらない作業のメモ。
MongrelというRubyのモジュールがあって、これはwebサーバの機能を持っている。似たようなモジュールとしてWEBrickというのがあるけれども Mongrelの方が新しくまたパフォーマンスも高いらしいというので昨日拾って中身を見てみるとmongrel(雑種)という名前に何か関係があるのかHTTPパーザの部分だけC拡張として実装してある。ソケット周りの部分をもCにしない理由は不明だが、大量のデータを処理するホットスポットをCにするという方針自体は正しい。
だが、こうしたCを使っているモジュールの常か、クロスプラットフォーム対応はおざなりなようでWin32版のバイナリの提供が若干遅れている。とあるテストをWin32版で行っていて不具合らしき現象に突き当たったので自分で新しい物をビルドしようと思いRubyForgeのSVNから未リリースのバージョンを取ってきた。どうやらメジャーバージョンアップを控えているようで色々中身が増えている。C拡張ソースコードがあるext\http11フォルダのextconf.rbがmkmfライブラリによるMakefile生成スクリプトなのでこれをRubyで実行する。(ちなみにRuby本体はRuby-mswin32
のビルドを使用している。)
ところがエラーが出てMakefileを作ってくれない。mkmf.logを見るとc.libというのがおかしいようだ。
とどのつまりUnixのCライブラリが前提になっていてWindowsでのビルドは全く無視されていると思われる。ドキュメントはビルドについて何も触れていないので、オフィシャルのWin32版がどうやってビルドされたのかすらわからない。仕方ないので試行錯誤してextconf.rb内のhave_libraryの第一引数をlibcpmt(VC++のマルチスレッドリリース版Cライブラリ)にしてやるとコンフリクトも無くどうにかMakefile
を作ってくれる。nmakeによるビルドの際はRuby本体のlib\ruby\1.8\i386-mswin32フォルダにあるconfig.h
先頭のコンパイラバージョンチェックにひっかかるので、これを編集してコメントアウトする必要がある。Makefile自体もまだ不完全で、
ライブラリがエクスポートする関数を示すdefファイルをRubyで生成する手順になっているのが、Rubyインタプリタへのパスに空白と
スラッシュが含まれているためにうまく動作せず、そのまま実行するとライブラリのバイナリ(http11.so)はできるものの何も関数が入っていないという状態になってしまう。そこで二重引用符でRubyインタプリタのパスを囲みスラッシュを\に変えなければならない。これでようやくまともなhttp11.soが出来上がるのでこれをMongrel
のlibフォルダへ移動する。
最新版でチェックしても問題は解決しなかった。その問題とは、Firefoxではページが表示されるのにIE7だととにかく「ページを表示できない」というDNSエラーの表示が出てどうにもならないというものである。タイムアウトはしていないのでソケット接続はしているようである。また、Windowsファイアウォールも適切に設定してあり、それ以前にファイアウォールの内側でテストしているのだから関係があるはずもない。冒頭に述べたように幸いソケット部分はRubyなので簡単にデバッグできそうかな等と思い始めた頃にはたと思い当たりMongrel::Configuratorで指定しているリクエストチェインからMongrel::DeflateFilter
を抜いてみる。これでやっとIE7でページを開くことが出来た。どうやらFirefoxと異なり圧縮モードへのIE7の対応に問題があったらしい。このライブラリが金を払う必要のある製品でないことだけが不幸中の幸いである。だが失った時間は帰ってこない。
2006-11-30
Shonuff
去年は1回しかこのサイトを更新できなかったと述べているうちにすでに2006年も末で今年もこのDICE v0.86リリースに合わせての 年1回の更新となる。書きためていた文章もいくつかアップロードした。サイトの全体的な改装なども行いたいけれどなかなか難しい。 リンク切れの修正程度が精一杯だ。このサイトを始めて7年、このサーバに移ってきてから4年経つ。DICEも4年が経ち、かなり大規模な アプリケーションになった。4種類のサーバが1つになっている上にGUIクライアントやwebアプリケーションのスクリプトなどが入って、 一人でメインテナンスするには正直言ってかなり厳しいサイズになっている。ドキュメント類の更新だけでも一仕事だ。アプリケーション のライセンスであるとか、ソフトウェアにまつわる形式的な物事に対して自分で決定し細部まで凝るのが以前は楽しみだった。プログラ ミングそのものについても一貫していて、DICEのデザインについてみると、自分がかつて書いた 2本の記録を読み返してみても構築的な欲求や形式へのこだわりを強く感じる。ネットワークセキュリティにも強い興味があり、 DICEの設計も偏執狂的にセキュリティを追及していた。IRCサーバというのは、他のサーバに比べ、一つの独立した世界を創造するという 側面が非常に強い。OSからハードウェアの抽象化という機能を抜いたような物だと考えれば案外近いかも知れない。セキュリティは、 作り出した世界を確固とするのに絶対に必須である。また、DICEを作り始めた2001年頃には、デザインパターンやeXtreme Programming、RUP、アスペクト指向などのポストオブジェクト指向とでもいうべきソフトウェア工学のトレンドが旺盛に議論されていて、 その頃は私もその関係の本やドキュメントを一生懸命追いかけた。その時の自分のスタンスはどちらかというと保守的なもので、eXtreme Programmingのような教えは米国のソフトウェアコンサルタントの新しい飯の種にすぎない、自己啓発セミナーのようで胡散臭い、といった 見方だった。また、色々なプログラミング言語を勉強したり、積極的に新しいプログラミングのトレンドを追いかけたりもした。 C++のテンプレートなどもその一つで、自分の3年前の文章を見るに、 当時はかなり興味を覚えていたようだ。余所余所しい書き方をするのは、自分の関心が他に移っていったからに他ならない。その 徴候はこのページの2004年4月28日の項に現れている。
実は、DICEを作りながら、3年以上前から別のネットワークアプリケーションを作ろうと考え色々と準備してきた。DICEにはTCP/IP ネットワークアプリケーションの全てが入っている。ファイルの送受信、通信の暗号化、多数のクライアントセッションのホスト、 クライアントセッションへのグループ(チャンネル)毎へのメッセージブロードキャスト、HTTPによるファイアウォール越え、データ レコードの検索、データベースとの接続、.NETコンポーネントのホスト、GUIクライアント、web GUI等、要はDICEというのは私にとってのWindowsネットワークアプリケーションC++ライブラリのサンプルアプリケーションだ。 DICEの中に入っている物を組み替えればどんなTCP/IPアプリケーションでもハイパフォーマンスを維持しつつ作れる。ツールは全て揃っている。アマチュアゲーム製作の際にやってはいけないことの筆頭として「自分用のライブラリを製作すること」というのがあるそうで、それは「いつまで経っても目的のゲームが完成しないから」だそうだ。DICEの場合、作り始めて4年で、自分用のライブラリ、ツールキットとしてはほとんど完成したのではないかというところまで到達した。
新しいアプリケーションはもちろんDICEの部品を積極的に活用する。今度はクライアントとしての側面を強調したアプリケーションになる予定だ。開発スタイルも、DICEのようにドキュメントも含めて完成したパッケージとするのではなくて、もっとカジュアルでインクリメンタルなものにしたい。それこそbloggerがblogを毎日記すように、頻繁に少しずつ更新したプログラムをアップロードしたい。セットアップもzipアーカイブの中身を取り出すだけの簡単な物が良いかもしれない。DICEでは一旦更新するとなるとドキュ メントやパッケージの更新も必要で大がかりになり、アプリケーションそのもののスピーディな更新ができなかった。気がついたら、自分が軽んじていたアジャイルソフトウェア開発のようなスタイルに惹かれていたのは何とも皮肉だ。こだわりやプライドを捨てることのなんと大変なことか。歳を取ってわかることというのはあると実感する。ツールの研究は十分やった。だから、こだわりを捨てて謙虚に、より多くの人に必要とされるようなソフトウェアを書きたい。応用(application)というのがキーワードだ。
しかしながら、より良いツールに対する興味も完全に失われたわけではなくて、どうやればクライアント向けの使いやすいユーザインターフェイスを作れるかについて、もうかなりの時間悩んでいる。最初に設定したユーザインターフェイスの要件は、1. ユーザが自由に改変できるものであること 2. 短期間で要素技術が陳腐化しないこと である。この要件に合致するには何を選べば よいか、悩み続けている。ユーザによる改変可能性については、ユーザインターフェイスはユーザが常に触れる物なのでユーザが 好き勝手に改変できるのが最良だろうという価値判断による。改変可能性の程度としては、スキン変更といった見栄えのみの変更に留まらず、ユーザとアプリケーションコア間でのインターフェイスとしてのデータストリームを全てユーザが制御できるようにしたい。ある意味Unixシェルのリダイレクトやパイプの概念と同じである。プログラム全体をオープンソースにすれば原理的にこの問題は解決するが、それをせずに、アプリケーションの一定部分のみプログラマブルにしたいというわけだ。パフォーマンス上の観点からも、パフォーマンスの要る部分はネイティブコンパイル済みで、それ以外はユーザが自由に変更できるという構成は理にかなっている。何よりそんなアプリケーションがあったら私自身が欲しい。
DICEを最初にリリースしたときから管理用GUIクライアントとして添付しているDICEAdminShellはMFCで作られているC++アプリケーションである。当然ユーザによる改変は出来ないし、MFCというライブラリは今ではほとんど進歩の望めない陳腐化したテクノロジになってしまっている。これではいかにも面白くない。そこで、次に候補になるのは.NETだ。2004年にはDICEが.NETコンポーネントを ホストできるようにした。これはwebサーバ向けの機能として入れた物でwebアプリケーション実行が主用途だが、GUIを持ちユーザの デスクトップとインタラクトするアプリケーションも実行できる。現在のMS SQLサーバはストアドプロシージャをC#などで記述でき、同じようにDICEもCLRをホストしている。CodeDomを用いてC#などのソース コードをコンパイルしてアセンブリにした上でロードし実行する機能も入れてあるので、ユーザによるコード改変も容易である。問題は、GUIのコードをWindows Formsで開発するのが良いことなのかということだ。あと1年もすればWPF/XAMLがWindowsアプリケーションの標準ユーザインターフェイス定義言語になることは目に見えている。もう一つの可能性として、C#やC++/COMでIEコンポーネントを使う、あるいはGecko/XULで アプリケーションを構築するという道がある。IEコンポーネントの方は私自身が日常的にIEを使っていない関係上IEウィジェット の見栄えや挙動に縛られるのは個人的に嫌だし、Mozillaの方はお世辞にも開発サポートが豊富とは言い難くまたランタイムの 配布サイズも大きくなってしまいそうだ。
そこで、最後に検討しているのはweb UIである。DICEにはIEとFirefoxの双方で使えるweb IRCクライアントを作って入れた。これはJavaScriptでタブ切り替えのUIを構成し、AJAXのHTTPリクエストではなくFlashでサーバ本体との通信を行っている。画面遷移も勿論無い。DICEにはwebサーバ機能があるので、リモート用途でなくともweb UIを簡単に付けられるというわけだ。もちろん、通信を暗号化すればインターネットを経由したリモートアクセスのためのUIと しても使える。web UIの短所は、右クリックコンテクストメニューがフックできない場合があること、クリップボードやサウンド 再生が使えないことである。クリップボードやサウンド再生は、リモートからアクセスするのではなくローカルで動かす場合 なら本体の方で処理すればよいのでそれなりに対処できるが、右クリックコンテクストメニューはブラウザ自身のメニューとの 兼ね合いで問題がある。その点のみ無視すれば、基本的に、フレームバッファの内容に直接演算を適用しないと得られない特殊な視覚効果を除き、普通のデスクトップアプリケーション並みのリッチなUIをweb UIでも実現できる。残る課題はFlashとサーバとの通信の暗号化くらいだけれどもそれも目処が付いている。そういうわけで、今考えているデザインは、UIはwebブラウザを使って、それでカバーできない部分は上記の.NET CLRホスティングでC#ソースコードを公開しユーザが改変できるようにしたいと思っている。アプリケーションのコアは今まで 通りC++で、パフォーマンスの要らない部分は可能な限り.NETの方へ回す。このページの下にある私が書いた2004年の文章では 「C++が格下の存在になりつつある」などと書いているが、実態は全然そんなことはなかったようで、Windows Vistaですら.NETは一定の範囲に留められている。DICEにPerlも組み 込んだし、要は臨機応変というわけだ。フットワークの軽さなら自信がある。
以上が今後公開しようと思っているアプリケーションの話。このサイトで他にやっているのはプログラミング関係の雑文の公開だが、一番反響があるのは意外なことにSSLの証明書を証明書ストアに入れる方法の記事だった。資料が無くて困っているのは皆同じのようである。ソフトウェア企業の人間が感謝のメールをくれたりする。中には記事の範囲を超えてあれこれと相談をしてくる人もいた。自分でビジネスをやっている人間は自分で解決して欲しいところだ。とは言っても私もFirefoxのBugzillaではオープンソースプロジェクトなのを良いことにかなり好き勝手な注文を付けたりしているので人のことは言えない。他人のバグのプロパティを変更する権限を私は持っているので、他人のバグには介入するわで余計始末が悪い。
最近は諸々の理由で全くPCゲームをやっていない。一方で、ゲーム機のハードウェアへの興味が約2年前から非常に高まった。 メインストリームPCがようやく並列プログラミングに入ろうかという時期に、ゲーム機は既に3コアとか9コアといった並列性の高いアーキテクチャをCPUに採用している。GPUの並列性はさらに高い。また、パフォーマンスがとかく軽視されがちなwebなどの プログラミングと異なり、パフォーマンスが何時の時代も追及されるのはゲームの分野である。ネットワークプログラミングも、MMOGやオンラインFPSなど一つのワールドイメージを維持しようとした場合の負荷は非常に高い。というわけでここ2年はBeyond3DのConsole Forumに入り浸っている。ここはゲームコンソール関連のフォーラムの中では世界で一番参加者の平均年齢並びに精神年齢が高いのではないかと思われるフォーラムでPS3やXbox 360の開発者もよく投稿しておりメモリのレイテンシにまで気を配るハードウェアに密着したプログラミングの話題は非常に勉強になる。ゲーム機の話題は技術的な物も含め日本発のものも多く、私はよく日本語記事の英訳を提供しているのでそれが各方面から喜ばれているようだ。Beyond3D自体はリアルタイム3Dグラフィックスハードウェア専門サイトで、業界人御用達のような場所である。
IRCも約2年前からあまりやっていない。今でも海外のネット上の情報の一番濃い部分がIRCにあるという点は変わらないが、それでもwebのフォーラムが爆発的に普及してきているという印象がある。6、7年前は、日本の方が掲示板は進歩していたと思う。 ところがそれ以降は海外の掲示板がCMSの進歩やPHPの台頭と相俟ってwebサイトの必需品となり、発展してきた。 imageshackとかimagevenue のようなイメージホスティングサービスも掲示板貼り付けを前提としてPHP掲示板用のBBコードを用意してくれる。海外の掲示板カルチャーは確固たるメンバー管理システムと組み合わさっていて、運用にはデータベースが必須である。 CMSと親和性が高いのも当たり前だ。日本に見られる2chのような一様な匿名空間やSNSと称した出会い系サービスの作る空間、 blogの散漫な空間とは一線を画した、社会的でかつ開かれた議論を行うための空間がそこにはある。こうなってくると、TCP/IPに乗せるのはHTTPだけで良く、IRC等は要らないのではないかという疑念も生じるかも知れない。しかし、webフォーラム とIRCの微妙な差異は依然として残っており、通信のオーバーヘッドの多寡を除けば、その差異とは、IRCではチャンネルのメンバーリストがリアルタイムに更新されメンバーの出入りがリアルタイムに宣言されるという点である。IRCはメンバーのプレゼンスをも模している。この参加者の居るライブ感という差異が残る限り、IRCが滅びることはない。一方で、Second LifeやWorld of Warcraftのような3Dの専用 クライアントによるリアルタイムコミュニケーションも、10年前には失敗したが回線品質が向上した現在はクリティカルマス に達しようかというところまで来ているようだ。それでも、無駄な部分を省いたコミュニケーションの需要は残るはずであり、むしろ参入障壁が十分に低ければシンプルなものがリッチなものを出し抜く可能性が十分にある。web IRCクライアントにはそのような展望も込めている。
2005-05-06
Thank You Falettinme Be Mice Elf Agin
DICEの更新日付を見たらなんと1年ぶりの更新だった。このウェブサイトについても同様である。実はDICE 0.85自体は去年の8月に 完成していたのだけれどそれから色々あって手を付けることが出来なくなりリリースそのものは今日に至ったという有様だ。書きたい ことも多々あるしかしまたしても時間がない。後日に譲る。
2004-04-28
DICE version 0.84 配布
昨年末にPrince of Percia: SOTをやって以来、全くPCゲームをプレイする気が失せていたのは前回書いたとおりである。 Painkillerも昔の面クリア型ゲームを中途半端に模したような感じでかなり興醒めというか期待外れだった。ところが、 ビデオカードのアップグレード予定も当分ないので今年はこのまま何もやらずに済まそうかなどと思っていたところ、あっさりと その方針を覆らせるゲームに当たってしまった。何のことはない、Unreal Tournament 2004である。デモ版をダウンロードして遊んでみたところ、ネットワーク対戦のOn-slaughtが実に面白い。 デモ版でこれだけ遊べていいのだろうかという出来の良さに率直に驚いてしまった。前作では、前々作からのグラフィックス の進歩にばかり目を取られ、時間もないということでUTで定評のあるボットの能力を信用してシングルプレイのラダーを クリアしあっさり通り過ぎていたのが、今作のONSで遅ればせながらやっとネットワーク対戦FPSの真価に触れたような気がする。 グラフィックス上は前作からほとんど進歩しておらず、またキャラクターもほとんど使い回しという状態ではあっても、乗り物 が正式サポートされたことで遊びの幅が立体的に広がった。最近では乗り物が登場するFPSは珍しくないとはいえ、Unrealの世界の武器の扱いに慣れすぎているせいか、Halo等では味わえない絶妙のバランスを感じる。それも、Haloほどにはかっちりと した作りでもなく、Unrealという名の文字通り非現実的にキャラクターがぴょんぴょん跳び回りつつ激しく接近戦を行うという のがUnreal Tournamentの真骨頂だ。20分程度で済むONSは実にリプレイバリューが高く、たとえ負けても激しい抗戦ができればそれなりに 満足感がある。その場限りの人間のチームは、上級者と下級者が混ざっているのでよりメリハリのあるプレイを楽しめる。 ONS(とASの一部)では乗り物もあるので、1on1だとさかんにサイドステップで飛び回る上級プレイヤーを叩ける逆転のチャンス も増え、集団ゲームとして実に合理的なハンディキャップ配置である。PCのいわゆる洋ゲーしかやらず、UTではなくUnreal本編 のようなシングルプレイヤー物を好み、一回最後までやったゲームは大概そのまま手放してしまう私のような人間にとって、この中毒性の陶酔はコンソールゲーム以来の久々の感覚である。下手をすると一年間UT2004だけでゲームの欲求をまかなえそうな気すらしている。非常な良作であると太鼓判を押したい。
ただ、これだけ褒めちぎり甲斐のあるUT2004でも、弱点はある。それはシングルプレイにおけるボットのAIである。定評のあるUTのボットだが、今回ばかりは人間と対比しての部分で分が悪い。人間相手の対戦ばかりやっていると、ボットの挙動の機械的な 限界と、人間のプレイヤーの人間的な癖や戦略的強さとの差異を、画面越しにひしひしと感じる。例えば、シングルプレイの ラダーにONSは入っていないのでINSTANT ACTIONでONSをプレイしてみると、ボットは非常に合理的にリンクノードを攻めようとするか、あるいは異常に向こう見ずな先制 特攻をかけてくるかの二つに一つである。ボットの技能を調節したときは、シングルプレイのラダーを上っていけば分かるよう に、チームプレイヤーの4つの能力パラメータ(正確さ/攻撃性/敏捷さ/戦略)がきちんと上昇していき、Skaarjの場合サイド ステップが多いなどのゲーム上の特徴を除くとほとんどむらがない。そして、上級ボットが恐ろしく武器の持ち替えが早いとか 反応速度が速いとかいった形で強いのに対し、低級ボットは妙に動作が遅く照準も定まらないといったようなわかりやすい差が、 ONSに比べゲームの密度の濃い1on1の戦闘ですら時折気になる。ところが、人間の上級プレイヤーの場合は、抽象的な表現をす れば、反射ではなく先読みが異常に優れている。それは、人間のプレイヤーの癖を学習しないと得られない戦略であり、残念ながら 製品版でもそういった観点のボット強化はあまり行われなかったようである。結果的に、ONSのシングルプレイは非常に味気ない ものになっている。もちろん裏を返せばそれだけネットワーク対戦が魅力的であるということになる。具体的な人間プレイヤーの 挙動としては、私がネットワーク対戦を観察していて最も人間的に感じたのは、Mantaで相手の頭上高く跳ねてそのままほぼ垂直 降下し相手を潰すテクニックである。真上という、マウスで回す場合視界が最も及びにくいと思われる部分から攻撃を仕掛け人間 のプレイヤーが最も嫌う死角を突くというこの戦略は、ボットにあらかじめ組み込めば可能なのだろうが、それにしても実に人間的である。車のクラクションを鳴らして味方を拾うのも些細なことだが協力プレイの基本コミュニケーションだ。またマップの 特性を理解した上でリンクノードを移動せずに超長距離から乗り物で砲撃するのもボットにはない人間プレイヤーの常套手段だろ う。こうしてみると、相手の人間的な癖を読んだ戦略の効用を自分も理解できゲーム内の世界で学習していくという感覚を覚えた ときこそが、ネットワークFPSの真髄を直感する瞬間と言えはしないだろうか。これは、同じネットワークゲームでも、MMORPGの 世界とはおそらく異質な、あるいはもっと鮮烈な体験である。会話は罵声と"pwnage""gg"等々以外ほ とんど欠くネットワークFPSでは、侍の世界よろしく、プレイヤーが無言の対話を丁々発止の決闘の最中に交わしているのだ。 そうはいっても負けたときにはそれなりに腹立たしさも感じるのでついつい勝つまで繰り返すこともある。それでも、ボットの チームに理不尽な負け方をした時ほどの屈辱感はないのが不思議だ。近い将来もっと賢いAIがボットに搭載され人間プレイヤーとの区別が付かない程度まで進歩するとしたら、この感覚がどのように変容するのか、非常に興味深い。
今回のバージョン0.84からDICEのHTTPサーバ部分に、.NETアプリケーションコンテナと称して、.NETオブジェクトをホスト出来 るようにした。C#/VB.NET/JScriptのコードをアセンブリにコンパイルして実行する機能と、.NETアセンブリを直接実行する機能が ある(ただしエントリポイントはMainではなくて特定の抽象クラスをユーザに実装してもらう方式)。リース期間はデフォルトで無限なので、CGIとは違いISAPIのようにメモリ上に置きっぱなしになり、PHPやJ2EEのようなセッション管理も可能である(ユーザがコードを書きさえすれば)。ただしメモリはそれなりに食うようである。ひょっとしたらリークしているのかもしれないが、CLRだかCOMマーシャリングだかのキャッシュはある程度呼び出しを繰り返すと落ち着くようだ。折角のwebサーバ機能にも関わらずCGIのようなダイナミックコンテンツをまったくサポートしないのはさすがに格好悪いよねということで色々考えていたところ、一番簡単そうなのがこれということで.NETを対象にすることになった。本当はASP.NETがサポートできれば大した話なんだろうが、さすがにそこまで大仰な物は作れないので、自分でC#やVB.NETのコードを書いたりコンポーネントを利用したりする人がプログラマブルに使えればいいだろうということでこの形にした。現在のASP.NETや、将来のYukonのストアドプロシージャ同様に、Unmanagedコード内にCLRをホストし、そこで.NETのオブジェクトを動かすという仕組みである。今のところセキュリティもへったくれもないのでサーバ管理者自身が好き放題に書いたスクリプトを実行するという使い方を想定している。いずれにせよWindows XP SP2でHTTP.SYSが搭載されるとのことなのでパフォーマンスの点ではIISに対抗しても仕方ない。Perl、PHP、Rubyなどがサポートできれば既存のCGIスクリプトなんかの再利用という観点からは最良なのだけれど、PerlはActiveStateのdllが関係しそうだしPHPもRubyも個人的に興味ないしで(CGIが使っている標準出力とかフックするのは大変そうだしRubyの組み込みマニュアルは本当にスカスカだし)、かといってApacheモジュールを使えるようにするとかいった計画は遊びには面倒すぎる。そこで.NETアプリケーションサーバという名目で行くことになった。世に出ているJavaのアプリケーションサーバは大概自前のJavaの実装を持っているようだけれど.NET系のものはどうなっているのだろうか。
一応DICEは今となってはやや古いWindows 2000も対象としているので、あまり.NET Frameworkには触れずに済ませ、次に作るアプリケーションで色々新しい構成を考えようと従来思っていたけれども、ある問題についてなかなか良い解がないので思いあぐね、DICEの方に一つの関連する方法を実装してみて具合を見ようというのも今回の追加機能の目的の一つである。その問題というのは、UnmanagedアプリケーションとManagedアセンブリの通信チャネルの選択である。それも、双方向で非同期の通信を可能にしたい。今回の場合で言うと、.NETコンポーネント側から見るとUnmanagedのDICEから非同期に呼び出しが来るように見えても、ホストされている.NETコンポーネントが非同期にDICEを呼び出す手段は提供していない。今のところ、DICEがホストしている.NETオブジェクトから非同期にDICEを呼ぶには、DICEにCOMのインターフェイスをつけて登録するのが簡単そうではある(既にATLサービスなのでレジストリも使っている)が、どうもスマートでない気がする。大体、ホストしている.NETコンポーネントの方へデバッガを仕掛けることがどうやら現状のDICEでは不可能なので、テストユニットを使ってドライバを用意したりする暇もない状況ではかなり面倒である。最近VC++ 7.1が無料配布されることになったが、やはりVCの肝はデバッガで、それが抜けていると少なくとも開発には役に立たない。Unmanaged/Managedの一番大袈裟な通信方法はおそらくMSMQやCOM+を使うものでこれはプラットフォームに依存しすぎる嫌いがある。そこで、以前は、TCP/IP接続が、低レベルながら移植性が高い上に位置透過性もあり最善と考えていたが、プロトコルを一々実装するのはやはり面倒は面倒だ。
最近は、上述のデバッガ問題から、Unmanaged C++にしがみつくのはやめにして、Managed C++でラッパーを作ってアプリケーション自体はいい加減に.NETの方へ重点を移し、位置透過性は.NETリモーティングでどうにかするのがいいかもと考えている。それなら、さすがにデバッガも問題なく使えるはずだ。そのためには、今使っているC/C++のライブラリをどうにかする必要が出てきそうで、これもなかなか頭が痛い。DICEのために作ったフレームワークも、次にそのまま使うというわけにはいかない。とはいっても、もう私の中では腹は決まっている。今回のDICEのようにC++で作った部分はピュアなUnmanaged実行ファイルとして保ち分離されたManagedアセンブリと通信させるモデルは、個人の立場ではこれ以上の維持は無理だというのが私の結論である。それよりは、パフォーマンスは要求しないアプリケーションの動作部分やGUIはC#で書き、パフォーマンスを要求する部分やレガシーコードをUnmanaged C/C++のコードをManaged C++でラップして、それらを一つのアプリケーションとして綴じ込むべきで、同期だの非同期だのといったことはマシン内では忘れた方が良い。実に単純な話だが、C++テンプレートのテクニックやパフォーマンスハックなどC++の楽しさに拘泥しすぎて完全な宗旨替えがいささか遅れてしまったようである。
DICEで一番デバッグに時間がかかったのはパースレッドメモリアロケータの部分だが、皮肉にも、それに次いで長い時間をSTLportのバグによって起こる、デバッガで追い切れない原因不明のメモリ破壊などの問題で失った。VC++ 7.1対応とバグ回避のためにCVSスナップショットを使用し始めたところそこに別のバグがあり、貴重な時間を随分失うことになってしまった。しかも更新の度に別の新しいバグをコミットしてくれたりするので参った。最近になってCVS内のテストコードが充実し安定してきたからよかったものの、0.83のリリースから0.84まで5か月近くもかかってしまったのはSTLportのCVSの更新を待っていたのが主な原因である。0.83は実はかなりの問題を抱えていたにもかかわらず、足踏みする羽目になった。DICE 0.83使用者には、早期の入れ替えをお勧めする。.NETアプリケーションコンテナは、その期間の開きに対して埋め合わせとして、また上記の実験のために入れたまでだ。これがパフォーマンスクリティカルな部分のみUnmanagedコードで、かつアプリケーションの他ライブラリ依存がもっと低ければ、こんな苦労をせずに済んだことだろうと思う。STLportがオープンなのは不幸中の幸いである。.NETの場合で不安なのはマイクロソフトのライブラリにバグがあっても修正がなかなか得られないことくらいだ。ネイティブコードの世界ですら、最近プログラミング言語Dが以前より大きな注目を集めるなど、確実に流れは新しい次元へ、それも以前よりさらに速く向かいつつある。.NETは登場以降3年経って全然普及していないなどと言われるが、Longhornを前にして、ギアは一段上がった。コミュニティとレガシーコード群の大きさを除けば、C/C++は、そこでは明確に不利な、格下の存在だ。よくても、UnmanagedとManagedを繋ぐグルーコードの扱いである。
2004-01-10
DICE version 0.83 配布
2003年の年頭には下記のように6回はこのページを更新するなどとうそぶいてみたものの蓋を開けてみると4回しか更新していなかったりする。しかも、すぐ下ではプログラミングに邁進するかのようなことが書かれているが目下全く手が進んでいないのでこのサイト的には情けない限りである。年末に当年の総括をするのが一般的なようだが、12月も1年のうちには違いないので、自己の1年を顧みての反省は1月にするのが適当である。反省と言えば、犬も歩けばblogにあたるというほどbloggingがwebで流行っている昨今、独り書きあるいは自省という行為が広まったようにも見える。しかし、実際の所blogというものは暗黙にあるいは明示的に対話や双方向の関連づけを前提として作られており、主に自省のためというより、他者が常に意識されている活動である。webで公開されている以上当然ではないかという意見もあろうが、blog以前に昔の日本のwebで行われていたweb日記というジャンルは、多くの場合匿名で行われていたので、個人が他者とのコミュニケーションのフィードバックを求めるという側面を必ずしも持っていなかった。いわば、一方的な告白である。当時はweb日記などには全然関心が無かったが、昨今blogに当たらずに過ごす方が無理なので毎日毎日よく時間を費やして書けるもんだと私などは感心して色々見て回っている。webデザインについても、blogの場合なぜか例外なく「シンプルで趣味のいいデザイン」を目指したと思しき様式に統一されているのも面白い。写真もそんなシンプルなフレームの間に挟まれていると実に映える。私は去年初めにMozilla Firebirdを使い始めるまでNN4に固執していた関係でスタイルシートやJavaScriptに関心を持つのが後れたので未だにその辺りについて何か学習するたびに面白みを覚えてしまう。DICEのwebインタフェイスを作るときにMozilla/IEのDOM操作で面白いことが色々出来るのにも開眼した。しかしこれがFlashまで行くと奥ゆかしさを失うような気がするのは何故だろう。あくまでwebブラウザonlyで出来るのが好ましいと感じる。
blogのなかで私が一番頻繁に見ているのはRuby開発者の松本行弘のblogである。プログラミングに関心のある人間なら楽しんで読める内容がほぼ毎日書かれているのは驚嘆に値する。Rubyに特に関心のない私がそう感じるのだから間違いない(Ruby 2という奴は気になるけど)。もっとも、当のblogでもオープンソース技術者というものは広告塔(エヴァンジェリストと言う奴か?)になるべきか否かという議論が、blog自体が明らかに広告であるにもかかわらず訪問者によって交わされるところを見ると、「日本の文化はつくづく奥ゆかしい」と好ましくも疎ましくも感じる。他に、プログラミング関係では、Don BoxのblogもLonghornオフレコ談義ばかりで読み甲斐がある。笑えたのはC++ Primerなどを書いているStanley Lippmanのblogで、まるっきりC++.NETの新仕様のプレゼンテーションとして使われている。こうした、普段それほど散文を書くとは思えない人々の文章を眺めるのはそれ自体楽しいが、一方で、文筆業の人間こそ読み甲斐のあるlogを書くはずである。書くはずであると思いきや、例えばWilliam Gibsonのblogは去年秋に本人の執筆活動との干渉を避けるために休止されている。休止自体はなるほど彼の作品の読者に対して誠実ではあるが、オープンソースという形でのプログラムコードのインフレが現実となっている一方で、古典的な文筆業に対するインターネット上での文章のインフレは何をもたらしつつあるのだろうか。
一応前回以降もPCゲームをやりましたがPCゲームの衰退をはっきりと感じさせる嫌な流れだった。プレイしたのは以下:
Max Payne 2
Halo PC
TRON 2.0
Dungeon Siege: Legends
of Aranna
Prince of Persia: The Sands of
Time
Republic: The Revolution
DS: LoAは手堅い作品だが前作のエンジンの完全な使い回しで話も一本道であり終盤かなりだれてしまったのが惜しい。とはいえDungeon Siege 2にはかなり期待している。Republicは、ものすごく期待していたタイトルだったものの、蓋を開けてみると全然思い描いたのと違っており参った。東欧の雰囲気が出ていたのは良かったにせよ、ボードゲーム + カードゲーム + 3Dはおまけ というようなゲーム内容だとは全然思わなかったので、騙されたという気分が結果的に勝ってしまった。後半の単調さと終盤の破綻したゲームバランスも気になる。PoP: TSoTは、久々にスーパーマリオのようなプラットフォームアクションゲーム(よりパズル寄りだが)をプレイする機会で結構新鮮だった。ただ、FPSに慣れた身にとっては、頻繁に入る自動視点補正が眼精疲労を促進してくれる。また、ATIのRadeonを載せたマシンとnVIDIAのGeForceを載せたマシンの双方でプレイしてみたところ、Radeonのマシンでは最新ドライバでも水のエフェクトが異常で、nVIDIA - the way it's meant to be played のロゴはさすが伊達ではないなと感じた。最近のベンチマークはnVIDIAの衰退を示しているが、個人的にはnVIDIAの方を応援したいところである。TRON 2.0は音楽が結構気に入った。ビジュアルは悪くない。グリッドレースは元の映画に全然郷愁を覚えることのできない者としての自分にとってははっきり言って面白くも何ともなかった。Halo PCは、待ち望んだタイトルだけあってなかなか楽しめた。ただ、シーンの繰り返しが多いのと、エンジンが全く最適化されていないのには閉口した。テクスチャの圧縮をする前にPCならではの良さを追求してほしかった。そして、Max Payne 2については、正直なところ失望した。期待が大きすぎたせいかもしれないけれども、あっけないほど短いゲーム、前作のそれに毛の生えたようなラストバトル、全く目新しさが感じられないゲームデザイン、などなど明らかに前作より退化した印象を覚えた。その辺は完全にHaloの件も合わせXboxに非があると思う。もう一つ悲しいのは、Deus Ex 2 (Invisible War)で、これもコンソールからの逆移植のような形態らしい。正月にやろうと思って楽しみにしていたものの、公式フォーラムでの批評があまりにもひどいので全くやる気が失せてしまった。最適化されていないエンジン、短いゲーム、などなど予想の範疇の問題が指摘されているので、やる前から気力が萎えてしまい、結局ゲームそれ自体への関心が今はここ数年で最低の状態である。果たして、救世主は現れるのだろうか? Doom 3、途上のソースコード(結構普通のC++コードで一部オブジェクトコードのままだった 笑)とコンテンツがリークしたHL2、UT 2004、それからPainkiller、S.T.A.L.K.E.R.に期待(全部FPSなんだけどね)。
2003-07-25
IN SOVIET RUSSIA DICE VERSION 0.8 RELEASES YOU!
やれやれやっとDICE 0.8の配布にこぎ着けることが出来て感慨深い。というくらいリリースが難航して結果約2か月も予定より遅れることになってしまった。その代わりと言っては何だが新しくwebサーバ機能も入り、かつ安定性も大幅に向上している(特にWindows XP/Windows Server 2003上)。「IRC/HTTP/opennapハイブリッドサーバ for MS Windows 2000/XP/2003」なんていかにも危なっかしい形容なのでIISのように簡潔な名称にしたいところではある。そこで私自身忘れていたのは実はDICEという名前がその役目を果たすべきものであるにもかかわらず未だに何故DICEという名前なのかどこにも由来などを書いていないということである。今回も書かないのだけれどもその代わりにDICEに関する今後の方向性を示唆する物としてIFIRCでのインタビューを参照されたい(これも微妙に古くなってしまったが)。
下でゲームやらないと書いた割には最近またやり始めている。とはいってもやりこんだのはGTA Vice CityとChaserだけだ。
GTA Vice Cityはまずサイトのflashがとても洗練されていて印象が良くまずはそこから入った。誰もが褒めちぎるタイトルなので一々付け加えるのも無粋だが、前作GTA3があまり気に入らなかった人間から言わせてもらえば、前作からそれほど時間を置いていないにもかかわらず大幅にクオリティが向上している。前作では残虐性の軽減を図ったのか人形のようだった通行人達もそれほど軽々しくなくむしろGTAアートワークのアニメ/トゥーンシェーダっぽい印象をそのまま取り込んだようなバランスの良さである。バイクでの疾走も他のバイクレースゲームのように決して操作が困難ではなく、またMafiaのように車中でダメージを受けることもないので安心してドライブを楽しめる。そして音楽が80年代ヒットの数々なのだ。ゲーム中の車で目的地へ飛ばしつつBilly JeanがFlash FMでかかったときの爽快感は、リアルの曲をゲーム中で使用するというアイデアへ半信半疑だった私の不安を遙かに裏切って新鮮だった。なにせリアルでイイものはゲーム内でも文句なくイイのである。残虐性で名高いこのシリーズにBilly Jeanの作者がライセンスを下したという事実もまた興味深いものの、このゲーム全体を貫くノリのよさ、快感原則への忠実性はほとんど禁じ手のようですらある。
Chaserは、それに対し、最初期待していなかった時点での予想水準は上回ったものの、しかしクリティカルヒットでは決してないという微妙な作品だった。よくある近未来物で、かつビジュアル面とプレイ時間の長さでは一級である。また、FPSの中でこれほど開けた空間の拡がりを強調したものは初めてだったのでその点はまず手放しで誉めたい。しかし、ストーリーやゲームバランスなど細部で微妙に違和感が残った。たとえば、似たような近未来物でもDeus Exのように作者らがこだわりを持って作り込めば非常に濃い作品となり、そのこだわり(Deus Exで言えばアメリカの都市伝説としての陰謀論や異星人などいわゆるトンデモ系)に全く共感を持てない私のような人間にも何かそのプロデューサーが強引に皆に押し付ける鬼気迫る強迫観念を共有できるような気にさせてくれるところがあるのである。それに対し、Chaserの場合、いずれも中途半端に料理された感じが否めない。皆がてんでばらばらに好き勝手にやった感じがあり、中盤のしっかりした作りに比べると前半と終盤は全然別のチームが作ったのではないかというのが私の推測である。どうもJoWoodというパブリッシャはバランスの悪い作品ばかりを取り揃えている気がしてしまう。実際の私のゲームプレイ体験はと言えばちょうどDevastationの後遺症が発現したのか、FPSであるこのゲームをやりながらゲロを吐きそうになった。それは閉所恐怖症の人間を追いつめるシーンが多いこのゲームのレベル設計だけの問題だけではあるまい。ところでそんな生焼けのゲームでも笑える点には事欠かない。主人公が宇宙から降りてくるときにいつのまにか革ジャンとジーンズを着ていたり、水中をアクアラングを付けて長期潜行するときも同じ服装だったり、日本人女科学者が会って15秒で殺害されたり、リトル・トウキョウのヤクザの用心棒が特撮ヒーローのような格好をしていたりする(実は非常に弱い)のである。
既に半分が過ぎてしまった2003年だが、このblogの2002年12月21日の項での予想を見てみると、Unreal IIがリリース済である他は未リリースである。ただしDungeon Siegeは拡張パックが近々出るようで、またDeus Ex 2もかなり完成に近づいているはずだ。Doom 3が延期になってしまったので、あとはHalo PCやHalf-Life 2くらいしか楽しみにできる作品がない。この状況を見ていると、WindowsにおけるPCゲームも量産されるRTSやオンラインゲームを除けばいよいよ衰退に近づいているようだ。
2003-04-03
DICE version 0.6 配布
Devastationやってみた。勿体ないので一応最後まで行ったけれどもとんでもない駄作だった。Unreal Tournamentのエンジンを使ってるのはいいとして、画面の雰囲気が何となくHalf Lifeを思わせる荒さで汚く、ボットの動作もぎこちない。シナリオは無理矢理UTのTeam Matchをやらせるためにでっちあげた(特にReGen、これこそご都合主義の権化である)と言っても過言ではない代物だ。「HOTEL れしゃお貴族」のような壊れた日本語ネタには尽きないゲームではあるが本当にそれだけだった。おまけに久しくFPSで酔ったことはなかったのに(移動しながらcrosshairsを標的あるいは消失点に固定し続けることが出来るようになればFPSでは酔わない)、何故かこのゲームに限って酔ったので最悪である。文字通り「むかつく」ゲーム体験となってしまった。今年はもうしばらくゲームをやらないと思う。
ところで、DICEバージョン0.22 - 0.5にはアセンブリによる中途半端な最適化によりPentium3で動作がおかしくなるバグがあったので、そのバージョンで正常に動作しなかった場合は今回の0.6を試して頂きたい。
2003-02-12
DICE version 0.22 配布
DICEバージョン0.22配布開始。メンテナンスリリースで特筆すべきことは何もない。尚、DICE上での利用に問題があるIRCクライアント用スクリプトがある場合、ここにDICEから削除されているIRCコマンドのリストがあるので自力でスクリプトの方を修正して頂きたい。それらのコマンドは、主にセキュリティ上の理由からDICEでは意図的に省かれているものである。
さてUnreal IIである。3日かかってクリアできた。解像度は1280 * 1024 * 32bitを使用した。最初は1024 * 768に設定したが明らかに汚かったので既にこの解像度はゲーム向きではないらしい。GF4Ti以上のVGA + 2Ghz以上のCPUで満足にプレイできると思われる。(Doom IIIだとこれでは足らないらしいが)
まず良かった点から挙げると、パーティクル表現(レーザーの流れやビームの粒子、炎、火花など)がとにかく豊かで美しい。 残念ながら絶対的に良い点として挙げられるのは以上のみである。あとは、UT2003に比べてもグラフィックが緻密であったこと、また自陣の防御を行うミッションの新奇さ、スナイパーライフルの扱いやすさなど、小粒の評価点がいくつかに留まる。全体的に、「美しいグラフィックのFPS」「アイキャンディ」以上のものではなかった。ゲーム中はさすがに夢中になってプレイしたとはいっても、終わってみると一番印象に残っているのは3Dベンチマークのように煌びやかな抽象図形がリアルタイムでレンダリングされるオープニングデモだった。Unreal IIのBGMはOgg VorbisのファイルなのでWinampなどで聴ける一方で、オープニングデモらしきファイルはシンクロが必要なのかOggではない種類のファイルなのでそのままでは音のみを聴くことはできないようである。
そして、面白くなかった点を挙げなければならない。最大の不満は、終盤のスクリプトの不自然さ、急ぎ足の展開である。宇宙船のクルーも本当にNPCらしいNPCというか、単なる説明役というか、全く魂を感じられないお粗末な設定であった。前作と比較するならば、ゲームの長さが明らかに短い。舞台設定が違うので仕方ないにしても、前作の、異星の空間に放り出され、次に何が起こるかわからない寒々とした不安感、荒涼とした風景に曝されつつ味わう孤独感は、一度も体験することができなかった。前作は野外や遺跡、エイリアンの宇宙船などが舞台で、色調も妖しげな翡翠色が多く、まさにunrealといった風情だったのが、今作はRed Factionのパロディかと思わせる部分があったり、Unrealというビッグタイトルが単にエンジンの名称を指すところまで矮小化されてしまったようだった。Drakkの惑星はさすがに前作風を意識して作ったと思しき様子だったものの、このミッションの最後の章がThe Solitaireという名前(他の章も全部Sで始まる)にしてあるところなど、前作の最終章の悪質なパロディに堕した観がある。しかも十分に巨大なボスキャラが一回も出てこない。さらに最終ミッションは簡単すぎて既にゲーム性を失い、キャラクターをコントロールできる点を除けば、ストーリーに花を添える美しい書き割りとしてのシーンが展開される退屈なデモに過ぎなかった。他にも、Skarrjが出てくるミッションが2つしか無い、主人公の足が遅い、EAXをONにするとOpenALが落ちる、など小さな欠点は多々ある。
勿論、今後このエンジンに基づいた傑作が多数生まれることは想像に難くない。しかし、前作がそれ自身傑作であっただけに、今作の陳腐なスペースオペラぶりは、悪い予感(このページ2002年11月20日の項参照)がここまで当たってしまうと逆に爽快なほどであった。しかも、前作と違ってマルチプレイも無い。Mafiaのような贅沢なゲームを味わってしまったあとだと余計に寂しいシンプルな構成である。シングルプレイヤー、マルチプレイヤーの双方を含んだミッションパックがリリースされることを願って止まない。
2003-01-07
DICE version 0.212 配布
あけましておめでとうございます。
去年末からC#で.NETフレームワーク用のプログラムを書いている。開発環境のサポートが充実している点を割り引いても、まるでかつてPerlでスクリプトを書いたときに味わったような爽快感を再び味わうことができた。
年末の総括を忘れていたので今数えてみたところ2002年は8回このページを更新できたのでなかなか悪くない結果である。今年は6回と予想しておく。
一昨日DICE v. 0.21を公開したが問題が発覚したので0.211に差し替え。
さらに昨日公開したDICE v. 0.211にも微妙な問題が発覚したので0.212に差し替え。
2002-12-23
DICE version 0.201 配布
DICE version 0.2 に凡ミスが見つかったので急いで修正&差し替え。結果的に別の部分まで手を入れることになったので慌ただしくリビジョンを上げた。あまり何回も見得を切るのは格好悪いので願わくばこれ以上問題が起こりませんように。
2002-12-21
DICE version 0.2 配布 & KLassphere Athens 配布
DICE version 0.2の配布を開始した。SQL Server/MSDEが全く要らなくなりより一般的なユーザに身近になったと思われる。SQL ServerのデータベースからDICE ver 0.2用のデータファイルを抽出するツールも置いたので移行も簡単である。来年はDICEに手を入れる機会はほとんどないのでこれを完成版と呼んでも差し支えない。ナンバリングこそ0.2ではあるがユーザインターフェイスの不親切ささえ脇に置けばサーバアプリケーションとしての内容は1.0と呼んでも良いものに仕上がったと自負している。SQL Serverのおかげでインストールに二の足を踏んでいた方は0.2の完成度を是非動かして試して頂きたい。ついでにISAPIの掲示板ももう手を入れる余裕がないのでなし崩し的に配布することにした。
2002年の俺的洋ゲー番付は
1. Mafia
2. Warcraft III
3. Unreal Tournament 2003
ですね。GTA3とかBattlefield 1942とか人によっては入れるかもしれない。一応この3つはシングルプレイヤーで用意されたものを最後までクリアできたものである。GTA3は最初の方でマップがわからなくなり断念(笑)、ミリタリー系は実はTom
Clancyのシリーズなど含め全部好かない(近未来もの除く)ので始めから入手していない。ミリタリーものに限らずシミュレータっぽいゲームに適応を強いられるのは性に合わないのである。そしてオンラインゲームも(UT2003のようなアーケードプレイを除き)やる時間がない。
そして2003年を予想すると、
1. Deus Ex 2
2. Unreal II
3. Dungeon Siege 2
こんな感じ? 疲れてるね。何はともあれ良いお年を。
2002-11-26
DICE version 0.1 SR1 配布
DICEについて、前回言及した更新版とは別にいくつかの機能を付け加えるとともに既存部分の振る舞いを変更したくなったのでサービスリリースとして更新必要ファイルのみアップロードした。先に0.1をインストールして、そこへ上書きということになる。修正は含んでいないので既に稼働中のサーバがある場合はどうしてもSR1の機能を使用したいということでなければ入れ替えの必要性はない。
2002-11-20
DICE version 0.1
標題の通りようやくDICEのバージョン番号付き正式リリースを迎えることができた。サーバアプリケーションに要求される一定水準のavailabilityを達成したことにより正式という冠とバージョン番号を付けた。そもそもバイナリは2週間以上前に出来上がっていたにもかかわらず他の作業に充てる時間の都合が付かず配布にこぎ着けるのが遅れてしまった。これからも評価版としての配布が続行される。運が良ければ年内にもう一度だけバージョンアップできるかもしれない。現在DICEは少なくとも2つの点でMicrosoftが提供するあるコンポーネントに依存しているのでどちらか、もしくは双方を取り除き代替物を組み込む予定である。DICEのコアを利用した別のアプリケーションも作りたいけれど時間がない。とにかく生産性を上げる手段を見つけるしかない。この無力感をどう償えばよいだろうか。少なくともこの鬱陶しいサイトの更新で焦燥が紛れないのは確かだ。
DICE作成着手前に、過去のソフトウェアと領域が重なる無駄なものを書かないよう(誰が今日Yet another HTTP/FTP/... server/clientを必要とするだろうか)調査を行ったのはもう1年以上も前のことになる。残っている最初のソースコードスナップショットの日付は2001年の米国WTC事件の日付である。2002年9月11日のSlashdot他OSDN系列(日本語由来の単語keiretsuが実際にSlashdotの人間により皮肉を込めて用いられる)上部の広告バナーは全て9.11.01とだけ右下隅に記した喪章を表す黒い矩形だったのを覚えている。その日の何日か前に前回ここにSlashdotについて書いた後で私の提出したstoryが取り上げられた。執拗に提出を続けて10分で却下されることもあった身としては思いがけず自分の投稿を発見したときは思わず頬を緩めてしまった。400を超すreplyがあり(funnyが多かったのはともかくとして)、2chのスレ立てに反応の量では下回るものの自己満足としては悪くない。東アジアの2chに同じく、Slashdotは西側世界で認知された一つの現象であり、しかも2chのように興味が分散しているのではなくcover storyに幾らとも知れない多数の人々の視線が集中する(アカウント制なので興味のないトピックは無視できるというのはまた別の話だ)。
ここしばらくPCゲーム自体にやや縁遠くなっていた。そんな時に大作という評判にとりあえず手を付けたMafiaが最初は疑わしかったものの実際は深く広い作品だったので反動で没入することになってしまった。エンディングのスタッフロールを見てぶっ飛んだが製作のIllusion Softworksはチェコ/スロヴァキアの会社でプログラミング以外のスタッフ/アーティスト/声優他も皆チェコ人らしき名前だった。こんなわかりやすい形で壮大なゲームは奇を衒ってばかりの日本の会社には無理だろう、残念ながら。
ところで私のこのサイトには結構Morrowindを検索して飛んでくる人がいるが全く関連情報はないことを断っておく。拡張パックTRIBUNALが今回リリースされるMorrowindは抑えたデザインが美しく、見るからに垢抜けないMight & Magicなどより対象年齢が高そうに見えるが、Dungeon Siegeをやった後だとNeverwinter Nights(これもやり始めてすぐに放棄)ですらまだるっこしく見えるのだから、とてもではないがそんな大作など息をつきながらプレイする気にはなれない。FPSでストーリーが付いているものがいいところだ。今後の人生で純正のRPGを最後までプレイする機会が果たして訪れるだろうか。Fallout以降のBlack Isle Studiosの小さなキャラがちょこちょこ動くタイプのRPG用エンジンは見るに堪えないので何故あんなものが高い評価を受けているのか理解できない。嫌いと言えばRTSは無意味な作業に時間がかかるので嫌いである。そんな私でもGTA3と並ぶ最近一番のヒット作Warcraft IIIは随分前にクリアし、シナリオがきっちり構成されたシングルプレイキャンペーンで主人公級のキャラクターによる大量虐殺や父殺しという日本の子供向けゲームではあまり現れないであろうものがあっさり描かれていたのが印象的だった。
そしてUnreal Tournament 2003である。デモですら相当に遊べるパッケージに仕上がっていたこのゲーム、完成版は納得の出来だった。前作同様、同時期のFPSと比べて明らかにエンジンの完成度が高くGeforce4 Tiでプレイすると高FPSを叩きだしてくれる。延期を繰り返しただけのことはあり期待を裏切らない作品になった。ただAssault Modeが無くなり、作品のトーンもコンソールを意識したのかやや軽いノリになっているのでその辺り意見が分かれるかも知れない。そうはいってもボールギャグを口に嵌めた犯罪者が飛び回りながら他の競技者を虐殺するという展開のゲームなのであとは推して知るべしといったところか。ただ、シングルプレイを終えてみると、デモをやっていた頃はいくらでも遊べそうな気がした物が単調な繰り返しに思えてきて滅入ってしまった。こうなってくると年内に出るか出ないか情報が錯綜しているUnreal IIの方へ期待したくなる。短時間のアーケードプレイよりじっくり楽しめるシングルプレイの方が私は好きである。前作は主人公が囚人という設定で、陰鬱な、しかし美麗に仕上げられたグラフィックを用いて構成されたタイトルだった。これもUT 2003と同じくIIでは子供受けする軽いノリに変更されてしまうのではないかという点が気がかりだ。
そしてDICEのリリース遅延は、最近AOMを始めたことにも一因がある。前作は難易度が高く最初から放棄し、またRTS自体時間を無為に過ごす感覚が払拭できず嫌いなジャンルなのだが例外が無いわけではなかった。今作はWarcraft IIIを追うかのようなストーリー/ヒーロー重視のキャンペーン設定でしかもWarcraft IIIよりは幾分か地味な印象すら受ける。にもかかわらず何故かその淡白なところに惹きつけられた。長く完成が待たれていた大作だがメディアのセンセーショナルな反応もないのが面白い。ゲームをプレイしてみて気付いたのはとにかく軽いアプリケーションであるということだ。
ほかにネットでよく見るものといえばPhoenixのBugzillaくらいだろうか。PhoenixとはMozillaプロジェクトの一つで重量級のMozilla本体とは毛色の異なる軽量ブラウザパッケージを作るというプログラムである。私が旧Netscapeからの流れでMozillaの常用を考慮する場合にどうしても解決して欲しかったバグがあるのだがMozillaでは1年近くもそのパッチが出ているにもかかわらずレビューが停止しており最近見切りを付けて全面的にIE系へ向かうところだったのが、Phoenixではそれが解決されていたので一気に惹かれていった。上述のパッチを書いた人間がPhoenixの方へ強くコミットしていたので納得したが、とにかくMozillaよりは追跡プロセスが早い。バグと言ってもBugzillaの場合広義のバグとして機能拡張の要求まで含んでいるので機能不全としての狭義のバグを報告するついでに他人任せの要求を出して楽しんでいる。PhoenixがMozillaの死骸から復活するというメタファは面白い。
Slashdotでは日本製の電子ガジェットについての話題がしばしば取り上げられ、日本人についての賛否含む言及も付随して現れる。日本人がLとRの発音を区別できないことを揶揄して'rinux'という表記も散見されるが、その他に"All your base are belong to us"という一文がジョークとして何度も挿入されているのに気付いた。説明も無しで意味不明なので検索したところ面白い日本語のサイトを見つけた。Jap-O'-Lantern内の、Jap in the Boxがそれであり、洋ゲー好きには感涙物の、海外ゲームが取り上げる奇妙な異世界としての日本が集成されている。"All your base are belong to us"をめぐる事情についても非常に詳しい。そしてまた抑えたコメントの挑発的なこと... 資料サイトに付されたコメントまで気が利いている。Jap-O'-Lanternはその他のコーナーの内容も、デザインも本当に見応えがある(実はゲームの話などよりも別の部分の、日本のJavaの雑誌などによく登場するある企業の成り立ちについての言及が興味深かったのである)。愛が溢れている。必見である。
海外ゲーム中の日本について述べている側から、Devastationという近々リリースされるであろう新Unrealエンジンベースのゲームの舞台として極東(日本とは明記されていない)が登場するらしい。新Unrealエンジンによる日本の神社(?)の精緻な描写は見応えがある。ちなみにDevastation販売元のARUSH EntertainmentはDuke Nukem: Manhattan Projectという非核三原則に抵触しそうな名称のゲームの販売元でもある。そちらは懐かしい横スクロール型のコナミコントラクローンでバカゲーっぷりが良い。同時にクソゲーでもあるけど。こっちはいつ出るの?
世界の非対称性はオリエンタリズムを論じたり9.11.01を引き合いに出したりするまでもなく自明だ。洋の東西を問わず日々新しい歴史が形成され、そして失われる。この無力感を、どう償えばよいのだろうか。圧倒的な忘却の進行を止める術はなく、我々にできるのは、テロリズムに訴えることを除けば、ただ笑うことのみである。
2002-09-XX
忙殺
現在DICEは配布停止中である。というのも次バージョンのリリースが2週間近く遅れてさらに未定扱いとなってしまい今後について逡巡してるのである。UT2K3も今週末には出ちゃうし... どうしよ。それはともかくいやーMafiaいい出来だ。GTA3よりずっと深みがあるし同時期に製作されたとは思えない。
2002-06-01
初夏の訪れ
半年と下で書いているがあっさり1月で次の更新が来てしまった(DICEをDICE prototypeとして更新版をリリース、VirtualDirectory単体動作を可能とした)。DICE prototype(DICEの単体動作版)はこれで事実上の最終版なので、次回更新は未定である。
前回更新後、Dungeon Siegeのシングルプレイヤーをクリアしたがエンディングがやや淡白であるように感じた。マルチプレイヤーの存在が前提となっているにせよ、洋ゲーのいわゆる大作とされるゲームのシングルプレイヤーで、エンディングに大クライマックスを持ってきたものには近年お目に掛かったことがない。何か食い足りないのである。かつてのメモリ量に厳しい制約のあるコンソール向けゲームは執拗にエンディングを引き延ばしてじらすものが多かったのでそのリズムが肉体に刻み込まれているに違いない。次はMorrowind、GTA3、SoF2だ!(と書きつつMorrowindは既に放棄)
VIAチップセットのM/BにPC2700メモリを挿してBIOSのメモリアクセス設定をパフォーマンス優先にしたところいわゆるビット落ちが起きてしまった。その結果、HDDからの大き目のファイルの読み出しでCRCエラーが発生するようになった。またVC++はコンパイラ内部エラーを3回に1回出すのでVC7のバグかと勘繰ったが当然そんなことはない(gccのベータでC++のコードをコンパイルした場合ならあり得る話なんだけどね)。VIAの掲示板はこの件で大荒れしていたが幸い自分のPCではメモリアクセス設定の変更で解決した。しかしそれに先立って20GBのデータをHDD間でコピーし4GB分のデータをDVDに焼いていた... 無事を祈るばかりである。
2002-05-01
春雨
先月から不覚にもDungeon Siegeにのめりこみ、気が付いたらシングルプレイ中盤を超えていた。反省しつつ中止する。次にプレイするのは半年後だろうか。 Unreal Tournament 2003後に再訪の線が濃厚である。Unreal 2は来年?
PCゲーム情報、PCゲーム用ハードウェア/ソフトウェア情報は、GameGuruがよろしい。先日は英語のサイトばかり紹介したので、英語に関する面白いサイトを2つ。Japanese Engrish(sic)は日本人の愉快な英語を取り上げ、amirightには聞き取りにくい英語の歌詞や替え歌が集められている。
ゲームを中止するとともに、本日DICEの初めての改版をアップロードした。DICEに関しては今後4-6か月程度は更新を期待できないので先の初回リリースバージョンでダウンロードをためらわれた方がいたとすれば今度こそ気兼ねなくダウンロードして頂きたい。そして半年間ながら、さようなら。
2002-04-12
リンク紹介に代えて
ブラウザを起動して真っ先に見るのはSlashdotだ。日本版もあるが、輸入品の常かはたまた輸入業者が悪いのか見るに耐えない代物になっているので(まずもって"アレゲ"というのが本質的な意味で頭が悪そうでキモい)、もっぱら本家のみ見ている。Slashdotは基本的にU.S.のサイトで"United States"というニューストピックもあるので、日本に持ってくるのが間違いである。Slashdotを構成しているプログラムであるSlash (Apache+mod_perl+MySQL)を使って別個のサイトを作るのならまだしも、Slashdotのブランドをそのままコピーしたサイトを支持するというのはいかなる意味を持つだろうか。日本人=copycatという誹りは免れないだろう。テクノロジを真似るのは大いに結構だが、精神やスタイルまで真似る必要は無い。もしくは、そう悟られてはならない。その意味で、日本版Slashdotには、VA Linux JapanのPR部門以上でも以下でもない非常にナイーブな試みであるという印象を禁じ得ない。一昔前の雑誌や最近のTV番組でアメリカのフレームワークを輸入して使用するものがあったが、インターネットではその類に出会いたくないものである。というのは、海外だろうがどこだろうがダイレクトに一次ソースへ到達することができるからだ。そして、Slashdot自体が既に、インターネット上の他のサイト(含ニュースサイト)をポインタとして情報を伝えるサイト、つまり二次使用素材(悪く言えばパクリ)を主とするmeta weblogなのである(時折運営側による大して面白くない問題提起が行われるにしても)。
さて、Slashdotには"アニメ"なるトピックがあり、これがOSS (Open Source Software)コミュニティと一体いかなる関連性を持つかについて常々非難の的になっている。これはSlashdot運営者のhemosとCmdrTacoの趣味によるもので、特にCmdrTacoはEverything (Apache+mod_perl+MySQL)によるアニメDVDレビューサイトAnimeFuを運営している。DVDレビューサイトでspoilerを含むことが出来ず突っ込んだレビューはできない場ではあるが、逆に短くまとめられているのでなかなか楽しく読める。特に、日本の素材を外国人がいかに解釈するかというのはいつ見ても面白い。それは、ゲームコンソール産業においても同様だ。AnimeFuは基本的にDVDが対象なのでエンコーディングクオリティやメニューについて一言付けられているが、ファイル共有サービスやIRCで有志が字幕付きで配布した海賊版DivXムービーについてコメントしてしまう者もいる。先述のようにストーリーについて詳細に検討することが禁じられているせいか、何故かcharacter developmentの有無が非常に大きな評価の分かれ目になっているようだ。アニメといっても絵そのものより演出や脚本に目が向いているのは興味深い。単にエキゾチックでオリエンタルなものが求められているのかそうでないのかは、今後の海外での日本アニメ産業の受け入れ状況を見守る必要があるだろう。
自作ソフトウェアをここで公開している関係上プログラミングに役立つサイトも紹介しておこう。Slashdotを最初に紹介した手前、SourceForgeを紹介しないわけにはいくまい。最近日本語版も作られた。本家でも日本語表示は出来るが、日本語版は日本語でのオープンソースソフトウェアプロジェクトのみを支援するようだ。自分では開発支援サービスを利用しないが、SourceForgeは有名無名の星の数ほどのプロジェクトが入っているので見て回るだけでも非常にためになる。また、Microsoft Windows上での開発に非常に役立つのがThe Code Projectである。類似サイトとしてCodeGuruがあり、日本ではよく引用されるが、前者の方が更新ペースが速くup-to-dateで使える記事が多い。ゲーム開発なら、Gamasutraがマーケティング含めて全てをカバーしている。私は標準C++が好きなのでその関係のサイトをよく見るが、C/C++ Users Journalの雑誌自体は有料ながら、C++ Experts ForumでC++についての最先端のコラムが読める。Modern C++ DesignのAndrei Alexandrescu氏や、Exceptional C++のHerb Sutter氏が書いているので、読み物として面白い物がいくつも公開されている。またANTLRというJava/C++/Satherのコードを生成できるパーサジェネレータも見つけた。Lex/Yaccに代わる、C++のコードを生成できるフリーソフトウェアである。そのほか、Microsoft Xbox部門のプログラマPete Isensee氏によるC++の最適化に関するテストのページも面白い。日本では、最近標準C++のMLを始めたepisteme氏のサイトにC++に関する記事がある。
毎日チェックするサイトとしては、Mozilla.orgを忘れるわけにはいかない。常用するには現段階ではかなり辛いものの(おそらくあと1年くらいはかかるだろう)、Mozillaの完成度は徐々に向上している。半年ほど前までは本当に使い物にならなかったのだが、そこから考えれば、1.0を迎えて相当に安定性が増した。Nighty Buildをほぼ毎日ダウンロードし、Bugzillaで自分が報告したバグの状況はどうなっているかとチェックしている。Bugzillaでバグをリポートすると早いものでは数時間でパッチが提供されるなどフィードバックを得ることが出来るのでなかなか楽しい。反面、修正されないバグはいつまで経っても修正されないのが歯痒いのだが。