J' apprend le java et j' aimerais savoir
si il est possible de faire
un MMORPG en java en temp réél.
Je vous
remercie d' avance pour votre aide. | Version imprimable du sujet
Cliquez ici pour voir ce sujet dans son format original |
| Forum TourDeJeu > Programmer > Mmorpg Java |
| Ecrit par: amaury Mardi 09 Novembre 2004 à 15h41 |
| Salut tout le monde, J' apprend le java et j' aimerais savoir si il est possible de faire un MMORPG en java en temp réél. Je vous remercie d' avance pour votre aide. |
| Ecrit par: ovni Mardi 09 Novembre 2004 à 16h37 |
| Vu la precision de ta question je vais commencer par repondre betement ... Oui bien sur tu peux faire un MMORPG dans n'importe quel langage que ce soit du php de l'asp du java mais aussi du C du Fortran du Perl voir meme du BASIC ( encore que la j'ai un doute sur les fonctions reseaux mais avec un compilateur moderne comme http://gambas.sourceforge.net/ les fonctions reseaux doivent largement exister ... ) Bon un peu plus serieusement , comme tu le sais certainement si tu apprend le JAVA tu as au moins 3 manierre de l'uttiliser -En stand Alone ( d'ailleurs tu ne le sais peut etre pas mais tu peux aussi le faire avec PHP ) j'entend par la un prog que tu telecharge , et que tu execute sur ta machine ( en clickant sur l'icone ou en l'appelant dans la console ) -En applet Java: en gros c'est ce que tu vois souvent sur les sites les applets qui font tout ralentir en affichant par exemple une image avec un effet eau mais il y a des tas d'autre possibilite -En Servlet : Tu execute les programme Java sur le serveur ( Comme un script php/asp/pl ) Une remarque generale neamoins en particulier pour les Servlet et les stand Alone : Attention il faut un hebergeur qui accepte ca , donc certainement un serveur dedie . A moins bien sur que tu invente une technique pour te passer d'un serveur ... Je laisse les experts te repondre sur les points technique ... |
| Ecrit par: Guest_amaury Mardi 09 Novembre 2004 à 16h53 |
| Merci pour ta reponse Pour plus de précision je souhaite faire un MMORPG en temps réel(dark age of camelot like) en java dans un univers medieval fantastique avec des graphisme 2d. Je pense le faire pas en applet mais en application. Si vous voulez me filez un coup de pouce  il sera le bienvenu. Comme je n' ai jamais fait de MMORPG je ne suis pas t rès fort donc je pense que cela se fait avec un tableau avec un texture sur chaque cases. Mais en temps réél je ne suis pas sur de l' existence d' un base de donnée comme MySQL. Sinon quelqun connait un JDK pour compiler mes source java plus vite? Sinon je vous remercie tous d' avance pour vos réponse. |
| Ecrit par: Cedric Mardi 09 Novembre 2004 à 18h53 | ||||
C'est tout a fait possible de le faire en Java. Le site de Sun reference d'ailleurs un certain nombre de jeux en 2D/3D en Java.
Comment ca ??? |
| Ecrit par: Grouik Mardi 09 Novembre 2004 à 20h31 | ||
Heu... un MMORPG peu (théoriquement) très bien se passer de graphisme, donc les problèmes de graphismes et consorts ne sont selon moi qu'un élément connexe au jeu. Le plus gros problème réside plutôt dans la notion de "Massive" pour un jeu en temps réel (ce que tu souhaites faire si j'ai bien compris). Gérer un grand nombre de personnes en temps réel implique, outre les aspects matériels comme un gros (synonyme : cher) débit au niveau du serveur, une gestion applicative du réseau pas simple (asynchronisme des actions entre les joueurs, déconnexion temporaires, etc...). Mais en même temps ça doit être sympa à faire. Complexe, long, mais sympa  Et tu n'as pas trouvé un langage plus gourmant en ressources que Java ?  |
| Ecrit par: Nonothehobbit Mardi 09 Novembre 2004 à 20h46 |
| Pour le serveur, tu peux en faire un solide en java je suis sûr, mais pour l'application cliente, avec des jolis graphismes 3D et tout dans un monde où il y aura plein de joueurs, j'ai peur que java ne tienne pas la route (ou alors faudra voir les graphismes à la baisse, ou alors faudra avoir une bonne machine pour le client). Donc pour un ptit mmorpg avec des graphismes sans prétentions, je pense que c'est possible, mais si tu veux un everquest/daoc like, je crois que java n'est pas super approprié, enfin c'est mon avis... Sans oublier que le client devra posséder une machine virtuelle java, pas cool. Cela dit, rien ne t'empêche de faire un serveur en java et un client en autre chose.  |
| Ecrit par: pascaltje Mercredi 10 Novembre 2004 à 12h04 |
| personne n'a pensé aux jsp? ça permet un jeu par navigateur, tout simplement, comme en php ou asp... A+ Pascal |
| Ecrit par: Cedric Mercredi 10 Novembre 2004 à 12h18 | ||
C'est marrant comme les a priori ont la peau dure Contrairement a ce que beaucoup de monde semble croire, Java est aussi performant que le C++ dans l'absolu, y compris en ce qui concerne les graphismes. La raison pour laquelle les graphismes en Java sont reputes lents est liee au fait que lorsque l'on developpe une application graphique, on utilise en general Swing... Or les composants Swing utilisent des composants AWT... qui utilisent des composants natifs. Alors qu'un widget C++ attaque directement du natif. Mais pour une application comme desire le faire notre ami, Swing est loin d'etre indique... je preconiserais plutot de passer par AWT, voire par SWT (ce sur quoi repose Eclipse). Et en terme de performances, ca devrait etre assez proche du C++ (mais pas du C neanmoins), sous reserve de programmer proprement. |
| Ecrit par: Grouik Mercredi 10 Novembre 2004 à 15h00 | ||
Dans l'absolu peut-être... mais tu ne manipules pas la mémoire en Java comme tu le fais en C / C++. Garbage Collector pas trop powa pour le coup  |
| Ecrit par: zumba Mercredi 10 Novembre 2004 à 15h36 |
| moi, maintenant, quand on me parle de faire du multimédia web, je pense flash. c'est quand meme fait pour meme si je ne suis pas assez doué en flash pour me faire un avis précis... cependant, si flash est balez pour faire du vectoriel, il n'en va pas de même pour faire du matriciel. Bon plus généralement pour une architecture clientWeb/serveur temps réel ne souffrant ni lag ni désynchronisation, à mon avis si tu veux faire du vrai temps réel qui tient la route il faut déléguer le maximum de traitement au client et minimiser au maximum la fréquence et le volume du dialogue client serveur. Donc le plus efficace est d'avoir client side : - un code client-side qui construit entièrement l'univers graphique et en stocke une bonne partie (tilesets - pour lesquels on peut considerer que le cache du navigateur joue plus ou moins le rôle de buffer-, et buffer local (partiel ou complet)de données de jeu genre typiquement la carte). ca peut etre du flash, du JS généré par ce que tu veux (asp, php), du svg, une applet... - un écouteur / répondeur branché sur un socket IP permanent du serveur, qui écoute des messages systèmes réduits à leur plus simple expression, comme si c'étaient des procédures, les interprete et répercute sur l'IHM. Ca je sais pas trop si on peut l'implémenter en JS (socket ip en JS, qqun en a entendu parler ?). mais en applet java ou en flash c'est faisable. Cet écouteur peut ensuite invoquer des méthodes JS locales à la page. La solution de l'activeX, s'il s'avère que mozilla les se mette à les supporter, serait pour moi la panacée (développement, mise à jour, dialogue avec le reste de la page...). et server side : pour la DB : php, asp, jsp, python... même combat ! mais uniquement les opérations de base de donnée avec leurs vérifications et - un écouteur-répondeur IP tournant en permanence : là est d'après moi le vrai choix technique : il faudrait avoir un programme type exécutable tournant en permanence sur le serveur. je ne pense pas trop que ce soit réalisable en script. un script qui boucle à l'infini se fera time-outer par apache/iis et avec une astuce telle un cron qui rapelle le script, on ne parle plus de temps réel. Et de toute facon derrière toute technologie web -et quoi qu'on bidouille sur la couche script- il y a le serveur web, une techno fondamentalement basée sur le sacro-saint principe de l'action/récation (requete/réponse si vous préferez) donc par définition asynchrone. Donc d'arès moi on ne peurt faire du vrai temps réel sans se dédouanner du service web. Elle ne peut donc pas être détournée à des fins de pseudo-synchronie. MAIS, elle peut completer un véritable module temps réel, car quand on y réfléchit, les éléments d'un jeu devant être rigiureusement temps réel peuvent se factoriser à tres peu d'éléments basiques, le reste pouvant rester du script C/S. Typiquement "je parle", j'envoie un texte à tous les écouteurs situés dans un rayon x/y limité. je bouge : pareil, jenvoie un message à tous ceux du coin "videLaCase(oldX, oldY), affiche avatar(newX,newY), donc ca c'est du broadcast limité par les coordonnées. Ensuite quand j'atatque un gars ou que je commerce avec lui là c'est un appel direct sur l'écouteur de l'autre joueur avec une méthode du genre "déclencheAction(combattre, zumba)". Et pour ce qui reste du client serveur : bah la fiche du perso, l'inventaire, la carte générale... bref tout ce qui n'a pas besoin d'être à jour a tout instant et surtout dont la mise à jour peut être déclenchée par un évènement synchrone...) bref pour moi il faut du lourd pour une partie du serveur. c'est pas forcément contraignant niveau développement, bien au contraire (pour te dire je développe mon seveur en VB -oui, oui, en VB!-, c'est du bonheur à débugger pas à pas, mais attention mon jeu est en tour par tour completement asynchrone aussi, je n'ai pas besoin que l'environnement client d'un joueur soit mis à jour aussitôt qu'un autre ramène une troupe dans son fief, problématique singulièrement différente dans un JDR ou 'temps réel' revet tout son sens). Mais là attention, difficulté : héberger un exe, ou du lourd, c'est autrement plus compliqué à trouver (mais pas impossible et pas nécéssairement hors de prix). voili voilo, ca n'intéressera que moi mais ca faisait un bout de temps que j'avais envie de théoriser tout ce que j'avais dans le crane concernant le délicat problème des architectures synchrones dans les jeux web.(web/synchrone, un contresens ??) zumba |
| Ecrit par: Guest_amaury Mercredi 10 Novembre 2004 à 16h53 |
| Merci Je ne compte pas faire le jeu tout seul. J' ai deja un graphiste et un scenariste mais je cherche un quelqu' un qui vat s' occuper du reseaux et d' autres graphiste ainsi qu' un webmaster. Sinon pour le prix: si le jeu me parait assez bien je le rendrez payant pas cher mais 5 a 10 euros par mois on verat et en plus c' est bon pour le rp. Mes graphismes seront en 2D pour que le jeu soit plus leger. Le JDK est un environement de devellopement intégrer et ce ne serat pas un applet mais une application que l' on devrat télécharger. |
| Ecrit par: Nonothehobbit Mercredi 10 Novembre 2004 à 21h49 | ||
Mwé, en même temps si c'est pour refaire toute l'interface à 0, en dur c'est pas top. Si j'ai dit ça c'est par expérience, ayant déjà un peu touché à Java3D (qui utilise OpenGL)... Honnêtement c'est pas excellement rapide, en tout cas je vois pas un mmorpg 3D (avec textures et tout) tourner là dessus, mais bon je suis pas un crack non plus. Par contre, tu devrais regarder du côté de shockwave, j'ai vu des choses assez impressionantes en 3D. Je sais pas ce que ça vaudrait pour un mmorpg mais ça coûte rien d'aller faire un ptit tour. |
| Ecrit par: askywhale Jeudi 11 Novembre 2004 à 13h35 |
| Jsuis d'accord avec Cedric (affichage 2d:java tient le coup tranquille) et Zumba (client lourd serveur faible, broadcasts selectifs),et tant qu'a faire je conseillerais une solution j2ee sous jsf. Questions en reste : la base de donnée tu t'en fout tu pourra changer plus tard Plus vite : heu non, tu parle de compil ou d'execution plus rapide ? En tout cas il me semble que c'est du lourd rien que pour le codage (pas moins de 10 mois/hommes, 50 me parrais + probable, et avec des gens expérimentés dans ces technos) |
| Ecrit par: Nonothehobbit Jeudi 11 Novembre 2004 à 19h25 |
| Ah non, là dessus je te contredis. L'avantage de java en tant que langage de haut niveau, c'est justement d'économiser pas mal de temps de codage et de débugage. |
| Ecrit par: askywhale Jeudi 11 Novembre 2004 à 19h58 |
| Je ne suis pas d'accord Java est plus performant, plus maintenable, plus extensible (et autres qualités encore) que php ou autre langage + bas niveau, mais n'est certainement pas plus rapide à coder, et pas beaucoup plus à débugguer. Dans tout les cas, mon estimation était sur la techno que je proposait (archi j2ee) ; je parle en tant que professionnel et formateur sur cette techno. Maintenant, c'est fou ce qu'on peut faire avec 2 ou 3 potes rien qu'en bossant durant les we |
| Ecrit par: Cedric Samedi 13 Novembre 2004 à 00h21 | ||||
En fait, notre ami se dirgeant plutot vers le 2d, Java 3d ne l'interesse pas trop  Enfin, pour faire de la 3d en Java, il y a quand meme des packages Java mieux faits que Java 3d, je trouve. J'ai recemment tester un excellent outil de ce style, et surtout bien plus facile a utiliser que Java 3d. Par contre, ca ne dispense pas de connaitre les bases de la programamtion 3d (notion de scenes et autres).
Pour le temps de codage... y'a quand meme un avantage a utiliser Java par rapport a des langages de bas-niveau car Java est quand meme fourni avec une toolbox de base assez exceptionnelle. Pour debugger, je trouve qu'il y a un gros avantage a utiliser Java par rapport a du C... le fait de reposer sur une machine vitruelle permet quand meme de faire des choses que gdb ne permet pas trop, ou permet de maniere peu ergonomique. Au final c'est quand meme surtout une question d'affinites |
| Ecrit par: TheNerf Lundi 15 Novembre 2004 à 23h16 |
| Bonjour, bonsoir, A titre personnel, je fourni ici mon expérience en la matière et je dit :  Zut, je sais plus... Ah si : j'ai fait un Chat en Java (à voir donc sur http://www.fighting-club.com...) et il est graphique, ne pèse rien et n'utilise pas trop les trucs tout fait (d'où son poids ridicule de 30Ko je crois). Mais... car il y a un mais : le serveur ne peut accepter sans toussoter plus de 20 personnes en simultanées. Et encore... Alors, j'ai réécris le serveur en VB (on dira ce qu'on veux du VB...). Même topo... Alors, sauf faire du P2P et gérer cela correctement genre une salle = un serveur (client en serveur), sinon, pas simple. Le problème se trouve à l'entrée des salles... Ils ont tendances à rentrer par l'entrée ! Saligos !!! |
| Ecrit par: Lxir Mardi 16 Novembre 2004 à 10h51 |
| Hum... si tu es en train d'apprendre Java, ça ne va pas être super simple. Mais c'est faisable. Pour faire un jeu en mode connecté (comme Sepao), il faut que tu développes ton propre protocole de communication client-serveur. Le protocole en lui-même est très simple (passages de chaines de caractères), mais la manipulation des flux est plus complexe et pose parfois des problèmes. Je te conseille de commencer par faire un chat: ça va te donner une idée de l'architecture et des techniques à utiliser. Ensuite, tu peux y greffer une base de données. Quand déjà tu auras fait ça; tu auras une base sur laquelle tu pourras poser une interface et des concepts propres à ton jeu. |
| Ecrit par: Cedric Mardi 16 Novembre 2004 à 11h49 | ||
Ayant developpe une appli qui devait servir une centaine de clients, je pense que tu as surtout eu un probleme de design. |
| Ecrit par: askywhale Mardi 16 Novembre 2004 à 20h22 |
Nan, mais ils avaient pu de sous après avoir acheté wsad, alors leur serveur c'est un 386  Je sais pas ce que c'est comme hébergeur chez afc, mais meme en codant très mal ça me parait être des perf vraiment pas bonne quand même |
| Ecrit par: TheNerf Mardi 16 Novembre 2004 à 23h42 | ||
| Comme hébergeur ? Je suis mon propre hébergeur... Ce n'est pas une question de serveur. J'ai testé sur plusieurs serveurs.
Euh... Je dois être un peu à la masse ce soir, mais c'est quoi wsad ??? Avez-vous testé ce genre d'application ? Avez-vous déjà fait des tests avec plus de 20 connexions simultannées ? Ce n'est pas un problème graphique, ça tiens bien la route. Mais j'ai connu d'autres applications du même genre qui ne pouvaient pas tenir plus. Et ce n'était pas moi le développeur... M'enfin si vous m'assurez que ça peut fonctionner, je vous crois. Je vais revoir un peu ma programmation... J'en aurais bien besoin alors... |
| Ecrit par: Grouik Mercredi 17 Novembre 2004 à 00h46 | ||||
WSAD : WebSphere Studio Application Developer. Comme son nom l'indique, c'est un environnement de développement - plutôt complet au demeurant puisqu'utilisant moult contributions d'Eclipse (le pendant open source de WSAD) et "intégré" par IBM - de projets Java tournant sur un serveur WebSphere. Note : prévoir de la RAM à foison pour faire marcher le bouzin sans s'énerver  Just my 2 cents... |
| Ecrit par: TheNerf Mercredi 17 Novembre 2004 à 00h50 |
| Et bin donc, pas de ça ici... Fait avec Notepad le Chat... |
| Ecrit par: khiguard Mercredi 17 Novembre 2004 à 04h08 |
| Je préfère prélude et sa façon artisanale de programmation. @+ |
| Ecrit par: Cedric Mercredi 17 Novembre 2004 à 10h52 | ||
De mon cote, la charge serveur etait bien plus importante que pour un chat et les tests ont ete realises avec 50 utilisateurs concurrents. Mais pour resoudre ton probleme, le mieux est de voir d'ou les problemes venaient : - charge CPU serveur ? A priori non, vu que vous avez teste sur differents serveur... - bande passante en sortie ? - probleme de section critique sur le serveur ? (chaque client bloque tour a tour les autres clients pendant un pouilleme de seconde pour faire des operations critiques) - probleme d'E/S sur le serveur (entrees/sorties comme vers des fichiers ou une BDD) ? Si tu arrives a repondre a ca, tu trouveras la solution a ton probleme. |
| Ecrit par: khiguard Mercredi 17 Novembre 2004 à 13h58 |
| Pourtant, je pensais qu'un chat java était super léger. Sinon un chat php ne serais pas plus léger pour le serveur? @+ |
| Ecrit par: askywhale Mercredi 17 Novembre 2004 à 14h58 |
| Arg non, php fait passer des script (donc chaque "application" n'a pas de processus indépendant, et encore moins une appli centrale qui gère tout les client). Les clients sont donc obligé de faire des appels réguliers (javascript) pour savoir si quelque chose c'est passé, une requète, une recherche de bd, une réponse à chaque fois... |
| Ecrit par: Cedric Mercredi 17 Novembre 2004 à 15h55 | ||
En fait, ca depend de ce que l'on entend par leger : parle-t'on de memoire ou de CPU ? Sinon, pour repondre a ta question, ca depend de la maniere dont c'est concu : - un chat reposant sur un serveur Java et contacte par des applets clientes est tres en terme de memoire et CPU, du fait que c'est le serveur qui contacte les applets pour les mettre a jour et non l'inverse. - si les clients sont des pages HTML qui se raffraichissent toutes les secondes, par exemple, la montee en charge est plus difficile... et pour que le serveur ne lache pas, il faut utiliser un mecanisme de cache pour eviter que le serveur tombe en terme de CPU. - si le serveur est compose de page PHP, le probleme est ce qu'ecrit Askywale : chaque PHP doit etre executee dans une environnement d'execution different (contrairement a un serveur Java compose de Servlets/JSP) ce qui fait que pour 10.000 clients, il y a 10.000 php.exe qui tournent. Et le probleme bloquant devient alors la Memoire. (par contre il est quand meme necessaire d'utiliser un cache pour que le serveur ne tombe pas a cause de la charge CPU) C'est un peu trop schematique et basique comme presentation, mais en gros ca repond a la question |
| Ecrit par: askywhale Mercredi 17 Novembre 2004 à 21h04 |
| Le mot que manque dans le message précédant est "lourd". En conclusion, il faut chercher : - une erreur de design : utiliser du profiling, analyser à la main, chercher une imprémentation opensource existante (en java ou non pour comparer) - une erreur bete dans le code (ça arrive) - une erreur dans la techno utilisée pour la communication (tpc sockets ?) mais en principe du java sur une machine moderne doit proposer des performance bien meilleure que ça |