IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement 2D, 3D et Jeux Discussion :

XNA est-il mort ? Doit-on encore s'intéresser à la technologie de Microsoft pour faire des jeux ?


Sujet :

Développement 2D, 3D et Jeux

  1. #1
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2008
    Messages
    26 815
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mai 2008
    Messages : 26 815
    Points : 218 179
    Points
    218 179
    Billets dans le blog
    117
    Par défaut XNA est-il mort ? Doit-on encore s'intéresser à la technologie de Microsoft pour faire des jeux ?
    XNA est-il mort ? Doit-on encore s'intéresser à la technologie de Microsoft pour faire des jeux ?



    Présentation

    En tant que développeur de jeux vidéo, vous avez sûrement entendu parler de XNA. Peut-être même que vous vous y êtes intéressé et que vous avez développé des programmes ou des jeux avec.
    Pour rappel, XNA est une série d'outils proposée par Microsoft pour faciliter le développement de jeux pour les plateformes Windows, Zune, Windows Phone 7 et même la Xbox 360. Pour cela, XNA repose sur le langage C#, la bibliothèque de jeux DirectX, l'éditeur Visual Studio, le débogueur GPU PIX, l'outil audio XACT. Ce framework a été une des premières opportunités offerte aux développeurs indépendants de publier des jeux sur une console (la Xbox 360) et d'avoir une visibilité augmentée à travers le Xbox Live.
    Le public visé par cet ensemble d'outils sont les étudiants, les passionnés et les développeurs indépendants. Afin de bénéficier de la publication sur le Xbox Live Marketplace, il est nécessaire d'avoir un compte premium vendu au prix de 99 $ par an.
    Vous pouvez découvrir une présentation approfondie (analyse de l'architecture, description technique...) dans cet article.


    Historique

    La toute première version de XNA (appelée XNA Game Studio Express) a été publiée le 11 décembre 2006. Durant l'année 2007, une seconde version (XNA Game Studio Express 1.0 Refresh) est apparue, proposant une mise à jour de la version précédemment nommée. Ensuite, quatre autres versions ont été distribuées, toutes nommées XNA Game Studio (2.0, 3.0, 3.1, 4.0). La dernière version (4.0) a été publiée le 9 mars 2010.
    Pour information, la version 3.0 apportait le support de Zune et de la communauté Xbox Live, le C# 3.0, LINQ et la plupart des versions de Visual Studio 2008. La version 3.1 rajoutait le support du playback vidéo, une nouvelle version de la bibliothèque audio et le support des avatars Xbox 360. Quant à la dernière version, elle apportait le support de Windows Phone 7.5 et de Visual Basic.

    Avec cette version estampillée 4.0, les MVP (Most Valuable Professionals) ont été avertis que le support s'arrêterait courant avril 2014. Aucune autre version du framework n'est prévue et Microsoft ne travaille plus du tout dessus, comme il est possible de l'apprendre dans cette actualité. De plus, lors de la sortie de la quatrième version, des utilisateurs étaient confus par le rapprochement du framework avec le SDK de Windows Phone et à l'époque déjà, certains présageaient la mort du framework.


    Les jeux développés avec XNA

    De nombreux développeurs ont utilisé cette technologie pour publier leurs jeux, que ce soit sur Xbox 360 ou sur PC. Nous pouvons citer Terraria, Fez, Escape Goat, Dust : An Elysian Tail.... Il serait bien dommage d'oublier Chibis Bomba, un jeu présenté dans nos pages.


    Les alternatives

    Comme vous l'avez compris, Microsoft ne compte plus faire de mise à jour. Le support de Windows 8, ou des nouvelles versions de Visual Studio ne sera jamais réalisé. Pourtant, la technologie n'est pas morte. Cela est possible grâce au projet open source MonoGame. MonoGame est une implémentation libre de la bibliothèque XNA 4. La deuxième bonne nouvelle est que l'équipe ne se limite pas au support des plateformes Microsoft, car il vous sera aussi possible de cibler Mac OS, Linux, Android, PlayStation Mobile, OUYA ainsi que Windows 8 et Windows Phone 8.
    Le projet est toujours en développement actif et la version 3.2 a été publiée le 7 avril 2014. De nombreux projets professionnels l'utilisent déjà comme Bastion ou encore Fez.
    Il faut aussi noter que Microsoft utilise MonoGame pour supporter Windows 8 dans leur propre projet : Kodu.

    Si vous cherchez à tout prix à installer XNA 4 sur Visual Studio 2012 ou 2013, vous pouvez utiliser cet outil qui se chargera d'activer le framework dans les éditeurs de Microsoft.


    Conclusion

    Lors de sa sortie, le framework avait donné une opportunité très intéressante pour les étudiants qui souhaitaient s'insérer facilement dans le monde du développement de jeux vidéo, notamment grâce à une bibliothèque simplifiée et l'utilisation du langage C#, mais aussi pour les développeurs indépendants souhaitant cibler la console de jeux de Microsoft.
    Malheureusement, Microsoft abandonne finalement cette technologie, possiblement car le marché est devenu bien plus compétitif avec des solutions comme Unity. Toutefois, grâce au projet Monogame, les studios reposant sur XNA peuvent continuer leurs travaux et même s'offrir un support de plateforme étendu.


    Votre opinion

    Avez-vous essayé d'utiliser XNA ? Qu'en pensez-vous ? Quel est votre avis sur MonoGame ?
    Pensez-vous que XNA/MonoGame est une technologie obsolète ? Pourquoi ?
    Conseilleriez-vous aux nouveaux développeurs de partir sur d'autres solutions ? Lesquelles ?


    Voir aussi

    Guide de migration XNA vers MonoGame en français
    Les tutoriels XNA/MonoGame de Developpez.com
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  2. #2
    Inactif  
    Homme Profil pro
    c++ java php javascript
    Inscrit en
    Octobre 2013
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : c++ java php javascript
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2013
    Messages : 374
    Points : 179
    Points
    179
    Par défaut
    XNA c'est surtout fait pour initier les débutants à la programmation de jeux vidéo, et pour prototyper des moteurs avant de les porter en c++, c'est pas vraiment pensé pour faire un produit commercial.

    Pour faire du jeu commercialisable en c# on utilise plutôt unity.
    nous devons inventer la langue de feu pour crâmer la langue de bois

  3. #3
    Inactif  
    Homme Profil pro
    c++ java php javascript
    Inscrit en
    Octobre 2013
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : c++ java php javascript
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2013
    Messages : 374
    Points : 179
    Points
    179
    Par défaut
    J'aurais peut-être pas du faire de comparaison avec unity car ça n'a vraiment rien à voir avec xna (le seul point commun c'est que parmi leurs langages utilisés il y'en a deux avec la même syntaxe, mais le c# pour ms framework et le c# pour mono c'est pas du tout la même mv dessous). Microsoft ça n'est pas leur boulot de faire des moteurs de jeux...

    XNA n'est pas un moteur c'est juste l'actuel wrapper officiel de directx pour débuter et prototyper des jeux windows en c#/vb#. C'est juste la continuation du wrapper directx pour VB, qui lui même était la continuation du wrapper VGA pour QB. Ils lui ont juste donné un autre nom que "directx numéro x pour c#" car xna a l'avantage de faire abstraction de la version.

    Alors bien sûr il y'a toujours eu des jeux à petit budget réalisés avec ces wrapper pour basic/c# mais ça a jamais été une solution géniale.

    [edit] Je me demande si les développeurs de casual n'ont pas été embrouillés par tout ce bazar de syntaxes. Unity c'est la continuation de middlewares qui sont progressivement passés de syntaxes basic-like à des syntaxes java-like. Peut-être que les habitués du basic se sont du coup sentis plus à l'aise sur xna que unity ...

    [edit2] Il faut dire aussi que les wrappers directx pour basic/c# c'est traître, parce que c'est des langage haut niveau lents, mais ça ne sert qu'à prototyper de l'algo bas niveau (et oui il faut tout coder soi-même) destinés à être porté en suite en c++. difficile d'obtenir des performances intéressantes en se contentant de xna donc, à moins de faire du gameplay 2d avec des calculs élémentaires.
    ça n'a donc strictement rien à voir avec unity qui lui a les librairies physx et umbra qui s'occupent de tous les algo bas niveau et le script c# est reservé à la fonction du script d'un engine, donc au game design.
    nous devons inventer la langue de feu pour crâmer la langue de bois

  4. #4
    Rédacteur
    Avatar de Nathanael Marchand
    Homme Profil pro
    Expert .Net So@t
    Inscrit en
    Octobre 2008
    Messages
    3 615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2008
    Messages : 3 615
    Points : 8 080
    Points
    8 080
    Par défaut
    Citation Envoyé par jean_kevin_musclor Voir le message
    Il faut dire aussi que les wrappers directx pour basic/c# c'est traître, parce que c'est des langage haut niveau lents, mais ça ne sert qu'à prototyper de l'algo bas niveau (et oui il faut tout coder soi-même) destinés à être porté en suite en c++. difficile d'obtenir des performances intéressantes en se contentant de xna donc, à moins de faire du gameplay 2d avec des calculs élémentaires.
    A moins de vraiment utiliser des trucs du genre CUDA, on a des très bonnes perfs en C# (oui oui, même équivalentes à ce qui pourrait se faire en C++). On a même les instructions vectorielles et la compilation native

  5. #5
    Inactif  
    Homme Profil pro
    c++ java php javascript
    Inscrit en
    Octobre 2013
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : c++ java php javascript
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2013
    Messages : 374
    Points : 179
    Points
    179
    Par défaut
    J'ai déjà essayé... les instructions vectorielles natives ne sont pas suffisantes pour égaler les perfs du c++.

    Les jeux 3d requièrent des algorithmes complexes comme le parcours de graph, la detection de collisions, le clipping, les déformations de mailles, etc... chaque objet est constemment en train de faire des tests sur une tonne d'autres objets.

    Par exemple t'as tes 50 corps rigides mobiles actifs qui testent en permanence une cinquantaine de polygones et/ou volumes chacun et le test est fait en moyenne 5 fois pour la précision (on arrive déjà à un ordre de grandeur de type 10000 tests avec un algo compliqué à chaque fois...), le frustum camera qui clippe une trentaine de portails ou occluders, et puis tous ces objets en plus doivent parcourir des structures compliquées genre octree-bsp-etc, rajoute la partie du décor qui est partiellement mise à jour (explosions ou building).
    Bref c'est vriament des calculs méga-lourdingues. Il est difficile d'obtenir des perf intéressantes avec c#-xna, et même en optimisant comme un malade tu n'arriveras jamais à égaler la vitesse de physx/umbra qui font ça nativement dans unity. j'ai essayé, ça marche pas...

    En + xna n'est pas une solution portable donc c'est pas plus prévu que les jeux pros que ne l'était le wrapper dx pour vb ou le vga qb.

    C'est fait pour débuter, s'entraîner et prototyper, et ça le fait très bien avec un environnement de prog simplifié. Il faut l'utiliser pour quoi c'est fait.
    nous devons inventer la langue de feu pour crâmer la langue de bois

  6. #6
    Membre chevronné
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2007
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2007
    Messages : 677
    Points : 2 137
    Points
    2 137
    Par défaut
    J’ai testé XNA puis Monogame. J’ai d’ailleurs créés quelques applis Windows 8 grâce à ce dernier (cf. ma signature).

    C’est très bien pour de petits projets, mais là où un moteur de jeux (dans la trempe de Unity) permet au développeur de se concentrer véritablement sur son jeu, XNA/Monogame/N’importe quel autre framework va nécessiter beaucoup plus de travail de la part du développeur pour mettre sur pied une base de jeu minimale ; si on veut de la physique on se la code, si on veut des shaders on se farcie du HLSL à la main, si on veut un joli terrain avec LOD dynamique on se le code... Au final on passe plus de temps à développer un moteur de jeu qu’à véritablement développer son jeu.

    C’est ce qui fait la force de Unity, UE, Cry Engine et consort, et c’est vers ces solutions qu’il faut s’orienter si on a la volonté de mener à bien un projet de jeu vidéo.

    Pour ce qui est des perf de XNA vs Monogame vs C++, j’aime bien ce lien qui date un peu. On voit clairement que XNA peut être 10 fois plus lent que du Directx natif, et que SharpDx (qui est un wrapper DirectX pour .Net utilisé notamment par Monogame pour assurer le pan Windows) s’en sort plutôt bien (en réalité il s'en sort même bien mieux que ce que l'article laisse entrevoir, car pas mal d'opti ont été apportés depuis, et le ratio perf SharpDX/C++ s'approcherait plus des 1.15~1.25 que des 1.5~2.3).
    Le WIP de The last bastion, mon projet de jeu-vidéo (un TD en 3D)

    Mon portfolio / Ma page fb

  7. #7
    Membre éprouvé
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    585
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 585
    Points : 1 138
    Points
    1 138
    Par défaut
    XNA ne m'a servi que pour voir s'il était possible de faire un peu de 3D en C#.
    Dès les premières rumeurs d'arrêt de XNA, j'ai migré en SharpDX. C'est plus bas niveau mais parfait pour ce dont j'avais besoin.
    Puis, dans le cadre de ma grande quête "apprendre un truc nouveau", j'ai testé SharpGL et j'ai maintenant migré vers le langage D et Derelict3.
    L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.

  8. #8
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 347
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 347
    Points : 20 347
    Points
    20 347
    Par défaut
    Citation Envoyé par jean_kevin_musclor Voir le message
    J'ai déjà essayé... les instructions vectorielles natives ne sont pas suffisantes pour égaler les perfs du c++.
    Dans la prochaine version de Visual Studio, on pourra avoir du code C# transformé en natif.

    Quant à Unity c'est sans doute un excellent outil mais sans vouloir relancer tout un débat, je doute qu'on puisse faire un jeu AAA avec.
    C'est parfait pour les petites équipes qui ont peu de moyens; les studios un minimum expérimentés préférent construire leur propre middleware.

  9. #9
    Membre actif Avatar de ShadowTzu
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Juin 2005
    Messages
    243
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Haute Saône (Franche Comté)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : Juin 2005
    Messages : 243
    Points : 296
    Points
    296
    Par défaut
    Au vue de l'abandon de DirectX Managed je n'ai jamais été attiré par XNA, il était clair pour moi qu'il (elle?) serait abandonné dés la fin de vie de la XBox360.
    En ce qui concerne les perfs du .NET pour les "algorithmes complexes" c'est devenu vraiment négligeable notamment depuis DirectX11 avec DirectCompute.

  10. #10
    Inactif  
    Homme Profil pro
    c++ java php javascript
    Inscrit en
    Octobre 2013
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : c++ java php javascript
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2013
    Messages : 374
    Points : 179
    Points
    179
    Par défaut
    Mat.M > VB6 était transformé en natif aussi, ça n'est pas pour ça qu'il égalait la vitesse du c++ ... mais même sans tenir compte des problèmes de perf, c'est pas très intéressant de s'enfermer dans un truc qui ne marche que sur windows.

    ShadowTzu > Le gpu est optimisé pour les calculs vectoriels et des "algorithmes" élémentaires dont la "complexité" est une bête boucle for donc on peut pas tellement parler d'algorithme c'est juste le même calcul répété. Tout le reste (ia, pathfind, broad phase, culling, mesh update, toutes les formules de collision que le gpu ne sait pas calculer, etc) c'est le cpu qui s'en charge. Sinon les jeux tourneraient à 1% cpu au lieu de 100%.
    nous devons inventer la langue de feu pour crâmer la langue de bois

  11. #11
    Inactif  
    Homme Profil pro
    c++ java php javascript
    Inscrit en
    Octobre 2013
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : c++ java php javascript
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2013
    Messages : 374
    Points : 179
    Points
    179
    Par défaut
    Hé au fait on a oublié de répondre au quizz de littlewhite.

    Votre opinion

    Avez-vous essayé d'utiliser XNA ? Qu'en pensez-vous ? Quel est votre avis sur MonoGame ?

    Non. J'ai débuté la 3d avec le basic. Donc j'en pense pas grand chose.

    Pensez-vous que XNA/MonoGame est une technologie obsolète ? Pourquoi ?

    XNA oui puisque microsoft l'a droppé. Monogame je sais pas trop si l'équipe de développement va suivre.

    Conseilleriez-vous aux nouveaux développeurs de partir sur d'autres solutions ? Lesquelles ?

    Pour ceux qui veulent produire des jeux vite il y'a les moteurs.

    Pour ceux qui veulent apprendre la programmation de moteur 3d avec un langage plus facile que le c++, ou bien faire du prototypage, je conseillerais jogl ou webgl qui sont des solutions plus standard que xna.
    nous devons inventer la langue de feu pour crâmer la langue de bois

  12. #12
    Membre actif Avatar de ShadowTzu
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Juin 2005
    Messages
    243
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Haute Saône (Franche Comté)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : Juin 2005
    Messages : 243
    Points : 296
    Points
    296
    Par défaut
    jean_kevin_musclor> "tout le reste" peut également être calculer par le GPU.

  13. #13
    Inactif  
    Homme Profil pro
    c++ java php javascript
    Inscrit en
    Octobre 2013
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : c++ java php javascript
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2013
    Messages : 374
    Points : 179
    Points
    179
    Par défaut
    Ouais sauf que la théorie et la pratique ne vivent pas dans la même galaxie et qu'on est sensé répartir la charge sur tous les processeurs de la machine et que le gpu est sensé calculer les choses pour lesquelles le gpu est optimisé. Or des algos de recherche codés en basic je le sens pas trop...

    Et pour ceux qui veulent dévier vers le débat "est-il dans l'intérêt d'un développeur de jeu de faire l'impasse sur le langage c++", ça mériterait un topic complet. Je pourrais déballer douze kilomètres d'arguments appuyés par l'expérience pour vous prouver que la réponse est non avec un grand n, mais ça serait hors sujet.

    Citation Envoyé par ShadowTzu Voir le message
    jean_kevin_musclor> "tout le reste" peut également être calculer par le GPU.
    J'ai jeté un oeil à ton moteur 3d en basic, je vais pouvoir étoffer ma réponse.

    Ton moteur est un moteur d'affichage, ce sont effectivement des "algos" pour lesquels un gpu est optimisé, et comme je disais plus haut je mets des guillemets à "algo" parce que c'est rien que des bêtes boucles for.

    Les algorithmes de moteur de jeu ça n'est pas les mêmes, ce sont d'une part des algo indépendants du gpu facile à porter car du calcul pur, d'autre part ce sont des algo récursifs ou itératifs basés sur des structures non-linéaires. Quelques exemples d'algos classiques qu'on retrouve dans la plupart des moteurs de jeu: arbres spatiaux moins obvious que les octree (bsp, bvh, etc), culling récursif basé sur une structure sector/portal, ia basée sur du pathfinder, broad phases de collision des moteurs physiques également basées sur des parcours d'abres (souvent des kd-tree, qu'on construit souvent au loading), etc... il y'a très peu de calculs vectoriels dans ces algos là, juste quelques petits produits scalaires ou en croix, tout le reste c'est de la recherche dans des tableaux (comme de la bdd mais en plus chiant), et, je vois pas trop lintérêt de déléguer ça au gpu à part se compliquer la vie inutilement.
    nous devons inventer la langue de feu pour crâmer la langue de bois

  14. #14
    Rédacteur
    Avatar de Franck.H
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2004
    Messages
    6 951
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Service public

    Informations forums :
    Inscription : Janvier 2004
    Messages : 6 951
    Points : 12 462
    Points
    12 462
    Par défaut
    Avez-vous essayé d'utiliser XNA ?
    Non

    Quel est votre avis sur MonoGame ?
    Ayant plongé un peu dedans en faisant une suite de tutoriels, je trouve qu'on est encore loin d'une intégration complète car il fallait, par exemple, pour afficher du texte, utiliser un outils pour convertir les fichiers au format xnb pour que les polices soient utilisable. Je ne parle même pas des fichiers audio que je n'ai pas réussi à utiliser correctement (c'est mon tutoriel manquant d'ailleurs) donc pour moi, MonoGame à encore du chemin à faire !

    Pensez-vous que XNA/MonoGame est une technologie obsolète ? Pourquoi ?
    Peut-être pas obsolète mais pas faite pour des projets d'envergure.

    Conseilleriez-vous aux nouveaux développeurs de partir sur d'autres solutions ? Lesquelles ?
    Suivant la grandeur du projet, XNA/MonoGame pour des tests de codes vite fait ou du prototypage comme ça a été dit précédemment mais sinon je conseillerais vivement Unity qui permet maintenant de faire également de la 2D aussi bien que de la 3D et qui permet de mettre facilement en scène votre jeu. J'ai surtout trouvé l’interaction (par exemple) entre l'ajout d'une variable publique dans le code et son apparition dans l'interface de l'éditeur formidable, j'ai jamais vu ça
    Mon Site
    Ma bibliothèque de gestion des chaînes de caractères en C

    L'imagination est plus importante que le savoir. A. Einstein

    Je ne répond à aucune question technique par MP, merci d'avance !

  15. #15
    Membre chevronné
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2007
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2007
    Messages : 677
    Points : 2 137
    Points
    2 137
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    Quant à Unity c'est sans doute un excellent outil mais sans vouloir relancer tout un débat, je doute qu'on puisse faire un jeu AAA avec.
    C'est parfait pour les petites équipes qui ont peu de moyens; les studios un minimum expérimentés préférent construire leur propre middleware.
    Quand on voit qu’il faut débourser entre 1500 et 4500 euros (si on souhaite cibler iOS et Android) pour Unity Pro, là où Unreal Engine est accessible pour 19 euros/mois, je me demande si Unity est réellement la solution la plus abordable financièrement ^^ (en termes de facilité d’apprentissage je ne dis pas).

    Citation Envoyé par jean_kevin_musclor Voir le message
    VB6 était transformé en natif aussi, ça n'est pas pour ça qu'il égalait la vitesse du c++ ...
    VB6 intègre énormément de mécanismes de vérification couteux, mais en mettant un peu les mains dans le cambouis et en optimisant un peu son compilateur on est en mesure d’obtenir des perfs similaires voire supérieures à celles du C++.

    Citation Envoyé par jean_kevin_musclor Voir le message
    Et pour ceux qui veulent dévier vers le débat "est-il dans l'intérêt d'un développeur de jeu de faire l'impasse sur le langage c++", ça mériterait un topic complet. Je pourrais déballer douze kilomètres d'arguments appuyés par l'expérience pour vous prouver que la réponse est non avec un grand n, mais ça serait hors sujet.
    On parle d’un développeur de jeu ou d’un développeur de moteur de jeu =P ?
    Les gros Middlewares utilisés par l’industrie sont développés en C++, je te l’accorde, mais les développeurs qui utilisent l’outil ne développent pas nécessairement en C++ (à titre d’exemple, j’ai joué un peu avec le Cry Engine, et tout le scripting se fait en LUA, sous Unity c’est du pseudo javascript ou du C#, sous UDK/UE on a le choix entre un langage de script maison ou du C++).

    Citation Envoyé par Franck.H Voir le message
    NonPeut-être pas obsolète mais pas faite pour des projets d'envergure.
    Après je ne pense qu’il y ait réellement une limite à l’envergure des projets réalisables avec XNA/Monogame. Je pense que c’est avant tout une question de productivité/efficacité.

    D’un point de vue subjectif, outre les considérations d’obsolescence (qui ne concernent qu’XNA, car câblé sur une version obsolète de DirectX, là où Monogame s’appuie sur les dernières versions d’OpenGl et de DirectX), je pense qu’à l’heure actuelle, pour la personne qui souhaite réellement développer un jeu vidéo, il existe des outils bien plus efficaces pour arriver au même résultat (Unity pour ne pas le citer, car il est de loin le plus facile d’accès).

    Du côté de XNA, si je devais citer quelques jeux auxquels j’ai joué et qui tiennent la route ; Terraria, Schizoid et Magicka. Du coté de Monogame ; ceux présents sur cette page (à l’exception de Infinite Flight que je n’ai pas testé). Il est clair que nous ne sommes pas face à des jeux AAA, mais nous sommes tout de même loin d’un morpion ou un casse-briques ^^.
    Le WIP de The last bastion, mon projet de jeu-vidéo (un TD en 3D)

    Mon portfolio / Ma page fb

  16. #16
    Membre actif Avatar de ShadowTzu
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Juin 2005
    Messages
    243
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Haute Saône (Franche Comté)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : Juin 2005
    Messages : 243
    Points : 296
    Points
    296
    Par défaut
    Citation Envoyé par jean_kevin_musclor Voir le message
    Ouais sauf que la théorie et la pratique ne vivent pas dans la même galaxie et qu'on est sensé répartir la charge sur tous les processeurs de la machine et que le gpu est sensé calculer les choses pour lesquelles le gpu est optimisé. Or des algos de recherche codés en basic je le sens pas trop...

    Et pour ceux qui veulent dévier vers le débat "est-il dans l'intérêt d'un développeur de jeu de faire l'impasse sur le langage c++", ça mériterait un topic complet. Je pourrais déballer douze kilomètres d'arguments appuyés par l'expérience pour vous prouver que la réponse est non avec un grand n, mais ça serait hors sujet.



    J'ai jeté un oeil à ton moteur 3d en basic, je vais pouvoir étoffer ma réponse.

    Ton moteur est un moteur d'affichage, ce sont effectivement des "algos" pour lesquels un gpu est optimisé, et comme je disais plus haut je mets des guillemets à "algo" parce que c'est rien que des bêtes boucles for.

    Les algorithmes de moteur de jeu ça n'est pas les mêmes, ce sont d'une part des algo indépendants du gpu facile à porter car du calcul pur, d'autre part ce sont des algo récursifs ou itératifs basés sur des structures non-linéaires. Quelques exemples d'algos classiques qu'on retrouve dans la plupart des moteurs de jeu: arbres spatiaux moins obvious que les octree (bsp, bvh, etc), culling récursif basé sur une structure sector/portal, ia basée sur du pathfinder, broad phases de collision des moteurs physiques également basées sur des parcours d'abres (souvent des kd-tree, qu'on construit souvent au loading), etc... il y'a très peu de calculs vectoriels dans ces algos là, juste quelques petits produits scalaires ou en croix, tout le reste c'est de la recherche dans des tableaux (comme de la bdd mais en plus chiant), et, je vois pas trop lintérêt de déléguer ça au gpu à part se compliquer la vie inutilement.
    Path finding sur GPU: http://gpgpu.org/2012/06/20/multi-agent-path-planning
    Octree sur GPU: http://gpgpu.org/2010/01/20/gpu-simu...nd-gpu-octrees
    Collision sur GPU: http://gpgpu.org/2010/12/27/fast-gpu...ormable-models

    L’intérêt de faire ça sur le gpu lorsqu'on fait du game en .NET est justement d'avoir quelque chose d'équivalent voir même de plus performant que si cela aurait été codé en c++ (gpu=100Gb/s)
    Ce n'est pas se compliquer la vie inutilement, c'est trouver des solutions intelligemment.
    j'en reviens donc à la même conclusion: En ce qui concerne les perfs du .NET pour les "algorithmes complexes" c'est devenu vraiment négligeable notamment depuis DirectX11 avec DirectCompute.

    Pour en revenir à XNA, basé sur DirectX9 (pas de compute shader) il est en effet difficile d'avoir de bonne perf avec ce genre d'algo. Alors qu'avec MonoGame (basé sur DirectX11) ou les wrapper (SharpX, SlimDX, ...) on a accès à DirectCompute et donc à la possibilité de coder de "gros" jeux.

    Mon Opinion?
    L'avenir des codeurs XNA est de passer à MonoGame.

  17. #17
    Inactif  
    Homme Profil pro
    c++ java php javascript
    Inscrit en
    Octobre 2013
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : c++ java php javascript
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2013
    Messages : 374
    Points : 179
    Points
    179
    Par défaut
    I-Pnose > Je ne vois pas de séparation catégorique entre les utilisateurs de moteur qui ne feraient que du script et les développeurs de moteur qui ne feraient que du c++, il me semble que c'est plus nuancé que ça. Les utilisateurs de unity par exemple peuvent faire des extensions en c++, et ils peuvent aussi faire une surcouche de moteur en c#. Pour cry engine ou id tech engine c'est encore plus évident tu mets les mains directement dans la source, c'est du boulot collectif où chacun pose son truc, je vois pas de séparation entre deux groupes. Et enfin dans le cas des jeux à petit budget codés maison, il n'y a aucune séparation jeu/moteur.

    ShadowTzu > Je sais que les gpu gèrent très bien les structures type grille/octree car ce sont des structures integer simples qui collent très près à la structure de la ram. Ceci dit il me semble que l'algo qu'on fait dans les octree gpu en général c'est le raycast, qui est une bête boucle for et pas un algo récursif. Je sais aussi que les gpu gèrent la dernière étape des algos de collision (qui elle aussi est une bête boucle for) puisque ce sont des calculs vectoriels, par contre les broad phase dans les structures compliquées des moteurs physiques, j'en doute. Bref tes articles confirment que le gpu c'est fait pour les algos pour lesquels le gpu est optimisé, pas pour la totalité des algo donc. si le cpu servait à rien ça se saurait...
    nous devons inventer la langue de feu pour crâmer la langue de bois

  18. #18
    Membre expert

    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Février 2006
    Messages
    1 031
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2006
    Messages : 1 031
    Points : 3 092
    Points
    3 092
    Par défaut
    Citation Envoyé par jean_kevin_musclor Voir le message
    Et enfin dans le cas des jeux à petit budget codés maison, il n'y a aucune séparation jeu/moteur.
    Théorème de jean_kevin_musclor ?
    Il faut arrêter d'affirmer tout et rien pour être un minimum crédible...

    Bref je confirme les dires de ShadowTzu et je vais même plus loin : sur PC mis à part pour un AAA et quelques exceptions le C#/Java/le langage de votre choix sont tout à fait adaptés, même pour du calcul de pathfinding, collision etc...
    1 : en s'y connaissant suffisamment dans ces langages on peut approcher les performances natives.
    2 : Même si l'exécution était 2x plus lente ( ce qui est loin d'être le cas ) ça serait intéressant au vu du temps de production gagné qui permet de mettre en place d'autres optimisations que l'on aurait jamais eu le temps de faire si l'on avait bossé en C++.

    Je considère tout de même qu'une solution optimale c'est du C++ pour le moteur et C# pour la partie gameplay, solution de Unity.

    Bref Monogame est un bon choix pour découvrir le développement de jeu vidéo et que vous ne souhaitez pas bosser chez Crytek plus tard.
    Suivez le développement de Chibis Bomba
    twitter : https://twitter.com/MoD_DiB
    DevBlog : http://moddib.blogspot.fr/

  19. #19
    Inactif  
    Homme Profil pro
    c++ java php javascript
    Inscrit en
    Octobre 2013
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : c++ java php javascript
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2013
    Messages : 374
    Points : 179
    Points
    179
    Par défaut
    Pour info ça fait un moment que unity a rejoint les rangs des moteurs AAA, aussi bien au niveau de la licence que de la complexité du moteur.

    Sur les mobile on fait des jeux simples on a pas besoin d'investir dans des moteurs.
    nous devons inventer la langue de feu pour crâmer la langue de bois

  20. #20
    Membre chevronné
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2007
    Messages
    677
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2007
    Messages : 677
    Points : 2 137
    Points
    2 137
    Par défaut
    Citation Envoyé par jean_kevin_musclor Voir le message
    Sur les mobile on fait des jeux simples on a pas besoin d'investir dans des moteurs.
    Ton point de vue.

    On fait des choses "simples" sur mobile (c’est relatif), seulement si on souhaite cibler plusieurs plateformes ces choses simples se démultiplient et on se retrouve avec tout un tas de projets à maintenir. Au final ce qui était censé être simple au départ se transforme en usine à gaz.

    Si on prend le cas de Monogame qui est multiplateforme, on se retrouve forcément avec un (voire deux) projets spécifiques par plateforme + des pans entiers à réécrire d’une plateforme à une autre en raison de spécificités systèmes de la cible (Capabilities, IAP, etc...). Mes jeux W8 ont beau être développés avec Monogame, je n'ai pas encore fait le moindre portage sur d'autres plateformes (même pas WP8 alors que ça reste du Microsoft) car ça représente une masse substantielle de boulot (pas très passionnant de surcroît).

    Bref, un studio indépendant a tout intérêt à opter pour un moteur de jeu s’il souhaite être efficace sur tous les fronts, que son projet soit simpliste ou complexe.
    Le WIP de The last bastion, mon projet de jeu-vidéo (un TD en 3D)

    Mon portfolio / Ma page fb

Discussions similaires

  1. Réponses: 2
    Dernier message: 18/08/2010, 12h22
  2. Est-ce possible de faire des jeux pour Ipod à Molette cliquable?
    Par Jakemanga dans le forum Développement 2D, 3D et Jeux
    Réponses: 7
    Dernier message: 19/05/2010, 14h48
  3. Quel est le meilleur controle pour faire des graph
    Par stdebordeau dans le forum Windows Forms
    Réponses: 2
    Dernier message: 28/09/2009, 13h17
  4. Maven est-il le meilleur outil pour faire des builds ?
    Par romaintaz dans le forum Maven
    Réponses: 66
    Dernier message: 31/07/2009, 16h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo