Discussion :

[youtpout978]

Bonjour,
j'ai commencé à bosser sur un rpg géolocalisé qui consistera essentiellement en du monster bashing, je voudrais en faire un jeu online et donc par exemple permettre la création d'équipe pour tuer des mob en coop et rendre ça persistant comme tout MMORPG.

Le concept est proche de celui là https://playorna.com/ sauf que je le fais en 3D.

Par contre je n'y connais rien dans le domaine de serveurs pour ce style de jeu, je sais moi même développer des webservices classique mais les problématiques ne sont pas les mêmes, j'ai fait quelques recherche et voilà où ça m'a amené :
Privilégié les WebSockets pour la communication.
Le serveur gère toutes les opérations pour éviter la triche (c'était évidant)

Par contre pour le stockage je me pose la question doit-on utiliser une bdd classique ou c'est à proscrire et il faut se tourner à tout prix vers du NOSQL ? (J'ai vu qu'il y a une version de Firebase juste pour ça)

Pour les serveurs existe-il des outils déjà tout prêt permettant la gestion de MMO, j'ai vu qu'il y a SmartFoxServer, Photon ...
Mais je vois pas ce qu'ils font exactement et les possibilités, le but quand même ça serait de pouvoir développer ses propres api ou méthodes et les intégrer dessus, quelqu'un a déjà utilisé ce genre de serveur et pourrait me conseiller ?
Sachant que j'aimerai pouvoir dev en C# si possible (JS est une possibilité, au pire JAVA après le reste des langages je ne connais pas assez ...).

Ou sinon faut-il créer son propre serveur? quel architecture choisir ? Comment se passe l'authentification ? où l'héberger (cloud ou dédié) ?

Si des gens s'y connaissent qu'ils se signalent j'ai plein de question ...

Actuellement pour mes tests je développe une API Rest (pour l'instant sans persistance).

[yildiz-online]

Privilégié les WebSockets pour la communication.

Effectivement c'est un bon support

Le serveur gère toutes les opérations pour éviter la triche (c'était évidant)

Oui, absolument tous les calculs doivent être fait sur le serveur, mais ça ne t'empêche pas de les faire sur les client aussi, pour plus de réactivité, et ensuite corriger le résultat si besoin.

Par contre pour le stockage je me pose la question doit-on utiliser une bdd classique ou c'est à proscrire et il faut se tourner à tout prix vers du NOSQL ? (J'ai vu qu'il y a une version de Firebase juste pour ça)

un serveur sql fera très bien l'affaire.

Ou sinon faut-il créer son propre serveur? quel architecture choisir ? Comment se passe l'authentification ? où l'héberger (cloud ou dédié) ?

C'est une possibilité, c'est ce que j'ai fait, l'architecture dépendra du jeu en lui même, un rpg tour par tour n'a pas les mêmes contraintes qu'un real time par exemple.
L'authentification se fait idealement sur une app distincte, elle a aussi ses propres contraintes (se protéger des comiques qui tentent les mots de passe en brute force par exemple...)

Actuellement pour mes tests je développe une API Rest (pour l'instant sans persistance).

du REST, ça risque d'être verbeux, mieux vaut un protocole plus léger et solide en général.

[youtpout978]

Oki merci.

Dans l'idée je partirai sur du websocket (la diff de perf avec les sockets classique est-elle importante ?)
Pour la connexion un serveur avec identity server permettant soit de crée un compte classique soit de passer par fb/google, j'aurai juste à transmettre le token.
Après pour l'appli server en elle même surement du microservice permettant d'isoler les fonctionnalités et chacun sa base de donnée et je sauvegarde toutes les interactions (event driven design avec rabbitmq ?) afin de prévenir la triche.
Ce n'est pas des design que j'ai déjà mis en oeuvre, j'essaye de me renseigner pour savoir comment les mettre en oeuvre, docker semble un outil indispensable.

Comme je l'ai dis pour le moment j'ai une simple api rest et des fonctionnalités pour me gérer mes zones et mes monstres par zone mais rien de persistant, tout est en mémoire résultat des bon temps de réponse le premier appel met 400ms mais les suivants 50ms, bon je test seul mais c'est déjà bon signe.

[yildiz-online]

Oki merci.

Dans l'idée je partirai sur du websocket (la diff de perf avec les sockets classique est-elle importante ?)

Il y a un overhead lors de l'upgrade http -> socket, sinon c'est kif kif

Pour la connexion un serveur avec identity server permettant soit de crée un compte classique soit de passer par fb/google, j'aurai juste à transmettre le token.

C'est une bonne approche.

Après pour l'appli server en elle même surement du microservice permettant d'isoler les fonctionnalités et chacun sa base de donnée et je sauvegarde toutes les interactions (event driven design avec rabbitmq ?) afin de prévenir la triche.
Ce n'est pas des design que j'ai déjà mis en oeuvre, j'essaye de me renseigner pour savoir comment les mettre en oeuvre, docker semble un outil indispensable.

Pas fan du microservice, ça veut dire un gateway qui va rediriger, donc un hop de plus, pour un jeu temps réél ça peut devenir compliqué.
J'utilise aussi une archi event driven, c'est bien adapté pour les jeux.

Comme je l'ai dis pour le moment j'ai une simple api rest et des fonctionnalités pour me gérer mes zones et mes monstres par zone mais rien de persistant, tout est en mémoire résultat des bon temps de réponse le premier appel met 400ms mais les suivants 50ms, bon je test seul mais c'est déjà bon signe.

Le premier c'est sans doute l'upgrade websocket.

[youtpout978]

Oui met l'overhead implique-t-il une grande différence? j'ai trouvé aucun benchmark comparant socket et websocket.

Comment tu as mis en place ton archi, tu utilises quel techno ?

Pour les microservices si tu héberges tout chez le meme provider ça devrais aller, surtout que les opérateurs cloud propose souvent leur propre solution pour ca style servicefabric que j'ai utilisé chez azure, mais qui contraint à leur techno mais j'ai cru comprendre que certains supportait RabbitMQ.

Donc tu préconise un seul gros projet avec toute la logique de gestion du jeu dedans ?

[yildiz-online]

Oui met l'overhead implique-t-il une grande différence? j'ai trouvé aucun benchmark comparant socket et websocket.

Pour l'overhead, c'est juste à la connexion, typiquement lors du loading screen par exemple, donc ce sera invisible.

Comment tu as mis en place ton archi, tu utilises quel techno ?

Mon moteur est basé sur netty pour le réseau, pour la persistence, jooq et puis peu importe le rdbms mais c'est postgres dans le jeu.
Tu peux jeter un oeil sur https://github.com/yildiz-online/engine-server (c'est tout petit vu que c'est modulaire, les librairies sont dans les modules adhoc que tu trouveras dans le pom.xml(et les implémentation chargées au runtime), et la logique de jeu, elle n'est pas open source).

L'architecture structurelle est modulaire, avec un découplage entre les composants.
L'architecture fonctionnelle est réactive(pas event driven au sens propre, mais plutot sur le pattern observer)

le scaling horizontal n'est pas encore géré, j'ai l'archi en tête, mais pas encore implémenté vu que pas besoin pour l'instant.

Donc tu préconise un seul gros projet avec toute la logique de gestion du jeu dedans ?

Non, moi j'ai plusieurs projets, divisés en features, qui sont des librairies, lors de la construction du binaire final, tout est assemblé en un seul gros artefact dans une unique image docker(toute la chaine de build est automatisée, c'est transparent).
C'est ce que je trouve de plus efficace quand il faut à la fois développer et s'occuper de l'opérationnel, et ce, à coté de la famille et du boulot(et les autres projets).