Ingenier

1
Ingeniería de SoftwareVale la pena en el
desarrollo de juegos?

• por
• Martín Massera (NGD studios)

2
o

• Desarrollo de juegos en grandes equipos

3
Por qué esta charla?

• ADVA Transmitir la experiencia
• Para quienes quieren empezar un proyecto
• Ingenieria de software, gralmente poco conocida
  por programadores amateur

4
Introducción a la ingeniería de software

• Un poco de historia la software crisis
• varios interrogantes
• Qué tienen que ver programar bien con buen
  software?
• Cómo manejar un proyecto grande para
• que haga lo que tiene que hacer?
• que sea estable?
• Que sea terminado a tiempo?

5
Historia de los videojuegos

• Empezó más tarde que el resto de la industria,
  pero la historia se repite.
• Pocas plataformas donde una persona sola puede
  terminar un juego.

6
Diferencias entre videojuegos y otro software

• Objetivo divertir
• Es un arte
• El prototipo del desarrollador
• Hay diferencias, pero no tanto a nivel de
  programación

7
Qué es la I.S.?

• Conjunto de teorías, métodos, herramientas, etc.
  para producir software con la calidad deseada.
• Además, facilitan todo el ciclo de vida de un
  software.

8
Ciclo de vida

• Diseño / Desarrollo
• Instalación
• Operación
• Retiro

9
Por qué esta charla? bis

• La I.S. proviene de la experiencia de otros
  desarrolladores (Best Practices)
• No silver bullet
• Es necesario encontrar soluciones para el
  desarrollo de videojuegos

10
Dicen que soy aburrido

• Supuestas contras
• rigidez en el proceso
• quita creatividad
• Más proceso menos desarrollo

11
Sobre qué trata la I. S.

• Análisis de requerimientos
• Manejo de riesgos
• Especificación
• Diseño / arquitectura
• Implementación
• Testing

12
Y no nos olvidemos del

• Proceso de desarrollo!

13
En juegos

• Requerimientos game design
• Testing mucho beta testing, muy poco del resto
• Otros Es importante
• manuales, cajas, promotoras en E3, etc.

14
En juegos

• Especificacion por qué no se hace?
• Tiempo de vida de los juegos
• Nivel académico requerido
• Riesgos muy importante en proyectos largos
• Implementacion esta parte es casi igual al resto
  del software

15
Calidad del software

• Hay que expresar la calidad deseada para poder
  alcanzarla
• Una vez establecida la calidad deseada, la
  calidad final es producto directo de la calidad
  del proceso de desarrollo
• Calidad vs tiempo vs presupuesto

16
Distintos atributos de calidad

• Internos vs externos
• Ej
• Performance (FPS)
• Estabilidad (cuelgues)
• Arquitectura
• Amigabilidad con el usuario
• Y diversión!!! La gran diferencia

17
Calidad, servicio y limpieza

• La calidad depende de muchas cosas. Ejemplo
• Target de usuario
• Tipo de juego.
• No siempre hay que ser carmack

18
Prueba y error

• Hay que planear para obtener la calidad deseada.
• Engines dificil de optimizar si no se penso en
  la velocidad desde el principio
• Prueba y error sirve en algunos casos (ej
  balanceo de gameplay)

19
Todo esto para alcanzar

• El nirvana de los programadores de juegos!

20
Proceso de desarrollo

• Cascada
• Iterativo
• Milestones
• Distintas formas de ir asegurando la calidad

21
Cascada

• Análisis de requerimientos
• Diseño
• Implementación
• Testing
• Demasiado utópico una fase puede cambiar cosas
  de las anteriores

22
Iterativo

• Una sucesión de cascadas
• Requerimientos 1? diseño 1? implementación 1?
  testing 1 ?
• Requerimientos 2? diseño 2? implementación 2?
  testing 2 ?
• Requerimientos 3? diseño 3? implementación 3?
  testing 3 ?etc

23
Milestones

• Dividir la fase de implementación en partes
• El resultado de cada parte es un ejecutable
  estable (aunque con menos features)
• Previenen la avalancha de bugs

24
Equipo de desarrollo

• Comunicación entre programadores
• Personalidades conflictivas
• Espíritu de equipo
• Comunicación con artistas / game designers
• El papel es tu amigo
• Responsabilidades, no todos hacen todo

25
Game design / requerimientos

• Game design disciplina independiente
• Análisis de requerimientos Game design y no
  tanto, distintas clases de requerimientos mas
  cerca de la implementación o del game design
• Un error en los requerimientos es muy dificil de
  corregir después (ej. No considerar multiplayer)

26
Diseño / Arquitectura

• Arquitectura distintas vistas
• Módulos
• Ejecución
• Conceptual
• Etc
• Más alto nivel
• Diseño ya entrando en detalle

27
Diseño / Arquitectura

• Definen el esqueleto del programa
• Patrones
• Estilos arquitectónicos
• Otras clases de software parecidas
• Simulación
• Sistemas de tiempo real
• Herramientas UML

28
Diseño / Arquitectura

• Diseñar para
• Velocidad
• Estabilidad
• Cambios (en el game design y segundas partes)
• Desafío Abstraer la tecnología de base
• No cambió el gameplay tanto como las placas 3D
• Cohesión vs acoplamiento
• No hardcodees mañana lo que puedes diseñar hoy

29
Implementación

• Un pequeño pero importante detalle
• A esta altura, todo o definido
• Los cambios a distintas etapas tiene que ser
  registrado (y no con comentarios en el código ?)

30
Herramientas que ayudan

• IDE de desarrollo (Kdevelop, Visual studio)
• Compilación distribuida (IncrediBuild)
• Chequeo de memoria dinámica (Bounds checker)
• Análisis de performance (Vtune)
• Control de versiones (CVS)
• Reporte de bugs, TO-DO list, wiki, foro, feedback

31
Errores

• En gral los errores son faciles de corregir solo
  si se detectan en la misma fase en que se hacen
• Hay que testear el game design

32
Verificacion / Testing

• El testing no puede demostrar la correctitud de
  un programa, solo sus errores
• Viejo y querido beta testing
• Otras cosas
• Regresion
• Integracion
• Unidad

33
Verificacion / Testing

• En general se deja de lado por falta de tiempo
• Hay herramientas
• assert
• cppunit
• Los bugs pueden
• Colgar el programa
• Arruinar la experiencia del jugador

34
Problema del testing en videojuegos

• Muchas veces resultados gráficos
• Bugs difíciles de reproducir
• La arquitectura tiene que estar pensada para
  corregir errores (logueo, saves, etc)

35
Conclusiones

• Vale la pena!!!
• Aunque no todo es útil para juegos... Seleccionar
  las herramientas/métodos

36
Conclusiones

• excepciones
• Software de alcance muy cortito
• plataformas donde no nos podemos dar el lujo de
  ciertas abstracciones por temas de eficiencia

37
Bibliografía

• Fundamentals of Software Engineering
• Ghezzi, Jazayeri y Mandrioli
• Game Architecture and Design
• Andrew Rollings y Dave Morris

38
Preguntas

• mmassera_at_dc.uba.ar