Bonjour la communauté, c’est le retour du lead dev !
De quoi on parle aujourd’hui Mathieu ?
– Très bonne question Raph (non genré, choix au pif, c’est une variation personnelle de Fred), de Conseil de Guerre évidemment.
Ah il y a du nouveau en ce royaume ?
– Et pas qu’un peu Raph, la joyeuse équipe du Projet CarTylion est l’heureuse détentrice d’un prototype jouable du jeu !
État des lieux
Le travail est donc terminé !
Et bien non il ne fait même que commencer. Un prototype, si avancé soit il, n’est jamais une version finale. Il contient notamment des bugs « acceptables » pour l’instant et du code pas forcément utile ou rangé.
C’est un peu comme la chambre des adolescents avant le passage des parents.
Je suis le parent et j’ai rangé et nettoyé pour que l’ordinateur, ici l’ado, puisse continuer à faire fonctionner le jeu, ici sa chambre. On a vu précédemment comment créer les briques de base du jeu et en faire l’agencement correct.
Cela suffit parfaitement pour un jeu « solo » mais Conseil de Guerre en solo n’est pas aussi intéressant (et c’est un euphémisme).
Mathieu avec une Intelligence Artificielle (IA) le solo serait possible et intéressant comme les échecs, le go, etc. !
– Tu as raison Raph mais faire une IA soi-même est très difficile, de même que du réseau, il faut donc faire un choix. On a donc choisi de nous reposer sur l’intelligence humaine des joueurs pour créer de la convivialité avant de faire de la compétitivité avec une intelligence artificielle.
Créer un réseau
On va donc utiliser une brique réseau, ou plutôt un ensemble de briques.
Mais Mathieu si notre mur, ici l’application, est fait de certaines briques « maison » comment faire entrer des briques « étrangères » qui assurent la connexion au réseau quel que soit le nombre d’utilisateurs ?
– En effet Raph il faut chercher des briques compatibles. Pensez à vos constructions Lego ou Playmobil, il est rare qu’une pièce de l’un aille sur l’autre sans forcer ou abimer. Ici c’est à notre mur de s’adapter car les briques du réseau seront très difficiles à modifier.
Pourquoi ne pas faire notre brique réseau « maison » simple Mathieu ?
– Raph en soi c’est peut-être ce que ferait un spécialiste des réseaux informatiques mais seul il lui faudrait entre 1 et 2 ans en s’inspirant du déjà fait, donc c’est une mauvaise idée. Adapter notre ensemble de briques déjà bien faites est donc la solution privilégiée car on devrait gagner du temps et je ne suis pas spécialiste réseau.
Utiliser des ensembles de fonctionnalités déjà prévues pour un usage et empaquetées s’appelle utiliser une API, attention au droits de distribution / utilisation. J’ai choisi de tester les trois bibliothèques de code « gratuites » à savoir MLAPI, Photon et Mirror. Encore faut-il les prendre en main. Les questions à se poser sont nombreuses :
- Comme vous vous en rappelez sûrement, dans les articles précédents, j’ai défini le débit comme une quantité de données circulant dans un tuyau et la latence comme une durée pour la donnée d’aller d’un bout à l’autre du tuyau. Faire du multijoueurs c’est donc avoir une infinité de tuyaux et faire le bon aiguillage, mais comment ? Une fois l’aiguillage fait, comment agir en cas de problème sur la voie et que transporter ?
- Même si on le voulait, impossible de mettre tout le jeu dans un seul train, dans plusieurs serait possible mais une mauvaise idée si les données ne sont pas cryptées. Pourquoi ne pas tout crypter ? Parce que toute donnée cryptée doit pouvoir se décrypter à la fin. Même les transactions bancaires décryptent avec une grande clé vos données pour faire vos opérations et si quelqu’un a la clé et écoute le réseau, désolé pour votre compte… Pour le jeu ce sera identique et on sera de toute façon plus facile à percer que les comptes bancaires donc on ne crypte pas tout. Pour éviter les petits malins qui voudraient tricher, on ne mettra en ligne que le strict nécessaire par exemple pas la main d’un adversaire mais seulement sa taille empêchant de savoir quelles cartes il a en main mais pas leur type Pion ou Décision, ce qui correspond à une partie réelle (pendant laquelle on voit les dos des cartes de l’adversaire).
J’avais utilisé un flux continu pour illustrer le débit mais c’est un peu abusif. On est plutôt sur du goutte à goutte plus ou moins gros et rapide. Chaque goutte est appelée paquet et ce n’est pas un cadeau voici sa tête :
Ce gros paquet peut se perdre ou arriver en retard ou pire être corrompu. Dans les deux premiers cas on le renvoie et on jette le(s) doublon(s) éventuel(s), c’est donc peu de gestion penseriez-vous, mais non. Il faut déterminer si le paquet est perdu depuis combien de sauts il l’est, c’est une estimation du temps. S’il faut au moins 4 sauts pour faire Lyon Paris un paquet qui en indiquerait moins n’arrivera jamais mais un paquet qui en montrerait 10 fois plus tournera longtemps avant d’arriver et pourrait solliciter un deuxième envoi du destinataire à l’expéditeur. Et qui doit gérer ce genre de questions ? Les développeurs, alias le stagiaire et moi.
Heureusement les objets présentés ici sont encapsulés un peu comme quand on achète un marteau, la tête est déjà associée au manche, ce qui le rend plus facile à utiliser pour un novice. Ceci est un aperçu des conditions à gérer faire une liste exhaustive de notre travail serait très indigeste, je vais donc vous épargner, mais si vous avez des questions, n’hésitez pas à me les poser dans les commentaires !
Le prototype n’est qu’un pas et il a fallu choisir la direction suivante, la mise en réseau. Ce ne sera pas une promenade de santé bien que très intéressant. Il ne s’agit pas de foncer tête baissée sinon ce sera le mur. On va éviter ceci mais il faudra un peu de patience.
Je vous laisse, mon T800 rappelle que « I will be back! » et Raph aussi.
Partagez-le !
Laisser un commentaire
Vous devez vous connecter pour publier un commentaire.