5 вещей, который стали для меня открытием при ведении инди-команды

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

Часто слышал эти фразы и подобные им "Если хочешь делать игру, учись самостоятельно разрабатывать", "разрабатывать игры легко, просто ты ленивый", "учи движки и программирование". Но полюбить это дело я не сумел. Каждый раз при изучении C# или Bluprints, меня вгоняло в сон.

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

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

Как вы уже догадались долго это не продлилось. Первых задач по разработке долго не было. Мы вечерами сидели и обсуждали идею игры и начали именно с сюжета. Ни слова о механиках, ни слова о том, что должна делать разработка. От меня ждали подвижек, что начну что-то лепить. Конкретики не было. Мои попытки сделать "что-то" вгоняли в сон. Пока понял, что ничего не выйдет прошло около 3х недель.

Из этой инди-команды ушел забыв на некоторое время о геймдеве. И только сейчас думаю, ребята потеряли со мной 3 недели. Будь на моём месте, реально горящий разработкой парень, оно прошло бы с пользой для команды.

Это была первая и единственная ситуация. Идея давать тестовое задание пришла в голову не мне, а разработчику, который был со мной в команде. Не сильно понимал, почему он принял такое решение. Пока мы не поговорили.

На коммерческих проектах одна из мотиваций на ряду с интересным проектом - это деньги о то, что ты занимаешься разработкой в рабочее время. На инди-проектах, всё сложнее. Занимаемся на энтузиазме в свободное от личных дел и работы время. Безусловно, каждому хочется получать удовольствие от занятия проектом.

На тот момент в команде было 2 разработчика. Один полный опыта и желания сделать проект. Другой... непонятно. Дали ему несколько задач и он то появлялся, то нет. То говорит, что сделает задачи, то молчит. В итоге разработка, которая даже не началась уже встала в ступор. Это сильно ударило по мотивации моего напарника. С тех пор стараемся брать людей через тестовое задание, которое проверяет несколько особенностей.

Не смотря на то, что инди-команда, как правило, делает проект на идее у любого человека со временем может пропасть интерес к долгосрочным проектам такого рода. И это нормально. В таком случае многие проекты просто закрываются не успев дойти до релиза.

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

Согласитесь, эти слова заставляют задуматься. А в правильном ли направлении иду? Не трачу ли время в пустую?

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

Когда разработка затягивается, для таких ситуаций и должен быть "одержимый идеей". Пока есть этот человек, проект будет жить. Большинство инди-игр доводятся до конца благодаря таким людям. Более подробно можно увидеть в этом видео.

Слышал легенду о том, что наш мозг, когда видит задачу и у неё нет чёткого дедлайна, то мозг либо размазывает задачу по всему доступному времени, либо вовсе откладывает её на потом. В данном случае может отложить навсегда.

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

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

В дополнение, они обращались ко мне в обратную сторону. То есть, когда разработчиков становилось много, а материала для выполнения мало, наш Лид меня "пинал". Не смотря на то, что хотелось оставить продумывание некоторых механик на потом.

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

Возьмём для примере краткое ТЗ, для замка, которое описал для себя как синопсис:

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

Описание для разработчика

на экране замка присутствуют объекты: здание, игральные карты, герой.

При открытии объекта здание, должно открываться топ-ап окно привязанное к данному объекту. В одном из объектов "Казармы" можно выбирать объект "игральные карты". И при нажатии на специальный кнопку в IU, можно регулировать численность закупаемых карт, которые также отображаются на панели ресурсов.

Художники для художника

Потребуется отрисовать спрайты: казармы, замок, элементы UI интерфейса, кнопки и ползунки для изменение количества при наёме существ. Элементы интерфейса и наполнение замка должны быть выполнены в Романской стиле. Замок располагается на равнине, поэтому краски нужно подобрать достаточно яркие, чтобы передать освещение. Некоторе здания должны быть слегка порушены, чтобы было видно, что замок уже пережил не один десяток нападений, но всякий раз худо бедно его восстанавливали.

Почему изначально это было проблемой?

Было сложно разделять, казалось бы не делимую сущность в описании задач. Когда описываешь замок, хочется добавить ему художественности. Это приводила к захламлённости в описании, в то время когда нужна чёткая выжимка, о том, что это такое и как это изобразить. Конечно художникам я продолжаю добавлять описание характеристики существа, чтобы было понятно, что оно из себя представляет. Но с технической точки зрения это просто объект, на который натягивается спрайт. Ни более ни менее.

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

Изначально у нас было немного людей. Всего трое. геймдизайнер, художник и разработчик. Дело по чуть-чуть двигалось и даже появлялись первые скетчи и намёки на игровые механики в прототипе. Но постепенно энтузиазм угасал.

Приходилось с этим что-то делать. Медленно но верно, искали ещё желающих. И заметил такую тенденцию.

Каждый раз, когда на проект приходил новый человек он с большим интересом брался за новые задачи. Это не могло не сказываться на продуктивности остальной команды. Проходило какое-то время и всё начиналось по новой. Иногда люди отваливались конечно. И мы постепенно искали новых. Когда они приходили, проект вновь получал новый толчок, а затем вновь всё немного затихало.

Есть один известный инди-проект, который распространяется бесплатно

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

Для чего я написал этот пост?

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

Какие вещи для вас оказались сюрпризом?