Ruhrpott.Life Framework – Entwicklungsstand
Stand: 25. September 2026
Ruhrpott.Life befindet sich weiterhin aktiv in Entwicklung.
Diese Übersicht zeigt den aktuellen Entwicklungsstand des Frameworks, bereits fest eingeplante Systeme, noch offene Konzepte und zukünftig angenommene Vorschläge aus der Community.
Dabei gilt:
„Geplant“ bedeutet nicht „bereits in Entwicklung“.
Ein geplantes System ist Bestandteil unseres Zielkonzepts, wurde aber technisch noch nicht oder noch nicht vollständig begonnen.
---
Status-Legende
🟢 **FERTIG
Implementiert, getestet und aktuell als abgeschlossen betrachtet.
🟡 **WIP / TEST
Bereits implementiert oder aktiv in Entwicklung, befindet sich aber noch im Test bzw. benötigt weitere Arbeit.
🔴 **GEPLANT / NOCH NICHT BEGONNEN
Fest für Ruhrpott.Life eingeplant, Entwicklung noch nicht oder noch nicht vollständig begonnen.
⚪ **CONCEPT
Idee oder System wurde angesprochen, ist aber noch nicht vollständig ausgearbeitet bzw. endgültig beschlossen.
🔵 **COMMUNITY-VORSCHLAG ANGENOMMEN
Vorschlag stammt aus der Community und wurde offiziell für Ruhrpott.Life angenommen.
---
🟢 FERTIG
Das eigentliche Game-Framework befindet sich weiterhin in einer frühen Entwicklungsphase.
Core-Systeme werden deshalb bewusst nicht vorschnell als fertig markiert.
Ein System wird erst auf 🟢 gesetzt, wenn es:
implementiert,
multiplayerfähig,
serverseitig abgesichert,
persistent,
ausreichend getestet
und mit den davon abhängigen Systemen verbunden ist.
---
🟡 WIP / TEST
Framework Core
🟡 Zentrale Framework-Grundstruktur
🟡 Serverseitige Autorität
🟡 Server-/Client-Kommunikation
🟡 Persistente Datenhaltung
🟡 MySQL-/MariaDB-Anbindung
🟡 Stabile interne IDs
🟡 Charakterbezogene Daten
🟡 Serverseitige Zustandsänderungen
🟡 Grundlegendes Event-System
🟡 Vorbereitung systemübergreifender Schnittstellen
---
Account / Bürger / Zugriff
🟡 Account-Grundsystem
🟡 Bürger-/Whitelist-Anbindung
🟡 `GAME_ACCESS`-Prüfung
🟡 Forum-/Launcher-/Game-Verknüpfung
🟡 Steam-Verknüpfung
🟡 Charakterzugriff
🟡 Rollen- und Berechtigungsgrundlage
🟡 Trennung zwischen Account und Charakter
---
Charakter-Core
🟡 Charakter-Grundsystem
🟡 Multi-Character-Grundlage
🟡 Charakterbezogene Persistence
🟡 Identity-Grundlage
🟡 LifeState-Grundlage
🟡 Lebens-/Bewusstseinszustände
🟡 Disconnect-/Schlafkörper-Grundlage
🟡 Charakterbezogene Rechte
🟡 Charakterbezogene Daten
🟡 Vorbereitung von Team-Charakteren
---
Inventar
🟡 Eigenes Ruhrpott.Life-Inventarsystem
🟡 Halbseitige Inventaroberfläche
🟡 Kleidungs- und Ausrüstungsslots
🟡 Drag & Drop
🟡 Direkte Itemübergabe
🟡 Serverseitige Prüfung von Inventaraktionen
🟡 Charaktergebundene Gegenstände
🟡 Integration nativer Reforger-Inventarfunktionen
🟡 Neues Ruhrpott.Life-UI
🟡 Einzelne Kleidungsbereiche
🟡 Slot-Symbole
🟡 Weitere Stabilitätsarbeit
🟡 Fehlerbehebung bei Drag & Drop
🟡 Fehlerbehebung bei UI-Abstürzen
---
Geld / Banking-Grundlage
🟡 Geldsystem
🟡 Cent-genaue Geldbeträge
🟡 Bank-Grundsystem
🟡 Charakterkonten
🟡 Transaktionsgrundlage
🟡 Anti-Dupe-Prüfungen
🟡 Transaktionshistorie als technische Grundlage
🟡 Vorbereitung für weitere Banking-Funktionen
---
On-Duty / Rechte
🟡 Rollen- und Rechte-Core
🟡 On-Duty
🟡 Off-Duty
🟡 Vorbereitung Polizei
🟡 Vorbereitung Feuerwehr
🟡 Vorbereitung Rettungsdienst
🟡 Vorbereitung RAC
🟡 Vorbereitung Firmen
🟡 Trennung von Dienstrechten und normalen Charakterrechten
---
Launcher / Game-Zugang
🟡 Launcher-Grundsystem
🟡 Login
🟡 Bürgerprüfung
🟡 Steam-Prüfung
🟡 Charakterauswahl
🟡 Serververbindung
🟡 Forum → Launcher → Game
🟡 Fehler-/Diagnosegrundlage
🟡 Update-/Patcher-Grundlage
---
🔴 GEPLANT / NOCH NICHT BEGONNEN
Core / Sicherheit / Persistence
Auth- & Session-Core
🔴 Kurzlebige signierte Game-Session-Tickets
🔴 Serverseitige Ticketprüfung durch den Gameserver
🔴 Ablaufende Sessions
🔴 Prüfung von Bürgerstatus
🔴 Prüfung von Spielberechtigung
🔴 Prüfung des ausgewählten Charakters
🔴 Prüfung relevanter Entitlements
🔴 Kein direkter Datenbankzugriff durch Client oder Launcher
---
Fail-Closed-System
Bei kritischen Backendproblemen sollen relevante Systeme nicht einfach weiterarbeiten.
Geplant:
🔴 Fail-Closed bei DB-Ausfall
🔴 Schutz vor Geldverlust
🔴 Schutz vor Item-Duplizierung
🔴 Schutz vor fehlerhaften Fahrzeugtransaktionen
🔴 Schutz vor beschädigten Charakterdaten
🔴 Transaktionssicherheit
🔴 Recovery-Mechanismen
🔴 Wiederherstellung nach Serverneustart
---
Backup / Recovery / Staging
🔴 Automatisierte Datenbank-Backups
🔴 Wiederherstellungstests
🔴 Staging-System vor produktiven Updates
🔴 Fehlerdiagnose
🔴 Audit-Logs
🔴 API-Dokumentation
🔴 Webhooks für spätere Integrationen
---
Charakter / Identität
Charaktererstellung
🔴 Vollständiger Charaktereditor
🔴 Charaktername
🔴 Geburtsdatum
🔴 Persistentes Charakteralter
🔴 Geschlecht
🔴 Aussehen
🔴 Charakteridentität
🔴 Charakterbezogene Rechte
🔴 Charakterbezogene Jobs
🔴 Charakterbezogene Organisationen
🔴 Charakterbezogene Akten
🔴 Charakterbezogene Fahrzeuge
🔴 Charakterbezogenes Geld
🔴 Charakterbezogenes Wissen
---
Charakter-Lebenszyklus
🔴 Charaktererstellung
🔴 Charakteraktivierung
🔴 Hauptcharakter
🔴 Teamcharaktere
🔴 Charakterwechsel
🔴 Verstorbener Charakter
🔴 Vermisster Charakter
🔴 Ausgereister Charakter
🔴 Kontrollierter Löschprozess
🔴 Persistente Historie relevanter Charakterzustände
---
Dokumente / Ausweise / Lizenzen
RPL Document Core
🔴 Personalausweis
🔴 Führerschein
🔴 Fahrerlaubnisklassen
🔴 Waffenlizenzen
🔴 Berufliche Qualifikationen
🔴 Atteste
🔴 Bescheinigungen
🔴 Schuldscheine
🔴 Verträge
🔴 Dokumente erstellen
🔴 Dokumente unterschreiben
🔴 Dokumente vorzeigen
🔴 Dokumente kopieren
🔴 Ablaufdatum
🔴 Aussteller
🔴 Berechtigungsprüfung für Aussteller
🔴 Persistente Dokumente
---
Bürgeramt
🔴 Ausstellung von Personaldokumenten
🔴 Namensverwaltung
🔴 Charakterregistrierung
🔴 Dokumentenänderungen
🔴 Verlust-/Neuausstellung
🔴 Verbindung mit Behörden
---
Universelles Interaktionssystem
RPL Interaction Core
Statt für jedes Feature ein eigenes Aktionsmenü zu bauen, soll ein gemeinsames System verwendet werden.
🔴 Spielerinteraktionen
🔴 Fahrzeuginteraktionen
🔴 Objektinteraktionen
🔴 Weltinteraktionen
🔴 Kontextabhängige Aktionen
🔴 Rollenabhängige Aktionen
🔴 Dienstabhängige Aktionen
🔴 Ausbildungsabhängige Aktionen
🔴 Itemabhängige Aktionen
🔴 Zustandsabhängige Aktionen
🔴 Zeitbasierte Aktionen
🔴 Abbrechbare Aktionen
🔴 Serverseitige Validierung
Nutzung unter anderem durch:
🔴 Medical
🔴 Polizei
🔴 Dokumente
🔴 Inventar
🔴 Fahrzeuge
🔴 Firmen
🔴 Immobilien
🔴 Freizeitaktivitäten
---
Fahrzeug-Core
Fahrzeugidentität
🔴 Permanente `vehicle_id`
🔴 VIN / Fahrgestellnummer
🔴 Fahrzeugmodell
🔴 Fahrzeugvariante
🔴 Persistenter Halter
🔴 Halterhistorie
🔴 Zulassungsstatus
🔴 Fahrzeughistorie
---
Kennzeichen
🔴 Eigenständige Plate-ID
🔴 Kennzeichen getrennt von VIN
🔴 Frontkennzeichen
🔴 Heckkennzeichen
🔴 `FrontPlateSocket`
🔴 `RearPlateSocket`
🔴 Kennzeichen auch auf Custom-/Tuningteilen
🔴 Zulassung
🔴 Ummeldung
🔴 Stilllegung
🔴 Halterwechsel
---
Fahrzeugschlüssel
🔴 Schlüssel als physischer Gegenstand
🔴 Fahrzeugzuordnung
🔴 Ersatzschlüssel
🔴 Schlüsselübergabe
🔴 Schlüsselverlust
🔴 Schlüsselverwaltung
🔴 Firmen-/Organisationsschlüssel
---
Fahrzeugeigentum
🔴 Fahrzeugkauf
🔴 Fahrzeugverkauf
🔴 Fahrzeugübertragung
🔴 Garagen
🔴 Persistente Fahrzeugposition
🔴 Persistenter Fahrzeugzustand
---
Fahrzeuginventar
🔴 Kofferraum
🔴 Handschuhfach
🔴 Sitzabhängiger Zugriff
🔴 Fahrzeuglager
🔴 Gewichtsberechnung
🔴 Überladung
---
Kraftstoffe
🔴 Benzin
🔴 Diesel
🔴 Weitere Kraftstoffarten
🔴 Tankstellen
🔴 Kraftstoffverbrauch
🔴 Elektrofahrzeuge
🔴 Akkuladung
🔴 Ladesäulen
---
Tuning / Custom Parts
🔴 Felgen
🔴 Reifen
🔴 Spoiler
🔴 Dachaufbauten
🔴 Ski-Box
🔴 Anhängerkupplung
🔴 Weitere Customteile
🔴 Persistente Fahrzeugkonfiguration
---
Diebstahl / Sicherheit
🔴 Fahrzeugzugang überwinden
🔴 Fahrzeug starten
🔴 Alarmanlage
🔴 Fahrzeugortung
🔴 Diebstahlzustände
🔴 Polizei-/Beweisanbindung
Fahrzeugdiebstahl soll bewusst nicht aus einem einfachen „Lockpick benutzen → Auto gehört dir“ bestehen.
---
🆕 Parksensoren
🔴 `RPL_VehicleParkingAssist`
🔴 Frontsensoren
🔴 Hecksensoren
🔴 Abstandsabhängige Warntöne
🔴 Ausstattung abhängig vom Fahrzeug
🔴 Anhängererkennung
🔴 Abschaltung bzw. angepasste Hecklogik bei Anhängerbetrieb
🔴 Nutzung durch verschiedene Fahrzeugklassen
---
Trailer / Auflieger
RuhrpottTrailerCore
🔴 Physische Kopplung von Zugmaschine und Auflieger
🔴 Bremslicht
🔴 Blinker
🔴 Beleuchtung
🔴 Handbremse
🔴 Stützbeine
🔴 Kennzeichen
🔴 Eigentümer
🔴 Ladung
🔴 Gewicht
🔴 Persistentes Abstellen
🔴 Ab- und Ankuppeln
Vorgesehene Varianten:
🔴 Standardauflieger
🔴 Kühlauflieger
🔴 Tankauflieger
🔴 Tieflader
🔴 Containerchassis
---
BOS-Fahrzeuglautsprecher
RPL Vehicle PA
Für:
🔴 Polizei
🔴 Feuerwehr
🔴 Rettungsdienst
Funktionen:
🔴 Vorgefertigte Durchsagen
🔴 Live-PTT
🔴 Fahrzeugabhängige Lautsprecher
🔴 Sitzabhängige Bedienung
🔴 Dienstabhängige Berechtigung
🔴 Synchronisierte Audiowiedergabe
---
Blaulicht / Einsatzfahrzeuge
🔴 Eigener BOS-Fahrzeug-Core
🔴 Blaulichtmuster
🔴 Frontblitzer
🔴 Heckblitzer
🔴 Warnmodi
🔴 Sirenen
🔴 Synchronisierte Licht-/Soundzustände
🔴 Unterschiedliche Systeme für Polizei
🔴 Feuerwehr
🔴 Rettungsdienst
🔴 RAC
🔴 Bau-/Sicherungsfahrzeuge
---
Medical
RPL Medical Core
🔴 Verletzungen nach Körperregion
🔴 Unterschiedliche Verletzungsarten
🔴 Blutverlust
🔴 Blutvolumen
🔴 Kreislauf
🔴 Atmung
🔴 Puls
🔴 Blutdruck
🔴 Sauerstoffsättigung
🔴 Bewusstsein
🔴 Herzrhythmus
🔴 Trauma
🔴 Medikamente
🔴 Infusionen
🔴 Defibrillation
🔴 Reanimation
🔴 Stabilisierung
🔴 Behandlung
🔴 Transport
🔴 Krankenhaus
---
Patientenmonitor
🔴 Körperübersicht
🔴 Vitalwerte
🔴 Untersuchung
🔴 Behandlung
🔴 Verlauf
🔴 Aktionen
🔴 Patientenakte
🔴 Gemeinsames Untersuchungsprotokoll
Bereits erhobene Befunde sollen nicht bei jedem neuen Behandler verschwinden.
---
Medizinische Geräte
🔴 Patientenmonitor
🔴 EKG
🔴 Defibrillator
🔴 Corpuls-/Lifepak-inspirierte Geräte
🔴 Sauerstoff
🔴 Weitere medizinische Ausrüstung
---
Polizei / Behörden
🔴 Personen kontrollieren
🔴 Identität feststellen
🔴 Dokumente prüfen
🔴 Fahrzeuge prüfen
🔴 Fahrzeughalter abfragen
🔴 Kennzeichenabfragen
🔴 Durchsuchungen
🔴 Fesseln
🔴 Escort
🔴 Festhalten
🔴 Beschlagnahmung
🔴 Verwahrung
🔴 Akten
🔴 Fahndungen
🔴 Einsatzinformationen
---
Beweis- / Knowledge-System
Handlungen sollen nicht nur optisch stattfinden.
Beispiel:
Ein Spieler benutzt während der Fahrt sein Smartphone.
Der Charakter erhält dabei einen echten Zustand wie:
`phone_in_hand`
Dieser kann später ausgewertet werden durch:
🔴 Polizei
🔴 Zeugen
🔴 Beweissystem
🔴 Beobachtung
🔴 Kamerasysteme
🔴 andere Frameworksysteme
Weitere geplante Zustände:
🔴 sichtbare Verletzungen
🔴 sichtbare Gegenstände
🔴 sichtbare Waffen
🔴 Fesseln
🔴 medizinische Zustände
🔴 Interaktionszustände
---
Dispatch / Leitstelle
Dispatch Core
Für:
🔴 Polizei
🔴 Feuerwehr
🔴 Rettungsdienst
🔴 RAC
Funktionen:
🔴 Einsätze
🔴 Einsatznummern
🔴 Einsatzorte
🔴 Mehrere Einsatzmittel
🔴 Einheitstatus
🔴 On-Duty-Anbindung
🔴 GPS-Anbindung
🔴 Einsatzhistorie
🔴 Einsatzprotokolle
🔴 Automatische Systemmeldungen
---
🆕 BIE / Support Summon
RPL SupportSummonCore
Internes System für:
🔴 BIE
🔴 Moderation
🔴 Development / Support
Funktionen:
🔴 Spieler in einen Supportzustand übernehmen
🔴 Schutz während des Supports
🔴 Freeze
🔴 Ursprüngliche Position speichern
🔴 Rückkehr an Ursprungsposition
🔴 Supportgrund
🔴 Bearbeiter
🔴 Zeitstempel
🔴 Vollständige Logs
---
Firmen / Employment
RPL Employment Core
🔴 Firmen
🔴 Arbeitgeber
🔴 Mitarbeiter
🔴 Arbeitsverträge
🔴 Firmenrollen
🔴 Berechtigungen
🔴 Arbeitszeiten
🔴 On-Duty-Anbindung
🔴 Gehalt
🔴 Firmenkonten
🔴 Firmenfahrzeuge
🔴 Firmenlager
---
Qualifikationen / Ausbildung
Qualifikation und tatsächlicher Arbeitsplatz sollen getrennte Systeme sein.
Geplant:
🔴 Führerscheine
🔴 Erste-Hilfe-Ausbildung
🔴 Berufsausbildungen
🔴 Meisterqualifikationen
🔴 Studium / Universität
🔴 Berufsspezifische Schulungen
🔴 QTE-/Prüfungssysteme
---
Banking 2.0
RPL Banking Core
Der ursprünglich einfache Bank-Core wird deutlich erweitert.
Geplant:
🔴 Girokonten
🔴 Gemeinschaftskonten / Shared Accounts
🔴 Firmenkonten
🔴 Organisationskonten
🔴 Sparkonten
🔴 Überweisungen
🔴 Dauerhafte Transaktionshistorie
🔴 Berechtigungen
🔴 Rechnungen
🔴 Zahlung von Rechnungen
🔴 Bankkarten
🔴 Kartenberechtigungen
🔴 Kredite
🔴 Kreditraten
🔴 Transaktionales Ledger
🔴 Anti-Dupe
🔴 Serverseitige Geldbewegungen
---
Organisationen
RPL Organisation Core
Für:
🔴 Unternehmen
🔴 Vereine
🔴 Behörden
🔴 Gangs
🔴 Kartelle
🔴 weitere Gruppierungen
Funktionen:
🔴 Mitgliedschaften
🔴 Ränge
🔴 Rechte
🔴 Organisationskonten
🔴 Abgaben
🔴 Fahrzeuge
🔴 Immobilien
🔴 Lager
🔴 Marker
🔴 Organisationshistorie
---
Immobilien / Adressen
Address / Property Core
🔴 Gebäude-ID
🔴 Wohnungs-ID
🔴 Hausadressen
🔴 Besitzer
🔴 Bewohner
🔴 Mietverhältnisse
🔴 Firmenadressen
🔴 Briefkästen
🔴 Behördenadressen
---
Möbel / Wohnungseinrichtung
🔴 Möbelgeschäfte
🔴 Möbel kaufen
🔴 Möbel transportieren
🔴 Möbel platzieren
🔴 Möbel drehen
🔴 Persistente Einrichtung
🔴 Sofa benutzen
🔴 Stuhl benutzen
🔴 Bett benutzen
🔴 Weitere interaktive Einrichtungsgegenstände
---
PottPhone
Smartphone Core
🔴 Smartphones
🔴 SIM-Karten
🔴 Rufnummern
🔴 Telefonate
🔴 SMS
🔴 Kontakte
🔴 Lautsprecher
🔴 Benachrichtigungen
🔴 Gerätezustände
---
Mobilfunknetz
🔴 Funkmasten
🔴 Netzabdeckung
🔴 Funklöcher
🔴 Netzqualität
🔴 Standortabhängige Verbindung
---
Apps
🔴 Bank
🔴 Potter
🔴 PottMarkt / Pottanzeigen
🔴 Navigation
🔴 Taxi / Ride
🔴 Nachrichten
🔴 Behörden-/Firmenfunktionen
---
GPS / Navigation
RPL Navigation Core
🔴 Smartphone-Navigation
🔴 Fahrzeugnavigation
🔴 Routen
🔴 Wegpunkte
🔴 Einsatznavigation
🔴 Organisationsnavigation
---
🆕 Markerfinder
Gerade aufgrund der Größe der Ruhrpott.Life-Welt soll die Karte nicht einfach mit hunderten permanent sichtbaren Symbolen zugemüllt werden.
Geplant:
🔴 Suche nach Ortsnamen
🔴 Suche nach Stadtteilen
🔴 Suche nach Kategorien
🔴 Suche nach Geschäften
🔴 Suche nach Behörden
🔴 Suche nach öffentlichen Einrichtungen
🔴 Übergabe an GPS
🔴 Charakterfavoriten
🔴 Private Standorte
🔴 Berechtigungsprüfung für Organisationsstandorte
---
🆕 Taxi / Ride-Hailing
RPL RideServiceCore
Grundsatz:
Spielerfahrer zuerst – KI als Fallback.
Geplant:
🔴 Fahrt über App bestellen
🔴 Abholposition
🔴 Ziel
🔴 ETA
🔴 Fahrpreis
🔴 Auftragsstatus
🔴 Spieler-Taxifahrer
🔴 Fahrerannahme
🔴 GPS-Übergabe
🔴 Bezahlung
🔴 KI-Fallback bei fehlenden Spielern
🔴 Verbindung mit Firmen
🔴 Verbindung mit PottPhone
---
KI-ÖPNV
Geplant:
🔴 Busse
🔴 Straßenbahnen
🔴 S-Bahn
🔴 Haltestellen
🔴 Linien
🔴 Fahrpläne
🔴 Echtzeitinformationen
🔴 Verspätungen
🔴 Wetteranbindung
🔴 PottPhone-Routenplanung
🔴 Umstiege
---
Postsystem
🔴 Hausbriefkästen
🔴 Wohnungszuordnung
🔴 Firmenbriefkästen
🔴 Straßensammelkästen
🔴 Briefe
🔴 Pakete
🔴 Spielerzusteller
🔴 Postunternehmen
🔴 48-Stunden-Failsafe
---
Verkehrssteuerung / Ampeln
Traffic Intersection Core
🔴 Kreuzungen
🔴 Ampelgruppen
🔴 Synchronisierte Phasen
🔴 Fahrtrichtungen
🔴 Fußgängerphasen
🔴 Dynamische Steuerung
---
BOS-Ampelpriorisierung
Bei aktiver Sonder-/Wegerechtsfahrt:
🔴 Erkennung des Einsatzfahrzeugs
🔴 entsprechende Fahrtrichtung freigeben
🔴 konfliktierende Richtungen sperren
🔴 danach kontrolliert zum normalen Zyklus zurückkehren
---
Wetter
RPL Weather Core
🔴 Ruhrgebiet-Wetter als Orientierung
🔴 Europe/Berlin-Zeit
🔴 Synchronisation aller Spieler
🔴 Flüssige Wetterwechsel
🔴 Fallback bei externer Störung
🔴 Smartphone-Wetter
🔴 News-Anbindung
---
News
🔴 Wetter
🔴 Verkehr
🔴 Serverereignisse
🔴 Wirtschaft
🔴 Polizeimeldungen
🔴 Pushmeldungen
🔴 Redaktionelle Inhalte
---
Animation / Character State Framework
Animationen sollen nicht überall als voneinander getrennte Scripts umgesetzt werden.
Geplant:
🔴 Zentrales Animationsframework
🔴 Emote-System
🔴 Waffenhaltungen
🔴 Smartphone
🔴 Tablet
🔴 Notizblock
🔴 Rauchen
🔴 AFK-Animationen
🔴 Charakterzustände während Animationen
🔴 Favoriten über Numpad
---
Zwei-Spieler-Interaktionen
Mit Zustimmung des anderen Spielers:
🔴 Hand geben
🔴 Umarmen
🔴 Küssen
🔴 weitere gemeinsame Animationen
🔴 Schwitzkasten / kontrollierte Interaktionen
---
Dealer / illegales RP
Dealer Quest- & Trust-System
🔴 Dealer müssen über RP entdeckt werden
🔴 Keine sichtbaren Standardmarker
🔴 Questketten
🔴 Vertrauen
🔴 Angst
🔴 Beziehung zum Dealer
🔴 Händlerkonditionen
🔴 Wechselnde Dealer
🔴 Dealer-Wechsel ungefähr alle 120 Minuten
🔴 Informanten
🔴 Polizeiliche Ermittlungswege
Dealer sollen außerdem nicht unbegrenzt Waren aus dem Nichts erzeugen.
🔴 Händlerbestand abhängig von Spielerware
🔴 Lieferketten
🔴 Mangelzustände
🔴 Wirtschaftsanbindung
---
Substanz-System
🔴 Unterschiedliche Wirkungen
🔴 Sichtveränderungen
🔴 Kameraverhalten
🔴 Koordinationsveränderungen
🔴 Medizinische Auswirkungen
🔴 Wechselwirkungen
🔴 Medical-Anbindung
🔴 Polizeiliche Erkennungsmöglichkeiten
---
Elektro / Computer / Darknet
🔴 Elektrogeschäfte
🔴 Haushaltsgeräte
🔴 Laptops
🔴 Computer in Wohnungen
🔴 Pottanzeigen
🔴 RPbuy
🔴 Potter
🔴 E-Mail
🔴 Bankzugriff
Darknet
🔴 Zugang nicht automatisch verfügbar
🔴 USB-/Quest-Zugang
🔴 Drop-System
🔴 Pickup-System
🔴 Trennung von Bestellung und Übergabe
🔴 Illegale Wirtschaftsanbindung
---
Fishing
🔴 Angelplätze
🔴 Gewässertypen
🔴 Fischarten
🔴 Wetterabhängigkeit
🔴 Jahreszeiten
🔴 Inventaranbindung
🔴 Händler
🔴 Boote
🔴 Fischereischein
---
Wildtiere / Jagd / Forst
🔴 Wildtierbestände
🔴 Tierarten
🔴 Reviere
🔴 Jahreszeiten
🔴 Jagd
🔴 Forst
🔴 Wildunfälle
🔴 Polizei
🔴 Rettungsdienst
🔴 wirtschaftliche Verwertung
---
Talent / Gym
🔴 Training
🔴 Erfahrung
🔴 Stärke
🔴 Kondition
🔴 Tageslimits
🔴 Charakterentwicklung ohne klassischen RPG-Levelspam
---
RPL Presence Guard
Für die verpflichtende Community-/Voice-Präsenz vorgesehen.
🔴 Presence Provider
🔴 TS6-Anbindung
🔴 Launcher-Autoconnect
🔴 Anwesenheitschannel
🔴 Grace-Time
🔴 Serverseitige Presence-Prüfung
🔴 Sperre bei fehlender Anwesenheit
🔴 Hinweisoverlay
🔴 Support-Channel-Anbindung
Reforger-VoN bleibt dabei für IC-Kommunikation vorgesehen.
---
RPL Ladebildschirm
🔴 Eigene Ruhrpott.Life-Bilder
🔴 Wechselnde Hintergründe
🔴 Fakten
🔴 unnützes Wissen
🔴 Ruhrpott-Sprüche
🔴 Witze
🔴 Gameplay-Tipps
🔴 Lore-Hinweise
🔴 Modular erweiterbare Content-Pools
---
Welt / Map
Ruhrpott.Life Large World
Die Ruhrpott.Life-Welt wird nicht auf eine klassische 16×16-km-Karte zusammengestaucht.
Die aktuelle Zielwelt bleibt bei ungefähr:
66 × 66 km
Arma Reforger dient dabei weiterhin als Entwicklungs- und Prototypingplattform.
Langfristiges Ziel:
Arma 4
Geplant bzw. aktuell technisch relevant:
🔴 Large-World-Architektur
🔴 Koordinatensystem
🔴 Terrain-Streaming
🔴 Objekt-Streaming
🔴 Sichtbarkeit
🔴 Beleuchtung
🔴 Kamera
🔴 LOD-Systeme
🔴 Performancezonen
🔴 Multiplayer-Synchronisation
🔴 Vorbereitung auf spätere Arma-4-Migration
---
Interne Alpha
Der erste relevante Meilenstein ist nicht die Menge der Features, sondern ein vollständig funktionierender Kernablauf.
Ziel:
Forum → Bürgerfreigabe → Steam → Launcher → 2FA → Charakter → Gameserver → Essen Hbf → Bürgeramt → Ausweis → Geld → Inventar → Fahrzeug → Garage
Für die Alpha müssen unter anderem funktionieren:
🔴 Charakter erstellen
🔴 Charakter laden
🔴 Ausweis
🔴 Geld
🔴 Inventar
🔴 Itemtransfers
🔴 Fahrzeugkauf
🔴 stabile `vehicle_id`
🔴 Fahrzeughalter
🔴 Schlüssel
🔴 `last_position`
🔴 Teamchar-Spawn
🔴 Disconnect
🔴 Connection Lost
🔴 Serverrestart
🔴 DB-Ausfall
🔴 Persistence
Danach:
🔴 Mehrspieler-Stresstest
🔴 ungefähr 5–10 Tester
🔴 längere zusammenhängende Spielsitzung
🔴 Prüfung von Persistence und Synchronisation
---
⚪ CONCEPT
Die folgenden Systeme wurden angesprochen, benötigen aber noch eine vollständige technische bzw. spielerische Ausarbeitung.
---
KI-Straßenverkehr
⚪ Dynamischer Verkehr
⚪ Stoßzeiten
⚪ Berufsverkehr
⚪ Staus
⚪ Verkehrsdichte
⚪ Autobahnverkehr
⚪ KI-Unfälle
⚪ Ampelreaktionen
⚪ BOS-Reaktionen
⚪ Verkehrsumleitungen
⚪ Performancekonzept für die große Welt
---
Crime-Minispiele
🆕 Tresorknacken
Das System selbst ist für Crime-RP vorgesehen, die konkrete Balancing- und Inhaltsstruktur muss noch ausgearbeitet werden.
🔴 Verschiedene Tresortypen
🔴 Drehrad-/Schloss-Minispiel
🔴 Serverseitige Prüfung
🔴 Tatsächlicher Tresorinhalt
🔴 Beute
🔴 Alarm
🔴 Dispatch-Anbindung
🔴 Werkzeugzustand
🔴 Manipulationsschutz
---
Geldautomatenraub
⚪ Manipulation von Geldautomaten
⚪ gefälschte Karten
⚪ Hacking-Ablauf
⚪ Polizeialarm
⚪ Reparatur
⚪ Ausfallzustände
⚪ Beute
Die genaue RP- und Balance-Struktur ist noch offen.
---
Freizeit / Minigame-Core
Mögliche gemeinsame technische Grundlage:
`RPL_MinigameFramework`
Angesprochen:
⚪ Billard
⚪ Dart
⚪ Kicker
⚪ Tischtennis
⚪ Air Hockey
⚪ Bowling
⚪ Golf
Ziel wäre:
⚪ physische Spiele in der Welt
⚪ andere Spieler können zuschauen
⚪ synchronisierte Spielzustände
⚪ gemeinsame technische Basis
---
Charakter / Frisuren
⚪ Modulare Frisuren
⚪ Frisuren unabhängig vom Kopfmodell
⚪ Haar-Slots
⚪ Geschlechts-/Kopfkompatibilität
⚪ Vermeidung hunderter kompletter Kopfvarianten
---
Spezialfahrzeuge / Arbeitsgeräte
⚪ Fahrzeugkräne
⚪ Bergekräne
⚪ Abschleppkräne
⚪ Autokräne
⚪ Hydraulik
⚪ Stufenlose Steuerung
⚪ Bewegliche Arbeitsgeräte
⚪ Gemeinsamer Vehicle-Equipment-Core
---
Erweiterte Wetterfolgen
⚪ Glätte
⚪ Temperaturauswirkungen
⚪ Straßenbedingungen
⚪ regionale Wetterunterschiede
⚪ Wetterauswirkungen auf Fahrzeuge
⚪ Wetterauswirkungen auf Unfälle
---
Erweiterte Verkehrsfolgen
⚪ Baustellen
⚪ Sperrungen
⚪ Unfälle
⚪ dynamische Umleitungen
⚪ PottPhone-Warnungen
⚪ Navigationsanpassung
⚪ Verkehrsnachrichten
---
Loyalty / Treuesystem
⚪ Login-Serien
⚪ Langzeitaktivität
⚪ Treueboni
⚪ kosmetische Belohnungen
⚪ besondere Community-Belohnungen
Die konkrete Ausgestaltung ist noch offen.
---
🔵 ANGENOMMENE COMMUNITY-VORSCHLÄGE
Diese Kategorie ist bewusst separat.
Hier landen nur Features, bei denen eindeutig feststeht:
Die Idee kam aus der Community und wurde offiziell angenommen.
Ein Vorschlag erhält zunächst:
🔵 **COMMUNITY-VORSCHLAG ANGENOMMEN
Beginnt die Entwicklung:
🔵 → 🟡
Ist die Umsetzung abgeschlossen:
🟡 → 🟢
Die Herkunft des Features soll intern trotzdem erhalten bleiben.
Aktuell werden keine bereits vorhandenen Features nachträglich als Community-Vorschlag bezeichnet, wenn die ursprüngliche Herkunft nicht eindeutig dokumentiert ist.
---
Statuswechsel
Normales Feature
🔴 **GEPLANT
↓
🟡 **WIP / TEST
↓
🟢 **FERTIG
Konzept
⚪ **CONCEPT
↓
🔴 **GEPLANT
↓
🟡 **WIP / TEST
↓
🟢 **FERTIG
Community
🔵 **COMMUNITY-VORSCHLAG
↓
🟡 **WIP / TEST
↓
🟢 **FERTIG
---
Grundsatz für neue Systeme
Ruhrpott.Life soll nicht aus hunderten voneinander getrennten Scripts bestehen.
Neue Features sollen nach Möglichkeit vorhandene Core-Systeme benutzen.
Ein neues System sollte deshalb immer prüfen:
Gibt es bereits eine passende Charakter-ID?
Gibt es bereits einen Zustand dafür?
Kann das Interaction Framework genutzt werden?
Wird Persistence benötigt?
Muss das Inventar informiert werden?
Muss Medical den Zustand kennen?
Kann Polizei den Zustand auswerten?
Ist Dispatch relevant?
Hat das Fahrzeug-System damit zu tun?
Ist die Organisation/Firma relevant?
Muss PottPhone etwas davon wissen?
Muss das System auf der Karte bzw. im GPS erscheinen?
Benötigt es serverseitige Autorität?
Muss es nach einem Serverrestart weiterbestehen?
---
Entwicklungsziel
Das Ziel von Ruhrpott.Life ist nicht:
„Wir haben 500 Features.“
Das Ziel ist:
„Eine Handlung an einer Stelle der Welt kann glaubwürdige Auswirkungen auf andere Systeme haben.“
Ein Smartphone in der Hand kann von der Polizei gesehen werden.
Eine Verletzung bleibt für den nächsten Rettungsdienst nachvollziehbar.
Ein Fahrzeug besitzt eine Identität, einen Halter, eine Historie und ein Kennzeichen.
Eine Straßensperrung kann Navigation, Verkehr und Nachrichten beeinflussen.
Eine Firma besitzt Mitarbeiter, Fahrzeuge, Konten, Gebäude und Waren.
Ein Einsatz verbindet Dispatch, GPS, Polizei, Feuerwehr, Rettungsdienst, Fahrzeuge und Protokolle.
Und genau daraus soll das Roleplay entstehen.
Ruhrpott.Life – Systeme, die miteinander spielen.