Skip to content

Tag: howto

Exciting goals

The structure of the objectives of a game must be clear, but also and above all exciting.

At the time of classic arcade games, players had to pass the level and get the highest score. This was exciting in that context, where one could brag to friends or show off one’s prowess.

The console age built on that, adding storytelling over the years. Also in other contexts, the players could comment on their achievements. I remember phone calls with friends to explain how to beat a Weapon in Final Fantasy VII. Strategy guides and magazines with reviews were popular. And it was like this thanks to this desire to understand and discover new exciting goals to achieve.

Social games have summed up all this past, allowing us to collaborate to achieve goals. The metagame concept has developed, you can reach certain objectives even without playing. The experience allows even casual players to take part in something fun. There was also a cleaning up of objectives that were getting too complex. This is thanks to understanding and profiling players.

As game designers, we must always ask ourselves where they will play and how much time they will want to invest.

Fun fact: the most engaged casual players and those who will spend the most will

  1. come back every day (regulars)
  2. come for a minute, but stay for an hour.

How to find a new job

I’ve been reading about a lot of layoffs in the industry lately. Many people give advice on finding a job and share their experiences. It’s great to see everyone working together.

Someone is capable of arming a portfolio to make the leads of the most renowned companies envious. Someone else manages to work in a bar gradually creating his game in his spare time. There are people who are very good at making new contacts and making themselves known. Others prefer to write or record videos. There are many ways and there is no need to get anxious and try to cover everything.

  • Do you have anything to say?
  • do you have something to show?
  • Do you have the opportunity to meet someone?
  • do you want to earn money doing another job at least for a while?
  • do you have the possibility to keep yourself without entrances for a while?
  • have an idea for a game?
  • Do you know which companies you would like to work for?
  • Do you have any idea of the specialty you want to acquire?

As far as I’m concerned, it’s hard to find universal advice to give to everyone. Each person is a world, everyone lives in a different context. Make contacts, have a portfolio, be kind, learn something every day, and dedicate yourself to a small project every month. They are all valid advice, but also very general. The human being is not a machine that receives instructions and executes, there are many factors at play.

Here’s what worked for me:

  1. think about making contacts rather than making a portfolio.
  2. be omnipresent at local events and always try to help before asking for help.
  3. ask for help.
  4. immediately move away from realities or people who don’t want me.

I don’t have an online portfolio, except an old link. I prefer to have a blog where I show my thoughts. And I do it because I don’t care to be evaluated for my technical skills. I don’t have to prove anything to anyone, least of all skills that can be acquired in 10 minutes of a YouTube tutorial.

The first step for a good prototype

Imagine you have to inform programmers about the development of a new feature. For the first iteration, it is always better to think of a single use case.

We game designers think in systems. Some go so far as to say “Game design is system design”. A system means having actors in a relationship, creating a space of possibilities.

For a new feature, it’s best to think of a single path to implement first. Someone talks about MVP, a minimum viable product. I have always preferred the expression “prototype”.

Without losing sight of the vision, respect the steps necessary for its development. The first step is best to be on the direct path.

Narrative matters

I hear too often “Nobody gives a darn about narrative in games”. Or “no one reads on mobile”.

But every successful game I know has a strong narrative component. Narrative is not the line of text, it is the sequence of events that creates a story together with the players.

use a star -> dialogue -> select decoration -> room upgrade -> dialogue -> new tasks -> new level

This is narrative.

swipe -> match -> explosion -> cascade -> match -> special tile -> … -> TASTY!

This is also narrative.

arena overview -> goal -> countdown -> GO! -> move character -> spot enemy -> hide -> collect gem

And this as well.

The story stack

Often we stuff a mediocre game with readable content in hopes that players will get hooked “for the story”. In this case, the risks of having an expensive and poorly thought-out product increase. A story should always be seen as the last step of a good game.

  • Fantasy comes first
  • Then come the actions that can be performed on the fantasy
  • Then comes the system of resources, rewards, and the game economy
  • The world is built on this
  • Stories can happen in the world.

If we start from the other side, however, it works for visual novels but not for mechanic based games.

Creativity and patience

For me, there is a direct relationship between creativity and patience. Ideas need to rest before being properly evaluated. Teams need to have the space to make their own journey and thoughts to make a game happen.

Most games never get published. This is due to many factors. But, a good pre-production phase helps mitigate the risk of not seeing the light.

I’ve read many articles explaining how AI tools help speed up the pre-production stage of a game. Some say that companies can also create content faster. I am very skeptical on this point.

In the pre-production phase, a team measures its potential toward a concrete challenge. The AI tools promise to give us concept art of a pretty high standard in minutes. We can also create stories and document templates. We can get quick code snippets.

But then we’ll find ourselves having to edit here and there. This editing process is different from the process that created successful games.

Since when did we decide that faster is better?

A good dish takes time to cook. A good vertical slice or demo, too. People need time to make meaningful connections, the sparks that ignite the engines. If we entrust this process to machines, then we end up working for the machine.

I enter my prompt and await the results. I review and analyze them. I iterate with these results by introducing more prompts. I review everything and make my changes. Instead of me acting and creating, it’s like I’m making corrections to an assistant. And it’s one of the worst assistants because it doesn’t actually think!

Fail faster is good advice, but it doesn’t mean we have to rush things. If something not created by us fails, it will be more difficult to grow. We will have no memory or connections that will make us understand which steps need to improve.

When did we decide that jumbled datasets are better than looking for references?

People need the process of searching for references to achieve creative goals. While the result of a prompt may appear to have excellent quality, it is still a mindless mixing of elements.

Our urge to have “the thing” now causes us to end up feeding a machine that will create something average. It makes us disperse in a mass.

The process that created the hit games that are on everyone’s lips works differently. There are two types of goals, project goals and personal goals. Every maker must have time to reflect. This time is invested in looking for references and organizing them. The same goes for an artist, a writer and a programmer. If this process is skipped in the name of speed, we will be acting like monkeys. Can we make something good? Just by chance.

Is it possible to use these tools in a healthy way?

The quick answer is no because datasets are a sophisticated intellectual property assault.

For the extended answer, imagine that there is no ethical/legal problem. Assume that the datasets are completely legitimate.

These tools can be used to unlock meaningful internal conversations for the team.

If I, a game designer, have to communicate some concepts to artists, these tools can facilitate my work. If a producer is briefing game writers, these tools can help estimate the number of words to use.

AI tools can help us learn to communicate with people belonging to other departments.

There is a direct correlation between the time a team works together and their odds of success. We should foster this necessary time with patience.

  • Instead of thinking about speeding up critical passages, let’s improve cross-department communication.
  • Instead of trying to get to the end faster, let’s improve our understanding of how everything contributes to it.

The art of vanity

Vanity metrics are metrics that are not used to make strategic decisions. They are used internally and externally by a team to make a good impression.

During the development of a video game, some useful metrics can become vanity metrics. The measure of MAUs, Monthly Active Users for example is often used as a vanity metric. An MAU is a player who has logged into the game at least once during the month. It is a measure that says little, with which few decisions can be made. Yet, if we have many MAUs, our partners and investors will be happy to know about it.

Another vanity metric I see in the world of premium development is the number of wishlists on Steam. Steam algorithm recommends your game based on the speed of getting wishlists. Wishlists are useful, but the metric representing the overall number is not. I have never seen a single company making strategic decisions based on that number. A premium games company decides to make a game and goes until the end. Having many wishlists motivates the team and piques the publisher’s interest. A textbook vanity metric.

Are vanity metrics useless?

Absolutely not! They help move things along, they help with certain discussions. I compare them to the placebo in medicine. Placebo is proven to work on so many occasions. Monitoring, presenting, and discussing vanity metrics allows us to unlock many situations.

If a game has tens of thousands of people returning every month at least once, this opens doors to investors. The fact of having many wishlists allows a publisher to focus their campaigns more on our game. The team benefits from it because it’s easier to prove that artistic decisions are the right ones. Proving artistic choices is hard, art has a strong aesthetic component. That’s where vanity comes in!

Flowcharts and UX flows

The difference between a flowchart and a UX flow is that the first is drawn from the point of view of the game, while the second is from the point of view of the players.

After writing a brief for a new mechanic or feature, specifying everything in a flowchart helps resolve edge cases. Useful before going on to detail the configurations necessary to unlock the programmers.

After designing UI wireframes, a UX flow helps to find missing pieces. Very useful for going on to detail the graphic assets needed to unlock the artists.

If we don’t have time and we need to be quick, the flowchart is the least essential of the two.

Escape from vanity metrics

I was in a conversation, one of these groups where tons of people are discussing game development. The founder of a local company says he opened his game as a beta. He invited some streamers to let them try the title. These streamers then left a vote. He stated that it was a success, the game had a high rating.

To me, it all led back to a single characteristic of the speaker: vanity. When you have a product in development, you have to challenge your assumptions. Especially if you want this product to be a real success. There’s no point in inviting people, putting them at ease, and asking them if they liked it. Probably some bias you have will be confirmed, some others will not. The more inexperienced part of the team will feel satisfied, the team will be treated well in the next few days. The boss is happy, everyone is happy.

Then comes the weight of reality, law of gravity. They don’t play your game, even for free. You can not recover the investment. You may need to make some staff cuts. You will still declare “yet we tested the game a thousand times and they said it was a good game”.

How to avoid falling into the ego trap?

By asking the right questions. Believing in a product and betting on its success is very positive. However, it must be done with caution.

  • You have to ask specific questions
  • You have to make hypothesis beforehand. These must be quantifiable and real: “Login time to a game is less than 30 seconds,” is a guess. “Love the game” is not a guess.
  • You need to put your designers to observe people playing without interruptions. They must develop the intellectual honesty necessary to create objective reports.
  • Then you have to work first to improve the strong points, then to solve the critical issues.

This is my advice. Escape from vanity metrics.

Three and four stars reviews

When studying a game it is also good to do it by reading people’s reviews.

In the case of mobile games, reviews are very often driven by two factors:

  • an in-game prompt asking you to leave a review. It is usually shown after a success, or at the end of the tutorial.
  • a moment of anger and frustration of a player. The lowest grade is usually given. For example, one star.
  • a moment of wonder and joy for a player. Normally the highest grade is given. For example, five stars.

When analyzing the reviews of a game (but also of a product on an e-store in general), I always filter for the average rating and above the average. For example, three and four-star reviews.

In fact, people who leave intermediate values usually leave more detailed comments. They belong to that part of Internet users that are a little less superficial. People who think things through a little more. The best candidates to give quality feedback!

First goal for every team

A team should first demonstrate to themselves and to the World they can develop a complete game.

Whether a team is composed of experienced members or newbies, the first thing should be completing a game.

Some team starts by helping other projects. Some others should probably start with something small. Finally, some others may work on a remake or an existing game adapted to intellectual property.

I like to compare a game development team to a rock band. First, you start doing covers or making your own stuff for small clubs. You cannot start by playing at Wembley Stadium, that’s your dream, but you must be realistic.

There is a lot of energy involved in the development of a game, you have to first prove you work well together.

When you still have nothing out there, talking about huge growth and wonderful disruptions may be frustrating. I respect the ambitions but listen to my humble suggestion: make your games the best you can. Just worry about that when you’re starting.

Unless, of course, the team is composed of at least a core that already faced together their struggles. You need to know how to hit the road together before of going to the sky. Success will come by hard work and only a few times thanks to contexts and events you cannot control.