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

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

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

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

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

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

**名前は開発中のものです。** · 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座標が高くなると、地平線と空の間に描画されない部分が出てきてしまいます・・

**名前は開発中のものです。** · 2014/08/25(月) 00:41:57.10

あぁXZ座標か。兎に角視点の高度はに角錐台は影響されない方向で。

**名前は開発中のものです。** · 2014/08/26(火) 13:52:23.48

いや、角錐台は影響されないんですけど、
aが立ってる地面とかは高度上げれば上げるほど離れていくわけじゃないですか
そうすると地面のポリゴンと角錐台がどんどん離れていって
地面のポリゴンの終端があらわになってしまいます。
街を探検するようなゲームなら全く問題ないんですが
海とか航空機とかで「地平線を表現したい」となった時にfogにも頼れず（霞ませたいわけじゃない）どうしたものかと・・・

LODで全力で軽量化しつつ、XZ座標1000000,1000000とかすごい桁のパラメータで遠くに設置してもいいんですが、
カメラのトリム距離もネックになってて、それだけの距離を1.0~0.0に収めると浮動小数点型の誤差？なのか、
遠景のZバッファによる描画が不自然になります

近景用と遠景用で2回判定してもいいんですが（通常ポリゴンとLODポリゴンで分けられたら一石二鳥かも）
なんだか王道から離れていってるようで、他の人がどう対処してるのかなと

**名前は開発中のものです。** · 2014/08/26(火) 21:43:36.70

　　　　／￣￣￣＼
　　／：　　　a　　：＼
　／： .：　　　　　.： .：＼
　　　￣￣￣￣￣←地面が小さいの？

地面をフォグの終了まで描画すればいいと思うけど…

**名前は開発中のものです。** · 2014/08/27(水) 17:08:35.72

ぢめんをちきゅうみたいにまるくするのはどう？

**名前は開発中のものです。** · 2014/08/28(木) 17:39:54.03

>>613
ということは、607の下の画像みたいなのは建物を思いっきり縮小してるんですかね？
上の画像はすごいきれいに水平線が見えますけど

**名前は開発中のものです。** · 2014/08/28(木) 21:14:49.09

上のは船上だから視点は高くても数十ｍ。水平線は結構近いと思うよ。

下のは数kmとかじゃないかな。建物を縮小というか単純に距離が離れてると思うけど…
それでもフォグを使って描画範囲を制限して、描画対象を削減してる。

**名前は開発中のものです。** · 2014/08/29(金) 17:47:40.60

>>616
今実際に水平線を描画してみたんですが、遠くの船が空中に浮いてるように見えます
海面の描画外で船を描画するとスカイドームの背景が船底より下に描画されます

海面にかけるフォグ色とスカイドームに貼り付けるテクスチャの水平部分に
同じ色を使っていい感じにごまかせないか試してみたんですが、
海面の上から船底が描画されるのでやっぱり違和感があります

**名前は開発中のものです。** · 2014/08/29(金) 22:39:55.32

船を描画するときフォグは無効にしてるの？

船全体がフォグの終了の向こうに出るまでは、フォグを有効にして船を描画。
向こうに出たら描画そのものをスキップしないとダメだと思うよ。

**名前は開発中のものです。** · 2014/08/30(土) 08:34:58.97

>>617
船のモデル側に海面ポリゴン（船底を隠す分だけ）をくっつけとけば、いいんじゃね？

**名前は開発中のものです。** · 2014/08/30(土) 11:22:17.06

>>618
海面は有効にしてますが船は有効にしてません
そもそもフォグをかける理由はスカイドームに描かれた海面と同色にして
違和感なく水平線を再現したいって理由なので
ある距離で突然船が消えるようなのは無理です

>>619
それだと嵐とかの表現で大波とか拡張したくなった時とか、
動的な表現に耐えられないような・・・
フォグとスカイドームの間だから単色の板ポリで動的に隠すことも出来なくはないかも

**名前は開発中のものです。** · 2014/09/01(月) 07:02:26.23

状況が良くわからないけど、こういうこと？

＿目＿＿＿＿空
＿＿視視＿＿空
＿＿＿＿視視空
＿＿＿＿＿＿海視
＿＿＿＿＿＿海＿視視
＿＿＿＿＿＿海＿＿＿視視＿＿＿＿＿＿＿＿＿浮船
海海海海海海海海海海海海海海海海海海海海海海海海ー水平な水平線
＿＿＿＿＿＿＿＿＿＿＿＿＿＿視視
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿視視
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＼
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿見た目の水平線

**名前は開発中のものです。** · 2014/09/01(月) 07:04:40.93

ちょっと修正

＿目＿＿＿＿空
＿＿視視＿＿空
＿＿＿＿視視空
＿＿＿＿＿＿海視
＿＿＿＿＿＿海＿視視
＿＿＿＿＿＿海＿＿＿視視＿＿＿＿＿＿＿＿＿浮船
海海海海海海海外外外外外視視外外外外外外外外外外外ー水平な水平線
＿＿＿＿＿＿＿＿＿＿＿＿＿＿視視
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿視視
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＼
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿見た目の水平線

**名前は開発中のものです。** · 2014/09/06(土) 11:55:58.35

http://i.gyazo.com/ab7ac366b1f7133d16273b35ef24044c.png
浮いて見える？

**名前は開発中のものです。** · 2014/09/20(土) 12:54:30.99

>>623
海面のポリゴンより遠い所で船を描画すれば
船底が見えて海面から浮いて見えるね

洋ゲーとかの遠くに見える空母とか戦艦ってどうやって表現してんだろうね

**名前は開発中のものです。** · 2015/03/16(月) 18:52:45.04

すごい大雑把な質問なんだけど
ゲーム設計において外部ライブラリの扱いってどうやるの？
ひとつだけならそれに従えばいいかもだけど複数になるとどうしても設計が汚くなってしまう

**名前は開発中のものです。** · 2015/12/19(土) 14:31:11.96

プログラマはMacを使ってるってマジ？
http://hayabusa3.2ch.net/test/read.cgi/news/1450395043/

**名前は開発中のものです。** · 2017/12/31(日) 20:22:02.22

簡単にお金が稼げる方法興味ある人だけ見てください。

グーグル検索⇒『来島のモノノリウエ』

A8RNONREKQ