• АННОТАЦИЯ
• ВВЕДЕНИЕ
• РАЗДЕЛ 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
• 1.1 Основные понятия компьютерной игры
• 1.2 Развитие
• 1.3 Классификация компьютерных игр
• 1.4 Игровая терминология
• 1.5 Взаимодействие игровых объектов
• 1.6 Итог
• РАЗДЕЛ 2. КОНЦЕПЦИЯ
• 2.1 Концепция
• 2.2 Постановка задачи
• РАЗДЕЛ 3. РАЗРАБОТКА АРХИТЕКТУРЫ
• 3.1 Инструментальные средства
• 3.2 Основная модель
• 3.3 Реализация частных случаев объектов взаимодействий
• 3.4 Выводы
• РАЗДЕЛ 4. ОТЛАДКА ПРОГРАММНОГО КОДА
• 4.1 Основные понятия
• 4.2 Отладка программного кода с помощью логирования в Unity3D
• 4.3 Использование отладчика в среде разработки Visual Studio 2012
• 4.4 Выводы
• РАЗДЕЛ 5. КОНТРОЛЬНЫЙ ПРИМЕР
• 5.1 Введение
• 5.2 Одиночные взаимодействия и состояния
• 5.3 Обработка триггеров и отложенный запуск события
• 5.4 Комплексные взаимодействия
• ЗАКЛЮЧЕНИЕ
• СПИСОК ЛИТЕРАТУРЫ

• ВВЕДЕНИЕ

Ни одна компьютерная игра не может обойтись без интерактивности.

• В виртуальном пространстве может находиться очень много различных объектов. Они могу двигаться, изменятся, взаимодействовать друг с другом. Интерактивность игры в свою очередь является результатом их взаимодействий. Мы можем получать информацию от различных объектов, передавать им сообщения, непосредственно влияя на них самих. Это может породить цепную реакцию событий, представляющую собой влияние одного действия на другое, а другого на третье и так далее.
• Цель дипломной работы - разработать архитектуру (модель) для унификации взаимодействия объектов в виртуальном пространстве для обеспечения гибкости и возможности масштабирования.
• Для достижения этой цели требуется изучить предметную область и создать концепцию модели взаимодействий.


РАЗДЕЛ 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Основные понятия компьютерной игры

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

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

В США игры признаны как предмет искусства, что позволяет им конкурировать с кино.

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

1.2 Развитие

Компьютерные игры появились достаточно давно, и развиваются, по сей день. История игр началась в 50-ые года прошлого столетия.

50-ые года

Великолепная тройка сделал первые шаги:

· Ральф Баэр - инженер, в 1951 году предложил идею интерактивного телевиденья;

· Дуглас А.С. в 1952 году создал компьютерный аналог крестиков-ноликов, который получил название “OXO”;

· Уильям Хигинботем в 1958 году разработал компьютерную игру “Теннис”, в которую можно было играть втроём.

60-е годы

В 1962 году компания Digital Equipment Corporation разработала игру культовую Space War.

Рисунок 1.1. Игра Colossal Cave Adventure.

70-е годы

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

Позднее, в 1975 году Уильям Кроутер создал игру, которая является отцом приключений с названием Colossal Cave Adventure, к этой игре был проявлен большой интерес со стороны общественности.

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

Рисунок 1.2. Очень популярная игра Pac-man.

80-е годы

80-ые годы можно назвать эрой наступления компьютерных игр. Так как персональные компьютеры сильно подешевели, их рынок стал серьезно возрастать. Так же появились компании, специализирующиеся только на компьютерных играх. Компанией Namco была выпущена многим известная игра “Pac-Mac”. В которой, вам приходилось управлять круглым жёлтым существом, перемещаясь по лабиринту, попутно собирая овощи и фрукты, при этом избегая враждебных существ.

В 1987 появились графически адаптеры VGA и SVGA, которые позволили отображать до 256 цветов, чем 16 цветов прошедших лет.

90-ые

В эти годы индустрия компьютерных игр стала расти всё сильнее и сильнее. В 1993 году очень известная компания Id Software, выпустила культовую игру Doom и именно она заложила основы жанра “Шутер”.

Начинания с 90-х бум компьютерных игр стал только набирать обороты, а индустрия расти и расти. В 1993 году 10 декабря компанией Id Software, был выпущен великий Doom. Игра которая заложила основы жанра шутер.

Самая первая игра с поддержкой сети появилась в 1994 под названием Rise of the Triad. Первый 3D-квадзи шутер появляется на следующий год под названием The Terminator: Future Shock. Но тогда ещё не было поддержкой 3D, но частичный объем мира, врагов и свободный обзор мышкой давал отличный эффект.

Рисунок 1.3. Одна из первых 3D игр - Duke Nukem 3D.

1996 год является эрой начала настоящих 3D игр. Появляетя первая в мире карта с поддержкой 3D - Voodoo I. Такие технологии позволили выпустить Duke Nukem 3D и Quake - первые в мире полностью трехмерные игры. Так же в этом году появились такие игры, как Super Mario, Command & Conquer: Red Alert, Tomb Raider, Resident Evil, Diablo и все-все-все.

Рисунок 1.4. Стратегическая игра Command & Conquer: Red Alert.

В 1998 году появляются культовые игры StarCraft и Half-life. Их продуманная механика позволила не терять к ним интерес на протяжение нескольких лет и по сей день в эти игры играют.

Новое время

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

Рисунок 1.5. Современная игра Crisis.

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

1.3 Классификация компьютерных игр

Компьютерные игры можно классифицировать по различным критериям:

· Жанр: геймплей задает жанровую направленность, возможно несколько разновидностей;

· Режим игры: одиночный или многопользовательский;

· Визуальное представление: игра может, как использовать графические средства оформления, так и напротив, быть текстовой. Игра также может быть двухмерной или трехмерной. Есть и звуковые игры -- в них вместо визуального представления используются звуки.

· Платформозависимость: на каких платформах возможет запуск игры, так же игры бывают платформонезависимыми (кроссплатформенными).

Классификация по жанрам:

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

· Боевик (Action) -- игра, требующая от игрока постоянных действий, насыщенная боевыми сценами, драками и перестрелками.

· Ролевая игра (RPG -- англ. Role Playing Game) -- игра, отличительной особенностью которой является наличие у персонажей определённых навыков и характеристик, которые можно обрести, а впоследствии развивать, выполняя какие-либо действия. К этому жанру относятся и многопользовательские ролевые игры (ММОРПГ), которые, в отличие от однопользовательских, не имеют ни конечной цели, ни законченного сюжета. Примеры: Gothic (серия).

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

· Компьютерный симулятор (Simulator) -- игра, созданная с целью симуляции реальных действий в жизни, например управление автомобилем или симулятор танкиста.

1.4 Игровая терминология

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

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

Texture - текстура. Это обычно двух мерное изображение, которое можно использовать как для наложения её на трёхмерные модели, так и отрисовки на экране как картинку.

2D-game - двумерная игра - игра, в которой используется только двухмерное пространство.

3D-game - трёхмерная игра - использующая трехмерные модели и трехмерный игровой мир.

Tile - тайл - небольшое изображение, которое используется для конструирования уровней в играх Так же существует такое понятие как AutoTile - это механизм создания бесшовных карт.

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

Pixel (пиксель) - наименьший элемент растрового изображения, точка, отображаемая на экране. Обычно в пикселях измеряют разрешение текстур (например - 640х640), экранное разрешение монитора, размеры игровых окон. Слово Pixel - это аббревитура от Picture's Element.

Texture Filtering (фильтрация текстур) - уменьшение искажений при наложении текстур на трехмерный объект.

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

Light Model (модель освещения) - способы моделирования освещения объектов.

1.5 Взаимодействие игровых объектов

«Заговори, чтобы я тебя увидел».

Сократ

Абстрагируясь от особенностей конкретной игры, можно считать, что игровой мир представляет собой некоторый набор объектов произвольной природы (игровых объектов) и правила их взаимодействия. Игрок (или игроки в многопользовательском случае) - один из этих объектов, при этом для игр рассматриваемого жанра всегда можно указать набор объектов, поведение которых определяется действиями того или иного игрока. Такие объекты мы будем называть персонажами данного игрока, они наиболее важны и интересны.

Практически ни одна компьютерная игра не обходится без взаимодействия с игровым пространством. Одним из примеров может послужить Dreamfall: The Longest Journey.

Игровой процесс

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

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

Игра трёхмерная, персонажи управляются клавиатурой (движение) и мышью (поворот камеры, действие).

Игрок управляет не одним персонажем, а в зависимости от сюжета периодически переключается на одного из трёх центральных персонажей -- Зои Кастильо, Эйприл Райн или Киана Альване.

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

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

С помощью геометрических алгоритмов луч может оповещать нас о пересечении с каким-либо объектом, объект должен обладать формой.

Пример Ray casting:

Рисунок 1.6. Использование Ray casting.

На рисунке 1.6 видно, как красный луч пересекает куб. С помощью управления камерой мы можем менять направление луча, таким образом можно использовать Ray cast как способ взаимодействия с окружением.

Рисунок 1.7. Использование Ray casting в игре для поиска предметов.

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

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

Результат взаимодействия:

· Левая клавиша мыши как условие взаимодействия;

· Звуковое сообщение и текст как результат взаимодействия.

С помощью рассмотренного примера можно рассмотреть схему взаимодействия:

Рисунок 1.9. Поэтапная схема взаимодействий с объектами.

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

Пример взаимодействия с невидимым объектом:

Рисунок 1.10. Триггерная зона взаимодействия.

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

Условие запуска - автоматически (дополнительных условий не нужно).

Результат - игровая сцена (внутри игровой ролик, для повествования процесса).

Рисунок 1.10. Результат взаимодействия с объектом (игровая сцена).

1.6 Итог

Проанализировав несколько примеров взаимодействия объектов в игровом пространстве, можно обобщить взаимодействия и сделать некоторые выводы.

Объекты взаимодействия обладают некоторой общностью:

· Способ взаимодействия (автоматический, нахождения объекта на сцене, использование инструмента поиска или RayCasting);

· Состояние объекта (определяет текущее поведение);

· Коммуникация (приём и отправка сообщения для обмена информация между объектами);

· Условие взаимодействия (Определённые условия для взаимодействия с объектом, например, клавиша мыши, значения определённых переменных и т.д.);

· Событие (или действие, которое происходит с помощью способа взаимодействия и проверки условия), могут срабатывать различные события, в зависимости от типа сообщения и влияют на состояния объекта.

РАЗДЕЛ 2. КОНЦЕПЦИЯ

2.1 Концепция

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

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

Рисунок 2.1. Общая концепция обмена сообщениями.

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

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

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

Основной алгоритм взаимодействия с объектом:

Рисунок 2.2. Основной алгоритм взаимодействия с объектом.

Каждый интерактивный объект, может совершать какие-либо действия. Чтобы действие произошло, оно проходит ряд проверок, одно из них: условие взаимодействия.

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

Условия и события зависят от состояния объекта. Состояния строятся в простой детерминированный конечный автомат и содержат в себе условия и событие для данного состояния:

Рисунок 2.3. Диаграмма состояний объекта.

На примере игровой двери:

Рисунок 2.4. Диаграмма состояний объекта на примере двери.

С помощью данной концепции можно построить гибкую и расширяемую модель взаимодействия между объектами в виртуальном пространстве. Так же концепция обеспечит независимость объектов с помощью обмена информацией между ними и сложное поведение с помощью состояний.

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

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

Основная цель: добиться гибкости и масштабируемости.

Рисунок 2.5. Общая схема архитектуры взаимодействий.

Реализовать главный объект иерархии InteractiveObject.

Он должен включать в себя базовую концепцию и обладать:

· Набором состояний с условиями взаимодействия и запуска, а так же самим событием;

· Добавление и удаление состояний;

· Подписываться и отписываться для прослушивания сообщений;

· Добавлять слушателей сообщений;

· Отправлять и обрабатывать сообщения.

На основе архитектуры выделить и реализовать основные интерактивные объекты, с помощью которых, можно строить более сложные модели.

Объект Player:

· Условие взаимодействия: взгляд (Raycast);

· Условие запуска: клавиши ввода, дополнительные условия, такие как предметы, сообщения отличаются типом.

Управляемые и управляющие объекты.

Управляемые объекты:

· Предоставление данных, которые можно изменять (посредством передачи сообщений);

· Смена управляющих объектов “на лету”;

· Удаление управляющих объектов;

· Запрет на изменение данных.

Управляющие объекты:

· Независимое представление управляемого объекта;

· Изменение данных управляемого объекта посредством сообщений.

РАЗДЕЛ 3. РАЗРАБОТКА АРХИТЕКТУРЫ

3.1 Инструментальные средства

Unity 3D

Рисунок 3.1. Логотип Unity3D.

Unity -- это мультиплатформенный инструмент для разработки двух- и трёхмерных приложений и игр, работающий под операционными системами Windows и OS X. Игры, созданные на данном инструменте можно портировать на: Windows, OS X, Android, Apple iOS, Linux, а также на игровые приставки Wii, PlayStation 3 и XBox 360. Так же можно создавать игры, работающие в браузере, для этого надо установить специальный модуль Unity Web Player. Также приложения созданные, с помощью Unity3D поддерживают обе спецификации 3D графики DirectX и OpenGL.

Особенности

· Несколько сценарных языков программирования: C#, JavaScript (модификация) и Boo;

· Возможность мгновенного запуска игры;

· Простая работа с ресурсами через Drag-and-Drop;

· широкие возможности импорта

· полностью настраиваемый и доступный большинству людей интерфейс

· кроссплатформенность

· мощь, гибкость и бесконечная расширяемость

· наличие бесплатной версии с некоторыми ограничениями

Рисунок 3.2. Графический интерфейс Unity3D.

Visual Studio 2012

Рисунок 3.3. Логотип Visual Studio 2012.

Microsoft Visual Studio -- линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств.

Visual Studio включает в себя редактор исходного кода с поддержкой технологии IntelliSense и возможностью простейшего рефакторинга кода. Встроенный отладчик может работать как отладчик уровня исходного кода, так и как отладчик машинного уровня. Остальные встраиваемые инструменты включают в себя редактор форм для упрощения создания графического интерфейса приложения, веб-редактор, дизайнер классов и дизайнер схемы базы данных. Visual Studio позволяет создавать и подключать сторонние дополнения (плагины) для расширения функциональности практически на каждом уровне, включая добавление поддержки систем контроля версий исходного кода (как например, Subversion и Visual SourceSafe), добавление новых наборов инструментов (например, для редактирования и визуального проектирования кода на предметно-ориентированных языках программирования или инструментов для прочих аспектов процесса разработки программного обеспечения (например, клиент Team Explorer для работы с Team Foundation Server). В данной работе Visual Studio 2012 используется как лучшая альтернатива MonoDevelop, которую использует Unity3D “из коробки”.

Рисунок 3.4. Графический интерфейс Visual Studio 2012.

Язык программирования C#

C# (произносится си шарп) -- объектно-ориентированный язык программирования. Разработан в 1998--2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как язык разработки приложений для платформы Microsoft .NET Framework и впоследствии был стандартизирован как ECMA-334 и ISO/IEC 23270.

C# относится к семье языков с C-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку операторов (в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщённые типы и методы, итераторы, анонимные функции с поддержкой замыканий, LINQ, исключения, комментарии в формате XML.

Переняв многое от своих предшественников -- языков C++, Java, Delphi, Модула и Smalltalk -- С#, опираясь на практику их использования, исключает некоторые модели, зарекомендовавшие себя как проблематичные при разработке программных систем, например, C# в отличие от C++ не поддерживает множественное наследование классов (между тем допускается множественное наследование интерфейсов).

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

3.2 Основная модель

“Стремитесь к слабой связанности взаимодействующих объектов”

Head First Java Patterns

Обычно в играх очень много различных взаимодействующих объектов.

Чем меньше они знают друг о друге, тем гибче система. Одному компоненту нет необходимости знать о внутреннем устройстве другого.

Коммуникации

Для обеспечения коммуникации для взаимодействующих объектов используем паттерн “Наблюдатель”.

Наблюдатель (Observer) -- поведенческий шаблон проектирования. Также известен как «подчинённые» (Dependents), «издатель-подписчик» (Publisher-Subscriber).

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

Создадим интерфейс для независимости от реализации.

public interface Observer {

void AddListener(string eventType, Callback handler);

void AddListener<T>(string eventType, Callback<T> handler);

void AddListener<T, U>(string eventType, Callback<T, U> handler);

void AddListener<T, U, V>(string eventType, Callback<T, U, V> handler);

void RemoveListener(string eventType, Callback handler);

void RemoveListener<T>(string eventType, Callback<T> handler);

void RemoveListener<T,U>(string eventType, Callback<T,U> handler);

void RemoveListener<T,U,V>(string eventType, Callback<T,U,V> handler);

void Fire(string eventType);

void Fire<T>(string eventType, T arg1);

void Fire<T, U>(string eventType, T arg1, U arg2);

void Fire<T, U, V>(string eventType, T arg1, U arg2, V arg3);

}

Observer представляет собой очень гибкий интерфейс на основе обобщений, в качестве первого аргумента передается тип события, второй аргумент Callback - перегруженный делегат (метод) на основе обобщений.

public delegate void Callback();

public delegate void Callback<T>(T arg1);

public delegate void Callback<T, U>(T arg1, U arg2);

public delegate void Callback<T, U, V>(T arg1, U arg2, V arg3);

Проанализировав предметную область, выделим временную составляющую взаимодействий:

- Долговременные взаимодействия (Должна быть возможность получить коммуникации для обмена сообщения с объектом);

- Мгновенные взаимодействия;

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

На основе этих доводов определим, интерфейс для интерактивного объекта:

interface INteractive {

void Connect(IDispatcher from);

void Disconnect(IDispatcher from);

void Send(string eventType);

void Send<T>(string eventType, T arg);

void Send<T, U>(string eventType, T arg1, U arg2);

void Send<T, U, V>(string eventType, T arg1, U arg2, V arg3);

}

Connect - Получение коммуникаций для дальнейшего обмена информацией.

Disconnect - Разрыв коммуникаций для прекращения обмена.

Send - Мгновенная отправка информации без установления коммуникаций.

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

Для реализации механизма работы “Обозревателя” агрегируем специально подготовленный объект Messager.

Диаграмма 3.1. Абстрактная модель обмена сообщениями.

Состояния

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

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

Для начала опишем требования к автомату:

- Добавление/Удаление состояний;

- Смена состояния;

- Обновление состояния;

- Доступ к владельцу;

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

- Доступ к владельцу;

- Перехват входа/выхода состояния;

- Исполнение обязанностей состояния;

Добавим возможность смены состояний для основной модели взаимодействий.

Диаграмма 3.2. Абстрактная модель с поддержкой состояний.

Теперь все требования учтены, рассмотрим полную картину:

Диаграмма 3.3. Финальная диаграмма интерактивного объекта.

Данная модель обладает коммуникациями для обмена информацией с другими объектами, построенными на этой модели.

Возможность смены состояний на основе конечных автоматов.

InteractiveObject включает в себя все требования. Частные случаи создания объектов взаимодействий будут рассмотрены в следующем разделе.

3.3 Реализация частных случаев объектов взаимодействий

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

4.1 Основные понятия

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

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

В этом разделе мы рассмотрим два варианта отладки:

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

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

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

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

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

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

Рисунок 4.1. Консоль Unity3D.

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

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

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

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

Рисунок 4.2. Уровни логирования.

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

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

Пример:

Неиспользуемая переменная.

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

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

его методы:

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

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

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

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

Рисунок 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);

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

Рисунки 4.4. - 4.6. Результаты работы логирования.

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

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

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

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

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

Рисунок 4.7. Отладчик, готовый к работе.

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

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

Рисунок 4.8. Точка останова.

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

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

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

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

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

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

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

Рисунок 4.9. Отладчик в рабочем режиме.

С помощью этого инструмента можно:

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

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

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

4.4 Выводы

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

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

5.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 5.5. Дверь готова к взаимодействию.

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

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

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

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

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

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

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

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

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

Рассмотрим этот объект подробнее:

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

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

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

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

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

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

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

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

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

Рисунок 5.10. Триггер в виде огня.

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

Рисунок 5.11. Пример лестницы с триггером

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

Рисунок 5.12. Лестница поднимается после активации триггера.

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

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

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

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

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

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

Рисунок 5.13. Сцена в исходном состоянии.

На сообщения, представленные выше, может реагировать объект RadioWheel:

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

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

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

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

· дует ветер.

Рисунок 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.

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