EVA 2003 - ADVA1 Ingeniería de Software… ¿Vale la pena en el desarrollo de juegos? por Martín Massera (NGD studios)

Presentación del tema: "EVA 2003 - ADVA1 Ingeniería de Software… ¿Vale la pena en el desarrollo de juegos? por Martín Massera (NGD studios)"— Transcripción de la presentación:

1 EVA 2003 - ADVA1 Ingeniería de Software… ¿Vale la pena en el desarrollo de juegos? por Martín Massera (NGD studios)

2 EVA 2003 - ADVA2 o… Desarrollo de juegos en grandes equipos

3 EVA 2003 - ADVA3 ¿Por qué esta charla? ADVA: Transmitir la experiencia Para quienes quieren empezar un proyecto Ingenieria de software, gralmente poco conocida por programadores amateur

4 EVA 2003 - ADVA4 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 EVA 2003 - ADVA5 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 EVA 2003 - ADVA6 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 EVA 2003 - ADVA7 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 EVA 2003 - ADVA8 Ciclo de vida Diseño / Desarrollo Instalación Operación Retiro

9 EVA 2003 - ADVA9 ¿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 EVA 2003 - ADVA10 “Dicen que soy aburrido” Supuestas contras: rigidez en el proceso quita creatividad Más proceso = menos desarrollo

11 EVA 2003 - ADVA11 Sobre qué trata la I. S. Análisis de requerimientos Manejo de riesgos Especificación Diseño / arquitectura Implementación Testing

12 EVA 2003 - ADVA12 Y no nos olvidemos del… Proceso de desarrollo!

13 EVA 2003 - ADVA13 En juegos Requerimientos: game design Testing: mucho beta testing, muy poco del resto “Otros”: Es importante manuales, cajas, promotoras en E3, etc.

14 EVA 2003 - ADVA14 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 EVA 2003 - ADVA15 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 EVA 2003 - ADVA16 Distintos atributos de calidad Internos vs externos Ej: Performance (FPS) Estabilidad (cuelgues) Arquitectura “Amigabilidad” con el usuario Y… diversión!!! La gran diferencia

17 EVA 2003 - ADVA17 Calidad, servicio y limpieza La calidad depende de muchas cosas. Ejemplo: Target de usuario Tipo de juego. No siempre hay que ser carmack

18 EVA 2003 - ADVA18 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 EVA 2003 - ADVA19 Todo esto para alcanzar El nirvana de los programadores de juegos!

20 EVA 2003 - ADVA20 Proceso de desarrollo Cascada Iterativo Milestones Distintas formas de ir asegurando la calidad

21 EVA 2003 - ADVA21 Cascada Análisis de requerimientos Diseño Implementación Testing Demasiado utópico: una fase puede cambiar cosas de las anteriores

22 EVA 2003 - ADVA22 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 EVA 2003 - ADVA23 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 EVA 2003 - ADVA24 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 EVA 2003 - ADVA25 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 EVA 2003 - ADVA26 Diseño / Arquitectura Arquitectura: distintas vistas Módulos Ejecución Conceptual Etc Más alto nivel Diseño: ya entrando en detalle

27 EVA 2003 - ADVA27 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 EVA 2003 - ADVA28 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 EVA 2003 - ADVA29 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 EVA 2003 - ADVA30 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 EVA 2003 - ADVA31 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 EVA 2003 - ADVA32 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 EVA 2003 - ADVA33 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 EVA 2003 - ADVA34 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 EVA 2003 - ADVA35 Conclusiones Vale la pena!!! Aunque no todo es útil para juegos... Seleccionar las herramientas/métodos

36 EVA 2003 - ADVA36 Conclusiones excepciones: Software de alcance muy cortito plataformas donde no nos podemos dar el lujo de ciertas abstracciones por temas de eficiencia

37 EVA 2003 - ADVA37 Bibliografía “Fundamentals of Software Engineering” Ghezzi, Jazayeri y Mandrioli “Game Architecture and Design” Andrew Rollings y Dave Morris

38 EVA 2003 - ADVA38 Preguntas mmassera@dc.uba.ar