The Nibblebit Challenge

Make one tiny game. All the way.

You want to make games. Good. For this challenge, make the smallest thing you can actually finish.

If you have never finished a game, “start small” doesn't tell you much. The stars below give you a minimum. Everything else waits.

The challenge is to finish the stars. Code, no-code, AI, free assets, ugly rectangles, whatever. Use whatever gets you through the list and into a build another person can play.

This chart is the challenge. Do the starred cards. The crossed-out cards are for later. Tap or click a star for its definition of done.

★ = required Follow the stars. Park the rest.

timeline LR
  Concept : ★ Pick tiny game idea
          : ★ One-page GDD
          : Lore bible
          : 20-page GDD
  Product : ★ Start screen
          : Settings menu
          : Save slots
  Gameplay : ★ First level
           : Second level
           : Skill tree
  Content : ★ Win / Lose screen
          : ★ Credit roll
          : Cutscenes
          : Voice acting
  Platform : ★ Web OR PC build
           : Mac + Linux
           : Console port
  Distribution : ★ Publish on itch.io
               : Steam page
               : Other storefronts
  Marketing : ★ Post it to strangers
            : Trailer
            : Press kit

The stars are the minimum. Pick the idea, write it down, then keep moving across the chart.

JavaScript is off. The minimum path is: pick a tiny game idea → one-page GDD → start screen → first level → win/lose screen → credits → web or PC build → itch.io → post it to strangers.

Do the stars once. Then you know what a complete trip from idea to release actually looks like.

Rules

Do every starred task before adding anything else.
If the engine or code starts becoming the project, simplify or switch.
Use existing assets when they save time.
Pick one engine and one target platform. Then stop comparing.
Write new feature ideas down somewhere. Don't add them yet.
Use tutorials to solve the problem in front of you, then go back to the game.

Keep the wins close together. Movement works. Good. Make the start button work. Then the lose condition. Then export it. If one task needs three evenings before anything works, make the task smaller.

What counts as done

Concept0. Pick a tiny game idea

Pick something boringly small. Familiar is fine. It only needs enough of a loop that somebody can play it for a minute and maybe want another go.

Cloning is fine. Snake is fine. Pong is fine. This one is about finishing a game.

Good first-game targets:

Snake — move, eat, grow, avoid hitting yourself.
Breakout — paddle, ball, bricks, clear the screen.
Pong — two paddles, one ball, small score target.
Flappy Bird — one input, avoid gaps, count distance.
Sokoban — one small room, push a crate onto a goal.
Whack-a-mole — click the target before it disappears.
One-screen dodger — survive for thirty seconds.
Collect-and-exit — collect three things, reach the exit.

Clone the mechanic. Use your own name and assets.

Avoid these for game one:

3D. 2D is enough to learn input, state, collisions, UI, assets, builds and releases. Those skills transfer.
Multiplayer. Networking, extra input paths, synchronization and testing multiply the work.
Physics-driven games. Simple collision rules are fine. Do not make physics simulation the core mechanic.
Story-heavy games. Writing, dialogue, pacing and content quickly become most of the project.
Complex puzzles. One simple puzzle is fine. A progression of tightly designed puzzles grows into a much bigger project.
RPG systems. Skip inventories, crafting, equipment, quests, skill trees and economies.
Procedural generation. Hand-make one small level.
Complex enemy AI. Straight lines, simple patrols and basic chasing are enough.
Open worlds, sandboxes and simulations. They create scope faster than they create a finished game.
Games that need lots of content. Avoid designs that only become fun after dozens of cards, levels, items or encounters exist.

If you're already explaining why your idea is actually simple, it is probably too big. One screen. One loop. One sentence.

Concept1. One-page GDD

Write the game down on one page anyway. Even if you're cloning Pong. Explain your version in your own words.

What do you play as?
What does the player do every few seconds?
What is fun for the player?
How do they win or lose?
Why might they play again?
What engine are you using?
Where do the assets come from?
What platform will you build for?
Where will somebody play or download it?

A useful Sid Meier-style check: look at the game from the player's side. Describe what the player is actually doing and where the fun comes from.

If you need an engine starting point, the no-code options below are valid. If you already want a conventional engine: Godot's first 2D game, Unity Learn, or Unreal for new users.

Later: lore, character biographies, concept art, DLC, sequels and reusable frameworks.

Product2. Start screen

When the game opens, the player should know the title, the controls and how to start.

Game title
Author name
Control scheme
A clear start action

Later: save slots, accounts, settings, custom keybindings, splash screens and logo cinematics.

Gameplay3. First level

Build one complete gameplay loop: start, play, end. Thirty seconds is enough if the player can do the main thing and reach a win or lose condition.

Get movement working. Then the interaction. Then the ending. Don't build the next five systems while the first one is still half done.

Later: level two, skill trees, crafting, procedural generation, more enemy types and boss fights.

Content4. Win / Lose screen

When the game ends, say so. Show a win or lose state. If the game has only one terminal state, build only that one.

Later: cutscenes, elaborate transitions and ending cinematics.

Content5. Credit roll

Credit yourself and the authors of the assets that made it into the build. Check the licence for each asset and follow its attribution requirements.

Include reused code, images, fonts, sound, music, writing and anything else that came from somebody else. If you used AI, state what it was used for.

Platform6. Build for Web or PC

Pick one target. Export the game and run the exported build yourself. If it only works inside the editor, you do not have a release yet.

Later: other desktop platforms, installers, mobile, consoles or moving the game to another engine.

Distribution7. Publish on itch.io

Create an itch.io page, add a short description, upload the game and make it public. For a web build, publish it as an HTML game. The creator guide and HTML5 docs cover the details.

Later: Steam, other storefronts, localization, trailers, press kits and a polished store page.

Marketing8. Post it to strangers

Put the public link somewhere people who do not know you can see it: Reddit, a game-dev Discord, Tumblr or a forum. Say what it is and ask people to try it.

Don't turn this into a marketing project. Put the link somewhere a stranger can actually find it. That's enough.

No-code is fine

If programming is eating the whole project, use something else. Visual events are fine. The challenge only cares whether you finish the game.

GDevelop — open-source, visual events, ready-made behaviours and web/desktop publishing. Its showcase includes SPECTRUM and Stranded on a Raft.
Construct 3 — visual event sheets and a quick route to small 2D/browser games. There Is No Game was built with Construct.
GB Studio — drag-and-drop and visual scripting, with web and Game Boy export.
Bitsy — tiny exploration and dialogue games with HTML export.
GameMaker — visual/low-code tooling with a much larger ceiling; its showcase includes games such as Undertale.

Use the simplest tool that gets you through the list.

Godot, Unity or Unreal

Already know one? Use it. Otherwise pick one and move on. You only need the tiny corner of the engine required by this game.

Godot — a good fit for a small 2D game. Its official beginner tutorial builds a complete game.
Unity — useful if you already know the workflow or have a suitable template.
Unreal Engine — use templates, Blueprints and existing assets; ignore the features your game does not need.

If learning the engine becomes most of the project, simplify or switch. You can always come back later.

Learn only what the next step needs

Use tutorials when you hit a problem. Learn the bit you need and go back to the game. You don't need to finish a course first.

Practical tutorials

GDevelop Academy — project setup through publishing.
Beginner's guide to Construct 3 — builds a complete small game.
GB Studio: Getting Started — start from the sample project and get something running quickly.
Godot: Your first 2D game — a complete beginner project.
Unity: Create with Code — broad beginner material; use the parts relevant to your current problem.
Unreal: Your First Hour — basic project creation, Blueprints and packaging.

GDC talks

How to Survive in Gamedev for Eleven Years Without a Hit — Jake Birkett — a useful perspective on making and releasing games repeatedly.
Failure Workshop — GDC 2017 — developers discussing projects and decisions that did not work.
Juice It or Lose It — Martin Jonasson & Petri Purho — how small feedback changes can make a simple game feel much better.
The Art of Screenshake — Jan Willem Nijman — another good example of improving feel with small changes.

On finishing and scope

Finishing a Game — Derek Yu — finishing as a skill of its own.
How Spelunky got its procedural hook & actually got finished — practical decisions behind getting Spelunky finished.
FINISH YOUR GAME — Rosstin Murphy — practical advice on getting a game into players' hands.

Assets and places to share

Kenney — game-ready art and UI.
OpenGameArt — art, music and sound; check each licence.
Freesound — sound effects with per-file licensing.
itch.io game assets — free and paid packs.
r/gamedev and Tumblr #gamedev — places to talk about the finished game.

Make the small game.

If Godot itself is still the blocker, Spawn Point is my free beginner game-dev webinar.

Join Spawn Point ↗

After the minimum

Once every star is done, expand whatever you want. Add another level, improve the art, write lore, add sound, localize it, port it, publish elsewhere, or start another game.

Do the minimum first. Once the core works you have something stable to change. You can play it, test it and show it to people. That is a lot easier than changing what “finished” means every time you think of another feature.

If you get stuck

Write down what already works, what doesn't, and three things you've tried. Then ask for help with that exact problem.