¿Cómo se obtienen datos útiles de playtesters? [cerrado]

Hay algunos tipos de comentarios que puede obtener de los expertos en juegos, y me pregunto cómo reunir mejor los datos para cada uno de ellos ...

1. Informes de bloqueo. Cuando mi juego C ++ se bloquea mientras alguien lo está jugando, ¿cómo puedo asegurarme de saberlo y aún mejor ... qué lo causó? Incluso obtener algo tan simple como el archivo y el número de línea que causó un bloqueo sería increíblemente útil.

2. Comentarios de diseño. Cuando un probador de juegos está jugando el juego, ¿cómo puedo saber si se están divirtiendo, por qué se divierten, por qué no se divierten y qué debemos pasar tiempo ajustando?

Supongo que estás hablando de probadores de juegos en el sitio y no de probadores beta de Internet.

Regla # 1: no los ayudes . La frustración debe ser lo más importante que debe verificar. La situación ideal sería un espejo de doble sentido con su equipo a un lado y el probador de juegos en el otro con una cámara de video en la cara y otra en la pantalla. Obviamente, esto no es factible para la mayoría de las personas, así que haz lo mejor que puedas. El solo hecho de que sus diseñadores se sienten y observen dónde se atasca la gente es una información muy útil. No vas a estar parado sobre sus hombros cuando se lleven el juego a casa, por lo que dar consejos sobre cómo pasar ciertas secciones no te dará la información que necesitas. Editar : otra forma de decirlo es esta: no pienses que están "jugando mal"

Regla # 2: No les des lo que quieren . Después de una sesión de prueba, tienes algún tipo de cuestionario que completan. Las sugerencias específicas que tienen generalmente no son prudentes de tomar al pie de la letra. Por lo general, hay una causa raíz que desencadena la mayoría de las respuestas y simplemente no saben cómo expresarla. Si puedes resolver eso, será mejor que lo hagas. Aunque en este momento tengo problemas para encontrar ejemplos específicos.

Regla # 3: Los datos son el rey . Si puede (y este es realmente otro elemento de la lista de deseos, sinceramente), haga un seguimiento de todo lo que pueda. Rastrea dónde mueren los jugadores. Rastrea dónde se quedan sin munición de un arma específica. Haz un seguimiento de las pastillas que se pierden. Haz un seguimiento de las actualizaciones que compran. Rastrea lo que los enemigos les hacen daño. Obviamente, estos son ejemplos específicos de FPS, pero estoy seguro de que hay dominios específicos para cualquier juego que estés haciendo. Si todo el mundo hace o no hace algo, esas son áreas en las que debería pasar un poco más de tiempo mirando.

Básicamente, no te importa lo que piensen los jugadores . Te importa obtener números en bruto para lo que hacen los jugadores . Necesitas ojos vírgenes para ver tu juego y decirte lo que los frustra y lo que se les hace hacer.

Para choques, investigue minidumps . No son perfectos, pero son una herramienta muy útil para descubrir dónde están los bloqueos.

Considere también una herramienta de informe de errores incorporada. Algo donde el usuario puede tomar una captura de pantalla, agregar una descripción y enviarla por correo electrónico a alguien automáticamente desde el interior del juego. Idealmente con una instantánea del mundo (es decir, guardado rápido o algún tipo de volcado de memoria) si su juego lo admite.

Ampliar los datos es un poco el sentimiento rey (¡+1 a Tetrad!):

Investigar grabación y reproducción :

• Si su juego es determinista y está basado en marcos, es posible que solo necesite almacenar una semilla inicial aleatoria y una tupla en (key/button state, joystick/mouse coords, frame #)cualquier momento que cambie el estado de entrada. La reproducción es tan simple como redirigir su entrada a esta transmisión. (Lo hemos hecho para muchos juegos de salto de plataforma en el pasado).
• Si su juego tiene API o sistemas de mensajes bien definidos para realizar acciones (un juego de estrategia por turnos, un juego de cartas, un juego de mesa o similar), es posible que pueda recolectar llamadas o mensajes de API en un determinado punto crítico . (Hicimos esto para un juego de cartas para una plataforma portátil).
• Es más difícil en algunos sistemas (los sistemas de paso de tiempo menos deterministas, roscados o arbitrarios pueden ser una molestia) pero puede valer la pena registrar los datos de todos modos; puede obtener resultados "lo suficientemente cercanos" para algunos usos.

Un sistema de "repetición" basado en estos métodos tiene muchas ventajas:

• úselo para reproducir bloqueos en una depuración o en una compilación o entorno instrumentado;
• cargar repeticiones bajo una compilación de creación de perfiles y obtener datos de rendimiento o uso de recursos;
• conéctelo al juego para proporcionar la funcionalidad de "reproducción instantánea", tal vez con una cámara diferente o un paso de tiempo;
• configura un juego de demostración de "modo de atracción" si el usuario se queda sin hacer nada en un menú;
• póngalo en su sistema de compilación como prueba de humo: si puedo reproducir esta repetición sin fallar, es más probable que sea una buena compilación;
• mire ejemplos de personas jugando para ver lo que hicieron y lo que no hicieron.

Conecte una entrada aleatoria en lugar de una transmisión grabada, y tiene una gran prueba de mono que puede dejar en remojo durante la noche o cuando sus máquinas de desarrollo estén inactivas.

A continuación, realice alguna grabación de eventos . Para un FPS hipotético, comience con algo como "el tiempo T: X mató a Y en el punto Z con el arma W": póngalo en un registro.

Una vez que haya recopilado algunos datos, descubra cómo automatizar la recopilación . No tiene que ser elegante durante el desarrollo:

• conectarse a un servidor SQL e insertar filas,
• dispara y olvida los paquetes UDP en un servidor syslog-ish simple,
• envíe el registro por correo electrónico la próxima vez que se inicie el juego,
• simplemente envuelva el ejecutable en un script de shell o archivo por lotes que cambie el nombre y copie un archivo .log en una unidad compartida común,
• (más tarde, para compilaciones de producción) use el Informe de errores de Windows o un servicio similar para recopilar datos sobre fallas ...

Realmente no importa, siempre que pueda recopilar datos.

Ahora extiéndalo: recopile volcados de memoria, rastreos de pila y grabaciones de entrada o evento. Agregue más eventos y más fuentes de datos:

• muestree la posición o la mano del jugador cada 10 segundos, grábelo en un mapa - "oye, nadie está usando esta esquina en la que pasé una semana modelando, es hora de poner un encendido allí"
• getFreeMemoryBytes() cada medio minuto
• getFPS() periódicamente
• tomar una foto o un video de lo que está haciendo el usuario a través de una cámara web (ideal para pruebas de usabilidad automatizadas, solo con el permiso y la comprensión del usuario, por supuesto)
• obtener información del sistema (nuevamente, con permiso del usuario)

Lo de "trazarlo en un mapa" puede volverse realmente increíble después de un tiempo: imagina una vista aérea de un mapa RTS o FPS. Pon un control deslizante sobre él, que represente el tiempo desde el inicio del juego. Seleccione un tipo de evento ("consiguió oro", "mató a alguien", lo que sea). Seleccione un conjunto de datos: tal vez un juego, tal vez 500 juegos en los últimos meses. Comience a tirar del control deslizante hacia la derecha y vea la actividad aparecer en el mapa.

Y si no puede encontrar buenas bibliotecas para ayudarlo con estas cosas (¡hay bastantes aquí y allá, sin embargo!), Considere rodar la suya propia: es una buena experiencia de aprendizaje, y no necesita ser particularmente elegante ser útil.

Obtenga los datos, descubrirá qué hacer con ellos. =)

Por supuesto, esto depende mucho de ... a) qué tipo de prueba quieres que se haga, y b) qué tipo de juego estás probando, y c) qué tipo de probadores e infraestructura tienes disponibles ...

También difiere mucho si está probando a) funcionalidad, b) equilibrio c) diseño del juego

Pero en general es posible que desee considerar estos aspectos ...

* a) Elija a la persona adecuada para el trabajo Suena demasiado simple para mencionarlo, pero lo he visto muchas veces y solo lo he visto en vivo nuevamente. Como siempre, existen diferencias significativas entre las personas con respecto a lo buenos que son en diferentes trabajos. Es posible que algunas personas que estén dispuestas o que estén ansiosas por hacer las pruebas no jueguen lo suficiente como para encontrar errores inusuales (o incluso simples). Algunos no son buenos para describir los errores. Algunos son mejores para probar problemas de equilibrio, algunos son más atentos a las debilidades visuales, algunos son más creativos al jugar el juego de formas inusuales y encuentran errores ocultos / raros, algunos son más atentos a la calidad técnica o visual, algunos son mejores para comprender los aspectos de la mecánica del juego e incluso puede sugerir cambios significativos (si desea que sus evaluadores hagan eso;).

* b) Use un software Issue-Tracker / Bug-Tracker Estas herramientas no solo pueden ayudarlo a organizar sus problemas, sino también a aumentar la calidad de los resultados de sus evaluadores al brindarles un marco para trabajar y aprender de los comentarios que reciben de los desarrolladores sobre sus problemas. Ayuda a mejorar la calidad de la salida de sus probadores mucho más rápido que si trabaja sin él. (También ayuda mucho con los probadores remotos) El software típico utilizado por los estudios de juegos es, por ejemplo, Mantis, JIRA (y, por supuesto, muchos otros ...) Consulte Wikipedia para obtener una lista general y también esta publicación sobre SO.

c) Agregue herramientas de prueba dentro del juego. Típicos son los accesos directos para probar niveles o secciones específicas del juego. Mostrar información adicional durante el juego a los evaluadores para que puedan agregar esto a los informes de errores. Esta podría ser la posición en un nivel, el número de objetos activos en una escena, la cantidad de ram de textura o paletas actualmente en uso, cualquier cosa útil para los desarrolladores.

d) Combina probadores experimentados con sangre fresca Siempre es bueno tener probadores que tengan mucha experiencia con tu juego y hayan aprendido cuáles son los problemas típicos y cómo (re) probarlos. Al mismo tiempo, quieres nuevos jugadores "vírgenes" de vez en cuando, especialmente para el equilibrio.

e) Tener un administrador de pruebas Alguien que coordine el proceso y lo adapte al juego en cuestión, las prioridades actuales y los probadores disponibles y el entorno de prueba.

f) Tener un documento de plan de prueba Esto valdría una publicación adicional.

Como mencionó Tetrad, obtenga tantos datos objetivos como pueda. Poner ganchos para almacenar ciertos eventos y volcarlos a un .csv no es muy difícil. Y una vez que lo tenga en Excel, puede estudiar, graficar y trazar hasta que las vacas lleguen a casa.

Además, tenga preguntas específicas que quiera responder. Los científicos no solo se sientan, encienden algunos experimentos y "hacen ciencia". Tienen preguntas específicas y medibles sobre las que quieren datos. A menudo obtendrá el máximo provecho de las pruebas de juego si adopta el mismo enfoque. Intentar calcular si tu juego es "bueno" es muy difícil de cuantificar. Pero determinar si la misión del tutorial simple solo está tomando los 5 minutos que espera, o si los probadores están luchando por resolver un cierto rompecabezas, en realidad pueden evaluarse.

A veces, la forma más efectiva de probar es iterativamente en ráfagas cortas. Haga que un par de probadores pasen una hora más o menos por la mañana, haga algunos cambios en los problemas que identifiquen y vuelva con los probadores nuevos a la mañana siguiente. Obviamente tienes que estar mirando una característica lo suficientemente pequeña como para mejorar en una tarde. Pero para un problema que ha sido particularmente terco, este método puede ser muy exitoso.

Definitivamente de acuerdo con la regla de Tetrad # 1. No los ayudes. Yo diría que una advertencia es explicarles que no los ayudará, y si necesitan ayuda, por favor pregunte. De esta manera, el jugador no termina frustrado.

El Cuestionario debe hacer preguntas abiertas, en lugar de preguntas simples sí / no, dependiendo de la edad y el número de evaluadores, estos pueden ser formularios que completan, o puede hacer las preguntas. También es importante hacer preguntas sobre su historia y su familiaridad con el género del juego que les estás haciendo probar; esto agregará contexto a sus respuestas específicas sobre tu juego.

Afortunadamente, cuando mi juego falla, me da una descarga de información sobre el error, por lo que puedo tomar una foto de eso y tomar nota de lo que estaba haciendo el jugador. Normalmente pruebo grupos de edades más jóvenes, así que cuando tenemos un accidente tengo que recordar explicarles que están haciendo un gran trabajo: pueden enojarse después de romper el juego. Los jugadores de prueba realmente han demostrado ser excelentes para encontrar errores oscuros que el equipo de desarrollo nunca encontraría jugando al juego de la manera "correcta".

Es posible escribir código que detecte bloqueos y registre la pila de llamadas. Eso puede ayudar mucho con los informes de errores. Tener un archivo de registro útil generado también ayuda. Puede solicitar al usuario que envíe estos archivos la próxima vez que jueguen, o tener una herramienta independiente que se ejecute después de que el juego se cierre o se bloquee si lo desea.

Para los informes de fallas, debe confiar en el personal de control de calidad pagado, no en expertos de juego. QA es alguien que contrata específicamente por su capacidad para encontrar errores e informarlos de manera significativa, y un buen evaluador vale su peso en oro (¡y cuesta solo una décima parte de su peso en oro, en comparación con los programadores!).

Si le preocupa "oh, y si descubren accidentalmente un bloqueo, no querríamos perderlo solo porque no están probando eso" ... para eso está el registro. Un sistema de registro lo suficientemente bueno debería registrar suficientes elementos de juego para poder reproducir un bloqueo exactamente.

Para la retroalimentación de diseño, no hay sustituto para que sus diseñadores de juegos realmente los vean jugar (o usar una grabadora de video si es necesario, etc.). No confíes en la memoria u opinión de playtester, que son notoriamente pobres. Pero si los estás viendo jugar en tiempo real, es evidente que solo observando la postura de la cara y el cuerpo si están comprometidos, aburridos o frustrados.