Dossier Faire des jeux - partie II

Articles GZ
1

[center][/center]

Après avoir jeté un oeil du côté des outils plutôt orientés 2D, nous voici de retour pour parler des solutions orientés 3D, pour des projets plus importants. L’étage au dessus quoi. Plus complexes, plus fournis, ces outils demandent un certain background en programmation pour en délivrer toute la puissance. Quoique, vous pouvez aussi faire comme ces enthousiastes qui choppent le SDK de Half Life et sortent un mod quelques mois plus tard, sans avoir tapé une ligne de C++ avant ça.

[center]Unity : the new guy

[/center]

Unity est un produit complet, qui contient un éditeur de scene, un éditeur de scripts (une version maison de SciTe), un pipeline d’import d’assets. Faisant un usage intensif de l’interface graphique, tout ou presque peut être manipulé dans l’éditeur et l’inspecteur d’objets. Cependant, vous aurez quand même besoin de taper du code. Pour ça, Unity gère trois langages de script : C#, Javascript, et Boo, utilisables indifférement. En effet, tout est compilé en code intermédiaire pour être exécuté sur Mono, une implémentation open-source du Runtime .Net de Microsoft. Voilà pour la partie technique, je ne vous embête pas plus longtemps avec ça.

La communauté autour de Unity est déjà conséquente, et très active. De nombreux wiki, extensions, plugins, et bouts de codes sont à disposition du néophyte comme de l’utilisateur avancé. Pour le confort de développement, Unity gère maintenant la synchronisation avec Visual Studio et l’utilisation d’une solution de Source Control dans l’editeur. Enfin, Unity a d’abord été développé sur Mac, puis porté récemment sur Windows. Celui-ci est donc disponible pour ces deux plateformes.

Cerise sur le gâteau, depuis la sortie de la version 2.6 cet automne, la version de base de Unity, anciennement “Unity3d Indie”, est devenue totalement gratuite. Un certain nombre de fonctionnalités ne seront pas utilisables (comme les ombres en temps réel par exemple), mais le coeur suffira pour développer un jeu complet sans problème.

Unity permet de cibler les plateformes PC et Mac, le Web via un plugin proprio (modulo quelques fonctionnalités, comme les shaders super avancés, etc), l’iPhone, et la Wii.

[center]
Minotaur China Shop et Off Road Raptor Safari, de FlashBang Studios[/center]

Nom : Unity
Prix : $0 pour la version de base, $1500 pour la version Pro (avec plein d’options partout et des versions pour Wii, iPhone, ou d’autres trucs) (plus d’infos)
Plateforme : Windows et Mac
Quelques jeux notables : Tout ce qui sort du studio FlashBang, jouable sur le site Blurst

[center]UDK : l’Unreal Engine à pas cher

[/center]

�?a été le coup de tonnerre de cette fin d’année 2009 : Epic livrait pour la première fois au public un standalone de son SDK (comprendre : pas besoin d’acheter un jeu pour pouvoir bidouiller un mod), avec des fonctionnalité supplémentaires, à destination des hobbyistes et des petites entreprises. Avec une renommée internationale, une tétrachiée de jeux “Unreal Engine 3 Powered” et le soutien de son porte monnaie, Epic a donc décidé de tacler le marché du dev indé sur PC. Avec un système de licences qui embrasse à peu près tous les cas de figure, même le plus petit studio peut se permettre de se lancer dans l’aventure.

L’UDK s’accompagne des fichiers permettant de coder en Unreal Script, de l’éditeur Matinee, d’une impressionnante collection d’exemples (héritage de 10 ans de développement du moteur), un éditeur de scènes, un éditeur de niveau, etc.

Bref, un bon point d’entrée en matière, et une bonne opportunité de faire de l’expérience sur ce moteur incontournable de l’industrie du Jeu Video.

[center]
Prometheus et The Ball, deux ex-mods UT3, nouveaux standalones.[/center]

Nom : UDK
Prix : gratuit, avec un système de royalties en cas d’activité commerciale (plus d’infos)
Plateforme : Windows
Quelques jeux notables : Tout ce qui s’est fait avec l’UE 3, mais plus particulièrement les différents mods UT III portés récemment sur UDK, comme Prometheus ou The Ball.

[center]NeoAxis Engine : the new, new guy

[/center]

Assez peu connu, le NeoAxis Engine est un ensemble d’outils construits autour du moteur de rendu Ogre3d, et de différentes bibliothèques (open source ou non). Il en résulte un moteur assez versatile, capable de donner naissance à toutes sortes de jeux, voire d’applications professionnelles (le showcase du site contient un certain nombre de projets “non jeux”).

Pour la partie technique, NeoAxis Engine est construit sur .Net pour toute la partie éditeurs, avec des wrappers pour les libs externes. De base, tout est disponible pour créer un jeu from scratch : gestion des terrains, de zones indoor/outdoor, de la GUI, de la physique (via PhysX ou ODE), du son spatialisé, du réseau. Pour tout ce qui est gameplay, le moteur utilise un système d’entités, que le développeur étendra en ouvrant son editeur de code préféré, pour y écrire du C#.

Le système de licences est assez large, avec plusieurs prix en fonction des utilisations. Un SDK non commercial est accessible gratuitement, afin de prototyper et tester le moteur. La licence “Indie” est disponible a $95, tandis que la licence commerciale monte a $395. Enfin, la licence “complète”, avec code source, s’élève à $9800, mais là, on n’est déjà plus dans les objectifs de ce dossier.

[center]
Sacraboar[/center]

Nom : NeoAxis Engine
Prix : $0 pour le SDK non commercial, $95 pour la licence Indie, $395 pour la licence commerciale (plus d’infos)
Plateforme : Windows
Quelques jeux notables : Sacraboar

[center]D’autres pistes …[/center]

Il existe bien sur d’autres middlewares du même style. Citons rapidement Torque3d et Shiva3d. Vous pouvez aller faire un tour sur DevMaster.Net, le site catalogue de reference en matière de moteurs de jeux.

2

[quote=“Ravine, post:1, topic: 50647”][/quote]Tiens ce logo me semblait familier : apparemment c’est la techno utilisée par EA Sports pour la création des GameFace, pour mettre votre tête sur les avatars virtuels de leur jeux via une photo.

Très bon article encore une fois. Content de voir que pas mal de ces outils utilisent C#, il ne me restera plus qu’à trouver le temps de jouer avec.

3

Je suis un peu moins bete a chaque article. Merci m’sieur. :smiley:
Peut-etre en parleras-tu dans un futur post dedie, mais je voudrais comprendre l’etat de l’art en matiere de modelisation physique.
J’ai cru comprendre qu’il existait des cartes d’acceleration pour soulager le processeur, en plus de la carte graphique; OK. Mais de quoi parle-t-on exactement?

Est-ce que les devs determinent les degres de liberte des objets 3D a animer (articulations des membres pour les organismes, rouages et segments pour les machines), leur affectent un poids, une resistance, une elasticite…etc?
La facon dont se deforment les textures des vetements dans les jeux (Dragon Age Origins pour exemple, puisque c’est a ca que je joue en ce moment) n’est pas realiste: on sent que la texture est simplement plaquee a la surface des polygones et qu’elle bouge avec eux au lieu de glisser sur la peau. Est-ce une limitation par le bas pour tenir compte des capacites de calcul des PC sur lesquels tourneront les jeux ou y-a-til encore un frein technique a la modelisation d’objet fluides comme la soie ou les poudres?

Concernant le rendu de la lumiere, pourrais-tu m’expliquer simplement la difference entre ce qui se fait aujourd’hui dans les jeux et le raytracing pur et dur? A l’epoque, j’avais un truc qui calculait une pauvre image pendant 3 jours sur mon Atari ST et je pensais qu’en 2010, tous les jeux utilisaient le raytracing a la volee, mais il me semble que ce n’est pas le cas. Ai-je raison?

Enfin, j’ai lu il y a quelques annees un article sur un moteur utilisant des « patatoides » plutot que des polygones pour la construction des objets 3D: il y avait des images assez convaincantes ou on voyait des objets tout en courbes douces plutot qu’en lignes brisees. Est-ce utilise? Quelles sont les limites?

Desole de poser des questions de n00b, mais je n’y connais a peu pres rien et le sujet m’interesse pas mal, donc je saute sur l’occasion.
Et puis si t’es pas content, fallait pas commencer a poster des trucs aussi interessants! :smiley:

4

Ces outils utilisent C#, et le fait que j’en parle ne dois pas etre etranger a ca. Je connais plus facilement les outils ou j’ai un minimum de skill. J’evoque tres rapidement Torque3d et Shiva3d, je ne sais pas ce qu’utilisent ces moteurs, mais ils existent. Et il y’a aussi DarkBasic et Blitz. Pareil, je ne connais pas donc vous n’aurez pas plus d’infos de ma part. J’espere juste que vous ne m’en voudrez pas de ne pas pouvoir etre exhaustif a ce niveau. :confused:

5

De carte d’acceleration hardware, linké via [Carte->Driver->API] au moteur physique du jeu qui permet « d’accelerer » directement les calculs physique en les prenant en charge a la place du proc. En gros, de la meme maniere qu’une carte graphique gere les graphismes (ou tout du moins les accelerent, parce que le proc est encore responsable de beaucoup de choses (mais de moins en moins)), une carte PhysX va prendre en charge une partie des calculs lié a la physique.

Ca c’est clairement chacun sa recette. Mais en gros et en general, ca tend vers l’approche la plus « realiste » possible. Donc, avec des animations IK (cinematique inverse), des blends d’animations, des bones (pour l’animation generale), pour le moteur physique, c’est pareil, tu vas definir des materiaux (de la meme maniere que tu pourrais definir des materiaux pour le rendu) et leur differentes reactions lors d’une collision (la restitution). Donc oui :smiley:

Il n’y a de limite que dans la puissance de calcul disponible je serais tenté de te dire. DAns un film d’animation, tout ca va etre reproduit a la perfection. Dans un jeu, faut quand meme tenir un rythme de rendu de malade, donc ca feinte, le but etant d’approcher le plus de ce qu’on veut au moindre cout (en puissance j’entends). Oui encore une fois :smiley: (Finalement, ya peu de secret hein)

Pour le rendu, il y a plein de techniques, mais gloablement, la en ce moment, c’est rendu de polygones ou deferred shading (qui est ni plus ni moins la meme chose, avec quelques differences). Intel esperait arriver comme un cake avec son Larabee et faire ho magie, vous utilisez vos API habituelles, nous on transforme ca en raytracing a la volé et hop, on a un peu le best of both world. Finalement, ca a pas marché, le raytracing est encore ultra couteux, meme si on va bientot y arriver. La dans l’idée, j’ai mit plein de mots clés en gras si tu veux plus d’infos, go wikipedia ou google :slight_smile:

Hum, la tu parles de rendu ou de physique ? Parce que c’est large la comme ca :slight_smile: Si c’etait niveau rendu, ca pourrait etre des nurbs ou ce genre de choses, si c’est niveau physique, c’est evident que pour les raisons de cout en calcul, on se limite a des patatoides (exemple sur un jeu que je connais pas trop mal, les personnages sont des cylindres, tout betement, et les projectiles sont des spheres, ni plus ni moins :P). Faire une restitution au niveau du polygone est extrement couteuse, sans compter qu’elle a peu d’interet puisque au final, c’est juste un niveau intermediaire entre le patatoide et le detail le plus proche de la realité.

Voila :slight_smile: Finalement, ya peu de miracles, c’est juste de la feinte et de la bidouille (de haut niveau, certes, mais de la gruge).

6

Ou le voxel ? (utilisé dans Outcast entre autres)

Pour ajouter ma pierre à l’édifice, il y a aussi Shiva 3D, un outil qui permet de créer des jeux 3D assez simplement. Le logiciel est multi-support (windows, linux, mac, iphone, etc) et permet de créer des jeux online (navigateurs) ou offline. C’est français (cocorico), ça existe depuis pas mal d’années maintenant et surtout il y a un bon support et une bonne communauté derrière. On peut télécharger une version d’essai et des exemples/tutos pour découvrir son potentiel, tout ça ici.

7

/mode chieur
Ca serait pas un anglicisme ?

8

[quote=“vorkosigan, post:7, topic: 50647”]/mode chieur
Ca serait pas un anglicisme ?[/quote]

Au contraire, ce serait plutôt même un emprunt que l’anglais à fait au français étant donné que le mot vient du latin. Il est en tout cas au dictionnaire de l’académie française depuis 1935 (merci Wiktionnary).

9

Yes!, merci AnA-l d’avoir pris le temps de m’expliquer tout ca.

Edit: je viens de jeter un coup d’oeil aux nurbs et voxels sur Wikipedia. Je ne crois pas qu’il s’agisse des « patates » que j’avais vues et je vais tenter de m’expliquer plus avant.
Pour faire une analogie risquee, je dirais qu’elles etaient a la 3D ce que Acrobat est a Word pour le rendu des polices: on peut zoomer en avant, il n’y a pas de crenelage.
J’avais donc l’impression que la surface n’etait pas rendue par une multiplication de petits polygones donnant l’illusion d’une courbe lisse (ce que je viens de voir pour les voxels et les nurbs). Au contraire, j’avais l’impression que la surface etait « calculee » avec des lignes courbes des le debut, pas des lignes brisees.

Bon, j’arrete le mode n00b, vu que je ne sais pas de quoi je parle… :smiley:

10

Les NURBS SONT des courbes calculées justement ( ta phrase est un peu ambiguë et on dirais que tu dis que les NURBS sont une succession de poly alors pour être sur!), et donc tu peux zoomer dessus ça sera toujours clean (comme du vectoriel dans le graphisme).

Après est ce que les Nurbs sont utilisées dans la 3d temps réel j’en sais rien mais ça m’intéresserait de le savoir.
Je suppose que c’est hyper-couteux en terme de calcul.

Sinon ya Krys64, qui a un site sur Unity, et qui développe un jeu actuellement.

11

Les nurbs sont effectivement des courbes calculées, mais la carte graphique, elle, ne sait que faire des rendus de triangles. Donc ce qui se passe, c’est que la courbe paramétrée est calculée soit sur le CPU soit sur le GPU (en fonction des capacités de la carte graphique) et est splittée en d’autant de petits triangles pour faire l’illusion d’une courbe parfaite. Cela s’appelle la tessellation, et ATI avait déjà tenté de pousser cette technique dans ses premières Radeon (la 7200), mais Microsoft n’avait pas suivi à l’époque. La tessellation est revenue sur le devant de la scène à cause du support officiel de cette technique dans DirectX 11.

12

Oui et non, en Dx 11, c’est pas que des triangles ( http://www.realtimerendering.com/blog/dire…i-tessellation/ ). D’ailleurs, les points sprites et les linestrip, c’est pas des triangles hein :smiley: Et c’est pas Dx 11. ( Qui, je suis d’accord, ramenes la tesselation sur le devant de la scene.)

13

Oui bon j’ai pas parler des points et des lines DirectX <11, parce qu’en général on les utilise quand même peu et que 99% du rendu ca reste quand même des surfaces paramétrées et donc de la tesselation de triangles :D.

Par contre, point très intéressant je ne savais pas que DirectX11 introduisait d’autres types de surfaces que les triangles. /me va voir l’article.

Chougar Edith:

Dois je en conclure que ca fini quand même par balancer des triangles/quad à la fin?

14

Ouais, ben j’etais alle un peu vite en besogne. J’ai lu un peu plus en detail sur les nurbs et comprends mieux. :smiley:

15

De la même façon, j’imagine, que les images vectorielles sont quand même finalement retranscrites en pixels pour l’affichage.
L’important étant que tu auras les courbes les plus fines possibles compte tenu de la puissance de ta machine, quelque soit le niveau de zoom (du fait de la résolution ou de la proximité d’un objet.)

16

[quote=“nbertrand59, post:15, topic: 50647”]De la même façon, j’imagine, que les images vectorielles sont quand même finalement retranscrites en pixels pour l’affichage.
L’important étant que tu auras les courbes les plus fines possibles compte tenu de la puissance de ta machine, quelque soit le niveau de zoom (du fait de la résolution ou de la proximité d’un objet.)[/quote]
Ah ben voila, tu l’as ecrit. Je ne voulais pas dire de connerie plus grosse que moi en parlant d’images vectorielles, mais c’etait excatement ce que j’avais en tete.

Au risque d’accaparer le propos avec des questions de neophyte (auquel cas j’en serais bien desole), est-ce que ca veut dire qu’un objet vectoriel est calcule de deux facons differentes: une “premiere fois” avant l’affichage (mais ou? comment?) et ensuite une “seconde fois” pour sa retransciption graphique a l’affichage?

Je sais qu’il existe des tutorials, des FAQs et autres, mais je trouve ca tellement plus tripant de me faire expliquer ces trucs en live par ceux qui bossent dedans…

[HS]On a sans doute des visions un peu deformees des professions que l’on aurait voulu exercer, mais l’infographie et la 3D, je m’imagine toujours que c’est une forme d’extase professionnelle. Je ne suis pas naif sur les conditions reelles de travail, mais bon, ca ma fait rever comme ado, quoi. [/HS]

17

Bah les formes vectorielles ca restes des courbes paramétrées. donc au lieu de dire “voilà le pixel x,y a une couleur rouge”, tu dis “tous les pixels en dessous de la courbe d’équation y = 2x + 3 sont rouges”. Ca te permet de ne pas être dépendant de la résolution de l’écran, et lors de l’affichage, on calcule au final la couleur de chaque pixel en fonction des expressions mathématiques qui la composent.

18

Ecstatica 1 et 2 et son rendu a base d’ellipsoïde ?

19

Ouais, donc la, c’est comme les voxel d’outcast, c’est du rendu full software (comme le raytracing actuellement en fait, meme si ca commence a etre accelerable par les GPGPU).

Mais au final, qu’on reste clair, le device de sortie, c’est un ecran, donc ya forcement une etape de rasterization, afin d’en sortir des pixels.

Ca, comme l’a dit mon cher collegue Moddib :

20

Je pense que tu viens de me donner l’accès au logiciel que je cherchais depuis un bon moment
si il est aussi « aisé » d’accès que je l’espère il pourrait me permettre de faire des choses assez rapidement.