Круглый стол: как рассчитать бюджет на создание своей инди-игры
Разработчики и издатель делятся своим опытом.
Инди-разработка бывает разной — условия работы зависят от количества сотрудников, типа финансирования, масштаба проекта. Часто создание игр — это лишь хобби, которым человек занимается ради удовольствия. В таком случае у него мало ограничений: он волен делать игру столько, сколько хочет и вкладывать в разработку любое количество денег.
Если же создание игры — это бизнес, который должен принести доход, а разработкой занимается сразу несколько человек на full-time, то появляется закономерный вопрос: как поддерживать этот бизнес на плаву? Очевидно, нужны источники финансирование и умение правильно ими распоряжаться. Как решить первую проблему, мы поговорим в будущем, а в этот раз сосредоточимся на анализе потенциальных расходов при разработке игры.
Чтобы понять, как посчитать бюджет для игры, мы поговорили с проектным менеджером и нарративным дизайнером Ash of Gods: The Way Антоном Баженовым, Head of Publishing в HypeTrain Digital Иваном Белоусовым, сооснователем Konfa Games Николаем Кузнецовым, разработчиком из Morteshka Владимиром Белецким, создателем The Executioner Фуадом Кулиевым. Все они поделились опытом и дали несколько советов, как составить смету для своего проекта.
Планируем расходы своей студии
По словам Кузнецова, когда работаешь небольшой командой, сложно точно спрогнозировать расходы. Заранее можно лишь определить, сколько денег потребуется, если привлекать дополнительных людей: к примеру, заказывать локализацию на английский.
Когда мы начали делать [свою вторую игру] Despot’s Game, у нас уже был некоторый опыт, поэтому удалось заранее прикинуть расходы: составили табличку прямо в Google Sheets, определили, сколько времени понадобится на каждую крупную задачу, указали средние по рынку зарплаты на эти задачи. А потом получившееся число умножили на полтора (надо было на три).
Фуад Кулиев отметил, что при создании The Executioner его команда допустила несколько ошибок планирования бюджета.
[Наш метод планирования бюджета] выглядел как: «У нас есть ХХХ долларов, давайте попробуем сделать игру и потратить поменьше [денег]».
На практике нам стоило на препродакшене создать список крупноуровневых задач и решить, какие будет выполнять команда, а какие — аутсорс. Команда работает через burn rate, поэтому можно с помощью спринтов или диаграмму Ганта понять, какими будут расходы. Аутсорс обычно оценивает стоимость позадачно.
Похожим образом действовала и команда Morteshka. Владимир Белецкий рассказал, что бюджет разработки составили, анализируя ежемесячные траты студии.
Мы отталкивались от ежемесячных затрат и примерного срока [релиза] проекта. Сверху добавляли дополнительные затраты, например, на локализацию. Но не всегда удавалось предусмотреть их или верно просчитать.
Срок проекта рассчитывался, исходя из объёма контента, который мы планировали реализовать. Кроме того, мы постоянно актуализируем бюджет в соответствии с текущей ситуацией.
Такой метод формирования бюджета хорошо подходит для небольших инди-разработчиков, которые хотят сохранить гибкость, творческую свободу и добиться естественного развития игры. Но для более крупных команд нужен иной подход: если это не инди, а коммерческая разработка, то важно тщательнее распланировать каждый этап создания игры.
По словам Антона Баженова, начинать планирование стоит со скоринга проекта: на этом этапе определяется время разработки, состав команды, требуемый контент, софт, необходимость привлечения аутсорса. Также важно примерно оценить перспективы игры и её окупаемость. Всё это сводится в единую таблицу, разделённую на несколько этапов разработки — для каждого этапа нужно составить список требуемых сотрудников.
По такой таблице должно быть понятно, сколько людей будет работать над проектом на каждом этапе, что они будут делать, сколько времени и денег уйдёт на разработку в целом, когда у проекта появится First Playable, Alpha, Beta, Release Candidate, какая поддержка планируется после релиза.
Для примера рассмотрим препродакшен. На этом этапе потребуются: геймдизайнер, чтобы определить кор-луп игры, нарративный дизайнер, чтобы написать историю, арт-директор, чтобы определить стиль проекта, разработчики, чтобы подготовить техническую базу. Ещё желательно привлечь проектного менеджера и продюсера — первый составляет расписание и делает всё, чтобы команда ему следовала, второй имеет чёткое видение проекта и принимает ключевые решения.
Но количество людей и состав команды зависят от проекта и его потребностей. Возможно, в какой-то момент препродакшена понадобится технический художник или геймдизайнер для разработки боевой системы.
Когда команда определена, нужно понять объём работы и обозначить сроки.
Допустим, у нас есть три месяца, чтобы закончить препродакшен. Таким образом мы определяем burn rate команды, вносим всех в таблицу. Геймдизайнер и нарративный дизайнер будут работать все три месяца препродакшена с зарплатой в тысячу долларов, то же самое касается арт-директора и разработчиков, но их зарплата будет 2 тысячи долларов, а ещё на последний месяц этого этапа мы возьмём художника-концептера за 1,2 тысячи долларов. Вносим всё это в таблицу — итого получается, что только на препродакшен и только на зарплаты мы потратим 25,2 тысячи долларов.
Николай Кузнецов из Konfa Games рассказал, что в его команде зарплаты выставляли в соответствии со средним уровнем на рынке. Баженов отметил, что в любом случае стоит выставлять зарплаты, отталкиваясь от размера своего бюджета.
Далее нужно определить, какую часть работы стоит отдать на аутсорс. Здесь используется похожий алгоритм: сперва нужно оценить объём работы, затем найти подходящих людей и договориться о стоимости их услуг.
Например, мы договорились, что композитор напишет нам пять треков длиной две минуты по цене тысяча долларов за минуту. Мы заключаем договор, по которому он получает аванс 50% до начала работ — в третьем месяце препродакшена. Это значит, что стоимость препродакшена вырастает на 5 тысяч долларов — до 30,2 тысячи долларов.
Также не стоит забывать про расходы на софт. Баженов отметил, что множество инструментов, сервисов и программ понадобятся с первого дня разработки, поэтому их стоимость тоже попадает в бюджет препродакшена. Есть много дополнительных неочевидных моментов, которые также влияют на финальную сумму.
В идеале компании нужна юридическая поддержка и делопроизводитель, который будет заниматься документами — это ещё расходы. Переводя зарплату каждому сотруднику, вы платите банковскую комиссию. Это тоже расходы, которые увеличиваются пропорционально количеству людей в команде. Также могут возникать неучтённые расходы, поэтому мы дополнительно внесём в таблицу 0,9% от общей суммы трат за каждый месяц.
В результате таблица должна показать, сколько будет стоить проект — тогда вы сможете решить, стоит ли вообще им заниматься.
Как признался Баженов, это не совсем инди, а, скорее, коммерческая разработка — то, какой она должна быть, и то, к чему должны стремиться инди.
Как правило, [у инди] нет организации, нет чёткого плана и понимания критического пути проекта, нет осознания того, что время — это деньги, нет понимания, что нельзя просто взять и добавить новую фичу в середине разработки, потому что это повлечёт сдвиг релиза на неопределённое время. И чем больше проект, тем больше проблем, за которыми нужно следить.
Как издатель оценивает план разработчиков
Иван Белоусов из издательства HypeTrain Digital рассказал, что при сотрудничестве со студиями-разработчиками, он смотрит на ежемесячные траты инди-команды и в общем оценивает план работы.
При оценке бюджета мы в первую очередь смотрим на burn rate команды — сколько она тратит на разработку в месяц, а также на сам план разработки: насколько он кажется нам реалистичным по срокам, закладывается ли там время на доработку и тестирование.
Белоусов рассказал, что не стоит излишне завышать или занижать бюджет. Если он будет слишком низким, то разработка может превратиться в ад, потому что придётся постоянно отвлекаться на решение сторонних проблем. Если же бюджет будет слишком высоким, то разработчики получат свой доход с запозданием — деньги от продаж игры сначала идут на покрытие расходов издателя, а только потом — студии.
Когда мы работаем с независимыми командами, мы исходим из того, что их финальная цель — как можно раньше начать зарабатывать с продаж игры. Поскольку у нашего финансирования приоритет по возврату, мы советуем найти баланс, который позволит комфортно разработать игру, но в то же время не повышать свои риски после релиза.
При этом не должно возникать ситуаций, в которых у команды закончились деньги, и она не может продолжать разработку. HypeTrain Digital работает со студиями по майлстоунам, а в случае отклонения от плана просит его актуализировать.
Если мы понимаем, что у игры большой потенциал, но ей всё ещё чего-то не хватает, то мы обсуждаем обновление плана.
Самая распространенная ошибка — это несоответствие запланированного бюджета и реального потенциала проекта. Но это уже касается слабого препродакшена в целом, особенно у разработчиков из России и СНГ.
Советы разработчикам
По словам Баженова, если деньги кончились, а игра ещё не готова, то это вина людей, которые планировали разработку: проектного менеджера, продюсера и остальных.
Поэтому так важно, чтобы в инди-командах был кто-то, кто принимает решения, может вовремя вмешаться и не дать геймдизайнеру запросить новую фичу. Такие вещи видны заблаговременно. Если у тебя за спринт команда не выдала необходимый объём работы, то, экстраполировав результаты на оставшееся время разработки, можно понять, что деньги кончатся раньше релиза. И это проблема, которую нужно решать.
Николай Кузнецов упомянул, что после того, как приблизительный бюджет рассчитан, его нужно умножить на коэффициент 1,5-2 — всё дело в непредвиденных расходах, которые обязательно появятся в ходе разработки. Хотя, по мнению Белоусова, это не лучшее решение, так как оно показывает, что план недостаточно точный.
Мы сталкивались с тем, что какие-то разработчики в конце добавляют какой-то процент, а порой и вовсе умножают всё на два. Мы не особо разделяем такую практику. Кажется, это плохо чисто с точки зрения психологии: что-то планируешь, но заранее думаешь, что твой план нереалистичный. Так сделай его реалистичным.
Белоусов считает, что инди-командам не стоит сразу же планировать разработку целой игры — лучше сначала сделать демо, а потом решить, стоит ли продолжать работу.
Не пытайтесь сразу составить бюджет всей игры и последующих дополнений. Начните с того, сколько вам нужно на пре-альфу, вертикальный срез. После этого уже смотрите на фидбек и думайте, как развивать проект дальше и стоит ли. Может быть жалко потратить два месяца впустую, но куда хуже потратить напрасно два года.
По словам Кузнецова, оценка трат и планирование бюджета — «это навык, который тоже нужно прокачивать — и первое время будет получаться плохо».
Кузнецов не советует необдуманно браться за разработку — лучше придумать несколько запасных планов, чтобы всегда была возможность отступить. Также Николай советует не слишком спешить с разработкой, так как повысить burn rate команды намного легче, чем снизить. Кроме того, люди склонны занижать количество времени, которое нужно для выполнения задачи: когнитивное искажение «ошибка планирования» — одно из самых известных.
Белецкий считает, что даже в условиях полной неизвестности лучше иметь хотя бы приблизительный план, чтобы просто двигаться дальше, а не стоять на месте.
Точный бюджет становится известен в один единственный момент — когда проект завершён, тут ситуация схожая с любым другим планированием. Тем не менее даже грубый план на этапе прототипирования помогает понять, куда двигаться дальше, где там финал за туманом войны, и далеко ли финальные титры. Так что совет один — планировать в любом случае, даже если план будет изначально неточен.
Кулиев также советует всегда иметь план под рукой — не стоит бездумно начинать разработку, имея определённую сумму денег.
На абсолютно любой бюджет можно сделать завершённый продукт и на абсолютно любой бюджет можно не сделать продукт вообще.
В будущем мы продолжим рассказывать про финансовую сторону разработки игр. Если у вас есть релевантный опыт, расскажите о нём в комментариях.
хороших людей и почитать приятно!
В посте это есть, но мне хотелось бы немного формализовать описание процесса.
1. Расписываем весь проект по пунктам. Какие менюшки, сколько уровней, игровые механики, список катсцен, система автотестов, сборка демобилда. Чем больше всего вспомните, тем лучше. Собственно, на то это и препродакшн, чтобы продумать всю игру. И тут же кроется почему бюджет домножают - все равно какие-то пункты забудут.
2. По каждому пункту расписываем сколько дней какого специалиста надо. Например, этот интерфейс дизайнер мокапит полдня, художник рисует за день и программист обвязывает за 2 дня.
3. Добавляем время на плейтесты, багофиксы, участие в выставках, отпуска, буфер на случай переделок и т.п.
4. Смотрим сколько месяцев выходит на каждого сотрудника (с учетом выходных), умножаем на зарплату сотрудника и вот у нас есть оценка фонда оплаты труда.
5. Также выписываем всё, что нужно аутсорсить и уточняем цены у потенциальных подрядчиков.
Чуть более продвинутый подход, когда считаете не зарплаты каждого, а оперируете понятием burn rate per employee. Типа сколько денег студия тратит за месяц поделенное на количество сотрудников. Тут может быть и аренда офиса, и услуги бухгалтера, и налоги, и печенки на кофепоинте, и хайринг, и много чего ещё. При этом в каждом регионе есть свои стандарты burn rate. Издатели и инвесторы в курсе где сколько и поэтому поймут и примут вашу смету, если вы её посчитаете через количество сотрудников * месяцы * burn rate на сотрудника. Но всё равно вы обосновываете количество месяцев скопом фичей, а не чуйкой.
Ярослав, а что вы думаете по поводу умножения финальной суммы на множитель (например, на 2)? Обоснована ли такая практика или лучше вообще не применять этот подход?
Я бы сказал burn rate считать банально удобней, но у тебя должна быть +- устоявшаяся команда работающая над одним проектом. Другая ситуация, когда в команде пара ключевых людей, а остальных ты еще сам не знаешь - кого будешь искать на фултайм, а какие задачи будешь аутсорсить. Или например вы делаете больше одного проекта за раз (например аутсорс и свой параллельно) и люди между задачами скачут: тогда лучше прикинуть по человекодням
Как прикинуть, сколько уровней у меня будет, если игра скажем, головоломка от первого лица типа Портал? Только начав работу над новым уровнем понимаешь, что надо написать еще пару механик, сколько кат сцен сделать. Мне кажется, разработчики там не сразу придумали всякие эти гели и прочие механики, а постепенно, в процессе разработки. Или нет? Как такое на препродакшене вообще продумывать?
Как дизайнер уровней, Вы наверно с таким сталкивались?
По горячим следам вопрос: почему не в геймдев, а в новый закрытый клуб? Я думаю такие посты интересней тем, кто только на пути в геймдев, а не тем, кому уже есть что показать.
Я подумал, что этот раздел в первую очередь убежище от массовой аудитории, когда хочется обсудить щекотливые темы. Иначе совсем грань между тремя разделами размывается
Николай, мы не стремимся прятать здесь щекотливые темы. Наша задача скорее в том, чтобы «перезапустить» профессиональную дискуссию на сайте. В любом случае в первое время мы будем искать баланс и пробовать разные темы.