Combien de joueurs peuvent rejoindre une même partie ?
La limite du nombre de joueurs pouvant se joindre à une partie sera probablement la bande passante de téléchargement de l'hôte. Le moteur lui-même n'impose aucune limite, mais il y a une limite pratique définie qui sera rencontrée.
Le problème est que l'hôte doit envoyer un message contenant des données pour N joueurs, à chacun des N joueurs. Par exemple, si l'hôte doit envoyer 16 octets de données pour chaque joueur, alors chaque message aura une taille d'environ N * 16, et ce message devra être envoyé N fois. Cela crée un besoin en bande passante de N-carré. Par exemple
10 joueurs = 16 x 10 x 10 = 1600 octets par mise à jour
20 joueurs = 16 x 20 x 20 = 6400 octets par mise à jour
30 joueurs = 16 x 30 x 30 = 14400 octets par mise à jour
...
100 joueurs = 16 x 100 x 100 = 160000 octets par mise à jour
Même si le nombre de joueurs augmente de façon linéaire, la bande passante nécessaire augmente proportionnellement au carré. Cela signifie que même avec un serveur beaucoup plus puissant ou moins de données nécessaires par joueur, vous n'obtiendrez pas beaucoup de joueurs supplémentaires.
Par défaut, les mises à jour sont envoyées 30 fois par seconde, donc le dernier exemple avec 100 joueurs nécessiterait en fait un taux de téléchargement d'environ 5 mégaoctets/sec (ou 40 mégaoctets/sec). Ce taux est assez élevé pour une connexion domestique, mais pas nécessairement pour un serveur dédié.
En plus de cela, l'hôte doit être capable de faire tourner le jeu pour un grand nombre de joueurs, en effectuant des tâches telles que les tests de collision avec compensation du temps de latence, qui peuvent être gourmands en ressources CPU. Enfin, il peut être nécessaire d'effectuer le rendu du jeu pour l'hôte s'il est également un participant. En général, la quantité globale de travail augmente rapidement avec le nombre de joueurs, et bien que cela dépende du jeu et de la connexion spécifiques, il est rare d'avoir près de 100 joueurs dans une partie.
Contrôler les formats de mise à jour
Il est possible de choisir le format de données exact des valeurs transmises par le moteur multijoueur. Utilisé correctement, cela peut réduire considérablement la quantité de bande passante nécessaire sans avoir d'effet significatif sur la précision du jeu. Cela permet au jeu d'utiliser plus efficacement le réseau, tout en augmentant probablement le nombre maximal de joueurs pouvant se joindre au jeu.
Si vous n'êtes pas familier avec les bits, les octets et le binaire, vous en avez déjà beaucoup entendu parler ailleurs. Vous pouvez commencer par consulter les articles suivants de Wikipedia sur les nombres binaires et les octets. En résumé, tous les nombres en informatique sont stockés en binaire : chaque chiffre ne peut être qu'un 0 ou un 1. Un octet est constitué de 8 bits et peut donc stocker 2^8 (256) valeurs différentes, soit de 0 à 255. Un plus grand nombre d'octets permet de stocker une plus grande gamme de valeurs. Les types à virgule flottante peuvent également stocker des valeurs fractionnaires, telles que 0,3, et nécessitent généralement au moins quatre octets.
Les types que vous pouvez utiliser dans Construct 2 sont les suivants :
Haut (double, 8 octets) : un nombre à virgule flottante à double précision qui peut stocker des nombres sans affecter leur précision. Il possède environ 15 à 17 chiffres significatifs de précision. Cependant, il faut 8 octets pour stocker un seul nombre, ce qui peut finir par augmenter considérablement les besoins en bande passante. En pratique, il est peu probable que ce choix soit nécessaire.
Normal (float, 4 octets) : un nombre à virgule flottante à précision unique qui peut stocker des nombres fractionnaires avec une précision d'environ 6 à 9 chiffres significatifs. Cela signifie que certains nombres seront arrondis à un nombre inférieur de chiffres significatifs. Cependant, il est généralement beaucoup plus pratique qu'un double, car il ne prend que la moitié du nombre d'octets et les chiffres au-delà des 6 premiers ne sont généralement pas importants (par exemple, 0,333333 est suffisamment proche de 0,3333333333333 pour des raisons pratiques).
Faible (int16, 2 octets) : un entier signé de 16 bits qui ne peut stocker que des nombres entiers compris entre -32768 et 32767.
Très faible (uint8, 1 octet) : un nombre entier non signé de 8 bits qui ne peut stocker que des nombres entiers compris entre 0 et 255.
Pour minimiser la bande passante, il est important de choisir la précision la plus faible possible qui n'affectera pas sérieusement la jouabilité. Par exemple, les positions X et Y peuvent souvent utiliser une faible précision (int16). Tant que la disposition est inférieure à 32767x32767 (ce qui est très grand), et que les positions sous-pixel ne sont pas importantes pour la jouabilité (puisque cela arrondira toute valeur fractionnelle), c'est parfaitement suffisant et utilise quatre fois moins de bande passante qu'un double.
Les précisions faibles (int16) et très faibles (uint8) sont utiles avec les entrées des joueurs pour que les pairs les envoient à l'hôte. En utilisant les expressions setbit, getbit et togglebit de la Construct 2, il est possible de définir des bits individuels dans ces nombres. Si un jeu utilise les quatre touches fléchées pour se déplacer et la barre d'espacement pour tirer, il ne s'agit que de cinq commandes, qui peuvent être stockées sur 8 bits, avec un 0 indiquant que l'on n'appuie pas sur la touche et un 1 indiquant que l'on appuie sur la touche. L'hôte peut alors examiner chaque bit et simuler les commandes appropriées. Tout cela peut être fait avec un seul octet, ou un int16 si vous avez plus de huit commandes, ce qui permet une utilisation très efficace de la bande passante. De même, l'hôte peut envoyer aux pairs plusieurs états de marche/arrêt en une seule valeur.