Skyrim est sorti le 11 novembre et son monde donne l’impression de continuer loin du joueur. Une console ne peut pourtant pas garder chaque village, personnage et objet en simulation complète. Le moteur fabrique cette continuité en changeant le niveau de détail selon la distance et l’importance.

Le monde est découpé en cellules. Autour du joueur, le moteur charge géométrie, textures, collisions, scripts et personnages. Plus loin, il remplace les modèles par des versions simplifiées ou un paysage précalculé. Très loin, il garde surtout un état abstrait : quête active, personnage vivant, coffre déjà ouvert.

Le budget d’une image impose des priorités

À 30 images par seconde, le jeu dispose d’environ 33 millisecondes pour lire les entrées, simuler, préparer le rendu et afficher. Un cycle simplifié pourrait être :

1. lire la manette et mettre à jour le joueur;
2. charger ou libérer les cellules selon sa position;
3. exécuter l’IA et la physique des objets proches;
4. sélectionner les objets visibles;
5. envoyer géométrie et textures au GPU;
6. sauvegarder certains changements en arrière-plan.

Le chargement doit éviter un arrêt visible. Une file prépare la prochaine cellule pendant que le joueur avance. Si le disque ne suit pas, des objets apparaissent tard ou une pause survient. Garder trop de cellules consomme la mémoire; les retirer trop tôt produit des allers-retours coûteux.

Les personnages lointains ne suivent pas nécessairement chaque pas. Le système peut calculer qu’un marchand est « au travail » et le placer à sa boutique lorsque la cellule est rechargée. Cette simulation allégée préserve la cohérence sans exécuter toute son IA.

L’illusion se brise aux frontières

Les bogues arrivent lorsque l’état traverse mal les niveaux de détail : un personnage essentiel disparaît, deux scripts modifient la même quête ou un objet tombe dans la géométrie. La sauvegarde sérialise des milliers de décisions et références. Une mise à jour du jeu qui change un script doit encore relire les anciennes sauvegardes; sinon des dizaines d’heures de progression deviennent inutilisables.

Le moteur doit aussi limiter les scripts créés par les quêtes et modifications. Une boucle lointaine peut consommer du temps même si son objet n’est plus visible. Des budgets par sous-système, des compteurs de scripts et des outils de profilage permettent de trouver ce qui vole le frame time.

Pour tester, je ferais des trajets rapides entre cellules, chargerais une sauvegarde ancienne, suivrais une quête dans un ordre inattendu et remplirais la mémoire jusqu’à la limite. Le chemin heureux dans un village vide ne représente pas la partie après cinquante heures.

Ce qui me plaît dans un monde ouvert, c’est cette architecture de fidélité variable. On ne calcule pas tout; on décide ce qui doit être exact maintenant, ce qui peut être résumé et quel état permettra de reconstruire le reste. C’est une pratique très utile dès qu’un système promet un monde plus grand que sa mémoire.