01 /

Observer une pression locale.

Mon régulateur examine le pool CPed et compte les personnages réseau présents côté client. Il ne mesure ni le nombre total de joueurs du serveur, ni directement le temps d’une frame. Ce signal sert à ajuster une partie de la population ambiante.

Dans les valeurs par défaut, le mode modéré commence à 90 personnages réseau avec un multiplicateur de densité de 0,55. À 108, le mode fort passe à 0,25. Un signal de pression lié à la création de personnages peut déclencher le mode d’urgence à 0. Ces seuils sont configurables ; ils ne représentent pas des limites universelles du moteur.

07 / Un régulateur avec mémoireObservations toutes les 2 s
NormalTemps simulé 0 s
10890880 s20 s
100%densité demandée
0smaintien restant
0/15 scompteur de retour

Intensité de génération demandée · ce dessin ne compte pas les personnages existants

Ma contrainte est retirée. Les éventuelles restrictions des autres systèmes restent actives.

Comptages fictifs et valeurs par défaut de mon régulateur. Les boutons de scénario avancent d’une observation. Le graphe conserve les 31 dernières mesures. Le modèle reproduit les transitions de densité ; il ne simule ni la génération du moteur ni les suppressions ciblées d’urgence.
02 /

Donner une mémoire au régulateur.

Si j’utilisais le même seuil pour activer et désactiver la protection, un comptage qui oscille autour de ce seuil ferait changer le mode en permanence. J’ai séparé le seuil de retour, fixé par défaut à 88, des seuils d’entrée.

J’ai ajouté deux temporisations. Le mode fort et le mode d’urgence peuvent être maintenus pendant au moins 30 secondes à partir du déclenchement concerné. Dans la branche de retour, une observation à 88 ou moins peut ensuite démarrer un compteur de grâce. Une nouvelle observation satisfaisant ces conditions peut désactiver la protection après au moins 15 secondes.

Ma boucle observe le pool toutes les deux secondes. Un changement de mode remet le compteur de grâce à zéro ; dans la branche de retour, une observation au-dessus de 88 le réinitialise aussi. Les observations à 90 ou plus passent par les branches de pression. La démonstration suit ces transitions, avec un retour évalué au rythme des observations.

03 /

Composer les contraintes des autres systèmes.

Une cinématique, une zone ou une instance peut déjà demander une densité réduite. J’ai organisé ces demandes comme des contraintes nommées : chaque système pose son propre override, puis le retire lorsqu’il n’en a plus besoin.

Pour chaque catégorie de population, je retiens le minimum entre la configuration de base et les contraintes actives. Le régulateur ne peut donc pas annuler une restriction plus forte décidée ailleurs. Quand il se désactive, il retire uniquement sa propre contribution.

Les multiplicateurs concernent la génération de population. Un réglage à 0,25 ne signifie pas que trois quarts des personnages présents disparaissent instantanément. C’est pourquoi le schéma représente une densité demandée, distincte du comptage observé.

PSEUDO-CODE EXPLICATIFdensitéEffective = min(base, contraintes actives)
pression élevée → activer et maintenir la protection
conditions de retour satisfaites → retirer ma contrainte
les autres contraintes continuent de s’appliquer
04 /

Prévoir un soulagement ciblé en urgence.

J’ai prévu un chemin complémentaire pour les situations de pression réseau. Il sélectionne certains personnages ambiants éloignés, exclut notamment les joueurs, les entités de mission et les personnages portant des marqueurs protégés, puis regroupe les candidats par propriétaire réseau.

La sélection est bornée à 24 candidats et privilégie les plus éloignés dans une bande de distance définie. Elle est relayée vers le serveur et les clients propriétaires pour tenter un soulagement ciblé. La réduction de densité et cette suppression ciblée sont deux mécanismes distincts.

Je garde les transitions observables avec le mode, le comptage et la densité demandée. Cela permet de comprendre quelle contrainte est active et pourquoi, sans transformer un seuil de configuration en promesse de performance.

Le principe

Je combine un seuil de retour, un maintien et un compteur de grâce. Le régulateur garde une mémoire de la pression au lieu de réagir à chaque variation isolée.

Poursuivre l’exploration

Comment j’ai conçu l’ObjectStreamer.