La mejor manera de probar casos simples en juegos

Al diseñar y probar un nuevo juego, la mayoría de las veces, las personas que prueban la funcionalidad se acostumbran a las cosas y ya no prueban las "formas tontas". Entonces, si el desarrollo rompe algo, puede ser una característica que solo un nuevo usuario se molestaría en probar. ¿Cuáles son algunas de las mejores formas de asegurarse de que su juego tenga sus "casos estúpidos" probados cuando finalmente se lance o después de una actualización importante? Metodología, asistencia de software, tal vez incluso sitios donde las personas jugarán y probarán por usted, etc.

Algunas cosas que diría son importantes:

Fomentar la prueba de la unidad del programador

Esto asegurará que ciertos errores estúpidos, si hay una prueba unitaria para ellos, no se repitan, porque la prueba unitaria fallará si lo hacen. Esto requiere un cambio en la metodología de programación, pero en mi opinión, vale la pena.

Automatice cualquier prueba que pueda

Más allá de las pruebas unitarias, cree un conjunto de funciones automatizadas y pruebas de aceptación que se ejecutan en cada compilación para asegurarse de que ciertas compilaciones sean buenas. Si tiene controles programables y su juego es generalmente consistente, puede probar muchos errores automáticamente.

Crear un plan de prueba multinivel

Asegúrese de que sus evaluadores tengan un plan de prueba que pruebe los errores más importantes. Esto debería ser de varios niveles:

• Prueba de humo: prueba que el juego no se bloquea en los casos más comunes.
• Prueba regular: prueba casos más infrecuentes.
• Prueba de remojo: Corre lo más profundo que puedas, haciendo retroceder tantos errores comunes como sea posible. Comprueba también que el juego puede permanecer encendido durante períodos de tiempo muy largos (días) sin fallar.

Cree este plan de prueba y sígalo en cada compilación.

Se puede hacer una especie de enfoque de cobertura de código para probar casos usando indicadores simples que se disparan una vez que el bloque de código se ha ejecutado en el juego. Mostrar qué indicadores se han activado y desactivado en la pantalla puede permitir a los evaluadores saber qué casos se han cubierto y cuáles no.

Tan simple como es, sigue siendo efectivo siempre que las banderas tengan nombres significativos para que los evaluadores puedan descubrir qué se supone que se debe hacer.

Esta técnica se le atribuye a Matthew Jack, quien la implementó en Crysis.

Varias buenas respuestas aquí en el lado de la programación. Agregaré uno que esté más orientado al diseño.

Haga que sus diseñadores de sistemas escriban planes de prueba de casos límite para probadores

Si saben lo que están haciendo, es muy probable que la persona detrás del diseño de un sistema, o de la secuencia de comandos de una secuencia en el juego, conozca los casos extremos de ese sistema y dónde podría fallar. También deberían tener una idea de dónde interactúa el sistema con los demás. Hacer que escriban un plan de prueba o que discutan con los evaluadores dónde es probable que las cosas salgan mal puede ahorrarles tiempo a todos.

Deberías investigar las llamadas pruebas de mono. Puede detectar muchos errores de este tipo:

https://secure.wikimedia.org/wikipedia/en/wiki/Monkey_test

También debes organizar las pruebas de experiencia del usuario con los "probadores de Kleenex", probadores que ven tu juego por primera vez y que nunca volverás a usar. Es un poco caro y complicado de organizar, pero vale la pena el esfuerzo. Si lo hace, filme cada prueba con 3 cámaras: una en la pantalla, una en los controles y otra en la cara del probador para detectar la frustración.

Gran pregunta, cada respuesta en este hilo es una excelente respuesta. Una cosa para agregar:

En mi experiencia (30 años de desarrollo de software): las aplicaciones y los juegos son más confiables si al menos un miembro del grupo de prueba es un experto probador de gorilas , experto en pruebas ad-hoc, abuso de aplicaciones y uso deliberado de juegos de la manera incorrecta para encontrar errores del tipo descrito por el póster original. Los probadores de gorilas tienen una habilidad poco común: cuando encuentres una buena, mantenla en tu equipo.

Para ver un ejemplo de pruebas efectivas de gorilas, consulte: www.youtube.com/watch?v=8C-e96m4730;)

Para resumir las respuestas en este hilo: las estrategias efectivas de calidad de software son multifacéticas , combinando múltiples enfoques para lograr un alto nivel de confianza en la calidad funcional y la confiabilidad de su juego.

Un truco interesante que escuché de un amigo para probar gráficos; durante una ejecución conocida de un nivel récord de estadísticas de rendimiento de la GPU a intervalos regulares (encuestas en la pantalla, por ejemplo). Luego puede reproducir esa ruta y si los números cambian fuera de una tolerancia dada, puede significar que algo ya no se muestra correctamente.

Una cosa simple y fácil que ayuda mucho, especialmente con las pruebas de estrés y las pruebas de red. Haz posible que tu IA juegue contra otra IA. Si puedes dejar tu juego solo jugando, o un pequeño grupo de IA en una red durante un fin de semana, puedes aprender mucho.

Por supuesto registrar todo.