• Author / Uploaded
• Juan Daniel Vargas

Citation preview

     

METODOLOGÍAS DE DESARROLLO DE VIDEOJUEGOS

 

 

CONTEXTUALIZACIÓN En sus comienzos, los videojuegos no eran más que juguetes desarrollados por programadores con relativa experiencia, que tenían una calidad gráfica aceptable, sin muchas pretensiones en sonido y jugabilidad. Hoy en día, son uno de los medios de entretenimiento más importantes, al punto que han superado en ventas a la industria del cine (Otter, 2008). En esa medida, el desarrollo de los videojuegos involucra una diversidad de disciplinas que van desde las ciencias exactas, hasta las distintas artes (visuales, literarias y musicales), haciendo que sea necesario gestionar sistemas de organización, que permitan encausar en una misma ruta tales disciplinas y oriente en etapas el trabajo del equipo. En la actualidad, se utilizan metodologías ágiles de desarrollo que permiten grandes resultados, rapidez en su ejecución y eficiencia en su implementación, de tal modo, nuestro objetivo en el presente material de formación será: Identificar las distintas metodologías para el desarrollo de un videojuego. Para cumplir tal propósito, estudiaremos algunas metodologías revisando cuidadosamente su definición, ventajas, técnicas y formas de aplicación.  

 

 

CONTENIDOS Metodologías de desarrollo Un videojuego, independiente del género al cual pertenece o la plataforma en que trabaja, es una aplicación de software cuyo desarrollo obedece a la utilización de ciertas metodologías de trabajo. A continuación, estudiaremos algunas:

1. Waterfall process o Modelo de cascada El modelo de cascada es una secuencia de diseño de procesos, enfocado en el orden y desarrollo riguroso de cada una de sus fases, las cuales se describen a continuación:

Managed,  M.  (2009).  Esquema  de  cascada  [Infografía].  Recuperado  el  5  de  junio  de  2009,  de:   http://www.managedmayhem.com/2009/05/06/sashimi-­‐waterfall-­‐software-­‐development-­‐process/  

 

 

Análisis de Requerimientos: Se analizan las necesidades de los posibles usuarios para determinar qué necesidades debe cubrir el videojuego. Diseño y arquitectura: Se descompone y organiza el sistema en elementos para ser trabajados por separado. Desarrollo y programación: Se desarrolla la programación y construcción de prototipos. Pruebas y aseguramiento de Calidad: Se aplica un test para verificar la presencia de errores en el videojuego, ya sea a nivel de programación o de jugabilidad. Implementación: Corresponde al compilado de la aplicación del juego y su utilización por parte del usuario. Mantenimiento: Se realizan seguimientos al videojuego para generar paquetes de correcciones y extensiones con mejoras. La mayor desventaja de este proceso, es la tendencia a retardar el desarrollo del videojuego, ya que cualquier error en determinada etapa sugiere volver a procesos anteriores.

2. Spiral model o Modelo espiral Este modelo creado por Barry Boehm, es un proceso de desarrollo de software que combina elementos de diseño y creación de prototipos en etapas, que da especial énfasis a las áreas claves (Boehm, 1986). El modelo en espiral pasa por una serie de iteraciones que se pueden representar en cuatro fases:  

 

 

Cortes,  A.  (2012).  Metodología  en  Espiral.  [Infografía].  

Definición de objetivos: Se describen los objetivos de la aplicación y las posibles restricciones al desarrollo del proyecto. Análisis de riesgos: Se identifican los riesgos y las posibilidades para solucionarlos. Desarrollo y prueba: Se pone en práctica las tareas de desarrollo. Una vez ha concluido el producto de una iteración, hay una verificación de sus prestaciones. Planificación de la siguiente iteración: De acuerdo a los resultados que arroje la actual iteración, se planifica el desarrollo de la siguiente. En la anterior imagen podemos observar un proceso de desarrollo donde cada etapa itera en espiral, dando como resultado una evolución cada vez más perfecta del producto final. El método en espiral combina las ventajas del método de Arriba – Abajo y de Abajo – Arriba (top-down and bottom-up concepts). El primero consiste en el análisis y descomposición, es decir en la ruptura de un sistema para conocer mejor la estructura de sus subsistemas. El segundo, pretende generar una síntesis de los sistemas para dar lugar a unos más complejos.

 

 

3. Rational Unified Process Es un proceso iterativo de desarrollo de software creado inicialmente por IBM. Se basa en la definición de módulos de contenido, donde cada uno se adapta a las necesidades del equipo de trabajo (Kruchten, 2004). Un proyecto bajo esta metodología posee cuatro fases en su ciclo de vida:

Hostzi  (2012).  Esquema  RUP  [Infografía].  Recuperado  el  3  de  agosto  de  2012  de:   http://erzh.hostzi.com/index/rup.html  

En el esquema se muestra las diferentes etapas del proceso, los elementos de estudio que comprenden cada una y su comportamiento. Igualmente, los picos de la gráfica representan los procesos críticos de estos. Inicio: Es una etapa objetiva donde se determina la viabilidad del proyecto en términos de recursos, presupuesto y modelo de negocio. Elaboración: Se gestionan los esquemas de arquitectura, dándole forma general al proyecto. Incluso se definen versiones preliminares de manual de usuario para optimizar la idea inicial de la aplicación y mitigar los riesgos identificados en la etapa inicial.

 

 

Construcción: Se centra en el desarrollo de componentes y de una programación más compleja. Transición: Se realizan pruebas de aplicación y un acercamiento al usuario final, con el objetivo de afinar el producto con respecto a sus expectativas. Se pueden identificar tres bloques de construcción:

Roles  

Productos  de  trabajo  

Tareas    

De(ine  un  conjunto  de  funciones  de   acuerdo  a  las  habilidades,  competencias,   conocimientos  y  responsabilidades.  

Es  lo  que  se  espera  lograr  de  una  tarea   especí(ica.  

Comprende  las  acciones  realizadas,     de(iniendo  un  resultado  signi(icativo.    

4. Essential Unified Process EssUP Esta metodología fue inventada por Ivar Jacobson como una mejora en el Rational Unified Process, en donde integra los elementos que considera asertivos de las metodologías CMMI o modelo de madurez de la capacidad de integración, la de Desarrollo ágil y el Proceso Racional Unificado (RUP). En esencia, plantea que los procesos de desarrollo pueden ser versátiles en la implementación de acciones, es decir, que el diseño de tareas y prácticas pueden combinarse según los requerimientos generales.

 

 

Agile  modeling  (2012).  Esquema  EssUPScrum  [Infografía].  Recuperado  el  21  de  agosto  de  2012  de:   http://www.agilemodeling.com/essays/agileModelingRUP.htm  

En esta gráfica se observa la inclusión de disciplinas al modelo esencial de procesos ágiles, involucrando aspectos de gestión empresarial y de negocios.

5. OpenUP Es un método utilizado por la Fundación Eclipse, que se fundamenta en la inclusión de contenido básico y vital en el proceso, utilizando un mínimo de esfuerzo en la consecución, inclusión y gestión de recursos de información. La mayoría de los elementos de OpenUP fomentan el intercambio de información entre los equipos de desarrollo, por ello todos sus miembros conocen el proyecto, sus objetivos, alcances y avances. El método OpenUp se basa en los siguientes principios: Diálogo para acordar intereses y compartir conocimientos.

 

 

Determinación de prioridades de trabajo para maximizar el beneficio obtenido por los interesados en el proyecto. Énfasis en la arquitectura para minimizar los riesgos y organizar el desarrollo. Planteamiento de un proceso evolutivo para obtener retroalimentación y mejoramiento continúo.

 MGallen  (2006).  Esquema  OpenUp  [Infografía].  Recuperado  de:   http://www.agilemodeling.com/essays/agileModelingRUP.htm  

En esta imagen podemos observar la forma como los microincrementos se relacionan con los ciclos de iteración y estos últimos, con el ciclo de vida del proyecto. Los microincrementos son pequeñas evoluciones en el proceso de desarrollo, los cuales comprenden tareas de solución a problemas puntuales de poca envergadura.  

 

 

6. Team Software Process TSP La versión inicial del TSP fue planteada por Watts Humphrey en 1996, proporciona un marco de trabajo de procesos definidos y estructurados que indican qué hacer en cada fase del desarrollo del proyecto, mostrando cómo conectar cada una de estas para construir un producto completo. El objetivo principal de TSP es completar con éxito a través de varios ciclos de desarrollo incremental, un proyecto de software de calidad, siguiendo el proceso y manteniendo un espíritu de trabajo colaborativo (Humphrey, 2000).

  Gómez,  A  (2009).  Esquema  TSP  [Infografía].  Recuperado  de:   http://4.bp.blogspot.com/_7hmOnhlTndM/Svm9oXKDzKI/AAAAAAAAABw/7mlyBVbnzXA/s1600-­‐h/1.jpg  

En la siguiente imagen puede visualizarse la diferencia entre el modelo PSP (Personal Software Process), que permite un control de trabajo de cada miembro del equipo y el modelo TSP (Team Software Process).  

 

 

7. Microsoft Solution Framework Es una serie de principios, modelos, conceptos y guías para diseñar aplicaciones bajo Windows (Keeton, 2006). Este método permite el desarrollo rápido y la refinación del producto, debido al conocimiento progresivo de los requerimientos de los clientes. Se basa principalmente en los modelos espiral y cascada (hitos y fases) y tiene como principios fundamentales la comunicación (cliente/usuario y desarrolladores), la capacitación de las personas (disciplina de disponibilidad), por ello, hay una formación del personal, la definición de los roles entre todo el equipo de trabajo y una inversión de calidad (tiempo, trabajo, dinero).

 Conamex  (2006).  Esquema  MSF  [Infografía].  Recuperado  de:  

http://www.conamex.com/solutions/4_0.htm  

En este esquema podemos observar el modelo de Microsoft solution framework basado en fases y eventos. Las fases plantean una división general del desarrollo del videojuego, mientras que los eventos, son los sucesos y circunstancias que de forma puntual desencadenan el inicio o terminación de una fase.

 

 

8. Agile software development El desarrollo ágil de software es un conjunto de métodos basado en el desarrollo iterativo e incremental, donde se evoluciona gracias a la auto-organización y la conformación de unos equipos multidisciplinarios. Igualmente, este método se centra en la respuesta rápida al cambio y el desarrollo continuo. Una de sus técnicas consiste en utilizar la programación en pareja, permitiendo solucionar de forma eficaz los esquemas de programación.

Tech  Jini  (2006).  Esquema    Metodología  ágil  [Infografía].  Recuperado  de:   http://www.techjini.com/ourapproach-­‐methodologies.html  

 

 

 

9. Extreme Programming (XP) Este enfoque de la ingeniería de software formulado por Kent Beck es uno de los sistemas más importantes de los procesos ágiles. Se enfoca en la adaptabilidad más que en la previsibilidad, por ello plantea que es más viable adaptarse a los cambios de requerimientos en cualquier punto del ciclo de vida del proyecto, que intentar plantear todos los requisitos desde el comienzo, generando esfuerzos para controlar los cambios.

Nosexybot,  J  (2006).  Esquema  XP  [Infografía].  Recuperado  de:  

http://nosexybot.blogspot.com/2012/04/extreme-­‐programming-­‐xp.html  

En esta imagen se puede observar cómo en el ciclo de desarrollo desde la escritura de código hasta el lanzamiento de una versión jugable del producto, se presenta una serie de procesos que poseen un rango de duración en el tiempo, que necesitan lapsos de respuesta predefinidos.

 

 

Extreme Programming tiene una serie de características que son importantes mencionar: Desarrollo iterativo e incremental: Pequeños ciclos de desarrollo que ofrecen mejoras, proporcionando mayor agilidad y eficiencia a largo plazo. Pruebas unitarias: Pruebas de código repetidas y automatizadas que incluye regresiones, las cuales intentan descubrir las causas de nuevos errores, problemas de funcionalidad o divergencias funcionales respecto a los requerimientos originales. Programación en parejas: Es una técnica que se enfoca en la programación de código por pareja en un mismo puesto de trabajo. Esto permite mayor control y revisión del código mientras se escribe. Refactorización del código: Reescritura de determinadas partes del código para facilitar su mantenimiento y su legibilidad, evitando modificar su comportamiento. Propiedad del código compartida: La responsabilidad y control del código es compartida por el equipo de programadores, quienes mantienen una secuencia de versiones, revisiones y cambios organizada para conocer el estado actual del código. Simplicidad: Al escribir el código, los programadores pueden generar estructuras simples, sin mayor complejidad funcional, las cuales estén limitadas a lo que será utilizado por el motor del videojuego. Desde sus comienzos, la programación extrema propone una serie de valores fundamentales para llevar a cabo esta metodología: Retroalimentación: El cliente se integra en el proceso de desarrollo del proyecto y permite que su aporte se haga en tiempo real. Por otro lado, los ciclos cortos permiten mostrar resultados más rápidos y hacer adaptaciones más eficientes a los cambios de requerimientos o de corrección de errores. Coraje: Se plantea como una actitud abierta a ser persistente y metódico, rompiendo esquemas sobre la valoración subjetiva del tiempo de trabajo, sacrificio y resolución de conflictos. Respeto: Este valor se centra en la actitud responsable del trabajo en equipo, del cumplimiento de los requerimientos y la apreciación del esfuerzo particular y colectivo.  

 

 

10. Scrum Scrum es un método de trabajo de tipo iterativo e incremental utilizado en entornos de desarrollo ágil de software, el cual define un conjunto de prácticas y roles que pueden tomarse como punto de partida para determinar el proceso de desarrollo que se llevará a cabo durante un proyecto. El concepto de scrum tiene origen en un estudio realizado en 1986 sobre los nuevos procesos de desarrollo utilizados en productos exitosos en Japón y los Estados Unidos (Canon, Xerox, Honda, Hewlett Packard), donde los equipos de trabajo partían de requisitos muy generales, innovadores y con un rango de plazo de lanzamiento menor que los productos anteriores (Takeuchi, 1986). Esta metodología fue creada por Jeff Sutherland, quien en conjunto con otros expertos en metodologías del mismo tipo, establecieron los primeros postulados de dicho esquema, entre los que se destacan: • • • •

 

Individuos e interacciones sobre procesos y herramientas Software operativo sobre documentación extensiva Colaboración con el cliente sobre negociación de contratos Respuesta a los cambios sobre cumplimiento estricto de un plan

 

En esta imagen se puede observar como los ciclos cortos de desarrollo (Sprints) son planeados y ejecutados con el fin de generar incrementos de producto, partiendo de información previa que a manera de requerimientos (Backlog), pauta el desenvolvimiento del proceso en reuniones diarias (scrum diario). La metodología scrum asume que el proceso de desarrollo de software es impredecible, por ello lo toma como una caja negra controlada, en vez de un proceso completamente definido. Esta es una de las principales diferencias entre el scrum y otras metodologías, como los modelos de espiral o de cascada, en los cuales el proceso se define por completo desde el inicio y se corre el riesgo de enfrentar problemas como la falta de comprensión o cambio de los requerimientos.  

 

 

CONCLUSIÓN Las metodologías de desarrollo de videojuegos han evolucionado a lo largo de los años hacia una mayor integralidad, interdisciplinaridad, relación con los clientes, cohesión en los equipos de trabajo y versatilidad en los procesos. Si bien el recorrido histórico muestra los cambios paulatinos en los conceptos, procesos y etapas de cada metodología, también sirve de pronóstico de los posible aspectos relevantes y susceptibles de cambio en los años venideros. En general, los estudios de desarrollo de videojuegos actuales tienden a utilizar las metodologías agiles de Scrum y Xp, ya que ofrecen mejores resultados a largo plazo.  

 

 

BIBLIOGRAFÍA Boehm, B. (1986). Un modelo espiral de desarrollo de software y de mejora. Estados Unidos: ACM SIGSOFT Humphrey, W. (2000). The Team Software Process. Estados Unidos: Carnegie Mellon. Jacobson, I. 2009. Essential Unified Process. Ivar Jacobson International. Recuperado el 25 de Julio de 2012, de: http://www.ivarjacobson.com/process_improvement_techn ology/essential_unified_process_software/ Keith, C. 2009. Waterfall Game Development. Agile Game Development. Recuperado el 24 de Julio de 2012 de: http://www.agilegamedevelopment.com/2009/01/in-dawn- of-video-gamedevelopment.html Kruchten, P. (2004). The Rational Unified Process: An Introduction. Estados Unidos: Addison-Wesley. Otter. (2008). The Movie Industry Vs. the Gaming Industry. Associated Content. Recuperado el 25 de junio de:http://www.associatedcontent.com/article/1015720/the_mo vie_industry_vs_the_gaming_industry.html Takeuchi (1986). The New New Product Development Game. Estados Unidos: Harvard Business Review

 

 

CRÉDITOS Desarrollo temático e investigación Álvaro Cortes Téllez Experto temático Eivar Rojas Asesor Técnico Diseño y adecuación a ava Carlos Amaya Asesor PARA AVA. SENA Alejandro Merchán Diseñador gráfico Magda Zulena Trujillo Asesora didáctica - Guionista Urlieson Sanchez Programador