sunday-lab 日本語版

汎用レンダーシーケンス (2)

2008-07-05T17:39:00.002+09:00

ここで XOOPS Cube コアのレンダリングについてもう一度みてみましょう。 XOOPS Cube コアでは、「CMSがテーマのフォーマットをデザイナーに強制しない」という前提条件で作られています。フォーマットを新作するためにはプログラムが必要ですが、交換できないよりずっとマシです。

XOOPS Cube コアは「描画機構:レンダーシステム」と「描画対象のバッファ:レンダーターゲット」を抽象化して扱っています。レンダーシステムとレンダーターゲットはメインシーケンスの統括的コントロールとは無関係に、独自に使用できる必要があります。

一方、レンダーオペレーションは、「レンダーシステムとレンダーターゲットをどう使うか」という、汎用レンダーシーケンス専用の指令データです。コアの汎用レンダーシーケンスがレンダーシステムとレンダーターゲットを自動的に使用するため、プログラム側でこれらの要素に直接アクセスする必要はなくなります。

ただしアクセスを禁じるわけではありません。汎用レンダーシーケンスは、上位の「シーケンス」の仕組みであり、レンダーシステムとレンダーターゲットは、下位の「レンダリング」の仕組みです。どちらも利用可能です。

XOOPS Cube Developers Group Japan のメーリングリストで onokazu さんが鋭く指摘したのは、「レンダーオペレーションと同主旨のメンバをレンダーターゲットが持っている」という点です。

対 Legacy 用の XOOPS Cube 0.9 にはレンダーオペレーションという仕組みはなく、レンダーターゲットがその役割を兼ねていました。

Legacy で重視したかったことに、アトリビュート（テンプレート変数）のリセットがあります。 XOOPS2 には先に登録されたテンプレート変数を、後のレンダリングが参照するというテクニックがありました。しかし、 Legacy は XOOPS Cube コアの交換式レンダーシステムに対応しているため、レンダーシステムＡで使われた変数にレンダーシステムＢがアクセスできないという問題(?)があります。 Legacy では同じレンダーシステムでも原則変数は引き継がないという仕様で操作感の統一を図りました。

もしこれが３Ｄプログラミングなら、そのような利用（パラメータの預けっぱなしを活かすことも、それでつまずくことも）はプログラマの責任です。しかし、私達は、XOOPS2 の経験を持つプログラマに対して、レンダリングが他のレンダリングのテンプレート変数にアクセスできないことを明示する必要があると考えました。そこで Legacy はレンダリング後にテンプレート変数を消去する仕様を持つに至りました。

この仕様の実装にあたり、Legacyでは、レンダーシステムを直接制御するのではなく、レンダーターゲットにリクエストを入れて送るという方式を取っています。レンダーシステムのアクセスは Legacy 側で行うことがほとんどでした。言い換えれば、「Legacy は非汎用のレンダーシーケンスを持っている」です。このとき、ターゲットが Legacy 非汎用レンダーシーケンスに対するレンダーオペレーションの一種として機能していたわけです。

Cube コア 1.0 では、レンダーオペレーションの導入とともに、この部分を正しく分離して仕上げる必要があるでしょう。結果として、システム、ターゲット、オペレーションでかなり明瞭なクラス分けができると思います。

汎用レンダーシーケンス (1)

2008-07-01T00:56:00.008+09:00

XOOPS Cube 1.0 コアには、汎用レンダー（描画）シーケンスが用意されており、1.0 の主要な検証項目の一つになっています。

私達は既に非汎用なレンダーシーケンスを知っています。 Legacy のレンダーシーケンスがそうです。 Legacy のレンダリングプロセスは XOOPS2 と同じステップを持たなければならず、以下のようになっています。

(1) モジュールの実行前に、ブロックを描画する
(2) モジュールの実行後、モジュールを描画する
(3) モジュールの描画後、最終出力としてテーマを描画する

このようなレンダリングの手順を汎用的にしたものが、 XOOPS Cube コア 1.0 の汎用レンダーシーケンスです。

XOOPS Cube コア 1.0 のレンダーシーケンスは、すべてのビジネスロジックの後に実行されます。そして BASE が交換可能というコアのフィーチャーに対応するために、コアはブロックやモジュールなどの特定のコンテンツ単位を認識しないようになっています。

レンダーシーケンスにとって、テーマ、モジュール、ブロックといった単位は必要ではありません。重要なことは、レンダリングの順序と、後ろのレンダリングプロセスが前のレンダリング結果（もしくは他のレンダーターゲット）にアクセスできることです。たとえばテーマは、ブロックやモジュールの描画結果を合成しなければいけません。

Legacy の非汎用的なレンダーシーケンスでは、最後にテーマを描画するために、最後にロジックが実行されていました。しかし、汎用レンダーシーケンスでは、一番最初に CMS のタスクがテーマのレンダリングを行うリクエストを出しても、実際のレンダリングは最後行うことが可能になっています。

つまりビジネスロジックの実行順と、描画の実行順を変えることができるのです。

メカニズムをチェックしてみましょう。例のPDFドキュメントも一緒に読んでみてください。

汎用レンダーシーケンスは、同じく汎用のメインシーケンスであるタスクシステムと同時に使うことを前提としています。これは非汎用のメインシーケンスは、 Legacy のような非汎用のレンダーシーケンスを持っているからです。

XCube_Root のメインシーケンスは、各タスクからレンダーオペレーションを収集します。レンダーオペレーションには、使用するレンダーシステムの名前や、描画の順序を示すシーケンス ID が収められています。

レンダーオペレーションは順不同（out-order）に収集されます。たいていの場合、最初のタスクは CMS のタスクであり、テーマの描画リクエストがオーダーされる可能性があります。

そのまま何もしなければ、いくつかのモジュールやブロックは、テーマの描画の後に描画が行われることになります。そのような順序は奇妙です。

そこで、 XOOPS Cube コアは、正しい順序（in-order）で描画シーケンスが行えるように、収集したレンダーオペレーションをソートしています。

ソートによって、正しい順序になりました。ソート後のこの状態は、一種のコマンドキューになっています。コアの汎用レンダーシーケンスは、先頭からひとつずつオペレーションを取り出して描画を行います。汎用レンダーシーケンスを使用する場合は、レンダーシステムとレンダーターゲットの取り扱いはコアに任せることができます。

最後のテーマを描画し終えると、画面が完成していることになります。その様子は、 XCube_PHP4 minahito_sandbox ブランチのサンプルでチェックすることができます。

なお、このエントリは Diff between XC and XCL(X2): Render Sequence の別バージョンになります。 XOOPS2 のレンダリングとの違いについて知りたいなら、 Diff between XC and XCL(X2): Render Sequence も読んでみてください。

2.1.5 RC のダウンロードが未だにゼロな件について

2008-06-25T06:54:00.005+09:00

こ、これは (^^;;

まぁ週末が本番ですよね。
それともカウンタが止まってるのか？

XOOPS Cube Legacy 2.1.5 RC release

2008-06-22T21:17:00.002+09:00

以下はxoopscube.orgに投稿されたニュースの翻訳案ですので、事実に反さない限り自由にコピーしたり翻訳の叩き台にしてもらってＯＫです！

---
リリースが遅れてすみません。

XCL 2.1.5 RC はテストのために利用可能です。 2.1.5 は 2.1.4 からのマイナーアップグレードバージョンであり、おそらくまず間違いなく 2.1.x 系の最後のリリースになります。このバージョンはひとつの重要なバグの修正、いくつかのバグフィックス、パッチを含みます。もしあなたが XCL を利用しているウェブマスターで、有志活動のために少し時間があるならば、 XCL 2.1.5 RC があなたにトラブルをもたらさないかどうかチェックをお願いします。

２週間後にプロジェクトは安定版をリリースする予定です。さあテストしましょう！

2.1.4 から 2.1.5 RC へのアップグレード
現況を破壊しないように、 mainfile.php 、そして、 /install ディレクトリをパッケージから取り除いてください。次に、パッケージのファイルをあなたのファイルにアップロードしてください。最後に、コントロールパネルの「モジュール管理」で赤いアイコンを表示するモジュールにアップデートをかけてください。アップグレードを隠すためにサイトクローズをかけておくとよいでしょう。

スタッフ

fugafuga
GIJOE
gusagi
kilica
marijuana
MAT
mikhail
minahito
nbuy (aka nobu)
nobunobu
okuhiki
tohokuaiki
Tom_G3x

xoopscube.jp will renewal

2008-06-21T02:00:00.012+09:00

「せめて既存のマニュアルへのリンクくらい貼ってぇ〜」
とお願いすること数ヶ月、 xoopscube.jp のリニューアルが決まりました。

うさでき、ひよこむ、 XUGJ へのマニュアルへのリンクがあるのかどうか分かりませんが、どうも独自っぽいです。いやもうユーザーがダウンロードから先のシーケンスに進めるならどうでもいいです！
XOOPS Cube プロジェクトへのリンクはある模様。なんらかの形で souceforge.net Wiki へのリンクもあると思われます。これでチーム体制やコントリビュート等の運営モデルへのドキュメントへの道も開かれることになりそうです。

ご存知の通り xoopscube.jp は一度コアチームの投票で閉鎖を決定して、フォーク後の方針に従ってユーザーコミュニティグループへの委譲を進めてきました。その流れの中で大本命と見なされていたのが「日本XOOPSユーザーズグループ」と「ひよこむ」でした。

しかし結果として閉鎖は覆され、 cube.jp はユーザーコミュニティグループのひとつとして維持され、 onokazu さんと tadashi さんが管理に残りました。その後の展開はご覧の通りです…… orz　いや、管理でみんな死んでたときに特に tadashi さんがハッスルしていた印象が無かったので、残ってどうするんだろうとは思っていたんですが……それ以上に当時は土壇場の転覆劇にむちゃくちゃ頭にきてたので、あまり考えてませんでしたが……

（当時の投票意思決定の仕組みでは特に閉鎖に反対はなかったので、いざ閉鎖実行段階で引っくり返されたときはさすがにドタマにきた）

以前から tadashi さんと xoopscube.jp に行き着くユーザーさんのためにも、リンクを充実させてはどうかという話をしてきました。しかし、オフラインで話をすると、快諾を貰うのですが、オンラインで話を確認すると、ポリシーを持ち出して見事に突っぱねられるのです。だったら最初からそう言ってよ！ (ToT)

既存のドキュメントへのリンクを充実させる事が XOOPS Cube ユーザーのためにならない、という tadashi さんの（オン限定）論調が理解不可能で、オフィシャルウェブページを立ち上げないとまずい、という結論に至ったのですが、結果として onokazu さんがリニューアルを実行に移してくれました。

これはかなり革新的な出来事だと思います。こんな日が来るとは……ありがとうございます！

噂レベルだった管理体制の強化も実行に移されるようです。お流れになったもんだと思っていましたが、ここは tadashi さんが地道に進めてくださったようです。m(__)m

ちなみに tadashi さんはオフラインではものすごい人です。

I'll move

2008-06-20T02:22:00.005+09:00

活動時間確保のために、引っ越します。
いま住んでいるところは長く住んでいて気に入っていて（市内で引っ越ししたこともある）、家賃も安くて、のどかで良いところですが、先週今週で心が折れました。 orz
なにがあったかはまた書きますが、 ToDo を紙に書き出してたら…… (ToT)

すでに家捜しに入っていますので、来月以降、物件が決まり次第引っ越して、生活サイクルを一新したいと思います。
でも今日は寝ます (^^;

なんでフリーウェア活動のために引っ越すんだ、そんなOSS思想家だったか俺はと、心の片隅でホントはちょっと思ってますが、
掛け持ちのプロジェクトも完全にリタイアしており、このまま何もできずに終わったら男が下がります。もう最安値ですけど。
暴走で引っ越します。(-_-;

ただ、暴走は結構ですが、プロジェクト運営モデルの認知度の低さや、 Doxygen 日本語ドキュメント計画のように完全無反応のトピックなどを考えるに、「言い出しっぺの法則」を貫く根性と同時に、諦めずに周知徹底を図っていくマメさなどを客観的に振り返る必要はあると思います。
なにげに tadashi さん級と言われる破滅的な日本語でまったく周囲とコミュニケーションが成立していない点も自分で自分のクビを締めています。 orz

なんか、あーせい、こーせい（こうしたほうがいい）というのがあったら、教えてください。

ということでとりあえず今夜はねます。明日も仕事ですし……

じゃあの。

A first draft of the official web site

2008-06-02T00:46:00.002+09:00

予告していました日本語版の XOOPS Cube オフィシャルウェブサイト草案バージョン１、コードネーム「これはひどい」をアップしておきました。 orz

肝心のインストールガイダンスなのですが、XOOPS Cube Legacyひとつを取り上げて説明を書くと、

Legacy はプロジェクトにおけるBASEのひとつでしかないという前提が崩れるイメージにならざるをえない
ダウンロードでホダ塾ディストリを入れる予定だったが、インストールはたぶん Wiki でなければフォローできない

というジレンマがあって、あれこれ考える前にまずは草案をあげてみようと思ったところ、他にも問題がぼろぼろと……

やはり開発モデルやチームモデルの説明のページを作ったほうがいいかなぁ……
あとディスカッションボードに書いてますが、開発のページは www.ogre3d.org の構成を拝借するより、 Wiki の GET INVOLVED などをコピーしたほうが適切ですね。

ということでディスカッションボードでの議論と Wiki の改変お待ちしております。

How to forward the official web site (beta)?

2008-05-29T23:54:00.001+09:00

オリジナルはこちらです。
原文の英語力のなさ（←言い回しなんかできん）と機械翻訳の精度があらぬことになっている気がしますが、今日も残業で時間ないし結果を恐れずガンガンいきますぜぃ！
（が、本当に必要なエントリ以外は時間取れるまで翻訳更新控えます）

なぜオフィシャルウェブサイトはベータなのですか？
なぜなら、今回は動的なウェブサイトを使わないからです。つまり、私達は、サーバ上で CMS を使いません。サーバ上の CMS の代りに、静的な CMS である RapidWeaver を使う予定です。Sourceforge.net ウェブサーバは、 XCL を動かすのに十分な軽さではありません。私は、オフィシャルウェブサイトのために XOOPS Cube の別の BASE を使うことを計画しています。しかし、その BASE は、未だ開発中です。従って、私達は、少なくとも 3 ヶ月くらい RapidWeaver を使うでしょう。更に、私達は、他の CMS を研究する必要がありますので、 RapidWeaver をよく使うことは有益です。

どうやって進めますか？
私は、公式のウェブサイトの草稿を日本語の sf.net Wiki の専用ページへ６月１日に投稿するでしょう。最初の草稿が日本語で書かれる理由は、私達は日本のトップページランクであり、そして、ユーザーのために十分な情報を準備できる状況ではない xoopscube.jp の代替として、不可欠の情報の準備をしなければならないからです。

最初の草稿が私の貧弱なドキュメントから第二段階の草稿に修正されるので、２週間は日本語から他の言語にページを翻訳しないでください。最初の草稿を翻訳するために時間を使う必要はありません。更に、日本版には、日本のウェブサイトとのリンクがあります。そのため、英語と日本語の両方を得意とするコントリビュータが第二段階の草稿を英語に翻訳してくれる予定になっています。それから、英語版を共に改良しましょう。

英語版と日本語版が少しの差異を持っていることは構いません。私のお粗末な英語は、ダメージをコミュニティに与えました。しかし、英語と、日本語の両方を得意とするコントリビュータは、バランスをとるでしょう。いずれにせよ、プロジェクトがアクティブメンバーとコントリビュータに満たされている現在、私達は古い方法と異なる新しい方法をとることができます。

オフィシャルウェブサイトはフォーラムを持ちますか？
いいえ。私達のフォーラムは既にプロジェクトページに存在します。そして、各言語版は、エンドユーザーに xoopscube.org のようなローカルコミュニティへのリンクを提供します。プロジェクトの役割がソフトウェア開発であるので、私達は、ウェブサイトを小さい状態に保つでしょう。しかし、次のウェブサイトは、静的な１枚のウェブページでありリンクしか持たない現在のページより、はるかにまともです。

どういうウェブサイトをゴールとして思い浮かべればいいですか？
それは、フォーラムを持たない www.ogre3d.org と若干の bleder.org です。ご存じのように、 XOOPS Cube は、基礎的アーキテクチャ、及び、プロジェクトモデルのために OGRE3D を参考にしてきました。私達のプロジェクトは、アナーキー方針であり、 OGRE3D とは異なります。しかし、それぞれのオフィシャルウェブサイトで提供するべきである情報は、同等です。

英語版は日本語版にフィードバックされますか？
はい、もちろんです。２つの版は、表現に関して多少の違いを持っていても構いませんが、それらの基礎的なものは、同等でなければなりません。

草稿の内容をどこで議論すればよいですか？
Sourceforge.net wiki は、コメント機能を私達に提供します。その機能は、良いディスカッションボードです。英語の草稿ページが作られた後で、我々は、コメント機能でそれについて論じることができる状態になるでしょう。

（追記）sf.net wiki のディスカッションボードはそのページの言語と英語を使ってOKです。日本語のページでは日本語を使ってガンガン意見交換してください。

英語から他の言語に翻訳してもいいですか？
はい。それは、自由です。私達のウェブサイトは、 GFDL 、もしくは、他のフリーライセンスの下にあるでしょう。従って、あなたは、あなたが望む場所 --- xoopscube.sourceforge.net か各ローカルコミュニティ --- へそれを翻訳できます。

しかし、ソフトウェア翻訳サービスによって翻訳元を読むことは、悪いアイデアです。英語版のみから翻訳してください。恐らく、英語版は、確実でしょう。他の言語版が言語圏内の各国や法律のために、特別な表現やリンクを保持しなければならないため、そのようなページは、翻訳ベースとして良くありません。

私達は、日本版からスタートしますが、最終的には、日本版は、日本独特の情況のために良い翻訳元にならないでしょう。

日本版追記:「公式」ですか、「オフィシャル」ですか？
「公式」と名のつくものに政府・地方自治体などの公的機関と同質の存在を求めたユーザーがいた（←マジ）過去のことを考えれば、オフィシャルサイトと書いたほうが無難かなと考えているヘタレです。しかし、公式はどこか？と尋ねられたり、全角２文字で表現したかったり、口頭で舌がもつれそうになった場合は公式と呼んでもらって構いません。

The Report of XOOPS Cube study session #1

2008-05-25T20:28:00.003+09:00

halt 氏（日本において最もポピュラーな PHP プログラマのうちの 1 人であり、クールガイ）は、 XOOPS Cube の概要を知ることを望む初心者のために第一回 XOOPS Cube 勉強会を主催しました。私と龍司さんは、彼のセッションを手伝うために、このイベントに行き、そして、初心者にとってのプロジェクトの問題点を知りました。

多くの日本のユーザーは、 xoopscube.jp が XOOPS Cube の公式サイトであると認識しています。
彼らは、 xoopscube.sourceforge.net 、 XUGJ 、及び、他のサイトを知りません。Google の検索結果でトップに来るものが、彼らにとっての公式サイトです。
入門書が不足しています。そのためユーザーはすべてをネットで調べるしかありませんが、彼らは xopscube.jp しか知らないのです。
彼らは、「うさぎにもできる XOOPS Cube 入門」や XUGJ のように、十分な情報を持ち、そしてサポートフォーラムをもつ他のサイトをまったく知りませんでした。 xoopscube.jp はどのようにインストールし、 XOOPS Cube を活用するかという情報がありません。ユーザーは道に迷います。
インストールウィザードは長いシーケンスであり、サーバー操作に関する高いスキルを要求します。私たちは doc ディレクトリ下のインストールマニュアルが読みやすいかどうか見直す必要があります。
初心者は、インストールマニュアルの存在を知らないかもしれません。私たちは、どのようにインストールするかのガイダンスの準備をするべきです。しかし、当面の入り口となる xoopscube.jp は、そのようなユーザーに有益なドキュメントを持ちたがらないでしょう。うーん。
初心者は、プロジェクトのスタンスや開発体制を知りません。私は、それらを直接ユーザーに説明する必要がありました。Sf.net Wiki は、それらに関するページを持っています。しかし、ユーザーには、そのページに到達する方法がないのです。

勉強会は、非常に重要な情報を私たちにくれました。私は、第二回の勉強会が開催されることを祈ります。

I'm weary

2008-05-24T01:44:00.006+09:00

ものすごく疲れた……なんだったんだ今週は……

ということで土曜日ですが、 halt さんの勉強会の手伝いにいってきて、そのあと別のグループと飲みにいく予定です。
日曜日は何も無いので、なんとか日曜日中に公式の素案を作り上げて最低でも sf.net の管理 ML に投げておきたい……
なにしろ API リファレンスの日本語版とかの作業もありますしね……

ところで、僕には疲れたときの大きな味方があります。
その味方が最新コンソールで復活するかもしれないという噂が！？

スウェーデン発『シェンムー』がWiiに移植される！かもしれない噂…

シェンムーは本当にいいゲームです、未だにドリームキャスト現役ですもん。
疲れたときはシェンムーIIを起動して香港に行って、怪しい店の売り子をやって楽しんでます。すごく気持ちがリフレッシュできます。
IIのショックは凄かったですね、前作のセーブデータを引き継いで所持金を香港ドルに換金する機能があるのに、ゲーム始めて１０分でかっぱらいに遭って有り金全部なくなるんですもん。あれには驚きました。
その状態で保存して、いつでもロードできるようにして、疲れたら香港に飛んでます。

シェンムーIもいいですけど、疲れたときはシェンムーIIですね。
アナログスティックで視点を変えて、ボタンを押して「お客さん遊んでいきませんか？」と声かけするのが楽しい。

これとファイナルファンタジーXIIは、世界を歩くだけで楽しいし、癒されます。
今日みたいにカープが勝つと最初から疲れも無いんですけどね (^^;

移植されれば嬉しいなぁ
でも描画系全替えでしょ？
Wiiに移植なんて半端じゃないと思いますが……

本当なら嬉しいです。そしてはやくシェンムーIIIを！（無理）

The Official Web Page

2008-05-23T07:51:00.002+09:00

xoopscube.jp は閉鎖する予定のサイトでしたが、現在、２人の管理者と数人の非常勤モデレータによって維持されています。そのためサイトの維持はタフな仕事になっており、ユーザーが XOOPS Cube を使うために必要な情報がない状態が続いています。

日本において、 xoopscube.jp は、 XOOPS Cube に関するトップページランクです。Google は、 XOOPS Cube を xoopscube.jp に使うことを望む初心者を導きます。しかし、彼らは、どのように xoopscube.jp で使用すればよいのか知ることができません

XOOPS Cube には、コミュニティサイトへのリンクがあり、そして、ユーザーをそれらのサイトに誘導します。それによって、 XOOPS Cube は、コミュニティ管理を持つことはなく、そして、コンパクトなプロジェクトを保っています。しかし、 xoopscube.jp は、ユーザーのために十分なコミュニティ機能を準備することができません。

十分なドキュメント、フレッシュなニュース、そして、充実したフォーラムを実現するために xoopscube.jp が（管理で精一杯であり）行動に出ることができない、という現状はプロジェクトの想定外です。 xoopscube.jp の現在の状態は、 xoopscube.jp がトップページランクのサイトであるがゆえに、プロジェクトとユーザーの両方に悪影響を与えます。私は xoopscube.jp が他サイトの既存ドキュメントにリンクを持てばよいのではないかと考えましたが、 xoopscube.jp には彼らのポリシーもあります。私は xoopscube.sourceforge.net のリニューアルが彼らを助けると願うばかりです。

プロジェクトの情熱と、xoopscube.jpの情熱が異なることは不幸かもしれません。しかし、そもそも１０人の管理者でも進展しえなかったものを２人の管理者で進めることは不可能な話です。プロジェクトは何も強制しませんし、彼らは彼らの望むことのみをすることができます。さらに、ユーザーが Google の検索結果から十分な情報を得られないことは、プロジェクトの宿題です。

そこで、私は、当面の間 XOOPS Cube コアの開発を停止することにしました。いずれにせよ、開発のための十分な自由時間をキープできない状況です。その代わりに、 xoopscube.sourceforge.net の公式ウェブページのリニューアル準備に集中するつもりです。プロジェクトは現在アクティブな開発者で満たされています。従ってこのことは 2.1.5 か 2.2.0 ブランチに全く悪影響を与えません。

詳細はプロジェクトのフォーラムをご覧ください。私たちのプロジェクトをコンパクトに保つために、 xoopscube.sourceforge.net は大量のコンテンツを持つことはしません。しかし xoopscube.sourceforge.net と sf.net Wiki をあわせてファーストステップに十分な情報を提供するつもりです。

xoopscube.jp のようなローカルコミュニティは他にもあります。これらのコミュニティは、有志の数が十分ではありません。従って、それらは、十分な情報の準備をし得ません。プロジェクトは、プロジェクトのタスクをこれらのコミュニティに強要したかもしれません。公式のウェブサイトのリニューアルは、コミュニティを助けるでしょう。

Revival of Free Software (4)

2008-05-22T07:55:00.001+09:00

最後に、私が常に XOOPS と XOOPS Cube からフリーソフトウェア精神を感じる理由を書きます。 XOOPS Cube が xoops.org からフォークしたとき、私達は、 XOOPS におけるフリーソフトウェア活動を復興させることを第一の目的としました。それは、フリーソフトウェアの復興であり、フリーソフトウェアの面白さの復興です。

なぜ？　その理由は、 XOOPS が純粋なフリーソフトウェアであったことです。XOOPS 財団は、それを粉砕し、スターリンが好きそうな恐怖の中央集権体制を作り、そして、XOOPS を好きな人のユーザーアカウントを（彼らの愛の形が財団の愛の形と一致しないという理由で）をアカバンします。しかし、 XOOPS が純粋なフリーソフトウェアであったことを忘れてはいけません。

onokazu さんが MyPhpNuke や XOOPS1 の開発に挑戦していたころ、ほとんどの人々はフリーソフトウェアのウェブアプリケーションが「利益の種」になるとは考えていませんでした。彼はあくまで彼の職業のためにプログラムを書く方法を学ぼうと MyPhpNuke と XOOPS を書きました。彼は技術翻訳の職業に就いており、技術要素をよりよく翻訳できるようになることを望んでいました。彼の職業に対する努力が XOOPS を生み出しました。

それは確かにフリーソフトウェアの行動です。

XOOPS は、純粋なフリーソフトウェア活動のうちの 1 つでした。その後、一部の人々はオープンソースウェブアプリケーションが利益をもたらすことに注目し始め、多くの新しい CMS が生まれました。そして、 XOOPS は XOOPS 財団によって傷つきました。現在、 XOOPS は、他の CMS としばしば比較されます。しかし、 XOOPS は、誰もビジネスとタイアップできると考えなかった創世期の CMS のうちの 1 つです。私は、 onokazu さんの偉業に尊敬の念を抱いています。

そして、私達のプロジェクトは、 XOOPS がかつて持っていたフリーソフトウェアの精神の復興です。XOOPS Cube は、スクラッチから書き起こされましたが、財団によって粉砕された XOOPS の精神を確かに引き継いでいます。

Revival of Free Software (3)

2008-05-21T07:52:00.001+09:00

前回のエントリに書いたように、この世のオープンソースプロジェクト全てが情報産業やウェブに関わるわけではありません。日本には、フリーソフトウェアとビジネスの間の関係について一般論を語ることを好む人がいます。しかし、彼らはそのようなプロジェクトを見向きもしません。恐らく、彼らは、そのようなプロジェクトが地球上に存在することを知りません。

各々の開発者は、各々の動機を持っています。誰にも特定のものとして定義できません。一部のジャンルにおける一部のオープンソースプロジェクトが何かを開発者に与えることは確かです。しかし、それは、開発者に対する唯一無二の動機ではありません。この世には次のようなプロジェクトもあるのです:

社会貢献性皆無
金が出ていくことはあっても金が入ることなんてありえない
キャリアプランにもライフプランにも一切影響しない

しかしながら、そのようなプロジェクトに加わる開発者はいます。あなたが心理学者でないならば、そのような開発者の心理を読み解いて解説する必要はどこにもありません。フリーソフトウェアプロジェクトに参加する開発者の動機を定義することは誰にもできません。動機もまた Free なのです。

一部の人々は私に私が XOOPS からどのような利益を得ているのか尋ねてきました。また XOOPS コミュニティのメンバーでさえ、得をすることがあるから XOOPS に関わっているのだろうと尋ねてきました。彼らは私を通じて自分自身を見ていたのだと思います。私の動機が利益だと彼らが感じた理由は、彼らの動機が利益だからです。

開発者は、損することがなければ、得がなくても行動します。

従って、 XOOPS Cube が IT/Web 産業だからといって、 XOOPS Cube の陰謀を邪推するのは無駄な時間です。あなたも私達もそんなことを考えるエネルギーがあるなら別の行動に使うべきです。

LinuxWorld Expo/Tokyo 2008

2008-05-20T23:50:00.002+09:00

LinuxWorld Expo/Tokyo 2008 という展示会が開催されます。このイベントでは最近、 .org パビリオンというコーナーが用意されることが恒例になっており、オープンソースコミュニティが出展できるようになっています。しかし開催日は……平日だっ！ orz

平日でも、ある程度のコミュニティなら何とか出展にあたるメンバーを集められるかも知れません。 XOOPS Cube では毎年 tadashi さんや龍司さんが出展してくださっています。ありがとうございます。 m(__)m

ということでセッションの紹介です（↓）

■5月29日　11:00「XOOPS Cube のイントラ応用事例」
講演者：株式会社RYUS 天野龍司

■5月30日 14:00「NetCommons XOOPS Cube 連携」
講演者：有限会社磯谷商店　長尾正

話によると、この展覧会は当日に行くと入場料が５０００円！！なのですが、事前に Web で予約しておけば無料になるそうです。ぜひ予約してから出かけましょう。

しかし、LinuxWorld というイベントに .org パビリオンというブースコーナーが設けられるのは非常にありがたいことですが、常識的に考えれば、一般的なオープンソース開発者が平日のイベントに出席することはなかなか難しいと言わざるを得ません。このあたり、感謝しつつも複雑な心境です。よくよく考えればこういう平日イベントにはビジネスユースのユーザーが集まりますので、僕ら開発者が行ってもできることは特にないんですが (^^;

そんな感じで、フリーソフトウェアの開発者はまだまだホリデープログラマが圧倒的に多いと思います。これに関して、平日のオープンソース関連のイベントに開発者が集まりにくいのは、開発者の勤務先の会社に問題があるからだとか、開発者の姿勢に問題があるからだ、という声をたまに聞くことがあります。開発者に理解のない会社がおかしいとか、ちゃんと休みを主張しない開発者の姿勢がよくないとか、そういう主旨の話だと思います。

しかし、開発者はおそらく仕事が忙しいから行けないわけではないと思います。個人的には、仕事が楽しいので、仕事とオープンソースのイベントを天秤にかけられないという人がほとんどじゃないかと思うんです。これまでＯＳＣとかでいろんな人と話した実感として。

休みなんて手続きすれば取れますけど、自分の中で仕事を休んでまで出かける動機が見つけられるかどうかです。会社に悪いとか、気が引けるとかではなくて。これは以前ＯＳＣなどで他の開発者とお話した時も同じようなことをおっしゃっていました。

「オープンソースに参加する人は会社の仕事に不満があるのだ」と一方的に決めつけて話しかけてくる人とか実は結構いて、たまにイベントなどで不愉快な思いをすることがあります。しかし、会社の不満をフリーソフトウェアにぶつけるタイプの人って本当にそんなにいるんでしょうか？　１２年やってますけど一人も見たことありません。

たとえば、社会や会社の不満をアルコールにぶつける人もいるにはいるでしょう。しかし、ほとんどの人は人生を豊かにするためにアルコールをおいしく楽しく飲んでいると思います。また、日々が充実していればいるほど、ビールもまたいっそうおいしくなりますよね。オープンソースというか、フリーソフトウェア活動って結構ネアカというかポジティブなものだと思うんすよね。だから、逆に平日との折り合いがつけづらい、ということなんじゃないかと思います。

まぁ確かにフリーソフトウェアの開発者って自分の仕事に対してツンデレな人が少なくない気がするので、誤解を招きやすいかもしれませんが……

そう考えると二日開催はきついとはいえ、平日と休日の両方で開催するＯＳＣはオープンソースプロジェクトにとってはありがたいですよね。

ということで行ける人は LinuxWorld Expo に行っちゃいましょう！

Shine has been banned

2008-05-19T07:28:00.005+09:00

少し前の話題ですが、 xoops.org と xoops.nl で７年間にわたるコミュニティメンバーであり、精力的な活動者だった Shine 氏が "プロジェクトの利用規約に同意しない発言がみられた" という理由で xoops.org からアカバンされました。発端はこれ。リンク集モジュールを探しているユーザーに Wflinks を薦めたのが運の尽きでした。すでに地獄のモデレーター Mamba 氏によって原文は編集されてしまい真実は闇の中ですが、どうやら Wflinks を薦めた際に親切に書き込んだ機能リストに XOOPS よりフォークした ImpressCMS という文字が含まれており（wflinksの最新版が ImpressCMS でしか稼働チェックされていなかった）、 Mamba 氏がこれを削除。投稿を編集されたことに怒った Shine 氏でしたが（当然）、 XOOPS を取り扱うサイトで ImpressCMS という単語を持ち出したうえに反省がみられないということで利用規約に反したことになり、アカウント無効・IP指定によるアクセス禁止処分となりました。

旧日本帝国も真っ青な利用規約の拡大解釈と適用っぷり。相変わらずすぐにアカウントを削除するサイト運営に「xoops.org のポリシーはおかしい」というトピックがあがったのですが、「特定の個人を攻撃する言葉がたくさん含まれている」ということからロック。

たぶんこの暗い話題でサイト全体のトーンが下がっていたこともあり、onokazuさんのXOOPS評議会？とやらの着任を「ジェダイの帰還」と大々的にアナウンスしたのではないかと思います。

そういえば財団が onokazu さんを追い出して Cube がフォークした際にも Cube という単語は「敵性語」として厳しく監視され、何人かアカバン食らっています。一応、その財団は ImpressCMS に去った、ということになっているのですが、正直違いが分かりません。金集めないだけましなのか。

XOOPS Cube study session #1

2008-05-18T13:09:00.005+09:00

な、なななな、なんと、RYUSのhaltさん主催で第1回XOOPSCube勉強会が開催されるそうです！

以下コピペで恐縮ですが:

2008年5月24日(土) 14:00〜17:00
会場: 株式会社ディノセミナールーム
(〒150-0002 東京都渋谷区渋谷3-13-11 渋谷TKビル9F)
募集人数: 20人

第1回XOOPSCube勉強会は「PHPはよくしらなかったり、あまり得意じゃないけどXoopsを使っていろんな事をしてみたい」という人を対象に、技術的な話よりも「何ができるのか」をXoops中心にして勉強する会です。参加費は無料です。

参加条件:

オープンソースに興味がある
Xoops等のオープンソースアプリを使って社内システムを構築してみたい
社内や部署内で使っているグループウェアや連絡ツールに不満をもっている
趣味プログラマや専業Webプログラマじゃない人
いっちょPHPでもはじめてみるか。の人。

不参加条件（このイベントは初心者向けなので以下の条件にあてはまる人は参加しないでください）:

XOOPSCubeの内部構造がしりたい
別に使う気はないけど技術的な興味で来る人

勉強会の進行概要は下記の通り
1. 挨拶 (5分)
- XOOPSCube勉強会の目的等について自己紹介(一人最大3分程度)

2.[発表]グループウェアにSNS。なんでも無料で作れる時代がやってきた
- 「無料で何ができるのか。無料でどこまでできるのか」を中心にグループウェア/SNS/ブログのような事を無料で実現する方法について紹介します

3.[発表]XOOPSCubeって？オープンソースって？
- 今回の勉強会のタイトルであるXOOPSCubeについて紹介

4.[発表]XOOPSCubeをインストールするには
- XOOPSCubeを利用する為に必要なPHPなどのインストール手順について紹介。

5. 雑談、交流など

……ということです。
参加はこちらから。

あの halt さんが XOOPS Cube （しかもLegacy BASEの）勉強会とは、最初ネタかと思いました。
どんな話が出てくるか、正直怖い(^^;
XOOPS Cube は褒められて伸びる子です！

しかし、もう本当に…… Legacy は動くものとしては使えるんですけど、これを持って技術者の人と話すときは本当に……本当に恥ずかしい！
早く次の BASE を形にしないと……

Revival of Free Software (2)

2008-05-17T23:43:00.001+09:00

日本 IT/Web 産業は、好景気です。私達が子供のころは、みんなプロ野球選手になりたがっていました。しかし、いま、若い人たちはウェブサービスのクリエイターになることを望み、努力を続けています。

この国において、 IT/Web オープンソースソフトウェアは、重要な意味を持っています。それは、開発者のキャリアを変化させ、開発者のチャンスを作り、そして開発者の人生に何かを与えます。

オープンソースの成果物は、ビジネス活動に積極的に使われます（ＩＴ産業では）。一部の人はオープンソースはビジネス活動とセットで語られなければならないと考えています。もちろん、この地球には IT/Web に関するものではない様々なオープンソースがあります。しかし、彼らはそんなものが地球上に存在するとは思っていないでしょう。少なくとも iPod で DOOM を動かすことに挑戦するようなプロジェクトは彼らの視界に入っていません。

いずれにせよ活動が活発なのはよいことです。しかし、 IT/Web OSS がビジネス活動に活発に使われたために、 XOOPS Cube は誤解に苦しまなければなりませんでした。

ご存じのように、 XOOPS Cube は、プリミティブなフリーソフトウェア活動のうちの 1 つです。しかし、人々は、そうは考えてくれません。なぜなら、 XOOPS Cube は、ビジネス活動のために使われることになっている IT/Web OSS だからです。

なぜか、最近の日本では、フリーソフトウェア活動は企業やビジネス活動と直接的にコラボレートするべきだという主張があります。

フリーソフトウェアとビジネスの関係は数十年前に結論が出ています。あなたはそれをフリーソフトウェア財団のウェブページで読むことができます。それについて改めて論じることは悪いことではありませんが、たくさんの人がその再定義に時間を浪費する必要はないでしょう。もし彼らが、そのような議論が OSS の発展のために必要だと考えているならば、ぜひ iPod で DOOM を動かすといったエクセレントなプロジェクトを含め OSS 全般に目を向けてもらいたいものです。結局のところ彼らは特定のものを発展させたいだけで、「OSS の発展」という言葉はオブラートとして使っているだけにすぎません。

XOOPS Cube プロジェクトは、だれからでもコントリビューションを受け取りますが、企業と直接的コラボレートは行いません。コラボレーションはフリーソフトウェアプロジェクトの義務ではありません。結果的にこの明瞭かつ昔ながらの方針が、フリーソフトウェアとビジネス活動とのバランスを自動的にとるでしょう。

Revival of Free Software (1)

2008-05-16T23:24:00.000+09:00

日本において、オープンソースはビジネスとともによく論じられます。それは、悪いことではありません。かつて、まだインターネットや「オープンソース」といった言葉が存在しなかったころ、私達は貧弱なモデムで草の根ネットに接続し、フリーソフトウェア活動に参加しました。当時、技術に興味がない人は私達の活動をまったく見向きもしていませんでした。「オープンソース」という言葉が作られてから、全ては変わりました。現在、非常にたくさんの人々がフリーソフトウェアに興味を持つようになり、そして、フリーソフトウェアで何かできないかと考えています。

フリーソフトウェアを通じてビジネス活動をすることは可能です。なぜなら、フリーソフトウェアは、自由なソフトウェアだからです。しかし、フリーソフトウェア活動自体は、ビジネス活動そのものではありません。XOOPS Cube は、プリミティブなフリーソフトウェア活動のうちの１つです。ですから、私は XOOPS Cube がビジネス活動に有益であることを願っていますが、ビジネス活動には一切タッチしたくありません。私達のプロジェクトがするべき唯一のことは、完全なる自由を維持することです。

XOOPS Cube は、パブリック・ドメインにあります。従って、だれでも、何かを XOOPS Cube にコントリビュートすることができます。 XOOPS Cube は、コントリビュータが何者であるかに関心はありません。コントリビュータは、学生、もしくは、企業かもしれません。しかし、それは、全く重要ではありません。プロジェクトは、企業とタイアップすることを考える必要はありません。プロジェクトは、あらゆる人からコントリビューションを受け取るスタンスさえ持っていればよいのです。

繰り返します。XOOPS Cube は、プリミティブなフリーソフトウェア活動です。既存のフリーソフトウェア活動が、私達が進むべき道を示しています。

フリーソフトウェア活動としての XOOPS は、XOOPS 財団のクソ野郎共によって傷を負いました。従って、私達はまずフリーソフトウェア活動としての XOOPS を復興させなければなりません。

Argon took a part in MY FAMICASE EXHIBITION

2008-05-15T23:26:00.000+09:00

わたしのファミカセ展とはなんですか？　これは、非常に非常に面白いイベントです。このイベントでは、NESと共に成長したいろいろなクリエイターが架空の NES ゲームタイトルのラベルをデザインしました。以下のビデオの前半は、「わたしのファミカセ展」が何であるかを英語の字幕で説明します。(あなたは私の貧しい英語を読む必要がないので、幸運です！)

実は、XOOPS Cubeコミュニティのメンバーであり、ホダ塾ディストリビューションのデザイナーである argon さんが、この展示に参加しています。彼は、テレビゲーム業界とアニメーション業界のキャリアを持っています。はい、彼の経歴は、私の経歴と類似しています。

彼の作品は、ウィザードリィに似た「NinthRune」です。チェックしてみましょう！

An ideal software design (2)

2008-05-14T23:27:00.000+09:00

大規模システム/アプリケーションの世界では、仕様書が事前に準備される。基本的に、それは、信頼できる。そのため、ソフトウェア設計者は、プログラムやプログラマのためにプログラムを設計することができる。しかし、大規模システム/アプリケーションは、どちらかというとプログラマではなくプログラムに指向する。なぜなら、そのようなシステム/アプリケーションは、長期間使われるからだ。従って、これらのシステム/アプリケーションは、小さな変更に対応するために柔軟で、そして、拡張性を持つべきである。これらの特徴を実装するために、ソフトウェア設計者は、プログラマの立場ではなくプログラムの立場でソフトウェアを設計する。ソフトウェアは合理的なモジュールに分割される。

それは、非常にエクセレントだ。しかし、それは、全ての場合に有効であるか？

大規模システム/アプリケーションは、ソフトウェアのひとつのカテゴリに過ぎない。この世のすべてのプロジェクトが同じシチュエーションであるわけではない。そこには、期間、目的、規模、サイクル、実行形態（リアルタイムかどうか等）、そして、専門性プログラマなどの要素がある。理想的なソフトウェア設計とは、それらの要素への最適解ではないだろうか。（そしてその設計が設計期間中に書かれること）

そのため、だれかが別の状況からその設計を眺める場合、その設計が良くないと感じるかもしれない。

一部の設計者は美しい設計を探求し、それを正義だと考えている。しかし、ソフトウェア設計は、設計者が彼の人生をささげる芸術ではないし、設計者が楽しむためのゲームでもない。しかしながら、大規模システム/アプリケーションを除き良いガイダンスがないのも事実だ。一部の設計者は、それらのガイダンスをクールと感じ、そして、それをプロジェクトに適用しようとする……

厳しい現実は、あなたの設計を（あなたの考える）理想から遠ざけるかもしれない。その一方で、厳しい現実は時折あなたを最適解へつれていくこともある。

OGRE 1.4.8 [Eihort] Released

2008-05-13T12:42:00.003+09:00

OGRE の新しいメンテナンスリリースが出ました。もうリポジトリが追えなくなってどれくらいになるんだろう…… orz

中を見ていないので翻訳も正しいものではないかもしれませんが、一応訳してみました。

---

コードネーム "Eihort" … 1.4.x ブランチ上では九分九厘最後のメンテナンスリリースになるであろうものが現在ダウンロードエリアで利用可能になったことをお知らせします。

ほんの少しのバグフィックスだけが、今回のレポートです。

ソースリリースと大半の SDK パッケージは既に更新されました。ほかのものは各メンテナが提供可能になった際に更新されます。

このリリースの後、私たちは待望のコードネーム"Shoggoth"こと 1.6.x ブランチ上の新しい安定版リリースに集中するつもりです。私たちは昨年のうちに、多くの新しいフィーチャーや改善されたフィーチャーを加えました。そして、相当な数の人々がそれを Subversion から既に使用中ですので、安定版リリースはそう遠い話ではありません。

v1.4.7 からの変更点:

Mac OS X:

古いマシン、特に初代iMacと古いPowerPCマシン上のわずかな GL ドライバが持つバグに対する回避方法
GLSL頂点アトリビュートエイリアシング問題に対する回避方法

Linux

非整合なGLXビジュアルの使用禁止
一部のLinux NVIDIA 169.xドライバーに関するFBO問題のためのワークアラウンド - このフィックスがあなたの手元で機能しない場合は、フォーラムスレッドにより根本的な当面の回避方法があります

Windows:

D3D9RenderSystem::__SetTextureStageState におけるセーフティチェックは７を上回るテクスチャーステージを無視しなければならない。D3D9デバッグモードで大量のテクスチャーを使用した場合のエラーの原因となりえた。
NOMINMAX宣言をWindowEventUtilitiesヘッダに加えた - windows.h をインクルードしていたため他の Ogre ヘッダの std::min/max と競合を起こしていた
GetModuleHandle呼び出しは、より正しくデバッグプラグインに対処するために修正された。

Terrain:

カメラやビューポートより先に地形を作成することを許可した
地形が見つからないときに assert するだけでなく例外を投げるようにした

Maya エクスポータの頂点カラーを修正 - float4 の代わりに Packged RGBA を使うように
Camera::setWindow() 修正
絶対パス指定における FileSystemArchive::exists のバグ修正
MayaExport の OSX ポートフォンマテリアルのサポート
すべての新しいGLSLカスタム頂点アトリビュート（一部のドライバ上で起こるエイリアシング問題を避けて全カスタムアトリビュートを使う必要がある場合にビルトインとリプレスする）をリストするためにマニュアルを更新

An ideal software design (1)

2008-05-12T23:31:00.001+09:00

通常、私達は、チームがプログラムに手をつけ始める前に、ソフトウェア設計を決めようとする。それは、簡単なブロック図であったり、 UML であったりするかもしれない。多くのプログラマが迅速な開発のためにあなたのチームに集まり始める。あなたがしなければならないことは、ソフトウェア設計である。それのために、あなたは、ソフトウェアをモジュールに分割する。それは、プログラムのための分割設計である。

しかし、あなたの任務は、各プログラマがプログラミングの一部を担当可能な状態を作り上げることである。あなたの設計は、それを実現し得るか？

プログラムの機構上妥当な分割設計と、プログラマに仕事を分けるために妥当な分割設計の間には、ちょっとした違いがある。もしあなたが自分でソフトウェアを設計してそのプログラムを書く場合は、恐らくあなたはこの事実に気づかない。

プログラム上の妥当性のために多くのモジュールに分割された理想的なソフトウェア設計は、しばしば、専門性のプログラマの仕事を妨害する。それは、生産的な開発を始めることを不可能にする。

多くのプログラムの専門的な要素がある --- makefile、メモリ管理、リソース管理、入力装置、ハードウェア制御、コンテンツパイプライン、並列処理、シェーダ、エフェクト、パーティクル、アニメーション、グラフィック、オーディオ、立体音響、人工知能、物理学、幾何学、プロシージャル技術、スクリプト、ネットワーク、デバッグシステム、サードパーティミドルウェア等など……。

これらの専門的な要素を系統的に組み合わせることでソフトウェアを設計し得るか？　ひょっとすれば、それは可能である。しかし、プログラムのために設計した理想的なソフトウェア設計は、プロジェクトに集まるプログラマにとっては悪いニュースである。ゲームシステムは、彼らの知識と彼らのコードの合成物を初期から要求する。そのため、プロジェクトは難航することになるだろう。

Is an Object-Oriented Game Engine necessary? (3)

2008-05-11T15:25:00.003+09:00

極限まで抽象化された概念であるところのゲームオブジェクトはおそらくもともとは画面への描画の最小単位として使われることで意義をもっていたのではなかろうか。要するに昔はオブジェクトがそれぞれ単純に自分自身を自分自身に基づいて描画するだけで画面が描画でき、単純明快な一部品として扱えていた。しかし、例えば最近のシャドウマッピングなどのマルチパスレンダリングが主流になってくると、自分自身を描画するときに自身や他のオブジェクトがすでに描かれたテクスチャがあることを前提としなくてはならない場合もある。描画するだけでも他のオブジェクトの描画結果に依存する必要がでてきてしまった。また、テクスチャを参照する必要がなかったり、透明度を無視してもよかったり、描画する内容も複数の描画指示のあいだで全く異なる。スーパークラスのポインタを渡してのんきに描画命令がとどくのを待つだけというわけにはいかない。描画処理の全体の流れの中のどこでなにを描画するか言及する必要がでてきてしまった。

描画処理の側面からみてももはやゲームオブジェクトはすべてが全く同じものだとはみなせない。

[描画でさえももはや構造化できない - 作業記録]

経緯としては指摘の通りなのですが、個人的にはゲームオブジェクト的なものと描画はかなり前の段階から切り離しが始まって、（今風に言うと）緩やかな結びつきで処理することがトレンドになってきているような気がします。それはつまりそれぞれ担当するプログラマが別人になったからとも言えるのですが、ゲーム上の処理は処理、描画系は描画系というノリが主流だと思います。
（といっても会社によって違うので何とも言えない）

昨日、「ゲーム・ビジネスロジック的ななにか」はタイトルに特化するので C++ の"再利用面"における有効活用はないんじゃないか、ということを書きました。しかし、僕は逆に描画系や３Ｄのシーン管理の部分は再利用性を生かして、なんとかミニライブラリに体系的にまとめられないものかと、ここ２〜３年くらい考え続けています。

たとえばシーンや、座標・座標と姿勢を持ち最終的にマトリクスに情報を出せる存在というものは３Ｄゲームなら必ず扱う概念です。ここに再利用性を持ち込む意図は、生産性のための再利用ではなく、フィーリング（あるいはモデルと言い換えてよい）の再利用です。ゲームの開発は「同じものを何度も書くのは馬鹿馬鹿しいからライブラリ化する」ほどスパンが短くありませんし、同じような物をタイトル毎に様子を見ながらコードをブッコ抜いて作る……という行為も高い効果を持つ一面があると思います。また、ハイエンドコンソールとそうでないコンソール、ポータブルマシンでは実装が変わってくることもありますから、どこかで手を動かす必要はあります。

ですから、あくまでフィーリングを揃えるための再利用というわけです。たとえば、 XML の DOM は C と C++ では使い方が全く異なりますが、フィーリングは一緒です。 C++ にも多くの種類の DOM がありますが、使い方が違うだけで根本にあるモデルは同じです。

少し極端な例えですが、そのような形で描画系やシーン管理、あるいはリソースマネジメントにはっきりと再利用のための C++ の活用を実践できないかと考えています。が、それも前述の方が書かれているように……どういう絵作りをするかでまったく手順が変わってくるので、やはりタイトル特化のアーキテクチャは避け難いですよね……これの単純な解法は、存在するんですが、パフォーマンスが……

そういう意味では（負け惜しみだけど）海外勢は似たようなものをよりゴージャスに作り替えていくことで次のタイトルを出す、という市場の形があるから、エンジン部分の再利用を促進できている部分があると思います。

たとえば、日本はＲＰＧでもタイトルごとに文法が違いますよね。ドラゴンクエストIIIを再利用してドラゴンクエストIVは作れそうですが、ファイナルファンタジーXIIを流用してドラゴンクエストVIIIを作るのは難しいでしょう。しかし、海外はＦＰＳといえばこうだ！という形がしっかりできあがっています。ここに一度作った物を広く再利用する市場があるんじゃないかと思います。

海外の方がゲームプログラムの設計が進歩的だから生産性が高いとよく言われますが、個人的には、ユーザーの厳密なジャンル認識の下、割りきりの基準ができつつあるのと、ＦＰＳのように明確な仕様のジャンルが大きな市場で存在しているため、日本よりそういったことがやりやすいからではないか……と考え初めています。

日本だろうと海外だろうと、タイトル or システムに対してその描画系は特化してしまう傾向。そして、抽象度を高めるとパフォーマンスが落ちてハイエンド部門の競争ではキツくなる……といったコンポーネント化へのジレンマは同じものを抱えているのではないかと考えています。

Is an Object-Oriented Game Engine necessary? (2)

2008-05-10T01:11:00.002+09:00

では、理想的なオブジェクト指向言語における理想的なゲームオブジェクト設計とは何だろう？　私は、良いゲームオブジェクト設計は、前時代に完成されたと考える。ビデオゲームプログラミングは、当時からオブジェクト指向設計の要素を実装してきた。

当時のビデオゲームプログラマがオブジェクト指向のプログラミングを実現することを望まなかったことは、重要である。彼らは、生産的な開発とエキサイティングなゲームを追求してきた。そこに我々が学ぶべきである何かがある。

現在、私達は、十分な仕様のオブジェクト指向プログラミング言語を用いることができる。私は、前のエントリで、それが私達のゲームオブジェクト設計を狂わせる原因であると書いた。しかし、当時のビデオゲームプログラマは、 C++ (Cも!) を使えなかった。従って、彼らは、マシン語を用いた。私が最初に加わったプロジェクトは、アセンブリで書かれていた。そのような条件下で、プログラマは、オブジェクト指向の設計を追求することはできない。従って、その設計は、自然とゲームのために良いバランスになる。

見てみよう。私達が使った技術は、タスクシステムである。もちろん、ビデオゲームプログラマは、 C++ と共に今この手法を使っている。しかし、当時のプログラマは、アセンブリでタスクシステムを書いた。従って、現在の手法と当時の手法には違いがある。

タスクシステムは、ポピュラーなビデオゲーム開発方法のうちの 1 つである。それは、データ格納とジャンプアドレス群から成る原始的なメモリブロックである。振る舞いを変更するには、ジャンプアドレスを書き直す。コールバックされたコードは、オフセットアクセスによってメンバーデータにアクセスすることができる。既にポリモーフィズムは実現していた。そこには「型」がない。しかし、それは、 C/C++ のコンパイルされた結果と類似している。現在、私達は、 C++ でこれを書く。C++ は、 vtable という概念を持っている。従って、もっとうまくポリモーフィズムを実現することができる。

一方、私達のプロジェクトは、タスクブロックが他のタスクブロックのジャンプアドレスにアクセスすることを禁じた。つまり、私達は、ゲームオブジェクトの間のメッセージ通信を禁じた。

タスクブロックが他のタスクブロックのジャンプアドレスにアクセスすることは、安全ではない、なぜなら、型がないからだ。C++ は、もう少しうまくそれを扱うことができる。なぜなら、私達は、 C++ でダウンキャストを比較的安全に書くことができるからだ。しかし、それは、同じくデバッグしにくい。私達がそれを禁じた別の理由は、私達はそのような方法からメリットを発見できなかったからである。

子供タスクは、自身のものをコントロールする。しかし、これらのタスクが他のタスクと仕事をする必要がある場合は、子供のマネージャ役である親タスクにまとめて仕事をさせた。私は、この方法が私達への最適解であるかどうかを知らない。しかし、それは、デバッグ、調整、調節に易く、そして、変更のために柔軟であった。

当時、私達の周りには「オブジェクト指向」という言葉がなかったので、私達は、それを追求しなかった。プログラマの自己満足が、ゲームオブジェクト設計の秩序を乱すこともなかった。

Is an Object-Oriented Game Engine necessary? (1)

2008-05-09T23:31:00.002+09:00

なぜわざわざゲームオブジェクトクラスなんてつくって下方へ特殊化するクラスヒエラルキーをつくるんだろう。オブジェクト同士の連絡では、オブジェクトリストを持つ方は信号を伝達するだけで、ダウンキャストなりの特殊化はオブジェクト群のそれぞれの内側で行われるような運用をされる。か、もっと無茶をやる。

(snip)

ゲームルールはゲームオブジェクト同士の交互のやりとりを全体として眺めた状態を完全に規定する。プラグイン系のようなゆるい統合ではやっていけない。完全な記述が求められる。新たな種類のゲームオブジェクトが追加されるとしたら、全ての既存のゲームオブジェクトに対する反応が完全に新たにおこされてなくてはならない。ひとつのピースが残りの全部のピースとの接合部をもっている多次元ジグソーパズルだ。無機的な構造物と比べてここが全く異なっている。

[ゲームオブジェクトを一般化して管理しないことの妥当性について - 作業記録]

私は、彼の葛藤を理解する。なぜなら、私もここ数年、ミドルウェア、エンジン、シーングラフを研究することによって、系統的にゲームエンジンやグラフィックスを扱うことに挑戦してきたからだ。しかし、会社の実際の仕事で、私はそれを実践できていない。リアルタイムアプリケーションであるビデオゲームプログラミングは、常にパフォーマンスを要求し、そして、多くのプログラマがプロジェクトに参加する。そのため、パフォーマンスとプロジェクトの初期期間の両方を犠牲にする体系的アーキテクチャは、有益ではない。

C++ のような高級言語は、我々のプログラミングスタイルを変えるよう誘惑する。アマゾンや書店は、オブジェクト指向のプログラミングを書く方法を教える本を陳列している。我々は、これらの本を読み、そして、オブジェクト指向のプログラミングによってゲームオブジェクトクラスを扱えないか考え始める。大規模システム設計におけるオブジェクト指向アーキテクチャについての十分な議論があることは確かである。しかし、（特に日本において）、ビデオゲームアプリケーション設計のための議論は十分とは言えない。

欧米では、開発者は、ゲームオブジェクト設計を議論する。しかし、彼らの大半は、 FPS 、及び、 RTS を開発する。これらのジャンルは、オブジェクト指向の設計と相性がよい。しかし、ゲーム全てが FPS/RTS であるわけではない。そのため、多くの日本の開発者は、ゲームオブジェクトクラス設計を議論しない。他のジャンルでは、ゲームコアが統括的にゲームをコントロールすることが必要である。そして、ビデオゲーム開発において最も重要なことは、調整と調節である。恐らく、我々の世界における理想的なアーキテクチャは、エンターテイメント制御装置を調整と調節が容易なように 1 つの場所に集めることだ。ビデオゲーム開発者は確定された仕様書より娯楽感覚を重要視しなければならない。

大規模システム設計を教える本にと一緒に我々がソースコードを書くならば、ゲームアプリケーションはプログラマの虚栄心を満たすだろう。しかし、そのアプリケーションは、ビデオゲームプログラムとして悪いものである。我々の理想的なプログラム設計は、大規模システムと異なるであろう。そして、ビデオゲームのオブジェクト指向設計は、大規模システムのオブジェクト指向設計と異なるだろう。従って、それらの本は、すべてのことを我々に教えてくれるわけではない。我々は、自分で答えを発見しなければならない。まだ日本もそして欧米もその答えを見つけてはいない。