Читайте также:
|
Каждая новая команда сталкивается с проблемой написания Дизайн Документа. Это объясняется тем что ни у кого нет примера Сценария проекта, который дожил до стадии релиза да и вообще такие вещи обычно не лежат на виду посторонних, ведь в них идея проекта – а это уже объект авторского права.
Сценарий должен быть один – его должны видеть как издатели, так и в первую очередь команда. Почему нельзя сделать презентабельную версию для издателя, спросите вы – потому что нету смысла делать одно и то же 2 раза, а если вы хотите отличить «версию дизайн документа для издателя» рекламой, восхвалением и превосходствами вашей игры – уверяю Вас, это плохая идея. Издателю нужна информация об игре, ведь им решать на сколько ваша игра высокотехнологична и стоит ли вкладываться в вашу команду. И расписывать больше чем вы планируете сделать – тоже не советую, потому что издатель ждёт от вас именно того, что вы заявили о своём проекте и не меньше.
Издателю нужно убедится в серьёзности и продуманности вашего плана. Грубо говоря осознаёте ли Вы что собираетесь делать? По этому не стоит в одном дизайн документе писать о том какая у вас хорошая и продвинутая физика и как реалистично будит прорисовываться мир, когда в другом ДД у Вас написаны ваши реальные цели с и задачи.
Вообще-то издателю нужно предоставить два документа – один из них дизайн документ, а второй – краткий перечень достоинств вашей игры. Второй документ как правило рекламирует проект в глазах издателя, но перебарщивать с голословными заявлениями и длинными описаниями не стоит. Этот документ, как правило краток и лаконичен. Его объём не должен превышать трёх страниц, а содержание должно поверхностно показать игру, обычно пишется название игры, жанровая принадлежность, какими именно качествами игра может заинтересовать и почему купят именно эту игру – туту можно тонко намекнуть на успех похожего проекта. Обязательно должна быть информация о сроках реализации и о стоимости разработки. Кстати, о сроках разработки – это очень больная тема особенно среди отечественного игростроя. Сроки разработки вы можете определить по объему работы, количеству разработчиков, возможных изменениях и отклонениях от ДД и другие форс-мажорные обстоятельства. Поскольку вы новички и есть много задач с которыми вы не сталкивались и будьте уверены что по ходу разработки столкнётесь ни один десяток раз и по этому берите в запас как минимум 30% больше времени.
Затем укажите ваше портфолио, в случае если это ваш первый проект, который не стыдно показать – укажите на демоверсию. Дальше можете перечислить все численные и другие превосходства.
От этого документа многое зависит, ведь если издателю не понравится – вероятность прочтения полного Дизайн Документа резко упадёт. Отнеситесь к этому серьёзно.
Ходят слухи что если предоставить хороший дизайн документ издателю, то он сразу же подпишет с вами контракт – это не так. Даже если у Вас есть чётко сформулированная идея, обречённая на успех - издателю необходимо оценить возможности вашей команды. Поэтому сделайте демо-версию и прихватите её с собой.
Этап 1 - Концепция
Текстово-графическое описание ключевого замысла проекта.
Может быть практически чем угодно от одной фразы или набора фич, до полноценных коммерческих предложений, с предполагаемыми прибылями, альбомами арта и т.п. Сильно зависит от необходимости привлечения капитала и трудовых ресурсов. Друзяки пойдут и за фразу или набор фич. Взять 100 миллионов евро надо будет писать огромные пакеты документов, со статистикой почему это выстрелит, анализом спроса, положения на рынке и т.п.
Объем документации: от 1 строки, до сотен страниц. Содержит в себе в основном описание почему вообще стоит этим заниматься.
Повторение этапа: обычно концепция или отметается, или сразу переходят к этапу 2.
Этап 2 - Прототип
Проверка концепции, чаще всего заканчивается провалом вне зависимости от объема первоначальных инвестиций.
Друзьям надоедает или им кажется что идея говно, инвесторы уходят в нефтянку и т.п. Прототип оказывается совершенно скучной жвачкой или не удается достичь никакого интересного вижена. Для создания прототипа используется все что можно и нельзя, так как прототип не продают, а чисто оценить идею. Иногда используется разработка прототипа с нуля - идиотами и слишком богатыми.
Объем документации: от 2-3 страниц, до сотен страниц. Содержит в себе описание ключевых игровых моментов, предназначен чтобы убедиться, что овчинка выделки стоит.
Повторение этапа: обычно прототип или показывает участникам проекта что можно делать или после нескольких итераций (до полугода), проект благополучно умирает. Есть уники, которые всю жизнь делают один и тот же прототип...
Этап 3 - Разработка
Создание игры, по отработанному вижену. Разработчик повозившись с прототипом понимает какая у него выйдет игра. И или пишется план разработки, или (чаще всего), делается все путем "вилами на воде нарисуем -- что будет дальше". Разработка проходит в несколько подэтапов, когда инвестор или сами разработчики оценивают получается у них что-то вменяемое или нет, и что с этим делать.
Объем документации: от 2-3 страниц, до сотен страниц. Содержит в себе описание всего того что понадобилось команде для разработки текущей итерации (описание арта, игрового процесса, интерфейса и т.п.).
Повторение этапа: Сильно зависит от типа и объема финансирования проекта и прибыльности текущей итерации (для онлайна).
Этап 4 - Полишинг
Доводка отдельного функционала и арта до состояния "можно продавать", для оффлайновых проектов обычно полишинг героически откладывается на пред-релизные кранчи. Для вменяемых онлайновых проектов, делается проще - реализуется функционал в минимально продажном виде, если игроки по статистике "отрабатывают" заложенное, то его дорабатывают - ставят в параллельный полишинг со следующей итерацией разработки. А если нет, то этой фичи после обновления не будет.
Объем документации: от 2-3 страниц, до сотен страниц.
Повторение этапа: повторяется после каждого нового функционала для онлайна 1-2 раза. Для оффлайновых проектов, обычно смешивается с доработкой проекта вообще и поэтому, особенно при отсутствии четких планов может продолжаться очень долго (не итеративно, а скорее хаотично).
Этап 5 - Релиз
Заработок на проекте. Для оффлайнового проекта продажи, для онлайнового - "выход в ОБТ", то есть игроки нагоняются и платить они могут. Приложение выглядит цельно, отдаленно похоже на концепт (обычно) или полностью отрабатывает фокус (редко). Но от соответствия проекта концепции его успех практически не зависит. Да и вообще от разработки коммерческий успех проекта зависит процентов на 50-40, при условии, что в разработке не было допущено откровенных ляпов.
Объем документации: Описание релиза, мануал, сайт игры.
Повторение этапа: Для оффлайна - бывает один раз. Сейчас часто релизят скачиваемые дополнения к проекту (иногда - платные) и патчи. Для онлайновых проектов, в зависимости от сложности разработки, релизы бывают в диапазоне от 2х недель, до полугода и реже.
Этап 6 - Поддержка
Помощь игрокам остаться в игре. Для оффлайна - пост-релизный этап, когда делается все чтобы игрок и дальше продвигал игру, среди друзей или в мультиплеере. Для онлайна - параллельный разработке, полишингу и релизам этап.
Объем документации: Инструкции, сайт поддержки и т.п.
Дата добавления: 2015-09-11; просмотров: 23 | Поможем написать вашу работу | Нарушение авторских прав |
| <== предыдущая лекция | | | следующая лекция ==> |
| Этапы разработки компьютерной игры. | | | Философия |