Les jeux en réseau comme vos jeux sur Roblox présentent le problème frustrant et inévitable du décalage. Si votre jeu est FilteringEnabled, vous utiliserez probablement un nombre décent de 
RemoteFunctions ou 
Événements à distance. Si vous utilisez RemoteFunctions ou RemoteEvents, il y aura forcément du lag dans votre jeu. Heureusement, il existe quelques stratégies que vous pouvez utiliser pour accepter ce décalage et l'intégrer gracieusement dans les fonctionnalités de votre jeu.
Contenu
- 1 La source du décalage
- 2 canons à retardement
- 3 Lag dans le monde réel
- 4 Tester le décalage dans Studio
La source du décalage
Avant d'apprendre certaines stratégies qui masquent le décalage, il est important d'avoir un modèle mental précis expliquant pourquoi le décalage doit exister dans les jeux avec des appels à distance.
Disons que vous êtes l'un de nos utilisateurs au Royaume-Uni et que vous jouez à un jeu ROBLOX FilteringEnabled. Dans ce jeu, un script local vous permet d'appuyer sur la touche 'F' pour tirer un canon. Le développeur de ce jeu a décidé que les boulets de canon sont trop importants pour que le client puisse les gérer. Par conséquent, le script local effectue un appel distant au serveur afin que le serveur puisse être celui qui se déclenche. Lorsque le client détecte que la touche « F » a été enfoncée, il contacte le serveur, le serveur tire le canon et le serveur informe le client de ce qui s'est passé en conséquence. Cependant, étant donné que votre ordinateur se trouve au Royaume-Uni et que les serveurs Roblox se trouvent aux États-Unis, cela nécessite qu'un signal soit transmis à travers tout l'océan Atlantique. À deux reprises. Cela prend du temps, et ce temps se présente sous la forme d'un décalage ennuyeux entre le fait d'appuyer sur la touche 'F' et de voir réellement le canon tirer.
Canons à retardement
Afin de rendre ce dernier exemple un peu moins hypothétique, ce tutoriel est accompagné d'un simple jeu ROBLOX appelé "Laggy Cannons". Vous pouvez y jouer en ligne ici, et vous pouvez également télécharger la version Studio pour vous-même si vous le souhaitez.
Dans Laggy Cannons, il y a quatre canons dirigés en direction de quatre cibles mobiles. Chaque paire canon-cible est affectée par le même temps de latence artificiellement exagéré, mais chaque paire canon-cible résout ce décalage d'une manière légèrement différente. Certaines paires gèrent mieux ce décalage que d'autres. La paire violette est meilleure que la rouge, la paire rouge est meilleure que l'orange et la paire orange est meilleure que la bleue.
Avant de lire le reste de ce tutoriel, le moment serait venu d'aller jouer à Laggy Cannons et de voir si vous pouvez sentir les différences entre les quatre. Pour jouer à Laggy Cannons, utilisez les quatre téléporteurs près du point d'apparition pour vous téléporter vers les blocs de canon avec les couleurs correspondantes. Lorsque vous vous tenez sur une plate-forme de canon, vous pouvez appuyer sur « F » pour tirer un boulet de canon et essayer de toucher la cible mobile de ce canon. Montez sur la zone colorée du bloc de canon pour revenir aux blocs de téléportation et essayez un autre canon. Vous pouvez manipuler le nombre de secondes de décalage artificiel en cliquant sur les boutons « + » et « - » sur le pavé de commande près du point de réapparition. Le reste de ce didacticiel explique en détail comment se comporte le canon ou la cible de chaque couleur et pourquoi. Nous généraliserons également les stratégies utilisées par chaque paire afin que vous puissiez les appliquer plus facilement à vos jeux.
Le canon bleu
Commençons par le canon qui n'essaie vraiment pas du tout : le canon bleu. Si vous appuyez sur la touche 'F', vous verrez et entendrez immédiatement l'explosion du tir de canon, mais vous ne verrez pas le boulet de canon pendant un bon moment. Voici la fonction qui est appelée dans un script local lorsque vous tirez le canon bleu :
--Dans une fonction locale de script local badCannonStrategy() Workspace.FireCannonEvent:FireServer(activeCannon) createExplosion(activeCannon) end
La première ligne de cette fonction utilise un RemoteEvent appelé « FireCannonEvent » pour demander au serveur de déclencher une variable globale appelée « activeCannon ». Le canon actif ici est, bien sûr, le canon bleu. FireCannonEvent est une requête unidirectionnelle vers le serveur. Après avoir envoyé au serveur un message lui demandant de tirer le canon bleu, ce script local affiche immédiatement une explosion à l'écran à l'aide de la fonction d'assistance non affichée « createExplosion ». Il n'y a aucun effort ici pour travailler avec le décalage inhérent au RemoteEvent. Le message est envoyé, l'explosion est créée, puis on attend que le serveur tire le projectile.
Leçon 1 : Soyez prudent avec votre code
La fonction badCannonStrategy() semble assez innocente. Il tire le canon et crée une explosion, n'est-ce pas ce que nous voulons ? Le problème est qu'il ignore complètement le décalage, et c'est très facile à faire. Si vous voulez faire d'excellents jeux, vous devez remarquer qu'il y aura du décalage ici. Lisez la suite pour savoir ce que vous pouvez faire à ce sujet.
Le canon orange
Le canon orange modifie légèrement la stratégie du canon bleu afin de synchroniser le tir du projectile avec l'explosion. La fonction qui tire le canon orange ressemble à ceci :
--Dans une fonction locale de script local okCannonStrategy() local waitForResponse = Workspace.FireCannonFunction:InvokeServer(activeCannon) createExplosion(activeCannon) end
Vous pouvez voir que le seul changement ici est la première ligne de la fonction. Au lieu d'utiliser un RemoteEvent pour tirer le boulet de canon, le canon orange utilise une RemoteFunction appelée "FireCannonFunction". Une RemoteFunction diffère d'un RemoteEvent en ce qu'elle a une valeur de retour. Alors qu'un RemoteEvent n'est qu'un signal du client au serveur, un RemoteFunction est un signal du client au serveur et également une valeur de retour du serveur au client. De plus, comme le client attend une valeur de retour, il attendra en fait que cette valeur de retour vienne avant de continuer dans son script local. C'est exactement la fonctionnalité dont profite le script de canon orange. Cette fonction de tir de canon légèrement meilleure attend que le serveur dise qu'il a tiré un boulet de canon avant de passer à l'explosion qui l'accompagne.
Leçon 2 : Synchroniser l'expérience
Le canon bleu n'a pas de sens parce que vous voyez l'explosion du canon bien avant de voir le boulet de canon. Dans le monde réel, les explosions et les tirs de boulets de canon se produisent simultanément. Pour qu'un jeu soit amusant et immersif, il ne doit pas enfreindre les attentes du joueur sur des choses stupides comme celle-ci. Suivez l'exemple du canon orange et utilisez RemoteFunctions pour synchroniser les événements sur le client et le serveur.
Le canon rouge
Alors que le canon orange résout le problème des boulets de canon et des explosions non synchronisés, il expose en fait un autre problème de décalage. Lorsque le joueur appuie sur la touche « F » pour tirer, il y a un délai important avant que le jeu ne réponde. C'est ce qu'on appelle le décalage d'entrée, et c'est l'une des choses que les joueurs détestent le plus. Il existe une astuce simple que vous pouvez utiliser pour supprimer le décalage d'entrée. Vous ne pouvez pas accélérer le temps qu'il faut au canon pour tirer. Quoi qu'il en soit, cela prendra le temps aller-retour qu'il faut pour qu'un message passe d'un client à un serveur à un autre. Vous pouvez cependant donner au joueur d'autres commentaires immédiats qui lui donneront l'impression que le jeu répond à ses commandes. Le retour immédiat que le canon rouge choisit de donner est un son. Lorsque le joueur appuie sur « F », le canon rouge commence immédiatement à jouer le son d'une mèche de canon qui brûle. Ce son jouera aussi longtemps qu'il faudra au serveur pour répondre à la RemoteFunction. Une fois que le serveur a répondu, le canon rouge éteint le son de la mèche en feu et crée une explosion qui accompagne le projectile que le serveur vient de tirer.
--Dans une fonction locale de script local bestCannonStrategy() Workspace.Sounds.BurningFuse:Play() local waitForResponse = Workspace.FireCannonFunction:InvokeServer(activeCannon) Workspace.Sounds.BurningFuse:Stop() createExplosion(activeCannon) end
Si vous allez jouer avec le canon rouge, cela devrait vous sembler totalement naturel. Il y a toujours un délai entre l'appui sur la touche 'F' et le tir du boulet de canon, mais il est imperceptible car le canon intègre ce décalage dans son fonctionnement.
Leçon 3 : Pas de décalage d'entrée !
Les joueurs détestent le décalage d'entrée. Il est frustrant de ressentir une déconnexion entre vous et le jeu. Bien qu'il puisse être nécessaire d'avoir une réponse tardive à l'entrée du joueur, vous pouvez toujours leur donner quelque chose de petit pour indiquer que leur demande a été entendue. Cela peut être un son, une couleur de brique changeante ou vraiment n'importe quoi. Faites savoir aux joueurs qu'ils sont écoutés et vous aurez des joueurs heureux.
La cible violette
Le canon violet fonctionne exactement de la même manière que le canon rouge. La différence entre la plate-forme violette et toutes les autres couleurs réside dans la fonctionnalité de la cible en mouvement.
Lorsque vous atteignez la cible bleue, orange ou rouge, vous remarquerez qu'il y a un délai entre le fait que la cible soit touchée et le son « ding » résultant et la mise à jour du score. À titre d'exemple, la mise à jour du « ding » et du score de la cible bleue est exécutée par la fonction serveur suivante :
--Script serveur Workspace.Blue.Target.Face.Touched:connect(function(projectile) wait(_G.artificialLag) --Comment Laggy Cannons crée un décalage artificiel --Lire le son de la cible Workspace.Sounds.TargetHit:Play() - -Mise à jour du score bleu blueScore = blueScore + 1 Workspace.Blue.Scoreboard.SurfaceGui.ScoreLabel.Text = blueScore end)
Nous savons que quelque chose d'aussi important que le score du joueur doit être géré par le serveur. Par conséquent, il doit y avoir un délai lors de la mise à jour du score d'une cible. Mais qu'en est-il du bruit de frapper la cible?
Bien que le serveur soit en fin de compte celui qui décide si la cible a été touchée ou non, le client est parfaitement capable de jouer immédiatement le son de frappe cible lui-même. Dans le pire des cas, si le client et le serveur ont un désaccord rare sur la question de savoir si la cible a été touchée, le joueur subira une divergence entre le son « ding » et la mise à jour du score. Cela peut arriver une fois sur cinq mille, et c'est un coût qui vaut la peine de donner un retour immédiat au joueur. Par conséquent, nous pouvons réellement diviser le script serveur précédent en un script serveur et un script local :
--Script serveur Workspace.Purple.Target.Face.Touched:Connect(function(projectile) wait(_G.artificialLag) -–(Comment Laggy Cannons crée un décalage artificiel) --Mise à jour du score violet purpleScore = purpleScore + 1 Workspace.Purple. Scoreboard.SurfaceGui.ScoreLabel.Text = purpleScore end) --Script local Workspace.Purple.Target.Face.Touched:connect(function(projectile) --Lire le son de la cible Workspace.Sounds.TargetHit:Play() end)
Leçon 4 : Divisez vos scripts
Parfois, vous devez faire la moitié du travail sur le serveur et la moitié du travail sur le client. N'ayez pas peur de détecter deux fois le même événement. La détection locale donne un retour d'informations au joueur et la détection du serveur gère une logique de jeu importante.
Lag dans le monde réel
Le décalage artificiel par défaut pour Laggy Cannons est d'une seconde. Ceci est superposé au décalage que votre machine subit naturellement lors de la lecture d'un jeu ROBLOX. Dans notre base de joueurs, nous voyons des joueurs avec un décalage allant de 0.1 à 1.5 seconde. Le décalage moyen semble osciller autour de 0.3 seconde. Heureusement, vous êtes maintenant équipé des outils pour gérer ce décalage.
Tester le décalage dans Studio
Si vous souhaitez simuler un décalage dans ROBLOX Studio, vous pouvez accéder à Fichier -> Paramètres -> Réseau -> IncomingReplicationLag et ajuster le nombre de secondes de décalage que Studio simulera lors de l'exécution d'un serveur de test.
