Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/brockmartin/roblox-game-skill/llms.txt

Use this file to discover all available pages before exploring further.

The Publish Checklist is the final gate before your Roblox game goes public. It covers every category that separates a polished, trustworthy release from a launch that frustrates players and damages long-term retention: data integrity, security hardening, performance on mobile, monetization correctness, gameplay edge cases, metadata quality, social features, and analytics. Work through each accordion section end-to-end and confirm every item before pressing “Publish.” This checklist is also the right trigger for the Security Audit and Performance Audit workflows if those have not been run yet. Trigger: “Run the publish checklist”, “is my game ready to launch”, “pre-launch review”, or invoked at the end of the New Game workflow.
The three most common launch failures are: data loss on server shutdown (missing BindToClose handler), unvalidated RemoteEvents (currency exploitable on day one), and broken ProcessReceipt (purchases don’t grant items or double-grant on retry). Check those three items first before working through the rest of this list.

​
Checklist Categories

  • DataStore tested end-to-end — Save, load, and verify player data across multiple play sessions. Test with both new players (first join, no existing key) and returning players.
  • Session locking implemented — Prevent data corruption when a player appears in multiple servers simultaneously. Use a session lock key in DataStore that is claimed on join and released on leave.
  • BindToClose handler — game:BindToClose() saves all active player data before the server shuts down. Test by stopping a local server and verifying data persists on the next join.
  • DataStore error handling — All :GetAsync(), :SetAsync(), and :UpdateAsync() calls are wrapped in pcall with retry logic and fallback behavior (never leave the player in a broken state on DataStore failure).
  • Data versioning — Player data includes a version number so future schema changes can migrate old data gracefully without loss.
  • DataStore budget awareness — Requests stay within Roblox DataStore rate limits (60 + numPlayers × 10 per minute for GetAsync). No tight-loop saves triggered every frame or on every action.
  • OrderedDataStore for leaderboards — If the game has leaderboards, they use OrderedDataStore and update at reasonable intervals — not every frame or every second.
  • Backup/recovery plan — A strategy exists for recovering player data if corruption occurs (DataStore versioning keys, external backups, or a rollback script).
  • All remotes validated — Every OnServerEvent and OnServerInvoke handler type-checks, range-validates, and authorizes all arguments. See the Security Audit workflow.
  • No exposed sensitive data — ReplicatedStorage contains no server secrets, admin keys, or exploitable configuration. Sensitive modules live in ServerStorage or ServerScriptService.
  • Rate limiting on all remotes — Per-player cooldowns prevent spam-firing of RemoteEvents and RemoteFunctions.
  • Server-authoritative game logic — Currency, damage, inventory, and progression are computed on the server. The client sends intent, not results.
  • Anti-exploit measures — Speed checks, teleport validation, and/or server-side hit detection are in place for competitive games.
  • No client-side server logic — Modules in ReplicatedStorage or StarterPlayer contain no logic that should be server-only.
  • Mobile tested — The game runs at 30+ FPS on a mid-range mobile device, or mobile is explicitly unsupported with device restrictions set in Game Settings.
  • Part count reviewed — Total workspace BasePart count is within acceptable range for the genre. StreamingEnabled is configured if part count exceeds 10,000.
  • No memory leaks — Event connections are disconnected when no longer needed. Per-player data and connections are cleaned up in PlayerRemoving. Temporary instances are destroyed.
  • StreamingEnabled configured — If the game has a large map, StreamingEnabled is on with appropriate StreamingMinRadius and StreamingTargetRadius values.
  • No deprecated API usage — wait(), spawn(), and delay() are replaced with task.wait(), task.spawn(), and task.delay() throughout.
  • Service calls cached — game:GetService() is called once per script at the top level and stored in a local variable.
  • Network traffic reasonable — RemoteEvents do not fire every frame. Payload sizes are minimal. FireAllClients is used only when all clients genuinely need the data.
  • MicroProfiler reviewed — No single frame spike exceeds 16 ms (60 FPS target) or 33 ms (30 FPS target) during normal gameplay. Use Ctrl+F6 in Studio to profile.
  • GamePasses functional — All GamePasses can be purchased and benefits are granted correctly. Verified with :UserOwnsGamePassAsync() on both new and repeat purchase flows.
  • ProcessReceipt correct — MarketplaceService.ProcessReceipt is implemented, handles every Developer Product ID, saves the grant to DataStore before returning PurchaseGranted, and handles the player-offline case with NotProcessedYet.
  • Prices reviewed — GamePass and DevProduct prices are appropriate for the value provided and competitive within the genre.
  • Purchase prompts work — PromptGamePassPurchase() and PromptProductPurchase() are tested in a live (non-Studio) server environment.
  • Premium benefits active — If the game supports Roblox Premium, Players.PlayerMembershipChanged is handled and benefits are correctly granted and revoked.
  • No purchase-blocking bugs — Players can purchase at any point in the game flow without errors, UI conflicts, or lost items.
  • Touch controls implemented — All core interactions work with touch input. No interaction requires hover or right-click.
  • Scale-based UI — All UI uses UDim2 with Scale values (not Offset) for positioning and sizing, or uses UIAspectRatioConstraint and UISizeConstraint for consistent layouts across screen sizes.
  • ContextActionService for input — Mobile-specific input is handled via ContextActionService with proper touch buttons, not keyboard-only UserInputService bindings.
  • Safe area respected — UI elements do not overlap with the Roblox top bar, chat, or device notch/home indicator areas.
  • Text is readable — Font sizes are large enough to read on a phone screen (minimum 14 pt equivalent).
  • Buttons are tappable — Interactive UI elements are at least 44×44 pixels on mobile for comfortable touch targets.
  • Performance on mobile — Game runs smoothly on lower-end mobile devices. Graphics quality scales appropriately based on device capability.
  • Core loop tested — The primary gameplay loop (what players do repeatedly) works from start to finish without errors across multiple cycles.
  • Edge cases handled — Player death during transactions, disconnection during saves, empty inventories, maximum stack sizes, and similar edge cases are explicitly tested.
  • First-Time User Experience (FTUE) works — A brand new player can understand the game within the first 2 minutes. Tutorial, onboarding prompts, or intuitive design guides them through the first loop.
  • Progression tested — Early game, mid game, and late game progression all work. Players do not get stuck, hit dead ends, or find the difficulty wall unbalanced.
  • Multiplayer tested — If the game has multiplayer, test with 2+ real players. Verify shared state, competitive/cooperative mechanics, and edge cases involving multiple players acting simultaneously.
  • Error recovery — If a script errors mid-session, the player experience degrades gracefully rather than breaking entirely (no infinite loading screens, no stuck UI).
  • AFK handling — Players who go AFK do not break the game for others or accumulate unfair advantages (resources, leaderboard positions, etc.).
  • Respawn works — Character respawn is clean with no lingering state from the previous life (equipped tools destroyed, active effects cleared, event connections cleaned up).
  • Game icon — 512×512 pixel icon uploaded. Clear, recognizable, and representative of the game at small thumbnail sizes.
  • Thumbnails — At least 3 thumbnails (or a video thumbnail) that showcase the best and most exciting parts of the game.
  • Description — Clear, compelling description explaining what the game is, what players do, and why it is fun. Includes relevant keywords for Roblox search ranking.
  • Genre set — Correct genre selected in Game Settings (Adventure, RPG, Simulator, etc.).
  • Max players configured — Players.MaxPlayers is set appropriately for the game design and server infrastructure capacity.
  • Allowed devices — Playable devices are set correctly. If the game does not support mobile or console, access is restricted rather than allowing a broken experience.
  • Age rating — The Experience Guidelines questionnaire is completed accurately and reflects the game’s content.
  • Updates channel — A group page, social link, or community is set up for communicating future updates to players.
  • Private servers — If appropriate for the genre, private servers are enabled, priced (or free), and private server functionality works correctly.
  • Social features — Friend invites, group integration, or social sharing features work and are tested.
  • Chat filtering — Any custom chat or text display uses TextService:FilterStringAsync() for all user-generated content. Unfiltered text is a ToS violation.
  • Moderation tools — If the game has social features, basic moderation is in place (report, mute, kick for game owners and admins).
  • Group integration — If the game is tied to a Roblox group, group ranks and permissions work correctly for any rank-gated features or rewards.
  • Key events instrumented — Critical player actions are tracked with AnalyticsService or a custom analytics system: joins, session length, first-time vs. returning, tutorial completion, core loop engagement, purchase events, and churn indicators.
  • Funnel tracking — Key conversion funnels are instrumented (FTUE → first loop completion, shop visit → purchase, etc.).
  • Error logging — Script errors are logged with context (player, location, action) for debugging production issues without needing to reproduce them locally.
  • Performance metrics — Server FPS, memory usage, and network stats are monitored or logged so degradation over time is detectable.
Before pressing Publish, complete these five final checks:
  1. Play as a new player — Launch the game on desktop, mobile, and console (if supported) from a fresh account with no existing data.
  2. Check every checklist item above — All boxes checked before publishing.
  3. External playtest — Have at least one other person play and provide feedback. They will find things you missed.
  4. Live DataStore test — Confirm DataStore saves work in a live (non-Studio) test server. Studio DataStore behavior differs — always verify in production.
  5. Developer Console review — Open the Developer Console (F9) and play a full session. Review all errors and warnings logged during that session before going live.

Build docs developers (and LLMs) love

Get started for freeTalk to us