Dónde colocar Script, LocalScript y ModuleScript en Roblox Studio

Decide qué lado realiza la acción #

Da una tarea clara a cada fragmento. Las reglas de recompensas necesitan validación del servidor; la presentación local de la interfaz pertenece al cliente. Una función compartida puede estar en un módulo llamado por el lado adecuado. Elige el punto de entrada antes de añadir objetos.

La ejecución depende del tipo, la ubicación y, en Script, RunContext. Un texto idéntico puede comportarse distinto en otro contenedor. El ejercicio crea mensajes separados del servidor y del cliente y después carga un módulo. Usa un proyecto de práctica para asociar cada mensaje con su ejemplo.

1. Ejecuta un Script de servidor #

Añade un Script normal llamado ServerStart dentro de ServerScriptService. Selecciónalo y establece RunContext en Server mediante Properties. Legacy también funciona aquí, pero Server deja explícito el propósito. Comprueba que esté activado.

Sustituye su contenido por el primer ejemplo. Abre Output e inicia Test con un jugador. Espera SERVER: ready en contexto de servidor. Confirma que se alcanzó print(), no que exista una lógica completa de recompensas. Si falta la línea, revisa filtros y ubicación antes de cambiar código.

print("SERVER: ready")

2. Ejecuta un Script de cliente #

Añade un Script normal llamado ClientStart en ReplicatedStorage. Establece RunContext expresamente en Client y pega el segundo ejemplo. Colocar aquí un Script con Legacy no crea por sí solo una entrada del cliente.

Inicia otra prueba. CLIENT: ready debe pertenecer al cliente y SERVER: ready al servidor. La documentación actual recomienda ReplicatedStorage para esta entrada del cliente. Evita mover este Script con contexto Client a StarterPlayerScripts: original y copia pueden ejecutarse y producir duplicación.

print("CLIENT: ready")

3. Considera las copias de LocalScript #

LocalScript se ejecuta en el cliente y no tiene RunContext. Para una práctica separada, detén Test, desactiva ClientStart temporalmente y crea LocalStart como LocalScript en StarterPlayer → StarterPlayerScripts. Usa print("LOCAL: ready").

Busca el mensaje del cliente tras iniciar Test. El contenido de Starter se copia al jugador, por lo que la fuente puede apuntar a Players → nombre → PlayerScripts. Esto explica la diferencia respecto a la ubicación original. Un LocalScript almacenado simplemente en ReplicatedStorage no se ejecuta allí por existir.

4. Carga ModuleScript desde una entrada #

Detén la prueba y crea un ModuleScript llamado exactamente PracticeModule en ReplicatedStorage. Pega el primero de los dos ejemplos de este apartado. Devuelve una tabla con start(). Crear el módulo no llama esa función: debe cargarlo código que se esté ejecutando.

Sustituye ServerStart por el segundo ejemplo: busca el módulo, recibe su valor mediante require() y llama start(). Una nueva prueba debe mostrar MODULE: started en el servidor. WaitForChild espera el nombre indicado; una errata no crea un módulo ausente. Compara nombre y código.

local PracticeModule = {}

function PracticeModule.start()
    print("MODULE: started")
end

return PracticeModule

print("SERVER: ready")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local practice = require(ReplicatedStorage:WaitForChild("PracticeModule"))
practice.start()

5. Elige el contenedor según su función #

Usa la tabla como estructura inicial. ServerScriptService sirve para entradas del servidor; ReplicatedStorage para el Script recomendado con contexto Client y módulos compartidos. Un módulo solo del servidor puede quedarse en ServerScriptService si el cliente no lo necesita.

Ubicación y visibilidad son cuestiones distintas. ReplicatedStorage llega a los clientes: sus módulos no deben contener secretos ni sustituir comprobaciones del servidor para compras o recompensas. ServerStorage guarda objetos del servidor; un Script normal no arranca automáticamente allí. Sitúa la entrada en un contenedor de ejecución.

6. Comprueba cuatro cosas si no arranca #

Revisa el tipo exacto, la ruta en Explorer, RunContext cuando exista y si está activado. Para un módulo, busca también el script que llama require(). Iconos parecidos o nombres iguales no demuestran entornos de ejecución iguales.

Añade un print al inicio, elimina el filtro de texto e incluye el contexto adecuado en Output. Si aparece la primera marca pero no la siguiente, estudia el código intermedio. Si no hay ninguna, revisa inicio y visibilidad. Lee los errores por su fuente; mover archivos al azar complica encontrar la causa.

7. Guarda el original y comprueba otra vez #

Detén Test antes de editar definitivamente. Si cambiaste una copia de LocalScript en PlayerScripts durante el juego, traslada la corrección al original en StarterPlayerScripts. Los objetos de prueba se restablecen al parar; cambiar solo una copia temporal puede no sobrevivir al siguiente inicio.

Reactiva ClientStart para los ejemplos principales y desactiva LocalStart cuando sobre. En una prueba nueva busca SERVER: ready, CLIENT: ready y MODULE: started desde la llamada del servidor. Guarda. Debes poder identificar tipo, ruta, contexto y llamador de cada mensaje antes de mover funciones reales una a una.