¿El Test Driven Development es viable en el desarrollo de juegos?

23

Como estoy certificado por Scrum, tiendo a utilizar metodologías ágiles mientras desarrollo un sistema, e incluso utilizo algunos lienzos del marco de Scrum para administrar mi trabajo diario.

Además, me pregunto si TDD es una opción en el desarrollo de juegos, si es viable.

Si creo en esta pregunta de GD, TDD no es de mucha utilidad en el desarrollo de juegos.
¿Por qué MVC y TDD no se emplean más en la arquitectura del juego?

Vengo de la programación industrial donde los grandes proyectos con grandes presupuestos deben funcionar sin problemas, ya que podría dar lugar a escenarios catastróficos si el código no se probara exhaustivamente por dentro y por fuera.

Además, seguir las reglas de Scrum alienta el cumplimiento de las fechas de vencimiento de su trabajo, ¡mientras que cada acción en Scrum tiene un tiempo límite! Entonces, estoy de acuerdo cuando en la pregunta vinculada anteriormente dicen que dejen de intentar construir un sistema y comiencen a escribir el juego. Es todo lo que dice Scrum, primero trata de no construir el sistema perfecto: haz que funcione al final del Sprint. Luego, refactorice el código mientras trabaja en el segundo Sprint si es necesario.

Entiendo que si no todos los departamentos responsables del desarrollo del juego usan Scrum, Scrum se vuelve inútil. Pero consideremos por un momento que todos los departamentos usan Scrum ... Creo que TDD sería bueno para escribir código libre de errores, aunque no desea escribir el sistema / juego "perfecto".

Entonces mi pregunta es la siguiente:

¿TDD es viable en el desarrollo de juegos de todos modos?

architecture software-engineering methodology testing test-driven-development Will Marcouiller
fuente
¿Qué va a agregar la discusión de esta pregunta más allá de la pregunta que ha vinculado?
Presento el marco de Scrum de gestión de proyectos en el desarrollo de software ágil y discuto qué quiere Scrum de un desarrollador durante un Sprint, por lo tanto, hacer que TDD sea viable como una opción. Quiero obtener el punto de vista de los demás sobre el tema desde el punto de vista de Scrum, no solo bajo el aspecto TDD o MVC. Quiero entender cómo TDD no es viable cuando se discute desde este lado de la medalla, aparte de considerar a TDD en sí mismo como un enfoque independiente.
Will Marcouiller
@Will TDD == ¿Diseño de arriba hacia abajo o diseño impulsado por prueba? Estaba pensando en Top Down e iba a dar una respuesta de manejabilidad a largo plazo, pero luego vi que la otra respuesta interpretaba TDD de una manera que no estaba ...
James
@ James: Test Driven Development.
caos
@ James: Perdón por la confusión! No sabía sobre el otro significado del acrónimo, ya que lo que tenía en mente era Desarrollo ágil de software con Scrum.
Will Marcouiller

Respuestas:

11

Ciertamente es viable, aunque muchos programadores de juegos aún no se han embarcado en la idea, o tienen una buena comprensión de cómo probar sistemas complicados. Admito que rara vez lo uso, a excepción de los sistemas no relacionados con el juego que son fáciles de probar.

Espere usar muchos objetos simulados. Debido a lo unidos que están muchos sistemas, es difícil probar los componentes individuales de eso.

Además, muchas cosas no se pueden probar a fondo. ¿Cómo se prueba, por ejemplo, un sistema de partículas? ¿Cómo prueba que su sistema de animación funciona correctamente? Muchas cosas son de naturaleza visual y no son obvias (al menos para mí) en cuanto a cómo realizar las pruebas adecuadas.

Sin embargo, hay muchas cosas que no son necesariamente pruebas unitarias en el sentido tradicional de la palabra, pero que existen como "pruebas" para características específicas. Cosas como los niveles de prueba para la navegación AI son bastante comunes, pero no son necesariamente las cosas más fáciles de automatizar.

Hay ciertos aspectos de los juegos que pueden (y probablemente deberían) tener pruebas unitarias escritas para ellos. Cualquier tipo de sistema genérico de "lectura de archivos" debe ser probado. Tal vez tenga algunas pruebas para la inicialización de cosas de hardware (superficies 3d, etc.). Tal vez tenga algunos servidores simulados y pruebe su código de interacción cliente / servidor. Ese tipo de cosas.

Tétrada
fuente
99
Estas son grandes propuestas para la presencia de pruebas automatizadas, pero no para el desarrollo basado en pruebas.
1
Interesante opinión, Tetrad! Gracias por tu grano de sal. ¿Preguntas cómo probar la animación visual? Difícil de decir en cuanto a los sistemas 3D, ya que nunca he escrito un solo juego, ¡tal vez después de haber desarrollado algunos juegos pequeños! Además, en 2D, a menudo he visto objetos representados por matriz y analizadores de matriz para representar la imagen en la pantalla. Por lo tanto, me aseguro de que después de presionar algunas teclas direccionales, la información correcta que se encuentra en el lugar correcto en la matriz resultante podría ser un comienzo. Todavía no sé lo suficiente sobre los componentes visuales de un juego, ¡y seguro que lo sabré este año! =)
Will Marcouiller
Estoy de vuelta después de un poco de codificación para decir que he respondido una pregunta esta semana (la primera en GD! =)) Que requería conocimiento de los conceptos de OOP. El PO quería ir a una serpiente Keys.Down, Keys.Leftetc. Eso quiere decir que el juego sabe dónde está el usuario desea la serpiente para ir, y la serpiente tiene que ir donde el juego le dice que, sin embargo, que no es más que la serpiente que se sabe moverse en las diferentes direcciones, por lo tanto, también de su posición en el juego. Habiendo dicho esto, en mi humilde opinión, hace que la Snakeclase sea comprobable! (Continuará ...)
Will Marcouiller
No solo es comprobable, sino que ahora es un buen candidato para TDD. Digamos que la serpiente se inicializa en la posición Vector2.Zero, con una velocidad de los 10.0fejes X e Y en este juego 2D. La primera pregunta es: ¿está posicionado en su supuesta posición inicial y cómo probarlo? Entonces, usted piensa que la Positionpropiedad estará expuesta públicamente. Segundo: ¿cómo hacer que se mueva? Los métodos de movimiento deben ser buenos, por lo que debe escribir una prueba para cada método de dirección MoveDown, MoveLefty así sucesivamente. Ahora, vaya y escriba su declaración de método y vea si la prueba se queja. Luego, vuelva a verificar la posición de la serpiente
Will Marcouiller
después de una MoveDownllamada al método! Como sabe que la Positionpropiedad se ha probado exhaustivamente, ¡es un miembro con el que puede contar! ¡Puedes adivinar la continuación aquí! ;-) Es decir que los componentes visuales definitivamente no pueden ser probados, pero la serpiente debe verse como una serpiente, todo dependiendo de qué tipo de serpiente quieras en el juego. El artista que dibuja la serpiente debe demostrar la suficiente satisfacción con su dibujo de la serpiente, ¡eso no se probará a través de TDD, por supuesto! Pero su posición con respecto a otros objetos puede, y la clase que representa a esta serpiente también. De hecho, TDD
Will Marcouiller
11

No creo que TDD, como tal, sea apropiado como base para el desarrollo del juego. Las pruebas unitarias automatizadas como parte de la metodología, claro, pero muchas de las preocupaciones clave del desarrollo del juego son subjetivas y no pueden probarse en la máquina para que las pruebas sean el motor del desarrollo. ¿Cómo vas a escribir una prueba con guión para determinar si una mecánica de juego es divertida? ¿Que un nivel es visualmente atractivo? ¿Incluso si un nivel le toma a un jugador típico alrededor de 15 minutos en completarse? TDD se ajusta a situaciones en las que la madurez de un proyecto se puede medir cuantitativamente en términos de su cumplimiento de una especificación, y eso simplemente no es desarrollo de juegos.

caos
fuente
3
¿Qué quieres decir cuando dices que el desarrollo del juego no cumple con las especificaciones? Mi punto es que debes saber qué tipo de juego escribes cuando quieres escribir uno. Como tal, las especificaciones, los requisitos se escribirán como características o similares; Tomemos un ejemplo de Producto atrasado en Scrum. ¡Conoces las historias de usuario que tendrás que desarrollar en tu juego para escribir el juego esperado! Entonces, para otro ejemplo, quizás necesites detectar colisiones en un juego de lucha, ¡estas son cosas comprobables! Si el juego es divertido es más una historia o una programación, en mi humilde opinión.
Will Marcouiller
@Will Marcouiller: No quiero decir que no tengamos especificaciones o que no podamos medir el cumplimiento de las mismas, pero que menos de lo que es importante sobre el proyecto puede especificarse de manera significativa que en otros tipos de desarrollo. Puede escribir "el juego debería ser divertido" en su especificación, pero esa no es una especificación con significado técnico. Puede y debe probar lo que es comprobable, pero el punto de TDD es que la prueba no es solo parte del proceso, es la base completa del proceso, una mentalidad fundamental, y no veo que eso funcione bien con campo subjetivo
caos
2
@Will Marcouiller, estoy muy, muy en desacuerdo con que la diversión del juego se reduce a la historia. Toda la diversión del juego se reduce a la jugabilidad, la historia es solo una ventaja.
AttackingHobo
1
@Will: No, dice que el disfrute que un usuario obtiene de un juego no se puede determinar mediante una prueba automatizada, y que los juegos tienen grandes cantidades de cosas que solo se pueden probar enviando el juego a las manos del consumidor.
DeadMG
1
@DeadMG: Eso es más cierto de lo que a nadie le gustaría, pero mi punto (no necesariamente el de AttackingHobo) implica el hecho de que el proceso de desarrollo en sí mismo debe incorporar pruebas, por diseñadores y productores y desarrolladores y evaluadores, que no pueden cuantificarse en una unidad prueba, que tiene que ver con la calidad de la experiencia y la sensación y el estilo y el efecto estético que crea el juego. Decirle a la gente que están haciendo TDD cuando esa es una parte tan importante del desarrollo es básicamente mentirles.
caos
6

Es un poco difícil determinar exactamente lo que está preguntando, ya que el título trata exclusivamente de TDD, pero parece que también está haciendo de Scrum una parte integral de la pregunta, y según tengo entendido, uno no requiere el otro.

Si creo en esta pregunta de GD, TDD no es de mucha utilidad en el desarrollo de juegos.

Eso es correcto. No creo haber oído hablar de él en la práctica en la industria de los juegos. (Pero tampoco supe que se usara fuera de la industria de los juegos, solo por individuos).

Vengo de la programación industrial donde los grandes proyectos con grandes presupuestos deben funcionar sin problemas, ya que podría dar lugar a escenarios catastróficos si el código no se probara exhaustivamente por dentro y por fuera.

Los juegos no necesitan funcionar sin problemas. Por lo tanto, hay mucho menos énfasis en la corrección del código. TDD no garantiza la corrección del código, pero algunas personas sienten que reduce la incorrección. Todavía tengo que ver pruebas de esto.

Además, seguir las reglas de Scrum alienta el cumplimiento de las fechas de vencimiento de su trabajo, ¡mientras que cada acción en Scrum tiene un tiempo límite!

Nunca he visto una metodología que no alienta el cumplimiento de las fechas de vencimiento, o que tenga acciones que no hayan sido programadas. El problema es que no importa qué metodología uses, estimar la complejidad del software es bastante difícil. No es imposible, pero estimarlo con precisión no tiene mucho que ver con el proceso. Si mi tarea es agregar un nuevo panel GUI, o corregir un error con la animación, o agregar una nueva estadística a los personajes, entonces el uso de Scrum no va a acelerar eso en absoluto, y el uso de TDD va ralentizar la tarea (en el posible beneficio de reducir más tareas de mantenimiento más adelante). Ciertamente no van a facilitar la estimación de la duración de la tarea.

Creo que TDD sería bueno para escribir código libre de errores, aunque no desea escribir el sistema / juego "perfecto".

Si se ha demostrado que TDD escribe un código mejor que otros métodos, entonces sí.

¿Hay pruebas de esto? El hecho de que la industria pueda usarlo no es una prueba. La industria es conocida por producir código pobre que se entrega tarde. La ausencia de ejemplos de proyectos importantes de TDD que hayan fallado o se hayan retrasado puede deberse a que se trata de un nuevo enfoque y pocas personas realmente han terminado dicho proyecto todavía. (Y los que están llegando tarde ... aún pueden estar funcionando).

¿TDD es viable en el desarrollo de juegos de todos modos?

¿Viable? Por supuesto. ¿Beneficioso? Eso aún no se ha probado.

Kylotan
fuente
1
Desafortunadamente, TDD y Scrum todavía se malinterpretan. Y esto es cierto para los proyectos existentes que tampoco ayudarán a acelerar las correcciones de errores o de lo contrario. Scrum es un marco para desarrollar sistemas complejos, como parece ser un juego. Scrum fomenta la corrección de errores de un Sprint a otro para que nunca se acumulen. TDD te coloca del lado del usuario. Por usuario, me refiero a programadores colegas que usarán su código. Te obliga a pensar cómo debería usarse para hacer que tu código sea fácil de usar para otros. Por lo tanto, conduce a un mejor diseño, por experiencia. Dicho todo esto, tienes opiniones interesantes sobre el tema.
Will Marcouiller
1
Forzar que los errores no se acumulen solo hace que las características se deslicen: mágicamente no se puede producir más tiempo. Tengo entendido que Scrum no tiene ningún método en particular específico para errores de todos modos. En cuanto a que TDD lo obliga a pensar en cómo otras personas usarán su código, no es la única forma de hacerlo. Por lo tanto, no es necesariamente mejor, y ciertamente no es necesariamente el uso más efectivo del tiempo.
Kylotan
1
Para su información, Noel Llopis usa TDD para sus juegos independientes, y su antigua compañía High Moon Studios lo usó ampliamente. No tengo una cita, lo siento.
Tenpn
¡Tienes algunos buenos puntos interesantes para leer! Gracias por tu aporte. Sin embargo, me gustaría agregar que TDD es otro enfoque al igual que XP (programación extrema). Y sí, Scrum no proporciona ningún método en particular específico para errores, y más bien invierte en la autoorganización del Equipo (de desarrolladores). Scrum no te dice cómo hacer las cosas, solo dice lo que se debe hacer. Es el compromiso del equipo caminar a través de lo que se debe hacer. Scrum solo apuesta por equipos autoorganizados y multifuncionales. Es el equipo el que decide cómo se deben desarrollar y probar las características, etc.
Will Marcouiller
(continúe ...) He respondido mi primera pregunta esta semana sobre las clases aquí en GD. El OP quería saber cómo hacer que su sprite se moviera al presionar teclas direccionales. Sintiéndome cómodo con los conceptos de OOP, descubrí que tal vez debería usar clases para desarrollar mi primer juego usando XNA. Dicho esto, mi Spacecraftclase se convierte en una clase totalmente comprobable con métodos y propiedades. Este es el tipo de cosas que absolutamente, en mi humilde opinión, se pueden probar completamente con TDD. Digamos que necesita una nave espacial, luego escribe las pruebas de lo que necesita para realizar una prueba a la vez.
Will Marcouiller
4

perdón por mi pobre inglés y perdón por mi punto de vista parcial: no soy diseñador de juegos sino codificador.

Creo que hay algunos malentendidos en esta discusión. Hablaré sobre TDD en forma más general, el llamado BDD. El desarrollo impulsado por el comportamiento no es una forma de probar el proyecto (las pruebas son algo así como los efectos secundarios). BDD es una forma de diseñar , una forma de refactorizar y diseñar software durante toda la producción (ver algunos lemas como KISS, "mantener la calidad", "probar temprano, probar a menudo") y no en una sola fase. BDD es lo opuesto a algún proceso de software clásico como el proceso en cascada o alguna otra metodología iterativa para hacer software.

Otro punto es que las pruebas automáticas son para aquellas características que podrían ser probadas automáticamente por una máquina computacional. no hay prueba de diversión en los juegos, y no hay prueba de usabilidad de una interfaz gráfica de usuario. la diversión o la usabilidad son materiales para otros trabajos y no para el desarrollo de software como diseñador de interacción, mundo y nivel d. de la misma manera que las partes artísticas (modelado, texturizado, etc.) son para artistas que usan computadoras como herramienta para la creatividad, obviamente esos trabajos podrían ser realizados por la misma persona que escribe el código, pero este no es el punto. la física podría ser probada, los algoritmos de optimización podrían ser probados, los comportamientos de objetos individuales podrían ser probados (con simulacros, trozos y ficticio como se mencionó anteriormente)

Lo último que pienso es que, en mi opinión, no solo el diseño del juego sino todo el código de escritura es un arte.

nkint
fuente
4

Aquí hay un caso de estudio de alguien que piensa que TDD y gamedev se mezclan bastante bien:

http://powertwenty.com/kpd/downloads/TestDrivenDevelopmentInPython.pdf

Es cierto que este es un pequeño proyecto en Pygame, pero da la idea de qué partes se pueden probar con un juego gráfico y cuáles no. Me sorprendió lo mucho que se podía hacer con TDD en este escenario.

Brandon
fuente
1
Sin una comparación con un grupo de control que realizó el mismo proyecto (clonar un juego de arcade trivial existente en un lenguaje de muy alto nivel), no dice nada acerca de si TDD es efectivo o no. Solo dice que usó TDD.
3

No, Test Driven Development no es adecuado para Game Development. Claro que puede escribir pruebas para algunas partes que desea probar, pero el proceso de Desarrollo del juego es completamente diferente del Desarrollo conducido por prueba, que requiere tener especificaciones exactas antes de comenzar el progreso.

Los juegos rara vez tienen especificaciones exactas cuando se inician. Y si lo hacen, siempre cambian y evolucionan durante el proceso de desarrollo.

El diseño del juego es un arte, no puedes tener pruebas específicas para saber cuándo el arte es bueno o completo.

AttackingHobo
fuente
¿No crees que se debe considerar ese factor divertido al analizar el juego en sí, el análisis funcional o similares? ¡Puedes configurar un conjunto de características que juntas harán que el juego sea divertido de jugar, y estas características son entonces comprobables! Solo estoy tratando de presentar diferentes opiniones para profundizar sobre el tema y los argumentos que se te ocurren. Gracias por tu aporte! =)
Will Marcouiller
3
Mucho desarrollo se reduce a ajustar cosas pequeñas y ver lo divertidas que son para jugar. No puedes probar esas cosas a menos que estén 100% grabadas en piedra. Y probar un sistema después de que se haya hecho no es TDD, está probando, pero no es el Desarrollo el que está impulsado por las pruebas.
AttackingHobo
2
Si cree que la mayoría de los proyectos del mundo real tienen especificaciones exactas cuando comienzan, entonces probablemente no haya trabajado en muchos proyectos del mundo real.
BlueRaja - Danny Pflughoeft