vk.com



Тема №984

Avatar 80x80не в сети

Продюсирование: правила игры

автор: 404mif  .  Птн, 20 Июл 2012, 14:22  .  комментарии: 0

Андрей Грищенко
Продюсер игровых проектов (внешняя разработка) фирмы "1С". Занимается поиском проектов и перспективных команд, организацией разработки и выпуска. В "1С" отвечал и отвечает за несколько десятков проектов, среди которых "Сталинград", "Полный привод: УАЗ 4Х4", "You Are Empty"; серия "Братья Пилоты" и "XIII Век", "Не время для драконов", "Анабиоз" и другие.
Алексей Пациорковский
Продюсер фирмы "1С". Проекты: "Магия Крови", "Кодекс Войны", "Дальнобойщики: Транспортная компания", "Волкодав", "7.62", "Диверсанты" и другие.


В этой статье авторы попытаются осветить следующие темы:
• Кто он такой - продюсер?
• Зачем он нужен?
• В чем его сила?
• Каковы слабые места продюсера?
• Правила игры
• Выводы
Итак, начнем!
Кто он такой - продюсер?
Вот он! (см. рисунок)

http://videoforum.com.ua/get/file=1457_93e63007db8de0cf9754
Образ продюсера издателя
В центре вы можете увидеть символическое изображение денег. Мы хотели поместить туда "рубль", но у него все еще нет своего знака, и мы поместили в тело продюсера "евро". Еще в прошлом году мы, возможно, выбрали бы "доллар".
В верхней части рисунка вы можете обнаружить инструменты работы продюсера. В правой руке находится молния, символизирующая контрольные функции, делегируемые продюсеру издателем. В левой руке символ времени, указывающий на важность сроков в работе продюсера. На открытом лице продюсера улыбка, символизирующая развитые навыки в сфере человеческого общения и дружеские отношения с разработчиками. Продюсер смело смотрит на свою работу через призму процентов.
В нижней части рисунка хорошо видны ярко-выраженные мужские половые признаки. Продюсер все еще мужская работа. Женщины-продюсеры - большая редкость, но нам хотелось бы надеяться, что эта ситуация изменится.
Классификация видов
Продюсеры бывают разные, смотря как их классифицировать:
• По месту работы: продюсер у издателя или у разработчика (линейный продюсер).
• По уровню ответственности и кругу обязанностей: исполнительные, генеральные и ассистирующие - в больших проектах.
• По охвату тем: общие и специализирующиеся (продюсер по дизайну, продюсер по технологии и т.д.).
Уже более года в продюсерском отделе "1С" наряду с общими продюсерами работают продюсеры по дизайну - Дмитрий Ножнин и Дмитрий Воронов, а также продюсер по технологиям - Дмитрий Долгов. Нам кажется, что практика использования специализирующихся продюсеров в нашем случае оказалась очень успешной.

http://videoforum.com.ua/get/file=1457_4710b29a950e32afdbda

Продюсер или менеджер проекта?
Однозначного ответа нет - это зависит от структуры именно вашего проекта, в первую очередь, от его размера и общей оргструктуры организации. В одних случаях менеджер проекта координирует работу продюсеров, в других - наоборот.
Некоторые считают, что продюсер отличатся от менеджера проекта так же, как арт-директор от ведущего художника - первые занимаются общими вопросами, задают курс; вторые - ежедневными обязанностями по постановке и контролю исполнения задач.
Для дальнейших целей будем считать продюсером сотрудника издателя, ответственного за своевременную разработку в оговоренных рамках бюджета продукта заданного качества.
Зачем он нужен?
1. Данность: издатель вкладывает средства и назначает человека, который будет следить за результатами освоения этих средств
Обратите внимание - не за расходованием средств (это задача бухгалтерии), а как каждый доллар/рубль превращается в результат. Поэтому неэффективное производство с частыми переделками, за которые честно платится честная зарплата, с точки зрения продюсера - нецелевое расходование средств.
2. Точка взаимодействия с машиной издателя и внешними сторонами - центр информации по проекту
Разработка некоторых продуктов может включать десятки (!) сторон-участников, среди которых разработчик - всего одна, хотя и важнейшая, сторона. Бывают еще лицензиары вселенной, названия, перосонажей; модели-звезды, лицензирующие использование своего образа и/или голоса; лицензиары технологий - движков и библиотек; аутсорсеры, релкамные агенства-партнеры и прочая, прочая, прочая.
Именно продюсер то лицо, через которое все эти стороны взаимодействуют и обмениваются информацией.
3. Профессионал, который может разделить с вами ответственность
Продюсер - это профессионал, с которым можно и нужно советоваться. И человек, с которым есть смысл разделить ответственность за принимаемые по проекту решения.
Основание для этого - опыт продюсера в производстве и выпуске продуктов и этот опыт может измеряться десятками выпущенных проектов. Пока разработчик создает год-два замечательную игру, продюсер у издателя обычно успевает отправить на завод с десяток других хороших игр.
А это значит, что у продюсера накапливается опыт прохождения альф/бет, организации тестирования, подготовки продукта к выпуску, подготовку упаковок и послепродажной поддержки, а также другие связанные с этими вопросами знания, затруднения, подводные камни и оптимальные пути.
4. Зеркало аудитории и рынка, взгляд снаружи
Продюсер обычно единственное лицо в проекте, кто не сделал в нем ничего "материального" - не рисовал текстуру, не писал строчки кода и не создавал скриптов. В этом смысле у него есть основное преимущество - отстраненность, способность критиковать, смотреть снаружи глазами будущего потребителя.
5. Неблагодарная работа - искать проблемы
Поверьте, это не очень приятно, но кто-то должен перебирать "белье" проекта и искать в нем вещи, требующие стирки.
Задача продюсера также и хвалить. Но то, что вы, может быть, редко слышите похвалу от своего продюсера, следствие той его позиции, что хорошо сделанная работа - это норма и долг любого нормального человека.
6. И другие…
Кроме того, обязанности продюсера обычно еще более широки, так как включают в себя взаимодействия с внутренними службами издателя (а чем он больше, тем и служб этих больше) и другими внешними сторонами, например, лицензиарами.
В чем его сила?
1. Представляет "издательскую машину" в отношениях с разработчиками

http://videoforum.com.ua/get/file=1457_a2b7592b4ecbb23ec431

Продюсер находится между разработчиками и "машиной издателя". Он является сотрудником издателя и проводником воли издателя для разработчика. Обычно деятельность продюсера скрывает от разработчика детали функционирования "машины издателя", и разработчик получает информацию от продюсера уже в отфильтрованном, сгруппированном и более удобном для восприятия виде. Фактически, продюсер занимается "переводом" с языка издателя на язык разработчиков.
Кроме того, он имеет полномочия контролировать результаты работы в интересах издателя. И настаивать на изменениях в том случае, если результаты не соответствуют ожиданиям издателя. Очень часто то, что кажется дискуссией с продюсером, на деле является попыткой продюсера проводить линию издателя, которую он предварительно обсудил внутри "машины издателя" с ответственными лицам. Вполне возможно, что продюсер сам лично не согласен с предлагаемыми издателем мерами или решениями, но он все равно должен отстаивать позицию издателя, а не свою личную. Представьте себе, что вам приходится отстаивать часами точку зрения, с которой вы лично не согласны, в ситуации, когда оппонент старается задеть вас лично или пытается надавить на вас. Продюсеру очень непросто сохранять симпатию и хорошее отношение к разработчику в таких сложных ситуациях.
2. Представляет разработчиков внутри "издательской машины"
Продюсер является представителем разработчика внутри "издательской машины". На совещаниях именно этот человек может сказать позитивные или негативные слова о разработчике или его проекте. Скорее всего, именно этот человек, при условии, что ему нравится работать с разработчиком, будет стараться добыть для него следующий контракт с этим издателем. Если между разработчиком и продюсером установились прочные деловые отношения, никто внутри "машины издателя" не заинтересован в том, что бы у разработчика был более крупный, дорогой и значимый проект, больше, чем продюсер его текущего проекта.
Хорошие отношения с продюсером, обычно, ведут к тому, что у проекта будет более продуманная упаковка, более сильный план продвижения и т.д. Просто потому, что продюсер будет уделять этому проекту больше внимания и создавать ему более выгодный образ в глазах других сотрудников издателя - PR-менеджеров, сотрудников департаментов маркетинга и лицензирования и т.п.
3. "Вентиль" на источнике финансирования

http://videoforum.com.ua/get/file=1457_59dbe76827c12a461be3

Это весьма интересная сторона работы продюсера, как нам кажется. В настоящий момент мы используем поэтапные модели финансирования проектов. Издатель делегирует продюсеру функции контроля результатов работ и решение об оплате за этапы зависит от того, примет результаты работы по этапам продюсер или нет. Если результаты не соответствуют ожиданиям издателя, и разработчики не смогли договориться с продюсером на сроки и объемы доработок, то деньги получить, скорее всего, будет затруднительно.
4. Источник информации
Находясь внутри "машины издателя", продюсер является ценным источником информации для разработчика. Информация буквально стекается к продюсеру со всех сторон - он находится в тесном контакте с другими продюсерами, другими разработчиками и просто с большим количеством людей. Есть смысл налаживать с продюсером такие отношения, в которых ему было бы полезно и интересно делиться этой информацией.
5. Носитель опыта
Пока разработчик работает на одном проекте, продюсер, обычно, успевает поработать на 5-7 проектах. Продюсер набирает очень быстро весьма разнообразный опыт, относящийся к разработке и выпуску продуктов. Работая с разными командами на разнотипных проектах, продюсер быстро набирает базу знаний о практике и прецедентах в разработке и издании продуктов. Большая часть проблем уже возникала у кого-то ранее, спросите совет у продюсера и, скорее всего, он сможет вам рассказать, что уже пробовали предпринимать в подобных ситуациях, и какие были результаты.
6. Ваш первый игрок
Разработчики и тестеры, конечно, тоже играют в игру. Но продюсер обычно действительно первый игрок, достаточно посторонний процессу разработки. Скорее всего, он сам любит и знает компьютерные игры, его оценки результатов труда разработчиков - это первые оценки аудитории игры. Не игнорируйте их. Пока игру критикует только продюсер, еще можно исправить что-то серьезное, когда за дело возьмутся бета-тестеры и журналисты, то времени уже будет слишком мало.
Слабые места продюсера
1. Всего лишь человек, и ничто человеческое ему не чуждо
Ваш продюсер может устать (от вас?), он может что-то забыть, заболеть или чем-то расстроиться. Если он хороший продюсер, то он будет до последнего держаться, чтобы его личное состояние не сказалось на ваших отношениях и не повлияло на отношения разработчик-издатель. Но если вы будете его злить, будете ему грубить или вести с ним нечестную игру, то будьте уверены, что он отреагирует и как "шестеренка машины издателя", и как обычный человек. Старайтесь быть корректными в отношениях с продюсерами - это обычные люди.
2. Продюсер может попробовать сделать "свою" игру руками разработчиков
У продюсера есть обычные человеческие слабости, но есть и слабости, свойственные именно продюсерам. Например, продюсер может попытаться сделать "свою" игру руками разработчиков. Такое случается, это правда. Не так часто, как думают разработчики, но бывает.
Продюсер может оказаться лично заинтересованным в проекте настолько, что попробует сделать его таким, каким он нравится ему, а не разработчику или издателю. Он будет руководствоваться своими субъективными предпочтениями в этом случае и его аргументация, если она вообще будет, не покажется вам слишком убедительной. Он будет делать "игру своей мечты" чужими руками.
Это тяжелая ситуация. Можем только порекомендовать вежливо интересоваться у продюсера, почему он настаивает на том или ином решении. Если вы не можете понять его объяснений, то есть смысл интересоваться, кто является инициатором этого решения и с кем оно согласовано.
Возможно, вам стоит подумать о привлечении третьей стороны для решения спорного вопроса - другого продюсера, эксперта в предметной области и т.п. Но будьте готовы, что вы окажетесь не в выигрыше "по решению суда" - бывает и так, что продюсер прав, даже, если вы не понимаете его объяснений.
3. Продюсера можно ввести в заблуждение
Продюсера можно обмануть или запутать. По-маленькому или по-крупному. Можно успешно обманывать даже пару-тройку этапов подряд. Но в конце концов результат сам скажет за себя. Когда обман вскроется, "светлый образ" разработчика в глазах сотрудников издателя подвергнется серьезной атаке со стороны продюсера - он отреагирует и как обиженный человек, и как "шестеренка машины издателя". Он постарается донести до каждого, что этот разработчик вел нечестную игру с продюсером. Он постарается ужесточить меры контроля по сдаваемым материалам и замедлить платежи в сторону разработчика. Он постарается, чтобы у разработчика не было больше проектов с этим издателем, и сам постарается с ним больше не работать. Это не так уж и мало, это может нанести разработчику серьезный прямой ущерб, и точно нанесет большой косвенный.
4. У продюсера издателя много проектов
Обычно, слишком много. В "1С" - больше 10 одновременно. Не хватает времени делать все, что нужно, и точно в срок. Продюсер часто выходит из положения, распределяя внимание неравномерно между своими проектами. Если проект находится в стадии препродакшена, то он, конечно, не отнимает столько внимания, сколько проект перед релизом. Но когда приходится выбирать между проектами в сходных фазах разработки, продюсеры уделяют львиную долю внимания - Туш! - своим любимым проектам.
Если проект стал любимым для продюсера, то он всегда найдет для него время и будет уделять ему максимум внимания. Если проект стал нелюбимым, то он все будет получать по-минимуму и в последнюю очередь. Вот такой простой человеческий подход. Это слабость продюсера - у него есть те проекты и разработчики, которых он любит.
5. Продюсер не может сделать за разработчика игру
Продюсер не может сам сделать игру. Даже привлекая максимум средств и внимания к проекту. Даже вмешиваясь во внутренние процессы работы компании разработчика. Игру делает разработчик, продюсер - обеспечивает, контролирует, корректирует и помогает.
Если корабль разработчика отклонился от ожидаемого издателем курса, то продюсер может написать или позвонить ему и сообщить, что вектор движения корабля вызывает беспокойство у издателя. Продюсер может нанести визит на палубу корабля разработчика - проверить, на месте ли весла, не умерли ли гребцы, не используется ли рабский труд. Возможно, он даже пощупает пальцем штурвал. Но сам он "грести" или "рулить" не может - гребут, ставят паруса и рулят на корабле разработчики.
6. Знания широкие, но неглубокие
Продюсер может знать много разных вещей, но он не может на равных конкурировать с узкими специалистами в их предметных областях. В конце концов, ему не за это платят деньги! Если продюсер не демонстрирует глубины знаний в конкретной предметной области, то это не значит, что он не знает вообще ничего - не стоит попадаться в эту ловушку.
Стоит учитывать, что продюсеры обычно имеют большой опыт работы с разными командами на различных проектах. Значительная часть проблем уже возникала и была решена на других проектах, и на основе этого продюсер может давать неожиданные рекомендации в конкретной предметной области, просто используя опыт опробованных решений других проектов. Кроме того, продюсеры часто прибегают к помощи более узких специалистов и экспертов в разных предметных областях.
Таким образом, продюсер не сможет сделать "за" или "лучше" работу программиста, дизайнера или художника - он не обладает достаточной квалификацией и опытом. Все, что он может сделать - помочь специалисту сделать работу советом или привлечением эксперта.
Правила игры
Здесь хотелось бы заявить те правила игры, по которым играем мы и соблюдение которых очень хочется от разработчиков игр.
Правила игры - Часть 1. Коммуникации
Правило №1. "Говорите на одном языке"
Все начинается с того, какие мы используем коммуникации - внутри команды, с вашим продюсером. Заложенные в коммуникациях проблемы могут аукнуться годами разработки и перерасходами бюджетов.
Самые опасные термины те, относительно которых у вас есть твердая уверенность. Лучше уточнить, что продюсер подразумевает под "альфой", "дизайн документом" или "прототипом".
Например, продюсер под "играбельным прототипом" ожидает увидеть полнофункциональный уровень, в который можно играть и оценить геймплей, его динамику и баланс. Разработчик же, вполне естественно, может быть доволен наконец заработавшим движком с голой картой по которой бежит персонаж с временно прикрученными анимациями от другого проекта. Это проблема.
Правило следующее. "Соблюдаем интерфейсы"

http://videoforum.com.ua/get/file=1457_57eb6fd030f1431ec9f2


Как говорилось выше, продюсер - это центр информации. По нормальному проекту через продюсера проходят тысячи и десятки тысяч писем, многие из которых содержат важную для проекта информацию. Если такая информация не прошла через продюсера - это маленькая граната или большая бомба под проектом.
Поэтому у разработчика всегда должен быть 1 (один) человек, ответственный за взаимодействие с издателем - обычно, это менеджер проекта или линейный продюсер. Также обязательно должен быть человек, который умеет собирать и отправлять материалы. Это может быть тот же человек (менеджер), но может быть и другой, технический специалист. Главное при этом, чтобы продюсеру издателя не отправлялись скриншоты художником, патчи программистами, а дизайнерами - новые карты.
Нарушение коммуникаций - путь в хаос.
Правило следующее. "Критика для продюсера - его функциональная обязанность"
Да, воспринимать критику тяжело. Но, к сожалению, как уже много раз говорилось выше - задача продюсера критиковать результат, если его можно сделать лучше. Важно, чтобы критика и направлялась и воспринималась не касательно личностей, а была направлена на достижение лучшего результата.
"Если вы не договорились об исключениях - действуют правила"
Если вы знаете, что не сможете самостоятельно сделать перевод игры на английский - договоритесь об этом с издателем, иначе тот будет ждать от вас версии на хорошем английском языке и очень удивится переводу "how much watch?".
Если вы не успеваете достичь вовремя результатов этапа - договоритесь об исключении, иначе будут действовать прописанные в контракте правила.
"Придерживаемся элементарных правил ведения деловой переписки"
Более подробно с элементарными правилами деловой переписки можно ознакомится здесь, но в данной статье кратко упомянем основное:
• Если вы не в отпуске, не в командировке и т.д., на деловое письмо необходимо ответить в течении суток. Если нельзя решить за это время вопрос - ответьте сразу, что в течении такого-то срока сможете ответить.
• На любое письмо, в котором содержится какая-то просьба или поручение или другое необходимой от вас действие - ответьте минимум "Ок", "Договорились". Ведь отправитель никогда точно не уверен, получили ли вы письмо или оно ушло в спам.
• Пользуйтесь кнопкой Reply All - тогда в копиях письма останутся все нужные получатели, которых включил в копии отправитель.
• Будьте кратки, конкретны и меньше эмоций! Деловая переписка - не форум, чат или блог.
Правила игры - Часть 2. Предконтрактная
"Если вы ищете издателя, высылайте коммерческие предложения"
Минимальная информация, которая необходима для какого-либо рассмотрения проекта:
• жанр и сеттинг
• основные особенности и отличия
• технология
• кто его будет делать (резюме команды, а не набор резюме ее членов!)
• за какие деньги и в какой срок (план, бюджет)
• как это будет выглядеть (скриншоты, скетчи).
И проявите терпение. Дайте издателю пару недель на просмотр ваших материалов и подготовку ответов. Худший ответ типа "Спасибо, это не интересно" можно получить сразу, а вот что-то более перспективное требует времени, согласований и пр.
Хотя, если продюсер издателя не прислал за неделю-две ни одного вопроса или уточнения - стоит, пожалуй, вежливо поинтересоваться - нет ли еще новостей по вашему предложению.
Правила игры - Часть 3. Разработка
"Мы так НЕ работаем: сначала движок и арт, потом - дизайн"
Не сильно вдаваясь в подробности, хотелось бы только подчеркнуть, что сейчас разработка игр - очень дорогое мероприятие по созданию развлекательного продукта, который должен найти себе место на рынке в условиях сильной конкуренции.
Чтобы это дорогое мероприятие окупилось, разработка должна быть построения "от целей": сначала маркетинг и финансовый план, потом - дизайн, из него - что для его реализации надо (движок, арт).
"Продукт должен быть лицензионно чист"
Это более чем очевидно, но не забудьте, что
• BINK Video платный для использования в коммерческих проектах;
• DivX тоже платный;
• и FMOD требует некоторых денег.
Также внимательно читайте "license.txt" тех технологий, которые вы используете в проектах. Не забывайте указывать копирайты, которые требуют их лицензионные соглашения - некоторые из них могут требовать даже размещения логотипа на упаковке игры. Вряд ли ваш издатель будет рад неожиданно узнать такую новость.
Из видео-кодеков можно безнаказанно использовать Windows Media 9 (WMV).
"Preproduction заканчивается, когда есть играбельный прототип и план на разработку всей игры"
Что такое препродакшен? "Подготовительный этап…" Это очень опасное определение! В таком определении нет границ, не понятно. Что такое "подготовка" и чем она должна заканчиваться.
Предлагается считать за правило, Preproduction - это подготовительный этап, во время которого проводится определение границ проекта, уточнение технологии, постановка стиля, поиск и подготовка кадров команды, который заканчивается играбельным прототипом и планом на разработку всей игры.
"Этап - это не самоцель, а средство измерения"
Конечно, если платежи "привязаны" к этапам, то для небольшой команды, которая работает над одним проектом, любая задержка этапа означает финансовые проблемы. Тем не менее, поэтапное финансирование - это неизбежное следствие необходимости компенсации рисков, которые несет издатель, давай сотни тысяч долларов (!) команде, которая обещает (!) через столько-то месяцев сделать игру.
"Фичекат и фичекрип - функциональная обязанность продюсера"
"Фичекат" и "фичекрип" - инструменты для корректировки объема проекта, позволяющие приблизить его к ожиданиям издателей, уложить в приемлемые сроки и выделенные ресурсы. Не стесняйтесь спрашивать продюсера, какие выгоды проекту принесет предлагаемое удаление или добавление каких-то элементов. Если он не может или отказывается аргументировать свои предложения, то, возможно, он использует эти инструменты не по назначению в своих интересах.
Правила игры - Часть 4. Релизная
"При тестирование должна использоваться система bug-tracking: никаких XLS, e-mail, ICQ"
Речь идет о стадиях проекта, на которых результаты работ по этапу уже включают полнофункциональные работающие версии игры. Иногда первым таким этапом может стать демо-версия для издателей, иногда альфа-версия, чаще всего бета-версия проекта.
На этой стадии работы разработчики уже должны использовать системы баг-трекинга для работы с проектом, которые позволяют продюсеру следить за работами по обнаружению и ликвидации ошибок. Если разработчикам кажется, что можно обойтись без таких систем в работе с "1С", то у них с нами будут проблемы.
Мы настаиваем на использовании одной из двух технологий работы с версиями игры:
1. Система Test Track Pro находится в "1С", и разработчики получают к ней удаленный доступ.
2. Система баг-трекинга (например, Mantis Bugtracker или Bugzilla) находятся у разработчиков, и продюсеры получают к ней удаленный доступ.
Наблюдение за работами по обнаружению и исправлению ошибок является важным инструментом продюсера для оценки степени готовности продукта и уровня его качества.
"Новая версия не тестируется до окончания цикла старой"
Это означает, что если цикл тестирования игры занимает 3 дня (тщательное прохождение игры), то только через 3 дня можно будет перейти к тестированию обновленной версии, содержащей исправления. В конце цикла восстанавливаются все отложенные записи о дефекатах,
Нарушения этого правила приводят к тому, что первая треть игры обычно оттестирована отлично, вторая треть - слабо, а последнюю треть игры вообще не видел никто.
"На этапе тестирования сейвы должны быть совместимы между версиями"
Это важное правило, которое игнорируют практически все разработчики. Подумайте о том, что на этих этапах в игру уже играют продюсеры, тестеры, сотрудники маркетинговых отделов, продюсеры западных издателей. Они все буду вынуждены заново проходить долгую и увлекательную игру.
Заботьтесь о совместимости и механизмах конвертации сейвов или сопровождайте каждую сдаваемую версию сейвами в ключевых местах и "читами".
"Первый релиз-кандидат релизом не становится"
Бета-версии и релиз-кандидат порождают разные виды ошибок. Ошибки в кредитах игры, в наименовании меток дисков и т.п. возникают только на этапе релиз-кандидата. После первого релиз-кандидата еще приходится изрядно поработать.
"Патч сразу после релиза - индикатор низкого качества продукта"
Патч к публичной демо-версии, версии для журналистов или издателей всегда вызывает отрицательную реакцию. Патч сразу после релиза - индикатор низкого качества продукта. Хотите ли вы, купив в магазине телевизор, прямиком нести его в мастерскую на ремонт?
Любой официальный патч - это продукт издателя. Состав патча согласовывается с издателем. Важно отметить, что приоритеты разработчика и издателя по составу патчей сильно отличаются - исправление ошибки в кредитах, например, для издателя куда важнее исправления любой технической ошибки игры.
Патч выпускается только по решению и в сроки, установленные издателем. Если разработчик хочет выпустить неофициальный патч, то он может получить разрешение на это у продюсера и распространять его через свой сайт с обязательным уведомлением, что это неофициальный патч, устанавливаемый пользователем на свой страх и риск.
"Продукт на рынок выпускает издатель"
Решения по датам релизов - решения издателя и только издателя. Никакие результаты работы по проекту без разрешения издателя не публикуются. Если кто-то хочет опубликовать результаты работ по проекту, например, в своем портфолио, то есть смысл спросить предварительно продюсера, не нарушит ли это какие-то договоренности или планы издателя.
У издателей и разработчиков в проекте есть некоторое "разделение труда" - разработчик игру делает, а издатель ее продает. Разработчику не стоит вмешиваться в процессы продажи игры. Если разработчика не попросили участвовать в создании упаковки, например, то лучше просто согласиться. Оспаривать с издателем даты релиза игры тоже не очень хороший тон.
Хочется дать ответ на самый частый вопрос разработчиков, задаваемый продюсерам: "Почему в магазине нет нашей игры?". Если это фирменный магазин "1С", то продюсер, возможно, сможет что-то выяснить, если это магазин крупной сети, то возможны варианты, но если это магазин ПБЮЛ "Иванов" на углу улицы Коммунистической и проспекта Маркса в городе Н, то такой вопрос нужно задавать ПБЮЛ "Иванов", а не вашему продюсеру. И, возможно, ПБЮЛ "Иванов" после этого начнет продавать вашу игру.
Правила игры. Часть 5. Продвижение
"Продвижение начинается, когда есть что показывать" Можно возразить: "Сталкер и LRC - самые раскрученные проекты, а их до релиза толком никто не видел". Следует однако иметь в виду, что это "звезды отечественного продвижения ", т.е. исключения. Таких проектов может быть один-два в год и рынок потом от них долго "отдыхает". И потом, кажущаяся естественность интереса к этим продуктам была далека не бесплатная и требовала много-много-много других усилий.
"Когда задумывается структура сайта игры, точно должно быть известно, кто и чем его будет наполнять"
Перед созданием сайта задумайтесь над ключевым вопросом: зачем туда приходить людям, будущим игрокам? Чтобы получить новую информацию об игре. Если сайт "мертвый", не обновлялся пару месяцев, это очень легко заметно, и туда больше никто не придет. Хватит ли у нас сил готовить регулярно скриншоты, каждую неделю публиковать что-то интересное - такое, что человек и в следующий раз бы зашел на сайт в ожидании дополнительной порции информации?
"Чем проект "круче", тем больше надо артов, рендеров, скриншотов, роликов, интервью, демо, пресс-туров и т.д."
Ну и почти повторение предыдущего правила, только более общее - давайте соизмерять амбиции возможности. Рекомендуем доклад Артеменко и Субботина "Легенды и мифы игрового пиара. V0.99".
Правила игры - Часть 6. Локализация
"Локкит предоставляет разработчик. Локкит предоставляется на английском"
Если это правило кажется вам обременительным (см. "Если вы не договорились об исключениях - действуют правила") - договоритесь с вашим продюсером заранее (!) о том, чтобы он помог организовать перевод текстов на английский.
"Переводы на целевые языки выполняет издатель на целевой территории; сборку локализованной версии выполняет разработчик"
Из этого, однако, следующее:
• Не рассчитывайте, что вы будете понимать, ЧТО вы вставляете. Интеграцию иероглифов simplified chinese невозможно для нас сделать осмысленно - только полуавтоматически.
• Используем только Юникод - китайская локализация с двухбайтной кодировкой совсем не редкость.
• Соблюдение сроков в работе с западными партнерами - стоит денег, а регламент работ диктуют западные паблишеры.
Выводы
Они же заповеди и принципы, которые хотелось бы огласить. Мы, сотрудники направления игровой разработки фирмы "1С", исходим в своей работе именно из этих принципов.
Вывод№1. Будьте партнерами
Взаимодействие "издатель-разработчик" построено на отношениях, когда выигрыш одной стороны - это выигрыш и другой стороны, т.н. win-win ситуация. Ведь чем выше продажи и прибыль издателя, тем большие роялти разработчика и желания у издателя инвестировать в разработчика еще денег.
Нарушения этого принципа приводят к проблемам
• Синдром "сдачи этапа" - см. "Этап - это не самоцель, а средство измерения". Такие искажения тактических целей могут в дальнейшем привести к расхождению стратегических и ситуация перерастет в отношения, где выигрыш одной стороны возможен только за счет ущерба другой стороны.
• Различия в истинных целях - глобальное расхождение. Это когда разработчик не хочет роялти, а хочет "маржей в авансах". Или издатель не хочет "игру века", а хочет "по-быстрому бабла срубить".
• Различия в творческом видении - по последствиям, в общем, не самые разрушительные, но тоже проблемные.
Вывод№2. Цените отношения
Сохраняйте хорошие отношения с теми, кто может быть вам полезен, и не создавайте врагов из тех, кто может быть опасен. Если вы построили отношения правильно, то ваше понимание продюсера поможет ему правильно понимать вас, а от этого выиграете, в первую очередь, вы.
Лучшие способы настроить против себя продюсера:
• проявлять невнимательность или неуважение;
• присылать этап в пятницу в 17-55 и требовать что-то в понедельник до 10-00 (особенно денег).
Вывод №3. Храните уважение
Если к продюсеру нет доверия или уважения - у проекта нет продюсера, а есть враг, препона и помеха. Если у вас конфликтные отношения с вашим продюсером - значит, у вас нарушены отношения в части уважения друг друга - решите эту проблему. Проблему можно решить как за счет пересмотра своего отношения, так и путем твердого требования к издателю назначить вам другого продюсера.
Будьте чаще критичны и к себе - это всем полезно.
Вывод №4. Не вводите в заблуждение
Имея точную информацию, продюсер может принимать правильные решения и может очень много сделать для вашего проекта. В том числе, помочь выйти из затруднения и справиться с кризисом. Локальный же выигрыш от искажения или "заметания мусора под ковер" будет стоить стратегических целей и перспектив.
Ну, и следует помнить, что вводя в заблуждение продюсера, вы вводите в заблуждение другие стороны - лицензиаров, маркетинг, будущих потребителей.
Вывод №5. Понимайте критику
Повторимся, что критика продюсера - не самореализация, а способ деятельности. Не бойтесь его критики, а используйте ее! Рассматривайте своего продюсера как источник полезной информации.
Критика должна быть направлена не на личности, а на результаты. Если это не так - ищете, в чем проблема.
Критику воспринимать сложно, об этом надо помнить всем.
Вывод №6. Выполняйте обязательства
Давайте вместе соблюдать элементарные правила человеческого взаимодействия:
• Не уверен - не обещай
• Пообещал - выполни
• Не можешь выполнить - договорись об изменении.
Ну и простое правило: предупреждать об изменениях в сроках до (!) истечения этих сроков - уже повод считаться профессионалом.
Ну, и в заключение, главное Правило:
Делайте вовремя хорошие игры!
Статья написана на основе доклада на КРИ-2007.

Статистика

Открытых тем ...................................... 1237

Ответов .............................................. 743

Просмотров ......................................... 1965903

Зарегистрированых пользователей ...... 2600

Новые пользователи: alexandrtihii966, andreytroz1992, Lievre, hitrof, lolckik