Developer Handbook.

This handbook is for everyone who makes the games and the platform: scripters, gameplay and backend engineers, builders, modelers, texture and concept artists, animators and riggers, VFX and lighting artists, sound designers and composers, designers, and the web team.

It sits on top of the Staff Handbook. Everything there about conduct, communication and safety applies to developers too.

Every piece of development work is a task with a brief, a deadline and acceptance criteria. Criteria come in two kinds, and both are written into the task before you start:

• Objective criteria can be checked: file formats, dimensions, naming, performance budgets, and whether it works as specified.
• Creative criteria need a judgment call, such as artistic fit or how a mechanic feels. These are signed off by the Project Director for the game, and anything not disclosed before you start cannot be held against your work.

Larger pieces of work, such as a character model or a soundtrack, move through a set of production stages. Each stage is recorded as it is reached, so the whole team can see where things stand without having to ask.

If the brief is unclear, ask before you start. A question on day one is far cheaper than a rebuild on day ten.

• It works. Test your own work against the brief and the obvious edge cases before you submit it.
• It performs. Our games run on phones as well as PCs. Keep part counts, textures, scripts and effects within the budgets the brief sets.
• The server is in charge. Anything that affects gameplay, currency or progress is validated on the server, never trusted from the client.
• It is accessible. Readable text, sensible contrast and controls that work on touch as well as keyboard and controller.
• It is ours to ship. Do not include third-party assets, AI-generated content or material lifted from another product without written approval from the Project Director.

Review is how good work becomes great work, and revision is a normal part of every task.

• Feedback must point at the criteria that are not yet met and say what would meet them.
• Reviews are given promptly. If a review is late, the deadline moves with it.
• Respond to each feedback point. Engaging in good faith with feedback counts, even when a creative call goes the other way.
• If you disagree with feedback, say so directly to the reviewer or the Project Director, with your reasons.

Work made for Lucky 7 belongs to the studio, as set out in your agreement. That includes source files, project files, scripts, models, rigs, animations, interface files, audio and documentation.

• Studio code lives in private repositories. Never commit it, or any part of an unreleased game, to a public repository, a public model or a personal cloud account.
• Never commit keys, tokens, passwords or configuration secrets anywhere. If it happens by accident, tell us straight away and do not try to rewrite history alone.
• Keep unreleased places private, and do not change place privacy or publish anything without approval.
• Only request access to the repositories and places your work needs.

Many of our players are children, and safety is designed in, not bolted on.

• No game system may ask for, collect, store or pass on a player's personal information.
• All player text goes through Roblox's filtering. Do not build chat, signs, name tags or input boxes that get around it.
• Save data holds only what the game needs. A failed save or load must never wipe a player's progress.
• Monetization is honest and clearly labelled, and follows the platform's rules.

Developers have more access than most, so the security basics in the Staff Handbook matter most here. On top of them:

• Two-factor authentication is required on your Roblox and source control accounts before you are given access to source files or Studio sessions.
• Treat anything that handles sign-in, payments or personal data as high risk, and ask for a second pair of eyes.
• Never log, print or store a password, even while debugging.
• If you find a vulnerability, report it to the Cyber Security division rather than testing it further on live systems.

Game work happens in Roblox Studio, with Luau source kept in version control. Art, models and rigs are built in industry tools and exported to the targets each brief sets. Our website and internal tools are built with Next.js and TypeScript.

The studio has its own production tools for tasks, production tracking, scheduling and time tracking, and you will be shown them when you join. If a tool slows you down, tell us; most of ours were built because someone asked.

AI tools are only used where the studio has approved them, and never with complete source files, unreleased designs or confidential information.

We hire people who want to get better. You will get direct, specific feedback from people who have shipped games, and you will own real systems that players use.

Junior contributors work on real features alongside experienced developers, and the ones who consistently deliver are first in line when larger roles open. See Junior Internships.

This is the public edition of the Developer Handbook. Staff can read an internal edition, which adds the tools, procedures and contacts behind each section, from their dashboard after signing in.

Where this handbook and your signed contract or agreement say different things, your contract or agreement is what applies. Pay, payment timing and the terms of your engagement are covered in your contract or agreement, not here.

We review the handbooks when the way we work changes. Each edition carries a version number and the date it was last updated, and a change in substance gets a new version.

Questions about anything in it can go to support@lucky7entertainment.com.