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

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

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

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

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

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

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

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

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

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

Indie way #3 - Games Jamm's

Последних несколько месяцев не было совсем времени, чтобы писать в блог, да и не было о чем говорить. Но пост об участии в games jamm's и пользе от них созрел давно, и самое время в преддверии нового Ludum Dare поделиться своими мыслями.

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

Следующий раз, уже два года назад, мы собрались командой в три человека и участвовали в Ludum Dare, с игрой в стиле The Sting!. Это был командный зачет, у нас было 72 часа, за которые мы не сделали толком ничего, так как уперлись в проблему планирования времени.

В последнем Ludum Dare я участвовал лишь для того, чтобы проверить возможность концепции, и я ее удачно проверил, не выложив игру, но так родилась Isles Of Umbra, правда, тогда в совсем текстовом режиме, но это дало возможность поверить в свои силы и начать делать этот проект.

Последним джемом, в котором я участвовал, стал Games Jam: Kanobu, благодаря которому проект получил публичность. Мы приняли участие в двух этапах - игровой концепт и концепт арт. По итогу, хоть мы и ничего не выиграли, но собрали команду и сейчас делаем проект во всю, с желанием его закончить по IGF.

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

Но давайте теперь поговорим о том, что же нам дает джем:

• Proof of concept - да, большинство джемов имеют установленную тему, но никто не мешает придумать игру под нее, проверить ее на жюри и игроках, которые будут оценивать и по итогу уже сделать выводы. На эту проверку не уйдет много времени и вы сделаете необходимый минимум, так как сроки очень сжатые.
• Планирование времени - работая над игрой, похожей на The Sting!, нашим главным врагом было время. Мы слишком долго думали над тем, какую концепцию выбрать под тему, решили писать свой движок вместо того, чтобы взять готовое решение, плюс усталость, которая с каждым часом нас тормозила, так как мы жестко рашили. Но, выявив проблемы, с ними не сложно бороться - брать готовые технологии, в которых есть разбираешься, ставить временные рамки на каждую часть работы, если выходим за них - упрощать и урезать. Проверкой для меня станет новый Ludum Dare(25-28 апреля) где я буду с новой командой.
• Публичность - вы привлекаете к себе внимание, даже простые посты в блоге процесса разработки Ludum Dare могут вызвать бурное обсуждение в комментариях, а это уже хороший старт для дальнейшего развития проекта.
• Команда - благодаря Games Jam: Kanobu нам удалось собрать отличную команду. Не принимай мы там участия - мы бы еще долго искали художника и людей, готовых нам помогать, или даже просто ретвитить и шейрить сообщения о статусах разработки.
• Работа с ограничениями - бытует мнение, что ограничения - это плохо. Но на самом деле ограничения есть во всем, на протяжении всего девелопмента, и они стимулируют к лучшим решениям, чем безграничные ресурсы.

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

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 ;)

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

Быть Джеком

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

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

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

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

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

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

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

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

Очень тихий Team Meat. Хороший пример команды, которая делает каждый раз проекты все лучше, и историей, которая получила финал. Информационный повод у них создают сами проекты, так как проекты делают вызов сами.

• у них была история ребят со своими проблемами, которые надеялись за счет своей игры решить эти проблемы. История хорошо показана в Indie Game The Movie
• решение проблем наступило с продажами SMB, история с очень хорошим концом. 
• выход The Binding of Isaac
• наброс в сторону Nintendo по поводу работы с ними, если Meat Boy будет добавлен в Smash Bros

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

Недоступный Джонатан Блоу. Мое отношение к данному персонажу очень неоднозначное, мне не нравится Braid, я не люблю слушать его лекции, и я не верю в The Witnes.

• создал образ, опять таки посмотрите IGTM
• довольно много и часто выступал, рассказывая о высоких материях и вдохновляя молодые умы делать игры
• укрепил свой образ созданием Indie Fund и условием получения инвестирования от них

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

Мастер на все руки Маркус Перссон. Я не могу сказать, насколько хорошо он пишет код, но он однозначно гениальный маркетолог.

• его история не была интересна прессе, так как еще не пришла гигантская волна моды на инди
• его проект создал его образ
• его твиттер читает 1,432,535
• он всегда все делает в нужный момент

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

Неизвестный Рами Исмаил. До прошлогоднего Mojam я никогда раньше не слышал о
Vlambeer, да и по самому стриму они были похожи на студентов, чем на сириоус бизнес. Но с выходом Ridiculous Fishing у них появилась история.

• участие в Mojam 
• история разработки Ridiculous Fishing построена на плохих пиратах, которые как ни пытались, но все равно не смогли сломать разработчиков. И на удивление, эта история выстрелила, хотя пираты достают всех.
• сертификация под XBONE

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

Антипример. Для полноты картины не хватает антипримера хорошего и целостного само пиара. И тут нам на помощь приходят старики индустрии Брайан Фарго, Уорен Спектор, Питер Молинье и, конечно же, Тим Шейфер. Эта дружная компания не вызывает к себе никакого доверия, но манипулирует аудиторией в виде простого меседжа "мы бедные и несчастные, нас не любят издатели". Этот образ побитой собаки вызывает сожаление аудитории и постоянные разговоры. Это позволило парням собирать деньги на kickstarter, а образ настолько крепкий, что никто не задается вопросом "а может, издатели их не любят, потому что проекты говно?"

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

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

Сообщество

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

Мы негативисты, считающие что все по дефолту плохо и может стать еще хуже. С одной стороны это хорошее качество, так как мы всегда готовимся к худшему и просчитываем самые плохие варианты наперед, даже если они с нами не произойдут. Другая сторона этой черты - критика, которая палка с двумя концами. С одной стороны, мы критикуем работу и это хорошо, так как под действием критики будут внесены полезные изменения, с другой стороны, мы критикуем все, а особенно в интернете. Хуже RU/CIS только польские игроки, если не верите, поиграйте пару недель на польском сервере League of Legends и все станет на свои места.

Есть книга Rework (её написала компания 37 signals, делающая хорошие продукты), которую неокрепшие умы стартаперов возвели в статус культовой. В этой книге есть очень важная часть о работе с клиентом. Эту часть, как по мне, необходимо прочесть всем, кто пытается строить сообщество вокруг своего продукта. Она дает очень важное понимание того, что каждый человек на форуме, страничке в соц сети или вашем блоге, пишущий, как он чью трубу шатал, является клиентом или же потенциальным клиентом вашего продукта. В остальном же в книге много "ваш КО", но как показывает практика, к этим прописным истинам люди доходят, наступив на все возможные грабли по пути.

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

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

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

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

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

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

Зачастую эта проблема выглядит так:

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

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

У меня есть хороший пример прям из этих выходных и хорошего, но очень глючного мода к Arma 3 Breaking Point. Ситуация разворачивалась следующим образом - ребята выкатывают новый патч, который просто все время роняет серваки, за этим патчем выкатывается патч в инсталер, который ломает и его. Ребятам потребовалось ровно 5 минут, чтобы запостить солюшен в твиттер, который уже сарафанное радио разнесло по форуму и сами же игроки помогали другим игрокам решить эту проблему. Это хороший подход решения проблемы, если бы прошло больше времени - на форумах скопились бы сотни сообщений от недовольных игроков, которые пришли поиграть, а им не дают.

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

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

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

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

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

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

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

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

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

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

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

Изоляция

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

Что мы делаем. Каждый раз, когда в любой компании людей заходит разговор - кто чем занимается, возникает тот неловкий момент, когда довольно тяжело объяснить, что же ты делаешь, и что такое делать игры. Как показывает практика, для людей со стороны игры - это что-то на уровне забавы и не может быть серьезным, не говоря уже о том, что это серьезный бизнес. За последних 5 лет мы пытались примерно 5 или 6 раз открыть собственную студию, и только один раз нам это удалось. Со всеми с кем мы общались, и у кто был не профильным инвестором был лишь один ответ "Я в этом ничего не понимаю и не буду инвестировать". Многие готовы инвестировать в e-commerce, и только единицы в игры. С одной стороны это не плохо, так как остаются не профильные инвесторы, но с другой их не так много и количества денег не достаточно для всех, кто пытается что-то делать.

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

У нас нет громких выходов. Мы замкнуты сами в себе, мы обсуждаем новости и проблемы в замкнутой экосистеме, и даже если эти новости хорошие и про большие продажи или прибыли, они остаются на страницах профильной прессы. Мы устраиваем хакатоны, но они привлекают наблюдателей со стороны, это опять таки наше внутреннее соревнование, чтобы показать свой уровень и засветиться среди своих. У нас нет громких выходов, о которых бы говорили все, а не только профильная пресса. Последним таким была продажа доли Super Cell за $1,53B, до этого - выкуп Activision Blizzard у Vivendi, помните еще что-то?
Да, тут можно вспомнить крах THQ или успешных социальных и мобильных издателей, но это опять таки своя уютная тусовка.

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

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

В заложниках ситуаций

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

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

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

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

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

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

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

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

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

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

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

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

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

Борьба с ветряными мельницами

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

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

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

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

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

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

А я последних несколько лет замечаю другую ситуацию, когда люди приходят в компанию с горящими глазами, с рвением делают свою работу, а спустя 2-3 года садятся на стул, расслабляются и перестают перформить. Хотя казалось бы, что вылететь и оказаться за бортом индустрии на 3-5 лет довольно легко, но это не пугает людей. И на само деле людям ничего не мешает  изучать что-то новое, пытаться себя как-то развивать, учитывая, что все есть в свободном доступе, а рядом есть коллеги, которые могут помочь. Складывается впечатление, что проработав долгое время на одном месте,  все пытаются свить себе теплое местечко там, забив на все остальное. Но не стоит забывать, что чем сильнее увлекаешься cover my ass development'ом, тем холоднее это место становится. Наша индустрия не постоянна, в ней происходят переменный каждый год, и если не пересматривать свои знания и умения, далеко в ней не убежать.

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

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

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

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

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

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

Вертикальные связи, нетворинг и суровая реальность

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

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

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

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

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

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

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

У меня за последний месяц было два насущных вопроса, один уже отпал, так как я нашел ответы на него сам, так как я не смог найти людей из CIS, которые подавались на IGF и могли бы мне прояснить ряд вопросов про early build. Но ответы я нашел сам и мы решили не гнаться в этом году за IGF, так как мы просто не успеем, и слишком поздно за это взялись.

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

Второй вопрос который меня волнует, это площадки, на которых стоит сконцентрироваться для освещения проекта, так как мы планируем скорый анонс, то этот вопрос с каждым днем волнует меня все сильнее.

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

Такие дела.

Out of Scope

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

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

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

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

Но к чему я это веду, это же состояние Out of Scope постоянно случается во время разработки и избавится от него довольно тяжело, если его запустить, но даже в запущенном состоянии это реально.

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

Основные причины, которые приводят к выходу за рамки scope:

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

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

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

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

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

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

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

проблема "говорить"

В этом коротком видео всего за 3 минуты Марк Риттенберг объясняет основную проблему менеджмента в RU/CIS, которая состоит в отсутствии умения налаживать коммуникации. Я думаю, что эта проблема свойственна не только нашему региону, но и EU/USA, возможно, в меньшей форме.

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

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

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

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

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

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

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

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

Нужно помнить, что в конце страдает не тот, кто мало работал, а тот, кто молчал и много работал.

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

3 мысли из лекции Никиты Буянова

Думаю, что не я один не подозревал, что существует компания AbsolutSoft, которая сделала и продолжает работу над Contract Wars. По ссылке можно найти первую часть выступления
Никиты Буянова, арт-директора в выше упомянутой компании, который рассказывает нам о выпуске проектов для midcore аудитории.

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

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

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

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

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

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

Мысль 2: Не знание технологии
Сейчас много всего лежит прям перед нами - Unity, UDK, Game Maker, бери и используй. Порог вхождения в индустрию максимально низкий, но любая готовая технология не гарантирует нам успеха или 100 процентного завершения проекта.

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

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

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

Технология легко может похоронить ваш проект.

Мысль 3: выход за рамки ТЗ
Все в команде знают как сделать лучше, и это хорошо. Но у этой медали есть и вторая сторона, когда желание сделать лучше превращает фичу A в фичу В, потому что все пытались сделать лучше, а сделали совсем другое, а проекту без фичи А не жить никак.

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

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

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

А еще сходите и почитайте пост о времени у Сергея Климов в блоге.

Документация устаревает в момент ее написания

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

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

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

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

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

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

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

• пишется one page document или же pitch, который отвечает на основные вопросы и на основе которого принимается решение о том, будет ли делаться проект;
• на основе питча пишется расширенная концепция, которая покрывает вопросы об основных механиках, которые мы будем использовать;
• после этого весь проект разбивается на промежуточные этапы для реализации этих механик;
• на основе этого создается дальнейшая документация, которая покрывает конкретно и детально те фичи, которые мы будем реализовывать на ближайшем промежутке.

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

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

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

Что мы имеем в сухом остатке:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На фоне вот этой статьи на 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. Нельзя делать пазлы, идущие против логики игры, сюжета игры и здравого смысла - это опять таки касается первого пункта, когда мы храним общий вижн и не даем выходить за его рамки и соблюдаем целостность проекта, таких ситуаций быть не должно.

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

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