Pantalla de carga en Roblox: elige recursos esenciales y explica qué está listo

Define la primera acción del jugador #

Empieza con una acción concreta: el jugador lee el nombre de una ruta de entrenamiento, ve su botón de inicio y entiende adónde conduce. Anota las imágenes y sonidos necesarios para ese momento. Una colección grande de mascotas en una tienda distante todavía no pertenece a la primera pantalla. Una lista enfocada permite discutir la necesidad de cada recurso, en lugar de convertir toda la experience en requisito de una pantalla decorativa.

Nuestro menú ficticio utiliza una ilustración, un icono de botón y un sonido corto. Los nombres illustration, start-icon y first-sound son identificadores didácticos, no asset ID publicados en Roblox. No conectamos imágenes ajenas ni presentamos el ejercicio como una prueba de nuestros cinco juegos. La finalidad es construir un registro honesto de resultados para recursos elegidos antes de integrarlo con descargas reales y una interfaz de usuario.

Separa la carga de contenido de la preparación del juego #

ContentProvider ofrece PreloadAsync para precargar contenido. La referencia indica que el método suspende el hilo que lo llama mientras realiza su trabajo, y sus ejemplos de callback informan un identificador de contenido y AssetFetchStatus. Esas observaciones corresponden al contenido. No confirman por sí solas lectura de partidas guardadas, creación del personaje, disponibilidad del servidor ni todos los objetos del mundo. El inicio necesita pruebas separadas para tareas diferentes.

Escribe por separado lo que el menú requiere de las imágenes seleccionadas y lo que debe ocurrir antes de iniciar la ruta. Un icono disponible con un personaje ausente no demuestra que todo el juego esté cargado. Si solo terminó el registro de una lista, describe esa lista. Nuestro ejercicio utiliza una regla de redacción: el mensaje visible debe nombrar exactamente el resultado que tu sistema puede comprobar, dejando claras las tareas todavía desconocidas.

No conviertas la cola de solicitudes en porcentaje #

RequestQueueSize parece un número práctico para mostrar progreso, pero la guía oficial de rendimiento advierte que la cola fluctúa. No es el denominador fijo de tu tarea. Nuevas solicitudes pueden cambiar su tamaño mientras la observas. Una cola que disminuye no representa automáticamente un porcentaje exacto de preparación del menú ni una prueba fiable de que terminaron todos los recursos necesarios para la acción prevista.

Elige para el ejercicio una lista propia e invariable de tres identificadores distintos. Su tamaño sigue siendo tres antes y después de recibir resultados. La condición importante es conocer la correspondencia entre una entrada y el resultado contado. Contar objetos arbitrarios y después tratar cada callback como un objeto no produce por sí solo un porcentaje válido de una escena completa. El denominador debe describir la misma unidad que realmente estás comprobando.

Construye una lista pequeña de lo necesario #

La guía de rendimiento recomienda precarga selectiva, como imágenes de la pantalla de carga, gráficos esenciales del menú y recursos del área inicial. Señala que precargar todo Workspace es una mala práctica porque aumenta la espera. Asigna a cada recurso un papel: por qué importa ahora, qué ve el jugador sin él y qué comportamiento permites si no está disponible. Esto ayuda más que inventariar todo lo que el juego mostrará alguna vez.

En el menú ficticio, un texto puede sustituir la ilustración, el botón debe conservar una etiqueta legible y la falta de sonido no debe ocultar su significado. Son decisiones de este prototipo que necesitan pruebas con jugadores. No significan que cualquier recurso de cualquier experience sea prescindible. Si un modelo es necesario para iniciar un nivel de forma segura, su preparación constituye otra condición de inicio que una pantalla decorativa no puede reemplazar.

Abrir imagen a tamaño completo ↗

Mantén contadores de resultados distintos #

El ejemplo original en Luau puro guarda total, resolved, succeeded y failed. El primero es el tamaño de la lista, el segundo cuenta resultados recibidos y los otros dos separan éxitos y fallos. La función record acepta un identificador didáctico y un booleano. No llama a una API de Roblox, no descarga archivos ni acepta directamente Enum.AssetFetchStatus. Un adaptador real debe traducir aparte un resultado de carga comprobado al estado necesario.

El ejemplo es un modelo verificable de registro. Tras un fallo y dos éxitos, sus valores son resolved=3, succeeded=2 y failed=1. settled significa que cada entrada tiene un resultado; allSucceeded sigue siendo false en este caso. No combines ambas comprobaciones en una sola palabra como listo. Recibir resultados de tres intentos y obtener correctamente tres recursos son logros diferentes, aunque el número de entradas procesadas sea idéntico.

-- Pure Luau bookkeeping, not a ContentProvider adapter.
-- Each manifest entry represents exactly one distinct content identifier.
local function newTracker(ids)
    assert(type(ids) == "table", "Manifest must be a table")
    local expected = {}
    local total = 0
    for _, id in ipairs(ids) do
        assert(type(id) == "string" and id ~= "", "Invalid content identifier")
        assert(not expected[id], "Duplicate content identifier")
        expected[id] = true
        total += 1
    end
    local entries = 0
    for index in pairs(ids) do
        assert(type(index) == "number" and index >= 1 and index % 1 == 0,
            "Manifest must use consecutive array indices")
        entries += 1
    end
    assert(entries == total, "Manifest cannot contain array gaps")
    local outcomes = {}
    local resolved = 0
    local succeeded = 0
    local failed = 0
    local tracker = {}

    function tracker.record(id, success)
        assert(type(success) == "boolean", "Outcome must be boolean")
        if not expected[id] or outcomes[id] ~= nil then
            return false
        end
        outcomes[id] = success
        resolved += 1
        if success then
            succeeded += 1
        else
            failed += 1
        end
        return true
    end

    function tracker.snapshot()
        return {
            total = total,
            resolved = resolved,
            succeeded = succeeded,
            failed = failed,
            settled = resolved == total,
            allSucceeded = resolved == total and failed == 0,
        }
    end

    return tracker
end

return newTracker

Evita que un resultado repetido cambie el registro #

Si el manejador vuelve a recibir un resultado para start-icon, los contadores no deben avanzar otra vez. Un éxito repetido por accidente tampoco debe sobrescribir un fallo registrado. Nuestro modelo acepta solo el primer resultado de cada identificador conocido e ignora mensajes ajenos. Es la política de un intento didáctico. Una descarga repetida deliberadamente necesita otro intento y una decisión explícita sobre cómo actualizar el estado y presentar el historial.

Valida la lista antes de empezar: los identificadores deben ser cadenas únicas y no vacías, y la tabla debe formar un array consecutivo sin huecos. De lo contrario, ipairs puede detenerse antes de lo esperado y producir un denominador incorrecto. Cada snapshot devuelto es una tabla nueva; editar sus campos no cambia el modelo interno. Estas restricciones se comprueban por separado. Superarlas no establece el comportamiento de la red ni del motor de Roblox.

Abrir imagen a tamaño completo ↗

Explica el fallo con un mensaje comprensible #

Separa el mensaje de progreso del mensaje de resultado. Procesados 2 de 3 recursos elegidos describe el registro; un recurso no se obtuvo describe un desenlace. No escribas todo cargado cuando failed sea mayor que cero. No inventes una duración restante exacta sin medirla. Un siguiente paso comprensible aporta más que una barra suave que esconde la parte desconocida del estado y da una impresión equivocada de certeza.

Para el menú ficticio proponemos una etiqueta legible en lugar de una imagen ausente y un aviso separado sobre el sonido. La revisión del prototipo debe comprobar si el destino y la acción inicial siguen siendo claros. Los objetos importantes para jugar necesitan otra respuesta: explicar la limitación y ofrecer una salida o un reintento permitido. No prometas que volver a intentar funcionará. Un fallo puede exigir revisar el identificador y acceso, no repetir solicitudes indefinidamente.

Continuar no debe fingir que cancela la descarga #

La guía oficial recomienda una opción Skip Loading cuando se necesita cargar muchos recursos. Define qué significa el control en tu prototipo: cerrar una pantalla decorativa y continuar con una sustitución disponible, o entrar en un menú limitado. La etiqueta debe corresponder a la acción. Esa recomendación no demuestra que pulsar el botón cancele automáticamente una llamada PreloadAsync en curso ni que convierta sus recursos en cargas exitosas.

Si llega un resultado después de cerrar el panel, su manejador debe actualizar el estado correctamente sin devolver al jugador a la pantalla de carga. Conectar una GUI concreta al ciclo de las solicitudes requiere otra prueba. Nuestro modelo puro no crea una GUI ni implementa el botón para omitir. Enseña los datos necesarios para decidir, pero no es un sistema terminado de cancelación, reintentos o transiciones de pantalla aplicable a todos los juegos.

Prueba el registro y la integración por separado #

Primero comprueba el modelo con eventos artificiales: identificador desconocido, repetición, fallo, dos éxitos en otro orden y una lista pendiente. Importan los contadores exactos y la ausencia de un allSucceeded falso. Las comprobaciones autónomas pueden ejecutarse sin conexión de red. Solo demuestran la lógica elegida para el ejemplo. Los nombres de las pruebas y sus informes deben conservar esa frontera, para que una prueba de tablas no parezca una prueba de un cargador real.

Después, un proyecto didáctico separado necesita recursos propios autorizados, observación de estados reales y pruebas de menú en los dispositivos previstos. Registra identificadores, entorno, cada resultado y disponibilidad de una acción ordinaria. Examina aparte contenido no disponible y un panel cerrado. Esa integración todavía no se realizó para este artículo. No se midieron duración de carga, cambios de memoria ni efectos sobre retención, y no pueden deducirse de las pruebas del registro.

Conserva una conclusión reproducible #

Una conclusión útil contiene la lista pequeña, motivos de selección, diferencia entre resolved y succeeded, comportamiento cuando failed no es cero y límite de preparación de la pantalla. El registro de dos éxitos y un fallo debe preservar el fallo expresamente. Para una lista vacía, el modelo no divide entre cero: informa de un estado resuelto sin recursos. Explica ese caso con palabras, en vez de mostrar un porcentaje indefinido.

Antes de adaptar la idea a un juego real, entrega a otro desarrollador el código, las comprobaciones autónomas y las condiciones todavía sin verificar. No agregues el mundo completo a la precarga solo para enseñar un bonito 100%. La primera pantalla debe hacer comprensible la acción prevista y describir honestamente su estado. El artículo y el modelo didáctico son originales; revisa los detalles actuales de API en las fuentes oficiales y mide los resultados del juego concreto por separado.