Roblox Dual Currency System: Soft Currency and Robux
ESCOPO
Generate a professional dual-economy system for Roblox: a soft currency earned during gameplay and a premium currency purchased exclusively with Robux. The prompt guides the correct implementation of the Developer Products flow, avoiding the common mistake of trying to directly manipulate the player's Robux balance.
Ideal for games with stores, upgrades, cosmetics, boosts, gem packs, and persistent economies. The requested result includes server-authoritative architecture, DataStore, validated RemoteEvents, reward duplication prevention, and practical instructions to configure and test everything in Roblox Studio.
Conteudo
Prompt principal
Act as a senior Roblox developer, specializing in Luau, game economies, DataStoreService, and secure monetization with MarketplaceService. Create a complete, secure, production-ready dual-currency system: one soft currency earned in-game and one premium currency purchased with Robux through Developer Products. Before writing the code, consider the specific context of my project below. If any item is empty or does not exist, adopt safe names and explain where I should create it. Preserve and integrate with existing objects whenever possible, without renaming or deleting resources from my game. MY GAME CONTEXT (I will fill in): - Soft currency name: [e.g.: Coins] - Premium currency name: [e.g.: Gems] - Current Explorer structure: [paste here] - Existing RemoteEvents/RemoteFunctions and their purposes: [paste here] - Developer Products and IDs: [e.g.: 123456 = 100 Gems; 123457 = 500 Gems] - Store/items that consume soft currency or premium currency: [describe] - Does a custom DataStore system already exist? [yes/no; paste details] - Does MarketplaceService.ProcessReceipt already exist in another script? [yes/no; paste the code or describe] - Additional reward, limit, and pricing rules: [describe] IMPORTANT ABOUT ROBUX: handle Robux correctly. The game cannot read, store, transfer, or alter the player's real Robux balance. Therefore, the hard/premium currency must be an in-game virtual currency, such as Gems, granted only after purchase confirmation of a Developer Product by MarketplaceService. Use PromptProductPurchase to initiate the purchase and MarketplaceService.ProcessReceipt on the server to confirm and grant the reward. Do not use PromptGamePassPurchase for consumable packs; briefly explain when Game Pass would be appropriate, but implement Developer Products in this system. Generate the main implementation as a server Script named CurrencyService.server.lua, to be placed in ServerScriptService. It must be self-contained and automatically create, if missing, the necessary RemoteEvents in ReplicatedStorage inside an organized folder, for example ReplicatedStorage/Remotes/Currency. If the recommended architecture requires auxiliary code, you may include at most one complementary ModuleScript, clearly identifying its name, type, and exact location in the Explorer. Do not deliver pseudocode or incomplete snippets. The Script must implement, at minimum: 1. Loading, creation, and persistent saving of soft and premium currency balances with DataStoreService, using UpdateAsync when appropriate, pcall, controlled retries, and failure handling without overwriting valid data. 2. A player data structure on the server and values replicated only for UI, preferably in leaderstats or in a clearly identified PlayerData folder. Replicated values must never be the source of truth. 3. Clear internal APIs, such as AddSoftCurrency, SpendSoftCurrency, AddPremiumCurrency, and SpendPremiumCurrency. Spending must be atomic in the server context: never allow negative balance, double charging, or duplicate granting. 4. A RemoteEvent for the client to request purchasing an item with internal currency. The client must send only an item identifier; price, currency type, balance, ownership, and purchase effect must be defined and validated exclusively on the server by a catalog table. Include item examples with both currency types and leave comments indicating where to edit. 5. A RemoteEvent to request opening a Developer Product purchase. The client must never state how many Gems they will receive or the price; it may only send an allowed ProductId. Validate the ProductId in a server reward table before calling PromptProductPurchase. 6. A robust implementation of MarketplaceService.ProcessReceipt that grants Gems only once per PurchaseId. Persist processed receipts in DataStore, return PurchaseGranted only when the grant has been confirmed, and return NotProcessedYet in temporary failures so Roblox can try again. Consider the possibility that the player is offline during delivery and explain, in comments, the strategy adopted for that. 7. UI update events and success/error responses that do not expose sensitive data. Every RemoteEvent input must go through type validation, size limits, basic per-player rate limiting, and state checks. 8. PlayerAdded and PlayerRemoving, saving in BindToClose, and connection/cache cleanup to reduce data loss and memory leaks. Follow Roblox security best practices rigorously: the server is authoritative; never trust the client for damage, currency, inventory, prices, disallowed IDs, or payment confirmation; validate all arguments received by RemoteEvent/RemoteFunction; do not use loadstring; do not expose keys, tokens, or external services. Do not use DataStore in LocalScript. If ProcessReceipt already exists in the provided context, do not silently overwrite the callback: show an explicit integration strategy through a product router/dispatcher. Deliver the answer in this order: (1) a quick overview of the architecture and created objects; (2) the complete Luau code, commented and ready to paste, obligatorily inside a markdown ```lua block; (3) an objective list of IDs, tables, and names I need to customize; (4) step-by-step instructions to test in Roblox Studio, including publishing to a test experience, configuring Developer Products, enabling API Services for DataStore in the appropriate environment, and how to simulate the purchase without manually granting currencies from the client. Ensure compatibility with current Luau and prioritize readability, optional typing, and professional maintainability.
