ゲームにおけるデータ構造・クラス設計・パターン2
■ このスレッドは過去ログ倉庫に格納されています
具体的なゲーム名を挙げて、 どのようにクラス設計をすればよいか、 継承・委譲関係はどのようにすればよいか、 使えそうなパターンは何かなど語るのもよし。 自作ゲームの内容とクラス図を書いて 改善案を聞くもよし。 設計に関して困ったことを質問するもよし。 関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。 大いに語れ。 前スレ http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/ テンプレ追加事項あったらよろすく Android開発でのパフォーマンスTips http://labs.techfirm.co.jp/android/cho/1283 http://labs.techfirm.co.jp/android/cho/1293 オブジェクト生成は避ける インターフェースは使わない スタティックメソッドを使う クラス内部でgetter/setterは使わない foreachループは気をつける 携帯端末だとオブジェクト指向をある程度捨ててパフォーマンスを稼ぐって形が 求められるみたい こういう環境のゲームは、どういうデータ構造・クラス設計を採用すべきかってのも 気になるな PS時代のゲーム開発みたいだなw あの制限ばかりの時代を経験した世代の方が 開発に向いていたりしてw 処理能力を操作に割かせるためにメモリに読めるだけ読むのかな それやりすぎるとアプリの切り替えをすることが多いスマフォじゃ 面倒が起きやすいんじゃないか >>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); } (ジェネリックの書き方は適当ですw) 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 以前、フラクタルで地形を作成するプログラムを書いたことがあるけど、 動的にマップデータを生成するのはどうだろう? ランダムシードを固定値で持っていれば、再現性もあるかと思うし。 言葉足らずすぎる気がしたので補足w 広い領域を、例えば5キロ平方に区切って、 隣の領域と連続性を保つため外周だけはデータを保持。 その内側の凹凸は動的生成、って意味です。 >>596 それ単独では制御が難しいかも。町を作りたいのに平らな地形が得られない、とか。 平らな地形の部分だけ追加データで入れるとかするのかな。 >>595 線→面への拡張は、概念はそんなにフクザツじゃない。 補間方法はベジェじゃなくてもスプラインでもいいけど、単純にXY両方でデータの無いところを補間するだけだと思う。 ただ当然実行時計算量とデータサイズのトレードオフはある。 TES2は分からんけど、TES4と同系統のエンジンのFO3なんかみると、 たまにそういう曲面のエッジが誤差か調整不足かで浮いてるところがマップのところどころにあった気がする。 これは曲面補間かどうかは分からないけども。 SourceEngineなんかも似たような技術が実装されてるし、けっこう昔からある技術なのかな? Game Programming Gemsとか探したら取り上げられてるかもね。 >>598 なるほど、ってことは、 街の地面:整地されてるから、メッシュを大きく平らに 平原とか砂漠とか:メッシュを大きく取って、細かい部分は補間なり動的生成なり 山岳みないな凹凸がある地形:メッシュを細かく って感じに・・・ (と言っておいてなんですが、メッシュの大きさを変えるのは、プログラムが汚くなりそうw) >>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:フォグの開始 c:フォグの終了 空は角錐台状につくってaのxy座標に追従 bを遠くにとれば遠くまで描画できるし、 空の天辺がフォグで霞むこともなくなる。 >>609 視点のY座標が高くなると、地平線と空の間に描画されない部分が出てきてしまいます・・ あぁXZ座標か。兎に角視点の高度はに角錐台は影響されない方向で。 いや、角錐台は影響されないんですけど、 aが立ってる地面とかは高度上げれば上げるほど離れていくわけじゃないですか そうすると地面のポリゴンと角錐台がどんどん離れていって 地面のポリゴンの終端があらわになってしまいます。 街を探検するようなゲームなら全く問題ないんですが 海とか航空機とかで「地平線を表現したい」となった時にfogにも頼れず(霞ませたいわけじゃない)どうしたものかと・・・ LODで全力で軽量化しつつ、XZ座標1000000,1000000とかすごい桁のパラメータで遠くに設置してもいいんですが、 カメラのトリム距離もネックになってて、それだけの距離を1.0~0.0に収めると浮動小数点型の誤差?なのか、 遠景のZバッファによる描画が不自然になります 近景用と遠景用で2回判定してもいいんですが(通常ポリゴンとLODポリゴンで分けられたら一石二鳥かも) なんだか王道から離れていってるようで、他の人がどう対処してるのかなと / ̄ ̄ ̄\ /: a :\ /: .: .: .:\  ̄ ̄ ̄ ̄ ̄←地面が小さいの? 地面をフォグの終了まで描画すればいいと思うけど… >>613 ということは、607の下の画像みたいなのは建物を思いっきり縮小してるんですかね? 上の画像はすごいきれいに水平線が見えますけど 上のは船上だから視点は高くても数十m。水平線は結構近いと思うよ。 下のは数kmとかじゃないかな。建物を縮小というか単純に距離が離れてると思うけど… それでもフォグを使って描画範囲を制限して、描画対象を削減してる。 >>616 今実際に水平線を描画してみたんですが、遠くの船が空中に浮いてるように見えます 海面の描画外で船を描画するとスカイドームの背景が船底より下に描画されます 海面にかけるフォグ色とスカイドームに貼り付けるテクスチャの水平部分に 同じ色を使っていい感じにごまかせないか試してみたんですが、 海面の上から船底が描画されるのでやっぱり違和感があります 船を描画するときフォグは無効にしてるの? 船全体がフォグの終了の向こうに出るまでは、フォグを有効にして船を描画。 向こうに出たら描画そのものをスキップしないとダメだと思うよ。 >>617 船のモデル側に海面ポリゴン(船底を隠す分だけ)をくっつけとけば、いいんじゃね? >>618 海面は有効にしてますが船は有効にしてません そもそもフォグをかける理由はスカイドームに描かれた海面と同色にして 違和感なく水平線を再現したいって理由なので ある距離で突然船が消えるようなのは無理です >>619 それだと嵐とかの表現で大波とか拡張したくなった時とか、 動的な表現に耐えられないような・・・ フォグとスカイドームの間だから単色の板ポリで動的に隠すことも出来なくはないかも 状況が良くわからないけど、こういうこと? _目____空 __視視__空 ____視視空 ______海視 ______海_視視 ______海___視視_________浮船 海海海海海海海海海海海海海海海海海海海海海海海海ー水平な水平線 ______________視視 ________________視視 __________________\ ___________________見た目の水平線 ちょっと修正 _目____空 __視視__空 ____視視空 ______海視 ______海_視視 ______海___視視_________浮船 海海海海海海海外外外外外視視外外外外外外外外外外外ー水平な水平線 ______________視視 ________________視視 __________________\ ___________________見た目の水平線 >>623 海面のポリゴンより遠い所で船を描画すれば 船底が見えて海面から浮いて見えるね 洋ゲーとかの遠くに見える空母とか戦艦ってどうやって表現してんだろうね すごい大雑把な質問なんだけど ゲーム設計において外部ライブラリの扱いってどうやるの? ひとつだけならそれに従えばいいかもだけど複数になるとどうしても設計が汚くなってしまう 簡単にお金が稼げる方法興味ある人だけ見てください。 グーグル検索⇒『来島のモノノリウエ』 A8RNONREKQ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる