Discoverability as a Productivity Problem

Gamers are less willing to subsidize inefficiency in game production than they have been in the past. This is a product of independent gaming’s success which has resulted in more developers being supported while simultaneously introducing more competition. This more competitive environment has been characterized through the discoverability problem, where games struggle to get attention in an increasingly crowded marketplace. While discoverability is a real concern, focus on such a narrow problem has left us unaware of a broader productivity problem in gaming. This article is the first in a series of two, and will describe and argue for the existence of the productivity problem.

A simple model of discoverability

We will begin with a model of discoverability, because it is better known and will provide us an example of working with a model. We will eventually use this model to support the claim that discoverability is a subset of the productivity problem.

The model begins with game developers. Game developers are production functions that take a set of inputs (workers, computers, licenses) and transforms them into an output (games). Here we will consider output measured in revenue, and three coarse inputs: labour, capital (computers, licenses), and marketing, a carve out from labour and capital that is dedicated to outreach. Successful development is finding an allocation of inputs that produces revenue that is equal to or greater than their cost.

We also require some assumptions. Production functions can take any form, and can differ between developers, but any allocation that assigns 0 to any of the inputs results in 0 revenue. This should be intuitive and lines up with common thoughts about discoverability. A game without computers remains an idea, and a game without workers is an idle computer. While no marketing probably does not actually result in 0 (Steam’s algorithms are better than it gets credit for), we treat it as good as 0 for simplicity. This essentially says that the algorithm augments marketing rather than replaces it.

Within the model we can categorize two types of discoverability advice. One is geared towards a better allocation of resources. The simplest example of this is convincing a developer to invest in marketing in the first place, which goes from 0 to some positive number, which, in turn, produces some positive value for revenue (assuming the other inputs have something). Essentially this is the model saying that marketing is as essential as any other aspect of development. This would not convince someone who believes that a developer only needs to make a good game, since this conclusion comes directly from the assumptions. Whether the recommendation is spending on marketing (in time or money) at all or simply spending more of it, the premise of this advice is that developers can achieve better outcomes through better resource allocations, and discoverability is just a specific focus on the marketing component.

The second type of advice attempts to modify the production function. That is, it attempts to make each hour spent on outreach have more impact. Without further restrictions on the production function, the set of developers can include everything from someone who takes 30 hours to compile a list and e-mail 1,000 streamers with a generic key offer to a sophisticated operation like Bungie with a dedicated team. The aim is still to achieve a better outcome in the form of more revenue, but it comes from a more efficient use of the existing resources rather than a different allocation.

Both types of advice have their place, and both are unified by the idea that developers can achieve success by generating more revenue to cover the costs of production or improve profits. This is a simplification of a very popular type of article, but it is intended to illustrate the mechanisms through which the advice works and provide an example of how we can learn about a complex topic through a simple model.

The limits of the discoverability framing

To see the limits of a discoverability framing, let us consider a developer that is neglecting an input that isn’t marketing. We know the game isn’t generating revenue because of the assumptions, and that this is the same outcome as when nothing is spent on marketing. The outcome does not tell us anything about the nature of the problem. The same diagnostic problem exists when we are merely underinvesting in an input.

The worst advice for the developer in this hypothetical would be to put more effort into outreach, and yet this is the most likely advice they would receive. The problem isn’t thinking about discoverability in the first place so much as the tendency for it to become a default explanation.

Discoverability is a seductive default because the idea that an unsuccessful game “didn’t find its audience” is obviously true, but its lack of explanatory power isn’t immediately obvious. It is a bit like explaining a political outcome as ‘more people voted for the winning outcome’ in that it is true while telling us very little about why this outcome came about.

If we know the problem is a discoverability problem, then the vast literature is helpful. The difficulty is that we may not know the nature of the problem. Models are useful in that they let us consider cases like where a developer underinvests in something other than marketing. Developers are resource constrained, and so these scenarios is not merely academic. Unfortunately, all the model really does is assert a developer has over or underinvested in an input without any explanation. We will develop an alternative to get closer to an explanation.

Accounting for productivity

The broader perspective this article will be considering is a productivity framework, and so we should start by defining productivity. Productivity is the ability to do more with the same or fewer resources. If I make a cup of coffee by bringing each item over one at a time, this will take a certain amount of time. If I bring everything over in one trip and make the coffee instead, I will make the same cup in less time. I have become more productive.

Even a simple illustration like a cup of coffee introduces complications. What about a coffee machine? The coffee machine improves my labour productivity, but the overall productivity improvement is ambiguous because we are comparing different things. Coffee shops improve productivity through acquiring new and better coffee machines all the time, but if I employing such a machine to brew a single cup in the morning, this is almost certainly a waste.

We are most interested in the kind of total productivity improvement that is associated with finding a better way of doing things. Taking an office from paper to digital involves acquiring capital, but carries with it productivity gains beyond simply buying new computers. For gaming this means improvements that allows developers to create better games at lower cost, usually by rearranging existing resources or putting them to better use.

A model of how customers pick games

We are focusing on productivity in order to come up with a better explanation for the outcomes we see in the market, and so we will introduce another model. This model deals with consumer choice.

In this model, developers must still develop games in such a way that revenue exceeds the costs of inputs, but this revenue is not calculated directly. Instead, revenue comes from a customer’s decision to buy a game. We won’t focus too much on inputs but it might be helpful to imagine more finer grained ones than we used above (instead of one labour measure, we could use specific measures for junior programmer, senior level designer, and so on).

One challenge is that games have tremendous variety that needs to be accounted for. Ideally we could reduce games down to one feature that matters. To do so, we will use a quality adjusted price, which we will call the real price. In essence, all games are reduced down to grey boxes with the word ‘GAME’ written on them, and the customer buys the ones with the lowest quality adjusted price until they are satisfied. This is a bit like buying apples in a grocery store in that you don’t care if it’s the EA apple or the Ubisoft apple so much as which one costs less.

It is not natural to think of games this way, so an example of a quality adjustment is in order. FTL: Faster Than Light (affiliate link) is an excellent game, available for $10.99 CDN right now. Even at full price, this is a great deal, since FTL provides the value of a more expensive game at a modest price. This value could be demonstrated through an experiment in which people get to choose to spend $10.99 on FTL or a randomly chosen game from the $10.99 cohort, since the likely outcome would almost certainly show a strong preference for FTL.

We can imagine running another experiment in which the choice is still between FTL and spending $10.99 on a game from that cohort, except that the price for FTL gets increased a little bit on each iteration. Once the results show an even split between FTL and random games we would know FTL was no longer a ‘good deal’ (in the sense of providing value in excess of its cost) and the difference between that price and $10.99 would quantify the quality of FTL in dollars.

In the model all the nominal prices are adjusted with higher quality games going down, and the lower quality games going up (this prevents the Unity Roll-a-Ball tutorial being listed on Steam at the lowest price and becoming a best seller). The resulting real prices establish an ordering of games from which a customer will make their choice.

The final step is to apply an individual adjustment for each customer to the real price to account for their idiosyncratic tastes. This adjustment serves a purpose beyond just making sure 4X fanatics pick the right game. Up to this point, one might reasonably wonder why FTL does not represent a price ceiling for every other indie game. The reason is that FTL does not confer value for each additional copy. I already own FTL and so its real price shoots up to some impossibly high number, and I choose the next game with the lowest value until I am satisfied.

To recap, developers make games using a series of inputs and those games are bought for the nominal price by customers. Customers choose which game they will buy based on the real price, which is a reflection of its underlying quality and their own individual preferences (this is a complicated way of saying people buy the things they like). Successful development is an allocation of inputs that generate enough revenue to cover their costs, but that revenue is a function of the choice described above.

What does the model tell us?

The discoverability framing achieved successful development by raising revenue, and so we will start there. What happens if developers raise the nominal price but don’t change anything else? Provided the real price does not go above the next best alternative the customer has, the developer makes more money.

While there are cases where raising the price will increase overall revenue (specifically when the good is inelastic), this does not describe the gaming market very well. Price decreases may attract enough customers to outweigh the cost, but if any group is familiar with discounting, it’s game developers. The final option is quality change.

Quality change can have an air of a certain kind of smug ‘just make a better game’ advice, but, from our definitions, it can be as simple as an accumulation of small improvements. The most likely source of positive quality change is productivity improvements, whether it’s better understanding the tools, or something more nebulous like improving the communication between teams to generate more ideas and implement them faster.

Productivity improvements also have the virtue of helping the other part of the equation in that a game that costs less needs to earn less to be profitable. Few developers would turn away these kinds of benefits, and yet we develop habits that turn us away from them. We can see this by considering a situation in which we might be able to get away with a nominal price increase.

Imagine we are in the early days of independent games on Steam. The storefront isn’t perfectly divided between large publishers and independents, but it would be fair to say that there are gaps in the market that the independents fill. The incumbents produce premium titles that attempt to appeal to a mass audience, while the independent games are more narrowly focused on experiences that are not being provided.

In such an environment there is potentially quite a large gap in the real price between our game and the next best alternative. If that gap is, say, $2, then we could conceivably raise the price by $1.90 and expect to see our revenue increase by about that much for each unit we expect to sell. This gap exists because there are fewer participants and they are targeting different segments.

In practice, not every developer would look at an opportunity like this and directly see it as an opportunity to maximize profits. Instead, these price increases to enter in through inefficiency, like spending more time on ‘polish’ than may actually be warranted, along with other tendencies which don’t amount to much individually, but add up over time. These become part of a developer’s production function, and so the price increase is realized as the developer setting a price that reflects the costs of production they observe. We’re back to walking across the kitchen each step in making a coffee.

With the arrival of more developers, there are more alternatives that will align with what a potential customer is interested in. The gaps between alternatives narrow, so that difference of $1.90 may suddenly mean that people pick the alternative simply because it represents a better value. Productivity matters in a way that it did not before. While it is not favourable to producers, this is precisely the reason why governments encourage competition.

There is good news and bad news in this state. The hard truth is that there are a great many games in production now that are simply not feasible from a profitability standpoint. In terms of the model, the production function of some developers does not produce a game that can cover the costs of development, no matter what the inputs are.

This is what I mean when I say that a discoverability problem is a productivity problem. Trivially it is a misallocation of resources, whether in the broad sense (not enough allocated to marketing) or the narrow sense (the specific spending on marketing is not being used effectively). In a more substantive sense it is because many games have priced themselves out of the market due to lagging productivity. Developers should expect to be fairly paid for their effort, but customers also expect value for their money, and today’s standards are high. To use another coffee analogy, being good at latte art does not imply success as a cafe owner, since success as a cafe owner involves organizing many factors that are not obviously part of the product.

What do we do about this?

The good news is that this environment is one that expects us to do our best work but also enables it. There are developers operating today that have quit their day jobs before learning basic functions of Unity. Such developers are not bad people or somehow uniquely deserving of financial distress, but it should be clear why the current environment cannot accommodate them.

This is good news because these kinds of problems have straightforward solutions. There are few industries in the world that support firms that do not bother to learn the basics of their craft, and there are countless resources available to develop those skills. Even when it comes to business skills, workers who are talented in one area have been promoted to management roles and have flourished. In fact, large companies have entire systems in place to mange this kind of transition. If the problem were developing relevant ideas that resonate in the current cultural climate, then I would be concerned, because it is not at all clear what causes cultural flourishing or stagnation, but the one thing we don’t seem to be short of right now is ideas.

This is not to understate the difficulty of the challenge. Success will involve more than learning the basics. However, learning the basics will also likely allow a developer’s specializations to finally be realized in a viable product, and so the results will be greater than expected. The willingness to improve skills have already been demonstrated through the appetite for specialized articles on approaches to outreach, the only difference here is that the focus is on a broader skill set.

Less direct approaches

Not every success is the product of a single minded obsession with doing things as quickly or inexpensively as possible. There are games that have successfully defined a niche for themselves. This can be seen as analogous to widening the gap between itself and the next best game again simply because there isn’t anything else like it. Developers have a monopoly on their individual creation. By foregoing mass appeal the developers appeal to the idiosyncratic preferences of their intended audience, lowering the real price for those customers.

Other developers specialize in games that align with their skills. Someone with a gift for a turn of phrase may not rush to make a first person shooter, while procedural generation mavens can be found making roguelikes. These skills probably have their origin in an interest in these topics, but from a production standpoint these are the aspects most likely to create the largest return for their effort. They are the most productive.

This brings me to one final and unfortunate point. While it is natural to wonder how any given developer can become more productive, there isn’t any generic advice that can apply here. To see why, let us consider one of the biggest general productivity boosts over the last decade: high-quality and affordable game development tools.

The cost of paid products have fallen in price, even as their capabilities have increased, and almost every single one has an effectively free alternative. Not only are the costs of the tools negligible, but the tools are widespread enough now that there is a common skill set to draw on, making it easier to integrate people into teams. This has brought about massive productivity gains across the gaming industry and is the reason we enjoy so many high quality titles at such low prices today.

But it is precisely because these improvements are widely available that this kind of productivity improvement does not result in more sales for one game or another. If every game is able to adopt the technology, then all products improve, and so the ranking for the customer remains unchanged. The best that generic productivity advice can offer is a temporary advantage while it transmits through the industry on the way to becoming a best practice.

The type of advice that will help developers achieve and maintain profitability will be unique to them or, at best, a handful of similar cases. Some developers may find simpler gains by adopting best practices that haven’t already been brought on, but improvements on the frontier are going to be found from looking inward. Intuitively we know this is true, since what works at Naughty Dog is not going to apply to a two person team. The productivity framework is intended to present a way of thinking about specific ways in which certain actions affect the overall outcome. Sometimes it will mean finding a way of doing something faster, and sometimes it will mean doubling down on something so it can really deliver the goods.

Summing Up

This has been a long article on a complicated subject, and so a summary is in order. While discoverability remains a real concern for games in today’s marketplace, there is a large and unrecognized productivity problem in gaming as well. This productivity problem is severe enough that a meaningful number of games would not be profitable, even if they were to get an ideal marketing budget. Focusing on productivity allows a developer to consider both the cost and the revenue side of profitability. Such a view does not replace discoverability as an objective, but rather sees it as one part in an overall production process. It is a framework intended to help developers identify where their efforts are best spent to do their best work.

While this article has offered a perspective, it has little to say about causes. The next article will be more speculative and offer specific reasons why game development may be experiencing productivity problems now.