タグ付けされた質問 「objects」

9
PlayerとWorldの間の循環依存関係を回避する方法は?
私は、上下左右に移動できる2Dゲームに取り組んでいます。基本的に2つのゲームロジックオブジェクトがあります。 プレーヤー:世界に対して相対的な位置を持っている ワールド:マップとプレイヤーを描画します これまでのところ、WorldはPlayerに依存している(つまり、参照している)ため、プレイヤーキャラクターをどこに描画するか、マップのどの部分を描画するかを把握するための位置が必要です。 衝突検出を追加して、プレーヤーが壁を通過できないようにします。 私が考えることができる最も簡単な方法は、意図した動きが可能かどうかをプレイヤーに世界に尋ねることです。しかし、それはPlayerとWorldの間に循環的な依存関係を導入します(つまり、それぞれが他方への参照を保持します)。私が思いついた唯一の方法は、WorldにPlayerを移動させることですが、それはやや直感的ではありません。 私の最良の選択肢は何ですか?または、循環依存関係を回避する価値はありませんか?

3
多くのユニークな武器/呪文/力のコードを構成する方法
私は、Pythonを使用してFTLの「ローグライクのような」ゲームを作成する経験の浅いプログラマーです(まだテキストのみを扱っているため、PyGameはまだありません)。 私のゲームには、ユニークな能力を生み出す多数の武器(初心者には約50個)が含まれます。オブジェクトコードを構造化する方法を理解するのに苦労しています(強力な(武器に根本的に異なる効果を持たせることを可能にする)点で)拡張可能な(たとえば、フォルダーにそれらをドロップすることによって後でより多くの武器を簡単に追加できるように) )。 私の最初の本能は、BasicWeaponクラスを持ち、そのクラスから異なる武器を継承することでした。しかし、これは私には問題があるようです:BasicWeaponクラスを基本的に役に立たないようにする必要があります(すべての武器に共通する機能は名前とタイプ(ピストル、aなど)のみです)、またはすべてを予測する必要があります独自の効果を考え出し、BasicWeaponにコーディングします。 後者は明らかに不可能ですが、前者はまだ機能します。しかし、それでは疑問が残ります。個々の武器のコードはどこに置けばいいのでしょうか? plasmarifle.py、rocketlauncher.py、swarmofbees.pyなどを作成し、それらをすべてゲームにインポートできるフォルダーにドロップしますか? または、eval / execに頼らずに、各武器の一意のコードを何らかの形で含むデータベーススタイルのファイル(Excelスプレッドシートのような単純なもの)を作成する方法はありますか? 後者のソリューション(データベース)に関して、私が苦労している根本的な問題は、コードとデータの分離を維持することが望ましいことを理解している一方で、武器が「コード」の境界を曖昧にしているように感じることだと思いますおよび「データ」を少し。それらはゲームで見られる多種多様な類似物を表しており、その意味ではデータに似ていますが、ほとんどの場合、他のアイテムと共有されていない少なくともいくつかのユニークなコードが必要です。コード。 このサイトの他の場所で見つけた部分的な解決策は、BasicWeaponクラスに空のメソッドの束(on_round_start()、on_attack()、on_move()など)を与え、各武器のそれらのメソッドをオーバーライドすることをお勧めします。戦闘サイクルの関連フェーズで、ゲームはすべてのキャラクターの武器に適切なメソッドを呼び出し、メソッドが定義されているもののみが実際に何かを実行します。これは役立ちますが、それでも各武器のコードやデータをどこに配置する必要があるかはわかりません。 ある種のハーフデータ、ハーフコードのキメラとして使用できる別の言語やツールはありますか?優れたプログラミングプラクティスを完全に実行していますか? 私はありません回答いただければ幸いですので、OOPの私の理解では、最高の状態で大ざっぱですあまりにもコンピュータ科学-yと。 編集: Vaughan Hiltsは、下の投稿で、私が本質的に話しているのはデータ駆動型プログラミングであることを明らかにしました。私の質問の本質は次のとおりです。データにスクリプトを含めることができるようにデータ駆動設計を実装し、メインプログラムコードを変更せずに新しい武器で新しいことを行えるようにする方法はありますか。

4
動的なゲームオブジェクトを保存する最も効率的なコンテナは何ですか?[閉まっている]
ここで何が尋ねられているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 7年前に閉鎖されました。 私は一人称シューティングゲームを作成していますが、さまざまな種類のコンテナについて知っていますが、ゲームで頻繁に追加および削除される動的オブジェクトを保存するのに最も効率的なコンテナを見つけたいと思います。元弾丸。 その場合、それはリストであるため、メモリは連続しておらず、サイズ変更が行われることはありません。しかし、その後、マップまたはセットを使用することも考えています。有益な情報があれば教えてください。 ちなみに私はこれをC ++で書いています。 また、私はうまくいくと思う解決策を思いつきました。 まず、大きなサイズのベクトルを割り当てます。たとえば、1000個のオブジェクトを割り当てます。このベクターに最後に追加されたインデックスを追跡して、オブジェクトの終わりがどこにあるかを把握します。次に、ベクターから「削除」されたすべてのオブジェクトのインデックスを保持するキューも作成します。(実際の削除は行われません。そのスロットが空いていることがわかります)。したがって、キューが空の場合、ベクトルに最後に追加されたインデックス+ 1に追加します。そうでない場合は、キューの先頭にあったベクトルのインデックスに追加します。

6
ビデオゲームはどのようにオブジェクト指向ですか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店しました。 私は、ビデオゲーム、特に巨大な3Dプロジェクトでオブジェクトの向きがどの程度使用されているのか、常に疑問に思っていました。両方ともその属性trollをwerewolf継承しenemy、それらの一部を上書きしたのはクールだと思います。しかし、クラスは重すぎて実用的ではないかもしれません。
18 objects 

5
2倍近いオブジェクトは2倍大きく見えますか?
だから、私はあなたがZ軸に沿って動くことができる2Dゲームを作成することを考えていました、あなたがいる層を変えることによって。深度に応じて、2Dスプライトをスケーリングします。 かつて、誰かが私に多くの2Dスプライトを持つデモを見せてくれ、スクロールすることでカメラの深さを変えることができました。そのため、ズームインすると、オブジェクトはプレーヤーに近づき、大きく表示されます。それから、オブジェクトが1ユニット近くになったとき、オブジェクトはどのくらい大きくなるのかと思いました。どのように計算しますか?だから男は私に言った:私が使用している1つの基本的なルールがあります:「オブジェクトは2倍近く、2倍大きく表示されます。」 今、私はそれを自分でテストすることで、ルールが現実の世界に適用されないことを知っています;)しかし、遠近法などのために現実の世界の計算で使用される定数はありますか?または式? これはそのような質問をするのに最適な場所ではないかもしれませんが、これはゲーム関連の質問に使用する唯一のサイトであり、私のコンテキストはゲームなので、試してみると思いました。また、3Dゲームに関連している可能性があるため、3Dの視点とマトリックスなどについてすべてを知っている人がここにいることを期待しています。 tl; dr: 「オブジェクトは2倍近く、2倍大きく表示されます」これは現実の世界では正しくありません。しかし、どの定数または式が正しいですか?

2
Painterのアルゴリズムで正確な結果を得る方法
少し前に、顔が別の顔と重なっていることを判断する方法を尋ねました。アドバイスは、Zバッファを使用することでした。 ただし、現在のプロジェクトではZバッファを使用できないため、Painterのアルゴリズムを使用したいと考えています。しかし、表面がいつ他の表面の後ろまたは前にあるかについての良い手がかりはありません。私は数多くの方法を試しましたが、それらはすべてエッジケースで失敗するか、一般的なケースでも失敗します。 これは私が今まで試したソート方法のリストです: 各面の中点までの距離 各面の各頂点までの平均距離 各頂点の平均z値 各面の頂点のz値を最大化し、それらを最初に描画します 各面の頂点の最小z値とそれらを最後に描画 問題は、顔の距離は近いかもしれませんが、それでも遠いということです。これらの方法はすべて信頼できないようです。 編集:たとえば、次の画像では、青い点がより近いため、青い点を中点とするサーフェスが赤い点を中点とするサーフェス上にペイントされます。ただし、これは、赤い点の表面が大きく、中間点がさらに離れているためです。赤い点のある面は青い点よりも上にペイントする必要があります。なぜなら、中間点の距離は反対であるため、より近いためです。 オブジェクトを描画する順序を決定するために、Painterのアルゴリズムで正確に使用されているものは何ですか?
14 3d  algorithm  objects  face 

4
オブジェクト指向OpenGL
私はしばらくの間OpenGLを使用しており、多数のチュートリアルを読みました。それらの多くがまだ固定パイプラインを使用しているという事実は別として、彼らは通常、すべての初期化、状態変更、および描画を1つのソースファイルにスローします。これは限られた範囲のチュートリアルには適していますが、完全なゲームにスケールアップする方法を見つけるのに苦労しています。 OpenGLの使用をファイル間でどのように分割しますか?概念的には、たとえば、純粋に画面に素材をレンダリングするレンダリングクラスを持つことの利点を見ることができますが、シェーダーやライトのようなものはどのように機能しますか?ライトやシェーダーなどのクラスを個別に用意する必要がありますか?

1
重複しないエンティティをランダムに配置するにはどうすればよいですか?
開発中のゲーム用にランダムに生成された環境を作成しています。で使用OpenGLしてコーディングしていJavaます。 (森を作成するために)私の世界にランダムに木を配置しようとしていますが、モデルを重複させたくありません(2つの木が互いに近すぎて配置されている場合に起こります)。これが私が話していることの写真です: 必要に応じてさらに多くのコードを提供できますが、ここに重要なスニペットがあります。オブジェクトをArrayListwithに保存していますList<Entity> entities = new ArrayList<Entity>();。次に、次を使用してそのリストに追加します。 Random random = new Random(); for (int i = 0; i < 500; i++) { entities.add(new Entity(tree, new Vector3f(random.nextFloat() * 800 - 400, 0, random.nextFloat() * -600), 0, random.nextFloat() * 360, 0, 3, 3, 3); } ここで、それぞれEntityは次の構文に従います。 new Entity(modelName, positionVector(x, y, z), rotX, …
11 opengl  java  objects 

2
オブジェクト指向の方法で在庫を処理するにはどうすればよいですか?
私はオブジェクト指向のアプローチに従ってプレーヤーのインベントリを処理するための最良の方法を考えています。 たとえば、剣と斧は2つの異なるクラスで、どちらも武器から継承しています。武器とポーションもアイテムから継承する異なるクラスです。 理想的には、在庫はアイテムのコンテナーとして実装されますが、それはいくつかの理由で実行できません。したがって、アイテム(スマート)ポインターのコンテナーである必要があります。newとdeleteの呼び出しでコードを制限したくないので、ctor / dtorでニュース/削除するItemWrapperクラスにラップします。 したがって、コードは次のようになります class Sword; class ItemWrapper; //Prepare the long sword. const Sword longSword(...params...); //Declare the inv vector<ItemWrapper> inv; //Add it to inventory inv.push_back(longSword); //compiles if ItemWraper(const Sword&) is defined. このアプローチは、コードの明快さと書きやすさの点で私が思いつくことができる最高のものでした。問題は、ItemWrapperがItemから継承するリーフクラスごとに1つのコンストラクターを必要とすることです(これはたくさんあります)。 これが私の初めての試みなので、知りたいのですが、正しい方向に進んでいますか?またはそれを行うためのより良い方法がある場合(おそらく、非常に多くのコンストラクタを回避する方法)?
7 c++  objects 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.