Si durante los últimos veinte años los proyectos Unity han empaquetado por defecto el «contenido que viaja fuera del Player» en AssetBundles indivisibles—donde un error de layout castiga a la vez el tamaño de descarga, los picos de memoria y las esperas de carga—entonces el 22 de septiembre de 2026 la entrada oficial de George Ing, Senior Engineering Manager de Unity, extendió esa factura de veinte años sobre la mesa y rodeó con bolígrafo rojo otra línea al pie de la hoja de laboratorio de un socio. El título es *Slime Rancher 2* de Monomi Park. Editor Unity 6.6 Beta (6000.6.0b10), máquina un MacBook Pro M5 Max. El mismo proyecto Addressables, backend cambiado de AssetBundle a content directory; Unity habla de cero cambios de código. La build incremental cayó de 32 minutos 16 segundos a 3 minutos 4 segundos. La clean build, de 58 minutos 6 segundos a 37 minutos 13 segundos. El tamaño del Player, de 4 GB a 2,88 GB—unos 1,12 GB menos. La carga de arranque a menú a jugabilidad, de 45 segundos a 30.
Crucé la entrada oficial, la introducción del manual de Unity 6.6 y un resumen técnico que seguía circulando ese día. Los números y mecanismos de abajo salen de materiales públicos. Este ensayo no tiene acceso al código del proyecto ajeno y no finge ser un informe de playtest.
Las imágenes que atraviesan el texto son esa factura incremental de treinta y tres minutos y el «paquete indivisible». Suenan a formato de archivo; como ética de producción son una negativa a seguir pagando impuestos por adivinar layouts. Primero haz que los artefactos se puedan cargar y descargar por separado; después discute lo bonito de los grupos. Los minutos y gigabytes ahorrados deben dejar prueba. La línea cara debe nombrarse—no atribuirse por costumbre a que «los grupos de Addressables aún no están bien dibujados».
1. Veinte años de default: el contenido es un paquete indivisible
Desde Unity 2.1, AssetBundle sostiene el contenido fuera del binario del Player. Durante veinte años un número extraordinario de juegos lo usó como representación de datos, incluidos títulos grandes. La especificación básica es dura. Cada Bundle es una unidad indivisible para distribución, almacenamiento y carga. Las dependencias se rastrean a nivel de Bundle, así que muchos assets se sueldan en monolitos mayores que, por eficiencia, suelen descargarse, cargarse y descargarse juntos.
Esa especificación empuja una gramática de producción casi inevitable. Cómo un título corta el layout de Bundles presiona directo sobre el runtime y el tamaño de descarga—tanto si usas AssetBundles a pelo como vía Addressables. Los equipos aprenden a dibujar grupos en el editor, a adivinar co-ubicación y a temer que «cambiar una textura arrastre medio mundo». Jugadores y desarrolladores leen tirones y tamaño de paquete con el mismo vocabulario: grupos demasiado gruesos, cadenas de dependencia demasiado largas, una hot update que baja demasiado. Ese entendimiento mutuo convierte «seguir dibujando un mejor mapa de grupos» en una inercia de producción perdonable.
Títulos como *Slime Rancher 2*—ya publicados, ya en Addressables—suben el coste de esa inercia a cifras concretas. El contenido ya es grande. Las builds incrementales pasan a menudo de media hora. El Player ya ronda los 4 GB. Del arranque al juego real aún cuesta una carga medida en tres cuartos de hora. El default pregunta cómo cortar grupos más finos y adivinar mejor la co-ubicación. Ellos preguntaron si, cuando el contenido local que viaja con el Player ya es tan grande, la unidad indivisible misma está cobrando impuestos en cada build y cada entrada a jugabilidad, y si lo que debe llegar al runtime son solo artefactos identificables por separado.
La bifurcación está aquí. Seguir puliendo el layout de Bundles es buscar asientos más baratos dentro del impuesto ciudadano. Cambiar la unidad de carga es admitir que la partida fiscal estaba mal escrita.
2. Artefactos independientes, stable id y tabla de hashes de contenido
Unity 6.6 escribe content directories como ruta alternativa a los AssetBundles entregados en local con el Player. Clava la redacción. Es una ruta alternativa, no un aviso de retiro de AssetBundles. La documentación dice que las builds de content directory solo soportan contenido local por ahora y no la distribución remota. El OTA de grano fino se deja para la generación Unity 7. En remoto, AssetBundles siguen siendo usables.
En el mecanismo, se niegan a seguir horneando assets en unidades de carga grandes. El runtime puede identificar, cargar y descargar artefactos individuales—mallas, texturas y el resto—con deduplicación implícita. Para proyectos que ya usan Addressables con contenido empaquetado con el Player, Unity dice que puedes pasar al backend de content directory con cero cambios de código. Los números del socio con *Slime Rancher 2* van por ese camino.
El build corre dentro del marco del asset importer. Cada asset lo construye un importer, aislado, fuera de proceso, determinista, con caché de asset database, saturación multi-núcleo y cachés compartidas del accelerator. George Ing lo dice claro: es la misma base anunciada como pipeline de build multiproceso en Unity 2023.1. La salida es un conjunto suelto de artefactos de grano fino, un manifiesto pequeño que rastrea dependencias y archivos de diagnóstico más legibles.
El direccionamiento parece git. Abres el build y los nombres de archivo son hashes de contenido. Nombres como `c0152db4dd710be51b2decb997325f34.cf` están addressados por contenido, no son aleatorios. El runtime puede deduplicar contenido idéntico de forma nativa. Pero si los artefactos se referencian por hash de contenido, al actualizar B cambia el hash de B, el de A tiembla cuando A referencia B, y la cascada sube la cadena. Content directories lo resuelve referenciando por stable id. El manifiesto guarda una tabla pequeña que mapea stable ids a hashes de contenido. Identidad estable y huella de contenido se separan; el churn en cascada se corta.
La carga monta el directorio, lee el manifiesto, resuelve dependencias por stable id entre artefactos y deja que cada uno se cargue y descargue solo. Lectura y deserialización asíncronas en paralelo, usando las APIs de lectura asíncrona de la plataforma. El formato inferior es la siguiente generación del content file format introducido con DOTS, llevando la carga multihilo de Entities a más tipos de asset. El motor también gana un tipo de referencia loadable moderno, `Loadable<T>`. El ejemplo es corto.
`Loadable<Mesh> bodyMesh;``bodyMesh.Load();`
Un Loadable mete el objeto en el build pero no lo carga hasta que llamas Load. Junto a la organización familiar con ScriptableObject, el contenido dinámico ya no tiene que diseñarse alrededor del mapa de layouts de Bundles. Piezas de un creador de personajes, chunks de terreno en streaming: cada uno puede ser una unidad de carga independiente.
3. Cuatro filas en la hoja del socio y los quince segundos que faltan al entrar a jugar
Los números sujetan la retórica. La tabla pública de Unity solo tiene cuatro filas, y bastan.
Build incremental: Addressables con backend AssetBundle a 32 minutos 16 segundos; tras pasar a content directory, 3 minutos 4 segundos—unos veintinueve minutos menos. Clean build: 58 minutos 6 segundos a 37 minutos 13 segundos. Tamaño del Player: 4 GB a 2,88 GB. Arranque a menú a jugabilidad: 45 segundos a 30. Los jugadores tocan los quince segundos que faltan. La tienda y el disco tocan el 1,12 GB que falta. El calendario de producción toca los veintinueve minutos incrementales que faltan.
Las condiciones también están fijadas. Unity Editor 6000.6.0b10, MacBook Pro M5 Max, proyecto Addressables existente, cambio de backend, cero cambios de código. Es una comparación donde cambió la unidad de carga y la superficie de Addressables aún podía hablar. No es una historia de victoria por reescribir el pipeline de contenido en tres meses. Para equipos pequeños, esa segunda lectura corta más. Puede que no convenzas a un productor de abrir una ventana de tres meses; a menudo sí puedes convencerle de cambiar un ajuste de backend y pegar los logs de build en el informe semanal.
Hay que dejar clara la frontera. El corte de 6.6 apunta al contenido local que viaja con el Player. Hot updates remotas, diffs de CDN y fetch bajo demanda Unity los deja para la generación Unity 7 y 2027. El boceto futuro es un manifiesto pequeño guiado por hashes que nombra exactamente qué artefactos faltan en el dispositivo, descarga solo esos y actualiza a grano de artefacto. Leer la entrada como «AssetBundles ya se pueden tirar» sesga la afirmación. El contenido local empaquetado con el Player tiene una ruta alternativa. Lo remoto aún puede viajar por Bundle. El «local only» de la documentación es una frontera.
Cierre: independencia es querer clavar el cuello de botella en la unidad de carga
Devuelve esta entrada de septiembre al otoño de 2026 en el suelo indie y de equipos medianos de Unity, y lo primero que golpea es una inercia de producción callada. Se asume que el contenido es un paquete indivisible. Que builds atascadas, paquetes atascados y entradas a jugabilidad atascadas son culpa de grupos de Addressables mal dibujados. Que «otra reunión de layout» basta. Pocos preguntan si, cuando el contenido local ya son varios gigabytes, el impuesto ciudadano ya cuesta más que la estética de agrupación; si una build incremental de treinta y tres minutos es cara por la potencia de la máquina o porque la unidad de carga obliga a recalcular el paquete entero.
Para equipos pequeños el material es especialmente útil. No necesitas un rancho a escala *Slime Rancher 2* ni un M5 Max. Sí tienes tu lista de «el default ya alcanza». Contenido local aún co-ubicado en Bundles gruesos. Una reunión de optimización que abre con «corta los grupos otra vez». Un paquete de hot update que baja medio mundo porque la co-ubicación se adivinó mal. Una incremental de media hora donde nadie se atreve a proponer cambio de backend. Docs que dicen local only mientras el informe semanal afirma que lo remoto también quedó resuelto. George Ing y la hoja del socio escriben el coste en tierra: cambio a cero código, comparación de cuatro filas, stable id frente a hash de contenido, cargas explícitas con Loadable. Lo caro es querer clavar el cuello de botella otra vez en la unidad de carga, y admitir en el recibo que la ruta alternativa local ya abrió mientras el billete remoto se compra aparte.
Las notas ejecutables son cortas.
- Separa si el dolor es contenido local con el Player o hot update remota. Content directories en 6.6 solo cubren lo primero.
- Si ya usas Addressables y el contenido viaja con el Player, prueba el cambio oficial al backend de content directory y guarda logs de antes y después.
- Anota al menos cuatro filas: incremental, clean, tamaño del Player, arranque a jugabilidad. Sin números, cambiar de backend es ambiente.
- Abre la salida del build y confirma nombres por hash de contenido y la tabla stable id según la documentación. El churn en cascada es el impuesto viejo; la tabla es el recibo nuevo.
- Prefiere cargas explícitas con `Loadable<T>` en contenido nuevo; no sueldes «en memoria» a una unidad grande.
- Prohíbe «AssetBundles están retirados» en el informe semanal. La frase correcta es ruta alternativa local. La estrategia remota es otro ticket.
- Trata el OTA de grano fino de Unity 7 / 2027 como prospectiva, no como promesa de entrega actual.
Treinta y dos minutos dieciséis segundos de incremental, un paquete indivisible, una tabla de stable id a hash de contenido, y los quince segundos que faltan a una entrada a jugabilidad de cuarenta y cinco. Antes de que el copy de tienda convierta «más rápido y más pequeño» en eslogan, producción ya escribió el estándar de auditoría en una entrada pública. Devuelve los artefactos a unidades de carga independientes primero; después clava el cargo en la unidad de carga correcta.
Fuentes y lecturas
- George Ing, Unity Blog (2026-09-22), Content Directories Beyond the AssetBundle (https://unity.com/blog/content-directories-beyond-the-assetbundle)
Unity Manual 6.6 Introduction to content directories
Comprobación de resumen Unity Content Directories × Slime Rancher 2