Discussion :

[smartties]

Présentation :

Boat craft, est un jeu multijoueur en vue de dessus sur Mobile, qui s'inspire de la vague des jeux .io.
Vous prenez le contrôle d'un bateau armé d'un canon que vous pourrez faire évoluer au long de la partie.



Objectif / Motivation :

Faire un jeu massivement multijoueur était une idée qui me tenais à cœurs depuis longtemps.
C'est donc un projet prototype pour approfondir mes compétences dans ce domaine et c'est également l'occasion de découvrir de nouvelles librairies/technos.
Mon objectif premier était de réaliser un jeu multijoueur stable, apprendre les concepts de la prédiction, réconciliation, load balancing. Mais également faire face au problème de lag, throttle, packet drop élevé...
Et ensuite, éventuellement essayer de faire quelque chose de sympa à jouer Mais je dois avouer que cette partie (améliorer le Gameplay) est assez compliquée et demandera de nombreuses itérations avant d'avoir d'obtenir un jeu marrant et équilibré ! C'est un projet que j’estimais faire en 2 semaines, et au final j'en ai consacré plus du double pour en arriver à cette premiere version de production.

Aspect technique :

J'utilise la librairie bas niveau Enet, dont l'un des points majeurs est de pouvoir bénéficier des avantages du protocole udp (rapidité), tout en garantissant la reception des donnés(reliability), en respectant l'ordre d'envoie/reception, le séquencement/rassemblement des packets, et ainsi que de nombreux autres avantages...
Je compresse/décompresse les packets avec Zlib (ce qui me donne ~30% de réduction de bande passantes).
Le client mobile iOS/Android utilise C++/Opengl ES 2.0 ainsi Firebase pour le coté analytique (mesurer l'acquisition, les cohortes démographiques, le temps d'utilisation du jeu, les crashs...).
Et pour ce qui est du back end, j'ai un masterServer et N gameServer, développés en C++ avec Enet et Sqlite3 (pour stocker les données persistantes comme les scores, noms...).
Pour la GUI j'utilise une "immediate mode gui" : Nuklear (dans le même genre que Imgui ).
L' "immediate mode gui" donne l'avantage de pouvoir réaliser des interfaces graphiques très rapidement, au coup de performances en comparaisons des "Retained mode"

Pour ce qui est de la location ma configuration est la suivante :
-Le masterServer : 1 Vps chez OVH
-Les gameServers : 2 serveurs dédiés chez Kimsufi localisés 1 en Canada et l'autre en France. Et 1 instance chez Amazon EC2

Le gameServer n'est pas coûteux en performances (en partie car il est actuellement configuré à 10 tick, soit 10 rafraîchissement par seconde, ce qui semble être suffisant pour un jeu mobile)
Je peux aisément héberger 10 gameServers (de 50 place chacun) par serveur dédié.

Prochaine mise à jour :
-Ajouter un tchat
-Régler un problème d'interpolation coté client (jitter)
-Ajouter plus de Canons/skins
-Équilibrer les armes et autres stats
-Prendre en compte le ping de l'utilisateur pour le Load balancing





Tous retours/questions/avis sur le jeu sont les bienvenus !

[Pat_AfterMoon]

Bonjour,

S'il s'agit d'un prototype, et bien c'est vraiment du prototype haut de gamme, bravo !

Merci pour ce "post" détaillé, notamment sur la partie technique, c'est vraiment intéressant. J'ai testé sur ma tablette Android et c'est très clean. J'ai un peu de mal à gérer la visée et le déplacement, mais, je suis un vieux, il me faut un WASD et une souris ou alors un jeu simple S'il y avait une possibilité de verrouiller le tir par rapport au bateau, ça pourrait peut être me convenir.
Petite remarque : dans l'écran de départ avec le pseudo, le champs est un peut bas, du coup le clavier virtuel Android le recouvre en grande partie (en mode paysage).

Moi qui ai l'habitude d'Unity3D je trouve intéressant de connaitre les détails techniques d'un projet comme celui-ci qui est fait avec des outils plutôt bas niveau "light" et sans dépendance.

Keep up the good work

[illight]

C'est rigolo, ça ressemble au projet de Vetea qu'il avait en tête non. C'était aussi une histoire de bateau il me semble

[MythOnirie]

Bonjour, le jeu est assez sympas à jouer sur mon téléphone.

Par contre, une fois qu'on s'est bien isolé dans un coin pour monter de niveau, les autres font rarement le poids...

[MoDDiB]

J'ai testé et c'est sympa, du très bon boulot.

On ne ressent vraiment pas le lag : le ping est de combien environ pour toi ?
Concrètement tous les calculs se font uniquement sur le serveur et c'est lui qui envoi l'information de destruction d'un boulet par exemple ?
Ou tu calcul aussi sur le client et il y a un système de résolution de conflit ?
Le serveur envoi toutes les infos à tout le monde ou uniquement pour les joueurs dans la zone d'intérêt ?

[smartties]

Salut, merci à tous pour vos retours !

J'ai un peu de mal à gérer la visée et le déplacement, mais, je suis un vieux, il me faut un WASD

C'est vrai que les contrôles ne sont pas évident, ce problème m'a déjà été rapporté plusieurs fois et je pense rajouter la possibilité de tirer directement en cliquant sur l'écran (sans passer par le joystick droit).

Petite remarque : dans l'écran de départ avec le pseudo, le champs est un peut bas, du coup le clavier virtuel Android le recouvre en grande partie (en mode paysage).

Normalement le champs se déplace automatiquement en haut de l'écran (comme sur cette image : https://i.imgur.com/1x43XGp.png ). À moins que le clavier virtuel recouvre tout l'écran ?

C'est rigolo, ça ressemble au projet de Vetea qu'il avait en tête non. C'était aussi une histoire de bateau il me semble

Ah c'est marrant je connaissais pas son projet Tu as une source ? Personnellement je me suis très fortement inspiré d'agar.io, tank.io diep.io

Par contre, une fois qu'on s'est bien isolé dans un coin pour monter de niveau, les autres font rarement le poids...

J'ai pu remarquer la même chose Afin d'équilibrer le jeu, il m'a été suggéré plusieurs idées, dont deux que j'ai trouvé intéressantes et réalisables :
- Des bots agressifs (ex : des requins) qui s'attaqueraient en priorité aux joueurs de haut niveaux
- Augmenter la taille du bateau et son champs de vision plus il évolue, mais en contrepartie réduire sa vitesse et agrandir sa hitbox, le rendant ainsi plus vulnérable.
Qu'en penses tu ?

On ne ressent vraiment pas le lag : le ping est de combien environ pour toi ?

De manière général depuis chez moi (Paris) j'obtiens un ping de ~60ms sur le server en France et ~190ms pour le server au Canada.
Ca fait plaisir, merci, j'ai beaucoup travaillé sur cette aspect (donné l'impression que le jeu est réactif).

Concrètement tous les calculs se font uniquement sur le serveur et c'est lui qui envoi l'information de destruction d'un boulet par exemple ?
Ou tu calcul aussi sur le client et il y a un système de résolution de conflit ?
Le serveur envoi toutes les infos à tout le monde ou uniquement pour les joueurs dans la zone d'intérêt ?

La simulation se fait coté server. Le client se contente d'envoyer les événements (angle des deux joysticks, l'intensité, et le type d'event : Nothing/Press/Down/Up), et recevoir les mise à jours.
Les données reliables, (que j'enregistre dans un dictionnaire coté client avec pour clé l'identifiant unique de chaque entités) :
- Le nombre de point de vie actuel + nombre de point de vie maximum. (2x uint16_t)
- Le nom (String < 18 octect)
- L'Experience / Experience Max / Level ( 2x uint16_t + uint8_t)
- Le type de bateau (le skin et le type de canon utilisé par celui ci)
- Lancement du projectile : temps server du lancement du projectile (int64_t) + position (2x float) + vitesse + (uint8_t) + angle(uint8_t) + type projectile (uint8_t)
- Destruction projectile : temps server de la destruction du projectile (int64_t).
et les données non reliables :
- Position (2x float)
- Angle du bateau (uint8_t : à l'envoie je mets l'angle dans 1 octect (angle/255), me donnant une précision de ~1.4 degré, ce qui est suffisant)
- Angle du canon (uint8_t)

Coté client je synchronise le temps du server lors du login avec un échange de 10 packets aller et retour, sur une période de 5 secondes pour mesurer le Round trip time moyen (une sorte de ping) et ajuste le temps Server coté client au fur et à mesure. J'ai pu constater que la précision entre tempServer Client et tempServer Server donnait une incertitude ~70ms . Malheureusement synchroniser un timer entre deux machines est un procédé assez imprécis.


Je m'assure également de ne jamais envoyer deux fois la même information à un client. Pour envoyer l'information qu'une seule fois, j'utilise un système de "subscriber", dont le principe est le suivant :
J'ai une classe EntiteVersion qui contient : une position (vect2D) et sa version positionVersion(uint32_t). À chaque fois que mon vecteur position est modifié, positionVersion est incrémenté de 1. (Il en va de même pour, les autres attributs : nom(String) nomVersion(uint32_t), angleBateau (uint8_t) angleBateauVersion (uint32_t)...)
Chaque Entités contient son instance d'EntiteVersion qu'elle met à jour à chaque interaction (changement de position, type, angle, vie...).
Chaque Entités contient également une liste d'EntiteVersion des entités dans un rayon de X. (En fait ce n'est pas une list, mais une unordered_map avec pour clé l'identifiant de l'Entité et contenue EntiteVersion)

Pour savoir si j'ai besoin d'envoyer une mise à jour à une Entité[42] ( où 42 est la clé identifiant le joueur Bob par exemple), il me suffit de parcourir toutes les Entités dans un rayon de X à l'Entité[42] (Bob), et de comparer leurs EntiteVersion avec celles présentes dans la liste de Entité[42]. Voici les cas résultants possible :

• Si Entité[28] se trouve dans le rayon de Entité[42], et que Entité[28].EntiteVersion n'est pas présent dans la liste de Entité[42].liste, alors j'ajoute une copie de Entité[28].EntiteVersion vers Entité[42].liste[28] et j'assigne une demande de mise à jour de l'Entité[28] dans la queue à l'intention de Entité[42].

• Si Entité[28] se trouve dans le rayon de Entité[42], et que Entité[28].EntiteVersion.positionVersion != Entité[42].liste[28].positionVersion, alors je mets à jour Entité[42].liste[28].positionVersion, et j'assigne une demande de mise à jour de la position de l'Entité[28] dans la queue à l'intention de Entité[42]. (cela s'applique pour la position, mais également les autres attributs : nom, angle...)
• Sinon pas de mise à jour

En bref, pour chaque client je determine ce que je dois lui envoyer en fonction d'une liste d'autres entités qui lui sont proches et de leurs versions. (je n'ai pas expliqué la solution au complet car cela prendrait trop de place, mais l'essentiel du principe est là)

Cette solution est assez coûteuse (parcourir toutes les entités, mettre à jour les listes, etc...), c'est pourquoi j'ai implémenté le spatialHashing (dont je me sert aussi pour gérer la physique) qui a drastiquement réduit la complexité de recherche et me donne des performances qui me conviennent ( Pour 1000 entités en constant mouvement, et pour chacune des ces 1000 entités : en appliquant l'algorithme précédent de recherche de mise à jour + sérialisation des données, j'ai un résultat fluides avec un server configurer à 15 ticks par seconde).

Au passage il y a un gros bug d'interpolation, qui provoque un effet visuel de saccade sur les mouvement des bateaux (jitter) lorsque la connexion du client est mauvaise. Malheureusement je l'ai constaté après être partie...
Je sais d'où vient le problème et comment le régler, mais cela devra attendre que je rentre

Merci encore pour ces avis constructifs ! En rentrant de vacances dans une semaine j'essayerai de les implémenter