{"id":75516,"date":"2025-11-28T20:27:37","date_gmt":"2025-11-29T01:27:37","guid":{"rendered":"https:\/\/niixer.com\/?p=75516"},"modified":"2025-11-28T21:21:46","modified_gmt":"2025-11-29T02:21:46","slug":"desarrollo-y-optimizacion-niveles-unity","status":"publish","type":"post","link":"https:\/\/niixer.com\/index.php\/2025\/11\/28\/desarrollo-y-optimizacion-niveles-unity\/","title":{"rendered":"Souls Like: Desarrollo de un Videojuego en Unity"},"content":{"rendered":"\n

Importancia de la optimizaci\u00f3n en el desarrollo de videojuegos<\/strong><\/h3>\n\n\n\n

Durante la fase de preproducci\u00f3n y preparaci\u00f3n t\u00e9cnica para el desarrollo de nuestro videojuego, fue necesario realizar una investigaci\u00f3n exhaustiva sobre las estrategias de optimizaci\u00f3n aplicables tanto a dispositivos m\u00f3viles como a sistemas Windows. La necesidad de optimizar surge no solo por la diversidad del hardware, sino tambi\u00e9n por las limitaciones inherentes a cada plataforma. Los dispositivos m\u00f3viles, por ejemplo, suelen contar con procesadores menos potentes, memoria restringida y limitaciones t\u00e9rmicas m\u00e1s estrictas. En contraste, Windows ofrece mayor capacidad, pero exige una correcta administraci\u00f3n de recursos para mantener altas tasas de fotogramas y evitar cuellos de botella. Por esta raz\u00f3n, la optimizaci\u00f3n se convierte en un requisito fundamental para asegurar una experiencia de juego fluida, estable y eficiente.<\/p>\n\n\n\n

Modularidad y dise\u00f1o basado en componentes reutilizables<\/strong><\/h3>\n\n\n\n

Una de las t\u00e9cnicas centrales identificadas en nuestra investigaci\u00f3n fue la modulaci\u00f3n o dise\u00f1o modular, que consiste en dividir los escenarios y objetos del juego en piezas independientes que pueden reutilizarse din\u00e1micamente. Este enfoque no solo reduce el peso del proyecto, sino que tambi\u00e9n disminuye el n\u00famero de assets que deben cargarse simult\u00e1neamente en memoria. La modularidad facilita la construcci\u00f3n de niveles complejos sin aumentar significativamente la carga de procesamiento o el tama\u00f1o del ejecutable. Adem\u00e1s, permite reutilizar geometr\u00edas, texturas y materiales, lo que resulta especialmente \u00fatil cuando se busca lanzar el mismo t\u00edtulo en plataformas con capacidades gr\u00e1ficas distintas. En motores como Unity, la modularidad tambi\u00e9n habilita el uso de instancing para renderizar m\u00faltiples copias de un mismo objeto de forma eficiente.<\/p>\n\n\n\n

Occlusion Culling y reducci\u00f3n del coste de renderizado<\/strong><\/h3>\n\n\n\n


Otra t\u00e9cnica clave fue el occlusion culling, una estrategia que evita renderizar objetos que se encuentran ocultos detr\u00e1s de otros y que, por lo tanto, no son visibles para la c\u00e1mara. Sin este tipo de optimizaci\u00f3n, el motor gr\u00e1fico procesar\u00eda geometr\u00edas innecesarias, generando un consumo elevado de GPU y reduciendo considerablemente el rendimiento. En nuestras pruebas y an\u00e1lisis se evidenci\u00f3 que el uso adecuado del occlusion culling permite mantener tasas de fotogramas m\u00e1s estables y liberar recursos del pipeline de renderizaci\u00f3n. Esta t\u00e9cnica se vuelve indispensable en escenarios amplios o con muchos elementos estructurales, como edificios modulares, interiores complejos o niveles urbanos, donde existen m\u00faltiples capas de objetos superpuestos. Su implementaci\u00f3n adecuada contribuye directamente a mejorar la fidelidad gr\u00e1fica sin sacrificar rendimiento.<\/p>\n\n\n\n

Consideraciones de rendimiento multiplataforma<\/strong><\/h3>\n\n\n\n

La investigaci\u00f3n tambi\u00e9n nos permiti\u00f3 comprender que optimizar para m\u00faltiples plataformas implica tomar decisiones equilibradas entre calidad visual y eficiencia. Para dispositivos m\u00f3viles, por ejemplo, se requieren modelos de baja cantidad de pol\u00edgonos, texturas comprimidas y sistemas de iluminaci\u00f3n simplificados. En cambio, la versi\u00f3n para Windows puede aprovechar hardware m\u00e1s potente, permitiendo resoluciones superiores, sombras en tiempo real y efectos avanzados. Sin embargo, incluso en esta plataforma, un rendimiento \u00f3ptimo no es opcional: sin una buena gesti\u00f3n de recursos, el juego puede presentar ca\u00eddas en FPS, tiempos de carga excesivos y consumo de memoria innecesario. Por esta raz\u00f3n, la optimizaci\u00f3n debe ser vista como una pr\u00e1ctica continua durante todo el ciclo de desarrollo, no como un ajuste final ejecutado al terminar el proyecto.<\/p>\n\n\n\n

Impacto de la optimizaci\u00f3n en la experiencia del jugador<\/strong><\/h3>\n\n\n\n


Finalmente, nuestra revisi\u00f3n documental evidencia que la optimizaci\u00f3n no solo beneficia al rendimiento t\u00e9cnico, sino que tambi\u00e9n mejora la experiencia del usuario. Un videojuego estable, con tiempos de respuesta adecuados y sin fluctuaciones de frame rate, genera una percepci\u00f3n m\u00e1s profesional, aumenta la inmersi\u00f3n y fortalece la retenci\u00f3n del jugador. Por ello, las t\u00e9cnicas mencionadas como la modularidad, el occlusion culling y otras que contemplamos en nuestra investigaci\u00f3n se convierten en elementos esenciales para alcanzar un producto final competitivo y t\u00e9cnicamente s\u00f3lido.<\/p>\n\n\n\n

Assets necesarios y optimizaci\u00f3n del escenario de las catacumbas<\/strong><\/h3>\n\n\n\n


Durante la construcci\u00f3n del escenario correspondiente al segundo nivel, un sistema de catacumbas, nos enfrentamos a un problema cr\u00edtico de rendimiento que evidenci\u00f3 la importancia de dise\u00f1ar y estructurar adecuadamente los assets antes de integrarlos en Unity. Inicialmente, el escenario hab\u00eda sido desarrollado como una \u00fanica pieza completa, con un solo material y un mapa de texturas horneado (baked) en resoluci\u00f3n 4K. Sin embargo, a pesar de contar con un mapa de alta calidad, el rendimiento en nuestras computadoras personales era considerablemente bajo, mientras que en las m\u00e1quinas de la universidad el comportamiento era apenas aceptable. Esta discrepancia nos gener\u00f3 inquietud y nos llev\u00f3 a investigar las causas subyacentes del bajo desempe\u00f1o.<\/p>\n\n\n\n

El primer paso fue aplicar una descomposici\u00f3n modular del entorno, dividiendo el mapa de las catacumbas en piezas independientes que luego ensamblar\u00edamos directamente en Unity. El objetivo era reducir el peso de la escena, facilitar el uso de t\u00e9cnicas como el occlusion culling y permitir que el motor reutilizara geometr\u00edas mediante instancing. Sin embargo, para nuestra sorpresa, esta primera versi\u00f3n modular no mostr\u00f3 ninguna mejor\u00eda significativa frente al escenario original. Incluso cuando hab\u00edamos reducido las texturas de 4K a 2K, la diferencia en rendimiento era pr\u00e1cticamente inexistente, lo que indicaba que el problema ten\u00eda un origen m\u00e1s profundo que la simple resoluci\u00f3n de texturas.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Tras un an\u00e1lisis m\u00e1s detallado, determinamos que los principales responsables del bajo rendimiento no eran las texturas ni los materiales, sino la complejidad geom\u00e9trica de los modelos. Durante la fase de modelado, varios elementos del escenario conservaban modificadores activos, especialmente Subdivision Surface y Bevel, los cuales incrementaban dr\u00e1sticamente la cantidad de pol\u00edgonos generados. Esto significa que, aunque visualmente la escena pareciera simple, en realidad conten\u00eda miles de tris y quads innecesarios, sobrecargando tanto la GPU como la etapa de renderizado en Unity. No importaba cu\u00e1ntas texturas reduj\u00e9ramos o cu\u00e1ntos m\u00f3dulos cre\u00e1ramos: el verdadero cuello de botella estaba en la geometr\u00eda.<\/p>\n\n\n\n

El proceso de optimizaci\u00f3n final consisti\u00f3 en aplicar o eliminar por completo los modificadores, simplificar la topolog\u00eda de los modelos y remover v\u00e9rtices, segmentos y uniones que no aportaban nada estructural al dise\u00f1o. Cada m\u00f3dulo fue revisado uno a uno hasta dejar \u00fanicamente la geometr\u00eda indispensable para mantener la forma visual. Al reimportar todos los modelos en Unity, el resultado fue inmediato: la tasa de fotogramas aument\u00f3 de forma notable, la escena se volvi\u00f3 mucho m\u00e1s ligera y finalmente pudimos aplicar t\u00e9cnicas de optimizaci\u00f3n como el occlusion culling con total eficacia.<\/p>\n\n\n\n

Esta experiencia nos permiti\u00f3 entender que, en escenarios complejos, exportar un entorno como un \u00fanico objeto con una textura gigante puede resultar contraproducente. En cambio, optar por assets modulares, geometr\u00eda optimizada y una topolog\u00eda limpia no solo mejora el rendimiento, sino que facilita la escalabilidad del proyecto y su mantenimiento a largo plazo. De este modo, logramos transformar una escena inicialmente problem\u00e1tica en un nivel funcional, eficiente y compatible tanto con dispositivos m\u00f3viles como con equipos de escritorio.<\/p>\n\n\n\n

Selecci\u00f3n de la versi\u00f3n de Unity y configuraci\u00f3n inicial del proyecto<\/strong><\/h3>\n\n\n\n


El equipo decidi\u00f3 trabajar con una versi\u00f3n estable de Unity que garantizara compatibilidad con los paquetes esenciales del proyecto (URP, navegaci\u00f3n, animaciones, UI, etc.). Tras evaluar opciones, se eligi\u00f3 una versi\u00f3n actual y confiable de Unity que ofreciera soporte continuo y herramientas necesarias para el despliegue multiplataforma.<\/p>\n\n\n\n

Cada integrante instal\u00f3 la misma versi\u00f3n del editor para evitar problemas de incompatibilidad, cambios en la estructura de librer\u00edas o conflictos al abrir escenas y prefabs compartidos.
<\/p>\n\n\n\n

Intento de trabajo colaborativo con GitHub Desktop<\/strong><\/h3>\n\n\n\n

Inicialmente, el equipo busc\u00f3 trabajar de forma totalmente colaborativa utilizando GitHub Desktop. La idea era que todos pudi\u00e9ramos:<\/p>\n\n\n\n

Clonar el mismo repositorio.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Trabajar simult\u00e1neamente sobre el proyecto.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Subir cambios de forma ordenada.<\/p>\n\n\n\n

Unificar escenas, scripts y assets sin sobrescribir trabajo ajeno.<\/p>\n\n\n\n

Sin embargo, la coordinaci\u00f3n result\u00f3 m\u00e1s compleja de lo previsto. Unity genera m\u00faltiples archivos internos, meta-ficheros y carpetas dependientes del sistema. Esto provoc\u00f3:<\/p>\n\n\n\n

Conflictos constantes al modificar la misma escena.<\/p>\n\n\n\n

Archivos doblados o sobrescritos accidentalmente.<\/p>\n\n\n\n

Dificultad para revisar cambios en carpetas grandes.<\/p>\n\n\n\n

Problemas al unir el trabajo de modelado, scripts y UI en un solo flujo.<\/p>\n\n\n\n

Pese a los esfuerzos por organizar ramas y commits, el proceso termin\u00f3 siendo m\u00e1s costoso que productivo, por lo que decidimos replantear el m\u00e9todo de trabajo.<\/p>\n\n\n\n

Divisi\u00f3n del proyecto por responsabilidades espec\u00edficas<\/strong><\/h3>\n\n\n\n

Para evitar bloqueos y conflictos en GitHub, definimos un pipeline de trabajo basado en roles. Cada integrante se encarg\u00f3 de un \u00e1rea espec\u00edfica, lo que permiti\u00f3 avanzar con mayor estabilidad.<\/p>\n\n\n\n

Integraci\u00f3n general y flujo del juego en Unity<\/strong><\/h3>\n\n\n\n

Felipe se centr\u00f3 en asegurar que todos los componentes del juego pudieran ensamblarse correctamente. Sus tareas incluyeron:<\/p>\n\n\n\n

Configurar el flujo de operabilidad del proyecto dentro de Unity.<\/p>\n\n\n\n

Conectar los niveles, incluso cuando eran escenarios de prueba.<\/p>\n\n\n\n

Implementar los Canvas, botones, men\u00fas, cr\u00e9ditos e interfaz general.<\/p>\n\n\n\n

Garantizar que la navegaci\u00f3n entre escenas funcionara sin errores.<\/p>\n\n\n\n

Definir el pipeline de trabajo para que el ensamblado final fuera posible.<\/p>\n\n\n\n

Su aporte fue fundamental para que el resto del equipo entendiera c\u00f3mo deb\u00eda estructurarse cada aporte antes de ser integrado al juego.<\/p>\n\n\n\n

Dise\u00f1o de escenarios y programaci\u00f3n de IA<\/strong><\/h3>\n\n\n\n

Christian asumi\u00f3 la responsabilidad de construir los niveles 1 y 3:<\/p>\n\n\n\n

Utiliz\u00f3 assets libres de uso y modelos descargados para componer ambos escenarios.<\/p>\n\n\n\n

Configur\u00f3 la IA del \u00fanico enemigo presente en el nivel 1.<\/p>\n\n\n\n

Ajust\u00f3 posiciones, colliders, iluminaci\u00f3n base y distribuci\u00f3n general de los elementos.<\/p>\n\n\n\n

Prepar\u00f3 las escenas para que pudieran integrarse al flujo del juego sin afectar rendimiento.<\/p>\n\n\n\n

En el caso del nivel 3, el escenario proven\u00eda de un asset externo tipo volc\u00e1n\/arena de batalla, cuyo dise\u00f1o era \u00fanico, por lo que la modularidad no fue necesaria.<\/p>\n\n\n\n

Modelado, modularidad y optimizaci\u00f3n de geometr\u00eda<\/strong><\/h3>\n\n\n\n

Sebastian se encarg\u00f3 del rendimiento del proyecto:<\/p>\n\n\n\n