ゲーム開発

多くの場合、ピクセルベースのゲームでキャラクターを動かすために、2.5などの速度値を使用します。ただし、衝突検出は一般的に私が行うとより困難になります。だから私はこのようなことをすることになります： moveX(2); if (ticks % 2 == 0) { // or if (moveTime % 2 == 0) moveX(1); } 私はそれを書く必要があるたびに内側にうんざりしますが、非整数の速度値でキャラクターを移動するよりクリーンな方法はありますか、これを永遠にやり続けるのですか？

21 c++  2d  movement  floating-point 

これは少々未解決の質問ですが、私は誰かが両方の正当な理由を提供してくれることを望んでいます。 両方の簡単な例： 補間モデル クライアントが位置の更新を頻繁に受信し、リモートがこのデータの補間を使用して位置を更新するValveモデルを考えてください。 経路探索 このモデルでは、ユーザーが宛先を送信し、全員がその宛先にパスファインディングすると考えます。 どのタイプのゲームがそれぞれに適していますか？

21 networking  path-finding  interpolation 

AI用のコマンドオーダーシステムを実装する最もエレガントな方法は何ですか？たとえば、小人の要塞では、森林伐採エリアに木材の切断をマークすると、小人は次のシーケンスを実行します。 木に行く 木を切る 備蓄に木材を届ける 別の木に行く 等々.. 私はすでにスタックコマンドが動作していません。アイドル状態からツリーの宛先タイルに到達する1。 私が恐れているのは、このような注文をさらに作成すると、これがどのように面倒になるかです： 家を建てる 備蓄に行く 建設エリアに木材を持ち込む 備蓄に戻る 建設エリアに石を持参 建物のスプライトをアニメートする 植付 備蓄に行く 種を農場に持ち込む 醸造 備蓄に行く 植物を静止させる 醸造スプライトをアニメートする だから私の質問は、ドワーフ要塞のようなコマンド順序システムをどのように実装し、同時にスパゲッティコードを回避するのですか？調査する必要があるデータ構造はありますか？コマンドシーケンスを別のxmlファイルに配置する必要がありますか？

21 architecture  ai  design-patterns  data-structure  strategy 

スプライトシートとテクスチャアトラスの違いは何ですか？ どちらも同じではありませんか？スプライトシートにはスプライトがいくつかあり、テクスチャアトラスにはスプライトもいくつかありますが、違いは何ですか？

21 spritesheet  texture-atlas 

私は、魔法の呪文システムを備えた小さな2Dトップダウンのオープンワールドサバイバルっぽいゲームを設計しています。これまでの動作方法： プレイヤーはゲームの開始時に「杖」を受け取ります プレイヤーが新しいアイテムや敵に遭遇すると、それらのアイテムを使用したり、敵を倒したりするのに役立つ呪文を獲得します 私が抱えている問題は、呪文を唱える方法を設計することです。最初は、0〜10のキーにさまざまなスペルをバインドしましたが、すぐにスペルの数がそれを圧倒しました。また、ゲームの後半で使用されない低レベルのスペルが最も有用なキーにバインドされるという問題があります。 それでは、ユーザーフレンドリーなスペルキャストシステムを作成する最良の方法は何ですか？必要に応じて、ゲームでのマジックの動作をオーバーホールできます。 編集：明確にするために、スペルの種類と目的が大幅に異なるPC用にリアルタイムで開発していますが、この質問はすべてのプラットフォームに当てはまります。

21 game-design  design-patterns  ui-design 

ゲームのバージョンにラベルを付けるためのベストプラクティスがあるかどうかは誰でも知っていますか。 バージョン管理以外の標準的な名前があるかどうかはわかりませんが、基本的には次のとおりです。 1.0 1.1 1.2 1.3.1ベータ

21 version-control 

リアルなピザを作成し、ユーザーがそれを操作できるようにします。 私が欲しいもの： 私が作成したもの： Blenderでピザのモデル（8個）を作成し、Unityにインポートしました。ピザのピースは非常に人工的に見えますが、その主な理由は「堅い三角形」です。 ユーザーがピースを動かしたときにチーズを伸ばしたり壊したりするにはどうすればよいですか？

21 unity  3d  physics  blender  soft-body-dynamics 

これが本当の質問と見なされない場合はご容赦ください。しかし、それは私が本当に混乱しているものです。 他のゲーム開発者がベクターの使用が非常に有用であるという話を絶えず聞いていますが、ベクターの数学に誰もがどのように脅かされているのか、ベクターは気が遠くなるように思えます。私はそれらについて学ぶことを一度もしなかった。 だから、ついにウィキペディアでベクターを見て、驚いた。私が何らかの形で誤解しない限り、ベクトル（簡単にするために、2Dであると言います）は、xとy座標です。 誤解している場合は、修正してください。 だからここに私の質問があります：それは2（または3）次元座標の表現がベクトルであることを意味しないのですか？その場合、ベクトルと座標は同じものです。また、座標を使用せずにゲームを作成することはほとんど不可能です。したがって、ベクターは、ゲームプログラミングをある程度行った人にとって、混乱したり、新しいものになるのでしょうか。 これは、いくつかの説明を使用できるものです。どんな助けも大歓迎です。

21 mathematics  vector  coordinates 

タイル64x32で等尺性マップを描画します。 const Offset = 160; int X, Y; for (int a=0; a < 6; a++) for (int b=0; b < 6; b++) { X = a * 32 - b * 32 + Offset; Y = a * 16 + b * 16; DrawTile(X, Y, tile); } このコードを示す画像： 親愛なる専門家は、セルの等尺性インデックスでのマウス座標の変換式を手伝ってください。例：（105; 100）-> …

21 mathematics  algorithm  isometric 

私はC ++でビートゲームをコーディングしており、イベント、トリガー、カットシーンなどのスクリプトを実装するときが来ました。インターネットで読み回して、かなりの情報を得ました。私の最初の選択ソリューションは、Cave Storyのような独自のスクリプト言語を実装することです。私はこれが示唆されているのを見ましたが、ほとんどの人はluaを示唆していますが、それは私のタイプのプログラミングに合わないようです。 独自のスクリプト言語を作成しましたか？既存のものを使用する代わりに、独自のロールを選択したのはなぜですか？開発中にどのリソースに相談しましたか？

21 scripting 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 平均して、アセンブリは現代のゲームコードでどれくらいの頻度で使用されますか？ 特に、x86、PPC、ARMなどの優れたC ++コンパイラを既に搭載しているプラ​​ットフォームでは、組み込みシステムのゲームはアセンブリを広範囲に使用すると想定しているためです。

21 c++  c 

で前の質問、それが署名した距離フィールドは、事前に計算実行時にロードされ、そこから使用することができることが示唆されました。 この質問の最後に（興味のある人のために）説明する理由のために、距離フィールドをリアルタイムで作成する必要があります。 面取り距離変換やボロノイ図近似ベースの変換（Pixeljunk Shooter dev guyによるこのプレゼンテーションで提案されている）の方法など、リアルタイム環境で実行可能なさまざまな方法に関する論文がいくつかありますが、私は（したがって、他の多くの人々と見なされる可能性があります）彼らは通常長く、大部分が数学で肥大化しており、説明はあまりアルゴリズム的ではないため、実際に使用するのは非常に困難です 距離フィールドをリアルタイムで（好ましくはGPU上で）作成するために、特に距離フィールドの品質を考慮して、どのアルゴリズムを提案しますか？ 別の論文やスライドへのリンクとは対照的に、実際の説明/チュートリアルを探しているので、この質問は1つに適格になると賞金を受け取ります:-)。 リアルタイムで実行する必要がある理由は次のとおりです。 大規模な2D環境用にこれらのSDFを事前計算する必要がある場合（大規模なTerrariaのようなマップの場合）、これは、ストレージスペース（およびマップ生成時間）のかなり大きなオーバーヘッドを受け入れ、より多くのリアルタイムのSDF生成に十分高速な複雑なアルゴリズム。 たとえば、タイルサイズが10 * 10ピクセルで1000 * 256（幅*高さ）の比較的小さなマップで、合計サイズが10000 * 2560ピクセルの場合、比較的小さなサイズを選択すると、すでに約2メガバイトのサイズがかかります。 0〜255の距離値のみを保存すると仮定すると、128x128のSDF解像度。 明らかに、これはすぐに大きくなりすぎる可能性があり、私が望んでいないオーバーヘッドです。 他にも何かあります： SDFは（衝突検出など）多くのことに使用でき、いくつかの有用なアプリケーションは潜在的にまだ発見されていません。多くの人が将来これらのことを探すと思います。ここで包括的な答えが得られれば、私たちは多くの人を助けると思います。

21 2d  signed-distance-field 

私はC ++とOpenGL 2.1を使用してゲームを書いています。データ/ロジックをレンダリングから分離する方法を考えていました。現時点では、描画を実装するための純粋な仮想メソッドを提供する基本クラス「Renderable」を使用しています。しかし、すべてのオブジェクトには特別なコードがあり、シェーダーのユニフォームを適切に設定し、頂点配列バッファーデータを整理する方法を知っているのはオブジェクトだけです。コード全体で多くのgl *関数呼び出しが発生します。オブジェクトを描画する一般的な方法はありますか？

21 c++  opengl  rendering  logic  data 

私の大学では、彼らは常にUMLのデザインやものについて強調し誇大宣伝していますが、ゲーム構造のデザインではうまく機能しないと感じています。今、私はゲームの設計をどのように始めるべきかについて専門的なアドバイスが欲しいですか？ストーリーは、プログラミングにある程度のスキルがあり、2Dプラットフォーマーをある程度拡張するなど、多くのマイナーゲームを行ってきたということです。私のプログラムについて私が見つけた問題は、質の悪いデザインです。しばらくコーディングした後、計画が不十分なために状況が崩れ始めます（新しい機能を追加すると、プログラム全体を再コーディングしなければならなくなる傾向があります）。ただし、単一の設計上の欠陥なしですべてを計画することは、あまりにも理想的です。したがって、ゲームをどのように計画すればよいかについてのアドバイスはありますか？私と私の友人がデザインを概観できるように、どのようにそれを目に見える写真に入れるべきですか？ 私は友人とゲームのコーディングを開始する予定でした。これが私の最初のチームワークになりますので、専門的なアドバイスがあれば嬉しいです。UML以外の代替手段はありますか？ 別の質問は、「プロトタイピング」が通常どのように見えるかということです。

21 game-design 

OpenGLバージョン3以降では、クライアント側レンダリングの使用が不要になりました。即時モードは廃止され、頂点配列は非推奨のようです。代わりに、私が正しく理解していれば、VBOは頂点をレンダリングする主な方法です。 すべてを均一にレンダリングする方法の背後にあるロジックを見ていますが、VBOには頂点配列に大きなマイナス面がないのですか？一般に、VBOは1 MBを超えるデータを含む大きなバッファーであると考えられていました。小さいジオメトリがたくさんあるシーンがある場合はどうなりますか？多数のノードを持つシーングラフがあり、各ノードには独自の変換などが必要です。各ノードは個別に削除したり、個別に追加したりすることもできます。以前は頂点配列を使用していました。したがって、最初の質問は、VBOに切り替えた場合、各オブジェクトにVBOを割り当てる必要があるため、シーングラフオブジェクトのオーバーヘッドが大きくなるかどうかです。 もう1つの懸念は、レンダリングするジオメトリが非常に動的になる可能性があることです。最悪の場合、すべてのジオメトリを一定期間フレームごとに再送する必要がある場合があります。この使用例では、VBOのパフォーマンスは頂点配列よりも劣りますか、それともVBOは頂点アレイと同じくらい機能しますが、それ以上は機能しませんか？ したがって、より簡潔な形式で、私の質問は次のとおりです。 1）VBOの割り当て/割り当て解除にかなりのオーバーヘッドがありますか（つまり、バッファーをセットアップするだけの行為です）。 2）フレームごとにCPUからデータを更新する場合、これは頂点配列を使用した場合よりも大幅に悪化する可能性がありますか？ そして最後に、私は知りたい： 3）上記の質問のいずれかに対する答えが「はい」の場合、なぜVBOよりも有利なレンダリングの他のモードを非推奨にするのですか？これらの潜在的な割り当てコストなどを軽減するために使用するはずのテクニックなど、ここに欠けているものはありますか？ 4）これらの質問への回答は、使用しているOpenGLバージョンによって大幅に変わりますか？パフォーマンスの高い方法でVBOを使用してコードをOpenGL 3または4の上位互換にリファクタリングすると、同じ手法がOpenGL 2でうまく機能する可能性が高いか、特定の手法がOpenGL 3ではるかに高速になる可能性があります+およびOpenGL 2を使用する他のユーザー スタックオーバーフローについてこの質問をしましたが、このサイトが私の質問に適している可能性があることに気付いたので、ここに再投稿しています。

21 opengl  performance  vbo