Voir la version complète : West! : the ouèb mmoRPG orienté Jeu de Rôle
Bonjour à tous, après moult pérégrinations je viens vous présenter un projet de jeu qui mijote sous le soleil du grand Ouest. Son nom temporaire est
West!
Après avoir participé au développement du moteur Ogre, et après avoir développé pendant presque 10 ans pour T4C (La quatrième prophétie) en semi pro (semi vu la misère que j'ai pu gagner niveau pécuniaire ^^), un MMO préhistorique qui a connu la gloire au début des années 2000 (et qui survie encore comme il peut), puis m'être lassé de la tournure que prenait la gestion des serveurs et le développement général j'ai décidé de me lancer dans un autre projet, un projet de MMO fortement orienté jeu de rôle. Ça sera un jeu de niche donc, et disons MORpg plutôt que MMORpg.
Les technos
Après une maquette en C#, puis une maquette en python, un tripotage en C++, j'ai décidé de tout reprendre sur des techno web : à savoir Node.js pour le coté serveur et jQuery/Canvas coté client.
L'avantage de node.js c'est que l'orienté évènement sied tout à fait à un jeu de ce type, et l'avantage de faire un client graphique en ''HTML5'' c'est qu'il sera portable. (et puis c'est mon job dans la vie donc j'ai quelques bases). De plus je n'aurais pas à m'inquiéter pour tout ce qui concerne la couche réseau, ma hantise absolue.
Évidement les perfs coté client vont demander un effort d'optimisation, et comme je n'ai pas envie de me lancer tout de suite dans WebGL il sera en 2D (iso3d) mais c'est un choix que j'assume, et les progrès des dernières années sont prometteurs.
L'ambiance et le Background
L'ambiance sera du Far West fantasy, c'est à dire du sable collant à la sueur d'homme bourrus au milieux de leurs troupeaux de vaches, des duels au colt, des plaines à longueurs de vue. Le coté fantasy sera très 'doux', introduit petit à petit et absolument dispensable. J'y reviendrais ultérieurement.
Le Gameplay
C'est un jeu dont le gameplay sera au service du roleplay certes, mais il s'agit d'un jeu tout de même. Donc il y aura une progression des personnages, basé sur une série de skills ouvrant à la fois des capacités (un skill 'bucheron' pour exploiter le bois, un skill combat au colt etc etc). Roleplay oblige le plus gros du jeu sera crée et construit par les joueurs. Les bâtiments, les objets disponibles seront donc crée par les joueurs, à partir de schémas et de ressources.
Exemple : Couper un arbre le retirera du monde en fournissant du bois pour le craft, les forêts vivront et donc d'autres arbres pousseront ou seront plantés. (script asynchrone qui fait évoluer le monde). Les animaux se reproduiront (gros morceau de code)
Concernant les skills ce jeu ne sera pas comme la plupart des MMO en évolution uniquement, un skill qui ne sera pas utilisé perdra des points au fil du temps, donc un joueur pourra perdre des niveaux.
Le jeu sera libre niveau PVP, c'est important à mes yeux dans un jeu roleplay. Le roleplay sera aussi récompensé avec des skills 'uniques' Sherif, Gouverneur, chef de bande, propriétaire de mine....
Avancement
Le serveur est déjà pas mal avancé, une grande partie des algorithmes est déjà calculé, mesuré, et un sous ensemble de tout ceci est codé (c'est la troisième version après tout, je réutilise pas mal d'algo déjà rédigés)
Le client est un peu plus à la ramasse, déjà parce que je suis un bille en graphisme, donc je maquette avec un pack de sprite bidon qui ne rend pas très bien.Cependant le code pur et dur est bien avancé :
un petit screen d'une version alpha du moteur, alors ça ressemble pas à grand chose quand c'est pas animé
http://tof.canardpc.com/preview2/c4e0fd83-7e70-407a-8889-41ae1f757824.jpg (http://tof.canardpc.com/view/c4e0fd83-7e70-407a-8889-41ae1f757824.jpg)
C'est un vrai moteur isométrique, avec alternance pair/impair, gestion des niveaux de terrain (coordonnée z)
J'espère avoir une version pré-alpha testable d'ici peu, ça va dépendre du temps que j'ai à consacrer à ce projet (dur de bosser le soir quand on a passé la journée au boulot à faire le même genre de chose ;) )
Voil, c'était un post un peu fouillis mais je ne savais pas trop comment entrer en matière. Comme j'ai la flemme je ne tiendrais pas de DevBlog, mais j'alimenterais ce topic !
Repo GitHub
J'ai décidé de mettre tout mon code sur github, le code est un peu petit cochon mais il va grandement s'améliorer au fil du temps si je craque pas!
https://github.com/Acknackhoul/west
Merci à ceux qui lisent
Évidement les perfs coté client vont demander un effort d'optimisation, et comme je n'ai pas envie de me lancer tout de suite dans WebGL il sera en 2D (iso3d) mais c'est un choix que j'assume, et les progrès des dernières années sont prometteurs.
Remarque perso:
Il est vrai qu'avec HTML5, on peut faire pas mal de choses assez jolie :).
Mais par contre sans librairie graphique, le HTML5 n'est très très optimisé... voir pire qu'un jeu flash :o.
Je ne connais pas trop le fonctionnement de WebGL (et ses limitations), mais faire de la 2D avec OpenGL à partir de Sprites, ce n'est pas très compliqué je trouve (je peux copier/coller mon code "noob" pour montrer).
Je suis aussi sceptique concernant les performances "réseaux" des jeux web, quand ce n'est pas asynchrone :s.
Mais je reste très curieux :).
Bon courage!
Tiens, c'est marrant, c'est exactement ce qu'on est en train de faire en projet de fin d'année dans mon école (à savoir un "mmorpg" en 3diso en node.js). On est pas mal avancé là, pour la partie graphique on utilise kinetic.js, c'est pas mal du tout (j'ai personnellement codé tout le moteur graphique du jeu avec cette librairie), c'est du canvas et pas du webgl. Mais sinon, ça bouffe pas mal de ressource, mais ça passe bien (le jeu est en semi tour par tour).
Mais sinon, mis à part son âge, node.js, c'est pas mal du tout pour faire du temps réel, ça marche assez fort, par contre, je sais pas si c'est vraiment ça niveau sécurité...
node.js et socket.io passent en ssl. Donc niveau sécurité il n'y a pas de soucis.
Niveau perf il faut voir que le websocket (via socket.io) n'a rien à envier à un socket classique, d'ailleurs il s'agit d'un socket classique tcp, il est juste ouvert par les soins d'une lib en js ^^
socket.io a l'avantage de passer par un autre moyen si le navigateur ne gère pas les websocket !
node.js n'est pas si vieux, dans le sens où il est bien maintenue, la dernière stable date du 2013.05.24, il y a 4 jours ! \o/
Je ne connaissais pas kinetic.js, après quelques recherches hier soir si je dois choisir une lib graphique j'irais pluôt vers pixi.js, qui fait du webgl2d ^^ http://www.pixijs.com/. (ou alors tree.js ? )
WebGL n'est pas réellement limité, c'est un pont qui était bien crade (même si ça s'améliore) vers la CG, donc potentiellement on peut faire aussi bien qu'un jeu 'lourd' avec du WebGL. D'ailleurs en général un jeu en webGL commence par charger localement tout à un tas de ressources. Un exemple de la puissance de WebGL c'est ça : http://www.unrealengine.com/news/epic_games_releases_epic_citadel_on_the_web/ L'unreal engine 3 porté en js et webGL (alors ça marchait que sur une nightly build particulière de Firefox à la sortie du truc, mais c'est un bon exemple de ce qu'on va avoir dans peu de temps. Cependant j'ai déjà bossé sur de la 3D et je sais que ça prend du temps et surtout que les ressources graphiques à produires sont bien plus complexes !
Sans être indiscret tu fais quelle école War-p? A mon époque on développait des sytèmes de gestion de portefeuilles à l'école, pas des jeux ! :( C'est ton premier moteur graphique ?
Nb : Je pense ouvrir les sources de mon projet (config de gameplay mis à part évidement : formule de dégat, calcul d'XP... pour garder de l'intêret au jeu ^^ ) si ça interesse des gens, le serveur, vu que le client sera évidement ouvert. Pour l'instant j'avance doucement mais surement.
Pour l'âge de node.js, je me suis mal exprimé, je voulais parler du fait que c'était très récent, et qu'il y a peu d'exemple de prod réussis(le seul que je connaisse s'est fait hacker environs 10sd après avoir été mis online...). Sinon, je suis à Supinfo (ouais, bon on en pense ce qu'on veut). Sinon, pour le moteur graphique, non ce n'est pas mon premier, et oui, c'est le plus complexe que j'ai fait entièrement à la main (on doit gérer pas mal de choses, et c'est vite le bordel en js).
Sinon, pour l'unreal engine, ils ont compilé le moteur c++ vers du js avec l'aide de mozilla, je crois qu'ils ont fait la même avec le source engine.
Niveau perf il faut voir que le websocket (via socket.io) n'a rien à envier à un socket classique, d'ailleurs il s'agit d'un socket classique tcp, il est juste ouvert par les soins d'une lib en js ^^
Ok, ca reste à voir du coup.
J'avais déjà voulu faire un tout petit jeu (un morpion) entre plusieurs joueurs/navigateurs, échanges synchrones avec du js/ajax maison. Ca a beau être super léger comme projet, mais les échanges HTTP étaient bien trop gourmandes...
L'origine de cette mauvaise optimisation vient du protocole et de la vieille techno.
Il est possible que sous HTML5 (et avec ses bibliothèques js) ca soit beaucoup plus optimisé et plus simple à gérer :).
Tomaka17
28/05/2013, 12h13
Le problème de node.js et la raison pour laquelle il n'est pas beaucoup utilisé, c'est que c'est très jeune et potentiellement buggé, mais aussi que c'est monothread.
Si ton jeu demande un gros trafic et que t'as beaucoup de monde connecté, ça risque de chier à ce niveau-là.
Et si tu veux faire un truc sans lag il faudra de toute manière probablement utiliser les websockets plutôt que l'HTTP tout simple.
Concernant les graphismes, je sais pas si t'as envisagé les canvas, mais pour un truc un peu temps réel en 2D c'est ça la solution préconisée sur le web.
Oui, node.js est monothread
- mais il se clusterise très bien au travers de redis, ça permet d'utiliser les 31 autres cores du processeur :p (je l'ai déjà utilisé comme ça pour un projet à très fort débit, mais bon dans un premier temps si j'arrive à avoir 2 joueurs ça sera bien)
- de plus node.js peut héberger des scripts lancés dans un thread différent, pour un traitement DB lourd, ou un long calcul. (thread_a_gogo) Bien sur il s'agit de thread immutables, mais ça rend déjà pas mal de services (http://bjouhier.wordpress.com/2012/03/11/fibers-and-threads-in-node-js-what-for/)
- ... et surtout node.js se détache des paradigmes habituels de programmation, en codant asynchrone et pensant asynchrone on évite d'être coincé par le monothreading. \o/
Tout le service de ressource statique sera fait par nginx (je ne suis pas fou), l'évolution du monde (animaux / végétation) est réalisée par un module à part (js pour rester dans le même langage, mais au besoin j'ai déjà le code en C++ qui effectue tout ça à la vitesse de l'éclair, il s'agit de requête sql, puis de long parcours de tableau avec des permutations et des additions en général)
Node.js se retrouve donc juste à faire du network (socket.io) et gérer le gameplay léger, bidule se déplace en x,y,z. le trafic réseau est fortement contenue.
Et puis dans le pire cas de l'univers si rien ne marche, j'irais pleurer des larmes de sang et je referais tout en Go !
@louc : Oui il ne faut pas faire de temps réel en http :D ca n'est pas du tout fait pour ça.
@louc : Oui il ne faut pas faire de temps réel en http :D ca n'est pas du tout fait pour ça.
C'étais par pur expérience et moment de lumière :p. Mais j'ai arrêté de réver quand j'ai vu de nombreux kB être invoqués sur le réseau, pour rien :emo:.
Enfin bref, j'ai une question non-technique au sujet du jeu:
As-tu une solution concernant les groupes de joueurs qui peuvent avoir une envie frénétique anti-écologique de briser toutes ressources naturelles et de couper toutes les arbres de l'univers ? (une repousse automatique ? Un moyen côté joueur pour faire repousser manuellement les ressources ? etc).
Certains jeux comme EvE Online et Wakfu ont dû gérer ce genre de situation. Pour EvE c'étais simple: Reset de l'environnement toutes les 24h. Pour Wakfu, ils ont laissés faire, mais ca n'a pas donné quelque chose de jolie jolie à la fin.
Dans le gameplay actuel comme je l'ai pensé ça sera tout à fait possible de tenter de provoquer un désastre écologique, mais couper un arbre prend du temps pour commencer, il y aura évidement une repousse automatique d'arbres, et pour faire un désastre écologique, donc pouvoir ravager les forets il faudra être sacrement organisé, survivre à la faune et la flore, aux maladies, et à la faim.
Dans ma première maquette j'avais un système de faim qui continuait même quand le personnage est déconnecté (il fallait soit déconnecter dans un saloon, soit avoir assez de nourriture non périssable dans le sac pour survivre le temps nécessaire (autoconso de la nouriture) Alors c'est un peu hardcore, mais le jeu se veut hardcore.
Ensuite contrairement à Wakfu, un jeu roleplay est encadré par des animateurs humains qui peuvent très bien déclencher un événement pour montrer la contrariété de la nature face aux pollueurs (une petite épidémie, une sécheresse, une destruction des récoltes de tous les joueurs ou presque, bref des trucs de GM)
Il y a un an Mozilla a fait une maquette de ce que j’essaie d'atteindre. http://browserquest.mozilla.org, ils ont open sourcé le tout et ils utilisent des technos proches, mais ça me motive bien de voir que le proof of concept pourra fonctionner ! Websocket c'est le pied.
Sinon quelques nouvelles, j'avance très lentement, concentré sur le coeur du coeur de l'appli. Donc rien de visuel pour l'instant.
Faut que je balance tout ça sur GitHub ! Ce WE si j'ai la force avec moi.
Voilà j'ai tout balancé sur GitHub : https://github.com/Acknackhoul/west
Il n'y a pas beaucoup de code parce que je passe pas mal de temps à tester les technos dans des projets poubelles. (que je ne poste pas, ça n'a aucun intérêt pour vous de me voir tester des tuto et bidouilles des trucs tout cradoc, l'utilisation de redis, et des tests de libs pour trouver ce qui me ferait gagner du temps. )
Là je bosse sur la partie la plus facile, le système de chat :
A moyen terme ce système de chat pourra être déporté sur un autre serveur node.js, il possède un pipe de connexion avec le serveur afin que la chat permette de lancer des actions en jeu (des actions un peu moins synchrone que les actions principales de déplacement / combat / utilisation d’entités) et bien sur afin de pouvoir discuter aussi avec les pnj.
Le système de chat permettra l'ouverture libre de canaux de discussion par les joueurs, protégé par un mot de passe, et d'un lot de canaux système.
Je n'ai pas de serveur pour l'instant pour héberger mon projet, je n'ai que du mutualisé qui ne supporte évidement pas node.js, ça sera une des prochaines étapes avoir une maquette en ligne.
Bien à ceux qui suivraient ! Plus de nouvelles plus tard !
[Edit : J'ai mis à jour le premier post avec les infos github]
Quand tu parles d'un "autre serveur node.js", tu parles d'un autre Thread, non ?
@Luc : Une autre instance de node.js, sur le même serveur ou non.
Mais pour l'instant c'est dans le code principal avec ses coupains.
Ca avance, toujours aussi doucement, mais ça avance.
Je gère le Chat (multi channel), mais aussi les déplacements. J'ai un peu benchmarké node.js et socket io, c'est fluide comme tout !
Par contre pour le coté GraphicEngine je vais définitivement basculer sur du WebGL, ne serais-ce que pour avoir des shadders et des particules, sinon c'est vraiment trop limité et ça met à genoux les PC même les puissants.
Luc t'as fais de l'OpenGL tu m'as dit ? :p T'as pas du temps à perdre sur un super projet en WebGL ? :D
Je pusherais le tout sur GitHub !
Ahah j'ai déjà deux projets sous les bras (et j'ai un peu de mal à m'organiser avec x) ).
Peux être plus tard, mais là ce n'est pas trop possible ;).
Tomaka17
09/06/2013, 20h00
Je pense que si t'as jamais touché à OpenGL ou DirectX de ta vie, c'est une très mauvaise idée de vouloir te lancer comme ça sur le tas.
Cela dépend pour quoi je dirais.
Il est possible de faire des choses très simple avec OpenGL/DirectX, surtout si le projet peut se résumer à "afficher tel Sprite à tel emplacement, de tel proportion, sous tel couleur et alpha".
Pour de la 2D, c'est largement possible. Mais s'il faut faire appliquer des effets graphiques en plus (blur & co), c'est une autre histoire.
Je pense que si t'as jamais touché à OpenGL ou DirectX de ta vie, c'est une très mauvaise idée de vouloir te lancer comme ça sur le tas.
Ça ira, j'ai bossé sur le code du générateur de particules d'Ogre3D \o/ (ok c'était il y a presque 10 ans maintenant, mais bon je ne pense pas être encore sénile).
J'ai surtout bossé sur l'optimisation du client de T4C (et le portage directx6->directx9).
Pour le moteur graphique je vais au plus simple, je vais faire de la 2D, sprite + normal mapping pour la gestion de la lumière et l'ombrage. Des trucs que j'avais déjà fait. Écrire et appliquer un shader c'est pas le plus dur.
Mais, je sais que c'est pas non plus totalement évident surtout que WebGL a encore pas mal de limites. Et surtout ça va prendre du temps.
Tomaka17
09/06/2013, 21h33
Cela dépend pour quoi je dirais.
Il est possible de faire des choses très simple avec OpenGL/DirectX, surtout si le projet peut se résumer à "afficher tel Sprite à tel emplacement, de tel proportion, sous tel couleur et alpha".
Pour de la 2D, c'est largement possible. Mais s'il faut faire appliquer des effets graphiques en plus (blur & co), c'est une autre histoire.
Il me semble que le WebGL c'est de l'OpenGL ES, c'est à dire grosso-modo OpenGL 3.3 mais sans les vieilles fonctions du genre glBegin/glEnd/glVertex/etc.
C'est à dire que même pour afficher un pauvre triangle en 2D t'es obligé de passer par des shaders.
Non mais sinon t'as threejs, processing.js, et toutes les libs qui permettent de faire du webgl sans se pincer les doigts très fort.
Il me semble que le WebGL c'est de l'OpenGL ES, c'est à dire grosso-modo OpenGL 3.3 mais sans les vieilles fonctions du genre glBegin/glEnd/glVertex/etc.
C'est à dire que même pour afficher un pauvre triangle en 2D t'es obligé de passer par des shaders.
Je ne parlais pas forcement des glBegin/glEnd ;). J'ai vérifié, et il existe encore sous WebGL quelques vieilles méthodes pour afficher des triangles sans passer par les shaders (même si je suis d'accord que l'utilisation de ces derniers est recommandé).
Par contre oui, il vaut mieux utiliser une techno qu'on connait et qui est moins performant, qu'un gros truc puissant mais dont on n'a pas d'expériences.
Non mais sinon t'as threejs, processing.js, et toutes les libs qui permettent de faire du webgl sans se pincer les doigts très fort.
Oui, et je vais utiliser pixi.js, comme j'avais déjà exploré cette piste il y a quelques temps. J'ai testé un peu ce WE et c'est parfait pour mes besoins. C'est un render Engine qui sera facilement adaptable au code que j'ai déjà rédigé (moteur de tiles). Faire tout le WebGL à la main va juste me faire perdre du temps que je pourrais passer sur du code utile (j'entends par là du code qu'aucune lib déjà existante ne fait, donc le gameplay)
Pour ceux que ça intéresse :
Leur site et le lien GitHub : http://www.goodboydigital.com/pixi-js-is-out/
Leur forum : http://www.html5gamedevs.com/forum/15-pixijs/
Quelques nouvelles : je joue avec pixi.js : voilà une adaptation très sommaire de mon moteur de tiles avec un merveilleux rendu en webgl ! http://www.filedropper.com/wengine *
Et je suis content de sa souplesse! J'ai l'impression d'utiliser SDL ! J'aime.
Prochain jalon refaire une sorte de double buffering pour gérer le scroll infiniment et de manière totalement fluide !!
* Testé avec firefox (je dev toujours avec FF), décompressez quelque part et ouvrez index.html
Alors oui pour l'instant ça fait pas grand chose, mais ça devrait évoluer assez vite, j'ai mis la partie serveur de coté après avoir tout refactorisé afin d'avoir une structure plus efficace. J'avais une usine à gaz, mais maintenant c'est bien mieux !
(ps : oui j'ai pas git push, je le ferais !)
(pss : oui c'est du code petit-cochon, \o/)
Perso je vois un espece de patchwork verdatre sur fond noir avec un cowboy qui fait des loopings derrières et le tout qui va et vient, c'est normal ?
C'est bien ça :) Le rendu ne compte pas c'est le framerate qui compte !
C'est tout à fait inutile, mais demain je devrais avoir quelque chose de plus pratique. je met surtout ça pour ceux qui voudraient voire la gueule du code, le rendu est totalement bidon (et les sprites sont dégeux)
Par contre le patchwork verdâtre devrait changer régulièrement (et totalement aléatoirement) avec des tons bruns moches.
Et si t'as jamais bossé avec du javascript dis-toi que normalement faire ce genre de rendu pourrait mettre à genoux un core i5. Mais cette lib est magique !
Edit : Mon but maintenant c'est d'avoir un scroll sur les deux axes sans le moindre drop de framerate.
Ben sur les navigateurs de maintenant, le JS tient pas mal la route, donc je suis moyennement impressionné :)
Et puis au début j'étais à 60fps et puis au bout d'un moment (je ne sais pas si c'est juste une question de temps), c'est tombé à ~20fps.
Un certain temps de combien de temps ? T'as quel navigateur (et quelle version)
Après quelques heures de tripotage : http://www.filedropper.com/scroll
On peut changer le pas de rendu et la vitesse de défilement (sauf que j'ai pas mis d'interface pour ça), donc pour ce faire : dans la console (de firebug par exemple )
drawbg.MVSpeed = 10; // Vitesse (par défaut c'est à 1)
drawbg.Mvpas = 3; // Pas de rendu (par défaut c'est à 2)
Mais j'ai des soucis sur les perfs que j’essaie d'améliorer.
Ca ne ressemble toujours pas à grand chose, mais ça avance pas mal sur le fond !
J'ai aussi bossé un peu sur le coté serveur, niveau des intéractions entre les entitées (joueurs<->joueurs, joueurs<->monstres...)
Firefox 21 sur un Core 2 Duo. En fait ça tombe à 20fps quand je suis sur une autre page, et ça met un peu de temps à revenir quand je reviens, mais je suppose que c'est normal.
---------- Post added at 22h14 ---------- Previous post was at 22h12 ----------
Sinon les tiles c'est toi qui les as dessinées, ou bien récupérées quelque part ?
Non j'ai récupéré, ça permet d'avoir une base rapide pour dev, quand j'aurais un moteur efficace je penserais à en faire moi même !
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. Tous droits réservés