Whiteのふりーとーく

時間的に余裕があるので贅沢に仕事をする。なんせ、次の打ち合せが来ないことには仕様はぜんぜん固まらないし、従って今実装進めてもそれが採用されるか怪しいわけで。

そんなわけでへこへことHTTP/1.1の仕様なぞ読みながら、あれこれ思案する。あれこれ思案しながら仕事できるのは、およそ新人扱いの今のうちだけであろうて。

今更感も絶好調な「銀色」感想。トータルとしては、良く頑張ったマルチレイヤ表現であろう。ただし、ゲームであると思ってはいけない。いちおうゲーム表現と考えることは可能であるが、決してインタラクティブな表現ではない。これは、単方向のマルチレイヤ表現である。むしろ基本はオートプレイだ。

オートモードはそれなりの出来。ただ、テキストレイヤの表示タイミングが、音声レイヤに依存しているのが難点。時折、テキストの進みが早過ぎたりするケースもあった。残念な点である。

_と、ここまで見れば（俺にしちゃあ）好印象ではあるのだが、だがしかし予想通りの場所の予想通りの演出のなさに萎えた。有り体にいうなら３章だ。全部セリフにするなっつーの。物語の力学も演出もない。つーか、全体の演出コンセプトがまるきり通ってるように見えないのはどうか。これはコンピュータゲームであって、絵も音楽も使えるのよ？

翻って、全体に目を戻すと、果たしてわかっててやってるのかそうでないのか、判断が難しい。たとえば「オートモード」が存在するあたりなどからはわかってるように思えるのだが、依然として「次の選択肢へ進む」やらそもそも選択肢が存在するあたりは、単にわかってないだけなのではないかとも思う。

_まぁ、あれだ。この調子で継続していってくれればそのうちモノになるような気もするが、新作（みずいろ）の宣伝文句を見ていると、根本的に勘違いしてる集団であるという気もする。願わくば、正しい継続が行なわれてほしいものだが。

先日お披露目のprecat.plのバグ修正。つーか、最後の一行出力させるの忘れてた(--;　だめじゃん。

_観察が行方を決定するゲーム、というものが作れるはずだ、と思う。提示された、一見完全に並立する情報の、閲覧順番が世界を決定づけるアドベンチャーゲームなどというシロモノである。

言うまでもないことだが、これはゲームだ。存在するリソース（情報）に対して、どれを見るかと言う選択が存在する。選択の結果によって、状況（世界）が変化する。あとはその関係性が理不尽でなければ、良いゲームになるための基本構造は満たせるであろう。

_では、理不尽でない――理の通った――関係性を持たせてやれば、それはよいゲームになるはずだ。そして、人間は（少なくともゲーマーと呼ばれる人種は）よいゲームには反応する。自らルールを発見し、応用しようとする。というか、発見したものを把握し応用しようとする衝動は、知性と呼ばれるものの持つ本質の一つだ。

で、知性の生き物である人間ならば、発見したものは把握し応用しようとするであろう。実際には、世の中もっと混沌に満ちていて、有り体に言うと馬鹿ばっかりで、そもそもそんなふうに動いてくれないものなのだが、それはこの際無視する。

とにかく、必要なのは発見させることだ。プレイヤーの観察によって世界が変化する、ということを発見させる必要がある。では、世界が変化したことを発見させるにはどうすればいいか？　

_このゲームでは、選択が発生する状況は一つしかない。つまり、プレイヤーが選択した情報を閲覧し終え、新たに見る別の（あるいは同じ）情報を選択する場面である。

この場面は同時に、最もインタラクティブ性が高まる瞬間であり、プレイヤーの意識が最も強くゲームを向く瞬間でもある。であればその瞬間に合わせ、提示する情報を変えればよい。すなわち、閲覧対象を決定するための選択項目を、以前と変化させるのだ。

プレイヤーがなにかを見て、そして選択画面に戻ってきたときに、なにかが変化している。ここまで提示すれば、プレイヤーはその原因を推察するだろう――「プレイヤーが閲覧を行なったから」だ、と。

_これで、あとはもういくつか、ルールを定めてやればよい。例えば「過去における予言は未来の確定した観測結果と関連がある」とかを示すのだ。あとはルールを組み合わせて、世界の中を渡り歩かせれば良い。

そうそう、大事なことを忘れていた。「望ましい結果」をプレイヤーに提示しておくことを忘れないように。目的がなければ、ゲームは成立しないのだから。

先刻の思考実験では非常にしれっと書いているが、「ルールを発見し、応用しようという衝動」というのは、ゲームというものの本質を考えるのに非常に重要なのではないか、と思ってみる。しかしそんなことを言い出すと知性とものを考えるという、およそ恐れ多くて（not誤字）踏み込みたくない領域に突入してしまいそうな気もする。

結局、外界に触れた知性的なものによる選択、がゲームの基本構造である以上、いつかは踏み込まなければならない領域なのはわかっているのだが……。

思考実験の補足。たとえば「過去における予言は未来の確定した観測結果と関連がある」とかをどう使うかというと、

• 未来を観測する（観測のたびに微妙に結果が変わる）。
• 望ましい観測結果が出るまで観測する。
• 過去の予言があった時点を観測する（未来の観測結果に依存して予言は変化している）。
• 予言に依存した中間点の何らかの事象を観測する（予言が変化しているので、変化する）

というような感じなわけです。実際には前出のルールに加えて「確率論的に結果が変わるケースがある」「最終観測結果が世界の状態となる」「過去の観測結果に現在は依存する」などのルールが存在してるわけですが。

_面白そうなアイデアなのだけど、これを実現するのに果たしてシナリオ量がどれだけ必要になるか。考えると、わりとクラクラ来てみたり。

ところで昨日のアレが某所でウケていて、作ることになるかもしれません。言い出しておいてなんだけど、あんなん管理できるとは思えませんが(--;

まー、考えるだけなら楽しいし、しばらくはアイデアだけだらだら考えるかと思います。あ、万一ここの記述を見て、そのままパクって企画書出す方がいたら連絡下さい。そしたら考えるのやめますんで（笑）

プロトコルとしての効率は大変に悪いですが、(--;、某方面に向けて言ってみるテスト。

_ここの更新は、現在以下のような手順で行なわれておりますです。

• 新規投入する文章を書く
• 更新用スクリプト（by Perl）を走らせる。動作は以下の通り。
• Webサイトから、ftpで現状の最新版、定静版、検索用インデックス、テンプレート、などを取ってくる。
• 取ってきたあれこれを（ローカルで）更新する。
• ローカルで更新したもののうち、最新版、定静版、検索用インデックス、をftpでWebサイトに置く。

主要な動作はすべてローカルで行なわれているので、perlが使えてftpさえ通ってしまえばだいたいどこでも動かせるはずです。ちなみにftp関係のコードは、勉強も兼ねて自作です。そんなことせんでもライブラリ使えば、馬鹿みたいにあっさり実現できます。

つーか、人間様がやることはいいかげんに文書書いていいかげんにスクリプト走らせるだけですな。あ、ftpのパスワードは一応手入力ですが。

ちうことで、某方面に向けて怠惰を推進してみる、と言いつつ日記システムの話。

_既に最新版抽出システムが存在しているのなら、

• 過去ログの適切な位置への新規文書投入
• 更新後ファイルのアップロード
• 文書記述以外の更新処理を自動化するバッチ

と構築すれば、自分がやるのは文書書くだけ、状態になりますな。このうち、自分が楽になれるところを優先して達成するのが吉。不便と思ってないところを、無理に変える必要はありませんし。

そそ、ついでにテキスト->htmlフィルタとか、検索用インデクサとか動かすようにするともっと幸せになれるかもしれません。

_リンクとかのタグ打ちは私も自力です。ただ、元テキスト自体はemacs上で書いてるのでhtml-modeの恩恵は受けられますが。あ、終了タグの補完は自動化してます。手で打ってもいいんだけど、そんな自明なものを人間が打つ必要はなし。むしろ機械がやるべきでせう。

誤字修正機能とかは皆無。つーかそのときは、検索用ライブラリの再構築が必要になったりするので、あきらめます。

_ちうか、あれだ。日記を認めるシステムたちなど参照のこと、と言ってしまえばそれでいい気がしないでもないですが(^^;

「ふわふわの泉」（野尻抱介、ファミ通文庫、ISBN：4-7577-0405-4）読了。感想：っつーか、これはどうよ？

面白い、確かに面白いんだけどさぁ。小説としてこれはどうかと思う。いや、面白いからいいんだけど。でもやっぱり小説としてこれはいかんわけで、でも面白いのは（以下エンドレス）

ちうことで、本日遅刻しました。いや、明確な就業時刻が決まってるわけでもないのだけど。

出がけに派手に鼻血を出してみたわけです。別に狙ったわけではないですが。

あれです、この時期アレルギーで鼻の粘膜弱ってるから、起きぬけとか風呂の中とか、血圧上がるタイミングは非常に危険なのです。しかも今日のはかなり派手で、久々に鼻血で死ぬかと思ったぐらい。いや、そんなんで死にゃせんけど。

でま、止まるまであれこれと（手慣れた）止血手順を行なって、血で汚してしまったあれこれの処置をして、遅刻大確定の時刻に家を出ましたとさ。

なぜかPython2.1のコンパイル & インストールなどという余計な手間を経てから、くらくらするような素敵なスクリプト & htmlと格闘。ってゆーかさー、<h3>とかの終了タグがないのはどーにかしよーぜー(-_-;

怒りをこらえつつ仕事は進める。Pythonが案外快適なのが唯一の救いか。

Perlのvar型の強力さを思い知ってみる。型変換もクソもなくとりあえず動くvar型のなんといいかげんで強力なことか。

昨日プリンタ購入。BrotherのHL-1240也。同価格帯では画質の点で若干見劣りするものの、給紙枚数と印刷速度が決め手。なにげに（手動での）両面印刷もOKなあたりが微妙にポイント高し。

ただ、若干メモリが少ない上に、増設が効かないあたりに難があるかも。不満というわけではないのだけど、ページレイアウト機能で複数ページまとめると、ときどきメモリ不足で解像度が（勝手に）下がったり。ま、どーせそういう印刷のときはクオリティなんて求めんわけだし、そのへん勝手にやってくれるのは素晴らしいのだけど。

ちうことで、おねぐらIRCのゲーム性の話の延長戦、ちうか場外乱闘。

_議論に「ゲーム性」などという曖昧なシロモノを持ち出すべきでない、という正論はこの際無視するとしても、そもそも表現というものはすべからくゲーム性を持っているものだと思います。

ゲーム性というよりは、インタラクティビティと言った方が良いでしょうか。映画であれ、小説であれ、表現というものは読者が読もうとして始めて意味を持つものです。

もちろん、読者の視線があることを意識しない表現というものもありますが、そういうのはインタラクティビティを考慮に入れてない、利用してないものなのでしょう。

要するに何が言いたいかというと、音、絵、声、文章、などの表現レイヤに、「ゲーム性、インタラクティビティ」というレイヤを付け加えて考えてみましょう、ということなんですが。

ちなみに、この件については過去あれこれ書き殴っています。そのへん読みたいという奇特な方は過去日記検索：レイヤの結果なぞ御覧下さい。密かに「プレイヤー」でもひっかかるのでS/N比低いですが、えてして微妙に関係ありげな感じのことが多いので気にせず。

_閑話休題。

前項で取り上げた前提を踏まえて、一つ質問をしてみましょう。

音付きの映画と、サイレント映画のどちらが優れていますか？

あるいは、カラーと白黒とどちらが優れていますか？

技術的にはどっちのほうが難しい、というのはあるでしょう。それをもって優れているとするなら正しい答ですが、こと表現と言う観点でならどちらが優れているとも言えません。

要は、どうレイヤを組み合わせて使っていくか、が問題ですから。音がないからこそ深く伝わるとか、白黒であるからこそ感じる鮮やかさとか、そういう効果を狙ってレイヤを制限することもあります。

_ただ、そう考えたとき、多くのコンピュータゲーム形式を取った物語表現は、ゲーム性というレイヤに自覚的でないと思うのです。ゲーム性というレイヤを、どう表現に組み込んでいくか、というところで非常に弱い。

もちろんそんなレイヤいらんというならそれで正しいです。それは、自覚した上での選択ですから。そうでなく、単にコンピュータの上で再生するからゲーム的な形式を取り入れても、それは意味がない。素人がカブれて高いギターみせびらかすようなもんです。

どーでもいいツッコミ。九九がなくてもかけ算はできます。その回数だけ足し算すればいいし、それが嫌なら2進の筆算――x+x = 2x, 2x+2x=4x, ...とやって言って、必要なだけの2ⁿxを求めて、最後にそれらを必要なだけ加算する、とすればできます。いや、そんだけ。

開発機と実験機が別である上に、実験機側のSSH設定によりX-windowsのPort forwardingが阻止されている。root権限は持てるから勝手に設定変更してもよいのだが、それは忍びないので以下のようなことを試みようと思い立つ。

• perlのNet::FTPモジュールを使い、ftpで対象の機体にファイルをputするスクリプトを書く
• makeを使って、各ファイル毎に更新されていれば前述のコマンドを走らせる

と、内容は非常に簡単。

問題は、送るファイルどもはCGIスクリプトであり、すなわちコンパイルもなんもされないという点である。これではmakeは更新を検知できない。

今回の回答はこんな感じ。

TARGET = target1.cgi,target2.cgi
all: putit.pl
putit.pl: $(TARGET)
	./putit.pl $?
	touch putit.pl

どーせputit.pl（ftpでファイル置くスクリプト）を置くのなら、touchコマンドでこいつを更新の目安にしてしまおう、というわけ。touchの対象は、別段Makefile自身でも構わないと思う（実験はしてない）。ちなみに、Makefileなんて書くの久しぶりで往生したのは秘密だ。

どうしたことか、pythonからOracleを叩く必要がある。ちうことで、DCOracleのインストール。

_以下、具体的にやったこと。

とりあえず、ORACLE_HOMEとかが設定してあるユーザでログイン。そしたら以下の順にコマンド実行。

% tar xzf DCOracle-1.3.2.tgz
% cd DCOracle/src
% cp Setup-8.1.5 Setup ：使用してるOracleのバージョンによる
% cp Makefile.pre.in-1.5 Makefile.pre.in ：使用してるpythonのバージョンによる
% make -f Makefile.pre.in boot PYTHON=python
% make
% python DCOracle_test.py user/pw@sid ：user,pw,sidには適切な文字列を
% su 
# make install
# cd ..
# cp -R DCOracle /usr/local/lib/python2.1/site-packages/ ：pythonのインストール先による

とやって、以上でインストール終了。

御覧の通り、python2.1に対してMakefile.pre.in-1.5で強引にインストールしておりますが、無事インストールできているようです。

いちおう解凍先ディレクトリの文書を追っていけば、以上の内容は把握できんこともないのですが、「解凍ルートのREADME.txt → srcディレクトリのREADME.txt」と必要な情報が分散されている上に、肝心のインストール先が「適切なモジュールの検索パスにコピー」とか曖昧な書き方されているのでわかりにくかったです。

せめてインストールドキュメントは一箇所ににまとめておくなり、コピーする時のコマンド例なり、示しておけっての。

自分たちに満足いくものを、という考え方は、アマチュアの考え方だと思います。プロにとっては、設定された条件がすべて。商業的プロフェッショナルであるならば、利益がすべて。

利益のためならば妥協をするのも、商業的プロフェッショナルの仕事のうちでしょう。

予算の枠、スポンサーの意向、遵守すべき基準、そういう諸々の制約の中で、いかに折り合いをつけていくか、最大限の効果を引き出していくか。そして、いかに売るか。

どんないいものを作っても、売れなければ商業的には敗北ですし、どんなクソでも売れれば勝利です。

もちろん、プロフェッショナリズムが常に商業的な方向を向くとは限りませんが、そうであるなら手を抜くのもプロの仕事です。手を抜いて、しかも売れるのなら。そっちの方が利益が大きくなるなら、積極的に手を抜くべきですから。

そう、利益がすべて、です。

しかし人間がそこまで割り切って考えられるものではありません。

実際には、そこまで割り切って労働しても士気がずんずん下がります。士気がずんずん下がったら、同じ投資で得られる結果が下がります。要するに、不利益です。

利益のために良いものを作らせるために士気を上げるために面白いと思うものを作る――というのが、理想的な好循環でしょう。

もちろん単に好き勝手やってもアンバランスなものが発生してしまうので――ってのは、モノを創るための２つの意識の再話になりますが。

作為的に作られたものと、感情に任せて作られたもの――どちらが好ましいかは人それぞれですが、

いや、トップページに（SSIで）張り付けてある更新日は動的生成なので更新されているのですが、それがHTTPのLast-Modified-Sinceヘッダに反映されないだけです。XBitHackの悪影響ナリ。嘘をついている――というわけでもないのですが、ふりーとーくの更新時刻取るんなら直接取って下さい。

もちろん、更新のたびにトップページのタイムスタンプを何らかの方法で変更してやれば、対処することは可能ですけど。連休中に気が向いたら、対処するかもしれません。

微妙にログが取れてなかったのを修正したり。SSIで呼んでるログ取りスクリプトへの引数間違えてたのこと(--;

あれこれ考えた挙げ句、結局やっぱり仕方なしにOracleのストアドプロシージャと戯れる。何故かようにわかりにくいか。単に俺が慣れてないだけかもしれないが、それにしたってもう少し人間様を大切にしやがれってんだ。

Jordana680（中古、液晶にヨゴレ有り）を購入。当座の執筆用機体として。一応、TP220をjvimで使うようにすればスワップなしで動く目処が立っていたので、そっちをシリコンディスク化という案もあったのだけど。

だけども、新しいオモチャの魅力には勝てず。思わず散在の巻。

速攻でNgが入っているあたり、なんつーか既にまっとうなユーザーではないですが。