La fluidité se joue entre deux créations.

Laisser de la place au reste du jeu.

Mon streamer partage le pool d’objets avec le reste du jeu. J’ai donc combiné trois informations dans le calcul du budget : la limite du profil, les handles déjà créés par le streamer et le nombre total d’objets observé dans CObject.

Dans cette configuration, j’ai fixé un seuil de pool à 3 000 et réservé 300 places, ce qui donne une cible prudente de 2 700. C’est une marge définie dans mon système, pas une limite universelle du moteur RedM.

Le profil medium autorise jusqu’à 350 objets de base. J’ai prévu jusqu’à 200 places supplémentaires pour retenir des handles existants, lorsque le pool le permet. Je distingue ces deux budgets : le plafond de 400 des profils les plus élevés concerne la sélection de base, et non le total avec rétention.

PSEUDO-CODE EXPLICATIFplaces = handlesActuels + (seuilPrudent - poolObservé)
budgetTotal = borner(places, 0, limiteProfil + rétention)
budgetBase = min(limiteProfil, budgetTotal)

Éviter de détruire pour recréer aussitôt.

Un joueur peut osciller autour d’une frontière. Pour éviter de changer immédiatement tout son voisinage, je ne valide un nouveau chunk central qu’après trois observations consécutives. Je conserve aussi jusqu’à neuf chunks quittés pendant 12 secondes, pour permettre leur réutilisation lors d’un retour rapide.

J’ai ajouté une rétention distincte pour les handles : jusqu’à 10 secondes et 200 places configurées, dans la limite du budget total. La sélection de base reste prioritaire. La rétention utilise les places restantes et conserve uniquement des entités déjà créées.

Hors de la portée principale, je demande deux conditions supplémentaires : l’objet doit appartenir à un chunk retenu et rester à une distance inférieure à la portée augmentée de 1,5 taille de chunk. Dans la portée, un handle récemment sorti de la sélection de base peut aussi être retenu. Ces bornes limitent la mémoire occupée par ce cache temporaire.

Répartir le travail dans le temps.

J’ai placé des points de cession avec Wait(0) dans les parcours et les opérations d’entités. Le budget de travail est réglé à 1 ms, vérifié à certains points ; les créations et suppressions peuvent aussi céder la main après quatre opérations.

Cette approche reste coopérative. Un appel natif ou un tri peut dépasser la cible avant le prochain contrôle. Le réglage de 1 ms me sert à découper le travail ; il ne garantit pas la durée de chaque frame.

J’évite également de refaire certaines passes de sélection lorsque le joueur reste immobile. La boucle utilise un intervalle inactif de 750 ms et un seuil de déplacement de 1 unité. Les changements d’état peuvent forcer une passe pour garder la sélection à jour.

Rendre les arbitrages visibles.

Réduire le budget limite les créations, mais rend aussi la sélection plus contraignante. Augmenter la rétention peut éviter des recréations, au prix de handles conservés plus longtemps. J’ai séparé ces réglages pour pouvoir travailler sur ce compromis.

J’ai instrumenté la passe avec des compteurs de candidats, d’objets gardés, de suppressions dues au budget, de handles perdus et de tentatives de création. Ils permettent de relier le comportement du streamer à une zone ou à un déplacement précis.

La démonstration reprend ma formule de budget avec un comptage du pool supposé fiable. Dans mon implémentation, j’ai aussi prévu un repli sur le budget de base si le comptage est indisponible, puis une nouvelle vérification avant de créer un handle.