Afin de prendre en charge des mécanismes physiques complexes tout en visant une expérience fluide et réactive pour les joueurs, le moteur de physique Roblox utilise un système de physique distribuée dans lequel les calculs sont répartis entre le serveur et tous les clients connectés. Dans ce système, le moteur attribue la propriété réseau des BaseParts simulés physiquement à un client ou au serveur pour diviser le travail de calcul des physiques.
Les clients expérimentent des interactions physiques plus réactives avec les parties qu'ils possèdent, car il n'y a pas de latence due à la communication avec le serveur. La propriété réseau améliore également la performance du serveur car les calculs de physique peuvent être répartis entre les clients individuels, permettant au serveur de se concentrer sur d'autres tâches.
Propriété de BasePart
Par défaut, le serveur conserve la propriété de tout BasePart. De plus, le serveur possède toujours les BaseParts ancrés et vous ne pouvez pas changer manuellement leur propriété.
En fonction de la capacité matérielle d'un client et de la proximité du Player.Character du joueur avec un BasePart non ancré, le moteur attribue automatiquement la propriété de cette partie au client. Ainsi, les parties proches du personnage d'un joueur sont plus susceptibles de devenir possédées par le joueur.
Propriété d'assemblage
Si un mécanisme basé sur la physique n'a pas de parties ancrées, définir la propriété sur une assemblée à l'intérieur de ce mécanisme définit la même propriété pour chaque assemblée dans le mécanisme.
Si vous ancrez une assemblée isolée qui n'est pas partie d'un mécanisme plus large, sa propriété revient au serveur, puisque le serveur possède toujours les BaseParts ancrés. Lors de la désancrage de la même assemblée, son état de propriété précédent est perdu et elle revient à une gestion automatique par le moteur.
Si vous ancrez une assemblée au sein d'un mécanisme plus large d'assemblées, sa propriété revient au serveur, mais la propriété des autres assemblées reste inchangée. La désancrage de la même assemblée rétablit sa propriété précédemment définie.
Définir la propriété
Dans les jeux avec des interactions physiques complexes ou dans les cas où vous devez attribuer un contrôle direct, vous pouvez définir la propriété via un appel côté serveur à BasePart:SetNetworkOwner().
Bien que vous puissiez appeler manuellement SetNetworkOwner(nil) pour le serveur pour des objets critiques de gameplay que le client ne devrait pas pouvoir manipuler, vous devriez le faire avec parcimonie car cela peut entraîner des interactions physiques saccadées pour les clients.
Notez également que le serveur possède toujours les BaseParts ancrés et que vous ne pouvez pas changer manuellement leur propriété.Considérons un véhicule qui a un objet VehicleSeat pour le conducteur et un objet Seat pour un passager, les deux inclus dans l'assemblée du véhicule. Avec les règles de propriété par défaut, si un personnage joueur s'assoit dans le Seat (passager) et qu'un autre joueur saute dans le VehicleSeat (conducteur), le passager obtient la propriété physique de l'ensemble du véhicule car il est entré en premier. Le conducteur devra attendre plusieurs cycles réseau avant que son entrée soit reconnue et le véhicule paraîtra moins réactif.
Le script suivant Script résout cela en attribuant manuellement la propriété réseau au conducteur. Dans ce script, le VehicleSeat définit son Occupant au Humanoid assis dessus, et le script écoute l'événement Changed du siège pour détecter quand un joueur s'assoit dans le siège. Lorsque le conducteur quitte le siège, la propriété réseau du véhicule revient à la gestion automatique avec BasePart:SetNetworkOwnershipAuto().
local Players = game:GetService("Players")
local vehicleSeat = script.Parent
vehicleSeat.Changed:Connect(function(prop)
if prop == "Occupant" then
local humanoid = vehicleSeat.Occupant
if humanoid then
-- Obtenez le joueur à partir du personnage
local player = Players:GetPlayerFromCharacter(humanoid.Parent)
if player then
vehicleSeat:SetNetworkOwner(player)
end
else
-- Réinitialisez la propriété lorsque le siège est inoccupé
vehicleSeat:SetNetworkOwnershipAuto()
end
end
end)
Pour des performances fluides et un comportement réactif, assurez-vous également d'attribuer la propriété de toutes les BaseParts libres au-dessus d'un véhicule au même client qui contrôle le véhicule.
Visualiser la propriété
Pour aider au débogage de la propriété réseau, Studio peut rendre des contours colorés autour des objets lors des tests de jeu.
| Couleur de contour | Description | |
|---|---|---|
| (vert) | Votre client possède la partie et la simule. | |
| (rouge) | La partie se trouve dans une "zone tampon" où votre client la simule mais elle est toujours possédée par autre chose. Votre client pourrait obtenir la propriété après cela, ou elle peut être rejetée. | |
| (blanc/gris) | Le serveur ou un autre client possède la partie par propriété réseau automatique ou par attribution explicite via part:SetNetworkOwner(). | |
| (noir) | La partie n'est possédée ni par le serveur ni par le client. La physique ne s'appliquera pas à cette partie. | |
Notez que dans une simulation multi-client, chaque client reçoit une couleur unique pour indiquer sa propriété ; cela est reflété dans la vue Serveur, vous aidant à déterminer quel client possède quelle(s) partie(s) à tout moment.
Pour activer la visualisation de la propriété réseau :
Cliquez sur le bouton options de visualisation dans le coin supérieur droit de la vue 3D.
Dans le menu déroulant, activez Propriétaires réseau.
Préoccupations en matière de sécurité
Roblox ne peut pas vérifier les calculs physiques lorsqu'un client possède un BasePart. Les clients peuvent en tirer parti et envoyer des données incorrectes au serveur, comme téléporter le BasePart, le faire traverser des murs ou voler.
De plus, les événements BasePart.Touched sont liés à la propriété réseau, ce qui signifie qu'un client peut déclencher des événements Touched sur un BasePart qu'il possède et les envoyer au serveur, même si le serveur ne voit pas cela toucher quoi que ce soit. Par exemple, un client peut faire en sorte qu'une épée inflige des dégâts à un autre joueur à travers la carte en déclenchant l'événement par des injections de scripts, il est donc important de vérifier la validité de tels événements déclenchés par les clients.
Voir Tactiques de sécurité et atténuation des tricheurs pour des tactiques de sécurité détaillées et des tactiques d'atténuation des tricheurs pour les jeux Roblox.