Write down when you will drop the prototype before you start

The point of a prototype is to answer a question rather than to make a game. If you do not write the question down at the start, the prototype never ends

This is the most important thing mobile taught me, learning to look at games purely as business. Everything we did was built on fail fast, whatever did not land died quickly and we moved on to the next one. Because there the question had already been written for us in KPIs, which KPI we would look at and after how long was set from the start

Publishers would never take a second look at a prototype whose data came back bad, because the decision sat directly with the KPIs, and nobody gets emotionally attached to a KPI

In a short 2 year mobile period we made close to 250 prototypes. Before I moved back over to this side in 2023 I built a template for Idle Arcades and could get an answer in 2 days. We took 9 games to soft launch back to back, only 1 of them turned into a global launch of course, but what brought that 1 was being able to move fast

As someone who gets attached to the game he makes with real passion, I had a terrible time getting used to that order. On top of that I took mobile pretty lightly because I thought I knew game design, I assumed it would be easy, and it hit me like a slap instead

But that is also what saved me. I had not set the rule, so I could not negotiate with it, and because of that I built an incredible honesty towards my games and towards myself

In Turkey this muscle has got a lot stronger over the last 5 years. Most of the industry comes from mobile, and most developers here grew up inside that discipline. But when they move over to the PC side most of them drop that muscle, when it is the most valuable thing that carries from mobile to PC

On the PC and Steam side there is nobody who can tell you whether the prototype landed except the players, and there is no single KPI you can look at while you are still prototyping. So you have to set that threshold for yourself

Here is what you do. Before you start, write a one sentence question and put a deadline next to it. Say the question is this, is this mechanic understood in 30 seconds and does it stay in the hand for 10 minutes. And keep the deadline under 2 weeks

Writing the question properly is a job of its own. If you ask “is it fun” the answer comes back yes almost every time, because you are playing the game you made and you already know how it is played. Always build the question around someone else. When you hand it over without explaining anything, do they get it in 30 seconds, do they start the second run themselves, do they come back to it after they put it down

When the time is up and there is no answer, the answer is always no

The most dangerous case is the prototype that almost works. A prototype that almost works can keep you busy for months, because every week it gets a bit better but it never gets good enough, and every week you look at that bit and carry on. If you are telling yourself “one more week and it will land”, you already have your answer

There is also a line everybody repeats, “do not polish the prototype”. I think the opposite. An ugly prototype gives you the wrong answer, because in most games what creates the feel is not the system itself, it is the sound, the camera, the recoil and the feedback. A mechanic you tested with grey boxes dies because it feels bad, when what died is not the mechanic, it is the layer that was missing

So polish the prototype enough that it can give you the final feel. Do not build levels, do not produce content, just make one single loop genuinely feel like something. If the question you are trying to answer is “does this feel good”, you cannot answer it in a build that has no feel

This does not hold for every genre of course. In a strategy game that feeds on systems, or in a deckbuilder, a grey box gives you the right answer. But in a genre built on feel like fps, tps or action, an unpolished build does not tell you the mechanic is bad, it only tells you it is incomplete, and you throw it away thinking it was bad

The risk of getting attached is already solved by that question you wrote at the start. If the deadline and the threshold are written down, polishing does not trap you, it gets you the right answer. Polishing is dangerous for the man with no rule and necessary for the one who has one

There is one more trap specific to us here in Turkey. Because we are a country that came out of mobile, we are genuinely good on the gameplay feel side, we do the polish fast and usually get it right. On content and systems we fail the class. So your prototype will probably feel great and will fool you for exactly that reason, because you will have tested the thing you are already good at

So build your question around the place where you are weak. You will nail the feel anyway, so ask “what do I have to put in front of the player in the tenth minute”

When the answer comes back no, do not throw the mechanic away, throw only the game away. The question you could not answer does not say the mechanic is bad, it says this game will not work with that mechanic

A prototype is made to be thrown away in the first place. Going in the bin is not failure, it is the prototype having done its job