Roblox Tycoon: Server-Authoritative Factories and Conveyor Belts
ESCOPO
This prompt creates an advanced technical request to generate a tycoon system with producing factories, physical items, and conveyor belts. The solution prioritizes server-side simulation, configurable production cycles, destination detection, secure delivery, and prevention of coin and item duplication or exploitation.
Ideal for developers who already have a tycoon map and want to adapt the automation to their own Model, Part, Attribute, tag, RemoteEvent, and Explorer structure names. The requested result from the assistant is a complete, commented Luau Script ready to paste into Roblox Studio, along with clear setup and testing instructions.
Conteudo
Prompt principal
Act as a senior Roblox developer specialized in Luau, multiplayer tycoon systems, Assembly physics, and server-authoritative architecture. Generate a complete factory and conveyor belt system for my game, using exclusively a server Script located in ServerScriptService. The result must be a single self-contained Luau Script, ready to paste into Roblox Studio, without relying on plugins, external frameworks, or omitted code. Before writing the code, analyze and incorporate the context I will provide below. If any data is missing, do not invent specific names: create a CONFIG section at the start of the script with values and paths that are easy to adapt, documenting exactly what I need to change. My game context will be pasted after this instruction and may include object names in the Explorer, plot structure, factory Models, conveyor Parts, item models, attributes, CollectionService tags, existing RemoteEvents/RemoteFunctions, leaderstats, money system, and tycoon ownership rules. [PASTE MY GAME CONTEXT HERE: names and paths in the Explorer, plot structure, existing objects, tags, attributes, RemoteEvents, money system, item models, and rules] Implement the system with these responsibilities: each factory belonging to a player must produce items at configurable intervals; each item must have a value, unique identifier, tycoon owner, and origin metadata; items must spawn at a configurable output point and travel through a network of conveyors. Conveyors must apply movement in a stable and efficient way on the server, preferably using impulse/calculated velocity or safe manipulation of AssemblyLinearVelocity, respecting the real direction of the Part and avoiding vertical velocity buildup. Do not use infinite individual loops for each item or disconnected Heartbeat: use a single centralized update and disconnect/clean up everything necessary. Design the Script to recognize factories, conveyors, collectors, and spawners by Attributes and/or CollectionService tags, prioritizing whichever pattern exists in the provided context. If no pattern exists, use an explicit and documented convention, for example: tags Factory, Conveyor, Collector and attributes OwnerUserId, ProductionInterval, ItemValue, ConveyorSpeed, and ItemTemplate. Each factory must produce only if it is active, has a valid owner, and respects a configurable limit of active items per plot/factory, preventing lag and instance spam. The created items must be anchored or unanchored according to the technical strategy you choose, but briefly justify the choice and ensure they can be transported correctly. Collection must happen only when a valid item touches or is detected inside a collector belonging to the same owner as the item. On the server, fully validate: item existence, marking as an item generated by the system, owner, already-collected state, numeric value within limits, and plot permissions. Upon delivery, grant money exclusively on the server through a function adaptable to my money system; never allow the client to report value, owner, created item, or reward. Implement debounce and double-collection protection, remove the item safely, and log useful warnings with warn only when there is invalid configuration or suspicious behavior. Even if I provide RemoteEvents, do not use RemoteEvent for production, transport, value, or automatic collection. If there is an optional player-initiated action, such as turning a factory on/off, validate the Player, plot ownership, allowed distance/state, and all received arguments on the server. Do not trust the client for damage, money, inventory, production rate, cost, or item identifiers. Avoid MemoryLeaks: disconnect events from destroyed items, clean up tracking tables, and handle players leaving the server. Deliver the response in this order: (1) a short summary of the architecture and the assumptions adopted; (2) a precise list of the script type and location in the Explorer: Script in ServerScriptService, including the expected objects/Attributes/tags; (3) the complete Luau code and extensively commented inside a single markdown ```lua block; (4) final numbered steps to configure and test in Roblox Studio with Start Server + Players, including tests for production, conveyor direction, item limit, collection, ownership change, and exploitation attempts. The code must be syntactically valid in Luau, use services with game:GetService, use task.wait/task.spawn when appropriate, handle missing references safely, and leave no pseudocode, "..." snippets, empty functions, or unimplemented dependencies.
