「2.5D」という用語の意味がわかりません。2.5Dと3D環境の違いについては特に混乱していますが、両方について異なる定義と記事を読んでいます。2.5Dが3Dのような部分は理解していますが、2.5Dが異なる部分は得られません。

それでは、ゲームが2.5Dであるとはどういう意味ですか？たとえば、ゲームは2.5Dで表示されますか？

2Dおよび3D（おそらくご存じのとおり）という用語は、ユークリッドワールド空間の空間次元の数を指します。この次元は序数でなければなりません。半次元のようなものは存在しないため、2.5Dという用語は実際にはナンセンスな用語であり、本質的な意味はありません。とは言っても、2.5は2と3の間の「どこか」であるため、2.5Dは一般に「2Dと3Dの間のどこか」の線に沿ったものを意味します。

個人的には、この用語を使用して、ゲームのグラフィカルな世界空間と論理的な世界空間の次元が異なる場合を指します。特に、ここには2つの異なるバリアントがあります。

• 2D論理および3Dグラフィカル。たとえば、2Dのゲームメカニクスと物理学を備えたプラットフォーマーですが、3Dメッシュとパースカメラでレンダリングされます。パックマン、ブレイクアウトなどの古典的なアーケードゲームのほとんどのリメイクは、このカテゴリに分類されます。下の写真：Pineapple Smash Crew

• 3D論理＆2Dグラフィカル。例には、3Dゲーム世界を持っているが2D等角図でレンダリングされるGnomoriaやSimCity 2000などのゲームが含まれます。下の写真：Xenonauts

この用語のもう1つの一般的な使用法（私が使用しているものではありません）は、3D グラフィックスとビルボード化された 2Dグラフィックスの組み合わせを利用するゲームを指します。この場合、この用語はゲームの論理的な次元をまったく説明しません。実質的にすべての3Dゲームは、パーティクルシステム、遠隔オブジェクトプロキシ、インワールドUIオーバーレイなど、何らかの方法でビルボードを使用します。したがって、この用語は通常、非背景オブジェクトの大部分が2Dグラフィックスを使用し、2.5Dと3Dの境界が多少ぼやけている場合にのみ使用されます。

「2.5D」という用語が適用された最初のゲームはDoomでした（Wolfenstein 3Dもある意味で資格があります）。

Wolfenstein 3Dは、基本的に3Dプレゼンテーションを備えた2Dゲームでした。2Dの迷路をナビゲートし、すべての床が平らで、すべての天井が同じ高さで、窓がなく、ドアが床から天井まであり、横に開いていたため、他のオブジェクトの上または下にいることはできませんでした。ゲームはレイキャスティングを使用して、画面の列ごとに、その方向に壁がどれだけ離れているか、壁にどのテクスチャがあったかを把握しました。次に、壁のテクスチャの列が距離に反比例する高さで描画され、上下のスペースが床の塗りつぶしと天井の塗りつぶしでペイントされました。敵とオブジェクトはスプライトであり、アスペクトの数は限られており、そのサイズは距離に比例します。

DoomはWolfenstein 3Dと非常によく似たテクノロジーを使用していましたが、より多くの3Dエクスペリエンスを得るためにそれを悪用しました。地図はまだ2D、2Dバイナリ空間分割を使用して表されます（したがって、.BSPマップファイル名）。タブを押したときにオートマップで見たのは、マップの直接2Dレンダリングでした。しかし、各セクターには独立した「床の高さ」と「天井の高さ」があり、エッジには上下のテクスチャがありました（周囲の一部よりも天井の高さが低い、または床の高さが高い場合に使用されます）。これにより、階段、窓、プラットフォーム、プール、およびその他の効果が可能になりました。エンジンは、最終的に壁にぶつかる前に通過した複数のセクターのリストと、それぞれのテクスチャを保持できなければなりませんでした。しかし、あなたはまだ本当の3Dアーキテクチャを持つことができませんでした-床の上げられたセクションを使用して、いくつかのスライムに「橋」を作ることができますが、下にあるものは不可能です橋。ゲーム内での位置はまだXとYのみです。プレーヤーが自分の高さを制御できるのは、物と、エレベーターで、床の高さを変更するためにスクリプト化された単なるセクターです。敵はまだスプライトであり（より多くの側面があったと思いますが）、衝突検出は2次元のみであり、ゲームには3Dモデルが見つからなかったため、ショットは高さで「自動照準」します。

異端者とヘキセンは、時として「2.75D」と呼ばれるまで、さらに一歩進んだDoomから派生したエンジンを使用しました。彼らはほとんど同じアーキテクチャ上の制限とスプライトベースの敵を抱えていましたが、プレイヤーが上下を見たり（ビューを傾けたり、エンジンが壊れるまで）、ジャンプ、飛行、しゃがむ能力を追加しました（高さを個別に変更する）。

2.5D

主にビデオゲーム業界で使用される2.5D（「2半次元」）、¾パースペクティブ、および疑似3D ar用語。2Dグラフィカル投影や一連の画像を生成するために使用される同様の手法のいずれかを説明するために使用されます（またはシーン）が実際にはそうでない場合に3次元（3D）の外観をシミュレートする、または2次元平面に制限されている3次元のビデオゲームでのゲームプレイ。

私の経験では、どの定義が強調されるかは、話し相手の年齢に依存します。

1. 高齢のゲーマーは、実際にはそうではないが、一連の画像（またはシーン）が3次元（3D）の外観をシミュレートするために使用される2Dグラフィック投影および類似の手法を使用する傾向があります。

2. 若いゲーマーは、2番目の定義「2次元の平面に制限されている3次元のビデオゲームでのゲームプレイ」を使用します。

個人的には、2番目の定義を使用します。私の意見では、Trine、Donkey Kong、およびSuper Mario Bros Wii Uはすべて2.5Dです。さらに、2.5D Steamタグは2番目の定義を使用します。私はこれが典型的なゲーマーがどのようにコンセプトを定義するかについての良いリトマス試験であると考えています）、そのため、第2の定義がより正しいと信じています。

3D

3次元で計算された3Dゲームグラフィックスを備えたビデオゲーム。これにより、2番目の2.5D定義のスーパーセットになります。

2.5Dは、2Dを3Dに見える便利な方法です。
たとえば、3Dエンジンを使用し、ゲームプレイを2Dプレーンのみに制限する場合、定義の線を実際にぼかすことができると思いますが、個人的には、2.5Dは3D に見えますが、2D として機能すると考えています。

投稿したゲームのスクリーンショットは3Dゲームです。

3Dゲームでは、頂点を使用してオブジェクトを描画し、実際の3Dオブジェクトを描画します。その後、オブジェクトを色付けしたり、テクスチャを付けたりします。

2Dゲームでは、オブジェクトはスプライト/スプライトシートなどから取得されます。

2つの違いは、表示方法です。スプライトは平らな紙のようなものです。別のピッチや角度で表示することはできません。そうしないと、スプライトが歪んでしまいます。3Dオブジェクトでは、カメラが移動すると、オブジェクトが3Dであるため、オブジェクトのさまざまな部分を見ることができます。

2.5Dゲームでは、これらの両方の世界を組み合わせています。カメラを動かしてさまざまな角度を見ることができないからといって、3Dではなくゲームを作らないという点に留意してください。これを決定するのは、その中にあるオブジェクトです。

2.5Dゲームの良い例は、ラグナロクオンラインです。2.5Dになっているのは、世界の大部分が3Dオブジェクトに感染していることです。建物、風景などはテクスチャ3Dオブジェクトです。頭上カメラを回転させて、これらのオブジェクトの異なる側面を同時に見ることができます。建物の正面だけでなく、左/右/屋根エリアを表示できます。ただし、プレーヤーは2Dスプライトであり、上に立つように配置されています。カメラを回転しすぎると、ゲームはそのキャラクターのスプライトシートの別のセルを読み込んで、立っているように見える方法を変更する必要があります。3Dではないため、キャラクターのさまざまな角度を表示することはできません。角度は、カメラのビューに応じて動的にロードされます。

http://sprites.technoized.com/images/sprite/ro/gm_m.png

これはゲームのスプライトシートです。ただ見ただけなら、それは2Dゲームのものだと思います。単独で、あなたは正しいでしょう。しかし、3Dの世界に配置されると、2.5Dゲームができます。

多くの場合、2.5Dは「等尺性」を表す別の方法です。2Dグラフィックは、3Dの外観を与えるように描画されますが、実際には3D座標をシミュレートするわけではありません。等尺性グラフィックに関するウィキペディアの記事を参照してください：http : //en.wikipedia.org/wiki/Isometric_graphics_in_video_games_and_pixel_art

要点は、2.5D /アイソメトリックでは、グラフィックを計算するためだけにx軸とy軸を持つ2D座標系を使用しているということです。グラフィックは単純に2Dスプライトであり、通常は3つの顔が見えるように描画され、（x、y）座標を使用して画面に配置されます。スプライトは、3Dでモデリングし、複数の角度から3Dモデルの2Dスプライトを作成することによって作成されることもあります。

移動するオブジェクトは、特徴的に見ることができる角度がわずかです。アイソメビューでキャラクターを回転させると、スムーズに回転しませんが、正面、3/4、側面など、いくつかの明確な角度が表示されます。これは、それぞれのユニークな画角がまったく新しいスプライトのセットを必要とするためです。

このタイプのシステムの制限のため、アイソメトリックゲームは通常1つのカメラアングルのみをサポートします。等尺性ゲームのもう1つの際立った特徴は、通常、消失点がないことです。実生活でオブジェクトを見るとき、オブジェクトがあなたに近い場合、オブジェクトはあなたの視覚でより大きく見えます。オブジェクトが遠くにある場合は、小さく表示されます。等尺性ゲームでは、空間内のどこにいても、すべてのオブジェクトは通常同じサイズで表示されます。

3Dゲームと比較して、x、y、zの3つの軸すべてをシミュレートします。非常に低いレベルでは、コンピューターはx、y、zをx、yに変換してモニターに表示しますが、より高いレベルでは、アーティストは実際に3軸上のポイントを操作してオブジェクトを表しています。コンピューターはオブジェクトの形状に関するすべての情報を持っているため、そのオブジェクトがどのような角度で見えるかを動的に計算できます。

一部のゲームは、2.5Dと真の3Dが混在しています。私が考えることができる例は、3D背景と2Dスプライトを特徴とするDisgaeaシリーズです。

どの定義がより受け入れられるかはわかりませんが、私と私の前の会社の人々は、「等尺性3Dのように見えるが、2Dスプライトを介してレンダリングされるゲーム」は2.5Dであると考えました。

では、なぜそうしたのかを説明しましょう。一般に、多くのオブジェクトを含む3Dワールドをレンダリングすると、処理に過度の圧力がかかり、FPSカウントが低下します。そのため、これを克服するために、一般にMayaなどの3Dレンダリングソフトウェアでオブジェクトを作成し、スプライトとしてレンダリングしました。ゲームで使用できます。レンダリング中に角度が考慮されたことは言うまでもありません。したがって、パブリッシャーとこの技術について話すために、通常この用語を使用しました。2Dの世界のように見える3Dの世界は、技術的にはまだ3Dです。したがって、通常、このメソッドの用語は使用しませんでした。ここで私のビットを共有する必要があると思った。

通常、「2.5-D」という用語は、2つの非常に異なるスタイルのゲームの1つを指します。

次のいずれかを意味します。

1）2Dレンダリングテクニックを使用するゲームですが、3つの空間次元で制御します。通常、グラフィックトリックを使用して、実際に3Dでレンダリングされたかのように表示します。これは90年代には非常に一般的でしたが、今日ではそれほど多くありません。（例：「DOOM」、「Duke Nukem 3D」、「Wolfenstein 3D」）

2）完全に3Dでレンダリングされたゲームですが、1つ以上の2D平面に沿って排他的に制御します。このスタイルは今日でも非常に人気があります。（例：「リトルビッグプラネット」、「ニュースーパーマリオブラザーズ」、「トライアルHD」）

モデルビューコントローラーアーキテクチャパターンを使用する場合、ゲームの最初のスタイルには、データを3次元で表す「モデル」がありますが、ユーザーに2次元でのみ表示する「ビュー」があります。ゲームの2番目のスタイルは逆です。

2.5Dでは、2Dアセット/レンダリングテクニックを使用して、3D環境の感覚を与えます。

さて、その定義では、次の曖昧な可能性のあるシナリオでは、いくつかの詳細が必要です。

ゲームA

3Dグラフィックス、GPUアクセラレーション、およびすべて（ゲームオブジェクトは画像ではなくメッシュ）を使用し、カメラの角度を固定します。さらに悪いことに、投影は正投影で、古典的な63.43度です。グラフィックが2Dではないことを一見してわかる唯一の方法は、3DGCは、細心の注意を払ってレンダリングすることを除いて、レンダリングに使用される投影に関係なく、手描きのスプライトと簡単に区別されるためです。さまざまなレンダリング手法、パラメーター、シェーダーなどを試すことができますが、それらが3Dメッシュであるという事実を隠そうとするのは大変です。

ゲームB

ゲームAの移植版ですが、3Dグラフィックスをうまく処理できない、またはまったく処理しないハードウェアを搭載していることが知られているプラ​​ットフォームをターゲットにしています。次に、ポートはメッシュをスプライトに置き換えます。たとえば、衝突には3Dバウンディングボックスが使用され、オブジェクトにはx、y、zの値を持つ位置プロパティがあります。ゲームロジックはほとんど触れられていないかまったく触れられておらず、レンダリングコードのみが変更されたためです。

ゲームBのスプライトはゲームAの3Dアセットのレンダリングであり、より曖昧にするために、ゲームAは複雑なシェーダーを必要としないため、そこにあるすべてのGPUの99％でフレームをゲームと区別することはできませんゲームAのフレームのB

2.5Dでは、ゲームオブジェクト間の相互作用は、3Dの錯覚が損なわれない一連の状況に限定されます。たとえば、2人のキャラクターがハグすることを表すには、2人のキャラクターが相互作用する単一の画像ファイルを作成する必要があります。キャラクターボディをパーツに分割して、正しい順序で描画することもできます。3Dでは、この問題は存在しません（2つのキャラクターが他のキャラクターのメッシュに侵入しないように正しくポーズを設定している別のものが存在します）。

ここで、これを視覚化するために、ゲームAとBにバグがあり、状況によってはプレーヤーキャラクターが別のゲームオブジェクトを通過でき、2.5Dと3Dを簡単に区別できると想像してください。

ゲームB、2.5Dレンダリング、スプライトは、その位置ベクトルのz値によって順序付けられます。この例では、正のzがダウンし、負のzがアップしています。z軸とy軸は平行ですが、zはyの0.5倍にスケーリングされます。したがって、可視領域が10yから-10yの場合、同じ領域に20zから-20zがあります。zが大きいオブジェクトは後から描画されるため、zが小さいオブジェクトの前にあるように見えます。影は床よりも上の層にありますが、他のすべてのオブジェクトよりも下の層にあるため、プレイヤーキャラクターの影は奇妙に見えます。そのため、プレイヤーキャラクターの影は立方体の上には決してありません。

ゲームA、3Dレンダリング。深度バッファー（zバッファーとも呼ばれます）は、ピクセル精度の深度テストに使用されます。したがって、オブジェクトが別のオブジェクトを完全に遮る必要はなく、三角形でさえ別のオブジェクトを完全に遮る必要はありません。ピクセル精度深度テストがあります。ゲームオブジェクトを任意の方法で回転させることができ、それらが相互作用するときに現実的な結果を得ることができます。

再開：2.5Dでは、スプライトは別のスプライトの前または後ろにあります。3Dでは、メッシュは三角形で構成されていますが、深さをテストするときの三角形は最小単位ではないため、ピクセル精度を得ることができます。もちろん、固定カメラアングルに対してアセットが作成されたため、2.5Dでのカメラの回転は不可能です。3Dでは当然ですが、3Dゲームでカメラの角度が設計によって制限されている場合は別です。

2Dグラフィックスのみをレンダリングできる場合に3Dの世界にいるような感覚を与えるためのさまざまなトリックがあります。

常に3Dを常に使用し、2.5Dを忘れないのはなぜですか？

開発者が2.5Dアプローチを好む理由のいくつかの例で考えることができます。

• 3D API（Direct3D、OpenGL、他にもあります）を知らない、または気に入らないかもしれません。
• ターゲットプラットフォームが3Dグラフィックス（古いデスクトップコンピューター、2Dコンソール）をうまく処理できない可能性があります。
• あなたのチームは素晴らしいスプライトを作成できますが、3Dモデルは作成できません。

2.5Dを使用して3Dグラフィックスの結果をどの程度近似できますか？

パフォーマンスとプログラミングの複雑な地平線があります。その地平線に近づくと、プロジェクトが実際に2.5Dで実現できるのか、完全な3Dに移行する必要があるのか​​を疑い始めます。たとえば、（理論的には）2.5Dでzバッファリングを使用できますが、ビデオメモリコスト（強力なモバイルデバイスではなく、オンボードグラフィックスを備えた古いデスクトップコンピューター）を支払うことはできますか？すべてのスプライトのZマスクを保存するために追加のイメージを保持するストレージコストを支払いますか？

2.5Dの良い候補はRPGゲームです。Baldur's Gateシリーズ、またはRTSは、Age of Empires 1および2（AoE 3は完全に3Dであり、簡単に区別できます）と考えています。

便利なリファレンス：

Zバッファリング：http : //en.wikipedia.org/wiki/Z-buffering

正投影：http : //glasnost.itcarlow.ie/~powerk/GeneralGraphicsNotes/projection/orthographicprojection.html