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

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

保守

良スレ保守

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

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


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

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

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

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

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

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

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

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

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

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;
}
って書くようになった。
どっちの書き方が多数派なのだろう？

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

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

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

たぶんそんな感じー

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

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

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

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

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

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

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

>>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(); }
とあまり変わらないんだけどね・・・

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

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

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

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

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

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

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

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

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

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

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

誤爆失礼

保守

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

ちょっと修正


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

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

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

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