close

Вход

Забыли?

вход по аккаунту

Румянцева Юлия Владимировна. Создание технической документации для проекта разработки приложения виртуальной реальности

код для вставки
0
1
2
3
АННОТАЦИЯ
ВКР 56 с., 18 рис., 2 табл., 7 источников, 2 прил.
ТЕХНИЧЕСКАЯ
ДОКУМЕНТАЦИЯ,
ПРОЦЕСС
ДОКУМЕНТИРОВАНИЯ, ТЕХНИЧЕСКОЕ ЗАДАНИЕ, ВИРТУАЛЬНАЯ
РЕАЛЬНОСТЬ, РАЗРАБОТКА ПРИЛОЖЕНИЯ.
Выпускная
квалификационная
работа
посвящена
созданию
технической документации проекта разработки приложения виртуальной
реальности.
В первой главе выпускной квалификационной работы приведен
анализ
технологии
виртуальной
реальности,
анализ
технической
документации и процесса документирования рассматриваемого проекта
разработки приложения виртуальной реальности.
Во второй главе выпускной квалификационной работы выявлены
ошибки в исходном процессе документирования, сформированы требования
к созданию технической документации, на основе которых выбран способ
документирования, разработан итоговый перечень проектных технических
документов, разработана техническая документация по проекту разработки
приложения виртуальной реальности, описанная на примере технического
задания.
Графическая часть выпускной квалификационной работы включает
иллюстрации, таблицы, которые объединены в презентацию PowerPoint.
4
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
5
1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
7
1.1 Анализ технологии виртуальной реальности
1.2 Анализ проекта разработки приложения виртуальной реальности
7
14
2 СОЗДАНИЕ ТЕХНИЧЕСКОЙ ДОКУМЕНТАЦИИ ПРОЕКТА РАЗРАБОТКИ
ПРИЛОЖЕНИЯ ВИРТУАЛЬНОЙ РЕАЛЬНОСТИ
21
2.1 Выявление ошибок в процессе документирования
21
2.2 Формирование требований к созданию документации
24
2.3 Выбор способа документирования
27
2.4 Выбор итогового перечня документов
31
2.5 Разработка технической документации
35
ЗАКЛЮЧЕНИЕ
55
СПИСОК ЛИТЕРАТУРЫ
56
ПРИЛОЖЕНИЕ 1. ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ФРАГМЕНТ
58
ПРИЛОЖЕНИЕ 2. ДИЗАЙН ДОКУМЕНТ
76
УДОСТОВЕРЯЮЩИЙ ЛИСТ № 140204/п
Ошибка! Закладка не определена.
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА ДОКУМЕНТА НА
ЭЛЕКТРОННОМ НОСИТЕЛЕ
Ошибка! Закладка не определена.
5
ВВЕДЕНИЕ
Виртуальная реальность (VR) – суперсовременная и многофункциональная
технология, которая уже применяется в значительном количестве сфер
деятельности. Это совершенно новый формат реализации привычной активности
человека.
Все большее количество IT-компаний внедряют технологию виртуальной
реальности в стек используемых ими технологий. Зачастую ими реализуются
интересные
и
технически
сложные
проекты,
требующие
четкого
документирования.
Как и каждая технология, виртуальная реальность имеет свои особенности
и, соответственно, требует адаптации привычной программной документации под
новый формат, учитывающий все нюансы.
Так как сама технология стала стремительно развиваться относительно
недавно, идей и примеров такой успешной адаптации достаточно немного.
Поэтому IT-компании, внедряющие технологию виртуальной реальности в свои
приложения не ограничены в творчестве при документировании, и основываются
лишь на уже существующих стандартах и личном опыте.
Документирование приложений рассматриваемого типа регламентирует
ГОСТ 19 (Единая система программной документации). Важно отметить, что
стандарт универсален и гибок в использовании. Документы, которые ЕСПД
предлагает к использованию, удобно адаптировать в том числе и для разработки
графических приложений с использованием технологии виртуальной реальности.
Грамотно созданная программная документация – это залог успеха
разрабатываемого программного обеспечения. Поэтому цель дипломной работы –
разработать техническую документацию, описывающую и формализующую
задачи поставленные перед командой при разработке приложения виртуальной
реальности для ООО “Диджитал-агентства “Синапс”.
6
Рассматриваемый проект – графический многопользовательский квест
виртуальной реальности “Сокровища горного короля”, разрабатываемый для
ООО “БФ Геймс”. Ознакомиться с рассматриваемым приложением-аттракционом
можно на сайте компании заказчика: https://www.bf-vr.ru/.
Данный
проект
является
первым
крупным
проектом
виртуальной
реальности для компании. Он технически сложен и обладает большим
количеством
деталей
документирование
и
необходимо
нюансов.
для
Соответственно,
успешной
реализации
качественное
и
внедрения
рассматриваемого программного обеспечения.
В ходе выполнения анализа предстоящей работы, были сформулированы
задачи дипломной работы:
1. Проанализировать технологию виртуальной реальности.
2. Проанализировать
проект
разработки
приложения
виртуальной
реальности.
3. Выявить ошибки в исходном процессе документирования.
4. Сформировать требования к документации.
5. Изучить способы документирования проекта.
6. Выбрать способ документирования проекта.
7. Создать
программную
реальности.
документацию
для
проекта
виртуальной
7
1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Анализ технологии виртуальной реальности
Под виртуальной реальностью подразумевают созданный техническими
средствами мир, с которым человек может взаимодействовать, полностью в него
погружаясь.
Виртуальная реальность (VR, от лат. virtus – возможный, потенциальный и
realis – существующий, действительный; англ. virtual reality, VR) – это мир, не
существующий на самом деле, созданный с помощью технических средств
искусственно. С помощью систем и инструментов виртуальной реальности
человек, погружаясь в нее, может совершать те же действия, что и в реальной
жизни, взаимодействовать с окружающим миром. Кроме того, благодаря
технологии виртуальной реальности человек может получить опыт, который в
реальной жизни получить невозможно. Говоря проще, VR – это смоделированная
реальность,
в
которой
создается
иллюзия
присутствия
пользователя
в
искусственном мире, его взаимодействия с предметами и объектами этого мира с
помощью органов чувств – ушей (слух), глаз (зрение), кожи (осязание) и др.
Виртуальную
реальность
еще
называют
искусственной,
электронной,
компьютерной реальностью.
Виртуальная реальность бывает нескольких типов:
 пассивная VR – это лишь изображение и его сопровождение звуком,
человек в такой VR ничем не управляет;
 обследуемая VR – в такой VR возможен ограниченный выбор сценариев
звука и изображения, а также действий человека;
 интерактивная VR – пользователь сам выбирает сценарии, управляет
такой VR.
Полное погружение в виртуальную реальность и взаимодействие с ее
объектами достигается только при использовании специальных устройств.
8
Такие
устройства,
которые
обеспечивают
полное
погружение
в
виртуальную реальность и имитируют взаимодействие человека с ней с помощью
всех органов чувств (глаза (зрение), уши (слух), язык (вкус), нос (обоняние), кожа
(осязание), вестибулярный аппарат (чувство равновесия и положения в
пространстве, ускорение, ощущение веса)), называют системами VR (см. рис.).
Рассмотрим указанные системы подробнее.
Указанные системы организуются на практике при помощи различных
девайсов (VR-аксессуаров).
VR-аксессуары – это оборудование, благодаря которому осуществляется
погружение в созданный техническими средствами мир.
2017 год называют годом аксессуаров для интерактивных приложений
любого рода. Например, на рынке VR-оборудования появилось все – от костюмов
с датчиками до тренажеров и винтовок для шутеров виртуальной реальности.
Обратимся к VR системам, рассмотренным на рисунке 1.
Системы изображения виртуальной реальности:
1. К системам изображения, с помощью которых формируется и выводится
изображение в виртуальной реальности, относятся шлемы и очки VR, а также
специальные мониторы.
В шлеме и очках виртуальной реальности есть один или несколько дисплеев для
вывода изображения, отдельно для левого и правого глаза, система линз,
корректирующая геометрию изображения, а также система для отслеживания
положения устройства в пространстве. Виртуальный ретинальный монитор
передает изображение прямо на сетчатку глаза, оно как бы висит перед глазами, в
воздухе. Это скорее ближе к дополненной реальности, потому что происходит
наложение: элементы виртуальной реальности накладываются на объекты
реального мира. Но при соблюдении определенных условий (например, почти
полное отсутствие света) возможен эффект присутствия в VR.
2. Системы звука виртуальной реальности. Ориентирование пользователя
при помощи слуха в виртуальной реальности обеспечивается современными
9
Рисунок 1 – Системы виртуальной реальности
10
акустическими системами, благодаря которым осуществляется локализация
источников звука. Использование различных технологий, которые имитируют
звук в реальном мире (отражение звука, прохождение его через препятствия и
др.), создает эффект присутствия человека, звук максимально приближен к звукам
в реальном мире.
3. Системы имитации тактильных ощущений и управления виртуальной
реальности.
К системам имитации тактильных ощущений относятся
устройства, называемые Heptics force feedback (устройства с обратной связью).
Управление в VR происходит контактным и бесконтактным способами. При
контактном пользователь использует «заменители» клавиатуры и мыши – руль,
педали, пистолет с функцией целеуказателя. При бесконтактном способе
управление осуществляется джойстиками, перчатками виртуальной реальности, а
также происходит отслеживание положений рук с помощью нескольких камер.
Также для управления используют костюм виртуальной реальности, частью
которого являются и перчатки, который отслеживает положение тела в
пространстве, а может передавать ощущения тактильного контакта, изменения
температуры. В рассматриваемом проекте управление осуществляется с помощью
контроллеров Oculus Touch.
4. Системы
прямого
подключения
к
нервной
системе.
Такие системы (датчики) передают данные непосредственно на нервные
окончания и напрямую в мозг. Но они очень дорогостоящие и не в полной мере
обеспечивают качество передачи данных для полного погружения в VR.
Это основные аксессуары для технологии виртуальной реальности. Но
рынок аксессуаров не ограничивается только вышеперечисленными системами.
Компании по производства VR-оборудования очень быстро совершенствуют и
выпускают новые системы для более глубокого погружения. С использование
такого количества технических средств для виртуальной реальности сферы и
способы применения VR ограничиваются практически только воображением
создателя приложения.
11
В ходе анализа технологии были рассмотрены популярные сейчас кейсы
виртуальной реальности.
Первоначально технологии виртуальной реальности использовались лишь в
военных целях – для тренировки солдат, имитации боев, но в последнее время с
успехом применяется в различных областях.
Согласно статистике, сейчас большую часть VR-индустрии занимают
игровые приложения и квесты виртуальной реальности.
Однако процент появления неигровых приложений на VR-рынке с каждым
годом растет. Преимущественно создаются приложения для сфер деятельности,
указанных в таблице 1.
Таблица 1 – Сферы деятельности, популярные для создания VR-приложений
Сфера деятельности
Популярные кейсы
1
2
3D визуализации и экскурсии
Такие
приложения
популярностью
музеи,
в
пользуются
следующих
гостиницы,
сферах:
концертный
зал,
конференции, магазины, рестораны
Реклама
Создание бренда компаний (интерактивные
визитки,
VR/AR-стенды
с
продуктами
компании)
Образование
Безопасная симуляция учебных процессов
(проведение
предметам),
(путешествия,
опытов
по
практическим
интерактивное
обучение
взаимодействие
различными объектами)
с
12
Продолжение таблицы Таблица 1
1
2
Медицина
Визуализация хирургических процессов,
состояния
человека
(МРТ,
УЗИ),
микрохирургия
Производство
Визуализация
чертежей,
симуляция
рабочих процессов
Моделирование
Приложения для дизайнеров, интерьеры,
скульптуры
Симуляторы
Приложения
для
тренировки
профессиональных навыков (управление
различными системами, транспортом)
Архитектура
Воссоздание
будущих
зданий
и
их
элементов, моделирование интерьера
Рассмотрим
популярные
устройства,
поддерживающие
технологию
виртуальной реальности.
Одной из самых популярных компаний на рынке девайсов для виртуальной
реальности является компания Oculus. Они производят широкий спектр VRаксессуаров.
Рассматривая проект квеста виртуальной реальности, остановимся на
используемых там устройствах.
Шлем виртуальной реальности Oculus Rift. При некорректном контенте
приложения он обеспечивает полное погружение в виртуальную реальность. Это
происходит за счет двух экранов, настроенных под восприятие человеческим
13
глазом как картины реального мира, звуковой системой, позволяющей передавать
реалистичные звуки и синхронизированной с экранами, а также благодаря многим
другим особенностям.
Также интересно рассмотреть контроллеры Oculus Touch. Все кнопки
контроллеров указаны на рисунке 2.
Рисунок 2 – Контроллер Oculus Touch
14
Такой дизайн удобен для пользователя. На рисунке 2 показаны кнопки
контроллера:
 кнопка «Thumbstick» часто используется в качестве джойстика и привычна
по управлению многим пользователям, державшим в руках обычные джойстики;
 кнопка «Menu Button» – в элементах интерфейса означает выход в меню,
либо используется произвольно;
 кнопка «Select» – используется для выбора объекта интерфейса, либо
исходя из концепта приложения или пожеланий Заказчика;
 кнопка «Back», если это требуется в приложении, означает выход на
предыдущий экран;
 «Thumbstick» – сенсорная кнопка, применение которой выбирается
разработчиком произвольно по необходимости;
 «Trigger» – одна из наиболее используемых кнопок в приложениях
виртуальной
реальности.
Обычно
используется
как
аналог
действий
указательного пальца в реальности;
 «Grip Button» – также одна из наиболее часто используемых кнопок. В
основном используется для хватания предметов;
 комбинация кнопок «Trigger» и «Grip Button» обычно означает сжатие
кулака.
Функционал кнопок «Trigger» и «Grep Button» еще больше погружает
пользователя в виртуальный мир за счет аналогий управления с привычными
действиями в реальном мире.
1.2 Анализ проекта разработки приложения виртуальной реальности
В процессе выполнения дипломной работы был исследован проект
разработки
приложения
виртуальной
реальности
компании
«Синапс»
«Сокровища горного короля» под рабочим названием «Заказ – Квест VR».
15
Следует отметить, что рассматриваемый проект – первый крупный комплексный
проект для компании. Поэтому к моменту принятия проекта в работу процессы
создания технической документации по проекту, а также требования для нее еще
не были выстроены.
Заказ подразумевал следующую задачу команды разработки – создание
программного обеспечения для проведения квеста в виртуальной реальности.
Работа над проектом квеста должна быть выполнена «под ключ», т.е. должна
быть произведена комплексная разработка всех частей проекта.
Работы, необходимые работы для реализации данного приложения
показаны на рисунке 3.
Как видно из рисунка 3, для реализации рассматриваемого проекта
требуются различные специалисты:
 руководитель проекта;
 архитектор;
 программисты;
 3D-моделлер;
 2D-дизайнер;
 звукорежиссер.
Ощутимая сложность проекта, большое количество необходимых специалистов и
взаимодействий между ними, наличие значительного количества технических и
сюжетных нюансов проекта повысили требования к технической документации.
Она должна была максимально отражать заявленные заказчиком требования к
программному
обеспечению
и
быть
доступной
каждому
специалисту,
работающему над проектом.
В качестве исходных материалов заказчиком был предоставлен концепт,
содержащий общее представление о разрабатываемом продукте, описательные
фрагменты с примерами графики, а также сценарий квеста.
16
Рисунок 3 – Разработка приложения виртуальной реальности
17
Концепт содержал в себе следующие разделы:
 основная задача;
 описание технической стороны проекта;
 задачи разработчиков;
 сюжетная составляющая проекта;
 дополнения;
 триггеры и предупреждения;
 техническое оснащение;
 термины;
 этапы разработки;
 дополнительные сведения.
Концепт был детально изучен и казался достаточно ёмким и не требующим
серьезной переработки. Беря во внимание установленные сроки для реализации
программного обеспечения, было принято решение доработки концепта путем
уточнения деталей требований. Получившийся документ был принят в разработку
в качестве проектной технической документации.
Процесс доработки концепта Заказчика до проектной программной
документации перед началом разработки программного обеспечения представлен
на рисунке 4 [5].
На первый взгляд концепт казался достаточно емким и не требующим
серьезной переработки, а лишь уточнения деталей.
В связи с этим была произведена доработка текущего концепта до
документа, используемого в качестве технической документации. Процесс
доработки
представлен
на
рисунке
последовательностей на рисунке 4.
ниже
с
помощью
диаграммы
18
Рисунок 4 – Диаграмма последовательностей процесса доработки концепта
19
Рассмотрим детальнее процессы, которые иллюстрирует диаграмма.
Для хранения и доработки концепта, ставшего впоследствии программной
документацией, был использован сервис работы с документами «Google
Docs». С помощью него были выполнены следующие действия:
 изучение концепта;
 выявление неясных требований;
 направление
вопросов
от
специалистов
компании
Заказчику
(специалистами комментировались неясные части концепта);
 направление ответов Заказчика на вопросы специалистов компании
(путем ответного комментирования документа концепта в Google Docs);
 доработка концепта с учетом новых требований.
Коммуникация с Заказчиком для выявления неуказанных требований, а
также согласование и утверждение внесенных изменений и доработок в концепт
проводились в форме переписки в Skype.
В представленном Заказчиком концепте планы игровых локаций были
нарисованы от руки с некорректным метражом, с нереальным расположением
объектов. Поэтому был осуществлен перерасчет метража и визуализация планов с
помощью инструмента «Microsoft Visio».
Также на доработанных планах локаций было предложено новое
расположение игровых элементов. Эти правки были также согласованы с
Заказчиком в форме переписки, после чего планы были добавлены в
программную документацию.
После того, как программная документация считалась доработанной и была
утверждена Заказчиком, проект перешел в стадию разработки.
После этого в документацию были добавлены конкретизирующие разделы,
такие как:
 «Функциональные требования к игровым элементам»;
 «Список ресурсов».
20
Данные разделы не противоречили утвержденному документу, а лишь
детальнее описывали уже зафиксированные требования.
Первый из добавленных разделов содержал в себе список интерактивных
предметов, а также возможности взаимодействия с ними.
Раздел «Список ресурсов» включал перечень графических и звуковых
ресурсов по локациям.
Указанные дополнения к концепту помогли избежать ряда ошибок при
работе
над
проектом
квеста
виртуальной
реальности.
Сформированный
документ был принят в работу как проектная программная документация по
разработке приложения.
Однако, как выяснилось в ходе работы над проектом, разработанного
документа оказалось недостаточно для работы над программным обеспечением
такого уровня сложности. Отсутствие знаний и опыта в разработке программной
документации привело к упущению значительной части критически важных для
разработки и корректной работы приложения аспектов.
Таким образом, установленные сроки и требования не соблюдались в ходе
первой части работ над проектом «Заказ – Квест VR». Это привело к ускоренной
работе, появлению багов в приложениях и, как следствие, к потере лояльности
Заказчика.
Для успешного завершения проекта было принято решение о реорганизации
процессов и документирования в компании и, в том числе, в текущем проекте. За
этим
последовали
существенные
изменениям
в
уже
спроектированной
архитектуре программного обеспечения на позднем этапе разработки, правке
значительного количества задач и, как результат, передвижению сроков проекта.
21
2 СОЗДАНИЕ ТЕХНИЧЕСКОЙ ДОКУМЕНТАЦИИ ПРОЕКТА
РАЗРАБОТКИ ПРИЛОЖЕНИЯ ВИРТУАЛЬНОЙ РЕАЛЬНОСТИ
2.1 Выявление ошибок в процессе документирования
После поверхностного рассмотрения проекта разработки приложений
виртуальной реальности был проведен аудит программной документации и
самого процесса документирования. В результате был выявлен ряд ошибок,
которые и привели к сложившемуся кризису на проекте.
Общей причиной всех совершенных в ходе документирования ошибок
являлось, естественно, отсутствие сформированного процесса разработки в
компании для проектов уровня рассматриваемого.
Ошибки были классифицированы по пяти категориям:
1. Выбор специалистов для разработки программной документации.
2. Перечень документов и их содержание.
3. Последовательность создания проектных документов.
4. Коммуникация при составлении проектной документации.
5. Внесение изменений в документацию.
Все эти моменты тесно связаны между собой и зачастую пересекались при
разработке и использовании документации в ходе проекта.
Ниже данные категории ошибок рассмотрены подробнее.
Отсутствие
сформированного
процесса
разработки
программной
документации привело к непониманию, с чего начать работу над концептом
Заказчика. Из-за этого было принято поспешное решение приступить к
рассмотрению и правкам концепта всей командой от состава администрации
компании до разработчиков. Как результат было получено значительное
количество интересных, но при этом требующих сложной реализации и,
соответственно, дополнительного времени идей. Эти дополнения были оценены и
приняты Заказчиком. Проблема состояла в том, что бюджет проекта уже был
22
фиксирован и не предусматривал такие дополнения. Таким образом, количество
работ по проекту возросло примерно на 25%.
Вторая ошибка – неверно выбранный перечень документов и их
содержание. На рисунке 5 представлены все документы, созданные за время
работы над проектом до внедрения новой документации. Также приведена
детализация составных документов по разделам.
Основными проблемами в данной категории являются [4]:
 концентрация избыточной, но при этом недостаточной информации по
проекту в техническом задании;
 создание большого количества отдельных технических заданий на
моделирование каждого объекта, и как результат, дублирование информации и
отсутствие порядка;
 написание технического задание на моделирование в неверном формате,
излишне лишающем моделлера возможности создать графику согласно его
видению;
 составление
соответствующих
списка
единой
графики
стилистике
и
поиска
игры.
отдельных
Поиск
этих
ассетов,
не
материалов
руководителем проекта.
Третья ошибка затрагивает один из важнейших аспектов управления
проектом – коммуникацию с Заказчиком. Способ выявления требований – с
помощью комментирования концепта в Google Docs всей командой разработки
ведет к ряду абсолютно нежелательных моментов.
Во-первых, комментирование позволят обнаружить контакт комментатора
(электронную почту). Это может привести к личной связи Заказчика с командой
разработки и последствиям от нарушения процесса разработки до перевода
проекта Заказчиком от разработки в компании на разработку конкретным
программистом. В особых случаях это может грозить переходом сотрудника из
компании на сторону заказчика.
23
Рисунок 5 – Первоначальная документация по проекту
24
Во-вторых, коммуникация всей команды разработки может привести к
потере лояльности клиента. Коммуницировать с Заказчиком – прямая обязанность
руководителя проекта. Остальные сотрудники не имеют возможности отвлекаться
от работы на выстраивание грамотной коммуникации.
В-третьих, подобные отвлечения грозят вырыванием разработчиков из
рабочего контекста и ухудшению качества выполнения задач.
Последняя из выделенных категорий ошибок касается внесения правок в
существующую документацию. В рассматриваемом проекте ведение документа с
изменениями
к
техническому
заданию
было
регламентировано
только
перепиской, что не может выступать в качестве основания для изменения. Это
привело в ряду конфликтов с Заказчиком в ходе и при завершении проекта
разработки.
Собранный перечень ошибок, совершенных за время документирования и
использования документации ясно показал необходимость разработки требований
к технической проектной документации и процессу ее создания.
2.2 Формирование требований к созданию документации
На основе результатов проделанного аудита проекта «Заказ – Квест VR»
был сформирован список требований к технической документации. Он затронул
все аспекты проекта, в которых были допущены критические ошибки в ходе
документирования.
Требования, сформулированные для документирования, изображены на
рисунке 6.
25
Рисунок 6 – Требования к документированию
26
Ниже представлено детальное рассмотрение разработанных требований.
1. Создание технической документации должно проводиться конкретными
специалистами, а не всей командой разработки.
 Создание концептуальной части. Во время этого этапа происходит
выявление требований Заказчика, а также их формализация и распределение по
четким разделам. После этого обязательно проводится согласование расписанных
требований с заказчиком. Эта часть работы по документированию должна
выполняться руководителем проекта.
 Создание
формализованных
технической
требованиях
части.
Заказчика
При
сформулированных
происходит
дополнение
и
этих
требований техническими аспектами, а разрезе начального проектирования
программного обеспечения. Данный этап должен выполняться техническим
специалистом. Его роль может играть проектировщик, тимлид или разработчик в
зависимости от проекта.
2. Коммуникация с Заказчиком по документированию после передачи
проекта
руководителю
руководителя
проекта.
проектов
Ни
должна
один
другой
проводиться
сотрудник
только
не
от
должен
лица
вести
коммуникацию по ходу выполнения работ с Заказчиком. В случае необходимости
контакта с заказчиком, он осуществляется через руководителя проектов.
3. Внесение изменений должно быть подкреплено документально. Должен
быть выбран способ документального подкрепления согласованных с Заказчиком
изменений к технической документации. Изменения должны быть однозначно
описаны и приняты к исполнению только после подписания сторонами Заказчика
и Исполнителя соответствующего документа.
4. Одним из важнейших требований, указанных на рисунке 6 является
создание грамотно выбранного перечня документов. Этому вопросу посвящен
следующий
раздел
документирования».
данной
дипломной
работы:
«Выбор
способа
27
2.3 Выбор способа документирования
Для решения проблемы с непригодной для использования документацией
было принято решение обратиться к ГОСТу. Документация на программное
обеспечение регламентируется Единой системой программной документации
(ГОСТ 19). ЕСПД содержит в себе набор стандартов, применяемых при
разработке программного обеспечения.
Чтобы определить перечень документов, необходимый для проекта
разработки программного обеспечения с использованием технологии виртуальной
реальности
был
изучен
стандарт ГОСТ 19.101-77
«Виды
программ и
программных документов» и таблицы 2 и 3 указанного стандарта. Разработка
проектной документации, представленной в данных таблицах позволило бы
удовлетворить разработанным требованиям к документированию. Однако
создание всех документов было бы излишним в условиях проекта “Заказ – Квест
VR”.
Согласно таблице 4 ГОСТ 19.101-77 обязательными для оформления
являются лишь такие документы как «Спецификация» и «Текст программы».
Исходя из этого, при изучении ГОСТ 19.101-77 «Виды программ и программных
документов»
был
выделен
ряд
документов,
наиболее
подходящий
для
рассматриваемого проекта (см. таблицу 2).
В таблице указаны сначала два обязательных документа, а затем
документы, необходимые именно для рассматриваемого проекта.
Документ «Программа и методика испытаний» был выбран для разработки
с целью формализовать и спланировать процесс тестирования программного
обеспечения как на этапе разработки, так и при настройке приложений и сдаче
работ.
28
Таблица 2 – Программные документы, выбранные для реализации приложения
виртуальной реальности
Вид программного
Содержание программного документа
документа
Спецификация
Состав программы и документации на нее
Текст программы
Запись программы с необходимыми
комментариями
Программа и методика
Требования, подлежащие проверке при испытании
испытаний
программы, а также порядок и методы их контроля
Техническое задание
Назначение и область применения программы,
технические, технико-экономические и
специальные требования, предъявляемые к
программе, необходимые стадии и сроки
разработки, виды испытаний
Эксплуатационные
Сведения для обеспечения функционирования и
документы
эксплуатации программы
«Техническое задание» – основной документ рассматриваемого проекта.
Требования к нему описывает ГОСТ 19.201-78 [9]. И согласно пункту 1.4 ГОСТа,
в данный документ можно включать приложения. Для удовлетворения
сформированных ранее требований было принято решение о создании следующих
приложений к техническому заданию:
 приложение, содержащее описательную часть документации (стилистику
графики, окружение, эмоции, которые должны передаваться пользователю и т.д.);
 приложение требований к моделям и сценам (требования к графике),
необходимые для удобной интеграции графики в проект.
29
В качестве эксплуатационных документов были выбраны для реализации:
 формуляр (основные характеристики программы, комплектность и
сведения об эксплуатации программы);
 руководство оператора (введения для эксплуатации программы).
Формуляр позволит конкретизировать порядок работ и тем самым защитить
Исполнителя от дополнительной незаявленной ранее работы.
В рассматриваемом квесте предполагается работа оператора и создание
отдельного приложения для него. В связи с этим было принято решение для
описания работы оператора. Это также упростит тестирование приложения
оператора на стороне Заказчика.
Исследование комплекса Государственных стандартов ЕСПД помогло
первичном формировании структуры документов, а также их содержании.
Для получения представления о разработке технической документации
прикладного характера, а именно для приложений виртуальной реальности, был
также изучен опыт других компаний.
Хорошим примером в создании технической документации выступила
компания «GD Forge». Основное направление их работы – это разработка
приложений для игровой индустрии с использованием технологий виртуальной и
дополненной реальности. Также одной из предоставляемой ими услуг является
разработка проектной документации в том числе и для неигровых проектов.
Ниже описаны основные аспекты, которые показались полезными для
внедрения в разработку технической документации для проекта «Заказ – Квест
VR».
Основными проектными документами компании являются «Техническое
задание» и «Дизайн документ». Они существуют неразрывно для одного проекта,
но используются каждый для разных целей.
В
Техническом
задании
описываются
непосредственно для команды программистов:
 нефункциональные требования;
аспекты,
необходимые
30
 функциональные требования;
 игровая логика.
Все эти моменты прописываются четко, в виде пунктов и таблиц. Игровая
логика прописывается преимущественно с использованием глаголов. Все
описательные фрагменты в “Техническое задание” не входят. Техническое
задание прописано четко и для проекта средней сложности составляет не более 15
страниц.
Разделы, связанные с описанием сцен, скетчи, референсы, описания
визуализаций, визуальных эффектов, звуков и т.д. детально расписываются и
согласовываются в «Дизайн документ», он же «Game Design Document». Он
создается после создания и согласования “Технического задания”. Этот документ
не имеет жесткой фиксированной структуры и пишется в свободном стиле.
«Game Design Document» также не ограничен по объему: чем точнее будет
передана создаваемая атмосфера, ощущения пользователя от нее, эмоции,
которые должно вызывать приложение, тем удобнее и регламентированнее будет
работа нуждающихся в документе специалистов.
Документ создается для 3D-моделлеров, 2D-художников, звукорежиссеров
и других креативных специалистов, работающих над проектом приложения
виртуальной реальности.
При изучении анализа требований и последующем составлении документов
в ходе анализа и по его результатам также был изучен процесс, действующий в
IT-компании «Gramant». Компания не занимается разработкой приложений для
виртуальной реальности, но изучение состава ее документов и процесса их
создания может быть полезен для компании.
Специалисты Gramant создают целую серию документов. Полезными для
внедрения в рамках рассматриваемого проекта являются:
 «Концепция системы»;
 «Бизнес требования».
Рассмотрим каждый из этих документов подробнее.
31
Документ «Концепция системы» формируется на основе предварительного
интервью с Заказчиком. Это очень условный документ, в который входит лишь
формирование цели создания системы, ее границы и место в окружающем мире.
Документ «Бизнес-требования»
является продолжением работы
над
«Концепцией системы». Он создается после дальнейших выяснений требований
Заказчика. Появляется понимание, какие вопросы разрабатываемая система
должна решать, а также определяются разделы будущего технического задания и
их содержание.
Документы, которые создают другие компании для разработки своих
приложений, были адаптированы под разработку программного обеспечения
проекта «Заказ – Квест VR».
2.4 Выбор итогового перечня документов
После проделанной работы по изучению существующего стандарта и уже
применяемых идей других компаний, был сформирован итоговый список
технических документов для рассматриваемого проекта виртуальной реальности.
На основе полученной информации и опыта была сформирована структура
технической документации, удовлетворяющая выделенным ранее требованиям.
Разработанная структура изображена схематично на рисунке 7.
Часть документов, указанных на рисунке, представляются в классическом
виде по ЕСПД. Но некоторые адаптированы под разработку программного
обеспечения аналогичного приложениям рассматриваемого проекта.
Техническое задание должно содержать четкую структурированную
информацию, но необходимы и описательные разделы. Для этого было принято
решение о создании ряда приложений к Техническому заданию:
1. Приложение 1. Дизайн документ (рассмотренный выше документ,
позволяющий передать все описательные и эмоциональные аспекты, важные для
донесения до пользователя).
32
Рисунок 7 – Техническая документация
33
2. Приложение 2. Требования к графике (включает в себя технические
аспекты моделируемых графических элементов проекта и не ограничивающее
создателей графии в визуальном представлении).
Учитывая особенности работы с командой моделирования и композитором
на текущем проекте, были добавлены также и следующие приложения:
3. Приложение 3. Требования к звуку.
4. Неочевидным
моментом
также
является
поэтапная
разработка
Технического задания.
Она состоит из трех этапов, перетекающих из одного в другой, как показано
на рисунке. Первые два документа («Концепция системы» и «Бизнес требования»)
разрабатываются руководителем проекта и относятся к концептуальной части
разработки документации. Документ «Техническое задание» относится к
технической части разработки документации и появляется в результате доработки
документа «Бизнес требования» техническим специалистом.
Руководствуясь выбранным перечнем документов был разработан процесс
создания технической проектной документации до передачи проекта в разработку
[6]. Процесс иллюстрирует диаграмма последовательностей, представленная на
рисунке 8.
В разработанном процессе также учтены сформулированные требования
документирования.
Разработанный процесс включает в себя ряд особенностей:
1. Вся коммуникация с Заказчиком происходит строго через руководителя
проектов.
2. Разработка
технических
документов
производится
конкретным
специалистом области [7].
3. После каждого этапа документирования производится согласование
разрабатываемого документа.
Техническое задание разрабатывается в три этапа: разработка концепции
системы, разработка бизнес требований, разработка технического задания.
34
Рисунок 8 - Диаграмма последовательностей процесса документирования
35
4. Результаты
первых
двух
этапов
–
промежуточные
документы,
необходимые для согласования с заказчиком.
5. Роли в разработки документов распределены следующим образом [2].
Руководитель проекта занимается выявлением всех требований заказчика, создает
первичные
документы,
специалистов.
координирует
Проектировщик
и
принимает
согласовывает
участие
в
работу
других
документировании
практически сначала разработки документации. В его обязанности входит
редактирование бизнес требований с учетом технических особенностей и
финальная разработка технического задания, а также формирует требования к
работе прочих специалистов. Специалисты по графике и звукам участвуют в
создании дизайн документа консультационно, а также согласовывают требования,
разработанные проектировщиком.
2.5 Разработка технической документации
Разработка технической документации подробно рассмотрена на примере
создания фрагмента документа «Технического задания».
При разработке технического задания особое внимание было уделено
документу ГОСТ 19.201-78 ЕСПД «Техническое задание. Требование к
содержанию и оформлению».
Рассмотрим более подробно раздел описания функциональных требований.
Функциональные требования были выявлены с помощью предоставления
Заказчиком концепта с описанием того, как он видит готовый квест. По ходу
составления документации требования уточнялись.
Процесс выявления и формализации требований строился следующим образом:
1. Подробное изучение концепта, предоставленного Заказчиком.
2. Поиск узких мест, несостыковок сюжета и т.д.
3. При необходимости, консультирование с техническим отделом о
возможности и способах реализации.
4. Информирование Заказчика о выявленных недостатках.
36
5. Предложение возможных решений.
6. Совместный выбор решения.
7. Формализация и документирование функционала с учетом внесенных
правок.
8. Согласование с Заказчиком.
9. Утверждение Заказчиком формализованного перечня работ.
Исходя из выявленных требований, архитектурно данный квест имеет две
части: приложение оператора и приложение клиента. Эти приложения образуют
собой клиент-серверную архитектуру. Поэтому, согласно стандарту ISO, данный
проект
подразумевает
разработку
программного
обеспечения
(ПО)
с
использованием технологии виртуальной реальности.
Рассмотрим требования к каждому приложению отдельно.
Для
формализации
требований
были
созданы
UML-диаграммы,
иллюстрирующие конкретные разделы требований.
Обратимся к описанию и формализации требований приложения оператора.
После изучения требований было принято решение формализации требований к
функционалу приложения оператора с помощью диаграммы прецедентов.
Требования, заявленные заказчиком для приложения оператора указаны на
диаграмме вариантов использования ниже (см. рисунок 9).
37
Рисунок 9 – Диаграмма прецедентов «Требования к приложению оператора»
Рассмотрим данную диаграмму подробнее.
Прецедентами определены следующие возможные действия оператора.
Обратимся к каждому из них:
1. Подключиться к голосовому чату. Игроки находятся в одном игровом
помещении и слышат друг друга.
Оператор следит за их действиями
дистанционно (из комнаты оператора) и слышит разговор игроков. Может
возникнуть необходимость координирования или прочих комментариев со
стороны оператора. Для этого для него должна быть реализована возможность
подключения к голосовому чату всех игроков.
38
2. Начать разговор от дракона. По сюжету квеста на локации «3» с игроками
разговаривает дракон. Для создания большей реалистичности и возможности
свободно разговаривать эту роль на себя берет оператор. Его голос искажается, а
модель дракона анимируется и синхронизируется с речью оператора в режиме
реального времени. Данный функционал должен быть доступен только на
локации «3».
3. Следить за действиями игроков. Отслеживание действий игроков должно
происходить путем показа 2D сцены текущей игровой локации или перехода
между локациями и аватарами игроков на них.
4. Принудительно завершить игру. Данное действие должно быть доступно
оператору в любой момент квеста. Должна быть возможность как завершить игру
для всех игроков, так и выводить игроков из виртуального пространства поодному.
5. Открыть дверь на следующий уровень. Реализация данного функционала
требуется с целью упрощения игрокам прохождения квеста в случае, если с этим
возникли трудности. При использовании оператором этой кнопки открывается
дверь перехода с текущего на следующий уровень.
После изучения заявленных требований был разработан макет интерфейса
приложения оператора, на котором условно обозначены все необходимые
элементы (см. рисунок 10).
Данный макет был согласован с Заказчиком и удовлетворяет всем
заявленным требованиям.
Впоследствии по данному макету и описанным требованиям было создано
приложение оператора. Рассмотренный макет был преобразован в интерфейс
приложения оператора.
39
Рисунок 10 – Макет интерфейса приложения оператора
Далее рассмотрим формализацию требования к реализации приложения
игрока.
Одним из важнейших разделов квеста виртуальной реальности является
управление в виртуальном пространстве. Управление в проекте «Заказ – Квест
VR» иллюстрировано рисунком 11 [3].
Управление в рассматриваемом проекте осуществляется при помощи
контроллеров Oculus Touch. На рисунке 11 с помощью заметок указаны
конкретные кнопки контроллера, нажатие на которые приводит к определенной
реакции игры.
В любой локации игрок может взаимодействовать с интерактивными
предметами. Для всех предметов доступно два вида взаимодействий (кроме
специальных, которые описываются для каждого предмета индивидуально): взять
предмет и толкнуть предмет. Данные действия осуществляются при зажатии
кнопки Trigger на контроллере и воспроизведении физического действия над
интерактивным предметом. Если игрок взял предмет, существует два возможных
действия: отпустить предмет и использовать предмет. Отпускание предмета
вызывается отпусканием кнопки Trigger на контроллере.
40
Рисунок 11 – Диаграмма вариантов использования для управления пользователя
41
Использование предмета также зависит от конкретной ситуации и
прописывается для каждого предмета отдельно. Таким образом должно
осуществляться управление в рассматриваемом квесте виртуальной реальности.
Рассматриваемый квест имеет сюжетную линию, объединяющую в себе 4
локации, а также переходы между ними. Для лучшего ориентирования в уровнях
и их последовательности была создана карта уровней квеста. Она представлена на
рисунке 12.
На карте схематично обозначены планы игровых локаций (уровней), а также
переходов между ними. Важно отметить, что последовательность уровней
показана стрелками. Это позволило специалистам, работающим над проектом
лучше ориентироваться в сюжетной линии квеста при разработке программного
обеспечения.
Для формализации референса Заказчика по планировке локации были
разработаны планы уровней, а также переходов на текущий уровень и с текущего
уровня. Планы содержат основное расположение зоны нахождение игроков в
виртуальном пространстве, а также ключевые игровые элементы локаций.
Такое отображение игровых локаций позволило всей команде разработки
однозначно понять требования заказчика и выполнить необходимые работы,
начиная от моделирования окружения и заканчивая настройкой оборудования для
физических локаций.
42
Рисунок 12 – Карта уровней
43
Так как результатом данного проекта является программное обеспечение
для проведения игры в формате квеста с использованием технологии виртуальной
реальности длительностью прохождения около 40 минут и содержащим
несколько локаций с переходами, работа с требованиями Заказчика в рамках
дипломной работы была рассмотрена на примере одной из игровых локаций
(локация «3»).
Уровень, который игрок проходит на рассматриваемой локации называется
«Логово Дракона». Это самый наполненный концептуально уровень квеста.
Поэтому было принято решение подробно иллюстрировать как план данной
локации, так и возможности игрока на ней. Значительное внимание было также
уделено сценарию действий, необходимых для прохождения уровня «Логово
Дракона».
В дальнейшем будет рассмотрена разработка материалов для данной
локации:
 план перехода на локацию;
 план локации;
 план перехода с локации;
 возможности игрока на локации;
 сценарий для прохождения локации;
 детализация сложной последовательности действий на локации.
Проиллюстрируем план перехода на локацию. Готовая иллюстрация для
технического задания представлена на рисунке 13.
44
Рисунок 13 – План перехода
45
Рассмотрим детально план локации «3».
Сам переход изображен светлым коридором. В переходе схематично
показаны факелы и камни, наполняющие пещеру.
Присутствуют две комнаты: «Начало уровня» и «Конец уровня». Для
системы они называются комнатами загрузки локаций. Важным требованием
заказчика была смена одной локации на другую так, чтобы этого не было заметно
игрокам. Поэтому было принято решение производить смену игровых локаций
именно в представленных комнатах загрузки.
Также в плане локации присутствует сегмент, называемый «Черная зона».
Он означает зону, недоступную для игрока во время нахождения в виртуальной
реальности. При попадании в эту зону игрок оказывается в «темном мире».
Единственный способ продолжить игру – вновь прийти в комнату загрузки и
начать переход заново. Для ориентации в «темном мире» также продумана
специальная логика.
Планы уровней построены таким образом, чтобы у игрока создавалось
впечатление, что он путешествует по огромной пещере или находится в открытом
пространстве. Такое построение планов игровых локаций построено на идее, что в
реальном мире игрок ходит по кругу на протяжении всей сюжетной линии квеста,
а смоделированный мир не дает этого замечать.
Далее игровая локация «3» изображена на рисунке 14.
Физическая
локация
в
данном
случае
значительно
меньше,
чем
смоделированное окружение. Однако, благодаря сформированному дизайн
документу моделлеры смогли создать мир, который не допускает столкновение
игрока со стенами.
46
Рисунок 14 – План локации
47
Переход с локации «3» аналогичен переходу на локацию. Отличие
заключается лишь в пути, который игрокам необходимо пройти для попадания на
следующую локацию. План перехода с локации «3» представлен на рисунке 15.
Рисунок 15 – План перехода
48
Созданные планы уровней оказались очень универсальными и удобными в
разработки. Они были использованы для ряда целей:
 согласования планировок локаций с Заказчиком;
 согласования расположения ключевых элементов с Заказчиком;
 лучшего понимания технического задания командой разработки;
 создания прототипов игровых локаций разработчиками;
 моделирования окружения.
Действия, которые возможны на уровне «3» также иллюстрированы
диаграммой на рисунке 16.
Рассмотрим подробнее представленную диаграмму.
На игровой локации «3» игрок имеет возможность взаимодействовать с
интерактивными предметами (сачок, книга, кувшин, факел, полено, мост). Также
на локации присутствует персонаж. Это дракон, с которым игрок может
разговаривать.
Задача локации сводится к освобождению дракона, поэтому все действия на
локации сводятся к последовательности действий для его освобождения. При
верном прохождении уровня представленные на диаграмме возможные действия
игрока образуют собой сценарий решения загадок.
Все действия также реализуются с помощью контроллеров привычным за
время квеста игроку способом.
49
Рисунок 16 – Диаграмма вариантов использования действий игрока на локации
«3»
50
Для наилучшего понимания игрового сценария на локации «3» была
создана диаграмма последовательностей, описывающая необходимые действия
игрока для прохождения уровня «3». Она изображена на рисунке 17.
Взаимодействие происходит между двумя субъектами – персонажами.
Это
игрок
и дракон. В остальных
интерактивными
предметами
игровой
случаях
локации.
игрок взаимодействует с
Последовательность
взаимодействий и приводит к решению загадок локации «3».
Сценарий действий можно описать лаконично следующим образом:
1. Дракон говорит голосом оператора.
2. Игроки отвечают.
3. Дракон переходит в idle-анимацию.
4. Игроки находят зелье в книге зелий.
5. Игроки вводят последовательность рун на стене с руками.
6. Руны загораются.
7. Стена раздвигается.
8. Игроки берут книги из углубления.
9. Игроки готовят зелье.
10. Игроки окунают оружие в зелье.
11. Оружие сияет.
12. Игроки ударяют оружием по цепи.
13. Оружие разрубает цепь.
14. Игроки освободили дракона.
15. Дракон улетает.
16. С неба падает ключ.
17. Игроки берут ключ.
18. Игроки нажимают на камень для опускания моста.
19. Камень опускает мост.
20. Мост опускается.
21. Игроки проходят по мосту.
этих
51
Рисунок 17 – Диаграмма последовательностей прохождения уровня «3»
52
22. Игроки вставляют ключ в дверь.
23. Ключ открывает дверь.
24. Дверь открывается.
25. Игроки переходят на следующий уровень.
Приготовление зелья – отдельная часть игровой логики. Поэтому
детализация этого процесса вынесена в отдельную диаграмму (см. рисунок 18).
Важно отметить, что действия данного процесса можно выполнять в любой
последовательности. На диаграмме представлена лишь одна из них.
Сценарий действий для приготовления зелья можно описать лаконично
следующим образом:
1. Игрок кладет бревна в кострище.
2. Бревна фиксируются.
3. Игрок подносит факел к бревнам.
4. Факел зажигает бревна.
5. Бревна горят.
6. Игрок наливает воду в котел с помощью кувшина.
7. Содержимое котла кипит.
8. Игрок ловит сачком насекомых и животных.
9. Сачок собирает насекомых и животных.
10. Игрок вытряхивает содержимое в котел.
11. Содержимое котла меняет цвет.
12. Игрок собирает растения и грибы.
13. Игрок кладет растения и грибы в котел.
14. Содержимое котла меняет цвет.
15. Зелье готово.
53
Рисунок 18 – Детализация приготовления зелья
54
Отображение сценариев действий, необходимых для прохождения уровня,
позволило быстро и удобно при согласовании с Заказчиком материалов для
разработки будущего приложения, так и при разработке начиная от начального
проектирования системы и заканчивая настройкой оборудования и тестированием
[1].
55
ЗАКЛЮЧЕНИЕ
В ходе написания дипломной работы, была изучена технология виртуальной
реальности, а также проведен аудит проекта разработки программного
обеспечения.
На основе выявленных в ходе аудита ошибок документирования были
сформированы требования к процессу документирования и перечню документов.
Далее были разработаны процесс документирования и сам перечень необходимых
документов. Впоследствии эти разработки были внедрены в работу компании на
рассматриваемом проекте и привели к улучшению показателей проекта и
успешной его сдаче.
В настоящий момент разработанный процесс документирования внедряется
в управление и другими проектами компании.
Исходя
из
возросших
проектных
показателей
и
масштабирование
созданных разработок на прочие проекты компании, цели и задачи дипломной
работы можно считать достигнутыми.
56
СПИСОК ЛИТЕРАТУРЫ
1. Абдикеев, Н.М. Реинжиниринг бизнес-процессов. Полный курс MBA
[Текст]: учебник / Н.М. Абдикеев, Т.П. Данько, С.В. Ильдеменов, А.Д. Киселев –
М.: ЭКСМО, 2005. – 578 с. – 3100 экз. – ISBN 5-699-19772-9.
2. Лазарев, С.А. Управление производством продукции на промышленных
предприятиях с применением современных информационных систем [Текст]: дис.
канд. экон. наук : 08.00.05 : защищена в 2000 г. / Лазарев Сергей Александрович. –
ОрелГТУ., 2000. – 162 с.
3. Методология функционального моделирования IDEF0 [Электронный
ресурс] / Руководящий документ, официальное издание, яз. рус. – Режим доступа:
http://www.businessstudio.ru/files/idef0rus.pdf.
4. Демарко, Том Deadline. Роман об управлении проектами [Текст]: [пер. с
англ.] / Том Демарко. ˗ М.: Манн, Иванов и Фербер, 2011., ISBN ˗
978-5-91657-284-1, ˗ 352 с.
5. Фаулер, М. UML. Основы [Текст]: [пер. с англ.] / Мартин Фаулер – СПб:
Символ – Плюс, 2004., ISBN ˗ 5-93286-060-X, ˗ 192 с.
6. Рейнвотер, Х. Как пасти котов. Наставление для программистов,
руководящих другими программистами [Текст]: [пер. с англ.] / Рейнвотер, Х. –
М.: Питер, 2016. – 256 с. – ISBN: 978-5-496-01820-3.
7. Архангельский, Г. Тайм-драйв. Как успевать жить и работать [Текст]:
Архангельский, Г., – М.: Манн, Иванов и Фербер, 2014. – 748 с. – ISBN: 978-500117-061-7.
8. ГОСТ 19.101-77. ЕСПД. Виды программ и программных документов
[Текст]. Введен 1980–01–01. – М.: Изд-во стандартов, 1992. – 3 с. – (Единая
система программной документации).
9. ГОСТ
19.201-78.
ЕСПД.
Техническое
задание.
Требования
к
содержанию и оформлению. [Текст]. Введен 1980–01–01. – М.: Изд-во стандартов,
1992. – 4 с. – (Единая система программной документации).
57
58
ПРИЛОЖЕНИЕ 1. ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ФРАГМЕНТ
1 Введение
1.1 Наименование
Наименование приложения “Квест виртуальной реальности “Сокровища
горного короля”.
1.2 Краткая характеристика области применения программы.
Приложение предназначено для проведения игры в формате квеста
виртуальной реальности на площадке, включающей игровую зону и комнату
оператора.
2 Основания для разработки
2.1 Основания для проведения разработки
Основанием для проведения разработки является Договор №01/17 от
26.07.2017 г.
Заказчик: ООО «БФ Геймс».
Исполнитель: ООО “Диджитал-агентство Синапс”.
2.2. Наименование и условное обозначение темы разработки
Наименование темы разработки – «Разработка игрового приложения
виртуальной реальности».
3 Назначение разработки
3.1. Функциональное назначение приложения
Функциональным
виртуального
игрового
назначением
приложения
интерактивного
является
пространства
для
обеспечение
прохождения
59
мультиплеерного квеста с соблюдением игровой логики, заявленной Заказчиком,
одновременно несколькими игроками (от 1 до 4 человек).
3.2. Эксплуатационное назначение программы
Приложение должно эксплуатироваться на площадках аттракционов
виртуальной реальности компании “BF VR-Games”. Конечными пользователями
приложения должны являться игроки, желающие пройти квест виртуальной
реальности “Сокровища горного короля”.
4 Требования к программному обеспечению
4.1 Требования к функциональным характеристикам
Функционал конечного ПО делится на две части: функционал приложения
оператора, функционал приложения игрока.
Архитектурное решение: приложение оператора выступает сервером,
объединяющим работу приложений игрока – клиентских приложений, а также
обладает дополнительным функционалом.
Требования к функциональным характеристикам приложения оператора и
приложения игрока описаны в разделах “Требования к функциональным
характеристикам приложения оператора” и “Требования к функциональным
характеристикам приложения клиента соответственно”.
4.1.1
Требования
к
функциональным
характеристикам
приложения
оператора
Функциональные
возможности
соответствовать диаграмме прецедентов:
приложения
оператора
должны
60
Рисунок 1 – Диаграмма прецедентов действий оператора
Элементы интерфейса приложения оператора показаны на рисунке.
Рисунок 2 – Элементы интерфейса приложения оператора
4.1.2 Требования к функциональным характеристикам приложения игрока
61
4.1.2.1 Требования к действиям игрока на игровой локации
Заявленные требования к наличию действий игрока, общих для всех
локаций, указаны на диаграмме:
Рисунок 3 – Диаграмма прецедентов действий игрока на игровых локациях
62
4.1.2.2 Требования к игровой логике на локации 3
Заявленные требования к наличию действий игрока на локации 3 указаны на
диаграмме:
Рисунок 4 – Диаграмма прецедентов действий игрока на локации 3
63
Сценарий действий, необходимый для успешного прохождения уровня 3
изображен на диаграмме:
Рисунок 5 – Диаграмма последовательностей для сценария успешного
прохождения уровня 3
64
Детализация процесса приготовления зелья изображена на диаграмме:
Рисунок 6 – Диаграмма последовательностей для сценария успешного
приготовления зелья
4.1.2.3 Требования к игровым локациям
Размерность игровой локации равна размерности физической локации: 7м
x 12м.
Если совместить все чертежи, то можно увидеть, что загрузочные зоны для
каждой локации накладываются друг на друга. То есть, когда игрок попадает в
загрузочную зону, он не должен понять, что произошла загрузка. За ним просто
должна закрыться входная дверь и после загрузки открыться дверь на выход.
Таким образом игроки будут ходить по кругу не замечая этого.
Планы игровых локаций изображены на схемах ниже.
65
Рисунок 7 – План локации 1
66
Рисунок 8 – План локации 2
67
Рисунок 9 – План перехода между локациями 2 и 3
68
Рисунок 10 – План локации 3
69
Рисунок 11 – План перехода между локациями 3 и 4
70
Рисунок 12 – План локации 4
71
4.2 Требования к надежности
Особых требований к надежности не предъявлялось.
4.3 Условия эксплуатации
Особых требований к условиям эксплуатации не предъявлялось.
4.4 Требования к составу и параметрам технических средств
Оснащение игровой зоны:
камеры Optitrack Prime 13 (12 шт.).
Комплект оборудования игрока:
комплекты точек отслеживания для камер optitrack prime 13:
комплект для отслеживания положения головы;
комплект для отслеживания положения рук;
комплект для отслеживания положения ног;
рюкзаки Zotac VR Go;
шлем виртуальной реальности Oculus Rift;
контроллеры Oculus Touch.
Технические средства оператора:
ПК оператора на ОС Windows 10.
4.5 Требования к информационной и программной совместимости
Приложение виртуальной реальности должно быть разработано на игровом
движке Unity.
Целевая операционная система: Windows 10.
72
5 Требования к программной документации
Состав программной документации должен включать в себя:
программные документы
спецификация
текст программы
программу и методику испытаний
техническое задание
эксплуатационные документы
формуляр
руководство оператора
6 Технико-экономические показатели
Расчет технико-экономических показателей не входит в обязанности
рабочей группы проекта и рассчитывается на стороне Заказчика.
7 Стадии и этапы разработки
7.1 Стадии разработки
Разработка должна быть проведена в три стадии:
техническое задание;
рабочий проект;
внедрение.
7.2. Этапы разработки
На стадии разработки технического задания должен быть выполнен этап
разработки, согласования и утверждения настоящего технического задания
заказчиком.
На стадии рабочего проекта должны быть выполнены перечисленные ниже
этапы работ:
73
проектирование;
разработка программного обеспечения;
завершение разработки программной документации;
испытания приложения.
На стадии внедрения должны быть выполнены этап разработки:
настройка оборудования на площадке Заказчика;
финальная сборка проекта;
передача проекта Заказчику.
7.3. Содержание работ по этапам
На этапе разработки технического задания должны быть выполнены
перечисленные ниже работы:
изучение концепта Заказчика;
определение и уточнение требований к техническим средствам;
определение требований к приложению;
определение стадий и этапов разработки программы и документации на нее;
создание, согласование и утверждение спецификации и технического
задания.
На этапе проектирования должна быть выполнена работа по изучению
архитектором предметной области, требований к программному обеспечению и
создана архитектура будущего программного обеспечения.
На этапе разработки программного обеспечения должна быть выполнена
комплексная работа, состоящая из следующих разделов:
разработка программной части ПО;
разработка графической части ПО;
разработка звуковой части ПО;
внедрение графической и звуковой части в проект ПО.
74
На этапе завершения разработки программной документации должны быть
созданы эксплуатационные документы на ПО в соответствии с требованиями
ГОСТ 19.101-77 и требованием п. «Требования к программной документации«
настоящего технического задания.
На этапе испытаний ПО должны быть выполнены перечисленные ниже
виды работ:
1) разработка, согласование и утверждение программы и методики
испытаний;
2) проведение испытаний в соответствии с программой и методикой
испытаний;
3) корректировка программы и программной документации по результатам
испытаний.
На этапе настройки оборудования на площадке Заказчика должны быть
произведены работы по настройке:
отслеживания камер по точкам;
взаимодействия приложений оператора и клиента;
инверсной кинематики.
На этапе финальной сборки проекта осуществляется сборка с учетом
проведенных настроек, а также подготовка проекта к сдаче.
На этапе передачи проекта заказчику должны быть проведены работы в
соответствии с п. “Порядок контроля и приемки”
7.4. Исполнители
Руководитель проекта
Фамилия И.О.
75
Тимлид проекта
Фамилия И.О.
Программисты
Фамилия И.О.
Фамилия И.О.
Фамилия И.О.
3D моделлер
Фамилия И.О.
2D дизайнер
Фамилия И.О.
Композитор
Фамилия И.О.
8 Порядок контроля и приемки
Контроль за ходом работ осуществляется путем тестирования заказчиком
каждого готовой части работ.
Графические и звуковые материалы согласовываются с Заказчиком перед
внедрением в проект.
Во время приемки работ Заказчику передаются:
1.
Программный код на физическом носителе
2.
Доступ к репозиторию проекта в GitLab
3.
Финальная сборка приложения оператора
4.
Финальная сборка клиентского приложения
Подписывается Акт выполненных работ.
76
ПРИЛОЖЕНИЕ 2. ДИЗАЙН ДОКУМЕНТ
Сюжетная составляющая проекта
Основной сюжет игры
Группа искателей приключений: рыцари, маги(они могут быть разных
полов – мужского и женского) ищут сокровища, спрятанные в глубокой пещере
волшебной скалы. На поясе воина (изображение 5, но забрало должно быть
постоянно закрыто) должен висеть меч (одноручный до 90 см), у мага должен
быть посох, который может выпускать огненный шар по нажатию кнопки №3 на
контроллере. Квест начинается у подножья скалы, на которой растет пара
деревьев и прочая растительность. Основная задача в данной локации: найти
ключ, позволяющий войти в пещеру. Далее команда проходит по коридору в
пещере во вторую локацию. При выполнении задания команда должна открыть
дверь и начать переход в третью локацию. В третьей локации команде нужно
освободить дракона, после чего они получат ключ, позволяющий перейти к
четвертой локации. В четвертой локации команда должна починить механизм
дверей, чтобы попасть в сокровищницу.
77
Рисунок 1 – Пример рыцаря (воина), щит воину в игре не нужен
Параметры игровой зоны
Необходимая игровая площадь: 81 м2 (9*9 м2 ). Масштаб в игре: 1:1 (один
шаг в реальном мире – шаг в виртуальном). Одна единица расстояния в Unity3d
соответствует одному метру в реальном мире.
Количество
игроков:
1-4.
Описание Локаций
Помимо описания сюжета и загадок для каждой локации данный раздел
также содержит схематические изображения каждого помещения с указанием
размеров каждой из стен, дверей и т. п. В идеале каждая загадка должна быть
отдельным модулем, который при тестировании игры можно было бы включить
или выключить. Или например, как в 4.3.3 изменить количество ключей.
Локация №0 – Начало игры
В самом начале, перед тем как появиться в первой локации, игроки
находятся в темном мире (физически находятся в комнате после калибровки).
Фоновая музыка может быть мелодией из фильмов про рыцарей или что-то
подобное.
В темном мире видны другие игроки в виде фантомов и ограничения
игровой зоны. Перед игроками должны находиться несколько моделей
персонажей на выбор (то, как они будут выглядеть). Это должны быть, как было
78
сказано ранее, воин и маг. Для того, чтобы выбрать персонажа для игры, они
должны подойти к желаемой модели и коснуться ее рукой. Смена аватара
сопровождается простым свечением и звуковым эффектом. После этого должна
загореться зона, встав на которую игрок перенесется в локацию 1.
Когда игрок появляется в локации 1, можно сделать ему эффект
телепортации, чтобы для игрока, сделавшего свой выбор раньше, это не было
просто резким появлением.
79
Локация №1 – Вход в пещеру
Рисунок 1 – Пример горного плато
Эту
локацию
можно
практически
скопировать
с
изображения
6,
расположенного сверху. Однако нужны некоторые изменения. С трех сторон
обрыв в реку, с четвертой – горный массив, в котором расположена дверь для
входа в пещеру. Поверхность этого плато не должна быть каменной. Она должна
быть покрыта различной растительностью (кусты и пара деревьев). На одной из
гор может быть расположен зАмок.
Задача в этой локации будет достаточно проста. Команде нужно отыскать
ключ, с помощью которого она сможет открыть дверь в пещеру и перейти во
вторую локацию.
Команда может искать ключ под камнями, в кустах и по
площади всего горного плато. Сам ключ будет находиться в дупле одного из
деревьев (на высоте 1,5 м). После того, как команда найдет ключ, они смогут
открыть дверь в пещеру и перейти ко второй локации.
80
Рисунок 3 – Схема первого уровня
Локация №2 – Пещерное кладбище
Команда попадает в первое помещение пещеры. Само по себе помещение
должно быть небольшим и соответствовать размерам игровой зоны. Потолки
должны
быть около
4х
метров, чтобы
создать ощущение свободного
пространства. У стены этой пещеры будет стоять один сундук. В углах и у стен
пещеры будут валяться 5 неподвижных скелетов. По всей пещере будут
разбросаны 6 идентичных ключей. Команда должна подобрать правильный ключ,
81
чтобы открыть сундук и забрать ключ, который позволит им открыть дверь в
следующую локацию. Первый ключ не подойдет. При попытке открыть им дверь
он сломается. Подойдет лишь последний ключ (в игре сундук магический, и хоть
и все ключи одинаковые, открыть его можно только последним ключом. Игроки
же в принципе не будет этого понимать. Они просто будут думать, что им все 5
раз не повезло с выбором. Все это делается только для того, чтобы дать им сразу 5
возможностей сразиться со скелетами). Но каждая попытка будет чревата
оживлением одного из скелетов, которого команде предстоит уничтожить. Скелет
может нападать на игроков (у него в руках есть меч), при этом игрок может
умереть, потеряв аватар, удары будут сопровождаться громким звуком в
наушниках игрока. Уничтожение скелета сводится к простому удару по нему
мечом рыцаря или попаданием одного заряда мага, а также ударами посоха мага
(скелет будет рассыпаться). Формирование огненного мяча происходит путем
нажатия на кнопку 3, при отпускании кнопки происходит выстрел огненным
мячом. При попадании на объект – на нем будут подсвечиваться частицы
(particles), а затем пропадать.
82
Рисунок 4 – Схема второго уровня
Когда команда будет использовать последний ключ, сундук откроется, а
последний скелет рассыплется, и они смогут забрать оттуда ключ, который
подойдет к двери, ведущей в другую локацию.
Меч просто висит на поясе, так же как и посох. Взмахи и удары будут
совершаться движением руки, то есть чтобы взять меч, игроку нужно будет
поднести руку к мечу на поясе и нажать на курок, после этого меч возьмется в
руку. Далее он просто будет перемещаться движениями руки. Сила удара должна
83
зависеть от скорости движения меча (посоха для мага). Можно применить
простые уравнения движения для ее вычисления.
Рисунок 5 – Схема перехода со второго на третий уровень
Локация №3 – Логово Дракона
84
После входа в эту локацию перед игроками откроется огромная пещера.
Они находятся на плато. Напротив двери, из которой они вошли, находится вход в
следующую локацию. Проблема в том, что дверь (вход в следующую локацию)
отделена от игроков, обрывом. Далеко внизу можно будет увидеть текущую лаву.
Они могут перебраться к другой двери только по хлипкому, узкому мосту,
который находится на другой стороне. Игрокам надо обрубить веревку, которая
опустит мост, при этом веревка должна быть заметна. Она идет от одного из
блоков крепления наверху к плато, на котором изначально стоят игроки. То есть
при разрубании веревки, мост может даже просто упасть на плато, а не спокойно
опуститься. Мост выглядит примерно как на рисунке 6:
Рисунок 6 – Пример моста
85
Недалеко от входа в этот «грот» пещеры будет располагаться кострище с
небольшим котелком и лежащей около него книгой. Потолок пещеры уходит
вверх и теряется в темноте. Далеко наверху виден небольшой кусочек неба (через
отверстие может пролететь дракон). В один момент сверху (спустя 30 секунд
после загрузки локации) плавно спустится дракон, который должен будет сесть
перед игроками на скалу (скала будет выше уровня моста) в центре обрыва и
спросить их о том, что они здесь делают (за дракона говорит оператор,
необходима обработка звука дракона процессором).
Рисунок 7 – Примерный вид дракона на скале
Игроки объяснят, что им нужно попасть в сокровищницу и для этого им
необходим ключ. Дракон (устами оператора) скажет, что он является хранителем
этого ключа уже сотни лет и если игроки помогут ему освободится, он отдаст им
ключ (при этом необходимо, чтобы у дракона была анимация перехода в режим
разговора, при возможности, надо подключить частотный и амплитудный
анализатор и привязать соответствующие анимации). Проблема лишь в том, что
лапа дракона прикована к магической цепи (цепь прикреплена к краю или центру
86
плато на котором стоят игроки), которую нельзя разрубить обычным мечом (или
разбить обычным огненным шаром). Для этого им нужно заколдовать меч (посох)
так, чтобы он смог разрубить эту цепь. Чтобы достичь цели, игрокам понадобится
открыть книгу, лежащую рядом с костром, и найти в ней подходящее зелье. В
зельи будут указаны необходимые ингредиенты и порядок их смешивания, но не
будет к ним иллюстраций. Для того, чтобы понять, как выглядит тот или иной
элемент зелья, игроки должны будут найти еще 2 книги (на левой стене,
изображение 14). Первая книга будет являться справочником по грибам,
растущим в этих пещерах, а вторая – будет иллюстрировать растения, которые
наполняют эти пещеры. Выбрав и смешав правильные ингредиенты, игроки
получат зелье, которым нужно будет обработать оружие: окунуть в котел меч
(посох) (но так, чтобы он не проходил сквозь него). После этого меч (посох)
засияет, и при ударе им по цепи дракона (выпускании огненного мяча), та
оборвется. Дракон взмоет в воздух, выпустив ввысь струю пламени и улетит.
Через несколько секунд на плато упадет столь желанный игроками ключ.
Описание книг и заклинаний:
Рисунок 8 – Книга заклинаний (стилистики и цвета, которые должны быть
использованы)
87
Рисунок 9 – Схематичное изображение обложки книги заклинаний.
Окружностями отмечено расположение девяти рун
В книге будет представлено 9 активных страниц, на которых будет
описание 9 различных заклинаний (в описание входят название, ингредиенты для
приготовления, действие заклинания и схематичное изображение). Изображения
ингредиентов присутствовать не будут.
Заклинание
Действие заклинания
Ингредиенты
Создание магической
Зачаровывает
Грибы
несокрушимой цепи (Здесь
цепь,
делая ее неразрушимой.
«Муравей»
это зелье прописано просто,
Крыса
чтобы показать игрокам, что
Муха
маг,
Растение
который
заколдовал
цепь, использовал для этого
«Недупляйка»
эту книгу заклинаний. В
реальности
игрокам
не
нужно будет использовать
это
заклинание,
да
и
ингредиентов у них всех не
будет.)
Магическое
(единственное
оружие
зелье,
Создает
способное
оружие
разрубить
что
Грибы
«Аквалон»
88
необходимое
для
угодно.
Ящерица
продолжения игры)
Светлячок
Растение
«Ширчатая слезка»
Перевоплощение
При принятии зелья с
Грибы
(это зелье также необходимо
добавлением волос человека,
«Зеркалки»
реализовать)
вы сможете на некоторое
Мышь
время принять его обличай
Пчела
(на 5-10 минут)
Растение
«Красная трава»
Ядовитые мучения
При принятии этого
зелья, вы сможете испытать
Грибы
«Муравей»
дичайшую боль, но при этом
Крыса
вы не умрете. (Как таковой
Муха
смерти нет. Но, например,
Растение
если игрок упадет в обрыв,
«Амосница»
то, как и с прохождением
сквозь стены,
он должен
попасть в темный мир. При
этом его аватар упадет с
обрыва
и
умрет.1
Чтобы
возродиться, игроку придется
вернуться в выделенную зону
(Для каждой локации своя –
начало уровня))
Левитация
При принятии этого
зелья,
вы
некоторое
сможете
на
время
приподняться в воздухе.
Грибы
«Ведьмины глазки»
Лиса
Мотылек
Растение
1
Механика падения примерно такая же, как и со стеной. Как только игрок проходит определенную зону
(зона земли) и оказывается над обрывом, он попадает в темный мир. Его аватар больше им не
контролируется, получает на себя rigidbody и включает анимацию падения. После исчезновения из поля
зрения, он удаляется. Для возрождения игроку необходимо вернуться в начало локации (комнату
загрузки), она должна как всегда быть ему подсвечена.
89
«Недупляйка»
Рисунок 10 – Сачок для ловли насекомых и ящериц
Для того, чтобы сварить зелья, игрокам нужно совершить несколько
действий (последовательность в первых 4-х действиях не сильно важна):
Собирают ингредиенты для зелья. Для этого сначала они должны найти
книгу заклинаний у кострища, обратить внимание на одну из стен в пещере, в
которой будут выделены 9 РУН, ПОХОЖИЕ НА ТЕ, ЧТО ИЗОБРАЖЕНЫ НА
КНИГЕ. На стене размещены изображения этих же рун, но в определенной
последовательности. Игрокам нужно будет нажать на руны на книге в том
порядке, в котором они изображены на стене (при нажатии на верную руну – она
подсвечивается). После этого в стене с рунами открывается отделение с 2 книгами
(о грибах и растениях). В них присутствуют изображения (где и как их можно
найти). По дизайну грибов и растений предпочтений нет, единственное, они
должны быть разных цветов и отличаться друг от друга. В книгах о грибах и
растениях не будет описания ингредиентов, только названия и изображения к
ним. В каждой книге будет 4 активных страницы (4 вида грибов и 4 вида
растений). В пещере будет располагаться по несколько грибов, и растений
каждого вида. Для того, чтобы поймать животное или насекомое – деревянный
сачок. Сачок будут лежать у скалы рядом с углублением в пещере.
С помощью этих книг игроки находят ингредиенты.
Разжигают костер на кострище. Для этого игроки должны собрать бревна,
разбросанные по всему плато, и поджечь их факелом.
90
Наливают воду в котелок из ручейка (подержать котелок у истока ручейка),
текущего из верхней стены через все плато.
Далее игрокам надо добавить ингредиенты в котелок (животные не будут
реагировать на добавление в котелок), и через несколько секунд зелье поменяет
цвет и будет готово.
По окончанию процесса, игроки должны взять котелок и окунуть в него меч
(посох).
Этим мечом рыцарь сможет разбить заколдованную цепь (маг – с помощью
огненного шара) и освободить дракона.
После этого дракон отдаст ключ команде, и она сможет продолжить свой
путь.
91
Рисунок 11 -Схема третьего уровня
Рисунок 12 – Схема перехода с третьего на четвертые уровни
Локация №4 – Дверь перед сокровищницей
Основные задачи команды в данной локации.
Попав в данную и последнюю локацию, игроки увидят расположенную в
центре комнаты большую двустворчатую дверь, которая ведет в сокровищницу. У
92
пещеры будут достаточно высокие потолки (около 5-6 метров). Будет видно, что к
двери ведут старые заржавевшие механизмы, которые идут вдоль стен к двери. На
одной из стен будет расположен рычаг, за который необходимо потянуть для
открытия последней двери. Рядом с рычагом будет находится углубление в скале,
на котором будут расположены несколько шестерен. При этом 3х или 4х
шестерни отсутствуют. Они будут лежать на полу. Одна из шестерен должна быть
разбита. У противоположной стены (в противоположном от входа углу) игроки
должны увидеть мини кузницу. Кузница представляет из себя отверстие в скале,
выложенное кирпичом, в котором горит огонь. Слева от него в скалу вставлены
меха для раздувания пламени (игроки ими должны растопить печь). С правой
стороны стоит наковальня, на которой лежат прихват и формы. Игроки должны
понять, что для открытия двери им необходимо выплавить новую шестерню. На
кузнице будет расположено несколько форм (3-4 формы), из которых им
необходимо будет выбрать правильную. Для этого они должны будут поместить
осколок шестерни в форму и убедиться, что он подходит. После этого игроки
должны будут расплавить старую шестерню в плавильне и залить содержимое в
форму. Остудив полученный предмет в бочке с водой (остужать можно в течение
5 минут после выплавки, по прошествии – можно не остужать), они должны
получить недостающую часть механизма. Как только весь механизм двери будет
восстановлен, они смогут опустить рычаг и попасть в сокровищницу (с золотом,
монетами,
коронами,
драгоценными
камнями,
сундуками,
канделябрами,
статуэтками и.т.д.). Сокровищница представляет из себя небольшую комнату
(размер как на изображении 16). Напротив входа стоит небольшой трон со
скелетом мертвого чародея на нем (тот что заточил дракона).
93
Рисунок 13 – Четвертый уровень (финальный)
Вокруг трона и лежит золото и драгоценности. Достигнув цели, игроки
смогут набить карманы золотом. Но в последний момент стены начнут
обваливаться, а пещера – трястись (видимо из-за дракона). Под ногами каждого
игрока появится светящийся круг, из которого вырастет цилиндрическая стена
света, устремляющаяся вверх. После свет будет становится все ярче и ярче и в
один момент (спустя 5-10 секунд) полностью выключится. На этом игра будет
окончена, и они смогут снять шлем.
Такое
окончание
игры
(обваливающиеся
стены,
тряска
пещеры,
телепортация игроков в темный мир) должно быть доступно в любой момент по
94
нажатию кнопки на пульте оператора (UI-кнопка “потрясти пещеру”), так как
время игры ограничено.
95
96
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
Наименование
Характеристики документа
на электронном носителе
группы атрибутов
атрибута
1.
Описание Обозначение документа \Плакаты\Презентация.pptx
документа
(идентификатор(ы)
файла(ов))
Наименование документа Демонстрационные плакаты к
выпускной
квалификационной работе
Класс документа
ЕСКД
Вид документа
Оригинал
документа
на
электронном носителе
Аннотация
Демонстрационный материал,
отображающий
основные
этапы
выполнения
выпускной
квалификационной работы
Использование документа Операционная
система
Windows
10,
Microsoft
PowerPoint 2016
2. Даты и время
Дата и время копирования 16.06.2018
документа
Дата создания документа 29.05.2018
Дата
утверждения 20.06.2018
документа
3. Создатели
Автор
Румянцева Ю.В.
Изготовитель
Румянцева Ю.В.
4. Внешние ссылки Ссылки
на
другие Удостоверяющий лист
документы
№ 140204/п
5. Защита
Санкционирование
ОГУ имени И.С. Тургенева
Классификация защиты
По законодательству РФ
6. Характеристики Объем
информации 1728169 Б
содержания
документа
97
7.
Структура Наименование
документа(ов)
(слайда) №1
Наименование
(слайда) №2
Наименование
(слайда) №3
Наименование
(слайда) №4
Наименование
(слайда) №5
Наименование
(слайда) №6
Наименование
(слайда) №7
Наименование
(слайда) №8
Наименование
(слайда) №9
плаката Титульный лист
плаката Аудит проекта разработки
приложения
виртуальной
реальности
плаката Цель и задачи работы
плаката Перечень
документов,
необходимых для ведения
проекта
плаката Разработанный
процесс
документирования
плаката Формализация требований к
приложению оператора
плаката Формализация
общих
требований к приложению
игрока
плаката Формализация требований к
локации «Логово дракона»
приложения игрока
плаката Аудит результатов внедрения
документации
98
1/--страниц
Пожаловаться на содержимое документа