World Builders 2023: Preparing a business plan for a game on Steam ru en

Notes on my participation in World Builders:

When I posted my final presentation [ru] (slides) for World Builders 2023 (my posts, site), I promised to tell how I made a roadmap and a financial model for the game. So, here they are.

At the end of this post, we will have:

• A brief strategy of our company: what we do, how, and why.
• A table with our beacons — successful games roughly similar to what we want to make. Similar in gameplay, team size, budget, etc.
• A composition of the team we need to assemble.
• A roadmap — a development plan for our game.
• An outline of our marketing strategy.
• A financial model — how much we will spend, how much we will earn.
• A large number of my caveats throughout the post.
• Jokes and I hope witty remarks.

All the final documents can be found here.

Disclaimer

In case you lose millions of dollars following this post, and gloomy guys come to you with questions, please do not redirect them to me. Take responsibility with your head held high, even if your legs are already set in concrete. Just kidding, do not deal with non-specialized investors, and your health will be fine.

Here is why you should critically look at this tutorial:

• I'm not a professional businessman. I had a business and spent more on it than I earned.
• This is the best of two business plans I've ever made. The fact that it is the best does not cancel the fact that it is the second.
• I have not yet received money for it, and even the person looking for investors is not me. So, I do not know how investors will react to these calculations.
• This business plan was prepared as part of my studies, not as part of "I put my soul into opening my company and investing all my time and resources into it."
• It is possible to make it 100500 times better, but I did not. Pa-ra-pa-pam. Because there was no time, and sometimes I was lazy.

Iterative development

During the reading, it may seem that all the work can be done sequentially from beginning to end. This is not the case. I post-factum organized everything into a narrative form to save you from jumping chaotically between documents.

So.

Define company strategy

Imagine, for some reason, you've decided to make a game for the indie developers' graveyard Steam. And it's a single-player sandbox strategy game (see presentation if you are interested). Maybe with multiplayer, but you're not sure yet.

Listing the possible reasons for these decisions is beyond the scope of this essay.

For example, if you focus on earning money (why then go into gamedev?), you should find reports on different platforms, see which genres make money on which platform, evaluate the average team size, investments, and development time, and make a weighted decision to create a free-to-play mobile MMORPG for low-grade mobiles in the African market or something like that. Just in case, I'm serious about Africa.

Choosing monetization the main financial flow

There are several approaches to monetizing games on Steam:

1. Through major releases.
2. Through selling DLC — Downloadable Content.
3. Through microtransactions

In my world model, the company should aim for one thing and use the rest as an additional source of income. If you try to catch two hares, you usually catch none.

I will not consider microtransactions, as in the field of single-player PC games, only AAA studios now how can allow themselves to do so, and only through giant marketing budgets and reputation loss. Indie developers will be buried alive by the Steam community for such a thing, and rightly so. Not to mention, I have no desire to mess up my karma.

Therefore, we have several options for the basic strategy:

1. Make a major release of "My Mega Game". Move on to something else.
2. Make a major release of "My Mega Game". Move on to something similar: make a sci-fi strategy after a fantasy one.
3. Make a major release of "My Mega Game". Make a major release of "My Mega Game 2". Make a major release of "My Mega Game 3". And so on.
4. Make a major release of "My Mega Game". Release a couple of DLCs. In parallel, work on something based on plan 2 or 3.
5. Make a major release of "My Mega Game". Endlessly release DLCs.

There was a concept of add-ons in the old days, but for simplicity, we will consider them the same as DLCs. At least, I don't see any significant differences for the purposes of this post.

Option 1, in my opinion, is almost never practiced now, in the case of a successful product. It wastes a lot of resources: the team's expertise, the code, the pool of freelance specialists, and the community are all lost. It's not very profitable. But some especially dedicated indie developers might do it just for fun.

Options 2 and 3 are close. They can even be alternated. They allow you to reuse more artifacts of work than option 1. The downside is a very uneven flow of money, and it's not guaranteed, which means holes in the budget.

The series of big releases is a risky venture. Therefore, in case of the success of the first release, many developers try to release at least a few DLCs to support the development of the next game. Which brings us to the fourth option.

Option 4 — releasing DLC in parallel with the development of the next game is a good way to reduce risks and make the life of the studio more predictable.

The problem with this approach is that not all teams can make a game that will be relatively easy to modify interestingly for players. Plus, not all genres are well suited for DLC.

For example, RPGs make it challenging to add each subsequent DLC because the game follows a single narrative. This makes it difficult to change mechanics (due to a campaign balance) and to extend the story (since good games are released with a complete and consistent storyline).

But if we don't have such problems, we can look at option 5 — replacing the main money flow from the releases of new games to the releases of DLCs. I call it the Paradox way because they are the best at it, as I see it.

The first release still brings a significant share of income, but the development focus is initially on the production of DLCs, which eventually outweighs the profit from the first release.

Massprodusing DLCs

The efficient, well-organized production of DLCs is great for two reasons.

Firstly, it forms a resilient developing ecosystem uniting the company and the player community:

1. With each released DLC, you improve the base game, tune it to a specific niche, and eventually become a monopolist in it.
2. Improved base game continues to be bought by players for whom it was not so good before. Therefore, your community continues to grow long after the release.
3. A strong community provides quick and high-quality feedback for your decisions, leading to the release of better DLCs. Good DLCs improve the game. The improved game attracts people to the community. The community provides even better feedback.

Secondly, you get a predictable cash flow:

1. The period between money inflows decreases from 1-2 years to 3-6 months.
2. The risks associated with errors are reduced. In case of a failed major release, studios often close. In case of a failed DLC, you release the next one. The studio lives as long as it can learn from its mistakes.
3. You sell DLCs not to random people but to your players. This makes marketing cheaper and income more predictable. You know how many people play your game and what percentage bought the previous DLC, so you can estimate how much money the next one will bring.

However, there are downsides:

• It works not with all genres. I think only with strategies and maybe sandboxes.
• The first release must still be quite noticeable and high-quality to form the core of your community. Paradox can afford to release mediocre products (judging by the reviews) and then polish them. But this is more of an exception — they are forgiven.
• You should know how to make games and how to listen to players. Not everyone can do this, and not everyone wants to.

Since we are making both a strategy and a sandbox, and in a free genre (public opinion simulation), we can risk and aim for the fifth option. In case of problems with organizing a pipeline for DLC production or with quality, we can always switch to the fourth option.

Early Access

An experienced developer may have noticed that I have bypassed Early Access.

I did this for several reasons:

• Now it is de facto standard. There is no point in skipping Early Access. The earlier you do Early Access, the earlier you get feedback from the universe [ru], the earlier you fix mistakes, the better the game will be.
• From my point of view, what exactly to release in Early Access is defined not by monetization but by marketing, team capabilities, and investors' wishes.

There are two poles:

1. Full release in Early Access. We release what we would release in a regular release, only now we are forgiven more bugs, and the team is calmly working on the day-one, week-one, month-one, year-one patches. When everything is sold, we make a release to highlight the game for players who, for some reason, missed Early Access.
2. "Quiet" release in Early Access. We release a minimal, consistent integral game but significantly cut its features. We work hard to polish and improve the game based on players' feedback. When the game is ready, we make a "loud" release.

In my opinion, the second approach is unconditionally more effective. It provides feedback much earlier, which inevitably increases the quality of development at its final stage — if the team is ready to hear feedback, of course.

But not everyone can afford this:

• There is a risk of wrongly defining what a "minimal integral game" is. If you release the wrong thing, you will quickly fall into the limbo. You may not receive money for the final development stage if you have financing by rounds.
• Your game may be initially designed minimally, for example, due to budget constraints. That is, you will have nothing to cut from it.
• Marketers or investors will shift the development schedule so that you simply cannot release with the necessary set of features: "full release by Christmas or death."

Final strategy

1. We are making a sandbox strategy for Steam.
2. We are focusing on the long-term release of a large number of DLCs.
3. We aim for a "quiet" release in Early Access, cultivating a community, actively exploiting feedback, and making a "loud" release when the game is ready.
4. If the release of DLCs isn’t financially effective enough, we shift to developing a new game (a sequel or a game in the nearby genre) while still supporting the first game with a few additional DLCs.

Based on this strategy and our understanding of gamedev, we can describe the major stages of our work.

Roadmap

Now, we need to estimate the amount of work. To do this, we unfold the stages of development into large tasks and estimate the time required to complete them.

The final roadmap can be found here.

The roadmap consists of three tables. For convenience, I highlighted their headers in color:

• The Red table contains all the major tasks we need to do.
• The Blue table shows the volume of tasks by tracks and stages.
• The Green table calculates the final time estimate for each stage.

We fill in the red table.

The Blue and Green tables are calculated semi-automatically: we set part of the values, and we take part from other tables. The Blue is calculated based on the Red, and the Green is calculated based on the Blue.

Red table

Here is an example from the beginning of the table, if you are too lazy to open the original:

Columns:

• Stage — the development stage at which we need to complete the task.
• Epic — a large piece of work that we do as a team.
• Task — a piece of an epic that should be done by specific specialists, such as developers or game designers.
• Track — what specialists do this task: developers, designers, marketers, etc. I'll explain why the column is called Track below.
• Estimation — our time estimate for the task.
• Comments — any additional comments.

What is a track

In any project, you can always highlight several streams of tasks that would be nice (but not always possible) to perform all the time, for example, by taking one task per week. Otherwise, some parts of the project will degrade.

The simplest example from gamedev are tracks of development, game design, and art.

Therefore, in an ideal project with an unlimited budget, work is always going on for each track to ensure the project grows evenly, organically.

Note that tracks should not be confused with roles, positions, or competencies. Above, I gave an example of high-level tracks. Here is an example of more specialized tracks for web development:

• business logic development;
• improving/maintaining the project's controllability: metrics, logs, tests;
• improving/maintaining security level;
• improving/maintaining performance.

Business always usually has a habit of ignoring tasks from not-so-mandatory-and-noticeable tracks that do-not-bring-value-directly. For example, tasks to improve project controllability might get dismissed because "everything is fine now."

But the catch is that the debt in track grows like a snowball, snowflake by snowflake. If you don’t pay it off, eventually disaster strikes: all new features get postponed in favor of urgent fixes using quick-and-dirty solutions. This leads to significant disruptions in the business’s planning and, on top of that, to deep-rooted project degradation, which further derails planning over time, creating a vicious cycle.

That's why the project leader's goal is to keep all tracks active.

Accordingly, when starting to make a table, I decided to describe tasks by tracks, assuming that:

• the list of tracks will be determined as we go;
• at each stage on each track there will be some amount of work.

In fact, in our specific case, we could use roles instead of tracks. But if the project were larger, the tracks would be more diverse. For example, game design could be divided into tracks of level design, mechanics, and narrative.

Also, it is not guaranteed that as the product develops and the team grows, we will not want to increase the details of our plans.

How to break down epics into tasks

The most important thing is to have a sense of balance. With all our desire, we cannot know the complete list of interface elements, sounds, mechanics, and whatever else will be in the final game. Therefore, there is no point in making such a list.

Instead, we should define work in large chunks, focusing on common sense and our own experience.

If you have no experience, use common sense only. :-) Then, find an experienced friend and ask them to check your work. Doing the opposite (finding a person to do this work for you) is not recommended, as the person will leave, and you will be left with an artifact you do not understand.

Of course, it is okay to delegate task breakdown to a team member (who has signed up to work with you further). Even cooler is doing it together as a team. I don't have a team for now, so I did it myself.

In our strategy, we briefly defined the goals of each development stage and the expected result upon its completion.

For example, for the Alpha version:

• Goal: Implement core game mechanics.
• Expected result: The PC game where you can play 1 game session and have some fun.

Knowing what game we are making, we can define what should be ready to complete this stage:

• Minimum game design description.
• Minimum user interface.
• Minimum game mechanics. In our case, it is a map, news channels, and events investigation.
• Some content.

We should complete these tasks as a team, but each epic contains a different amount of work for various specialists. Therefore, we should break them down into tracks.

For example, we know that we need a map in our game — it is our epic Implement game map.

• What sort of map? Who knows. So, we create research tasks on two tracks:
  • game design — what should be on the map, how it should work;
  • art — how it should look.
• Of course, we need to implement it, so we will create a task on the development track.
• It would be great to have a procedural map generation. But it is definitely not required for the Alpha version. So, we create additional epics and tasks for the Beta and Early Access stages.

Besides the straightforward epics, there is an invisible work that is also mandatory. We cannot forget about it. Here are examples from my roadmap:

• Moving the game logic from the prototype to the real project. This is necessary because the prototype was developed using technologies that are convenient for prototyping (web), not for creating a game for Steam.
• Developing tools for game designers to speed up their work.
• Playtests at the end of each stage and game improvement based on their results.
• Development of QA approaches for content quality assessment. There will be procedural story generation in the game. Therefore, we need to somehow assess the generated stories' lower quality boundary. Are they diverse enough? Do they involve all NPCs? In other words, we need to protect ourselves from a random total failure when the generation algorithm starts to produce complete nonsense due to a bug in it. It is difficult for developers to notice such statistical phenomena because they cannot play full game sessions all day long (they have work to do).
• Worldbuilding for the game. A consistent, solid context will make it easier for game designers and artists to keep their work in sync.
• Validating and setting up diversity in the game. We are making a game about a modern metropolis, so we need to represent people of different races, views, and abilities.
• Tutorial.
• Creating the Newspedia (like Civilopedia in the Civilization series). The game will have many nuances, and we need to help players navigate them.
• Tasks on community building and working with it.
• Infrastructure for tracking game errors and metrics.
• Something fun for the Deluxe version, which we will sell a little more expensive.
• Modding support.
• Adaptation for people with disabilities.
• Wiki for the community.

Tasks estimation

Estimations are a complex and tricky question. The specific approach depends on your experience.

There are two main approaches:

• Estimation in story points — abstract units of complexity. For example, you state that the simplest task is worth one point and then estimate all other tasks proportionally to it. When everything is estimated, you convert points to working time at some rate.
• Estimation in ideal working time from the start.

For my personal needs, I usually estimate work in "ideal working days" (when no one and nothing distracts the worker). I chose the same approach for the roadmap. But for joint estimation in a team, it is better to use story points.

Blue table

After we have described all the work, we can find out how much time each track will take at each stage of development. This will allow us to estimate the number of employees required for each track so that the work is done evenly.

For this, we group the Red table by the triple stage + epic + track and sum the working time in them.

Columns:

• Stage — development stage.
• Track — track.
• Sum — total amount of work on the track at the stage in days.
• Workers — the number of employees that will be on the track at the stage. The fractional part is the share of my time that I can allocate to help. I will tell how to choose the number of employees for the tracks later.
• Workdays — the number of working days per person.
• Work Months — the number of working months that will take the track at the stage.

We convert the working time to (working) months because our estimates are very rough, and later, no one will need to know the "exact" number of days.

Green table

The Blue table gives us the lower (optimistic) estimate of the duration of each stage for our team (which we will talk about a bit later).

The goal of the Green table is to convert the optimistic estimate into a realistic one in a calendar time.

For this, we:

• Set the time of each stage equal to the duration of the longest track on it.
• Increase it by different smart coefficients.
• Round up because there is no limit to pessimism in software development.

Columns:

• Stage — development stage.
• Max — the duration of the stage in months. It is equal to the duration of the longest track on the stage.
• Forgotten Work — our estimate of the share of work that we forgot to include in the stage. The coefficient increases with time because we see the first stages better than the last ones. Work on the last stages will significantly differ from the plan due to the accumulation of mistakes in our model of the game and the improvement of our understanding of it as the development progresses.
• Mistakes Fixing — the time we need to fix the errors/bugs we made. The coefficient decreases with time because we make fewer mistakes as we learn.
• Learning — training costs for the team. Expecting the team to know everything you need immediately after hiring is unrealistic. Our team should invest time in learning new tools, approaches, theories, etc.
• Team Lubrication — a penalty on the team's time to get used to each other. People need to learn to work with each other.
• Vacations — you didn't forget about vacations and illnesses, did you? 0.08 in the table is approximately 1/12 of a year.
• Expected Work — the rounded-up estimate of the calendar time for the stage.

In the end, we have 4 development phases, each lasting six months — a perfect plan for how to kill to productively spend two years of your life.

By the way, this is not counting DLCs. The development of DLCs is not included in the Roadmap because:

• The complexity of their development depends heavily on the quality of the game's architecture. Now it is unpredictable, like guessing on a goat's liver.
• The same applies to their content: there is no game yet — we don't know what to add to it.
• Since we’re aiming for long-term monetization through DLCs, we'll need to establish a DLC production pipeline after the initial release (features of which can be varied quite flexibly). This pipeline will be constrained from the top by marketing demands and community expectations, and from the bottom by architectural and team limitations. We’ll need to plan the features of each DLC in a way that fits within tight development timelines. It will be totally different planning.

Composing the team

So, in the Blue table, we need to write down the number of employees for each track at each stage of development.

When determining the number of employees, we should remember the following:

• On each stage, on each track, it is reasonable to have so many employees that all tracks are completed at approximately the same time.
• It is not mandatory to hire all employees at once. Firstly, new projects always start from the narrow front of work, when the presence of additional employees will only delay progress. Secondly, the fewer people you hire, the less money you need to ask. Especially if you are going to raise funds in rounds.

I have no team yet, so I operated with "virtual employees" and just added my share of time to the estimates.

If you already have a team (or will have one), it’s wise to add a column in the Blue Table per each team member. This allows you to accurately track how much impact each person will have on each track. This approach also comes in handy if you hire a “star” who works like five people or an intern who may count as half of an employee.

By following these logic, we may create an image of our future team:

• Two developers and two game designers to fill the main tracks.
• One key specialist for tracks with too many tasks for outsourcing.
• Hiring is in two stages: first, for the project kickoff, and then, for the steady development phase.
• Tasks and employee specializations are adjusted according to the requirements of each development stage. For example, we don’t need utilities or QA automation in the Alpha version, but they become essential for smooth development and achieving the desired quality later on. Therefore, we will hire a second developer by the start of the Beta version.
• We’ll hire a producer by the Beta stage since I can handle managing five skilled people part-time, but I’ll need help beyond that (I want to continue writing code and working on game design). Also, I don’t have experience managing outsourcing, so it would be great to delegate that responsibility.

Positioning — beacon games

Before we start developing a financial model, it would be useful to gather some information about the fate of similar projects.

• First, if there are no similar projects, it is a reason to think is the concept of our game is so unique that no one has ever thought of it, or is it so bad that no one has ever tried to implement it.
• Second, such a list will provide us a feedback on the expected amount of work and the team size. We can compare our calculations with real data.
• Third, it will allow us to estimate (using heuristics) some parameters for the business model.

I chose beacons based on genre and the significant player experience they provide. It is possible to philosophize about alternative approaches. For example, someone could dig up some Steam statistics or collect raw data and make some data science magic.

What data do we need:

• Development time.
• Team size.
• The price of the game at the release time.
• The number of copies sold.
• The estimated revenue.

Most of this data is private, and almost no one will give it to you. Especially the exact values.

But we don’t really need exact data (as if all our previous calculations were spot-on, yeah?), approximate information should be enough. In my case, I unexpectedly found it easily on Wikipedia and news sources.

By the way, here is some advice. If you are going to make a game in the future, but not right now, start collecting links to interviews and press releases from developers. They will come in handy when you start planning.

In case Wikipedia is not enough, there are several Steam statistics aggregators, such as Steam Spy.

Marketing strategy

One more important thing to do before preparing the financial model is to outline marketing activities. In our time marketing takes half of the development budget, if not more.

I'll skip the part with general ideas on building a community, finding players, and similar things. Firstly, there are a couple of related slides in the presentation. Secondly, it is a well-known and popular topic, there are plenty of materials on the internet. I even wrote a small essay [ru] about my experience. Plus, in my opinion, all these considerations are more about marketing philosophy (who and where to look for) than about actual expenses (how many players to look for and how much to pay for them). Here we are interested in how much to pay.

In the context of marketing, two things are important to us.

Firstly, key events for which we will prepare marketing activities:

• Early Access release.
• Exit from Early Access.
• Releasees of DLCs.

Secondly, the types of this activity, for us it is:

• Releasing a supporting video.
• Attracting new players.
• Returning old players.

In the rest, our focus should be visible from the table:

• We shoot gameplay videos for Early Access and spend "a little" on attracting hardcore strategy players to forge a core of our community.
• On the exit from Early Access, we shoot a cool video with the idea of the game and spend a lot of money on attracting a wide audience.
• On the release of free DLCs / base game updates, we return old players and spend a little on attracting new ones, focusing on the features of the DLC. For example, if the DLC is inspired by X-Files, we may launch a company aimed at fans of the series.
• On the release of paid DLCs, we shoot a video about the idea of the DLC and aim spendings at our community and a little at new players.

Financial model

Finally, we can get to the most interesting part — counting money.

You can find the spreadsheet with the calculations here.

It contains two sheets:

• A detailed monthly calculation — for us and for the convenience of modeling.
• A brief excerpt from the first sheet — a slice of the most important parameters at key points in development — for investors and a beautiful presentation.

The second sheet is built automatically based on the first one.

The model is built till the release of the fourth paid DLC, but it is calculated for a slightly longer period — until the end of the fourth year of development.

I will explain the first sheet. It contains 65 rows. The calculation goes from top to bottom, left to right, so I will just describe all the rows in order.

I won’t write down the formulas—you can find them in the original table—but I will describe the calculation logic if it’s not straightforward.

I’ve split the description into sections based on the relevance of the data. In the table, these sections are highlighted by different background colors.

So, let's go.

Header

[1] Year — Color differentiation of the years of development for easy navigation.

[2] Month — The ordinal number of the month, also for navigation.

[3] Milestones — Important events in the life of the game. Each event usually changes the parameters of the financial model. For example, when starting the development of the Beta version, we increase the size of the team.

Base game sales

[4] Standard Edition Price $ — The price of the base game at the release. We choose it balancing our greed and the price of beacon games on their release.

[5] Deluxe Edition Price $ — The price of the deluxe version of the game. For players who want to spend a little more money on the game. We choose it a bit higher than the base game's price.

[6] Game Purchases / Month — The expected number of organic purchases per month. From the echoes of marketing, community building, and other activities.

[7] Game Purchases Boost— The number of game purchases we expect from our marketing efforts. This parameter is not calculated but set. The reasons for choosing this approach and its alternatives will be discussed later when we get to the marketing spending calculations.

While deciding on this number, consider:

• How much money you can get from the investors.
• How many players are in the chosen genre on the chosen platform. In my opinion, even 10% of the target audience is a booming success, aim at 1% or less.

Also note that your marketing will be tied to specific events. You will pour a lot of money into a particular month and then maintain some minimal activity to pick up the tail.

[8] Game Purchases Boost Tail — Players who will purchase the game as a tail/echo of your marketing activities. Calculated as 1/3 of the effectiveness of marketing in the previous month. I took 1/3 by eye from SteamSpy charts (how quickly the audience growth rate decreases).

[9] Game Purchases / Month — The total number of purchases of the base game per month.

[10] Total Game Owners — How many purchases will be made over time, including this month.

[11] Deluxe Edition Purchases % — The share of purchases of the deluxe version of the game. I estimated it as a modest 5%.

[12] Standard Edition Purchases — The number of purchases of the base game per month.

[13] Deluxe Edition Purchases — The number of purchases of the deluxe version of the game per month.

[14] Standard Edition Revenue — How much players will pay for the base version per month.

[15] Deluxe Edition Revenue — How much players will pay for the deluxe version per month.

[16] Game Revenue— How much players will pay for both versions per month.

[17] Total Game Revenue — How much players will pay for both versions over time, including this month.

DLC sales

All paid DLCs are described using the same logic, so I will only describe the rows of the first DLC.

[18] Paid DLC 1 Convertion Rate — Our estimate of the share of base game owners who will buy the DLC. I took the estimate by googling the news, but there is not much information. 30% conversion is an ambitious goal.

[19] Paid DLC 1 Purchases — The number of players who will buy the DLC per month. There is a slightly confusing formula, but its essence is to count old and new players coming each month and not count people twice.

[20] Paid DLC 1 Price — The price of the DLC. We balance between greed, industrial standards, and our idea of the volume of the DLC. To determine the acceptable price range, I just looked at the prices of Paradox DLCs. Plus, the first DLC is expected to be smaller because it will be the first, and it will take some time to solve inevitable technical problems. Therefore, the price should be lower.

[21] Paid DLC 1 Revenue — The expected revenue from the sale of the DLC per month.

[22] Total Paid DLC 1 Revenue — The expected revenue from the sale of the DLC over time, including this month.

Calculating the money we'll receive from Steam

Of course, not all money from the players will end on our bank account. In this section, we estimate how much money we'll actually see.

[38] Raw Gross Revenue — The total revenue from the sale of the base game and all DLCs per month.

[39] Expected Discounts Loss — The expected "losses" from discounts on Steam.

[40] Raw Gross Revenue - Discounts — Our revenue after accounting for discounts.

[41] Steam Fees — The standard 30% Steam fee.

[42] Revenue After Steam Fees — Our revenue after the Steam fee.

[43] Total Revenue After Steam Fees — Our ongoing revenue after all losses and fees, including this month.

Spends on development

The part of the model for which we spent so much time calculating the roadmap and team composition.

[44] Team Size — The number of people in the team.

[45] Average Gross Salary $ — The average salary of a team member.

[46] Sallary Indexation — Salary indexation. I think almost no one includes this but in vain. In my opinion, this should be an obligatory element of the agreement today. So to say, an aspect of work ethics.

[47] Final Sallary — The final average salary with indexation.

[48] Team Cost — The total cost of the team per month.

[49] Average Outsource Staff — The number of outsourcers we will work with. My "expert" estimate: something will always be outsourced, but it is unclear to what extent, most likely in a small one, so 1.

[50] Average Outsource Cost — The expected cost of one outsourcer per month. The logic is the same as with the average team salary.

[51] Outsourcing Cost — The total cost of outsourcing per month.

[52] Development Cost— The total cost of all development per month.

[53] Total Development Cost — The overall cost of all development since the beginning of time, including this month.

Calculating marketing

Let’s take a break from the table and think about how we’re going to calculate the marketing budget.

In our model, we will choose a simpler and more reliable approach — we will estimate the cost of attracting a single player to purchase the game, CPI — Cost Per Install. Don't confuse it with Cost Per Impression, in this post we will only talk about installs.

CPI for Steam is as vague as conversions to wishlists and from them, but:

• It is a single parameter, not two. There is less effect of error accumulation and no temptation to adjust the parameters to each other.
• CPI is easier to estimate. It is enough to know the marketing budget and the total number of game sales. We got this information when we were looking for beacon games.
• CPI is a global inertial phenomenon, it is less inclined to change unexpectedly, usually it only increases follows long global trends.
• An estimate of CPI may be more accurate than conversions to/from wishlists, because it is directly and rigidly limited by the market: budgets, people's willingness to engage in advertising, etc. Companies that do bad marketing leave the market. If we use data from successful products, we should get a relatively realistic estimation of CPI.

CPI for the base game we will estimate simply:

• The marketing budget for beacon games is taken as half of their revenue.
• By dividing the marketing budget by the estimated number of purchases, we get CPI.

Out CPI (for the base game) is set approximately as an average between beacon games. Additionally, I want to note that we have set lower sales than beacon games have, so our CPI may be slightly lower. CPI grows as the target audience is covered, as it becomes more difficult to find new players.

Marketing costs

So, let's return to the biggest are of our spendings. According to the final calculations of our model, by the release, we will spend 2.5 times more on marketing than on development :-D

[54] Marketing Ongoing Cost — An estimated cost of minimal permanent monthly activity for "light" PR of the game to stay on the radars.

[55] Marketing Videos Cost — The expected cost of developing videos for concrete events (releases). The cost of a video minute can be relatively easily Googled. Or you can even ask for price lists from companies that do this.

[56] Marketing New User Cost — The expected cost of attracting new players — CPI.

[57] Marketing Old User Cost — The expected cost of attracting our players to purchase DLCs.

[58] Marketing Performance on New Users (Game) — The cost of attracting new players to the game, per month.

[59] Marketing Performance on Old Users (DLC)— The cost of attracting our players to purchase DLCs, per month.

[60] Marketing Month Cost — The total cost of marketing per month.

[61] Total Marketing Cost — The overall cost of marketing since the beginning of time, including this month.

Expected profits

The most important part of our table — the result of all our work, research, and calculations.

[62] Month Costs — All costs per month.

[63] Total Costs — The overall costs since the beginning of time, including this month.

[64] Month Gross Revenue — Our revenue per month, after all incomes and costs.

[65] EBITDA— EBITDA as it is — our money before removing indirect costs (taxes, amortization, interest, etc.). This parameter is essential for investors.

What to do after the financial model is finished

After you enter the last formula, stretch the columns for the required number of months, color everything, you will look at the final numbers and see that there is some unprofitable crap. Or, conversely, very suspiciously profitable.

It means the beginning of the most exciting stage of setting up the model when you twist a bunch of levers (constants in the table), play with the volume of work, and tune the size of the team to get a picture that will be convincing for you, your team, and investors.

Have Fun!

How much time did it take to develop the business plan

Instead of a conclusion, I will provide statistics on the time these documents took from me.

Of course, this is an approximate time, because I did not do this work full-time.

• Short strategy of the company — You develop strategy not at some specific moment, but all the time while working on ideas, concepts, presentations and so on. Later you just write down the information that already sits in your head.
• Table of beacon games — ±2 days. I spent a lot of time trying to understand what to search and how to search. When I figured it out, it went quickly.
• Team composition — less than a day. The basic composition should be well visible from the roadmap.
• Roadmap — ±2 days.
• Outlines of marketing strategy — Here are the same considerations as with the company strategy.
• Financial model — ±3 days, the idea of calculations changed several times. If you take a ready-made model, it will be much faster.

That’s all for now. Thank you for your time, and best of luck in game development!