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

Brave GNU Worldの新しい号へようこそ。 第31号 [5] ではFreeCIVをとりあげ、 皆さんへは他のFreeなゲームの例について尋ねさせてもらいました。 フィードバックはなかなか良好で、 今回は、 いろいろなジャンルのゲームをいくつか紹介することにします。

BZFlag

今号最初のゲームであるBZFlag [6] の話をするのに、 たいして時間はかかりません。 各プレーヤは、 3D風景の中で戦車を操縦し、 他のプレーヤを撃ち、 敵の旗を奪い、 アイテムを得ようとします。 つまり、 LANやインターネット上で複数の敵を相手にする古典的「早撃ち」 ("shoot em up") ゲーム、 というわけです。

BZFlagは、 Chris Schoenemannが1992年、 卒論の作業をうまく回避したCornell大学での、 "Program of Computer Graphics"に端を発します。 他の学生の参加により、 BZFlagは急速に進歩し、 まもなく、 多くの学生におなじみの消閑の具となりました。

このゲームは当初、 iris-gl風グラフィック・ライブラリーを使ったHP-UXワークステーション用に書かれましたが、 第3回"SGI Indizone Contest"の開かれたとき、 Chrisがこれを全面的に書き直して、 グラフィックを改良し、 サウンドを追加しました。 BZFlagは、 独自のカテゴリーをきりひらきました。 さらなる拡張の後、 ChrisはこれをGNU/LinuxとWin32に移植し、 GNU General Public Licenseの下でFree Softwareとしてリリースしました。

これまでにTim RikerがBZFlagの管理を引き継ぎ、 いっしょに10数人の開発者がSourceForgeでこれに取り組みました。 そのおかげで、 SourceForgeで活発なプロジェクトのトップ10に数回、 入ったことがあります。

Chrisによれば、 なかなかいいゲームプレーと、 バランスのとれた迫力がBZFlagの特長だ、 とのこと。 経験豊かなプレーヤとの決闘では、 複雑な躍動に終わってしまうよう、 戦車の前進、 回転、 発砲、 再装填速度が調整されています。 そこでは、 戦略上の些細な誤りがすべてを決定します。

ホーム・ページのコメントが、 その何よりの証拠です。 なんと「米陸軍戦闘工作訓練センター」 ("U.S. Army Combat Maneuver Training Center") の人たちまで、 BZFlagを好んでプレーしている、 とのこと。

BZFlagの問題部分は、 ネットワーク関係のコードです。 このゲームは元々、 高速で変化する情報をマルチキャストや、 ブロードキャストで伝送できるローカル・ネットワーク (LAN) 用に設計されました。 一方、 奪った旗などの情報がなくならないよう、 サーバーとの通信はTCPでおこないます。

インターネットでプレーできるよう、 UDPのパケットをTCP上でも伝送しますが、 これはタイミングで大きな問題をひきおこします。 これまでのところ、 サーバーはUDPパケットをUDPで伝送しますが、 伝送上の問題があると接続が妨害されがちなので、 TCPの利用はすべて置き換える予定です。

次のリリースでは、 ネットワーク化にともなう潜在的問題の整理が目的で、 バグも減り、 また「インチキ対策」 ("cheat-proof") も向上するでしょう。 長期的には、 さらなるプレーのモードと、 グラフィックス・エンジンの全面改訂が、 役に立つことでしょう。

Chrisの望んでいるほどうまく進んでいないMacintoshへの移植には、 手助けが必要です。 また、 BZFlagで改良可能な部分は、 ネットワーク・プロトコルだけではありません。 グラフィックス、 コンピュータ側の人工知能プレーヤ、 物理法則モデルは、 つねに注目に値する面です。

Arkanae

今号の次のゲームは、 ロールプレーイング・ジャンルの代表です。 Arkanae [7] では、 世界が"Arcance"という信じられないほど強い7匹の生物に支配され、 プレーヤはその世界を救わなければならない英雄になります。 この生物は、 人類のために一度、 強力な水晶で封じられたのですが、 ふたたび自由の身になったのです。

このゲームには、 一部の人にとっては驚くべき3Dグラフィックス品質と、 一本道でない広大なストーリーがあります。 プレーヤは、 善悪どちらのために戦うのか、 またどのように隠された宝を探し、 謎を解き、 モンスターと戦うのかを、 選ぶことができます。

Arkanaeに使われているプログラミング言語はJavaで、 3次元ハードウェア・アクセラレーションのきくようArkanae専用に書かれたJava 3D Engineのopale.soya [8] を使っています。

ご参考までに、 このエンジンは、 Fraunhofer InstituteのM3 ("Man Model Measurement") プロジェクトのバイオモデリング部分で、 3次元視覚化に使われているものです。

Javaを使った結果、 このプロジェクトはプラットホームと無関係に、 GNU/Linux、 Mac OS X、 Windowsでうごきます。 しかしそれと同時に、 Javaにいつもある問題があります。

つまり、 Javaをちゃんとインストールするのは往々にして冒険だ、 ということと、 全機能を提供するFreeなJavaの実装がいまだにない、 ということです。 たとえば、 ArkanaeはSun JVM 1.3やBlackDownに依存していますが、 どちらもFree Softwareではありません。

つまり、 GNU General Public Licenseの下でFree Softwareとして許諾されているArkanaeが、 かなり技術的な問題のある独占的プラットホームに依存しているわけです。

これはゲームとしては致命的でないとはいえ、 Free Softwareのコミュニティーは、 FreeなJavaの実装を促進するか、 さもなくばJavaぬきでやるか、 ということについて、 もっと考えるべきだ、 といえます。 Javaの背後にある思想はとても有用ですので、 Freeな選択肢を強化していく方がたぶん望ましいでしょう。 "GNU and Java"ホーム・ページ [9] では、 序説をみることができます。

しかし、 Arkanaeの試用に興味のある人は、 このことで楽しみをふいにすることはありません。 なぜならArkanaeのもたらすものはかなりのもので、 すでにフランス語、 英語、 ドイツ語、 イタリア語用に地域化されているからです。

Arkanaeに関連した問題は、 Windowsプラットホームです。 スレッドのサポートがないため、 キーボード管理と音楽がめんどうだからです。

作者のBertrand Lamy、 Jean-Baptiste Lamy、 Althea Chiaは、 シナリオを完成させ、 Arkanaeを完璧にしようとしています。 Bertrandの将来の計画には、 Cの3Dエンジンで現在準備中の別のゲームがあります。 Jean-BaptisteはPythonを知って、 何かプロジェクトを立ち上げようと思っています。

レベルを増やすというかたちでのArkanaeへの手助けは、 特に有用でしょう。 レベルのエディターは確かにありますが、 これを使うのにはややてこずるので、 潜在的レベル・デザイナ用にBertrandは入門コースを用意しています。

これはこのへんにして、 次はロールプレーイング・ゲームのファン注目の話題。

XShipWars

数年前、 宇宙戦争シミュレーションのEliteをプレーした人ならだれでも、 XShipWars [10] にかなり熱中しそうです。 Eliteと同様、 プレーヤは、 外交、 貿易、 戦闘での援助をうけつつ、 広大な宇宙空間を生き残らなければならない宇宙船の船長を引き継ぎます。

ゲームは、 ほぼクライアントとサーバーからなっています。 サーバーは、 クライアントが宇宙空間や他のプレーヤと相互作用できるよう、 宇宙空間の処理をします。 宇宙空間自体は、 主にプレーヤの相互作用からなります。 特別な許可をもったプレーヤは、 新しい物体を発生させ、 宇宙空間をかたちづくることもできます。 さらに、 コンピュータ制御の船に人工知能 (AI) を搭載できる特殊モジュールがあります。 こういう船は、 所属する帝国にしたがって、 他のプレーヤを助けたり、 攻撃をかけたりします。

これは、 "ShipWars"という、 純粋にテキスト・ベースの1995/1996年のゲームが出発点でした。 テキスト・ベース版はFortranで書かれましたが、 今日ではC/C++だけを使っています。 コンピュータ・グラフィックスの専門家とプログラマからなる、 ゆるやかに編成されたグループである、 Wolfpack Entertainmentにより、 (X)ShipWarsは開発されました。 この人たちのいうところによれば、 「5年にわたるプロジェクトで、 まあまあなんとか作業できた」とのことで、 GNU General Public Licenseの下でリリースされています。

当開発の副産物として、 2つのプロジェクトがあり、 XShipWarsの外部で使われています。 libjsw [11] ライブラリーは、 高能率のジョイスティック・ライブラリーで、 YIFF [12] は、 ゲーム用にしつらえられたオーディオ・サーバーです。 これらプロジェクトの始まった当時、 GTKやESDは考えられてさえいませんでした。

XShipWarsについてのアンケートに答えてくれたTaura Milanaが信ずるに、 XShipWarsの弱点は、 ゲームプレーにとって高速度と快適さがより重要と考えられるために、 最近の標準に十分追従できていないグラフィックスにあります。 また、 空中戦で必要な意思決定は、 初心者にとってはつらいものがあります。

それをのぞけば、 XShipWarsはかなり成熟、 安定し、 特に、 アクションと戦略のバランスは、 Tauraのかなりのお気に入りです。 XShipWarsの開発は現在、 真の機能的拡張より、 さまざまな小物にむけられています。

XShipWarsの計画より興味深いのは、 第3世代にあたる"ShipWars 3D"の計画です。 これにむけ、 OpenGLや最新技術を基にした完全な再実装が、 計画されています。

しかし、 この乱闘にすぐ参加したいという人は、 そんなに長く待つ必要はありません。 たとえOpenGLのサポートがなくても、 XShipWarsはおもしろいからです。

現在最大のXShipWars宇宙空間は、 Stein Vraleによる"Terminus"です。 XShipWarsコミュニティーの動機付けのおかげで、 Terminus宇宙空間は、 全システム、 全惑星、 全宇宙船がユニークで、 使い回しのないような場所に発展しました。 プレーヤ達は巨大な宇宙空間で探検したり、 交換したり、 自分の宇宙船を強化したりできます。

今月のゲームはここまで。 冬の夜長をFree Softwareでつぶすオプションをもう少し提供したい、 と私は思っています。 [1]

TRAMP

TRAMP「透過遠隔(ファイル)アクセス多重化プロトコル」 (Transparent Remote (file) Access, Multiple Protocol) プロジェクト [14] には、 多くのEmacs利用者が興味あるはずです。 Kai Großjohannは、 これでAnge-FTPとよく似たEmacsへのGPLアド・オンを提供しています。

ネットワーク環境では、 別マシンでファイル編集をしなければならない、 ということは、 必要なことの典型例です。 Ange-FTPでは、 このファイルをFTP経由で転送し、 ローカルで編集し、 元どおりに転送します。

FTPをあてにする代わりに、 TRAMPはsuやsudo同様、 ssh、 telnet、 rloginのようなシェル・ベースの転送プロトコルをサポートしています。 TRAMPはまた、 必要とあらば、 マシンへのアクセス方法の追加がまあまあ簡単になるよう、 設計されています。

シェル接続をとおして、 TRAMPはまずファイルの有無や、 その許可がどうかなどを確認します。 ファイルの編集については、 2つの選択肢があります。 ファイルは、 いわゆる「インライン」方式というシェル接続をとおして直接の編集が可能です。 あるいは、 Ange-FTPの動作と同様、 ローカル・ホストへ転送することができます。 Kaiはこちらの方式を「帯域外」方式といっています。

さらに、 TRAMPには制限のついた遠隔実行機能があり、 これでバージョン管理 (VC) 機構との統合が可能になります。 そのため、 CVS管理配下のファイルはTRAMPで遠隔編集でき、 リポジトリーにたいする (編集結果の) 確定は、 通常のキー操作「C-x v v」でできます。

TRAMPを使いUnixマシン上のファイルをWindowsマシンで編集することも、 理論的には可能です。 しかし、 それをちゃんと構成するには、 たとえばsshがかなりの特別版を用意しなければならないなど、 ちょっと工夫がいります。 Kaiは今のところ、 これについての詳しい説明を提供できないので、 もしどなたか多少の詳細をご存じで彼にあげてもよい、 という方は、 ぜひそうしてください。

その反対に、 Windowsマシンに格納されたファイルをUnix上のEmacsで編集するのは、 もっとめんどうです。 なぜならTRAMPでは、 遠隔ホスト上の環境はUnix風ということが、 前提だからです。

さまざまなUnix実装は、 ときにかなり異なっていることがあるので、 できるだけ安定にするため、 TRAMPは、 いつもファイル状態へのアクセスなどの方法を複数もつようにしています。 しかし標準的な各種のUnixでは、 これはまったく問題になりません。

TRAMPにはすでにかなりの歴史があり、 早期の版の名前はrssh.elで、 その後rcp.elといっていました。 Daniel Pittmanは今、 Kaiのかねてからの希望であったTRAMPの再実装に取り組んでいます。 将来の計画には、 非同期/対話的なシェルコマンドをサポートすることや、 接続の準備をもっと気のきいたものにすることがあります。

またKaiは最終的に著作権をFree Software Foundationに委譲しようと思っていて、 そうなるとTRAMPはGNU Emacsの正式な一部分になります。

Kopi

"Decision Management Systems GbmH" (DMS) のKopiプロジェクト [15] は、 Java、 JDBC、 JFC/Swing配下のデータベース・アプリケーション用開発環境を提供しています。

コンパイラでありプロジェクトの旗艦 (flagship) であるKJCは、 Thomas Grafの知るかぎり、 最近のJava仕様を完全にサポートし、 全部Java自体で書かれた、 唯一のFreeなJavaコンパイラです。

Kopi環境は、 Java Virtual Machine (JVM) のアセンブラと逆アセンブラ、 JVMクラス・ファイルの修正と生成用のライブラリー、 Java内の埋込みSQLのコンパイラであるXKJCも提供しています。 最後の目玉は、 データベース・アプリケーションをつくるための特殊な高水準言語を提供する、 アプリケーション・フレームワーク「Visual Kopi」です。

Thomas Grafは、 Kopi最大の長所はKJCの高い品質、 速度とみています。 Jacks (Jacks is an Automated Compiler Killing Suite) テスト・スイートによると、 Sun (Javac) やIBM (Jikes) のようなコンパイラを上回っています。 具体的で堅い数字をお望みの方へ、 Kopiチームによると、 1GHz Athlon上RedHat GNU/Linux 7.1を使い、 クライアント/サーバー・モードのKJCで、 Jacksテスト・スイート (1845コンパイル) に37秒以下です。

またKJCは、 危険な、 縮退したコード、 「汚らしい」読めない構文、 ありそうな最適化について、 さまざまな種類を指摘した、 完全な診断メッセージを出すことができます。 開発者にとって、 コードの保守がこれで簡単になります。

Kopiを最新の仕様どおりに維持することが、 今後の主目標の1つです。 ですから、 DMSはたとえば、 TU Viennaでの卒論で、 きたるべきJava 1.4仕様への拡張を開発したMartin Lacknerを雇いました。 またMamisoa Rajosvahは、 Visual Kopiの「開発者用ガイド」 (Developers Guide) に取り組んでいますが、 これはまもなく完成するでしょう。

GNUコンパイラ・コレクション (GCC) 同様、 Kopi実行時のライブラリーは、 GNU Lesser General Public Licenseの下で、 その他の部分は、 GNU General Public Licenseの下でリリースされています。

今号の最後に、 小さいものの興味深いプロジェクトを紹介しましょう。

CDArgs

CDArgs [16] は、 Stefan KamphausenがC++で書いた、 シェルの「cd」コマンドの拡張です。

これは、 「cd」コマンドを、 ディレクトリー・ブラウザのようなブックマーク (栞) で拡張するものです。 またブックマークを管理する統合インターフェースもあたえます。 とはいえ、 ブックマークはASCIIファイルにただの行として保存されていますので、 どんなテキスト・エディターででも簡単に編集できるのですが。

彼がこのプロジェクトのアイデアを得たのは、 ドイツのコンピュータ誌iXで、 Michael Schilliが同様な (とはいえ、 ここまで進んだものではありませんでしたが) 機能をPerlスクリプトで実装したのを見たときでした。 スクリプトはFreeでない許諾の下にあったので、 Stefanはアイデアをとりだし、 GNU General Public Licenseの下、 若干の機能をつけ、 新たな実装をしました。

国際化、 文書化、 移植性、 大文字小文字を無視したパターン照合、 構成可能なキーマップにかんするさらなる開発のため、 彼は、 ほぼClaus BrunzemaとTomi Ollilaの2人から手助けをしてもらっています。 新しいリリースはもうすぐでしょう。

CDLoop

Claus Brunzemaは、 特殊なエンドレス・プレー機能をもつCDプレーヤであるCDLoop [17] プロジェクトも書きました。 このソフトウェアの通常の利用者は、 CDの一部を、 ある表記法で書き留めておいたり、 あるいは、 それに調子を合わせたりするミュージシャンでしょう。

ふつう、 A、 Bの繰返し位置だけなら記録はできますが、 その後の修正までは無理なので、 すべてはきっかりその瞬間にボタンを押すことにかかっています。 ところがCDLoopなら、 位置の修正や、 ブックマークとしての保存もできるのです。

CDLoopは、 グラフィックのツールキットとしてguile-gtkと、 guileを使って、 C++で書かれました。 GNU General Public Licenseの下で入手可能です。

guileのおかげにより、 およそ思い付きそうな方法でCDLoopをプログラムしたり構成したりできます。 ちょっと並はずれたアプリケーションでも、 問題になることはないでしょう。

そんなところで…

私のところに時どき、 こんな質問がきます。 「Brave GNU Worldの記事って、 どれくらい宣伝になるのですか?」 この質問にたいする最終的な回答はありません。

ほとんどのプロジェクトでは、 劇的な関心の増加の有無を私に知らせてきはしません。 その一方、 私は、 あるプロジェクトでは関心が劇的に増加 (時には2、 3日で何百から何千までという) した、 という嬉しいメールを受け取ったこともあります。

しかし、 私から出せるような具体的で堅い数字はありません。 またBrave GNU Worldはさまざまなメディアで相次いでリリースされています。 時には、 ウェブ上での最初のリリースから2月以上かかることもあります。

自分の経験からいって、 Brave GNU Worldの記事でプロジェクトが評判になり、 時には他ではできない関係を作ってくれる、 ということは確かだ、 と私は言えます。 毎度のことですが、 お考え、 コメント、 フィードバック、 質問、 プロジェクトの紹介は、 いつものアドレス [1] へ。