Считаем бизнес-план для игры в Steam ru en

Когда выкладывал отчётную презентацию (слайды) по World Builders 2023 (мои посты, сайт), обещал рассказать как делал roadmap и финансовую модель для игры. Выполняю обещание.

К концу поста у нас на руках будут:

• Краткая стратегия нашей компании: что мы делаем, как, зачем и почему.
• Табличка наших маяков — успешных игр, которые примерно похожи на то, что мы хотим сделать. Похожи как по геймплею, так и по размеру команды, бюджету, etc.
• Состав команды, которую нам надо собрать.
• Roadmap — план разработки нашей игры.
• Зачатки маркетинговой стратегии.
• Финансовая модель — сколько мы будем тратить, сколько зарабатывать.
• Огромное количество моих оговорок по всему посту.
• Шутки и прибаутки.

Все итоговые документы вы можете найти тут.

Снятие ответственности

Если вдруг вы просрёте понесёте убытки на десятки миллионов долларов, последовав советам в этом посте, и к вам придут угрюмые дядьки с вопросами, не перенаправляйте, пожалуйста, их ко мне. Несите свою ответственность с гордо поднятой головой, даже если ваши ноги уже заливают бетоном. Шучу, не имейте дела с непрофильными инвесторами и ваше здоровье будет в порядке.

Вот почему стоит критически смотреть на этот урок:

• Я не профессиональный бизнесмен. У меня был бизнес и я потратил на него больше, чем заработал.
• Это лучший из двух бизнес-планов, что я готовил. То что он лучший, не отменяет того, что он второй.
• Мне (пока) не дали под него денег и даже не я занимаюсь поиском инвесторов. Поэтому не знаю как инвесторы отреагируют на эти выкладки.
• Этот бизнес-план готовился в рамках учёбы, а не в рамках «я поставил душу на открытие своей конторы и вкладываю в неё всё время и ресурсы».
• Можно было сделать в 100500 раз лучше, но я не сделал. Па-ра-па-пам. потому что не было времени, а иногда даже было лень.

Циклическая разработка

По ходу чтения может казаться, что всю работу можно сделать последовательно от начала до конца. Это не так. Я постфактум организовал всё в форму рассказа, чтобы не заставлять вас хаотически прыгать по документам..

Итак.

Стратегия компании

Представим, вы решили делать игру для кладбища инди разработчиков Steam. Причём singleplayer стратегию-песочницу (смотрите презентацию, если интересно). Может с мультиплеером, но пока вы не уверены.

Разбор возможных причин этих решений выходит за рамки эссе.

Например, если у вас во главе угла стоит заработок (зачем тогда идти в геймдев?), то по-хорошему надо поднять отчёты по разным платформам, посмотреть какие жанры на какой платформе сколько зарабатывают, оценить средний размер команд, инвестиций, времени разработки. После чего принять взвешенное решение и идти делать free-to-play мобильную MMORPG для low-grade мобилок на африканском рынке. На всякий случай, про Африку я серьёзно.

Выбираем монетизацию основной финансовый поток

В Steam есть несколько подходов к монетизации игр:

1. Через крупные релизы.
2. Через продажу DLC — Downloadable Content.
3. Через микротранзакции

В моей картине мира компания будет целиться на что-то одно, а остальное использовать как дополнительный источник дохода. Если ловить двух зайцев, то обычно ни одного не поймаешь.

Микротранзакции рассматривать не буду, так как в них в области singleplayer PC игр пока умеют могут только ААА студии и только через гигантские маркетинговые бюджеты и потерю репутации. Инди разработчиков за такое сообщество Steam живьём закопает. И правильно сделает. Не говоря уже о том, что карму себе портить не хочется.

Соответственно, у нас есть несколько вариантов базовой стратегии:

1. Большой релиз «My Mega Game». Уходим заниматься чем-нибудь другим.
2. Большой релиз «My Mega Game». Уходим заниматься чем-нибудь по-мотивам: сделали стратегию про фэнтези, теперь делаем про космос.
3. Большой релиз «My Mega Game». Большой релиз «My Mega Game 2». Большой релиз «My Mega Game 3». И так далее.
4. Большой релиз «My Mega Game». Выпускаем пару DLC. Параллельно пилим что-нибудь по плану 2 или 3.
5. Большой релиз «My Mega Game». Вечно выпускаем DLC.

Раньше было такое понятие как Addon, но для простоты будем считать их теми же DLC. По крайней мере я не вижу существенных отличий для целей этого поста.

Вариант 1, по-моему, сейчас почти никто не практикует, в случае успешного продукта, конечно. Так как много ресурсов тратится впустую: теряется наработанная экспертиза команды, код, пул внештатных специалистов, сообщество — не очень выгодно. Но какие-нибудь очень упорные инди могут заниматься этим по фану.

Варианты 2 и 3 близки, их даже можно чередовать. Они позволяют переиспользовать значительно больше наработок, чем вариант 1. Минусом является очень неравномерное поступление денег, к тому же не гарантированое. А значит дыры в бюджете.

Серия больших релизов — рискованное мероприятие, поэтому в случае успеха первого релиза многие разработчики стараются выпустить хотя бы несколько DLC, чтобы поддерживать разработку следующих игр. Что приводит нас к четвёртому варианту.

Вариант 4 — выпуск DLC параллельно с разработкой следующей игры — хороший способ снизить риски и сделать жизнь студии более предсказуемой.

Проблема с этим подходом в том, что не все команды могут сделать игру, которую будет относительно легко модифицировать интересным для игроков способом. Плюс, не все жанры хорошо подходят для DLC.

Например, RPG делают добавление каждого следующего DLC сложнее, так игра идёт с цельной историей, а значит и механики менять сложно (из-за баланса кампании) и новые истории приплетать сложно (мы же релизимся с цельным сюжетом).

Но если у нас нет таких проблем, то мы можем смотреть на вариант 5 — перенос основного потока денег с релизов новых игр на релизы DLC. Я называю его Paradox way, потому что они умеют в него лучше всех.

Первый релиз всё ещё приносит существенную долю дохода, но фокус разработки изначально строится на поточном производстве DLC, которые со временем перевешивают по профиту.

Конвейер DLC

Грамотное поточное производство DLC круто по двум причинам.

Во-первых, оно формирует крепкую развивающуюся экосистему, включающую компанию и сообщество игроков:

1. С каждым выпущенным DLC вы дорабатываете и базовую игру, тюните её под конкретную нишу и, со временем, становитесь монополистом в ней.
2. Доработанную игру продолжают покупать игроки, для которых раньше она была не так хороша. Поэтому ваше сообщество продолжает расти долгое время после релиза.
3. Крепкое сообщество даёт быструю и качественную обратную связь для ваших решений, что ведёт к выпуску более качественных DLC. Хорошие DLC улучшают игру. Улучшенная игра привлекает людей в сообщество. Сообщество даёт ещё лучшую обратную связь.

Во-вторых, вы получаете предсказуемый поток денег:

1. Период между крупными поступлениями снижается с 1-2 лет до 3-6 месяцев.
2. Снижаются риски, связанные с ошибками. В случае провального релиза студии часто закрываются. В случае провального DLC вы выпускаете следующее. Студия живёт до тех пор, пока в состоянии учиться на своих ошибках.
3. Вы продаёте DLC не случайным людям, а своим игрокам. Это делает маркетинг дешевле, а доход предсказуемее. Вы знаете сколько людей играет в вашу игру, какой их процент покупал предыдущие DLC, а значит можете прикинуть сколько денег принесёт следующее.

Правда есть и минусы:

• Работает не со всеми жанрами. По-моему, только со стратегиями и, может быть, песочницами.
• Первый релиз всё-таки должен быть достаточно заметным и качественным, чтобы сформировать ядро вашего сообщества. У Paradox получается выпускать посредственные продукты (судя по отзывам), а потом их допиливать. Но это скорее исключение, им прощают.
• Надо уметь делать игры и слушать игроков. Не все это умеют и не все хотят.

Поскольку мы делаем и стратегию и песочницу, да ещё и в свободном жанре (симуляция общественного мнения), то можем рискнуть и нацелиться на пятый вариант. В случае проблем с организацией производства DLC, всегда можно откатиться на вариант 4.

Early Access

Опытный разработчик мог заметить, что я обошёл стороной Early Access.

Сделал я это по нескольким причинам:

• Сейчас это де-факто стандарт. Пропускать Early Access смысла нет никакого. Раньше делаете Early Access, раньше получаете обратную связь от вселенной, раньше исправляете ошибки.
• Что конкретно релизить в Early Access, на мой взгляд, определяется не столько монетизацией, сколько маркетингом, возможностями команды и желаниями инвесторов.

Есть два полюса:

1. Полный релиз в Early Access. Выпускаем то, что выпустили бы в обычный релиз, только теперь нам прощают больше багов, а команда спокойнее пилит патчи первого дня, недели, месяца, года. Когда всё продано, делаем release, чтобы засветиться перед игроками, которые почему-то пропустил Early Access.
2. Условно «тихий» выход в Early Access. В Early Access выпускаем цельную игру, но очень сильно урезанную по фичам. Ориентируясь на обратную связь долго и упорно допиливаем и полируем. Делаем громкий выход из Early Access.

На мой взгляд, второй подход безальтернативно эффективнее, так как даёт обратную связь значительно раньше, что неизбежно увеличивает качество разработки на её последнем этапа. Если команда готова обратную связь слышать.

Но не все могут себе позволить такую роскошь:

• Есть риск ошибиться с тем, что такое «минимальная целостная игра». Если выпустите не то, быстро уйдёте по рейтингу в чистилище. Если у вас финансирование по раундам, то денег на релиз после этого вам не дадут.
• Ваша игра может быть изначально задизайнена минимально целостной, например, из-за ограничений бюджета. То есть вам будет нечего из неё убрать.
• Маркетологи или инвесторы сдвинут рассписание разработки так, что вы просто не сможете выйти с нужным набором фич: «полный релиз под Рождество или смерть».

Итоговая стратегия

1. Мы делаем стратегию-песочницу под Steam.
2. Мы ориентируемся на длительный выпуск большого количества DLC.
3. Мы ориентируеся на «тихий» выход в Early Access, культивацию сообщества, активную эксплуатацию обратной связи от него и громкий релиз.
4. Если выпуск DLC окажется недостаточно финансово эффективным, мы переключаемся на разработку нового продукта, с использованием существующих наработок, подерживая его выпуском нескольких DLC к первой игре.

На основе планов выхода в Early Access и понимания геймдева мы можем описать крупные этапы разработки нашей игры.

Roadmap

Теперь нам надо оценить объём работы. Для этого мы должны развернуть этапы разработки в конкретные крупные задачи и оценить время, необходимое на их выполнение.

Итоговый Roadmap вы можете найти по ссылке.

Roadmap состоит из трёх таблиц. Для удобства я выделил цветом их заголовки:

• Красная таблица — все крупные задачи, которые мы должны сделать.
• Синяя таблица — объём задач по трекам и этапам.
• Зелёная таблица — итоговая оценка времени на каждый этап.

Красную таблицу мы заполняем.

Синяя и зелёная таблицы рассчитываются полуавтоматически: часть значений мы задаём, часть берём из других таблиц. Синяя считается по Красной, Зелёная — по Синей.

Красная таблица

Пример из начала таблицы, если вам лень открывать оригинал:

Колонки:

• Stage — этап разработки, на котором мы должны выполнить задачу.
• Epic — крупный кусок работы, который мы делаем всей командой.
• Feature — кусок эпика, который делают конкретные специалисты, например, разработчики или дизайнеры.
• Track — какие специалисты делают эту задачу: разработчики, дизайнеры, маркетологи, etc. Почему колонка называется Track объясню ниже.
• Estimation — наша оценка времени на выполнение задачи.
• Comments — любые дополнительные комментарии.

Что такое трек

В проекте всегда можно выделить несколько потоков задач, которые хорошо бы (но не всегда возможно) выполнять всегда, например, каждую неделю брать по одной задаче. Иначе какая-то часть проекта будет деградировать.

Самое простое из геймдева, это треки разработки, игрового дизайна, художественного оформления.

Поэтому, при идеальном ведении проекта с неограниченным бюджетом, по каждому треку всегда что-то делается, чтобы проект рос равномерно.

Обращу внимание, что не надо путать треки с ролями, должностями, компетенциями. Выше был приведён пример высокоуровневых треков. Вот для примера более специализированные треки для веб разработки:

• разработка бизнес-фич;
• улучшение контролируемости проекта: метрики, логи, тесты;
• контроль безопасности проекта;
• улучшение производительности.

Бизнес всегда обычно грешит тем, что игнорит задачи с не-самых-обязательных-и-заметных треков, которые не-приносят-value-напрямую. Например, не одобряет задачи по улучшению контролируемости проекта, потому что «сейчас и так всё ок».

Но фишка в том, что долг по треку растёт как снежный ком, снежинка за снежнкой, если не платить его, то в какой-то момент приходит беда, все фичи откладываются в пользу срочных исправлений через костыли, что приводит к существенному нарушению планирования того же бизнеса и, до кучи, к глубинной деградации проекта, которая через время ещё сильнее рушит планирование и так по кругу.

Поэтому задача лидера проекта в том, чтобы поддерживать активными все треки.

Соответственно, начиная делать таблицу, я решил расписывать задачи именно по трекам, предполагая что:

• перечень треков определится по ходу заполнения;
• на каждом этапе на каждом треке будет какой-то объём работы.

По факту, можно заметить, что именно в нашем конкретном случае можно было писать должности. Но, если бы проект был больше, то треки были бы не такими общими. Например, геймдизайн мог разделиться на треки левел-дизайна, механик и нарратива.

Также нет гарантии, что по мере разработки продукта и становления команды, мы не захотим увеличить детализацию наших планов.

Как выделять задачи

Самое главное — чувствовать меру. При всём желании мы не можем знать весь перечень элементов интерфейса, звуков, механик и чего угодно в финальной игре. Поэтому нет никакого смысла его составлять.

Вместо этого надо набрасывать работу крупными кусками, ориентируясь на здравый смысл и собственный опыт.

Если у вас нет опыта, используйте только здравый смысл :-) Потом найдите опытного товарища и попросите его проверить вашу работу. Делать наоборот (искать человека сделать эту работу сразу за вас) не могу рекомендовать, так как человек уйдёт, а вы останетесь с артефактом, который не понимаете.

Делегировать накидывание задач человеку из команды (который подписался, что будет с вами и дальше), конечно, можно. Ещё круче, делать это всей командой. У меня команды нет, поэтому делал сам.

В нашей стратегии, для каждого этапа разработки мы кратко сформулировали, что должно получиться в итоге.

Например, в нашем случае для Alpha версии:

• Цель: Implement core game mechanics.
• Описание результата: The PC game where you can play 1 game session and have some fun.

Зная, что за игру мы делаем, мы можем определить что в ней должно быть для завершения этого этапа:

• Минимальное описание геймдизайна.
• Минимальный интерфейс пользователя.
• Зачатки базовых механик. В нашем случае карта, каналы распространения новостей, расследование событий.
• Какой-то контент.

Эти задачи мы должны сделать всей командой, но каждая из них содержит разный объём работы для разных специалистов. Поэтому разложим их на треки.

Например, вот мы знаем что нам нужна карта в игре.

• Какая это будет карта? А кто же его знает. Поэтому мы выделяем подзадачи на исследование сразу по двум трекам:
  • как карта должна работать в геймдизайне;
  • как карта должна выглядеть.
• Конечно, нам надо реализовать карту в коде. Поэтому у нас появляется третий трек — разработка.
• Было бы круто иметь процедурную генерацию карты. Но в Alpha версии она определённо не нужна, так как не соответствует цели разработки. Поэтому эту идею мы выносим в отдельные куски работы и помещаем на этапы разработки Beta и Early Access версий.

Кроме прямых задач на разработку, есть задачи невидимые со стороны, но тоже обязательные. Нельзя о них забывать. Вот примеры из моего roadmap:

• Перенос логики игры из прототипа в реальный проект. Необходим, так как прототип разрабатывался на технологиях, удобных для прототипирования (web), а не для игры в Steam.
• Разработка инструментария, который должен помогать геймдизайнерам работать быстрее.
• Плейтесты в конце каждого этапа и доработка игры по их результатам.
• Разработка QA подходов для оценки качества контента. В моей игре будет процедурная генерация историй, поэтому необходима возможность оценить нижнюю границу их качества. Достаточно ли они разнообразны, затрагивают ли всех NPC, и так далее. Другими словами, нужно защитить себя от случайного тотального фиаско, когда из-за ошибки в алгоритме генерации он начнёт выдавать полную ерунду. Разработчикам сложно такое замечать, потому что они не могут гонять полные игровые сессии целыми днями (им работать надо), из-за чего им сложно видеть статистические явления.
• Проработка мира, в котором происходит игра. Без цельного контекста, геймдизайнерам и художникам будет сложно согласовывать свою работу друг с другом.
• Проверка и настройка разнообразия в игре. Мы делаем игру про современный мегаполис, поэтому у нас должны быть представлены люди разных рас, взглядов, возможностей.
• Туториал.
• Создание Newspedia (по аналогии с Civilopedia в серии Civilization). В игре будет много нюансов, нужно помочь игрокам ориентироваться в них.
• Задачи на формирование сообщества и работу с ним.
• Инфраструктура для отслеживания ошибок и метрик игры.
• Что-нибудь прикольное для Deluxe версии, которую мы будем продавать чуть дороже.
• Поддержка модов.
• Адаптация для людей с ограниченными возможностями.
• Вики для сообщества.

Оценка задач

Оценка задач — вопрос сложный и запутанный. Конкретный подход зависит от вашего опыта.

Можно выделить два подхода:

• Оценка в story points — абстрактных единицах сложности. Например, вы говорите, что самая простая задача стоит одно очко, после чего все остальные задачи оцениваете пропорционально ей. Когда всё оценено, переводите очки во время по какому-то курсу.
• Оценка сразу в реальном времени.

Для себя работу я обычно оцениваю в «идеальный рабочих днях» (когда никто и ничто не отвлекает). Этот же подход выбрал для roadmap. Но для совместной оценки лучше использовать story points.

Синяя таблица

После того как мы расписали всю работу, мы можем узнать сколько времени займёт каждый трек на каждом этапе разработки. Это позволит нам подобрать количество сотрудников на треки так, чтобы равномерно двигаться по ним.

Для этого мы группируем Красную таблицу по тройке значений этап + эпик + трек и суммируем рабочее время в них.

Колонки:

• Stage — этап разработки.
• Track — трек.
• Sum — общий объём работы по треку в днях.
• Workers — количество сотрудников, которые будут на треке на этом этапе. Дробная часть — это доля моего времени, которое я смогу выделять на помощь. Как подбирать количество сотрудников на треки расскажу ниже.
• Workdays — количество рабочих дней на человека.
• Work Months — количество рабочих месяцев, которое займёт трек.

Всё время я перевожу в рабочие месяцы, так как расчёты очень приближённые и далее никому «точное» количество дней будет не интересно.

Зелёная таблица

Синяя таблица даёт нижнюю (оптимистичную) оценку длительности каждого этапа для нашей команды (про которую поговорим чуть позже).

Задача зелёной таблицы — перевести оптимистичную оценку рабочего времени в реалистичну оценку календарного времени.

Для этого мы:

• Время каждого этапа приравниваем к длительности максимального трека.
• Увеличиваем его на разные умные коэффициенты.
• Округляем вверх, так как в разработке софта нет предела пессимизму.

Колонки:

• Stage — этап разработки.
• Max — длительность этапа, равна длительности максимального трека.
• Forgotten Work — наша оценка доли работы, которую мы забыли для этапа. Коэффициент возрастает, так как первые этапы мы видим лучше, чем последние. Работа на последних будет сильно отличаться от плана из-за накопления ошибки в нашей модели игры и улучшения нашего понимания её же по мере разработки.
• Mistakes Fixing — ожидаемое дополнительное время на исправление ошибок. С учётом вашей компетенции и ожидаемой компетенции команды.
• Learning — затраты на обучение команды. Не бывает такого, что команда сразу умеет всё, что вам надо. Обязательно нужно будет учить новые инструменты, подходы, теории, etc.
• Team Lubrication — штраф на время срабатывания команды. Людям нужно время, чтобы научиться работать друг с другом.
• Vacations — вы же не забыли про отпуска и болезни? Правда-правда? 0.08 в таблице — это примерно 1/12 года.
• Expected Work — округлённая вверх оценка времени на этап.

Итого, у нас получается 4 этапа разработки, каждый по полгода — отличный план как убить потратить с пользой два года своей жизни.

Кстати, это не считая DLC. Разработка DLC не включена в Roadmap, потому что:

• Сложность их разработки сильно зависит от качества архитектуры игры. Сейчас это непредсказуемо, всё равно, что гадать на печени козла.
• То же самое относится к их содержанию: нет игры — мы не знаем чем её дополнять.
• Поскольку мы ориентируемся на длительную монетизацию через DLC, после релиза (итоговые фичи которого можно варьировать довольно гибко) нам надо будет построить конвеер производства DLC, который будет ограничен сверху требованиями маркетинга и свойствами нашего сообщества, а снизу — ограничениями архитектуры и команды. Нам потребуется так планировать фичи каждого DLC, чтобы его разработка влезала в ограниченные временные рамки. Это будет совсем другое планирование.

Планирование команды

Итак, в Синей таблице нам надо прописать количество сотрудников на трек на этап разработки.

Подбирая количество сотрудников мы ориентируемся на следующие соображения:

• На каждом этапе на каждом треке разумно иметь столько сотрудников, чтобы треки занимали примерно одинаковое время.
• Не обязательно сразу нанимать всех. Во-первых, разработка нового проекта всегда стартует с малого фронта работ, когда лишние люди мешают, и только со временем этот фронт расширяется. Во-вторых, это снижает ваши запросы на первые инвестиции. Особенно, если инвестиции предполагаются раундами.

У меня под рукой команды нет, поэтому я оперировал «чистыми» сотрудниками и просто приплюсовал долю своего времени в нужные графы.

Если же у вас есть команда (или будет), в Синюю таблицу разумно добавлять по колонке на сотрудника. Там можно будет точно отражать сколько времени он сможет тратить на какой трек. Это же пригодится и в случае найма «звезды», которая будет работать за пятерых, и стажёра, который сойдёт за половину сотрудника.

Следуя этим соображениям, мы получаем такую команду:

• По два программиста и геймдизайнера, чтобы закрывать основные треки.
• По одному ключевому специалисту, для задач, которых слишком много для аутсорса.
• Найм в два этапа: под старт проекта и под выход на ровную разработку.
• Задачи и специализации сотрудников скорректированы под требования этапов разработки. Например, для Alpha версии нам не нужны вспомогательные утилиты и автоматизация QA, но для ровного хода разработки и нужного качества они обязательны. Поэтому второго разработчика нанимаем к началу разработки Beta версии.
• Продюсера нанимаем к Beta версии, так как с синхронизацией пяти толковых ребят я смогу справиться на полставки, а дальше потребуется помощь. Плюс, у меня нет опыта взаимодействия с аутсорсом, было бы круто это делегировать.

Позиционирование — игры-маяки

Прежде чем приступить к разработке финансовой модели, нам будет полезно собрать немного инфы про судьбу похожих проектов.

• Во-первых, если нет похожих на ваш продуктов, то это повод крепко задуматься а то ли вы делаете.
• Во-вторых, это даст вам обратную связь по ожидаемым объёму работ и команде. Вы сможете сравнить свои подсчёты с реальными данными.
• В-третьих, это позволит вам прикинуть (с помощью эвристик) некоторые параметры для бизнес модели.

Я выбирал маяки по жанру и значимому опыту, который получают игроки. Тут можно пофилософствовать и найти кучу альтернатив. Например, раскопать какую-нибудь статистику Steam или подключить ИИ, кластеризацию и прочий data-science.

Какие данные нам интересны:

• Время разработки.
• Размер команды.
• Цена в момент релиза.
• Проданные копии.
• Примерная выручка (revenue).

Большинство из этого приватные данные и никто так просто их вам не даст. Особенно точные значения.

Но точные данные нам и не нужны (типо все предыдущие наши расчёты были точны, ага), а примерная информация, в моём случае, неожиданно легко нашлась в Википедии и новостных ресурсах.

Кстати совет. Если вы собираетесь когда-нибудь в будущем делать игру, но вот не прямо сейчас, начинайте собирать ссылки на интервью и прессрелизы разработчиков. Потом как найдёте.

Для случаев, когда Википедии недостаточно, у нас есть несколько агрегаторов статистики Steam. Например, Steam Spy.

Маркетинговая стратегия

Ещё одно важное дело перед расчётом финансовой модели — накидать маркетинговые активности, так как на маркетинг сейчас уходит половина бюджета разработки, а то и больше.

Я опущу общие размышления по формированию сообщества, поиску игроков и тому подобное. Во-первых, про это есть пара слайдов в презентации. Во-вторых, это известная и популярная тема, в интернете полно материалов. Даже у меня небольшое эссе есть. Плюс, на мой взгляд, все эти соображения скорее определяют философию маркетинга (кого и где искать), чем реальные траты (сколько искать и сколько платить). Нам же интересно сколько платить.

В рамках маркетинга нам важны две вещи.

Во-первых, ключевые события к которым надо готовить маркетинговую активность:

• Выход в Early Access.
• Релиз.
• Выход DLC.

Во-вторых, виды этой активности, у нас это:

• Выпуск сопровождающего видео.
• Привлечение новых игроков.
• Привлечение старых игроков.

В остальном фокус должен быть виден из таблички:

• Для Early Access снимаем геймплей видео и «немного» тратимся на привлечение хардкорных игроков в стратегии, чтобы культивировать из них ядро сообщества.
• На Release снимаем крутое видео с идеей игры и вливаем деньги в широкую аудиторию, чтобы набрать игроков.
• На выпуске бесплатного DLC возвращаем старых игроков и немного привлекаем новых, целясь на особенности конкретного DLC. Например, если DLC будет вдохновлено X-Files, мы можем запустить компанию нацеленную на фанатов сериала.
• На выпуске платного DLC делаем видео про идею DLC, целимся в старых игроков и немного в новых.

Финансовая модель

Наконец мы можем заняться самым интересным — подсчётом денег.

Эксельку с расчётами можно найти по ссылке.

В ней два листа:

• Детальный помесячный расчёт — для нас и для удобства расчёта.
• Краткая выдержка из первого листа — срез самых важных параметров в моменты ключевых событий разработки — для инвесторов и для красивой презентации.

Второй лист строится автоматически на основе данных с первого листа.

План построен до выпуска четвёртого платного DLC включительно, но расчитан на чуть больший срок — до конца 4-ого года разработки.

Разбирать буду первый лист, в нём 65 строк. Расчёт идёт сверху вниз слева направо, поэтому буду просто описывать все строчки по порядку.

Формулы прописывать не буду, их можно посмотреть в оригинальной таблице, но буду описывать идею расчёта, если она неочевидна.

Описание разобью на разделы по близости данных. В таблице они отличаются цветом фона.

Итак, поехали.

Шапка

[1] Year — Цветовая дифференциация лет разработки для удобства навигации.

[2] Month— Порядковый номер месяца, тоже для удобства навигации.

[3] Milestones — Важные события в жизни игры. Каждое событие обычно меняет параметры финансовой модели. Например, при начале разработки Beta версии мы увеличиваем размер команды.

Продажи основной игры

[4] Standard Edition Price $ — Цена базовой версии игры. Её выбираем балансируя между нашей жадностью и ценой продажи игр-маяков на их релизе.

[5] Deluxe Edition Price $ — Цена люксовой версии игры, для игроков, которые хотят занести немного больше денег разработчикам. Выбираем чуть дороже цены базовой версии.

[6] Game Purchases / Month — Ожидаемое количество органических покупок в месяц. С отголосков маркетинга, работы с сообществом и прочих активностей.

[7] Game Purchases Boost— Количество покупок игры, которые мы ожидаем от наших маркетинговых усилий. Этот параметр мы не рассчитываем, а задаём. Причины выбора такого подхода и его альтернативы будут разобраны чуть позже, когда дойдём до расчётов трат на маркетинг.

Выбирая, учитывайте:

• Сколько денег вам могут дать.
• Сколько игроков в выбранном вами жанре на выбранной платформе. Имхо, даже 10% от ЦА — это успешный успех, ориентируйтесь на 1%.

Также обратите внимание, что ваш маркетинг будет приурочен к конкретным событиям. То есть вы будете вливать очень много денег в конкретный месяц, а потом поддерживать какую-то минимальную активность, чтобы подобрать хвост.

[8] Game Purchases Boost Tail — Игроки, которые привлекаются как хвост/эхо ваших маркетинговых активностей. Рассчитываю как 1/3 от эффективности маркетинга в предыдущий месяц. 1/3 взял на глаз из графиков SteamSpy (как быстро уменьшается скорость прироста аудитории).

[9] Game Purchases / Month — Общее число покупок основной игры в месяц.

[10] Total Game Owners — Сколько покупок будет совершено за всё время, включая этот месяц.

[11] Deluxe Edition Purchases % — Доля покупок люксовой версии игры. Взял скромные 5%.

[12] Standard Edition Purchases — Количество покупок базовой версии игры в месяц.

[13] Deluxe Edition Purchases — Количество покупок люксовой версии игры в месяц.

[14] Standard Edition Revenue — Сколько заплатят игроки за базовую версию в месяц.

[15] Deluxe Edition Revenue — Сколько заплатят игроки за люксовую версию в месяц.

[16] Game Revenue— Сколько заплатят за обе версии в месяц.

[17] Total Game Revenue — Сколько заплатят за обе версии за всё время, включая этот месяц.

Продажи DLC

Все платные DLC описаны в рамках одной логики, поэтому разберу только строки первого DLC.

[18] Paid DLC 1 Convertion Rate — Наша оценка доли владельцев базовой версии игры, которые купят DLC. Оценку брал погуглив новости, но информации не то, чтобы много. 30% конверсии — это амбиционзная цель.

[19] Paid DLC 1 Purchases — Количество игроков, которые купят DLC. Там немного запутанная формула, но её суть в том, чтобы считать и старых и новых игроков, приходящих каждый месяц, и при этом не считать людей дважды.

[20] Paid DLC 1 Price — Цена за DLC. Балансируем между жадностью, индустриальными стандартами и вашим представлениям об объёме DLC. Для определения допустимого интервала цен я просто глянул цены DLC от Paradox. Плюс, первое DLC будет «на пробу» и какое-то время уйдёт на решение неизбежных технических проблем, поэтому DLC может быть меньше и цену ставлю меньше.

[21] Paid DLC 1 Revenue — Ожидаемый доход от продажи DLC в месяц.

[22] Total Paid DLC 1 Revenue — Ожидаемый доход от продажи DLC за всё время, включая этот месяц.

Расчёт денег, которые мы получим от Steam

Конечно, все деньги, которые мы насчитали мы и близко не увидим. В этой части мы считаем что может придти к нам на счёт.

[38] Raw Gross Revenue — Суммарный доход от продаж игры и всех дополнений за месяц.

[39] Expected Discounts Loss — Ожидаемые «потери» от скидок в Стиме.

[40] Raw Gross Revenue - Discounts — Наш доход после учёта скидок.

[41] Steam Fees — Комиссия Steam. Стандартные 30%. Говорят можно договориться, но noname студии это не грозит.

[42] Revenue After Steam Fees — Наш доход после комиссии Steam.

[43] Total Revenue After Steam Fees — Наш суммарный доход после всех потерь, включая текущий месяц.

Траты на разработку

Та часть модели, для которой мы так долго считали roadmap и состав команды.

[44] Team Size — Размер команды на месяц расчёта.

[45] Average Gross Sallary $ — Средняя зарплата члена команды.

[46] Sallary Indexation — Индексация зарплат. Думаю, это почти никто не закладывает, а зря. На мой взгляд это обязательный элемент соглашения в наши дни. Так сказать, элемент рабочей этики.

[47] Final Sallary — Итоговая средняя зарплата с учётом индексации.

[48] Team Cost — Суммарные затраты на команду в месяц.

[49] Average Outsorce Staff — Количество аутсорсеров, с которыми будем работать. Моя «экспертная» оценка: что-то постоянно будет аутсорсится, но не ясно в каком объёме, скорее всего в небольшом, поэтому 1.

[50] Average Outsource Cost — Ожидаемая стоимость одного аутсорсера в месяц, логика такая же, как и со средней зарплатой команды.

[51] Outsoursing Cost — Суммарная стоимость аутсорса в месяц.

[52] Development Cost— Суммарная стоимость всей разработки в месяц.

[53] Total Development Cost — Общая стоимость всей разработки с начала времён, включая текущий месяц.

Расчёт маркетинга

Давайте немного отвлечёмся от таблицы и подумаем как мы будем считать маркетинг.

В нашей модели мы выберем самый простой (и от того надёжный) подход — будем напрямую оценивать стоимость привлечения покупателя нашей игры, ака CPI — Cost Per Install. Не путайте с Cost Per Impression, в этом посте мы будем говорить только об установках.

CPI для Steam величина такая же неопределённая, как конверсии в вишлисты и из них, зато:

• Это один параметр, а не два. Меньше эффект накопления ошибки по цепочке, не будет искушения подгонять параметры друг под друга.
• Его проще оценить, достаточно знать бюджет на маркетинг и суммарное количество продаж игры. Эту информацию мы добыли, когда искали игры-маяки.
• CPI — глобальное иннериционное явление, он меньше склонен резко меняться, обычно только увеличивается следует долгим глобальным трендам.
• Оценка CPI может быть точнее конверсий вишлистов, так как напрямую и жёстко ограничивается рынком: бюджетами, готовностью людей вестись на реклмау, etc. Компании, сделавшие плохой маркетинг, уходят с рынка. Если мы будем использовать данные успешных продуктов, мы будем получать относительно реалистичную оценку CPI.

CPI для базовой игры мы будем оценивать просто:

• Бюджет на маркетинг игр-маяков принимаем равным половине их доходов (revenue).
• Делим бюджет маркетинга на оценку количества покупок, получаем CPI.

Наш CPI (для базовой игры) установим примерно посередине между играми-маяками. Дополнительно обращу внимание, что мы заложили меньшие продажи, чем у игр-маяков, поэтому и CPI может быть чуть ниже. CPI растёт по мере охвата целевой аудитории, так как становится сложнее находить новых покупателей.

Траты на маркетинг

Итак, возвращаемся к самой большой области наших расходов. Согласно финальным расчётам нашей модели к релизу на маркетинг уйдёт раза в 2.5 больше, чем на разработку :-D

[54] Marketing Ongoing Cost — Оценка минимальной перманентной ежемесячной активности по «лёгкому» пиару игры, чтобы не пропадать с радаров.

[55] Marketing Videos Cost — Ожидаемая стоимость разработки видео под конкретные события (релизы). Стоимость минуты видео относительно легко можно нагуглить. А можно даже написать конторам, которые этим занимаются, вам дадут прайс-лист.

[56] Marketing New User Cost— Ожидаемая стоимость привлечения новых пользователей — CPI.

[57] Marketing Old User Cost — Ожидалемая стоимость привлечения наших игроков к покупке DLC.

[58] Marketing Performance on New Users (Game) — Траты на привлечение новых игроков, в месяц.

[59] Marketing Performance on Old Users (DLC)— Траты на привлечение наших игроков к покупке DLC, в месяц.

[60] Marketing Month Cost — Все траты на маркетинг в месяц.

[61] Total Marketing Cost — Суммарные траты на маркетинг с начала времён по текущий месяц включительно.

Итоговые суммы

По сути, самая важная часть нашей таблицы — итог всей нашей работы, всех наших исследований и расчётов.

[62] Month Costs — Все затраты в месяц.

[63] Total Costs — Суммарные затраты с начала времён по текущий месяц включительно.

[64] Month Gross Revenue — Наш доход в месяц, после всех приходов и расходов.

[65] EBITDA— EBITDA как она есть — наши деньги до вычета непрямых расходов (налоги, амортизация, проценты, etc). Этот параметр смотрят инвесторы.

Что делать, когда закончили финансовую модель

После того как вы вобьёте последнюю формулу, растянете колонки на нужное количество месяцев, разукрасите всё, вы посмотрите на итоговые числа и увидите, что там фигня какая-то неприбыльная. Или, наоборот, сильно подозрительно прибыльная.

Это значит, что у вас начинается очень интерсный этап настройки модели, когда вы крутите кучу рычажков (констант в таблице), играетесь с объёмом работ, размером команды, чтобы получить картину, которая будет убедительной для вас и для инвесторов.

Have Fun!

Сколько времени заняла разработка бизнес-плана

Вместо заключения приведу статистику по времени, которые у меня отняли эти документы.

Конечно, это примерное время, так как я не делал эту работу full-time.

• Краткая стратегия компании — стратегию вы продумываете не в какой-то конкретный момент, а всё время пока работаете над концептами, презентациями, и прочим. Потом вы просто записываете информацию, которая уже давно сидит в голове.
• Табличка игр-маяков — ±2 дня. Долго пытался понять что и где искать, когда разобрался, пошло быстро.
• Состав команды — меньше дня, базовый состав должен быть хорошо виден из Roadmap.
• Roadmap — ±2 дня.
• Зачатки маркетинговой стратеги — тут те же соображения, как и с общей стратегией.
• Финансовая модель — ±3 дня, концепция расчётов несколько раз менялась. Если взять готовую модель, то намного быстрее будет.

На этом всё. Спасибо за ваше время и удачи в геймдеве!