5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :名前は開発中のものです。:2006/08/10(木) 20:27:06 ID:BnvyxuCB
具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

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

2 :名前は開発中のものです。:2006/08/10(木) 20:45:47 ID:X/dQa2Wp
はっ、意味不明

3 :名前は開発中のものです。:2006/08/10(木) 20:46:24 ID:8+CwRGdy
設定提案とヲチと批判しかできないこの過疎板で
技術を語れるかが見物だ。

4 :名前は開発中のものです。:2006/08/10(木) 22:23:22 ID:BnvyxuCB
抽象的過ぎたからひとまずお題を挙げておくか。
⊃「パックマン」

敵に関しては、敵の抽象クラスを継承したサブクラスで
移動アルゴリズムをオーバーライドするよりも、
アルゴリズムを別のクラスで用意して
それに対する参照を敵のクラスに持たせる方がいいのかな?

5 :名前は開発中のものです。:2006/08/10(木) 23:26:41 ID:BnvyxuCB

+-----------------------+
| CEnemy |
+-----------------------+
| move() |
| (strategy->execute()) |
+-----------<>----------+
| strategy
|
|
+-----V-----+
| Strategy |
+-----------+
| execute() |
+-----A-----+
|
+------+---------+----------+
| |
+------+-------+ +------+------+
|AkabeeStrategy| |PinkyStrategy|
+--------------+ +-------------+
| execute() | | execute() |
+--------------+ +-------------+

クラス図で書くとこうなるのか?まあ絶対ズレているだろうがな…。
俺自身は超初心者だから間違いがあったら指摘お願い。

6 :名前は開発中のものです。:2006/08/10(木) 23:27:33 ID:BnvyxuCB
ちょw
いくらなんでもズレすぎだ…。

7 :名前は開発中のものです。:2006/08/10(木) 23:29:52 ID:GhkTPLBd
パックマンごときに大げさなパターンはいらねべ。
敵キャラの個別化をしたければテンプレートメソッドパターンぐらいで十分。
好きにすればよい。

8 :名前は開発中のものです。:2006/08/10(木) 23:38:42 ID:BnvyxuCB
>>7
確かにその通りなんだが、
まあいきなり大規模なものを持ってきても
話しづらいかなと思って。

9 :名前は開発中のものです。:2006/08/10(木) 23:39:13 ID:BnvyxuCB
一応>>5のズレ直しverを貼っておこう…。

 +-----------------------+
 |      CEnemy      |
 +-----------------------+
 |      move()       |
 |  (strategy->execute())  |
 +-----------<>----------+
          | strategy
          |
          |
     +-----V-----+
     |  Strategy  |
     +-----------+
     |  execute() |
     +-----A-----+
          |
     +------+------------+----------+
     |               |
+------+-------+   +------+------+
| AkabeeStrategy |   | PinkyStrategy |
+--------------+   +-------------+
|  execute()   |   |  execute()   |
+--------------+   +-------------+

10 :名前は開発中のものです。:2006/08/11(金) 00:00:57 ID:YoP5XUOs
シューティングゲームの敵と敵から打たれるミサイルなんかは、
ファクトリメソッドパターンかな・・・

11 :名前は開発中のものです。:2006/08/11(金) 00:24:48 ID:C/hX80Tz
「こういうキャラに対しては何ちゃらパターンが使えるな」
みたいなことは大体わかるのだが、
全体をまとめようとするとうまくいかないのはオレだけか?

12 :名前は開発中のものです。:2006/08/11(金) 00:39:49 ID:jjyZUyYu
同じ方向に話を進めるためには
タスクシステムの内容を統一した方がいいんじゃね??

13 :名前は開発中のものです。:2006/08/11(金) 01:37:19 ID:tpCf6gfL
ttp://www.gamedesignpatterns.org/


14 :名前は開発中のものです。:2006/08/11(金) 05:13:38 ID:XHr3GWC7
名スレの予感

15 :名前は開発中のものです。:2006/08/11(金) 07:46:49 ID:8h85L6qq
>>9
CEnemyのCって何?

16 :名前は開発中のものです。:2006/08/11(金) 07:51:46 ID:sJYQdfLa
ClassのCじゃねぇの。

17 :名前は開発中のものです。:2006/08/11(金) 08:14:44 ID:pd/2z5bI
MFCを知らんのか?

18 :名前は開発中のものです。:2006/08/11(金) 08:22:18 ID:sJYQdfLa
うん、普通に知らない。

19 :名前は開発中のものです。:2006/08/11(金) 10:46:52 ID:fe4sLs9R
charだけあれば他は要らない

20 :名前は開発中のものです。:2006/08/11(金) 11:46:44 ID:YxjqBpJS
Cつけるのはダサいからやめろ。

21 :名前は開発中のものです。:2006/08/11(金) 13:15:07 ID:NMgVyy7Y
じゃあ、なにつければいいのさ?


22 :名前は開発中のものです。:2006/08/11(金) 13:16:16 ID:defJrMH6
そのクラスを直感的に理解できるよう努力すれば他に何もいらない

23 :名前は開発中のものです。:2006/08/11(金) 13:32:51 ID:DmUndduC
Cつけるの癖になってるなぁ。

24 :名前は開発中のものです。:2006/08/11(金) 14:04:44 ID:XHr3GWC7
コードスタイルはクラス設計とは関係ないだろ
Cの1文字ぐらい脳内削除できんのかね

25 :名前は開発中のものです。:2006/08/11(金) 15:22:03 ID:AWZ202Sp
大文字で始まる名詞はクラス以外ありえないから、無意味に邪魔なゴミつけるんじゃないよ。
今出回ってる雑誌や書籍、それにオープンソースのコードに
Cつけてるものがどれほどあるか見てみろ。
MSなんか、C#では逆にCを「つけるな」と言ってるしな。

>コードスタイルはクラス設計とは関係ないだろ

わざわざ変なスタイルを使うやつは、高確率で変なクラス設計をする。
普通にコードを書く気が最初からないんだから。

26 :名前は開発中のものです。:2006/08/11(金) 15:37:25 ID:mPv7ZiBt
>>25
コードスタイルについてはごもっともだけど、
>わざわざ変なスタイルを使うやつは、高確率で変なクラス設計をする。
って誰が言ってたのさ。統計とったの?
そうですか、あなたの経験上ですか。では、変なクラス設計の基準はどこに?

27 :名前は開発中のものです。:2006/08/11(金) 15:56:24 ID:XHr3GWC7
>>25
お前の言っていることは間違いではないが、焦点がズレているな
俺が言いたかったことは、>>9の敵クラス名がCEnemyだろうがEnemyだろうが
クラス図には何の影響もないということだ
変なスタイルを使う奴は云々という決め付けはいらない
設計がそこに転がっているんだからその優劣を語ればよい

28 :名前は開発中のものです。:2006/08/11(金) 16:01:15 ID:DmUndduC
>>25
何でそんなに興奮してるんだ?
コードスタイルは分かりやすさ、第一。
別にコード公開する気もないし。

29 :名前は開発中のものです。:2006/08/11(金) 16:32:11 ID:C/hX80Tz
>>7
Template Methodパターンだと、実行時に移動アルゴリズムを
変更したくなったときに面倒じゃないか?
パックマンがパワー餌を食べたことがMediatorを通して
通知されたとき、strategyを逃げるアルゴリズムに
変更すれば、同じ呼出しで適切な移動が可能。
まあ、オリジナルだと逃げるアルゴリズムは共通だから
それは組み込んでおいて通常移動はオーバーライドでも
問題ないけど、通常移動も動的に変更したいのならStrategyかな。

実際問題、パックマンを作るのにここまで慎重に設計する必要は
ないが、設計スレだし色々探ってみるのがよさそうだ。

30 :名前は開発中のものです。:2006/08/11(金) 18:51:41 ID:Vuvb9Lvy
>>11
俺もその辺はよく悩むな。
最近はゲーム全体の構造について再度考え直そうと思って、
ttp://www.jeffplummer.com/Writings/Thesis/Thesis_with_Appendix.pdf
このあたりを読んで研究中。
GDC'06のTim Sweeneyの講演(Building a Flexible Game Engine)のスライド早く公開されないもんかな。

31 :名前は開発中のものです。:2006/08/11(金) 20:08:38 ID:Ip8C/yOX
>>30
GDCのじゃないけどTim Sweeneyの別の場所での講演
スライド。参考までに。
ttp://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt

時間表現からレンダリング、シミュレーションの並列実行化という
レベルの全体構造を考えるならGDC06のSim, Render, Repeat
? An Analysis of Game Loop Architecturesおすすめ。

32 :名前は開発中のものです。:2006/08/11(金) 21:10:41 ID:C/hX80Tz
>>30-31
SUGEEEEEEE!!!
英語苦手だけど頑張って読んでみるか。

33 :名前は開発中のものです。:2006/08/11(金) 21:44:28 ID:Vuvb9Lvy
>>31
おぉ、トンクス。参考になりまつ。
やっぱり並列化も次世代機を考慮すると重要なトピックになりつつあるんだなぁ…

34 :名前は開発中のものです。:2006/08/11(金) 21:54:05 ID:Ip8C/yOX
シングルコアを使い切る→マルチスレッド
マルチコアを使い切る→並列同時実行

35 :名前は開発中のものです。:2006/08/12(土) 00:11:13 ID:Eayw3C5n
お前ら!TCBを格納するのに何使ってる?
STLのlist使ってたんだけど、
動的メモリ確保で遅くなるから配列を使った方がいいと聞いて…。
それから単方向ではなく双方向リスト構造にする利点があれば教えてくれ。

36 :名前は開発中のものです。:2006/08/12(土) 02:27:39 ID:pnW+o/wl
やだ

37 :名前は開発中のものです。:2006/08/12(土) 02:41:00 ID:Xdt1RmGF
>>29
>Template Methodパターンだと、実行時に移動アルゴリズムを
>変更したくなったときに面倒じゃないか?
フラグのOF/OFFの分岐でいいべ。パックマン程度だったらその方がずっとコード
が分かりやすい。移動パターンが何種類もあると言うんだったら別だが。

38 :名前は開発中のものです。:2006/08/13(日) 01:11:05 ID:o/UAG1nJ
ゲームプログラムでMediator使うの微妙じゃね?
オブジェクト同士が相互作用しまくりで
処理内容が多岐にわたるゲームの場合、
updateしたよあとよろしくね♪じゃMadiatorの仕事が多すぎる。

結局俺の場合、例えばシューティングで当たり判定をとるんだったら
自機インスタンスへのポインタを敵のクラスのメンバに持たせたり
自機インスタンスをグローバルにしちゃったりする。
よくないことはわかりつつも。何か良い方法はないものかね。

39 :38:2006/08/13(日) 02:36:16 ID:o/UAG1nJ
ん?もしかしたら俺は物凄く馬鹿な勘違いをしていたのかもしれん。
今までは、Mediatorクラスが持つ関数は
呼び出し側の参照を引数として取るupdateただひとつだけで、
updateは引数から得られる情報を元に適切な処理を選択し、
適切なオブジェクトに通知するのだと思っていた。が、
Mediatorに複数の関数を持たせて
呼び出す側が選択するというのもありなんだな。
例えば当たり判定処理のためのhitCheckとか。

タスクリストを持つクラスにMediatorを兼任させるのもありか。
ごちゃごちゃするが。

>>35
listのままでおk

40 :名前は開発中のものです。:2006/08/13(日) 08:56:01 ID:y5vatLvS
この板ですごい久しぶりの良スレ候補だ。

41 :名前は開発中のものです。:2006/08/13(日) 11:24:21 ID:vE5CRkDF
>>38
まぁゲームシステムにもよるだろうなぁ。自機が一機しかなければ
自機クラスにMediatorの仕事やらせてもまず大差ないだろうし。
弾のような飛び道具出すにしても、
自機の敵キャラクタのインスタンス配列をそのまま渡せば
そこまで複雑になるとも思えない。むしろこっちの方が楽そう。
マリオみたいに敵同士の当たり判定がある場合は、
Mediatorみたいなものは必須だと思うけど。

42 :名前は開発中のものです。:2006/08/15(火) 01:28:43 ID:mFMpUmTh
デザパタ話か…
昔、GraphicsクラスやらInputクラスやらを
シングルトンにしようとしたが、初期化するための引数が多いせいで
Graphics.getInstance()なんて簡潔な呼び出しをすることが
不可能だと気づいて泣いたぜ

43 :名前は開発中のものです。:2006/08/15(火) 01:53:25 ID:EK48DUhB
>>42
initializeメンバ関数を別途用意して最初の方で呼び出せばいいだけの話じゃ?

44 :名前は開発中のものです。:2006/08/15(火) 02:22:10 ID:mFMpUmTh
>>43
それやるくらいなら俺はシングルトンパターンを適用せずに
フィールドを全部staticにする
初回のgetInstance()呼び出しでコッソリ初期化、
表面上は初期化いらずな点がシングルトンの利点だと勝手に思っているから

45 :名前は開発中のものです。:2006/08/15(火) 03:30:20 ID:EPdRstT4
Monostateパターンか

46 :名前は開発中のものです。:2006/08/16(水) 12:54:24 ID:kC6PmX5a
Mediator処理関数の呼び出すべき順番が決まっているのに
呼び出し側のタスクがその順番で並んでいないときは発狂する。

47 :名前は開発中のものです。:2006/08/19(土) 01:00:05 ID:aLDfzS42
Mediatorを適用しているサンプルを見たことがない。
プレイヤーへのポインタを保持する敵タスク(リスト)ばかりだ。
ttp://d.hatena.ne.jp/kenmo/20051215#p1にMediatorの解説があるが
接触判定のような単純な通信にしか使えんな。これは。

48 :名前は開発中のものです。:2006/08/19(土) 10:25:32 ID:IzB67zRr
このスレでよく出てくるタスクって何の事?

49 :名前は開発中のものです。:2006/08/19(土) 10:59:20 ID:Br4d5o3I
>>48
タスクシステムでググると出てくる。GameDevPukiWikiにも載っている。
http://gamdev.org/w/?%5B%5B%A5%BF%A5%B9%A5%AF%A5%B7%A5%B9%A5%C6%A5%E0%5D%5D

50 :名前は開発中のものです。:2006/08/19(土) 12:03:47 ID:Ozyz6ud5
タスクシステムの考え方は海外ではあまり見ない和製概念だね
向こうではDDAやらエンジン単位でのアーキテクチャが主流なのかな

51 :名前は開発中のものです。:2006/08/19(土) 12:16:19 ID:IzB67zRr
タスクシステムって要はリストの事なの?

52 :名前は開発中のものです。:2006/08/19(土) 13:19:26 ID:Br4d5o3I
タスクコントロールブロックがリスト構造を成しているとは限らない。

53 :名前は開発中のものです。:2006/08/19(土) 14:40:17 ID:NMv1rX3b
オレはCompositeパターンを使ってTCBをTreeにしている。
こうすると走査が面倒ななるから、必要なTCBだけMediatorに登録。

54 :名前は開発中のものです。:2006/08/23(水) 17:59:02 ID:i8zrNBaj
シューティングゲームなどで、C++タスクシステムにおいて、
敵管理タスクが当たり判定や弾の狙い撃ちをするために、
自機タスクから座標などの情報を取得するにはどうすればいい?

55 :名前は開発中のものです。:2006/08/23(水) 20:30:16 ID:M0hCP3PA
今北お!

モデルの実装は普通にやればいいと思うんだけれども、
たとえば >>9 のパックマンでキャラ画像情報とかって
どこに持つ?

で、アルゴリズムとどうやって結びつける?

俺はなんかもう面倒くさくなって全部一緒になってんだよねー(最悪)

56 :名前は開発中のものです。:2006/08/23(水) 20:32:29 ID:M0hCP3PA
>>54
多分、自機情報がグローバルにあるんだと思うよ!

57 :名前は開発中のものです。:2006/08/23(水) 20:55:16 ID:Y+7SXF19
パックマンクラスかな

58 :名前は開発中のものです。:2006/08/23(水) 21:23:13 ID:PRMjREAH
つか、誰か>>50の解説を頼む。

59 :名前は開発中のものです。:2006/08/23(水) 21:28:31 ID:3o00L+nM
>>55
画像情報がビットマップなんかのことだったら殆ど別だな。
ゲーム総まとめクラスから
キャラの座標値、アニメーションインデックス値を吐かせて
それを画像クラスに投げてる。

60 :名前は開発中のものです。:2006/08/24(木) 00:46:53 ID:YfRhQBsC
【敵機(Enemyクラス)が自機(Playerクラス)の座標の取得する場合】
(GetXY()となっているが、XとYを別々に取ってきても構わない)

・そもそもクラスにまとめていない or 自機も敵機もごちゃ混ぜクラス。
 自機の座標の取得には苦労しないよ派。
・Playerのインスタンスplayerがグローバル。
 player.GetXY()で座標を取ってくるよ派。
・PlayerがSingleton。
 Player::Instance().GetXY()で座標を取ってくるよ派。
・PlayerがMonoState。
 player.GetXY()もしくはPlayer::GetXY()で座標を取ってくるよ派。
・Enemyクラスがplayerへのポインタを保持。
 player->GetXY()で座標を取ってくるよ派。
・enemyがMadiatorに自機の座標の取得を要求。
 Madiatorがplayerの座標を調べて返してくれるよ派。
・playerやenemyが属する統括クラス(GameとかTaskListとか)に
 enemyがアクセス可能。
 Game.(->)GetPlayer()->GetXY()で座標を取ってくるよ派。

61 :名前は開発中のものです。:2006/08/24(木) 20:19:35 ID:ioVHmuR2
>>59
キャラの座標やアニメーションインデックス自体は、
やっぱり>>9でいうCEnemyにあるんだよねぇ?
それを総まとめクラスが集約してるみたいな構造かなぁ。

その設計だと、ダーティ領域を消すための前回のスプライト位置は
画像クラスに持ってるんだろうか?

62 :名前は開発中のものです。:2006/08/25(金) 07:38:55 ID:hwdyVz4L
アニメーションインデックスは
CEnemyのメンバとして直接持つのではなく、
委譲関係にあるインデックス管理クラスが持った方がいいかな。
インデックス管理クラスはmap<String, list<POINT> >みたいな構造にして、
動作の名前を与えるとPOINT構造体を返してくれるというような。

63 :名前は開発中のものです。:2006/08/25(金) 11:50:36 ID:cXY4CALt
>>61
総まとめクラスにインデックス値を吐かせてるのは
それがフレーム管理もやってるから。
インデックス値はCEnemyには持たしていない。
毎回背景から再描画してるんで、
前回スプライト位置は保持していない。メンドイし。

64 :名前は開発中のものです。:2006/08/25(金) 14:31:51 ID:7Z0tsXKn
>>63
>総まとめクラスにインデックス値を吐かせてるのは
>それがフレーム管理もやっているから
いやそれ全然理由になっていないと思うぞ…。

65 :63:2006/08/25(金) 20:56:45 ID:cXY4CALt
あれ?自分で書いておいて訳わかんねw
作ったまとめクラスよく見たらフレーム管理はしてなくて、
1フレーム進めるメソッドがあるだけだった。
んで、そのメソッドを実行するたびに
0〜(アニメーション数-1)までくるくる回す
インデックス値のメンバがそこにあった。
数ヶ月前に書いたソースを思い浮かべながら書いたら
記憶があいまいで勘違いしてた。スマソ

66 :名前は開発中のものです。:2006/08/26(土) 02:58:51 ID:MLjkH/sO
>>65
それをやると、敵を生成したタイミングにかかわらず
同じ敵が同じ状況で常に同じモーションをとることになるな(行進みたいに)。
俺はモーションをバラにさせたいときは>>62みたいなクラスを敵クラスに持たせ、
あえて統一したいときはそれを敵リストクラスに持たせている。

67 :名前は開発中のものです。:2006/08/27(日) 01:28:02 ID:AkzK5166
簡単なことを難しくやる典型例みたいな…
やっぱしゲームには過度なオブジェクト指向は必要ないかなあ

68 :名前は開発中のものです。:2006/08/27(日) 01:36:32 ID:ksgBJOiI
3Dゲームはオブジェクト指向無しではやってられまへん。

69 :名前は開発中のものです。:2006/08/27(日) 01:58:03 ID:8IJYN4+M
>>67
このスレに書かれているようなクラス設計を
どんな規模のゲームにでも毎回採用している奴はいないだろう。
採用した方がむしろ簡単になったり、差し替えが楽になったり
するようなところに適用すればいい。
パックマンとかシューティングとかは説明例に利用されているだけだし。
ゲームに過度なオブジェクト指向は必要ないというのはちと早計。

70 :名前は開発中のものです。:2006/08/27(日) 09:16:10 ID:6AN46lHX


71 :名前は開発中のものです。:2006/08/27(日) 11:43:57 ID:1/1wdIdP
こんなスレが出来てたのか。

いわゆるタスクシステム的な、個々のオブジェクト同士の依存関係の記述は、
ここの考え方と同じ方針でやってる。
ttp://www.issei.org/blog/archives/000225.html

72 :63:2006/08/27(日) 12:10:26 ID:f+3tvpuV
>>66
まぁ漏れの場合はそこまで凝ったシューティングじゃなかったし。
もっと拘ると最終的にそれに近くなってくるだろうなぁ。

>>67
難しいか?このくらいじゃ慣れの問題でしょ。
大規模なゲーム作るとなると設計をちゃんとしなければ
取り返しがつかなくなって訳若布になる。
それに、そこで作ったコードを再利用するなら
他のゲームも自動的にオブジェクト志向なコードになる。

73 :名前は開発中のものです。:2006/08/27(日) 13:24:46 ID:DcPmG1mi
そこに時間という足かせとのバランスを考慮するんだろ

74 :名前は開発中のものです。:2006/08/27(日) 14:46:15 ID:Iv3Ktm5x
過度のオブジェクト指向はゲームじゃなくても要らないっしょ。
過度なんだから。

まぁ、でもパックマンに >>9 ぐらいの設計は全然アリだよね。
CEnemyを直接継承しちゃうかな。俺は。

75 :名前は開発中のものです。:2006/08/27(日) 20:51:21 ID:e75LZdTl
ゲーム固有のコード全てを持つクラス の名前ってどんな風に付けますか?

Game だと(他のタイトルのコードと)紛らわしいし、ゲームタイトルって選択もあるだろうけど
開発を始めたばかりの頃に気の訊いたタイトルを思いつけるとも限らないし・・・
参考までに聞かせてください

76 :名前は開発中のものです。:2006/08/27(日) 20:59:17 ID:91MNPNDq
ゲームのすべてのコードが含まれてるなら後で変更しても問題ないんじゃないの

77 :名前は開発中のものです。:2006/08/28(月) 06:10:31 ID:ylt7gNTk
たとえばJavaならeclipse様の力で名前なんかどうにでもできるんだが、
そういうツールがない場合、開発コード名をつける。

78 :名前は開発中のものです。:2006/08/29(火) 08:01:09 ID:ewOrOlMJ
>>75
namespaceで区切る。

79 :名前は開発中のものです。:2006/08/30(水) 08:47:32 ID:nhdG+7sO
良スレだと思うのだがなかなか伸びないな。
やはりこの板は設計論より実装論が先立ってしまう人が多いからだろうか…

80 :名前は開発中のものです。:2006/08/30(水) 10:33:46 ID:/npQLrEC
単に内容について来られる奴が予想以上にいない説。
スクリプタやプログラム初心者が多いこの板では
このスレでメインに置かれているC++自体がまず敷居高し。
加えてタスクシステムやデザインパターン等の前提知識が必要だし、
ある程度作り慣れた人でないと語られている手法の有用性がわからない。
っていうか>>2が端的にこのスレの性格を表している気がしなくもない。

81 :名前は開発中のものです。:2006/08/30(水) 10:42:16 ID:ywEU+7yH
イベント駆動型で作れないかな

82 :名前は開発中のものです。:2006/08/30(水) 11:31:13 ID:9Enygb8x
パズルゲームとかなら

83 :名前は開発中のものです。:2006/08/30(水) 19:00:19 ID:/p+hSpd6
むしろ糞スレ化せずに80以上のまともなレスがあるのが奇跡だよなぁ。

84 :名前は開発中のものです。:2006/08/30(水) 23:25:09 ID:YwiXGvRz
実装論先行型が多いと思う

デザインパターンって人に伝えるために作られたものだと思う
一人で作ってる分には必要ないんでない?

あとオブジェクト指向はホント必要、いやまじで、ないと軽く逝ける
どこまでやればオブジェクト指向ってのかは謎だけど

とりあえずデザインパターンとあまり関係ないんだが
クラスの作り方どうやってるか聞きたい
複雑な行動パターンをお手軽に実装できる方法とかない?


85 :名前は開発中のものです。:2006/08/30(水) 23:37:00 ID:zbf6UWXA
C++で、クラス関連の機能から触り始め
テンプレートの書き方やSTLライブラリまで一通り勉強したけど
デザインパターンにはまだ触れたことがない
今のところ、機能ごとに切り分けたクラスを作りためながら
自前のゲーム用ライブラリを構築するだけで満足してしまってる

86 :名前は開発中のものです。:2006/08/30(水) 23:42:43 ID:5F9omhv6
どうでもいいことを突っ込まずにはいられない
>85
>STLライブラリ
頭痛が痛いです

87 :名前は開発中のものです。:2006/08/31(木) 00:11:24 ID:HS89R3Gm
知ってるがな
どうでもいいことには突っ込まずにいてください

88 :名前は開発中のものです。:2006/08/31(木) 00:17:43 ID:RTC9z+se
プログラムを勉強し始めて間もなく
多くの人が感動したアルゴリズムと同じく、
綺麗なクラス設計を示したのがデザパタだ
みたいなことを誰か言ってたな。

89 :名前は開発中のものです。:2006/08/31(木) 00:47:27 ID:q0N5Gk6x
83が変なコトいうから微妙な空気が漂ってきた。

90 :名前は開発中のものです。:2006/08/31(木) 03:24:35 ID:LuxRambo
デザインパターンの意図については語る必要はない気がする。
こっちは利用する側なんだし。実際このスレではパターン名で疎通が取れているし
パターン自体も色々な使用例が挙げられていて役立っているからそれでいい。

>>84
>複雑な行動パターンをお手軽に実装できる方法とかない?
なんとなく、このスレでは扱わない具体的な実装面に踏み込む内容な気がする。
どちらにしろ具体例を挙げてくれないと意見しにくい。
行動パターンがコロコロ変わるというのであれば>>9の方法でいいんじゃないか?

91 :名前は開発中のものです。:2006/08/31(木) 17:27:49 ID:AP7414ou
こういうスレは、この板では貴重だと思う。
当たり判定のアルゴリズムはわかっても、
それぞれの物体の座標をどうやって取得するか等を語れるスレは少ないし。

92 :名前は開発中のものです。:2006/08/31(木) 18:34:51 ID:H1On9wAl
>>90
前にSTG作った時に敵の数を20以上作れと言われた
一つ一つ行動パターンを作っていくのがえらいめんどくさかった
既出ですまそ、そしてありがとうございます

93 :名前は開発中のものです。:2006/08/31(木) 19:32:51 ID:FYTUeEKw
「複雑な行動パターン」ってどういうもん?
キャラの状態が色々あってステートの変化の組み合わせが多い(格ゲー系にありがち)とか、
行動の流れが複雑でプログラムがめんどくさい(シューティングにありがち)とか、
カテゴリはいくらでもありそうだからなぁ

でも大抵はスクリプトを使えば割と面倒なタスク処理が解決すると思うので紹介
タスクを実装するのにvirtual Update() = 0;な関数を用意したクラスを使うのは皆よくやると思うのだが
キャラにとっては一連の流れ(=関数)を一々タイムスライスしてやらなきゃならんのは面倒だ。
そこでスクリプトを使うと結構その辺が簡略化されるよ
例えばシューティングゲームで360度回転しながら弾を撃つ処理を書くときとかが良い例だと思うのだが

class Hoge
{
 float m_Angle = 0;
 Update() {
  m_Angle += AngleVel;
  Fire(m_Angle);
  if( m_Angle >= 360.0f )
   Destroy( this );
 }
};
と書くよりは
HogeThread() {
 for( float Angle = 0; Angle < 360; Angle += AngleVel; ) {
  Fire(m_Angle);
  Wait(1);
 }
}
と書きたいわけだな。Wiat(1)みたいなのはスクリプトの得意技だ
>>9の例を使うと、class ScriptStrategyみたいな感じのクラスを作るのがいい感じ。

94 :名前は開発中のものです。:2006/08/31(木) 19:34:21 ID:FYTUeEKw
それにしてもひどい文法エラーだと自分でつくづく思った。

95 :名前は開発中のものです。:2006/08/31(木) 21:15:01 ID:XOYGLdi+
>>93
ゲームプログラムとしては前者のコードの方が自然だから
わざわざ後者にしたいという理由がわからない。

96 :名前は開発中のものです。:2006/08/31(木) 21:43:04 ID:WNbosGuA
IEnumerator<IAction> GetAction()
{
 for( float Angle = 0; Angle < 360; Angle += AngleVel; ) {
  yield return new FireAction(m_Angle);
 }
}

C#でこういうのどうだろ

97 :名前は開発中のものです。:2006/08/31(木) 21:52:59 ID:q0N5Gk6x
>>93の例は微妙に不適当な気がする。
”複雑な状態遷移をスクリプト(というよりこの場合fiber/coroutine)で処理した方が簡単”
というのは言えると思うが、
”毎フレームUpdateを呼ぶよりもHogeThreadを1回だけ起動する方法にしたい”
なんて思う人はごく稀だと思われる。

この場合、>>9のStrategyのサブクラスとしてScriptStrategyを定義して、
excuteが呼ばれるたびにコンテキストを復帰して起動する処理を作る方が自然。


98 :名前は開発中のものです。:2006/09/01(金) 00:30:03 ID:r4ifVKGE
>>95
そんなことは無いですよ。BulletMLはまさしく後者の方法の一種です。
わざわざこのためにpythonのマイクロスレッドを利用する人もいるくらい。

>>96
まさにその考え方です。
ただC#ではIteratorでしかyieldが使えないので…

>>97
なんか表現を誤った気がします。
結局はおっしゃるとおりコルーチンってことです。

99 :名前は開発中のものです。:2006/09/01(金) 22:44:26 ID:gcVCkYdV
人それぞれといわれかねない質問だが・・・、
衝突判定は何処で行う?
キャラが他のキャラクタと当たるかどうかを各々チェックする?
衝突クラスなるものがキャラと他のキャラとをチェックする?

100 :名前は開発中のものです。:2006/09/01(金) 23:18:48 ID:m70wFV1r
衝突判定の対象になるキャラを、障害物クラスに登録しておき、
キャラのメソッドで、判定用ベクトルを格納するクラスを生成し、
その判定ベクトルクラスを、障害物クラスに渡している。
障害物クラスで扱うデータは、
オリジナルだったり複数種のFVFだったりするので、
判定そのものはテンプレートにした。

101 :名前は開発中のものです。:2006/09/01(金) 23:37:56 ID:PZ94qqHg
5000個くらいのキャラの衝突を総当りでやってたらうざったいもんな。
キャラの最小サイズを1ピクセルになるようにマップを縮小したものを容易。
キャラを移動させたらその位置を塗り替えるが、その場所が既に塗り替えられてれば衝突、もしくは
詳細の衝突判定を行う。
クラスにするまでもないと思うが。


102 :名前は開発中のものです。:2006/09/01(金) 23:50:16 ID:KqJnfdNw
俺は衝突クラスを作るかな。
実装は>>101みたいな感じだけど4分木を使ってもっと大雑把にやる。
まあ実装に関してはこのスレの範囲外だけど。

103 :名前は開発中のものです。:2006/09/02(土) 18:17:30 ID:NT+ChiaN
衝突判定でよく話題になるダブルディスパッチだけれども
boost::variant使うと継承無しで実現できちゃうよ。
中身はswitch caseのコンパイル時自動生成してるだけだけど。
継承関係なしで仮想関数の真似事もできるんで、
たまには役に立つかもしれない。

104 :名前は開発中のものです。:2006/09/02(土) 18:26:27 ID:AcWLcw3K
GameObjectは型クラスの概念に近いことが多いから、
ある程度規模が大きくなると、コンパイル時のダブルディスパッチの確定だけじゃ追いつかなくなるんだよね…
UnrealEngineではスクリプトに完全に委譲してしまってるみたいだけど。

105 :名前は開発中のものです。:2006/09/02(土) 18:36:54 ID:NT+ChiaN
variant型なんだからもちろん実行時型識別してくれるよ。
具体的には型にid振ってswitch caseしてるだけ。
メモリアロケーションも発生しないからなかなか優秀。
ただオブジェクトサイズが最大のものに揃っちゃうけど。

106 :名前は開発中のものです。:2006/09/02(土) 18:40:42 ID:NT+ChiaN
こんな感じね。↓

#include <boost/variant.hpp>

using namespace boost;

class visitor : public static_visitor<> {
public:
void operator () (int n, int m) const {}
void operator () (char n, char m) const {}
void operator () (char n, int m) const {}
void operator () (int n, char m) const {}
};

・・・・
variant<int, char> v0, v1;
v0 = int(2);
v1 = char(3);
apply_visitor(visitor(), v0, v1);
v0 = char(2);
v1 = char(3);
apply_visitor(visitor(), v0, v1);

107 :名前は開発中のものです。:2006/09/02(土) 21:49:46 ID:AcWLcw3K
>>105
いや、突き詰めていくと、同じ型であってもゲーム上で異なる意味を持つ場合がよくあって、
そういう場合は(言語としての)型でのディスパッチだけでは不十分で、
結局、ゲームにあわせたIDなり名前なりで自前のルーチンを組むことになるって話。

特にRTSやFPSみたく、プログラマは基本的な構造とツールを提供するだけで
後はデザイナーの仕事、のように分業されてるゲームではそうなりやすいでしょ。

って書いてて気づいたけど型クラスじゃなくて型オブジェクトだったよ(´・ω・`)スマソ。

108 :名前は開発中のものです。:2006/09/03(日) 02:35:53 ID:zkit7pB+
それは単に振る舞いを型まで落としきれてないだけでは。
仮に振る舞いが外部設定可能だったとしても
型をパラメータ化したファクトリ作れば良いし。

109 :名前は開発中のものです。:2006/09/03(日) 02:45:46 ID:zkit7pB+
ああ、”ゲームオブジェクト”のディスパッチでは
足りない、ということであれば同意。
上のは当たり判定オブジェクトを別に作ってそっちで
ディスパッチする前提で話してた。

110 :名前は開発中のものです。:2006/09/03(日) 20:53:10 ID:IzfZGbvV
てかここまでくるとスレ違いじゃね?

111 :名前は開発中のものです。:2006/09/03(日) 21:18:48 ID:2Y2SZ/cc
>>110
何故?

112 :名前は開発中のものです。:2006/09/03(日) 23:09:12 ID:H5xQl2Ix
>>109
そう、そういう意味ですた。
パックマンやテトリスみたく、型とオブジェクトの振る舞いが1:1で対応するようなゲームであれば
boost::variantやLokiのStaticDispatcherで事足りるし、その方が高速なんだけど
ツールでカスタマイズ可能なオブジェクトを導入したとたんに破綻しちゃうんだよね…
普通はどうするもんなんでしょうか。

113 :名前は開発中のものです。:2006/09/04(月) 00:35:37 ID:Q7Y7fGRp
>>110
話題が無いよりマシ

>>112
>>108>>109にも書いてあるけどStrategyパターン使ったら?

114 :名前は開発中のものです。:2006/09/04(月) 22:45:10 ID:rb/d93oY
衝突は悩みますよねー。
まぁ、衝突判定のためのクラスを作って、そこに対象をごっそり
addしていくような感じですかね。わたしは。

115 :名前は開発中のものです。:2006/09/04(月) 23:02:41 ID:IU7YOKU2
2Dの衝突判定の話と3Dの衝突判定の話が混在しているから困るw

116 :名前は開発中のものです。:2006/09/04(月) 23:16:45 ID:FM5ShwwG
次元1つ違うだけジャン

117 :名前は開発中のものです。:2006/09/04(月) 23:41:18 ID:sQ13V/oj
判定アルゴリズムを語っているわけではあるまいし、問題ないだろう。

118 :名前は開発中のものです。:2006/09/05(火) 00:52:09 ID:ZZN1keOu
さすがに>>101のやり方は3Dじゃやらんだろww

119 :名前は開発中のものです。:2006/09/05(火) 01:15:43 ID:XCG3Ame9
画像だとめんどいけど多次元配列にすればいけるんじゃね?

120 :名前は開発中のものです。:2006/09/05(火) 01:32:48 ID:N2PWUf7J
>>119
普通はAABBのツリー構造にするけどな

121 :名前は開発中のものです。:2006/09/05(火) 04:06:58 ID:9I8P67h+
グリッドでやるのは現実的じゃないけど、オクツリーなら。

122 :名前は開発中のものです。:2006/09/05(火) 05:52:03 ID:b0Le55Md
こういう話題も一応『データ構造』の内に入るのかな?
レンジ広めな良スレだな。

123 :名前は開発中のものです。:2006/09/05(火) 07:11:57 ID:WVxlLvIu
まとめ
・形状衝突判定とゲームオブジェクト衝突判定の話が混在してて紛らわしいお
・VisitorパターンはAcceptor側の個数が暴発するときには使いづらいお
・挙動をStrategy化すればAcceptorが暴発しにくくなるお
・次元を問わずグリッドよりツリーのほうがお勧めだお

124 :名前は開発中のものです。:2006/09/08(金) 23:55:09 ID:NaDeRAxZ
群体を制御するプログラムのいい案ない?
複数の個体で整列したり陣形を作るっていうのが目標

どっちかというとAIの分野に入ると思うけど
そこまで複雑な物じゃなくてもいいかなと思ってる

125 :名前は開発中のものです。:2006/09/09(土) 00:04:25 ID:htHhZzlR
チーム全体の行動を担うダミーエージェントを用意して、
そいつが全エージェントの操作を行うというのが楽なんじゃね?
昔からある多間接キャラとかはこういうタイプなんだろか

個々のエージェントが周囲の状態を見て次の移動地点を決めたりするのは
まさしくAIって感じだが果てしなく重くなりそう

126 :名前は開発中のものです。:2006/09/09(土) 00:27:32 ID:8XOJrFUy
>>125
> 個々のエージェントが周囲の状態を見て次の移動地点を決めたりするのは
> まさしくAIって感じだが果てしなく重くなりそう
そうでもない。
今のクラウドシミュレーションの基礎になってるレイノルズの方法では
3つの単純な操作を各個体に適用するだけでリアルな挙動を作り出せる。

これに、基準になる目標点を個々に与えたり、パラメータを調節・追加することで整列や陣形も表現できる。
といっても完璧に意図した陣形にしたければ、予め動きを指定しておくしかないけど。

127 :名前は開発中のものです。:2006/09/09(土) 03:06:35 ID:KrPaatUc
boidっ言ってちょ。1行目だけ読んで「レイノルズって誰だ?」とか思っちゃった。
ツリー的な構造にしてセパレーション以外の適用範囲を限定したりすると、
複数の集団が扱えるし、(影響力の強くした)ツリーの親で操作できて手軽。

128 :124:2006/09/09(土) 11:31:36 ID:c7q33UAv
まとめると
チーム全体の指揮をするエージェントを作る
個々に単純な操作や状況判断する機能をつける
ツリー構造で処理する

思い出したんだがそういえば鳥の群れのシュミレーションとか参考になりそうだと思った
ttp://www.red3d.com/cwr/boids/

>>125>>126のやり方を組み合わせられれば理想的なプログラムになりそう

129 :名前は開発中のものです。:2006/09/09(土) 13:29:03 ID:QcPvLvjH
階層ステートマシーンってどんなものか知ってる人いる?

130 :名前は開発中のものです。:2006/09/10(日) 00:43:16 ID:20rok1qS
>>129
従来のステートマシン(全てのステートが完全に等価)に
クラスなりパッケージ化で階層を加えて
オブジェクト指向との親和性を高めた物って認識をしてたけど、違うのかな?

131 :名前は開発中のものです。:2006/09/10(日) 06:09:51 ID:lBlbiG31
>>128
リンク先の動きが魚っぽい。

132 :名前は開発中のものです。:2006/09/13(水) 09:43:56 ID:NFAfFOse
魚に吹いたw

133 :名前は開発中のものです。:2006/09/17(日) 13:13:30 ID:w8QCz84O
2chからリンクされていたから何かと思ったら、こういう話かw 一安心。

>>129
ふつーのステートマシンだと全ての状態が対等なので、状態×入力に
比例して記述が増えていく。似た状態をまとめて、必要な記述量を減ら
そうってのが階層ステートマシン。

たとえば RPG の主人公キャラなら、まず「生きてる」「死んでる」で状態を
分けて、さらに「生きてる」の中に「通常」「混乱」「スリープ」とか入れ子に
して挙動が異なる部分だけ書く。

>>130
> オブジェクト指向との親和性を高めた物って認識をしてたけど、違うのかな?
直接は関係ないです。OOPL を使ったほうが書きやすいかな、って程度。

むかし、ゲーム屋さんやってたときに作った代物があるので、どーぞ。
ttp://www.issei.org/diary/?20040208#08

参考書
ttp://www.amazon.co.jp/exec/obidos/ASIN/1578201101

134 :名前は開発中のものです。:2006/09/17(日) 13:24:01 ID:yvndUkUn
strategyのstrategyみたいなもんか。

135 :名前は開発中のものです。:2006/09/22(金) 22:18:45 ID:u76SSGNK
質問です。

まず、動的にメモリ上に作成されたオブジェクト、AとBがあります。
ある時、オブジェクトBはオブジェクトAへの参照を保持したとします。
しかしその後、オブジェクトAは消失してしまいます。

こういった場合に、オブジェクトBの保持していたオブジェクトAへの参照が
無効になったことが分かる、良い参照構造がありましたら教えてください。
スマートポインタをちょっと調べてみましたが、あれってこういう場合に使うものではないですよね?(むしろ逆のような感じ)

言語はC++です。

136 :名前は開発中のものです。:2006/09/22(金) 22:33:30 ID:zpdtl+m6
>>135
boost 使うなら shared_ptr と weak_ptr 組み合わせて使う。

或いは、非参照オブジェクトに

bool isTerminated() const;

みたいなメンバ変数を持たせて、参照側はスマートポインタで保持。使う前に

if (p->isTerminated())
 p = NULL;

みたいなチェックを入れる。私は intrusive_ptr 好き人間なので、後者で統一
してました。

137 :名前は開発中のものです。:2006/09/23(土) 10:55:14 ID:gkZ8TjvK
>>135
インスタンスのポインタのポインタ持たせておけばおk。
Aのインスタンス開放時は必ずぬるぽを指定する。

138 :名前は開発中のものです。:2006/09/23(土) 14:31:03 ID:HUIkr9ZU
>>136
weak_ptr使ってみました。これは良いですね。
セットされていたshared_ptrが消失すると以降のlock()が無効になる。
これで私の希望は叶ったように思います。
ただ・・これって内部ではどのような処理が行われているのでしょうか?
ソースを読んでみようかと思いましたが・・私にはちょっと難しかったです。
どなたか、簡単に解説していただけませんでしょうか?

intrusive_ptrについては、よく分かりませんでした。

>>137
Bがインスタンスのポインタのポインタを持つとして、
その「インスタンスのポインタ」にあたるデータは
Aが持つのでしょうか?それとも違う者が持つ?または誰も所有しないのでしょうか?
ちょっと具体的なイメージが沸きませんでした。
宜しければサンプルコードみたいなものを書いて頂けるとありがたいです。

139 :名前は開発中のものです。:2006/09/23(土) 15:44:06 ID:LShRrPtb
>>138
# boostは使ってないけど、weak_ptrの実装に興味あったのでソース見てみた。
# 間違ってたらごめんね。

intrusive_ptrは参照されるオブジェクトに参照カウンタの仕組みが備わっている場合に
使えるスマートポインタ。shared_ptrは参照カウンタをヒープに確保してて何にでも使える
汎用性がある代わりにオーバーヘッドがありゲーム用ならintrusive_ptrが好まれるという
ことだと思われる。

weak_ptrはそのヒープに確保される参照カウンタ(オブジェト)自身の参照カウンタを
上げ下げするもので、weak_ptrが全部消えるとその参照カウンタオブジェクトが
消えるという仕組みのようだね。

# detail/sp_counted_base_w32.hpp
class sp_counted_base
{
long use_count_; // #shared
long weak_count_; // #weak + (#shared != 0)

virtual void destroy() // nothrow
{
delete this;
}
void weak_release() // nothrow
{
if( BOOST_INTERLOCKED_DECREMENT( &weak_count_ ) == 0 )
{
destroy();
}
}
};


140 :名前は開発中のものです。:2006/09/23(土) 20:21:11 ID:gkZ8TjvK
>>138
こんな感じだな。インスタンスのポインタは別に誰が持ってても良い。
っつかポインタのポインタ持ってる時点でそれと同義だし。

class clsA;
class clsB;

class clsB
{
int val;
public:
clsB(int v){val=v;}
int getVal(){return val;}
};

class clsA
{
clsB **pb;
public:
clsA(clsB **b)
{pb=b;}

int getVal()
{
if((*pb))
{return (*pb)->getVal();}
else
{return -1;}
}
};


141 :138:2006/09/23(土) 20:22:09 ID:gkZ8TjvK
改行が多いって怒られた。

int _tmain(int argc, _TCHAR* argv[])
{
clsA *a;
clsB *b;
int ret;

b=new clsB(256);
a=new clsA(&b);
delete b;
b=NULL;

ret=a->getVal(); //ret==-1
return 0;
}

142 :140=141:2006/09/23(土) 20:22:57 ID:gkZ8TjvK
名前ミスった。気にせんでくれ。

143 :名前は開発中のものです。:2006/09/25(月) 21:33:59 ID:hvNCBo59
ここで挙げられたパターンや何やらを使っているような、
小規模でわかりやすいサンプルってありますかね?
シューティングを作ろうとしているのですが、設計で悩むことが多くて、
参考になるものが欲しくなってきたので、何かあればよろしくお願いします。

144 :名前は開発中のものです。:2006/10/10(火) 21:23:54 ID:yCqIkWyw
>>143
シューティング製作スレから.
ただし,漏れはまだ読んでないので内容については保証できんが.
ttp://ime.nu/www.amazon.co.jp/exec/obidos/ASIN/4797337214/

145 :名前は開発中のものです。:2006/10/31(火) 10:38:39 ID:xPxE7qYC


146 :名前は開発中のものです。:2006/11/04(土) 23:26:00 ID:fX21zZRx
タスクシステムって本当に有効なのか?
逆にプログラミングが煩雑になりそうな気がするんだが。

147 :名前は開発中のものです。:2006/11/04(土) 23:30:01 ID:gABtDaTi
>>146
何度か挙がってるネタだな。まず「タスクシステム」を定義しないと、
いつもどおりグダグダになるだろう。

148 :名前は開発中のものです。:2006/11/04(土) 23:49:54 ID:fX21zZRx
>>147
タスクシステムというのは、
処理関数とワークエリアがセットになったタスクがリスト構造になっていて、
順番にタスクの処理関数を実行していく仕組みだと思ってる。違うかもしれんが。
あるタスクが、ほかのタスクの保持するデータを参照するのが難しそうだ。

149 :名前は開発中のものです。:2006/11/05(日) 01:52:09 ID:SWu+bHZ4
>>148
関数とワークエリアがセットって言ったら仮想関数使えばいいだけの話。
あとは抽象クラスへのポインタをコンテナに保持すればできあがり。
システムって名付けるほどのもんでもないよな。

そこで済ませておけばいいものを、なんでもかんでもそのリストを
使ってやろうとすると、バグの温床となる「タスクシステム」ができあがるんじゃないか
と思っている。

150 :名前は開発中のものです。:2006/11/05(日) 02:16:36 ID:luPotGyi
実際C++だと必要ないよ。

151 :名前は開発中のものです。:2006/11/05(日) 09:28:27 ID:x/qHNT/o
>150
そうでもない。組み込み方面からもたらされたと思われる非プリエンプティブな
スレッドみたいなもうちょっと複雑なものとするなら、C++のみでは無理、
アセンブラが必要。WindowsならCreateFiberを使えるが、NT系で
しか使えない。

これからマルチコアが当たり前になると、スレッドをタスクと名づける人が増える
かもね、おおややっこしい。

152 :名前は開発中のものです。:2006/11/05(日) 09:43:30 ID:wi810l51
>>151
147の発言を地でいってるな。

153 :名前は開発中のものです。:2006/11/05(日) 14:05:29 ID:zA+hRC02
>>151
そういう意味のタスクじゃなくて

154 :名前は開発中のものです。:2006/11/07(火) 04:30:19 ID:grfbgSgu
初心者だがレスさせてくろ
タスクシステムはビデオ屋でいうポストレンタルシステムではないでしょうか
ゲームプログラムにおいてはリアルタイム戦略ゲームのAIに有効かと
例えば自立スレッド型のユニット(目的地を指定すれば、勝手に動いてくれる)をA地点に移動したのち、B地点に移動させるAIを組もうとしたときなど。
ユニットのスレッドが行動リストをもっていて、AIはぼんぼんリストに行動をaddしていけばいい
ユニットのスレッドはリストの下から行動を処理する。

このシステムがないとAIはユニットがA地点に到着した情報を取得し、
その後でB地点に池という命令を出さなければならないのでAIの手間が非常にかかる  おやすみなさい
  

155 :名前は開発中のものです。:2006/11/07(火) 10:26:39 ID:vi/Nuttr
>>154
それは >>148 の言うようなタスクシステムとは全然違う。
コマンドのキューと言えば十分。システムなんて呼ぶほどのものでもない。

「タスクシステム」の共通な定義が無いのが
一番の問題なのかもしれないと思った。
俺様解釈が多すぎていまさら定義も難しい。

156 :名前は開発中のものです。:2006/11/07(火) 10:45:17 ID:FxrEUOug
少なくともこのスレでのタスクシステムの共通定義は
>>148でいいんじゃないの?
今までずっとそれ前提で話が進められていたし、
そうでないと思っているのは的外れな>>154だけだと思うんだが。
タスクに親子関係持たせるとか優先度がどうだとかいった細かい部分は
その都度最適なものを選べばよし。

157 :名前は開発中のものです。:2006/11/07(火) 19:23:55 ID:qUpAvALP
Cでリスト使ってて、
C++に移行したら「それタスクシステムだよ」って言われた。
どうすればいいでしょう?

158 :名前は開発中のものです。:2006/11/07(火) 21:40:27 ID:3jPQsnxn
もうすこしkwsk

159 :名前は開発中のものです。:2006/11/08(水) 10:10:54 ID:U+HCvDbD
>>157
そうだよ。って答えれば解決。

160 :名前は開発中のものです。:2006/11/10(金) 11:57:52 ID:bWKjGfw+
ところで
http://d.hatena.ne.jp/kataho/20061013
ここのブログのこの問題といてみない?

161 :160:2006/11/10(金) 11:58:41 ID:bWKjGfw+
すまね、上げちまった

162 :名前は開発中のものです。:2006/11/10(金) 13:40:25 ID:0fi4/IIn
この板にしては珍しく良スレだな

163 :名前は開発中のものです。:2006/11/10(金) 21:25:10 ID:ZkgdRmE9
>>160
>koei.co.jp scei.co.jp square-enix.co.jp みてるんだったら会社いれてよ!!!!!!

お題とは関係ないがこの辺にワロタw
proxyぐらい使いましょうね、大手の皆さんw

164 :名前は開発中のものです。:2006/11/10(金) 22:26:18 ID:HTGezavx
>>163
別に問題ないと思うけど。さすがに社内サーバのアドレスを referer で飛ばしてくるのは
どうかと思うが>k社

165 :名前は開発中のものです。:2006/11/11(土) 01:08:30 ID:YsMNBgEw
自意識過剰

166 :名前は開発中のものです。:2006/11/12(日) 00:41:12 ID:uTWo+6kj
んで問題はとかねーの?

167 :名前は開発中のものです。:2006/11/12(日) 01:35:58 ID:R+1O/KH4
>>166
マジメに考えるほどのもんじゃない気がするが。

メモリの断片化や使用量見積もりを考えると、全オブジェクトを必要最小限の寿命で
確保・解放なんてせずに、シーン毎に必要なファイルぶち込んだアーカイブ作って
終わりだし。

168 :名前は開発中のものです。:2006/11/16(木) 13:28:43 ID:S/Ecbdk+
コーエーといえば寝るおもしろす事件だなw

169 :名前は開発中のものです。:2006/11/16(木) 14:51:20 ID:fgcxjfqh
>>167
いつ何時どういう顔でどういう武器を持ったアバターが登場するかわからない
MMOとかだとシーンとか生ぬるいこといってられないんじゃない?

170 :名前は開発中のものです。:2006/11/18(土) 00:38:40 ID:hjek6YSO
>>169
組み合わせが分からないなら、ワーストケースでも対応できるようにする必要があるから、
賢いメモリ管理はしない方が良いと思うが。

171 :名前は開発中のものです。:2006/11/18(土) 00:45:51 ID:Blaci8UD
10000とか決めうちで適当にアバター(?)放り込む領域とっときゃい〜じゃん。
クライアントで10000人同時表示とかどうせ無理だからw
なんかが湧いたとしても、
射程外の見かけ小さく見えるアバターから削除しちまえばOK。

172 :名前は開発中のものです。:2006/11/18(土) 18:42:03 ID:uDXwDRk4
>> 171
その領域のどこに確保されたのかを示すハンドルやポインタはどうすんのよ。

173 :名前は開発中のものです。:2006/11/18(土) 19:28:39 ID:GUEcKJwf
スケーラビリティはガン無視がゲームにおけるデータ構造・クラス設計の常識?

174 :名前は開発中のものです。:2006/11/19(日) 04:21:52 ID:qRasGZX0
コンシューマならそれでも良いと思うけど、
昨今のPCゲーム開発であればスケーラビリティは必須では?
なんせ環境が数倍以上違うことだってあるからね。

175 :名前は開発中のものです。:2006/11/19(日) 06:35:18 ID:2miANHZG
> その領域のどこに確保されたのかを示すハンドルやポインタはどうすんのよ。
領域が決めうちでも決めうちでなくても発生する問題。

> スケーラビリティ
MMOなんだから、クライアントの更新でスケーラビリティを代替すればいい。
逆にPCの優劣で、プレイヤー間に格差が出るほうが問題と言えば問題。

176 :名前は開発中のものです。:2006/11/19(日) 09:18:23 ID:GnePFvEb
んで問題はとかねーの?

177 :名前は開発中のものです。:2006/11/19(日) 10:07:08 ID:P05vv5BZ
あれは、クラスデザインで対応すべき問題ではない、っつーのが答え
だろうな。

178 :名前は開発中のものです。:2006/11/19(日) 15:53:33 ID:3G1y/i2K
>> 175
だから、それを採用してもその問題が残るんだろ?
この問題の本質はそこだろ。どうやってデータへのアクセスを共有させんだ?

179 :名前は開発中のものです。:2006/11/19(日) 16:36:03 ID:2miANHZG
いや、エンジン書いてもそれはゲームじゃないからw
さっさとゲーム上の具体的なシーンについて見積もりを建てなさい。
領域なんて初期化時に必要な領域全部取ってしまえば問題無い。

180 :名前は開発中のものです。:2006/11/19(日) 16:54:45 ID:3G1y/i2K
>> 179
件のサイトってMMORPG作ってるわけで、
MMORPG開発を前提にした問題を出してるんだがなあ。
シーンなんて簡単なもんじゃ見積もれないって。

181 :名前は開発中のものです。:2006/11/19(日) 17:17:03 ID:2miANHZG
↓↓↓ここから見積もれる/見積もれないの一点だけで100年戦争↓↓↓

182 :名前は開発中のものです。:2006/11/19(日) 20:33:12 ID:GnePFvEb
なんか虎をつかまえてほしいなら虎を屏風からだしてくれみたいな回答だな
あきれた

183 :名前は開発中のものです。:2006/11/20(月) 01:22:30 ID:SHLy4x4v
>>180
URL貼った上で「件のサイト」を持ち出すのは、
あまり良くないと思うのだが…

184 :名前は開発中のものです。:2007/01/14(日) 05:03:57 ID:gu/ia/06
良スレあげ

185 :名前は開発中のものです。:2007/01/19(金) 02:34:32 ID:RsBU2cJ/
シーン・・・
昔すべてのシーンはスタックのみで再現可能と思ってた時が俺にも有りました。

実際大半はOKだけど、相互に行き来できるような仕組みを作りたい場合
別の方法をとらないといけないし、平行して動かす場合や
一部をストップさせたいときはいっそシーンクラスじゃなく
スレッドで動くクラスの方が良いと思えてきました。

まだ研究中。

186 :名前は開発中のものです。:2007/01/19(金) 13:33:30 ID:GdZe8cga
俺はそれは兄弟関係をコンポジットにして解決しとるよ

187 :名前は開発中のものです。:2007/01/19(金) 14:48:25 ID:RsBU2cJ/
コンポジットパターンですか?
なるほど。

188 :名前は開発中のものです。:2007/01/27(土) 00:03:58 ID:Mwc3VMrB
良スレ発見。

皆様のお知恵をお借りしたい。

効果音、BGM、描画エンジンなどの管理オブジェクト(コンテキストっていうのか?)をどうやって、
キャラクターなどから参照させるかということについてです。

キャラのオブジェクト生成時に、必要なものだけ渡してやるのがベストなんでしょうか?

今は、全部持ったGameクラスっつーのを作って、そのインスタンスのローカル変数一個を
どこからでも参照できるようにして、
各キャラクターから参照できるようにしているんだが、
今の流行的に、ローカル変数がイヤンなので、
なんとかしてやりたいのです。

ABAさんのソースとか見ると、生成時に引数で渡しているんだけど、
うちのDelphiだと、各ユニット間の循環参照問題を回避できなくて真似できないんだよね・・・。

189 :名前は開発中のものです。:2007/01/27(土) 00:27:08 ID:GLW5syD3
ローカル変数?グローバル変数だよね。
その方法がまあ無理なくやれると思う。

グローバル変数がどうしても嫌なら
インターフェイス宣言を使えば、循環参照は回避できるよ。


190 :名前は開発中のものです。:2007/01/27(土) 00:46:55 ID:Mwc3VMrB
ごめん。グローバル変数です。
インターフェースか、Delphiのインターフェースって普通じゃないからなあ。

過去レスに出てた↓こちらのCtxってのが参考になるかもしれんけど。

或曰: お仕事
http://www.issei.org/blog/archives/000225.html


191 :名前は開発中のものです。:2007/01/27(土) 01:29:23 ID:lX9/hWgh
音はコンテクストとは違うのでは?リソース?
そのインスタンスの性質そのものなんだからバリバリ依存してていい
描画デバイスはそれ自体のステートがあるんで外からもらう必要があるだろうけど
別にグローバル変数で問題ないでしょう?
まあ描画するときにだけ引数でもらうように改変するのを無理して止める気はないけど

http://www.issei.org/blog/archives/000225.html
おもしろいなーfacade+visitorかぁ

192 :名前は開発中のものです。:2007/01/27(土) 05:01:28 ID:Cu/waNhi
サウンドみたいなものはモロにシングルトンにしてしまって
CSoundManager::GetInstance().Play( FX_HOGE );
こんなんでよいのでは

193 :名前は開発中のものです。:2007/01/27(土) 14:40:32 ID:lX9/hWgh
http://www.issei.org/blog/archives/000225.html
何か違和感があったので、寝ながら考えたんだけど
こいつの問題はゲームエンティティのクラスとctxのインターフェイスが1対1になってるとこかな。
まったく同じ汎用的なインターフェイスを複数のエンティティへ公開したいとしても
いちいち別の実装とインターフェイスを設けなくてはならなくなる。
意味のない制約を守るために重複コードができてしまう。

194 :名前は開発中のものです。:2007/01/27(土) 15:41:16 ID:lX9/hWgh
それにゲームエンティティクラスが増えて、継承の階層とかができても
ctxの実装は全部の名前に_ctxつけたインターフェイスを全部同時に多重継承するんだろか?

ctxにmixinするインタフェイスはゲームエンティティのクラス群の構造に依存しないで
区分けそのものに対する名前をつけてやる方がきれい、というか合理的に思う。
例えばとにかく弾をつくるインタフェイスを公開するctxインターフェイスならICtxShootとか。



195 :issei:2007/01/27(土) 22:48:39 ID:+PYaC1IQ
>>193
> まったく同じ汎用的なインターフェイスを複数のエンティティへ公開したいとしても
> いちいち別の実装とインターフェイスを設けなくてはならなくなる。
そうですね。

ただ、純粋仮想関数のプロトタイプが同じなら実装は一つで済むから、ヘッダ
ファイルをメンテするのが多少面倒って程度です。

struct ICtxEnemy { virtual void createShot() = 0; };
struct ICtxField { virtual void createShot() = 0; };
class Manager : public ICtxEnemy, public ICtxField { virtual void createShot(); };
// これで実装は両方に提供できる

このスキーム使って仕事で RPG のリアルタイム戦闘を作ってたんだけど、面倒で
手に負えないって状況には至らなかった。むしろインターフェースごとに公開する
関数が限定されていたから、仕様変更時にチェックが短期間で済んだ感じ。細かい
数字を残してないから、具体的に何パーセント改善とは言えないけどさ。

汎用的なインターフェースをどうするかってのは悩みどころだけど、やりたければ
sturct ICtxEnemy { virtual ICtxCommon& getCommonCtx() = 0; };
とかかなぁ。私は汎用インターフェースは結局作らずシングルトンで済ませちゃった
けど。

196 :名前は開発中のものです。:2007/01/27(土) 22:53:18 ID:FT2+QYPW
>188
個別にオブジェクトのアドレスを渡した場合、パラメータの個数が膨大になるのと、
きれいにまとめないとかなり手間がかかるね。

シングルトンで実装して、グローバルアクセスがよいのではとおもう。



197 :名前は開発中のものです。:2007/01/28(日) 01:11:39 ID:aVNVY6/P
>>issei(誰?w)
>// これで実装は両方に提供できる
確かにそうだね。書いてみてから気がついた。
具体的に書くコードの量とかの増減をあげつらう批判をしたいわけじゃないだホントは

また寝ながら考えたんだけど、要はこれはエンティティクラスの主要なメソッドを使うには
このctxインターフェイスを実装しているオブジェクトをなんとかして用意してください。
というエンティティクラスからの表明が主題で、managerが全部を継承して実装するというのは、
たまたま今回採用されたやりかたに過ぎない、別にどうでもいい部分なんだね。

エンティティクラスが継承ツリーをつくるようなときは最上位のクラスのctxに
下位層のクラスが使おうとする純粋仮想関数も書き加えてかなきゃいかんね。
つまり最上位のオブジェクトを以って、主要メソッドを実行しても、
その下位の継承したクラスの機能追加されたものが呼ばれる可能性があるわけなので。

なんで俺が日記の作者も言ってない手法の使い方をまとめてんだ…

ぜんぜん関係ないけどcontextってのはあんまり実態にそぐわない名前だと思うなぁ。分かるけど。
relianceとかdependencyとかのがいいような気がする。

198 :issei:2007/01/28(日) 01:38:40 ID:ViuHLna9
>>197
> >>issei(誰?w)
日記の人です。

> また寝ながら考えたんだけど、要はこれはエンティティクラスの主要なメソッドを使うには
> このctxインターフェイスを実装しているオブジェクトをなんとかして用意してください。
そうそう。

本当のマネージャとは別に、エンティティの単体テスト用とかデバッグ用に ICtx***
インターフェースを実装した別のマネージャーも作ってました。

確か別のプログラマがエフェクト用の対話型エディタを作ってたんだけど、そこで
デザイナからキャラクタにエフェクト乗せて見たいとリクエストがあって、エフェクト
エディタにキャラクタ用のコンテクスト実装してたんじゃなかったかな。もちろん、
大半の仮想関数はダミー(ヒット判定なんかの関数は、常にヒットしないと返す
だけ)だけど。

199 :名前は開発中のものです。:2007/01/28(日) 19:27:03 ID:aVNVY6/P
風呂はいりながら考えたんだけど
ようは移植用区画、エンティティクラス、実装を委譲したい関数群、
それぞれをシステム内で1対1対1。ひとまとめにしたいわけだ。それはわかる。
だが無駄に暗黙的な命名の制約を持ち込むvisitorインターフェイスには反対。
contextというが、それらが文脈として差異を持たされるのは結局はプロジェクト全体で複数作られる
実行単位ごとなわけだ。それに対してvisitor風に関数レベルで型への依存を表明するのは
適当だとは思えない。何がどのレベルで変わるのかがきちんと示せてるのがいいコードっすよね。
ついでに実装をまとめるだけが目的の節操のないmixinも反対だ。

俺はこうする。

class Player
{
public:
void exec() { CreateShoot(); }
void Method0();
private:
static void CreateShoot(); // どこか他のコンパイル単位で定義してやる
};

どこか他のシステムへもっていってもstatic関数を定義した.cppの方だけ取り替えれば移植が完了する。

200 :名前は開発中のものです。:2007/01/31(水) 00:35:16 ID:NKCnpIjT
クラス名・変数名に迷ったら書き込むスレ。Part9
http://pc10.2ch.net/test/read.cgi/tech/1168356029/113-132
から誘導されてきました。

・こんな構造の名前はなにがいいですか?
・タスクっぽいですねー
・擬似マルチタスクっぽいかも?
・スタック使え!
・え?スタック?
・segregated storage使え。
・boostのpool?

まあ、そんな感じで、ゲーム向けのデータ構造をどうするかって話になりました。

201 :名前は開発中のものです。:2007/01/31(水) 00:44:13 ID:YqKTmdjS
>>200
答えでてんじゃん。
ここで何が聞きたいの?

202 :名前は開発中のものです。:2007/01/31(水) 00:49:48 ID:jNUdiQRe
フラグ立ててるだけなのがなー。
削除と同時に最後尾のデータをコピーしちまえ。

203 :名前は開発中のものです。:2007/01/31(水) 01:00:05 ID:8/b3tbHY
>>200
そのアルゴリズムのどこが高速なのか本当に分からない。
フラグを立てて何に使うの?

204 :名前は開発中のものです。:2007/01/31(水) 01:08:05 ID:kxHbC4YN
いや、向うで煙たがられて誘導されたからって、
本当にこっちに来る事もないだろww

205 :名前は開発中のものです。:2007/01/31(水) 01:09:38 ID:8/b3tbHY
今適当に書いたけどフラグなんか使うよりこっちのほうがいいんじゃないか

template<typename T,int N>
class FixedAllocator
{
 union Block
 {
  T Data;
  Block* pNext;
 };
 Block* m_pGarbage;
 Block m_Pool[N];
public:
 FixedAllocator()
 {
  m_pGarbage = &m_Pool[0];
  for( int i = 0; i < N-1; i++ )
   m_Pool[i]->pNext = &m_Pool[i+1];
  m_Pool[N-1]->pNext = NULL;
 }
 T* Alloc()
 {
  Block* pRet = m_pGarbage;
  m_pGarbage = m_pGarbage->pNext;
  return &m_pGarbage->Data;
 }
 void Free( void* p )
 {
  static_cast<Block*>(p)->pNext = m_pGarbage;
  m_pGarbage = static_cast<Block*>(p);
 }
};

206 :名前は開発中のものです。:2007/01/31(水) 01:10:11 ID:94hlWcQw
>>202
フラグ管理より双方向リストでつないどくのが良いと思うけどな。

struct PoolNode
{
 struct PoolNode* pn_next;
struct PoolNode* pn_prev;
 char pn_padding[8]; //必要なら
 char pn_buf[PN_BUFSIZE];
};

static PoolNode nodes[NODENUM];

// 未使用ノードは、こっちにつなぐ
static PoolNode* free_first = &nodes[0];
// 使用中ノードは、こっちにつなぐ
static PoolNode* inuse_first = 0;

現実には、俺なら自前で書かずに STLport の node allocator にお任せして、
STLコンテナ使っちゃうか、boost::pool だけと。

207 :名前は開発中のものです。:2007/01/31(水) 01:13:52 ID:NKCnpIjT
boostみて、なんじゃこりゃーな感じだったので、

>>206とか、見るとわかりやすいですね。

配列でデータは持つんだけど、使用中ノードは、連結リスト風につないでおくっと。
未使用ノードも同じようにもつ。

これだけで、済む話かー。

208 :名前は開発中のものです。:2007/01/31(水) 01:14:36 ID:YqKTmdjS
>>205
それが segregated storage だろ。

209 :名前は開発中のものです。:2007/01/31(水) 01:15:32 ID:8/b3tbHY
>>208
そう言うのか

210 :名前は開発中のものです。:2007/01/31(水) 01:17:52 ID:kxHbC4YN
欲しいのはクラス名だけであって、
>>200が考案した以外のクラスなんて興味ないんだろw
だって、>>200より優れたクラスなんて存在しないんだからwww

つ 【ステフ18クラス】
つ 【次世代コミュクラス】
つ 【バキュンバキュンクラス】

この板ならではのクラス名を授けるから好きなの選べ

211 :名前は開発中のものです。:2007/01/31(水) 01:18:10 ID:8/b3tbHY
そう言うっていうか、boostのクラスなのか。
boost、まだ知らん機能多すぎる…orz

212 :名前は開発中のものです。:2007/01/31(水) 01:22:57 ID:94hlWcQw
boostは、知ってても使いこなせてないクラスも多いなぁ。fusionとかmplとか。

普段お世話になってるのは、stdafx.h 見るとこんな感じ。

#include <boost/array.hpp>
#include <boost/bind.hpp>
#include <boost/call_traits.hpp>
#include <boost/crc.hpp>
#include <boost/cstdint.hpp>
#include <boost/function.hpp>
#include <boost/format.hpp>
#include <boost/intrusive_ptr.hpp>
#include <boost/lambda/lambda.hpp>
#include <boost/lambda/bind.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/noncopyable.hpp>
#include <boost/ref.hpp>
#include <boost/scoped_ptr.hpp>
#include <boost/scoped_array.hpp>
#include <boost/static_assert.hpp>

213 :名前は開発中のものです。:2007/01/31(水) 01:24:55 ID:NKCnpIjT
>>210
変数名つけろスレから着たけど、
いまや、クラス名だけでないです。

>>210さんが、私のデータ構造を最高!マンセー!他はクズ!>>200様に一生従います!
と言ってくださるのは、うれしいのですが、

他に、どんな効率のよい、データ構造があるかというのを知りたいのです。

Delphiには、boostねーよー。うらやましい。

214 :名前は開発中のものです。:2007/01/31(水) 01:26:10 ID:NKCnpIjT
× >>200様に一生従います!
>>200様に一生を捧げます

間違えました。

215 :名前は開発中のものです。:2007/01/31(水) 01:26:40 ID:94hlWcQw
>>213
効率はデータの使い方に依存する。で、何に使おうと思ってるの?

216 :名前は開発中のものです。:2007/01/31(水) 01:46:00 ID:94hlWcQw
もしかしたら、主要なデータ構造を一通り勉強したいってこと? それなら、
まずは(データ構造を処理するアルゴリズムとセットで)

・Cプログラマのためのアルゴリズムとデータ構造
・珠玉のプログラミング
・プログラム設計の着想
・プログラミング作法

あたりの書籍を読むのがお薦めだが。

217 :名前は開発中のものです。:2007/01/31(水) 02:00:35 ID:kxHbC4YN
>>213
いや、普通に皮肉だから、無理にレスしなくていいよ。

218 :名前は開発中のものです。:2007/01/31(水) 02:31:13 ID:sTyDsN4F
この板で数少ない有用なスレッドだな

219 :名前は開発中のものです。:2007/01/31(水) 15:38:04 ID:CxDF9OMM
>>215
パーティクルや弾幕のように、
追加、削除の頻度が高い場合に使える構造はないかと探していました。

>>216
勉強したいだけ、というわけではないのですが、
参考になります。

220 :名前は開発中のものです。:2007/01/31(水) 19:22:58 ID:WbpDldoh
弾幕だったら各機で同時に発射しうる最大数に応じた領域確保しちゃうかな。
頂点バッファは1つあれば十分だし。

221 :名前は開発中のものです。:2007/01/31(水) 20:28:29 ID:94hlWcQw
>>219
パーティクルは出現数の上限を決めて、それを超えたら適当に消すのが常套手段。
多少消えても人間は気づかんから。

メモリ管理自体は PS2 以降のハードなら大した工夫は要らなくて、pool なり STLport の
node allocator なりで十分な性能が出る。それよりベクトル演算効率化することを考えとけ。

222 :名前は開発中のものです。:2007/01/31(水) 22:47:38 ID:YNrC6zK6
>>221
おまいの賢さは分かったが数個前のレスくらい読んでやれ

223 :名前は開発中のものです。:2007/01/31(水) 23:00:17 ID:94hlWcQw
>>222
同時に発射しうる最大数を確保して超えないことを保証するのと、適当な数を
確保しておいて越えたときに消しちゃえってのは、一見似てるけど使いどころが
違う。

一般にヒット判定があれば前者、単なる見た目だけなら後者。ヒット判定がある
ものを適当に消すと致命的なバグになったり、予期せぬ挙動をすることがある
ので。

224 :219:2007/01/31(水) 23:25:03 ID:NKCnpIjT
まあ、実際、別のプロジェクトで、毎回、インスタンス生成しても、
描画の方が圧倒的に遅すぎるというプロファイル結果が出たりしたので、
そんなに神経質になる必要はないんですけどね orz
(動作環境は、PCです)

新しいプロジェクトで、
パーティクル一杯出したいから、それぐらいは、pool化したいなって思ったんです。

72 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)