原則匿名で公開・個人情報は送られません。必要に応じ御署名/非公開希望をお書き添え下さい。
_ 掲示板:YaPW 旧掲示板 SMIL Boston日本語訳(頓座)
自分の意見としては、GORRYさんのそれに賛成。演出という側面から考えるなら「版面ごとに逐次で理解できるもの」と「連続版面としてはじめて意味があるもの」は使い分けるべきものでしょう。
もちろん、どちらにしろ版面の小ささを意識して内容を構成しなければならないとは思います。というか、いわゆるノベルゲーム形式のものは、「文章を読ませる」ものではなく、「版面を見せる」ように作るのが理想だと思います。
本とかに比べて、版面の機能を自由に設定できるのがゲームにおけるマルチレイヤ表現の特徴。絵が出る、文が出る、音が出る……バックスクロール可能なのも版面の機能の一つ。どれが正道とか邪道とかではなく、ありとあらゆる可能な手段を使って、表現できる。それこそがメリットだと思うのです。
と、本としての邪道の極みたる「はてしない物語」を近頃再読した身としては思うのでした。
あるいはお約束が悪いのではなくお約束の見せ方が悪いのだとかいろいろ言いたいこともあるけどそこらはパスっちうことで。
そのアイデアは、ハイパーリンク的ADV、っちう認識でいいのかな? そんな感じのものだったら、以前に考えて、内輪で話のタネにしたことがあったです。個人的には純粋に思考実験として、周囲からはほんのちょっとの期待を受けながら。
ちうことで、過去のメールを掘り返してみると、丁度去年ぐらいのことでした。丁度いい機会だから埋もれないようにまとめとこう、とか思ってみたり。大した話がされたわけでもないけれど、更なる泡沫の礎となることを期待して。
改ページの利用が「文章」として邪道なのは、そこで「文字・記号」の連続としての表現だったものが、突如版面そのものを利用した表現になってしまうから。クラシックだと思っていたものに突如ヘヴィなドラムが重なってきたら「邪道!」と思うのもある意味当然。
ところで特定のシーンだけクリック音ってので、サスペンス系の話でクリックで靴音って演出を思いついてみました。面白そうなので私としてはアリ。
昼頃に家を出てのんびりと京葉道路 -> 靖国通りと流して会社へ。
でもって、仕事……というわけでもなく、かといって仕事にまったく関係ないわけでもない調べ物など。
昨日(勤務中の)先輩との余太話で、CGIのエラーチェッカとかないか、という会話があったので。具体的には、フォームにあれこれと入力されそうな値を適当に突っ込んで結果を見ると言うツール。
とりあえずgoogleで検索してWeb Site Test Tools and Site Management Toolsなんかにたどり着いてみたが、有効そうなものが見当たらない。
Source Forgeで"CGI test"で検索してみたが、こっちもイマイチ。CCTEなるものが近そうな雰囲気だが、1年近く放置されている上にアルファ版なので、ドキュメントが整備されておらず、なにやってくれるものかがさっぱりわからん。一応アイデアがないこともないので、作ってみてもいいかもしれない。ということで、今考えてるアイデアをまとめてみる。
まぁともかく作ってから使い物になるか考えるという方針でよろしいかと思う。ということで、しばらくは考慮期間に入るつもり。
というのも、BD-1にボトルホルダーを付けたいのである。しかも、折り畳み性能に極力影響を与えないようにして。
曲者なのは、折り畳み性能云々の方だ。この制約を満たしそうな取り付け位置として、メインフレーム直上、目一杯下げたシートにぶつからない範囲で極力シートポストに寄せた位置、というのに目をつけた。
目をつけたのはいいのだが、BD-1のメインフレーム形状は、楕円柱という特殊な形状をしている。しかも、結構太い。然るに、よい取り付け器具が見つからない。なければ自分で作るしかない。ということで、思案する。
取り付け器具、というと大層なものに思えるが、なんのことはない。要するに、ボトルホルダーを留められるネジ穴があればよいのだ。すなわち、適当な間隔のネジ穴が2つ、あればよい。ということで、あれこれ方針を考えてみる。
とりあえず溶接は却下。そんな設備がどこにあろうか。第一フレームが再起不能になったらどうする。同様にネジ穴切るのも却下。接着剤はまだましだが、あまりやりたくない。
となれば、テンションかけて固定しかあるまい。とりあえず、その場はなんとなく訳に立つかも知れないという理由で焼入れリボン(厚さ0.3mm)だけ買って帰る。
で、今日。とりあえずペダルを適当に交換してから、以前に買っておいたボトルホルダーを片手に、近所のコンビニより近いホームセンターへ出向く。あれこれ思案の末、揃えたものは以下の通り。
基本路線は、「ボトルホルダーをネジでステン曲板に固定」「ボトルホルダー+ステン曲板をケーブルタイでフレームに固定」。ゴムは、フレームの傷防止、ステン板からはみ出るであろうナット高さの埋め、ケーブルタイと組み合わせでの固定効果、と盛り沢山な役割つきである。こうしてみると、ゴムというのは実に素晴らしい素材だ。
ゴムを適当な形に切り、ボンドで板に貼り合わる。ゴム、板、ナットでそれなりに取り付け器具っぽいものを作り、ゴム側を下にしてケーブルタイでフレームに固定。
ボトルホルダーをねじ留めし、サドルを目一杯下げて位置調整。このへん、ケーブルタイなどといういいかげんな留め方をしているので簡単に調整できる。
試しにボトルを入れたり外したりして、それなりな具合なのを確認。しばらく試してみて、改良点など考えよう。写真などは今のところ環境がないのでそのうちに。ちなみにゴム板合わせても、1000円に行っていないはずである。
ちょっと遅れてプログラマに100質問に回答してみるのこと。
普段より幾分早く目が醒めたので血迷って自転車で出勤。
道筋はいつものように、サクッと14号に出てまっすぐ行くと靖国通りに名前が変わりやっぱりまっすぐ、で会社まで。電車使った場合の+15分ぐらいで到着。
これだったら、晴れてる日は自転車で来てもいいかもしれない、とか思ってみたり。
諸般の事情でrsyncを憶えてみる。本当は先方にWebDAVかCVSあたりを使わせたいのだが、とりあえずその必要性を説くところから入らねばならない。説けたとしても、それ用のアプリケーションを導入させねばならない。
というのは面倒なのでrsyncである。これにMakefileを組み合わせて、ひどく簡単な更新管理環境を構成する。もはやmakeがただのスクリプト切り替え機としてしか機能していない(*1)のはどうかと思うが、touchとかfindとかsshとか組み合わせてそれっぽく動くものを作成。
make co
でprimary -> local copyにファイルをコピーmake commit
でlocal copy -> primaryにファイルをコピー。ただしprimaryが更新されていないときのみ。make check
でprimaryが更新されていないかチェック。make check
やmake commit
で更新が検知された場合には、手作業でどうにかするってことで。cvsと組み合わせてそのへんまでやらせるというアイデアもあるが、とりあえずはこれでよかろう。
RHOST = hostname RDIR = /path/to/target CHECK = `ssh $(RHOST) find $(RDIR) -type f -newer $(RDIR)/.checkout` co: @rsync -auvzb -e ssh --exclude '*~' --exclude '.checkout' $(RHOST):$(RDIR) ./ @ssh $(RHOST) touch $(RDIR)/.checkout @touch .checkout commit: @r=$(CHECK);if [ $$r ]; then echo $$r; exit 1; fi @rsync -auvzb -e ssh --exclude '*~' --exclude '.checkout' ./ $(RHOST):$(RDIR) @rsync -auvzb -e ssh --exclude '*~' --exclude '.checkout' $(RHOST):$(RDIR) ./ @ssh $(RHOST) touch $(RDIR)/.checkout @touch .checkout check: @echo $(CHECK)
(*1)ファイル更新日付のチェックはrsyncの仕事なので
今日も今日とて自転車通勤。
実際に走ると、BD-1の走行性能の意外な高さが実感できる。流石にロードバイクには勝てないが、街乗りMTB相手だったらひけを取らないぐらいの走りは可能だ。とはいえ、その走行性能を拡張するのは本末転倒だろう。それなら素直にロードを選べばよい。
_ものにはそれぞれ向き不向きがある。自転車ばかりではない。たとえば我が生業の相棒となってしまいそうな、プログラム言語とかでも――だなんて話はプログラム言語話のときにしたか。
_仕事が微妙に手空き。知見を広めるべく読んだり考えたり。オブジェクト指向についての良文:オブジェクト指向は本当に「オブジェクト」指向か?。
_単一の万能な手法などはありえない。必要ならば変化させた方がずっとうまく行くことがある。考え方の枠と言うのは、あくまで考えやすくするためにあるのであって、考えにくくなるのならとっ払ってしまったほうが良い。
_たとえば板金屋は素粒子論だのニュートン力学だの金属の弾性だの剛性だのとかいう理屈は知らなくても、ハンマーを握るその手は、必要な物理的挙動を把握している。そこにある感覚によって、(限定的ではあるが)それらは確かに理解されている。
_理解と体系化とは異なる作業だ。されど、プログラムという作業は驚くほど直観的でない。本質的に、理屈から理解を組み上げていくようなシロモノである。それはすなわち、数学という体系のもつ構造に近しいのであるが。
_かくて、魔法の言葉で世界は宣言され、要素によって世界は回り、時がそれを収束させる(あるいはさせない)。我々がコマンドを打ち込みそれを回すことは、宇宙の開闢と消滅であるのかもしれない。
ついでに名前空間とかURL参照オブジェクトとかそういうものも作れるようにする予定で、ガツガツと素体を組んでいく。たいへんに気持ち悪いがたいへんに柔軟なPerl5のオブジェクト指向実装を活かして、「コンストラクタを直に呼ばずにコンストラクト〜」などといきなりどうかと思うことをやらかしたりと、微妙な頭が悪さは保ちつつ。
目覚めると、なにやら筋肉が張っている。
至極当然である。しばらくろくに運動していなかったところに、突如自転車通勤を始めたのだから。試しに(いまさらになって)地図で距離を計ってみると、片道30km以上あるっぽい。往復すると60km。疲れるはずである。早いとこサイクルコンピュータを買うべきか。
などと思いながら新宿へ。会社の最寄り駅と新宿駅までとが、同運賃なのを発見し回数券購入。自転車通勤は当分続けるつもりで。
お出かけの主目的は、東急ハンズでアルミ板を中抜きしてもらうこと。先日会社で16ポート100/10Baseスイッチングハブを買ったのだが、そいつを机と机の間に吊す、というレイアウト案を実現するための実験用である。
行きの電車の中ではあれこれと検索エンジンのインデックスの作り方など思案する。ものの本だの論文だのを当たれば、あっさりよい案が見つかるのであろうが、こういうのは考えるのが楽しいという側面もある。
新宿について、寄り道せずにハンズ6Fへ。適当な大きさの板を頼み、ハブの寸法に合わせた中抜きを依頼。しばらく時間がかかるので、自転車用に小物など見繕って時間を潰す。安いLEDライトを試しに買う。件の板の位置固定用の両面吸盤も調達。
少し外に出て空腹を満たすと、ほど良い時間。品を受けとってから、もう少し板面を小さくしてもらえば良かったと気付く。敗北風味。
帰りの電車では疲れがでて、気持ち良く寝てしまう。ぼちぼち目覚めると、そろそろ最寄り駅。駅を出ると、雨はほぼやんでいた。明日は晴れるだろうかと思いながら、帰宅。
ちなみにリンクは丹下桜のあれこれの部分宛ッス。
最終兵器彼女が予想通りのやり方で話をリリース。これ以外の終わりようなどない(というか、ずっとそういうふうにやってきた)が、あちこち荒れるだろうなぁ。
それにしたって小学館は本当に作者に好き勝手やらせるところであるなぁ、と再確認。
先日購入したアルミ板を背負って出社。あつらえたような(*1)見事さで、バッチリと16ポートハブを吊すことに成功。早速8ポートハブx2の環境から移行。アクセスしやすいし、邪魔にならないし、これなら量産してもいいかもー、とかいう話に。
そこから机の配線用の穴(下から電源ケーブルとか通すために空いてる)に、5ポートハブぐらいなら入りそうだという話をして、思い余って部材を家探しすることに。あれこれ候補をめぐった挙げ句、ゴミになりかけてた梱包用のビニルロープで支え受けるような形にしてみると、奇麗にハマる。いいかもしれない、と感心しあって本業に戻る。
(*1)ちゃんと寸法計ったのだから、あたりまえ
_我らの好き勝手で世界は幸福になるのであって、好き勝手の理由に関わらず世界は幸福になる。もちろん衝突も(それに伴う不幸も)起こるだろうけれど、ほんとうに幸福になろうと思っているならそれだって回避できるはずだ。それとも自分の信じるところの正義だなんてものを貫こうとしてたりしないかい?
_ところで一つ見落とすべきでないことは、今の世界を動かしてるモデルがひどく巨大な馬鹿げた自転車だってこと。新天地を絶対的に必要とし、利益は常に拡大し続けるなんてモデル、熱力学的に間違ってるとは思わないか?
_世の中ビジネスモデルでしか考えないのも間違ってるし、知的好奇心でしか考えないのも間違ってる。お金儲けにしか興味がないのも倒錯だし、知的側面にしか興味が向かないのも倒錯。だったら100年先のことしか考えないのも倒錯で、明日の食いぶちしか頭にないのも倒錯かい?。
_確かに自分では作れないかもしれない。けど、「Linusの法則」は言ってる。「目玉の数さえ十分あれば、どんなバグも深刻ではない」と。広い見方をするならば、「望む機能がない」のだってバグみたいなものだ。見つけた問題を理解するのは別の人で、問題を見つけることの方が難しい。せっかく見つけた問題をふいにしているのは誰のせい?
_我らの好き勝手で世界は幸福になるのであって、好き勝手の理由に関わらず世界は幸福になる。たとえ自分の力だけで世界を幸福にできなくたって、誰かが幸福を考えるきっかけになれれば世界は幸福に向かって回り出す。足りないのはきっと踏み出す勇気。
_かく言うこれが倒錯だってことはわかってるけど、ときには倒錯だって必要だ。信じ難い程に偏った熱気。それだけが革命の礎になる。革命なんていらないって? 動力がなきゃ車輪はいつか止まってしまうぜ?
_枷とはそれを枷であると思うから枷なのであって、それを踏み台と考えるなら飛躍の礎と見ることもできる。小説は現実に比べて実に貧弱な媒体であるが、小説で表現される物語とは現実を簡略化した何かではない。
同じことが音楽やら絵画やら映画やらにも言える。ゲームにも言える。ただゲームはひどく複雑であり、しかもまだまだ利用の技術が確立していない分野であるというだけだろう。
それを探しては回りから騒ぎ立てて気付かせたい、というのがゲーム評論というものに望まれる立ち位置の一つであることは、知りおき願いたいところである。
_ABCの関係においていうならば、GPMのアプローチとは、BがAの力を借りて(あるいは、AがBに触れることにより)Cを生産する、というものである。A+B = A + BCという不思議な式がそこでは成立する。
というか、その式が成立してしまうことを大前提としているアプローチであり、根本的にゲームが好きでなければこんな発想は産まれない。言うなれば、ゲームが好き過ぎた罰すら好きだった結果の産物であろう。
_ところでAIRはゲームの限界に絶望などしていないと思うのである。AIRというのは、ひどく現実的に、ADV/ノベル形式のゲームというものの限界を見据えた上で、物語を表現するときにそれを利用した、というものでしかない。あくまでも物語が主であり、ゲーム、及びゲームの限界は手段でしかない。物語の表現に絞って考えるなら、AIRは見事にそれを成し得ているとも言える。物語が好き過ぎた挙げ句、ゲームが好き過ぎた罰をもダシに使ってしまったと言えるのではないか。
_KtFにおいては、果たして本当に作者がゲームが好きなのかすら怪しくなる。なんというか、ゲームが好き過ぎた罰ではなくて、あらゆるものが好き過ぎた罰の、ゲームに関わる部分をうまいこと利用してしまったような感を受けるのである。その感に、全体を流れる衒学趣味からくる錯覚が含まれていることは否定しないが、しかしゲームに対する(いい意味での)関心の弱さがにじみ出ているように思う。
_ときに、KtFと本来対比させるべきゲームは断固としてPrismaticallizationであると主張してみよう。この二つ、あれこれと相違は見出せるのだが、なぜか似たような印象を持ち、それでいながらぜんぜん別物であったりするのだ。というのはあくまで主観だが、ともかくこれをこねくり回してみる作業はゲームが好き過ぎる一個人にとっては結構面白い作業かもしれない。
_ところでこの文、「〜が好き過ぎた」の「〜」の部分を女性の名前に置き換えてみると非常に頭が悪いことになる。むしろ理解の手助けにはなるかもしれないが、不謹慎だ。いや、世の中そんなもんかもしれんのだが。