ПРИМЕНЕНИЕ ИНТЕРАКТИВНЫХ VR ТРЕНАЖЕРОВ В ПРОМЫШЛЕННОСТИ

Цель:  разработать основной функционал проекта “Строение тела человека” и применить логические конструкции основанные на использовании переменных.

Задачи:

-  Закрепить навык создания переменных в XRMS Varwin и использования их в своих проектах

-  Научиться выводить переменные в объект “Текст”

- Научиться задавать события для объектов типа “Зона”

-  Научиться присваивать имена и значения переменным

-  Усвоить навыки тестирования своих проектов на баги/ошибки

- Получить навыки дизайн-мышления для успешного проектирования UX/UI

- Усвоить навыки использования свойств объекта

-  Научиться использовать блоки категории “Событие” в своих проектах

Методические материалы для подготовки к занятию:

Пошаговая инструкция по разработке кейсов #4.

В этот раз сразу начнем с ТЗ:

 Необходимо разработать приложение на платформе Varwin, которое позволяло бы проверять знания о расположении органов человеческого тела.

Специальные требования:

1. В приложении должны использоваться минимум 3 органа человеческого организма.
2. Должна быть создана система оценки, позволяющая определить количество правильных ответов в баллах.
3. Должен быть реализован удобный UX/UI.
4. Только когда все органы будут на месте, то должно высветиться сообщение о победе.

Подготовительная работа

Уже по классической схеме:

1. Создаем новый проект
2. Выбираем локацию, в данном случае отлично подойдет “Школьный класс”, но вы можете выбрать и другую локацию.
3. Открываем Desktop-редактор.

Читаем ТЗ: Необходимо разработать приложение на платформе Varwin, которое позволяло бы проверять знания о расположении органов человеческого тела.

Специальные требования:

1. В приложении должны использоваться минимум 3 органа человеческого организма.

 Значит на сцене нам понадобится человеческое тело и 3 органа из библиотеки “Анатомия”: в нашем примере мы выбрали Скелет, Мозг, Сердце и Печень.

Также нам понадобится ”Текст”, а вернее даже два таких объекта.

На одном мы напишем формулировку задания, а на другой будем отображать результат.

Самостоятельная работа: Вы уже знакомы с параметрами и свойствами объекта, поэтому постарайтесь добиться такого результата, как будто задание написано мелом на доске (подсказка на картинке ниже).

Для того, чтобы сделать вторую панель, просто копируем первую и даем ей название “Результат”, а также поменяем в ней текст:

Самостоятельная работа: Также нам необходимо разместить 4 зоны в местах, где должны располагаться органы и назвать их соответствующим образом. Где должны располагаться органы вы можете найти в учебнике по анатомии, а как располагать зоны мы уже знаем из предыдущего кейсового задания.

Подсказка находится на картинке ниже:

Итак, все необходимые объекты на сцене, переходим к настройке их свойств!

Стандартные свойства объектов и их настройка.

 Давайте подумаем какие свойства применить для объектов на сцене. Для этого применим технику UX/UI-дизайн мышления: продумываем возможные действия пользователя с этими объектами.

Во первых для объекта “Скелет”:

По сути, с точки зрения UX/UI-дизайна у пользователя не должна быть возможность перемещать этот объект, т.к. это может в будущем сломать логику размещения органов (скелет не будет перемещаться вместе с зонами).

Поэтому следует отключить все свойства, связанные с взаимодействием контроллерами, а именно: “Можно брать в руку”, “Можно использовать”, “Можно дотронуться”.

Скелет должен быть статичным объектом, т.к. нам важно, чтобы органы проходили сквозь него, поэтому ставим галочку, напротив “Статичный”.

С другой стороны,  для пользователя скелет будет являться препятствием, чтобы он не мог сквозь него пройти, поэтому ставим галочку напротив свойства “Препятствие”.

Т.к. скелет уже имеет свойство “Статичный”, то не имеет смысла добавлять свойство “Гравитация”.

“Зона телепорта” нам точно не нужна, поскольку мы не собираемся “ходить” по скелету, это и с точки зрения реалистичности было бы неправильно.

Свойства “Масса” и “Пружинность” здесь не играют особой роли, т.к. скелет не задействован во взаимодействии с другими объектами, поэтому оставим их значения по умолчанию.

 В итоге должна получиться следующая картина: 

Далее давайте в такой же логике продумаем свойства для органов:

Пользователь должен взаимодействовать с этими предметами, поэтому выставляем все галочки, связанные с контроллерами (забегая вперед, свойства “Можно использовать” и “Можно дотронуться” по факту не будут никак влиять на логику в сценарии, но с другой стороны и не помешают его реализации, поэтому давайте их оставим).

Поскольку органы будут располагаться близко (например, сердце и легкие), то нам важно, чтобы они не выталкивали друг друга из скелета и могли проходить насквозь и скелета, и других органов, поэтому выставляем галочку “Статичный”.

“Гравитация” нам так же не понадобится, т.к. органы должны “висеть” в скелете, иначе они упадут. Но в любом случае, поскольку объект “Статичный”, то гравитация не будет работать. Тем не менее уберем галочку со свойства “Гравитация” “для галочки”, чтобы не путаться в будущем.

“Зона телепорта” также нам не понадобится, логика здесь та же, что и для скелета.

Свойство “Препятствие” можно отключить, т.к. органы маленькие, и не будет ничего страшного, если пользователь сможет проходить сквозь них, возможно, в некоторых моментах, это будет даже удобнее.

“Масса” и “Пружинность” здесь также не важна, мы попробуем использовать эти свойства в следующих кейсах.

Самостоятельная работа: в третьем кейсовом задании мы уже выставляли свойства для UI-объектов, типа “Текст”. В текущем проекте также есть такие объекты. Продумайте почему мы выставили именно такие свойства, применяя дизайн-мышление, а также примите их в текущем проекте.

Сборка логики.

Теперь откроем редактор логики и снова обратимся к ТЗ:

Должна быть создана система оценки, позволяющая определить количество правильных ответов баллах.

Это значит, что нам необходимо будет не просто зафиксировать, что результат успешный/неуспешный как в предыдущем кейсе, а динамически определить результат в баллах.

Допустим, если мы поставили только один орган на свое место, а остальные перепутали, то результат будет “1 из 4”.

Для этого удобнее всего использовать переменную, которая будет хранить результат.

Ранее мы с Вами уже создавали переменную, для использования её в данном проекте, давайте сделаем это ещё раз.

“Итак, вы создали переменную и присвоили ей начальное значение в момент инициализации (запуска) приложения. Теперь осталось сформировать условия, при которых эта переменная будет изменяться.”

Для этого обратимся к новому типу блоков объектов из категории “События” на примере все тех же зон.

Создание логики для зон с помощью Событий.

Определение: События - это блок, который выполняет действие один раз при наступлении определенных условий, прописанных в архитектуре события.

 Для зоны данный блок выглядит так:

Архитектура события состоит из следующих пунктов:

1. Условие выполняется при совершении действия: объект вошел/вышел.
2. Выбор зоны в которую должен войти (или из которой должен выйти объект), задается условным оператором.
3. Параметр “zonetarget” - это переменная, которая определяется объектом. Например для зоны Мозг zonetarget = объект Мозг. Т.е. это объект, который должен войти в/выйти из зоны для активации события.

Давайте соберем первое событие для зоны “Мозг”.

Для этого выберем для пунктов события:

1. Событие: Вошел
2. Зона: Мозг
3. В тело события вставим блок, который будет проверять условие равна ли переменная zonetarget значению объекта “Мозг. Для этого выберем в категории “Объекты” “Любой” и используем самый верхний блок, выбрав из выпадающего списка объект “Мозг”.

Примечание: “Любые” объекты содержит блоки, которые можно применить абсолютно к любым объектам на сцене, в. т.ч. и к Игроку. Об этом мы поговорим подробнее в следующих кейсах. 

После этого необходимо в теле условного оператора определить действия, которые произойдут при его активации.

В данном случае, если мы помещаем в “Зону Мозг” объект “Мозг”, то мы все делаем верно, поэтому переменная “Результат” должна увеличиться на единицу.

Это очень частая задача в программировании логики приложения, поэтому она вынесена в отдельный блок:

Примечание: в других языках подобное действие также называют Инкремент, инкрементирование (от англ. increment «увеличение») — операция во многих языках программирования, увеличивающая переменную. Обратную операцию называют декремент (уменьшение). Чаще всего унарная операция приводит переменную к следующему элементу базового типа (то есть для целых чисел — увеличивает на единицу.

 Последнее, что нам следует сделать при активации события - это обновить текстовую панель с результатом.

Для этого вставьте блок “Задать текст” в объекте “Текст” в тело события и в поле “Текст” вставьте переменную “Результат”.

Таким образом, каждый раз когда событие будет активироваться, у нас будет обновляться результат на доске.

 Примечание 1: Вы уже могли сделать вывод о том, что переменные могут хранить разные типы данных: числовые, текстовые, объекты и др. Разные типы данных мы разберем в следующих кейсовых заданиях.

Примечание 2: особенность блоков из категории “Событие” заключается в том, что проверка происходит единоразово при наступлении соблюдения условия. Блок с условным оператором “Если” не подошел бы для реализации задуманной логики, поскольку он постоянно проверяет выполнено ли условие или нет, и если выполнено, то выполняет действия в теле этой логической конструкции. Т.е., если бы мы собрали конструкцию наподобие этой:

То результат бы бесконечно увеличивался на 1, пока объект “Мозг” находится в “Зоне Мозг”. В ситуации же событием, это происходит лишь один раз.

Самостоятельная работа: теперь соберите такие же события для всех остальных органов, чтобы получилась следующая картинка:

Создание финального сообщения.

Из ТЗ: Когда все органы будут на месте, то должно высветиться сообщение о победе.

Когда все органы будут на месте, значение переменной будет = 3. Это наше условие для вывода сообщения.

Для этого обратимся к новому блоку из категории “Логика”, который отвечает за сравнение (1).

Выберем блок “Сравнение” (2).

Примечание: этот блок можно развернуть и увидеть другие знаки сравнения.

Подставим этот блок напротив “Если” и добавим в пустые ячейки “Результат” = “3” (3). Напомним, что это блок из категории “Математика”.

Далее добавьте действие при выполнении условия, вы уже знаете как это сделать:

Тестирование проекта.

После того как вы применили логику, можно попробовать запустить проект.

Нужно понимать, что в этом проекте вы разработали более сложный проект, чем в предыдущих, поэтому повышается шанс возникновения ошибок и недочетов в сценарии - это нормально для процесса разработки, но крайне неверно, когда в конечном продукте присутствуют ошибки. Именно поэтому во время разработки любого проекта присутствует стадия тестирования.

Определение: Тестирование - это процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранных определенным образом.

В данном учебном курсе мы не будем глубоко погружаться в методику тестирования (или QA (от англ. quality assurance) — обеспечение качества), самое главное для Вас - это запомнить, что любой проект перед его финальной презентацией необходимо проверять несколько раз на наличие ошибок.

Запустите проект и попробуйте ответить на вопрос: что в проекте работает неправильно? Зафиксируйте эти замечания.

Наверняка вы найдете самый грубый недочет - это то, что переменная у нас увеличивается на 1 каждый раз, когда объект попадает в свою зону.

Это значит, что просто поместив и вынув “Мозг” 3 раза подряд можно победить, а что еще хуже, после победы, повторяя эти действия, переменная снова начнет увеличиваться на доске, что ну совсем не удовлетворяет нашему изначальному ТЗ:

Только когда все органы будут на месте, то должно высветиться сообщение о победе.

Давайте решим этот недочет с помощью дополнительных блоков, которые будут отнимать на 1 значение переменной при выходе целевого объекта из своей зоны:

Примечание: когда мы отнимаем от результата единицу - это называется “Декремент”, обратная операция по отношению к “Инкременту”.

Если вы все сделали правильно, то при размещении всех органов вы увидите следующую картину:

Контрольные вопросы (выборочно можно использовать на этапе рефлексии, для проверки усвоения знаний, полученных на занятии):

1. Что такое тестирование проекта? Что под собой подразумевает этот термин?
2. Как можно было по-другому реализовать систему оценки правильности расположения объектов/органов на скелете?
3. Что такое “zonetarget” и как он работает?
4. Сколько раз нужно проводить тестирование проекта?
5. Что такое инкремент и декремент?
6. Что будет если включить свойство “гравитация” для объекта без включенного свойства “препятствие”?