[DE | EN | FR | IT | JA | ES | KO | PT]

多くの読者を触発できるはずのプロジェクトでいっぱいの、 Brave GNU Worldの新しい号へようこそ。

今月も最初は、 きっと誰かが考えたように、 Free Softwareのゲームの紹介で始まります。

Trophy

Andrew Mustunは、 計算機科学の研究を中止したためにできた穴をふさぐため、 Trophy [5] の開発を2000年3月に始めました。 Trophyは、 ゴール通過以外の目標もある、 2次元鳥かん型の自動車レース・ゲームです。

具体的にいうと、 ゴールの通過は実はどうでもよく、 ちょうどジェームズ・ボンドものの映画によくありそうな、 装備が車にはあって、 そういうアイテムを好んで使うからです。

スムーズなスクロールにはパワフルなコンピュータがお勧めではありますが、 しっかりしたグラフィックスとサウンドのおかげで、 相当アクション・ファンの友だちをうならせるにもすでに十分なゲームに仕上がっています。

TrophyはC++で書いてあり、 AndrewはこれをGNU General Public Licenseの下でリリースしています。 最大の弱点は、 ネットワーク・プレーのオプションがないことではないでしょうか。 Andrewは今、 従事している研究が忙しいので、 また時間がとれたら、 これをやる予定ではいます。

この記事の準備にあたり、 Andrewは、 銃に反対し平和を愛す一個人であると同時に、 車は銃ぬきでも十分危険と考えてもいることを、 強調していました。 ともあれ、 25の彼はいまだ運転免許をもっておらず、 車の運転はしません。

ですがそのことも、 Trophyでつぶす楽しい午後のひとときを減じることにはならないでしょう。 レースの間、 GIMPでトラックの設計をすることに気晴らしを見出そうという人も、 大丈夫。 Trophyのホーム・ページには、 そうする方法が書いてあります。

ネットワーク・オプションのないことはかなり大きいので、 興味ある開発者はもちろん自分で実装してみることを歓迎します。 この方面での手助けにたいし、 Andrewは本当に感謝することでしょう。

Adonthell

Adonthellプロジェクト [6] は、 Freeな2次元ロールプレーイング・ゲームの作成におおわらわです。 これは初期の端末版のSNESに似ていますが、 より自由度を高めるようにしてあります。

多くのゲームでは、 それぞれ理解しやすい連結部分が2つあります。 ストーリー、 グラフィックス、 音楽などといった内容の重要さは、 ただちに明らかです。 たとえばプレーヤとのインターフェースをとりもつような技術的な構成部分は通例、 「エンジン」といいます。

それらしいたとえは、 プログラムとOS、 楽譜と楽器の関係といったところでしょうか。 この分離により、 言語による抽象的形式と、 エンジンにより決まる能力の2本立てで、 ゲームを書けるのです。

Adonthellプロジェクトは、 固定のストーリーのゲームを開発するだけではありません。 むしろロールプレーイング・ゲーム用のエンジンを開発し、 そのエンジンにストーリーを解釈させ、 それにそってゲームをすすめます。 全リリースにおいて、 コードのみならず、 完結した小さなゲームもつける予定です。

ごくふつうの出入りはありますが、 Adonthellの常連チームは、 Kai Sterker、 Alexandre Courbot、 James Nash、 Benjamin Walther-Franks、 Joel Vennin、 Joseph Toscano、 Mike Nieforthです。 このうち3人だけがプログラマで、 ほかは、 音楽家、 グラフィック・アーチスト、 作家です。 この組合せと、 年1度は直に打合せをするというメンバーのこだわりのおかげで、 ゲームはプロ級の「感じ ("feels")」がし、 インターネット上の活気ある会社のいい例にもなっています。

Adonthellのコードとグラフィックスは、 GNU General Public Licenseの下でリリースされています。 エンジン自体は、 C++言語で書かれています。 ゲームの制御、 拡張、 ゲーム内のスクリプトは、 エンジン埋込みのPythonインタープリタによります。 そのため、 Adonthellエンジン用のゲームをC++部分に触らずに書くことができます。 音楽については、 OGG Vorbis [7] が使われています。

優先事項の1つは、 エンジンとゲームを別々なパッケージにできるようにすることでした。 (今は) ちょっとしたPython (のスクリプト) 同様、 マップやダイアログのエディターのようなツールの説明文と、 エンジンをインストールする必要があるだけです。

これをもっとおもしろくするため、 Adonthellグループは、 歴史、 慣習、 特性のある完結した世界の作成に取り組んでいます。

Brave GNU Worldのアンケートに答えてくれたAlexandre Courbot曰く、 次の段階は、 蓄積した経験をもとに多くのコードを書替えだそうです。

チームはいまだに、 ほかのプラットホームへの移植を喜んで手伝ってくれる人たちをさがしています。 GNU/Linux、 FreeBSD、 OpenBSD、 BeOSで、 ゲームの動作確認がされています。 長期的には、 独占的なOSの利用者に最初の自由を味わってもらうため、 そうしたOSへのサポートも計画されています。

開発内部では、 ネットワークでのプレーができるよう、 クライアント/サーバーを基本にしたアーキテクチャーへの移行がすすんでいます。 多数のプレーヤのサポートは予定外ですが、 中数のプレーヤが永続的な世界で対話できるようなAdonthellの拡張はすべきでしょう。

1999年の第1歩から、 Adonthellはすでにかなりのところに到達おり、 さらなる開発に希望が託されています。 それなりのスキルをおもちで、 もう待ち切れない、 という人には、 作業のお手伝いをおすすめします。 Adonthellチームは、 すべてのサポートを歓迎しています。 [8]

そうでない皆さんの中には、 最初の遊べるリリースである 「Waste's Edge」で午後のひとときを過ごした方も、 いるかもしれませんね。

XBindKeys

Philippe Brochardは、 X11のキーにシェルのコマンドを割当てるプログラムXBindKeys [9] を書きました。 メーラー、 ブラウザ、 xtermといったよく使うプログラムを、 メニューを行ったり来たりせずキーの組合せで起動できます。 キーボードから手を離す必要なくあることができるようになることに慣れてしまうと、 この能力なしではいられなくなってしまうことでしょう。

一部のウインドー・マネージャは、 元々キー割当てをサポートしていますが、 たいてい全部のキーが割当て可能にはなっていません。 たとえば、 一部のキーボードだけにしかない特殊なキーなどがそうです。 Philip自身、 彼のキーボードにある「power」キーの押下でシャットダウン・メニューを出すために、 XBindKeysを使っています。

新しいウインドー・マネージャを使ったり、 場合ばあいで色々なウインドー・マネージャを使い分けたりする皆さんも、 お好みのキー組合せを新しいウインドー・マネージャに教えるときの問題を、 ご存じのはずです。

XBindKeysはこの問題を両方とも解決してくれます。 これもまたPhilippeの書いたミニプログラムである MoveMouse [10] との組合せで、 あらかじめ指定した場所にキー一発でマウスをもってくることもできます。

XBindKeysとMoveMouseは、 両方ともCで書かれ、 GNU General Public Licenseの下で入手可能です。 というのも、 Philippeは、 これがGNU Systemにたいする自分の貢献だと感じているからです。

XBindKeysの設定は、 わかりやすいのべたんのASCII設定ファイルを直に編集するか、 Laurent Vuibertの書いたGTKフロント・エンドのXBindKeys-Config [11] を使えば、 できます。

注意点として言っておかなければならないことは、 ウインドー・マネージャを上げる前に、 XBindKeysをちゃんと立ち上げておかなければならない、 ということです。 そうすると、 打鍵がウインドー・マネージャに横取りされず、 XBindKeysに行きます。

XBindKeysは安定しており、 Philippeはこれを小さく便利にしておきたいという信念をもっているので、 今後の開発予定はありません。 ひろがりつつある「機能主義 (featureism)」に対抗する良い例を、 これは示しています。

Access Road

ITセキュリティーは、 疑いなく非常に複雑ですが、 重要な分野です。 プログラムにあるバグの可能性を意識することは、 適度によいことですが、 「バグなし (bug free)」でうごくプログラムの組合せで、 セキュリティーのプログラムをつくることもできるはずです。

複雑な環境や問題は、 ときとして、 かなり複雑であいまいな情報システムを要求します。

アクセス制限ぬきでは、 データは、 乱用されたり、 内密に変更されたりします。 この問題は、 たとえば、 コンピュータを基礎とした病院を考えたとき、 すぐ明らかになります。 その反対、 つまり、 すべてのアクセスへの全面制限でも、 すべての作業が不可能になるため、 うまい考えではありません。

となると、 当面の問題は、 便利で必要な活用が可能な一方、 乱用が不可能になるよう、 システムを設計することです。

そのようなシステムの着想は、 人間のすることですから、 有意で潜在的な誤りが、 常にありえます。 Patrick ThazardによるAccess Road [12] は、 情報システムの複雑な環境のモデル化と、 視覚化を管理者用にしようとしています。 これ自体、 セキュリティーを高めるものではありませんが、 さもないと見過ごしてしまいそうなセキュリティー上の問題発見を援助してくれます。

Patrick Thazard自身は、 1987年からコンピュータ・セキュリティーのコンサルタントとして働いており、 GNU General Public Licenseの下、 JavaでAccess Roadを書きました。 文献はGNU Free Documentation Licenseの下でリリースしました。

Access Roadは現在、 GNU/Linux風のシステム、 簡易ルーター、 Solaris風システムをサポートしており、 最後のリリースまでデータの更新がなくても、 他の開発者用にかなり役立つ構造をすでにあたえている、 とPatrickは確信しています。

今後の計画には、 まずGNU/LinuxとApache間での相互作用、 そしてその後で、 OSと活用中のDBMS間の相互作用の追加があります。 長期的展望としては、 CORBAのようなモデリング・システムや、 Windows 2000/XPへの拡張で、 システムが完結するはずです。

その前にもしなければならない作業はまだそれなりにあり、 Patrickは彼の作業を喜んでサポートしてくれる開発者をさがしています。 一般的なグラフィカル・モデリングのアプローチに潜在的な弱点があるとしても、 このプロジェクトはすごくおもしろく、 新しい手法への道をひらきそうです。

GNU Cons

GNU Cons [13] は、 その先達にあたるプログラムである GNU Make [14] の代替の1つです。 ソースからインストールするソフトウェアをダウンロードしたり、 Linuxカーネルを再コンパイルしたりした人なら、 「make」というコマンドをぽんと入れ、 GNU Makeを使った、 ということがあるでしょう。

Makeの書かれたころは、 手やBash (訳注: ボーン・アゲーンというよりただのボーン) シェル・スクリプトでプログラムをコンパイルしており、 当時としては、 非常な進歩であったわけです。 ですが、 自分でメークファイルを書こうとしてみれば、 その文法がかなり理解しがたいものであることが間違いなくわかるはずです。 そのため、 多くの開発者がうごくメークファイルを他のプロジェクトからパクって、 自分の目的用に直したり、 GNU Automakeのような別のプログラムで自動生成したりするわけです。

それにもまして、 Makeの更新検出は最終更新時刻のみに基づくのですが、 これでは、 別なコンパイラ・オプションで再コンパイルしようとするときにはうまくいきませんし、 問題のあるところです。

GNU Consという名前は、 プログラムを"Cons-tructed" (被構築) にする助けにできるよう、 選ばれました。 その目的は、 GNU Makeのおこなうべき仕事をこなすことです。

その中心的構成要素は、 ファイルが修正されたかどうかを検出するうまい機構です。 GNU Consはファイルの修正時刻を見るだけではなく、 ファイルの良好な同定となるMD5痕跡で作動します。

こうした能力のよい例は、 次のような状況でのGNU Consの振舞です。 プログラム「test」が「test1.o」「test2.o」「test3.o」からできている、 とします。

プログラムの最初のコンパイル後、 オブジェクト・ファイル「test2.o」をわざと損傷、 破損させます。 GNU Consの次の呼出しで、 「test2.o」の再構築をし、 プログラム「test」の再リンクをしません。 なぜなら、 生成版の「test2.o」が前にリンクしたときと同一であることが、 GNU Consに検知されるからです。

別なコンパイラ・オプションでGNU Consを呼び出したときは、 結果だけでなく、 生成パラメータも比較対象なので、 全部分が再コンパイル、 リンクされます。

GNU Consは、 すでにこの作業から引退したBob Sidebothamにより、 Perlで書かれました。 Rajesh VaidheeswarranとSteven Knightが、 安定版 (Rajesh) と開発版 (Steven) の管理者を引き継ぎました。 GNU Consは、 GNU Projectの一部として、 GNU General Public Licenseの下でリリースされています。

Perlを使っているおかげで、 GNU Consは、 WindowsやUnixモドキでもうごきますし、 おなじみ「メークファイル」と等価な構成ファイルでは、 非常に動的かつ、 複雑な表現で、 可能なかぎり、 プログラムをあるシステムにカスタム化することができます。

GNU ConsはC/C++にかたよっているとはいえ、 十分使えるところにきています。 他のプログラミング言語は、 Johan HolmbergのCons::Plusモジュールで、 アクセスできます。 また構成ファイルはいうまでもなくややPerl寄りですが、 これには多数の人にプラスとはいえないものがあります。

この記事のしめくくりに、 Brave GNU Worldで標準の質問にかなり長々と回答してくださったGNU Consチームへ、 謝意を表しておきたいと思います。

Rajesh VaidheeswarranとErich Waeldeは、 この記事ではほとんど割愛せざるを得なかったにもかかわらず、 私にとってかなり興味深かった実例をたくさんあげ、 膨大な情報を寄せてくれました。 興味をもった開発者らにConsを試してみるべき理由を考えていただける程度に、 重要な特長の一部が十分理解されるよう、 私は期待するものです。

SCons

GNU ConsとSCons [15] 間の名前の明白な類似性は、 偶然ではありません。 SConsの設計は、 大部分GNU Consに基づいており、 GNU Consの開発版の管理者であったあのSteven Knightが、 2000年8月ソフトウェア大工仕事大会 (Software Carpentry competition) 用にこれを書いたのです。

しばらくの間Consの管理をした後、 この大会に向け、 ConsのアイデアとPythonのパワーを合体させる、 という目標を彼は追求しました。

SConsは、 そのときの作業に基づいています。 Consのように、 すぐれた修正検出と、 依存関係解決の能力をそなえますが、 構成ファイルはPythonを基本としています。 またSConsは、 コマンド行オプションでのスレッド数の指定の可能な並列コンパイルを、 すでにサポートしています。

SConsはまだやや若いプロジェクトです。 最初のαは2001年12月13日にリリースされました。 そのため、 かなり短期間で機能の追加をともなったリリースが、 おこなわれています。 誕生からの後方互換性や品質の維持のため、 強力な退行試験基盤でプロジェクトが作業中であるとしても、 日常活用には差障りがあるかもしれません。

計画中の拡張リストはまだまだ長く、 そこにはJava、 C#、 Fortranの良好なサポートだけでなく、 アーカイブやいくつかの形式 (PDF、 PostScript、 TeXその他) での文献生成能力が、 載っています。

SConsは、 自由を守りとおせないことがわかっているX11式の許諾の下でリリースされています。 長期的展望からはGPLの選択の方がよい、 ということはいえますが、 SConsは明らかにFree Softwareの資格があり、 一見してみたり、 参加してみたりするのは、 明らかにいい考えです。

おしまい

さて、 今月のBrave GNU Worldは、 このへんで。 次号のため私は、 とあるプロジェクトをしまいこんであり、 紹介するのをもう楽しみにしてます。 これで私の生活も楽になり、 みなさんもまたそうであるだろうことを望みます。

それまでの間、 ご機嫌よう。 ご提案、 お考え、 コメント、 フィードバック、 プロジェクトのご紹介を遠慮なさることのないよう。 できればメール [1] にて。