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

**名前は開発中のものです。** · 2006/08/10(木) 20:27:06

具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

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

**名前は開発中のものです。** · 2008/04/12(土) 23:04:47

>>920
> ステートマシンって一般的な単語なのかな
プログラマには常識だと思うな。

学生さんでも、大学で情報系専攻してれば必修だし。

**名前は開発中のものです。** · 2008/04/12(土) 23:11:40

考え始めたらこれ結構面白いなぁ。
さっき書いた動的拡張をスクリプトにするとして俺ならこんな感じ。

object 村人
　abstract action 会話

object 村人A extends 村人
　action 会話
　　message("おいらは村人A！")

action 魔王を倒した
　object 喜ぶ村人
　　action 会話
　　　message("あんたのお陰で村は平和だぜ！")
　dynamic extend 喜ぶ村人 on derived(村人)

action なんか知らんが魔王が復活した
　cancel dynamic extend 喜ぶ村人 on derived(村人)

>>920
ステートマシンて情報処理系の試験に出ないっけ？
波動(？)と何か関係あるの？

**名前は開発中のものです。** · 2008/04/12(土) 23:31:33

ものすごくスパゲッティになりそう

**名前は開発中のものです。** · 2008/04/12(土) 23:37:53

ここの住人はみんな情報系なのかな

**名前は開発中のものです。** · 2008/04/12(土) 23:45:24

波動ってハードのことね
ハードだと普通に使う、というかこの考え方がないと組み込みのコードもかけないだろ

**名前は開発中のものです。** · 2008/04/12(土) 23:48:56

>>922
誰でも一度は考えるなｗ
とはいえ、”いかに綺麗な構造を実現するか”より、
”いかに大量のフラグを管理するか”を中心に据えてツール類を整備した方が
スクリプターも楽だし、メンテもし易く、バグも出づらく、高速なコードができあがるという罠。

**名前は開発中のものです。** · 2008/04/13(日) 00:12:34

class Event
があって、List<Event> に全イベントをステージ最初にぶち込む。
で、各フェーズ毎に全イベントに、発動可能かを問い合わせる。
発動可能なら、キャラの位置を調べて、イベントの位置と合致する
なら実際にイベントを発動。

これ、chain of responsibility

**名前は開発中のものです。** · 2008/04/13(日) 00:29:46

DirectXと付き合うこと数年。
描画担当をエンティティから切り離すのはいいとして
その描画担当がシーンツリーの奥深くまでLPD3DDEVICEをもっていって
最底辺でd->SetRenderStateとかやってるのは
最近マルチパスレンダリングとか外部ファイルになったシェーダー等を考えるに
適当でないと感じるようになってきた
何かいいデザインがあるでしょうか

**名前は開発中のものです。** · 2008/04/13(日) 00:35:14

中間描画パケット使うてのはどうよ？
MTFrameworkやPSSG（はちょっと違うが）も似たような方式だし。

[シーンツリー] --(生成)--> [中間パケット配列] --(最適化)--> [最終中間パケット] --> [描画]

って流れで。
DirectX本体は、パケットの配列を読んで実行するのみで、シーンツリーには一切関与しない。

描画部を完全に切り離せる上、最適化部もシーンツリーのトラバースと分離できるメリットがある。
ただ、マテリアルやマルチレンダーターゲットの表現が難しい（的確なパケットを定義しないと冗長になってしまう）から、
パケットの設計が一番大変かと。

**名前は開発中のものです。** · 2008/04/13(日) 00:44:07

>>926
確かにその通りだよね。
今目に見えているものだけで動作を予測できるか、
ってとこがポイントなのかな。
自分でも、さっきのスクリプトみたいなのをスクリプターが頑張って書いても、
いざ実行してみて( ﾟдﾟ)ﾎﾟｶｰﾝってなってるのが目に浮かぶし。

でもそれは、専用のスクリプトエディタ的なアプリを作って
今見えているスクリプトに関連する情報を注釈としてオーバーレイ表示して
直ぐに関連を理解させることさえ出来れば結構改善できる気がするんだよね。
プログラムでクラス指向が普及しているのも、IDEによる直感的な補佐の
影響が効いているからだと個人的には思ってるし。

でもまぁ、一般的に想定出来る量の分岐のゲームで
ここまでやることはきっと割に合わないのだろうなぁと思う。
ただ、最近はオブリビオン(やったことないけど)とかいう、
莫大なスクリプトが存在するらしいゲームも出てるらしいじゃん。
そういったゲームリソースの肥大化から考えると、
こういうの考えておいて損はしないと思うんだよね。

**名前は開発中のものです。** · 2008/04/13(日) 00:57:00

>>927
こう書いたが良かった。List<Event*>
判定処理はConcreteEventクラス毎に違う

**名前は開発中のものです。** · 2008/04/13(日) 02:22:04

なんか勉強になる

**名前は開発中のものです。** · 2008/04/13(日) 04:39:58

>>929
MTFrameworkとかよくわからんけどデバイスコンテキストを持ちたくないとか、
ステートマシンにかかわりをもちたくないとか
単純なそういうものの隠蔽を望んでるわけじゃないのです

たとえば各個がDraw()を実装するような構造だと、シーンに一回デプスバッファだけ描かせるようにする
とかいう改変をしなくちゃならない場合に全部にDrawDepth()みたいな名前で同じようなことを
しなくちゃならん実装をしないといけないのはちょっと変だと思うわけです。

具体的な描画の手続きが末端におしつけられてる構造がなんとかならないかなと思ってるのかも。
わかりません。

**名前は開発中のものです。** · 2008/04/13(日) 05:37:30

>>933
自分でも分かってないのかよｗｗｗ
まぁ俺は末端の描画処理に上層から介入したいのだと見たよ。
その前提で答えてみる。

現状ツリー上に階層化された描画物は、上層から
IDirect3DDevice*を引数としてリレーしたものを使って描画してるわけだよね。
んでこれらの描画物の描画処理に変化を加えたいということであれば、
上層で、IDirect3DDeviceを拡張したインスタンスを作りそれを下層へ放流すれば良い。
分かるかも知れんが詳細にやり方を書くと、IDirect3DDeviceって確かクラスだったよね？
であれば単純に継承して各メソッドで本物のインスタンスへの委譲メソッドを書く。
そしたら自分が拡張したいメソッド、この場合SetRenderStateか？を好きなように変更する。
そんな感じでどうよ。
もちっと考えると、そもそもIDirect3DDeviceなんかを末端から直接触らせずに
自作クラスでラップしたものを使わせるようにすると見易いし色々と便利かと思うな。

こういう考え方、きっとよく知られてる知識なんだと思うけど、俺はJavaやって初めて知ったよ。

**名前は開発中のものです。** · 2008/04/13(日) 09:09:47

そういうことするなら直接継承はしないだろ

**名前は開発中のものです。** · 2008/04/13(日) 10:23:53

>>929
なるほど意味分かった。
形状描画とマテリアル（描画嗜好）分離されてるからそれでいいねえ

**名前は開発中のものです。** · 2008/04/13(日) 11:40:53

>>935
インタフェースなんだから直接継承しても問題ないんじゃないの？
あれ、ごめん、C++だとIDirect3DDeviceのメソッド郡はvirtualじゃないのか？
となると単純に継承しても元の型でアクセスされると拡張されたメソッドが呼ばれないのか。
じゃああれだ、自前クラスにするだな。

**名前は開発中のものです。** · 2008/04/13(日) 14:26:45

カプコンのなんとかフレームワークをパクればいいじゃない

**名前は開発中のものです。** · 2008/04/13(日) 14:39:55

言うは易し、行うは難し

**名前は開発中のものです。** · 2008/04/13(日) 18:58:15

中間なんたらを使うにしても結局ひとつのフレームを描画するための手続きが
シーングラフの各最小単位に分散してしまうのを僕は懸念してるのだと思うのです。
優先度みたいな古臭いタスクの仕組みが採用さられてるようだけれど結局
「あれ？この直前の優先度は何番だｔったっけ」とかいって探し回るマヌケな姿が目に浮かぶ
です。
MTFrameworkでぐぐってもimpressのアレしかでてこないのでこんな批判ですが
何か他に資料が公開されてるのでしょうか？

**名前は開発中のものです。** · 2008/04/13(日) 20:37:38

会社の機密情報をホイホイと公開すると思うの？
ｊｋ。

**名前は開発中のものです。** · 2008/04/13(日) 20:59:07

MTFrameworkについては公に出回ってる話しか知らんが

＞優先度みたいな古臭いタスクの仕組み

意味わからん
ハードウェアに渡す描画コマンドに優先順位があるのは今も昔も同じだし
よって投げるパケットに優先順位があるのも別に古臭くもなんとも無い
つか必須

「タスクの仕組み」がナニを指すのか知らんが、タスクシステムスレで言うところの
タスクシステム（＝ギャラクシアンの実装）の話をしてるのなら、あれは
エンティティ処理も描画処理も何もかも内包してる概念だから、ここでその話題を
持ってくるのは何か違う気がする

エンティティを線形リストに入れるだけなんて古臭い、シーングラフを使うのが現代的
などという話をしたいなら、それはここでは無関係の話題と思われ

**名前は開発中のものです。** · 2008/04/13(日) 21:14:21

＞描画するための手続きがシーングラフの各最小単位に分散してしまう

ないない。MTFrameworkだろうがその他のミドルウェアだろうがそれはない
各エンティティがグラフに入ってようが何であろうが自由だし
そのグラフ走査の順序でエンティティ更新処理が決定していようが

GPUに投げる情報の順序とは独立した、全く別の話

**名前は開発中のものです。** · 2008/04/13(日) 21:47:18

＞れはここでは無関係の話題と思われ
＞GPUに投げる情報の順序とは独立した、全く別の話
はい。MTFrameworkがいい、だめ、といったことを話したいんじゃなくて
MTFrameworkみたいなのの上の層の、中間描画パケットや描画の手続きを投げつける
構造のほう
のアイデアを伺いたいんです。

でもシーングラフ的構造を改めて設計でやりくりしようとせず
そこはそのままの形を留めたまま横断的事象を管理するために
一旦描画手続きをバッファにまとめる、というのもひとつの現実解なのかもしれないですね。

**944** · 2008/04/15(火) 05:27:06

>>943
＞ないない。MTFrameworkだろうがその他のミドルウェアだろうがそれはない

「手続き」というのは適当ではない表現だったとおもいます。
中間描画パケットはシーングラフの構成とは無関係に共通するシェーダをまとめあげる
役には立つと思うんだけど（そのためにつくられた仕組みなんでしょうし）
描画の主体は依然としてシーンのノードにあるのが普通だと思います。
全体としてみればシーングラフのツリーが描画をしていると言うことができるはず。
具体的にはシーンの最小単位がdrawとかいう名前のインターフェイスを持っていて
ここがパケットを発行するようになっているはず。

しかし一回のフレームを描画するのに全く異なる性質のものを複数回描画させられる
時代になった昨今、drawがここにあるのに違和感を感じる場面に遭遇することが多くなりました。

たとえばあるポストエフェクトのためにバックバッファとは別のバッファへデプスを描きだしていたとします
ユーザーの設定や場面によってそのエフェクトをばっさり無効にしたい場合
このバッファを描画する必要もなくなるわけです。ここでもしもシーンの各最小単位が
各々判断してバッファへの描き出しをやっていると大変なことに。シーンの最小単位が
描画の主体であるがゆえにこういった非効率が生じるわけです。

シーングラフとは別に描画の主体が存在するべきなのかもしれません。わかりませんが。

**名前は開発中のものです。** · 2008/04/15(火) 08:22:02

ガンダムに例えるとどういうこと？

**名前は開発中のものです。** · 2008/04/15(火) 15:18:31

>>945
>描画の主体は依然としてシーンのノードにあるのが普通だと思います。
>全体としてみればシーングラフのツリーが描画をしていると言うことができるはず。
>具体的にはシーンの最小単位がdrawとかいう名前のインターフェイスを持っていて
>ここがパケットを発行するようになっているはず。

シーングラフのノードにdraw()があるのが「普通」だと言いたいのか？
普通というからには有名どころの3Dゲームエンジンの少なくとも過半が
そういう設計になってることを実際に確認したんだろうな？

脳内妄想で普通とか言ってるとか言うなよ？

**名前は開発中のものです。** · 2008/04/15(火) 17:13:48

>>947
＞しかし一回のフレームを描画するのに全く異なる性質のものを複数回描画させられる
＞時代になった昨今

昨今？
見た目(形状、材質)が異なる複数種のインスタンスを効率よく描画するとか
そういう要請は10年以上前からほとんど変わってないよ

ところで俺の作文を見てくれ

　GPUのモンスターパワーに物を言わせ、パフォーマンスアナライザの類を一切用いずに
　呑気なコードを組んでもグリグリ動くちょい派手エフェクトの3Dアクションゲーがリリースできる
　時代になった昨今

どう思う？

**名前は開発中のものです。** · 2008/04/15(火) 17:29:08

すごく…いい時代です…

って俺なのか？ｗ

**名前は開発中のものです。** · 2008/04/15(火) 17:45:14

わりぃｗｗｗｗ>>948でレスアンカー間違えたｽﾏﾝｺ
×　>>947
○　>>945

＞ここでもしもシーンの各最小単位が各々判断してバッファへの描き出しをやっていると

あれ、中間描画ナンチャラの話はどこへ行ったんだ
「各最小単位」がシーングラフの階層構造内の各ノードのことで
そのノードのdrawメソッドが「バッファへの描き出し」をやるのか？
それ中間描画ナンチャラも何もなく、drawメソッド内で
直接DrawPrimitiveとか呼び出してね？

**名前は開発中のものです。** · 2008/04/16(水) 07:55:31

>>945
シーングラフを使ったことの無い俺が頓珍漢なことを言うけど、
一概にシーングラフって言っても、グラフ構造以外の
動作の実装って、各エンジンによってバラバラなんじゃないの？
その辺をどういう風に実装してるのかを>>944が情報開示しなきゃ、
具体的なアドバイスって出来ないんじゃないの？

ググってみたけどこれに近いの？各個が描画処理を持ってる。
http://www.quatouch.com/products/hisui/doc/scenegraph.html
こんな風に直に描画メソッドを呼び出しているから、
描画の主体がシーンの最小単位って言ってるの？
であれば「各ノードの描画要求」を仲介する管理者を立てればいいよね。
これは末端まで伝播されるコンテキストをその管理者とすると都合が良さそう。
管理者にエフェクト描画フラグとノード描画(node)メソッドを作って、その内部実装は、
if (
　(!nodeはエフェクト) ||
　(nodeはエフェクト && エフェクト描画フラグ)
){
　node.draw(this);
}
これで良いんじゃないのかな。

ただ、各ノードが描画メソッドを持ってしまっているとすると、
ゲームの実行状態と関係してくる複数の描画処理を、
一つのノードに内包させてしまっているのかなという気がするので、
その場合は、描画処理を一つずつノードへ分解しなければいけないと思うよ。

**名前は開発中のものです。** · 2008/04/16(水) 08:14:41

ごめん読み直したら解釈間違ってた。
「エフェクトをばっさり無効にしたい」ってとこだけ意識してしまって、
それが要求だと勘違いしてしまった。
半透明系のエフェクトの描画処理を無効化したいものだと思って
書いてしまったので、変なところは読み飛ばして欲しい。

ほんとの要求は、「描画先バッファを上層で制御したい」ってことだよね。
まあこれも多分、先に書いた管理者のノード描画部分で制御出来るんじゃないのかな。

**名前は開発中のものです。** · 2008/04/16(水) 21:55:02

>>951
＞ググってみたけどこれに近いの？各個が描画処理を持ってる。
そんなかんじです。drawをもってるcompositeパターン
>>952
＞ほんとの要求は、「描画先バッファを上層で制御したい」ってことだよね
制御できるかできないかという意味では
シーングラフがdrawを実装した今のままでも十分制御できます。
リファクタリングの動機は不可能を可能にとか、そういうところにはないと思います。

**名前は開発中のものです。** · 2008/04/16(水) 23:08:47

>>953
Visitor風の実装に変えてみたら？
シーングラフはモデルとマテリアル情報だけ持って、
Visitorがシーングラフをトラバースして必要があれば描画する
ポストエフェクトを切りたければ、ポストエフェクトのVisitorを無視すればいい、的な。

でも、どんなに描画とデータを分離したところで、実際にゲームを作ることになれば
ノード単位でのエフェクト制御（シャドウを落とすかどうか、とか）がどうしても必要になってきて、
末端に細かいフラグが蓄積してしまってあまり意味がないんだよね。

結局、描画エンジンに限っていえば、データと処理の分離は、
最大公約数的な情報を末端のノードに持たせることになって、逆に効率を落としちゃうし、
タイムクリティカルなゲームの最適化を阻害するのが実情。

先進的なエンジンほど、制約がきつい（拡張性が無い、固定機能ばかり）のが現実だから、
何かいい構造を思いついたら発表すれば、一儲けできるかもよ？

**名前は開発中のものです。** · 2008/04/16(水) 23:24:47

>>953
君のシーングラフというのは
ノード(特にdrawインタフェース付きのやつ)同士の接続は何を表しているの
まぁ典型的なものなら座標系(例えば姿勢行列)の親子関係になるわけなんだけど
この場合、巡回目的は行列スタックを積み上げてながら仮想空間上の各ノードの
ワールド座標を得ることだったりするわけだが、その処理の中でdrawを呼び出すの？

**名前は開発中のものです。** · 2008/04/17(木) 03:10:24

>>954
大枠のコンセプトとしてはVisitorということになるのかもしれません。
ただ、VisitorそのものはC++ではその真価を発揮できない、
Compositionツリーの方に新しい要素が頻繁に追加されることが予想される
等、その弱点がちょうど今回のケースにあてはまり、そのままでは適用しずらそうです。
さらに個人的な感想をかけば、型と場合に応じて関数がいくつもできあがるのは好みません。

それこそ中間描画パケットのようなローテクなアプローチが必要なのかもしれないです。

**名前は開発中のものです。** · 2008/04/17(木) 07:36:26

>>956
> ただ、VisitorそのものはC++ではその真価を発揮できない、
コードを書いてみてくれ。なんか勘違いしてるような気がするんで。

**名前は開発中のものです。** · 2008/04/17(木) 10:20:54

>>956
ゲームに使う分には、ノードに種類フラグを持たせて、適切にアップキャストするのが常套手段だね。
Visitorは対応している種類のノードだけ処理する。
Visitorの関数の数の爆発にも、ノードの種類の増加にも簡単に対応できる。
ダブルディスパッチが目的ではないから、Visitorとはコンセプトが少し違うな。
イテレータに近いかも。

**名前は開発中のものです。** · 2008/04/22(火) 22:42:37

>>956
つNVSG
Traverserあたりを調べればそういう基本的な悩みは解決すると思う。

**名前は開発中のものです。** · 2008/04/23(水) 18:23:23

>>959
とても参考になりました。
シーングラフはあくまでデータの一群であって
それぞれの目的をその名に冠したtraversalがそれを利用してそれぞれの目的を果たすと。
レンダリングもtraversalの一種に過ぎないと。そんな解釈みたいですね。

ただコレ、NodeHintsなるものとか、ShadowMappingがなぜか埋め込まれてるとか
ちょっと気味が悪い部分もありますね。

**名前は開発中のものです。** · 2008/04/23(水) 19:09:53

＞ちょっと気味が悪い部分もありますね。

具体的に言ってごらん

**名前は開発中のものです。** · 2008/04/23(水) 20:47:19

>>960

>>954　に
> ノード単位でのエフェクト制御（シャドウを落とすかどうか、とか）がどうしても必要になってきて、
> 末端に細かいフラグが蓄積してしまってあまり意味がないんだよね。

ってちゃんと書いてあるじゃねえか
NVSGはその典型例だよ

**名前は開発中のものです。** · 2008/04/25(金) 00:41:21

ノード毎の付加情報はあってもいいでしょ。各々のトラバーサーが自分に必要な
属性を処理すればいいだけ。C#のAttributeなんかが同じ要求から出てきたものじゃないかと思う。
プロパティグリッドの情報はオブジェクトにとって本質的じゃないけど、オブジェクト側に埋め込んでおきたい
みたいな。

**名前は開発中のものです。** · 2008/04/25(金) 00:47:43

C#のAttributeは型とメンバにメタデータを付ける機能だよ
オブジェクトには付けられない

**名前は開発中のものです。** · 2008/04/25(金) 01:13:35

インスタンスって意味でオブジェクトって使ったわけじゃないんだけど・・・。
じゃまぁ、s/オブジェクト/クラス・メンバ/ということで。

**名前は開発中のものです。** · 2008/05/05(月) 14:08:00

ほしゅ

**名前は開発中のものです。** · 2008/05/11(日) 16:38:51

プログラム板のデザインパターンスレから誘導されてきました。
ゲームを作ろうと思い、デザインパターンの勉強をしてるんですが
Singletonをどんな風に使うのか今一ピントきません。

Singletonじゃないと困る場合。
Singletonだと助かる場合。
出来たら例を示して貰えないでしょうか。

**名前は開発中のものです。** · 2008/05/11(日) 16:57:46

シングルトン滅びろ

**名前は開発中のものです。** · 2008/05/11(日) 17:02:04

バカほど背伸びしてアレコレ使いたがるよな。

**名前は開発中のものです。** · 2008/05/11(日) 17:24:11

やる気になってる馬鹿が一番伸びるだろ。
いい気になってる自称天才が一番伸びねえよ。

**名前は開発中のものです。** · 2008/05/11(日) 17:28:01

背伸びしてアレコレ使わないとバカとやらを脱出できないだろう。
少なくとも「糞だって他の人が言っていたから」
という理由だけで、一度も使ったことのないモノを非難する人よりはマシ。

**名前は開発中のものです。** · 2008/05/11(日) 17:42:18

デザパタの中でシングルトンが一番わかりやすいと思うんだけどなあ

**名前は開発中のものです。** · 2008/05/11(日) 17:52:03

>968-971を俺なりに要約すると、
・基本的な仕組みが判ってれば問題無い。
・ゲームを作っていけば、自ずと使う場面がわかるはず。
・判らないようじゃ、ゲーム制作に向いてない。
・むしろ技法を知らなくても何時の間にかそれっぽく書けるのが理想。
・使う言語が決まってるなら、そのスレを当たるのお勧め。

**名前は開発中のものです。** · 2008/05/11(日) 18:00:20

>>967
「クラスのインスタンスがひとつだけであることを保障する」というシングルトンの目的が
必要になる場面なんてほとんどないから、ピンとくるわけがない。

グローバル変数大好きなやつが免罪符みたいに使ってることのほうが多いから、
強いて言えば「グローバル変数が使いたいとき助かる」と言えるかもしれない。

**名前は開発中のものです。** · 2008/05/11(日) 18:16:18

>>974
画像を先読みしておいて使いまわしたい時には、
シングルトンで先読みして、
必要な時にクラス作って呼び出すってやってるんだけど、
これってもしかして、間違えてる？

**名前は開発中のものです。** · 2008/05/11(日) 18:30:24

>>975
それのどこでシングルトンが必要なのかわからない。

**名前は開発中のものです。** · 2008/05/11(日) 18:36:53

＞判らないようじゃ、ゲーム制作に向いてない。
はじめから知ってろってことか

**名前は開発中のものです。** · 2008/05/11(日) 18:40:49

（明示的な）グローバル変数が無い言語(java?)なら必要かもしれないけど、
ハナからある言語ならシングルトンなんてスパゲティ抑止策としか思えない。
そういう言語だとシングルトンは必要と言えば必要だし、いらなきゃいらない。

と言うわけでお前等落ち着け。

**名前は開発中のものです。** · 2008/05/11(日) 18:41:31

>>976
つーことは。間違えてるのか。
描画クラスをダレに持たせるかが分からなくて、
ダレにも持たせないのを選択したのが、悪いのかな？

**名前は開発中のものです。** · 2008/05/11(日) 18:42:43

書き忘れ。Ｃ＋＋でウインドウズ用のプログラムを作ってました。

**名前は開発中のものです。** · 2008/05/11(日) 18:53:03

コンストラクタやデストラクタが、近いように見受けられますが
それで済むなら、シングルトンは必要ないですよね。
一つしか存在しないのを分からせる為の目印と言うには分かりにくいですし…
となると、シングルトンが作られた目的というか、用途があるはずですが
例えば、データを受け取って、それをファイルへセーブするクラスはどうでしょうか。

キャラ毎に進行状況やフラグをセーブするような場合や
キャラリストファイルから特定のキャラを選び、探索チームを作成し
そのチームのキャラデータのみをキャラリストファイルへ反映させる場合です。
wile(チームの終わりまで) {
　Team[ chara_pos ].save()
}
（そんなごちゃごちゃしたセーブのやり方をするなと言うツッコミはなしで）

**名前は開発中のものです。** · 2008/05/11(日) 18:57:03

>>979
描画クラスは一つ一つのキャラクターが持つはず。
画像は同じでもアニメのパターンが違ってたりするので。

>>976
STGのザコ敵で、同じ画像を使っていて、何百匹も出る場合です。

**名前は開発中のものです。** · 2008/05/11(日) 19:03:55

ｇｄｇｄだなぁ…

クラスに画像が固定ならシングルトンでも良いけど、
可変なら微妙じゃね？
（シングルトンで可変な数の画像読むなら別だろうけど、
それはそれでアクセス方法がシングルトン的じゃなくなりそうｗ）

つか、必要か不要か二元論な奴は、
議論する暇あったらミニゲームでも作って、
いろいろ試したらどうよ…

**名前は開発中のものです。** · 2008/05/11(日) 19:38:15

質問する方も答える方もバカでﾜﾛﾀｗ
背伸びしすぎｗ

**名前は開発中のものです。** · 2008/05/11(日) 19:38:35

> 一つしか存在しないのを分からせる為の目印と言うには分かりにくいですし…
・シングルトンを知っていれば分かる
・知らずに2個インスタンスを作ろうとしても作れない
これ以上に分かりやすい目印はないと思うが。

**名前は開発中のものです。** · 2008/05/11(日) 20:27:08

今、自分は、地図を開いて「このマークはわかりにくい」と言ってるような
現状だというのは分かっています。
マーク単体の意味は分かっても、それを利用する為の判断基準のようなものが
自分の中にまだ備わっていないので、先達の方に例を示して貰えないかと来てみたわけです。

**名前は開発中のものです。** · 2008/05/11(日) 20:50:58

いい加減くどいな。ゲーム作り始めれば判るよ。お前だって
「自転車のハンドルを右にきる理由は理解してるのですが、タイミングは何時ですか？」
と聞かれたら「転んで憶えろ」と言うしかないだろ？

**名前は開発中のものです。** · 2008/05/11(日) 20:51:58

シングルトンて言葉にするの、何か恥ずかしくね？
「このクラスはシングルトンです。」
とか真顔で言える気がしない。
唯一のインスタンスを保障するだけの癖に
大層な名前がついてるなって思う。

**名前は開発中のものです。** · 2008/05/11(日) 20:52:35

とりあえず言わせてくれ。
みんな話題待ちすぎｗｗｗ突然レスがつきすぎだぜ

**名前は開発中のものです。** · 2008/05/11(日) 21:04:49

>>967
ハンドルとか設定とかを持たせるときとか

**名前は開発中のものです。** · 2008/05/11(日) 21:05:29

シングルトンは人に説明するのに便利すぎる
他のパターンと違って誤解される可能性が低いのと他よりは知名度高いからよく使ってる

でも、デザパタって意外と知ってる人少ないよね
普通に会話に使うもんだと思ってGoF勉強したけどほとんど通じない

**名前は開発中のものです。** · 2008/05/11(日) 21:07:20

ところで、シングルトンは
インスタンスがなければ生成してから返し、ある場合は既にあるインスタンスを返す関数が在るってことであってる？
個人製作なら自分ルールで最初にその手のインスタンスは初期化する、って決めておけばいらなそう。

複数人で開発する場合で、その手のインスタンスを前もって初期化したくない場合は効果がでるかもわからん

**名前は開発中のものです。** · 2008/05/11(日) 21:07:32

>>987
不幸なことに、シングルトンが必要と思われるケースのプログラムを
今までに組んだことがありません。
極端な言い方をすれば、この先シングルトンを使う場面に遭遇しなければ
シングルトンが何なのかさえ分かりません。
知っていて使わないのと、知らないで使えないのでは大きく意味が違うと思います。

**名前は開発中のものです。** · 2008/05/11(日) 21:29:15

ム板のデザインパターンスレに戻った方が良いと思うよ。
ここはGoFすらろくに知らないで設計語ってるスレだから

**名前は開発中のものです。** · 2008/05/11(日) 21:32:50

業務系とゲーム系だとまた求められてるものが違うから

スコープはコンテナが管理するというのが今の流れだよね
シングルトンであるとかプロトタイプであるとかで構成は変えないしね

ゲームなら面とかでスコープかえると初期化が楽になるかもしれないけど
メリットはあまりないかと

オンラインゲームなら必須の知識ではあるけど

**名前は開発中のものです。** · 2008/05/11(日) 21:45:37

>>993
だったら使うなよ。くだらん豆知識さっさと忘れてゲーム作れ。
気がつけば「あ、これシングルトンだったね」と気がつく日もあるだろう。

**名前は開発中のものです。** · 2008/05/11(日) 21:55:34

>>996
失礼ですが、他の人が言ったことを繰り返して言っているだけの言動からは
貴方がデザインパターンを理解しているとは到底思えません。

**名前は開発中のものです。** · 2008/05/11(日) 22:13:28

挙句の果てに、妄想で批判とか、折角ゲーム作るように促してやってるのに困った奴だな…

**名前は開発中のものです。** · 2008/05/11(日) 22:24:00

>>998
スレタイを確認した方が良いんじゃないですか？

**名前は開発中のものです。** · 2008/05/11(日) 22:24:58

他の方々のレスは大変参考になりました。
ありがとうございました。

**１００１** · Over 1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。