2001-07-20
NFSをautofsでもって自動マウントさせているんだけど，なぜか特定のマシンだけ，マウントするのに５分近くかかる。いろいろ格闘してみた結果，けっきょく，portmapをインストールしていなかったのが原因だったようで。よくわかんないけど，NIS関連が入ってないとうまく動かないものらしい。
いつもcustomインストールでギリギリまで攻めてたのが裏目にでたなあ，とおもった。Windowsを入れるときとかも，ペイントブラシやワードパッドを外してしまうぐらい，外し好きなんで。
2001-07-21
あいかわらずGT3をプレイ。GTモードではGT-oneが手に入ったので，アマチュアリーグではほぼ無敵状態。なので，ひさしぶりにアーケードモードにもどって，ノーマルモードを全クリアしてみたり。
たいていのゲームは，２週間ぐらいプレイすれば飽きてきて，ふだんの趣味の時間へと戻れるんだけど，GT3は下手に長続きしてしまって，自由な時間をほとんど消費してしまっているのが，うれしいやら悲しいやら。
ノーマルモードもクリアしたことだし，そろそろ封印しようかとおもった。ほんとうは，もうちょっと遊べそうなんだけど……。いいかげん，cygwin布教計画を進行させなければならんのです。
2001-07-22
日曜の夕方に，おもむろに出勤。週末の夜に家にいたところで，どうせ無為な時間を過ごしてすまうってんで，夕方に出勤することがよくある。まあ，最近は特にいそがしいし。
設計的な行詰まりを感じながらも，じわじわとプログラミング。わりと優柔不断な性格なので，何回も繰り返し設計しなおすのがいつものパターン。いつまでもこんなやりかたじゃだめだよなあ，っておもうんだけど，じわじわと設計が強固になっていく感覚はわりとカタルシスかもしれない。
最近書き直したところで面白かったのが，Makefile。むかしから，Makefileの構文っていまいちアバウトですっきりしないなあ，っておもっていたんだけど，GNUのmakeはかなり拡張が効いていて，わりと読みやすい書き方ができるようになっていた。
むかしはmakeにもいろんな派生があって，互換性に気をつかっていたこともあったけど，いまではGNU以外はほとんどIDE(統合環境)だから，GNU以外のmakeに気をつかうこともないでしょ……，ってことで，がちがちにGNU make式に書き換えてみた。
2001-07-23
今日はなんか猛烈に暑い。昨日も日中はこんくらい暑かったのかもしれない。会社に泊まったり，へんな時間帯に出勤したりすることが多いので，いまいち安定した季節感がつかめないでいるような気がする。
こんなに暑いのに，昼食にはなぜかカレーを食べた。暑いのと辛いのとで汗がだらだら出てくる。今朝は泊まりだったのに……。昼からさっそくダメな気分に。
午後はダメな気分ながらもプログラミング。環境をバージョンアップしてからというもの，デバッガ(gdb)の調子がよくてきもちいい。
CUIベースのgdbは見ためが地味なんで嫌われることも多いけど，ひとたび操作に慣れれば，これはこれでかなり使いやすい。短縮コマンドやTAB補完など，CUIベースを意識したインタフェースが装備されているので，慣れれば速いってのはあたりまえなのかもしれない。データの検査なんかはGUIのほうがいいとおもうけどね。
2001-07-24
やっぱ今日も暑い。なんか，今年の夏はずっとこんな調子なのかとおもうと気が滅入る。暑いのは嫌いじゃないけど，今年の夏はどうやらずっと休めなさそうだし，どうせ仕事漬けなんだったら，過ごしやすい冷夏のほうがいいんだけどな。そういえば今朝風呂入ったときに，首筋がひりひりしてたのをおもいだした。そんなに日ざしが強いのかな。東京の夏の昼間は，もんやりとかすみがかかったような色をしていて，ギラつくような日ざしの強さってのを感じない気がする。
なにげにPS2Linuxでxmmsをコンパイル。いままではmadplayをコマンドラインで使ってたんだけど，ちょっと色気を出してみようかとおもって，ダウンロードしてみた。とりあえず，'./configure; make; make install'一発でOK。動作も問題なし。負荷はだいたい平均で10%ぐらい。ちなみにmadplayもおなじぐらいだった。PS2のSPU2の仕様のせいで，44kHz->48kHz変換がCPUに入っているはずなので，そこをなんとかすれば少しは軽くなるとおもう。
xmms - http://www.xmms.org/
mad - http://www.mars.org/home/rob/proj/mpeg/
2001-07-25
今日も，古いところをぱらぱらと書き直しつつ，拡張を加えていくようなプログラミング。むかし作ったアクセス関数に，最近知ったpure関数属性ってのをばしばし付け加えてみたりした。付け加えたところで，そんなに変わるもんでもないとおもうけどね。
pure関数属性ってのは，gccの関数属性のひとつで，「返値を得る以外になんの効果もなく，引数とメモリの参照しか行わない関数」をあらわす。たいていのアクセス関数は，どっかの構造体の中身を覗いてその値を返すだけなんで，この関数属性が適用できる。こういった関数属性をこまめに付けておくと，最適化にわずかながらも影響が出るみたいだ。
ただ，これらの修飾的な関数属性は，基本的に自己申告制なんで，属性と実際の動作に食い違いがあったりすると，恐ろしいバグのもとになるんじゃないかって気もする。どうしたもんだか。
ちなみに，メモリの参照さえも行わず，完全に引数のみから返り値が決まるような関数にはconst関数属性が適用できる。数学関数なんかがこの適用範囲だろう。これはわりと最適化に影響が出そうな気がするので，こまめに付けるようにしたほうがいいのかもしれない。
関数属性でほかによく使うものには，noreturn属性やunused属性なんかがある。どっちも名前どおりの属性で，おもに警告を抑えるのに使う。
よく，海外のソフトなんかで，アーカイブのなかに'file_id.diz'って名前のファイルが入れられていることがある(最近は見かけなくなってきたけど)。たいていその中にはアーカイブの概要みたいなものが書いてあるんだけど，それがなんで'file_id.diz'なのかずっと不思議におもっていた。
というか，不思議におもっていたことを思い出したので，とっさに調べてみた。
http://www.everything2.com/index.pl?node=file_id.diz
どうやら，むかしのBBSサイトの仕様のなごりってことらしい。正しいfile_id.dizは44文字以内で書くものなんだそうで。次からは気を付けてみようかな，とおもった。
2001-07-26
今日はわりと涼しい日。毎日こんな感じだとたすかるんだけど。
サーバマシンのLinuxを入れ換えた。そのマシンには今までRedhat Linux 5.2が入れてあって，まわりのマシンはほとんどがRedhat Linux 7.0に移行していたんだけど，さすがにここまで世代がずれてるとlibcのバージョンが違くなってたりして，環境の共存がやりにくくなってくるのだ。
インストールにちょっとてこずったけど(NICをなかなか認識してくれなかったのだ……めんどくさ)，これですっきりしたマシン構成になったので，よしとしよう。OSのバージョンが一致していると，設定とかを使いまわせるので便利なのだ。ていうか，ふつうはこうするもんなんだろうけど。あたらしいもの好きな人が多いんで。
またいつもの調子で，むかしのコードにげしげしと直しを入れていたら，プリプロセッサマクロをヘビーに使っている箇所が出てきた。これはいただけない……。
これは，むかしよく使っていた技で，
↑こんなかんじのヘッダファイル(foobar.h)を作っておいて，
↑インデクス列を作ったり，
↑テーブルを作ったりするわけ。
まあ，これはこれでそこそこ便利ではあるんだけど，プリプロセッサのマクロってそんなに高機能でもないので，ちょっと凝ったことをやろうとおもうと，とんでもなく複雑なマクロになってしまったり，むりやりな書式になってしまったりと，あまりいいことがない。
最近では，この手のマクロはほとんどPythonを使って自動生成する方法に切り替えている。Pythonでこの手のフィルタを書くのはそんなにむずかしいことじゃないし，正規表現のおかげで，わりと凝った書式にも柔軟に対応できるようになる。
2001-07-27
最近，ゲームのスクリプト制御についてちょっと考えることがある。
どんな内容のゲームでも，よっぽど小規模じゃないかぎりは，スクリプト制御の導入を一度は考えることがあるとおもう。実は，このスクリプト制御の導入ってのは意外と重要な問題で，これを中途半端に見切ってしまったがばかりに，最終的に多くの余計な労力を費してしまうことがある。ぼくも実際に，そういう現場を何度か目にしたことがあるし，そういう経験談も多く耳にしてきた。
とりあえず，なぜスクリプト制御が必要とされるのか，その動機を整理してみようとおもう。
第１の動機は，ゲーム制御の設計／実装の作業をプログラマの外に出すという目的だ。RPGやアドベンチャーゲームなんかでは，イベント制御やNPC制御，UI制御やフラグ管理など，そういった雑多な処理が大量に発生するんだけど，これらすべてをプログラマがプログラム内で実装するってわけにはいかないので，これらの仕事をデザイナー／プランナーに引き渡すために，スクリプト制御の仕組みが必要になることがある。
第１の動機で焦点になるのは，どの程度までスクリプトによって制御させるか，また，スクリプトの仕様はどのようなものにするか，というところだとおもう。スクリプトをとことん汎用的なものにして，ゲームのほとんどをスクリプト制御にしてしまうこともあるし，データにほんのちょっと制御コマンドが混じった程度のもので済ませてしまうこともある。
ここで落し穴になりやすいのが，非プログラマな人にプログラマ的センスを期待してはいけないということ。文法とかは勉強してもらえばなんとかなるんだけど，ロジックの構築ってのは意外とセンスを要する作業で，非プログラマな人にとって障害となりやすい。だから，スクリプトを汎用的な仕様にすればするほど，スクリプト担当者は逆にとまどってしまうだろう。「どんな処理も，どんな風にも組める」ってのはむしろ不都合で，「限られた処理を，定型にしか書けない」ほうがかえって効率がいいのだ。
結局，スクリプトを汎用的にすればするほど，プログラマに仕事が返ってくる率は高くなる，ってのが僕の意見。第１の動機では，スクリプトはシンプルで限定的な設計のほうがいいようだ。
……長くなってきたので，続きは明日以降にしようかな。
2001-07-28
土曜日の朝は会社でお目ざめ。ていうか昼だけど。さっき食べたマックが腹にもたれる……。
昨日のつづき。
第２の動機は，ゲーム制御の手段をプログラムの外に出すという目的。第１の動機にもあったように，RPGやアドベンチャーゲームなんかには雑多な処理がたくさんあるんだけど，これらの制御をプログラム内に持ってしまうと，ちょっとした仕様を変更するにもプログラムをリビルドしなくてはならなくなってしまう。しかも，変更した結果をチェックするにはプログラムを再起動させなければいけない。開発も終盤になって，ある程度プログラムが大きくなった段階では，これはだいぶかったるい作業になるだろう。
このように仕様変更にかかるコストが上がってくると，開発者の変更に対する気力が失われてきてしまう。まあ，そんなに頻繁に変更をかけるほうにも問題はあるんだけど，ある程度の思考錯誤ってのはやっぱり必要なわけだし，仕様にバグがあった場合なんかは修正が必須になるわけだから，変更のコストが高いってのは深刻な問題だと言えるとおもう。
第２の動機で重要なのは，制御の手段がプログラムの外に出ることだから，スクリプトの汎用性にこだわる必要はあまりなさそうだ。
スクリプト言語の実装ってのは意外と難しいもので，ちゃんと汎用性を備えたものを作るには相当の労力を要する。ここで変に凝ったものを作ろうとすると，多くの予想外の労力と時間を費してしまうことになる。
しかも，スクリプトを汎用的にすることは，同時に，スクリプトにバグを混入させる可能性を高めていることにもなる。しかも，そのスクリプト言語に限られたデバッグ方法しか用意されなかったような場合，デバッグ作業は困難を極めることになるだろう。ていうか，なります。
それでも，もろもろの事情から汎用性を強めたい，なんて場合には，既存のスクリプト言語を使うのが無難だとおもう。ゲームの制御みたいな用途にあった，組み込み用にデザインされた小規模な言語がいくつかあるので，それをまず試してみるのがいいだろう。
僕がいまのところ目を付けているのは，
lua - http://www.tecgraf.puc-rio.br/lua/
small - http://www.compuphase.com/small.htm
の２つ。smallはまだちょっと試してみてないので，いつか実験してみないと。
2001-07-29
昼間，寝ているときに宅急便が届く。REASONの日本語マニュアルとアップデートCDだった。いらないけど，くれるもんならもらっとく。そしてまた寝る。けっきょく，起きたのは夕方。いつも休日はこんなペース。
ゲーセンでプロギアとナイトレイドをプレイ。プロギアはあいかわらずヘタ。ナイトレイドは，なんとなくおもしろさがわかってきたかも。古めかしいデザインでだいぶ損をしているような気がする。なんていうか，バラデュークとか，アークゾーンとか，そこらへんのノリ。ちょっとね。
日記の整形用スクリプトをしこしこと書く。家でプログラミングするのはちょっと久しぶりだった。いい感じでできてきたけど，まだトップページができてないなあ。まあ，適当に，適当に。
2001-07-30
ちらりとsmallのドキュメントを眺める。どうやら，ただのスクリプト言語ではなくて，コンパイラにバイトコードを吐かせて，それをバーチャルマシンで実行するって仕組みらしい。
ちょうど，スクリプト言語よりもバーチャルマシンかなあ，とか，うすうすおもっていたところなので，渡りに船って感じだ。
僕のバーチャルマシン構想としては，Wabaを参考にして簡易JavaVMをつくるとか，Quake3をまねしてlccにバーチャルマシンコードを吐かせるとか，そういうのを考えていたんだけど，うまくいけば，smallがそれらの代替になってくれるかもしれない。
で，とりあえずsmallをコンパイルしてみるも，一発では通らず。Win32がメインターゲットってことで，GCC環境についてはあまり真面目に取り組んでないみたい。なげやりなmakefileが付いてるだけだったし……。
まあ，しばらく付き合ってみようかな。
2001-07-31
最近，日本語キーボードをむりやり英語配列にマップして使用するという技を体得した。単純な技だけど，これがなかなかおもしろくて，おもわずキーを見てしまうと間違ったキーを押してしまうので，わざとキーを見ないようにして打たないといけないのだ。まさに心眼で見切るってやつです。
この技を極めれば，英語配列と日本語配列の絶妙な違いに二度と惑わされることはなくなるだろう。
（英語配列を使ってるひとならわかるとおもうけど，括弧が横に１個ずれてたりとか，コロンがセミコロンになったりとか，わざとやってんじゃないかこいつってぐらいの絶妙な違いっぷりなのだ）
なんていうか，人として一段階進化した感じだ（ダメな方向に）。