トップページ⇒gamedev
585コメント234KB

ゲームにおけるデータ構造・クラス設計・パターン2

■ このスレッドは過去ログ倉庫に格納されています
0001名前は開発中のものです。2008/05/23(金) 21:10:59ID:8M1gqhPX
具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。

前スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/

テンプレ追加事項あったらよろすく
0337名前は開発中のものです。2008/08/28(木) 22:22:03ID:xedxyhWb
>333
爆発オブジェクトを自身と同じ場所に生成して、自身を削除する
って認識で合ってる？
03383182008/08/28(木) 23:04:17ID:Z+eKsEJG
>>335
保守性については、仕様変更により、状態を追加したり、廃止したりする時、影響する部分を探し出すのがめんどくさいというかすっきりしないというか。
読みやすさは個人的な好みかもしれません。
保守性、読みやすさともにstateパターンの方が好きです。
でも、直交した状態群が複数あるとき、stateパターンで実装するのが難しそうなので悩んでいました。
うまい方法が見つからなければ、enumとifでいくつもりでした。

>>336
ダイアモンド継承の方が一般的な呼び方なのかもしれません。
仮想継承を使うことによって、継承グラフが菱形になるやつです。
0339名前は開発中のものです。2008/08/29(金) 00:44:03ID:hcEje8O4
ダライアス継承なんて初めて聞いたなあ

英語だと Multiple Inheritance あるいは Diamond Inheritance と言うようだが。
あとダライアス（Darius？）はペルシャ人の名前のようだ。
まゆに唾つけて聞いておこうかな
0340名前は開発中のものです。2008/08/29(金) 00:50:36ID:rESH+j3C
ダライアス継承でググってみても勘違いで質問してる奴にしか引っかからないな
デザパタへの無駄なこだわりとか、初心者がなんか変な用語がいっぱい並んでる本だけ読んで惑わされてるだけに見える
0341名前は開発中のものです。2008/08/29(金) 02:39:33ID:VLtb7ZED
Multiple Inheritance (多重継承) と Diamond Inheritance (ダイヤモンド継承) は
違う概念だが...というかダライアスっていうとシューティングゲームしか思い浮かびませーん
0342名前は開発中のものです。2008/08/29(金) 06:43:42ID:gdp2Jatd
http://ir9.jp/prog/ayu/datlog/tech_cpp/1106527792/1106527792_01.html#R50
0343名前は開発中のものです。2008/08/29(金) 10:26:08ID:ESvglHwU
>>337
合ってると思うよ。
問題があるとすれば、状態を変化させるだけの場合、ライフとかのパラメータ引き継ぎどうすんねんとか。
そこんとこがツクールVじゃ無理だった。(最近の(95とか)はシラネ)
0344名前は開発中のものです。2008/08/29(金) 14:31:33ID:UaA8GGvx
>>341
>ダライアスっていうとシューティングゲームしか思い浮かびませーん
ダライアスの面セレクト画面が菱形継承図っぽいところから生まれた俗称だったりしてw
0345名前は開発中のものです。2008/08/29(金) 14:34:13ID:nV9hYRuE
>だったりしてw
いやだったりしてっつーかそれしかなくね
0346名前は開発中のものです。2008/08/30(土) 13:56:18ID:vqGqt03L
ダイヤモンドが2個も3個もあるような継承のことか。
C3 MRO の解説でしか見たこと無いが。
0347名前は開発中のものです。2008/08/30(土) 14:18:00ID:gGJd0yLw
ドラえもん 「ことわざゲーム」
これはいいアニメ。 ... ドラえもん 藤子Ｆ不二雄 アニメ
ドラえもん後期 ドラえもん本編 教育アニメ コメント非
表示推奨 緑 ...
http://ex-co-jp.8866.org/gourmet/080803.rar
0348名前は開発中のものです。2008/08/30(土) 14:23:18ID:h7pQaJrI
なんかあちこちで見かけるな。これ以上ないってくらい、明らかにヤバいリンク
0349名前は開発中のものです。2008/08/30(土) 14:32:04ID:hoYQeFVI
夏休みも終わりって事さｗ
0350名前は開発中のものです。2008/08/30(土) 14:40:33ID:vqGqt03L
Bot使った宣伝書き込みかなぁ
0351名前は開発中のものです。2008/08/30(土) 15:36:27ID:h7pQaJrI
なんかのマルウェアって聞いたが
0352名前は開発中のものです。2008/08/31(日) 15:40:22ID:5jP5dBFC
A has B B has C C has Dのようなクラス構成で
Aで作ったEをＤで使うために、Ａから呼び出したB、Bから呼んだＣ、Ｃから呼んだＤのそれぞれの関数の引数に
Ｅを渡していくのはいいのかな？
0353名前は開発中のものです。2008/08/31(日) 15:45:26ID:eaWcmeF0
いいんじゃね。
0354名前は開発中のものです。2008/08/31(日) 15:47:56ID:fQJxWw7j
別に悪くはないと思うよ
Eの役割によってはABCD全てからアクセスできる領域に置くのもアリかもね
なんにせよその構成だけじゃいいとも悪いとも言えない
0355名前は開発中のものです。2008/08/31(日) 15:54:48ID:5jP5dBFC
>>353
>>354
サンクス
AからDは直接呼べないけど、Eを使うのはDなので、
AからDにEを渡したいけど、それだけのために間にクラスでEをたらし回しにするのがどうかな〜と
思ったんだよね
0356名前は開発中のものです。2008/09/02(火) 03:29:08ID:m23QvXa7
このスレにUMLで図描いて貼っても、きっと誰かが見る前に流れて消えてしまう罠
0357名前は開発中のものです。2008/09/02(火) 03:31:07ID:m23QvXa7
>>352 >>355
コンポジッションの視点、あるいはチェインズ・オブ・レスポンシビリティの視点で言えば、
それは普通にアリ。　っていうか、>>354 も言ってるけど、その構成だけだと（意図する形の意味づけが見えないと）
本当はいいとも悪いとも言えないが。
0358名前は開発中のものです。2008/09/02(火) 17:16:20ID:BpB/a+5N
CarクラスはTireクラスを４つ持っているとして、
TireクラスもCarクラスを持っていてCarクラスの関数を使えるという設計はいいんでしょうか？
0359名前は開発中のものです。2008/09/02(火) 17:22:14ID:Kf1ObPTz
コールバックしたいならインターフェース化してポインタ渡すとよい
TireクラスでCarクラスを生成するとかなら論外
0360名前は開発中のものです。2008/09/02(火) 17:30:36ID:BpB/a+5N
TireクラスにCarクラスのポインタを持たせて、Tire生成時とかにCarクラスのオブジェクトのポインタを渡せば
いいということでしょうか？
0361名前は開発中のものです。2008/09/02(火) 17:36:03ID:NydWLubY
>>360
Tireが常にCarのポインタを持っている必要もなくて、
CarがTireのメソッド呼び出し時に必要なポインタを渡すのもアリだと思う。
0362名前は開発中のものです。2008/09/02(火) 17:40:44ID:IXiySr/S
タイヤが車に関心があるってどういう状況？
0363名前は開発中のものです。2008/09/02(火) 17:42:28ID:NydWLubY
「パンクしたよ」って知らせてくれるんじゃね？
0364名前は開発中のものです。2008/09/02(火) 17:44:29ID:IXiySr/S
なるほど
0365名前は開発中のものです。2008/09/02(火) 19:17:31ID:gmtfIbjx
それ車が「パンクしたか？」メソッド持ってるんじゃダメなの？
0366名前は開発中のものです。2008/09/02(火) 19:20:27ID:IXiySr/S
車が、常に「パンクしたか？」ってタイヤに聞くの？
0367名前は開発中のものです。2008/09/02(火) 19:24:40ID:gmtfIbjx
うん
パンクに限らずあらゆる故障具合をウェルネスシステムが監視しててそいつに聞けば全部OKみたいな
車のメソッドじゃなくなったけど
0368名前は開発中のものです。2008/09/02(火) 19:38:46ID:IXiySr/S
メディエーターみたいなの？
0369名前は開発中のものです。2008/09/02(火) 20:44:39ID:F4HrtZLF
>>366
実際のTPMS（タイヤ空気圧監視システム）はそういうものだよ。
ホイールに取り付けられたセンサーモジュールが車両本体側装置と一定時間毎に無線交信してる
具体的には、本体が一定時間毎に圧力値を問い合わせ。センサーモジュールが圧力値を返してる
ポーリング処理。

float _pressure = m_wheel[n]->GetPressureState();
0370名前は開発中のものです。2008/09/19(金) 19:13:57ID:FmM/zRja
ほしゅ
0371名前は開発中のものです。2008/10/05(日) 14:32:14ID:tMuqv+yj
このスレはJavaでも大丈夫なの？
0372名前は開発中のものです。2008/10/05(日) 14:52:40ID:v7IsXRIY
>>371
質問内容の分野がよくわからないなら、以下へどうぞ。

【初心者】ｽﾚを立てる前にｺｺで質問を【Part17】
http://pc11.2ch.net/test/read.cgi/gamedev/1210443288
0373名前は開発中のものです。2008/10/05(日) 17:40:56ID:6np9SFhP
>372がエスパーすぎる
0374名前は開発中のものです。2008/11/01(土) 11:27:07ID:g//jQFBy
データ(アイテムとかマップとか)ってどうやって作ってます？
エクセルで打ち込んでcsvで保存？
0375名前は開発中のものです。2008/11/01(土) 12:46:01ID:YmfIaKZ8
別にそれでいいし
専用にエディタ作ってもいいし
ありもので済ませてもいいし
俺はPlatinum map editor使ってるし
0376名前は開発中のものです。2008/11/01(土) 12:58:04ID:g//jQFBy
>>375
マップに関しては、フリーのエディタがあるんですね。

規模が小さいゲームなら、アイテムとかはエクセルが効率いいのかな。
0377名前は開発中のものです。2008/11/01(土) 16:47:28ID:NlVHrve1
既存のマップツールは便利なんだが、結局そこから独自形式へのコンバータを作ってる。
0378名前は開発中のものです。2008/11/02(日) 08:08:32ID:JeGt0JB9
海岸線自動生成とかやってくれるエディタあるっけ？
0379名前は開発中のものです。2008/11/02(日) 09:02:07ID:i1X6CLvS
>378
エディタでやるの？
0380名前は開発中のものです。2008/11/04(火) 18:29:40ID:CIBt14+U
機能としてはエディタ側じゃね？
0381名前は開発中のものです。2008/11/06(木) 00:16:08ID:46fvhfrF
ツクールで海岸線をシフト＋右クリックすると分かる
0382名前は開発中のものです。2008/11/11(火) 20:24:09ID:rtOtwyEd
最近Gofのデザインパターンを読んで、目から鱗が落ちまくった。
今までぐだぐだやってたのが全部無駄というか馬鹿だったのに気づいてしまった。
他の初心者がこんなことが起きないように、勝手にメモ。

1、相互参照は可能ならば避ける。どちらかが一方的に知り、メソッドでその都度渡すほうがいい。
→クラス図の関連の矢印の向きは重要。関連が1方向なら、関連される（変数として保持される側の）クラスの再利用が容易。
→相互参照関係にあるクラス同士を、一方的な関連にすることは大抵の場合可能なはず。（関連する側が冗長になるが。）

2、再利用を考えたフレームワークは（初心者は）作らない。
→再利用のための部品を作る程度にとどめるのがいい。フレームワークの設計は正直拡張性を考え出すと難しすぎるらしい。

他に鉄則があったらだれか教えてください　orz


0383名前は開発中のものです。2008/11/12(水) 01:30:10ID:LsEQ4TEa
相互参照すると、クラス開放時にお互いが争ってメモリリークすんだよな
クラスA「Bさん、お先にどうぞどうぞ」
クラスB「いえいえ、ここはAさんがお先に」
クラスA「どうぞどうぞ」
OS「おまえら、どっちもさっさとイケ！」
ピー…
0384名前は開発中のものです。2008/11/12(水) 09:02:45ID:QWqH0Tgg
> Gofのデザインパターン
GOF本でわかったならよいけど、退屈でわからない人は
First Headの本オススメ

Head Firstデザインパターン―頭とからだで覚えるデザインパターンの基本: エリック フリーマン, キャシー シエラ, エリザベス フリーマン, バート ベイツ, Eric Freeman, Kathy Sierra, Elisabeth Freeman, Bert Bates, 佐藤 直生, 木下 哲也, 福龍興業: Amazon.co.jp: 本
http://www.amazon.co.jp/dp/4873112494
http://images-jp.amazon.com/images/P/4873112494.09.MZZZZZZZZZ.jpg
0385名前は開発中のものです。2008/11/12(水) 23:23:14ID:hxIHNKys
ライブラリを作るとして、名前空間とクラスはどのように配置するのがいいでしょうか。

たとえば、ある単純な機能のクラスがいくつかあります。
これを集約してより大きな機能のあるクラスがライブラリ内で作られている場合、
1、大きなクラスをネスト先の名前空間に入れる。（HogeLibrary.Composite）
2、小さなクラスをネスト先の名前空間に入れる。（HogeLibrary.SmallComponent）
3、そもそもが間違い。同一名前空間に配置する。

どれが適切でしょうか？
0386名前は開発中のものです。2008/11/13(木) 21:08:31ID:3NMFClPL
>>385
boostでは、ライブラリ利用者が直接触る必要ないものはdetailっていうネームスペースに入れてあるね。

ってそういう話じゃない？
0387名前は開発中のものです。2008/11/14(金) 01:18:47ID:USS/q0/d
>>385
名前空間を分けるメリットが見当たらなければ分けないほうがいいでしょ。
0388名前は開発中のものです。2008/11/16(日) 02:04:27ID:OW89wflh
ライブラリ利用者の立場にたって、
どうなってると使いやすいかを考えて臨機応変に決める。
0389名前は開発中のものです。2008/11/19(水) 20:47:58ID:oq/eqnIP
>>382-384
まだ読んでいない俺には勉強になったthx
0390名前は開発中のものです。2008/11/20(木) 09:17:22ID:jP0yKBYe
>>384
のFirst Head本は、読み物形式で
悪いコードをよいコードに変更していきながら、解説しているようになっているので、
GOF本よりかなり読みやすいよ

ただ、いくつかのパターンが省略されて適当解説になっているので、注意。
適当になってる後半部分も解説されていたらかなり神本だった
（まああのペースで全部網羅すると、値段とページがすごいことになりそうだがｗ）
0391名前は開発中のものです。2008/11/30(日) 20:02:56ID:GlMxgFAf
すいませんというか疑問です。
特定の条件を満たしたら処理(入力の読み取り)を行う、という作業を内部で行う関数を作ろうと思ったのですが、疑問がいろいろ出てきました。
(1回のループの中に複数この関数を配置して、どこかで実際に実行する、というような使い方を想定してます。)

1、この関数を採用する場合、名前の付け方
Polls()、CanPoll()、IsPolling()　…主目的が『必要ならば読み取る』なので何かしっくりしない。

2、何かよりよい代替の設計があるだろうか
何か設計が変な気がする、が、なぜそう思うのはわからない。

どなたか導きをお願いします







0392名前は開発中のものです。2008/11/30(日) 20:03:41ID:GlMxgFAf
なんかいっぱい改行が入ってるorz
0393名前は開発中のものです。2008/11/30(日) 20:44:16ID:O5396ILY
>>391
関数の名前は内部での処理なんて割とどうでもいいので、
とにかくその関数の意味(挙動)がわかる名前にしたらいいんじゃね。

ちなみにJavaの場合、キーボードやマウスからの入力によってイベントが発生し、
そのイベントによって適切なリスナーの関数が起動されます。
プログラムの本流が直接読みに行くことなんてしません。

0394名前は開発中のものです。2008/12/02(火) 23:03:37ID:QPPOGJkH
>>393
気持ちが悪かったから、結局色々こねくり回して何とか別の方法で実装しました。
DirectInputのBufferedは偉大ですね、と。
0395名前は開発中のものです。2008/12/03(水) 00:00:25ID: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
0396名前は開発中のものです。2008/12/13(土) 14:29:53ID:lcU0tpK0
ゲーム開発論を語るスレを立てようと思っていたんですが、すでに似たようなスレがあると聞いて相談にきました。
このスレがあるので必要ないのでは？という意見があり、新スレを立てるべきかどうか迷っています。
ご意見頂けないでしょうか？

↓ゲーム開発論スレ要望の経緯
http://pc11.2ch.net/test/read.cgi/gamedev/1206381315/

ＫＯＮＡＭＩ、スクエニ、セガ、バンナム、コーエーの大手5社がゲーム開発現場の未来を再び討議
「5年後のゲーム開発現場を考える〜ゲーム会社技術開発の現場から2〜」
http://game.watch.impress.co.jp/docs/20080916/cedec_dev.htm

「Gears of War」はいかにして生まれたのか。Cliff Bleszinski氏が語る，有効なゲーム開発プロセス
http://www.4gamer.net/news/history/2007.03/20070309215934detail.html

Agile型開発でのゲームデザイン
http://www.4gamer.net/news/history/2007.03/20070311002313detail.html
0397名前は開発中のものです。2008/12/14(日) 06:46:04ID:foB3PhGt
>>396
ここは実装について話すスレなので、開発論は全くのお門違い。
とっとと失せろ！！
0398名前は開発中のものです。2008/12/14(日) 06:47:43ID:3zIx1sHY
想定通りでワロタ
0399名前は開発中のものです。2008/12/15(月) 01:28:13ID:AODSdSoN
>>395
ありがとう助かるよ
0400名前は開発中のものです。2008/12/18(木) 23:54:28ID:QLMqRIYY
キャラクタのデータはテキストファイルにゆだねて動的にできるけど
ふるまいはどうすればいいんだろう。
基本ふるまいをプログラムに実装して(静的)、テキストファイルで
その呼び出しを記述する(動的)とかなのかな。他に思いつかん。
0401名前は開発中のものです。2008/12/19(金) 12:11:03ID:ygbWfkiR
俺はそうしてる。
0402名前は開発中のものです。2008/12/21(日) 09:35:05ID:7nb+zy1b
つまりスクリプトですね。
0403名前は開発中のものです。2008/12/25(木) 19:24:07ID:QpPf00tD
知ってるよDIって言うんだよね
0404名前は開発中のものです。2008/12/26(金) 01:45:37ID: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クラスに任せる形になる。
見通しが悪くならずに拡張できる。
今までずっと気づかなかった自分の頭の悪さに笑うしかないぜ。
0405名前は開発中のものです。2008/12/26(金) 08:47:36ID:Y8oI6MzT
「勝手にメモ」を書き込んでくれる人（達？）の存在は、正直ありがたい
0406名前は開発中のものです。2008/12/28(日) 17:34:36ID:pzJs6/UU
MVCでいうと、
M:StgScene
V,C:Menu,Playing
ってことなのだろうか？
Stateパターンという風にも捉えられる？
0407名前は開発中のものです。2008/12/29(月) 00:45:07ID: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();
　}
};
0408名前は開発中のものです。2009/01/07(水) 23:21:00ID: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したシーンに子が出来て、自分がフォーカスシーンで無いことを表す。
・原則として、自分の子供と祖先の子供以外には直接遷移できないとする。する必要も考えられないので。

･･･っとここまで書いて、ソースコードがないとどう考えても伝わらんだろと思った。

0409名前は開発中のものです。2009/01/07(水) 23:25:20ID:rBsXmGd8
しかもミスってる。
# unfocusing　･･･『戻り値に次の遷移先シーンかnull返す。』　←×

正しくは、+Updateの行の後ろに『戻り値に次の遷移先シーンかnull返す。』と書くつもりでした。

0410名前は開発中のものです。2009/01/09(金) 00:07:48ID:vYDzTrO8
自作の状態遷移クラスに似てるな。

・状態に親子関係がある。
・戻り値の意味によって遷移先を決める。
・自分の子、先祖の子以外は直接遷移できない。

ってあたり、ほぼ同じっぽい。

戻り値って具体的に何を返しているの？
自分の場合、STAGE_CLEARとかの定数を返している。
その値をみて、さらに親へ遷移(戻り値を返す)したり、子供へ遷移したりしてる。
0411名前は開発中のものです。2009/01/09(金) 01:05:35ID:2TNYOX7D
>>410
このソース、イベントといってるところでわかるように、C#です。Updateの戻り値はSceneインスタンスですね。
C#ではhoge.GetType()でインスタンスの型情報(Typeインスタンス)が取得できるもんで、それを定数代わりに利用します。
で、戻り値に対する処理はこんな感じ。

戻り値がnullなら、フォーカスシーンが孫以下であることを表します。

戻り値sceneのGetType()と、
・ChildのTypeインスタンスと比較すれば遷移が不要かどうかわかります。(等しければ移動していない。)
・定数として保持させたType配列と比較すれば遷移先が子かどうかはわかります。
・自分のTypeインスタンスと比較すれば遷移先が自分かどうかがわかります。自分ならば、focusingで初期化処理を呼び出します。
・それ以外の場合、祖先および祖先の子のいずれかであることがわかります。いずれにしても上位のシーンに処理を仰ぎ、自分は破棄されます。

ってかんじでしょうかね。
0412名前は開発中のものです。2009/01/09(金) 01:28:17ID:vYDzTrO8
インスタンスそのものを返すのかぁ。
確かにそのほうが直接的ですっきりするかもね。
0413名前は開発中のものです。2009/01/10(土) 23:29:07ID:GXwf3cbn
インスタンスを生成するのは作成した瞬間にクラスが2つ分になってメモリが足りなくて死ぬ
危険があるから1個間にはさみたいな。

生成メソッドはstaticにするとかなんとか。
0414名前は開発中のものです。2009/01/11(日) 00:09:06ID:dWwzUAmX
まて、よく意味はわからんが今時のゲームやるようなWindows環境前提なら、最低でも500MB程度はメモリに余裕があるだろう。
どう考えても使いきれるとは思えん
0415名前は開発中のものです。2009/01/11(日) 02:43:39ID:cWr0moum
あれか？　NSAppみたいなアプリケーションのインスタンスを丸ごとコピーするとかの話か？
0416名前は開発中のものです。2009/01/12(月) 02:58:31ID:8xCnbJpy
>>414
PCならそうかもしれないけど、コンシューマ機だと360でやっと512MB(ただしVRAM込み)、
DSにいたっては4MBしかないからね。
0417名前は開発中のものです。2009/01/12(月) 03:30:42ID:mDvqZ10E
シーン遷移時に元シーン内で新シーンのインスタンスを生成するのは、
そのコンストラクタへシーン用引数を指定できるのがメリットかな。

あと、シーンコンストラクタ/デストラクタとは別にシーン初期化/解放メソッドを定義しておいて、
シーンのコンストラクタは必要なシーン用引数のメンバへの保存だけを行うような形にすれば、
メモリが足りないということは殆どなくなると思うけどね。

それから、個人的な意見としては、
シーンが生成される際にはまだ生成元シーンのインスタンスへはアクセス可能でいたい。
このライフサイクルのほうが、現在の実行状態を認識し易くて、様々な仕様変更に柔軟に耐えうると思う。
0418名前は開発中のものです。2009/01/12(月) 03:32:37ID:mDvqZ10E
ごめん
×ライフサイクル
○ライフタイム
0419名前は開発中のものです。2009/01/12(月) 11:14:49ID:pb2pea9L
そのあたりの話は研究しがいがあるな。
0420名前は開発中のものです。2009/01/12(月) 13:32:30ID:YXD0YS+N
>>418
一応、常にnewするのは遷移元シーン、deleteするのは対象のシーンの親、ってことになってるけどこれじゃだめかな？
クラス図の関連が木構造で、枝をはさみで切るイメージ。
0421名前は開発中のものです。2009/01/12(月) 14:12:02ID:sqS0O25/
シーンをまたぐデータは、そもそもシーンが管理すべきなのか
検討した方がいいかも。
0422名前は開発中のものです。2009/01/13(火) 22:46:08ID:BhFnEm7r
シーンを跨ぐデータはスマートポインタみたいなもんで管理するんだが
そのポインタを渡すのにシーン生成を先にしたいという感じかな。

オレは管理マネージャ作るけど。
0423名前は開発中のものです。2009/01/13(火) 22:46:54ID:BhFnEm7r
管理マネージャじゃマネージャマネージャだなｗ

まあC++になって楽になったものよ。
0424名前は開発中のものです。2009/01/14(水) 03:24:31ID:0DnXfUAy
>>421
原則として、シーンをまたぐデータはないように設計する。…言い方が悪いな
あるシーンで使われたデータは、その子シーンで使われることがあっても、祖先のシーンで使われることはないように設計する。

あるシーンが持つデータを子シーンが使いたかったら、
>>417が言ってくれているように、コンストラクタで自由に子シーンに渡してしまう。
まぁほとんどの場合はコンストラクタ時に親シーンをそのまま子シーンに渡す。(子シーンで使いたいデータはpublicにしておく)
0425名前は開発中のものです。2009/01/14(水) 03:32:21ID:0DnXfUAy
親シーン子シーン関係なくデータを引き継ぐ場合として考えられるのは、例えばこんなときか。
ゲームを普通にプレイしてゲームオーバー表示(プレイ画面に追加表示)。その後ハイスコア画面に行くと考えると、
スコアの点数がまたぐデータになる。

RootScene>GameScene>GamePlaying
から
RootScene>GameScene>GamePlaying>GameOver
となり、その後
RootScene>HighScoreScene
に遷移する。

その際GameOverがHiScoreSceneを生成する際にコンストラクタでスコアデータを渡してやれば無問題。
0426名前は開発中のものです。2009/01/17(土) 14:39:28ID:AWtASysq
YAGNI
0427名前は開発中のものです。2009/01/21(水) 22:53:35ID:sHv/LIGj
スレが止まってるとさびしいな。
独り言でも言ってるか。

STGを作るときに、解決すべき内容は。
・1/60秒や入力情報など、最も基本的なものの構築。
・シーン遷移等、シーン管理の構築。
ここまでで共通の枠組みは作れる。シーン遷移はこのスレで紹介してたやり方でいくとして。

実際のゲーム中の解決すべき内容は
・自機、敵機などを1オブジェクトとするとして、オブジェクトの構造およびオブジェクト達の管理方法。
・敵出現(=ステージ情報)の作成方法、および管理方法や、それにかかわること。(リプレイとか。)
・あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・オブジェクト同士の衝突判定の記述。衝突判定まで。
・誘導弾など、常に依存先がかわるオブジェクトの記述方法。
で一通りっぽい。この手順でオブジェクトのインタフェースや管理方法を徐々に改良すると考える。


0428名前は開発中のものです。2009/01/21(水) 23:23:50ID:sHv/LIGj
オブジェクトの構造とそれらの管理。
前提として、管理のことを踏まえスーパークラスで多態性する。

publicにしそうな変数は　位置、速度、耐久力(=生存判定)
publicにしそうな関数は　更新、描画
いまいち不定だけどpublicで必要そうなものは、衝突判定にかかわるもの。

どこまでを1オブジェクトとするか。
・部位破壊が出来るものなど、一方的に依存するオブジェクトは別オブジェクトとして扱う。状況によっては相互参照も許可、を想定。
（本質的にバリアや耐久力表示と同じ関係なので。）
0429名前は開発中のものです。2009/01/22(木) 00:12:28ID:P249I5A7
ステージ情報の管理。
これを管理するクラスを一つ作る。主なデータとしては
敵出現データ情報（背景出現情報)、ランダムシード、ステージ進行速度。ついでに入力情報の蓄積もここがやると見通しがいいかも。

基本的に言語そのままでは出現情報は記述しづらいので適当なスクリプトを自作する。
wait、enemy、background、musicがあれば十分。
ボス戦手前などに掛け合いをはさむなら、event命令もあるといい。
簡単に変更できるようにすることを考えると、命令を分岐、並列に記述できる文法があると便利。
(waitによる相対時間出現なので。現在の出現配置を維持しつつ追加したいときとか。)

この方法は読んだ人は気づいてると思うけど、ある本を参考にしました。

0430名前は開発中のものです。2009/01/22(木) 00:45:44ID:P249I5A7
で、今は
あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)

・依存オブジェクトの生成は、被依存が関わってくるのでそれの参照を取得する方法は深く考える必要はない。
・完全な対応関係ならば、依存オブジェクトは被依存オブジェクトをその型で参照を保持する。
(スーパークラスで保持する必要性がない。被依存側の、依存側で必要なメンバはpublicにする。)
・逆に、誘導弾やエフェクトなどは被依存をスーパークラスで参照を保持する。

>>428で生存判定がインタフェースにいるので、ここら辺は融通が利く。
0431名前は開発中のものです。2009/01/22(木) 00:57:55ID:P249I5A7
オブジェクト同士の衝突判定の記述。衝突判定まで。

・複数の矩形で衝突判定を処理するオブジェクトがいることが想定される(ボスなど。)
→バウンディングボックスも実装。
・後々考えると、回転可能な矩形判定が後腐れない。
→バウンディングサークルにしといた方が、記述の割りに回転に対応できる。

衝突判定データを保持するクラスを作って、オブジェクトは衝突判定データのインスタンスをリスト構造(場合によっては木構造)で保持。がいい感じ。
オブジェクトを2つ受け取り、それの衝突判定を走査する、という処理を行う関数をつくればいい。

誘導弾などの実装、は思案中。いい感じが思いつかない。

0432名前は開発中のものです。2009/01/22(木) 04:27:16ID:lwlInfIx
>>427-431
とりあえず「管理」という言葉を使わないように考えることをおすすめする。
http://www.google.co.jp/search?q=SomethingManager
0433名前は開発中のものです。2009/01/22(木) 04:40:32ID:P249I5A7
>>432
サンクス。こんな考え方があったのか
言われてみれば、作り始めたての頃は○○Managerや○○Dataはかなりいた気がする。
今は1個だけしかいないところを見ると(UpdateManager)、自然とどうやら身についてはいるっぽい。
0434名前は開発中のものです。2009/01/22(木) 15:25:00ID:x7I7tNfu
大抵のクラスは、何か管理してるか、何かのデータを持ってる気がする。
0435名前は開発中のものです。2009/01/29(木) 21:46:47ID:dRfTqeNw
そうだけど、それとクラスの名前が〜管理、〜データになることはイコールじゃないよねって話でしょ
管理とは何をすることなのか、そのデータは何を表わしているのかが名前で分かった方がいい
0436名前は開発中のものです。2009/01/30(金) 16:55:21ID:O2nIHOeq
>>434は別に口答えしてるわけじゃない気がするｗ
■ このスレッドは過去ログ倉庫に格納されています