Capítulo 5 Evaluación con usuarios

En las fases finales del desarrollo se llevaron a cabo pruebas con usuarios que no habían tenido contacto previo con la herramienta. Una vez el catálogo estuvo implementado, se desarrolló un plan de pruebas para probar si el diseño de la herramienta planteado es correcto, e identificar posibles cambios y mejoras. En este capítulo se recogen los objetivos de las pruebas, se analizarán los resultados obtenidos y se sacarán conclusiones al respecto.

5.1 Objetivos de las pruebas

Previo a las pruebas con usuarios, se definieron una serie de objetivos para la evaluación. Estos objetivos, descritos a continuación, están diseñados para cubrir los fundamentos principales del catálogo de componentes y orientar las pruebas para que respondan a estas cuestiones.

Objetivos de las pruebas

• Valorar la usabilidad del estado actual de la herramienta como catálogo para diseñar enemigos.
• Evaluar si el nivel de configuración de los componentes que constituyen el catálogo es correcto.
• Averiguar si faltan componentes o si, por el contrario, algún componente se podría retirar del catálogo.

Para definir estos objetivos, es importante recordar la fase de diseño del Capítulo 3 donde se analizaron los enemigos del videojuego Cave Story, se definieron los componentes de este catálogo y, de forma teórica, se demostró su funcionamiento creando enemigos con el catálogo. El objetivo de la herramienta es que cualquier persona pueda construir enemigos de forma sencilla, por ello las pruebas se orientaron a replicar comportamientos de enemigos clásicos con los componentes y sensores implementados.

5.2 Organización de las pruebas

Debido a la pandemia mundial que tuvo lugar durante la publicación de esta memoria debido al virus SARS-CoV-2, conocido como Coronavirus, la planificación del trabajo y las pruebas con usuarios de vieron modificadas. Inicialmente se iba a probar la herramienta de forma presencial y posiblemente con un número más elevado de probadores. No obstante, las pruebas se han realizado de forma online, mediante una videollamada individual con cada probador. Las pruebas tenían una duración de unos treinta y cinco a cuarenta minutos.

En la fase previa, tras una introducción, se le explicaba al probador brevemente los com­ponentes que va a manipular, usando la guía visual de referencia con los comportamientos que deberían esperar y garantizarle asistencia durante la prueba para resolver dudas o errores que pudieran surgir. La guía visual puede consultarse en el Apéndice B, y consta de dos páginas. Para evitar sobrecargar al probador al principio, les recomendaba centrar su atención en la primera página (Figura B.1) en la que se ilustran los tipos de movimien­tos básicos que iban a usar al principio, y con eso delante se les explicaba brevemente los componentes así como se les solucionaba alguna duda que pudieran tener. Cuando el pro­bador había realizado entre tres o cuatro comportamientos básicos, pasaba a introducirles las combinaciones de los mismos. Eran combinaciones sencillas, siguiendo la tabla de la Figura 4.10, y no se les avisaba de que tenían que combinar dos sencillos explícitamente, para ver si se entendía que algunos comportamientos eran combinables. Finalmente, se les introducía sensores a los comportamientos a replicar. Era entonces cuando se les dirigía a la segunda página, en la Figura B.2 y, de nuevo, se les explicaba brevemente o les resolvía cualquier duda que tuvieran al respecto. Para la explicación inicial no hace falta entrar en detalle, puesto que la guía visual aporta el conocimiento necesario para empezar a utilizar la herramienta. Esto se realizaba mientras abrían el proyecto y se instalaba el paquete vacío con todo lo necesario, así se aprovechaba el tiempo.

Durante las pruebas se pedía a los probadores una serie de comportamientos, entre siete y ocho, para que los replicaran con la herramienta. No se le mencionaban los nombres de los componentes, sino que las tareas se presentaban en forma de descripciones de enemigos clásicos de videojuegos 2D. Con la descripción de lo que tiene que hacer en enemigo, y los datos que proporciona la guía, el objetivo era que el probador crease un comportamiento aproximado. Por lo general, existe una forma rápida y directa de obtener ese resultado que es usando el componente correcto, no obstante había veces que el comportamiento era muy aproximado como para considerar que la tarea había resultado errónea. Por ejemplo, uno de los probadores decidió utilizar un comportamiento Floater (Figura 4.6) horizontal para cubrir una plataforma sin caerse, lo que según el diseño original se puede resolver con un Pacer. En este caso, ambos comportamientos cumplen con la descripción propuesta de que el enemigo debe recorrer la plataforma, teniendo en cuenta que al llegar al extremo ha de darse la vuelta así que se daba por válido.

Durante la prueba, se les respondía a las dudas que tuvieran y, para que los probadores no sintieran que estaban siendo examinados, se les dejaba experimentar con la herramienta como quisieran aunque eso supusiera una desviación en las pruebas. Debido al reducido nú­mero de probadores, y a que las pruebas se hacían de forma online, las pruebas se diseñaron a mano y se personalizaron en función de los grupos componentes que funcionaban bien juntos. No obstante, todas las pruebas con usuarios siguieron el mismo patrón: al principio, se describían componentes sencillos, luego se introducía una combinación de algunos com­ponentes previamente vistos y finalmente introducían comportamientos de enemigos con sensores. Al principio de la prueba, se elegía un grupo de descripciones de comportamientos para la prueba de forma aleatoria entre todas las pruebas diseñadas que no se hubieran utilizado. No obstante, si durante el transcurso de las pruebas con el usuario iban fluidas, se hacían menos pruebas de componentes sencillos y daba el salto a cosas más complejas mientras que en caso contrario incidía más en los comportamientos para intentar identificar los problemas de base en la herramienta.

Para extraer los resultados se ha utilizado un cuestionario sencillo, de apenas 3 minutos, en el que se recoge lo más importante de cara a generar unas gráficas que respondan a las preguntas principales definidas en los objetivos. Las preguntas eran de escala numérica, donde la escala medía el nivel de acuerdo con la frase de la pregunta. Estaba valorado de tal manera que el 1 significaba un desacuerdo absoluto con la afirmación planteada, mientras que un 5 significaba un acuerdo absoluto con la afirmación. El cuestionario era totalmente anónimo, y antes de mandar el formulario se les pedía que dejasen de compartir pantalla para no ver lo que respondían. Por supuesto, todos los probadores realizaron el mismo cuestionario por lo que los datos reflejan la opinión y crítica de los probadores de forma conjunta.

5.3 Resultados de las pruebas

Los experimentos con la herramienta se realizaron a lo largo de una semana, y todos los usuarios utilizaron el mismo paquete de Unity con el mismo catálogo de componentes. Lo único que se modificaba entre versiones del paquete era la corrección de los errores que pudieran tener algunos de los componentes y que entorpecían el correcto desarrollo de las pruebas.

En total, este experimento ha contado con diez probadores que se han ofrecido volunta­riamente a probar la herramienta. Para buscar probadores se utilizó la red social Twitter, y el director de este TFG, por su parte, difundió la herramienta por los foros de las asigna­turas que imparte. Al contar con probadores que vengan de redes sociales se ha observado como algo positivo que la disposición a hacer pruebas y la curiosidad por la herramienta surge de ellos. A pesar de no tener un gran número de pruebas se han obtenido unas opi­niones más variadas que si hubiera seguido el plan de pruebas que se pensó inicialmente con un gran número de alumnos del grado, donde los comentarios sobre la herramienta hubieran sido mucho más homogéneos.

Los probadores que se han ofrecido a probar esta herramienta tienen distintos niveles de conocimiento en el desarrollo de videojuegos y por tanto se pueden englobar en dos conjuntos:

• Noveles: Este grupo está compuesto por 2 alumnos de primer año del Grado en De­sarrollo de Videojuegos en la Universidad Complutense, estudiantes que están apren­diendo los fundamentos de la programación y el desarrollo de videojuegos por lo que suponen un público objetivo de la herramienta. Tienen un conocimiento aproximado acerca de la programación, pero son un grupo que no tiene experiencia real aún. Se incluye en este grupo a una diseñadora del Grado en Diseño, por la facultad de Bellas Artes de la Universidad Complutense que, a pesar de no contar con conocimientos de programación, ha utilizado Unity en diversas asignaturas. Este grupo de 3 personas supone un público objetivo porque este catálogo debería resultar sencillo de utilizar por usuarios sin conocimientos de programación.
• Veteranos: He podido contar con 5 personas de últimos años del Grado en Desarrollo de Videojuegos y que, por tanto, tienen más conocimiento y experiencia en el campo del desarrollo de videojuegos. Se incluyen en este grupo, además, 2 personas veteranas de la industria, con varios juegos lanzados al mercado y experiencia trabajando con herramientas para el desarrollo de videojuegos. Es interesante contrastar las opiniones de este grupo con las opiniones del conjunto de probadores noveles para entender qué se esperaría de este catálogo desde un punto de vista más profesional.

Las opiniones de este segundo grupo, más mayoritario, son especialmente interesantes porque son personas que cuentan con una experiencia mucho mayor en el desarrollo de videojuegos y por tanto, pueden criticar el proyecto no desde un punto de vista académico sino como una herramienta que pueda salir al mercado, valorando la usabilidad y el nivel de acabado como personas que usan herramientas similares en su día a día.

Respecto al nivel de utilidad a nivel teórico, en la pregunta del cuestionario acerca de lo útil que resulta la herramienta se aprecia que la impresión general acerca de la idea de hacer un catálogo de comportamientos llama mucho la atención. Como se indica en la Figura 5.1, un 90% (9 de 10) de los probadores coinciden en que la herramienta funciona como catálogo de componentes, con un 70 % calificándolo con la mejor puntuación, lo que deja en manifiesto el enorme potencial que tiene este proyecto como herramienta para crear movimientos enemigos en dos dimensiones, y augura un buen futuro a la herramienta si se ampliase su utilidad.

Figura 5.1: Utilidad de la herramienta

Un objetivo de las pruebas era evaluar si la herramienta es accesible, es decir, que sea rápida y sencilla de utilizar por cualquier persona independientemente de su nivel de experiencia con ella. Idealmente, una persona que prueba la herramienta por primera vez y que, por tanto, no conozca nada sobre ella pueda aprender a usarla y construir su primer enemigo rápidamente. Para ello se desarrolló la guía visual (Figuras B.1 y B.2), con la idea de que sirviera como documentación tanto para aprender a utilizar la herramienta como para refrescar su contenido.

La herramienta resulta sencilla de aprender a usar, pero no todo lo que hubiera resultado deseable. En este caso, la interpretación que se le da a los resultados tan variados, como se aprecia en la Figura 5.2, acerca de por qué no ha resultado tan sencilla de utilizar se debe a los estándares de cada perfil de probador. Un factor determinante es que la guía visual resultaba útil, pero era un arma de doble filo porque si generaba confusión inicial, la primera impresión de la herramienta podría resultar frustrante. La crítica elaborada a la guía visual está al final del Apéndice B.

Durante las pruebas, se observó que los alumnos de primer año del grado utilizaban la herramienta de forma correcta una vez veían los componentes funcionar en ejecución lo cual no es negativo, ya que no se considera que el ensayo y el error sea algo a evitar al utilizar esta herramienta. No obstante, cuando se les presentaban las primeras descripciones, el proceso de saber qué comportamiento utilizar era más lento, y la gran mayoría fallaba en su primer intento. Esto pasaba también con alumnos de los últimos años del grado, pero en menor medida debido a la experiencia previa y a que contaban con una formación en programación. Para los probadores veteranos de la industria, la usabilidad de la herramienta no cumplía con los estándares que ellos utilizarían en el día a día, y me inspiraron a hacer modificaciones como la integración con Unity que se ve en la Figura 4.3.

A pesar de la diversidad de opiniones que observamos en la Figura 5.2 acerca de lo fácil que es empezar a utilizar la herramienta, que se podría calificar como buena, pero no sobresaliente, se extrae de la Figura 5.3 un punto positivo que es que a pesar de que la herramienta pueda tener una dificultad de entrada más alta que lo previsto, la herramienta no genera frustración cuando se utiliza. Un 60 % de los encuestados afirma que están en desacuerdo con la afirmación de que la herramienta les parece frustrante, pero un 30 % han sentido algo de frustración al utilizarla, presumiblemente por esas primeras interacciones con la herramienta.

Figura 5.2: Sencillez de la herramienta

Figura 5.3: Frustración generada por la herramienta

Otro aspecto problemático que perjudica la usabilidad de la herramienta son los nom­bres de los componentes. Los nombres utilizados no son casualidad, sino que siguen un estándar inspirado en el artículo de Bright (2014) acerca de los componentes sencillos para enemigos en dos dimensiones, que se trata al inicio de este mismo Capítulo. Son nombres en inglés, siguiendo con los estándares comentados en el Capítulo 1 de que la herramienta tenía que ser íntegramente en inglés, pero no considero que eso haya sido un factor tan importante.

Como se aprecia en la Figura 5.4, los nombres que dado a cada uno de los componentes no son auto explicativos. Por ejemplo, uno de los nombre que han generado más confusión es Bullet. El componente Bullet se mueve en línea recta en una dirección simulando el mo­vimiento de una bala, pero era muy confundido con el componente Liner por su asociación a «línea», a pesar de que Liner es un componente de movimiento lineal hacia el jugador. De nuevo, la guía visual supone un arma de doble filo porque, aunque es rápida de con­sultar, no se incluyen los atributos que tiene cada componente y aunque eso suponga una documentación más extensa ayudará a entender mejor de qué es capaz cada componente. Los probadores más veteranos, tanto los del perfil de industria como los de último año del grado, tienen a prestar más atención a los atributos públicos de ha herramienta, pero otro elevado porcentaje de probadores ignoran los atributos.

Figura 5.4: Claridad de los nombres

Figura 5.5: Personalización de los atributos

Un aspecto más positivo sobre los componentes ha sido que el nivel de personalización que presentaban los componentes en general ha sido bastante positivo. Como se aprecia en la Figura 5.5 con un 50 % de los probadores clasificándolo como adecuado. No obstante, no se puede ignorar que un 30 % de los probadores lo han considerado mejorable. Durante las pruebas, observé que algunos de los probadores más veteranos echaban en falta un nivel de personalización más avanzada en algunos componentes.

Cuando los probadores más veteranos manipulaban los comportamientos de movimiento que implicaban conocer la posición del jugador, encontraba que había usuarios que echaban en falta poder definir un objetivo del movimiento distinto al jugador. Por ejemplo, cuando utilizaban el componente Follower que persigue al jugador se planteaban la opción de que el enemigo pudiera perseguir otro objeto, asignable desde el editor. Cuando se les preguntaba acerca de esta cuestión a los probadores más noveles, mencionaban que no lo echaban tanto en falta.

Otro punto de la herramienta que podría mejorarse, en relación a la Figura 5.5 es la configuración de los sensores. Actualmente, los sensores son un elemento muy simplificado y automático, tanto que se encarga de recoger manualmente todos los componentes de movimiento asignados al objeto y, por defecto, los desactiva hasta que el sensor detecte al jugador. Un probador de primer año del grado me planteó la cuestión de si podía crear un objeto que se mueva al principio de la ejecución y que, si el sensor se activa, incorpore un movimiento extra a su ruta. Con la implementación actual no sería difícil crear ese sistema, pero sería recomendable contar con el editor visual antes de integrar esa funcionalidad.

Lo que se extrae de la Figura 5.5 es que aún es preciso afinar los atributos públicos de los componentes, intentando apelar tanto a los usuarios más conformistas como a los usuarios que desean un nivel de personalización mas elevado, propio de una herramienta más sofisticada.

En resumen, la idea del catálogo de componentes cumple con sus objetivos principales de ser una herramienta sencilla e utilizar y capaz de construir enemigos personalizables rápidamente. Se podría calificar esta primera implementación como positiva, pero es im­portante corregir los nombres de los componentes así como crear una documentación mejor al margen de la Guía Visual (Apéndice B) que ayude a solventar las dudas que surjan al utilizar la herramienta por primera vez. Finalmente, sería interesante añadir una ventana más visual a la herramienta, para separar el catálogo del editor y así tener un mayor control sobre cómo se presenta la información.

La evaluación con usuarios es un componente crucial en el desarrollo y mejora de los videojuegos. Proporciona información valiosa sobre la experiencia del usuario, identifica áreas de mejora y valida el diseño y la jugabilidad:

1. Objetivos claros:
   • Define claramente los objetivos de la evaluación. ¿Estás buscando retroalimentación sobre la jugabilidad, la interfaz de usuario, la historia, o algún otro aspecto específico?
2. Selección diversa de usuarios:
   • Involucra a una variedad de usuarios representativos del público objetivo. Esto incluye a jugadores casuales, jugadores expertos y cualquier otro segmento de usuarios que pueda estar destinado a tu juego.
3. Prototipos y versiones de prueba iterativas:
   • Realiza pruebas a lo largo del proceso de desarrollo, desde prototipos tempranos hasta versiones más avanzadas. Esto permite realizar ajustes a medida que evoluciona el juego.
4. Métricas cuantitativas y cualitativas:
   • Combina métricas cuantitativas, como tiempos de juego, tasas de éxito y otras métricas analíticas, con comentarios cualitativos de los usuarios para obtener una comprensión más completa de la experiencia.
5. Observación directa y retroalimentación en tiempo real:
   • Observa a los usuarios mientras juegan para captar reacciones genuinas. Además, solicita retroalimentación en tiempo real para obtener información instantánea.
6. Encuestas y entrevistas post-prueba:
   • Después de cada sesión de juego, realiza encuestas o entrevistas para profundizar en la experiencia del usuario. Preguntas abiertas pueden revelar percepciones y aspectos no anticipados.
7. Iteración basada en resultados:
   • Utiliza los hallazgos de las evaluaciones para realizar iteraciones en el diseño. Ajusta aspectos como la dificultad del juego, la interfaz de usuario, la narrativa, etc., según las necesidades y comentarios de los usuarios.
8. Consideraciones de accesibilidad:
   • Asegúrate de incluir usuarios con diferentes niveles de habilidad y experiencia. Además, ten en cuenta las consideraciones de accesibilidad para garantizar que el juego sea inclusivo para todos.
9. Confidencialidad y consentimiento:
   • Garantiza la confidencialidad de los datos recopilados y obtén el consentimiento informado de los participantes antes de llevar a cabo las pruebas.
10. Análisis de tendencias y patrones:
    • Identifica tendencias y patrones en los comentarios y resultados de las pruebas. Esto puede ayudar a priorizar áreas clave para mejorar.