Développement jeux vidéo : quelles bases à avoir absolument ? [Débat]

[fqueinnec]

Excellent (les commentaires le sont encore plus, surtout quand on voit les (tres grands) noms derrieres ces commentaires)

http://altdevblogaday.org/2011/04/01...-and-patterns/

[Matthieu Brucher]

Les commentaire sur le design architectural n'a strictement rien à voir avec l'assembleur. Encore une fois, on peut être un excellent développeur en C ou C++ et comprendre les tenants et les aboutissants de chaque cache, de leur taille, de la taille de leur ligne, du nombre d'unités entières et flottantes, du micro-séquenceur et faire un code efficace derrière.

[Valmond]

Moi je me demande si le type a trouvé un job ou pas (le post date de 2002 ) ...

Sinon ouais, pour commencer dans du JV c'est bien de connaitre du C++ et des Algos, comme ça tu peux apprendre n'importe quel autre langage au besoin (plus facilement).
Puis après 6 mois de coder des menus on te filera un truc plus compliqué et tout à coup t'as 5 ans d’expérience dans plein de domaines différents ...

Enfin, de nos jours il y a des écoles de JV et tout, trop facile

[Takezo02]

En lisant ça moi je deviens tout complexer, je penses vraiment bien connaitre le C++, j'ai étudier et mis en pratique un tas de trucs (templates, pattern's, algo en tout genre, UML, X librairies et framework) cependant j'ai jamais étudier l'architecture de mes processeurs qu'ils soient Intel ou Amd. Travaillant aussi depuis un certain temps avec les moteurs de jeu Torque (toutes les versions) je me suis peu intéresser à l'optimisation en tant que telle(bas niveau). Pour moi elle devait être incluse sans m'en soucier...

J'ai repérer de l'assembleur dans le source de mes outils mais ça reste tout bonnement obscur. Je n'ai jamais pris la peine non plus d’étudier les instructions magiques SSE ou MMX ou 3DNow! mais en même temps existe t-il de bon tutos pour ça. Enfin tout ça pour dire que ça me remet en question sérieusement même si je ne développe pas sur console à l'heure actuelle.

Il serait bien d'orienter les gens sur les bons tutos ou bouquins concernant ces choses là.

Les compilateurs actuels ne sont ils pas capable de transformer le code de façon transparente pour en faire du hautement optimiser? Dans Visual C++ on peut choisir les options d'optimisations sur le linkage et l'executable, serait ce un leurre?Quelle est la portée et l'efficacité de ses soi disant optimisations?

Voilà les questions pour ma part.

[fqueinnec]

Salut Takezo02

inutile non plus de complexer... le fait meme que tu fasses la demarche de vouloir apprendre le SSE2 / SSE3 (MMX et 3DNow sont assez depassés maintenant) est une très bonne chose..
Je vais commencer par parler des optims du compilateur...
Un compilo sait optimiser, dans une certaine mesure... Dans bien des cas, ils font très bien leur boulot et donnent un code assez bon... Cependant, j'ai vu énormément d'exemples où ils faisaient du caca et n'optimisaient pas grand chose (surtout sur console) ! Lorsque l'on optimise, c'est même un reflexe à developper : verifier le code généré ! Le truc du "le compilo fait mieux que nous" est un mythe, point barre... Par contre, le truc, c'est vraiment d'orienter l'optimiseur pour lui faire faire ce qu'on veut...

Il faut être, par exemple, tout particulièrement attentif aux remplissages de vertex buffers et autres resources graphiques, qui sont souvent en WriteCombine (du moins sur console) et qui nécessitent vraiment de faire extrêmement gaffe au code généré par le compilo.


Et dans les cas des instructions SIMDs, le resultat est souvent bien mauvais.
Deja, inutile de tabler sur l'assembleur des le départ... Il te suffit de te faire une petite librairie de fonctions encapsulant les intrinsic SSE (et autres), ensuite, tu n'as plus à coder en asm du tout, tu appelles ces fonctions et là, le compilo fera son boulot.

Revenons en aux mauvaises perfs des compilos en matiere de SSE/Altivec/VMX : Les raisons sont simples : Deja, les données... Nombre de moteurs utilisent des vecteurs à 3 composantes, d'autres à 4 composantes mais non alignées, qui empêche le compilo de les prendre directement pour travailler dessus.
De plus, et ça, c'est surtout vrai sur console a base de PowerPC (PS3 & 360), il faut éviter toute opération manipulant des champs individuels.. car cela nécessite de "sortir" du copro pour repasser (grosse latence !) sur le CPU...

Par exemple :

Vec1 = Vec2 + Vec3;
Vec1.x = Vec4.x; // Tres tres mauvais !
if (Vec1.y > 12.0) // Idem, passage sur CPU + branch eventuel : Grosse penalité (+de 40 cycles sur certaines plateformes)
{
Vec1 = ZeroVec;
}

il vaut mieux faire :

Vec1 = VecAdd(Vec2 , Vec3);
Vec1 = VecSelect(Vec1, Vec4, Mask_TakeX); // on reste sur le copro
VecTest = VecGreater( VecSplatY(Vec1), VecSplatConst(12.0)); // Genere un mask entierement à FFFFFF si superieur, 0 sinon
Vec1 = VecSelect(Vec1, ZeroVec , VecTest);

ici, on reste entièrement sur le copro, aucune pénalité (hormis les inevitables latences entre instructions)... Le code est beaucoup beaucoup plus rapide

Et crois moi, aucun compilo n'est capable de faire ca automatiquement, AUCUN... Tu peux assez facilement (enfin avec un peu de pratique) obtenir un facteur 10 en codant comme ça...
Comme tu peux le voir, ici, je n'ai pas fait d'asm.. j'ai utilisé des fonctions inlinées contenant des intrinsics comme ici :

forceinline SSEVector VecGreater (SSEVector _V1, SSEVector _V2 )
{
#if defined(_XBOX360)
return __vcmpgtfp( _V1, _V2 );
#elif defined(_SSE2)
return _mm_cmpgt_ps( _V1, _V2 );
#elif defined(SN_TARGET_PS3)
.... etc...
#endif
}

J'ai vu un bon nombre de moteurs ayant des classes vecteurs "optimisées en SSE", mais utilisées n'importe comment et qui du coup, avaient des performances minables sur PowerPC... voire même bien plus lentes que leur équivalent en cpu...

Quant aux tutoriaux... Il doit bien y en avoir.. sinon, je dirais qu'il suffit de te faire une petite librairie encapsulant les instructions de base du SSE en lisant leur doc, puis ensuite de t'entrainer à l'utiliser un peu partout en essayant au maximum de ne pas "sortir" de ta librairie...

'fin voila...
bon courage

[bafman]

pour préciser sur le SSE, la base du problème est que les processeurs fonctionnent en utilisant des registres. chaque "unité" de calcul a son jeu de registres qu'il peut utiliser (APU, FPU, SSE). les registres SSE sont des registres 128 bits qui peuvent donc contenir 4 flottant 32 bits. le problème, c'est que le cloisonnement entre ces jeux de regitres est strict (et c'est parfaitement justifié d'un point de vu materiel). Du coup, quand on a une donnée x dans un registre SSE et qu'on veut l'utiliser dans un calcul FPU, le processeur est obligé de passé par un truc super lent qui s'appel... la mémoire... il est obligé d'extraire la donnée du registre SSE, la stocker en memoire, puis la recharger dans un registre FPU. La memoire etant lente (comparativement à une operation en registre), on se tape des dizaine de cycles de latence. Du coup, plus on fait de changement de jeux de registre, plus on perd de temps. C'est pour ça qu'on conseil, autant que possible, de ne pas melanger le code SSE et le code FPU.

tout ceci, sans parler des load hit store et autre joyeuserie qui font que le SSE est un très bon moyen de gagner des perfs, mais surtout, sont particulièrement dépendant de la façon dont on presente les données.

Et pour revenir au sujet initial, on trouve plein de tutos sur l'utilisation des intrinsic SSE sur le net, le principal problème etant de trouver un domaine ou les utiliser pour se faire la main...

[Takezo02]

@bafman

le principal problème etant de trouver un domaine ou les utiliser pour se faire la main...

A priori, d'après ce que j'ai pu lire cette dernière semaine sur le sujet, le domaine d'application est très large et en ce qui concerne le développement de jeux vidéo, les calculs matricielles sont fortement impactés ainsi que les codecs Audio/Vidéo.

Comme c'est passionnant, je vais m'organiser pour progresser sur cette voie là et être plus complet sur ce sujet.

Merci pour vos réponses

[bafman]

ha mais je ne dit pas que le domaine n'est pas vaste, je dit just que le plus dur pour débuter, c'est de trouver dans quel domaine on va l'utiliser

partir sur une lib de calcul vectoriel est un bon début. sinon, faire de petits exercices de manipulations d'images peut être très formateur aussi. Personnelement, je recommande de faire ses premier pas dans un domaine qui demande la manipulation de gros buffers (comme les images justement) car c'est la qu'on a les plus gros gains de perf et c'est super motivant pour continuer.

je me suis amusé a faire de petits tests hier soir chez moi sur un calcul simple sur des gros buffers de données, j'ai reussi à passer de 900ms pour la version c++ FPU standard à environ 120ms pour la version SSE la plus optimisée

[Youille]

Bonjour à tous, et merci pour toutes ces informations à dispositions des néophytes. C'est une vraie mine de connaissances !
Après avoir lu le topic, je remarque toutefois que vous n'avez pas abordé l'Action Script 3. Je sais juste de ce langage qu'il est celui de Dofus 2 et du jeu Transformice.

Pourriez-vous me donner votre avis sur ce langage par rapport aux autres ?

Merci dans tous les cas !

[LittleWhite]

L'action Script 3, donc du Flash est une technologie pour le web. Cela fonctionne principalement dans les navigateurs, ce qui n'est pas une mauvaise chose. Par contre, le Flash a tendance à être plus lent que d'autres technologies, mais comme ils sont implémentés sur presque tous les postes clients, le marché est assez énorme.
Bien sur, on ne fera pas de Flash pour un jeu ayant pour cible des consoles.

Les jeux sont bien souvent limité à la 2D, mais la sortie de la version 11 devrait changer les choses.
Le langage est assez "simple", par rapport au C / C++.

Il existe de nombreuses bibliothèques pour commencer facilement à faire son jeu. J'ai personnellement eu l'occasion d'essayer Flixel qui je pense n'est pas mal du tout.

[Dabou Master]

Désolé de rapporter mon grain de sel dans un sujet vieillissant (voire mouru) mais super meat boy c'est un jeu qui visait d'abord la console, mais il me semble que c'est du flash non ?
Rien n'empêche que je me trompe mais un "c'est l'exception qui confirme la règle" me paraîtrait un peu inapproprié dans ce cas.

Au pire oubliez ma remarque ^^.

[LittleWhite]

Meat Boy, la première version, est un jeu Flash. C'était un peu le prototype du jeu.
(Tout comme World of Goo qui a eu un prototype en flash).

Après, un jeu visant le monde console, ne sera pas en Flash (je n'ai pas souvenir que ce soit compatible)

Un jeu qui a "bien marché" tout en Flash (sur Steam en plus) c'est Binding of Isaac (crée par ceux qui ont fait Super Meat Boy)

[Dabou Master]

On parle pas des jeux qui fâchent

Ce jeu il est sympa mais il raaaame !!!!
J'ai pas une foudre de guerre comme pc en ce moment c'est sûr, mais lagger à ce point pour un jeu en 2D ça me fait toujours mal au coeur ^^.
J'étais convaincu que super meat boy était en flash mais j'ai dû me tromper autant pour moi. Mais après ce à quoi j'ai pu jouer, je conseillerais le flash en aucun cas .

[tlt]

En tout cas, je remarque que les besoins ont changé au fur et à mesure que les années s’écoulent rien qu'en lisant ce sujet.
Néanmoins, il y a certains besoins qui n'ont pas trop changé à savoir: la connaissance d'au moins un langage (qui plus est orienté objet) , un peu de math (ou beaucoup), ... de la patience (beaucoup) et un cerveau qui pense

Pour ma part, je pense aussi que le programmeur doit avoir au moins quelques notions de graphisme (voire même plus):
genre le fonctionnement des meshs, les effets graphiques , les matériaux , les lumières ... à part le fonctionnement de la machine et autres trucs liés à la programmation.

Bref, est ce que je me trompe si je dis qu'il a besoin de tout savroir (ou presque)
Et donc plus il connait des choses, mieux c'est

[idmapria]

Je suis pas sûr que la question du topic soit bien formulée...

Développeur de jeux c'était un métier dans les années 80 mais aujourd'hui ça n'est plus un seul métier, c'est plein de métiers différents où chacun est spécialiste sur son truc à lui. Entre celui qui bosse sur le calcul de lags, celui qui bosse sur telle ou telle partie du moteur graphique, celui qui bosse sur tel ou tel portage, celui qui a le nez dans les problèmes de hardware, celui qui coordonne l'équipe, celui qui code telle ou telle partie mécanique d'un moteur, celui qui travaille sur les personnages/objets, celui qui bosse sur la physique, celui qui bosse sur les parties intefaces/menus/appli/multimedia, celui qui bosse sur les script end-user, ceux qui r&d et ceux qui prod... aujourd'hui développer des jeux ça regroupe une centaine de métiers différents.

Même au niveau du langage y'a pas de tronc commun, y'a de tout... déjà côté moteur ça peut être c ou c+ ou asm plus les managé (java,c#) et tous les scripts exotiques divers et variés (ça nous fait déjà donc des dizaines de langages possibles), et côté tools genre éditeur/convertisseur gfx/son/mesh/maps/scenars/scripts/etc alors là t'as tous les langages du monde possibles.

Le seul tronc commun là dedans... heu... ben c'est qu'on tape du code

Donc la question "quelles bases avoir pour coder des jeux", je serais bien incapable d'y répondre... par contre la question "quelles bases avoir pour bosser sur telle partie d'un jeu" là c'est sans doute mieux posé.


Quand à la question qu'une bonne partie des lecteurs de ce topic se pose, quelles bases pour les jeu indy/amateur c'est à dire avec des moyens minuscules et un mec qui code tout seul... ben d'abord il faut choisir un "poste" sur lequel on va travailler et là bah... dans l'indy on voit deux alternatives:

1 - soit tu mises sur un jeu très rétro comme à l'époque où les jeux étaient faits par un mec tout seul (genre pacman) et là tu vas tout coder. donc au niveau des bases il faut un minimum de connaissances en maths

2 - soit la méthode "moderne", tu te mets en poste de end-user, tu vas paramétrer un moteur tout fait, et là les bases à avoir dépendent entièrement du moteur choisi

3 - soit entre deux chaises, la solution béquilles qui mâchent à moitié le travail mais qui te laissent libre au niveau du gameplay général (librairies ou midware). et là les bases, c'est flou... il faut des connaissances en algo, mais il faut aussi bien connaître l'outil choisi