Animated Notification System with Roblox Tweening
ESCOPO
Generate a professional notification system for Roblox with animated entry and exit, smart stacking, message queuing, visual priorities, and support for multiple categories such as success, error, warning, reward, and info. The system creates and manages the interface dynamically, reducing dependence on manual elements in StarterGui.
Ideal for developers who want to present polished visual feedback for game events such as completed purchases, updated quests, received rewards, full inventory, or system alerts. The prompt requests specific context from the Explorer and existing RemoteEvents, allowing the code to adapt to the real project without sacrificing security or organization.
Conteudo
Prompt principal
Act as a senior Roblox developer specialized in Luau, client-server architecture, responsive UI, and interface optimization in Roblox Studio. Create a complete, reusable, production-ready system of animated notifications and popups with TweenService. Before writing the code, you must take into account the context of my project below. If any field is empty, adopt a safe convention and briefly state the assumption before the code block, without asking additional questions. MY GAME CONTEXT: - Experience name/genre: [PASTE HERE] - Desired visual style (e.g., futuristic, cartoonish, minimalist): [PASTE HERE] - Priority resolution/platforms (PC, mobile, console): [PASTE HERE] - Existing RemoteEvent for server > client notifications (full path): [EX.: ReplicatedStorage.Remotes.NotifyClient] - Current format of the arguments sent by the server: [EX.: title, message, type, duration] - Names of existing UI objects in the Explorer that should be reused: [PASTE HERE] - Required colors, fonts, or icons: [PASTE HERE] - Desired limit of simultaneous notifications: [EX.: 4] - Desired extra features (sound, close button, icons, etc.): [PASTE HERE] MANDATORY TYPE AND LOCATION: deliver ONE single LocalScript, intended for StarterPlayer > StarterPlayerScripts. This LocalScript must programmatically create its own ScreenGui inside PlayerGui at runtime, with ResetOnSpawn configured appropriately to preserve or recreate the UI correctly after respawn. Do not rely on plugins, external packages, paid assets, mandatory image IDs, or nonexistent modules. The script must implement the following technical requirements: 1. Use TweenService for smooth entry, repositioning, exit animations and, when appropriate, a subtle scale animation. Entry must combine transparency and horizontal or vertical offset; exit must occur safely before the card is destroyed. 2. Create a clear local API, for example ShowNotification(config), even if it remains internal to the LocalScript. The configuration must support title, message, type, duration, priority, optional icon, and an optional deduplication identifier. 3. Implement configurable visual types, at minimum: Success, Error, Warning, Info, and Reward. Each type must have an accent color, a safe textual/placeholder icon, and coherent visual behavior. 4. Position the cards in a safe area of the screen, preferably in the top-right corner, using AnchorPoint, UDim2, UIPadding, UIListLayout, and appropriate constraints. The interface must remain readable on mobile screens and cannot depend on fragile absolute coordinates. 5. Maintain a queue for messages above the simultaneous limit. Higher-priority messages should be able to enter before normal ones when technically feasible. When a card leaves, the next item in the queue must be shown. 6. Avoid duplicates: if a notification with the same deduplication identifier is visible or queued during a short window, update/reject the repeat in a predictable way. Also protect the system against excessively long text, invalid duration, invalid type, and spam. 7. Allow optional manual closing via button, without breaking tweens, the queue, or instance destruction. Ensure multiple removal calls do not cause errors, connection leaks, or cards stuck on screen. 8. Connect to the informed RemoteEvent only if it exists and is truly a RemoteEvent. This event is exclusively server > client for visual presentation. The LocalScript must never send currency, damage, inventory, rewards, permissions, or any gameplay decision to the server. 9. Explain in comments that the server must be authoritative: any client > server RemoteEvent/RemoteFunction must be fully validated on the server, including types, limits, player state, permissions, and rate limiting. Never trust notifications requested by the client as proof of a reward or valid action. 10. If the RemoteEvent exists, accept payloads as a table and also a simple argument format, but sanitize all values before rendering. Since this is client-side code, treat the payload only as visual content and do not execute text, functions, or arbitrary references received. Demand production quality: use task.wait/task.delay when necessary, well-defined TweenInfo, organized connections, unambiguous variable names, useful comments in Brazilian Portuguese, and checks with FindFirstChild/WaitForChild with timeout when appropriate. Do not use unnecessary infinite loops or deprecated APIs. Include commented examples of local calls to test Success, Error, and Reward, but leave those calls disabled by default so they do not pollute the real game. MANDATORY RESPONSE FORMAT: - Start with a short list of assumptions based on the provided context. - Then deliver the full LocalScript in a single markdown block identified as ```lua. - Do not omit sections with phrases like “rest of the code” or “add your logic here”. The code must be complete and directly pasteable. - After the code, provide objective instructions to install it in the Explorer, configure the RemoteEvent, fire a notification from a server Script only as a conceptual example, and test queueing, priority, deduplication, responsiveness, and respawn in Roblox Studio. Prioritize robustness, polished visual experience, and compatibility with the provided context.
