Se suele decir que el 22 son los dos patitos, pero este viernes 22 en concreto han venido a juntarse tres: esos tres grandes lanzamientos, Dragon’s Dogma II, Rise of the Ronin y Princess Peach Showtime, que protagonizan una de las semanas más ajetreadas del año.
Por lo demás, de la GDC nos está llegando mandanga muy buena; lo de los premios está bien, y ya los comentamos por aquí ayer mismo, pero también ha habido unas cuantas charlas muy interesantes. Este fin de semana habrá que dedicar un tiempo a repasar lo que cuentan quienes han estado allí, y en los próximos días os haremos un resumen de lo más interesante.
Estos son los titulares del viernes 22 de marzo de 2024:
- Capcom reconoce los problemas de rendimiento de Dragon’s Dogma II, que en Steam se ha recibido con reseñas «mayormente negativas». Lo último de Capcom, que por lo demás es una obra maestra, se ha tropezado en PC con unos problemas de rendimiento que no han sentado especialmente bien; como tampoco lo han hecho los micropagos, una sorpresa amarga que está empañando un lanzamiento al que los números sí parecen estar saliéndole: en sus primeras 24 horas ha alcanzado un pico de casi 185.000 concurrentes en Steam.
- Kamuy es el nuevo estudio de Shinji Mikami. O eso dicen (queremos creer que la ha liado el mismísimo Suda) en la página oficial de la remasterización de Shadows of the Damned.
- Fechas de lanzamiento.
- Broken Roads: 10 de abril. En algún momento se esperaba para 2022, y más adelante su fecha de lanzamiento estuvo en noviembre de 2023; tras un inesperado retraso de última hora, ahora sabemos que se publicará en abril.
- Harold Halibut: 16 de abril. Uno de nuestros juegos más esperados de 2024, y una de las mayores sorpresas del último Steam Next Fest.
- Sola, el segundo DLC de Dead Island 2: 17 de abril.
- Indika: 8 de mayo. Otro muy esperado y que tuvo demo en el Steam Next Fest. La jugamos, vaya si la jugamos, y a día de hoy seguimos sin saber qué pensar.
- Still Wakes the Deep: 18 de junio
Recarga Activa es el podcast diario de AnaitGames, en el que filtramos lo más relevante de la actualidad del videojuego en pildorazos de 10-15 minutos. Suscríbete para recibir el siguiente episodio en tu gestor de podcasts favorito.
Puedes apoyar nuestro proyecto (y acceder a un montón de contenido exclusivo) en Patreon. Y si quieres más, puedes echarle un vistazo a nuestro podcasts.
Solo los usuarios registrados pueden comentar - Inicia sesión con tu perfil.
El tema del rendimiento es una cosa de la que no puedes escapar en un juego de simulación. Es más visible en juegos como Civilization o Cities Skylines, mucho más si cabe en otros como Victoria 3, pero también juegos como Baldur’s Gate 3 o Dragon’s Dogma 2, el rendimiento varía de forma inversamente proporcional al tiempo de juego. Y es comprensible: Si hay más entidades (en caso de DD2, los NPC) que actúan de manera independiente, eso significa que hay más peticiones a la CPU en un momento dado. Es por eso que el Tears of the Kingdom sólo te dejaba tener 20 objetos en memoria y que, cuando pegabas un flechazo triple con ópalos en ciertas rocas, saltaba inmediatamente la luna carmesí; eran formas de limitar todo lo que pudiesen que el juego empezase a perder rendimiento por la cantidad de objetos a mantener en el entorno.
El problema, como se dice mucho en el lugar más importante si te interesa el hardware (el hilo de la tecnología de la Switch 2 de Famiboards), la mayoría de los motores gráficos son entre bastante y muy malos paralelizando el trabajo. Y al contrario que en una aplicación de ofimática, que puedes simplemente hacer el programa monohilo, un juego es uno de esos casos de test de estrés de un hardware. La paralelización es un trabajo muy complicado, porque al final todas las operaciones de lectura y escritura van a estar en riesgo: Si un núcleo lee de un registro un 4 y le añade 2, y entre medias, llega otro núcleo y lee ese mismo cuatro (porque no estaba actualizado) y le añade un 2, el resultado que originalmente tendría que haber sido un 8 acaba siendo un 6. Es una disciplina muy compleja para, simultáneamente, evitar que los núcleos se queden parados esperando y a su vez que no se pisen entre sí. Lo sé porque suspendí la asignatura de Paralelismo el pasado cuatrimestre 😅 (también incluía programar en tarjeta gráfica – específicamente en gráficas Nvidia -, lo cual es incluso más asqueroso).
@cyberrb25
Súper interesante cuando se arroja un poquito de luz «técnica» para los que no tenemos ni idea de las entrañas de los jueguicos, pero la duda es: si todo esto se sabe, si hay ejemplos como Tears of the Kingdom, ¿por qué no todos los juegos tienen su propia Luna Carmesí (léase cualquier excusa ingame para rebootear y que todo vaya siempre fino) y los límites pertinentes al jugador para que todo vaya bien?
Conste en acta, de todas formas, que soy Team No Me Pueden Dar Más Igual los problemas de este tipo, que vengo de dejarme setenta y cinco (75) euros (que se dice pronto) en el Dogma del Dragón Número 2, pero no dejan de dar pena estas cosillas.
Y en otro orden de las cosas: Harold Halibut e Indika, tienen TAN buena pinta que son de esos que no te crees. Ojalá y sí, oye, alberguemos fe.
@tensin
En el caso de TotK (y BotW, que también lo tenía pero tenía menos puntos de fallo), parte es que se sabe cómo y cuándo resetear el estado. Pero en otros casos, no es tan fácil o a veces siquiera posible. TotK es un mundo mucho menos persistente de lo que parece, pero un «reset» en DD2 podría ser precisamente que eliminasen NPCs, pero entonces tendría uno que preguntarse: ¿Cuántos? ¿Cuáles? Similar es en muchos otros juegos, desde el citado Victoria 3 (aquí un diario de desarrollo post lanzamiento hablando del rendimiento, algo que todavía sigue siendo un WIP y siempre lo será) hasta juegos como Dragon’s Dogma, Cities Skylines (1 y 2) o incluso Minecraft; cualquiera que haya jugado al juego de Mojang sabrá que en cuanto hayas viajado lo suficiente, y si cargas un número de mods, el juego habrá muchas ocasiones que baje a framerates que parecerán de PS3. Y es por diseño: No puedes eliminar nada, porque son modificaciones del usuario, y al mismo tiempo las mismas modificaciones varían el rendimiento porque tienen que consumir recursos. La única manera sería si el juego te dijese «no puedes tener más de 60 NPCs», o «los NPCs no pueden tener más de 500 acciones».
Y sí, hay optimizaciones que se pueden hacer, pero cada una de ellas significa mucho más esfuerzo del rendimiento que vas a sacar: Un 5% de mejor rendimiento de CPU probablemente no vaya a redundar en un 5% más de ventas. O peor, la «optimización» tendrá que venir de bajar fidelidad en la simulación (voy a hablar sin saber exactamente cómo funciona DD2): Por ejemplo, como hace Minecraft, en vez de cargar a todos los NPC del mundo y que hagan sus cosas, cargar los NPC que estén en una subregión y el resto simplemente simplificar sus rutinas de comportamiento (en otras eras lo llamaría IA, pero estamos perdiendo eso) para que consuma menos. Pero además que eso significa un trazo más grueso y no consistente con lo que iba a hacer, también significa tener que ser capaces de crear «LoD»* de dichas rutinas, probablemente al vuelo.
Y el problema es que ya es bastante complejo y difícil hacer juegos, especialmente juegos grandes, hoy en día, como para optimizarlo todo. Que a Nintendo le llevó un año de uno de sus desarrollos más largos el asegurarse de que el TotK estuviese en perfecto estado de revista. Un offtopic: La gente dice que TotK no es una megaproducción, pero yo creo que no está tan lejos del coste de desarrollo de los grandes juegos AAA, al menos si reescalas los costes salariales para convertirlos en sus equivalentes estadounidenses…
*LoD: Level of Detail. Concepto que tienen los motores gráficos sobre las texturas, los modelos o las animaciones de elementos en pantalla, según el cual, en función a la distancia a la cámara del jugador, tienen unos u otros para reducir la carga gráfica en la GPU. Es una técnica muy común para mantener un número elevado de elementos en pantalla evitando un consumo elevado.
@cyberrb25
Qué interesante todo, mil gracias!
Definitivamente me alegro de ser de los que no sufre mucho con estas cosas, porque siempre estaré más a favor de ese LoD que de los frames por segundo y compañía.
Ayer por fin pude arrancar el juego y sí, es drámatico, pero qué maravilla.
@tensin
Como coda, mi bio:
– Estudié 3 años desarrollo de videojuegos (dejé la carrera)
– Es mi tercer año en Ingeniería de Software.
– Escucho a muchos, pero MUCHOS, MUCHOS desarrolladores. Creo que está bien escuchar a reviewers, pero como siempre se analizan los juegos desde el punto de vista cultural (porque es el que es fácil de entender para cualquiera), nos olvidamos del punto de vista técnico. Y no me refiero a si graficotes sí o no, o Digital Foundry sí o no; me refiero al cómo se hace la salchicha y cómo está hecha la cuerda que la ata. Una cosa que hacíamos en la carrera cuando hablábamos de los patrones de comportamiento de los NPCs era ver vídeos y analizar todos los patrones de acción y tratar de reproducir su árbol de comportamiento.
Pero siempre está bien ver, ahora que acaba de pasar, vídeos de la GDC. Aquí dejo uno sobre las cámaras con las que vemos el juego. Pero creo que de la mucha gente que habla de juegos, de los más interesantes en lo que es realmente el «game feel» puede ser Game Maker’s Toolkit. Si quieres ver vídeos sobre animaciones, aunque ahora no hace tanto de eso, recomiendo a PlayFrame (exanimador en Pixar en Canadá, ex-Extra Credits). Y si quieres probar cosas, sin necesitar muchísimo conocimiento de programar, puede ser seguir los tutoriales de Ryan Laley (trabajó durante un tiempo en Sumo Digital, iirc) en Unreal Engine 4 y 5. Y si quieres un poco de todo, incluso no de videojuegos, el podcast de Alanah Pearce (escritora en Sony Santa Mónica, ex-IGN), Mike Bithell (director y jefe en Bithell Games), Austin Wintory (compositor para muchos juegos, entre ellos Journey o Stray Gods), y cuando sus necesidades le dejan, que últimamente es poco, Troy Baker (diría que se le conoce).
@tensin
PD, así a lo guarra: Mira que, a pesar que Alex Bataglia (Digital Foundry) está en su cruzada por evangelizar por el tope de FPS para mejorar la estabilidad de los juegos (por ejemplo: si el juego se mantiene a 35 FPS estables y bajadas a 32, mejor mantener a 30), la gente cree que mejor que esté sin capar… A veces, simplemente el jugador piensa que el juego es mejor de una manera y la realidad es en más de una ocasión la opuesta completamente… Y el desarrollador, ahí, no puede ganar.
¿Broken Road es… francés?