Tetris ゲームを作成しているとします。適切なプログラマーであれば、一方にビュー ロジックがあり、もう一方にビジネス ロジックがあります。おそらく本格的なMVCが進行中です。
モデルがその を送信するupdate()
と、期待どおりにビュー自体が再描画されます。
しかし...たとえば、ラインを消すアニメーションを追加したい場合、それをビューにどのように実装しますか?
「すべてが適切にカプセル化されている」ことを除いて、必要な仮定を立ててください。
Tetris ゲームを作成しているとします。適切なプログラマーであれば、一方にビュー ロジックがあり、もう一方にビジネス ロジックがあります。おそらく本格的なMVCが進行中です。
モデルがその を送信するupdate()
と、期待どおりにビュー自体が再描画されます。
しかし...たとえば、ラインを消すアニメーションを追加したい場合、それをビューにどのように実装しますか?
「すべてが適切にカプセル化されている」ことを除いて、必要な仮定を立ててください。
個人的には、ブロック位置の更新がなくても、できるだけ頻繁に画面を分割して描画します。したがって、 「更新」部分と「レンダリング」部分を含むループがどこかにあるでしょう。Update は、ポジションの更新および/またはブロックの削除を行う、または行わないロジックに対してボールを再生します。Render はグラフィック パーツにボールを再生し、ブロックをあるべき場所に描画します。
消去する行がある場合、ロジックはそれらの行を削除することを認識し、マークすることができます。ここでは、すべてのピースが 4 つの単一のブロックで構成され、これらのブロックのいずれかが単一のオブジェクトであると仮定します。このブロックに「ダイ」フラグが設定されている場合、レンダリング パーツを使用してブロックを消滅させることができます (たとえば、500 ミリ秒で爆発します)。この時間の後、オブジェクトは破棄される可能性があり、1 行上のブロックは落下します。なぜ500ミリ秒なのですか?そうですね、時間ベースの移動を使用することをお勧めします。これにより、さまざまなコンピューターでゲームの速度が同じに保たれます。
ところで、このような update-render-loop を提供する、いわゆるゲーム エンジンは既に存在します。たとえば、XNA の場合は、.NET ラインを使用します。独自のエンジンをコーディングすることもできますが、これは簡単な作業ではなく、非常に時間がかかることに注意してください。私はこれを一度行ったことがありますが、ソース エンジンのようなエンジンになるとは思っていませんでした ;-)
ほとんどのゲームは、モデルの状態が変化するのを待ってからビューを更新するのではなく、ゲームのビューをできるだけ速く再描画するループを実行します。
モデル ビュー パターンが気に入った場合は、モデルからオブジェクトが削除された後も、ビューがいくつかのタイプのオブジェクトを描画し続け、数ミリ秒かけてフェード アウトするのが適切に機能する可能性があります。
別のアプローチは、クラス MVC を差分実行のようなものと組み合わせることです。「ビュー」は表示されるもののモデルですが、描画コードは「ビュー」が作成するイベントのストリームを前のレンダリングからのストリームと比較します。したがって、あるストリームに線があり、次のストリームにない場合、描画コードはその違いをアニメーション化できます。これにより、図面をビューから抽象化できます。多くの場合、MVC の「ビュー」は、ディスプレイを直接描画するものではなく、ウィジェットのコレクションであるため、ネストされた MVC 階層になります。アプリケーションは MVC (データ モデル、ビュー オブジェクト、アプリ コントローラー) であり、ビュー オブジェクトにはウィジェットのコレクションがあり、それぞれが MVC です (ウィジェットの状態 (ボタンが押されたなど)、ルック アンド フィール/ツールキットのバインディング、ツールキット イベントのマッピング ->
私自身、これはよく疑問に思ったことです。
私自身の考えは次のようなものです。
1) ビューにはブロックの状態 (形状、yada-yada) が与えられますが、追加の「遷移」データが含まれます。
2) 行を削除する必要があるという事実は、ビューで計算されるのではなく、状態でエンコードされます。
3) ビューは現在遷移を描画する方法を知っています:
ゲームを MVC と考えるのは興味深いことです。これは私が取ったことのない視点ですが (奇妙な理由で)、非常に理にかなっている興味深い視点であることは間違いありません。MVC を使用して Tetris ゲームを実装すると仮定すると、コントローラーとビューの間の通信に関して考慮すべきことが 2 つあります。状態があり、イベントがあります。
コントローラーは明らかに、ユーザーの対話の中心点です。キーボード コマンドが発行されると、コントローラーはそれらを解釈し、適切な状態調整を行います。ただし、ゲームが特定のイベントと一致する状態になることがあります...たとえば、削除する必要があるブロックでラインを埋めます。
Scoregraphic は優れた基盤を提供してくれました。コンピューター間で一貫した速度を維持するために、ビューは一定のサイクルで動作する必要があります。ただし、画面を更新して新しい状態をレンダリングするだけでなく、応答してアニメーションを実行できるイベントのキューも必要です。Tetris で行を埋める場合、コントローラーは、ある種の基本イベント タイプから派生した厳密に型指定されたイベント オブジェクトをビュー イベント キューに発行できます。これは、ビューが適切なアニメーション応答を実行するために使用できます。