Embed Size (px)
Citation preview
Universidad de San Buenaventura Cali Facultad de Ingeniería
Programa de Ingeniería Multimedia
RACED, Modelo Centrado en el Usuario para el Desarrollo Ágil de
Videojuegos Casuales en Dispositivos Móviles
Proyecto de Grado para optar al título de Ingeniero Multimedia
EDGAR ALEXANDER BEJARANO SOTO
CÉSAR MARTÍNEZ URIBE
Director de la Investigación: Ing. Víctor Manuel Peñeñory
Cali, Valle del Cauca
Abril 11 de 2014
ii
Santiago de Cali, 11 de Abril de 2014
Ingeniero,
ANDRES CALDERON
Director Programa de Ingeniería Multimedia Universidad de San Buenaventura -
Cali
Nosotros Edgar A. Bejarano Soto identificado con la cedula de ciudadanía 16.289.374
de Cali y César Martínez Uribe identificado con la cedula de ciudadanía 1.107.038.166
de Cali, hacemos entrega de nuestro proyecto de grado titulado “Modelo para el
Desarrollo Ágil de Videojuegos Casuales en Dispositivos Móviles Centrados en el
Usuario” como requisito para optar al título de Ingeniero Multimedia, dejamos
constancia de que todo lo que está escrito aquí ha sido referenciado adecuadamente.
Atentamente
Edgar A. Bejarano Soto César Martínez Uribe
iii
AGRADECIMIENTOS
Queremos agradecer a nuestras familias, parejas, amigos y tutor por el apoyo
incondicional brindado durante la realización de este trabajo de grado.
iv
TABLA DE CONTENIDO
AGRADECIMIENTOS ..................................................................................................... iii
ÍNDICE DE ILUSTRACIONES ......................................................................................... vi
INDICE DE TABLAS ....................................................................................................... vii
RESUMEN DE LA PROPUESTA .................................................................................... 8
INTRODUCCIÓN ............................................................................................................. 9
JUSTIFICACIÓN ........................................................................................................... 16
ANTECEDENTES ......................................................................................................... 17
Nacimiento de la industria de videojuegos ............................................................ 17
Primeras consolas móviles para jugar ................................................................... 20
Avance de los dispositivos Móviles de las comunicaciones al entretenimiento 22
Video Juegos Casuales primera aplicación de Entretenimiento en dispositivos
móviles ...................................................................................................................... 26
CAPITULO I: MODELOS DE DESARROLLO DE SOFTWARE .................................... 27
1. Modelo en Cascada ........................................................................................... 27
2. Modelo en Espiral .............................................................................................. 29
3. Proceso Unificado Racional (RUP) .................................................................. 30
4. Ingeniería de Requisitos ................................................................................... 32
6. Scrum ................................................................................................................. 36
7. Programación Extrema (XP) ............................................................................. 39
8. Metodologías Cristal ......................................................................................... 42
CAPITULO II: MODELOS BASADOS EN LA INTERACCIÓN HUMANO –
COMPUTADOR, LA USABILIDAD Y EL DISEÑO CENTRADO EN EL USUARIO ....... 45
1. Usabilidad e Interacción Humano Computador (HCI)..................................... 45
2. Ingeniería de la Usabilidad ................................................................................ 50
3. Diseño centrado en el usuario (DCU) .............................................................. 58
v
CAPITULO III: MODELOS PARA EL DESARROLLO DE VIDEOJUEGOS................... 62
1. Game Object Model II (GOM II) ......................................................................... 62
2. Game Unified Process (GUP) ............................................................................ 63
3. Huddle ................................................................................................................ 64
CAPITULO IV: DCU en Videojuegos ............................................................................. 66
1. Experiencia del Jugador (PX) y Jugabilidad ................................................... 66
2. Experiencia de Jugador en Dispositivos Móviles ........................................... 70
CAPITULO VI: RACED, MODELO CENTRADO EN EL USUARIO PARA EL
DESARROLLO AGIL DE VIDEOJUEGOS CASUALES EN DISPOSITIVOS MÓVILES 74
Fase 1: Conceptualización ...................................................................................... 77
Fase 2: Diseño .......................................................................................................... 81
Fase 3: Implementación ........................................................................................... 86
FASE 4: Control de Calidad ..................................................................................... 89
CAPITULO VII: ESCAPE FROM HELL, PROTOTIPO DE VIDEOJUEGO CASUAL
PARA DISPOSITIVO MÓVIL ......................................................................................... 91
FASE 1: CONCEPTUALIZACIÓN ............................................................................. 91
FASE 2 DISEÑO (DISEÑO GRAFICO) ..................................................................... 96
FASE 2: DISEÑO (Equipo de Desarrollo) ............................................................. 101
FASE 3: IMPLEMENTACIÓN .................................................................................. 104
CONCLUSIONES ........................................................................................................ 108
ANEXOS...................................................................................................................... 110
Anexo 1: Encuesta Fase 1 ..................................................................................... 110
Anexo 2: Pruebas Heurísticas Para todas las Fases del modelo ....................... 115
REFERENCIAS ........................................................................................................... 117
vi
ÍNDICE DE ILUSTRACIONES
Ilustración 1: Estudio realizado sobre el mercado de las aplicaciones móviles ............. 10
Ilustración 2: Reporte sobre los desarrolladores en los diferentes continentes. ............ 11
Ilustración 3: Categorías de aplicaciones más instaladas en Google Play y Apple App
Store .............................................................................................................................. 13
Ilustración 4: Primeras consolas portátiles, a la izquierda Mattel Electronics Auto Race,
en el medio Coleco Electronic Quaterback y a la derecha Microvision ......................... 20
Ilustración 5: a la izquierda un Game & Watch de Super Mario Bross y a la derecha el
primer Game Boy que salió al mercado. ....................................................................... 21
Ilustración 6: Primer teléfono celular del mercado DynaTAC 8000X ............................. 23
Ilustración 7: "Simon", considerado el primer SmartPhone de la historia. ..................... 23
Ilustración 8: Nokia 6110 con la aplicacion de “Snake” abierta. .................................... 24
Ilustración 9: Flujo de trabajo del Modelo en Cascada. ................................................. 27
Ilustración 10: Flujo de trabajo del modelo en Espiral ................................................... 29
Ilustración 11: Flujo de trabajo del RUP. ....................................................................... 30
Ilustración 12: Marco de trabajo de Scrum .................................................................... 36
Ilustración 13: Marco de trabajo de XP .......................................................................... 39
Ilustración 14: Marco de trabajo Cristal. ........................................................................ 42
Ilustración 15: Espacios de trabajo del Game Object Model ......................................... 62
Ilustración 16: Las tres fases de Huddle. ....................................................................... 64
Ilustración 17: Triada de la Jugabilidad ......................................................................... 69
Ilustración 18: Guía de estilo y evaluación de videojuegos en móviles (Nokia, 2010) ... 72
Ilustración 19: Elementos heurísticos propuestos por (Korhonen, 2006) ...................... 73
vii
Ilustración 20: Esquema de trabajo de RACED ............................................................. 76
Ilustración 21: A la izquierda bocetos del personaje y a la derecha un concepto final. . 97
Ilustración 22: Estados del personaje en su diseño final. .............................................. 97
Ilustración 23: Diseño del nivel del videojuego. ............................................................. 98
Ilustración 24: Prototipo en papel del video juego. ........................................................ 99
Ilustración 25: Correcciones realizadas después de las pruebas. ............................... 101
Ilustración 26: Casos de uso. ...................................................................................... 102
Ilustración 27: Aparte de un Script de programación. .................................................. 103
Ilustración 28: Diseño de personaje en Pixelart. .......................................................... 104
Ilustración 29: Interfaz de trabajo en Unity 3D. ............................................................ 105
Ilustración 30: Prueba de usuarios. ............................................................................. 107
INDICE DE TABLAS
Tabla 1: Objetivos en el diseño de la Experiencia de Usuario y la Experiencia de
Jugador.......................................................................................................................... 68
Tabla 2: Software de Escritorio vs Software de Entretenimiento ................................... 68
Tabla 3: Análisis de Requisitos videojuego Escape From Hell ...................................... 93
Tabla 4: Análisis de Usuarios ........................................................................................ 94
Tabla 5: Asignación de tareas. ...................................................................................... 96
8
RESUMEN DE LA PROPUESTA
El progreso de las tecnologías informáticas y de comunicaciones ha permitido integrar
en dispositivos móviles gran potencia de cálculo y almacenamiento. Esto ha conllevado
al uso acelerado de tecnologías móviles en todo el mundo. Provocando así, la aparición
de un mercado totalmente novedoso para el desarrollo de aplicaciones, especialmente
videojuegos. Los videojuegos son la aplicación móvil más vendida en los mercados
internacionales, y Colombia no es ajena a esta realidad, muchos desarrolladores y
emprendedores ven en esto un mercado virgen y lleno de posibilidades, por esta razón
es necesario pensar en introducir un modelo de desarrollo ágil que permita crear
videojuegos de gran calidad y que atiendan a la demanda del mercado y que su
desarrollo sea diseñado basado en la experiencia del usuario.
9
INTRODUCCIÓN
Los rápidos avances de la informática, así como la constante evolución de las
telecomunicaciones que comenzaron a principios de este siglo, permitieron la
posibilidad de reducir los tamaños de los procesadores y componentes electrónicos,
estos avances facilitaron la portabilidad de dispositivos sin dificultad. Fue así como
aparecieron los primeros dispositivos con características de almacenamiento y
computación cada vez mayor, computadores portátiles, Pocket Pc, videojuegos de
bolsillo, entre otros, comenzaron a abrirse paso en los mercados.
Los factores antes mencionados sumados a la consolidación en muy pocos años de
la tecnología inalámbrica puesta al alcance de todos en los teléfonos móviles, marco
una tendencia actual: fabricar dispositivos pequeños, que permitieran la comunicación y
con la mayor potencia de cálculo posible.
Los grandes fabricantes han integrado importantes características en estos
dispositivos, como por ejemplo, las ya mencionadas posibilidades de comunicación,
conexión a internet, conexión a redes sociales, entretenimiento, videojuegos,
reproducción de música, y almacenamiento de datos, todo en dispositivos móviles
conocidos actualmente como: Smartphones y Tablets, la potencia de cálculo de estos
es ahora comparable con ordenadores personales. Según el ingeniero Dilip
Krishnaswamy: “Los smartphones ayudan a los usuarios a estar conectados a la
10
información en cualquier momento, y en cualquier lugar, la información simplemente
está allí cuando usted la necesita” (Romero, 2011).
La masificación y difusión que han alcanzado los dispositivos móviles en tan poco
tiempo ha provocado la aparición de un mercado totalmente novedoso para el
desarrollo de aplicaciones, convirtiendo a los dispositivos en la plataforma ideal para la
implementación de soluciones innovadoras. Actualmente existen más o menos
1’200.000 aplicaciones disponibles en la tienda en línea de aplicaciones de Apple App
Store y el distribuidor de contenidos desarrollado por Google para dispositivos basados
en el sistema operativo Android llamado Google Play Store.
Ilustración 1: Estudio realizado sobre el mercado de las aplicaciones móviles1
1 Infografía realizada por la empresa StarDust (Viallon, 2013).
11
Ilustración 2: Reporte sobre los desarrolladores en los diferentes continentes2.
Hoy en día se conoce ampliamente los beneficios de los dispositivos móviles en las
actividades diarias de las personas, diferentes aplicaciones facilitan y hacen más
entretenida la vida, pues a través de estos aparatos se puede, por ejemplo, comprar
productos, comunicarse y compartir información, hacer relaciones a través de las redes
sociales, entretenerse y sobretodo jugar.
“Los videojuegos son una perspectiva del hombre debido a que el nacimiento y
crecimiento de estos, responde a cada momento histórico de la sociedad, sus fines
2 Estudio realizado por VisionMobile, empresa dedicada a la investigación de la economía y modelos de negocio de las aplicaciones móviles (VisionMobile, 2014).
12
constantemente cambian, desde su capacidad y tecnología hasta sus contenidos”
(Melissinos, O'Rourke, & Mika, 2012) .
En un principio nació como una industria enfocada para los niños, pero hoy en día, hace
parte intrínseca de todo ser humano. Los videojuegos se han convertido en un medio
de comunicación que representa las necesidades, ilusiones, fantasías, intelecto y el
gusto por alcanzar metas de las personas, estos factores han tomado mayor relevancia
en el auge actual de los dispositivos móviles debido a que los videojuegos están de
manera más fácil y al alcance de todos; existe una categoría de videojuegos llamada
casual, según la Asociación de Juegos Casuales o CGA por sus siglas en ingles “Los
juegos casuales son desarrollados para el público en general y familias, estos son
videojuegos que son divertidos y fáciles de aprender y jugar” (Casual Games
Association, 2005).
Estadísticas revelan el gran crecimiento a nivel mundial del desarrollo de videojuegos
para dispositivos móviles y en países desarrollados esta industria es abordada por un
grupo multidisciplinar de personas como lo son: programadores, diseñadores gráficos,
escritores, ilustradores entre otros (Baldwin, 2006), ya que el contexto comunicativo,
social y humano ha creado la necesidad de revalorizarlo en las últimas décadas,
empresas como Rovio, creadora del exitoso juego Angry Birds es clara muestra de
esto.
13
Ilustración 3: Categorías de aplicaciones más instaladas en Google Play y Apple App Store3
Por otra parte el crecimiento del uso de dispositivos móviles en América Latina ha
tenido un aumento del 16% en los últimos 2 años y se espera que para el 2018 esta
tendencia continúe acercándose al 60% (GSMA; A.T. Kearney; Wireless Intelligence,
2011), lo anterior ha dispuesto un mercado emergente y lleno de posibilidades de
empleo para los desarrolladores de aplicaciones móviles. Colombia tiene una gran
apuesta en este sentido, el gobierno nacional apoyado por el ministerio de las TIC tiene
en sus planes de desarrollo grandes propuestas de apoyo económico para las
empresas que comiencen a trabajar en este aspecto, entre los proyectos encontramos
apps.co4 que hace parte de la iniciativa vive digital5 con la cual el gobierno propone que:
“en el año 2014, los colombianos tendrán una vida más fácil y productiva gracias a una
amplia oferta de aplicaciones y contenidos digitales” (Ministerio de las TIC, 2011).
3 Reporte realizado por Distimo, empresa dedicada al análisis de las métricas de aplicaciones en los diferentes mercados para dispositivos móviles (Calinescu, 2014). 4 Iniciativa del Ministerio de las TIC Colombiano en el cual se propone capacitar a empresarios, independientes, emprendedores y cualquier persona interesada en temas de tecnología para el desarrollo de negocios que pongan a Colombia como un país “líder en la producción de aplicaciones digitales y emprendimiento“ (MinTIC, 2012). 5 Plan de tecnología del actual presidente Juan Manuel Santos, con el “que se busca que Colombia de un gran salto tecnológico mediante la masificación de internet y el desarrollo del ecosistema digital nacional” (MinTIC, 2010).
14
En Colombia, a pesar de que el gobierno dispone de importantes recursos económicos,
la oferta de aplicaciones móviles hechas en nuestro país es muy pequeña, además se
evidencia la poca experiencia que existe por parte de los desarrolladores para entrar a
competir con los diferentes países de elite, esta situación pone en duda el
conocimiento de un modelo para el desarrollo de videojuegos en dispositivos móviles
(Ministerio de las TIC, 2011).
Los aspectos señalados en los párrafos anteriores evidencian el crecimiento de
usuarios de aplicaciones, especialmente videojuegos, para dispositivos móviles y como
el desarrollo de estas aplicaciones se convierte en una industria importante y
emergente en nuestro país, pero para entender las razones que motivan la realización
de este trabajo debemos considerar dos conceptos. El primero de ellos es la evolución
de los sistemas de computación y de qué manera este desarrollo ha provisto al mundo
de innumerables dispositivos de propósito general y específico, como por ejemplo los
dispositivos móviles, y con ellos es posible realizar casi cualquier tarea que deba llevar
a cabo un humano en su contexto social de trabajo o incluso de ocio en consecuencia,
este desarrollo nos ha permitido entender el usuario como elemento importante,
generando así una disciplina denominada HCI (Human-Computer-Interaction) que en su
concepto trata de acercar a los usuarios cada vez a los dispositivos enfocándose en la
interacción entre individuo y ordenador y reconociendo la “Facilidad de uso ” como
concepto clave (Ramos, 2001). El segundo concepto es entender las exigencias de un
mundo globalizado que cambia constantemente, además de un mercado muy
competitivo de aplicaciones para dispositivos móviles, este mercado requiere que todos
15
los desarrollos sean implementados de manera eficiente y eficaz, para ello la
metodologías ágiles se enfocan en el desarrollo iterativo e incremental, donde los
requisitos y soluciones evolucionan mediante la colaboración de grupos auto
organizados y multidisciplinarios, pautas claves para realizar con éxito desarrollos de
aplicaciones. Es por esta razón que el reto para los nuevos desarrolladores de video
juegos para dispositivos móviles en Colombia, es realizar videojuegos de alta calidad y
que integren el diseño centrado en el usuario, la interacción humano – computador y
todo esto enmarcado en una metodología ágil de desarrollo (Kannan, 2011) que permita
responder a las exigencias de un mercado en crecimiento.
La pregunta que surge es: ¿cómo construir un modelo de desarrollo para videojuegos
casuales en dispositivos móviles, que integre la perspectiva de la Ingeniería de
Software, las metodologías ágiles, así como los principios de la interacción humano-
computador y el diseño centrado en el usuario?
16
JUSTIFICACIÓN
Se ha evidenciado que muchas empresas que actualmente elaboran videojuegos para
dispositivos móviles no acostumbran a seguir metodologías de desarrollo para sus
aplicaciones; según Luis Ernesto Parra, Director ejecutivo de la empresa Press Start
“Escribir documentos de diseño para juegos, no es lo mismo que desarrollarlos, en
nuestra empresa no hacemos documentos de diseño, en vez de eso, hacemos un
prototipo, no muy complejo, hacemos las pruebas digitales o en papel, las analizamos y
comenzamos a desarrollar” (Parra, 2013), por otra parte Tom Viswat Director de la
empresa de desarrollo ThumbStar respecto a este tema dice “Nosotros nos
preocupamos más por crear las estrategias de ventas y el marketing, nuestros
desarrolladores se encargan de presentarnos los juegos, algunas veces utilizan
metodologías conocidas de desarrollo” (Viswat, 2013).
Es por esta razón que se propone un modelo para el desarrollo de videojuegos en
dispositivos móviles, el cual integre el diseño centrado en el usuario y el HCI en una
metodología ágil de desarrollo, dicho modelo deberá satisfacer las necesidades de un
mercado y apuntar al objetivo que tiene nuestro país, en el desarrollo de tecnologías
digitales.
17
ANTECEDENTES
Nacimiento de la industria de videojuegos
El primer desarrollo de videojuegos comienza muy ligado a la guerra fría, las tensiones
políticas entre Estados Unidos y la Unión Soviética, que se enfrentaron desde el año
1945 hasta 1989 sin que ninguna de las dos partes tomara acciones contundentes
frente a la otra, generaron el comienzo de la investigación y la tecnología computacional
para simular y predecir situaciones frente a un supuesto ataque armado. Fueron
jóvenes científicos como el físico William Higinbotham y Steve Russell que
profundizaban en estas tecnologías y buscaban mejorar resultados militares, quienes
desarrollaron los primeros juegos e idearon la forma de usar dispositivos controladores
para la interacción y la simulación de situaciones con las maquinas, usado
osciloscopios, botones y otros elementos extraídos de componentes electrónicos como
teléfonos.
Fue así, como en respuesta a las tensiones de esta época, o como escape a la
seriedad y responsabilidad de sus trabajos o tal vez como un grito de juventud y
rebeldía, estos científicos empezaron a usar sus conocimientos y herramientas
tecnológicas para desarrollar videojuegos. En una sociedad paranoica donde pulsar un
botón era sinónimo de destrucción masiva, estos jóvenes usaron botones como primera
herramienta de interacción humano maquina hacia un nuevo mundo virtual.
18
Higinbotham en 1958 y Russell en 1962 fueron algunos de los pioneros de este
desarrollo con sus videojuegos Tennis for two y Space Invaders respectivamente.
En 1972 la popularización de estos juegos en las universidades y centros de
investigación de Estados Unidos donde contaban con sofisticados equipos, paralelo al
desarrollo de esta industria en Japón que estaba apostando a la miniaturización de los
componentes computacionales, llevó los videojuegos de los laboratorios y las
universidades directos a los hogares y los puso al alcance de las personas, a finales de
los setentas y comienzos de los ochentas, empresas como Namco, Atari y Magnavision
desarrollaron las primeras consolas para usar en casa con el televisor, el frenesí de las
videojuegos había comenzado. Con el auge de juegos como Pong y Space Invaders,
nacieron compañías que llenaron el mercado de las consolas con juegos de muy mala
calidad, pese a esto en 1980 Toru Iwatani de la empresa Namco, creo uno de los
videojuegos más representativos de la historia porque fue el primer juego pensado en
un personaje, con un diseño colorido, este juego rompió los esquemas porque se pensó
en una historia y se involucró en ella a un personaje que lograra dar más sentimiento a
la experiencia de jugar. El juego se llamó PAC-MAN.
En 1983 la industria de los videojuegos estaba en crisis, la sobresaturación del mercado
y el desarrollo de juegos de baja calidad, hizo pensar en la necesidad de conformar
equipos de trabajo interdisciplinarios para la creación de juegos, se valoró la
importancia de tener algo más que programadores, contar con artistas, ilustradores,
19
escritores, y sincronizar estos perfiles mediante metodologías de desarrollo que
permitieran controlar la calidad de los productos. La experiencia de juegos como PAC-
MAN había marcado un camino importante y empresas como Nintendo tenían muy
claro estos conceptos.
Fue así como en 1985 Nintendo lanza al mercado su consola y la acompaña el juego
que cambiaría el modo de ver la industria de los videojuegos, Mario Bros, fue el primer
juego en pensar en una historia, en un guion con un principio y un final y en el
desarrollo artístico que exigió más potencial de programadores y desarrolladores,
Nintendo fue la empresa en entender que los video juegos son la perspectiva del ser
humano y su necesidad de imaginación curiosidad y placer por ganar, competir y
sentirse personificados en mundo paralelos.
En 1988 Nintendo era la compañía más fuerte en la industria de videojuegos y se
aventuró a lanzar una consola portable llamada Game Boy, que se convertiría en el
dispositivo de videojuegos portátil más vendido y famoso. Entre sus novedades el
Gameboy tenía un juego llamado Tetris, este fue un juego desarrollado y diseñado en la
Unión Soviética en el año de 1984 por Alekséi Pázhitnov, sus derechos fueron vendido
a Nintendo en 1988 y la compañía lo incluyo en el lanzamiento de su Game Boy
convirtiéndolo en el juego más popular y jugado de todos los tiempos.
20
Primeras consolas móviles para jugar
El mercado del videojuego portátil ha sufrido muchas transformaciones a lo largo de su
historia y siempre ha estado de la mano del crecimiento de los juegos en consolas, los
primeros videojuegos portátiles fueron experimentos realizados a finales de los 70 como
el Mattel Electronics Auto Race y Coleco Electronic Quarterback (Estados Unidos
Patente nº 4249735, 1978) (Estados Unidos Patente nº 4327915, 1980), juegos muy
simples, que mostraban luces moviéndose alrededor de su pequeña pantalla de
bombillos LED.
Después en 1978 Milton Bradley desarrolla Microvision (Estados Unidos Patente nº
4359222, 1978) la primera consola portátil con juegos intercambiables Aunque no hay
datos oficiales de ventas, si se conoce que la compañía ingresó unos 8 millones de
dólares por esta consola en su primer año lo que supone algo más de 50 mil unidades.
Ilustración 4: Primeras consolas portátiles, a la izquierda Mattel Electronics Auto Race, en el medio Coleco Electronic Quaterback y a la derecha Microvision
21
El 1980 nace el primer videojuego portátil exitoso, fue la serie de juegos de bolsillo
Game & Watch de Nintendo basados en la electrónica de una calculadora. Algunos de
los personajes más populares de Nintendo como Mario, Link o Donkey Kong hicieron
acto de presencia en esta serie de minijuegos. Ya en 1989 la empresa Nintendo
revoluciono el mercado de los videojuegos portátiles, con su producto llamado GAME
BOY inspirándose en las máquinas Game & Watch. Se alimentaba mediante pilas, y
permitía jugar en cualquier lugar y a varios juegos. El Game Boy logró vender hasta
1998, unos 87 millones de unidades en todo el mundo, acaparando el 85% del mercado
portátil. En 1996 Nintendo sacó una versión reducida del GameBoy, la versión Pocket,
para revitalizar su portátil. Era una versión mucho más pequeña, con menos peso y una
pantalla más grande y que además tan sólo usaba 2 pilas en vez de las 4 de antes.
Ilustración 5: a la izquierda un Game & Watch de Super Mario Bross y a la derecha el primer Game Boy que salió al mercado.
22
A partir de aquí Nintendo ha tenido el liderato en el desarrollo de dispositivos móviles
para juegos, consolas como Game Boy Advance, Nintendo DS, hoy en día Nintendo
3DS comparte este liderato con el PSP o Play Station Portable de Sony.
Avance de los dispositivos Móviles de las comunicaciones al
entretenimiento
“Los dispositivos móviles han evolucionado de una manera muy rápida, en sus casi 30
años de existencia han pasado de ser teléfonos que median y pesaban mucho, a
celulares que apenas caben en la palma de nuestras manos, y que tienen múltiples
propósitos además de llamar. (Romero, 2011)”
La historia de los dispositivos móviles comienza en 1983, cuando la empresa americana
Motorola, incluía en el mercado el primer teléfono celular bautizado con el nombre de
DynaTAC 8000X, este era un teléfono que pesaba aproximadamente un kilo y media
casi treinta centímetros, su costo en el mercado era no más que $3995 dólares, sus
funciones incluían una memoria para guardar treinta números telefónicos y una batería
que duraba una hora.
23
Ilustración 6: Primer teléfono celular del mercado DynaTAC 8000X
La competencia aparecía diez años después en 1993, cuando IBM en compañía de
BellSouth, sacaron al mercado “Simon”, este se podría decir fue el Smartphone de la
época, ya que traía una pantalla táctil, entre sus funciones estaban él envió y
recibimiento de E-Mails y faxes, calculadora, calendario, agenda.
Ilustración 7: "Simon", considerado el primer SmartPhone de la historia.
24
La finlandesa Nokia estremecía el mercado en 1997 con su Nokia 6110, era el primer
teléfono que permitía la interconexión entre ellos, mediante su puerto infrarrojo. Entre
sus características estaba el famoso juego Snake, el cual tenía la opción de jugarse en
“red” por medio del puerto infrarrojo, convertidor de moneda, configuración de perfiles,
calculadora, reloj, calendario, envió de mensajes de texto, y carcasas intercambiables.
Ilustración 8: Nokia 6110 con la aplicacion de “Snake” abierta.
En el año 2000 Sony Ericsson incursionaba en el mercado con su R380, el cual fue el
primer celular en correr un sistema operativo, en este caso el Symbian OS. En el 2002
sacaron a la venta el P800, el cual incluía un reproductor de MP3s, cámara y una
pantalla táctil a color.
Después del 2002 aparecieron los primeros celulares con funciones de PDA conocidos,
donde la compañía RIM abarco el mercado rápidamente con su Blackberry 6210 en el
2003, el cual contaba con un teclado QWERTY para hacer más fácil el envío de
25
mensajes de texto o correos electrónicos; en ese mismo año la compañía Palm Inc.
lanzaba su Treo 600, el cual arribaba con un sistema operativo llamado Palm OS, entre
sus funciones se encontraba la posibilidad de llamar directamente desde la lista de
contactos y mirar el calendario mientras se hablaba, además soportaba aplicaciones de
terceros.
Ya en el año 2007 Apple inundaba el mercado con su iPhone, el cual arribaba con un
sistema operativo diseñado exclusivamente para estos dispositivos llamado iOS,
además brindaba la oportunidad de descargar aplicaciones gracias a su App Store. De
esta manera empezaba la denominada guerra de los Smartphones donde la compañía
HTC se unía con la poderosa Google para lanzar su sistema operativo Android, el cual
tendría muy buena acogida entre las diferentes compañías fabricantes de celulares,
Samsung, LG, entre otros.
Situación muy distinta sucedió en el mercado de las Tablet, ya que el primer paso se
puede decir que lo hizo Microsoft con su Tablet PC en el año 2001, la cual tuvo muy
poco éxito a diferencia de lo que haría su competencia Apple en 2010 con el
lanzamiento de su famoso iPad obteniendo un rotundo éxito. Actualmente compañías
como Samsung, BlackBerry, Sony, Toshiba, Acer entre otras, incursionaron en este
mercado monopolizado por el iPad.
26
Video Juegos Casuales primera aplicación de Entretenimiento en
dispositivos móviles
La Asociación Internacional de Desarrolladores de Videojuegos, IGDA por sus siglas en
inglés, define los juegos casuales como: “juegos que generalmente implican controles
de juego menos complicados y una complejidad global en términos de jugabilidad o la
inversión necesaria para pasar el juego” (International Game Developers Association,
1994). Los juegos casuales tienden a ser más lentos y no tan frenéticos como pueden
ser los juegos de alta gama para consolas o computador, además tienen reglas simples
y no requieren de mucho tiempo de juego.
Juegos como Snake y Tetris fueron las primeras aplicaciones en acompañar la
tecnología de comunicación móvil, después, juegos como Pac-Man, Solitario, Zuma,
Angry Birds, Plantas vs Zombies, entre otros, son juegos casuales de gran éxito, ya que
coinciden con el estilo de vida de muchas personas; son juegos que se pueden jugar en
cualquier lugar, por ejemplo, en el metro, bus, avión, oficina, entre otros y en intervalos
de tiempo no mayores a veinte minutos.
Las interfaces suelen ser amigables y permiten una experiencia de juego tranquila para
no estresar al usuario. Además para que un juego sea considerado casual, debe ser un
juego familiar.
27
CAPITULO I: MODELOS DE DESARROLLO DE SOFTWARE
1. Modelo en Cascada
Ilustración 9: Flujo de trabajo del Modelo en Cascada.
En los años 70 Winston W. Royce definió este modelo que ha sido utilizado y criticado
desde su creación. Fue el primer modelo lineal-secuencial en aparecer en el desarrollo
de software, presenta una característica especial en donde el proyecto debe describir
cada fase en papel antes de que alguna línea de código sea escrita.
Al usar esta metodología se debe tener especial cuidado en hacer un buen
levantamiento de requerimientos antes de pasar a la fase de implementación ya que el
costo de hacer algún cambio después de esta fase podría ser lo suficientemente alto
como para cancelar el proyecto.
El modelo en cascada está dividido en cinco fases, a continuación se explica cada una
28
de ellas:
Requerimientos: En esta fase se hace un levantamiento de las necesidades del
usuario para definir qué objetivos cumplir. Al finalizar debe crearse un documento
de especificación de requisitos, el cual contiene toda la información de lo que
debe hacer el producto.
Análisis y Diseño: Aquí se define la arquitectura de software que se va a
utilizar. Para esto se divide el proyecto en diferentes elementos que puedan ser
elaborados por los diferentes equipos de trabajo.
Implementación: En esta fase se definen los algoritmos que suplirán los
requerimientos del usuario, además se crean prototipos para corregir errores o
implementar mejoras.
Pruebas: Al finalizar la implementación se recogen todas las piezas creadas y se
ensamblan para comprobar que funcionan correctamente, se realizan las
pruebas necesarias para encontrar errores de programación o errores de diseño.
Mantenimiento: Al finalizar el proyecto el usuario final puede requerir algunos
arreglos en su producto bien sea por causas de fábrica (errores de diseño o
programación), o por cambios externos (nuevos sistemas operativos, periféricos,
etc.).
El modelo en cascada ha sido criticado en diferentes aspectos ya que se le han
encontrado desventajas que han sido suplidas por otras metodologías del tipo ágil, por
ejemplo al ser una metodología lineal no permite que ningún cambio sea realizado
durante la marcha, es decir que si no se hace un excelente levantamiento de
29
requerimientos los resultados pueden ser catastróficos (Pressman, Ingenieria del
Software: Un enfoque Practico, 2005).
2. Modelo en Espiral
Ilustración 10: Flujo de trabajo del modelo en Espiral
En 1986 (Boehm, 1988) Barry Boehm propuso un proceso de desarrollo de software
conocido como el Modelo en Espiral, este modelo hace un énfasis en el análisis de
riesgos. Es importante mencionar que este modelo utiliza la creación de prototipos para
así evaluar riesgos. El modelo en espiral está definido en cuatro fases de desarrollo en
las cuales el proyecto avanza de manera iterativa de fase en fase:
Planificación: En esta fase se hace un levantamiento de requerimientos y se
evalúan los diferentes riesgos que pueda presentar el proyecto.
Análisis de Riesgos: En esta fase se identifican los riesgos y sus posibles
soluciones, además de crear un primer modelo en papel o un prototipo.
Ingeniería: En esta fase se empieza a crear el software o la aplicación, al
30
finalizar se hace una evaluación del producto creado.
Evaluación: En esta fase es donde el cliente evalúa el desarrollo del proyecto y
es quien determina si este está preparado para continuar a la siguiente espiral o
iteración.
El modelo en cascada requiere hacer un buen análisis de riesgos además de una
constante comunicación con el cliente para determinar el éxito del proyecto.
3. Proceso Unificado Racional (RUP)
Ilustración 11: Flujo de trabajo del RUP.
En 1995 una compañía llamada Rational Software Corporation, fundada por Grady
Booch, Ivar Jacobson y James Rumbaugh, desarrollaron un flujo de trabajo conocido
31
como Proceso Unificado Racional (RUP, por su nombre en inglés), el cual adoptó UML6
como lenguaje para el diseño (Bell, 2003).
Este proceso utiliza los casos de uso como herramienta para representar los requisitos
del sistema, el análisis y diseño, su implementación y las pruebas que se deben
realizar. Otra característica importante de RUP, es que es un proceso iterativo debido a
que el trabajo se segmenta en pequeños proyectos, permitiendo de esta manera un
incremento secuencial que genera un aumento en el producto.
Cada iteración salta por cada una de las fases del proceso, cabe aclarar que debe
existir una planificación de iteraciones, un análisis de riesgos y por último la integración
de los resultados de todas las iteraciones.
RUP, tiene cuatro fases de desarrollo, estas son (Kroll & Philippe, 2003):
Inicio: En esta fase se estudia el problema y se delimita el proyecto, para lograr
esto se debe identificar todos los riesgos que se pueden encontrar en la marcha,
además de definir los diferentes casos de uso y los recursos necesitados. Al
finalizar esta fase se tienen listos los objetivos del ciclo de vida del proyecto.
Elaboración: Esta fase es la más importante de las cuatro existentes, debido a
que es aquí en donde se crea el plan de desarrollo y se eliminan los elementos
6 Lenguaje Unificado de Modelado o UML, es un lenguaje gráfico que sirve para describir diferentes procesos
dentro de un sistema, está enfocado en lenguajes orientados a objetos, ya que utilizando los casos de uso puede brindar un panorama detallado del programa antes de entrar al código.
32
de riesgo más altos del proyecto; de esta manera se puede predecir el costo y el
tiempo necesario para completar el desarrollo. Al terminar algunas iteraciones es
posible tener un prototipo para verificar que no hay dificultades en el proyecto. Al
finalizar esta fase se obtiene el ciclo de vida de la arquitectura. El proyecto puede
ser abortado o replanteado si no supera esta fase.
Construcción: Esta fase es en donde se integran todos los componentes en un
solo producto, se deben manejar bien los recursos para optimizar costos, tiempo
y calidad. Al finalizar esta fase se decide si el producto está listo para ser
ejecutado por los usuarios sin exponer el proyecto a altos riesgos.
Transición: Esta es la fase en donde el proyecto es entregado a los usuarios,
generalmente aparecen problemas que deben ser solucionados en nuevas
versiones.
4. Ingeniería de Requisitos
Es el proceso de desarrollar una especificación de Software. Las especificaciones
pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del
sistema. De tal manera, La Ingeniería de Requisitos, se utiliza para definir todas las
actividades involucradas en el descubrimiento, documentación y mantenimiento de los
requerimientos para un producto (Ortas, 2001).
33
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de
requisitos. El cliente intenta replantear un sistema confuso, a nivel de descripción de
datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como
interrogador, como consultor, como persona que resuelve problemas y como
negociador.
El análisis y la especificación de requisitos pueden parecer una tarea relativamente
sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso.
Abundan las ocasiones para malas interpretaciones o falta de información. Es muy
probable que haya ambigüedad.
(Pressman, 2002) Plantea las siguientes tareas o etapas fundamentales en el análisis
de requerimientos:
Reconocimiento del problema: Se deben de estudiar inicialmente las
especificaciones del sistema y el plan del proyecto del software. Realmente
se necesita llegar a comprender el software dentro del contexto del sistema.
El analista debe establecer un canal adecuado de comunicación con el
equipo de trabajo involucrado en el proyecto. En esta etapa la función
primordial del analista en todo momento es reconocer los elementos del
problema tal y como los percibe el usuario.
Evaluación y síntesis: En esta etapa el analista debe centrarse en el flujo y
estructura de la información, definir las funciones del software, determinar los
34
factores que afectan el desarrollo de nuestro sistema, establecer las
características de la interfaz del sistema y descubrir las restricciones del
diseño. Todas las tareas anteriores conducen fácilmente a la determinación
del problema de forma sintetizada.
Modelización: Durante la evaluación y síntesis de la solución, se crean
modelos del sistema que servirán al analista para comprender mejor el
proceso funcional, operativo y de contenido de la información. El modelo
servirá de pilar para el diseño del software y como base para la creación de
una especificación del software.
Especificación: Las tareas asociadas con la especificación intenta
proporcionar una representación del software. Esto más adelante permitirá
llegar a determinar si se ha llegado a comprender el software, en los casos
que se lleguen a modelar se pueden dejar plasmados manuales.
Revisión: Una vez que se han descrito la información básica, se especifican los
criterios de validación que han de servir para demostrar que se ha llegado a un buen
entendimiento de la forma de implementar con éxito el software. La documentación del
análisis de requerimientos y manuales, permitirán una revisión por parte del cliente, la
cual posiblemente traerá consigo modificaciones en las funciones del sistema por lo que
deberán revisarse el plan de desarrollo y las estimaciones previstas inicialmente.
35
5. MANIFIESTO ÁGIL
La constante necesidad de consumo por parte de los usuarios ha transformado la forma
de desarrollar software, de esta manera los métodos tradicionales de desarrollo se
empezaron a volver obsoletos, pero ¿qué significa ser ágil?, Jim Highsmith dice que ser
ágil significa: “Entregar rápido. Cambiar rápido. Cambiar a menudo” (Highsmith, Agile
Project Management Advisory Service, 2000).
Los métodos agiles de desarrollo aprendieron de las ventajas y errores de sus
predecesores, modelos como el de Cascada o Espiral, presentaban problemas en el
momento en que se requería un cambio sustancial en el proyecto, generando así
retrasos o en algunos casos cancelación de los mismos, debido a que se tenía que
empezar desde cero nuevamente.
En el 2001 se reunieron los ponentes de los métodos agiles, quienes crearon el
“Manifiesto por el Desarrollo Ágil de Software”. El manifiesto dice lo siguiente (Agile
Manifesto, 2001):
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia
experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a
valorar:
Individuos e interacciones sobre procesos y herramientas.
Software funcionando sobre documentación extensiva.
36
Colaboración con el cliente sobre negociación contractual.
Respuesta ante el cambio sobre seguir un plan.
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la
izquierda.
Cockburn y Highsmith explicaban que: “Lo que es nuevo sobre los métodos agiles no
son las practicas que usan, sino el reconocimiento de la gente como el motor principal
para el éxito del proyecto” (Highsmith, 2001).
6. Scrum
Ilustración 12: Marco de trabajo de Scrum
En 1996 Ken Schwaber y Jeff Sutherland desarrollaron un marco de trabajo
denominado Scrum (Schwaber & Sutherland, 1991); el término fue tomado del Rugby,
37
ya que un Scrum ocurre cuando los jugadores de ambos equipos se amontonan juntos,
en un intento de avanzar por el campo.
Para llevar a cabo esta metodología se debe tener en cuenta el funcionamiento de la
misma, que consiste en una serie de iteraciones así:
Planificación: En esta reunión inicial se definen las diferentes iteraciones a realizar, los
requisitos más prioritarios para cada una de ellas, y se identifica la meta a la que se
quiere llegar. Durante esta reunión los miembros del equipo se asignan las tareas que
cada uno de ellos quiere realizar.
Reunión diaria del equipo: Durante la realización del proyecto, se planean reuniones
diarias que tienen una duración máxima de 15 minutos, en la cual cada miembro del
equipo dice: ¿Qué ha hecho?, ¿Qué va a hacer? y ¿Qué inconvenientes ha tenido?
esta reunión sirve para aumentar la productividad y el compromiso del equipo.
Iteración: Las iteraciones pueden ser cortas; máximo dos semanas, o largas; máximo
un mes. Cada iteración que haya sido planteada en la planificación debe proporcionar
un resultado que pueda ser verificable por el cliente, y que sea una aproximación del
resultado final del producto. Los equipos de trabajo deben garantizar el cumplimiento de
cada uno de los objetivos propuestos. Las iteraciones pueden darse por terminadas si
no se puede llevar a cabo por cambios en el proyecto.
Inspección y adaptación: Al terminar una iteración el equipo se reúne en una reunión,
en donde se hace una breve demostración con el cliente de la iteración que ha llegado
38
a su fin, y se hace una retrospectiva para mirar que problemas o fortalezas tuvo el
equipo de trabajo para lograr la meta, y de igual manera para encontrar métodos que
mejoren la efectividad del trabajo en grupo.
Scrum está basado en cinco principios que se deben tener en cuenta al desarrollar
software con ella, estos son:
Empirismo: Durante las iteraciones los equipos deben responder a
conocimientos nuevos, o condiciones cambiantes, de esta manera el
equipo está en una constante inspección y adaptación.
Aparición: La planificación está diseñada para maximizar la aparición de
nuevas características, ya que no se sabe que cambio puedan aparecer
en el desarrollo.
Cajas de tiempo: El tiempo es valioso en un proyecto desarrollado con
Scrum, ya que debe cumplirse estrictamente el cronograma de iteraciones
que este estipulado en el inicio de la planeación de este.
Priorizar: Al analizar los requerimientos del proyecto, se puede encontrar
que hay algunas características que son más importantes que otras, y son
esas a las que se le debe dar prioridad por encima de otras.
Auto-organización: Los equipos no mayores a siete miembros, se
organizan de forma autónoma, operan sus procesos y crean el mejor
producto posible manteniéndose dentro de las cajas de tiempo.
39
Al desarrollar software usando Scrum, lo más importante es el equipo y su distribución,
de esta manera este debe consistir en un Maestro del Scrum, un cliente y un equipo de
desarrolladores. A continuación se explicaran las funciones de cada miembro:
Maestro del Scrum: Esta persona se encarga de mantener al equipo
motivado, debe ayudar a resolver los problemas que se detecten, ayuda a
que haya comunicación entre los desarrolladores y los clientes.
Cliente: Este es el dueño del proyecto y se encarga de comunicar la
visión del producto a desarrollar y maximizar el retorno de inversión.
Equipo de desarrolladores: Es un equipo multidisciplinar de personas,
que determinarán cuánto trabajo pueden aceptar para empezar una
iteración y a su vez se compromete a entregarla a tiempo y funcional.
7. Programación Extrema (XP)
Ilustración 13: Marco de trabajo de XP
40
En 1998 (Highsmith, Agile Project Management Advisory Service, 2000), la compañía
norteamericana de autos, Chrysler, estaba diseñando un software para realizar los pagos de
sus aproximadamente 87.000 empleados, el diseño inicial fue un fiasco, así que la compañía
decidió contratar a Kent Beck, en ese momento se desechó todo lo que había anteriormente y
se empezó desde cero, adoptando una práctica fuera de lo común que se conocería después
como Programación Extrema. Esta práctica que resultó ser un éxito se popularizó en 1999,
siendo destacada en diferentes revistas, artículos y en el libro escrito por Kent Beck, Extreme
Programming Explained: Embrace Change (Beck, 1999).
Al trabajar usando XP se debe tener en cuenta que todo el equipo de trabajo debe estar
en el mismo lugar y según sus creadores se debe trabajar en parejas ya que “dos
cabezas piensan mejor que una”, otra virtud y a la misma vez se puede convertir en un
problema, es que al usar esta metodología no es necesario escribir tanta
documentación ya que todo lo que se deba comunicar se hace de manera oral.
La Programación Extrema tiene cinco valores (Wells, 2009) que se deben tener en
cuenta al desarrollar con ella, estos son:
Simplicidad: Un diseño simple toma menos tiempo de terminar que
uno complejo.
Comunicación: Todos los días el equipo se reúne, para comunicar
problemas y soluciones. Lo esencial en estas reuniones es que el
equipo haga una rendición de cuentas, en donde se estará al tanto de
41
que se logró ayer, que se lograra hoy, y qué problemas están
causando retrasos en el desarrollo.
Retroalimentación: Es importante hacer pruebas con el cliente, ya
que este es el que tiene la última palabra sobre la funcionalidad del
software. Esto se hace a manera de ciclos o iteraciones pequeñas que
finalmente son acopladas en un software totalmente funcional.
Valentía: Se necesita tener el coraje para triunfar y decirle no al
fracaso. No se tiene miedo, porque nadie trabaja solo. Si se tiene que
desechar algo porque no dio el resultado esperado, se desecha y se
empieza de nuevo.
Respeto: Cada persona del equipo es importante para el desarrollo,
todos deben respetarse y aceptar las críticas respetuosas de los
demás.
XP es una metodología ágil que como se ha explicado anteriormente es abierta al
cambio, pero el cambio en sí no es un problema, sino la habilidad del equipo a
acomodarse a este cambio, por esto XP te permite trabajar en pequeños intervalos en
los cuales el equipo desarrollador se puede dar cuenta de que está haciendo mal antes
de terminar el proyecto, y el cliente puede estar al tanto del contenido que se está
desarrollando. Kent Beck explica en su libro lo siguiente: “XP asume que tú quieres
crecer como persona, potencializar al máximo tus habilidades y mejorar tus relaciones
humanas (Beck, 1999)”.
42
Debemos tener en cuenta los roles que se pueden desempeñar en un equipo de XP
(Williams, 2007):
Manager: Es el encargado de formar el equipo de trabajo, de obtener
recursos y solucionar los problemas que aparezcan en el equipo.
Entrenador: Esta persona se encarga de entrenar a los miembros del
equipo en el uso adecuado de XP.
Rastreador: Se encarga de recopilar las historias de usuarios.
Programador: Se encarga de diseñar y codificar el desarrollo.
Ensayador: Se encarga de ayudar a los clientes y desarrollan
pruebas.
Cliente: Es aquel usuario final que da el visto bueno del trabajo.
8. Metodologías Cristal
Ilustración 14: Marco de trabajo Cristal.
43
El método Cristal es un conjunto de metodologías que se diferencian por sus
características como: el tamaño del equipo y la envergadura del proyecto. Alistair
Cockburn creo esta familia de métodos mientras trabajaba para IBM en 1991, él se dio
cuenta que “No existe una sola manera de hacer proyectos, por el contrario cada
proyecto es diferente y depende de varios factores (Cockburn, 2004)”.
Esta metodología utiliza un código de colores para así diferenciar una de otra; Cristal
Claro, Cristal Amarillo, Cristal Naranja, Cristal Azul, entre otras. En este caso se hablará
sobre Cristal Claro que es una metodología adaptable para equipos y proyectos
pequeños, entre dos y ocho personas máximo.
La ventaja de este método es que al ser un equipo de pocas personas, la comunicación
diaria es más sencilla y cada miembro puede saber cómo están avanzando los demás.
Además de que se realizan múltiples ciclos de entrega para ir analizando los avances;
entre sus fases podemos encontrar:
Preparación: Es aquí donde se construye el equipo de trabajo, y se
hace una exploración del problema y se crea el plan inicial del
proyecto. Esta fase puede tomar entre 1 o 4 semanas. La exploración
del problema es en donde se define el valor del proyecto, la tecnología
a usar, los requerimientos, el plan de trabajo y el equipo necesario para
llevarlo a cabo.
44
Ciclo de Entrega: En este ciclo se hace una re calibración del plan
inicial, ya que cada que se hace una entrega se va obteniendo
información valiosa que no se tuvo en cuenta en un principio. Es
importante que estas entregas se le hagan a un usuario final, para así
poder obtener la retroalimentación pertinente.
Iteración: Las iteraciones pueden variar dependiendo de la capacidad
del equipo, estas pueden durar entre una semana y dos meses.
Ciclo de Integración: Durante la integración se recopila todo lo que
este desarrollado y no tenga errores, para ir formando el producto final.
45
CAPITULO II: MODELOS BASADOS EN LA INTERACCIÓN HUMANO –
COMPUTADOR, LA USABILIDAD Y EL DISEÑO CENTRADO EN EL
USUARIO
1. Usabilidad e Interacción Humano Computador (HCI)
El HCI es una disciplina que tiene como objetivo desarrollar y mejorar la efectividad, la
utilidad y la eficiencia de sistemas computacionales y su relación con el entorno (Dix,
2003) para lograr estos objetivos propuestos por el HCI, es necesario primeramente
que los sistemas tengan un punto de encuentro efectivo entre persona y ordenador, es
decir un punto en el cual personas y sistemas transmitan mutuamente información,
datos y sensaciones, este punto de encuentro se llama Interfaz, como lo explica Laurel
B (Laurel, 1990)Una interfaz es una superficie de contacto que refleja las propiedades
físicas de los que interactúan. De esta manera la Interfaz se convierte en pieza clave en
el diseño de sistemas y aplicaciones porque aquello que no sea posible de expresar a
través de ella, permanecerá fuera de la relación mutua.
Por otra parte para que los sistemas interactivos cumplan su objetivo, deben ser
usables, así pues la usabilidad es el grado o medida en la que un producto puede ser
usado por determinadas personas para conseguir objetivos específicos en un contexto
de uso especificados (1998, Information Technology - Evaluation of Software Products -
General Guide. ISO)
46
Se expone aquí un punto clave en cual estos conceptos convergen para convertirse en
una parte fundamental del desarrollo de aplicaciones, siguiendo los objetivos del HCI,
debemos diseñar interfaces que no se conviertan en una barrera comunicativa sino que
permita que las aplicaciones sean fáciles de utilizar y aprender para que de esta
manera el usuario pueda realizar sus tareas y conseguir sus objetivos de manera
sencilla, es decir, interfaces que contenga funciones útiles y agradables, sistemas con
alto grado de usabilidad (Gloud & Lewis, 1985)
Las interfaces de sistemas construidos con criterios de usabilidad tienen una serie de
ventajas tales como la mejora de la productividad, la reducción del coste y del tiempo
de aprendizaje, y el incremento de la autonomía de los usuarios finales. (Lozano, 2002)
Diferentes autores han estudiado el beneficio que representa el estudio de las
interfaces de usuario y la usabilidad y han concluido que el éxito o fracaso de una
aplicación depende altamente de un buen manejo de la usabilidad en el diseño, por
ejemplo, Landauer explica, que el 80% de los costes de mantenimiento – lo que
representa el 80% del total de los costes del desarrollo de software – se deben a
problemas de los usuarios con el sistema y no a problemas técnicos. Además indica
que el 64% de estos costes están relacionados con problemas de usabilidad. Además,
varios estudios sobre el tema de la productividad en herramientas software concluyen
que la facilidad de uso y aprendizaje son unas de las razones más importantes a la hora
47
de incrementar de forma efectiva la productividad de los usuarios del software.
(Landauer, 1995)
Para lograr crear interfaces usables en las aplicaciones, se deben entender varios
conceptos:
a. La usabilidad de las interfaces puede ser medida de forma objetiva, mediante
diferentes componentes que demuestran su calidad. (Nielsen J. , Usability 101:
Introduction to Usability, 2012).
Facilidad de Aprendizaje: este punto da una medida de que tan fácil es para un
usuario llevar a cabo una tarea básica la primera vez que usa el sistema.
Eficiencia: Una vez el usuario ha aprendido el sistema, se debe medir cuánto
tarda en la realización de tareas diversas.
Recordación: este punto evalúa cuánto tarda un usuario que ha dejado de usar
el sistema por un tiempo, en recordar su funcionamiento, y cuánto tarda en
adquirir las bases necesarias para usarlo eficientemente de nuevo.
Eficacia: Durante la realización de una tarea, cuantos errores comete el usuario
y que tan grave son las consecuencias de estos errores
Satisfacción: Que tan agradable y sencillo es para el usuario la realización de
tareas
48
De estos puntos anteriormente descritos se desprenden otros principios generales que
se pueden aplicar a un sistema interactivo para evaluar su usabilidad (Dix, 2003)
Sintetizable. El usuario tiene que poder evaluar el efecto de operaciones
anteriores en el estado actual. Es decir, cuando una operación cambia algún
aspecto del estado anterior, es importante que el cambio sea captado por el
usuario.
Familiar. Los nuevos usuarios de un sistema poseen una amplia experiencia
interactiva con otros sistemas. Esta experiencia se obtiene mediante la
interacción en el mundo real y la interacción con otros sistemas informáticos. La
familiaridad de un sistema es la correlación que existe entre los conocimientos
que posee el usuario y los conocimientos requeridos para la interacción en un
sistema nuevo.
Consistencia. Este es un concepto clave en la usabilidad de un sistema
informático. Diremos que un sistema es consistente si todos los mecanismos que
se utiliza son siempre usados de la misma manera, siempre que se utilicen y sea
cual sea el momento en que se haga.
Flexibilidad. La flexibilidad se refiere a la multiplicidad de maneras en que el
usuario y el sistema intercambian información.
Recuperabilidad. Grado de facilidad que una aplicación permite al usuario para
corregir una acción una vez está reconocido un error.
49
Tiempo de respuesta. Se define generalmente como el tiempo que necesita el
sistema para expresar los cambios de estado del usuario. Es importante que los
tiempos de respuesta sean soportables para el usuario.
b. La usabilidad debe ser medida de manera subjetiva porque depende también de
contextos y factores psicológicos y sociales.
Las personas son seres enormemente complejos, un hecho que añade inevitablemente
un alto grado de incertidumbre tanto al diseño como a la evaluación de productos
interactivos (Dillon A. , 2001)
La diversidad de tipos de usuario y los diferentes espacios y momentos en que se usa
una aplicación, así como los factores cognitivos de las personas son items
determinantes para la usabilidad de sistemas, igualmente la usabilidad no debe ser
entendida como una cualidad universal, toda interface nace para satisfacer una
audiencia específica, por lo tanto un producto es usable si lo es para esta audiencia en
concreto, no para el resto de la población (Montero, 2009).
La motivación de una persona al usar una aplicación no es la usabilidad, es la utilidad,
es decir los usuarios buscan solamente un provecho o beneficio de dicha aplicación,
pero no por ello son conceptos aislados entre sí, por lo que siempre debemos analizar
50
la usabilidad con relación a la utilidad del producto. “la usabilidad representa el grado en
el que el usuario puede explotar la utilidad” (Dillon & Morris, 1999).
Los tres puntos citados anteriormente nos llevan a asumir que para diseñar con éxito
interfaces usables, es necesario mantener un total contacto y profundo conocimiento
del usuario final, porque será él quien determine la calidad del diseño, por tal razón, se
hace necesario incorporar en este proceso técnicas que ayuden a captar las exigencias
del usuario usando los criterios de usabilidad, con el fin de desarrollar interfaces
intuitivas y fáciles de usar que ayuden al usuario a sacar el máximo provecho de la
aplicación, a este forma de construir aplicaciones se la llama Diseño Centrado en el
Usuario (Lozano, 2002).
2. Ingeniería de la Usabilidad
La Ingeniería de la Usabilidad es una metodología que proporciona la manera de
proceder organizadamente, para poder conseguir usabilidad en el diseño de interfaces
de usuario durante el desarrollo de un producto interactivo. Se trata de una materia
multidisciplinar que tiene sus raíces en otras disciplinas básicas: sicología cognitiva,
sicología experimental, etnografía y ingeniería del software.
51
La Ingeniería del Software es una aproximación al desarrollo del software que engloba
la definición de requisitos de la aplicación, la definición de objetivos y el diseño/testeo.
Este proceso suele realizarse en ciclos iterativos hasta conseguir las metas marcadas.
La Ingeniería de la Usabilidad utiliza los componentes generales de la Ingeniería del
Software proporcionando un proceso para el diseño y desarrollo de sistemas
interactivos que sean usables.
Es preciso que se siga un ciclo de vida iterativo. En una fase previa se establecen unas
especificaciones de usabilidad que van a servir de patrón con el que comparar el nivel
de usabilidad del sistema. A continuación comienza un ciclo diseño-evaluación-rediseño
que finaliza cuando se alcanzan los niveles detallados en las especificaciones de
usabilidad.
Las técnicas que se exponen a continuación van a agruparse según su uso en dicho
ciclo:
Especificaciones: Análisis de usuarios, análisis de tareas y especificaciones de
usabilidad.
Diseño: Diseño de la interacción, prototipado y participación de usuarios.
Evaluación: Test de usabilidad y evaluación heurística.
52
Para cada técnica o concepto se va a explicar su motivación, el procedimiento que
siguen y las técnicas relacionadas, si corresponde.
a. Especificaciones: Al principio del proyecto se elaboran unas especificaciones
de usabilidad intentando que realmente reflejen el nivel de usabilidad del sistema
en los aspectos específicos que más interesen. Estas especificaciones dirigirán
el proceso iterativo de desarrollo, pero para crearlas será necesario identificar
previamente a los usuarios y las tareas que van a desarrollar con el sistema.
Esta parte está muy relacionada con la Ingeniería de Requisitos.
b. Análisis de Usuarios: Si se desea construir un sistema software usable, se
debe primero conocer a fondo a qué usuarios específicos está destinado, cuáles
son sus características (Hix & Hartson, 1993). Para conocer a los usuarios, las
tareas que desarrollan y cómo las llevan a cabo. Es importante conocer cómo
piensa el usuario para desarrollar un sistema que trabaja según ese esquema (y
no según el esquema mental del equipo de desarrollo).
El procedimiento que se realiza depende del sistema específico a desarrollar.
Algunos procedimientos que pueden llevarse a cabo son los siguientes:
Visitas de campo: Cuando se desarrolla software para una empresa u
organización es muy útil observar al usuario en su entorno de trabajo habitual,
53
más si cabe en el caso de que el usuario esté utilizando un sistema que será
reemplazado por el que se va a construir.
Cuestionarios: Sin ser tan útil como hablar a los usuarios en su entorno
habitual, la información acerca de los usuarios puede ser recogida mediante
cuestionarios.
Técnicas relacionadas: El análisis de usuarios puede proporcionar una
categorización de usuarios, la cual puede ser útil a la hora de obtener una
muestra de usuarios con los que realizar test de usabilidad.
c. Diseño: Una vez identificadas las tareas a las que el sistema va a dar soporte,
se puede empezar a diseñar la interacción del sistema, como una primera
aproximación que será evaluada y, eventualmente, mejorada en posteriores
iteraciones. En primer lugar se va describir el diseño de la interacción del sistema
y las técnicas de prototipado relacionadas con la usabilidad. A continuación se
van a describir dos principios de diseño que implican en distinto grado al usuario
en el diseño del sistema: el diseño centrado en el usuario y el diseño
participativo.
Diseño de la Interacción El diseño de la interacción se puede dividir en dos
etapas: Diseño del concepto del sistema y diseño de la parte visual de la
interacción. El diseño del concepto del sistema es la actividad más importante
del desarrollo de software, pues definirá de qué modo va a funcionar el sistema.
Es importante crear un concepto del sistema que pueda ser comprendido y
asimilado fácilmente por el usuario. Para ello se pueden usar metáforas (como la
metáfora del escritorio usada por algunos sistemas operativos) basadas en
54
conceptos familiares para el usuario, o bien imitar sistemas ya conocidos por el
usuario.
El diseño es una actividad creativa y no puede mecanizarse. De todos modos,
aunque no hay recetas de cómo crear un buen concepto del sistema, sí hay
principios generales que nos pueden guiar en dicha tarea, como intentar lograr
una consistencia en la interacción, intentar minimizar la posibilidad de error por
parte del usuario, no sobrecargar la memoria del usuario, ofrecer realimentación
al usuario sobre sus acciones, etc. En el trabajo de Constantine y Lockwood
(Constantine & Lockwood, 1999) se puede encontrar una gran cantidad de
consejos de diseño.
El concepto del sistema se materializa posteriormente al realizar el diseño de la
parte visual de la interacción (interfaz gráfica de usuario). Hay una serie de
normas pertenecientes al campo del diseño gráfico sobre cómo escoger los
colores, tipos de letra, la disposición de los elementos en una ventana, etc. Esta
parte suele realizarla un diseñador gráfico profesional.
Normalmente el diseño desemboca en la creación de un prototipo para ser
evaluado con usuarios.
Prototipado El prototipado no es una técnica exclusiva de la Ingeniería de
Usabilidad, pero es muy valiosa en las primeras fases del desarrollo para
representar el diseño de la interacción y evaluar su usabilidad.
55
No es posible conocer la opinión de los usuarios mostrándoles especificaciones
técnicas a un nivel abstracto. Los usuarios entenderán mucho mejor los
prototipos concretos del sistema.
Algunas técnicas de prototipado ayudan a representar la interacción con un
esfuerzo mínimo de implementación:
Borradores en papel: Al principio del proceso de diseño se pueden crear
prototipos sobre papel para mostrarlos al usuario. Normalmente son
representaciones de las ventanas de la aplicación. El diseñador actúa como
sistema, presentando al usuario el siguiente elemento cuando ocurre una
transición entre ventanas (Nielsen J. , 1993).
Técnica del Mago de Oz (Preece, y otros, 1994) Un experto humano actúa
como sistema, dando las respuestas a las peticiones del usuario. El usuario
interactúa normalmente con el terminal, pero en vez de haber un software detrás,
un desarrollador está frente a otro terminal conectado al primero a través de la
red, y va tecleando la supuesta respuesta del sistema. El usuario normalmente
no sabe acerca del “truco”, para conseguir la sensación de estar tratando con un
sistema real.
Escenarios, storyboards y viñetas: Un escenario describe una historia de
ficción de un usuario interactuando con el sistema en una situación concreta. Las
viñetas son representaciones que capturan la interacción que ocurre en un
escenario. Storyboards son secuencias de viñetas que se centran en las
principales acciones en una situación. Estas técnicas posibilitan que el equipo de
56
diseño piense acerca de lo apropiado del diseño actual a las necesidades del
usuario, favoreciendo un proceso de diseño más centrado en el usuario.
d. Evaluación: La evaluación de usabilidad permite conocer el nivel de usabilidad
que alcanza el prototipo actual del sistema, e identificar los fallos de usabilidad
existentes. La evaluación se realiza usualmente mediante test de usabilidad,
complementados con evaluaciones heurísticas.
Test de Usabilidad Los test de usabilidad son la práctica de usabilidad más
extendida. Consisten en presentar al usuario una serie de tareas a realizar, y
pedirle que las realice con el prototipo del sistema. Las acciones y comentarios
de usuario se recopilan para un análisis posterior.
Para conseguir unos test de usabilidad con resultados fiables, las condiciones
del test y del lugar donde éste se realiza deben ser lo más parecidas posibles al
entorno de uso previsto para el sistema.
Se basa en que no es posible conocer el nivel de usabilidad de un sistema si no
se prueba con usuarios reales. En primer lugar, es preciso decidir con qué
distintos grupos de usuarios se va a probar el sistema, y cuántos participantes de
cada grupo se van a obtener para realizar los test. A continuación, se deben
diseñar las tareas de test cuya realización se va a pedir a los participantes;
normalmente se sacan del resultado del análisis de tareas, intentado
enmarcarlas en un contexto de uso real. Hay que decidir también otros detalles,
como la posibilidad de pedir ayuda al evaluador, qué tipo de información se dará
a los participantes acerca del sistema antes de comenzar con el test en sí, o si
57
se dará la posibilidad al participante de acceder libremente al sistema para
obtener opiniones acerca de su impresión global. Otra variante consiste en
realizar cada test con dos usuarios para observar los comentarios que
intercambian. Es habitual pedir al participante que “piense en voz alta” mientras
intenta llevar a cabo las tareas; este procedimiento permite identificar partes del
sistema con un nivel pobre de usabilidad.
Cuando el test está preparado y los participantes han sido reunidos, los test se
llevan a cabo, opcionalmente grabados en audio o vídeo. Otra posibilidad es
registrar las acciones de los usuarios en un fichero del sistema para un análisis
posterior; una vez se han realizado todos los test, los datos recogidos son
analizados y los resultados se aplican en el siguiente ciclo de diseño.
Evaluación Heurística Un experto en usabilidad (o en HCI) puede realizar una
evaluación heurística del sistema para hacer algunas iteraciones de desarrollo
más cortas, y así ser capaces de realizar más iteraciones en el proceso de
desarrollo. El experto realizará una crítica basado en su experiencia de diseño de
la interacción, o en guías de diseño de usabilidad ampliamente aceptadas.
Los expertos proporcionan una información distinta a la obtenida de usuarios
finales mediante test de usabilidad. Las sugerencias de modificaciones por parte
de un experto suelen tener más valor que las realizadas por usuarios, por ser
más viables y más precisas acerca de los problemas subyacentes de usabilidad
(falta de consistencia, navegabilidad pobre, etc.) Por otra parte, para identificar
58
problemas de usabilidad específicos es preciso realizar test de usabilidad con
usuarios reales. La evaluación heurística no debe usarse en vez de los test de
usabilidad, sino como complemento a los mismos.
Los expertos identifican ciertos problemas de usabilidad que requerirían un gran
número de test de usabilidad para ser correctamente identificados y
solucionados. Se explica al experto el modo de funcionamiento del sistema, y se
le entrena en las funciones principales. Se le informa acerca del dominio de
aplicación y el experto revisa el sistema según la conformidad del mismo a guías
de diseño. Una vez finalizada la revisión el experto elabora un informe con los
problemas identificados y sugerencias de diseños alternativos (opcionalmente),
el cual es entregado al equipo de desarrollo.
3. Diseño centrado en el usuario (DCU)
El diseño centrado en el usuario es un enfoque que busca lograr un producto con la
funcionalidad adecuada para usuarios concretos, por lo tanto, su diseño está dirigido
por las personas que van a usar el producto. El usuario debe ubicarse en el centro de
toda decisión de diseño, Aquí no solo diseñamos productos, diseñamos experiencias de
usuario, ya que no es posible entender un producto desvinculado de su uso, de su
contexto y necesidades y motivaciones de usuarios finales (Dillon & Morris, 1999)
59
El diálogo y la fácil comunicación de un sistema con el usuario es de vital importancia
en el desarrollo de aplicaciones, la interfaz debe permitir esta comunicación de forma
sencilla, por tal razón, como lo explica Thinbleby (Thimbleby, 1990) La interfaz
determinará en gran medida la percepción e impresión que el usuario tendrá de la
aplicación, las características de los usuarios pueden afectar el modo de trabajo y
condicionar el proceso de comunicación con el sistema.
Debido a esto, el conocer a profundidad el usuario, las actividades que realiza y un
profundo análisis del contexto donde desarrolla su trabajo, es determinante para un
buen diseño de sistema e interfaces. (JoAnn & Hackos, 1998)
Por lo tanto, cada producto y usuarios son únicos, así que, aplicar métodos sin seguir
líneas de trabajo perfectamente definidas y bien organizadas suelen llevar al fracaso,
para Nielsen (Nielsen J. , 1993) el modo más económico de aplicar con éxito criterios
de usabilidad es realizar un estudio previo que permita conocer a los usuarios desde
sus características, habilidades, escenarios de trabajo y tareas, esta metodología es
denominada Diseño Centrado en el Usuario (DCU)
El DCU, es la vía para alcanzar la usabilidad, es decir, la usabilidad representa el qué, y
el DCU representa el cómo, diseñar objetos usables es muy loable pero no implica
necesariamente que se hayan logrado usando el Diseño Centrado en el Usuario
(Cañada, 2003).
60
Shineiderman, (Shneiderman, Designing the user interface, 1998), plantea, que una de
las bases para alcanzar altas cuotas de calidad es utilizar métodos de diseño iterativo
que permita realizar pruebas tempranas de prototipos, revisiones basadas en la
retroalimentación de las observaciones y reacciones de los usuarios y los refinamientos
sucesivos posteriores. Este concepto define una metodología que proporciona una
manera de proceder organizada e iterativa para poder conseguir la usabilidad en el
diseño de una interfaz, teniendo en cuenta la experiencia al usuario.
Aplicar el DCU para el diseño de sistemas, no solo busca productividad, eficiencia y
satisfacción al usarlo, sino que también es una apuesta al éxito del producto, porque
cuando una aplicación no es percibida como una herramienta útil para el usuario y las
tareas que se busca resolver no son respaldadas de manera sencilla por el sistema, es
muy seguro que esta aplicación no llegue a usarse en lo absoluto. También, una buena
aplicación de Diseño Centrado en el Usuario ayudará a detectar errores graves antes
de la implementación, haciendo más fácil y económico de corregirse. Por otra parte hay
que tener en cuenta los elevados costes de servicio de atención al usuario que pueden
derivarse de un sistema con problemas de usabilidad (Cushman, 1991).
Existen varios estudios basados en el DCU en los cuales sus autores han profundizado
y aplicado los conceptos del Diseño Centrado en el Usuario, tal es el caso de MPIU+A
desarrollado por Toni Granollers, presenta un modelo propio de DCU en el cual, como
61
su propio nombre indica, no sólo aplica y tiene en cuenta la usabilidad en su
metodología, sino que también se ha integrado el concepto de accesibilidad en él, su
proceso incluye el análisis detallado en cuanto a requisitos, diseño, Implementación y
Lanzamiento de los productos o sistemas interactivos en general. En el año 2010
Araceli Moré Martín presenta un modelo denominado MPUI+A Agil en el cual explica
un esquema de una única metodología que integra las metodologías ágiles y el modelo
presentado por Granollers, encontramos también el Design Thinking, conceptualizado y
masificado por Tim Brown (Brown, 2008) en el cual explica que el Design Thinking es
un proceso creativo en torno a la construcción de ideas, donde al no haber juicios se
elimina el miedo al fracaso, y se alienta con ello la máxima entrada y participación en
las fases de ideación y prototipo. Cuando se habla de Design thinking no se habla de
diseño entendido como el diseño del producto. Se trata de la aplicación de una materia
que tiene que ver con entender la conducta humana respecto del producto, en este
sentido, toma gran relevancia la forma en que se estudia a los usuarios.
62
CAPITULO III: MODELOS PARA EL DESARROLLO DE VIDEOJUEGOS
1. Game Object Model II (GOM II)
Ilustración 15: Espacios de trabajo del Game Object Model
Este modelo de desarrollo diseñado por Alan Amory en 2006, utiliza el paradigma de la
programación orientada a objetos para su planteamiento. Este modelo fue creado para
diseñar videojuegos educativos, y está dividido en diferentes espacios que se
explicaran a continuación:
Espacio de juego: En este espacio se define todo lo referente a la
mecánica de juego (objetivos, logros, género, narrativa, autenticidad).
63
Espacio de visualización: En este espacio se hace todo el desarrollo
cognitivo de las interfaces, menús y mensajes que le sirvan al usuario.
Espacio de elementos: En este espacio es donde se hacen todos los
elementos del videojuego (sonidos, gráficos, historia, trama).
Espacio de actores: En este espacio se define la interacción y los
roles de los personajes.
Espacio de problemas: Este es el espacio más importante del
modelo, ya que aquí es donde se definen los problemas educativos
que solucionara el videojuego y como lo hará.
Espacio social: Es en este espacio en donde se crean las
características sociales que puede tener el videojuego.
El autor explica que “Una manera simple de usar este modelo es crear una lista de
chequeo de todos los criterios necesarios para el desarrollo del videojuego y evaluar
esta lista frente a las especificaciones de diseño del juego (Amory, 2006)”.
2. Game Unified Process (GUP)
Este proceso de desarrollo fue creado por Kevin Flood (Flood, 2003), y surgió a raíz de
la creación de un videojuego de casino en línea, esta metodología combinó RUP con
XP, brindándole a esta una comunicación constante entre los equipos de desarrollo.
Simplicidad, agilidad e independencia son tres principios en los que se basa GUP.
64
GUP está dividido en cuatro fases igual que RUP, estas son:
Inicio: En esta fase se definen los objetivos, alcance del proyecto y
requisitos técnicos. Igual que en RUP esto permite extraer una lista de casos
de uso y de factores de riesgo del proyecto.
Elaboración: En esta fase se desarrolla el primer prototipo de la aplicación y
se complementa el análisis de los casos de uso.
Construcción: Esta fase se desarrolla por medio de iteraciones en donde se
van desarrollando los casos de uso propuestos en principio. Al ser una fase
iterativa se van generando versiones del proyecto funcionales.
Transición: Esta fase sirve como un intervalo entre la construcción y la
producción del proyecto.
3. Huddle
Ilustración 16: Las tres fases de Huddle.
65
Huddle recibe su nombre debido a la analogia con SCRUM, en donde “se llama Huddle
a la reunión que se realiza en el juego antes de cada jugada en el fútbol americano
(Morales, Nava, Fernández, & Mirsha, 2010)” es un proceso de desarrollo ágil enfocado
para grupos de 5 a 10 personas, el cual está dividido en 3 fases:
Preproducción: En esta fase se hace toda la planeación del proyecto, se
empieza con una idea y de esta se desarrolla un documento de diseño que
tiene como objetivo detallar la propuesta. Es indispensable que todos los
miembros del equipo participen en esta fase. Cuando el documento de
diseño sea aprobado se debe crear el feature log y el sprint plan; el primero
es donde se detallan todas las características del videojuego y el segundo es
donde se definen las diferentes iteraciones que tendrá el videojuego y los
tiempos de las mismas.
Producción: En esta fase Huddle se apoya de varias herramientas de
Scrum, de esta manera se realizan las diferentes iteraciones que deban
hacerse, después de cada iteración se procede a ejecutar una prueba alfa,
con la cual se verifica si la iteración ha sido completada o debe corregirse. Al
finalizar todas las iteraciones se continúa hacia las pruebas betas, que son
realizadas por personas ajenas al equipo de desarrolladores. Cuando las
pruebas beta no arrojan más errores se obtiene un producto final y se debe
pasar a la siguiente fase.
66
Postmortem: En esta fase se genera un reporte en el cual se especifican las
actividades que se llevaron a cabo durante todo el proyecto, además se
deben tener en cuenta los aspectos negativos y positivos para no cometer
los mismos errores o seguir trabajando de esa manera en próximos
proyectos.
CAPITULO IV: DCU en Videojuegos
En capítulos anteriores se ha explicado que, para lograr el éxito en el diseño de
sistemas interactivos, es de vital la importancia de realizar interfaces teniendo en
cuenta el usuario final y el contexto en que serán usadas dichas aplicaciones, hemos
conocido los planteamientos entregados por la Ingeniería de Requisitos, el Human
Computer Interaction (HCI) y el Diseño Centrado en el usuario (DCU), y vemos como
poseen muchas características entre sí, la más importante es que buscan como objetivo
mejorar la Experiencia del Usuario, también conocida como UX, podemos entender el
UX como el conjunto de sensaciones, sentimientos o emociones que se producen en el
usuario cuando maneja un sistema interactivo.
1. Experiencia del Jugador (PX) y Jugabilidad
Los videojuegos son un sistema interactivo “Especial” ya que su objetivo es más
subjetivo: Entretener, divertir hacer sentir bien a jugador de tal manera que disfrute
usando la aplicación, a este tipo de experiencias la llamamos Experiencia del Jugador
(PX).
67
La Experiencia del Jugador, es decir la cantidad de satisfacción que una persona
siente al usar un videojuego es medida a través de la jugabilidad, esta describe la
calidad de juego en términos de sus reglas de funcionamiento y de su diseño. Se refiere
a todas las experiencias de un jugador durante su interacción con sistemas de juegos,
estas experiencias son mucho más amplias y específicas que las de un usuario de un
sistema interactivo tradicional, por lo tanto debemos analizar otros factores que son
vitales en el diseño de Videojuegos, como lo son la mecánica de juego, la historia, el
diseño de personajes, reglas, recreación de un mundo virtual, entre otros.
En el diseño de videojuegos va más allá, porque busca explotar al máximo la
experiencia del usuario ya que su principal objetivo es provocar distintas emociones y
asegurar su entretenimiento, esta naturaleza lúdica, es la hace que los videojuegos
sean diferentes de otros sistemas, los cuales están diseñados para realizar una tarea
concreta, mucho más funcional y objetiva con la necesidad de que el usuario pueda
realizar de forma eficaz, eficiente y satisfactoria.
Lazzaro (Lazzaro, 2008), ha planteado (en la Tabla1) las diferencias entre la Usabilidad
en aplicaciones de productividad y la jugabilidad en aplicaciones de entretenimiento.
68
Tabla 1: Objetivos en el diseño de la Experiencia de Usuario y la Experiencia de Jugador
Por otra parte Autores como Rouse (Rouse III, 2001) y Korhonen (Korhonen, 2006)
plantean principios de diseño en Videojuegos para alcanzar una mayor jugabilidad,
estos principios pueden ser comparados y complementados con los principios
explicados anteriormente por Nielsen (Nielsen, 1993) y Scheiderman (Shneiderman,
2000)Tabla 2.
Tabla 2: Software de Escritorio vs Software de Entretenimiento
69
Rollings en (Rollings & Adams, 2003) presenta la traída de la jugabilidad en cual se
explica como la jugabilidad es alcanzada cuando se diseña bien la base de un juego, es
decir, sus objetivos, reglas, retos y mecánicas, para ello identifico tres elementos claves
los cuales son: Core Mechanics, Storytelling & Narrative, Interactivity.
Ilustración 17: Triada de la Jugabilidad
Core Mechanics: es el corazón del juego, constituido por el conjunto de reglas
que definen y fijan el funcionamiento y comportamiento del juego.
Storytelling & Narrative: Todos los juegos tienen historia y la complejidad de
ésta depende de del tipo de juego, la narración de esta historia influye en la
jugabilidad, convirtiendo al jugador en elemento pasivo o activo en el juego.
Interactivity: Es el conjunto de elementos que el jugador puede ver, oir y con los
que interactúa dentro del juego, la interactividad le da el “sabor” al juego y es el
criterio para definir su clasificación.
70
En el año 2002, la universidad de Tampere y su laboratorio de investigación hipermedia
(Jarvien & Others, 2002) realizó un interesante trabajo, define la jugabilidad como el
conjunto de criterios a tener en cuenta para que la experiencia del jugador sea lo más
positiva posible para él. Y propone un modelo de Experiencia de Jugador basado en
cuatro componentes:
Jugabilidad Funcional: Esta jugabilidad se relaciona con los controles y los
mecanismos de navegación a lo largo del juego, así como su propia interfaz, va
ligada estrechamente a la usabilidad de sistemas interactivos tradicionales
Jugabilidad Estructural: Está relacionada con las mecánicas del juego, así
como con aspectos no estéticos, como el correcto uso de regla y objetivos que
ayudan al jugador a adquirir un mejor control sobre el juego.
Jugabilidad audiovisual: Son los aspectos relacionados con el arte visual y
sonoro que aparecen a lo largo del juego y la manera como estos afectan las
sensaciones y dan realismo al juego.
Jugabilidad Social: Conjunto de actividades sociales dentro del juego, estas
actividades pueden ser la interacción o la planificación con otros usuarios.
2. Experiencia de Jugador en Dispositivos Móviles
El nuevo salto tecnológico, la movilidad, la miniaturización y la integración de la
computación con la vida diaria ha provocado la introducción del ordenador en el mundo
del ocio y las relaciones sociales, hoy en día las personas que interactúan con
71
dispositivos móviles en toda su vida cotidiana quieren que estos dispositivos sean
objetos funcionales y además valiosos, este aspecto es importante, porque añade una
carga emocional adicional que se debe tener en cuenta en el diseño tanto externo del
dispositivo, como en el diseño y funcionalidad de sus aplicaciones e interfaces. Por otra
parte, el mercado y el uso de computadores ha variado de forma significativa, sus
dimisiones y facilidad de conexión inalámbrica permite usarlos en entornos muy
diversos, Bertini explica que la investigación en HCI debe crear nuevas interfaces
adaptables a los dispositivos, al entorno y a los usuarios. Como vemos el computador
se ha desvinculado de las actividades laborales y ha entrado a formar parte del ocio y
las relaciones sociales es por ello que la evaluación de la usabilidad en dispositivos
móviles no debe basarse tanto en la productividad si no el la reducción de la frustración.
La investigación realizada por Korhonen (Korhonen, 2006) fue realizada para Nokia
Research Lab (Nokia, 2010) y es referente importante sobre la usabilidad y la
experiencia de jugador en dispositivos móviles, estos estudios plantean que una buena
experiencia de jugador se obtiene mediante el equilibrio entre las capacidades del
dispositivo, el contexto de uso del terminal, la historia, el diseño visual, las mecánicas
del juego y el tipo de interacción adquirida durante el juego y definen la jugabilidad
como la representación de la experiencia del jugador ante un determinado juego, es
decir, el grado en que un juego es divertido de jugar y está directamente afectado por la
calidad de la narración , la historia del juego, la mecánicas, y el realismo del juego. Lo
que lleva a que se produzca una total inmersión en el juego.
72
A partir de estas premisas, Nokia ofrece una guía de estilo para el diseño de juegos
móviles y para la evaluación de su jugabilidad.
Ilustración 18: Guía de estilo y evaluación de videojuegos en móviles (Nokia, 2010)
Dentro del campo de los dispositivos móviles se destaca el trabajo de Korhonen
(Korhonen, 2006) en el cual se proponen unas heurísticas a realizar por expertos pero
teniendo en cuentas las diferencias entre los Videojuegos y las otras aplicaciones
interactivas tradicionales:
En video juegos, el objetivo es divertir y hacer disfrutar el proceso del juego.
Aprender como jugar, resolver problemas o descifrar las cosas es parte de la
experiencia del usuario en el juego.
En un video juego los jugadores no deben estar pendientes del resultado en
tiempo de uso del propio juego.
73
Los diseñadores de video juegos deben realizar contenidos, objetivos que el
jugador debe alcanzar ante el reto propuesto.
Korhonen propone heurísticas basadas en los siguientes tres elementos
Ilustración 19: Elementos heurísticos propuestos por (Korhonen, 2006)
Usabilidad: Las heurísticas de usabilidad del juego analizan el control y la
interfaz con la que el usuario interactúa con el juego.
Movilidad: Las heurísticas sobre movilidad analizan como afectan al usuario el
contexto cambiante del dispositivo móvil.
Gameplay: la dinámica de las acciones que ocurren cuando un jugador juega y
se manifiesta cunado el usuario interactúa con las mecánicas del juego.
74
CAPITULO VI: RACED, MODELO CENTRADO EN EL USUARIO PARA
EL DESARROLLO AGIL DE VIDEOJUEGOS CASUALES EN
DISPOSITIVOS MÓVILES
Al diseñar video juegos teniendo en cuenta al usuario como objetivo principal, se
deberá obtener un producto que satisfará los gustos de esté. En consecuencia, el
equipo de trabajo deberá desarrollarlo de manera ágil e iterativa para culminar de
manera eficiente y efectiva el videojuego, todo lo anterior permite la reducción de los
costos de producción y de soporte.
Esta investigación plantea el siguiente modelo centrado en el usuario para el desarrollo
ágil de videojuegos casuales en dispositivos móviles al cual hemos llamado RACED.
Este modelo cuenta con 4 fases de nominadas respectivamente, Conceptualización,
Diseño, Implementación y Testeo, dichas fases contienen cada una pasos iterativos y
en las cuales se tiene en cuenta al usuario desde el principio del desarrollo.
Para su realización se ha tenido en cuenta todas las premisas del Diseño Centrado en
el Usuario pero principalmente aquellas planteadas por (Granollers, 2004) en su modelo
de ingeniería de usabilidad, pero entendiendo que los videojuegos son desarrollos
particulares, porque buscan explotar al máximo las emociones de sus jugadores y por
75
ello la experiencia del jugador se convierte en medida fundamental de satisfacción, se
tuvieron en cuenta factores de aceptación en las mecánicas de juego, personajes, y la
historia.
Por otra parte se unieron procesos propios de las metodologías agiles, especialmente
SCRUM y XP, por tal razón se debe tener muy en cuenta para la asignación de tareas
los grupos de trabajo, para este modelo se sugiere que el grupo este conformado por
un líder del proyecto, un equipo de diseño, que son los encargados de toda la parte
artística del videojuego y un equipo de desarrollo, que son los encargados de la
programación y ensamble del mismo y cada uno con su correspondiente líder. Hemos
tenido en cuenta los tiempos que plantea la metodología ágil XP, en la cual cada
iteración dura 4 semanas e incluye: planificación, análisis de requisitos, diseño,
codificación, revisión y documentación, por esta razón para el modelo que presentamos
sugerimos una duración de 3 días en cada tarea dentro de cada una de las fases
76
Ilustración 20: Esquema de trabajo de RACED
77
Fase 1: Conceptualización
Como su nombre lo indica esta fase sirve como base para el desarrollo del proyecto,
debido a que es aquí en donde se conceptualiza la idea a desarrollar. Es de vital
importancia aclarar que previo al desarrollo de esta fase, debe existir una idea básica
del videojuego a crear; con esto listo se han definido dos etapas claves: análisis de
requisitos del juego y análisis de usuarios.
1. Análisis de requisitos del video juego
En esta actividad se deben tener en cuenta los diferentes requisitos necesarios
para la elaboración del videojuego. Entre estos requisitos se recomiendan los
siguientes:
Al crear un videojuego se debe tener claro el objetivo del juego ya que de allí se
pueden definir las otras características del mismo. Teniendo en cuenta que este
modelo está orientado para la creación de videojuegos casuales el objetivo debe
ser lo más concreto y fácil de entender posible.
Se debe definir la motivación del juego, es decir que hace que el videojuego a
desarrollar sea entretenido y que motivará a que los jugadores utilicen el juego
en cualquier momento.
Las características del juego son los diferentes elementos que se deben tener en
cuenta al diseñar el videojuego como: opciones, modos de juego, niveles,
78
objetos, personajes, enemigos, cámaras, inteligencia artificial, cinemáticas,
efectos de sonido y música, entre otros; se debe detallar cada una de estas
características muy bien debido a que esto servirá de base para las etapas de
diseño, musicalización y programación en la fase de implementación.
Teniendo en cuenta las características del juego, se podrán definir las mecánicas
de juego, estas son las diferentes interacciones que el usuario puede hacer
dentro del juego, se debe ser muy cuidadoso al definir estas mecánicas de juego
para no tener errores que puedan retrasar las fases posteriores.
Un punto importante a considerar son las características de hardware o
tecnología con las cuales se desarrollará el videojuego, para evitar limitantes
tecnológicas no contempladas.
2. Análisis del usuario
En esta segunda actividad se debe tener en cuenta al usuario, para esto es
necesario hacer un análisis de las diferentes características que debe tener el
público objetivo que usara el juego. Se debe considerar que el modelo que se
plantea es para el desarrollo de videojuegos casuales en dispositivos móviles,
por esta razón el jugador puede ser cualquier persona que tenga acceso a
alguno, pero siempre es importante hacer una sectorización del mercado
objetivo. Es importante recalcar que este análisis es importante hacerlo desde el
punto de vista de los modelos del DCU pero tratando de no ser tan específico
como lo indican las metodologías agiles, esto con el fin de no abordar detalles
79
que pueden ser innecesarios. Se recomienda tener en cuenta los siguientes
requisitos en el momento de analizar al usuario:
Las características generales del usuario o público objetivo como: sexo, edad,
habilidades, necesidades de entretenimiento y aspectos culturales que puedan
motivar o desmotivar el uso del juego.
Se debe plantear de manera clara el modelo de negocio que se va a utilizar para
el videojuego debido a que esto puede determinar también características
adicionales del jugador, para este planteamiento se sugiere seguir los modelos
de negocios actuales en la industria de video juegos para dispositivos móviles,
estos son: gratuitos, gratuitos con publicidad, gratuitos con contenido Premium7,
o pagar por jugar.
3. Evaluación de fase
Después de realizar las dos actividades anteriores es necesario hacer una
evaluación de fase, se recomienda usar una técnica conocida como encuesta
con el fin de establecer perfiles de usuarios. En esta evaluación es indispensable
incluir características generales del videojuego y debe realizarse teniendo en
cuenta el público objetivo que se definió en la etapa de análisis de usuario.
7 Contenido Premium: Es aquel contenido que el usuario tiene la posibilidad de comprar con dinero por medio de una tarjeta de crédito para adquirir mejoras en el video juego.
80
4. Análisis de resultados
Después de hacer una evaluación es importante hacer un análisis de resultados
con el cual se analizará si es posible pasar a la siguiente etapa o si se deben
hacer correcciones antes de continuar, en caso de que se encuentren
deficiencias en el análisis será necesario re plantear los requisitos del juego y el
público objetivo.
5. Asignación de tareas
Una vez se ha dado el visto bueno al análisis de resultados se procederá a
realizar una asignación de tareas para las dos fases siguientes. Esta asignación
de tareas consiste en definir las diferentes iteraciones que se implementaran en
el desarrollo del videojuego. Esta asignación de tareas se recomiendo hacerla de
la siguiente manera:
Se debe organizar cada tarea dependiendo de su prioridad esto es importante
para saber qué problemas se deben abordar primero para evitar inconvenientes
más adelante; se recomienda usar dos técnicas de Scrum llamadas: product
backlog o lista de objetivos priorizada y feature board o tabla de funciones, la
cual facilita el trabajo multidisciplinar que existe en un equipo de trabajo que
desarrolla videojuegos.
Al finalizar la fase de conceptualización se obtendrá como resultado un documento de
diseño en el cual se especificarán los requisitos del video juego y el público objetivo, y
una lista de objetivos a cumplir en las siguientes fases.
81
Fase 2: Diseño
Como se ha explicado anteriormente, la fase anterior, entrega al equipo de diseño las
características completas del videojuego, estas especificaciones darán las
herramientas necesarias para elaborar el prototipo en papel, además el paso o iteración
llamada “asignación de tareas” de la fase anterior (que es un paso propio de las
metodologías agiles) provee de forma explícita aquellos requisitos indispensables que
se deben tener en cuenta para la conceptualización del diseño del videojuego y que son
la base, no solo de las mecánicas de juego, sino también de la interactividad y la
comunicación entre la interfaz y el usuario.
Esta segunda fase denominada Diseño, está ubicada en la parte central del modelo que
se propone, por tal razón, es una fase fundamental y en la cual el equipo de trabajo
debe prestar mucho cuidado, porque es el punto que conecta la fase de
conceptualización con la fase de implementación, como lo veremos más adelante, de
esta manera, al concluir con éxito cada iteración de esta fase, se podrá asegurar en
gran medida un producto final que cumple con los beneficios que entrega el modelo. La
fase de Diseño es realizada de manera paralela por dos equipos, el equipo de diseño
gráfico y el equipo de desarrollo.
82
1. Fase 2 desde la perspectiva del equipo de Diseño Gráfico:
En esta fase, el equipo de diseño gráfico realiza tres iteraciones denominadas en su
orden así: sketch, prototipo de fase y evaluación de fase; el objetivo es que el juego
desarrollado tenga unos diseños que responden a las exigencias y características
de usuario, no sobra resaltar que el paso a la siguiente fase del modelo, depende
exclusivamente de una evaluación que brinde resultados positivos; A continuación
se explicara cada iteración:
a) Sketch: En esta iteración el equipo de diseño gráfico realiza los bocetos en
papel de todos los personajes principales y secundarios que tendrá el juego,
además, realizara los bocetos de los elementos con los que interactúa el
personaje como armas, objetos, premios, también los escenarios y niveles en
los que se mueve el personaje y sus obstáculos, y el diseño del menú e interfaz
del videojuego desde luego todas estas condiciones dependen de las mecánicas
de juego y la asignación de tareas entregadas en la primera fase.
b) Prototipo de fase: los prototipos son documentos, diseños o sistemas sencillos
que tienen incorporadas partes del sistemas que se quiere implementar, se usan
básicamente para hacer simulaciones del funcionamiento, para evaluar la
fiabilidad técnica y para determinar la precisión de la aplicación.
83
Así pues, teniendo listos los personajes, el equipo de diseño, integrara estas
piezas con un prototipo en papel de la interfaz del juego, estos bocetos de la
interfaz servirán para determinar la ubicación de los elementos con los cuales el
jugador interactúa, como botones, puntajes, ventanas de ayuda, entre otros, y se
realizaran pensando en el tipo de evaluación en el cual se pondrá a prueba.
Cabe recalcar que en diferentes documentos consultados referente a los
prototipos en papel, los autores consideran que no se debe entrar en detalles
estéticos al dibujar el prototipo, sin embargo en esta investigación se propone
que estos pueden ser realizados a consideración de los artistas es decir, con
colores, incluso con algunas ideas estéticas y de diseño que tenga el equipo,
porque de esta manera se puede evaluar no solo la funcionalidad sino también
las metáforas graficas que hayan sido pensadas para la aplicación.
c) Evaluación de fase: La evaluación es la parte más importante del proceso de
diseño centrado al usuario, porque es el momento donde involucramos al usuario
logrando conocer sus necesidades, limitaciones y el comportamiento frente al
prototipo que hemos realizados, aquí se debe realizar mínimo dos técnicas de
evaluación que arrojaran resultados suficientes para determinar el camino que
debe llevar el diseño de la interfaz del videojuego, se recomiendan usar las
siguientes técnicas por la facilidad de evaluar resultados y su bajo costo: test de
usuarios, evaluación heurística y/o focus group.
84
2. Fase 2 desde la perspectiva del equipo de Desarrollo:
Este equipo deberá trabajar en el diseño del juego, pero abordado desde la
ingeniería de software, de tal manera que se pueda establecer los elementos
básicos y funcionales para desarrollar una arquitectura adecuada y asi tener un
buen soporte, se lograra un juego muy bien estructurado en su código. Los
beneficios de trabajar en forma iterativa en este punto es que se tendrá unos
buenos patrones de datos, diseño modular, código limpio, y todo esto facilitara la
actualización mejoras y además, la reutilización de componentes para el futuros
videojuegos. Todo esto se hará teniendo en cuenta los retos de interacción
puestos por la “asignación de tareas” en la Fase 1 y la especificación de la
plataforma y software a usar.
Debemos recordar que en este punto solo se diseñara y se planificara la
estructura del videojuego no se hará desarrollo, para lograr dicho objetivo, se ha
integrado nuestro método con las iteraciones propias de la Metodología Ágil XP,
que en su orden son: Análisis de la Interactividad, Tarjetas CRC, Soluciones
Puntuales, Evaluación de Funcionalidad, Reciclaje. Y se explican a continuación:
Análisis de la interactividad: Una de las partes más importantes que entrega
La Fase 1 es la “asignación de tareas” como ya lo sabemos, este documento
describe el tipo de interactividad entre el usuario y el juego, además de aquellas
mecánicas y características de los personajes que fortalecerán la relación
usuario-juego y que posteriormente será el valor diferenciador de cada juego.
Por ejemplo: el uso del giroscopio parta ciertas acciones del juego, el uso de
85
ciertos gestos táctiles para algunas opciones del juego, capacidad de juego en
línea, uso de cámara integrada, tipos de movimientos y físicas de los
personajes,, colisiones, entre otras, El equipo de desarrollo deberá entender
estos elementos y pensar en las soluciones para su implementación.
Tarjetas CRC: Esta iteración es propia del método ágil XP, aquí teniendo en
cuenta el análisis de interactividad se realiza un cuadro o tarjetas para organizar
los requisitos del juego y establecer un orden en su arquitectura y estableciendo
quien será el responsable y cuál será la posible solución en el desarrollo.
Soluciones puntuales: En este punto el equipo de desarrollo ya tiene claro los
retos en implementación que propone el juego, de tal manera que realizaran
soluciones puntuales a cada uno de los requerimientos especificados en la
iteración anterior, se tratara de un pequeño programa muy simple, que facilita a
los programadores la tarea de exploración de un determinado problema o
necesidad que deben valorar, sin tener la necesidad de realizar una gran
implementación o una estimación totalmente errónea basada en criterios
abstractos.
Evaluación de Funcionalidad: Por último, el líder del equipo de desarrollo
evalúa y establece si la solución puntual propuesta en la iteración anterior
responde de manera funcional a la exigencia que plantea la “Asignación de
tareas”.
86
Reutilización: Una parte importante corresponde a la reutilización de código. Es
por ello que el reciclaje o reutilización, implicara mantener un código limpio y fácil
de comprender, modificar y/o ampliar. Para lograr una buen reciclaje, los equipos
de desarrollo pueden establecer pautas comunes de codificación, uso de
patrones, refactorización, etc. Técnicas que les permitan un mejor del código
generado y en consecuencia puedan hacer un mejor uso de éste.
3. Documentación de Fase:
Al final de toda la fase se obtendrá un documento de fase, el cual explica las
eventualidades importantes que surgen a lo largo del desarrollo de la misma
entregando también algún tipo de sugerencia o cambio que resulto de la etapa de
evaluación, este documento será de vital importancia para comenzar la siguiente
fase y generar esa sinergia entre cada una de estas.
Fase 3: Implementación
En esta fase ya están completamente claros los objetivos de usabilidad, al igual que las
metáforas de diseño que se van a usar, la Fase anterior nos ha suministrado prototipos
evaluados y que responden a las exigencias planteadas para el juego y a su vez el
equipo de desarrollo tiene control total respecto a la arquitectura y a la estructura de
código en el juego, y se sabe de cómo resolver los retos de interactividad que propone
las mecánicas de juego, así pues, que están las condiciones dadas para comenzar los
diseños finales y el desarrollo de la aplicación, esta fase cuenta con las siguientes
87
iteraciones: la primera iteración integra los diseños gráficos finales, la programación y la
musicalización, esto llevará a una iteración que se encarga de realizar una Prototipo
Funcional, posterior a esto tenemos la iteración denominada Evaluación y por último la
Documentación de Fase. A continuación explicaremos cada iteración:
Diseños Gráficos Finales:
El equipo creativo realiza la creación artística de los personajes (posturas, ropas,
modelado 3D si es el caso, rigging8, animaciones entre otros) y entornos
(Elementos destacados, armas, espacios) con la calidad final, y estos artes
contará con los aportes y retroalimentación del equipo de trabajo y con el director
creativo para mejorar sus características y apuntar a alcanzar con éxito las
exigencias planteadas en las fases anteriores.
Musicalización:
La musicalización nutre a los videojuegos de características que favorecen a la
inmersión del jugador en las situaciones de juego, la musicalización en los
videojuegos de consola resulta ser adaptativa porque se convierte en parte de la
narración, e informativa porque cambia dinámicamente según las acciones y
circunstancias del juego. La musicalización en videojuegos de consola ha
avanzado muchísimo a tal punto que la frontera entre música para cine y para
Juegos parece ser muy difusa. Caso contrario sucede en el caso particular de los
videojuegos para dispositivo móvil y más aún si hablamos de juegos casuales,
en los cuales la musicalización es sencilla o carece de importancia, la razón es,
8 Es el proceso técnico/artístico de configurar un personaje, modelo 3D, propiedad, objeto para que pueda ser posteriormente animado (Arzuza, 2011).
88
básicamente que resulta molesto, incomodo o inútil hacer uso de la música, por
la variedad de espacios y momentos en los cuales se juega, es decir, si el
usuario se encuentra en la iglesia, el hospital, una reunión o un salón de clases,
no desea que se sepa que está jugando, por otra parte si el jugador se encuentra
en un medio externo como una calle, un paradero de bus, o en el centro
comercial, es muy probable que no escuchara la intensión musical del juego. Es
por esta razón que en esta investigación recomendamos que el equipo de
musicalización no se centre en la creación de pistas musicales o secuencias
para acompañar el juego, mejor, deben prestar atención y enfocarse en la
creación de los sonidos que acompañan las acciones, es decir, pasos, golpes
colisiones. Saltos chillidos, etc, teniendo en cuenta las “asignación de tareas” y
lograr sonidos creativos y reales buscando generar conexión entre usuario y
personaje.
Programación:
En esta fase el equipo de desarrollo realiza toda la programación del juego
teniendo en cuenta la arquitectura y los estándares que se han marcado todo se
representara en el Prototipo Funcional.
Prototipo Funcional:
Esta iteración es la integración de los diseños finales la musicalización todo
unido bajo una estructura de programación limpia y modular, es una versión que
debe satisfacer todos los requisitos, y su funcionalidad deberá ser probada el
terminar el diseño, es decir , se debe verificar que cada y una de las tareas e
89
interacciones funciona y proporciona los resultados esperados en cada nivel,
esta verificación y control se realiza por por el mismo equipo de desarrollo, para
así, tener un juego lo más estable posible antes de ser entregada a la
evaluación.
Evaluación de fase:
El proceso de evaluación es el mismo que ya conocemos de fases anteriores con
la diferencia que el usuario y los expertos pondrán a prueba un producto
completamente funcional y con todas las características implementadas, en este
punto se debe estudiar muy bien los resultados de la evaluación y determinarlos
por prioridades e importancia ya que llegado a este punto es más difícil realizar
aquellos ajustes que no justifiquen su realización con razones sólidas. Se debe
dar mayor importancia a aquellas que atenten con la jugabilidad del producto. Es
muy probable que esta fase resulte más larga debido a la detallada evaluación
que se debe hacer por lo tanto deberá iterar completamente la fase un par de
veces de tal forma que se convierta el prototipo funcional en una Versión Alfa o
Versión Beta antes de llegar a la última Fase.
FASE 4: Control de Calidad
Después de recibir el resultado de la evaluación de la fase anterior y de tener un
prototipo funcional, es el momento de hacer un debugging9 del videojuego, para esto es
importante contar con expertos que se dedicaran a jugar el video juego por unas
9 Debugging: proceso en el cual se identifican y corrigen errores de software.
90
cuantas horas, días o semanas con el propósito de encontrar aquellos bugs10 y/o
glitches11 que contenga el mismo. Existen diferentes técnicas para hacer este control de
calidad, se recomienda usar una llamada functional game testing o pruebas de juego
funcional.
Después de identificar un error el equipo de control de calidad deberá entregar un
reporte al equipo de desarrollo quien a su vez verificara si el error es muy grave o
puede pasarse por alto, en caso de ser corregido se devolverá al departamento de
control de calidad para probar de que no exista más el error. Este proceso se debe
hacer de manera iterativa cuantas veces sea necesario hasta asegurar que el
videojuego que se entregara sea un producto de buena calidad.
Al finalizar esta fase se procederá con la entrega final del video juego para su
comercialización, es importante que el equipo realice un documento a manera de
reporte para saber que salió bien y mal durante el desarrollo general del videojuego,
esto servirá para no cometer los mismos errores en futuros proyectos o en su defecto
para seguir trabajando de esa manera.
10 Bug: es un error de software que causa fallas importantes en el sistema, desde fallas técnicas hasta fallas de seguridad (Cambridge University, 2014). 11 Glitch: es un error de software que causa resultados inesperados pero no interfieren con el desarrollo del videojuego, en algunos casos un glitch, puede desencadenar funciones que son explotadas por jugadores para obtener ventajas en el juego (Cambridge University, 2014).
91
CAPITULO VII: ESCAPE FROM HELL, PROTOTIPO DE VIDEOJUEGO
CASUAL PARA DISPOSITIVO MÓVIL
Uno de los objetivos importantes de este trabajo de grado es realizar un prototipo
funcional en el cual se pueda poner a prueba el modelo planteado, para ello se elaboró
un nivel de un video juego y se probó haciendo uso del modelo hasta el final de su
tercera fase; llegando a este punto se pueden determinar los beneficios del modelo
RACED. El video juego realizado contiene características similares al famoso juego
llamado Flappy Bird12, se tomaron las particularidades de este, debido a que se trata de
un video juego casual por excelencia, sus sencillas mecánicas, su historia simple y la
manera fácil en que se puede jugar, es el ejemplo preciso de esta clase de videojuegos.
Así que se tomócomo referencia a Flappy Birdy basados en esta idea, se entendió su
funcionamiento y se generó el código que solucionara los requerimientos del video
juego y se convirtió en un video juego llamado ESCAPE FROM HELL, en él se
analizaron las fases del modelo planteado.
FASE 1: CONCEPTUALIZACIÓN
ANALISIS DE REQUISITOS
En esta etapa se procedió a hacer el análisis de los requisitos del video juego siguiendo
los parámetros establecidos en el modelo tal como se muestra en la tabla 3.
12 Flappy Bird: Videojuego que fue viral en el 2012/2013 y creaba gran adicción a sus jugadores debido a su nivel de dificultad.
92
Concepto Información
Nombre Escape from Hell
Objetivo El objetivo del juego es impedir que el personaje caiga al suelo lleno de lava ardiente o choque con el techo cubierto de fuego, a su vez debe esquivar obstáculos hechos de púas de metal para no morir.
Motivación del juego
Escape from Hell es un videojuego de fácil acceso y con una curva de aprendizaje compleja lo cual hará que el jugador desarrolle habilidades para poder avanzar en el nivel.
Historia SKULLIE es un alma condenada al infierno que quiere escapar, con la ayuda de un ángel, quien le entrego sus alas mas no le enseño a volar. ¿Podrás ayudarlo a escapar?
Opciones Play Instructions Options
Modo de juego Individual
Niveles Este video juego en particular consta de un solo nivel el cual está distribuido de la siguiente manera: El techo estará cubierto de fuego ardiente color rojo. En el fondo se observaran las almas condenadas en el infierno. El piso estará cubierto de lava ardiente color naranja. A lo largo del nivel nos encontraremos cuerpos cavernosos con puntas de metal que se deben esquivar, al igual que se debe evitar tocar el techo y el piso.
Personajes Skullie es un cráneo color blanco, con unos ojos grandes, al cual le otorgaron unas alas de metal para poder volar.
Enemigos En este videojuego el enemigo es el entorno distribuido de la siguiente manera: Techo de fuego Piso de Lava Cuerpos cavernosos con púas de metal
Mecánicas de Juego
Al iniciar el juego se pueden hacer tres cosas al tocar la pantalla del dispositivo: Al tocar el botón de jugar entraremos a la pantalla de juego, aquí debemos presionar la pantalla del dispositivo para que el personaje empiece a planear por el escenario, cada vez que se toque la pantalla el personaje volara dependiendo de la forma en que se toque esta; entre más fuerte más se elevara el personaje, a menor presión se elevara menos.
93
Al tocar el techo de llamas, el piso de lava o alguno de los cuerpos cavernosos, se perderá el juego y aparecerá un botón de Jugar de Nuevo, para volver a empezar el juego, y un botón de Volver a Inicio, con el cual el jugador será devuelto al menú principal. Al esquivar un cuerpo cavernoso se obtendrá un +1 que se sumara al puntaje del juego. Al tocar el botón de instrucciones entraremos a la pantalla de instrucciones, aquí veremos de manera gráfica como se juega el videojuego. Para volver al menú principal se puede hacer de dos formas, tocando el botón de volver al inicio o con el botón para volver a atrás del dispositivo (si lo tiene). Al tocar el botón de opciones accederemos a las opciones del videojuego en la cual podremos apagar o prender la música y los efectos de sonido. Para volver al menú principal se puede hacer de dos formas, tocando el botón de volver al inicio o con el botón para volver a atrás del dispositivo (si lo tiene).
Cámara El juego cuenta con una vista 2D horizontal
Efectos de sonido No aplica
Música No aplica
Hardware El videojuego está orientado para celulares y tabletas que tengan sistema operativo android 4.x o mayor.
Software El videojuego será desarrollado en el motor de videojuegos Unity en su versión gratuita 4.3, utilizando el lenguaje de programación C#, los archivos gráficos se realizaran usando photoshop CS6. Tabla 3: Análisis de Requisitos videojuego Escape From Hell
ANALISIS DE USUARIOS
Al finalizar de analizar los requisitos necesarios para la realización del video juego se
procedió a estudiar al público objetivo del mismo, como se ha explicado a lo largo de
esta investigación, los usuarios de videojuegos casuales son muy genéricos es decir, el
video juego debe ser jugable por un amplio rango de personas, tanto en edad como en
sexo o gustos, los juegos casuales deben ser sencillos y fáciles de jugar para toda la
94
familia, sin embargo cada juego debe establecer un pequeño nicho de personas con
cualidades específicas y establecer unas habilidades mínimas que debía tener aquel
usuario puntual y objetivo, dichas características se describen a continuación en la tabla
4.
Concepto Información
Edad Jóvenes y adultos entre los 14 y 35 años.
Sexo Hombres y Mujeres.
Habilidades del usuario Los jugadores de Escape from Hell deben como mínimo saber manejar interfaces táctiles y leer.
Necesidades de entretenimiento Teniendo en cuenta el rango de edad al que va apuntado el juego, se puede deducir que son jóvenes y adultos que en su tiempo libre encuentren la necesidad de jugar mientras esperan el almuerzo, la ruta del colegio, una cita, entre otros.
Análisis etnográfico Los jugadores de Escape from Hell son personas jóvenes de estratos socioeconómicos entre 3 y 6, son personas modernas muy ligadas a la tecnología que le gustan los retos y con permanente deseo de superar obstáculos, algunos de ellos estudiantes de colegio o pregrado o jóvenes trabajadores.
Perfil del entorno Los entornos son tan variados como los dispositivos móviles lo permiten, espacios en zonas comunes y con mucha afluencia de gente o simplemente espacios solos y de momentos personales del usuario
Modelo de negocio El video juego será descargable de manera gratuita sin ningún tipo de publicidad.
Tabla 4: Análisis de Usuarios
95
EVALUACIÓN
Después de este análisis preliminar y tener claro el grupo objetivo, se procedió a
escoger un selecto grupo con el cual se realizó la primera evaluación que involucra al
usuario, para esto se realizó una encuesta (ver anexo 1), en ella determinamos
mediante preguntas cerradas, es decir aquellas preguntas en las cuales se selecciona
una de las respuestas previamente determinadas, con este tipo de preguntas se evaluó
la aceptación de la idea del juego. En esta misma encuesta se usaron algunas
preguntas abiertas, es decir aquellas que el usuario da su percepción explicativa y
personal del juego, estas preguntas abiertas nos sirvieron para incluir algunas ideas o
conceptos al juego.
En el análisis de la evaluación se concluyó con una muy buena aceptación de la idea
del juego por parte de los usuarios, además, las preguntas abiertas aportaron
sugerencias positivas de las mecánicas de juego y se trataban básicamente de: “para
jugar, se debe usar la acción táctil” y “adicionar un puntaje máximo logrado en el juego
actual” estas dos sugerencias fueron modificadas en el documento de requerimientos
porque se consideró que aportaban beneficios al juego.
ASIGNACIÓN DE TAREAS
Este es uno de los momentos más importantes del modelo planteado ya que aquí se
distribuyen las tareas principales a los diferentes equipos que participan en la creación
del juego, con la evaluación positiva se realizó la siguiente asignación de tareas:
96
META DISEÑO PROGRAMACIÓN
Menú Principal Botones de Jugar, Instrucciones y Opciones.
Estados e interacción de los botones: presionado, no presionado, ir a.
HUD Puntaje: sumar +1 al esquivar un cuerpo cavernoso.
Skullie y sus estados
Vivo quieto Vivo alas arriba Vivo alas abajo Muerto
Volar al tocar la pantalla.
Nivel
Piso de lava Cuerpos cavernosos Techo de fuego
Colisiones con el piso de lava, techo de fuego y cuerpos cavernosos.
Efectos de Sonido
Música Tabla 5: Asignación de tareas.
FASE 2 DISEÑO (DISEÑO GRAFICO)
DISEÑO GRAFICO
Con la asignación de tareas ya establecidas, el equipo de diseño plasmó los dibujos en
papel de lo que sería el personaje principal mediante bocetos en trazos tal como se ve
en la imagen de la izquierda de la Ilustración 21. Posteriormente se realizó una idea
más cercana al concepto final como lo vemos en la imagen derecha de la Ilustración 21:
97
Ilustración 21: A la izquierda bocetos del personaje y a la derecha un concepto final.
Este personaje se bocetó en los estados especificados de los requerimientos como lo
vemos en la Ilustración 22. Igualmente mediante este mismo proceso se realizaron los
entornos y obstáculos con los cuales el personaje principal interactúa a lo largo del nivel
en la Ilustración 23.
Ilustración 22: Estados del personaje en su diseño final.
98
Ilustración 23: Diseño del nivel del videojuego.
PROTOTIPO
Estos diseño previos se unen en un prototipo de papel (Ilustración 24), que será
presentado a los evaluadores; para este prototipo se dibujó de manera sencilla y en
hojas separadas, cada acción que puede realizar el jugador en un momento del juego,
de manera que, cuando el usuario elija una acción, se le debe mostrar la hoja
correspondiente al resultado de ésta. Con este prototipo se busca evaluar si las
metáforas, la interacción y la interfaz es comprensible y por lo tanto usable.
99
Ilustración 24: Prototipo en papel del video juego.
EVALUACIÓN
Para la evaluación del prototipo se realizaron dos pruebas que en su orden fueron
Prueba Heurística (ver anexo 2) y Test de Usuarios, Para la prueba Heurística se invitó
a dos expertos, el primero de ellos fue un diseñador gráfico conocedor del diseño y
creación de personajes y otro fue un diseñador gráfico con experiencia en UX, ellos
evaluaron personajes, entornos e interface, e identificaron algunas dificultades y
plantearon soluciones que se explicaran en el siguiente punto de esta fase. Por otra
parte se seleccionó a 5 participantes para hacer el Test de Usuarios, estas personas
se determinan teniendo en cuenta el análisis de usuarios realizado en la primera fase.
Ellos evaluaron el Prototipo en papel mediante el protocolo “Think-aloud” o pensamiento
100
en voz alta donde el usuario expresa en voz alta lo que está pensando o no entiende y
las razones por las cuales lleva a cabo una acción o duda, con ello se pretendió
detectar en que momentos los usuarios se equivocan o se detienen durante la
ejecución del juego y las razones por las cuales toman decisiones equivocadas. Los
resultados se explicarán en el siguiente punto.
DOCUMENTO DE FASE
En este paso se analizaron los resultados de la evaluación y se consignaron en un
documento junto con los bocetos y el prototipo que serán llevados a la FASE 3, dado
que los resultados de la evaluación presentaron cambios mínimos y ellos no apuntaban
a un replanteamiento de diseño de personajes o interfaz, se decidió realizarlos sin iterar
de nuevo en la fase.
Las conclusiones de la evaluación más importantes fueron las siguientes:
1. Las pruebas Heurísticas en relación al diseño de personajes sugieren realizar
una versión más estilizada de forma que se omitan algunos detalles y las
pruebas de usuario en este mismo tema resaltan la importancia de añadir
elementos al personaje principal, en este caso se trata de “unos cachos de
diablo que den más la idea que se trata de un personaje venido de los
infiernos”, de igual manera.
101
2. El test de usuarios concluyó que el personaje debía tener “alas más parecidas
a las de un ángel, son visualmente agradables y relacionan mejor al
personaje con el contexto de la historia”. Lo demás puntos de la evaluación
fueron completamente positivas. La Ilustración 25 muestra las correcciones
realizadas por el equipo de diseño que fueron adjuntadas en este documento.
Ilustración 25: Correcciones realizadas después de las pruebas.
FASE 2: DISEÑO (Equipo de Desarrollo)
ANALISIS DE INTERACTIVIDAD
El equipo de desarrollo realiza el análisis las tareas y basadas en ellas, prepara casos
de uso para resolver los problemas de interactividad que plantea las mecánicas de
juego, esos casos de uso los plantee en tarjetas CRC que se observan a continuación.
102
TARJETAS CRC
Estas tarjetas presenta cada interactividad del juego y su tiempo para resolverse de
esta manera el equipo de desarrollo tendrá claro cada objetivo y podrá determinar
responsables para resolverlos, igualmente se determinó los tiempos estimados y en él
se consigna los resultados de la prueba realizada. En la siguiente imagen vemos los
casos de uso planteados.
Ilustración 26: Casos de uso.
SOLUCIONES PUNTUALES
El equipo de desarrollo planteó las soluciones en código que considero más favorables
para resolver los casos de uso generados en las tarjetas CRC, estos códigos los
probaron usando formas simples como cuadrados y círculos.
103
Ilustración 27: Aparte de un Script de programación.
EVALUACIÓN DE FUNCIONALIDAD
El líder del equipo de desarrollo evaluó desde su conocimiento la funcionalidad de las
interacciones presentadas por el equipo de desarrollo, de esta manera, estos trozos de
código funcionales están aprobados y listos para ser integrados en la programación
total de la Fase siguiente y de igual manera serán almacenados y reciclados para
futuros desarrollos que demanden soluciones similares.
104
FASE 3: IMPLEMENTACIÓN
DISEÑO GRÁFICO FINAL
El equipo de diseño realizó las piezas finales que llevará el juego, en fases anteriores
se determinó que el concepto del juego sería PIXELART, el pixel art es una forma de
arte digital basado en el puntillismo y que fue adoptado por los videojuegos antiguos y
posteriormente en juegos de móviles en sus primeras generaciones para diseñar sus
videojuegos y ha sido tomado como tipo de arte para SCAPE FROM HELL en la
siguiente figura su observa el personaje del videojuego diseñados en Pixelart.
Ilustración 28: Diseño de personaje en Pixelart.
105
PROGRAMACIÓN
El equipo de desarrollo recibe los artes entregados por el equipo de diseño y los integra
en este paso, para de esta manera realizar el prototipo funcional que será evaluado en
esta fase.
Ilustración 29: Interfaz de trabajo en Unity 3D.
PROTOTIPO FUNCIONAL Y EVALUACIÓN
En este punto el equipo de desarrollo ya tiene listo el primer prototipo funcional y puede
ser jugado en dispositivos móviles, para su evaluación se tuvo en cuenta el análisis de
tres expertos mediante pruebas heurísticas (ver anexo 2) al igual que pruebas de
usuario para las cuales se eligió a 5 personas. Estas pruebas de usuario se realizaron
con 3 tipos de dispositivos móviles comerciales, el Samsung Galaxy S4, Motorola Razr
y una tableta Toshiba con sistema operativo Android, estas pruebas se llevaron a cabo
en entornos externos diferentes para cada uno de los participantes, los usuarios jugaron
la aplicación y la evaluaron mediante la técnica de ThinkAloud, después de escribir sus
106
comentarios, se le formularon preguntas en torno a sus expectativas y sus impresiones
en tanto a diseño visual como a mecánicas. En cuanto a las pruebas Heurísticas, lo
expertos jugaron y entregaron sus puntos de vista teniendo en cuenta sus
conocimientos y nos dieron sus observaciones.
Los resultados de esta evaluaciones entregaron una excelente satisfacción respecto a
la jugabilidad, “es sencillo de entender y fácil de jugar ya que requiere mínimos
conocimientos”, consideraron que además era divertido ya que su breve historia
respecto a Skullie en el infierno, le imprime una curiosidad adicional que lo convierte en
un juego más entretenido, ya que las personas sienten simpatía por el personaje, por
otra parte algunos usuarios considero que el juego se convierte en un gran reto y algo
adictivo ya que cada usuario quiere sobrepasar su propia marca, advirtieron que no era
un juego fácil, por tal razón se hace más interesante. Otro sector de usuarios considero
ese nivel de dificultad una barrera para seguirlo jugando por tal razón, sugieren que el
juego tenga la opción de seleccionar el nivel de dificultad.
El juego en diseño tuvo una buena aceptación y las metáforas realizadas en el pixelart
fueron entendidas, teniendo en cuenta que el pixelart es una técnica que da una
dificultad mayor en hacer los objetos parecidos a la realidad.
107
Ilustración 30: Prueba de usuarios.
Para finalizar se encontraron varios bugs o errores de programación que
desencadenaron acciones confusas o resultados indeseados, como por ejemplo en
algún pasaje de un obstáculo Skullie no moría al colisionar con este, entre otros, que
deben ser solucionados por el equipo de desarrollo antes de continuar a la fase final.
De esta manera el prototipo funcional de SCAPE FROM HELL se puso a prueba en el
modelo RACED, las conclusiones las analizaremos a continuación.
108
CONCLUSIONES
Después de algunas búsquedas bibliográficas, no se encontró fácilmente una guía bien
estructurada para el desarrollo, la creación y realización de aplicaciones en dispositivos
móviles, más exactamente videojuegos. El equipo de trabajo buscaba que dichos video
juegos se realizarán de forma ágil atendiendo a la demanda actual asegurando además
el éxito del mismo, se encuentra entonces que un punto fuerte para el éxito en
productos interactivos es tener en cuenta al usuario en el proceso de desarrollo, por
esta razón se tomó la decisión de realizar una investigación con respecto a la industria
de los videojuegos, y estudiar a fondo las teorías de usabilidad, HCI, Diseño centrado
en el usuario y los conceptos que rigen las metodologías convencionales y agiles para
el desarrollo de software; adicionalmente las investigaciones que en general han
realizado diferentes autores respecto al desarrollo de videojuegos, para de esta manera
proponer un Modelo Centrado en el Usuario Para el Desarrollo Ágil de Videojuegos
para Dispositivos Móviles, dicho modelo se llamó RACED.
Se creó el prototipo de un videojuego Casual llamado ESCAPE FROM HELL y se puso
a prueba usando RACED, el modelo respondió de manera efectiva, por una parte, las
iteraciones y asignación de tareas tomadas de las metodologías agiles, aseguró un
buen y rápido desempeño de los equipos de trabajo. Cada fase entregó resultados en
menos de dos semanas, lo cual se considera muy positivo, ya que en mes y medio se
tenía el prototipo funcional trabajando correctamente. Por otro lado el estudio de
requerimientos y las evaluaciones en cada fase por parte de los usuarios permitieron
109
mejorar de forma segura el concepto de arte y jugabilidad, a tal punto que al finalizar la
tercera fase los usuarios tenían una muy alta satisfacción con el prototipo presentado,
todo esto minimizo errores y redujo el tiempo estimado de entrega.
Cabe recalcar que el modelo se probó en un prototipo de un solo nivel y que el
videojuego contenía las características principales de un juego ya popular, por tal razón,
y a manera de trabajo futuro, se debe evaluar el funcionamiento del modelo en un
videojuego casual completo, además, que este sea totalmente nuevo en sus mecánicas
de juego y que incluya musicalización. Se considera que como posibles mejoras se
puede modificar y probar el modelo de tal manera que sea útil para realizar desarrollos
de videojuegos más complejos y robustos.
Para finalizar se puede concluir que el modelo RACED y en general esta investigación,
puede ser usada por equipos de trabajo y pequeños y medianas empresas de
desarrollo de aplicaciones para móviles, como un punto de partida para organizar la
creación de video juegos, de esta manera los desarrolladores asegurarán productos
con una buena experiencia de jugador, desarrollos rápidos que se verá reflejados en
bajos costos de producción y productos que cumplan con los estándares de desarrollo
actuales.
110
ANEXOS
Anexo 1: Encuesta Fase 1
Se realizó una encuesta digital que constaba de 11 preguntas para saber que
aceptación tendría el videojuego, y que cambios en las mecánicas de juego se podrían
implementar.
Se tomó una muestra total de 50 personas que tenían edades entre 14 y 30 años, a
continuación se muestran los resultados obtenidos.
1. ¿Qué edad tienes?
2. ¿Sexo?
a. M
b. F
6
8
21
5
3 2
Edad
14 17 22 25 28 30
111
3. ¿Tienes algún dispositivo móvil para tu uso personal?
a. Si
b. No
4. ¿Tienes instalados video juegos en tu dispositivo móvil?
a. Si
b. No
35
15
Sexo
Masculino Femenino
50
0
Dispositivo Movil para uso personal
Si No
50
0
Videojuegos instalados
Si No
112
5. ¿En cuáles de estas situaciones usas más tu dispositivo móvil para jugar?
a. En casa
b. En el bus
c. En el colegio/universidad
d. Otro, ¿Cuál? __________________
6. ¿Cuánto tiempo del día destina usted a jugar en su dispositivo móvil?
a. Menos de 1 hora
b. 1 hora
c. Más de 2 horas
7. ¿Con que frecuencia descarga nuevos juegos para su dispositivo móvil?
a. 1 vez al día
17
221
10
Uso del dispositivo móvil
En casa En el bus En el colegio/universidad Otro
23
20
7
Tiempo de juego
Ménos de 1 hora 1 Hora Más de 2 horas
113
b. 2 o más veces a la semana
c. 2 o más veces al mes
8. ¿Conoce el videojuego flappy bird o alguno parecido?
a. Si
b. No
9. ¿Le interesaría jugar un video juego parecido al de la pregunta anterior, cuyo
personaje es una calavera con alas de metal que debe escapar del infierno?
a. Si
b. No
2
12
28
Descarga de videojuegos
1 vez al día 2 o más veces a la semana
2 o más veces al mes
39
11
Flappy Bird
Si No
114
10. ¿Qué opciones adicionales le gustaría que tuviera el videojuego?
a. Objetos
b. Tabla de puntaje
c. Power Up
11. En cuanto a la jugabilidad, ¿Cómo le gustaría poder jugar este juego?
a. Botones en pantalla
b. Giroscopio (es decir moviendo el dispositivo móvil
c. Táctil en cualquier lugar de la pantalla
47
3
Escape from Hell
Si No
11
31
5 3
Opciones Adicionales
Recoleccion de Objetos Tabla de puntaje
Power Ups Ninguna
115
Anexo 2: Pruebas Heurísticas Para todas las Fases del modelo
Las pruebas Heurísticas se realizaron con los expertos con el fin que ellos desde su
perspectiva detecten posibles fallos, en este caso se seleccionaron expertos en
Experiencia al usuario y expertos en Diseño Gráfico. Posteriormente se les solicito
realizar evaluación de la interfaz, evaluación de los personajes, Elementos y entornos, y
Evaluación de la jugabilidad. A continuación se explica cada una:
Evaluación heurística de interfaz: teniendo en cuenta sus experiencias los
evaluadores midieron la calidad de la interfaz teniendo en cuenta los lineamientos
básicos de diseño como son:
•Utilización de principios para organización de elementos: (Proximidad, Simetría,
Semejanza, Continuidad)
•Simplicidad de la interfaz
•Relación entre figura y Fondo
•Utilización de las teorías y significados del color
3
12
35
Jugabilidad
Botones en pantalla
Giroscopio
Tactil en cualquier lugar de la pantalla
116
•Coherencia Global de la interfaz
Evaluación Heurística de los personajes: Es determinada por la tecnología y el tipo
de arte usado para el diseño del juego, en el caso de SCAPE FROM HELL se trata de
Pixelart, los factores a tener en cuenta fueron:
•Conceptualización de los personajes Elementos teniendo en cuenta la narrativa del
juego
•Calidad en el uso de la técnica de diseño escogida para el juego
•Correcto uso de metáforas y estados en los elemento y personajes del juego
Evaluación Heurística de la jugabilidad: Finalmente, se solicita a los evaluadores
analizar la experiencia de la jugabilidad en general de la aplicación teniendo en cuenta:
• Satisfacción, agrado o complacencia ante el videojuego y el proceso de jugarlo
• Aprendizaje, es decir la facilidad de comprender y dominar la mecánica de juego
• Efectividad, Que tan efectivo es el juego en ofrecer diversión mientras se logra el
objetivo del juego
• Inmersión, Capacidad de Inmersión e integración por parte del jugador
• Motivación, Capacidad de Motivación en continuar jugando y persistir en la tarea de
culminar objetivos
Respuesta, Que tan buena y clara es la respuesta del juego a las acciones perpetradas
por el jugador
117
REFERENCIAS
14598-1, I. (Information Technology - Evaluation of Software Products - General Guide. ISO). 1998.
Agile Manifesto. (2001). www.agilemanifesto.org. Retrieved Agosto 1, 2013, from
http://agilemanifesto.org/iso/es
Amory, A. (2006). Game Object Model Version II: a Theoretical Framework for Educational Game
Development. Durban: Springer.
Arzuza, J. (2011, Abril 13). www.artzuza.com. Retrieved Marzo 15, 2014, from
http://www.artzuza.com/2011/04/character-animation-technical-director.html
Baldwin, M. (2006, Julio). Gamasutra. Retrieved Julio 29, 2013, from Carrer paths in the Game Industry:
http://www.gamasutra.com/view/feature/131164/career_paths_in_the_game_industry.php
Beck, K. (1999). Extreme Programming Explained: Embrace Change. Adisson-Wesley.
Bell, D. (2003, Junio 15). IBM. Retrieved from
http://www.ibm.com/developerworks/rational/library/769.html
Boehm, B. (1988). A Spiral Model of Software Development and Enchancement. IEEE Computer, 61-72.
Bromley, E. (1978). Estados Unidos Patent No. 4249735.
Bromley, E. (1980). Estados Unidos Patent No. 4327915.
Brown, T. (2008). Design Thinking. Hardvard Business Review.
Calinescu, M. (2014). Unveiling the Secrets behind App Store Category Dynamics. Amsterdan: Distimo.
Cambridge University. (2014). Retrieved from http://dictionary.cambridge.org/es/diccionario/ingles-de-
negocios/bug?q=bug
Cambridge University. (2014). Retrieved from http://dictionary.cambridge.org/es/diccionario/ingles-de-
negocios/glitch?q=glitch
Cañada, J. (2003). 10 Malentendidos sobre Interacción Persona-Ordenador. Retrieved 13 2013, Junio,
from http://www.terremoto.net/x/archivos/000060.html
Casual Games Association. (2005). Casual Games Association. Retrieved Julio 15, 2013, from
http://www.casualgamesassociation.org
Cockburn, A. (2004). Crystal Clear: A Human Powered Methodology for Small Teams Including the Seven
Properties of Effective Software Projects. Addison-Wesley Professional.
118
Constantine, L. L., & Lockwood, L. A. (1999). Software for Use: A Practical Guide to the Models and
Methods of Usage-Centered Design. New York: Addison-Wesley.
Cushman, W. (1991). Human Factors en product design. New York: Elsevier Science Publish Company.
Dillon, A. (2001). Beyond Usability: Process, Outcome and Affect in human computer interactions.
Canadian Journalof Information Science, 57-69.
Dillon, A., & Morris, M. (1999). P3: modeling and measuring the human determinants of information
systems usage. 43rd Annual Meeting of the Human Factors and Ergonomics Society, Paper
presented at the Annual Meeting of HFES in Texas.
Dix, A. (2003). Human-Computer Interaction (3rd Edition). Prentice Hall.
Flood, K. (2003, 14 2014). www.gamedev.net. Retrieved Enero 23, 2014, from
http://www.gamedev.net/page/resources/_/technical/general-programming/game-unified-
process-r1940
Gloud, J. D., & Lewis, C. (1985). Designing for usability: key principles and what designers think.
Communications of the ACM, 300-311.
Granollers, T. (2003). User Centred Design Process Model. Usability Engineering and Software
Engineering Integration. Lérida: IOS Press.
GSMA; A.T. Kearney; Wireless Intelligence. (2011). Observatorio Móvil de América Latina. Londres:
GSMA.
Highsmith, J. (2000). Agile Project Management Advisory Service. Cutter Consortium.
Highsmith, J. (2001). Agile Software Development: The people factor. IEEE Computer, 120-122.
Hix, D., & Hartson, H. R. (1993). Developing User Interfaces: Ensuring Usability Through Product and
Process. John Wiley and Sons.
International Game Developers Association. (1994). International Game Developers Association.
Retrieved Octubre 27, 2013, from IGDA: www.igda.org
Jarvien, A., & Others. (2002). Communication and Community in Digital Entretaiment Services.
Hypermedia Laboratory Net.
JoAnn, T., & Hackos, J. C. (1998). User and Task Analysis for Interface Design. John Wiley & Sons, Inc.
Kannan, N. (2011, Septiembre). Software Quality. Retrieved Noviembre 25, 2012, from
http://searchsoftwarequality.techtarget.com/tip/Mobile-development-Why-using-an-Agile-
methodology-makes-sense
Korhonen, H. K. (2006). Playability Heuristic For Mobile Games. ACM Press.
119
Kotonya, G., & Sommerville, I. (1998). Requirements Engineering: Processes and Techniques. In G.
Kotonya, & I. Sommerville, Requirements Engineering: Processes and Techniques (pp. 25 - 49).
Chichester: Wiley.
Kroll, P., & Philippe, K. (2003). The Rational Unified Process Made Easy. In P. Kroll, & K. Philippe, The
Rational Unified Process Made Easy (pp. 39 - 41). Addison Wesley.
Landauer, T. K. (1995). The Trouble with Computers:Usefulness, Usability and Productivity. MIT Press.
Laurel, B. (1990). The art of human-computer interaction. Addison-Wesley.
Lazzaro, N. (2008). Game Usability: The four fun keys. CRC Press.
Lozano, M. D. (2002). Desarrollo y Generación de Interfaces de Usuario a Partir de Tecnicas de Analisis de
Tareas y Casos de Uso. Inteligencia Artifcial, 83-61.
Melissinos, C., O'Rourke, P., & Mika, M. (2012). The art of Video Games: From Pac-Man to Mass Effect. In
C. Melissinos, P. O'Rourke, & M. Mika, The art of Video Games: From Pac-Man to Mass Effect
(pp. 10-14). Welcome Books.
Ministerio de las TIC. (2011, Octubre). Vive Digital. Retrieved Octubre 10, 2012, from
http://www.vivedigital.gov.co/files/PresBalanceViveDigital_2011.pdf
Ministerio de las TIC. (2011, Octubre). Vive Digital. Retrieved Octubre 10, 2012, from
http://www.vivedigital.gov.co/files/Vivo_Vive_Digital.pdf
MinTIC. (2010). Vive Digital. Retrieved from http://www.mintic.gov.co/portal/vivedigital
MinTIC. (2012). www.apps.co. Retrieved from www.apps.co
mobiThinking. (n.d.). mobiThinking. Retrieved Julio 29, 2013, from http://mobithinking.com/mobile-
marketing-tools/latest-mobile-stats/e#lotsofapps
Montero, Y. H. (2009). Informe APEI sobre Usabilidad. APEI.
Morales, G., Nava, C., Fernández, L., & Mirsha, A. (2010). Procesos de Desarrollo para Videojuegos.
CULCyT, 26-39.
Nielsen, J. (1993). Usability Engineering. AP Professional.
Nielsen, J. (1993). Usability Engineering. In J. Nielsen, Usability Engineering (pp. 165 - 226). California:
Morgan Kaufmann.
Nielsen, J. (2012, Enero 4). Usability 101: Introduction to Usability. Retrieved Enero 31, 2014, from
http://www.nngroup.com/articles/usability-101-introduction-to-usability/
120
Nokia. (2010). Game design and User Experience. Retrieved Julio 6, 2013, from
http://library.developer.nokia.com/index.jsp?topic=Design_and_User_Experience_library/GUID-
21B5CE2C-7141-41CF-A669-2006502C151E.html
Ortas, A. (2001). Aproximación a la Ingeniería de Requerimientos. Uruguay.
Parra, L. E. (2013, Enero). ¿Como funciona la industria de los videojuegos en dispositivos moviles desde
la perspectiva de su empresa? (C. Martínez Uribe, Interviewer)
Perfetti, C. (2005, junio 9). www.uie.com. Retrieved Enero 15, 2014, from
http://www.uie.com/articles/five_second_test
Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S., & T., C. (1994). Human-Computer Interaction.
Addison Wesley.
Pressman, R. (2002). Ingeniería del Software Un enfoque práctico. McGraw-Hil.
Pressman, R. (2005). Ingenieria del Software: Un enfoque Practico. In R. Pressman, Ingenieria del
Software: Un enfoque Practico (p. 601). McGraw-Hill.
Ramos, M. (2001). HCI concepto y desarrollo. El Profesional de la informacion.
Rollings, A., & Adams, E. (2003). Andrew Rolling and Ernest Adams on Game Design. New Riders Games.
Romero, J. (2011). Smartphones: The Pocketable PC is your phone smarter than a fifth grader? IEEE
Spectrum Magazine.
Rouse III, R. (2001). Game Design: Theory & Practice. Wordware Publishing INC.
Schwaber, K., & Sutherland, J. (1991). www.scrum.org. Retrieved Noviembre 30, 2013, from
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf
Shneiderman, B. (1998). Designing the user interface. Michigan: Addison Wesley.
Shneiderman, B. (2000). Universal Usability. Comunication of the ACM, 84-91.
Smith, J., Karr, G., & Jones, L. (1978). Estados Unidos Patent No. 4359222.
Thimbleby, H. (1990). User Interface Design. ACM Press Addison and Wesley.
Viallon, F. J. (2013). Mobile Applications & Reputation. Marseille: StarDust SAS.
VisionMobile. (2014). Developers Economics Q1 2014 State of the Developer Nation. Londres: Vision
Mobile.
Viswat, T. (2013, Febrero). El uso de metodologias en la industria de los video juegos. (E. Bejarano,
Interviewer)
121
Wells, D. (2009, Septiembre 28). www.extremeprogramming.org. Retrieved Agosto 5, 2013, from
http://www.extremeprogramming.org/values.html
Williams, L. (2007). A survey of Agile Development Methodologies.
