OGRE & Cube (1)
2007/01/31 | XOOPS Cube
Cube の設計は OGRE をベースにしています。私が Cube (Shade2 という名前だった) のデザインに手をつけ始めたとき、私は PHP と Web アプリケーションを十分に習得していませんでした（今もですが）。そこで、私は私が普段扱っている設計を Xcube に持ち込みました。それはシーングラフの概念（特にOGRE）です。

この頃、私は Shade がそのまま XCube になるとは考えていませんでした。しかし、私は次のような考えを持っていました。

フレームワークなし

この当時、日本の PHP プログラマはフレームワークについてよく議論していました。そして、「フレームワーク」は日本人にとって特別な意味を持ち始めていました。日本人はよく日本語と英語を使い分けるため、「フレームワーク」はその邦訳である「枠組」とは異なるものになっていました。それは IT プロフェッショナルたちにとって重要な議論であったと思われます。しかし、私には普通でない状況に感じられました。私はそれに巻き込まれたくありませんでした。以上のことから、私は XCube はフレームワークを持つべきではないと考えました。

マルチレンダーターゲット

デザイナーはテーマフォーマットや CSS を問題視しています。しかし、これは一種の宗教論争です。私は、これは複数のレンダラによって解決可能なため、 XCube がこの手の論争に加わるべきではないと思いました。しかし、新しいフォーマットは既存のモジュールやテーマに悪影響をもたらします。私たちは同時に異なるフォーマットを使うことができ、最終出力はそれらの結果を含んでいることができるべきです。3Dアプリケーションはよくそのような目的を持ちます。私はレンダーシステムとレンダーターゲットの概念を XCube に持ち込みました。

構成

XCube の構成は .ini ファイルによって決定されます。それは DI ではないかといった人がいます。しかし、これは DI ではありません…なぜなら、 XCube はプロフェッショナルの世界でホットトピックスとなっていることに首を突っ込むつもりはないからです。実は、このプロセスも OGRE をベースにしています。 OGRE は換装可能なマネージャで構成されています。そして既にそれらのマネージャとして使用可能な多くのプラグインがあります。開発者は cfg を編集することによって、その組み合わせを決定します。これはユーザーがプログラムの初期段階に影響を与えることができる唯一の手段です（ソースコードの直編集を除けば）。 OGRE は「換装可能」というコンセプトを示すことで、「万人が納得する設計とは何か？」という不要な議論に遭遇しなくなりました。

換装

XCube はウェブサイトを実現するための具体的な関数を持っていません。これも OGRE のコンセプトです。 OGRE は非常にコンパクトなエンジンです。それは力学、AI、地形、そして BSP を持っていません。OGRE の開発が始まった頃、そのようなエンジンは常識では考えられませんでした。「エンジン」とは FPS を速やかに実現するために多くのフィーチャーを実装していなければならないモノだったからです。しかし、他のいくつかのエンジンは、多くの達成課題や多くの論争を解決することができずに、開発が止まり始めました。その間にも OGRE はその進捗を維持しました。

たとえば、あるエンジンにおいて、あなたが BSP の処理に納得がいかなかったとしても、ソースコードをいじらない限り組み込みの BSP 処理を変更することはできません。 OGRE はそのようなケースに対して異なる道を示しています。「換装」は「唯一無二の標準」を否定します。 OGRE において、あなたは異なる BSP を開発することが可能です。同じことが XCube でも言えるのです。この特徴は Wii 的であると呼ぶこともあります。
|