Whiteのふりーとーく

2001年9月前半

About this Page |過去分一覧


原則匿名で公開・個人情報は送られません。必要に応じ御署名/非公開希望をお書き添え下さい。


_ 掲示板:YaPW 旧掲示板 SMIL Boston日本語訳(頓座)



9.2

@

昨日は仕事の打合せで青山あたりへ。話自体は午前中で終って、ネットワーク作業している部隊を置き去りにしてふらふらと街へ。246号線沿いに、渋谷方面へ歩いてみる。

最近のお気に入りはバイク(原動機付、無の両方)を眺めながらのお散歩だったり。

渋谷から銀座線で末広町へ出て、そこから岩本町駅まで歩く。当然寄り道しつつ。途中で大学の後輩に合い、ちょいと会話してみたり。

ちょこちょこと買物をして、帰還。

@

理屈では、psutilsでできる作業です>面付け。WindowsとかMac側でPostScriptを吐く時にADSC(エラーが少なくなるよう最適化)で出力すること、とかがポイントでしょうか。でないとpsutilsで処理できません。

中綴じならpsbookでサクっとできてしまいます。平綴じだと、psnupでいけるでしょうか。最悪、pstopsであれこれテストして最適なパラメータ探せばなんとかなるはず。

いじょ、あんまり役に立ってないけど、一応メモとして。


9.3

@

土曜日に訪問して頂いてきた資料と格闘。今日は絶対にコーディングしないと心に誓って、主に紙ベースで分析。世の中はコンピュータに都合が良くない程度に混沌であることを再認識し、問題の落しどころをひたすら考える。

考えても考えても落しどころは見つからない。憔悴する。

それでも頑張って、糸口の糸口ぐらいなものを見つけて本日終了。


9.4

@目標設定

資料と格闘、もといデータベース再設計の続き。とりあえず当座の仕事をつなぎの仕事と認識し、別途ましなものを作る提案をしていく方向で心を固める。

一点決意をすると突破口が見えてくる。紙ベース、既存システム、それぞれでのデータの扱われ方を手元の資料からひたすら眺め、データの扱いを極力シンプルにしようと考える。いくつか方針を定めてみる。技術者として今回は譲れないラインを固めてみる。

……どうせそう長くないうちに捨てられるシステムだ。だからこそ、今回やるべきことは動くものを作ることではなく、動くものの作り方を確立させることだ。似たような仕事を続けるなら経験は役に立つ。ワークフローを確立できるならそれをパッケージとして売ることも可能かもしれない。

次のミーティングまでに、なにをしようとしてるかを、素人さんにもわかるように説明できるようにしたい。難しいことだけれど、いいもののために。


9.5

@PDFを面付け。

ああ、なるほど

一応そのようなプラグインのパッケージソフトはいくつか存在してるみたいです。Colloco ProとかQI+とか。その手のものにしてはお値段手頃だし。んでも、プラグインでは印刷屋でその場で面付けして〜とかは無理ですな。

あとは、AdobePS8.6に製本印刷の機能があるなんて情報も転がってたり。同様にRIPレベルで面付けできる、ってケースもそれなりにあるようです。

ところでWebぐるぐるしていて手書きPDF入門なんてのにも遭遇してみたり。いや、次の遊び対象にいいかな、なんて思うので。理屈的にはpstopsみたいなフィルタを作ることは可能なように思うし。

@

ということで、気になってしまったものは仕方なく、手書きPDF入門を読んでPDFのお勉強。いや、非常にいいページです。PDFの基本概念がよくわかります。

ちうことで、いーかげんにPDFのリファレンス情報を生成するPerlなスクリプトを書いてみたり。日本語の通るa2pdfぐらいだったら、簡単に作れるかしらん。


9.6

@

ふと思い立っておうちLinux君の設定をふにふに。/etc/X11/wdm/wdm-config.in を書き換えて、背景をVineLinux2.1.5のデフォルトからNavy一色に。でもって試しに会社からVNCで接続。背景がグラデーションだった状態に比べ、確実にレスポンスアップ。TightVNCのtightエンコーディング + ssh圧縮で、ローカルで動かすVMwareよりは快適に動作。

実際かなり使えます。twm系の殺風景なWindow Managerでなら、真面目に実用速度って感じ。

@物語二想

気になるキーワードが並んでるので反応。メッセージのトンネリングも兼ねて。

_少年の側からの恋愛的ジュブナイル話の基本って、"Only you forever" だと思うのですよ。少年漫画的に燃える話ってたいていそんな感じなんで。でもって物語としては、その幻想が様々な理由で崩れようとする。崩れようとしたときに、どんなふうに髪振り乱して血吐度を吐いて闘って、その結果としてどうなるか、って感じになると思うのです。幻想を実現させてしまうにせよ、夢敗れて立ち上がるにせよ。

_ところでノスタルジーというのはいつの時代も作品分析に必ずと言っていいほど使われるキーワードなんでないかという気もします。なんでかって? その時代のクリエイターは、昔は夢に心躍らせる少年少女だったのですから。そうでなくても、その人の作るものにはその人の歴史がのしかかるものだし。


9.7

@

ロクにやってもないのに言うのは何ですが、悪いのはシナリオの取捨選択できなかった責任者だと思ったり思わなかったり。


9.10

@

ふと思い立って、久しぶりにSMIL関連の現状を追ってみたり。

なにげにSMIL2.0が勧告(Recommendation)になってたりするのね。邦訳は存在してないみたいな感じだし、CVSで公開翻訳レポジトリでも立ててみようかしらん、っちうことで準備開始〜。


9.11

@興味の理由

SFがどうとか言っていたのはHello,world. に対してであって、BITTERSWEET FOOLSについてではありません。>雪駄さん

正直キャラ絵にはあんまり魅力がないが、遠景には力のある絵師を使って、果たしてどういうマルチレイヤ表現を出してくるものか――そんなあたりに興味があったので購入はしました。まだやってません(--;


9.12

@憎悪の結実

ともかく、否が応でも時代は動く。後世からみたとき、この一撃こそが21世紀の幕開けであるのかもしれない。

@お仕事中。

仕事中です。と書いてるこの瞬間は当然息抜き中ですが。ともかくいろいろ切羽詰まってきて、納期目前にして(先方の都合で)まだ仕様が固まり切らんという非道な事態だったりもするのですが、どうとでも対応できるように半ばモックアップめいたものをガツガツと作ってます。むしろ作り方をつくるつもりで作ってます。インラインの詳細なドキュメント萌え。むしろ個人的にはPODとか憶えるべきでしょうか? それともWEB?

_設計方針としてはデータ構造としてのクラスを作り、それに合わせて適切なリレーショナルDBのスキーマを作ると言うような感じです。両者のパラダイム/構造の差は同期取るときのメソッドに喰わせるという、処理系に厳しい考え方。端的に言えば、C的な構造体の裏にRDBMS置くためにクラス化、っちう感じ。

まだまだこれからいくつもクラスつくってDB作らなきゃいけません。作り方はまとめ上げてしまうことになった(*1)んでさしたる苦労でもないんですが。


(*1)先方からの返答の待ち時間長くて、そうせざるを得なかった


9.13

@

一昨日のこと。同居人と主に水夏の構造について話す。ちなみに俺様は未プレイのまま(--;

話の振り方としては、私の方がようやく「ブギーポップは笑わない」を読んだので、それと対比させながら。従って、両方についてのネタバレ含む

それぞれ主題がバラバラな方向を向き、でありながら緩やかに連結する物語の構成法。たいていはあるギミックを用意し、その周辺に起こる複数の物語を並べることで、連続して眺めた時にギミックを浮き上がらせるという手法。終章が名付けの物語であるのならば、それ以前の(一見無関係な)各篇は「名」にまつわる物語であるべきである。最悪、そこにおいては「名」が無いこと、あるいは既に付与された「名」に特別な意味があることを提示できなければならないであろう(意味を明示する必要はない。ただ、意味が「ある」ことだけ伝われば十分である)。 ツカミの重要性。とかくギミックに読者が魅せられなければ、読者は連作を読んでくれない。

ブギーポップは両方の点で上手い。とかく読者は「ブギーポップ」という存在に魅せられる(ように描かれている)し、その正体はわかっていながらまったくわからぬままに物語は幕を降ろしてしまう。けれども物語としてはきちんと収束し、満足も得られる。これは多分に、「ブギーポップの周辺で起きた物語」にこそ主眼が置かれているからかもしれないが。

対して、そのような(周辺にこそ主眼を置くような構成)はゲームでは取りにくい。おそらくは、ゲームという形式が、読者の能動を呼び起こすもの、彼方よりは此方のものとして機能するものであるがゆえに。であれば、やはりゲームにおける物語はより収束するべきものであろう。少なくとも、収束的な結末は用意されるべきである。利得というゲーム本来の成立用件を満たすためにも(*1)


(*1)もちろん、芸術としてはそうでないものをもって芸術と成すこともできる。無論、多くの客に嫌われる恐れがあるわけだが。

@

今の仕事はなにげに伸び伸びになっていて、途中で他の人に引き継いで私は別の仕事にかからねばならない。こうなると問題となるのは引き継ぎである。引き継ぐ相手は多分差し向かいの席に座るであろうから、いざとなれば聞いてもらえればいいのだが、それは面倒である。ここは正しく無精を発揮すべく文芸的プログラミングだ!――ということで、文芸的プログラミング実践中。

単にコメント文がやたら多いだけ、ではあるのですが、いちいち留意点とか設計思想とか書いていくのが妙に気持ちいいです。癖になるかも。


9.14

@発想浮遊。

いつぞやのトンチキなアレの続き。主にここ数日に思いついたことなど。

_ゲーム序盤は、一本道をひたすら辿らせて、インターフェースの基本的な使い方を憶えてもらう。どんなLook&Feelになるかは知らないが、選べるところ(=閲覧できるシーン)は目立って表示されるべきだ。

そのうち目立つところが2つ(以上)に増えたりする。するってーと「選択して閲覧」ということをプレイヤーが憶える。

あるいは、どこかを選んで閲覧したあと、選択画面に戻った時に、明示的に変化を示すのも良い。たとえば、「今まで見ていたシーンの光が消灯し、そこから波紋が広がり、別のどこかのシーンに収束して点灯する」なんて感じ。

まったく変化がなく、同じところしか見れない、という場面も必要だ。で、出てくるものが微妙に違ったりする。これでもって、「一つのシーンが多くの相から出来ている」ことがわかる。

ところでユーザーフレンドリーにするには選べるシーンに注釈が出たりするとイイ。「空を見る歌恵」みたいな感じで――そしてもちろん、見えるものは微妙に変わったりする。

そのうちに突然「どこも光ってない」という状態を出してみたりするのもいい。で、ポインタを適当なところに動かすと光ってみたりするわけだ。

_で、こういった基本ルールを把握させたあたりで、突然「できること(=選択できる閲覧可能シーン)」を増やしてみる。できれば物語内の出来事と連動させる形で。そしてここから先は、製作者もどうなってるかわからないぐらい複雑な系になってることが望ましい。もちろん、物語面での論理性は維持したままで、であるが。


御意見・御感想の宛先white@niu.ne.jp