El jugador es un simpático robot de mantenimiento a bordo del barco que se encarga de reparar el barco ya que sufrió un accidente durante el viaje. FCD: Facultad de Comunicación y Diseño de la Universidad ORT Uruguay FI: Facultad de Ingeniería de la Universidad ORT Uruguay.
Organización del documento
El presente trabajo tiene como objetivo describir el proyecto de diplomado T-44, realizado como requisito para la obtención del título de Licenciado en Sistemas en la Universidad ORT Uruguay y realizado bajo la tutoría de la Doctora Helena Garbarino, en el periodo comprendido entre agosto de 2022. y abril de 2023. Finalmente, se detallan las actividades de SQA realizadas y las métricas establecidas, así como su evolución y análisis a lo largo del proyecto.
Motivación
El Equipo de proyecto
Juan Pedro tiene 3 años de experiencia en el campo del 3D en diversos proyectos como impresión de prototipos y piezas funcionales. Leonardo tiene 3 años de experiencia en desarrollo de videojuegos, 11 creaciones a nivel estudiantil y asistencia a diversos talleres.
Objetivos
- Académicos
- Del proyecto
- Hitos del proyecto
- Del producto
Por otro lado, en aquel momento era fundamental el conocimiento sobre Unreal Engine 5, tanto por parte de los compañeros de arte como de los desarrolladores. Afortunadamente, todos los miembros del equipo pudieron agregar horas a la carga previamente acordada para asegurar la entrega en los días 1, 2 y 3 del proyecto.
Descripción del problema
Descripción de la solución
Una nota que creemos imprescindible hacer es que una de las características especiales de este proyecto fue la cooperación entre todos los miembros desde el principio. Esto hizo que todos los miembros se apropiaran de la historia y la convirtió en un desarrollo compartido.
Modularidad
29 La solución presentada fue un corte vertical que cumplió con las expectativas de todos los miembros del equipo, con total jugabilidad y con una clara posibilidad de escalar en un tiempo mucho más limitado, teniendo en cuenta el estado actual del código y la modularidad tanto del arte como del arte. así como programación. Este recurso se utilizó únicamente en puntos concretos y medidos, ya que dependiendo de la pendiente del obstáculo podía resultar demasiado estrecho.
Propuesta de valor
También se tuvo cuidado de observar el paso del tiempo fuera de la nave, de modo que los agujeros negros, nebulosas y otros sean visibles en días diferentes. Finalmente, los acertijos se diseñaron para que resolver los problemas de la nave fuera de dificultad media para no frustrar ni aburrir a los jugadores.
Personaje principal
31 También se desarrolló un barco que era divertido de navegar con densas secciones de obstáculos que en ciertos momentos presentan desafíos para el jugador, contrastándolas con otras mucho más fáciles que le permiten concentrarse y apreciar los aspectos artísticos del barco. Finalmente, las luces que se encuentran en el lateral serán los indicadores de energía que tiene almacenado el robot, cuya funcionalidad se describirá más adelante en el documento.
Búsqueda de referencias
Se eligieron estos tres juegos porque “Portal”, Ilustración 5 y [1], es un referente en el género de los rompecabezas 3D y T-44 está fundamentalmente enfocado a ese medio. The Turing Test”, Ilustración 6 y [2], y “The Entropy Center” son dos exponentes más actuales que se definen como competidores directos porque tienen una historia similar y se dirigen a una audiencia similar.
Introducción
Proceso de Ingeniería de requerimientos
Descubrimiento y análisis
36 En particular, la modalidad de trabajo habitualmente definida por la FCD es incluir todos los requisitos del proyecto como si fuera a completarse independientemente del tiempo disponible. Luego de iniciar el trabajo y tener una idea más clara del tiempo dedicado al desarrollo, se define el avance final, que en este caso se determinó como 3 días de juego.
Documentación
Validación
Validar la funcionalidad que se implementó en el juego fue un proceso de todo el equipo. Se tuvieron en cuenta las métricas que se definirán en el capítulo de Gestión de Calidad.
Requerimientos
Actores del sistema
Jugador casual: el jugador que disfruta jugando videojuegos, pero que no se toma demasiado en serio su experiencia de juego. Coleccionista: El jugador que se dedica a coleccionar objetos en los videojuegos, como armas raras, trajes especiales o logros difíciles de conseguir.
Requerimientos funcionales
Los requisitos RF28-RF30 describen la iluminación en el borde de los objetos con los que el jugador debe interactuar. Los requisitos de RF78-RF81 corresponden al movimiento de la cámara que sigue el movimiento del robot.
Principales funcionalidades
En la puerta de la sala de carga y parte del pasillo hubo que introducirlo. Después de resolver el rompecabezas de las olas, el jugador tenía que ir a la barrera en el pasillo de la sala de llenado e interactuar con ella.
Requerimientos no funcionales
Una funcionalidad oculta es la posibilidad de transportarse desde la sala de control a la cocina a través de un túnel secreto. A diferencia de los sistemas informáticos clásicos donde, a pesar de no cumplir un requisito no funcional, el usuario aún puede utilizar la herramienta, en un videojuego, si no se cumple un requisito no funcional, puede incluso provocar que el usuario no pueda abre el juego.
Diagramas de secuencia
88 Como se puede ver, esta característica solo se activa una vez que el jugador ha completado completamente el Día 1 y ha resuelto el segundo conjunto de fusibles; de lo contrario, el jugador no podrá pasar al día siguiente. Como se ve en la ilustración reciente, esta característica solo se activa cuando el jugador presiona el botón de pausa y presenta algunas transmisiones alternativas.
Introducción
Análisis de requerimientos no funcionales
El 91% de la capacidad se destina a diseños arquitectónicos del mundo virtual, es decir, a todos los componentes gráficos y sólo el 10% a codificación. Si bien se hizo una reducción para permitir una jugabilidad un poco más fluida, puede que no haya sido suficiente para satisfacer a todos los jugadores.
Decisiones de diseño
Definición de estándares y buenas prácticas de codificación
Las buenas prácticas también promueven la seguridad y principalmente la escalabilidad del software, al reducir la vulnerabilidad a ataques y hacer crecer el software de manera ordenada y estructurada. Para este proyecto, en primer lugar se estudiaron y siguieron las buenas prácticas recomendadas por la propia plataforma UE5 en su página web [3].
Patrones arquitectónicos
34;BP_EngineeringBaseObject" que contiene métodos y propiedades comunes a todos los objetos interactivos en la sala de ingeniería, como un "BoxCollision", un "Widget" y funciones de interacción. Con esta técnica también podemos definir la funcionalidad de cada clase hija de una forma sencilla. extenderse, ya que los métodos y propiedades de la clase base simplemente se heredan.
Herramientas y tecnologías de desarrollo
Listado de herramientas y tecnologías
Justificación de herramientas y tecnologías
Por otro lado, Substance Painter es una herramienta utilizada para el diseño de texturas y su uso también es común en la industria. 102 Específicamente para el seguimiento del tiempo, utilizamos Clockify, una herramienta de seguimiento del tiempo en línea que ofrece varios beneficios a los usuarios.
Vistas
- Estructura de paquetes
- Vistas de comportamiento
- Diagrama de entidades
- Diagrama de despliegue
105 En el paquete "Personajes": están todos los proyectos, materiales, animaciones, mallas, dispositivos, entre otros que le dan forma y "vida" al robot. En el paquete "Nivel": se encuentran todos los planos, mallas, texturas y objetos interactivos para todo el nivel del juego.
Introducción
Atributos de la jugabilidad
Modelo de jugabilidad
Factores de jugabilidad
Como se menciona en este trabajo, y se puede observar en la Ilustración 55, todo lo relacionado con los videojuegos gira en torno a una buena experiencia de jugador. Otros autores proponen la inmersión como un factor independiente de la jugabilidad, separándola de la eficiencia tal y como se define en este trabajo.
Introducción
Objetivos del producto
Objetivos académicos
116 Que este documento contiene toda la información necesaria para la comprensión de la solución desarrollada por profesores, evaluadores y otros estudiantes y está disponible en la fecha de entrega. Lograr la correcta aplicación de los conocimientos adquiridos sobre el proceso del software durante el curso (Licenciatura en Sistemas) para generar un producto de calidad que cumpla con los requisitos de nuestros compañeros de arte y las expectativas del grupo objetivo: los jugadores, y pueda ser entregado en tiempo y forma.
Objetivos del proceso
Aseguramiento de la calidad (SQA)
Para alcanzar los objetivos descritos anteriormente y teniendo en cuenta lo establecido en la norma UNE-EN ISO, el equipo ha desarrollado dos planes de calidad, uno para el proceso de ingeniería y otro para el proceso de gestión. Estos planes de calidad, presentes en los anexos, se definieron en la fase de planificación y fueron controlados y monitoreados durante todo el proyecto.
Principales actividades de SQA
Testing
Al hacer clic en el botón de reanudar el juego se desactiva el menú de pausa y el jugador recupera el control del juego. Al hacer clic en el botón de salida del menú principal, volverá al menú principal.
Definición de métricas
Introducción
130 En resumen, las mediciones de calidad del software son una herramienta clave para garantizar que el software cumpla con los estándares de calidad y funcionalidad esperados por los usuarios y clientes, y para establecer objetivos claros y mensurables para el desarrollo de software, permitiendo evaluar el progreso y la calidad del proyecto.
Métricas de proceso
Con base en la experiencia de medición de historias de Victoria y Renso, se estimó que el esfuerzo promedio de cada miembro sería de 8 puntos de historia por semana. Para esta métrica, no tomamos en cuenta un número promedio de tareas por miembro porque cada tarea tiene su propio valor en puntos de historia.
Métricas de jugabilidad
Quizás en un tipo de juego diferente, que tenga una mayor cantidad de funcionalidades, ciertos tipos de errores por sí solos no afectan la continuidad del juego. En nuestro caso, si los errores existen en los rompecabezas o puertas, el jugador no puede continuar. En el juego estos puntos de referencia tan exigentes se definen por este motivo. Nos gustaría incluir en nuestra encuesta un campo para obtener información sobre el nivel de juego de cada jugador, esto serviría para medir cómo es la experiencia de un jugador experto y qué tan eficiente es, en comparación con la experiencia y efectividad de un nuevo jugador.
Evolución y análisis de métricas
Resultado de las métricas de Proceso
La siguiente ilustración presenta un cuadro comparativo entre los hitos estimados al inicio del proyecto y los obtenidos al final. A continuación se presentan los resultados obtenidos respecto al número de tareas existentes en el backlog.
Resultado de las métricas de Jugabilidad
145 Considerando que 22 personas participaron en la encuesta, el número promedio de acertijos resueltos por jugador nos da un punto de referencia. La suma total de satisfacción por usuario es y dado que en la encuesta participaron 22 personas, la satisfacción promedio por jugador es una medida dentro del rango aceptable definido al inicio.
Metodología de gestión de proyecto
En nuestro caso, el equipo FCD estará más específicamente a cargo de las tareas del track de descubrimiento y de las tareas FI del track de implementación. Como se muestra en la Ilustración 61, la ruta de descubrimiento debe tener una iteración antes de la ruta de implementación para que comience a funcionar y esto será demostrado por el Gantt creado.
Metodología del proceso de construcción de software
- Roles
- Roles y responsabilidades
- Artefactos
- Ceremonias
A continuación, en la Tabla 51, se detallan los roles de cada uno de los miembros del equipo. Es responsable de especificar y verificar los requisitos funcionales y no funcionales del proyecto.
Gestión del tiempo
- Definición de actividades
- Estimación de recursos y duración
- Desarrollo del cronograma
- Etapas del proyecto
- Disponibilidad del equipo
Como puede ver en la Figura 62, el número total de horas dedicadas al proyecto fue 2213. La Figura 65 EDT muestra la distribución de las fases del proyecto en una EDT.
Gestión de Riesgos
Planificación de los riesgos
Otro riesgo para el medio ambiente es la falta de experiencia en programación de videojuegos y UE5 por parte de los desarrolladores. Además de los cursos de los miércoles, hay comunicación continua con el tutor de FCD a través de Discord.
Resultado de evaluación de riesgos
Desafortunadamente vemos que tanto en este proyecto como en la industria de los videojuegos, el tema de la estimación del tiempo es un desafío. Mala reputación: si el juego es de baja calidad, es probable que la reputación de la empresa (o grupo de creadores) se vea empañada, lo que puede hacer que los usuarios tengan menos confianza en sus futuros productos.
Gestión de las comunicaciones
Comunicación interna
Aunque al principio teníamos claro que no podían durar más de 15-20 minutos, tuvimos algunas ocasiones en las que duraron hora y media. En los registros, sin embargo, nos centramos en asegurarnos de que el proyecto avanzaba y que nadie se quedaba sin poder avanzar.
Comunicación externa
Esto propició un mejor uso del tiempo, aunque fue algo en lo que tuvimos que trabajar durante todo el proyecto. Nos permitió hacer preguntas específicas en varias ocasiones, compartir lecciones y también tener tres sesiones de consulta durante el proyecto.
Resultados de los Sprints
- Sprint 0
- Sprint 1
- Sprint 2
- Sprint 3
- Sprint 4
- Sprint 5
- Sprint 6
- Sprints 7 y 8
Además, se implementó la primera versión de la colección de coleccionables, en este sprint también se realizó la integración de la animación de nanobot iniciada en el sprint anterior, entre otras actividades. La velocidad de este sprint fue 44, por lo que estuvo bastante cerca de la velocidad esperada.
Introducción
187 Hay que tener en cuenta que en varias ocasiones hubo conflictos de Git que demandaron mucho tiempo, sobre todo por rework de algunos de los integrantes. Creemos que si continuamos con este trabajo, deberíamos seguir explorando las posibilidades de trabajar de una manera más eficiente.
Control de versiones
Repositorio
La primera es la falta de experiencia en el desarrollo de videojuegos entre los desarrolladores. Disponible: https://es.slideshare.net/SECiVi/cosecivi14-jugabilidad-como-medida-de-calidad-en-el-desarrollo-de-videojuegos.
Requisitos Funcionales
T-44
GDD
Registro de horas clockify
Plan de calidad del proceso de ingeniería
Plan de calidad del proceso gestión
Distribución de horas y actividades sprint 7 y 8
Resultados encuesta número 1 (al finalizar la sprint 2)
Resultados encuesta número 2 (al finalizar la sprint 6)
Imágenes Trello
Link para descargar el videojuego
Link para visualizar el trailer
