FiveM Frameworks: ESX, QBCore & QBOX

Einführung: FiveM Frameworks verstehen

FiveM Frameworks bilden das Rückgrat von Roleplay-Servern. Sie sind nicht nur Code-Bibliotheken — sie sind komplette Systeme, die Spieleridentität, Jobs, Inventar, Berechtigungen, Datenbankinteraktion und Server-Wirtschaft verwalten. Ohne Framework müsstest du diese Systeme von Grund auf bauen. Mit einem erbst du Jahre an Community-Verfeinerung und Plugin-Ökosystemen.

Die drei dominierenden Frameworks heute sind ESX, QBCore und QBOX. Jedes repräsentiert eine andere Philosophie: ESX betont Einfachheit und modulbasierte Architektur, QBCore kombiniert Legacy mit modernen Mustern, und QBOX ist die neuere, Lua-first Neugestaltung auf Basis von ox_lib und oxmysql. Diese Unterschiede zu verstehen ist entscheidend, ob du einen neuen Server startest, einen bestehenden wartest oder eine Migration erwägst.

Dieser Guide geht in die Tiefe bei Architektur, Performance-Eigenschaften, Datenbankmustern und dem Ökosystem rund um jedes Framework.

Framework-Vergleich: ESX, QBCore und QBOX auf einen Blick

Jedes Framework macht unterschiedliche Kompromisse bei Geschwindigkeit, Einfachheit und Erweiterbarkeit.

ESX Architektur: Modulbasiert, event-gesteuert, ressourcenschonend. Der Core verarbeitet Spielerinitialisierung, Jobs und Basisinventar. Alles andere — Shops, Polizei, Medizin, Housing — ist eine separate Ressource. Das macht ESX hochgradig anpassbar, erfordert aber mehr Integrationsarbeit.

QBCore Architektur: Monolithisch mit geteilten Exports und Callbacks. Das Framework enthält Jobs, Housing, Inventar und viele Systeme out-of-the-box. Stärker opinionated als ESX, schnelleres initiales Setup. Der Kompromiss: Schwerer, Systeme zu entfernen, die du nicht willst, und Callbacks können enge Kopplung zwischen Scripts erzeugen.

QBOX Architektur: Modernes Lua-first Design mit ox_lib und oxmysql. Betont async/await-Muster statt Callbacks, sauberere Tabellenstrukturen und direkte Exports statt Dispatch-Systemen. Für Server, die eine saubere Code-Architektur ohne Legacy-Ballast wollen.

Für einen detaillierten technischen Vergleich siehe .

Deep Dive: QBOX und der ox_lib-Stack

QBOX repräsentiert die aktuelle Richtung moderner FiveM-Entwicklung. Es ist nicht nur ein Framework — es ist Teil eines Ökosystems, das ox_lib (moderne UI-Komponenten), oxmysql (Promise-basierte Datenbank) und ox_target (Interaktionssystem) umfasst. Zusammen schaffen sie ein kohärentes Entwicklungserlebnis.

Warum QBOX wichtig ist: QBOX entfernt die Callback-Hölle. Statt:

TriggerEvent('esx:getPlayerFromId', playerId, function(xPlayer) -- verschachtelte Callbacks hier end)

Schreibst du async/await-Logik:

local player = await GetPlayer(playerId)

Das verbessert die Code-Lesbarkeit dramatisch und reduziert Bugs durch Callback-Reihenfolge-Probleme. QBOX standardisiert auch Datenstrukturen: Spieler-Objekte, Item-Definitionen und Jobs folgen alle konsistenten Mustern.

ox_lib Integration: ox_lib bietet modernes UI (Benachrichtigungen, Dialoge, Eingabefelder), Vektormathematik-Utilities und Skelettanimations-Helfer. Kein Gefrickel mehr mit Benachrichtigungssystemen oder manuellen Distanzprüfungen — ox_lib erledigt das sauber.

Performance-Eigenschaften: QBOX hat geringeren Speicher-Overhead als ESX (kein Event-Dispatcher-Bloat) und sauberere Callback-Ketten als QBCore. Die meisten QBOX-Server berichten von 5–10 % niedrigerer CPU-Auslastung als QBCore-Äquivalente bei gleicher Script-Last.

Migrationspfade: Wann und wie das Framework wechseln

Migration ist einschüchternd, aber oft notwendig. Server wachsen aus Frameworks heraus, Performance wird kritisch oder die Community bewegt sich zu neuen Standards.

Wann migrieren:

Performance-Verschlechterung — Callback-Overhead oder Event-Spam verursacht Lag
Script-Ökosystem schrumpft — weniger Entwickler schreiben Ressourcen für dein Framework
Fundamentale Architektur-Limitation — Framework kann dein geplantes Feature-Set nicht unterstützen
Wartungsaufwand — Framework-Entwicklung ist stagniert oder zum Nachfolger gewechselt
Team-Expertise verschiebt sich — deine Entwickler kennen QBOX besser als ESX

Migrations-Komplexität: ESX zu QBCore: moderat. QBCore zu QBOX: hoch (erfordert Umschreiben auf async/await). ESX zu QBOX: sehr hoch (braucht sowohl Muster- als auch Architekturänderungen).

Migrationsstrategie: Beide Frameworks parallel betreiben mit Namespace-Trennung. Wrapper-Exports erstellen, die zwischen Frameworks übersetzen. Jobs, Housing und Core-Systeme zuerst migrieren (höchster Impact). Periphere Systeme zuletzt. Für Schritt-für-Schritt-Anleitungen siehe .

Datenbank-Migrationen: Beim Wechsel von mysql-async zu oxmysql verbessert sich die Performance, aber die Syntax ändert sich. Siehe .

Wirtschaft und Spieldesign: Wie Frameworks Geld handhaben

Frameworks verwalten nicht nur Charakterdaten — sie definieren das Wirtschaftsmodell. ESX nutzt ein vereinfachtes Job-/Gehaltssystem. QBCore erweitert das mit Job-Stufen und granularer Kontrolle. QBOX bietet noch mehr Flexibilität durch ox_lib-Integration und async-Muster, die komplexe Wirtschaftssysteme machbar machen.

Job-Wirtschaft: Die meisten Frameworks koppeln Einkommen an Jobs. ESX nutzt TriggerEvent für Gehaltsauszahlungen auf Timer. QBCore nutzt ähnliche Muster mit mehr Konfiguration. QBOX macht es einfach, komplexe Logik zu implementieren: Skill-basierte Boni, dynamische Preise basierend auf Serverbedingungen, sogar Live-Wirtschaftsanpassungen basierend auf Spieler-Angebot/Nachfrage.

Banksysteme: Alle drei Frameworks unterstützen Bankkonten (Geldlagerung getrennt von Bargeld). QBOX macht es einfach, Features wie Kontosperren, Zinsen oder dynamische Transaktionsgebühren zu implementieren.

BIP-Wachstum balancieren: Häufiger Fehler: Server generieren unendlich Geld durch Jobs, während Geldsenken (Geschäfte, Häuser, Fahrzeuge) begrenzt sind. Das erzeugt Hyperinflation. Moderne Frameworks ermöglichen automatische Senken: serverweite Events (Naturkatastrophen, die Geld zur Wiederherstellung kosten), steigende Preise oder NPC-Steuersysteme. Siehe für detaillierte Strategien.

Das richtige Framework wählen: Entscheidungsmatrix

Es gibt kein einzelnes bestes Framework. Deine Wahl hängt von Servergröße, Entwicklererfahrung, Script-Verfügbarkeit und Community-Support-Bedarf ab:

Kriterium	ESX	QBCore	QBOX
Server-Größe (Ziel)	Klein-Mittel (1–50 Spieler)	Mittel-Groß (50–200 Spieler)	Jede Größe (optimiert für Skalierung)
Team-Erfahrung	Mittleres Lua	Mittleres-Fortgeschrittenes Lua	Fortgeschrittenes Lua (async/await-Muster)
Script-Ökosystem	Am größten verfügbar (Legacy)	Umfangreich und aktuell	Wachsend, modernisierend
Setup-Zeit	2–3 Wochen (viel eigene Arbeit)	1–2 Wochen (mehr Features inklusive)	2–3 Wochen (weniger Fertig-Scripts)
Lernkurve	Moderat (event-gesteuert)	Moderat-Steil (Callbacks + Exports)	Steil (async/await, ox_lib erforderlich)
Performance	Gut mit Tuning	Gut (Callback-Overhead bei Skalierung)	Ausgezeichnet (async-first Design)

Entscheidungsregeln:

Erstes Framework? Starte mit QBCore. Größtes Ökosystem, meiste Tutorials, meiste Scripts verfügbar.
Fortgeschrittene Lua-Entwickler und moderne Architektur gewünscht? QBOX.
Nischen-Server mit einzigartigen Systemen? ESX (akzeptiere den eigenen Entwicklungsaufwand).
Performance als Top-Metrik? QBOX.
Schnelles Deployment am wichtigsten? QBCore (meiste Abkürzungen verfügbar).

Framework-spezifische Script-Ökosysteme

Jedes Framework hat einen anderen Marktplatz an Ressourcen.

: Farming-Scripts, ältere Sicherheitssysteme, Legacy-Housing-Systeme. Die meisten sind stabil und kampferprobt, aber es fehlen moderne Features. Gut zum Lua-Lernen.

: Alles. Restaurants, Immobilien, Fahrzeuganpassung, Justizsysteme, Gefängnis-Roleplay. Wenn ein Feature in FiveM RP existiert, hat jemand eine QBCore-Ressource dafür geschrieben. Die Qualität variiert stark.

: Aufstrebendes Ökosystem mit Fokus auf Code-Qualität. ox_lib-basiertes UI, saubere async-Muster, moderne Datenbankinteraktionen. Weniger Fertig-Optionen, aber was existiert, ist generell besser entwickelt. Siehe für detaillierte Script-Ökosysteme.

FAQ

Kann man das Framework mitten im Betrieb wechseln?

Technisch ja, praktisch ist es schmerzhaft. Du müsstest alle Spielerdaten exportieren, ins Schema des neuen Frameworks umwandeln und das neue Framework parallel deployen. Die meisten Server brauchen dafür eine Woche Migration, wipen Charakterdaten oder akzeptieren Datenverlust bei Legacy-Systemen. Plane die Framework-Wahl sorgfältig beim Launch.

Ist QBOX produktionsreif?

Ja. QBOX betreibt derzeit Hunderte aktive Server mit 50+ gleichzeitigen Spielern. Das Framework ist stabil, die ox_lib-Abhängigkeit solide und die oxmysql-Performance bewiesen. Allerdings ist das Script-Ökosystem kleiner als bei QBCore.

Welche Datenbank nutzt jedes Framework?

Alle drei unterstützen MySQL/MariaDB. ESX nutzt typischerweise mysql-async. QBCore nutzt mysql-async oder ghmattimysql. QBOX nutzt oxmysql (rein Promise-basiert, beste Performance). Die Datenbank selbst unterscheidet sich nicht — es sind die Client-Bibliothek und Query-Muster, die zählen.

Können ESX- und QBCore-Scripts zusammen auf einem Server laufen?

Nicht nativ. Sie nutzen unterschiedliche Exports, Events und Datenstrukturen. Du bräuchtest Wrapper-Code zum Übersetzen. Die meisten Server machen das nicht — es ist einfacher, bei einem Framework zu bleiben und Ressourcen bei Bedarf zu portieren.

Welches Framework hat den meisten Community-Support?

QBCore, mit Abstand. Größte Discord-Communities, meiste Tutorials, meiste Ressourcen. ESX hat Legacy-Support (viele alte Scripts, alte Dokumentation). QBOX hat wachsenden Support, aber weniger Gesamtressourcen.

Wie lange dauert eine vollständige Framework-Migration?

Für einen kleinen Server (20 Scripts, 1–2 Entwickler): 2–4 Wochen. Für einen mittleren Server (50+ Scripts, mehrere Systeme): 2–3 Monate mit Planung und Tests. Für große Server: 3–6 Monate, wenn du keine Daten wipest. Der größte Zeitfresser ist das Umschreiben eigener Systeme, nicht der Framework-Wechsel selbst.

Fazit: Deine Framework-Strategie aufbauen

Wähle dein Framework basierend auf drei Faktoren: Team-Expertise, Performance-Anforderungen und Ökosystem-Bedürfnisse. Für die meisten neuen Server bleibt QBCore der Standard, weil das Script-Ökosystem unübertroffen ist. Für performance-kritische oder technisch fortgeschrittene Teams ist QBOX die Zukunft. ESX eignet sich nur, wenn du volle Anpassungskontrolle willst und es dir nichts ausmacht, Systeme von Grund auf zu bauen.

Unabhängig von der Framework-Wahl bleiben die Grundlagen: saubere Architektur, Datenbankoptimierung und klare Trennung zwischen Core-Systemen und Gameplay-Scripts. Ein gut strukturierter ESX-Server übertrifft einen chaotischen QBCore-Server.

Bereit zum Start? Stöbere in unserem Marktplatz nach framework-kompatiblen Scripts, Job-Ressourcen und Wirtschaftssystemen unter .