ゲーム開発

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

15 architecture  software-engineering  design-patterns 

背景が常に色を変えている2D無限ランナータイプのゲームがあります。一方、プラットフォームの色は同じままです。このようにして、ある時点でのプラットフォーム（色が背景の色と同じである場合）がプレイヤーに対して「見えない」ようになります。 どうすれば団結でこの問題を創造的、短期的かつ便利に回避できますか？ PS光沢のあるマテリアルを追加しようとしましたが、うまくいきませんでした。

15 unity 

ゲーム開発業界で3Dユニバースをレンダリングするためのベストプラクティスは何ですか？ 具体的には： データポイントが与えられ、静的です。各ポイントには位置、色、サイズがあります。 データセット全体は、使用可能なメモリよりもはるかに大きくなります。 ユーザーは、より大きな画像を一度に「ズームアウト」できる必要があります。 最も素朴なアプローチは、ユニバースをキューブに分割し、目に見えるものだけをレンダリングすることです。このシナリオで「ズームアウト」をどのように実装する必要があるのか​​わかりません。可能なズームレベルごとにキューブを事前に計算する必要がありますか？または、より良いアプローチがありますか？ テクノロジーにとらわれないソリューションを探しています。

15 graphics  algorithm  grid 

動的に生成されるゲームのことを考えるとき、ランダムに生成されるレベルを持つディアブロのようなものを考えます。手続き的に生成されたゲームを考えるとき、私はゆるい鳥や他の無限のランナーのようなものを考えます。 しかし、これらは両方ともレベルをランダム化するだけです。手続き的に生成されたゲームは常に生成されており、動的に生成されたゲームはすべて前もって生成されているのでしょうか？または、これらの用語は交換可能ですか？ 動的に生成されるゲームと手続き的に生成されるゲームの違いは何ですか？

15 procedural-generation  random  terminology 

Unity 3Dプログラミングおよびゲームソフトウェアを使用して、AndroidおよびiOS用のモバイルゲームアプリを作成しても大丈夫ですか？Unity 3Dの無料版を使用しており、Google Playに公開して作成した現在のゲームアプリの販売を計画しています。また、広告を掲載する無料アプリとして設定することで、この方法でお金を稼ぐこともできます。 開発者の中には、無料版のUnity 3Dを使用してゲームを作成し、App StoreまたはGoogle Playを介して公開している開発者もいます。もしそうなら、ビジネス用のいくつかのゲームアプリの作成に依存するために無料版を使用しているので、収益のためにUnity開発チームへの貢献を支払うか共有する必要がありますか？

15 unity  legal  google-play  business-model 

現在、ユニットの局所回避のための物理的衝撃力をシミュレートしていますが、この方法はユニットをフォーメーションから押し出すことがあり、ユニットが凝集すると非常に望ましくない効果があります。 Starcraft 2のようなRTSゲームの場合、ローカル回避はどのように行われますか？物理学はシミュレートされていますか、それとも全知のコントローラーがすべての場所を決定しますか？私はこの質問が少し広いかもしれないことを知っているので、Starcraft 2のローカルな回避行動をどのように達成するかについて具体的に尋ねています。動作するものなら何でも大歓迎です。 コードを探しているわけではありません-Starcraft 2（または同様のゲーム）がローカル回避を処理する方法の有用なリソースまたは説明だけです。 現在、衝突検出（貫通ベクトル）、衝突力、および速度による移動が実装されています。すべてのユニットは、衝突について別のユニットと照合されます-衝突すると、オブジェクトは貫通ベクトルによってすぐに相殺され、衝突力が適用されます。次に、別のループがオブジェクトをその速度で移動し、速度にドラッグを適用します。オフセットは、凝集したユニットに過剰な衝突力がかかる問題を緩和しますが、ユニットが時々飛び出すこともあります。 私が探しているソリューションは、次の要件を満たす必要があります（Starcraft 2のように）。 オブジェクトは重複しません。または、少なくとも重複を最終的に解決する必要があります。 オブジェクトは必要以上に押し合うことはないので、2つのユニットがフォーメーション内でお互いに隣接して移動できます。 オブジェクトが同じ目的地に向かって固まる場合、奇妙な動作はありません。 さまざまなサイズのユニット、さらにはさまざまな凸形状をサポートできます。 私がこれまで考えてきたのは、衝突を検出する代わりに、将来の衝突を検出して、重複が発生しないようにすることです。次に、2つのユニットの速度が重なり合わないように、制約を適用します。オーバーラップを超えた動きを制限するアルゴリズムをいじっています。

15 physics  rts  collision-avoidance 

私は2Dトップダウンシューターに取り組んでおり、Quake 3のようなネットワークゲームで使用されるコンセプトをコピーするために最善を尽くしています。 信頼できるサーバーがあります。 サーバーはクライアントにスナップショットを送信します。 スナップショットには、タイムスタンプとエンティティの位置が含まれます。 スナップショット位置間でエンティティが補間されるため、動きがスムーズに見えます。 必要に応じて、エンティティの補間は「過去に」わずかに行われるため、複数のスナップショットを補間します。 私が直面している問題は「クロック同期」です。 わかりやすくするために、サーバーとの間でパケットを転送する際のレイテンシーがゼロであると少しの間ふりをしましょう。 サーバーのクロックがクライアントのクロックより60秒進んでいる場合、スナップショットのタイムスタンプはクライアントのローカルのタイムスタンプより60000ミリ秒進んでいます。 したがって、クライアントのクロックが追いつくのに時間がかかるため、エンティティスナップショットが収集され、クライアントが特定のエンティティが移動するのをクライアントが見るまで約60秒間待機します。 スナップショットを受信するたびにサーバーとクライアントのクロックの差を計算することで、この問題を克服することができました。 // For simplicity, don't worry about latency for now... client_server_clock_delta = snapshot.server_timestamp - client_timestamp; エンティティが補間にどの程度沿っているかを判断するとき、単にクライアントの現在の時間に差を追加します。ただし、これに関する問題は、スナップショットが他のクロックよりも速く/遅く到着するために2つのクロックの差が突然変動するため、ジャーキネスが発生することです。 知覚可能な遅延が補間のためにハードコードされている遅延と、通常のネットワーク遅延によって引き起こされる遅延のみであるように、クロックをどのように密接に同期できますか？ 言い換えると、ジャーキネスを導入せずに、クロックが大幅に非同期化されたときに、補間の開始が遅すぎる、または早すぎるのを防ぐにはどうすればよいですか？ 編集：Wikipediaによると、NTPを使用して、インターネット上のクロックを数ミリ秒以内に同期できます。ただし、プロトコルは複雑に思えますが、おそらくゲームで使用するには過剰ですか？

15 networking  server  client-server  synchronization  socket 

ゲームの開始時に作成された手続き的に生成された世界でゲームを作成しています。グリッドで表されるいくつかの領域で構成されています（8x8、9x6、サイズは理想的には任意です）。これらの領域は、依存関係リストを介して互いに接続されることになっています。 そのグリッドの少なくとも3つのスペースがこれらの2つの領域の間に露出している場合、接続が存在します。その3つのスペース接続エリアの中央のセルには、エリア間の出入り口があります。 私はそれらを接続する方法を見つけようとしてきましたが、同時に考慮する必要のある領域が増えるにつれて、ますます複雑になります。 ペーパープロトタイピングをいくつか試しましたが、視覚的に行うのは非常に簡単なプロセスですが、コードによって同じ効率で部屋を配置できる優れた数式のセットは見つかりませんでした。 これが私が今苦労している「単純な」例です： エリア「a」は「b」および「c」に接続する必要があります エリア「b」は「a」と「d」に接続する必要があります エリア「c」は「a」と「d」に接続する必要があります エリア「d」は「b」および「c」に接続する必要があります 簡単にするために、リストに表示される順番で部屋を配置していることを考えてみましょう（他の人も試しました）。そこで、標準の手続き型ダンジョン生成アルゴリズムとしてこれにアプローチしています。 最初の領域なので、ボード上の任意の場所に「a」を配置します。次に、壁をランダムに選択します。その壁には何も接続されていないため、そこに「b」を配置できます。 ここで「c」を配置する必要がありますが、「a」はすでにボード上にあり、壁が占有されているため、別の壁に配置することにします。しかし、「d」が表示され、「b」と「c」にも接続する必要があるため、すべてのプレースメントが実行されるわけではありません。 同じ依存関係を持つ2つの部屋を反対側の壁に置くことはできないという制限を試みましたが、それでも成功を保証するものではありません。 また、エリアのサイズが異なる他のケースでは、反対側の壁にいるとうまくいきます。 また、有効なソリューションを除外するため、使用済みの壁を考慮しないことは欠陥のある仮定です。 Optimal Rectangle PackingやGraph Layoutアルゴリズムなど、他の手続き生成アルゴリズムなどの研究を調べてみましたが、通常、これらのアルゴリズムはこの問題のすべての制約を考慮しておらず、一緒に混ぜることは困難です。 適切な配置が見つかるまで領域とバックトラックを配置するなど、たくさんのアプローチを考えましたが、それらは試行錯誤に非常に依存しており、計算の面でコストがかかるようです。しかし、私が言及した最後の2つの問題に関する広範な研究を考えると、それが唯一/最良の解決策かもしれませんか？ 私はちょうど誰かが過去に同様の問題を抱えていたか、またはこれを理解し、アルゴリズムをどこから始めるべきかについていくつかの指針を与えてくれるかどうかを見たかっただけです。または、失敗した場合は、設定した制約を緩めることを検討する必要があります。

15 procedural-generation 

高速で移動するスプライトの効果を、ゴーストのように引きずります。ソニックのこのイメージに非常によく似たもの（質の悪い謝罪、それは私が達成しようとしている効果の唯一の例です） ただし、アトラス内のスプライトの量を本質的に2倍（または4倍）にする必要がないように、スプライトシートレベルでこれを行いたくありません。また、非常に労働集約的です。 この効果を達成する他の方法はありますか？おそらくシェーダーブードゥー教の魔法によるものですか？Unityと2D Toolkitを使用しています（それが役立つ場合）。

15 unity  sprites  graphic-effects 

最近、ループレベルのデザインを持つことができる2D横スクロールマルチプレイヤーゲームを作成する方法について議論がありました（スターバウンドとその世界がどのようにループしているのかを考えてください）。 最も簡単な方法は、プレイヤーを一方から他方へテレポートできるトリガーゾーンを持つ長方形のマップを作成することだと思いました。しかし、このアプローチの明らかな問題は、マップの端に複数のプレイヤーが一度にいる場合です。プレイヤーをお互いの前にテレポートするだけでなく、他のプレイヤーが消えることなくプレイヤーを輸送する方法が必要になります。 このアイデアを追加して問題を解決するために、私は次のことを思いつきました。プレイヤーが「クローンゾーン」（緑の四角）を見ることができるトリガーゾーン（画像の赤の四角）を持っています。この緑色の正方形では、トリガーゾーンの反対側からのオブジェクトが対応するクローンゾーンにコピーされます（A＆Bシェイプで見ることができます）。プレイヤーが「クローンゾーン」の開始端に到達すると、マップの反対側にテレポートされます。 この例では、プレイヤー2はプレイヤー1を見ていると考えますが、実際には自分のクローンを見ているか、その逆です。 これは目前の問題にとっては少し極端で複雑に思えました。私の質問は、この解決策が問題に取り組むための良いアプローチであるかどうか、またはこの問題を解決するより簡単な方法があるかどうかを知ることです。

15 2d  camera  multiplayer  level-design 

クイックノート：これはゲーム開発の Q＆Aサイトであることは知っていますが、グラフィックカードの知識が豊富で経験があると思いますので、この質問に答えます。これが完全にトピック外であると思われる場合は、適切なサイト/フォーラムを参照してください。編集：実際、それは gamedevに関連しています：悪いコードがカードの過熱や破壊を引き起こす可能性がある場合、ゲーム開発者はそれを認識し、アプリケーションがそれをしないことを確認する必要があります。 これは奇妙な、または愚かな質問のように思えるかもしれませんが、グラフィックカードを（何らかの形で）破壊するようなグラフィックレンダリングアプリケーションを実際に作成することは可能ですか？ この質問をするようになった直接的な理由は、（驚くことではないが）自分の壊れたグラフィックカードです。修理を行った後、サービスマンは、さまざまなアプリ（ゲーム）をテストし、正常に動作したと言いました。しかし、自分のアプリ（シェーディングデモの延期）を起動すると、100℃以上に加熱されました。したがって、私のカードは結局修正されませんでしたが、ここで重要なことは、問題が自分のアプリを実行しているときにのみ発生するように見えたことです。 さまざまなGPU要求ゲーム（Crysisなど）をプレイし、しばしば限界までプッシュしました（ゲームが5 FPSで動作するほど高い設定をしていた）、いくつかのベンチマークも...だから私は与えました私のカードは何度も作業負荷がかかりすぎて追いつくことができませんでした（したがってFPSが低い）が、危険な温度に達することはありませんでした。しかし、私自身のアプリケーションはそれを達成することができました（少なくともv-syncがオフのとき）。：Pそれは私自身のアプリでしかなかったので、悪い冷却システムが犯人だとは思いません。 だから、私は尋ねます-悪意のあるコードによってグラフィックカードを（何らかの方法で、過熱するだけで）破ることが可能かどうかを考えていますか（またはおそらく知っていますか）？ 更新： ジョー・スウィンデルは、過熱が問題になるかもしれないと言った（まあ、それは間違いなくカードを壊す可能性がある）。しかし、適切な冷却システムは、（どんな状況でも）その発生を防ぐべきではありませんか？ Borealは別の問題を指摘しました。正しく理解すれば、FPSはCPUとGPUの両方に拘束されます（そうですか？）。そのため、FPSが低いと、CPUの負荷が高いか、GPUの負荷が高いことを示す場合があります。しかし、再び-カードが「常に100％使用されている」場合でも、適切な冷却システムはGPUの過熱を防ぐべきではありませんか？

15 gpu  hardware 

私は初めて団結してゲームを作りましたが、団結のせいで何もせずに売れるのではないかと思っていましたか？

15 unity 

ゲーム開発用のこのクールなWebサイトを見つけました。これにはイージング機能のリストがあります。 サイトには目的の説明が含まれていますが、それは私の頭に浮かびます。イージング機能とは何ですか？ 更新 Phaser.ioのソースコードから関数自体のより良い例を見つけました。これらの関数は、ここでの答えが示唆するよりもはるかに単純です。パラメータは1つのみkです。答えの一部として、これらの使用方法を知りたいです。

15 game-design  easing 

UnityゲームをAndroidに移植し、プレーヤー設定の「最小APIレベル」を「2.3.3（APIレベル10）」に設定しました。 ただし、ストアでは、「Androidが必要：1.6以上」と表示されます。 Google Developer Consoleではこの設定が見つからなかったので、ストアはアプリケーションを調べて失敗しただけだと推測しています。 私は何か見落としてますか？

15 android  unity  google-play 

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