FiveM Lua Script entwickeln: Client, Server, Events und Security richtig aufbauen

Eigene FiveM Lua Scripts sind schnell angefangen. Eine Resource mit fxmanifest.lua, einer Client-Datei und einer Server-Datei ist in wenigen Minuten erstellt. Schwieriger wird es, wenn daraus ein dauerhaft wartbares System werden soll.

Bei meinen FiveM-Projekten versuche ich deshalb, bereits beim Aufbau einer Resource klare Grenzen zwischen Client, Server und gemeinsamen Definitionen zu ziehen. Das wird besonders wichtig, wenn viele eigene Systeme miteinander kommunizieren.

Grundstruktur einer FiveM Resource

Eine kleine Resource kann beispielsweise aus fxmanifest.lua, client.lua, server.lua und optional gemeinsamen Dateien bestehen. Mit wachsendem Umfang teile ich Funktionen jedoch lieber nach Verantwortungsbereichen auf, statt mehrere tausend Zeilen in einer Datei zu sammeln.

Eine Einführung zum Resource-Aufbau findest du in FiveM Resource erstellen: Aufbau, fxmanifest, Client und Server richtig trennen.

Client und Server haben unterschiedliche Aufgaben

Der Client kümmert sich vor allem um Dinge, die unmittelbar mit dem Spieler und GTA zusammenhängen: Eingaben, UI, Animationen, lokale Entities und Darstellung. Der Server verwaltet dagegen vertrauenswürdige Zustände wie persistente Daten, Berechtigungen oder wirtschaftlich relevante Aktionen.

Netzwerk-Events bewusst einsetzen

Events sind ein zentraler Bestandteil von FiveM. Gleichzeitig können schlecht entworfene Events unnötige Netzwerklast verursachen oder Sicherheitsprobleme schaffen. Ich versuche deshalb, Events eindeutig zu benennen, Payloads klein zu halten und serverseitig zu validieren.

Bei einer Aktion sollte der Server nicht einfach glauben, dass der Client die Voraussetzungen erfüllt. Je nach System werden beispielsweise Position, Berechtigung, Besitz, Status oder Cooldowns serverseitig überprüft.

Keine sensiblen Entscheidungen ausschließlich im Client

Ein häufiger Architekturfehler besteht darin, wichtige Logik nur clientseitig umzusetzen. Alles, was Geld, Inventar, Rechte oder andere Spieler betrifft, sollte so aufgebaut sein, dass manipulierte Client-Aufrufe nicht automatisch zu einem gültigen Ergebnis führen.

Exports und APIs statt direkter Abhängigkeiten

Wenn mehrere Resources miteinander arbeiten, möchte ich möglichst klar definierte Schnittstellen. Statt fremde interne Datenstrukturen direkt vorauszusetzen, können Exports oder bewusst definierte Events eine stabile API zwischen Modulen bilden.

Dieser Ansatz ist auch ein zentraler Bestandteil meines Artikels FiveM eigenes Framework entwickeln: Architektur, Module und Schnittstellen.

Performance messen statt raten

Nicht jeder Loop ist automatisch schlecht und nicht jedes Event ein Performance-Problem. Problematisch werden unnötig häufig ausgeführte Berechnungen, große Payloads oder wiederholte Datenbankzugriffe ohne sinnvollen Grund.

Statt Optimierungen nach Gefühl einzubauen, sollte zunächst gemessen werden. Mehr dazu gibt es unter FiveM Performance: Ressourcen, Events und Datenbank sinnvoll optimieren.

Datenbankzugriffe bündeln

Persistente Daten gehören bei vielen RP-Systemen dazu. Trotzdem muss nicht jede kleine Aktion sofort mehrere Datenbankabfragen erzeugen. Je nach Datenart können Zustände im Speicher gehalten, gezielt synchronisiert oder gesammelt gespeichert werden. Wichtig ist dabei immer, Konsistenz und mögliche Serverabstürze mitzudenken.

Logging erleichtert die Fehlersuche

Bei größeren Systemen reicht ein einzelnes print() irgendwann nicht mehr aus. Sinnvolle Logs sollten erkennen lassen, welche Resource, welcher Spieler und welche Aktion beteiligt waren. Besonders bei administrativen oder wirtschaftlichen Aktionen kann das später enorm viel Zeit sparen.

Warum ich auf eigene Systeme setze

Für State-SA entwickle ich die zentralen Systeme selbst, statt die komplette Serverarchitektur auf ESX oder QBCore aufzubauen. Das bedeutet mehr Entwicklungsarbeit, ermöglicht aber klare eigene Schnittstellen und eine Architektur, die genau auf die benötigten Systeme zugeschnitten werden kann.

Die Hintergründe dazu beschreibe ich in FiveM Server ohne ESX oder QBCore: Warum ich auf eigene Systeme setze.

Fazit

Ein gutes FiveM Lua Script besteht für mich nicht nur darin, dass eine Funktion im Spiel funktioniert. Entscheidend sind klare Zuständigkeiten, serverseitige Validierung, kontrollierte Netzwerkkommunikation und eine Struktur, die auch nach Monaten noch verständlich bleibt. Gerade bei einem Server mit vielen Eigenentwicklungen zahlt sich diese Arbeit langfristig aus.