Spielmechaniken

Das System hinter den Spielmechaniken im Social Media Simulator steuert die gesamte Spiellogik, die Berechnungen der Kennzahlen und die Abwicklung von Events. Die Mechaniken sind serverseitig in Spring Boot implementiert und laufen komplett unabhängig vom darstellenden PHP-Frontend.

Core-Loop & Zeitsteuerung

Die Spielmechanik basiert auf einem zustandslosen, pull-basierten Modell. Es gibt keinen permanenten Hintergrund-Thread, der die Server-Ressourcen blockiert, sondern die Updates werden über die Client-Anfragen getriggert.

Das 10-Hz-Intervall: Da das Frontend die Daten über updateHUD() 10 Mal in der Sek (100ms) neu abfragt, nutzt das Backend diese Requests, um die zeitabhängigen Variablen (z. B. passives Einkommen durch Werbeeinnahmen oder Mitarbeiter-Kosten) zu berechnen und zu inkrementieren.
Echtzeit-Berechnung: Bei jedem Aufruf der REST-Schnittstelle wird die Zeitdifferenz zum letzten Request ermittelt und die Werte wie Guthaben (money) oder Forschungspunkte (researchPoints) entsprechend hochgerechnet.

Kern-Komponenten der Mechanik

1. Wirtschaftssystem (Finanzen)

Das Wirtschaftssystem berechnet den Cashflow des Spielers.

Einnahmen: Generieren sich passiv basierend auf der Reichweite der Plattform und aktiv durch Interaktionen.
Ausgaben: Die laufenden Kosten berechnen sich direkt aus der Anzahl der eingestellten Mitarbeiter (employees).
Sandbox-Modus: Ist in der Konfiguration die Flag infinite_money aktiv, werden finanzielle Abzüge bei Einkäufen im Shop ausgesetzt.

2. Upgrade-Logik (Shop-Schnittstelle)

Der Shop schaltet neue spielerische Möglichkeiten frei und skaliert die Produktionswerte. Ein Kauf läuft nach folgendem mechanischen Muster ab:

Der Client sendet den Item-Namen per POST an /api/shop/buy.
Das Backend schaut in der registrierten Upgrade-Liste nach dem Basispreis.
Es wird geprüft, ob money >= price erfüllt ist.
Bei Erfolg wird der Preis abgezogen und der jeweilige Effekt (z. B. Erhöhung der Forschungsrate oder Freischaltung neuer Event-Typen) auf das Spielobjekt angewendet.

3. Ereignis-Trigger (RPG-Events)

Zufallsereignisse brechen das lineare Wachstum auf und fordern strategische Entscheidungen.

Trigger-Chance: Bei den regelmäßigen API-Abfragen besteht eine prozentuale Wahrscheinlichkeit, dass ein unvorhergesehenes Ereignis generiert wird.
Zustands-Sperre: Sobald ein Event aktiv ist, wird im JSON ein Event-Objekt mitgeliefert. Das Frontend pausiert optisch und erzwingt das HTML5-Dialogfeld.
Konsequenzen-Verarbeitung: Die Antwort des Spielers wird an /api/game/event-choice?choice=... gesendet. Das Backend wertet den String aus und modifiziert die Server-Variablen (z. B. Abbuchen von 50 Euro bei Gehaltserhöhungen oder Verringern des Mitarbeiter-Zählers bei einer Kündigung).

Erweiterbarkeit (Extensions)

Die Spielmechaniken sind so aufgebaut, dass sie über ein Modul-System erweitert werden können. Wie im Frontend-Template ersichtlich, können Themes oder Mechanik-Erweiterungen (z. B. cyberpunk oder matrix_theme) registriert werden.

Style- & Skript-Hooks: Über die ext.php der jeweiligen Extension werden zusätzliche Stylesheets und JavaScript-Dateien injiziert, die das Verhalten der Aktionen-Box manipulieren können.
HTML-Footer-Hooks: Ermöglichen es, eigene, unsichtbare Dialoge oder zusätzliche Event-Listener in den DOM einzubetten, um neue Gameplay-Elemente zu registrieren, ohne den Core-Code der Plattform zu verändern.

API-Referenz für Mechaniken

Endpunkt	Methode	Beschreibung	Auswirkung auf Spielmechanik
`/api/init`	GET	Initialisiert eine neue Session.	Generiert eine neue, eindeutige Game-UUID.
`/api/game`	GET	Ruft den aktuellen Zustand ab.	Berechnet den zeitlichen Fortschritt seit dem letzten Aufruf.
`/api/shop/buy`	POST	Führt einen Kauf aus.	Validiert Guthaben, zieht Kosten ab und aktiviert Upgrade-Effekte.
`/api/game/event-choice` (Coming Soon)	POST	Verarbeitet RPG-Entscheidungen.	Wendet die positiven/negativen Konsequenzen des Events an.