Wie man ein FiveM-Skript per Vibe-Coding entwickelt

Einführung: Die Zukunft der FiveM-Entwicklung

Willkommen in der Zukunft der FiveM-Entwicklung. Wenn du schon eine Weile Skripte schreibst, kennst du den Aufwand: Boilerplate-Code, sich wiederholende Config-Setups und die Suche nach Syntaxfehlern in der Dokumentation. Wenn du neu bist, kann die Lernkurve von Lua und Client-Server-Networking steil wirken.

Dieser Guide ist Teil unseres vollständigen FiveM-Content-Creation-Guides, der alles von MLO-Design über Scripting und Fahrzeug-Modding bis hin zum Aufbau deiner Creator-Marke abdeckt.

Gib Vibe-Coding eine Chance.

Es geht nicht nur darum, die KI für dich Code schreiben zu lassen – es geht darum, ein „technischer Direktor" zu werden, während ein KI-Assistent die Handarbeit übernimmt. In diesem Guide durchlaufen wir einen wiederholbaren Workflow, um eine FiveM-Ressource mit KI als Copilot zu bauen, zu härten und zu polieren – ohne Qualität oder Sicherheit zu opfern.

Für einen umfassenderen Blick auf KI-Tools in unserem Ökosystem, lies unseren Guide zu FiveM-Skripte mit KI schreiben.

Was ist „Vibe-Coding"?

Im Kontext dieses Tutorials ist Vibe-Coding die Kunst der schnellen Iteration mit einem KI-Assistenten (wie ChatGPT, Claude oder Cursor), bei der du einer strikten Schleife folgst:

1. Du definierst die Spec: Du sagst der KI genau, was passieren soll.
2. KI entwirft den Code: Die KI generiert den Boilerplate, die Logik und die Struktur.
3. Du prüfst & validierst: Du überprüfst die Diffs auf Sicherheitslücken (dem Client vertrauen?), Performance-Probleme (Busy-Loops?) und Logikfehler.
4. Du triffst Entscheidungen: Du schreibst nicht jede Zeile, aber du triffst jede architektonische Entscheidung.

Die Kernregel: Die KI ist der Junior-Entwickler; du bist der Senior-Lead. KI schreibt Entwürfe; du triffst Entscheidungen.

---

Das Demo-Skript: „Item Use + Progress + Validation"

Um diesen Workflow zu lernen, drucken wir nicht einfach „Hello World". Wir bauen ein reales Szenario, das das wichtigste Konzept in FiveM lehrt: Server-Autorität.

Das Skript: vibe-consumable

• Aktion: Spieler benutzt ein Item (z.B. ein „Reparatur-Kit" oder „Energy Drink").
• Client: Prüft, ob der Spieler beschäftigt ist, spielt eine Animation, zeigt einen Fortschrittsbalken.
• Server: Verifiziert, ob der Spieler das Item tatsächlich besitzt, entfernt es und gewährt eine Belohnung (Gesundheit/Rüstung/Status).
• Sicherheit: Wir werden uns speziell darauf konzentrieren, Exploiter daran zu hindern, die Belohnung ohne Verwendung des Items auszulösen.

Wenn du vor dem Einstieg eine Auffrischung der Grundlagen brauchst, lies unsere Einführung in Lua-Scripting.

---

Kapitel 0: Setup & Tooling

Bevor wir viben, brauchen wir ein Studio.

1. Code-Editor: VS Code ist Standard, aber Cursor (ein VS Code-Fork mit eingebautem KI) ist das ultimative Vibe-Coding-Tool. Es ermöglicht „Chat with codebase" und das sofortige Anwenden von Diffs.
2. Die Umgebung: Ein lokaler FXServer für schnelles Testing.
3. Die Denkweise: „Der Client ist nicht vertrauenswürdig." Das ist dein Mantra. Die KI wird das oft vergessen und dem Client blind vertrauen. Du musst es erkennen.

---

Kapitel 1: Die Spec definieren

Der größte Fehler, den Entwickler mit KI machen, ist vages Prompting. „Mach ein Skript, das Essen isst" gibt dir Schrott. „Mach ein ESX-Skript, bei dem die Verwendung von Brot einen 5s-Fortschrittsbalken über ox_lib auslöst, dann ein Server-Event auslöst, um Brot zu entfernen und Hunger hinzuzufügen" gibt dir Gold.

Unsere Spec für vibe-consumable:

„Erstelle eine standalone Ressource, die mit QBCore/ESX kompatibel ist (über Bridge oder Config).

1. Config: Items, Dauer, Anim Dict und Belohnungstyp (Gesundheit/Rüstung) definieren.
2. Client: Lauscht auf ein bestimmtes Event oder Export, um das Item zu „benutzen". Prüft, ob der Ped am Leben/nicht beschäftigt ist. Spielt Anim. Verwendet ox_lib für den Fortschrittsbalken.
3. Server: Lauscht auf das Abschluss-Event. MUSS Item-Anzahl vor dem Entfernen verifizieren. Fügt Belohnung hinzu.
4. Struktur: config.lua, client/main.lua, server/main.lua, fxmanifest.lua."

Kapitel 2: Das Gerüst

Lass uns das Skelett generieren. Wir wollen sofort eine saubere Ordnerstruktur.

„Ich brauche eine Ordnerstruktur für eine FiveM-Ressource namens vibe-consumable. Bitte generiere die fxmanifest.lua mit Standard-Metadaten, eine config.lua mit einem Beispiel-Item (Wasser) und leere client/main.lua und server/main.lua-Dateien. Version '1.0.0' verwenden." | Überprüfung:

Enthält die fxmanifest.lua die Client/Server-Skripte korrekt?	fx_version 'cerulean'
game 'gta5'	shared_script 'config.lua'
client_script 'client/main.lua'
server_script 'server/main.lua'
dependencies { 'ox_lib' }	Hinweis: Wir haben ox_lib zu den Abhängigkeiten hinzugefügt, da wir es verwenden wollen.

---

Kapitel 3: Den MVP-Loop implementieren

Jetzt die Logik. Wir machen das in zwei Durchläufen: Client, dann Server.

Durchlauf 1: Client-Interaktion Wir verwenden ox_lib für die UI, da uns das das manuelle Schreiben von NUI-Callbacks erspart.

„Schreibe die client/main.lua. Sie soll eine Funktion UseConsumable(itemName) haben, die:

1. Das Item in der Config nachschlägt.
2. lib.progressBar mit der Config-Dauer prüft.
3. Bei Erfolg TriggerServerEvent('vibe-consumable:server:consume', itemName) auslöst."

Durchlauf 2: Server-Validierung Hier glänzt Vibe-Coding. Du kannst die KI bitten, die Logik zu implementieren, und sie dann bitten, „als Sicherheitsprüfer zu handeln".

„Schreibe server/main.lua. Behandle das vibe-consumable:server:consume-Event. WICHTIG: Vertraue dem Client nicht.

1. Hole den Spieler aus der Source (nehme QBCore für diese Demo an).
2. Prüfe, ob der Spieler das Item tatsächlich in seinem Inventar hat.
3. Falls ja: Item entfernen -> Spieler heilen -> Benachrichtigen.
4. Falls nein: Eine Warnung protokollieren, dass der Spieler möglicherweise cheatet."

---

Kapitel 4: Härtung

Wir haben ein funktionierendes Skript, aber es ist fragil. Lass es uns härten.

1. Server-seitige Validierung

-- Die KI hat vielleicht nur `if item` geprüft. Wir müssen `item.count > 0` prüfen.

„Refaktoriere das Server-Event. Stelle sicher, dass wir die spezifische Menge des Items prüfen. Füge eine Cooldown-Tabelle hinzu, damit ein Spieler das Event nicht 10 Mal pro Sekunde spammen kann."

2. Sichere Events

Das Event vibe-consumable:server:consume kann von jedem Executor ausgelöst werden.

• Vibe-Check: Validiert der Server den Eingabe-itemName strikt gegen die Config? Ja. Prüft er die Distanz (falls zutreffend)? Hier nicht, aber gut im Hinterkopf zu behalten.

-- Für mehr zur Optimierung deiner Logik in dieser Phase, lies unseren Guide zu Boosting Performance in FiveM:
-- https://fivemx.com/blog/boosting-performance-fivem-optimize-scripts

---

Kapitel 5: Performance & Zuverlässigkeit

Wir wollen nicht, dass unser Skript CPU ms frisst.

Checkliste für die Überprüfung:

• Loops: Führen wir eine Citizen.Wait(0)-Schleife aus, um Tastendrücke zu prüfen? Lösung: Stattdessen RegisterCommand oder KeyMapping verwenden.
• Exports: Verwenden wir ox_lib korrekt statt schwerer nativer Zeichenfunktionen?
• Resmon: Prüfe resmon 1 in der Konsole. Es sollte im Leerlauf 0,00ms sein.

„Überprüfe den Client-Code. Ersetze alle CreateThread-Schleifen für die Eingabeerkennung durch RegisterKeyMapping, um die Performance zu optimieren."

---

Kapitel 6: UX-Politur

Ein Skript funktioniert, wenn es arbeitet; es vibet, wenn es sich gut anfühlt.

1. Locales: Niemals Text hardcoden. Alle Strings in locales/en.lua verschieben.
2. Benachrichtigungen: Ein Benachrichtigungssystem verwenden (Konfigurierbar: ox_lib, qb-notify, okok, etc.).
3. Debug-Modus: Ein Config.Debug-Toggle hinzufügen, das nützliche Informationen für Server-Besitzer in der Konsole ausgibt.

„Refaktoriere config.lua, um eine Locales-Tabelle einzuschließen. Ersetze alle hardcodierten Print/Notify-Strings in Client- und Server-Dateien durch Lookups aus dieser Tabelle."

---

Kapitel 7: Verpackung & Veröffentlichung

Du bist nicht fertig, bis du eine README hast.

„Schreibe eine README.md für diese Ressource. Beinhalte:

1. Titel: Vibe-Consumable
2. Abhängigkeit: ox_lib
3. Installationsschritte.
4. Ein Snippet der Config.
5. Ein Hinweis zur server-seitigen Validierung."

-- Wenn du diese Logik aus einem älteren Framework migrierst, lies:
-- https://fivemx.com/blog/converting-fivem-scripts/

---

Vibe-Coding-Workflows

Es gibt nicht nur einen Weg. Finde deinen Flow:

1. Der Architekt (Spec -> Generieren -> Prüfen -> Ausführen): Am besten für neue Skripte. Du schreibst eine Textdatei mit den Anforderungen, gibst sie der KI und bekommst eine ganze Menge Code zurück. Du verbringst 80 % deiner Zeit mit dem Überprüfen.
2. Das Skelett (Manuell gerüsten -> KI füllt Module):

    -- Du erstellst Dateien und Funktionen: `function HandleEat() end`.
    -- Du markierst die Funktion und sagst der KI: "Fülle diese aus."

3. Der Archäologe (Debug & Legacy refaktorieren):

    -- Füge ein altes, nicht optimiertes Skript in den Chat.
    -- Prompt: "Modernisiere diesen Code. Verwende `ox_lib` für die UI,
    -- entferne Busy-Loops und behebe veraltete Native-Aufrufe."

4. Der Pair-Programmer: Mit Tools wie Cursor oder Copilot tippst du einen Kommentar -- Prüfen, ob der Spieler Berechtigung hat, und lässt die KI die nächsten 5 Zeilen vervollständigen. Das ist die schnellste „Flow-State"-Methode.

---

Prompt-Kit

Kopiere diese Vorlagen, um deinen Workflow zu beschleunigen.

Das „Initial Brief"-Template:

„Handle als Senior FiveM-Entwickler. Ich brauche ein [Framework: QB/ESX/Standalone]-Skript, das [Core Feature] handhabt. Einschränkungen:

• [Bibliothek: ox_lib/qb-menu] für UI verwenden.
• Auf 0,00ms Leerlauf optimieren.
• Config von Logik trennen.
• [Spezifischer Native/Event] muss verwendet werden."

Das „Security Audit"-Template:

„Analysiere den folgenden Server-seitigen Code auf Exploits. Suche speziell nach:

1. Vertrauen von Client-Daten ohne Verifikation.
2. SQL-Injection-Risiken (falls SQL verwendet wird).
3. Fehlendem Rate Limiting. Liefere eine refaktorierte Version, die diese Probleme behebt."

Das „Native Finder"-Template:

„Ich brauche einen FiveM-Native, der [Aktion, z.B. ein Objekt an einen Bone anhängen] handhabt. Bitte gib den Native-Namen, einen Link zur FiveM Natives-Referenz und ein Verwendungsbeispiel in Lua an."

Du kannst auch die FiveM-Docs hier abrufen

---

Quality Gates

Bevor du auf GitHub oder deinen Server pushst, durchlaufe diese Gates:

• Security Gate: Habe ich die Item-Anzahl auf dem Server verifiziert, bevor ich die Belohnung vergebe?
• Performance Gate: Ist resmon 0,00ms–0,01ms?
• Documentation Gate: Ist die config.lua erklärt? Ist die Abhängigkeitsliste korrekt?
• Error Gate: Gibt es Skriptfehler in der F8-Konsole beim Happy Path (normale Nutzung) oder Edge Cases (Item droppen während der Fortschrittsbalken läuft)?

Viel Spaß beim Coden!

Wenn du mit diesem Workflow etwas Cooles baust, teile es in den FiveM-Foren.

Wie man KI für FiveM nutzt