FORUM Xbox 360 & Xbox » Making Of » Projet Java

Ancien projet:
 

 
Nouveau projet:
Un ensemble d'outils pour la création de jeux 2D (principalement RPG) de type RPG Maker.

J'avais trouvé ça il y a maintenant pas mal de temps, c'est ptet pas les plus jolis sprites du monde mais ça sera mieux que des carrés pour tes tests et au moins tu as le droit de les utiliser

Merci Zeross

Un pote (qui était dans le groupe de création de la démo de Zelda dont j'ai parlé plus haut mais qui finalement n'a rien fait du tout) m'a fait remarquer l'existence d'une méthode intersects dans la classe Rectangle de Java (étonnant de sa part, vu que c'est un gros glandeur ) qui aurait pu vachement me simplifier la vie si je l'avais trouvée à l'époque !
 
C'est moi qui me suit occupé des collisions dans la démo (ainsi que tout ce qui touche à Link : animations, combats...), les seuls trucs que je n'ai pas codé sont les évènements (coeurs, herbes...) et l'éditeur de cartes (bien que j'ai fourni des billes à mon autre pote pour l'aider dans sa tâche, je pouvais pas tout faire ) et aussi barbare que ça puisse être, j'ai fait tous les tests avec les valeurs des coordonnées avec des signes de comparaison, le truc bien relou
 
Si vous la voulez, je peux vous la mettre quelque part (mais pour le code source, théoriquement je n'ai pas le droit, le projet appartient à l'école, mais bon, je doute qu'ils s'en aperçoivent ), mais vous risquez de me dire que c'est très buggué
C'est jouable mais les animations sont mal fichues (en particulier les attaques).
 
Le tout marche sur tout système d'exploitation mais la musique saccade un peu sur MacOS X.

 
Bah, en même temps j'y toucherais plus à cette démo, quitte à faire quelque chose dans le genre je préfère recommencer.
 

 
Apparemment oui, d'après ce que m'avait dit un de mes profs à l'école. Bon, en même temps si je le réutilise ils vont avoir du mal à le prouver sauf si je n'y fais aucune modification (quasi-impossible).

Java t'es impose ou c'est un "choix artistique"

Bien sur, tu sais y'a bien des gens qui developpent un OS multitache pour intellivision donc l'un dans l'autre

Moi qui essayait d'etre subtile  
Je suppose qu'on peut le "choisir" si le but est de mettre a dispo le jeu derriere sous forme d'applet sur une page web.
Apres perso clairement je tenterais pas de faire un danmaku, suis pas sur que le frame rate suive  

 
Java ne m'est pas imposé car il s'agit d'un projet personnel, je ne suis plus à l'école
 

 
Roh, des jeux 3D professionnels en Java, ça existe vous savez ? (j'ai oublié le nom d'un des jeux sur lequel j'étais tombé par hasard)  
 

 
Mon but n'est pas du tout de faire une applet.
 

 
Je ne savais même pas que la SDL existait en Java A mon avis, les classes du JDK bien utilisées suffisent à créer un shoot'em up performant et fluide, même un Danmaku !
J'ai choisi Java car c'est effectivement le langage dans lequel je suis le plus à l'aise, je hais le C++ que je trouve trop barbare Java n'est pas du tout plus lent que C++, mais il est plus lent que "le C du C++", si je me fais bien comprendre A part un démarrage moins rapide, les applications Java bien programmées sont performantes.
De plus, en choisissant Java, tout le monde pourra essayer ma démo. Si j'avais choisi un autre langage comme l'Objective-C, le C++ ou l'AppleScript, j'aurais été obligé de faire plusieurs versions (sauf pour l'AppleScript, ça aurait été un peu difficile vu qu'il appartient à Apple) selon les systèmes d'exploitation.
 

C'est étrange mais utile et pratique

Pour l'instant, le Danmaku n'est pas à l'ordre du jour pour moi
Je suis un peu occupé en ce moment, pas trop le temps de programmer cette démo... Entre continuer mes jeux, regarder des animes, programmer et apprendre le japonais, il me reste pas grand chose du peu de vie sociale que j'ai

 
Je vais voir ça
Ah la dure vie d'informaticien
 
EDIT : Hallucinant ton BulletML là  
Je pense que ça devrait bien me servir
Merci

C'est un choix, je peux comprendre. Moi je peux pas voir le LISP et pourtant je fais de l'IA

Je demande une definition de bien programme alors, parce que les techniques barbares de programmation full-statique pour pas que le garbage collector se lance c'est pas ce que j'appelerais bien programmer

C'est un mythe qui a la vie dure, mais entre la SDL, QT, OpenGL, Ogre, boost et cie faut presque le vouloir pour arriver a coder un truc pas cross plateforme en C++ (ou coder avec les API microsoft mais ca c'est un autre probleme). Je dis pas que le code est 100% identique mais les differences se limitent a deux ou trois macros et la compilation dans la majorite des cas.

Bah une recompilation c'est parfois bien chiant ! Je déteste ça
Et puis toutes tes librairies là me demanderaient un certain investissement supplémentaire pour un résultat quasi-identique, donc inintéressant pour moi pour l'instant Je préfère me perfectionner avec Java

J'ai ete tente de tester parce qu'on a eu un proj de systeme expert (qui se termine demain a minuit \o/). Mais bon, je sortais de stage, fallait que je refasse du  beau C++ ca me manquait

C'est possible via a vis du format des binaires de windows? J'ai jamais cherche a le faire mais il me semblait que c'etait trop heteroclyte  

Je sais, c'est pour ca que je dis qu'il est interprete
Encore que je suis assez curieux de voir les consequences en fonction des archis: la prediction de branchements des P4 je suis pas persuade qu'elle comprenne le bytecode java  

C'est d'ailleurs marrant de voir les perfs des jeux sur telephones portables: a meme hard le portable avec JIT fait x2 le frame rate du portable sans...

bibliotheques
Ca je dis pas, c'est un choix.

 
Euh de mon expèrience ça serait presque le contraire : même en utilisant des API soit disant cross plateformes il faut se motiver pour que faire du code vraiment portable le dernier exemple que j'ai en tête c'est une appli utilisant Performer, Qt et la STL et qui devait tourner sur IRIX et Linux, donc pas le truc le plus compliqué du monde, ben au final ça marche pas aussi bien tu es obligé comme tu dis de tester et d'appliquer des petites verrues localement pour corriger tel petit truc qui n'est pas géré pareil.
 
Et je passe sur OpenGL ou déjà avoir du code "portable" entre deux cartes 3D ATI et NVIDIA même sous windows est déjà une sacré gageure (surtout quand t'utilises du GLSL entre NVIDIA qui respecte pas la norme, ATI qui a des bugs c'est fun )

Ca je dis pas, mais je partais plus sur une comparaison vis a vis des utilisations courantes du java.
De mon cote, j'ai eu l'occasion de faire un proj cross plateforme avec gestion de webcam. Si la recuperation du flux differe entre les archis, le code de l'affichage sous QT etait identique.

En meme temps, sans un serveur X "natif" derriere sur ton cygwin, ca tournerait moins bien
 
EDIT: on remarquera la magnifique publicitee ciblee que ce thread arrive a generer:
http://tasogarenorequiem.free.fr/java.jpg

Tiens, je ne savais pas qu'il y avait des trucs aussi passionnants sur PF XD
Votre tendre java me rappelle mes récentes douceurs nocturnes sur JSF et le terrible viol de JBOSS sur mon esprit de non initié.
 
Comme je dis souvent "Java, ça pue". Mais au délà de ça, j'aurais dû dire que "Aaaah Java, le temps de prendre un café entre deux traitements"

Faut dire qu'a partir du moment ou c'est pour troller sur java, y'a des fora plus adaptes  

Pareil avec Jonas (et Globus aussi d'ailleurs...) mais J2SE c'est quand meme heureusement moins le bordel que J2EE.

Ca par contre, ca me rappelle un partiel de modelisation objet de systeme de gestion de cafetiere: l'interface machine fournie etait en java

J'avais déjà pas eu le temps de faire grand chose comme travail sur cette démo mais étant encore une fois privé d'ordi pendant 1 mois (vive Apple ), ça ne risque pas de progresser

Bon, quand j'aurais un ordi à moi, je pourrais éventuellement m'y mettre

Bon, j'y pu m'y remettre un peu (enfin commencer surtout ) pendant une petite période creuse au taf
J'ai commencé à programmer les bases, et là je me suis attaqué vite fait au moteur graphique.
 
Je vais nettoyer un peu le code et poster ici, j'aimerais avoir vos commentaires sur la manière dont j'ai réalisé ce premier fragment qui dessine dynamiquement tous les types d'objets du jeu à l'écran, sans que je n'ai à déclarer explicitement à la main ce qu'il faut faire, la méthode est "générique". Et ça tranche pas mal avec mon Zelda avant qui avait été programmé à la va vite pour tenir les délais et dans lequel le moindre ajout d'objet ou de personnage nécessitait un copié/collé de plusieurs lignes et quelques modifications au niveau de certaines valeurs. Ici, tout devrait être transparent

Moi en tout cas je suis intéressé. J'ai eu l'occasion de faire quelques petits jeux avec SDL en C/C++ à l'école mais jamais en Java (que j'utilise le plus pourtant, mais pour des application métier destinées à l'entreprise )

Bon courage

Je vais essayer de montrer la méthode que j'ai choisi pour rendre mon moteur souple et dynamique, il est très loin d'être fini. J'en suis encore au tout début, mais ne voulant pas faire fausse route, des commentaires sur ma méthode s'imposent.
Je repasse tout à l'heure pour mettre ça si je suis pas trop pris par Ninja Gaiden

Donc voici le code en question :  

 
Bon y a encore quelques morceaux de code très temporaires, pour les tests, cette classe est loin d'être finie. Vous vous en doutiez vu le peu de choses qu'elle contient
Donc, j'ai utilisé le principe de la réflexion pour coder ce moteur. En gros, j'utilise des objets de base pour fabriquer une sorte de pointeur qui va aller me récupérer les objets à dessiner dans une liste chaînée(de type Vector). Ensuite, vu que tous les objets à dessiner héritent d'une classe qui contient les méthodes utiles pour le dessin, les noms de méthodes sont donc les mêmes à chaque fois quelque soit la classe. Ce qui me permet d'utiliser la méthode invoke() de la classe Class afin de lui dire d'invoquer la méthode indirectement. Dans le cas actuel, je me sers de ça juste pour récupérer les coordonnées des objets et les envoyer à l'écran.
 
Ah, n'empêche, les listes chaînées sont très simple d'accès avec Java (enfin je n'en doutais pas vraiment mais je ne m'étais pas encore penché sur le sujet) et là je me rends compte que j'aurais dû utiliser ça pour le Zelda, ça aurait été plus pratique ! Ici, il me suffit de déclarer l'objet et de faire un addObjectToDraw() pour l'envoyer à la suite et qu'il soit rendu à l'écran, sur le Zelda je vous explique pas comment c'était peu pratique pour rajouter ne serait-ce qu'un seul objet à l'écran...  
Beaucoup de pertes de temps, des trucs bâclés, on était pressés car le temps passait vite et on n'avait pas tout le temps qu'on voulait pour bien coder ça Mais quand je vois le peu de temps que j'ai pris pour mettre ça en oeuvre, je me dis que franchement j'ai fait n'importe quoi avec le Zelda M'enfin c'est comme ça qu'on apprend
J'ai lu une partie d'un article sur l'architecture d'un jeu en 3D en C++, qui m'a donné des idées pour mon code. Et 2 ou 3 trucs appris à droite à gauche me font utiliser sans m'en rendre compte quelques principes des Design Pattern.

A la lecture j'ai quatre remarques qui me viennent à l'esprit:

1. draw est un verbe irrégulier: drawedObjects me fait mal aux yeux personnellement

2. Je préfererais que quelqu'un te le confirme, pour moi le java ça remonte à un moment. Mais il me semble que vector n'est pas une liste chaînée mais juste un vecteur. La différence étant qu'en cas de dépassement dépassement de capacité ça cause un realloc de tout le vecteur. Tant que t'en es conscient c'est bon, mais faut faire gaffe au dimensionnement de la bestiole (il me semble qu'il y a une classe du genre list qui pour le coup est une vraie liste chaînée).

3. Je suis pas spécialiste du Java (enfin vu mes posts ça tu t'en doutes ), mais je pense très sincèrement qu'il vaudrait mieux caster plutôt que de passer une récupération de la classe avec une recherche de méthode par strings. Ca te fait faire un cast vers l'interface ou la classe en question mais ça me semble quand même beaucoup mieux niveau temps d'exécution parce que là pour chaque objet tu vas avoir deux recherches de méthodes en log (voire en linéaire... je sais pas comment java gère son bordel) du nombre de méthodes de la classe ce qui risque de dégrader pas mal les perfs si tu as beaucoup d'objets.

4. C'est pas forcément pertinent vu que je sais pas ce que tu comptes faire exactement. Mais vu que tu comptes coder un shooting game, je serais d'avis d'organiser tes objets en plans (du genre arrière plan, vaisseau au 2e plan et projectiles au premier), donc plutôt avec un Vector de Vector par exemple (il doit y avoir mieux comme structure mais c'est pour l'idée). Comme ça au moment de la mise à jour de l'affichage tu peux tranquilement faire du plan par plan plutôt que d'essayer de maintenir un genre de Z-buffer.

Autrement ça me paraît pas mal. Mention spéciale à l'indentation  

Je confirmes, d'ailleurs Vector est déconseillé par Sun depuis Java 1.2 il me semble, ils le garde pour des raisons de comptabilité.
Tu peux avoir une liste chainée avec la classe List effectivement (List liste = new LinkedList(); ). Si tu travaille avec java 1.5 ou supérieur, tu peux utiliser les generics et éviter les casts.

J'essaierai de lire (et comprendre ) le code ce soir (là je suis au boulot )

 
Mince, je m'étais pas du tout rendu compte de la faute d'anglais que j'ai fait Ca m'arrive parfois d'oublier certains verbes irréguliers C'est pas très grave pour le code, mais bon merci de me l'avoir signalé Et sans chercher dans un livre d'anglais, je corrige tout de suite ma faute : c'est drawnObjects
 
2. Pour la réalloc je sais, c'est pour ça que j'ai mis un bloc de commentaire à un moment pour me rappeler de me préoccuper de cette gestion. Car si on le laisse faire tout seul, il fait 1 réalloc à chaque ajout après le nombre défini par défaut Je ne savais pas que Vector était déconseillé, je vais donc utiliser autre chose
 
4. La gestion en plans, c'est prévu mais là je n'ai fait qu'une toute petite partie pour tenter et voir ce que valait cette méthode.

 
La réflexion ou recherche de classes/méthodes par nom, effectivement c'est limite hors sujet pour du Java mais comme ça existe, j'ai voulu tenter !
C'est juste pour voir si ça fonctionne ET oui la classe dérivée de Frame est la seule à pouvoir tracer quelque chose, je préfère que ça soit comme ça. Chaque objet s'occupe de ses affaires et pas de celles des autres, c'est mon principe