The StudioDojo pipeline
StudioDojo teaches the process real studios use to take a game from an idea to something people can play. It is the top rung of our maker-ladder — after building a place (BrickTots), making a fair course (ObbyPals) and editing a level (WorldForge), StudioDojo is about designing and shipping.
The five steps
- Scope. Say your game in one sentence, pick the one core verb, and write the win condition. If you can’t say it simply, it isn’t scoped yet.
- Build. Choose only the parts your core loop needs (2–4), the rules that make the goal reachable (2–3), and one safety/fairness choice you make on purpose.
- Playtest. Print the rubric and watch three real people play without you explaining. Where do they get stuck? When do they lean in?
- Revise. Change one thing your playtest pointed at — not five. Then playtest again.
- Ship. You leave with two files: a compact design code you keep, and a real Roblox Studio (Luau) starter.
The coach only asks
StudioDojo’s coach never writes your game or hands you an answer — it asks the questions a good mentor asks, and the design stays yours. That’s deliberate: designing is a skill you build by making the decisions yourself.
The Studio bridge
When you ship, StudioDojo generates a Luau project starter — a commented script with an idiomatic snippet for each rule you chose. It is a starting point, not the finished game. Open Roblox Studio, add your parts, paste it into a Script, and grow it. Nothing uploads; the starter is yours to build on.
A design is a file you keep
Your design code (a short sd1-… line) captures your whole design. Save it, paste it back anytime to reopen, or share it. It lives only on your device — no account, nothing sent anywhere.
What it teaches (and what we don’t claim)
StudioDojo is practice in the game-design process and the discipline of designing for a player, not for yourself. We make no claim it raises IQ or makes you an entrepreneur — it’s an honest studio for learning how games get made and shipped.
Where this idea comes from
Playtest early: the playcentric way
Tracy Fullerton’s textbook Game Design Workshop (first edition 2004, with Christopher Swain and Steven Hoffman) teaches designers to put players in front of the game from the first rough version and keep doing it, instead of designing for months and testing at the end. From its second edition (2008) the book calls this a “playcentric” approach.
One thing to hold: A paper prototype: the game drawn on cards and paper, played by people before any code exists. Carolyn Snyder’s book Paper Prototyping (2003) shows how teams test software ideas the same way.
Why it matters: Players do things designers never expect. A cheap test in week one finds the problem while it is still cheap to fix, which is why studios watch a few real players early rather than one big test late.
What we don’t know: How many testers are enough is argued. Jakob Nielsen’s rule that five users find most usability problems (2000) is widely quoted and widely disputed; game designers mostly say test often with a few people rather than once with many.
Dates:
- 2000 Nielsen argues five test users find most usability problems.
- 2003 Snyder’s Paper Prototyping collects the methods for software.
- 2004 Game Design Workshop’s first edition teaches playtesting from the first prototype.
- 2008 The second edition calls it “A Playcentric Approach”.