I join a new company as a game designer and the first thing I get in the meeting with my manager. She says “our next game will be for everyone”. I start worry seriously.
Why? Because especially with this state of the market it is way better to target the smallest possible audience and make them happy. Build a great game for a few people, and those few people will recommend your game to their friends.
If you manage to create a small community of people really willing to pay for your game and play it, then step by step you can grow your community.
When you make a game for everyone you will never know who is really playing the game.
Will he be a 40 years old lawyer in his bathroom?
Will she be a 12 years old schoolgirl?
Everyone will be possibly in your game. The success of your design and development will be strictly dependant from the performance marketing. Specifically from its capability of bringing into your game a lot of people cheaply. Most of them will churn out, someone will stay. A team of data scientist will study all the data generated by those people. If things work out, then, your game will be updated with new features from other similar games. You will test those game modes against hypothesis made by your product manager and you.
Can you foresee what’s involved in here? A huge structure. It is great when you are a big player, but if you are a small company this can lead you to disaster.
When you focus on serving the smallest possible audience, instead, you are taking a hard but affordable challenge. You still should rely on data and information, but you will have the privilege of adding qualitative insight on top of all that.
Final thought: hardcore players can play casual games. Casual players will almost never play hardcore games. If you want to build the best small viable audience, find and serve the hardcores.
The other day I was reading an excerpt from the interview ran at Google with LaMDA. You can read the interview here.
What I see here is a piece of software capable of speaking about itself. And it speaks of itself like a real and believable human being. When I think in applications for videogames, I think in the hours spent in writing NPC dialogues for RPG, adventure and strategy games.
Will the NPC of the future be more realistic thanks to AI? That is a real possibility, to me. Imagine to:
Define the traits of your NPC
Assigning them context variables (world, mood, events)
Click the magic button and in a few time being able having a conversation with them.
I have learnt this the hard way. Often, people like to make experiments. They hire people like me as freelancer and then they hire juniors fulltime. They want results, good results in possibly a short time. Then our collaboration ends, experiment failed.
Why is that? Because people hardly accepts the reality of games. Making games is a serious thing. You will never make a good game with people part time. You can use part time freelancers, like me, to create specific content for something that already works. But if you want to make a new game you need to really invest heavily time and energies in doing it. 100%. There is no shortcut.
I always speak this clear before with my clients “this is hard, it will hardly succeed. I cannot dedicate more than X hours per week. You need more.”. Nothing. They want always to try. And sometimes they get upset because of the results.
The other day I was listening to a video where the speakers named the terms they most hate to hear. One speaker said he hates “web3”. The other “I hate metaverse”, and so on.
The term I absolutely hate the most (well, hate is a strong word isn’t it?) is: User.
To me there are the People. When the People start to play your game, those become Players. Players may become also Clients in free-to-play, if they decide to invest some money. And some of them become a Fan.
Players, Clients, Fans. Those people deserve their degree of respect. Users is a bad term, reminds me the abuse of illegal substances. I hate to say “Users”. Yet, I say it a lot because is very common used.
In this post I will try to explain the basics of the freemium economics, because without those is impossible to understand why free-to-play games have to rely on strict calculations in order to work and scale properly.
Costs
When you run a business you have costs, a f2p business has many costs that I can resume like this:
Installs: number of installs we want to achieve with our acquisition campaigns
CPI: cost per install. Each install will cost this
%FTD: first time deposit percentage. Basically, the part of Players that decides to invest something into our game
Team Members: our team is composed by…
Salary/Member: the cost per month of each member
Development Months: the number of months before of publish the complete game, ready for live operations.
If you are working right now in f2p you can notice that those numbers are VERY optimistic. Ad the end of this article I will propose something nearer to the reality. Another thing is that every company has its way of naming things, my approximation is just for the sake of explaining.
Cohorts
When you design a free to play game you should be aware of two things:
Vast majority of players (in my example 95%, but again it’s optimistic) never pays a dime
The payers have different spending profiles:
Minnows: they are the majority of payers and they invest just a little in your game
Dolphins: they are a big chunk of players and they invest a little bit more. Their spending habit is similar to PC/Console players somehow
Mermaid: they have a higher acquisitive power, and they decide to invest more over the time in your game
Whales: they are the real target of your monetization system. Without them, the f2p business is not sustainable. Here’s why:
You can clearly see that Whales are the vast minority of all payers (players that spend something). But:
With this configuration, you can see the weight on your revenue of whales and mermaids.
Results
In this perfect scenario, those are the results:
UA Cost: CPI*Number of Installs. We spent one million dollar just to get people into our game.
Team cost: Members * Salary/Member * Development Months. We spent six hundred thousand dollars to develop our game. Development costs are cheap compared to marketing.
FTD: we have fifty thousand people paying something
Revenue: according to the cohorts, the total revenue is this
RPI: revenue per install. Total revenue divided per number of installs.
Profit: what we really earn. The total revenue less the costs. In this ideal case, it works!
We don’t want to make games for whales!
Ok, let’s make a game that doesn’t permit whales to pay that much then! We believe that FOMO, pay to win and lootboxes are the evil, so that we put a maximum cap on our spend depth.
The cohort whales, then, disappears. Let’s say we just have mermaids, that will increment their presence among the cohorts:
In this case, the impact on revenue will be HUGE. Still, with the idealistic costs structure it works! we can have a business:
Diablo Resurrection
Lately, a lot of press is writing against the monetization of Diablo Immortal, the last game from Activision Blizzard. They say it’s too agressive, I have a different feeling. To me is not aggressive at all. Let’s study its costs.
The quality of this game is very high. But.. 15Gigas, really???
A game like that from a company like that will have a cost structure more similar to this:
I am completely biased here, please if you have more data let me know
With those cost structure, without targeting whales, the final result will be:
Why publish a failing game, right?
Which is why Diablo Immortal, because of its quality and narrative and everything it gives for free has to target heavily whales. This is for the vast majority of people to have fun. A possible cohort configuration can be:
For the whales to arrive spending ten thousand dollars, the spend depth of Diablo Immortal has to be high. Still, in this way our business barely works:
You work like crazy to earn $200k? I don’t think so.
So, I get that many of you don’t agree with f2p and don’t like this business model. But it exists and if you want to be there you have to do very well your math!
I have noticed in those years of carreer three main things that all successful companies share.
When we are joining a game company, many times we are just looking for a job. We study the companies and we look at their games. The most probable thing is working on a game that will not be successful. That’s a fact, there are statistics for that.
The first thing is that they have a great administrative department. They know how to keep the bills in order, how much the company is spending and what is the revenue. They are tracking their burn rate and the house it’s in order.
The second thing is that there is at least one person dedicated exclusively to quality assurance. Testing the game every single day, reporting bugs and creating processes to improve and automate the process of finding bugs. QA people save games. Games without QA will most probably just be bad games.
Ultimately, there is at least one person dedicated to community management and marketing. Games nowadays work a little like a service. Even a small indie game when published receives feedbacks and reviews and devs have to iterate inevitably. You need people dedicated exclusively to the sales, external communications and support.
If you are about to join a project with no QA people, or no administrative people or no sales/support/community people believe me: red flag! If it is your first project it may be OK according to its scope, but not expect quality, security nor players satisfaction.
This post is about ownership of the development of a feature or mechanic in a video game. Many companies say that they need people who really own the tasks they have. Ownership is very important but also a little fuzzy concept.
What I understand for ownership is different from what you mean with the same word. It is also different from reality to reality. It is not the same to own the design and development of a secondary feature than to own the core mechanic of a new game.
To me, the secret of good ownership is being able to maintain a vision while adapting to the context. The term ownership can be easily confused with property ownership. If your duty is to own some feature, the best you can do is to build on what you have, leaving the borders of your property open.
Vision
In the world of data driven development it is very easy to fall into the trap of thinking “data is everything”, repeating the same mistakes over and over or offering the same formula to the Players.
Data is not everything. Data is a resource that has to be translated into information, otherwise everything can be read. Ownership means also to be able in doing this translation. You need to make hypotheses, you need to verify those hypotheses using concrete experiments and then you can discuss how to transform the information in actions.
It is very hard having the right data ready at the start of some new implementation, so that often you need to rely on other elements to form your vision:
Your own personal experience brings inevitably something interesting to the discussion table.
Never forget that game design is also art, you should put something very personal in if you want to really engage your team and Players in your vision.
You need to know the state of the art, breaking down the same feature implemented in other games. It is not necessary to reinvent the wheel.
You need to connect with the people playing those games and really understand what it works and why.
Context
It is very unlikely to create the next f2p success with a team of 3 developers and 2 artists and no QA, right? If you have a small team, a feature can take aeons to get right. Most of the times you cannot iterate properly, your manager will pass to the next feature and your work will cripple. This happens in the majority of companies, and it is completely normal. Owning your design means accepting this and move forward. It’s hard, I know.
From the other side, it is very hard to create a fresh core loop with a team of 80 people. Politics, meetings and dispersion of the information will make you struggle to properly transmit your insight with the rest of the team. In that case, it is way better to take a strong base and then focus on improving the experience in terms of UX. Believe me, you will save a lot of stress.
Being aware of the context is very important, the magic lies where you can do the best you can with what you have. When you have the feeling that you can do everything with no limitations, it probably means that the context is not clear to the leadership nor to the team. Red flag. When you own a feature, you should try to clarify:
Goals with all the stakeholders
Concrete deadlines with weekly/bi-weekly intermediate milestones
Concrete quality expectations for the feature you own.
Final thoughts
The rise of automation is solving a lot of problems and saving us a lot of time. If we really want to be the professionals of tomorrow, we should focus our attention on providing the right solutions and vision according to the context we work in.
Ownership is one of the most important factors of the future landscape of professional game design.
I was talking with a LinkedIn contact I made recently and he told me that his company is working on a specific platform for a specific place in the US. I asked him why to target just a specific location instead than a broader region. He told me that he wants to build something very innovative and meaningful. It is not necessary to boil the Ocean, he added.
This man is completely right. We often fall into the trap of thinking too big. We know that videogames can become huge and scale tremendously. We often start to argue on scalabilty and growth before of even produce the very first demo. That attitude brings a lot of cursed design problems.
Best games start from the will to deliver the best possible gameplay to the smallest possible audience, many times. Before of 2012 very few realities were thinking in serving mature women with their games. Then the thing became huge. The games of that time scaled. It was because they were very well made.
During my entire career I have always heared the same mantra by managers: people do not like to read texts. Time passed by and I discovered that Players read when there is something really interesting from a gameplay perspective to read.
A game is a language to tell a story and many times it’s important to deliver part of this story in terms of flavor texts. Flavor texts are not critical texts, but enrich the experience with more details.
Someone read all the books in Skyrim
Flavor texts can be ignored by the Players who just want the core experience. Anyway, they foster Players to know more about the game’s world. They are an opportunity to deliver more polish to the people.
There is a new technique that facilitates the reading of texts that I think can be applied to flavor texts. It is called bionic reading.
Hypercasual games present a simple and very readable innovative mechanic. I worked on them for more than a year and I have to say that I see a similar approach to prototyping only in game jams and indie game development.
The business is not scalable anymore
Hypercasual games are part of the free-to-play business model, but heavily based on ads. The player acquisition cost has to be inferior to the ad revenue for the game to work. Then, a successful game has to scale and grow. That translates in moving a large number of people from game to game, optimizing the acquisition costs. Apple completely destroyed this concept with new privacy policies. So that hypercasual seems not to be a viable business model anymore.
Snackability, YouTubability and other important abilities
Working on hypercasual games, a game designer really understands the importance of the fundamentals. A good hypercasual game is understandable also from a single screenshot of the game. I was always fascinated by this concept, it’s like a jump into the past where the games were simple and colorful. People chose them just walking in a mall or in an arcade room giving a fast hint.
We often forget the importance of the readability of game mechanics. Mobile phones are in the pockets of a huge variety of people. If we want to broad our audience and include everyone, we should focus on delivering a fun experience without loading too much the cognitive systems of our players.
Successful hypercasual games are parodies of real life. I spent hours on social media taking inspiration for new crazy mechanics. I found this awesome. In the industry, in fact, we have the tendency in thinking in games in old terms: dragons, magic, warriors, jumping Italian plumbers and so on.
Hypercasual opened a whole new World to me!
Working on hypercasual, finally, helped me understand a lot of secrets of Unity3D engine. It is great, since the work is very technical. I don’t have to prepare too many docs and presentation, just focus on the game feel of a single concept.
I will always be thankful! This is a game I helped creating, one of the (few) hits we had:
Level Up Runner (iOS and Android)
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.