A strong game creator portfolio does more than display polished screenshots. It lets a reviewer understand the brief, your role, the decisions you made, the evidence you collected, and what changed because of that evidence. The finished game matters, but the process explains whether you can make another good decision on the next project.
For most creators, three focused case studies are more useful than fifteen unexplained thumbnails. Each case study should answer a simple question: what problem did you take responsibility for, and how can someone verify the result?
Choose projects for signal, not volume
Select projects that reveal different parts of your judgment. A compact portfolio might include:
- One playable prototype that proves a core mechanic.
- One iteration-heavy project that shows how feedback changed the design.
- One constrained project, such as a jam entry or short production brief, that shows scope control.
Avoid including several projects that all prove the same thing. If every entry is a visual concept with no playable evidence, the portfolio cannot show interaction design. If every entry is a code sample with no explanation of player experience, it cannot show product judgment.
An unfinished project can belong in the portfolio when the lesson is clear and the evidence is honest. Label its status. Do not present a mockup as a shipped game or a recorded sequence as a playable build.
Start each case study with the brief
A reviewer should understand the project in less than a minute. Open with a short brief:
- Player promise: what the player should feel or accomplish.
- Constraint: time, platform, team, asset, input, or technical limit.
- Your role: what you personally decided or produced.
- Success test: what observable result would make the prototype worth continuing.
For example, “Make a one-button climbing prototype readable without a tutorial in 48 hours” is more informative than “A fun platform game.” The first statement exposes the design problem and the constraint.
Document iteration as decisions
A process section should not be a diary of every action. Organize it around meaningful changes:
- Version: what the player saw or could do.
- Observation: what happened in a test or review.
- Decision: what you changed and why.
- Result: what became clearer, remained broken, or created a new tradeoff.
Use screenshots, short clips, changelog excerpts, sketches, or prompt excerpts only when they support that chain. A pile of artifacts without commentary makes the reviewer reconstruct the story themselves.
If a project spans multiple updates, the game development devlog guide provides a repeatable structure for publishing those decisions over time.
Show real playable proof
When the portfolio claims interaction, provide interaction evidence. The best option is a stable playable link with basic instructions and a clear platform note. If that is not practical, provide a short unedited capture that shows input, gameplay, failure, and recovery—not only a cinematic montage.
For each playable item, include:
- Supported browser, device, or engine build.
- Controls and expected session length.
- Known issues that affect the test.
- Build or version identifier.
- Date checked.
- A fallback video or image set if the build becomes unavailable.
Do not use a CSS mock, fake HUD, or hand-built phone frame as proof of gameplay. Those can illustrate layout ideas, but they cannot verify a playable claim. Label concept art, greyboxes, prototypes, and release builds accurately.
Make your role auditable
Team projects need a role statement. Name what you owned, what collaborators owned, and which tools or third-party assets were used. If AI assisted the work, disclose where it entered the process and what you changed or verified.
A useful role note might say:
Role: mechanic design, level scripting, playtest plan, and final edit.
Collaborators: original music by [name]; character model licensed from [source].
AI-assisted work: early visual exploration and draft code suggestions.
Human review: selected the final direction, rewrote interaction logic, tested builds, and cleared asset rights.This is not a defensive disclaimer. It helps the reviewer attribute the work correctly.
Write a retrospective with tradeoffs
End each case study with a short retrospective:
- What worked, based on visible or testable evidence?
- What did not work?
- Which constraint shaped the outcome most?
- What would you change in one more iteration?
- What did you deliberately leave out?
Avoid unsupported claims such as “players loved it” unless you can explain who tested it, what they did, and what you observed. Qualitative notes are valid evidence when presented as observations rather than universal conclusions.
Portfolio case study template
Project title and status:
[Prototype / jam entry / in development / released]
One-sentence brief:
[Player promise + core constraint]
My role:
[Specific decisions and deliverables]
Build information:
[Playable link, controls, platform, version, date checked]
Initial hypothesis:
[What you expected the player to understand or enjoy]
Iteration 1:
- Observation:
- Decision:
- Evidence:
Iteration 2:
- Observation:
- Decision:
- Evidence:
Third-party and AI use:
[Tools, assets, licenses, attribution, and human review]
Retrospective:
- What worked:
- What failed:
- What I would test next:Portfolio review checklist
Before publishing a case study, verify:
- The brief names a player promise and a real constraint.
- Your role is separated from team, tool, and asset contributions.
- Project status is accurate.
- A playable claim has playable proof or a clearly labeled fallback.
- Version and date information are visible.
- Iteration artifacts explain decisions rather than decorate the page.
- Failures and tradeoffs are included.
- Third-party assets have licenses and attribution where required.
- AI use is disclosed where relevant.
- No fabricated users, outcomes, rankings, revenue, or capabilities appear.
- Every external link works in a private browser window.
Turn a portfolio project into a contribution proposal
A well-documented case study can become a useful public tutorial, build log, or showcase. The SEELE Creator Program guide explains eligibility, rewards, and application materials. Apply with one focused project rather than your whole archive: state what you will build, what evidence you will publish, and who the contribution is for.
Community organizers can also use the AI game jam guide to define evidence and submission requirements that produce portfolio-ready entries. The guide is an organizing framework, not an announcement of a SEELE event.
Review the official SEELE Creator Program page before preparing a proposal.
FAQ
How many projects should a game creator portfolio include?
Start with two to four strong case studies. Add another only when it demonstrates a meaningfully different skill, constraint, or role.
Does every portfolio project need a playable link?
No. Art direction, writing, production, or research work may need different evidence. But if you claim to have designed a playable interaction, provide a build or an honest recording that shows the interaction.
Can I include an unfinished game?
Yes. Label its status and make the case study about the decisions, evidence, and next test rather than implying that it shipped.
How should I disclose AI-assisted work?
Name the stage where AI was used, the inputs or constraints you provided, what you changed, and what you verified. Do not credit an automated output as if it independently made design decisions.
Can a portfolio project support a SEELE Creator Program application?
Yes. A focused case study can demonstrate your proposed format and evidence plan. Check the official Creator Program page for current terms before applying.