SCUM : Mise à jour du développement #67 – ScumWorld

Clair…

“Des solutions telles que diviser les acteurs en groupes échelonnés, ou simplement mettre à jour moins fréquemment, pourraient atténuer le problème, mais dégraderont également l’expérience client en diminuant la fréquence des mises à jour.”

Ok génial. Donc (quelque chose comme) le taux de ticks…

“Les nœuds de graphique de réplication (nous les appellerons “nœuds” en abrégé) effectuent le travail réel consistant à déterminer quels acteurs ont potentiellement besoin de mises à jour, à les trier en groupes, à stocker des listes précalculées à envoyer aux clients, etc. Leur tâche ultime est de fournir des « listes de réplication » d’acteurs à la demande à chaque connexion client le plus rapidement possible, afin que le serveur dépense le moins de cycles CPU possible par acteur et par client.

Cela ressemble à la théorie des graphes. Itinéraires les plus courts, listes… ok, passionnant.

Citation de Simon

Merci romaniser . Donc, en gros, vous pouvez dire : le système est là pour créer une performance équilibrée entre le joueur, le serveur et le client. Avec ce système de graphiques de réplication, les acteurs n’ont plus besoin d’évaluer chaque client connecté individuellement, résolvant ainsi le problème de performances du processeur sans sacrifier l’expérience client. Alors peut-être pouvons-nous nous attendre (espérons-le) à une amélioration des performances en termes de jouabilité multijoueur dans SCUM.

Très bien, je comprends.

Merci