ゲーム開発

私は、MFC、QT、Forms、SWING、および数年前のいくつかのWeb-GUIフレームワークなど、多くの「保持された」GUIシステム（これが意味することについては以下）でアプリケーション開発に取り組んできました。私は常に、ほとんどのGUIシステムの概念が非常に複雑で不器用であることを発見しました。コールバックイベント、リスナー、データコピー、文字列から何かへの変換の量-変換（など）は、アプリケーションの他の部分と比較して、常にミスと頭痛の原因でした。（データバインディング/モデルの「適切な」使用でも）。 今、私はコンピューターゲームを書いています:)。私はこれまでに1つのGUIで作業しました。宮城（よく知られていませんが、基本的に他のすべてのシステムと同じアイデアです。） ひどかった。 ゲームのようなリアルタイムレンダリング環境の場合、「保持された」GUIシステムはさらに時代遅れになったように感じます。ユーザーインターフェイスは通常、自動レイアウトする必要も、オンザフライでサイズ変更可能なウィンドウを持つ必要もありません。代わりに、常に変化するデータ（世界のモデルの3D位置など）と非常に効率的に対話する必要があります 数年前、私は基本的にイミディエイトグラフィックスモードに似ていますが、ユーザーインターフェイス用の「IMGUI」に出会いました。私はまだアプリケーション開発に携わっており、IMGUIシーン自体はそれほど広くも成功もしていないように思えたので、あまり注意を向けませんでした。それでも、彼らがとるアプローチは非常にセクシーでエレガントであるため、このUIの方法を使用して次のプロジェクトのために何かを書きたいと思うようになりました（私は職場で誰も納得させることができませんでした：（...） 「保持」と「即時」の意味を要約します。 保持されたGUI：別の初期化フェーズで、ラベル、ボタン、テキストボックスなどの「GUIコントロール」を作成し、それらを画面に配置する記述的な（またはプログラム的な）方法を使用します。コントロールは、X、Yの位置、サイズ、境界線、子コントロール、ラベルテキスト、画像などの独自の状態のほとんどをメモリに保持します。コールバックとリスナーを追加して、イベントを通知したり、GUIコントロールのデータを更新したりできます。 即時GUI：GUIライブラリは、ワンショットの "RenderButton"、 "RenderLabel"、 "RenderTextBox" ...関数で構成されています（編集：Renderによって混乱しないでくださいプレフィックス。これらの関数は、ユーザー入力のポーリング、文字の挿入、ユーザーがキーを押したときに文字の繰り返し速度を処理するなどのコントロールの背後にあるロジックも実行します...）コントロールを「即座に」レンダリングするために呼び出すことができます（doesn ' tはすぐにGPUに書き込まれる必要があります。通常は、現在のフレームについて記憶され、後で適切なバッチに分類されます。ライブラリはこれらの「状態」を保持しません。ボタンを非表示にする場合は、RenderButton関数を呼び出さないでください。ボタンやチェックボックスなどのユーザーインタラクションを持つすべてのRenderXXX関数には、ユーザーがボタンをクリックしたかどうかを示す戻り値があります。あなたの「RenderGUI」関数は、ゲームの状態に応じてRenderXXX関数を呼び出すかどうかの大きなif / else関数のように見え、すべてのデータ更新ロジック（ボタンが押されたとき）がフローに絡まります。すべてのデータストレージはGUIの「外部」にあり、Render機能にオンデマンドで渡されます。（もちろん、大きな関数をいくつかに分割したり、GUIの一部をグループ化するためにいくつかのクラス抽象化を使用したりします。1980年のようなコードはもう書いていませんよね;）） 今回、Unity3Dが実際に組み込みのGUIシステムとまったく同じ基本的なアプローチを使用していることがわかりました。おそらく、このアプローチを備えたGUIがいくつかありますか？ それでも..周りを見ると、保持されたGUIシステムに強いバイアスがあるように見えますか？少なくとも、Unity3Dを除き、このアプローチは見つかりませんでした。元のIMGUIコミュニティは、かなり静かなようです。 だから誰も両方のアイデアで働いていて、強い意見がありますか？ 編集：私は実世界の経験から生じる意見に最も興味があります。IMGUIフォーラムでは、即時GUIアプローチの「理論上の弱点」について多くの白熱した議論があると思いますが、実際の弱点について知ることは常により啓発的であると思います。

38 gui 

MMORPGの探検とインタラクションの面を楽しんでいるが、平均的なMMORPGの一部であるエンドレスグラインドマラソンの時間がないというプレイヤーの大きな市場があると思います。 MMORPGは、プレーヤー間の相互作用に関するものです。しかし、異なるプレイヤーがゲームに投資する時間が異なる場合、消費する時間が少ない人はすぐにパワー平準化の友人の後ろに足りなくなり、もはや彼らと対話することができなくなります。 これを解決する1つの方法は、プレーヤーが1日に達成できる進捗を制限し、1日1時間または2時間以上プレイしても意味がないようにすることです。しかし、忙しいカジュアルプレーヤーでさえ、日曜日の午後をビデオゲームで過ごすのが好きな場合があります。2時間後にそれらを停止するだけでは本当にイライラするでしょう。また、毎日の進行制限を毎日使用するようプレッシャーをかけます。そうしないと、プレーヤーは何かを無駄にしたい気がするからです。このプレッシャーは、カジュアルなゲーマーにとって有害で​​す。 週に40時間以上プレーするプレーヤーと10時間以上プレーできないプレーヤーとの間で競技場を平準化するために他に何ができるでしょうか？ 編集：あなたのすべての答えをありがとう。彼らは皆とても刺激的で、面白いアイデアをくれました。私が最初にやることは休憩メカニックになると決めたので、Orin MacGregorによる答えを受け入れました。しかし、私は他の多くの答えも支持しました。レストメカニックの私の最初のドラフトに興味がある場合は、私の開発ブログでそれについて読むことができます：http : //ontraindevelopment.blogspot.com/2012/10/rest-system.html

38 game-design  mmo 

浮動小数点は、大きな世界での正確さのために常に面倒でした。 この記事では、舞台裏について説明し、明らかな代替手段である固定小数点数を提供します。次のようないくつかの事実は本当に印象的です： 「64ビットの精度で、太陽からPl王星までの最も遠い距離（74億km）にサブマイクロメートルの精度で到達できます。」 サブマイクロメートルの精度は、fpsが必要とする（位置や速度でさえ）必要以上のものであり、本当に大きな世界を構築することができます。 私の質問は、固定小数点にそのような利点があるのに、なぜ浮動小数点を使用するのですか？ほとんどのレンダリングAPIと物理ライブラリは浮動小数点を使用します（そして、その欠点に苦しむため、開発者はそれらを回避する必要があります）。 彼らはとても遅いですか？ また、アウターラやインフィニティなどのスケーラブルな惑星エンジンは、大規模をどのように処理すると思いますか？位置に固定小数点を使用していますか、それとも空間分割アルゴリズムがありますか？

38 graphics  physics 

この根本的な問題を抱える質問が頻繁に出てきますが、それらはすべて特定の機能やツールの詳細に追いついています。これが出てきたときにユーザーに紹介できる標準的な回答を作成する試みです-多くのアニメーションの例があります！:) 一人称カメラを作っているとしましょう。基本的な考え方は、左右に見えるようにヨーし、上下に見えるようにピッチすることです。そのため、次のようなコードを少し書きます（例としてUnityを使用）： void Update() { float speed = lookSpeed * Time.deltaTime; // Yaw around the y axis using the player's horizontal input. transform.Rotate(0f, Input.GetAxis("Horizontal") * speed, 0f); // Pitch around the x axis using the player's vertical input. transform.Rotate(-Input.GetAxis("Vertical") * speed, 0f, 0f); } または多分 // Construct a quaternion or …

38 rotation  geometry  transformation 

ここで言われているように： 時間 このフレームの開始時刻（読み取り専用）。これは、ゲームの開始からの秒数です。 そして、私が知っているように、時間はフロートに保存されます。したがって、私の質問は、時間の価値が非常に大きくなったときに何が起こるかということです。あふれますか？精度が失われ、バグが発生しますか？ゲームはただクラッシュするのでしょうか？

37 unity 

Androidデバイスの画面上で、プレイヤーがポイントA（x1、y1）から他のポイントB（x2、y2）に線を引く必要があるゲームに取り組んでいます。 その図面が直線にどれだけ適合するかを見つけたい。たとえば、90％の結果は、描画がほぼ完全に線に合うことを意味します。プレーヤーがAからBに曲線を描くと、低いスコアが得られます。 エンドポイントは事前にわかりません。これどうやってするの？

37 algorithm  geometry  touch 

無限のゲームは、同じゲームプレイの仕組みが何度も繰り返されることで構成されています。できる限り、ほとんど同じことをし続けなければなりません。 したがって、プレイヤーをゲームに飽きさせるのは非常に簡単です。プレイヤーを引き付けるためにゲームデザインに実装できる概念は何ですか？ より具体的に言うと、私のゲームは無限のタッピングゲームで、ロケットをタップして花火に爆発させたり、時には流星にも爆発させたりします。

37 game-design  mobile  clicker 

最近、さまざまな4Xゲーム（eXplore、eXpand、eXploit、eXterminate、Civilizationシリーズなど）をプレイしましたが、それらのほとんどが同じ問題に苦しんでいることに気づきました。その他、そのプレーヤーはほとんど無敵になります。支配的なプレーヤーは、他のプレーヤーよりもはるかに多くのリソースにアクセスできます。また、そのプレイヤーは研究において大きな利点があります。つまり、他の派ionsはすぐに技術に戻り、弱い派factが対抗できないツールを強力なプレイヤーに提供するため、ゲームはさらに簡単になります。 この段階では、このプレイヤーが必然的に勝つことは明らかです。ただし、通常、ゲームはここで停止しません。支配的なプレイヤーがすべての弱いプレイヤーを次々とスチームロールしている間、それは数時間続きます。彼らは非常に強力なので、これは彼らに挑戦しません。したがって、ゲームのこのフェーズは、誰にとっても退屈で退屈な雑用になります。支配的なプレイヤーは、敵の基地/都市/惑星から他のプレイヤーにユニットを移動させます。終.。 この退屈で退屈なエンドゲームを避けるために、4Xゲームをどのように設計できますか？

37 game-design  balance  turn-based-strategy  4x 

スクラッチダメージはゲームメカニックであり、攻撃が成功すると、常に最小限のダメージが与えられます。これは、攻撃者によるダメージから防御が直接差し引かれる減法戦闘システムでよく使用されます。そのため、ターゲットは常に最小限のダメージを受けます。 このようなシステムの欠点は、少なくとも私にとっては、ハックだということです。次のような単純な式を取り、Damage = Attack - Defenseそれを（少し）より複雑な式に変換しますDamage = max(Attack - Defense, 1)。 また、キャラクターの成長などのプレイヤーのスキルを損なうと感じています。どれだけ多くの防御ボーナスを獲得しても、すべての攻撃は小さなダメージを与えます。それでは、何の意味もないのに、なぜあなたの防御力をそんなに高くするのでしょうか？ さらに、これによりHPとダメージに大きな数値を使用することが推奨されるため、スクラッチダメージはごくわずかです。結局、最小ダメージが1で、10 Hpしかない場合、それはあなたの健康の10％です。20 Hpであっても5％です。そして、絶対に必要でない限り、そのような大きな数字の使用は避けたいです。 ただし、スクラッチ損傷の非常に重要な利点が1つあります。デッドロックの問題を解決します。 どちらの側も他方にダメージを与えることができない場合、デッドロックが発生します。すべてのリソースを防御に投資し、攻撃にほとんど投資しない場合、キャラクターはダメージを受けないかもしれませんが、どちらもあまり対処できません。したがって、どちらの側もダメージを与えることはできないため、戦闘は永遠に続きます。これは特に、クリティカルヒット（これも嫌いです）のようなランダムなメカニズムがない場合です。 少なくともスクラッチ損傷があれば、最終的に誰かが勝ちます。これは、最もHPまたは攻撃数が最も多いものである可能性がありますが、戦闘は終了します。 だから、常に結果が出る戦闘システムを持つのが好きです。しかし、私は引っかき傷が好きではありません。私の選択肢は何ですか？ 乱数のローリングを含まない代替手段。戦闘を100％確定的にしたい。同じ戦いが行われた場合、まったく同じ結果が発生する必要があります。 ゲームプレイの詳細を知りたい場合は、ターンベースの戦闘の観点から考えてください。戦闘は自動化できます（部隊を設計し、他の部隊と対戦します）。

37 game-design 

コンソールとPCゲームには、開発者が見逃した/修正する時間がなかったバグを修正するためのパッチが時々あります。 私の質問は、これらがどのように機能するのですか？ 場合によっては、パッチファイルのサイズは数メガバイトです。小さなファイルがコンパイルされたプログラムをどのように変更できるか理解していません。

37 console  pc  patching 

ゲームの保存ファイルや他のゲーム生成データを保存する場所の、プラットフォームごとに1つ以上のディレクトリの明確なリストが必要です。OS開発者の仕様に基づいているか、推奨事項がない場合は一般的な使用方法であるため。 プラットフォームごとに1つの回答を、異なるディレクトリで提供してください。また、C ++またはCでディレクトリの場所を取得する方法の例が最適です。これは、あなたがより苦労する言語だからです。 場所： プレイヤーのゲームデータ（保存されたゲーム、設定）。 共有ゲームデータ（すべてのコンピューターユーザーのハイスコアや構成など）。 一時的なゲームデータ（キャッシュディレクトリ）。

37 savegame 

いくつかのカスタムゲームデータを保存する必要があります。地図、プレーヤーなど それらすべてに「サブオブジェクト」があります。たとえば、マップとマップにはタイルの「配列」があります。すなわち、階層データ。うまくいけばバイナリはありません。 これらに適したフォーマットは何でしょうか？ これまで私は考えてきました： シリアル化：これは高速で簡単ですが、基になるクラスを変更すると壊れる傾向があります:( XML：これを解析するのは本当に嫌いです。私のテストケースは100行以上のコードであり、非常に単純な形式でさえ、「忙しい仕事」のように思えました。 INI：階層データにとっては本当に不器用です。 Protobuf：使用したことはありませんが、クラスを変更した場合は、手作業で何度もいじり、中断する必要があることを読んでください。 別のオプション？だから私はここにいる！ 編集：これはJava btwです。 編集2： 「Controlled Binary Serialization」に決めました（以下を参照）。 長所： これは速い （ディスク上）小さく、読み取り/書き込み中に簡単に圧縮/解凍できます。 ゲームやツールセットからの読み取り/書き込みは非常に簡単です。 オブジェクトに含める/除外するものを決定できます。 オブジェクト/データはネストできます。 短所： 手動で編集することはできません（XML、YAMLなど） スクリプトで簡単に読み取り/変更できない デフォルトでは、Javaシリアル化は他の実装に比べてかなり遅い/肥大化していますが、安定して動作します

37 java  file-format  xml  data  file 

実行時に特定のピクセルの色を変更する必要がある、メガマンのようなゲームに取り組んでいます。参考：メガマンでは、選択した武器を変更すると、メインキャラクターのパレットが選択した武器を反映するように変更されます。スプライトのすべての色が変化するわけではなく、特定の色のみが変化します。 プログラマーはパレットと、ピクセルとパレットインデックス間の論理マッピングにアクセスできるため、この種の効果はNESで一般的であり、非常に簡単に実行できました。ただし、最新のハードウェアでは、パレットの概念が同じではないため、これはもう少し困難です。 テクスチャはすべて32ビットであり、パレットを使用しません。 私が望む効果を達成するために知っている2つの方法がありますが、この効果を簡単に達成するより良い方法があるかどうか興味があります。私が知っている2つのオプションは次のとおりです。 シェーダーを使用してGLSLを記述し、「パレット交換」動作を実行します。 シェーダーが利用できない場合（たとえば、グラフィックカードがサポートしていないため）、「オリジナル」テクスチャのクローンを作成し、色の変更が事前に適用された異なるバージョンを生成することができます。 理想的には、シェーダーを使用したいと思います。シェーダーは簡単に見えるため、テクスチャの複製方法とは対照的に追加作業がほとんど必要ないためです。テクスチャを複製して色を変更するだけでVRAMが無駄になるのではないかと心配しています。心配する必要はありませんか？ 編集：私は最終的に受け入れられた答えのテクニックを使用することになり、これは参考のために私のシェーダーです。 uniform sampler2D texture; uniform sampler2D colorTable; uniform float paletteIndex; void main() { vec2 pos = gl_TexCoord[0].xy; vec4 color = texture2D(texture, pos); vec2 index = vec2(color.r + paletteIndex, 0); vec4 indexedColor = texture2D(colorTable, index); gl_FragColor = indexedColor; } 両方のテクスチャは32ビットであり、1つのテクスチャはすべて同じサイズ（私の場合は6色）であるいくつかのパレットを含むルックアップテーブルとして使用されます。ソーステーブルの赤チャンネルをカラーテーブルのインデックスとして使用します。これは、メガマンのようなパレット交換を実現するための魅力のように機能しました！

37 opengl  textures  palette 

事前のイベントによって偏ったチャンスベースのシステムを実装したいと考えています。 背景：数年前、私はWorld of Warcraftのアップデートを思い出します。彼らは、スパイクチェーンのイベントに対抗する新しいチャンス計算機を実装したことを発表しました。（たとえば、クリティカルストライクを行うか、連続して数回回避する）。アイデアは、あなたがヒットをかわす場合、次のヒットをかわす可能性は減少するが、それは両方の方法で働くということでした。ヒットを回避しないと、次のヒットを回避する機会が等しく増加します。ここでの主要なトリックは、いくつかの試行にわたって、覆い焼きの可能性がプレイヤーの統計シートでプレイヤーに与えられた割合に対応することでした。 この種のシステムは当時非常に興味をそそられ、今ではそのような解決策が必要な状況にあります。 私のトラブルは次のとおりです。 このようなシステムの実装に関するオンラインリソースを見つけることができると思いますが、それを見つけるための関連する話題の言葉が欠けているだけかもしれません。 また、2項式（つまり2つの結果）ではなく、4つの相互に排他的なイベントを含むシステムに適合するために、このアプローチが必要です。 私の現在のアプローチは、ラッフルチケットシステムのアプローチに似ています。イベントが発生すると、他のすべてのイベントを優先して重みを変更します。4つのイベントが等しく発生する可能性がある場合、これは機能する可能性がありますが、私の場合は、より広く普及する必要があります。しかし、一般的なイベントがより頻繁に発生するため、他のものの重みが意図したよりもはるかに大きくシフトし、イベントがあった初期値の周りに平均チケット数を維持するために必要な重みシフトの数値を見つけることができないようです与えられた。 いくつかの方向ポインターまたは明確な例が大歓迎です。

37 random 

私にはC ++ゲームプログラミングの本があり、その中にLuaセクションがあります。Luaセクションを読み始めましたが、面白いように聞こえますが、C ++ゲームでLuaを使用することの長所と短所を判断することはできません。私が現在考えることができる唯一の利点は、再コンパイルすることなく、Luaを介してコーディングの更新を行うことができることです。それ以外は、何も考えられません。それでは、C ++ゲームにLuaを追加することの長所と短所は何ですか？ 例をいただければ幸いです。

37 lua