Размещено на http://www.allbest.ru/

Федеральное государственное автономное образовательное учреждение высшего образования

Национальный исследовательский университет

Высшая школа экономики

НИУ ВШЭ-Нижний Новгород

Курсовая работа

На тему «Разработка медицинского программного обеспечения на основе технологий виртуальной реальности для пациентов с функциональным головокружением»

Студент

Гладун Н.А.

Нижний Новгород 2019



Оглавление

Введение

1. Техническое задание

1.1 Исследование предметной области. Функциональное головокружение

1.2 Исследование предметной области. Виртуальная реальность

1.3 Постановка задачи

1.4 Требования к курсовому проекту

1.5 Анализ технического задания

2. Разработка программы

2.1 Уровень с морем. Локация

2.2 Уровень с морем. Скрипты

3. Эксплуатационная документация

3.1 Меню оператора

3.2 Интерфейс игрока

Заключение

Список литературы

Приложение



Введение

За последние два десятилетия информационные технологии совершили огромный скачок и стали играть всё большую роль в самых разных сферах человеческой жизни. Сейчас огромную популярность набирает технология Виртуальной Реальности (здесь и далее - VR). Ей уже нашли немало различных применений, но эта сфера всё ещё остаётся недостаточно исследованной и крайне перспективной.

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

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



1. Техническое задание

1.1 Исследование предметной области. Функциональное головокружение

Функциональное головокружение было впервые зафиксировано в статье «Phobischer Attacken-Schwankschwindel, ein neues. Syndrom» в 1986 году. Авторы статьи, Brandt и Dieterich, использовали термин «фобическое постуральное головокружение» для определения хронического невесибулярного колебательного головокружения, вызванного внешними (социальными или ситуативными) стимулами, которое не может быть объяснено органическими отоневрологическими расстройствами.

Только в 2015 году Brandt и его коллеги в статье «Functional dizziness: diagnostic keys and differential diagnosis» окончательно сформулировали определение и дали заболеванию официальное название - «постоянное постурально-перцептивное головокружение». В той же статье впервые был использован термин «функциональное головокружение» в качестве более простого и доступного общественности названия заболевания.

Функциональное головокружение включает в себя большой спектр симптомов, обнаруженных и задокументированных разными учёными и врачами в разные периоды времени. Далее указан весь список возможных симптомов со ссылками на статьи, в которых они впервые были упомянуты: приступообразные эпизоды нестабильности с ощущением ступора, угасания, легкости в голове или тошноты, возникающие при ходьбе или резком подъёме (Brandt и другие, 2009); постоянное и выраженное чувство головокружения в голове, продолжающееся в положении лежа (Staab, Ruckenstein, 2005); чувство головокружения и нестабильности при поездках в транспорте; сочетание головокружения с симптомами брутибула (Staab, 2000); отсутствие объективных признаков нарушения равновесия при неврологическом обследовании: диссоциация между объективными тестами и субъективным ощущением нестабильности; агорафобия и избегающее поведение; повышенное ощущение головокружения или избегания поведения в определенных обстоятельствах (например, в магазинах, театрах, на открытых пространствах, на высоте или под землей) или после стресса или конфликта; уменьшение симптомов во время физической активности, отвлечения или после небольшой дозы алкоголя (Brandt и другие, 2009); использование постуральных контрольных стрессовых стратегий; страх падений без падений в анамнезе; необоснованная и чрезмерная забота о будущем; отсутствие нистагма при вращательном головокружении; необычная или эксцентричная осанка или походка (Balaban и другие, 2013).

На данный момент существует пять известных методов борьбы с функциональным головокружением: образовательные программы, призванные дать пациенту понять причину головокружения и частично помочь преодолеть его (Brandt и другие, 2009); психотерапия (Edelman и другие, 2011); фармакотерапия (Staab, 2006), а также снижение повышенного чувства нестабильности и вестибулярная гимнастика. Согласно исследованиям (Thompson и другие, 2012), последние два метода показывают наилучшие результаты - в среднем 60% человек отмечают значительные улучшения после прохождения лечения по этим методам.

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

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

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

1.2 Исследование предметной области. Виртуальная реальность

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

Во-первых, необходимо было сделать достаточное количество сцен, чтобы показать функционал движка Unity, а также иметь возможность уже с прототипа погружать пациентов в различные ситуации. Моей задачей была работа над сценой, симулирующей плавание на лодке и морскую качку. Мной была выбрана именно эта сцена, поскольку она соответствовала следующим критериям: полезность (морская качка - серьёзный симптом функционального головокружения, и погружение в такую обстановку должно помочь пациентам научиться переживать стрессовые ситуации), доступность тематических бесплатных моделей для Unity (несколько вариантов сцен были отброшены, поскольку для них не удалось найти подходящих моделей), многофункциональность (возможность менять управление игровым персонажем, отдавая его пациенту, либо оператору, отлично вписывается в легенду сценки - вёсельной лодкой пациент управляет сам, в то время, как контроль над моторной принадлежит оператору) и удобство исполнения (управление вёслами за счёт джойстиков даёт больше возможностей, чем физическое перемещение игрока по игровому миру с помощью VR шлема, так как позволяет создать игровой мир больших размеров, не сковывая себя размерами комнаты или длинной провода VR шлема). Во-вторых, необходимо было сделать меню, в котором оператор сможет настраивать параметры сцены. Нами было выбрано четыре параметра, доступные для изменения в сцене с морем - это непосредственная скорость лодки, скорость ветра (влияющая на скорость морской качки), сила качки (влияющая на угол отклонения лодки при качке) и способ управления лодкой (по заданному маршруту или игроком с помощью джойстиков).

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

1.3 Постановка задачи

Создать рабочий прототип игрового приложения в виртуальной реальности для помощи в адаптации пациентов с функциональным головокружением. Приложение должно содержать в себе: сцену в море с возможностью управления лодкой как через заданную оператором программу, так и вручную джойстиками; меню, позволяющее оператору настраивать сцену соответственно рекомендациям врача; запись видео в процессе работы с приложением и детальное логирование серьёзнейших изменений, содержащее в себе временные метки.

1.4 Требования к курсовому проекту

Функциональные требования:

1. Оператору доступна сцена, содержащая в себе путешествие пациента в виртуальной реальности на лодке.

2. Управление в сцене может быть в руках как оператора, так и пациента.

3. Сцена должна содержать в себе симуляцию морской качки, т.е. лодка должна раскачиваться при движении.

4. Оператор может вручную задавать скорость движения лодки и волн, а также амплитуду качки.

5. Весь процесс работу с приложением записывается на видео.

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

Количественные требования:

1. Приложение доступно лишь для одного пользователя одновременно.

2. Скорость лодки измеряется в километрах в час и не может быть меньше 0 км/ч. Верхней границы нет.

3. Скорость ветра измеряется в метрах в секунду и не может быть меньше 0 м/с. Верхней границы нет.

4. Сила качки измеряется в абстрактных единицах, а её значение находится в интервале от 0 до 20.

Требования совместимости:

Планируется совместимость приложения исключительно с HTC Vive и семейством систем Windows.



1.5 Анализ технического задания

В начале работы мы провели исследование, чтобы определить, какой игровой движок использовать в своей работе. В качестве двух вариантов рассматривались Unity и Unreal Engine 4, поскольку они оба являются бесплатными и предлагают наибольший функционал из всех, существующих на сегодняшний день.

Первым пунктом, по которым мы анализировали движки, стал язык программирования, на котором пишутся скрипты для каждого из них. В случае Unity это C#, в то время как Unreal Engine использует C++. Оба эти языка на момент начала разработки были хорошо нам знакомы и, в рамках данной задачи, они не имеют существенных различий, поэтому по данному пункту нам в равной степени подходили оба движка.

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

И последним, на что было обращено внимание, оказались системные требования. Unreal Engine 4 потребляет значительно больше ресурсов, чем Unity, что сказывается на низкой работоспособности этого движка на слабых компьютерах, или же полном её отсутствии. Поскольку в нашем распоряжении были лишь домашние компьютеры, не обладающие мощными вычислительными мощностями, мы остановились на движке Unity, обладающем всеми необходимыми нам функциями при меньших системных требованиях.

Когда вопрос с инструментарием был решён, предстояло принять ещё одно решение - давать ли в наших сценах возможность пациентам самостоятельно перемещаться по игровому миру, или же дать оператору полный контроль над ситуацией. Этот вопрос был рассмотрен со многих сторон.

Если пациент обладает возможностью перемещаться по сцене самостоятельно, это значительно усиливает его погружение, что крайне положительно сказывается на успешности симуляции. В то же время, это порождает несколько проблем. Во-первых, находясь в закрытой комнате и будучи привязанным к оборудованию и VR-шлему, пациент находится в своеобразной «скованности», поскольку его действия и свобода перемещения ограничены стенами и длинной шнура - а, следовательно, ограничены так же размер сценки и наши возможности для её разработки. В-вторых, это также ограничивает функционал сцены, поскольку не даёт возможности оператору изменять скорость и амплитуду движения. В-третьих, становится невозможным симуляция движения вокруг пациента, такого, как качающийся пол.

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

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



2. Разработка программы

2.1 Уровень с морем. Локация

Мы были ограничены исключительно бесплатными 3D-моделями расширения .fbx, которые можно было найти в Unity Asset Store и на просторах интернета, что сделало невозможным внедрение в приложение фотореалистичной графики. Тем не менее, мы постарались подобрать такие текстуры и модели, чтобы у пользователя не пропадало ощущение погружения.

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

Перед нами встало два возможных решения проблемы - растянуть существующее изображение по всей поверхности моря или создать множество объектов («плиток») с отдельными текстурами и объединить их в один. Первый вариант оказался нерелевантным, поскольку растянутая текстура выглядела совершенно нереалистично и не создавала ощущения моря. В то же время, вариант со множеством объектов, кроме отсутствия этой проблемы, так же позволял упростить создание ощущения морской качки и движения волн (об этом будет подробнее рассказано в пункте «реализация». Таким образом, мы остановились на втором варианте, и именно он был воплощён в итоговом приложении.

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

Когда было принято решение о создание кольца из гор и серии каменных декоративных препятствий, перед нами встал о вопрос о выборе 3D-моделей для них. Проблема заключалась не только в ограниченном наборе, из которого мы имели возможность выбирать модели для скал, но и в том, что они должны были соответствовать определённым признакам.

Во-первых, нам не подходили модели низкого качества, поскольку их присутствие на карте негативно влияло на погружение, не позволяя игроку в полной мере ощутить реальность происходящего.

Во-вторых, моделей должно было быть определённое количество (как минимум пять), чтобы была возможность создать ощущение реального горного массива, а не кольца из множества одинаковых камней.

В-третьих, стилистика и цветовая палитра моделей должны были совпадать.

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



Рисунок 1 - Модели скал

1) Arch. Модель каменной арки. Она рассматривалась на добавление в сцену, но не попала в финальную версию, поскольку для того, чтобы дать лодке возможность проплыть под аркой, арку пришлось бы очень сильно увеличить, из-за чего она занимала бы слишком много места и мешала полноценному изучению сцены. При этом, как обычный декоративный элемент, арка не гармонировала с прочими моделями, и от неё пришлось отказаться.

2) Stone. Качественная модель каменного уступа. Она была добавлена в сцену, однако её текстура, для соответствия, была заменена на ту, что используется в Rock_Pack2.

3) Rock_Pack1. Набор скал и камней, включающий одну арку. В финальную версию не попал, поскольку модели в этом наборе оказались недостаточно качественными и реалистичными.

4) Rock_Pack2. Набор скал и камней, также включающий одну арку. Именно из скал этого набора (с добавлением Stone) был создан итоговый горный массив. Кроме того, арка из этого набора стала той каменной аркой, под которой может проплыть игрок на своей лодке.

Рисунок 2 - Сцена с морем, вид сверху.

Рисунок 3 - Морской пейзаж, вид из лодки. Рисунок 4 - Каменная арка.



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

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

Рисунок 5 - Модели лодок и вёсел

1) Boat1. Потрёпанная, старая лодка с реалистичной текстурой. Эта лодка подходила для нас идеально, и именно она попала в итоговую сцену.

2) Boat2. Очень хорошая модель с качественной текстурой, однако, не подошла для нашего приложения - из-за низких бортов не удавалось сделать достаточно сильную качку - лодка просто начинала погружаться под воду, что шло в разрез с реальной физикой и разрушало погружение.

3) BoatWithOars. Эта модель рассматривалась нами в первую очередь, поскольку сразу содержала в себе и лодку, и вёсла. Однако, проблемой стала отсутствие текстур на модели лодки. У нас не было возможности создать свою текстуру, а текстуры с других моделей на этой смотрелись нереалистично. Однако, модели вёсел оказались очень качественными, и текстура с сидений в Boat1 отлично подошла для них, поэтому именно эти вёсла были использованы в итоге.

4) Oar. Модель весла, которая рассматривалась нами как вариант на добавление в сцену. Однако, вёсла в модели BoatWithOars оказались качественнее.

5) StrangeBoat. Необычная модель, которая рассматривалась в качестве альтернативы выбранной нами лодке. Однако, эта модель не вписывалась в окружение, и потому от неё отказались.

6) Canoe. Ещё одна альтернативная модель лодки. Модель Boat1 оказалась более качественной, поэтому итоговый выбор пал на неё.

2.2 Уровень с морем. Скрипты

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

Скрипт, ограничивающий перемещение воды, привязан к каждой конкретной «плитке» моря (выше говорилось о том, что море является не цельным объектом, а набором «плиток»). Когда эта «плитка» оказывается за пределами видимости (скрывшись за горным кольцом), скрипт активируется и перемещает её обратно в начало карты, также за пределы горного кольца, из-под которого она появится через какое-то время. Таким образом, море всё время движется вперёд, но никогда не исчезает.

Следующим, крайне важным скриптом, является тот, что отвечает за движение вёсел. Каждый раз, когда лодка поворачивается в одну из сторон, активируется скрипт, привязанный к соответствующему веслу. Это весло совершает круговое движение, погружаясь в воду и появляясь из неё, что соответствует реальным движениям гребца. Скрипт также активируется для обоих вёсел, когда происходит движение вперёд.

Отвечающий за движение скрипт имеет три разных режима работы - 'manual', 'operator' и 'player'. Режим `manual' означает непосредственный контроль движений лодки с помощью клавиш клавиатуры и использовался исключительно в тестовых целях (в финальной версии программы вся информация о нём скрыта, но он всё ещё доступен). Режим `operator' позволяет оператору задать скорость движения лодки и углы её поворотов. Пользователь при этом может только поворачивать голову. Режим `player' даёт пользователю возможность управлять вёслами с помощью джойстиков.

Вне зависимости от выбранного режима, в скрипте, отвечающем за движение, присутствуют четыре глобальные переменные. Переменная «control_type» отвечает как раз за режим работы, как указано в предыдущем абзаце. Переменная «speed» отвечает за скорость лодки. На неё умножается расстояние, проходимое лодкой при использовании игроков двух джойстиков сразу или угол поворота лодки при использовании только одного. Переменная «power_water» отвечает за силу качки. На неё умножается угол, на который отклоняется лодка при качке. Переменная «speed_water» отвечает за скорость ветра. На неё умножается скорость, с которой происходит качка. Значения для всех четырёх переменных задаются оператором в меню непосредственно перед запуском сцены.

3. Эксплуатационная документация

3.1 Меню оператора

Рисунок 6 - Меню оператора.

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

Кнопка меню оператора «Запуск»

Рисунок 7 - Кнопка «Запуск».

При нажатии на эту кнопку запускается сцена «Море» с заданными оператором параметрами. Оператор имеет возможность в любой момент снова вызвать меню по нажатию клавиши «esc» на клавиатуре.

Элемент меню оператора «Скорость качки»

Рисунок 8- Элемент «Скорость качки».



Нажимая на кнопки «-» и «+» оператор может, соответственно, уменьшать или увеличивать скорость качки на 1 м/с. Текущее значение скорости качки указано между кнопками. Минимальное возможное значение 0 м/c, на максимальное значение ограничений нет.

Элемент меню оператора «Скорость лодки»

Рисунок 9 - Элемент «Скорость лодки».

Нажимая на кнопки «-» и «+» оператор может, соответственно, уменьшать или увеличивать скорость лодки на 1 км/ч. Текущее значение скорости лодки указано между кнопками. Минимальное возможное значение 0 км/ч, на максимальное значение ограничений нет.

Элемент меню оператора «Сила качки»

Рисунок 10 - Элемент «Сила качки».

Нажимая на кнопки «-» и «+» оператор может, соответственно, уменьшать или увеличивать силу качки на 1 условную единицу. Текущее значение силы качки указано между кнопками. Минимальное возможное значение 0, максимальное возможное значение 20.

Кнопка меню оператора «Режим управления»

Рисунок 11 - Кнопка «Режим управления».

Нажатие на эту кнопку меняет текущий режим управления. Всего в приложении доступно два режима управления - «Игрок» и «Оператор» (режим физического управления с помощью клавиатуры доступен только при непосредственном редактировании кода). При переключении режима меняется надпись на кнопке.

3.2 Интерфейс игрока

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

В режиме же самостоятельного управления он всё также может двигать головой, но, также, ещё и перемещаться на лодке, управляя вёслами с помощью кнопок на джойстиках. Нажатие кнопки на одном джойстике осуществляет движение соответствующим веслом и поворот в соответствующую сторону. Нажатие же одновременно на обе кнопки выполняет движение обоими вёслами и движение вперёд.

Кроме того, в этом режиме оператор может в любой момент нажать клавишу «esc» на клавиатуре, чтобы открыть меню оператора.



Заключение

Приложение полностью завершено и готово к работе. Все необходимые функции были реализованы. Графика находится на достаточно реалистичном уровне, чтобы создать эффект погружения. Этому также способствует движение волн и наличие скал.

Финальное исследование показало, что технология Виртуальной Реальности представляет хорошие результаты в терапии функционального головокружения. В дальнейшем планируется развитие и совершенствование приложения, добавление новых функций и сцен, в зависимости от рекомендаций и запросов практикующих врачей.

Кроме того, перспективным является развитие приложения «в ширь», то есть расширение возможностей для лечения разнообразных заболеваний, не ограниченных только функциональным головокружением, а, также, терапии после пережитой операции.



Список литературы

1. Brandt, T., Dieterich, M., (1986), «Phobischer Attacken-Schwankschwindel, ein neues. Syndrom. Munich: Mьnch Med Wochenschr»

2. Brandt, T., Huppert, D., Strupp, M., Dieterich, M., (2015). «Functional dizziness: diagnostic keys and differential diagnosis. Munich: J Neurol»

3. Brandt, T., Dieterich, M., Strupp, M., (2009). «Vertigo. Munich: Praktika»

4. Staab, J. P., Ruckenstein, M. J., (2005). «Chronic dizziness and anxiety: Effect of course of illness on treatment outcome. Rochester: Archives of Otolaryngology -- Head & Neck Surgery»

5. Staab, J. P., (2000). «Diagnosis and treatment of psychologic symptoms and psychiatric disorders in patients with dizziness and imbalance. Rochester : Otolaryngol. Clin. North Am»

6. Balaban, C., Furman, J., Staab, J., (2013). «Threat Assessment and Locomotion: Clinical Applications of an Integrated Model of Anxiety and Postural Control. Rochester: Seminars in Neurology»

7. Edelman, S., Mahoney, A. E. J., Cremer, P. D., (2012). «Cognitive behavior therapy for chronic subjective dizziness: a randomized, controlled trial. New York: American Journal of Otolaryngology»

8. Staab, J. P., (2006). «Chronic dizziness: The interface between psychiatry and neurootology. Rochester: Current Opinion in Neurology»



Приложение

Внутренний скрипт движения воды

using System.Collections;

using System.Collections.Generic;

using UnityEngine;

public class Water_Moving_Back : MonoBehaviour {

// Use this for initialization

void Start () {

}

IEnumerator Water()

{

for (int i = 0; i<1000; i++)

{

transform.Translate(Vector3.forward/100);

yield return new WaitForSeconds(1);

transform.Translate(Vector3.back/100);

}

}

// Update is called once per frame

void Update () {

StartCoroutine(Water());

}

}

Внешний скрипт движения воды

using System.Collections;

using System.Collections.Generic;

using UnityEngine;

public class Water_Returning : MonoBehaviour {

// Use this for initialization

void Start () {

}

// Update is called once per frame

void Update () {

if (transform.position.z > 350)

{

transform.Translate(Vector3.down*360);

}

}

}

Движение лодки (включая качку)

using System.Collections;

using System.Collections.Generic;

using UnityEngine;

public class Boat_Move : MonoBehaviour {

public int time_spent;

// Use this for initialization

void Start () {

time_spent = 0;

}

// Update is called once per frame

void Update () {

int speed = MenuButtons.Params.speed;

int speed_water = MenuButtons.Params.speed_water;

int power_water = MenuButtons.Params.power_water;

time_spent++;

if (time_spent == 180*power_water + 1)

{

time_spent = 0;

}

if ((time_spent < 40*power_water + 1) || (time_spent > 140*power_water))

{

//transform.Rotate(Vector3.left/100);

transform.Rotate(Vector3.forward/500*speed_water);

}

if ((time_spent > 50*power_water) && (time_spent < 150*power_water + 1))

{

//transform.Rotate(Vector3.right/100);

transform.Rotate(Vector3.back/500*speed_water);

}

/*if ((time_spent < 51) || ((time_spent > 150) && (time_spent < 201)))

{

//transform.Rotate(Vector3.left/100);

transform.Rotate(Vector3.forward/100);

}

if (((time_spent > 75) && (time_spent < 126)) || ((time_spent > 225) && (time_spent < 276)))

{

//transform.Rotate(Vector3.right/100);

transform.Rotate(Vector3.back/100);

}*/

string control_type = "manual";

//Options - 'manual', 'operator', 'player'

if (control_type == "manual")

{

if (Input.GetKey(KeyCode.W))

{

transform.Translate(Vector3.forward/50*speed);

}

if (Input.GetKey(KeyCode.S))

{

transform.Translate(Vector3.back/500*speed);

}

if (Input.GetKey(KeyCode.A))

{

transform.Rotate(Vector3.down/100*speed);

}

if (Input.GetKey(KeyCode.D))

{

transform.Rotate(Vector3.up/100*speed);

}

}

}

}

Работа с внешним интерфейсом (кнопки)

using System.Collections;

using System.Collections.Generic;

using UnityEngine;

using UnityEngine.SceneManagement;

public class MenuButtons : MonoBehaviour {

// Use this for initialization

void Start () {

}

// Update is called once per frame

void Update () {

}

public static class Params

{

public static int speed = 5;

public static int speed_water = 5;

public static int power_water = 5;

}

public void PlayPressed()

{

SceneManager.LoadScene("Boat");

}

public void SpeedPlusPressed()

{

Params.speed++;

}

public void SpeedMinusPressed()

{

if (Params.speed>0) Params.speed--;

}

public void SpeedWaterPlusPressed()

{

Params.speed_water++;

}

public void SpeedWaterMinusPressed()

{

if (Params.speed_water>0) Params.speed_water--;

}

public void PowerWaterPlusPressed()

{

if (Params.power_water<20) Params.power_water++;

}

public void PowerWaterMinusPressed()

{

if (Params.power_water>0) Params.power_water--;

}

}

Работа с внешним интерфейсом (текст)

using System.Collections;

using System.Collections.Generic;

using UnityEngine;

using UnityEngine.UI;

public class Speed_Value : MonoBehaviour {

// Use this for initialization

void Start () {

}

// Update is called once per frame

void Update () {

GetComponent<Text>().text = MenuButtons.Params.speed.ToString() + " км/ч";

}

}

using System.Collections;

using System.Collections.Generic;

using UnityEngine;

using UnityEngine.UI;

public class Speed_Water : MonoBehaviour {

// Use this for initialization

void Start () {

}

// Update is called once per frame

void Update () {

GetComponent<Text>().text = MenuButtons.Params.speed_water.ToString() + " м/с";

}

}

using System.Collections;

using System.Collections.Generic;

using UnityEngine;

using UnityEngine.UI;

public class Power_Water : MonoBehaviour {

// Use this for initialization

void Start () {

}

// Update is called once per frame

void Update () {

GetComponent<Text>().text = (20-MenuButtons.Params.power_water).ToString();

}

}

Размещено на Allbest.ru

...