Microsoft et l'école d'ingénieur EFREI proposent aux étudiants (1ere S, TS,...) de programmer leur premier jeux Xbox avec XNA studio, débutants welcome:
holiday-camps.efrei.fr
Microsoft et l'école d'ingénieur EFREI proposent aux étudiants (1ere S, TS,...) de programmer leur premier jeux Xbox avec XNA studio, débutants welcome:
holiday-camps.efrei.fr
Salut je vien de découvrir la SDL mais c' est une bibliothéque extra ordinaire surment parce que je suis débutant dans le domaine mais c'est un excellent outil d'apprentissage .
fait des recherches et essaie la . et tu m'en diras plus
bon dev
tu peux le telecharger
www.libsdl.org/download-1.2.php
Beugue Serigne TOUBA
Pour faire de bon jeux et des jeux efficaces il faut surtout bien connaitre la théorie et avoir un peu de logique.
Le C/C++ est à mon sens incontournable. Néanmoins des langages comme JAVA3D ou le flash commencent à avoir des bases solides. Pourtant, ceux-ci fonctionnent avec un garbage collector ou ne permettent pas encore de coder avec la carte graphique et semblerait donc moins efficaces pour la gestion de la mémoire ou l'optimisation des performances, c'est pourquoi ils sont moins appréciés.
Au delà de l'aspect programmation des logiciels du genre de virtools (3Dvia maintenant qui est gratuit) peuvent te soustraire de la partie programmation dur d'un moteur. Cependant, la connaissance des algorithmes sous-jacents grâce à l'utilisation des bibliothèques comme la SDL, openCV(pour le traitement d'image), openGL(pour la 3D et la 2D) peut te permettre de renforcer tes bases toutes en abordant un aspect technique avancé en matière d'optimisation de code te faisant ainsi connaitre via les discussions sur les forums la segmentation d'un espace 2D ou 3D(via quadTree ou octree etc...), l'optimisation des rendus de pièces via l'algorithme place et portails etc...
Houlla, tu devrais te renseigner sur le garbage collector. Dans bien des cas, ça améliore les perfs.
La lenteur des langages managés est due aux runtime check et non au GC.
houla, on a déjà dit beaucoup sur le sujet du garbage collector. merci de ne pas relancer un vieux troll...
C'est pourquoi je dis à ce monsieur de mieux se renseigner
Quand bien même ça améliorerait les perfs on ne peut savoir avec exactitude quand est ce qu'il va passer.
En rien je n'ai critiqué et affirmé que le GC n'optimisait pas les perfs j'ai supposé(sembler parait être un mot clair).
Au dela de tout ce qui est réalité ce qui fait le plus défaut à la programmation en entreprise au delà des coups de production etc ce sont le a priori du genre JAVA pas assez performant pour le jeu vidéo...
Bah oui mais c'est la réalité, JAVA n'est pas assez puissant pour ce domaine.
J'ai utilisé un petit simulateur de robot en 3D, c'était pas très rapide alors qu'il n'y avait pas beaucoup de polygones (une centaine).
De même pour une logiciel de traitement d'image où il fallait uniquement afficher des lignes et des cercles en 2D, seulement 1 pixel d'épaisseur sans aucun effet. En JAVA ils n'ont jamais réussi à avoir des performances acceptables, du coup ils ont interfacé du C et du JAVA et là plus de problèmes.
Flash c'est pareil, c'est loin d'être aussi puissant, ça se met très vite à ramer =(. Je suis en train de développer un shoot em up en Flash au délà de la centaine de projectiles ça commence à ralentir. Alors que n'importe quel autre shoot em up développer en C/C++ même vieux de 10 ans peut grimper à 500 facilement.
Infinity - To The Top, shoot'em up développé en Haxe / OpenFL pour FLASH et Android, piou piou rythmé dans l'espace
Mais est-ce que ça ne pourrait pas être un problème de compétences ou d'expérience du développeur ?
Le souci ne pourrait-il pas également venir du logiciel et de la plateforme d'exécution plutôt que du langage ?
D'autre part, s'interfacer avec des librairies en C c'est quelque chose d'assez courant. Je ne vois pas pourquoi on voudrait faire du "full java" par exemple, alors que des choses performantes existent déjà sous formes de librairies C.
Est-ce qu'il n'y aurait pas une mauvaise foi générale qui affirmerait que non, Java c'est pas assez rapide, alors que C++, si, la preuve, quand on fait mal les trucs en Java, eh ben ça rame !
Si vous suivez ma pensée...
[|]
Pour ma part j'utilise java et ogre4j comme moteur 3d, donc une interface java-code natif via JNI, les perfs sont excellentes(alors que le code n'est pas encore optimisé), le GC n'a jamais été un soucis du fait que j'utilise des objets ayant une vie assez courte. (donc c'est la collection mineure, assez rapide, qui entre en jeu pour s'occuper de ces objets)
Je suis moi même souvent étonné de la vitesse d'exécution sur des parties que j'ai codé avec les pieds.
La chose à en retenir c'est qu'il ne faut pas imputer tous les maux de la terre au langage, une connaissance correcte de celui ci a bien plus d'impact que ses performances internes.
Avez-vous des exemples de cahier de charges pour jeux vidéos? Je pense qu'en faire un peut être très utile pour le développement.
Pas certain.
Il est fort possible qu'un cahier des charges pour un projet X ne convienne pas pour un projet Y (donc difficile de faire un template générique).
On doit pouvoir trouver des exemples de cahier des charges dont on peut s'inspirer partout, mais ça ne sera pas des informations relatives au jeu vidéo mais probablement plus à un développement logiciel tout court.
Encore que ça dépend de l'ambition du projet (parce que là j'imagine qu'on parle à un niveau "amateur" ?), et des normes utilisées pour ce qui est de la production de documentation en amont (et là il y a beaucoup de façons de faire, plus ou moins standardisées).
La chose la plus utile selon moi pour le développement, c'est d'être payé. Si y'a pas de sous à la clé, y'aura difficilement un jeu.
Les choix d'architecture et d'implémentation dus à des contraintes externes, aux specs ou peu importe à quoi jouent sûrement beaucoup aussi.La chose à en retenir c'est qu'il ne faut pas imputer tous les maux de la terre au langage, une connaissance correcte de celui ci a bien plus d'impact que ses performances internes.
[|]
Bonjour,
je donne mon petit avis sur les bases qu'il faut avoir absolument de mon point de vue personnel, qui va pas forcément aller dans le consensus
savoir quel est le meilleur langage ou les meilleurs cours de math/algo me parait pas être la bonne approche car on ne sait pas forcément de quel langage et de quels algos on va avoir besoin, tout dépend du type de jeu
ce que je pense le plus important c'est
1 - faire un exercice pas gratifiant mais facile, genre un morpion ou un pong, et de le finir jusqu'au bout, avec des scores, un menu, et cetera... comme ça on apprend déjà à afficher des images, du texte, jouer des sons, à structurer un jeu en states...
une fois qu'on s'est tapé cet exercice (compter deux semaines de boulot à plein temps, voir un mois pour les débutants), on a une idée des étapes de fabrication d'un jeu de A à Z et on a appris à maitriser des libs graphiques / son / texte... on sait déjà le temps de travail que ça représente pour un jeu tout bête, ça aide mieux à voir le temps que ça va prendre pour un jeu compliqué
2 - s'attaquer tout de suite aux deux bêtes noires des débutants et amateurs: l'étude des sources ou hacks "classiques" et des formats de maps de jeux "classiques" (en réalité ces deux là vont ensemble)
l'encodage des maps est fondamental car le gameplay est entièrement basé dessus
tant qu'on s'est pas farci un minimum cette partie chiante de l'apprentissage, on va rester bloqué dans une forme d'amateurisme
Voilà quelques exemples qui m'ont énormément aidé:
- pour les jeux 2d: les éditeurs de maps pour hacker les roms de metroid1 et metroid3
pas de source à étudier mais ça apprend comment sont foutues les maps des jeux 2d classiques.
dans l'editeur de metroid1 ici:
http://www.angelfire.com/electronic/dokidoki/zebes.html
on voit que la logique d'une carte en tuiles sur ces vieux jeux n'est pas de créer bêtement un tableau de tiles. les maps sont divisées en écrans pour guider le design, chaque écran contient une liste d'objets superposés, l'assemblage de ces objets est converti en tuiles (il me semble que cette conversion se fait à la volée au runtime, y'avait pas de place pour stocker des tilemaps sur ces vieilles consoles)
dans l'editeur de metroid3 là:
http://jathys.zophar.net/files/smile.zip
là c'est pas le même système, y'a la place dans la rom pour stocker des tilemaps, donc la conversion objet -> tuile se fait directement dans l'editeur de maps (avec cet éditeur là en fait on assemble bêtement des tuiles pour que ça forme des objets, mais il est possible que le système utilisé par les développeurs était un peu plus subtil, afin de pouvoir faire les levels plus vite)
on apprend d'autres trucs en tripotant ce format: il y'a plusieurs grilles superposées.
d'abord une grille juste pour l'affichage, qui contient les tuiles
ensuite, une grille qui contient des données qui peuvent être indépendantes de ce qui est affiché: les données de collision (bloc carré, pente à 45 degré, à 30 degré...), le fait qu'un bloc est cassable ou pas et avec quelle arme
une troisième grille pour stocker les personnages (j'ai vérifié en étudiant la doc de la console)
et une quatrième grille pour l'arrière plan
après avoir étudié tout ça on comprend mieux comment construire efficacement une map de jeu en tuiles
y'a des éditeurs pour hacker d'autres classiques genre mario world, j'ai pas regardé si y'a d'avantage à apprendre dedans
- pour les jeux 3d: les specs du format bsp de l'id tech engine
si vous voulez faire des jeux 3d qui se déroulent dans une architecture, vous allez être obligé d'utiliser un format bsp+occlusion tout fait, il serait beaucoup trop long de se lancer dans son propre logiciel de modélisation de bsp map... il y'en a plein de gratuits
les moteurs 3d classique sont souvent prévus pour afficher le format bsp, c'est le cas d'ogre3d (voir le tutoriel), ça va être vrai pour la 3d ria sur le web aussi il y'a déjà des portages en cours.
et même sans ça, c'est bien d'étudier ce format qui fut le standard d'un gros paquet de moteurs de l'époque 95/2000 (quake, half life, counter strike, wolfenstein ennemy territory, call of duty 1, star wars...)
étudier la source des moteurs d'id software apprend un paquet de trucs aussi
ce sont deux exemples où on a tout à apprendre... c'est laborieux à étudier mais une fois qu'on a vu à quoi ressemble le travail des pros, on est moins perdu pour se lancer dans un développement
si vous avez d'autres exemples de sources et hacks à valeur didactique, n'hésitez pas à les citer.. ça pourrait être intéressant à regrouper dans un article
pour voir à quoi ressemble un projet amateur qui a réussi: http://www.advsys.net/ken/build.htm
j'en vois qui parlent de la lenteur des langages interpretés pour la 3d...
normalement on utilise un langage compilé qui gère le rendu des tonnes de triangles pour que ça soit le plus rapide possible, et par dessus on peut utiliser un langage interpreté pour gérer ça à un niveau plus grossier
par exemple dans le torque engine, ou dans unity3d, le rendu des triangles est codé en c+, et on gère les objets qui contiennent les triangles avec le script c#
pour java je crois que ogre4j permet de fonctionner de la même manière
pour le petit flash player qui va bientôt passer à la 3d j'éspère qu'ils ont prévu ça aussi, parce que si on doit tracer chaque triangle avec du script on va avoir des perfs bien pourries
pour voir à quoi ressemble un projet amateur qui a réussi: http://www.advsys.net/ken/build.htm
La première base à avoir :
http://fr.wikipedia.org/wiki/Jeu
Je dis ça parce que y a des programmes qui sont de belles vitrines technologiques, mais on ne peut pas appeler ça des jeux. Exemple : Call of Duty 7. Le joueur est guidé du début jusqu'à la fin par un gros point jaune "Follow" dans un univers scripté comme c'est pas permis, avec une violence indécente, et très user-friendly (aspect commercial inside).
Et en plus, les graphismes sont tellement réalistes qu'on ne peut même plus parler de travail d'artiste là dedans. Ils ont tout copiés sur la réalité. Pas de place pour l'imagination, telle est la devise préférée des "industriels" du jv de nos jours.
Enfin je ne sais pas ce que vous en pensez, mais à mon sens ça n'est pas un jeu vidéo, c'est un film d'animation américain à grand budget.
Donc voilà quoi, certes un jeu vidéo c'est beaucoup de technique, mais, comme pour une œuvre d'art, c'est aussi et surtout un travail d'imagination, et d'artiste.
Tres bonne vue d'ensemble, un programmeur doit savoir choisir le bon outil pour développer un programme. Un langage de programmation est un outil
A ta liste je rajouterais le langage D a préféré au C++ si on n'a pas des besoins de lib externe exotique (sinon va falloire utiliser extern c pour binder)
En D support de l'openGL 2, 3 et 4 peu de langage peuvent s'en vanter
moteur 3D tel que ogre porter il ya également Yage un moteur 3d entierement ecrit enD
Le D est aussi rapide que le c++ voir dans certains cas plus rapide. Langage ne prenant que le meilleur des langage existant, très simple a dévelooper et maintenance de code facile.. Enfin des message d'erreur humainement compréhensible et j'en passe.
Bref le D a choisir en 1er dans le cas ou l'on a pas de lib exotique dans le cahier des charges
En
le choix des langages c'est pas ça le problème.
ça dépend entièrement du jeu. est-ce un jeu pour mobile, pour pc, mac, web ria, etc c'est ça qui va définir le langage
y'a juste deux langages dans lesquels t'es obligé d'avoir un minimum de bases c'est c/c+ , même si tu vas rien coder avec, t'as au moins besoin de savoir le lire pour pouvoir étudier les sources qui t'apprennent comment c'est fabriqué un jeu vidéo. je dirais que dans l'idéal faut aussi des bases en assembleur.
je pense par exemple à la boite qui ont codé une lib pour afficher les bsp maps dans le flash player, même s'ils ont tout codé en actionscript, il sont obligés de connaitre un minimum le c pour pouvoir porter les sources d'id software
pour voir à quoi ressemble un projet amateur qui a réussi: http://www.advsys.net/ken/build.htm
D'une certaine manière, un langage en soit ça n'est jamais plus qu'une centaine de mots de vocabulaire à apprendre avec plusieurs types de grammaire comprenant quelques variations d'un langage à l'autre.
Enfin en plus la plupart des mots-clés "principaux" (if, else, while, for) sont communs à quasiment tout les langages (les plus répandus, du moins).
Il suffit donc d'appréhender les grammaires (doit on parler de paradigmes ?) différentes et d'apprendre à programmer dans un langage de bas niveau pour, à mon avis, être capable de lire n'importe quel langage (enfin dans une mesure non grotesque, évidemment).
juste pour corriger une erreur, les api COM sont utilisables en C, donc on peut faire du dx en C.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager