Tag: howto

Before players decide to step into your magic circle and start having a good time, they have feelings. They might watch a video on YouTube, read an article about your game, or simply land on your store page and look at the trailers, screenshots, and descriptions.

All of this evokes emotions and feelings. Emotions are the first step of perception. That’s why when you start designing levels for a narrative-driven game (RPG, adventure, platformer, and so on), you need to think first about the emotional intensity curve over time. This way, you can properly estimate the moment-to-moment experience.

I recently used this approach for a personal exercise: creating a hypothetical level for The Last of Us.

You can see each step is associated with a specific dynamic I want the Player to experience during the level. This curve was the final one, but I worked on many iterations. You plan a curve, and then you iterate over time.

When we’re working on a new game, it’s very common to spot a lot of problems and point them out when we’re talking with our team. Having an analytical mindset is normal, especially if you’re in a role like a game designer or gameplay developer. You are, by default, forced to analyze everything very specifically, and this can lead to your analysis being extremely detailed.

The impulse can be to immediately flag these issues, especially nowadays on a Slack channel for instance. They are designed to make you talk. You see that a feature doesn’t work and you mention it because you want to make it known. The issue with this is that, especially when you are in a more senior position, it can lead to confusion.

Imagine you are on a boat with others, and you are all rowing towards a specific direction. Suddenly you notice a leak in the boat, and you stop rowing and shout, “Hey guys! The boat is leaking!” Everybody will stop, right? And someone will fix the leak before continuing.

What if, instead, you continue to work and offer a solution? For example, “Joe, you can fix the leak while we all continue to work,” or “Guys, continue to row! I need to fix this using this plug!”

This shows a different problem-solving skill, one that I had to learn the hard way. Don’t just point at a problem without proposing some solution. Be a problem solver, and your team will appreciate that.

Let’s talk about technical skills. I read a question around often and sometimes some students ask me: what skills should I have?

The question comes most of the time from our innate desire to fit (gregariousness, submission). There is a job market and we want to get in. This is fair.

As far as I’m concerned, the answer is like learning a new language. If there is no valid reason behind it, we will make a lot of effort to learn it. I learned English to better understand songs and video game stories. I learned Spanish to be able to live where I live. I learned Portuguese because of the culture and history behind Capoeira. I did learn because I felt would improve me as a person.

Likewise, the technical skills I decided to cultivate for game design come from there. Spreadsheets because I have always liked math and put things in order. The most common engines, especially for level design, because it puts me in a state of flow like when I play a video game. Game writing because, as you can see, I love writing. UX/UI because I don’t know how to draw, but I still like to arrange things visually as a form to clarify my ideas.

The question for me is not “which skills should I learn?”, but “which are the technical skills that can help me find my voice and let it come out?”