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

23

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?

Visir
fuente
16
Tenga en cuenta que en muchas 'sin fisuras' juegos de mundo abierto, no son los tiempos de carga cuando el jugador se mueve a un lugar impredecible. Uno puede caminar desde un extremo de Nueva York al otro en The Division sin tener que ver una pantalla de carga, mientras que el viaje rápido a un lugar requiere carga. Se trata de saber qué cargar a continuación.
Felsir
2
@Felsir Dungeon Siege lo hizo de la misma manera.
Mason Wheeler
Como ejemplo, Batman Arkham Origins usa pantallas de carga justo antes de las escenas de corte y al ingresar a áreas completamente nuevas. Su naturaleza progresiva basada en la historia se presta bien y le da al usuario un descanso natural. Esto funciona especialmente bien debido a las áreas muy expansivas con activos de muy alta definición. Sería muy lento codificar y probar esta función para obtener pocos beneficios.
Casey Kuball
eleva tu RAM hasta 128 gb. Cree una unidad de RAM de 64 gb más o menos, cargue su juego en la unidad de RAM. Los tiempos de carga serán tan rápidos que apenas los notará. Actualicé a un SSD y la mayoría del tiempo de carga se acortó dramáticamente. Actualización de la tarjeta de video, especialmente a más RAM de video.
cybernard
La carga asincrónica lleva tiempo, que puede variar según la CPU y la velocidad del disco. No siempre puede estar seguro de que las cosas se cargarán cuando las necesite.
Alan Wolfe

Respuestas:

31

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".
Peter - Unban Robert Harvey
fuente
Como seguimiento al punto de "equilibrio de la carga del servidor", muchos juegos en línea que llegan al mercado hoy cuentan con un área central de "concentrador" que es exclusiva para usted y que nadie más puede acceder. Muy a menudo, estas áreas se colocan detrás de una zona de carga o un área de caminata lenta (por ejemplo, el BOO en 'The Division') para que puedan sacarlo de la instancia en la que estaba anteriormente y ubicarlo en su propia instancia privada .
SGR
77
También está el problema de la memoria. Es posible que no sea posible cargar un nivel existente mientras se mantiene el actual en la memoria (particularmente para consolas o dispositivos portátiles), por lo que debe usar una pantalla de carga
Jezzamon
@Jezzamon Creo que la totalidad del mapa de Skyrim nunca se guarda en la memoria en ningún momento dado. ¿Puede ser que esté equivocado? Pero si no, ¿por qué cualquier otra situación sería inaplicable con las estrategias de carga dinámica de los mapas masivos de juegos de mundo abierto?
Viziionario
Prácticamente ya nadie lanza su propio motor de juego desde cero. Compran un motor (Unreal, Unity, CryEngine) y un montón de middleware y lo pegan. Los motores base generalmente no están configurados para transmitir contenido de forma continua, o para reiniciar sin volver a cargar. Piensa en cuántas veces has muerto en un juego solo para enfrentarte a un tiempo de carga de 60 segundos, a pesar de que los activos y el nivel ya estaban cargados. Las razones que dio @Peter también son las razones por las que no ve los juegos que le permiten comenzar a jugarlos mientras todavía descarga los activos con mucha frecuencia.
Tom B
2
@Viziionary Levels normalmente reutiliza muchas texturas, y un nivel diferente usa un conjunto diferente de texturas. Un nivel de mazmorra usará muchas texturas de pared de mazmorra, un nivel del desierto usará texturas de arena y rocas del desierto, un nivel de montaña usará texturas de roca, hierba y nieve, etc. Para juegos donde esto es cierto, descargar medio nivel cuando sea Las texturas que se utilizan en todo el nivel solo liberarán una pequeña fracción de la memoria utilizada (o descargarán las texturas que aún necesita).
Peter - Unban Robert Harvey
10

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.

Almo
fuente
¿Por qué no priorizar la carga del menú pesado / de acceso frecuente? En cualquier juego de rol, si abro el menú, es 90% del tiempo equipar algo que encontré o usar un elemento. Podrías comenzar por este menú. O comience con el menú que tarda 5 minutos en cargar, y suelte la carga si el usuario sale del menú.
DrakaSAN
1
@DrakaSAN Pero eso está a menudo optimizado. Incluso el Diablo original te mostró el inventario en la caída del sombrero. El enfoque de "esperar para todo" parece haber tenido un gran resurgimiento con las consolas modernas, que tenían muy poca memoria en comparación con una PC. Y dado que muchos juegos que están tanto en la PC como en la consola son portados consola-> PC, algunas limitaciones de la consola se heredan en el proceso. Compare Diablo III o Divinity con Skyrim o Dark Souls: las diferencias son bastante obvias.
Luaan
2
¿Los menús de carga lenta son un problema real en los juegos? No.
Alan B
@AlanB solo si la única forma de acceder a los consumibles es a través de ese menú. Vea Destiny en Xbox 360 / PS3 y cuánto tiempo lleva usar un paquete de munición en comparación con las versiones XB1 / PS4.
SGR
1
@SGR Estaba a punto de usar Destiny en PS4 como ejemplo de un menú con tiempos de carga inaceptablemente largos, no puedo imaginar cuánto peor es en las consolas de última generación.
IllusiveBrian
5

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 .

Jibb Smart
fuente
3
Jak y Daxter tienen tiempos de carga. Están escondidos detrás de las puertas, en un método similar a los ascensores ME1 y cómo ocultan los tiempos de carga.
Nzall
2
Sin embargo, los tiempos de carga ocultos detrás de las salas de la curva S y como no se sienten como los tiempos de carga.
Almo
Si entiendo bien, los mapas de mundo abierto como Skyrim no se cargan en la memoria, solo las piezas que el usuario necesita ver de inmediato, así que ¿no podría cargar previamente en pequeñas porciones iniciales de todos los mapas (20?)? Con la optimización adecuada de los datos del mapa, parece que la RAM real utilizada no es un gran problema en términos de cantidad de RAM moderna, incluso en dispositivos móviles. Creo que es el poder de renderizado de la tarjeta de video lo que obstaculiza la mayoría de los juegos. Simplemente parece que podrías cargar las áreas de inicio de todos esos mapas de halo para el usuario, luego renderizar el seleccionado mientras se deja el resto de la memoria.
Viziionario
1
Los mapas no son lo que tarda una eternidad en cargar: son las texturas enormes, los archivos de modelo, los programas de sombreado, etc. que son específicos de un nivel o área.
Tom B
3

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.

Vaillancourt
fuente
2

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 :)

Luaan
fuente
2

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.

Waddles
fuente
2

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.


fuente
1

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.

Cort Ammon - Restablece a Monica
fuente