Advanced NPC Dialogue System with Option Tree
ESCOPO
Ideal for developers who want a reusable system, secure against client-side exploits, and ready to grow with reputation, quests, progress flags, rewards, and multiple NPCs.
Conteudo
Prompt principal
Act as a senior Roblox developer specialized in Luau, client-server architecture, exploit security, and scalable narrative systems. Create a complete NPC dialogue system based on an option tree, using the context of my game provided below before generating any code. My project context (replace the fields when I provide real values): - NPCs and paths in Explorer: [PASTE HERE, for example: Workspace.NPCs.Guard, Workspace.Village.Merchant] - Part used for interaction: [existing ProximityPrompt / NPC part / create ProximityPrompt] - Existing interface: [PASTE paths to ScreenGui, Frames, Labels and Buttons, or say "create interface via script"] - Existing RemoteEvents/RemoteFunctions: [PASTE NAMES AND PATHS, or say "create the necessary ones"] - Existing data/progress system: [leaderstats, ProfileService, custom DataStore, attributes, none, etc.] - Desired dialogue rules, NPCs, texts, choices, rewards, and conditions: [PASTE HERE] - Visual and compatibility constraints: [desktop/mobile/gamepad, style, distance limit, etc.] If any essential information is missing, do not invent names of already existing objects. First, objectively list the assumptions adopted and use consistent names that are easy to replace. If I say I do not yet have an interface or remotes, create the necessary structure programmatically or explain exactly which instances to create in the Explorer, prioritizing a ready-to-test solution. Implement an architecture composed of the following files, delivered in full: 1. A ModuleScript called `DialogueDefinitions`, placed in `ReplicatedStorage/Shared` (or in the equivalent path I provide). It must contain the dialogue data for multiple NPCs in a declarative and scalable structure. Each node must support: `Id`, NPC text, player options, next node, ending, optional condition, alternate text for failed condition, and optional server-authorized action. Include real examples of at least two NPCs and one branch with a progress requirement. 2. A Script called `DialogueServer`, placed in `ServerScriptService`. It must control the dialogue session per player, connect the ProximityPrompts or the interaction method provided, open dialogues, validate player distance to the NPC, validate whether the NPC exists, and validate whether the selected option belongs to the session's current node. The server must be the sole authority for conditions, flags, rewards, coins, inventory, and progression. 3. A LocalScript called `DialogueClient`, placed in `StarterPlayer/StarterPlayerScripts` or inside the ScreenGui indicated in my context. It must display the dialogue, render buttons dynamically, allow closing the conversation, handle mouse/touch/gamepad input when applicable, and never decide rewards, conditions, or progression. Use `RemoteEvent`s with clear names, preferably `DialogueRemote` for server-client communication, creating them in `ReplicatedStorage/Remotes` only if they do not already exist. Define an explicit message protocol, for example: server sends `Open`, `Update` and `Close`; client requests only `SelectOption` or `RequestClose`. Every message received from the client must be rigorously validated on the server: types with `typeof`, existence and format of IDs, string length limits if there is textual data, rate limit/debounce per player, current session state, maximum distance, character health, and option eligibility. Never trust the client to report the current NPC, current node, damage, coin, item, completed quest, or any sensitive state. Implement robust cleanup: end sessions on death, leaving the game, moving away from the NPC, NPC being destroyed, or dialogue being finalized. Avoid duplicate connections and memory leaks. Do not use `loadstring`, do not use DataStore directly inside interface logic, and do not create infinite loops unnecessarily. Structure small, named functions, use `--!strict` when viable, modern `task` APIs, and helpful comments in Portuguese explaining relevant decisions. The response must contain, in this order: a brief section "Structure in the Explorer"; a section "Complete code" with ALL files in full inside a single markdown ```lua block, separating each file by large comments with name and path; a section "How to customize dialogues" with examples of nodes and conditions; and a section "How to test in Roblox Studio" with steps to test in Start Server + Players mode, verify remotes, distance, invalid choices, and session closure. Do not deliver pseudocode, incomplete snippets, or unimplemented dependencies. The code needs to be ready to paste, respecting the paths and objects I provide.
