Недавно в очередной раз попробовал поучаствовать в небольшом инди проекте.
Сделал прототип с примитивной графикой, второй партнер должен был завезти улучшенную графику, но не смог, и я в целом решил написать небольшую статью о том — почему очень хочется, но не получается. В статье много банальщины, но может кому пригодится.
Да и еще раз да, с сроками все пролетают, от маленьких до больших разработок, потому-что получение качественного игрового процесса это очень сложно, и очень много времени уходит на переделку фич и геймплея. Но корень зла зачастую хранится именно в первичной оценке сроков.
Возьмем простой прототип кликера — тапаем по экрану, герой лупит монстра мечом и скиллами. Всё супер просто, большинство разработчиков оценив масштабы прототипа скажет что на такую задачу может уйти от нескольких часов до дня/парочки.
Код
Интерфейс
Даже для прототипа нужен минимальный интерфейс, но если мы рассматриваем прототип/PoC (proof of concept), желательно иметь вкусный дизайн и нормальный UX. Минимум который нужен:
Графика и анимация
Тут более менее понятно
Спецэффекты
Звуки
Просто смотрим предыдущие списки и на всю графику, интерфейс и спецэффекты добавляем звуки. На это уходит очень много времени.
Чтобы показать первичный объем который нужно провернуть, чтобы получить хоть какой то играбельный прототип, который может называться игрой. Я не учёл локализацию и много другой работы, но основную мысль которую я хочу донести — это первичный объем работы.
Я вывел небольшое правило — даже на маленький таск может легко уйти от часа до двух. Очень мало людей занимаются инди разработкой фултайм. Многие из которых я знаю — совмещают с полноценной работой. То есть на инди разработку уходит только свободное вечернее время, у меня это порядка 2-3 часов, думаю у большинства на самом деле также. 1+ несложный таск в день. На сложный таск может уйти несколько дней. Не каждый день получается работать над проектом в силу различных причин. В итоге объем в списках выше — это уже больше месяца работы, при том что всё идёт хорошо, и все профи. А это только прототип. А потом понадобится более сложная система апгрейдов, еще больше графики, завезти разный шмот который влияет на атаку/скиллы/хп/нанятых героев, найм героев в помощь игроку, различные режимы игры.
Разработка симпатичного прототипа супер простого кликера может занять месяц или два, крайне легко, хотя как я писал выше — на первый взгляд работы там на пару дней максимум. А если брать бету — то может отнять год. Затягивание процесса фрустирует, и люди начинают отваливаться. Это при условии что все более менее опытные разработчики. И тут мы переходим к пункту 2.
Увы, хороший программист — не означает хороший инди разработчик, также как хороший художник/моделер/аниматор и тд. В инди разработке очень много начинающих, и отличный художник который очень хорошо рисует, может быть не в состоянии правильно подготовить графику для используемого движка. Будет много ошибок, реимпорт, перенастройки, переанимации и много всякого багла связанного с кривым импортом графики.
Насчёт программистов — отличный С# программист который не знает Unity3d, будет писать кучу своих велосипедов и решений, которые будут дублировать функционал Unity и не факт что будут хорошо работать. Потому что парадигма программирования в чистом шарпе и внутри юнити довольно весомо отличается.
Далее — если что то из списков выше делается первый раз, то понадобится время на ресерч, что опять умножает время разработки. Поэтому в итоге даже на простые таски уходит не день, а три. И мы опять получаем растягивание сроков. Для горящих молодых людей это будет необходимый опыт, а для ветеранов — очередное разочарование.
Итоги просты — даже маленький проект легко превращается в долгострой, люди перегорают когда не видят задорного результата, проект сливается в корзину.
Поэтому:
Насчёт советов — с удовольствием выслушаю ваши, интересен опыт движения инди проекта к релизу. С точки зрения организации процесса.
Сделал прототип с примитивной графикой, второй партнер должен был завезти улучшенную графику, но не смог, и я в целом решил написать небольшую статью о том — почему очень хочется, но не получается. В статье много банальщины, но может кому пригодится.
1. Сроки
Да и еще раз да, с сроками все пролетают, от маленьких до больших разработок, потому-что получение качественного игрового процесса это очень сложно, и очень много времени уходит на переделку фич и геймплея. Но корень зла зачастую хранится именно в первичной оценке сроков.
Возьмем простой прототип кликера — тапаем по экрану, герой лупит монстра мечом и скиллами. Всё супер просто, большинство разработчиков оценив масштабы прототипа скажет что на такую задачу может уйти от нескольких часов до дня/парочки.
Но! Давайте внимательно посчитаем минимальный объем работ:
Код
- Система интерфейсов(нужно уметь отображать всю необходимую инфу)
- Загрузка уровней
- Загрузка/пуллинг графики (в игре может быть много переиспользуемых эффектов/ресурсов)
- Главный персонаж и его умения
- Враг
- Система атаки
- Система прохождения уровней (должна возрастать сложность и собираться графика уровня)
- Система начисления очков
- Система апгрейда игрока (скиллы и бонусы от уровня)
- Система озвучки
- Система начисления/расхода ресурсов (у игрока могут быть скиллы за ману или по триггерам)
- Система хранения данных игрока (надо же хранить прогресс)
Интерфейс
Даже для прототипа нужен минимальный интерфейс, но если мы рассматриваем прототип/PoC (proof of concept), желательно иметь вкусный дизайн и нормальный UX. Минимум который нужен:
- Главное меню
- боевой интерфейс (с шкалами здоровья, экспы, прогресса уровня, шкалами маны, зарядки скиллов и тд)
- попап о победе в текущем раунде
- попап о проигрыше
- попап о лвлапе
- интерфейс апгрейда игрока
Графика и анимация
Тут более менее понятно
- Графика хотя бы трех врагов
- Графика главного героя
- Графика для генерации уровней
- анимация графики уровней
- На каждый скилл нужна анимация (тут надо умножать на количество скиллов).
- На базовые атаки нужна анимация (разновидностей базовых атак должно быть много, чтобы пользователю не было скучно смотреть на один и тот же замах меча)
- Анимация победы персонажа
- Анимация проигрыша персонажа
- Анимация атаки противника
- Анимация получения дамага противником
- Анимация полудохлого противника
- Смерть противника
Спецэффекты
- индикация дамага (всякие циферки, тряски, покраснения экрана)
- применение скиллов (на каждый скилл)
- индикация получения дамага(кровь/искры/дым)
Звуки
Просто смотрим предыдущие списки и на всю графику, интерфейс и спецэффекты добавляем звуки. На это уходит очень много времени.
Для чего все эти списки?
Чтобы показать первичный объем который нужно провернуть, чтобы получить хоть какой то играбельный прототип, который может называться игрой. Я не учёл локализацию и много другой работы, но основную мысль которую я хочу донести — это первичный объем работы.
Я вывел небольшое правило — даже на маленький таск может легко уйти от часа до двух. Очень мало людей занимаются инди разработкой фултайм. Многие из которых я знаю — совмещают с полноценной работой. То есть на инди разработку уходит только свободное вечернее время, у меня это порядка 2-3 часов, думаю у большинства на самом деле также. 1+ несложный таск в день. На сложный таск может уйти несколько дней. Не каждый день получается работать над проектом в силу различных причин. В итоге объем в списках выше — это уже больше месяца работы, при том что всё идёт хорошо, и все профи. А это только прототип. А потом понадобится более сложная система апгрейдов, еще больше графики, завезти разный шмот который влияет на атаку/скиллы/хп/нанятых героев, найм героев в помощь игроку, различные режимы игры.
Разработка симпатичного прототипа супер простого кликера может занять месяц или два, крайне легко, хотя как я писал выше — на первый взгляд работы там на пару дней максимум. А если брать бету — то может отнять год. Затягивание процесса фрустирует, и люди начинают отваливаться. Это при условии что все более менее опытные разработчики. И тут мы переходим к пункту 2.
2. Компетенции
Увы, хороший программист — не означает хороший инди разработчик, также как хороший художник/моделер/аниматор и тд. В инди разработке очень много начинающих, и отличный художник который очень хорошо рисует, может быть не в состоянии правильно подготовить графику для используемого движка. Будет много ошибок, реимпорт, перенастройки, переанимации и много всякого багла связанного с кривым импортом графики.
Насчёт программистов — отличный С# программист который не знает Unity3d, будет писать кучу своих велосипедов и решений, которые будут дублировать функционал Unity и не факт что будут хорошо работать. Потому что парадигма программирования в чистом шарпе и внутри юнити довольно весомо отличается.
Далее — если что то из списков выше делается первый раз, то понадобится время на ресерч, что опять умножает время разработки. Поэтому в итоге даже на простые таски уходит не день, а три. И мы опять получаем растягивание сроков. Для горящих молодых людей это будет необходимый опыт, а для ветеранов — очередное разочарование.
3. Итоги и советы
Итоги просты — даже маленький проект легко превращается в долгострой, люди перегорают когда не видят задорного результата, проект сливается в корзину.
Поэтому:
- Внимательно оценивайте реальный первичный объем работ, часто где вам кажется работы на один день, там может быть работы на 1 месяц командой, когда это всё затянется — команда может не выдержать и развалиться
- Старайтесь накапливать и переиспользовать решения, речь не только об наработках, но и о учебных материалах
- Первичный прототип может быть и с минимумом графики, но графика должна быть достаточно живой чтобы прототип понравился — нужны анимации и эффекты. Графики должно быть ровно столько — чтобы нравилось и чувствовался тот самый геймплей.
- Ведите разработку публично, выкладывайте в комюнити и на форумах прогресс проекта, разбивайте таски так чтобы результат был наиболее очевиден. Это будет создавать то самое ощущение правильного движения живого проекта. И команда будет понимать что их труд не напрасен.
Насчёт советов — с удовольствием выслушаю ваши, интересен опыт движения инди проекта к релизу. С точки зрения организации процесса.
