Dans 2.5D, vous utilisez des ressources / techniques de rendu 2D pour donner la sensation d'un environnement 3D.
Maintenant, avec cette définition, dans le scénario potentiellement ambigu suivant, une élaboration est nécessaire:
Jeu A
À l'aide de graphiques 3D, le GPU a accéléré et tout (les objets du jeu sont des maillages, pas des images), avec un angle de caméra fixe. Rendons-le encore pire, la projection est orthographique, les 63,43 degrés classiques. La seule façon de remarquer à première vue que les graphiques ne sont pas 2D est parce que 3DGC, sauf que vous les rendez avec un soin extrême, se différencie facilement des sprites de dessin à la main, quelle que soit la projection utilisée pour les rendre. Vous pouvez expérimenter différentes techniques de rendu, paramètres, shaders, etc., et vous aurez du mal à cacher le fait qu'il s'agit de maillages 3D.
Jeu B
Un portage du jeu A, mais ciblant des plates-formes connues pour avoir du matériel qui ne gère pas très bien les graphiques 3D ou ne le gère pas du tout. Ensuite, le port remplace les maillages par des sprites. Il utilise toujours des boîtes de délimitation 3D pour les collisions, par exemple, et les objets ont une propriété de position avec des valeurs x, y et z, car la logique du jeu n'a généralement pas été touchée ou pas du tout touchée, seul le code de rendu a été modifié.
Comme les sprites du jeu B sont des rendus des actifs 3D du jeu A et, pour rendre les choses plus ambiguës, le jeu A ne fait rien qui nécessite des shaders compliqués, dans 99% de tous les GPU, vous ne pouvez pas différencier une image du jeu B d'un cadre du jeu A.
Dans 2.5D, l'interaction entre les objets du jeu est limitée à l'ensemble des situations où l'illusion de la 3D ne peut pas être compromise. Pour représenter deux caractères étreignant, par exemple, vous devrez créer un fichier image unique avec les deux caractères interagissant, car essayer de représenter l'action de câlin en n'utilisant qu'une seule image par caractère serait trop difficile ou impossible. Vous pouvez peut-être venir avec un corps de personnage divisé en parties et les dessiner dans le bon ordre. En 3D ce problème n'existe pas (il en existe un autre qui pose correctement les deux personnages pour qu'ils ne pénètrent pas dans le maillage de l'autre personnage).
Maintenant, pour visualiser cela, imaginez que les jeux A et B ont un bug qui, dans certaines situations, permet au personnage du joueur de passer à travers un autre objet de jeu, ce qui nous permet de différencier facilement le 2.5D et le 3D.
Jeu B, 2.5D Render, les sprites sont classés par la valeur z de son vecteur de position. Dans cet exemple, le z positif est en baisse et le z négatif en hausse. l'axe z et l'axe y sont parallèles mais z est mis à l'échelle par un facteur de 0,5 de y. Donc, si la zone visible est de 10y à -10y, dans la même zone, nous avons de 20z à -20z. Les objets avec un z supérieur seront dessinés plus tard, ils seront donc vus comme devant des objets avec un z inférieur. L'ombre du personnage du joueur a l'air bizarre parce que les ombres sont dans une couche supérieure au sol, mais dans une couche inférieure à tous les autres objets, de sorte que l'ombre du personnage du joueur n'est jamais au-dessus du cube.
Jeu A, rendu 3D. Le tampon de profondeur (également appelé z-buffer) est utilisé pour les tests de profondeur de précision des pixels. Donc, un objet n'a pas besoin d'en occlure complètement un autre, même un triangle n'a pas besoin d'en occlure complètement un autre, nous avons un test de profondeur de précision en pixels. Nous pouvons faire pivoter les objets du jeu de n'importe quelle manière et obtenir des résultats réalistes lorsqu'ils interagissent.
En résumé: en 2.5D, un sprite est devant ou derrière un autre sprite. En 3D, un maillage est constitué de triangles, mais le triangle n'est pas l'unité minimale lors du test de profondeur, vous pouvez avoir une précision en pixels. Bien sûr, la rotation de la caméra en 2.5D est impossible car les actifs ont été créés pour un angle de caméra fixe, tandis qu'en 3D, c'est naturel, si les angles de la caméra sont restreints par la conception dans un jeu 3D est un autre sujet.
Il existe différentes astuces pour donner l'impression d'être dans un monde 3D lorsque vous ne pouvez rendre que des graphiques 2D, je n'ai présenté qu'un exemple rapidement élaboré en utilisant certains atouts d'un de mes projets abandonnés.
Pourquoi ne pas simplement utiliser la 3D toujours et oublier le 2.5D?
Eh bien, je peux penser dans certains exemples pourquoi un développeur peut préférer l'approche 2.5D:
- Peut-être qu'ils ne connaissent pas ou n'aiment pas les API 3D (Direct3D, OpenGL, il y en a d'autres).
- Peut-être que la plate-forme cible ne gère pas bien les graphiques 3D (anciens ordinateurs de bureau, consoles 2D).
- Votre équipe peut faire des sprites incroyables mais pas des modèles 3D.
Combien pouvez-vous approximer les résultats des graphiques 3D en utilisant 2.5D?
Il y a un horizon de performance et de complexité de programmation. Lorsque vous vous rapprochez de cet horizon, vous commencez à douter si votre projet est vraiment possible en 2.5D ou si vous devez aller en 3D. Par exemple, vous pouvez utiliser la mise en mémoire tampon z en 2.5D (en théorie), mais pouvez-vous payer le coût de la mémoire vidéo (ancien ordinateur de bureau avec carte graphique intégrée, pas d'appareils mobiles puissants)? Voulez-vous payer le coût de stockage d'une image supplémentaire pour enregistrer le z-mask de chaque sprite?
Les bons candidats pour 2.5D sont les jeux RPG, pensez à la série Baldur's Gate ou RTS, pensez à Age of Empires 1 et 2 (AoE 3 est entièrement en 3D et se différencie facilement).
Références utiles:
Z-Buffering: http://en.wikipedia.org/wiki/Z-buffering
Projections orthographiques: http://glasnost.itcarlow.ie/~powerk/GeneralGraphicsNotes/projection/orthographicprojection.html