Making a game in a weekend
Two days is enough to finish a small game and nowhere near enough to finish a small version of a large one. Almost every unfinished weekend project is the second thing wearing the clothes of the first. The scoping decisions below are the difference, and all of them are made before any work begins.
Cut these before you start
A menu. Start in the game; add a title on the last afternoon if there is time.
Saving. A game that runs for six minutes does not need persistence, and persistence eats an afternoon.
More than one level layout. Build one space and make it good. If the game is procedural, build one generator and one set of rules for it.
Original audio, unless audio is the project. Silence is a legitimate choice and much better than half-finished sound.
Any system that requires a second system to be interesting. If the crafting only matters because of the economy, you are building two things.
Decide the verb first, in one sentence
Write down the single thing the player does, in the form you press a button and X happens. If you cannot write it, you do not have a project yet, you have a setting. Setting is cheap and can be added at any point; the verb cannot.
Then write the ending condition in one more sentence. A game with a stated ending can be finished. A game without one expands to fill whatever time remains, which on a weekend means it does not exist on Sunday night.
A shape for the two days
Saturday morning. Build the verb and nothing else. Grey boxes, no art, no feedback beyond what you need to see it working. By lunch you should be able to press the button and see the thing happen.
Saturday afternoon. Add the opposition: the thing that makes the verb a decision rather than a formality. A timer, an obstacle, a cost, another actor. Stop when pressing the button has stakes. This is the point at which you know whether the project is worth Sunday, and it is early enough to change plans.
Saturday evening. Play it for twenty minutes and write a list. Do not fix anything yet. Sort the list into things that stop it working and things that would make it better; ignore the second column entirely until Sunday afternoon.
Sunday morning. Fix the first column. Then build the ending, however plain — a score, a screen, a stop. Having an ending in place by lunch on the second day is the single strongest predictor of finishing.
Sunday afternoon. Now, and only now, spend on feel: screen shake, a sound, a colour, the pause before the score appears. This is where the largest apparent quality gain per hour lives, and it is wasted if spent earlier on a design that was going to change.
Sunday evening. Stop building. Write the two lines of instruction someone needs to start, test that it runs from a clean copy, and ship it. The last hour is always packaging, and projects that do not budget for it are the ones that never get sent to anyone.
What to do with the leftovers
Keep the list you wrote on Saturday evening. The second column — the things that would have made it better — is a design document written under real conditions, and it is far more useful than a document written before anything existed.
Most weekend projects should end at the weekend. A few will keep asking to be continued, and the ones that do are usually the ones where the second column is full of things you want to play rather than things you want to build. That distinction is worth trusting.