Почему инди проекты не доживают до релиза +8



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

1. Сроки


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

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

Но! Давайте внимательно посчитаем минимальный объем работ:


Код

  1. Система интерфейсов(нужно уметь отображать всю необходимую инфу)
  2. Загрузка уровней
  3. Загрузка/пуллинг графики (в игре может быть много переиспользуемых эффектов/ресурсов)
  4. Главный персонаж и его умения
  5. Враг
  6. Система атаки
  7. Система прохождения уровней (должна возрастать сложность и собираться графика уровня)
  8. Система начисления очков
  9. Система апгрейда игрока (скиллы и бонусы от уровня)
  10. Система озвучки
  11. Система начисления/расхода ресурсов (у игрока могут быть скиллы за ману или по триггерам)
  12. Система хранения данных игрока (надо же хранить прогресс)

Интерфейс

Даже для прототипа нужен минимальный интерфейс, но если мы рассматриваем прототип/PoC (proof of concept), желательно иметь вкусный дизайн и нормальный UX. Минимум который нужен:

  1. Главное меню
  2. боевой интерфейс (с шкалами здоровья, экспы, прогресса уровня, шкалами маны, зарядки скиллов и тд)
  3. попап о победе в текущем раунде
  4. попап о проигрыше
  5. попап о лвлапе
  6. интерфейс апгрейда игрока

Графика и анимация

Тут более менее понятно

  1. Графика хотя бы трех врагов
  2. Графика главного героя
  3. Графика для генерации уровней
  4. анимация графики уровней
  5. На каждый скилл нужна анимация (тут надо умножать на количество скиллов).
  6. На базовые атаки нужна анимация (разновидностей базовых атак должно быть много, чтобы пользователю не было скучно смотреть на один и тот же замах меча)
  7. Анимация победы персонажа
  8. Анимация проигрыша персонажа
  9. Анимация атаки противника
  10. Анимация получения дамага противником
  11. Анимация полудохлого противника
  12. Смерть противника

Спецэффекты

  1. индикация дамага (всякие циферки, тряски, покраснения экрана)
  2. применение скиллов (на каждый скилл)
  3. индикация получения дамага(кровь/искры/дым)

Звуки

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

Для чего все эти списки?


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

Я вывел небольшое правило — даже на маленький таск может легко уйти от часа до двух. Очень мало людей занимаются инди разработкой фултайм. Многие из которых я знаю — совмещают с полноценной работой. То есть на инди разработку уходит только свободное вечернее время, у меня это порядка 2-3 часов, думаю у большинства на самом деле также. 1+ несложный таск в день. На сложный таск может уйти несколько дней. Не каждый день получается работать над проектом в силу различных причин. В итоге объем в списках выше — это уже больше месяца работы, при том что всё идёт хорошо, и все профи. А это только прототип. А потом понадобится более сложная система апгрейдов, еще больше графики, завезти разный шмот который влияет на атаку/скиллы/хп/нанятых героев, найм героев в помощь игроку, различные режимы игры.

Разработка симпатичного прототипа супер простого кликера может занять месяц или два, крайне легко, хотя как я писал выше — на первый взгляд работы там на пару дней максимум. А если брать бету — то может отнять год. Затягивание процесса фрустирует, и люди начинают отваливаться. Это при условии что все более менее опытные разработчики. И тут мы переходим к пункту 2.

2. Компетенции


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

Насчёт программистов — отличный С# программист который не знает Unity3d, будет писать кучу своих велосипедов и решений, которые будут дублировать функционал Unity и не факт что будут хорошо работать. Потому что парадигма программирования в чистом шарпе и внутри юнити довольно весомо отличается.

Далее — если что то из списков выше делается первый раз, то понадобится время на ресерч, что опять умножает время разработки. Поэтому в итоге даже на простые таски уходит не день, а три. И мы опять получаем растягивание сроков. Для горящих молодых людей это будет необходимый опыт, а для ветеранов — очередное разочарование.

3. Итоги и советы


Итоги просты — даже маленький проект легко превращается в долгострой, люди перегорают когда не видят задорного результата, проект сливается в корзину.

Поэтому:

  1. Внимательно оценивайте реальный первичный объем работ, часто где вам кажется работы на один день, там может быть работы на 1 месяц командой, когда это всё затянется — команда может не выдержать и развалиться
  2. Старайтесь накапливать и переиспользовать решения, речь не только об наработках, но и о учебных материалах
  3. Первичный прототип может быть и с минимумом графики, но графика должна быть достаточно живой чтобы прототип понравился — нужны анимации и эффекты. Графики должно быть ровно столько — чтобы нравилось и чувствовался тот самый геймплей.
  4. Ведите разработку публично, выкладывайте в комюнити и на форумах прогресс проекта, разбивайте таски так чтобы результат был наиболее очевиден. Это будет создавать то самое ощущение правильного движения живого проекта. И команда будет понимать что их труд не напрасен.

Насчёт советов — с удовольствием выслушаю ваши, интересен опыт движения инди проекта к релизу. С точки зрения организации процесса.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (10):

  1. nrgian
    /#20183082

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


    Люди быстро учатся. Разве нет?
    Ну переделает художник первую порцию графики, если программист не удосужился заранее всё пояснить.
    Если, конечно, не решёно было сразу запилить 100% графики и только потом начинать скармливать графику движку…

    • Brightori
      /#20183086

      Не всё так просто, часто бывает нужен целый пласт знаний/скиллов, например 3д моделер делает воксельную графику в MagikaVoxel, там теперь несколько пространств с модельками, у каждой модельки генерится своя точка отсчёта координат относительно пространства, для каждого пространства генерится своя текстура, если в пространстве несколько моделек — у них всех смещен центр, это надо исправлять в 3д редакторах, если пространств много — надо сделать общий атлас. Если возник общий атлас — надо править ювишки. Если в юнити используется HDRP или LWRP — надо переделать шейдеры. Чтобы посвятить человека в нюансы, придётся потратить много времени на его обучение, причем обучение подразумевает как работу в юнити так и в 3д редакторах. Поэтому я упомянул что под наработками я также понимаю учебные материалы. Опять же человек может не понимать по английски.

  2. Vyaza
    /#20183424

    Касательно сроков полностью согласен, сам увяз в проекте «на полгода-год максимум», работаю третий год, и релиза даже близко не видать. Благо отваливаться некому — работаю один.

    • Brightori
      /#20184954

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

  3. androidovshchik
    /#20183456 / +1

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

    • MacroSss
      /#20184886

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

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

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

  4. superyateam
    /#20184110

    Сам наступал на эти грабли. Потерял около двух лет (понятное дело, работая в свободное время).
    Сделал вывод: работать одному — никаких партнеров. То, что я не умею — заказываю фрилансеру. Таким образом, проект зависит только от меня. Мне не нужно спрашивать партнера: «ну что там, как там, ты занимался проектом?». Никто меня не кормит завтраками.
    С фрилансерами, работающими за деньги — все гораздо проще, чем с так называемыми «партнерами».

    • Brightori
      /#20184924

      Да, это самый правильный выход) если работать на результат

  5. Areso
    /#20184842

    Если процесс доставляет удовольствие, то можно не релизиться в принципе. Уже три года веду проект в 1 лицо, все нормально. Для себя вывел правило, что у меня есть «стабильная ветка», где можно играть, и дев, где код может быть сломанным. В среднем раз в месяц выкладываю стабильные версии. Люди играют, но retention rate оставляет желать лучшего.

    • Brightori
      /#20184948

      Да ) хороший вариант, публичность разработки/проекта даёт необходимый драйв, но одному сложно сделать средний/большой проект. Один мой знакомый пилит 5 лет средний проект (стратежку), и даже прототип нормальный не сделал )