Realm System

[EinJOJO]

Technische Ansätze:

Realm Lifecycle

• UNLOADED (* Standardzustand bei allen Objekten)
• LOADING
• IDLE: Wenn kein Spieler drinne ist. Zeitpunkt des Eintritts merken!
• ACTIVE: Sobald mind. ein Spieler drinne ist.
• STALE: Nach 1 MInute Idle die Welt lokal entladen (bytes in Datei schreiben), dort verweilt sie für 5 Minuten. Der Host kann das Realm sehr schnell wieder laden.
• UNLOADING

Logging (Iteration 2? )

• Besucherhistorie
  • Realm ID
  • Wer? UUID
  • Zeitpunkt?
  • (session-id)
  • Hat einen Ladeprozess angestoßen?
• Ladehistorie
  • Historie ID
  • Realm ID
  • Welcher Host?
  • Wann?

Rate limiting: Schutz vor DOS-Angriffen

Sobald ein Spieler ein Realm lädt, wird er GELOCKT, Folglich kann er keine weiteren Lade / Erstell Operationen anregen.
Das Laden soll auf x / Minute limitiert werden.

Modelle / Abstraktionen / Objekte

Template

Realm

Spieler

Gradle Modul Struktur

api
core | Plattform unabhänge Kernlogik, soll ermöglichen über Velocity Realms zu laden oder Player Routing anzulegen.
paper

Funktionen und Features

1. Eigene Welten für Spieler

Automatische Erstellung: Jeder Spieler erhält bei dem erstem mal ausführen des Befehles /realm automatisch eine eigene Welt (Realm). - Kann auch durch das Raumschiff GUI passieren.
Performante Verwaltung: Realms werden wenn ein Spieler das Realm besucht geladen und entladen,

z. B. über einen separaten Storage-Server, um Ressourcen zu sparen.
Sollten Realms über 1 Monat lang nicht geladen werden, wird es archiviert.

Serverentlastung:
Bei einer hohen Anzahl aktiver Realms werden automatisch zusätzliche Server erstellt, um die Leistung zu sichern.

2. Besuch anderer Realms

Spieler können die Realms anderer Spieler erkunden.
Befehl: /planet visit <Name> – Besuche das Realm eines anderen Spielers.

=> Realm Visibility

Sichtbarkeit	Beschreibung
privat	Kein Spieler kann das Realm besuchen, ohne im Trustsystem hinterlegt zu sein (mind. Gast)
öffentlich	Jeder kann das Realm besuchen
(gelistet)*	Das Realm wird ähnlich zu der Discord Discovery Funktion hervorgehoben

*Das ist Teil einer zweiten Iteration, und muss weiter konkretisiert werden. Somit nicht in der 1. Iteration implementieren

3. Trust-System

Spieler können gezielt Rechte an andere Spieler vergeben:
Befehl: /planet <Name> – Gibt einem Spieler Berechtigungen in deinem Realm.

Bezeichnung	Beschreibung
Gast	Ist nur berechtigt, solange der Besitzer AUF dem Realm ist.
Hinzugefügt	Ist berechtigt, solange der Besitzer auf dem Netzwerk ist.
Vertrauter	Ist berechtigt auch wenn der Besitzer offline ist.

4. Vom Server Geschützte Bereiche

• Jedes Realm enthält vordefinierte Zonen (BoundingBox), die vor Blockabbau geschützt sind (z. B. der Spawn-Bereich).
• Spieler können in geschützten Bereichen interagieren, z. B. Truhen öffnen oder Schalter betätigen, jedoch nicht abbauen/bauen.

5. Erweiterungssystem

Begrenzte Anfangsgröße:

Spieler starten mit einem kleinen Bereich ihres Realms.

Freischaltung neuer Bereiche:

Spieler können Coins ausgeben, um schrittweise mehr Bereiche ihres Realms freizuschalten.
Das Realm hat immer einen Rechteckigen Bereich.
Eine Erweiterung findet stets in eine Richtung statt.

Befehl: /planet expand – Schaltet neue Teile des Realms frei.
Implementierung: Öffnet ein einfaches "click to upgrade"-GUI

Es folgt eine Idee für Iteration 3?

realms.upgrade.title
. . . . r . . . .
. . . . t . . . .
. . l . . . r . .
. . . . b . . . .
. . . c c c . . .

---
c: Confirm = Bestätigt das Upgrade |  2 State: { 
  1. Upgrade möglich
  2. Kein Upgrade möglich
}, material = Papier

---
r: Realm Info: skull, planet,
lore: { 
-- wird noch definiert 
}

6. NPC-Unterstützung (Extra Modul oder Drittplugin basierend auf der Realm API)

NPCs sind in allen Realms gleich und können z. B. Händler, Questgeber oder Dekoration sein welche z.b sprechen oder Befehle ausführen.
Standard-NPC: Olaf
Standort: Spawn-Bereich des Raumschiffs.
Funktionen: Verwalten von Trusts 6 Removes, Flags, Expands und Bans & Unbans.

#### 7. Archivierungsfunktion
Automatisches Archivieren: Realms, die über einen längeren Zeitraum - 1 Monat- inaktiv sind, werden komprimiert und in einen Archivstatus versetzt.
Spieler können archivierte Realms wiederherstellen, indem sie das Realm betreten .
(Archivierung bietet keine Performance-Vorteile.)

8. Mob-Spawning (EXTRA MODUL / PLUGIN)

Mobs können spawnen - Mythic Mobs API.
TECHNISCH: Erfordert "property system", wo sämtliche zusätzliche Informationen angefügt werden können.

9. Zentraler Zugriff

Befehl: /planet home – Teleportiert den Spieler zu seinem eigenen Realm.
Befehl: /planet visit – Ermöglicht das Erkunden anderer Realms.

10. Datenbank-Integration

Alle Spieler- und Realm-Daten werden in einer Datenbank gespeichert:
Daten: Weltstatus, freigeschaltete Bereiche, Trust-Listen, NPC-Positionen (property system).

Technische Details und Erweiterbarkeit

1. Performance-Optimierung
   Realms werden bei Inaktivität entladen und bei Bedarf wieder geladen.
   Separate Server-Speicher (Storage-Server) ermöglichen Mutli Server Konstruktionen
   An Lock Management ist zu denken (Zwei Server dürfen kein Realm teilen / doppelt laden)

STALE-ZUSTAND
Angenommen ein Spieler geht längere Zeit farmen, dann sollen Ressourcen freigemacht werden. Der Realm-Host besitzt aber weiterhin das Lock, und die Welt zählt weiterhin als limitierendes Element beim Laden von weiteren Realms. Hier soll nur die Spiel-Erfahrung der aktiven Realm-Spieler verbessert werden. Der Host muss trotzdem die Performance besitzen alle Realms von Stale im ACTIVE Zustand zu unterstützen.

2. Erweiterungen
   Integration mit anderen Plugins:
   MythicMobs: Anpassung von Mob-Spawning an spezifische Realms.
   WorldGuard: Schutzbereiche und Flags.
   PlaceholderAPI: Anzeige von Realm-spezifischen Daten im HUD oder Chat.
   NPC Plugin