Pick evidence you can explain
Show a mechanic that fits the role you want to discuss: readable controls, a risk-reward choice, or a puzzle clue that changes a route. Keep the prototype small enough that a reviewer can reach the central interaction quickly. Avoid presenting a generated artifact as evidence of code you did not write or of a production system you did not build.
Use a process brief
Example prompt: “Create a single-screen timing game with one button. A marker sweeps past a visible landing zone; press to stop it. A centered landing earns a point, a partial overlap gives no point, and a miss ends the run. Show the result immediately and let Restart reset the score and marker. Keep the sweep speed fixed.” In your portfolio notes, explain why the landing zone is the key variable, what test you ran, and one limitation you would address in a code-based version.
Review what a visitor can actually access
Test the public link in a fresh browser session and make sure the opening rule and main action are understandable. Add a short project note with your role, the question tested, and what the prototype can and cannot demonstrate. A public playable link is one artifact in a portfolio, not proof of implementation work you did not perform.
Because the game is public, do not include confidential employer work, unreleased client material, or personal information. Check the title, visible copy, and prompt-derived content before using the link in a professional portfolio.
Questions about portfolio game prototype
What can a public game link demonstrate?
It lets a reviewer try the interaction and see the player-facing result. Pair it with honest process notes about your role, the design question, and the testing you personally carried out.
What should I explain next to the prototype?
Describe your design question, the rule you tried, the test you ran, and one limitation. Concrete process notes are more informative than claiming a prototype proves broad expertise.