> For the complete documentation index, see [llms.txt](https://studio-docs.sandbox.game/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://studio-docs.sandbox.game/game-jams/game-jam-judging-rules.md).

# Game Jam Judging Rules

The Sandbox hosts recurring Game Jams, governed by standardized evaluation guidelines. Participants are advised to review these criteria thoroughly prior to submitting their work.

Active and upcoming competitions are listed on the official Game Jam schedule: <https://luma.com/calendar/cal-N1dcwpx1CrY8tOE>

## **Game Jam Judging Rules**

All eligible submissions will be evaluated using the same judging criteria and process.

### **Eligibility**

#### **Jam Development Period**

Development of the submitted game must begin during the official Game Jam period.

Games published or publicly available before the Game Jam start date are not eligible, including modified, expanded, or updated versions of previously released games.

Creators may use existing creator-owned assets, reusable systems, templates, code libraries, tools, and other general-purpose content as building blocks. These materials do not need to be created during the Jam, but the submitted game itself must be developed during the official Jam period.

The Sandbox may request reasonable evidence of development timing when a submission's eligibility is questioned.

### **Evaluation Time**

Judges will allocate an initial evaluation window of approximately 5 minutes per submission, beginning when the experience launches.

We may, and frequently do, continue playing beyond the initial evaluation period when a game gives us sufficient reason to engage more deeply. Additional playtime is at the judge's discretion and is not guaranteed.

Loading, menus, cinematics, tutorials, exposition, onboarding, and gameplay all count toward the initial evaluation period. Judges are not required to extend a session to compensate for content that delays access to the core experience.

The 5-minute evaluation window is not a target game length. Games may contain significantly more content, progression, or depth. The opening experience should give players a clear reason to continue playing.

### **Design for the Judging Window**

Creators should get players into meaningful gameplay as quickly as possible.

The core gameplay, strongest ideas, and overall quality of the experience should become apparent during the initial evaluation period. Games may reward continued play with additional mechanics, progression, content, or depth, but should not rely on extended play before the core experience becomes clear and engaging.

Judges are not required to:

* Complete the game or replay it
* Reach every level, area, mechanic, upgrade, or feature
* Continue playing specifically to reach content introduced later

Pacing, onboarding, clarity, and engagement are part of the experience being evaluated.

### **Judging Criteria**

The criteria below provide the general framework used to evaluate Game Jam submissions.

Individual Game Jams may adapt, replace, or add criteria to reflect the specific theme, goals, or intended experience of that Jam. Any Jam-specific criteria will be defined in the competition brief and will apply consistently to all eligible submissions.

#### **1. Gameplay & Engagement**

How compelling and enjoyable is the core experience? Are the mechanics satisfying, readable, and well-paced? Does the game encourage continued play?

#### **2. Creativity & Originality**

Does the game demonstrate creative thinking through its concept, mechanics, systems, presentation, or use of Studio's capabilities?

#### **3. Polish & Execution**

How well is the game built and presented? Consider controls, responsiveness, stability, visual and audio presentation, bugs, and overall craftsmanship.

#### **4. Scope & Completeness**

Does the experience feel complete and appropriately scoped for what it is trying to achieve? Ambition is valuable when it is successfully executed, but larger scope or more content is not inherently better.

#### **5. Use of Theme**

How effectively and creatively does the game incorporate the Jam theme into the experience?

#### **6. Design & Cohesion**

Do the mechanics, level design, progression, onboarding, presentation, and other elements work together as a coherent experience?

Judges evaluate the submitted experience, not the amount of development time, content, or complexity behind it.

### **Judge Notes**

Creators may provide brief Judge Notes containing:

* Controls or critical setup information
* Approximate intended session length
* Up to three notable mechanics or features

Judge Notes provide context only. Judges are not required to reach or evaluate every feature listed, and descriptions do not substitute for functionality available in the submitted game.

### **Technical Requirements**

Submissions must be playable in the supported Sandbox Studio environment during judging.

Judges may restart or retry a game after a crash, failed load, or blocking bug when reasonable. Persistent technical problems may affect the evaluation, and judges are not required to repeatedly restart a game or work around significant issues.

Creators are responsible for ensuring that their submitted build and any permitted external services or dependencies remain functional during judging. Content that cannot be reliably accessed may not be considered.

### **Submitted Version and Updates**

Judging will be based on the submitted version of the game.

The final competition rules will define whether post-deadline updates are permitted and, if so, what changes are allowed. The same rules will apply to all participants.

### **What Judges Evaluate**

Judges evaluate the submitted playable experience.

Trailers, screenshots, descriptions, Judge Notes, development history, or explanations of intended functionality may provide context, but do not replace functionality that is absent, inaccessible, or not demonstrated in the game.

### **Prizes and Final Decisions**

The final competition rules will define whether a submission may receive multiple awards and how tied scores are resolved.

Judging decisions and subjective scoring are final. Factual errors involving eligibility, rule application, prize allocation, or the judging process may be reviewed by The Sandbox team.

### **Conflicts of Interest**

Judges will not evaluate submissions they materially contributed to or where another significant conflict of interest exists.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://studio-docs.sandbox.game/game-jams/game-jam-judging-rules.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
