¿No podrían todos los juegos evitar la carga posterior al inicio?

Al igual que los juegos gigantes de mundo abierto cargan mapas masivos dinámicamente, ¿no podríamos cargar mapas, menús y prácticamente cualquier interfaz o configuración 3D a través del mismo método de carga dinámica? Sin cambiar el entorno, parece que las interfaces y varias ubicaciones dentro del juego podrían cargarse dinámicamente de la misma manera que se cargan mapas masivos de mundo abierto mientras los recorres.

¿Por qué no se hace esto? Veo muchos juegos modernos en los que tienes que esperar un minuto o más mientras se carga el partido / mapa / nivel. Sé que hay una latencia involucrada con la conexión de pares, pero eso no toma más de unos momentos en mi experiencia. ¿Qué problemas existen con este concepto para evitar que se use para eliminar el tiempo de carga relacionado con la carga de datos de mapa / nivel / interfaz?

La respuesta es sí, esto podría hacerse, en la mayoría de los casos, al menos en cierta medida.

Las razones por las que no se hace son muchas:

• Se requiere tiempo y dinero para hacerlo bien.
• La cantidad de errores que pasan las pruebas será mayor
• Los tiempos de carga son aceptados por los usuarios.
• Puede haber otras razones para los tiempos de carga, como el equilibrio de la carga del servidor.
• Las soluciones genéricas que se pueden comprar en el estante son más compatibles con "cargar todo de una vez".

Si sus menús tienen una tonelada de activos, esos activos tardan en cargarse. Tampoco tiene idea de en qué orden las personas navegarán por su menú. Podrían hacer clic en opciones -> atrás -> créditos, o créditos -> atrás -> iniciar el juego en rápida sucesión. Por lo tanto, no hay una estrategia de transmisión razonable.

En un juego de mundo abierto, sabes que el jugador no se moverá más rápido que cierta velocidad, por lo que sabes que no necesitas cargar las versiones detalladas de ubicaciones lejanas hasta que se acerquen a ellas.

Un factor importante en la viabilidad de tal solución es la previsibilidad de lo que necesita cargarse. Si el jugador carga niveles completamente nuevos sin forma de anticipar lo que elegirá, simplemente no es posible una solución completamente integrada. Por ejemplo, cuando el jugador puede seleccionar cualquier nivel del juego para jugar, o si tiene libertad para teletransportarse a áreas completamente diferentes en juegos de mundo abierto.

Algunos juegos de Halo comienzan a cargar el nivel seleccionado en segundo plano mientras configuran juegos multijugador. Esto reduce el tiempo de espera cuando los jugadores están listos para comenzar, y es probablemente lo más cercano que se puede llegar a tal solución cuando el jugador puede elegir libremente diferentes niveles con activos completamente diferentes.

Por supuesto, dijiste "sin cambiar el entorno", pero solo quería mencionar el ejemplo de Halo , ya que es algo de lo que me gustaría ver más.

Dentro de una campaña continua, o cuando el desarrollador tiene mucho control sobre la ubicación del jugador, tal solución es ciertamente viable, tal como usted dice. A Naughty Dog le gusta eliminar los tiempos de carga, ya que Jak y Daxter no tienen tiempos de carga en la PS2, y los juegos de Uncharted tienen un solo tiempo de carga al principio.

Sin embargo, para muchos, el tiempo de carga no es un problema que deba resolverse . O es un problema que es muy bajo en las prioridades de los desarrolladores, cuando siempre se puede hacer más entre ahora y la fecha de lanzamiento .

Hora.

Necesitas tiempo para ahorrar tiempo. O necesita dinero para compensar la falta de tiempo. En cualquier caso, "¡Sin tiempo de carga!" es una característica que solo aquellos que tienen el lujo de pagar pueden ofrecer. Se necesita una planificación muy cuidadosa, y debes comprender muy bien lo que estás haciendo y no todos los desarrolladores de juegos tienen los recursos para hacerlo.

En definitiva, son recursos limitados.

Los juegos de mundo abierto y especialmente los MMO están muy diseñados para la previsibilidad: siempre sabes con anticipación qué datos necesitas cargar. Puedes ver esto en la arquitectura de los mundos: cada vez que hay muchos recursos que deben cargarse, tienes alguna forma de evitar que el usuario vea las cosas que aún no están cargadas. La forma más común son las puertas y entradas que bloquean su vista en la siguiente área durante los pocos segundos cruciales necesarios para la carga. La mayoría de los MMO también usan modelos y texturas menos detallados, lo que acorta considerablemente los tiempos de carga.

Algunas cosas aún son impredecibles, incluso con un diseño cuidadoso. Por ejemplo, puede haber pancartas personalizadas usadas por los jugadores, que solo se muestran una vez que los datos relevantes se han enviado a su computadora a través de la red. Por supuesto, la mayoría de los juegos intentan limitar esto para hacerlo más barato (por ejemplo, los banners de Diablo III son composiciones simples, fáciles de enviar con pocos bytes de datos). Pero en última instancia, a veces solo tienes que esperar a que lleguen los datos. Y debe mostrar algo mientras la carga está en progreso; en muchos juegos, esto puede causar una interrupción en la inmersión al ver un modelo gris de bajo detalle que se muestra mientras espera que se carguen los datos.

Y con todo esto, cargar así es un problema resuelto (TM), pero eso no lo hace fácil. Cuesta muchos recursos y tiempo, tanto en la optimización de los recursos y su utilización para garantizar una experiencia de juego fluida, como en el código en sí mismo: el código asincrónico es difícil. También puede significar una experiencia de juego reducida, incluso si todo sale bien; significa que debes asegurarte de no cruzar las capacidades de ancho de banda de tu denominador común más bajo, por lo que debes reducir la calidad de los modelos y texturas, o hacerlos menos variada, y la geometría de sus mundos está severamente limitada. Si no lo hace, el juego será bastante imposible de jugar, aunque recuerdo personas que jugaron juegos que tardaron 10 minutos (¡o incluso más!) En cargar un mapa, simplemente porque su computadora no estaba a la altura de la tarea, el juego en sí funciona bien después de eso. Si se cargara sin problemas, el juego simplemente se congelaría o mostraría texturas y modelos feos todo el tiempo mientras espera que se carguen los datos. La carga diferida no es beneficiosa para todos, es una compensación como la mayoría de las cosas en ingeniería :)

Una razón por la que la carga dinámica no siempre es la solución ideal que otras respuestas realmente no han considerado, creo que también es pop-in y otros artefactos gráficos.

La predicción de qué cargar y qué no cargar a menudo falla, y puede ser una experiencia perjudicial cuando lo hace. Uno de los peores ejemplos de esto fue en Rage by id Software. Al menos en las primeras versiones, los sistemas de megatexture lograron que incluso algo como girar demasiado rápido produjera enormes cantidades de textura e incluso artefactos geométricos antes de desaparecer lentamente.

Estos problemas simplemente no son un problema si todo está precargado.

Algo a considerar no es necesariamente qué cargar, sino qué descargar. Cuando solo tienes tanto presupuesto para espacio, cuando cargas cosas nuevas, ¿cuáles son las viejas para eliminar? ¿Qué tan seguro está de que esos activos no se utilizarán en los próximos segundos? Estos son problemas difíciles de resolver.

Si cada estado de juego es lo suficientemente pequeño como para caber dentro de un presupuesto común del sistema, entonces todas las ventajas son evidentes, en lugar de cargar, simplemente vas directamente a un nivel y las cosas se desvanecen a medida que juegas. Pero, como sugieren las respuestas principales, el tiempo de carga para un juego pequeño no sería demasiado extenso como para preocuparse de todos modos.

Creo que vale la pena pensar en el razonamiento por el que los sistemas de carga dinámica se crearon originalmente, ya que sabes que varios de tus estados de juego pueden ser demasiado grandes para un sistema común y un juego de ese tamaño simplemente no es posible precargarlo por completo.

Una razón común es que no siempre es igualmente fácil determinar si un recurso será necesario en el futuro cercano.

Como usó la paginación del terreno como ejemplo, continuaré con eso.

Es perfectamente razonable si está en una cuadrícula de mapa dada para cargar todas las cuadrículas de mapa contiguas en segundo plano. Usted sabe que el usuario puede, en el mejor de los casos, ingresar uno de esos. Cuando lo hacen, puede descargar los que ya no están adyacentes y cargar los que ahora están. Esto lo has notado.

Ahora imagine un viaje rápido. No hay absolutamente ninguna manera de predecir dónde puede elegir ir el usuario. Tienen (generalmente) casi todo el mapa para elegir. La precarga de todos los posibles lugares de viaje rápido requeriría demasiada memoria (en primer lugar, también podría cargar todo el mapa en la memoria) y demasiado tiempo (suponiendo que no tuviera todo el mapa precargado). ¿Cuándo pasaría esto? ¿Cuándo abren el diálogo de viaje rápido? ¡El problema solo empeoraría varias veces!

Es por eso que incluso la mayoría de los juegos con paginación de terreno "sin carga" todavía tienen pantallas de carga en viajes rápidos. También es por eso que, si te mueves lo suficientemente rápido, a veces puedes activar pantallas de carga incluso en juegos con mapas sin carga (recuerdo haberlo hecho en TES Oblivion).

Ahora imagine que esto se aplica a los recursos del juego en general, donde las relaciones a menudo no son obvias. Tendrá que cargar todas las opciones posibles o comenzar a adivinar lo que el usuario va a hacer. Adivinar es costoso (tanto en desarrollo como en CPU) y un desorden complejo para programar. Ejemplos específicos:

• Guardar archivos: necesitaría cargar todos los archivos guardados antes de que el usuario llegue a la pantalla de guardar, o adivinar qué archivo podrían cargar (últimos 5, etc.).
• Interfaz de usuario: muchos juegos de estrategia cambian su interfaz de usuario dependiendo de tu facción. Tendría que cargar todos los diseños de interfaz de usuario posibles antes de que el usuario comenzara su juego.
• Mundo del juego: en los juegos generados por procedimientos, como Minecraft o juegos RTS como Civilization, el mundo no existe hasta que se ve, en mayor o menor medida. Precargar esto es imposible ya que no existían para empezar; calcularlos previamente podría, en el mejor de los casos, hacerse de manera similar a la carga previa, y no es aplicable en el caso de RTS.

Puede haber formas de solucionar algunos de estos problemas, pero eso cuesta dinero de la vida real . La mayoría de los jugadores aceptan pantallas de carga razonables y, en todo caso, tienden a estar dispuestos a gastar más en hardware para mitigarlos. Se ve como un problema de hardware , no un problema de juego , a menos que sea inusualmente excesivo o perjudicial (como cargar en el medio de los niveles).

Y tenga en cuenta que la carga en segundo plano no es gratuita. Por lo general, el uso moderno del terreno de carga en segundo plano y algunos archivos de modelo tiene un impacto mínimo, pero si de repente está adivinando sobre muchos recursos diferentes, especialmente si no tiene métricas confiables y tiene que descargar muchos recursos y cargar superfluos , puede moler el sistema en polvo.

La idea de cargar en segundo plano es usar los ciclos muertos para un mejor uso, pero solo hay tantos ciclos muertos para usar. Lo mismo ocurre con la memoria: la precarga puede aumentar sustancialmente el uso de memoria de un juego. Con una pantalla de carga, puede volcar los recursos existentes. No existe ese lujo con la carga de fondo, lo que significa que podría duplicar el requisito de memoria del juego solo en ese aspecto.

Este es un problema común derivado del hecho de que los juegos son productos blandos en tiempo real, donde una entrega tardía de contenido no es tan útil como una entrega a tiempo (contraste con el tiempo real difícil, como los autos en las computadoras, donde una entrega tardía no puede ser mejor que ninguna entrega). Tienes que decidir qué cargar y dónde.

A veces, las entregas tardías son particularmente malas. Por ejemplo, si se te permite correr en un mundo antes de que se carguen todas las paredes, puedes ponerte detrás de una pared que nunca podrías haber atrapado si el juego cargara las paredes antes de permitirte moverte. No siempre es fácil saber cuándo puede salirse con la suya con una carga de contenido "perezosa" y cuándo debe garantizar que el contenido esté completamente cargado.

La carga dinámica también es mucho más complicada. Debe considerar constantemente qué hacer si el recurso aún no se ha cargado. Esto es una pérdida de recursos para el desarrollo. Es mucho más fácil de desarrollar cuando puede confiar en los recursos que existen.

Las latencias tampoco son siempre aceptables. He oído hablar de casos en Starcraft en los que "calentarías" tu juego al cargar un mapa que tiene el efecto secundario de almacenar en caché cada imagen / modelo cargado dinámicamente. Entonces saldrías y jugarías el juego normalmente. Para los jugadores de élite, esto minimizó el tartamudeo de la GUI que realmente afectó su juego. Intentar probar qué latencias serán aceptables para los usuarios y cuáles no lo es es complicado.