В посте это есть, но мне хотелось бы немного формализовать описание процесса.
1. Расписываем весь проект по пунктам. Какие менюшки, сколько уровней, игровые механики, список катсцен, система автотестов, сборка демобилда. Чем больше всего вспомните, тем лучше. Собственно, на то это и препродакшн, чтобы продумать всю игру. И тут же кроется почему бюджет домножают - все равно какие-то пункты забудут.
2. По каждому пункту расписываем сколько дней какого специалиста надо. Например, этот интерфейс дизайнер мокапит полдня, художник рисует за день и программист обвязывает за 2 дня.
3. Добавляем время на плейтесты, багофиксы, участие в выставках, отпуска, буфер на случай переделок и т.п.
4. Смотрим сколько месяцев выходит на каждого сотрудника (с учетом выходных), умножаем на зарплату сотрудника и вот у нас есть оценка фонда оплаты труда.
5. Также выписываем всё, что нужно аутсорсить и уточняем цены у потенциальных подрядчиков.
Чуть более продвинутый подход, когда считаете не зарплаты каждого, а оперируете понятием burn rate per employee. Типа сколько денег студия тратит за месяц поделенное на количество сотрудников. Тут может быть и аренда офиса, и услуги бухгалтера, и налоги, и печенки на кофепоинте, и хайринг, и много чего ещё. При этом в каждом регионе есть свои стандарты burn rate. Издатели и инвесторы в курсе где сколько и поэтому поймут и примут вашу смету, если вы её посчитаете через количество сотрудников * месяцы * burn rate на сотрудника. Но всё равно вы обосновываете количество месяцев скопом фичей, а не чуйкой.
Ярослав, а что вы думаете по поводу умножения финальной суммы на множитель (например, на 2)? Обоснована ли такая практика или лучше вообще не применять этот подход?
Я бы сказал burn rate считать банально удобней, но у тебя должна быть +- устоявшаяся команда работающая над одним проектом. Другая ситуация, когда в команде пара ключевых людей, а остальных ты еще сам не знаешь - кого будешь искать на фултайм, а какие задачи будешь аутсорсить. Или например вы делаете больше одного проекта за раз (например аутсорс и свой параллельно) и люди между задачами скачут: тогда лучше прикинуть по человекодням
Как прикинуть, сколько уровней у меня будет, если игра скажем, головоломка от первого лица типа Портал? Только начав работу над новым уровнем понимаешь, что надо написать еще пару механик, сколько кат сцен сделать. Мне кажется, разработчики там не сразу придумали всякие эти гели и прочие механики, а постепенно, в процессе разработки. Или нет? Как такое на препродакшене вообще продумывать? Как дизайнер уровней, Вы наверно с таким сталкивались?
В посте это есть, но мне хотелось бы немного формализовать описание процесса.
1. Расписываем весь проект по пунктам. Какие менюшки, сколько уровней, игровые механики, список катсцен, система автотестов, сборка демобилда. Чем больше всего вспомните, тем лучше. Собственно, на то это и препродакшн, чтобы продумать всю игру. И тут же кроется почему бюджет домножают - все равно какие-то пункты забудут.
2. По каждому пункту расписываем сколько дней какого специалиста надо. Например, этот интерфейс дизайнер мокапит полдня, художник рисует за день и программист обвязывает за 2 дня.
3. Добавляем время на плейтесты, багофиксы, участие в выставках, отпуска, буфер на случай переделок и т.п.
4. Смотрим сколько месяцев выходит на каждого сотрудника (с учетом выходных), умножаем на зарплату сотрудника и вот у нас есть оценка фонда оплаты труда.
5. Также выписываем всё, что нужно аутсорсить и уточняем цены у потенциальных подрядчиков.
Чуть более продвинутый подход, когда считаете не зарплаты каждого, а оперируете понятием burn rate per employee. Типа сколько денег студия тратит за месяц поделенное на количество сотрудников. Тут может быть и аренда офиса, и услуги бухгалтера, и налоги, и печенки на кофепоинте, и хайринг, и много чего ещё. При этом в каждом регионе есть свои стандарты burn rate. Издатели и инвесторы в курсе где сколько и поэтому поймут и примут вашу смету, если вы её посчитаете через количество сотрудников * месяцы * burn rate на сотрудника. Но всё равно вы обосновываете количество месяцев скопом фичей, а не чуйкой.
Ярослав, а что вы думаете по поводу умножения финальной суммы на множитель (например, на 2)? Обоснована ли такая практика или лучше вообще не применять этот подход?
Я бы сказал burn rate считать банально удобней, но у тебя должна быть +- устоявшаяся команда работающая над одним проектом. Другая ситуация, когда в команде пара ключевых людей, а остальных ты еще сам не знаешь - кого будешь искать на фултайм, а какие задачи будешь аутсорсить. Или например вы делаете больше одного проекта за раз (например аутсорс и свой параллельно) и люди между задачами скачут: тогда лучше прикинуть по человекодням
Как прикинуть, сколько уровней у меня будет, если игра скажем, головоломка от первого лица типа Портал? Только начав работу над новым уровнем понимаешь, что надо написать еще пару механик, сколько кат сцен сделать. Мне кажется, разработчики там не сразу придумали всякие эти гели и прочие механики, а постепенно, в процессе разработки. Или нет? Как такое на препродакшене вообще продумывать?
Как дизайнер уровней, Вы наверно с таким сталкивались?