El arma secreta de Valve
Valve usa las pruebas con jugadores como un motor de diseño: empezar pronto, repetir cada semana, mirar sin ayudar, elegir a las personas adecuadas y leer cada resultado contra un objetivo claro.
Publicado el 2026-06-30 · Game design
Cómo las pruebas con jugadores crearon a GLaDOS
GLaDOS existe porque quienes probaban le dijeron a Valve que el juego todavía no era un juego. Más o menos un año después de empezar Portal, una persona tras otra daba el mismo veredicto: gran tutorial, ahora déjanos jugar al de verdad.
Ya lo habían jugado. Unas 14 cámaras de pruebas hechas a mano, todas terminadas, y aun así la secuencia no se presentaba como un juego completo. No había forma dramática, ni motivación, ni contexto de por qué importaba nada de aquello.
Qué son las pruebas con jugadores, y qué no son
Hacer pruebas con jugadores significa mirar a alguien jugar una parte de tu juego, a veces hacerle preguntas después, y dejar que lo que viste impulse cambios de diseño. No es control de calidad, que sobre todo caza errores, y no es un grupo de opinión, que se acerca más al estudio de mercado.
El mecanismo es sencillo, y de ahí viene su fuerza. No recoges veredictos. Recoges comportamiento.
La respuesta de Valve, tras algo de debate, fue darle al jugador un antagonista. Alguien que le plantara cara, que lo empujara hacia delante, que le explicara el sentido de las pruebas. Eso replanteó los puzles como entrenamiento para un enfrentamiento.
En Portal eso llegó a casi todo: la curva de aprendizaje, la frustración, la legibilidad de los objetos, el ritmo, la dificultad, la coherencia de la historia, incluso el aspecto blanco y aséptico. Los primeros escenarios eran más sucios y recargados, y quienes probaban no distinguían qué elementos eran piezas del puzle. En una prueba, una persona pasó media hora empujando una estantería hacia un botón mientras una caja esperaba al lado, ignorada.
Verlo duele. También es la información más honesta que puede recibir un diseñador, porque muestra lo que comunica el juego y no lo que el equipo esperaba que comunicara.
En Valve, todo diseño empieza como una hipótesis
El proceso de Valve es un ciclo: fija un objetivo, haz un intento y luego haz una prueba con jugadores para ver si el intento cumplió el objetivo. Si no da la talla, cámbialo y da otra vuelta.
El equipo de Portal aprendió ese ciclo nada más llegar. Su juego empezó como Narbacular Drop, un proyecto de estudiantes de DigiPen. Gabe Newell lo vio, le ofreció trabajo al equipo y su nuevo encargo fue reconstruir la idea en el motor de Valve y dentro del universo de Half-Life.
Que los jugadores mueran una y otra vez intentando redirigir bolas de energía puede apuntar a un arreglo de diseño de niveles, como limitar los portales a paredes por encima de la altura del jugador. Que los jugadores no se fijen en el objeto que importa puede apuntar al diseño visual. Que los jugadores pierdan el interés a mitad puede apuntar al ritmo o a la motivación.
La iteración sigue hasta que, en palabras del desarrollador David Speyrer, mirar las pruebas deja de ser insoportablemente doloroso.
Verlo es doloroso. También es la información más honesta que puede obtener un diseñador, porque muestra lo que el juego está comunicando y no lo que el equipo esperaba que comunicara.
Por qué Valve prueba antes que casi todos los estudios
Valve no es rara por recoger opiniones de jugadores. Casi todos los desarrolladores lo hacen. Lo que distingue al estudio es lo pronto que empieza y lo implacablemente que repite.
Kim Swift y el equipo de Portal hicieron su primera prueba tras más o menos una semana en Valve, sin nada más que una sala a medio terminar que enseñar. A partir de ahí el juego entró en un ritmo semanal: prueba el viernes, comenta los resultados el lunes, aplica lo aprendido durante la semana, vuelve a probar el viernes.
La costumbre viene de una casi catástrofe con el Half-Life original. Con unos dos meses por delante antes de su supuesta salida, el equipo tuvo que aceptar que el proyecto no funcionaba. No se podía jugar de principio a fin, los niveles conectaban mal y había problemas técnicos por todas partes.
Así que tiraron buena parte y lo reconstruyeron, quedándose con dos ideas que sobrevivieron a la crisis. Una era la cábala: equipos pequeños y multidisciplinares responsables de partes concretas del juego. La otra eran las pruebas frecuentes desde las primeras fases, porque si el juego volvía a fallar querían saberlo ese mismo día, no en el último mes.
Ese planteamiento importa porque impide que el playtesting degenere en una recogida de opiniones. Mike Ambinder, antiguo psicólogo interno del estudio, lo ha descrito como tratar los diseños como hipótesis y los playtests como los experimentos que los validan. La pregunta nunca es solo si a alguien le gustó un nivel. Es si el nivel produjo el efecto concreto para el que se construyó.
Juegos que Valve rehízo según lo que hacía la gente
Half-Life salió y fue enormemente influyente, y el proceso reconstruido se quedó. Las pruebas siguieron guiando los juegos del estudio después, a veces en detalles pequeños y a veces al nivel de un diseño entero.
Uno pequeño: quienes probaban rompían todas las cajas de un nivel, así que Valve decidió que algunas guardaran munición y vida. La gente ya trataba las cajas como algo que merecía investigarse, y el juego podía ir a su encuentro.
El hábito se remonta a una casi catástrofe en el Half-Life original. Con unos dos meses por delante antes de la fecha de lanzamiento prevista, el equipo tuvo que asumir que el proyecto no funcionaba. No se podía jugar de principio a fin, los niveles conectaban mal y había problemas técnicos por todas partes.
Steam llevó la costumbre más allá del lanzamiento. Los datos de juego mostraron a mucha gente atascada en Episode One, y el equipo parcheó un asedio difícil para bajar la dificultad.
La realidad virtual subió de nuevo la apuesta en Half-Life: Alyx. Valve descubrió que en realidad virtual baja la paciencia para quedarse quieto mirando cómo hablan los personajes, así que el juego tenía que ir más rápido. Christine Phelan ha descrito el comportamiento de quien juega como otra entrada de diseño, con apenas un momento del juego que no tocara lo que enseñaron o dijeron quienes probaban.
Empieza a probar antes de que el juego parezca terminado
Prueba pronto, porque pronto es cuando un problema todavía se puede resolver bien. Valve ha dicho que la gran mayoría de sus cambios más importantes salen de las pruebas, y justo por eso el estudio intenta empezar en cuanto puede.
Encuentra un problema tarde y el arreglo suele ser endeble: un personaje que explica un mal puzle, más carteles señalando un objeto que no se lee, guiones estirados sobre un nivel que nunca funcionó. Encuéntralo pronto y puedes repensar el diseño en lugar de parchearlo.
Otros más grandes cambiaron la forma de juegos enteros. La pistola de gravedad de Half-Life 2 iba a aparecer mucho más tarde, y a los testers les encantó tanto que Valve la adelantó. Left 4 Dead ganó los contornos de rayos X sobre los supervivientes porque los playtesters no conseguían localizar a los compañeros en peligro. Portal 2 perdió una pintura que permitía caminar por las paredes, porque mareaba a varios testers.
La idea no es presentar algo terminado. Es descubrir si lo que está sin terminar merece terminarse, y la forma más rápida de saberlo es ponerlo en marcha y dejar que alguien lo juegue.
La realidad virtual volvió a subir la apuesta en Half-Life: Alyx. Valve descubrió que la paciencia de un jugador para quedarse quieto viendo hablar a los personajes cae en VR, así que el juego tenía que avanzar más rápido. Christine Phelan ha descrito el comportamiento de los jugadores como un input de diseño más, y apenas queda un momento del juego que no haya tocado lo que los testers mostraron o dijeron.
Sigue probando con un calendario regular
Prueba a menudo, porque un ritmo semanal mantiene las opiniones pegadas al trabajo en curso e impide que un equipo se vaya muy lejos en la dirección equivocada antes de que nadie lo note.
La frecuencia también produce volumen, y el volumen produce patrones. Cada capítulo de Half-Life 2 pasó por unas 100 personas que lo probaron. Con números así puedes distinguir un fallo común de un caso raro.
Una prueba puede hacerse a los pocos días de prototipar una mecánica o de hacer el blockout de un nivel. El build puede ser feo, todo programmer art y texturas provisionales de color naranja chillón, y esa fealdad está haciendo un trabajo real. Impide que el equipo vuelque arte, audio y pulido en una mecánica que no se ha ganado nada de eso.
La repetición también afila a los diseñadores. Gabe Newell ha dicho que tras cientos de pruebas un diseñador desarrolla mejor intuición sobre qué estrategias funcionan y cuáles no. De ahí sale la sabiduría popular de un estudio, frases como la gente no aprende bajo estrés, o la gente no mira hacia arriba.
Quédate callado mientras quien juega se atasca
No digas nada. Una prueba debería reflejar lo más fielmente posible la experiencia real de quien juega, lo que descarta pistas, respuestas, orientación y cualquier intento de rescatar a alguien de su confusión.
Aguantar 20 minutos viendo a alguien dar vueltas por un nivel sin encontrar la respuesta que creías imposible de pasar por alto es una lección de humildad. Esa humildad es la idea. Nadie está suspendiendo un examen salvo el diseño.
Las entrevistas y los cuestionarios siguen teniendo su sitio. Fueron como Valve diagnosticó en primer lugar la falta de contexto de Portal. Pero el comportamiento normalmente le enseña más a un desarrollador que una explicación después de jugar.
La gente dice que algo le gustó por educación, o porque el recuerdo ya se ha difuminado, o porque le faltan palabras para lo que sintió. La postura, la duda, la frustración visible, la risa y las acciones repetidas una y otra vez suelen ser mucho más honestas.
Quien lo construyó debería mirar la prueba
En Valve, las pruebas no se delegan en un departamento aparte. Quien es responsable del nivel, la mecánica o la función es quien se sienta a mirar cómo se juega.
Observar directamente compra comprensión y motivación. Un informe te dice que la gente se atascó. Ver a alguien atascarse te dice exactamente cómo, dónde y por qué falló tu diseño.
También genera ideas. En Half-Life: Alyx, la gente se tapaba la boca con la mano por instinto para evitar que Alyx tosiera cerca de Jeff, el enorme zombi ciego. Valve cogió ese instinto y lo convirtió en una mecánica.
Eso son las pruebas en su mejor versión: no solo cazar errores, sino encontrar cosas. De vez en cuando alguien revela una versión mejor de tu juego intentando algo para lo que nunca construiste soporte.
A los testers también les gusta proponer soluciones. Esas sugerencias pueden ser realmente interesantes, pero llegan sin ningún conocimiento de la visión del juego, sus limitaciones, herramientas, calendario o estructura general. Escucha el problema que hay debajo de la sugerencia en lugar de implementar la sugerencia en sí.
Ajusta las opiniones a la gente para la que diseñaste
No todas las personas que prueban son igual de relevantes para cada decisión. Valve recurre a todo tipo de gente, desde su propio personal hasta niños y jugadores expertos, y aun así tiene que preguntarse a qué público sirve un cambio concreto.
El final de Portal es el caso de estudio. Mientras Valve resolvía el combate contra GLaDOS, jugadores muy aficionados a los shooters dijeron que el final pedía más acción, más reto, más exigencia de habilidad. Un consejo creíble, y muy mal ajustado al juego más lento y cerebral que casi todo el público de Portal había pasado horas aprendiendo.
También genera ideas. En Half-Life: Alyx, los jugadores se tapaban instintivamente la boca con la mano para evitar que Alyx tosiera cerca de Jeff, el enorme zombi ciego. Valve tomó ese instinto y lo convirtió en una mecánica.
Hacer buenas pruebas significa saber para quién es el juego y pasar las opiniones por ese filtro, no dar el mismo peso a todas las voces en todas las preguntas.
Cuestiona las suposiciones escondidas en tus soluciones
El mismo final muestra cómo una suposición puede sobrevivir sin examinarse dentro de un arreglo. Si el último encuentro no tenía que ser una prueba de habilidad al estilo shooter, entonces seguro que tenía que ser el puzle más complejo del juego.
Las pruebas dijeron que no. A quienes probaban la secuencia de huida de mitad de Portal les pareció intensamente climática y muy satisfactoria, aunque el uso de portales en ella es sencillísimo. La presión del tiempo, el drama visual y lo que estaba en juego en la historia hacían el trabajo.
Ante un final con más acción, esos jugadores salían frustrados, confundidos e insatisfechos. Valve sí atendió al público hardcore, mediante cámaras avanzadas opcionales y mapas de desafío, pero el final principal tenía que recompensar al público que había seguido el lenguaje de puzles de Portal hasta allí.
Esto es fácil de infravalorar. Los diseñadores tienden a suponer que un juego tiene que terminar con la versión más difícil, densa y exigente de su mecánica central. A menudo el final más fuerte es el que deja a quien juega sentir todo el peso de lo que ya sabe hacer.
Trata las reacciones como pruebas, no como instrucciones
Las opiniones son datos. Interpretarlas, filtrarlas y decidir qué hacer con ellas sigue siendo trabajo del diseñador, y esa es la lección más importante de todas.
Half-Life 2 empezaba al principio con una introducción muy corta antes de que Gordon Freeman cogiera un arma y empezara a disparar. A quienes probaban les gustaba. Llegar rápido a la acción emociona, y las respuestas lo decían.
Valve lo cambió igualmente. El guionista Marc Laidlaw ha explicado que el equipo quería que la gente viera primero a la Alianza hacer algo horrible, para que contraatacar se leyera como una respuesta y no como el modo por defecto de una máquina de matar. También querían que la llegada de la palanca tuviera más fuerza emocional.
Esa distancia es la diferencia entre reaccionar a las opiniones y usarlas. Sigue la respuesta positiva inmediata y el comienzo se vuelve más rápido y significa menos. Valve usó la prueba para entender qué funcionaba y luego fue a por una forma emocional mejor de todos modos.
Cuando una prueba mata un proyecto entero
La decisión más drástica de Valve a partir de unas pruebas llegó después de Portal. Una jam interna produjo un juego de puzles experimental llamado F-Stop, construido alrededor de una cámara que fotografiaba objetos y luego los hacía reaparecer en otra parte del mundo con otra escala.
A Gabe Newell le gustó lo bastante como para querer desarrollarlo como continuación de Portal, con cada entrega de la saga mostrando una tecnología distinta de Aperture Science.
Casi un año de desarrollo después, quienes probaban devolvieron una respuesta inequívoca: Portal sin portales no funcionaba. Valve abandonó esa dirección y volvió a empezar, y lo que salió por el otro lado fue Portal 2.
Es un resultado brutal de recibir, y también es todo el motivo para probar. Una prueba puede mejorar una sola sala, descubrir un personaje, recolocar un arma, quitar una mecánica que marea a la gente o decirle a un equipo que toda su premisa no da lo que la gente vino a buscar.
El arma secreta de Valve nunca fue que la gente diseñe el juego. Es que la gente revela lo que el juego está haciendo de verdad, y el estudio toma mejores decisiones cuando tiene esa prueba en la mano.
When a playtest kills an entire project
La decisión de playtesting más drástica de Valve llegó después de Portal. Una jam interna produjo un juego de puzles experimental llamado F-Stop, construido en torno a una cámara que fotografiaba objetos y luego los hacía reaparecer en otro punto del mundo a distintas escalas.
A Gabe Newell le gustó lo suficiente como para querer desarrollarlo como continuación de Portal, con cada entrega de la serie mostrando una tecnología distinta de Aperture Science.
Casi un año de desarrollo después, los playtesters dieron una respuesta inequívoca: Portal sin portales no funcionaba. Valve abandonó esa dirección y volvió a empezar, y lo que salió por el otro lado fue Portal 2.
Es un resultado brutal de recibir, y también es la razón misma de hacer pruebas. Un playtest puede mejorar una sola sala, descubrir un personaje, recolocar un arma, eliminar una mecánica que marea a la gente o decirle a un equipo que toda su premisa no está dando lo que los jugadores venían a buscar.
El arma secreta de Valve nunca fue que los jugadores diseñen el juego. Es que los jugadores revelan lo que el juego está haciendo de verdad, y el estudio toma mejores decisiones una vez que tiene esa evidencia en la mano.
Build it in Flockbay
En la app de Flockbay, pásale el build a alguien que no haya oído la premisa y observa una sesión sin dar explicaciones. Apunta el minuto en que pregunta si el juego ya ha empezado. Ese minuto es tu verdadero comienzo. Cambia el build para que la pregunta no surja, o para que la respuesta sea obviamente sí.
Un creador de puzles con IA y una plantilla de puzles de lógica pueden hacer cámaras todo el día. La voz, o lo que está en juego, todavía tiene que probarlo un desconocido.
Descarga Flockbay
Merece la pena hacer una prueba con jugadores cuando mide un objetivo que fijaste a propósito. Pon una versión en marcha, dásela a otra persona y mira lo que tu juego le enseña de verdad.