Calculating the Game Engine Market Size – Determine the Market Size for Game Engine Software

This question on Quora "How do I determine the consumer market size for game engine software?” peaked my interest. Here’s my reply:


Determine the game engine market size

VALUE vs REVENUE

Before we start estimating the market size for game engines, let's decide exactly what we want to find out - is it the VALUE game engines generate, or the REVENUE?

REVENUE is the about of money spent on game engines, VALUE is how much value, in dollar-terms, game engines create. VALUE is the REVENUE potential for the game engine industry. (Note: it is possible for REVENUE to exceed VALUE if the value chain around the industry has the capacity for it.) REVENUE is determined by how much of that value is captured by game engine companies today.

For example, you hire a personal assistant to help you draft an email. You pay the assistant $25 for drafting the email, which would have taken you half an hour if you were to write it yourself during your work day. If you make $120 per hour during work hours, the personal assistant has saved you half an hour - which has the value of $120x0.5hr=$60 (VALUE generated by assistant). However you only paid the assistant $25 for the work (REVENUE).

So in this example, for the "email drafting market by this PA" is:

  • Value: $50
  • Revenue: $25

The model you create differs depending on which one you are estimating. For game engines, Value will include value of internal game engines (tools and middleware built in-house in game companies to produce their own games - how much time and cost are saved from these) while Revenue will be mostly sales from game engine companies.

Market Sizing Steps

In general, estimating a market consists of three basic steps:

  1. Define the model/formula
  2. Make assumptions
  3. Validate assumptions

Model - REVENUE

Let's assume we want to find out the revenue generated from selling game engines. There are in general two ways to model your estimate: Top-down vs Bottom-up.

Top-down

A top-down approach essentially means you start from the top - a big number about a very broadly defined market, and then drill down to the specifically defined market you are estimating.

For example, you might say the total amount of money spent on B2B computer software is a $100 billion dollars (all numbers in this example are made up), and computer graphics related software is 10% of that, which gives you $10B. Then you find out that out of the $10B computer graphics B2B software, 5% is on 3D software, 2% on vector graphics, 7% on photo imaging, and 3% on animations. Let's say we want to look at 3D game engines only, we multiply $10B by 5% = $500 million. Finally, we found that 30% of all 3D software has features to create interactions - a key feature for games. So we multiply $500 million with 30% and get to $150 millions. That's our estimated market size for 3D game engines from a top-down approach in this example. Again all numbers are made up in this example.

You'll often have to figure out a way to define the percentages - make assumptions and validate them. It's rare to have all these numbers available to you. One way of finding these percentages is by looking at company annual reports and see how much they are spending on particular areas, or look at the sales numbers of all companies in one industry and benchmark against a different industry. Lots of creative ways to come up with these as long as you can back up your reasoning.

Bottom-up

A bottom-up approach starts from looking at the smallest unit of sales and then scale up. You evaluate how many potential buyers are out there (number of game companies, individuals game developers, non-gaming developers who might use game engines for other purposes...etc.), how much are they spending on average, where sales can take place (game engines + comparable substitutes), how often they are sold, how many distribution channels are available, how many international markets are game engines available, localization...etc. The list goes on and on but the point is with a bottom-up approach, you try to get to the top revenue number by scaling small set of sales continuously.

For example, let's say we want to estimate the market size (revenue) for game engines for board games. Let's start by finding out the number of board game production companies in the US - say 250 (all numbers are again made up in the example). They on average spend $1000 per developer every other year, and their average size is 5. So every year, each company spends $1000x5x(1/2) = $2500. That gives us 250x$2500 = $625,000 for all the companies in the US. Let's say we found out that US board game production companies represent 25% of all board game production companies in the world. Assuming all board game production companies spend the same amount in the world, $625,000/25% = $2,500,000 would be the world annual revenue for game engine for board games.

That is just one example of modeling using a bottom-up approach. There are many different ways you can structure your model / defined your formula. The bottom-up approach usually requires more work but can provide good solid foundations for your model.

Model - VALUE

Estimating the value game engines produce requires a bit of imagination - we want to find out not just how much money is spent on game engines but also the invisible VALUE that's been generated from these software - in-house engines, pirated copies, value generated from free/open-source middleware...etc.

Again, we can use either the Top-down approach or the Bottom-up approach. Let's do a quick thought exercise using the top-down approach:

Let's say the global mobile gaming market is $20B in 2014, and mobile represents 50% of total gaming market (again all numbers in the example are made up). That gives us a total of $50B for the consumer gaming market. $50B is the total VALUE generated from all the activities required to deliver all the games in the world into consumers hands. Now how much of that $50B can be attributed to game engines? Let's look at this rough value chain for the game industry:

Resources (capital) => Pre-production => Production => Distribution => Platform => Retail => Consumer

(Not a complete value chain for the industry - simplified and some layers might be overlapping and parallel to another.)

Each layer adds more value to the product until it reaches the consumer. If we know how much value each layer is attributing to the total value, we can start getting to know how much value game engines are responsible for.

Game engines are in the production layer. If we can say production accounts for 20% of the total value, and game engines account for 15% of the production layer, the VALUE game engines generate in the game industry would be $40Bx20%x15%=$1.2B.

How do we find out the percentage for each layer? This is where we'll have to make assumptions and try to back up our logic. Let's say Resources is $2B global invested amount in gaming. That accounts for 5% of the value (of the total $40B). Then we can look at big gaming companies and see how they spend their money - how much on pre-production, how much on production - to get a percentage of those two. For distribution, platform, and retail values, we can look at how much of a cut they take (ex. physical retail takes 50%, App Stores take 30%) to estimate their percentage of values attributed.

Again this is all very rough and numbers are for the most part made up in the examples.

The reason why I choose a top-down approach for the VALUE estimation is because this takes care of different ways game engines produce value. If we do a bottom-up approach, we will have to list out all the different ways a game engine can add value - in-house engine, open-source engine, art software with interactive features, different degrees of tools (ex.what do we consider an Engine and a Kit?)...etc. It can get pretty complicated very quickly. When we look at the value generated from an industry, most of the time we just want to get a sense of how big it is - so even though a top-down approach might not give you the granularity, it can give us a quick rough idea of what we need.

Comments