74B. Games as a Service (GaaS)

GaaS can be very profitable due to the ability to charge recurringly. This is a much more complicated product. Attempting this without the proper skill sets has contributed to the decline of AAA.

Games as a service is a broad description of a game that is provided over time, potentially many years, where players are charged repeatedly over that time in order to pay for the game, the service. The obvious advantage is that you can generate more money over the long run if players keep giving you money, instead of just giving you money up front in a retail business model. Some GaaS also charge up front and then expect more money for the player to pay for the game they just bought. This is a high risk business practice unless the game is sold as a mandatory subscription service and the player consents at purchase to keep giving money after they have given you their money.

Definitions aside, the reason that I am writing this article right after I explained why AAA is imploding is that I assume that AAA companies would rather not be imploding, and anyone reading my substack probably would prefer AAA to be successful also. In addition to the misuse/misunderstanding of how to use data in game development, the lack of understanding of how to build a GaaS game is causing AAA game devs to rapidly deplete their assets. I am a huge proponent of GaaS, that is why as a super fan who could see serious problems in the earliest GaaS games like Everquest, World of Warcraft, and EVEOnline I decided in 2005 to commit what was left of my life to solving those problems.

Without a solution to those problems, GaaS games are almost certainly going to be unsuccessful in the current environment. These games require huge budgets to have any chance of being competitive, and with such a high rate of failure risk mitigation is paramount. Just throwing “extra” content together, adding more charges for said content, and slowing progression to force players to grind/spend more for it is essentially an auto fail approach. Yet this is what we are witnessing. It is a bit like trying to build a skyscraper without an architect or an airplane without an aerospace engineer. Granted, the requisite skill sets are not taught in any university, so it can be hard for HR to know what to do about this, and most likely they don’t even know they have to hire someone other than a producer to guide said production.

There are hundreds of things that require attention and detailed coordinated planning for a GaaS to have reliable success over a span of 10+ years, like my previous designs. This does not necessarily have to add production cost or even production time. It turns out that knowing what you are going to build, how, and why actually can reduce production time and cost by 50% or more. World of Tanks Blitz was designed in 11 weeks in Minsk, Belarus, and World of Warships was designed in 14 weeks in Saint Petersburg. Overall production was swift and relatively low budget as no revisions were required. Morale was very high because everyone know what they were building and why, and how their work contributed to the overall project success.

Here I will talk about the three biggest components required in designing a GaaS, and why you need them. Omission of any will cripple your product.

What Service are you Providing?

If your customer was hungry and was looking for a product that solved that problem, you might make them some food. If they were cold you might make them some clothing. If your customer is bored/lonely/stressed/depressed then what can you give them to solve those problems? These are the typical reasons a person would seek out a long term online gaming solution.

Do you know what boredom is? Do you know what loneliness is? Do you know what it means for a person to be stressed or depressed? These are all physiological processes. While you may have a personal experience of all of these sensations, if you don’t know what these sensations are symptoms of and what part of the solution might be in our sphere, then how are you going to provide value to the consumer? You might look at a building and know it has doors and walls and you can walk around inside of it. But an architect is going to be able to describe that building in much greater and more precise detail. They will know all the components of that building, what materials to use, what order to assemble it in, and likely all relevant codes and regulations. That’s the level of detail you require when making a GaaS in order to minimize risk and production costs, and to make sure your game can weather the test of time.

For a very basic explanation of how games affect players on a physiological level, and to get an idea of how all of these systems are interconnected, I would recommend reading The Physiology of Gaming. I would recommend every GaaS developer read it. Your consumer is the human brain. Knowing a bit about it’s needs and why it might be coming to you for help can make success far less random and conversion much more certain.

Player Goals

If the player’s goal is to “have fun”, they might be able to complete that goal in an hour. If their goal is to get to “max level”, that might take them a month. When World of Warcraft came out I was one of the first 100 players to the L60 cap. It took me 8 days playing 22 hours a day (which I don’t recommend attempting). That comes out to 176 hours, and that was the Progression Lifespan of the game at launch for an expert user. Since that can be done in a month, if you are charging $15 a month subscription to the player then you are providing $15 of service. If they get the first month free with a retail purchase, then you won’t get paid at all for that service.

If your goal is $200 or higher per person from your players (which was easy for us to achieve with World of Warships) then how are you going to make that happen? What goal would make them play and spend long enough to hit that target? If you just make everything take 10 times longer, you run the risk of the player getting bored and churning out. If you have a max level cap, players could experience depression when they hit it.

Do you have sufficient social interactions included in your design to keep the player finding your product valuable long after the dopamine hits have dropped to almost zero? Can they make friends in your game? Can they peacock to random or known people and show off? Generally any activity that is dopamine generating will diminish in effect every time it is repeated. This is a safety mechanism built right into the human organism to make it addiction resistant. Do you know how to bypass those safeguards? Should you? What will happen if you do intentionally or accidentally? Do you have a plan for that?

The next (third) section can make this all much easier for you.

Cyclical, non-Cyclical, and Semi-Cyclical Content

Open world games (like World of Warcraft) where you progress until some level cap and then slam into a brick progression wall represent non-Cyclical content games. They go to some end and then instead of stopping players are expected to grind for equipment and such.

A Cyclical game goes for some period of time and then stops. The player then repeats the progression from the beginning. World of Warships or Defence of the Ancients (DotA) and its reskins (Dota2 and LoL) are Cyclical games. Players then go through the exact same game/maps but with different content. In WoWs that would be a different ship/nation pathway. In LoL that would be a different Avatar. The Cycle in WoWs might take a month per ship nationality. In LoL that cycle might last 15 minutes.

Cyclical games FAR outperform non-Cyclical games for the same development cost because they allow the developer to use the same content over and over without limiting the Progression Lifespan. Some help with Cyclical game design was provided in How to Make Healthy Games.

A Semi-Cyclical design is essentially two games in one. One is a slow progression persistent layer and inside of that is a faster moving Cyclical game that resets periodically but sends persistent content to the main game. This gives the advantages of both game types and allows for better peacocking since some content does not recycle. As you can imagine, this is a very complicated design. The upside should be much higher revenue generation than a non-Cyclical game and longer lifespan than a Cyclical game. The only example I could cite would be the super secret mega MMORTS being built at Chris Taylor’s Wargaming Seattle (greenlit in 2014) facility, formerly called Gas Powered Games. Chris’ game was terminated by Wargaming just prior to him and I leaving the company.

[Game Economy]

An economy could be a fourth element of a GaaS but it is entirely optional. An economy as I define it involves player to player trade and interdependencies. The purpose of a game economy is to create a social glue between players through these interdependencies. That social/economic interdependency is critical for human health, both in and out of games, as we are very social creatures.

Honestly though, a game economy can have catastrophic consequences if you make even a small error, like how Axie Infinity got hacked for 650 million USD! Thus I would not even attempt it in a web2 environment unless you have already launched a successful GaaS game without an economy. If you want to make a web3 game, you will need a game economy almost by definition. So far no game economy has been successfully launched in web3. I would define success as the entire economy holding at least 90% of its value per month. Similarly, this has also not been achieved in web2. It will happen, hopefully in my lifetime as much of my early research was focused on creating the technology for sustainable game economies. Without those technologies this is really a a bad idea to attempt in a GaaS.

The economy of my web3 Gods Unchained game was perhaps one of the most successful game economies in web3 or web2, though I designed it in 3 weeks and it does not contain the level of interdependencies necessary to create a full game economy.

Wrapping Up

I would recommend that developers take the process of making a GaaS a lot more seriously than they are currently. Right now they just slap something together without much planning. That planning doesn’t need to take a really long time (as evidenced by my last 3 successful “to market” GaaS games taking 11 weeks, 14 weeks, and 3 weeks respectively to design), but that time is going to be dependent on the training and experience of your designers. If you can’t get all the key people on your team then you should consider making something simpler and staying out of GaaS as it will just end up being a money pit for your company. If you can handle the three key elements described in this paper, you should be in fairly safe territory.

[I originally listed StarGarden as a semi-Cyclical game but deleted this as it is a murky example. It is very difficult to do hard resets in web3 games when player own utility items, so StarGarden would be better described as non-Cyclical.]