Во всем виноваты бюджеты

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

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

Но перед тем как продолжить читать дальше, послушайте отличный доклад от Petri Purho "Why Being Poor and Having No Budget is Good For Making Game". Его я привожу часто в пример, когда начинаются разговоры за бюджеты. Он банальный, в нем нет ничего нового, но он дает понять, что игры можно делать и без бюджетов.

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

Немного о мастер классе Матиаса Кэмпкэ

Вчера нам довелось побывать на мастер-классе Матиаса Кемпке, который главный дизайнер скоро выходящего The Night Of The Rabbit. Вчерашнюю встречу сложно назвать мастер-классом, это скорее рассказ Матиаса о том, как он начал делать игры и пришел к разработке такого проекта, как TNoTR.

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

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

1. Vision Keeper - понятие, о котором часто забывают, но нельзя отрицать необходимость такого человека. Этот человек в команде, который отвечает за целостность виденья и изначальной идеи, не давая ей превратиться в мутанта, еле стоящего на ногах, по причине, что все пихали идеи и меняли общий вижн проекта. По сути это может быть продюсер, лид дизайнер или другой человек в команде, который не будет давать нарушить общую идею, канву истории или сетинг идеями и фичами, которые производит команда.
2. Шаринг знаний - когда работаешь один или в команде из двух трех человек, можно обойтись без детальной документации и все обьяснить на словах, при большой команде необходима детальная документация, которая даст максимальные ответы на вопросы. Тут я конечно готов поспорить, но о достаточности документации я напишу в одном из последующих постов, так как мне есть о чем сказать. 
3. Проблема коммуникаций - при работе с большой командой дизайнеру необходимо каждый день много общаться со всей командой и отвечать на их вопросы. И это, кстати, самая сложная часть работы, так как помимо того, что нужно делать работы по продакшену, идет постоянное общение, которое отвлекает и занимает очень много времени. Но без этой части работы никуда, все знания всегда в голове дизайнера, и на вопросы все-таки нужно отвечать.
4. Проблемы коммуникаций внутри команды - зачастую члены команды плохо коммуницируют между собой, и если возникают какие-либо проблемы, то предпочитают промолчать и как-то решить, чем о них сказать вслух. Это тема еще одного из будущих постов, на тему взаимодействий внутри команды, а то проблем зачастую больше, чем можно себе представить.
5. Любая загадка в игре должна восприниматься как часть мира, а не препятствие - это очень справедливо, потому что когда ты втыкаешься в пазлы, которые вставлены в игру, чтобы затормозить игрока, а не потому что оно здесь действительно нужно, то очень легко сломать для себя магию игрового мира. Ну и на самом деле такие вещи сильно влияют на темп игры, и когда тебя резко останавливают без причины на то, играть становится не так комфортно.
6. Нельзя делать пазлы, идущие против логики игры, сюжета игры и здравого смысла - это опять таки касается первого пункта, когда мы храним общий вижн и не даем выходить за его рамки и соблюдаем целостность проекта, таких ситуаций быть не должно.

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

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

Начать с чистого листа, или испытание бумагой

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

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

 Что мы получаем:

• определенного рода структуру на выходе, которую можно шейрить с командой
• возможность проделать несколько итераций идеи на бумаге, пока она реально не заработает, такой себе прототип

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

Зачем это делать:

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

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

Завтра я попробую немного рассказать о сегодняшнем мастер классе Матиаса Кэмпке. Он натолкнул меня на ряд интересных моментов, о которых давно хотелось написать, но все руки не доходили.