- 1 名前：名前は開発中のものです。 [2008/05/23(金) 21:10:59 ID:8M1gqhPX]
- 具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。
関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。
前スレ
pc11.2ch.net/test/read.cgi/gamedev/1155209226/
テンプレ追加事項あったらよろすく
- 364 名前：名前は開発中のものです。 [2008/09/02(火) 17:44:29 ID:IXiySr/S]
- なるほど
- 365 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 19:17:31 ID:gmtfIbjx]
- それ車が「パンクしたか？」メソッド持ってるんじゃダメなの？
- 366 名前：名前は開発中のものです。 [2008/09/02(火) 19:20:27 ID:IXiySr/S]
- 車が、常に「パンクしたか？」ってタイヤに聞くの？
- 367 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 19:24:40 ID:gmtfIbjx]
- うん
パンクに限らずあらゆる故障具合をウェルネスシステムが監視しててそいつに聞けば全部OKみたいな
車のメソッドじゃなくなったけど
- 368 名前：名前は開発中のものです。 [2008/09/02(火) 19:38:46 ID:IXiySr/S]
- メディエーターみたいなの？
- 369 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 20:44:39 ID:F4HrtZLF]
- >>366
実際のTPMS（タイヤ空気圧監視システム）はそういうものだよ。
ホイールに取り付けられたセンサーモジュールが車両本体側装置と一定時間毎に無線交信してる
具体的には、本体が一定時間毎に圧力値を問い合わせ。センサーモジュールが圧力値を返してる
ポーリング処理。
float _pressure = m_wheel[n]->GetPressureState();
- 370 名前：名前は開発中のものです。 mailto:sage [2008/09/19(金) 19:13:57 ID:FmM/zRja]
- ほしゅ
- 371 名前：名前は開発中のものです。 mailto:sage [2008/10/05(日) 14:32:14 ID:tMuqv+yj]
- このスレはJavaでも大丈夫なの？
- 372 名前：名前は開発中のものです。 mailto:sage [2008/10/05(日) 14:52:40 ID:v7IsXRIY]
- >>371
質問内容の分野がよくわからないなら、以下へどうぞ。
【初心者】ｽﾚを立てる前にｺｺで質問を【Part17】
pc11.2ch.net/test/read.cgi/gamedev/1210443288
- 373 名前：名前は開発中のものです。 mailto:sage [2008/10/05(日) 17:40:56 ID:6np9SFhP]
- >372がエスパーすぎる
- 374 名前：名前は開発中のものです。 mailto:sage [2008/11/01(土) 11:27:07 ID:g//jQFBy]
- データ(アイテムとかマップとか)ってどうやって作ってます？
エクセルで打ち込んでcsvで保存？
- 375 名前：名前は開発中のものです。 mailto:sage [2008/11/01(土) 12:46:01 ID:YmfIaKZ8]
- 別にそれでいいし
専用にエディタ作ってもいいし
ありもので済ませてもいいし
俺はPlatinum map editor使ってるし
- 376 名前：名前は開発中のものです。 mailto:sage [2008/11/01(土) 12:58:04 ID:g//jQFBy]
- >>375
マップに関しては、フリーのエディタがあるんですね。
規模が小さいゲームなら、アイテムとかはエクセルが効率いいのかな。
- 377 名前：名前は開発中のものです。 mailto:sage [2008/11/01(土) 16:47:28 ID:NlVHrve1]
- 既存のマップツールは便利なんだが、結局そこから独自形式へのコンバータを作ってる。
- 378 名前：名前は開発中のものです。 mailto:sage [2008/11/02(日) 08:08:32 ID:JeGt0JB9]
- 海岸線自動生成とかやってくれるエディタあるっけ？
- 379 名前：名前は開発中のものです。 mailto:sage [2008/11/02(日) 09:02:07 ID:i1X6CLvS]
- >378
エディタでやるの？
- 380 名前：名前は開発中のものです。 mailto:sage [2008/11/04(火) 18:29:40 ID:CIBt14+U]
- 機能としてはエディタ側じゃね？
- 381 名前：名前は開発中のものです。 mailto:sage [2008/11/06(木) 00:16:08 ID:46fvhfrF]
- ツクールで海岸線をシフト＋右クリックすると分かる
- 382 名前：名前は開発中のものです。 mailto:sage [2008/11/11(火) 20:24:09 ID:rtOtwyEd]
- 最近Gofのデザインパターンを読んで、目から鱗が落ちまくった。
今までぐだぐだやってたのが全部無駄というか馬鹿だったのに気づいてしまった。
他の初心者がこんなことが起きないように、勝手にメモ。
1、相互参照は可能ならば避ける。どちらかが一方的に知り、メソッドでその都度渡すほうがいい。
→クラス図の関連の矢印の向きは重要。関連が1方向なら、関連される（変数として保持される側の）クラスの再利用が容易。
→相互参照関係にあるクラス同士を、一方的な関連にすることは大抵の場合可能なはず。（関連する側が冗長になるが。）
2、再利用を考えたフレームワークは（初心者は）作らない。
→再利用のための部品を作る程度にとどめるのがいい。フレームワークの設計は正直拡張性を考え出すと難しすぎるらしい。
他に鉄則があったらだれか教えてください orz
- 383 名前：名前は開発中のものです。 mailto:sage [2008/11/12(水) 01:30:10 ID:LsEQ4TEa]
- 相互参照すると、クラス開放時にお互いが争ってメモリリークすんだよな
クラスA「Bさん、お先にどうぞどうぞ」
クラスB「いえいえ、ここはAさんがお先に」
クラスA「どうぞどうぞ」
OS「おまえら、どっちもさっさとイケ！」
ピー…
- 384 名前：名前は開発中のものです。 mailto:sage [2008/11/12(水) 09:02:45 ID:QWqH0Tgg]
- > Gofのデザインパターン
GOF本でわかったならよいけど、退屈でわからない人は
First Headの本オススメ
Head Firstデザインパターン―頭とからだで覚えるデザインパターンの基本: エリック フリーマン, キャシー シエラ, エリザベス フリーマン, バート ベイツ, Eric Freeman, Kathy Sierra, Elisabeth Freeman, Bert Bates, 佐藤 直生, 木下 哲也, 福龍興業: Amazon.co.jp: 本
www.amazon.co.jp/dp/4873112494
images-jp.amazon.com/images/P/4873112494.09.MZZZZZZZZZ.jpg
- 385 名前：名前は開発中のものです。 mailto:sage [2008/11/12(水) 23:23:14 ID:hxIHNKys]
- ライブラリを作るとして、名前空間とクラスはどのように配置するのがいいでしょうか。
たとえば、ある単純な機能のクラスがいくつかあります。
これを集約してより大きな機能のあるクラスがライブラリ内で作られている場合、
1、大きなクラスをネスト先の名前空間に入れる。（HogeLibrary.Composite）
2、小さなクラスをネスト先の名前空間に入れる。（HogeLibrary.SmallComponent）
3、そもそもが間違い。同一名前空間に配置する。
どれが適切でしょうか？
- 386 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 21:08:31 ID:3NMFClPL]
- >>385
boostでは、ライブラリ利用者が直接触る必要ないものはdetailっていうネームスペースに入れてあるね。
ってそういう話じゃない？
- 387 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 01:18:47 ID:USS/q0/d]
- >>385
名前空間を分けるメリットが見当たらなければ分けないほうがいいでしょ。
- 388 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 02:04:27 ID:OW89wflh]
- ライブラリ利用者の立場にたって、
どうなってると使いやすいかを考えて臨機応変に決める。
- 389 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 20:47:58 ID:oq/eqnIP]
- >>382-384
まだ読んでいない俺には勉強になったthx
- 390 名前：名前は開発中のものです。 mailto:sage [2008/11/20(木) 09:17:22 ID:jP0yKBYe]
- >>384
のFirst Head本は、読み物形式で
悪いコードをよいコードに変更していきながら、解説しているようになっているので、
GOF本よりかなり読みやすいよ
ただ、いくつかのパターンが省略されて適当解説になっているので、注意。
適当になってる後半部分も解説されていたらかなり神本だった
（まああのペースで全部網羅すると、値段とページがすごいことになりそうだがｗ）
- 391 名前：名前は開発中のものです。 mailto:sage [2008/11/30(日) 20:02:56 ID:GlMxgFAf]
- すいませんというか疑問です。
特定の条件を満たしたら処理(入力の読み取り)を行う、という作業を内部で行う関数を作ろうと思ったのですが、疑問がいろいろ出てきました。
(1回のループの中に複数この関数を配置して、どこかで実際に実行する、というような使い方を想定してます。)
1、この関数を採用する場合、名前の付け方
Polls()、CanPoll()、IsPolling() …主目的が『必要ならば読み取る』なので何かしっくりしない。
2、何かよりよい代替の設計があるだろうか
何か設計が変な気がする、が、なぜそう思うのはわからない。
どなたか導きをお願いします
- 392 名前：名前は開発中のものです。 mailto:sage [2008/11/30(日) 20:03:41 ID:GlMxgFAf]
- なんかいっぱい改行が入ってるorz
- 393 名前：名前は開発中のものです。 mailto:sage [2008/11/30(日) 20:44:16 ID:O5396ILY]
- >>391
関数の名前は内部での処理なんて割とどうでもいいので、
とにかくその関数の意味(挙動)がわかる名前にしたらいいんじゃね。
ちなみにJavaの場合、キーボードやマウスからの入力によってイベントが発生し、
そのイベントによって適切なリスナーの関数が起動されます。
プログラムの本流が直接読みに行くことなんてしません。
- 394 名前：名前は開発中のものです。 mailto:sage [2008/12/02(火) 23:03:37 ID:QPPOGJkH]
- >>393
気持ちが悪かったから、結局色々こねくり回して何とか別の方法で実装しました。
DirectInputのBufferedは偉大ですね、と。
- 395 名前：名前は開発中のものです。 mailto:sage [2008/12/03(水) 00:00:25 ID: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 名前：名前は開発中のものです。 mailto:sage [2008/12/13(土) 14:29:53 ID:lcU0tpK0]
- ゲーム開発論を語るスレを立てようと思っていたんですが、すでに似たようなスレがあると聞いて相談にきました。
このスレがあるので必要ないのでは？という意見があり、新スレを立てるべきかどうか迷っています。
ご意見頂けないでしょうか？
↓ゲーム開発論スレ要望の経緯
pc11.2ch.net/test/read.cgi/gamedev/1206381315/
ＫＯＮＡＭＩ、スクエニ、セガ、バンナム、コーエーの大手5社がゲーム開発現場の未来を再び討議
「5年後のゲーム開発現場を考える〜ゲーム会社技術開発の現場から2〜」
game.watch.impress.co.jp/docs/20080916/cedec_dev.htm
「Gears of War」はいかにして生まれたのか。Cliff Bleszinski氏が語る，有効なゲーム開発プロセス
www.4gamer.net/news/history/2007.03/20070309215934detail.html
Agile型開発でのゲームデザイン
www.4gamer.net/news/history/2007.03/20070311002313detail.html
- 397 名前：名前は開発中のものです。 [2008/12/14(日) 06:46:04 ID:foB3PhGt]
- >>396
ここは実装について話すスレなので、開発論は全くのお門違い。
とっとと失せろ！！
- 398 名前：名前は開発中のものです。 mailto:sage [2008/12/14(日) 06:47:43 ID:3zIx1sHY]
- 想定通りでワロタ
- 399 名前：名前は開発中のものです。 mailto:sage [2008/12/15(月) 01:28:13 ID:AODSdSoN]
- >>395
ありがとう助かるよ
- 400 名前：名前は開発中のものです。 [2008/12/18(木) 23:54:28 ID:QLMqRIYY]
- キャラクタのデータはテキストファイルにゆだねて動的にできるけど
ふるまいはどうすればいいんだろう。
基本ふるまいをプログラムに実装して(静的)、テキストファイルで
その呼び出しを記述する(動的)とかなのかな。他に思いつかん。
- 401 名前：名前は開発中のものです。 mailto:sage [2008/12/19(金) 12:11:03 ID:ygbWfkiR]
- 俺はそうしてる。
- 402 名前：名前は開発中のものです。 mailto:sage [2008/12/21(日) 09:35:05 ID:7nb+zy1b]
- つまりスクリプトですね。
- 403 名前：名前は開発中のものです。 mailto:sage [2008/12/25(木) 19:24:07 ID:QpPf00tD]
- 知ってるよDIって言うんだよね
- 404 名前：名前は開発中のものです。 mailto:sage [2008/12/26(金) 01:45:37 ID: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 名前：名前は開発中のものです。 mailto:sage [2008/12/26(金) 08:47:36 ID:Y8oI6MzT]
- 「勝手にメモ」を書き込んでくれる人（達？）の存在は、正直ありがたい
- 406 名前：名前は開発中のものです。 mailto:sage [2008/12/28(日) 17:34:36 ID:pzJs6/UU]
- MVCでいうと、
M:StgScene
V,C:Menu,Playing
ってことなのだろうか？
Stateパターンという風にも捉えられる？
- 407 名前：名前は開発中のものです。 mailto:sage [2008/12/29(月) 00:45:07 ID: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 名前：名前は開発中のものです。 mailto:sage [2009/01/07(水) 23:21:00 ID: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 名前：名前は開発中のものです。 mailto:sage [2009/01/07(水) 23:25:20 ID:rBsXmGd8]
- しかもミスってる。
# unfocusing ･･･『戻り値に次の遷移先シーンかnull返す。』 ←×
正しくは、+Updateの行の後ろに『戻り値に次の遷移先シーンかnull返す。』と書くつもりでした。
- 410 名前：名前は開発中のものです。 mailto:sage [2009/01/09(金) 00:07:48 ID:vYDzTrO8]
- 自作の状態遷移クラスに似てるな。
・状態に親子関係がある。
・戻り値の意味によって遷移先を決める。
・自分の子、先祖の子以外は直接遷移できない。
ってあたり、ほぼ同じっぽい。
戻り値って具体的に何を返しているの？
自分の場合、STAGE_CLEARとかの定数を返している。
その値をみて、さらに親へ遷移(戻り値を返す)したり、子供へ遷移したりしてる。
- 411 名前：名前は開発中のものです。 mailto:sage [2009/01/09(金) 01:05:35 ID:2TNYOX7D]
- >>410
このソース、イベントといってるところでわかるように、C#です。Updateの戻り値はSceneインスタンスですね。
C#ではhoge.GetType()でインスタンスの型情報(Typeインスタンス)が取得できるもんで、それを定数代わりに利用します。
で、戻り値に対する処理はこんな感じ。
戻り値がnullなら、フォーカスシーンが孫以下であることを表します。
戻り値sceneのGetType()と、
・ChildのTypeインスタンスと比較すれば遷移が不要かどうかわかります。(等しければ移動していない。)
・定数として保持させたType配列と比較すれば遷移先が子かどうかはわかります。
・自分のTypeインスタンスと比較すれば遷移先が自分かどうかがわかります。自分ならば、focusingで初期化処理を呼び出します。
・それ以外の場合、祖先および祖先の子のいずれかであることがわかります。いずれにしても上位のシーンに処理を仰ぎ、自分は破棄されます。
ってかんじでしょうかね。
- 412 名前：名前は開発中のものです。 mailto:sage [2009/01/09(金) 01:28:17 ID:vYDzTrO8]
- インスタンスそのものを返すのかぁ。
確かにそのほうが直接的ですっきりするかもね。
- 413 名前：名前は開発中のものです。 mailto:sage [2009/01/10(土) 23:29:07 ID:GXwf3cbn]
- インスタンスを生成するのは作成した瞬間にクラスが2つ分になってメモリが足りなくて死ぬ
危険があるから1個間にはさみたいな。
生成メソッドはstaticにするとかなんとか。
- 414 名前：名前は開発中のものです。 mailto:sage [2009/01/11(日) 00:09:06 ID:dWwzUAmX]
- まて、よく意味はわからんが今時のゲームやるようなWindows環境前提なら、最低でも500MB程度はメモリに余裕があるだろう。
どう考えても使いきれるとは思えん
- 415 名前：名前は開発中のものです。 mailto:sage [2009/01/11(日) 02:43:39 ID:cWr0moum]
- あれか？ NSAppみたいなアプリケーションのインスタンスを丸ごとコピーするとかの話か？
- 416 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 02:58:31 ID:8xCnbJpy]
- >>414
PCならそうかもしれないけど、コンシューマ機だと360でやっと512MB(ただしVRAM込み)、
DSにいたっては4MBしかないからね。
- 417 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 03:30:42 ID:mDvqZ10E]
- シーン遷移時に元シーン内で新シーンのインスタンスを生成するのは、
そのコンストラクタへシーン用引数を指定できるのがメリットかな。
あと、シーンコンストラクタ/デストラクタとは別にシーン初期化/解放メソッドを定義しておいて、
シーンのコンストラクタは必要なシーン用引数のメンバへの保存だけを行うような形にすれば、
メモリが足りないということは殆どなくなると思うけどね。
それから、個人的な意見としては、
シーンが生成される際にはまだ生成元シーンのインスタンスへはアクセス可能でいたい。
このライフサイクルのほうが、現在の実行状態を認識し易くて、様々な仕様変更に柔軟に耐えうると思う。
- 418 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 03:32:37 ID:mDvqZ10E]
- ごめん
×ライフサイクル
○ライフタイム
- 419 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 11:14:49 ID:pb2pea9L]
- そのあたりの話は研究しがいがあるな。
- 420 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 13:32:30 ID:YXD0YS+N]
- >>418
一応、常にnewするのは遷移元シーン、deleteするのは対象のシーンの親、ってことになってるけどこれじゃだめかな？
クラス図の関連が木構造で、枝をはさみで切るイメージ。
- 421 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 14:12:02 ID:sqS0O25/]
- シーンをまたぐデータは、そもそもシーンが管理すべきなのか
検討した方がいいかも。
- 422 名前：名前は開発中のものです。 mailto:sage [2009/01/13(火) 22:46:08 ID:BhFnEm7r]
- シーンを跨ぐデータはスマートポインタみたいなもんで管理するんだが
そのポインタを渡すのにシーン生成を先にしたいという感じかな。
オレは管理マネージャ作るけど。
- 423 名前：名前は開発中のものです。 mailto:sage [2009/01/13(火) 22:46:54 ID:BhFnEm7r]
- 管理マネージャじゃマネージャマネージャだなｗ
まあC++になって楽になったものよ。
- 424 名前：名前は開発中のものです。 mailto:sage [2009/01/14(水) 03:24:31 ID:0DnXfUAy]
- >>421
原則として、シーンをまたぐデータはないように設計する。…言い方が悪いな
あるシーンで使われたデータは、その子シーンで使われることがあっても、祖先のシーンで使われることはないように設計する。
あるシーンが持つデータを子シーンが使いたかったら、
>>417が言ってくれているように、コンストラクタで自由に子シーンに渡してしまう。
まぁほとんどの場合はコンストラクタ時に親シーンをそのまま子シーンに渡す。(子シーンで使いたいデータはpublicにしておく)
- 425 名前：名前は開発中のものです。 mailto:sage [2009/01/14(水) 03:32:21 ID:0DnXfUAy]
- 親シーン子シーン関係なくデータを引き継ぐ場合として考えられるのは、例えばこんなときか。
ゲームを普通にプレイしてゲームオーバー表示(プレイ画面に追加表示)。その後ハイスコア画面に行くと考えると、
スコアの点数がまたぐデータになる。
RootScene>GameScene>GamePlaying
から
RootScene>GameScene>GamePlaying>GameOver
となり、その後
RootScene>HighScoreScene
に遷移する。
その際GameOverがHiScoreSceneを生成する際にコンストラクタでスコアデータを渡してやれば無問題。
- 426 名前：名前は開発中のものです。 mailto:sage [2009/01/17(土) 14:39:28 ID:AWtASysq]
- YAGNI
- 427 名前：名前は開発中のものです。 mailto:sage [2009/01/21(水) 22:53:35 ID:sHv/LIGj]
- スレが止まってるとさびしいな。
独り言でも言ってるか。
STGを作るときに、解決すべき内容は。
・1/60秒や入力情報など、最も基本的なものの構築。
・シーン遷移等、シーン管理の構築。
ここまでで共通の枠組みは作れる。シーン遷移はこのスレで紹介してたやり方でいくとして。
実際のゲーム中の解決すべき内容は
・自機、敵機などを1オブジェクトとするとして、オブジェクトの構造およびオブジェクト達の管理方法。
・敵出現(=ステージ情報)の作成方法、および管理方法や、それにかかわること。(リプレイとか。)
・あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・オブジェクト同士の衝突判定の記述。衝突判定まで。
・誘導弾など、常に依存先がかわるオブジェクトの記述方法。
で一通りっぽい。この手順でオブジェクトのインタフェースや管理方法を徐々に改良すると考える。
- 428 名前：名前は開発中のものです。 mailto:sage [2009/01/21(水) 23:23:50 ID:sHv/LIGj]
- オブジェクトの構造とそれらの管理。
前提として、管理のことを踏まえスーパークラスで多態性する。
publicにしそうな変数は 位置、速度、耐久力(=生存判定)
publicにしそうな関数は 更新、描画
いまいち不定だけどpublicで必要そうなものは、衝突判定にかかわるもの。
どこまでを1オブジェクトとするか。
・部位破壊が出来るものなど、一方的に依存するオブジェクトは別オブジェクトとして扱う。状況によっては相互参照も許可、を想定。
（本質的にバリアや耐久力表示と同じ関係なので。）
- 429 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 00:12:28 ID:P249I5A7]
- ステージ情報の管理。
これを管理するクラスを一つ作る。主なデータとしては
敵出現データ情報（背景出現情報)、ランダムシード、ステージ進行速度。ついでに入力情報の蓄積もここがやると見通しがいいかも。
基本的に言語そのままでは出現情報は記述しづらいので適当なスクリプトを自作する。
wait、enemy、background、musicがあれば十分。
ボス戦手前などに掛け合いをはさむなら、event命令もあるといい。
簡単に変更できるようにすることを考えると、命令を分岐、並列に記述できる文法があると便利。
(waitによる相対時間出現なので。現在の出現配置を維持しつつ追加したいときとか。)
この方法は読んだ人は気づいてると思うけど、ある本を参考にしました。
- 430 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 00:45:44 ID:P249I5A7]
- で、今は
あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・依存オブジェクトの生成は、被依存が関わってくるのでそれの参照を取得する方法は深く考える必要はない。
・完全な対応関係ならば、依存オブジェクトは被依存オブジェクトをその型で参照を保持する。
(スーパークラスで保持する必要性がない。被依存側の、依存側で必要なメンバはpublicにする。)
・逆に、誘導弾やエフェクトなどは被依存をスーパークラスで参照を保持する。
>>428で生存判定がインタフェースにいるので、ここら辺は融通が利く。
- 431 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 00:57:55 ID:P249I5A7]
- オブジェクト同士の衝突判定の記述。衝突判定まで。
・複数の矩形で衝突判定を処理するオブジェクトがいることが想定される(ボスなど。)
→バウンディングボックスも実装。
・後々考えると、回転可能な矩形判定が後腐れない。
→バウンディングサークルにしといた方が、記述の割りに回転に対応できる。
衝突判定データを保持するクラスを作って、オブジェクトは衝突判定データのインスタンスをリスト構造(場合によっては木構造)で保持。がいい感じ。
オブジェクトを2つ受け取り、それの衝突判定を走査する、という処理を行う関数をつくればいい。
誘導弾などの実装、は思案中。いい感じが思いつかない。
- 432 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 04:27:16 ID:lwlInfIx]
- >>427-431
とりあえず「管理」という言葉を使わないように考えることをおすすめする。
www.google.co.jp/search?q=SomethingManager
- 433 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 04:40:32 ID:P249I5A7]
- >>432
サンクス。こんな考え方があったのか
言われてみれば、作り始めたての頃は○○Managerや○○Dataはかなりいた気がする。
今は1個だけしかいないところを見ると(UpdateManager)、自然とどうやら身についてはいるっぽい。
- 434 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 15:25:00 ID:x7I7tNfu]
- 大抵のクラスは、何か管理してるか、何かのデータを持ってる気がする。
- 435 名前：名前は開発中のものです。 mailto:sage [2009/01/29(木) 21:46:47 ID:dRfTqeNw]
- そうだけど、それとクラスの名前が〜管理、〜データになることはイコールじゃないよねって話でしょ
管理とは何をすることなのか、そのデータは何を表わしているのかが名前で分かった方がいい
- 436 名前：名前は開発中のものです。 mailto:sage [2009/01/30(金) 16:55:21 ID:O2nIHOeq]
- >>434は別に口答えしてるわけじゃない気がするｗ
- 437 名前：名前は開発中のものです。 mailto:sage [2009/01/31(土) 08:12:45 ID:qu7YpnnP]
- アクションゲームとかでキャラの座標って本当にキャラ自身が持つべきなのかな？
とたまに悩む
- 438 名前：名前は開発中のものです。 mailto:sage [2009/01/31(土) 12:07:33 ID:2t9biDkM]
- Ｇｅｍｓにある『コンポーネントベースのオブジェクト管理』とか見てみるとよい
- 439 名前：名前は開発中のものです。 mailto:sage [2009/01/31(土) 19:06:11 ID:mhj1e1O5]
- そのへん追求し始めたらキリ無いよねw
最近はもう深く考えるのはやめた
- 440 名前：名前は開発中のものです。 mailto:sage [2009/01/31(土) 19:11:05 ID:L0OEs6zN]
- >>437
悩む悩むｗ
- 441 名前：名前は開発中のものです。 mailto:sage [2009/02/01(日) 19:03:38 ID:tMKL4U61]
- >>437
1番近い敵キャラが攻撃してくる
って処理を書いたときに同じ疑問を俺も感じた。
int near = CEnemy::returnNearNum();
enemy[near].attack();
↑こんな感じで静的なメンバ変数を返して貰っていたけど
STGみたいに「自機」対「敵機達」ならこれでもいいんだけど
ボンバーマンみたいなバトルロワイヤルとかサッカーやアメフトみたいなボールゲームとか
お互いの位置関係が重要なゲームになるとステージ側が管理すべきかなと。
- 442 名前：名前は開発中のものです。 mailto:sage [2009/02/02(月) 20:35:13 ID:esDSGZyH]
- ステージ側でやってることが多くなって
どこかに細分化できないかなと悩み出すんですね
わかります
- 443 名前：名前は開発中のものです。 mailto:sage [2009/02/03(火) 03:59:27 ID:cOF6NPxT]
- キャラの位置をステージ側で管理する手法も
割と普通だとは思うけど、OOP前提なら避けたいかなあ
近傍キャラの検索スピードを最適化したいということなら
ステージ側に直前のフレームでの位置情報のコピーを作るとか
- 444 名前：名前は開発中のものです。 mailto:sage [2009/02/06(金) 21:51:27 ID:+KF0MHRv]
- たとえば、石クラスと、マップクラスと、それらを管理するシーンクラスがあったとして、
・石に重力を働かせる処理
・石と石の衝突処理
・石とマップの衝突処理
は、それぞれどのクラスが担当すべきだろうか。
- 445 名前：名前は開発中のものです。 mailto:sage [2009/02/06(金) 21:56:52 ID:jTgjQpbm]
- >>444
物の理を司る GOD class
- 446 名前：名前は開発中のものです。 mailto:sage [2009/02/06(金) 21:57:18 ID:sBGSiXKq]
- 分からないから指向をそのままレスとして出力。
・ゲームは現実を模倣するものじゃないから、重力が全てに等しく働くとは限らない。
・が、固有の係数との積で出せばいいからやはり個々ではない所に基本重力値を。
・衝突判定方法をあらかじめ限定しておけば、二つの物体を引数にとって判定を返す関数を作ることが可能。
・同上により、マップと石との判定をあらかじめ限定化すれば、独立した関数として定義可能。
ごめん、適当に書いただけ。
- 447 名前：名前は開発中のものです。 mailto:sage [2009/02/06(金) 21:58:24 ID:y5Y5dk+m]
- 唐突に石とかマップとかいわれても一般性がなさすぎてバックグラウンドがよくわからん
- 448 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 00:34:27 ID://aDzdii]
- > ・石に重力を働かせる処理
石クラス
> ・石と石の衝突処理
マップクラスに位置情報を登録して一括処理
> ・石とマップの衝突処理
石クラス
- 449 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 01:46:53 ID:HaVHq232]
- > ・石に重力を働かせる処理
石クラス
> ・石と石の衝突処理
衝突判定クラス
> ・石とマップの衝突処理
衝突判定クラス
- 450 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 13:25:16 ID:bH//onUq]
- > ・石に重力を働かせる処理
ゲーム管理クラス
> ・石と石の衝突処理
ゲーム管理クラス
> ・石とマップの衝突処理
ゲーム管理クラス
- 451 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 14:22:20 ID:VS035g6S]
- > ・石に重力を働かせる処理
石に重力クラス
> ・石と石の衝突処理
石と石の衝突処理クラス
> ・石とマップの衝突処理
右とマップの衝突処理クラス
- 452 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 14:51:09 ID:VC/wpjC+]
- >>451
オブジェクトの衝突判定の組み合わせの数だけクラス作るつもり？
- 453 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 16:19:23 ID:Pn1Dl7Zh]
- >>450
CGameManagerですね、わかります
- 454 名前：447 mailto:sage [2009/02/07(土) 16:35:33 ID:oHEfOG3S]
- みんな何のことだかわかっていて俺涙目
- 455 名前：名前は開発中のものです。 mailto:sage [2009/02/13(金) 17:17:04 ID:gamtZzLZ]
- テーマが石なら、
>・石に重力を働かせる処理
シーン管理クラス
>・石と石の衝突処理
シーン管理クラス
>・石とマップの衝突処理
シーン管理クラス
だな。
石なら質量・形(テクスチャ)・位置・速度・加速度など汎用なメンバ変数だけで事足りる。
シーンに乗る子オブジェクトを継承した石クラスを作っておいておくだけ。
石クラスの中身は空で、後々必要になったら拡張できるぐらいにとどめておく。
だから感覚的にはクラスを用いただけの構造体のような使い方で書くかな。
これがもし石でなく、人のような思考の多様性を持たせるのなら、また話は変わってくるかも。
- 456 名前：名前は開発中のものです。 mailto:sage [2009/02/13(金) 17:35:30 ID:gamtZzLZ]
- 455だけど、修正
やっぱ衝突判定クラス作るわ。
シーン管理は保持オブジェクトと描画などについて司るだけで、
オブジェクト(石やらマップやら)をそれに入れて判定するだけにとどめておくのがいいと思った。
- 457 名前：名前は開発中のものです。 mailto:sage [2009/02/14(土) 00:06:30 ID:wuF2UeZP]
- 沈静化したネタに対するレスより新たなネタの方がスレが進んでうれしいと思うな、思うな
- 458 名前：名前は開発中のものです。 mailto:sage [2009/02/14(土) 00:20:27 ID:+0ELSliX]
- >>457
じゃあ新たなネタ出せよ
- 459 名前：名前は開発中のものです。 mailto:sage [2009/02/14(土) 01:01:03 ID:1cFYmXpg]
- ああ。誘導されて初めて来たんで、日付もろくに見てなかった。悪い。
新しいネタか……。じゃあ、１つだけ。
ゲームって作りながらデバッグや、完成してからももちろんチェックするんだろうけど、
その過程でゲーム特有のデバッグ手法があれば教えてほしい。
リークチェックやAssert使うとかの普遍的な手法の話というよりは、
ゲーム特化で、データ構造・クラス・パターンの観点から、、
いかにしてスクリプト上の変な挙動を見破れる技法だとか、
デバッグメニューとして必要なものは何かだとかそういうのが知りたい。
自分のようなアマチュアではそこまで手が回らないんで、
いつも自分で修正・テストを繰り返して大体動くなと思ったらテストプレイをお願いしている。
そんな中、どのように効率よく(少ないコード＆短かい時間で)デバッグできるか教えてほしい。
そもそもデータ構造やクラスを気をつけていればバグは出ないとかいうのは無しで。
- 460 名前：名前は開発中のものです。 mailto:sage [2009/02/14(土) 03:08:07 ID:qKH3GStO]
- 人にデバッグを頼むのであれば、調べたい場所まですぐにたどり着けるような仕組みを。
無敵モードとかステージセレクトみたいな。
当然ながら、バランスチェックを含めたテストプレイならこれらの機能はＯＦＦで。
コリジョンの可視化。特定のボタンやデバッグ用のフラグでコリジョン無視。
エネミーやアイテムを自由に配置。デバッグメニューからのパラメータ操作。
ボタン一発で勝利／敗北または成功／失敗。必要に応じて、強制クリティカルとか強制回避なども。
アニメーションやオブジェクトの移動の速度コントロール（数十倍〜数十分の一まで）。
特定の状況下のセーブデータ捏造、隠しやおまけの強制解放。
スクリプトはエラーチェックを厳しくするぐらいしか思いつかないな……。
- 461 名前：名前は開発中のものです。 mailto:sage [2009/02/14(土) 10:08:02 ID:hPf9zE7f]
- リリース用には付けなくても、デバッグ用にリプレイ機能あるといいよ。
- 462 名前：名前は開発中のものです。 mailto:sage [2009/02/15(日) 16:27:42 ID:933sIzgh]
- 速度調整機能つけたりログ吐かしたり
そんくらいしかやっていないな。
- 463 名前：名前は開発中のものです。 mailto:sage [2009/02/18(水) 14:05:52 ID:1weRwVko]
- >>460-462
いろいろありがとう。
あらかたデバッグ用に実装してみました。
- 464 名前：名前は開発中のものです。 mailto:sage [2009/02/18(水) 14:39:48 ID:0gTNCSoI]
- 行動力あるね
素晴らしい。見習いたい
|
 |
