ProjectBuilderでゲーム製作 - 1062602712

1：ぷご：2003/09/04(木) 00:25: Cocoaで作るのか、OpenGLを使うのか、core graphicsで頑張るのか、Carbonも重要だ、そして役立ちツールは？

疑問と悩みの尽きないMacOSXでのゲーム開発について議論し尽くしましょう。
2：ぷご：2003/09/04(木) 00:29: Cocoa + Objective-C で適当に作ると遅かった。やはり遅かった。
処理速度を要求されないゲームを作るのには非常にいいけれども。

OpenGLではゲーム専用の感じが強すぎて、応用が利かないのでは？
というわけで、core graphicsに興味津々。Quartzともいう。
3：ぷご：2003/09/04(木) 00:31: 複数キー入力はCarbon使ってGetKeysやらないとだめなのかなぁ。
きじばとさんのところにあるHIDのサンプルあるけど、難しそう。
4：ぷご★：2003/09/07(日) 20:34: core graphicsをCocoaで使うサンプルってないのかなー。
NSViewやNSImageと組み合わせるやり方が分からない。

Carbonで使ったほうがよいかな。
すでにGetKeys使ってCocoa+Carbonになっているし。
5：き：2003/10/02(木) 00:03: パッドの使用は思ったより素直で難しくなかったですよ。

入力の快適さは、特にアクション系のゲームの面白さに直結しますから、
より多くの作品がHID対応になってほしいですね。
最近はフォースフィードバックとか楽しい技術もあるようですし。
6：ぷご：2003/10/03(金) 00:30: パッド持ってる人ってどれくらいいるんだろう？と思ってしまうのですけどね。
結構多いのかな？僕も以前持ってましたし。
本格的なアクションかシューティングを作る時には対応しないといけませんね。

とてもそこまでのゲームが作れる技量には至りそうにないです。
7：ぷご：2003/10/12(日) 22:47: 現在Carbonでプログラム作成中。
ProjectBuilderだとOSX専用のものしか作れない。
Classic用にはMPWで作ればいいか。

MPWでClassicアプリ作るよりはかなり楽です。
Cocoaよりも慣れてる分簡単ですし。
仕事でC使ってるのが生かせますし。
C言語だと他機種への移植が楽ですし。
GUIを楽に使えないのがデメリット。ゲームではあまり関係ないです。

リソースはResEditで開けないのか？
8：ぷご：2003/10/13(月) 17:45: リソースはResEditで開けた。
ビルドしたアプリケーションを一度捨てたらOKでした。

パッケージの内容を表示して、その中に本体があるという構造。
9：ぷご：2003/10/13(月) 19:45: >>8
それやるとアプリが起動しなくなった。
アプリにリソースフォークを持たせてはいけないのか。無念。

別にリソースファイルを作るかな。
10：ぷご：2003/10/17(金) 00:51: カレントディレクトリの取得方法
http://developer.apple.com/ja/technotes/tn2015.html

cicnはGetCIconでないとうまく取得できない。GetResourceが使いたいのに。
11：ぷご：2003/10/18(土) 01:52: Carbonでは「いますぐ画面を更新したい！」というのはどうするんだろう？
MacOSX Carbon Programming Guideに載ってたかな？

「オフスクリーンから画面へのコピーはOS側（プロセスマネージャ）
　の管理で定期的に行われると思います（たぶん）」

たぶんってなんだよー。
12：ぷご：2003/10/18(土) 02:10: QDFlushPortBufferを使うのか。ふむふむ。
いや、うまく反映されないような。
13：ぷご：2003/10/18(土) 02:32: ああ、バグがあってQDFlushPortBufferを読んでいなかっただけだった。
14：ぷご：2003/10/23(木) 01:11: WaitNextEventがやたら遅いな。
1tickを指定したら､ほんまに1tick待ってる感じ。
15：ぷご：2003/10/23(木) 23:38: 64*64pixel,16bit colorの画像を120回転送。
これでiBook/700で60fpsくらいでる。

HyperCard+PgColorXの5倍ほど。よし、まぁまぁだな。
単なるCopyBitsの練習だけど。
16：しんた51：2003/10/25(土) 01:16: オヒサしぶりです。
オフスクリーンというと、OpenGLの拡張機能で高速転送しているらしいですね。
ATIだとかOSのバージョン違いで速度に随分差が出るみたい。
QDはオーバーヘッドが凄そうなので、自前描画の方が速いのでは？
17：ぷご：2003/10/25(土) 04:56: こんばんは。

QuartzExtremeはグラフィックアクセラレータ使うんで、かなり強力です。
でも非対応機種だと遅いままなのが残念。

自前描画はpugoGLの経験でダメと結論付けました。
速くても、ゲーム作るのが面倒になるなら意味が無いです。
それに、自前描画よりもOpenGLのほうが良いです。
CPUが仕事しない分、他のことできますし。

OpenGLを使わない理由は、3Dに興味が無いのと、
ソースを公開して参考にしてもらうためです。
18：ぷご：2003/10/25(土) 13:22: NewGWorldのオプションでuseDistantHdwrMemを使って
VRAM上にGWorldを配置できる。

でも速度変わらず。既に高速になってた模様。
OSのバージョンによっては効くかも。
19：ぷご：2003/10/26(日) 00:50: 本日より、「PBでゲーム制作」改め「XCodeでゲーム制作」です。
ゲームだけを考えている訳じゃないですが。
20：ぷご：2003/10/30(木) 00:17: もしや、Xcodeって使いにくい？
伝統と信頼のProjectBuilderのほうがいいのか？

まぁ、慣れの問題だなこれは。
21：し51：2003/11/02(日) 19:14: ううむ、Xcode使いにくいです…（笑）
Mac以外でも開発する人にとっては、慣れるにも結構な負担が…
22：ぷご：2003/11/02(日) 20:57: うう、やっぱり使いにくいのか。
Appleのソフトはいつも使いやすい事が魅力だったのに。
23：ぷご：2003/11/05(水) 23:05: Xcode1.01アップデータが出たよー。
ファイルのデータの破損または消失を修正したらしい。
そんなんで大丈夫な品質なのか？
Pantherに無理矢理間に合わせただけのような。
24：ぷご：2003/11/26(水) 00:10: http://homepage.mac.com/mkino2/backnumber/2003_11.html#November%2024_1
↑やっぱりCだよ、C！という意見。

やっぱり基本はCだと思うね。HyperTalkの動作も
裏でCが動いているイメージがあれば理解しやすい。

Cの動作はアセンブリ言語が分かれば理解しやすくて、
アセンブリ言語は論理回路が・・・とは続かない。

Cで事実上最高のパフォーマンスを出せるし、
巨大なアプリを構築できる実績があるから。

悪い部分もあるけど、それはCをやってからのお話。
25：ぷご：2003/12/22(月) 00:00: XcodeでnibベースではないCarbonアプリケーションは
新規プロジェクト作成できないようだ。

えーい、無理矢理作ったれ！
26：ぷご：2003/12/30(火) 12:13: Carbonでゲーム作成中。

メモ。
GWorldの領域がVRAMに取られるかメインメモリに取られるか
分からないので、useLocalHdwrMemでメインメモリに取る事で
半透明などの動作は速くなる、と。
27：ぷご：2003/12/30(火) 15:35: 構造体のメンバの順番。
Pointがv,h
Rectがtop,left,bottom,rightの順番になっている。

HyperCardからの移植がやりにくいなぁ。
28：ぷご：2003/12/30(火) 15:37: >27
Carbon以前から、そうなんだけどね。今気づいた。
昔の僕は構造体の初期化を使ってなかったんだなぁ。
29：ぷご：2004/01/03(土) 21:53: クイックターイム！
たしかpugoGLで使ってたのでコピーしてくる。
動かねぇ。インクルードファイルが足りないようだ。
<QuickTime/QuickTime.h>をincludeする。
関数が無いとか言いやがる。ちきしょう。
プロジェクトにQuickTimeのFrameworkを追加する。
これでOKだった。

またそのうち忘れたときに見直せるようにメモ。
30：ぷご：2004/01/12(月) 12:48: ＜実行環境＞
Classic(CFM)：OS9.xとそれ以前、OSXのClassic環境で動作。C,C++などで開発。CW,MPW
Carbon(CFM)：OS8.1～OS9.x、OSXで動作。C,C++などで開発。CW,MPW
Carbon(Mach-O)：OSXで動作。C,C++などで開発。CW,PB
Cocoa(Mach-O)：OSXで動作。Objective-CかJavaで開発。PB
なお、CocoaとCarbon(Mach-O)は併用可能。
＜グラフィックAPI＞
QuickDraw：初期Macからの2DグラフィックAPI群。Classic,Carbon。
Quartz/CoreGraphics：OSXでの2DグラフィックAPI群。CocoaとかCarbonに関係ない、ベースの部分。
OpenGL：OSXでの3Dグラフィック環境。WIn,Unixでも動作。OS9以前だと互換ライブラリを使用出来る。
　　　　　OSXで3Dのアクセラレータを有効にするにはこれを使うしか無い。
＜ライブラリ（参考）＞
SDL：Mac,Win,Unixで互換性があるグラフィックライブラリ。よく知らないけど。
GLUT：OpenGLを簡単に扱えるようにして、マウス、キーなどの各種APIも
　　　　取り込んでMac,Win,Unixで互換性がある。これもよく知らないけど。

Classic-QuickDraw：OS9.x以前、Classic環境
Carbon-QuickDraw：OS8.1～OSX
Carbon-Quartz：OSX
Carbon-OpenGL：OSX、互換ライブラリでOS9以前も可。
Cocoa-Quartz：OSX
Cocoa-OpenGL：OSX

OS9以前を考えると、Carbon-QuickDraw、Carbon-OpenGLかな。
ゲーム作るならQuartzよりOpenGLのほうが楽そう。
作るのが2Dのゲームにしても。

僕はなんだかQuickDrawに親しみすぎてしまったな・・・。
ゲーム以外では使うのがためらわれるのでOpenGLは
敬遠していたけど、これからFinderすら3Dになるような気もするので、
OpenGLに移ろうかな。
31：ぷご：2004/01/18(日) 15:15: 訂正
CodeWarriorでもMach-Oで開発可能。
32：ぷご：2004/02/04(水) 22:28: Appleは何かと宣伝うまいよなぁ。
Xcodeにしろ、Cocoaにしろ、実際はそんなに大した事は無いし。
それなのにいかにも凄いように見せる。

Carbonもわりといい環境なんだよぉ。MPWも使いこなせば何かと役に立つし。
MacBeat Carbonもデバッグ時はXcode、コンパイル時はMPWとすることで、
ZeroLinkで公開して中身空っぽという失敗を防げるし、、、。
33：ぷご：2004/02/17(火) 22:53: MMO・SRPGでも作ってみたいなぁ。
来年にはサーバ環境ができるので（もう来年の話？）
構想でも暖めておきますかね。

Carbon版HyperCard構想と同じような暖め方ね。
作りたいけど作れないという。考えるのが面白い。
34：ぷご：2004/02/17(火) 23:03: サーバはMacOSXマシン。今使ってるiBookにでも入れれば電力は安くつく。
デスクトップのG5でも買って開発マシンとする。
回線は光。本気でやるなら２回線引くもよし。（金持たんかな・・・）

サーバ、クライアントともにCarbon、OS9でも動作する。
Mac専用部分は別ファイルに分けた作りになるので移植も可能。
Cocoaで作るとそうはいかない。Carbonのメリットとする。
使用言語は単なるC言語。ソースはフリーで。
35：ぷご：2004/02/17(火) 23:11: グラフィックは2D。OpenGLを研究して、パフォーマンスが良さそうなら採用。
回転や変形ができ、他機種へ移植可能。

グラフィックはモノトーンに色がついただけの程度のカラー画像。
画像の用意が楽で、複数人数で作っても差が目立ちにくい。
世界観にも強い印象を与える。

舞台はサイバースペース。グラフィックに合わせる。
ネットワークゲームという時点で既にサイバースペースなのだが、
そこで、さらにサイバースペースを表現する。
36：ぷご：2004/02/17(火) 23:18: 移動シーン：移動、会話、買い物などが行える。
　　　　　　お絵描き、画像表示、ファイル転送があるとなお良い。
　　　　　　人工無能との無味乾燥した会話も楽しめる。
戦闘シーン：限られた人数しか入れない。
　　　　　　S・RPGで戦闘し、シナリオを進める。

戦闘シーンはターン制を採用。１回の味方側ターンの時間のうち、いつでも１度だけ行動出来る。
戦闘の参加人数は決まっており、足りない場合はAIを使う。
戦闘シーン中の会話も可能。
37：ぷご：2004/02/17(火) 23:21: ネットワークインターフェイスとしてBSDソケットを採用。
って、OS9には無いじゃないか。だれか互換API作ってないのかな？
38：ぷご：2004/02/20(金) 23:34: ネットワークのメッセージはHTTPを元にする。
基本的にテキストのみ。

テキストのほうが拡張しやすく、分かりやすい。
性能はバイナリに比べて劣るが、拡張性を優先。
別のクライアントやサーバに転用も可能となる。
39：（　´ω｀）y-~ （G5PVvZZ2）：2004/02/25(水) 08:43: 問題は、

い　か　に　あ　り　が　ち　じ　ゃ　な　い　シ　ス　テ　ム　に　す　る　か

Macの世界じゃ、ＭＭＯＲＰＧ自体が片手の指で足りるほどしか存在しないようですが、
Winでは両手でも足りません（オープンベータテスト含む）

しかし、現実問題、
・モンスターハント
・他人との取引
・アイテム合成
・他人との戦争
大体この４つの要素で要約させられてしまうのです。

私が思うに現在はＭＭＯＲＰＧバブルです。
コリアンがものすごい勢いでＭＭＯＲＰＧを増産している以上、
間違いありません。
しかし、いずれは崩壊する危険性があります。
ゲーマー人口もゲーマーの時間もお金も無限ではないのです。

というか、発想を飛躍させ、世界を造るＭＭＯＲＰＧなんていうのはどうだろうかとか。
基本的に世界の初期のＮＰＣは人材を用意してくれる人材所だけ。
武器すらまともに手に入らない。
しょうがないので、モンスターと戦い、いろいろなものを手にしていく。
いろいろなものが手に入ったらそれを組み合わせて世界を発展させるものを造ったりとか。
40：創基：2004/02/25(水) 16:47: 私もサーバーを手にしてからずっと考えてはいるのですが良いアイディアってなかなか出ませんね。
すべてをこちらから提供するには限界があるので、ユーザーに一部を委任しようと考えてます。
ここはRPGの原点TRPGができるようにするのがよいかなと考えてます。
ブロードバンドが普及してデータも高速に運べるようになったことですし、GMもユーザーにやらせてしまいましょうってことです。
ゲームサーバーに接続するクライアントソフトが二種類あって一つは一般プレイヤー用、もう一つはGM用。
ゲームサーバーの機能は一般プレイヤーをGM用ソフトが立ち上がっているクライアントに接続するだけ。
どんなマップ、どんなシナリオを用意するかはGM次第ってのが面白そう。
GM用のソフトはオープンソースにして拡張できるようにしておくのがベターですかね。
ク・リトル・リトル神話みたいに参加型で世界を作ってゆくゲームなるといいなぁ。
問題はゲームバランスをどうするか。
いかなるアイテムでもGMが提供できるので強力なアイテムを容易に創りだせるんですよね。
どこに制限を置くかが難しい。
やはりエクスカリバーはアーサー王しか持ってはいけないから。

上の世界を造るMMORPGも一度考えたことがあるけどちょっと問題があるんですよね。
プレイヤーに世界を構築させることがゲームの中心で面白さの核心とします。
モンスターが落とすものやマップから拾えるものを材料にいろいろなものを造ってゆきます。
この前提では、ゲーム内に存在しないものを生み出すことができません。
作者の意図した範囲内でしか世界を構築させることができず、ゲームに大きな制約が付いてしまいます。
シミュレーションゲームのように組み上げては壊しを繰り返すゲームならいいんですが、MMORPGには難しいかと。
世界が飽和した後に面白さが残りません。
41：ぷご：2004/02/25(水) 21:19: ありがちじゃ面白くないですが、それ以前に
ベースシステムをどうするか、という問題で困るんですよね。
MMORPGバブルは終わるように思いますが、ネットワークゲームは
ずっと続くものだと思います。

世界を造る、ね。モンスターと戦う事で新しいものを作り出せる、
というのは楽しそうですね。ダンジョンも造れると楽しいかな。
シナリオも、、、ってそれだと創基さんの案になるか。
42：（　´ω｀）y-~ （G5PVvZZ2）：2004/02/25(水) 21:51: シヴィライゼーション風でいいんじゃないの？
プレーヤーが一生懸命試行錯誤して発展のための材料を手に入れ、
（ものによっては当然一人ではどうにもならない莫大な量が必要だったりする）
他国間戦争もあったりで、文明が簡単に滅びたり。
もちろん頻繁に戦争があったら洒落にならんので、
週１回程度に制限と。

・・・うーん一皮向けてはいるが、やっぱり、作業ゲーという領域は、
どうにもならんものなのかねえ。
43：創基：2004/02/25(水) 22:14: 私はベースのシステムはアップレット＋サーブレットのJavaタッグで行こうと考えてます。
ソケットをガシガシ使えますし一つの言語でサーバとクライアントを作れるのが強み。
ただし、マスターするまで道は果てしなく長く‥‥　しかも遅い。
移植性を考えると妥当かなとも思いますが。

作者の意図した遊び方と意図しない遊び方をどう扱うことにするかも重要ですよね。
チートされるのは困るけど、新しい面白さをユーザーが開拓できないのも困る。
作者の手を離れたところでユーザー全員が長く楽しんでくれればいいんだけど。
誰かが楽しむと誰かが被害を被るってことも多いしなぁ。
ネットワークゲームでは金銭的な被害は起こりにくいけど、精神的な被害が現実社会より大きな意味を持つ。
気分を害したってだけで大きな問題になるので困った者です。
遊び方のスタンスの違いでもめることもめること。

取りあえず、Javaで普通のRPGを作ってから続きは考えようかと思っています。
44：ぷご：2004/02/25(水) 23:20: >42
う～ん、ネットワークゲームである必然性は薄いかな。
僕はMMORPGはメッセンジャーソフトの延長で考えてます。
>36にお絵描きやファイル交換が入っているのはそのため。
音声や映像はいらないので、お絵描きが欲しい。

>43
移植性で言えばJavaは非常に良いですね。
遅いのも、HCに比べれば我慢出来る範囲。

FLASHはどこまでできるのかというのが気になってます。
手軽さで言えばブラウザから出来るのが最高です。

遊び方は出来るだけ自由にしたいんですけどねぇ。
悩みどころですね。まぁ、作りもせずに心配しても
仕方が無いんですけど。
45：（　´ω｀）y-~ （G5PVvZZ2）：2004/02/26(木) 01:18: >43
金銭的被害は皆無どころじゃないですよん。
ＲＭＴとか、大規模ＭＭＯＲＰＧでは当たり前のように行われていますからね。
そして、それに漬け込む詐欺も出てくるわけです。
また、他人のアカウントを奪い取って、そのアイテムをＲＭＴしたりってこともありますね。
46：ぷご：2004/02/27(金) 21:26: >45
金銭的被害はゼロじゃないけど、あまり考える必要はないかな。
個人レベルで作るものならね。
47：創基：2004/02/28(土) 01:14: ぐ、メールを入れるのがめんどくさい。

>45
作者が直接金銭的なトラブルに巻き込まれるの方が可能性は低いってことです。
精神的な問題はユーザーが去ってゆくという直接的な結果が表れますからね。
大規模MMOPRGでも制作者サイドがアイテムの売買を斡旋したりはしませんよね。
えっと補足、売買ってのはゴールドではなくエンで行う交換です。

逆にエンによる交換を制作者サイドが公認したとするとそれはそれで面白そうですね。
昔、アクアゾーンの魚はデータが販売されていた。
一度魚が死ぬともう同じ魚は読み込めなくなるので20匹購入とかそういう形になってたと思います。
あれをアイテムでやれば、歳くったゲーマーが帰ってくるかも知れませんね。
金はないけど時間のあるプレイヤーはモンスターを倒してアイテムを集める。
時間はないけど金のあるプレイヤーは制作者サイドに入金してアイテムを集める。
就職して一日1時間も遊べないユーザーはどう頑張ってもヒマを持て余したガキには勝てません。
制作者に多く金を払った人が楽しめるゲームってのは制作者サイドとしてとても正しい。

>44
Flashは初期投資がいるので触れそうにありません。
今のところグリーティングカードぐらいのレベルのものしか無さそうです。
サーバーとのデータ交換もhttp経由のみでストリームが使えないみたいです。
常にデータ交換を必要とするMMORPGには荷が重そうです。
48：ぷご：2004/03/02(火) 00:05: >47
Flashでやるとしたら、Flashでできることをやりますよ。
JavaScriptよりは楽で、ミニゲームには向いてるかなと。
本当に作りたいのは大物ゲームなんですけどね。
49：し51：2004/03/08(月) 19:04: 昔お勤め先で又聞きしたんだけど、
一人で小規模MMORPGをJAVAで製作・運営してる人が居まして、
それはもう毎日が大変らしいという話。
寝ても覚めてもユーザーサポート、メンテにアップデートに鯖落ち対処で
バイトもしないで広告収入だけで何年も喰ってるとか。
一度始めたら辞めるか廃れるまで覚悟が居るみたい…。
サイト、ゲーム名忘れちゃったので今も継続中かどうかは不明ですが。
50：ぷご：2004/03/09(火) 01:00: >49
そいつは大変そうですね、、、。考えてるだけだとサポートも何も要らないので
構想だけ膨らんでいくのですが。
51：（　´ω｀）y-~ （G5PVvZZ2）：2004/03/12(金) 00:24: とりあえずVMみたいなのを製作・運営することをキボンヌ。

しかしまあ、あれはクリエーター・ユーザーともにドキュソ級の
人間が勢ぞろいしたって感じだね。

クリエーター側は後先省みずに一部のユーザーに特権を与え、
その一部のユーザーがその特権を履き違えてクリエーターを強迫する。

とりあえず、VMは死んだね。
首に紐をくくりつけて遊んでいたところを強引に引っ張られ窒息死したような感じ。

よい意味だけでなく、悪い意味での教訓になったことだろう。
52：ぷご：2004/03/12(金) 00:51: >51
ノーコメント、としておきます。
53：創基：2004/03/16(火) 17:19: ネット上を彷徨っていたところおもしろそうなTRPGを発見。
http://www004.upp.so-net.ne.jp/babahide/library/paranoia.html
これは人を相手にするから面白いって代物。
ネットワークゲームを造るならこういったモノを造りたいものです。
現在のMMORPGはアイテムを交換するにせよ殺しあうにせよ相手が人である必要性が少ない。
ただ、そういった機能をNPCに持たせていないだけで十分持てるものばかり。
人を相手にしているからこそ面白いってことがネットワークゲームの真髄のはず。

>51
裏側で何が起こっていたかはよく知りませんが、表のゲームだけ見ても問題点はあった気がします。
ゲームバランスとしてパワープレー以外の作戦が立てれないという問題があったように思います。
天使のいたずらが強力すぎた結果ですが。
最低でも2～4種類程度レイザーの組み方の方向性が欲しかったと思う。
作戦性戦略性が低すぎたように思う。
54：（　´ω｀）y-~ （G5PVvZZ2）：2004/03/16(火) 19:35: パラノイアきたか！

しかし、これをMMORPGにすると１８禁確定だね。

一部ではやっぱり戦略性だという流れがあります。
そんなことはさておき、先行１ターン目、魔法出して終わり。
これに対しての後攻の対抗手段。

やっぱり運ゲーその次に戦略ゲー・財産ゲーという感じもします。
情報が少なすぎです。
もっともマジックみたいに平地三枚タップして裏返しで何か出てきたら、
１００回に９９回はあのむかつく天使だから、
次のターンからやばすぎるから早く除去しないと・・・
というのも問題ですが。
55：（　´ω｀）y-~ （G5PVvZZ2）：2004/03/16(火) 19:49: まあ、とにもかくにも、
デバッグという意味でのテストプレイではなく、
バランスという意味でのテストプレイは、３人じゃとてもじゃないが足りないね。

その昔、MoMAという、非常に馬鹿げた事態が起こりました。
１ターンキルが５％ぐらいで発生し、
序盤先攻決めるコインフリップ、中盤初期手札の引きなおし、終盤最初の数ターン
なんていうひどい言われようもありました。

現在のように２ターン目に4/4クリーチャーが出てくる程度ならまだかわいいのです。
対策を立てる猶予がありますから。
１ターンキルにあった側はまず何もできないのです。

専門にして飯食ってきた会社でも、こんな馬鹿げたことがありますからね。
最低１０人。できれば２０人ぐらいドカンと。

こういうゲームにリアルマネーがかかっていたら、
さぞかし、強運の持ち主決定戦大会・賞金つきになるでしょうな。
56：（　´ω｀）y-~ （G5PVvZZ2）：2004/03/16(火) 20:19: ただし、MoMAデッキへの最強クラスの対抗方法して、
土地だけ１０００枚デッキというのも可能だが、
はたして、それをゲーム、あるいはメタゲームといえるのか？
といわれると激しく疑問。

まあ、もっとも、こんなデッキではMoMA以外のデッキに負けるがね。

http://jicchan.hp.infoseek.co.jp/data/decX/MoMa.html#at
57：ぷご：2004/03/17(水) 21:20: >54-56
何だか分からんけど難しそうですね
58：（　´ω｀）y-~ （G5PVvZZ2）：2004/03/18(木) 17:29: 簡単な話、
メジャーな勝利手段A(肉体的に倒す)とマイナーな勝利手段B（精神的に倒す）があって、
マイナーな勝利手段Bを超高速で目指すのがMoMAというやつです。
それ以外に強引に勝利をもぎ取るもっとマイナーな勝利手段Cもありますが、
関係ないし、そんなデッキも大規模な大会では３～４つしか存在してないので除外。

勝利手段Aを防ぐには並大抵のことではありません。
間接的にはいくらでも防ぐ方法はありますが、
実際のところ、完全な対策はありません。
勝利手段Bはそれよりは簡単です。
こちらはライフとは違い、初期時点でいくらでも増やせますから。
当然、その見返りとして、偏りという代償が発生しますが。

とりあえず、カードゲーム風ゲームをつくる人には、
マジックはせめて歴史は知ってほしいし、できればやってもらいたいね。
コストがないというのはどれだけ恐ろしいことか、
ゲームが超高速化するとどれだけつまらないゲームになるかとか。
59：（　´ω｀）y-~ （G5PVvZZ2）：2004/07/21(水) 01:34: VM滅亡。

この滅亡はクリエーターのための標である。
未来のためにこの標を決して忘れてはならない。
60：（　´ω｀）y-~ （G5PVvZZ2）：2004/07/21(水) 11:43: http://www.vector.co.jp/vpack/browse/person/an012243.html

キター！
61：ぷご：2004/07/21(水) 22:25: 何が来たんだー！？・・・ProjectBuilder関係ねぇ～！
62：（　´ω｀）y-~ （G5PVvZZ2）：2004/07/22(木) 14:01: ま、これによってRの中の人たちも動かざる得ないでしょうな。
年末までに出なかったら詐欺みたいなもんですね。

ただ、ゲームシステムがESのGBで出たゲームに酷似しているということに気がついてるか謎ですが。
63：（　´ω｀）y-~ （G5PVvZZ2）：2004/08/02(月) 20:53: http://ogapee.at.infoseek.co.jp/onscripter.html
これってクラシック環境＆68Kにも移植できる？

makefileの作り方がいまいち謎。
64：（　´ω｀）y-~ （G5PVvZZ2）：2004/08/02(月) 21:32: http://ogapee.at.infoseek.co.jp/onscripter.html
これってクラシック環境＆68Kにも移植できる？

makefileの作り方がいまいち謎。
65：ぷご：2004/08/04(水) 01:08: そりゃやる気次第じゃねぇ？
66：ぷご：2004/08/20(金) 15:51: MacOSX10.3ではウィンドウは一度バッファにためてから描画するのが普通。
10.2ではできたんだっけ？
いや、10.3でも直接描画できたっけ？

もちろん、直接VRAMに直書きすることは今でもできるはず。
こんな疑問形だらけの書き込みでは、何の役にも立たないなぁ。
67：ぷご：2004/08/21(土) 18:00: Xcode1.5が出てたことを思いだしてダウンロード中。
500kbpsしかでないADSLだと少し重い。
68：i：2004/08/30(月) 22:20: ドキュメントがかなり変わった、ぐらいかなあ？>1.5
初めまして。
69：ぷご：2004/09/02(木) 23:17: >68
・・・今頃気づきました。初めまして。
僕はドキュメント読まない（読めない？）ので、特に変わらないかな。

Xcode実はまだ落としてなかったので、落としますかね。
ADSLと違って回線が切断されないのが良いね、寮ネットは。
70：ぷご：2004/09/04(土) 20:05: 長らくサイトが放置されていましたが、
みすどさんのGood PeopleがCarbon化されています。
http://misudo.com/
71：（　´ω｀）y-~ （G5PVvZZ2）：2004/09/11(土) 09:37: http://www.bluesnews.com/files/idstuff/source/quake2.shtml
地震２ソース
72：ぷご：2004/09/11(土) 22:17: ごめんなさい、そんなソースは僕が見ても何の役にも立ちません。
高度すぎるし、ゲームを作る気も無くなってしまった・・・。

誰かすごい人、役に立てて。
でも本当にすごい人ならこんなもんじゃないけど。
73：（　´ω｀）y-~ （G5PVvZZ2）：2004/09/12(日) 07:19: せめてPgColorXつかってドルアーガ風ルーティア開発でも希望。

ストーリーは邪神降臨、世界大洪水、邪神退治に塔を上ると。
もちろんタイムの代わりに下から水が襲ってくると。
水に浸かってしまったらアウト。

ある条件をクリアしないと宝箱が出ない＆その宝箱を取らないとクリア困難orクリア不可能。
で条件の例として、
・２００回ジャンプ
・５秒間操作しない
・２秒間自由落下する

とか。
74：ぷご：2004/09/12(日) 22:53: ゲームをプレイする気がないと、ゲームは作れないんです。
僕の求めるものは、そこには全く無いんです。

でも、どこにあるのか分からない。僕の求めるもの。
75：（　´ω｀）y-~ （G5PVvZZ2）：2004/09/13(月) 20:52: ま、夢と希望持て。
こころの健康に悪い。

だが、俺には夢も希望も持てない。
そんなのとは無縁な生涯を送る宿命だからな。
76：ぷご：2004/09/13(月) 22:13: 夢と希望が「ここには」無い。

しかしまぁ、74の文章でよくそこまで理解できましたな。
77：（　´ω｀）y-~ （G5PVvZZ2）：2004/09/17(金) 15:14: それはぷご様が俺よりも１レベル上のサトラレ能力を持ってるからだ。

と冗談半分でいってみる。
78：ぷご：2004/10/04(月) 00:09: ん、やね氏のはてなダイアリーでクォータービューの描画順の問題を解説してくれるらしい。
このお題は某所でさんざん議論したので、興味深いな。

僕は「3すくみ状態になるので絶対に無理。」が結論だったが、さて。
79：ぷご：2004/10/04(月) 00:22: やね掲示板も読んでみる。
って、あのスレの時点で解決したんじゃなかったのか。

ちなみに現在の僕の到達点は、
「3Dにするならポリゴンにしたほうが見た目が良い」
「2Dにするなら平面でやったほうが分かりやすくて良い」
だったりしますが。
80：ぷご：2008/03/15(土) 22:39:37: このスレが立って4年半の月日が流れた。
ProjectBuilderという名前はもう忘れられて、Xcode3.0になっている。
漢字Talk時代の開発者は見かけなくなり、OSXになってからMacをはじめた人たちが増えた。

で、、、今からXcodeでアプリ開発始めてみようってのはどうなのか？
ProjectBuilderの頃のCocoaよりだいぶ使いやすくなってるし、
情報も充実してるから、今から追いかけてみますかね・・・。

iPhone向けの開発ってのも面白いテーマだしね。
81：ぷご：2008/03/16(日) 22:26:47: PGO BOX 360始動！
（何にもないけど）
・・・なんか接続が異常に不安定です。
so-netさん大丈夫なんでしょうか？

http://www012.upp.so-net.ne.jp/PGO/
84：ぷご：2013/10/29(火) 08:19:58: ブラウザ上で昔のMacがシミュレートされてる。
HyperCard Playerもある。ものすごい再現度。
http://jamesfriend.com.au/pce-js/