Sometimes it’s easy for us to forget that a term we commonly use is actually field-specific jargon. And so it is with ‘review code’ – a term that every games journalist, influencer or PR will understand, and which we often make the mistake of thinking developers will understand too. But why would they?

I’ve noticed that ‘review code’ is confusing to a lot of people. So I thought I’d write a quick post about it: what review code is, what it isn’t, how it works, and when it should be available. Q&A format because it’s Friday and I’m tired.

What is review code?

Review code is a version of a game that is sent to the media for review. Back in the Stone Age, when I was a games journalist, it used to arrive in the post on a plain white CD-R, usually along with a bit of paper explaining what the game is, the date/time on which reviews can go live, and any other embargo or nondisclosure conditions. These days, it’s far more likely to be a Steam key in an email.

What should my review code consist of? What version of the game should I send?

You should send the full and finished version of the game. It should be the version that – barring a last-minute emergency when you realise an arcane set of interactions sets the player’s house on fire – you expect to appear on the digital store shelves. A reviewer will review your review code on the assumption that it’s the full and final version, and if they find out that it isn’t, they’re likely to not bother reviewing it at all, as they need to be confident in the consumer advice they’re giving to their readers. If your review code is buggy and broken, they can’t confidently tell their audience that it won’t be on launch, even if you pinkie-promise that you’re already working on fixes.

Should I send anything with my review code?

Yes: send a press kit with plenty of info about the game, a deck of high quality (unwatermarked!) screenshots, trailers, any supplementary material. Tell them when the game is releasing, where, and for how much. Tell them exactly when they can run their reviews or coverage – at least to the day (you’d normally set an embargo until release day, or one day before if you’re feeling confident), and you may even want to set a time.

When should I send review code?

Long enough in advance that it has chance to land in someone’s inbox and get ignored for a while; for someone to give it a go to see if it’s interesting; for a review to be assigned; for the reviewer to play enough of the game to write about it; for that review to get written and edited and scheduled; and for any bigger releases queue-jumping and demanding the writer and editor’s attention in the meantime.

If you want a review on launch day, which you do, that means at least one month before release for online coverage, or two months before release for print coverage.

Wait a minute… but doesn’t that mean I need to have completely finished my game 1-2 months before I plan to release it?

Yes, it does.

Oh.

Quite.

What about if the game is, like, 95% finished but just needs some polish in the last level?

It needs to be the finished version.

OK, fine. But I’ll just send this list of known issues along with the review code. They won’t write about those, right?

It needs to be the finished version.

Right.

…Shall we think about moving the release date back by a couple of months?

Yes please.