{"id":28654,"date":"2026-02-28T17:24:14","date_gmt":"2026-02-28T16:24:14","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=28654"},"modified":"2026-03-01T13:36:16","modified_gmt":"2026-03-01T12:36:16","slug":"multiplayer-arena-dynamische-game-sessions-mit-docker-fastapi","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/28\/multiplayer-arena-dynamische-game-sessions-mit-docker-fastapi\/","title":{"rendered":"Multiplayer-Arena: Dynamische Game-Sessions mit Docker & FastAPI"},"content":{"rendered":"\n

Game:<\/strong> https:\/\/46.101.127.20.sslip.io\/ (online bis 31. M\u00e4rz 2026) (beachte Readme im Git!<\/strong>)<\/p>\n\n\n\n

Git Repo<\/strong>: https:\/\/github.com\/ek101-collab\/ArenaGame-with-ContainerSessions<\/p>\n\n\n\n

Einleitung und Motivation<\/h2>\n\n\n\n

Im Rahmen der Vorlesung “System Engineering und Management”<\/strong> bestand die Kernaufgabe darin, ein Projekt zu konzipieren und umzusetzen, das moderne Web- und Cloud-Technologien nutzt. Zu Beginn der Projektphase lag mein Fokus auf einer klassischen Wetter-App. Das Ziel war es, den grundlegenden Umgang mit Serverarchitekturen, REST-APIs und Daten-Parsing zu verstehen. Doch w\u00e4hrend der ersten Prototypen wurde mir klar, dass ich diese Gelegenheit nutzen wollte, um tiefer in ein Feld einzutauchen, das meine wahre Leidenschaft und mein Karriereziel darstellt: die Spieleentwicklung<\/strong>.<\/p>\n\n\n\n

Besonders die Architektur von Multiplayerspielen hat mich schon immer fasziniert. Die Herausforderung, hunderte von Datenpaketen pro Sekunde konsistent \u00fcber ein Netzwerk zu verteilen, ist eine der komplexesten Aufgaben im System Engineering. So entstand die Idee, eine vereinfachte Version eines \u201eArena Fighters\u201c (\u00e4hnlich wie Super Smash Bros.<\/em>) zu entwickeln.<\/p>\n\n\n\n

Bei der Umsetzung von “ArenaGame”<\/strong> lag die Priorit\u00e4t nicht auf einem massiven Umfang an Inhalten. Stattdessen konzentrierte ich mich auf die pr\u00e4zise Synchronisation fundamentaler Mechaniken: Laufen, Schlagen und Dashen. Diese Aktionen m\u00fcssen \u00fcber das Netzwerk so abgeglichen werden, dass sich das Spiel f\u00fcr alle Kontrahenten fair und fl\u00fcssig anf\u00fchlt. Da ich zuvor fast ausschlie\u00dflich an lokalen Anwendungen gearbeitet hatte und Netzwerk-Kommunikation f\u00fcr mich Neuland war, war mein prim\u00e4res Ziel die Implementierung einer soliden, entkoppelten und skalierbaren Serverarchitektur<\/strong>.<\/p>\n\n\n\n

In den folgenden Kapiteln stelle ich die einzelnen Komponenten des Projekts im Detail vor. Ich erl\u00e4utere die gew\u00e4hlten technischen Ans\u00e4tze und beschreibe, wie ich die Architektur aufgebaut habe, um die Anforderungen an eine stabile Spielsession zu erf\u00fcllen.<\/p>\n\n\n\n

Spielprinzip<\/h2>\n\n\n\n

Zu Beginn werden alle teilnehmenden Spieler zuf\u00e4llig in der Arena positioniert. Ab diesem Moment k\u00f6nnen sich die Spieler frei bewegen und andere Spieler angreifen. Zus\u00e4tzlich steht ihnen eine Dash-Mechanik zur Verf\u00fcgung, mit der sie Angriffen ausweichen oder vor Gegnern fl\u00fcchten k\u00f6nnen.<\/p>\n\n\n\n

Ziel des Spiels ist es, alle gegnerischen Spieler gegen die W\u00e4nde der Arena zu schlagen. Um zu verhindern, dass sich alle Spieler dauerhaft in der Mitte der Arena aufhalten und sich durch Treffer nur minimal bewegen, habe ich eine Knockback-Mechanik integriert, die f\u00fcr mehr Dynamik im Spielverlauf sorgt.<\/p>\n\n\n\n

Diese Mechanik funktioniert so, dass ein Spieler bei jedem Treffer einen bestimmten Prozentsatz an Knockback aufbaut. Je h\u00f6her dieser Prozentsatz ist, desto st\u00e4rker f\u00e4llt der R\u00fccksto\u00df aus, der bei einem weiteren Treffer ausgel\u00f6st wird. Dadurch wird nicht nur das Spielgeschehen beschleunigt, sondern auch verhindert, dass eine Runde zu lange dauert oder im Extremfall gar kein Ende findet.<\/p>\n\n\n\n

Jeder erfolgreiche Treffer erh\u00f6ht den Knockback-Wert um 20 %, welcher f\u00fcr alle Spieler sichtbar \u00fcber dem jeweiligen Charakter angezeigt wird. Der maximal erreichbare Wert liegt bei 110 %. Diese Grenze wurde bewusst gew\u00e4hlt, da das Spiel den Namen \u201e110 %\u201c tragen sollte. Erreicht ein Spieler diesen Wert, wird bei einem Treffer ein extrem starker R\u00fccksto\u00df ausgel\u00f6st, wodurch es deutlich schwieriger wird, sich innerhalb der Arena zu halten.<\/p>\n\n\n\n

Sobald alle Spieler bis auf einen die Arena-Wand oder -Grenze ber\u00fchrt haben und dadurch ausgeschieden sind, gewinnt der verbleibende Spieler. Der Gewinner wird anschlie\u00dfend auf dem Bildschirm angezeigt, bevor alle Spieler wieder ins Hauptmen\u00fc zur\u00fcckgef\u00fchrt werden.<\/p>\n\n\n\n

Architektur<\/h2>\n\n\n\n

Wie ich bereits zu Beginn erw\u00e4hnt habe, war es mein Ziel, eine Serverarchitektur zu entwickeln, die verschiedene Aufgaben klar voneinander trennt. Aus diesem Grund habe ich eine mikroservice\u00e4hnliche Struktur umgesetzt, bei der einzelne Komponenten jeweils spezifische Aufgaben \u00fcbernehmen:<\/p>\n\n\n\n