2 раздел анализ предметной области 5



Скачать 11.53 Mb.
страница4/4
Дата27.10.2016
Размер11.53 Mb.
Просмотров406
Скачиваний0
ТипДипломная работа
1   2   3   4


РАЗДЕЛ 4. ОТЛАДКА ПРОГРАММНОГО КОДА




  1. Основные понятия

Отладка – это процесс выявления и исправления ошибок в программном обеспечении.


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

  • Логирование в среде Unity3D и визуальный контроль;

  • Использование отладчика в среде разработки Visual Studio 2012.



  1. Отладка программного кода с помощью логирования в Unity3D

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

Сборка происходит автоматически при выявлении изменений в исходном коде. Это позволяет, выявить ошибки на раннем этапе.

Такой механизм называется – статический анализ кода.



c:\users\asus\desktop\сохраненное изображение 2013-6-2_2-54-13.720.jpg

Рисунок 4.1. Консоль Unity3D.
Если была обнаружена ошибка на этапе компиляции, Unity3D сообщит нам об этом в консоль, так же укажет причину и место ошибки. Такой подход позволит нам быстро выявить и исправить проблему, что является очень полезным.

Для лучшего восприятия Unity3D использует уровень логирования.

Это графическая классификация для оповещения разработчика.

Существуют следующие уровни для сообщений:



c:\users\asus\desktop\levels_cr.png

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

Пример:


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

Для вывода информации в консоль (лог) используется объект Debug и

его методы:


  • Log (Информационный уровень);

  • LogError(Уровень ошибок);

  • LogWarning (Уровень предупреждений).

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



c:\users\asus\desktop\сохраненное изображение 2013-6-2_3-42-59.812.jpg

Рисунок 4.3. Компонент лестница в редакторе Unity3D.
Для отображения сообщений мы можем использовать информационный уровень логирования. Использую Debug.Log, получим данные о лестнице и выведем лог, зная, что нажимая на кнопку “Пересобрать лестницу” вызывается определённый обработчик, который отвечает за компоновку лестницы и сбор данных, например, сортировка ступеней, расчёт габаритов и угла наклона.

Добавим код логирования в метод сборки лестницы и проверим результат для разных случаев:


Debug.Log("Количество ступеней: " + ChildrenPositions.Count);
Debug.Log("Габариты ступени: \n" + "Ширина: " + StepWidth + " Высота: " + StepHeight

+ " Длина: " + StepLenght);
Debug.Log("Габариты лестницы: \n" + "Ширина: " + (StepWidth * ChildrenPositions.Count) + " Высота: " + (StepHeight * ChildrenPositions.Count)

+ " Длина: " + StepLenght);
Debug.Log("Угол наклона: " + Angle);
Добавим код логирования в метод сборки лестницы и проверим результат для разных случаев:

c:\users\asus\desktop\сохраненное изображение 2013-6-2_4-1-14.650.jpg

c:\users\asus\desktop\сохраненное изображение 2013-6-2_4-3-6.720.jpg

c:\users\asus\desktop\сохраненное изображение 2013-6-2_4-4-36.788.jpg

Рисунки 4.4. – 4.6. Результаты работы логирования.
Анализ полученной информации позволит проверить правильность данных, Например с помощью ручного расчёта.

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

Логирование не позволяет останавливать поток работы игры и изменять данные, это недостаток исчезает, если использовать инструмент отладки, который мы рассмотрим в следующем разделе.



  1. Использование отладчика в среде разработки Visual Studio 2012

Специальный механизм отладки для Unity3D – UnityVS позволяет контролировать поток работы программы. То есть мы получаем возможность непосредственно контролировать каждый шаг. Для этого нам надо включить среду разработки в режиме отладки:



c:\users\asus\desktop\сохраненное изображение 2013-6-2_4-40-6.253.jpg

Рисунок 4.7. Отладчик, готовый к работе.
Сейчас система готова и может перехватить поток, и пока разработчик не закончит отладку, программа будет пошагово выполняться.

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



c:\users\asus\desktop\сохраненное изображение 2013-6-2_4-43-41.576.jpg

Рисунок 4.8. Точка останова.
Выполнение программы остановится здесь (красная точка), пока разработчик не продолжит работку программы. Для трассировки используется несколько подходов управления потоком:

  • Пошаговое перемещение по потоку только в контексте кода;

  • Пошаговое перемещение по потоку c проходом всех вызовов методов;

  • Перемещение до точки останова (точка прерывания);

  • Перемещение обратно на один шаг или до точки останова.

Так же существуют и другие подходы, но обычно этого достаточно.

Запустим игру в режиме отладки и посмотрим, какие возможности нам даст этот инструмент:

c:\users\asus\desktop\сохраненное изображение 2013-6-2_4-53-56.413.jpg

Рисунок 4.9. Отладчик в рабочем режиме.
С помощью этого инструмента можно:


  • Повлиять на направление потока программы;

  • Просмотреть стек вызова “Call Stack” (позволяет отследить путь и пройти его заново для выявления проблем);

  • Просмотреть и изменить значения переменных “Locals”.



  1. Выводы

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



РАЗДЕЛ 5. КОНТРОЛЬНЫЙ ПРИМЕР




    1. Введение

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


Буду представлены следующие сцены:

  • Одиночные взаимодействия и состояния;

  • Обработка триггеров и отложенный запуск события;

  • Комплексные взаимодействия.



    1. Одиночные взаимодействия и состояния

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



c:\users\asus\desktop\сохраненное изображение 2013-6-2_21-34-9.571.jpgc:\users\asus\desktop\сохраненное изображение 2013-6-2_21-34-20.615.jpg

Рисунки 5.1- 5.2. Объект не готов к взаимодействию (слева) и объект готов к взаимодействию (справа).
На рисунке 5.1, объект не готов к взаимодействию, а на рисунке 5.2. готов, на котором это состояние свидетельствует красный цвет.

Как только канал связи налажен, мы можем отправить сообщение, объекту взаимодействия, нажав на левую клавишу мыши. Это будет событие типа “Action”, на которое данный объект отреагирует заранее запрограммированными действиями. В данном случае это получение физической силы по направлению камеры, то есть предмет отлетит на некоторое расстояние. Есть возможность передавать не только тип события “Action”, но и количество силы, приложенное к объекту.



c:\users\asus\desktop\сохраненное изображение 2013-6-2_21-42-57.75.jpg

Рисунок 5.3. Результат взаимодействия.

Так же мы снова рассмотрим изменения состояния на примере объекта дверь.



c:\users\asus\desktop\сохраненное изображение 2013-6-2_21-45-24.411_cr.jpg

Рисунок 5.4. Общий вид сцены (дверь закрыта).

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



c:\users\asus\desktop\сохраненное изображение 2013-6-2_21-48-20.149.jpg

Рисунок 5.5. Дверь готова к взаимодействию.
Дверь готова к коммуникации, так как об этом нас свидетельствует жёлтый цвет. Теперь, чтобы начать взаимодействие с дверь достаточно отправить ей сообщение (то есть нажать на левую клавишу мыши).

c:\users\asus\desktop\сохраненное изображение 2013-6-2_21-53-53.22.jpg

Рисунок 5.6. Дверь в состоянии “Открывается”.
Дверь отреагировала на начала открываться. Она в состоянии “Открывается”.

Как только дверь полностью откроется, это определяется анимацией, она перейдёт в состояние “Открыта”.



c:\users\asus\desktop\сохраненное изображение 2013-6-2_21-53-11.466.jpg

Рисунок 5.7. Дверь в состоянии “Открыта”.
Состояние “Открывается” нельзя прервать пользователем, открытую дверь, нельзя открыть снова, если её не закрыть. Состояния инкапсулируют и изменяют поведение объекта внутри себя.

    1. Обработка триггеров и отложенный запуск события

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



c:\users\asus\desktop\сохраненное изображение 2013-6-2_23-26-46.159.jpg

Рисунок 5.8. Графический вид компонента лестница.
Рассмотрим этот объект подробнее:

c:\users\asus\desktop\сохраненное изображение 2013-6-2_23-36-41.185.jpg

Рисунок 5.9. Настройки для компонента лестница.


  • С помощью аргумента Duration можно контролировать длительность анимации;

  • Start Delay позволяет запустить событие отложено, то есть через некоторое время;

  • First Step – это объект для подсчёта габаритов ступеней;

  • Slope – интерполяционный объект для выравнивая лестницы;

  • Switch – объект, который сообщает лестнице, а том, что ей надо отреагировать и выполнить свои действия (триггер);

  • Easy type – метод изменения координат вовремя анимации для улучшения реализма;

  • Up – ориентация лестницы (вверх или вниз).

Изначально лестница опущена или поднята (в зависимости от ориентации), если у лестницы нет триггера (Switch), то она начинает подниматься или опускаться через время Start Delay (в секундах) за время Duration (то же в секундах). Чтобы поднять или опустить лестницу, когда пользователь это захочет, тут нам на помощь приходят триггеры:


c:\users\asus\desktop\сохраненное изображение 2013-6-2_23-32-19.168_cr.jpg

Рисунок 5.10. Триггер в виде огня.
Данный объект обладает геометрической фигурой “сфера”, а так же является триггером, который можно добавить к лестнице с помощью простого Drag and Drop.

c:\users\asus\desktop\сохраненное изображение 2013-6-3_0-1-21.350.jpg

Рисунок 5.11. Пример лестницы с триггером
Данная лестница будет опущена до тех пор, пока игрок не войдёт в триггер Flame3, который сообщит лестнице, что ей надо подниматься.

c:\users\asus\desktop\сохраненное изображение 2013-6-3_0-5-6.429.jpg

Рисунок 5.12. Лестница поднимается после активации триггера.
Персонаж зашёл в триггер Flame3, тем самым инициализировал событие и лестница начала подниматься.

    1. Комплексные взаимодействия

В данном примере мы будем посылать несколько событий объектам взаимодействия:



  • Левая клавиша мыши – событие совершения действия “Action”;

  • Колесо вверх мыши – событие увеличения уровня звука “WheelUp”;

  • Колесо вниз мыши – событие уменьшения уровня звука “WheelDown”.


c:\users\asus\desktop\сохраненное изображение 2013-6-3_0-12-42.726.jpg

Рисунок 5.13. Сцена в исходном состоянии.
На сообщения, представленные выше, может реагировать объект RadioWheel:

c:\users\asus\desktop\сохраненное изображение 2013-6-3_0-13-59.601.jpg

Рисунок 5.14. Объект RadioWheel.

Если отправить сообщение (нажатие на левую клавишу), объект RadioWheel принимает его и передает дальше, сообщая остальным объектам, что событие произошло:



  • включается музыка;

  • начинает падать снег;

  • дует ветер.

c:\users\asus\desktop\сохраненное изображение 2013-6-3_0-44-55.522.jpg

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



ЗАКЛЮЧЕНИЕ


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

Данная концепция хорошо показала себя на этапе разработки. Изначально правильный ход со слабой связанностью хорошо отразился на гибкости и масштабируемости модели. Это позволило легко сопровождать текущий проект и добавлять новые изменения. Полиморфный интерфейс обмены сообщениями, позволяет создавать какие угодно вариации на основе обобщений. Поддержка состояний объектов придает сложное поведение объектам, каждое состояние обрабатывает только в контексте родителя и самого состояния, что позволяет разработчиками не заботиться о других, а работать только в этом контексте. Состояния могут быть добавлены и удалены в любой момент. Так же эта система может быть использована для придания интеллекта игровым объектам, то есть создания A.I.



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

СПИСОК ЛИТЕРАТУРЫ




  1. Sue Blackman “Beginning 3DGame Development with Unity” 2011;

  2. Will Goldstone “Unity Game Development Essentials” 2009;

  3. Стиллмен Э., Грин Дж. - Изучаем C#. Включая C# .NET 4.0 и Visual Studio 2010. 2-е издание (Бестселлеры O'Reilly) – 2012;

  4. Фримен Эр., Фримен Эл., Сьерра К., Бейтс Б. - Паттерны проектирования – 2011;

  5. “История развития компьютерных игр” http://www.igrover.ru/node/503;

  6. Wikipedia – “Компьютерная игра” http://ru.wikipedia.org/wiki/Компьютерная_игра;

  7. “Игровая терминология” http://www.intuit.ru;

  8. Wikipedia – “Компьютерная игра Dreamfall: The Longest Journey” http://ru.wikipedia.org/wiki/Dreamfall:_The_Longest_Journey;

  9. Wikipedia – “Microsoft Visual Studio” http://ru.wikipedia.org/wiki/CSharp;

  10. Wikipedia – “Язык программирования C#” http://ru.wikipedia.org/wiki/CSharp;

  11. “Система обмена сообщениями в игре” http://wiki.unity3d.com/index.php/Advanced_CSharp_Messenger.


Поделитесь с Вашими друзьями:
1   2   3   4


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал