Mmorpg Java, peut t' on en faire un

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.

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 GAMBAS 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 ...

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.

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 ???

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 ?

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.

personne n'a pensé aux jsp?

ça permet un jeu par navigateur, tout simplement, comme en php ou asp...

A+

Pascal

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.

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

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

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.

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.

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)

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.

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

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

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 AFC...) 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 !!!

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.

Ayant developpe une appli qui devait servir une centaine de clients, je pense que tu as surtout eu un probleme de design.

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

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...

Euh... Je dois être un peu à la masse ce soir, mais c'est quoi wsad ???

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...

Et bin donc, pas de ça ici...
Fait avec Notepad le Chat...

Je préfère prélude et sa façon artisanale de programmation.
@+

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.