Paper Animal Adventure
Cloud-Backend auf Basis von Azure und .NET für Backend-Services, Automatisierung und Deployment eines Indie-Games.
Azure Web Apps · Azure Functions · Azure MySQL · Azure Container Registry · Key Vault · GitHub Actions · Docker
Für Paper Animal Adventure lag mein Fokus nicht nur auf der Spieleentwicklung selbst, sondern auch auf dem Aufbau einer passenden Azure-/Cloud-Infrastruktur im Backend.
Dabei habe ich Backend-Services mit .NET konzipiert, containerisiert in Azure bereitgestellt und Deployment- sowie Automatisierungsprozesse mit modernen Cloud- und DevOps-Tools umgesetzt. Besonders spannend war für mich hier die Verbindung aus praktischer Softwareentwicklung, Infrastruktur und sauberem Betriebssetup.
🕹️ Features
Ranglistensystem
Spieler können eigene Punktzahlen in eine globale Rangliste hochladen und die Punktzahlen anderer Spieler abrufen.
Nutzergenerierte Inhalte
Spieler können eigene Inhalte erstellen oder Inhalte von anderen Spielern herunterladen. Diese Inhalte werden in einem XML Format in einem MySQL-Datenbank gespeichert.
Discord Integration
Spieler haben die Möglichkeit ihre Aktivität auf Discord zu teilen, ein Discord Bot postet automatisch bestimmte in-game Ereignisse auf dem Discord Server des Spiels.
Wöchentlicher Ranglistenreset
An jedem Sonntag werden die Ranglistendaten mithilfe einer Timerfunktion zurückgesetzt. Gleichzeitig wird hier ein neuer “Seed” generiert, der die Rahmenbedingungen für das neue Turnier festlegt.
CI/CD
Automatisiertes Deployment über GitHub Actions.
Containerisierte Bereitstellung
Die Backend-Services werden containerisiert über Azure Web Apps und Azure Container Registry bereitgestellt.
💡 Designentscheidungen
Azure Web Apps für containerisierte Backend-Services
Ich habe Azure Web Apps als Hosting-Grundlage für die Backend-Services gewählt, weil sich containerisierte .NET-Anwendungen damit vergleichsweise einfach und zuverlässig bereitstellen lassen. Für den Projektkontext war das eine passende Lösung, um moderne Cloud-Bereitstellung zu nutzen, ohne unnötige operative Komplexität einzuführen.
Azure Container Registry für den Deployment-Workflow
Die Container-Images werden zentral in Azure Container Registry verwaltet. Dadurch ließ sich ein klarer Deployment-Prozess aufbauen, bei dem GitHub Actions neue Images baut und die Services anschließend konsistent in Azure bereitgestellt werden können.
Azure Database for MySQL für persistente Spieldaten
Für Ranglisten, nutzergenerierte Inhalte und weitere persistente Backend-Daten habe ich eine relationale Datenbank auf Basis von Azure Database for MySQL verwendet. CosmosDB wäre auch eine Alternative gewesen, jedoch habe ich mich hier wegen Kostengründen für MySQL entschieden.
Azure Functions für zeitgesteuerte Prozesse
Wiederkehrende Abläufe wie der wöchentliche Ranglistenreset und die Generierung neuer Turnierparameter habe ich mit Azure Functions umgesetzt. Dadurch konnten diese Prozesse klar vom Haupt-Backend getrennt und unabhängig ausgeführt werden.
Managed Identity
Wo möglich, habe ich auf Managed Identities gesetzt, damit Azure-Ressourcen sicher miteinander kommunizieren können, ohne Zugangsdaten direkt in Konfigurationen oder Code hinterlegen zu müssen.
Key Vault
Sensible Werte, die nicht über Managed Identities abgedeckt werden konnten, habe ich zentral in Azure Key Vault verwaltet. Dazu gehört in diesem Fall unter anderem das Discord-API-Token, da externe Dienste wie Discord nicht nativ über Managed Identities angebunden werden können.
GitHub Actions für CI/CD
Für Build- und Deployment-Prozesse habe ich GitHub Actions eingesetzt, um Änderungen reproduzierbar und mit möglichst wenig manuellen Zwischenschritten in die Cloud zu bringen. So ließ sich der Bereitstellungsprozess sauber automatisieren.
Discord-Bot als separater Service
Die Discord-Integration habe ich als eigenen Service gedacht, um spielbezogene Ereignisse unabhängig vom Kern-Backend verarbeiten und veröffentlichen zu können. Diese Trennung sorgt für eine klarere Struktur und erleichtert spätere Erweiterungen.
📈 Weiterentwicklung
Deployment Slots
Aktuell wird der Discord-Service über GitHub Actions direkt im Produktionsslot bereitgestellt. Perspektivisch wäre ein separater Deployment-Slot sinnvoll, um Releases vor dem Wechsel in die Produktionsumgebung gezielter testen und absichern zu können.
Getrennte Umgebungen
Langfristig wäre eine klarere Trennung von Development-, Staging- und Production-Umgebungen sinnvoll. Das würde Deployments kontrollierter machen und Änderungen besser absichern.
Erweiterte CI/CD-Absicherung
Der bestehende Deployment-Workflow funktioniert, könnte aber um zusätzliche Validierungsschritte wie automatisierte Tests, Health Checks oder kontrollierte Freigaben erweitert werden.
Skalierung und Entkopplung
Mit wachsendem Funktionsumfang wäre es sinnvoll, einzelne Prozesse noch stärker voneinander zu entkoppeln und Services gezielter nach Verantwortlichkeiten zu trennen.