先日、図書館で借りた本に「プログラミング言語Lisp 入門からマルチメディアまで」と言うのがありまして～・・Macで動くCommonLispを使ってる感じ？それでネットにつないだり音楽を再生したりグラフィックを表示したりする方法が書かれているので、いつか参考になるかも・・
旧ASCIIから出てた本ですね・・・相当古い。
確かにCommon Lispに付いての本なんだけど、多分あまり役に立たないんじゃないか、と・・・・・・。Macintosh Common Lispと言う商用製品ベッタリだし、本に貼られてる写真見てみれば分かるけど、Mac OS8とかMac OS9用とかでしょ(笑)?OS X以前の本なんだよな(笑)。
だから今だと・・・ねぇ。
ちなみに、商用製品のMacintosh Common Lispからフォークしたオープンソース版がClozure Common Lispと言う処理系なんですが、今はWindows版もあるのかな・・・多分。
商用製品からフォークした事もあって、最速と言われるCMUCLやSBCLといい勝負で、多分IDE込みの実装を目指してると思う・・・・・・Mac OS X上でね。
だから、多分ノウハウ的にはWindows上だと厳しい事になるんじゃないか。
まずはRacketの標準出力を使って表示をするので、画面を書き換える方法を作らんといかん。単純に「改行」を10回か15回か繰り返して画面をスクロールさせてしまうことで実現しようというのだけど・・たったこんだけのことが簡単には実現できない(-_-;) Pythonだったら屁を出すよりも簡単なのに！
ちょっとこれ以降は難しいかなぁ。
「何故難しいのか」ちと説明していく。
ハッキリ言うと別にRacketのせいじゃないんだ。
昔のパソコンだと構成が単純だし、シングルタスクだったりしたせいで、プログラミング言語(特にBASIC?)で画面制御を行うのは比較的簡単でした。何故なら、パソコンも一社毎に一つの独自規格のブツを出すのがフツーだったんで、他の会社のパソコンの存在さえ考えなければどのようにしても出来たわけです。
一方、UNIXなんかは「特定のハードウェア」を想定してなかった。そんなわけで、「大まかにどの機械でもこれは持ってる」と言うんで、標準入出力ってのを当時のレベルで定義したわけですね。
ところが、そのせいで、UNIXで「どの端末でも派手に☓☓をしたい」ってのが出来なかった。この「派手に☓☓」の中身が「星田さんがやりたい」事です。例えば端末画面の逐次更新、とかですね。コマンドの入出力を順次スクロール、なんつーのはどの機械でも出来るけど、画面をフィールドに見立てて例えばキャラを動かしてアニメーションする、なんつーのは「標準入出力」前提のUNIXじゃ出来ない事だったんですよ。
そんな中、1980年に登場したのがcursesってライブラリで、これで初めてUNIX上でキー入力に従ってキャラが端末上を走り回るようなプログラムを作ることが出来た。
そう、前紹介したRogueってゲームはこのcursesを用いて作ったブツなんです。
ちなみに、このcursesってのは、「ライブラリ」って言えば聞こえがいいけど、原理的には一種のAPIで、ハードウェアによる入出力部分、具体的にはハードウェアメーカーから提供されてる各機種の別々のドライバを統一インターフェースでラップしてるだけです。UNIXで書かれてるわけじゃない。
いずれにせよ、この時点で、初めてUNIXの端末でキーを叩いて自由にキャラを動かせるようになった・・・それで、このテのプログラムをUNIXで作るにはcursesを利用する、と言うノウハウが出来上がったわけです。現在でもこれは変わらない。AT&T謹製から代わりGNUのncursesを使うようになったくらい、ですね(※)。
一方、当時はまだ、ある意味PCの方が優秀だった。UNIXみたいに端末に縛られる必要もなかったし、描画も可能。UNIXと違って「移植性」を考慮する必要がなかったからメーカーから提供されるツールで入出力を直接制御出来た。
しかもシングルタスクだったんで、パソコンのパワーを自分で書いたプログラムに全フリする事が可能だったわけですが・・・・・・。
Apple Macintoshが民生機で初めて「プログラマに全てを委ねず」APIでプログラミングに制限を持たせたマシンである。スティーブ・ジョブズは「UIはOSに従って統一的であるべきだ」と言う哲学を持っていた為、「プログラマに色々と勝手にやらせない」仕組みとしてこれを設計したが、一方、意外だが当時の、特にゲームプログラマはこのMacの思想を嫌い、MacのソフトがDOSのソフト程数が揃わない遠因となる。この当時は民生機の商業プログラマは「何でも自分で自由にプログラミング出来る」環境を愛しており、この習慣は、ぶっちゃけ、Windows 95が出るまで続くことになる。反面、Windows 95でGUIが市民権を得て、「面倒臭いGUIプログラミング」を緩和するAPIというやり方に、やっとプログラマ側が従う構図が出来るのである(言い換えると、ここに来て初めて「GUIと言う面倒臭さ」が目の前に具現化した、のだ)。
ところが、Windows時代(具体的にはNT系がポピュラーになってから)に入って状況が変わります。
圧倒的に違うのがここで(民生機初じゃないけど)マルチタスクに変わった、と言うこと。つまり、「なんかのソフトがパソコンの全リソースを専有する」って状態じゃなくなった事。
仮にマルチタスクでなんかのソフトがパソコンのリソースを全部専有して機械の入出力を全部専有するようになれば困るわけですよ。
ここに来て、70年代のUNIXに於ける問題点がWindowsに出てきたわけです。
昔は端末を起動すればパソコン全部が端末に専有された。一方、Windows以降だと端末はあくまでWindowsで走る数多くのソフトのうちの一つじゃないとならない。
そんなワケで、MicrosoftがWindows用に設計したいわゆるDOS窓は、「最小限のコマンドプロンプトとしての機能を備えた」1ソフトとして設計される事となる・・・・・・いや、これがある種結果マズかったわけだ(笑)。
そう、実はUNIXでの端末に比べると、単にDOS窓のパワーがねぇんだな(笑)。あくまでDOSコマンドを走らせる「だけ」の前提で設計されてるだけで、GUIの時代、端末で「あれこれやりたい」ってニーズが出るたぁ思ってなかった、と言うか(笑)。懐古趣味程度の前提でしか設計してないのです。
とここまで読んできて、
「あれ?でもWindows版のRogueだと自由に自キャラ(@)が動かせて、画面も固定されてるんじゃない?」
と不思議に思うかもしれません。
種を明かすと、実はこのバージョン、DOS窓を利用していない。
要するに実は「専用端末」を別途プログラミングしてるだけ、なんです。つまり、CLIアプリに見せかけた厳然たるGUIのソフトなんです。そうじゃないとUNIXの端末を使ったCLIなソフトをWindowsに移植出来ない、と。
このくらい、UNIXの端末利用ソフトとWindowsのDOS窓には機能的に差がありすぎて、下手をすればWindowsだとCLIのプログラムを書くよりGUIで書いた方が簡単な場合がある・・・・・・端末利用前提だとそうなっちゃう可能性があるんですね・・・・・・。
Racketにも端末を直接制御するライブラリがある事はある。chartermと言うライブラリです。
This package could be used to implement a status/management console for a Racket-based server process (perhaps run in GNU Screen or tmux on a server machine, to be detached and reattached from SSH sessions), a lightweight user interface for a systems tool, a command-line REPL, a text editor, creative retro uses of old equipment, and, perhaps most importantly, a Rogue-like application.
このパッケージはRacketベースのサーバープロセス(恐らくSSHセッションから切り離したり再接続してサーバー上のGNU Screenやtmuxを走らせる)向けのステータス/管理コンソールや、システムツール向けの軽量なUI、テキストエディタ、古い機器に見られるレトロな何か、あるいは、多分超重要なRogue-likeみたいなソフトに使われるでしょう。
Windows用Racketでもこのライブラリはインストール可能ですが、生憎、使えない(苦笑)。
ちなみに、RacketでもPythonのpipやRubyのgem、PerlのCPANみたいにインターネット経由のライブラリインストールが可能で、書式はDOS窓から
raco pkg install <ライブラリ名>
としてツールを取ってくる事が出来ます。chartermなら、
raco pkg install charterm
になるんですが。
でも使えない。
It does not run on Microsoft Windows, but terminal emulator and Telnet/SSH programs running on Windows can probably use charterm programs running on a Unix-like.これはMicrosoftのWindowsでは走りませんが、ひょっとしたらターミナルエミュレータかWindowsのTelnet/SSHプログラム上だったらUnix-likeで動くかもしれません。
ま、確証はねぇぞ、と(笑)。
まぁ、この手のプログラム書く人って今どきはUNIX/Linuxベッタリな環境を使ってるかiMac使ってるんで、Windowsまでなかなか手を伸ばしてくんないんですよね。
で、ちと調べてみたんですが・・・要するにDOS窓が貧弱だからダメなんだ、と。で、Windows使ってる層はDOS窓使うか、あるいは尖ってる人はPowerShell使ってるんで、「端末エミュレータ」を新たにWindowsで導入する人ってあんまいないじゃないですか。
で、こういうのを見つけて試してみたんだけど。
軒並みインストール/アンインストールしてchartermが動作すっか調べてはみたんだけど、今んトコ全滅です(笑)。なかなか上手くイカん。
と言うわけで、少なくとも現時点ではWindowsでRogueのような端末プログラムをRacketでは書けません。書くとしたら、やっぱGUIの機能を使って自作端末を作るしかないんじゃないかなぁ。
ちなみに、ホント、ミニコン時代とか、画面更新が無いゲームの方が多かったんですけどね・・・要するにテキストアドベンチャーとか、文字列がスクロールするゲームの方が実際はフツーだったんですよ・・・・・・。
だから、アーケードのゲームとミニコンのゲームってそういう意味ではルーツも表現方法も違っていたわけです。
パソコン黎明期で超有名だったゲーム「スタートレック」。BASICで書かれたゲームでそのため数多く亜流を生み出したが、オリジナルはHP(ヒューレットパッカード)製のミニコンで動くBASIC製のゲームだった。それの亜流の中には「端末の画面更新」を行う商用版などもあったが、基本的には図示はしつつも上部へとスクロールしていくゲームであった。
パソコンの黎明期から80年代後期までDOSで人気があったテキストアドベンチャーゲーム「ZORK」。実はルーツ的には古典的なAI研究の落し胤で、当時の人工知能でのエキスパートシステム作りで培われた手法を一種ダウングレードしてPCに移植して成功した例である。そう、エロゲの遠い祖先は実は人工知能で、この辺のテクニックこそ「実用Common Lisp」に詳しい。当然、文章だらけ、と言う事は端末のスクロールは望むトコである。
ちなみに、Zorkはリメイクされてグラフィックアドベンチャーになり、後にプレイステーションでReturn to Zorkとしてリリースされている。
※: このcursesと言うライブラリがハッカーの遊び場を提供してて、例えば端末版パックマンとか誰得なゲームなんかを生み出している。
こういうフザケたゲームでさえ、WindowsのDOS窓で実装するのは激ムズなのだ。
