Advanced Inter-Round Map Voting System
ESCOPO
Generate a robust inter-round map voting implementation for competitive, cooperative, or minigame Roblox experiences. The prompt instructs the AI to analyze the real structure of your Explorer, adapt the names of existing RemoteEvents, folders, and interfaces, and deliver ready-to-use Luau files.
The requested system follows a server-authoritative architecture: the server selects candidates, controls the timer, validates votes, prevents duplicates, and decides the winning map. It also covers visual updates for players, tie handling, players joining or leaving during voting, and safe integration with loading the next round.
It is intended for developers who already have, or want to structure, a professional match loop and need to avoid common mistakes such as trusting the client to record votes, select maps, or determine results.
Conteudo
Prompt principal
Act as a senior Roblox developer, specialized in Luau, server-authoritative multiplayer systems, and scalable architecture for round cycles. Develop a complete inter-round map voting system, strictly adapted to the context of my game that will be provided below. Before writing the code, read and use the information in the PROJECT CONTEXT block. If any essential data is missing, do not invent an incompatible structure: state your assumptions clearly at the beginning of the response and use configurable names concentrated at the top of the scripts. My goal is to receive complete Luau files, ready to paste into Roblox Studio, not pseudocode or incomplete snippets. PROJECT CONTEXT — I will fill this in before sending: - Map structure: [e.g., ServerStorage/Maps, each map is a Model] - Where the active map should be cloned to: [e.g., Workspace/ActiveMap] - System/object that starts the next round: [name, path, and API/BindableEvent, if any] - Voting duration in seconds: [value] - Number of candidate maps: [value] - Existing RemoteEvents/RemoteFunctions and their respective paths: [list] - Existing voting UI and hierarchy of elements: [ScreenGui, Frames, buttons, labels, etc.] - If the UI does not exist yet: [yes/no] - Desired tie-breaking rules: [random among tied / order / other] - Special restrictions: [blocked maps, minimum players, gamepass, test mode, etc.] Deliver a solution composed of these files, explicitly stating the type and location of each one in the Explorer: 1. A server Script in ServerScriptService, for example MapVotingServer.server.lua. It must be the total authority over the voting. 2. A LocalScript in StarterPlayer/StarterPlayerScripts or inside the ScreenGui in StarterGui, choosing the most appropriate location according to the UI provided. It must only render state, send the voting intent, and never decide the result. 3. If needed for organization, a configuration ModuleScript in ReplicatedStorage, for example MapVotingConfig. Include it only if it provides real benefit; if you include it, deliver the entire file. The server Script must: locate and validate folders/instances with WaitForChild using timeouts and useful error messages; select candidates without repetition and only among valid maps; start, synchronize, and end a countdown; send the initial state and updates to all players; accept one vote per player, but allow vote changes during the window; correctly remove votes from players who leave; calculate counts on the server; resolve ties according to the informed rule; choose the winner exclusively on the server; and expose a clear integration point so the round loop can load the winning map. If there are no players, not enough candidates, or no votes, implement a predictable and documented fallback. Security is mandatory. Any data received from a RemoteEvent or RemoteFunction must be validated on the server: confirm that the player is valid, that voting is active, that the map identifier is allowed for that round, and that there are no unexpected payloads. Do not accept vote counts, winner names, remaining time, damage, currency, inventory, or any critical decision from the client. The candidate list and the winner must exist only on the server. Use RemoteEvents with simple, documented contracts; if the Remotes do not exist in the context, create them safely in ReplicatedStorage/Remotes in the server Script, without duplicating them. In the LocalScript, implement responsive updates for buttons, displayed votes, the currently selected map, a disabled state after voting ends, and synchronization for a player who joins in the middle of voting. If the UI does not exist, create a simple UI by code with three configurable options, vote labels, and a timer, without relying on external assets. If it does exist, adapt to the exact paths provided and do not recreate unnecessary components. Add local debounce only for user experience, but make it clear in comments that real protection is on the server. Quality requirements: use modern Luau, --!strict when compatible, types when they improve safety, descriptive names, useful comments, and disconnectable connections when applicable. Avoid unnecessary infinite loops, excessive polling, globals, untrusted require, loadstring, and outdated APIs. Preserve multiplayer compatibility and handling of players joining/leaving. Do not use DataStore, HTTPService, or currency systems unless the context explicitly asks for them. Format the final response in this order: (1) brief summary of assumptions and architecture; (2) installation tree in the Explorer; (3) each complete file in its own identified markdown block, necessarily using ```lua; (4) objective explanation of each RemoteEvent contract; and (5) detailed steps to test in Roblox Studio, including Test > Start Server with multiple Players, vote changes, ties, late joins, leaving during voting, and no-vote cases. Do not omit any required file and do not deliver partial code.
