Whiteのふりーとーく

@

以前にGnoCatanを利用してRPMのspecファイル書きの練習をしたのを突如発掘。ということで、いいかげんに公開

• gnocatan-0.7.1-1.src.rpm
• gnocatan-0.7.1-1.i386.rpm(Red Hat Linux 8.0でbuild)
• gnocatan.specとgnocatan-0.7.1_rpm.patch。patchの方はいい感じでハードコーディングとかかましてやがります。

@仕事

tarでやろうとするも、公開(のはず)のディレクトリに大きなログファイルがある始末。find + tarでどうにかできるかと思ったが失敗(tarの仕様 / xargsの制限?)。仕方ないのでいつもの如くrsyncを勝手にコンパイル。で、-e ssh --rsync-path=$HOME/bin/rsync とか付けて実行。これで一応目的の範囲のものを手もとに落とすことに成功。

@GUIと「多機能」はそんなに相性がよくないのかもしれない。

http://elel.vis.ne.jp/imgpage/0804word.htmを見て笑う――そして標題のようなことを思う。

「多機能」と「高機能」が違うことには注意。もちろん、「直感的に多機能を使いこなせる」ことはGUIの利点であるが、そもそも多機能を使いこなす状況は「直感的」とは程遠い。

@寝坊

激しく寝坊して昼過ぎ出社。

@

しかし仕事は凄い勢いでペンディング(客の回答待ち)なのであった。仕方ないので調査とかに時間をかけるが、モチベーションが上がるはずもなく、だからゆっくりとしか進まないがそれで丁度いいぐらいに暇。

もちろんそれで納期が伸びるわけもなく、後で苦労することになるのだろう。時間を貯めておくことはできないが、前借りしてしまうのは容易なのだということか。

@原稿

あいもかわらず今ごろになってGameDeepの原稿とか書いていたり。

ネタは「ときめきメモリアルの最終進化形はパワプロのサクセスモードに違いない！」というアレな感じのもので。相変わらずのインチキ考察でなんかそれっぽいものが書けていくのが不思議不思議。

と、いうことでGameDeep vol.8「ギャルゲー超越論(仮)」は、コミックマーケット64の以下のスペースにて委託販売の予定です。

• presented by tatuya 1日目 東ユ-16b
• ジャンク・ヤード 2日目 西ほ-01a
• 豆満江開発機構 3日目 東ヒ-26a

あと、GD #は出たりするかもしちゃったりしれません。こちらはすばらしく未定。

@

一連の攻略されなかったヒロインはどうなるか？話(リンクは発火元)を読みつつ、「皆殺しの富野」というフレーズを思い出す。

何故富野がかくも皆殺しを行なっていたかと言えば、作中で提示した多くの物語に決着を与えようとするからではないだろうか。例えば主人公への対立という軸で登場したキャラクターの物語は、主人公が勝利することによって必然的に行き詰まりを迎える。であれば、行き詰まった物語の明解な終焉として、死が用いられるのは必然だ。とは言え近作ではそうでもなくなってきた(もっと別の弾き出し方をするようになっている)のだが。

_翻って、攻略されなかったヒロインの方に目を向けよう。

そこで目に付くのは、一度提示した物語を回収しない乱暴さだ。

乱暴、というのは言いすぎだとしても、あまりセンシティブではない作業が往々にして行なわれているのは事実だ。抽象的な話になるが、説明しよう。

所謂「共通ルート」では各々のストーリー(の伏線)が提示される。そしてそれぞれの伏線は各々のルートで解決される。ところが、これでは全ての伏線が解決されるには足りないのだ。問題は、Aルートのための伏線[a]とBルートのための伏線[b]が、一緒に提示されていることである。個々で独立していれば、これは問題を起こさないだろう。ところが、これを近く(同じ共通ルート内で)提示することによって、[a]と[b]は衝突する。あるいは化学反応的な変化を起こして、[ab]という新たな伏線を引き起こす。

[ab]の発生は実はプレイヤーの勝手な想像であるのだが、しかし[ab]は発生してしまう。それも結構な高確率で。このとき[ab]の解決を図らなければ、[a]と[b]が解決されても何かが残ってしまう――ような錯覚を受ける。

_もちろん昨今では[ab]を解決する作業が「二次創作」という遊びの一形態として存在しているわけであるから、わざと[ab]を残すような作り方もアリだろう。しかし、意図して残すのと意図せずに残してしまうのとでは、大違いだ。しかも、意図したか意図していないかは、存外簡単に読者に伝わってしまうものなのだ。

@

ところで俺は同居人に対して「[ab]まできっちり書きこめ！」と言わんばかりの酷いアイデアを提示したのだなあ、と気付いてみた。

@

週末は部屋の模様替えとかで潰れました。無印良品のPP組立式ワゴンを6段構成で導入して、これまで部屋の真ん中に鎮座していたサイドテーブル兼TV台をカラーボックスと入れ換えで本棚群の中へ。こころもち部屋の解放感がUP。

ということで、現在はウレタンブロックの導入を検討中。

で、当然ながらGameDeeoの原稿はあんまり進まず。

@

週末を挟んでしまったので今更感も強いけど、返答とか。

http://www2.osk.3web.ne.jp/~naokikun/diary17.htm#030808_3より：

伏線[a]と伏線[b]が互いに無矛盾であり、かつ、伏線[a]の解決[A]と伏線[b]の解決[B]が互いに無矛盾であるとします（ここまでは既に書いた前提条件です）。

さて、ここで問題になるのが、Whiteさんの言う[ab]とは、どういう演算なのか、と言うことです。

単なる「AND」なのであれば、伏線[ab]には少なくとも一つごく自然に矛盾しない解決、つまり[A][B]を同じようにAND演算したもの[AB]が与えられるはず。

Whiteさんの言いたいのはそうではなく、[a]と[b]の間に起きる何かの「化学反応」でしょう。

そこをもうちょっと解説してほしいかも。記号より具体例で語るほうがいい話題かもしれませんが。

以前の提示について言い直すと、「同じ作品の中で語っている以上、[a]と[b]は独立ではない(と思われても仕方がない)」あるいは「発信者の思っている通りに受信者が受け取るわけではない」ということです。

_演算[ab]についての(実は今考えている)解説：[ab]は単なるAND演算ではない。それは、受信側での情報変換(*1)である。伏線(=情報)[a]と[b]が同一のコンテクスト下で提示されることによって、情報[ab]が主に受信側で発生する。

ただし、[a]、[b]は発信側に由来するものであり、[ab]は受信側に由来(?)するものである。その情報の来歴に着目するならば、[ab]についてはむしろ別の記号(例えば{ab})を当てるべきであるかもしれない。

_ということで、来歴を明確にするべく、{}を導入して仕切り直したいと思います。

_ここで重要視しているのは、「{a}と{b}から{ab}が発生するときのルール」ではなく、「{ab}が発生した結果、{ab}と予想({ab})が乖離すること」です。すなわち、「発信者の思っている通りに受信者が受け取るわけではない」という点です。

_……とまあ、なんか偉そうに書いてはいますが、基本的には表現者にとってはあたりまえのことだと思います。ただ、ゲームでは双方向性やら多様性(分岐性)の絡みのせいで、発信者の意図せざるところを受信者が着目してしまう局面が多くなるんじゃないか、とも思います。

@

久々に(仕事する上で使いたくて)libgajafとかいじったときに思いついたことメモ：

• 生成時のコンフィグ情報を、インデックスファイルに持たせるのが正しそうな気が。
• というか、メタ情報フィールドは可変長にしたいのう(今は格好悪く固定長)。
• インデクサのCでの書き直しはどうだろう？
• ハッシュ長を2048bits(=256bytes)ぐらいにするとそれなりに誤判定しなくなる。
• もうひとがんばりすれば、俺以外でも使えるシロモノ
• 何故大人しくnamazuをつかわない？(ぉ

ま、どれもこれも実装上の問題で、目新しさなぞなんにもないのだけど、ね。

@致命的造反

プリンタに造反されました。というか、酷使し過ぎ。

症状は紙づまりっぽいのですが、かなり深いところに紙が残留してしまった模様で、手の打ちようもなく。メーカーのページで調べると、修理を頼んだら最低15Kコースらしいです。で、同等の新品買うと20K。両面印刷機能付のやつなら35K〜50K。とりあえず35Kコースかなあ、という雰囲気ですよ。

_GameDeepについては、既に最低限の生産を完了した後だったのが不幸中の幸いというか。というわけで、新たに発生してしまう粗大ゴミの修理に挑戦したい方が万一おられましたらお知らせくださいませ。

@出撃その１

今更告知。GameDeepの類は以下のように委託されます。

しかし、プリンタ様には造反を食らったので部数が足りるかは不明です。てへ。

_で、今日は家でのんびりのつもりだったのですが、急遽売り子を要請されたので出撃です。で、明日も売り子。

例の如く例の蛍光オレンジで会場に存在していると思いますよ。そんなわけでよろしく＞各位