TECNOLOGÍAS WEB PARA LA CREACIÓN DE UNA 
HERRAMIENTA DE ENSEÑANZA DE CONCEPTOS DE 

PROGRAMACIÓN A TRAVÉS DE UN VIDEOJUEGO 

WEB TECHNOLOGIES FOR THE CREATION OF A 
TOOL FOR TEACHING PROGRAMMING CONCEPTS 

THROUGH A VIDEO GAME 
 

 
 

TRABAJO FIN DE GRADO 
CURSO 2023-2024 

 
AUTORES 

NICOLAS ESPINOSA MOOSER 
SANTIAGO MORAL SANTORIO 

SAMUEL ALEJANDRO PARRA CALDERÓN 
DIEGO ÁLVAREZ CARRETERO 

 
DIRECTORES 

IVÁN MARTÍNEZ ORTIZ, ANTONIO CALVO MORATA 
 

GRADO EN INGENIERÍA DEL SOFTWARE 
FACULTAD DE INFORMÁTICA 

UNIVERSIDAD COMPLUTENSE DE MADRID 



 

 
TECNOLOGÍAS WEB PARA LA CREACIÓN DE 

UNA HERRAMIENTA DE ENSEÑANZA DE 
CONCEPTOS DE PROGRAMACIÓN A TRAVÉS 

DE UN VIDEOJUEGO 
WEB TECHNOLOGIES FOR THE CREATION OF A 

TOOL FOR TEACHING PROGRAMMING 
CONCEPTS THROUGH A VIDEO GAME 

 
TRABAJO DE FIN DE GRADO EN INGENIERÍA DEL SOFTWARE  

 
AUTORES 

NICOLAS ESPINOSA MOOSER 
SANTIAGO MORAL SANTORIO 

SAMUEL ALEJANDRO PARRA CALDERÓN 
DIEGO ÁLVAREZ CARRETERO 

 
DIRECTORES 

IVÁN MARTÍNEZ ORTIZ, ANTONIO CALVO MORATA 
 

CONVOCATORIA: JUNIO 2024 
 

GRADO EN INGENIERÍA DEL SOFTWARE 
FACULTAD DE INFORMÁTICA 

UNIVERSIDAD COMPLUTENSE DE MADRID 
 

27 DE MAYO DE 2024 

 





 III 

DEDICATION 

To all of the students in the trenches who 

have not yet found their ninja star. 





 V 

ACKNOWLEDGEMENTS 

This thesis would not have been possible without the support and guidance of 

many individuals who contributed their time, knowledge, and resources. 

First and foremost, we would like to express our deepest gratitude to our advisors, 

Iván Martínez Ortiz, and Antonio Calvo Morata, for their unwavering support, guidance, 

and insightful feedback throughout the course of the year. We valued their quips and 

their (great) patience. 

We are also profoundly thankful to the young adults who came to test our project, 

as well as the two doctoral students who gave us their insights. 

Another mention goes to Grace McLaren Rutherford for their design expertise, 

help, and support during the development of this project. 

Finally, we are forever grateful to our families for their unconditional love and 

support. Thank you for believing in us and for your constant encouragement throughout 

our studies. 

Thank you all.





 VII 

RESUMEN 

TECNOLOGÍAS WEB PARA LA CREACIÓN DE UNA HERRAMIENTA DE ENSEÑANZA DE 

CONCEPTOS DE PROGRAMACIÓN A TRAVÉS DE UN VIDEOJUEGO 

Debido al creciente uso de las tecnologías en la vida cotidiana y en diversos 

campos, en los últimos años se ha acentuado la necesidad de impartir enseñanza 

relacionada con la informática en las escuelas. Ha habido una creciente necesidad de 

herramientas para enseñar programación y desarrollar habilidades de pensamiento 

computacional durante la educación obligatoria. Los Juegos Serios han demostrado ser 

una herramienta educativa y formativa eficaz que ha sido aplicada en multitud de 

campos, como la educación y la salud, y ser utilizada como herramienta para enseñar 

conceptos básicos de programación de una forma atractiva. 

Por ello, el objetivo principal de este proyecto es utilizar los conocimientos 

técnicos adquiridos durante el grado para diseñar y desarrollar una plataforma que sirva 

como introducción a los conceptos de programación a través de Juegos Serios en las 

aulas, así como proporcionar analíticas a los profesores del progreso de aprendizaje de 

los alumnos. 

Con este objetivo en mente, se realizó un análisis del estado actual de la 

utilización de la tecnología en las aulas, así como de iniciativas anteriores de naturaleza 

similar. A continuación, se diseñó e implementó una plataforma web que permitiera a 

los alumnos asimilar conceptos informáticos a través de un juego interactivo. Tras el 

diseño, se desarrolló la plataforma y se probó con usuarios objetivo, con el fin de evaluar 

la viabilidad de la herramienta. 

Palabras clave 

Juegos Serios, Programación, Aplicaciones Web, Ciencias de la computación, 

Educación, Herramientas 





 IX 

ABSTRACT 

WEB TECHNOLOGIES FOR THE CREATION OF A TOOL FOR TEACHING PROGRAMMING 

CONCEPTS THROUGH A VIDEO GAME 

Due to the growing use of technologies in everyday life and in various fields, the 

need for computer science-related education in schools has been emphasized in recent 

years. There has been a growing need for tools to teach programming and develop 

computational thinking skills during mandatory education. Serious Games have proven 

to be an effective educational and training tool that has been applied in a multitude of 

fields, such as education and health, and be used as a tool to teach programming basic 

concepts in an attractive way. 

Therefore, the main goal of this project is to use the technical knowledge acquired 

during the degree to design and develop a platform that serves as an introduction to 

programming concepts through Serious Games in classrooms as well as provide analytics 

to teachers of students’ learning progress. 

With this objective in mind, an analysis was conducted on the current state of 

technology utilization in classrooms, along with past initiatives of a similar nature. Then, a 

web platform was designed and implemented to enable students to grasp computing 

concepts through interactive gameplay. Following design, the platform was then 

developed and tested with target users, with the aim of assessing the viability of the tool. 

Keywords 

Serious Games, Programming, Web application, computational thinking, 

Education, Teaching tools 

 

 



 X 

TABLE OF CONTENTS 

 

Dedication ............................................................................................................................... III 

Acknowledgements ................................................................................................................ V 

Resumen ................................................................................................................................. VII 

Abstract ................................................................................................................................... IX 

Table of Contents .................................................................................................................... X 

Figures Index ......................................................................................................................... XIV 

Tables Index ......................................................................................................................... XVII 

Chapter 1 - Introduction ..................................................................................................19 

1.1 Motivation .....................................................................................................................19 

1.2 Objectives .....................................................................................................................19 

1.3 Work Plan .......................................................................................................................20 

1.3.1 Domain Study .........................................................................................................20 

1.3.2 Design......................................................................................................................21 

1.3.3 Development..........................................................................................................21 

1.3.4 Validation ................................................................................................................21 

1.4 Work Methodology .......................................................................................................21 

1.4.1 Planning ..................................................................................................................22 

1.4.2 Workflow .................................................................................................................23 

1.4.3 Development Environment ...................................................................................25 

Introducción ............................................................................................................................26 

1.5 Motivación ....................................................................................................................26 

1.6 Objetivos ........................................................................................................................26 



 XI 

1.7 Plan de trabajo .............................................................................................................27 

1.7.1 Estudio de Dominio ................................................................................................27 

1.7.2 Diseño ......................................................................................................................28 

1.7.3 Desarrollo ................................................................................................................28 

1.7.4 Validación ..............................................................................................................28 

1.8 Metodología de Trabajo ..............................................................................................28 

1.8.1 Planificación ...........................................................................................................29 

1.8.2 Flujo de Trabajo ......................................................................................................31 

1.8.3 Entorno de Desarrollo ............................................................................................33 

Chapter 2 - Domain Study ...............................................................................................34 

2.1 Digital Education in Spain ............................................................................................34 

2.2 Serious Games ...............................................................................................................35 

2.2.1 Articoding ...............................................................................................................35 

2.2.2 Light Bot ..................................................................................................................37 

2.2.3 CodeCombat .........................................................................................................38 

2.2.4 Scratch ....................................................................................................................40 

Chapter 3 - Proposed Solution ........................................................................................42 

3.1 Problems of Existing Solutions .......................................................................................42 

3.2 Solution ..........................................................................................................................42 

3.3 Required Features .........................................................................................................43 

3.3.1 Categorized Puzzles ...............................................................................................43 

3.3.2 Progress Tracking ....................................................................................................44 

3.3.3 Community .............................................................................................................44 

3.3.4 Educator Toolset .....................................................................................................44 

3.3.5 Offline Functionality ...............................................................................................45 



 XII 

3.3.6 Accessibility.............................................................................................................45 

3.3.7 Low System Requirements .....................................................................................45 

3.4 Design ............................................................................................................................45 

3.4.1 Serious Game Design .............................................................................................46 

3.4.2 Web application Design ........................................................................................49 

3.4.3 Database Creation ................................................................................................51 

3.5 Added Value.................................................................................................................53 

Chapter 4 - Development ...............................................................................................55 

4.1 Architecture ..................................................................................................................55 

4.2 Server .............................................................................................................................56 

4.2.1 Webserver ...............................................................................................................56 

4.2.2 RESTful API ...............................................................................................................57 

4.2.3 Authorization and cookies .....................................................................................58 

4.2.4 Sequelize .................................................................................................................60 

4.2.5 Testing Suite ............................................................................................................61 

4.3 Client ..............................................................................................................................63 

4.3.1 Platform Interface ..................................................................................................64 

4.3.2 SPA Router ..............................................................................................................66 

4.3.3 Game Controller ....................................................................................................66 

4.3.4 Service Worker ........................................................................................................74 

4.3.5 xAPI ..........................................................................................................................76 

4.3.6 Web tour .................................................................................................................83 

Chapter 5 - Validation .....................................................................................................85 

5.1 Session Details ...............................................................................................................86 

5.2 Feedback & Errors .........................................................................................................87 



 XIII 

5.3 Data Analysis .................................................................................................................87 

5.4 Conclusions ...................................................................................................................93 

Chapter 6 - Personal Contributions .................................................................................94 

6.1 Collaborative work .......................................................................................................94 

Chapter 7 - Conclusions and Future Work ................................................................... 103 

7.1 Conclusions ................................................................................................................. 103 

7.2 Future Work .................................................................................................................. 104 

7.2.1 Private levels ......................................................................................................... 104 

7.2.2 Advanced level sharing ...................................................................................... 104 

7.2.3 Group creation ..................................................................................................... 104 

7.2.4 Lockdown Mode .................................................................................................. 105 

7.2.5 Improve RESTful API endpoints ............................................................................ 105 

7.2.6 Sequelize Migrations ............................................................................................ 106 

Bibliography .......................................................................................................................... 107 

Appendixes ........................................................................................................................... 109 

 

 



 XIV 

FIGURES INDEX 

Figure 1-1 Gantt Diagram as an estimation of the project. ................................................20 

Figure 1-2: GitHub Projects’ Kanban Board. .........................................................................22 

Figure 1-3: Example of task details. .......................................................................................23 

Figure 1-4: Project Branch structure. .....................................................................................24 

Figure 2-1 Example Articoding level. .....................................................................................36 

Figure 2-2 Example Light Bot level. ........................................................................................37 

Figure 2-3 Example CodeCombat level. ..............................................................................39 

Figure 2-4 Example scratch workspace. ...............................................................................41 

Figure 3-1 initial game interface. ...........................................................................................46 

Figure 3-2 Initial design for the ‘Create’ puzzle zone. ..........................................................48 

Figure 3-3 Final design for the ‘Create’ puzzle zone. ...........................................................49 

Figure 3-4 Initial home page design. .....................................................................................50 

Figure 3-5 Final home page design. ......................................................................................51 

Figure 3-6 Final database design. .........................................................................................52 

Figure 3-7 Logical design of database schema. .................................................................53 

Figure 4-1 Simplified architecture diagram. .........................................................................55 

Figure 4-2 Display of the BlockLeap OpenAPI file. ...............................................................58 

Figure 4-3 Cookies used in BlockLeap. ..................................................................................59 

Figure 4-4 Sequelize model folder system. ............................................................................60 

Figure 4-5 Test result. ...............................................................................................................62 

Figure 4-6 Files percentage of usage. ...................................................................................62 

Figure 4-7 Initial home page design. .....................................................................................64 

Figure 4-8 Final navigation bar design. .................................................................................64 



 XV 

Figure 4-9 Final home page developed. ..............................................................................65 

Figure 4-10 Alternative design for home page with locked categories. ...........................65 

Figure 4-11 A category page, showing the levels in it. ........................................................66 

Figure 4-12 Example of Phaser’s 'Play' scene with the additional 'Clone' and 'Speed 

Modifier' features. ...........................................................................................................67 

Figure 4-13 Initial 'Create' scene design. ..............................................................................68 

Figure 4-14 Interaction with RexUI’s developer. ...................................................................69 

Figure 4-15 Testing with RexUI toolbox that was discarded. ................................................70 

Figure 4-16 Final 'Create' scene design. ...............................................................................71 

Figure 4-17 Blockly toolbox limited to Actions and Variables categories. .........................72 

Figure 4-18 Blockly workspace with 'Run' and 'Stop' buttons. .............................................73 

Figure 4-19 Interface showing cached levels when lacking internet connectivity. ..........75 

Figure 4-20 Message shown when new Service Worker version is detected. ....................75 

Figure 4-21 Example of traces collected in BlockLeap in xAPI format. ..............................78 

Figure 4-22 Example of traces collected in BlockLeap in xAPI format. ..............................79 

Figure 4-23 Web tour shown the first time a puzzle is played. .............................................84 

Figure 4-24 Actions available in 'Play' section, including 'Help'. .........................................84 

Figure 5-1 Project members during the validation session. .................................................85 

Figure 5-2 Students testing BlockLeap. ..................................................................................86 

Figure 5-3 Participant age distribution. .................................................................................88 

Figure 5-4  Participant responses to BlockLeap’s level of simplicity....................................88 

Figure 5-5 Perceived usefulness of BlockLeap to participants. ...........................................89 

Figure 5-6  Perceived intuitiveness of BlockLeap to participants. .......................................90 

Figure 5-7 Perceived enjoyability of BlockLeap to participants. ........................................90 

Figure 5-8 Participant responses to BlockLeap’s level of difficulty......................................91 



 XVI 

Figure 5-9 Participant responses to BlockLeap’s interface and graphics. .........................92 

 



 XVII 

TABLES INDEX 

Table 4-1 Table of xAPI traces used in BlockLeap. ...............................................................82 

 





 

 

19 

Chapter 1 - Introduction 

1.1 Motivation 

As technology becomes more and more integrated into society, there is a growing 

need for it to become part of education systems world-wide. This motivates this project 

to make use of a ‘Serious Game’ to make the learning experience more enjoyable. This 

project is also motivated by an existing solution, Articoding, and the limitations 

discovered, primarily the technical requirements and deployment complexity. 

A Serious Game, also known as an applied game, is a video game which is 

designed with a purpose beyond entertainment. The term "serious" typically denotes 

video games utilized across various industries such as education, scientific exploration, 

healthcare, etc. Serious Games were built upon the concept of educational simulations, 

including flight simulation and medical simulation, but in the context of this project, a 

Serious Game is considered a game with an emphasis on educational value derived from 

fun and competition. 

1.2 Objectives 

The main goal of the project is to create a web-based platform for use in 

educational institutions that utilizes gamification to develop programming skills in young 

adults. To fulfill this goal the project proposes some specific requirements: 

- Analyze Serious Games and existing solutions with a similar goal with the 

intention of analyzing key elements and any missing features, tools, or 

improvements that should be implemented as part of this project. 

- Ensure its usability in educational environments, specifically reducing system 

requirements needed to be run on the often low-end or antiquated computers 

normally found in high schools. 

- Provide educators with a set of tools that can be used as part of their 

curriculum to teach programming, gather feedback, and evaluate their 

students' performance. 



 

 

20 

- Incorporate a layer of educational data analytics, enabling researchers, 

teachers, and administrators to collect and analyze data pertinent to student 

engagement and patterns, like time spent on each level of the game, what 

actions were taken, how many attempts were needed to succeed (by each 

student), and so on. 

1.3 Work Plan 

A multi-phase plan was established at the beginning of the project to create a 

simplified plan of action, and the associated Gantt diagram can be appreciated in 

Figure 1-1 below, as an estimate of the project’s phases.  

 

Figure 1-1 Gantt Diagram as an estimation of the project. 

The following sections explore each of these phases in detail.  

1.3.1 Domain Study 

As a prerequisite to the design and development, a non-exhaustive analysis of 

existing educational platforms and Serious Games was done and is reported in Chapter 

2 - Domain Study. The analysis focused on educational Serious Games and platforms for 

learning programing, in order to identify common features. Additionally, missing features 

or possible improvements were also investigated. 



 

 

21 

1.3.2 Design 

After completing the analysis, a design phase was conducted to define the 

features of both the Serious Game and the web platform. This phase included the design 

of the project’s Serious Game and its mechanics, the application’s webpage interface, 

and the server-side requirements. Initial drafts were established for reference, as the 

project’s agile methodology allowed for iterations and changes to occur during the 

duration of the project. This phase is outlined in Chapter 3 - Proposed Solution. 

1.3.3 Development 

The development phase detailed in Chapter 4 - Development describes how the 

identified features were implemented, tested, and deployed internally with multiple 

milestones, including exploration, minimum viable product, and stable beta version. This 

phase also considers the tool exploration phase, which encompasses the selection of 

technologies and dependencies for the project. 

1.3.4 Validation 

Following the completion of the development phase, a stable version was 

deployed and tested by a group of high school students. The validation phase allowed 

the detection of bugs, missing features, and possible improvements. This helped establish 

future feature prioritization based on user feedback. The validation phase is detailed in 

Chapter 5 - Validation and future features in Chapter 7 - Conclusions and Future Work. 

1.4 Work Methodology 

To attain the project’s objectives, the Kanban methodology was employed. The 

Kanban methodology is an agile approach to project management that emphasizes 

continuous improvement, flexibility in task management, and optimized workflow.  It 

revolves around visualizing the entire project through a Kanban board, which serves as a 

graphical representation of the project's tasks and their progress. It was chosen to allow 

for easy understanding of the status of the project, including tasks in progress, future tasks, 

and completed tasks. 



 

 

22 

The Kanban board typically consists of columns representing different stages of 

work, with tasks represented by cards that move through these columns from left to right 

as they progress toward completion. One of the key principles of Kanban is limiting work 

in progress (WIP) to maintain consistent standards and ensure that the amount of work 

matches the team's capacity. This means that no member can have more active tasks 

than were set prior to the projects’ start. By focusing on incremental improvements and 

responding to changing priorities, Kanban helps teams deliver value more efficiently and 

effectively. 

1.4.1 Planning 

The Kanban board and project were hosted in GitHub Projects due to its high 

integration with GitHub’s which uses git, a Version Control System (VSC). GitHub Projects 

provides a simple, shared Kanban board where tasks were introduced and updated 

accordingly. All tasks contained the primary fields title, description, stage, and epic. The 

title was used to identify tasks, descriptions detailed requirements or subtasks, the stage 

defined the status, and the epic grouped similar tasks into general feature categories.  

This project created custom stages to denote the possible states of a task: “Todo”, “In 

Progress” and “Done”. An example of the Kanban board used, its interface, and epics 

are shown in Figure 1-2: GitHub Projects’ Kanban Board. 

 

Figure 1-2: GitHub Projects’ Kanban Board. 



 

 

23 

Additional fields were also created in tasks to add useful information, particularly 

a priority, and an estimated effort required to complete the task. The priorities defined 

were “Low”, “Medium”, and “High”. This organization allowed the project to progress 

quickly and avoid the overhead of strict organizational structures as well as ensuring 

access to up-to-date information on the status of the project for all members. An 

example of this can be found in Figure 1-3 below. 

 

Figure 1-3: Example of task details. 

1.4.2 Workflow 

Following an agile development methodology, the project established sprints with 

a duration of 2 weeks. Milestones were created during organizational meetings with the 

project’s directors at the start of each sprint. The project authors conducted weekly 

meetings at the mid-point of each sprint to internally assess progress and allow for 

collaboration in more advanced tasks. At the end of sprints, progress was assessed in 

conjunction with the project directors and new milestones, task priorities and task 

assignments were set. 

Connected to the project’s Kanban planification on GitHub pages, GitHub’s VCS 

was used to track changes and collaborate during development. The 3-branch structure 

depicted in Figure 1-4 was used in GitHub to establish a development workflow. 



 

 

24 

 

Figure 1-4: Project Branch structure. 

The main branch, depicted by green nodes, symbolizes the project's stable 

production version. It serves as the foundation for Continuous Integration (CI) and 

Continuous Deployment (CD) processes. The blue nodes represent the development 

branch, where changes are integrated and tested in a CI environment before 

deployment. This branch acts as a staging area for ongoing development work. 

Specific features or issues, illustrated by orange nodes, are worked on by individual 

developers in separate branches, and undergo CI testing to ensure their functionality 

and compatibility with the overall codebase. Before merging a feature into the 

development branch, developers create a Pull Request (PR) as a formal request to 

merge changes from one branch into another. Before being able to merge a PR to the 

development or main branches, other project members must review the proposed 

changes, discuss any potential issues, and ensure code quality. As part of the CI/CD 

process, the development branch was automatically deployed to GitHub’s Pages by 

GitHub Actions1 when a PR was merged into the development branch. 

 

1 https://pages.github.com/ 



 

 

25 

1.4.3 Development Environment 

This section details the integrated development environment (IDE) and other tools 

such as communication software used during the development phase of the project.  

Visual Studio Code (VS Code) was chosen as the project’s IDE for its tight 

integration with GitHub, extensive support for various programming languages, and 

varied extensions library. Extensions such as Live-Server, and Live-Share allowed for quick 

development, collaborative work, and local testing. 

In addition to VS Code, the open-source tool Xampp2 was used to host a 

development database locally and simplify development. 

Communication between the project’s authors was conducted through the free 

messaging and voice chat app Discord3. It allowed for text and video communication 

and worked as a channel to communicate quickly, such as when sharing useful resources 

or short snippets of code. During sprint planning and assessment meetings with the 

project’s directors, Google Meet4, the successor to Google Hangouts5, was used to 

communicate with remote participants, who were unable to attend the meetings in-

person due to schedule conflicts. Although similar to Discord’s video chat, Discord 

offered the advantage of persistent chat and was thus the preferred communication 

tool for the project’s authors. 

  

 

2 https://www.apachefriends.org/index.html 

3 https://discord.com/ 

4 https://meet.google.com/ 

5 https://hangouts.google.com/ 



 

 

26 

Introducción 

1.5 Motivación 

A medida que la tecnología se integra más y más en la sociedad, crece la 

necesidad de que forme parte de los sistemas educativos. Esto motiva este proyecto 

para hacer uso de un 'Juego Serio' para hacer la experiencia de aprendizaje más 

agradable. Este proyecto también está motivado por una solución existente, Articoding, 

y las limitaciones descubiertas, principalmente los requisitos técnicos y la complejidad 

de despliegue. 

Un Juegos Serio, también conocido como juego aplicado, es un videojuego 

diseñado con un propósito que va más allá del entretenimiento. El término "serio" suele 

referirse a videojuegos utilizados en diversos sectores, como la educación, la exploración 

científica, la sanidad, etc. Los Juegos Serios se crearon a partir del concepto de 

simulaciones educativas, como la simulación de vuelo y la simulación médica, pero en 

el contexto de este proyecto, un Juegos Serio se considera un juego con énfasis en el 

valor educativo derivado de la diversión y la competición. 

1.6 Objetivos 

El objetivo principal del proyecto es crear una plataforma web para su uso en 

instituciones educativas que utilice la gamificación para desarrollar habilidades de 

programación en jóvenes adultos. Para cumplir este objetivo, el proyecto propone 

algunos requisitos específicos: 

- Analizar Juegos Serios y soluciones existentes con un objetivo similar con la 

intención de analizar los elementos clave y cualquier característica, 

herramienta o mejora que falte y que debería implementarse como parte de 

este proyecto. 

- Garantizar su usabilidad en entornos educativos, concretamente reduciendo 

los requisitos del sistema necesarios para ejecutarse en los ordenadores, a 

menudo de gama baja o anticuados, que suelen encontrarse en los institutos. 



 

 

27 

- Proporcionar a los educadores un conjunto de herramientas que puedan 

utilizar como parte de su plan de estudios para enseñar a programar, recopilar 

comentarios y evaluar el rendimiento de sus alumnos. 

- Incorporar una capa de análisis de datos educativos que permita a 

investigadores, profesores y administradores recopilar y analizar datos relativos 

a la participación y los patrones de los estudiantes, como el tiempo dedicado 

a cada nivel del juego, las acciones realizadas, el número de intentos 

necesarios para tener éxito (por cada estudiante), etc. 

1.7 Plan de trabajo 

 Al inicio del proyecto se estableció un plan multifásico para crear un plan de 

acción simplificado, y el diagrama de Gantt asociado puede apreciarse en la ilustración 

0-1, a modo de estimación de las fases del proyecto. 

 

Ilustración 0-1: Diagrama de Gantt como estimación del proyecto. 

 Las fases del plan descritas en el diagrama son exploradas en detalle en esta 

sección. 

1.7.1 Estudio de Dominio 

Como requisito previo para el diseño y desarrollo, se realizó un análisis no 

exhaustivo de las plataformas educativas y los Juegos Serios existentes, que se recoge 

en el Capítulo 2 - Estudio de dominio. El análisis se centró en Juegos Serios educativos y 



 

 

28 

plataformas para el aprendizaje de programación, con el fin de identificar las 

características comunes. Además, también se investigaron las características que 

faltaban o las posibles mejoras. 

1.7.2 Diseño 

Tras completar el análisis, se llevó a cabo una fase de diseño para definir las 

características tanto del Juegos Serio como de la plataforma web. Esta fase incluyó el 

diseño del Juegos Serio del proyecto y su mecánica, la interfaz de la página web de la 

aplicación y los requisitos del lado del servidor. Se establecieron borradores iniciales 

como referencia, ya que la metodología ágil del proyecto permitía iteraciones y 

cambios durante la duración del proyecto. Esta fase se describe en el Capítulo 3 - 

Solución propuesta. 

1.7.3 Desarrollo 

La fase de desarrollo detallada en el Capítulo 4 – Desarrollo, describe cómo se 

implementaron, probaron y desplegaron internamente las características identificadas 

con múltiples hitos, incluyendo la exploración, el producto mínimo viable y la versión 

beta estable. Esta fase también considera la fase de exploración de herramientas, que 

abarca la selección de tecnologías y dependencias para el proyecto. 

1.7.4 Validación 

Tras la finalización de la fase de desarrollo, se desplegó una versión estable que 

fue probada por un grupo de estudiantes de secundaria. La fase de validación permitió 

detectar errores, características ausentes y posibles mejoras. Esto ayudó a establecer la 

priorización de futuras características basándose en los comentarios de los usuarios. La 

fase de validación se detalla en el Capítulo 5 - Validación y las futuras características en 

el Capítulo 7 - Conclusiones y trabajo futuro. 

1.8 Metodología de Trabajo 

Para alcanzar los objetivos del proyecto se empleó la metodología Kanban. La 

metodología Kanban es un enfoque ágil de la gestión de proyectos que hace hincapié 



 

 

29 

en la mejora continua, la flexibilidad en la gestión de tareas y la optimización del flujo 

de trabajo.  Gira en torno a la visualización de todo el proyecto a través de un tablero 

Kanban, que sirve como representación gráfica de las tareas del proyecto y su progreso. 

Se eligió para permitir una fácil comprensión del estado del proyecto, incluidas las tareas 

en curso, las tareas futuras y las tareas completadas. 

El tablero Kanban suele constar de columnas que representan distintas fases de 

trabajo, con tareas representadas por tarjetas que se desplazan por estas columnas de 

izquierda a derecha a medida que avanzan hacia su finalización. Uno de los principios 

clave de Kanban es limitar el trabajo en curso (WIP) para mantener unos estándares 

coherentes y garantizar que la cantidad de trabajo se ajusta a la capacidad del equipo. 

Esto significa que ningún miembro puede tener más tareas activas de las que se fijaron 

antes del inicio de los proyectos. Al centrarse en mejoras incrementales y responder a 

prioridades cambiantes, Kanban ayuda a los equipos a ofrecer valor de forma más 

eficiente y eficaz. 

1.8.1 Planificación 

El tablero Kanban y el proyecto se alojaron en GitHub Projects debido a su alta 

integración con GitHub's que utiliza git, un Sistema de Control de Versiones (SCV). GitHub 

Projects proporciona un tablero Kanban sencillo y compartido en el que se introdujeron 

y actualizaron las tareas. Todas las tareas contenían los campos primarios título, 

descripción, etapa y épica. El título se utilizaba para identificar las tareas, las 

descripciones detallaban los requisitos o las subtareas, la etapa definía el estado y la 

épica agrupaba tareas similares en categorías de características generales.  Este 

proyecto creó etapas personalizadas para denotar los posibles estados de una tarea: 

“Todo”, “In Progress” y “Done”. En la ilustración 0-2 se muestra un ejemplo del tablero 



 

 

30 

Kanban utilizado, su interfaz y las epopeyas: Tablero Kanban de los proyectos de GitHub.

 

Ilustración 0-2: Tablero Kanban utilizado en proyecto. 

También se crearon campos adicionales en las tareas para añadir información 

útil, en particular una prioridad, y una estimación del esfuerzo necesario para completar 

la tarea. Las prioridades definidas fueron “Low”, “Medium”, y “High”. Esta organización 

permitió que el proyecto avanzara con rapidez y evitar la sobrecarga de estructuras 

organizativas estrictas, además de garantizar a todos los miembros el acceso a 

información actualizada sobre el estado del proyecto. Un ejemplo de ello puede verse 

en la Ilustración 0-3. 

 



 

 

31 

 

Ilustración 0-3: ejemplo de tarea detallada. 

1.8.2 Flujo de Trabajo 

Siguiendo una metodología de desarrollo ágil, el proyecto estableció sprints con 

una duración de 2 semanas. Los hitos se crearon durante reuniones organizativas con los 

directores del proyecto al inicio de cada sprint. Los autores del proyecto celebraron 

reuniones semanales a mitad de cada sprint para evaluar internamente los progresos y 

permitir la colaboración en tareas más avanzadas. Al final de los sprints, se evaluaban 

los progresos junto con los directores del proyecto y se establecían nuevos hitos, 

prioridades de tareas y asignaciones de tareas. 

Conectado a nuestra planificación Kanban en las páginas de GitHub, se utilizó el 

VCS de GitHub para realizar un seguimiento de los cambios y colaborar durante el 

desarrollo. La estructura de 3 ramas representada en la ilustración 0-4 se utilizó en GitHub 

para establecer un flujo de trabajo de desarrollo. 



 

 

32 

 

Ilustración 0-4: Estructura de ramas para el proyecto. 

 La rama principal, representada por nodos verdes, simboliza la versión de 

producción estable del proyecto. Sirve de base para los procesos de integración 

continua (IC) y despliegue continuo (DC). Los nodos azules representan la rama de 

desarrollo, donde los cambios se integran y prueban en un entorno de integración 

continua antes de su despliegue. Esta rama actúa como área de preparación para el 

trabajo de desarrollo en curso. 

Las funciones o problemas específicos, ilustrados por los nodos naranjas, son 

trabajados por desarrolladores individuales en ramas separadas, y se someten a pruebas 

de CI para garantizar su funcionalidad y compatibilidad con el código base general. 

Antes de incorporar una función a la rama de desarrollo, los desarrolladores crean un 

Pull Request (PR) como solicitud formal para incorporar los cambios de una rama a otra. 

Antes de poder fusionar una PR en la rama de desarrollo o en la principal, otros miembros 

del proyecto deben revisar los cambios propuestos, discutir cualquier problema 

potencial y garantizar la calidad del código. Como parte del proceso CI/CD, GitHub 

Actions6 despliega automáticamente la rama de desarrollo en GitHub Pages cuando se 

fusiona un PR en la rama de desarrollo. 

 

6 https://pages.github.com/  

https://pages.github.com/


 

 

33 

1.8.3 Entorno de Desarrollo 

En esta sección se detalla el entorno de desarrollo integrado (IDE) y otras 

herramientas como el software de comunicación utilizado durante la fase de desarrollo 

del proyecto.  

Se eligió Visual Studio Code (VS Code) como IDE del proyecto por su estrecha 

integración con GitHub, su amplia compatibilidad con varios lenguajes de 

programación y su variada biblioteca de extensiones. Extensiones como Live-Server y 

Live-Share permitieron un desarrollo rápido, trabajo colaborativo y pruebas locales. 

Además de VS Code, se utilizó la herramienta de código abierto Xampp7 para 

alojar localmente una base de datos de desarrollo y simplificar el desarrollo. 

La comunicación entre los autores del proyecto se realizó a través de la 

aplicación gratuita de mensajería y chat de voz Discord8. Permitía la comunicación por 

texto y vídeo y funcionaba como un canal para comunicarse rápidamente, como 

cuando se compartían recursos útiles o pequeños fragmentos de código. Durante las 

reuniones de planificación y evaluación de sprints con los directores del proyecto, se 

utilizó Google Meet9, el sucesor de Google Hangouts10, para comunicarse con los 

participantes remotos, que no podían asistir a las reuniones en persona debido a 

conflictos de agenda. Aunque similar al chat de vídeo de Discord, Discord ofrecía la 

ventaja del chat persistente, por lo que fue la herramienta de comunicación preferida 

por los autores del proyecto.  

 

7 https://www.apachefriends.org/index.html  

8 https://discord.com/  

9 https://meet.google.com/  

10 https://hangouts.google.com/  

https://www.apachefriends.org/index.html
https://discord.com/
https://meet.google.com/
https://hangouts.google.com/


 

 

34 

Chapter 2 - Domain Study 

In the current educational model, the combination of technology with teaching 

methodologies has become increasingly relevant when it comes to teaching required 

skills in the modern era. Below, the issue in the Spanish educational system is analyzed 

and how this project’s proposal based on the application of a Serious Game can be 

used to address the issue. 

2.1 Digital Education in Spain 

Being a part of the Organisation for Economic Co-operation and Development 

(OECD) [1], Spain participates in the Programme for International Student Assessment 

(PISA), which evaluates whether 15-year-old students have acquired key knowledge and 

skills. [2] In the PISA 2022 assessment, Spain achieved 473 points, statistically similar to 

Germany, France, and the United States among others. Given that in Spain’s education 

system programming and computational thinking have traditionally been supplementary 

subjects, the introduction of the test “Learning in the Digital World” in [3] PISA’s 2025 

assessment might see Spain achieve a lower score. This test will evaluate students’ 

capacities in “self-regulated learning” and “computational and scientific inquiry 

practices”, [3] including the use of digital tools and solving problems with computational 

thinking. Despite these developments and an ever-increasing requirement for 

technological education, Spain still lacks comprehensive integration of technology in its 

curriculum.  

This project proposes the implementation of gamification techniques and Game-

Based Learning (GBL) methodologies through Serious Games in Spain’s education 

system. There is an opportunity to leverage video games not only for learning 

programming but also for addressing broader societal issues and promoting interest in 

STEM disciplines, especially among underrepresented groups like girls [4]. Research 

suggests that girls who play video games are more likely to choose STEM disciplines, 

highlighting the potential of video games to influence career choices and educational 



 

 

35 

pathways. Thus, this project aims to create an accessible serious game as an educational 

tool to increase technological education in Spain’s education system. 

2.2 Serious Games 

An analysis of existing Serious Games was conducted to identify key aspects and 

any missing features, tools, or improvements to be considered during the design and 

development of the project. The scope of this analysis has limited to Serious Games, and 

more specifically Serious Games related to teaching programming. 

2.2.1 Articoding 

Articoding is a Serious Game from the Complutense University of Madrid’s research 

group e-UCM with the objective of creating a game to integrate into Spain’s education 

system. It was developed with Unity from 2020 to 2021 as part of the project “Serious 

Games to Promote Computational Thinking and Coding” and further developed from 

2021 to 2022 as part of “Using Serious Games to improve programming learning at the 

school”. [5] The first project established the base of the game Articoding and the second 

implemented additional functionality and improvements. 

Its functionality consisted of a series of puzzles that users solved using block-based 

programming, a puzzle builder, and a guide that was unlocked as new elements were 

used in the serious game. The puzzles were categorized to align with key concepts 

typically taught in programming classes such as variables, data types, functions, etc. and 



 

 

36 

ordered in increasing difficulty or complexity, allowing users to gradually progress in their 

learning. 

 

Figure 2-1 Example Articoding level. 

Figure 2-1 shows a Articoding level with the screen clearly divided into the code 

section, on the left-hand side and the map one on the right-hand side. In the code 

section you are free to drag and drop any code block available to structure the program 

meant to solve the problem presented in the puzzle map. The user also has the possibility 

to zoom in and out on the code blocks to better see what’s there. The image also shows 

that the run button is in the top-middle of the screen, and in the top-right corner the 

player can restart the level, check the manual for help or exit and go back to the 

category levels. 

Articoding was tested multiple times in educational environments as a tool to 

teach programming and computational thinking. Initial testing was conducted at the 

Faculty of Computer Science of the Complutense University of Madrid and after various 

iterations of development, the authors performed simulated classes at educational 

institutions in Spain. 



 

 

37 

The first tests made with real users proved that the game could be applied in 

school classes by the teacher in a satisfactory way. The game also maintained the 

interest of the players and, even if some levels could suppose difficult challenges to 

overcome, in general the users said that the difficulty and growth over the time was 

appropriate. 

2.2.2 Light Bot 

Light Bot11 is an educational puzzle video game for learning software programming 

concepts, developed by Danny Yaroslavski. It is available as an online Flash game, and 

an application for Android and iOS mobile phones. 

 

Figure 2-2 Example Light Bot level. 

As the creator, D. Yaroslavski, said in analysis of his application, all the levels of 

Light Bot could be written with a typed language code in an easy way, allowing a simpler 

 

11 LightBot 

https://lightbot.com/


 

 

38 

start in programming languages, since coding is hard because text is scary, in his own 

words [6]. 

Light Bot teaches programming logic by controlling a robot via a simple and 

intuitive set of actions with the aim of reaching some specific cells of the map. 

This game has sequential levels of increasing difficulty that introduce new 

programming concepts as users play through them. In this game, the level upgrade 

barriers are designed to guarantee a proper balance between entertainment, 

motivation, and learning [7]. Similarly to Articoding, it allows users to view the result of 

each command for immediate feedback. 

Figure 2-2 shows the actions on the top right-hand side of the page can be 

dragged to different functions or placed directly into the main method cells. When the 

player finishes placing the different actions, the robot will execute all actions in a left-to-

right order right after the player selects the button located at the left of the second 

function. The player can also regulate the game volume as well as reset the level to try it 

again with other solutions. 

By using this game, a user can learn programming concepts such as loops, 

functions and more, without entering code in any programming language whatsoever. 

2.2.3 CodeCombat 

CodeCombat12 is an educational video game that helps with learning software 

programming concepts and languages, and was founded in February 2013 by George 

Saines, Scott Erickson, Matt Lott, and Nick Winter. Its primary target audience is students 

aged between nine and sixteen years old. 

Through CodeCombat’s web-based videogame, students can learn to type 

coding languages such as JavaScript, Python or HTML while learning the fundamentals 

of computer science. It provides tools for teachers to track the progress of their students, 

 

12 CodeCombat 

https://codecombat.com/


 

 

39 

has a large community of players, and can be played in more than sixty different 

languages. Each level has a different goal that the student must achieve to progress to 

the next level, giving the teacher general statistics of their class, as well as personal 

statistics of each user and time completion. 

 

Figure 2-3 Example CodeCombat level. 

With the completion of the levels, players receive different attributes that are 

necessary to complete further levels. For example, having achieved the exit of the fourth 

level of the first campaign, the player will receive a sword that will let them attack 

enemies in the fifth level. 

Figure 2-3 shows how in the right-hand side the player can code the actions that 

the hero in the map located in the left-hand side will reproduce. On the top left-hand 

side remains a post with the tasks to achieve in each level. On top of the screen the menu 

and the hints appear visible to every player to get help to solve the level. Under the map, 

the game shows a bar that the player can use to see the level progress and to manage 

some visual and auditory options. Finally, there are some explanations about the code 

written right below the code section. 

CodeCombat differs from Articoding and Light Bot as it requires typing out 

commands, rather than using a block-based programming framework. The complexity 



 

 

40 

of this compared to block-based programming is reduced by CodeCombat’s extensive 

web-tour that guides users through all the tools needed, as well as by helpful sounds and 

hints that appear. By just playing just the first campaign, a user can learn different 

programming concepts such as syntax, methods, parameters, strings, loops, and 

variables. 

In addition to the game, players can access accomplished and locked 

achievements, get a view of locked and unlocked heroes, customize items and 

accessories to use in the next levels, join clans to be part of a team or change the 

programming language. 

2.2.4 Scratch 

Although it is not a Serious Game, the community-oriented online platform Scratch 

was analyzed due to its popular use in educational environments and block-based 

Scratch programming language. The Scratch Foundation aims to “create digital stories, 

games, and animations” and “[promote] computational thinking and problem-solving 

skills” with its platform [8]. This project considers the analysis of the Scratch platform 

valuable due to its similarity to this project’s aims. 

The Scratch platform teaches programming through the creation of interactive 

experiences such as videogames, interactive visual novels, etc. Once a project is 

created on the Scratch platform, it can be published to the community to be played, 

with the code publicly accessible so other users can learn from it. This makes Scratch a 

dynamic tool for use in educational environments as it allows educators to create a 

customized curriculum, where they can assign students to create something specific, or 

look at a community project’s code and learn from it. An example from this can be 

appreciated as in Figure 2-4 below, where a mini-game is being portrayed on the right 

on real time, as the user tinkers with it via the blocks, as shown on the left. 



 

 

41 

 

Figure 2-4 Example scratch workspace. 

  



 

 

42 

Chapter 3 - Proposed Solution 

Given the prevalent lack of resources at educational institutions, the goal of this 

project is to build an online block-based puzzle solving serious game that remains a light-

weight alternative to Articoding built around a community-based platform. The project 

aims to implement features similar to successful existing solutions and improve on them. 

3.1 Problems of Existing Solutions 

Although Scratch has achieved large-scale success and is widely used in 

educational environments to teach programming, and Articoding shares many of the 

goals of this project, several aspects do not cover the identified requirements of this 

project. 

The primary limitation of Articoding is one raised by its authors, equipment at an 

educational institution is unlikely to meet the system requirements of a Unity based game, 

regardless of optimization. This was one of the primary conclusions in Articoding’s 

validation phase, and an objective its authors left for future projects such as this. It 

additionally lacks a community aspect, such as sharing puzzles created by users, or a 

toolset for teachers to track student progress. 

Similarly, while Scratch is widely used as a teaching tool, it does not teach 

programming via a Serious Game, it is used as a tool to create projects like visual novels, 

platform games, or other interactive experiences. This project considers the scope of 

Scratch to be too broad for use in educational environments to teach programming. 

3.2 Solution 

Considering the possible improvements in existing solutions, this project presents 

BlockLeap. BlockLeap combines Articoding’s focus on learning programming through a 

Serious Game with Scratch’s web platform, extensive educator toolset, and community 

aspects. Specific requirements considered as part of BlockLeap are detailed below. 



 

 

43 

3.3 Required Features 

This section introduces specific requirements of BlockLeap established through the 

analysis of features in existing Serious Games and possible improvements to these Serious 

Games. These features are considered important to achieve BlockLeap’s goal of 

becoming an educational tool for learning programming and computational thinking. 

3.3.1 Categorized Puzzles 

Similar to Articoding, BlockLeap’s Serious Game will consist of puzzles solvable via 

a block-based programming language. To create a learning structure, these puzzles will 

be categorized into common programming themes and will increase in difficulty 

progressively. This is done as an application of reinforcement learning, as users repeat 

certain skills and use them in different contexts by completing categories and using the 

skills learned in further puzzles. BlockLeap proposes the following categories: 

• Introduction: Familiarize users with the platform’s interface and functionality, as 

well as the simple movement action. 

• Variables: Learn how to store and use data with the creation of different variables 

that would have to be used to complete the levels. 

• Data types: Learn how to use different types of variables such as Booleans or strings 

to solve the levels. 

• Basic operators: Learn mathematical and logical operations that can be done 

with the available data types. 

• Loops: Learn how to code a solution that repeats several times or while a condition 

is met. 

• Conditionals: Learn about conditional code execution. 

• Functions: Learn how to use functions to help organize the code. 

While each category will focus on a programming concept, some aspects of 

previous categories will be required to apply repetition learning and ensure concepts are 

understood. When talking about categories the referred categories are the official ones, 



 

 

44 

the ones that will appear right on the first page as the main content, categories that will 

be created by the team. 

3.3.2 Progress Tracking 

Users should receive feedback to allow them to evaluate their progress and 

success in completing puzzles and learning. BlockLeap proposes a star system to indicate 

different levels of quality or success, as well as a guided progression by forcing the 

completion of levels and categories in a specific order. To achieve this, a simple and 

optional registration system should be implemented to store user progress. These features 

ensure that concepts are learned comprehensively and in a logical order.  

3.3.3 Community 

Taking inspiration from the Scratch Foundation’s web platform, BlockLeap 

proposes creating a tool to allow users to create their own levels from scratch or take a 

published level as a base and work over it. Levels can then be published to the 

community for others to play, edit, and learn from. 

Publishing a level should only occur when it has been validated that the level is 

completable in order to prevent users from publishing incomplete or impossible levels 

that might frustrate other users. 

The features of a level creator and a community can further gamify the learning 

experience as users create their own levels and have access to an unlimited number of 

levels to experiment and play with. 

3.3.4 Educator Toolset 

A set of tools or functions should be provided for educators to better collect, 

organize, and analyze the use of BlockLeap in an educational environment.  BlockLeap 

would benefit from an educator user role that provides access to features such as bulk 

student account creation, access to student account progress data, etc. This can 

include an extension of the community aspect, allowing for the sharing of puzzles 

created by educators to students rather than publishing them to the community. 



 

 

45 

3.3.5 Offline Functionality 

Traditionally, one downside to a web platform in comparison to a native desktop 

application such as Articoding is the requirement for internet connectivity. However, the 

current state of the art in web development allows us to implement an offline mode for 

BlockLeap, thus reducing the impact of transitioning to a web-based tool. When the user 

loses their internet connection, they should still be able to play some levels (e.g. the last 

visited). With this in mind, when internet connectivity is lost or unavailable, BlockLeap 

should notify users and present a limited functionality version of BlockLeap and allow the 

user to regain the full functionality when connectivity is restored.  

3.3.6 Accessibility 

In order to reach a broader audience and have a larger impact in programming 

education, BlockLeap should be multi-platform or platform agnostic. With this in mind, 

BlockLeap is designed as a web application, as by being accessible from any device 

with a web browser and an internet connection, BlockLeap would be accessible to 

almost all schools in Spain do [9]. 

3.3.7 Low System Requirements 

As BlockLeap’s primary audience are educational institutions that generally lack 

or have a limited supply of computers, BlockLeap should require few technological 

resources to be used by the students in the school classroom. By being available to 

educational institutions without the technological resources to deploy a native desktop 

app, BlockLeap can reach a larger number of students and have a larger impact in 

programming education. This can be achieved by reducing the server response time, 

optimizing code, and using asynchronous loading where possible to prevent thread 

blocking.  

3.4 Design 

This section details BlockLeap’s design phase conducted to meet the established 

requirements. This phase comprises the design of the Serious Game and its mechanics, 



 

 

46 

the web application design (functionality and user interface), and the server-side 

functionality. Initial designs were established for reference, while maintaining the 

project’s agile methodology anticipated the need to iterate and leading to multiple 

design changes during development. 

3.4.1 Serious Game Design 

BlockLeap centers on learning basic programming principles through puzzle-

solving mechanics and block-based programming. The game is comprised of three main 

sections: ‘Play’, ‘Create’, and ‘Community’.  

The ‘Play’ section is BlockLeap’s Serious Game, where users solve puzzles to learn 

programming. It is divided vertically into 2 zones, a programming zone on the left and a 

game world zone on the right as seen in Figure 3-1 initial game interface. 

 

Figure 3-1 initial game interface. 

The programming zone consists of two main elements, a categorized toolbox of 

programming blocks and a workspace to place blocks on to code. Blocks should be 

dragged into the workspace where the blocks would then have to be connected to one 

another, symbolizing the flow of the game as a set of instructions to be executed one 

after another. Above the programming zone, a play and stop button allow the execution 



 

 

47 

or cancellation of the code created in the workspace. Code executed will be the 

method of interaction with the game zone. 

The game zone is a visual representation of the puzzle to be solved and contains 

multiple entities that can be controlled or interacted with the code blocks. To facilitate 

development, part of the asset pack “Dungeon Tileset II” shown in Appendix A - Game 

Design was used. The pack has the CC0 license and is allowed for free use and 

modifications, the specific sprites used are detailed in appendix A - Game Design. The 

list of game world entities designed were: 

• Player: The main character, whose actions (e.g. movement) the user can control. 

• Objective: The goal for the player to reach. It symbolizes the winning condition of 

each level. The objective is often called “exit” since the intention is to exit the 

current level and enter the next one. 

• Wall: A collision object. Player entities cannot enter this object and are returned 

to their original position when colliding with it. It can be used as decoration or to 

limit movement. 

• Trap: A basic obstacle, meant to be an instant loss for a player if enabled and 

touched. The intention is to force players to either circumvent or disabled this 

entity. 

• Enemy: An advanced obstacle that causes an instant loss when touched, similar 

to the trap. Enemy entities move in a horizontal or vertical pattern whenever a 

player entity moves. 

• Bonus: A collectable item. This entity can incentivize creative thinking and 

additional complexity. Collecting it should provide a reward. 

The second section BlockLeap’s Serious Game is the 'Editor’ tool, to allow users to 

create their own puzzles, test them, and save them privately or publish them to the 

community for others to play. The initial design is shown in Figure 3-2. 



 

 

48 

 

Figure 3-2 Initial design for the ‘Create’ puzzle zone. 

 The final design was based on existing editing tools such as Photoshop, with a 

toolset on the left-hand side and a central workspace and can be explored in Figure 3-3. 

The toolset consists of 3 tools, “Add”, “Remove”, and “Move Camera”. These tools allow 

users to create their levels easily and quickly without complication. The add/remove 

buttons near the grid allow users to quickly expand or reduce the number of tiles in the 

level grid, on which they can place entities selected from the “Add” tool. Once a design 

was completed, the save button will load the puzzle into the “Player” zone to validate 

and verify the puzzle is completable. After validating it, the user can save or publish the 

puzzle. 



 

 

49 

 

Figure 3-3 Final design for the ‘Create’ puzzle zone. 

 The third section of BlockLeap is the ‘Community’, meant to represent levels that 

aren’t official but are playable, since they were created by other users. This way, the 

project had more depth, since it not only encourages users to think logically but also think 

in reverse, thinking of levels that can be solved with the provided blocks, and allow others 

to solve their creations. All of this was encased in the community section, which was 

deemed the lowest in priority. 

3.4.2 Web application Design 

This section details BlockLeap’s initial web design established based on the design 

of the project’s Serious Game. Given the project’s aim to be used in an educational 

environment, typically high school aged students, a simple and intuitive design was vital. 

Educational use could also entail the use of tablets rather than computers, and thus a 

simple design would allow for a more responsive platform. A simple navigation bar, with 

the principal features of BlockLeap’s Serious Game would allow for easy navigation and 

a clear differentiation between navigation and content. A sketch of the design can be 

found below in Figure 3-4. 



 

 

50 

 

Figure 3-4 Initial home page design. 

The home page, the first page viewed by a user, implements BlockLeap’s ‘Play’ 

functionality. A simple, hierarchical group of categories are shown, where a user can 

select the programming topic they want to learn about. An almost identical structure is 

shown when selecting a category to show the available puzzles. As an initial prototype 

design, the specific information of a category or puzzle was not considered until later in 

the project. 

Once a level was selected, the ‘Play’ section described in the section ‘Serious 

Game Design’ above would be shown. A diagram of the designed interface can be 

seen in Figure 3-5 below. 



 

 

51 

 

Figure 3-5 Final home page design. 

The create option would similarly directly show the ‘Create’ section described 

above and the ‘Community’ section would show a list of public community levels with a 

similar structure to that of categories and official levels. 

3.4.3 Database Creation 

With the proposed features, game design, and webpage design in consideration, 

an initial database model was designed and presented to the project’s directors. The 

database was designed with the assumption that all features proposed would be 

implemented, regardless of whether the project was completed within its duration or not 

to provide a working starting point to any future development. Figure 3-6 below illustrates 

the initial schema for the project. 



 

 

52 

 

Figure 3-6 Final database design. 

 After some iteration, a simplified database schema was designed, as shown in 

Figure 3-7. The simplified version took into account the feedback received by the mentors 

in the following weekly meeting, and consequently some overlap between objects were 

removed as well as unnecessary relations between certain entities. 



 

 

53 

 

Figure 3-7 Logical design of database schema. 

3.5 Added Value 

While existing solutions provide comprehensive tools for learning programming or 

are popular educational platforms, BlockLeap combines these concepts into a tool for 

educational institutions with reduced technological resources, be it computers or tablets. 

Additionally, BlockLeap provides a comprehensive toolset for educators to track learning 

progress, customize their curriculum, and manage their students. 

Another benefit of BlockLeap, shared by Articoding, is the possibility for offline use. 

Only requiring an internet connection for the initial loading of BlockLeap’s platform, the 

rest of the application, excluding the Community, would be run on the client regardless 

of internet connectivity.  

BlockLeap’s ‘Community’ improves Articoding’s creation of puzzles, allowing 

students to experiment with creating and then share them with the community, or 

combined with the educator toolset to create puzzles to practice or test a specific 

programming concept. 



 

 

54 

Finally, as an open-source project, BlockLeap provides an easy framework for 

expansion and future work. While not included in the scope of this project, features such 

as internationalization, puzzles-as-quizzes, or other features can be implemented by 

anyone. Iterative work can improve BlockLeap’s platform and allow more users to learn 

programming, be it in school or individually, and this project encourages any and all 

contributions. 

  



 

 

55 

Chapter 4 - Development 

This chapter offers a comprehensive overview of the architecture developed for 

BlockLeap’s platform, covering foundational elements, key components, and their 

interactions in detail. A general overview of the project architecture is presented before 

detailing the specific Client-side and Server-side architectures, as well as any challenges 

encountered during development. 

4.1 Architecture 

The project comprises two main components: the server and the client, where the 

server consists of the web server and a RESTful API, and the client is any computer, tablet, 

or other device that connects to the web server. To streamline development, server and 

client components were developed separately and then merged after integration 

testing. 

 

Figure 4-1 Simplified architecture diagram. 

 The web server runs a Node.js environment and servers the application using 

Express.js. To satisfy BlockLeap’s requirement to use minimal system resources, server-side 

logic was reduced, and the web application was developed as a Single Page 

Application (SPA). This entails serving a single endpoint with Express.js, always returning 

the same HTML file regardless of the path and then performing routing on the client. The 



 

 

56 

server also hosts the RESTful API, managing more complex requests by clients, such as 

database access (e.g. requesting puzzles, user registration, etc.).   

 Although as an SPA, BlockLeap reduces the server load, the client-side structure 

gains complexity. The client controls interface routing, the Serious Game logic through 

controllers, and additional functionality such as a Service Worker for offline functionality 

and data collection. The above diagram presents a simplified view of the final 

architecture developed. 

4.2 Server 

In the following section, a detailed description of specific server-side 

implementations and core functionality is presented. The development of server-side 

components was done on the BlockLeap-Backend repository13 using the RESTful API. 

4.2.1 Webserver 

As an SPA, the Express.js server was a single endpoint that always returned the 

same page, as well as implementing the RESTful API described below. 

The webserver made use of a powerful Node.js package HelmetJS that enables 

the security of the HTTP headers returned by the Express.js application. HelmetJS uses a 

bunch of different middleware functions in order to enhance the security of the 

application by preventing code injection, click-jacking, or Cross-Sit Scripting. 

It also uses PinoJS, a logging framework for Node.js that boasts exceptional speed 

and provides features. The team opted to use this framework instead using the JavaScript 

console logging because the last one can slow down the execution of JavaScript code 

slowing down the overall performance of the entire application, something that is totally 

contrary to what this project aims to with this web application. 

 

13 https://github.com/BlockLeap/BlockLeap-Backend/ 

https://github.com/BlockLeap/BlockLeap-Backend/


 

 

57 

4.2.2 RESTful API 

An API14 is a set of definitions and protocols that allow two software components 

to communicate with each other. An API defines how software components interact, the 

call or request that can be made, how to make those requests, the data formats to be 

used and the conventions.  

More specifically, a RESTful API is an API that uses the principles of the REST15 

architecture. This type of API uses standard HTTP method, such as GET, POST, PUT or 

DELETE, to perform operations on resources accessed via URLs. For a client-server website, 

a RESTful API is used because it is an implementation of an API that strictly follows the 

principles and constraints of the REST architecture.  

OpenAPI16 was used because it is a specification for a RESTful API that allows to 

describe how it works and how it is built in a standardized way. OpenAPI facilitates the 

documentation, design and maintenance of APIs using human and machine-readable 

formats such as JSON or YAML. The Swagger17 editor was used to display an OpenAPI 

YAML file, as shown in Figure 4-2. Within the OpenAPI standard the endpoints to be 

implemented have been defined. It defines in detail the type HTPP verb it uses, the 

parameters it uses, whether it uses the HTTP body or cookies, and the type of responses it 

sends. The OpenAPI file for BlockLeap can be found in the backend GitHub repository18. 

As mentioned in Figure 4-1, an architecture using a router, middlewares and 

application logic has been followed. For the application logic, controllers have been 

used which are called from the routers. These controllers are responsible for calling the 

database and preparing the response. Several middlewares are used for the correct 

 

14 Application Programming Interface 

15 Representational State Transfer 

16 OpenAPI Initiative 

17 API Editor 

18 https://github.com/BlockLeap/BlockLeap-Backend/blob/dev/openapi.yml 

https://www.openapis.org/
https://swagger.io/tools/swagger-editor/
https://github.com/BlockLeap/BlockLeap-Backend/blob/dev/openapi.yml


 

 

58 

functioning of the server, such as the error management middleware. This catches any 

exception thrown by the application or database. Depending on the type of exception 

caught, an error code is generated with a status appropriate to the type of error along 

with a message describing the error that will be sent to the client. 

 

Figure 4-2 Display of the BlockLeap OpenAPI file. 

4.2.3 Authorization and cookies 

An authorization system was implemented using JWT19. JWT is an open standard 

for creating access tokens that enable the secure transfer of information between entities 

such as a client and a server. JWT is ideal for authentication and authorization in web 

applications because it can be digitally signed, ensuring data integrity and authenticity. 

The token is created when a login request is received and deleted when a logout request 

is received.  

To send the token to the client, the original idea was to send it in the response 

body and the client store it in local storage. However, this had a security problem which 

 

19 JSON Web Tokens 

https://jwt.io/


 

 

59 

is that this private information could be extracted from the token via an XSS20 attack. For 

this reason, it was decided to use first-party cookies. This is because they can be set by 

setting the httpOnly parameter to true, which prevents them from being accessed by 

client-side JavaScript code. These cookies are automatically sent by the browser to the 

corresponding server with each HTTP request. Although the use of cookies with JWT is not 

widely recommended due to the limited storage of cookies, it was decided to use it as 

the JWT payload created on the server is not large. 

According to this explanation, the server creates 2 cookies after a successful login 

request. The first cookie with key ‘jwt’ has httpOnly set to true and contains the private 

key for authentication. The second cookie with key ‘session’ has httpOnly set to false and 

contains the user id, name, and role. Both will expire in 2 hours. The client will only be able 

to read information from the ‘session’ cookie, while the server will use the ‘jwt’ cookie to 

know If the user is authenticated or authorized. Figure 4-3 shows the use of the 2 cookies 

in more detail. 

 

Figure 4-3 Cookies used in BlockLeap. 

 

20 Cross-Site Scripting 



 

 

60 

4.2.4 Sequelize 

For its facilities encouraging a model-driven approach to database interactions 

the team decided to use Sequelize. 

Sequelize is an Object-Relational Mapping (ORM) library for Node.js that abstracts 

away the complexity of writing raw SQL queries, supports multiple SQL databases such as 

PostgreSQL, MySQL, SQLite, and MSSQL and provides mechanisms for data validation 

and sanitization between other advantages. It also supports the definition of relationships 

between database tables, such as one-to-one, one-to-many, and many-to-many 

associations to simplify querying related data and ensuring data integrity at database 

level. Finally, Sequelize encourages a model-driven approach to database interactions, 

a valuable thing due to the relations database the team decided to present their entities 

with. 

As the team discussed their database interactions way before the creation of the 

webserver-side of the application, this ORM library was perfect because it has a build 

tool called Sequelize-auto which can create the entire Sequelize model to operate with, 

just by introducing some database information into a command. 

This creates a folder system with a file for each entity and an initialize file that can 

be called from Sequelize to get all database relations information. The folder shown in 

Figure 4-4 with its files was created with that command. 

 

Figure 4-4 Sequelize model folder system. 



 

 

61 

With all this being settled and in order to make use of this powerful library, the only 

thing left was to create an instance of Sequelize providing some information of the 

database, such as the schema, the user, the password, the host, the dialect, and the 

database port. 

4.2.5 Testing Suite 

To evaluate the correctness of the endpoints and to make an application test, the 

team opted to use Jest21, an open-source testing framework built on JavaScript together 

with Supertest, a Node.js library that allows developers to test the API because its utility to 

test the entire RESTful API at a time. 

With these two tools, the team just had to create a file with their tests proving the 

correctness of each database component by testing all created endpoints. 

Then, with just a command, all tests are run, and it appears the result of the tests 

with all the information of the used files to get the information or to push it into one 

database entity as shown in the Figure 4-5, then, a useful view of the files, contrasted by 

size, appears in console, and can be seen in Figure 4-6. 

 

21 https://jestjs.io 



 

 

62 

 

Figure 4-5 Test result. 

 

 

Figure 4-6 Files percentage of usage. 



 

 

63 

All this information helped the team to check and see whether the endpoints were 

sending or receiving the right information and also find out if the queries were correctly 

written to get an estimated requests behavior in the application. 

4.3 Client 

In the following section, a detailed description of specific client-side 

implementations and core functionality is presented. The client-side was developed on 

the BlockLeap-Client repository22 using TypeScript and makes use of Rollup23 to bundle 

the BlockLeap application. In order to create the Serious Game, BlockLeap makes use of 

Google’s Blockly library24 and the Phaser framework25. Blockly is used to implement a 

custom block-based programming language and Phaser was used to implement the 

visual aspect of the puzzle and game logic. 

 

22 BlockLeap-Client (github.com) 

23 Rollup 

24 Blockly  |  Google for Developers 

25 Phaser 

https://github.com/BlockLeap/BlockLeap-Client
https://rollupjs.org/
https://developers.google.com/blockly?hl=es-419
https://phaser.io/


 

 

64 

4.3.1 Platform Interface 

 

Figure 4-7 Initial home page design. 

The visual aspect of the platform underwent multiple iterations, from initial 

designs, for example Figure 4-7, to the final design. The interface developed aimed to 

be simple in order to be intuitive to use, for example by having a simple navigation bar 

(Figure 4-8) at the top of every page with the platform’s main features, and internal 

testing led to several changes to improve usability. 

 

Figure 4-8 Final navigation bar design. 

 As an example of a usability improvement, the final home page design changed 

the layout of categories to have a hierarchical order to categories, rather than a hard to 

follow left-to-right and top-to-bottom order, as in Figure 4-9. A counter to show the 

number of levels in a category and a short description were also added to provide easier 

understanding of the category’s contents.  



 

 

65 

 

Figure 4-9 Final home page developed. 

An alternative interface was developed to further improve the hierarchical order 

of categories, allowing the locking of categories, and forcing the completion of all a 

category’s levels before being able to proceed to the next category. This interface is 

shown in Figure 4-10, although it is not included in the production version deployed. 

 

Figure 4-10 Alternative design for home page with locked categories. 

The category’s level interface was also updated to the hierarchical structure used 

in the home page, and additional data such as a level description, the number of stars 

collected, and the number of attempts were displayed, which can be appreciated in 

Figure 4-11 below. 



 

 

66 

 

Figure 4-11 A category page, showing the levels in it. 

Additional changes were made to the interface designed and will be detailed in 

the following relevant sections. 

4.3.2 SPA Router 

As an SPA, BlockLeap would require client-side routing in order to load a resource 

directly, rather than always loading the home page and forcing the user to navigate to 

their required destination. This was implemented through a routing system, where 

depending on the URL navigated to, the router would make server requests if needed 

and load the resource. The specific resource requested would then update the web 

interface and load any other required items. 

4.3.3 Game Controller 

To reduce coupling and increase cohesion, BlockLeap’s Serious Game logic was 

contained in a Game Controller, this was further divided into a Phaser Controller, to 

manage the game zone of the ‘Play’ section and the whole ‘Edit’ section, and the 

Blockly Controller to control the programming zone of the ‘Play’ section. 

4.3.3.1 Phaser Controller 



 

 

67 

The Phaser Controller controlled the instance of the Phaser game and contained 

two scenes, a ‘Play’ scene and a ‘Create’ scene. Each scene implements the logic 

required and had no interaction between them, while making use of the same 

framework and shared assets. A basic example of a loaded scene can be found in Figure 

4-12 below. 

 

Figure 4-12 Example of Phaser’s 'Play' scene with the additional 'Clone' and 'Speed Modifier' features. 

The ‘Play’ scene consisted of creating the visual representation of a puzzle and 

instantiating the different entities. While the scene handles the game logic, such as the 

loading of assets, the scaling of assets, and checking for the win-condition, each entity 

individually handles its logic, such as reacting to collisions. The scene was not directly 

interactable with, as puzzles must be solved through the Blockly block-code 

programming, further explained below. On top of the ‘Play’ scene, buttons were added 

to implement the features ‘Clone’ (blue) and ‘Speed Modifier’ (yellow). Cloning allows 

users to take the current level, be it an official level or a level from the community, and 

import it into the ‘Creator’, to edit and expand on the puzzle. The ‘Speed Modifier’ setting 

allowed users to get through larger levels and iterate through their code more quickly, 

rather than having to wait for animation to complete, as well as maintaining a slower 

speed for more precise decisions more quickly. 



 

 

68 

 

Figure 4-13 Initial 'Create' scene design. 

The interactive ‘Create’ scene handled the creation of puzzles with a resizable 

board where entities could be placed by users, and the initial design can be found in 

Figure 4-13 above. Each tile of the board handled logic to ensure entities could not be 

placed on empty tiles and the board handled the conversion of the visual representation 

to a savable JSON format. Out of all pages in BlockLeap, the puzzle creator underwent 

the largest number of redesigns. The initial design had several usability problems, such as 

an unintuitive resize system or a lack of background customization and fixed entity limit.  

An iterated design attempted to solve the background customization and entity 

limit by creating an asset toolbox with tabs for background assets and entities. This was 

developed with the Phaser plugin RexUI. The team had contact throughout the 

communication software Discord with the developer of the plugin, to concrete ideas for 

a possible interface, a brief reference to this back and forth can be found in Figure 4-14 

below. 



 

 

69 

 

Figure 4-14 Interaction with RexUI’s developer. 

 It is also worth noting that this design worked well with the plugin but required a bit 

of complex thinking behind it, since the way the plugin worked was by creating 

components that relied on Phaser to overwrite certain classes. This was part of the reason 

the mentors later suggested switching to a design that used plain HTML instead.  



 

 

70 

 

Figure 4-15 Testing with RexUI toolbox that was discarded. 

 After further iterations, the aspect of a drag-and-drop UI, as in Figure 4-15,  was 

completely discarded in favor of a tool selection and click-and-hold as shown in. This was 

done to improve the experience of creating larger levels. The new design proposed 

would allow users to “paint” the level rather than having to individually select each asset 

and position. By having a toolset similar to those in editing software such as Photoshop, 

the interface can be more familiar to users, and can be appreciated in Figure 4-16 below. 

 The change from a resizing modal to buttons on top and on the left of the board 

was also implemented to provide users a more intuitive and responsive method to resize 



 

 

71 

the board. Rather than having to open a modal, select a width and height, and then 

accepting it, users can instantly add or remove rows and columns. 

 

Figure 4-16 Final 'Create' scene design. 

4.3.3.2 Blockly Controller 

The Blockly Controller is instantiated in conjunction with the ‘Play’ scene of the 

Phaser Controller, to create the programming zone. Blockly consists of a toolbox of blocks 

and a workspace on which blocks can be placed and connected to form the program. 

The Blockly library handles both the visual representation of code blocks and the code 

generation of blocks in the workspace. An example of Blockly’s implementation in a 

given level of the project can be seen in Figure 4-17 below. 



 

 

72 

 

Figure 4-17 Blockly toolbox limited to Actions and Variables categories. 

This project developed custom blocks, both visually and the code generation, with 

the Blockly library. While visually similar to the default blocks of Blockly, BlockLeap’s code 

generator implemented a custom event system further described below. 

The workspace was the area where users could connect blocks to generate code 

to execute. Workspaces are always instantiated with a custom “Start” block to denote 

the start of the code. Any block not connected to the “Start” block was ignored, except 

for function blocks which were processed separately. An example of the layout with 

buttons can be found in Figure 4-18. Blockly’s default workspace has zooming tools and 

a garbage bin to delete blocks in the lower right corner, but to improve usability the 

official Zoom-to-Fit26 plugin was used to resize the workspace viewport if needed. 

 

26 https://www.npmjs.com/package/@blockly/zoom-to-fit (last accessed: 2024-05-15)  

https://www.npmjs.com/package/@blockly/zoom-to-fit


 

 

73 

 

Figure 4-18 Blockly workspace with 'Run' and 'Stop' buttons. 

4.3.3.3 Event System 

The event system is roughly based on the JavaScript Event and CustomEvent 

capabilities, making communication between different parts of the application possible, 

specifically between the Blockly logic and the Phaser game engine. These events are 

dispatched as instances of a custom event, which carry data that will then be used by 

the event listeners. 

The event listeners are configured to respond to specific events. For the project, 

most blocks generate an event that is dispatched by the Blockly controller and captured 

later to execute the changes within Phaser itself. Other practical things done for event 

handling were delaying event execution or stopping its propagation once captured by 

a listener.  

Each event had an event name and a detail property. The name was used to 

identify the type and which listener would then have to capture it, and the detail would 

capture all relevant data (for example, in a block, the event name would be the name 



 

 

74 

of the block, and the detail, any information, like children blocks or instructions, as well as 

values) 

Overall, the event system was a substantial upgrade upon the previous system, 

but had a major drawback, being that events are launched and evaluated when code 

is executed in each level, but there are instances where this should not be the case (for 

example, evaluating a condition before the player has reached the point where the 

condition is to be evaluated will mean a certain failure) this was a necessary evil, due to 

the benefits of using events, which facilitated communication between Phaser and 

Blockly. 

4.3.4 Service Worker 

As previously mentioned in Chapter 3 - Proposed Solution, the project was 

intended to have an offline mode where the player could continue with their learning 

without having an internet connection. 

In addition to this, a fluent web application was one of the team's main goals, as 

well as making sure that the application performance stayed fresh, and the user 

experience maintenance rely consistent. 

With all these requirements in mind, it was decided to include a Service Worker, a 

JavaScript file executed in the players browser (in the background) that monitors and 

intercepts all server requests. This script can help the application to run faster and 

smoother because it can store resources in cache that can be read when needed, 

without having to make any further requests. This is because the Service Worker has 

access to a browser independent store. Service Workers allow the storage of HTML, CSS 

or JavaScript files, images, and other necessary resources for the application. 



 

 

75 

 

Figure 4-19 Interface showing cached levels when lacking internet connectivity. 

One of the most powerful capabilities of the Service Worker is that it can make the 

web application run without having Internet connectivity. This is due to its cache storage 

which makes it possible to get the resources needed without having to request the server 

for that information. When the player loses connection, the learning doesn’t stop 

because the programmed Service Worker has an amount of maximum ten levels stored, 

the last levels that the player entered, for the user to keep exploring and keep solving 

those levels.  

When the Service Worker notices a version update, it will notify the user that the 

application has an update. This applies transparency to the application, giving the user 

the sense of a new application version that can be used by the developers to solve 

problems, implement new characteristics, or simply update content, while having the 

application running. The notification appears on top of the screen to make sure the user 

knows that the web application has a new version available as seen in Figure 4-20 below. 

 

Figure 4-20 Message shown when new Service Worker version is detected. 



 

 

76 

All this allows the application to make a greater and faster user experience, be 

more reliable, and add a bunch of functionalities to the page. 

4.3.5 xAPI 

To evaluate the users' skills in the use and play of BlockLeap, xAPI27 was built 

together with an LRS28. An LRS is an information storage system that stores data related 

to learning processes in an organized format. It provides a secure, centralized system for 

storing information about learning activities such as online courses or webs, interactions 

with learning material and participation in simulations. 

The LRS is designed to be compatible with xAPI, a standard that enables learning 

applications to collect and monitor information about users’ learning experiences in a 

consistent and compatible manner. The LRS acts as a central repository for the data 

collected by xAPI, enabling detailed analysis and monitoring of the evolution of learning 

over time. This transmitted data is referred to as traces. 

Watershed29 was used as an LRS because of its comprehensive approach to 

managing and evaluating learning data. It offers an intuitive interface, effective 

visualization tools and the ability to integrate with other educational technologies, 

making it an attractive option for implementing an LRS efficiently and easily. 

This integration of an analysis system makes it possible to debug and improve the 

game mechanics and interface according to the interactions and difficulties of the 

players, as well as to evaluate the difficulty of the video game thanks to the solutions and 

number of attempts of a level submitted by the players. It is also used to know the level 

of knowledge of the players. 

 

27 Experience API 

28 Learning Record Store 

29 https://www.watershedlrs.com  

https://www.watershedlrs.com/


 

 

77 

This collected data can be used to check if expected behaviors are being met 

and to help developers make better decisions. For example, the number of times they 

use the stop button, the number of attempts they make to complete a level, the speed 

at which they play, whether they use the bounce wall mechanic, the solution they have 

used etc... 

In any case, these traces should make it possible to identify what happened 

during the game, or at least the most important situations and decisions, without having 

to observe the player directly or record all his actions. 

4.3.5.1 xAPI Traces 

In the context of xAPI, interaction data, usually know as traces, are expressed in 

statements consisting of a subject, a verb, and a predicate. This information (Serrano-

Laguna et al., 2017) includes an actor performing the action, a verb describing the action 

performed, the object on which the action is performed, and extensions that provide 

additional information about the action (e.g. the context in which the action occurs). 

To properly define an xAPI trace, the xAPI-Spec30 guide and specification has 

been followed, where all the information to define the data structures and elements 

necessary to create xAPI traces can be found. This guide provides comprehensive details 

of the mandatory and optional fields that must be included in an xAPI trace. By following 

this guide, developers can ensure that the xAPI traces they generate are consistent, 

interoperable, and compliant with established standards. 

 

30 https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#241-id 

https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#241-id


 

 

78 

 

Figure 4-21 Example of traces collected in BlockLeap in xAPI format. 

The trace shown in Figure 4-21 is an example trace generated after completing a 

level, presenting the following information. As for the mandatory fields, there is the trace 

id (id) in uuid31 format, the actor who is identified by the name “pepito” (actor.name), 

the action performed which is the completed action (verb.id) and the object on which 

 

31 Universal Unique Identifier 



 

 

79 

the action was performed is a level (object.definition) which is level 10 (object.id). In result 

we have information about the score obtained (result.score), if the level has been passed 

(result.success) and other aspects to be evaluated (result.extensions). In score we have 

the score obtained (score.raw), between a minimum of 0 (score.min) and a maximum of 

3 (score.max), where the score is scaled from 1 unit (score.scaled), with the possibility of 

obtaining a score of 0, 1, 2 or 3. The most important extensions of the result are the solution 

sent by the player, the number of attempts to win, the number of blocks used or if the 

bounce mechanic was used. In context are the version of the game and the session 

which is a uuid that is generated after entering the web page and is deleted when 

logging out or close the web page. This is useful to know the users’ progress during that 

time. Finally, there is the timestamp, which is the time at which the trace was created. 

 

Figure 4-22 Example of traces collected in BlockLeap in xAPI format. 



 

 

80 

The trace shown in Figure 4-22 is generated after accessing the introduction 

category with id 1. The same format as above is used, where the actor is “pepito” 

(actor.name), the action performed is accessed (verb.id) and the object on which the 

action was performed is a screen (object.definition) whose object id is the accessed URL. 

Another field is the authority field, which gives information about who has confirmed that 

the trace is correct, it can be seen that Watershed has been used. 

The verbs and objects used to capture the BlockLeap interaction and create the 

xAPI traces, the following have been used: 

• Completed: this trace is used to indicate that a game element has been 

completed 

o Level: a level of the game 

• Failed: this trace is used to indicate that a game element has not been completed 

o Level: a level of the game 

• Accessed:  this trace is used to access some areas of the website 

o Screen: website screen 

• Interacted: this trace is used when you interact with a navigation icon on the 

website or with a block in the game 

o Screen: website screen 

o Math number: block of number 

o Movement: block of movement 

o Change status: block of change status 

o Variables Set: block of variable 

• Logged in, Logged out: This trace is used to indicate when the user logs in or logs 

out 

o Profile: Site on the website where the above-mentioned actions are 

performed 



 

 

81 

Below is a detailed table of all traces used in BlockLeap: 

Information 
collected 

xAPI verb used Object xAPI 
used 

Extensions (optional) 

Complete a game 
level 

Completed Level Success 
Score 
Blocks used 
Game Velocity 
Attempts until win 
Bounced 
User levels completed 
Total official levels 
Nº of clicks stop button 
Solution Code 

Fail a game level Failed Level Succes 
Blocks used 
Game Velocity 
Number attempt 
Bounced 
User levels completed 
Total official levels 
Nº of clicks stop button 
Solution Code 

Access to a 
category 

Accessed  Screen  

Access to a level Accessed Screen  
Access to the level 
editor 

Accessed Screen  

Access to 
community page 

Accessed Screen  

Access to the 
profile 

Accessed Screen  

Interacted with the 
play icon 

Interacted Screen  

Interacted with the 
profile icon 

Interacted Screen  

Interacted with the 
community icon 

Interacted Screen  

Interacted with the 
editor icon 

Interacted Screen  

Change of state of 
a block 

Interacted Math number, 
movement, 
change status, 
variables set 

Level id 
Name (type of change) 
Old value 
New value 



 

 

82 

Delete a block or 

blocks 

Interacted Math number, 

movement, 

change status, 

variables set 

Level id 

Deleted Blocks 

Move a block Interacted Math number, 

movement, 

change status, 

variables set 

Level id 

Move actions 

Log into the website  Logged in Profile  

Log out from the 

website 

Logged out Profile  

Table 4-1 Table of xAPI traces used in BlockLeap. 

To send the traces to the LRS, xAPI.js32 was used. This is an open-source library 

developed in JavaScript to simplify the integration and use of the xAPI standard in web 

applications. This library provides several functions and methods that allow developers to 

interact with an xAPI compatible with an LRS efficiently and effectively. By using xAPI.js, 

developers can send learning experience data, such as user interaction events, to an 

LRS in a structured and xAPI compliant manner, making it easy to track and analyze 

learning progress.  

In order to start using xAPI.js, a basic authentication must be set up to connect to 

the LRS, using the username and password that the LRS create when the endpoint was 

created. This is the place where the traces will be stored. 

const auth = XAPI.toBasicAuth(username, password); 
const xapi: XAPI = new XAPI({ 

endpoint: endpoint, 
 auth: auth  

}); 

 

32 https://www.xapijs.dev  

https://www.xapijs.dev/


 

 

83 

Then, the trace is created and sent to the LRS using the sendStatement function 

of the previously created xAPI instance. 

const myStatement: Statement = { ... }; 
xapi.sendStatement({ 

statement: myStatement 
}); 
 

4.3.5.2 XAPI User evaluation 

With the traces collected using xAPI, it is possible to evaluate various aspects of 

the player when using BlockLeap. Some of the most important interactions to understand 

the player are: The number of levels a player completes or fails to complete during a 

session, i.e. from the time they enter the web site until they log out or close the web site. 

In addition, from the result information these traces contained, can be used to determine 

the average number of blocks used in a level, if bounce mechanics are used, how many 

times the stop button is pressed, or the average number of attempts;  the least visited 

pages on the web site, which should make you think about why they are not visited and 

encourage to implement or rethink new designs for these pages; if the plater interacts 

with the navigation icons by capturing this trace, but the accessed traces does not 

capture it, a possible web page malfunction would be detected. Finally, the actions 

performed on the blocks allow to know if the Blockly trash is used or the number of 

movements or changes of state of the blocks that a user makes in a level. 

4.3.6 Web tour  

As feedback from the validation phase detailed in Chapter 5 - Validation, users 

requested more detailed explanations or guides on how certain more advanced blocks 

worked in BlockLeap. Thus, an additional “Web tour” feature was planned and partially 

implemented. 



 

 

84 

 

Figure 4-23 Web tour shown the first time a puzzle is played. 

Multiple application tour libraries were analyzed, including WebTour JS, Bootstrap 

Tour, and Shepherd. Ultimately, TourGuide JS was selected for its simplicity and a guided 

tour was implemented for the level player. After completing a tour, TourGuide JS will 

automatically store the state in the browser’s LocalStorage and would not show the tour 

during the next load. To allow users to repeat a tour, an additional ‘Help’ button was 

added to the ‘Play’ section of BlockLeap, as in Figure 4-23 and Figure 4-24. 

 

Figure 4-24 Actions available in 'Play' section, including 'Help'. 

  



 

 

85 

Chapter 5 - Validation 

As part of the project, and having completed a stable beta version of BlockLeap, 

a validation session was organized on April 9th, 2024. The validation session was 

conducted in collaboration with a high school at the Faculty of Computer Science at 

the Complutense University of Madrid. This validation session aimed to gather feedback 

from BlockLeap’s target audience, as well as test the application in real time, and find 

possible improvements. 

Three of the four authors of this project were able to attend the session to observe 

the use of BlockLeap and solve any doubts users had. A single member of this project 

was unable to attend the session due to personal reasons. 

 

Figure 5-1 Project members during the validation session. 

 



 

 

86 

5.1 Session Details 

The session was planned to have a maximum duration of 2 hours and consisted of 

an initial anonymized survey on participants’ age, gender, basic questions on previous 

knowledge of programming, and future career interests (if any). After the survey, 

participants were allowed to immediately start using BlockLeap with no previous 

guidance in order to assess the intuitiveness and clarity of the interface. The session 

finished with verbal feedback from participants and a closing survey similar to the initial 

one to assess changes after the use of BlockLeap. 

During the use of BlockLeap by participants, they were asked to register and sign 

in with a BlockLeap account in order to track participants’ progress and gather metrics, 

however not all participants did this. The authors of this project were available during the 

session to resolve doubts, receive instant feedback, and identify bugs, many of which 

were reported by participants. 

 

Figure 5-2 Students testing BlockLeap. 



 

 

87 

5.2 Feedback & Errors 

The session was extremely useful in detecting bugs, and features missing simply by 

observing how participants used the platform. For example, puzzles being impossible to 

complete or the navigation bar missing an indicator of the status of the page. Additional 

bugs were reported by multiple users, such as a level being impossible to complete due 

to an enemy that always collided with the player regardless of either entity’s position. 

After participants completed the available puzzles and experimented with the 

puzzle creator, they provided useful improvement suggestions and feature requests. This 

included creating separate enemies for horizontal and vertical movement rather than a 

single enemy that could move in either direction, and a guided tour to introduce new 

blocks, as some blocks were not intuitive to use and where therefore disregarded in 

attempts to solve the puzzles. 

To address these issues and enhancements, additional tasks were added to the 

project’s planning, divided into three categories: bugs, improvements, and levels. Each 

task was assigned a developer and priority, and a majority were implemented within the 

following development sprint. Any unresolved tasks are left ‘future work’ are 

documented in detail in Chapter 7 - Conclusions and Future Work. 

5.3 Data Analysis 

From the initial survey and post-session survey filled in by participants, a simple 

analysis was performed.   

The following graphics are analyses of the post-survey data, mainly from the 

numerical responses to the questions about the gaming experience. The x-axis 

corresponds to the score given and the y-axis corresponds to the number of users who 

gave that score. Except for the graphic in Figure 5-3, the minimum score is 0 and the 

maximum score is 5, scaling by 1 unit. The average score is also shown.  

The graphic in Figure 5-3 shows the age of the participants in the session, where 

the majority are 15 years old, and the average age is around 15,5 years old. 



 

 

88 

 

Figure 5-3 Participant age distribution. 

The graphic in Figure 5-4 shows that most participants found the activity simple, 

with an average score of 3,5, but it is worth noting that 2 participants gave a score of less 

than half (2.5). 

 

Figure 5-4  Participant responses to BlockLeap’s level of simplicity. 

0

1

2

3

4

5

6

7

8

9

10

15 16 17

U
se

rs

Age

AGE

AVERAGE: 15,5

0

1

2

3

4

5

6

7

8

1 2 3 4 5

U
se

rs

Score

How simple do you rate the activity (more value is 
better value)?

AVERAGE: 3,53



 

 

89 

The graphic in Figure 5-5 shows that most participants found the activity useful, 

with an average of around 3,75. 

The graphic in Figure 5-6 shows that most participants found the activity tasks 

intuitive, with an average score of around 3,4. This average is an indication that smalls 

changes to the usability design of the website should be considered to make it more user-

friendly. 

 

 

Figure 5-5 Perceived usefulness of BlockLeap to participants. 

0

1

2

3

4

5

6

7

8

9

1 2 3 4 5

U
se

rs

Score

How do you value the usefulness of the activity carried out 
(more value is better value)?

AVERAGE: 3,76



 

 

90 

 

Figure 5-6  Perceived intuitiveness of BlockLeap to participants. 

The graphic in Figure 5-7 shows that most participants enjoyed the activity, with 

and average around 3,7. This means that BlockLeap is fun to play and promotes learning 

programing in a fun and educational way. 

 

Figure 5-7 Perceived enjoyability of BlockLeap to participants. 

The graphic in Figure 5-8 shows that most participants found that the increase in 

difficulty is not unreasonable but also not very balanced, whit an average of 3,2. Ideally, 

0

1

2

3

4

5

1 2 3 4 5

U
se

rs

Score

How intuitive do you find the tasks proposed in the 
activity (more value is better value)?

AVERAGE: 3,38

0

1

2

3

4

5

6

1 2 3 4 5

U
se

rs

Score

How enjoyable do you think the activity was 
(more is better)?

AVERAGE: 3,69



 

 

91 

an average of more than 4 would be desirable, so it is necessary to rethink the design of 

the levels. 

The graphic in Figure 5-9 shows that most participants liked the interface of the 

website and the video game, with an average score of 5,4. This is a good sign that the 

website interface and graphics are well designed and do not need any drastic 

adjustments. 

 

Figure 5-8 Participant responses to BlockLeap’s level of difficulty. 

 

0

1

2

3

4

5

6

7

1 2 3 4 5

U
se

rs

Score

How do you rate the increasing level of difficulty 
of the tasks proposed in the activity (higher value 

is better rating)?

AVERAGE: 3,23



 

 

92 

 

Figure 5-9 Participant responses to BlockLeap’s interface and graphics. 

Participants also responded some more post-survey questions where they gave 

their opinion about the session. These responses can be found in Appendix C - Results of 

Validation Session. 

In general, most participants found the activity interesting and useful. However, it 

should be noted that the participant with ID 6 found it repetitive and the participant with 

id 12 found a bug in the level design. These 2 comments lead to rethinking the design of 

the levels already created.  

The concept that has caused the most problem is undoubtedly the variables. To 

better understand the concept of variables blocks, a tutorial or guide should be 

implemented. Other difficulties were the item or skeleton, which would be fixed if a guide 

was implemented. Regarding the difficulty in level selection, it is because the Web Tour 

was not implemented when this session took place. 

0

1

2

3

4

5

6

7

8

1 2 3 4 5

U
se

rs

Score

How do you rate the interface and graphics of the 
application (more rating is better rating)?

AVERAGE: 4,53



 

 

93 

5.4 Conclusions 

The session served as BlockLeap’s initial deployment demonstration with real users 

that provided valuable insights into the use of the platform, identified significant issues, 

and its effectiveness in programming education. 

By working with real users, it became possible to prioritize the tasks needed to 

address the issues identified and make significant improvements to BlockLeap. Ultimately, 

the feedback received from this evaluation improved the final version of BlockLeap by 

fixing the bugs found and implementing some of the improvements suggested.  



 

 

94 

Chapter 6 - Personal Contributions 

6.1 Collaborative work 

This project has been developed collaboratively by a group of four Bachelor of 

Software Engineering students with the help of the project directors Iván Martínez Ortiz 

and Antonio Calvo Morata. 

This chapter attempts to capture the different contributions made by each 

member of this team during this project. These contributions are listed right below. 

Nicolas Espinosa Mooser 

Version Control and CI/CD 

Managed the configuration of GitHub, GitHub Pages, GitHub Actions, and the 

CI/CD pipeline.  

Development Environment 

Managed the folder structures of both Backend and Client repositories, as well as 

compilation and bundling (i.e. node commands and Rollup.js configuration). 

Tool Exploration 

Tested different libraries including Blockly and Phaser as well as their integration 

into the project. 

Interface Design 

Designed and implemented all interfaces of the web application. 

Level Schema Design 

Designed and implemented the structure of levels to be saved in collaboration 

with Santiago Moral Santorio. 



 

 

95 

SPA Logic 

Implemented all SPA logic including routing, controllers, and loaders. 

Phaser 

Individually implemented all final Phaser Scenes including logic, asset loading, etc. 

Collaborated with Santiago Moral Santorio in the testing of Phaser’s RexUI plugin for the 

discarded design of the Level Editor. 

Blockly 

Collaborated with Santiago Moral Santorio in the design and implementation of 

Blockly blocks, code generation and toolbox definitions. 

Event System 

Collaborated with Santiago Moral Santorio to implement the event system for 

Blockly to send data to Phaser. 

Web Tour 

Explored web tour libraries and implemented the web tour functionality in 

BlockLeap. 

Service Worker 

Debugged and completed the Service Worker implementation. 

 

 

 

  



 

 

96 

Santiago Moral Santorio 

Tool Exploration 

Tested some Serious Games and platforms that had a similar goal (namely: 

Scratch33, Articoding34, Human Resource Machine35 and 7 Billion Humans36) prior to the 

final implementation with Blockly and Phaser. 

Blockly 

Collaborated with Nicolas Espinosa throughout the project to implement all usable 

(and some unused due to testing) Blockly blocks, including the design, testing & 

implementation phases. This also takes into account the toolbox definition, code 

generation and workspace plug-ins. 

Phaser 

Analyzed and tested individual Phaser frameworks and plugins like RexUI to 

implement and upgrade the editor functionality (in cooperation with Nicolas Espinosa) 

and developed class-specific logic like win and loss conditions or some animations. 

In addition, implemented the refactor of Phaser to avoid crashes from level to 

level, due to an internal faulty scene deletion, which forced a front-end project-wide 

refactor of files and structure. 

Event System 

 

33 Scratch 

34 Articoding 

35 Human Resource Machine 

36 7 Billion Humans 

https://scratch.mit.edu/
https://github.com/WeArePawns/Articoding
https://tomorrowcorporation.com/humanresourcemachine
https://tomorrowcorporation.com/7billionhumans


 

 

97 

In collaboration with Nicolas Espinosa, implemented the event system for the 

project, including prior design of what events should be, contain and what classes would 

send and listen for said events, in order to communicate Blockly and Phaser via the 

aforementioned events dispatched by the user while playing. 

Debug 

Debugged and corrected several issues throughout the project’s life, both 

reported by users during validation and considered by the team and mentors (ranging 

from faulty collisions to wrapping all Blockly code generation for a better error handling), 

as well as some back-end issues like database corruption.  

Level Design 

Cooperated with the team to develop the released levels, as well as divide them 

into categories and decide which blocks would be available and why. This also takes 

into account the structure of the save files in JSON format, which was severely reworked 

in collaboration with Nicolas Espinosa, to modify the standard Tiled 37 into an acceptable 

and efficient data structure. 

Memory participation 

 Wrote sections from this document, including Chapter 1 (both Spanish and English) 

as well as subsections from Chapter 2, chapter 4 and Chapter 7. Some other contributions 

include Appendix A, as well as the read and correction of English grammar throughout 

the document, including the remake of Chapter 5 (excluding the section 5.3).  

 

37 Tiled - map editor for 2D platforms 

https://www.mapeditor.org/


 

 

98 

Samuel Alejandro Parra Calderón 

Level design and fix errors 

Cooperated with the team to develop the released levels, as well as divide them 

into categories and decide which blocks would be available and why. In addition, 

review and fix errors in the levels found by the students during the validation session. 

Tool Exploration 

Researched xAPI along with xAPI.js, used and designed OpenAPI, tested 

Sequelize, JWT and Blockly events. 

xAPI 

Designed the xAPI traces and their implementation with xAPI.js, studied which 

actions or events to analyse, and created the LRS in Watershed. 

Blockly 

Captured event types generated by Blockly for analysis in xAPI. 

OpenAPI 

Designed and implemented OpenAPI using a YML file in collaboration with Diego 

Álvarez Carretero. 

 

RESTful API 

Implemented endpoints, middlewares, and controllers with Express.js and 

Sequelize for the server in collaboration with Diego Álvarez Carretero. In addition, 

implementation of error handling and error states. 

JWT and Cookies 



 

 

99 

Implemented the use of JWT on client and server using cookies. In addition, cookie 

setting to protect security. 

Login, logout, and registration. 

Implemented the login, logout, and client registration. 

Memory participation 

Wrote sections of this document, including chapter 5, the subsections RESTful API, 

Authentication and cookies, and the xAPI of Chapter 4, and the subsection Improve 

RESTful API endpoints of Chapter 7. Also wrote Appendix B and Appendix C 

  



 

 

100 

Diego Álvarez Carretero 

Sequelize ORM 

Configured the application ORM, created the model with all the database entities 

and relationships, as well as the initialization file and the configuration one. 

Server structure 

Created and implemented the data access objects (DAO) as well as the routers 

and controllers. 

Application tests 

Implemented all the application tests with their aggrupation in specific entities 

and the endpoints of each of them. 

Interface design 

Designed the first approach of the web application interface including the 

navbar, the categories’ view, the levels view and the community one. 

Service Worker 

Implemented the Service Worker file, the registration and update file, and the 

offline view along with Nicolás Espinosa Mooser. 

Serious Games 

Serious game’s introduction and Articoding, Light Bot and CodeCombat analysis, 

the first one in collaboration with Nicolás Espinosa Mooser 

 Proposed solution 

Introduced the proposed solution chapter, tracked the problems of the existing 

solutions, presented the solution, and write the added value of the application. 

Required features 



 

 

101 

Presented the required features of categorized puzzles, progress tracking, 

community, offline functionality, accessibility, and low system requirements. 

Webserver 

Did the webserver introduction as well as the Sequelize explanation, the testing 

suite paragraph, the platform interface along with Nicolas Espinosa Mooser, and the 

Service Worker section of the fourth chapter. 

Conclusions and future work 

Started the conclusions’ introduction and presented the Sequelize Migrations 

section for the future work. 

Entity Relationship Database Diagram 

Developed the Entity Relationship Diagram for the project database in 

collaboration with all the members of the team. 

Tool exploration 

Tried some Serious Games such as Articoding, Light Bot and CodeCombat to 

analyse their characteristics and explore the mentioned solution. 

OpenAPI Specification 

Helped with the specifications of the application endpoints with OpenAPI along 

with Samuel Alejandro Parra Calderón. 

Level design 

Created different levels for each of the official categories, with their board, the 

available blocks, the blocks usage limit, and the starting code blocks structure for the 

user.





 103 

Chapter 7 - Conclusions and Future Work 

In retrospective, this project has achieved its initial objectives. BlockLeap is a tool 

that can introduce programming education within the Spanish education system, a web 

application with a Serious Game designed to teach basic programming skills. This web 

application has also been tested with a group of high school students to validate the 

implementation and its usefulness. 

This is to highlight the research work the team had to make in order to understand 

and internalize things as Computational Thinking, Serious Games and their use in the 

education system or the collection and treatment of the data received by the levels as 

the students dealt with the game. To address this knowledge gaps, the team had to read, 

test, and acquire this knowledge by trying several Serious Games, inform about the use 

and application of Computational Thinking, and all in all get the sense of the objectives 

these projects aim to get a notion of the point this project wanted to reach. Additionally, 

as part of the development, the team had to investigate, learn about and test multiple 

tools such as Phaser and Blockly. 

7.1 Conclusions 

As a closing point, the team believes that the project has achieved its goals, 

having developed a serious game to encourage computational thinking. The game 

underwent formal testing with target users, successfully promoting the necessary skills for 

the current educational paradigm. 

The project has been a challenging undertaking, with ups and downs, requiring 

not only technical expertise but also the learning of new tools and technologies. The 

team had to become familiar with these technologies and frameworks, as well as fine-

tuning them to work together efficiently. 

It is also worth noting that the project had some limitations, often found through 

trial and error, and a summary of those, as well as possible expansions of the project, can 

be described in the next section. 



 104 

Finally, this project represents a step towards incorporating Serious Games as a 

feasible and trustworthy tool for educators to implement with students, as a way to 

promote necessary skills in an engaging and effective way. 

7.2 Future Work 

This section reflects upon certain features that went unfinished or some desired 

capabilities that were thought of but were out of the scope of the project, as well as 

some insights on planned upgrades for the project. 

7.2.1 Private levels 

This feature was conceived as a way to let users create their own levels for fun. This 

would allow each user to have control over which of the levels created would or would 

not be shared with the community. However, this feature was not given a high priority 

due to some pressing issues with the community aspect of the project, like the 

presentation (which levels are shown, latest creations, highest rated…) and since none 

of those aspects were present, this feature was delayed and eventually fell out of scope.  

7.2.2 Advanced level sharing 

The level sharing prospect was thought of as a way to let users share their created 

levels with specific people, like friends or classmates, a gateway to challenge one 

another and set visibility properties of a level. This could allow teachers to see what their 

students are tinkering with and promote fun challenges. This feature was given priority 

due to the amount of value it adds, but it was gated due to the preceding features 

needed for it to work, such as group creation, explored further below. 

7.2.3 Group creation 

The possibility of creating users by groups or bulk creation was a good idea, since 

most students using this would have to be registered to use the full capabilities of 

BlockLeap. However, and more importantly, teachers would want to keep track of their 

students, as well as what levels are being achieved, to see disparities (such as students 

already completing all levels and students falling behind). Since this requires login, the 

idea of the teacher or admin generating users on the go was very useful, it would allow 



 105 

teachers to assign each student a generated account, saving time and allowing for 

easier access to their metrics.  

Another relevant aspect missing for this feature was the capability to create 

groups (like a classroom, or a set of players) which the team felt it was needed in order 

to complete the bulk creation, since the newly created users would need to then be 

placed in a group. 

Due to the lack of administrator privileges (that is, an administrator should have 

more features, like control over groups, what levels are available, and so on) this feature 

was postponed and kept at bay until a favorable structure was built around it, and 

eventually became a big feature to overcome and was left out of the final release. 

7.2.4 Lockdown Mode 

Although partially implemented, being able to lock categories and levels to force 

users to complete the puzzles in order is a valuable feature. BlockLeap’s implementation 

partially deals with logged in users but problems during the implementation for 

anonymous users and LocalStorage prevented the addition of this feature to the stable 

version. Additionally, this feature should not be mandatory in case a demonstration or 

fully open version is needed with all categories and levels unlocked. 

7.2.5 Improve RESTful API endpoints 

The current design of endpoints that are used with GET verbs does not follow good 

practice, because many endpoints would not be needed if another endpoint, such as a 

GET all level, implemented the following concepts: 

• Pagination. This allows handling large datasets more efficiently and improves the 

user experience by reducing the loading time. A use case would be when loading 

community levels. 

• Projection. Using projection via a query parameter, usually called select, allows 

only the data specified in select to be retrieved. 

• Filtering. Query parameters can be used to filter information, for example, to 

retrieve the levels created by a specific user. 



 106 

Implementing these concepts in the endpoint design improves the efficiency, 

maintainability, performance, and scalability of the RESTful API. 

7.2.6 Sequelize Migrations 

Sequelize Migrations is a feature provided by Sequelize, the ORM that was used in 

the creation of the server-side of the application. 

This feature can alter the database schema in a systematic and reversible way. 

To represent each database change, there will be a migration, ensuring that the 

database builds coherently as the application keeps growing or changes. 

The introduction of this feature would lead the developers to keep track of the 

changes carried out against the database schema to create a sort of version control for 

this conversion. This feature would also allow the creation of the database from scratch 

by just applying all the migrations files one by one with the option to roll back to a previous 

state if there is a deployment problem maintaining the integrity of the data untouched. 

All these utilities that the Sequelize Migrations provides would make an easier 

journey for the programmers and will supply a better and reliable consistency to the 

application database schema at the same time.



 107 

BIBLIOGRAPHY 

[1]  OECD, "Our global reach - OECD," 2022. [Online]. Available: 

https://www.oecd.org/about/members-and-partners/. 

[2]  OECD, «PISA,» 2024. [En línea]. Available: https://www.oecd.org/pisa/. 

[3]  www.oecd.org, «Learning in the Digital World - PISA,» [En línea]. Available: 

https://www.oecd.org/pisa/innovation/learning-digital-world/. 

[4]  P. Spangenberger, F. Kapp, L. Kruse, M. Hartmann y S. Narciss, «Can a Serious Game 

Attract Girls to Technology Professions?,» International Journal of Gender, Science 

and Technology, vol. 10, nº 2, 2018.  

[5]  A. M. S. a. P. M. M. T. Duarte Balvís, «Uso de juegos serios para mejorar el aprendizaje 

de la programación en la escuela,» 2022. [En línea]. Available: 

https://docta.ucm.es/entities/publication/1111fecf-12f1-4cbd-9ac1-

462b991b395e. [Último acceso: May 2024]. 

[6]  D. Yaroslavski, «Text is keeping kids from coding,» Medium, 2017.  

[7]  P. Moreno-Ger, D. Burgos y J. Torrente, «Digital games in eLearning environments: 

Current uses and emerging trends,» Simulation & Gaming, vol. 40, nº 5, pp. 669-687, 

2009.  

[8]  Scratch Foundation, «Scratch - About,» 2019. [En línea]. Available: 

https://scratch.mit.edu/about. 

[9]  Ministerio de educación y formación profesional, «Estadística de la Sociedad de la 

Información y la Comunicación,» 2021. [En línea]. Available: 

https://www.educacionfpydeportes.gob.es/dam/jcr:bd19d3f0-6fca-4819-9206-

2ac80dbc8859/notasice20-21.pdf. [Último acceso: 2024]. 



 108 

[10]  L. A. Bucki, Word 2013 Bible, John Wiley & Sons, 2013.  

[11]  CFI, «Cursos de Formación en Informática,» [En línea]. Available: 

http://cursosinformatica.ucm.es. [Último acceso: 01 06 2019]. 

 



 109 

APPENDIXES 

Appendix A - Game Design 

This appendix aims to provide a comprehensive guide to the Blockly blocks 

created as part of BlockLeap’s Serious Game, as well as what entities and sprites have 

been used. 

Blocks 

The blocks used for BlockLeap all have a category and generating code behind 

it, which determines everything, from tooltips to colors. A list with all of the used & unused 

blocks can be found below: 

 

This is the movement block, it’s the 

quintessential block for navigating the 

game, and it can choose the direction 

and the number of blocks to move, which 

can be a number block or a variable 

block. 

 

The rotation block can make the player 

turn to a side. It had its uses when facing a 

certain direction implied being able to 

interact or not with something (e.g. if the 

player is not facing the exit, then the 

player cannot win) but since that 

condition was removed it was removed 

from the production version. 

 

This block allows to change all the traps of 

the map either on or off. This allows for the 

traversal of difficult terrain and then it 



 110 

would’ve enabled for the modification of 

specific traps to stop enemies. 

 

The text block is a basic Blockly block, but 

is not used, since it’s mainly used to set 

variable names and such, and that part is 

handled directly within the variable blocks 

themselves. Hence, this is no longer 

needed, as of now. 

 

The number block is another pillar of 

Blockly. In this case, it was heavily used, 

both for early levels and to test loop 

conditions. It only receives positive 

numbers and is the most used block 

(because it can also go inside the 

movement block). 

 

The basic loop block. This took a while, 

since it both accepts numbers and 

variable blocks, and has a failsafe in case 

someone enters an absurdly big number, 

to prevent crashes. 

 

The advanced loop block, which 

evaluates conditions and logical 

statements, such as 1 < 5, which is always 

true, or VARIABLEBLOCK > 2, with the 

hopes to modify the block and make it an 

ending loop. It has not undergone any 

testing and hence is not in the official 

game. 



 111 

 

The basic condition statement, which 

evaluates a logical input and decides 

whether or not to execute the inside 

blocks. Due to the project’s architecture, 

the if statement evaluates at the 

beginning of the code and not where its 

placed, making its testing difficult and 

hence it did not make it to the official 

game. 

 

A complex iteration of the previous block. 

Evaluate a condition and execute 

something if said condition is met. 

Otherwise, execute another set of blocks. 

 

Logical evaluator of two expressions, 

which are connected on the right. This 

block evaluates whether both are true or 

not, and its meant to be used inside 

another block, such as an if or loop block. 

 

Another logical operator, which checks 

whether two connected blocks or sets of 

blocks are equal, not equal, or 

comparable (greater or lower) if possible. 

This block is not usable and hence it did 

not make it to the first release. 

 

The variable block. This block was 

amongst the hardest to develop, since 

Blockly handles variables different from 



 112 

inputs, and so a variable is stored in a 

different region of the application itself. 

This block is meant to be set to a value 

(such as number or id of a playable item 

or string) and then referenced as many 

times as needed with the block below. 

 

The callable variable block acts as a basic 

type like a number, and is used in some 

levels to force the user to think creatively 

with only one variable and no additional 

setter blocks. 

 

 

This block went unused due to the fact 

that the setter block for variables already 

allows for setting it to a number, whichever 

one was created, so this seemed a bit less 

useful. 

 

  It is also worth mentioning that some blocks were planned as well, such as function 

or method blocks, but due to testing constraints with the gaming framework, they did not 

go beyond a staging phase. 

Game Entities 

The entities used in BlockLeap are part of a Creative Commons 038 package used 

by the team, and they can be explored below: 

 

38 https://creativecommons.org/public-domain/cc0/ 



 113 

 

The player, represented as a frog. It’s the 

main entity of the game since it’s the one 

players interact with the most.  

 

The exit, portrayed (rather accurately) as 

a ladder, carrying the player to the next 

level of the game.  

 

The chest represents the bonus in previous 

sections, and it’s a challenge to obtain the 

extra points of some levels. 

  

The trap, an obstacle for the player, 

meant to force avoidance or disabling if 

the appropriate block is allowed in a 

given level. 

 

The omni-wall, a 4-directional wall made 

from an amalgamation from the original 

sprites, proudly designed by Nicolas 

Espinosa, it is the in-bounds wall of the 

game, meant to be aesthetically pleasing 

on all sides and to indicate impassable 

terrain. 

 

The enemy. This entity has a 

predetermined pattern, represented as a 

skeleton the traverses the map and ends 

current try on collision with the player. 

 



 114 

Appendix B - BlockLeap Solutionary 

This appendix contains every puzzle created and a possible solution, as some have 

multiple solutions. Puzzles are presented categorized and from easiest to hardest 

difficulty. 

Introduction 

1-1: Movement 

Puzzle Possible Solution 

 
 

1-2: Movement-2 

Puzzle Possible Solution 

 

 



 115 

1-3: Trap 

Puzzle Possible Solution 

 
 

1-4: Trap – 2 

Puzzle Possible Solution 

 

 

1-5: Enemy 

Puzzle Possible Solution 



 116 

 

 

1-6: Enemy – 2 

Puzzle Possible Solution 

 

 

1-7: Chest 

Puzzle Possible Solution 



 117 

 

 

1-8: Test 

Puzzle Possible Solution 

 

 

1-9: Test -2 

Puzzle Possible Solution 



 118 

  

Variables 

2-1: Movement Variable 

Puzzle Possible Solution 

 

 

2-2: Movement Variable-2 

Puzzle Possible Solution 



 119 

  

2-3: Movement Variable-3 

Puzzle Possible Solution 

 

 

2-4: Multi Variables 

Puzzle Possible Solution 



 120 

 

 

2-5: Recycle 

Puzzle Possible Solution 



 121 

 

 

2-6: Recycle - 2 

Puzzle Possible Solution 



 122 

 

 

2-7: Chests! 

Puzzle Possible Solution 

 

 



 123 

 

Data Types 

3-1: Trap 

Puzzle Possible Solution 

 
 

3-2: Trap - 2 

Puzzle Possible Solution 



 124 

 
 

3-3: Player 

Puzzle Possible Solution 

 

 

  



 125 

Appendix C - Results of Validation Session 

Initial survey  

 

Post-session survey 

 

  



 126 

Answers about post-survey questions, where 13 students were present in the 

validation session. Here are the things participants answered. 

• Question: 

o What did you think of the activity? 

• Answer: 

o 1. Fun and useful 

o 2. It has been very good and entertaining 

o 3. Entertaining 

o 4. I found it very interesting and entertaining to learn the basic concepts 
of programming 

o 5. Very entertaining and nice to look at 

o 6. Repetitive 

o 7. Funny 

o 8. Entertaining 

o 9. Very ingenious 

o 10. I hate the skeleton 

o 11. Very entertaining 

o 12. Fun, I learned some cool stuff, but the levels don’t require you to use 
the mechanics that are introduced, for example in variables don’t need 
to use them 

o 13. Very good 

  



 127 

• Question: 

o Which task or concept of the activity did you find most difficult? 

• Answer: 

o 1. Understanding variables 

o 2. About the item 

o 3. Level selection 

o 4. Mixing between variables and movements 

o 5. When setting variables and movements 

o 6. Final levels 

o 7. When setting variables 

o 8. About the item 

o 9. The first skeleton 

o 10. Logical functions 

o 11. Nothing 

o 12. The fun mechanic of bumping into wall to avoid enemies 

o 13. Nothing  



 128 

• Question: 

o Do you have any suggestions for improving the activity? 

• Answer: 

o 1. Keep the character facing the direction in which it is moving 

o 2. Create some kind of tutorial 

o 3. Fix bugs 

o 4. More difficulty 

o 5. Nothing 

o 6. Implement more options 

o 7. Nothing 

o 8. Nothing 

o 9. Create some kind of tutorial 

o 10. Nothing 

o 11. Fix the bugs mentioned above and be able to play the levels you 
create in the editor 

o 12. I wish you could move diagonally. It would change the style of the 
game a lot 

o 13. Nothing 

 

 



 129 

Appendix D - Additional Contributions 

 

 As Santiago Moral Santorio was unable to attend the validation session, Antonio 

Calvo Morata edited him into the photo (Santi wears a suit to work and showed up to 

our weeklies overdressed). 


	Dedication
	Acknowledgements
	Resumen
	Abstract
	Table of Contents
	Figures Index
	Tables Index
	Chapter 1 - Introduction
	1.1 Motivation
	1.2 Objectives
	1.3 Work Plan
	1.3.1 Domain Study
	1.3.2 Design
	1.3.3 Development
	1.3.4 Validation

	1.4 Work Methodology
	1.4.1 Planning
	1.4.2 Workflow
	1.4.3 Development Environment


	Introducción
	1.5 Motivación
	1.6 Objetivos
	1.7 Plan de trabajo
	1.7.1 Estudio de Dominio
	1.7.2 Diseño
	1.7.3 Desarrollo
	1.7.4 Validación

	1.8 Metodología de Trabajo
	1.8.1 Planificación
	1.8.2 Flujo de Trabajo
	1.8.3 Entorno de Desarrollo


	Chapter 2 - Domain Study
	2.1 Digital Education in Spain
	2.2 Serious Games
	2.2.1 Articoding
	2.2.2 Light Bot
	2.2.3 CodeCombat
	2.2.4 Scratch


	Chapter 3 - Proposed Solution
	3.1 Problems of Existing Solutions
	3.2 Solution
	3.3 Required Features
	3.3.1 Categorized Puzzles
	3.3.2 Progress Tracking
	3.3.3 Community
	3.3.4 Educator Toolset
	3.3.5 Offline Functionality
	3.3.6 Accessibility
	3.3.7 Low System Requirements

	3.4 Design
	3.4.1 Serious Game Design
	3.4.2 Web application Design
	3.4.3 Database Creation

	3.5 Added Value

	Chapter 4 - Development
	4.1 Architecture
	4.2 Server
	4.2.1 Webserver
	4.2.2 RESTful API
	4.2.3 Authorization and cookies
	4.2.4 Sequelize
	4.2.5 Testing Suite

	4.3 Client
	4.3.1 Platform Interface
	4.3.2 SPA Router
	4.3.3 Game Controller
	4.3.3.1 Phaser Controller
	4.3.3.2 Blockly Controller
	4.3.3.3 Event System

	4.3.4 Service Worker
	4.3.5 xAPI
	4.3.5.1 xAPI Traces
	4.3.5.2 XAPI User evaluation

	4.3.6 Web tour


	Chapter 5 - Validation
	5.1 Session Details
	5.2 Feedback & Errors
	5.3 Data Analysis
	5.4 Conclusions

	Chapter 6 - Personal Contributions
	6.1 Collaborative work
	Nicolas Espinosa Mooser
	Version Control and CI/CD
	Development Environment
	Tool Exploration
	Interface Design
	Level Schema Design
	SPA Logic
	Phaser
	Blockly
	Event System
	Web Tour
	Service Worker

	Santiago Moral Santorio
	Tool Exploration
	Blockly
	Phaser
	Event System
	Debug
	Level Design
	Memory participation

	Samuel Alejandro Parra Calderón
	Level design and fix errors
	Tool Exploration
	xAPI
	Blockly
	OpenAPI
	RESTful API
	JWT and Cookies
	Login, logout, and registration.
	Memory participation

	Diego Álvarez Carretero
	Sequelize ORM
	Server structure
	Application tests
	Interface design
	Service Worker
	Serious Games
	Proposed solution
	Required features
	Webserver
	Conclusions and future work
	Entity Relationship Database Diagram
	Tool exploration
	OpenAPI Specification
	Level design



	Chapter 7 - Conclusions and Future Work
	7.1 Conclusions
	7.2 Future Work
	7.2.1 Private levels
	7.2.2 Advanced level sharing
	7.2.3 Group creation
	7.2.4 Lockdown Mode
	7.2.5 Improve RESTful API endpoints
	7.2.6 Sequelize Migrations


	Bibliography
	Appendixes
	Appendix A - Game Design
	Blocks
	Game Entities

	Appendix B - BlockLeap Solutionary
	Introduction
	1-1: Movement
	1-2: Movement-2
	1-3: Trap
	1-4: Trap – 2
	1-5: Enemy
	1-6: Enemy – 2
	1-7: Chest
	1-8: Test
	1-9: Test -2

	Variables
	2-1: Movement Variable
	2-2: Movement Variable-2
	2-3: Movement Variable-3
	2-4: Multi Variables
	2-5: Recycle
	2-6: Recycle - 2
	2-7: Chests!

	Data Types
	3-1: Trap
	3-2: Trap - 2
	3-3: Player


	Appendix C - Results of Validation Session
	Initial survey
	Post-session survey

	Appendix D - Additional Contributions