Magic The Serverlessling

Facultad de Inform´atica Trabajo de Fin de Grado Magic The Serverlessling Por Rodrigo Tobar Guill´en Dirigido por Jos´e Luis V´azquez Poletti David Pacios Izquierdo MADRID, 2023–2024 ii Agradecimientos En primer lugar, quiero agradecer todo el apoyo que me han dado Jos´e Luis V´azquez Poletti y David Pacios Izquierdo, tutores de este trabajo. Gracias a su labor este proyecto ha alcanzado todo su potencial, lo cual no habr´ıa sido posible sin ellos. Adem´as, quiero reconocer la labor de la Secretar´ıa de Estudiantes y del Vicedecano de Ordenaci´on Acad´emica e Innovaci´on Docente Adri´an Riesco Rodr´ıguez. Gracias a su esfuerzo por ayudar a los estudiantes de la facultad ha sido posible solucionar todos los problemas administrativos que he tenido. Por ´ultimo, agradecer a mi familia y amigos que se han interesado por el proyecto y su desarrollo. Su inter´es y apoyo me han impulsado a la hora de realizarlo lo mejor posible. iii iv Abstract Magic: The Serverlessling is an online multiplayer game based in the popular TCG Magic: The Gathering. With a simplified set of rules and a reduced number of cards, casual players will be able to familiarize with the game while they play with their friends. In addition, the internal structure of the game has been totally developed using serverless computing, being one of the project’s objectives acting as a case study in order to analyze feasibility of this technology as a game/application development tool. Keywords: Videogame, Serverless, AWS, Lambda, S3, Card Game, Efficiency Analysis. v vi Resumen Magic: The Serverlessling es un juego multijugador en l´ınea basado en el popular juego de cartas Magic: The Gathering. Con reglas simplificadas y un n´umero reducido de cartas, los jugadores m´as casuales podr´an familiarizarse con el juego mientras juegan con sus amigos. Adem´as, la estructura interna del juego se ha realizado en su totalidad mediante computaci´on sin servidor, siendo uno de los objetivos de este proyecto actuar como caso de estudio para analizar la viabilidad de esta tecnolog´ıa como herramienta de desarrollo de videojuegos y aplicaciones. Palabras Clave: Videojuego, Serverless, AWS, Lambda, S3, Juego de cartas, An´alisis de eficiencia. vii viii ´ Indice general Abstract ......................................................... V Resumen ........................................................ VII Cap´ıtulo 1 Introduction ....................................... 1 Cap´ıtulo 1 Introducci´on ....................................... 3 Cap´ıtulo 2 Estado del Arte .................................... 5 Cap´ıtulo 3 Metodolog´ıa y Tecnolog´ıas..........................15 Cap´ıtulo 4 Desarrollo del Proyecto ............................. 23 Cap´ıtulo 5 Resultados y Discusi´on ............................. 45 Cap´ıtulo 6 Conclusiones y Trabajo a Futuro .................... 49 Cap´ıtulo 6 Conclusions and future applications ................. 53 Cap´ıtulo A Anexo: Manual de Instalaci´on ...................... 57 Bibliograf´ıa ...................................................... 62 ix 6 2.2. Magic: The Gathering Online Figura 2.1: Magic: The Gathering Online MTGO es la versi´on online de Magic. Lanzado en 2002, este juego permite a los jugadores jugar entre ellos en cualquier momento a trav´es de su ordenador. Si bien esta opci´on elimina parte del factor social que tiene jugar en persona, es apreciado por los jugadores debido a la oportunidad que les brinda este servicio de poder jugar en cualquier momento y con un gran y variado n´umero de personas con mazos diferentes. Otra de las ventajas de este servicio es la automatizaci´on de las acciones, lo que evita errores o trampas por parte de los jugadores. Sin embargo, esto a˜nade problemas adicionales como el de los errores mec´anicos, como pasar de fase por un click err´oneo, lo cual no puede pasar en el formato f´ısico. Este sistema est´a basado en servidores convencionales. Para pagar los costes de mantenimiento y conseguir beneficios, el juego tiene una econom´ıa propia; para jugar torneos competitivos hacen falta ”t´ıckets”. Estos se pueden comprar a Wizard of the Coast por 1$. Como hay muchos jugadores interesados en jugar los torneos, los t´ıckets tienen una amplia demanda, y dado que son transferibles entre cuentas, se pueden usar como moneda de cambio. Esto permite a los jugadores intercambiar sus cartas por t´ıckets, propiciando que los consigan para comprar cartas, jugar torneos, etc. Adem´as, existen mercados secundarios en los que se pueden vender a un precio algo menor que el oficial, permitiendo al usuario liquidar los bienes que tenga dentro del juego[3]. Dicha posibilidad insta a los interesados en el juego a meterse en ´el y participar en los eventos, ya que al igual que pasa en el juego f´ısico, tienen la capacidad de recuperar parte de su inversi´on en cualquier 7 momento[4]. Como a˜nadido para incentivar a´un m´as la adquisici´on de cartas, Wizards of the Coast puso en marcha un sistema por el cual si un jugador obtiene una colecci´on completa de cartas digitales, a cambio de unas tasas puede canjearla por esa misma colecci´on completa en formato f´ısico. Esto permite liquidar los bienes digitales y permutarlos a activos f´ısicos de forma totalmente oficial, lo cual inspira confianza en gente que quiera ingresar dinero en la plataforma. 2.3. XMage XMage es un proyecto independiente que habilita a los jugadores de Magic el poder jugar al juego de forma online con otros jugadores en multitud de formatos distintos y con todas las cartas disponibles de forma gratuita. Al no estar reconocido de forma oficial no dispone de una cantidad de jugadores tan elevada como la de Magic Online o Magic Arena, los cuales s´ı son de car´acter oficial, pero algunas personas lo usan para poder disfrutar de la experiencia de juego sin tener que adquirir las cartas que necesitan. En ese sentido este proyecto tiene cierta similitud, ya que no se quiere poner ninguna barrera de entrada econ´omica. Una vez que el usuario crea una cuenta gratuita, puede ir a una secci´on de creaci´on de mazos en las que podr´a confeccionar lo que dese´e, aunque solo podr´a usar sus mazos en aquellas partidas que trascurran en formatos compatibles con dicho mazo. Una de las opciones es exportar la lista de cartas para que cualquier persona pueda importarla en su cuenta r´apidamente. Al igual que este proyecto, XMage existe en formato de aplicaci´on, con lo que el usuario descarga un cliente de forma local. Sin embargo, una diferencia clave es que XMage s´ı usa servidores convencionales para mantener su multijugador en l´ınea; tienen un servidor para Estados Unidos y otro para Europa, alojados en centros de datos de Nueva York y Alemania respectivamente. Para lidiar con los costes de mantenimiento de los servidores piden a los jugadores apoyo econ´omico mediante la plataforma de mecenazgo Patreon. 2.4. Cockatrice Cockatrice es un programa multiplataforma de c´odigo abierto que permite simular partidas de Magic entre varios jugadores. Si bien pretende imitar de forma m´as fiel algunos aspectos del juego presencial, el dise˜no del programa impide que los jugadores se aprovechen del sistema para obtener una ventaja injusta, bas´andose este sistema en el uso de servidores convencionales. Si 8 bien es una herramienta que varios jugadores han usado desde su creaci´on, el mantenimiento de este servicio tiene algunas desventajas. Seg´un datos sacados de su p´agina oficial, de los tres servidores que hab´ıa vigentes ya solo queda uno de ellos activo. Adem´as, este ´ultimo servidor parece tener una gran carga de jugadores. Por otra parte, en la misma p´agina se piden donaciones, y se indica que estas son necesarias debido a que el coste de mantenimiento mensual es de unos 100$, siendo este bastante elevado. Como a˜nadido, cabe destacar que el cierre de dos de los tres servidores puede ser un indicativo de que el sistema de donaciones fue insuficiente a la hora de amortizar los costes. 2.5. YouRuleYouRole YouRuleYouRole[5] es un servicio online pensado para alojar partidas de rol online creado por ´ Alvaro Rodr´ıguez-Peral Bustos. Permite a los organizadores de partidas desarrollar escenarios o situaciones seg´un consideren y de forma sencilla, pudiendo ser jugados m´as adelante por los jugadores que el organizador considere. Este proyecto nace a ra´ız de la complejidad de reunir en un espacio f´ısico y un momento determinado a la cantidad de personas suficientes como para jugar una campa˜na de rol. Gracias a YouRuleYouRole, es m´as sencillo realizar una partida, ya que los jugadores no tienen que desplazarse hasta un sitio concreto, ahorrando bastante tiempo en el proceso y aportando a su vez una gran comodidad. De hecho, en ciertos casos en los que por alg´un motivo los jugadores no pueden juntarse, una herramienta como esta puede llegar a posibilitar la partida que de otra forma no podr´ıa haber tenido lugar. Este servicio est´a construido con tecnolog´ıa Serverless en su totalidad, us´andose los siguientes servicios de AWS: 1. El funcionamiento del servicio y toda la l´ogica se manejan a trav´es de funciones AWS Lambda. Estas se han atomizado todo lo posible con el fin de que fueran extremadamente ´optimas, ya que al ser un juego online este requiere de cierta fluidez para ser disfrutable. El otro motivo es que el coste de mantenimiento del servicio est´a determinado casi en su totalidad por el tiempo de ejecuci´on y el espacio asignado a las funciones. 2. Dichas funciones son llamadas cuando es oportuno mediante API Gateway; los clientes mandan una petici´on a una API Rest y es la API la que hace las llamadas a las distintas funciones. De esta forma la API Rest act´ua como intermediario entre los clientes y la l´ogica Serverless 9 de las funciones. 3. Toda la informaci´on del servicio as´ı como de las partidas que est´an en juego se encuentra alojada en una base de datos en forma de un sistema de ficheros en un Bucket S3. Si bien en la documentaci´on se explica que una alternativa era usar DynamoDB, se opt´o por S3 por dotar al proyecto de una mayor flexibilidad, pues al guardar y procesar toda la informaci´on en archivos de texto plano es mucho m´as f´acil reinventar el sistema o transportarlo a un entorno distinto, ya que ese tipo de archivo tiene una mayor compatibilidad que las tablas de DynamoDB, que son propias exclusivamente del ecosistema de AWS. Por otra parte, la informaci´on se ha almacenado en el sistema en un formato muy dividido entre carpetas y ficheros distintos. Gracias a esto, las funciones Lambda son m´as eficientes, ya que no tienen que cargar grandes archivos cada vez que se va a acceder a un dato concreto. La visi´on de priorizar la flexibilidad de los datos y no encerrarlos en el ecosistema AWS y adem´as el compartimentar la informaci´on al m´aximo es un enfoque que se comparte y que se ha aplicado en este proyecto. Otra de las similitudes que hay con este proyecto es que hace un estudio de viabilidad sobre el mantenimiento del juego y analiza el coste por partida dado un n´umero medio de llamadas a funciones, as´ı como el coste de las llamadas a la API y el del mantenimiento de archivos en S3. Adem´as, plantea posibles soluciones de cara a afrontar los costes. En especial, destaca la idea de crear una tienda en la que los organizadores de partidas puedan vender sus assets y partidas a otros organizadores a cambio de dinero, llev´andose el juego una comisi´on del 30 % por cada transacci´on. Para que fuera totalmente viable esta linea har´ıa falta crear una comunidad solida. En esta opci´on tambi´en cabr´ıa la venta de productos adicionales propios en la tienda, los cuales coexistir´ıan con los de la comunidad. Otro de los planteamientos para la sostenibilidad ser´ıa el de hacer asociaciones y pactos con empresas que quisieran tener representaci´on dentro del juego, la cual se traducir´ıa en m´as contenido para la comunidad. La ´ultima idea ser´ıa vender el juego en una plataforma como Steam. Si bien este ´ultimo enfoque no se traducir´ıa en un flujo de dinero perpetuo en el largo plazo, puede ser una fuente de ingresos muy potente que al combinarse con las otras lineas de creaci´on de contenido alcanzase la viabilidad e incluso los beneficios en el proyecto. Habr´ıa que destacar que para poder desarrollar el contenido propio de algunas de estas l´ıneas habr´ıa que contratar a un equipo, con lo cual los costes de mantenimiento de todo el proyecto aumen- 10 tar´ıan considerablemente. 2.6. Cust-OTEA: Marcado de documentos de forma segura El objetivo de este proyecto era el de desarrollar una herramienta que permita a una persona crear marcas de agua invisibles en sus documentos para poder protegerlos ante un posible uso fraudulento por parte de terceros[6]. Este problema surge entre otras cosas del auge de las aplicaciones de edici´on de documentos, las cuales tienen cada vez m´as y mejores herramientas que tienen funcionalidades variadas, entre ellas la capacidad de editar o borrar marcas de agua. Adem´as, usando metodolog´ıas convencionales los costes en tiempo y dinero eran demasiado elevados, as´ı que Samuel Antonio Eugercios Nevado busc´o la forma de desarrollar una herramienta que solucionase el problema y cuyo funcionamiento fuera r´apido y barato en cuanto a coste. Tras investigar y comparar las distintas opciones, descubri´o que la tecnolog´ıa serverless aplicada a trav´es de los servicios de Amazon era la opci´on m´as viable. La herramienta hace uso de API Gateway para enviar la informaci´on de entrada al resto de servicios. Por otra parte, hay 3 buckets S3 que almacenan los datos que usar´an las funciones Lambda, cada uno con un estado de los datos distinto, y finalmente las dos funciones Lambda son las que crean y a˜naden la marca de agua encriptada a los documentos. Adem´as de comparar la soluci´on serverless en tiempo de ejecuci´on y en coste con respecto al uso de un ordenador ordinario, tambi´en compara estas caracter´ısticas entre AWS y Google Cloud. Si bien en Google Cloud el coste al mes ser´ıa de 0.61$, con AWS el coste es de tan solo 0.01$, siendo AWS muy superior en este sentido. Por otra parte, el ordenador, al cual se le asigna un importe de 1000 euros, tendr´ıa un coste mensual de 83.33 euros o 90.82$al cambio actual.(Se asume una amortizaci´on en un a˜no). Por tanto, tanto Google Cloud como AWS superan por mucho al ordenador local. Es importante mencionar que si bien en este an´alisis AWS resulta m´as eficiente que Google Cloud, hay estudios que ofrecen resultados diferentes[7], as´ı que es probable que el tipo de aplicaci´on afecte radicalmente a la efectividad de cada entorno. 2.7. Mafia - A Serverless Multiplayer Game Mafia - A Serverless Multiplayer Game[8] es un juego multijugador online Severless que est´a basado en el juego de mesa hom´onimo. Est´a siendo desarrollado por Jackson Bowe, y es un juego de navegador con todo el backend 11 realizado con servicios de AWS. Cabe destacar que una de las principales diferencias con respecto a este proyecto es que su base de datos se ha realizado mediante AWS DynamoDB En el juego hay cuatro estados distintos, en cada uno de los cuales los jugadores podr´an realizar unas acciones u otras en base al rol que les haya sido asignado. Un enfoque llamativo de este proyecto es que toda la arquitectura Backend est´a basada en c´odigo, y no se realiza ninguna acci´on manual en AWS. Esta metodolog´ıa puede incrementar ligeramente la dificultad de algunas tareas, pero trae consigo potentes ventajas; 1. Los cambios realizados mediante la consola de AWS no pueden ser rastreados con herramientas como Git, al contrario de lo que pasa al realizar variaciones manuales. 2. Con un solo comando puede desplegar el juego en una regi´on totalmente distinta, dot´andolo de flexibilidad. 3. Mediante el uso de un comando puede eliminar el juego por completo. Esto resulta pr´actico llegados a un caso extremo en el que los costes fueran insostenibles, ya que su creador podr´ıa detener el servicio r´apidamente para evitar un desembolso econ´omico insostenible. En cuanto a la arquitectura de la aplicaci´on, el cliente interact´ua con todo el sistema a trav´es del front end desarrollado con Quasar. Este env´ıa peticiones mediante API Gateway a una HTTP API que a su vez llama a las distintas funciones Lambda que ha creado, ya sea para identificiaci´on del usuario con Cognito, para realizar una acci´on dentro del juego, etc. Cuando se realizan acciones del propio juego o en el lobby de partida se debe informar a todos los dem´as usuarios para mantener una coherencia l´ogica. Para esto se ha usado IoT Core, un servicio webSocket de AWS el cual usa el protocolo MQTT ( Message Queuing Telemetry Transport )[9]. Esta decisi´on se debe a que es un servicio r´apido y eficiente a la vez que escalable, ya que al igual que con otros servicios de AWS como Lambda el usuario solo debe pagar por lo que se usa. La alternativa que menciona el desarrollador es crear una funci´on Lambda que act´ue como webSocket y que almacene la informaci´on del usuario que realiza una acci´on en una tabla DynamoDB, para que cuando un mensaje tenga que ser enviado al usuario, su id de conexi´on pueda encontrarse en la tabla y as´ı mandarle el mensaje. El problema es que por cada mensaje de un usuario habr´ıa que leer la tabla entera, 12 lo cual es considerado por el creador del proyecto como lento, ineficiente y probablemente m´as costoso que la alternativa de IoT Core. Una motivaci´on compartida con este proyecto es la de investigar el desarrollo Serverless y familiarizarse con ´el. Sin embargo, este proyecto tiene otros objetivos adem´as de investigar el entorno Serverless. Es por ello que en este caso se ha optado por no usar algunos de los servicios de AWS que s´ı usa Mafia en pos de ventajas de desarrollo y comodidad del usuario. 2.8. Simple Trivia Service Simple Trivia Service es un videojuego web desarrollado con el fin de mostrar las capacidades de AWS a la hora de hacer juegos. Usa servicios de registro e identificaci´on de usuarios con AWS Cognito, datos de jugadores y partidas en las bases de datos de DynamoDB, l´ogica de juego y funcionalidad mediante AWS Lambda, API Gateway se encarga de la comunicaci´on y transmisi´on de datos y los an´alisis de datos se consiguen a trav´es de Kinesis yS3 con Athena. El juego tiene modo individual y multijugador, y algunas de sus funcionalidades son una tabla de clasificaci´on, un chat, un mercado y la posibilidad para los jugadores de crear contenido. 2.9. Serverless Architecture for Data Processing and Detecting Anomalies with the Mars Express MARSIS Instrument Este proyecto est´a enfocado al estudio e investigaci´on de la ionosfera de Marte[10]. Para ello, se pretend´ıa analizar distintos ionogramas para detectar anomal´ıas. En cuanto al procesamiento de la informaci´on, se opt´o por una arquitectura modular sin servidor. Entre las distintas ventajas mencionadas, se explica que la computaci´on en la nube permite a los desarrolladores elaborar proyectos, investigaciones, aplicaciones, etc. sin tener que preocuparse de desplegar un complejo entramado de servidores, ocup´andose de esto el proveedor de los servicios. El hecho de delegar la tarea de gesti´on de recursos y ejecuci´on de programa a otra entidad permite que los investigadores puedan dedicarse en su totalidad al desarrollo del proyecto. Adem´as, gracias a su eficiencia, el enfoque serverless es ideal para proyectos en los que los costes deben estar muy ajustados, tal y como es el caso. La arquitectura sin servidor ha sido desplegada con los servicios de AWS. El procesamiento de los datos est´a basado en un sistema distribuido en m´odulos en el cual hay una serie de funciones Lambda y buckets S3. El resul- 13 tado de las funciones se almacena en los buckets, actuando estos como una memoria secundaria y a su vez como disparadores de las otras funciones, ya que es una arquitectura en cadena en la que el resultado de unas funciones puede provocar que se llame a otras. El uso de esta tecnolog´ıa se puede considerar un acierto, ya que en an´alisis comparativo con respecto al uso de ordenadores propios de entre 3250 y 3500 euros se observ´o una capacidad de procesamiento muy inferior a la de la arquitectura serverless. En concreto, en los 20 minutos que tard´o esta en procesar los 441919 ionogramas, los ordenadores solo pudieron procesar 4320 en el mejor caso y 1440 en el peor. Por otra parte, el coste de esta arquitectura fue muy inferior al de los ordenadores. Para el procesamiento de todos los ionogramas los servicios de AWS requirieron un pago de 0.00001$. Este bajo coste se debe a funciones Lambda muy optimizadas y a que casi no hay almacenamiento en S3, ya que solo se guardan los archivos de entrada y salida, borr´andose los archivos intermedios durante la ejecuci´on de las funciones Lambda. 2.10. Towards Supporting Millions of Users in Modifiable Virtual Environments by Redesigning Minecraft-Like Games as Serverless Systems Los autores de este trabajo[11] se fijaron en que videojuegos similares a Minecraft en cuanto a ser un juego multijugador que transcurre en un mundo modificable no son tan escalables como podr´ıan. Se refieren a este tipo de juegos como MEVs (modifiable virtual environment), y se˜nalan que si bien estas obras tienen m´as de 100 millones de jugadores en el mundo, no ofrecen una gran cantidad de jugadores por partida, mientras que si aprovechasen una arquitectura basada en servicios de la nube podr´ıan ser much´ısimo m´as escalables y tener m´as jugadores de forma concurrente. Explican algunas de las t´ecnicas usadas en la actualidad, como por ejemplo representar solo una parte del mundo al jugador e ir carg´andola conforme este se mueve, o simular localmente acciones hasta que se recibe el estado real del juego por parte del servidor. Sin embargo, su propuesta es la creaci´on de una arquitectura serverless que en un futuro podr´ıa permitir millones de jugadores simult´aneos. 2.11. Conclusiones respecto al estado del arte Tras analizar distintos proyectos y estudios, se observa que hay varias versiones en l´ınea de Magic. Sin embargo, todas usan metodolog´ıas convencionales. Por otra parte, hay varios estudios que demuestran que una de las 14 mejores opciones a la hora de desarrollar software escalable y a bajo coste es el uso de la computaci´on sin servidor[12], en especial en el entorno de AWS. Algunos equipos han aprovechado la concurrencia que ofrece AWS Lambda para poder realizar c´alculos y operaciones complejos en muy poco tiempo y con un gasto m´ınimo. Otras personas se han servido de la concurrencia para poder atender a todas las llamadas realizadas y generar una arquitectura similar a un servidor usando funciones como servicio. Este ´ultimo enfoque es el que tiene un gran potencial en cuanto al desarrollo de un sistema online r´apido, escalable y de bajo coste, as´ı que a la vista de los resultados de dichos trabajos, todo apunta a pensar que la tecnolog´ıa se ajusta a la necesidad de este proyecto. Cap´ıtulo 3. Metodolog´ıa y Tecnolog´ıas Una vez revisado el estado del arte, el enfoque elegido para realizar el proyecto ha sido el uso de la tecnolog´ıa serverless del entorno AWS. Por tanto, una vez elegida la tecnolog´ıa, se deben comparar las distintas posibilidades que existen entre aplicaciones y programas de desarrollo. Para abarcar un trabajo de gran envergadura se deben usar m´ultiples herramientas con prop´ositos variados; programaci´on y desarrollo, organizaci´on, dise˜no de elementos gr´aficos, etc. Las herramientas seleccionadas para crear Magic: The Serverlessling han sido las siguientes: 3.1. LaTeX LaTeX[13] es un sistema de composici´on de textos que permite la elaboraci´on de documentos t´ecnicos evitando problemas existentes en otras alternativas. Su caracter´ıstica principal es que admite comandos del lenguaje Tex, los cuales dotan al usuario de opciones ´unicas a la hora de desarrollar sus escritos. Gracias a su capacidad de elaborar textos de gran calidad, a ser un est´andar a la hora de crear documentos t´ecnicos y cient´ıficos y a su facilidad de uso, se ha optado por usar LaTeX para el desarrollo de esta memoria. 3.2. Overleaf Overleaf es un editor de LaTeX online que tiene buenas funcionalidades como la redacci´on colaborativa y simult´anea, un historial de cambios en el documento y una opci´on de compilaci´on integrada que junto con un doble visor editor-resultado se traduce en un uso ´agil y sencillo de LaTeX, pudiendo comprobar al momento los cambios introducidos en el documento. Debido a sus potentes caracter´ısticas, facilidad de uso, aprobaci´on comunitaria y a que es una herramienta gratuita, se opt´o por este editor para la redacci´on del documento presente. 3.3. draw.io draw.io es una aplicaci´on web multiplataforma gratuita que permite la elaboraci´on de gr´aficos de gran calidad, cobrando especial relevancia en cuanto al desarrollo de gr´aficos complejos tales como diagramas de flujo, diagramas UML, diagramas de arquitecturas complejas, diagramas organizativos, etc. Los diagramas se pueden editar en cualquier momento y se pueden exportar a varios tipos de formato distintos. Sumado a su baja dificultad, estas cualidades hacen de la aplicaci´on una opci´on excelente para conseguir gr´aficos 15 22 nes que desempe˜nan la l´ogica de juego, AWS S3 funciona como la base de datos de todas las partidas y permite activar las funciones Lambda, AWS API Gateway hace que los usuarios puedan llamar a la funci´on de comienzo de partida y recibir la informaci´on necesaria para interactuar con la misma, y por ´ultimo, AWS Cloudwatch muestra informaci´on sobre los dem´as servicios, con la cual se puede analizar su funcionamiento. Para asignar un c´odigo ´unico a las partidas se ha usado el patr´on UUID y su correspondiente biblioteca de Python, y para los archivos de las partidas se ha elegido el formato JSON. La base de datos Gatherer permite la b´usqueda y obtenci´on de las im´agenes de las cartas de Magic oficiales, mientras que MTG Cardsmith tiene como funci´on la creaci´on de cartas de Magic personalizadas. Para desarrollar assets no relacionados com Magic, como los elementos de la interfaz, se ha elegido Gimp. Se ha optado por Github como sistema de control de versiones para poder mantener a salvo los avances en el cliente y poder acceder a ellos desde cualquier lugar, y por otra parte se han usado Pivotal Tracker y Trello para gestionar y organizar las diferentes tareas de desarrollo. Por ´ultimo, para la elaboraci´on de esta memoria se ha elegido el sistema Latex y el entorno especializado Overleaf. Los gr´aficos presentes en la memoria se han desarrollado con draw.io. Cap´ıtulo 4. Desarrollo del Proyecto 4.1. Desarrollo de la aplicaci´on El proyecto se pone en marcha una vez que se determin´o el objetivo de crear una versi´on online simplificada de Magic que sea barata, escalable y f´acil de usar mediante computaci´on sin servidor. Est´a formado por un cliente local y por una estructura serverless. El cliente ser´ıa una aplicaci´on local desarrollada en C# y con SDL y act´ua a modo de interfaz, permitiendo al usuario interactuar con el back-end del proyecto, que corresponde a la parte serverless, encargada de la l´ogica. El bucle principal[24] de la aplicaci´on local realiza las siguientes acciones: 1. Se comprueba si ha habido cambios en la partida descargando el archivos cambios.json de la misma y los aplica en caso de haberlos. Esta acci´on solo se realiza dos veces por segundo para optimizar el rendimiento 2. Se detectan y se procesan todos los eventos de entrada realizados por el cliente, enviando peticiones en forma de archivos a S3 cuando es necesario 3. Se renderizan todas las im´agenes de la interfaz gr´afica 4. Se hace una breve espera para que la duraci´on del bucle sea siempre uniforme A su vez, la aplicaci´on tiene las clases Player yCard que permiten almacenar la informaci´on de los jugadores y las cartas respectivamente[25]. Mediante el sistema de almacenado de informaci´on y actualizaci´on de las partes de la misma que se ven modificadas se consigue una gran eficiencia con respecto a otros enfoques como por ejemplo mostrar el estado de juego recibi´endolo en su totalidad cada vez que haya un cambio. 23 24 Figura 4.1: Cliente local de Magic: The Serverlessling 4.2. Arquitectura Serverless Magic: The Serverlessling est´a desarrollado en su totalidad en el ecosistema de AWS. A trav´es de distintos servicios, la l´ogica de juego y su informaci´on se gestionan con tecnolog´ıa Serverless, y los usuarios ven reflejados estos procesos en su cliente local. La arquitectura AWS est´a compuesta de tres servicios: AWS Lambda se encarga de la l´ogica, S3 de la informaci´on yAPI Gateway de la conexi´on inicial. Por otra parte, los clientes locales son aplicaciones que se encargan principalmente del renderizado del juego, del input del jugador y de la conexi´on con AWS. 25 Figura 4.2: Arquitectura de Magic: The Serverlessling 4.2.1. AWS S3 y almacenamiento de la informaci´on AWS S3 es un sistema de almacenamiento mediante el cual se guarda toda la informaci´on de las partidas a modo de base de datos. Al formar parte del ecosistema AWS, se puede acceder a esta informaci´on y manipularla de forma program´atica mediantes las funciones AWS Lambda. A su vez, la subida de archivos a S3 es un disparador v´alido para dichas funciones. Este proyecto usa dos buckets S3 distintos para evitar un bucle de ejecuci´on: se sube un archivo a un bucket, esto desencadena una funci´on Lambda que sube un archivo al mismo bucket, lo cual lleva a volver a llamar a la funci´on. Por tanto, al tener un bucket de input para llamar a las funciones y un bucket con la informaci´on de juego, se puede modificar libremente la informaci´on del bucket de datos sin que se produzcan llamadas no deseadas. Bucket inputmts Este bucket act´ua como disparador de las distintas funciones Lambda. Est´a compuesto por 3 carpetas: activateAbility,nextPhase yplayCard, hom´oni- 26 mas a las funciones invocadas cuando se sube un archivo en cualquiera de ellas. Dentro de las carpetas, los archivos subidos por la aplicaci´on tienen como nombre el identificador de partida. Esto evita el problema de que dos usuarios de distintas partidas hagan un input a la vez y cuando se acceda a la informaci´on en la ejecuci´on de Lambda la informaci´on haya quedado sobrescrita. Dentro de estos archivos en texto plano se encuentran escritos los par´ametros de lanzamiento de la funci´on, los cuales ser´an le´ıdos por esta durante su ejecuci´on. Bucket magic-the-serverlessling El bucket magic-the-serverlessling act´ua como la base de datos de todo el sistema. Dentro de sus sistema de carpetas almacena archivos JSON que contienen toda la informaci´on correspondiente a una partida. Su estructura es la siguiente: 1. games/: carpeta inicial que contiene todas las partidas en juego. 2. games/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/: carpeta que almacena toda la informaci´on de una partida, siendo su nombre su identificador alfanum´erico. 3. /game.json: guarda la informaci´on general de la partida. 4. /usuarioX/battlefield, hand o library/Y.json: guardan la informaci´on de las cartas de un jugador. Cada carpeta corresponde a una zona distinta en la que puede encontrarse una carta. 5. /usuarioX/info.json: guarda la informaci´on relativa al jugador X. 6. /cambios.json: guarda los ´ultimos cambios realizados para que los clientes puedan actualizar su estado de juego de forma ´optima. A su vez, la estructura interna de estos archivos es la siguiente: game.json (gameInfo en Lambda): 1. activePlayer: n´umero entero correspondiente al jugador al que le toca llevar a cabo acciones. 2. phase: n´umero entero que corresponde a la fase actual del turno. 3. attackersIds: array de enteros en el que se registran los identificadores de todas las criaturas que est´an atacando. 4. blockerId: entero en el que se guarda el identificador de la criatura que est´a lista para bloquear. 27 5. waitingForTarget: entero que especifica si hay una carta que requiere un objetivo para hacer su efecto. Si su valor es -1 significa que no hay ninguna carta esperando. En caso contrario, su valor ser´a el identificador de la carta en espera, lo que bloquear´a cualquier acci´on que no sea designar un objetivo para esa carta. /usuarioX/info.json (playerInfo en Lambda): 1. lives: n´umero de vidas que le quedan al jugador. 2. cardsinHand: n´umero de cartas que tiene en mano el jugador. 3. remainingLandPlays: n´umero de tierras que puede jugar el jugador. Se restablece cada turno. 4. libIndex: ´ındice que indica cu´al es la siguiente carta a robar del mazo. 5. blue/red/black/white/green/colorless: enteros relativos a la cantidad de man´a azul, rojo, negro, blanco, verde o incoloro que tiene el jugador, respectivamente. cambios.json (cambios en Lambda): 1. idCambios: contador que se incrementa con cada acci´on que produzca un cambio. Se usa para llevar un registro de los cambios que se han aplicado de forma local en un cliente para que no se repitan. 2. cardsDrawnPlayerX: identificadores de las cartas que ha robado el jugador X. 3. cardsPlayedPlayerX: identificadores de las cartas que ha jugado el jugador X. 4. cardsTappedPlayerX: identificadores de las cartas que ha girado el jugador X. 5. cardsUntappedPlayerX: identificadores de las cartas que ha enderezado el jugador X. 6. cardsAttackingPlayerX: identificadores de las cartas del jugador X que est´an atacando. 7. cardsBlockingPlayerX: identificadores de las cartas del jugador X que se est´an preparando para bloquear. 28 8. cardsBlockedPlayerX: identificadores de las cartas del jugador X que han sido bloqueadas por la criatura que estaba designada para bloquear a continuaci´on. 9. cardsDestroyedPlayerX: identificadores de las cartas del jugador X que han sido destruidas. 10. cardsDiscardedPlayerX: identificadores de las cartas del jugador X que han sido descartadas. 11. temporalStatsPlayerX: identificadores de las cartas del jugador X que han aumentado sus estad´ısticas temporalmente, seguidos de la cantidad de aumento recibido. 12. victoryPlayerX: indica si ha ganado uno de los jugadores. 13. livesPlayerX: indica las vidas actuales del jugador X. Si es -1 no ha habido cambios. 14. newPhase: indica la fase actual. Si es -1 no se ha cambiado de fase. 15. newActivePlayer: id del jugador activo. Si es -1 no ha cambiado. usuarioX/ZONE/X.json (cardInfo en Lambda): 1. cardType: cadena de texto que indica el tipo de la carta. Puede ser ’LAND’, ’CREATURE’, ’SORCERY’ o ’INSTANT’. 2. cardName: cadena de texto que contiene el nombre de la carta. 3. tapped: variable que determina si la carta est´a girada o enderezada. 4. blue/red/black/white/green/colorless: coste de man´a de cada color de la carta. 5. hasTarget: indica si la carta necesita que su jugador designe un objetivo para realizar su efecto. 6. power: n´umero que equivale a la fuerza de la carta. 7. toughness: n´umero que equivale a la resistencia de la carta. 8. temporalPower: n´umero que indica un aumento de fuerza temporal. 9. temporalToughness: n´umero que indica un aumento de resistencia temporal. 10. damage: representa el da˜no que ha sufrido la carta este turno. 29 11. attacking: determina si la criatura est´a atacando. 12. blocker: id de la criatura que est´a bloqueando a esta carta. 13. attackerBlocked: id de la criatura a la que est´a bloqueando esta carta. 14. summoningSickness: representa si la carta tiene mareo de invocaci´on. 15. flying/lifelink/deathtouch/trample: indican si la criatura tiene las habilidades de volar, v´ınculo vital, toque mortal o arrollar, respectivamente. 16. id: n´umero identificador de la carta. 4.2.2. Funciones Lambda y l´ogica de juego Las funciones Lambda de AWS son el n´ucleo del proyecto, ya que a trav´es de ellas se gestiona toda la l´ogica de la aplicaci´on. Adem´as, el estudio de sus capacidades son el foco del an´alisis del proyecto. AWS Lambda permite crear c´odigo y ejecutarlo en una m´aquina remota de Amazon en respuesta a un disparador personalizable, habilitando al usuario de crear un sistema similar al de los servidores pero sin disponer de uno y eliminando todas las desventajas de los mismos. Este proyecto cuenta cuatro funciones Lambda, cada una con una funcionalidad y caracter´ısticas diferentes; Funci´on play La funci´on play se encarga de crear una nueva partida y todas las estructuras de datos pertinentes o de crear la informaci´on del segundo jugador cuando se quiere unir a la partida. En concreto, realiza las siguientes acciones: 1. Eval´ua los par´ametros de lanzamiento para saber qu´e acciones debe llevar a cabo 2. En el caso de crear una nueva partida, genera un identificador uuid que no est´e siendo usado por ninguna otra partida 3. Genera la estructura gameInfo, la cual almacena toda la informaci´on relativa a la partida 4. Genera la estructura playerInfo, la cual guarda la informaci´on de un jugador 5. Sube al bucket S3 magic-the-serverlessling dichas estructuras en sus correspondientes ficheros dentro de una nueva carpeta cuyo nombre es el identificador creado anteriormente 30 6. Se generan las distintas cartas posibles y se guardan en el mazo del jugador, el cual es barajado a continuaci´on 7. Se genera la estructura de cambios, la cual sirve para comunicar a los jugadores las variaciones que se producen en la partida 8. El mazo del jugador se sube a S3 asignando un identificador a cada carta. Despu´es, el jugador roba 7 cartas y estas se indican en el fichero de cambios 9. La funci´on termina y devuelve el identificador de la partida para que el creador de la misma pueda comunicarse con ella y tambi´en para que pueda envi´arselo a su oponente El disparador de est´a funci´on es una llamada a una API Rest creada mediante AWS API Gateway. Esta llamada se produce cuando un usuario inicia su aplicaci´on local y usa la consola para indicar si quiere crear una partida o unirse a una mediante un n´umero. En cuanto a sus par´ametros, tiene tres posibles par´ametros: 1. command: indica si la funci´on debe crear una nueva partida o unirse a una ya existente. Las dos opciones son ’CREATE GAME’ y ’JOIN GAME’ respectivamente. 2. deckId: determina el mazo que usar´a el jugador que ha llamado a la funci´on. El 0 corresponde al mazo de color negro y el 1 al de color verde. 3. id: en el caso de que el jugador se est´e uniendo a una partida, este env´ıa el identificador de la misma para que la funci´on genere sus datos en ella. El funcionamiento de la funci´on es el siguiente: 31 Figura 4.3: Arquitectura de la funci´on play Figura 4.4: Diagrama resumen de la funci´on play Funci´on playCard La funci´on playCard gestiona toda la l´ogica detr´as de jugar una carta, desde pagar el coste de la misma hasta trasladarla a la zona adecuada o realizar su efecto. El proceso de ejecuci´on es el siguiente: 38 2. Activar la habilidad de una carta en el campo de batalla puls´andola 3. Declarar el objetivo de un efecto o hechizo pulsando sobre la carta que va a ser dicho objetivo 4. Avanzar de fase en el turno pulsando el bot´on de Next Phase 5. Declarar un atacante pulsando sobre la criatura en cuesti´on durante su fase de declaraci´on de atacantes 6. Preparar a una criatura suya para bloquear, cancelar la preparaci´on o el bloqueo declarado pulsando sobre ella en la fase de bloqueos 7. Bloquear a una criatura rival pulsando sobre ella en la fase de bloqueos teniendo a una criatura lista para bloquear Estas acciones se pueden realizar en momentos concretos del turno, cuyo flujo y reglas son los siguientes: Figura 4.11: Fases de un turno y posibles acciones Por otra parte, en las siguientes figuras se muestra como var´ıa el estado de juego seg´un las acciones posibles: 39 Figura 4.12: Estado neutral de la partida Figura 4.13: El jugador usa sus tierras para agregar man´a y estas quedan giradas Al pulsar sobre cada tierra, se sube al bucket S3 inputmts un fichero con los identificadores de la partida, el jugador y la carta seleccionada. Esto provoca la ejecuci´on de la funci´on Lambda activateAbility, que re- 40 coge los datos del fichero. Esta funci´on recoge del bucket S3 magic-theserverlessling los archivos del jugador y de la carta. A continuaci´on, a˜nade a los datos del jugador un man´a de color negro y cambia el estado de la carta a girada. Acto seguido se suben los archivos de nuevo con la informaci´on actualizada junto con el fichero de cambios para que los jugadores puedan actualizar su versi´on. Figura 4.14: El jugador juega una carta con el man´a de sus tierras Cuando un jugador pulsa sobre una carta de su mano se sube al bucket S3 inputmts un fichero con los identificadores de la partida, el jugador y la carta seleccionada. Esto provoca la ejecuci´on de la funci´on Lambda playCard, que recoge los datos del fichero. Esta funci´on recoge del bucket S3 magic-the-serverlessling los archivos del jugador y de la carta. A continuaci´on, se comprueba en el archivo del jugador si este dispone de man´a para pagar la carta, y en caso afirmativo se le resta el coste de la misma. Despu´es, se sube la carta a la carpeta battlefield del jugador y a su vez se borra el archivo de la carta de la carpeta hand. Por ´ultimo, se sube el archivo del jugador con sus datos actualizados y el 41 fichero de cambios. Figura 4.15: El jugador declara a dos de sus criaturas como atacantes Cuando un jugador pulsa sobre una criatura suya durante la fase de ataque se sube al bucket S3 inputmts un fichero con los identificadores de la partida, el jugador y la carta seleccionada. Esto provoca la ejecuci´on de la funci´on Lambda activateAbility, que recoge los datos del fichero. Esta funci´on recoge del bucket S3 magic-theserverlessling los archivos del jugador, de la carta y del juego. Tras comprobar el tipo de carta y la fase del turno, se cambia el estado de la carta a atacando ygirada y se a˜nade su id a la lista de atacantes del fichero que tiene los datos de la partida. Finalmente se suben todos los ficheros con su informaci´on actualizada junto con el fichero de cambios. 42 Figura 4.16: El jugador defensor prepara a su criatura para bloquear Cuando un jugador pulsa sobre una criatura suya durante la fase de bloqueo se sube al bucket S3 inputmts un fichero con los identificadores de la partida, el jugador y la carta seleccionada. Esto provoca la ejecuci´on de la funci´on Lambda activateAbility, que recoge los datos del fichero. Esta funci´on recoge del bucket S3 magic-theserverlessling los archivos del jugador, de la carta y del juego. Tras comprobar el tipo de carta y la fase del turno, se registra en el archivo de partida su id como pr´oxima bloqueadora. Despu´es se suben de nuevo los archivos modificados y el fichero de cambios. 43 Figura 4.17: El jugador defensor elige a qu´e criatura atacante va a bloquear su bloqueadora Cuando un jugador pulsa sobre una criatura rival durante la fase de bloqueo se sube al bucket S3 inputmts un fichero con los identificadores de la partida, el jugador y la carta seleccionada. Esto provoca la ejecuci´on de la funci´on Lambda activateAbility, que recoge los datos del fichero. Esta funci´on recoge del bucket S3 magic-theserverlessling los archivos del jugador, de la carta que ha sido bloqueada, de la carta que estaba preparada para bloquear y el del juego. A continuaci´on, se guarda en el archivo de la criatura bloqueadora el id de la criatura a la que bloquea, y por otra parte se guarda en el de la criatura bloqueada el id de su bloqueadora. Por ´ultimo, se suben los archivos modificados y el fichero de cambios. 44 Figura 4.18: Se producen los da˜nos. La criatura bloqueadora muere y la criatura atacante que no fue bloqueada hace da˜no al jugador defensor Cuando el jugador defensor pulsa sobre el bot´on de Next Phase tras haber designado a los bloqueadores se sube al bucket S3 inputmts un fichero con los identificadores de la partida y del jugador. Esto provoca la ejecuci´on de la funci´on Lambda nextPhase, que recoge los datos del fichero. Esta funci´on recoge del bucket S3 magic-the-serverlessling los archivos de los dos jugadores y del juego. A continuaci´on, se avanza en uno el contador de fase de la partida y se comprueba la fase actual. Como se ha llegado a la fase de da˜nos, se realiza un proceso por el cual se van recogiendo los ficheros de las criaturas atacantes, cuyos ids est´an guardados en el archivo de la partida. Por cada una se comprueba si tienen una bloqueadora. En caso afirmativo, se descarga el archivo de la bloqueadora y se hacen da˜no entre si seg´un su fuerza. Si una criatura pierde toda su vida durante el combate, su fichero se elimina de la carpeta battlefield de su controlador. En caso de que la criatura no fuera bloqueada, el jugador defensor pierde vidas igual a la fuerza de la criatura. Tras revisar a todas las criaturas atacantes, se suben los archivos de todas las criaturas que han sobrevivido al combate, los archivos de los jugadores y el del juego. Cap´ıtulo 5. Resultados y Discusi´on 5.1. An´alisis de costes de AWS Lambda Las cuatro funciones Lambda utilizadas han requerido de muy poco espacio de memoria ram, dado que la asignaci´on m´ınima de 128MB ha sido suficiente para todas ellas, requiriendo unos 77MB de media. Por otra parte, el tiempo de ejecuci´on medio ha sido el siguiente: Funci´on Tiempo de ejecuci´on play 4940ms playCard 481ms activateAbility 450ms nextPhase 558ms Cuadro 5.1: Tiempo de ejecuci´on medio de las funciones Lambda Asumiendo la cota superior de coste por una partida y que los jugadores no hacen llamadas innecesarias, se pueden realizar los siguientes c´alculos de coste por partida: En cada turno se tiene que avanzar de fase un total de 8 veces asumiendo que se entra en combate. Dado que un jugador que tenga que robar cartas sin tener m´as cartas disponibles en su biblioteca pierde, el m´aximo n´umero de turnos jugados ser´a el de 106, ya que ambos empiezan teniendo 7 de las 60 cartas en mano. Por tanto, habr´ıa un m´aximo de 846 llamadas a nextPhase, considerando que el primer jugador empieza en su fase principal. Si ambos jugadores juegan todas sus cartas, el l´ımite de cartas jugadas ser´ıa de 120, siendo estas las posibles llamadas a la funci´on playCard. El coste total medio de man´a entre los mazos disponibles es de 85. Esto implica que para jugar todas las cartas har´ıa falta activar las tierras 85 veces. Por otra parte, hay 19 criaturas por mazo de media. Si suponemos que todas las criaturas atacan 3 veces por partida y que bloquean una vez, tendr´ıamos 190 llamadas a activateAbility para gestionar el combate, lo cual sumado a las activaciones de tierras nos dar´ıa un total de 275 llamadas por jugador, siendo en total 550. Podemos considerar 20 llamadas m´as para designar objetivos de habilidades, ya que son algo m´as del total de cartas que existen en el juego que puedan hacer objetivo. Por tanto, en una partida cualquiera se puede asumir con seguridad que se van a producir las siguientes llamadas: 45 46 Funci´on N´umero de llamadas play 2 playCard 120 activateAbility 570 nextPhase 846 Cuadro 5.2: N´umero m´aximo de llamadas estimado para una partida En conjunto estos datos nos indican que habr´ıa un m´aximo de 1538 llamadas a AWS Lambda por partida. Gracias al nivel gratuito de AWS, el primer mill´on de solicitudes a Lambda cada mes es gratuito. Por tanto, se podr´ıan jugar 650 partidas a coste cero en cuanto a n´umero de solicitudes. Por otra parte, cada mes se permiten un m´aximo de 3,2 millones de segundos de tiempo de ejecuci´on de forma gratuita. Multiplicando las llamadas por su tiempo medio tenemos como resultado 796168ms de ejecuci´on por partida, lo que equivale a 796 segundos. El l´ımite de partidas gratuitas impuesto por el tiempo de ejecuci´on ser´ıa de 4020 partidas en total. Dado que las 650 partidas es el l´ımite gratuito m´as bajo, a partir de ese n´umero de partidas habr´ıa que incurrir en un gasto por los servicios de AWS Lambda. A trav´es de la calculadora de costes oficial, se ha calculado que 1000 partidas fuera de la capa gratuita tendr´ıan un coste de 1.97$. Por tanto, los servicios de Lambda de una partida costar´ıan 0.00197$. 5.2. ´ Analisis de costes de AWS S3 Las llamadas put object,get object ydelete object se producen la siguiente cantidad de veces por funci´on: Funci´on get object put object delete object play 1 67/68 7 playCard 7 8 1 activateAbility 8 5 7 nextPhase Variable Variable Variable Cuadro 5.3: N´umero de llamadas a S3 por cada funci´on Lambda Se producen 134 put object para crear los mazos y robar las cartas iniciales. Con las 120 llamadas a playCard habr´ıa 960 peticiones de put object yget object y unas 120 a delete object. Con las 570 llamadas a activateAbility habr´ıa unas 4560 peticiones de get object, 2850 de put object y 3990 a delete object. Con las 846 peticiones a nextPhase, considerando que solo en un tercio de las peticiones se necesitar´ıa acceder a todas las cartas del campo de batalla y que ser´ıa muy extra˜no que un jugador tuviera m´as de 15 cartas en juego a la vez, se podr´ıan calcular unas 4230 llamadas a 47 get object y otras 4230 a put object. Adem´as, por cada llamada a Lambda se produce un put object a S3, as´ı que recibir´ıa 1261 peticiones m´as. Por otra parte, considerando que el juego comprueba si hay cambios 2 veces por segundo, si suponemos que una partida dura media hora, entre los dos jugadores se har´ıan 7200 llamadas a get object para poder recoger los cambios en la partida. Aproximadamente habr´ıa como mucho en una partida 10261 llamadas a put object, 16950 llamadas a get object y alrededor de 4125 a delete object. Usando la calculadora de costes, obtendr´ıamos que el coste de S3 por la partida ser´ıa de 0.06$aproximadamente. 5.3. Costes totales Sumando los costes, obtendr´ıamos que como m´aximo una partida podr´ıa costar 0.062$, suponiendo que en la partida se usen todas las cartas, tenga su m´axima duraci´on de turnos y dure media hora. Dada la automatizaci´on de algunos procesos de juego gracias al formato digital y a la simplicidad de las reglas, la duraci´on de las partidas deber´ıa ser extremadamente inferior, y por tanto su coste. Por otra parte, habr´ıa que considerar costes mensuales adicionales. El almacenamiento de informaci´on en el bucket S3 costar´ıa 0.02$cada mes. Es bajo debido a que un archivo de partida ocupa tan solo 45kb, permitiendo hasta 20000 ficheros de partidas por ese coste. Adem´as, mediante el borrado peri´odico de estos ficheros, su n´umero y por tanto su coste se mantendr´ıa bajo control. Otro coste adicional cada mes ser´ıa el de API Gateway. Seg´un la calculadora de costes, se necesitar´ıan 0.04$para gestionar 10000 solicitudes, as´ı que ser´ıa un coste bajo y asumible. Servicio Coste AWS Lambda 0.00197$ AWS S3 0.06$ AWS API Gateway 0.000008$ Coste total de una partida 0.062$ Cuadro 5.4: Desglose de coste por partida de cada servicio 5.4. Enfoques para afrontar los costes En el caso de que se quisieran cubrir los costes, la opci´on m´as viable ser´ıa a trav´es de una suscripci´on. Esta garantizar´ıa en cierta medida que se cubren los gastos por servicios, ya que se podr´ıa ajustar a las estad´ısticas de uso de tal forma que el proyecto fuera rentable. Adem´as, servir´ıa como barrera de entrada para que solo accediese al contenido un p´ublico m´as comprometido con el juego y que no se pudiera saturar mediante una gran cantidad de 54 ke into consideration is that with this approach a lot of time would be saved at the time of setting up the server, adquiring a place where you could keep it working constantly, malfunctions that could disable the service, etc. Another one of the main pros is that the cost is produced over time and it is scalable; if the final product does not perform well and it gets only a few users the costs will be very low, and if a server is adquired it will have costed a lot of money that will remain wasted. In addition, serverless can be a nice option if the lack of founding is a problem, because the monthly cost of the services will be lower than the cost of getting a server. Next, if the app has a good business model, the costs will be easier to get covered because they adjust to the demand of the product and they take place over time. Another important alternative is selecting a player that will be the host of the game, and letting him act as a server. On one hand, it is an interesting option because of the lack of costs. On the other hand, it can produce poor quality user experience if the host has a bad Internet connection, which does not matter so much in other approaches. Other issues are the additional difficulty at the time of getting statistics and information about the games played and the connection, and also there are some games in which being the host is considered an advantage, as the host will have less latency than other users. To sum up, serverless technology has proved itself as being scalable and succesful at the time of developing software. 6.6. Future work There are some features and content that couldn’t be implemented but they were a viable option during the development process. Although it was considered how to develop them, finally several ideas were required to be discarded. The content which holds the most potential to be implemented as future work is the following: 6.6.1. Bigger card pool There should be a low number of cards in order to be a beginner-friendly game, although there is still room for including more cards and effects without being overwhelming for new players. 6.6.2. Option to reconnect an on-going game One of the project limits is that if a game is abandoned for any reason, players will not be able to join that game again, as a system to recover the state of the game does not exist. However, with the creation of a new Lambda function and the modification of local client’s code, this option would beca- 55 me available. 6.6.3. Account system and card collection To make the game more interesting and improve its depth without making it harder, an account system could be implemented. This would allow players to check their stats and even obtain new cards which could be used to create decks. S3 buckets would need several improvements and new Lambda functions would need to be created in order to add this feature. 56 Chapter A. Anexo: Manual de Instalaci´on A continuaci´on se detalla paso por paso c´omo poder descargar y disfrutar del juego. Descarga del cliente local Para empezar, habr´a que acceder al siguiente repositorio ubicado en Github: https://github.com/rtobar01/Magic The Serverlessling 2/releases Figura 6.1: P´agina de versiones de Magic: The Serverlessling Acto seguido, dentro de la p´agina que muestra la figura se deben descargar los archivos en cualquiera de los formatos y descomprimirlos en una carpeta. Ejecuci´on del juego A continuaci´on, para poder acceder al juego tan solo hay que ejecutar el archivo ejecutable MagicTheServerlessling.exe, el cual se encuentra en la siguiente ubicaci´on: 57 58 Al ejecutar el archivo, se abrir´a una ventana de SDL en negro y una consola de comandos. A trav´es de las indicaciones de la consola, el usuario podr´a elegir qu´e mazo de cartas quiere usar y si desea crear o unirse a una partida. Si crea una partida, la aplicaci´on le mostrar´a el c´odigo de la partida, el cual 59 deber´a ser enviado por cualquier medio a su oponente, que habr´a seleccionado la opci´on de unirse a una partida y deber´a pegar el c´odigo del creador de la partida. 60 Bibliograf´ıa [1] E. Jonas, J. Schleier-Smith, V. Sreekanti, C.-C. Tsai, A. Khandelwal, Q. Pu, V. Shankar, J. Carreira, K. Krauth, N. Yadwadkar et al., “Cloud programming simplified: A berkeley view on serverless computing,” arXiv preprint arXiv:1902.03383, 2019. [2] R. Garfield, “Magic: The gathering,” Wizards of the Coast, vol. 27, p. 28, 1993. [3] M. DI NAPOLI, “Multi-asset trading with reinforcement learning: an application to magic the gathering online,” 2018. [4] E. LUCIANO and A. DI RE, “Understanding the magic: The gathering card market an ethnographic approach toward a market strategy eugenio luciano and alexander di re,” Beyond the Deck: Critical Essays on Magic: The Gathering and Its Influence, p. 43, 2023. [5] ´ A. Rodr´ıguez-Peral Bustos, “Youruleyourole,” 2021. [6] S. A. Eugercios Nevado, “Cust-otea: Marcado de documentos de forma segura,” 2023. [7] B. Gupta, P. Mittal, and T. Mufti, “A review on amazon web service (aws), microsoft azure & google cloud platform (gcp) services,” in Proceedings of the 2nd International Conference on ICT for Digital, Smart, and Sustainable Development, ICIDSSD 2020, 27-28 February 2020, Jamia Hamdard, New Delhi, India, 2021. [8] J. Bowe, “Mafia - a serverless multiplayer game,” Medium, 2023. [9] D. Dinculean˘a and X. Cheng, “Vulnerabilities and limitations of mqtt protocol used between iot devices,” Applied Sciences, vol. 9, no. 5, p. 848, 2019. [10] D. Pacios, J. L. Vazquez-Poletti, B. S´anchez-Cano, R. MorenoVozmediano, N. Schetakis, L. Vazquez, and D. V. Titov, “Serverless architecture for data processing and detecting anomalies with the mars express marsis instrument,” The Astronomical Journal, vol. 166, no. 1, p. 19, 2023. [11] J. Donkervliet, A. Trivedi, and A. Iosup, “Towards supporting millions of users in modifiable virtual environments by redesigning Minecraft-Like 61 62 games as serverless systems,” in 12th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 20). USENIX Association, Jul. 2020. [Online]. Available: https://www.usenix.org/conference/hotcloud20/ presentation/donkervliet [12] J. S. Argonza, “Computaci´on sin servidor,” Tecnolog´ıa e Innovaci´on en Educaci´on Superior. [13] T. Fischer, “Latex as an archiving format: Benefits and problems,” 2003. [14] T. Bj¨orkholm and J. Bj¨orkholm, Kanban in 30 days. Packt Publishing Ltd, 2015. [15] D. Spinellis, “Version control systems,” IEEE software, vol. 22, no. 5, pp. 108–109, 2005. [16] A. Hejlsberg, M. Torgersen, S. Wiltamuth, and P. Golde, The C# programming language. Pearson Education, 2008. [17] P. Wegner, “Concepts and paradigms of object-oriented programming,” ACM Sigplan Oops Messenger, vol. 1, no. 1, pp. 7–87, 1990. [18] S. Lantinga, “Simple directmedia layer,” http://www. libsdl. org/, 2007. [19] I. Challenger-P´erez, Y. D´ıaz-Ricardo, and R. A. Becerra-Garc´ıa, “El lenguaje de programaci´on python,” Ciencias Holgu´ın, vol. 20, no. 2, pp. 1–13, 2014. [20] L. Bassett, Introduction to JavaScript object notation: a to-the-point guide to JSON. O’Reilly Media, Inc., 2015. [21] P. Sbarski and S. Kroonenburg, Serverless architectures on AWS: with examples using Aws Lambda. Simon and Schuster, 2017. [22] O. S. G. G´omez, “Paradigma de programaci´on dirigido por eventos,” 2007. [23] M. Niranjanamurthy, U. Archana, K. Niveditha, S. A. Jafar, and N. Shravan, “The research study on dynamodb—nosql database service,” Int. J. Comput. Sci. Mob. Comput, vol. 3, no. 10, pp. 268–279, 2014. [24] P. Mileff, “Game loop: the heart of the game engine,” Production Systems and Information Engineering, vol. 11, no. 3, pp. 51–63, 2023. [25] T. Rentsch, “Object oriented programming,” ACM Sigplan Notices, vol. 17, no. 9, pp. 51–57, 1982.