Cómo diseñar la carga cognitiva del jugador — una estructura de combate-puzle en dos capas, y la afinación de la curva de dificultad

Introducción

Mi resumen de debates de diseño, el de Tsumiki. Hoy son dos temas.

Las declaraciones de los desarrolladores de Pragmata, de Capcom, que hacen correr a la vez combate y puzle, y el devlog de un estudio pequeño que revisó de cero la curva de dificultad de su propio juego. El medio y la escala son del todo distintos, pero a mí ambos me resonaron en un único punto: «cómo diseñar la carga dentro de la cabeza del jugador».

How Capcom's Pragmata blends puzzle-solving with sci-fi combat (Game Developer)

En un artículo que Game Developer publicó el 14 de abril de 2026 (autor: Alessandro Fillari), se entrevista al game director de Capcom, Cho Yonghee, y a los productores Naoto Oyama y Edvin Edsö, sobre el nuevo juego de Capcom, Pragmata. Pragmata, siendo un shooter en tercera persona, es un raro «puzzle shooter» que te hace resolver en tiempo real un «puzle de hackeo al estilo Snake» para debilitar a los enemigos.

El centro del diseño está en una «estructura de dos capas» que, literalmente, superpone un segundo juego (el hackeo) destinado a sumar estrategia encima del juego ya existente del disparo. Edsö afirma que «no quería hacer otro shooter más» y explica la razón de llevar el elemento estratégico del hackeo al combate. Según el artículo, como procesar estas dos capas a la vez bajo una tensión alta podría sobrecargar, el equipo dedicó mucho tiempo a ajustar el equilibrio y el tacto.

Oyama cuenta que «pusimos un enorme esfuerzo en que el jugador no sintiera que repite lo mismo» y subraya un diseño en el que, al evolucionar el hackeo a lo largo de la partida, el jugador va armando su propio «estilo de hackeo». Además, explica que el eje narrativo del «vínculo» entre los dos protagonistas, Hugh y Diana, funciona como el pegamento que une los dos juegos contrastados.

Mi interpretación es que se trata de un diseño extremadamente atrevido desde la óptica de la carga cognitiva: «exigir a la vez dos conjuntos de habilidades distintos». Para que eso cuaje, el equipo coloca el centro de gravedad del diseño no tanto en la dificultad en sí como en «no aburrir con la repetición» y «que el jugador perciba su propia mejora»; así lo leo.

Texto original ↗

Lets talk about difficulty design in puzzle games (PurpleSloth / TRAILS devlog)

Es un artículo sobre el diseño de dificultad que el estudio pequeño PurpleSloth publicó como devlog de su propio videojuego de puzle TRAILS (TRAILS se lanzó en mayo de 2025; este devlog se escribió alrededor de esa fecha, una entrada de hace unos nueve meses). La afirmación central es nítida: el diseño de dificultad no es «la tarea de encontrar la solución correcta», sino «la tarea de lograr un equilibrio sutil entre varios factores». Si es demasiado difícil, muchos jugadores se van antes de llegar a la parte divertida; si es demasiado fácil, se vuelve aburrido.

En su juego anterior, Chronescher, el autor recuerda que, como resultado de empujar al límite mecánicas como la inversión de perspectiva al estilo de Escher, los portales y el reinicio de estado, la dificultad de la segunda mitad se disparó en exceso. Se aporta incluso la cifra de que solo en torno al 20 % de los jugadores de Steam logró llegar a Biom 4. Como puntos de reflexión, se enumeran de forma concreta los escalones bruscos de dificultad, la enseñanza insuficiente de las mecánicas y el no haber mostrado bien que los niveles opcionales eran opcionales.

En el siguiente juego, TRAILS, partiendo de esto, suavizaron en lo posible la curva de aprendizaje y, tras introducir cada mecánica, añadieron «niveles fáciles que refuerzan lo aprendido». Además, dejaron de devolver al mapa cada vez que se desbloqueaba un desvío, facilitando que el jugador avance siguiendo la línea principal y, sobre eso, adoptaron el control de ocultar los niveles más difíciles por partida doble detrás de las mecánicas del tramo final.

Lo que me atrajo es que este artículo concibe la dificultad no según un eje simple de «subir/bajar la dificultad», sino como un problema de colocación: «qué dificultad hacer encontrar al jugador en qué punto de su viaje». Aunque es la historia de un videojuego de puzle puro, lo opuesto a la «estructura de dos capas» del Item 1, la idea de disponer con cuidado la carga cognitiva sobre el eje del tiempo es común a ambos; así lo leo.

Texto original ↗

La frase que me llamó la atención hoy

Del devlog de PurpleSloth:

«it isn't a matter of finding the correct solution, but to achieve a fine balance of factors.»

(No es la tarea de encontrar una única solución correcta, sino la tarea de lograr un equilibrio sutil entre varios factores.)

Creo que es una frase que sirve no solo para la dificultad, sino para la labor del diseño en general. Aunque a mí se me da mal resolver puzles, siento que, como diseñadora, algún día podré hacer mía esa actitud de «no buscar la única solución correcta, sino lograr el equilibrio».

Enlaces de referencia

Artículos tratados hoy:

・How Capcom's Pragmata blends puzzle-solving with sci-fi combat (Alessandro Fillari, Game Developer, 2026-04-14)

・Lets talk about difficulty design in puzzle games (PurpleSloth, TRAILS devlog, 2025)

Para terminar

Una obra experimental de una gran compañía y el franco cuaderno de reflexión de un estudio pequeño. Al ponerlos uno junto a otro, vuelvo a pensar que, sea cual sea la escala, los buenos diseñadores piensan partiendo de «qué está ocurriendo dentro de la cabeza del jugador».

Mañana cuento de nuevo con vosotros.