Тех.задание, которое, мы для себя в подавляющем большинстве случаев разрабатываем сами, и которое заказчик лишь правит и утверждает, несколько отличается от концепт-документа, о котором пишет Кларк Олдрич. У нас концепция, как правило, - это просто два-три предложения, в которых мы кратко описываем, на каком сюжете и в каком формате будет происходить подача учебного материала и плюс к этому описанию небольшое демо. Об этом уже писалось здесь, не буду повторяться. Если же наша игровая концепция и демо заказчика устраивает, то мы, имея на руках: 1) объем исходного учебного материала, 2) сложность сюжета; 3) выбранный заказчиком способ реализации, калькулируем стоимость разработки, которая практически всегда заказчика устраивает (кто же не захочет получить "серьезную игру" фактически по цене обычного электронного курса? :) После чего мы садимся и начинаем писать ТЗ.
Так как мы с заказчиком, как правило, заключаем общий договор на разработку электронных курсов, а реализуемые проекты оформляем отдельными доп.соглашениями, то ТЗ является первым приложением к доп.соглашению, а второе приложение к договору - календарный план в виде диаграммы Гантта, содержащий конкретный состав работ на каждом этапе, сроки, контрольные точки и ответственных за каждый этап. Общий объем всего документа (доп.соглашение с приложениями) - 12-16 листов. Содержание нашего ТЗ включает в себя 14 разделов. Предлагаю описание некоторых их них.
1. Краткое описание истории, положенной в основу курса
Этот раздел ТЗ содержит историю, сюжет которой является основой, "веревкой", на которую нанизываются "бусины" учебного материала. Придумывание сюжета игры, который потом развернется в сценарий и геймплей, - самая сложная и творческая часть нашей работы. В этом же разделе ТЗ содержится краткое описание основных миссий, которые игроку необходимо будет пройти.
8. Технические характеристики курса
Здесь описываются основные технические характеристики учебного курса:
- используемый браузер и, при необходимости, плеер,
- задаваемые размеры экрана,
- положение камеры (например: "Вид на виртуальный офис: Сцены 1 и 3 - от 3 лица (из-за спины виртуального персонажа), Сцена 2 – от 1 лица (глазами виртуального персонажа)";
- требования к озвучиванию;
- формат SCORM, в котором будут передаваться данные в LMS и т.д.
Естественно, что это самый важный раздел всего тех.задания, который заказчик внимательней всего читает и в который он вносит больше всего исправлений. До утверждения ТЗ исправления в этот раздел могут вноситься до 5-6 раз и больше. И это понятно. Пока вы предлагаете заказчику концепт, игра для него еще "в тумане", он очень смутно видит только ее общие очертания, в основном полагается на вашу экспертность и лишь надеется: "Да, это, должно быть, будет здорово!" Пока еще он точно не представляет себе, как это все будет устроено, двигаться и достигать поставленной цели.
А когда вы выкладываете перед ним ясным и четким языком изложенное описание того, как и что будет происходить на каждом уровне игры или симуляции, что должен будет делать игрок, и что будет происходить в результате этих его действий, то тогда-то игра и материализуется в глазах заказчика, и теперь вашей основной задачей будет попытаться как-то остановить неудержимую мощь его разбуженных фантазий. Потому что на этом этапе заказчик наконец-то реально понимает, что ему нужно и... начинает творить!
Ну а вы должны будете умудриться втиснуть все это творчество в прокрустово ложе ваших сроков и бюджетов. Так что не стесняйтесь мягко время от времени напоминать заказчику, что изначально калькулировался все-таки ваш вариант представления этой игры, и, если заказчик хочет получить в игре дополнительные фичи, то это вовсе не вопрос, но эти фичи должны быть дополнительно оплачены. В результате, я уверена, вы совместно обязательно найдете какой-то компромиссный вариант, в котором и пожелания заказчика будут учтены, и ваша заложенная рентабельность не сильно упадет :) У нас, во всяком случае, так и получается.
Что включается в этот раздел. Для каждого уровня описываются: 1) цель уровня (миссия игрока), 2) темы учебного материала - а) переводимые в геймплей и b) включаемые в игру как дополнение, 3) подробный геймплей уровня.
12. Интерфейс
В данном разделе вы подробно описываете все элементы интерфейса - что означает каждый элемент, как он выглядит и какой функционал к нему привязан.
В конце раздела не забудьте упомянуть, что: "...в ходе написания сценария могут потребоваться дополнительные функции, не описанные в данном ТЗ. В этом с случае по согласованию с Заказчиком в интерфейс Курса могут быть включены дополнительные элементы, панели и кнопки..." Ну или что-то в этом духе. В общем, оставьте себе некоторое пространство для отступления, так как абсолютно все в начале проекта учесть невозможно, а подписанное ТЗ весьма сильно свяжет вам руки. Так что постарайтесь прописать документ как можно детальнее.
После написания и утверждения ТЗ у заказчика начинается второй этап разработки - написание сценария. Поговорим об этом в следующий раз.
См.также:
- Психологическая модель геймплея как обучающей деятельности
- Плохой дизайн первого уровня симуляции – это провал всей симуляции
- Элементы игры: ложка сахара для помощи диабетику в гипогликемическом шоке
(c) http://www.premiumconsult.ru
0 коммент.:
Отправить комментарий