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
そいつは大変そうですね、、、。考えてるだけだとサポートも何も要らないので
構想だけ膨らんでいくのですが。