Libro de juega libre

PROGRAMA ESTRATÉGICO DE INVESTIGACIÓN Y DESARROLLO PARA EL SECTOR COLOMBIANO DE LA ANIMACIÓN Y VIDEOJUEGOS

JUEGA LIBRE Pablo A. Figueroa, David S. Diaz, Nicolaz D. Perez, Juan C. Buitrago, Andres R. Gomez, Sebastian Gil y Rafael A. Ruiz Grupo de Investigación IMAGINE Departamento de Ingeniería de Sistemas y Computación Proyecto cofinanciado por Colciencias Programa Nacional de Ciencia, Tecnología e Innovación en TIC

Universidad de los Andes Bogotá, Colombia

PRÓLOGO Desde hace varios años el gobierno colombiano busca impulsar el sector de las tecnologías. Entre ellos destaca el sector de la animación y los videojuegos. De esto desprende uno de los proyectos más ambiciosos desarrollados en este sector, el proyecto D.A.V.I.D (Desarrollo en Animación y Videojuegos), que es un apoyo al sector de la industrial de la animación y los videojuegos en Colombia, el cual es financiado por Colciencias.

Dentro del marco del proyecto D.A.V.I.D, uno de sus pilares es aportar a las personas y las empresas una guía que les permita navegar a través de la dinámica para la construcción de contenidos digitales sobre todo videojuegos, siendo una tarea muy importante si se quiere llegar a competir a nivel mundial.

La idea de este proyecto es permitir que las personas puedan aprender más sobre los contenidos digitales y como se pueden desarrollar médiate herramientas de libre acceso o gratuitos. La implementación de herramienta para el desarrollo de este tipo de contenido genera una gran curiosidad en las empresas que buscan competir con empresas internacionales.

La idea de los autores del presente libro es dar a conocer este trabajo y permitir que otras personas puedan participar en él, con la idea de seguir perfeccionando y mejorando la industria de contenidos digitales en Colombia, mostrando la participación en diferentes eventos y el desarrollo de algunos productos en el marco del proyecto.

En las primeras páginas se puede encontrar una explicación de la idea del proyecto en general. En seguida se describe como las diferentes partes en las que se basa el proceso de desarrollo, en la última parte del libro se mencionan algunos de los resultados obtenidos que pueden ser útiles consultar al momento de desarrollar contenido digital.

Rafael Antonio Ruiz Gutiérrez Ingeniero de Sistemas

TABLA DE CONTENIDO

Contenido INTRODUCCIÓN ..................................................................................................................................... 9 CAPÍTULO I: ......................................................................................................................................... 11 ANTECEDENTES ................................................................................................................................... 11 CAPÍTULO II: ........................................................................................................................................ 13 PROCESO ............................................................................................................................................. 13 CAPÍTULO III: ....................................................................................................................................... 15 DESARROLLO CREATIVO ...................................................................................................................... 15 CAPÍTULO IV: ....................................................................................................................................... 23 PRODUCCIÓN ...................................................................................................................................... 23 CAPÍTULO V: ........................................................................................................................................ 35 TESTING: “PRUEBA DE JUEGO” ........................................................................................................... 35 CAPÍTULO VI: ....................................................................................................................................... 45 PUBLICACIÓN Y MANTENIMIENTO ..................................................................................................... 45 CAPÍTULO VII: ...................................................................................................................................... 49 HERRAMIENTAS................................................................................................................................... 49 CAPÍTULO VIII: ..................................................................................................................................... 55 RESULTADOS ....................................................................................................................................... 55 SIMÓN EL BOBITO ........................................................................................................................... 55 CAPÍTULO IX: ....................................................................................................................................... 59 EVENTOS.............................................................................................................................................. 59 DEViCE ............................................................................................................................................. 59 FUKUSHIMA GAME JAM .................................................................................................................. 63 CAPÍTULO X: ........................................................................................................................................ 67 MONO ............................................................................................................................................. 67 CAPÍTULO XI: ....................................................................................................................................... 73 TRABAJOS FUTUROS........................................................................................................................ 73 BIBLIOGRAFÍA ...................................................................................................................................... 75

INTRODUCCIÓN “Juega Libre es un portal que pretende brindar herramientas, tutoriales y sobre todo procesos para el desarrollo de videojuegos. El objetivo es generar una comunidad de desarrolladores dispuesta a colaborar entre sí. Te invitamos a explorar el sitio, seguro encontrarás algo de tu interés :)… Ahh y no olvides subir tus juegos, nos encantaría ver lo que has desarrollado.”

Fig. 1 Página principal de Juega Libre

CAPÍTULO I: ANTECEDENTES Desde hace más de diez años, la Universidad Complutense de Madrid tiene un Master en Desarrollo de Videojuego, en el cual buscan que sus estudiantes tengan conocimiento sobre contenidos específicos sobre las características del hardware y el software utilizado en el desarrollo de videojuegos, donde buscan promover los juegos de sus alumnos a través de internet.

La Unión Europea, en su “Programa Europa Creativa de apoyo a los sectores culturales y creativos (2014-2020): Subprograma MEDIA”, ha tenido varias convocatorias, una en 2014 y otra en 2015, para la fomentación del desarrollo de videojuegos, tanto en el sector privado como en el sector público, buscando incrementar la producción de obras en formato digital, entre ellas los videojuegos.

Otros eventos importantes para la difusión en el aprendizaje del desarrollo de videojuegos son los Jams, los Jams en la actualidad son muy importantes ya que ofrecen distintos tipos de ideas y de experiencias para familiarizarse con este tipo de desarrollo.

El Global Game Jam (GGJ), sin duda el Jam más popular y más grande que existe, la versión del 2014 reunió 23189 participantes que crearon un total de 4292 juegos. El GGJ promueve una de las iniciativas emprendedoras más grandes, haciendo presencia en 72 países y cerca de 488 locaciones distintas. El GGJ no promueve un ganador del evento. En cambio, terminados todos los límites de tiempo, ofrecen host y promueven Play Parties en las locaciones del evento. Estas Play Parties son organizadas normalmente por los administradores de las locaciones, y tienen como objetivo mostrar los resultados locales, promover los juegos más populares y establecer puntos de contacto para que las empresas busquen nuevos talentos y nuevas ideas.

Otro evento de esta naturaleza es el Ludum Dare, una iniciativa que nació en 2002 gracias a Geoff Howland como un evento completamente online. En principio, la experiencia es individual y competitiva, donde la comunidad vota por los juegos para elegir un ganador. El tema central de cada competencia también es elegido por votación. El evento posee una amplia comunidad web que ofrece mucho apoyo y seguimiento a los participantes del evento. El Ludum Dare trata de efectuarse cuatro veces al año en una versión clásica de desarrollo individual de 48 horas, aunque actualmente también promueve eventos mucho más cortos en tiempo de desarrollo o competencias por equipos.

El Experimental Gameplay Project, es una iniciativa estudiantil de la Universidad Carnegie Mellon cuyo principal propósito es que los participantes creen, a partir de un tema común, juegos que propongan mecánicas nuevas, innovadoras o poco convencionales. El Jam toma una semana y los juegos deben ser creados por una única persona. La creatividad es sin duda el espíritu principal del Jam, que se centra principalmente en la investigación, la innovación y en las propuestas interesantes.

CAPÍTULO II: PROCESO El proceso descrito en este libro es un proceso general para el desarrollo de videojuegos, que permite desarrollar juegos casuales y triple A, durante el tiempo de desarrollo que sea necesario; ya que es un proceso cíclico donde cada una de sus etapas es evaluada y corregida para pasar a la siguiente.

Fig. 2: Diagrama del proceso del desarrollo de un videojuego.

El proceso general está compuesto por cuatro etapas denominadas “Desarrollo creativo”, “Producción”, “Testing”, “Despliegue y mantenimiento”. Como se observa en la Figura 2 es un proceso por etapas que al finalizar se retroalimenta en caso de error para corregir fallas y perfeccionar el producto.

También existe un proceso ágil de desarrollo de videojuegos el cual se puede observar en la figura 3. Este proceso permite desarrollar juegos casuales durante un periodo corto, de alrededor de 2 semanas. Estos juegos pueden ser útiles para probar conceptos en mecánicas de juego, publicables en juegalibre.

Fig. 3: Diagrama del proceso rápido del desarrollo de un videojuego.

La gran diferencia entre uno y otro modelo es la velocidad con que se realizan los entregables, siendo considerablemente más rápido todo el desarrollo en el proceso rápido, también en este no hay una fase de retroalimentación que si existe en el proceso general.

CAPÍTULO III: DESARROLLO CREATIVO Esta etapa está constituida por diferentes actividades que buscan desarrollar y crear el concepto del juego, entre ellas esta su apariencia, las mecánicas, si es entretenido, etc. En el desarrollo creativo se van a formalizar y a documentar las ideas base del juego. Cada uno de los documentos que se van a generar en esta primera etapa cumplen dos objetivos principales: 

Articular al equipo desarrollador para que todos trabajen sobre las mismas ideas y con los mismos objetivos en mente.



Plasmar las ideas claramente de tal manera que se puedan comunicar con facilidad a terceros, con el objetivo de vender la idea.

Fig. 4: Diagrama del diseño creativo del videojuego.

Brainstorming La lluvia de ideas, también denominada tormenta de ideas, es una herramienta de trabajo grupal que facilita el surgimiento de nuevas ideas sobre un tema o problema determinado. La lluvia de ideas es una técnica de grupo para generar ideas originales en un ambiente relajado.

Esta técnica fue desarrollada por Alex Osborn (especialista en creatividad y publicidad) en los años 30 y publicada en 1963 en el libro “Applied Imagination”. Es la base sobre la que se sostiene la mayoría de las demás técnicas.

Generación de ideas Para la generación de ideas, se establece un número de ideas al que queremos llegar, teniendo en cuenta ciertas reglas a seguir.

Reglas fundamentales   

Toda crítica está prohibida.

Toda idea es bienvenida.

Tantas ideas como sea posible.

Los participantes dicen todo aquello que se les ocurra de acuerdo al problema planteado y guardando las reglas anteriores.

Un ejemplo es el siguiente Ejemplo ¿Qué podemos hacer para mejorar los problemas del tráfico urbano?

Respuestas:  Quemar los coches.  Vivir en el campo.  Restringir los días de circulación.  Aumentar muchísimo el precio de los coches.  Aumentar muchísimo el precio de la gasolina.  Ir en bici.  Ir a pie.  No salir de casa.

   

Vivir todos en la misma casa.

Trabajar y vivir en el mismo edificio.

Penalizar el uso del coche.

Pinchar todas las ruedas.

Con esta técnica se puede llegar a conseguir una gran lista de ideas basadas en un tema específico para su videojuego, mientras más ideas y menor sea el tiempo que se utilice en este proceso; mejor será el resultado, de igual manera existen otras técnicas de desarrollo de ideas para esta etapa del proceso creativo como lo es la técnica llamada “Cadáver Exquisito”.

CONCEPTUALIZACIÓN DEL PROYECTO Esta primera actividad consiste en crear y documentar todos los conceptos básicos que darán forma y originalidad al videojuego. Estos conceptos básicos incluyen ideas como: La premisa, las mecánicas de juego, los personajes, etc. Todos deben ser definidos y plasmados para posteriormente ser trasmitidos a través de distintos documentos como el One Pager, el Pith y la propuesta de negocio.

El equipo de desarrollo debe conformarse de tal manera que todos los aspectos básicos del proyecto sean cubiertos (programación, diseño, trabajo artístico y sonoro), además de los retos específicos planteados en la conceptualización del proyecto.

One Pager (Documento de propuesta) Es el primer documento que crea un diseñador de juegos donde explica el concepto y vende su juego a los editores y desarrolladores, y pone sus ideas y visión en un documento conciso. Puede ser un documento de una o dos páginas máximo. El documento empieza con el título de juego, vendiendo el nombre del juego, así como su diseño.

La primera frase es la más importante y a menudo es la más difícil de escribir. En una frase se debe describir el concepto de juego. Se enfatiza esta regla: debe explicar todo el juego en una frase. Por lo general, la frase repite el título del juego e incluye género del juego y una descripción básica o visión general del concepto.

Ejemplos: 

GANGSTER es un FPS (Disparos en primera persona) donde el jugador es un gánster como Jesse James, Parker Clyde, o John Dillinger, y el jugador

se coloca en los escenarios de gánsteres y deben completar con éxito cada misión. 

P-MAN es un juego de acción en el que maniobrar un círculo amarillo animado comiendo puntos, a través de un laberinto tratando de destruir las bases de luces, con seis enemigos que con entusiasmo recorren el laberinto tratando de capturarlo.



BÉISBOL COUCH POTATO es un juego de deportes (béisbol) en 3D donde el jugador selecciona su equipo de estrellas y dirige el equipo por una temporada de juego de la Serie Mundial, seleccionando sus All-Star en equipo, asignando en cada juego el orden de bateo y la selección de los lanzadores.

El documento también incluye otros aspectos del juego, como las características (las funciones básicas, estándar, así como características especiales que hacen del concepto algo diferente o mejor que los juegos actuales), los requisitos de hardware y software necesarios (obligatorio) y sugeridos (recomendado) para jugar correctamente.

También puede incluir cualquier operación de comercialización y los análisis de ventas que le ayudarán a soportar su concepto y obtener un interés en su juego, como la licencia, la audiencia prevista (sexo, grupos de edad de los jugadores), y los datos pertinentes.

El documento es muy importante y debe ser comprensible para todos, desde los empresarios hasta los jugadores hardcore.

Pitch document Documento corto que ilustra de una manera muy gráfica la idea general y las características importantes del juego. El objetivo del documento es presentarlo a posibles inversionistas, por lo tanto se deben plasmar los puntos claves del juego, factores diferenciadores y razones por las cuales sería un proyecto rentable. Este tipo de documento se puede crear a manera de presentación.

Las partes del Pitch para un videojuego varían según el tipo de videojuego; para un videojuego casual; puede tener las siguientes:   

Portada con el nombre y gráfica del videojuego.

Sinopsis.

Características del videojuego (personajes, power up, acciones divertidas y game play).

   

Mecánicas (Como se juega).

Dispositivos.

Plan de mercado y monetización (Ver diferentes tipos de monetización de videojuegos casuales como free to play, publicidad).

Estado del desarrollo.

Elaboración de la propuesta de negocio y Vender la idea La elaboración de una propuesta de negocio usa como insumo los documentos producidos en la conceptualización de tal manera que pueda trasmitir de forma clara y rápida:   

La idea general del juego.

Los elementos diferenciadores de la idea.

La estrategia de monetización.

Esto, con el objetivo de poder vender la idea como un poryecto, ya sea para conseguir una compañía publicitaria, inversores o posibles usuarios.

Modelos de monetización Aunque no parezca tan importante este tema a la hora del diseño del gameplay, en los juegos casuales o juegos sociales, jugados a través de redes sociales y dispositivos móviles, los modelos de monetización de cada uno pueden marcar el ritmo de inmersión de los jugadores dentro de cada videojuego; con base en esto es muy importante definir un modelo de monetización acorde al videojuego, con el fin de no limitar el juego del jugador solo a niveles pagos o llenos de publicidad.  





Monetización por venta: Es el modelo tradicional donde el videojuego se vende una sola vez al jugador el cual dispone de él.

Monetización por suscripción: En este modelo la forma de obtener dinero es mediante la suscripción a un tipo de cuenta que permite el acceso al juego, este es tradicional de los MMOG. Monetización F2P Free to Play: Es este caso el juego se puede obtener de forma gratuita, lo que implica que el dinero debe venir de otro tipo modelo de negocio, de los cuales se destacan la monetización por publicidad, la monetización por micro transacciones y monetización por contenido “premium”.

Monetización por publicidad: En este modelo, básicamente se añade publicidad; banners, videos o interstitials, en el videojuego. Los mayores





anunciantes del sector en este sentido son; Google con el servicio AdMob que da la posibilidad a los anunciantes para que distribuyan la publicidad en las apps móviles, Twitter con su red de anuncios MoPub y Facebook.

Monetización por micro transacciones: En este modelo se busca que mediante pagos de cantidades relativamente pequeñas se pueda obtener algún beneficio al momento de jugar el videojuego.

Monetización por contenido “Premium”: Este tipo de modelo presenta una experiencia básica al jugador, la cual puede ser mejorada al pasar a un tipo de cuenta de lujo donde se tiene acceso a nuevo contenido.

Game Design Document <Versión inicial> Un documento de diseño del juego (a menudo abreviado GDD), es un documento dinámico de diseño altamente descriptivo del diseño del juego para un videojuego. Un GDD es creado y editado por el equipo de desarrollo y es utiliza principalmente en la industria de los videojuegos para organizar los esfuerzos dentro de un equipo de desarrolladores.

El documento es creado por el equipo de desarrollo como resultado de la colaboración entre los diseñadores, artistas y programadores como una visión orientadora que se utiliza en todo el proceso de desarrollo del videojuego; el desarrollador tiene que adherirse al GDD durante el proceso de desarrollo del juego.

Antes que una producción a gran escala pueda comenzar, el equipo de desarrollo produce la primera versión de un documento de diseño del juego que incorpora la totalidad o la mayor parte del contenido gráfico y conceptual del juego inicial.

El documento de diseño describe el concepto del juego y los principales elementos de juego en detalle. También puede incluir bocetos preliminares de diversos aspectos del juego; a veces acompañado de prototipos funcionales de algunas secciones del juego.

Este documento sigue siendo un documento vivo durante todo el desarrollo, a menudo cambian semanalmente o incluso diariamente. Si se compila en una lista de necesidades del juego, se llama “media list”, del cual se hablara más adelante.

Prototipo físico

El prototipo físico pretende representar de manera general las mecánicas más importantes del juego, de tal manera que se pueda generar una idea básica del flujo de juego. Los prototipos físicos pueden desarrollarse rápidamente usando papel y lápiz, cartas, modelos en miniatura, entre otras cosas.

El objetivo principal de un prototipo físico es desarrollarlo y usarlo lo más fácil y rápido posible para observar cómo funcionan las reglas del juego. Esto, para hacer cambios tempranos en la idea si se detecta que alguna actividad no funciona o simplemente no es divertida.

Prototipo digital El prototipo digital es usado para revisar la distribución de los scores en la pantalla, saltos especiales y lugares en los que el gameplay podría cambiar, se busca probar visualmente los escenarios más atrayentes del juego.

Es importante en el prototipo digital mostrar la acción más importante del juego, por lo que este escenario es uno de los más atrayentes para el jugador, al igual que el escenario cuando el jugador pierde o gana.

Un prototipo digital, es una de las herramientas más cercana a lo que podremos sentir a la hora de probar el juego ya desarrollado. El prototipo además nos permite ver la distribución visual de los elementos, los momentos interesantes del juego, las funciones a nivel de controles del personaje, formas de enfoque de la cámara, y en general como se ambienta un juego y como el jugador percibe los elementos exhibidos.

Los prototipos a menudo tienen el único fin de actuar como una prueba de concepto o para probar ideas, mediante la adición, modificación o eliminación de algunas de las características. La mayoría de los algoritmos y características en un prototipo puede ser pasadas al juego una vez que se han completado.

Un modelo de desarrollo exitoso de prototipos es iterativo, donde el diseño es refinado basándose en el progreso actual.

Consejos 

No se debe diseñar con las gráficas y efectos visuales que se tiene pensado para el videojuego, ya que el objetivo es probar las mecánicas y puede perderse el foco.

ď&#x201A;ˇ

Utilizar paquetes prototipo. Link

grĂĄficos

predeterminados

para

el

desarrollo

del

CAPÍTULO IV: PRODUCCIÓN La etapa de producción debe considerar las distintas actividades que cada grupo especializado realiza y los productos resultantes de cada actividad. Estos productos deben converger en un punto de tal manera que puedan hacer parte de un videojuego funcional, transformado la comunicación y la administración de todo el equipo de desarrollo en habilidades fundamentales del proceso de producción.

Fig. 5: Diagrama de la producción del videojuego.

Equipo de Game Design El objetivo concreto del equipo de diseño consiste en plantear los lineamientos que los equipos de producción utilizarán para la construcción de assest para el juego.

Esto convierte al equipo de diseño en los encargados de coordinar y supervisar la producción, de tal manera que todo el trabajo siga las mismas ideas y converja al mismo objetivo.

Diseño de Personajes Características El diseño de los personajes es una de las tareas más importantes dentro del proceso de dar vida a los protagonistas de nuestros proyectos. Ya sean personajes realistas, estilizados, caricaturas u objetos animados, todos deben poseer características propias en su fisonomía y comportamiento para generar empatía con los espectadores. Tener en cuenta el diseño de los personajes que integrarán nuestros proyectos nos lleva a darle un valor agregado a la historia que queremos contar.

Lo primero que se debe tener en cuenta antes de diseñar un personaje, es tener una historia, en la cual este se desarrolla (actúa). Esto nos ayuda a tener claras diferentes características del personaje, la esencia del personaje son todas aquellas características que lo hacen único y que determinan su forma de actuar.

Nombre del personaje · Apodo del personaje · Edad · Características Todo lo necesario para que el personaje parezca real y quede plasmado en la historia.

Altura, peso, musculatura, color de pelo, cabeza, orejas, brazos, etc…

Ejemplo:   

Nombre del personaje: Simón.

Apodo del personaje: “El Bobito”.

Edad: 9 años aproximadamente.





Características Personales: Le gusta jugar en la arena, le gustan los huevos revueltos, odia las lentejas, siempre ha soñado con ser piloto, en el colegio es el tímido, etc.

Ropa: Le gusta las camisetas azules y siempre suele llevar una, los pantalones vaqueros le quedan bien aunque suele ponerse overoles, etc.

Bocetación En la bocetación buscamos plasmar el diseño conceptual, existen diferentes técnicas de ilustración para este proceso desde el manga hasta la ilustración tradicional, para el personaje de Simón el proceso de bocetación tiene como base la ilustración infantil la cual busca representar formas complejas a partir de formas básicas, como círculos, cuadrados, rectángulos y triángulos.

Se debe dibujar el personaje muchas veces buscando cada vez tener más detalle en las características que lo hacen único y también dibujarlo en diferentes posiciones y puntos de vista, los cuales nos servirán a futuro si el personaje está pensado para animación 2d o 3d.

Finalización La finalización es el proceso a través del cual convertimos nuestros bocetos de lápiz y papel en un archivo digital, el cual nos facilita proceso de color, texturas, líneas y detalles a nuestros personajes, los cuales una vez terminados podemos animar.

Los bocetos son escaneados y pasados a programas vectoriales o de mapas de bit (Inkscape, gimp, illustrator, photoshop, etc.), donde se redibujan y se terminan.

Fig. 6: Proceso de bocetación de Simón.

Diseño de Escenarios El diseño de escenarios o niveles, es realizado en la mayoría de proyectos de videojuegos por un diseñador especializado en este tema, el cual está encargado de crear los niveles-locales, escenarios o misiones.

Esto se hace comúnmente mediante un editor de niveles en un programa de desarrollo de videojuegos. Este es un proceso artístico y técnico, de allí que el diseñador de niveles necesite de conocimientos de diseño y programación.

El diseño de niveles para cada nivel individual en un juego moderno suele comenzar con bocetos, croquis, renders y modelos físicos. Una vez terminados, estos conceptos se transforman en una amplia documentación del modelado, el medio ambiente, y la colocación de las entidades específicas del juego (actores), normalmente con la ayuda de un editor de niveles de un motor de videojuegos.

Los pasos generales son: 







  

Trazado de las características a gran escala del mapa, tales como colinas, ciudades, salas, túneles, etc., también los jugadores y los enemigos para determinar su interacción con las condiciones ambientales y las “reglas del juego”, como día / noche, el clima, los sistemas de puntuación, las armas permitidas o tipos de juego, los plazos y los recursos de partida.

Especificación de ciertas regiones donde determinadas actividades de juego o comportamientos se producen, tales como la recolección de recursos o power ups.

Especificación de la ubicación de los elementos estáticos que hacen parte del nivel, tales como puertas, llaves y botones, los cuales pueden interactuar con los avatares.

Especificación de la ubicación de las distintas entidades, tales como las unidades de los jugadores, enemigos, puntos de spawn de monstruo, escaleras, monedas, nodos de recursos, las armas, los puntos de almacenamiento, etc… Esto depende del tipo de videojuego, normalmente un videojuego casual solo tiene en cada nivel un espacio de desarrollo.

Especificación de la salida y destinos de salida para uno o más jugadores.

Adición de detalles estéticos, como texturas gráficas, sonido, animación, iluminación y música.

La colocación de nodos; son espacios donde el jugador se encuentra con explicaciones y guías que le ayudan a continuar el juego; en un videojuego casual es poco común el uso de este tipo de nodos, ya que por naturaleza su game play es lo bastante sencillo como para que el usuario necesite de estas guías, de igual forma esto depende del diseño del juego.

Es posible que durante las pruebas del prototipo digital el diseño del nivel se modifique varias veces antes de lograr el resultado deseado.

HUD (Head Up Display) En los videojuegos, se llama HUD (del inglés: “Head-Up Display”) a la información que en todo momento se muestra en pantalla durante la partida, generalmente en forma de iconos y números. El HUD suele mostrar el número de vidas, puntos, nivel de salud y armadura, mini-mapa, etc.

Generalmente el HUD muestra datos simples como:  Número de vidas restantes.  Puntos obtenidos.  Tiempo restante para completar el nivel.  Objetos conseguidos (Power Ups), etc.

Con el paso del tiempo, el HUD fue evolucionando. Las nuevas tecnologías y la evolución de los videojuegos cambiaron drásticamente el HUD haciendo que comenzara a dividirse por el tipo de juego que use un HUD. Por ejemplo: Los FPS (first person shooter) usan un HUD que muestra la ubicación del objetivo, un radar, los puntos de vida, los puntos de escudo, el arma en uso, las municiones restantes, las recargas, las granadas, la mira donde apunta el arma y un sistema de daño que indica por marcas en la visión del jugador por donde recibe daño y la gravedad del daño. El HUD puede variar en elementos.

Los del tipo Grand Theft Auto muestran el arma en juego, los puntos de vida, la energía restante para correr, el dinero disponible y un radar donde se muestran los edificios, tiendas, enemigos y aliados.

Hoy en día, todos los videojuegos usan un tipo de HUD que se adapta al juego, generalmente, el HUD tiene un diseño distinto que va de acuerdo con el juego.Por ejemplo en Halo el HUD adquiere un característico tono azul y en Saints Row usa diseños con un borde en forma de grafiti.

El HUD debe ser diseñado para no entorpecer el juego y brindar al jugador en todo momento la información de juego necesaria. Con el paso del tiempo, se ha comprobado que la mejor zona para colocar el HUD es en el borde de la pantalla, lo que permite al jugador acceder a la información necesaria con solo mover un ojo.

Fig. 7: Ejemplo de HUD en un videojuego

HUD “Juegos Casuales” Dado que los juegos de video tratan de llegar a un nuevo público más allá del mercado gamer, los desarrolladores se están dando cuenta de la necesidad de simplificar el diseño de la interfaz. Mientras que los jugadores hardcore pueden ver numerosas barras de estado e indicadores en pantalla, es más probable que un jugador casual se sienta abrumado. Los jugadores que buscan una experiencia”pick up and play” (Levantar y jugar) no están dispuestos a gastar tiempo en averiguar para que son todas las barras y los indicadores. Cuanto más simple y más intuitiva sea la interfaz, es más accesible el juego para jugadores casuales.

Fig. 8: Ejemplo de HUD de un juego casual “Mr. Albert”

En el HUD de un juego casual como Mr. Albert encontramos únicamente la barra de energía, el contador de power ups, el botón de pause, el contador de puntos, y los botones de juego.

Animaciones La animación es el proceso que consiste en la aplicación de movimientos a imágenes o dibujos; en los juegos, el personaje está controlado por el jugador. Las decisiones que tome el jugador afectan a las animaciones de su personaje. Las animaciones en los juegos se crean por bucles, donde la secuencia empieza y acaba en la misma posición, y entonces pasa a la siguiente acción del bucle. Una posible secuencia de movimientos sería correr, saltar, pararse y correr de nuevo.

En otra distinta, el personaje empieza a correr, camina, se para y se tumba en el suelo. El animador debe considerar muchas combinaciones de acciones que pueden ser elegidas por el usuario.

Videojuegos 2D La animación de personajes y elementos para videojuegos 2d se realiza con una técnica llamada cuadro a cuadro o pose a pose, a través de la cual se genera un archivo llamado Sprite Sheet; este archivo contiene todas las imágenes que hacen parte del movimiento el cual al reproducirse genera un loop o bucle (Repetición).

Este tipo de animación está compuesto por dos partes: Assets: Usualmente se denomina asset a cualquier recurso gráfico que se carga externamente.

Sprite Sheet: Una sprite sheet (o strip) es una imagen no animada de gran tamaño en la que aparecen muchas imágenes de un personaje (o varios) mostrando todos los frames de sus animaciones.

Videojuegos 3D Una de las diferencias entre los juegos 2D y 3D radica en que para cada escena 3D podemos mover la cámara todo lo que queramos. Por tanto, la animación tiene que ser correcta desde cualquier ángulo. No podemos dejarnos ningún punto, ninguna ecuación, sin resolver.

El rápido avance tecnológico ha permitido que muchas de las técnicas anunciadas hace pocos años sean ya una realidad, en mucho menos tiempo del esperado,

como por ejemplo la animación basada en el esqueleto o la aplicación de la cinemática inversa. Estas técnicas están ya más que establecidas en la animación de personajes en 3D. Gracias a este avance, podemos realizar también la enorme cantidad de cálculos necesaria para técnicas como la captura de movimientos de forma rápida y sencilla.

Tipos de animación 3d 

Estructura Jerárquica: Definimos un personaje con estructura jerárquica dividiéndolo en partes articuladas del cuerpo; cada parte se trata como un objeto separado, almacenado en una jerarquía y unido uno a otro por puntos de eje o puntos de pivote.

Fig. 9: Ejemplo estructura jerárquica.

Ejemplo:

Video 1: Ejemplo de animación jerárquica.

Mezcla entre mallas de personajes: Una aproximación diferente a la animación de personajes en tiempo real se basa en usar más de un objeto que represente al mismo personaje, mostrando cada objeto en una pose diferente.

Todos estos objetos deben tener el mismo número de vértices. En este caso, la animación se realiza interpolando las correspondientes posiciones de los

vértices entre los diferentes objetos y mezclándolos intercambiando los objetos uno detrás de otro.

o

simplemente

Fig. 10: Ejemplo de mezcla de mallas.

Ejemplo:

Video 2: Ejemplo animación entre mallas.

Animación del esqueleto y mallado de la piel: La animación del esqueleto fue desarrollada para simplificar el proceso de animación que trata con objetos articulados, mejorando el aspecto de los objetos animados haciéndolos más realistas. El método en cuestión consiste en una mejora de los comentados anteriormente, y se basa en el uso de un endoesqueleto. Este endoesqueleto es una estructura jerárquica de articulaciones, que además tendrá un mallado de vértices representando la silueta del objeto. Esta separación entre el mallado y la estructura jerárquica es lo que hace que este método sea mejor que los dos anteriores. Este método está dividido en la animación a personajes con piel rígida y a personajes con piel suave; siendo el segundo el método con el cual se logra mayor realismo.

Captura de movimientos (motion capture o mocap en inglés): Consiste en la extracción de movimientos a partir de actores reales. A estos actores hay que colocarles unos sensores a través de los cuales obtendremos los movimientos en nuestro personaje modelado gracias a la cinemática inversa. La función que realiza la cinemática inversa en la captura de movimientos es la de calcular todos los

ángulos que se forman en todas las articulaciones de cada personaje que aparece en pantalla. Al estar usando los ángulos entre las articulaciones para montar las animaciones, podemos aplicar los movimientos capturados a toda clase de personajes. No importa lo diferentes que sean físicamente, la animación va a ser igual para todos los modelos.

Vídeo 3:

Vídeo 4: Ejemplos de Motion Capture.

Links: Keyframing Organizado Motion Capture Character animation La Noire

Media List El Media List, es un documento pequeño en el que se encuentra de manera organizada la lista de todos los assest que son necesarios para el desarrollo del juego; fijos, animados o de sonido; con el fin que cada uno de los integrantes del grupo de desarrollo sepan que tienen que hacer específicamente.

Ejemplo: Media List “Reto Pastelero” DISEÑO:  Menú Principal.  Botones (play, pause, menú, opciones, etc.).  Pantalla Ganó.  Pantalla Perdió.  Pantalla loading.  Assest Zombie (Caminar, comer pastel, caerse).  Assest Simón (Caminar, saltar, lanzar pastel).



Power Ups (Bigote y sombrero).

PROGRAMACIÓN:  Menú Principal.  Botones (play, pause, menú, opciones, etc.).  Pantalla Ganó.  Pantalla Perdió.  Pantalla loading.  Assest Zombie (Caminar, comer pastel, caerse).  Assest Simón (Caminar, saltar, lanzar pastel).  Power Ups (Bigote y sombrero).

DISEÑO AUDIO:  Ambiente.  Foley (Caminar, saltar, lanzar, comer, etc.) * Para cada personaje.  Música ganó.  Música perdió.

Equipo de músicos La producción sonora consiste en integrar el audio necesario para los distintos efectos auditivos que se usaran en el juego. Estos elementos se componen de:  Foley (efectos de ambiente).  Música y banda sonora original.  Voces.

Equipo de programación El equipo de programación posee las habilidades técnicas necesarias para la construcción de los elementos funcionales del juego (ej. El HUD y el Gameplay).

Son también los encargados de integrar los diferentes assets producidos por los otros equipos de tal manera que se genere un ejecutable funcional del juego al final del proceso completo de producción.

Equipo artístico El equipo artístico está encargado de concretar y crear los assets especificados por el equipo de diseño, además de dar vida al concepto artístico y visual que se espera el juego posea. Al igual que el equipo de diseño, su trabajo se enfoca en la creación de:

    

Personajes.

Escenarios.

Elementos complementarios.

Animaciones.

Arte del HUD.

CAPÍTULO V: TESTING: “PRUEBA DE JUEGO”

Fig. 11: El sub-proceso de la prueba del juego o el testing es uno de los más importantes dentro del desarrollo de videojuegos, ya que a través de este controlamos la calidad de los videojuegos.

JUGAR Y DOCUMENTAR ERRORES La función principal de las pruebas de juego es el descubrimiento y documentación de los defectos de software (bugs). Para este campo es necesario tener experiencia informática, competencia analítica y habilidades de evaluación crítica.

Dado que los juegos se vuelven más complejos, un mayor número de recursos de control de calidad, denominados “Evaluación de la Calidad” o “Control de calidad”

son necesarios. La mayoría de los desarrolladores utilizan un equipo de control de calidad grande para probar varios niveles de su juego al tiempo.

Esto depende del tipo de videojuego; para un videojuego casual se puede tener un pequeño grupo de probadores (Testers) para el control de calidad; detectando fallos y ‘bugs’, ya sea en el código de programación o en las capas gráficas.

Un tester debe ser capaz de anotar y hacer referencia a los problemas que se encuentran en el videojuego a través de informes detallados, cumplir con los plazos y con las tareas que el nivel de habilidad exigido por el juego para completar los objetivos requeridos, hasta en los niveles más difíciles.

Lista de pasos Es importante que cualquier error identificado esté bien documentado, de tal manera que sea posible reproducir el error para su posterior estudio y corrección. Documentar un error implica identificar aspectos como:     

Nivel o locación específica.

Acción que se realizó.

Resultado esperado.

Resultado obtenido.

Condiciones específicas que se identificaron.

Lista y equipos Es importante organizar el proceso de pruebas detalladamente. Esto implica llevar un repositorio organizado de los errores que se han detectado, de tal manera que se pueda identificar.   

La organización cronológica de los errores.

Errores pendientes, en revisión y corregidos.

Correspondencia de los errores (que equipo es responsable de cada error).

Aspectos generales La garantía de calidad es un componente crítico en el desarrollo del juego, aunque la industria de los videojuegos no tiene una metodología estándar, cada desarrollador tiene sus propios métodos.

Los grupos de desarrollo pequeños no disponen siempre de personal de control de calidad, a diferencia de las grandes empresas que pueden emplear equipos de control de calidad de tiempo completo, para realizar pruebas a juegos comerciales tipo triple A. Las pruebas se inician tan pronto como el primer código está escrito y aumentan en la medida que el juego avanza hacia su finalización.

El trabajo del equipo de control de calidad (QA) es controlar el juego desde su primera entrega hasta finales de la post-producción. Al principio del proceso de desarrollo del juego el equipo de pruebas es pequeño y se centra en la información diaria para un código nuevo. A medida que el juego se acerca a la fase alfa, el equipo puede ser más numeroso, con el fin de comenzar a documentar todos los errores.

A veces, características que no son errores son reportados como errores y, a veces falla el equipo de programación para solucionar problemas ya reportados; este tipo de variables son las que determinan al sub-proceso de control de calidad o testing como un sub-proceso cíclico en el que cada error que es encontrado se reporta, se arregla, se revisa que este bien y si está mal vuelve al ciclo; mientras que paralelamente se prueba que la corrección de un error no genere cambios inesperados en el juego.

Un buen sistema de notificación de errores puede ayudar a los programadores a trabajar eficientemente. A medida que los proyectos entran en fase beta, el equipo de pruebas tiene asignaciones claras para cada día.

Es importante también después de haber realizado las pruebas de la corrección de un error, hacer que esta parte del juego, la pruebe una persona diferente con el fin que un nuevo punto de vista diferente ayude a identificar nuevos errores.

Durante la prueba del juego se descubren los errores a menudo sutiles. Algunos errores son fáciles de documentar, pero muchos requieren una descripción detallada de lo que el desarrollador puede reproducir o encontrar en el error.

La mayoría de las compañías clasifican los errores de acuerdo con su gravedad:  

CRÍTICOS: Que impiden que el juego se desarrolle, por ejemplo, se puede bloquear el juego.

BUGS: Son los problemas esenciales que requieren atención, sin embargo, el juego todavía puede ser jugable.



BUGS PEQUEÑOS: Que se pueden notificar en forma de recomendación en lugar de errores.

Roles dentro del testing Game tester (Probador) Un tester de juego es un miembro de un equipo de testing que lleva a cabo las pruebas de juego. Un tester principalmente trabaja en estrecha colaboración con diseñadores y programadores, especialmente hacia el final del proyecto.

Los testers son responsables de comprobar que el juego funciona, es fácil de usar, tiene acciones que tienen sentido, sin dejar a un lado la diversión. También de escribir informes de errores precisos y específicos, y si es posible proporcionar descripciones de cómo el error puede ser reproducido.

La persona encargada de QA (Control de Calidad) Es la persona responsable del seguimiento de los informes de fallos y tiene como responsabilidad que el juego funcione correctamente, la gestión de listas de errores, y está encargada del manejo del personal de control de calidad (Testers).

También son responsables de que los equipos de QA produzcan informes completos, que incluyen verificar que no se dupliquen los informes de errores.

Proceso de prueba 1 Identificación: Comportamiento incorrecto del programa se analiza y se identifica como un error.

2 Informes: El error se informa a los desarrolladores que utilizan un sistema de rastreo de defectos (Bugzilla o Mantis) Las circunstancias del error y los pasos para reproducir se incluyen en el informe. Los desarrolladores pueden solicitar documentos adicionales, tales como un video en tiempo real de la manifestación del insecto (bug).

3 Análisis: La persona responsable del error, tal como un diseñador, artista, o programador comprueba el mal funcionamiento y lo analiza para definir cómo puede corregir este error. Esta parte del proceso está fuera del alcance de los deberes del tester del juego.

4 Verificación: Después de que el desarrollador corrige el problema, el tester verifica que el error ya no se produce. No todos los bugs son abordados por el desarrollador, por ejemplo, algunos errores pueden ser reclamados como características (expresado como “NAB” o “Not A Bug”), y también puede ser “renunciado” (dado permiso para ser ignorado) por los productores, los diseñadores de juegos, o incluso probadores de control de calidad, de acuerdo con la política de empresa.

Metodología No existe un método estándar para probar un juego, y la mayoría de las metodologías son realizadas por desarrolladores de videojuegos individuales. Las metodologías se están continuamente cambiando y refinado; y pueden ser diferentes para diferentes tipos de juegos (por ejemplo, la metodología para probar un MMORPG será diferente de la prueba un juego casual).

Prueba de funcionalidad Es comúnmente asociada con la frase “prueba del juego”, la prueba de funcionalidad no requiere amplios conocimientos técnicos; busca problemas generales en el juego en sí o en su interfaz de usuario, tales como problemas de estabilidad, problemas de mecánica de juego, y la integridad del juego, siendo la prueba más común en juegos casuales.

Pruebas de cumplimiento De las normas de cada dispositivo o consola y de cumplimientos de derechos de autor, etc., es la razón de la existencia de laboratorios de pruebas de juego.

En primer lugar se encarga de revisar el cumplimiento de las licencias para las diferentes plataformas o consolas, las consolas tienen estrictos requisitos técnicos autorizados por sus fabricantes. Por ejemplo, Sony publica una lista de verificación de requisitos técnico” (TRC), Microsoft publica los requisitos técnicos de certificación (TCR), y Nintendo publica un conjunto de “directrices” (Lotcheck).

Algunos de estos requisitos son muy técnicos y están fuera del alcance de las pruebas de juego. En otras partes, en particular el formato de los mensajes de error estándar, manejo de datos de la tarjeta de memoria, y la manipulación de material con derechos de autor y marcas legalmente registradas, son responsabilidad de los tester del juego. Incluso una sola violación de presentación para aprobación de la

licencia puede hacer que el juego sea rechazado, posiblemente se incurra en gastos adicionales para más pruebas y nuevas presentaciones. Además, el retraso puede provocar que el título pierda una oportunidad importante de lanzamiento, incurriendo en costos aún mayores de dinero al editor.

Los requisitos son los documentos de propiedad entregados a los desarrolladores y editores bajo acuerdos de confidencialidad. No están disponibles para el público en general, a pesar de que la familiaridad con estas normas se considera una habilidad valiosa para tener como tester.

El cumplimiento también puede referirse a los órganos reguladores, como la ESRB y PEGI, si el juego se dirige a una clasificación de contenido en particular. Los testers deben notificar un contenido objetable que puede ser inadecuado para la clasificación deseada. Similar a la concesión de licencias, los juegos que no reciben la clasificación deseada deben ser revisados, corregidos y presentados de nuevo ante el órgano regulador, a un costo adicional.

Este tipo de pruebas de cumplimiento también son importantes en juegos casuales en la actualidad ya que este tipo de juegos aun en un formato pequeño manejan altos niveles de derechos de autor y publicidad.

Pruebas de compatibilidad De la compatibilidad depende de la versión final del juego. A menudo dos rondas de pruebas de compatibilidad se hacen; una a principios de la versión beta para dar tiempo a la resolución de problemas, y al final o durante la beta reléase.

Es importante probar el juego en diferentes configuraciones de hardware.

Las pruebas de compatibilidad se aseguran de que el juego se ejecuta en diferentes configuraciones de hardware y software. El hardware incluye marcas de diferentes fabricantes y periféricos de entrada como una variedad de gamepads y joysticks.

Pruebas de localización Este tipo de pruebas busca que el juego sea acorde con la región de su público objetivo, con el fin de utilizar un lenguaje similar tanto en el guion como en el game play con el fin de penetrar más en este mercado específico.

Pruebas de remojo En el contexto de los videojuegos, consiste en dejar el juego durante períodos de tiempo prolongados en varios modos de funcionamiento, como en modo lento, pausa, o en la pantalla de título. Esta prueba no requiere la interacción del usuario más allá de la configuración inicial, y generalmente se maneja por los probadores de QA. Las herramientas automatizadas pueden ser utilizadas para la simulación de acciones repetitivas, como los clics del mouse. El remojo puede detectar pérdidas de memoria o errores de redondeo que se manifiestan sólo en el tiempo.

Pruebas beta Se realizan durante la fase beta del desarrollo. A menudo esto se refiere a la primera versión públicamente disponible del juego. Las versiones Beta, públicas son eficaces porque miles de fans podrán encontrar errores que los testers no encontraron.

Pruebas de regresión Se realizan una vez por error corregido por los programadores. QA comprueba si el error sigue ahí (regresión) y luego ejecuta pruebas similares para ver si durante la solución se rompió algo más. Esa segunda etapa es a menudo llamada “halo de prueba”, que implica la evaluación de todo en torno a un bug, en busca de otros bugs.

Pruebas de carga Prueba los límites de un sistema, como el número de jugadores en un servidor de MMOG, el número de sprites activos en la pantalla, o el número de subprocesos que se ejecutan en un programa en particular. Las pruebas de carga requieren ya sea de un gran grupo de testers o software que emula la actividad pesada.

Pruebas multijugador Puede implicar un equipo de QA en modo multijugador por separado si el juego tiene una parte significativa multijugador. Esta prueba es más común en los juegos de PC. Los testers se aseguran que todos los métodos de conexión (módem, LAN, Internet) están trabajando. Esto permite que pruebas de un solo jugador y multijugador se produzca en paralelo.

Videos donde se muestra ejemplos de Bug en juegos.

Video 5: Bug con los sprites.

Video 6: Bug con las mecรกnicas del enemigo.

Video 7: Bug con el comportamiento del enemigo.

CAPÍTULO VI: PUBLICACIÓN Y MANTENIMIENTO

Fig. 12: Diagrama del despliegue y el mantenimiento en el proceso general.

El proceso de despliegue y mantenimiento de un videojuego hace parte de su postproducción, donde el juego ya alcanzo un punto de desarrollo alto y puede considerarse un producto terminado. Anteriormente los juegos desarrollados para las consolas de videojuegos no tenían casi ningún período de mantenimiento teniendo como consecuencia que el juego siempre albergaría varios bug (errores).

En los últimos tiempos, la popularidad de los juegos en línea en las consola ha crecido, permitiendo a los desarrolladores mantener sus juegos a través de parches descargables, todo gracias a internet.

Actualmente es muy difícil pensar en un videojuego que no entre en alguna etapa de mantenimiento, incluso si fue lanzado para consola. La accesibilidad que se obtiene por medio de Internet permite que los desarrolladores puedan hacer seguimiento continuo a sus productos, detectando y solucionando errores, problemas jugabilidad y extendiendo las capacidades del juego ofreciendo contenido nuevo.

Beta testing Las pruebas Beta son una práctica común en la industria pues agilizan el proceso de pruebas, aprovecha el máximo número de testers con el mínimo de recursos, y en general sirve también como un pre – lanzamiento del producto.

Las pruebas consisten en hacer un lanzamiento limitado del juego a un público selecto, en general de forma gratuita pero controlada. En esta etapa el juego ya debe estar en post-producción, y ser una versión muy cercana al lanzamiento final.

Los jugadores elegidos tendrán la oportunidad de probar el juego por un tiempo y previo al lanzamiento oficial, con el objetivo de otorgarle a los desarrolladores información sobre el desempeño del mismo. Para sacar el mayor provecho de unas pruebas Beta, es necesario considerar: 

  



Proveer a los usuarios de un buen sistema de reporte de errores. Los betatesters son conscientes de que van a probar un producto que no está 100% terminado y que puede tener fallas, lo que si no tolerarán será no tener un sistema eficiente y fácil de usar de reporte de bugs.

Tener un buen equipo de apoyo a la comunidad que esté pendiente del desarrollo de las pruebas.

Definir y caracterizar bien todos los aspectos que se desean probar del desempeño del juego, por fuera de los errores que se encuentran.

Aprovechar la versión beta para crear expectativa sobre el juego (hype) sin revelar los elementos más emocionantes que serán parte del lanzamiento oficial.

No tener miedo de recibir críticas y feedback de los testers, en especial si se detecta algún comportamiento no deseado en la dinámica del juego que no se tuvo en cuenta durante el diseño del mismo.

Seguimiento de Analytics Previo a la publicación del juego es importante que el juego ofrezca retroalimentación a los desarrolladores de cómo está siendo usado, esto solo se puede hacer en aquellos juegos que poseen las capacidades de conectarse a través de internet. Es necesario identificar el tipo de información de juego que se desea recolectar y el propósito detrás de la actividad. Información común que se desea recolectar en un videojuego es:     

Información de compra o descargas.

Tiempo de juego.

Zonas de salida (cuándo el jugador decide acabar la sesión de juego).

Zonas de abandono (cuándo el jugador decide dejar de jugar).

Comportamiento competitivo, si el juego es multijugador (Qué personajes se usan más, qué armas, quien pierde o gana más y en dónde).

Publicación La publicación se refiere únicamente al momento en que el juego está disponible al público. La publicación puede ser física (por retail) o digital en distintos tipos de portales (Steam, GOG). La publicación marca un punto donde ya se enfrenta al usuario final, y lo único que hay por hacer es esperar la reacción del público.

Mantenimiento Para el mantenimiento se prueba el juego, durante un periodo de tiempo esperando obtener la mayor cantidad de informes de bug como sea posible. Una vez que el desarrollador cree que ha obtenido suficiente información, los programadores deben empezar a trabajar en un parche. El parche puede tardar semanas o meses en desarrollarse, pero es la intención de corregir los errores más críticos y problemas con el juego que causaba el mal funcionamiento del código anterior, o en raras ocasiones, solucionar problemas no deseados causados por los parches anteriores. En ocasiones, un parche puede incluir características adicionales, contenidas o incluso puede alterar el juego.

En el caso de un juego multijugador masivo online (MMOG), como un MMORPG o MMORTS, el envío del juego es la fase inicial de mantenimiento. Los juegos en línea son de mantenimiento continuo ya que el mundo del juego está cambiando continuamente y se añaden nuevas funciones. El personal de mantenimiento para un MMOG popular puede contarse por docenas, a veces incluyendo a los miembros del equipo de programación original.

Este proceso es un proceso cíclico que busca mejorar la versión beta del videojuego, con el fin de tener una versión finalizada para lanzar al mercado, por esto la importancia de un buen sistema de comunicación (administradores de bugs) que les permita a todas las partes enterarse de lo que tienen que hacer y cuando con el fin de no generar actividades que estanquen el ciclo.

Análisis Es importante tomar la información de las analíticas implementadas para tomar decisiones, en especial en juegos que evolucionan con el tiempo, como los mencionados anteriormente. El proceso de análisis ayuda a identificar: 

Errores que deben ser corregidos.

  

Arreglos que se deben realizar en cuanto al balance o características de elementos de juego.

Comportamientos y jugabilidad que no se esperaban.

Necesidad de más contenido.

En el proceso rápido se centra más en la adicción de analytics al juego antes de su publicación, y así se recopilar información para futuros trabajos, como parches o actualizaciones.

Fig. 14: Diagrama del despliegue y el mantenimiento en el proceso rápido.

CAPÍTULO VII: HERRAMIENTAS Existen diferentes herramientas que permiten dar soporte a las diferentes etapas del desarrollo de los videojuegos. Existen herramientas tanto de libres como de pago que valen su mención debido a su aporte al mundo del contenido digital.

Diseño Stitches: Es un generador de sprite sheets en línea que permite arrastrar las imágenes para tu sprite sheet y generarlo automáticamente.

Pencil: Es un software de animación y dibujo para Mac OS X, Windows y Linux.

Permitiendo crear animación tradicional a mano (dibujos animados) con mapa de bits y gráficos vectoriales. Pencil es gratuito y de código abierto.

Inkscape: Es un editor de gráficos vectoriales de código abierto, con capacidades similares a Illustrator, Freehand, CorelDraw o Xara X, usando el estándar de la W3C: el formato de archivo Scalable Vector Graphics (SVG). Las características soportadas incluyen: formas, trazos, texto, marcadores, clones, mezclas de canales alfa, transformaciones, gradientes, patrones y agrupamientos. Inkscape también soporta meta-datos Creative Commons, edición de nodos, capas, operaciones complejas con trazos, vectorización de archivos gráficos, texto en trazos, alineación de textos, edición de XML directo y mucho más. Puede importar formatos como Postscript, EPS, JPEG, PNG, y TIFF y exporta PNG así como muchos formatos basados en vectores.

El objetivo principal de Inkscape es crear una herramienta de dibujo potente y cómoda, totalmente compatible con los estándares XML, SVG y CSS. También busca mantener una próspera comunidad de usuarios y desarrolladores usando un sistema de desarrollo abierto y orientado a las comunidades, y estando seguros de que Inkscape sea fácil de aprender, de usar y de mejorar.

Adobe Illustrator (AI): Es el nombre o marca comercial oficial que recibe uno de los programas más famosos de la casa Adobe, junto con sus hermanos Adobe Photoshop y Adobe Flash, y que se trata esencialmente de una aplicación de creación y manipulación vectorial en forma de taller de arte que trabaja sobre un tablero de dibujo, conocido como “mesa de trabajo” y está destinado a la creación artística de dibujo y pintura para Ilustración (Ilustración como rama del Arte digital

aplicado a la Ilustración técnica o el diseño gráfico, entre otros). Es desarrollado y comercializado por Adobe Systems Incorporated y constituye su primer programa oficial de su tipo en ser lanzado por ésta compañía definiendo en cierta manera el lenguaje gráfico contemporáneo mediante el dibujo vectorial. Adobe Illustrator contiene opciones creativas, un acceso más sencillo a las herramientas y una gran versatilidad para producir rápidamente gráficos flexibles cuyos usos se dan en (Maquetación-Publicación) impresión, vídeo, publicación en la Web y dispositivos móviles. Las impresionantes ilustraciones que se crean con éste programa le han dado una fama de talla mundial a esta aplicación de manejo vectorial entre artistas gráficos digitales de todo el planeta, sin embargo, el hecho de que hubiese sido lanzado en un principio para ejecutarse sólo con el sistema operativo Macintosh y que su manejo no resultara muy intuitivo para las personas con muy poco trasfondo en manejo de herramientas tan avanzadas afectó la aceptación de éste programa entre el público general de algunos países.

Synfig Studio: Es un software de animación 2D libre y de código abierto, diseñado para la creación de animación de calidad cinematográfica con una ilustración vectorial o de mapa de bits. Se elimina la necesidad de crear la animación fotograma a fotograma, lo que le permite producir animaciones 2D de mayor calidad con menos personal y recursos. Synfig Studio está disponible para Windows, Linux y MacOS X. GIMP: Es el acrónimo de GNU Image Manipulation Program. Se trata de un programa de distribución gratuita para tareas como retoque fotográfico, composición de imágenes y creación de imágenes. Tiene muchas capacidades.

Puede ser utilizado como un simple programa de dibujo, un programa de retoque fotográfico, un sistema de procesamiento de imágenes o un convertidor de formato de imagen, etc.

GIMP es expandible y extensible. Está diseñado para ser ampliado mediante plugins y extensiones para hacer casi cualquier cosa. La avanzada interfaz de scripting permite todo, desde las tareas más simples a los más complejos procedimientos de manipulación de imágenes para ser fácilmente secuencias de comandos.

Adobe Photoshop: Es uno de los programas más famosos de edición de fotografías, y que se trata esencialmente de una aplicación informática en forma de taller de pintura y fotografía que trabaja sobre un “lienzo” y que está destinado a la edición, retoque fotográfico y pintura a base de imágenes de mapa de bits. Su capacidad de retoque y modificación de fotografías le ha dado el rubro de ser el programa de edición de imágenes más famoso del mundo.

Blender: Es un programa informático multiplataforma, dedicado especialmente al modelado, animación y creación de gráficos tridimensionales.

El programa fue inicialmente distribuido de forma gratuita pero sin el código fuente, con un manual disponible para la venta, aunque posteriormente pasó a ser software libre.

Autodesk 3ds Max: Es un programa de creación de gráficos y animación 3D desarrollado por Autodesk. Creado inicialmente por el Grupo Yost para Autodesk, salió a la venta por primera vez en 1990 para DOS. 3ds Max, con su arquitectura basada en plugins, es uno de los programas de animación 3D más utilizado, especialmente para la creación de video juegos, anuncios de televisión, en arquitectura o en películas.

Autodesk Maya: También conocido como Maya, es un programa informático dedicado al desarrollo de gráficos 3D por computadora, efectos especiales y animación. Surgió a partir de la evolución de Power Animator y de la fusión de Alias y Wavefront, dos empresas canadienses dedicadas a los gráficos generados por computadora. Más tarde Silicon Graphics (ahora SGI), el gigante informático, absorbió a Alias-Wavefront, que finalmente fue absorbida por Autodesk dueña de 3d Studio Max. Maya se caracteriza por su potencia y las posibilidades de expansión y personalización de su interfaz y herramientas. MEL (Maya Embedded Language) es el código que forma el núcleo de Maya y gracias al cual se pueden crear scripts y personalizar el paquete.

El programa posee diversas herramientas para modelado, animación, renderización, simulación de ropa y cabello, dinámicas (simulación de fluidos), etc.

Además, Maya es el único software de 3D acreditado con un Oscar gracias al enorme impacto que ha tenido en la industria cinematográfica como herramienta de efectos visuales, con un uso muy extendido debido a su gran capacidad de ampliación y personalización.

Desarrollo Aptana Studio: Es un entorno de desarrollo integrado de software libre basado en eclipse y desarrollado por Aptana, Inc., que puede funcionar bajo Windows, Mac y Linux; provee soporte para lenguajes como: Php, Python, Ruby, CSS, Ajax, HTML

y Adobe AIR. Tiene la posibilidad de incluir complementos para nuevos lenguajes y funcionalidades.

CAAT: Es un gestor de escenas gráficas basado en la dirección de multiisntancias. Es capaz de hacer uso de Canvas, WebGL y CSS con el mismo código base, también características como actores, contenedores, transiciones de escena, comportamientos, interpolaciones, caminos, pila personalizada de transformación, temporizadores, ciclo de vida de los elementos, entre otras más.

Construct2: Es un editor de juegos 2D basado en HTML5, desarrollado por Scirra Ltd. Se dirige principalmente a los no programadores, que permite la creación rápida de los juegos mediante la mecánica de arrastrar y soltar, usando un editor visual y un sistema de lógica basada en el comportamiento.

GameMaker: Está hecho para principiantes y experimentados por igual, permitiéndoles crear juegos multiplataforma en tiempo record y por una fracción del costo.

Además de acelerar en un 80 por ciento el desarrollo de juegos en comparación a programar en lenguajes nativos, los desarrolladores pueden crear en unas pocas horas prototipos completamente funcionales, y un juego completo en cuestión de semanas.

LimeJs: Es un marco de trabajo HTML5 para la construcción rápida de juegos para todas las pantallas táctiles modernas y navegadores de escritorio.

Unity 3D: Es un ecosistema de desarrollo de juegos, un potente motor de renderizado totalmente integrado con juego, con un completo arsenal de herramientas intuitivas y flujos de trabajo rápidos para crear contenido 3D interactivo; publicación multiplataforma fácil, miles de activos de calidad, listos para usar en la “Asset Store” y una comunidad de intercambio de conocimientos.

Producción MANTIS Bug Tracker: Es un sistema de seguimiento de errores (lista de características) muy popular basado en la web. Está escrito en el lenguaje de programación PHP y trabaja con MySQL, MS SQL y bases de datos PostgreSQL y un servidor web. Mantis se puede instalar en Windows, Linux, Mac OS, OS / 2, y otros. Casi cualquier navegador web debe ser capaz de funcionar como un cliente.

Se distribuye bajo los términos de la Licencia Pública General de GNU (GPL).

Kunagi: Kunagi ofrece una gestión integrada de proyectos, que complementa Scrum con una selección de las mejores prácticas para cubrir todas las necesidades de gestión de proyectos. No sólo ofrece la gestión de los documentos básicos de Scrum, sino también una serie de datos adicionales. Además, incluye varias características para la facilidad de uso y la colaboración.

Kunagi pretende ser accesible y conveniente para el desarrollo profesional y no profesional de proyectos de cualquier tamaño. Su interfaz web utiliza la última tecnología para lograr la usabilidad del software de escritorio mientras se ejecuta en un navegador, por lo que es accesible desde cualquier lugar.

GitHub: es una página para alojar proyectos utilizando el sistema de control de versiones Git. Utiliza el framework Ruby on Rails porGitHub, Inc. Desde enero de 2010, GitHub opera bajo el nombre de GitHub, Inc. El código se almacena de forma pública, aunque también se puede hacer de forma privada, creando una cuenta de pago.

Dropbox: Es un servicio de alojamiento de archivos multiplataforma en la nube, operado por la compañía Dropbox. El servicio permite a los usuarios almacenar y sincronizar archivos en línea y entre ordenadores y compartir archivos y carpetas con otros.

Existen versiones gratuitas y de pago, cada una de las cuales cuenta con opciones variadas. Está disponible para Android, Blackberry e IOS (Apple). Dropbox es un software que enlaza todas las computadoras mediante una sola carpeta, lo cual constituye una manera fácil de respaldar y sincronizar los archivos.

Sonido Audacity: Es un editor de audio libre, fácil de usar, multipista para Windows, Mac OS X, GNU/Linux y otros sistemas operativos. La interface está traducida a varios idiomas. Se puede usar Audacity para:       

Grabar audio en vivo.

Grabar el sonido que se esté escuchando en el equipo si utiliza Windows.

Convertir cintas y grabaciones a sonido digital o CD. Editar archivos WAV, AIFF, FLAC, MP2, MP3 y Ogg Vorbis.

Cortar, copiar, unir y mezclar sonidos.

Cambiar la velocidad o el tono de una grabación.

Y mucho más. Vea la lista completa de funciones.

Linux MultiMedia Studio: También conocido como LMMS, es una estación de trabajo de audio digital de software libre (licenciado bajo GPL) y multiplataforma que permite producir música con el ordenador.

Análisis Google Analytics: Es un servicio gratuito de estadísticas de sitios web. Ofrece información agrupada según los intereses de tres tipos distintos de personas involucradas en el funcionamiento de una página: ejecutivos, técnicos de marketing y webmasters.

Se pueden obtener informes como el seguimiento de usuarios exclusivos, el rendimiento del segmento de usuarios, los resultados de la campaña de marketing, el marketing de motores de búsqueda, las pruebas de versión de anuncios, el rendimiento del contenido, el análisis de navegación, los objetivos y proceso de redireccionamiento o los parámetros de diseño web. Este producto se desarrolló en base a la compra de Urchin (hasta entonces la mayor compañía de análisis estadístico de páginas web) por parte de Google.

Piwik: Es una herramienta de análisis web gratuita que le proporciona informes detallados sobre los visitantes de su sitio web, sus campañas de marketing y mucho más. Piwik es de código abierto.

CAPÍTULO VIII: RESULTADOS SIMÓN EL BOBITO En este trabajo, el objetivo es crear y publicar una de las mejores prácticas de producción contenido digital en línea basada únicamente en tecnologías de código abierto para su desarrollo total a bajo costo y manteniendo la calidad, compitiendo contra procesos basado en herramientas comerciales para el desarrollo del contenido digital.

Siguiendo tendencias de la industria, que se centrarán en las plataformas web y móviles utilizando marcos HTML5 para videojuegos de plataformas en 2D y libros interactivos. Siguiendo las tendencias más recientes, este también debe permitir en forma simultánea el desarrollo de ambos, el videojuego y el libro interactivo.

Para lograr estos objetivos, se simulo un inicio de producción de contenidos digitales donde sólo se utilizan herramientas de código abierto. Con el fin de simular un medio ambiente realista, una serie de técnicas y estrategias utilizadas por las empresas de éxito en todo el mundo se planificaron y ejecutaron.

Los resultados parciales en la pre-producción han demostrado que alianzas estratégicas son una estrategia muy fructífera que puede mejorar el logro de los objetivos de negocio. "La Fundación Rafael Pombo" es una organización dedicada a la promoción y popularización del legado del poeta Rafael Pombo, quienes han demostrado ser muy amables al dar su apoyo en el uso de las licencias de los personajes y la orientación pedagógica del proyecto, de no ser por ellos, un esfuerzo mucho mayor habría sido necesaria con el fin de definir una audiencia y un tema nuevos.

La producción simultánea de un videojuego y el libro han demostrado ser de facilidad cuando se utiliza las mismas tecnologías. La reutilización de código y activos en un principio llego a casi el 40%.

Logros alcanzados en los procesos de apoyo incluyen análisis estadístico de la interacción del usuario con la plataforma HTML5 para la creación de informes de análisis de embudo. Estos informes ayudan a los diseñadores de juegos para comprender las tasas de deserción para los diferentes conceptos en el juego o el

libro y crear cambios al diseño del contenido en lugar del código, con el fin de mejorar el producto.

Al hacer el análisis de proceso de construcción de contenidos digitales se pudo determinar que la secuencia es “Buscar Heramientas-> Crear assets-> Integracion a la herramientas -> Completar el libro”, lo que genera un contenido de con excelente calidad independiente de si es una herramienta libre o licenciada.

En la etapa de preproducción se aprovechó el trabajo con la fundación Rafael Pombo para la creación del story board que dio soporte al documento de diseño del juego y el libro, dando como resultado un pitch y el documento de diseño del juego.

En la etapa de producción se realizó el diseño de personajes, la creación de assets, desarrollo y retroalimentación, que permitió obtener una versión preliminar.

En el proceso de diseño, no existió una limitante importante al usar una herramienta se software libre comparada con una privada, lo que permitió aprovechar el contenido previo elaborado para el libro para generar el juego.

Etapa de post-producción: Sonido->Musicalizacion->Ajuste multiplataforma-> Ajustes del juego. Para la evaluación del juego uso la plataforma “Piwik” a través de la creación de un plug-in que permite obtener datos de los usuarios como el apreciado en la Fig. 14, donde 3 personas probaron el juego solo dos jugaron el primer nivel y solo una persona continuo en el segundo nivel.

Fig. 14: Ejemplo de métricas obtenidas durante las pruebas del juego.

Video 8: Presentación del libro interactivo de “Simón el bobito”.

Fig. 15: Pantalla de inicio del juego de “Simón El Bobito”.

CAPÍTULO IX: EVENTOS De.Vi.C.E. De.Vi.C.E. (Desarrollo de Videojuegos Creativo y Experimental) es un evento colaborativo de creación de videojuegos diseñado para crear un espacio de aprendizaje e innovación.

La propuesta principal de De.Vi.C.E es el aprendizaje, espacio que no es común encontrar en otros eventos de este estilo. Teniendo esta proposición en cuenta, De.Vi.C.E ofrece un espacio de cuatro semanas. En las primeras dos los participantes pueden explorar y conocer las herramientas, conocimientos y habilidades necesarias para el proceso de desarrollo, mientras que en las últimas dos semanas se lleva a cabo el desarrollo de los juegos como tal.

El objetivo final del evento es formar grupos aleatorios de desarrollo en las semanas finales para crear un videojuego sencillo con base a un tema propuesto.

Al final, todos los grupos presentan su producto final, o por lo menos un prototipo de una idea que pueda desarrollarse en el futuro. Los resultados son sometidos a votación de los participantes y del público que visite el portal web del evento para seleccionar un juego ganador.

Para la primera versión de De.Vi.C.E se contó con 193 estudiantes inscritos. Los participantes se dividieron en tres roles de trabajo distintos: 89 para el rol de Desarrollo/Programación, 62 para el rol de Arte/Diseño y 42 para el de Música.

Hubo representación de 12 ciudades distintas del país e interés por aprender a usar por primera vez o para expandir los conocimientos previos de 18 herramientas distintas de desarrollo, dentro de las que se pueden destacar: Unity, GameMaker, Gimp y Audacity.

El tema elegido para la primera versión de De.Vi.C.E era cambiar de tamaño, todos los juegos creados debían incluir de alguna manera esta mecánica. El evento se llevó a cabo en cuatro etapas de desarrollo y una de postmortem.

Se estableció un periodo inicial de divulgación e inscripciones de aproximadamente tres semanas para dar a conocer el evento en distintos medios

y manejar la inscripción de los participantes. La divulgación del evento y el periodo de inscripción se llevó a cabo durante las dos últimas semanas de Febrero de 2014, para dar comienzo a las actividades del evento en la primera semana de Marzo. La convocatoria estaba dirigida a estudiantes bachilleres o de pregrado interesados en el tema. Era posible inscribirse de forma individual o inscribir un grupo de compañeros pre-formado para el posterior trabajo grupal.

Toda la información que se suministró a lo largo del evento, al igual que el manejo del proceso de inscripción y de la entrega de trabajos semanales se realizó a través de un portal web desarrollado específicamente para el primer evento.

Adicionalmente, con fines de publicitar el evento y de crear una comunidad web alrededor del mismo, se crearon grupos de participación en Facebook y en Twitter.

Durante la primera semana del evento el objetivo principal era presentar a los participantes las distintas mecánicas y herramientas que se utilizarían en el evento, además de resolver dudas concernientes al portal y al evento. Se instó a los participantes a familiarizarse con una herramienta que les ayudara en su trabajo, y a comenzar su proceso creativo dentro del evento proponiendo un Pitch Document para un posible juego a desarrollar en las semanas finales.

Durante la segunda semana del evento, y la última del periodo de aprendizaje, se ofreció el espacio para que los participantes profundizaran en los conocimientos de la herramienta elegida y pusieran en práctica un poco de lo aprendido, por lo tanto, se les pidió un pequeño prototipo del juego que propusieron en la semana anterior. No se especificó ningún formato o criterio de entrega, teniendo en cuenta la amplia diferencia de trabajo entre los roles, solo se pidió demostrar en un video el funcionamiento del material construido.

En la tercera semana del evento se dio inicio a las actividades en grupo. Con base a las entregas realizadas durante las anteriores semanas, el equipo organizó tantos grupos como fue posible de tal manera que se equilibraran roles y conocimientos de herramientas, y se les dio una recomendación del tipo de juego a realizar (2D o 3D) y de la herramienta a utilizar. Si al evento los participantes se pre – inscribieron con un grupo, hasta este momento realmente empezaron a trabajar juntos. En base al rol y a herramienta que cada participante seleccionó se crearon 7 grupos de 5 personas, respetando la proporción de 2 desarrolladores, 2 diseñadores y 1 músico. Solo uno de los grupos participantes estaba pre – inscrito desde las primeras semanas.

Además de pedirles un primer prototipo funcional del proyecto, también se les pidió a los grupos una versión básica de un Documento de diseño del juego.

La cuarta y última semana del evento tuvo como objetivo únicamente completar un juego funcional y jugable. Al final de la semana se le pidió a los grupos un ejecutable del juego con el objetivo de publicarlo posteriormente en el portal web del evento para someter los trabajos a votación. Al final de la semana se escogió un juego ganador.

Durante esa misma semana de votación también se le pidió a los grupos un último entregable: un postmortem, donde se le pidió a los participantes hacer un pequeño análisis de su experiencia, comparando el juego planeado y el entregando, además de especificar algunas buenas o malas decisiones que tomaron como grupo durante el periodo de desarrollo.

REGLAS PARA PARTICIPAR Para poder participar en el evento se deben cumplir las siguientes reglas:  

Vivir en Colombia Tener algo de tiempo libre y muchas ganas de aprender

Después de inscribirse: 

  

A menos que desees trabajar con alguien en especial, se asignara un grupo aleatorio dependiendo del rol que se decida tomar al momento de la inscripción.

Una vez estén asignados los grupos, se debe ponerte en contacto con los compañeros que te fueron asignados.

El grupo es responsable de construir varios entregables a lo largo del evento, solo así será posible evaluar el trabajo y dar retroalimentación.

Al final comentara cuales fueron los mejores juegos.

TAREAS POR SEMANA El evento sigue la metodología de un “JAM”, en la cual durante un mes, compuesto por 4 semanas, se desarrollan diferentes actividades y al final de la semana se hace un entregable, las siguiente muestra es un ejemplo de las actividades propuestas en la página del evento.

Semana 1   

Elegir un rol.

Elegir una herramienta para dicho rol.

Diseñar un videojuego que haga uso del tema del mes, y crear un pitch que lo describa.



Aprender algo sobre la herramienta elegida, y crear un pequeño video mostrando lo que se aprendió (no importa que sea muy poco, ya tendremos otra semana para aprender algo mas).

Semana 2   

Aprender un poco más sobre la herramienta elegida, y crear un pequeño video mostrando lo que se aprendió (recomendado, aprender algo relacionado con el tema del mes).

Indicarnos que roles estás en capacidad de realizar y que herramientas manejas.

Indicarnos los nombres de usuario de tus compañeros de grupo (opcional, si tienes un grupo predefinido).

Semana 3    

Crear un documento de diseño con la idea desarrollada del juego.

Crear un prototipo funcional del juego propuesto.

Crear un video del prototipo funcionando y montarlo en YouTube.

Crear una copia de las conversaciones que hayan realizado por fuera de la herramienta en un archivo de texto.

Semana 4         

Proveernos los nombres completos de los participantes.

Crear una copia de las conversaciones que hayan realizado por fuera de la herramienta en un archivo de texto.

Crear un prototipo funcional final del juego propuesto.

Darnos el nombre del juego y una imagen que lo represente.

Crear un video (trailer) y montarlo en YouTube.

Entregarnos el código fuente y los ejecutables del juego.

Indicarnos si el ejecutable es Web y para que otras plataformas está dirigido.

Indicarnos en que plataforma se desarrolló el juego.

Indicarnos si nos dan permiso de divulgar su proceso de desarrollo como ejemplo para los demás concursantes.

Hasta el momento De.Vi.C.E. ha tenido ocho ediciones, tres en 2014 en los meses de marzo, mayo, septiembre y noviembre; y en 2015 en el mes de febrero, abril, septiembre y noviembre de las cuales se han producido 12. Cada juego tiene anexos que se pueden ser consultados en su página en el evento.

De.Vi.C.E. cuenta con un “Hall de la Fama” donde se destacan los juegos que ganaron cada uno de los eventos.

FUKUSHIMA GAME JAM El Fukushima Game Jam es un evento creado en 2011 para conmemorar a las víctimas del Desastre de Fukushima de ese mismo año. El Fukushima Game Jam, se realiza alrededor del mundo en conexión con Japón, es una instancia que ofrece a los entusiastas de los videojuegos, un espacio que dio origen a nuevos trabajos y obras creativas. Donde participaron cuatro países entre ellos Colombia, Taiwan, Chile y Japon.

El Fukushima Game Jam es un evento que inició en Japón en el 2011, para mostrarle al mundo la gran actividad alrededor de las Tecnologías de la Información existente en la región de Tohoku, afectada por el terremoto y posterior maremoto del mismo año. En el 2013, la IGDA Colombia se unió al trabajo realizado por la IGDA Japón en este evento. En el cual se busca desarrollar un juego completo en 36 horas.

Este evento que se organizó por primera vez en Colombia, tuvo dos sedes una en la ciudad de Bogotá y la otra en la ciudad de Medellín por parte del SENA. La Universidad de los Andes en colaboración con IGDA Colombia presento la sede Colombiana del Fukushima Game Jam 2013 en Bogotá, En total hubo una participación de 78 personas en la sede de Bogotá y 40 en la sede de Medellín.

Para dar inicio al Fukushima Game Jam, que comenzó el 2 de agosto de 2013 con la charla del consejero de la embajada del Japón en Colombia, Katsuhiro Matsumoto quien habló sobre el área de Fukushima y el desarrollo de la región desde el terremoto, seguido por la charla de parte de Microsoft sobre la construcción en HTML5 con la herramienta Construct2.

El Fukushima Game Jam, sede Colombia, inició con algunos eventos de entrenamiento en desarrollo de videojuegos y de concientización sobre el problema en Japón durante el viernes 2 de agosto de 2013. En simultánea con Japón comenzó el Game Jam el viernes a las 10pm, y se dio por terminado la sesión de desarrollo de videojuegos el domingo 4 de agosto a las 3am.

Durante el transcurso del evento se contó con licencias de desarrollo de diferentes productos para todos los participantes. Lo que permitió eliminar restricciones en cuanto a herramientas de desarrollo. A continuación se listan las herramientas que fueron llicenciadas:   

Unreal Engine UDK. Unity 3D. OPTPiXSpriteStudio.



BISHAMON Personal.

Como resultado final de este evento fueron creados 15 juegos en la sede de Bogotá que fueron publicados en la página de Juegalibre. Esto juegos fueron presentadas a los demás participantes mediante Streaming entre las 3am y las 5 am del domingo 4 de agosto de 2013. En este espacio se hizo la presentación de los juegos presentados en cada uno de los países participantes

Fig. 14: Juegos desarrollados en el Fukushima Game Jam 2013 Colombia, sede Bogotá.

Video 9: Video en japonés de la experiencia del Fukushima Game Jam 2013 y sus participantes en otros países.

Fig. 15: Entidades participantes en el Fukushima Game Jam 2013.

CAPÍTULO X: MONO Otro de los objetivos presentes en el proyecto D.A.V.I.D, es la construcción de herramientas para el apoyo a procesos de contenidos digitales, siendo uno de los más significativos, debido a que en Colombia, la mayoría de las pequeñas y medianas empresas de contenidos digitales llevan a cabo la ejecución de sus procesos con seguimientos, estimaciones y planeaciones muy poco detalladas, además de contar con mucho conocimiento tácito y poco explicito tanto a nivel de las labores realizadas por sus trabajadores, la gestión de proyectos y la estandarización de procesos, lo que conlleva a las empresas a tener una capacidad productiva limitada para asumir retos del mercado internacional que les permitan un mayor avance.

MONO surge como una derivación de este objetivo, cuya finalidad es proporcionar a la industria una herramienta de software libre adaptable a cualquier proceso de desarrollo de contenidos de digital, además de fácil uso y pensada en ayudar a estandarizar y hacer seguimiento de proyectos del mismo campo. En este orden, el software en cuestión debía cumplir con las siguientes funcionalidades: 

Gestión de Procesos: Se centra en la creación, modificación, utilización y reutilización de conjuntos de tareas que esta relacionadas de manera lógica para generar productos de contenidos digitales, entendidos como procesos, que pueden ser reutilizados mediante plantillas en diferentes proyectos. o Administración de tipos de plantillas de procesos (creación y modificación de agrupaciones de plantillas de procesos). o Administración de actividades (creación, modificación, definición de tipo y eliminación de actividades dentro de un proceso). o Administración de tareas por actividad (configuración y definición de tiempos, recursos y responsable de una actividad que será ejecutada como tarea de un trabajador). o Administración de plantillas de procesos (conjuntos de procesos reutilizables para cualquier proyecto definido en MONO). o Diseño de plantillas de procesos (modelador de procesos bajo notación BPMN 2.0). o Programación de procesos (Administración de actividades, validación y puesta en marcha de procesos en proyectos).



Gestión de Proyectos: Busca proveer funcionalidades para la creación, modificación, seguimiento y control de proyectos de contenidos digitales. o Administración de Proyectos (Creación y modificación de proyectos de una empresa registrada en MONO).

o Configuración de Proyectos (Priorización de actividades del proyecto, agregar nuevos procesos al proyecto y seguimiento de costos). o Ejecución de Proyectos (Seguimiento y control de proyectos mediante reportes y estadísticas). o Gerencia de Proyectos (Organización de proyecto colaborativos). 

Configuración General: Permite la creación y modificación de empresas según tipo, y tipos de productos que se pueden administrar en MONO. Además, de los recursos que posee cada una de estas empresas. o Administración de tipos de productos o Administración de Empresas  Administración de tipos de recursos  Administración de recursos



Administración de Roles: Permita la definiciones de roles de trabajo que pueden ser asignados a los distintos trabajadores de las empresas registrados en MONO.



Administración de Dispositivos: Gestión de productos generados a los largo de la ejecución de procesos en MONO, entendido como Artefactos, que pueden ser accedidos, modificador y utilizados en el ciclo de vida de un proyecto



o Administración de tipos de artefactos (ayuda para la tipificación dada a cada artefacto) o Administración de artefactos (Creación, Modificación y acceso de artefactos dentro de un proyecto o procesos según se requiera).

Administración de Usuarios: Creación, modificación y definición de permisos para usuarios que hacen uso de MONO.

Estas características debían ser implementadas entre 2012 y 2015, sin embargo, un tema sensible frente a su desarrollo era el proceso requerido para su construcción, ya que de utilizar un método tradicional como Relational Unified Process (RUP) u otros, se hacía necesario un diseño completo de la arquitectura del sistema por adelantado (Big Design Up Front), lo que generaba un retraso en tiempo 6 o 7 meses de espera para iniciar la construcción de MONO; pero, de ejecutar el proyecto siguiendo un método ágil para mostrar periódicamente resultados, a su vez tenía como contrapartida la condición de tener una arquitectura emergente y no pre-diseñada, lo que dejo a criterio del equipo de desarrollo la estructura y calidad del producto. Optando por usar Scrum como método ágil de desarrollo, con el reto de realizar el diseño de la arquitectura del sistema en la medida que fuese necesario.

En el marco de lo anterior y seguimiento las directrices de Scrum, cada Sprint del proyecto sería de 2 semanas, el desarrollo debía hacerse aplicando prácticas de

desarrollo orientado por pruebas (Test-Driven Development – TDD) y finalmente el equipo de trabajo se estructuró de la siguiente manera: 

El rol de “Product Owner” fue asumido por el director del proyecto D.A.V.I.D, quien se encargó de ser el intermediador entre las empresas participantes en el proyecto, Colciencias quien es la entidad financiadora la iniciativa y el equipo de desarrollo. De esta manera, se pudo gestionar los requerimientos y realizar cambios a lo largo del desarrollo.



Como “Scrum Master”, se eligió un profesor del departamento de Ingeniería de Sistemas de la Universidad, experto en gobierno e implementación de Tecnologías de la Información en organizaciones, con experiencia en gestión de proyectos relacionados con la generación de contenidos digitales.



Aunque Scrum no define o contempla este tipo de mirada, un rol adicional que se tuvo en cuenta para el proyecto fue el de "Architecture Owner", quien estaría a cargo de velar por la arquitectura del producto y de igual manera, comprometerse a realizar el papel de un segundo Scrum Master. Este rol fue asumido un profesor del mismo departamento, director de la Maestría en Arquitectura de TI y experto en el área.



En el caso de los “Scrum Developers”, dado que fue un proyecto financiado por Colciencias, el equipo de desarrollo se conformó por asistentes graduados en investigación de la facultad, quienes debían ser profesionales graduados realizando sus estudios de maestría, y que en contraprestación se financiarían su posgrado dentro de la Universidad.

De igual manera, a nivel técnico MONO fue construido mediante tecnología libres y open source, dado que su propósito no está pensado en generar lucro, sino apoyar la industria; que para efectos del desarrollo se optó su construcción mediante las siguientes tecnologías:

Software Ruby Ruby Rails Apache HTTPD

Versión 2.1.3

Descripción

Lenguaje programación base del software MONO. on Framework de aplicaciones web código abierto escrito 3.2.8 en Ruby, sobre el cual se escribió MONO. Servidor web HTTP de código abierto, sobre el cual se 2.2.22 despliega MONO. Módulo para el servidor web que soporte aplicaciones Phusion 4.0.53 desarrollado mediante Ruby, Python y Node.js, el cual Passenger se integra de la complicación del código de MONO. Sistema de gestión de bases de datos relacional, sobre MySQL 5.5.43 el cual se maneja la persistencia MONO. Java 1.7.0_80 Software que provee herramientas de desarrollo para la

Development Kit

Tomcat

7.0.26

Razuna

1.5.2

Kunagi

0.25.1

creación y ejecución de programas escritos en Java, su uso en MONO está en la ejecución del administrador de artefacto digital Razuna, y la herramienta de seguimiento a actividades Kunagi.

Servidor contenedor de Servlets para Java, el cual ejecuta Razuna y Kunagi.

Herramienta para administración de artefactos digitales, el cual se comunica con MONO para gestión de artefactos en los procesos implementados sobre el mismo.

Herramienta de administración de proyecto ágiles basados en Scrum.

Tabla 1: Tecnologías usadas en MONO.

La construcción de MONO se cumplió después de 36 sprints, 291 historias de usuario implementadas y 920 puntos de historias. Cada Sprint está planeado para cumplir con una funcionalidad en específico, como se detalla en la siguiente lista: Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Propósito Inicio del proyecto y proceso de formación. Definición de las tecnologías y configuración de los ambientes para el desarrollo del proyecto.

Implementar las operaciones CRUD para proyectos y el enlace al disco local, sin tener en cuenta el diseño de la interfaz de usuario.

Diseñar e implementar la interfaz de usuario para proyectos y depósitos.

Gestionar recursos de trabajo en contenidos digitales Gestionar plantillas de procesos y tipos de plantillas Gestionar procesos y actividades a partir de diagrama de flujo de procesos Gestionar procesos a través de la metáfora de panel de control y agregar compuertas de decisión a flujos Parámetros y configuración, asociación de artefactos Configuración de proyectos, generación de procesos a partir de plantillas, instanciación de un proceso Instanciación de un proceso, asociación de recursos y participantes en proyecto, configuración de ambientes Estadísticas del proyecto, vista Kanban del proyecto, integración repositorio de artefactos Razuna Niveles de acceso, autorización y autenticación, importación de artefactos basecamp, dropbox Importación de artefactos, asociar artefactos a un proyecto, script primera presentación proyecto Establecer priorización, tipos de control y revisiones para actividades

15 16 17 18 19 20 212 22 23 24 25 26 27 28, 29,30,31,32 33 34 35 36

Flujo del aprobación de tareas, control de estados de tareas Cambio de estados en Kanban, estadísticas de estados por procesos Aprobaciones en paralelo y secuenciales, acumulación de horas trabajadas, ordenar tareas por prioridad Motor de reglas, flujo de aprobación de tarea en Kanban Validar y publicar proceso, convertir aprobaciones en tareas Procesamiento de compuertas motor de reglas, tareas de decisión, histórico de revisiones Mejorar visualización de revisiones y decisiones, revisión de reportes, script segunda presentación Burndown chart Model driven development con RGEN, videos de documentación Construcción de Wiki de documentación, editar en configuración, generar metamodelo y modelo XPDL y Petrinets Documentación de Wiki, inhabilitación de usuarios y recursos, generar XPDL de proceso, xml de integracion Migración a la nube, pruebas automaticas , xml de integracion Ciclo de proceso y compuerta de cierre, pruebas de interfaz con Selenium, pruebas automáticas Información Perdida, después de un ataque informático al servidor de producción, donde se encontraba la herramienta de administración del proyecto.

Programa de Capacitación y Solución de problemas de seguridad en instancias de Amazon Web Services.

Prueba Piloto con empresarios y Solución de incidencias Prueba Piloto con empresarios y reconfiguración del set de pruebas Proceso de re-evaluación y mejora de MONO Tabla 2: Descripción de los Sprint del proyecto MONO.

Actualmente, MONO fue licenciado bajo una licencia GPL versión 3.0 con el propósito de proteger su uso y distribución como software open source en la industria de contenidos digitales Colombia, para que de esta manera, empresas pequeñas, medianas y grandes estén en capacidad de gestionar sus procesos y proyectos de preproducción, producción y postproducción de videojuegos, animación, largometrajes, entre otros; de forma colaborativa, integrada, controlado y planificada.

MONO se diferencia de las herramientas de gestión de proyectos basados en procesos mediante dos características fundamentales, la primera y más representativa, es su enfoque de trabajo colaborativo, dado que la aplicación está pensada para que varias empresas que a partir de acuerdos, puedan ejecutar proyectos de forma colaborativa, mediante recursos humanos y materiales compartidos y controlados desde la misma aplicación, lo que conlleva a que estas empresas puedan asumir retos mayores a su capacidad propia de forma individual.

Por otra parte, MONO a diferencia de las herramientas actuales de BPM, la ejecución de sus procesos se hace con base a los eventos que ocurren en la organización y no los definidos por el proceso, dado que las labores que ejecutan este tipo de empresas son de carácter artístico, rudimentario y manual, lo que conlleva a que se deben realizar priorización de actividades, y el cambio dinámico del flujo de trabajo, situaciones que son soportadas por MONO. Cabe agregar que dentro de los aspectos a resaltar de la labor realizada en el proyecto D.A.V.I.D, en particular MONO durante su desarrollo, se puede enunciar las ventajas en un primer momento que trajo el uso de esta herramienta con las empresas de pruebas, ya que se logró evidenciar que varias de las planificaciones, costos y asignaciones de trabajo realizadas en varias proyectos, no correspondían con el esperado o que su cuantía no era la correcta, como fue el caso de 3 empresas de la agremiación de empresas pos-productoras Postpopulli.

Si se desea conocer más sobre MONO y como usarlo, puede ingresar a la wiki, allí se puede encontrar información relacionada con el uso, instalación y gestión de la herramienta. De igual manera, se puede visitar la página del proyecto MONO y su descripción en la página de D.A.V.I.D.

CAPÍTULO XI: TRABAJOS FUTUROS El software con licencias de fácil acceso al menos para individuos seguirá siendo un elemento importante para el desarrollo de contenidos digitales, debido a su uso común en el mercado actual, al gran potencial de aprendizaje que proveen y al acceso a tecnología de punta. Analizamos a continuación cada uno de estos puntos.

En la actualidad hay una gran aceptación hacia las licencias abiertas desde el punto de vista de los productores de hardware y software para contenidos digitales, o por lo menos a licencias que les permita a individuos o estudiantes tener acceso a la tecnología sin incurrir en costos iniciales. La filosofía detrás de este movimiento es sencilla: si los desarrolladores de contenido aprenden a usar las herramientas y les gusta la funcionalidad que encuentran, es más probable que en el futuro compren licencias de dichas herramientas. Existen muchos esquemas disponibles, pero uno de los más exitosos últimamente ha sido el esquema de licenciamiento de Unity: Al entrar al mercado de los motores para videojuegos, sus competidores eran motores medianos que vendían licencias alrededor de U$1000.

En ese momento, Unity ofreció una licencia mucho más barata (alrededor de U$300), con la opción de descargar una versión gratuita con funcionalidad limitada.

Actualmente la mayoría de la funcionalidad del motor viene incluida en su versión de gratuita para individuos, su versión profesional cuesta alrededor de U$1500, y se puede decir que domina el mercado, a la par de motores más tradicionales como son Unreal Engine y Cry Engine. Aunque un motor verdaderamente abierto tiene algunas ventajas derivadas de su naturaleza como software libre, dichas ventajas son muy etéreas para cualquier desarrollador de contenidos que fácilmente puede tener acceso de manera legal a un software comercial de alta calidad. Dada la aceptación que ha recibido esta técnica de mercadeo, es muy factible que siga usándose en el futuro.

El software libre es también excelente para la educación. El desarrollo de material educativo alrededor de software de fácil acceso asegura que los estudiantes que usen dicho material no van a tener problemas de licenciamiento, lo cual crea una cultura poco establecida en Latinoamérica de uso de software legal. Si dicho material es también gratuito o de un costo accesible se crea una estrategia muy poderosa para la formación de profesionales en desarrollo de contenidos. Hay que mejorar los esquemas existentes de certificación, para que personas que aprendan por su cuenta o por medio de recursos de fácil acceso puedan también competir en el mercado laboral con base en sus competencias.

Por último, el software libre generalmente permite tener acceso a tecnologías de punta, dada la favorabilidad que encuentra este esquema de licenciamiento en

nuevas empresas creadoras de tecnología. Una empresa innovadora de tecnología generalmente le interesa crecer muy rápidamente su base de usuarios, y por consiguiente usa esquemas de software libre para licenciar sus innovaciones y hacerlas llegar a la mayoría de desarrolladores posible. Desde el punto de vista del desarrollador, estas tecnologías le permitirán tener acceso a herramientas de punta, que generalmente le permitirán aprovechar nuevos mercados para sus productos.

Ahora, desde nuestro punto de vista de desarrolladores de contenidos digitales en Latinoamérica y educadores para este público, tenemos que aprovechar las tecnologías de software libre para hacer más relevantes nuestros desarrollos a nivel mundial. Primero podemos ser observadores activos de lo que está pasando con nuevas tecnologías, para mostrarle al mercado qué oportunidades hay que aprovechar a mediano y largo plazo. Segundo, debemos preparar a nuestros estudiantes para que aprovechen las ventajas del software libre y similares, enseñándoles a buscar y usar nuevas tecnologías como parte de su trabajo normal y cotidiano. Tercero debemos preparar a nuestros ingenieros más avanzados para comprender y mejorar proyectos de software libre, para prepararnos a tener un rol más activo en la generación de tecnología para el desarrollo de contenidos digitales a nivel mundial.

BIBLIOGRAFÍA  Chulis, K. Análisis de Big Data para la monetización de videojuegos, juegos móviles y sociales. (2012) [en línea] [Consulta: 23 febrero 2014], Disponible en: http://www.ibm.com/developerworks/ssa/industry/library/ba-big-datagaming/ba-big-data-gaming-pdf.pdf

  

        

Experimental Gameplay Group, Experimental Gameplay Project (s.f), [en línea] [Consulta: 19 mayo de 2014], Disponible en: http://experimentalgameplay.com/ Figueroa P., Gómez, A., Gil, S., DE.Vi.C.E: Un evento de aprendizaje y desarrollo colaborativo de videojuegos, 1st Congreso de la Sociedad Española para las Ciencias del Videojuego, Barcelona, España p. 117-126.

Figueroa P., Mendoza N. Un proceso corto e introductorio al desarrollo de videojuegos, [en línea], [Consulta: 31 de agosto 2015], ], Disponible en: https://sistemasacademico.uniandes.edu.co/~pfiguero/dokuwiki/lib/exe/fetch. php?media=presentations:articulo_8ccc.pdf Fullerton, Tracy, Christopher Swain, and Steven Hoffman. Game design workshop: a playcentric approach to creating innovative games. n.p.: Amsterdam: Elsevier Morgan Kaufmann, 2008.

Gibson, Jeremy. Introduction to game design, prototyping, and development: from concept to playable game-with Unity® and C#. n.p.: Upper Saddle River, NJ: Addison-Wesley, 2015.

Gobal Game Jam, Gobal Game Jam (s.f) [en línea] [Consulta: 19 mayo de 2014], Disponible en: http://globalgamejam.org/ Gobal Game Jam, History (s.f) [en línea] [Consulta: 19 mayo de 2014], Disponible en: http://globalgamejam.org/history J. Sutherland y K. Schwaber, «Scrum Guides,» ScrumGuides.org, 2013. [En línea]. Available: http://www.scrumguides.org/. [Último acceso: 18 11 2015].

K. Beck, Test-Driven Development: By Example, Boston: Addison-Weskley, 2004.

Ludum Dare, Ludum Dare (s.f), [en línea] [Consulta: 19 mayo de 2014], Disponible en: http://www.ludumdare.com/ Pedersen, R., Game Design Foundations (Wordware Game and Graphics Library) [en línea], Chapter 8: The “One Pager” Concept Document, [Consulta: 19 febrero 2013], Disponible en: http://flylib.com/books/en/4.230.1.58/1/ Pérez, F., ESTUDIO DE TÉCNICAS DE ANIMACIÓN PARA PERSONAJES DE VIDEOJUEGOS (2011) [en línea], [Consulta: 19 febrero 2013],

Disponible en: http://master.us.es/masterma1/TfM_pdfs(Julio11)/Francisco_Miguel_Perez_ Romero.pdf

   

   

S. W. Ambler, A Manager’s Introduction to The Relational Unified Process, Ambysoft, 2005.

S. Ambler, «Big Modeling Up Front (BMUF) Anti-Pattern,» Agile Modeling, [En línea]. Available: http://www.agilemodeling.com/essays/bmuf.htm. [Último acceso: 18 11 2015].

Shell, J. The art of game design. Boston: Elsevier/Morgan, 2008. ISBN: 9780123694966.

Unión Europea, Programa Europa Creativa de apoyo a los sectores culturales y creativos (2014-2020): Subprograma MEDIA, [en línea], (2014), [Consulta: 23 febrero 2014], Disponible en: http://www.ayudas.net/Programa_Europa_Creativa_apoyo_sectores14054BT1ERP21O1PQ.htm Wikipedia, Game testing, [en línea], [Consulta: 19 febrero 2013], Disponible en: http://en.wikipedia.org/wiki/Game_testing Wikipedia, HUD (Informática), [en línea], [Consulta: 19 febrero 2013], Disponible en: http://es.wikipedia.org/wiki/HUD Wikipedia, Level design, [en línea], [Consulta: 19 febrero 2013], Disponible en: http://en.wikipedia.org/wiki/Level_design Wilson, G., Off With Their HUDs!: Rethinking the Heads-Up Display in Console Game Design [en línea], (2006), [Consulta: 19 febrero 2013], Disponible en: http://www.gamasutra.com