Secure Anti-Invasion System for Roblox Bases and Tycoons

# www.prompthubai.com.br
# Encontre prompts, agentes e workflows testados para vender, programar e automatizar com IA em português.

# Secure Anti-Invasion System for Roblox Bases and Tycoons

## Cabecalho
- Tipo: Conteudo
- Categoria: Games
- Modulos: 0
- Agentes: 0

## Escopo
Generate a robust base and tycoon protection system for Roblox multiplayer experiences. The result should be an authoritative server-side Luau Script, prepared to identify the owner of each base, monitor protected zones, block intruders, and handle exceptions such as allies, teams, or temporary permissions.

The prompt guides the AI to adapt the code to the real structure of your Explorer, including folder names, Parts, Attributes, owner values, CollectionService tags, and RemoteEvents that already exist. It also requires strict validation of any request coming from the client, preventing exploits related to teleportation, damage, money, item theft, and unauthorized access.

Ideal for developers creating tycoons, base-building games, PvP with territories, simulators, and experiences with private properties. The requested code comes commented, ready to paste into Roblox Studio, and includes a multiplayer test plan.

## Prompt Principal
Act as a senior Roblox developer, specializing in Luau, multiplayer security, and server-authoritative architecture. Create a complete base/tycoon protection system against other players using a single server Script called `BaseProtectionServer`, located in `ServerScriptService`. Before writing the code, analyze and use the context of my game provided below.

My Explorer context and current rules (I will fill in or replace these fields):
- Folder that contains all bases/tycoons: [EX.: workspace.Tycoons]
- How each base is identified: [EX.: Model with Attribute `BaseId`, numeric name, or its own folder]
- How the owner is stored: [EX.: Attribute `OwnerUserId`, IntValue `OwnerUserId`, ObjectValue `Owner`, or external system]
- Name/location of the protected zone parts: [EX.: Model.BaseZone, Part `ProtectionZone`, or CollectionService tag `BaseProtectionZone`]
- Structure of doors/barriers: [EX.: Part `Barrier`, folder `Doors`, existing CollisionGroup]
- Current method for claiming a base: [describe]
- Existing RemoteEvents/RemoteFunctions and location: [list name, path, and purpose]
- Damage/weapon system used in the game: [describe scripts, events, and how damage occurs]
- Money, theft, or inventory system that must be blocked in the base: [describe]
- Teams, allies, gamepasses, or permissions that may enter: [describe]
- Desired action when an intruder enters: [EX.: teleport to Spawn, push out, only prevent interaction, show warning]
- Other relevant objects or rules: [describe]

Create the code for a normal server Script (not a LocalScript and not a ModuleScript), to be inserted into `ServerScriptService`. The system must work in a multiplayer environment and adopt server-authoritative behavior: the server is the only source of truth for base ownership, permissions, damage, currency, items, doors, and protection effects. Never accept from the client an owner UserId, a target base, a permission, a money value, a damage amount, a position, or a reward without validating everything on the server.

Implement a robust and configurable solution inside the Script itself, with a clearly organized `CONFIG` section at the beginning. It should make it easy to adapt folder names, Attributes, tags, protection duration, intruder behavior, distance/tolerance limits, and ally rules. If the information in my context is incomplete, make safe assumptions and centralize all of them in `CONFIG`, documenting exactly what I need to change in the Explorer in comments.

The system must, when applicable to my structure: reliably detect which base belongs to each player; recognize whether a character is inside that base's zone; allow the owner and authorized players; block or remove intruders from the area according to the configured rule; avoid excessive loops and connection leaks; handle `PlayerAdded`, `PlayerRemoving`, `CharacterAdded`, respawn, death, owner changes, ownerless bases, and destruction/recreation of objects. Use `Players`, `RunService`, `CollectionService`, `PhysicsService`, and other services only if they are truly necessary and compatible with the provided context.

If there are RemoteEvents or RemoteFunctions related to doors, purchases, collection, damage, theft, access, or base claiming, integrate server-side validation. For each remote call, validate on the server: argument types with `typeof`, existence and class of Instances, the real link between the player and the base, plausible distance between character and object, base state, cooldown/rate limit, and authorization. Do not use remote events to grant damage, currency, items, or ownership solely based on data sent by the client. If the weapon/damage system is external and cannot be changed in this single Script, leave a documented interface/function so the damage script can check before applying damage in a protected zone.

Avoid fragile solutions such as relying only on `Touched`, using `while true do wait()` for all players, setting owner on the client, or making the entire base anchored as the only security strategy. Prefer efficient heartbeat-based monitoring with a configurable interval, reliable spatial checks, and managed connections. Do not permanently destroy the intruder's character unless there is an explicit option in the configuration. Ensure the system does not block the owner due to temporary failures during respawn.

Your response must follow exactly this structure:
1. A short list of prerequisites and the expected Explorer structure.
2. A single Markdown code block with the `lua` language, containing the complete, functional, commented Luau Script ready to paste into `ServerScriptService`.
3. After the block, objectively explain which `CONFIG` values I should adapt to my game.
4. Finish with a step-by-step guide to test in Roblox Studio using `Test > Start` with at least two players, including tests for owner, intruder, respawn, owner change, invalid RemoteEvents, and client-side exploit attempts.

Do not deliver pseudocode, incomplete snippets, client code as the main security mechanism, or unexplained dependencies. Prioritize compatibility with current Luau, readability, useful error handling, and real server-side security.