1 / 32

Problemática Inicial

Juan Linietsky. Problemática Inicial. DESARROLLO DE VIDEOJUEGOS CON BAJO PRESUPUESTO. 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.

waldo
Download Presentation

Problemática Inicial

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related