ゲームにおけるデータ ..
241:名前は開発中のものです。
08/07/20 03:05:04 x+htBSIe
ソースがあるだけマシだよ
アーケード版のバイナリだけ渡されて
「これをPS2に移植してください。ソースは紛失してしまいました。」
と言った大田区の某大手ゲーム会社があったそうな。
242:名前は開発中のものです。
08/07/20 03:08:22 ZbM+kRVz
>>241
すみません… それ、たぶんウチだ orz
243:名前は開発中のものです。
08/07/20 03:39:46 18o8S9Zj
最悪だなそれ
MAMEでも進呈したほうがいいな
244:名前は開発中のものです。
08/07/20 15:36:02 gpI6Slf5
オブジェクト指向のくずれてるウンココードに出会ったらどうしますか？
245:名前は開発中のものです。
08/07/20 17:18:51 g88tpUo2
見なかったことにする
246:名前は開発中のものです。
08/07/20 17:43:16 1Zabkxz6
それ俺だな。
どうやれば良いか分からないから、手探りで書いてる(´・ω・｀)
247:名前は開発中のものです。
08/07/20 22:53:25 zgBZw03q
シングルトンで作ったクラスが2つや3つもインスタンスを生成することになったら破綻しない？
248:名前は開発中のものです。
08/07/20 23:02:17 Tcsf7iZJ
>>247
各フィールドやメンバ関数がまるごとstatic宣言されていない限りは、破綻しないと思うよ。
数に制限のあるリソース(or デバイス)を取り扱ってる場合は、セマフォか何かで排他処理とかロックとかが必要になるかもしれないけど。
249:名前は開発中のものです。
08/07/20 23:02:30 USb+9tXO
どういう意味？
シングルトンが2つも3つもあるならそれはシングルトンじゃないし
シングルトンのインスタンスがさらにインスタンスを生成するようなメソッド持ってても別に破綻しないけど？
250:名前は開発中のものです。
08/07/21 01:05:54 9zclfNbN
>>247の文章が破綻
251:名前は開発中のものです。
08/07/21 14:17:23 Y7Mzeak+
コメントにシングルトンと書かれてるのに２つも３つもインスタンスが
出来てる、辞めた先輩の残した謎コードって事ですね。わかりませn
252:名前は開発中のものです。
08/07/21 18:53:57 9zclfNbN
XBOX360, PS3, Wii 売れ行きに関係なく、開発しやすいプラットフォームはどれ？
253:名前は開発中のものです。
08/07/21 18:54:50 NGr1sFSW
箱○
254:名前は開発中のものです。
08/07/21 23:51:13 yo6BY71C
箱○は個人で十分開発できるからなぁ
255:名前は開発中のものです。
08/07/22 00:00:52 grvq6f3A
箱○ 天国
Wii 普通
PS3 言わせるなｗ
という感じか？
256:名前は開発中のものです。
08/07/22 00:03:34 9zclfNbN
>>255
詳しく
257:名前は開発中のものです。
08/07/22 00:08:34 zCVKhHD7
お前ら本当に3機種の開発ツール使ったことあるのかとｗ
258:名前は開発中のものです。
08/07/22 00:21:20 inlA4ozd
なんで個人開発限定なんだよ
259:名前は開発中のものです。
08/07/22 00:35:03 88jYUtHh
XNAのことを言ってると予想
260:名前は開発中のものです。
08/07/22 02:21:06 TRIzaodv
XNAの市販ゲームが出たってニュースは前に見た気がするけど
実際どんなもんなんだろ
261:名前は開発中のものです。
08/07/22 02:44:01 kfP9Fty3
サターンのSBL,SGLしか使ったこと無い
262:名前は開発中のものです。
08/07/22 02:45:19 zCVKhHD7
360(XNA)、Wii(インターネットチャンネル)、PS3(YellowDogLinux)という話？
263:名前は開発中のものです。
08/07/22 16:12:48 k5fUsZQo
Wiiはインターネットチャンネルどころじゃない
264:名前は開発中のものです。
08/07/22 18:29:14 c7QeI/ED
ゲーム機はDirectXを使うの？
265:名前は開発中のものです。
08/07/22 18:36:04 Jekk8SUv
DirectXはMSだけ
あ、Dreamcastという例外があるか
266:名前は開発中のものです。
08/07/22 20:52:26 6od3yLDu
ゲーム機ではないが、アーケードの基盤がWindows系というパターンはあるな。
DirectXそのものを使ってるかどうかは知らないが。
267:名前は開発中のものです。
08/07/25 15:29:12 9vpYBrtF
やってみて、無理と判断され、チームを外されることってある？
268:名前は開発中のものです。
08/07/25 20:06:41 66T6bhjF
>>267
板違い
プログラマー＠2ch掲示板
URLﾘﾝｸ(pc11.2ch.net)
269:名前は開発中のものです。
08/07/26 01:19:05 +2uolo1R
いつしかスレ違いな話題ばかりになってるな。路線復帰しようぜ。
270:名前は開発中のものです。
08/07/26 02:28:02 Esaqa0cW
アドベンチャーゲームの画面クリックやら動的に変化しまくるコマンドとかはどうやって管理してるんだね？
271:名前は開発中のものです。
08/07/28 18:13:52 9GhNVVJ3
前者は状態フラグの配列なり持っておけば十分だろ
後者はなんだ？状態フラグ読んで条件分岐すればコマンド変化はいくらでも管理できるでしょ
それともzorkみたいなやつかな。それだと構文解析が肝だろうなあ
272:名前は開発中のものです。
08/07/29 14:37:45 kHD6g876
>>271
なるほど。フラグの状態で、出るコマンドを制御すればいいのか。
サンクス
273:名前は開発中のものです。
08/07/31 18:14:30 ucHp1Nqp
メニューコマンドってみんなクラス化しているもんなのかな？
メニューオブジェクトを生成してどうこうみたいな。
274:名前は開発中のものです。
08/07/31 21:20:41 Gc2qBZ+R
ベタコードで記述したり構造体・配列のままより
クラスにしたほうがアクセスの統一をはかれる分いいかなぁ。
まーメニュー触るコードが一箇所ならどっちでもいいんでね？
ようはクラスにするしないじゃなくて
複雑さを無くしたり楽するためにどうするかだから。
275:名前は開発中のものです。
08/07/31 21:26:22 NXR7vyyv
フロントコントローラーパターンとコマンドパターンでやります。
276:名前は開発中のものです。
08/07/31 21:38:09 A+bu5iPx
メニューによるけど、FF風のメニューは別シーンにして、その中の一つ一つのコマンドは
だいたい同じインターフェースを実装してる。
277:名前は開発中のものです。
08/08/01 00:01:16 yD3o9/Uf
クラスメンバって全部privateにしてgetterでしか取得できないようにするべき？
privateにしたメンバをもつクラスを保持しているクラスから、そのprivateメンバにアクセスしたいときに
get()で呼び出すのが面倒なんだが・・・・publicならそのまま呼び出せるし
278:名前は開発中のものです。
08/08/01 00:11:49 yp70Uz6t
>>277
クラス使って日の浅い俺はset()、get()作りまくり。確かにメンドイ。
たぶん何か間違っている。
279:名前は開発中のものです。
08/08/01 00:14:41 GzWnlC6Z
>>277
俺も同じようなこと悩んでて、気がついたら両方混在してた。
「これはクラスじゃない、構造体なんだ！」
って言い聞かせながらところどころpublicにしてたりw
280:名前は開発中のものです。
08/08/01 00:22:47 z2aBgJTr
全部て
全部にgetter/setter作る意義って、メンバごとに独自処理必要な場合だろ
そういうの不要ならpublicなり言語の提供するアクセサメソッド簡略化機能とうかで構わんて
281:名前は開発中のものです。
08/08/01 00:28:14 4UGZmRTZ
排他制御や状態確認が不要ならどうでもいいかもだけど
コード書くのがマンドイだけなんじゃ？
まっしなIDEやプロパティのある言語つかうとかかな。
282:名前は開発中のものです。
08/08/01 00:32:32 GzWnlC6Z
>>280
例えば、「すばやさ」と「回避率」と「盾の大きさ」というメンバ変数があったとする。
仕様変更により、これら三つを「守備力」に統合しようとしたとき、
各メンバ変数へのアクセスが全てアクセサメソッド経由なら、
そのクラスの変更だけで終わってしまう(ごまかせる)というメリットがあるよ。
283:名前は開発中のものです。
08/08/01 00:36:38 z2aBgJTr
まて、そら元々アクセサの設計が統合可能だった場合だろ
すばやさにアクセスしても盾の大きさにアクセスしても「守備力」が変わるって設計で良いなら構わんが……
守備力を出すクラスなりが仲介して、他のパラメータを元から束ねてた場合の話って事かな。
ちょっとエスパー疲れるぞ？
284:名前は開発中のものです。
08/08/01 00:47:59 GzWnlC6Z
>>283
まあ、そういうこともあるさ(汗)
ここはお茶を濁しながら、オブジェクト間の結合を弱めましょうとか何とか言って、逃げようかな。
あと、全部アクセサメソッドつけたくなる理由は、Java beansに対応させるってのもあるな。
シリアライズしてXMLでデータを吐けるとか特典があったはず(要らない特典かも)。
285:名前は開発中のものです。
08/08/01 00:54:19 b/gVwGdZ
getterもsetterも持ってるメンバってのは、結局外から値をいじれるわけだから、
publicにした方が使う側は書きやすくでいいんじゃないの？と思うわけ。
ああ、でもsetterに値のチェックとか入れれるのか・・・・
286:名前は開発中のものです。
08/08/01 01:01:50 b/gVwGdZ
しかもget()で取得するのが配列だったりすると、
取得側で配列格納用の変数も用意しないと取得した配列の要素にアクセスできないし、
非常に手間。
287:名前は開発中のものです。
08/08/01 01:02:58 tFL87oCT
とりあえずpublicで書いていって、
気が向いたらprivateにして、
それまで直接アクセスしたるところを、
大河の流れのように涙を流しながら直せば無問題。
288:名前は開発中のものです。
08/08/01 01:07:26 b/gVwGdZ
>>287
なるほど。あまりスッキリしないやり方ですが、しょうがないですかね。
いちいちget()で呼んで、呼び側の変数のセットして使うのって、スループット高そうなのもイヤなんですよね。
289:名前は開発中のものです。
08/08/01 01:09:03 b/gVwGdZ
特にゲームだと毎フレームごとにいろんなものを描画するから、描画要素が多いとそれだけ呼び出しも増えるわけで。
290:名前は開発中のものです。
08/08/01 01:19:38 ua9U6ROu
c++での話だが速度はインライン展開されるの期待できるから問題ないし
メソッドが多くて中で使いまくるならclassで隠蔽。メソッド内でもget、set呼ぶ。
データの集合でしかなくメソッドが簡単な処理しかないならstructでpublic化かな。
コンストラクタ、コピーコンストラクタ、代入、比較演算あたりまでならstructで。
291:名前は開発中のものです。
08/08/01 01:32:56 b/gVwGdZ
>>290
こういうのって、センスが必要ですね・・・・。
ちょっと気になった事があるんですが、
自分のクラスのpublic関数が、内部で自分のクラスのprivateなメンバを使う場合、
わざわざgetterで呼び出して使う必要はないですよね？
class Foo{
private int a;
public int get(){ return a;}
public int calc(){
return get() * 2;
}
このようなcalc()の書き方に利点はあるのでしょうか？
292:名前は開発中のものです。
08/08/01 02:26:05 ua9U6ROu
getter,setterがpublicなら外部参照する可能性があるということで
内部だけで使うprivateメンバ変数と意識して区別できるとか
関数内のローカル変数と名前が被ってもメンバ変数を指してるのが一目瞭然とか。
命名規則で見分けられるようにするのが良いんだろうけどなるべくそうしてる。
293:名前は開発中のものです。
08/08/01 03:52:45 eorE7C0S
getterロボ
294:名前は開発中のものです。
08/08/01 04:12:11 gQhqelIh
メンバ変数の存在が setter/getter の追加みたいに public 部分に影響するのがおかしいんだよ。
まず public なインターフェースが決まって、その後で必要なメンバ変数を private で考えるのが筋だろ。
295:名前は開発中のものです。
08/08/01 18:37:49 YDkT93Ih
>>294
今まで作ってきたゲームの焼き直しなら、現実的なやり方だね。うん。
296:名前は開発中のものです。
08/08/01 19:02:25 m4Vy5Xwk
理想と現実はだいぶ違うよな
個人製作なら気に入らなければ壊して作りなおせるからそれでもいいけど
それにこだわって完成させられない場合が多い気がする
297:名前は開発中のものです。
08/08/01 20:43:12 mQpnHwPh
インターフェース中心の設計でプログラミングするんだったら
プライベートメンバ変数にはアクセッサを用意すべき。
単なるクラスだけでプログラムするんだったら、位置とか角度とか見たいなアクセス頻度の高い
メンバはパブリックのほうが良いかと思う。
298:名前は開発中のものです。
08/08/02 00:14:18 n2w2ONnP
ぶっちゃけ、片っ端からget/setにしたほうが、悩む時間を削減できて、完成が早まる（ﾄｲｲﾅw
299:名前は開発中のものです。
08/08/02 00:25:25 MidBaG0Q
しかしgetやsetが乱れ飛んで読みづらくなることも
300:名前は開発中のものです。
08/08/02 06:50:04 xZ8r6Jdx
>>299
プロパティが欲しいと。
301:名前は開発中のものです。
08/08/02 11:52:40 eytLWJfu
C#はそういう意味ではスマートだなぁ
302:名前は開発中のものです。
08/08/02 23:43:30 Pnu26psa
ゲームのシーン管理ってどうすりゃいいんだろう
303:名前は開発中のものです。
08/08/03 02:53:56 DVblpxWK
シーンつったってゲームによって全然違うからな
もう少し具体的に
304:名前は開発中のものです。
08/08/03 16:40:36 HN+lqKwd
>>301
現行のゲーム機はまだC++なんだよな
305:名前は開発中のものです。
08/08/03 21:47:19 XQeDRsrL
>>302
シーンってのが何を指してるのかが微妙すぎ。
VMCに分けろじゃないけど、
Visual面だけでシーンを切り分けるのがいい時もあるし、
Dataの読み込みや各種準備の時が切り分けにてきしてる場合もある。
そうじゃなくて、Loopを二つぐらい回しながら、
片っぽでバックの処理こなしつつリアルタイム進行で、
残りで、Interfaceを回してくタイプとかもあるし、
結局どんな処理が必要などんなゲームなのか？
どれを止めると不味いか、どれは止めても復帰させれば問題ないか？
とかによると思う。
306:名前は開発中のものです。
08/08/03 21:52:25 qGD4tU/f
シーンて、どのゲームも
タイトルー本編ーゲームオーバ
てな感じジャンか。細かいところは違えども。
ゲーム全体の状態遷移をどうするか聞いてんじゃないの？
307:名前は開発中のものです。
08/08/03 22:00:54 0ZCECk8O
おいどんのシーンは一種のタスクシステム(笑)で、
ウィンドウ管理、イベント管理、衝突判定、FPS調整、各オブジェクト行動などがセットになっとるでごわす。
シーンの切替えはこのセットをまるごと取り換える作業なのですたい。
308:名前は開発中のものです。
08/08/03 23:21:42 HN+lqKwd
FFとかのムービーシーンの管理はどうやればよかですたい？
309:名前は開発中のものです。
08/08/03 23:31:02 +gPnPllx
プロダクションだとファイルサーバ置いてモデル素材とか徹底管理するみたいだね。
Digital Anime Artwork(1/2)って本が内情ノウハウ溢れてて参考になった。
ほんとフォルダ分けの徹底とワークフロー統一にどこも頭悩ませてるようだ。
いまどきだとプロジェクションマップとか多用する規模の物も多いしな、美術、撮影、合成と
310:名前は開発中のものです。
08/08/03 23:31:41 +gPnPllx
あれ？ ここCG板じゃねえじゃん。
うわ俺凄く恥ずかしいマジレス？
311:名前は開発中のものです。
08/08/03 23:31:45 0ZCECk8O
>>308
ムービーシーンなんて作ったことないからわからんですたい。
脳内妄想では、ムービーを再生できるオブジェクトが登録されてるシーンに移行するだけですたい。
312:名前は開発中のものです。
08/08/04 17:38:42 OcXTlg2n
うさんくさか博多弁多かたいね。なんかぐらぐらこく
馬鹿にしないでください＞＜
313:名前は開発中のものです。
08/08/04 23:28:56 Vp8LYTR0
>>312
こらあげにまっことすまんかったぜよ。
314:302
08/08/04 23:40:39 OTznAvMd
>>306
そうそうそんな感じ。
1シーンの処理は画像やその他のデータの読み込み、メインループ、
次のシーンに移る前の要らないデータの破棄のような感じにするつもり。
前のシーンに戻れるように階層構造を使ったりしたら難しくなりそう。
315:名前は開発中のものです。
08/08/07 02:18:10 iFGNdN4x
しーん…
316:名前は開発中のものです。
08/08/07 15:44:15 J5sJkFaL
【 審議中 】
∴∵
317:名前は開発中のものです。
08/08/24 00:35:34 kCbI2Ziv
（審議が長引いています。今しばらくお待ちください）
318:名前は開発中のものです。
08/08/27 21:03:35 pp3RgERm
キャラクターの状態って、どうやって実装してますか？
例えばマリオなら、
enum { SMALL, BIG, FIRE };
enum { STAR, NOT_STAR };
のように、直交した状態ごとにenumで列挙して、ifで場合わけするのでしょうか？
stateパターンでは無理？？？
319:名前は開発中のものです。
08/08/27 21:31:52 tgwWcjRq
それだけだとモーション中とかが実装できないよね
FCマリオならそのenumに加えて、ゲームステータスとして「巨大化アニメ進捗」を示すカウンタ用意すれば十分だと思う
ステータス変化中に他の画面止めていいのか、それとも無敵時間とか起きながら遷移中にも時間は動かすのか前提がもうちょい欲しいかも。
その辺の細部を徹底的に見つめていくと、
適するパターンがあるのか、それとも独自な設計選ぶべきかが見えてくるんじゃないかな。
マリオにしてもSFCのヨッシーとかFC版3での画面奥行き潜りとか、色々
実装したい事を見据えて行くと変数の数やステータスのまとめ方が見えて来るだろうしね。
320:318
08/08/28 00:48:01 Z+eKsEJG
>>319
いろいろ考えないといけない事多いですね。
この手のものを実装する方法として、stateパターンとenumとifで場合わけの他に何かあるんでしょうか？
状態の種類と数が複雑になってくると、enumとifを使う方法しかない気がしてきます。
ifで場合分けって、コードが汚く感じてあまり好きじゃないんですよね。
でも、こういうケースでは、これがベストなのかなぁ。
321:名前は開発中のものです。
08/08/28 01:16:45 q3w3U78u
>コードが汚く感じてあまり好きじゃないんですよね。
好みと言うより仕方がない気も。
よくわからんなら下手に「なんとかパターン使うべきなのかな！」って
考えるより、ベタで汚いながらも「いじりやすい」単純なコードからはじめてさ、
あとはめくらめっぽう試した方がいいよ。
ifでの場合分けさえ、インライン展開される事を知ってるかどうかで汚くても使う訳で。
で、知ってる人にはそういうのやら三項演算多用した分岐の方を「美しい」って言っちゃったりするからねｗ
322:名前は開発中のものです。
08/08/28 01:34:35 O/+Qqs/2
最初ってそういうの考えちゃうよな
世間じゃどういうのが正しいんだろうとか考えて自分のコードが全然すすまねぇ
今ではなんだかんだで破綻するギリギリまで「動けばいいや」の精神で書いてる
仕事じゃないからこそだな
323:名前は開発中のものです。
08/08/28 03:20:26 tq3ymPlL
関数ポインタで飛ばせば見た目は良くなるね。
可視性に問題が出てきそうで自分では使ってないけど。
324:名前は開発中のものです。
08/08/28 09:12:41 y2qhH8VC
そこで goto ですよ
325:名前は開発中のものです。
08/08/28 10:11:26 MS2hHN8x
某シューティングツクール的にはそもそも「状態」という概念が無くて、
全く別のオブジェクトを「発射」して、自分を「消滅」させることで状態の変化を表現してた。
326:名前は開発中のものです。
08/08/28 11:46:09 Qlb2/Pnm
javaは関数ポインタ使えないんだ・・・・
327:名前は開発中のものです。
08/08/28 11:57:21 MS2hHN8x
>>326
Javaの場合は、状態クラスを作って、それを持つようにすればいいんだよ。
328:318
08/08/28 17:59:10 Z+eKsEJG
>>321,322
汚いコードって書き直したくなってくるんですよね。
綺麗に書けないと達成感がないというか・・・。
また、本などで知識をつける毎に、今まで書いてきたコードが正しくない書き方だったな〜と思うことが多くて(プログラミング始めた頃はダライアス継承とかやってたｗ)。
完成させることが第一と思っていてもついつい・・。
>>323,327
stateパターンですよね？
>>325
そういう方法でやってるところもあるんですね。
でも、オブジェクトのコピーが効率悪そう。
329:名前は開発中のものです。
08/08/28 18:35:54 CuTVRbF+
自分ひとりで考えても、本を読んでも出てこない、他人の眼に触れさせなければ見えてこないものもある。
それよりも自分の達成感の方を優先したいならそっちを選べば良いさね。
つか、コードの正しさ、綺麗さ、効率の良さ、読みやすさってどういうものだとして使ってる？
330:名前は開発中のものです。
08/08/28 19:03:37 Jt4Hw7jN
むしろ可能な全ての表記法を試す勢いで！
次のプログラムからは気に入った表記で。
昔の事は忘れましょう。
331:名前は開発中のものです。
08/08/28 19:43:21 MS2hHN8x
人が書いたソースを読むのって勉強になるけど、読む気が出ない……
>>328
>stateパターンですよね？
パターンのことはよく知りませんが、ポリモーフィズム(多態性)です。
332:名前は開発中のものです。
08/08/28 20:37:26 xedxyhWb
＞状態という概念が無い
敵が爆発する瞬間とかだとやっちゃうなあ……。効率悪いんだろうか。
333:名前は開発中のものです。
08/08/28 21:28:28 MS2hHN8x
>>332
他に良い方法があるならどうぞ。
MHz世代のCPUで通用してた方法だから、致命的な効率低下があるとは思わないよ。
334:318
08/08/28 21:30:31 Z+eKsEJG
>>329
コードの正しさ、綺麗さの２つは曖昧な表現で使うべきではなかったですね。
私はコードには、実行効率、保守性、読みやすさの３つがあると思っています。
今問題にしてるのは、主にこのうち後者２つです。
ただ、読みやすさは人それぞれなのかもしれません。
>>331
状態毎に仮想関数をオーバーライドするのが、まさにstateパターンですね。
335:名前は開発中のものです。
08/08/28 21:59:24 O/+Qqs/2
保守性も読みやすさもifとenumにしたからと言って損なわれるものでも無いと思うけど何を悩んでるの？
336:名前は開発中のものです。
08/08/28 22:18:17 qtCAmqfQ
ダライアス継承ってどんな継承？
337:名前は開発中のものです。
08/08/28 22:22:03 xedxyhWb
>333
爆発オブジェクトを自身と同じ場所に生成して、自身を削除する
って認識で合ってる？
338:318
08/08/28 23:04:17 Z+eKsEJG
>>335
保守性については、仕様変更により、状態を追加したり、廃止したりする時、影響する部分を探し出すのがめんどくさいというかすっきりしないというか。
読みやすさは個人的な好みかもしれません。
保守性、読みやすさともにstateパターンの方が好きです。
でも、直交した状態群が複数あるとき、stateパターンで実装するのが難しそうなので悩んでいました。
うまい方法が見つからなければ、enumとifでいくつもりでした。
>>336
ダイアモンド継承の方が一般的な呼び方なのかもしれません。
仮想継承を使うことによって、継承グラフが菱形になるやつです。
339:名前は開発中のものです。
08/08/29 00:44:03 hcEje8O4
ダライアス継承なんて初めて聞いたなあ
英語だと Multiple Inheritance あるいは Diamond Inheritance と言うようだが。
あとダライアス（Darius？）はペルシャ人の名前のようだ。
まゆに唾つけて聞いておこうかな
340:名前は開発中のものです。
08/08/29 00:50:36 rESH+j3C
ダライアス継承でググってみても勘違いで質問してる奴にしか引っかからないな
デザパタへの無駄なこだわりとか、初心者がなんか変な用語がいっぱい並んでる本だけ読んで惑わされてるだけに見える
341:名前は開発中のものです。
08/08/29 02:39:33 VLtb7ZED
Multiple Inheritance (多重継承) と Diamond Inheritance (ダイヤモンド継承) は
違う概念だが...というかダライアスっていうとシューティングゲームしか思い浮かびませーん
342:名前は開発中のものです。
08/08/29 06:43:42 gdp2Jatd
URLﾘﾝｸ(ir9.jp)
343:名前は開発中のものです。
08/08/29 10:26:08 ESvglHwU
>>337
合ってると思うよ。
問題があるとすれば、状態を変化させるだけの場合、ライフとかのパラメータ引き継ぎどうすんねんとか。
そこんとこがツクールVじゃ無理だった。(最近の(95とか)はシラネ)
344:名前は開発中のものです。
08/08/29 14:31:33 UaA8GGvx
>>341
>ダライアスっていうとシューティングゲームしか思い浮かびませーん
ダライアスの面セレクト画面が菱形継承図っぽいところから生まれた俗称だったりしてw
345:名前は開発中のものです。
08/08/29 14:34:13 nV9hYRuE
>だったりしてw
いやだったりしてっつーかそれしかなくね
346:名前は開発中のものです。
08/08/30 13:56:18 vqGqt03L
ダイヤモンドが2個も3個もあるような継承のことか。
C3 MRO の解説でしか見たこと無いが。
347:名前は開発中のものです。
08/08/30 14:18:00 gGJd0yLw
ドラえもん 「ことわざゲーム」
これはいいアニメ。 ... ドラえもん 藤子Ｆ不二雄 アニメ
ドラえもん後期 ドラえもん本編 教育アニメ コメント非
表示推奨 緑 ...
URLﾘﾝｸ(ex-co-jp.8866.org)
348:名前は開発中のものです。
08/08/30 14:23:18 h7pQaJrI
なんかあちこちで見かけるな。これ以上ないってくらい、明らかにヤバいリンク
349:名前は開発中のものです。
08/08/30 14:32:04 hoYQeFVI
夏休みも終わりって事さｗ
350:名前は開発中のものです。
08/08/30 14:40:33 vqGqt03L
Bot使った宣伝書き込みかなぁ
351:名前は開発中のものです。
08/08/30 15:36:27 h7pQaJrI
なんかのマルウェアって聞いたが
352:名前は開発中のものです。
08/08/31 15:40:22 5jP5dBFC
A has B B has C C has Dのようなクラス構成で
Aで作ったEをＤで使うために、Ａから呼び出したB、Bから呼んだＣ、Ｃから呼んだＤのそれぞれの関数の引数に
Ｅを渡していくのはいいのかな？
353:名前は開発中のものです。
08/08/31 15:45:26 eaWcmeF0
いいんじゃね。
354:名前は開発中のものです。
08/08/31 15:47:56 fQJxWw7j
別に悪くはないと思うよ
Eの役割によってはABCD全てからアクセスできる領域に置くのもアリかもね
なんにせよその構成だけじゃいいとも悪いとも言えない
355:名前は開発中のものです。
08/08/31 15:54:48 5jP5dBFC
>>353
>>354
サンクス
AからDは直接呼べないけど、Eを使うのはDなので、
AからDにEを渡したいけど、それだけのために間にクラスでEをたらし回しにするのがどうかな〜と
思ったんだよね
356:名前は開発中のものです。
08/09/02 03:29:08 m23QvXa7
このスレにUMLで図描いて貼っても、きっと誰かが見る前に流れて消えてしまう罠
357:名前は開発中のものです。
08/09/02 03:31:07 m23QvXa7
>>352 >>355
コンポジッションの視点、あるいはチェインズ・オブ・レスポンシビリティの視点で言えば、
それは普通にアリ。 っていうか、>>354 も言ってるけど、その構成だけだと（意図する形の意味づけが見えないと）
本当はいいとも悪いとも言えないが。
358:名前は開発中のものです。
08/09/02 17:16:20 BpB/a+5N
CarクラスはTireクラスを４つ持っているとして、
TireクラスもCarクラスを持っていてCarクラスの関数を使えるという設計はいいんでしょうか？
359:名前は開発中のものです。
08/09/02 17:22:14 Kf1ObPTz
コールバックしたいならインターフェース化してポインタ渡すとよい
TireクラスでCarクラスを生成するとかなら論外
360:名前は開発中のものです。
08/09/02 17:30:36 BpB/a+5N
TireクラスにCarクラスのポインタを持たせて、Tire生成時とかにCarクラスのオブジェクトのポインタを渡せば
いいということでしょうか？
361:名前は開発中のものです。
08/09/02 17:36:03 NydWLubY
>>360
Tireが常にCarのポインタを持っている必要もなくて、
CarがTireのメソッド呼び出し時に必要なポインタを渡すのもアリだと思う。
362:名前は開発中のものです。
08/09/02 17:40:44 IXiySr/S
タイヤが車に関心があるってどういう状況？
363:名前は開発中のものです。
08/09/02 17:42:28 NydWLubY
「パンクしたよ」って知らせてくれるんじゃね？
364:名前は開発中のものです。
08/09/02 17:44:29 IXiySr/S
なるほど
365:名前は開発中のものです。
08/09/02 19:17:31 gmtfIbjx
それ車が「パンクしたか？」メソッド持ってるんじゃダメなの？
366:名前は開発中のものです。
08/09/02 19:20:27 IXiySr/S
車が、常に「パンクしたか？」ってタイヤに聞くの？
367:名前は開発中のものです。
08/09/02 19:24:40 gmtfIbjx
うん
パンクに限らずあらゆる故障具合をウェルネスシステムが監視しててそいつに聞けば全部OKみたいな
車のメソッドじゃなくなったけど
368:名前は開発中のものです。
08/09/02 19:38:46 IXiySr/S
メディエーターみたいなの？
369:名前は開発中のものです。
08/09/02 20:44:39 F4HrtZLF
>>366
実際のTPMS（タイヤ空気圧監視システム）はそういうものだよ。
ホイールに取り付けられたセンサーモジュールが車両本体側装置と一定時間毎に無線交信してる
具体的には、本体が一定時間毎に圧力値を問い合わせ。センサーモジュールが圧力値を返してる
ポーリング処理。
float _pressure = m_wheel[n]->GetPressureState();
370:名前は開発中のものです。
08/09/19 19:13:57 FmM/zRja
ほしゅ
371:名前は開発中のものです。
08/10/05 14:32:14 tMuqv+yj
このスレはJavaでも大丈夫なの？
372:名前は開発中のものです。
08/10/05 14:52:40 v7IsXRIY
>>371
質問内容の分野がよくわからないなら、以下へどうぞ。
【初心者】ｽﾚを立てる前にｺｺで質問を【Part17】
ｽﾚﾘﾝｸ(gamedev板)
373:名前は開発中のものです。
08/10/05 17:40:56 6np9SFhP
>372がエスパーすぎる
374:名前は開発中のものです。
08/11/01 11:27:07 g//jQFBy
データ(アイテムとかマップとか)ってどうやって作ってます？
エクセルで打ち込んでcsvで保存？
375:名前は開発中のものです。
08/11/01 12:46:01 YmfIaKZ8
別にそれでいいし
専用にエディタ作ってもいいし
ありもので済ませてもいいし
俺はPlatinum map editor使ってるし
376:名前は開発中のものです。
08/11/01 12:58:04 g//jQFBy
>>375
マップに関しては、フリーのエディタがあるんですね。
規模が小さいゲームなら、アイテムとかはエクセルが効率いいのかな。
377:名前は開発中のものです。
08/11/01 16:47:28 NlVHrve1
既存のマップツールは便利なんだが、結局そこから独自形式へのコンバータを作ってる。
378:名前は開発中のものです。
08/11/02 08:08:32 JeGt0JB9
海岸線自動生成とかやってくれるエディタあるっけ？
379:名前は開発中のものです。
08/11/02 09:02:07 i1X6CLvS
>378
エディタでやるの？
380:名前は開発中のものです。
08/11/04 18:29:40 CIBt14+U
機能としてはエディタ側じゃね？
381:名前は開発中のものです。
08/11/06 00:16:08 46fvhfrF
ツクールで海岸線をシフト＋右クリックすると分かる
382:名前は開発中のものです。
08/11/11 20:24:09 rtOtwyEd
最近Gofのデザインパターンを読んで、目から鱗が落ちまくった。
今までぐだぐだやってたのが全部無駄というか馬鹿だったのに気づいてしまった。
他の初心者がこんなことが起きないように、勝手にメモ。
1、相互参照は可能ならば避ける。どちらかが一方的に知り、メソッドでその都度渡すほうがいい。
→クラス図の関連の矢印の向きは重要。関連が1方向なら、関連される（変数として保持される側の）クラスの再利用が容易。
→相互参照関係にあるクラス同士を、一方的な関連にすることは大抵の場合可能なはず。（関連する側が冗長になるが。）
2、再利用を考えたフレームワークは（初心者は）作らない。
→再利用のための部品を作る程度にとどめるのがいい。フレームワークの設計は正直拡張性を考え出すと難しすぎるらしい。
他に鉄則があったらだれか教えてください orz
383:名前は開発中のものです。
08/11/12 01:30:10 LsEQ4TEa
相互参照すると、クラス開放時にお互いが争ってメモリリークすんだよな
クラスA「Bさん、お先にどうぞどうぞ」
クラスB「いえいえ、ここはAさんがお先に」
クラスA「どうぞどうぞ」
OS「おまえら、どっちもさっさとイケ！」
ピー…
384:名前は開発中のものです。
08/11/12 09:02:45 QWqH0Tgg
> Gofのデザインパターン
GOF本でわかったならよいけど、退屈でわからない人は
First Headの本オススメ
Head Firstデザインパターン―頭とからだで覚えるデザインパターンの基本: エリック フリーマン, キャシー シエラ, エリザベス フリーマン, バート ベイツ, Eric Freeman, Kathy Sierra, Elisabeth Freeman, Bert Bates, 佐藤 直生, 木下 哲也, 福龍興業: Amazon.co.jp: 本
URLﾘﾝｸ(www.amazon.co.jp)
URLﾘﾝｸ(images-jp.amazon.com)
385:名前は開発中のものです。
08/11/12 23:23:14 hxIHNKys
ライブラリを作るとして、名前空間とクラスはどのように配置するのがいいでしょうか。
たとえば、ある単純な機能のクラスがいくつかあります。
これを集約してより大きな機能のあるクラスがライブラリ内で作られている場合、
1、大きなクラスをネスト先の名前空間に入れる。（HogeLibrary.Composite）
2、小さなクラスをネスト先の名前空間に入れる。（HogeLibrary.SmallComponent）
3、そもそもが間違い。同一名前空間に配置する。
どれが適切でしょうか？
386:名前は開発中のものです。
08/11/13 21:08:31 3NMFClPL
>>385
boostでは、ライブラリ利用者が直接触る必要ないものはdetailっていうネームスペースに入れてあるね。
ってそういう話じゃない？
387:名前は開発中のものです。
08/11/14 01:18:47 USS/q0/d
>>385
名前空間を分けるメリットが見当たらなければ分けないほうがいいでしょ。
388:名前は開発中のものです。
08/11/16 02:04:27 OW89wflh
ライブラリ利用者の立場にたって、
どうなってると使いやすいかを考えて臨機応変に決める。
389:名前は開発中のものです。
08/11/19 20:47:58 oq/eqnIP
>>382-384
まだ読んでいない俺には勉強になったthx
390:名前は開発中のものです。
08/11/20 09:17:22 jP0yKBYe
>>384
のFirst Head本は、読み物形式で
悪いコードをよいコードに変更していきながら、解説しているようになっているので、
GOF本よりかなり読みやすいよ
ただ、いくつかのパターンが省略されて適当解説になっているので、注意。
適当になってる後半部分も解説されていたらかなり神本だった
（まああのペースで全部網羅すると、値段とページがすごいことになりそうだがｗ）
391:名前は開発中のものです。
08/11/30 20:02:56 GlMxgFAf
すいませんというか疑問です。
特定の条件を満たしたら処理(入力の読み取り)を行う、という作業を内部で行う関数を作ろうと思ったのですが、疑問がいろいろ出てきました。
(1回のループの中に複数この関数を配置して、どこかで実際に実行する、というような使い方を想定してます。)
1、この関数を採用する場合、名前の付け方
Polls()、CanPoll()、IsPolling() …主目的が『必要ならば読み取る』なので何かしっくりしない。
2、何かよりよい代替の設計があるだろうか
何か設計が変な気がする、が、なぜそう思うのはわからない。
どなたか導きをお願いします
392:名前は開発中のものです。
08/11/30 20:03:41 GlMxgFAf
なんかいっぱい改行が入ってるorz
393:名前は開発中のものです。
08/11/30 20:44:16 O5396ILY
>>391
関数の名前は内部での処理なんて割とどうでもいいので、
とにかくその関数の意味(挙動)がわかる名前にしたらいいんじゃね。
ちなみにJavaの場合、キーボードやマウスからの入力によってイベントが発生し、
そのイベントによって適切なリスナーの関数が起動されます。
プログラムの本流が直接読みに行くことなんてしません。
394:名前は開発中のものです。
08/12/02 23:03:37 QPPOGJkH
>>393
気持ちが悪かったから、結局色々こねくり回して何とか別の方法で実装しました。
DirectInputのBufferedは偉大ですね、と。
395:名前は開発中のものです。
08/12/03 00:00:25 QPPOGJkH
ついでにスレを読み返してメモメモ、と思った情報をまとめてみた。
コルーチン、マイクロスレッド、ファイバ
>>145,>>146,>>162,>>164
楽だが応用性のないありがちな実装
>>159,>>160
分業とデバッグ
>>194-213
ADVの画面クリックとか
>>270,>>271
メニュー画面の管理とかシーン管理とか
>>59-71,>>207,>>273-276>>302,>>305-314・・・VMCはたぶんMCVのことだよね？
状態管理とか
>>318-325
priateとgetter、setter
>>277-301
設計Tips
>>352-357,>>358-367,>>382-384
396:名前は開発中のものです。
08/12/13 14:29:53 lcU0tpK0
ゲーム開発論を語るスレを立てようと思っていたんですが、すでに似たようなスレがあると聞いて相談にきました。
このスレがあるので必要ないのでは？という意見があり、新スレを立てるべきかどうか迷っています。
ご意見頂けないでしょうか？
↓ゲーム開発論スレ要望の経緯
ｽﾚﾘﾝｸ(gamedev板)
ＫＯＮＡＭＩ、スクエニ、セガ、バンナム、コーエーの大手5社がゲーム開発現場の未来を再び討議
「5年後のゲーム開発現場を考える〜ゲーム会社技術開発の現場から2〜」
URLﾘﾝｸ(game.watch.impress.co.jp)
「Gears of War」はいかにして生まれたのか。Cliff Bleszinski氏が語る，有効なゲーム開発プロセス
URLﾘﾝｸ(www.4gamer.net)
Agile型開発でのゲームデザイン
URLﾘﾝｸ(www.4gamer.net)
397:名前は開発中のものです。
08/12/14 06:46:04 foB3PhGt
>>396
ここは実装について話すスレなので、開発論は全くのお門違い。
とっとと失せろ！！
398:名前は開発中のものです。
08/12/14 06:47:43 3zIx1sHY
想定通りでワロタ
399:名前は開発中のものです。
08/12/15 01:28:13 AODSdSoN
>>395
ありがとう助かるよ
400:名前は開発中のものです。
08/12/18 23:54:28 QLMqRIYY
キャラクタのデータはテキストファイルにゆだねて動的にできるけど
ふるまいはどうすればいいんだろう。
基本ふるまいをプログラムに実装して(静的)、テキストファイルで
その呼び出しを記述する(動的)とかなのかな。他に思いつかん。
401:名前は開発中のものです。
08/12/19 12:11:03 ygbWfkiR
俺はそうしてる。
402:名前は開発中のものです。
08/12/21 09:35:05 7nb+zy1b
つまりスクリプトですね。
403:名前は開発中のものです。
08/12/25 19:24:07 QpPf00tD
知ってるよDIって言うんだよね
404:名前は開発中のものです。
08/12/26 01:45:37 NBeqwEQB
最近でたセガのあれな本を読んで、自分がずっと詰まってたしょーもないことを勝手にメモ。
結論としては基本中の基本で、データと処理は独立させましょ、ってことなんだけど。
ゲーム中ができたけど、ポーズ機能を追加、ポーズメニュー表示関連をクラスで作って実装するには、という感じの想定。
こんな感じに管理してるとして(具体的にはもっと複雑だけど。)
class StgScene {
Mover movers[];
void Update() {
//A
for(・・・) {
movers[i].Move();
}
//他判定処理等
//B
for(・・・) {
movers[i].Draw();
}
//C
}
}
・A〜Bまでの処理はポーズ時すっ飛ばす、となる。ので、関数化するなりクラス化したい。
・対象性を考え、Menuクラスに対してA〜Cの処理をPlayingクラスにする。(つまりSTGSceneはデータのみ。)
・MenuクラスにもB〜Cの処理を書き、追加してMenu関連の処理も記述する。
こうすると、結果的にSTGシーンはデータしか持たなくなって、処理はPlayingクラスやMenuクラスに任せる形になる。
見通しが悪くならずに拡張できる。
今までずっと気づかなかった自分の頭の悪さに笑うしかないぜ。
405:名前は開発中のものです。
08/12/26 08:47:36 Y8oI6MzT
「勝手にメモ」を書き込んでくれる人（達？）の存在は、正直ありがたい
406:名前は開発中のものです。
08/12/28 17:34:36 pzJs6/UU
MVCでいうと、
M:StgScene
V,C:Menu,Playing
ってことなのだろうか？
Stateパターンという風にも捉えられる？
407:名前は開発中のものです。
08/12/29 00:45:07 THn3O3Oz
Stateパターンだとこんなかんじかね？
struct StgScene {
void A();
void B();
void C();
};
class State {
virtual void Update(StgScene&) = 0;
};
class Playing : public State {
virtual void Update(StgScene& scene){
scene.A();
scene.B();
scene.C();
}
};
class Menu : public State {
virtual void Update(StgScene& scene){
scene.C();
}
};
408:名前は開発中のものです。
09/01/07 23:21:00 rBsXmGd8
なんか話題無いなー的なので、>>404の続きでも。今回もセガのあれを参考にしました。
自分もまだ試作中だけど、かなり自由かつ堅実に作れる。
StgSceneクラスの考えをもう少し推し進めると、全てのシーンの汎化クラスであるSceneクラスが作れそう。
# child // フィールド。子シーンの保持。
# childTypes // フィールド。runやUpdateの戻り値が自分の子かどうか識別するためのもの。
# run(Scene parent) // メソッド。child == null のとき、自分が実行すべきシーンと認識してrunする。戻り値に次の遷移先シーンかnull返す。
# focusing // イベント。シーン遷移で自分が次にrunする場合の初期化処理。Update内のシーン遷移処理に際し呼ばれることが目的なので、abstractメソッドでもいいです。
# unfocusing // イベント。シーン遷移で別のシーンに移動する際の後始末。上と同様。戻り値に次の遷移先シーンかnull返す。
+Update(Scene parent) // childがいればchildのUpdateを呼び出し、そうでなければrunする。その後、遷移先シーン(つまりUpdateやrunの戻り値)に応じた遷移処理を行う。
Updateの実装内容について
１、シーンは線形リストを形成し、末端シーンのrunを実行するように記述する。(rootScene → StgGame → StgPlayingや、rootScene → TitleScene → TitleHighScoreといったリスト構造になる。)
２、runのreturnに意味を決める。そしてそれによって処理が分岐するように記述する。null、自分、兄弟シーン、親以上。
・nullは、runしたシーンに子が出来て、自分がフォーカスシーンで無いことを表す。
・原則として、自分の子供と祖先の子供以外には直接遷移できないとする。する必要も考えられないので。
･･･っとここまで書いて、ソースコードがないとどう考えても伝わらんだろと思った。
409:名前は開発中のものです。
09/01/07 23:25:20 rBsXmGd8
しかもミスってる。
# unfocusing ･･･『戻り値に次の遷移先シーンかnull返す。』 ←×
正しくは、+Updateの行の後ろに『戻り値に次の遷移先シーンかnull返す。』と書くつもりでした。
410:名前は開発中のものです。
09/01/09 00:07:48 vYDzTrO8
自作の状態遷移クラスに似てるな。
・状態に親子関係がある。
・戻り値の意味によって遷移先を決める。
・自分の子、先祖の子以外は直接遷移できない。
ってあたり、ほぼ同じっぽい。
戻り値って具体的に何を返しているの？
自分の場合、STAGE_CLEARとかの定数を返している。
その値をみて、さらに親へ遷移(戻り値を返す)したり、子供へ遷移したりしてる。
411:名前は開発中のものです。
09/01/09 01:05:35 2TNYOX7D
>>410
このソース、イベントといってるところでわかるように、C#です。Updateの戻り値はSceneインスタンスですね。
C#ではhoge.GetType()でインスタンスの型情報(Typeインスタンス)が取得できるもんで、それを定数代わりに利用します。
で、戻り値に対する処理はこんな感じ。
戻り値がnullなら、フォーカスシーンが孫以下であることを表します。
戻り値sceneのGetType()と、
・ChildのTypeインスタンスと比較すれば遷移が不要かどうかわかります。(等しければ移動していない。)
・定数として保持させたType配列と比較すれば遷移先が子かどうかはわかります。
・自分のTypeインスタンスと比較すれば遷移先が自分かどうかがわかります。自分ならば、focusingで初期化処理を呼び出します。
・それ以外の場合、祖先および祖先の子のいずれかであることがわかります。いずれにしても上位のシーンに処理を仰ぎ、自分は破棄されます。
ってかんじでしょうかね。
412:名前は開発中のものです。
09/01/09 01:28:17 vYDzTrO8
インスタンスそのものを返すのかぁ。
確かにそのほうが直接的ですっきりするかもね。
413:名前は開発中のものです。
09/01/10 23:29:07 GXwf3cbn
インスタンスを生成するのは作成した瞬間にクラスが2つ分になってメモリが足りなくて死ぬ
危険があるから1個間にはさみたいな。
生成メソッドはstaticにするとかなんとか。
414:名前は開発中のものです。
09/01/11 00:09:06 dWwzUAmX
まて、よく意味はわからんが今時のゲームやるようなWindows環境前提なら、最低でも500MB程度はメモリに余裕があるだろう。
どう考えても使いきれるとは思えん
415:名前は開発中のものです。
09/01/11 02:43:39 cWr0moum
あれか？ NSAppみたいなアプリケーションのインスタンスを丸ごとコピーするとかの話か？
416:名前は開発中のものです。
09/01/12 02:58:31 8xCnbJpy
>>414
PCならそうかもしれないけど、コンシューマ機だと360でやっと512MB(ただしVRAM込み)、
DSにいたっては4MBしかないからね。
417:名前は開発中のものです。
09/01/12 03:30:42 mDvqZ10E
シーン遷移時に元シーン内で新シーンのインスタンスを生成するのは、
そのコンストラクタへシーン用引数を指定できるのがメリットかな。
あと、シーンコンストラクタ/デストラクタとは別にシーン初期化/解放メソッドを定義しておいて、
シーンのコンストラクタは必要なシーン用引数のメンバへの保存だけを行うような形にすれば、
メモリが足りないということは殆どなくなると思うけどね。
それから、個人的な意見としては、
シーンが生成される際にはまだ生成元シーンのインスタンスへはアクセス可能でいたい。
このライフサイクルのほうが、現在の実行状態を認識し易くて、様々な仕様変更に柔軟に耐えうると思う。
418:名前は開発中のものです。
09/01/12 03:32:37 mDvqZ10E
ごめん
×ライフサイクル
○ライフタイム
419:名前は開発中のものです。
09/01/12 11:14:49 pb2pea9L
そのあたりの話は研究しがいがあるな。
420:名前は開発中のものです。
09/01/12 13:32:30 YXD0YS+N
>>418
一応、常にnewするのは遷移元シーン、deleteするのは対象のシーンの親、ってことになってるけどこれじゃだめかな？
クラス図の関連が木構造で、枝をはさみで切るイメージ。
421:名前は開発中のものです。
09/01/12 14:12:02 sqS0O25/
シーンをまたぐデータは、そもそもシーンが管理すべきなのか
検討した方がいいかも。
422:名前は開発中のものです。
09/01/13 22:46:08 BhFnEm7r
シーンを跨ぐデータはスマートポインタみたいなもんで管理するんだが
そのポインタを渡すのにシーン生成を先にしたいという感じかな。
オレは管理マネージャ作るけど。
423:名前は開発中のものです。
09/01/13 22:46:54 BhFnEm7r
管理マネージャじゃマネージャマネージャだなｗ
まあC++になって楽になったものよ。
424:名前は開発中のものです。
09/01/14 03:24:31 0DnXfUAy
>>421
原則として、シーンをまたぐデータはないように設計する。…言い方が悪いな
あるシーンで使われたデータは、その子シーンで使われることがあっても、祖先のシーンで使われることはないように設計する。
あるシーンが持つデータを子シーンが使いたかったら、
>>417が言ってくれているように、コンストラクタで自由に子シーンに渡してしまう。
まぁほとんどの場合はコンストラクタ時に親シーンをそのまま子シーンに渡す。(子シーンで使いたいデータはpublicにしておく)
425:名前は開発中のものです。
09/01/14 03:32:21 0DnXfUAy
親シーン子シーン関係なくデータを引き継ぐ場合として考えられるのは、例えばこんなときか。
ゲームを普通にプレイしてゲームオーバー表示(プレイ画面に追加表示)。その後ハイスコア画面に行くと考えると、
スコアの点数がまたぐデータになる。
RootScene>GameScene>GamePlaying
から
RootScene>GameScene>GamePlaying>GameOver
となり、その後
RootScene>HighScoreScene
に遷移する。
その際GameOverがHiScoreSceneを生成する際にコンストラクタでスコアデータを渡してやれば無問題。
426:名前は開発中のものです。
09/01/17 14:39:28 AWtASysq
YAGNI
427:名前は開発中のものです。
09/01/21 22:53:35 sHv/LIGj
スレが止まってるとさびしいな。
独り言でも言ってるか。
STGを作るときに、解決すべき内容は。
・1/60秒や入力情報など、最も基本的なものの構築。
・シーン遷移等、シーン管理の構築。
ここまでで共通の枠組みは作れる。シーン遷移はこのスレで紹介してたやり方でいくとして。
実際のゲーム中の解決すべき内容は
・自機、敵機などを1オブジェクトとするとして、オブジェクトの構造およびオブジェクト達の管理方法。
・敵出現(=ステージ情報)の作成方法、および管理方法や、それにかかわること。(リプレイとか。)
・あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・オブジェクト同士の衝突判定の記述。衝突判定まで。
・誘導弾など、常に依存先がかわるオブジェクトの記述方法。
で一通りっぽい。この手順でオブジェクトのインタフェースや管理方法を徐々に改良すると考える。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5264日前に更新/166 KB
担当:undef