Blog

How to do a good dev diary

Dev diaries are very common as PR tools, both among AAA companies and indie studios. We’re not talking about technical stuff (like “how we solved this or that coding challenge”) or post-mortems where every figure is broke down and analyzed under the microscope. They’re helpful for the indie community, and you can learn a great deal from them – but they’re aimed at professionals, and thus not exactly the best option for promoting a game. We’re talking about dev diaries made for your audience, the people you want to buy your games. Today we want to give you a few tips and tricks about how to make a good dev diary to promote your game.

Picking a list of topics

The first thing you have to keep in mind is: what exactly do you want to talk about? It’s not a trivial question – you’re not doing this to make new friends, you have a game you want to promote. You need to pick a topic and decide how to approach it, keeping in mind your ultimate goal (which could be getting wishlists, driving traffic to your site, engaging with your community in your social media channel… but generally speaking it’s all the same: sparking interest around your game).

Remember what we told you about marketing plans? It will come handy here: if you have a clear picture of how your audience is and where to find it, it will be easier to decide the best topics. For instance, if you’re doing a strategy game and you know your audience to be super hardcore, breaking down the numbers and showing them the maths behind the scenes could be super interesting to them. On the other hand, if it’s a casual strategy game such as Clash of Clans, that approach would bore the heck out of them.

Two different approaches

In broad strokes, we could say that there are two kinds of promotional dev blogs. The first one is the most obvious: discussing some features of the game. You can show some new feature or expand on something you teased about some time ago, explain how they work, and maybe even how’s its development going.

Be careful with that last one, though. Apart from this kind of content not being targeted at fellow game devs but at your audience, there are some more risks attached. If you talk about something still under development and, in the end, you have to drop that feature for whatever reason (production issues, it’s too complex, it doesn’t fit with the game, it just isn’t fun…), you’ll have to explain why. People don’t necessarily know about game development, and they might not understand your reasons. Transparency is perfectly fine – as long as you know where you’re going and you don’t write yourself into a corner. As they say: underpromise, then overdeliver. Keeping that in mind, this is the easiest one to do.

Make it personal

The other kind of dev diary is more aimed at showing the human side of your company. I’m sure you can think of a good number of indie devs that have managed very well to cross that bridge between brand and audience. The goal here is not to talk about a feature in particular as much as giving a face and voice to your brand. It’s easier to become a fan of a brand when you think of it as something close and personal, and not just a logo and a name – and what’s more personal than a friend? It’s also great to make people more empathetic to you, more prone to excuse your mistakes and to applaud your triumphs as their own. You can also talk about your philosophy toward games, what you’re trying to achieve; and to appeal to different niche audiences by having members of your team talk “directly” to them.

This does not mean that you’re not talking about your game – just that you are doing it through someone’s “lens”. Let’s keep the example of the strategy game. You’re doing it, say, based in World War II. There’s this person in your team that just can’t stop talking about World War II history – they are such a history nerd that they know every tiny detail, the name of the freaking fifth sergeant of the Nth company in a forgotten beach. If you plan to do a dev blog about the historical research you did for the game, introduce this person in the video and make them talk. Q&As, interviews, AMAs – they are all great tools to make your brand evolve into a group of people your audience know and love.

The medium is the message

Topic and approach are leg one and two of this stool; the third leg is the medium – how do you want to tell this story? Will it be a video, a text, a Q&A, a comic? No medium is wrong per se as long as it works to carry your message through. You should take into account, though, that as the media theorist Marshall McLuhan said, the medium is the message. Although coined originally to express that a medium itself is more important than the meaning or content of a message in particular, it’s also commonly used to say that a message changes depending on the medium you use to pass it around.

Let me explain this. What I mean is that you should choose how you tell every story depending on the actual story you’re trying to tell, and looking into the strengths and weaknesses of every medium. Text (dissertations, narrations, etc.) is great for going into very fine detail, for instance – elaborating complex ideas and concepts, explaining the lore of a game… Dialogues (Q&As, interviews) are great to confront points of view and to get to know someone through their interests and how they talk – and they are super easy to read. Video is technically harder to do, but it’s agile to watch, easy to consume and share, and has no equal when it comes to actually show a game, new characters, animations, features…

Again, it doesn’t matter what you choose as long as it’s a conscious choice and you know where you’re leading to play to its strengths. There is no best option per se – and the best way to go if you’re keeping a regular, long-term dev blog is to do a bit of everything so as to give variety and keep your audience interested.

Keep it real – but localize

The last piece of advice is: keep it real and don’t go crazy. Don’t spend thousands of dollars in making a super fancy video, for instance. Triple-A games do that sometimes because they work differently: they can afford to pay a huge check for a super short teaser trailer to get lots of exposure in singular moments. That’s hardly the case with indie devs: you need something relatively cheap for it to be sustainable. A regular dev blog during months is like an open door to invite your fans in, take a seat and share some time with you. But a one-shot thing won’t really work if you don’t have an eager audience waiting for you: a fireworks display is fine if there are enough people to watch it; if not, it’s a waste of time and powder. Unless you really can afford it, keep the costs low – this is a marathon, not a sprint race.

There is one thing, however, where you should consider spending as much as possible: localization. You’re trying to reach out to your audience here, right? Then it makes sense to localize your dev blogs – the more languages you speak, the more people you can talk to. Obviously, you can’t translate everything into every single language out there, but you can analyze where your players came from in the past (or, if it’s your first game, which are the key markets for you – marketing plans from the very beginning, remember?). Apart from English, the other obvious one is Chinese (for obvious reasons too), and then your mother language if English is not your primary one. On top of that, it depends – but the usual suspects are German, French, Korean, and Japanese, followed in a second tier by Italian, Portuguese, and Spanish.

Once you know which languages are most important to you, calculate how much it will cost to localize every dev blog on average and how long you want the dev blog to be ongoing, and then see if you can set apart the budget for that. These calculations are important because, once you announce that you’re publishing a dev blog in these many languages, you should consider that as a commitment with your fans and stick to it to the very end. Localizing your blogs you’re sending a powerful message: you care for all your audience from all over the world (or at least for as much as your budget can afford). If you drop some languages midway, you send another message: that some audiences are, in fact, less valuable to you – and that your word means nothing when push comes to shove. If you want to see a couple of examples of good practices, please check the dev blogs of Spire of Sorcery and Mount & Blade II: Bannerlord. Sadly we can’t share any numbers, but believe me when I say their efforts are totally worth it.

That’s all for today – keeping in mind these simple piece of advice, you can plan a general strategy on how to do a dev blog to helps you to reach out to your audience. In the near future we’ll discuss this topic again, but focusing on how to record interviews to do video dev blogs. It looks as easy as hitting the Record button in a video camera, but it’s a bit trickier than that if you want to make it look professional enough on a low budget. I’ll give you a few ideas on where and how to position the camera, basic lighting, audio, staging, and editing – it won’t make you the next Steven Spielberg, but it will be enough for you to create nice videos that you can share on Youtube and your social media channels. See you next week, let’s make some jaleo!