Skip to content

Tag: howto

How to self-educate in designing games

Improve your design abilities adapting this writing method by Benjamin Franklin.

Benjamin Franklin was born poor and he stopped being educated when he was 10 years old. He developed a method of self-education and became great at writing informative texts. Here there is his method:

“I took some of the papers, and, making short hints of the sentiment in each sentence, laid them by a few days, and then, without looking at the book, tried to complete the papers again, by expressing each hinted sentiment at length, and as fully as it had been expressed before, in any suitable words that should come to hand. Then I compared my Spectator with the original, discovered some of my faults, and corrected them.”

Can this be adapted to game design?

Try this:

  1. Find good videogames and make hints of every interesting part you see. Start from the brickfile.
  2. Wait for a few days and then come back to the hints. Who is the target of this game?
  3. Try to reconstruct the features and mechanics that you can reconstruct. Focus on the simple things, don’t overcomplicate it.
  4. Wait again for a few days and then come back. Does that make sense? Is the audience the same again or you are looking for other kind of Players?
  5. Repeat 3 and 4 until you are happy with your result
  6. Prototype just the things you improved!

The best template to start with game writing

The best way to learn how to write for video games is to do it. Write, print your work, read it aloud. Reading aloud is critical to develop your text comprehension skills. Do not be shy nor lazy. Read your works aloud!

If you don’t know how to start because you have no time to code or to make a game, don’t worry. Think in the game you love, imagine a situation between two of its characters. The situation can have branches inside, but maximum 2 endings: the good and the bad.

Now it’s time to write your script. Sarah Longthorne released a while ago this fantastic template for branching narrative in visual novels. You may want to start from here. This is one of the best resources I have ever found for free.

If you are thinking in an RPG, of course that will be different from a visual novel. In this case the triggers that bring the story to the players are different.

You should think in those triggers and create your own template!

How to deconstruct a game

One of the skills that make a game designer instantly hireable is the deconstruction of games. It is no easy task to complete, since the first instinct is to end the job once we have identified the core loop, the secondary loop and maybe some unique feature.

I have seen too many times teams copying from here and there after a quick deconstruction and the result is something like

Not cool huh?

A good deconstruction looks for the audiences of some game and wants to really empathize. Having a document with the core features is nice, but having empathy maps, customer journeys and personas at the end of it is key for the success of a project.

  • Play the game for the right amount of time
  • Look for its update logs: you need to know where developers put the highest efforts
  • Read reviews and study them
  • Look for streamers, those are free playtests
  • Join Discord channels and Reddits to spot the interesting and pain points
  • Run playtests of your competitorsTry to interview core Players

With all those insights, build your Player. Forget demographics, focus on behaviors and needs!

Game designers, do not use Bartle’s taxonomy

Years pass by and I still see and read a lot of articles and videos that suggest using Bartle’s Taxonomy of Players for MUDs.

Richard Bartle was one of the designers and researchers around the online communities for MUDs, multi user dungeons. The very first version of MMOs.

He identified four different approaches of players of that time to the medium.

What I learnt from his work was that it is very interesting to haver your own taxonomy to create your player persona.

But, people still seem to use it to start thinking in the very first personas as if they were part of a ‘90s MUD. Players changed a lot. Your game is probably not a MMO. Using the same taxonomy for those cases will probably lead to mistakes.

It is true that it may be good to discuss with your team, but you are not doing the right job. Do this instead:

  • Create your personas
  • When your game is running, identify your player personas by interviewing players
  • Create your own taxonomy

Stop using Bartle’s taxonomy, unless you are designing a MUD for telnet. You will most likely not have killers among your players!

Try this when you get stuck

When you get stuck in a creative process share your concerns as soon as possible. I advise you to do it with conviction. People react quite badly to extreme things. Propose a sudden extreme draft to your team so that their brains are activated!

I usually get stuck on the writing side. Finding a tone for a new character or for a specific moment. Finding the right words is always very complicated to me. I need time that often I don’t have.

Define a tone according with the context and circunstances. Write down lines as quickly as possible in that tone. Try to do it in an extreme way. Share it immediately with the team. If you have a week to prepare a dialogue (that never happens), imagine that you have one hour. 

Pass your draft in slack or whatever with conviction: “I’m thinking something like this”. People will start to help you with ideas and concepts, believe me. They cannot accept that extreme thing. That is why you may want to be it: to activate their brain defenses!

With this technique you will get 3-5 potential tones and various references that I can explore! The team contributed to that and they will also feel more involved with the whole thing.

I hope this trick is useful to you!

Game Designers, use this onion to design your prototype

The onion model is the base that I use to think in any prototype of a new video game. I discovered it in a video years ago and I have never stopped to use it. I have never found that video again, sorry about that.

This onion model is made to be started from both sides. It works better to start from the narrative side and go toward the center. We have already a lot of core mechanics that are proven to work. Fire, match-3, gamble, merge, harvest, etc.

Which kind of feelings do you want your Players to have?

First question: which kind of experience do we want to give the Players? What are the feelings we want for our Players?

The answer can be pretty vague: “just a relaxing and quick experience.”

Or it can be detailed: “I want my Players to feel they are managing a video games company with its budget and people.”

Usually, this model works better with the second kind of answers. Try to spend the right amount of time in this part.

Then I try to identify the personas. Do not forget to use OCEAN!

I facilitate a session with all the team, in which we decide the kind of narrative we want to deliver. Content has a high cost, so that you may want to start from here believe me. It is good from the very beginning to start estimating its dimension.

Once we have the narrative, it’s time to pass to the progression part. Example:

Narrative: “You are a space traveler. You have to stop the evil Empire from oppressing the universe.”

Progression: “explore the universe, complete missions and quests.”

Do you really want to start with an open world game?

Progression: “beat the levels and defeat the bosses”

Ok, that seems better! Will the bosses have special behaviors?

Progression: “try to reach the best score and climb the leaderboard”

It’s Social, I like it. Is the leaderboard for real? NEVER do a real leaderboard for a prototype!

Only later think in the mechanics!

The secondary mechanic is related with the meta part of the game. Think of your Players when they are NOT playing your game. Which things do they think in when they have the intention to play your game again? 

“I have to enter because I have to collect my boosters” (Candy Crush Saga). Boosters are your secondary mechanic.

“I need to play again because they are attacking my base” (Clash of Clans). Raids are your secondary mechanic.

“I need to play again because I have to beat the Royal Griffin” (The Witcher 3). Spells or Crossbow are your secondary mechanic.

Now you have it! The core mechanic, I am sure, will come alone!

No? Really? Do you want to create a new one? OK.

  • Forget about all that we said and make a prototype including ONLY the core mechanic.
  • Iterate on that until you have it.
  • Playtest a lot, put your core mechanic really in crisis.

Then, and only then, you may want to add all the rest. My suggestion is trying to be really conservative on the other parts if you want to avoid headaches.

How to deal with your boss

One of the things I wanted to understand earlier when I started working as a game designer is that part of the job is making your boss successful.

Your boss could be the founder of the company you work for, in the case of small businesses. In this case, he will likely have to be accountable to investors. Try to understand the pressure he has and adapt your proposals to it.

It is not important in the profession to be right. The important thing is to deliver the things done. It does not matter that your idea is not accepted, very often there is an external pressure that causes them to take paths that may seem wrong.

Better to make our proposals, but willingly accept the impositions. The facts may prove us right, or we may discover other things we have ignored.

If your boss is a more technical person, better focus on trying to guide him on the more business side. We try to understand the context in which we work and which solutions can be simpler and faster to implement. Our importance in the team will increase!

If your boss is a manager, or a person who generally reports to the CEO or some other manager, it is appropriate to accompany our proposals with spreadsheets with numbers that we can generate. Money, or success metrics!

We must try hard to deliver these numbers, otherwise we risk our proposals being rejected because our boss is unable to defend them properly to superiors.

It is important to empathize with our leaders and understand what profile they have. If they are successful, we’ll be that too!

How to create a repository of the games we play

I learned a technique that I use a lot from a YouTube video of an industry expert. The technique is called brickfile and is an excellent tool to research and internalize some aspects of a game that we are studying and analyzing.


When I play a new title, I always record game sessions and upload them to my YouTube channel. In the case of mobile games, I wait for a session on day 3 and try to record at least 40 minutes of play by going through all possible screens.
Save snapshots of the gameplay video, watching it again. I use VLC for this operation which allows you to save snapshots using the SHIFT + S combination

vlc snapshots
Take all the snaps and pass them to the PureRef program, which is free and allows you to view them in the form of a grid.

PureRef
Brickfile is the name of this format, and is very useful for future reference. You can easily check the various features of a game and use each snapshot for wireframes, too. In fact, from PureRef you can easily copy and paste into other programs such as Inkscape!


I have created a public repository on GitHub where I will upload my brickfiles. It would be great if it were a collaborative project!