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

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

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

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

**名前は開発中のものです。** · 2007/01/31(水) 00:44:13

>>200
答えでてんじゃん。
ここで何が聞きたいの？

**名前は開発中のものです。** · 2007/01/31(水) 00:49:48

フラグ立ててるだけなのがなー。
削除と同時に最後尾のデータをコピーしちまえ。

**名前は開発中のものです。** · 2007/01/31(水) 01:00:05

>>200
そのアルゴリズムのどこが高速なのか本当に分からない。
フラグを立てて何に使うの？

**名前は開発中のものです。** · 2007/01/31(水) 01:08:05

いや、向うで煙たがられて誘導されたからって、
本当にこっちに来る事もないだろｗｗ

**名前は開発中のものです。** · 2007/01/31(水) 01:09:38

今適当に書いたけどフラグなんか使うよりこっちのほうがいいんじゃないか

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);
　}
};

**名前は開発中のものです。** · 2007/01/31(水) 01:10:11

>>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 だけと。

**名前は開発中のものです。** · 2007/01/31(水) 01:13:52

boostみて、なんじゃこりゃーな感じだったので、

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

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

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

**名前は開発中のものです。** · 2007/01/31(水) 01:14:36

>>205
それが segregated storage だろ。

**名前は開発中のものです。** · 2007/01/31(水) 01:15:32

>>208
そう言うのか

**名前は開発中のものです。** · 2007/01/31(水) 01:17:52

欲しいのはクラス名だけであって、
>>200が考案した以外のクラスなんて興味ないんだろｗ
だって、>>200より優れたクラスなんて存在しないんだからｗｗｗ

つ　【ステフ１８クラス】
つ　【次世代ｺﾐｭクラス】
つ　【ﾊﾞｷｭﾝﾊﾞｷｭﾝクラス】

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

**名前は開発中のものです。** · 2007/01/31(水) 01:18:10

そう言うっていうか、boostのクラスなのか。
boost、まだ知らん機能多すぎる…orz

**名前は開発中のものです。** · 2007/01/31(水) 01:22:57

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>

**名前は開発中のものです。** · 2007/01/31(水) 01:24:55

>>210
変数名つけろスレから着たけど、
いまや、クラス名だけでないです。

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

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

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

**名前は開発中のものです。** · 2007/01/31(水) 01:26:10

× >>200様に一生従います！
○ >>200様に一生を捧げます

間違えました。

**名前は開発中のものです。** · 2007/01/31(水) 01:26:40

>>213
効率はデータの使い方に依存する。で、何に使おうと思ってるの？

**名前は開発中のものです。** · 2007/01/31(水) 01:46:00

もしかしたら、主要なデータ構造を一通り勉強したいってこと？　それなら、
まずは(データ構造を処理するアルゴリズムとセットで)

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

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

**名前は開発中のものです。** · 2007/01/31(水) 02:00:35

>>213
いや、普通に皮肉だから、無理にレスしなくていいよ。

**名前は開発中のものです。** · 2007/01/31(水) 02:31:13

この板で数少ない有用なスレッドだな

**名前は開発中のものです。** · 2007/01/31(水) 15:38:04

>>215
パーティクルや弾幕のように、
追加、削除の頻度が高い場合に使える構造はないかと探していました。

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

**名前は開発中のものです。** · 2007/01/31(水) 19:22:58

弾幕だったら各機で同時に発射しうる最大数に応じた領域確保しちゃうかな。
頂点バッファは１つあれば十分だし。

**名前は開発中のものです。** · 2007/01/31(水) 20:28:29

>>219
パーティクルは出現数の上限を決めて、それを超えたら適当に消すのが常套手段。
多少消えても人間は気づかんから。

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

**名前は開発中のものです。** · 2007/01/31(水) 22:47:38

>>221
おまいの賢さは分かったが数個前のレスくらい読んでやれ

**名前は開発中のものです。** · 2007/01/31(水) 23:00:17

>>222
同時に発射しうる最大数を確保して超えないことを保証するのと、適当な数を
確保しておいて越えたときに消しちゃえってのは、一見似てるけど使いどころが
違う。

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

**219** · 2007/01/31(水) 23:25:03

まあ、実際、別のプロジェクトで、毎回、インスタンス生成しても、
描画の方が圧倒的に遅すぎるというプロファイル結果が出たりしたので、
そんなに神経質になる必要はないんですけどね orz
（動作環境は、PCです）

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

**名前は開発中のものです。** · 2007/03/21(水) 22:27:58

>>224
シミュレータの場合、速度最優先で描画をしない状況もあるから、
それが免罪符にならない場合もあるんだよね

**名前は開発中のものです。** · 2007/03/23(金) 13:48:25

良スレage

**名前は開発中のものです。** · 2007/03/26(月) 06:10:31

ところで、
キャラクターの構造体は何で取ってる？
今じゃ普通にダブルでとっても問題ないよな。
むしろ、その方が微調節がしやすくって良いよね。
俺は貧乏癖がついててイントでとって微調節がやり辛くなって、
結局後で困ったりしてるんだよね。

皆は何で取ってる？

**名前は開発中のものです。** · 2007/03/26(月) 06:11:56

あ、ゲームは普通の２ｄのアクションゲームとかです。

**名前は開発中のものです。** · 2007/03/26(月) 08:35:24

doubleでおｋ

次の話題どうぞ

**名前は開発中のものです。** · 2007/03/26(月) 12:51:40

単純にintのかわりにすると計算誤差で困ることも多いからちゃんと使ってくれ
具体的にはイコールで判定とかやっちゃだめだぞ

**名前は開発中のものです。** · 2007/03/26(月) 18:43:03

>>227
自分で固定小数点数作るのが楽ちんだろ
浮動小数点数の等号問題も出ないし

**名前は開発中のものです。** · 2007/03/26(月) 19:09:19

桁落ちの誤差で困ったことはないなあ。
「本当はセーフだったのに、桁落ちしたせいで等号が成立して
　敵に当たったことになって死にました」みたいな状況は
あるだろうけど、まず気づかないと思うし。

そのあたりを完璧にしたいのであれば、丸め誤差も考慮に入れて
10進固定小数点数クラスを作らなければならないだろうけど、
そこまでしたくないというのが正直なところ。

**名前は開発中のものです。** · 2007/03/26(月) 19:20:52

>>232
そんなクラス作らなくてもいいんじゃね？
16ビットシフトするだけでゲームの精度的には十分かと。

**名前は開発中のものです。** · 2007/03/26(月) 21:35:29

ttp://shinh.skr.jp/template/gamenum.html

**名前は開発中のものです。** · 2007/03/26(月) 22:10:26

>>232
なんか勘違いしてるけど、固定小数点数にするのに１０進は関係ないぞ。

**名前は開発中のものです。** · 2007/03/26(月) 22:13:45

>>235
10進って言ったのは、丸め誤差を考慮しての話なんだけど。
桁落ちとは関係ない。

**名前は開発中のものです。** · 2007/03/27(火) 01:42:55

10進でも2進でも丸め誤差は出るってば。

**その1** · 2007/03/27(火) 06:12:21

「キャラの座標の型に関して」

・整数か小数か -> 断然小数

・小数の表現方法
　-> 浮動小数点数 or 固定小数点数
　-> 2進表現 or 10進表現

・浮動小数点数
　○ 基本型であるので扱いが楽
　× 演算速度が遅い
　△ 非常に近い値同士を比較したときに桁落ちが発生する
　　 (桁落ちが発生したところで別段問題がない場合も多々ある)
・固定小数点数(クラス実装)
　○ 比較による桁落ちが発生しない
　○ 実態は整数型なので演算速度が早い
　　-> × 汎用性の高い実装(シフト数の異なる固定小数点数同士でも演算を
　　　　　可能にするなど)を行うと、結局浮動小数点数以下の演算速度に
　× 固定小数点数オブジェクトの生成が頻繁であると遅くなる
　　 (特にオペレータ・オーバーロードに注意)
　△ 小数点以下の精度(桁数)が固定
　　 (ただし、精度が足りなくて困ることはまず無いと思われる)

**その2** · 2007/03/27(火) 06:13:22

・2進表現
　○ 基本型は2進表現なので扱いが楽
　× 10進表現で有限小数となるが2進表現で循環小数になるような値の場合、
　　表現できない桁が切り捨てられるなどして丸め誤差が発生する

・10進表現
　○ 循環小数に対する丸め誤差が起きない
　　-> × 一般によく使われるであろう加算減算処理では問題ないが、
　　　　　除算を行うなどすると何進数であろうが丸め誤差は発生する
　XX 基本型とは程遠い別次元の演算手法が要求される
　　 (2進表現で循環小数となるような値を基本型で記述した時点でアウト)
　× 同じバイト数で表現できる値の範囲が2進表現より狭い

勝手にまとめっぽい形式で書いてみた。
固定小数点数に関してはクラスとして実装した場合を想定した。
個人的に、固定小数点数を素のintで表現して、その都度シフト変換を行うような手法は、
変換方法に依存した関数/クラスを大量発生させるので論外だと思う。

**名前は開発中のものです。** · 2007/03/27(火) 06:39:01

10進表現ってBCDのことだったの？
俺はてっきりintを10^nで割って使う話だと思ってた。

**名前は開発中のものです。** · 2007/03/27(火) 06:42:53

色々書いたけど、結局俺は無難なdoubleを使っちまうかなあ。
試しに固定小数点数クラスを作ってみたけどあんまし早くならなかった。
っていうかコンパイラによって速度が大きく変わりそうな予感。

10進表現での計算は、誤差が出たら切腹必至の
銀行システムとかでのみ使うものだと思っている。
言語的にサポートされていれば話は別だけど。

以上長文&駄レスすまん。

**名前は開発中のものです。** · 2007/03/27(火) 06:45:51

>>240
俺は流れ的にBCDのことだと思ったが…。違ってたらすまん。

**名前は開発中のものです。** · 2007/03/27(火) 10:06:48

昔は、固定小数点使ってたな
今は、さすがに、浮動小数だわ

問題は、環境によっては、リプレイでずれるとかその辺
（D3DXの最適化とか最適化とか最適化とか）

**名前は開発中のものです。** · 2007/03/27(火) 12:34:52

浮動小数点だと0.1ですらがあらわせないからな
表せないのに無理しているのが浮動小数点
あらわせないのなら扱わない、問題が出ないようにするのが固定小数点

0.1を10回たしたら１になるとか思ってるような人は固定小数点つかっとけと

**名前は開発中のものです。** · 2007/03/27(火) 14:36:14

アナログコントローラーとか3D処理やったこと無いのかな

**名前は開発中のものです。** · 2007/03/27(火) 19:55:06

Flashとかだと0.5ずつずらさないと隙間が空くとかあるんだよね

**名前は開発中のものです。** · 2007/03/27(火) 20:06:13

微妙に関連する話題だと思うんだけど、
皆は(無限)多倍長精度整数を使ってたりする？

**名前は開発中のものです。** · 2007/03/28(水) 00:55:28

>>247
固定小数点数使ってたら、上の桁が足りなくて、
仕方なしに64ビット整数を使っちゃったことはある

**名前は開発中のものです。** · 2007/03/28(水) 05:12:49

>>247
そういうのは学術用だと思うよ。
ゲームなら実際問題そんないらんっしょ。

**名前は開発中のものです。** · 2007/03/28(水) 05:53:37

得点計算で使われることもあると思う。
32bit符号なし整数では40億程度しか表せないし。

恐ろしい桁数の得点をガンガン加算させて、
かつ一の位までキッチリ使っちゃうような
血も涙もない鬼の方御用達です。

**名前は開発中のものです。** · 2007/03/28(水) 07:59:56

無限多倍長精度整数って書いてるんだよな。
long longより上だと3倍長で7.9x10の28乗とかになるけど……要るか？

**名前は開発中のものです。** · 2007/03/28(水) 11:11:39

>>249
んなーこたーない。
経営シミュレーションで多倍長な変数を使うことはあるよ。
キャッシュとか資産とかの額で。
まさか、浮動小数点使うわけにはいかんし。

**名前は開発中のものです。** · 2007/03/28(水) 12:08:50

ビルゲイツの資産とか32bitに収まりきらんもんな

**名前は開発中のものです。** · 2007/03/28(水) 12:54:06

そもそもビルゲイツの資産は、株価がちょっと変わるだけで
とんでもない額が変動するから、下の方の桁にあまり意味はない。

**名前は開発中のものです。** · 2007/03/28(水) 15:10:12

32bitどころじゃないだろ。

まあ、毎年訳分からん団体に１兆寄付してるおっさんだからな。

寄付してるのは妻の方だけ？

**名前は開発中のものです。** · 2007/03/28(水) 16:57:57

自分の設立した財団じゃないのあれ？

**名前は開発中のものです。** · 2007/03/30(金) 00:16:52

Delphiの日付用構造体TDateTimeを馬鹿にするなよ？
日付なのに、不動小数

**名前は開発中のものです。** · 2007/03/30(金) 01:10:16

不動ならいいや('ー`)

**名前は開発中のものです。** · 2007/03/30(金) 03:52:48

MSのAccessも日付はdoubleでもってたような・・・

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

いいシーン管理方法が思いつかない…。
「シーンはスタックに積む」って話をよく聞くけど、
積みっぱなしでメモリは大丈夫なのかとか、
タイトルシーンやメニューシーンはその都度生成した方が
再初期化の手間いらずで楽なんじゃないかとか、
ロードの際にスタックの中身をいちいち
再現しなきゃいけないんじゃないかとか、色々疑問が残る。

**名前は開発中のものです。** · 2007/04/01(日) 13:27:10

>>260
何が「いい」かは作るプログラムによって違うからな。
疑問に思うんならやってみろとしか言えない。

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

なるほどそういうときにシリアライズを使うのか

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

>>260
Gemsの５巻にスタックを使ったシーン管理が載っている。

試してみたら、なかなか使い易かったよ。

**名前は開発中のものです。** · 2007/04/01(日) 15:35:35

>>262
javaのシリアライズの話ならそういう時の為のものじゃないぞ

**名前は開発中のものです。** · 2007/04/01(日) 20:39:12

>>260
作ってるゲームによるでしょ。

シーン切り替えの度にブラックアウト & ロード処理が入るふつーの RPG だと、
シーンは必要な都度 new して作る（ただしテクスチャ・モデル等のリソース類は
事前に割り当て決めておく）、状態遷移はプログラム側でベタに行う…で十分に
管理できる程度だった。

**名前は開発中のものです。** · 2007/04/05(木) 20:02:57

>>263
Gemsうｐ！！
って、無理だｗ

ソースコードだけでも配ってないのか・・・

**名前は開発中のものです。** · 2007/04/06(金) 02:24:49

【警告】
日本はカルト教団に支配されてしまいます。
選挙に行きましょう。

**名前は開発中のものです。** · 2007/04/06(金) 16:07:18

スタックベースのシーン管理に参考になるページはないですか？

**名前は開発中のものです。** · 2007/04/07(土) 09:34:17

どっかのやねうの昔のサイトに解説がなかったか。

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

YaneSDK.Netのソース読め

**名前は開発中のものです。** · 2007/04/08(日) 01:31:41

本人がいらっしゃるようなので一言申し上げますが
yaneSDK3rdの更新してください＞＜
2ndからトランジエントビルトを移植しようとしたんですが正直無理です＞＜

**名前は開発中のものです。** · 2007/04/08(日) 01:42:46

無理とか言ってたらなんも成長しないがな。
つか本人が来たとか本気で思ってるのか。

**名前は開発中のものです。** · 2007/04/08(日) 02:50:06

皮肉にマジレスしてどーする

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

そういや、やねうらおの会社の社員が、やねうらおを訴えた件はどうなったんだろうな。

**名前は開発中のものです。** · 2007/04/09(月) 03:25:15

騙された馬鹿が、ギャーギャー文句言ってただけ

**名前は開発中のものです。** · 2007/04/09(月) 03:38:12

いい加減スレ違い。

**名前は開発中のものです。** · 2007/04/09(月) 13:14:13

スタックベースのシーン管理について質問

つくってみたけど、いまいち利点がわからん・・・
何が便利なんだろう・・・

**名前は開発中のものです。** · 2007/04/09(月) 15:13:20

スタックみたいな古臭いのじゃなくて
デザインパターンでオブジェクト指向的にスッキリと出来ないものなんだろうか

**名前は開発中のものです。** · 2007/04/09(月) 16:14:10

シーンをオブジェクトと見なしてスタックに積むんだから、
十分オブジェクト指向じゃないかと思うんだけど、そういうことではない？

**名前は開発中のものです。** · 2007/04/09(月) 18:50:04

>>277
利点かー。
末端のシーンがどこに戻るか把握しなくていいから、シーンを柔軟に組めるとか、シーンを再利用しやすいとか。
ごめん、思いつきで書いた。

**名前は開発中のものです。** · 2007/04/09(月) 20:46:27

>>279
うん。
それ自体が定型になるなら、スタックベースのシーン管理というのも
ゲームにおけるデザインパターンといっても過言ではないと思う。

**277** · 2007/04/09(月) 20:49:46

とりあえず、googleして、定番とおもわれる

・呼び出し（Call)
・移動(GoTo)
・呼び出し側に戻る（Return)

をシーン管理オブジェクトに、実装して、シーンを状態遷移してみたりしたんだけど、

これって、シーンを遷移するときって、前のシーンは開放しちゃっていいのか？
開放しちゃうと、
しなかったらしなかったで、リソース圧迫するし

クソー、Game Programing Gems 5がほしいZE

**277** · 2007/04/09(月) 20:54:13

> 開放しちゃうと、
開放しちゃうと、呼び出し(Call)の意味あんのかな？と思うし

**名前は開発中のものです。** · 2007/04/09(月) 23:33:21

ところでシーン間の関係はだれが持つの？

シーンクラス？シーン管理クラスとか他のクラス？

分岐のあるゲームだとこれ重要。
次に進めるべきシーンを決める奴が持てばいいのか・・・？

シーン遷移管理とシーン関係管理＋フラグ管理に分けるとか？

>シーンを遷移するときって、前のシーンは開放しちゃっていいのか？

javaだとこれ厄介なんだよね。何しようが使ってなかったら勝手に拾われるから。
一応クリーンアップなりシャットダウンなり処理して放置かな。

こういうときにファイナライザ使うもんじゃないしね。

**名前は開発中のものです。** · 2007/04/10(火) 00:13:19

>>277
シーンは最初に全部確保して
最後に全部解放してるよ。

シーンスタックそのものが「アクティブなシーン」のスタックであって、
今アクティブじゃないシーンは別のリストに保管してる。
でスタックに積まれてるものは一通り処理する。

こうすることで移動画面中にメニューも表示して移動もメニュー選択も可とか
裏画面でデモ（通常ゲーム処理）回しながら上にウィンドウ表示とか
出来ますよ　って趣旨だったと思う >Gems5

ただ、ウィンドウ関係以外には特に利点は無さそう。

**名前は開発中のものです。** · 2007/04/10(火) 01:08:35

マルチスレッドを実現する手段の一種ということ？

**名前は開発中のものです。** · 2007/04/10(火) 01:12:58

>>285
＞でスタックに積まれてるものは一通り処理する。
これ、厳密にはスタックって呼べなくね？
LIFO≠スタック

**名前は開発中のものです。** · 2007/04/10(火) 01:16:37

なんだ、シーンの遷移がスタック的なのかと思ってた。

**285** · 2007/04/10(火) 01:26:00

>>287
上にシーンを積んだときにサスペンド処理（シーンクラスのメソッド）を呼ぶようにして
サスペンド中も実行したいシーンはその処理でサスペンド時も実行してねフラグを立てる
とかそんな処理になっていたと思うから　一応一番上に積まれているのが
現在のシーンってことになる。
立ち読みだから細かいことは忘れたｗ

スタック全体をなめるんだからスタックとは言わないと俺も思う。

**277** · 2007/04/10(火) 01:59:26

わかった。
かなり勘違いしていた・・・。

>>288
俺もそう思ってたｗｗ

**名前は開発中のものです。** · 2007/04/10(火) 09:19:06

これ読んで、久々にパックマン作りたくなったな～。
アクションゲームは、作ってないけど、デザインパターンを、正しく使うと、プログラムがスッキリするし、大好き。
デザインパターンって、しらない人多いのかな？

**名前は開発中のものです。** · 2007/04/10(火) 09:47:11

Large-Scale Stack-Based State Machines
James Boer
Game Programming Gems 5, 2005.

**名前は開発中のものです。** · 2007/04/11(水) 01:26:38

>>291
> デザインパターンって、しらない人多いのかな？
んなわきゃない

**名前は開発中のものです。** · 2007/04/11(水) 05:40:08

スタックベースのシーン管理、結局、状態遷移をスタックベースに作ってしまったｗ

これで、

　タイトル画面→(呼び出し)→ゲーム処理→(戻る)→タイトル画面

とか、
　タイトル画面→(呼び出し)→リプレイのメニュー→(呼び出し)→ゲーム処理→(戻る)→
　リプレイメニュー→(戻る)→タイトル画面
とかできるようになったｗ

スタックベースといったらやっぱりこっちだろｗ

**名前は開発中のものです。** · 2007/04/11(水) 05:56:16

スタック的に自然な状態遷移しかしないのであれば役に立つだろうけど、
そうではない大部分のゲームにとっては役立たず以外の何物でもないと思う。

**名前は開発中のものです。** · 2007/04/11(水) 07:47:20

スタックというデータ構造を状態遷移を表現するために利用するからには
・次のシーンに移る＝push操作
・1つ前のシーンに戻る＝pop操作
という対応関係が常に成り立っていて、この操作のみで完結すべきなんだが、
これだけの操作でOKなゲームがどれだけあるかっていうと、ぶっちゃけほとんどない。
スタックにこだわるあまり、データ構造を破壊したり
オブジェクトの役割を破壊したりするような例が後を絶たないのだが、
>>279と>>281のようなやり取りが行われている現状では仕方がないか。

**名前は開発中のものです。** · 2007/04/12(木) 03:38:40

実質が状態遷移ならstateパターンでいいやんって事ですか？

**名前は開発中のものです。** · 2007/04/12(木) 04:43:05

>>297
Stateパターンとか全く関係ないよ。
シーンの遷移をうまく表現するためのデータ構造に関する話。

どこまで理解しているかわからないから基礎から説明する。
Stackというデータ構造は、
・オブジェクトを1つStackに積むpush操作
・最後にStackに入れたオブジェクトを1つ取り出して捨てるpop操作
・最後にStackに入れたオブジェクトを参照するtop操作
を持つ。ここで、
・push操作＝次のシーンに移る
・pop操作＝1つ前のシーンに戻る
・top操作＝現在のシーンを取得する
と対応付けると、これはシーン管理に使えそうだぞってことになる。
これが、今話題に上がっているStackベースのシーン管理。

これをStateパターンにしたところで、Stackの中に入るオブジェクトが
シーンオブジェクトから状態オブジェクトに変わるだけで、
シーン遷移のための操作やベースとなるデータ構造は変化しないってのはわかる？

**名前は開発中のものです。** · 2007/04/12(木) 05:16:23

(続き)
で、何故Stackベースのシーン管理に関して
>>295と>>296(俺)のような批判が出るかって言うと、
>>298で挙げた3つの操作だけでうまく管理できるような
状態遷移になっているゲームが少ないから。

例えば、Stackの状態が
タイトル <- メニュー <- ゲーム処理 <-
だとして、ゲームオーバーシーンに移りたいとする。そうするとpush操作で
タイトル <- メニュー <- ゲーム処理 <- ゲームオーバー <-
となるが、次にタイトルシーンに移りたくなったときに、
これに対応する操作がない。あくまで与えられている操作は、
次のシーンに移るか、1つ前のシーンに戻るかだけだから。

"ゲームオーバーシーンから戻るときだけは
topがタイトルシーンになるまでpopする"というような特例を
不都合が生じる度に設けると、Stackベースにした意味がなくなる。
これが>>296で言った『データ構造の破壊』に相当する。

"Chain of Responsibilityパターンを使ってシーンオブジェクト間で
データをリレーしていけば実現できるよ"って意見をどこかで
見たことがあるのだが、そもそもシーンオブジェクトには
状態遷移を正しく行う責任はないので、オブジェクトの動作的に不自然。
これが>>296で言った『オブジェクトの役割の破壊』に相当する。

ここまで神経使うかよって思うのが普通だとは思うけど、
せっかくのデータ構造スレなので色々グダグダと言ってみた。
よさげなデータ構造があれば是非ともそれを利用したいし。

**名前は開発中のものです。** · 2007/04/12(木) 07:27:37

Stackのシーン管理を、必要なところだけ使うようにすればいいんじゃないの。
セーブ画面とか、オプション画面とか。