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

平均的なゲームでは、シーンには数百または数千のオブジェクトがあります。デフォルトのnew（）を介して動的に銃の弾丸（弾丸）を含むすべてのオブジェクトにメモリを割り当てることは完全に正しいですか？ ダイナミックアロケーション用のメモリプールを作成する必要がありますか、これを気にする必要はありませんか？ターゲットプラットフォームがモバイルデバイスの場合はどうなりますか？ モバイルゲームでメモリマネージャーが必要ですか？ありがとうございました。 使用言語：C ++; 現在Windowsで開発されていますが、後で移植する予定です。

17 architecture  mobile  memory-efficiency 

使い捨てテストとして、1週間でUDPを使用した簡単なゲームを作成しようとしたことがあります。それは恐ろしく行きました。 私は早くそれを捨てました。私が抱えていた主な問題は、すべてのプレーヤー/敵/オブジェクトのゲーム状態を古い状態に復元し、プレーヤーがプレイしている時点までゲームを早送りすることでした（つまり、ジャンプの0.5秒前。プレイヤーがジャンプを逃すようにする） たぶん、この方法は最も簡単な方法ではありませんか？私はそれが疑われるが、最初から間違って設計し、2日目の終わりに気付いた。（だから私はあまり勉強しなかったか、そんなに時間を無駄にしなかった） 私自身と他の人にとって、単純なUDPゲームには何が関係し、どのように書くのですか？または、状態を適切に復元する予測問題をどのように解決しますか？ これをCW bcとしてマークします。役立つ答えがたくさんあることを知っています。

17 architecture  networking 

作成するゲームを完了するのに十分な時間がないのに、堅実なソフトウェアアーキテクチャとそれをすべて達成するために良い進歩をすることとのバランスをどのように実現できますか？ 私の個人的な挑戦：今日は効果的であると同時に長期的な思考はいかがですか？さらに、あなたがそれをしている間、あなたは過去5年間使ってきた同じ繰り返しパターンに頼るのではなく、途中で新しいことを学びたいと思うかもしれません？

17 architecture  time-management  development-speed 

私はC＃でお金を稼ぎます。一般的には、その言語で、インターフェイスを使用してすべてを高い天国に切り離します。これはエンタープライズコードでは十分に役立ちましたが、C＃でゲームを作成する際には、基本クラスのデフォルトの動作を定義できるため、継承に向かう傾向があります。でも、かつて「継承よりも作曲を好む」と言っていた建築神に背を向けているように、私はこれを行うのは汚い気がします。私はそれが白黒ではないことを知っていますが、もう少し作業してインターフェイスを使用して、ほぼ同じことを達成できると感じています。 他の人は何をしますか？継承はゲームに適したアプローチですか、または一部のインターフェイスでリファクタリングする必要がありますか？

16 c#  architecture 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 去年閉鎖されました。 機能クリープを有利に使用できますか？ ゲームのプロトタイプを作成するたびに、機能が誤って追加されます。これは、偶然の一致によって発生するか、既存のコンテンツに基づいて簡単に追加できます。 ゲームのジャンルを知っている場合、基本的な仕組みを作り始め、それらが明らかになったら機能を追加できますか？ たとえば、6か月かけて2Dプラットフォーマーを作成したい場合、ランニング、ジャンプ、射撃などを開始し、誤って見つけたコアメカニックを追加できますか？または、これは、事前に計画されていない時間投資のリスクが高すぎますか？ これの背後にある私の論理は、設計が支出に見合ったものになるということです。設計の選択は、作成が簡単なものを中心に（時間的に）より簡単に構築されます。 要約すると、ゲームを設計する前にビルドするのに問題はありますか？

16 game-design  architecture  time-management 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 私は、ゲームに固有の用語の一般的な辞書を探しています（デザインパターンが物事がどのように相互作用するかについて共通の言語を持っているように）。 たとえば、複雑さの高いピンポンのゲームを作成している場合、それに応じて名前を付けたいと思います。 私は、ユーザーがウィジェットと呼ばれる対話可能なビジュアルオブジェクト、doodadと呼ばれる非インタラクティブなオブジェクトを見ました（とにかくスタークラフトマップエディターで遊んだとき）。フレームレートクロックに適切な名前はありますか？ゲームの時計に適切な名前はありますか（時計は世界のオブジェクトの動きに関するもので、視覚的な描画ではありません）？ 辞書が欲しいので、同じ言語を話せるようになります。私は、doodads、whosits、whatsists、flim-flamsと名付けられたものを作成することを懸念しています...そして、私はそれをしたくありません。

16 architecture  design-patterns 

UnityでRPG / RTSゲームを作成しています。多くのキャラクターが存在し、潜在的に多くの異なる環境があります。私はコーディングの部分にかなり自信を持っています（そのため、この質問は実際にはゲームエンジンに関係していません）。音楽も自分で作成します（ソロ作品、バンドでのパッドベースのライブドラム、友人のためのミキシングなど）。したがって、必要なすべてのツールを十分に把握していると思います。しかし、私はゲームのサウンドデザインを作成したことがなく、その方法を本当に理解していません。 サウンドエフェクトをどのように整理して使用しますか？たとえば、5つの異なるキャラクタータイプと3つの異なるグラウンド（草、泥、木など）があるとします。5* 3の足音を作成しますか？サンプルにバラエティに富んだランダムピッチを追加するのは良い考えですか？環境音についてはどうですか—バックグラウンドで起動するメインループを作成しますか、それともゲームレベル全体に実際の音（水、風、木の樹皮の動き、鳥）を配置しますか？ 全体として、私はこのシステムがどのように設計されるべきかをよく理解していないので、この愚かなランダムな質問が多すぎます。誰かが私に何らかのガイドや問題に関する記事へのリンクをくれたらとても感謝します。

16 architecture  sound  sound-effects 

ここで一種のトレーディングカードゲームを作成しようとしていますが、何らかの方法で、マジックザギャザリング、または遊戯王に似ています！トランプゲーム。 基本的に、ゲームに慣れていない人のために、ゲームのルールを曲げることができる特別な効果を持つ特別な種類のカード（スペルカード/トラップカード/など）があります。私がまったく知らないのは、これらのカードのロジックを実装する方法です。私はカードのデータをフラグを付けて保存するという考えを持っていますが、それはどんな種類の能力があるのか​​を示すことができますが、それができることは非常に限られています（おそらくいくつかの単純な統計変更のみ）。 これらのカードにどんな種類の効果があるのか​​を知るために、ここに遊戯王に存在する呪文カードの効果のいくつかの例があります！トランプゲーム： 破壊されたクリーチャーを復活させる 相手のクリーチャーをコントロールする いくつかの条件に基づいてクリーチャーのステータスを変更します（例：破壊された特定の名前のクリーチャーの数） いくつかの条件が満たされた場合、特定のクリーチャーを特別に召喚します。 複数のクリーチャーを融合して、より強いクリーチャーにします。 一部の特殊カードの効果に対する耐性。 コナミは、このゲームのいくつかのビデオゲームを作成し、AIと数千種類のカードを完備しています。データベース全体をハードコーディングすることは実際には不可能だと思いますか？ 今、もちろん私がやろうとしているのは、それらのゲームほど複雑ではありませんが、私は好奇心が強いです、どうやってそれらを実装するのですか？

16 architecture  game-mechanics  card-game 

私はしばらくの間2D RPGに取り組んでいますが、デザインに関するいくつかの悪い決定を下したことに気付きました。特に問題を引き起こしているものがいくつかあるので、他の人がそれらを克服するためにどのようなデザインを使用したのか、または使用するのだろうかと思っていました。 少し背景を説明するために、私は去年の夏休みに仕事を始めました。最初はC＃でゲームを作成していましたが、約3か月前にC ++に切り替えることにしました。C ++を頻繁に使用してからしばらく経っていたので、C ++の適切なハンドルを取得したかったので、このような興味深いプロジェクトが良い動機付けになると考えました。ブーストライブラリを広く使用しており、グラフィックスにはSFMLを、オーディオにはFMODを使用しています。 かなりの量のコードが書かれていますが、それを廃棄して最初からやり直すことを検討しています。 ここに私が持っている主要な関心分野があり、他の人がそれらを解決したり、解決したりする適切な方法について意見を聞きたいと思いました。 1.循環的な依存関係 C＃でゲームを実行していたとき、C＃での問題ではないので、これについて実際に心配する必要はありませんでした。C ++に移行すると、これはかなり大きな問題になり、間違って設計したのではないかと思うようになりました。クラスを分離する方法を想像することはできませんが、それでもクラスに自分のしたいことをさせることができます。依存関係チェーンの例をいくつか示します。 ステータス効果クラスがあります。このクラスには、キャラクターに効果を適用するためのいくつかのメソッド（Apply / Unapply、Tickなど）があります。例えば、 virtual void TickCharacter(Character::BaseCharacter* character, Battles::BattleField *field, int ticks = 1); この関数は、ステータス効果を与えられたキャラクターがターンするたびに呼び出されます。Regen、Poisonなどのエフェクトを実装するために使用されます。ただし、BaseCharacterクラスとBattleFieldクラスへの依存関係も導入します。当然、BaseCharacterクラスは、現在どのステータスエフェクトがアクティブになっているかを追跡する必要があるため、循環依存関係になります。バトルフィールドは戦闘パーティーを追跡する必要があり、パーティークラスには別の循環依存関係を導入するBaseCharactersのリストがあります。 2-イベント C＃では、キャラクター、バトルフィールドなどのイベントにフックするためにデリゲートを広範囲に使用しました（たとえば、キャラクターのヘルスが変化したとき、ステータスが変更されたとき、ステータスエフェクトが追加/削除されたときなどにデリゲートがありました。）そして、戦場/グラフィックコンポーネントがそれらのデリゲートにフックして、その効果を強化します。C ++では、似たようなことをしました。明らかに、C＃デリゲートに直接相当するものはないため、代わりに次のようなものを作成しました。 typedef boost::function<void(BaseCharacter*, int oldvalue, int newvalue)> StatChangeFunction; そして私のキャラクタークラスで std::map<std::string, StatChangeFunction> StatChangeEventHandlers; キャラクターのステータスが変更されるたびに、マップ上のすべてのStatChangeFunctionを繰り返し呼び出します。動作しますが、これは物事を行うための悪いアプローチであることが心配です。 3-グラフィックス これは大きなことです。これは私が使用しているグラフィックスライブラリとは関係ありませんが、概念的なものです。C＃では、グラフィックスを、ひどいアイデアだとわかっている多くのクラスと結合しました。今回はそれを分離したいので、別のアプローチを試みました。 グラフィックを実装するために、ゲームに関連するすべてのグラフィックを一連の画面として想像していました。つまり、タイトル画面、キャラクターステータス画面、マップ画面、インベントリ画面、バトル画面、バトルGUI画面があり、基本的にこれらの画面を必要に応じて積み重ねてゲームグラフィックを作成することができます。アクティブな画面が何であれ、ゲーム入力を所有します。 ユーザー入力に基づいて画面をプッシュおよびポップする画面マネージャーを設計しました。 たとえば、マップ画面（タイルマップの入力ハンドラー/ビジュアライザー）で起動ボタンを押した場合、スクリーンマネージャーへの呼び出しを発行して、メイン画面をマップ画面上に押してマップをマークします。描画/更新されない画面。プレーヤーはメニューをナビゲートし、必要に応じてより多くのコマンドをスクリーンマネージャーに発行して、新しいスクリーンをスクリーンスタックにプッシュし、ユーザーがスクリーンを変更/キャンセルするとそれらをポップします。最後に、プレーヤーがメインメニューを終了したら、ポップメニューからポップしてマップ画面に戻り、描画/更新するようにコメントして、そこから移動します。 バトル画面はより複雑になります。背景として機能する画面、戦闘の各パーティを視覚化する画面、および戦闘のUIを視覚化する画面があります。UIはキャラクターイベントにフックし、それらを使用してUIコンポーネントをいつ更新/再描画するかを決定します。最後に、使用可能なアニメーションスクリプトを使用するすべての攻撃は、画面スタックからポップする前に、追加のレイヤーを呼び出して自身をアニメーション化します。この場合、すべてのレイヤーが一貫して描画可能で更新可能としてマークされ、バトルグラフィックスを処理する画面のスタックを取得します。 私はまだスクリーンマネージャを完全に動作させることができていませんが、しばらくはできると思います。それについての私の質問は、これは価値のあるアプローチですか？悪いデザインの場合、必要なすべての画面を作成するのに多くの時間を費やす前に、今すぐ知りたいと思います。ゲームのグラフィックをどのように構築しますか？

16 c++  architecture  rpg 

そのため、FSMを使用してゲームの状態管理を行うこと、FSMとは何か、1つを構築するためにスタックまたは状態のセットを使用することについて多くのことを読みました。私はすべてを経験しました。しかし、私はそのためにFSMの実際の適切に設計された実装を書くことにこだわっています。具体的には、どのようにして状態間を移行する問題をどのようにきれいに解決するのか、（どのように）状態が他の状態からのデータを使用できるようにするのか、などです。C ++で実装を設計および作成するためのヒントや、さらに良いコード例はありますか？

16 c++  architecture  software-engineering  game-loop  state 

私はシングルトン/グローバルの落とし穴について何度も聞いていますが、なぜ彼らがそれほど頻繁に眉をひそめているのか理解しています。 私が理解していないのは、エレガントで乱雑な選択肢が何であるかということです。シングルトン/グローバルを使用する代わりに、オブジェクトを必要とするオブジェクトに到達するまで、オブジェクトをエンジンオブジェクトに何百万レベルも渡すことが常に必要になるようです。 たとえば、私のゲームでは、ゲームの起動時にいくつかのアセットをプリロードします。これらのアセットは、プレーヤーがメインメニューをナビゲートしてゲームに入るまでずっと使用されません。このデータをGameオブジェクトからScreenManagerオブジェクトに（実際には1つのScreenのみがこのデータを処理するという事実にもかかわらず）、次に適切なScreenオブジェクト、およびその他の場所に渡すことになっていますか？ 混乱した依存関係の注入のためにグローバル状態データを交換しているように見えますが、子オブジェクトに渡す目的以外はデータを気にしないオブジェクトにデータを渡します。 これは、シングルトンが良いことなのでしょうか、それとも私が見逃しているエレガントな解決策がありますか？

16 architecture 

私は最初からビデオゲームを作ろうとしていますが、これは本当に新しく、基本的な問題に直面し続けています。最も重要なのは、ビデオゲームがオフスクリーン情報をどのように保存するかということです。つまり、プログラムは画面に次に表示するものをどのように知るのでしょうか？または、プレーヤーが環境を変更した場合、次に画面にロードするときにこの変更はどのように残りますか？ たとえば、New Super Mario Brosで？を押すと、ブロックしてから画面の外に出て、戻ってきても、ヒットしたままです。この情報はどのように保持され、次にプレーヤーがブロックをロードするときに実行されますか？なぜリセットされないのですか？

16 game-design  architecture  software-engineering  game-mechanics 

他のバージョンでは辞退したいゲームが完成しました。これらは、ほぼ同じ種類のデザインの類似したゲームになりますが、常にではなく、基本的に物事が変化する場合があります。 コアコードをゲームとは別にバージョン管理して、ゲームAで見つかったバグを修正した場合、その修正がゲームBに存在するようにします。 私はそれを管理する最良の方法を見つけようとしています。私の最初のアイデアはこれです： engine一般化できるすべてを含み、ゲームの他の部分から完全に独立したモジュール/フォルダー/何でも作成します。これにはいくつかのコードが含まれますが、ゲーム間で共有される汎用アセットも含まれます。 このエンジンを独自のgitリポジトリに配置します。これはゲームに含まれますgit submodule 私が苦労しているのは、残りのコードの管理方法です。メニューシーンがあるとしましょう。このコードはゲーム固有ですが、ほとんどのコードは汎用的な傾向があり、他のゲームで再利用できます。に入れることはできませんがengine、ゲームごとに再コーディングするのは非効率です。 ある種のgitブランチのバリエーションを使用すると、それを管理するのに効果的かもしれませんが、これが最善の方法だとは思いません。 誰にもアイデアや共有する経験、またはそれについて何かありますか？

15 architecture  software-engineering  design-patterns 

CPUキャッシュを賢く使用するための優れたアーキテクチャであるECSゲームエンジンのドキュメントをよく読みます。 しかし、CPUキャッシュの利点を理解することはできません。 コンポーネントが連続したメモリの配列（またはプール）に保存されている場合、コンポーネントを順番に読み取る場合にのみCPUキャッシュを使用するのが良い方法です。 システムを使用する場合、特定のタイプのコンポーネントを持つエンティティのリストであるエンティティリストが必要です。 ただし、これらのリストは、順番ではなくランダムな方法でコンポーネントを提供します。 それでは、キャッシュヒットを最大化するECSを設計する方法は？ 編集： たとえば、物理システムには、RigidBodyおよびTransformコンポーネントを持つエンティティのエンティティリストが必要です（RigidBodyのプールとTransformコンポーネントのプールがあります）。 したがって、エンティティを更新するためのループは次のようになります。 for (Entity eid in entitiesList) { // Get rigid body component RigidBody *rigidBody = entityManager.getComponentFromEntity<RigidBody>(eid); // Get transform component Transform *transform = entityManager.getComponentFromEntity<Transform>(eid); // Do something with rigid body and transform component } 問題は、entity1のRigidBodyコンポーネントがそのプールのインデックス2にあり、entity1のTranformコンポーネントがそのプールのインデックス0にあることです（一部のエンティティは他のコンポーネントを持たず、エンティティを追加/削除するため/ランダムにコンポーネント）。 コンポーネントがメモリ内で連続している場合でも、それらはランダムに読み取られるため、キャッシュミスが多くなります。 ループ内の次のコンポーネントをプリフェッチする方法がない限り？

15 c++  architecture  entity-system  memory-efficiency  entity-component 

私は、コンポーネントベースのエンティティ設計に頭を悩ませようとしています。 私の最初のステップは、オブジェクトに追加できるさまざまなコンポーネントを作成することでした。すべてのコンポーネントタイプに対して、iにはマネージャーがあり、マネージャーはすべてのコンポーネントの更新機能を呼び出し、必要に応じてキーボードの状態などを渡します。 次にしたことは、オブジェクトを削除し、各コンポーネントにIDを持たせることでした。したがって、オブジェクトは同じIDを持つコンポーネントによって定義されます。 今、私はすべてのコンポーネントのマネージャーは必要ないと考えています。たとえばSizeComponent、Sizeプロパティを持っているだけです。結果としてSizeComponent更新メソッドはなく、マネージャーの更新メソッドは何もしません。 私の最初の考えはObjectProperty、コンポーネントをコンポーネントのプロパティとして持つのではなく、コンポーネントがクエリできるクラスを持つことでした。だから、オブジェクトが多数を持っているでしょうObjectPropertyし、ObjectComponentます。コンポーネントには、オブジェクトのプロパティを照会する更新ロジックがあります。マネージャーは、コンポーネントの更新メソッドの呼び出しを管理します。 これはオーバーエンジニアリングのように思えますが、マネージャーがどのオブジェクトにどのコンポーネントロジックを実行する必要があるかを知る方法が必要なので、コンポーネントを取り除くことができるとは思いません（そうでなければコンポーネントを削除するだけです更新ロジックを完全にマネージャーにプッシュします）。 この（持っているObjectProperty、ObjectComponentとComponentManagerオーバーエンジニアリングクラス）？ 良い選択肢は何でしょうか？

15 architecture  component-based  design-patterns