Carbon版HyperCardを騙ろう - 1067262136

1：ぷご：2003/10/27(月) 22:42: Xcode+CarbonでOSX用のHyperCardを作ってしまえ！
という構想はあるものの、そこまでの能力と時間と資金は
ありません。というわけで、構想や妄想や感想や暴走を
繰り広げてみようというスレッドです。

いけそうだと思ったら本気で作るかも。
4：ぷご：2003/10/28(火) 22:57: ●過去との互換性
HyperTalkをベースにした言語を使えるようにする。
HyperTalkから簡単に変換できる程度のもの。

カードピクチャやボタン、フィールドのデータやプロパティは
コンバート用のHyperCardスタックを作ってリソースに書き出す。
どのような構造になっているのかはXMLあたりで記述したいなぁ。
5：ぷご：2003/10/28(火) 23:02: ●ペイントを基本に
MacOSXではアンチエイリアスが多用されており、
これと相性のいいのはドロー形式なのだろうが、
ペイントの方が分かりやすいため、あえてペイントを
基本にしてデザインできるようにする。

液晶の解像度が今後大きく上がるのではないか？
そのとき、アンチエイリアスは不必要になるだろうと
考えている。僕個人としてはそうなってほしい。
6：ぷご：2003/10/28(火) 23:10: ●フィールド
テキスト編集機能をどう実現すればいいのかは悩むところ。
表示だけならHTMLを表示するのが良さそう。
Webをそのまま表示できれば便利だし、案外楽に組み込めそうに思う。

でも、やはり普通にMLTEを使うべきかな。
なるべく自前での実装はさけたい。
7：ぷご：2003/10/28(火) 23:14: ●アプリケーション化
スタックデータはすべてリソースに持つことになるので、
アプリケーション化といっても特別なことをする必要は
あまりなく、リソースを組み込むくらいで良い。

ちなみに、１アプリケーションで複数のスタックを開くことはできない。
１アプリで１スタックに対応させる。
8：ぷご：2003/10/28(火) 23:23: ●開発方法
いわゆる「オープンソース」の開発では、
開発者自身の興味や技術的な面にばかり
力が入ってしまう傾向があるように思われる。
HyperCardにはそれは似合わない。

ビルアトキンソンは何を考えながらHyperCardを
作ったのだろうか？

ベース部分は一人で作らないといけないだろうと思う。
9：ぷご：2003/10/29(水) 19:48: 昨日分を修正
・スクリプトは保存時コンパイルではなく、実行時コンパイルとする
・複数のスタックを同時に開くことはできないが、ライブラリ化は可能。
　リソースとスタックスクリプトを扱える。
10：ぷご：2003/10/30(木) 23:26: HyperCardでは視覚効果は大したことはできなかったが、
いまのCPUではかなりのことが可能。ページめくりくらい欲しい。

カードだけでなく、ボタンやフィールドの表示/非表示でも
視覚効果を付けることができる、のは作るの大変そう。
11：ぷご：2003/11/01(土) 15:24: 中間言語はBASIC的なものになると思うんだが、
それではあまり良くない。魅力に欠ける。
とは言っても速度面とシンプルさ、分かりやすさの
バランスが必要なので凝った事は出来ないしなー。

GOTO文はさすがに作りたくないので入れませんが。
ifとrepeat、next repeat、exit repeatでできるでしょ。
12：ぷご：2003/11/01(土) 15:50: プロジェクトは名前が重要だと思ってみたりする。
mirageとかいうXCMDはその名の通り蜃気楼のように消え去った。

というわけで、現在の案
中間言語実行アプリ：「MacRoke」（まっくろけ）
中間言語：「未定」
高級言語：「未定」
RAD型開発環境：「未定」

未定だらけだ。
13：ぷご：2003/11/01(土) 20:08: mallocとfreeで文字列変数を確保しようと思っていたのだが、
Poolを作って1024byte単位で確保とかしたほうが良さそう。
メモリの断片化&メモリの再確保による速度低下を防ぐわけ。
14：ぷご：2003/11/01(土) 21:26: 変数名から変数の中身を取得する部分や、
関数名から関数の内容（スクリプトだから単なるテキスト）を
取得する部分はリストの単純サーチで作ればいいと思っていたのだが、
速度低下が激しい気がする。

静的リンクは無理としても、せめて１度参照したものだけでも
静的リンクに出来ないものか？

いや、あまり変な実装するのはやめておこう。
最初は出来るだけ単純な構造で作り上げ、その後
パフォーマンスが悪いところを集中的に改善するほうが
良い結果が得られる。最もシンプルでデバッグしやすい作戦でいこう。
15：ぷご：2003/11/01(土) 23:16: リソースをいろいろ扱えるようにしたい。
Carbon版のResEditが作れるくらい。

それができれば、それだけでも存在価値はありそう。
スクリプティング可能なリソースエディタだなんて！
16：ぷご：2003/11/02(日) 01:43: ゲームを作る事はあまり考えないようにする。
ゲームを作れるだけのポテンシャルを持つ基盤にしなければ
ならないが、ゲーム以外が作れないなら意味が無い。

教育分野で使える、とすれば魅力なんだが使われるとも思えないし、
便利ツールが作れる、プロトタイプが作れる、というところで
適当に落ち着かせよう。高度な開発環境ならXcodeがある。
便利な開発環境が足りないんだ。
17：ぷご：2003/11/02(日) 10:57: Mac&Win両対応ってのはもう古い。
ユーザ数を最大にしたければ、
「Win専用」
でいいじゃないか。

MacとWinじゃ思想が違うので、出来上がるものも
違ってくるんだよ。だからMacでしかできないものを
作るべきなんだ。Winに移植するためには異常な労力が
掛かるべきなんだ・・・。

とは言いつつも、できるだけ移植しやすいように作ろうとか考えているぷごであった。
18：ぷご：2003/11/02(日) 12:46: こういうソフトは、フリーでなければならない。
個人では開発力が足りない。
オープンソースでは方向性が違ってしまう。

方向性を固めてから、オープンソースというのが一番現実的かな。
19：ぷご：2003/11/05(水) 23:23: emacsみたいにスクリプト内蔵？のスクリプトエディタに出来ないか考えてみる。
スクリプトエディタ内でスクリプトを使うというのも面白いかも。
しかし、そもそもスクリプトエディタそのものをスクリプトを使って作ろうと
思っているので、元々の構想通りなのだった。

ウィンドウを複数開けるが、メインウィンドウは１枚のみ。
テキストカーソルはサブウィンドウにも置ける。
メッセージボックスやスクリプトエディタはサブウィンドウとして実現。
リソースエディタやパレット、デバッグログ表示もサブウィンドウ。
20：ぷご：2003/11/07(金) 00:58: GIMPみたいにスクリプトを内蔵した画像処理ソフトを、、、
って、マクロやAppleScriptのほうが便利だな。

テキストエディタの場合は出来る限りキーボードから
マウスに持ち替えなくても操作できるようになるのが理想的。

とはいえ、GUIではマウスを使う場面は多くなる。
HyperCardのようにキーボードショートカットを充実させたいところ。
21：ぷご：2003/11/10(月) 22:06: 中間言語レベルでも計算式の評価くらいできるようになっていないと
不便だし、速度もかなり遅そうだ。

逆に言えば、計算式の評価さえあればそこそこ使えそうな気もする。
基本コマンド：AAA bbb,ccc
同じコマンドを呼ぶ別方法（AAAが記号以外のとき）：AAA(bbb,ccc)
さらに別方法（AAAが記号で引数が２つのときに限る）：bbbAAAccc
これでいけるかな
22：ぷご：2003/11/12(水) 00:53: 基本コマンド無意味だな・・・。

素性の良い言語は言語仕様も何かとうまく作られているもの
ではないかと何となく思ってみた。

だからといってどうしようもないわけだが。
23：ぷご：2003/11/12(水) 21:48: 大風呂敷を敷いたプロジェクトは破綻する。
未来の分かる人間はおらず、失敗をしない人間もいない。
ゆっくりと着実に進むのが確実な方法だ。

ちゅうことで、自作ゲームのベースに使える程度のスクリプトと
データ取り扱いが出来るくらいのもんでも作るかな。
24：名取：2003/11/19(水) 16:39: 式の評価…逆ポーランド記法とかなんとかですね。難しそうだ
いっそHyperTalkっぽい言語からAppleScriptに直して実行するとか…
25：ぷご：2003/11/19(水) 21:03: AppleScriptで実行するならはじめからAppleScriptで何の問題も無いような
26：eagle：2003/11/20(木) 16:22: 店頭でASでシステム終了プログラムを書いて、
それを起動項目にぶち込んだこ（銃声）
27：名取：2003/12/06(土) 15:15: 私はCocoaで。
練習練習。
http://homepage.mac.com/k_natori/.cv/k_natori/Public/HTEditor01.sit-link.sit
28：原田：2003/12/06(土) 16:47: うちでは起動しませんでした＞HyperTalkEditor
サイズから見るに、Xcodeのゼロリンクが有効のままではないですか？
http://homepage.mac.com/mkino2/panther/Xcode/zerolink.html
29：JNT：2003/12/07(日) 02:06: あの…23のぷごさんのセリフ、使わせてもらってもいいですか？
人工無能のセリフで…
30：ぷご：2003/12/07(日) 09:54: >27
ZeroLink: could not load .o file: /Users/natori/..(中略)../MyDocument.ob
「パッケージの内容を表示」して、中身を直接実行するとこんなエラー出てきました。
ZeroLinkねぇ。メニューから「完成版としてビルド」とか出来ないもんでしょうか。

>29
全然構いませんよ。
31：ぷご：2003/12/07(日) 10:15: スクリプトエディタは内蔵の方が使いやすいかなぁ。
パス指定されたファイルの何行目かを開くことと、
ファイルが変更された事を本体アプリに知らせれば
内蔵エディタとあまり変わらない気もしますが。

そういえば、今のHC内蔵スクリプトエディタは
何行目を開くという事が出来ないな。
あった方が便利だと思うんだけど。
32：（　´ω｀）y-~：2003/12/07(日) 21:43: >>31
そうかぁ？
何行目だけしか表示されないっていうのはデバグの追跡には役立たずに近いんじゃないかと。
33：ぷご：2003/12/07(日) 21:47: 「ss」コマンドでの検索で、なんで検索した文字のある行に飛ばないのか。
そんだけ。
34：創基：2003/12/07(日) 23:35: 「ss」コマンドで検索した後はコマンド-Gですぐ飛べますよ。
それを手間と考えるか考えないかによりますが。
ScriptFindStringというグローバル変数がスクリプトエディタの検索文字列と対応しているようです。
35：名取2：2003/12/08(月) 09:30: 書き込めてないのでもう一回、と。
なぜしたらばに蹴られるのだ
http://homepage.mac.com/k_natori/.cv/k_natori/Public/HTEditor011.sit-link.sit
36：ぷご：2003/12/09(火) 00:15: >34
スクリプトのエラーが出たときはその行がすぐ開きますね。
それくらいは出来てほしい。

>35
見れました。色が付く事に感動しますね。
37：名取：2003/12/11(木) 11:46: 環境設定で色を変えられるようにしようと思い、なんとかウィンドウは開けるように。
しかしNSColorをNSArchiverでNSDataにして、NSUserDefaultsに突っ込み、
次回起動時に復活させようとすると強制終了を食らう。
デバッグしても原因がよく分からない。うーむ
38：＜ばいばいきーん／削除済み＞：＜ばいばいきーん／削除済み＞: ＜ばいばいきーん／削除済み＞
39：名取：2003/12/14(日) 11:58: HyperTalkEditor 0.2。
環境設定他いろいろ。
http://homepage.mac.com/k_natori/.cv/k_natori/Public/HTEditor02.sit-link.sit
40：リンク：2004/01/04(日) 05:28: 通りすがりのものです。
ぷごさんはforthという言語を知ってますか。
この言語、コアな部分がROMの削除不可ブロックに収まるほど小さいため、
ブートローダとして利用されたりしてます。
小さいだけあって、個人でも作るのは難しくありません。
僕自身、ANSI準拠ではありませんが、作ってみました。
コア部分だけですが、1Kラインくらいでした。
この言語の変数や関数のリンクの仕方が参考になるかもしれません。
41：ぷご：2004/01/04(日) 12:09: リンクさん、ありがとうございます。
なるほどforthですか。
コンパイラの本を買ってきたのはいいけれど分厚くて読む気がしなかったので、
forthあたりから調べてみる事にします。
42：ぷご：2004/01/10(土) 14:14: CHASM
http://www.creysoft.com/index.htm

HyperTalkが動くらしい。
REALbasicで作ってるらしい。
43：ぷご：2004/01/10(土) 14:25: WildFireというプロジェクトもある、と。
何だかよく分からないが
CHASMはHyperTalkインタープリタ
WildFireはHyperCardクローンを目指している。

両者の関係はよく分からないが、何らかのやり取りはしている。

個人的にはHyperCardはいくら出来の良いものを作っても、
それが単なるクローンであれば大した成果は無いと思う。

HyperCardの次の次あたりを目指して、、、
ネットワーク、3D、ムービー、その他のものを手軽に扱える
環境でなくてはならない。

実はCocoaは割と近い位置にあるんだと思う。
44：名取：2004/02/23(月) 10:33: 土日にちょいと悪戯心を起こしてCocoaをいじりました。
書類の中にいろんなボタンを配置出来るアプリを作ろうと思って。
…結果、NSButtonの参照を持ち、initでNSButtonを作り、
アクセッサメソッドでNSButtonをどうこうするモデルオブジェクトをNSArrayContollerで
情報ウィンドウとバインディングしてしまいましたわい。
…おお。ボタンの追加と削除、名前、visible、enabled、rectをいじれる。
ボタンのタイプがうまくいじれないし、ドラッグで位置や大きさを変えられる訳じゃないけど
HyperCardもどきのガワなら結構何とかなるのでは！？と思いましたです。
45：ぷご：2004/02/24(火) 00:03: CocoaはCocoa自体で十分なのでは？
Cocoa挫折した人間が言うのもなんなんですが・・・。
46：名取：2004/02/25(水) 11:13: ＞Cocoa自体で十分？

うーむ、例えばCocoaではInterface Builderでインターフェースを作って、コード部分と繋いだりしますよね。
それからビルドしてやっと動くものになるわけですよ。他の環境でも大体そうですけど。
HyperCardではカードを作って、ボタンを置いて、ボタンにスクリプトを書いて、ってどの段階でも
それは動作品であり製作中でもあります。
私がHyperCardで好きなところはやはりここですよ。

確かにCocoaでもHyperCardとのアナロジーで理解出来るところはありますけど、
HyperCardのように巧妙に制限された環境も必要なんだと思うんです。
Appleのiアプリケーションのように、制限することで逆に機能を使いこなせるような。
まずオブジェクト指向とかいう抽象的なものを理解しなければならないようなものでなく、
「ここにボタンがある」って具象的に感じられるような。
47：ぷご：2004/02/25(水) 20:37: ＞Cocoa自体で十分
なんでこんな事書いたんだっけ？
Cocoaで十分なんだったら、Carbon版HCのスレなんて立てないよ。

うーん。
Cocoaの機能を使うならCocoaを使えば便利だなと思ったんでしょう。
誰もCocoaの機能を使うと言ってませんが。僕が勝手にそういう事にしてまいました。

＞46
名取さんが以前から主張されてる事ですね。
HyperCard的なものが必要な理由は納得しました。
個人的には「ここに絵を描ける」というのも重要と思います。

制限する、という意味ではHyperCardもどきの何でも使えるようなものより、
何かに特化されたもののほうが求められているかなぁ。
Cocoa版RPG作成ツールとか。
48：名取：2004/02/26(木) 11:14: 実はCocoa版Timpaniを作ろうかな、とはちょっと思ってます。
49：名取：2004/03/05(金) 15:23: Cocoa版見かけだけHyperCardにしても、Cocoa版Timpaniにしても、
ResEditにあたるリソース管理部門を作る必要がありそうですね。
バンドルにしてしまえばいいのかなあ。
50：ぷご：2004/03/05(金) 19:47: Mach-Oアプリの場合はリソースの代わりにパッケージ構造になってるんで、
絵や音なんかはファイルでの管理にすればいいと思います。

XCMDにあたる部分は、バンドルかな。
51：名取：2004/03/08(月) 09:30: 絵や音も含め、スタック自体をパッケージにしようかと思ったんです。
RTFDみたいに。
難しいかな…

さて位置・サイズ変更のGUIはどうやって組み込めばいいのか（笑）
一番上に透明なViewをのっけて、適当に四角とか描かせりゃいいのかな。
52：名取：2004/03/23(火) 13:18: とりあえず「PseudoCard」と銘打って、画面にボタンを配置するだけのアプリを制作。
悲しいほど何も出来ない。

これからの課題：
HCButtonのArrayを含むHCCardを作って、そのArrayを含むHCStackをMyDocumentの
内容にしたり。HCFieldを作ったり。
難しいだろうけどHCStackにNSImageのArrayをぶちこんで、HCButtonに設定出来るようにすれば
見栄えもするかも。でもスクリプトは無理だろうなあ…
http://homepage.mac.com/k_natori/.cv/k_natori/Public/PseudoCard01.sit-link.sit
53：ぷご：2004/03/24(水) 21:21: Carbon版HyperCardも進めないといけないな、、、。
54：名取：2004/03/27(土) 17:06: PseudoCardオブジェクト継承図（妄想）

NSObject
　┗ HCObject
　　　┣ HCPart
　　　┃　┣ HCButton
　　　┃　┗ HCField
　　　┗ HCOwner
　　　　　┣ HCCard
　　　　　┗ HCBackground
55：6年ぶりのハイパカ：2004/05/08(土) 01:29: ちなみに
http://www.runrev.com/
Runtime Revolutionを使ってる方っていますか？
あれはなかなか面白そうなんですが。
それとも、やはりハイパカの魅力は無料なところですかねー？
56：ぷご：2004/05/08(土) 23:40: RunRevの出来はいいのかもしれないですが、手を付けにくいですね。
Webコンテンツ作成には全く向かないし、単体アプリ作成環境としては中途半端。
お金出すのなら別なものに出します。

HyperCardは基本的にスクリプトが誰でも見れるようになっているところが
個人的には気に入っています。
57：6年ぶりのハイパカ：2004/05/09(日) 00:27: たしかに、よく考えたらRunRevはスクリプトが見れませんね。
他の人の大作スタックのスクリプトを眺めてニヤニヤしていた自分にとっては
それは結構痛いです。
まぁ確かにお金出してまでのものではないかもしれませんね

しかしWinでもHyperTalk使いたいー（笑）
一から勉強して自分で作る・・・
うーん、絶望的だ・・・
58：holythunderforce：2004/05/24(月) 22:46: http://www.tigabyte.com/
HyperNext
↑HyperCardっぽい
59：ぷご：2004/05/25(火) 23:16: holythunderforceさんこんばんは。あ、某454さんですね。

HyperNextは以前HYPERCARD PARKで話題になってました。
頑張っているとは思うけど、どうやっても流行んなさそう。
求められているのはこんなのじゃないと思うんですよ。

JavaScriptがもっとグラフィック強かったらなぁ。
60：（　´ω｀）y-~：2004/05/27(木) 12:15: http://www.smokymonkeys.com/triglav/
でもやってみる？
61：holythunderforce：2004/05/28(金) 00:48: 2ちゃんねらﾊｹｰﾝ　(￣ー￣)ﾆﾔﾘ
正直、HyperCardって美化されてる気がします。
HyperCardバージョンアップされても、あんまり盛り上がらないんでは。
ちなみに僕はHyperCardスタックをJavaにトランスレイトして、ホームページに
貼付けられるようなものがあったらいいかもと妄想したりもします。
まあ、それでもFlashの画面効果とか見てると、今更HyperCardもないかなと。
62：（　´ω｀）y-~：2004/05/28(金) 19:34: したらばに書き込んでるくせに、
2ちゃんねらﾊｹｰﾝ　(￣ー￣)ﾆﾔﾘ
なんてことばは今日びはやんねーんだよ！

まずは>61から美化することを提案します。
63：ぷご：2004/05/29(土) 00:43: スタックをホームページに貼付けるんじゃなく、そのまんまホームページになればなぁ・・・
と思っています。
Javaのお絵描きチャットが割と近いのかな。

HTMLはテキストに寄りすぎてるし、Flashも見た目だけという感じ。
もうちょっとどうにかなると思うんだけど。
64：ぷご：2004/08/05(木) 01:29: ひさびさにCarbon版HyperCardプロジェクトをいじってみる。
ふむふむ、結構作り込む気があったんだな。
当時から技術力は上がってないな・・・。精進せねば。

GUIも何も無い、単なるスクリプト実行環境だけど、
HyperTalkのようにお手軽スクリプトが組めると結構楽しめるかも。
65：ぷご：2004/12/10(金) 00:00: HyperCardなら一瞬で終わるのに、
Windowsだと半日くらい掛かる仕事があったりする。

PerlやRubyを習得すればすむ話なのだが、
やはりここはHyperCardの移植を……。

それは無理にしても、とりあえずHyperTalkを
動かせるようになるとなにかと便利かな。
66：ぷご：2004/12/24(金) 01:35: 新ペイントツールを作っていて、とりあえずペイント機能は
どうにかなる事が分かった。

スクリプトも仕組みは作っていたので
HyperTalkを扱えるように頑張ればそれっぽくなるなぁ。

データ構造の扱いも問題だけど、PICTやcicnを解析したから
それっぽいものはできそうな気もする。

とりあえずは、もう少しペイント機能を作り込んでみよう。
それからスクリプト、データ構造、テキストの扱いなど。
絵を描けてスクリプトを動かせれば、何か使えるツールには
なってくれる。
67：ぷご：2004/12/28(火) 00:22: 1年以上前に書いたこのスレッドを見直すと、今考えている事とだいたい同じ。
ちょっと違う点を書いておこう。

Q.なぜCocoaじゃなくCarbonなのか？
A.Cocoaはよく分からないから。移植性に乏しいのもある。

変数には数値(int,double型)と文字列(バイナリ含む)を格納できる。
バイナリデータは16進数に変換する事で表示できる。

リソース、と言っているがMacのリソースの事ではなく
独自にリソースのような仕組みを作る。
ファイルの先頭に個々のリソース位置へのテーブルを持っておき、
１ファイルの中にすべてのデータを保持する。

ファイル構造はXMLでは記述しない。もっと平凡な形式にする。
人間が解読できるようにテキスト形式にする。
分かりやすいフォーマットは普及するフォーマットとなる。

アンチエイリアスは今後も重要であり続けるだろう。
しかし、ドロー形式は分かりにくいので採用しない。

フィールドは簡易HTMLで実現するのが良いと思う。
やはり、移植性は考えておきたいからだ。

基本となるアプリケーションはペイント機能も無い状態。
スクリプトを動作させる事はできる。
ペイント機能などはホームスタックの機能で補う形になる。
ホームスタックはOSが異なろうが動作する。

文字列変数の確保はmallocとfreeを使う。
mallocとfreeでもメモリの再確保による速度低下は対策されている。
ま、そりゃ当然だよなぁ。ClassicのNewHandleとかは
対策されてないらしいが。

FireFoxやLinuxなどがオープンソースの中でも強力だ。
これはお手本となるものがあって、それに向かって進んだからこそ
できた事であって、お手本が無ければみんなの目標をひとつに
定める事はできなかっただろう。
お手本となるべきはHyperCard。今の時代のHyperCard。

forthについて調べなくてはならないなぁ。
68：ぷご：2004/12/28(火) 08:02: 文字コードはユニコードを使うが、何もかもユニコードにすると
スピードが落ちそうだし、容量も２倍食う。

ASCIIとユニコードの２種類対応あたりで行っておきたい。
69：ぷご：2004/12/28(火) 08:13: ２種類ののコードがあるのは厄介。文字列はユニコードのみ。
スクリプトもユニコード。中間言語も。

1バイトごとを扱うために、byte of という演算子でもサポートしよう。
70：ぷご：2004/12/29(水) 00:51: HyperCardでは目標が遠すぎる。
とりあえず、テキストエディタで書いたソースで簡単な
ゲームくらいは動かせるものを作ろう。

METALを目標に据えることにする。これは実現可能な範囲だ。
71：ぷご：2004/12/30(木) 12:01: スクリプトエンジンわからん。
ものすごく単純なものなら自作したけど、
何も勉強せずに突っ走るのはやはり無謀かな……。
とは言え、作ってみる→わからない→本を読む→納得
という方向で行くのが物事を理解できる道だと思うので
とりあえず、突っ走ってみよう。
72：（　´ω｀）y-~ </b><font color=#005500>（G5PVvZZ2）</font><b>：2004/12/30(木) 15:44: http://www.jppass.com/lgp/sonota/down.htm

とりあえずヒントになる？
73：ぷご：2004/12/30(木) 16:58: Winユーザ向けにはこういうのが豊富だよねぇ。

Macユーザをターゲットに、ゲーム開発環境を出しても
あまり面白いゲームは出て来ないだろうな。

とにかくなんでも使える、というものを出すと
予想外のものが出てきそうな気がする。
74：ぷご：2004/12/31(金) 22:41: HyperTalkのうちゲーム作成に使われるものと、
PgColorXのコマンドをHyperTalkに合うようにしたものを
サポートすれば、それなりに使えるかな。

ペイント機能も作れる=HyperCard以上に何でも作れる。
でも、HyperTalkの一部しかサポートしないので
グラフィックに特化したような環境となる。

[PgColorX風コマンド]
create buffer "abc"
set rect of buffer "abc" to 0,0,512,384
set port to cd window
copy buffer "abc" from "0,0,64,64" to "0,0" with transparent
set frameColor to red
set fillColor to white
draw rect "3,3,61,61"
75：ぷご：2005/01/03(月) 00:32: バイナリを扱えるようにして、ビット演算なんかも
できるようにすると色々使えそう。

XCMDの用な拡張方法は用意せず、
ソースコードそのものをいじる事によって
拡張するしかないことにしようかな。

スクリプト単独で何でもできるようにする。
76：ぷご：2005/01/03(月) 10:45: ボタンやフィールドに色付けできるようにすると
センスの無いスタックがあふれてしまう。
かといって、標準のデザインだけでは自由度が低い。

ということで、いくつかのテーマからデザインを選ぶように
すれば自由度と統一感を保てそう。
77：ぷご：2005/01/06(木) 23:47: コーディングは進んでいませんが、
形は頭に思い描けるようになったかな。
単なるHyperTalk+描画機能だけの実行環境。
GUIやペイントは実行環境上で構築。
機能の拡張はオープンソースでいじり放題。
OS固有のAPIはなるべく使わないが、QuickTimeは使う。

そんなところで。
78：ぷご：2005/01/23(日) 22:27: コンパイラの本を買ってきた。理解不能だった。
コンパイラの仕組みと言う、やや入門的な本を買ってきた。
これなら、少しは理解できそうだ。

以前買った分も合わせて、3冊もコンパイラの本があるよ。
ちょっとはモノになるといいなぁ。
79：Classiclll：2005/02/02(水) 18:16:40: お持ちの本にも書いてあるかと思いますが、
再帰←逆ポーランド←自由文脈文法←【BNF記法】→コンパイラ用パーサ（C言語）→言語処理
でたどっていったほうが、理解はしやすいかと思います。
UNIXってC言語コンパイラー（パーサー）とともに育ったというような気がしてます。
とりあえず、私の理解と記憶ベース（これが不正確）から、書きました。
80：ぷご：2005/03/05(土) 20:40:27: サーバ側にスタックを置いて、ユーザはプレイヤー(ブラウザ)で見るというのが
理想的だなぁ。サーバ側のスタックをいじることができないと意味が無い。
81：ぷご：2005/05/13(金) 21:40:19: Carbon版HCは終了。Carbonアプリをちまちま作っていく余生を過ごしますかね。
82：ぷご：2005/06/12(日) 06:39:55: 僕が欲しいのはOSX版HyperCardじゃなく、スクリプト型の開発環境ではないかと思った。
スクリプト言語としてはHyperTalkでなくPerlとかRubyとかの方が強力で速いだろうし、
ペイント機能がついてると言っても、XCMDでカラーを使おうとすれば他のソフトが必要だし、
HyperCardのオブジェクト指向は便利だけど、無くちゃならないというほどでもない。
GUI部品をスクリプトで扱えれば、とりあえずOKのような気がする。
83：ぷご：2005/06/13(月) 00:02:57: Luaでスクリプト。
SDLで描画とキー＆マウス。
CocoaでGUI部品。
QuickTimeでサウンド。

こんなところで最低限のものは作れないかなと思ってみる。
カードとかオブジェクト指向もなく、とりあえずスクリプトで
画像処理をいろいろ試行錯誤できる環境。
Carbonはもういいや。
84：ぷご：2005/06/13(月) 00:36:25: Luaはゲームなどで使われる組み込み用言語。
高速で、シンプルで、実績がある。
日本語での説明資料も無いことは無いけど、少ないかな。

LuaはPascalっぽいと言われていて、HyperTalkもPascalっぽいところが
あるので気に入った。Rubyよりも取っ付きやすい。
85：ぷご：2005/07/27(水) 00:58:12: luaからSDLを制御する実験がやっとできた。
マウスクリックを検出して色を塗るだけだが・・・。
86：ぷご：2005/07/29(金) 01:09:10: SDLは結構速いし、luaは簡単だから誰でもスクリプト出来る。
これだけでもHyperCard+PgColorXより、ゲーム開発環境としては強力。

GUIとかテキスト表示とかセーブとかややこしいのが残るけど。
Cocoaはそのあたり強力なので組み合わせることが出来れば素晴らしい。
87：ぷご：2005/07/31(日) 00:19:11: Cocoaにぶつかり、ぶつかり、ぶつかり。
やっぱりCarbonで行こうか。Lua+Carbonでいいじゃないか。
88：ぷご：2005/07/31(日) 02:39:12: ■SDL
CocoaのGUIなどとの組み合わせを考えず、3Dを使わないテレビゲームのような
ゲームを作るなら非常に良い感じ。キー入力や高速描画処理が非常に楽です。
OSを選びませんが、それが逆にOSとの親和性に欠けるという欠点になります。

■Lua
使っていて楽しいです。やっぱりスクリプト言語で制御できるのは嬉しい。
日本語の扱いなど気になりますが、パッチがあるので何とかなるでしょう。
ライセンスも緩いですし、末永く使っていこうと考えています。

■Cocoa
SDLとCocoaのGUIを組み合わせつつ、スクリプト制御をさせようと
しましたが、行き詰まりました。
がんばって勉強すれば出来るんでしょうけど、断念。
89：ぷご：2005/07/31(日) 23:47:04: Lua+Carbonを使ったゲーム開発環境は軌道に乗りつつある。
とは言え、データの扱いや開発インターフェースなど問題は
たくさんある。
データがテキストで扱えるようなものならLuaスクリプト形式で
出力するようにすれば読み込みは楽になる。それ以外はファイルで。
開発インターフェースはずいぶん先の話になるだろうから、
今はまだ考えないでおこう。
90：ぷご：2005/08/02(火) 01:32:26: 今日はMLTEを使ったフィールドの実現。
クリックで選択して文字を入力できるようになった。
文章入力中もidleハンドラが動くのが愉快。

そして終了時に必ず「予期しないエラー」で落ちるようになった・・・。
91：ぷご：2005/08/02(火) 07:46:25: グラフィックは基本的にペイント形式を使うことになると思う。
カードグラフィックではなく、PICTボタンの絵を編集できるような
感じにしたい。レイヤーとして使える訳だ。
透明度を持たせてテキストなどすべてアンチエイリアス。

・・・なんか重そう。描画をOpenGLに出来ないかなぁ。
92：ぷご：2005/08/02(火) 07:58:35: ボタンの周りが相当大きな範囲で白くなってしまうのが困る。
自前描画が必要なのか？そいつは苦しい。
93：ぷご：2005/08/03(水) 01:16:00: ボタンの周りが白くなるのはkWindowCompositingAttributeで解決できるようだ。
ウィンドウをメタルにも出来る。

今度はウィンドウへのクリックが効かなくなったので回避方法を探さないと。
94：ぷご@疲労困憊：2005/08/04(木) 00:29:10: 風呂敷がだいぶ広がってきたので、まとめないとまずいな。
PgColorXみたいにはじめは単機能に絞っておいて、
あとから機能を足していくのが現実的でしょう。

Luaによるゲーム開発環境として出来るだけ早く公開したいけど、
仕事が本格的に忙しいので時間が取れそうにないです・・・。
95：ぷご@ちょっと復活：2005/08/18(木) 02:19:39: kWindowCompositingAttributeを使うと
MLTEフィールドが反応しなくなるのはなぜだろう。
96：ぷご：2005/08/19(金) 01:28:57: HIViewを使えばいいのか？HITextViewとか。
そこまでやってる暇がないので、テキストはDrawStringでいいか・・・。
97：ぷご@もう26歳か：2005/08/20(土) 02:18:36: MacBeatやpugoGLやPgColorXからコードをコピーしてきている。
Lua+pugoGL+PgColorXみたいな感じになるのかな。なんか違うなぁ。
98：ぷご@まだ26歳だ：2006/02/08(水) 23:26:26: XULRunner良いのかな？
調べてみたいと思うが、最近Xcode触ることもないな。