Problemática Inicial

1. Juan Linietsky Problemática Inicial DESARROLLO DE VIDEOJUEGOS CON BAJO PRESUPUESTO

2. Problemática Inicial • Fantasía de un Desarrollador • Crear juegos llenos de contenido. • Estar al nivel tecnológico del primer mundo. • Investigar conceptos nuevos de gameplay. • Competir en el mercado AAA internacional. • Hacer el Half Life 2

3. Problemática Inicial • Realidad del Desarrollador. • No tiene un centavo, o cuenta con poco presupuesto. • No tiene experiencia en proyectos como el que quiere realizar. • Tiene poco tiempo, trabaja para ganarse el pan. • Estudia • Tiene un altar dedicado a John Carmack en su ropero, y todos los días le reza para ser como él, arrastrandose por el suelo y sollozando “no soy digno John”!

4. Problemática Inicial • Costos y Cifras • Los juegos AAA cuestan de 1 a 5 millones de U$S promedio. • Los “budget” games cuestan cientos de miles de dólares. • Los “casual games” cuestan decenas de miles de dólares. • Los costos de las herramientas de desarrollo alcanzan también los miles de dólares. • La extrema división/tercerización del trabajo es muy común en paises del primer mundo.

5. Problemática Inicial • Claves para abaratar costos: • Se debe bajar el costo del desarrollo. • Se debe bajar el costo de las herramientas. • Se debe reducir la cantidad de integrantes del mismo al mínimo indispensable. • Se debe planear el desarrollo de la manera mas predecible posible, para no quedar corto en recursos (tiempo y dinero) en su implementación. • Se debe cuidar la implementación y evitar retrasos sacrificando lo que lleve demasiado.

6. Problemática Inicial • Nuestras Ventajas: • Estamos en el tercer mundo • Podemos encontrar soluciones del tercer mundo. • La devaluación de la moneda es provechosa en caso de inversiones. • Los sueldos son bajos • La capacitación de los desarrolladores es muy alta.

7. Planificando el Desarrollo • Porqué el desarrollo debe ser predecible? • Evitar dificultades inesperadas. • Los inversionistas/publishers piden timelines. • Riesgo de caer en catch-up contínuo con la tecnología. • Los recursos (tiempo y dinero) asignados para un proyecto se pueden acabar. • El futuro propio/del país/del mundo/etc es incierto.

8. Planificando el Desarrollo • Eligiendo el Grupo de Trabajo: • Depende el desarrollo, pueden ser amigos, socios o empleados. • Los amigos / personas de confianza pueden no ser la mejor opción. Si bien es amigo, puede no trabajar bien. • Nunca dar por segura a una persona, es mejor esperar unos meses para comprobarlo. • Democratizar la toma de decisiones puede ser catastrófico. DEBE Haber liderazgo. • El BrainStorming puede resultar en pérdida de tiempo.

9. Planificando el Desarrollo • Eligiendo las Herramientas:Herramientas Pirata+ Más comunes y familiares + Riesgo de uso prácticamente nulo en este país. + Suelen ser mas fáciles de usar y aprender por principiantes. - Ilegal (si bien es una practica mas que común) - Suele ser ilegal desarrollar con herramientas pirata y legalizarlas luego. - Si el juego va a ser publicado internacionálmente, puede haber mayor riesgo legal. - Pueden generar sentimiento de culpa.

10. Planificando el Desarrollo • Eligiendo las Herramientas: • Herramientas Gratuitas / OpenSource + Gratis y libres de culpa. + Excelentes comunidades de ayuda / listas de correo. + Pueden ser modificadas a gusto. + Suelen correr en varias plataformas. + Ideales para usuarios avanzados. - Más difíciles de aprender en muchos casos. - Poco intuitivas. - No tanta documentación.

11. Planificando el Desarrollo • Panorama de Herramientas Gratuitas/Bajo Costo • Gráfica: • Blender 3D (reemplaza 3DSMAX / Maya) • The Gimp ( reemplaza Photoshop ) • MilkShake 3D (exportador/importador) • Art of Illusion • OpenCanvas (CG Drawing 70 dólares)

12. Planificando el Desarrollo • Panorama de Herramientas Gratuitas/Bajo CostoProgramación: • Línea de compiladores de GNU (gcc) • Subversion/CVS (administración de repositorios) • IDEs: Dev-C++ / Code::Blocks • FreePascal • Java/Eclipse • DarkBasic • Lenguajes de Scripting: LUA / Python / Scheme / Ruby/etc. pueden ser excelentes alternativas al VB.

13. Planificando el Desarrollo • Panorama de Herramientas Gratuitas/Bajo Costo • Audio: • Renoise (tracker/sequencer) • Rezound (editor de sonido) • CheeseTracker (tracker avanzado) • Kristal (DAW) • FL Studio (100 Dólares)

14. Planificando el Desarrollo • Diagramas de GanttVentajas: • Son útiles para la división y organización de tareas • Son útiles para reducir tiempos muertos de desarrollo • Son útiles para el seguimiento del proyecto. • Son útiles para determinar qué no fue de acuerdo a lo planeado. Desventajas: • Sin mucha experiencia previa, no son tan útiles para predecir tiempos de desarrollo. • El sofware para utilizarlos (Microsoft Project) es costoso.

15. Planificando el Desarrollo • Diagramas de Gantt:

16. Planificando el Desarrollo • UML (Unified Modeling Language) • Un videojuego tiende a ser demasiado grande para diagramarse completamente en UML. • UML es un set estandarizado de diagramas y metodologías comunes, no tienen por qué usarse todas. • Si el concepto del juego no está bien definido desde el principio, se vuelve más difícil de aplicar. • No hay un estándar de que herramientas UML que se use en el área de videojuegos, algunos desarrolladores prefieren unas más que otras. Otros no usan UML.

17. Planificando el Desarrollo • Diseño del juego: • Determinar por qué el juego va a ser jugado. • Determinar qué parte de la idea lo hace atractivo, sin haberlo jugado todavía. • Pero fundamentalmente, lo que se debe definir es: ¿POR QUÉ VA A SER DIVERTIDO?

18. Planificando el Desarrollo • Conceptos comunes de “diversión”: • Concepto de diversión del Game Designer: • Fórmulas, Recompensas, gameplay, atributos,etc • Concepto de diversión del Programador: • Física realista, Partículas, Shaders, etc. • Concepto de diversión del Artista (gráfico): • Personajes atractivos, Dragones de tres cabezas, Mundos inmersivos, etc. • Todos aportan, pero no definen una premisa.

19. Planificando el Desarrollo • Definiendo la Premisa Fundamental. • Los desarrollos de bajo costo no pueden darse el lujo de implementar varias premisas que hagan divertido a un juego. • La historia demuestra que una premisa muy divertida es más efectiva que cien aburridas. • La premisa es lo que define la originalidad como juego, no su contenido. • Cambiar la premisa a mitad del desarrollo puede ser tan inevitable como contraproducente.

20. Planificando el Desarrollo • Ejemplos de Premisas Fundamentales en Juegos: • Mario: Habilidad y libertad de movimiento • Doom: Matar, Matar y Matar demonios explorando. • Silent Hill/R.Evil: Sobrevivir, Asustar al Jugador • Metroid/Castlevania: Explorar un mundo interconectado • Tetris/Columns/Etc: Eliminar piezas que se acumulan • Katamari: Juntar cositas en el Katamari es enviciante. • Zelda: Vivir una aventura explorando un mundo • Dune/Warcraft/C&C: Crear y comandar un ejército. • Juegos de Deportes/Autos: Competir

21. Planificando el Desarrollo • Modelos de juegos y su efecto en el desarrollo: • Desarrollos muy predecibles: • Son aquellos que llegada una etapa temprana, es fácil determinar cuánto llevará el resto de la producción del mismo. • Desarrollos poco predecibles: • Son aquellos en que aún bien diseñados, se vuelve una incógnita saber cuándo se concluirán.

22. Planificando el Desarrollo • Factores del desarrollo predecible en un juego: • División en niveles: Si el juego está dividido en niveles, se vuelve fácil predecir el tiempo de creación de un nivel. Juegos que utilizan este recurso: • Juegos de Carreras (autos/naves/etc), Juegos de Plataformas (Mario/Spyro/etc), FPSs, Puzzle. • Habilidad: En muchos casos, el incremento de la dificultad de un juego (independientemente del género)se basa en forzar al jugador a pensar cada vez ms, en vez de introducir nuevos elementos.

23. Planificando el Desarrollo • Grafico del desarrollo predecible en un juego:Al desarrollar/crear un primer nivel/etapa completo, es fácil predecir el tiempo del resto.

24. Planificando el Desarrollo • Factores que hacen el desarrollo impredecible: • Juego ajustado a una historia: Asi como una pelicula, el guión puede ser modificado/ajustado durante el desarrollo. • Balance de atributos: El balance de atributos en un juego puede llevar tiempo indefinido. Mas aún el de unidades en un juego de estrategia. • Exploración: Nunca se puede terminar un area porque esta interconectada con otras.

25. Planificando el Desarrollo • Grafico de desarrollo poco predecible: • Como no se pueden usar etapas de referencia, es muy difícil predecir otras.

26. Implementación del Juego • Existen formas de acelerar la implementación: • Lograr que el juego sea divertido en etapas tempranas. • Usar estilos artísticos que lleven menos tiempo crear. • Crear herramientas que faciliten el trabajo artístico. • Programar aproximaciones en vez de simulaciones. • Aislar y evitar problemas en vez de resolverlos, sin abusarse.

27. Implementación del Juego • Logrando que el juego sea divertido: • Pulir el control o interfaz desde el principio. • Crear situaciones divertidas de prueba. • Hacer que otras personas lo jueguen y opinen. No cerrarse al feedback.

28. Implementación del Juego • Estilos artísticos que llevan menos tiempo. • Los gráficos “realistas” no son mejores. La “realidad” no se supone que sea “artística”. • Toon Shading y Gráficos Vectoriales evitan la compleja y tediosa tarea de texturar / detallar. • Usar herramientas, con las que si bien no se obtienen resultados perfectos, aceleran mucho el desarrollo . • En lo posible, pedir ayuda a quien programe para la creación de herramientas.

29. Implementación del Juego • Aproximar en vez de simular: • Lleva menos tiempo programar una aproximación de un comportamiento que simularlo, es el caso de: • Física • Colisiones • Inteligencia Artificial • Partículas • Continuidad de un area • Mientras no haga diferencia a la premisa del juego, aproximar puede ahorrar tiempo y frustraciones.

30. Implementación del Juego • Aislar y evitar problemas en vez de resolverlos: • Si dibujar/modelar un objeto es muy difícil y costoso, es mejor evitarlo o reemplazarlo por otro. • Si implementar gameplay features cuesta mucho tiempo de programación y no es esencial al juego, olvidarlo. • Si algun algoritmo no funciona en ciertos casos, puede ser mas fácil evitar dichos casos que rehacerlo o agregar parches.

31. Conclusión • Finálmente podemos decir que: • Bajar el tiempo y costo de un desarrollo es posible • Es teóricamente posible llegar a la calidad de juegos internacionales haciendo los sacrificios necesarios. • Es muy fácil mandarse macanas por no querer ceder en el área de contenido. • Desarrollar un juego es una experiencia personal, a veces sacrificamos tiempo por divertirnos!

32. Fin! Eso fue todo. Esperemos les haya gustado.