Je suis un petit curieux qui voudrai commencer à s’intéresser au codage et plus pour l'instant au java. J'aimerai savoir comment a était fais (coder) les modes de vue(à la troisième ou première personne...) sur les jeux (en particulier minecraft avec le fonctionnement f5).
Merci de me répondre, si vous savez quelque chose dessus.
>J'aimerai savoir comment a était fais (coder) les modes de vue(à la troisième ou première personne...) sur les jeux (en particulier minecraft avec le fonctionnement f5).
Ce genre de questions ne relèvent pas forcément du Java mais d'un sujet bien plus vaste: la 3D
Si tu souhaites en apprendre davantage sur ce domaine, je te conseille de te rendre sur le [site d'LWJGL] (https://www.lwjgl.org/).
Je te mets en garde, et sans vouloir te décourager, si tu n'as jamais codé - je te recommande vivement de te faire les dents avec des technologies utilisées dans le monde du jeu vidéo (C et principalement C++), mais ce n'est pas donné à tout le monde comme certains aimeraient le faire croire.
Cela ne demande pas de simples bases en algo, cela demande également des bases en géométrie spatiale si tu souhaites faire des trucs sympas.
En tout cas, si tu as besoin d'autres ressources, n'hésites pas à demander.
Je dis peut etre des bêtises ne codant pas en 3D mais je connais un peu le principe:
Pour la 3D les développeurs utilisent des "moteurs graphiques" qui sont en fait des gros logiciels qui calcule les deplacment d'objet et les dessine en fonction de où on veut les mettres, d’ailleurs les développeurs ont de moins en moins de ligne de code à mettre, d'où l'emploi du mot "logiciel".
NB: c'est un peu un des principes de l'algorithmie, savoir coder un truc qui fait qq chose d'inutile et lui faire faire un truc énorme. Ex: un algorithme pour donner la somme des entiers entre 1 et N , si N = 10 bah tu peux le faire toi même mais l’intérêt c'est de le tester sur ton programme et si ça te donne la même chose bah rien ne t’empêche de mettre N à 6914869. C'est pareil dans l'histoire de l'informatique, au début on codais en binaire, et plutôt que de coder un gta en binaire bah on a codé "l'assembleur" qui a simplifié le code à tt le monde, puis les langages de programmation, puis les méthodes pour afficher rapidement un carré, puis les moteurs graphiques. avec un peu d'astuce on peut rapidement dessiner un cube et faire croire qu'on tourne autour en bougeant ses arrêtes, et pour un moteur 3D c'est pareil mais en gérant chaque élément un par un, mais sans se fatiguer à écrire des milliards de ligne ! Le moteur le fait à ta place
Et par conséquent, il y a très probablement une option dans ces logiciels pour fixer la"caméra", soit derrière ton perso, soit dans ses yeux !
Tout ce que tu vois n'est que des données stockées en masses dans des gros tableaux, qui connaissent ainsi l'emplacement de tout ce qui fait un jeu. Et ton moteur graphique calcule quel pixel afficher et où pour recréer ce que ta "caméra" voit en fonction de toutes ces informations. Et ainsi tu peux savoir que ya un stormtrooper planqué dans l'arbre et qu'il vient de te tuer parce que tu te pose trop de questions existentielles
Les devs de Minecraft utilisent LWJGL, et non pas un moteur de jeu.
Pour les graphismes, c'est de l'OpenGL. Les modes de vues sont donc gérés avec des transformations matricielles, mais il s'agit là de mathématiques de assez haut niveau. Mais brièvement:
Pour la première personne: Les mouvements de la souris changent deux angles, phi et theta. Ces angles sont ensuite utilisés pour faire tourner la caméra. Les controles de déplacement ne font rien d'autre que bouger la caméra vers l'avant, ou l'arrière, la gauche ou la droite (avec des additions de vecteurs).
Pour la troisième personne: Même principe, sauf que phi et theta modifient l'orientation de la tête du joueur, et la caméra est placé vers l'arrière du joueurs, relativement a sa tête: donc quand tu tourne la tête, la caméra reste derrière.
Un truc a savoir: OpenGL n'a pas grand chose a voir avec la caméra, ne pas les confondre.
Les devs de Minecraft utilisent LWJGL, et non pas un moteur de jeu.
Et ils s'en bouffent les doigts.
Quand l'objectif est de développer un jeu, on utilise un moteur de jeu. Parce que dans le cas contraire, ça aboutira toujours à devoir re-développer un moteur, même minimal. Et le résultat ce sera un effort de développement plus élevé pour obtenir un résultat moins bon car moins concentré sur une tâche précise.
Nass0931 a écrit:
Pour les graphismes, c'est de l'OpenGL. Les modes de vues sont donc gérés avec des transformations matricielles, mais il s'agit là de mathématiques de assez haut niveau.
Pour la caméra, c'est des maths assez basiques, pas besoin d'aller très loin. C'est plutôt pour avoir un bel éclairage qu'il va falloir réfléchir. (Et pour tout ce qui vient derrière).
Quand l'objectif est de développer un jeu, on utilise un moteur de jeu. Parce que dans le cas contraire, ça aboutira toujours à devoir re-développer un moteur, même minimal. Et le résultat ce sera un effort de développement plus élevé pour obtenir un résultat moins bon car moins concentré sur une tâche précise.
- Edité par Ksass`Peuk il y a environ 1 heure
Mais justement, le fait de devoir re-développer un moteur a des avantages:
Tu ne dépend pas d'un autre logiciel
Tu n'a pas besoin d'aller chercher un tutoriel pour utiliser un logiciel
Ton moteur est optimisé pour ton jeu, donc le jeu est plus léger et rapide
Tu sais faire un moteur de jeu, et ça c'est cool
Le jeu est normalement plus rapide, car il y a juste ce qu'il te faut, ni plus, ni moins.
Si tu veut rajouter une fonctionnalité dans ton jeu, mais qu'il faut modifier le moteur pour y arriver, tu peux.
Une fois que ton moteur est fait, tu peut le réutiliser pour faire d'autres jeux, et tu saura toujours mieux l'utiliser qu'un moteur tierce.
Ksass`Peuk a écrit:
Pour la caméra, c'est des maths assez basiques, pas besoin d'aller très loin. C'est plutôt pour avoir un bel éclairage qu'il va falloir réfléchir. (Et pour tout ce qui vient derrière).
- Edité par Ksass`Peuk il y a environ 1 heure
La caméra possède quand même deux matrices: une de projection, et une de vue. En effet, l'éclairage demande encore plus de connaissances, mais la gestion de la caméra demande quand même au minimum de savoir ce qu'est une matrice et une transformation...
Je rajouterai au commentaire de ROMAINPCLECHAT qu'au début du jeux vidéo (et même de l'informatique), il n'y avais que le processeur qui s'occupait des graphismes. Ce n'est que par la suite, et pour répondre au demande en puissance de plus en plus élevée des jeux vidéo, qu'on a décidé de rajouter un composant pour faire ces calculs plus rapidement, et de manière plus optimisée que le processeur: la carte graphique. La plupart des PC en possèdent une aujourd'hui, mais pas tous. Certains processeurs "intègrent" une carte graphique.
Et en effet, pour utiliser cette carte graphique, il faut des pilotes. Et ces pilotes aussi facilitent la tâche en nous évitant de coder des millions de lignes de code ! C'est eux qui nous permettent également de communiquer de la même manière avec une carte NVIDIA qu'une carte AMD ou même une carte intégré au processeur, via des API graphiques, les deux plus connues étant Direct3D et OpenGL ! Cependant, ce n'est pas le pilote qui fait tout le boulot, le pilote a pour seul but de commander la carte graphique, car c'est dedans que sa passe toute la magie (comme dessiner un triangle. C'est d'ailleurs la seule forme qu'une carte graphique sait dessiner, car a partir d'un triangle, on peut faire toutes les formes possibles et imaginables, inutile de lui apprendre a faire un rectangle si elle sait déjà le faire ?).
Ça fait déjà pas mal, mais dit toi qu'il ne s'agit la que de la partie "graphismes" d'un jeux vidéo, et encore, tout n'est pas là. Un jeu c'est aussi: des sons, des physiques, des contrôles (joystick, clavier souris, casque de réalité virtuelle...), mais il faut aussi porter son jeu sur toutes les plateformes: windows, linux, mac, consoles portables, consoles de salon...
Mais justement, le fait de devoir re-développer un moteur a des avantages:
(1) Tu ne dépend pas d'un autre logiciel
(2) Tu n'a pas besoin d'aller chercher un tutoriel pour utiliser un logiciel
(3) Ton moteur est optimisé pour ton jeu, donc le jeu est plus léger et rapide
(4) Tu sais faire un moteur de jeu, et ça c'est cool
(5) Le jeu est normalement plus rapide, car il y a juste ce qu'il te faut, ni plus, ni moins.
(6) Si tu veut rajouter une fonctionnalité dans ton jeu, mais qu'il faut modifier le moteur pour y arriver, tu peux.
(7) Une fois que ton moteur est fait, tu peut le réutiliser pour faire d'autres jeux, et tu saura toujours mieux l'utiliser qu'un moteur tierce.
(1) Tu dépends déjà de la version de la JVM et de la version de la bibliothèque graphique bas niveau que tu utilises.
(2) A la place, tu vas devoir parcourir moultes tutoriels pour avoir une conception solide, et acquérir les connaissances nécessaires à son développement. Sans parler des heures de debug et d'optimisation.
(3) Non, tu rêves. Les moteurs de jeux comme Unity ou Unreal c'est des milliers d'heures de développement, de debugging et d'optimisation par des experts de leur domaine. Si tu veux avoir un truc plus rapide, même en optimisant pour ton jeu, il faut que tu ailles les battre sur leur propre terrain et bon courage.
(4) Oui, mais en fait c'est un projet à part entière qui devrait être fait en dehors de toute idée de développer un jeu en même temps. Pour concentrer les efforts et la conception sur cette tâche particulière et pas de diviser la concentration sur plusieurs tâches différentes simultanément.
(5) Cela revient à (3). Et je le répète : non. En particulier, il n'a pas les années d'optimisations des moteurs courants.
(6) Cas au combien rare pour ne pas dire inexistant pour un indé et encore plus pour un débutant.
(7) Super tu sais utiliser un moteur branlant, utilisé nulle part, qui n'a certainement pas la stabilité des moteurs bien établis, ni leurs performances. Tu aurais utiliser ce temps pour apprendre à utiliser un moteur, tu aurais gagné beaucoup de temps pour tes développements futurs. S'ajoute à cela que ce qui est critique pour les performances d'un jeu, c'est les performances du moteur, pas celle du programme qui le pilote.
Nass0931 a écrit:
mais la gestion de la caméra demande quand même au minimum de savoir ce qu'est une matrice et une transformation...
1: Sauf si tu le fait en C++, dans ce cas la tu ne dépendra que de l'API graphique, mais c'est quelquechose que tout les jeux ont en commun, donc ça ne pose pas de problème.
2: Sauf si tu sais déjà le faire ! En effet, si tu n'y connais rien dans la création d'un moteur de jeu, il vaut mieux en utiliser un qui existe déjà, comme Unity ou Unreal Engine.
3: Mais d'optimisation pour un domaine de jeu vidéo très vaste: de l'open world à l'RPG, en passant par le MOBA et le shoot'em up, les jeux de gestion ou encore les jeux de cartes. Tandis que ton moteur, il sera fait pour faire un seul type: par exemple, un shoot'em up.
4: En effet, on ne commence pas a faire un moteur de jeu juste pour développer un jeu. Ça doit être un projet a part entière qui doit te servir plus tard pour faire des jeux.
5: Si tu compte faire un moteur pour faire tout les types de jeux, c'est clair que pour optimiser autant que les autres moteurs, ça va être compliqué. Mais si tu te concentre sur un domaine bien précis, tu devrai pouvoir au moins les égaler.
6: Mais ça peut toujours arriver !
7: Après, tu décide d'utiliser un moteur ou non en fonction du jeu que tu veut faire. Si c'est un petit jeu, il vaut mieux faire ton propre moteur, mais si tu prévoit de faire un gros jeu open-world, en effet tu gagnera du temps a apprendre un moteur déjà existant qu'en faire un avec assez de fonctionnalité.
Choisir d'utiliser un moteur ou non est un choix important. Il faut savoir si tu gagnera plus de temps en créant ton propre moteur, ou en apprenant a en utiliser un autre. Pour le cas de Minecraft, son créateur, Markus 'Notch' Persson, a développer Minecraft sans moteur car à l'origine, son but était juste d'apprendre a utiliser java et LWJGL. Si il aurait apprit a utiliser un moteur, alors il sera juste capable de faire un jeu avec ce moteur, et uniquement ce moteur. Mais comme il sais déjà faire son moteur, alors il ne dépend que du langage et des API, chose qui est plus facilement obtenable partout, et de manière gratuite.
1: Sauf si tu le fait en C++, dans ce cas la tu ne dépendra que de l'API graphique, mais c'est quelquechose que tout les jeux ont en commun, donc ça ne pose pas de problème.
Raté, tu seras dépendant de l'implémentation de C++ (parce que pas d'ABI standard). Tu seras dépendant de ta version d'OGL ou de DX. Tu seras dépendant de ta bibliothèque gestionnaire de fenêtre. Et si tu t'y prends mal t'auras des dépendances d'OS.
Nass0931 a écrit:
2: Sauf si tu sais déjà le faire ! En effet, si tu n'y connais rien dans la création d'un moteur de jeu, il vaut mieux en utiliser un qui existe déjà, comme Unity ou Unreal Engine.
Même en sachant déjà le faire, le temps de développement, debug et optimisation explose le temps nécessaire pour apprendre à utiliser un moteur.
Nass0931 a écrit:
3: Mais d'optimisation pour un domaine de jeu vidéo très vaste: de l'open world à l'RPG, en passant par le MOBA et le shoot'em up, les jeux de gestion ou encore les jeux de cartes. Tandis que ton moteur, il sera fait pour faire un seul type: par exemple, un shoot'em up.
5: Si tu compte faire un moteur pour faire tout les types de jeux, c'est clair que pour optimiser autant que les autres moteurs, ça va être compliqué. Mais si tu te concentre sur un domaine bien précis, tu devrai pouvoir au moins les égaler.
(3) Tu étales ta méconnaissance du sujet. Le type de jeu a un impact pour ainsi dire invisible sur l'optimisation du moteur en terme de performances, et c'est de loin la première difficulté dans le développement d'un moteur ...
(5) Et si tu penses pouvoir les égaler même sur un domaine précis, tu rêves encore plus. Je t'invite à aller voir le post sur le moteur Nazara sur le forum. @Lynix bosse dessus depuis 6 ans maintenant, et c'est pas une tâche en C++, très loin de là. Et il n'aura jamais la prétention de dire égaler Unity ou Unreal.
Nass0931 a écrit:
6: Mais ça peut toujours arriver !
... Quand j'écris le mot "rare", c'est pas "un débutant aura rarement besoin de ça", c'est "on aura rarement un débutant qui aura besoin de ça". Cela fait une sacré différence. En l'occurrence, à supposer que ça arrive, trouver un workaround sera plus court que faire une modification de moteur de toute façon.
Nass0931 a écrit:
Pour le cas de Minecraft, son créateur, Markus 'Notch' Persson, a développer Minecraft sans moteur car à l'origine, son but était juste d'apprendre a utiliser java et LWJGL. Si il aurait apprit a utiliser un moteur, alors il sera juste capable de faire un jeu avec ce moteur, et uniquement ce moteur. Mais comme il sais déjà faire son moteur, alors il ne dépend que du langage et des API, chose qui est plus facilement obtenable partout, et de manière gratuite.
Et Minecraft a payé le prix de l'incompétence de Notch sur le domaine du moteur pendant des années. La sous optimalité du jeu et l'horreur en terme de performances, c'était pas Java, c'était le code Minecraft. Le résultat c'est que les développeurs en ont chié (et en chient encore) pour maintenir le jeu à flot et que des portions monstrueuses du code ont dû être réécrites.
_ faire son moteur c'est intéressant et ça apprends plein de truc, d'ailleurs il sort encore de nouveaux moteurs de jeux.
_ faire son moteur c'est pas rentable et en tant que pro il est préférable d'utiliser un bon outils existant (ou sinon le créer avec une grosse équipe d'expert insomniaque et un gros chèque)
Enfait, si tu veut être sur de finir un jeu et que t'es indé, il vaut mieux utiliser un moteur existant. Car en effet, tu gagnera du temps a apprendre à l'utiliser plutôt que de faire ton propre moteur, et tu aura plus de chance d'aboutir a un jeu jouable et bien fini.
Mais si tu est plus dans le cadre pro, que tu dirige une bonne entreprise de jeu vidéo, il y a un moment ou il faut créér son propre moteur de jeu propriétaire. Exemple: Rockstar Games ont leur propre moteur, RAGE, Gaijin aussi, avec Dagor Engine, Ubisoft ont Anvil...
Par contre, si tu veut juste faire un moteur pour le fun, bah tu peut sans problème. Et tu peut toujours l'utiliser pour faire des jeux dans le futur, si t'en a envie.
Mais si tu est plus dans le cadre pro, que tu dirige une bonne entreprise de jeu vidéo, il y a un moment ou il faut créér son propre moteur de jeu propriétaire. Exemple: Rockstar Games ont leur propre moteur, RAGE, Gaijin aussi, avec Dagor Engine, Ubisoft ont Anvil...
Oui et non. Énormément de jeu dans les AAA sont développés avec un moteur à large distribution. Exemple, la série des Batman de Rocksteady, c'est l'UE3, pareil pour Bioshock, GearsOfWar, MASS EFFECT PUTAIN (pardon), pour l'UE4, on a aussi de petites productions comme SFV.
Après, un scénario très commun c'est des studios qui achètent des licences de gros moteurs et qui vont modifier ce moteur pour répondre exactement aux besoins définis par l'équipe de développement du jeu. Ou encore de backporter des optimisations d'une version à l'autre. Cela coûte beaucoup moins cher et évite d'avoir une équipe très chère dédiée au développement d'un moteur.
Après, les très gros studios vont parfois capitaliser sur un moteur maison qu'ils vont faire évoluer au fil du temps comme ceux que tu cites, on peut citer aussi Bethesda ou EA avec le FrostBite par exemple. Mais là, c'est même plus une question de "bonne entreprise", c'est une question de boîte avec un capital colossal.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C