Как уже было сказано, терминология немного гуляет по индустрии, и конкретная должность может вмещать в себя даже достаточно неочевидные роли. При этом и сами роли иногда трактуются самым экзотическим образом. Но основу нужно знать и не путаться. И – если вы ищете специалиста – понимать, что вы вообще от него хотите (вы удивитесь, но многие представляют это достаточно смутно). Набор скиллов у человека может быть разным, но стоит понимать какие-то, казалось бы, очевидные вещи. Например, что продюсер всегда кое-что смыслит в геймдизайне, что не очень рационально требовать от левел-дизайнера умения составлять питчи проекта, а от геймдизайнера – опыта работы комьюнити-менеджером. Этот слегка шизофренический ряд звучит как шутка, но каждый из примеров – реальный случай.
Кроме того, старайтесь использовать терминологию корректно и не лепить детских ошибок. И вообще, перечитывайте, что написали. Не размещайте вакансию «гей-дизайнера», если не хотите получить вот прямо гей-дизайнера – ну или глуповатые улыбки. (Да, это тоже реальный пример, а не просто избитая шутка, построенная на созвучии двух слов.) Это же касается не только ролей/должностей, но и специализированной лексики вообще. Она не такая сложная, ее можно освоить. Нельзя писать «фит бэк» вместо «фидбек», нельзя называть моделлеров «модельерами», не нужно называть сеттинг «сейтингом». Этим вы отпугнете людей и сообщите, что у вас проблемы с использованием сложившейся терминологии (т. е. у вас мало опыта), у вас не очень хорошо с грамотностью, вы небрежны и у вас плохо с английским.
Не стоит недооценивать этот момент и сваливать все на «и так поймут». Да, поймут (см. выше). И, вероятно, разорвут коммуникации. Если человек из банковской сферы будет в переписке оперировать терминами «кридит», «ре-фенансированье» и «каш баг», с ним тоже перестанут разговаривать. По очевидным причинам.
Резюмируя главу
Подводя итоги главы, исходя из представленных данных, алгоритм примерно понятен. Автор и команда разработчиков проекта могут успешно использовать его на уровне идеи и изначального понимания картинки запланированной игры.
Несколько раз на протяжении этой главы мы также проговаривали, что решение о том, что за игру вы разрабатываете, – это примерно половина данных для планирования. И, вероятно, у пытливого читателя возник вопрос, какой же второй фактор, влияющий на этот процесс.
Это не то, что вы собрались разрабатывать, а как именно вы собрались это делать. Об этом наша следующая глава, посвященная типу компании, которую вы собрались построить вокруг разработки игры.
1.3. Кем вы хотите быть?
Большинство начинающих разработчиков склонны недооценивать фактор типа компании, которую они хотели бы построить в долгосрочной перспективе, концентрируясь вокруг продукта и стартовой команды. Это может показаться разумным на начальных этапах, однако недостаток планирования в этом поле запросто может в ближайшей перспективе, как говорят наши американские друзья, выстрелить им в ногу.
Причин тут несколько, но основная заключается в том, что, если отпускать развитие компании на самотек, концепция будет формироваться «как придется». И на момент открытия юридического лица это будет делаться исходя из сугубо внешних факторов. Что практически всегда не на руку разработчику.
Результаты такого отношения – спешка и ошибки в момент предстоящего подписания сотрудничества с партнером, фрустрация и потеря мотивации основателями компании (игра вроде та, но хотелось семейного дружественного коллектива, а приходится масштабировать команду на десятки человек или, наоборот, хотелось крутую компанию, а мы не растем). И, что самое основное, – отсутствие правильного целеполагания в таком важном вопросе, как развитие занимающего ощутимую часть жизни занятия.
Составить классификацию типов компаний-разработчиков в индустрии достаточно сложно (они в основном складываются как гибриды разной деятельности, особенно в первые несколько лет), но в рамках вопроса о дальнейшей мотивации и последующего планирования хотелось бы выделить следующие четыре типа.
1. Хобби-разработка.
2. Индустриально-ориентированная продуктовая разработка.
3. Бизнес-ориентированная продуктовая разработка.
4. Это отдельный тип компаний (вне основного списка) – сервисно-ориентированный бизнес, связанный с разработкой полного цикла. Он не лежит в фокусе нашей темы, но его невозможно обойти и не обсудить хотя бы вкратце.
Давайте разберем каждый тип в деталях, при этом ориентируясь на данные из предыдущей главы.
Хобби-разработка
Иными словами, изначально некоммерчески ориентированная разработка игр (которая может потом вдруг как-то бурно коммерциализироваться), когда людям просто в удовольствие. Кому-то нравится писать рассказы у себя в Facebook, кто-то любит наигрывать на пианино, кто-то рисует натюрморт, чтобы успокаивать нервы. А кто-то вот любит поделать игры. Или годами разрабатывать одну и ту же игру, и людям от этого тепло и хорошо.