5. Git Learning Game V2

5.1. Einleitung

Die gute Resonanz auf die erste Version unseres Git-Learning-Games, die große Freude unseres Teams an der Entwicklung, sowie die unzähligen Ideen und Möglichkeiten zur Verbesserung und Erweiterung haben uns dazu bewogen, eine zweite Version des Git-Spiels zu entwickeln. Diese Version soll nicht nur die bestehenden Funktionen verbessern, sondern auch neue Features und eine verbesserte Benutzererfahrung bieten. Der Fokus lag hierbei vor allem auf einer besseren Spiel- und Lernerfahrung für den Nutzer aber auch auf der Verbesserung der technischen Basis des Spiels, die uns die Möglichkeit der Weiterentwicklung in Zukunft erleichtern soll.

5.2. Demo

5.3. Grundlagen

Die meisten Grundlagen sind die gleichen wie bei der ersten Version des Git-Spiels (Version 1 Grundlagen). Es wurde größtenteils auf Basis der bestehenden Technologien weiterentwickelt.

5.3.1. Git

Git ist ein verteiltes Versionskontrollsystem, das zur Nachverfolgung von Änderungen in Quellcodeprojekten verwendet wird. Es ermöglicht mehreren Entwickler:innen, parallel am selben Projekt zu arbeiten, Änderungen zu verwalten und frühere Versionen wiederherzustellen [GIT].

5.3.2. Local Storage

Der Local Storage ist eine Webtechnologie, die es ermöglicht, Daten direkt im Webbrowser eines Nutzers zu speichern, dauerhaft und ohne Ablaufdatum. Sie gehört zur Web Storage API, die von modernen Browsern wie Chrome, Firefox, Safari und Edge unterstützt wird. Im Gegensatz zu Cookies werden Daten im Local Storage nicht automatisch mit jeder HTTP-Anfrage an den Server gesendet, was ihn effizienter und sicherer für bestimmte Anwendungsfälle macht.

5.3.3. Didaktik

In dieser Version wird nun auch ein größerer Fokus auf Didaktik im Spielablauf gelegt. Hierzu wurden die Level nach Schwierigkeitsgraden in Sektoren unterteilt, sodass gezielt sowohl Anfänger als auch fortgeschrittene Git-Nutzer unser Lernspiel zur verbessserung ihrer Fähigkeiten einsetzen können. Auch Wiederholungen sind bewusst eingebaut, damit die Spieler sich gelernte Git-Befehle besser merken können.

5.4. Vorgehensweise

5.4.1. Git Implementierung

Zu Beginn wurde versucht, im Backend innerhalb eines Docker-Containers ein eigenes Git-Repository zu erstellen und dieses mit dem Frontend zu verbinden. Zunächst kam ein Git-Dummy zum Einsatz, um Git-Kommandos und deren Wirkungen visuell zu simulieren. Anschließend wurde ein echtes Repository im Container integriert, das erfolgreich funktionierte: Git-Befehle konnten über die Kommandozeile ausgeführt und die Ausgaben im Frontend als Text angezeigt werden. Im weiteren Verlauf wurde jedoch festgestellt, dass dieser Ansatz potenzielle Sicherheitsrisiken mit sich bringt und die Skalierbarkeit der Anwendung – ein zentrales Ziel der zweiten Version des Git-Spiels – einschränkt. Aus diesem Grund wurde der ursprüngliche Ansatz wieder verworfen. Der Fokus verlagerte sich anschließend auf die Verbesserung des Workflows, die Optimierung der Benutzeroberfläche sowie den Ausbau einer umfassenderen Bibliothek an Spielantworten. Ziel war es, bei korrekten Eingaben nicht nur einfache Rückmeldungen wie „Korrekt“ zu liefern, sondern auch realistische Ausgaben anzuzeigen, wie sie Git in der entsprechenden Situation tatsächlich generieren würde.

5.4.2. Speicherung des Spielfortschritts

Um das Speichern des Spielfortschritts zu ermöglichen, musste zunächst die Frontendlogik so umgebaut werden, dass der Fortschritt zentral an einer Stelle hinterlegt wird. In Rahmen dieses Refactorings wurden auch weitere Zustände der UI und die Spiellogik in eigene Komponenten ausgelagert. Da dadurch der Spielfortschritt in einer dedizierten Komponente gespeichert wird, besteht die Logik den Fortschritt in den Local Storage des Browsers zu speichern nur noch daraus, bei jeder Änderung des Fortschritts den Local Storage zu aktualisieren und beim Laden des Spiels den Fortschritt aus dem Local Storage auszulesen. Dank der Änderung kann der Nutzer nun nach dem Abschließen eines Levels den Browser-Tab schließen und beim nächsten Besuch des Spiels an der selben Stelle fortsetzen, an der er pausiert hatte.

5.4.3. Gitlab pipeline

Es wurde eine GitLab-Pipeline aufgesetzt, die bisher nur das git-learning-game Frontend betrifft. Hierzu wurde auf einer VM ein GitLab Runner gehostet. Diese GitLab-Runner-Instanz ist containerisiert und mit dem GitLab-Repository verknüpft.

Die erste Stage ist das Linting – hierbei werden die Frontend-Dateien mit ESLint überprüft. Die zweite Stage überprüft den Build-Prozess: Dabei wird das Docker-Image unseres Frontends gebaut und mit npm audit fix geprüft, ob automatisch behebbare Schwachstellen in den verwendeten npm-Paketen vorliegen. Sollte der Build fehlschlagen oder es nicht behebbare Sicherheitslücken geben, schlägt diese Stage fehl.

Diese Stages werden nur ausgeführt, wenn es Änderungen im Ordner frontend gibt. Das bedeutet, es erfolgen keine unnötigen Prüfungen, wenn Änderungen in anderen Projekten unseres Multi-Projekt-Repositories vorgenommen werden.

Schließlich wurde der main-Branch des Repositories, mit Hinblick auf mögliches automatisiertes Deployment, geschützt: Entwickler können nicht mehr direkt auf diesen Branch committen. Änderungen müssen immer über einen Merge Request erfolgen. Merge Requests sind nur möglich, wenn die Pipeline zuvor fehlerfrei durchgelaufen ist.

5.4.4. Überarbeitung der Story

Die Anzahl der Level wurde aus didaktiktischen Gründen deutlich reduziert(auf 119). Damit ist es für den Spieler leichter, seinen Spielerfolg(dem Ausbruch aus dem Git-Gefängnis) vor Augen zu halten. Zudem wurden die Level in Bereiche aufgeteilt( Kellerverlies-> Werkstattbereich->Dankesnotiz-Projekt->Gefangenen-Tagebuch->Exploit-Projekt->Ausbruch-Krise->Kontrollraum->Nachtschicht-Logbuch->Ausbruch ). Hierbei beinhalten die ersten beiden Bereiche nur ‚leichte‘ Git-Befehle, die darauffolgenden Bereiche(4 und 5) bereits schwierigere und die hierauf folgenden Bereiche(6 und 7) sehr fortgeschrittene Git-Befehle. Die Schwierigkeit in den letzten 3 Sektoren liegt hingegen in der großen Anzahl an verschiedenen Git-Befehlen die dort vorkommen.

5.4.5. Verbesserung der UI/ UX

Durch den Einsatz der Vue.js-Komponentenbibliothek Vuetify war bereits eine sehr ansprechende Benutzeroberfläche aus der ersten Version des Git-Spiels vorhanden. Diese wurde auch gegen einige UI-Standarts gegengeprüft, das Grundlayout und Design haben sich bewährt jedoch bewährt und wurden nur durch kleinere Anpassungen verbessert. Ein größeres Problem in der User Experience stellte das unabsichtliche Neustarten des Spiels dar, wenn der Nutzer ausveresehen auf den „Reset“ Button, direkt neben dem „Hinweis anzeigen“ Button klickte. Dies wurde durch einen Zusätzlichen Bestätigungsdialog behoben, der nun erscheint, wenn der Nutzer auf den „Reset“ Button klickt. Als etwas ungünstig hat sich auch der Dialog „Level abgeschlossen“ nach jedem einzelen Befehl erwiesen. Daher wird, mit der neuen Struktur der Geschichte einhergehend, dieser Dialog nur noch am Ende eines „Bereiches“ des Gefängnisses angezeigt. Zudem wird der letzte Satz, der meist die Frage nach dem gesuchten Git-Befehl beinhaltet, fett gedruckt. Somit muss der Leser nicht mehr die ganze Lernstory lesen sondern kann sich auch ausschließlich auf das Erlernen von Git-Befehlen konzentrieren. Ein weiteres neues Feature ist die Möglichkeit, gezielt Bereiche auszuzwählen die dem gewünschten Schwierigkeitsgrad entsprechen. Hierzu wurde ein Dropdown-Menü entwickelt, das die verschiedenen Sektoren als Auswahlmöglichketen zur Verfügng stellt. Diese wurden farblich nach ihrer Schwierigkeit gekennzeichnet(Grün: leicht, Gelb: mittel, Orange: mittel-schwer, Rot: schwer).

5.5. Fazit & Ausblick

Wir betrachten unser Ziel, das Git Game auf ein neues Level zu heben, als erreicht. Die grundlegende Überarbeitung umfasst eine vollständig neue Story mit eigenen Levels und differenzierten Schwierigkeitsgraden, eine verfeinerte Ein- und Ausgabe mit der Möglichkeit, mehrere korrekte Antworten zu akzeptieren, sowie die Option, den Spielfortschritt im Browser zu speichern. Ergänzt wird dies durch ein verbessertes User Interface und optimierte Eingabemöglichkeiten. Damit ist das Projekt im Rahmen des DVA-Praktikums als abgeschlossen zu betrachten – ein zukünftiger Ausbau von Levels sowie in der Testphase identifizierte Fehler bieten Potenzial für weitere Verbesserungen. Im nächsten Schritt möchten wir die App weiter verbreiten, sodass möglichst viele Studierende der THA – und auch darüber hinaus – das Git Game nutzen können, um ihr Wissen über Git zu vertiefen und einen leichteren Einstieg in das Versionskontrollsystem zu finden. Dies kann zugleich als erweiterte und intensive Testphase dienen. Wir hoffen, mit unserer Arbeit einen wertvollen Beitrag zur Unterstützung vieler Lernender leisten zu können.

5.5.1. Gitlab pipeline

Die von uns aufgebaute Pipeline ermöglicht es dem Entwickler, bei jedem Commit schnelles Feedback über mögliche Fehler zu bekommen. Dadurch wird die Codequalität hoch gehalten, und Fehler können schnell identifiziert und dadurch leichter behoben werden.

Es wäre sicherlich erstrebenswert, diese Pipeline weiter auszubauen. Hierbei sollten zunächst Stages für das Backend des git-learning-games erstellt werden, die Änderungen am Backend überprüfen. Hierdurch wäre es dann möglich, automatisierte Integrationstests zu erstellen. Schließlich wäre automatisiertes Deployment noch eine hilfreiche Ergänzung der Pipeline, zurzeit wird dies noch manuell gemacht. Hierbei wäre es mit nicht zu viel Aufwand möglich, automatisch den Projektstand vom Main-Branch über Docker direkt auf der VM zu deployen.

5.6. Literaturverzeichnis

[GIT]

Chacon, S., & Straub, B. (2014). Pro Git (2nd ed.). Verfügbar unter: <https://git-scm.com/book> (Zugriff am: 20.05.2025)