Как НЕ стоит создавать инди-команды. Часть 1

Вступление

В данный момент я состою в команде энтузиастов, которая занимается разработкой крупного проекта - видеоигры по известному фэндому. Команда начала собираться более 4 лет назад, но фактическая разработка игры началась всего 1.5 года назад. Я пришёл в команду через полгода после её создания и в данный момент являюсь самым старым её участником и знаю почти что всю её историю.

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

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

    1. Идеи для игры

Ошибки на этапе разработки идей

Изначально команда собиралась, чтобы сделать нормально работающую, оптимизированную игру с уклоном не в казуал, а в ролевой отыгрыш, если не на замену, то как минимум для ролевой части аудитории игры от польских разработчиков по всемирно известному фандому.
Мы придумали огромное количество самых разнообразных идей, придумали как усовершенствовать механики, существовавшие в той игре, придумали десятки фич и тому подобное. Мы были уверены, что делаем всё правильно, вот только на вопрос “а какой должна быть игра” никто не мог ответить. Мы придумали сотни идей, но собрать их в одну игру никак не получалось. Одни механики задавали быстрый темп, другие медленный, одни требовали мини-игр, а другие аналогичные обходились без них, многие механики и фичи не сочетались, а иногда и взаимоисключают друг друга. Всё это не позволяло нормально определять вектор развития, составить карту разработки, определить приоритетные задачи. Таким образом дальше разработка даже не началась.

К чему приводит такой подход

Так было первые полтора года. А затем решили одну из идей, как мы её называли кор-фичу, разработать, чтобы привлечь разработчиков (об этом позже) - редактор карты. За 3 месяца он был полностью сделать, все публичные площадки проекта говорили о нём, говорили в YouTube. Но фактически он был бесполезен. Он создавал карту для игры, которой просто нет. В данный момент от этого редактора команда отказалась. Именно в таких моментах проявляется проблема отсутствия составленного концепта.

Исправление ситуации

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

    2. Обучение

Обещание обучить

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

"Будем учить полгода и вот тогда начнём"

С ещё одной аналогичной проблемой я столкнулся ещё в школьные годы. Кратко описать её можно следующей фразой “Давай я учу программирование, а ты модели делать, через полгода, когда научимся, начнём делать”. Суть проблемы в том, что не имея даже базовых знаний в сфере разработки игр, многие ребята собираются в небольшие команды, придумывают идеи для игры, но момент начала разработки не наступает, так как никто не обладает навыками, требуемыми для разработки игры. Часто это приводит к тому, что участники команды договариваются читать книги по какой-то из сфер программирования и “учить” её. И на этом моменте всё заканчивается, так как никто не выучивает свою сферу.

Можно выделить два фактора, сопутствующие ситуации: отсутствие коммуникации в процессе обучения, отсутствие плана обучения. Первый фактор подразумевает, что каждый член команды учит всё отдельно и не сообщает никому об успехах или проблемах. Такое обучение малоинтересно человеку, а какая-либо трудно решаемая проблема может полностью лишить обучающегося мотивации. Второй фактор подразумевает, что обучающийся не формируют список необходимых для изучения знаний, что приводит к прокрастинации в связи непониманием целей применения изучаемого материала. К примеру нет никакого смысла изучать тяжёлое и требовательное HardSurface моделирование, если ваша игра в Low Poly стиле.

Более верный подход к командному обучению

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

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