Skip to content

Tag: howto

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.

Looking for a better design test

A test is very often included in the selection processes for game designers. For junior profiles, without many portfolios, I find this an interesting thing. For the more senior, it is a difficult filter to check. I don’t know if I’m against or for it, honestly.

There are things good and bad in tests

In my opinion, a plus point is that they can reveal the writing skills of a game designer. It’s a key point, especially in these times when work is at least partly remote. It’s important to know how designers express themselves and how much they can be engaging with their writing.

A test also shows the reasoning ability of the designer. The problem is that it is difficult to read the reasons behind certain thoughts with the written medium. Without offering the designers the opportunity to defend their work, we will probably tend to prefer someone who thinks like us.

One thing that has always annoyed me is that there is a lot of work before the test which very often is not considered. You send me a competitor’s game and tell me that I can propose a feature and that I have a week to do it. If I’ve never played this game, studying it well will take me about a week off if I have to work simultaneously. All unpaid work, will not be used by the company. Wasted time for everyone.

But then how to do it?

Avoiding the test completely seems to be a dream. Some companies are gradually replacing it with other practices, though. If it were up to me, I would do the following:

  • Congratulations, you working with us on this project! It’s been 3 years, write a letter to your manager explaining everything you have achieved. You need to imagine yourself in this position 3 years from now. Explain in detail the steps that led you to your dream result.
  • Play game X, try to break it down, and think about what could be improved and for which KPI. Tell us when you’re ready and come to the office to discuss it with your future manager.

Maybe I’m a dreamer and this is not a process for all types of companies. But I am convinced that:

  1. You can get higher-quality information this way
  2. The traditional way is really difficult to evaluate because it depends a lot on who reads the test.

Review of the book “The Secret Science of Games”

I finished reading the book “The Secret Science of Games” written by John Hopson. There are very few books written by people with extensive experience and for me, they are a real treasure. The book focuses on Games Research, a discipline that deals with connecting game designers with players.

the book is live here

What I liked

John has worked on hugely successful titles such as Destiny, Halo, Fable, etc. You can feel his experience in his thought which have a clear point of view. Reading the book you understand the importance of seeing real people play your games.

Particularly interesting reflections on the importance of being quick and frugal at times to be effective. It is not always necessary to wait for a complete report. Game research is perceived as something slow and precise, but John points out that it is not science. That game design still has a creative and artistic side that depends on personal sensibilities that go beyond numbers and hypotheses.

The length of the chapters is perfect. With a coffee, you can read yourself a complete chapter. This means that in breaks from work, I read everything. The length of the book, at around 200 pages, also makes it a booklet that you want to have on your desk.

Finally, the final section on case studies is very passionate and candid. We realize the challenges of our profession and how we must never underestimate that silent part of our players. Very often we refer to online reviews and opinions, but those who communicate there are usually a specific type of player who does not represent the entire community. All are very well specified in the book.

What I’ve missed

I am quite a visual person. People in such a demanding profession as John usually don’t have all the time in the world to write a book. The result is that the book is made up of many words and no images. I missed images and diagrams in certain passages, to better understand the decisions made following discoveries in the laboratory. I would have also liked to see organizational charts to understand how to structure a team.

Another thing I would have liked to see is tips on how to do game research when you’re not Bungie or Microsoft. When you’re part of a small, independent team. When you are trying to create something well done to attract investors. I’m sure game research can be done at that stage, and you must. Game research and quality assurance are very often sacrificed, and this affects the final quality of the product.

Three quotes that I loved

“Games research lives somewhere in between scientific rigor and creative disorder”

pag. 37

“If I can’t find a quote or a snippet of video to support a statistic, I’m probably looking at the wrong statistic.”

pag- 104

“A good tutorial or hint system is one that guides the player as completely as they need, while offering them the opportunity to turn away from the path”

pag- 187

Start from Personas

When you study game design, you usually focus on documents and prototypes for small games. The first steps that are taught in educational centers are purely technical.

Then you are in the market without the skills that make you a professional designer. Which are not the techniques, but are those oriented toward the video game business.

Normally a team reports to one or more managers who maintain a business vision. Our role as designers is to understand how to realize this business vision. We have to think more about endorsing the product than creating something directly. Players will receive the product packed and polished. Technical skills are important, but our ability to understand the business is critical.

Personas are one of the methods that allow this communication across the whole team. I share with you this workshop that aired last Saturday. The audio is bad, but the content is excellent.

If you want to work for companies as an employee or consultant, you need to come up with frameworks that solve concrete business problems. Thinking about who will really play and how to structure a product for them requires effort and is not intuitive.

Respect the art of game design

I met a prospective client the other day who needed simple service. Given a set of published games, derive a design document that specifies everything that should be included in the final game.

The goal of the document was for a programmer to take it and figure out exactly what to do to produce the final game.

I told him his dream is beautiful, but that remains so. Making a game is not an assembly line; the specification documents that other developers need to work with must be produced based on real development needs.

The best way to be successful in video games is to maintain a certain degree of realism and respect for this art that is so difficult to master.

Reviews are your best friend

Whenever you are starting a new game project or if you are working on LiveOps for an old one, you have a free asset that is very useful: reviews.

Only a small part of Players are willing to leave reviews for your games, especially in free-to-play. Videogames can ask directly in-game to leave a review, but not everyone does so. They do not represent in any case the dominant opinions, but they are useful to spot opportunities for your game.

  • If you read critical reviews and you notice something that repeats a lot, that something can be converted into a unique selling point for your game.
  • If you read positive reviews and you notice something that repeats a lot, that something should be a must-have for your game.

Use Steam or Data.ai to filter out positive and negative reviews. Remember Pareto’s principle. Use always 80% of other games and innovate on the 20%.

  • 80% you should take can be read in positive reviews that repeat
  • 20% of novelty can be read in critical reviews that repeat

Analyze the reviews of the main game you are taking as a competitor, but also of its clones and competitors!

What? There are NO clones of that game? You are probably choosing the wrong competitor and you will hardly manage to have success in its field.