A Finished Small 2D Game Released on itch.io with a Playtest Log

The problem: most first games are never finished

Almost every student who wants to make games starts a large project, adds features before the core mechanic is fun, and stops halfway. The result is a folder of unfinished prototypes and nothing a studio or player can actually play. Postmortems on itch.io from jam and hobby developers repeat the same lessons: over-scoping, too little playtesting, and export problems discovered at the end.

A small game that is finished, released and shaped by real player evidence shows more skill than a large one that is not. It covers the whole pipeline: design, programming, art and audio integration, builds and release.

What already exists and the gap

• itch.io hosts hundreds of thousands of small games and jam entries, and gives any developer a free page with web and desktop builds.
• GMTK Game Jam and similar jams force a finished game in a few days, which is great practice but leaves no time for proper playtesting.
• Godot's "Your First 2D Game" tutorial and Unity Learn pathways teach the engine, but they end with the tutorial's game, not yours.

What is missing for most students is a structured project that forces completion and evidence: a design document with an out-of-scope list, three planned playtest rounds with new players, a public release and an honest post-mortem. That structure is what this FYP provides.

What you build

One small 2D game built around a single mechanic you can describe in one sentence (for example, "you can only move when the music plays" or "every jump flips gravity").

• Player: plays from a start menu through levels or an endless mode, can pause, restart and change volume.
• Playtester: plays without help while you observe and take notes.
• You as designer: turn observations into changes and record what happened.

The final artefact is a public itch.io page with a web or desktop build, credits and a devlog post.

The technically interesting part

For a beginner project, the interesting part is discipline and evidence, not a clever algorithm.

• Greybox first. Build the mechanic with coloured rectangles and make it feel good (input response, jump arcs, camera) before any art. Keep a short "feel" changelog of tweaks such as coyote time and jump buffering.
• A real playtest method. Say nothing while people play, note timestamps where they get stuck, bored or delighted, and ask the same three questions afterwards. Turn notes into a prioritised list and change only the top items between rounds.
• Release engineering. Automate exports, test on another machine, and upload with itch.io's butler tool so each build is versioned.

Show your supervisor two design changes that came directly from player evidence, with before and after clips.

How to evaluate it

• Completion: every item in the design document is either shipped or explicitly cut, with reasons.
• Playtest improvement: track one or two numbers across rounds, such as the share of players who finish level three or the average number of deaths on the hardest level.
• Release quality: the build runs on a machine without the engine, and in two browsers for web builds.
• Credits and licences: every asset listed with its licence; no NonCommercial or unclear sources.

Suggested plan

1. Week 1: design document, out-of-scope list, engine choice.
2. Week 2: greybox prototype of the core mechanic.
3. Weeks 3 to 4: levels or endless mode, menus, restart, first playtest round.
4. Weeks 5 to 6: art and audio, second round, fixes.
5. Week 7: third round, polish, release on itch.io.
6. Week 8: post-mortem and report.

Path to a product

This is a learning project first, but it can still earn. itch.io lets you set a price or pay-what-you-want, and a polished small game can become the demo for a larger version on Steam. More often, the release is your proof that you can ship, which is what studios look for in junior hires. The marketing guidance in the resource below applies even at this size.

Scope warning

No multiplayer, no procedural generation, no custom engine, no story with cutscenes. One mechanic, five levels or an endless mode, and polish. If you finish early, add stretch goals rather than new mechanics.

Learn what you need on Sefism

• Godot Docs: Your First 2D Game : a complete small game to learn the engine before your own.
• Kenney Game Assets : CC0 art and audio you can use without licence worries.
• jsfxr : quick sound effects for jumps, pickups and hits.
• GMTK Game Jam : a public jam for the stretch goal comparison.
• How To Market A Game : writing a store page and getting players to your release.
• Programming roadmap : the fundamentals you need before an engine makes sense.

Get help with this idea

The hardest part of this project is saying no to features. Tauseef can help you choose a core mechanic small enough to finish, plan the three playtest rounds, and frame the report so examiners reward polish and evidence rather than size. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session