星田さんの記事に対するコメント。
Racketで使えて、今後別の言語を使っても応用が利くものということで・・
うん。wxWidgetsは幅広く使われてます。
だから「言語をまたいで使う」には結構良いGUIツールセットになってる。
反面、例えばScheme実装同士、となるとイマイチ信用がおけない(笑)。
例えばGaucheもGUIツールキットがあったと思うんだけど、LinuxベッタリのGTK+ベースだったと思う(※1)。
だから、wxWidgetsを使ったRacketよりも使うのが難しいと思う。そしてそもそもGaucheはクロスプラットフォームを意識した処理系じゃない(※2)。
だから、Windowsでも使えるGUIアプリをScheme系で作りたい、ってなると、現実問題としてはRacket一択になるんじゃないか。歴史的にSchemeは「外部インターフェース」が公式に定義されてこなかった以上(※3)、「Scheme処理系の作成者の好みによって」別々のGUIツールキットを内包するしかない。要するに処理系レベルでは「統一性」なんぞねぇわけだ(※4)。
つまり、「言語間を移動する」にはwxWidgetsはかなり信頼を寄せられる(※5)反面、Scheme実装毎を渡り歩いても、そういう恩恵は請けられないだろう、と言う事だ(ANSI Common Lispと条件は違う)。
なお、今GTK+とか言ったけど、ザックリ言うと、基本的には、wxWidgetsとGTK+の関係ってこういうカンジになってんのね。
つまり、例えばwxWidgetsで一つの関数名で「ある事をしたい」場合、Windows/Linux/Macで「違う名前で同じ機能」のブツを同名で呼び出したり、あるいは似たような機能を組み合わせたモノを同名で呼び出すようにする。引数の違いや順序も「wxWidgetsで作られた関数」からそれぞれのプラットフォームのAPIに合わせたカタチで呼び出す、と。
そうすれば、単一のシステムから各プラットフォーム毎に「同じ名前でプログラムが書ける」と。それが「差異の吸収」って事なわけ。
こういうプログラムをラッパーとか呼んだりするんだけど、wxWidgetsはそういうラッパーなのね。実際に動いてるのは各プラットフォーム毎に「別々のシステム」なんだけど、関数名や引数の数、引数順序を統一させておいた関数を間に挟めば、プラットフォームの差異を気にせんでGUIが出来る、と。そういう「最大公約数的な機能」に纏め上げてるのがwxWidgetsの大まかな仕組みなわけ。
逆に言うと、プラットフォーム毎に備わってる「特殊な機能」は使えない。あくまで相互互換的に動くモノのみ取り出してる、って見方が出来るわけ。細かい事やりたければやっぱレイヤーを降りて難しいトコに突っ込まなアカン、って話になるわけだけど、そういう「大変な事」にツッコんでいく必要性もあんまねぇだろ、って事で、悪くない方針だよね。
そうなんです！tkinter、Pythonの時にちょっとだけいじってみようかと思ったんですが・・なんかCLIよりカッコ悪くない？という印象でした(^_^;)
うん、tcl/tkは汚い(笑)。汚い、っつーか、周りから浮くんだよな(笑)。そういうのを「ルックアンドフィール」とか呼んだりすんだけど、WindowsだろうがLinuxだろうが浮きまくってる。どのプラットフォームでも違和感が半端ない(笑)。
元々、UNIXで発達したプログラミング言語なんだけど、簡易に扱える、って事以上にはメリットはねぇかなぁ。いや、「簡易に扱える」事自体はメリットではあるんだけどね。
こーゆー事も全然知らなかったんですが・・
ちなみに、SHARP X68000もビットプレーン方式だったと思う。
当時の処理速度やデータ転送速度だと、グラディウスみたいなゲームだとビットプレーン方式じゃないと苦しいよね。
ちなみに、「背景画面を複数持てる」ってのもビットプレーン方式の特徴だったと思う。ビットマップ方式のプレステだと、実はファミコンみたいに背景画面が一つしか持てないし、2Dのゲームを移植するのは随分とテクが要ったと思うわ。
多分背景をスクロールさせるんじゃなくって、ポリゴンで背景画面作って・・・とかやってたんじゃねぇのかな。恐らく。
プレステの「グラディウス外伝」。随分と頑張ってるが、元々プレステはこのテのテのゲームは苦手。背景画面を動かす、と言うより、たくさんポリゴン(疑似スプライト)を作ってそいつらを移動させる事で「何とかなってる」ように見せてるんじゃないか知らんけど。
ついでにダメ元でナウシカゲームブックもやらせてみたが「字が小さくて読めない」とのこと。ごもっとも(-_-;)
10歳でしょ?
ゲーム画面としてのブツが小さくて読めない、と言うよか、まだ大人が読む「文庫本サイズでの文章」を読み慣れてねぇんじゃねぇの、って思う。
特に、最近の・・・でもねぇか(笑)、小学校や中学校の「教科書」って僕らの頃と違って大判なんだよな。「大きいサイズの本」に慣れてるから、「小さい文庫本サイズの本」ってフォントの小ささも併せて余計慣れないんだよ、多分。
余談だけど、多分星田さんって元々本読むの得意なんだよ。こういうのって何だろ、遺伝っつーか才能とかあるんだよな。なんだか良く分からんけど。
僕も例えば、昔っから「洋画は吹き替えでは絶対観ない」って思ってたんだけど、小学生の頃からそうだったの。10歳前じゃん?でもスターウォーズとか、オルカとか、それこそマニトウとか(笑)、観に連れて行ってもらって、でも「字幕が嫌だ」って思った事がねぇんだ。
だから字幕読んでたんだよ。んで「誰でもそれが出来る」とか思ってたんだけど、よう考えてみると違うんだよな。知らない漢字が出てきたらどうすんだ、とか読む速さはどうなんだ、とかさ。
何で子供が観に行きたい、とか言う映画とか、わざわざ吹き替えしてんだろ?ってずーっと不思議だったんだけど、良く良く考えてみると俺が異常だったんだわ(笑)。あるいは知らん漢字が出てきてもスルーできる能力があった、とか(笑)。パニクらない。
でさ、多分星田さんもそうなんだろうけど、「自分が出来る事は子供が出来る」ってやっぱ考えちゃダメなんだよな(笑)。
10歳の子供に文庫本サイズのページの「読解」はキツイ(笑)。やっぱ中学生以上になるんじゃないか。だからアドベンチャーゲームとか、ある意味PG13なんだわ(笑)。
んでだな。ナウシカのゲーム。
最初写真使って作る、とか、速攻組み立てる、ってのはなるほど良いアイディアだとは思ったんだけど。
一つ、ゲームのシステムとしては、やっぱ構文解析とか、命令の実行とか足りない部分があって、多分次回作の「ラピュタ」はその辺どうにかせんといけなくなると思う。
実際写真使ったお陰で実装が面倒になる事もあると思うんだよな。
でもテキスト打ち込むのはメンド臭い、と。
そこで、だ。今更なんだけど、ADVの「2つ目」なんでブレイクスルーを。
OCR(Optical Character Reader)って技術があるんだ。光学文字読み込み。
その名の通り、写真データに文字が写ってた場合、それからテキスト情報を読み取る技術ね。
んで、WindowsでもLinuxでも、フリーのOCRソフトとか色々あって、そいつに画像データを喰わせるとテキストデータとか、あるいはワープロデータに変換してくれる。
他にも探してみればいいと思う。「多言語対応」とかなってるヤツなら相当ラクして写真からテキストデータを作れるんじゃないか。
ただ、100％完全に変換可能、って事はない。日本語は特にややこしいんでね(※6)。
反面、「要修正」にせよ、全部自分で打ち込むよかマシだと思う(※7)。
一夜明けて布団から出るか・・となった瞬間にひらめいた。子供でも一緒に楽しめるゲームと言えば・・CLIで桃太郎電鉄みたいなの作れるんじゃないか？ターン最初に例のグラフィック表示で地図と物件の表示を行うようにしてババ抜きの時のサイクルリストでプレイヤーリストを構造体に持たせて回していく・・地元星田周辺を使った超ローカルゲームにしたら内輪ウケくらいは狙えるような気がするなぁ・・次は春休みに帰ってくるので、ラピュタを終えたら挑戦開始しよう！
いいアイディアだと思う。
っつーか、コンピュータ上のビデオゲームの発展の歴史の中で、実は「ボードゲームのビデオゲーム化」って重要なターニングポイントなんだよ。
言っちゃえば、RPGなんかもそうでしょ?「メンツを集めるのが面倒臭い」んで、コンピュータに相手をさせて、ソリティア(※8)を成立させる、ってのが元々の発想なんだわ。
星田さんが好きな(確か?)「大戦略」とか。ウォーシミュレーションゲームなんかも元々はボードゲームだよな。ボードゲームのコンピュータゲーム化、ってのはコンピュータサイエンスを含んだり、あるいはちと外れたトコでは大テーマなんだわ、実は歴史的には。
X68000用の「Super 大戦略 68K」。元々このテの「ウォーシミュレーションゲーム」はルーツはボードゲームで、大体作者が「一人でプレイしたい」と思って個人的に制作してみた、ってのがその後の発展の基礎だったりする。ものすごく個人的な動機で作ったりするんだ。
今は消えちゃったけど、と言うかフランスのUBISOFTに買収されたコンピュータ・ウォーシミュレーションゲームの老舗、ちょくちょく名前を出してたSSI(Strategic Simulations, inc)なんかも、元々社長がボードゲームでのウォーゲームのファンで、それをソリティアにしたかった、ってのが会社創設の動機だった、との事。
私(ジョエル・ビリングス)の大学時代の専攻はコンピュータ・サイエンスではなく経済学でした。経済とはいっても数理経済学だったのでコンピュータ、それもIBMの大型コンピュータをしょっちゅう使っていました。子供のときから(コンピュータを使わない)ウォー・ゲームが大好きだったのですが、ウォー・ゲームには2つの難点があると感じていて、それは「プレイする相手を探すのが難しく、たいがいの場合一人でやらなければならないこと」と「ボードを使ったゲームでは、敵の状況が全て見通せてしまうこと」でした。コンピュータを使えばそういった欠点が克服できると思い、大学のコンピュータでごく簡単なコンピュータ・ウォー・ゲームを作ってみました。コンピュータはいつでも相手になってくれるし、プレイヤーと敵の間に「壁」を作るので、相手の状況が見えないわけです。例えば、当社が1980年に出版した一番最初の製品「コンピュータ・ビスマルク」は基本的に「海戦において相手の船をやっつける」ものですから、敵の戦艦ビスマルクがどこにいるかを知っていたら、ゲームのおもしろさがほとんど無くなってしまうのです・・・、と言っても結局は自分自身がコンピュータ・ウォー・ゲームで遊んでみたかったというのがコンピュータ・ウォー・ゲームを作り始めた一番大きな理由ですね。電視遊戯大全より
ジョエル・ビリングス
コンピュータ・ビスマルク(Apple II版)。1980年製、という事は、光栄の「川中島の合戦」より1年早い登場だ。とは言っても、ほぼ同時期に「ウォー・ゲームのビデオゲーム化」というアイディアを日米共に「思いついていた」という事だ。
んでだな。
星田さんにはいいアイディアがあるじゃない。
以前こんな記事を書いたんだけど、知る限り、レトロハードでの「ビデオゲーム化」はこれしか知らん。
でも星田さん、詳しいんでしょ?多分、「カタンの開拓者たち」ってのをビデオゲーム化してみればいい(笑)。多分やるだけの価値があるんじゃないかな。
僕は全然ルール知らんので(笑)、作ってくれたら遊びます(笑)。
※1: GTK+は元々、対Photoshopとして開発された画像編集ソフトGimpを作る為のライブラリ目的に制作されたが、これが転じて、Linuxでの一番人気のデスクトップ環境、GNOME制作の為のツールキットとして転用された。
しかし厳密に言うと、GTK+はLinux等のフリーOS専用ではなく、クロスプラットフォームのツールだ。従ってWindowsでも使う事が出来る。
ただし、Windowsでの活用事例はそんなに多くなく、またwxWidgetsに比べると低レイヤーで使うのが難しい。そして自由度が高い。
結局このテのツールは自由度が高い = 使うのが難しい、んだ。そして一番のユーザーはC言語ユーザーだろう。GTK+はC言語で書かれてるので、C言語用グラフィックライブラリとして見る事が可能だ。
なお、wxWidgets用のGUIビルダーのwxGlade。Gladeって何なんだ、っちゅーのは、GTK+用の有名なGUIビルダーにGladeってのがあって、そこから名前を借りてきたらしい。
LinuxでC言語ユーザーが頼るGUIビルダー、Glade。クロスプラットフォーム(なんだけど)を狙わないのならLinuxでのC言語使いはC++を使う事なく、Glade + GTK+でGUIアプリを作るケースが殆どだ、と思う。なお実は「作成したGUIのデザイン」はxmlで保存され、C言語で作られたアプリ側にそのxmlファイルを「食わせて」、パーズしてデザインを「再構成」したように記憶してる。
記憶だと、そもそもGTK+と言うツールキットは、Smalltalkのように「メッセージを送信して」GUIを作っていく。と言う事は、Schemeが持ってる「継続」と言うモデルと相性が良い。
そんなこんなで、恐らくだけど、川合史朗さん自身がCハッカーでエキスパートである事(つまりGTK+でのGUIを自身が良く知ってる事)。それと上で書いたようなSchemeが元々持ってるモデルが「メッセージ送信」と相性が良い辺りで、GaucheはGTK+を選んだんじゃねぇのかな、って予想してる。
※2: 自信なし。
ただし、当初はやっぱUNIX系フリーOS対象としてしか考えられてなかったんじゃないか。
野良ビルドでWindows版が出た、とか公式に併合された、と言うような噂があったけど、どうなんだろ。
あ、ちなみに「野良ビルド」とは、川合史朗さんじゃない人が、ソースコードを入手してWindows上で使えるようにコンパイルして配布してくれた、って意味なんだけど、このテの「野良ビルド」が、キチンと公式が「新しいバージョンを発表」したらそれに追従してくれるか分からんのだよ(このテの問題は、例えばUbuntuのPPAも抱えていて、最初はこまめに更新しててもメンテナが「飽きちゃって」寂れてく、ってのが良くある)。
そして「Windows版」が全機能をLinux版と同じように「使える」とは限らない。
つまり、PythonがWindowsでもLinuxでも「使える」程、(仮にWindows版があっても)Gaucheを信用していいか分かんない(逆に言うと、Linux上だと絶大な信頼を寄せてイイんで、PaizaみたいなWebサービスで使える、と言う事だ)。
結局、Windowsを含めて「使える」となると、Scheme系処理系だと結果Racket一択、ってなるのはしょーがないと思うわけだ(これはANSI Common Lispでも、「いくら他に性能が良いのがあっても」一般論として使うのならCLISP一択となり、例えば野良ビルドの「SBCL」はアテに出来ない、ってのと同じ理屈となる)。
※3: 仕様上、理論的には、今は違う。
ただし、何度も言ってるけど、現時点でもR5RSがデファクトスタンダードで、R7RS-smallにも準拠してない処理系が多い以上、Schemeは「処理系によって実装者の好みのGUIツールキットを内包してる」ようにしか作り様がなく、結果、「ユニバーサルな外部GUIライブラリ」なんて定義しようがないわけだ。
例えば、Racketでも過去、
「RacketでQtを使いたい」
と言う要望が実装者への要望として送られた事があるが、見事に実装者側に却下されたのを見たことがある(笑)。いや、俺が言ったワケじゃないよ(笑)?
Scheme実装はPython以上に実装者側の「好き嫌い」が激しくなるんだ。何故なら長らく、「外部へのインターフェースを持ちようがない」仕様だったから。
そしてこのテの「要望」「却下」は、原理的にはANSI Common Lisp界隈では起き得ない事で、ある意味、Scheme界隈独特の現象だと思う。
※4: この辺が、言語仕様上「色々考えられて」作られてるANSI Common Lispと違ってる。
ANSI Common Lispだと「外部ライブラリ」からの読み込みが定義されている以上、外部でユニバーサルなGUIのツールキットライブラリを定義する事が可能で、どの処理系でもそれを使える事が保証される。
従って、Schemeとは違って、直接、例えば「wxWidgetを使いたい」となれば、バインディングさえ作成すれば即刻そのライブラリの恩恵を「どのANSI Common Lisp処理系」でも理論的には享受可能、って事になる。
それがANSI Common Lispを「現実的なエンジニアリング言語」と成してるわけで、Common Lispユーザーが「Schemeは綺麗だけど理論だけだ」と貶す原因でもある。
※5: なんせ、不思議な事に「JavaScript用バインディング」なんつーのも有志によって作られていて「ブラウザ上でしか動き様がなかった」JavaScriptでもGUIアプリが作成可能、と言うワケの分からん事になってる(笑)。
他にもOCaml用のwxWidgetsバインディングなんかも開発されてるらしく、このように「言語を渡り歩く」とすれば、かなり広範囲に渡ってwxWidgetsバインディングの名を目にする事が出来るだろう。
※6: 英語の、過去の実文書をスキャンして作ったようなPDFだと、テキストのコピペが出来たりしてビックリするだろう。英語でのOCRの技術は実は割に普及してたりする。アルファベットなんかは単純だから、だ。
反面、やはり「光学文字読み込み」でも日本語は厄介ではあるんだ。
今後の技術の発展、普及に期待したい。
※7: インクジェットプリンタではなく、レーザープリンタだったら、Windows側にOCRソフトを用意しておけば、スキャンされたデータから直接テキストをおこす事が可能な場合もある。
※8: 語源的には「一人でゲームをする」事。
実はニュアンス的には「ひとりエッチ」とか「ぼっち飯」とかに近い(笑)。
これもそのうち、もとこんぐさんが解説してくれるかも。
