5 правил успешной разработки приложений для бренда Heads&Hands
Презентация о правилах разработки мобильных приложений для крупных брендов. Основные ошибки и проблемы, с которыми сталкивается компания-разработчик и способы их решения.
Обзорный материал о применяемых методиках работы над цифровыми продуктами. Лекция проведена в рамках интенсива по продуктовому дизайну в Британской Высшей Школе Дизайна (Москва).
Инструменты юзабилити для роста бизнесаFedotov Alex
Обзор 5 летней практики команды юзабилити.
Как создать персонаж или архетип персоны
Как за 5 секунд понять качество вашего сайта или посадочной страницы
Как своими руками сделать юзабилити-тестирование
10 принципов юзабилити Якоба Нильсена для быстрой оценки юзабилити вашего сайта
Удаленное юзабилити тестирование, сервисы
Как создать интерактивный прототип, обзор программ Axure, Marvel и других
Что будет, если выйти за пределы парадигмы дизайнер-заказчик и самому управлять процессом получения результата? Управление проектированием, дизайном и разработкой продуктов, исследование рынка и конкурентов, тестирование ваших решений и поддержка ваших пользователей — что нужно знать дизайнеру о работе менеджера или для тех, кто хочет им стать.
5 правил успешной разработки приложений для бренда Heads&Hands
Презентация о правилах разработки мобильных приложений для крупных брендов. Основные ошибки и проблемы, с которыми сталкивается компания-разработчик и способы их решения.
Обзорный материал о применяемых методиках работы над цифровыми продуктами. Лекция проведена в рамках интенсива по продуктовому дизайну в Британской Высшей Школе Дизайна (Москва).
Инструменты юзабилити для роста бизнесаFedotov Alex
Обзор 5 летней практики команды юзабилити.
Как создать персонаж или архетип персоны
Как за 5 секунд понять качество вашего сайта или посадочной страницы
Как своими руками сделать юзабилити-тестирование
10 принципов юзабилити Якоба Нильсена для быстрой оценки юзабилити вашего сайта
Удаленное юзабилити тестирование, сервисы
Как создать интерактивный прототип, обзор программ Axure, Marvel и других
Что будет, если выйти за пределы парадигмы дизайнер-заказчик и самому управлять процессом получения результата? Управление проектированием, дизайном и разработкой продуктов, исследование рынка и конкурентов, тестирование ваших решений и поддержка ваших пользователей — что нужно знать дизайнеру о работе менеджера или для тех, кто хочет им стать.
Обзорный материал о базовых принципах прототипирования цифровых продуктов. Использованы общедоступные материалы по теме, собранные с различных тематических ресурсов. Для демонстрации использованы прототипы студии funkypunky. Лекция проведена в рамках интенсива по продуктовому дизайну в Британской Высшей Школе Дизайна (Москва).
User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...Yury Vetrov
Мастер-класс Юрия Ветрова "Кросс-платформенное проектирование для мобильных — Android, iPhone, Windows Phone 7, Symbian" с конференции User Experience 2011.
Андрей Солоной "Как людям бизнеса работать с программистами"Startup_Technologies
Эксперт Startup Weekend, ведущий .NETразработчик и архитектор с большим опытом, ментор в EffectiveSoft Андрей Солоной выступил на Стартап-школе с мастер-классом: "Как людям бизнеса работать с программистами"
Обзорный материал о базовых принципах прототипирования цифровых продуктов. Использованы общедоступные материалы по теме, собранные с различных тематических ресурсов. Для демонстрации использованы прототипы студии funkypunky. Лекция проведена в рамках интенсива по продуктовому дизайну в Британской Высшей Школе Дизайна (Москва).
User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...Yury Vetrov
Мастер-класс Юрия Ветрова "Кросс-платформенное проектирование для мобильных — Android, iPhone, Windows Phone 7, Symbian" с конференции User Experience 2011.
Андрей Солоной "Как людям бизнеса работать с программистами"Startup_Technologies
Эксперт Startup Weekend, ведущий .NETразработчик и архитектор с большим опытом, ментор в EffectiveSoft Андрей Солоной выступил на Стартап-школе с мастер-классом: "Как людям бизнеса работать с программистами"
How to make a Customer journey a successful tool.Geert Stox
How to make a thorough Customer Journey?
This presentation will guide you through every step to make an insightful Customer Journey and make it a helpful tool for your marketing and communication strategies. The perfect starting point for your next product service design or innovation :-)
An update to my presentation on crowdfunding, this time with more emphasis on Belgium.
You can see the presentation video here:
https://www.youtube.com/watch?v=KnHExqzHUY0
The presentation consists of 11 + 1 tips for successful crowdfunding in our little country.
Проектный анализ в разработке игр: давайте начнем сбор данных / Данил Денеко ...DevGAMM Conference
Игровую индустрию трудно представить без современного набора продуктовых метрик, анализа поведения пользователя. Аналогичный подход можно применить к процессу разработки игры – собирать данные о скорости производства единиц контента, производительности труда, разнице между плановыми и фактическими затратами.
В рамках этого доклада я предлагаю обсудить базовые понятия проектного анализа и их применимость в игровой разработке.
Содержание:
1. Что нужно описывать в техническом задании, а чего вписывать не следует
2. Примеры описания пунктов технического задания
3. Особенности описания в технических заданиях медиа-элементов курса (звук, видео, анимация, графика)
4. Подводные камни при составлении технического задания
Alexandr Mezin: Analytics for the game designers
UA Online GameCraft Conference 2021
Website - https://gamecraftconf.com/online
Youtube - https://www.youtube.com/startuplviv
FB - https://www.facebook.com/GameCraftConference
Разработка сайта это как война: череда сражений за победу. А в современной войне есть три важные вещи: разведка, артобстрел и авиация. Небесные высоты мы оставим дизайнерам, а поговорим о разведчиках и об орудиях дальнего боя. То есть о системных аналитиках и о проектировании сайтов.
"ТОП 3 кроки для швидкого старту кар'єри Project Manager в IT компанії"
как продать издателю свою игру
1. Как продать издателю свою игру? Правильное оформление и подача материалов по проекту Косенко Роман, менеджер по внешним проектам, [email_address] КОНФЕРЕНЦИЯ РАЗРАБОТЧИКОВ КОМПЬЮТЕРНЫХ ИГР 21-22 марта 2003 года
Собственно, как здесь написано, меня зовут Косенко Роман, я работаю в фирме «1С», называюсь менеджером внешних проектов, или, как вариант, модным словом «продюсер». В ближайший час я постараюсь рассказать о том, как продать издателю свою игру. Я намерено использовал термин «продать» , несмотря на его… империалистическое звучание, потому что так, фактически, и обстоит дело – разработчик предлагает, а издатель покупает или не покупает права на проект с банальной и весьма меркантильной целью – получить прибыль. Издатель занимается изданием игр не потому, что ему это нравится (хотя бывает и не без этого), а для того, чтобы зарабатывать деньги. Может быть это чересчур очевидно, но некоторые разработчики почему-то об этом забывают и настойчиво, а иногда и публично требуют чего-то от издателя. Это смешно, а главное – бессмысленно, а вернее - ведет к противоположному результату. Из вышесказанного первое правило – издатель ничем не обязан разработчику, последний всего лишь предлагает приобрести права на издание проекта – я постараюсь рассказать, как это делать наилучшим образом. [>]
Еще немного общих слов о самом процессе представления проекта издателю. [>] [>] Индустрия молода , поэтому универсальных решений и стандартов пока не существует . Они просто не успели сложиться. Реальные деньги , а вместе с ними корпоративная культура и все сопутствующие институты пришли в индустрию компьютерных игр, на мой взгляд, всего 3-4, может быть 5 лет назад. Поэтому некоторые или, вернее сказать, все компании-издатели могут и будут предъявлять свои собственные требования к порядку подачи проектов, это касается и перечня необходимых документов, и их содержимого. У западных издателей порядка и стандартизации, возможно, чуть больше, но уверяю вас, придя в EA, Activision, Sony или, например, в Microsoft, вы обнаружите, что по только одним им ведомым причинам, все хотят от вас разного. В целом все будет более-менее схоже, но в деталях отличий будет предостаточно. Тем не менее, определенная сложившая практика, конечно же, есть. Мы в 1С стараемся ее придерживаться, по мере сил, а также рассчитываем, что приходящие к нам разработчики будут делать то же самое. Очевидно, что для разработчика, имеющего за плечами уже изданные и успешные проекты , могут и будут сделаны существенные поблажки . Но в данном случае я буду говорить о молодой команде , которая ищет издателя для своего первого проекта. [>]
Если предположить, что мечтой любого разработчика является заполучить в издатели Electronic Arts во всем мире и, скажем, 1С в России, то разумно следовать установленным этими издателями правилам . Это один из шагов к тому, что ваш проект будет как минимум рассмотрен . Надо учитывать, что принятый на западе стиль общения (это когда вам постоянно улыбаются, кивают головой, хором говорят “wow!” ) предполагает, что вам скорее просто не ответят, чем ответят прямым отказом. Получая иногда десятки предложений в неделю, менеджер гарантированно отбросит те, что не соответствуют его личным или же принятым в компании представлениям о форме подачи проекта. Он сделает это хотя бы по причине экономии времени . Это действительно так, мы сами с этим сталкивались, работая с другими (западными) издателями. И хотя мы стараемся отвечать на все заявки, это в большой степени зависит от загруженности конкретного менеджера. [>]
Резюмируя вышесказанное, хочу подчеркнуть, что все рассказываемое мною дальше в полной мере относится именно к 1С и может служить лишь рекомендацией по работе с другими издателями . [>]
Чтобы четко структурировать процесс подачи проекта, я разделил происходящее на три этапа и незатейливо назвал их – первый, второй, третий. [>] Деление это достаточно условно , в реальности этапы плавно перетекают один в другой и даже пересекаются, но, опять же, это деление позволяет четко представить себе процесс подачи и, главное, рассмотрения проекта. Итак, три этапа… [>]
На первом этапе разработчик заявляет о своем существовании и объясняет издателю , какую именно игру он собирается делать. Это по сути коммерческое предложение разработчика издателю. В результате первого этапа у издателя обязано сложиться предельно четкое представление о будущей игре , на основании которого он сделает принципиальный вывод - нужна она ему или нет. Хочет он ее издавать или нет. [>]
На втором этапе разработчик убеждает издателя, что потенциально способен сделать предполагаемую игру. Т.е. достаточно ли квалификации у команды, серьезны ли их намерения , насколько детально продумана игра и спланирована разработка и т.д. Характерно, что именно на этом этапе формируется основное впечатление о разработчике вообще. В итоге, издатель решает готов ли он рисковать, вкладывая деньги в предлагаемый проект. [>]
На третьем этапе разработчик согласовывает с издателем процесс разработки , формируется план работ по проекту, контрольные точки, утверждается смета проекта , обсуждаются термины договора , порядок оплаты и т.д. Данный этап выглядит уже чисто техническим , но, на самом деле, он достаточно важен , и на нем издатель еще может отказаться от проекта , если не удастся прийти к консенсусу по каким-то важным вопросам. [>]
Прохождение каждого из этих этапов – хороший знак для разработчика, свидетельствующий о правильности пути, но не гарантирующий успеха всего мероприятия. Отказ может последовать на любом этапе по разным причинам. [>]
Нужно иметь в виду, что со стороны издателя в рассмотрении проекта участвует множество людей из разных отделов . Оценивается качество проекта , его перспективность , востребованность , финансовые , юридические вопросы и совершенно отвлеченные факторы, не имеющие прямого отношения к разработке игр. Это требует определенного времени . [>]
Теперь подробнее о каждом этапе. По порядку. [>] Первый этап. [>] Как я уже говорил, первый этап – это объяснение издателю, что за игру собирается делать разработчик. Объяснение – описание проекта - оформляется в документ под названием концепт проекта , о котором я расскажу через пару минут. Этап фактически сводится к написанию этого документа и отправке его издателю. [>]
Может показаться, что этот этап сравнительно прост, по крайней мере - с точки зрения трудозатрат . Это не так . Концепт проекта – чрезвычайно важный и сложный документ . Правильно составленный концепт , при условии интереса издателя, облегчит прохождение остальных этапов. Из десятков подаваемых проектов лишь единицы успешно проходят первый этап и принимаются к дальнейшему рассмотрению. Часто именно потому, что разработчики не придали нужного значения первому контакту с издателем. Важно отнестись к нему со всей серьезностью . Если вы ограничитесь письмом: «Привет! Мы молодая команда разработчиков. Хотим делать стратегию про Римскую Империю. Интересует ли вас данное предложение?», результат очевиден. Вам откажут. Тщательно подготовьтесь к первому общению с издателем. Основательно поработайте над документом , который вы собираетесь ему отправлять. Сленг , панибратство , любая мелочь способна полностью испортить впечатление , как и элементарные ошибки в тексте (приписка «извенити за ашипки» не исправит ситуацию). [>]
Итак, подаваемый на этом этапе документ называется концепт проекта . [>] Концепт проекта является максимально сжатым описанием проекта на 3-5 страницах. Не более того . Обратите внимание на последнее, 3-5 страниц – это , наверное , предельный объем , который человек способен быстро пробежать глазами, ухватив и сохранив весь смысл. Большего не нужно, ибо документ большего размера скорее «отпугнет» менеджера , и читать его не будут в силу той же экономии времени. Наличие у разработчика полноценного дизайн - документа издатель будет готов оценить несколько позднее (на следующем этапе). [>]
Концепт – это ни в коем случае не рекламное объявление , а квинтэссенция видения проекта разработчиком. Избегайте размытых формулировок – если вы собираетесь делать шутер, то так и пишите - «шутер», а не «игра популярного жанра и т.д.». Постоянно помните, что после прочтения концепта у менеджера должно сложиться четкое представление - о чем будет игра, как в нее играть, на что она похожа . [>]
При написании концепта не нужно бояться сравнений . Если вы напишете, что игра будет похожа на Doom III , но пошаговой, то не факт, что издателю это понравится, но, по крайней мере, он сможет четко себе представить, о чем идет речь. Лучше ссылаться на известные игры , но если вы собираетесь затронуть какой-то весьма специфичный жанр или уникальный игровой элемент , то можно вспомнить и нечто малоизвестное (в этом случае необходимо обязательно указать полное название игры, разработчика, издателя, время выхода). [>]
Вот из чего, на мой взгляд, должен состоять идеальный концепт проекта . [>] Во-первых, жанровая и платформенная принадлежность . Тут все элементарно. Просто пишете, к какому жанру или пересечению жанров относится игра (шутер, стратегия, симулятор с элементами РПГ и т.д.), и для каких платформ она будет разрабатываться. [>]
Во-вторых, целевая аудитория . Это может быть « игра для детей », « игра для людей преклонного возраста » или, если игра активно эксплуатирует основные человеческие инстинкты, в ней присутствуют обнаженные женские или мужские тела , кровь , насилие и т.д., то - сами понимаете , на какой возраст она должна быть ориентирована. Здесь же полезно указать, на какую группу игроков рассчитана игра. Это могут быть приверженцы MMORPG или пластилиновых квестов , шутеров или sci-fi RPG . Можно сослаться на ряд похожих игр , любители которых должны, по вашему мнению, обратить внимание и на ваше творение. [>]
Далее следует одна из самых, если не самая важная часть . Это детальное предельно четкое описание игрового процесса . Если игроку предстоит собирать зеленые кубики , объединять их в пирамидки и уничтожать оранжевые шарики , то так и пишите. Ни в коем случае не заменяйте это на безусловно интересный сюжет , согласно которому 12 тысячелетий зеленые кубики были необоснованно угнетаемы и притесняемы оранжевыми шариками , как жестоко подавлялись восстания, но наконец… и т.д. Нужно четко и конкретно рассказать , что нужно и можно будет делать игроку , как это будет для него выглядеть , какое удовольствие он этого должен получить. Повторюсь, это самая важная часть концепта. На основании этого описания издатель представит себе игру, поставит себя на место игрока, и решит, готов он издавать ее или нет . [>]
После того, как вы описали геймплей , можно кратко рассказать о сюжете игры. Где происходят игровые события , что случилось , кто главный герой , кто главный враг , и как добро победит зло или наоборот . [>]
Дальше следует анализ сильных и слабых сторон основных конкурентов или аналогов. Тут тоже все относительно просто . Перечисляете некоторое количество похожих проектов , которые уже вышли (очевидно, что самых значимых ) и отмечаете, какие были находки в каждом проекте, что реализовано удачно и – соответственно - в вашем проекте будет повторено и развито, а также - какие были допущены погрешности и, соответственно, как вы собираетесь их исправить . То же самое нужно проделать и для предполагаемых конкурентов - проектов, которые должны будут выйти приблизительно в одно и то же время с вашим, и указать на свои преимущества . [>]
После этого, настало время рассказать о технологической базе проекта. Несмотря на то, что в последнее время особых технологических прорывов не наблюдается, и индустрия стала развиваться достаточно равномерно, издатель должен представлять себе общий технологический уровень проекта . Достаточно простого перечисления основных технологий , которые будут задействованы в проекте (например, инверсная кинематика , динамические тени и т.д.) – все достаточно кратко и – обязательно - простыми словами . Важно не переусердствовать на этом этапе. Несмотря на то, что многие, хотя и далеко не все, менеджеры в прошлом сами были разработчиками и к тому же стараются следить за развитием технологий, сугубо технологические дебри могут остаться за пределами их понимания . [>]
Далее уместен краткий рассказ о команде: где находится , сколько человек в составе, есть ли опыт разработки . [>]
И закончить все это необходимо предполагаемым сроком разработки и общей стоимостью проекта. Например , «Предполагаемое время разработки – 24 месяца, бюджет – 2 миллиона». К слову, некоторые менеджеры начинают чтение как раз с этого , ибо, в силу разных причин, издателю может быть неинтересна тактическая стратегия через 24 месяца или за 2 миллиона. Вот , собственно, и все по концепту проекта. Написав такой документ, необходимо отправить его по адресу , предназначенному для сабмита проектов, и ждать реакции издателя, которой, как я уже говорил, может и не последовать , что означает отказ. Сколько может занять времени рассмотрение? По-разному. Но будьте уверены - если издателю действительно интересен проект, он ответит относительно быстро. [>]
Итак, второй этап . [>] Если вы получили ответ, и он не является прямым отказом , то можно считать, что вы перешли ко второму этапу . Вообще, это хороший показатель – такое случается с одним проектом из десятков . Обнадеживаться, однако, не стоит – предстоит еще многое. [>] На втором этапе , как я уже говорил, разработчик убеждает издателя, что способен реализовать все заявленное. Под способностью здесь подразумевается не просто компетентность и умение программистов программировать, а художников – рисовать, но и серьезность намерений разработчиков, наличие необходимых специалистов или возможность их привлечения, продуманность проекта в целом (если из 100 будущих миссий расписана всего одна , а про остальные говорится, что они будут придуманы в процессе, то это вызовет как минимум удивление), умение планировать и прочие «отвлеченные» факторы. Понятно, что на этом этапе происходит очень интенсивный обмен материалами по проекту. [>]
Обычно, заинтересовавшись присланным концептом проекта, издатель попросит предоставить следующее : информацию о команде , предварительный дизайн-документ , демонстрационную или технологическую версию , имеющиеся наработки по контенту . [>]
Представление команды. Это, наверное, самый легкий пункт . [>] Вам всего лишь нужно перечислить, какое количество профессиональных людей имеется в команде на постоянной основе , т.е. готово заниматься (а вернее – занимается) проектом большую часть своего времени. Буквально – «два программиста, сценарист, два художника, три моделлера и т.д». Рассказать, на чем основывается их профессионализм . В каких проектах принимали участие ; если не принимали, то чем занимались вообще. Если каких-то нужных специалистов в команде нет, то следует объяснить, как и в какие сроки их планируется привлечь , есть ли какие-то договоренности. [>]
Предварительный дизайн-документ . [>] Предварительный дизайн-документ – это, по сути, расширенный и доработанный концепт, объемом до 50 или больше страниц. В принципе, его уже можно считать полным дизайн-документом. Я поясню, в чем разница . Дело в том, что так называемый полный дизайн-документ обязан включать в себя полную спецификацию игры вплоть до используемых математических моделей и внутренней документации (например, описания принятых форматов данных). Издателю эта информация на данном этапе совершенно не интересна . Да и, возможно, не будет интересна и далее. В общем, в данном случае, говоря о предварительном дизайн-документе , я буду говорить о документе, полностью описывающем игру , но не затрагивающем технические аспекты . Один из подходов предполагает разделение дизайн-документа на функциональную и техническую спецификацию . Вот функциональная спецификация и есть наш предварительный дизайн-документ. [>]
Идеальная структура данного документа следующая. [>] Формальная спецификация игры состоит из жанровой и платформенной спецификации , взятых из концепта проекта, к которым необходимо добавить системные требования . Минимальные, рекомендованные, максимальные. Желательно пояснить , какой класс железа необходим игре. Например, объем текстур , который предполагается использовать, определяет минимальный объем видеопамяти в 64 Mb . Напишите об этом. [>]
Детальное описание всего игрового процесса . Полное описание возможностей игрока – как происходит управление игровыми объектами, какие действия может предпринимать игрок, какую информацию и как получает. Какая имеется мотивация тому или иному поведению игрока. Какая предусмотрена система бонусов (т.е. наград) и наказаний . Какие предполагаются режимы игры . Нужно описать роль искусственного интеллекта в игре, если это необходимо для полного понимания игрового процесса. [>]
Описание игрового мира, в котором происходят все игровые действия. Если это единый мир – то его численные характеристики , правила перемещения игрока по нему. Численные характеристики – это размеры , протяженность дорог , количество городов , количество специальных объектов , плотность их размещения и т.д. Если игровой мир – набор отдельных уровней (карт) или групп уровней – то необходим их перечень , характеристики, аналогичные названным, и порядок перехода между ними. Далее должно следовать перечисление и описание всех объектов игрового мира – персонажей , оружия , предметов , сооружений , городов , техники , магических заклинаний и т.д. Т.е. абсолютно всего , что есть (или будет) в игре. Если для некоторых элементов уже имеются эскизы или графическая реализация , желательно разместить их непосредственно в документе . [>]
Игровой интерфейс . Формируется схема игрового интерфейса . Составляется описание всех экранов базового и игрового меню , панелей управления . Описываются все принципы и методы управления , которые доступны игроку. [>]
Графическая составляющая игры . Перечисляются все графические элементы , которые необходимы для создания и выпуска игры. Элементы интерфейса , экраны меню , заставки , фоны , курсоры , прицелы , иконки . Анимационные вставки (пререндеренные ролики и ролики на движке). Спрайты , текстуры ландшафта , модели флоры и фауны , персонажей или юнитов , техники , зданий и сооружений , оружия , предметов и прочих игровых объектов . Список может быть огромен, поэтому допускается группирование – 25 текстур для зимнего ландшафта. 50 моделей «летних» деревьев. Список спецэффектов . Маркетинговые материалы и упаковка (логотипы, реклама, сайт, упаковка). [>]
Звуковая составляющая игры . Аналогично предыдущему пункту – только на этот раз все, что касается звука в игре. Количество и стилистика музыкальных треков . Перечень звуков для интерфейса , фоновые шумы . Звуков выстрелов , взрывов , смертей , двигателей . Все, что нужно, чтобы игра ожила. Не забываем про речь в игре . [>]
Остается сюжет игры, и документ можно считать готовым. В данном случае уже уместно его более полное описание . Опять же, не нужно увлекаться мишурой. Масштабное и красочное описание предыстории, полные тексты диалогов – этого не нужно . Нужна основная идея , полный перечень квестов , заданий , участвующих персонажей , возможных линеек развития сюжета и окончаний игры . Готово? Если вы обратили внимание, составленный таким образом предварительный дизайн-документ – это фактически ТЗ на разработку с детальными перечнями необходимых работ . Не считая работ по программированию , которые тяжелее нормируются и описываются. Чем грамотнее и полнее он составлен, тем выше издатель оценит ваше понимание предстоящего процесса разработки и умение планировать . [>]
Следующая часть второго этапа – предоставление демонстрационной или технологической версии. [>] Идеально, конечно же, показать самодостаточную часть игры (отдельную миссию, уровень, этап и т.д.), полностью реализованную и с контентом финального качества. Увидев и картинку, и геймплей, издатель сможет с легкостью оценить, согласен он издавать такую игру или нет. Но идеальный вариант – достаточно редкое явление , чаще разработчик готов предоставить какие-либо технологические версии. Здесь есть варианты . [>]
Сразу оговорюсь, совсем без версии, скорее всего, ничего не выйдет. Как бы ни была привлекательна игра на бумаге , издатель, как правило, предложит прийти тогда, когда будет готова версия . [>]
Первый вариант – графический движок и больше ничего. К сожалению, вариант не самый хороший, ибо более-менее приличную картинку сейчас умеют делать очень многие, а вот приклеить к ней интересную игру – далеко не каждый. Тем не менее, если вы уверены, что ваша картинка действительно сногсшибательна , а геймплей очевиден – почему бы не попробовать. [>]
Второй вариант – идеальный геймплей . Крайний случай - это когда вся графика представлена набором разноцветных параллелепипедов , а происходящее столь увлекательно , что играющий сам готов домыслить остальное . Чувствуете в себе силы на что-то подобное? У меня есть определенные сомнения … [>]
Третий вариант – нечто среднее между двум предыдущими. Самый ходовой , но совсем не простой . Его худшая версия – это когда и геймплей еще никакой , и графика особо не блещет . Лучше, конечно же, потратить время, и довести и то, и другое до приемлемого уровня . Это когда, как минимум, не придется через каждую секунду извиняться за демонстрируемое , говоря «на эту модель не смотрите , она уже переделана, просто не успели вставить », «здесь текстуры временные », « освещение уже готово, но пока глючит , мы его еще вставим»… Подобные комментарии приведут, в лучшем случае, к тому, что вас попросят прийти в следующий раз , в худшем – что вас занесут в «черный список» и больше не станут воспринимать всерьез. [>]
Соответственно, лучшее, что можно сделать, - стремиться довести этот третий вариант до того, о чем мы говорили в самом начале – нормальной демонстрационной версии . [>]
Что касается контента или арта, здесь все довольно очевидно . Из того, что есть, выбираете лучшее , по возможности единообразно оформляете и передаете издателю. Основные мысли здесь следующие. [>] Естественно, что при отсутствии полноценной демонстрационной версии данный пункт становится обязательным и чрезвычайно важным. Издателю в любом случае нужно оценить качество графики , которую разработчик способен производить. [>]
Аналогично рассказанному ранее, ни в коем случае не нужно показывать материалы и, извиняясь, сообщать , что смотреть на них не нужно, что они будут лучше, потому как вы их уже переделали, но просто не успели собрать или записать на болванку. [>]
Хорошо бы, чтобы материалы от художников или моделлеров, утвержденные соответствующими лицами, были единообразно оформлены . К ним могут быть добавлены рамочки, рюшечки, символика игры и разработчика , название того, что демонстрируется . Это не займет много времени и ресурсов , но добавит материалам серьезности и представительности . [>]
Вот, собственно, и все , что я хотел сказать по второму этапу . Если издатель начинает заговаривать о плане работ , смете проекта или обсуждать договор , значит, вы добрались до третьего этапа . Это очень хороший знак , который, впрочем, тоже ничего не гарантирует. [>] [>] Перейдя к третьему этапу , разработчик фактически вышел на финишную прямую . Осталось согласовать процесс разработки и подписать договор . [>]
Необходимые для этого документы : смета проекта и план работ . О них и поговорим. [>]
Окончание третьего этапа - подписание договора . Договор – это отдельная тема , затрагивать которую в данном выступлении я даже не буду. Вкратце, «рыба» договора есть у любого издателя, и он ее предоставит разработчику, если последний дойдет-таки до подписания . Раньше – вряд ли . Не нужно спрашивать - почему. Конкретное содержание договора обычно сугубо индивидуально , так как адаптируется с учетом особенностей проекта и переговоров с разработчиком. Еще одно замечание. Раньше часто, сейчас меньше, но все же бывает, что задается вопрос – необходимо ли являться юридическим лицом для заключения договора? В подавляющем большинстве случаев – да. Т.е. подписание договора с физическим лицом - скорее исключение , чем предмет обсуждения. К тому есть и юридические, и экономические предпосылки , а также и вопрос серьезности намерений разработчика. [>]
Смета проекта. Здесь есть два основных и, с первого взгляда, взаимоисключающих момента . [>] Во-первых, принципиальное решение о финансировании проекта принимается на основании его общей стоимости . Во-вторых, сложившейся практикой является тот факт, что все производимые выплаты покрывают расходы разработчика на собственно разработку и не должны включать прибыль . В чем, собственно, смысл . С одной стороны, для издателя важно , что если данный проект стоит 1 миллион , а принесет – 2 , и, с учетом прочих расходов, он экономически выгоден , то браться за него можно. С другой стороны, вложение денег в любой проект – рискованное мероприятие . Вероятность вернуть вложенные деньги без нормального (успешного) завершения проекта весьма мала . Разработчик же спокойно работает и получает зарплату … В случае провала или неуспеха проекта, разработчик может сетовать лишь на мистическую «упущенную прибыль» , а издатель потеряет вполне реальные деньги . Если в бюджет проекта закладывать еще и прибыль разработчика , то ситуация станет совсем некрасивой . Поэтому существует некое «джентльменское соглашение» , согласно которому финансовые взаимоотношения издателя с разработчиком построены по схеме advance against royalty , где advance – деньги, которые разработчик получает в качестве аванса на разработку, а royalty – прибыль , которую разработчик получит после того, как «отобьются» расходы на разработку . Данная схема позволяет говорить о разделении рисков между издателем и разработчиком. [>]
Детальная смета проекта позволит издателю убедиться в том, что разработчик соблюдает указанное «джентльменское соглашение», и оценить эффективность использования средств . В принципе, издатель владеет несравнимо большим объемом информации о стоимости тех или иных работ, и может помочь уменьшить расходы на разработку . Это в Америке разработчик может сказать издателю: «мне нужно два с половиной года и два с половиной миллиона», а на вопрос: «почему столько?», ответить: «год работы стоит миллион, два с половиной года – два с половиной миллиона». У нас и в Европе такой фокус не пройдет . [>]
Как же составлять смету . [>] Учитывая вышесказанное, смета может содержать все , что нужно разработчику, чтобы успешно выполнить разработку проекта. Поэтому включать в нее можно все, что угодно. Всего одно «но» – если проект в сумме окажется чересчур дорогим – от него откажутся , возможно, даже до рассмотрения сметы (на первом этапе). [>]
Правильную смету можно представить в виде таблицы , где колонки – это, например, месяцы предполагаемой разработки, а строки – предполагаемые расходы. [>]
Расходы нужно разделить на две группы : единовременные и регулярные . Внутри этих групп формируются подгруппы по типам расходов. К единовременным расходам относятся, например, расходы на покупку или обновление техники , лицензирование сторонних технологий , привлечение третьих фирм на определенные работы (озвучка, мокап). К регулярным затратам относятся – аренда , операционные расходы (связь, интернет, канцелярия, расходные материалы) и оплата труда сотрудников . Что касается оплаты труда сотрудников. Не думайте, что нам интересно, сколько получает каждый отдельно взятый сотрудник разработчика. Вполне можно приводить обезличенные данные . Например, программисты – 3 человека – фонд оплаты труда столько-то , художники – 5 – фонд оплаты труда столько-то, ведущий программист , сценарист и т.д. Далее сводятся итоги по группам , помесячно , общие , добавляются налоги , которые разработчик, конечно же, платит, и получается вполне приличный предмет для разговора с издателем . [>]
Следующая задача – план работ . [>] Из грамотного предварительного дизайн-документ а план работ формируется достаточно легко . Создание необходимых для игры ресурсов группируется по некоторому принципу и раскладывается на временной линии . Группировку правильно осуществлять с привязкой к структуре игры , например - все материалы, относящиеся к определенной части (уровню) игры . [>]
Разбиение разработки на этапы необходимо для обеспечения контроля издателя за ходом разработки. Идея очевидна: процесс разработки разбивается на кусочки , закончив один из которых, разработчик сдает результат издателю, последний сравнивает полученное с тем, что было заявлено в плане работ и, если все хорошо, процесс повторяется . [>]
Поэтому, описание каждого этапа выглядит как перечисление задач , которыми занимается команда разработчика на протяжении этапа, и результатов , которые достигаются по его окончании. [>]
Оптимальная длина этапа – один месяц . По опыту, это позволяет издателю достаточно плотно участвовать в процессе разработки, понимая, как и куда идут дела . [>]
Оплата разработки напрямую привязана к этапам . Обычно очередной платеж происходит после принятия издателем очередного этапа . Впрочем, некоторым разработчикам бывает удобнее получать финансирование более крупными кусками и реже . Это не является проблемой. [>]
Еще один момент , который нужно учесть, составляя план работ. В подавляющем большинстве случаев для издателя важно привязать сдачу некоторых работ ко внешним событиям . Например, для проектов, приближающихся к определенной стадии, чрезвычайно важно иметь текущую версию к моменту начала очередной выставки E3 или ECTS. Возможно, для этого придется перекроить план. Имейте это в виду. В общем, в итоге, все описанное должно вылиться в план работ , который будет включать этапы разработки , контрольные точки и план платежей . Если все это имеется и согласовано , у издателя достаточно материалов и оснований для составления и подписания договора . [>]
Если есть какие-то вопросы , я готов ответить на них. Если нет – спасибо за внимание .
![Как продать издателю свою игру? Правильное оформление и подача материалов по проекту Косенко Роман, менеджер по внешним проектам, [email_address] КОНФЕРЕНЦИЯ РАЗРАБОТЧИКОВ КОМПЬЮТЕРНЫХ ИГР 21-22 марта 2003 года](https://image.slidesharecdn.com/random-100301025638-phpapp01/85/-1-320.jpg)
