ゲーム開発

プロおよび独立系ゲーム開発者向けのQ&A

2
企業がVisual Studioの本当に古いバージョンをまだ使用しているのはなぜですか?
C ++が使用されている理由を理解しています。それはこの質問についてではありません。 ゲームをインストールすると、一般的にSteam(最近はSteamのみを使用します)は、配布可能なC ++ 2005ランタイムをインストールします。 私の質問は、なぜこれが当てはまるのですか?8年以上前にリリースされたランタイムが依然として普及している理由は何ですか?私が最近インストールしたゲームのいくつかは少し古いので、2、3年の開発時間を想定すれば、それがその時点で実証済みのテストされた標準であると言えるでしょう。 ゲーム会社がVC ++ランタイムの新しいバージョンを使用しないのはなぜですか?
9 c++ 

2
LibGDX And​​roidゲームからFacebookにスコアを投稿するにはどうすればよいですか?
私はLibGDXを使用してAndroidゲームを作成しています。ゲームのHTMLバックエンドは作成していません。AndroidのGoogle Playストアに置いておきたいだけです。 スコアをFacebookに投稿することはできますか?もしそうなら、どうすればいいですか?Webベースのゲームのみのソリューションを検索して見つけました。

2
IFステートメントで1つではなく2つのシェーダーを使用する
私は比較的大きなopengl ES 1.1ソースをES 2.0に移植する作業をしています。 OpenGL ES 2.0(つまり、すべてがシェーダーを使用する)では、ティーポットを3回描画したいと思います。 最初のものは、均一な色(古いglColor4f)です。 2つ目は、頂点ごとのカラーです(ティーポットにも頂点カラーの配列があります)。 3つ目は、頂点ごとのテクスチャです。 そして、おそらく4番目の1つで、頂点ごとのテクスチャと色の両方があります。そして、多分5番目のもので、法線も含まれます。 私が知る限り、実装には2つの選択肢があります。1つ目は、動作を変更するように設定されたユニフォームを使用して、上記のすべてをサポートするシェーダーを作成することです(たとえば、単一カラーユニフォームまたは頂点ごとのカラーユニフォームを使用します)。 2番目の選択肢は、状況ごとに異なるシェーダーを作成することです。一部のカスタムシェーダーの前処理では、それほど複雑ではありませんが、描画オブジェクト間でシェーダーを切り替える際のパフォーマンスコストが問題になります。私はそれがささいに小さくないことを読みました。 つまり、これを行う最善の方法は、両方を構築して測定することですが、入力を聞くのは良いことです。
9 opengl-es  glsl 

1
GPUでの地形の生成
私のエンジンでは、CPUで計算されたPerlinノイズalghoritmを使用して無限地形を作成します。 地形の作成は次のようになります。 カメラがアンロードされたパッチに近い場合、作成します 与えられた境界で513x513ノイズ配列を計算します 法線、接線、従法線、インデックスを計算する データをvboに渡す 長所: 必要なときにのみレンダリングする必要がある 衝突しやすい コン 遅い64個の513x513パッチが3,1s(1スレッド)で作成されます。各タイルについて、〜20msのノイズの作成、〜25msの頂点、法線、正接、正接、インデックス。カメラが速く動くとき、ユーザーはタイルのロードに気づくことができます。 メモリを消費する??? 今私はGPUで地形を完全に生成することによってこれをスピードアップする方法を考えていましたが、いくつかの疑問があります: シェーダーがすべてのフレームを実行する場合、この計算能力はノイズを何度も計算するために無駄になりませんか?これは、結果をRBGAテクスチャに書き込み、後で頂点シェーダーでディスプレイスメントに使用することで回避できますが、メモリ使用量が増加します。一方、作成が非常に高速になる場合は、表示されているタイルのみをメモリに保持する必要があります。ただし、バッファーを切り離すと、gpu-cpu syncが発生し、アプリの速度が低下する場合があります(私は正しいですか?) テレインが頂点シェーダーによって置き換えられたフラットグリッドである場合、CPUで同じ作業を実行して、衝突の特定のポイントで高さと法線を計算する必要があります。 これは単なる概念ですが、すべてを高速化するために、ビューポートにグリッドを投影することを考えていたため、使用される頂点は最小限に抑えられています。これでうまくいくと思いますか? 私の最後の質問は: GPUで無限地形を作成するために最もよく/最も速く/広く使用されているテクニックは何ですか?
9 terrain 

2
ポイントとサイズをいつ構造体として表す必要がありますか?
私の単純なRuby 2Dゲーム開発フレームワークの一部として、私のゲームオブジェクトには位置(xとyの値)とサイズ(幅と高さ)があります。 class MyGameObject attr_accessor :x attr_accessor :y attr_accessor :width attr_accessor :height ... 私が見た別のアプローチは、位置をPoint構造として扱い、サイズを構造として扱うことでしたSize: Point = Struct.new(:x, :y) Size = Struct.new(:width,:height) class MyGameObject attr_accessor :position # Point instance attr_accessor :size # Size instance ... 一部のフレームワークでは前者を使用します(GDX、Gosuなどだと思います)。他のユーザーは後者(cocos2d-iphone)を使用します。問題は、(ゲーム開発における)両方の動作の長所と短所が完全に明確ではないことです。一部のフレームワークが一方を選択し、もう一方を選択しない理由がわかりません。 考慮すべき重要な違いはありますか?

2
振り子を振る方法を教えてください。
おもりをつけて、振り子のように前後に揺れるロープをシミュレートしたい。実際の物理学は過剰です。同じ動きを延々と繰り返すだけです。 jQueryは、私が探しているものに似た「スイング」の容易さを備えています。それはどのように機能しますか? である角度から別の角度に回転することを考えてMath.easeOutExpoいましたが、実際の振り子は別の方法で緩和されます...

2
ボクセルフェースクロール(メッシュの単純化、場合によっては貪欲を使用)
編集:これは私自身の学習経験のためだけのものであり、私がこの質問をするのはパフォーマンス上の理由のためではありません。 これはMinecraftのような地形エンジンに関するものです。ブロックをチャンク(16x256x16ブロック)に格納します。チャンクを生成するときは、複数の手順テクニックを使用して、地形を設定し、オブジェクトを配置します。生成中は、チャンク全体(ソリッドまたは非ソリッド)に1つの1D配列と、ソリッドブロックの個別の1D配列を保持します。 生成後、隣接するソリッドブロックを繰り返し処理して、隣接するソリッドがないブロック面のみを生成します。生成する顔を独自のリストに保存します(これは、可能な顔/法線ごとに1つずつ、6つのリストです)。チャンクをレンダリングするとき、カメラの現在のチャンクのすべてのリストと、他のすべてのチャンクのカメラに面するリストのみをレンダリングします。これを行うには、6つのリストすべてを1つのバッファーに格納し、描画する範囲を変更します。 Andrew Russellが提案したこの小さなシェーダートリックで2Dアトラスを使用して、類似した面を完全にマージしたいと思います。つまり、それらが同じリストにある場合(同じ法線)、互いに隣接している場合、同じライトレベルである場合などです。最終的には四角形になることはわかっていますが、頂点の数を簡単に50%削減できるはずです私の見積もりが正しい場合はそれ以上。 私の仮定は、6つのリストのそれぞれを、それらが置かれている軸、次に他の2つの軸でソートすることです(ブロックの上部のリストは、Y値、X、Zの順にソートされます)。 これだけでも、非常に簡単に顔のストリップをマージできますが、可能な場合は、ストリップだけではなく、マージすることを目指しています。私はこの貪欲なメッシュアルゴリズムについて読みましたが、それを理解するのに多くの問題を抱えています。 だから、私の質問:説明されているように顔のマージを実行するには(動的なテレイン/ライティングの悪いアイデアであるかどうかを無視して)、実装が簡単なアルゴリズムがあるのでしょうか?また、私は貪欲なアルゴリズムをはるかに簡単な方法(リンクまたは説明)で案内する答えを喜んで受け入れます。 実装が簡単な場合や、ストリップを実行するよりも少しだけ優れている場合でも、パフォーマンスが少し低下してもかまいません。ほとんどのアルゴリズムは四角形ではなく三角形に焦点を当てているのではないかと心配しています。現在の方法で2Dアトラスを使用すると、現在のスキルに基づいて三角形を実装できるかどうかわかりません。 PS:私はすでにチャンクごとに錐台カリングを行っており、説明したように、ソリッドブロック間のフェースもカリングします。私はまだ閉塞淘汰をしていないし、決してしないかもしれない。 *編集:私は独自の小さなテクニックを実装しましたが、おそらく名前が付いていますが、6つのリストをたどります。これらのリストは、それらが置かれている軸、ブロックタイプ、照明レベルの順に並べ替えられています。私はそれらを反復処理し、移動しながら新しい長方形を作成し、同時に(特定の軸に向かって大きなバイアスをかけて)それらを成長させます。明らかに最適ではありませんが、実際には非常に高速であり、頂点数を平均で50%近く削減します。Byte56のコメントは、私が本当の答えを考えているクローゼットですが、答え/報奨金としてそれを選択することはできません。 これは、最適化をほとんど行わずに完全な初期地形を生成した後、この問題を処理する私の速くて単純な方法です。与えられたすべての正方形が同じ画像、光レベル、法線などであると仮定します。各色は、私がレンダリングする異なる四角形です。私のリストはそれらがそうであるようにソートされているので、これは非常に簡単/高速なアプローチです。

5
いくつのレベルを作る必要がありますか?
ロックされています。この質問とトピックへの回答はロックされています。質問はトピックから外れていますが、歴史的に重要です。現在、新しい回答や相互作用を受け入れていません。 私のゲームの多くで取り組む1つの問題は、ゲームに入れるレベルの数を決定しようとすることです。これは、ジャンルやプラットフォームに関係します。 一般に、決定する可能性のある制約(私の場合は適用されませんが)には、次のものが含まれます。 所定のスケジュールまたはリリース日 固定予算 ゲームのストーリーが終了/終了する (PCGゲーム):難易度が「不可能」になります これらはすべて素晴らしいですが、作成するレベルの数を教えてくれるほどの制約はありません。 理論上は良さそうに聞こえるが、実装するのが難しいもう1つの制約はゲーム時間です。たとえば、マリオやスーパーミートボーイの場合、xレベルごとの分数を推測しy、意図した合計ゲームプレイの分数を目標にして、レベルを得ることができy/xます。 しかし、これらのどれも私にはまったく正しいように見えません。レベルを追加するタイミングと停止するタイミングを決定するためのより良い方法があるはずです。

1
ミップマップを使用したテクスチャ座標の不連続性により継ぎ目が作成される
私はopenGLの学習を始めたばかりで、ミップマップで球体をテクスチャリングするときにこのアーティファクトを取得しています。基本的に、フラグメントがテクスチャのエッジをサンプリングするときに、不連続性(たとえば1から0まで)を検出し、最小のミップマップを選択して、この醜いシームを作成します。 醜い縫い目http://cdn.imghack.se/images/6bbe0ad0173cac003cd5dddc94bd43c7.png だから私はtextureGradを使用してグラデーションを手動でオーバーライドしようとしました: //fragVert is the original vertex from the vertex shader vec2 ll = vec2((atan(fragVert.y, fragVert.x) / 3.1415926 + 1.0) * 0.5, (asin(fragVert.z) / 3.1415926 + 0.5)); vec2 ll2 = ll; if (ll.x < 0.01 || ll.x > 0.99) ll2.x = .5; vec4 surfaceColor = textureGrad(material.tex, ll, dFdx(ll2), dFdy(ll2)); …

3
スロットルを回避する方法は?
私はネットワーク化されたiOSゲームを書いています。でパケットを送信するときGKMatchSendDataReliable(私はどの仮定 60のパケット毎秒(隣接パケット間のように16ミリ秒)、平均ping時間でUDPを書き込む自分のパケット受信コードであった)急速に悪化:私は次々 (以下7個のゲームセンターの一致を開い)、100パケットの「フラッド」を送信しました(毎秒60パケットのレートで)。私は平均往復時間を測定しました、そしてこれらは結果です: [ 21:16:39 ]: I saw an average roundtrip time of 52.342787 ms, he saw 54.496590 ms [ 21:16:34 ]: I saw an average roundtrip time of 62.631942 ms, he saw 61.991655 ms [ 21:16:45 ]: I saw an average roundtrip time of 88.394380 ms, he saw 83.619123 …
9 networking  udp 

2
水で満たされた領域を定義するにはどうすればよいですか?
私の小さなゲームエンジンを見栄えの良い水のシミュレーションで強化したいと思います。それに取り掛かるには、ゲームで水を表現する適切な方法を見つける必要があります。残念ながら、私は多くの異なる表現を知りませんので、私はあなたに尋ねます。少し前に私が尋ねた同様の質問があります。しかし、問題を明確に定式化していないので、答えは正しいですが、私が探していたものではありません。 一部のゲームでは、水は高さレベルによって定義されます。たとえば、高さが0未満のすべては水中です。私はこの表現を(主に古い)ゲームで見ました。問題は、浸水していない屋外の洞窟で、湖や海ごとに水位が異なることです。 水の発生のもう1つの、より正確な表現は、粒子です。すべての水滴は、ワールドスペースのポイントとして保存されます。それらをレンダリングするために、メタボールなどの手法を使用して、単一のメッシュを構築することができます。それらの間のダイナミクスを簡単に計算できるので、この表現はリアリズムにとって素晴らしいでしょう。残念ながら、リアルタイムでメタボールの海を計算できるマシンはありませんでした。 エンジンで水を表す他の方法はありますか?動的な湖が欲しいので、静的なジオメトリによって水域を定義することはできません。たとえば、プレーヤーが地形を変更して湖を広げた場合、水はその湾を満たし、その湖の全体的な水位はわずかに低下するはずです。

1
2D水上面プロファイル
頂点フラグメントシェーダーを使用して、水面の厚さの効果を作成しようとしています。 私は3Dゲーム環境にいますが、それはスクロールビューなので、「2D」ビューです。 以下は、フラグメントシェーダーを使用して実際の2Dでこのような効果を作成するための優れたチュートリアルです。 しかし、これは私の場合には使用できないと思います。今のところ、屈折を適用するのは平面だけです。 そして、水厚効果を適用したいです。しかし、私はそれを行う方法がわかりません。 現時点では、頂点を使用して水の変形/変位を作成しようとはしていません。これはポイントではありません。 シンプルなクワッドで可能かどうかはわかりませんが、このようなオブジェクトを使用する必要があるかもしれません。 下記は用例です。 この効果をどのように作成するかについては、私にはまったくわかりません。 どうもありがとう ! [ 編集 ]レイマンウォーターエフェクトが追加され、エフェクトの参照が改善されました。

2
Javaランタイムに依存せずにデスクトップJavaゲームを配布するにはどうすればよいですか?
Javaアプリケーションを「そのまま」実行するスタンドアロンパッケージに変換することは可能ですか?エンドユーザーは、Java JREをインストールする必要はありません。また、インストーラーにJREが含まれていて、ユーザーのためにインストールする必要もありません。 最終的なディストリビューションには、通常のデータファイルおよび必要に応じて追加のJARとともに、ネイティブ実行可能ファイル(できればWindows、Mac、およびLinuxごとに1つ)が含まれている必要があります。特に「1つのファイル」ソリューションを探しているわけではありません。実際には、データファイルを難読化しないでください。 これはどのように行うことができますか?

1
重いフラグメントシェーダーのパフォーマンスの最適化
次の一連のシェーダーの最適化についてサポートが必要です。 バーテックス: precision mediump float; uniform vec2 rubyTextureSize; attribute vec4 vPosition; attribute vec2 a_TexCoordinate; varying vec2 tc; void main() { gl_Position = vPosition; tc = a_TexCoordinate; } 断片: precision mediump float; /* Uniforms - rubyTexture: texture sampler - rubyTextureSize: size of the texture before rendering */ uniform sampler2D rubyTexture; uniform …

2
2つのコーナーがある斜めの見通し線
現在、私は視線にBresenhamのラインアルゴリズムを使用しています。問題は、プレイヤーが壁をのぞくことができるエッジケースを見つけたことです。プレイヤーが壁の2つの隅の間を、反対側に特定の角度でギャップがあるように見たときに発生します。 結果として、2つの壁の間のタイルに無効のマークが付けられます。 これを解決するためにブレセンハムのラインアルゴリズムを修正する最も速い方法は何ですか?良い解決策がない場合、より適したアルゴリズムはありますか?どんなアイデアでも大歓迎です。ソリューションは3Dもサポートできる必要があることに注意してください。 編集:私の簡単な解決策は、線のx座標とy座標が変化したときに両方の角が閉じているかどうかを確認することでした。完成した製品の実際のソースコードとインタラクティブなデモについては、http://ashblue.github.io/javascript-pathfinding/を参照してください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.