Игра как бизнес. От мечты до релиза

Text
12
Reviews
Read preview
Mark as finished
How to read the book after purchase
Don't have time to read books?
Listen to sample
Игра как бизнес. От мечты до релиза
Игра как бизнес. От мечты до релиза
− 20%
Get 20% off on e-books and audio books
Buy the set for $ 10,83 $ 8,66
Игра как бизнес. От мечты до релиза
Audio
Игра как бизнес. От мечты до релиза
Audiobook
Is reading Виктор Маренин
$ 5,75
Synchronized with text
Details
Font:Smaller АаLarger Aa

Регистрация торговых марок

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

Вот почему.

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

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

› В продолжение предыдущего пункта – подойдите к вопросу ответственно, прогоните названия через Google, посмотрите, какие сайты зарегистрированы. Если требуется – почитайте Википедию. С конкретным продуктом бывает по-разному, но в большинстве случаев бренд компании не должен быть идиотским и/или банальным. Тут даже речь не о том, что ваши торговые марки обязаны быть какими-то невероятно искрометными. Просто – для начала – если вы плохо владеете английским (а бренд у вас почти наверняка будет англоязычным), то дайте свои идеи кому-то на проверку. Не стоит называть компанию «Дверь» или «Фонарный столб» (но по-английски) – это глупо. Не стоит называть ее «Фарт» или «Сакс» – это не только безумие и вас не поймут, но такие компании уже существуют (или существовали), специализируясь на перепродаже детских игрушек из Китая в Россию (т. е. это сейчас не с потолка пример был, truth is stranger than fiction). Если регистратор компаний предлагает вам готовое юрлицо с названием Molestica (тоже реальная история из практики), вам это не нужно, от вас любой контрагент сбежит в ужасе на стадии подписания даже самого базового документа.

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

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

Другой распорядок жизни

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

Основные моменты здесь такие.

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

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

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

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

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

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

Хозяйственная деятельность

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

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

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

› По поводу технического оснащения у меня есть один из самых древних советов в индустрии. Даже если вы начинаете работать на технике, которую по сусекам насобирала команда, собирайте компьютеры самостоятельно, исходя из задач проекта, когда появится такая возможность. Мало того, что это все-таки выгоднее (потому что собранные в магазине конфигурации создаются с другими целями и, в том числе, там идет наценка). А когда вы собираете железо руками, держа в голове кучу технических ограничений и особенностей игры, вы дотошно оптимизируете один из важных аспектов разработки. Если у вас есть возможность со старта привлекать админа или девопса[18], и он часть команды, – вообще отлично.

 

› Продумайте, как вы хотите, чтобы функционировал ваш офис перед тем, как что-то арендовать. Это звучит очевидно, но вы не хотите, к примеру, делать свободный график, в котором у вас программист работает по ночам, а днем его вообще никто никогда не видел и, возможно, он и не человек вовсе. А помещение при этом вы себе решили снять в торговом центре, у которого есть фиксированные часы работы. Или же вы изначально планируете много встреч, посещение офиса сторонними лицами и большое количество видеозвонков. И, наверное, лучше бы ваш офис соответствовал определенным презентационным стандартам. Удобно ли туда будет добираться ежедневно вашей постоянно пополняющейся команде? Можно ли там где-то курить (автор при этом не поощряет эту вредную привычку, но осознает, что многие сознательно ее выбирают) или нужно будет каждый раз выходить за пределы, установленные арендатором? Есть ли доступ к местам общепита? Парковки? И еще множество вопросов удобства и осознания того факта, что ваш офис должен отвечать запросам команды проекта. Позже, кстати, вопрос стандартов может быть поставлен любым серьезным издателем и партнером. Поэтому также уточняйте по поводу возможности – как арендатора – вносить изменения в офис (например, возможность вводить отдельные телефонные линии, устанавливать свои замки внутри и так далее).

› Сразу же ставьте перед собой вопрос базовой безопасности информации в офисе, потому что даже если вы считаете, что это все чепуха, ваши потенциальные партнеры так считать не будут. Я про всякие USB/DVD-Burners и так далее. На физическом уровне – это «у кого будут ключи от офиса», имеется ли система сигнализации, кто получит доступ к паролям и так далее.

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

Организация разработки

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

› Среда разработки, собственно, IDE[19]. Скорее всего, в вашем случае это будет Windows и, говоря о программной среде, то, что вы для себя выберете исходя из задач и позиционирования проекта. Скажем, если это С++, то будет Visual Studio. Вообще на вашем проекте должен быть главный программист, технический директор или – не важно, как его называть, – человек, отвечающий за этот вопрос и технологический стек (возможно, это вы).

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

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

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

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

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

Лицензирование технологий и инструментов

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

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

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

› Знайте свои пакеты и здраво оценивайте необходимости и возможности. Очень часто руки разработчиков тянутся либо в сторону «мне нужны все пакеты PRO, чтобы потом два раза не вставать», либо наоборот: «возьмем всего по минимуму, потом разберемся». Если у вас со старта есть понимание и возможность оценить, какой конкретно функционал вам нужен, выбирайте то, что вам потребуется. Ну, условно говоря, вам всем зачастую нужен самый обычный Windows, а дорогие пакеты лучше считать, во-первых, именно в том количестве, которое вам необходимо по плану, а, во-вторых, в том объеме функционала, который вам нужен для проекта. В первую очередь я здесь говорю о дорогих графических решениях. Также не пренебрегайте студенческими предложениями, особенно на первых порах. Они обычно дешевые и доступные, но при этом могут прослужить вам достаточно долго до момента коммерциализации.

› Оглядывайтесь на рынок (в самом широком смысле): от локального рынка труда – чтобы понять, специалисты в каком конкретно графическом пакете или движке вам доступны на данный момент, до глобального рынка, по которому можно определить, какой лучше выбрать движок в конкретном жанре и на какие конкретные платформы. Повторюсь, оглядывайтесь: не нужно тренды делать причиной основополагающих решений. Для вас это все-таки продукт. Команда и план развития студии – в первую очередь, но рынок дает подсказки, и игнорировать их глупо. К примеру, если у вас под боком школа специалистов в Maya и главный моделлер работает на этом софте, странно было бы покупать пять пакетов 3ds Max, даже если они сейчас дешевле. Или если вы собрались портировать игру на современные консоли, скорее всего, Unity – это опрометчивый выбор.

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

Готовность к внешней деятельности

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

Здесь мы говорим о следующих вещах.

› В первую очередь, английский язык. Он должен у вас быть, и он должен быть хорошим. Вам не нужно какое-то специальное образование. Возможно, вы не слишком отличаете Present Perfect от Present Past Perfect. Но на уровне «поддержать разговор», что-то там пошутить, понять собеседника – вы обязаны это уметь. Я всегда говорил и повторю тут еще раз: хороший базовый язык нагоняется практикой. Если вы даже не светоч лингвистики, но пару лет плотно устно и письменно общаетесь – вы молодец. Если у вас нет этого уровня и вы не готовы делегировать внешние функции, начинайте учиться. Обходных вариантов тут нет. Без языка или кого-то, кто умеет общаться на английском, вы вычеркиваете для себя 90 % рынка.

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

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

 

› Последний, но не менее важный момент: позволяет ли здоровье активно путешествовать, переживать джетлаги, презентабельно выглядеть и проводить достаточно плотные четыре-пять дней на мероприятии (возможно на нескольких, которые следуют одно за другим). Опять же, тут нет ничего страшного, если не позволяет. Автор, к примеру, последние пару лет активно избегает посещения двух выставок подряд, потому что эффективность на второй чудовищно провисает (и планирует график, исходя, в том числе, из этого).

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

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

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

18Подразумевается DevOps (development и operations) инженер, который работает на стыке двух должностей – программист и системный администратор. – Прим. ред.
19Интегрированная среда разработки – Integrated Development Environment. – Прим. ред.
You have finished the free preview. Would you like to read more?