{"id":28550,"date":"2026-02-21T12:48:56","date_gmt":"2026-02-21T11:48:56","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=28550"},"modified":"2026-02-21T12:48:58","modified_gmt":"2026-02-21T11:48:58","slug":"entwicklung-einer-verteilten-cloud-anwendung-am-beispiel-eines-multiplayer-spiels","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/21\/entwicklung-einer-verteilten-cloud-anwendung-am-beispiel-eines-multiplayer-spiels\/","title":{"rendered":"Entwicklung einer verteilten Cloud-Anwendung am Beispiel eines Multiplayer Spiels"},"content":{"rendered":"\n

Einleitung<\/h2>\n\n\n\n

Den meisten sollte das Spielprinzip von \u201cCookie Clicker\u201d bekannt sein: Ein Klick auf einen Keks erh\u00f6ht den Spielstand um einen Punkt. Das Spiel ist endlos, hat keine Punktegrenze. Es geht darum, im Leaderboard nach oben zu klettern. Im Rahmen der Vorlesung \u201cSystem Engineering and Management\u201d (143101a)  erweiterten wir das Konzept zu einem Echtzeit-Multiplayer Spiel. Das Spiel nannten wir \u201cOvercookied\u201d.<\/p>\n\n\n\n

In Overcookied treten zwei zuf\u00e4llig ausgew\u00e4hlte Spieler in einem 60 Sekunden Match gegeneinander an. Wer am Ende die meisten Klicks hat, gewinnt. Zus\u00e4tzlich spawnt alle 5-10 Sekunden ein \u201cGolden Cookie\u201d. Der Spieler, der zuerst auf den Golden Cookie klickt, erh\u00e4lt einen kurzen \u201eDouble Click”-Bonus, bei dem jeder Klick doppelt gewertet wird.<\/p>\n\n\n\n

Das Ziel des Projekts war nicht die Entwicklung eines ausgereiften Spiels, sondern das Kennenlernen und Verstehen von Echtzeit-Gameloops in verteilten Systemen sowie moderne Web- und Cloud-Technologien. Wir wollten Amazon Web Services (AWS) durch praktische Implementierung kennenzulernen, indem das Spiel als verteiltes System betrieben wird, horizontal skalierbar ist und gleichzeitig geringe Latenzen, konsistente Zust\u00e4nde sowie eine zuverl\u00e4ssige Synchronisation zwischen den Clients bietet. Zus\u00e4tzlich war das Projekt durch einen Budgetrahmen begrenzt. Die Umsetzung erfolgte innerhalb eines AWS-Free-Tier-Accounts mit einem verf\u00fcgbaren Guthaben von 200 US-Dollar. Aufgrund dieser Einschr\u00e4nkung musste die Infrastruktur jederzeit automatisiert auf- und abgebaut werden k\u00f6nnen, um Kosten zu kontrollieren und unn\u00f6tige Ausgaben zu vermeiden. Also musste unsere Infrastruktur zus\u00e4tzlich als “Infrastructure as Code\u201d aufgebaut werden, um reproduzierbare und kosteneffiziente Deployments zu erm\u00f6glichen. <\/p>\n\n\n\n

In den folgenden Kapiteln des Blogeintrags werden die einzelnen Umsetzungsschritte, Architekturentscheidungen und Herausforderungen beschrieben. <\/p>\n\n\n\n

Lernziele<\/h2>\n\n\n\n

Unser Ziel war es, praktische Erfahrungen mit Cloud-nativer Softwareentwicklung zu sammeln und die wichtigsten Konzepte verteilter Systeme kennenzulernen und in einem realen Projekt anzuwenden. Den Fokus legten wir dabei auf den Cloud-Anbieter Amazon Web Services, wo wir unsere Anwendung in einem Kubernetes Cluster deployen wollten, sowie die Verwendung von Infrastructure as Code. Au\u00dferdem wollten wir lernen, wie ein Echtzeit- Multiplayer Gameloop funktioniert und wie er sich in einem verteilten System realisieren l\u00e4sst.
<\/p>\n\n\n\n

Anforderungen<\/h2>\n\n\n\n

Aus unseren Lernzielen ergaben sich folgende funktionale und nichtfunktionale Anforderungen an das Projekt Overcookied:<\/p>\n\n\n\n

Funktionale Anforderungen<\/strong><\/td>Nicht-funktionale Anforderungen<\/strong><\/td><\/tr>
– Login \u00fcber Google OAuth 2.0Zuf\u00e4lliges Matchmaking zwischen 2 Spielern
– Echtzeit-Multiplayer-Gameloop (Begrenzung der Spielzeit auf 1min pro Match)
– Live Anzeige der Klicks und Scores (Eigene und des Gegners)
– Goldener Cookie mit 5s begrenztem Doppelte-Punkte-Bonus
– Leaderboard und Spielhistorie<\/td>		– Geringe Latenz
– Konsistente Spielst\u00e4nde\u00a0
– Hohe Verf\u00fcgbarkeit (Horizontale Skalierbarkeit)
– Kostenkontrolle (Reproduzierbarer Infrastruktur Auf- und Abbau)
– Trennung von Frontend, Backend und Infrastruktur
– Ansprechendes UI<\/td><\/tr><\/tbody><\/table>
Tab 1. Funktionale und nichtfunktionale Anforderungen an “Overcookied”<\/em><\/figcaption><\/figure>\n\n\n\n

Echtzeit Gameloop<\/h2>\n\n\n\n

Die Anwendung hat drei Schichten: ein Next.js-Frontend, ein Go-Backend mit WebSocket-Support und eine Datenhaltungsschicht. Im Frontend nutzten wir TypeScript sowie Next.js, wo wir bereits Erfahrung hatten. Mithilfe von Tailwind konnte so schnell das UI f\u00fcr das Spiel erstellt werden. Das Frontend besteht aus diesen Pages:<\/p>\n\n\n\n

\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n<\/div>\n\n\n\n

Fig. 1 – Main-Menu-Page (links): Game History und Leaderboard | Fig. 2 – Game-Page (rechts): Cookie + Golden Cookie, sowie ein HUD \u00fcber den aktuellen Spielstand<\/em><\/p>\n\n\n\n

F\u00fcr das Backend w\u00e4hlten wir die Programmiersprache Go, die f\u00fcr uns neu war. Durch AI-assisted Coding und den vielf\u00e4ltigen guten Dokumentationen aufgrund der Popularit\u00e4t von Go, wurde der Einstieg in neue Programmiersprache deutlich erleichtert. Go eignet sich aufgrund seiner Performance und seiner einfachen Concurrency mittels Goroutines und Channels besonders gut f\u00fcr serverseitige Echtzeit-Anwendungen und wurde daher f\u00fcr den Multiplayer-Gameloop eingesetzt.\u00a0<\/p>\n\n\n\n


<\/p>\n\n\n\n

\"\"<\/a>
Fig. 3 – Schematische Abbildung des Spielablaufs<\/em><\/figcaption><\/figure>\n\n\n\n

Wenn ein Spieler die Game-Seite betritt, \u00f6ffnet das Frontend eine WebSocket-Verbindung. Im Frontend ist die echtzeit Spiellogik in einem Custom Hook gekapselt. Er verwaltet die WebSocket-Verbindung, den Spielstatus (IDLE \u2192 MATCHMAKING \u2192 PLAYING \u2192 FINISHED), Scores, Timer und Power-Ups. Das Frontend ruft nur exponierte Methoden auf (sendClick<\/code>, claimGoldenCookie<\/code>, quitGame<\/code>) und reagiert auf State-\u00c4nderungen.\u00a0<\/p>\n\n\n\n

Das Backend registriert die Websocket Verbindung und erstellt einen Client mit den Benutzerdaten. F\u00fcr jeden Client werden zwei parallele Goroutinen gestartet, sogenannte \u201cPumps\u201d. Der Name kommt aus der Analogie zu einer Wasserpumpe: Eine Pump-Funktion l\u00e4uft in einer Endlosschleife und “pumpt” Daten kontinuierlich von einer Quelle zu einem Ziel. Sie blockiert, wartet auf den n\u00e4chsten Datensatz, leitet ihn weiter, und wartet erneut.<\/p>\n\n\n\n

Es werden zwei Goroutines ben\u00f6tigt, da Websocket Verbindungen gleichzeitig lesen und schreiben. Ein Spieler kann jederzeit klicken (Read), w\u00e4hrend der Server ihm gleichzeitig Timer-Updates schickt (Write). Ein einzelner Loop m\u00fcsste zwischen Lesen und Schreiben wechseln und blockiert sich so selbst: \u200b\u200bWenn gerade kein Click ansteht, wartet die \u201cRead-Routine\u201d auf unbestimmte Zeit und in dieser Zeit k\u00f6nnen keine Server-Events gesendet werden. Umgekehrt blockiert ein langsamer Client das Schreiben und staut eingehende Nachrichten auf. Die Trennung in zwei Goroutines l\u00f6st das Problem:<\/p>\n\n\n\n