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

6
パズルゲームが常に可能かどうかを知るにはどうすればよいですか?
私は、すべての白いタイルを取り除くことを目標とする一種のパズルゲームを作成しました。質問の最後に試してみてください。 毎回、ボードは5 * 5グリッドのランダムな場所に白いタイルでランダムに生成されます。そのグリッド上の任意のタイルをクリックすると、タイルの色と、タイルの両側でタッチしているすべてのタイルが切り替わります。私のジレンマは、不可能なボードを生成するかどうかわからないという事実です。このようなことを確認する最良の方法は何ですか? function newgame() { moves = 0; document.getElementById("moves").innerHTML = "Moves: "+moves; for (var i = 0; i < 25; i++) { if (Math.random() >= 0.5) { $(document.getElementsByClassName('block')[i]).toggleClass("b1 b2") } } } newgame(); function toggle(a,b) { moves += 1; document.getElementById("moves").innerHTML = "Moves: "+moves; $(document.getElementsByClassName('block')[a+(b*5)]).toggleClass("b1 b2"); if (a<4) {$(document.getElementsByClassName('block')[(a+1)+(b*5)]).toggleClass("b1 …

5
サーバー上のゲームロジック!良いまたは悪い?
現在、シンプルなオンラインマルチプレイヤーゲームを計画しています。そしてここに質問があります。サーバーでゲームロジック全体を作成し、クライアントからサーバーに入力を送信するだけで意味がありますか?長所と短所はどちらですか、そうしない理由はありますか?

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

5
ゲームロジックスレッドとレンダリングスレッド間の同期
ゲームロジックとレンダリングをどのように分離しますか?ここで正確にそれを尋ねる質問が既にあるように思えますが、答えは私にとって満足のいくものではありません。 私がこれまでに理解していることから、それらを異なるスレッドに分ける点は、ブロックされているスワップバッファ呼び出しからレンダリングが最終的に返される次のvsyncを待つのではなく、ゲームロジックが次のティックですぐに実行を開始できるようにすることです。 しかし、具体的には、ゲームロジックスレッドとレンダリングスレッド間の競合状態を防ぐためにどのデータ構造が使用されているか。おそらく、レンダリングスレッドは、描画対象を特定するためにさまざまな変数にアクセスする必要がありますが、ゲームロジックがこれらの同じ変数を更新している可能性があります。 この問題を処理するための事実上の標準技術はありますか。ゲームロジックを実行するたびにレンダリングスレッドが必要とするデータをコピーするようなものです。解決策が何であれ、同期のオーバーヘッドや、すべてを単一スレッドで実行するよりも少ないものは何ですか?

1
物理学とゲームロジックをUIコードから分離する
私は単純なブロックベースのパズルゲームに取り組んでいます。 ゲームプレイは、ゲームエリア内を移動するブロックで構成されているため、簡単な物理シミュレーションです。しかし、私の実装では、理想とはほど遠いものであり、より良い方法についての指針を教えていただけませんか。 多くのパズルゲームで行ったように、ゲームロジックとUIの2つの領域にコードを分割しました。 ゲームロジックは、ゲームの一般的なルール(チェスの正式なルールシステムなど)を担当します。 UIはゲーム領域とピース(チェス盤やピースなど)を表示し、アニメーション(チェスの駒のアニメーションの動きなど)を担当します。 ゲームロジックは、ゲームの状態を論理グリッドとして表します。各ユニットは、グリッド上の1つのセルの幅/高さです。したがって、幅6のグリッドの場合、幅2のブロックを境界と衝突するまで4回移動できます。 UIはこのグリッドを取得し、論理サイズをピクセルサイズに変換して描画します(つまり、定数を乗算します)。ただし、ゲームにはゲームロジックがほとんどないため、ゲームロジックレイヤー[1]は、衝突検出以外にはあまり関係がありません。仕組みは次のとおりです。 プレイヤーがピースをドラッグし始めます UIは、ゲームロジックにそのピースの正当な移動領域を要求し、プレイヤーがその領域内でそれをドラッグできるようにします プレイヤーは駒を手放す UIはピースをグリッドにスナップします(そのため、有効な論理位置に配置されます) UIはゲームロジックに新しい論理的位置を伝えます(ミューテーターメソッドを使用します。 私はそれに満足していません: ゲームロジックレイヤーのユニットテストを作成していますが、UIは作成していません。UIにはトリッキーなコードがすべて含まれていることがわかりました。ピースが他の人や境界と衝突してグリッドにスナップするのを止めます。 UIがゲームロジックに新しい状態を通知するという事実が気に入らないのでmovePieceLeft()、他のゲームのようにメソッドまたはそのようなものを呼び出すようにしたいのですが、そのアプローチにはあまり向いていません。ゲームロジックは、UIで可能なドラッグとスナップについて何も知りません。 最善の方法は、ゲームロジックレイヤーを取り除き、代わりに物理レイヤーを実装することだと思います。それに関していくつか質問があります。 このような物理層は一般的ですか、それともゲームロジック層にこれを行わせるのがより一般的ですか? グリッドへのスナップおよびピースのドラッグコードは、UIまたは物理レイヤーに属しますか? そのような物理層は、通常、ピクセルサイズまたはゲームロジック層のような何らかの論理ユニットで動作しますか? ゲームのコードベースでイベントベースの衝突検出を見たことがあります。つまり、プレーヤーがピースをドラッグするだけで、UIがそれを素直にレンダリングして物理システムに通知し、物理システムがonCollision()メソッドを呼び出します。衝突が検出されると作品に。もっと一般的なものは何ですか?このアプローチまたは最初に法的運動領域を求めていますか? [1] レイヤーはおそらく私が言っていることの正しい言葉ではありませんが、サブシステムは誇張されており、各レイヤーは複数のクラスで構成されているため、クラスは誤解しています。

3
UPSとFPS-何を制限する必要がありますか。その理由は何ですか。
現在C ++とSDL2を使用してゲームを作成していますが、疑問に思っていることが1つあります。毎秒のフレーム数(FPS)や毎秒の更新数(UPS)を制限することは理にかなっていますか? UPSを制限すると、基本的にゲームの速度を制御できると思います。プレーヤーが1更新あたり1ピクセル移動し、常に毎秒30回更新する場合、30ピクセル/秒の速度で移動します。 1秒あたりの計算量が減るため、おそらくCPUも解放されます。FPSを制限すると、1秒あたりのドローコールの量が減少するため、GPUが軽減されます。そのすべてを正しく理解できていれば幸いです。そうでない場合でも、自由に修正してください。 私の質問は-私のゲームで何を制限すべきですか?FPS?UPS?どちらも?どちらでもない?これに対する別のより良いアプローチはありますか?これはほとんどのゲームでどのように行われ、その理由は何ですか? 回答は大歓迎です!
11 game-loop  logic  sdl2 

3
オブジェクトをレンダリングから分離する必要があるのはなぜですか?
Disclamer:私はエンティティシステムパターンが何であるかを知っており、それを使用していません。 オブジェクトとレンダリングの分離についてたくさん読みました。ゲームロジックは、基盤となるレンダリングエンジンから独立している必要があるという事実について。それはすべてうまく、そしてダンディであり、それは完全に理にかなっていますが、他の多くの苦痛も引き起こします: ロジックオブジェクトとレンダリングオブジェクト(アニメーションの状態を保持するオブジェクト、スプライトなど)間の同期の必要性 レンダリングオブジェクトがロジックオブジェクトの実際の状態を読み取るために、ロジックオブジェクトを公開する必要があります(多くの場合、ロジックオブジェクトは、ダムゲッターおよびセッターオブジェクトに簡単に変換されます) これは私には良い解決策のように聞こえません。一方、オブジェクトをその3D(または2D)表現として想像することは非常に直感的であり、維持も非常に簡単です(そして、はるかに多くのカプセル化も可能です)。 グラフィックス表現とゲームロジックを一緒に維持し(同期の問題を回避)、レンダリングエンジンを抽象化する方法はありますか?または、上記の欠点を引き起こさないゲームロジックとレンダリングを分離する方法はありますか? (例として、私は抽象的な講演の理解があまり得意ではありません)

5
論理ゲームのデータ構造/控除規則/手がかりの十分なセット?
私は、アインシュタインのパズルに似たロジックゲームの開発について考えてきました。これには、新しいゲームのリプレイごとに異なる手がかりが含まれます。 提供する手がかりが一意のソリューションを指すことを保証するために、さまざまなエンティティ(ペット、家の色、国籍など)、控除規則などを処理するためにどのデータ構造を使用しますか? 控除ルールを考えられる手掛かりと一緒にプレイする方法を考えるのに苦労しています。どんな洞察もいただければ幸いです。

1
スリープを使用して単一スレッドでロジック/更新コードをレンダリング/描画コードから分離する
私は、ゲームオブジェクトの速度はFPSによって妨げられるべきではなく、時間に基づくべきであると読みました。更新/描画コードを分離して、描画速度を制限せずにパフォーマンスを最大化し、時間に基づいて一定のロジック更新速度を提供するにはどうすればよいですか? 私の現在の疑似コードは次のとおりです loop { draw(); if (ticksElapsed() > 100) { update(); ticks+= ticksElapsed(); } } 問題は、描画コードがupdate()レートのパフォーマンスを妨げていることです。また、スリープ状態になると、描画機能とロジック機能の両方が使用できなくなるため、CPUが100%消費されます。 私もSDLを使用していますが、vsyncオプションがないようです。固定および可変時間ステップという用語も聞いたことがありますが、sleep()でそれをどのように行うことができるかわかりません。

4
ソースのようなエンジンはエンティティをどのように処理しますか?
ソースエンジン(およびその前任者、goldsrc、quake's)では、ゲームオブジェクトは2つのタイプ(ワールドとエンティティ)に分かれています。世界はマップジオメトリで、エンティティはプレーヤー、パーティクル、サウンド、スコアなどです(ソースエンジンの場合)。 すべてのエンティティには、そのエンティティのすべてのロジックを実行するthink関数があります。 したがって、処理する必要のあるものがすべてthink関数を含む基本クラスからのものである場合、ゲームエンジンはリストにすべてを格納し、すべてのフレームでループしてその関数を呼び出すことができます。 一見すると、このアイデアは合理的ですが、ゲームに多くのエンティティがある場合は、リソースが多すぎる可能性があります。 では、Sourceなどのエンジンは、ゲームオブジェクトの処理(処理、更新、描画など)をどのように行うのでしょうか。

5
自分の冒険を選択-選択肢スタック
私は現在、独自のアドベンチャーゲームを選択して構築しています。これで、すべての選択に対して1つの結果が得られ、線形フローを作成するのは簡単ですが、以前のすべての選択が次の結果に影響を与えるための優れたアルゴリズムはありますか?私は明らかに以前のすべての選択を保存し、決定する大きな 'IF'ステートメントを持つことができましたが、もっと良い方法があるかどうか疑問に思いましたか? 私の一部は、すべての選択肢に「スコア」が必要かどうかを疑問に思っており、これを使用して(おそらくしきい値を使用して)次のアクションを決定し、各アクションをスコアに追加します。 私は主にこれをswift / SpriteKitで行っていますが、この時点でのコードよりもコンセプトのほうが重要だと思います。 以下のジョシュのコメントに応じて: 現時点ではまだ概念段階にあると思いますが、各「ページ」はカスタムオブジェクトまたはjsonファイルのいずれかになります。私はあなたの答え(現在は削除されています)について考えていましたが、各ENUMオプションを少し持っているかもしれません。次に、各ページに「スコア」を付けることができます。次に、選択した前のオプションを使用して、どのビットが設定され、どのページを決定するかを決定します。私が「ストーリー」をどのようにフォーマットするかを決定するのをほとんど手助けし始める前に、この問題に対する既存の解​​決策があったのかと思っただけだと思います 形式の大まかな推測: { "text":"You arrive in the dungeon and there are 2 doors", "options":[ 1: "Go left", 2: "Go Right" ], "score" : 0 // first page } {"text" "You went left and meet a dragon", "options":[ 0: "Game over, you were eaten" …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.