AI Game Jam Guide: Scope, Rules, Judging, and Submission Checklist

An AI game jam needs more than a theme and a deadline. Organizers should define what participants may bring in, how AI use must be disclosed, which rights each team must hold, what judges will evaluate, and what evidence makes a submission valid.

This article is a neutral planning framework for community organizers and participants. It does not announce or imply that SEELE AI is currently hosting a game jam. Use it to draft rules for your own event, then adapt the language to your community, jurisdiction, platform, and review capacity.

Define the theme and boundaries together

A theme should create a design constraint, not merely suggest an art style. “Only one safe place,” “the map remembers,” or “every action has a cost” can influence mechanics, level structure, and narrative.

Publish boundary examples with the theme:

• What interpretations are clearly in scope?
• What content is prohibited?
• Are teams allowed, and what is the maximum team size?
• Can participants use pre-existing code, templates, or assets?
• Must all game-specific work begin during the jam?
• Which engines, platforms, and export formats are accepted?
• What accessibility or content-warning information is required?

If rules allow pre-existing tools or assets, require teams to identify them. The goal is not to punish reusable infrastructure; it is to judge the work completed under the same disclosed conditions.

Scope a 48-hour game around one proof

For a 48-hour jam, the project should prove one player experience. A useful scope has:

• One core verb or tightly connected pair of actions.
• One short onboarding path.
• One complete win, loss, or ending state.
• One visual system that keeps the game readable.
• One tested build target.

A practical schedule:

Hours 0–4: interpret and choose

Generate several interpretations, select one player promise, identify the largest technical risk, and define a kill list. Do not spend the opening hours polishing a logo or writing lore the build cannot support.

Hours 4–16: prove the core loop

Build the smallest playable version with temporary or properly licensed assets. Test input, camera, collision, objective, and restart behavior. If the loop is not understandable, reduce scope before adding content.

Hours 16–30: make a complete path

Add onboarding, one progression step, an ending, basic audio where rights allow, and readable UI. Keep a stable checkpoint build before major changes.

Hours 30–40: test and cut

Test on the required device or browser. Fix blockers first. Remove features that threaten completion. Record known issues rather than hiding them.

Hours 40–48: package and verify

Export, test from a clean environment, prepare disclosure and credits, capture truthful media, and submit before the deadline. Reserve time for upload failures and permissions.

Write explicit AI-use rules

“AI allowed” is not a complete rule. Specify which uses are permitted, restricted, or prohibited. Categories may include:

• Ideation and planning.
• Code suggestions or debugging assistance.
• Image, animation, audio, voice, or text generation.
• Asset editing and variation.
• Automated playtesting or analysis.
• Submission-page writing.

Require a disclosure that identifies the tool, stage, material generated or assisted, and human review. Do not require participants to publish secrets, private prompts, credentials, or proprietary data.

A compact disclosure can use this format:

Tool or model:
Stage used:
Input type:
Output used in the submission:
Human changes and verification:
Rights or license check:

Organizers should also state whether judges evaluate AI use itself or only the resulting game and process. Participants should not receive hidden penalties for a disclosed use that the rules explicitly permit.

Set rights, safety, and attribution requirements

Require teams to submit only material they have the right to use. This includes music, fonts, models, images, code, voices, trademarks, and training or reference inputs where applicable.

Rules should cover:

• License and attribution requirements for third-party assets.
• Treatment of fan work and protected characters.
• Privacy and consent for recorded voices, faces, or personal data.
• Prohibited harmful or illegal content.
• Disclosure of AI-generated or AI-assisted material.
• A process for reporting a rights or safety concern.
• Organizer authority to hide or disqualify a submission when evidence is missing.

Do not promise that a tool's output is automatically safe to publish. Participants remain responsible for reviewing their submission.

Use a judging rubric that rewards a finished idea

A balanced rubric for a short jam can use five equally weighted categories:

Publish scoring anchors. For example, a top theme score requires the theme to shape both mechanics and player decisions; a low score means the theme appears only in surface presentation.

Decide tie-break rules before judging. Organizers can use a designated category, a short judge discussion, or a shared-award policy. Do not invent a popularity metric after seeing the entries.

Require evidence that judges can access

A valid submission should include:

• Title, team members, and contact method.
• Short description and theme interpretation.
• Playable build or accepted downloadable package.
• Supported platform and controls.
• Estimated play time.
• AI-use disclosure.
• Third-party asset credits and licenses where required.
• Content warnings and accessibility notes where relevant.
• Known issues.
• Two or three truthful screenshots and an optional short capture.
• Source link only if the rules require it.

Test links in a signed-out browser. A private cloud link, expired build, missing executable, or access-request page can make judging impossible. State whether organizers will allow fixes to packaging errors after the deadline and whether such fixes may change game content.

Submission checklist

Before the deadline, participants should verify:

• The game starts from a clean install or signed-out browser.
• Controls and objective are visible.
• Win, loss, restart, and quit paths behave as described.
• The submitted version matches the stated build number.
• No placeholder claims or fake gameplay appear in the listing.
• Screenshots come from the submitted build and are not presented as features that do not exist.
• AI use is disclosed according to the rules.
• Third-party assets are credited and permitted.
• Team roles are accurate.
• Known issues are listed.
• Content warnings are present where needed.
• All links and permissions work.
• The submission was received before the stated deadline and time zone.

Plan the post-event showcase before launch

A showcase should preserve context, not just announce winners. Ask participants for permission to feature their game, media, credits, and process notes. Keep the original build status visible and do not rewrite participant claims as organizer endorsements.

Useful post-event outputs include:

• A gallery of eligible entries with consistent metadata.
• A judge note tied to the published rubric.
• A short organizer retrospective about rules and operational issues.
• Optional creator case studies that show scope decisions and iteration.
• An archive date and policy for broken builds.

The game creator portfolio guide helps participants turn an entry into an evidence-based case study. The game development devlog guide provides a structure for a midpoint update and retrospective.

Organizer rules checklist

Before announcing an event, confirm:

• Theme, dates, deadline time zone, and eligibility are explicit.
• Team size and pre-existing work rules are explicit.
• AI uses are categorized and disclosure is required.
• Rights, safety, privacy, and attribution rules are published.
• Build formats and judge access requirements are testable.
• The rubric and tie-break process are public.
• Packaging-fix policy is decided.
• Moderation and dispute contacts are assigned.
• Showcase permissions are collected.
• No sponsor, prize, judge, partner, or product capability is claimed before confirmation.

A creator path for community organizers

A community organizer with an original event framework, tutorial, public recap, or other useful contribution can review the SEELE Creator Program guide. The program accepts proposals from community builders, but acceptance and format should not be assumed.

Check the official SEELE Creator Program page for current terms, then propose the contribution, intended audience, evidence, and publishing destination. This CTA is an invitation to apply to the program, not an announcement that SEELE is running or sponsoring your event.

FAQ

Is SEELE AI currently hosting the game jam described here?

No. This article is a planning framework and does not announce a SEELE-hosted event.

Should an AI game jam require prompt disclosure?

Require useful process disclosure, but avoid forcing participants to reveal secrets, private data, credentials, or proprietary material. Tool, stage, output use, human changes, and rights review are usually more important than every prompt word.

Can participants use pre-existing assets or code?

That depends on the published rules. If allowed, require disclosure and valid licenses so judges can distinguish reusable infrastructure from work completed during the jam.

How should judges score AI-assisted work?

Publish the policy in advance. Judges can score the resulting interaction, theme, completeness, communication, and process documentation without inventing hidden penalties for allowed, disclosed tools.

What should happen to entries after the event?

With creator permission, archive eligible entries with accurate credits, disclosures, build status, and rubric-based notes. Plan how broken links and later updates will be labeled.