Introducción a Test-Driven Development y los videojuegos presentada en el IWT2 Dojo US el 5 de octubre de 2.012

1. Desarrollo de
Videojuegos Dirigido
por Pruebas
TDD for Games Development

2. Desarrollo de Videojuegos Dirigido por Pruebas
• Aprender los conceptos
claves de TDD.
• Aprender conceptos
clave de los
videojuegos.
• Ver cómo aplicar TDD
en la programación de
un videojuego.
• Estudiar un ejemplo
práctico.
Objetivos
2

3. Resumen de la
Charla
3

4. Resumen de la Charla
• Programar un juego muy
sencillo usando TDD.
• Explicaremos primero TDD
• Usaremos LUA y Löve
(ideas aplicables a otros
entornos).
• NO entraremos en detalles
de LUA ni Löve.
4

5. Resumen de la Charla
Demasiado Constante Variable no
rápido equivocada declarada
Faltan enemigos
Mala lógica
5

6. Resumen de la Charla
• LUA: http://www.lua.org/
• Programming in LUA: http://www.lua.org/pil/
• Löve: https://love2d.org/
• Código fuente: e-mail
• Curso TDD desde cero:
http://www.iwt2.org/opencms/opencms/IWT2/
formacion/catalogo/curso0006.html?locale=es

7. 03. TDD
1. Resumen.
2. Conceptos generales
3. El Proceso TDD
4. TDD + Videojuegos
5. Comenzando un juego
en TDD
6. Un ejemplo más
avanzado
7. Conclusiones
Índice
7

8. Conceptos Generales
8

9. Definiciones
• ¿Qué es probar?
Para probar un programa
tenemos que ejecutarlo.
Verificación dinámica del La prueba tiene un límite.
comportamiento del
software a partir de un
conjunto finito de casos de No vale ejecutar el
prueba. programa de cualquier
manera.

10. Definiciones
Ejemplos de casos de pruebas en el mundo real
¿Funciona el teléfono?.
Valores de Acciones Resultado esperado
prueba
123-45-67-89 1. Descolgar auricular. (Pepote): “Digameee”.
2. Marcar número de Pepote.
3. Esperar contestación.
¿Me está bien esta camisa?
Valores de Acciones Resultado esperado
prueba
Mi cuerpo. 1. Ponerme la camisa. Elegancia y confort.
2. Abrochármela.
3. Moverme un poco.
4. Mirarme al espejo.
Cuidado con la etiqueta o con arrugarla
por si hay que devolverla

11. Definiciones
Necesidades Verifican
de los Pruebas de
aceptación
Qué se prueba. usuarios
Verifican
Paso a Pruebas de
producción implantación
Pr
ba
oc
ue
e
Verifican
so
pr
Requisitos del Pruebas de
de
sistema sistema
de
so
de
e
s
oc
arr
Pr
oll
Interacción Verifican Pruebas de
o
entre integración
componentes
Componentes Verifican Pruebas
aislados unitárias
Ensamblado Necesidades
Requisitos del Paso a
Código fuente de de los
componentes
sistema producción
usuarios Momento de
realizarla
Pruebas Pruebas de Pruebas de Pruebas de Pruebas de
unitarias integración sistema implantación Aceptación
Ejecución de las pruebas

12. Definiciones
• Pruebas unitarias:
– Cuando: Durante la construcción del sistema
– Objetivo: Comprueban la correcta unión de los
componentes entre sí a través de sus interfaces, y
si cumplen con la funcionalidad establecida .
• Ejemplo:
– Combinar el código de acceso a la base de datos
con el código de lógica de negocio y probar que
funciona correctamente.

13. Definiciones
• Pruebas de aceptación
– Cuando: Después de la implantación en el entorno
de producción
– Objetivo: Verifican que el sistema cumple con
todos los requisitos indicados y permite que los
usuarios del sistema den el visto bueno definitivo.
• Ejemplo:
– Que el sistema pueda realizra una venta
correctamente (ahora en el entorno de
producción).

14. Pruebas con LUA
Veamos un ejemplo muy sencillo
Valores de Acción Resultado
prueba
2, 3 Suma(2,3) 5
-1, 0 Suma (-1, 0) -1
… … …

15. El Proceso TDD
15

16. El Proceso TDD
No pensamos en qué software /
código tenemos que construir
Pensamos en cómo queremos
usarlo
El cómo usarlo nos las dan las No la diseñó quien la
pruebas. Las pruebas son las iba a utilizar
usuarias de nuestra creación

17. El Proceso TDD
• Suponemos que estamos escribiendo una prueba
para una clase que funciona como un carrito de la
compra que aún no ha sido escrita.
• Veamos un posible caso de prueba

18. 2. El Proceso TDD
• Estamos tomando decisiones .
• Decisiones sobre cómo crear un
carrito: ¿cuál es el nombre de la
clase? ¿Tendrá un constructor
sin parámetros?
• Decisiones sobre añadir
elementos:¿Usaremos una
llamada a un método? ¿cuál
será el nombre de ese método?
¿Qué parámetros tendrá y de
qué tipo serán?
Antes de escribir
• Decisiones sobre cómo
comprobamos que el carrito ha el código
almacenado el producto. ¿qué pensamos cómo
métodos incluimos,? ¿cuáles el queremos usarlo.
resultado esperado? ¿Hay que
escribir antes una prueba para
dicho método? 18

19. 2. El proceso TDD
El proceso de TDD
Es decir, los pasos que
vamos dando para ir
escribiendo nuevo
código
Veamos un ejemplo
completo paso a paso

20. 2. El Proceso TDD
Veamos un ejemplo. Vamos a sumar dos números
enteros. Lo primero según TDD, es escribir una nueva
prueba
No tenemos en
Valores de prueba Acción Resultado cuenta valores
A, b cuáles quiera Suma(a, b) a+b extremos
… … …

21. 2. El Proceso TDD
Autogeneramos el código que falta con Eclipse para poder
ejecutar la prueba.
Escribimos el código mínimo (más corto) para que la prueba
pase con éxito

22. 2. El Proceso TDD
¿Qué podemos refactorizar en este ejemplo?
Nombres más descriptivos para los parámetros
Arreglar atajos del código que
no requieren más pruebas

23. Código mínimo para Pasar una Prueba
• ¿Cómo escribir una prueba para un código
que no existe?
• Escribe una prueba para el código que te
gustaría que existiera.
– Hazlo tan simple como quieras.
– Con los parámetros y tipo devuelto que más fácil
te hagan el trabajo.

24. TDD + Videojuegos
24

25. ¿Esto se aplica a videojuegos?
Resolviendo niveles automáticamente
http://www.youtube.com/watch?v=DlkMs4ZHHr8 http://www.youtube.com/watch?v=NOTBy0lKSbo

26. ¿Esto se aplica a videojuegos?

27. ¿Esto se aplica a videojuegos?

28. Comenzando un
videojuego con
TDD
28

29. ¿Qué queremos conseguir?

30. ¿Qué queremos conseguir?

31. Framewrok: Löve + LUA
Dt es el delta-time o tiempo entre
dos llamadas. Lo usamos para
adaptar la velocidad del juego a la
máquina
Vamos a implementar estos
métodos para realizar el juego
anterior
Sólo con escribir estos tres métodos ya tenemos
juegos.
Aproximadamente 150 líneas de código.

32. ¿Por dónde empezamos?
• Nuestro primer paso no va a
ser muy distinto del segundo, Un jugador que se
mueva.
el tercero, etc. definimos una
prueba de aceptación. Disparos
• No vamos a intentar hacer Enemigos que se
muevan
todo el juego de golpe, pero
sí elegiremos una Colisión de disparos y
enemigos.
característica que tenga valor
y relevancia en el juego. Fin del juego
• Apuntemos las candidatas:

33. TDD en Juegos
• Ten siempre una lista de
Un jugador que se características o requisitos de
mueva. código.
Disparos • Eso son cosas que se te van
Enemigos que se ocurriendo cuando escribes
muevan pruebas y escribes código
para superar las pruebas.
Colisión de disparos y
enemigos. • Te ayuda a no tener cosas en
la cabeza y céntrate en seguir
Fin del juego tu foco
• Te indican qué es lo siguiente
a realizar

34. TDD en Juegos
Un jugador que se
mueva.
Disparos
Enemigos que se
muevan
Colisión de disparos y
enemigos.
Fin del juego

35. TDD en Juegos
Un jugador que se
mueva.
Disparos
Enemigos que se
muevan
Colisión de disparos y Un fondo negro
enemigos.
Un cuadrado rojo
Fin del juego
El cuadrado en el centro y
en la parte baja de la
pantalla
Si pulso  mueve a la
derecha
Posibles pruebasmueve a la
Si pulso 

36. TDD en Juegos
Escribimos el esqueleto d enuestro primer conjunto de pruebas
Un fondo negro
Un cuadrado rojo
El cuadrado en el centro y
en la parte baja de la
pantalla
Si pulso  mueve a la
derecha
Si pulso  mueve a la
izquierda

37. TDD en Juegos
Ejecutamos prueba y falla.
Sólo necesitamos una línea para arreglarlo en el archivo main.lua:
BgColor = {}

38. ¿Por dónde empezamos?
Un jugador que se
mueva.
Disparos
Enemigos que se
muevan
Colisión de disparos y Un fondo negro
enemigos.
Un cuadrado rojo
Fin del juego
El cuadrado en el centro y
en la parte baja de la
pantalla
Si pulso  mueve a la
derecha
Posibles pruebasmueve a la
Si pulso 

39. ¿Por dónde empezamos?
Escribimos el esqueleto de nuestro primer conjunto de pruebas
Un fondo negro Falla
Un cuadrado rojo
El cuadrado en el centro y
en la parte baja de la
pantalla
Si pulso  mueve a la
derecha
Pasa
Si pulso  mueve a la
izquierda
Decidimos el
diseño.

40. Un ejemplo más
avanzado
40

41. Un ejemplo más avanzado
Los aliens mueven en una
dirección.
Cuando el primer alien llega
al borde de la pantalla,
todos bajan hacia abajo y
mueven en otra dirección
Cuando llegan al límite
inferior se acaba el juego
¿Cómo quiero
hacerlo?

42. Un ejemplo más avanzado
Crear a los
aliens
Estamos probando
este escenario
Pero podemos probar Escribimos nuevas
otros escenarios
pruebas para
escribir el código

43. Un ejemplo más avanzado
Aliens[1..8]
Aliens[9..16]
Aliens[33..40]

44. Un ejemplo más avanzado
Valores de prueba (*) Acción Resultado esperado
D = Der Mover en la dirección Todos los aliens han
AmE. X < Límite incrementado su X en 1.
AmB.Y < Límite
D = Der Cambiar dirección y D = Izq.
AmE. X == Límite bajar Todos los aliens han
AmB.Y < Límite incrementado su Y en 1.
D = Der Mover en la dirección Todos los aliens han
AmE. X < Límite incrementado su X en 1.
AmB.Y < Límite
… … …
Lo que influye en el movimiento es la dirección, altura (coordenada Y)
del alien más bajo y la coordenada X del alien más en el extremo

45. Un ejemplo más avanzado

46. Un ejemplo más avanzado

47. Un ejemplo más avanzado
Este método ya está terminado. Pasamos a otra tarea.

48. Conclusiones
48

49. Conclusiones
• Fallos que tengo escribiendo juegos.
– Escribo más nombres de variables (y se crean nuevas
variables sin yo saberlo)
– Me equivoco en operaciones aritméticas (sumas,
restas, etc.)
– Me equivoco utilizando constantes
– Utilizo variables que, en otra parte del código, dejer
de utilizar
– A veces no sé si se está entrando en un if o ejecutando
un código determinado.
– En general, LUA escala mal.

50. Conclusiones
El proceso de TDD
Es decir, los pasos que
vamos dando para ir
escribiendo nuevo
código

51. Conclusiones
10.000 líneas de código C#...
Comprobado…. 124 assemblies .NET Ahora que mis pruebas unitarias
generados…. Comprobado…. 52 están escritas puedo empezar a
scripts de construcción… construir mis componentes.
comprobado