FiveM Frameworks erklärt: Kompletter Guide zu ESX, QBCore & QBOX
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,…

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 ESX vs QBCore vs QBOX: Vollständiger technischer Vergleich.
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 Wie man von ESX zu QBCore migriert.
Datenbank-Migrationen: Beim Wechsel von mysql-async zu oxmysql verbessert sich die Performance, aber die Syntax ändert sich. Siehe Migration von mysql-async zu oxmysql.
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 Eine balancierte GTA RP Wirtschaft designen 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.
ESX Scripts: Farming-Scripts, ältere Sicherheitssysteme, Legacy-Housing-Systeme. Die meisten sind stabil und kampferprobt, aber es fehlen moderne Features. Gut zum Lua-Lernen.
QBCore Scripts: 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.
QBOX Scripts: 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 FiveM Scripts: Kompletter Guide 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 /shop.
Frequently Asked Questions
Kann man das Framework mitten im Betrieb wechseln?
Technisch ja, praktisch ist es schmerzhaft. Du müsstest alle Spielerdaten exportieren (Geld, Items, Immobilien, Job-Historie), ins neue Schema umwandeln und das neue Framework parallel zum alten deployen. Die meisten Server brauchen dafür eine Woche Migration, wipen Charakterdaten oder akzeptieren Datenverlust bei Legacy-Systemen.
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, sodass du möglicherweise eigene Systeme entwickeln musst.
Welche Datenbank nutzt jedes Framework?
Alle drei unterstützen MySQL/MariaDB. ESX nutzt typischerweise mysql-async (Promise-basiert). 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.
