For the next year I dream of an industry always more diverse and fresh.
I hope that all communities and also minorities will feel more included in it.
I hope to see also people from other sectors joining the industry bringing some fresh air.
I hope to see more junior professionals with an opportunity to really show off their talent.
I really hope to see this thing expanding as it deserves!
This year I have worked a lot on hypercasual games. I like the fact that its development requires you not to get attached to any specific idea. You design a game mechanic very quickly, put your hand on the engine with few specifications and then you speak on something done.
It reminds me of a method proposed by Jordan Mechner, creator of Prince of Persia.
Working on hypercasual games I learnt that:
The noob, they really have to understand things well. You need to slow down that difficulty curve, believe me
The pro, they like to have games which permit to spot a perfect path to follow and win
The hacker, they will try to hack the rules of your game. Best games out there permit them to do that, for instance Aquapark.IO
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!
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!
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.
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
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:
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 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 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.