Skip to content

Tag: design

Definition of mechanics and features

How do you define mechanics and features? This is very important for the success of the development. Many times, we think that just talking about something makes that clear for anyone. This is the most common mistake of inexperienced game designers.

“It’s simple, the character moves with the stick and shoots with the right trigger!”

With this sentence I have a gameplay in my mind and you have another.

You should really make the effort of empathizing with the people you are speaking with. Be as visual as possible. 60% visuals, 30% multimedia and only 10% written content is what I try to follow. It is better to speak on something visual and then find and solve all the related problems. 

Often, the things we define will require some further set up. Maybe you will have to decide the speed of something. Maybe the odds for some reward. The best way to communicate this is to show clearly how you would like to set up the things, in the engine you are using or in some spreadsheet! 

Do them a favor: speak about your needs!

Have you created your framework yet?

I have been observing the profiles of the most renowned game designers for some time. They all have one thing in common: they have developed frameworks and shared them with the world.

What are the tools and methodologies you use the most to tackle problems? Group everything, create a mind map, and share your thoughts every now and then. Your framework is interesting to the world, believe me!

Don’t waste any more time, start building your frameworks. It helps to think about everything in the form of a system. Excellent tool for optimizing times!

People enjoy challenging fate

This truth is the basis of many of the first games that humans have played. I believe many have seen artifacts of ancient dice at some exhibit in the city.

Many people today condemn games that include gambling in their experience. “It’s just gambling, it’s not a game!”

And who are you to decide what a game is? To me it’s very simple: if there is a form of fun we can consider it a game. If people can learn something new without dying in the test, we can consider this test a game.

Gambling games, play-to-earn games, they are all games. They all offer their own form of entertainment.

Can a game ruin people? No. People ruin themselves. Accept it. People are a lot smarter than you think. Those who fall into addictions do so for a series of personal problems. It is impossible for a game, or any product, to be able to manipulate any human being.

The levels beat chart is your best friend

Before you put your hand on the engine of choice and design your level, or even think in the level itself, it is good to have a beat chart prepared. In this way you can have a big picture of the result of the level design iteration.

The most common way of doing that is by using the most important tool for game designers: spreadsheets.

Prepare a sheet with the following information

  • Level: the number of the level in the sequence
  • Skill Atom: what should the Player learn/practice/improve in this level?
  • Minutes: how much time should the level last from start to finish in a perfect scenario?
  • Difficulty: what is the fail rate percentage of this level for an average player?
  • Skills: Core, Secondary, Obstacles and so on. Color those cells to represent the presence of old and new skill atoms in the level
  • Author: Who is in charge of designing this level?
  • Comments: after each iteration the other level designers can leave comments here

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!

Do you keep a gameplay journal?

Do you keep a handwritten journal for your gameplays? I think it is a fundamental part of my routine as a game designer.

We use everyday a lot of different tools, each one with its subscription models and stuff. But nothing can substitute a journal. On a journal you are alone with your inner self. In a journal you can identify clearly your personality. If you don’t keep a journal is super hard to not become a follower of trends and methods you don’t fully understand.

Do it now! Start a Gameplay Journal.

For every game you play and every time you play it, write a new entry down. What should you write? Well, it’s your journal. I can say you what I write down. This work in my own case.

First of all, I describe in detail everything that I remember. I describe without giving any opinion. “I like this, I don’t like that” is not really important. The important thing is what did I felt in any occasion.

When I am speaking about a new mechanic that I can identify, I sketch also a flow of its rules and how that works. I do it quickly, I don’t have to double check it and pass it to a developer. So that it’s just a way to train my quickness, somehow. I felt that I complete tasks at my day job way faster since I do that.

Finally, I try to reason on design choices and its audience. I also try to stress my assumptions imagining possible risks for the design approaches I find.

When you write down with your bare hands the brain makes connections that are not possible to make with a computer monitor writing with a keyboard. Keep use pen and paper, you will never regret it!

Data means nothing

Data means nothing without the ability to get meaningful information from it.

I still see a lot of discussions around pure data everyday, most of them completely pointless.

“I am sure this works, data says it clearly!”. False, data is raw. Data says nothing. Data has to be put in context.

“You think our players would like this? Let’s prove it with data!”. You will never prove anything with data, you should write down concrete hypotheses and then take the raw data and transform it first in information and, only after, in insight.

“Yes, I also like this. But I want to see the data first!”. If you want to make real games you should consider just being bold sometimes. If you really like something, put it on! Players will appreciate that. If results are bad, I swear, it will probably depend on other things.

If you use the data-driven approach, you risk to really miss your point because when anything becomes the subject of our analysis the result of this analysis will be influenced by this fact. You should use data to get information to inform your design decisions, not to drive them.

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!