How to judge a game you did not code

Start with the thing that quietly stops people from doing this well. There is a widespread assumption that assessing a game requires understanding its implementation, and that anyone who did not write the code is offering opinions rather than findings.

It is not true, and it is worth being blunt about. Whether a game is good is decided by playing it. Every judgement that matters here is a judgement about experience: whether the controls answer, whether you understood what to do, whether you were bored at minute four, whether you wanted another go. None of those depend on knowing how the code is arranged, and none become more accurate if you learn.

People who write the code are in fact worse at some of this, because they know where the seams are and route around them without noticing. Coming to a game without that knowledge is closer to how everyone else will meet it.

What a review does need is method. Left to itself, playing your own project produces a fog of mild dissatisfaction that is impossible to act on. The rest of this is a way to convert that fog into a short list of specific things.

The first pass has one rule: start from the beginning, as though you had never seen it, and do not fix anything while you play. Not a value, not a typo, not the thing that irritates you in the first ten seconds. Play to the end of whatever exists.

Cold means a few practical things. Do not skip the opening because you have seen it forty times. Do not use the shortcut you built for testing. Do not start in the middle. Every one of those habits hides the part of the game that most new players will actually experience, which is the first two minutes.

Leave a gap first if you can. A day is enough, a week is better. Distance is what lets you see the thing rather than your memory of intending it, and it is the single cheapest improvement to the quality of your own feedback.

While playing, note times and nothing else. A line whenever something happens in you: confusion, boredom, surprise, irritation, the moment you stopped reading text, the moment you started skipping. Do not write causes yet. Just the clock and the reaction.

The second pass is the most uncomfortable and the most valuable. Put the game in front of somebody who has not seen it and keep your mouth shut.

Silence is the whole technique. The instinct to explain is enormous, and every explanation destroys the data you came for. If you have to say press E to pick things up, you have just learned that the game does not communicate that, and the moment you say it you cannot learn anything else about it. Write it down instead and stay quiet.

Watch their hands and their face more than the screen. You are looking for hesitation, for the direction they try first, for the button they press repeatedly hoping something happens, for the moment they lean back. People rarely report those things afterwards, because by the end they have solved the confusion and forgotten it existed.

Two or three people is enough to see a pattern. If all of them turn left at the same junction and you built the content on the right, that is not three opinions, it is one fact about your level. Watch for those repeats. They are the closest thing to certainty you will get.

Afterwards, ask open questions rather than leading ones. What were you trying to do there. What did you think that button would do. Where did you think you were meant to go. Avoid asking whether they liked it, because almost everybody says yes to the person who made the thing.

Now go back to your notes and write what each moment felt like, in ordinary words, without proposing a solution. Bored. Lost. Cheated. Rushed. Nothing happened. I did not know that was coming. I stopped caring who these people were.

The reason to separate feeling from fix is that the fix is usually wrong and the feeling is usually right. If a section is boring, your first instinct might be to add enemies, when the real cause is that the section is too long, or that you already know the outcome, or that the reward at the end does not matter. Add enemies and you get a boring section with enemies in it.

Players do the same thing when they give feedback, which is why the old advice about listening to the problem rather than the solution exists. Apply it to yourself. Your own suggested fixes deserve exactly as much scepticism as anyone else's.

Keep the vocabulary plain. There is no need for design terminology, and reaching for it tends to smuggle in an assumption about the cause. I did not know where to go is more useful than the level lacks affordances, because it does not pretend to know why.

Sort your list into two piles, because they need completely different responses and mixing them wastes weeks.

Broken means the game did not do what it was meant to do. The character passes through the wall. The door does not open. The score resets. These are unambiguous, they are cheap to describe, and they are almost always quick to put right. They are also very good at hiding everything else, because a player who falls through the floor cannot tell you whether the level was interesting.

Boring means everything worked and you did not care. This pile is the one that decides whether the game is any good, and it is the harder one, because the fix is a design decision rather than a repair. Nothing in the project is malfunctioning. It simply is not worth doing.

Clear the broken pile first, in one sitting, without redesigning anything. Then play again, because the boring pile changes once the interruptions are gone. Sometimes a section you thought was dull was only dull because a bug pulled you out of it. More often, fixing the bugs makes the boredom stand out more clearly, which is uncomfortable and useful.

There is a third pile that is worth watching for: things that work but are misunderstood. Nobody uses the dodge. Everybody thinks the blue door is locked. Not broken, not boring, just unread. These usually have small physical fixes, like moving something into view, and they punch above their weight.

A short standing checklist keeps reviews comparable across versions. Three questions cover most of it.

First: what did I do most, and did I enjoy it? Whatever action occupies the majority of the minutes is the game, whatever the description says. If the honest answer is that you spent most of the time walking and the walking is dull, that is the finding, and it outranks everything else on the list.

Second: what was the first thing I did not understand? Not everything, just the first, because confusion compounds and later confusions are often consequences of the first one. Fixing the earliest misunderstanding sometimes clears three later ones for free.

Third: when did I want to stop? Note the time and what had just happened. Wanting to stop is a strong, reliable signal, and unlike liking or disliking it is hard to talk yourself out of. If the same minute shows up across several sessions, you have found the shape of the problem.

Answer those three in writing after every review pass, even when the answers are embarrassing. Compared side by side across versions, they show whether the project is improving, which is otherwise remarkably hard to tell.

Not all feedback is equally useful, including your own, and knowing what to set aside is part of the skill.

Discount reactions to placeholder art. If the character is a grey capsule, people will mention the grey capsule, and it tells you nothing about whether the game works. This cuts both ways: a rough look can make a good game feel bad, and a nice-looking version can make a hollow one feel fine for the first ten minutes.

Discount the first thirty seconds of anyone's opinion after they finish. It is usually politeness. The useful comments arrive when you ask about specific moments, or a day later when they mention something unprompted, which is the strongest signal available: whatever they remember without being asked is what the game actually is.

Discount your own judgement on the fifteenth consecutive play. You have lost the ability to see the opening, your hands know things the player's will not, and everything feels slow because you have done it too many times. That is when to stop and find a fresh pair of eyes.

Discount suggestions that would turn it into a different game. They are usually a sign that the person wanted a different game, which is worth knowing, but is not a note about the one in front of them.

A review that ends in a page of observations has not finished. Convert it into at most five changes, ordered, each stated as something that will be observably different afterwards.

Ordering matters more than completeness. Put the thing that occupies the most minutes first, then the earliest confusion, then the moment you wanted to stop. Those three usually cover more ground than the other twelve items combined, and several of the twelve will evaporate once the first three are addressed.

Write each change so that you could tell whether it happened by playing, without inspecting anything. The corridor should be half as long. Hitting an enemy should make it flinch. The blue door should be visible from where the player starts. Stated that way, you can verify the change yourself, and verification is the part that keeps a project honest.

Then play the whole thing again, cold, from the start. That is the loop: play, watch, name, sort, change, play. It is not complicated, and it is almost entirely made of things a person who does not write code can do better than a person who does, because it depends on seeing the game as it is rather than as it was intended.