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

**名前は開発中のものです。** · 2008/05/23(金) 21:10:59

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

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

前スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/

テンプレ追加事項あったらよろすく

**501** · 2009/03/23(月) 00:38:25

>>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()みたいにベタ書きで
どこまでいけるかやってみるかな。

**名前は開発中のものです。** · 2009/03/25(水) 00:59:33

hamigaki::coroutines使ってみた。

**名前は開発中のものです。** · 2009/03/25(水) 12:39:16

yhamigakiさんのexec.jamモジュールにはお世話になっております

**名前は開発中のものです。** · 2009/04/05(日) 14:24:00

スレッド1..n 仮想描画コマンドをメモリに積む
デバイス用スレッド　仮想描画コマンドを解釈して実際のコマンドを発行

利点単体テストが容易、移植が容易、マルチコアの恩恵を受けることができる
欠点仮想描画コマンドバッファの管理にロック、セマフォは必須、上手に使用しないと逆に重い

**名前は開発中のものです。** · 2009/04/06(月) 03:21:58

仮想描画コマンドバッファをスレッドごとに持てばいいじゃない。

**名前は開発中のものです。** · 2009/07/15(水) 22:32:12

http://www6.atpages.jp/~autonomydoll/game/RPGClient.zip

クライアントからサーバーに要求を送って、サーバーから要求を受け取るような機能を付け加えたいんだが、どういう設計にすればいいかわからない。定石みたいなのがあったら教えてほしい。

今のクラス構成
ScreenManger-->ScreenGame-->Title
　　　　　｜　　　　　　　　　　　　　　　 |->Main-->Map -|
　　　　　｜　　　　　　　　　　　　　　　　　　　　　-->Unit--->sprite--|
　　　　　｜--------------------------------------------------------------->GraphicsWarpper

**名前は開発中のものです。** · 2009/07/15(水) 22:40:07

WinAPI使ってるなら、WiｎSockで送信して、ウィンドーメッセージで受信する。他はｼﾗﾈ。

**名前は開発中のものです。** · 2009/07/15(水) 22:41:36

>>516
> ScreenManger

画面飼槽

> GraphicsWarpper

グラフィックスワープ装置

何が言いたいのかさっぱりわからないのだが。

**516** · 2009/07/15(水) 22:46:53

>>517
忘れてました。
net frameworkを使ってます。

>>518
ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます

GraphicsWarpperは単なるラッパーです。

**名前は開発中のものです。** · 2009/07/15(水) 22:57:45

こんな面白い難読化もなかなかないな

**名前は開発中のものです。** · 2009/07/15(水) 23:01:47

>>519
> net frameworkを使ってます。

.NET Framework を勝手に先頭のドットを省略したり、勝手に小文字に変えたりするなよ・・

> ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます

それならMangerではなくManagerだろ。

> GraphicsWarpperは単なるラッパーです。

それなら、WarpperではなくWrapperだろ。

小学校は夏休みなのか・・
せめて中学生になってからにしてくれ

**名前は開発中のものです。** · 2009/07/15(水) 23:14:16

>>521
すまん。スペルミスった・・・。

**名前は開発中のものです。** · 2009/07/16(木) 01:35:23

まず日本語と英語を勉強するべきでは？
そうじゃなくても、変数名などを略すのはやめた方がいい、複雑なコードになると対応できない
自分はdeleteHandCardListみたいな長い名前つけたりするけど、困ることは１つもないね

ちなみに件の話に関しては書籍があるよ
GameDeveloperのオンラインゲームの青本
MMORPGを作る赤本もある
2chで説明すると1スレ使っても無理だと思う

**名前は開発中のものです。** · 2009/07/16(木) 02:06:03

>>523
ありがとう。
それをあたってみる。

**名前は開発中のものです。** · 2009/07/16(木) 02:29:30

質問の内容と関係ない単語にしかつっこめない奴が多くてﾜﾗﾀ

**名前は開発中のものです。** · 2009/07/16(木) 05:49:13

2～3人で多いのか、寂しい生活してるんだな

**名前は開発中のものです。** · 2009/07/16(木) 10:25:09

言われて悔しいならもっと勉強しろよ

**名前は開発中のものです。** · 2009/08/14(金) 18:57:02

コミケの影響で最近来なかったここを再び覗くように。変なテンションダァ･･･

>>395
395以前のまとめ

>>404,406-407
シーン遷移考え方

>>408-413,416-425
シーン遷移実装サンプルと問題点。

>>427-433
0からSTGの作成を考える。
根本的な勘違いや非効率的なことがあるのであまり参考にはならない。

>>437-443
オブジェクトと座標管理

>>444-456
オブジェクトと衝突判定と全体効果

>>459-465
デバッグ用処理を考える。(衝突判定表示とか)

>>501-511
DirectXのデバイスの管理とか使い方

>>523
ネットワーク機能参考図書紹介

**名前は開発中のものです。** · 2009/08/14(金) 19:24:51

STGのビジュアル関連向上に関するメモ。
･･･あんま設計と関係ないな･･･

それっぽい弾の作り方
・コマは2コマは以上用意して、画像の色を通常っぽいのと白っぽいのにする。アニメは4コマあればきれい。
・ケイブっぽい弾を作る場合。1コマ作った後、コピーして1ドットぐらい前後ずらし、形を適当に修正。明るい部分はなるべく中心に近づくよう修正。
・円形の回転する弾の工夫。わざと中心から斜めに1ドットずつずらす。

ちょっと光ったエフェクトとか。
・メイン画像と残像(というか残光)画像を用意。後は適当に残像表示の要領で重ね描画。
・センコロのブーストエフェクト。適当な○画像をブースター付近から扇子状に放射するだけ。それっぽいブーストグラフィックが得られる。

弾やエフェクトはポーズ連打して見てみたりすると、プログラムと画像をうまく考えれば誰でも作れるものが多い･･･気がする。

**名前は開発中のものです。** · 2009/08/14(金) 22:21:56

>>529
設計というよりは演出(エフェクト)の話でしょうか。
もし続けるなら専用のスレを立てた方がよいと思われ。

**名前は開発中のものです。** · 2009/10/05(月) 01:40:33

シミュレーションやRPGで
経営状況や主人公の内部パラメータと呼ばれる
データ群がごっそりあると思いますが，
そういったものの管理は
実際のゲーム開発でどういった形でなされるものですか？

データクラスを作ってアクセッサで操作を許す？
それとも，すべてグローバル変数で持たせる？

**名前は開発中のものです。** · 2009/10/05(月) 04:33:25

シングルトンクラスのオブジェクトをグローバルに定義する

**名前は開発中のものです。** · 2009/10/05(月) 07:34:29

SQLiteとか使って手抜くってのもあり

**名前は開発中のものです。** · 2009/10/14(水) 22:12:56

グローバル変数はありえない。データクラス。
ただ、データの表示とかはいつも頭を捻らすなぁ。

**名前は開発中のものです。** · 2009/10/15(木) 07:50:05

アクセッサ書くのめんどいだろ

**名前は開発中のものです。** · 2009/10/15(木) 08:41:22

なんでそんな両極端なの？

**名前は開発中のものです。** · 2009/10/15(木) 15:54:18

0と1しか無いからな
オタクの頭ん中は

**名前は開発中のものです。** · 2009/10/15(木) 20:13:55

別に両極端で構いません．
意見を頂けるだけで嬉しいです．

むしろ噛み付くほうが迷惑です．

**名前は開発中のものです。** · 2009/10/15(木) 22:16:10

使う人がデータを把握できてるなら好きにすればいいんだよ。
質問は実際のゲーム開発だから、面倒でも形式的にやるしかないんじゃない。

**名前は開発中のものです。** · 2009/10/15(木) 22:18:05

>>535
アクセッサ書くのめんどくさいって言ってたら
コーディングが意味不明になってやる気をなくす自信がある。
実際それで何回も挫折した。分かりにくくなるくらいならメンドイ方がマシ。

**名前は開発中のものです。** · 2009/10/15(木) 23:29:40

俺は変数に直接アクセスでも分かりにくいと思わないし。
アクセッサ書くのもめんどくさいとは思わない。

**536** · 2009/10/16(金) 00:35:50

>>538
悪い、噛み付くとかそういうつもりは無かった。
普通に設計して、グローバルにアクセスする必要があるデータを持ってるクラスだけ
Facade経由でアクセスできれば良いんじゃないかと思っただけ。
グローバル変数はさすがにあり得ない…

**名前は開発中のものです。** · 2009/10/16(金) 01:18:33

２ｃｈで素直に謝られると逆に困ります．
参考になりました，ありがとうございます．

**名前は開発中のものです。** · 2009/10/16(金) 01:38:32

グローバル変数を利用側が直接更新したり参照したりするのはアウトだけど、
スタティックグローバルな変数を、何らかのアクセス関数を通して更新/参照するような設計は普通だと思う。

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

て感じで、結局データを引数で取る形になるから、クラスで実装して方がいいんじゃないかと思う。

**名前は開発中のものです。** · 2009/10/16(金) 06:29:56

代入の時などに別の処理を入れるんでなければ
変数を直接弄るんでもいいかな・・・。

**名前は開発中のものです。** · 2009/10/16(金) 11:40:43

入力値の正当性をチェックしたり、同時に変更しなければならないパラメータが1つじゃなかったり、
そういう可能性を考慮すると、関数を経由させたほうが便利。

**名前は開発中のものです。** · 2009/10/16(金) 20:07:25

アクセッサ経由だとバグっぽい動きも引っ掛けやすいが、
そうでないと大変そうだな。デバッグ一件で1時間とか悩みたくないし。

**名前は開発中のものです。** · 2009/10/18(日) 12:51:59

>546
確かに使い方を間違えるってのはよく起こる

**名前は開発中のものです。** · 2009/10/25(日) 23:29:18

Compositeをゲームのシーン管理に使うのってどうやるんですか？
次に来るシーンを各クラスに設定しておいたりとか・・？

**名前は開発中のものです。** · 2009/10/25(日) 23:57:46

何を聞いてるかがちょいと分からないけど
Gems5巻にいいのが載ってたと思うよ。
とりあえず Google [スタックベースのシーン管理 gems]。

**名前は開発中のものです。** · 2009/10/26(月) 00:08:52

というか前スレの260あたりか。Compositeかどうかも微妙だな。ｽﾏｿ

**名前は開発中のものです。** · 2009/11/16(月) 14:29:49

>>501
その後どうなった？
俺も今描画周りを考えてる

**名前は開発中のものです。** · 2009/12/13(日) 15:40:07

よく読んでないけどEmptyProject風に

void Create(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki = new Jiki();
jiki->Create(lpD3DDEV);
}

void Draw(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki->Draw(lpD3DDEV);
}

って風にやったら問題あるの？

**名前は開発中のものです。** · 2009/12/14(月) 01:36:46

deviceの作成は一箇所のクラスでシングルトン
device呼び出しが長くなるが、面倒なら#define
俺はこんな感じ

無知なんだけど、デバイスて何個も必要になることあんの？

**名前は開発中のものです。** · 2009/12/14(月) 01:57:52

デバイスが複数あったら複数必要なんじゃね。

**名前は開発中のものです。** · 2009/12/14(月) 03:13:37

その複数てのがさ、動的に管理しないといけないものなら複数個保持するクラスにすればいいし
そうでないなら同じようなクラスを用意するかな

便利だからグローバルにしてるわけだし
仕方ないとおもってる
必要な関数ごとにデバイス渡すとか面倒すぎる

まあ、何十個もデバイスがいるわけじゃないからできる荒い方法ではあるんだけどな

**名前は開発中のものです。** · 2009/12/14(月) 11:05:57

ボンバーマンを拡張して繋がれてるコントローラの数だけ
プレイヤーが増えるとかいった仕様にしたいなら
コントローラのデバイスは動的に管理した方がいいと思う。

**名前は開発中のものです。** · 2009/12/14(月) 14:08:44

プレイヤが一人でも全てのコントローラで操作できるようにしているが
（左右同時に押された場合は後からの入力を優先）
コントローラが壊れて常に右側に入力があるみたいな状態になるとうざったそうだな

**名前は開発中のものです。** · 2009/12/14(月) 15:35:13

壊れたコントローラーはサポートしなくてもいいと思うよｗ

**名前は開発中のものです。** · 2009/12/21(月) 22:25:25

sharedptrみたいなの実装したいのですが、
それらしいことがのってる
more effective c++と、Accelarated C++
のどちらの本が役立ちそうでしょうか？

boostソース読めってのは無しでお願いします。

**名前は開発中のものです。** · 2009/12/21(月) 23:10:45

>>560
「スマートポインタ」でググれば解説もサンプルも見つかるよ。

**名前は開発中のものです。** · 2009/12/22(火) 01:26:27

>>560
なんで boost::shared_ptr 使わないの？

**501** · 2009/12/30(水) 05:37:23

>>552
描画スクリプトっぽく進めてる。>>510 の言うとおりの方法。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？
描画スクリプトみたいなのを作るほうがプログラム構造は単純になった。
>>511に書いたやり方は結局デバイスアクセス処理が分散していて大して煩雑さは改善されなかった。

簡単な2Dゲームだと描画は大部分が画像描画コマンドだけで構成されてた。思ってたより単純。
あとは少ないながらもカメラ位置変更コマンドと文字列描画コマンドも使った。

コマンド構造体を配列に突っ込んでカウンタを+1とかしてコマンド列（描画スクリプトみたいの）を作ってる。
あと画像描画コマンドでは描画すべき画像は番号で指定してる。番号に対応する画像を用意するのは解釈側の責任。
デバイスデータの引き回しはなるべく避けたかったので。

デバイスを関数間で無闇に引き回さなくても済むようになったので気が楽だし、
メモリデータの変更だけで描画内容が変わるのもおもしろい。
やって良かったと思ってる。

**501** · 2009/12/30(水) 22:40:42

>>563を読み返したらちょっと違うところがあったので訂正。引用したこの文。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？
自分の場合、描画スクリプトを作るのは「各オブジェクト」というより「各シーン管理オブジェクト」になった。

つまり
シーン管理オブジェクトが自身の所有する各オブジェクトの情報をアクセサ経由で読み取って
描画スクリプトみたいなものを組み立てる。

たくさんある細かい各オブジェクトに描画スクリプト的なものを作成させるのは責任というか依存性が散らばりすぎて複雑になる。
だから数の少ない管理オブジェクトがconst修飾済みの読み取り専用オブジェクトから得た情報だけを元に描画スクリプト的なものを組み立ててる。

**名前は開発中のものです。** · 2009/12/31(木) 08:32:52

sqliteを組み込んで、画像やモデルを相互変換可能な名前/IDで管理するとか夢が広がるわな
内部で使うのは番号(ID)だとしても、人間にとっては名前の方が分かりやすいし

**名前は開発中のものです。** · 2009/12/31(木) 15:10:35

>>565
Google App Engine+Flash(Flex)でノベルもどき作ってるけど、まさにそれやってるわ。
GaeなんでsqliteじゃなくてGoogle Big Table使ってるけどね。
スクリプトはForthベースの俺々スクリプトだけど、
SilverlightだとPythonやRubyエンジンが使えるので、
次作るときはそっち使おうかなと思ってる。

**名前は開発中のものです。** · 2010/01/04(月) 06:09:33

おおー、ゲームのバックエンドサーバーにもGAE使う時代かｗ

たしか、mixiアプリのモバイルゲームでGAE使った事例があったな。
3000万PV/月をかなり安価で乗りきれるとか

Togetter(トゥギャッター) - まとめ「100万PV／日のmixiアプリモバイルをGoogle App Engineで実装した@gclue_akira氏に直撃インタビュー」
http://togetter.com/li/494

すれ違いの話題になるが、昨今のネットが絡むゲームの場合バックエンドの技術も必要だけど、
そういう話題を扱ったスレってないものかな
この板にネットゲームの開発時代が少ないみたいだから、需要はないのかもだけど

まーGAEならWebProg板のAppengineスレ行けばいいしな

**名前は開発中のものです。** · 2010/01/04(月) 06:10:39

x 開発時代
o 開発自体

**名前は開発中のものです。** · 2010/04/20(火) 00:42:02

前スレの最後のほうに出てた描画の話題って結局どうなりました？（928ぐらい）

**名前は開発中のものです。** · 2010/05/11(火) 16:43:34

http://blog-imgs-27.fc2.com/c/h/u/chudoku200/1239712143736s.jpg

**名前は開発中のものです。** · 2010/09/20(月) 21:23:17

アクションゲーム作ってるんですが
どういう風にクラス分けすればいいか悩んでます

MAPクラス
Playerクラス
GameFrameクラスの3つがあって
mainループで

switch(MODE)
{
case TITLE:~~~~;break;
case MENU:~~~~;break;
case STAGE01:~~~~;break;
case STAGE02:~~~~;break;
.
.
.
}

みたいなことをしています。
各Stageに行くたびに、ステージ前処理と、ステージ後処理をしたいです
というとコンストラクタとデストラクタ……つまりはクラスを使えばいいんじゃないか？
という感じなのですが

Playerクラスの持っている情報と、操作関連を上手く融合させたり
Mapクラスの持っている情報と、Playerクラスを上手く組み合わせたりが出来ません……

こういう部分はどういう風にデザインするのがいいのでしょうか

**名前は開発中のものです。** · 2010/09/21(火) 03:43:33

STAGE01とSTAGE02を分ける必要は無いだろ。
ファミコンの「ドラえもん」みたいな、1面と2面で全く違うゲームになるなら別だけど。

**名前は開発中のものです。** · 2010/09/23(木) 17:38:03

まずそのswitch文をなんとかしよう。
TitleクラスとMenuクラスとStageクラスを追加するとか。
その上で、StageをPlayerとMapのメディエータとして実装する、というのはどうだ？

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

>>571
貴方は俺か
クラス名と悩みが殆ど同じとかｗ

**名前は開発中のものです。** · 2010/12/04(土) 14:39:29

>>571
ちょっと難しいかもしれないが
ttp://marupeke296.com/GDEV_main.html
ここはかなり参考になる気がするよ。サンプルもあるし。
その6とその7ね。

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

保守

**名前は開発中のものです。** · 2011/05/20(金) 08:10:28.28

良スレ保守

**名前は開発中のものです。** · 2011/08/02(火) 05:21:50.11

Android開発でのパフォーマンスTips
http://labs.techfirm.co.jp/android/cho/1283
http://labs.techfirm.co.jp/android/cho/1293

オブジェクト生成は避ける
インターフェースは使わない
スタティックメソッドを使う
クラス内部でgetter/setterは使わない
foreachループは気をつける

携帯端末だとオブジェクト指向をある程度捨ててパフォーマンスを稼ぐって形が
求められるみたい
こういう環境のゲームは、どういうデータ構造・クラス設計を採用すべきかってのも
気になるな

**名前は開発中のものです。** · 2011/08/02(火) 12:43:43.47

iアプリを思い出すなーｗ

**名前は開発中のものです。** · 2011/08/04(木) 13:31:14.84

PS時代のゲーム開発みたいだなｗ
あの制限ばかりの時代を経験した世代の方が
開発に向いていたりしてｗ

**名前は開発中のものです。** · 2011/08/09(火) 01:57:38.36

処理能力を操作に割かせるためにメモリに読めるだけ読むのかな

**名前は開発中のものです。** · 2011/08/09(火) 20:19:58.06

それやりすぎるとアプリの切り替えをすることが多いスマフォじゃ
面倒が起きやすいんじゃないか

**名前は開発中のものです。** · 2011/08/15(月) 07:32:13.82

>>19
消えてるみたい
どこか掲載されるサイトしらない？

**名前は開発中のものです。** · 2011/08/21(日) 15:33:02.73

こないだ色々探したんだけど、糞アフィブログのリンク記事しか見つからなかった
キャッシュとかも見たんだけどさ

**名前は開発中のものです。** · 2011/09/04(日) 02:30:22.85

>>580
そうかもしれない。
その世代が今のゲーム現場で老害化してるんでむしろ行って欲しい。

**名前は開発中のものです。** · 2011/12/29(木) 00:00:54.00

よさげなスレなのに、あまり話が盛り上がってないな・・・

RPGのクラス設計で、「CharacterがItem（複数）を持っている」
状態を表したい時、
昔の自分は、
class Character {
　　List<Item> inventory;
}
って書いていたけど、最近の自分は、
class Inventory {
　　static List<Item> itemList;//全キャラクター分のアイテムを格納
　　Character character;
　　public int Count { get { itemListを数えて返す } }
　　public Item this[int no] { get { itemListのno番目を返す } }
}
class Character {
　　Inventory inventory;
}
って書くようになった。
どっちの書き方が多数派なのだろう？

**名前は開発中のものです。** · 2011/12/29(木) 00:30:31.32

そこまでいったら、Interface抽出までやるかなー。

**名前は開発中のものです。** · 2011/12/29(木) 11:43:29.12

インタフェース抽出・・・
こんな感じ？

interface IGameData<T> {
　　int Count { get; }
　　T this[int no] { get; }
　　void Add(T arg);
　　void Remove(T arg);
}
（ジェネリックの書き方は適当ですｗ）

class Inventory : IGameData<Item> {
　　static List<Item> itemList;//全キャラクター分のアイテムを格納
　　Character character;
　　public int Count { get { itemListを数えて返す } }
　　(ry)
}

**名前は開発中のものです。** · 2011/12/29(木) 15:58:30.64

たぶんそんな感じー

**名前は開発中のものです。** · 2012/01/09(月) 19:11:25.37

>>588
なんでitemList がstaticなんだ

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

プログラム自体全くの素人なんで
取り敢えず3D空間上に地面を作ってその上をキャラクタが歩き回れるプログラムを作ったんだけど
地面を生成する際に必ず必要になる地面の各頂点の座標だけで1面につきfloat1つ分で4byte取られるんだよね
そこでふと思ったんだけど
エルダースクロール2ってどうやってそこらへんの情報を扱ってるんだろ
あのゲームのマップの大きさを計算してみたら一辺317Kmもあるみたい
1面を5m四方として扱ってもマップ全体を表すのに16078240000byteも必要
エントロピー圧縮しても1/15位が限界だと思うから約1GB
本当はこれらにさらに木や草の位置、地面のテクスチャの種類なんかが必要なんだよね
それなのにtes2のデータサイズを見ると160MBしかない
何かマップ設計自体が特殊なんだろうか

**名前は開発中のものです。** · 2012/01/10(火) 01:20:07.70

常にそのデータをメモリ上に保持しておかなければいかんわけじゃないだろ……

100km先のデータなんて近づいてきたら読めばいいじゃない

**名前は開発中のものです。** · 2012/01/10(火) 02:51:27.11

floatじゃなくてhalf floatなのかもしれん。これだけで半分になる。

あとは、エントロピー符号化の前に、
曲面補完とか使って圧縮かけてるのかもしれない。
ビットマップで曲線を保持すると解像度分のデータが必要だが、
ベジェ曲線なんかで表せば、上手くいけばハンドル数個分で済む。
FUELなんかはたぶんこういう方法使ってて、川が途中で途切れてたりするところが目立つのはそのためだと思う。

全部俺の勝手な予想だが、いろいろ工夫はしてると思うよ。

**名前は開発中のものです。** · 2012/01/10(火) 20:26:05.97

>>590
ん、ごめん。判りにくいな～と思いつつ手抜きしてしまった。
こんな感じのコーディングを想定していました。

class Inventory : IGameData<Item> {
　　static List<Item> itemList;
　　//クラスメンバ
　　Character character;
　　//プロパティ
　　public int Count { get {
　　　　int num = 0;
　　　　for(int i = 0; i < itemList.Count; i++) num += (itemList[i].Character == this.character)? 1 : 0;
　　　　return num;
　　} }
　　public Item this[int no] { get {
　　　　for(int i = 0; i < itemList.Count; i++) if (itemList[i].Character == this.character) if (--no < 0) return itemList[i];
　　　　throw new Exception();//noがオーバーしてたら例外（とかreturn null;とか）
　　} }
}
class Item { public Character Character; }
class Character { Inventory inventory = new Inventory(this); }

結局、呼び出す側からの見た目は、
class Inventory : List<Item> { }
class Character { Inventory inventory = new Inventory(); }
とあまり変わらないんだけどね・・・

**名前は開発中のものです。** · 2012/01/10(火) 22:24:32.24

>>592
そういう問題ではないんだけど、マップの構造設計を考えるとそこも考えなきゃいけないと思う

>>593
ベジェ曲線・・・確かに全く別のアプローチ方法で面白いかも・・・
ベジェ曲線を3次元で表現するのかX、Yどちらかに絞って高さだけを表現するのか
ただそうするとどのタイミングでどこの情報を取ってくるかが問題になるのかな
単純に複数の面(25個ずつくらい)をまとめた構造体で管理してたんじゃベジェ曲線の利点が薄まる？
もう少し調べてみます。アドバイスありがとう

**名前は開発中のものです。** · 2012/01/10(火) 23:12:32.40

>>595
以前、フラクタルで地形を作成するプログラムを書いたことがあるけど、
動的にマップデータを生成するのはどうだろう？
ランダムシードを固定値で持っていれば、再現性もあるかと思うし。

**名前は開発中のものです。** · 2012/01/10(火) 23:17:34.89

言葉足らずすぎる気がしたので補足ｗ

広い領域を、例えば５キロ平方に区切って、
隣の領域と連続性を保つため外周だけはデータを保持。
その内側の凹凸は動的生成、って意味です。

**名前は開発中のものです。** · 2012/01/11(水) 01:47:31.95

>>596
それ単独では制御が難しいかも。町を作りたいのに平らな地形が得られない、とか。
平らな地形の部分だけ追加データで入れるとかするのかな。

>>595
線→面への拡張は、概念はそんなにフクザツじゃない。
補間方法はベジェじゃなくてもスプラインでもいいけど、単純にXY両方でデータの無いところを補間するだけだと思う。
ただ当然実行時計算量とデータサイズのトレードオフはある。

TES2は分からんけど、TES4と同系統のエンジンのFO3なんかみると、
たまにそういう曲面のエッジが誤差か調整不足かで浮いてるところがマップのところどころにあった気がする。
これは曲面補間かどうかは分からないけども。
SourceEngineなんかも似たような技術が実装されてるし、けっこう昔からある技術なのかな？
Game Programming Gemsとか探したら取り上げられてるかもね。

**名前は開発中のものです。** · 2012/01/13(金) 08:38:17.24

>>598
なるほど、ってことは、
街の地面：整地されてるから、メッシュを大きく平らに
平原とか砂漠とか：メッシュを大きく取って、細かい部分は補間なり動的生成なり
山岳みないな凹凸がある地形：メッシュを細かく
って感じに・・・
（と言っておいてなんですが、メッシュの大きさを変えるのは、プログラムが汚くなりそうｗ）

**名前は開発中のものです。** · 2012/01/13(金) 23:38:29.70

>>599
偏った例で恐縮だけど、SourceEngineのディスプレースメントサーフェイスは
分割数は2,4,8とか2の倍数固定でそれほど柔軟ではないし、穴あけれないとか制約はある。
だからその辺はレベルデザイナーのほうで調節する感じ。
ただしスムージングはかけれるから、たぶん補間はしてる。
たぶんゲームエンジンはどれも似たような仕組みは実装してると思うよ。
ディスプレースメントなら頂点4つ(△ポリゴン2つ)＋差分テクスチャマップをシェーダーにぶち込んで高速処理、とか
そんなんだと思う。
あくまで予想だけど！

**名前は開発中のものです。** · 2012/06/10(日) 17:27:25.03

特定の条件がなんなのか不明だけど、eventListenerとかgetInputとかで良いんじゃないの
設計としてはおかしくはない

**名前は開発中のものです。** · 2012/06/10(日) 17:28:33.69

誤爆失礼

**名前は開発中のものです。** · 2012/10/13(土) 15:00:59.36

保守

**名前は開発中のものです。** · 2014/08/05(火) 01:15:42.94

タイル形式の箱庭データ配置ってどう思う？
メモリーが少なかった頃の遺物？
高速化のために未だに使う事ってある？

**名前は開発中のものです。** · 2014/08/05(火) 12:28:28.50

良くも悪くもゲームが記号的になるね

**名前は開発中のものです。** · 2014/08/18(月) 17:56:46.58

Androidでゲームを作ってるんですが、クライアント・サーバー型のゲームのデータを
データベースで管理しようとすると武器の名前とかいらないと思って、端折りまくってたら
武器のIDだけのテーブルになってしまいました。(パラメータはクライアントで持ってます)

ここまでくるとテーブルとして参照するだけcpuの無駄だと思い、
テーブルを消していくと他のテーブルと全く関わり合いのないテーブルが出てきます。
（例えば武器を売った時にいくらお金が手に入るか？とか）

そうすると何か自分の考えてる構造に不安を覚えるのですが、これは正しいのでしょうか？
「データベースの外とリレーション貼ってる」って考えれば自分を納得させられるような気もしないんですが・・

**名前は開発中のものです。** · 2014/08/18(月) 18:09:33.31

砂漠とか海の3D空間で遠景を表現するのってどうすればいいですか？

地平線とスカイドーム（スカイボックス？）の切れ目が不自然になって、
ちょっとでもカメラのY座標を高くすると地面の切れ目もはっきり目立ちます。
fogは遠くのオブジェクトも見たいのであまりしたくありません。

http://livedoor.blogimg.jp/terashima999/imgs/1/3/1321e840.jpg
http://yoda.dip.jp/Diary/200707/20070711_AC6_1.jpg
↑こういうの

**名前は開発中のものです。** · 2014/08/23(土) 15:13:29.78

>>607
LOD(level of detail)を使って遠くまで描画すればいいと思う。
ちょっと古い記事だけど下記のサイトが参考になるんじゃね？

3Dゲームファンのための「ワンダと巨像」グラフィックス講座
http://game.watch.impress.co.jp/docs/20051207/3dwa.htm
の「■地形のLODシステムと読み込み」の項目

**名前は開発中のものです。** · 2014/08/23(土) 18:35:40.53

なるべく地平線や水平線の近くまで描画したいんでしょ？
自分の場合は

　　　　／￣￣￣＼
　　／：　　　　　　：＼
　／： .：　　　a　　.： .：＼
￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　↑↑
　　　　　　　　　　　b　c
a：視点の位置
b：フォグの開始
ｃ：フォグの終了

空は角錐台状につくってaのxy座標に追従
bを遠くにとれば遠くまで描画できるし、
空の天辺がフォグで霞むこともなくなる。

**名前は開発中のものです。** · 2014/08/24(日) 14:20:41.69

>>609
視点のY座標が高くなると、地平線と空の間に描画されない部分が出てきてしまいます・・