Los recursos que todo servidor usa

FiveM por sí solo te da un servidor de GTA V vacío: el motor, la red y la capacidad de cargar recursos. Pero no sabe qué es «dinero», ni un «trabajo», ni un «inventario», ni quién eres tú entre sesión y sesión. Todo eso lo aporta un framework de roleplay: una base de recursos que se instala encima de FiveM y define las reglas del juego de rol.

Qué es un framework de roleplay

Un framework es la capa que convierte un servidor vacío en un servidor de RP. Te da las piezas comunes que casi cualquier servidor necesita, para que no tengas que reinventarlas en cada recurso.

• Identidad persistente: cada jugador tiene un personaje guardado en la base de datos (nombre, apariencia, datos).
• Dinero: efectivo, banco y, a veces, dinero negro, con funciones para sumar y restar.
• Trabajos: policía, mecánico, taxista... con rangos y permisos.
• Inventario: objetos que el jugador lleva encima y que se guardan al desconectar.

ESX Legacy (es_extended)

ESX es el framework más veterano y el que más recursos de terceros tiene disponibles. Su recurso principal se llama es_extended. Para usarlo desde tu script obtienes el «objeto compartido» (el core de ESX) y, a partir de él, accedes a los jugadores.

-- Obtener el core de ESX (lado servidor)
ESX = exports['es_extended']:getSharedObject()

RegisterCommand('pagar', function(source)
  local xPlayer = ESX.GetPlayerFromId(source) -- objeto del jugador
  if not xPlayer then return end

  xPlayer.addMoney(500)            -- le damos 500 de efectivo
  print(xPlayer.getMoney())        -- cuánto efectivo tiene
  print(xPlayer.job.name)          -- su trabajo actual, ej. 'police'
end)

-- Callback: el cliente pregunta, el servidor responde
ESX.RegisterServerCallback('mi_recurso:saldo', function(source, cb)
  local xPlayer = ESX.GetPlayerFromId(source)
  cb(xPlayer.getMoney())
end)

QBCore (qb-core)

QBCore es más moderno y modular, con una comunidad muy activa. Su recurso principal se llama qb-core. La idea es idéntica a la de ESX: obtienes el core y desde él accedes a cada jugador; solo cambian los nombres de las funciones.

-- Obtener el core de QBCore (lado servidor)
local QBCore = exports['qb-core']:GetCoreObject()

RegisterCommand('pagar', function(source)
  local Player = QBCore.Functions.GetPlayer(source) -- objeto del jugador
  if not Player then return end

  Player.Functions.AddMoney('cash', 500)   -- le damos 500 de efectivo
  print(Player.PlayerData.job.name)         -- su trabajo, ej. 'police'
end)

-- Callback: el cliente pregunta, el servidor responde
QBCore.Functions.CreateCallback('mi_recurso:saldo', function(source, cb)
  local Player = QBCore.Functions.GetPlayer(source)
  cb(Player.PlayerData.money.cash)
end)

ESX y QBCore, lado a lado

Cuando ves los dos juntos, descubres que es la misma lógica con distinto vocabulario. Esta tabla mental te servirá para traducir cualquier recurso de un framework al otro:

• Obtener el core: ESX.getSharedObject() ↔ QBCore:GetCoreObject()
• Obtener al jugador: ESX.GetPlayerFromId(source) ↔ QBCore.Functions.GetPlayer(source)
• Dar dinero: xPlayer.addMoney(500) ↔ Player.Functions.AddMoney('cash', 500)
• Ver el trabajo: xPlayer.job.name ↔ Player.PlayerData.job.name
• Crear callback: ESX.RegisterServerCallback(...) ↔ QBCore.Functions.CreateCallback(...)

El ecosistema ox (overextended)

Por encima del framework hay un conjunto de recursos del equipo overextended (los «ox») que se han vuelto el estándar moderno. Lo bueno es que funcionan tanto con ESX como con QBCore, así que aprenderlos te vale para ambos mundos.

• oxmysql: la conexión a la base de datos MySQL/MariaDB. Casi todo el ecosistema depende de él.
• ox_lib: caja de herramientas (menús, inputs, notificaciones, zonas, callbacks). Te ahorra escribir UI y utilidades a mano.
• ox_inventory: un inventario completo, con peso, slots y objetos guardados en base de datos.
• ox_target: interacción «por mirada»: apuntas a algo y aparece un menú de acciones contextuales.

Bridges: un recurso, varios frameworks

Muchos recursos modernos quieren venderse o usarse tanto en ESX como en QBCore. Para no escribir el código dos veces usan un «bridge» (puente): detectan qué framework está activo en el servidor y, a partir de ahí, llaman a las funciones correctas detrás de una interfaz común.

-- Patrón de puente simplificado
local Framework, name

if GetResourceState('es_extended') == 'started' then
  Framework = exports['es_extended']:getSharedObject()
  name = 'esx'
elseif GetResourceState('qb-core') == 'started' then
  Framework = exports['qb-core']:GetCoreObject()
  name = 'qb'
end

-- Función unificada: el resto del recurso ya no se entera del framework
local function darDinero(src, cantidad)
  if name == 'esx' then
    Framework.GetPlayerFromId(src).addMoney(cantidad)
  elseif name == 'qb' then
    Framework.Functions.GetPlayer(src).Functions.AddMoney('cash', cantidad)
  end
end

ESX o QBCore: cómo elegir

No hay una respuesta única, y los dos son opciones serias y mantenidas. ESX tiene la base de recursos más grande del mercado, así que es fácil encontrar (o comprar) casi cualquier sistema ya hecho. QBCore suele considerarse algo más moderno y modular en su diseño, con datos del jugador muy estructurados. Para empezar, elige el que use la comunidad o el creador de contenido que sigues, porque tendrás más ejemplos a mano.