1

Indice

Nuestro equipo se llama Profi tPlay, un equipo de técni-cos y creativos dedicados a incrementar las ganancias de nuestros clientes (empresas) por medio de instalaciones y aplicaciones interactivas para sus clientes (consumido-res).

Está formado por:• Danae Vara - SCRUM y diseño de producto• Pau Moreno - Programación e implementación• Emiliano Martínez - Diseño gráfi co de interfaces• Jordi Mola - Grabación y edición de vídeo.

Introducción 3Desarrollo 4Programación 6Estética 8Diseño de Producto 10Implementación 12Gestión 14Conclusiones 15

3

Introducción

El presente proyecto corresponde al cuarto y último ejercicio de la asigna-tura de Diseño, Arte y Creatividad impartida por el Prof. Emiliano Labrador Ruiz de la Hermosa dentro del Master en Creación, Diseño e Ingeniería Multimedia del BES LaSalle – Universitat Ramon Llull.

A lo largo del curso hemos ido evolucionando en los proyectos. Comenzan-do por ejercicios individuales y tras un largo recorrido hemos llegado al último de los proyectos, el más complejo y el más apasionante.

Briefi ng: En equipo de cuatro miembros, realizar en colabora-

ción con un colectivo, una aplicación multimedia con fi -nes artísticos o prácticos que ha de ser utilizada por dicho colectivo. Se ha de respetar un cariz estético marcado.

A continuación, en esta memoria, se puede encontrar de una manera más detallada el desarrollo del proyecto, desde el nacimiento de la idea hasta su implementación, pasando por su diseño, construcción y programación.

Durante todo el proceso de ha adoptado una fi losofía de trabajo tipo SCRUM, es decir, se ha mantenido contacto directo y continuo con el cliente y el pro-fesor, y se han utilizado pequeñas metas tipo sprint para alcanzar el objetivo buscando aprovechar el tiempo al máximo.

El ejercicio se ha llevado a cabo en ocho semanas, utilizando dos semanas para el brainstorming, cuatro para desarrollar la idea, y las últimas dos para preparar la implementación y su documentación.

Después del planteamiento del proyecto el equipo se reunió para realizar un primer brainstorming par elegir el colectivo con el que se deseaba trabajar. El colectivo se-leccionado fue el de los propietarios de bares. Éste co-lectivo se eligió por tener cercanía a él, ser un sector de interés para el grupo y representar una oportunidad para trabajar con un referente externo como cliente cercano. En lo particular David Palacios, propietario del Bar TuruTa-pes en Sant Boi.

Más adelante el equipo llevó a cabo un segundo bra-instorming, donde se defi nió, tomando como referencia las necesidades de nuestro cliente, la idea a desarrollar. La idea elegida fue la de crear un juego interactivo para que nuestro cliente-colectivo pudiera utilizar en su estableci-miento y fomentar las ganancias de éste mientras fi deli-zar su clientela, que eran sus necesidades. Dicho juego había de estar vinculado al control de stock del bar pues sería este el que controlaría en cierta medida el desarrollo de la aplicación.

TuruGame es el nombre de la parte del juego. Es la parte con la que tienen relación los clientes del bar y con la que interactúan conscientemente. TuruGame es un jue-go, a modo de juego de casillas, donde según los clientes forman equipos por mesas en el bar y, representados por fi chas en el tablero, van tirando los dados para avanzar hacia la meta.

El formato de juego de mesa con casillas y dados se eli-gió por diferentes razones: es un formato que la gente rela-ciona y es intuitivo para jugarlo. Al igual que los dados, que son universales y hacen recordad un juego y diversión.

A lo largo del tablero, de 50 casillas, ha diferentes obs-táculos o premios con los que se pueden encontrar los equipos. Hay unas casillas que los hacen avanzar, otras retroceder, en cinco casillas ganan premios por cortesía del bar y en otras dos les toca castigo. El premio fi nal, y el más grande, se encuentra al fi nal del tablero y solamente uno equipo puede llegar a él. Las casillas de castigo fueron petición del cliente.

5

Desarrollo

Para la elaboración del tablero fi nal antes se crearon diferentes opciones para probarlos en playtests preliminares y poder pulir la mecánica del juego. De ese modo nos asegurábamos que el cliente no perdería dinero por un mal diseño del tablero y reglas.

Es de gran importancia mencionar que el juego se creó de una forma abierta donde el cliente puede modifi car los datos del juego según vea las necesidades.

El TuruGame se basa en los datos proporcionados por el TuruStock. El TuruStock es un programa a modo de control de inventario donde el pro-pietario del bar puede llevar las cuentas de sus clientes. Se ha pensado el vincular las dos aplicaciones a modo que el propietario pueda tener el juego en movimiento sin tener que estar al pendiente de él puesto que los turnos los va reasignando el mismo control de cuentas.

TuruGame y TuruStock funcionan en armonía de la siguiente manera:

1. La mesa, equipo, pide productos a consumir,2. Por cada dos euros de consumo se le abona una tirada a la mesa,3. El equipo utiliza el pulsador que está en su mesa para tirar el dado.4. Avanza según la suerte.5. Entre tirada y tirada hay un tiempo de espera de dos minutos donde el

equipo no puede volver a tirar, esto está pensado para no dar ventaja a ninguna mesa por haber pedido antes.

6. Así continúa por el tablero según el dado y las casillas en las que caiga.7. Las casillas le pueden dar premios o castigos. 8. El premio mayor se encuentra al fi nal del camino y se ha de llegar con

la tirada justa para ganarlo, de otro modo la fi cha vuelve atrás y lo sigue inten-tando.

9. Según vaya consumiendo la mesa, el camarero puede seguir sumando en su cuenta y así le van apareciendo tiradas nuevas a los jugadores.

Más detalles de las partes de la aplicación se detallan en los apartados de interfaces, programación y pulsadores.

La parte de programación se ha divido en dos ejecutables: TuroStock y TuruGame. Ya que la

idea es aprovechar el consumo del cliente, se ha creado una aplicación que fuese útil para el dueño del bar, que no le supusiera ninguna pérdida de tiempo y a su vez per-mitiera algún tipo de interacción con el juego. Por tanto se diseño una aplicación de gestión de mesas, que está pensada para poderla seguir desarrollando como gestión de Stock (de ahí su nombre).

Ambas aplicaciones están desarrolladas en Flash, gra-cias a que podemos integrar fácilmente un diseño 2D con código bastante elaborado. Esto nos permite hacer apli-caciones escalables con muy poco margen de tiempo. Como contrapunto, la aplicación es lenta, y se ha tenido que crear un servidor web para poder comunicar las dos aplicaciones via Wifi (recordemos que Flash es un cliente), con la complejidad que eso conlleva a la hora de progra-mar. El lenguaje a sido ActionScript 3, para no quedarnos desfasados utilizando versiones anteriores, y que nos ha dado mucha más versatilidad a la hora de programar gra-cias a estar orientado a objetos.

Con esta idea, TuruStock es una aplicación comple-tamente escalable, dividida en diferentes clases para su posterior ampliación, que carga un XML como base de datos para los productos. Esto nos permite hacer que la aplicación sirva para cualquier bar/tienda/establecimien-to con tan solo cargar el XML. Éste sigue una estructura muy sencilla que consta de categorías y productos, los cuales tienen información en cada atributo del XML. Tal y como está hecha la programación es fácil también añadir nuevos atributos que nos permitan hacer la gestión de stock, avisar al dueño del bar cuando se esté quedando sin un producto, calcular los benefi cios netos que está teniendo al día… etc.

7

Programación

Es por tanto, una aplicación que se vale por sí sola, que no necesita del juego para ser atractiva. Gracias a la tecnología usada, y a ser modifi car datos vía wifi , nos permitiría portarla a un dispositivo móvil que podría ser la libreta usada por el camarero, teniendo un mayor control sobre la aplicación y facilitando aún más la tarea del camarero, ya que no tendría que hacer el pedido dos veces (una en la libreta y una en TuruStock). Está planteado como líneas de futuro, ya que de momento el camarero tenía que escribir en la libreta y en la máquina registradora. La idea fi nal es facilitar al máximo la tarea al camarero.

Gracias al control de cada mesa mediante la aplicación de TuruStock, po-demos saber el consumo actual, y cuanto gasta cada vez que se pide de nue-vo. Esto nos permite utilizar estos datos para que el cliente juegue casi sin darse cuenta. Existe otra aplicación ejecutándose en otro ordenador (condición necesaria que ambos estén dentro de la misma red) que recibirá los datos re-cogidos por TuruStock, los interpretará, y trabajará con ellos. En nuestro caso, TuruGame recogía los datos siguientes: Numero de mesa que consume, y cantidad consumida en un pedido. Cada vez que el cliente volvía a pedir, se incrementaba el número de tiradas en función de una relación defi nida. A partir de aquí el cliente podía interactuar con la aplicación mediante un pulsa-dor inalámbrico. Para diferenciar los pulsadores inalámbricos, se cogieron 3 numpads inalámbricos normales y corrientes, a los cuales se les dejo teclas diferentes para que enviasen números diferentes. Esto tan solo nos limita en un aspecto, el número máximo de mesas que pueden jugar son 17, tantas como teclas tiene el teclado inalámbrico. La aplicación TuruGame, está todo el rato escuchando eventos de teclado, de tal manera que cuando recibe un dato, resta una tirada a la mesa que apretó el pulsador: Cuando recibe un 1, resta una tirada a la mesa 1, cuando recibe un 2, resta una tirada a la mesa 2… etc. Además la aplicación bloquea durante dos minutos las tiradas del usuario, de tal manera que hace el juego un poco más duradero.

Toda la aplicación es completamente confi gurable vía XMLs, y está planea-do hacer una tercera aplicación de backend, que permita al camarero gestio-nar estos XMLs sin tener que entender cómo funciona éste lenguaje, de una manera mucho más intuitiva.

Muchas veces para inspirarme observo la naturaleza, se planteaba otro reto importante el diseñar un tablero de casillas que fuera diferente a todo los visto y que se com-prendiera y gustara.

9

Estética

Una de las cosas más difíciles para un diseñador gráfi co es hacer algo que sea del agrado de todos los espectadores y a la vez ser inovador y sorpren-dente.

En el caso de hacer una interfase gráfi ca que vería cualquier cliente de un bar, se planteaba todavía más difícil ya que llega un número indefi nido de clien-tes y prácticamente inclasifi cable.

Finalmente planteamos algo limpio y sencillo para la interface de TuruS-tock y usando algunos brillos y sombras para hacer los elementos mas apete-cibles y una sencilla tipografía un poco condensada para aceptar una buena cantidad de información legible como es la open font Yanone Kaffeesatz.

Teniendo en cuanta que nuestro proyecto está naciendo de la mano de TuruTapes como cliente inicial, quisimos acercarnos mucho a su nombre y es-tética en la medida de lo posible. Tomamos en negro, rojo y blanco de su logo y los hicimos nuestros con ciertos toques diferenciadores como el encrudecer el blanco y plantear nuestros logos con algun punto coincidente, adicional al color y al nombre, como es la tipografía de “turu” en el logo de TuruGame pero inclu-yendo nuestro toque con una tipografía más actual pero siempre procurando la atemporalidad como lo es la ITC Offi cina Serif.

En el caso del diseño para el tablero, la inspiración de la naturaleza me llegó por el llamado numero Phi Φ que se encuentra en cada sitio de la naturaleza y del cual deriban conceptos como el número áureo, la sucesión de Fibonacci, la divina proporción, el rectánculo de Euclides, etc.

Este número está presente en la espiral logarítmica de las conchas del molusco nautilo la cual está integrada en el diseño del tablero.

Adicionalmente, para darle un toque local adecuado para un bar “de toda la vida” de Barcelona, quisimos usar el trencadis como elemento característico.

11

Diseño de producto

Para que los jugadores de las mesas pudieran activar sus turnos en el Turu-Game, hacía falta un objeto interactivo: el pulsador.

La parte tecnológica del pulsador está solucionada con un numpad inalám-brico que envía un solo valor (por pulsador) al TuruStock. Cada pulsador tiene un numpad que identifi ca la mesa.

Los pulsadores debían guardar en su interior los numpads inalámbricos pro-tegidos, ser resistentes (dentro de las condiciones posibles), hacer referencia a un pulsador para un juego siendo intuitivos en su uso y guardar la estética del TuruGame mientras diferencia las mesas.

Los pulsadores están hechos con medias bolas de porexpan de 20cm de diámetro que han sido esculpidas para guardar en su interior el numpad, en-macilladas, lijadas y pintadas. Cada pulsador hace referencia a la fi cha que representa la mesa en el tablero y sigue la estética del TuruStock también.

Cada uno de los pulsadores permite un fácil acceso al numpad para en-cenderlo, apagarlo y cambiarle las baterías. También tienen un recubrimiento antideslizante para que no se resbale por la superfi cie de la mesa.

Para la implementación del juego se realizaron tres pulsadores que repre-sentan las mesas 1,2, y 3. Rojo, verde y azul.

�������������������

������

������������ �������� ������������

������� �������������������������

���������������������������������

�� ���

���������������������

�� �������������������

�����������������������

���� ���� !�"�� ����#$����

���� �%�������������&��

���������'�������(�%� ������

�� �)"*�#�* ��+�,-#

������ ������� ��������

����.������%������

"�� ����%��(��/���0�����%� 1

������������� ����������

������������������ �����

�������������������������� �

���������� ����

������������������������������22�� �����

������ ���

Para realizar la implementación de la aplicación se preparó un evento con antelación. Se diseño un cartel y se creó un evento para invitar a los “ami-gos” del grupo del bar en facebook.

La prueba se realizó el viernes 28 de enero de 21h a 23h. Donde partici-paron tres mesas con cuatro personas cada una.

Durante la implementación se rea-lizó la grabación del video para po-der documentar las experiencias de la prueba. También se pidieron autoriza-ciones fi rmadas para los derechos de imágenes de los menores presentes y se realizaron encuestas para medir la satisfacción de los participantes.

13

Implementación

Como resultados del playtest podemos resumir lo siguiente:• Los jugadores se divirtieron mucho con el juego y no dudan en lo volverían

a jugar

• Los equipos están conscientes de que el juego incita al consumo no pla-neado pero aceptan esta verdad y la asumen

• A los participantes les gustó mucho la idea del juego y lo encuentran justo. • También dijeron que les gustaba la estética del juego y la interacción con

los pulsadores.

• Los equipos se divierten más cuando son varias mesas las que juegan a la vez pues se genera un ambiente de competitividad que incita más al juego.

• Durante las pruebas se pudo observar como la gente creaba estrategias, que incluían gastar más dinero, para poder seguir teniendo tiradas y jugar más.

• Nuestro cliente, el dueño del local, terminó muy satisfecho con la prueba y

desea seguir adelante con el proyecto.

El test también sirvió para probar la aplicación y defi nir cambios a rea-lizar en una línea de futuro:

• Dar una solución al tema sonido para que éste sea más potente y genere movimiento

• Las tiradas bajarán de precio, en vez de dos euros ahora serán de euro y medio

• El tiempo de espera entre tiradas también se reducirá de dos minutos a uno sólo para dar más agilidad.

• Se crearán tres pulsadores más para poder tener uno en cada mesa del bar

Gestión

Para la conducción del proyecto se trabajó con la metodología ágil de proyec-tos SCRUM. Desde el primer día que se designaron roles se comenzó a trabajar en los documentos que marcarían el avance del proyecto.

Se realizó un formato de Product Backlog con los entregables generales y un Sprint Backlog donde se podía visualizar en un mismo documento toda la información del estado actual del proyecto, así como las tareas ya realizadas y las que faltan por realizar hasta el día fi nal de la entrega.

Dentro de la tabla del SCRUM se detallaron en primer lugar los grandes blo-ques o historias que se debían realizar y a continuación, dentro de cada una de esas historias, se detallaron las tareas necesarias para que dicha historia se completara.

Durante una reunión inicial con el equipo, y una vez ya defi nida la idea que se desarrollaría se plantearon las tareas que se veían necesarias, cada miem-bro del equipo tomó las que desarrollaría y también asignó horas de dedicación para cada tarea. En conjunto con el equipo se defi nieron fechas estimadas de entregas para cada tarea de modo que no se perdiera el hilo del desarrollo y se terminaran retrasando las tareas.

Al cliente, dueño del bar, se le mantuvo informado a lo largo del proyecto del estado de la aplicación. También se comentaban con él los cambios que veíamos necesarios y se le pedían datos referentes a su local que hacían falta para el de-sarrollo de las aplicaciones TuruGame y TuruStock.

Se puede decir que tanto el equipo como el cliente terminaron el proyecto contentos, incluso se continuará trabajando en él aun después de terminar la asignatura del máster.

En cuanto al profesor, también se le mantuvo informado del desarrollo del pro-yecto y de los weekleys de las tareas SCRUM pero más de una manera informa-tiva y sobre los entregables, pues se consideraba que el cliente de la aplicación era el dueño del bar.

15

Conclusiones

El desarrollar un proyecto tan a profundidad y con tanto realismo como es llevar un cliente externo al ambiente académico nos ha nutrido mucho en la expe-riencia. Al hacer esto nos acercamos más a la realidad de la vida laboral y nos vamos preparando para nuevos retos.

Los proyectos ya no son tan personales y se han de involucrar las necesida-des y requisitos que plantea el cliente y saber lidiar con ellos para que sean en pro del proyecto.

El proyecto desarrollado se ha de decir que fue una idea ambiciosa y más considerando la dedicación que teníamos disponible, así como la implicación. Pero aún así nos ha gustado trabajar en algo tan grande pues lo desarrollaremos más en un futuro.

El principio de un proyecto más grande se comenzó a cocinar en este ejer-cicio. Como equipo tenemos el interés de seguir desarrollando el proyecto y llevarlo a producción, buscando clientes y comenzando a venderlo, pero antes hay que terminarlo de pulir.

http://www.emiliano.ws/turugame/

Recomendamos ver la página web del proyecto ya que contiene información relevante en formatos multimedia.