Common mistakes in a first playable build
A first playable is a toy you can fail at, not a costume of every menu. The mistakes that make the build impossible to judge.
A first playable is the earliest build where a person can fail at the interesting verb. Not a menu, not a gray room with a slide deck, not every system you hope to have by the end. If someone can jump, shoot, sneak, or stack, and the failure teaches them something, you have a playable. Most first builds fail that test because the team built a tour of intentions instead of a toy.
The vertical slice costume
Teams hear that they should make a slice and then build a thin costume of the final game: title screen, options, two unfinished modes, a map that is a corridor of signs. None of it is fun, and all of it is expensive. A first playable can be ugly. Scope versus polish in a small game is about finished work. This is earlier. You are allowed to be unfinished. You are not allowed to be unjudgeable. If a player cannot tell whether the toy is fun, the build is a progress report, not a playable.
Teaching inside the toy
A paragraph of instructions on a whiteboard next to the keyboard means the camera and the prompt failed. Put one line in the world, or a control that is obvious because the object affords it. Then shut up. Watch. Every extra system you add before the first system is readable is a place for the player to get lost. UI readability in small indie games matters even in a prototype. A prototype is still a surface someone has to read under pressure. Huge debug numbers all over the screen are for you. Hide them for the guest.
Content instead of the loop
A common mistake is authoring ten rooms before one room is worth repeating. The loop is the product. The second room is a reward for a loop that already works. Gray boxes are fine if the collision is honest. Pretty boxes that you fall through are a trailer. Why characters often use capsule colliders is the sort of invisible truth that makes a gray room fair. Spend the hour on the jump you will still have at the end, not on a skybox you will replace.
Save, restart, and the fragile demo
If the only way to show the game is a practiced sequence that crashes on a wrong button, you do not have a playable. You have a magic trick. Add a fast restart. Survive a wrong button. Decide what happens when the player falls out of the world, even if the answer is a rude respawn. What Does a Game Engine Actually Do Every Frame? will keep happening after your scripted path ends. The build should too. A crash on the unexpected path is the first bug worth fixing, ahead of the next feature.
Who the build is for
A first playable for the team can expose debug keys. A first playable for a teacher, a friend, or a playtest cannot. Know which one you are making this week. The mistake is handing the debug build to a stranger and then explaining the game with your voice for twenty minutes. If your voice is required, the build is not ready for that stranger. Make it ready, or keep it internal. Both are respectable. Pretending they are the same hour is how you collect useless feedback about your instructions instead of your toy.
Frequently asked questions
How long should a first playable be? Long enough to fail and try again a few times. Often that is a minute of toy, not a level. Stop when more content would only repeat an unproven verb.
Does ugly art invalidate the test? Only if the ugliness prevents reading the action. Placeholder can be clear. Placeholder that hides the hazard is a false test of the design.
Should we add multiplayer before the single player is fun? Almost never. Two people feeling a broken verb is not twice the data. It is the same data with scheduling pain.