Commissioned work fails in a small number of predictable ways. We have hit most of them, and none of them are mysterious.
This is the honest list, and the useful thing about it is that four of the five are largely in your hands.
One: the brief was about the occasion
The most common failure and the one that produces the worst outcome, which is something pleasant and generic.
A brief that says "a 50th birthday game for my mum" describes a category. What comes back is a nice game for somebody's mum. It is competent, it is personalised in the sense that her name is in it, and it lands with a polite thank you.
The fix is detail about places and specifics. The house, the street, the caravan, the dog's name, the thing she always says, the chair nobody else sits in. That is what makes somebody ask how you knew.
The field on our form that asks where the game should be set is the one that does this work, and it is the one people write the least in. What to write is in how to write a brief for a custom game.
Two: the wrong difficulty
The second most common, and it is entirely preventable with one sentence.
A game built at standard difficulty and given to a four-year-old is frustrating. The same game given to somebody who plays every evening is trivial. Both produce a person who stops playing, for opposite reasons.
We can set this correctly, easily, if we are told. Difficulty is a configuration value rather than a rewrite: it changes gravity, jump height, speed, the forgiveness window and the number of lives, from unlimited attempts at the gentlest setting to a genuine platformer at the hardest. That is described in designing one game for a four year old and an adult.
What we cannot do is guess. Tell us the age, whether they play games at all, and whether anybody will be helping them.
Three: too long to finish
The mistake nobody expects, because length feels like generosity.
A game that takes forty minutes, given to somebody at a party, gets started by four people and finished by none. And the ending is usually where the personal payoff is, so nobody sees the best part.
Two fixes, and we apply both by default when we know the context.
Keep it short: ten to fifteen minutes for anything opened at an event. And put the personal content at the front, so a person who stops after two minutes has already had the point of it. The full argument is in how long a custom game should take to finish.
Tell us where it will be played. Party, home, or over time. That one answer sets the length.
Four: the likeness does not land
Less common, and worth being straightforward about because it does happen.
At the size a character appears, a likeness is carried by posture, build, hair shape and one or two signature details rather than by facial accuracy. That works beautifully for somebody with a distinctive shape and less well for somebody whose recognisability lives entirely in their face.
Two things reduce the risk.
Send casual, full-length photographs rather than posed ones. A studio portrait produces a character who looks like they are at a studio. The reasoning is in what photographs we actually need from you.
Tell us what is distinctive. The jumper he always wears, the way she stands, the specific glasses. One sentence does more than a fourth photograph.
If it is not right when you see it, say so immediately and specifically. "It does not look like him" is hard to act on; "his hair is much darker and he never wears a collar" is a ten-minute change. Character artwork is separate from the game's geometry, so replacing it disturbs nothing else, which is the point of the separation described in why game artwork gets drawn twice.
Five: the deadline arrived late
Not the deadline being tight. The deadline being disclosed late.
A tight date is workable, almost always, at a reduced scope. A date that emerges halfway through is not, because decisions have already been made against a different assumption.
Send the actual date in the first message. It is the single most useful thing in an enquiry. More on what drives a schedule is in how long does a custom game take to make.
What we do to reduce the risk on our side
For balance, since four of the five above are things a customer can control.
The engine is shared and already works. The movement, collision and interface have had their problems found once rather than per commission, which removes the category of failure where a bespoke game simply does not play well.
Every build is driven before delivery. A program plays the level with simulated input and asserts the end can actually be reached. That is not a substitute for judgement, it is a guarantee about a specific class of defect, and it is described in proving a game is actually finished.
Every build is opened on a real phone. Two genuine defects were found this way and neither was visible in a resized browser window: touch controls overlapping on small screens, and a game rendering blank because a font was loading from somebody else's server.
Somebody outside the project plays it. Because you cannot playtest your own work, which is the argument in what one person watching can tell you.
What this means
Detail about places is the whole brief.
Say who is playing, how old, and where.
Give the real date, immediately.
And tell us specifically if something is wrong, as early as you notice. Everything is cheaper before the artwork is finished.
