Discussion :

[Invité]

Bonjour bonjour,

J'ai décidé de vous présenter mon projet en cours, et qui devrait m'occuper longtemps (en espérant que le présenter me motive un peu à faire avancer la bête... ).
A savoir; c'est un projet que je réalise en loose, quand je n'ai rien d'autre à faire. L'avancement est donc chaotique et il ne sortira pas demain.

Bref, je vous présente donc Liminary.

C'est quoi ce mot !?
"Liminary" c'est un terme anglais vieilli qui désigne l'action de préparer quelquechose.
On peut dire que ça se rapproche un peu du mot français (aussi peu utilisé...) "Liminaire" qui désigne "l'action en elle-même".
Bref, un nom tout à fait à propos pour un outil qui se veut un facilitateur de projet.

Qu'est ce que Liminary:

Liminary est un outil tout en un de développement de jeux multijoueurs, orienté RPG (pour l'instant).
Il se veut à la fois robuste, facile à modifier pour un développeur accompli et facile à prendre en main pour un débutant.

Liminary se compose de 3 pans:
- une interface de création de jeu où l'utilisateur va pouvoir construire son projet (réaliser ses cartes, ses règles de combat, ses quetes, ses animations, sa GUI)
- un client graphique en 3d qui sera à fournir aux joueurs
- un système de serveurs de jeu

Le système de serveurs de jeu peut être décorellé du client graphique. En effet, il propose de communiquer en Binaire, XML et JSON. Il peut aussi fonctionner en mode TCP ou UDP.

Je travaille actuellement sur ce système de serveurs (les autres projets ne sont pas encore lancés).

Quelles sont les technologies utilisées pour Liminary?

Le système de serveurs de jeu est codé en Java; pour des questions de portabilité entre plateforme.
J'utilise Grizzly qui est une surcouche de Java NIO pour la gestion des entrées sorties.Et également Jackson pour la sérialisation/désérialisation JSON. Log4J pour la gestion des traces du système.

Mysql est utilisé pour la base de données.

Des tests automatisés sont écrit au fur et à mesure de l'avancée et tout est compilé avec Maven (en surcouche de Ant).
Il y aura certainement d'autres bibliothèques plus tard en fonction des besoins qui se présenteront.


Une première mouture du client se basera certainement sur les restes d'un précédent projet de RPG (Pentacles Mayhem) dont je retirerais tout ce qui n'avait pas été codé par moi/ n'est pas utilisable pour un client seul / et ajouterais ce qui manquait.
Il sera donc codé en C# et utilisera le moteur Truevision 3D 6.5 et FMOD pour le son. La librairie réseau reste à déterminer.
Ceci changera certainement dans un 2e temps (car Java d'un côté et C# de l'autre ce n'est pas des plus cohérents); mais l'objectif sera de pouvoir avoir un rendu exploitable dans des temps raisonnables et de conserver ce qui marchait.

Le studio de création en lui-même reste sur des technologies à définir (surtout en raison du choix de moteur 3D qui sera déterminant pour la finalisation du projet)
Il sera certainement également développé en Java.

Vue détaillée du fonctionnement du système de serveur

Le système de serveurs se présente comme suit :

Un Master Server qui gère toute les entrées dans le système, le changement d'unité logique (par exemple un changement de canal), la communication inter-serveurs, répertorie les entités actives (joueurs et serveurs) et gère la création des nouveaux personnages.

Un Data Server qui gère l'accès à base de données, les sauvegardes et récupérations d'informations; et fourni aux autres entités du système les informations dont elles ont besoin pour travailler.

Un ou plusieurs Map Server qui vont gérer les cartes du jeu, toute la logique de combat, les quetes etc.


Où est ce que j'en suis?

Mon travail actuel se concentre sur le point d'entrée du système (aka le Master Server).

J'ai commencé à coder une librairie utilitaire qui gère déjà la récupération des paramétrages, la sérialisation/désérialisation des flux et l'accès à la BDD.

Côté serveur pur, j'avais commencé à coder en NIO pur la création des sockets d'écoute, au final je suis en train de retravailler le tout avec Grizzly pour que ce soit plus simple.

J'ai commencé aussi des parties du Data Server, mais le résultat ne me semble pas si probant, il y aura donc certainement une réécriture.

Quand au client C#, je n'ai pas encore commencé la modification. Mais à l'époque il était capable de gérer les maps (propriétaire, arg!), le placement des bâtiments, les animations et déplacement des créatures et du personnage joueur, les cycles jours/nuit et l'environnement. Je pense que ces points évolueront peu (uniquement gestion de la commande à distance). Il faudra que je réécrive la gestion des ambiances sonores (réalisée par un autre dev) et que je retouche la gestion de la GUI.
Le plus gros morceau sera donc la communication client serveur!

La roadmap :

Je vais me concentrer surtout sur le Master Server dans les mois qui viennent.

Nomenclature des échanges interserver et avec les clients
Gestion des connexions clients et autres serveurs
Listing des autres serveurs actifs (pour permettre le routage)
Gestion de la création de comptes clients et de personnages
Gestion de l'authentification, du mode sans compte
Gestion des droits spéciaux (pour les comptes admins)
Sécurité du Master Server

Pour la suite, on verra quand j'en serais là!

[tristan_m]

Bonjour,

L'objectif de faciliter un projet grâce à la mise à disposition d'une solution fonctionnelle et modifiable est très clair dans votre présentation.
Par contre, je vois également "outil de développement". Donc par pure curiosité, avez-vous prévu des fonctionnalités d'aide au développement?
Ex :

• debugging : breakpoint, step-by-step des scripts utilisateurs côté serveur
• monitoring : bande passante, temps de réponse, cpu, ram
• test : bots éventuellement paramétrables voire programmables, simulation de latence ou de charge

Ce serait évidemment beaucoup de travail sur un projet qui se veut déjà ambitieux,
mais ces fonctionnalités seraient majeures pour mettre en avant la qualité de cet outil,
et vraisemblablement utiles lors du développement de Liminary lui-même.

Ensuite, concernant la méthodologie, je vois quasi-exclusivement la partie Master Server dans la partie effectuée ainsi que dans la roadmap.
J'imagine que c'est l'élément crucial de Liminary, mais je pense qu'il faut rapidement attaquer les autres parties.

• Pour la motivation déjà :
  C'est toujours plaisant de voir une fonctionnalité marcher de bout en bout,
  plutôt que de simplement constater des rapports de tests unitaires dans un coin du projet.
• Pour dérisquer plus rapidement :
  Faire une partie complète dans un premier temps c'est prendre le risque d'avoir oublié/négligé quelque chose de l'autre côté
  et donc de devoir tout refaire ou placer des rustines peu satisfaisantes pour que l'ensemble fonctionne.
• Pour avoir quelque chose à montrer :
  La motivation vient aussi dans le fait de pouvoir présenter ses avancées et dans les retours de la communauté.
  Une démo, une vidéo ou même une capture d'écran montrant 10 personnages gérés par le serveur est plus motivant
  qu'un changelog indiquant que le serveur est capable de gérer 200 personnages mais que la partie client n'est pas implémentée.
  Et idéalement ces présentations permettent d'obtenir des retours constructifs !

Enfin, je reviens sur cette phrase :

car Java d'un côté et C# de l'autre ce n'est pas des plus cohérents

Tout dépend de votre objectif.
L'avantage d'utiliser le même langage des deux côtés est que les parties communes client/serveur du protocole ne sont à implémenter qu'une seule fois et sont débuggables des deux côtés.
L'avantage d'utiliser deux langages différents, c'est de s'assurer que le protocole est indépendant d'un framework ou autre lié à l'un des deux langages.
La question est donc : Est-ce que vous proposerez la possibilité de brancher "n'importe quel" client en face du serveur?

Bon courage pour la suite !

[Neckara]

Bonjour,

Niveau serveur, si tu veux vraiment être portable, je te conseillerais plutôt un langage compilé comme le C++ ou le C.
En effet, je ne suis pas certain qu'installer une JVM soit vraiment super sur une raspberry pi. Mais je peux me tromper.


Pour le client, je trouve dommage d'utiliser C# pour nos amis Linuxiens (même si on peux essayer de bidouiller avec Mono).
Quitte à faire, je préférerais du Java, mais d'autres langages sont aussi possibles.


Après, c'est très dommage d'utiliser des langages différents entre le client et le serveur car tu devras transcoder (?) certaines classes.


Enfin, d'expérience, je ne peux que te déconseiller de commencer par le serveur. Je pense que le mieux est de se concentrer sur le client quitte à avoir un serveur simulé via telnet. C'est beaucoup plus encourageant et valorisant surtout quand on avance pas vite.
Regarde mon moteur, plusieurs mois à bosser sur le système de module, personne n'y comprend rien, pas trop d'échanges. Je fait une simple fenêtre avec un shader, une simple image, ça parle à tout le monde. Au début, c'est certes pas très important, mais on se rend bien compte que sans un soutient moral, c'est difficile d'avancer.

[NevilClavain]

On voudrait en voir plus. Un lien vers un site ? des screenshots ?

[Neckara]

Re-bonjour,

Je ne prétend pas tout savoir sur tout et je suis bien conscient que j'ignore encore beaucoup de choses et qu'il peut m'arriver de dire des bêtises.
Il est aussi normal d'avoir des avis qui divergent sur certains sujets.

Le fait de me moinssoyer montre qu'il y a une personne en désaccord avec moi et c'est bien, il vaut mieux cela que de croire qu'on fait unanimité.
Mais j'aimerais tout de même vous demander une petite faveur.

Serait-il possible de me corriger ? Outre le fait que cela me permettra d'en apprendre plus et de m'améliorer, j'attire votre attention sur le fait que ce sujet est avant tout là pour aider akd. Me corriger permettra alors de l'aider, de le conseiller en lui fournissant d'autres arguments et en lui indiquant ce qui était faux dans mes dire (j'ose croire que je ne raconte tout de même pas que des bêtises ^^).

Je pense que ce serait gentil d'avoir une petite réponse.

Akd, n'écoute pas Neckara, il ne dit que des bêtises.

En effet, je te déconseille le C, C++ restent des langages difficiles à maîtriser. Pour tes besoins et ton niveau, l'assembleur serait bien plus approprié.

Akd, n'écoute pas Neckara, il ne dit que des bêtises.

Peu importe le langage que tu utilises, le tout est que tu utilises un langage avec lequel tu es à l'aise et surtout que tu te fasses plaisir.

[Invité]

Bonjour et déjà merci pour les premiers retours.

Je vais tâcher de répondre dans l'ordre :

L'objectif de faciliter un projet grâce à la mise à disposition d'une solution fonctionnelle et modifiable est très clair dans votre présentation.
Par contre, je vois également "outil de développement". Donc par pure curiosité, avez-vous prévu des fonctionnalités d'aide au développement?
Ex :

• debugging : breakpoint, step-by-step des scripts utilisateurs côté serveur
• monitoring : bande passante, temps de réponse, cpu, ram
• test : bots éventuellement paramétrables voire programmables, simulation de latence ou de charge

Je n'avais absolument pas envisagé cet aspect! O_o
(En fait, justement, je poste ce sujet parce que j'imagine bien qu'il y a pleins de choses auxquelles je n'ai pas pensé, en voilà la preuve).
J'avais éventuellement prévu de faire du monitoring plus tard en tant qu'outil d'aide à l'exploitation; mais pas du tout de debug ou ce genre de chose.
Donc je note, car ça m'a l'air bien intéressant tout ça!

Ensuite, concernant la méthodologie, je vois quasi-exclusivement la partie Master Server dans la partie effectuée ainsi que dans la roadmap.
J'imagine que c'est l'élément crucial de Liminary, mais je pense qu'il faut rapidement attaquer les autres parties.

Je pense aussi que rapidement je vais me retrouver travailler tout azimuth sur les composants du système (peut être pas la partie studio de développement mais au moins le client serveur avec des jolis rendus graphiques).

J'ai préféré pour l'instant partir sur l'obscur noeud technique qu'est le Master server car c'est un peu la colonne vertébrale du système (et également parce que comme je travaille une fois de temps en temps sur le bébé, j'oublie une fois sur deux où j'en étais... donc si je pars dans tout les sens, je suis fichue!)
Mais je sais déjà que pour le tester il me faudra à minima un bout de client et un bout du dataServer. Parce que même là, des logs d'exécution sur fond noir, pour faire des rapports d'avancement ça va être sacrément austère!

La question est donc : Est-ce que vous proposerez la possibilité de brancher "n'importe quel" client en face du serveur?

Tout à fait! Je suis partie du principe qu'au final, le développeur ne voudra peut être pas être limité à mon client tout pourri!
D'où (et c'est d'ailleurs une des seules briques qui marche pour l'instant!) la possibilité de générer des flux binaires, xml et json.
(et également la communication en TCP et UDP; mais là dessus, il faut que je vérifie les impacts de l'utilisation de grizzly; parce que j'avais précablé avec NIO, là je sais pas ce que ça va donner).

Bonjour,

Niveau serveur, si tu veux vraiment être portable, je te conseillerais plutôt un langage compilé comme le C++ ou le C.
En effet, je ne suis pas certain qu'installer une JVM soit vraiment super sur une raspberry pi. Mais je peux me tromper.

Je voulais pouvoir faire abstraction de la couche matérielle, d'où mon choix de Java.
Il y a aussi le fait que j'ai pas mal perdu la main dans les autres langages (alors que celui là même si c'est pas mon préféré, j'en fait tous les jours à mon travail). Donc vu que c'est déjà un projet tordu, j'ai voulu me simplifier la vie.
Après, je vois mal qui va utiliser un raspberry pour faire tourner un serveur (mais pareil, je suis peut être hors sujet).

Pour le client, je trouve dommage d'utiliser C# pour nos amis Linuxiens (même si on peux essayer de bidouiller avec Mono).
Quitte à faire, je préférerais du Java, mais d'autres langages sont aussi possibles.

Là c'est juste pour gagner du temps parce que la gestion de la création de l'environnement sur mon projet en C# était déjà bien avancé (donc pour avoir du visuel, c'est top).
Après je l'ai dit, je suis consciente que plus tard il faudra que je change l'orientation (déjà parce que Truevision 3D sent le sapin )

Après, c'est très dommage d'utiliser des langages différents entre le client et le serveur car tu devras transcoder (?) certaines classes.

Ca me fait faire aussi travailler le serveur dans un environnement hétérogène. Avec mon objectif qu'il puisse être utilisé seul, c'est aussi un bon point de départ (surtout pour le mode binaire où j'ai quelques craintes...)

Enfin, d'expérience, je ne peux que te déconseiller de commencer par le serveur. Je pense que le mieux est de se concentrer sur le client quitte à avoir un serveur simulé via telnet.

C'est dans ce sens que j'avais prévu de travailler quand PM était un meuporg... résultat il a fini en rpg tout court xD... donc cette fois-ci je veux travailler les intéractions client serveur, ca fait partie de mes faiblesses sur ce projet.

On voudrait en voir plus. Un lien vers un site ? des screenshots ?

Pas de site pour le moment (ça ne sera pas le plus long à mettre en place, de ce côté là je maitrise!!).
Je travaillerais le site quand j'aurais au moins une pré-alpha digne de ce nom.

J'avais prévu que ce topic me serve de mini dev-blog quand j'avais des choses intéressantes à présenter.

Pour les screenshots, les rapports de tests c'est tristounet donc j'éviterais de faire des screenshots de mon log Eclipse...
(bon ok! j'ai compris, faut que je me bouge pour avoir du graphisme!!)

Akd, n'écoute pas Neckara, il ne dit que des bêtises.

Je ne pense pas, l'objectif de la présentation de mon projet, que je sais peu avancé; c'est aussi pour être critiqué et recevoir des conseils.

Et puis c'est bien quand on est tout seul de pouvoir s'appuyer sur la communauté pour faire évoluer mon opinion (si vous m'aviez dit il y a 5 ans que je coderais un serveur en Java un jour de ma propre volonté...)

(j'ai l'habitude des critiques, tant qu'elles sont constructives, je prends tout!)