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オブジェクトとするとして、オブジェクトの構造およびオブジェクト達の管理方法。
・敵出現(=ステージ情報)の作成方法、および管理方法や、それにかかわること。(リプレイとか。)
・あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・オブジェクト同士の衝突判定の記述。衝突判定まで。
・誘導弾など、常に依存先がかわるオブジェクトの記述方法。
で一通りっぽい。この手順でオブジェクトのインタフェースや管理方法を徐々に改良すると考える。
428:名前は開発中のものです。
09/01/21 23:23:50 sHv/LIGj
オブジェクトの構造とそれらの管理。
前提として、管理のことを踏まえスーパークラスで多態性する。
publicにしそうな変数は 位置、速度、耐久力(=生存判定)
publicにしそうな関数は 更新、描画
いまいち不定だけどpublicで必要そうなものは、衝突判定にかかわるもの。
どこまでを1オブジェクトとするか。
・部位破壊が出来るものなど、一方的に依存するオブジェクトは別オブジェクトとして扱う。状況によっては相互参照も許可、を想定。
（本質的にバリアや耐久力表示と同じ関係なので。）
429:名前は開発中のものです。
09/01/22 00:12:28 P249I5A7
ステージ情報の管理。
これを管理するクラスを一つ作る。主なデータとしては
敵出現データ情報（背景出現情報)、ランダムシード、ステージ進行速度。ついでに入力情報の蓄積もここがやると見通しがいいかも。
基本的に言語そのままでは出現情報は記述しづらいので適当なスクリプトを自作する。
wait、enemy、background、musicがあれば十分。
ボス戦手前などに掛け合いをはさむなら、event命令もあるといい。
簡単に変更できるようにすることを考えると、命令を分岐、並列に記述できる文法があると便利。
(waitによる相対時間出現なので。現在の出現配置を維持しつつ追加したいときとか。)
この方法は読んだ人は気づいてると思うけど、ある本を参考にしました。
430:名前は開発中のものです。
09/01/22 00:45:44 P249I5A7
で、今は
あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・依存オブジェクトの生成は、被依存が関わってくるのでそれの参照を取得する方法は深く考える必要はない。
・完全な対応関係ならば、依存オブジェクトは被依存オブジェクトをその型で参照を保持する。
(スーパークラスで保持する必要性がない。被依存側の、依存側で必要なメンバはpublicにする。)
・逆に、誘導弾やエフェクトなどは被依存をスーパークラスで参照を保持する。
>>428で生存判定がインタフェースにいるので、ここら辺は融通が利く。
431:名前は開発中のものです。
09/01/22 00:57:55 P249I5A7
オブジェクト同士の衝突判定の記述。衝突判定まで。
・複数の矩形で衝突判定を処理するオブジェクトがいることが想定される(ボスなど。)
→バウンディングボックスも実装。
・後々考えると、回転可能な矩形判定が後腐れない。
→バウンディングサークルにしといた方が、記述の割りに回転に対応できる。
衝突判定データを保持するクラスを作って、オブジェクトは衝突判定データのインスタンスをリスト構造(場合によっては木構造)で保持。がいい感じ。
オブジェクトを2つ受け取り、それの衝突判定を走査する、という処理を行う関数をつくればいい。
誘導弾などの実装、は思案中。いい感じが思いつかない。
432:名前は開発中のものです。
09/01/22 04:27:16 lwlInfIx
>>427-431
とりあえず「管理」という言葉を使わないように考えることをおすすめする。
URLﾘﾝｸ(www.google.co.jp)
433:名前は開発中のものです。
09/01/22 04:40:32 P249I5A7
>>432
サンクス。こんな考え方があったのか
言われてみれば、作り始めたての頃は○○Managerや○○Dataはかなりいた気がする。
今は1個だけしかいないところを見ると(UpdateManager)、自然とどうやら身についてはいるっぽい。
434:名前は開発中のものです。
09/01/22 15:25:00 x7I7tNfu
大抵のクラスは、何か管理してるか、何かのデータを持ってる気がする。
435:名前は開発中のものです。
09/01/29 21:46:47 dRfTqeNw
そうだけど、それとクラスの名前が～管理、～データになることはイコールじゃないよねって話でしょ
管理とは何をすることなのか、そのデータは何を表わしているのかが名前で分かった方がいい
436:名前は開発中のものです。
09/01/30 16:55:21 O2nIHOeq
>>434は別に口答えしてるわけじゃない気がするｗ
437:名前は開発中のものです。
09/01/31 08:12:45 qu7YpnnP
アクションゲームとかでキャラの座標って本当にキャラ自身が持つべきなのかな？
とたまに悩む
438:名前は開発中のものです。
09/01/31 12:07:33 2t9biDkM
Ｇｅｍｓにある『コンポーネントベースのオブジェクト管理』とか見てみるとよい
439:名前は開発中のものです。
09/01/31 19:06:11 mhj1e1O5
そのへん追求し始めたらキリ無いよねw
最近はもう深く考えるのはやめた
440:名前は開発中のものです。
09/01/31 19:11:05 L0OEs6zN
>>437
悩む悩むｗ
441:名前は開発中のものです。
09/02/01 19:03:38 tMKL4U61
>>437
1番近い敵キャラが攻撃してくる
って処理を書いたときに同じ疑問を俺も感じた。
int near = CEnemy::returnNearNum();
enemy[near].attack();
↑こんな感じで静的なメンバ変数を返して貰っていたけど
STGみたいに「自機」対「敵機達」ならこれでもいいんだけど
ボンバーマンみたいなバトルロワイヤルとかサッカーやアメフトみたいなボールゲームとか
お互いの位置関係が重要なゲームになるとステージ側が管理すべきかなと。
442:名前は開発中のものです。
09/02/02 20:35:13 esDSGZyH
ステージ側でやってることが多くなって
どこかに細分化できないかなと悩み出すんですね
わかります
443:名前は開発中のものです。
09/02/03 03:59:27 cOF6NPxT
キャラの位置をステージ側で管理する手法も
割と普通だとは思うけど、OOP前提なら避けたいかなあ
近傍キャラの検索スピードを最適化したいということなら
ステージ側に直前のフレームでの位置情報のコピーを作るとか
444:名前は開発中のものです。
09/02/06 21:51:27 +KF0MHRv
たとえば、石クラスと、マップクラスと、それらを管理するシーンクラスがあったとして、
・石に重力を働かせる処理
・石と石の衝突処理
・石とマップの衝突処理
は、それぞれどのクラスが担当すべきだろうか。
445:名前は開発中のものです。
09/02/06 21:56:52 jTgjQpbm
>>444
物の理を司る GOD class
446:名前は開発中のものです。
09/02/06 21:57:18 sBGSiXKq
分からないから指向をそのままレスとして出力。
・ゲームは現実を模倣するものじゃないから、重力が全てに等しく働くとは限らない。
・が、固有の係数との積で出せばいいからやはり個々ではない所に基本重力値を。
・衝突判定方法をあらかじめ限定しておけば、二つの物体を引数にとって判定を返す関数を作ることが可能。
・同上により、マップと石との判定をあらかじめ限定化すれば、独立した関数として定義可能。
ごめん、適当に書いただけ。
447:名前は開発中のものです。
09/02/06 21:58:24 y5Y5dk+m
唐突に石とかマップとかいわれても一般性がなさすぎてバックグラウンドがよくわからん
448:名前は開発中のものです。
09/02/07 00:34:27 //aDzdii
> ・石に重力を働かせる処理
石クラス
> ・石と石の衝突処理
マップクラスに位置情報を登録して一括処理
> ・石とマップの衝突処理
石クラス
449:名前は開発中のものです。
09/02/07 01:46:53 HaVHq232
> ・石に重力を働かせる処理
石クラス
> ・石と石の衝突処理
衝突判定クラス
> ・石とマップの衝突処理
衝突判定クラス
450:名前は開発中のものです。
09/02/07 13:25:16 bH//onUq
> ・石に重力を働かせる処理
ゲーム管理クラス
> ・石と石の衝突処理
ゲーム管理クラス
> ・石とマップの衝突処理
ゲーム管理クラス
451:名前は開発中のものです。
09/02/07 14:22:20 VS035g6S
> ・石に重力を働かせる処理
石に重力クラス
> ・石と石の衝突処理
石と石の衝突処理クラス
> ・石とマップの衝突処理
右とマップの衝突処理クラス
452:名前は開発中のものです。
09/02/07 14:51:09 VC/wpjC+
>>451
オブジェクトの衝突判定の組み合わせの数だけクラス作るつもり？
453:名前は開発中のものです。
09/02/07 16:19:23 Pn1Dl7Zh
>>450
CGameManagerですね、わかります
454:447
09/02/07 16:35:33 oHEfOG3S
みんな何のことだかわかっていて俺涙目
455:名前は開発中のものです。
09/02/13 17:17:04 gamtZzLZ
テーマが石なら、
>・石に重力を働かせる処理
シーン管理クラス
>・石と石の衝突処理
シーン管理クラス
>・石とマップの衝突処理
シーン管理クラス
だな。
石なら質量・形(テクスチャ)・位置・速度・加速度など汎用なメンバ変数だけで事足りる。
シーンに乗る子オブジェクトを継承した石クラスを作っておいておくだけ。
石クラスの中身は空で、後々必要になったら拡張できるぐらいにとどめておく。
だから感覚的にはクラスを用いただけの構造体のような使い方で書くかな。
これがもし石でなく、人のような思考の多様性を持たせるのなら、また話は変わってくるかも。
456:名前は開発中のものです。
09/02/13 17:35:30 gamtZzLZ
455だけど、修正
やっぱ衝突判定クラス作るわ。
シーン管理は保持オブジェクトと描画などについて司るだけで、
オブジェクト(石やらマップやら)をそれに入れて判定するだけにとどめておくのがいいと思った。
457:名前は開発中のものです。
09/02/14 00:06:30 wuF2UeZP
沈静化したネタに対するレスより新たなネタの方がスレが進んでうれしいと思うな、思うな
458:名前は開発中のものです。
09/02/14 00:20:27 +0ELSliX
>>457
じゃあ新たなネタ出せよ
459:名前は開発中のものです。
09/02/14 01:01:03 1cFYmXpg
ああ。誘導されて初めて来たんで、日付もろくに見てなかった。悪い。
新しいネタか……。じゃあ、１つだけ。
ゲームって作りながらデバッグや、完成してからももちろんチェックするんだろうけど、
その過程でゲーム特有のデバッグ手法があれば教えてほしい。
リークチェックやAssert使うとかの普遍的な手法の話というよりは、
ゲーム特化で、データ構造・クラス・パターンの観点から、、
いかにしてスクリプト上の変な挙動を見破れる技法だとか、
デバッグメニューとして必要なものは何かだとかそういうのが知りたい。
自分のようなアマチュアではそこまで手が回らないんで、
いつも自分で修正・テストを繰り返して大体動くなと思ったらテストプレイをお願いしている。
そんな中、どのように効率よく(少ないコード＆短かい時間で)デバッグできるか教えてほしい。
そもそもデータ構造やクラスを気をつけていればバグは出ないとかいうのは無しで。
460:名前は開発中のものです。
09/02/14 03:08:07 qKH3GStO
人にデバッグを頼むのであれば、調べたい場所まですぐにたどり着けるような仕組みを。
無敵モードとかステージセレクトみたいな。
当然ながら、バランスチェックを含めたテストプレイならこれらの機能はＯＦＦで。
コリジョンの可視化。特定のボタンやデバッグ用のフラグでコリジョン無視。
エネミーやアイテムを自由に配置。デバッグメニューからのパラメータ操作。
ボタン一発で勝利／敗北または成功／失敗。必要に応じて、強制クリティカルとか強制回避なども。
アニメーションやオブジェクトの移動の速度コントロール（数十倍～数十分の一まで）。
特定の状況下のセーブデータ捏造、隠しやおまけの強制解放。
スクリプトはエラーチェックを厳しくするぐらいしか思いつかないな……。
461:名前は開発中のものです。
09/02/14 10:08:02 hPf9zE7f
リリース用には付けなくても、デバッグ用にリプレイ機能あるといいよ。
462:名前は開発中のものです。
09/02/15 16:27:42 933sIzgh
速度調整機能つけたりログ吐かしたり
そんくらいしかやっていないな。
463:名前は開発中のものです。
09/02/18 14:05:52 1weRwVko
>>460-462
いろいろありがとう。
あらかたデバッグ用に実装してみました。
464:名前は開発中のものです。
09/02/18 14:39:48 0gTNCSoI
行動力あるね
素晴らしい。見習いたい
465:名前は開発中のものです。
09/02/19 03:37:37 4unT5BXH
いやいや。実装したのはこんだけです。
コリジョン可視化:テクスチャ読み込み後に四隅に沿って緑色で四角線を書くだけ
パラメータ操作:テンキーで実装
4と6で対象パラメータを選択 (あらかじめ操作対象を手動でlistしておく)
789でパラメータ上昇(7で+1,8で+10,9で+100)
123でパラメータ下降(1で-1,2で-10,3で+100)
0で強制0(bool値ならfalse)
便利ボタン:戦闘強制勝利機能とエンカウント無効をFXXキーに割り当て
速度コントロール:VSync非同期にして、FPSを上げることで対応
2倍にすると早すぎたので、1.5倍(90fps)をボタンに割り当て
リプレイ機能:フレームごとの入力(キーボード/ジョイパッドを合わせた入力値)をファイルに出力
(一見単純そうだけど、セーブ/ロードの関係でこれには実装に手間取った)
作っているのがRPGなので、便利ボタンとパラメータ操作がとても役に立っています。
ありがとうございました。
466:名前は開発中のものです。
09/02/21 07:24:48 3Qcrn5pr
洋ゲーだと、LuaみたいなDSLをスクリプトとして組み込んでるせいか、
ゲーム中でもコンソール出して直接変数いじったりできるのがあるよな。
467:名前は開発中のものです。
09/02/21 12:50:08 YLpnm94h
ｽﾚﾘﾝｸ(gamedev板)
468:名前は開発中のものです。
09/02/24 16:03:05 xS4ZudQO
スマートポインタの使いどころ教えて
469:名前は開発中のものです。
09/02/25 02:46:38 1o4GjPkR
使いどころっつーわけじゃないけど
次のC++規格が決まれば、早ければ今年中にも
std::shared_ptr
として使えるようになる予定
今でも既に std::tr1::shared_ptr になってるけど
470:名前は開発中のものです。
09/02/25 05:08:14 M8Pe/6zZ
>>468
まず一般的に、スマートポインタは動的確保されたヒープに用いるとして。
使いどころは、
・ヒープの解放処理を書くのが面倒であったり忘れてしまいたいとき
・ヒープの被参照期間を別のオブジェクトらの生存期間と一致させたいとき
・ヒープの参照状態を把握したいとき
・これまでのソースが生ポインタで参照しまくり不正参照でメモリ破壊しまくりで発狂しそうなとき
だと思う。
471:名前は開発中のものです。
09/02/25 11:43:26 woJXacCs
要約すると、いろんな人・場所で使われるポインタだったら使いどきってことですか
472:名前は開発中のものです。
09/02/25 18:18:12 QjeqtKpK
Yes
いろんなとこから参照されていて、開放時期が掴めないときは最高に便利
理論的には、参照カウンタが0になったら自動的に消えていってくれるよ
473:名前は開発中のものです。
09/02/25 18:28:42 nKINhS/o
つまり、いらなくなったらすぐに消されるってことですね
私のように
474:名前は開発中のものです。
09/02/25 18:31:43 Z+e+XbPJ
不況だもんな・・・
475:名前は開発中のものです。
09/02/25 18:55:09 1o4GjPkR
いや、それは地球の資源不足で君の給料が確保できないだけだ
スマートポインタがあれば使われなくなった人材をどんどん自動破棄して・・・
476:名前は開発中のものです。
09/02/27 15:15:39 MDeQuwXl
例えばDirectxのDeviceインスタンスなど、あらゆる所で使われそうなインスタンスは、どう使ってますでしょうか？
Draw、Moveを持つオブジェクトと画面の表示物が1対1で対応してる設計で、
リソース(画像や効果音)などの情報も全てオブジェクトがコンストラクタで受け取り内部で保持してるいかにもoopな設計なのですが、
Deviceインスタンスは
1、Drawの引数に渡す
2、コンストラクタで引数にとり、各オブジェクトがあらかじめ参照を保持。
3、グローバル変数
4、そもそもその設計はまずい
5、その他
現在2です。
1から3に共通する問題としては、Deviceインスタンスをオブジェクト内で操作した内容が間違ってた場合、
発見がかなりめんどくさそうな所でしょうか?
477:名前は開発中のものです。
09/02/27 15:58:46 XnWaU4Ou
デバイスホルダー的なシングルトン作るとか
478:名前は開発中のものです。
09/02/27 17:33:53 lChaxYTz
俺もシングルトンかな。参照回数が0になったらreleaseで。
479:名前は開発中のものです。
09/02/28 00:40:47 OR4wkfx2
ハッシュテーブルのキーって文字列じゃなくてもいいのかな？
符号なし整数とか。
どっかにそういう例ないです？
480:名前は開発中のものです。
09/02/28 08:42:03 Cadu6Xk7
ハッシュが計算できるなら、キーはなんでもいいよ
481:名前は開発中のものです。
09/03/04 04:45:32 y6+tTW6F
>>479
こんなんでいいか？
URLﾘﾝｸ(codezine.jp)
482:名前は開発中のものです。
09/03/06 11:34:39 7UNSgj8M
C++でシングルトンするのってなんか滑稽じゃね？
Javaじゃないんだし
そこまでクラス原理主義にならんでもいいのにと思う
483:名前は開発中のものです。
09/03/06 13:08:45 A313Daxt
>>482
グローバル変数が欲しいんではなくて、システム全体で一つしかないということを
明示的にする為のパターンだから
484:名前は開発中のものです。
09/03/06 14:26:30 7UNSgj8M
グローバル変数関係ないやろ
普通にstaticで隠してヘッダで関数だけ提供すればいいやんけ
インスタンシエーション必須の言語が苦肉の策でひねり出したのがシングルトン
よーく考えよう
485:名前は開発中のものです。
09/03/06 14:28:31 7UNSgj8M
あ、ちょっとちがうな。
「クラス定義必須、インスタンシエーション普通」の言語だな。
486:名前は開発中のものです。
09/03/06 15:48:06 A313Daxt
>>484-485
エンド ユーザーがそのクラスを作成できてしまうじゃないか
作成できないようにしたのがシングルトンだろ
話変わるけどカプセル化って C++ や Java の特長みたいに言われるけど
C言語でも出来るんだよなー
487:名前は開発中のものです。
09/03/06 16:07:52 7UNSgj8M
>>486
そのクラスのインスタンスが１つであることを保証するのがシングルトン
クラス(原因)が無ければインスタンス(問題)も無い
だからシングルトン(解決策)も要らんと言っているんだ
C++でのシングルトンはマッチポンプなんだよ
488:名前は開発中のものです。
09/03/06 16:18:21 7UNSgj8M
URLﾘﾝｸ(www.geocities.jp)
「C++ シングルトン」でググったら出てきたページ
この労力を指して滑稽だと笑ってるんだけどな
Javaなら習得必須の概念だし俺も普通に使うが
C++でこんなん無理してやったら馬鹿みたいだと思わね？
// 生成やコピーを禁止する
↑アホじゃね？ 最初からクラスにしなきゃいいじゃん
クラス原理主義に陥って思考停止しちゃってるんじゃないか
目的と手段の関係について考え直してみるといい
489:名前は開発中のものです。
09/03/06 16:29:34 7UNSgj8M
まあ、要件に多態性があるならクラス化した方が楽かもしれんけど
それ以外だとやっぱり儀式めいたものを感じるな
490:名前は開発中のものです。
09/03/06 16:29:53 oPKUKLY9
先にクラス原理主義という単語を発してしまった時点で
ID:7UNSgj8Mが単なるC++においてのクラスアンチなだけに見える件
491:名前は開発中のものです。
09/03/06 16:34:17 7UNSgj8M
>>490
アンチクラスなんて単語あったんだ
知らなかった
C++でもクラス使いまくりなんだけど
C++でシングルトンやらないだけでアンチクラスか
492:名前は開発中のものです。
09/03/06 16:39:54 7UNSgj8M
クラスアンチだしｗ
URLﾘﾝｸ(www.google.co.jp)
ググるとアンチクラスが出てくる上にプログラムカンケーねえしｗ
まあいいや
C++シングルトン症候群と命名しておこう
マジで一度考え直した方がいい
493:名前は開発中のものです。
09/03/06 16:57:37 12yJl3As
労力って
コンストラクタをprivateにしたり、
コピーコンストラクタを宣言だけ記述したりするだけじゃん
>↑アホじゃね？ 最初からクラスにしなきゃいいじゃん
クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう
じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ
494:名前は開発中のものです。
09/03/06 17:07:43 7UNSgj8M
>クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう
いくらでもあるのか
そういや初期化を意識させたくない場合なんかもクラスで管理した方がいいな
あとは>>489
俺にはこの２つくらいしか思いつかんが
こういう風にクラス化する理由があるならいいんじゃね
>じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ
>>484
495:名前は開発中のものです。
09/03/06 17:20:31 12yJl3As
>>484の方が楽だとは思えない
まあでもお前がその方が楽だと言うなら尊重するよ
一緒に仕事する相手じゃないからな
496:名前は開発中のものです。
09/03/06 18:55:30 Erqh3NJs
namespaceでくるんだり全部staticメソッドにしたりもしてみたけど、
素直にシングルトンにしたほうがイディオム的に分かりやすいと思う。
ファクトリメソッドとかで、普通のオブジェクトと同じように生成したい場合も、
シングルトンのほうが便利だよね。
それと、あとから「やっぱシングルトンやめ」ってなったときに、
変更が少なくてすむのも利点かなあ。
497:名前は開発中のものです。
09/03/06 20:00:35 z7QigqBL
まぁ疑問を持つのは悪い事じゃない
他人に強要しなければね
498:名前は開発中のものです。
09/03/12 10:42:00 X7nBBwQA
Delphiでシングルトンする方法なんてこれだぞ(公式ライブラリVCLで使われている方法)
interface // 宣言部(C++のヘッダーにあたる)
type
TPrinter = class // クラスの宣言
：
end;
function Printer(): TPrinter;
implementation // 実装部(ヘッダーじゃない方)
var FPrinter: TPrinter; // グローバルへんすうw
function Printer(): TPrinter;
begin
if FPrinter = nil then FPrinter := TPrinter.Create; // TPrinter生成
Result := FPrinter
end;
厳密にインスタンス化の制限とか、もはやどうでもいいクラスｗ
499:名前は開発中のものです。
09/03/12 10:43:53 X7nBBwQA
>>498
捕捉：
（わかると思うけど）使う時は、他のユニットから
Printer.HogeMageSimasu;
見たいに使う
あと抜けてるけど、実際には、finalzation節？でアプリ終了時のFPrinterの開放処理がある。
500:名前は開発中のものです。
09/03/16 15:21:22 FTtiBwy2
また変なのが沸いてるのか
501:名前は開発中のものです。
09/03/18 23:45:50 1sOkzJT6
デバイスに直接アクセスする処理ってどこに書いてる？
今まであちこちに散らばって状態で書いてたんだけどなんか扱いづらい。
下みたいな感じで一箇所にまとめた方がいいのかな。
今：あちこちでデバイスにアクセス
void draw_landform(void) {
...
lpD3DDEV->draw(...);
}
void draw_menu(void) {
...
lpD3DDEV->draw(...);
}
案：デバイスアクセスは１箇所。デバイスに渡すデータをあちこちで作る。
const DrawData *draw_landform(void) {
...
return ...;
}
const DrawData *draw_menu(void) {
...
return ...;
}
void main_loop(void) {
draw_data.push(draw_landform(), ...);
draw_data.push(draw_menu(), ...);
lpD3DDEV->draw(draw_data, ...);
}
もし既に案の方法でやってる人いたら使い勝手教えて！
502:名前は開発中のものです。
09/03/19 04:54:27 KYbRBn+z
久々に答え甲斐のありそうな相談が来たな
だが俺はモーションインデックスとベクトルをリストに投げて後で一気に処理する方法だから答えられそうに無い
お前らに任せたぜっ！
503:名前は開発中のものです。
09/03/19 05:21:17 XLj1eEa+
描画能力のあるオブジェクトをリストなりグラフなりに登録しておいて、デバイスハンドルはビジターで渡す、とか。
504:名前は開発中のものです。
09/03/19 19:28:19 ALN5WhPj
俺はこの案では無いなぁ…てかどうせなら
lpD3DDEV->draw(draw_data, ...);
は
draw_data.draw(...);
みたいにしてlpD3DDEVに直接アクセスしない方が…
505:501
09/03/20 00:10:41 /TREybMM
レスありがとう。
>>502
「案」の方に似たやり方だよね？ draw_dataがリスト相当で。
やっぱやってる人いたか。採用してるってことは使いやすいんだろうか
>>503
void LandForm::draw(LPDIRECT3DDEVICE9 lpD3DDEV) {
...
lpD3DDEV->draw(...);
}
みたいな感じ？
デバイスに直接アクセスする処理が複数のクラスに散らばるのはＯＫという判断？
この方が使いやすいってことかな？ うーん。。。
>>504
Draw_data::draw(...) {
this->lpD3DDEV->draw(this->draw_data, ...);
}
こんな感じ？ ラッパー作れって話？
「案」ではないってことは 503 さん宛てのコードと同じ感じでやってるのか
うーん、デバイスクラスに依存するクラスが増えると身動き取りづらくなると思うんだけど
気になる人って少ないんだろうか。
0人では無かったけれど。
506:名前は開発中のものです。
09/03/20 02:39:39 D2lp0Ec4
まずはMVCを試みてみるのはどうだろうか
507:名前は開発中のものです。
09/03/20 04:52:36 09EDEaYz
struct Visitor;
struct Element { // 訪問される側の基底クラス
virtual void accept(Visitor&) = 0;
};
class Landform : Element {
public:
virtual void accept(Visitor& x) { x.visit(*this); }
Data* getLandData();
private:
...
};
class Menu : Element {
public:
virtual void accept(Visitor& x) { x.visit(*this); }
Data* getMenuData();
private:
...
};
struct Visitor { // 訪問する側の基底クラス
virtual void visit(Landform&) = 0;
virtual void visit(Menu&) = 0;
};
class DrawingVisitor : Visitor { // 各要素を訪れて描画を行うクラス
public:
DrawingVisitor(LPDIRECT3DDEVICE9 p) : pDevice(p) {}
virtual void visit(Landform& x) { pDevice->draw(x.getLandData()); }
virtual void visit(Menu& x) { pDevice->draw(x.getMenuData()); }
private:
LPDIRECT3DDEVICE9 pDevice;
};
続く…
508:名前は開発中のものです。
09/03/20 04:53:53 09EDEaYz
…続き
elementList.push_back(landform);
elementList.push_back(menu);
void mainLoop() {
DrawingVisitor visitor(lpD3DDEV);
for(ElementList::iterator i = elementList.begin(); i != elementList.end(); ++i) {
i->accept(visitor);
}
}
うーむ…。
509:501
09/03/21 12:54:05 Y4F/PoMw
>>506
今回の話ではModelとControllは関係なくて、Viewの枠内だけで完結する話だと思ってる
>>507
複雑すぎて俺の頭では完全には理解できないけど、
> virtual void visit(Landform& x) { pDevice->draw(x.getLandData()); }
> virtual void visit(Menu& x) { pDevice->draw(x.getMenuData()); }
ここを見るとデバイスに直接アクセスする処理を１クラス内、複数関数にまとめたって感じかな
うーん…、複数の関数にデバイスアクセス処理が分散してるとこがあまりうれしくないかな。
（俺には複雑過ぎるのはさておき）
俺が扱いづらいと思ってるところは、
pDeviceさえあればdraw()以外にもbegin_render()とかset_camera()とかいろいろ
デバイスに対して変更加えることができちゃうわけで、
それをばら撒くってことはいつどこでデバイスに変更が加わるか、例えばいつどこで何回begin_render()されてるのか
とかが追跡しづらくなる。これは１週間後の自分に優しくない。
こんな感じでデバイスに直接アクセスする処理をどう管理したもんかと考えて
ひとつの対策案としてデバイスアクセス処理を１関数内に限定しちゃえってのが >>501 の「案」。
だから例えば複数の関数に同一デバイスへのアクセス処理が分散してるのは自分的には問題が解決していないと感じる。
510:名前は開発中のものです。
09/03/22 03:32:29 O7e3N6nq
描画するにはデバイスに対して様々なパラメータを設定しなけりゃならんわけだが
>>501だとそこをどう処理するのかがよく分からない。
各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？
そうじゃないなら、結局デバイスをやりとりしなきゃならなくなるような。
511:501
09/03/23 00:38:25 /nVLLFvd
>>510
確かに。描画スクリプトかー、どうしよう。
ポリゴンの描画順番の最適化とかやり始めたら必要になりそうな気もするけど
今の自分のプログラムでは大げさすぎるかなぁ。今のところ2D的にしか使ってないし。
あとデバイスってサウンドとか入力装置とかもあるけど、それらもおんなじ感じで取り扱いたいし。
デバイスにアクセスする処理が関数１個の中に「ひとまとまりで」収まってればＯＫとするなら
下のように書いて済ませられるかな？
void dev_state1(void) {
lpD3DDEV->BeginScene();
lpD3DDEV->set_parameter(...);
lpD3DDEV->draw(draw_landform(), ...);
lpD3DDEV->set_parameter(...);
lpD3DDEV->draw(draw_menu(), ...);
lpD3DDEV->EndScene();
}
ひとまとまりってのは１フレーム分のデバイスアクセス処理全部。
描画内容を大きく変えたい時はdev_state2()とかをまた別に作っておいて、
ゲームのステートに応じてどれを実行するか切り替える。
なんか描画スクリプトの方が夢があるな。
外部GUIツールで描画内容を設計して
吐き出した描画スクリプトをゲームで解釈して表示とかおもしろそう。
でも描画システムの根幹過ぎて汎用的に作るのめんどくさそう。。。
うーん、とりあえず簡単に済ませたいからdev_state1()みたいにベタ書きで
どこまでいけるかやってみるかな。
512:名前は開発中のものです。
09/03/25 00:59:33 koP5FPqt
hamigaki::coroutines使ってみた。
513:名前は開発中のものです。
09/03/25 12:39:16 C50L0uFm
yhamigakiさんのexec.jamモジュールにはお世話になっております
514:名前は開発中のものです。
09/04/05 14:24:00 a5PaoF6B
スレッド1..n 仮想描画コマンドをメモリに積む
デバイス用スレッド 仮想描画コマンドを解釈して実際のコマンドを発行
利点 単体テストが容易、移植が容易、マルチコアの恩恵を受けることができる
欠点 仮想描画コマンドバッファの管理にロック、セマフォは必須、上手に使用しないと逆に重い
515:名前は開発中のものです。
09/04/06 03:21:58 NgKFyYts
仮想描画コマンドバッファをスレッドごとに持てばいいじゃない。
516:名前は開発中のものです。
09/07/15 22:32:12 1c2msACv
URLﾘﾝｸ(www6.atpages.jp)
クライアントからサーバーに要求を送って、サーバーから要求を受け取るような機能を付け加えたいんだが、どういう設計にすればいいかわからない。定石みたいなのがあったら教えてほしい。
今のクラス構成
ScreenManger-->ScreenGame-->Title
｜ |->Main-->Map -|
｜ -->Unit--->sprite--|
｜--------------------------------------------------------------->GraphicsWarpper
517:名前は開発中のものです。
09/07/15 22:40:07 h6KyoexM
WinAPI使ってるなら、WiｎSockで送信して、ウィンドーメッセージで受信する。他はｼﾗﾈ。
518:名前は開発中のものです。
09/07/15 22:41:36 3ppQI3l+
>>516
> ScreenManger
画面飼槽
> GraphicsWarpper
グラフィックスワープ装置
何が言いたいのかさっぱりわからないのだが。
519:516
09/07/15 22:46:53 1c2msACv
>>517
忘れてました。
net frameworkを使ってます。
>>518
ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます
GraphicsWarpperは単なるラッパーです。
520:名前は開発中のものです。
09/07/15 22:57:45 cL81hhcG
こんな面白い難読化もなかなかないな
521:名前は開発中のものです。
09/07/15 23:01:47 3ppQI3l+
>>519
> net frameworkを使ってます。
.NET Framework を勝手に先頭のドットを省略したり、勝手に小文字に変えたりするなよ・・
> ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます
それならMangerではなくManagerだろ。
> GraphicsWarpperは単なるラッパーです。
それなら、WarpperではなくWrapperだろ。
小学校は夏休みなのか・・
せめて中学生になってからにしてくれ
522:名前は開発中のものです。
09/07/15 23:14:16 1c2msACv
>>521
すまん。スペルミスった・・・。
523:名前は開発中のものです。
09/07/16 01:35:23 Ac1CnfQd
まず日本語と英語を勉強するべきでは？
そうじゃなくても、変数名などを略すのはやめた方がいい、複雑なコードになると対応できない
自分はdeleteHandCardListみたいな長い名前つけたりするけど、困ることは１つもないね
ちなみに件の話に関しては書籍があるよ
GameDeveloperのオンラインゲームの青本
MMORPGを作る赤本もある
2chで説明すると1スレ使っても無理だと思う
524:名前は開発中のものです。
09/07/16 02:06:03 Dq9kBSTx
>>523
ありがとう。
それをあたってみる。
525:名前は開発中のものです。
09/07/16 02:29:30 lK28N0n1
質問の内容と関係ない単語にしかつっこめない奴が多くてﾜﾗﾀ
526:名前は開発中のものです。
09/07/16 05:49:13 0eDNLm6a
2～3人で多いのか、寂しい生活してるんだな
527:名前は開発中のものです。
09/07/16 10:25:09 irpkCXOF
言われて悔しいならもっと勉強しろよ
528:名前は開発中のものです。
09/08/14 18:57:02 qfXJNhjS
コミケの影響で最近来なかったここを再び覗くように。変なテンションダァ･･･
>>395
395以前のまとめ
>>404,406-407
シーン遷移考え方
>>408-413,416-425
シーン遷移実装サンプルと問題点。
>>427-433
0からSTGの作成を考える。
根本的な勘違いや非効率的なことがあるのであまり参考にはならない。
>>437-443
オブジェクトと座標管理
>>444-456
オブジェクトと衝突判定と全体効果
>>459-465
デバッグ用処理を考える。(衝突判定表示とか)
>>501-511
DirectXのデバイスの管理とか使い方
>>523
ネットワーク機能参考図書紹介
529:名前は開発中のものです。
09/08/14 19:24:51 qfXJNhjS
STGのビジュアル関連向上に関するメモ。
･･･あんま設計と関係ないな･･･
それっぽい弾の作り方
・コマは2コマは以上用意して、画像の色を通常っぽいのと白っぽいのにする。アニメは4コマあればきれい。
・ケイブっぽい弾を作る場合。1コマ作った後、コピーして1ドットぐらい前後ずらし、形を適当に修正。明るい部分はなるべく中心に近づくよう修正。
・円形の回転する弾の工夫。わざと中心から斜めに1ドットずつずらす。
ちょっと光ったエフェクトとか。
・メイン画像と残像(というか残光)画像を用意。後は適当に残像表示の要領で重ね描画。
・センコロのブーストエフェクト。適当な○画像をブースター付近から扇子状に放射するだけ。それっぽいブーストグラフィックが得られる。
弾やエフェクトはポーズ連打して見てみたりすると、プログラムと画像をうまく考えれば誰でも作れるものが多い･･･気がする。
530:名前は開発中のものです。
09/08/14 22:21:56 FZUQWr9u
>>529
設計というよりは演出(エフェクト)の話でしょうか。
もし続けるなら専用のスレを立てた方がよいと思われ。
531:名前は開発中のものです。
09/10/05 01:40:33 mQYy5BRf
シミュレーションやRPGで
経営状況や主人公の内部パラメータと呼ばれる
データ群がごっそりあると思いますが，
そういったものの管理は
実際のゲーム開発でどういった形でなされるものですか？
データクラスを作ってアクセッサで操作を許す？
それとも，すべてグローバル変数で持たせる？
532:名前は開発中のものです。
09/10/05 04:33:25 /TvwIsfE
シングルトンクラスのオブジェクトをグローバルに定義する
533:名前は開発中のものです。
09/10/05 07:34:29 Rel4l/Gg
SQLiteとか使って手抜くってのもあり
534:名前は開発中のものです。
09/10/14 22:12:56 TwzkU58s
グローバル変数はありえない。データクラス。
ただ、データの表示とかはいつも頭を捻らすなぁ。
535:名前は開発中のものです。
09/10/15 07:50:05 P3b4xThD
アクセッサ書くのめんどいだろ
536:名前は開発中のものです。
09/10/15 08:41:22 OtHf9VTl
なんでそんな両極端なの？
537:名前は開発中のものです。
09/10/15 15:54:18 byjv3si3
0と1しか無いからな
オタクの頭ん中は
538:名前は開発中のものです。
09/10/15 20:13:55 P3b4xThD
別に両極端で構いません．
意見を頂けるだけで嬉しいです．
むしろ噛み付くほうが迷惑です．
539:名前は開発中のものです。
09/10/15 22:16:10 r8d5RKMA
使う人がデータを把握できてるなら好きにすればいいんだよ。
質問は実際のゲーム開発だから、面倒でも形式的にやるしかないんじゃない。
540:名前は開発中のものです。
09/10/15 22:18:05 2byzEsEE
>>535
アクセッサ書くのめんどくさいって言ってたら
コーディングが意味不明になってやる気をなくす自信がある。
実際それで何回も挫折した。分かりにくくなるくらいならメンドイ方がマシ。
541:名前は開発中のものです。
09/10/15 23:29:40 r8d5RKMA
俺は変数に直接アクセスでも分かりにくいと思わないし。
アクセッサ書くのもめんどくさいとは思わない。
542:536
09/10/16 00:35:50 L+kS7tAJ
>>538
悪い、噛み付くとかそういうつもりは無かった。
普通に設計して、グローバルにアクセスする必要があるデータを持ってるクラスだけ
Facade経由でアクセスできれば良いんじゃないかと思っただけ。
グローバル変数はさすがにあり得ない…
543:名前は開発中のものです。
09/10/16 01:18:33 MsmDVyev
２ｃｈで素直に謝られると逆に困ります．
参考になりました，ありがとうございます．
544:名前は開発中のものです。
09/10/16 01:38:32 tEeFyBBH
グローバル変数を利用側が直接更新したり参照したりするのはアウトだけど、
スタティックグローバルな変数を、何らかのアクセス関数を通して更新/参照するような設計は普通だと思う。
// gamedata.h
void update();
int get_parameter1();
// gamedata.cpp
static int s_paramter1 = 0;
static int s_paramter2 = 0;
....
void update() { /* 更新 */ }
int get_parameter1() { return s_paramter1; }
唯一しか存在しないゲーム中のデータをどう実装・管理するか、って視点だけで考えれば
スタティックグローバルであろうと、クラスであろうと大差ないと思うけど、
ある時点でのスナップショットを扱う必要がある、みたいな場合、
// gamedata.h
void update(Data* gamedata);
int get_parameter(Data* gamedata);
て感じで、結局データを引数で取る形になるから、クラスで実装して方がいいんじゃないかと思う。
545:名前は開発中のものです。
09/10/16 06:29:56 UJ9WR3Zt
代入の時などに別の処理を入れるんでなければ
変数を直接弄るんでもいいかな・・・。
546:名前は開発中のものです。
09/10/16 11:40:43 /PDPq+0/
入力値の正当性をチェックしたり、同時に変更しなければならないパラメータが1つじゃなかったり、
そういう可能性を考慮すると、関数を経由させたほうが便利。
547:名前は開発中のものです。
09/10/16 20:07:25 eJ9LLkd5
アクセッサ経由だとバグっぽい動きも引っ掛けやすいが、
そうでないと大変そうだな。デバッグ一件で1時間とか悩みたくないし。
548:名前は開発中のものです。
09/10/18 12:51:59 Yr/zm5ey
>546
確かに使い方を間違えるってのはよく起こる