Tous les jeux ne pouvaient-ils pas éviter le chargement après le démarrage?

Tout comme les jeux géants du monde ouvert chargent des cartes massives de manière dynamique, ne pourrions-nous pas charger des cartes, des menus et pratiquement n'importe quelle interface ou paramètre 3D via cette même méthode de chargement dynamique? Sans changer l'environnement, il semble que les interfaces et divers emplacements du jeu pourraient tous être chargés dynamiquement de la même manière que les cartes du monde ouvert massives sont chargées lorsque vous les parcourez.

Pourquoi n'est-ce pas fait? Je vois tellement de jeux modernes où vous devez attendre une minute ou plus pendant le chargement du match / de la carte / du niveau. Je sais qu'il y a une latence impliquée dans la connexion des pairs, mais cela ne prend pas plus de quelques instants dans mon expérience. Quels sont les problèmes avec ce concept pour l'empêcher d'être utilisé pour éliminer le temps de chargement impliqué dans le chargement des données de carte / niveau / interface?

La réponse est oui, cela pourrait être fait, dans la plupart des cas, au moins dans une certaine mesure.

Les raisons pour lesquelles cela n'est pas fait sont nombreuses:

• Il faut du temps et de l'argent pour bien faire les choses.
• Le nombre de bogues qui passent le test sera plus élevé
• Les temps de chargement sont acceptés par les utilisateurs.
• Il peut y avoir d'autres raisons pour les temps de chargement, comme l'équilibrage de la charge du serveur.
• Les solutions génériques qui peuvent être achetées sur étagère sont plus compatibles avec «charger tout à la fois».

Si vos menus ont une tonne de ressources, ces ressources prennent du temps à se charger. Vous n'avez également aucune idée de l'ordre dans lequel les utilisateurs navigueront dans votre menu. Ils pouvaient cliquer sur options -> retour -> crédits, ou crédits -> retour -> démarrer le jeu en succession rapide. Il n'y a donc pas de stratégie de streaming raisonnable.

Dans un jeu en monde ouvert, vous savez que le joueur ne se déplacera pas plus vite qu'une certaine vitesse, vous savez donc que vous n'avez pas besoin de charger les versions détaillées des emplacements lointains jusqu'à ce qu'ils les approchent.

Un facteur important dans la faisabilité d'une telle solution est la prévisibilité de ce qui doit être chargé. Si le joueur charge des niveaux entièrement nouveaux sans aucun moyen d'anticiper ce qu'il choisira, une solution complètement transparente n'est tout simplement pas possible. Par exemple, lorsque le joueur peut sélectionner n'importe quel niveau du jeu à partir duquel jouer, ou s'il a la liberté de se téléporter vers des zones complètement différentes dans les jeux du monde ouvert.

Certains jeux Halo commencent à charger le niveau sélectionné en arrière-plan lors de la configuration des jeux multijoueurs. Cela réduit le temps d'attente lorsque les joueurs sont prêts à commencer et est probablement le plus proche d'une telle solution lorsque le joueur peut choisir librement différents niveaux avec des actifs complètement différents.

Bien sûr, vous avez dit "sans changer l'environnement", mais je voulais juste évoquer l' exemple de Halo , car c'est quelque chose que j'aimerais voir plus.

Dans une campagne continue, ou chaque fois que le développeur a beaucoup de contrôle sur l'emplacement du joueur, une telle solution est certainement viable, comme vous le dites. Naughty Dog aime supprimer les temps de chargement, Jak et Daxter n'ayant connu aucun temps de chargement sur la PS2, et les jeux Uncharted ayant un seul temps de chargement au début.

Cependant, pour beaucoup, le temps de chargement n'est tout simplement pas un problème qui doit être résolu . Ou il est un problème qui est très faible sur les priorités des développeurs, quand il y a toujours plus qui pourrait être fait entre maintenant et la date de sortie .

Temps.

Vous avez besoin de temps pour gagner du temps. Ou vous avez besoin d'argent pour compenser le manque de temps. En tout cas, "Pas de temps de chargement!" est une fonctionnalité que seuls ceux qui ont le luxe de se le permettre peuvent offrir. Il faut une planification très minutieuse, et vous devez très bien comprendre ce que vous faites et tous les développeurs de jeux n'ont pas les ressources nécessaires.

En fin de compte, ce sont des ressources limitées.

Les jeux en monde ouvert et en particulier les MMO sont fortement conçus pour la prévisibilité - vous savez toujours quelles données vous devez charger longtemps à l'avance. Vous pouvez voir cela dans l'architecture des mondes - à chaque fois qu'il y a beaucoup de ressources à charger, vous avez un moyen d'empêcher l'utilisateur de voir ce qui n'est pas encore chargé. Le moyen le plus courant est les portes et les entrées qui bloquent votre vue dans la zone suivante pendant les quelques secondes cruciales nécessaires au chargement. La plupart des MMO utilisent également des modèles et des textures moins détaillés, ce qui réduit considérablement les temps de chargement.

Certaines choses sont encore imprévisibles, même avec une conception soignée. Par exemple, il peut y avoir des bannières personnalisées portées par les joueurs, qui ne s'affichent qu'une fois que les données pertinentes ont été envoyées à votre ordinateur via le réseau. Bien sûr, la plupart des jeux essaient de limiter cela pour le rendre moins cher (par exemple, les bannières de Diablo III sont des compositions simples, faciles à envoyer avec aussi peu d'octets de données). Mais au final, il suffit parfois d'attendre que les données arrivent. Et vous devez montrer quelque chose pendant que le chargement est en cours - dans de nombreux jeux, cela peut provoquer une interruption de l'immersion lorsque vous voyez un modèle gris peu détaillé affiché en attendant que les données soient chargées.

Et avec tout cela, le chargement comme celui-ci est un problème résolu (TM), mais cela ne le rend pas facile. Cela coûte beaucoup de ressources et de temps, à la fois pour optimiser les ressources et leur utilisation pour assurer une expérience de jeu fluide, et pour le code lui-même - le code asynchrone est difficile. Cela peut également signifier une expérience de jeu réduite même si tout va bien - cela signifie que vous devez vous assurer de ne pas traverser les capacités de bande passante de votre plus petit dénominateur commun, vous devez donc réduire la qualité des modèles et des textures, ou les rendre moins varié, et la géométrie de vos mondes est sévèrement limitée. Si vous ne le faites pas, le jeu sera tout à fait injouable - alors que je me souviens des gens qui ont joué à des jeux qui ont pris 10 minutes (ou même plus!) Pour charger une carte, simplement parce que leur ordinateur n'était pas tout à fait à la hauteur, le jeu lui-même fonctionne bien après cela. S'il avait un chargement transparent à la place, le jeu gèlerait ou afficherait des textures et des modèles moches tout le temps en attendant que les données soient chargées. Le chargement différé n'est pas gagnant-gagnant, c'est un compromis comme la plupart des choses en ingénierie :)

Une raison pour laquelle le chargement dynamique n'est pas toujours la solution idéale que les autres réponses n'ont pas vraiment envisagée, je pense que c'est aussi le pop-in et d'autres artefacts graphiques.

La prédiction de ce qu'il faut charger et de ce qu'il ne faut pas charger échoue souvent, et cela peut être une expérience néfaste lorsqu'elle le fait. L'un des pires exemples de cela était dans Rage by id Software. Au moins dans les premières versions, les systèmes de megatexture ont fait en sorte que même quelque chose comme tourner autour trop rapidement fasse apparaître d'énormes quantités de texture et même des artefacts de géométrie avant de disparaître lentement.

Ces problèmes ne sont tout simplement pas un problème, tout est préchargé.

Quelque chose à considérer n'est pas nécessairement quoi charger, mais quoi décharger. Lorsque vous n'avez qu'un budget limité pour l'espace, lorsque vous chargez de nouvelles choses, quelles sont les anciennes à supprimer? Êtes-vous certain que ces actifs ne seront pas utilisés dans les prochaines secondes? Ce sont des problèmes difficiles à résoudre.

Si chaque état de jeu est suffisamment petit pour tenir dans un budget système commun, alors chaque avantage est apparent, au lieu de charger, vous passez directement à un niveau et les choses se fondent au fur et à mesure que vous jouez. Mais, comme le suggèrent les principales réponses, le temps de chargement d'un petit jeu ne serait pas trop long de toute façon.

Je pense que cela vaut la peine de réfléchir au pourquoi des systèmes de chargement dynamiques ont été créés à l'origine, étant que vous savez que plusieurs de vos états de jeu peuvent être trop grands pour un système commun et qu'un jeu de cette taille n'est tout simplement pas possible de précharger entièrement.

Une raison courante est qu'il n'est pas toujours aussi facile de déterminer si une ressource sera nécessaire dans un avenir proche.

Puisque vous avez utilisé la pagination du terrain comme exemple, je vais continuer avec cela.

Il est parfaitement raisonnable si vous êtes dans une grille de carte donnée de charger toutes les grilles de carte adjacentes en arrière-plan. Vous savez que l'utilisateur peut, au mieux, en saisir un. Quand ils le font, vous pouvez décharger ceux qui ne sont plus adjacents et charger ceux qui le sont maintenant. Vous l'avez noté.

Imaginez maintenant un voyage rapide. Il n'y a absolument aucun moyen de prédire où l'utilisateur peut choisir d'aller. Ils ont (généralement) presque toute la carte à choisir. Le préchargement de tous les emplacements de voyage rapide possibles prendrait beaucoup trop de mémoire (vous pourriez aussi bien charger toute la carte en mémoire en premier lieu) et beaucoup trop de temps (en supposant que vous n'aviez pas la carte entière préchargée). Quand cela arriverait-il? Quand ils ouvrent la boîte de dialogue de voyage rapide? Le problème ne ferait qu'empirer plusieurs fois!

C'est pourquoi même la plupart des jeux avec une pagination de terrain "sans charge" ont toujours des écrans de chargement pour les déplacements rapides. C'est aussi pourquoi, si vous vous déplacez assez vite, vous pouvez parfois déclencher des écrans de chargement même dans des jeux avec des cartes sans charge (je me souviens l'avoir fait dans TES Oblivion).

Imaginez maintenant que cela s'applique aux ressources de jeu en général, où les relations ne sont souvent pas évidentes. Vous finirez par devoir soit charger toutes les options possibles, soit commencer à deviner ce que l'utilisateur va faire. Deviner est coûteux (à la fois en développement et en CPU) et compliqué à programmer. Exemples spécifiques:

• Fichiers de sauvegarde: vous devez charger chaque fichier de sauvegarde avant que l'utilisateur n'atteigne l'écran de sauvegarde, ou deviner quel fichier il pourrait charger (5 derniers, etc.).
• UI: De nombreux jeux de stratégie changent leur UI en fonction de votre faction. Vous devez charger chaque conception d'interface utilisateur possible avant que l'utilisateur ne commence sa partie.
• Monde du jeu: dans les jeux générés de manière procédurale, comme Minecraft ou les jeux RTS comme Civilization, le monde n'existe pas tant qu'il n'est pas vu, à des degrés divers. Le préchargement est impossible car ils n'existaient pas au départ; leur précalcul pourrait au mieux se faire de la même manière que le préchargement et n'est pas applicable dans le cas RTS.

Il pourrait y avoir des moyens de contourner certains de ces problèmes, mais cela coûte de l'argent dans la vie réelle à comprendre. La plupart des joueurs acceptent des écrans de chargement raisonnables et, le cas échéant, ont tendance à vouloir dépenser plus en matériel pour les atténuer. Il est considéré comme un problème matériel , pas un problème de jeu , sauf s'il est inhabituellement excessif ou perturbateur (comme le chargement au milieu des niveaux).

Et gardez à l'esprit que le chargement en arrière-plan n'est pas gratuit. L'utilisation moderne du terrain à chargement en arrière-plan et de certains fichiers de modèle a généralement un impact minimal, mais si vous devinez soudainement de nombreuses ressources différentes, en particulier si vous ne disposez pas de mesures fiables et devez décharger de nombreuses ressources et charger des ressources superflues , vous pouvez transformer le système en poussière.

L'idée du chargement en arrière-plan est d'utiliser les cycles morts pour une meilleure utilisation, mais il n'y a que peu de cycles morts à utiliser. Il en va de même pour la mémoire - le préchargement peut augmenter considérablement l'utilisation de la mémoire d'un jeu. Avec un écran de chargement, vous pouvez vider les ressources existantes. Aucun luxe de ce type avec un chargement en arrière-plan, ce qui signifie qu'il pourrait doubler les besoins en mémoire du jeu sur ce seul plan.

Il s'agit d'un problème courant dû au fait que les jeux sont des produits en temps réel doux, où une livraison tardive de contenu n'est pas aussi utile qu'une livraison à temps (contrairement au temps réel dur, comme les voitures dans les ordinateurs, où une livraison tardive ne peut pas être mieux qu’aucune livraison). Vous devez décider quoi charger et où.

Parfois, les livraisons tardives sont particulièrement mauvaises. Par exemple, si vous êtes autorisé à courir dans un monde avant que tous les murs ne soient chargés, vous pouvez vous placer derrière un mur que vous n'auriez jamais pu atteindre si le jeu avait chargé les murs avant de vous laisser bouger. Il n'est pas toujours facile de dire quand vous pouvez vous en sortir avec un chargement de contenu «paresseux» et quand vous devez garantir que le contenu est entièrement chargé.

Le chargement dynamique est également beaucoup plus compliqué. Vous devez constamment vous demander quoi faire si la ressource n'a pas encore été chargée. C'est une ponction sur les ressources de développement. C'est beaucoup plus facile à développer quand on peut compter sur les ressources pour exister.

Les latences ne sont également pas toujours acceptables. J'ai entendu parler de cas dans Starcraft où vous "réchauffiez" votre jeu en chargeant une carte qui a pour effet secondaire de mettre en cache chaque modèle / image chargé dynamiquement. Vous quitteriez alors et joueriez le jeu normalement. Pour les joueurs d'élite, cela a minimisé le bégaiement de l'interface graphique qui a réellement affecté leur gameplay. Il est difficile de prouver quelles latences seront acceptables pour les utilisateurs et lesquelles ne le seront pas.