Вспомнить все

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

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

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

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

Так, к примеру, много лет назад я зарекся, что буду скриптовать, так как мне это банально надоело. И я действительно не скриптовал до начала этого года, когда мы начали в свободное от основной работы время делать проект - мне пришлось лезть и разбираться в юнити, найти удобный для себя формат и работать в нем (с playmaker мне стало куда проще работать с Unity). Но это "разобраться" пошло дальше, и я сейчас с удовольствием берусь поскриптовать в своем основном проекте, хотя это и не входит в мои обязаности, а мне, как оказалось на самом деле, нравится скриптовать.

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

На днях мне пришлось разбираться с google analytics, который я видел впервые, так как мы запускали блог для Isles Of Umbra и нуждались в статистике, которую в tumblr посмотреть нельзя. Теперь полученные знания и понимание работы google analytics мне пригодятся и в основной работе, так как я никогда с ним не сталкивался (в основном работал с самописными тулзами для статистики, которые более выгодны для игровых проектов, чем сторонние).

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

Да, можно сказать, что так мы никогда не будем профессионалами в одном направлении, но будучи indie необходимо быть человеком-оркестром, и уметь все на удовлетворительном уровне (критерии умений и знаний ставим себе сами) лучше, чем уметь что-то одно, но при этом утонуть в попытках найти людей, которые будут уметь другое и готовы войти в вашу команду

Indie way #2 - Ограничения

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

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

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

А теперь давайте поговорим про ограничения, которые разделим на три категории:

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

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

Indie way #1 - Технологии

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

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

Я всегда завидовал людям, которые максимально универсальны, могут и код писать и рисовать и музыку делать, и дизайн придумывать. Даже если все это делается не на high level. При наличии таких умений разрабатывать indie-игру куда проще, чем обладать узкопрофильными знаниями.
Все таки, если нет возможности собрать команду, то indie для людей-пароходов.

Прототип платформера с ревайдом времени с использованием GameMaker 8.1

Свой первый прототип/игру я сделал в 12 лет, и тогда мне это казалось просто "ВАУ!!!!!!!1111, я смог это сделать", для этого я использовал Blitz Max, на который случайно набрел в интернете, начитался туториалов и сделал змейку с генерируемой графикой. (в основе лежал один из туториалов для Blitz Max, который я довольно сильно модифицировал).

Прототип одного из проектов с использованием самописного движка

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

Прототип UI проекта, который я делал вместе с mercai используя UDK

Ладно, вступление как-то затянулось, так что перейдем к технологиям. За последние годы я опробовал многое - Unity, UDK, Game Maker, Stencyl, Construct, вновь Blitz Max с желанием сделать модификацию на SCP, Twine, Phaser и т.д. Кстати, у Pixel Prospector есть хороший гайд по технологиям, используемым для разработки игр, и проектам, сделанных на них. Проекты, понятное дело, не показатель удобности технологии, но гайд интересный.

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

Попытка сделать красивый Volume light с использованием GameMaker 8.1

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

• Документация -  как по мне, самый важный элемент любой технологии. Она помогает понять, как с этим работать, какие есть подводные камни и насколько сильно придется танцевать с бубном. Чем меньше документации, тем сильнее мы полагаемся на сообщество.
• Сообщество -  помогает с примерами, дает ответы даже на самые часто задаваемые вопросы по сотому разу, помогает с pro tips и прочими интересными вещами, которые не так легко обнаружить. Самое слабенькое коммюнити сейчас у Phaser, но тут и понятно, каждый считает, что проще написать свой html5 framework, чем развивать уже существующие, там дикий запад. Самые хорошие, но это опять имхо, у Game Maker и Unity.
• Простота использования - больше в контексте порога вхождения, так как не всегда высокий порог вхождения означает, что можно сделать что-то очень крутое,  но чем он выше, тем меньше людей остается с этой технологией, отсюда и меньшее количество людей в сообществе.
• Поддержка со стороны разработчиков - когда нет ответа в документации или в сообществе, единственный путь - обратиться к создателям. Когда есть официальная поддержка (пускай платная, что даже лучше), работать с таким движком куда приятнее, так как выше вероятность получить ответ. Но часто ситуация обратная, когда ответ нельзя получить и от разработчиков, так как они такого не пробовали делать или по другой причине (недавно читал подобный тред в сообществе Construct, где народ обсуждал парсинг текста).

Не помню, что за прототип, но на Unity ;)

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

У нас нет нехватки идей, мы не умеем довести до конца начатое

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

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

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

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

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

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

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

Мы. Не идеальны и все так делали, и будем продолжать делать, в надежде накопить идей про запас или использовать их в связке с текущими core features. Но в один момент необходимо остановится и посмотреть на свой проект, посмотреть, сколько еще не доделано и сколько не работает так, как мы задумали в самом начале. И принять решение, что же делать дальше - генерировать тонны ненужных и не важных в данный момент идей или же доделать проект. Каждый решает сам для себя.

Хороший Продюсер

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

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

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

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

О чувстве собственной важности

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

Существует такое понятие как эффект Даннинга-Крюгера, который определяет следующие вещи, довольно сильно характеризирующие появление у нас ощущения "чувства собственной важности"

Эффект Даннинга — Крюгера — когнитивное искажение, которое заключается в том, что люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации^[1]. Это приводит к возникновению у них завышенных представлений о собственных способностях, в то время как действительно высококвалифицированные люди, наоборот, склонны занижать свои способности и страдать недостаточной уверенностью в своих силах, считая других более компетентными. Таким образом, менее компетентные люди в целом имеют более высокое мнение о собственных способностях, чем это свойственно людям компетентным, которые к тому же склонны предполагать, что окружающие оценивают их способности так же низко, как и они сами.

Подробнее на википедии.

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

Зачастую самый высокий уровень ЧСВ попадается у дизайнеров, так как удивительным образом наши дизайнеры без имени ведут себя на порядок хуже, чем люди с именем и 10-20 годами опыта в индустрии  из EU/USA (тут мы не берем в пример Клифа, так как у него это публичный образ, который играет ему на руку, прим. редактора).

Проблема с завышенным ЧСВ выявляется у дизайнеров на собеседованиях одним простым вопросом "Вы знаете, чем занимается наша студия?" - в ответ на который человек с завышенным ЧСВ чаще всего отвечает довольно шаблонно. Точнее, двумя путями:

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

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

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

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

Разработчики не играют в игры и немного о собеседованиях

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

Это я к тому, что с людьми, которые делают игры, но при этом в эти самые игры не играют, довольно тяжело работать. И особенно сложно объяснять, что ты хочешь получить на выходе, так как приводя в пример проекты, не получаешь никакого фидбека, человек просто не понимает, о чем ему говорят.

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

В ходе каждого собеседования у нас есть два обязательных вопроса:

• в какие игры играете ? - тут подразумевается платформа, жанр, направление
• назовите 3 запомнившиеся игры за последний год ?  

И тут начинается самое веселое - люди не играют, либо играют в одну игру на протяжении долгого времени (зачастую это WoW или EVE Online, или другая ММО). Оба варианта плохие и я объясню почему.

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

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

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

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

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