Warum Bestandsarchitektur wichtig ist
Das Inventarsystem ist das Rückgrat jedes FiveM-Roleplay-Servers. Jede Interaktion des Spielers mit Gegenständen, vom Aufheben einer Waffe bis zur Übergabe eines Schlüssels, fließt durch das Inventar. Ein schlecht gestaltetes Inventar führt zu Exploits zur Duplizierung von Gegenständen, Desynchronisierungsproblemen und frustrierten Spielern, die ihre Ausrüstung verlieren. Die robustesten Inventarsysteme folgen einem serverautoritativen Modell, bei dem der Client nur anzeigt, was der Server ihm mitteilt, und niemals darauf vertraut, dass der Client seinen eigenen Status meldet. Allein diese architektonische Entscheidung eliminiert die meisten Duplikat-Exploits, die Server mit vom Client vertrauenswürdigen Inventaren gefährden. Denke bei der Planung deines Inventars zuerst an den Datenfluss: Der Server besitzt die Wahrheit, der Client rendert sie und jede Mutation durchläuft ein validiertes Serverereignis.
Gewicht vs. Slot-basierte Systeme
Die Wahl zwischen gewichtsbasierten und platzbasierten Inventarsystemen prägt das Spielerlebnis grundlegend. In einem Slot-basierten System enthält jeder Slot einen Artikeltyp mit einer maximalen Stapelgröße, und die Gesamtzahl der Slots definiert die Tragfähigkeit. In einem gewichtsbasierten System hat jeder Gegenstand einen Gewichtswert und der Spieler hat ein maximales Tragegewicht. Viele moderne Frameworks kombinieren beide Ansätze, indem sie Steckplätze für die Organisation verwenden, die Gesamtkapazität jedoch nach Gewicht begrenzen. Hier ist ein Beispiel für eine kombinierte Gewichts- und Slot-Artikeldefinition:
Das Feld weight wird aus Präzisionsgründen in Gramm gespeichert und die stackSize steuert, wie viele dieser Artikel in einen einzelnen Slot passen. Wenn ein Spieler versucht, einen Gegenstand aufzunehmen, stelle sicher, dass ein Platz verfügbar ist und dass das Gesamtgewicht das Höchstgewicht nicht überschreitet. Diese doppelte Validierung verhindert, dass Spieler unrealistische Mengen an schweren Gegenständen mit sich führen, selbst wenn ihre Plätze leer sind.
Serverseitige Validierung und Anti-Exploit
Jede Inventaraktion muss auf dem Server validiert werden, bevor sie wirksam wird. Wenn ein Spieler einen Gegenstand von Slot 3 auf Slot 7 zieht, sendet der Client eine Verschiebungsanforderung und der Server überprüft, ob der Quellslot diesen Gegenstand tatsächlich enthält, der Zielslot ihn akzeptieren kann und die Mengen konsistent sind. Lasse den Kunden niemals die Anzahl der Artikel angeben oder Artikel aus dem Nichts erstellen. Hier ist ein sicherer serverseitiger Move-Handler:
Beachte, dass die DropPlayer-Aufrufe eindeutig unmögliche Vorgänge erfordern. Durch die Protokollierung dieser Ereignisse in einer separaten Prüftabelle kannst du Exploit-Versuche und -Muster erkennen. Erwäge auch die Einführung einer Ratenbegrenzung bei Inventarisierungsereignissen, da seriöse Spieler selten mehr als ein paar Inventarisierungsvorgänge pro Sekunde durchführen, während automatisierte Exploits oft schnell Hunderte von Anfragen senden.
Artikelmetadaten und einzigartige Artikel
Metadaten verwandeln einfache Elemente in reichhaltige, einzigartige Objekte. Eine Waffe kann ihre Seriennummer, Haltbarkeit und beigefügte Modifikationen tragen. Ein Telefon kann seine zugewiesene Nummer und Kontaktlistenreferenz speichern. Lebensmittel können einen Ablaufzeitstempel haben. Metadaten werden als JSON-serialisierte Lua-Tabelle in der Datenbank gespeichert und an jede Elementinstanz angehängt. Der Hauptunterschied besteht zwischen stapelbaren Elementen, die dieselben Metadaten verwenden, und eindeutigen Elementen, die jeweils eine eigene Metadatentabelle erhalten. So erstelle eine Waffe mit vollständigen Metadaten:
Wenn du Artikel mit Metadaten im NUI anzeigen, übergebe die Metadaten zusammen mit den Artikelinformationen, damit die Benutzeroberfläche Details wie Haltbarkeitsbalken, Seriennummern und Qualitätsbewertungen anzeigen kann. Dies gibt den Spielern eine tiefere Verbindung zu ihren Gegenständen und unterstützt fortgeschrittene Roleplay-Szenarien wie Waffenregistrierungssysteme oder forensische Untersuchungen, die eine Seriennummer bis zu ihrem Besitzer zurückverfolgen.
NUI-Leistung per Drag-and-Drop
Die Inventar-Benutzeroberfläche ist eines der leistungsempfindlichsten NUI-Elemente, da Spieler ständig damit interagieren. Vermeide es, bei jedem Update das gesamte Inventarraster neu zu rendern. Verwende stattdessen einen virtuellen DOM-Ansatz oder gezielte Elementaktualisierungen, die nur die geänderten Slots ändern. Wenn ein Spieler ein Element zieht, handhabe das Ziehen vollständig in JavaScript mithilfe von Mausereignissen, anstatt während des Ziehens Positionsaktualisierungen an den Lua-Client zu senden. Sende das endgültige Drop-Ergebnis nur als einzelnen NUI-Callback. Hier ist ein performantes Drag-Handler-Muster:
Verwende für die visuelle Darstellung das CSS-Raster für das Slot-Layout und vermeide umfangreiche CSS-Animationen auf Inventargegenständen, da Spieler möglicherweise Dutzende von Slots gleichzeitig sichtbar haben. Bildsprites für Elementsymbole werden schneller geladen als einzelne Bilddateien und reduzieren HTTP-Anfragen beim ersten Öffnen des NUI.
Lager- und Containersysteme
Über das persönliche Inventar hinaus benötigen Spieler Zugriff auf externen Speicher wie Fahrzeugkofferräume, Hausverstecke und gemeinsam genutzten Organisationsspeicher. Jeder Containertyp sollte seine eigenen Kapazitätsgrenzen und Zugriffskontrollregeln haben. In Fahrzeugkoffern wird das Fahrzeugschild als eindeutige Kennung verwendet, in Hausverstecken werden Eigentums-IDs verwendet und in Arbeitsverstecken wird der Jobname in Kombination mit einer Gehaltsüberprüfung verwendet. Speichere Containerbestände in einer dedizierten Datenbanktabelle getrennt von den Spielerbeständen, um Abfragen effizient zu halten:
Wenn ein Spieler einen Container öffnet, lade dessen Inhalt aus der Datenbank und sperrest du ihn, um den gleichzeitigen Zugriff mehrerer Spieler zu verhindern. Verwende eine serverseitige Sperrtabelle, die nachverfolgt, welche Stash-IDs derzeit von wem geöffnet sind. Löse die Sperre, wenn der Player den Container schließt oder die Verbindung trennt. Dies verhindert den klassischen Duplikat-Exploit, bei dem zwei Spieler denselben Kofferraum öffnen und beide dieselben Gegenstände entnehmen.
Inventarsynchronisierung und -persistenz
Um die Inventardaten zwischen dem Serverspeicher, der Datenbank und der Client-Anzeige synchron zu halten, ist eine sorgfältige Koordination erforderlich. Speichere den Spielerbestand regelmäßig in der Datenbank, nicht bei jeder einzelnen Artikeländerung, um die Schreiblast der Datenbank zu reduzieren. Ein Speicherintervall von 30 bis 60 Sekunden funktioniert für die meisten Server gut. Speichere außerdem immer beim Trennen des Players und beim Herunterfahren des Servers mithilfe des Ereignisses playerDropped und eines Shutdown-Handlers. Implementiere ein Dirty-Flag-System, das nur dann in die Datenbank schreibt, wenn sich der Bestand seit dem letzten Speichern tatsächlich geändert hat:
Auf der Client-Seite werden Batch-Updates für NUI durchgeführt, sodass mehrere schnelle Bestandsänderungen, wie z. B. der Erhalt mehrerer Artikel aus einem Herstellungsvorgang, zu einer einzigen Aktualisierung der Benutzeroberfläche und nicht zu einer pro Artikel führen. Dadurch wird der Flackereffekt eliminiert, den Spieler sehen, wenn Gegenstände einzeln in ihrem Inventargitter erscheinen.
Leistungsüberwachung und -optimierung
Überwache die Leistung deines Inventarsystems, indem du wichtige Kennzahlen verfolgen: durchschnittliche Datenbankspeicherzeit, Ereignisverarbeitungsrate und NUI-Rendering-Frequenz. Verwende den FiveM-Profiler, um Engpässe in deinen Bestandsrückrufen zu identifizieren. Zu den häufigsten Leistungsfallen gehört das Durchlaufen aller Spielerinventare in jedem Frame für nähebasierte Funktionen wie das Aufsammeln von Bodengegenständen, die unnötige Serialisierung großer Metadatenobjekte und das Aktivlassen von NUI-Frames, wenn das Inventar geschlossen wird. Verwende für Bodengegenstände ein räumliches Rastersystem, das nur Gegenstände innerhalb der Spielerzelle überprüft, anstatt jeden fallengelassenen Gegenstand auf dem Server zu scannen. Zwischenspeichern von Elementdefinitionen in einer nach Elementnamen indizierten Nachschlagetabelle, sodass das Abrufen von Elementeigenschaften eine O(1)-Hash-Suche und kein O(n)-Array-Scan ist. Erwäge schließlich die Implementierung einer Inventar-Paginierung für Container mit sehr großen Kapazitäten, indem du nur die sichtbaren Slots laden und beim Scrollen des Players zusätzliche Zeilen abrufen, wodurch sowohl Datenbankabfragen als auch das NUI-Rendering selbst bei Lagern mit Hunderten von Slots schlank bleiben.