Proposition sur le passage en réseau de

The Legend of Zelda: Breath of the Wild

Ajouter une dimension de réseau dans un jeu open world tel que The Legend of Zelda:
Breath of the Wild n’est pas chose aisée .

Étant un open world, une grande quantité d’informations devront être synchronisées. Il
faudrait synchroniser le monde et les interactions .

La physique devra être synchronisée afin de permettre la synchronisation des projectiles.

Les projectiles aussi, afin de permettre des combats fluides. Les différentes créatures dont
la physique est simulée devront être synchronisées aussi. Le cycle jour/nuit ainsi que la
météo devront aussi être synchronisés afin de conserver les intentions des game designers
et de permettre une aventure commune entre les joueurs .

Cependant, il est important de prendre en compte les contraintes techniques. Les joueurs ne
doivent avoir aucune restriction sur leur liberté. De plus, l’infrastructure réseau de Nintendo
n’est pas la plus efficace. Et pour finir, il faut éviter au mieux les dépenses non nécessaires.

Avec les contraintes posées, une architecture client-serveur risquerait d’être trop coûteuse. Il
faudrait financer l’installation et le maintien des serveurs sur le long terme. De plus, dans le
cadre d’une architecture client-serveur, au vu du grand nombre d’informations qui ont besoin
d’être communiquées entre les clients et le serveur, l’infrastructure réseau de Nintendo étant
limitée, cela pourrait causer des problèmes de jouabilité .

Afin de ne pas impacter le game design, les sanctuaires devront être instanciés. C’est-à-dire
que chaque joueur ne peut y être que seul dans une instance gérée par son client ou bien le
serveur.Cependant, les sanctuaires étant instanciés, il faudra stocker quels joueurs ont
accompli quels sanctuaires. De même pour les quêtes.

Il sera également important de correctement définir la fréquence d’envoi des informations

sur le réseau.

Afin de faire cela, une base de données pourrait être mise en place dans le cadre d’une
architecture client-serveur. Cependant, cela demanderait un temps de développement
supplémentaire.

Le framerate du jeu sur Switch tournant autour des 30 fps et le jeu ne nécessitant pas au
joueur d’avoir des input timer sur des frames, il serait démesuré de choisir un net Tick de
plus de 30 Hz. Comme dit précédemment, le jeu ne nécessite pas au joueur d’avoir des
réactions à quelques frames près, et ce même pour les esquives ou contres parfaits. Je
pense qu’un net Tick de 10 Hz serait largement suffisant.

Étant un jeu coopératif et non compétitif, les clients peuvent tout simplement connaître les
sanctuaires et quêtes qu’ils ont eux-mêmes effectués. Cela permet d’avoir une gestion de
ses données qui fonctionne peu importe l’architecture choisie. Certes, cela permet au joueur
de tricher plus simplement, mais qu’importe car les joueurs seraient alors les seuls
responsables de leur propre expérience de jeu.

Cependant, une architecture peer-to-peer, quant à elle, demanderait à la console d’effectuer

des calculs ainsi que des envois et réceptions d’informations supplémentaires. Cela
impacterait alors les performances du jeu .

En considérant une architecture Client-Serveur :

Le serveur effectue les calculs de Physiques autour des joueurs. Il n’y aurait alors aucun
problème d’autorité puisque seul le serveur pourrait effectuer ses calculs. Cependant, cela
implique que plus les joueurs sont éloignés, plus le serveur aura de calculs à faire.

La gestion d’un monde cohérent avec la météo et le cycle jour/nuit serait également
simplifiée car le serveur enverra simplement ses informations aux joueurs. Cependant, le
nombre limité de joueurs par serveur nécessite de posséder une grande quantité de
serveurs, qui devront être achetés puis maintenus, ce qui causerait des frais
supplémentaires non négligeables.

Il serait possible de limiter le nombre de serveurs à acheter en développant les applications

serveur de sorte à ce que plusieurs puissent tourner sur une seule machine. Cependant,
cela allongerait le temps de développement.

De la même manière que la physique, les IA ne pourront effectuer des calculs que s'ils sont
autour des joueurs.Cependant cela implique les mêmes problèmes que pour la physique.

De plus, il sera important de choisir correctement si un joueur a besoin des résultats de ses
calculs s'ils ont été requis par un autre joueur. Car afin d’économiser de la bande passante
et des performances, il faut bien n’envoyer que des informations nécessaires aux clients qui
en ont besoin.

Dans une situation client-serveur, si un joueur ramasse un objet, l’autre joueur ne peut plus
le ramasser, ce qui permet rapidement d’empêcher les problèmes de duplication. Dans le
cadre d’instances telles que les sanctuaires, il faudra que le serveur puisse gérer des
instances différentes en même temps, augmentant également le nombre de calculs
nécessaires.

Malgré tout cela, dans l’objectif d’une coopération multijoueur entre deux joueurs, je pense
qu’une architecture peer-to-peer serait plus favorable. Puisqu’elle permet de neutraliser les
coûts matériels des serveurs pour l’entreprise. De plus, la connexion entre deux personnes
directement peut tout à fait être plus efficace qu’avec un serveur en intermédiaire .

En considérant donc une architecture Peer to peer :

Afin de conserver la liberté des joueurs, les simulations seront effectuées par autorité. Un
client a l’autorité sur la zone où il effectue les calculs physiques si il était en hors ligne. Les
informations de physique calculées par un joueur ne seront alors envoyées que si l’origine
de ses calculs se trouve dans la zone d’affichage de l’autre joueur. Cela permettra à un
joueur à un coin de la map de ne pas être affecté par les événements d’un joueur de l’autre
côté de la map ainsi que de ne pas donner de calcul supplémentaire à d’autres clients .

Cependant, qu’en est-il lorsque les deux joueurs sont côte à côte et que leurs zones de
simulation de physique se superposent ? Dans ce cas, le client le plus proche de l’objet à
simuler possède la responsabilité d’effectuer les calculs pour cet objet, et ce jusqu’à ce que
l’objet quitte sa zone de simulation .

Afin d’économiser des performances et de la bande passante, nous pouvons sélectionner et

trier les informations à communiquer entre les clients par importance .

Les informations qui seront primordiales à partager, peu importe la distance, seront :

● l’état des joueurs, c’est-à-dire les points de vie, en vie/mort, une approximation de la
position .
● le cycle jour/nuit ainsi que la météo .

Les informations qui seront primordiales à partager si les joueurs sont à une distance
appropriée à l’envoi d’informations seront :

● la physique des objets, car il s’agit d’un des éléments les plus importants pour
l’interaction avec le monde .
● les monstres, c’est-à-dire leur position, état, animations .
● les projectiles, car il s’agit d’un aspect important des combats .
● les joueurs et leur affichage, c’est-à-dire une position plus exacte, leurs animations
ainsi que ce qui a déjà été cité .
● les collectibles, car il ne serait pas dérangeant si un objet ramassé par un joueur au
loin peut être ramasser à nouveau par un autre joueur . Par contre, afin d'éviter la
duplication, un objet qui est dans la zone de simulation des deux joueurs doit être
synchronisé. Cela permet d’éviter qu’un joueur pose un objet au sol et que les deux
puissent le ramasser.

Les informations qui ne sont pas nécessaires à partager seront :

● les inventaires de marchands, car cela empêcherait qu’un joueur empêche un autre
d’acheter des objets .
● quels sanctuaires ont été accomplis, puisque les sanctuaires sont instanciés, chaque
joueur peut les accomplir indépendamment des autres .

Après avoir identifié les informations nécessaires à partager ou non, je peux en déduire
qu’utiliser un protocole TCP sera suffisant.Cependant, un protocole UDP modifier permettrait
de réduire l’impact en performance des envois de données, mais prolongerait la durée de
développement.

L'objectif de ce protocole UDP modifier serait d’avoir un protocole nous permettant de définir
avec précision les informations qui peuvent se perdre et celles qui doivent absolument
arriver à destination.
 Le nombre de joueurs étant défini et réduit à deux, cela nous permettra d’être certains que
les informations nécessaires seront envoyées au bon moment. De plus, cela nous permettra
de choisir les informations qui devront être envoyées avec précision, telles que les points de
vie des joueurs, ainsi que les informations qui ont besoin de moins de précision, telles que
des positions qui seront actualisées assez régulièrement pour qu’un ou deux messages
perdus n’impactent pas le gameplay .

Il sera nécessaire d'effectuer une interpolation des positions des éléments afin de permettre
d'éviter des bugs visuels dérangeants, ce qui entraînerait des calculs en plus sur la console.
De plus, si l’un des joueurs possède une très mauvaise connexion, cela nuira à l’expérience
des deux joueurs en causant, par exemple, la téléportation du joueur ou, pire encore, des
monstres attaquant trop vite ou ne se téléportant pas correctement.

Il existe également la possibilité d'effectuer un système de serveur dédié et d'hôte.

Cependant, cela signifierait que la console d'un des joueurs serve à la fois de Joueur/Client
et de serveur. Les limitations matérielles de la Switch ne permettent pas de faire fonctionner
le serveur et le jeu correctement simultanément. Il s'agit donc d'une solution à écarter.

En Conclusion :

Afin d’ajouter une dimension réseau à ce jeu, je pense donc qu'il est préférable d'utiliser un
protocole TCP dans une architecture Peer-to-Peer. Effectuer les calculs de physique sur les
clients qui possèdent l’autorité des objets concernés, de même pour les IA et les collisions.

Cependant, si le développement d'un protocole personnalisé est possible, il est alors

préférable de le faire plutôt que d'utiliser un protocole TCP qui est plus lourd.